W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2010

Re: [media] Moving forward with captions / subtitles

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 16 Feb 2010 13:03:08 +0800
To: "Eric Carlson" <eric.carlson@apple.com>
Cc: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u77eziw9atwj1d@philip-pc>
On Tue, 16 Feb 2010 10:22:34 +0800, Eric Carlson <eric.carlson@apple.com>  

>   Yikes, teach me to ignore email for 12 hours :-(
> On Feb 15, 2010, at 12:46 AM, Philip Jägenstedt wrote:
>> On Mon, 15 Feb 2010 15:19:09 +0800, Eric Carlson  
>> <eric.carlson@apple.com> wrote:
>>> On Feb 14, 2010, at 11:06 PM, Philip Jägenstedt wrote:
>>>> I think calling the grouping element <track> is a bad idea when it in  
>>>> fact doesn't specify a track but a group of tracks (each track in  
>>>> <source>).
>>>  But it does not represent a group of tracks!
>>>  The <track> element represents a single track in the presentation,  
>>> which uses one of the <source> elements as its source of media data.
>> How would this tie into the MediaTrack API and the MediaTracks  
>> collection? It is my understanding that each individual stream in a Ogg  
>> or MPEG-4 would be a MediaTrack.
>   Yes, exactly.
>> Would a <track> or a <source> represent a MediaTrack? If it is <track>,  
>> how would one activate a single <source> via the MediaTracks  
>> collection? Or is the intention that source selection in <track>  
>> completely determine which <source> is used so that the only way of  
>> switching between e.g. languages is rearranging the order of <source>s  
>> and calling .load() (or similar)?
>   I am proposing that a <track> be represented by a MediaTrack. The UA  
> would select one of the <source> elements, or the "src" attribute on the  
> <track>, and that file would be used as the track's media data.
>   As you note, this *is* different from "alternate tracks" in an MPEG-4  
> or QuickTime file, but it is different by design. If we represent each  
> <source> by a MediaTrack object we will need to load every source,  
> whether it is displayed or not, to answer questions about it. The  
> MediaTrack object in the multi track API proposal has an ellipsis after  
> "enabled" to represent the other track properties we will want to expose:
> interface MediaTrack {
>   readonly attribute DOMString name;
>   readonly attribute DOMString role;
>   readonly attribute DOMString type;
>   readonly attribute DOMString lang;
>            attribute boolean enabled;
>   ...
> };
>   Some of these properties won't be possible to answer without loading  
> and parsing a file (eg. duration), which we shouldn't require for a file  
> that won't be used.
>   MPEG-4 and QuickTime files don't have this problem because even if a  
> track's media is external to the movie, the movie file always contains  
> the track meta data so it is possible get it without loading/parsing the  
> track data.

Good point. My thinking is that attributes of MediaTrack that require  
loading the track would simply be unavailable when the track is not  
enabled, like e.g. HTMLMediaElement.duration. At least role, type and lang  
are available from markup though and should be what the "track selection  
algorithm" operates on.

With <track><source>, is it at all possible to use the MediaTracks  
collection to activate tracks or build scripted menus? While not a  
must-have feature, it would be nice if the same API can be used to operate  
on both resource-internal tracks and tracks added with markup.

Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 16 February 2010 05:03:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:08 UTC