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: David Singer <singer@apple.com>
Date: Wed, 09 Apr 2014 23:52:08 +0200
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>
Message-id: <99FAB707-FB7C-4024-82E7-EED9BED910AF@apple.com>
To: Pierre-Anthony Lemieux <pal@sandflow.com>

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

> Hi David,
> 
>> Um, no, IF it is in the file, it's in the kind user-data box in the track.
> 
> It might be in a manifest, outside of the ISO BMFF file.


OK, we’re at cross purposes.  AFAIK, no-one is saying it has to be in the file, but that we want a standard place to put it so it can be.  

When writing the HTML, if the item embedded in HTML is a DASH manifest, then yes, you look at that.  If the item is an MP4 file, look at that, and so on.  When writing the manifest, you might need to look at the embedded files to find their language and kind, and so on….


> 
> Thanks,
> 
> -- Pierre
> 
> On Wed, Apr 9, 2014 at 2:31 PM, David Singer <singer@apple.com> wrote:
>> 
>> 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.
>> 

David Singer
Manager, Software Standards, Apple Inc.
Received on Wednesday, 9 April 2014 21:54:58 UTC

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