Re: [MSE] Resolving Bug 24370

+1

Cyril

Le 02/04/2014 10:26, Silvia Pfeiffer a écrit :
> On Wed, Apr 2, 2014 at 6:04 PM, Jim Ley <jim.ley@gmail.com> wrote:
>> On 2 April 2014 01:17, Aaron Colwell <acolwell@google.com> 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."
>> http://www.whatwg.org/specs/web-apps/current-work/#text-track-language
> 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.
>
> Regards,
> Silvia.
>


-- 
Cyril Concolato
Multimedia Group / Telecom ParisTech
http://concolato.wp.mines-telecom.fr/
@cconcolato

Received on Wednesday, 2 April 2014 12:20:49 UTC