13:53:40 RRSAgent has joined #me 13:53:40 logging to https://www.w3.org/2021/06/15-me-irc 13:53:45 Zakim has joined #me 14:00:05 tidoust has joined #me 14:02:03 ChrisLorenzo has joined #me 14:13:08 scribenick: cpn 14:13:19 Topic: Use cases 14:13:24 Gary: Live captioning 14:14:48 zacharycava has joined #me 14:15:05 ... Overlap between live captioning and segmented VTT files 14:15:54 Chris: How is overlap handled with segmented delivery? 14:16:17 Gary: If you know the cue end time, you can just put that, and not repeat the cue in the next segment. That should generally work 14:17:11 ... At FOMS (a long time ago) we talked about segmented VTT delivery. There wasn't the idea of unbounded cues then. If you have the start/end time and text, most caption displays won't display and remove the caption. It will look like a continuous cue. 14:17:36 ... So you could have the previous cue end at the segment bounary, then repeat the cue at the start, with start time set to end of previous segment 14:17:53 ... That's not ideal, and would require display clients to not blink the caption out in between 14:18:14 ... At the time, we thought that shuold be a TTWG note that the client shouldn't do that in these cases 14:18:23 ... Would be nice if there were a more explicit signal 14:19:13 Chris: Any difference between captioning and chapter segments? 14:19:39 Gary: For live chapterisation, it would be the same. It ends at some point, then when you know the next chapter you can update the previous one 14:20:08 Chris: Last discussed in TTWG: https://www.w3.org/2021/05/13-tt-minutes.html 14:22:28 Chris: At that meeting, Pierre talked avbout 14:22:44 s/avbout/about live captioning where a caption may be updated./ 14:23:37 ... Is this a use case to be added to the document - updating existing captions? 14:23:49 Gary: Do you mean updating the text of the cue? 14:23:58 Chris: That seems to be the use case 14:24:19 Gary: That makes sense. Instead of making it into two cues, you could have a single cue that gets updated 14:24:46 ... It would be useful if Nigel or Pierre were on this call. Not sure how other caption formats handle this 14:25:16 ... Having an overview of that should help us, so we're not hitting the same issues with live 14:26:21 Chris: So specific scenarios i listed in the requirements section of the doc: Req1 is updating an existing cue 14:27:00 ... Does this need to be more specific, or do 1a, b, c cover all cases? 14:27:41 Gary: I think so 14:27:55 Chris: Updating just the text or any other attributes? 14:28:19 Gary: VTTCue API allows anything to be updated, so could add that 14:28:40 ... Is this requirements, or more of a wish-list? We may decide we want all or only some of these 14:32:12 Chris: [Describes Use cases vs Requirements] 14:32:30 Gary: Useful to capture the use cases and see how they translate into requirements. 14:33:19 ... We could add a note to say that when we move to the spec we may not address all the requirements. Some could be done in user-land 14:34:15 Chris: looking at use cases, perhaps VTT in fMP4 should move to be a requirement 14:34:44 Gary: Yes, it seems lower level. It's equivalent to segmented VTT. In fMP4 the last cue can be unbounded. I'm not completely clear on that though 14:36:43 Chris: In the TTWG meeting, Cyril talked about sync samples. 14:37:10 Gary: If you have segmented vtt, you can seek to the middle of the video, and you'd only load the segmented vtt from that point on. 14:38:02 ... If you have unbounded cues you'd need to collate them across multiple segments. Otherwise the client needs to collate them 14:38:16 Chris: And that means merging duplicates or reconciling cues that have been updated between the segments 14:38:18 Gary: Yes 14:39:49 Chris: That's kind of in use case 2a, b. Wondering whether to put "live captioning" as the use case. and move those to the requirements list 14:40:56 Gary: This would potentially apply to VoD segmented too. For that you already know the timing, so shouldn't be an issue, so calling it "live captioning" should be good 14:43:11 Chris: Nigel said: "it may be worth understanding and describing a working model for how to deliver live captions in a VTT context.". 14:43:35 Gary: Known end times, and segment accordingly. That's because WebVTT gives you that, so can't do anything else 14:43:46 ... Could be part of the reason why people ship 608/708 to the client 14:46:41 Zack: With 608/708, one of the main reasons we send that for live streams, the state machine running at the encoder to output the cues. It's a non-trivial lift, not easy. Once we have plans to accept TTML based or other captioning formats then normalise everything to WebVTT at that point. 14:47:55 Chris: Does this lead to a requirement for unbounded cues? 14:48:33 Zack: We haven't dived deep enough to know yet. If you're trying to capture whole sentences in 608 as single cues, then unbounded is more likely what you want, then update the unbounded cue 14:48:58 ... Otherwise you might put out bounded captions based on live segment size 14:49:23 Gary: For that, would you have the danger of cutting a sentence in the middle then starting a new cue in the middle of the sentence 14:49:40 Zack: You wouldn't have time, performing updates across 14:50:04 Gary: There's an unofficial draft from 2014 of how to convert 608/708 to WebVTT, it could potentially help 14:50:24 https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html 14:51:06 Gary: It's out of date with respect to new WebVT features, e.g., first version of regions 14:51:46 ... If there's ways to ensure you don't get cues that are really short 14:51:48 jib has joined #me 14:53:07 Chris: I think we have a set of well known use cases, should be reasonable easy to define, and derive a set of requirments from 14:53:25 Gary: And for each requirement, state which use case it relates to 14:54:19 Chris: To conclude, we need to update the document to capture what we've discussed 14:54:32 Gary: I can help, yes 14:55:27 Chris: The doc was an initial idea, happy for things to move around 14:56:26 ... Once the doc is updated, we can get Nigel and Pierre's input on live TTML / IMSC captioning 14:56:31 Gary: Could ask at next TTWG meetings 14:57:58 ... Once we have the doc more fleshed out, then we can decide if we want another call 14:58:18 ... We can use an upcoming MTE DataCue call to get an update too 14:59:36 Chris: Also make sure we've captured the WebVMT requirement properly. I can follow up with Rob on that 15:01:38 [adjourned] 15:01:44 rrsagent, draft minutes v2 15:01:44 I have made the request to generate https://www.w3.org/2021/06/15-me-minutes.html cpn 15:01:49 rrsagent, make log public 15:05:13 jib has joined #me 15:05:13 zacharycava has joined #me 15:05:13 ChrisLorenzo has joined #me 15:05:13 cpn has joined #me 15:05:13 ada has joined #me 15:05:13 gkatsev has joined #me 15:05:13 mounir has joined #me 15:05:13 Orphis has joined #me 15:05:13 emilio has joined #me 15:05:13 sangwhan has joined #me 15:05:13 timeless has joined #me 16:02:25 Zakim has left #me 17:15:12 kaz has joined #me 18:31:01 rrsagent, draft minutes v2 18:31:01 I have made the request to generate https://www.w3.org/2021/06/15-me-minutes.html cpn 18:31:37 Present: Chris_Needham, Chris_Lorenzo, Zachary_Cava, Gary_Katsevman, Francois_Daoust, Atsushi_Shimono 18:31:41 Chair: Chris_Needham 18:31:44 rrsagent, draft minutes v2 18:31:44 I have made the request to generate https://www.w3.org/2021/06/15-me-minutes.html cpn 18:36:42 Meeting: MEIG WebVTT Unbounded Cues 18:36:44 rrsagent, draft minutes v2 18:36:44 I have made the request to generate https://www.w3.org/2021/06/15-me-minutes.html cpn