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

all agreed, but in a pipeline workflow, where the content creator is not the HTML author (not unlikely) it can really help to have self-describing content.

On Apr 9, 2014, at 21:22 , Pierre-Anthony Lemieux <> wrote:

>> I've no objection to specifying a way to add them into the file, but not all files will have this,
>> so it remains useful to be able to specify these programmatically.
> Right. It seems pretty limiting to assume that all ISOBMFF files will
> have the proposed box. In particular, some content might already have
> the information outside the ISOBMFF file, e.g. in a manifest, and/or
> in existing boxes.
> Based on the short discussion this morning, it sounds like an
> immediate question is how to tie a 'kind' value with a specific track
> at init, before a TextTrack object is created. Did I get this right?
> Best,
> -- Pierre
> On Wed, Apr 9, 2014 at 10:44 AM, Mark Watson <> wrote:
>> My comment on this at the meeting was that the track kinds need to be
>> available to the application before any media is downloaded so that the
>> application can decide what media to download. So, they will be in the
>> manifest.
>> I've no objection to specifying a way to add them into the file, but not all
>> files will have this, so it remains useful to be able to specify these
>> programmatically. However, once specified for a track it does not need to be
>> possible to change the kind.
>> ...Mark
>> On Wed, Apr 9, 2014 at 5:56 PM, Cyril Concolato
>> <> wrote:
>>> Hi all,
>>> As a data point for this discussion, Bob Lund and I submitted a
>>> contribution to the MPEG meeting, held last week in Valencia, to highlight
>>> the problem in the mapping of DASH Role to HTML5 kind. The contribution is
>>> available here:
>>> The MPEG group agreed to define 3 new role values ("description", "sign"
>>> and "metadata") as part of the amendment 2 of DASH.
>>> Cyril
>>> Le 07/04/2014 09:05, Aaron Colwell a écrit :
>>>> 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
>>> --
>>> Cyril Concolato
>>> Multimedia Group / Telecom ParisTech
>>> @cconcolato

David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 9 April 2014 21:23:07 UTC