Re: Processor Profile, Content Profile and codecs

On Thu, Oct 8, 2015 at 1:53 AM, Cyril Concolato <
cyril.concolato@telecom-paristech.fr> 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
> http://concolato.wp.mines-telecom.fr/
> @cconcolato
>
>
>