W3C home > Mailing lists > Public > public-tt@w3.org > May 2014

Re: Draft TTML Codecs Registry

From: David Singer <singer@mac.com>
Date: Thu, 15 May 2014 17:43:48 +0200
Cc: TTWG <public-tt@w3.org>
Message-id: <A479EF2F-B2C7-4A8D-A91A-0ACA4AFA1F41@mac.com>
To: Michael Dolan <mdolan@newtbt.com>

On May 15, 2014, at 15:57 , 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.

If you want the terminal to be required to support your extensions, then yes, you are defining a new profile.

I cannot think of any other specification that allows content authors to create new profiles on the fly.  For example, in AVC (H.264) there are various tools, and for some cases there are no profiles that contain both tool A and tool B.  If you were allowed to signal “you must support both profile Pa (requiring tool A) and profile Pb (requiring tool B)” then you have effectively created a new processing profile.  In all other places I know of, if you want to specify that a terminal support all of a set of features, you have to find or make a profile that requires all those features.  Therefore if the Venezuelan Beaver Cheese Operatives define extensions in a new namespace, and they want to require those extensions, I think that they need to define a processing profile, and its short name, and document carefully what the processing profile requires (and what the document profile requires and permits) for the case that they want to mandate some aspects of TTML and some of VBCA.  It is not safe/good to allow people to say “support Pa and Pb”, when those profiles might easily have something in conflict (e.g. Pa says that element X must be discarded, and Pb says it must be processed).

> 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

Dave Singer

Received on Thursday, 15 May 2014 15:44:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:43:35 UTC