Re: Processor Profile, Content Profile and codecs

Le 06/10/2015 13:49, Michael Dolan a écrit :
>>> TTML1 the 'profile' MIME parameter is equivalent (but with long URI values) to the 'codecs' we are discussing.
> That was my earlier question - what is  "codecs" exactly? (Yes, TTML1 profile is processor profile).
I answered previously to this question based on the Registry document. 
The registry seemed clear: profiles in the registry correspond to 
processor profiles which are different from content profiles. However, 
on further reading indeed it is not so clear. It uses terminology that 
is related to TTML2 (the distinction between processor profile and 
content profile, the link to TTML 2 profile combination) but at the same 
time only refers to TTML1 profiles (BTW, the links to CFF profiles are 
broken). Is the registry applicable to TTML1 only or to TTML2 only or to 
both? I guess both, but this could be clarified.
> Some options:
> 1. It is substantively identical to profile; or
> 2. It is substantively identical to profile but with combination operators; or
If it is meant to be applicable to both TTML 1 and TTML2, then the 
'codecs' parameter would be equivalent to the 'profile' parameter of 
TTML1 (i.e. to the ttp:profile attribute) but equivalent to the 
'ttp:processorProfiles' attribute in TTML2.
> 3. It is the full MPD string; or
No. How MPEG defines MPD attributes or ISOBMFF's MIME type is MPEG's 
business. It should be based on what the TTWG defines, but it is not the 
topic here.
> 4. Combinations of the above.
> Our POR now is #2.
>    But I think we need ot return to this after we chat some more in MPEG.
MPEG can discuss about it. But MPEG (or any other organization) will not 
be able to do anything if the TTML specs are not clear. They will not be 
able to make use of the registry, if the process to retrieve the 
processor profile identifier from a document is not well defined. I 
think some guidelines should be added to the registry document.


> Regards,
>  Mike
> -----Original Message-----
> From: Cyril Concolato []
> Sent: Tuesday, October 6, 2015 4:40 AM
> To: 'TTWG' <>
> Subject: Processor Profile, Content Profile and codecs
> Hi all,
> Consider the following scenario:
> - someone has authored a TTML document
> - someone else needs to generate the "codecs" attribute for this document (either because the document is served by an HTTP server which wants to compare the associated processor profile with what the HTTP client accepts, or because it needs to add a codecs attribute to a DASH MPD, or because the document is packaged in an MP4 and the MP4 is to be fed to a MediaSource Buffer or described in a DASH MPD).
> The question is simple: how to find out which processor profile a given document conforms to?
> For TTML2 [2], there is a definition of 'processor profile' and a process to find it out:
> "Processor profiles are declared by using (1) the|ttp:processorProfiles| <;charset=utf-8#profile-attribute-processorProfiles>attribute
> on the root|tt|element, (2) one or more|ttp:profile| <;charset=utf-8#profile-vocabulary-profile>elements
> of type|processor|, or (3) a combination of these two mechanisms. If not declared, a processor profile is inferred from a declared content profile or from adefault profile <;charset=utf-8#terms-default-profile>."
> If the attribute is used, this seems clear to me.
> If elements are used, the designator may not be present: "if not specified, the defined profile is considered to be an undesignated profile". I guess this means that the processor profile in that case is considered "not declared" and then inferred or defaulted.
> If the profile is inferred or defaulted, there seems to be a way to find the associated designator, but I'm not sure, as it seems to be a complex task to do [3]. Are there restrictions in derived specs to always either use the attributes?
> For TTML1 [1], the notion of processor profile does not exist. The spec however says:
> "The profile of TTML that must be supported by a TTML/Content Processor/in order to process a/Document Instance/is determined either
> (1) by specifying a|ttp:profile|attribute on the root|tt|element, as defined by*6.2.8 ttp:profile* <>, or (2) by including one or more|ttp:profile|elements in the|head|element, in accordance with*6.1.1 ttp:profile* <>."
> I understand that the notion of profile in TTML1 is equivalent to the notion of 'processor profile' in TTML1;.
> The differences with TTML2 seems to be that:
> - there is no default or inferred profile.
> - the ttp:profile element does not have a designator attribute.
> So for cases where the ttp:profile attribute is not used, how can the profile identifier be determined? Are there recommendations in derived TTML specifications (EBU, SMPTE, ...) to always set the ttp:profile attribute?
> Additionally, the "profile" parameter defined in TTML1's MIME type registration says:
> "The document profile of a TTMLDocument Instance may be specified using an optional|profile|parameter, which, if specified, the value of which must adhere to the syntax and semantics of|ttp:profile|parameter defined by Section*6.2.8 ttp:profile* <>of the published specification."
> IIUC, this means that for TTML1 the 'profile' MIME parameter is equivalent (but with long URI values) to the 'codecs' we are discussing.
> Cyril
> [1]
> [2]
> [3]
> --
> Cyril Concolato
> Multimedia Group / Telecom ParisTech
> @cconcolato

Cyril Concolato
Multimedia Group / Telecom ParisTech

Received on Tuesday, 6 October 2015 12:23:51 UTC