This week French satellite specialist UDcast announced an Open Statistical Multiplexing Architecture complete with a white paper pushing variable bit rate TV channels services and just how they are multiplexed together in a DVB-H mobile TV service.
At the same time Tandberg, in the throes of being acquired by Ericsson, has announced its own end to end Mobile TV encoding system, which includes the UDcast IP encapsulators (see separate story).
The Tandberg system includes its new mPlex media processing core professional receivers, the UDCast IPE-10 for DVB-H IPE, time slicing and Forward Error Correction, the ability to create and schedule single frequency networks, whether they are fed by ATM networks or by satellite modulation.
The Tandberg system also enables local content and presumably local advertising, which is another aspect of mobile TV that UDcast focuses on with its low priced local video splicing technology.
The UDcast white paper to our view, falls far short of what a white paper should cover for a mobile TV multiplex and it serves to just explain to those that have never quite understood DVB-H, how the overall package is multiplexed. It has a nice diagram which illuminates the manner in which statistical multiplexing gives bandwidth benefit, anywhere between 25% and 40% depending upon who you listen to, to a DVB-H signal.
But the entire process is perhaps a little more complicated than the UDcast paper is letting on and there are many places where proprietary technique is required.
To encode a TV channel at all the encoder needs to have a target output resolution such as a quarter VGA, which is the most prevalent resolution for broadcast mobile TV. Then it needs to encode using a variable bit rate approach and decide on an optimum or average bit rate as a target or the total bit rate for the cluster of channels collectively. Then a statistical multiplexer needs to take a stab at forcing the multiple TV channels together, making a note of where high speed action requires a greater data rate and where a lower amount of movement in the video, or a lower requirement for sharp edges (for instance a dark scene) means that the total amount of data sent can be far lower.
Not only does the aggregate bandwidth of all the channels come to less than the total available anticipated bandwidth that would be used if a constant bit rate formula was used, but the DVB-H multiplex doesn’t have to deliver them in real time at all. Since the way DVB-H works is in time slicing, with all of the bandwidth available to deliver say 4 seconds of video in about a quarter of a second. This is then stored, buffered and played out on a mobile device.
The very last bits tells the handset when it needs next turn its radio on once again to get the next time slice or burst of the program. So it’s not even necessary to use a constant burst size as long as each channel has enough video to play out before the next slice of data for that channel is required.
So not only is it possible to vary the bit rate in the real time stream, but it is also possible to vary how long each burst is going to be in order to deliver 4 seconds of video. And given that other data, such a EPG data has to be sent periodically over the same multiplex, this can be slowed down or speeded up, to fine tune the total bandwidth used.
We think that eventually this will become an iterative process. There is a variable bit rate stream set up by the encoder, and then it measures it against the other streams that are being encoded both on this encoding module, on others nearby, and potentially on other remote encoders.
The likely outcome may or may not meet the quality requirements and then the encoder can take steps to fix this. For instance some systems use variable GOPs. A GOP stands for a group of pictures and it is the number of frames between the fully descriptive reference frames called I-frames or Intra frames. The I-Frames are compressed bit maps and are very heavy compared to the other frames in a video sequence. There is a threshold calculation when using variable GOPs, which looks ahead at the changes to the video and decides when to put in an I-frame.
Constant GOP sizes are a feature of IPTV, because there’s a constant bit rate for each TV channel in fixed networks. Varying the GOP is something you would only bother with in highly constrained bandwidths. As mobile TV tires to it more and more channels into a given bandwidth, we expect that it will become standard. This give the advantage of when the service is first watched on, or when a channel is changed, each burst might begin life with an I-frame, as might each new scene.
Most subsequent frames are far smaller than the original I-frame because they are made up of sending on the changes from the last frame. The encoder also works out a number of movement prediction strategies and informs the remote device what strategy works best. It then finally only sends data that won’t fit either the reference to the I-frame or the movement prediction. The encoder can tell when suddenly these other frames are going to become ‘heavy’ so that it is worthwhile sending a new I-frame, so that the subsequent data rate can once again fall.
But the encoder, using pre-processing, can calculate ahead of time all of this and should be able to look at all the other channels that are being encoded for the same multiplex and decide if a new I-frame would collide with another channel that also has heavy data requirements at that time. It could then delay the I-frame for a few frames, or send it early, so that the two channels are not forced into high data rates at the same time. This type of co-operation between the elements of an encoder, statistical multiplex and an IP encapsulators is not yet common, but we can see it all coming.
The encryption engine and breaking the channel data in to IP packets at the IP encapsulation engine, also take time, and the more data that is crushed into the multiplex, the more overhead these place on the data (around 4% of the total we understand).
As we said this needs to be iterative. The whole chain of the delivery mechanism (the video needs to be here ahead of time for the encoder to make these decisions), the encoder, the IP Encapsulator, the encryption engine, the statistical multiplexor all need to be part and parcel of a single calculation.
It needs to take in what the outcome will be and look at its policy and priorities for each channel and their quality requirement, come up with the best strategy and deliver the video in as near to real time as it can. At present this whole process is not iterative and yet it already takes between 7 and 10 seconds, so that when TV channels are simulcast, the mobile TV version is running like a permanent replay, slightly behind, for instance, a DVB-T stream.
Finally there is the issue of organizing these multiplexes so that once they are made, they stay made. If you need to break up a multiplex because some of the TV channels are not going to be sent in this region, then that would be hugely inefficient. It is best, and this is what UDcast is also saying in its paper, that regional variations are delivered separately in a multicast of their own.
But the reward for all of this technology, once achieved, is potentially vast. Instead of fitting 25 mobile TV channels into an old analog 8 MHz TV channel, you might get 35 channels. This allows more variation in the bouquets, more advertising revenue, and a higher perceived value for subscriptions.
Given all of this, companies like UDcast, which has developed many of the skills needed, are going to be in short supply and other encoder makers, other than Tandberg, will either have to develop all of these skills themselves to enter the lucrative mobile TV market, or work with the likes of UDcast.
It seems to us that Tandberg, if it doesn’t have these skills in house, should create more of an integrated end to end chain, by acquiring UDcast.
It also seems to us that the very reason for UDcast pushing the idea of standardizing the process of multiplexing mobile TV channels together, is that so instead of it being a small company, swimming with sharks that might gobble it up, it can stay friends with as many of the encoder and DVB-H modulator companies in the field and build its portfolio.
UDcast spoke at the International Wireless Industry Consortium this week talking through all of these plans and the white paper.
UDcast says that the first products supporting the open standard for statistical multiplexing are already available on the market from UDcast and are being tested with various partners in Italy, Germany, France and Finland.