15:01:43 RRSAgent has joined #tt 15:01:43 logging to https://www.w3.org/2022/04/14-tt-irc 15:01:46 RRSAgent, make logs Public 15:01:48 Meeting: Timed Text Working Group Teleconference 15:01:55 Present+ Atsushi, Mike, Pierre, Nigel 15:02:03 Regrets: Andreas 15:02:08 scribe: nigel 15:02:20 Agenda: https://github.com/w3c/ttwg/issues/215 15:02:44 Previous meeting: https://www.w3.org/2022/03/31-tt-minutes.html 15:03:10 Present+ Cyril 15:03:46 cyril has joined #tt 15:04:06 Chair: Nigel 15:04:09 Topic: This meeting 15:04:58 Nigel: Today we have IMSC HRM Wide Review update, 15:05:05 .. DAPT-REQs update 15:05:13 Chair: Nigel, Gary 15:05:17 Present+ Gary 15:05:31 plh has joined #tt 15:05:36 .. Timed Text in Low Latency Streaming applications, 15:05:54 .. Behaviour with non-native controls (in case there's anything more to say about that today) 15:05:59 Gary: Probably not this week 15:06:21 Nigel: And Rechartering status update (for 2nd half of the hour only) 15:06:32 .. Any other business, or points to make sure we cover? 15:06:52 Atsushi: I'd like to point to an error in the DAPT-REQs 15:07:00 Nigel: OK, let's cover that in that agenda topic 15:07:13 group: [no more AOB] 15:07:21 Topic: IMSC-HRM Wide Review update 15:07:44 Nigel: Quick update: I sent the comms out, and got some thank you acknowledgements back. 15:07:52 .. So I think we can tick that action as being done. 15:08:05 .. As is often the case with these occasional liaison messages, there are some updates to the 15:08:14 .. liaisons page that came to light. 15:08:43 .. I have not forwarded any of the thank you/acknowledgements to the member-tt list. 15:08:49 .. Anyone think that's worth doing? 15:08:54 Pierre: I think you can safely not do it. 15:09:00 Nigel: I'm hoping for that! 15:09:16 .. Ok, I won't then. 15:09:33 .. Any questions or points on this before moving on? 15:09:41 Topic: DAPT-REQs 15:10:02 Atsushi: For now we have SVG images integrated in the HTML. 15:10:18 .. That causes fatal errors in the HTML validator which doesn't support XML namespaces in SVG 15:10:35 .. That error comes from HTML Validator and will cause a fatal error during streamlined publication 15:10:58 .. during GitHub Action, so one way is to ask the HTML Validator to support integrated SVG images, 15:11:02 .. which I believe is quite hard. 15:11:16 .. Another is to separate that part as a distinct file, not integrated into HTML. 15:11:23 .. If possible I'd like to propose the latter way. 15:11:37 Nigel: If I understand correctly that will break the page, 15:11:47 pubrules error -> https://www.w3.org/pubrules/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2022%2FDNOTE-dapt-reqs-20220412%2F&profile=DNOTE&validation=simple-validation&informativeOnly=false&echidnaReady=false&patentPolicy=pp2020 15:11:50 .. because it will stop the click-through fragment links in the SVG from working. 15:11:58 .. I think! 15:12:14 Cyril: Yes because inside the SVG you have href fragment ids that point to elements in the HTML, 15:12:16 .. for navigation. 15:12:21 Atsushi: Ah! 15:12:36 Nigel: Exactly 15:12:54 Atsushi: For now I have no idea then. 15:13:05 Cyril: Let's think offline. I don't know if it's a Must, it's a Nice to Have. 15:13:16 Pierre: Have we asked how much trouble it would be to update the validator? 15:13:27 Atsushi: No idea. I suppose there's quite a small activity on that now. 15:13:52 Nigel: I'd note that the W3C Process doc includes an embedded SVG with some behaviour as well. 15:14:14 Nigel: I think the action is to ask about updating the validator. 15:14:16 Pierre: At least. 15:14:36 Atsushi: Yes. In any case please note that there is a possibility of some errors being shown due to this. 15:14:57 Nigel: Yes I can see the validator errors are terrible. 15:15:06 .. But can we still publish? 15:15:32 Atsushi: Yes, for the initial publication of FP DNote it is done manually so we can state 15:15:44 .. that these errors are okay. 15:15:53 .. It should be possible to publish by hand. 15:16:37 .. You may see in that page I pasted above that Charter extension has not yet been announced yet, 15:16:59 .. so there's an error about the group. I'm waiting for that - should happen today or tomorrow I believe. 15:17:19 Nigel: Right. 15:17:41 Nigel: So status now is Not Published Yet. 15:17:51 .. Atsushi will you ask about fixing the HTML Validator? 15:18:07 Atsushi: I will write today or tomorrow to sys team or spec prod. Someone might know something. 15:18:14 Nigel: Ok, thanks. 15:18:32 .. Any more on this agenda topic? 15:18:47 Topic: Timed Text in Low Latency Streaming applications 15:19:05 -> https://lists.w3.org/Archives/Public/public-tt/2022Mar/0010.html Thread that began this. 15:19:15 Gary: I want to note that everything that we're discussing here for IMSC would also apply 15:19:34 .. to WebVTT in terms of HLS segmentation etc. 15:19:47 .. It's something we have started to investigate too, how to do this. 15:20:00 Mike: It's a timely topic. I'm aware of one encoder vendor that implemented something. 15:20:05 .. Still learning what they did exactly. 15:20:45 Nigel: Would be good to start this with a summary of the problem that needs solving. 15:21:00 Mike: The problem is that TTML documents can't really be incrementally parsed and displayed. 15:21:09 .. You have to get to the end of the document and then you can start to present. 15:21:17 .. You can make it better by omitting things like set and animation. 15:21:26 .. In general the model is you get a document, you parse it and display it. 15:21:37 .. That process introduces delay in packaging the segment. 15:21:46 .. You can't start to emit the segment until you have a complete document, 15:21:58 .. and if it's a 2s segment say, you can't emit anything until those 2s are up. 15:22:19 .. This is only for low latency live. If you have VOD and don't care about low latency you don't care about this. 15:22:36 .. In a TV studio like today for ATSC the encoders are taking an MPEG transport stream with 608 captions, 15:22:49 .. and starts transcoding into ATSC 3 including IMSC 1. 15:23:00 .. For video and audio you can encode incrementally with random access points. 15:23:17 .. In the case of IMSC 1 you have to wait until the segment time is over before shipping it off. 15:23:27 .. In practice that imposes a delay in the audio and video today. 15:24:23 q+ 15:24:32 Nigel: And you could reduce the segment duration, but there's something limiting that? 15:24:57 Mike: Every time you make the segment duration smaller there's a lot higher ratio of signalling to content. 15:25:31 .. Some schemes like CMAF limit the minimum duration of a segment to 960ms. 15:25:42 Cyril: Mike, you mentioned 2 things that got me thinking. 15:25:56 .. In live low latency, what would be the constraint that would make the progressive rendering not work? 15:26:08 .. As I mentioned on the thread, it is possible to have a progressive SAX parser and renderer. 15:26:25 .. The 2nd question is: nothing prevents low latency chunks with documents. The overhead increases, 15:26:33 .. but is it that significant compared to audio and video? 15:26:46 Mike: I'm coming at this from the desire to have a backward compatible solution with existing 15:27:03 .. equipment in the field. One of the solutions is chunking IMSC 1. 15:27:17 .. In theory a smarter decoder could parse that and present it. 15:27:31 Cyril: I don't follow - you're saying implementations in the field don't support progressive decode? 15:27:39 Mike: No, the incremental encode into packets... 15:27:57 Cyril: No, I mean 1 segment = 1 sample = 1 document but you deliver this with HTTP chunked transfer, 15:28:09 .. progressively, and you let the renderer handle the SAX parsing and incremental rendering. 15:28:15 Mike: Non-backwards compatible. 15:28:18 Cyril: Why? 15:28:27 Mike: A decoder today wouldn't know how to handle that. 15:28:44 Gary: The expectation is that the document is done after writing and won't get updated afterwards. 15:28:52 Mike: Yes, it's too late in the 1-2s timeframe. 15:29:10 Cyril: So to paraphrase, decoders do not support chunked download and parse? 15:29:15 Mike: They could, but they don't. 15:29:24 Cyril: And why not increase overhead with multiple small samples? 15:29:36 Mike: My reading of 14496-30 says there's 1 document per segment. 15:29:50 Cyril: I disagree, part 30 does not mention segmentation, it talks about carriage into samples. 15:30:04 Mike: I'll check that, maybe I was referring to CMAF. It would solve the problem. 15:30:24 .. But today, a backwards compatible solution would be to start putting out documents incremental 15:30:41 .. and a smart decoder could parse and decode as it goes along, whereas older ones have to wait. 15:30:55 .. Need to take into account that there are some devices that can never be updated. 15:31:08 .. Need to support their behaviour for a while until end of support period. 15:31:15 .. Harder than software decoders, for example. 15:31:35 .. Idea is that the sum of the samples would still be a legal segment. 15:31:42 Cyril: That's not compliant with part 30. 15:32:06 Mike: Not multiple samples, just chunked delivery in different packets, for a single sample. 15:32:40 .. That's one idea that would keep compliance and backwards compat 15:32:41 q+ 15:32:45 ack cyril 15:32:51 ack n 15:34:12 Nigel: Complicated interplay between standards here, with constraints coming from 15:34:24 .. specifications not defined here. How can we constrain our discussion to things that we can control? 15:34:48 Mike: Need to include constraints from ISO. 15:34:57 s/ISO/ISOBMFF 15:35:28 q+ 15:35:40 Nigel: But that doesn't impose any issues - the key constraint here is from CMAF not ISOBMFF. 15:35:54 Mike: The two largest implementations are from DASH and HLS with CMAF. 15:35:56 ack c 15:36:10 Cyril: CMAF does not constrain anything here though - 960ms is a recommendation only. 15:36:16 .. It's the same for audio and video and this is no different. 15:36:32 .. To Nigel's point, what is needed in TTML to solve this use case? 15:36:38 Mike: Different ways to solve this. 15:36:49 .. We could introduce non-backwards-compat features in TTML to help solve this. 15:36:50 ack 15:36:54 Cyril: For example? 15:37:09 Mike: Like assumptions in the case of a partial document, for example. 15:37:16 q+ to ask about whether short segments provide a good UX. Might have really short lines? 15:37:18 .. Not sure I want to go there, it's just an example 15:37:30 .. I hadn't given it a lot of thought until our exchange. 15:37:43 .. Based on a private conversation I thought of a couple of ideas of how it could work. 15:37:57 .. I have a somewhat unique problem with respect to broadcast, which adds a layer 15:38:04 .. in terms of what can and can't be expected to work. 15:38:09 ack g 15:38:09 gkatsev, you wanted to ask about whether short segments provide a good UX. Might have really short lines? 15:38:27 Gary: One of the potential solutions is to have really short segments, and a document per segment. 15:38:39 .. My issue with that is a potentially bad user experience, if there is not enough text to 15:38:52 .. provide a full line. Unless you did a whole bunch of work to position properly. 15:38:58 .. Because you can't append to an existing cue. 15:39:09 Cyril: It's difficult to know the position because you don't know the device font. 15:39:16 Gary: It's like how to handle partial cues. 15:39:30 .. You might want to send stuff to the client before you have all the information you want to have. 15:39:32 q+ 15:41:18 q+ 15:41:54 Nigel: Strict formatting formats make this easier - in the BBC we use word by word live subtitles 15:42:06 .. all the time in IMSC and it works fine as long as the text alignment is set correctly. 15:42:19 .. In situations where, for example, text is centre aligned, it is unreadable. 15:42:29 Gary: Yes, that does make it easier. 15:42:31 ack c 15:42:34 ack n 15:42:46 Cyril: It would really help to have a concrete example, not talking about 15:42:56 .. documents, chunking, segmentation, just what you want to display at what time, 15:43:09 .. then people can propose ways to do it, and we can see where the spec compliance issues arise. 15:43:12 ack 15:43:15 Mike: Happy to put that together. 15:43:22 .. First and foremost, the encode delay. 15:43:31 .. No problem with TTML syntax for timing. That's not the issue. 15:44:00 .. Given a paint-on progressive delay, within a single document you can add text in small numbers of letters. 15:44:10 .. Most decoders work pretty well that way. 15:44:23 .. Good question, so I'll try to explain the problem in more detail in writing, with a picture or two. 15:44:33 .. I'll take that as an action item. 15:44:36 Cyril: Thank you. 15:45:27 Nigel: Just a clarification question about the requirements: is anyone worrying about data rates? 15:45:41 Mike: In general no, but one of the things we have had to do is reconstruct the screen for a 15:45:47 q+ to ask about character/word deletions from say 608 15:45:57 .. random access point in every segment. The first thing to worry about is recreating the screen 15:46:12 .. from scratch. That could be tedious. So far that hasn't hurt the processors but it gets 15:46:20 .. quickly out of control, hence the focus on the HRM. 15:46:32 .. The initial implementations to make this work were terrible and violated the HRM. 15:46:41 .. Now the output is HRM conformant that helped bound the complexity. 15:46:47 Nigel: Thanks. 15:46:50 ack g 15:46:50 gkatsev, you wanted to ask about character/word deletions from say 608 15:47:02 Gary: Maybe not to answer right now, but one thing brought up previously 15:47:12 .. with regards to live captioning is that sometimes the captioner can delete words or 15:47:23 .. characters in 608, and depending on how you're doing live captions you might, 15:47:36 .. say if you're emitting VTT or IMSC caption right before a delete command, how would you 15:47:40 .. go about deleting that word? 15:47:53 Mike: This is an issue with live captioning. So far the encoders have ignored it. 15:48:00 .. I haven't produced any tests with backspace. 15:48:24 Gary: This is probably a longer term thing, we don't need to worry in the short term. 15:48:32 Mike: For now it's a general problem not a low latency live one. 15:49:50 Nigel: In IMSC just as you can add text you can remove it, so I don't think that's a format problem per se. 15:50:05 .. If you're in a cue based environment where cues cannot easily be changed, I don't know how to resolve that. 15:51:13 .. For time, let's close off now unless there's anything else burning on this topic? 15:51:20 Topic: Rechartering status update 15:51:23 [plh joins] 15:51:27 Present+ Philippe 15:51:58 Nigel: Atsushi already advised that we're expecting a Charter extension. 15:52:07 Philippe: It's on my list - your Charter runs out at the end of the month? 15:52:11 Nigel: No, two weeks ago! 15:52:36 Philippe: Oops - Atsushi, do you want to do it? It has approval already. 15:52:48 .. I'll get on it - I have a bunch of announcements to AC to go too. 15:53:01 Nigel: The other side of this is dealing with the FOs. 15:53:42 scribe+: gkatsev 15:53:57 pal has joined #tt 15:54:20 nigel: last time we talked, we had tried to contact apple to get more info for the FO 15:54:28 .. and we got a response. 15:54:47 .. Asked if Adobe's proposal of indenpendenant would be good/enough. 15:54:52 .. Response was no, but good change. 15:55:16 q+ 15:55:26 .. Independenace of implementation was the big issue for them. 15:55:40 .. Could be that the way we defined facts and verifications doesn't look like implementations to Apple. 15:55:57 .. No further follow-up from Apple yet. 15:56:19 phl: I had a talk with Apple last week. 15:56:29 .. big change in charter. 15:56:56 .. From their point of view, the new change doesn't satisfy "adequate implementation experience" 15:57:12 .. If spec says in CR for longer, that's fine. 15:57:43 nigel: AC rep from Google also objected. 15:57:52 .. asked what's defined as an implementation. 15:57:53 ack plh 15:58:02 .. He stated that treating content as an implementation isn't good enough. 15:58:37 .. Ralph's view seemed to support our charter updates. 15:59:02 plh: they want to raise the bar. 16:00:51 .. You don't have to agree with their views. 16:01:07 .. People who read the specs should be able to reproduce without talking to the spec maintainers 16:01:39 nigel: following up from being able to implement from the spec 16:01:58 .. but a lot of specs don't necessarily allow this 16:02:19 .. Should we wrap it up for today? 16:02:32 s/phl/plh/ 16:02:40 .. Should we adjurn for today? 16:02:43 .. Yes. 16:03:53 rrsagent, make minutes 16:03:53 I have made the request to generate https://www.w3.org/2022/04/14-tt-minutes.html nigel 16:06:52 s/backspace/bakspace 16:06:54 s/ack// 16:06:56 s/ack// 16:07:02 s/bakspace/backspace 16:07:07 rrsagent, make minutes 16:07:07 I have made the request to generate https://www.w3.org/2022/04/14-tt-minutes.html nigel 16:09:23 s/a lot of specs don't necessarily allow this/some specs do allow implementation choices, deliberately, e.g. CSS 16:09:40 s/Yes./[adjourns meeting] 16:09:48 rrsagent, make minutes 16:09:48 I have made the request to generate https://www.w3.org/2022/04/14-tt-minutes.html nigel 16:10:22 s/adjurn/adjourn 16:10:25 scribeOptions: -final -noEmbedDiagnostics 16:10:34 zakim, end meeting 16:10:34 As of this point the attendees have been Atsushi, Mike, Pierre, Nigel, Cyril, Gary, Philippe 16:10:36 RRSAgent, please draft minutes v2 16:10:36 I have made the request to generate https://www.w3.org/2022/04/14-tt-minutes.html Zakim 16:10:39 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:10:43 Zakim has left #tt 16:11:05 rrsagent, excuse us 16:11:05 I see no action items