- From: Michael Dolan <mdolan@newtbt.com>
- Date: Fri, 11 Dec 2015 18:15:01 -0800
- To: "'Glenn Adams'" <glenn@skynav.com>
- Cc: "'Andreas Tai'" <tai@irt.de>, "'Nigel Megitt'" <nigel.megitt@bbc.co.uk>, "'TTWG'" <public-tt@w3.org>
- Message-ID: <01f701d13482$ebdf0730$c39d1590$@newtbt.com>
They really are unrelated profiles. They have very little in common. The fact that they are defined in a single Rec is misleading, perhaps.
The IMSC1-Image profile will display nothing at all if processed as TTML1 or IMSC1-Text.
Arguably IMSC1-Text is part of the TTML1 model.
They need to be different models, I think.
Regards,
Mike
From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Friday, December 11, 2015 5:51 PM
To: Michael Dolan <mdolan@newtbt.com>
Cc: Andreas Tai <tai@irt.de>; 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 5:32 PM, Michael Dolan <mdolan@newtbt.com <mailto:mdolan@newtbt.com> > wrote:
I hope we can work through the EBU provision and just solve this the straightforward way.
However, in regard to: “If you know the document presented to you is an IMSC document, then…”, again, in what external context are you given only this information? I maintain that the condition being set up is contrived and no one would do it (at least not on purpose).
Not at all. I described this is exactly what is done in the case of the Timed Text Toolkit (TT) tool set, which uses a model parameter to establish the set of applicable profiles to draw from when verifying/presenting a document. I described this in some detail in an earlier message in this thread.
I am (now) using the term "multiple-profile processor" to describe such usage. In the case of TTT, it is told that a document should be verified with the "imsc1" model, which admits two profiles (text or image), but absent a determination (or defaulting) of profile, processing cannot be performed.
If you refer to the case where there is only the presence of an IMSC1 namespace in the document, OK, but then the external context is entirely missing, which I maintain is a broken system/environment. The multi-profile IMSC1 processor must be told which it is.
Mike
From: Glenn Adams [mailto:glenn@skynav.com <mailto:glenn@skynav.com> ]
Sent: Friday, December 11, 2015 2:48 PM
To: Michael Dolan <mdolan@newtbt.com <mailto:mdolan@newtbt.com> >
Cc: Andreas Tai <tai@irt.de <mailto:tai@irt.de> >; Nigel Megitt <nigel.megitt@bbc.co.uk <mailto:nigel.megitt@bbc.co.uk> >; TTWG <public-tt@w3.org <mailto:public-tt@w3.org> >
Subject: Re: Formal Object to any new CR of IMSC1
On Fri, Dec 11, 2015 at 3:16 PM, Michael Dolan <mdolan@newtbt.com <mailto:mdolan@newtbt.com> > wrote:
I’m having trouble understanding an external context conveying only “IMSC1” generically without declaring it to be a specific profile. It would be like an external context (e.g. media type) declaring a document is only TTML and then demanding that there be some other way to determine it actually conforms to SDP-US.
Imagine you are implementing or have an implementation of a multiple-profile IMSC processor, i.e., a processor that can process either text or image profile documents. Or imagine you have a more general TTML processor that can process multiple sets of multiple profiles, each set of which is associated with a parameter supplied to that general processor. [All the TTT processors fall into this latter category.]
If you know the document presented to you is an IMSC document, then you know it must be one of the two IMSC profiles, but you don't know which if no ttp:profile is specified, thus a fallback is provided (if no other environmental metadata is supplied).
A “metadata generator” would of course need either sufficient external context or the profile designator.
So, I am still not understanding the problem that is unique to the IMSC1 profiles.
It is unique to IMSC1 because IMSC1 doesn't define a fallback profile and doesn't require ttp:profile. TTML1 and TTML2 also don't require ttp:profile (attribute or element) but define a normative fallback profile. SMPTE-TT would fall under the TTML1 logic. NFLXTT mandates a ttp:profile attribute. EBU-TT doesn't permit ttp:profile, but instead defines ebuttm:conformsToStandard, which appears to be required in an EBU-TT 1.1 and EBU-TT-D document (at least the spec says "shall be used", which I assume to mean is required), but is not defined in EBU-TT 1.0.
All that said, even if I am missing something I’m personally fine with requiring ttp:profile (has been required in DECE CFF).
We have been told that EBU-TT prohibits the use/presence of the ttp:profile attribute, in which case it would a problem to author dual use EBU-TT|IMSC documents. However, having just reviewed tech3350 (1.1) and tech3380, I don't find any normative language that actually states such a prohibition (Andreas? Nigel?).
Regards,
Mike
From: Glenn Adams [mailto:glenn@skynav.com <mailto:glenn@skynav.com> ]
Sent: Friday, December 11, 2015 12:43 PM
To: Michael Dolan <mdolan@newtbt.com <mailto:mdolan@newtbt.com> >
Cc: Andreas Tai <tai@irt.de <mailto:tai@irt.de> >; Nigel Megitt <nigel.megitt@bbc.co.uk <mailto:nigel.megitt@bbc.co.uk> >; TTWG <public-tt@w3.org <mailto:public-tt@w3.org> >
Subject: Re: Formal Object to any new CR of IMSC1
On Fri, Dec 11, 2015 at 11:54 AM, Michael Dolan <mdolan@newtbt.com <mailto:mdolan@newtbt.com> > wrote:
Why does a document that does not declare its profile have to have a default between two specific IMSC1 profiles?
The "Document Interchange Context" may be told or otherwise know (from context of use) it is an IMSC document, but not which IMSC profile applies.
Lacking the signaling, it might be something else entirely (i.e. nether IMSC1 profile).
In which case the "Document Interchange Context" has not been told or determined it is an IMSC document, in which case a general-purpose, multiple profile TTML processor may (absent other information) treat it as a TTML1 document in which case the DFXP Transformation Profile would apply.
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).
See above.
And, if so somehow, why can’t the signaling be external?
It could be, in which case the language I propose already covers this circumstance without resorting to the failsafe fallback.
If no <http://www.w3.org/TR/ttml1/#parameter-attribute-profile> ttp:profile attribute is present in a Document Instance, and if the Document Interchange Context does not make an implicit or explicit reference to and does not otherwise make a determination of a pre-defined profile defined herein, then the IMSC Text profile applies.
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.
Note that Cyril has already raised the issue about how a metadata generator should determine which IMSC profile should apply, however, no definitive answer was provided (as far as I recall).
Mike
From: Glenn Adams [mailto: <mailto:glenn@skynav.com> glenn@skynav.com]
Sent: Friday, December 11, 2015 10:21 AM
To: Andreas Tai < <mailto:tai@irt.de> tai@irt.de>
Cc: Nigel Megitt < <mailto:nigel.megitt@bbc.co.uk> nigel.megitt@bbc.co.uk>; TTWG < <mailto:public-tt@w3.org> 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
------------------------------------------------
Received on Saturday, 12 December 2015 02:15:55 UTC