Showing posts with label OTT TV. Show all posts
Showing posts with label OTT TV. Show all posts
Approaches to Building a VOD Service from Scratch
If you’re thinking about building a VOD service and you don’t have to deal with legacy, this is how you do it.
Standards-Based, Premium Content for the Modern Web
These days, a person is just as likely to be watching a movie on their
laptop, tablet, or mobile phone, as they are to be sitting in front of a
television. Cable operators are eager to provide premium video content
to these types of devices but there are high costs involved in
supporting the wide array of devices owned by their customers.
A
multitude of technological obstacles stand in the way of delivering a
secure, high-quality, reliable viewing experience to the small-screen.
This four-part blog series describes an open, standards-based approach
to providing premium, adaptive bitrate, audio/video content in HTML and
how open source software can assist in the evaluation and deployment of
these technologies.
By Greg Rutz, Lead Architect, CableLabs
HTML5 Video in Safari on OS X Yosemite
We're excited to announce that Netflix streaming in HTML5 video is now available in Safari on OS X Yosemite! We've been working closely with Apple to implement the Premium Video Extensions in Safari, which allow playback of premium video content in the browser without the use of plugins.
If you're in Apple's Mac Developer Program, or soon the OS X Beta Program, you can install the beta version of OS X Yosemite. With the OS X Yosemite Beta on a modern Mac, you can visit Netflix.com today in Safari and watch your favorite movies and TV shows using HTML5 video without the need to install any plugins.
We're especially excited that Apple implemented the Media Source Extensions (MSE) using their highly optimized video pipeline on OS X. This lets you watch Netflix in buttery smooth 1080p without hogging your CPU or draining your battery. In fact, this allows you to get up to 2 hours longer battery life on a MacBook Air streaming Netflix in 1080p - that’s enough time for one more movie!
Apple also implemented the Encrypted Media Extensions (EME) which provides the content protection needed for premium video services like Netflix.
Finally, Apple implemented the Web Cryptography API (WebCrypto) in Safari, which allows us to encrypt and decrypt communication between our JavaScript application and the Netflix servers.
The Premium Video Extensions do away with the need for proprietary plugin technologies for streaming video. In addition to Safari on OS X Yosemite, plugin-free playback is also available in IE 11 on Windows 8.1, and we look forward to a time when these APIs are available on all browsers.
Congratulations to the Apple team for advancing premium video on the web with Yosemite! We’re looking forward to the Yosemite launch this Fall.
By Anthony Park and Mark Watson, Netflix Tech Blog
Netflix’s Many-Pronged Plan to Eliminate Video Playback Problems
For all of Netflix’s complaints about Internet service providers harming video performance, one of the company’s top technology experts is confident that the streaming company can solve most of its customers’ problems.
David Fullagar, Netflix’s director of content delivery architecture, spoke about the company’s plans Monday at the Content Delivery Summit in New York. He described the hardware Netflix uses in its Open Connect content delivery network (CDN), noting that the company has a technological advantage over traditional CDNs because it’s always delivering content to devices running Netflix’s own software rather than using a hodgepodge of products built by other companies.
The best-known parts of Open Connect are probably the storage boxes that Internet service providers can take into their own networks to bring content closer to consumers. ISPs can also peer with Netflix, exchanging traffic directly without hosting Netflix equipment. But these aren’t the only ways Netflix’s Open Connect technology can deliver good quality.
Netflix used to use third-party CDNs such as Akamai, but it has moved most of its traffic over to Open Connect in the past couple of years. Outside the US, 100 percent of Netflix traffic is distributed using Open Connect equipment. The percentage is in the “high 90s” in the US, with plans to hit 100 percent this summer. Even if the storage boxes aren’t inside an ISP’s network, they’re not too far away. They could even be in the same data centers, the Internet exchange points where Netflix transit providers connect to ISPs.
Fullagar was asked by an audience member how Netflix works with ISPs who offer competing products. “From a quality point of view we don’t need to be that close to the end user for the sort of video we serve,” Fullagar said. “Having extremely low latency is nice” because it allows videos to start playing faster. However, “what we’re most interested in is a good, uncongested link, and that doesn’t necessarily have to be very low latency.”
Netflix’s peering with ISPs has been controversial because some of the Internet providers have demanded payment in exchange for accepting Netflix traffic. Netflix gave in to Verizon and Comcast, agreeing to pay both companies, but it has claimed that the Federal Communications Commission should force the ISPs to provide free peering. Netflix has sent its traffic through congested links when its business disputes have gone unresolved, deteriorating quality despite the other steps Netflix takes to improve it. (Comcast and analyst Dan Rayburn accused Netflix of purposely sending traffic through congested links.)
When asked how much Netflix can affect streaming performance given that it controls the server end of the connection as well as the user’s software, Fullagar said, “I think we’re on the tip of the iceberg of being able to do quite a lot there.” Netflix’s access to information about each customer’s device and Internet connection will fuel some as-yet-unrevealed strategies for improving quality, he said.
“We have extra information beyond just, hey this is someone wanting this file," he said. "At connection time we know the sort of client they are, whether it’s a Wii or a PS4 or a streaming stick. We know the network they’re on, we know a bunch of historical information about latency and quality of service we’ve had to those networks. We know whether they’re connected on a device that’s wired or wireless. There’s a bunch of hints that we have there.”
The company has started some “experiments that are working out really well, and in the future we’ll talk more about that.”
Netflix itself has equipment at about 20 Internet exchange points in North America and Europe and has "tens if not hundreds of embedded caches in ISP networks," Fullagar said.
The Network Team
Netflix’s Open Connect division has about 40 people, Fullagar said. About 20 are software engineers who either build software for Netflix servers or work on the company's management software, which runs on Amazon’s cloud network and performs functions such as load balancing. Another 10 Open Connect employees are network architects, and another 10 are in operations.
Netflix stores video on two types of boxes that it designed, one that’s heavy on HDDs and another that’s all SSDs. Netflix built them in part because it couldn’t find the right mix of compute and storage capabilities in products from hardware vendors.
The HDD unit is a 4U-sized chassis that holds 216TB on 36 drives of 6TB each. It has 64GB RAM, a 10 Gigabit NIC, and some SSD for frequently accessed content.
The smaller, 1U, SSD-only unit contains 14 drives of a terabyte each, 256GB of RAM and a 40 Gigabit NIC. About 75 percent of the cost of both the HDD and SSD boxes is taken up by storage. Each unit uses Intel CPUs.
Netflix refreshes hardware annually to improve performance. At its biggest locations, Netflix keeps multiple copies of its entire video library in case of failure. That’s more than a petabyte of video files for its North American catalog.
The company relies heavily on open source software, including FreeBSD and the Nginx Web server, as well as several management applications the company wrote itself.
Netflix distributes multiple terabits per second and accounts for an astonishing one-third of North American Internet traffic at peak times, i.e. the traditional TV “prime time” each evening. During off-peak hours in the middle of the night, Netflix fills disks with the videos its algorithms say people are most likely to watch the next day. This dramatically reduces network utilization during peak hours.
The management software Netflix runs on Amazon Web Services handles distribution of content, analyzes network performance, and connects users to the proper video sources. Netflix wrote its own adaptive bitrate algorithms to react to changes in throughput, and a CDN selection algorithm to adapt to changing network conditions such as overloaded links, overloaded servers, and errors, the company said.
When Netflix used multiple third-party CDNs, connections would fail over from one to another in case of error. Netflix still uses the same failover technology, but with “multiple hierarchies” within Open Connect instead of multiple CDNs, Fullagar said.
Although Netflix is moving all its data onto Open Connect hardware, that doesn’t automatically reduce the controversial role its transit providers Level 3 and Cogent have played in carrying traffic. Level 3 and Cogent have warred with ISPs over whether they should have to pay in order to send Netflix traffic onto their networks. As a result, interconnections between these transit providers and ISPs have gotten congested, reducing the quality of Netflix and other Web services that travel over the links.
The role of transit providers is only reduced when Netflix signs direct interconnection agreements with ISPs, as it has done Verizon and Comcast, a Netflix spokesperson said. In the absence of such agreements, Netflix data passes through the company’s own CDN and then through a transit provider before hitting an ISP's network.
The payment controversies don’t necessarily affect the working relationship between the technical teams of Netflix and ISPs, though. “Engineering people at companies, whether large or small, operate independently of commercial interests,” Fullagar said. “In the UK, one of our biggest competitors is one of our best networking partners.”
Source: Ars Technica
New DASH-AVC/264 Guidelines Include Support for 1080p Video
Version 2.0 of the DASH-AVC/264 guidelines, with support for 1080p video and multichannel audio, is now publicly available on the DASH Industry Forum (IF) website.
The new guidelines includes several promised extensions, including one on HD video that moves the recommended baseline from 720p to 1080p.
720p had initially been chosen, according to the initial guidelines released in May, as a "tradeoff between content availability, support in existing devices and compression efficiency." At that time, the baseline video support used the Progressive High Profile Level 3.1 decoder and supported up to 1280x720p at 30 fps.
"The choice for HD extensions up to 1920x1080p and 30 fps is H.264 (AVC) Progressive 12 High Profile Level 4.0 decoder," the new guidelines state, adding support for 4.0 decoders that was lacking in the previous set of guidelines.
In addition, the guidelines also provide a way to handle standard definition (SD) content.
"It is recognized that certain clients may only be capable to operate with H.264/AVC Main Profile," the guidelines state. "Therefore content authors may provide and signal a specific subset of DASH-AVC/264 by providing a dedicated interoperability identifier referring to a standard definition presentation. This interoperability point is defined as DASH-AVC/264 SD."
The new guidelines also cover several multichannel audio options.
"The baseline 1.0 version of DASH-AVC/264 only required support for HE-AACv2 stereo," says Will Law, secretary of DASH IF and Chairman of its Promotions Working Group. "Version 2.0 introduces multichannel Dolby, DTS and also Fraunhofer profiles."
Law also says that there will be a number of DASH-AVC demonstrations around the at IBC at Amsterdam's RAI Convention Centre on September 12, 2013. "These demonstrations will show the latest advancements in the DASH workflow, from encoding, through delivery and playback, including 4K video, HEVC and multichannel audio," says Law. "You'll also see HbbTV and multi-screen applications as well as solutions for DASH use in the broadcast world."
These demonstrations will occur at various booths, including Akamai—the company where Law works as a Principal Architect for Media—Ericsson, Haivision, Microsfot, Nagra, and a host of others.
Digital Primates has been hosting a demonstration of a JavaScript version of a DASH-AVC/264 reference player. The dash.js is also being reviewed for the 1.0 release, according to Law, and release is planned just prior to IBC.
The official version will be launched soon at the DASH IF site but until then the Digital Primates demo can be found on their site. The demo requires Chrome or Internet Explorer 11 (IE); PlayReady DRM playback is currently only available with IE for this demo.
As the DASH IF points out, DASH-AVC/264 "does not intend to specify a full end-to-end DRM system" but it does provide a framework for multiple DRMs to protect DASH content. The guidelines allow the additional of "instructions or Protection System Specific, proprietary information in predetermined locations to DASH content" that has previously been encrypted with what's generally known as the Common Encryption Scheme (ISO/IEC 23001-7).
By Tim Siglin, StreamingMedia
Who is Powering the Rise of Online Video?
A confluence of technologies, evolving business models and changing consumer lifestyles are converging to propel the rise of online video and fundamentally transform TV, advertising and content delivery methods.
Here are the online video ecosystem segments and companies that are giving rise to this transformation.
The Current State of Android and Video
In the OS landscape, Android is by far the most widely used for tablets and mobile devices. With over 900 million current activated users and approximately 70% market share in the space, the platform is not only the most popular, but it’s also the most fragmented in terms of OEM’s and OS versions out there.
Android History and Origins
Android is a Java-Based operating system used for mobile phones and tablet computers. It was introduced and developed initially by Android, with financial backing from Google. Google acquired Android in 2005. Google announced their mobile plans for Android in 2007 and the first iteration of Android hit the shelves in 2008. Android is the world’s most widely distributed and installed mobile OS. However, in terms of application usage and video consumption, iOS devices lead the way. A consistent user experience and standardized video playback are two of the reasons for this.
Performance of Video on Android
When running video on Android devices, the experience varies from OEM to OS version to media source. Because of this lack of standardization with video, we wanted to give an overall look at the top mobile devices running Android to determine how video is delivered and how it performs across a few key sites and platforms.
We tested the following top devices running the most used versions of Android (2.3, 4.0, 4.1 or 4.2):
- Google Nexus 7
- Google Nexus 4
- Samsung Galaxy 4
- HTC One
- Samsung Galaxy II
- HTC EVO 4G
On the devices running older versions of Android, the experience was inconsistent across sites and the video performance wasn’t as strong. Some of the top video sites showed the option for either video display on a player or in the web browser, and some had very poor viewing capabilities for video.
A sample look at the different variations of video transfer and display on the Android devices is below:
Open Source on Android
Because Android is open source, Google releases the code under the Apache License. For this reason, every OEM modifies the open source code for their devices.
OEM’s create their own coding and specifications for Android for each device. This makes any standardization very difficult. When testing different versions of Android on different target devices, there are a lot of inconsistencies.
Google regularly releases updates for Android which further confuses things. End users often do not upgrade, either because they don’t know how, or because their device does not support the new release. The scattered consistency of updates further confuses any efforts at standardization.
Two of the largest and most widely used Android OEM’s both released their latest open source codes earlier this year. For the Samsung Galaxy codes please click here. For the HTC One click here.
Versions of Android
In 2008 Android v1.0 was released to consumers. Starting in 2009, Android started using dessert and confection code names which were released in alphabetical order: Cupcake, Donut, Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich, and the latest, Jelly Bean.
A historical look at the Android devices is below:
In terms of market share, the Gingerbread remains the most popular.
Top Android Devices per OS version
The top devices running Android in terms of both sales and popularity come from various OEM’s, with the majority from Samsung, HTC, LG and Asus. A few of the top devices from the most widely used Android OS versions are as follows:
DRM Content on Android
Android offers a DRM framework for all devices running their 3.0 OS and higher. Along with their DRM framework, they offer consistent DRM for all devices using Google’s Widevine DRM (free on all compatible Android devices) which is built on top of their framework. On all devices running 3.0 and higher, the Widevine plugin is integrated with the Android DRM framework to protect content and credentials. However, the content protection depends on the OEM device capabilities. The plug in provides licensing, safe distribution and protected playback of media content.
The image below shows how the framework and Widevine work together.
Closed Captions on Android
As developers know, closed captioning is not a simple “feature” of video that can be simply activated. There are a number of formats, standards, and approaches and it’s especially challenging for multiscreen publishers. On Android devices, closed captioning varies from app to app. However, any device using Jelly Bean 4.1 or higher can use their media player which supports internal and external subtitles. Click here for more information.
For any device using the Gingerbread version or lower which do not have any support for rendering subtitle, you can either add subtitle support yourself or integrate a third party solution.
Most larger broadcasters pushing content to OTT devices now serve closed captioning on Android (Hulu Plus, HBO GO, and Max Go to name a few).
Does Android support HLS?
Android has limited support for HLS (Apple’s HTTP Live streaming protocol), and device support is not the same from one version or one device to the next. Android devices before 4.x (Gingerbread or Honeycomb), do not support HLS. Android tried to support HLS with Android 3.0, but excessive buffering often caused streams to crash. Devices running Android 4.x and above will support HLS, but there are still inconsistencies and problems.
Best Practices for Video on Android
For deploying video on Android, there are several suggested specifications to follow. Below is a list of files supported by Android devices. Developers can also use media codecs either provided by any Android-powered device, or additional media codecs developed by third-party companies. If you want to play videos on Android, find a multi-format video player or convert videos to Android compatible formats using an encoding company.
Video Specifications for Android
Below are the recommended encoding parameters for Android video from the Android developer homepage. Any video with these parameters are playable on Android phones.
Video Encoding Recommendations
This table below lists examples of video encoding profiles and parameters that the Android media framework supports for playback. In addition to these encoding parameter recommendations, a device’s available video recording profiles can be used as a proxy for media playback capabilities. These profiles can be inspected using the CamcorderProfile class, which is available since API level 8.
For video content that is streamed over HTTP or RTSP, there are additional requirements:
- For 3GPP and MPEG-4 containers, the moov atom must precede any mdat atoms, but must succeed the ftypatom.
- For 3GPP, MPEG-4, and WebM containers, audio and video samples corresponding to the same time offset may be no more than 500 KB apart. To minimize this audio/video drift, consider interleaving audio and video in smaller chunk sizes.
Source: Encoding.com
The State of Streaming Media Protocols 2013
Protocols are a geeky thing, almost up there with metadata or IP address schemes. Without protocols, there would be no concept of a webpage, email delivery, or even VoIP (voice or video over IP). In fact, there would be no streaming of any flavor.
With that in mind, let's take a quick look at the latest developments in a few key protocols, some of which are just coming into widespread use for streaming.
On Time or On Target? The UDP Question
You may have heard the truism that "time is money." We often use that concept when we talk about hardware- or software-based transcoding: If a job needs to be done quickly, even faster than real time, go for the hardware; if time is less critical, use software.
The same concept, slightly morphed, can be applied to the world of streaming protocols: If low latency is key, go with UDP (User Datagram Protocol), but if delivery guarantee is more critical, go with TCP (Transmission Control Protocol). The latter provides control over guaranteed packet delivery -- the control in the transmission control protocol name -- while the former does not.
Every other protocol that we discuss in this article will hinge on TCP, but recent advances on the UDP front bear mention.
I'm not going to retrace step by step the key points that Dom Robinson travels in his recent article titled Reliable UDP (RUDP): The Next Big Streaming Protocol?, but I do want to point out several highlights.
First, in and of itself UDP is unreliable, but it's fast and efficient. The protocol itself has no mechanism to guarantee delivery or request missing packets, as does TCP. A properly constructed application, though, can act as the first line of defense in detecting loss or packet corruption with subsequent request for dropped packets.
"It can take TCP upward of 3 seconds to renegotiate for the sequence to restart from the missing point," wrote Robinson, "discarding all the subsequent data, which must be requeued to be sent again. Just one lost packet can cause an entire ‘window' of TCP data to be re-sent."
Second, UDP can work hand-in-hand with error-correction techniques. Many legacy intermittent networks, including those based on asynchronous transfer protocols such as ATM, used Forward Error Correction (FEC) to anticipate intermittent outages. FEC provides "packet flooding" at a certain percentage above 100% of packets -- be it 15%, 20%, 30% -- to then allow the client application to reconstruct the missing or corrupt packets without the need to request that packets be retransmitted.
Third, the concept of reliable UDP has been around for quite some time and can be accomplished with a number of open source tools, but there are also a number of commercial licensees that offer tools based on RUDP.
Your mileage may vary if you want to tinker under the hood of a freeware application such as UDP Data Transfer, or you may just want to reach out to a vendor in the RUDP space. Regardless of your choice, there are enough RUDP options out there to warrant research, especially if very low latencies and FEC are part of your workflow.
HTTP Über Alles
The fanfare around Dynamic Adaptive Streaming over HTTP, or DASH for short, continues to build at a rate we'd only ever seen back in the early streaming days of Real versus Microsoft. DASH was ratified back in late 2011, but its adoption has moved at a rapid pace.
Let's take a look at the HTTP flavors out there in current circulation: HDS, HLS, MPEG DASH, and Smooth Streaming. We'll look first at DASH followed, in alphabetical order, by the Adobe, Apple, and Microsoft proprietary offerings.
DASH It All, or Just 264?
Due to DASH's ability to deliver any of several types of files -- from the fragmented MP4 version of ISO Base Media File Format (ISOBMFF) to the Apple-modified MPEG2 Transport Stream (M2TS) -- the DASH specification reads like an encyclopedia of encoding, encryption, and delivery technologies.
To offset the potential problem that plagued MPEG 4 system -- a wide-ranging specification, based on Apple QuickTime, that was too complex to easily implement -- the industry has begun looking at options and commonalities of all the major HTTP delivery solutions. It has, as of the time of this writing, begun drafting a subset specification that centers on H.264 served as fragmented MP4. This use of ISOBMFF and H.264 is being dubbed as DASH 264.
What impact the DASH 264 specification has on the potential of bringing Apple into the DASH fold -- it was a contributor to the DASH specification, but is the only M2TS-based HTTP solution -- remains to be seen. But several industry players we spoke to stated the strong need to get solid DASH implementations into the field in early 2013.
Adobe's Flash vs. DASH Conundrum
While Adobe wouldn't publicly come out in support of DASH, despite co-sponsoring an ISOBMFF white paper in late 2011, the company did put its weight behind DASH in late February 2012.
"I am excited to announce that Adobe's video solutions will adopt the emerging video standard, MPEG-DASH across our video streaming, playback, protection and monetization technologies," wrote Kevin Towes in an Adobe blog post. "Adobe will support MPEG-DASH ISOBFF on demand and live profiles which are recommended in DASH-264 recommendation."
Towes anticipated the question many would ask: What about Flash and the Adobe HTTP Dynamic Streaming (HDS) protocol? He noted that Adobe will continue to push forward with HDS, even as Adobe supports DASH.
"Adobe will continue developing its HDS format used to deliver high quality, protected video experiences across multiple devices," wrote Towes, noting that the DASH profile for ISOBMFF "is similar to Adobe's HDS format and supports many of the performance objectives of the HDS format."
The continued development of HDS makes sense, as it offers Adobe the chance to try out new functionality within the confines of the Flash Player, but as we move into 2013, we wonder whether this is a sustainable model.
Adobe MAX 2013, to be held in May, may shed some light on HDS -- and perhaps even RTMP -- but meanwhile Adobe continues to show DASH functionality in the Flash Player.
An Apple (Protocol) a Day
Much has been made of the idea that HTTP Live Streaming (HLS) is a standard in the marketplace, but as one panelist at a recent DASH event quipped, "The IETF drafts of the Pantos spec are more a suggestion than a standard."
The Pantos spec, as it is known in the industry, is a series of working drafts for HLS submitted by two Apple employees as an information draft for the Internet Engineering Task Force. As of the time of this article, the Pantos spec is currently at informational version 10.
Much has changed between the early versions and the most recent v10 draft, but one constant remains: HLS is based on the MPEG-2 Transport Streams (M2TS), has been in use for almost 2 decades, and is deployed widely for varied broadcast and physical media delivery solutions.
In that time frame, however, little has changed for basic M2TS transport stream capabilities. For instance, M2TS still lacks an integrated solution for Digital Rights Management (DRM). As such, all HLS versions cannot use "plain vanilla" M2TS, and even the modified M2TS used by Apple lacks timed-text or closed-captioning features found in more recent fragmented elementary stream streaming formats.
Yet Apple has been making strides in addressing the shortcomings of both M2TS and the early versions of HLS: In recent drafts, the HLS informational draft allows for the use of elementary streams, which are segmented at the time of demand rather than beforehand. This use of elementary streams means that one Achilles' heel of HLS -- the need to store thousands, tens of thousands, or hundreds of thousands of small segments of long-form streaming content -- is now eliminated.
Google, with its Android mobile operating system platform, has adopted HLS for Android OS 4. Some enterprising companies have even gone back and created HLS playback for earlier versions of Android OS-based devices.
Smooth Streaming Ahead?
No discussion of HTTP protocol-based streaming delivery would be complete without a mention of Microsoft Smooth Streaming. After all, the Protected Interoperable File Format (PIFF) is the basis for the Common File Format (CFF) that is being used for UltraViolet, and the Common Encryption Scheme (CES) is based partly on Microsoft's 2008 idea that common encryptions and encoding could be implemented for use around the fragmented MP4 standard.
As we enter 2013, rationalization of PIFF-CFF-CES and the upcoming Common Streaming Format (CSF) will continue to pare down the number of options, which is a good thing if we are to get back to the business of creating content and delivering it to anyone who wants to view it.
Yet Microsoft isn't resting on its laurels, as the company announced in late 2012 that it would be supporting Smooth Streaming via the Open Source Media Framework (OSMF) that is part of Adobe's Strobe initiative for Flash. Yes, you heard that right: Not only does Flash Player support DASH in beta (thanks to Adobe), but it now supports Smooth Streaming (thanks to Microsoft).
Is RTSP Dead?
One of the most venerable streaming protocols, the Real-Time Streaming Protocol, has been implemented natively into every type of device: set-top boxes, smartphones, tablets, and PCs. Yet these implementations are often fraught with buggy code, limited support, and a number of oddities.
In testing performed on a number of Android OS devices, we have been surprised to find that RTSP-based video playback -- served from a standards-based server -- could not be played with built-in applications and services, despite the requirement for the base Android OS to be able to play this content. Content that would play consistently on numerous RTSP implementations would stop dead in its tracks on other devices.
This was true of any standards-based streaming protocol in the late 1990s, but these days, consumers just expect their content to stream with limited buffering and at varying data rates. RTSP offers neither of these as certainty, but is quite inexpensive to implement, so we suspect that it will be with us for at least a few more years before retiring to greener pastures to make way for DASH and more recent streaming protocols.
Where Does RTMP Fit?
At a recent informational meeting I attended with a major software company, a slide that was shown caught my attention, more for the lack of what was shown than for what the slide contained.
This particular slide listed the typical agnosticism -- codec, protocol, player -- of their soon-to-be-released update, and it had the regular litany of compatibilities. Yet what caught my attention was that the sparsest, by far, was the protocol list.
Only two protocols were noted -- HTTP and RTMP -- so I asked why RTMP was listed when other non-HTTP protocols were not. To summarize their response, they said RTSP and other non-HTTP protocols weren't being requested at all, but RTMP was still a valid industry solution.
Part of the reason lies in the fact that RTMP is "true" streaming with very low latencies and session "statefulness" that can't yet be found in HTTP-based delivery. In addition, RTMP is firmly entrenched on the vast majority of devices -- with the exception of the iOS devices -- thanks to the inclusion of the Flash Player on handsets, tablets, mobile devices, and PCs.
Yet, for all that entrenchment, as we've noted previously, Adobe continues to lean toward the HTTP delivery model in all the important ways including monetization functionality. We're not ruling out RTMP, but we do understand that the scalability and interoperability of HTTP solutions such as MPEG DASH and HLS offer compelling reasons to surf the fine streaming waves coming out of Apache servers everywhere.
Conclusion
So what does 2013 hold? We think the year is DASH's to lose.
Once DASH is officially supported in Flash, we see the possibility that DASH will be firmly enough entrenched to begin "hockey stick" growth for online video delivery. If DASH 264 can be implemented as quickly as it appears it will be ratified, and if there is some form of rationalization between HLS and DASH, including the ability to include Apple's DRM scheme in the Common Encryption Scheme, we might just note 2013 not only as the beginning of true online video delivery growth but also as the point at which cable and satellite providers begin to pay attention to delivery to all devices -- including set-top boxes -- for a true TV Everywhere experience.
By Tim Siglin, StreamingMedia
Content Preparation for Adaptive-Bit-Rate Video
Today’s media landscape is radically more diverse than just a few years ago. The delivery of consistently acceptable image and sound quality is taken for granted by viewers, despite uncertain or fluctuating bandwidth. Adaptive-Bit-Rate (ABR) streaming technology makes this possible.
What is ABR Streaming?
ABR streaming is a delivery technology designed to provide consistent, high-quality viewing in situations where bandwidth may fluctuate, and where viewers may be on a wide range of devices.
Prior to ABR streaming, Web or mobile video delivery was typically done by encoding a single downloadable file or stream at a fixed bit rate and frame size. Viewers could buffer some of the video, and then simultaneously download and play it back. This delivery model was similar to cable transmission, where a single bit rate is transmitted over a reliable medium.
Unfortunately, transmission mediums for Web and mobile devices are unreliable, and bandwidths vary. During fixed-rate video playback, viewers with low bandwidth suffer from excessive buffering (delaying playback). To compensate, providers have tended to encode at lower bit rates, punishing viewers with high bandwidth. Even then, any fluctuations in bandwidth can cause buffering delays.
To solve this problem, ABR streaming content is encoded into multiple layers, each potentially a different bit rate, frame size and/or frame rate. These layers are combined into a single package that represents the original content. ABR players switch between layers depending upon the device and available bandwidth, to ensure consistent high-quality playback.
For example, a single ABR package might include six layers, each encoded at progressively higher bit rates. As a viewer watches content on his/her mobile phone during a train ride, the player will adaptively switch between low bit rates and high bit rates, depending upon the connectivity of the device.
How Does it Work?
Most ABR streaming technologies use standard Web protocol (HTTP delivery) to send video. This offers advantages over specialized streaming protocols such as RTSP or RTP, as HTTP-based delivery works immediately on Internet networks and can take advantage of edge technologies designed to cache HTTP requests.
During playback, video and audio are delivered via HTTP in small fragments, each representing some small amount of video, typically between 2 and 10 seconds in length. Each content package includes multiple layers, and each layer may include many fragments. For example, an hour-long movie may have 12 layers, each with a thousand fragments. The player is provided with a package manifest file outlining which layers are available and the location of the fragments for each layer.
During playback, the player requests and downloads a fragment from a layer. While the fragment is played, the connection speed is monitored, and the player may opt to switch layers, either increasing or decreasing the video bit rate based upon the connection speed. Players may also choose layers with different frame sizes or frame rates to optimize the visual experience for the device. This adaptive behavior is what ensures consistent playback regardless of connection speed or device.
There are several different ABR streaming technologies available: Apple HTTP Live Streaming (HLS), Adobe HTTP Dynamic Streaming (HDS), Microsoft Smooth Streaming (MSS), and more recently MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH). Each technology requires a complete ecosystem. The content must be prepared correctly, and the correct player must be used. All of the technologies work fundamentally in the same manner, using HTTP for content delivery in fragments.
Where these technologies differ is largely related to the structure of the underlying packages. For example, HLS for older versions of iOS requires a separate file for each video fragment. In contrast, most other packages store fragments for a layer in a single file, allowing the player to download fragments using HTTP byte range requests, which download a small part of a larger file.
Other differences in ABR technology relate to the viewer experience. Apple HLS, for example, provides for a dedicated key frame layer, allowing users to scrub through the video quickly. Other packages allow an audio-only stream with a poster image for extreme low-bit-rate situations.
Preparing Content
Preparing ABR content takes several steps. First, the desired packaging and layer structures need to be identified. Next, content must be encoded, checked for quality, packaged, encrypted and delivered.
Choosing Packaging and Profiles
Packaging choice is generally driven by what devices must be supported. Not every device supports players for every type of ABR streaming technology. As a result, one should catalogue both the devices and the players that will be supported. The necessary packaging will naturally become apparent as a result.
The selection of optimal bit rates, frame sizes and frame resolutions will vary depending upon device types, connection types and encoding technology. Apple and Adobe provide excellent starting points with suggested profiles suitable for their ecosystems. However, practically speaking, the entire catalogue of devices, expected network connections and network costs must be considered when designing layers.
With these considerations, layer design is a balancing act between frame size, bit rate and quality. However, the actual encoding technology used may have the biggest effect upon quality. For example, one study performed by the MSU Graphics & Media Lab showed that the use of x264 encoding technology saved necessary bit rates by as much as 50 percent compared to other H.264 encoding technologies at the same quality level. As a result, it is recommended that layers be designed while performing actual encoding tests with the final encoding technology.
Most packages, however, generally contain between 16 and 24 layers. Part of layer design will require a reduction in the number of layers. It is best to select a few common native display frame sizes (such as 1080p) and then encode multiple bit rates to those frame sizes. Doing so will avoid unnecessary performance degradation on players that use software scaling (particularly important for Adobe HDS).
Encoding, Packaging, Delivery and DRM
Each layer will require that a complete H.264 stream be encoded. With 16 to 24 layers, encoding an ABR package can easily require 20 times the processing power needed for a single H.264 stream. Fortunately, highly parallelized multirate H.264 encoding technology exists that re-uses information across the different streams. When combined with GPU acceleration, today’s encoding systems can offer 10 or 20 times the speed of CPU-based systems.
When preparing for multiple devices, an important aspect of encoding is transmuxing, the ability to re-use encoded H.264 streams across multiple package types. This prevents having to re-encode the same bit rates simply to package the video differently.
With on-demand content, it is important to perform QC checks on the different video streams. QC may be performed visually or by using automated tools that measure quality across all of the streams.
On-demand content often requires user authentication and protection prior to playback, which requires Digital Rights Management (DRM). When using DRM, the video must be encrypted during packaging, typically using AES 128-bit encryption. DRM systems typically have subtle requirements for how the encryption is performed by the encoder or packager, and it is important to validate that the two are compatible.
Finally, content delivery will be performed, either as a compressed TAR file or in the native package form. Where possible, it is recommended that the entire production process (ingest, encoding, transmuxing, packaging, quality control, encryption and delivery) be combined into a single automated workflow. Manual steps will significantly slow production time and may result in errors. It is also recommended that the ABR production process be combined with non-ABR production into a single automated system. This reduces system maintenance costs, offers a single view into the overall content production for all distribution channels and allows workflow efficiencies such as unified metadata preparation and content preprocessing.
Conclusion
Preparing video for ABR streaming generally requires research up front to choose technologies and encoding profiles, and a well-integrated, accelerated encoding approach to ensure workflow efficiency. With today’s tools, it is possible to fully automate the ABR content production workflow with full integration into existing content preparation and delivery workflows.
By John Pallett, Broadcast Engineering
OTT Video Delivery
OTT video, or streaming media, is an evolving set of technologies that deliver multimedia content over the Internet and private networks. A number of online media platforms are dedicated to streaming media delivery, including YouTube, Brightcove, Vimeo, Metacafe, BBC and Hulu.
Streaming video delivery is growing dramatically. According to the comScore 2009 U.S. Digital Year in Review Video Metrix, Americans viewed a significantly higher number of videos in 2009 than in 2008 (up by 19 percent) because of both increased content consumption and the growing number of video ads delivered.
In January 2010, more than 170 million viewers watched videos online. The average online viewer consumed 187 videos in December 2009, up 95 percent over the previous year, and the average video duration grew from 3.2 to 4.1 minutes.
Hulu, for example, in that same month delivered more than 1 billion streams for a total of 97 million hours. According to comScore, the character of video viewing is changing as well, with more people watching longer content.
There is a growing effort by broadcasters to make regular TV content available online. For example, the BBC has developed the BBC iPlayer and the bbc.co.uk website to support replication of most BBC broadcast material. The service has been outstandingly successful: 79.3 million requests were serviced in October 2009. NBC coverage of the 2010 Winter Olympics included live and recently recorded content, complete with commercials.
Whenever there is the possibility of a large or dynamic viewer audience, a reliable CDN is required. CDNs once only used to replicate website content around the world. Now, they have expanded dramatically to handle streaming media. Research and markets estimated the value of CDN services for 2008 at $1.25 billion, up 32 percent from 2007.
Top CDNs include Akamai, Mirror Image Internet, Limelight Networks, CDNetworks and Level 3. Streaming media services must deal with content collected from disparate sources and distributed to a growing number of devices.
Technology Trends
The most common network protocol used to transport video over IP networks is the Real Time Streaming Protocol (RTSP). RTSP is a stateful protocol used to establish and control media sessions between a media server and client viewer. RTSP clients issue VCR-like commands to control media playback. The transmission of the audio/video stream itself is most often handled by the Real-time Transport Protocol (RTP), although some vendors have implemented their own transport protocol. RTSP and RTP are almost universally used to implement VOD features.
Most video players, such as the Adobe Flash Player, use proprietary protocols that provide additional functionality and flexibility. Flash Player has an almost total presence on PCs and Macs, and is used to deliver more than 80 percent of online videos. The Adobe Flash Player is a lightweight client embedded in Web browsers. Adobe uses the Real Time Messaging Protocol (RTMP) to deliver streaming content, providing multiple independent channels, which are used to control and deliver content. RTMPT is an RTMP variant that encapsulates RTMP packets in HTTP.
First released in 2007, Microsoft's Silverlight player is growing in popularity within the player market. The Silverlight player uses HTTP as its top-level transport mechanism and for media streaming. Using HTTP as a single transport mechanism can result in significant internal cost reduction for end-to-end delivery. Silverlight includes Digital Rights Management (DRM) features similar to those available in Adobe Flash.
HTTP Live Streaming (HLS) is a media streaming specification that is developed by Apple that uses HTTP as the transport. Devices such as the iPhone, iPad and Apple-compatible platforms support this streaming technology. The “Live” is misleading in the name, as this technology works for on-demand and live streaming. HLS supports streaming media that is segmented into smaller chunks of data, to improve delivery and user experience. An Extended M3U Playlist format file is used that contains the media segments to download.
Modern streaming media technologies adapt to changing network conditions, especially those related to mobile devices. As conditions degrade or improve, the player requests an alternate lower or higher bit rate media stream. Multiple flows are prebuilt or constructed at multiple bit rates and divided into chunks so that a player can seamlessly switch different flows.
The ability for a video player to adapt to varying network conditions is termed differently across players. In the Silverlight player, it is called Smooth Streaming; Adobe Flash 10.1 terms it HTTP Dynamic Streaming; and Apple iPhone's HLS refers to it as adaptive streaming.
How is IPTV Delivered?
Delivery of video to the consumer has undergone rapid change in recent years and is guaranteed to continue to do so in the future. Cable TV networks deliver a large range of content, and the ability to provide user interactive features, including VOD.
Carrying the most promise for the future is delivery of video over multiservice IP networks. This is commonly referred to as IPTV. It is delivered as a triple-play service to consumers that include High-Speed Internet (HSI) and VoIP.
Video over IP Information Flow
The major components and data flow in IPTV networks consists of media and control flowing between content servers and home networks.
The two types of video services delivered are linear broadcast and VOD. Both have dramatically different characteristics that affect the networks that handle them. Broadcasts are regularly scheduled programs sent to large numbers of subscribers. It is sent efficiently over multicast IP routes.
VOD service delivery exhibits an entirely different behavior from linear broadcast service. Stored videos are sent to the subscriber on demand. Each subscriber receives his or her own video flow, which they can control with VCR-like controls.
The differences are responsible for the complexity of the delivery network. Broadcast TV over IP is primarily a one-way channel, using well-understood multicast protocols. The home network is responsible for multicast messages and image display. VOD adds another level of complexity. Requests for and control of video content are transmitted upstream from the subscriber to the service provider using RTSP. Video content is returned to the subscriber through RTP.
IPTV Delivery Challenges
Until differentiating services are developed for IP-based video-voice-data networks, IPTV services will continue to be compared with traditional TV, cable and satellite service. As such, the IP delivery network must remain transparent to customers.
Customers expect video quality and service availability to be on par or better to make the switch. With multiple choices available to consumers, there is little tolerance for poor quality and operational problems. A poorly engineered network can lead to substantial customer churn.
To successfully deploy IPTV, the following end-user requirements must be addressed:
- Video quality: subscribers' perception of quality must be the same or better than other alternatives;
- Minimal channel change delay: because instant response is expected;
- Assured service delivery and availability for an always-on service.
IPTV Testing Requirements
Service providers must systematically test and verify network devices in each of the video transport architectures, including video content servers, core and edge routers, access devices, and customer premises equipment. Such testing provides an understanding of individual device performance and may determine how much impact each has on the overall system.
System-level tests that incorporate more than one demarcation point in the transport architecture are required. In this way, a clear understanding of how well the individual systems play with each other is determined.
Finally, the network must be tested end-to-end. Most standard routing and forwarding performance tests should be performed, looking at packet loss or latency under different load conditions.
Test Methodologies
All types of video testing, both OTT and IPTV, require testing through large-scale subscriber emulation. That is, large user communities must be simulated performing “normal” activities in order to exercise video components, subsystems and end-to-end delivery. “Normal” activity is directly related to the type of video delivery.
IPTV
Broadcast IPTV delivery is highly dependent on multicast operation. In order to avoid sending individual programs to individual users, all viewed channels are broadcast to all users wishing to view particular channels.
It is up to the STB and all routers between the source(s) and the subscriber(s) to join and leave multicast groups that correspond to a particular broadcast stream.
Broadcast IPTV testing requires emulation of subscribers engaged in two types of behavior:
- Requesting a channel (joining a multicast group), watching for a period of time and then requesting an alternate channel (leaving one group and joining another);
- Rapidly changing channels, often called “channel zapping”.
During this type of testing, the critical measurements are:
- Video quality, largely related to jitter and drop outs. Several types of quality of experience metrics, including VMOS and VQMon, produce values that are closely related to how viewers “feel” about their experience;
- Channel change latency — that is, the time between channel change request and response.
VOD
VOD stream delivery is point-to-point, as opposed to multicast. VOD users have VCR-like buttons at their disposal: play, pause, fast forward, rewind and stop. VOD testing requires emulation of subscribers engaged mostly in viewing and occasionally in VCR-like control activities.
During this type of testing, the critical measurements are:
- Video quality, as described above;
- Command latency — that is, response to VCR-like control activities.
OTT
OTT delivery is also point-to-point, and testing requires emulation of large audiences of users accessing a larger set of possible sources than with VOD. The same VCR-like controls are available, but due to the generally short nature of OTT content, are generally used less often.
What differentiates OTT from VOD and makes it much more difficult to test is changing connection rates. OTT content is saved many times over at the source for delivery at many different connection rates — for example, high resolution for broadband connections and low resolution for mobile devices. OTT delivery must quickly and transparently switch between streams based on conditions dictated by the consumer.
OTT testing, therefore, must emulate frequent bandwidth changes from a large community of users accessing many possible streams. During this type of testing, the critical measurements are:
- Video quality, as described above. Empirically, one's expectations of quality for this OTT delivery are much less than broadcast TV;
- Smooth presentation. As bandwidth availability changes, consumers must not be aware of the changeover of streams. That is, there should be no noticeable pauses.
BY Dave Schneider, Broadcast Engineering
MP4 File Fragmentation for Broadcast, Mobile and Web Delivery
Consistent multi-platform audio and video content delivery presents an ongoing challenge for broadcasters. Explosive smartphone and tablet growth on varying operating systems —Android, Apple iOS, or Windows Phone—threatens to create a user-experience divide between users on mobile devices, at the desktop or in the living room.
Broadcasters must address multi-platform consumption demands without compromising content security or network efficiencies. Many broadcasters are assessing efficiency of transport protocols used for content delivery, to see how they stack up for web and mobile delivery. Some legacy solutions, such as MPEG-2 Transport Stream (M2TS), lack basic web delivery functions.
What key information do broadcasters and network operators need to know as they look for more efficient approaches to the media delivery? This white paper explores fragmented MP4 files (fMP4) and considers whether the fMP4 format can replace legacy file formats.
Along the way, we’ll explore four key areas that impact both broadcasters and network operators:
- Format benefits of fMP4
- Network benefits of fMP4
- Movement toward fMP4 standardization
- Platforms supporting fMP4
By Timothy Siglin, Transitions, Inc.
Not Just Mobile: Adobe is Abandoning Flash on TVs as Well
Adobe announced Wednesday that it would be abandoning its work to enable rich applications on mobile devices through Flash, and would be focusing on HTML5 and Adobe AIR apps instead. But at the same time that it was working on bringing Flash video and applications to mobile devices, it was also hoping to bridge the divide between web video and what could be watched on connected TVs. So what happens to those efforts?
While the market for TV apps is incredibly fragmented, it doesn’t appear that Adobe’s Flash will provide a solution. The company confirmed through a statement that like mobile, it will no longer focus on porting the Flash plugin into web browsers on CE devices, but believes developers should build native apps on those devices instead. An Adobe spokesperson writes:
“Adobe will continue to support existing licensees who are planning on supporting Flash Player for web browsing on digital home devices and are using the Flash Player Porting Kit to do so. However we believe the right approach to deliver content on televisions is through applications, not a web browsing experience, and we will continue to encourage the device and content publishing community down that path.”
Adobe’s efforts to bring Flash to connected TVs, Blu-ray players and other devices, like its mobile Flash plans, were part of its Open Screen Project, which aimed to create a consistent app runtime across multiple devices. The idea was that developers would be able to create a Flash application once and be able to distribute it across web browsers, mobile devices and TVs.
Two-and-a-half years ago, Adobe announced a number of partnerships with OEMs and system-on-chip vendors such as Broadcom, Intel, STMicroelectronics, NXP Semiconductors and Sigma Designs to embed the Flash player into their silicon. But the number of TVs and other CE devices that support the Flash player have been limited to those from Sony and Logitech running the Google TV operating system. And Google TV has hardly been a success.
Now, Adobe is taking a step back from those plans, but not abandoning the TV app segment altogether. Instead of pushing multi-screen browser-based Flash applications, Adobe is hoping to convince developers to create native apps on mobile and TV devices using the Adobe AIR framework. Already some developers are taking advantage of that framework, with publishers like CNet, Epix and YouTube building TV apps for Samsung TVs based on Adobe AIR.
By Ryan Lawler, GigaOM
Google TV Porn Powered by HTML5, Not Native Apps
This summary is not available. Please click here to view the post.
Tablet TV: This is Just the Beginning
The tablet boom has already transformed the TV Anywhere and OTT strategies of some Pay TV operators but the real disruption is yet to come. The tablet market has so far been dominated by Apple with the iPad, but now attention is switching to Amazon whose product has been factored into forecasts by some analysts even before its launch. Forrester Research predicts it will give Apple a run for its money and notch up sales of up to 5 million units worldwide during the last quarter of this year. Apple, by contrast, will sell anywhere between 10 million and 22 million iPad2s in the same period depending on whose forecast you believe in a highly volatile and wildly fluctuating market.
For Pay TV operators the point is that the Amazon device, assuming analysts’ predictions are correct and that its launch is imminent, will retail for around $250, or perhaps under €200 in Europe, about half the price of the iPad2, and be designed with video in mind. It could turn the tablet into the second TV of choice for many homes during 2012, making it imperative that Pay TV operators act immediately to ensure that this is an opportunity rather than a threat to their business.
Some operators have already done this, with the consensus being that tablets should be embraced as companion devices acting as remote controls and programme guides or for associated activities such as voting in games or reality TV shows, as well as alternative TVs themselves. And without question there should be no extra charge for delivering content to tablets or any other device. This point was made before IBC by US satellite operator DISH Network, whose VP of Consumer Technology Vivek Khemka argued that extending TV services to tablets should not be viewed as an immediate revenue opportunity but as a competitive measure.
“I think the revenues will flow from the customer becoming stickier, and maybe upgrading to premium packages,” said Khemka.
The same line has been taken by Liberty Global with its multimedia gateway called Horizon, which was unveiled at IBC. This includes Wi-Fi ports to deliver TV services to tablet devices at no extra charge. Liberty Global is conducting field trials with Horizon in the Netherlands with commercial launch planned for Q1 2012 by its UPC operation there, followed by its operations in Switzerland and Germany soon after. The aim is to attract developers of Apps to enrich the service both on tablet devices and primary TVs.
“We have ripped up the set-top and made it into a platform so that users can seamlessly navigate content and integrate it onto many devices in multiple places,” said Mike Fries, President and CEO of Liberty Global.
For operators such as Liberty Global, the challenge is to tie tablets into their Pay TV package to prevent consumers from defecting to emerging services that may provide some of the same content free over-the-top. One point in their favour is that at present tablets will consume most TV content over Wi-Fi within the home, rather than over cellular 3G or 4G services that are as yet incapable of delivering premium video services through lack of consistent bandwidth. This means that operators who supply the broadband connection are well placed to provide content to tablets within the home, especially if they can integrate them with the service as companion devices.
Tablets in companion mode can also create the indirect revenue opportunities alluded to by Khemka at DISH Network by increasing engagement with the content being watched on the big screen, drawing more viewers in. During the IBC conference several speakers referred to the ability of companion devices, which admittedly could be smartphones or laptops as well as tablets, to boost audiences for less popular niche content by providing an added element of entertainment or enlightenment.
Such entertainment can involve integration with social media, and this has been exploited very effectively by the UK Eden channel, which re-broadcasts natural history and action programmes made by the BBC and others. The channel allows viewers to vote via companion devices on aspects of programmes, such as their favourite wildlife attraction, with prizes. It also features question and answer sessions via Facebook with major wildlife presenters such as David Attenborough.
“This has led to a 112% increase in viewing within the key 16 to 34 age group,” said Steve Plunkett, Director of Innovation and Technology at Red Bee Media UK, which worked with the Eden channel on the project. Speaking at an IBC conference panel, Plunkett described this as a striking result given that the Eden channel broadcasts content that is quite specialised rather than having mass-market appeal.
To be successful with tablets, operators or broadcasters must play to their strengths rather than just treating them as second TV sets, as the Eden channel has done. The failure of mobile TV so far can be attributed partly to an inability to exploit smaller screens properly, according to Sefy Ariely, VP for Sales and Marketing at IPTV middleware and content discovery specialist Orca Interactive.
“At the end of the day the reason I believe mobile TV was not successful is because it was trying to take the experience from one context to another,” said Ariely, speaking to Videonet at IBC.
This led to a temporary loss of interest in convergence between fixed and mobile TV, according to Ariely, but now the tablet is fast bringing it back. “We have watched how the iPad and tablet have sown the seeds for a tsunami of multi-screen and TV Anywhere discussions, and seen everyone scrambling while for us it was already built-in. We see this as another step in the trend towards personal TV.”
Indeed it is the potential of tablets to personalise the whole TV experience that holds the keys to success for operators, according to Neale Foster, VP of Global Sales at ACCESS, a provider of software for portable and wireless devices. “Apps can seriously enhance that experience and that is the point of companion and multi-screen devices,” said Foster, speaking on a panel hosted during IBC by CA and Pa TV software provider NDS. “They must be enjoyable and fun.”
Over time apps on tablets as companion devices also have potential to create those elusive new revenue opportunities that Pay TV operators are craving, by enabling adverts that play across both screens with scope for interactivity. “I think when the advertisers and media buyers get hold of this it is going to go stellar,” said Steve Godman, Sales Director at London-based digital media agency Skinkers, speaking on the same NDS sponsored panel. “The minute you get a really robust advertisement platform plugged into this stuff you will start generating revenue from it”.
The tablet boom has opened this door for advertising related apps, Godman added. “Tablets change the dynamic – you don’t have to fire up a laptop.” But for advertising, as with the associated programme, the context must be right for the device. “The opportunity lies in providing the right content for the device.”
The potential of tablets is not just as companion devices, or even as second TVs within the home, but also to usher in the era of full TV Anywhere that is not confined to locations where wired connectivity or Wi-Fi access is available. This full tablet potential will emerge gradually over the next few years, according to Andrew Baron, Chief Operating Officer at the UK cable operator Virgin Media.
“We are starting to see the ecosystem emerging, with video and the mobile getting ever-closer,” said Baron at an IBC conference. “I confidently predict the major theme here (at IBC) in the next three or four years will be mobile.”
This will require either further improvement in the ability of mobile 4G networks to provide the required bandwidth and Quality of Service for HD video, or else carpeting almost the whole country with Wi-Fi. With the arrival of the tablet, the end device is now driving mobile video forward rather than holding it back as before.
By Philip Hunter, Videonet
Improving QoE for IP Video Services
The boom in OTT and TV Anywhere services is underlined by rapid growth in IP video transmission at all stages of the content lifecycle, and this is expanding greatly the scope and demand for Quality Assurance (QA) products. Even leading proponents of OTT services still admit there is some way to go to provide acceptable Quality of Experience (QoE) for high-definition premium content over unmanaged networks in particular.
“One of the main obstacles to OTT is the lack of a great user experience,” says Helge Høibraaten, CEO of Vimond Media Solutions, a spin-off of Norwegian commercial TV station TV 2, which is commercialising its OTT broadcast platform internationally.
Speaking at a conference during the recent IBC exhibition in Amsterdam, Høibraaten indicated that an OTT platform was defined by the quality it delivers and must meet the needs of all devices including tablets, PCs and smartphones. Vimond itself has only just extended its applications suite to Apple iOS devices (iPad and iPhone), Android and Windows phones, in addition to Windows desktop PCs which it already supported. The message for vendors of OTT platforms, and for the services that run on them, is that they should only embrace new device types when acceptable quality can be guaranteed.
The definition of acceptable quality is admittedly rather subjective. It is certain, though, that IP networks are creating new challenges for providers of QA video products. These vendors have been extending their portfolios to tackle video delivery over both managed and unmanaged IP networks, with various announcements made at IBC.
While unmanaged networks including the Internet pose the greatest challenge, even managed IP networks require careful handling to avoid packet loss and latency resulting from congestion within the infrastructure. This can happen because unlike traditional broadcast networks, IP infrastructures do not have fixed end-to-end paths and have no pre-determined transmission times for each IP packet. It is possible for more packets to enter the network than can be delivered within an acceptable time frame, leading to congestion and either dropped packets, delays, or both. Either of these can cause loss of quality on receiving devices.
The remedy is to apply traffic shaping, which involves holding up IP packets that are less critical or which can afford a little delay in order to preserve capacity for the most important packets. This can be performed at the point of entry to the network or within the network by routers themselves or other dedicated devices, and the key with managed networks is that operators can control the traffic shaping process better. Potentially, packet loss can be eliminated and latency kept within acceptable limits, according to Per Lindgren, VP Business Development and Co-Founder of Net Insight, the Swedish-owned vendor of the Nimbra IP media transport platform. Net Insight tackles the managed IP quality issue by breaking the network down into separate segments and applying QoE mechanisms including traffic shaping to each.
The first step is to ensure that the routers themselves do not create problems under congestion by dropping packets as they pass through, so Net Insight has applied traffic shaping at this level to ensure this does not happen. “By traffic shaping even inside our MSRs (Media Switch Routers), we can traffic shape down until we ensure we do not lose any packets there,” says Lindgren.
The next step is to address the links through the core network between the routers and ensure that the QoS needs of each individual service are met. “Traditionally telcos have not been treating media traffic as a special service,” says Lindgren. “So we propose building service aware media networks. MSRs aggregate traffic so that the core network (provided by a telco) only handles aggregated flows rather than individual services. Our MSRs then handle the different protection needs of each service, and can add QoS enhanced links inside a media service network rather than just at the edges.”
In this way, by addressing both the routers and links between them separately as part of a coordinated traffic management approach, the network can achieve much higher levels of quality. Even then, though, the possibility of packet loss or delay cannot be discounted, and so the third element of Net Insight’s QA strategy is to monitor every link. “We can do continuous real-time monitoring of traffic between MSRs and see any packet loss sent between one MSR and another,” Lindgren explains. “That makes it much easier to troubleshoot.”
Within unmanaged IP networks, on the other hand, it is impossible for broadcasters or operators to do either traffic shaping or performance monitoring since they do not own the infrastructure. This is an increasing issue with the growth of cloud-based services where the infrastructure is normally owned and managed by a third-party with video delivered over some Content Distribution Network (CDN). In that case there is an apparent black hole between the cloud and the end user, making it difficult for a content provider to know what quality the customer is getting.
Another Swedish vendor specialising in distributed video delivery, Edgeware, has tackled this problem with its Convoy VDN, which is software operating within the company’s Distributed Video Delivery Network (D-VDN) platform. Announced at IBC, this operates by combining the receiving device’s capability with the QoS known to be provided by the delivery infrastructure, according to Edgeware’s Chief Marketing Officer Duncan Potter.
The point is that CDNs usually operate via adaptive streaming protocols to improve network efficiency and performance, breaking video up into multiple small file chunks that can take different routes before being reassembled at the destination. The network detects each user’s CPU capacity and bandwidth continuously and adjusts the quality of the stream in real-time to ensure that QoE is always as good as it can be at that point in time. But breaking up video into chunks does make it hard to monitor what is going on within the CDN, and this is the problem Edgeware has addressed with Convoy VDN. “As we are a network device we can see what is going through,” said Potter. “We work out what is sent, collect statistics via a central reporting engine, and that is integrated with the higher level CDN management system.”
Such measures may help ensure optimum quality when a service is working normally but do not cater for major outages within the infrastructure. While IP networks are becoming more reliable, there is rising dependence in an increasingly global content market on external communication links that may be unreliable. This is a particular problem for the growing number of niche and ethnic services that have a global audience distributed across numerous, often small, communities around the world.
Such ethnic services can be lucrative, with high profit margins for operators because consumers are prepared to pay a premium or a separate subscription to receive them, but the total revenue in a given region is usually relatively small. This means operators cannot afford to spend too much capital on protecting against failure of the service in a region beyond their control, according to Danny Wilson, CEO of TV performance monitoring vendor Pixelmetrix. “Typically if an operator imports content from, say, India, they are vulnerable to loss of signal from Delhi,” he points out.
Pixelmetrix is tackling this with software announced at IBC that enables its DVStor recording and playback platform to perform disaster recovery and start playing out the content in the event of an outage. “We are recording what is going on at a downlink coming in from overseas and have integrated this with our test and measurement devices,” says Wilson. “Then if there is any interruption, the sensor detects that input signal is lost, and this DVStor solution can then provide back-up recovery on a real-time basis.”
This, in effect, is a cloud-based disaster recovery service and could be incorporated within IP-based delivery infrastructures. It highlights the growing scope of Quality Assurance, bringing together elements of disaster recovery, troubleshooting and performance monitoring within an overall QoE package.
By Philip Hunter, Videonet
Subscribe to:
Posts (Atom)
