Re: Draft TTML Codecs Registry - Issue-305

I think that *within* the document, it’s worth marking all sorts of things:  stuff required for formal validation, complete parsing, and so on.  Outside the document, you merely need to know “if I fetch this, could I plausibly process it?”, and thus avoid fetches where the answer is “no”.

I think that some (most?) of John’s questions are in the former area.

But simple “claim and permission” is enough for the latter;  the name of a profile in the list 
* claims that the document is conformant to the content requirements of the profile
* permits that a processor conformant to the processing requirements may process the document as best it can under that profile (i.e. ignoring extensions that it doesn’t deal with)

Such a parameter would, I think, be a natural “profiles” list inside the document “profiles” MIME parameter outside the document, and “codecs” sub-parameter of stpp.ttml outside the document when the document is in an MP4-family file.

The list inside the document is important to be able to generate the other two, of course…

On May 19, 2014, at 18:11 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

> If we can definitively ditch the generic XML requirement that certainly
> gives us more freedom. What do we need in order to confirm that?
> 
> It looks like the change from 'description of document' to 'set of
> acceptable processors' is a bigger one though - are we okay to make that
> leap too?
> 
> 
> 
> On 19/05/2014 17:02, "David Singer" <singer@mac.com> wrote:
> 
>> In Part 12 we were hamstrung by XML.  We *wanted* something that would
>> tell the user of the file what they needed to know to determine whether
>> they could process, but all XML offers is the schema (great, now I know I
>> don¹t have the exact schema ‹ but do I have a satisgactory one?) and
>> namespaces (great, so there is stuff from other namespaces in here ‹ but
>> is it mandatory to recognize or discardable?)
>> 
>> We can do better with TTML, I hope.
>> 
>> On May 18, 2014, at 3: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:
>>> 
>>> 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).
>>> 
>>> 
>>> 
>>> 
>>> 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;
>>> 
>>> 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.
>>> 
>>> 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]
>>> 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]
>>> 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.
>>> 
>>> ---------------------
>>> 
>> 
>> 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.
> -----------------------------

Dave Singer

singer@mac.com

Received on Monday, 19 May 2014 16:21:15 UTC