RE: Meaning of audio track kind 'descriptions'

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:37:35 UTC