This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
(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.
"start" and "end" are byte ranges, right? Otherwise I would suggest using temporal media fragment URIs.
(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.
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.
(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.
Discussed in telcon: http://www.w3.org/2012/06/19-html-media-minutes.html#item06
Closing this bug and splitting into these following bugs: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18962 https://www.w3.org/Bugs/Public/show_bug.cgi?id=18963 per discussions in: http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0074.html http://www.w3.org/2012/07/31-html-media-minutes.html#item05