{Minutes} TTWG Teleconference 2024-05-23

Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2024/05/23-tt-minutes.html


In plain text:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

23 May 2024

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2024/05/09-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/282

      [4] https://www.w3.org/2024/05/23-tt-irc


Attendees

   Present
          Andreas, Atsushi, Ewan, Gary, Nigel

   Regrets
          Chris Needham, Pierre

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Required metadata field for earliest SMPTE time
            code to allow conversion between DAPT and ESEF
            w3c/dapt#232
         2. [8]Add section about mapping from TTML to the DAPT
            data model w3c/dapt#216
    3. [9]TTML2 ttm:role issues
    4. [10]TPAC 2024
    5. [11]Meeting close

Meeting minutes

  This meeting

   Nigel: Today we have DAPT, TTML2 ttm:role and TPAC
   … Is there any other business or points to make sure we get to
   within those topics?

   no other business

  DAPT

    Required metadata field for earliest SMPTE time code to allow
    conversion between DAPT and ESEF [12]w3c/dapt#232

     [12] https://github.com/w3c/dapt/issues/232


   github: [13]w3c/dapt#232

     [13] https://github.com/w3c/dapt/issues/232


   Ewan: The issue was around conversion between legacy formats
   and DAPT.
   … DAPT is related to media time. The issue I had is, when
   converting from ESEF with explicit SMPTE timecodes,
   … I needed to decode the media time in the DAPT relative to the
   SMPTE timecode.
   … But there isn't a metadata field helping to do the mapping in
   DAPT or TTML2.
   … For some authoring platforms you can't specify the timecode
   of the first frame of the programme,
   … just the timecode of the first description.
   … That's likely the best metadata value to reflect in DAPT to
   use for this conversion activity.

   Nigel: I see this as a problem of relating the DAPT media time
   to the SMPTE timecode of the source media,
   … which you need to do so that, during a thing called
   "compilation", which takes as input a programme timecode
   … for the beginning, and generates a single WAV file the
   duration of the programme,
   … that compilation process can know when, relative to the begin
   time passed in, the DAPT media time begins.

   Andreas: Thanks Ewan for bringing up this case.
   … I understand this as being about the mapping between two
   different time coordinate systems.
   … A source file and maybe a target file in the SMPTE timecode
   space but DAPT is media time,
   … and to get proper conversion you want some metadata either
   telling what the source timecode is,
   … or, for converting to a target file, that uses SMPTE
   timecode. Is that correct?

   Ewan: yes, it's trying to find an anchor that's common between
   both.

   Andreas: Yes, that could be a common use case, but I'm not sure
   if it falls in scope of DAPT, because
   … it is information outside the DAPT document itself.
   … It is tricky because the information is specific to the DAPT
   document.
   … I wonder if it is useful to define some metadata in W3C or
   DAPT, or you could always use any kind
   … of metadata to enable this use case.
   … The overall question is: is this a workflow problem, or do we
   expect it to be a common use case
   … that needs to be supported in different workflows?

   Ewan: Difficult to say, easy for me to speak to my own
   workflows.
   … The most common workflow involving compilation requires the
   presence of the media.
   … You wouldn't have single WAVs and an exchange document. That
   maybe makes it more unusual
   … and less general for me. It's possible that others have the
   same difficulty with the same process.
   … Or they could capture the information externally to the
   exchange document. It's a good question,
   … I'm not sure I can answer it.
   … It's also specific to this conversion use case, between ESEF
   and DAPT.
   … Without this metadata I don't think DAPT can accommodate that
   use case.
   … It feels like that is a use case we can consider - is DAPT a
   clean slate for new workflows?

   Nigel: I'm sympathetic to this use case, partly because I think
   ESEF is one of the de facto "standards"
   … used by a lot of people, and I think creating a pathway for
   migration to DAPT would be very helpful.

   Andreas: It's sort of tunnelling some metadata through the DAPT
   document. I think that it's a use case
   … that's not specific to DAPT, right. It could be for
   conversion against legacy STL files and TTML too.
   … As Nigel said, we have defined this metadata field in the
   EBU, startOfProgramme, which is kind
   … 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.

   Nigel: I thought about this and decided it is close, but not
   the right thing.
   … The trouble is that during the conversion process you may not
   know the start of programme timecode.
   … All you definitely know is the timecode of the first
   description and the media time you're giving that.
   … If you happen to know the start of programme timecode you
   could use it for this, but it would have to
   … come from some other source.

   Ewan: The legacy format does have some theoretical provision
   for start of programme, but it wasn't ever implemented,
   … which is frustrating.

   Andreas: In EBU STL we have two different metadata fields, one
   is startOfProgramme, and the other,
   … that relates to the timecode of the first description, would
   be the first Timecode In cue (TCI).
   … I think we have not defined that in EBU-TT, I'm not sure.
   … Ewan, you're saying you want both, the start of programme
   timecode and the timecode of the first description,
   … because it depends on the platform, which is available.

   Ewan: Yes I think so.

   Nigel: My experience of conversion workflows is that the more
   standalone they are the better,
   … because if you have to start introducing other data from
   other sources that introduces the potential for errors.
   … the other thing I thought about with this is if this use case
   is an argument for allowing SMPTE timecodes
   … in DAPT, but I think it's better to have a cross-reference
   data point in the document that relates
   … the media time to some other external SMPTE timecode than to
   suffer the implementation difficulties
   … that others have had with SMPTE timecode in TTML, in terms of
   getting correct implementation of
   … dropMode, frameRate etc, where interoperability has been a
   problem.

   Andreas: Maybe you can explain a bit what you mean about a
   cross reference data point?
   … Still I'm wondering if I have understood the full impact -
   why should this be specific to DAPT and could
   … not be something that also relates to other data in TTML?

   Nigel: What I mean is some metadata that relates a fixed point
   in the media timeline with a fixed point
   … in the alternate SMPTE timecode timeline, e.g. media time
   zero = 10:00:00:00 SMPTE.
   … Exactly one value would be present if the mapping is needed.
   … Or no values if not.
   … It may well be a problem for other uses of TTML, but it
   hasn't been as presented as one,
   … with such a clear use case, so far.

   Andreas: OK, what you propose is to map a DAPT media time to a
   SMPTE timecode timeline?

   Nigel: Yes

   Andreas: That's quite a generic solution, definitely, but if we
   have two data points, like in STL,
   … one for start of programme, the other the timecode of the
   first description or first frame of content,
   … would that also work? What would be a blocker for that
   solution?

   Nigel: You could do that, I just think if everyone is using the
   same media time reference point, that's
   … halved the likelihood of different implementations.

   Andreas: I see your point, maybe we need to see what others
   think.
   … What Ewan described seems to be a well understood in the
   world where this solution is being used.
   … It could be that people building these solutions have
   something already known and implemented.
   … I agree your solution is the cleaner way, and from a
   structure point of view, maybe a better fit.
   … I'm not sure if its easier.

   Nigel: Interesting question.
   … Thinking about next steps, I wonder if it's worth opening a
   pull request for this.
   … It could even be an "at risk" feature. I think the idea of
   this solution is that it allows flexibility but
   … is pragmatic for anyone coming from usage of this legacy
   format.
   … Andreas, were you hinting that the best place to define this
   metadata is not DAPT, but somewhere else?

   Andreas: Yes, I was wondering where it should go instead. I saw
   that this kind of metadata could apply
   … to other use cases. Then you open it up for a different kind
   of content.

   Nigel: I'm taking this as implementation feedback, because it
   came about during Ewan's attempts to implement DAPT.
   … That's very strong.
   … I'd be happy to open a pull request to propose something,
   even if we say it's "at risk", and then
   … get more review on that.
   … Any other thoughts on this?

   SUMMARY: @nigelmegitt to open a pull request to propose a
   DAPT-specific solution

    Add section about mapping from TTML to the DAPT data model
    [14]w3c/dapt#216

     [14] https://github.com/w3c/dapt/issues/216


   github: [15]w3c/dapt#216

     [15] https://github.com/w3c/dapt/pull/216


   Nigel: Status update on this.
   … So far no reviews since the most recent discussions and
   changes to the pull request.
   … I completed the extension feature work.
   … I'd appreciate people's views on whether my assessment of the
   normative statements that we make
   … into extension features is right.
   … I also ran into a breaking change in Respec.
   … Two things: first, the "simple" class on tables used to be
   implemented directly by Respec,
   … and the maintainers decided they shouldn't be doing that for
   W3C spec, and rely on W3C CSS instead.
   … But that doesn't support class="simple", instead it has
   class="data".
   … So I fixed that up.
   … The second thing is that Respec and W3C CSS now supports dark
   mode as well as light mode,
   … and the spec didn't work in dark mode.
   … So I fixed that up as well.
   … It doesn't seem to work in the preview, but it works for me
   when locally checked out.
   … I think I might need to check that again!
   … Did anyone have a chance to look at this PR?

   Andreas: No, not yet

   Nigel: OK

   SUMMARY: Please review!

  TTML2 ttm:role issues

   Nigel: I opened this pull request on TTML2 to clarify the point
   discussed last call:

   [16]Metadata attributes apply as well as elements
   w3c/ttml2#1273

     [16] https://github.com/w3c/ttml2/pull/1273


   Nigel: That needs a review too. It's quite a simple one.
   … The diff link now works on TTML2 pull requests!
   … 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.

   Atsushi: For a CRS we need a list of changes, can be a list of
   GitHub Issues and PRs,
   … and then bring them to horizontal reviews - just the deltas,
   not a full horizontal review.

   Nigel: That makes sense. For a CRD we don't need that do we?

   Atsushi: For CRD it's quite easy but I don't think there's a
   tool for streamlined publication - we don't
   … have a toolchain for XML spec editing.
   … E.g. for DAPT we are performing a streamlined publication via
   echidna for each PR merge.
   … I don't believe we have an automated tool for XML specs.
   … Of course WG can publish CRD at any time, we just need one
   call for consensus to perform the publication

   Nigel: That's exactly what I meant - to look up how we do the
   non-streamlined publication.
   … The spec build process is easy using ant.

   Atsushi: For CRD we can use GitHub Actions, but for others we
   have to put into CVS and ask systeam to
   … publish as CRD. It's like a handmade streamlined publication.
   … The same resolution could be made one time that works for the
   life of the specification,
   … but we need a manual procedure to action it.

   Nigel: That makes sense.

   Atsushi: Like a CfC for streamlining all remaining publications
   including TTML2, to republish
   … every time a PR is merged.
   … It's not automated but the record of the decision is needed.

   Nigel: Thank you

  TPAC 2024

   Nigel: Gary did the form, thank you!

   Gary: Yes, you're welcome.

   Nigel: It's weird to plan 4 months in advance what we want to
   do on each day.
   … I think we were flexible with our day choices?

   Gary: We requested Friday but I marked us as flexible. MediaWG
   meets on Thursday.
   … The idea is that all our non-joint meetings would be on the
   same day.

   Nigel: And the joint meetings we requested are...

   Gary: APA WG, MEIG and ADCG

   Nigel: Thanks. We don't think we have any joint topics with
   MediaWG at the moment.
   … Action on all to request agenda topics, please!
   … Anything else to say about this?

   Gary: No

  Meeting close

   Nigel: Thanks everyone. let's adjourn, we've hit time!
   [adjourns meeting]

   Atsushi: See you in two weeks

   Nigel: Yes, two weeks for our next call.


    Minutes manually created (not a transcript), formatted by
    [17]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

     [17] https://w3c.github.io/scribe2/scribedoc.html