Re: Processor Profile, Content Profile and codecs

On Thu, Oct 8, 2015 at 1:53 AM, Cyril Concolato <> wrote:

> Le 07/10/2015 17:48, Glenn Adams a écrit :
>> 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.
> I agree, it is very fragile to specify the profile outside of the document
> because the information might get lost in a workflow, or worse become
> invalid.
>> 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.
> That's what I fear.
>> 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.
> Well, I think this is a bit over-engineered. You can't build a video
> stream saying I use this feature from this profile and that feature from
> that other profile. You indicate the smallest profile that supports all
> features.

We had our reasons at the time. I suppose time will tell whether that
functionality is used or not.

>>             - 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
>>       o if F is required, but not supported, then abort processing
>>         unless abort is overridden
>>   * for each extension E in EPP
>>       o if E is required, but not supported, then abort processing
>>         unless abort is overridden
>> There is nothing difficult about this process.
> Difficult might not be appropriate word. Not affordable might be better. I
> want a *simple* way to find the profile. Checking each feature, each
> extension is too much for me.
> I'm considering applying the following algorithm, to find the profile
> identifier(s) to produce the codecs:
> - if the document is TTML1,
>     - if the ttp:profile attribute is present, use it
>     - if ebutt:conformsToStandard exist, use them and combine them

by 'combine them' I take this to mean map each "standard" to some registry
entry short identifier and then use the combination syntax

>     - otherwise return a full profile (which one?)

there is only one 'full' profile, which requires every feature to be
supported; this is probably not what you want, since it would potentially
exclude processing of documents (on platforms that implement #profile but
not the full set of features); it would be better to use one of the minimal
profiles instead, either the transformation or presentation profile; if the
context of use is presentation, then it would be the latter

> - if the document is TTML2,
>    - if the ttp:processorProfiles is present, use it
>    - if ttp:profile elements with designators are present, use them and
> combine them,

designators on a ttp:profile element are intended to designate that profile
not refer to another profile; the @use attribute on ttp:profile is what
refers to another profile (that serves as the basis for the new profile
being defined by the ttp:profile element); note also that TTML2 permits the
use of nested profiles;

>    - otherwise return a full profile

same comment as above about use of 'full profile'

> Would that work?
> Cyril
> --
> Cyril Concolato
> Multimedia Group / Telecom ParisTech
> @cconcolato

Received on Thursday, 8 October 2015 14:42:40 UTC