[whatwg] Video : Slow motion, fast forward effects

[Peter Kasting]

On Wed, Oct 15, 2008 at 2:08 AM, Ian Hickson <ian at hixie.ch> wrote:

> For example, if Alice uses Browser A, and finds that when rewinding the
> sound isn't played, and thus does a hack that fakes the sound playback by
> having a separate hidden <video> element while rewinding, in which she
> seeks, plays forward for a bit, seeks, plays, etc, then when Bob loads
> that page in Browser B, which does play audio when rewinding, he'll get
> a horrible double audio effect.
>
> Or similarly, if Alice, in an attempt to get a cool effect, plays a bunch
> of videos backwards, and when the user selects one, plays it forward, then
> Bob will find that all the audio from all the videos plays simultaneously
> instead of all being muted except the video that Alice is expecting to
> play.


I continue to think two things:
* These use cases are really a stretch, compared to the much more plausible
use case of simply allowing a user to scrub a video forwards or backwards.
* All this still seems well-enough-solved if audio can be programmatically
muted.  The worst possible case is that the author, as you say, does not
test in one browser, and causes another browser to have overlapped audio.
 Then users complain and the author is responsible and fixes their JS to
mute the audio (hopefully simple), or they are lazy and don't.  Neither one
seems like catastrophe.  As you say in your mail, authors act irrationally,
and not all will fix their pages.  But so what?

By comparison, mandating that browsers play audio puts a great burden on
browsers and codec authors (since the feasibility of reversed audio depends
on the format, the OS, etc.), and mandating that they don't completely rules
out whole classes of use cases.  This cure is much worse than the disease.

> If muting is needed, then it should be explicitly requested.
>
> We can get this by requiring that the user agent play _some_ audio, even
> if severely degraded, at all speeds including negative speeds. I'm happy
> to require that if people are ok with it.


I don't see how this is any better than the "no spec" case you wanted to
avoid.  Use your previous argument again: an author tests in one browser,
which plays reversed audio in a fashion he deems acceptable.  The released
app, played in another browser, sounds hideous.  Users complain.

The only way to avoid inconsistency is to specify either no playback or
perfect playback, and both have major problems IMO.

I don't think anyone is disagreeing on the importance of allowing this.
> The question is whether we should require it to be supported today, or add
> an explicit attribute to support this later.


I don't see how an explicit attribute buys you anything more or less than
explicit muting until the day when every browser respects that attribute in
all cases -- and if our reason for not mandating reversed playback is that
it's technically infeasible in some circumstances (which I think has merit),
that's unlikely to ever happen.

Certain audio encoding formats can be reversed much more easily than others.
 It is reasonable to imagine a world where, for technical reasons, all
browsers support reversing the audio of some formats, but not others.  A
spec which allows browsers to play reversed audio lets authors write
interoperable apps which use audio scrubbing if they at least stay to these
formats.  This world is imperfect, but it seems beyond the scope of the spec
to say which specific formats will support reversed audio.  To my knowledge,
the list of specific image formats browsers must decode is not specified,
but authors seem capable of sticking to ones that are supported everywhere.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081015/41431a09/attachment-0001.htm>