Re: [MSE] Resolving Bug 24370

On Wed, Apr 2, 2014 at 6:04 PM, Jim Ley <> wrote:
> On 2 April 2014 01:17, Aaron Colwell <> wrote:
>> 2. Allowing kind & language to change during playback could result in all
>> sorts of added complexity to the HTML5 spec.
>> I'd like the people who care about this particular feature to answer the
>> following questions so that we can make some progress.
>> 1. What do you expect the UA to do when kind and/or language is changed on
>> a xxxTrack object?
>> 2. Why isn't the language & kind data simply placed in the initialization
>> segments instead of only being in a DASH manifest?
>> 3. Are there real world, compelling examples that require support for
>> language and/or kind to be able to change during playback?
> 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.

>   Similarly alternate
> audio tracks may also change for similar reasons,

Similarly, each one of these audio tracks are a different track and
thus there is no need for mutability.

> and knowing the current
> language of a text track or audio stream is important, not just for user,
> but also for applications, Spoken Subtitling would require the language of
> the text in the subtitles/captions to be able to provide any sort of Text to
> speech on it.
> In BBC Wales in the UK, broadcasts both in English and Welsh and a live
> stream of that will switch between languages.  Hixie's suggestion that
> no-one watches long running live broadcast-like TV on the web is I'd say
> completely wrong,

I agree, there should be long-running streams. However, that doesn't
mean that there can't be new tracks coming and going. Every time there
is a change in language and a track of that language hasn't been
created yet, there should be a new track. It makes semantic sense to
keep such tracks separate.

> few do it with the VIDEO element certainly, but that's
> where MSE and DASH are coming to help.
> The spec currently says "The language of a text track can change
> dynamically, in the case of a text track corresponding to a track element."

Right, the app developer can change the value of the attribute, though
I don't know what the use case would be, since nothing is going to
happen in the browser as a result of this change of value, so it's not
very useful.

> So it seems the UA problems all need to be addressed for that use case which
> is already been a stable part of the spec for many years, so I believe the
> UA complexity is a red herring to the question, that is required to be
> addressed for both text tracks that change and text tracks that get added /
> removed.   I don't particularly see why that is limited to text track's
> defined in a Track element but not in-band.

You misunderstand: right now, nothing happens when the value of
language is changed. However, for the use case of in-band tracks
discussed here, we would need to introduce complicated changes that
have to deal with a change in language - something that is NOT yet
part of the spec.

I agree with Hixie that we should not make language and in particular
not kind mutable and expect anything to happen when we do. Language
and kind are two fixed metadata values per track and if you have some
data that does not fit into a track such defined, it should go into a
new track.

Hope that helps clarify.


Received on Wednesday, 2 April 2014 08:27:39 UTC