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

On Mar 2, 2011, at 10:01 , Frank Olivier wrote:

> "About multiple text track formats, my working assumption is that we will be able to agree on a single format that everyone supports as there is not really any of the legal of business issues that we have for audio and video."
> Yes, this would be a very desirable outcome. However, it would still be prudent to have the ability to reference multiple text track formats for the same content, as some user agents may have the ability to display more-complex-than-baseline text track formats.
> 

Also, looking ahead, we should not assume that even if we pick a default and mandate now, it'll be the best for all time. If we (or someone) introduces a new, better, format, there will be a need for a while to offer both.

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Philip Jägenstedt
> Sent: Tuesday, March 01, 2011 11:58 PM
> To: public-html@w3.org
> Subject: Re: Tech Discussions on the Multitrack Media (issue-152)
> 
> 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?
> 
> 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.
> 
> About multiple text track formats, my working assumption is that we will be able to agree on a single format that everyone supports as there is not really any of the legal of business issues that we have for audio and video.
> 
> If, however, we should both fail at finding a baseline text format and decide that we should use <track> for audio and video as well, then wouldn't multiple <track> elements with a type parameter be enough? We could define it such that multiple <track> elements that differ only in type should be assumed to representing the same content and have some kind of track selection algorithm for picking one. Am I too optimistic?
> 
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 2 March 2011 19:40:05 UTC