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

Re: Media Source draft proposal

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 19 Apr 2012 17:24:57 -0700
Message-ID: <4F90ACD9.5000003@jumis.com>
To: robert@ocallahan.org
CC: Maciej Stachowiak <mjs@apple.com>, Aaron Colwell <acolwell@google.com>, public-html@w3.org, Adrian Bateman <adrianba@microsoft.com>, Mark Watson <watsonm@netflix.com>
On 4/19/2012 4:45 PM, Robert O'Callahan wrote:
> On Fri, Apr 20, 2012 at 6:58 AM, Maciej Stachowiak <mjs@apple.com 
> <mailto:mjs@apple.com>> wrote:
>     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
> I actually think those are fairly well separated from this proposal. 
> This proposal is all about manipulating the data that goes into a 
> decoder; WebRTC and the Audio WG are all about manipulating decoded 
> data. The latter two need to be carefully coordinated, but this doesn't.

Their creation was well separated. Now that they're relatively stable, 
it's a good time to coordinate.

Web Audio needs reliable buffering otherwise it requires too much 
decoded information to be stored in ram.
Audio and MediaStream APIs are may allow for audio post-processing of 
Encrypted Media. Timing attacks may be an issue.

Use case: Bob turns on his Camera enabled TV and connects to Alice on a 
secure channel; Bob runs a filter on Alice's audio stream to reduce 
background noise so he can better hear the conversation.
Alice is running a secure mobile phone which handles encryption via 
hardware acceleration with encryption keys isolated from the OS.

Technical examples:

Web Audio and Media Source overlap:

"Creates an AudioBuffer given the audio file data contained in the 
ArrayBuffer. The ArrayBuffer can, for example, be loaded from an 
XMLHttpRequest with the new responseType and response attributes"

"Asynchronously decodes the audio file data contained in the 
ArrayBuffer. The ArrayBuffer can, for example, be loaded from an 
XMLHttpRequest with the new responseType and response attributes. Audio 
file data can be in any of the formats supported by the audio element."

void sourceAppend(in DOMString id, in Uint8Array data);
"Segments can be appended in pieces"
"[A segment is a] sequence of bytes that contain packetized & 
timestamped media data"

As a general pipeline issue, the worker processing of the MediaStream 
Processing API is also relevant.

Where the Audio API has AudioProcessingEvent exposing buffers to the 
main thread, the MediaStream Processing API has ProcessMediaEvent only 
exposed to worker threads, which may be relevant to the Encrypted Media 

WebRTC does not currently specify encryption techniques beyond requiring 
that "configuration information should always be transmitted using an 
encrypted connection."
Content protection seems to be a reasonable item to consider.

Note that the WebRTC reference implementation includes hooks to 
"external encryption":

Received on Friday, 20 April 2012 00:25:23 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:51 UTC