Meeting minutes
This meeting
Nigel: Today we have 3 main topics.
… 1. IMSC 1.2, not sure if there's a lot we can cover
… 2. TTML2 2nd Ed
… 3. TTML Profile Registry
… Is there any other business, or points to make sure we cover during those?
Cyril: Yes, as an AOB we could discuss what happened at MPEG and the issue raised about
… the notion of empty documents, as an FYI maybe.
IMSC 1.2 ARIB liaison response
Nigel: I haven't had time to collate our thoughts into a draft liaison response yet.
… Not aware of any other points to discuss on this issue?
TTML2 Implementation Report
Cyril: I have an action to check the details of the IR are correct, but the other thing to note
… is that we will need implementations.
Nigel: We have one, but only for one presentation feature, at the moment!
… I had the impression that the TTT tool will be updated to pass all the validation tests?
Cyril: Yes, but the timeline might be a bit far.
Nigel: Right, others are welcome of course.
CSS font-matching algorithm may introduce fingerprinting issues w3c/ttml2#1202 (PING review)
Nigel: Just an FYI that Sam Weiler did contact me, and the action is with me to look for a time
… when interested parties can have a discussion to try to resolve the issue.
… I plan to issue a doodle or similar to try to find such a time.
… Anyone who wants to join that, please do let me know - I imagine at least Pierre and me.
Pierre: Yes, of course.
Nigel: I don't think there's much more to say on this topic at the moment - Andreas made
… some really helpful suggestions on the github issue, but I don't think they added any
… normative language, and that seems to be the sticking point with Sam at the moment.
TTML Profile Registry
Nigel: Glenn has stepped down as Editor, and I've stepped up just to fill the gap,
… but would be very happy if anyone else wants to volunteer.
… I take the hint from Cyril that we can consider all of our documents to be joint ventures.
… Mike Dolan remains an Editor also.
… I want to flag up that we would like to discuss the infamous long-standing issue 71, and
… Mike can join us on the call next week for that.
… [summarises issue as being about the + and | operators in the codecs parameter not being defined]
… Two main decisions:
… 1. How to define - do we need to reference something in TTML2 or not?
… (and if in TTML2 what if that means a change to TTML2)
… 2. Where to define - in the current registry text or elsewhere in the document.
… This has implications about needing to update our registration with IANA or not.
Cyril: It would be easy to discuss if we had a concrete text but I don't know if I will have
… time to produce the text.
Nigel: Yes, though we may need to understand where the likely area of consensus will be first.
Cyril: Regrets from me for next week and the week after - but please do proceed without me.
AOB - MPEG
Cyril: MPEG has been virtually meeting this week.
… I'll paste a link to the discussion that started this AOB.
Cyril: This may affect TTML and WebVTT.
… In CMAF there is a duration, and it is common for there to be no subtitles at some times,
… especially at the end, e.g. during the credits.
… You have to do some padding, but you can also ask the same question between subtitles
… especially in live cases. When you have no subtitle content for some period, what should be delivered?
… In ISO there are 3 specs involved: CMAF, ISOBMFF and MPEG-3 Part 30.
… There is a tool in ISOBMFF called duration-is-empty, which allows you to say there is no
… sample in an MPEG-4 segment. It's not explicitly allowed or disallowed in either Part 20 or CMAF.
… There's a practice where most people use empty documents when there is no content to
… be streamed. This has been documented as a possibility in MPEG-4 Part 30.
… The issue raised is if it should be a recommendation in CMAF.
… The discussion is ongoing and MPEG welcomes feedback on how people should do it.
… My opinion is that if the industry uses empty documents probably we should go for that.
… But in terms of design it would be better to use the duration-is-empty flag. If you have a
… subtitle generator followed by a packager followed by a DASHer, then the DASHer part
… should not need to know the flavour of subtitle format used, ideally. It may not be how
… it is implemented in many workflows.
Pierre: As a data point, in IMF, an upstream master format, there is a requirement to use
… filler timed text documents, presumably empty.
Cyril: I thought there was one single document in IMF
Pierre: No, there can be any number but there can't be a part of the timeline with no document
… associated with it.
… I have seen people put in dub cards and associated an empty document, but I've also
… seen people point to an empty part of an existing document. Both are permitted.
Cyril: That would be an interesting data point for the MPEG issue.
Pierre: It's a slightly different issue for masters, but the lesson is that defining at the package
… level the absence of essence is ambiguous because, what is video black? There is not one
… definition of that. The decision, heavily influenced by it being a master format, is that
… you cannot have empty essence tracks at any point in the timeline, to remove any ambiguity.
Cyril: I understand and agree. It makes sense. The context may be different in the streaming
… context, where there may be absence of things.
Pierre: Yes, and consumers may not mind so much about black picture or audio artefacts at boundaries.
… What is the objection to having empty documents, technically?
Cyril: It highly depends on the workflow, right. In MP4Box, the way it is architectured, the
… DASHing part is completely media unaware. Having to know that you are DASHing
… TTML and having to create an empty document for that.
Pierre: How would that work with video?
Cyril: Same thing. When you DASH and are missing something you could use duration-is-empty.
Pierre: Is that what MP4Box uses today, for video?
Cyril: The question was never raised because you don't have gaps in your timeline. The
… streams are not sparse.
Pierre: Again when you get to dub cards, audio can be sparsed. Historically people have
… chosen not to do that.
Andreas: Question: I thought in part 30 the usage of an empty doc as a filler is mandatory.
Cyril: No, there's a "may".
Andreas: OK, I think we (IRT) always recommended to use it when we worked with streaming
… encoder and packager manufacturers. We would say they should use an empty document.
Cyril: Just to respond to that, it makes sense if the authoring system provides empty documents.
… I wrote in the issue, and Nigel commented on it, that it would be weird for the authoring
… system to provide heartbeat empty documents when there is no content, but it seems
… I was wrong.
Andreas: I know that TTML does a lot of things in MP4 that are really different, and how
… WebVTT is used is more common to how MP4 tracks are built.
… In the EBU Tech3381 spec there is some clarification on part 30 that may be helpful for EBU-TT-D.
… An empty document is defined. But it doesn't say it must be used.
… One last question: is it possible to use 2 options, duration-is-empty and an empty document
Cyril: I don't think it is possible.
Nigel: Tech3381's empty document is defined as "a processor must be able to accept" or
… similar wording - I think in a formal sense that empty document is not conformant to EBU-TT-D.
… Just a side note.
… On the point of defining content that the DASHer can use while being type-unaware,
… how does it handle init segments now?
Cyril: Just describing MP4Box, there is an import phase that is media aware, and it creates
… an init segment once. Then the DASHer is copying things over without looking at the media
… any more.
… To the question about an empty segment, yes, while being media unaware, the DASHer
… could architecturally have a way to deliver empty documents. That is an option.
… I'd like to come back to the point about empty EBU-TT-D documents. Did I understand
… that there are different views of what an empty TTML document is?
Nigel: Clearly yes in the sense that there are any number of documents you can construct
… that have no presentational effect, for example those just containing metadata.
… Specifically in EBU-TT-D there is a cardinality constraint so that body must contain
… at least one div and div must contain at least one p.
… That means that the conformant way to generate an empty document is to have no body.
… But I know one encoder that doesn't do this, it puts out an empty div.
Cyril: It could crash a player?
Nigel: I don't know, that's part of the issue, but it's conformant EBU-TT-D so a player should
… be able to deal with a document with no body. I agree this is a player question primarily.
Pierre: We should call the "empty" document a "minimal" one!
Andreas: The reason we defined the empty document in Tech3381 is because part 30 is unclear about it.
… It is clear that anybody else not using EBU-TT-D may make their own interpretation of an empty document.
… In 3381 we clearly said what an empty doc is, I'm not sure exactly about conformance with EBU-TT-D.
… The other point is that Tech3381 is referenced by HbbTV for DASH, so there may be
… other standards that refer to that definition of an empty document.
Cyril: Yes, the question is not to remove it, but maybe to document it clearly in CMAF, if it is the practice in use.
Andreas: I know streaming encoders use it, maybe not all of them, but definitely some of them do it.
Pierre: I like the idea of being unambiguous. The other thing I wanted to suggest is,
… what about MPEG actually formally asking TTWG for an opinion?
… They could propose a spec to TTWG and ask for an answer.
Cyril: I suggested liaising with different entities, and they could include W3C, for sure.
Pierre: In the past I've seen MPEG just do something, making a quick decision, but in this case,
… maybe we should try something different.
Cyril: That's why I brought it here and brought Nigel into the tickets.
Pierre: If you need help in MPEG taking time to do this well then I'm happy to help.
… It is not a simple topic.
Cyril: Feel free to raise any point you think is difficult to handle in the ticket; that will give
… me arguments to say we should take our time.
… I have one other small point about TTML in MP4, related to the MPEG meeting.
… Mike Dolan came with a contribution about the use of TTML in DASH, possibly in the
… context of ATSC, indicating that it is ambiguous how to create MP4 segments containing
… TTML, with respect to timing.
… We had discussions about the DASH media presentation timeline, the period timeline,
… and the MP4 presentation timeline. Overall I think we agreed, and Stephen Perrott from BBC
… gave an example, of how it should be working. We noticed something suboptimal in
… the MP4 spec, Part 30:
<cyril> The top-level internal timing values in the timed text samples based on TTML express times on the track presentation timeline – that is, the track media time as optionally modified by the edit list. For example, the begin and end attributes of the <body> element, if used are relative to the start of the track, not relative to the start of the sample. This is shown in the figure below, using W3C TTML syntax
Cyril: The reason this was written this way is two-fold.
… I think, timing values when they're nested in time container are relative to the parent
… container?
Nigel: Depends on the value of timeContainer.
Cyril: par and seq?
Nigel: Yes
Cyril: We thought only the top level is significant. But times can be on the body, div, p, span etc.
… The second sentence with the example about body refers to a figure that does not have
… timing on body, so we have raised a defect report. Do you think we have a better way
… to say the first part?
Nigel: I would say that the computed times on TTML elements are on the track presentation timeline.
… In other words, don't delve into the time computation algorithms defined in TTML, but just
… reference the resulting values.
… You could also say that the media timebase coordinates are coincident with the track presentation timeline.
… Also top level timings are not only on body but also region.
Cyril: Individuals can propose wording but a proposal from TTWG would be good.
Nigel: I'm sure we could try to do that, but MPEG should come and ask us.
Cyril: Yes, but we could liaise to say "we've been made aware, here's an answer". I know it's not good practice.
Pierre: Bad things have happened from this in the past!
Cyril: We have a big overlap here with MPEG membership.
Andreas: I would support what Cyril says, to try to help solve the problem regardless of
… the best formal practice.
Pierre: The reason I am resistant is not because I don't want to offer a good solution.
… Rather, if we offer a solution as TTWG, then we will need to be there in person at some
… impossible time at some point in the future to defend that input. If we are not willing to
… do that, then it's not going to happen!
Cyril: Honestly, this will be people known to this group.
… For example Mike has a view on this, and we could invite him here.
Pierre: That would already be a lot better.
Nigel: This is really important for us, thank you for raising it.
Cyril: If I'm not here next week, it would be good to ask Mike about this too.
Pierre: Can you summarise this all?
Cyril: We will write it as a defect report. I will ask if it can be public.
Pierre: I encourage you to ask it to be forwarded to TTWG so people are aware this is happening.
Cyril: I will ask. Thank you.
Pierre: Thanks for bringing this up.
Nigel: Thanks from me too.
Meeting close
Nigel: We're out of time today, thanks everyone. See you next week if you can make it! [adjourns meeting]