Re: [MSE] Summary of "Resolving Bug 24370" thread and proposed next steps

On Mon, Apr 7, 2014 at 5:05 PM, Aaron Colwell <acolwell@google.com> wrote:
> In the interest of trying to move forward on the MSE bug 24370, I'm going to
> try to provide a high level summary of the "Resolving Bug  24370" thread and
> propose a way forward. Please forgive me if I accidentally misrepresent
> something.
>
> Summary:
> 1. Changes in languages are allowed during the course of a presentation, but
> there is some debate about how these should be represented in HTML5. The
> majority opinion in the thread appears to prefer immutable language & kind
> attributes and track objects being added & removed to reflect language
> changes.
>
> 2. Currently track kind can't be signalled in ISO-BMFF content. A new
> box/atom needs to be defined to signal this information.
>
> 3. No argument or example has been given that requires Javascript to
> explicitly change the language or kind of a track. My interpretation of Jim
> Ley's comment is that the application only wants to be notified of changes
> in the media and does not need to be able to change the values on the
> tracks.
>
> 4. Bob Lund and David Singer appear to explicitly support removing the
> mutable attribute definitions. I believe Silvia Pfeiffer implicitly supports
> their removal based on the arguments she has made in the thread. I also
> support removal of the mutable attribute definitions.

I thought I was quite explicit about that. ;-)

> Proposed Next Steps:
> 1. Remove the mutable attribute definitions for language and kind. I'm
> unclear about the process around this sort of change since this is not an
> "at risk" feature. I'd hate to have to go through a long Last Call process
> again for this.
>
> 2. Work with David Singer and other MPEG savy folks to define a new box/atom
> for ISO-BMFF to carry track kind information. This definition could
> initially live in the ISO-BMFF byte stream format spec while it is waiting
> to be officially standardized by MPEG.
>
> 3. Silvia and/or Hixie update the HTML specs to reflect the expected
> behavior for language & kind changes. I don't have concrete proposals for
> this at the moment, but it seems like there has been confusion around the
> intended behavior when track changes occur mid-playback and whether or not
> the track attributes can change value during playback.

I think two things should be done in the HTML spec:
* explain that language & kind changes have no effect
* recommend, possibly even require that in-band tracks with cues of
several languages should be exposed to HTML as multiple text tracks

I think taking this back to the open bug in the WHATWG would be a good
way to continue the discussion with Hixie.

> Please indicate your support or opposition to the summary and proposed next
> steps.

You have my support.

Cheers,
Silvia.

Received on Monday, 7 April 2014 07:52:33 UTC