<aol>Me too.</aol>
As I understand it, the intention was that because some players can't
support it, all players should be forbidden to do it because web
developers might somehow come to rely on it not working. I'm having
trouble imagining how that could be a significant problem, and
mandating that behavior in the spec seems very weird. A note in the
spec explaining that you should mute it if you really want it to not
play sounds like a much better way to go.
Is there any situation where muting it like that won't elegantly
solve this problem?
--
Andy Lyttle
[EMAIL PROTECTED]
On Oct 14, 2008, at 11:28 AM, Peter Kasting wrote:
On Tue, Oct 14, 2008 at 8:00 AM, Eric Carlson
<[EMAIL PROTECTED]> wrote:
Some media formats and/or engines may not support reverse
playback, but I think it is a mistake for the spec to mandate this
behavior. Why is reverse playback different from other situations
described in the spec where different UAs/ media formats will
result in different behavior, eg. pitch adjusted audio, negotiation
with a server to achieve the appropriate playback rate, etc?
I think the current sentence that talks about audio playback rate:
When the playbackRate is so low or so high that the user agent
cannot play audio usefully, the corresponding audio must not play.
could be modified to include reverse playback as well:
When the playbackRate is such that the user agent cannot play
audio usefully (eg. too low, too high, negative when the format or
engine does not support reverse playback), the corresponding audio
must not play.
Agree wholeheartedly.
Mandating silence during reverse playback seems bizarre in the
abstract, unnecessary if authors have a way to mute, and
potentially detrimental to future applications which may _want_ to
be able to do this in a controlled fashion (e.g. a virtual
turntable application).
PK