RE: Draft TTML Codecs Registry - Issue-305

Hi David,

Yes, I agree.

The latter area ""if I fetch this, could I plausibly process it?" is irrelevant IMHO to the use cases I am interested in.
In 'my' use cases there is an expectation that the (fetched) content is already validated, conforms to a known given standard (or known set of standards) and that the processor in question is capable of decoding all such documents that are fetched (regardless of which features individual documents exhibit).

In other words, the content that is available to be fetched has already been pre-qualified for the chain to the 'glass'.
As a slight aside, migration of (subtitle) documents to a new distribution chain would be expected to require a re-qualification, and possibly transcoding/conversion of the documents to suit the new chain. There is no real requirement for a 'run anywhere on many processors' (subtitle) document. This might seem like an ideal, but in practise, legal rights and distribution / revenue models generally preclude this concept. A subtitle document (at least at the professional level) is typically licensed for use by a specific operator - in exactly the same ways that AV content is licensed.

This IS the AV model. This is the expected operational practise of AV content publishers. A strong a priori specification based model.

There is no requirement for a processor to be able to deduce the feature requirements of a document *in this model*. (I have growing concerns about mentions of 'lists' of features inside every document... since for me those lists are superfluous save for a 'call out' to a single external 'specification').
There is no requirement for a content publisher to determine the processing capabilities of a processor *in this model* (well perhaps only *once* when they qualify that decoder and give it a 'seal of approval'). Certainly not dynamically.
There is no requirement for a processor to publish its processing capabilities *in this model*.
There almost is no real *useful* requirement for a processor that can tell you it cannot process a document *in this model*, since that represents a failure to present, which is always to be avoided. The emphasis is on first time right presentation.

BUT there is a real requirement to be able to define the structure and expected outcomes of a set of documents when processed by a processor that supports the necessary features.

So for me, the emphasis of Glenn's sterling efforts, whilst completely in keeping with web strategies for semantic web (which I generally wholeheartedly approve of), seem to be at a tangent to the real requirements that I see in my sphere of interest.

My concern is that there is a growing divergence between what are IMHO 'real' requirements, and the current and previous discussions. I am also concerned that 'my' priorities (which are focussed around strong specification and validation) seem to have a low priority compared to more esoteric 'requirements' - for which I do not easily see a use case. My priorities are driven by *deployed* TTML based solutions.

I am pretty certain that the proposals could solve my concerns, but in order to be adopted in my sphere of interest they do need to be clearly seen to resolve those concerns in a simple and lightweight manner.

Best regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv | www.screensystems.tv | https://twitter.com/screensystems

Visit us at
Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand 5E4-01

P Before printing, think about the environment-----Original Message-----
From: David Singer [mailto:singer@mac.com]
Sent: 19 May 2014 17:20
To: Nigel Megitt
Cc: Glenn Adams; Michael Dolan; TTWG
Subject: 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



This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ

Received on Tuesday, 20 May 2014 08:50:20 UTC