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

Re: Media Source draft proposal

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 19 Apr 2012 11:58:53 -0700
Cc: public-html@w3.org, Adrian Bateman <adrianba@microsoft.com>, Mark Watson <watsonm@netflix.com>
Message-id: <B6A75BBC-1C2E-4F45-A60A-7123E9B69676@apple.com>
To: Aaron Colwell <acolwell@google.com>

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.


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
Received on Thursday, 19 April 2012 18:59:27 UTC

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