Re: Draft TTML Codecs Registry - Issue-305

On Mon, May 19, 2014 at 6:27 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  On 18/05/2014 02:39, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
> On Fri, May 16, 2014 at 2:51 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:
>
>>  On 15/05/2014 23:45, "Glenn Adams" <glenn@skynav.com> wrote:
>>
>>   Could you cite the exact documents/sections that you are referring to
>> by "quoted text"?
>>
>>
>>  I was referring to the text from ISO/IEC 14496-12, AMD2 that Mike
>> included in his email.
>>
>
>  I assume you refer to:
>
>
>  Correct.
>
>
>   From 14496-12, AMD2:
>>
>> namespace is a null-terminated field consisting of a space-separated
>> list, in UTF-8 characters, of
>> one or more XML namespaces to which the sample documents conform. When
>> used for metadata,
>> this is needed for identifying its type, e.g. gBSD or AQoS [MPEG-21-7]
>> and for decoding using XML
>> aware encoding mechanisms such as BiM.
>>
>> schema_location is an optional null-terminated field consisting of a
>> space-separated list, in UTF-
>> 8 characters, of zero or more URL’s for XML schema(s) to which the sample
>> document conforms. If
>> there is one namespace and one schema, then this field shall be the URL
>> of the one schema. If there
>> is more than one namespace, then the syntax of this field shall adhere to
>> that for xsi:schemaLocation
>> attribute as defined by [XML]. When used for metadata, this is needed for
>> decoding of the timed
>> metadata by XML aware encoding mechanisms such as BiM.
>
>
>  This tells me nothing of why one would want to signal content profile or
> why one would want to communicate namespace usage separately (from XMLNS
> declarations found in the document).
>
>
>  The common text "When used for metadata, this is needed for … decoding
> using XML aware encoding mechanisms such as BiM." in both paragraphs
> appears to indicate the intended purpose of providing the information.
> Arguably in our case we don't need a generic XML processing feature in
> which case perhaps no value for this attribute is needed at all. That
> doesn't seem to be the case though given the level of interest in this
> topic.
>
>
>>  Regarding
>>
>>  The processing behaviour may or may not be expressed in terms of
>>> TTML1-style profile features. There's no other language other than prose
>>> available for this purpose (that I know of).
>>
>>
>>  If a specification defines processing semantics that must be supported
>> in order for a processor to conform to the specification, and if that
>> specification does not define any feature/extension, then I would firstly
>> view that as a broken specification; however, another potential
>> interpretation is that the specification implies an otherwise unnamed
>> feature/extension whose feature/extension designation corresponds to the
>> profile designation. That is, the profile designation serves as a
>> high-level, un-subdivided designation of the set of semantics mandated by
>> compliance with the defined profile.
>>
>>
>>  Concerning 'broken' I note also TTML1SE §3.3 [1] does require an
>> implementation compliance statement (ICS) to support claims of compliance –
>> it would seem reasonable to require this as an input to the registration
>> process. Or in TTML2 weaken this requirement.
>>
>>  [1] http://www.w3.org/TR/ttml1/#claims
>>
>>
>>  This might be a way out of this without having to have such
>> specifications define individual, fine-grained feature/extension
>> designations.
>>
>>
>>  Yes, that would be helpful to lower the barrier to entry.
>>
>>
>>  Anyway, I'm still waiting for a someone to articulate a use case for
>> signaling a content profile, or any aspect of a content profile (e.g.,
>> namespaces, schemas).
>>
>>
>>  Did Mike's email including the relevant sections from 14496-12 not do
>> this?
>>
>
>  No, it does not. I repeat, signaling content profile can only have two
> purposes in the context of decoding/processing as far as I can tell:
>
>  (1) to validate incoming document, which is not yet done by any TTML
> processor, though we are looking at adding a @validation attribute in TTML2
> that could be used to require this;
>
>  (2) to imply a processor (decoder) profile in lieu of explicitly
> signaling of a processor profile;
>
>
>  (3) to support generic XML processing functionality not specific to TTML.
>

