For or against Adaptive Bit Rate? part III: Why isn't ABR more successful?

So why isn't ABR more successful? As we have seen here and here, there are many pros for the technology. It is a simple, efficient means to reduce the load on networks, while optimizing the quality of experience and reducing costs.

Lets review the problems experienced by ABR that hinder its penetration in the market.

1. Interoperability
Ostensibly, having three giants such as Apple, Adobe and Microsoft each pushing their version of the implementation leads to obvious issues. First, the implementations by the three vendors are not interoperable. That's one of the reason why your iPad wont play flash videos.Not only the encoding of the file is different (fMP4 vs. multiplexed), but the protocol (MPEG2TS vs. HTTP progressive download) and even the manifest are proprietary.This leads to a market fragmentation that forces content providers to choose their camp or implement all technologies, which drives up the cost of maintenance and operation proportionally.MPEG DASH, a new initiative aimed at rationalizing ABR use across the different platforms was just approved last month. The idea is that all HTTP based ABR technologies will converge towards a single format, protocol and manifest.

2. Economics
Apple, Adobe and Microsoft seek to control the content owner and production by enforcing their own formats and encoding. I don't see them converge for the sake of coopetition in the short term. A good example is Google's foray into WebM and its ambitions for YouTube.

4. Content owners' knowledge of mobile networks
Adaptive bit rate puts the onus on content owners to decide which flavour of the technology they want to implement, together with the range of quality they want to enable. In last week's example, we have seen how 1 file can translate into 18 versions and thousand of fragments to manage.Obviously, not every content provider is going to go the costly route of transcoding and managing 18 versions of the same content, particularly if this content is user-generated or free to air. This leaves the content provider with the difficult situation to select how many versions of the content and how many quality levels to be supported.
As we have seen over the last year, the market changes at a very rapid pace in term of which vendors are dominant in smartphone and tablets. It is a headache for a content provider to foresee which devices will access their content. This is compounded by the fact that most content providers have no idea of what the effective delivery bit rates can be for EDGE, UMTS, HSPA, HSPA +, LTE In this situation, the available encoding rate can be inappropriate for the delivery capacity.

In the example above, although the content is delivered through ABR, the content playback will be impacted as the delivery bit rate crosses the threshold of the lowest available encoding bit rate. This results in a bad user experience, ranging from buffering to interruption of the video playback.

5. Tablet and smartphone manufacturers knowledge of mobile networks
Obviously, delegating the selection of the quality of the content to the device is a smart move. Since the content is played on the device, this is where there is the clearest understanding of instantaneous network capacity or congestion. Unfortunately, certain handset vendors, particularly those coming from the consumer electronics world do not have enough experience in wireless IP for efficient video delivery. Some devices for instance will go and grab the highest capacity available on the network, irrespective of the encoding of the video requested. So, for instance if the capacity at connection is 1Mbps and the video is encoded at 500kbps, it will be downloaded at twice its rate. That is not a problem when the network is available, but as congestion creeps in, this behaviour snowballs and compounds congestion in embattled networks.

As we can see, there are  still many obstacles to overcome for ABR to be a successful mass market implementation. My next post will show what alternatives exist to ABR in mobile networks for efficient video delivery.

For or against Adaptive Bit Rate? part I: what is ABR?

Adaptive Bit Rate streaming (ABR) was invented to enable content providers to provide video streaming services in environment in which bandwidth would fluctuate. The benefit is clear, as a connection capacity changes over time, the video carried over that connection can vary its bit rate, and therefore its size to adapt to the network conditions.The player or client and the server exchange discrete information on the control plane throughout the transmission, whereby the server exposes the available bit rates for the video being streamed and the client selects the appropriate version, based on its reading of the current connection condition.

The technology is fundamental to help accommodate the growth of online video delivery over unmanaged (OTT) and wireless networks.
The implementation is as follow: a video file is encoded into different streams, at different bit rates. The player can "jump" from one stream to the other, as the condition of the transmission degrades or improves. A manifest document is exchanged between the server and the player at the establishment of the connection for the player to understand the list of versions and bit rates available for delivery.

Unfortunately, the main content delivery technology vendors then started to diverge from the standard implementation to differentiate and control better the user experience and the content provider community. We have reviewed some of these vendor strategies here. Below are the main implementations:

• Apple HTTP Adaptive (Live) streaming (HLS) for iPhone and iPad: This version is implemented over HTTP and MPEG2 TS. It uses a proprietary manifest called m3u8. Apple creates different versions of the same streams (2 to 6, usually) and  breaks down the stream into little “chunks” to facilitate the client jumping from one stream to the other. This results in thousands of chunks for each stream, identified through timecode.Unfortunately, the content provider has to deal with the pain of managing thousands of fragments for each video stream. A costly implementation.
• Microsoft IIS Smooth Streaming (Silverlight Windows phone 7): Microsoft has implemented fragmented MP4 (fMP4), to enable a stream to be separated in discrete fragments, again, to allow the player to jump from one fragment to the other as conditions change.  Microsoft uses AAC for audio and AVC/H264 for video compression. The implementation allows to group each video and audio stream, with all its fragments in a single file,  providing a more cost effective solution than Apple's.
• Adobe HTTP Dynamic Streaming (HDS) for Flash: Adobe uses a proprietary format called F4F to allow delivery of flash videos over RTMP and HTTP. The Flash Media Server creates multiple streams, at different bit rate but also different quality levels.  Streams are full lengths (duration of video).

