MPEG-TS is used to contain h264 chunks for HLS. MPEG-DASH and the new CMAF standard use fMP4 containers instead. My personal take is that Media over QUIC (MoQ) should support both.
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.
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.
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
Is MPEG-2 still used over h264 for things that would justify this RFC in 2026?
MPEG-TS is used to contain h264 chunks for HLS. MPEG-DASH and the new CMAF standard use fMP4 containers instead. My personal take is that Media over QUIC (MoQ) should support both.
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.
good
This looks like a kludge that should be used as a last resort. Transport Stream is not for the Internet.
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.
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