css-meeting-bot
commented
3 years ago The Timed Text Working Group just discussed Fix #1232 by clarifying the [resolve timing] procedure w3c/ttml2#1233, and agreed to the following:
SUMMARY: No consensus to merge this pull request at present.
The full IRC log of that discussion
<nigel> Topic: Fix #1232 by clarifying the [resolve timing] procedure w3c/ttml2#1233<nigel> github: https://github.com/w3c/ttml2/pull/1233
<nigel> Nigel: [summarises current state]
<nigel> Pierre: What is the problem with the spec as it stands?
<nigel> Nigel: I think it's a problem of ease of understanding, mainly.
<nigel> .. It seems to me from observation that different readers have different understandings of the ISDs that get generated.
<nigel> Pierre: Maybe that's the crux of the issue. There's a huge difference between what an implementation will generate and how the spec
<nigel> .. defines an ISD. Today the spec does not require an implementation to generate anything.
<nigel> .. It just defines an ISD.
<nigel> Nigel: It gives a procedure for generating them.
<nigel> Pierre: I don't think it compels an implementation to generate that sequence.
<nigel> .. The reason is that in some cases the implementation doesn't want an ISD, it just wants to know the rendering at time X.
<nigel> .. It's output is not a sequence of ISDs, just one rendering.
<nigel> .. I agree with you that in the marketplace I've seen confusion about the rendering process of TTML in general.
<nigel> .. But I think that's different than what the current text says, which I think is fine.
<nigel> .. It could be improved with an explanation or notes.
<nigel> Nigel: I agree - I've written an implementation that doesn't touch ISDs at all, which is fine.
<nigel> Pierre: Conceptually, in my mind, not at an implementation or conformance level, a TTML document can be represented by a sequence of ISDs.
<nigel> .. Here's a procedure to generate that conceptual sequence of ISDs.
<nigel> .. You might ask why you care about those ISDs. If you're trying to render something it's a really useful concept.
<nigel> 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.
<nigel> .. So it seems important that everyone agrees on what the ISDs are.
<nigel> 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.
<nigel> .. Or is there an empty one?
<nigel> Nigel: It's dancing on the head of a pin to try to identify the difference between an empty ISD or no ISD.
<nigel> Pierre: There's a huge difference between saying that a document defines behaviour from a to b, and saying that it is always
<nigel> .. defined from 0 to infinity but may contain empty ISDs.
<nigel> .. 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.
<nigel> .. Whatever temporal interval the ISOBMFF sample selects, there's always something there. The current text as proposed,
<nigel> .. which might be what Glenn intended, though it's hard to tell, implies that outside the begin and end of the body, somebody
<nigel> .. could read the spec and say that the renderer returns an error, document not defined.
<nigel> Nigel: It's the document processing context that defines what happens outside the root temporal extent.
<nigel> Pierre: It's doing the industry a disservice to say we are not going to define it.
<nigel> Nigel: I'm nervous that defining ISDs when they're not there could break some applications.
<nigel> .. For example I think EBU-TT Live defines behaviour based on the root temporal extent.
<nigel> .. 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
<nigel> .. beginning of the first ISD and the end of the last one to be defined, and default them to zero and infinity respectively.
<nigel> Pierre: It's not clear to me why the root temporal extent is defined by the body, given that regions have timing.
<nigel> 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
<nigel> .. however it likes.
<nigel> Pierre: The tt element defines the root temporal extent.
<nigel> -> https://www.w3.org/TR/ttml2/#document-structure-vocabulary-tt 8.1.1 tt
<nigel> .. We could do a significant amount of work to define this more clearly.
<nigel> .. It's worth exploring the proposal you made about defining it on the tt element - it would be totally explicit.
<nigel> Nigel: Note that it's a proposal for clip times rather than an offset relative to which the document times are computed.
<nigel> Pierre: It's a statement that the document behaviour is not defined outside of those.
<nigel> .. Independently of that I would be tempted to define that there's an ISD for every time between 0 and infinity.
<nigel> Nigel: I think that would be a substantive change compared to now.
<nigel> Pierre: I encourage us not to imply that it is different to that. It won't help MPEG.
<nigel> Nigel: There's also confusion that's been raised before about whether the root temporal extent is an interval or a duration.
<nigel> Pierre: We could go down the path to really try to reconcile these terms. We've failed before but we could try again.
<nigel> .. In the context of what MPEG is working on is if there is an ISD defined at every point between 0 and infinity.
<nigel> .. Then their job is super easy.
<nigel> Nigel: It's also easy if they know that there might not be.
<nigel> Pierre: It creates special cases.
<nigel> Nigel: Realistically, the additional case is "if no ISD is defined, then the presentation is the same as if an empty ISD were active".
<nigel> Pierre: What is an empty ISD?
<nigel> Nigel: It's one that generates no presentation.
<nigel> Pierre: Does it have an empty body or no body?
<nigel> Nigel: Does it matter?
<nigel> Pierre: I think that's something that should be defined in TTML, not elsewhere.
<nigel> Nigel: That's probably true.
<nigel> Pierre: Can you find it in EBU-TT Live?
<nigel> Nigel: [looks at the document] it defines the terms "Document resolved begin time" and "Document resolved end time".
<nigel> Pierre: The concepts of the ISDs that get created and those are not dependent on each other.
<nigel> .. One concept is the period of time during which some behaviour is defined.
<nigel> .. The other is what ISDs get created either within that defined behaviour period or outside it.
<nigel> .. Imagine you're building a renderer: you'd want something to get returned for every point of time.
<nigel> .. Separately you would want to know if the author defined something for the time coordinate you're interested in.
<nigel> Nigel: Right, and the application may override whatever the author defined.
<nigel> Pierre: I'm really worried that the current text introduces additional complexity by implying that there is no ISD defined outside
<nigel> .. the root temporal extent.
<nigel> .. If I specify the begin and end on body, does that define the root temporal extent?
<nigel> s/t./t, which is murkily defined.
<nigel> 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
<nigel> .. context says "no, it's always zero to infinity", then that's fine, and that's what would get applied in the proposed text.
<nigel> .. It can't be that the flexibility pins applications down too much, given this flexibility.
<nigel> 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
<nigel> .. any user, especially MPEG.
<nigel> 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!
<nigel> Pierre: I think leaving it undefined is better than introducing a term that has insufficient definition.
<nigel> 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
<nigel> .. to argue for it.
<nigel> Pierre: I'm totally game to really work through what the definition of root temporal extent is and define it clearly.
<nigel> Nigel: That sounds like a F2F or virtual F2F session, like at TPAC.
<nigel> Pierre: Absolutely.
<nigel> SUMMARY: No consensus to merge this pull request at present.
<nigel> 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,
<nigel> .. so others might have interesting things to say about it, who haven't had opportunity yet.
Fix #1232 by clarifying that the active time duration of the current document instance is the root temporal extent, and adding an elaboration note about the permitted range of ISD time coordinates.
This change can be previewed at https://rawgit.com/w3c/ttml2/issue-1232-clarify-isd-construction-build/index.html#procedure-resolve-timing