Re: [MSE] Resolving Bug 24370

On Wed, Apr 2, 2014 at 6: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.
>

I think there are 2 separate issues here.
1. How are language changes within an inband track supposed to be
represented in HTML5?
2. Should JavaScript be allowed to modify the kind & track attributes on
the xxxTrack objects?

I am mainly trying to resolve #2 because it directly effects MSE, but I
believe the HTML5 spec needs to clarify #1.

Personally, I think language changing within a track is a reality of
existing broadcast content and forcing a track removal and then addition on
a language change doesn't feel like it is truly expressing what is going
on. You have the same track but the language just changed. Why not simply
allow the read-only attribute change value and fire a "change" event. The
application can respond to this event and determine whether it wants to
select a new track or not. As long as the attribute is simply mirroring
what is in the media data, I think everything is fine. It is less clear to
me that JavaScript is in the right position to know the proper language so
I'm definitely leaning towards preventing JavaScript maniplation of this
information. I feel like this is a minimal impact compromise since all the
UA has to do is signal that attributes on a track changed and nothing more.


>
> 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.
>>
>
> I can see that argument, but the spec would need to say that instead,
> simply making them non-mutable doesn't meet that use case.  I don't also
> see it really solving the UA and user issues that were raised as the
> motivation for not having mutable, but certainly it would solve the use
> cases.
>

I agree that tracks should be able to come and go, but I would hate for us
to muddy the semantics of what is happening in the actual underlying media.
The broadcast scenario isn't actually creating a new track. It is simply
changing the properties of an existing track. I think added complexity only
occurs if the UA has to do something substantial w/ such changes.


>
>
>> 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.
>>
>
> Well it's very useful if you have built something on top of the track
> metadata to provide the user with a choice - language and kind is not
> actually enough for that (how do you identify which is the Audio Described
> version) to it will be have to controlled out of band anyway, but the point
> was, the spec already requires it to not be read only from a track list, it
> doesn't seem to be any value in not having mutable from elsewhere.
>

Does JavaScript need to really be able to change the value or does the
application just want to see when the value changes in the underlying media?

Aaron