5 ms·

MPEG-2 Transport Stream Packaging for Media over QUIC Transport

68 points by mondainx 5mo ago

wmf 5mo ago
This looks like a kludge that should be used as a last resort. Transport Stream is not for the Internet.
- dylan604 5mo ago
  Transport stream is specifically meant for unstable connections vs Program streams used for DVDs with a nice steady data stream. Digital cable signals and other signals use transport streams specifically because they can resync if things do get out of sync. But yes, working with TS feels kludgy. I haven't had to deal with them in over a decade, but there was one tool that made it all super easy, MP2TSME, that I hear is no longer available
  - pkulak 5mo ago
    They are still pretty widely use for HLS/DASH streams. You may not be dealing with them, but you're probably watching them.
- heyitsdaad 5mo ago
  The Internet you are referring to is not meant for low latency streaming. This is what it takes make it low latency. MPEGTS is proven stable and ubiquitous. If only it has less overhead.
- lxgr 5mo ago
  Transport Stream is for everything, which includes the Internet.
- iso1631 5mo ago
  I'm been using MPEG2 transport streams over the internet to broadcast programs to millions of people for over 15 years, and of course over private IP networks. I'm almost certain you've seen some of that output
- somat 5mo ago
  Tell that to cable isp's. I don't know if things have changed. but due to the way things fell out when they were trying to transition to internet service on their video lines it ended up being ip encapsulated in mpegts. Something about how all their existing equipment spoke mpegts.
- ranger_danger 5mo ago
  > Transport Stream is not for the Internet. As a rule, strong feelings about issues do not emerge from deep understanding.
yulia_dev_la 5mo ago
[flagged]
- mondainx 5mo ago
  thanks
quapster 5mo ago
[flagged]
Almondsetat 5mo ago
Is MPEG-2 still used over h264 for things that would justify this RFC in 2026?
- koito17 5mo ago
  MPEG-2 TS is a container. H.264 is a coding specification. They are totally different things. One can find MPEG-2 TS in surprising places (see: DOCSIS encapsulating Ethernet frames into TS packets). If I had to guess why MPEG-2 TS, it'd probably be the for the fact it's a well-supported streaming format in both hardware and software. If you tried using QuickTime or MPEG-4 containers, you'd have to rely on hacks like ensuring the moov atom preceeds mdat. Matroska may be worth considering (especially the subset used by WebM to make it stream-friendly and quicker to seek), but no idea how widespread hardware support is for (de)muxing that.
  - dylan604 5mo ago
    Before ProRes, we captured HD content at 100Mbps MPEG2 video with PCM audio wrapped in a 302m stream that were muxed together as an MP2TS wrapper. The 302m made it even more difficult as not all MP2TS tools could do it correctly, and some would not allow for custom Program stream IDs and needed to be remuxed by other tools allow for custom PIDs as a post process. But seeing how many uses people came up with for using MP2TS just shows it's flexibility and resilience.
  - TD-Linux 5mo ago
    Hardware support does not matter for TS, as containers are handled in software. Fast start is irrelevant because MoQ normally uses fragmented MP4, not progressive.
    - lxgr 5mo ago
      Sure, but there are a lot of media applicances that don't really have upgradeable software. I suppose it can be pretty useful to just (un)wrap MoQ and feed the result over a local interface into something that just expects M2TS and vice versa.
  - 5mo ago
mondainx 5mo ago
Try not to confuse container vs codec. M2TS can carry a plethora of content and is very widely used these days, in the streaming world.
- lxgr 5mo ago
  Including IP (over DOCSIS), I believe!
  - vetrom 5mo ago
    I became aware of RFC4259: https://www.rfc-editor.org/rfc/rfc4259 https://www.rfc-editor.org/rfc/rfc4259, but is there literature about its use in the wild? Searching on [rfc4259, nanog] comes up snake eyes for me.
    - lxgr 5mo ago
      DOCSIS would probably not be be specified in RFCs, but see e.g. here: https://account.cablelabs.com/server/alfresco/9b8a9bd8-dea3-483d-988e-7d001f8a7869 https://account.cablelabs.com/server/alfresco/9b8a9bd8-dea3-... I suppose the main reason was compatibility with existing cable headend infrastructure, but I'm also curious to know if there were ever actual TV and DOCSIS data sharing a single physical transponder. Would be a nice way of leveraging spare bandwidth due to variable bit rate video encoding!

