{Minutes} TTWG Teleconference 2024-06-06

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


In plain text:

   [1]W3C

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


                Timed Text Working Group Teleconference

06 June 2024

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

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

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

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


Attendees

   Present
          Andreas, Atsushi, Chris_Needham, Cyril, Ewan, Matt,
          Mike, Nigel, Pierre

   Regrets
          Gary

   Chair
          Nigel

   Scribe
          cpn, nigel

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Add section about mapping from TTML to the DAPT
            data model w3c/dapt#216
         2. [8]Required metadata field for earliest SMPTE time
            code to allow conversion between DAPT and ESEF
            w3c/dapt#232
    3. [9]Metadata attributes apply as well as elements
       w3c/ttml2#1273
    4. [10]TPAC 2024
    5. [11]Meeting close

Meeting minutes

  This meeting

   Nigel: Much like last time!
   … DAPT: some stalled work, can we un-stall it?

   ... There's a TTML issue and, from last time, we need to start
   a CfC to publish a CR draft of TTML2
   … The TTML2 PR needs review
   … Draft TPAC schedule has been published
   … AOB?

   (nothing)

  DAPT

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

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


   github: [13]w3c/dapt#216

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


   Nigel: This has been open for ages, and stalled, so need to
   decide what to do
   … I think we've done everything we said we'd do, but needs
   review to confirm that
   … I added another small change, on the table formatting because
   of changes to ReSpec
   … So pragmatically, I applied the new table styling in this PR,
   as well as support for dark mode

   Nigel: Looking at the wording for pruning foreign vocabulary
   and constraints on ttp:contentProfiles values, I didn't think
   that was testable so didn't want an extension feature
   … Happy to hear other opinions
   … Cyril, could you review, or anyone else?
   … I think this is the last significant thing to do before we
   can go to CR. This addresses #110. With #44 we can close with
   no change, and lastly, #75, per-script type restrictions. We
   may have enough

   Cyril: We discussed last time, should we merge "represents"
   with the script type?

   Nigel: That's #227, not marked as must-have. Not sure we have
   an answer yet

   Cyril: If we adopt it, would be a non-backwards compatible
   change, so good to resolve before CR

   Nigel: Have marked it as CR must-have

   Nigel: Please add comments to the issue, to discuss next time

   Cyril: Sure

   SUMMARY: Needs review

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

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


   github: [15]w3c/dapt#232

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


   Nigel: We discussed this last time, I had an action to create a
   PR, but not had time yet
   … It's worth discussing again

   Ewan: A problem I found converting between ESEF and DAPT is
   with timeline references, you need at least one shared timecode
   value in the DAPT
   … the time codes are all relative to the media in DAPT, so
   without the value it's impossible to accurately convert between
   both formats
   … so looked for a value we could share, but didn't find one
   … EBU-TT has a first frame in programme
   … the ESEF format does have field, but it's not implemented in
   a common authoring platform, so files won't have it
   … So add a new metadata field for the first frame of the
   content, which would be common to any exchange format
   … Not clear if it should be in DAPT or drawn from another spec
   like TTML2

   Nigel: There's a compilation process that happens, where the
   input to it, in broadcast workflows, is expressed in SMPTE time
   code
   … used for synchronisation in playout
   … so although we don't have SMPTE timecode in DAPT, if you're
   generating a file with the AD content in it, you need to
   associate the timeline with the SMPTE timecode
   … This common example, where you don't know all the info,
   there's one piece of data missing, this proposal is to add DAPT
   metadata to say where time 0 matches some SMPTE time code
   … So rather than expressing all times in DAPT in SMPTE
   timecode, have one point in time as a cross-reference

   Mike: I wonder if using a timecode that has gaps is a harder
   problem to solve, and if it would be more productive to do in a
   DASH context, where it's broadly understood
   … For timed text we don't permit there to be gaps, e.g., a
   track such as a wave file with DAPT in it, it's not OK to have
   it start/stop, put in a null segment

   Nigel: I'm not sure I understand how that would work. How would
   you generate DASH that knows this. This is before decoding and
   packaging
   … Agree that the audio file has to be continuous
   … It needs to have the same play rate in the media as the
   resulting compiled audio file so you can play them in sync
   … DASH doesn't have SMPTE time code?

   Mike: No, time of day in UTC

   Nigel: If you had an external wrapper for DAPT, you could put
   additional info in it

   Cyril: It should be possible to do a lossless round trip, at
   least
   … even if with external vocabulary

   Nigel: That's the key question, should it be external or
   natively supported in DAPT, as it'll be a common issue and we
   could solve in a common way

   Cyril: How much vocabulary would it pull it, can we add just
   that one attribute?

   Nigel: You can
   … The value in the EBU-TT metadata spec isn't exactly what we
   need, there isn't one that relates exactly to this
   … Document start of programme in #1 but that info isn't
   available in ESEF, so you can't map it, but also can't rely on
   the DAPT media timeline being the start of the programme
   … You don't know where on the programme content timeline where
   that is, as the start of programme timecode is missing
   … so becomes a circular dependency

   Matt: Makes sense to me, there's an offset value in BWAV where
   you can calculate start of programme
   … Hard to have a series of timed events, they always refer to
   another audio file or audio track in another media file, so
   borrowing document start of programme makes sense

   Nigel: That feels like an interesting misuse, as time of first
   description may be a minute into the programme
   … So if you use document start of programme as start of first
   AD...

   Cyril: Introduce an empty DAPT event before the first, then use
   start of programme for that. If we were to use this as a hack,
   the first description in the DAPT document would have the
   correct semantics for start of document?

   Nigel: Don't think you would
   … You don't know how the AD in the file relate to the start of
   the programme in the original media. We lose the relationship
   with the timeline, so need a way to recreate it
   … My goal was to propose some data or metadata to say that time
   0 in the media timeline corresponds to some SMPTE timecode, to
   rebuild the relationship between the timeline

   Matt: Works nicely with how our BWAVs work

   Nigel: We should look at how those two concepts coincide

   Matt: We can use to synchronise without a sidecar XML file

   Pierre: I've seen people get in trouble doing that, the value
   is meaningless outside the context of the timed text file

   Matt: It's in the compiled WAV file, agree it goes wrong if you
   mix and match

   Pierre: Use a playlist, don't hard-code into individual
   components of a playlist, from my experience

   Andreas: How would this be resolved with playlists?

   Pierre: If you have two separate components in a media
   playback, they way to relate their relative offsets is through
   a third object like a playlist
   … Alternative is to have multiplexes, to tightly bind the
   essence components
   … But as soon as they're not tightly bound they get separated,
   reused, so binding by inserting info individually stops working
   IME

   Matt: Challenge here is they come from different suppliers and
   different processes
   … Those suppliers needs some way to have the relationship
   between the timelines

   Pierre: The playlist would do that. Doesn't have to be an
   external file, could be an API

   Nigel: Interesting point, unless they're tightly bound. The AD
   script and the original media are tightly bound, it's a 1:1
   relationship
   … The scenario is more specific, and reliably specific, than
   the general case where you see those problems

   Andreas: I understand both positions. The metadata can be
   meaningless or out of control of how you exchange the AD. So
   it's at the risk of the user to interpret the metadata and
   restrict the workflow
   … I commented on this last time, the timecode of the first
   content in the AD isn't new, it's in EBU STL or EBU subtitles,
   time of first cue
   … If makes sense to add metadata to refer to the zero timecode,
   could also be used for other things, and DAPT could be used for
   other TTML profiles
   … If we use this kind of metadata, good to define in a way that
   refers not only to DAPT

   <Zakim> nigel, you wanted to ask if the "compilation" timecode
   could be provided as an input into the conversion from ESEF to
   DAPT

   Nigel: I want to make another suggestion, don't know how
   feasible it is
   … At the moment, the compilation gives a single continuous
   output media, with a timepoint expressed in timecode. Could
   that be provided as an input in the conversion from ESEF to
   DAPT, provided earlier, so that defines time 0. Then you don't
   need anything in DAPT as that defines the time of the output

   Cyril: This question does seem applicable to more than DAPT,
   should discuss in context of TTML2

   Nigel: We can do that, but I'm try to reframe it to make the
   problem disappear

   Matt: Unless you're producing a BWAV, the WAV has no concept of
   timecode, so descriptions are offset from 0
   … When you want to consume that file downstream, the challenge
   is how does the consumer how it relates to the asset it belongs
   to?

   Pierre: In my mind that's a workflow issue. Whoever is
   producing the wave file needs source material. Can be done in
   different ways, text with a playlist, a web player. There's
   some context that the wave file is part of
   … So the workflow is in charge of making sure those things stay
   synchronsied

   Matt: For us that's a proxy file, which must have the same
   timeline as the target

   Pierre: One way to achieve that is send the proxy and require
   whoever creates the wave file to route it back into the proxy,
   so there's no ambiguity on the relationship between the two.
   Reingest the created audio essence back in to their asset
   management system
   … Then the playlist provides the unambiguous relationship
   between them
   … Or use a web based application that includes the original
   cnotent, the proxy, then it's all done behind the scenes and
   the relationship is preserved by the system

   Nigel: There's a legacy problem here, there's a large number of
   ESEF AD files, exist independently of any workflow or asset
   management system
   … If you have the original media, you can relate them, but you
   may not have access to that when you want to convert to a
   different format
   … That's part of the challenge here
   … So going back to my original question of providing the data
   upfront, you can't because you don't have it
   … If you want to avoid having additional metadata, the
   conversion task has to look it up from somewhere else, and that
   may not be easily accessible

   Ewan: Yes. My feeling is, in the absence of the data to convert
   a script to the DAPT file, you'd have an archive of ESEF files,
   so would extend the life of the ESEF standard. A service
   provider, trading in scripts from other providers using non
   DAPT you may not be able to exchange without that additional
   context

   Nigel: We could express as metadata, and deferred processing,
   rather than making it a fixed offset. Does that tie it too
   closely to a specific process, not generic enough?

   Matt: Our files have a content start time and content end time,
   in the ESEF header
   … Relies on the describer putting the data in
   … But if we have a wav file that doesn't match the duration of
   the content, things go wrong

   Ewan: That's #230

   The compiled wav may extend beyond the content end time
   … Not always possible to populate the value

   SUMMARY: Issue discussed, alternative workflows considered,
   potentially frame as "deferred conversion data" or similar.

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

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


   github: [17]w3c/ttml2#1273

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


   SUMMARY: Review needed

  TPAC 2024

   [18]Draft TPAC 2024 timetable

     [18] https://www.w3.org/2024/05/tpac2024-schedule-20240523.html


   Nigel: TTWG meets on the Friday, joint meeting with APA.
   Overlaps with MEIG Monday joint meeting with MEIG.
   … Joint meeting with ADCG. Schedule looks awkward. Any comments
   or requests?

  Meeting close

   Nigel: Thanks everyone. Apologies for being slightly over time.
   [adjourns meeting]


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

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