Most 2110 kit relies on narrow timing. That means packets arriving and leaving in a window on the order of 10 microseconds. Doing that in software reliably for your typical 100gbit interface is challenging.
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.
I want to add that if wifi 8 delivers half the reliability improvements it promises, we really need more IP A/V devices fast! Huge promise!
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.
You might also want to mention AMWA NMOS, which is increasingly used alongside SMPTE 2110 in setups like this. NMOS (Networked Media Open Specifications) defines open, vendor-neutral APIs for device discovery, registration, connection management, and control of IP media systems. In practice, it's what lets 2110 devices automatically find each other, advertise their streams, and be connected or reconfigured via software.
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.
I'm amused but not entirely surprised to see that live video production hasn't meaningfully progressed since I was involved 30+ years ago.
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.
Seems the classic legacy overengineered thing that costs 100x production costs because it's a niche system, is 10x more complex than needed for to unnecessary perfectionism and uses 10-100x more people than needed due to employment inerta.
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
That's certainly true to an extent. Other commenters have already highlighted necessary complexities. There is absolutely a lot of very entrenched "ways-of-working" that add unnecessary complexity, as with every domain. Not everything is a technical problem though and the social / process side of this sort of setup is what can make it work at all.
Today's broadcasting truly is a beautifully evolved piece of engineering. For a guy like me who dabbles in time / frequency synchronisation, this is a great example of a use case that physically malfunctions without sync.
...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.
15 comments
[ 3.2 ms ] story [ 31.4 ms ] threadPipeWire 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...
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.
Good article. Got me to read the article because I was curious why...
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.
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.
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
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.
...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.