68 points by mondainx 5mo ago

wmf 5mo ago

This looks like a kludge that should be used as a last resort. Transport Stream is not for the Internet.

dylan604 5mo ago
Transport stream is specifically meant for unstable connections vs Program streams used for DVDs with a nice steady data stream. Digital cable signals and other signals use transport streams specifically because they can resync if things do get out of sync. But yes, working with TS feels kludgy. I haven't had to deal with them in over a decade, but there was one tool that made it all super easy, MP2TSME, that I hear is no longer available
- pkulak 5mo ago
  They are still pretty widely use for HLS/DASH streams. You may not be dealing with them, but you're probably watching them.
heyitsdaad 5mo ago
The Internet you are referring to is not meant for low latency streaming. This is what it takes make it low latency. MPEGTS is proven stable and ubiquitous. If only it has less overhead.
lxgr 5mo ago
Transport Stream is for everything, which includes the Internet.
iso1631 5mo ago
I'm been using MPEG2 transport streams over the internet to broadcast programs to millions of people for over 15 years, and of course over private IP networks. I'm almost certain you've seen some of that output
somat 5mo ago
Tell that to cable isp's. I don't know if things have changed. but due to the way things fell out when they were trying to transition to internet service on their video lines it ended up being ip encapsulated in mpegts. Something about how all their existing equipment spoke mpegts.
ranger_danger 5mo ago
> Transport Stream is not for the Internet. As a rule, strong feelings about issues do not emerge from deep understanding.

yulia_dev_la 5mo ago

[flagged]

mondainx 5mo ago
thanks

quapster 5mo ago

[flagged]

Almondsetat 5mo ago

Is MPEG-2 still used over h264 for things that would justify this RFC in 2026?

koito17 5mo ago
MPEG-2 TS is a container. H.264 is a coding specification. They are totally different things. One can find MPEG-2 TS in surprising places (see: DOCSIS encapsulating Ethernet frames into TS packets). If I had to guess why MPEG-2 TS, it'd probably be the for the fact it's a well-supported streaming format in both hardware and software. If you tried using QuickTime or MPEG-4 containers, you'd have to rely on hacks like ensuring the moov atom preceeds mdat. Matroska may be worth considering (especially the subset used by WebM to make it stream-friendly and quicker to seek), but no idea how widespread hardware support is for (de)muxing that.
- dylan604 5mo ago
  Before ProRes, we captured HD content at 100Mbps MPEG2 video with PCM audio wrapped in a 302m stream that were muxed together as an MP2TS wrapper. The 302m made it even more difficult as not all MP2TS tools could do it correctly, and some would not allow for custom Program stream IDs and needed to be remuxed by other tools allow for custom PIDs as a post process. But seeing how many uses people came up with for using MP2TS just shows it's flexibility and resilience.
- TD-Linux 5mo ago
  Hardware support does not matter for TS, as containers are handled in software. Fast start is irrelevant because MoQ normally uses fragmented MP4, not progressive.
  - lxgr 5mo ago
    Sure, but there are a lot of media applicances that don't really have upgradeable software. I suppose it can be pretty useful to just (un)wrap MoQ and feed the result over a local interface into something that just expects M2TS and vice versa.
- 5mo ago

mondainx 5mo ago

Try not to confuse container vs codec. M2TS can carry a plethora of content and is very widely used these days, in the streaming world.

lxgr 5mo ago
Including IP (over DOCSIS), I believe!
- vetrom 5mo ago
  I became aware of RFC4259: https://www.rfc-editor.org/rfc/rfc4259 https://www.rfc-editor.org/rfc/rfc4259, but is there literature about its use in the wild? Searching on [rfc4259, nanog] comes up snake eyes for me.
  - lxgr 5mo ago
    DOCSIS would probably not be be specified in RFCs, but see e.g. here: https://account.cablelabs.com/server/alfresco/9b8a9bd8-dea3-483d-988e-7d001f8a7869 https://account.cablelabs.com/server/alfresco/9b8a9bd8-dea3-... I suppose the main reason was compatibility with existing cable headend infrastructure, but I'm also curious to know if there were ever actual TV and DOCSIS data sharing a single physical transponder. Would be a nice way of leveraging spare bandwidth due to variable bit rate video encoding!