DME ResourcesStumbled on a blog post today about this topic, which is worth the read IMHO - "Why I moved away from FOSS as my main toolset". The author, whom I first met when he was a student in a LEVA Level 1 and/or 2 class I was teaching the better part of 10 years ago, raises some valid points about leveraging FOSS in DME workflows; training, support and documenting FOSS tools being the points I agree with. To that end, keep your eyes & ears open for news about professional training & support for FOSS solutions related to DME.
With that said, I'm going to make a few comments and pose a few questions to the community based on the above post, so if you haven't read it...the rest of this post is probably moot.
First, I always find it interesting when people do a 180. Of course, new information that can be validated is often the cause of this. Other times, not so much. In any case, another thing I find interesting about this post is the particular solution the author chose to standardize on. As he points out, "an application that had everything I needed and utilized some of the applications and libraries I was familiar with". I find this very interesting in that, based on my cursory knowledge and review of the solution, as well as their website and documentation, that particular solution doesn't reference any of the FOSS projects incorporated in it (e.g. FFmpeg binaries, OpenCV, Exiftool, MediaInfo, Libav libraries, and more). In fact, their license agreement states something to the effect of "entirely privately developed". Weird.
What's not weird, is that they also point out that you don't own their software; you're licensing it, and your license can be revoked at any time. Not unusual at all when it comes to software licensing, but it does make the hair on the back of my neck standup everytime I read that.
Quick thoughts and comments aside, a few questions to consider:
- How do you validate if you're only trained on or use one tool (any tool)?
- If it can parse the primary stream(s), how do you know when your tool can or can't read a proprietary/closed container properly?
- What are you missing if your tool can't parse the container? Metadata yes, but could the tool also overlook other streams?
- Does the File format even matter if video displays when you press play?
- Are you willing to testify in court that you never played the multimedia in the proprietary player that was specifically designed to play that proprietary file type?
- What framework(s) do your multimedia tools use?
- Is it possible that the tool the author standardized on could parse/display/report differently than other tools, as in the example about total frame count from his post, and if so...which tool is right and why? Does how much you paid for the solution have anything to do with this?
- Can we validate a FOSS tool that leverages a second FOSS solution as it's engine (e.g. MediaInfo using FFprobe), with another tool that uses the same engine?
- And so on, and so forth. :)
Multimedia Frameworks and container file formats matter. Proprietary software designed for a specific format matters too, whether we like that or not.
It's also not that hard to keep abreast of DME related FOSS solutions, especially if you're only using a handful of them regularly. Although documenting them isn't as elegant as some professional tools, on the plus side you can easily archive the actual FOSS solution(s) used. Twenty years from now someone could pull the case and process using the exact same software (Without needing to contact a vendor, that may no longer exist) to replicate your results.
Elephant in the Room
I am employed by a vendor. The author is employed by a vendor. We are both former law enforcement. I consider the author a friend. In fact, he was a large contributor here for a few years when he first entered the global DME community. I gladly allowed, and continue to allow, him and others to promote their own blogs here, if their posts are helpful to the community and aren't directly related to selling something.
I like to think we're all trying to do the right thing for the right reasons. In that regard, unfortunately I'm wrong more than I care to admit. As I say in every class I teach, EVERY tool has strenghts and weaknesses. There are many things about the author's solution of choice that I like, but there are several that are red flags for me personally; not properly crediting the FOSS solutions behind your GUI interface is one of them. It may seem like a minor issue to many, but I bet most of those that feel that way have never created any software...or tried to make a living from it. I'm a nit picker when it comes to my work. That's what I do, and probably one of the reasons why you're reading this.
Those that know me know that if I'm wrong, I'll do my best to be the first to admit it. I'm still hoping I'm wrong about the proper FOSS attribution and references for the "entirely privately developed" solution that the author has standardized on, especially since it could have legal ramifications. All the best my friends.
