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 w3c/dapt#232
github: w3c/
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 w3c/dapt#216
github: w3c/
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:
Metadata attributes apply as well as elements w3c/ttml2#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.