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

On Thu, Mar 3, 2011 at 8:51 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>
> On Mar 2, 2011, at 1:36 PM, Silvia Pfeiffer wrote:
>
>> 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.
>>
>  Who said anything about a decision based on quality? The resource selection algorithm for the main resource doesn't make assumptions about quality when selecting among multiple <source> elements, why would we speciry anything else for track?
>
>
>> I am not convinced that the <source> mechanism should be allowed for
>> text tracks - it might cause more damage than good.
>>
>  "more damage than good" is a stretch. What "damage" are you talking about?
>
> eric

So, the question is what we expect people to do with the alternatives.
If, as you say, the list of resources in the <track> element would be
gone through using the source selection algorithm and the first one
that that browser understands will be displayed, then what is the
author of these captions to do?

If I am the author and I create a WebVTT file and all browsers support
this format, why should I also author a TTML file? Unless that would
give me something in addition to the WebVTT, I wouldn't. Thus, the
TTML would necessarily be able to provide "higher quality" of some
sort to make me want to use it instead of the baseline WebVTT. The
same with any other format. And in addition, I'd have to make sure to
provide the TTML ahead of the WebVTT in the markup, since otherwise no
browser will ever get to it (this is always under the assumption that
everyone will in fact implement WebVTT support).

The "damage" I am talking about is that of requiring people to have to
author more than one format. But you are right - this is not dependent
on the markup, this is a general problem of having more than one
format available as a solution - it's the same for the img element, so
ignore this comment.

The question still stands: is the choice sufficiently possible just
through the formats that the browser supports in the analogous way
that the <img> element supports both png and jpg?

Cheers,
Silvia.

Received on Wednesday, 2 March 2011 22:05:41 UTC