RE: TTML Profile Registry (aka Codecs Registry)

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.

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

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

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

Cyril

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

Received on Saturday, 19 September 2015 14:00:52 UTC