Re: [media] Moving forward with captions / subtitles

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.


> <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?

 + Do we enable the first track in a group if none match? 

  + 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?


On Feb 16, 2010, at 9:49 PM, Silvia Pfeiffer wrote:

> 
> Agreed. I think that confirms the above proposal?
> 
> I'm curious what Eric and Geoff think about this now?
> 
  We are getting there ;-)


eric