Re: Formal Object to any new CR of IMSC1

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

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

Received on Friday, 11 December 2015 21:09:50 UTC