RE: Draft TTML Codecs Registry

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.

---------------------