[whatwg] Remove addCueRange/removeCueRanges

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Fri Aug 14 03:48:59 PDT 2009

On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Walther<walther at svox.com> wrote:
> Silvia Pfeiffer wrote:
>> 2009/8/14 Dr. Markus Walther <walther at svox.com>:
>>> Hi,
>>>> The .start/.end properties were dropped in favor of media fragments,
>>>> which the Media Fragments Working Group is producing a spec for.
>>> Who decided this? Has this decision been made public on this list?
>>>> It will
>>>> be something like http://www.example.com/movie.mov#t=12.33,21.16
>>> var audioObject = new Audio();
>>> audioObject.src
>>> ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBAAAAABAAEAIlYAAESsAAACABAAZGF0Yf7///8AAAAA....';
>>> // play entire audio
>>> audioObject.play();
>>> // play (0.54328,0.72636) media fragment
>>> ?????
>> Not in this way. In fact, the new way will be much much simpler and
>> does not require javascript.
> With the code snippet given I was pointing out that it is not obvious
> (to me at least) how the proposed media fragment solution covers data
> URIs. If it is not meant to cover them, it is limited in a way that the
> solution it seeks to replace is not.

I see no reason why they should not be applicable to data URIs when it
is obvious that the data URI is a media file. This has not yet been
discussed, but would be an obvious use case.

BTW: Did the start and end attribute implementations that you refer to
cover the "data" scheme, too?

>> Or if you really wanted to do it in javascript, you'd only need to
>> reload the resource:
> Of course we want to do this dynamically in JavaScript - IMHO it would
> be the norm not the exeception to select fragments based on user input.
> Precomputed fragments are of limited use. I don't quite understand why
> the dynamic case is so often underrepresented in these discussions...

This example from the BBC shows how to dynamically jump to fragments
based on user input by setting the currentTime of the video. I don't
see a difference between using the currentTime and using "start" and
"end". Precision is influenced more strongly by the temporal
resolution of the decoding pipeline rather than the polling resolution
for currentTime. I doubt the previous implementations of "start" and
"end" gave you a 3 sample accurate resolution even for wav files.


More information about the whatwg mailing list