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

On Apr 9, 2014, at 23:27 , Pierre-Anthony Lemieux <pal@sandflow.com> wrote:

>> 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?
> 

Um, no, IF it is in the file, it’s in the kind user-data box in the track.  It doesn’t help to be vague, does it?

> 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.
>> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 9 April 2014 21:31:38 UTC