Re: Processor Profile, Content Profile and codecs

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Wednesday, 7 October 2015 16:48

On Wed, Oct 7, 2015 at 2:54 AM, Cyril Concolato <cyril.concolato@telecom-paristech.fr<mailto:cyril.concolato@telecom-paristech.fr>> wrote:
Le 06/10/2015 15:19, Nigel Megitt a écrit :
On 06/10/2015 12:39, "Cyril Concolato"
<cyril.concolato@telecom-paristech.fr<mailto: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.
Having two dimensions of profiles really doesn't help. Audio streams, video streams don't have that distinction.
As a player implementation, your really want to be able to tell rapidly: "Can I play this file?". As a packager (like MP4Box) or as a server, you want to be able to provide that information to a player. This may need some processing of the file, but that processing should be limited (finding an attribute value on the root element is ok).

The only utility in declaring a content profile is for validation/verficiation purposes. It allows the author to declare which content constraints were used when constructing the document.

For the purpose of a decoding content, the processor profile is more relevant. This is why the current profile MIME parameter, and presumably, a new codecs parameter should focus only on processor profile.


Are there restrictions in derived specs to always either
use the [ttp:profile or ttp:processorProfiles] attributes?
No there aren't such restrictions.
That is really annoying because it makes the job of server/packager difficult, which means that they will probably put a catch-all profile (if any), which won't be useful.
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
Yes, sorry for the typo.
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."
Thank you for the pointer. I will have to check what the part about "Document Interchange Context" means but this looks quite complex to me. Would it be correct to find the profile identifier as follows: a) if a ttp:profile attribute exists, find in the registry the short name corresponding to the attribute value, b) if not, use 'tt1t' ? I fear this wouldn't be correct.

Document Interchange Context abstracts the delivery context, allowing, for example, the envelope or container to specify a profile without doing so in the document itself. Though I would always prefer the document to do so.

As for finding what processor profile applies to a document, it is rather more complicated than simply looking for a ttp:profile attribute, even in TTML1. This is because it is possible to declare a profile within the document instead of by reference, i.e., by using the ttp:profile element.


- 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.
According to the registry, profiles have designators. According to 5.2 in TTML1, profiles have designator. It seems very hard to determine if a document can be played by a player by inspecting all features to see if they match existing profiles.

Not really. This has been implemented multiple times without difficulty. The process works as follows:

  *   determine the effective processor profile EPP that applies to document D
  *   for each feature F in EPP
     *   if F is required, but not supported, then abort processing unless abort is overridden
  *   for each extension E in EPP
     *   if E is required, but not supported, then abort processing unless abort is overridden

There is nothing difficult about this process.


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.
That's bad, as it makes it practically impossible for a player to know in advance if it can play the content.

The algorithm "determine the effect processor profile" always returns some profile, so that is the profile the processor should nominally use.



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.
The registry indicates that "urn:ebu:tt:exchange:2015-09" is a profile designator. I would expect to find it in the ttp:profile attribute. Please clarify the registry!
The fact that the use of the "ebuttm:conformsToStandard" attribute is only a recommendation not a requirement is not good. There needs to be a simple way to identify a EBU-TT document!

I agree with this sentiment.

TTML2 deprecates ttp:profile attribute in favour of ttp:processorProfiles, ttp:contentProfiles etc. The ttp:contentProfiles attribute closely matches the semantic of ebuttm:conformsToStandard, in my opinion. Nevertheless I don't think there's any proposal to make the presence of those attributes mandatory, and it would be unhelpful for some parts of the author->distribute chain to require them, so I would object to it. However it may be reasonable for an encoder/packager to require their presence on documents provided as input – that's out of scope of our specifications though.



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?
A better understanding of TTML1!

My ultimate goal is to be able to produce, with GPAC, MP4 files and DASH content that use TTML documents and that can be used meaningfully. This currently looks desperately impossible. I'm wondering if I shouldn't stop working on TTML in MP4 ...

I agree that the lack of proper document internal declaration of processor profile is frustrating, and I feel the same. However, to conclude it is impossible to meaningfully use TTML seems an exaggeration. Let's look at the possible scenarios:

Scenario #1 - Processor Supports Profile System

  *   EPP is always determined, but may not match authorial intentions in case no document internal/external evidence declares profile;
  *   if EPP is defaulted, and default requires a feature/extension not supported, then processing may be aborted if not overridden; this would suggest the default be lenient (fully or relatively unconstrained); otherwise, unsupported features will be ignored;

Scenario #2 - Processor Does Not Support Profile System

  *   processing never aborts processing, but simply ignores unsupported features

There is nothing impossible about performing this processing. Obviously, it makes sense to always declare a profile within a document, but apparently some communities have not chosen to do this for whatever reason.

I disagree: it does not make sense to always declare a profile within a document. This depends which part of the chain you are in and what other knowledge is available. For example a workflow may permit a document to be authored and then subsequently in a separate process to be transformed to compute and insert the profile details.

In data rate constrained environments especially when there are a large number of documents, e.g. in a live streaming, it is likely to be preferable to define the profile in use across the end points and avoid the large amount of redundant data definition.

It must be possible at least to permit this as an operational practice even if it is less generally useful. For the intersection of that practice and Cyril's use case I would expect there to be some kind of independent input like a command line flag, config file etc to tell the software what profile to use in the absence of other information – I'm veering away from the scope of the working group though here.

Perhaps they believe that a processor will always choose either the fully unconstrained 'null' profile or automatically choose the profile they are using due to context of use (e.g., processors in region R assume a specific profile commonly used in region R).

Yes, that (context of use) is a likely practical solution.

Nigel




Cyril


--
Cyril Concolato
Multimedia Group / Telecom ParisTech
http://concolato.wp.mines-telecom.fr/

@cconcolato