W3C home > Mailing lists > Public > public-html-a11y@w3.org > June 2011

Re: Meaning of audio track kind 'descriptions'

From: Mark Watson <watsonm@netflix.com>
Date: Mon, 27 Jun 2011 08:50:28 -0700
To: Bob Lund <B.Lund@CableLabs.com>
CC: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, David Singer <singer@apple.com>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
Message-ID: <24333872-8C4D-4470-AA4F-0FBB0754DB37@netflix.com>
Yes, exactly.

...Mark

Sent from my iPhone

On Jun 27, 2011, at 8:37 AM, "Bob Lund" <B.Lund@CableLabs.com> wrote:

> Hi Mark,
> 
> If I understand you, the difference between your (1) and (2) is that in (1) there would be exactly one new @kind - "main+descriptions" and in (2) @kind can contain atomic kinds, e.g. "main", "description", etc. and compound kinds, e.g. "main+description". In both cases, the user agent, Web content or user will decide which tracks to enable based on @kind which specifies which kinds are premixed in a media resource track.
> 
> Bob
> 
>> -----Original Message-----
>> From: Mark Watson [mailto:watsonm@netflix.com]
>> Sent: Friday, June 24, 2011 1:22 PM
>> To: Bob Lund
>> Cc: Silvia Pfeiffer; David Singer; HTMLAccessibility Task Force
>> Subject: 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 Monday, 27 June 2011 15:51:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:41 GMT