RE: Meaning of audio track kind 'descriptions'

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 Friday, 8 July 2011 17:24:19 UTC