Re: [MSE] Appending URLs

Hi Aaron,

I do think this is a good idea, but I am not sure if it is a good idea to do it right away (in this first version).

We know that XHR + appending bytes works, moving to appending Urls is an optimization. My concerns are:
(i) there are some other things that are necessary to make appending Urls work, specifically to ensure the script has enough network performance information to make the rate adaptation decisions
(ii) (you can answer this better than me) it's possible that appendUrls could be much more implementation work than append bytes

I understand that a script could still use XHR and Blob URLs - is this efficient ? I'm not that familiar with blob URLs - can you get one from an XHR without copying the data up to the Javascript layer ? If that is the case, then my concerns are diminished.

The W3C Web Performance group has some good specifications for providing performance information to scripts on HTTP operations performed by the browser. But the information is available to Javascript only after each download is complete - I guess that is as much as you get with XHR…

…Mark

On Jun 14, 2012, at 1:54 PM, Aaron Colwell wrote:

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