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.
- Will the TTML MIME type registration define a 'codecs' parameter (or 
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. 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.
- 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.
- 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.
- 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.
- 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.

Cyril



Le 18/09/2015 11:22, Michael Dolan a écrit :
>
> Colleagues-
>
> Per an action item from this week’s meeting, this is a status of the 
> registry, a next step and a proposed process to publication…
>
> The registry has been somewhat misnamed “Codecs Registry” and should 
> be more properly, “Profile Registry”.  (“Codecs” came from the primary 
> use in the DASH @codecs.)
>
> The table values were recently updated to reflect: 1) input from EBU 
> and 2) a decision to identify versions in the codes.
>
> We also recently agreed that codes should be limited to 4 characters 
> to facilitate future consideration in the MP4RA registry (and thus 
> needs a sentence or two in the body of the registry page that they are 
> so constrained).
>
> If everyone is satisfied with the above, then the registry is needed 
> by the industry ASAP.  Although the registry and its codes are cited 
> in TTML2 (but not TTML1), it is needed externally today for TTML1 
> (e.g. DASH). Therefore this needs to be put on a path to publication ASAP.
>
> The registry is an administrative tool with published rules for 
> maintenance.  As such, I believe this should published as a WG Report, 
> and thus only needs TTWG consensus to publish and revise.
>
> Regards,
>
>                 Mike
>
> -------------------------
>
> Michael A DOLAN
>
> TBT, Inc. PO Box 190
>
> Del Mar, CA 92014
>
> (m) +1-858-882-7497
>


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

Received on Friday, 18 September 2015 12:07:39 UTC