- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 9 Jul 2011 15:40:46 +1000
- To: Bob Lund <B.Lund@cablelabs.com>
- Cc: Mark Watson <watsonm@netflix.com>, David Singer <singer@apple.com>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
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 Saturday, 9 July 2011 05:41:34 UTC