Re: Processor Profile, Content Profile and codecs

On Wed, Oct 7, 2015 at 2:54 AM, Cyril Concolato <
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> 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.


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


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