(This is quite a technical blog post but projects like this are the reason we’re able to deliver broadcast infrastructure faster, at lower-cost and better than anyone else. For some background visit: http://www.slideshare.net/kierank12/implementing-uncompressed-over-ip-in-software-and-the-pitfalls).
At Open Broadcast Systems we push £200 Blackmagic video boards in ways the creators didn’t intend. We add functionality that people continue to tell us can only be done with specialist hardware with price tags ten, or even a hundred times more.
We also have an SMPTE 2022-6 (SDI over IP) stack written entirely in software, designed for use with standard Network Cards, something which surprised many visitors from hardware-centric vendors to our booth at IBC.
We depend on a lot of obscure functionality of Blackmagic products that we currently test manually. One of these in the C-200 decoder is the ability to realign the audio bitstream with respect to the video frame and making sure this alignment stays consistent and doesn’t drift. This capability for example is used to realign Dolby E audio on the correct line for clean splicing. For our customers who are handing off an SDI feed to a third-party, they can be sure that Dolby E is on the correct line.
The problem we face is that across the range of Blackmagic cards we have in the field for playback (Decklink Duo, Decklink SDI 4K, Decklink Quad 2, Decklink Duo 2) is that there are a large number of combinations of driver/firmware and model and output resolution. We need to be sure that updates we push don’t break existing functionality. So we turn to what the rest of the software industry does in this case, unit testing, except this time using physical hardware. At the same time we also need a way of unit testing the SDI bitstream reader and writer we created as part of our SMPTE 2022-6 implementation. So this kills two birds with one stone.
To do this we needed a way of capturing a full SDI frame – we can do this in the IP domain easily but Blackmagic cards don’t expose this because they want to provide a unified interface to analogue, HDMI and SDI. So we turned to the Dektec Dtu-351 USB3 capture device which now has Linux drivers. It took some trial and error to find a machine the drivers didn’t crash on however (binary blobs are great!). Naturally, being a company which writes in C or assembly, we also converted the 2000 line C++ example capture tool to 300 lines of C to build a upipe module. Being USB3 also helped reduce the number of PCIe slots. We believe there isn’t much else for a similar price that can do raw SDI capture.
Using our existing SDI parser we can now unit test the following:
- SDI CRC
- SDI samples per line
- Valid TRS
(The above are largely for the IP world, we can assume capture hardware does these checks)
- Correct number of audio samples
- SMPTE 337 (Dolby E) line position
- Audio BCH code correctness
- Audio and audio control packets on the correct line
- Audio packet clock offset correctness (lots of vendors don’t seem to bother about this)
From there we can easily update firmware/driver of our Blackmagic Cards and make sure the SDI bitstream is valid. We could also test for sample accuracy but at this point we decode a recorded transport stream to test our entire decode pipeline.
You can see how as the stream starts and stops the SMPTE 337 syncword stays within the tolerance of 21±2 lines.
This unit testing lets us do something very interesting as well, testing compliance of other vendors’ 2022-6 implementation. Note that I write compliance and not interoperability, these aren’t the same thing. More on that another day.
Special thanks to the Blackmagic Support team for their extensive help and our colleagues at Vericom and DMC (especially Mark) for pushing our team to do great things.
Want to work in the SpaceX of broadcast technology?
We can’t provide perks like pool tables and juice bars but you can work in an functioning broadcast centre in Central London on delivering high profile content to millions in a fast paced but fun environment. We design, build and deploy all our core technology from scratch and open source the vast majority of it. Our customer-base is committed to pushing the boundaries of IT (and not just IP) in broadcast without being constrained by old viewpoints. After all, would any other broadcast manufacturer post details of their tech in public.
