Re: [MSE] Appending URLs

Hi Duncan,

Comments inline...

On Fri, Jun 15, 2012 at 4:06 AM, Duncan Rowden <Duncan.Rowden@bbc.co.uk>wrote:

> 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.
>
The reason I was suggesting the transfer time is because the user agent may
want to defer or rate limit the download. I thought it might be useful to
reflect this fact to the application by indicating how much time the UA
actually spent trying to download the content.


> ****
>
> **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.
>
Providing the HTTP code & # of bytes seems good to me. I'm not sure I
understand the difference between a reason string and an "error message
body". Could you elaborate please?


> ****
>
> **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.
>
The reason I was suggesting timing was to compensate for delays
intentionally introduced by the UA. For example if memory is getting a
little tight, the UA may decide to stop reading from the socket for a
little while until the timeline has moved far enough forward to evict some
old data. An adaptation algorithm would need to know that this is happening
so that it didn't think that the delays actually reflected very low
connection bandwidth.

It might be that I am unnecessarily coupling append rate limiting with the
actual download. It just seemed like a simple way to address two problems
with one solution.


> ****
>
> **4)      **Would adding an extra value to the media.networkState work
> for this?
>
I hadn't thought about this before, but it does seem like NETWORK_IDLE and
NETWORK_LOADING could be used to track this. Since we can have appends
happening on different source buffers at the same time, we probably should
make this a per SourceBuffer networkState and specify events that fire on
transitions between these two states.

Thanks for the feedback.

Aaron

*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.
>