14:58:06 RRSAgent has joined #tt 14:58:11 logging to https://www.w3.org/2024/05/23-tt-irc 14:58:11 RRSAgent, make logs Public 14:58:12 Meeting: Timed Text Working Group Teleconference 14:58:27 Agenda: https://github.com/w3c/ttwg/issues/282 14:58:31 scribe: nigel 14:58:35 Chair: Gary, Nigel 14:58:54 Present: Nigel 14:59:04 Previous meeting: https://www.w3.org/2024/05/09-tt-minutes.html 14:59:13 Regrets: Chris Needham, Pierre 14:59:20 rrsagent, make minutes 14:59:21 I have made the request to generate https://www.w3.org/2024/05/23-tt-minutes.html nigel 15:02:40 Present+ Ewan, Andreas 15:02:58 Present+ Atsushi 15:04:07 atai has joined #tt 15:04:10 Topic: This meeting 15:06:03 Nigel: Today we have DAPT, TTML2 ttm:role and TPAC 15:06:26 .. Is there any other business or points to make sure we get to within those topics? 15:06:43 no other business 15:06:50 Topic: DAPT 15:08:08 Subtopic: Required metadata field for earliest SMPTE time code to allow conversion between DAPT and ESEF w3c/dapt#232 15:08:20 github: https://github.com/w3c/dapt/issues/232 15:10:10 Ewan: The issue was around conversion between legacy formats and DAPT. 15:10:28 .. DAPT is related to media time. The issue I had is, when converting from ESEF with explicit SMPTE timecodes, 15:10:46 .. I needed to decode the media time in the DAPT relative to the SMPTE timecode. 15:11:00 .. But there isn't a metadata field helping to do the mapping in DAPT or TTML2. 15:11:27 .. For some authoring platforms you can't specify the timecode of the first frame of the programme, 15:11:35 .. just the timecode of the first description. 15:11:53 .. That's likely the best metadata value to reflect in DAPT to use for this conversion activity. 15:13:48 q+ 15:14:24 Nigel: I see this as a problem of relating the DAPT media time to the SMPTE timecode of the source media, 15:14:41 .. which you need to do so that, during a thing called "compilation", which takes as input a programme timecode 15:15:02 .. for the beginning, and generates a single WAV file the duration of the programme, 15:15:18 .. that compilation process can know when, relative to the begin time passed in, the DAPT media time begins. 15:15:22 ack atai 15:15:31 Andreas: Thanks Ewan for bringing up this case. 15:15:44 .. I understand this as being about the mapping between two different time coordinate systems. 15:15:57 .. A source file and maybe a target file in the SMPTE timecode space but DAPT is media time, 15:16:11 .. and to get proper conversion you want some metadata either telling what the source timecode is, 15:16:26 .. or, for converting to a target file, that uses SMPTE timecode. Is that correct? 15:16:38 Ewan: yes, it's trying to find an anchor that's common between both. 15:16:51 Andreas: Yes, that could be a common use case, but I'm not sure if it falls in scope of DAPT, because 15:16:59 .. it is information outside the DAPT document itself. 15:17:15 .. It is tricky because the information is specific to the DAPT document. 15:17:34 .. I wonder if it is useful to define some metadata in W3C or DAPT, or you could always use any kind 15:17:39 .. of metadata to enable this use case. 15:17:57 .. The overall question is: is this a workflow problem, or do we expect it to be a common use case 15:18:05 .. that needs to be supported in different workflows? 15:18:16 Ewan: Difficult to say, easy for me to speak to my own workflows. 15:18:29 .. The most common workflow involving compilation requires the presence of the media. 15:18:46 .. You wouldn't have single WAVs and an exchange document. That maybe makes it more unusual 15:19:00 .. and less general for me. It's possible that others have the same difficulty with the same process. 15:19:11 .. Or they could capture the information externally to the exchange document. It's a good question, 15:19:16 .. I'm not sure I can answer it. 15:19:28 .. It's also specific to this conversion use case, between ESEF and DAPT. 15:19:37 .. Without this metadata I don't think DAPT can accommodate that use case. 15:20:12 .. It feels like that is a use case we can consider - is DAPT a clean slate for new workflows? 15:20:20 q+ 15:20:42 Nigel: I'm sympathetic to this use case, partly because I think ESEF is one of the de facto "standards" 15:21:01 .. used by a lot of people, and I think creating a pathway for migration to DAPT would be very helpful. 15:21:05 ack at 15:21:24 Andreas: It's sort of tunnelling some metadata through the DAPT document. I think that it's a use case 15:21:40 .. that's not specific to DAPT, right. It could be for conversion against legacy STL files and TTML too. 15:22:03 .. As Nigel said, we have defined this metadata field in the EBU, startOfProgramme, which is kind 15:22:20 .. of the data we're looking for, but I'm not sure if you could use this and find a semantic for this use case. 15:22:39 Nigel: I thought about this and decided it is close, but not the right thing. 15:25:05 .. The trouble is that during the conversion process you may not know the start of programme timecode. 15:25:19 .. All you definitely know is the timecode of the first description and the media time you're giving that. 15:25:36 .. If you happen to know the start of programme timecode you could use it for this, but it would have to 15:25:40 .. come from some other source. 15:25:50 Present+ Gary 15:26:15 Ewan: The legacy format does have some theoretical provision for start of programme, but it wasn't ever implemented, 15:26:22 .. which is frustrating. 15:26:42 Andreas: In EBU STL we have two different metadata fields, one is startOfProgramme, and the other, 15:27:05 .. that relates to the timecode of the first description, would be the first Timecode In cue (TCI). 15:27:16 .. I think we have not defined that in EBU-TT, I'm not sure. 15:27:33 .. Ewan, you're saying you want both, the start of programme timecode and the timecode of the first description, 15:27:41 .. because it depends on the platform, which is available. 15:27:48 Ewan: Yes I think so. 15:29:27 Nigel: My experience of conversion workflows is that the more standalone they are the better, 15:29:43 .. because if you have to start introducing other data from other sources that introduces the potential for errors. 15:30:46 .. the other thing I thought about with this is if this use case is an argument for allowing SMPTE timecodes 15:31:03 .. in DAPT, but I think it's better to have a cross-reference data point in the document that relates 15:31:22 .. the media time to some other external SMPTE timecode than to suffer the implementation difficulties 15:31:35 .. that others have had with SMPTE timecode in TTML, in terms of getting correct implementation of 15:31:51 q+ 15:31:54 .. dropMode, frameRate etc, where interoperability has been a problem. 15:31:59 ack at 15:32:13 Andreas: Maybe you can explain a bit what you mean about a cross reference data point? 15:32:34 .. Still I'm wondering if I have understood the full impact - why should this be specific to DAPT and could 15:32:41 .. not be something that also relates to other data in TTML? 15:33:02 Nigel: What I mean is some metadata that relates a fixed point in the media timeline with a fixed point 15:33:28 .. in the alternate SMPTE timecode timeline, e.g. media time zero = 10:00:00:00 SMPTE. 15:33:42 .. Exactly one value would be present if the mapping is needed. 15:33:46 .. Or no values if not. 15:34:08 .. It may well be a problem for other uses of TTML, but it hasn't been as presented as one, 15:34:13 .. with such a clear use case, so far. 15:34:50 Andreas: OK, what you propose is to map a DAPT media time to a SMPTE timecode timeline? 15:34:52 Nigel: Yes 15:35:07 Andreas: That's quite a generic solution, definitely, but if we have two data points, like in STL, 15:35:22 .. one for start of programme, the other the timecode of the first description or first frame of content, 15:35:32 .. would that also work? What would be a blocker for that solution? 15:36:00 Nigel: You could do that, I just think if everyone is using the same media time reference point, that's 15:36:15 .. halved the likelihood of different implementations. 15:36:51 Andreas: I see your point, maybe we need to see what others think. 15:37:06 .. What Ewan described seems to be a well understood in the world where this solution is being used. 15:37:24 .. It could be that people building these solutions have something already known and implemented. 15:37:38 .. I agree your solution is the cleaner way, and from a structure point of view, maybe a better fit. 15:37:42 .. I'm not sure if its easier. 15:37:49 Nigel: Interesting question. 15:38:42 .. Thinking about next steps, I wonder if it's worth opening a pull request for this. 15:39:40 .. It could even be an "at risk" feature. I think the idea of this solution is that it allows flexibility but 15:39:53 .. is pragmatic for anyone coming from usage of this legacy format. 15:40:24 .. Andreas, were you hinting that the best place to define this metadata is not DAPT, but somewhere else? 15:40:39 Andreas: Yes, I was wondering where it should go instead. I saw that this kind of metadata could apply 15:40:51 .. to other use cases. Then you open it up for a different kind of content. 15:41:28 Nigel: I'm taking this as implementation feedback, because it came about during Ewan's attempts to implement DAPT. 15:41:32 .. That's very strong. 15:41:51 .. I'd be happy to open a pull request to propose something, even if we say it's "at risk", and then 15:41:55 .. get more review on that. 15:42:08 .. Any other thoughts on this? 15:42:23 SUMMARY: @nigelmegitt to open a pull request to propose a DAPT-specific solution 15:43:03 Subtopic: Add section about mapping from TTML to the DAPT data model w3c/dapt#216 15:43:09 github: https://github.com/w3c/dapt/pull/216 15:43:14 Nigel: Status update on this. 15:43:26 .. So far no reviews since the most recent discussions and changes to the pull request. 15:43:40 .. I completed the extension feature work. 15:44:32 .. I'd appreciate people's views on whether my assessment of the normative statements that we make 15:44:42 .. into extension features is right. 15:44:59 .. I also ran into a breaking change in Respec. 15:45:13 .. Two things: first, the "simple" class on tables used to be implemented directly by Respec, 15:45:29 .. and the maintainers decided they shouldn't be doing that for W3C spec, and rely on W3C CSS instead. 15:45:42 .. But that doesn't support class="simple", instead it has class="data". 15:45:45 .. So I fixed that up. 15:46:02 .. The second thing is that Respec and W3C CSS now supports dark mode as well as light mode, 15:46:09 .. and the spec didn't work in dark mode. 15:46:16 .. So I fixed that up as well. 15:47:59 .. It doesn't seem to work in the preview, but it works for me when locally checked out. 15:48:06 .. I think I might need to check that again! 15:48:31 .. Did anyone have a chance to look at this PR? 15:48:35 Andreas: No, not yet 15:48:38 Nigel: OK 15:48:42 SUMMARY: Please review! 15:49:11 Topic: TTML2 ttm:role issues 15:49:32 Nigel: I opened this pull request on TTML2 to clarify the point discussed last call: 15:49:47 -> https://github.com/w3c/ttml2/pull/1273 Metadata attributes apply as well as elements w3c/ttml2#1273 15:50:09 Nigel: That needs a review too. It's quite a simple one. 15:51:05 .. The diff link now works on TTML2 pull requests! 15:51:58 atai has joined #tt 15:52:29 .. I would like us to publish a new CRS or CRD soon, so Atsushi, if you could check how we can do that, it could be helpful. 15:52:48 Atsushi: For a CRS we need a list of changes, can be a list of GitHub Issues and PRs, 15:53:02 .. and then bring them to horizontal reviews - just the deltas, not a full horizontal review. 15:53:16 Nigel: That makes sense. For a CRD we don't need that do we? 15:53:51 Atsushi: For CRD it's quite easy but I don't think there's a tool for streamlined publication - we don't 15:53:58 .. have a toolchain for XML spec editing. 15:54:20 .. E.g. for DAPT we are performing a streamlined publication via echidna for each PR merge. 15:54:31 .. I don't believe we have an automated tool for XML specs. 15:54:51 .. Of course WG can publish CRD at any time, we just need one call for consensus to perform the publication 15:55:12 Nigel: That's exactly what I meant - to look up how we do the non-streamlined publication. 15:55:18 .. The spec build process is easy using ant. 15:55:47 Atsushi: For CRD we can use GitHub Actions, but for others we have to put into CVS and ask systeam to 15:55:59 .. publish as CRD. It's like a handmade streamlined publication. 15:56:14 .. The same resolution could be made one time that works for the life of the specification, 15:56:21 .. but we need a manual procedure to action it. 15:56:31 Nigel: That makes sense. 15:56:48 Atsushi: Like a CfC for streamlining all remaining publications including TTML2, to republish 15:56:53 .. every time a PR is merged. 15:57:04 .. It's not automated but the record of the decision is needed. 15:57:23 Nigel: Thank you 15:57:31 Topic: TPAC 2024 15:57:41 Nigel: Gary did the form, thank you! 15:57:42 Gary: Yes, you're welcome. 15:58:13 Nigel: It's weird to plan 4 months in advance what we want to do on each day. 15:58:29 .. I think we were flexible with our day choices? 15:58:44 Gary: We requested Friday but I marked us as flexible. MediaWG meets on Thursday. 15:58:55 .. The idea is that all our non-joint meetings would be on the same day. 15:59:03 Nigel: And the joint meetings we requested are... 15:59:13 Gary: APA WG, MEIG and ADCG 15:59:31 Nigel: Thanks. We don't think we have any joint topics with MediaWG at the moment. 15:59:48 .. Action on all to request agenda topics, please! 16:00:02 .. Anything else to say about this? 16:00:05 Gary: No 16:00:10 Topic: Meeting close 16:00:28 Nigel: Thanks everyone. let's adjourn, we've hit time! [adjourns meeting] 16:00:39 Atsushi: See you in two weeks 16:00:45 Nigel: Yes, two weeks for our next call. 16:00:50 rrsagent, make minutes 16:00:52 I have made the request to generate https://www.w3.org/2024/05/23-tt-minutes.html nigel 16:09:22 atsushi has joined #tt 16:10:18 scribeOptions: -final -noEmbedDiagnostics 16:10:21 zakim, end meeting 16:10:21 As of this point the attendees have been Nigel, Ewan, Andreas, Atsushi, Gary 16:10:27 RRSAgent, please draft minutes v2 16:10:28 I have made the request to generate https://www.w3.org/2024/05/23-tt-minutes.html Zakim 16:10:34 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:10:34 Zakim has left #tt 16:10:38 rrsagent, excuse us 16:10:38 I see no action items