Re: [media] Moving forward with captions / subtitles

On 2/17/10 11:31 AM, "Eric Carlson" <eric.carlson@apple.com> wrote:


On Feb 17, 2010, at 12:00 AM, Philip Jägenstedt wrote:

On Wed, 17 Feb 2010 15:10:06 +0800, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

Maybe we have converged?

Yes, and for the record this is what I think we agree on:

<track> is used to reference an external text track.

 Although we are only talking about external text tracks at the moment, I think we will be talking about other media types soon enough (eg. audio description) so I would say

<track> is used to reference an external track.

GF:  Agreed, but add descriptive language, e.g., "<track> is used to reference an external track, such as captions, subtitles or audio descriptions."


<trackgroup> is used to group several tracks which are mutually exclusive. Often they will have the same role="", but this isn't necessarily so.

Your example with active changed to enabled:

<video src="video.ogv">
  <track src="cc.en.srt" srclang="en" role="CC" enabled>
  <track src="tad.en.srt" srclang="en" role="TAD">
  <trackgroup role="SUB">
    <track src="subs.de.srt" srclang="de">
    <track src="subs.sv.srt" srclang="sv">
    <track src="subs.jp.srt" srclang="jp">
  </trackgroup>
</video>

<track> is a void element (no end tag), if there any reason to think that it would ever need child elements then now is the time to give it an end tag.

 I think we will need an end tag to allow <track> to have <source> elements for non-text media formats, for example audio description tracks, as long as we don't have a mandated format.

  One thing we are missing here is the "media" attribute. All of the examples we have used so far have selected alternates based on language but we also need to be able to consider a user's accessibility needs when choosing between track alternates. I believe that a content author should be able to describe a track with exactly the same media query syntax we are developing to describe movies.

  Another major topic we haven't talked about is how external tracks affect the movie's readyState and networkState. For example, if a movie's readState is HAVE_FUTURE_DATA and the user or a script enables a track for the first time, the readyState should drop back to HAVE_METADATA. I don't think this will be difficult, but we need to spell out all of the state changes thoroughly.

  Some questions and thoughts, in no particular order:

 +  I assume that if I use our track API to examine the track tracks in a trackgroup, the one chosen from among a group of alternates is enabled, and the others are not?

 + I also assume that if I set the enabled property on one track in a group all of the others are automatically disabled?
GF:  If by "disabled" you mean disabled at playback, then yes.  Just verify for me that the user will have the ability to *enable* the disabled tracks if desired.


 + Do we enable the first track in a group if none match?
GF:  Not sure I understand what you mean by "if none match."  If you mean that none of the tracks match the user's preference settings, then I'd say we do *not* enable any tracks automatically.


  + I think that a media query that evaluates to "false" means it *must* not be enabled because it is not appropriate for the user's environment, so should setting enabled to true on such a track just fail?
GF:  Not sure here what you mean, either.  Can you give an example?