- From: John Foliot <jfoliot@stanford.edu>
- Date: Tue, 28 Jul 2009 14:51:21 -0700 (PDT)
- To: "'Dan Connolly'" <connolly@w3.org>, "'James Graham'" <jgraham@opera.com>
- Cc: "'Ian Hickson'" <ian@hixie.ch>, "'Robin Berjon'" <robin@berjon.com>, "'Shelley Powers'" <shelley.just@gmail.com>, <public-html@w3.org>, "'David Singer'" <singer@apple.com>
Dan Connolly wrote: > > I find this note that we had before... > > [[ > It would be helpful for interoperability if all browsers could support > the same codecs. However, there are no known codecs that satisfy all the > current players: we need a codec that is known to not require per-unit > or per-distributor licensing, that is compatible with the open source > development model, that is of sufficient quality as to be usable, and > that is not an additional submarine patent risk for large companies. It must also allow [spec] for the inclusion of transcript/caption files; user-agents/browsers that support any given codec MUST also provide native support for the on screen display of, and off screen extraction of[*] caption files. [* the ability for AT to parse text files for re-purposing, for example to Braille output devices] > > I can live with that option (i.e. don't require any codec > and don't even say why not) somewhat reluctantly. It seems > worth a bit of screen space to explain to our readers > what we spent so many collective person-months figuring out. It may very well be that the codec question will not be resolved quickly, as from my lowly vantage point the positions of the browser vendors appear fairly entrenched at this time. If the LC specification is that multiple codecs be supported, from the viewpoint of accessibility the means to ensure captioning - including the API to render captioning on screen - should be specified formally, so that browser vendors supporting "x" codec have clear specification in this matter, and content developers (who will be left with no choice than to encode to two codecs for 'universality's sake') have explicit and precise specifications and guidance to provide captioning; failure here is an abrogation of the accessibility mandate and should not be specifically hinged to the codec discussion. If different solutions are dependent on the choice of codec and attendant media wrapper, and a universal specification that covers this aspect cannot emerge, then the multiple means (as there are multiple codecs) should be specified in the document: If option 1, then do this for captioning, if Option 2, then do that for captioning, if x-option - spec'd x-captioning solution. As well: * caption formats should be clearly articulated and specified (or external specifications should be referenced: i.e.: DFXP @ http://www.w3.org/TR/ttaf1-dfxp/) * existing examples that show sourcing multiple encoded media streams should be clearly spec'd as well - for example, is source order important? (yes, no, n/a) * If a particular codec/media wrapper cannot support both in-band and out-band captioning (desirable and currently evident in Ogg/Kate examples being demo'd by Silvia Pfeiffer and Mozilla developers http://people.mozilla.com/~prouget/demos/srt/index2.xhtml ), then clear instruction and specifications on how to 'in-code' provide the out-band solution must also be provided. Bottom line, the captioning aspect of <video> should not be explicitly linked to (or delayed by) the codec conversation (but I acknowledge that it might be shaped by that discussion). Failure to provide captions with <video> at Last Call however would be a significant barrier to acceptance at that time. JF
Received on Tuesday, 28 July 2009 21:52:07 UTC