Re: [media] Moving forward with captions / subtitles

On Feb 17, 2010, at 22:42 , Silvia Pfeiffer wrote:

> On Thu, Feb 18, 2010 at 4:49 PM,  <philipj@opera.com> wrote:
>> On Thu, 18 Feb 2010 00:31:17 +0800, Eric Carlson <eric.carlson@apple.com>
>>>  +  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 think Eric has already considered using this API for both, tracks
> embedded and external to the media resource. Also, in MPEG there is
> the construct of groups, too. So maybe we need to introduce that in
> the API somehow?
> 
> 
>>>  + 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?
> 
> No, I think we should refrain from that. The trackgroup has no
> semantic meaning other than grouping tracks together to be activated
> mutually exclusively. It's like a radio group. Using type, language or
> role on the trackgroup is just a simplified way or expressing that all
> track elements share the same value on those attributes, IMO. For
> example, @track and @role could both be on the trackgroup element and
> the the tracks inside don't have to all repeat it.
> 
> 
>>>  + 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.
> 
> Ok, added.
> 


It seems to be that if a trackgroup represents an optional feature (e.g. "captions"), then

a) the expression that says whether the trackgroup as a whole is wanted or not, should be, well, at the trackgroup level (a media query)
b) *which* of the trackgroup you want should be expressed by attributes on the enclosed tracks.

Do we need something at the trackgroup level that gives me a clue what criteria to use to select between the tracks?  ("These differ by language", "These differ by mime type") or do we have a rule that is like <source> ... walk down the group and enable the first that seems supportable (and implicitly disable the rest)?  I am kinda not keen on 'best match' specifications (but they are hard to avoid when talking about languages).


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 18 February 2010 23:25:26 UTC