[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...
http://open.bbc.co.uk/rad/demos/html5/rdtv/episode2/index.html
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.
Regards,
Silvia.
More information about the whatwg
mailing list