Re: Processor Profile, Content Profile and codecs



On 07/10/2015 09:54, "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.

Well it doesn't help in your use cases immediately below, but it does help
in other parts of the chain and for other user types.

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

It's a catch-all for 'the stuff that happens outside of the document that
is not in the TTML spec' so it is as complex as your workflow is.

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

> 
Right, sorry about that. Other threads have overtaken this particular
point.

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

Profile designators exist regardless of the use of the ttp:profile
attribute. I don't think there's anything to do in 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!

That's partly an EBU issue; I think your point is that if TTML were to
require a ttp:profile attribute then this problem wouldn't have arisen.
The trouble with the ttp:profile attribute is you can only have one of
them and it is very unhelpful if you want to author a document that
conforms to multiple profiles simultaneously, which is often possible and
desirable. Note that ttp:profile attribute is deprecated in TTML2 in
favour of ttp:contentProfiles and ttp:processorProfiles which allow this
richer semantic. 

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

Fair enough!

>
>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 Thursday, 8 October 2015 08:22:04 UTC