- From: Aaron Colwell <acolwell@google.com>
- Date: Thu, 14 Jun 2012 13:54:53 -0700
- To: public-html-media@w3.org
- Message-ID: <CAA0c1bCJGzDXEOcUPEMUf8a6G7Le=TkY+=xFPRxwwZ0YHTPvZA@mail.gmail.com>
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. 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; 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 ? 2. What information should we report via the appenderror event? HTTP status code? HTTP reason string? # 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? 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? Please let me know what you think. Aaron
Received on Thursday, 14 June 2012 20:55:23 UTC