RE: TTML Profile Registry (aka Codecs Registry)

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.

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

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.

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.

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

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

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

Cyril

Regards,
	Mike


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 13:15:33 UTC