Re: [MSE] Appending URLs

If we are going to provided download progress information for adaptive streaming though this API, then ideally it should have the following properties:
- progress information should be associated with the URL/byte range
- the HTTP response time should be available and separated from any time spend doing redirections, CORS pre-flights etc.
- the bytes received information should be provided in the form of triples (reception start, reception end, bytes received) so that the script does not average over time periods where the client was (deliberately) not receiving data (or, equivalently, we could have reception start/stop/progress events that come with timestamps).

We could provide this information in this API, or we could adapt the Web Performance Resource Timing [1] work to this purpose.

…Mark

[1] http://w3c-test.org/webperf/specs/ResourceTiming/

On Jun 18, 2012, at 12:04 PM, Aaron Colwell wrote:

comments inline..

On Sun, Jun 17, 2012 at 11:04 PM, Sunyang (Eric) <eric.sun@huawei.com<mailto:eric.sun@huawei.com>> wrote:
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;
[yang] why use length instead end, one more step to compute the boundary is not wise.

[acolwell] Length is used  because end is considered error prone. Just from my own demo experience I've forgotten the -1 in the end = start + length -1 computation several times. I'm sure I'm not alone in this and it seems like a minor thing for the UA to implement so that developers don't have one more thing to remember.


1.      What information should we report via the appenddone event? bytes transferred? duration of transfer ?
[yang] I think it depend on what we need from appendone event, I think the status code is enough. Application only needs to know whether it is successful, will not care bytes, duration etc, that’s my opinion.
But if for online video editing, duration may be needed .

[acolwell] The reason I mentioned bytes and transfer duration, is for the adaptive streaming use case. This information can be used to estimate the available bandwidth.


2.      What information should we report via the appenderror event? HTTP status code? HTTP reason string? # of bytes appended?
[yang] What purpose of report from appenderror event? If only for application callback, the status code is enough, if for user readable text, we may return text. But I think nobody will read the text returned by appenderror, so error code is enough. And I think if the append has error, next append will override the previous part no matter how many bytes are appended, so no need for # of bytes appended.

[acolwell] I don't think it is a safe assumption that the next append will overwrite all the data from the previous append. The number of bytes appended could be useful in determining what got appended and where to start the next append. We definitely need to figure out what state the segment parser should be in after an error occurs. The current API triggers a MEDIA_ERR_DECODE to happen if an append fails because it basically means that there is something wrong with the bytestream. No further appends are allowed after that. In the case of a URL based append the problem could either be a networking error OR a bytestream error. It isn't clear to me whether we want to trigger a MEDIA_ERR_NETWORK if the append has a network problem because there may be ways for the application to recover. Returning the number of bytes successfully appended allows the application to determine what segments were successfully appended and which ones will need to be retried.

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?
[yang] append is used to append media segment to a presentation timeline, right? If for end user review, media segment’s download bytes and duration has no meaning to him at all, the end user always see a complete video. But for video editing or AD publisher, we may need to know the upload progress, rather then download progress.

[acolwell] downloaded bytes & download duration mean a lot to an adaptive streaming application. That is why I'm suggesting them. Periodic updates of this information facilitate bandwidth estimation and may influence what the application decides to append next.