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

On Thu, Mar 3, 2011 at 6:39 AM, David Singer <singer@apple.com> wrote:
>
> 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.


All of these concerns are fair enough. However, I also wonder if this
necessarily means to have <source> elements for them. The <img> tag
supports multiple formats without needing a <source> selection. Also,
if you are providing a webvtt and a ttml file, are they really
considered alternative resources or should they both be listed in a
selection menu to the user? If we want the latter - and Mark's
comments seemed to indicate that - then:

  <video id="v1" poster=“video.png” controls>
     <track kind="captions"  srclang="en" label="Captions">
          <source src="captions.vtt" type="text/vtt">
          <source src="captions.xml" type="application/ttml+xml">
      </track>
  </video>

surely would be better marked up as:

  <video id="v1" poster=“video.png” controls>
     <track kind="captions"  srclang="en" label="Captions" src="captions.vtt">
     <track kind="captions"  srclang="en" label="Captions" src="captions.xml">
  </video>

The <source> mechanism has been introduced to allow UAs to pick the
first format that they understand and ignore the other <source>
elements in this list. This exposes all the options that the UA
supports to the user and allows them to pick for themselves without
the browser making an implicit decision on quality.

I am not convinced that the <source> mechanism should be allowed for
text tracks - it might cause more damage than good.

Cheers,
Silva.


>> -----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 21:37:42 UTC