- From: Eric Carlson <eric.carlson@apple.com>
- Date: Mon, 15 Feb 2010 18:22:34 -0800
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
- Message-id: <53940BA2-9505-4456-9863-9FF495235A38@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. eric
Received on Tuesday, 16 February 2010 02:23:41 UTC