- From: Dr. Markus Walther <walther@svox.com>
- Date: Mon, 17 Aug 2009 11:21:01 +0200
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.
Received on Monday, 17 August 2009 02:21:01 UTC