W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: Tech Discussions on the Multitrack Media (issue-152)

From: Eric Carlson <eric.carlson@apple.com>
Date: Wed, 2 Mar 2011 09:13:20 -0800
Cc: public-html@w3.org
Message-Id: <116B882D-1F21-4B2C-8116-D7A4D0E07512@apple.com>
To: Philip Jägenstedt <philipj@opera.com>

On Mar 1, 2011, at 11:58 PM, Philip Jägenstedt wrote:

> On Tue, 01 Mar 2011 23:51:30 +0100, David Singer <singer@apple.com> wrote:
> 
>> Hi Silvia, friends
>> 
>> Eric and I have been discussing this, and we've added an 8th option to the Wiki, for your consideration.
>> 
>> at <http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API>
> 
> This is like option 2 except that <track> is not a void element and can have <source> child elements, right?
> 
  Yes, or "a combination of options 2 and 3" as we note in the text.

> For all of the options that don't use <audio> and <video> to represent audio and video tracks, do you consider it a problem that properties of HTMLMediaElement are not available? Some of these allow for interesting conflicts such as looping a slave video but not the master video, but I imagine at least videoWidth, videoHeight and volume would be useful to have.
> 
  While some properties of HTMLMediaElement could be useful (eg. videoWidth and videoHeight as you note), I think one advantage of this proposal is that the full media element interface is *not* available on <track>. The timeline of a <track> must be slaved to the clock of the parent media element, so I think it will be difficult to define the behavior of the parent when attributes like playbackRate or loop are changed, or methods like load(), play(), or pause() are called on a track.

eric
Received on Wednesday, 2 March 2011 17:14:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC