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

41–50 of 54 posts

Re: Why does MPEG Transport Stream still exist?

#41

Post by toast0 »

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.

> It shouldn't be used on discs (ahem Blu-ray) or other storage and it shouldn't be used over the Internet.

I thought Blu-Ray switched to program stream, but DVD was transport stream (sounds like I've got things backwards though). Transport stream for optical media isn't that insane though, because while you can seek, seeking isn't great, and if you have a failed read, it's probably better to just move on than to retry that sector a bunch of times. Of course, using transport streams allows for smaller buffers and lower BOM, so there's that too.

Re: Why does MPEG Transport Stream still exist?

#42

Post by izacus »

anonuser123456 wrote: post #40
somat wrote: post #39

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

The term you are looking for is ‘random access point’. This property is more a function of the encoding parameters of the video stream. It just happens that MPEG-TS is typically encoded so as to minimize the reasonable time between RAPs. Also, MPEG-TS streams have sync bytes every 188 bytes, making it trivial to align the bitstream and then find the RAPs. Basically the use case you are describing is just the normal o…

It's also a property of TS being designed for exactly this use-case, which is why it has these sync bytes and mechanisms to allow decoders to randomly access the stream and still get all the necessary data.

Re: Why does MPEG Transport Stream still exist?

#43

Post by pezezin »

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.

If I remember correctly, the 188-byte packets are a result of using ATM AAL-5 frames, each 53-byte frame having 5 bytes of ATM header, 1 byte of AAL-5 framing, and 47 bytes of payload (47x4 = 188).

Re: Why does MPEG Transport Stream still exist?

#44

Post by eternityforest »

MPEG-TS is just amazing.

For a web dev, the most notable thing is that every block is the same length.

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.

No matter where you start, as long as you're on a 188 byte line, you're good, the decoder knows what's up.

You don't have to decode or understand anything, you just need to count bytes.

Sub-second latency over LAN WiFi into a regular browser is trivial, even with your server written in pure Python.

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.

Re: Why does MPEG Transport Stream still exist?

#45

Post by hkwerf »

mjevans wrote: post #36

"Error Resilience" / "Clock Recovery" Don't RTMP and probably WebRTC both handle this in ~1-4 second chunks with video segments and a playlist? For non-live content a buffer can be attempted multiple times. Live content, yes that's an issue, but often if it's missed it's too late.

For clock recovery, it's more about frame-accuracy here. The drift and jitter requirements on the PCRs (Program Clock References, one of the timestamps in the transport stream), stream is limited very strictly on a wide timescale. Here's a nice reference about it: https://download.tek.com/document/25W_14617_1.pdf, see for example Figure 8.

The limits here are surprisingly hard to achieve, both on the multiplexer side and on the decoder side. I've implemented clock recovery for the transport stream products at my company and it has been quite surprising how many multiplexers inject bad PCR data that's outside of the acceptable range.

Re: Why does MPEG Transport Stream still exist?

#46

Post by eternityforest »

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.

I use it for storage because I can stream a recording, with full seeking, while I'm actively capturing it, or I can stream it over a websocket for a little less latency.

Having one thing that works just as well as WebSockets as it does over HLS makes things a lot easier on low performance devices where a format conversion would be a bad thing.

MPEG-TS is like a virtual analog RCA jack, it's easy to understand and work with and manipulate as long as you don't have to touch the encoding or decoding stuff, and lets you do lots of odd applications.

Re: Why does MPEG Transport Stream still exist?

#47

Post by hulitu »

russellbeattie wrote: post #32
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.

The new ATSC 3.0 standard (NextGen TV) in the U.S. allows MPEG-TS, but prefers DASH using an OFDP wrapped UDP stream, which after hardware decoding is consumed just like any other network stream. It's really well done. Digital TV in the U.S. will eventually be like a giant, one-way WiFi signal.

> The new ATSC 3.0 standard (NextGen TV) in the U.S.

Don't worry. After 3 comes 4 and 5. /s

Re: Why does MPEG Transport Stream still exist?

#48

Post by hulitu »

londons_explore wrote: post #33

> able to recover the clock of the source in order to know when to drop or duplicate video frames So this is why I can never watch a whole movie and not have a single dropped frame! 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. Whereas now every device seems to think it ca…

> So this is why I can never watch a whole movie and not have a single dropped frame!

No, it is because bandwidth is expensive. That's why you get a 4k UHD HDR stream at 3MB/s. Your whole stream is calculated based on the few full frames that you receive.

Notice how everybody says: HD up to ...

Down to 0.

Re: Why does MPEG Transport Stream still exist?

#49

Post by alephnil »

anonuser123456 wrote: post #40
somat wrote: post #39

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

The term you are looking for is ‘random access point’. This property is more a function of the encoding parameters of the video stream. It just happens that MPEG-TS is typically encoded so as to minimize the reasonable time between RAPs. Also, MPEG-TS streams have sync bytes every 188 bytes, making it trivial to align the bitstream and then find the RAPs. Basically the use case you are describing is just the normal o…

> This property is more a function of the encoding parameters of the video stream

Not really. Formats like mp4 can't be parsed without reading the container header, that may be at the start or end of the file. Thus you can't read an mp4 by starting in the middle without reading the header and then seek to the middle of the file. This is the case regardless of encoding parameters. With mpeg-ts on the other hand, you can seek to a random place in the middle, and recover the stream on the next Iframe. Not many other file formats allow this.

Re: Why does MPEG Transport Stream still exist?

#50

Post by ta1243 »

akira2501 wrote: post #27
asabil wrote: post #18

Earlier quoted context omitted.

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.

MPEG-TS allows for packaging multiple streams with independent time bases.

For example audio at 48k and video at 90k. The problem with that being that as they wrap around at different times. So video wraps first, then audio wraps later, and this can happen several times over
Post reply on HN