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

: [MSE] Appending URLs

From: Sunyang (Eric) <eric.sun@huawei.com>
Date: Mon, 18 Jun 2012 06:04:09 +0000
To: Aaron Colwell <acolwell@google.com>, "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <9254B5E6361B1648AFC00BA447E6E8C32AEA9352@szxeml545-mbx.china.huawei.com>
See inline

________________________________

Ϊ޹˾ Huawei Technologies Co., Ltd.
[Company_logo]

Phone: +86 25 56622934
Fax: +86 25 56624081
Mobile: +86 13851889004
Email: eric.sun@huawei.com
ַϾ껨101 ΪϾ ʱࣺ210012
Huawei Technologies Co., Ltd.
No 101,Software Avenue, Yuhua District,Nanjing 518129, P.R.China
http://www.huawei.com

________________________________
ʼ丽лΪ˾ıϢڷ͸ַгĸ˻Ⱥ顣
ֹκκʽʹãȫ򲿷ֵй¶ơɢʼ
Ϣ˱ʼ绰ʼ֪ͨ˲ɾʼ
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
: Aaron Colwell [mailto:acolwell@google.com]
ʱ: 2012615 4:55
ռ: public-html-media@w3.org
: [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.
[yang]+1, this is benefitial to control the source rate.


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.

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 ?
[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, thats my opinion.
But if for online video editing, duration may be needed .

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.

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 segments 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.
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?
[yang] Can we selectively download some parts for the media? Yes, I think it is a good idea, we may mark different parts of media as different priority, if bandwidth is bad, we may omit the AD part, but the core video content to prevent damage user experience.

Please let me know what you think.

Aaron





image001.jpg
(image/jpeg attachment: image001.jpg)

Received on Monday, 18 June 2012 06:09:11 UTC

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