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

On Mar 2, 2011, at 2:04 PM, Silvia Pfeiffer wrote:

> 
> 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).
> 
  Yes, this is exactly the situation we have today with browsers that support more than one media container format. 

> 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?
> 
  If all browsers end up supporting a common format, and if that format meets all captioning needs, there won't be a *need* to have <source> for text tracks. However, if we allow the inclusion of audio and video through <track> we will *require* <source> to deal with alternate encodings and it will be silly to forbid the use of <source> for text tracks.

eric