On Wed, Oct 15, 2008 at 5:28 AM, Peter Kasting <[EMAIL PROTECTED]> 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
Also in the case of a caption/subtitle authoring application: being able to scrub through the audio forwards/backwards is a very important means for captioners to identify the time points to start/end a caption segment. I disagree with mandating silence and would rather deal with an intermediate inconsistent browser landscape for lack of the audio scrubbing feature in some browsers. Regards, Silvia.