Then it would seem to be outside the scope of TTML.


>
>
>
>  In the context of the current thread, it seems only the second of these
> is potentially relevant. However, I have to ask why one wouldn't simply
> signal a processor profile instead of using a more complex process of
> signaling a content profile and then having the decoder/processor infer a
> processor profile from that content profile.
>
>
>  My proposal is to signal a specification not a content profile.
>

I don't know what that means.


> This meets both the stated requirement in 14496-12 of identifying set of
> {namespace, schema} and the requirement to direct the choice of processor
> profile.
>

I don't think so.


> The content provider may not want the receiving system to infer 'any
> possible' processor profile from the content profile but instead describe
> 'must be one of these' processor profiles.
>

Sure, in which case the content author should reference or specify a
processor profile in the document, in which case signaling a content
profile has no purpose.


>
>
>
>  If there are other reasons for signaling content profile (in the context
> of the current thread) then I haven't seen them articulated.
>
>
>
>>
>>
>>
>>
>>
>> On Thu, May 15, 2014 at 1:28 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:
>>
>>>  Since namespaces and schemas define and constrain document contents
>>> without defining processing behaviour the quoted text defines a content
>>> profile declaration. It isn't asking for anything concerning specific
>>> processor capabilities but is merely describing  the contents of the
>>> document. The information may be used for downstream processing by context
>>> aware processors. The reference to namespace-aware compression makes clear
>>> that the mapping from whatever label scheme we choose to namespaces and
>>> schemas is important.
>>>
>>>  However it's clear that we expect the receiving system to use the
>>> information to direct its processing, as described previously.
>>>
>>>  Consider that the specification of a TTML variant x consists of the
>>> union of a content profile Cx and a description of processing behaviour Bx,
>>> which I'll express as S = C + B. The content profile shall itself reference
>>> one or more namespaces and schema locations. The processing behaviour may
>>> or may not be expressed in terms of TTML1-style profile features. There's
>>> no other language other than prose available for this purpose (that I know
>>> of).
>>>
>>>  It is possible to define two specifications S1 and S2 where S1 = Cx +
>>> Bx and S2 = Cx + By, i.e. the same contents are processed with different
>>> behaviour. By the quoted text there is no need to differentiate between
>>> them from an ISO 14496 perspective. However we understand from our
>>> knowledge of the problem space that it may be useful to signal to a
>>> receiving system which behaviour set is desirable. And it may be helpful in
>>> a receiving system to differentiate between the available behaviours in
>>> order to provide the optimal experience.
>>>
>>>  Would it be contrary to the spirit of the ISO wording to assign short
>>> labels each corresponding to some Specification, and for receiving systems
>>> to be expected to dereference (using a cached lookup table!) from those
>>> labels to the namespaces and schema locations contained within that
>>> specification's content profile? This would satisfy the ISO requirements
>>> and permit us to signal additionally the processor features and behaviours.
>>> At this stage the expression of those is not our concern – just that there
>>> is a document somewhere that describes how the implementation should work.
>>>
>>>  Going back to the previous example, if a document conforms to Cx then
>>> it could be signalled either as S1 or S2 or both, and if the content
>>> provider has verified that presentation will be acceptable either way then
>>> both S1 and S2 would be declared, otherwise just one of them (or neither if
>>> there's some other Sn that also uses Cx).
>>>
>>>  With this scheme combinatorial logic wouldn't really make sense – you
>>> could infer something about unions and intersections of content profiles
>>> but since the language used to describe processor behaviours can't be
>>> mandated (okay it could in theory, but it wouldn't be accepted in practice)
>>> it wouldn't be a well defined operation. Incidentally this is in no way a
>>> critique of the effort put in by Glenn, and its outcomes, in terms of
>>> defining content and processor profiles – though it might be nice to verify
>>> that this simple expression can be expanded into that scheme should a
>>> specification writer choose to do so.
>>>
>>>  This implies that every combination of content profiles and behaviours
>>> must be considered carefully and registered as a new specification with a
>>> new label. It also implies that if a document declares conformance with a
>>> set of specifications then it must conform to every member of the set of
>>> content profiles and it may be processed according to any one of the set of
>>> processing behaviours.
>>>
>>>  The expression of that set is as described previously, where we pick
>>> our favourite delimiter out of a hat made out of ampersands.
>>>
>>>  Also: this topic was discussed in summary briefly on the call today
>>> and a new suggestion arose, that some guidance for 'reasons why the TTWG
>>> would reject an application for registration' would be helpful. When
>>> requiring combinations to be registered separately there's a greater need
>>> to ensure that the registration process is quick and painless, and this
>>> guidance would help us and those who may follow to expedite it.
>>>
>>>  Nigel
>>>
>>>
>>>   On 15/05/2014 18:00, "Michael Dolan" <mdolan@newtbt.com> wrote:
>>>
>>>    I believe the problem statement is to replace the potentially
>>> unwieldy long strings in the namespace & schema_location fields defined in
>>> 14496-12 and 14496-30 with a more compact string suitable for the DASH
>>> manifest codecs field.
>>>
>>>
>>>
>>> From 14496-12, AMD2:
>>>
>>>
>>>
>>> namespace is a null-terminated field consisting of a space-separated
>>> list, in UTF-8 characters, of
>>>
>>> one or more XML namespaces to which the sample documents conform. When
>>> used for metadata,
>>>
>>> this is needed for identifying its type, e.g. gBSD or AQoS [MPEG-21-7]
>>> and for decoding using XML
>>>
>>> aware encoding mechanisms such as BiM.
>>>
>>>
>>>
>>> schema_location is an optional null-terminated field consisting of a
>>> space-separated list, in UTF-
>>>
>>> 8 characters, of zero or more URL’s for XML schema(s) to which the
>>> sample document conforms. If
>>>
>>> there is one namespace and one schema, then this field shall be the URL
>>> of the one schema. If there
>>>
>>> is more than one namespace, then the syntax of this field shall adhere
>>> to that for xsi:schemaLocation
>>>
>>> attribute as defined by [XML]. When used for metadata, this is needed
>>> for decoding of the timed
>>>
>>> metadata by XML aware encoding mechanisms such as BiM.
>>>
>>>
>>>
>>> I’m warming up to the idea of requiring TTML content profiles be created
>>> for the combinations.
>>>
>>>
>>>
>>>                 Mike
>>>
>>>
>>>
>>> *From:* Glenn Adams [mailto:glenn@skynav.com <glenn@skynav.com>]
>>> *Sent:* Thursday, May 15, 2014 9:15 AM
>>> *To:* Nigel Megitt
>>> *Cc:* Michael Dolan; TTWG
>>> *Subject:* Re: Draft TTML Codecs Registry
>>>
>>>
>>>
>>> My understanding from Dave was that the problem is how to answer the
>>> following method:
>>>
>>>
>>>
>>> boolean canPlay(String contentTypeWithParameters)
>>>
>>>
>>>
>>> I have not seen any statement of a problem that relates to signaling
>>> content conformance.
>>>
>>>
>>>
>>> As for requirements driving the ability to express a combination of
>>> profiles, we already have (in TTML1) and will have more (in TTML2) that
>>> permits a user to characterize processing requirements by means of a
>>> combination of existing profiles. Consequently, any shorthand signaling of
>>> first-order processor support needs to be able to repeat the expression of
>>> such combinations.
>>>
>>>
>>>
>>> I don't buy any "its too complex" argument thus far, primarily because
>>> nobody has stated what is (overly) complex in sufficient detail to
>>> understand if there is a problem or not.
>>>
>>>
>>>
>>> My perception of the TTML profile mechanism is that it is easy to
>>> understand and implement, and, further, that it is a heck of lot easier to
>>> understand and implement than XML Schemas.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, May 15, 2014 at 9:58 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>> wrote:
>>>
>>> Agreed there's a gulf of understanding/expectation that we need to
>>> bridge.
>>>
>>>
>>>
>>> Can anyone volunteer to draft a set of requirements for this
>>> functionality, in the first instance being the smallest set needed to meet
>>> the ISO specs? (Mike, I guess I'm thinking of you, following our discussion
>>> at the weekly meeting earlier)
>>>
>>>
>>>
>>>
>>>
>>> On 15/05/2014 16:48, "Glenn Adams" <glenn@skynav.com> wrote:
>>>
>>>
>>>
>>>  i can see this subject is not going to be resolved easily as we
>>> clearly have a large gap about requirements; e.g., i think there are no
>>> requirements to signal content conformance, but only client processor
>>> requirements, i think we must use the TTML profile mechanism, etc
>>>
>>> On Thursday, May 15, 2014, Michael Dolan <mdolan@newtbt.com> wrote:
>>>
>>> Maybe "highly undesirable", but if we don't address the A + B signaling
>>> explicitly, then profiles need to be created for all the combinitorics of
>>> namespaces in practice. Not the end of the world, but virtually prevents
>>> the
>>> simple signaling of 3rd party namespaces already provided by the
>>> namespace/schemaLocation mechanism today. No I am not proposing we use
>>> that
>>> - I am pointing out a deficiency in this proposal that we already address
>>> today in 14496.
>>>
>>> Anyway, we need to go through the points in my email a week ago - if not
>>> today, then on the 29th.
>>>
>>>         Mike
>>>
>>> -----Original Message-----
>>> From: David Singer [mailto:singer@mac.com <singer@mac.com>]
>>> Sent: Thursday, May 15, 2014 5:20 AM
>>> To: Glenn Adams
>>> Cc: TTWG
>>> Subject: Re: Draft TTML Codecs Registry
>>>
>>> OK
>>>
>>> Though it will be a sub-parameter of the codecs parameter for the MP4
>>> file
>>> type, from the point of view of TTML it's actually a profile short name
>>> registry rather than codecs registry, so I think we should rename it.
>>>
>>> the values here should be usable in both
>>> a) the profiles parameter for the TTML mime type
>>> b) the codecs parameter for the MP4 mime type
>>>
>>> so, also "named codecs" -> "named profiles"
>>>
>>>
>>>
>>> I agree with Cyril that we only need a single operator here (implement
>>> one
>>> of these profiles and you're good to go), both because we don't need the
>>> complexity, and because a "implement both/all of these" is effectively
>>> inviting file authors to make up new profiles ("to process this document
>>> you
>>> have to implement both A and B"), which is (IMHO) highly undesirable.
>>>
>>>
>>>
>>> On May 15, 2014, at 9:55 , Glenn Adams <glenn@skynav.com> wrote:
>>>
>>> > See [1].
>>> >
>>> > [1] https://www.w3.org/wiki/TTML/CodecsRegistry
>>>
>>> Dave Singer
>>>
>>> singer@mac.com
>>>
>>>
>>>
>>>
>>> ----------------------------
>>>
>>>
>>>
>>> http://www.bbc.co.uk
>>> This e-mail (and any attachments) is confidential and may contain
>>> personal views which are not the views of the BBC unless specifically
>>> stated.
>>> If you have received it in error, please delete it from your system.
>>> Do not use, copy or disclose the information in any way nor act in
>>> reliance on it and notify the sender immediately.
>>> Please note that the BBC monitors e-mails sent or received.
>>> Further communication will signify your consent to this.
>>>
>>> ---------------------
>>>
>>>
>>>
>>>
>>
>