Re: TTML Profile Registry (aka Codecs Registry)

Sorry, been away - I have some comments too on this, inline:

On 19/09/2015 15:00, "Michael Dolan" <mdolan@newtbt.com> wrote:

>More more comments inline (from Paris 15e today :-)
>
>-----Original Message-----
>From: Cyril Concolato [mailto:cyril.concolato@telecom-paristech.fr]
>Sent: Friday, September 18, 2015 7:46 AM
>To: public-tt@w3.org
>Subject: Re: TTML Profile Registry (aka Codecs Registry)
>
>See comments inline (from Paris 13e :).
>
>Le 18/09/2015 15:14, Michael Dolan a écrit :
>> Cyril-
>>
>> (greetings from near L’arc de triomphe today)
>>
>> Thanks for your detailed review.
>>
>> CIL below.
>>
>>  Mike
>>
>> -----Original Message-----
>> From: Cyril Concolato [mailto:cyril.concolato@telecom-paristech.fr]
>> Sent: Friday, September 18, 2015 5:07 AM
>> To: public-tt@w3.org
>> Subject: Re: TTML Profile Registry (aka Codecs Registry)
>>
>> Hi all,
>>
>> Reading the registry, there are a few things that confused me:
>> - Is it up to other entities (like MPEG) to indicate how they intend
>> to use the identifiers (such as in the sample description entry of
>> TTML tracks for MPEG)? My guess is that it is what was intended, but
>> the registry should say so more clearly.
>>
>> MD>> The registry was intended to provide a short name for the profile
>> designator URI as requested by MPEG, nothing more.  Although MPEG's
>> intended use for it was for a codecs value, it is not constrained to
>>that.
>CC: That's my understanding too. I'm not sure it is that clear from the
>text. Something like "this registry can be used by other entities to
>exchange processor profiles in a compact way" could help.
>
>MD>> Good.

NM: Sounds good to me too.

>
>>
>> - Will the TTML MIME type registration define a 'codecs' parameter (or
>>
>> MD>> The TTML1 media type was defined long ago (although more recently
>> registered with IANA). It is defined in TTML1.  It cannot be changed
>> without substantively revising TTML1. See:
>> http://www.w3.org/TR/ttaf1-dfxp/#media-types-registration Although a
>> profile parameter is defined, it must be set to the fully qualified
>> profile designator. There is no codecs parameter.
>CC: Adding a parameter to a MIME type does not look like a big revision.
>I think it would be useful, outside of ISOBMFF, on HTTP for instance to
>know
>in advance if you can process the file or not.
>
>MD>> As useful as it may be, it's substantive which puts TTML1 through the
>standard CR->R process which I am confident no one would support given all
>our other work.

NM: Agreed.

>
>>
>> similar) or indicate that RFC 6381 is applicable to TTML? My guess is
>> that it should, I don't know if it does already and what the parameter
>name is.
>> In that case,  I think a link to where this is defined or a note
>> indicating that it will be defined is needed.
>>
>> MD>> Unfortunately, like a rapidly growing number of media type
>> MD>> "profiles",
>> it is not addressed in 6381.  As you know, the current plan in mp4-sys
>> is to revise 6381 to just the basics and then defer to the MP4RA for
>> the codecs values. For the unwary user, like all the other undefined
>> codec values, it's hard to discover them.
>CC: I meant that if some a TTML spec was using this registry, a link to it
>would have been useful, but since the MIME type does not use it, then it's
>fine.

NM: Conversely I don't think we'd have any objection to extending the MIME
type to using the registry; in face we have agreed to do that in TTML2
already.

>>
>> If this is not the case, if this registry is only intended for use in
>> ISOBMFF (ie only as 'video/mp4; codecs="stpp.<4cc>"'), or other
>> entities, then please say so.
>>
>> MD>> See above.  No.
>CC: See the proposed sentence above.
>>
>> - The presence of the codecs example which uses ISOBMFF's codecs
>> parameter without saying it is misleading. Either remove this example,
>> or provide another example with the TTML mime type, or clearly
>> indicate that the syntax using codecs="stpp.ttml.<4cc> is for
>> indicating tracks in ISOBMFF files as defined by MPEG.
>>
>> MD>> We should do the latter, thanks.
>CC: Fine, make sure it is written in informative style and that the real
>definition is in ISO 14496-30.

NM: Yes, with the small tweak that instead of <4cc> we'd have <TTML
profile registry defined subtype> to allow for any additional syntax we
might want in addition to simple 4 character codes.

>>
>> - The presence of 'stpp' as a 4CC identifier in the table is wrong.
>> 'stpp' is a 4CC defined by MPEG to differentiate between different
>> track types. It does not define a (processor) profile of TTML. Please
>remove it.
>>
>> MD>> Well, certainly unclear.  If we fix the example, we can clarify
>>this.
>>
>> - What does 'n/a' mean in the table? My guess is that it is used when
>> the same specification defines multiple profiles. I suggest merging
>> the "Profile Definition" and "Public Specification(s)" into one and
>> using a single reference (URL, section number ...) per identifier.
>>
>> MD>> "n/a" means per the dictionary.  In the case of the profile
>> MD>> designator,
>> it means there isn't one. The public spec (which is required and
>> sufficient) is in the other column.
>CC: For me, one link (one column) is sufficient, the most precise one:
>the "Profile Definition" if any or the "Public Specification". I don't see
>the point of having sometimes 2 values and sometimes 1 with n/a.
>
>MD>>  When present the profile designator is authoritative.  And, some
>specs
>(IMSC1) define more than one profile.

NM: Depends what you mean by 'authoritative'. There's always the
possibility for a spec to define subtle or complex constraints not thought
worthy of a feature designator. Ultimately it's the spec that defines
document and/or processor conformance rules for a profile, but profile
documents can be used to allow machine processing of feature sets to
derive suitability of a particular processor+document combination.

>
>> - Are the '+' and '|' combinators really necessary? They make the
>> parsing and generation more complex. Anyway this is a normative
>> definition. It should not be in the registry but in the MIME type
>definition.
>>
>> MD>> Agree that this syntax does not belong here.  This should be just
>> MD>> a
>> registry.  However, I believe that this syntax should be permitted in
>> codecs and other places.  The reason is that we have found it useful
>> to a) signal multiple conforming profiles within the same namespace
>> (e.g. conformant to any of TTML-FULL, IMSC1 and SDP-US); and 2)
>> conformant to multiple namespaces (e.g. TTML-FULL and SMPTE-TT).
>CC: Fine.

NM: The syntax has value, established in previous conversations, due to
the overlapping nature of different TTML profiles and the ability for
document creators to deliberately restrict their feature usage to a
sub-set of features common to multiple profiles. The syntax does not
necessarily have to be normative in the registry page but we should
certainly include it there for now since we don't have any other place we
can put it other than TTML2.


Nigel


>
>Cyril
>
>--
>Cyril Concolato
>Multimedia Group / Telecom ParisTech
>http://concolato.wp.mines-telecom.fr/

>@cconcolato
>
>
>

Received on Tuesday, 22 September 2015 12:54:29 UTC