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

51–54 of 54 posts

Re: Why does MPEG Transport Stream still exist?

#51

Post by drmpeg »

hkwerf wrote: post #45
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 sid…

Writing a T-STD compliant TS multiplexer is not trivial. When I was at LSI Logic, I spent many hours perfecting the TS multiplexer used on the MPEG-2 encoder in the Motorola DCT-6412 P3 STB.

Here's a short clip that's T-STD compliant with about 29 ns of PCR jitter.

https://www.w6rz.net/advatsc3.ts

BTW, last time I checked, the TS muxer in FFmpeg is horribly T-STD non-compliant.

Re: Why does MPEG Transport Stream still exist?

#52

Post by [deleted] »

1827163 wrote: post #22
drmpeg wrote: post #15

Earlier quoted context omitted.

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.

And in those early days many cable providers didn't even implement the Baseline Privacy Interface, so you could sniff the entire neighborhood's downstream traffic with a modified modem or possibly even a DVB-C capable TV card. There was literally a register bit in the cable modem MAC to enable promiscuous mode, and you could just set it: https://pastebin.com/18702Ziq Sadly the Broadcom modem hardware I used to experi…

[deleted]

Re: Why does MPEG Transport Stream still exist?

#53

Post by lxgr »

hulitu wrote: post #48
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.

A low bit rate normally does not cause dropped frames (unless it's so low that not even the required amount of I-frames can be encoded, but that would be a pretty extreme mismatch of resolution and bitrate).

Re: Why does MPEG Transport Stream still exist?

#54

Post by kuschku »

alephnil wrote: post #49
anonuser123456 wrote: post #40

Earlier quoted context omitted.

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

Of course you can start an mp4 at an arbitrary point, that's what fragmented mp4 is for :)

It's just lots of independent separate mp4 files concatenated into a single file.

Post reply on HN