Re: [MSE] Resolving Bug 24370

On Thu, Apr 3, 2014 at 5:30 AM, Aaron Colwell <acolwell@google.com> wrote:
>
>
> 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?

Do you think we should mention language changes as another example
where multiple tracks are created in
http://rawgit.com/silviapfeiffer/HTMLSourcingInbandTracks/master/index.html
? Would that help clarify?

Cheers,
Silvia.

> 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

Received on Sunday, 11 May 2014 19:38:43 UTC