- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 27 May 2021 16:13:49 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <72F9FFC1-0C1A-4D0B-BB72-32072500DEAC@bbc.co.uk>
Thanks for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2021/05/27-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
27 May 2021
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2021/05/13-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/186
[4] https://www.w3.org/2021/05/27-tt-irc
Attendees
Present
Atsushi, Nigel, Pierre
Regrets
Andreas, Cyril, Gary
Chair
Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]Fix #1232 by clarifying the [resolve timing] procedure
w3c/ttml2#1233
3. [7]Meeting close
Meeting minutes
This meeting
Nigel: We're low on numbers today, so not sure we can cover all
the agenda items.
… In particular, I think we need Cyril and/or Glenn for the
Shear calculations issue.
… We may be able to discuss the ISD pull request.
… The fingerprinting PR looks ready to merge.
Atsushi: I raised the TPAC joint meeting topic thanks to my
calendar reminder - it's 4 months out.
… We may need to raise the actual meeting 1 month before, and
start thinking about it 2-3 months before.
… It's just a heads-up for gathering requirements and ideas.
Nigel: The one thing I'd really flag up is to work with the CSS
community to try to make progress on line-based formatting.
… I suggest I make a comment on the fingerprinting vectors PR,
to say "ready to merge"
… and we postpone discussion about shear
… but that Pierre and I could use this time usefully to discuss
the ISD PR.
… I think that will be all for today, but anything else?
Pierre: no, let's do it!
Fix #1232 by clarifying the [resolve timing] procedure w3c/ttml2#1233
github: [8]https://github.com/w3c/ttml2/pull/1233
[8] https://github.com/w3c/ttml2/pull/1233
Nigel: [summarises current state]
Pierre: What is the problem with the spec as it stands?
Nigel: I think it's a problem of ease of understanding, mainly.
… It seems to me from observation that different readers have
different understandings of the ISDs that get generated.
Pierre: Maybe that's the crux of the issue. There's a huge
difference between what an implementation will generate and how
the spec
… defines an ISD. Today the spec does not require an
implementation to generate anything.
… It just defines an ISD.
Nigel: It gives a procedure for generating them.
Pierre: I don't think it compels an implementation to generate
that sequence.
… The reason is that in some cases the implementation doesn't
want an ISD, it just wants to know the rendering at time X.
… It's output is not a sequence of ISDs, just one rendering.
… I agree with you that in the marketplace I've seen confusion
about the rendering process of TTML in general.
… But I think that's different than what the current text says,
which I think is fine.
… It could be improved with an explanation or notes.
Nigel: I agree - I've written an implementation that doesn't
touch ISDs at all, which is fine.
Pierre: Conceptually, in my mind, not at an implementation or
conformance level, a TTML document can be represented by a
sequence of ISDs.
… Here's a procedure to generate that conceptual sequence of
ISDs.
… You might ask why you care about those ISDs. If you're trying
to render something it's a really useful concept.
Nigel: This came out of MPEG work in progress where they want
to write a spec that explicitly references the set of ISDs that
gets generated.
… So it seems important that everyone agrees on what the ISDs
are.
Pierre: A really confusing consequence of the current language
is that if a body has a begin time then there's no ISD before
then.
… Or is there an empty one?
Nigel: It's dancing on the head of a pin to try to identify the
difference between an empty ISD or no ISD.
Pierre: There's a huge difference between saying that a
document defines behaviour from a to b, and saying that it is
always
… defined from 0 to infinity but may contain empty ISDs.
… If you generalise it to go from 0 to infinity then that makes
the MPEG spec easier to define, because there are no special
cases.
… Whatever temporal interval the ISOBMFF sample selects,
there's always something there. The current text as proposed,
… which might be what Glenn intended, though it's hard to tell,
implies that outside the begin and end of the body, somebody
… could read the spec and say that the renderer returns an
error, document not defined.
Nigel: It's the document processing context that defines what
happens outside the root temporal extent.
Pierre: It's doing the industry a disservice to say we are not
going to define it.
Nigel: I'm nervous that defining ISDs when they're not there
could break some applications.
… For example I think EBU-TT Live defines behaviour based on
the root temporal extent.
… We could go back to my proposal from our F2F at Apple a few
years back, and define attributes on the tt element that allow
the
… beginning of the first ISD and the end of the last one to be
defined, and default them to zero and infinity respectively.
Pierre: It's not clear to me why the root temporal extent is
defined by the body, given that regions have timing.
Nigel: I don't think body does define the root temporal extent,
it has a part to play, but the document processing context can
modify it
… however it likes.
Pierre: The tt element defines the root temporal extent.
[9]8.1.1 tt
[9] https://www.w3.org/TR/ttml2/#document-structure-vocabulary-tt
Pierre: We could do a significant amount of work to define this
more clearly.
… It's worth exploring the proposal you made about defining it
on the tt element - it would be totally explicit.
Nigel: Note that it's a proposal for clip times rather than an
offset relative to which the document times are computed.
Pierre: It's a statement that the document behaviour is not
defined outside of those.
… Independently of that I would be tempted to define that
there's an ISD for every time between 0 and infinity.
Nigel: I think that would be a substantive change compared to
now.
Pierre: I encourage us not to imply that it is different to
that. It won't help MPEG.
Nigel: There's also confusion that's been raised before about
whether the root temporal extent is an interval or a duration.
Pierre: We could go down the path to really try to reconcile
these terms. We've failed before but we could try again.
… In the context of what MPEG is working on is if there is an
ISD defined at every point between 0 and infinity.
… Then their job is super easy.
Nigel: It's also easy if they know that there might not be.
Pierre: It creates special cases.
Nigel: Realistically, the additional case is "if no ISD is
defined, then the presentation is the same as if an empty ISD
were active".
Pierre: What is an empty ISD?
Nigel: It's one that generates no presentation.
Pierre: Does it have an empty body or no body?
Nigel: Does it matter?
Pierre: I think that's something that should be defined in
TTML, not elsewhere.
Nigel: That's probably true.
Pierre: Can you find it in EBU-TT Live?
Nigel: [looks at the document] it defines the terms "Document
resolved begin time" and "Document resolved end time".
Pierre: The concepts of the ISDs that get created and those are
not dependent on each other.
… One concept is the period of time during which some behaviour
is defined.
… The other is what ISDs get created either within that defined
behaviour period or outside it.
… Imagine you're building a renderer: you'd want something to
get returned for every point of time.
… Separately you would want to know if the author defined
something for the time coordinate you're interested in.
Nigel: Right, and the application may override whatever the
author defined.
Pierre: I'm really worried that the current text introduces
additional complexity by implying that there is no ISD defined
outside
… the root temporal extent, which is murkily defined.
… If I specify the begin and end on body, does that define the
root temporal extent?
Nigel: It can't be both ways. The way root temporal extent is
defined permits the processing context to vary it, so if a
processing
… context says "no, it's always zero to infinity", then that's
fine, and that's what would get applied in the proposed text.
… It can't be that the flexibility pins applications down too
much, given this flexibility.
Pierre: The bottom line for me is I don't see how introducing
into the definition of the ISD construction process a vague
term helps any
… any user, especially MPEG.
Nigel: That's one of the roots of the problem: there's already
a vague term - it can't be more vague than completely
undefined!
Pierre: I think leaving it undefined is better than introducing
a term that has insufficient definition.
Nigel: Okay, if there isn't consensus to merge this change,
that's fine. I think it's an improvement, but there's a limit
to how much I'm prepared
… to argue for it.
Pierre: I'm totally game to really work through what the
definition of root temporal extent is and define it clearly.
Nigel: That sounds like a F2F or virtual F2F session, like at
TPAC.
Pierre: Absolutely.
SUMMARY: No consensus to merge this pull request at present.
Nigel: I plan to give this 2 weeks, and if we don't have
consensus to merge, then close it. It's been open only 2 days
so far,
… so others might have interesting things to say about it, who
haven't had opportunity yet.
Meeting close
Nigel: Thanks for the chat today.
… I raised an issue to create a list of topics to potentially
discuss at TPAC.
[10]Create a list of F2F/TPAC topics w3c/ttwg#191
[10] https://github.com/w3c/ttwg/issues/191
Nigel: We'll adjourn here today, see you in 2 weeks. [adjourns
meeting]
Minutes manually created (not a transcript), formatted by
[11]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[11] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 27 May 2021 16:14:43 UTC