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