Re: [media] Moving forward with captions / subtitles

On Thu, 18 Feb 2010 00:31:17 +0800, 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.
>
>
>> <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?

What does enabled mean here? Since the MediaTracks API doesn't reflects
the concept of groups, the mapping is open for debate. I think we should
either reflect groups in some way, or we should simply expose all tracks
in all groups (enabled or not) and setting .enabled=true on a track should
implicitly disable the others in the same group.

>  + I also assume that if I set the enabled property on one track in a  
> group all of the others are automatically disabled?

Yes.

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

I don't think so, but we haven't discussed the track selection algorithm
much at all. I suppose it should first find the the first track with the
enabled="" attribute in each group and enable that. But do we also want an
enabled attribute on the group itself that performs selection based on
media type, language, role etc?

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

I agree, possibly throwing NOT_SUPPORTED_ERR or some other exception.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 18 February 2010 05:52:21 UTC