Re: Draft TTML Codecs Registry

On May 15, 2014, at 18:15 , Glenn Adams <glenn@skynav.com> wrote:

> 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.

Right.  At the moment I am only interested in the canPlay, which in other cases we have reduced to “you need to support one of A,B,C” and the terminal knowing “I support C,F,G”, and working out whether the set in common is empty or not.

> 
> 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 disagree, as previously stated.  That it’s possible to design a way to express complex things does not make it desirable.  But this is a second-order question; if those that ‘own’ the TTML ‘world' want to design an algebra for the profiles parameter and codec sub-parameter, most of the characters in ‘ASCII’ are available to you….


> 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.

Now, there you have one of the easier tests known (‘easier than XML schemas’)…as an aside, how can a language whose NAME includes ‘extensible’ make it so damned hard to manage (a) revisions of the same specification, in a clean way (b) base specifications and enhancements, in a clean way?  For both of these namespaces and schemas are, well, a nightmare.

> 
> 
> 
> 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

Received on Thursday, 15 May 2014 17:04:38 UTC