Meeting minutes
This meeting
Nigel: Just one topic on the agenda really, the MPEG liaison
… Does anyone want time to discuss Patent Policy 2020?
Cyril: No, waiting on position internally - I will follow up.
Nigel: Any other business?
Pierre: Pull Request on IMSC Test Repository
Nigel: Okay
MPEG Liaison regarding ISO/IEC 14496-30 (carriage of TTML in MP4) #167
github: https://
Nigel: The member-tt reflector archive doesn't allow access to the attachment.
Atsushi: I've emailed the systeam about it, it may take some time
Nigel: Nevertheless hopefully we all have the liaison by email?
Cyril: Also I checked internally: MPEG has a spreadsheet of liaison orgs and who is appointed.
… From W3C side it says Jeff Jaffe is the officer. If that is not the case W3C should send a message back asking to update it.
<atsushi> https://
Atsushi: From W3C side there are 3 WGs related, and we have on the page I linked above
… 9 so from our side, it is complicated.
… We have liaison between WG and WG, so I am not sure how we organise liaisons in such
… a complex scenario, but W3C does need to think about it.
… And also if we have time to look at the liaison table we have WG11 from ISO pointed to MPEG but it seems
… SC29 organise the WG coordination so we need to update that also.
Cyril: Yes WG11 does not exist anymore.
… I was also checking, it includes Jean Claude Dufourd who is no longer involved.
… Vlad could be the liaison for the font part maybe.
… But I think in general the right way is to send to the secretariat of SC29 and
… optionally to send to the Chair at the same time if we know who that is.
Atsushi: Usually the team contact is used for each WG. For general liaisons we point to Jeff as CEO.
… I will talk to Philippe after the Thanksgiving holiday about how to update the table.
Nigel: Thanks for the important admin. Looking at the substance of this liaison.
… It looks like the request is for how to express the relationship between the different timelines
… by aligning their zero points.
Cyril: Last time we discussed this, Pierre suggested using "document time zero" as the origin, rather than "timeline".
… I mentioned the " [document temporal coordinate space] " too which is defined in TTML2.
Nigel: Yes, I noticed that term earlier too.
Cyril: I had an action from last time to draft an update.
… (to part 30).
… [shares screen]
… [reads through proposed update to 14496-30]
… I had a question last time. The previous text talked about "body" but we should avoid it because it is not
… clear to me if the outermost element is the region or the body, given ISD construction.
… I noted last time not to use "document timeline"
… Possibly use ISD though that could be confusing.
… The other suggestion was to use a formula, saying time X output from the TTML decoder maps to the ISOBMFF timeline
… I'm not necessarily looking for feedback on the rest from TTWG.
… The idea is to say all TTML documents share the same timeline with the same origin that
… matches the presentation timeline in the ISOBMFF file.
… And then say that the sample times clip the document times, and that's it.
… The rest is not really relevant.
<Zakim> nigel, you wanted to ask about discontinuous - is it allowed?
Nigel: Does 14496-30 constrain the timebase? If smpte discontinuous is allowed then we have to do something.
Cyril: We touched on this last time - it would be great feedback to say it would make life easier if support were removed.
Nigel: Specifically it's for discontinuous markerMode.
Cyril: Yes then the times are treated as labels and can't be compared, right?
Nigel: Right
… The whole notion of timing changes because you have to have some other thing that issues labels that you can compare.
… It doesn't really fit with the timing model of ISOBMFF, I think.
… It would be useful to clarify, if it does not mention at the moment.
… Having done that, I think that [document temporal coordinate space] is the correct terminology to use.
… And I wonder what is supposed to happen if `clock` timebase is used?!
Cyril: My understanding is that smpte timebase is not used extensively but wallclock times may be used in a dash environment.
Nigel: I'm not sure how they would, but conceivably.
… The BBC specifies an epoch for the DASH packaging that's equivalent to the UNIX epoch, so all times are relative to the start of 1970.
… But in the TTML they'd be media timebase, otherwise it's a bit painful going over midnight boundaries.
Cyril: Okay, how do you want to proceed Nigel?
… We want to respond to MPEG?
… The next MPEG meeting is early January.
… It would be great to have a response of some sort by then, even just to get the ball rolling
Nigel: I hoped we would get somewhere today and then draft the response as a later step.
Cyril: What do we want to respond? To say "use [document temporal coordinate space] " if you want to refer to a timeline?
… Or use "computed times" to find a match to document time?
Nigel: I think it's misleading to think about body or region etc
… Instead any time anything changes as defined by the TTML document, the time of the change
… is a coordinate in the [document temporal coordinate space] so it makes sense to say that.
Cyril: That makes sense, yes.
Nigel: Unless there are unusual time modes in ISOBMFF I can't see how it makes sense to use anything other than media timeBase.
… That's what it was defined for.
Cyril: yes
… The clock time base could have use cases, but I'm not sure how to use it.
Nigel: Q: If you had a clock time expression, how would you relate that to the presentation timeline in ISOBMFF?
Cyril: I'd ask back how do you relate the TTML to the related media object.
Pierre: I think this is too complex - just use the ISD times.
Nigel: My point is that unless you can relate an ISOBMFF presentation timeline to a clock time then it makes no sense to use clock timeBase.
Cyril: That makes sense, we should clarify media timebase only.
Nigel: Yes
Cyril: OK, assuming that, then Pierre you said it's simple to use ISD start and end times and we should use that.
Pierre: Anything else is misleading. If you have seq and par containers then having a time in the middle of a document doesn't mean anything.
Cyril: I'm reluctant to start talking about ISD in Part 30 but if the group thinks it is needed then we could.
Pierre: If you're looking to reduce implementor confusion then the only thing that makes sense is the time coordinates
… on the ISDs. That's the interface between ISOBMFF and TTML. How you generate those coordinates in the TTML is a TTML authoring issue.
Nigel: I agree, I'm not sure if we have a clearly defined term for the computed time that applies to the beginning of each ISD.
Pierre: 11.3.1.3 Intermediate Synchronic Document Construction defines this.
11.3.1.3 Intermediate Synchronic Document Construction
Cyril: easier to use bullet 2 [resolve timing] than [construct intermediate document]
Pierre: That's fine as well.
Nigel: That is formally where it is defined.
… So those resolved times T0, T1 etc are times on the document temporal coordinate space.
Cyril: It sounds obvious, that's the only possibility here.
Nigel: That's it I think, it makes sense and is super clear.
Cyril: Yes I think that could work.
Pierre: I would avoid as much as possible talking about how you author a TTML document, in the ISO document.
Cyril: I would say "each document in the sample produces a set of times T0, T1 etc and they're all placed on this timeline, and time zero
… on the timeline is time zero on the presentation timeline".
… What I'm not sure is, it seems a bit circular. You need to know what is the active time duration of the document instance.
… You have that by looking at the first and last times.
Pierre: You're getting a string of digits, in seconds.
… Imagine the rule is to take the output of the ISD construction process, and each Ti is an offset into the ISOBMFF track timeline.
… If it says 2s that's literally 2s into the ISOBMFF timeline.
… Then I can author a TTML document that generates that 2s.
Nigel: I can see Cyril's concern that "active time duration" is not clear and some implementers might think that Ti is relative to
… the beginning of the active time duration, not an absolute value.
Cyril: §8.1.3 has text that seems to be a bit confusing when it comes to root temporal extent and document temporal coordinate space.
Nigel: I can see "active time interval" too.
… I think the text about active time interval and the root temporal extent wording on body is orthogonal to this question of alignment of timelines.
… What I read that text to mean is that if any descendant of body might extend temporally beyond the end of the body's duration, then
… it will not generate an ISD at that point; this is separate to the alignment of those ISD times Ti.
Cyril: How do you define active time interval then, for the document?
… It needs to be clear if ISOBMFF refers to it. I still think there is some ambiguity.
Nigel: What ambiguity do you see?
Cyril: It's a bit circular. To compute the active time duration you need T0 .. Tn and the active duration is Tn-T0.
Nigel: But I don't think you care. What you need to know is how those values Tn relate to the ISOBMFF track timeline.
Cyril: We need to say which values lie outside the period during which an ISOBMFF sample is active.
Nigel: Have to think about truncation as well as active vs not active ISD times.
Cyril: Is it correct to say that the active time interval of the document is the active time interval of the body element possibly clipped by the root temporal extent?
Nigel: I wouldn't.
Pierre: What's the point of doing that?
Cyril: If someone asks me what the active duration is I want to be able to answer that.
Pierre: Why would they want to understand this? Seriously, they should read the spec.
… Something that's not said here under resolved timing is that the first thing you do is interpret every begin, end and dur according
… to SMIL semantics, as per 12.4.
… That will give you unambiguously on every element an absolute computed begin and end.
… That is implied in this [resolve timing] step. Then what you call active duration doesn't really matter.
… All that really matters are those time coordinates.
Nigel: I'm with that.
Pierre: We could improve the text for sure!
Cyril: I don't want ISOBMFF, when it defines the clipping, to conflict with any defined active time duratoin.
Pierre: It's the same in IMF, where it's called the playable region which is a subset of the time spanned by all the ISDs, often.
… [sorry I've got to drop off the call now]
Cyril: I have enough I think.
Nigel: One more thing that may or may not be helpful, but I believe it is true that the root temporal extent is defined
… to be the same as the ISOBMFF sample period.
Cyril: I think so, yes.
… It is defining the external presentation context, the ISOBMFF.
Nigel: Exactly.
… I think the two key points are temporal alignment, and clipping.
Cyril: Yes, I think people get clipping, but maybe not alignment, especially in the live case.
… There may be no sample with presentation time zero, and the ISO document was talking about "start of track" which for
… some people might be ambiguous.
Nigel: Makes complete sense.
… In terms of the liaison response, to help you draft 14496-30, what is useful to send back?
Cyril: Two things:
… 1. Constrain to media timeBase, because clock or smpte doesn't match your expectation.
… 2. We advise MPEG to use the resolved timing procedure in TTML2 which produces a list of time coordinates
… to align with the track timeline. We suggest using that wording.
Nigel: Okay makes sense, I will draft something and share here before sending back.
SUMMARY: @nigelmegitt to draft response based on conversation
Meeting Close
Nigel: It's amazing how fast time goes when you're talking about time! We're out of it for today. [adjourns meeting]