Re: Formal Object to any new CR of IMSC1

On Fri, Dec 11, 2015 at 2:08 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> > we need a fallback in case that recommendations is not followed
>
> FYI. Based on the TPAC minutes [1], it looks like the GPAC tool will
> reject the document if not profile can be determined.
>

So with the proposed new language, a profile is always determined, though
it could be wrong. However, it could be correct as well, in which case
documents that would otherwise be prematurely aborted would be processed
instead. And if the failsafe fallback were incorrect, it would likely fail
which is no different than failing due to lack of a failsafe fallback.


>
> [1] http://www.w3.org/2015/10/29-tt-minutes.html
>
> As Andreas mentioned earlier, this could be considered as an ultimate
> fallback, encouraging implementers to support more creative
> alternatives.
>
> On Fri, Dec 11, 2015 at 12:58 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > On Fri, Dec 11, 2015 at 1:52 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Hi Glenn et al.,
> >>
> >> > 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).
> >>
> >> Cyril's feedback [1] directly led to the recommendation [2-3] that
> >> ttp:profile or ebuttm:conformsToStandard be present to signal
> >> conformance to either Image Profile or Text Profile (see Section
> >> 6.10).
> >
> >
> > ok, except that this usage is defined to be optional (SHOULD), and we
> need a
> > fallback in case that recommendations is not followed
> >
> >>
> >>
> >> [1] https://lists.w3.org/Archives/Public/public-tt/2015Oct/0026.html
> >> [2] http://www.w3.org/2015/10/08-tt-minutes.html
> >> [3] https://github.com/w3c/imsc/issues/75
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> On Fri, Dec 11, 2015 at 12:42 PM, Glenn Adams <glenn@skynav.com> wrote:
> >> >
> >> >
> >> > 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 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
> >> >>
> >> >> ------------------------------------------------
> >> >>
> >> >>
> >> >
> >> >
> >
> >
>