Re: Processor Profile, Content Profile and codecs

On Tue, Oct 6, 2015 at 5:39 AM, Cyril Concolato <> wrote:

> 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| <
> on the root|tt|element, (2) one or more|ttp:profile| <
> 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 <
> >."
> 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?

TTML1 did not define the notion of a content profile, only processor
profile, which it simply referred to as 'profile', as specified by the
ttp:profile attribute or element.

In TTML2 we have more clearly distinguished between these, and defined two
new parameter attributes:

   - ttp:processorProfiles
   - ttp:contentProfiles

These may refer to different sets of profiles. In TTML2, we also defined a
method for inferring processor profile from content profile in the case
that only content profile is specified.

> For TTML1 [1], the notion of processor profile does not exist.

I'm afraid you have it backwards. Only processor profile exists in TTML1.
But it was simply called 'profile'.

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

I think you mean "is equivalent to the notion of processor profile in

> The differences with TTML2 seems to be that:
> - there is no default or inferred profile.

Actually, it (TTML1) defined the default as the DFXP Transformation profile
(in the absence of any other information):

"If neither ttp:profile
<> attribute nor
ttp:profile <> element
is present in a *Document Instance*, and if the *Document Interchange
Context* does not make an implicit or explicit reference to a pre-defined
profile or does not specify a *Profile Definition Document* or another
equivalent set of feature designations, then the DFXP Transformation
profile applies."

In TTML2, the default is determined by the "[construct default processor
profile]" algorithm, which can yield one of five results: inferred
processor profile or one of four standard profiles depending on whether
processor is primarily a presentation or transformation processor, and
whether ttp:version is specified (and what its value is).

> - the ttp:profile element does not have a designator attribute.

In TTML1 it does not; in TTML2 it does.

> So for cases where the ttp:profile attribute is not used, how can the
> profile identifier be determined?

Both TTML1 and TTML2 define how to determine the effective processor
profile in this case, though TTML2 is more explicit about the process.

> Are there recommendations in derived TTML specifications (EBU, SMPTE, ...)
> to always set the ttp:profile attribute?

SMPTE-TT contains the following language. It is not clear to me if this
language requires the presence of ttp:profile attribute or not. Though one
may reasonably infer that if it is present, then it must use the designator
so specified.

"This profile shall be referenced in a conforming SMPTE-TT document by the
designator: http://www.smpte- This designator may be
used in the same manner as designators in TTML Section 5.3. "

It is not clear to me whether EBU-TT-D requires, allows, or prohibits the
use of 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.

semantically, yes, but syntactically, no

> Cyril
> [1]
> [2]
> [3]
> --
> Cyril Concolato
> Multimedia Group / Telecom ParisTech
> @cconcolato

Received on Tuesday, 6 October 2015 17:00:36 UTC