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

Cyril

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

Received on Friday, 18 September 2015 14:46:51 UTC