While the current hype surrounds HTTP delivery as being less costly—and by assumption, more efficient—than traditional streaming, the question is one that the industry should consider, in light of the advances in both HTTP Live Streaming (HLS) and fragmented MPEG-4 (fMP4) that have been announced recently.
The more mature (or long-in-the-tooth, depending on your perspective) technology on the market is MPEG-2 Transport Stream (M2TS), which makes up the packaging protocol for content delivery in HLS.
HLS has gained huge popularity, in no small part because it’s the only way to stream to the iOS devices. Let me be the first to say that MPEG-2 Transport Stream is a tried-and-true technology that has been used extensively for broadcast transmission over the past decade. Yet its age makes it a bit of a millstone that seems to be holding back advances in the over-all HTTP streaming marketplace.
Because M2TS is a technology that has been in use for more than 10 years, based on a specification that was around almost 5 years prior, it uses the now-outdated ATM packet delivery protocol.
ATM was used in the days before pure IP networks and required 4-bytes header information in each 188-byte packet. While 4 bytes doesn’t sound like much, consider that an hourlong video stream at a single bandwidth of 1.5 megabits per second could require more than one ATM packet per second, with almost 32Kbps being taken up by the header information.
At the end of the hour, a total of 115,000 kilobits of header information would be passed. The majority of content today is sent across either pure IP networks or Ethernet metro networks, and these newer network protocols have to work to unpackage the ATM cells, adding a bit of processing time to the router in addition to the significant overhead noted above.
M2TS works great for a variety of solutions for which it was originally intended, such as simultaneously broadcasting a number of cable channels, each with either one or multiple channels of alternate audio. To properly synchronize the video stream (known as an elementary stream) with the one or multiple audio streams, a process known as multiplexing (or muxing) was employed. An example of muxing would be a single video stream that could be viewed with either English or Spanish audio: All three streams—one video and two audio—are sent at the same time, and the television or set-top box chooses between the audio channels to decode the one most appropriate to the viewer.
The problem with extrapolating M2TS into the world of streaming is this: If it makes little sense to have all the additional overhead of 4 bytes per ATM packet, it makes no sense at all to send multiple audio channels to a single streaming viewer.
At any given time, the viewer is only going to choose one audio stream to listen to, meaning that a selection within the video playback application of Spanish could trigger a request for a Spanish audio stream, while a later request for English audio could signal the Spanish audio stream to end and the English audio stream to begin. Without the need to multiplex multiple elementary audio streams, the benefit of MPEG-2 Transport Stream rapidly disappears.
This article first ran in the October/November 2011 issue of Streaming Media under the title, "No Country for Old Technologies?"
Add to this the fact that HLS extends M2TS delivery functionality beyond what is typically carried in an M2TS payload—think DRM or encryption—and it’s easy to see that HLS is not your father’s MPEG-2 Transport Stream.
If broadcasters are going to have to rebuild their MPEG-2 Transport Stream solutions to accommodate the extensions to M2TS that the HLS spec requires, isn’t it time to start looking for a better-fitting solution, rather than relying on old technology that was created years before the tablet devices the streams are being delivered to?