RE: Formal Object to any new CR of IMSC1

Why does a document that does not declare its profile have to have a default between two specific IMSC1 profiles?  Lacking the signaling, it might be something else entirely (i.e. nether IMSC1 profile).  How do you even know to select one of the two IMSC1 profiles?  It might be some other subset of TTML (especially for text which might only have the NS namespace).

 

And, if so somehow, why can’t the signaling be external?  It is required in any real application to tell the difference in some manner.  For example, in track selection in DECE (ISOBMFF) such signaling for text versus image is required external track metadata. Ditto for ATSC DASH – the manifest has required metadata.

 

                Mike

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Friday, December 11, 2015 10:21 AM
To: Andreas Tai <tai@irt.de>
Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>; TTWG <public-tt@w3.org>
Subject: Re: Formal Object to any new CR of IMSC1

 

 

 

On Fri, Dec 11, 2015 at 10:46 AM, Andreas Tai <tai@irt.de <mailto:tai@irt.de> > wrote:

Dear Glenn, Nigel, Pierre,

I read through the complete conversation on github and on this thread. May be (and hopefully) this turns out to be a very useful discussion to make the life of TTML implementers easier.

How I understand Glenn's concern there is a missing solution for the following scenario:

A processor that is an IMSC processor gets a document where neither from ttp:profile, ebuttm:conformsToStandard and also not from the interchange context the information can be derived if the document should be processed according to the IMSC 1 Text or IMSC 1 Image profile. If there is no deterministic algorithm that defines what the processor should assume in this case, the processor is unable to know what rules he needs to apply and also he does not know if he can process the document at all.

There is some discussion and reservation from Nigel and Pierre that there is such a thing as a generic IMSC processor (that combines the feature of the Text and Image profile), but lets take this assumption.

 

After giving this last point some further thought, I would suggest we use the term "multiple-profile processor" to describe such a processor. The reason being that the term "generic processor" is already defined in TTML1 to effectively mean the common core, i.e., intersection of, processing components of multiple profiles, which is a bit different than supporting multiple profile instances.

 

As for assuming the existence of such a processor, we don't have to assume, since the TTV, TTX, and TTPE tools in the Timed Text Toolkit [1] are all multiple-profile processors, where the set of available profiles when processing any given document is determined by a "model" parameter provided to the tool set. Examples of (already implemented) values of models and the set of available profiles used when applying the model include:

* ttml1 model

* dfxp presentation profile
* dfxp transformation profile
* dfxp full profile

* ttml2 model

* ttml2 presentation profile
* ttml2 transformation profile
* ttml2 full profile
* all ttml1 profiles

* nflxtt model

* nflx-cc profile
* nflx-sdh profile

* imsc1 model

* imsc1 text profile
* imsc1 image profile

Although these tools could employ a pre-processor to guess the profile given a specific model, this is undesirable for a number of reasons: (1) there is no standard definition of the heuristics that would be used, thus resulting in non-interoperability; (2) in a validation/verification context the use of heuristics to approximate essential processing parameters (such as profile) reduces the certainty of results.

 

[1] https://github.com/skynav/ttt

 

 


We had a long discussion at the last TPAC meeting in October 2015 about the need to specify the information about the "profile" of an TTML document. If no information is provided at all (neither through the interchange context nor explicitly in the document) this makes it is not only very hard for a processor, it makes it maybe impossible to apply a consistent and interoperable processing. We therefore agreed to strongly advise to provide this information by the known means because otherwise processing will be unpredictable. We could even make it stronger by saying that in the absence of such information this can not be a IMSC or other profile's document and if the the processor behaves just as a IMSC processor (could be by configuration as in the case stated by Glenn) then he should reject the document. The benefit of this behaviour would be that it "encourages" all users to specify the needed information.[1] 

The option that Glenn favoured (apply by default the Text profile if an IMSC processor gets a TTML document with missing profile information) is less strict. But although I think the behaviour proposed above is clearer and give better guidance I would not oppose such a solution in case there is no other agreed solution.

Best regards,

Andreas

[1]  Of course a TTML 1 processor that conforms to the DFXP Transformation profile would be able to process such a document but if he does not conform to this profile he also may reject the document.




Am 11.12.2015 um 17:11 schrieb Glenn Adams:

I should make another point, which is that by your suggestion (that the TTML1 fallback applies), then all EBU-TT-D documents that attempt to conform to the IMSC text profile will be interpreted as a non-IMSC document in the absence of document interchange determination. Is that desirable behavior? I think not. It tells me the design is broken.

 

On Fri, Dec 11, 2015 at 9:03 AM, Glenn Adams <glenn@skynav.com <mailto:glenn@skynav.com> > wrote:

 

 

On Fri, Dec 11, 2015 at 2:51 AM, Nigel Megitt <nigel.megitt@bbc.co.uk <mailto:nigel.megitt@bbc.co.uk> > wrote:

Glenn,

I do not think this is a helpful move.

To recap the GitHub issue discussion:

Since IMSC defines two profiles of TTML the normative fallback defined in TTML1 applies in the absence of any other defined behaviour.

 

That won't work, since in the EBU-TT-D case, it would be wrong to apply the DFXP Transformation Profile.

 


Furthermore the mechanisms for specifying either of the two profiles are coincident with the ttp:profile attribute as defined in TTML 1 and the presence  of ebuttm:conformsToStandard with the appropriate value for EBU-TT-D also indicates IMSC text profile conformance.

So this objection does not appear to be well formed, in that the assertion that no fallback behaviour is defined is false.

 

Clearly by "no fallback" I mean no fallback that yields an IMSC profile. So in that sense my point stands.

 


At the very least, IMSC is no worse than TTML1 in this respect, a topic which was much discussed at our recent face to face meeting.

 

Without a determination of IMSC profile that yields either text or image profile, it is not possible to process a document that purports to be an IMSC conforming document since processor conformance is defined in terms of knowledge of the applicable profile.

 


Finally, it is clear that we do not have consensus for an IMSC specific algorithm, which by the way would further fragment the processing of generic TTML documents since any such processor would have to be configured somehow to expect one of either TTML or IMSC to know which rules to use. It is clear that IMSC is intended to be a profile of TTML and not a separate format in its own right.

 

But that [any such processor would have to be configured somehow to expect one of either TTML or IMSC to know which rules to use] is manifestly true already, with or without an IMSC specific algorithm.

 


I hope these arguments will persuade you to consider other options.

 

>From my perspective, both you and Pierre are not attempting to address my comment substantively. I have proposed one possible fallback algorithm, I'm willing to entertain other algorithms as long as they produce one of two answers: IMSC text or IMSC image profile and do not require pre-parsing the entire document.

 

Until that occurs, my objection stands.

 


Kind regards

Nigel



> On 11 Dec 2015, at 00:37, Glenn Adams <glenn@skynav.com <mailto:glenn@skynav.com> > wrote:
>
> Unless and until a fallback profile is mandated normatively in IMSC1, SKYNAV formally objects to any new CR being published.


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

 

 

 

-- 
------------------------------------------------
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 <tel:%2B49%2089%2032399-389>  | Fax: +49 89 32399-200 <tel:%2B49%2089%2032399-200> 
http: www.irt.de <http://www.irt.de>  | Email: tai@irt.de <mailto:tai@irt.de> 
------------------------------------------------
 
registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------