Re: proposed updated response to MPEG on codecs

On Sat, Oct 18, 2014 at 4:56 AM, Andreas Tai <tai@irt.de> wrote:

>  Understood. One question: A specification that builds on TTML and but
> has not a normative list of TTML features and extensions is not a TTML
> profile, correct?
>

Correct, it would not be a "TTML profile" in the formal sense of how TTML
uses the term profile. However, in a general sense it might be considered
an "informal profile of TTML". In any case, it would certainly confuse
users and authors, and to some extent, would subvert the intended use of
TTML.


>
> Best regards,
>
> Andreas
>
> Am 17.10.2014 um 18:53 schrieb Glenn Adams:
>
> 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
>> ------------------------------------------------
>>
>>
>>
>>
>
>
> --
> ------------------------------------------------
> 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
> ------------------------------------------------
>
>