15:00:56 RRSAgent has joined #tt 15:00:56 logging to https://www.w3.org/2021/09/30-tt-irc 15:00:58 RRSAgent, make logs Public 15:01:00 Meeting: Timed Text Working Group Teleconference 15:01:02 Agenda: https://github.com/w3c/ttwg/issues/199 15:01:10 Previous meeting: https://www.w3.org/2021/09/16-tt-minutes.html 15:01:12 cpn has joined #tt 15:01:15 scribe: nigel 15:01:47 Present: Pierre, Chris_Needham, Nigel 15:01:52 Present+ Gary 15:01:54 Chair: Gary, Nigel 15:02:09 Regrets: Andreas, Glenn 15:03:38 Present+ Cyril 15:03:56 Topic: This meeting 15:04:15 Present+ Atsushi 15:04:27 Nigel: Today, we have some IMSC HRM progression to discuss, 15:04:37 .. Charter, 15:04:48 .. and WebVTT Unbounded Cues, for which Chris has kindly joined us. 15:05:08 .. In AOB, Atsushi raised a joint meeting we have arranged with APA for SAUR. 15:06:44 .. I'll have to dig out the email to find out when we agreed to meet. 15:06:56 .. Is there any other business to raise? 15:07:04 no other business 15:07:26 mike has joined #tt 15:07:28 Nigel: Any requests about what order we cover the topics in? 15:07:43 Chris: I have another call at half past so if we can cover unbounded cues before then that would help me. 15:07:57 Nigel: OK. Any other constraints on timings? 15:08:13 Topic: WebVTT Unbounded Cues 15:08:30 Nigel: I circulated Chris's summary of Monday's call. 15:09:09 -> https://lists.w3.org/Archives/Public/public-web-and-tv/2021Sep/0018.html Notes from Monday's MEIG call 15:09:23 .. Who can summarise the outcome? 15:09:41 Chris: The issue we were looking at is how to support unbounded cues for timed metadata. 15:09:53 .. We were focused on the timed metadata use case rather than the captioning use case. 15:10:09 .. The idea put forward by Rob Smith (WebVMT) was to introduce a syntax change to WebVMT to 15:10:20 .. allow the end time of a cue to be omitted to indicate that it's unbounded. 15:10:33 .. In the discussion we looked at segmented delivery and concluded that we don't need a syntax change 15:10:47 .. because you can repeat the timed metadata cue within each segment and set the start time and the end time of 15:10:59 .. the cue to match the segment, and then you can match either by the identifier or by the cue content. 15:11:22 .. In order to coalesce the representation in each segment across multiple segments into a cue 15:11:39 .. that spans multiple segments. That allows the duration of the timed metadata to be effectively unbounded because 15:11:52 .. the information can be repeated until the event needs to end, when you fix the end time. 15:12:08 .. That was the conclusion we came to. There's some follow-up work needed to look at the issue 15:12:18 present +mike 15:12:22 .. of identifying cues across WebVTT documents so that cues can be matched up. 15:12:35 .. Then some follow-up work to describe in a Note the processing model that the client would use 15:12:47 .. to detect and coalesce the events. 15:13:00 .. I think from the point of view of segmented media delivery we have a solution that we think is okay. 15:13:14 .. I still have a question as to whether there's a use case for more of a real time delivery, like 15:13:29 .. delivering over WebSocket or real time protocol, where you're not delivering segmented media. 15:13:41 .. That's speculation on my part, rather than a use case I've heard anyone put forward. 15:13:54 .. There'll be a follow-up meeting in a couple of weeks where we can look at the cue identifiers question. 15:14:03 .. Think that's it, did I miss anything? 15:14:11 Gary: That pretty much covers it. 15:14:29 Chris: There's stuff I'd like to do next. 15:14:40 .. We have a document intended to gather use cases and requirements. 15:14:53 .. It would be nice to describe a worked example and then convert that document into use cases plus example. 15:15:00 .. I'm not sure we really need a requirements document now. 15:15:11 .. Gary, would you be interested in developing an example and adding it in to the document? 15:15:16 Gary: Yes, I can do that. 15:15:29 Chris: Then that document could capture the story of where we ended up. 15:15:39 .. Thank you, I'll be happy to review that when it's ready. 15:15:55 .. In the future this group could publish it is a WG Note depending on what you decide is appropriate, here. 15:16:24 Nigel: Thank you both. Any questions or more on that? 15:16:35 Chris: Thank you for your input into the discussion, it was helpful. 15:16:58 pal has joined #tt 15:17:35 Topic: IMSC HRM 15:17:50 Nigel: I'm not sure if we have a lot to discuss today. Opening it up so we can advise on current status. 15:18:20 Pierre: Status is that we created a new repo, imsc-hrm, I created a starting 15:18:26 .. document that reflects IMSC 1.2. 15:18:38 .. I moved all IMSC HRM issues to that repo. 15:18:44 .. There are 3 open pull requests, all approved now. 15:18:56 .. Our rule is 2 weeks, so I expect them to be merged next week. 15:19:06 .. There's one issue left in the backlog, which we can discuss today. 15:19:24 .. It's issue 5, the one that asks if painting the background of a span element should be of 15:19:37 .. equivalent complexity as painting the background of the entire region into which the span is flowed. 15:19:43 .. There's a long thread and some disagreement. 15:20:00 .. My contention is that it doesn't make sense for the background of a span 15:20:11 .. to have equivalent complexity as drawing the background of the region, because region can grow 15:20:21 .. arbitrarily big and font size can grow arbitrarily small. 15:20:37 .. Furthermore a really simplistic implementation of a renderer might have bitmap fonts and might 15:20:53 .. draw backgrounds of glyphs by filling in a blank, which is definitely smaller than a region. 15:21:08 .. My contention is that we should reduce the cost of drawing a span to drawing the background 15:21:22 .. behind each of the characters. Nigel has a different opinion; we have been iterating on that. 15:21:28 Nigel: Thanks for the great summary. 15:22:04 .. Just because Pull Requests have an approval doesn't mean you shouldn't look if you care about it! 15:22:36 .. I'm happy to talk about that issue - we have some time. 15:22:58 Pierre: One option is to take an iterative approach, to publish one version now, 15:23:10 .. then iterate on a fix for that issue. We may not have to resolve it before publishing. 15:23:13 Nigel: Good point. 15:23:18 cyril has joined #tt 15:23:25 RRSAgent, pointer 15:23:25 See https://www.w3.org/2021/09/30-tt-irc#T15-23-25 15:23:33 Pierre: I think there's a new process in W3C to have "evergreen" documents that we could try. 15:23:56 Mike: If it helps the decision making process, I have growing piles of segmented documents that I'd like 15:24:07 .. to throw at the HRM to see what the results are. 15:24:35 Nigel: There is an issue I think needs to be raised and addressed, so far I haven't had time, but there's a comment in one of the pull requests. 15:24:38 .. And that is: 15:25:15 .. There's a question about what we do in the HRM when the ISDs come from multiple IMSC documents delivered in a 15:25:18 .. segmented context. 15:25:45 .. For example, do we need something to address the last ISD of one document being identical to the first ISD of the next document, 15:25:54 .. and if so, what is our test for identity? 15:26:22 .. In the special case of an empty ISD it's quite easy. 15:26:33 .. But for non-empty ISDs it's going to take some thought. 15:27:14 Mike: You may need some explicit signalling to indicate to the renderer that the ISDs are identical, 15:27:25 .. otherwise the assumption would be that it is not. 15:27:37 q+ 15:28:00 Pierre: My experience is that expecting renderers to detect identical ISDs other than empty ISDs is hard or impossible. 15:28:27 Nigel: As a contrary data point, one of our developers told me recently that we do exactly that in one of our player implementations. 15:28:32 ack cy 15:28:56 Cyril: I'm curious about what Pierre said, that it's difficult to compare. Maybe in a general comparison algorithm 15:29:15 .. it would be difficult, but in practice when you segment the document the ISD would be identical. 15:29:27 .. For example hashing could work in some but not all cases. 15:29:39 Pierre: Structural equivalence is easy but rendering equivalence is not. 15:31:37 Cyril: There have been many cases where the documents are structurally the same. 15:31:51 .. The difficulty is when the documents are structurally different but have equivalent rendering. 15:32:13 Pierre: The HRM is not for flicker prevention but for document complexity. 15:34:03 Nigel: Of course it's trivial to construct an example where the last ISD in a segment lasts only a few milliseconds, 15:34:09 .. and then gets duplicated in the next one. 15:34:16 Pierre: Please raise the action and include examples. 15:35:10 Mike: I've been looking at content recently. In general segmented content often fails the HRM, 15:35:25 .. but it's getting better. I'm not seeing very few of these except edge cases. 15:35:37 .. I've never seen failure of the HRM on the first ISD. Just a data point. 15:35:54 .. We shouldn't confuse flicker and decoder optimisation with failure of the HRM on a segment boundary. 15:35:58 Nigel: Very useful, thank you. 15:36:16 Cyril: My second point: when we are talking about side information telling the renderer 15:36:28 .. about identical ISDs. There's something similar in WebVTT in MP4. 15:36:44 .. You can tag a sample with a source id. When you split a sample into two the source id remains the same therefore 15:36:55 .. you can detect that they were the same. I've never seen it used. 15:37:08 .. It's not bulletproof because you could edit the WebVTT after splitting, and then you 15:37:16 .. have to be careful about editing the source id. 15:37:27 .. That was about signalling equivalence of ISDs out of band. 15:37:37 Nigel: Very interesting. 15:38:29 .. I see Pierre is sharing something re the span background issue. 15:38:38 Pierre: Additional background to consider. 15:39:00 .. [shows simple caption on screen] There's a region spanning the entire safe area of the root container is created. 15:39:06 .. displayAlign = after on the region 15:39:21 .. All the subtitles are flowed into that region with the idea that they are bottom aligned and flow up. 15:39:30 .. It works regardless of the size of the subtitle. 15:39:34 .. This also allows roll-up. 15:39:37 .. This is very common. 15:40:06 .. What's also common is to put black background on the span, resulting in background behind the text only - there's linePadding here. 15:40:10 .. Any questions? 15:40:12 no questions 15:40:40 Pierre: This is pretty common. The issue today in the HRM is that drawing the background for each span 15:40:51 .. has the same cost as drawing the background over the entire region. 15:41:03 .. In this case the region is sized to be almost as big as the root container, so this becomes an issue. 15:41:28 .. If you have multiple spans on a line the cost multiplies as the cost of drawing the whole region for each span. 15:41:45 .. This increases the complexity of the ISD significantly, which does not match the cost to implementations. 15:42:01 .. One approach suggested in the issue is that the complexity of drawing the background of the span should 15:42:10 .. scale with the number of characters rather than the size of the region. 15:42:28 .. It's simplifying things, but it's much closer than scaling as the size of the region. 15:42:37 .. There's been a long discussion, and it'd be good to resolve. 15:42:42 .. I will add this picture to the issue. 15:42:44 Nigel: Thank you. 15:44:21 .. I think the problem is understood by those who have commented so far; the discussion has been about how to resolve it, 15:44:39 .. and how to make the HRM match more closely what real renderers have to do, which is to layout the text and then do the drawing. 15:44:56 .. One of the advantages of the HRM now is that it can be applied statically without having to have a renderer. 15:45:44 .. I will copy this discussion into the issue later, since we did not use github-bot and the topic has been much broader than this issue. 15:46:22 .. Question: is it a requirement of the HRM that you don't have to do layout to work out the complexity? 15:46:44 Pierre: I consider it a requirement. The HRM is never going to match implementations but should scale like the complexity of an implementation. 15:47:10 .. That's what's broken right now. It seems obviously wrong right now, the way the span background scaling works. 15:48:06 Nigel: Another approach where it fails now is if people use smaller regions and set overflow and wrapOption to exceed the region. 15:48:11 .. It fails for that case too. 15:49:07 Pierre: I've not seen that. I've seen people try to size the region to the text and get unwanted line wraps. 15:49:16 Nigel: Sometimes people do both, as a safety measure. 15:49:21 Pierre: I'd like to see examples of that. 15:49:36 .. Would be really helpful to get other views on this too. 15:50:05 -> https://github.com/w3c/imsc-hrm/issues/5 span elements are included in NBG(R_i) w3c/imsc-hrm#5 15:50:44 Topic: Charter 15:51:08 Nigel: I just managed to complete my review of the pull request, and noticed one key question to raise. 15:51:24 Gary: I'm still reviewing, will look at it today. 15:52:06 PR -> https://github.com/w3c/charter-timed-text/pull/65 15:52:06 preview -> https://himorin.github.io/charter-timed-text/ 15:52:10 Nigel: Here's the interesting clause I noticed: 15:52:14 .. "All new features should be supported by at least two intents to implement before being incorporated in the specification. " 15:52:28 .. This is for "consider adding" 15:53:09 .. We've never gated features on intent to implement before, but I want to open it up to see what members' views are. 15:53:26 Pierre: I think we should consider relaxing the two implementations requirement to a single reference implementation. 15:53:47 Nigel: That's going to be interesting because of the Process. 15:54:06 Pierre: I brought it up because having a reference open source implementation is to me preferable to having 15:54:17 .. two non-reference or non-open intents to implement, which is very vague. 15:54:22 .. It's at least equivalent. 15:54:26 Mike: I agree with that. 15:54:42 Gary: Is the intent to implement a replacement for needing two implementations? 15:55:03 Nigel: I think it's an attempt to filter out work that would never successfully get to Rec. 15:55:21 Mike: I would argue that a single open source implementation is far better than two secret implementations under any measure. 15:55:37 .. The latter model that W3C has had for a long time was trying to address the reality of folks not necessarily 15:55:49 .. wanting to disclose product details or implementations. That's fine and maybe still okay, 15:56:02 .. but a single open source should be sufficient: almost all orgs do that today. 15:56:22 Cyril: I agree with that, and I'm a big advocate of open source, but I don't think one open source implementation is _sufficient_. 15:56:40 .. One implementation doesn't prove that the standard is working or is adopted or interoperable. 15:56:57 Mike: I agree. It's okay to have two single closed implementations that claim compatibility. 15:57:21 Cyril: It's not only about open or closed source, it's also about the ability to demonstrate it. 15:57:40 .. I understand that W3C staff could look at the testing. I think that's wrong. Fine to avoid disclosing code source, but 15:57:47 q+ 15:57:48 .. at least require a binary to demonstrate testing. 15:57:55 Atsushi: Two things: 15:58:14 .. The same discussion is happening in Process even for web browsers, with Edge moving to Chromium. 15:58:44 .. Even for web browser specs Chromium is effectively single implementation, with a small number of Gecko and Webkit users. 15:59:17 .. Secondly, this text is required by the Process document of W3C so I don't think we can change this. 15:59:32 Nigel: I think it is not a Process requirement, but one of the questions the Director would ask. 15:59:53 Atsushi: There is a possibility to proceed without it, yes. 15:59:55 ack pal 16:00:15 Pierre: The draft charter has a link to implementation experience in the Process, but the Process but does not require 2 implementations. 16:00:24 https://www.w3.org/2020/Process-20200915/#adequate-implementation 16:00:29 .. That's one of the things to consider. What's required is adequate implementation experience. 16:00:41 .. Last time we did the Charter I was not happy that it "ad libbed" on the process. 16:00:54 .. My recommendation is to strike it from the Charter and let the Process speak for itself. 16:01:06 present -mike 16:01:08 .. Just remove the statement, rather than restating it. 16:01:45 Nigel: We're about at time - please could you raise that issue on the Charter draft? 16:02:40 Atsushi: If we want to do something please can we merge the current PR first, which merges the current template in, 16:02:46 .. and use that as a starting point? 16:03:19 Nigel: I think so, yes. When Gary has looked at it perhaps we can raise issues after merging it as suggested. 16:03:27 Atsushi: I will try to address Nigel's comments. 16:03:45 Topic: AOB - Joint meeting with APA 16:03:50 Nigel: I'll send a reminder about this. 16:03:52 Topic: Meeting close 16:04:26 Nigel: Thanks everyone. [adjourns meeting] 16:04:30 rrsagent, make minutes 16:04:30 I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel 16:22:05 i/.. I see Pierre is sharing something re the span background issue./Subtopic: span elements are included in NBG(R_i) w3c/imsc-hrm#5 16:22:15 rrsagent, make minutes 16:22:15 I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel 16:22:26 Present+ Mike 16:22:32 rrsagent, make minutes 16:22:32 I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel 16:23:24 i/Nigel: There is an issue I think needs to be raised/Subtopic: Segmented IMSC 16:23:52 rrsagent, make minutes 16:23:52 I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html nigel 16:24:28 scribeOptions: -final -noEmbedDiagnostics 16:24:32 zakim, end meeting 16:24:32 As of this point the attendees have been Pierre, Chris_Needham, Nigel, Gary, Cyril, Atsushi, Mike 16:24:34 RRSAgent, please draft minutes v2 16:24:34 I have made the request to generate https://www.w3.org/2021/09/30-tt-minutes.html Zakim 16:24:37 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:24:41 Zakim has left #tt 16:26:39 rrsagent, excuse us 16:26:39 I see no action items