Re: Processor Profile, Content Profile and codecs

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

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

Cyril

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

Received on Wednesday, 7 October 2015 08:55:20 UTC