Quote from a white paper Transitions just completed on fragmented MP4 (fMP4) and MPEG-DASH:
Proponents say that the Common File Format (CFF) and Common Encryption (CENC) scheme will represent two important steps toward large-scale online video distribution via adaptive delivery of fragmented elementary streams.
Since CFF can also be used outside of the bounds of UltraViolet, significant interoperability may also exist between UltraViolet disc-based playback and online video platforms, in much the same way that the DVD Forum’s published specifications for DVD playback guaranteed interoperability between DVD players. It’s not out of bounds to think of CFF as the DVD standard for the web.
To get a better understanding of the power of fragmented MP4, first look at the sidebar in the white paper on "combinatorial complexity" for which Netflix contributed a real-world example. Even without CFF and CENC, Netflix is proving the case that fMP4 scales much better than the HLS approach (with a far lower asset management impact).
The white paper has been several months in the making, starting first as separate concepts by two key companies in the streaming space: Adobe Systems and Microsoft Corporation. Each has their proprietary solutions, but both are committed to seeing fragmented MP4 (fMP4) offer a potentially viable alternative to legacy streaming solutions.
After several meetings, both companies chose to jointly work with Transitions to create a white paper noting the benefits of fMP4 and, to a slightly lesser extent, the potential benefits of MPEG-DASH (a proposed standardization of dynamic streaming over HTTP that I mentioned in a prior blog post).
Special thanks to Microsoft and Adobe for providing financial resources and access to subject-matter experts, who spent time expanding on key concepts and the ever-changing nature of fragmented MP4 and the MPEG-DASH ratification process.
The full white paper can be found here.
[Addition: Adobe and Microsoft have both published blog posts, outlining their support for fMP4 and mentioning reasons for working together: Adobe's Kevin Towes blog post Microsoft's Chris Knowlton blog post]
Proponents say that the Common File Format (CFF) and Common Encryption (CENC) scheme will represent two important steps toward large-scale online video distribution via adaptive delivery of fragmented elementary streams.
Since CFF can also be used outside of the bounds of UltraViolet, significant interoperability may also exist between UltraViolet disc-based playback and online video platforms, in much the same way that the DVD Forum’s published specifications for DVD playback guaranteed interoperability between DVD players. It’s not out of bounds to think of CFF as the DVD standard for the web.
To get a better understanding of the power of fragmented MP4, first look at the sidebar in the white paper on "combinatorial complexity" for which Netflix contributed a real-world example. Even without CFF and CENC, Netflix is proving the case that fMP4 scales much better than the HLS approach (with a far lower asset management impact).
The white paper has been several months in the making, starting first as separate concepts by two key companies in the streaming space: Adobe Systems and Microsoft Corporation. Each has their proprietary solutions, but both are committed to seeing fragmented MP4 (fMP4) offer a potentially viable alternative to legacy streaming solutions.
After several meetings, both companies chose to jointly work with Transitions to create a white paper noting the benefits of fMP4 and, to a slightly lesser extent, the potential benefits of MPEG-DASH (a proposed standardization of dynamic streaming over HTTP that I mentioned in a prior blog post).
Special thanks to Microsoft and Adobe for providing financial resources and access to subject-matter experts, who spent time expanding on key concepts and the ever-changing nature of fragmented MP4 and the MPEG-DASH ratification process.
The full white paper can be found here.
[Addition: Adobe and Microsoft have both published blog posts, outlining their support for fMP4 and mentioning reasons for working together: Adobe's Kevin Towes blog post Microsoft's Chris Knowlton blog post]
Posts
10 comments:
Hi Tim,
thanks for sharing this information. Would I be reading the near future correctly if I make the assumption that today the best HTML5 can offer in terms of standardization of video delivery and protection is a whitepaper?
Also any idea what level of momentum is behind this whitepaper?
Many thanks,
Stephen Bennett
Steve, take a look at my previous blog post to understand how this fits into HTML5 as DASH isn't as much an HTML5 approach as a common file / format approach (via XML):
http://workflowed.blogspot.com/2011/11/dash-of-this-dash-of-that.html
I've also updated this blog post, noting Adobe's and Microsoft's support for fMP4.
It's appears to be worst than I thought. We are back in the realm of whitepapers, nothing concrete.
Steve I wouldn't worry too much, there are some quite good existing methods to stream video online, DASH is just a potential next one hence it being at this early stage.
One thing that jumped out at me though Tim, was your continuous referring to HLS as "proprietary". What about it is proprietary?
Seems blatantly obvious to me this is part of the overall goal of the paper, to discredit HLS in favour of Adobe and Microsoft approaches (which IMO are much more deserving of the label "proprietary"; where are the open-source solutions for them?). Anyway, assuming DASH actually is well-done, and is an open standard, it seems to be shaping up well, certainly one to keep an eye on.
Nick, thanks for the comments; I enjoyed reading through your testing of HLS vs HDS on your blog (http://rdkls.blogspot.com/2011/12/benchmarking-adobe-hds.html)
In terms of proprietary, and the use of the term, it's strictly to differentiate standards-based versus proprietary-based approaches.
Since HLS (Apple's HTTP Live Streaming) isn't true MPEG-2 Transport Stream (M2TS) it's proprietary, meaning it needs something other than a standard to operate. While the M2TS segments are themselves compliant, the need for the m3u8 proprietary manifest keeps it from being implemented in a traditional M2TS broadcast environment.
HDS and Smooth Streaming are also proprietary, at least for the next bit until DASH is ratified; like Apple, the Adobe solution has been a de facto standard (read, proprietary). Microsoft's Smooth Streaming is a bit further along the proprietary-standards continuum.
Both HDS and Smooth Streaming use the standard ISO container identified in parts 12 and 14 (MP4) and, while both approach the segmenting differently, they use the same time-code / time stamping approach that's made its way into DASH (and which HLS is capable of, too). Smooth even uses the ISMV container.
In the end, the reason for calling out the proprietary nature of HLS is to point out that DASH has room in it for M2TS, just not with the proprietary baggage that Apple has added on to its flavor of M2TS.
Make sense?
Not everyone agrees with me, including a good friend and colleague, Jan Ozer, as noted in his StreamingLearningCenter blog post (http://streaminglearningcenter.com/blogs/apple-to-adobe--microsoft-with-friends-like-you-who-needs-enemies.html) but I think we're way overdue for a move from proprietary to standards-based adaptive streaming over HTTP.
Hello
could you please tell me, do you know any software I can use to create mpeg dash content?
We need in our company such content to test our software but it is very hard to find
thank you
At the moment, since the standard was only recently ratified, no commercial tools exist. Should change in next few weeks, though.
The white paper linked in the first sentence of the post is full of false statements and exudes a clear anti-HLS bias.
For example, on the topic of "combinatorial complexity", the white paper claims that with HLS you would need to create a muxed stream for every single possible combination of audio + video. That is patently false: HLS can just as well create individual assets with only a video track, or only an audio track, and leave it up to the manifest / client to decide on a specific combination to request and play back.
This means that there are not 4000 different sets of streams to manage, that there is no difference on the caching performance on edge servers, etc...
That is just a completely false premise that flows through the entire white paper and in your blog post.
I guess it's unsurprising that Microsoft and Adobe would try to promote their preferred streaming solution against Apple's, but it's disappointing to see a false debate based on falsehoods rather than an analysis of the real technical merits of each solution.
Thanks for the feedback, Hugo. It's not an HLS bias any more than it's a Smooth bias, etc. Here's why:
At the time of the white paper's writing, the HLS "Pantos Spec" (which is not a standard, since it's still in draft form this many years later) was incapable of doing what you are describing in late 2014. In other words, it could not do "late binding" and required many many permutations, which leads to combinatorial complexity.
The reason that HLS is now capable of this "late binding" is thanks to the work done by the MPEG DASH committee, as well as a few of its members including Adobe, Apple, and Microsoft. The work was based on the concept of "late binding" for fragmented MP4, which is what everyone in the market uses besides Apple.
The side benefit of it all was that Apple, since it controls the Pantos Spec (and HLS as a whole), was able to implement late binding into HLS. In other words, the standards committee work forced a non-standard (albeit perhaps defacto "standard") in to a position where it needed to respond to the marketplace.
Do I personally think fMP4 is a much more elegant solution than HLS? If HLS continues to rely on MPEG-2 Transport Stream (M2TS) then the answer continues to be yes. It's not a bias, it's an opinion, and yet it's not inaccurate at all...
Tim
Very Nice...!!!You can also checkout our website that provide you lots of services like Live Streaming Solution
,live streaming,real time audience and many more services are there.for more you can also visit us i.e mangomolo.com
Post a Comment