Re: Shifting gears for a second (was RE: Codecs for <video> and <audio>)

On Fri, 3 Jul 2009, Silvia Pfeiffer wrote:
> >
> > Captions inside media files can be crawled and indexed by search 
> > engines, and can be exposed to screen readers.
> 
> Video files are currently handled as opaque elements in the <video> tag 
> - there is no API to expose any captions that may be inside the file.

A search engine doesn't need an API. It can just implement HTML5 natively, 
and just crawl all <source> elements and grab all the src="" attributes.


> The only system that is able to get access is the media framework and it 
> is typically buried deep inside the browser. As long as there is no 
> standard API to access captions for a media file, they are not exposed 
> to search engines and screen readers.

Screen readers sit atop browsers, so if the browser can get to the 
subtitles, so that can be screen reader.


> 10 years ago I was mkaing the same arguments that you are. But now, 
> after having tried to push for time-aligned text inside audio-visual 
> files for so long, I have come to the conclusion that it is actually 
> easier to deal with separate files than with captions inside media 
> files. As external files, they are easier to edit, easier to share, 
> easier to access, easier to parse, easier to handle on a server (e.g. in 
> a database) and generally easier to manage. All you get with putting 
> them inside the media file is that you do not lose them when you hand 
> them around or edit the file, but this can be solved in a different way. 
> Having captions inside a file turns them from a text format into a 
> binary format and that is detrimental for most applications.
> 
> In fact, my suggestion is not to look at these as completely different 
> and incompatible forms for captions, but as different states of the same 
> resource. Sometimes it is better to get the fully integrated resource 
> and sometimes it is better to get the text and the video parts of the 
> resource as separate representations.

Well, as mentioned earlier, I think that we should support this kind of 
thing too. This is probably the first set of features we should add once 
the current API is implemented properly and reliably. Hopefully by then 
we'll have good implementation experience, and a format that is simple to 
hand-author, media-independent, and doesn't require a whole HTML or SMIL 
processor or something complicated like that to handle.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 3 July 2009 10:09:16 UTC