On Aug 7, 2008, at 12:23 PM, Charles Iliya Krempeaux wrote:
Hello,
On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking <[EMAIL PROTECTED]>
wrote:
Dave Singer wrote:
At 20:10 +1200 7/08/08, Chris Double wrote:
On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> playbackRate is the right way to do it, but maybe Firefox doesn't
yet
> support it.
So can I assume HTML5 spec also allow playbackRate to be negative
value.
ie to support go backward at various speed....
Yes.
Would you expect the audio to be played backwards too?
I think that's extra credit and optional. As you say, even with
audio coded in independent frames you have to flip the samples,
which is a pain. For audio with forward dependencies, correct
decoding means decoding forwards and then flipping whole chunks of
timeline (though AAC doesn't suffer too badly if you don't do this,
by the way).
Honestly, this seems useless enough that the spec should just say
that when playback is less than 0 sound should be turned off. I'd
hate to see engineers working on this just because "the spec says it
should work that way".
I don't think turning sound off is a good idea.
This feature would be used to implement "scrubing". Like what you
see in Non-Linear Editors... for making movies, etc. (I.e.,
grabbing the "position handle" of the player, and moving it forwards
and backwards through the video, and varying speeds, to find what
you are looking for.)
In those types of applications, the audio is on. And it is
important for usability, for the video editor to hear the sound.
But those applications are not naïvely playing the sound at the
current playback rate; they are grabbing little snippets of audio
samples from the current playhead position, and playing them at normal
rate. I don't think the spec should go into this much detail about
what happens to audio when rate != 1.
Simon
