Re: proposed updated response to MPEG on codecs

I'm afraid I will have to object to the notion of creating a thing called a
TTML "dialect" that is not describable as a TTML "profile". We definitely
*do not* need an alternative characterization of TTML processor
requirements or content constraints.

On Fri, Oct 17, 2014 at 8:23 AM, Andreas Tai <tai@irt.de> wrote:

> Hi Cyril,
>
> Thanks for the quick feedback! See some comment inline.
>
> Am 17.10.2014 um 15:32 schrieb Cyril Concolato:
>
>> Hi Andreas,
>>
>> Le 17/10/2014 14:33, Andreas Tai a écrit :
>>
>>> As I understand the main intent of this communication is to define the
>>> responsibilities of the MPEG and TTWG  for the signalling of "TTML document
>>> dialects" in an MP4 container. There seems an agreement to use the MPEG
>>> codecs parameter where MPEG has the task to define a prefix and TTWG to
>>> define suffix.
>>>
>>> How the W3C/TTWG defines that suffix is not of core interest for the
>>> MPEG group (as long the general syntax for codecs parameter is followed). I
>>> highlight this because my following comment may not stop this letter
>>> because the "Suffix" definition is not decided yet and in the
>>> responsibility of the TTWG.
>>>
>>> Regarding the proposed solution in the liaison letter (and in this
>>> thread) more discussion seems to be needed. From my current review it may
>>> not be applicable for all "TTML dialects". Some "dialects", like EBU-TT-D,
>>> do not rely on the defined semantics of TTML profiles. Therefore I do not
>>> think that it is a good idea to make "TTML profiles" as a central concept
>>> for the codecs registry for "TTML dialects".
>>>
>> The idea would be that EBU-TT-D would be registered and have a short name
>> to be used as a dialect in the processorProfiles parameter.
>>
> In general this would meet an important requirement from decoder
> implementers.
>
>  EBU-TT-D may not "rely on the defined semantics of TTML profiles" but it
>> can be viewed as a "dialect" of TTML. Is that clearer?
>>
>
> I think that the general pattern is a adequate solution. The problem I see
> is with the definition what is meant by a processor profile. A processor
> profile has defined semantics. It reference the TTML profile mechanism.
> This mechanism is a formally well-thought-out concept. But it is not used
> consistently or not used by some TTML dialects. As well it has not been
> fully understood by some implementers. Therefore it would be good to have
> the (additional) possibility to just reference the specification of the
> "TTML dialect" without using the profile semantics.
>
>  Maybe the terms profiles or processorProfiles are misleading, I don't
>> know.
>>
> In the current registry proposal (and in the TTML2) draft "processor
> profile" has defined semantics. I think it was chosen on purpose (although
> I do not agree that this is the best solution).
>
> | Maybe we should talk about dialects to cover not just profiles of TTML
> but extensions too.
>
> I think the use of an alternative term would be a good idea because
> "profile" has a link to the semantic concept of TTML profiles and often
> this linkage is not intended.
>
> Best regards,
>
> Andreas
>
>
>
>> Cyril
>>
>>>
>>> Best regards,
>>>
>>> Andreas
>>>
>>> Am 17.10.2014 um 00:16 schrieb Michael Dolan:
>>>
>>>> Take 2 on the communication to MPEG - attached.  Over to Dave (really
>>>> this
>>>> time).
>>>>
>>>> -----Original Message-----
>>>> From: Michael Dolan [mailto:mdolan@newtbt.com]
>>>> Sent: Thursday, October 16, 2014 1:35 PM
>>>> To: 'Timed Text Working Group'
>>>> Subject: RE: proposed updated response to MPEG on codecs
>>>>
>>>> That would be the proper thing to do.
>>>>
>>>> -----Original Message-----
>>>> From: David Singer [mailto:singer@apple.com]
>>>> Sent: Thursday, October 16, 2014 1:07 PM
>>>> To: Glenn Adams
>>>> Cc: Michael Dolan; Timed Text Working Group
>>>> Subject: Re: proposed updated response to MPEG on codecs
>>>>
>>>> Seems that way
>>>>
>>>> On Oct 16, 2014, at 12:57 , Glenn Adams <glenn@skynav.com> wrote:
>>>>
>>>>  we could always define this new MIME media type parameter in TTML2,
>>>>> but
>>>>>
>>>> wouldn't we need to update the current registration?
>>>>
>>>>> On Thu, Oct 16, 2014 at 1:01 PM, David (Standards) Singer
>>>>>
>>>> <singer@apple.com> wrote:
>>>>
>>>>> On Oct 16, 2014, at 10:22 , Michael Dolan <mdolan@newtbt.com> wrote:
>>>>>
>>>>>  I cannot support defining a formal media type string (including any
>>>>>> of
>>>>>>
>>>>> its parameters) on an informal wiki.  This is highly irregular.
>>>>
>>>>> agreed.  I think that MPEG should say "the mime type the contents
>>>>> would
>>>>>
>>>> have if in a separate file goes here, with any optional parameters" and
>>>> stop
>>>> at that.
>>>>
>>>>> So, MPEG doesn't care how irregular we are, but we should not be
>>>>>
>>>> irregular, of course.
>>>>
>>>>>   I believe its general syntax and semantics must be normatively
>>>>>> defined
>>>>>>
>>>>> in TTML2 as part of the media type (and preferably in my view) then
>>>> registered with IANA (not the other way around either).
>>>>
>>>>> yup
>>>>>
>>>>>                   Mike
>>>>>>
>>>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>>>> Sent: Thursday, October 16, 2014 9:23 AM
>>>>>> To: Michael Dolan
>>>>>> Cc: Timed Text Working Group
>>>>>> Subject: Re: proposed updated response to MPEG on codecs
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 16 Oct 2014, at 16:52, Michael Dolan <mdolan@newtbt.com> wrote:
>>>>>>
>>>>>> Thanks for fixes.   I assume Dave will update before posting.
>>>>>>
>>>>>> As for the your second point, I am not sure that I follow. We must
>>>>>>
>>>>> define the new media type parameter formally in TTML2 or our decisions
>>>> and
>>>> this communication are meaningless.  Is your point that we did not
>>>> agree as
>>>> a group to register the update with IANA?  I agree, but I also did not
>>>> say
>>>> that to MPEG (although I personally think we should).
>>>>
>>>>>
>>>>>> I was expecting the MIME type parameter to be external to TTML2 and
>>>>>>
>>>>> defined on the registry page. I'm not against updating the IANA
>>>> registration
>>>> if that's useful but we haven't decided to do that. If we do, then
>>>> clearly
>>>> the relevant part of the TTML 2 spec would need updating to match. If we
>>>> don't, then there may be no changes resulting, in TTML2.
>>>>
>>>>> Since there may therefore be no change in TTML 2 I don't want to
>>>>>> give
>>>>>>
>>>>> the wrong impression.
>>>>
>>>>> Nigel
>>>>>>
>>>>>>
>>>>>>
>>>>>>                  Mike
>>>>>>
>>>>>> From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>>>>> Sent: Thursday, October 16, 2014 8:39 AM
>>>>>> To: Michael Dolan; 'Timed Text Working Group'
>>>>>> Subject: Re: proposed updated response to MPEG on codecs
>>>>>>
>>>>>> Thanks for the quick turnaround Mike. 3 things:
>>>>>>
>>>>>> typo: s/medaType/mediaType
>>>>>> correction: s/procProfile/processorProfiles
>>>>>>
>>>>>> Query: do we want the sentence "Its parameters will be extended in
>>>>>> TTML2
>>>>>>
>>>>> to include the proposed syntax above." ? Unless we're changing the IANA
>>>> registration then I do not think we have agreed to do this.
>>>>
>>>>> Kind regards,
>>>>>>
>>>>>> Nigel
>>>>>>
>>>>>>
>>>>>> From: Michael Dolan <mdolan@newtbt.com>
>>>>>> Date: Thursday, 16 October 2014 16:29
>>>>>> To: 'Timed Text Working Group' <public-tt@w3.org>
>>>>>> Subject: proposed updated response to MPEG on codecs
>>>>>> Resent-From: <public-tt@w3.org>
>>>>>> Resent-Date: Thursday, 16 October 2014 16:30
>>>>>>
>>>>>> Per my action item from today, please see the attached.
>>>>>>
>>>>>> Over to Dave and Nigel for review to see if I captured where we
>>>>>> ended up
>>>>>>
>>>>> in today's call; then over to Dave to upload to MPEG (or I can if
>>>> needed).
>>>>
>>>>> Time is very short and should be posted Sunday morning CEDT.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>                  Mike
>>>>>>
>>>>>> Michael A DOLAN
>>>>>> TBT, Inc.  PO Box 190
>>>>>> Del Mar, CA 92014
>>>>>> (m) +1-858-882-7497
>>>>>> mdolan@newtbt.com
>>>>>>
>>>>> David Singer
>>>>> Manager, Software Standards, Apple Inc.
>>>>>
>>>>>
>>>>>
>>>>>  David Singer
>>>> Manager, Software Standards, Apple Inc.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> --
> ------------------------------------------------
> Andreas Tai
> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>
> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
> http: www.irt.de | Email: tai@irt.de
> ------------------------------------------------
>
> registration court&  managing director:
> Munich Commercial, RegNo. B 5191
> Dr. Klaus Illgner-Fehns
> ------------------------------------------------
>
>
>
>