- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Tue, 27 May 2014 09:23:03 -0700
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
Hi Nigel, > Not really, Ok. Before tackling with signaling, which is an orthogonal issue, I suggest we go back to your earlier concern regarding the means of overriding the default HRM parameter values specified in IMSC. What is the downside in allowing supplementary specifications to override the default HRM parameter values specified in IMSC? Best, -- Pierre On Tue, May 27, 2014 at 9:04 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: > Hi Pierre, > >>Perhaps you are asking how conformance to this supplementary >>specification would be signaled? > > Not really, but if I were asking that what would your answer be? There are > no feature designators for complexity at the moment. > > > Kind regards, > > Nigel > > > On 27/05/2014 16:48, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: > >>Hi Nigel, >> >>> and a document exceeding the minimum >>> parameter values as stated in IMSC would not be conformant. >> >>The document would be conformant to the supplementary specification >>overriding the default HRM parameter values specified in IMSC. >> >>Perhaps you are asking how conformance to this supplementary >>specification would be signaled? >> >>Thanks, >> >>-- Pierre >> >>On Tue, May 27, 2014 at 8:32 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>wrote: >>> Hi Pierre, >>> >>>>As currently drafted, IMSC allows anyone to unambiguously define and >>>>document new values for the HRM parameters. >>> >>> >>> Sorry, I'm not seeing this: IMSC provides no mechanism for allowing new >>> HRM parameter values to be adopted, and a document exceeding the minimum >>> parameter values as stated in IMSC would not be conformant. This means >>> that any content profile conformance would be discounted by a binary >>> 'conformant/not conformant' decision based on the complexity >>>measurement. >>> I'd prefer to parameterise it explicitly in the IMSC spec so that a >>> document can be IMSC syntax and content conformant and separately >>> conformant to a stated complexity level. >>> >>> This would allow other complexity levels to be introduced in the future >>> without having to write a whole new spec. >>> >>> Kind regards, >>> >>> Nigel >>> >>> >>> On 27/05/2014 16:22, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: >>> >>>>Hi Nigel, >>>> >>>>> If we do, let's make them as useful as we can, >>>>> by allowing for reasonable variations. >>>> >>>>I like the idea of reducing friction to adoption. >>>> >>>>As currently drafted, IMSC allows anyone to unambiguously define and >>>>document new values for the HRM parameters. Please elaborate on the >>>>obstacles one would face if one were to do so. Do you foresee >>>>implementation and/or specification issues? >>>> >>>>Thanks, >>>> >>>>-- Pierre >>>> >>>>On Tue, May 27, 2014 at 3:50 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>>>wrote: >>>>> Hi Pierre, >>>>> >>>>>>As it stands, anyone in the world can unilaterally create a >>>>>>specification defining new values. How can it be "more open" than >>>>>>that? >>>>> >>>>> If we don't need standards why bother with a standards body like W3C? >>>>>If >>>>> we do, let's make them as useful as we can, by allowing for reasonable >>>>> variations. >>>>> >>>>> Kind regards, >>>>> >>>>> Nigel >>>>> >>>>> >>>>> >>>>> >>>>> On 23/05/2014 17:50, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>>wrote: >>>>> >>>>>>Hi Nigel, >>>>>> >>>>>>> I see what you mean that you could create a new 'super-profile' >>>>>>>that >>>>>>>has >>>>>>> higher value complexity parameters, and existing IMSC documents >>>>>>>would >>>>>>>conform to it. >>>>>> >>>>>>Exactly! >>>>>> >>>>>>> It just seems a lot of effort to go to just to be able to draw >>>>>>>glyphs >>>>>>>on the screen more >>>>>>> quickly, when the rest of the document structure is identical. >>>>>> >>>>>>Where is the effort? The specification could be a single page defining >>>>>>new values for these parameters. >>>>>> >>>>>>> Yes it would - actually I'd like a more open mechanism >>>>>>> to specify alternate sets of values >>>>>> >>>>>>As it stands, anyone in the world can unilaterally create a >>>>>>specification defining new values. How can it be "more open" than >>>>>>that? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>-- Pierre >>>>>> >>>>>>On Fri, May 23, 2014 at 9:30 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> >>>>>>wrote: >>>>>>> Hi Pierre, >>>>>>> >>>>>>> On 23/05/2014 16:56, "Pierre-Anthony Lemieux" <pal@sandflow.com> >>>>>>>wrote: >>>>>>> >>>>>>>>Hi Nigel, >>>>>>>> >>>>>>>>> so that it can be used to construct maximally complex test >>>>>>>>>documents >>>>>>>>>that compliant >>>>>>>>> processors must be able to process successfully, while permitting >>>>>>>>>processors >>>>>>>>> to process even more complex documents. >>>>>>>> >>>>>>>>I am not aware of provisions in the specification that prevent >>>>>>>>processors from implementing capabilities beyond that required to >>>>>>>>process documents that conform to (proposed) IMSC 1.0. >>>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>>> >>>>>>>>> > This would open up the possibility for future increases in >>>>>>>>>complexity >>>>>>>>> by allowing the threshold values for sub-profiles of IMSC to be >>>>>>>>>changed >>>>>>>>> to 'greater complexity', in the knowledge that pre-existing IMSC >>>>>>>>>compliant >>>>>>>>> documents will be continue to be processable. >>>>>>>> >>>>>>>>Yes. That option exists in my mind. >>>>>>> >>>>>>> I suppose this is a matter of perspective - I see what you mean that >>>>>>>you >>>>>>> could create a new 'super-profile' that has higher value complexity >>>>>>> parameters, and existing IMSC documents would conform to it. It just >>>>>>>seems >>>>>>> a lot of effort to go to just to be able to draw glyphs on the >>>>>>>screen >>>>>>>more >>>>>>> quickly, when the rest of the document structure is identical. >>>>>>> >>>>>>>>>Very closely related to this, the HRM (§7) [1] in various places >>>>>>>>>sets >>>>>>>>>threshold >>>>>>>>> parameter values using the wording "Unless specified otherwise, >>>>>>>>>the >>>>>>>>>following table >>>>>>>>> shall specify..." but there is no mechanism for specifying >>>>>>>>>otherwise >>>>>>>> >>>>>>>>As it stands, the mechanism to specify otherwise would be in a >>>>>>>>different specification. In other words, anyone in the world could >>>>>>>>write a specification referencing IMSC 1.0 and including a provision >>>>>>>>such as "the Normalized image copy performance factor (ICpy) shall >>>>>>>>be >>>>>>>>12". >>>>>>>> >>>>>>>>Would clarifying this in the specification make sense? >>>>>>> >>>>>>> Yes it would - actually I'd like a more open mechanism to specify >>>>>>> alternate sets of values but this would help too. >>>>>>> >>>>>>>> >>>>>>>>> It should be permitted for processors not to be subject to the HRM >>>>>>>>>values at all, >>>>>>>> >>>>>>>>Processors are not subject to HRM constraints, IMSC 1.0 documents >>>>>>>>are. >>>>>>>>As suggested above, processors can choose to implement abilities >>>>>>>>that >>>>>>>>go beyond that required to process IMSC 1.0 documents, e.g. to >>>>>>>>process >>>>>>>>other profiles, including profiles that extend IMSC 1.0. >>>>>>> >>>>>>> Understood - I meant this in the context of a minimal processor >>>>>>>profile >>>>>>> not as written in the current working draft. >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Nigel >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>On Fri, May 23, 2014 at 5:54 AM, Timed Text Working Group Issue >>>>>>>>Tracker <sysbot+tracker@w3.org> wrote: >>>>>>>>> ISSUE-319 (HRM should be a processor compliance test): HRM should >>>>>>>>>be a >>>>>>>>>processor compliance test and allow different levels of complexity >>>>>>>>>for >>>>>>>>>different use cases [TTML IMSC 1.0] >>>>>>>>> >>>>>>>>> http://www.w3.org/AudioVideo/TT/tracker/issues/319 >>>>>>>>> >>>>>>>>> Raised by: Nigel Megitt >>>>>>>>> On product: TTML IMSC 1.0 >>>>>>>>> >>>>>>>>> The Hypothetical Render Model is defined as a content profile >>>>>>>>>constraint, which appears to set a maximum complexity on all >>>>>>>>>documents. >>>>>>>>>It would be better to make it a minimal processor profile >>>>>>>>>constraint, >>>>>>>>>i.e. so that it can be used to construct maximally complex test >>>>>>>>>documents that compliant processors must be able to process >>>>>>>>>successfully, while permitting processors to process even more >>>>>>>>>complex >>>>>>>>>documents. >>>>>>>>> >>>>>>>>> This would open up the possibility for future increases in >>>>>>>>>complexity >>>>>>>>>by allowing the threshold values for sub-profiles of IMSC to be >>>>>>>>>changed >>>>>>>>>to 'greater complexity', in the knowledge that pre-existing IMSC >>>>>>>>>compliant documents will be continue to be processable. >>>>>>>>> >>>>>>>>> Very closely related to this, the HRM (§7) [1] in various places >>>>>>>>>sets >>>>>>>>>threshold parameter values using the wording "Unless specified >>>>>>>>>otherwise, the following table shall specify..." but there is no >>>>>>>>>mechanism for specifying otherwise; §4.7 simply states that all >>>>>>>>>sequences "of intermediate synchronic documents SHALL be >>>>>>>>>reproducible..." without providing any reference to an external >>>>>>>>>location >>>>>>>>>where the parameters in the HRM can be set to other values. >>>>>>>>> >>>>>>>>> One possible solution to this is to introduce a 'complexity level' >>>>>>>>>table and list the current parameter values as, for example >>>>>>>>>'complexity >>>>>>>>>level 1' and change the wording in §4.7 to state that for use cases >>>>>>>>>that >>>>>>>>>need to specify complexity they must either specify an equivalent >>>>>>>>>table >>>>>>>>>with alternative parameter values or use the default 'level 1' >>>>>>>>>values. >>>>>>>>>It should be permitted for processors not to be subject to the HRM >>>>>>>>>values at all, and there should be scope in future versions of IMSC >>>>>>>>>to >>>>>>>>>add more levels, if there is a strong argument for doing so. >>>>>>>>> >>>>>>>>> [1] http://www.w3.org/TR/ttml-imsc1/#hypothetical-render-model >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----------------------------- >>>>>>> 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. >>>>>>> ----------------------------- >>>>> >>> >
Received on Tuesday, 27 May 2014 16:23:52 UTC