- From: Michael Dolan <mdolan@newtbt.com>
- Date: Fri, 18 Sep 2015 06:14:50 -0700
- To: <public-tt@w3.org>
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