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.
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.
Actually SMPTE 2110 can host video (2110-20), audio (2110-30) and ancillary data (2110-40) essences, and each essence can be delivered independently of the others.
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)
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.
ST 2110-22 is codec agnostic. It just standardises CBR compression, for which JPEG-XS is a good fit today.
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.
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.
> like why they use bundles of analog copper wire for audio instead of digital fiber
Good article. Got me to read the article because I was curious why...
nice to see an article from my industry! st2110 is such a complex standard which a lot of the hardware mentioned has been molded to deal with.
Fun to see.
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...
Actually SMPTE 2110 can host video (2110-20), audio (2110-30) and ancillary data (2110-40) essences, and each essence can be delivered independently of the others.
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.
ST 2110-22 is codec agnostic. It just standardises CBR compression, for which JPEG-XS is a good fit today.
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.
Ooh, you're right, and it just adopts the IETF RTP payload types for that. Cool.
Also forgot about IPMX.
It's worth mentioning NDI (Network Device Interface) as well, which is widely used in the Pro-AV for transporting compressed video and audio over IP.