- 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>
On Tue, 16 Feb 2010 10:22:34 +0800, Eric Carlson <eric.carlson@apple.com> wrote: > > 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