- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Thu, 23 Jun 2011 14:34:01 -0600
- To: Mark Watson <watsonm@netflix.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: David Singer <singer@apple.com>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
> -----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 Thursday, 23 June 2011 20:34:43 UTC