- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Fri, 18 Sep 2015 16:46:23 +0200
- To: public-tt@w3.org
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