Re: Media Source draft proposal

It seems to me that this spec has some conceptual overlap with WebRTC, and WebAudio, which both involve some direct manipulation and streaming of media data.

WebRTC: http://dev.w3.org/2011/webrtc/editor/webrtc.html
Web Audio API: https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html

Unfortunately, it seems that each of the three specs (WebRTC, Web Audio, and Media Source) will end up in a different Working Group. I think that the technical relationship among these three specs is more important than the relationship between Media Source and Encrypted Media. I suggest that we may need a Task Force of all three Working Groups to ensure that these specs are aligned and make a coherent whole.

Regards,
Maciej


On Apr 16, 2012, at 1:13 PM, Aaron Colwell 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.
>  
> Aaron Colwell, Google
> Adrian Bateman, Microsoft
> Mark Watson, Netflix