17:31:52 RRSAgent has joined #tt 17:31:52 logging to https://www.w3.org/2022/09/15-tt-irc 17:31:54 RRSAgent, make logs Public 17:31:55 Meeting: Timed Text Working Group Teleconference 17:32:44 tidoust has joined #tt 17:33:53 Agenda: https://github.com/w3c/ttwg/issues/226 17:34:02 Previous meeting: https://www.w3.org/2022/09/01-tt-minutes.html 17:34:11 Chair: Gary, Nigel 17:34:32 present+ 17:34:53 Present: Andreas, Alexander_Flenniken, Atsushi, François, Gary, Hew, Nigel 17:35:22 scribe: gkatsev 17:35:36 nigel_: welcome, this is thursday at TPAC, first TTWG meeting 17:35:43 .. earlier had a joint meeting with MEIG 17:35:50 .. later on today we have an APA joint meeting 17:35:56 .. Accessible Platforms Architecture 17:36:08 .. to talk about Synchronization Accessible User Requirements 17:36:17 .. Our agenda is primarily with the DAPT 17:36:27 .. and there are a few TTML issues to cover as well 17:36:37 .. Is there anything else for today's call? 17:37:04 .. We will get to intros in a moment 17:37:14 .. Tomorrow's meeting is much longer with a lot more topics 17:37:23 .. Might come back to more topics 17:37:35 .. Rechartering moved slightly to accomodate Phillipe 17:37:44 .. And joint with Media WG is tomorrow 17:38:03 .. Anything else today or tomorrow 17:38:22 scribe: gkatsev, nigel 17:38:35 Gary: Tomorrow, with Media WG may be worth bringing up text based audio descriptions 17:38:48 Nigel: From the breakout session yesterday? 17:38:52 Gary: Yes 17:39:33 nigel_: Apple showed using WebVTT to drive speech synthesis to provide audio descriptions 17:39:54 .. I also led a meeting about getting user data from the video element without breaking user privacy 17:40:09 .. there should be minutes for those sessions 17:40:23 .. Independent Interoperable Implementations meeting was yesterday as well 17:41:20 .. should we mention both webvtt and DAPT work? 17:41:24 Gary: why not? 17:41:56 nigel_: Introductions 17:42:19 .. you probably noticed that Gary and I are the chairs 17:42:30 cyril has joined #tt 17:43:09 Alexander: I work at Bocoup. I'm interested because I worked on a personal project and implemented captions 17:43:15 .. and wanted to know what's up 17:43:40 atai: I'm Andreas Tai from Munich, I'm an independent consultant and previously worked for a german broadcaster 17:43:47 atsushi: I'm a w3c contact for the TTWG 17:44:07 Francois: I work for the W3C where I track media related activity 17:44:42 Hew: Hew Maxwell I work for red bee media. Produce a lot of AD. 17:45:08 cyril: Cyril, I work for netflix. Currently working on the DAPT document and WebVTT/TTML for netflix 17:45:15 nigel_: our first agenda toopic is DAPT reqs and issues 17:45:52 .. I think the issues are fairly straight forward 17:45:56 .. Should we start with the new one? 17:46:13 .. Comment from Simon who works at yello-umbrella 17:46:23 .. wants to adjust process step 4 17:46:33 .. about defining audio mixing instructions for AD (AD only) 17:46:54 .. that can be useful for the dubbing workflow, where the original M&E track isn't available 17:47:08 .. or it's desirable to mix over original voice 17:47:26 .. Does that make sense? 17:47:32 all: yeah 17:47:41 s/a german broadcaster/german broadcasters/ 17:48:01 nigel_: I better open a PR for that 17:48:18 .. issue #16, amount and rate of gain in 2.7 17:48:24 .. in the same section as above 17:48:41 .. [quotes from the doucment] 17:49:03 .. I don't quite understand the ambiguity, but might need a rewrite to make it clearer 17:49:48 .. issue 7, event will come up later, we better cover this 17:50:01 .. in the reqs, we have set of events 17:50:31 .. document defines list of intervals called an event 17:50:38 cyril: did you respond to nested events? 17:50:48 nigel_: definition of event is list of events with begin and end times 17:51:04 .. I struggle with events, good to open up for discussion 17:51:16 .. from our discussion cyril, we weren't happy with the name "event" 17:51:22 .. comes up with the data model 17:51:33 .. theres timed entities at the top and we need a name for them 17:51:38 q+ 17:51:41 .. calling them event is a new bit of terminology 17:51:44 .. doesn't exist in TTML 17:51:53 .. webvtt has distinct concept of cue 17:51:59 .. and has a close analogy, but not quite the same 17:52:10 ack atai 17:52:27 atai: I remember I think the concern the name overlaps with other things like javascript 17:52:40 .. I could imagine integrating another programming language could get very confusing 17:52:51 .. maybe if it is prefixed to make it special to the profile 17:53:00 .. could still be event but prefixed 17:53:12 hew: speech event? 17:53:29 cyril: yeah, you may want to represent on-screen text, which won't be speech 17:53:42 when you're describing the content, there may be text you want to repsent 17:53:51 hew: is the output speech? input may not be speech 17:53:58 .. but isn't the output always speech? 17:54:14 cyril: yes, but we have different types of scripts 17:54:22 .. you can't script pre-recorded 17:54:29 .. intermediate steps may not be speech events 17:54:37 .. may not have content in it 17:55:06 atai: could call dapt:event 17:55:20 .. but could be confusing because event in xml could also have a namespace prefix 17:55:39 nigel_: although , we want to map to existing ttml rather than a new entity 17:55:48 cyril: maybe provide a description but still call it event? 17:55:58 nigel_: still could cause confusing 17:56:02 cyril: like dom events? 17:56:10 .. I don't think there'll be a lot of overlap 17:56:22 nigel_: I did some research into this into how script writing tools handle this 17:56:29 .. and best I can find is paragraph 17:56:47 .. we may want to make these divs, but if it's called paragraph someone might want to make it p 17:57:10 cyril: I think we should keep it event, I think overlap is small 17:57:13 nigel_: would script event work? 17:57:18 cyril: still javascript script 17:57:34 atai: it's hard to know intuitively by the name alone 17:57:43 .. a more descriptive name would be better 17:57:48 cyril: like script interval? 17:57:55 nigel_: that's quite general purpose 17:58:04 .. script interval sounds just like a time range 17:58:12 .. but it needs to be associated with an element at the end 17:58:28 cyril: could have someone else 17:58:35 nigel_: proposals: 17:58:40 .. keep "event" 17:58:43 .. "speech event" 17:58:49 .. "script interval" 17:59:06 .. "script event" 17:59:19 atai: I like "script event" because it's the closest to what it 17:59:22 .. is 17:59:30 nigel_: event sounds like a single moment in time 17:59:36 .. it's a range and not a period at time 17:59:46 hew: events need time to happen 17:59:52 .. script event sounds fine to me 18:00:08 nigel_: we have a shared editorial goal to make it as easy to read 18:00:18 .. "script event" would be easiest to tweak to see how it works 18:00:51 gkatsev: do we need to answer it right now? 18:01:03 nigel_: we do want a FPWD soon (today maybe?) 18:01:14 .. we're going to try script event, but we're open to other suggestions 18:01:33 cyril: what about nesting? 18:01:43 .. the fact that audio fade in and fade out 18:01:48 .. are these two different events? 18:01:53 nigel_: we need to be clear about nesting 18:02:03 cyril: I wouldn't call it nesting, but variations 18:02:10 .. phases, maybe. Not nesting 18:02:53 gkatsev: I think that webvtt calls time overlapping cues as nested cues 18:03:02 .. as a data point 18:03:20 atai: maybe write it as one word? 18:03:29 nigel_: I don't think this will be an element name, but a div or p 18:03:43 .. part of the data model is to relate to the TTML 18:03:49 .. script is made from script events 18:03:55 .. and TTML is like this 18:04:05 .. data model and data structure use different terminology, slightly 18:04:08 cyril: model defines the terms 18:04:34 .. ttml defines the syntax, but no new terms 18:05:07 nigel_: where we have these nested like in example 5 18:05:15 .. of ADPT 18:05:21 .. these could be timed steps 18:05:39 cyril: script event is the high level concept 18:05:43 nigel_: entity? 18:06:01 cyril: forexample, AD spoken at this time 18:06:08 .. point 2 or point 3 seconds is a bit of a detail 18:06:26 nigel_: we're not calling them sub events 18:06:31 cyril: I don't think we need to name them 18:06:38 .. I think it's AD specific 18:06:43 .. not applicable to dubbing 18:07:03 nigel_: actually, we just considered something for dubbing, which was AD only previously 18:07:12 cyril: I understood it as mixing and not animation of gain 18:07:21 nigel_: animation is part of it 18:07:36 .. so if you need to duck audio for the dub 18:07:43 .. you def would want to lower the gain 18:07:47 cyril: and certainly a curve 18:08:11 nigel_: I think we've got an editorial action there we can do in the reqs and DAPT itself 18:08:21 .. issue 6 from cyril 18:08:26 present+ 18:08:33 cyril: I created the issue based on your comment Nigel 18:08:41 nigel_: this is a data modeling point 18:08:48 .. maybe we can pass it by and not worry too much 18:09:55 .. [showing some ADPT reqs] 18:10:05 .. I think maybe not an issue 18:10:11 cyril: lets close it then 18:10:18 nigel_: event doesn't need to have content initially 18:10:23 .. could have an empty div with times in it 18:10:39 cyril: yes, especially in step 1, the first step is indetifying gaps 18:10:48 nigel_: identify a set of script events 18:10:54 .. yeah, let's close it 18:11:23 .. definition of script event doesn't require content 18:11:38 Present+ David_Singer 18:12:09 cyril: last isue is the MAUR 18:12:14 nigel_: I think we can just do that 18:12:23 .. I'll take the action to update the DAPT reqs 18:12:33 .. those are all the issues on dapt-reqs 18:12:41 .. I'll try to do an editorial pass later this after noon 18:12:57 cyril: if we look on issues on the document, there's plenty 18:13:15 nigel_: if you've been swamped, cyril and I have been doing lots of editorial work 18:13:22 .. and created lots of issues for editorial work 18:13:32 .. should we descript where we are at editing? 18:13:36 cyril: major changes we've made 18:13:39 .. the introduction 18:13:46 .. and adding step-by-step examples 18:13:54 .. they can start reading top to bottom 18:14:01 .. and will be less dry than directly into technical aspects 18:14:09 .. Nigel has been porting structure of ADPT work 18:14:22 .. by adding sections like Definitions and Conformance 18:14:28 nigel_: worth saying why at this point 18:14:35 .. When I drafted ADPT, I closely followed IMSC 18:14:40 .. to make it a profile of IMSC2 18:14:52 .. to make things required or options. That kind of thing. 18:14:58 .. If need be, define additional features 18:15:03 q+ 18:15:05 .. formally, I think that's what it is 18:15:21 .. what's the best way to make it a usable spec, while making the required formal steps 18:15:34 cyril: I think we have an agreement that it should be easy for the reader 18:15:38 .. and not need to be an expect for TTML 18:15:45 .. but at the same time we want it to be Correct 18:15:52 .. in the sense that it should be based on TTML 18:15:57 .. and validate that the script is TTML 18:16:05 .. and a TTML processor should be able to process this script 18:16:18 .. that second part shouldn't be emphasised, but not hidden 18:16:29 .. This document is targetting authors and implementors 18:16:49 .. Shouldn't have too much to go to TTML2 spec or TTML1 spec to start implementing 18:16:55 .. If they wanted to better understand things 18:17:07 Present+ Pierre 18:17:24 nigel_: I'm very interested on your views on this, Pierre 18:17:37 .. based on your experience on your work on IMSC 18:17:47 .. can you describe your thoughts? 18:17:57 pal: I haven't had chance to look at the latest changes 18:18:02 .. There's at least two audiences 18:18:11 .. First, someone who just wants a quick start 18:18:26 .. Someone who wants to try it and get a quick result as fast as possible 18:18:31 .. That might be done 18:18:44 .. As soon as you try doing something more esoteric, you'll need to read the spec 18:18:51 .. I have the same relationship with the HTML spec 18:19:00 .. Most of the time I just had a template 18:19:09 .. but sometimes need to refer to the spec or MDN documentation 18:19:21 .. I think to target different sets of readers 18:19:36 .. I would have a really good set of examples and then details spec 18:19:41 cyril: what do you call it? 18:20:09 pal: in the case of IMSC, the last version of IMSC have a pragmatic approach to make a profile of TTML 18:20:17 .. what's missing in IMSC is a section on best practices or a quick start 18:20:26 .. "how to do simple subtitles" 18:20:39 nigel_: there's a bit of me over the years of doing IMSC 18:20:57 .. there's almost annoying details that are hard to make details that explain but also make it formal 18:21:02 .. and don't leave holes 18:21:07 q? 18:21:15 ack atai 18:21:16 q+ 18:21:29 atai: I agree with cyril that possible this spec maybe more read by non-technical people 18:21:32 .. compared to IMSC 18:21:37 .. or other TTML profiles 18:21:55 .. Would be very valuable for a section that those people can read to understand DAPT and use it correctly 18:22:09 .. issue with IMSC and WebVTT is making it human readable to make it easily understandable 18:22:22 .. WebVTT is doing at the beginning lots of example explaining things 18:22:37 .. I think this is what Pierre is proposing and I think that would be a good way to do it 18:22:59 .. I would also agree with cyril if you need to make it a decision to make it more complex or easier to understand 18:23:02 ack cy 18:23:04 .. maybe choose makeing it easier 18:23:10 cyril: I'd like to make 3 points 18:23:20 .. 1. this profile will be much simpler than IMSC 18:23:31 +1 18:23:38 .. I feel this should be possible to write the spec slightly differnet from IMSC because you don't need to understand as much complex details 18:23:57 .. point 2 and 3. is the notion of processor 18:24:14 .. validating and content processors, lots of concepts 18:24:20 .. In order to make it simpler in DAPT 18:24:29 .. I suggested we define whic processors we envision here 18:24:38 .. maybe a recorder or a converter to subtitling format 18:24:45 .. we define what conformance means for those processors 18:25:00 .. we can say it's a TTML processors 18:25:10 .. but basic usage doesn't need to know it's a TTML processor 18:25:20 .. 3rd point is the notion of features 18:25:35 .. we decided to demonstrate TTML implementation via features 18:25:48 .. and we map each to a value and what not 18:26:02 .. that's why in IMSC 1.1 we define the features and the new features defined in IMSC 1.1 18:26:09 .. I think that's complex to understand for a non-expect 18:26:14 .. I understand the value of defining feature 18:26:22 .. Makes IR and conformance and coverage easyier 18:26:28 q+ 18:26:29 .. I'm not disagreeing wiht defining features 18:26:42 .. but we shouldn't necessarily define features in the way we've done it in IMSC/TTML 18:26:57 .. that's hard to understand for those that don't already know TTML 18:27:17 .. Folks don't understand the big features table in the specs 18:27:23 .. WE can do a simpler job in DAPT 18:27:34 .. maybe push it into an annex, so that it isn't first to readers 18:27:39 nigel_: as long as it's normative 18:27:42 ack n 18:27:45 cyril: yes 18:28:02 nigel_: I think I've got a slight uncertainty on how useful the features list 18:28:11 .. might be slightly more useful than you might think 18:28:21 .. implementor can work through that list one at a item 18:28:31 .. which might help implementors as a kind of TODO list 18:28:52 cyril: I'm willing to do a first pass and propose something for features 18:29:08 nigel_: to me it makes little difference whether it's in the main spec 18:29:12 q+ 18:29:31 .. or an annex that comes at the end 18:29:40 .. makes little practical difference 18:29:56 .. I understand the more you scroll the harder/more complex it feels 18:30:05 cyril: we agree it is simpler 18:30:17 q+ 18:30:20 q+ to mention IMSC compat 18:30:21 .. but we see lots of features, even if lots are prohibited, because you have to go through it all 18:30:36 atai: as a data point when we started EBU-TT 18:30:48 .. we deliberatly chosen not feature approach because we didn't understand it 18:30:56 .. and once we thought it might be useful to have a features list 18:30:59 .. we then put it at the end 18:31:05 .. and we put it in the end 18:31:12 .. for those that aren't familiar with TTML, it's hard 18:31:26 .. we need to put ourselves in the shoes of people who are just appraoching the spec 18:31:29 +1 18:31:31 pal: just two thoughts 18:31:37 .. moving to an annex sounds like a good idea 18:31:42 .. a casual reader shouldn't care 18:32:04 .. in IMSC we unfortunately, had to list permitted and prohibited, because about half is permitted/prohibited 18:32:15 ack at 18:32:16 ack pal 18:32:18 ack n 18:32:19 nigel_, you wanted to mention IMSC compat 18:32:28 .. in DAPT, most things are prohibited, so, might simplify the table by only listing permitted and say everything else if prohibited 18:32:36 nigel_: I wanted to mention something that's directly related 18:32:42 .. should we base this directly on IMSC? 18:32:56 .. we couldn't do it, because IMSC prohibited some things that we wanted in DAPT 18:33:09 .. but we should be able to turn DAPT document into a captions document 18:33:15 .. by allowing everything allowed in IMSC 18:33:25 q+ 18:33:27 .. conformance test could have optional 18:33:46 .. or perhaps we can just have a sentence "everything permmitted in IMSC that isn't mentioned here, is optional" 18:33:55 .. optional means you can put it into the document but you can also leave it out 18:34:23 .. only test would be a validator could complain about TTML syntax that is used that isn't even listed as optional 18:34:31 .. we have 3 different versions of IMSC 18:34:41 .. can say everything in latest IMSC as optional 18:34:46 .. or mark each feature as optional 18:34:52 ack at 18:35:12 atai: when I thought about it today, I think the beauty of the profile is that it's styling agnostic 18:35:18 .. beyond dubbing and AD even 18:35:33 .. I'm not sure by allowing all IMSC features, you risk this becoming an IMSC profile 18:35:55 .. it's not about styling and layout but just about script events 18:35:56 q+ 18:36:00 ack n 18:36:03 .. I wouldn't highlight this in the document 18:36:10 nigel_: what you raised there is kind of interesting 18:36:15 .. there's a whole other approach 18:36:27 .. we can make an IMSC 1.3 or 2 and introduce an audio profile there 18:36:38 .. and add in audio requirements a long with text/image 18:37:32 .. and in DAPT point at the IMSC audio profile 18:37:49 .. would only need a note about how to fulfil reqs for IMSC audio profile 18:37:58 cyril: my first thought it's probably not a good idea 18:38:16 .. IMSC is for subs, I don't see why adding audio to it 18:38:29 .. the title of the document is profile*s* 18:38:39 .. how would you feel if we define two profiles in this document instead of one 18:38:47 .. central one would be without audio/animation 18:38:56 .. and other one will be with audio/animation support 18:39:06 .. animation is complex and audio could be complex 18:39:17 .. in dubbing you generally don't need mixing instructions 18:39:28 .. it seems like this might be a good idea with nested profiles 18:39:32 q+ 18:39:39 ack at 18:39:39 .. because someone could adopt first profile and then adopt second one later 18:39:52 atai: generally I agree another IMSC profile isn't good 18:40:04 .. for nesting and having two profiles, a superset and a subset maybe that works 18:40:11 q+ to mention profile levels 18:40:20 ack n 18:40:20 nigel_, you wanted to mention profile levels 18:40:21 .. each profile with distinct features could be confusing 18:40:34 nigel_: one thought I had about it, it lets people who are making dubbing authoring tools 18:40:53 .. allows those not to add unnecessary featurs but say it's conforming 18:40:57 .. and vice versa 18:41:11 .. one thought I is not to call it two distinct things 18:41:22 .. maybe a level 1 and level 2 things 18:41:29 .. to show that one is building on top of the other 18:41:47 cyril: we never had this notion of levels before 18:41:52 nigel_: it's just a name 18:42:03 q+ 18:42:03 cyril: but if you receive a document and you want to know if you want to process it 18:42:13 nigel_: you'll need two profile designator 18:42:17 cyril: then you have two profiles 18:42:20 ack at 18:42:22 nigel_: good point 18:42:48 atai: as I said before, the profile itself could be used outside of AD and dubbing 18:42:56 .. maybe as first step for captioning 18:43:03 .. and maybe won't need multiple profiles 18:43:10 [David_Singer leaves] 18:43:21 .. I'm not sure could be solved in a way that the features could be documented separately 18:43:54 nigel_: not sure I quite follow 18:44:10 atai: what's the driver for two profiles? Confusion by people having features they won't use? 18:44:23 .. like dubbing folks not needing any AD? and having trouble implementing the spec? 18:44:32 .. or parsers needing to conform to both but only caring about one? 18:44:49 .. Maybe have one profile but separate the usecases in the spec 18:45:05 nigel_: comes to defining classes of processors that cyril mentioned 18:45:15 .. could have a class of processors that support AD or Dubbing 18:45:16 q+ 18:45:26 ack gk 18:45:47 Gary: WebVTT has CSS extensions with a section that says a WebVTT processor 18:46:00 .. without a web engine can still be conformant if it doesn't support the CSS extensions 18:46:35 nigel_: hello kim 18:46:40 Present+ Kim_Patch 18:46:54 Kim: I work with frontline to make interactive transcripts 18:46:57 .. and we use WebVTT 18:47:06 .. and there's some issues we've had to jerryrig 18:47:12 .. and I wanted to let you know 18:47:17 .. Don't know much else about this group 18:47:31 .. if that would be useful or maybe connect to someone 18:47:35 nigel_: yes definitely be useful 18:47:40 .. we could create some time now 18:47:54 .. or if there's some edge cases on DAPT reqs 18:48:03 .. can we come back to it in a minute? 18:48:18 cyril: what could help decide the structure 1 profile/2 profile 18:48:31 .. to indentify features 18:48:48 .. what's shared is script events and timing, script type idenfitication, and optional styling 18:48:58 nigel_: on-screen annotation should go in the middle too 18:49:06 .. AD would read out on-screen things 18:49:21 cyril: not sure if character identification would be needed in AD 18:49:35 .. contextual langauge, I'm unsuage about, maybe useful to make AD in another langauge 18:49:46 .. maybe should be shared too 18:49:52 nigel_: but timing could be different there 18:50:15 cyril: audio and animations that are those that you don't need in first pass when doing dubbing 18:50:27