- 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>
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 UTC