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

There's
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24563
and that just got resolved with Aaron's new proposal, which also makes
a lot of sense to me.

I think you can close this ACTION.

Cheers,
Silvia.


On Wed, May 7, 2014 at 3:54 AM, Paul Cotton <Paul.Cotton@microsoft.com> wrote:
> At the HTML WG F2F meeting I was assigned Media TF ACTION-65:
>
> http://www.w3.org/html/wg/media/track/actions/65
>
> which refers to the point 3 in the email below:
>
>
>
>>3. Sylvia and/or Hixie update the HTML specs to reflect the expected
>> behavior for language & kind changes.
>
>
>
> Have such bugs been filed and/or processed for HTML5?  If so could you give
> me pointers so that I can close out the ACTION item?
>
>
>
> If not do you need any further information to open such bugs?
>
>
>
> /paulc
>
>
>
> Paul Cotton, Microsoft Canada
>
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>
> Tel: (425) 705-9596 Fax: (425) 936-7329
>
>
>
> From: Aaron Colwell [mailto:acolwell@google.com]
> Sent: Monday, April 07, 2014 3:06 AM
> To: <public-html-media@w3.org>
> Subject: [MSE] Summary of "Resolving Bug 24370" thread and proposed next
> steps
>
>
>
> 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.
>
>
>
> 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. Sylvia 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.
>
>
>
>
>
> Please indicate your support or opposition to the summary and proposed next
> steps.
>
>
>
> Thank you,
>
> Aaron

Received on Sunday, 11 May 2014 20:35:25 UTC