RE: [MSE] Appending URLs

Hi Aaron,

 

I agree with altering the sourceAppend() API altered to take in URLs,
which will particularly help out resource constrained devices.

 

As for your questions:

1)      I think appenddone should probably have the bytes transferred
returned, as from an adaptive manifest file you'd usually only know the
average bitrate. I'm not sure duration of transfer is required, as you
can do the timing in JavaScript.

2)      The HTTP code should definitely be in there. Unless you foresee
non-standard reason strings, I don't think this needs to be in there. If
you want more information relayed, maybe adding an error message body
would be more appropriate? If the player doesn't throw away the data
before it reached error (should it do this?), then # of bytes appended
is useful. 

3)      An appendprogress event would be useful for monitoring purposes.
Again the question is if you want to do the timing in JavaScript, or
have the underlying acquirer doing this for you? Passing back how much
data is downloaded is good and where the information is available the
total data size should be passed back too.

4)      Would adding an extra value to the media.networkState work for
this?

 

Duncan

 

From: Aaron Colwell [mailto:acolwell@google.com] 
Sent: 14 June 2012 21:55
To: public-html-media@w3.org
Subject: [MSE] Appending URLs

 

Hi,

 

I wanted to start a discussion about changing the sourceAppend()
signature to take URLs instead of a Uint8Array (Bug 16998
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=16998> ). The primary
motivation here is to avoid pulling the media data up into the
JavaScript layer unnecessarily. Changing to a signature like this also
provides a way for the user agent to control the rate of appending and
potentially improves how effectively it can use its cache.

 

There has been a little bit of discussion in the bug comments and the
current signatures being proposed are shown below.

 

void sourceAppend(in DOMString id, in DOMString url, optional long long
start, optional long long length);

[TreatNonCallableAsNull] attribute Function? onappenddone;
[TreatNonCallableAsNull] attribute Function? onappenderror;

 

If we decide to go the more object oriented path in Bug 17082
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17082> , I'd expect the
id parameter to be dropped from the signature.

 

The application calls sourceAppend() with the URL and optional range
parameters to append data and waits for either the appenddone or
appenderror events to fire before attempting another append. appenddone
signals that the data was successfully appended and appenderror
indicates that the append failed for some reason.

 

For applications that want to generate media data on the fly or modify
it before appending, they can use XHR to fetch the data and BlobBuilders
to stage the modified data. Blob URLs can then be generated and passed
to sourceAppend(). Blob URLs could also be used to handle data received
as Blobs from the WebSockets or File APIs.

 

Here are some open questions I still have about this approach:

1. What information should we report via the appenddone event? bytes
transferred? duration of transfer ?

2. What information should we report via the appenderror event? HTTP
status code? HTTP reason string? # of bytes appended?

3. Should we add a appendprogress event that periodically fires, like
the HTMLMediaElement progress event, that conveys how much data has been
downloaded so far and how much time it has spent actually downloading?

4. The user agent may want to delay or slow down the download because of
memory or bandwidth constraints. Do we want to convey this to the web
application? If so, how?

 

Please let me know what you think.

 

Aaron

 

 

 


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.