This article is incorrect about WebRTC. I don’t know about other protocols and what they offer.<p>* Clock Recovery<p>I have had no problems with measuring NTP drift. As the clocks change I would measure.<p>* Common Clock for Audio and Video<p>Sender Reports contain a mapping of Sequence Number to RTP Sequence Numbers. This is respected by every player I have used. My guess is author put their media in different MediaStreams. If you want all your tracks to be synced you need to mark them as one MediaStream.<p>* Defined latency<p>WebRTC provides playoutDelay. <a href="https://webrtc.googlesource.com/src/+/main/docs/native-code/rtp-hdrext/playout-delay/README.md" rel="nofollow">https://webrtc.googlesource.com/src/+/main/docs/native-code/...</a>. This allows the sender to add delay to give a better experience.<p>* Legacy transport<p>You can transport anything you want via RTP or DataChannels. Maybe I am missing something with this one?
The simple answer:<p>MPEG-TS still exists because it’s <i>still</i> the best media container/transport system in existence.<p>It was designed and has evolved over a long time based on solid foundations by <i>very</i> smart people in the industry, across multiple institutions and professions.<p>As opposed to the “format du jour” that was quickly thrown together by some eastern block script kiddie who saw the basic outline of an AVI file and figured they could do better…<p>Case in point: MPEG-TS has scaled from DVD across BluRay (and DVD-HD) is the backbone of both satellite and terrestrial digital broadcasting.
> able to recover the clock of the source in order to know when to drop or duplicate video frames<p>So this is why I can never watch a whole movie and not have a single dropped frame!<p>Back in the old TV days, the TV camera set the 60 fps frequency, and if it was slightly slow at just 59.9 fps, then your TV would also run slightly slow. The whole system was synced perfectly.<p>Whereas now every device seems to think it can set it's own version of "60 Hz". Your GPU's 60Hz is inevitably a bit different from your displays idea of "60Hz", which in turn is a bit different from your web browsers idea of "60Hz", which is again a bit different from the livestream you're watchings version of "60 Hz". At every stage, when one clock is slightly faster, frames are dropped, and at other stages duplicate frames are inserted. End result: You can't watch a film without random occasional jitters.<p>Please, everyone in the AV industry: Design your shit better. We should take away your quartz crystals and force you to have only inaccurate timing devices just so you are forced to properly sync everything!
MPEG-TS is incorporated in many digital TV standards. They will continue to be around for a long time simply because of that, regardless of technical points.
I started using mpeg_ts when I discovered that it streams well, that is, it can start randomly in the middle without much trouble. A few other formats I tried choked under this use case.<p>I don't know what this property is called so I don't really know how to search how well a format can start mid stream. any hints?
Another MPEG-TS alternative used by some projects.<p><a href="https://ieeexplore.ieee.org/document/9828725" rel="nofollow">https://ieeexplore.ieee.org/document/9828725</a><p><a href="https://github.com/agilecontent/efp">https://github.com/agilecontent/efp</a>
MPEG-TS is just amazing.<p>For a web dev, the most notable thing is that every block is the same length.<p>Have gstreamer output to a named pipe. Read from it and send it over websockets. Be sure that every packet or stream starts at a 188 byte boundary.<p>No matter where you start, as long as you're on a 188 byte line, you're good, the decoder knows what's up.<p>You don't have to decode or understand anything, you just need to count bytes.<p>Sub-second latency over LAN WiFi into a regular browser is trivial, even with your server written in pure Python.<p>I'm sure someday something might replace it, but right now it seems like one of those things that Just Works, and it's really nice when stuff actually works.
I am not an expert in this area, but I've worked around its edges, and video has always struck me as one of tech's great HARD problems. It's a really frustrating combination of: meant for human consumption, difficult to characterize algorithmically, realtime, having a distinct future temporal envelope, etc. The problem is precisely that many people want to many different things with video - and depending on what you want to do with it you may prefer an entirely different stack!<p>I almost want to compare it to making good vaccines in the medical world - some of the most beneficial work to all parties, but also some of the least commercially rewarding.
This feels like one of those classic "because it's very simply <i>not bad enough</i> for people to stop using it, given how <i>only a little better</i> the newer alternatives are".
"Error Resilience" / "Clock Recovery"<p>Don't RTMP and probably WebRTC both handle this in ~1-4 second chunks with video segments and a playlist?<p>For non-live content a buffer can be attempted multiple times.<p>Live content, yes that's an issue, but often if it's missed it's too late.