Why does MPEG Transport Stream still exist?
1–10 of 54 posts
Re: Why does MPEG Transport Stream still exist?
#2I 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!
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.
Re: Why does MPEG Transport Stream still exist?
#3[deleted]
Re: Why does MPEG Transport Stream still exist?
#4This article is incorrect about WebRTC. I don’t know about other protocols and what they offer.
* Clock Recovery
I have had no problems with measuring NTP drift. As the clocks change I would measure.
* Common Clock for Audio and Video
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.
* Defined latency
WebRTC provides playoutDelay. https://webrtc.googlesource.com/src/+/main/docs/native-code/.... This allows the sender to add delay to give a better experience.
* Legacy transport
You can transport anything you want via RTP or DataChannels. Maybe I am missing something with this one?
Re: Why does MPEG Transport Stream still exist?
#5MPEG-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.
Re: Why does MPEG Transport Stream still exist?
#6This article is incorrect about WebRTC. I don’t know about other protocols and what they offer. * Clock Recovery I have had no problems with measuring NTP drift. As the clocks change I would measure. * Common Clock for Audio and Video 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.…
> I have had no problems with measuring NTP drift.
Yeah, their claim is just weird. RTP does not impose an accuracy requirement on its timestamps (despite the name "NTP timestamp" in the Sender Reports, they are not actually expected to be synchronized with an NTP source), but I am skeptical such requirements would be met in practice if they did exist. The author only talks about video, but audio is a much bigger problem: if you do not send the right number of samples to the sound card at the right rate, you are going to get annoying clicks and pops, and "dropping or duplicating" audio frames will only cause more problems. You do not need to send media for a day to have these issues. Oscillators are bad enough they show up in minutes, and WebRTC obviously has strategies for dealing with them.
> If you want all your tracks to be synced you need to mark them as one MediaStream.
More specifically, the underlying mechanism of giving tracks that need to be synchronized the same CNAME has existed in RTP since the original RFC 1889 from the year 1996. The timestamp wrapping does require some care to get right, but is basically a non-issue.
That said, a lot of WebRTC applications will not ask for synchronization because it necessarily introduces latency, and for interactive use cases you are often better served by sacrificing exact sync for lower latency (as long as latency is low enough, sync is never going to get too bad, anyway). But that is very different from saying the standards do not support it if you want it.
Re: Why does MPEG Transport Stream still exist?
#7I 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…
All those patents don't help either (in medicine it's more debatable)
Re: Why does MPEG Transport Stream still exist?
#8This article is incorrect about WebRTC. I don’t know about other protocols and what they offer. * Clock Recovery I have had no problems with measuring NTP drift. As the clocks change I would measure. * Common Clock for Audio and Video 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.…
> I have had no problems with measuring NTP drift. Yeah, their claim is just weird. RTP does not impose an accuracy requirement on its timestamps (despite the name "NTP timestamp" in the Sender Reports, they are not actually expected to be synchronized with an NTP source), but I am skeptical such requirements would be met in practice if they did exist. The author only talks about video, but audio is a much bigger pro…
Don't get myopic here - the timing constraints are critical for systems like DVB-T/C/S (and whatever the US equivalent is), not as much web. The things you're talking about might be dismissable when you're sending things from your blog app, but TS is primarily used in broadcasting.
The DVB machines I've worked with were very sensitive to any kind of jitter and clock skew.
Re: Why does MPEG Transport Stream still exist?
#9This article is incorrect about WebRTC. I don’t know about other protocols and what they offer. * Clock Recovery I have had no problems with measuring NTP drift. As the clocks change I would measure. * Common Clock for Audio and Video 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.…
Author here:
>I have had no problems with measuring NTP drift. As the clocks change I would measure.
Did you read the article? NTP is not the same as the video/audio clock which is what you need to care about. I have to now take a drink even though it's 5am here in Singapore.
> Common Clock for Audio and Video
No idea what sequence numbers have to do with clocks here. Maybe you mean a mapping of absolute time to relative time in RTCP? If the RTCP SR value for absolute time is using NTP (or any other wrong clock as it's not mandated to match audio/video clock), then it's by definition impossible to know how to sync audio and video after several wraparounds of each RTP timestamp.
> WebRTC provides playoutDelay.
This is not the same as a defined, video frame or audio sample accurate delay (ten milliseconds as a unit...) to allow for variations in frame size to maximise quality. It also appears to mix up network delays vs VBV delays. They are separate delays and are handled at different layers of the stack.
> You can transport anything you want via RTP or DataChannels
None of this is standardised and therefore requires control of both ends. Also high end applications need Uncompressed Audio and for the above RTP timestamp reasons this can't be precisely synced with video.
Re: Why does MPEG Transport Stream still exist?
#10This article is incorrect about WebRTC. I don’t know about other protocols and what they offer. * Clock Recovery I have had no problems with measuring NTP drift. As the clocks change I would measure. * Common Clock for Audio and Video 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.…
Regarding clock, ideally you'd want to be able to genlock them.
The goal is to ensure that all input sourced send their video frames at the exact same point in time, and that each audio device also samples at the exact same points in time.
In the past that was even more important, as you'd want to make sure the scanline of CRTs in the studio and of the camera were perfectly synced.