None of the implementations above are inter-operable, from a manifest or from a file perspective, which means that a content provider with one 1080p HD video could see himself creating one version for each player, multiplied by the number of streams to accommodate the bandwidth variation, multiplied by the number of segments, chunks or file for each version... As illustrated above, a simple video can result in 18 versions and thousand of fragments to manage. This is the reason why only 4 to 6% of current videos are transmitted using ABR. The rest of the traffic uses good old progressive download, with no capacity to adapt to changes in bandwidth, which explains in turn why wireless network operators (over 60 of them) have elected to implement video optimization systems in their networks. We will look, in my next posts, at the pros and cons of ABR and the complementary and competing technologies to achieve the same goals.

Find part II of this post here.

Need an IT manager for my connected home!

I am not really an early adopter. I tend to integrate new products and technologies when my needs change.
Until recently, my electronic devices were dumb and mute, just performing what I wanted to, either working or not.

In this new era of hyper connected homes though, everything becomes exponentially more complex as you add more connected devices. Since I have started my business, I had also to use cloud-based apps and services to expand my brick-and-mortar tools.
Now, with two desktops, a laptop, a tablet, two smartphones, a connected PVR, a PS3 and countless accounts and services from Dropbox, Youtube, Netflix, Google apps, Tweeter, Blogger... it does not take much to see how how these devices, interacting with all these apps and data points can quickly start conflicting with each other.
Especially when you layer that these devices communicate over LAN, Wifi, Bluetooth, RF, IR...
Add as well surveillance camera and energy management modules in the future and complex becomes complicated.

UPnP (Universal Plug and Play) and DLNA (Digital Living Network Alliance) usually do a good job of device discovery. Service and content discovery and priority setting is where it starts to get tricky.
Here are a few of the problems I had to face or am still facing in this hyper connected world.

Authentication and handover:
I use Rogers as a service provider for one of my smartphones. I use their self-help app to manage my bill, my subscription and travel packages. One of the things that is truly a problem is that it works only on a cellular network. Most of the times I need to use it is when I am travelling to add or remove a travel pack for voice, data or text. Because of the expensive roaming data rates, it does not make sense to connect while roaming just to enable a feature that saves me the roaming costs. Obviously, Rogers has not enabled Wifi - cellular authentication and credentials handover.

Authorization and software version control:
I am a Bell subscriber for TV and internet at home. I was excited when I received an email showing off Bell's new mobile TV and companion screen apps for my iPhone / iPad. I was less excited when my iPhone, on rogers network could not use Bell's content, even though I am a Bell customer. Too bad, but I thought at least I could use the PVR remote control with my iPad on Bell's network. Does not work either, because I would have to upgrade my PVR. A PVR, I am renting from Bell. You would think it would be possible for them to know what PVR I am using and therefore allow me to re flash the software to avail of new capabilities or try to up sell me to the latest new PVR and features...

Credentials management
At some point, security relents before complexity. When you want to run a secure network across several interfaces and devices, managing credentials with associated permissions becomes tricky. You have to find a way to have credentials that can easily be shared, remaining secure while managing what device has access to what dataset under which conditions.

Connectivity, content discovery  and sharing:
Inevitably, users buy new devices and add up capabilities along the way. The flip side of that coin, though is that it makes for a very heterogeneous environment. When you start having several devices with similar capabilities or overlaps, you want them to function with each other seamlessly. For instance, my old desktop running XP cannot easily join the workgroup of my new desktop and laptop running windows 7.
There are solutions, but none of them straightforward enough for a regular user. A last example is the fact that my laptop, my iPad, my iPhone, my PVR, my 2 desktops and my PS3 to some extend all act as media servers. They all have local content and they all access content from the cloud, the internet or local content stored in other devices. Again, I haven't found a solution yet that would allow me to manage and share content across devices with clear permission management. Additionally, there is no search or recommendation engine that would allow me to perform meta search across 1) my local content on several devices 2) the internet and OTT content providers and apps I am using 3) the electronic programming guide of my set top box and present me a choice like: do you want to watch boardwalk empire Sunday at 9 pm on HBO, now on HBO Go, buy the entire season on Amazon or play the episodes from my PVR or media servers.

Compatibility:
Too often, i have to transcode videos or change content format to ensure that I can see them on all my screens. This leads to multiple versions of the same content, with associated discoverability and version control issues. Another example is around contact management. It is incredible that Apple still does not get contact management right. If you enable iCloud and have your contacts synchronized with anything that is not apple (Google contacts or linked in) you end up with endless duplicates contacts with no hope to merge and delete without adding on new expensive apps.

Control and management:
It strikes me that with that many connected devices and apps, I have not found yet a single dashboard giving me visibility, control and management of all my devices, allowing me to allocate bandwidth, and permissions for sharing data and content across platforms.

I think at the end of the day, this field is still emerging and while it is possible to have a good implementation when purchasing a solution from scratch from a single vendor or service provider, assembling a solution organically as you add new devices is likely to have you spend hours deciphering DNS and DHCP configurations. I think what is needed in the short term is a gateway platform, acting as middle-ware, indexing and aggregating devices and content, providing a clear dashboard for permissions management and authorization. That gateway could be the set-top-box if it is powerful enough. It would give back to MSO the control they are loosing to OTT if they are willing to integrate and provide a cohesive environment.