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 w3c/dapt#216
github: w3c/
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 w3c/dapt#232
github: w3c/
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 w3c/ttml2#1273
github: w3c/
SUMMARY: Review needed
TPAC 2024
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]