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: https://
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.
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.
Create a list of F2F/TPAC topics w3c/ttwg#191
Nigel: We'll adjourn here today, see you in 2 weeks. [adjourns meeting]