Bug 16998 - Change sourceAppend() to take a URL and optional range parameters
Summary: Change sourceAppend() to take a URL and optional range parameters
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P1 normal
Target Milestone: ---
Assignee: Aaron Colwell (c)
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-08 18:21 UTC by Aaron Colwell (c)
Modified: 2012-09-21 22:33 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Colwell (c) 2012-05-08 18:21:47 UTC
Currently sourceAppend() allow media data to be passed in via a Uint8Array. In most cases it is completely unnecessary for JavaScript to have access to the actual binary data. I am proposing that the signature to sourceAppend() be changed to the following:

void sourceAppend(in DOMString id, in DOMString url, optional long long start, optional long long end)

This would avoid the need for JavaScript to fetch data via XHR and would allow the browser to utilize its resource fetching and caching subsystems more effectively. Dynamically created media data could still be generated by JavaScript if need be and passed in through Blob urls.

sourceappenddone & sourceappenderror events would also be needed to signal when appending has completed or encountered an error.

The optional start & end parameters are there to allow a subset of the resource to be fetched.
Comment 1 Philip Jägenstedt 2012-05-10 14:24:34 UTC
This is a welcome change, since it also means that the data doesn't have to reside on the ECMAScript heap, where out-of-memory can't be handled gracefully.

Is end inclusive or exclusive? The HTTP Ranges header has start and end inclusive, which is something I've seen mistakes with in test cases at Opera.
I'd suggest using an unsigned length parameter instead of end, since that's less prone to mistakes.
Comment 2 Aaron Colwell (c) 2012-05-10 15:21:28 UTC
(In reply to comment #1)
> This is a welcome change, since it also means that the data doesn't have to
> reside on the ECMAScript heap, where out-of-memory can't be handled gracefully.

Agreed. I also figured that this change would allow the UA to regulate the append rate so it can have a little more control over the memory usage.

> 
> Is end inclusive or exclusive? The HTTP Ranges header has start and end
> inclusive, which is something I've seen mistakes with in test cases at Opera.
> I'd suggest using an unsigned length parameter instead of end, since that's
> less prone to mistakes.

Good point. I like the idea of using a length parameter instead.
Comment 3 Silvia Pfeiffer 2012-06-15 01:19:53 UTC
"start" and "end" are byte ranges, right? Otherwise I would suggest using temporal media fragment URIs.
Comment 4 Aaron Colwell (c) 2012-06-15 01:24:32 UTC
(In reply to comment #3)
> "start" and "end" are byte ranges, right? Otherwise I would suggest using
> temporal media fragment URIs.

Yes. start & length's units are bytes. Based on Philip J's comment above (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16998#c1), the method will specify a length instead of an end offset.
Comment 5 Yang Sun 2012-06-18 03:02:10 UTC
  I am ok with the suggetion of length instead of end,
but I think it is more complex for compute start-end range using (start,length) model.
  In (start,end) model, I only need to make sure the next start will not overlap with previous end, but in (start,length) model, we need 1 extra step, to compute the end of previous end using start+length-1, then make sure the current start does not overlap with it.

(In reply to comment #1)
> This is a welcome change, since it also means that the data doesn't have to
> reside on the ECMAScript heap, where out-of-memory can't be handled gracefully.
> 
> Is end inclusive or exclusive? The HTTP Ranges header has start and end
> inclusive, which is something I've seen mistakes with in test cases at Opera.
> I'd suggest using an unsigned length parameter instead of end, since that's
> less prone to mistakes.
Comment 6 Aaron Colwell (c) 2012-06-18 18:15:52 UTC
(In reply to comment #5)
>   I am ok with the suggetion of length instead of end,
> but I think it is more complex for compute start-end range using (start,length)
> model.
>   In (start,end) model, I only need to make sure the next start will not
> overlap with previous end, but in (start,length) model, we need 1 extra step,
> to compute the end of previous end using start+length-1, then make sure the
> current start does not overlap with it.

I'm not sure I completely follow your concern. I agree that the UA must do the extra computation end = start + length - 1, but I think this is relatively minor compared to people incorrectly computing end on their own. In most of the work demo I've done with the Media Source API, I've usually had a starting offset and a length and then had to convert it into a proper Range header. Like many others, I did this incorrectly the first time I tried it. I think using length will prevent many others from making the same mistake.
Comment 7 Adrian Bateman [MSFT] 2012-06-19 15:54:30 UTC
Discussed in telcon: http://www.w3.org/2012/06/19-html-media-minutes.html#item06