W3C home > Mailing lists > Public > public-html-media@w3.org > April 2014

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

From: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Wed, 9 Apr 2014 14:27:36 -0700
Message-ID: <CAF_7JxC1LtOSzbx4bfW18EG8w5hfrJg8pP0-Wo=eQ2sQqwnrjQ@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: Mark Watson <watsonm@netflix.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>, "public-html-media@w3.org" <public-html-media@w3.org>, "dash@lists.uni-klu.ac.at" <dash@lists.uni-klu.ac.at>
> it can really help to have self-describing content.

Yes. The "self-description" might not always be in the box specified
at [1], and the suggestion is that MSE should support alternative
means.

[1] http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0055.html

Makes sense?

Thanks,

-- Pierre

On Wed, Apr 9, 2014 at 2:22 PM, David Singer <singer@apple.com> wrote:
> 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 <pal@sandflow.com> 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 <watsonm@netflix.com> 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
>>> <cyril.concolato@telecom-paristech.fr> 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:
>>>> http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=14553
>>>> 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
>>>>> <http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0018.html> 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
>>>>> <http://lists.w3.org/Archives/Public/public-html-media/2014Apr/0015.html> 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
>>>>> <https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/isobmff-byte-stream-format.html>
>>>>> 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
>>>> http://concolato.wp.mines-telecom.fr/
>>>> @cconcolato
>>>
>>>
>>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
Received on Wednesday, 9 April 2014 21:28:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:03 UTC