Re: [MSE] Resolving Bug 24370

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 <> wrote:

> On Sun, Apr 6, 2014 at 4:12 PM, Glenn Adams <> wrote:
>> On Sat, Apr 5, 2014 at 11:55 PM, Silvia Pfeiffer <>
>> wrote:
>>> On Thu, Apr 3, 2014 at 12:20 AM, Jim Ley <> wrote:
>>>> On 2 April 2014 09:26, Silvia Pfeiffer <>
>>>> wrote:
>>>>> On Wed, Apr 2, 2014 at 6:04 PM, Jim Ley <> 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