<video>RE: Codecs for <video> and <audio> (survey of positions on ISSUE-7 video-codecs)

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