Re: Meaning of audio track kind 'descriptions'

Hi Bob,

Both cases would allow you to signal the following example:

a) Video Track: main
b) Audio Track: main
c) Audio Track: main+descriptions (= pre-mixed audio descriptions)
d) Audio Track: descriptions (= separate audio descriptions)

The difference is that in case (2), "main+descriptions" means "both 'main' and 'descriptions'" - the client interprets it according to its understanding of the kind 'main' and the kind 'descriptions' whereas in case (1) there is a third kind called "main+descriptions" which the client understands as a separate third thing.

Applying the rule that you should play exactly one track having each kind that you require*, the client that wants "main" and "descriptions" will choose either (a)+(b)+(d) or (a)+(c) (according to user preference or client capability).

The main point is that (1) is just a solution specifically to the audio descriptions case, wheras (2) is a more general approach.

For example we could have 

a) Video Track: main
b) Video Track: main + captions
c) Audio Track: main
d) Audio Track: main + descriptions
e) Audio Track: descriptions
f) Text Track: captions
g) Text Track: descriptions

A client that wants "main" + "descriptions" will choose
(a) + (c) + (e)	- if the user prefers audio descriptions mixed on the client
(a) + (d) - if the user prefers pre-mixed audio descriptions
(a) + (c) + (g) - if the user prefers text descriptions

A client that wants "main" + "captions" will choose
(a) + (c) + (f) , or
(b) + (c)

* To make this work the 'one of each kind' rule sometimes has to apply per media type and sometimes globally. By default, I want one track with "captions" - if there are multiple such tracks available I should use some user preference order (closed captions preferred over open captions, audio descriptions preferred over text etc.). However for some kinds I want 'one for each media type' i.e. I want main audio and main video.

Btw, nothing should preclude users selecting combinations which don't match the rule. If the user wants both open and closed captions, or both audio and text descriptions, they should be able to get that.

...Mark

On Jun 23, 2011, at 1:34 PM, Bob Lund wrote:

> 
>> -----Original Message-----
>> From: Mark Watson [mailto:watsonm@netflix.com]
>> Sent: Wednesday, June 22, 2011 7:35 PM
>> To: Silvia Pfeiffer
>> Cc: David Singer; Bob Lund; HTMLAccessibility Task Force
>> Subject: Re: Meaning of audio track kind 'descriptions'
>> 
>> 
>> On Jun 22, 2011, at 3:05 PM, Silvia Pfeiffer wrote:
>> 
>>> On Wed, Jun 22, 2011 at 4:55 PM, Mark Watson <watsonm@netflix.com>
>> wrote:
>>>> 
>>>>> But
>>> anyway, I did mention "main+descriptions" could be a solution for
>>> legacy content.
>>> 
>> 
>> Ok, so rather than respond to the other points, let's work on this basis
>> and see where it goes ...
>> 
>> We have two options:
>> (1) define the specific string "main+descriptions" for the case of an
>> alternative track containing main audio and descriptions, or
>> (2) define a general rule that a track can have multiple kinds, with the
>> string returned from getKind being a '+' separated list of kinds and the
>> rule that you should play exactly one track having each of the kinds
>> that you require.
> 
> I don't understand (2). Can you provide an example showing both the case where there is a "main+ description" and a "description"?
> 
> Bob
> 
> In the case of the Descriptive Video Service, the user chooses to play one of a set of description tracks. @kind should help the user agent/user identify the set of description tracks and, as we've been discussing, identify whether to mix two tracks or play an alternative. @kind doesn't contain a rule about what needs to be combined.
> 
> Can you explain?
> 
> Bob 
>> 
>> Btw, apologies in advance that I will miss the media subteam call today.
>> I'm travelling.
>> 
>> ...Mark
>> 
>> 
>>> Cheers,
>>> Silvia.
>>> 
> 
>

Received on Friday, 24 June 2011 19:22:03 UTC