[whatwg] Remove addCueRange/removeCueRanges

[Dr. Markus Walther]

Hi,

> 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.

OK. That would be welcome - although there could be syntactic problems
as where to place fragment parameters.

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

Yes, on Apple's Safari at the time. I had a working prototype which now
longer works.

>>> 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 agree regarding 'start'. W.r.t. 'end', the difference is quite simple
IMHO: when treated as a declarative description as to where audio has to
stop, it is up to the UA to implement it correctly (there could be some
friendly browser competition as to who is most accurate...). I see no
practical reason why this could not be done sample-accurately for media
types such as 16-bit PCM WAVE that support sample-accurate work.

On the other hand, 'currentTime' has no such semantics. So you would be
looking at a bewildering array of factors influencing temporal
resolution, including JS & machine speed, and you could not make any
guarantees to your customer. In speech applications, sub-millisecond
resolution matters as to whether you hear an audible artifact or not. If
your task would be, say, to remove such artifacts from the signal, a
'currentTime'-based solution in all likelihood would not give
reproducible results.

 I doubt the previous implementations of "start" and
> "end" gave you a 3 sample accurate resolution even for wav files.

'end' was quite inaccurate for Safari, but this may be due to a
buffering  issue - to this day, Safari's audio latency when doing
something like "onmouseover='audio.play();" is much higher than Mozilla
Firefox.

So, to my mind it seems a solvable UA implementation issue, not a
problem with semantics.

Kind regards,
-- Markus
_________________________________________
SVOX AG, Baslerstr. 30, CH-8048 Zürich, Switzerland
Dr. Markus Walther, Software Engineer Speech Technology
Tel.: +41 43 544 06 36
Fax: +41 43 544 06 01
Mail: walther at svox.com



This e-mail message contains confidential information which is for the
use of the addressee(s) only. Please notify the sender by return e-mail
or call us immediately, if you erroneously received this e-mail.