[whatwg] Video : Slow motion, fast forward effects

[WeBMartians]

The big VoDS (Broadbus/Motorola, SeaChange, Arroyo...) do not offer audio when the play rate is anything other than +1.0.
________________________________
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Simon Fraser
Sent: Thursday, 2008 August 07 18:52
To: Charles Iliya Krempeaux
Cc: Biju Gm at il; Dave Singer; whatwg at lists.whatwg.org; Chris Double; Ian Hickson; Jonas Sicking
Subject: Re: [whatwg] Video : Slow motion, fast forward effects

On Aug 7, 2008, at 12:23 PM, Charles Iliya Krempeaux wrote:
	Hello,
	On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking <jonas at sicking.cc> 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 <ian at hixie.ch> wrote:
					 On Thu, 7 Aug 2008, Biju Gm at il wrote:
					 On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson <ian at hixie.ch> 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