MPEG-2 Transport Streams Are Still the Backbone of Live Video, and MOQ Needs Them
MPEG-2 Transport Streams and MOQ: Yes, MPEG-TS Is Still Relevant Today

New streaming protocols succeed not because they are technically superior, but because they solve real problems while fitting into existing industry workflows. That is why Red5's Paul Gregoire and Synamedia's Gwendal Simon coauthored an IETF draft for packaging MPEG-2 Transport Streams over MOQ. Despite being dismissed as old, MPEG-2 TS underpins contribution feeds, broadcast workflows, satellite distribution, and SRT — the dominant ingest protocol in broadcasting. The draft addresses random access points, alternate bitrate switching, relay processing, multi-program handling, timing, PCR continuity, SCTE-35 signaling, and authorization, ensuring MOQ integrates cleanly into production environments.
One thing I’ve learned over the years building streaming infrastructure is that new video streaming protocols do not succeed just because they are technically better. They succeed when they solve real problems while still fitting into how the industry actually operates.
- Balooga
Graduated from college and day one in my first real job, I was handed a hardcopy of the MPEG-2 transport stream spec and told to read it and come back with questions.
That's how you onboard.
- wmf
The real argument about Transport Stream isn't its age but unnecessary overhead. If backwards compatibility is more important than overhead, fine. But acknowledge that there is a tradeoff.
- korhojoa
I'm hoping this attracts the right crowd.
I've been struggling with getting carplay to show it's alternate screen on my car's cluster display. Everything is fine for the first three seconds or so, then because apple doesn't use a nice annex-b stream (android auto's cluster display works fine), but avcc, shoving it into mpeg-ts requires some work.
Apple's encoder stops sending frames if nothing is happening on the screen, and at least my instrument cluster's h264 decoder loses sync after 3 seconds of no frames being delivered.
I've tried different kinds of filler, null ts packets, P-frames with no changes, etc. The decoder just doesn't want to resume playback when the frames start flowing again.
Any ideas?