Thursday, January 26, 2012

For or against Adaptive Bit Rate? part IV: Alternatives

As we have seen  here,  hereand  hereAdaptive Bit Rate (ABR) is a great technology for streaming video contents in lossy networks but it is handicapped by many challenges that are hindering its success and threatening its implementation in mobile networks.

Having spoken to many vendors in the space, here are two techniques that I have seen deployed to try and  emulate ABR benefits in mobile networks, while reducing dependencies on some of the obstacles mentioned.

DBRA (Dynamic Bit Rate Adaptation)

DBRA is a technique that relies on real-time transcoding or transrating to follow network variations. It is implemented in the core network, on a video optimization engine. When the video connection is initialized, a DBRA-capable network uses TCP feedback and metrics to understand whether the connection is improving or worsening. The platform cannot detect congestion in itself but deduces it from the state of the connection. jitter, packet loss ratio, TCP window, device buffer size and filling rate are all parameters that are fed into proprietary heuristic algorithms. These algorithms in turn instruct the encoder frame by frame, bit by bit to encode the video bit rate to the available delivery bit rate.

In the above diagram, you see a theoretically perfect implementation of DBRA, where the platform follows network variations and "sticks" to the up and downs of the transmission rate.
The difference between each implementation depends largely on how aggressive or lax the algorithm is in predicting network variations. Being overly aggressive leads to decreased user experience as the encoder decreases the encoding faster than the decrease in available bandwidth while a lax implementation results in equal or worse user experience if the platform does not reduce the encoding fast enough to deplete the buffer, resulting in buffering or interruption of the playback.

Theoretically, this is a superior implementation to adaptive streaming, as it does not rely on content providers to format, maintain streams and chunks that might not be fully optimized for all network conditions (wifi, 3G, EDGE, HSPA, LTE…) and devices. It also guarantees an "optimal" user experience, always providing the best encoding the network can deliver at any point in time.
On the flip side, the technique is CAPEX expensive as real time encoding is CPU intensive.

Vendors such as Mobixell, Ortiva and others are proponents of this implementation.

Network-controlled Adaptive Streaming:

Unlike in ABR, where the device selects the appropriate bandwidth based on network availability, some vendors perform online transcoding to simulate an adaptive streaming scenario. The server feeds to the client a series of feeds whose quality vary throughout the connection and fakes the network feedback readout  to ensure a deterministic quality and size. The correct bitrate is computed from TCP connection status. More clearly, the network operator can decide at what bit rates a streaming connection should take place, spoofing the device by feeding it a manifest that does not correspond to the available delivery bit rate but to the bit rate selected by the carrier. 

This technique uses ABR as a Trojan horse. It relies on ABR for the delivery and flow control, but the device looses the capacity to detect network capacity, putting the carrier in control of the bandwidth it wants dedicated to the streaming operation.

These alternative implementations give the carrier more control over the streaming delivery on their networks. Conversely, handsets and content providers relinquish he capacity to control their user experience. The question is whether they really had control in the first place, as mobile networks are so congested that the resulting user experience is in most cases below expectations. In any case, I believe that a more meaningful coordination and collaboration between content providers, carriers and handset manufacturers is necessary to put the control of the user experience where it belongs: in the consumer's hands.

1 comment:

Aldo said...

It sounds like these alternatives are viable only for a unicast stream, with a limited number of simultaneous users, since each user needs its own optimized encoder or transcoder at the server end. Multicast and broadcast wouldn't be possible, as the server can't accommodate the individual requirements of each client. -agc