RE: Meaning of audio track kind 'descriptions'

I thought there was agreement in this group on the following:

1) There is a need to accommodate the two types of audio descriptions: pre-mixed and separate track
2) The current meaning of @kind=description is the separate track case
3) @kind = main+description could be used for the premixed track

Mark summarized two alternatives: adding this one new kind or specifying a more general rule of constructing compound kinds of the form @kind=atomic_kind+atomic_kind.

I don't have an existing use case beyond audio descriptions, although I imagine a similar situation might arise for signing: burned in or separate track.

Absent any other use cases, is there support for at least submitting a bug to add the single new kind main+description?

Thanks,
Bob Lund 
________________________________________
From: Silvia Pfeiffer [silviapfeiffer1@gmail.com]
Sent: Friday, July 08, 2011 11:40 PM
To: Bob Lund
Cc: Mark Watson; David Singer; HTMLAccessibility Task Force
Subject: Re: Meaning of audio track kind 'descriptions'

I don't think we've thought through all the aspects and implications
of this approach yet. It would be worth going through some examples
and writing this up as a list of things that are currently broken and
how this approach would fix it without breaking the other needs. I
suggest starting a wiki page. Unless we can explain the problem in
detail and provide good reasoning for this solution in comparison to
others, I wouldn't be comfortable stating that I support this yet.

Cheers,
Silvia.

On Sat, Jul 9, 2011 at 3:23 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
> I think that (2) is a more flexible approach. Is there consensus within the media subgroup on extending audio and video track @kind to include compound kinds?
>
> Thanks,
> Bob Lund
>
>
>> -----Original Message-----
>> From: Mark Watson [mailto:watsonm@netflix.com]
>> Sent: Monday, June 27, 2011 9:50 AM
>> To: Bob Lund
>> Cc: Silvia Pfeiffer; David Singer; HTMLAccessibility Task Force
>> Subject: Re: Meaning of audio track kind 'descriptions'
>>
>> 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 Tuesday, 12 July 2011 13:30:00 UTC