Over the last decade, there’s been a quiet revolution in the world of video hardware. Readily available development kits, FPGAs, and new manufacturing processes mean it’s easier than ever for small companies to produce hardware. This has driven down the price of hardware in the video industry dramatically, and made hardware available to serve previously underserved niches. Platforms like Kickstarter mean independent inventors with an idea can track down a small but devoted audience. Whereas it used to take a massive, integrated manufacturer to build a camera or a capture device, it can now be done by a small team.
While this has benefited our industry across the board, it has had a noticeable impact. Small hardware vendors don’t usually have a big QA department to test and re-test their files, and often don’t have relationships with vendors to obtain official file writing libraries. In our work with customers, we see files from every imaginable piece of hardware, and we’ve noticed that some of this new hardware is a bit buggy.
Let’s back up briefly and talk about file format standards. Most of the common file formats (QuickTime MOV, MXF, etc) are meticulously documented and standardized. These standards are highly technical – they’ll explain exactly what each bit in a file means, how to write and parse different flags and account for all the special cases one might encounter. You can look at the raw bytes in a QuickTime file and, using the specification, know (for example) exactly what type of audio track it has, how many samples it has, and where in the file to find them.
While it can seem like a format like QuickTime is robust and identical between hardware, software and different platforms, in reality there’s the Apple “world” and everyone else. Because Apple doesn’t distribute software for other vendors to use in their hardware or software, developers and manufacturers need to “go it alone.”
When someone wants to build a piece of hardware that writes QuickTime files, they can go a couple routes. Often, they can repurpose an open source library, using something like the popular Libavformat. This has the benefit of providing well-tested, well-maintained code. However, different platforms, performance envelopes, and licensing requirements may dictate that developers needs to write their own QuickTime writer.
To do this, the hardware vendor will read through the spec, and write code to match it. But, developers aren’t perfect, and even the most well written spec isn’t crystal clear. As a result, hardware often writes files that aren’t quite perfect.
Let’s give an example. QuickTime stores some metadata in a portion of the file called the UDTA atom. The structure of this data dictates what type of string the metadata is written as (UTF8, UTF16, etc) and how long the string is. One piece of hardware we encountered leaves off the string format bytes, and only writes the string length. As a result, even though they put metadata in the file, no application on the computer can read it properly.
Working on EditReady, we’ve seen countless examples, some very obvious, some a bit more insidious.
Although it’s never good to have buggy hardware, the modern world of hardware has a few options for dealing with these bugs that didn’t exist in the past. First off, when we track down one of these bugs, we always report them to the vendor. Almost universally, vendors these days are much more receptive and accessible than in the “old” days. Second, hardware vendors have a lot more options for fixing these types of bugs. A simple software update – sometimes, even delivered over the internet directly – can usually resolve these things, and most vendors are eager to provide that type of support months or even years after selling their hardware.
Overall, we’re very excited about all of the cool hardware available these days, and we love playing our part in the process of making that hardware just a little bit better.