W3C home > Mailing lists > Public > public-html-media@w3.org > April 2014

Re: [MSE] Resolving Bug 24370

From: David Singer <singer@apple.com>
Date: Sun, 06 Apr 2014 11:45:21 +0200
Cc: Glenn Adams <glenn@skynav.com>, Jim Ley <jim.ley@gmail.com>, Aaron Colwell <acolwell@google.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
Message-id: <240114BD-CEAA-4357-8B7E-0B0862937BF8@apple.com>
To: Silvia Pfieffer <silviapfeiffer1@gmail.com>
I think that adding/removing tracks, or reloading the entire video element, are cleaner and more direct ways to get the UA to re-evaluate what it is playing.  Switching a track to russian and then saying “oh, I switched you to russian, hope you don’t mind” seems rather roundabout and an un-needed duplication of this functionality.

On Apr 6, 2014, at 8:21 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> On Sun, Apr 6, 2014 at 4:12 PM, Glenn Adams <glenn@skynav.com> wrote:
>> 
>> On Sat, Apr 5, 2014 at 11:55 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
>> wrote:
>>> 
>>> On Thu, Apr 3, 2014 at 12:20 AM, Jim Ley <jim.ley@gmail.com> wrote:
>>>> On 2 April 2014 09:26, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
>>>> wrote:
>>>>> 
>>>>> On Wed, Apr 2, 2014 at 6:04 PM, Jim Ley <jim.ley@gmail.com> wrote:
>>>>>> 
>>>>>> Isn't the use case for language being mutable simply live subtitles
>>>>>> of a
>>>>>> live "channel" that has programmes in different languages and
>>>>>> therefore
>>>>>> has
>>>>>> closed captions / subtitles in different languages.
>>>>> 
>>>>> Each one of those subtitle languages would be a different track, so
>>>>> there is no need for mutability.
>>>> 
>>>> 
>>>> No they're not, some shows are in English, some are in Welsh, the
>>>> subtitle
>>>> track is a single one for the live broadcast, similarly with audio, the
>>>> broadcast audio changes languages.
>>> 
>>> Every show should have its own subtitle track.
>> 
>> 
>> That is an operational policy issue that shouldn't be determined by the
>> technology. For example, TTML explicitly supports the presence of multiple
>> languages in a single TTML document. The user of TTML decides how to use it:
>> whether to create different TTML files for different languages, or whether
>> to merge different languages into the same TTML document (allowing selection
>> to occur at processing or rendering time).
> 
> You can do that if you just deliver content and leave the rendering to
> the application.
> 
> In the discussed case, the user of the technology is the browser user
> and there are certain assumptions under which content is consumed.
> 
> I explained the poor consequences that a mid-change of track language
> and kind can have on the example of a blind user. Do you disagree with
> that example?
> 
> 
>> It should not be construed to be poor practice of a TTML author merges
>> different languages into the same file,
> 
> That may be as is.
> 
>> which translates to a single track
>> using HTML5 mechanisms.
> 
> At the point where you hook into HTML5, you have to deal with the
> content consumption approach of HTML5. A TTML file with cues of
> multiple languages should be converted into as many tracks as there
> are languages in use. This is a requirement of the way in which tracks
> are consumed in a HTML5 browser. A TTML mapping into HTML5 would need
> to provide for this functionality.
> 
> Regards,
> Silvia.

David Singer
Manager, Software Standards, Apple Inc.
Received on Sunday, 6 April 2014 09:45:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:02 UTC