Re: Formal Object to any new CR of IMSC1

On Fri, Dec 11, 2015 at 5:32 PM, Michael Dolan <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]
> *Sent:* Friday, December 11, 2015 2:48 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 3:16 PM, Michael Dolan <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]
> *Sent:* Friday, December 11, 2015 12:43 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 11:54 AM, Michael Dolan <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 ttp:profile
> <http://www.w3.org/TR/ttml1/#parameter-attribute-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: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> 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> wrote:
>
>
>
>
>
> On Fri, Dec 11, 2015 at 2:51 AM, Nigel Megitt <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> 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 | 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
>
> ------------------------------------------------
>
>
>
>
>
>
>