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

RE: [MSE] Appending URLs

From: Duncan Rowden <Duncan.Rowden@bbc.co.uk>
Date: Mon, 18 Jun 2012 11:40:18 +0100
Message-ID: <124049A7728972469B1F2B326E65B5883BC6B7@bbcxues48.national.core.bbc.co.uk>
To: Aaron Colwell <acolwell@google.com>
CC: <public-html-media@w3.org>
Hi Aaron,

 

Comments inline:

 

From: Aaron Colwell [mailto:acolwell@google.com] 
Sent: 15 June 2012 22:15
To: Duncan Rowden
Cc: public-html-media@w3.org
Subject: 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.

 

[DR] Seems reasonable to me

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?

 

[DR] I understand the reason string to be the standardised text that comes with an http code (e.g. 404  Not Found), but I'm sensing here that we meant the same thing.

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.

 

[DR] Thanks for explanation. Seems like a good suggestion

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.

 

[DR] I agree

 

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. 

 

 


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.
					
Received on Monday, 18 June 2012 10:40:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:56 UTC