<div dir="ltr"><div class="gmail_quote">On Wed, Oct 15, 2008 at 2:08 AM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For example, if Alice uses Browser A, and finds that when rewinding the<br>
sound isn't played, and thus does a hack that fakes the sound playback by<br>
having a separate hidden <video> element while rewinding, in which she<br>
seeks, plays forward for a bit, seeks, plays, etc, then when Bob loads<br>
that page in Browser B, which does play audio when rewinding, he'll get<br>
a horrible double audio effect.<br>
<br>
Or similarly, if Alice, in an attempt to get a cool effect, plays a bunch<br>
of videos backwards, and when the user selects one, plays it forward, then<br>
Bob will find that all the audio from all the videos plays simultaneously<br>
instead of all being muted except the video that Alice is expecting to<br>
play.</blockquote><div><br></div><div>I continue to think two things:</div><div>* 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.</div>
<div>* 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?</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">> If muting is needed, then it should be explicitly requested.<br></div><div class="Ih2E3d">

<br>
</div>We can get this by requiring that the user agent play _some_ audio, even<br>
if severely degraded, at all speeds including negative speeds. I'm happy<br>
to require that if people are ok with it.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>The only way to avoid inconsistency is to specify either no playback or perfect playback, and both have major problems IMO.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">I don't think anyone is disagreeing on the importance of allowing this.<br></div>
The question is whether we should require it to be supported today, or add<br>
an explicit attribute to support this later.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>PK</div></div></div>