15:00:01 RRSAgent has joined #tt 15:00:01 logging to https://www.w3.org/2021/06/24-tt-irc 15:00:05 Zakim has joined #tt 15:00:08 cpn has joined #tt 15:01:54 zakim, start meeting 15:01:54 RRSAgent, make logs Public 15:01:55 Meeting: Timed Text Working Group Teleconference 15:02:30 Present+ Andreas, Glenn, Nigel, Pierre, Atsushi 15:02:46 Present+ Chris_Needham 15:03:14 Agenda: https://github.com/w3c/ttwg/issues/188 15:03:25 Previous meeting: https://www.w3.org/2021/06/10-tt-minutes.html 15:04:03 Chair: Nigel 15:04:12 Regrets: Cyril 15:04:42 scribe: nigel 15:04:47 Topic: This meeting 15:05:29 Nigel: Today, we have a topic Gary requested, about handling live delivery of TTML, which I propose we tackle when he has joined. 15:05:38 Present+ Gary 15:06:20 .. We also have 2 issues on TTML2, which perhaps we can make progress on. 15:06:54 .. I have kept the IMSC HRM issue about spans on the agenda in case there is anything to discuss. 15:07:22 Pierre: On the HRM thing, I haven't made much progress but I think we should take 10 minutes to talk about strategy. 15:07:37 .. How do we propagate HRM changes through IMSC 1.0.1, 1.1 and 1.2? 15:07:43 .. Rather than going through the issues themselves. 15:07:50 Nigel: Ok, good idea 15:08:02 .. Then we have an IMSC Test issue/pull request. 15:08:12 .. In AOB we have TPAC 2021. 15:08:24 .. Any other points to discuss or make sure we cover? 15:08:28 group: [none] 15:08:38 Topic: How live delivery is handled in TTML/IMSC 15:09:16 Nigel: This was asked by Gary - perhaps we should work out if there is a quick answer or if we need a longer session. 15:09:24 Gary: This comes from the unbounded cue discussion last week. 15:09:41 .. Partly because of your mention Nigel, one of the issues is how unbounded cues work with live captioning. 15:10:01 .. There is segmented captioning happening with WebVTT and HLS, also done for live. I have an understanding of how that works, 15:10:10 .. but not how TTML and IMSC does live. I suspect it might be similar. 15:10:22 .. Figured it would be similar, but wanted a sense of it so that if there are any specific 15:10:28 .. problems then we don't repeat the same issues. 15:11:16 scribenick: cpn 15:11:33 Nigel: The first thing to note with TTML is that it's an application layer on top of TTML 15:11:48 ... You probably need constructs for streaming delivery around TTML, provided by other things 15:12:20 ... I know of 4 wrappers around TTML that do this: MPEG-2, MP4 DASH/HLS streaming, RTP, and the EBU TT-Live extensions 15:12:35 ... The all provide some sort of time windowing of the TTML document, and they send a sequence of TTML documents 15:12:57 ... The only one that doesn't use a wrapper is EBU TT-Live 15:13:27 ... The wrapper defines a time window with a beginning and a duration that signals: from this point time onwards, this single TTML document is active 15:13:39 ... As a consequence of that, any previously active TTML document is no longer active 15:13:58 ... The last piece of the puzzle is to align the timelines between the TTML payload content and the external timing 15:14:07 ... There are established ways to do that, defined in the wrapper 15:14:11 pal has joined #tt 15:14:15 q+ 15:14:38 ... There could be an external timeline, e.g., an epoch such as 1 Jan 1970 and times are relative to that. Or each TTML document starts at time zero relative to when document playback begins 15:15:10 ... The question then is how to do it for live? Live captioning is captioning of an audio stream that also has a separate mechansim for encoding, packaging, and distribution 15:15:39 ... The requirement, from an audience perspective, is to get the captions in a way that's aligned with the audio. They could be a little bit late, or co-timed with server side delays 15:16:15 ... We generally dont' have completely unbounded stuff. Can't issue for encoding, packaging, distribution until you get to the end of the time it applies to 15:16:56 ... You could have a single subtitle that begins at some time, with no end time. It would have no end or dur attribute in the document 15:17:13 ... The application semantics would say that the document stops being active and a new document becomes active 15:17:15 q- 15:17:27 ... If the TTML document appears unbounded in that case, the application applies a bound 15:18:07 Pierre: They way modern packaging and streaming formats work, the playlist is at a higher level than the TTML document. The playlist sets the bounds 15:18:31 Gary: That's helpful. That aligns with what I figured, which also applies to segmented WebVTT 15:18:47 ... A question would be: do unbounded cues makes sense for TTML2? 15:19:11 s/TTML2/TTML too/ 15:19:19 Nigel: If you want a semantic that says within the document there's no end time for an element, it can already be done. Simply omitting the end time does that 15:20:03 Gary: The end time is defined by how it's delivered to the application. A cue with no end time or duration would be forcefully bounded by the media segment it's embedded in, e.g., MP4 15:20:05 Nigel: Yes 15:20:57 ... The last document stays active until you activate another one. In a segmented MP4 context (DASH), it's generally predefined when segment ends / segment durations will be 15:21:29 Pierre: I've not seen a requirement for unbounded cues yet 15:22:02 Gary: We'll continue with WebVTT on the use cases and deriving requirements. If it make sense for live captioning to have unbounded cues in webvtt, we could maybe also talk about application in TTML 15:22:07 q+ 15:22:14 ack n 15:22:18 ... It's still early. Not clear that having unbounded cues is a requirement we want to proceed with 15:22:58 Nigel: Are we asking the wrong question? The conversation about bounded/unbounded cues starts from an assumption that a cue is a semntic object in its own right that a user can interact with 15:23:25 ... In the scheme's I've talked about, there's not a requirement to semantically identify a signle piece of content as it changes over time 15:23:39 q+ 15:23:41 ... Instread, the focus is on delivering the right presentation by delivering the documents 15:24:06 ... If a client wants to do some analysis to identify duplicates (for example), it's up to the application 15:24:20 q- 15:24:26 ... Having one thing that gets updated is a different semantic model 15:25:05 Pierre: People talk about subtitle cues, there's a good mapping with pop-on captions, e.g., on a DVD. It breaks down when you talk about progressive subtitling, where words appear additively, paint-on 15:25:24 ... Or where lines appear in the same region. In those scenarios the concept of a subtitle doesn't work at all 15:25:44 ... There's no such thing as "a subtitle". The TTML model is text flowed in a region 15:26:34 Gary: I think that for the document that Chris started we're trying to separate high level use cases (e.g., live captioning) from requirements - e.g., create unbounded cue so we can deliver earlier, for example 15:27:06 ... So we want the right use cases. The individual cues are less important than knowing that we're capturing spoken word 15:27:08 q? 15:27:20 Nigel: Have we answered the question? 15:27:25 scribenick: nigel 15:27:28 Gary: It does for me 15:27:53 Chris: The question I have is around other kinds of metadata. In WebVTT I think it's possible 15:28:06 .. that you can annotate chapter points, or denote segmentation of the content. 15:28:19 .. In that case if you're starting a new chapter, which says "this news segment just started" 15:28:26 .. and it starts now and we don't know the end time, 15:28:35 .. is there any equivalent model in TTML for that kind of use case. 15:29:07 Pierre: Yes, absolutely. It's possible in TTML to specify that an element has an undefined end time. 15:29:18 Chris: And then it becomes application specific how to interpret that. 15:29:29 Pierre: What to do with it. The interpretation in TTML is pretty unambiguous. 15:29:39 .. Then do you leave it undefined or clip the presentation to some value. 15:30:18 Nigel: There's nothign to stop you adding your own metadata to an element, e.g., to indicate which chapter you're in 15:30:46 ... That segmentation applies to content rather than there being some other "thing" that has start or end time signalled 15:31:25 Pierre: As I understand it, WebVTT came from SRT, which came from DVD subtitles. That's a really specific use case, subtitles for translation. It's all pop-on 15:31:39 Gary: It has other mechanisms 15:32:02 Pierre: People say "a cue" or "a subtitle", a model that only works if it's pop-on subtitles or captions 15:32:21 Nigel: Any other questions? 15:32:27 Chris: No 15:33:12 Topic: Shear calculations and origin of coordinate system. w3c/ttml2#1199 15:33:22 Glenn: Status update on what I've been doing. 15:33:35 .. We recently finalised our implementation of line shear and block shear (tts:shear) 15:33:52 .. in the TTPE package. It's checked into a branch right now, possibly merged into the main branch. 15:34:10 .. We were able to verify the correct origin and orientation of the axes for both line shear and shear 15:34:28 .. in all of the writing modes in combination with different default paragraph level bidi levels. 15:34:33 .. That looks good. 15:34:43 .. One of the things we wanted to do was to resolve an issue Nigel had brought up 15:34:57 .. regarding processing of tts:shear semantics because in order to compute the adjustment 15:35:13 .. to the inline progression dimension (ipd) for doing line breaking, it is necessary to know 15:35:26 .. the value of the block progression dimension (bpd) that will be used for that adjustment. 15:35:38 .. The value of bpd may depend on having performed line breaking, so there is a potential 15:35:49 .. recursive process to resolve what the value of the bpd might be. 15:36:03 .. However after analysing the TTML specification semantics we realised that 15:36:18 .. bpd on a block area such as a paragraph is always defined in the sense that it has an initial value 15:36:33 .. which is auto, and at the present time, auto is defined such that it maps to 100%, 15:36:51 .. which means that the container area bpd in which the paragraph will be fitted constrains the 15:37:04 .. maximum value of the bpd, and in fact fixes it, because in all cases we can map 15:37:15 .. that back up to some region which is definite in its height and width and therefore bounded. 15:37:37 .. The long and short of it is that bpd = auto = 100% = bpd of the container area constrained by region size. 15:37:50 .. It can be no larger than the bpd of the region in which that p is placed. 15:38:02 .. The default semantics for doing shear calculation of the ipd can be determined ahead 15:38:07 .. of time when bpd = auto. 15:38:24 .. If bpd is set to some other value, e.g. an explicit length, or minContent, maxContent or fitContent, 15:38:36 .. which are defined in TTML2 but not used in IMSC, then other processes can be used to 15:38:52 .. determine the value of BPD and therefore plugged into the shear calculation to get the adjustment to ipd. 15:39:01 .. We were able to verify that and check that into our codebase, 15:39:11 .. and have entered it into the implementation report as having been implemented. 15:39:25 .. We added an expectation file in ttml2-tests for the TTPE output, so we 15:39:29 .. view that as having been resolved. 15:39:35 .. The next step is to update the spec as necessary. 15:39:40 .. Cyril has mentioned a couple: 15:39:46 .. Change sin theta to tan theta. 15:40:02 .. Add information about the origin and orientation of the axes for the purpose of performing the skew transformation. 15:40:09 .. I've started work on creating that update. 15:40:23 .. I plan to generate some SVG visuals that can go into the spec that 15:40:41 .. show the origin and axis for the different writing mode combinations wrt the paragraph directionality. 15:40:47 .. I expect that in the next few weeks. 15:41:00 .. We're trying to get all of the TTML2 tests implemented and checked into TTPE so that we have 15:41:12 .. resolved any issues in the tests and that will allow us to at least have one implementation 15:41:18 .. of every test that is listed in the implementation report. 15:41:36 .. Right now there are 3 tests left for us to complete, which should take 2-4 weeks approximately. 15:41:47 Nigel: Thank you Glenn. Any questions. 15:42:00 s/s./s? 15:42:27 SUMMARY: @skynavga Glenn to continue working on specification pull request. 15:42:39 Topic: Clarify if the first ISD must/may be constructed when empty w3c/ttml2#1232 15:42:57 github: https://github.com/w3c/ttml2/issues/1232 15:44:48 Glenn: I added a comment to the PR 15:44:52 -> https://github.com/w3c/ttml2/pull/1233#discussion_r650411506 Comment 15:45:08 .. pointing out that there is already text in the TTML element that makes the equivalence between 15:45:28 .. active document interval and root temporal extent. We already have established that, 15:45:54 .. it is just that this particular instance in this procedure should have the consistent language. 15:46:03 .. It is not introducing anything new or different in my opinion. 15:46:07 .. I'd like to see that move forward. 15:46:18 Nigel: Am I correct that you're not happy with that Pierre? 15:46:29 Pierre: If we are going to make that change we should rationalise the terms across the document 15:46:40 .. and really get to the bottom of what the term root temporal extent means. 15:46:49 .. I don't think we should make this change piecemeal. 15:47:10 Glenn: I think this started because the wording "active document duration" appears and it is the only place where it appears 15:47:24 .. exactly like that. The intent here is simply to resolve that one issue. 15:47:29 .. It is clear that's what is meant here. 15:47:35 Pierre: I don't think it is clear. 15:47:53 .. The term that has been used has been duration, now we're replacing it with extent. 15:48:00 .. I would like to know what root temporal extent means. 15:48:04 Glenn: That boat has sailed. 15:48:17 Pierre: I don't know, it's been ambiguous and we should say what it does. 15:48:26 .. It is not defined in the document, we're trying to clarify it. 15:48:33 Glenn: Root temporal extent is defined as a term. 15:48:46 Pierre: It is a circular definition. If we're clarifying it, we should say what it means or does. 15:48:59 Glenn: The intent of this change is not to modify the define root temporal extent. 15:49:15 Pierre: It actually changes the interpretation though. 15:49:27 .. My situation is to go back and rationalise what root temporal extent means. 15:49:31 .. We should not make piecemeal changes. 15:49:47 Glenn: I find that quite interesting and wouldn't discourage anyone from undertaking such a project. 15:50:00 .. This particular issue is not predicated on reviewing the definition of root temporal extent. 15:50:07 .. If you think it is true I would like to see the argument. 15:51:27 Nigel: This has been discussed before. It would be good to explain why this procedure depends on the term 15:51:39 .. root temporal extent and defines it, which is circular. 15:52:34 Pierre: The XXXXScribeMissedXXXX 15:52:48 Glenn: The root temporal extent is defined by the document processing context. 15:53:04 Pierre: It's never clear to me how there can be an implicit duration but no implicit begin and end. 15:53:19 Glenn: This goes back to the semantics of SMIL which make use of the term implicit duration in a highly technical manner. 15:53:29 .. We have used that definition in the context of TTML. 15:53:44 .. SMIL does not (I don't recall) define an implicit begin or end and we did not do that. 15:53:55 .. That sounds like a new work item/requirement that is not on our docket right now. 15:54:13 .. I think it is inappropriate to slip it into this PR - it may be an interesting question and possibly elaborate that 15:54:26 .. more in the definition of root temporal extent. But it is clear in the current language that we have 15:54:40 .. an equivalence statement in the specification of the tt element, so what this change proposes is simply 15:54:50 .. to make that usage consistent within the document because we had a case in the timing 15:54:56 .. semantics that did not define that properly. 15:55:08 Pierre: By the way SMIL does define implicit end and implicit begin. 15:55:09 Glenn: Thank you 15:55:14 Pierre: Do they apply here? 15:55:21 Glenn: That's outside the scope of this PR in my opinion. 15:55:39 Pierre: That's my point, if we are tweaking or capturing the original intent of root temporal extent then we have 15:55:44 .. to get to the bottom of this. 15:55:56 .. My interest here is that there has been confusion here about what the active duration 15:56:11 .. of a TTML document is, if you try to render a document outside its active duration. 15:56:29 Glenn: Durations have a fixed usage in TTML and SMIL that is independent of the begin and end points. 15:56:41 .. If you can resolve the begin and end then the difference is the active duration. 15:57:00 .. I still fail to see how you can interpret the current PR as an attempt to redefine the root temporal extent, 15:57:12 .. especially as we already have the statement that makes that equivalence. 15:57:48 .. If the phrases are different from the intended meaning in resolve timing, then I don't know what else it could be. 15:58:04 .. "Active time duration" sounds like a shorthand for that tt element definition. 15:58:12 .. So this change seems to make this more consistent rather than less so. 15:58:21 Nigel: By the way that is my position as well. 15:58:34 Glenn: If you think this is redefining root temporal extent I would like to see the argument for that. 15:58:51 .. It is not the intent, and if it were true then we would have to revisit the language in the tt element as well, which is 15:58:54 .. not in the scope of this issue. 15:59:13 .. I have no objection to revisiting and trying to fine tune the use of the term root temporal extent. 15:59:40 Nigel: Thank you, we're running out of time. Anyone else have anything to add on this? 15:59:57 .. [no] - we need to work out a way to resolve. 16:00:42 .. I brought this to the group to try to work out how to get to consensus on the PR. 16:01:06 Pierre: Maybe we're closer than you think - remove the note, and take the "i.e." out, but ultimately the 16:01:13 .. root temporal extent is application specified. 16:03:10 Nigel: Thank you, please could you comment on the pull request so we can end the call? 16:03:17 Pierre: Happy to stay on and discuss further if you have time. 16:05:17 SUMMARY: Nigel and Pierre to continue discussions. 16:05:21 Topic: Meeting close 16:05:48 Nigel: Thanks everyone, let's adjourn for today. [adjourns meeting] 16:32:04 rrsagent, make minutes 16:32:04 I have made the request to generate https://www.w3.org/2021/06/24-tt-minutes.html nigel 16:40:35 rrsagent, make logs public 16:40:40 rrsagent, make minutes 16:40:40 I have made the request to generate https://www.w3.org/2021/06/24-tt-minutes.html nigel 16:49:57 i/Nigel: There's nothign/scribe: cpn 16:50:11 i/Glenn: Status update/scribe: nigel 16:50:43 s/The all provide some sort of time windowing/They all provide some sort of time windowing 16:51:02 s/EBU TT-Live/EBU-TT Live/g 16:51:46 s/dont' /don't 16:52:38 s/semntic/semantic 16:52:57 s/In the scheme's I've talked about/In the schemes I've talked about 16:53:11 s/signle/single/g 16:54:01 s/nothign/nothing/g 16:58:07 s/XXXXScribeMissedXXXX/[scribe missed this - apologies] 16:59:27 s/Nigel and Pierre to continue discussions./Nigel, Pierre and Glenn to continue discussions. 16:59:35 rrsagent, make minutes 16:59:35 I have made the request to generate https://www.w3.org/2021/06/24-tt-minutes.html nigel 17:12:45 s/, which I propose we tackle when he has joined// 17:16:46 s/don'thave/don't have 17:17:11 s/Can't issue for encoding/It is not possible to issue documents for encoding 17:17:55 s/Instread/Instead/g 17:18:27 i/Gary: It does for me/scribe: cpn 17:18:44 i/Chris: The question I have/scribe: nigel 17:22:30 rrsagent, make minutes 17:22:30 I have made the request to generate https://www.w3.org/2021/06/24-tt-minutes.html nigel 17:24:34 scribeOptions: -final -noEmbedDiagnostics 17:24:37 zakim, end meeting 17:24:37 As of this point the attendees have been Andreas, Glenn, Nigel, Pierre, Atsushi, Chris_Needham, Gary 17:24:39 RRSAgent, please draft minutes v2 17:24:39 I have made the request to generate https://www.w3.org/2021/06/24-tt-minutes.html Zakim