W3C home > Mailing lists > Public > public-html@w3.org > April 2012

Re: Media Source draft proposal

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 18 Apr 2012 15:20:20 +1000
Message-ID: <CAHp8n2=GdcR2kxmcV1O4hdZXQOgxY2EeGZb+VuiZ3vUm-zpjkA@mail.gmail.com>
To: Aaron Colwell <acolwell@google.com>
Cc: public-html@w3.org, Adrian Bateman <adrianba@microsoft.com>, Mark Watson <watsonm@netflix.com>
On Tue, Apr 17, 2012 at 6:13 AM, Aaron Colwell <acolwell@google.com> wrote:
> In December, the Media Pipeline Task Force of the Web & TV Interest Group
> sent a note to
> the HTML WG that included a link to three different architectural options
> for supporting
> Adaptive Streaming in HTML5 applications:
> http://lists.w3.org/Archives/Public/public-html/2011Dec/0120.html
> http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes#Architectural_Models
> One model proposes to allow "script to explicitly send the media segments.
> The manifest
> file is processed by script and any adaptation algorithm can be used to
> select the
> individual segments for playback."
> Together, Google, Netflix, and Microsoft have developed a concrete proposal
> that supports
> this scenario. We have updated the proposal in recent weeks based on
> feedback from the
> Web & TV IG and would like to submit the document for consideration by the
> HTML Working
> Group.
> We have uploaded the draft "Media Source" proposal here:
> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
> This document is intended to be a starting point for discussion. We have
> highlighted
> several open issues in the document and there are no doubt other issues. The
> goal of the
> extension specification is to provide additional functionality to HTML5
> media elements
> so that web pages can programmatically feed data into different media
> tracks. One use
> of this feature is to support the adaptive streaming scenario outlined by
> the interest
> group but it isn't the only one. Other scenarios include offline video
> editing (media
> could be read with File API and local processing done on source data),
> seamless playlists,
> and fast "TV-like" channel switching (you donít need to resend init segments
> on changes).
> With the group's agreement, we would like to discuss this proposal in the
> working group
> as part of the HTML.next conversation started last year:
> http://www.w3.org/wiki/HTML/next#Adaptive_Streaming
> Specifically, we think it would be useful for the proposed Media Task Force
> to consider
> this proposal alongside the Encrypted Media proposal. We believe that both
> specifications
> are useful independently and one can be usefully implemented without the
> other. However,
> since they both extend the HTML5 media elements, it is useful for them to be
> considered in
> the same forum to ensure they do not conflict.

If this is non-controversial, I would suggest to just keep it in this
forum and work towards inclusion into HTML asap. I wouldn't want to
delay it by moving it into a TF whose focus is elsewhere. The adaptive
streaming is pretty important stuff that people are asking for
independently of encryption and want to use in particular for live
streaming of HTML5 video, but also to provide more adequate quality
video to the users.

The Encrypted Media TF can discuss and propose changes to this
proposal that are required for encryption purposes, but I do not
believe that it would require a fundamentally different approach to
adaptive streaming.

Received on Wednesday, 18 April 2012 05:21:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:22 UTC