Re: Processor Profile, Content Profile and codecs

On 06/10/2015 12:39, "Cyril Concolato"
<cyril.concolato@telecom-paristech.fr> 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?

That's easy. The answer is always none - a document conforms to a content
profile and a processor conforms to a processor profile. You might want to
ask how to find out which processor profile is required to process a
document that may optionally state a content profile though.

>
>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|
><https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?conten

>t-type=text/html;charset=utf-8#profile-attribute-processorProfiles>attribu
>te 
>on the root|tt|element, (2) one or more|ttp:profile|
><https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?conten

>t-type=text/html;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
><https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?conten

>t-type=text/html;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?

No there aren't such restrictions.

>
>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*
><http://www.w3.org/TR/ttml1/#parameter-attribute-profile>, or (2) by
>including one or more|ttp:profile|elements in the|head|element, in
>accordance with*6.1.1 ttp:profile*
><http://www.w3.org/TR/ttml1/#parameter-vocabulary-profile>."
>I understand that the notion of profile in TTML1 is equivalent to the
>notion of 'processor profile' in TTML1;.

s/'processor profile' in TTML1/'processor profile' in TTML2

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

There is: from TTML1SE §5.2: "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."

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

What would a designator attribute be for? Features have designators, not
profiles. There is a use attribute though.

>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?

In TTML1SE § 5.2, a Note includes: "it is permitted that the Document
Interchange Context determines the applicable profile through private
agreement, out-of-band protocol, or common use (between sender and
receiver) of a profile defined by an external specification."

In other words, the spec is deliberately silent on how the profile
identifier can be determined if it is not within the document itself.

I'm not aware of a specific recommendation to set the ttp:profile
attribute. In EBU-TT it is actually prohibited - an alternate
ebuttm:conformsToStandard element is permitted, cardinality 0..*, to
indicate all of the standards to which the EBU-TT document claims
conformance. For EBU-TT Part 1 v1.1 there is a recommendation to include
the value "urn:ebu:tt:exchange:2015-09". The EBU did not consider that the
ttp:profile attribute carries the same semantic.

>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*
><http://www.w3.org/TR/ttml1/#parameter-attribute-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.

The use of short codes instead of long URI values is significant. The
addition of extra syntax would also be significant. But if you omit the
operators and consider the short code and the URI to be synonyms, then
yes, I think there's a form of equivalence. What do you conclude or gain
from that?

Nigel


>
>Cyril
>
>[1] http://www.w3.org/TR/ttml1/

>[2] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html

>[3] 
>https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?content

>-type=text/html;charset=utf-8#semantics-processor-profile-processing
>
>-- 
>Cyril Concolato
>Multimedia Group / Telecom ParisTech
>http://concolato.wp.mines-telecom.fr/

>@cconcolato
>
>

Received on Tuesday, 6 October 2015 13:20:26 UTC