Re: [whatwg] Remove addCueRange/removeCueRanges
On Mon, 17 Aug 2009, Max Romantschuk wrote: Silvia Pfeiffer wrote: 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. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. A reasonable forward-compatible solution would be to allow (by whichever method settled upon) millisecond-resolution to be specified for setting/resetting from where/to play the clip. User agents could implement a best-effort, not needing to guarantee any specific resolution at this point. As far as I can tell, HTML5 already allows this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove addCueRange/removeCueRanges
At 0:49 +1200 23/08/09, Robert O'Callahan wrote: On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk mailto:m...@romantschuk.fim...@romantschuk.fi wrote: Silvia Pfeiffer wrote: 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. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. Those tricks aren't that hard, at least for Theora; we do them in Firefox. It's very easy in QuickTime or MP4. Timestamps of the frames can be sample accurate, so you decode the right frame, and trim the result. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Remove addCueRange/removeCueRanges
On Sat, Aug 22, 2009 at 7:37 AM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Xiph has spent a long time on developing libraries that make seeking simple for Ogg Theora/Vorbis and Firefox has the advantage of using these libraries. In fact we had to write this support ourselves. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Remove addCueRange/removeCueRanges
On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk m...@romantschuk.fi wrote: Silvia Pfeiffer wrote: 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. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. Those tricks aren't that hard, at least for Theora; we do them in Firefox. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Remove addCueRange/removeCueRanges
On Sat, Aug 22, 2009 at 10:49 PM, Robert O'Callahanrob...@ocallahan.org wrote: On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk m...@romantschuk.fi wrote: Silvia Pfeiffer wrote: 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. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. Those tricks aren't that hard, at least for Theora; we do them in Firefox. Xiph has spent a long time on developing libraries that make seeking simple for Ogg Theora/Vorbis and Firefox has the advantage of using these libraries. I'm sure it's possible with other codecs / containers, too. But it's not trivial. Also, I still doubt that for lossy codecs a 3 sample accurate resolution on audio can be provided reliably every single time. I would be delighted to be proven wrong. Silvia.
Re: [whatwg] Remove addCueRange/removeCueRanges
Silvia Pfeiffer wrote: 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. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. A reasonable forward-compatible solution would be to allow (by whichever method settled upon) millisecond-resolution to be specified for setting/resetting from where/to play the clip. User agents could implement a best-effort, not needing to guarantee any specific resolution at this point. Regards, Max Romantschuk -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Remove addCueRange/removeCueRanges
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: walt...@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.
Re: [whatwg] Remove addCueRange/removeCueRanges
Max Romantschuk wrote: I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. Quick feedback: I completely agree it is illusory to guarantee sample-accuracy accross codecs, and never meant to imply such a requirement. The much weaker goal I would propose is to support at least one simple lossless audio format in this regard (I am not qualified to comment on the video case). Simple means 'simple to generate, simple to decode', and PCM WAVE meets these requirements, so would be an obvious candidate. For that candidate at least I think one could give sample-accurate implementations of subinterval selection - tons of audio applications demonstrate this is possible. -- 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: walt...@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.
Re: [whatwg] Remove addCueRange/removeCueRanges
Dr. Markus Walther wrote: The much weaker goal I would propose is to support at least one simple lossless audio format in this regard (I am not qualified to comment on the video case). Simple means 'simple to generate, simple to decode', and PCM WAVE meets these requirements, so would be an obvious candidate. For that candidate at least I think one could give sample-accurate implementations of subinterval selection - tons of audio applications demonstrate this is possible. That is a good point, and having done sample editing it's true that for applications like speech sub-millisecond resolution makes sense. The problem becomes what makes sense as the chosen unit. Time is the intuitive option, but with samples we have aliasing issues when trying to match a particle time offset to a sample offset. Allowing microseconds would be a possible solution, but I doubt any authors would like to think in the terms of microseconds. But on the other hand if samples are the unit of choice that instantly ties the interval scale to the file. If an author wants to halve his bandwidth usage by halving the sample rate for PCM or FLAC (comparable to increasing the compression for a lossy format) all the interval information has to be redone. (The offsets will point to the wrong parts of the file at a different sample rate.) Time based intervals would not have this issue. The problem becomes even more convoluted when taking video into account. Then there are multiple permutations of sample rates and frame rates to take into account. It would of course be an option to have a sample-accurate option for audio only, but would this really be implemented in user agents? Authors will likely not adopt any solution poorly supported in user agents and stick to existing plugin solutions like Flash. Regards, Max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Remove addCueRange/removeCueRanges
On Thu, 13 Aug 2009, Philip Jägenstedt wrote: We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. I've commented out the cue range feature. On Thu, 13 Aug 2009, Dr. Markus Walther wrote: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. AFAIK, when dropping support for 'start' and 'end' attributes it was noted on this list that cue ranges would provide a replacement to dynamically select, say, a 3-second range from a 1-hour audio source. So, if cue ranges will indeed be dropped, could browser vendors and standards people consider putting 'start' and 'end' back in, just like Safari had it for a while (albeit buggy)? Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) Just my 2c. There's not going to be a way to do subrange selection in this version of the API. It'll be one of the first things to come back, I expect. As was pointed out, there are many notes in the spec source of things to bring to the next version of the spec. If anyone wants to maintain an off-spec copy of these annotations, please feel free to do so. On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: I am actually hoping that we could attach callbacks to time-aligned text segments which makes the whole approach to cue ranges more generic. Hopefully I will have a demo of this within the next few weeks, so we can discuss further. I don't really think we want to tie callbacks of this nature to text -- in fact, the two are likely to be almost mutally exclusive features: you would need callbacks when you're not using timed text solutions, so that you can do your own. Another example would be keeping a slide show in sync with an audio track, where each slide has a cue range -- this has nothing to do with text tracks, and you wouldn't want to have to generate a fake text track file just to get the hooks to do this when all your data about slide timings is in script already. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 4:08 AM, Philip Jägenstedtphil...@opera.com wrote: On Fri, 14 Aug 2009 12:48:59 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Waltherwalt...@svox.com wrote: Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@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,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // 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? To my knowledge/experience, there is nothing special about data URIs. Any differences in how they work with the DOM interface or media fragments are more than likely implementation bugs. The problem is that you can't use fragment identifiers with data-URIs. For example data:text/plain,hello world#frag Represents a text/plain document with the contents: hello world#frag It does not represent the 'frag' part of a document with the text 'hello world'. / Jonas
Re: [whatwg] Remove addCueRange/removeCueRanges
On Sat, 15 Aug 2009 08:47:32 +0200, Jonas Sicking jo...@sicking.cc wrote: The problem is that you can't use fragment identifiers with data-URIs. For example data:text/plain,hello world#frag Represents a text/plain document with the contents: hello world#frag It does not represent the 'frag' part of a document with the text 'hello world'. Actually, I think that is false (and a bug in Firefox). At the time the data URI RFC was written RFC 2396 was still the URI RFC and there fragment identifiers were not a formal part of the URI syntax but rather something you could append to any URI during retrieval operations, which is clearly what data URIs are for. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 11:58 PM, Anne van Kesterenann...@opera.com wrote: On Sat, 15 Aug 2009 08:47:32 +0200, Jonas Sicking jo...@sicking.cc wrote: The problem is that you can't use fragment identifiers with data-URIs. For example data:text/plain,hello world#frag Represents a text/plain document with the contents: hello world#frag It does not represent the 'frag' part of a document with the text 'hello world'. Actually, I think that is false (and a bug in Firefox). At the time the data URI RFC was written RFC 2396 was still the URI RFC and there fragment identifiers were not a formal part of the URI syntax but rather something you could append to any URI during retrieval operations, which is clearly what data URIs are for. Would be great to get clarification on that. Safari seems to behave the same (though not if you modify a fragment on a already entered uri) / Jonas
Re: [whatwg] Remove addCueRange/removeCueRanges
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,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? See http://www.w3.org/2008/01/media-fragments-wg.html and http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Examples Did you look at these yourself? I couldn't find something that approaches a spec of comparable quality to WHATWG in these pages. Is there any provision for the dynamic case, where you want to change the media fragment after it has been loaded, with zero server interaction, and working for data URIs as well? Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) There has been much discussion about audio canvas API:s and I trust this could fit into that scope. As the 'inventor' of the term, I am of course familiar with the discussion - here I was merely adding an item to the wishlist. View source at http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video and search for v2 and you'll find some of these ideas. Could these be lifted from hidden HTML comments to something with better visibility somehow? -- Markus
Re: [whatwg] Remove addCueRange/removeCueRanges
Silvia, 2009/8/13 Dr. Markus Walther walt...@svox.com: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. Not quite. You can always use the video.currentTime property in a javascript to directly jump to a time offset in a video. And in your javascript you can check this property until it arrives at your determined end time. So, there is a way to do this even now. How can polling approach that somehow monitors currentTime meet any halfway-decent accuracy requirements? E.g. to be accurate to 1-3 samples at 22050 Hz sampling frequency? I doubt your approach could fulfill this. To my mind, the current turn of events suggests simply to allow start/end attributes back into the WHATWG spec, eased by the fact that there were already browser implementations of it. -- Markus
Re: [whatwg] Remove addCueRange/removeCueRanges
2009/8/14 Dr. Markus Walther walt...@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,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // 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. All you need to do is: video src=http://www.example.com/movie.ogv#t=12.33,21.16; or audio src=http://www.example.com/sound.oga#t=0.54328,0.72636; Or if you really wanted to do it in javascript, you'd only need to reload the resource: video.src = http://www.example.com/movie.ogv#t=12.33,21.16;; or audio.src = http://www.example.com/sound.oga#t=0.54328,0.72636;; That would have the same effect as setting start and end time. Regards, Silvia.
Re: [whatwg] Remove addCueRange/removeCueRanges
Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@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,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // 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. 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... -- Markus
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Waltherwalt...@svox.com wrote: Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@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,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // 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.
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, 14 Aug 2009 10:28:14 +0200, Dr. Markus Walther walt...@svox.com wrote: 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 happened in November 2008: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017157.html This is the specific spec change: http://html5.org/tools/web-apps-tracker?from=2400to=2401context=10 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,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? See http://www.w3.org/2008/01/media-fragments-wg.html and http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Examples Did you look at these yourself? I couldn't find something that approaches a spec of comparable quality to WHATWG in these pages. Implementation (should) always comes before spec and there is no implementation yet. Given the simplicity of the most basic syntax, I am not at all worried by the lack of a proper spec yet. Is there any provision for the dynamic case, where you want to change the media fragment after it has been loaded, with zero server interaction, and working for data URIs as well? You can change the fragment with scripts at any time you want followed by load()/play(). data URI's with fragments are perfectly valid as far as I can see. The rest is up to proper implementation (caching). Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) There has been much discussion about audio canvas API:s and I trust this could fit into that scope. As the 'inventor' of the term, I am of course familiar with the discussion - here I was merely adding an item to the wishlist. View source at http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video and search for v2 and you'll find some of these ideas. Could these be lifted from hidden HTML comments to something with better visibility somehow? I agree that would be nice, perhaps on http://wiki.whatwg.org/ ? -- Philip Jägenstedt Opera Software
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, 14 Aug 2009 10:42:50 +0200, Dr. Markus Walther walt...@svox.com wrote: Silvia, 2009/8/13 Dr. Markus Walther walt...@svox.com: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. Not quite. You can always use the video.currentTime property in a javascript to directly jump to a time offset in a video. And in your javascript you can check this property until it arrives at your determined end time. So, there is a way to do this even now. How can polling approach that somehow monitors currentTime meet any halfway-decent accuracy requirements? E.g. to be accurate to 1-3 samples at 22050 Hz sampling frequency? I doubt your approach could fulfill this. To my mind, the current turn of events suggests simply to allow start/end attributes back into the WHATWG spec, eased by the fact that there were already browser implementations of it. Highly accurate looping or fragment selection is something that requires a lot of work on the implementation side. I don't have a particular aversion to .start/.end, but think it would be wise to wait for implementor experience before (re)introducing any of start/end, addCueRange/removeCueRanges or a timed text API. Whatever the spec says before that is likely to be wrong. -- Philip Jägenstedt Opera Software
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, 14 Aug 2009 12:48:59 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Waltherwalt...@svox.com wrote: Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@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,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // 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? To my knowledge/experience, there is nothing special about data URIs. Any differences in how they work with the DOM interface or media fragments are more than likely implementation bugs. -- Philip Jägenstedt Opera Software
Re: [whatwg] Remove addCueRange/removeCueRanges
I agree with this assessment. Please note that at this stage this is my personal opinion, since I haven't discussed it with other Mozilla developers yet. Regards, Silvia. On Thu, Aug 13, 2009 at 6:31 PM, Philip Jägenstedtphil...@opera.com wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. -- Philip Jägenstedt Opera Software
Re: [whatwg] Remove addCueRange/removeCueRanges
Hi, please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. AFAIK, when dropping support for 'start' and 'end' attributes it was noted on this list that cue ranges would provide a replacement to dynamically select, say, a 3-second range from a 1-hour audio source. So, if cue ranges will indeed be dropped, could browser vendors and standards people consider putting 'start' and 'end' back in, just like Safari had it for a while (albeit buggy)? Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) Just my 2c. --Markus Philip Jägenstedt wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary.
Re: [whatwg] Remove addCueRange/removeCueRanges
On Thu, 13 Aug 2009 14:34:55 +0200, Dr. Markus Walther walt...@svox.com wrote: Hi, please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. AFAIK, when dropping support for 'start' and 'end' attributes it was noted on this list that cue ranges would provide a replacement to dynamically select, say, a 3-second range from a 1-hour audio source. So, if cue ranges will indeed be dropped, could browser vendors and standards people consider putting 'start' and 'end' back in, just like Safari had it for a while (albeit buggy)? The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. It will be something like http://www.example.com/movie.mov#t=12.33,21.16 See http://www.w3.org/2008/01/media-fragments-wg.html and http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Examples Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) There has been much discussion about audio canvas API:s and I trust this could fit into that scope. View source at http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video and search for v2 and you'll find some of these ideas. -- Philip Jägenstedt Opera Software
Re: [whatwg] Remove addCueRange/removeCueRanges
At 10:31 +0200 13/08/09, Philip Jägenstedt wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. We reluctantly agree. We suggested a re-think a year ago, and though that got some support, it didn't get the editor's support. We do not have an implementation of the current spec., and don't expect to. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015284.html We do think the functionality is important, and are saddened to agree with this proposal, however. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 3:31 AM, David Singersin...@apple.com wrote: At 10:31 +0200 13/08/09, Philip Jägenstedt wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. We reluctantly agree. We suggested a re-think a year ago, and though that got some support, it didn't get the editor's support. We do not have an implementation of the current spec., and don't expect to. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015284.html We do think the functionality is important, and are saddened to agree with this proposal, however. I am actually hoping that we could attach callbacks to time-aligned text segments which makes the whole approach to cue ranges more generic. Hopefully I will have a demo of this within the next few weeks, so we can discuss further. Regards, Silvia.
Re: [whatwg] Remove addCueRange/removeCueRanges
Hi Markus, 2009/8/13 Dr. Markus Walther walt...@svox.com: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. Not quite. You can always use the video.currentTime property in a javascript to directly jump to a time offset in a video. And in your javascript you can check this property until it arrives at your determined end time. So, there is a way to do this even now. I agree that this is rather crude and not integrated, which is why I am working on a callback addition to the itext specification. However, the situation is not as bad as you may think. Also, I don't think keeping the cueRange specification in the spec will change the current situation with browser vendors not implementing it. So, your needs won't be satisfied no matter whether it says or not. We could decide to keep the cueRange proposal in the spec as a reminder that there is still a problem to be solved. However, since we have removed such reminders elsewhere in the spec (e.g. the need for a baseline codec), it doesn't seem to make much sense to me to keep it as a reminder. Just my 2c. :-) Cheers, Silvia.
