[Bug 10941] Media elements need control-independent "pause" for presenting lengthy descriptions/captions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10941

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |ian@hixie.ch

--- Comment #7 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-10-05 00:29:14 UTC ---
There are two cases here:

1. A browser that supports audio descriptions natively, and needs to stop
playback of the video and primary audio tracks while a secondary audio
description track plays back content.

I'm not familiar with any content like this (I've rarely seen audio
descriptions on real content at all, but the few times I've seen it, e.g. on
Digital TV in the UK, the video was never stopped in this fashion), so it's
hard to comment on this, but if there are user agents that want to implement
this, I could make the spec handle it by changing this requirement:

"When a media element is potentially playing and its Document is a fully active
Document, its current playback position must increase monotonically at
playbackRate units of media time per unit time of wall clock time."

...to cover this case, e.g. by adding " and is not in a description-pause
state" after "potentially playing", and then define "description-pause state"
as being for the aforementioned case.

Are there user agents interested in implementing this? (Are there any media
formats that support audio tracks having content with non-zero length to be
played at an instant in time on the primary timeline?)


2. A future time where we have multiple media elements all synchronised on one
timeline, coordinated by some object that can start and stop individual tracks.

If this is the case being discussed here, then we should make sure to take this
use case into account when designing the controller API, but it is probably
premature to make changes to the spec at this point for that case, since
there's no way to sync tracks so far.


Which case are we talking about here? Or is it a third case I haven't
considered?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 5 October 2010 00:29:17 UTC