The State of MPEG-DASH 2016
The industry is turning away from plug-ins and embracing HTML5 everywhere. Here's how the vendor-independent streaming standard is gaining momentum.
Showing posts with label MPEG DASH. Show all posts
Showing posts with label MPEG DASH. Show all posts
DASHInterpret
DASHInterpret converts video-on-demand dynamic adaptive HTTP streams (MPEG-DASH) to Apple HTTP live stream (HLS), useful when you already have existing MPEG-DASH content and you need to serve it to existing Apple users who don’t want to use a third-party
There are several software out there (e.g. Wowza or Evostream) that takes in live streams in the form of RTSP, RTMP, MPEG-TS, FLV, etc… and they produce many other formats out of that single input. They come in the form of a server (service) listening to ports or connecting to other remote streaming servers. Their purpose is to simply bridge the gap between different streaming format as they serve multiple streaming format output from a single input. These servers are mainly used in 3 use cases, but majority of usage is in live streaming.
Use Cases:
- Takes a live stream (e.g. RTMP, RTSP, MPEG-TS…) as an input, and outputs another live stream which could be the same format or a different format
- Takes a live stream as an input, and outputs a recorded or video on demand stream (e.g. MP4, MPEG-DASH, HLS…) stored as files on disk
- Takes a video on demand stream as an input, and outputs either a live stream or another video on demand stream.
DASHInterpret is not one of these software, although what it solves is similar, it leans more to the video on demand space. It is not a server running on the background listening to ports or making connections and all those networking stuff. It is simply a utility that reads in a video on demand MPEG-DASH and converts it to another video on demand format. The software is portable in that you can move around computers and use it without doing any setup, configuration or installation. Version 1.0.0 release currently supports conversion of DASH-IF compliant Dynamic Adaptive Streaming over Http (MPEG-DASH) content to Http Live Streaming (HLS).
So what is the advantage of using DASHInterpret? If you are only converting VODs, you will be able to do this a lot easier and quicker than any of these live streaming servers. Since DASHInterpret does not get its input from the network, it does not have to worry about the performance penalty of going through the network stack, it is also not limited to the meager 1000 Mbit speed of modern networks, rather, it operates on the speed of your hard disk I/O which is a minimum of 6000 Mbit for average computers. You also don’t need to spend a day or week to learn how to use it, 30 seconds is all you need to learn how to use it. You can take it anywhere and be able to use without configuring or some sorts of setup, you can even store it in a USB drive and run directly from there no problem.
Why convert only MPEG-DASH streams? Because MPEG-DASH is the current and next generation technology when it comes to adaptive bit rate streaming over http protocol. Streaming businesses will transition now or in the near future, and part of that transition are users who can’t transition or will not transition quickly. That’s where DASHInterpret will come in, the content provider will use it to translate its MPEG-DASH to the format familiar to the customer like HLS for Apple users. As of this writing, HLS is still the dominant http streaming technology in operation especially for the millions of Apple users.
Subtitles in an IP World
An end-to-end demonstration of EBU-TT-D subtitles being delivered via MPEG DASH and displayed by a client.
The Structure of an MPEG-DASH MPD
This article describes the most important pieces of the MPD, starting from the top level (Periods) and going to the bottom (Segments).
The State of MPEG-DASH 2015
An interesting article by Nicolas Weil, presenting the past, present, and future of MPEG-DASH.
MPEG-DASH Content Generation Using MP4Box and x264
An interesting article describing how to produce MPEG-DASH content with open source tools.
DASH AVC/264 Support in GPAC
This article shows you how to setup GPAC for your OnDemand and Live contents.
DVB MPEG-DASH Profile Specification
The DVB MPEG-DASH Profile Specification defines the delivery of TV content via HTTP adaptive streaming. This includes the following:
- A profile of the features defined in MPEG DASH (referred to by MPEG as an "interoperability point") largely based on the "ISOBMFF live" profile defined by MPEG.
- Constraints on the sizes or complexity of various parameters defined in the MPEG DASH specification.
- A selection of the video and audio codecs from the DVB toolbox that are technically appropriate with MPEG DASH constraints and/or requirements for the use of these, without mandating any particular codec.
- Using MPEG Common Encryption for content delivered according to the present document.
- Use of TTML subtitles with MPEG DASH.
- Requirements on Player behaviour needed to give inter-operable presentation of services.
- Guidelines for content providers on how to use MPEG DASH.
Overhead and Performance of Low Latency Live Streaming using MPEG-DASH
HTTP Streaming is a recent topic in multimedia communications with on-going standardization activities, especially with the MPEG DASH standard which covers on demand and live services. One of the main issues in live services deployment is the reduction of the overall latency. Low or very low latency streaming is still a challenge.
In this paper, we push the use of DASH to its limits with regards to latency, down to fragments being only one frame, and evaluate the overhead introduced by that approach and the combination of: low latency video coding techniques, in particular Gradual Decoding Refresh; low latency HTTP streaming, in particular using chunked-transfer encoding; and associated ISOBMF packaging.
We experiment DASH streaming using these techniques in local networks to measure the actual end-to-end latency, as low as 240 milliseconds, for an encoding and packaging overhead in the order of 13% for HD sequences and thus validate the feasibility of very low latency DASH live streaming in local networks.
By Nassima Bouzakaria, Cyril Concolato and Jean Le Feuvre
DVB Approves UHDTV HEVC Delivery Profile
A significant step in the road to Ultra High Definition TV services has been taken with the approval of the DVB-UHDTV Phase 1 specification at the 77th meeting of the DVB Steering Board. The specification includes an HEVC Profile for DVB broadcasting services that draws, from the options available with HEVC, those that will match the requirements for delivery of UHDTV Phase 1 and other formats. The specification updates ETSI TS 101 154 (Specification for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream).
The new DVB-UHDTV Phase 1 will allow images with four times the static resolution of the 1080p HDTV format, at frame rates of up to 60 images per second. Contrast will be drastically improved by increasing the number of bits per pixel to 10 bit. From the wide range of options defined in the HEVC Main 10 profile, Level 5.1 is specified for UHD content for resolutions up to 2160p. For HD content, HEVC Main profile level 4.1 is specified for supporting resolutions up to 1080p.
The DVB-UHDTV Phase 1 specification takes into account the possibility that UHDTV Phase 2 may use higher frame rates in a compatible way, which will add further to the image quality of UHDTV Phase 1.
“HEVC is the most recently-developed compression technology and, among other uses, it is the key that will unlock UHDTV broadcasting,” said DVB Steering Board Chairman, Phil Laven. “This new DVB–UHDTV Phase 1 specification not only opens the door to the age of UHDTV delivery but also potentially sets the stage for Phase 2, the next level of UHDTV quality, which will be considered in upcoming DVB work,” he continued.
Also approved was the specification for Companion Screens and Streams, Part 2: Content Identification and Media Synchronization. Companion Devices (tablets, smart phones) enable new user experiences for broadcast service consumption. Many of these require synchronisation between the Broadcast Service at the TV Device and the Timed Content presented at the Companion Device. This specification focuses on the identification and synchronisation of a Broadcast Service on a TV Device (Connected TV or STB and screen) and Timed Content on a Companion Screen Application running on a Companion Device. Part 2 outlines the enabling factors for the identification of, and synchronisation with, broadcast content, timed content and trigger events on TV devices (for example a Connected TV or STB) and related content presented by an application running on a personal device.
Another specification to gain approval from the Steering Board was the MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks. This specification defines the delivery of TV content via HTTP adaptive streaming. MPEG-DASH covers a wide range of use cases and options. Transmission of audiovisual content is based on the ISOBMFF file specification. Video and audio codecs from the DVB toolbox that are technically appropriate with MPEG-DASH have been selected. Conditional Access is based on MPEG Common Encryption and delivery of subtitles will be XML based. The DVB Profile of MPEG-DASH reduces the number of options and also the complexity for implementers. The new specification will facilitate implementation and usage of MPEG-DASH in a DVB environment.
The three new specifications will now be sent to ICT standards body ETSI for formal standardisation and the relevant BlueBooks will be published shortly.
Source: Advanced Television
UHD HEVC Data Set
As part of the 4Ever project, we have been releasing an HEVC and DASH ultra high definition dataset, ranging from 8bit 720p 30Hz up to 10bit 2160p 60 Hz. The dataset is released under CC BY-NC-ND.
The data set web page is here, and more information on the dataset can also be found in this article.
Source: GPAC
DASH Talks NAB 14
During the 2014 NAB show in Las Vegas, the DASH Industry Forum organized a 2hr session with nine presentations giving you the latest technical, business and deployment updates on MPEG-DASH. Speakers represented companies from across the DASH ecosystem. Here is the video replay of this event.
Microsoft Smooth Streaming Client 2.5 with MPEG DASH Support
The PlayReady team, working in conjunction with the Windows Azure Media Services team is pleased to announce the availability of the Microsoft Smooth Streaming Client 2.5 with MPEG DASH support.
This release adds the ability to parse and play MPEG DASH manifests in the Smooth Streaming Media Engine (SSME) to provide a Windows7/Windows8 and MacOS solution using MPEG DASH for On-Demand scenarios.
Developers that wish to move content libraries to DASH have the option of using DASH in places where Silverlight is supported. The existing SSME object model forms the basis of DASH support in the SSME. For example, DASH concepts like Adaptation Sets and Representations have been mapped to their logical counterpart in the SSME.
Also, Adaptation Sets are exposed as Smooth Streams and Representations are exposed as Smooth Tracks. Existing Track selection and restriction APIs can be expected to function identically for Smooth and DASH content.
In most other respects, DASH support is transparent to the user and a programmer who has worked with the SSME APIs can expect the same developer experience when working with DASH content.
Some details on the DASH support compared to Client 2.0:
- A new value of ‘DASH’ has been added to the ManifestType enum. DASH content that has been mapped into Smooth can be identified by checking this property on the ManifestInfo object. Additionally the ManifestInfo object’s version is set to 4.0 for DASH content.
- Support has been added for the four DASH Live Profile Addressing modes: Segment List, Segment Timeline, Segment Number, and Byte Range.
- For byte range addressable content, segments defined in the SIDX box map 1:1 with Chunks for the track.
- A new property, MinByteRangeChunkLengthSeconds, has been added to Playback Settings to provide SSME with a hint at the desired chunk duration.
- Multiple movie fragments will be addressed in a single chunk such that all but the last chunk will have a duration greater than or equal to this property. For examples of how to set Playback Settings see the Smooth documentation.
There are some limitations in this DASH release, including:
- Dynamic MPD types are not supported.
- Multiple Periods are not supported in an MPD.
- The EMSG box is not supported.
- The codec and content limitations that apply to Smooth similarly apply to DASH. (see here)
- Seeking is supported, but not trick play. Playback rate must be 1.
- Multiplexed streams are not supported.
Source: Microsoft
DASH Segmenting
Usually when creating a video, all that is needed is to encode it using a codec (for example H.264 or HEVC). However, to transmit a video using MPEG-DASH, an extra segmentation step is required. Typical encoders do not provide this step and produce content which is not compatible with DASH.
Hosted as a GitHub project, dash.encrypt is available as an open-source application written in Java. It takes encoded video and audio from an array of different formats and repackages them as valid DASH streams. It also generates the required manifest which is the table of contents for the stream.
Live Streaming to the Browser Using MSE and MPEG-DASH
For the next two weeks, we’re running a trial in conjunction with Radio 3 to deliver surround sound to your browser for a series of classical music concerts. On the Radio 3 blog, Rupert Brun explains the background to the trial and how to get involved.
Here in Broadcast & Connected Systems at BBC R&D, we are always looking for new ways to apply our technology research to extend the reach of BBC content to the maximum number of users. Surround sound isn’t new, but delivering it to the home via the Internet has traditionally meant installing plugins or other applications, limiting the platforms and consumers we can target.
In this experiment, we believe we are the first broadcaster in the world to stream a live outside broadcast in discrete multichannel audio to the home using MPEG-DASH, and we're doing it using just a compliant web browser - no plugins, no separate software installation required.
Why Stream to the Browser, and Why Now?
The beauty of the browser is that it is (almost) ubiquitous. Every PC, tablet and smart phone has a browser installed when it ships. Increasingly, smart TVs, set top boxes and games consoles have some form of browser environment available, bringing HTML5, CSS and Javascript functionality to the majority of consumer electronic devices.
People expect to be able to consume BBC content on any platform. To enable this, the BBC currently has to support a number of streaming protocols and has to maintain many different applications with differing code bases and levels of functionality in order to support hundreds of different set top boxes, smart TVs, mobile devices and desktop environments.
What if we could have a single encoding and distribution workflow and a single cross-platform client application, reducing the complexity of distribution and allowing our developers to concentrate on delivering great user experiences?
From a listener’s perspective, the browser “just works” which makes accessing our services much easier. Removing the requirement to install plugins or other software removes a significant barrier for some users. Indeed, for cross-platform compatibility, security and stability, many browser vendors have decided not to support plugins in the future so we need to move away from these anyway.
Three particular technical standards should enable us to do this in the future: HTML5, MPEG-DASH and W3C Media Source Extensions.
HTML5 and Media Source Extensions (MSE)
In HTML5 the HTMLMediaElement, typically a video or audio tag, exposes a source element which accepts a URL of the content to be played. The browser retrieves, decodes and plays the media data automatically, providing it knows how to handle your media type. This offers simplicity for the developer and, in theory, has removed the need for plugins, but the trade-off is that there is no control over many important variables: how data is downloaded and from where, how much data is buffered, which adaptive streaming algorithms to use or what to do in case of failure.
The ability to control these variables is key to providing a world-class user experience, but by default they are hard-coded into the browser. Ideally we want to hand as much control as possible to the Javascript application, while still deferring to the browser for parsing, decoding and rendering the media data. Typically, Adobe Flash or Microsoft Silverlight applications have been used to provide all of this functionality on those platforms that support those plugins.
Most of these features can be replicated in Javascript but, until now, it has not been possible to feed media data to the HTMLMediaElement. The Media Source Extensions define a Javascript API which allows media streams to be constructed dynamically within a Javascript application.
At the heart of MSE is the MediaSource object. This object is created by the application and attached to the media element. Its purpose is to provide the media data for playback as requested by the media element.
The MediaSource object maintains a collection of SourceBuffers. These are the interface through which the application appends media data to the source and methods are provided to insert, remove and manage media data. They are essentially an abstraction of a timeline – media data can appended to the buffer based on media playback timestamp, or it can be appended sequentially, ignoring timestamps. The latter mode enables unrelated media to be spliced together, which allows uses such as advert insertion or even video editing in the browser.
The application handles the requesting of media data from the server and appends the response to the SourceBuffer. Decoupling the fetching of media data from playback allows the media data to be sourced using novel transport mechanisms or from different locations.
SourceBuffers can contain audio, video or timed text and an instance is created for each stream that needs to be presented. Typically there might be one video stream, one audio stream and perhaps a subtitle stream. Since each media type is handled separately, access services such as audio description or subtitling can be selected simply by requesting a different stream.
Finally, the specification also includes extensions to the HTMLVideoElement allowing measurement of video decode and rendering performance which could be used to help decide the most appropriate video stream to present if a number of options are available.
An additional benefit of not hardcoding features into the browser is that any functionality upgrades such as improved adaptive algorithms or defect fixes are simply a case of updating the Javascript application, which is freshly fetched each time the page is loaded, rather than requiring every user to upgrade their browser. Software updates to the browser itself might be fairly easy on a PC but happen infrequently on a smart TV or set top box.
Content Delivery Using MPEG-DASH
MPEG-DASH is the new standard for delivering media content over the Internet. It is designed to allow content to be delivered efficiently in a segmented form, making use of standard caching techniques for web content in order to deliver to large audiences. It supports bitrate adaptation, allowing each viewer to receive a stream in the best quality that their Internet connection can deliver.
Since even surround audio streams need only a low bitrate connection, we are not using bitrate adaptation for this trial. The audio stream is simply encoded at a constant rate of 320 kbps using AAC-LC. However, MPEG-DASH still takes care of dividing the live audio stream into short segments that the client can retrieve using HTTP. Most importantly, MPEG-DASH is a streaming standard which can be implemented for a browser using the W3C Media Source Extensions.
Building a MPEG-DASH Player Using MSE
In order to deliver the surround audio to you, a DASH player application needs to at least perform the following tasks:
- Create a MediaSource object and set it as the source of the media element
- Request and parse manifest and create SourceBuffer objects for each enabled stream
- Request segments for each stream and append them to the SourceBuffers
- Repeat step 3
Where Next?
MSE has recently reached Candidate Recommendation stage, meaning that it should be complete enough to allow implementation, but browser support is still limited.
Right now, Chrome (33 or higher), and IE11 on Windows 8.1, are the only browsers we’ve seen which support enough features for our trial. If you’re a fan of Firefox, Safari or other browsers, these currently have incomplete support, though many of these vendors have publicly stated they are working on it.
As support for these features becomes more widespread, we expect that more and more content on the Internet will be delivered this way. Other content providers are also starting to use these techniques: Netflix has deployed a MSE-based player – this is the default player if you are using IE11 on Windows 8.1. Youtube has also deployed a MSE-based player for some content on some platforms.
Although we are actively experimenting with MSE in BBC R&D, there are no immediate plans to launch any BBC services using the technology. Nevertheless, HTML5, MPEG-DASH and MSE are a powerful set of standards that are sure to play a significant role in delivering media content on the Internet in the coming years.
By Dave Evans, BBC R&D
Building an Online Video Player with DASH-264
This article discusses the current state of online video, delves into the DASH standard, explores the challenges of building a DASH player, and, finally, walks through the basics of implementing the open source Dash.js player.
Subscribe to:
Posts (Atom)
