[Ogg a11y] architecture for video and accessibility on the Web

[ogg.k.ogg.k at googlemail.com]

Hi,

> * Our focus for video (and audio) accessibility here stems from a need
> for the Web; accessibility will also be required in other applications
> than the Web Browser, so some thought should also be spent on how to
> enable offline video accessibility without much loss of functionality
> (e.g. less styling capabilities)
[...]
> * Also, Web Browsers already implement a lot of functionality for
> styling text; we should try to re-use that functionality without
> enforcing a complex styling model on offline video applications

I read this as a strong hint towards CSS. CSS is known to be difficult to
fully implement, as proved by the time it took browsers to get it right (if
some do). Pushing CSS on other viewing programs might be a good way
to get them to not support it, or support it as a lot of video players now
support ASS/SSA: with varying degrees of support, meaning you have
to rely on a common subet. Specifying a subset of CSS could possibly
be a solution to this. Or did I read this hint wrong ?

> * Playback can work via one connection to a multiplexed media
> resource, or via multiple connections to the media data and the text
> data separately. Assuming the user can only provide one URL to the
> media resource, the latter case would need to have a URL to a resource
> description such as SMIL or ROE through which the player can then
> re-issue a request to several separate resources. I am not sure this
> is desirable and would like to discuss this.

Pros:
- ease of updating any one track without having to demux/remux
- less bandwidth taken on a single server (though the one serving the
  video track will take maybe 90% of it anyway)

Cons:
- any one server is down means you can't play the subset you want
- sync problems if one server is slower and can't keep up
- the usual 'dead link' one finds on the internet if linking to somewhere else

> * In either case the media decoding subsystem of the Browser will need
> to hand over audio, video and text data to the Browser. If the text
> data was already in some XML format, the Browser's internal XML parser
> could be re-used to create a DOM in a nested browsing context for the
> Web page that the video or audio tag are part of. It would in general
> be easier and more flexible to provide a nested browsing context DOM
> for each text codec of a media resource rather than defining a
> standard javascript API.

Would it need to be so complex though ? This would seem to set a high
bar for non browser players, who do not have a DOM setup already.

> * Since it's XML (or maybe better even: HTML-like), the HTML means of
> attaching style information to elements can also be applied to these
> elements and provide styling commands to the Browser.

Same potential issue.

> * We would further define a media mapping of such a resource into Ogg
> and implement this in a little library such that it can be used to
> create multiplexed media resources for the download case.

liboggz (unless you mean it to also output to Matroska, or some other
containers that may exist ?)