- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 7 Jan 2016 16:20:34 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D2B44074.2F95F%nigel.megitt@bbc.co.uk>
Thanks all for a productive start to 2016. Minutes from today's meeting can be found in HTML format at http://www.w3.org/2016/01/07-tt-minutes.html
I didn't get around to it but once again congratulations to all who have been involved in developing TTML over the years for the Emmy award.
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
07 Jan 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/01/07-tt-irc
Attendees
Present
nigel, glenn, andreas, mike, pierre
Regrets
tmichel
Chair
nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This Meeting
2. [5]Action Items
3. [6]IMSC CR3 etc
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This Meeting
nigel: Next week David Ronca from Netflix has agreed to present
what he couldn't at Sapporo,
... so I'd like to propose a 2 hour meeting so we can do that
and normal business.
... i.e. on 14th Jan
... For today I propose we look at Actions, IMSC CR3 and issue
#111 and TTML2 Editorial Actions.
... Also as AOB, more on the Emmy award.
... Any other AOB?
group: no AOB
Action Items
action-451?
<trackbot> action-451 -- Thierry Michel to Investigate if we
are required to move to the 2015 process -- due 2015-12-03 --
PENDINGREVIEW
<trackbot>
[9]http://www.w3.org/AudioVideo/TT/tracker/actions/451
[9] http://www.w3.org/AudioVideo/TT/tracker/actions/451
nigel: The objection deadline passed on the call for consensus
so we have moved to 2015 process.
close action-451
<trackbot> Closed action-451.
atai2: I pushed some corrections of the drafts relating to
fonts and mapping and the feature problems reported by Pierre
and Simon.
nigel: Please could you review your actions on tracker and if
there's any update or a move to a github issue add the info and
mark the action as pending review or closed?
atai2: Okay, I'll update them.
nigel: Thanks!
IMSC CR3 etc
nigel: I'd like us to look at issue #111 if we can - we have a
good set of people here to talk about this.
[10]https://github.com/w3c/imsc/issues/111
[10] https://github.com/w3c/imsc/issues/111
glenn: Pierre and I had a talk about this and that resulted in
a modification to my proposal that would allow me to remove the
objection.
pal: One way is to give control to Glenn on Webex to
review/edit the solution live?
nigel: Just checking everyone can see a shared screen?
group: No objections.
glenn: [shares screen showing proposal text]
... The main objection was that a processor that can work with
both profiles simultaneously needs to
... make a decision on what profile to apply.
... Implementors might choose either text or image profile and
implement only one of them, in which case there's no decision
point.
... However if you're implementing a processor that operates in
a mode that only supports those two profiles then you need to
make a
... decision with one of two answers, either text or image
profile. Other possibilities I consider out of scope, for
example a processor that
... can handle an arbitrary set of TTML profiles. This document
is not interested in or defining or discussing that usage in
the larger context.
<Zakim> mdolan, you wanted to ask about the premise
mike: An observation: in the known specification and
implementations of the predecessor and IMSC 1 the decoders all
support both
... profiles but don't rely on any sort of intermediate Y in
the train tracks. The external signalling defines one or the
other.
... The scenario is an implementation possibility but the issue
hasn't come up because the switch in the train tracks was
signalled at a higher level.
glenn: I account for that internally. I'm dealing with the
situation where there is no external information, and the
processor is not
... implementing a sniffer and there is no external metadata
and I'm trying to resolve the ambiguity that in the absence of
any external
... profile metadata or preprocessor that guesses it then there
is such a fork in the processing path. I only want to deal with
the fallback
... default scenario here.
mike: In this case, unlike perhaps the other TTML1 profiles,
it's not the case that IMSC 1 Text and IMSC 1 Image are subsets
of each other
... so treating them like the TTML 1 profiles where that
processing can be done this is different.
glenn: I'm not arguing that. I'm interested in 2 kinds of
processing. For validation if you don't know what kind of
profile you're validating
... with then it's not useful to proceed. I'm addressing a
presentation processor case where you build a presentation
engine that can
... support both of the two profiles and in doing so makes a
decision on which profile applies to perform constraint
processing during the
... presentation process. That can be provided externally by
the document interchange process, using sniffing or envelope or
context, or
... in the absence of that there needs to be a decision made.
This harks back to the fact that TTML1 and TTML2 both define
such a fallback
... default normatively. In TTML1 it is the DFXP transformation
profile. TTML2 has a more complex algorithm using the version
parameter
... and other information and chooses between a default in the
TTML 1 profile space or a default in the TTML2 profile space.
... Both cases define a fallback default.
... In that case, I have an implementation that makes such a
decision, and it's my perception that the specification is
ambiguous and it
... should be possible to define a fallback default like TTML1.
mike: In TTML1 the fallback is trivial - it's full.
glenn: That's not the default - it's transformation.
mike: It's easy because there are no extensions and all
profiles are strict subsets.
... Normally people think about profiles as subsets - in this
case it's a subset plus extensions so the fallback breaks down
in this case.
glenn: TTML1 does support extensions so I don't see how IMSC
does something different in this regard. The defaulting
algorithm
... doesn't take into account profiles outside its own space -
you're right there. The only point in having a fallback default
is to resolve
... the specification ambiguity in a formal way. If you leave
it undefined I perceive that as being a hole in the
specification, that it says A OR B
... and doesn't provide guidance as to making the decision.
pal: Do you agree that if the image and text profiles were in
two specifications then that statement would not apply?
glenn: It wouldn't apply to either of those documents, correct.
But they are both in the same specification so it is not
relevant.
pal: I think it is relevant because it's an artefact of the
profiles being in the same specification.
<Zakim> nigel, you wanted to ask why a processor needs to make
this decision
nigel: Why would you want to do "constraint processing" here
given that a processor that can process documents in either
profile
... must logically support the union of features needed to
process all features, so why would you need to make the
decision?
glenn: There are a number of options for what to do and which
rules to use, depending on which profile is in place. If as
part of your
... presentation process you are paying attention to the
constraints but not validating for the purpose of aborting if
not valid, or notifying
... the user of problems then you have to pay attention to
which constraints apply. In some cases the constraints are
common to both
... profiles, such as the use of different metrics, and there
are per profile constraints defined in §7 and §8.
... You need to know which rules apply.
nigel: I'm confused still - what behavioural differences would
arise if a non-conformant document were processed?
glenn: The differences would depend on which profile applied.
In the absence of any external information then it has to have
a default.
... I made the text profile the default fallback because it
seemed least likely to be a false positive. The only case is an
image profile document
... that contains no indication that it is an image profile
document.
mike: I'm still not sure I agree with the premise but I'd like
to see what you're proposing.
glenn: Let me take you through it.
... [add terminology for single profile processor and multiple
profile processor]
pal: I just want to make something clear - the multi-profile
IMSC processor is one that ONLY supports both IMSC processors
and no others?
glenn: Right.
pal: And nothing else?
glenn: That's correct. Further down I specified a note that the
determination of processing of an arbitrary document instance
not compatible
... with either profile definition here is out of scope. It
wasn't my intent to handle a truly generic processor. That's an
uber problem that
... could be specified elsewhere if we wanted to.
nigel: What do we do with an SDP-US or SMPTE-TT document that
in all other respects than the profile indication is IMSC
conformant?
glenn: I'll get there.
... The #profile feature in §6 as agreed in Sapporo needs to be
referenced in the defaulting algorithm so I elevated that text
into this
... proposal without any change in it. Where it says [profile
specification] that's the same text as agreed in Sapporo.
... Then the meat of the proposal under the [profile
defaulting] section describes what a single profile processor
and multiple profile processor
... should do.
... [single] - if profile designator doesn't match processor
profile then document processing may be aborted
... [multiple] - too complex rules to summarise in minutes
mike: A comment: I think the context in a single profile
processor will be clear - the real issue is for the multiple
profile processor.
... The choice of default to the text profile is not based on a
good decision tree because the probabilities of text or image
seem equal.
glenn: You're correct. You could say it's a random choice, but
I tried to choose one that I thought would be more likely
compatible, because
... it's more likely compatible with EBU-TT-D. I was trying to
reduce the number of false positives and negatives and I
thought the text profile
... would do a better job in some scenarios. The case where it
would be wrong is if a document is image profile and the
algorithm chooses
... to process as a text profile.
mike: What does "tentatively" mean? Does it imply a SHOULD?
glenn: I use the term SHOULD to intentionally weaken the
language and to make it possible for the implementation to make
more choices.
... An implementation could choose the image profile - that
wouldn't follow the recommendation but would be permitted.
... By tentatively I mean that if the wrong decision is made
then abort would be an option, or retry with the other
decision.
... When it is processing it is working on a guess.
atai2: It is strongly recommended to signal the profile or give
information in the context. You have the probability of making
the right
... choice by using text profile but you have no fact to base
the decision on.
glenn: Keep in mind that when it says "compatible with" I tried
to avoid language that would strictly pin the language to a
processor profile
... as defined in TTML1 because IMSC mixes the specifications
of content and processor profiles. You're right. The way to
have this default
... apply is to ensure there is some indication of profile, but
the intent of this language is to encourage it.
nigel: I can't see behavioural differences for processors based
on the profile - what practical difference does this make?
glenn: If you're using vertical writing mode that violates the
constraints of the image profile - so what should the processor
do? It can only
... decide whether to abort or ignore if it knows the profile.
I agree there are few explicit normative statements that define
behaviour. The
... only one I can think of off hand is the UAX14 line breaking
algorithm. The definition of behaviour on non-compliance is
undefined, which
... makes it hard to interoperably test content in my
estimation. The processor needs an indication of what to do.
mike: I agree with Andreas, a recommendation or strong
encouragement to use profile is helpful, and further,
... on discovering that it's not a text profile then you should
try the image profile rather than aborting. I would then
probably be happy with
... this.
glenn: A strong recommendation to mark or signal externally the
profile would be fine. I could add that.
... On discovering a profile incompatibility switching profile
- is that what you meant?
mike: Yes, I think you want to encourage all possible efforts
to try the correct presentation even if you discover an element
or attribute that
... doesn't fit the profile would be better.
glenn: If I were to change the note about potentially aborting
would that help?
mike: Yes, where "try the other profile" is the preferred
option.
nigel: We're out of time - I don't think we've handled the
SDP-US or SMPTE-TT issues.
glenn: I'll work on this in the meantime and we could maybe
deal with that next time?
pal: I'll review the revised proposal. Something I think will
need to change is the name of the multi profile processor. It
needs to be
... explicit that it supports only those two profiles, e.g. an
'exclusive multi-profile processor' or something similar.
nigel: Summarising, we need to review a revised version of this
and discuss again next week.
glenn: I will post the proposal as a message to the public
reflector.
nigel: Thanks all, I'll close the call now [adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [11]scribe.perl version
1.144 ([12]CVS log)
$Date: 2016/01/07 16:13:21 $
[11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[12] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
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.
---------------------
Received on Thursday, 7 January 2016 16:21:08 UTC