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.

https://stop2110.org/

> 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).

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.