On Fri, Nov 14, 2008 at 1:56 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > There were 81 e-mails on the topic of looping audio and video. > > I haven't included them here because they were mostly redundant. However, > I read them all, and it seems that the use cases and feedback boiled down > to these points: > > 1. Feedback: Simplify the API where possible; in particular start/end/ > loopStart/loopEnd and so on. > > 2. Use case: looping complete tracks of background audio or video without > glitches. > > 3. Use case: playing a track starting at a particular location without > using script that waits for the media to load. > > 4. Use case: playing different media segments with only one HTTP request. > > To address point 1 I've removed all those attributes and related APIs. > > To address point 2 I've added a single attribute "loop", which, when > set, causes the UA to loop back to time=0 when the clip ends. > > To address point 3 I would like us to consider using recently begun > work relating to fragment identifiers for media content. I have edited > the spec so that it defers to the fragment identifier or any metadata > in the resource, but I expect we will have to further tweak this. > > To address point 4 I would like to rely on a more generic solution > that also addresses this for CSS, images, etc. This could be jar:, or > it could me a MIME multipart solution, or offline caching, or data: > URLs, or something else. However, I think this transcends the media > API and therefore I haven't added anything specifically in this API to > deal with it. > > If I have missed a key point, please do let me know. It's quite > possible that I missed something when reading this thread as it was > quite long and had a lot of repetition.
I think this is great news and agree with the solutions. For point 4 I would actually question the need to have the different byte ranges be delivered in one HTTP request. If this is for playback, there is plenty of time while the first fragment is playing to request and receive the second etc. It's like a playlist of fragments. But if the application really needs to receive different byte ranges in one go, MIME multipart does sound like a good solution. Regards, Silvia.
