MPEG-4 AVC, also known as H.264, is now ubiquitous. This video specification has been adopted by a slew of standards bodies and implemented in devices ranging from cell phones to set-top-boxes. Between H.264's availability in Apple's QuickTime and the recent adoption of H.264 by Adobe's Flash player, this video codec will soon be available on more devices and networks and be viewable by more consumers than any other codec. Does this mean that content can now be shared between STBs, mobile devices, and the desktop? Almost, but not quite. There are three obstacles to sharing content completely.
First, there are various implementations of video codecs in the product jungle, and not all are the fittest, with a complete or correct implementation. The H.264 specification is complex and it is easy to miss corner cases and create encoders or decoders that are not 100% compliant. With time, these interoperability issues will resolve, but in the interim, service operators are wise to focus on vendors with extensive H.264 experience.
Second, H.264 comes in different profiles – meaning that the encoders may use different sets of encoding tools to compress a video stream. The encoder and decoder have to share (or at least understand) the same profiles. Typically, content encoded in profiles that target mobile devices will be decodable by STBs or software decoders – but understanding profiles and levels is important for ensuring interoperability.
Finally, and most significantly, there are differences in the transport mechanism – the way that the data that define the video stream arrive at the client device. There are, more or less, three different transport mechanisms used for delivering H.264 content to different devices. For IPTV, STBs ingest MPEG-2 transport streams. For 3G mobile phones, the transport mechanism is RTSP/RTP-based. And for the desktop, the transport is either RTSP/RTP or a proprietary variant based on RTSP/RTP. Even though the payload for each of these transport mechanisms may be H.264, devices that consume these different transport mechanism cannot interoperate at all.
MPEG-2 TS is a transport mechanism in which one stream carries multiple, multiplexed data streams. Audio (which may contain multiple channels and languages) is mixed with video, ancillary data (such as closed captioning or teletext) and other data describing the streams. MPEG-2 TS streams have been widely used in digital TV and hence have found acceptance for IPTV deployments as well, even though they are somewhat less efficient and less error resilient than RTSP/RTP streams.
When streaming with RTSP/RTP transport, the RTSP protocol is used to negotiate a connection between a server and the client device, and this is followed by separate RTP streams for each of the services required: audio, video, or other types of services. This transport mechanism is adopted by 3GPP for use in mobile video, and it is also the transport protocol supported by Apple's QuickTime for internet video applications.
Lastly, Adobe's Flash has an RTSP/RTP variant called RTMP for streaming video to the Flash player. This streaming protocol does not currently support H.264, but Adobe has announce future support soon, and given Flash's prevalence on the desktop, it will be a relevant protocol for potential streaming video on the Internet.
What doest all this mean for service operators? It means that convergent head-ends which target multiple networks and multiple devices should be based on equipment and on vendors that have products and experience with multiple delivery mechanisms.
