[whatwg] Thoughts on video accessibility

[Michael Dale]

Yea as Silvia outlines in the intro to this thread we will likely 
continue to see external timed text files "winning out" over muxed timed 
text.

"Its just more flexible" ... Javascript embedding libraries which are 
widely used today for flash video will be even more widely used with the 
emerging browser support of the video tag.

So its not too big a deal... the complexity of transcript formats will 
be handled by dedicated javascript libraries. If the browser does expose 
some timed text tracks muxed with the media then the library will 
integrate that into the interface.

That being said having some semantically meaningful source data 
representation is worthwhile. By supporting these proposed syntax with 
the embedding libraries we are promoting the idea that the syntax will 
eventually be adopted and natively handled by the browser. But in 
practice even if we do get native timed text support a javascript 
library will likely rewrite it to conform the sites layout and skinning 
anyway.

The "take-away" point here is if people do mux text tracks that they 
should be exposed via javascript. Otherwise it will be of very limited 
value in the context of web media.

peace,
--michael

Silvia Pfeiffer wrote:
> And now we have a first demo of the proposed syntax in action. Michael
> Dale implemented SRT support like this:
>
> <video src="sample_fish.ogg" poster="sample_fish.jpg" duration="26">
>  	<text category="SUB" lang="en" type="text/x-srt" default="true"
>  		title="english SRT subtitles" src="sample_fish_text_en.srt">
>  	</text>
>  	<text category="SUB" lang="es" type="text/x-srt"
>  	 	title="spanish SRT subtitles" src="sample_fish_text_es.srt">
>  	</text>
> </video>
>
> Michael writes:
>   
>> the demo: (tested on IE, Firefox, Safari ... with varying degrees of success ;)
>> http://metavid.org/w/extensions/MetavidWiki/skins/mv_embed/example_usage/sample_timed_text.php
>>     
> (bottom example)
>   
>> If Firefox exposes timed text tracks in ogg media the script could query
>> them and display them alongside any available markup text tracks (but of
>> course other browsers like IE wont easily expose those muxed text tracks
>> so its likely the least common denominator of text based markup /
>> pointers will be dominate for some time)
>>     
>
> You will need to click on the "CC" button on the player and click on
> "select transcripts" to see the different subtitles in English and
> Spanish.
>
> Regards,
> Silvia.
>
>
> On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>   
>> I heard some complaints about there not being any implementation of
>> the suggestions I made.
>>
>> So here goes:
>>
>> 1. out-of-band
>> There is an example of using srt with ogg in a out-of-band approach here:
>> http://v2v.cc/~j/jquery.srt/
>> You will need Firefox3.1 to play it.
>> The syntax of what Jan implemented is different to what I proposed,
>> but I wanted to take it forward and make it more generic.
>>
>> 2. in-band
>> There is also a draft implementation of srt inside Ogg through the
>> OggText specification, but I it's not released yet. It is also not as
>> relevant to this group as the out-of-band example.
>>
>> Cheers,
>> Silvia.
>>
>>
>>
>> On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>>     
>>> On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>
>>> wrote:
>>>       
>>>> Silvia Pfeiffer wrote:
>>>>         
>>>>> I'm interested to hear people's opinions on these ideas. I agree with
>>>>> Ralph and think having a simple, explicit mechanism at the html level
>>>>> is worthwhile - and very open and explicit to a web author. Having a
>>>>> redirection through a ROE-type file on the server is more opaque, but
>>>>> maybe more consistent with existing similar approaches as taken by
>>>>> RealNetworks in rm files and WindowsMedia files in asx files.
>>>>>
>>>>>           
>>>> This (having a separate document that references other streams) is what I
>>>> was thinking of. I guess which is more natural depends on who is doing the
>>>> assembling. If it is the HTML author that takes the individual pieces and
>>>> links them together then doing it in the HTML is probably easiest.
>>>>         
>>> For what it's worth, loading an intermediate document of some new type which
>>> references other streams to be loaded adds a lot of complexity to the
>>> browser implementation. It creates new states that the decoder can be in,
>>> and introduces new failure modes. It creates new timing issues and possibly
>>> new security issues.
>>>
>>> Rob
>>> --
>>> "He was pierced for our transgressions, he was crushed for our iniquities;
>>> the punishment that brought us peace was upon him, and by his wounds we are
>>> healed. We all, like sheep, have gone astray, each of us has turned to his
>>> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
>>> 53:5-6]
>>>
>>>