Re: proposed updated response to MPEG on codecs

If you're extending ttml, why not do that through this WG here?

Just a thought...
Back to lurking.

Regards,
Silvia.
On 18 Oct 2014 21:59, "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?
>
> 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
> ------------------------------------------------
>
>