Exploring a Modern SMTPE 2110 Broadcast Truck
jeffgeerling.com
jeffgeerling.com
The specs are fully open source and developed in the open, with reference implementations available on GitHub (https://github.com/AMWA-TV)
The specs define REST API's, JSON schemas, certificate provisioning, and service discovery mechanisms (DNS-SD / mDNS), providing an open control framework for IP-based media systems.
PipeWire had some decent AES67 support for network audio. Some really fun interesting hardware already tested. Afaik no SMPTE 2110 (which is video) but I don't really know.
I know it's not the use case but I do wish compressed formats were more supported. Not really necessary for production, but these are sort of the only defacto broadly capable network protocols we have for AV, so it would expand the potential uses a lot IMO. There may be some very proprietary JPEG-XS compression, but generally the target seems to be uncompressed.
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/AES...
ST 2110-22 standardizes compressed video using JPEG XS. While there is a patent pool for XS, otherwise the format is standardized and open.
It would be nice to see an essence type defined for AVC, but the quality tradeoffs of AVC/HEVC are really not appropriate for the domain that ST 2110 is aiming for: which is the contribution side video network of a broadcast operation.
There are alternative "consumer grade" and "prosumer grade" IP video solutions out there.
There is Teleport which is growing up in the OBS space, but is quite capable (we've used it in production for quite awhile)
https://github.com/fzwoch/obs-teleport
And of course the underpinning of 2110 itself is RTP, which is a standard network protocol, which does have AVC defined as a payload type in RFC 6184
https://www.rfc-editor.org/rfc/rfc6184
Really it's a bit odd to wish that ST 2110 had compressed video when it's really just a specific profile of RTP with some broadcast specific bits on top while RTP itself does support lots of payloads.
ST 2110-10 which provides the timing just standardizes PTP and the meaning of the RTP timestamps (notably a specific epoch), but there's nothing stopping you from using PTP based timestamps for your RTP payloads otherwise.
ST 2110 is not a "plug and play" system by itself. There is a whole standard that adds in such capabilities which is the NMOS IS standards, but none of that is attempting to make "peer to peer" (so to speak) ST 2110 a thing, so actually using it for anything other than a broadcast system is far from trivial, and you'd be better off using something else. NMOS goal is to make auto configuration of ST2110 flows a thing, which they have broadly succeeded in doing.
For plug-and-play IPMX (https://ipmx.io/about/) is looking to be a pretty promising approach that combines ST 2110 with NMOS, auth, encryption and other useful features. It's targetted at the ProAV market but IMO should be mostly suitable for consumer use.
Also forgot about IPMX.
Jpeg-xs did indeed get ffmpeg support a couple months ago. https://www.phoronix.com/news/FFmpeg-Merges-JPEG-XS
And those need good protocols, to get anywhere. Ideally with compression.
It's both overkill, but also, extending ST 2110 and or AES67 feels like a really good option, feels sort of like what we have for semi standard IP AV. There are some other notable interesting techs listed too. I don't have a horse in the race but I do want some maximalist big very capable protocols that are broadly adopted.
Yes, the technology has evolved – digital vs analog (partly – for example analog comms here because digital (optical) "isn't redundant" (lol, what?)); higher resolution; digital overlays and effects, etc. But the basic process of a bunch of humans winging it and yelling to each other hasn't changed at all.
This is an industry ripe for massive disruption, and the first to do it will win big.
Good article. Got me to read the article because I was curious why...
...but the first time I learned about SMPTE, was from Frank Zappa's song "Baby Snakes" - interestingly it mentiones both SMPTE and sync. Every time SMPTE is mentioned, this plays in my head.
A more reasonable thing is to just use high quality cameras, connect to the venue fiber Internet connection, use normal networked transport like H.265 with MPEG-TS over RTP (sports fans certainly don't care about recompression quality loss...), do time sync by having A/V sync and good clocks on each device and aligning based on audio loud enough to be recorded by all devices, then mix, reencode and distribute on normal GPU-equipped datacenter servers using GPU acceleration
Perfect is the enemy of the good, as always—reading through that site, it seems like no solution is perfect, and the main tradeoff from that authors perspective is bandwidth requirements for UHD.
It looks like most places are only hitting 1080p still, however. And the truck I was looking at could do 1080, but runs the NHL games at 720p.
The “no standalone switch can give enough bandwidth” issue has generally been solved since that page was written. You can buy 1U switches now off-the-shelf with 160x100G (breaking out from 32x800G). One of the main drivers of IP in this space is that you can just, like, get an Ethernet switch (and scale up in normal Ethernet ways) instead of having to buy super-expensive 12G-SDI routers that have hard upper limits on number of ins/outs.
Of course, most random YouTubers are not going to need this. But they also are not in the market for broadcast trucks.
We sort of traded the big expensive SDI switchers for big expensive SDNs
I never fully understood why SDI over fiber remains so niche, e.g. UHD people would rather do four chunky 3G-SDI cables instead of a much cheaper and easier-to-handle fiber cable (when the standards very much do exist). But once your signal is IP, then of course fiber is everywhere and readily available, so there seems to be no real blocker there.
They'd obviously need a lot less and the lines are a lot lighter but maybe folks figured if they could avoid repeating that scenario in their design, it might be a good idea :-P
* Outer diameter: 6mm
* Max tensile load: 900 N
* Crush resistance: 750 N / 10 cm
* Max proof stress: >= 0,69 GPa
That being said, if you aren't already in the Newtek/Vizrt ecosystem, might I recommend exploring Teleport, which is a free and open source NDI alternative built into OBS which has also served us very well.
Why do you need good clocks? For audio, even with simultaneously playing speakers, you only need to synchronize within a couple of ms unless you need coherence or are a serious audiophile. If if want to maintain sync for an hour I suppose you need decently good clock.
But as long as you have any sort of wire, basically any protocol can synchronize well enough. Although synchronizing based on visual and audible sources is certainly an interesting idea. (Audio only is a completely nonstarter for a sporting event: the speed of sound is low and the venues are large. You could easily miss by hundreds of ms.)
> then mix, reencode and distribute on normal GPU-equipped datacenter servers using GPU acceleration
Really? Even ignoring latency, we’re talking quite a few Gbps sustained. A hiccup would suck, and if you’re not careful, you could easily spend multiple millions of dollars per day in egress and data handling fees if you use a big cloud. Just use a handful of on-site commodity machines.
Suppose you give a budget of 4ms to composite the frame. Now you have 12.7ms from the end of the previous frame in which to collect the current frame from each camera and do whatever fancy processing you want to do (drawing first down lines, adding ads, etc). Of course, you can always cheat a bit by pipelining frames, but this adds latency, and maybe you would prefer to avoid that. Let's say you don't want to pipeline and you budget 8.7ms for all this fancy work, which gives you a 4ms window in which to receive all your incoming frames, which need to be in exact lockstep from all cameras. (This is very, very conservative, since, again, this is not a videogame and it's probably fine to buffer all inputs for a few tens or even hundreds of ms. I'm ignoring the time to transfer each frame -- I'm assuming we're counting from the end of the frame transfer time. If it takes a full frame to transfer a frame, then you cannot possibly avoid one frame of transfer latency anyway.)
So you need all those fancy cameras to stay in sync to plus or minus 4ms. That's a piece of cake with basically any modern technology, where "modern" means, I don't know, the last 30 years? NTP can do this. PTP can do this even with a fully software implementation and no assistance from the switches whatsoever. A cellphone can do this. A fancy GPSDO can do orders of magnitude better than this. A decent RTC will take a whole 200 seconds to drift by a problematic amount. The only actual fancy tech needed is the ability for the host controller on each camera to discipline the camera's frame clock, which I imagine any camera worth its salt can do.
I don't see why a $30k clock is useful here, or why very fancy protocols are needed. I do see why there's a need to get everyone to agree on a protocol, though.
I did once watch an event where I was genuinely impressed by the synchronization, though: a parade at a theme park. There were hundreds or thousands of fixed speakers and hundreds of mobile speakers in the parade, and all of them stayed perfectly synchronized, playing parts of the same music, to within the precision of my ears. I'm guessing the design goal was better than 1ms synchronization error, over at least half an hour, across acres of space, in a potentially adverse RF environment (at least the ISM bands would have been horribly polluted by everyone's phones). And possibly the mobile speakers would even have needed to compensate for their own locations due to the speed of sound being kind of low and the actual parade speed possibly being a bit unpredictable.
If I were designing that, I might have used GPSDOs on each mobile element or possibly some kind of wireless clock distribution -- a 20ppm clock is not even close to good enough.
But event broadcasting doesn't have these problems per se because, anywhere there's a camera, there's already a reliably, high-bandwidth data link of some sort so the camera feed can get to where it's going in real time.
There are many microphones involved in a production, and humans are quite good at detecting desync between audio/video when watching a presenter talk. You cannot fix desynchronization further down the chain if the desynchronization is variable for each source.
> sports fans certainly don't care about recompression quality loss...
I think that's quite an assumption. In a modern video chain youd need to decompress and recompress the video from a camera many many times on the way to distribution. Every filter or combining element would need to have onboard decoding and encoding which would introduce significant latency, would be very difficult to maintain quality, and would introduce even more energy requirements than the systems we already deploy.
High quality cameras aren't any good if they throw away their quality at the source before they have an opportunity to be mixed in with the rest of the contribution elements. You certainly wouldn't compress the camera feeds down to what you'd expect to see on a consumer video feed (about 20Mbps for 4K on HEVC).
> normal networked transport like H.265 with MPEG-TS over RTP
If you want to, you can do that already using SMPTE ST 2110-22 which loops in the RTP payload standards defined by the IETF. ST 2110 itself is already using RTP as its core protocol by the way (for everything).
> do time sync by having A/V sync
What do you mean by this? In order to synchronize multiple elements you need a common source of time. Having "good clocks" on each device is not enough: they need to be synchronized to the level that audio matches up correctly, which is much more precise than video as audio uses sample frequencies in the 48Khz-96Khz range, whereas video of course is typically just 60Hz. Each clock needs a way to _become_ good by aligning themselves to some global standard. If you don't have a master clock like PTP, your options are... what... GPS? I mean you _could_ equip each device with its own GPS transponders, but if the cameras cant get a reliable GPS lock then you're out of luck.
> aligning based on audio loud enough to be recorded by all devices
Do you mean physically? Like actual audio being emitted into the space where the devices are? Because some of the devices will be in the stadium where theres very very loud noises on account of the crowd, and some of them will be in the backroom where that audio is not audible. Then you need to factor in the speed of sound, which is absolutely significant in a stadium or other large venue. None of this is particularly practical.
If you mean an audio sound that is sent to each device over a cable, well are we talking SDI (copper)? If so, we wouldnt use audio for that, we would use what's called Black Burst. But what generates the black burst? Typically, its the grandmaster clock. The black bursts on SDI need to be very precise, and that requires a dedicated piece of real time hardware.
If you mean sending it over ethernet, you now need to ensure you factor in the routing delays that will inevitably happen over an open unplanned network. To deal with those delays, we typically do two things. One, we use automatically planned networks, where the routers are aware of the media flows going over each link, and the topology is automatically rearranged in order to minimize or eliminate router buffering (aka software defined networks, typically using NMOS IS standards to handle discovering and accounting for the media essences).
Typically video equipment expects the individual pixels to line up, save for some buffering (~1–10µs), not just the individual frame. So your synchronization requirement for video is in the gigahertz range (or about megahertz, if you take the buffering into account), not 60 Hz. (Of course, what matters is normally the absolute offset, not the frequency, but they tend to be somewhat inversely related.)
The approach that you're hinting mostly describes the general direction of remote production (https://video.matrox.com/en/media/guides-articles/what-is-re...). The big traditional players are already across that (https://www.grassvalley.com/ampp/, https://www.rossvideo.com/use-cases/remote-production/), AWS also has a plethora of services to lock you into their stack (https://aws.amazon.com/media-services/), and there's interesting new players too (https://www.tryiris.ai). There's a heap of different workflows out there, and OB trucks like the one highlighted here are just one of those.