Re: Processor Profile, Content Profile and codecs

On 06/10/2015 12:49, "Michael Dolan" <mdolan@newtbt.com> wrote:

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

It is none of the above. It is:

5. An indication of the required processor capabilities needed to process
the document expressed using a syntax formed of short codes and
combination operators.

The existing profile in the TTML 1 IANA registration requires a single URI
profile designator. The new syntax does not use URIs directly, but
indirectly. Further, the statement in TTML 1 ยง5.2: "may be any URI that
feasibly dereferences a TTML Profile Definition Document" is not reversed
exactly, but we do explicitly permit URIs that are known not to
dereference to a profile definition document.

Kind regards,

Nigel


>
>Our POR now is #2.  But I think we need ot return to this after we chat
>some more in MPEG.
>
>Regards,
>
> Mike
>
>-----Original Message-----
>From: Cyril Concolato [mailto:cyril.concolato@telecom-paristech.fr]
>Sent: Tuesday, October 6, 2015 4:40 AM
>To: 'TTWG' <public-tt@w3.org>
>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|
><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?
>
>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;.
>
>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*
><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.
>
>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:00:33 UTC