RE: Processor Profile, Content Profile and codecs

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

Some options:

1. It is substantively identical to profile; or
2. It is substantively identical to profile but with combination operators; or
3. It is the full MPD string; or
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.



-----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 Concolato
Multimedia Group / Telecom ParisTech

Received on Tuesday, 6 October 2015 11:49:55 UTC