Re: 答复: [MSE] Appending URLs

comments inline..

On Sun, Jun 17, 2012 at 11:04 PM, Sunyang (Eric) <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.