Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does MPEG Transport Stream still exist?

obe.tv

Post reply on HN
Print view View original

11–20 of 54 posts

Re: Why does MPEG Transport Stream still exist?

#11

Post by kierank »

derf_ wrote: post #6
Sean-Der wrote: post #4

This 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…

The RFC does not mandate that the RTCP timestamp (which you need to handle wraparound if you join a stream halfway through) needs to be the same as the video/audio clock.

In practice this clock is generated via the PC clock so it isn't the same clock at all: https://chromium.googlesource.com/external/webrtc/+/lkgr/mod...

RTCP SRs are sent quite rarely (defaulting to 1s for video, 5s for audio) so quite poor for precise clock recovery required in professional applications.

Probably practical implementations just use buffer fullness to drive their resampler.

Re: Why does MPEG Transport Stream still exist?

#12

Post by tonymillion »

The simple answer:

MPEG-TS still exists because it’s still the best media container/transport system in existence.

It was designed and has evolved over a long time based on solid foundations by very smart people in the industry, across multiple institutions and professions.

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…

Case in point: MPEG-TS has scaled from DVD across BluRay (and DVD-HD) is the backbone of both satellite and terrestrial digital broadcasting.

Re: Why does MPEG Transport Stream still exist?

#14

Post by wmf »

numpad0 wrote: post #5

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.

Right, but transport stream should only be used in broadcasting. It shouldn't be used on discs (ahem Blu-ray) or other storage and it shouldn't be used over the Internet. Program stream is usually a better choice.

Re: Why does MPEG Transport Stream still exist?

#15

Post by drmpeg »

numpad0 wrote: post #5

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.

Fun fact. DOCSIS 1.0 through 3.0 cable Internet uses MPEG-2 Transport Streams to deliver the IP packets. It has to, because the QAM specification (ANSI/SCTE 07) is built around 188 byte TS packets.

Re: Why does MPEG Transport Stream still exist?

#17

Post by keithwinstein »

tonymillion wrote: post #12

The simple answer: MPEG-TS still exists because it’s still the best media container/transport system in existence. It was designed and has evolved over a long time based on solid foundations by very smart people in the industry, across multiple institutions and professions. 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…

(FWIW, DVDs use MPEG-2 program streams, not transport streams. Both MPEG-2 part 1 systems streams, just different kinds.)

Re: Why does MPEG Transport Stream still exist?

#18

Post by asabil »

kierank wrote: post #9
Sean-Der wrote: post #4

This 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 rela…

Each RTP packet has a 32bit timestamp, and a 32 bit SSRC. Each "sender" in an RTP session must use the same SSRC, this is how synchronisation between audio and video streams from the same sender (lip-sync) is achieved.

The timestamps have a resolution defined by the clock rate communicated externally through a signalling channel.

Re: Why does MPEG Transport Stream still exist?

#19

Post by lxgr »

wmf wrote: post #14
numpad0 wrote: post #5

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.

Right, but transport stream should only be used in broadcasting. It shouldn't be used on discs (ahem Blu-ray) or other storage and it shouldn't be used over the Internet. Program stream is usually a better choice.

What about bridging broadcast media to IP or vice versa?

One of the advantages of MPEG-TS is that it’s dead simple to map it to RTP or even plain UDP and back even with packet loss and data errors.

Re: Why does MPEG Transport Stream still exist?

#20

Post by lxgr »

drmpeg wrote: post #15
numpad0 wrote: post #5

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.

Fun fact. DOCSIS 1.0 through 3.0 cable Internet uses MPEG-2 Transport Streams to deliver the IP packets. It has to, because the QAM specification (ANSI/SCTE 07) is built around 188 byte TS packets.

I’ve always wondered if that was done to allow mixed video and DOCSIS channels, shared hardware on either end, or just to ensure that TVs and STBs can quickly and safely skip DOCSIS channels that they won’t be able to decode anyway.
Post reply on HN