Meeting minutes
This meeting
Nigel: Topics for today: news on the charter, status update and issues on DAPT, also IMSC-HRM to understand the state
… We may be ready to think about CR exit criteria
… Also proposal from Apple to add to WebVTT metadata for strobing in video
… TPAC 2023 planning, but may not get to that today
… Anything else to cover?
Chris: I'd like to cover TPAC, but not urgent
Charter
Nigel: The Council has concluded and written a report, but needs Atsushi to talk about it
… Next step is some need to validate the updated charter with everyone who commented. Plan is to have a 1 month extension, so the new charter would start on 1 May
[Atsushi arrives]
Atsushi: The FO Council report is out, we need to ask every reviewer to check the final version for a 1 week period, starting today
… It should be settled by next Thurdsay. I hope to get management approval in a week or so, so the new charter could be installed by mid April, I believe
… We have a 1 month extension approved, so if we don't want a gap, we can start the extension tomorrow
Nigel: Yes please
… Can I post a link to the Council report?
W3C Council Report on the FOs against the TTWG Charter
Atsushi: It's public, I got approval to send to AC reviews, so I think it's OK to post here
Nigel: I expected an announcement
… Can we set the charter end date to start date + 2 years?
Atsushi: Yes. If you want 2 weeks spare, you can extend to end of April and start on 1 May, not sure if that would work
Nigel: I'm neutral on that. Any other views?
Atsushi: Not sure 2 weeks makes a difference for the review
Nigel: I think the charter has had plenty of review time
… Anything else on the charter?
Nigel: On the report, I've proposed a couple of changes to Florian. Not sure what will happen with those, some were editorial, others more formal
… For example, it says we didn't accept the proposed changes in full, which I think we did
… But this shouldn't hold up the charter
Chris: I also sent you a comment directly
Nigel: OK, will feed that back to Florian too
DAPT
Nigel: Last time Cyril and I did an issue triage we identified some to be resolved before FPWD
… The editorial ones have been done, needs an editorial pass, but the document is now feature complete
… Cyril generated some more issues. Thank you Andreas for your input
… I want to identify which issues we think need to be resolved for FPWD, if any, and label them
Cyril: Do we think there are any? I don't think so, personally
… What's the expectation for FPWD? It doesn't need to be stable
Nigel: It's there to invite review from the group
Cyril: Would it trigger any communication from W3C?
Nigel: There'll be an announcement, and we could write a blog post
<atsushi> example for IMSC-HRM
Chris: Also a patent exclusion opportunity, so worth getting in the features if they have patent implications
Andreas: I found some issues that I may open. Should I do that now or wait until it's published as FPWD?
Nigel: I prefer not to wait
Cyril: I agree
… Are those blockers for FPWD?
Andreas: I don't think so
Nigel: For the issues recently looked at, one is more structurally substantive than the others, about changing script types
… So we have a workflow script type and a separate application script type, dubbing or AD
… Feels useful to do that sooner than later.
Cyril: I think you're right, but do we have agreement?
Nigel: There seems to be agreement from those who commented
… I'll label it as FPWD and assign to you
… Issue #75
Cyril: Also worth discussing the SSML integration w3c/dapt#121
Clarify how to use SSML with DAPT
Cyril: Reviewing the AD part of the spec with colleagues, we have TTML attributes that seem overlapping with SSML
… So what's the relationship? Can we use these attributes or the SSML equivalent syntax or not?
… Proprietary data, not in DAPT or TTML namespaces. Extending that example with SSML could be interesting
Nigel: Yes, definitely. We have to decide on the direction here. Thinking about how TTML2 deals with styling, a lot is imported from CSS
… Defined in TTML2 using styling vocabulary unique to TTML2
… Audio styling attributes: pitch and speak, are both based on SSML semantics based on the prosody element
… What we found with TTML2 and CSS, is there's friction. We could say in TTML2 we won't add more SSML attributes, but do it by injecting SSML into the document
… That would mean defining precedence rules between two audio attributes. I think that would allow unlimited addition of SSML content
… Not sure if it can all be done in attributes, but think so
… Other direction is to define equivalent vocabulary in TTML2 for everything you may want to use in SSML
Cyril: Please no
Nigel: It's a choice we have, so prefer the first option
Cyril: A third option could be to say not use the TTML2 attributes and only SSML syntax
Nigel: If we do that, we would need to adopt the special URI that's defined for the audio source attribute
… ttml/resource/#speech
… (reads definition)
Nigel: It could work, but I think it needs some research on the structure and how you'd inject SSML
Cyril: Don't have a strong opinion, just considering options. Needs more study
Nigel: It's an obvious form of extension that people may want to use
… So propose not doing that before FPWD
Cyril: We can add an issue to the spec to say that's the direction, and get industry feedback
Nigel: I'll add an issue to do that, assign to myself
Cyril: Another issue to discuss is time expressions and associated restrictions
… It's related to IMSC
… How much of a problem has it been to allow the time syntax that looks like a SMPTE time code but isn't one
-> w3c/dapt#123 Consider restricting time expressions
<Github> w3c/
Pierre: It's a recurring issue, I get questions about it
Cyril: Consider restricting time expressions so there's no confusion possible
Pierre: Absolutely. If the only option is time based media, that's a very good idea
… People will still be confused, but there'll be a simple answer
Andreas: I agree
Nigel: I don't think I object, but have a concern it may be against current industry practice in authoring in some way
… The change may be sensible, but people may not want to
Pierre: People create files that pass validation but don't behave as the author intended
… Use case is authoring house gets a proxy with SMPTE time code burned in, they create an IMSC file with expressions that match the SMPTE time code
… The time expressions in the TTML file then don't work down the line
… Hard to explain to people why that happens. Easier to explain if it's not supported in IMSC
… It's a common work flow
Cyril: Pierre and Andreas, please comment on the issue
Nigel: Other open issues recently commented on. Nothing obvious to look at before FPWD
Cyril: EBU TTML source media identifier
… Issue 122
<Github> w3c/
Cyril: I was surprised there's no way to provide a link to the source media document
Nigel: There's a defined element in EBU TTML for this
… Do we need to add something normative to the spec, or recommend a schema to use?
Cyril: I'd like to have something in the spec, to avoid the burden of having to refer to another spec
Nigel: Could be an example that shows the element and namespace name is all that you'd need
… But do we need to be specific on how to do it, or point to options that are available and allow people to define their own
Cyril: Let's start by saying here's one way to do it, see how people react
… But not blocking FPWD
Nigel: Please look at the ED as it exists now. I'd like to start a CfC to publish as FPWD
PROPOSAL: Publish DAPT FPWD based on ED and any editorial changes made in the next 2 weeks
Nigel: Any objections?
<atsushi> +1
Cyril: I support it
Andreas: I support it
RESOLUTION: Publish DAPT FPWD based on ED and any editorial changes made in the next 2 weeks
Nigel: There'll be a 2 week decision review period
Nigel: Anything else on this topic?
(nothing)
IMSC HRM
Nigel: No issues to be addressed before CR. We're waiting on the TAG review
… The TAG milestone suggests they hope to look at it this week
… We also need to look at CR exit criteria. Pierre, any proposals?
Pierre: We did that a while back
Draft exit criteria at w3c/imsc-hrm#59
Pierre: Not finished, but the framework is there. We need to finish the tests and invite getting the content. There's a wiki page also
Nigel: For CR exit criteria, the proposal is in #59
… Please raise any concerns in the PR
Pierre: All we need to agree now is the exit criteria, then we can fill in the actual tests during the CR exit period
… So I'll clean up the CR branch and then we can send for review
Nigel: I think what this says matches, or goes beyond the charter requirements, so we should be fine
… There's specific text about IMSC HRM in the Council report, recommend looking at that
… They explicitly suggest that two validating implementations would be a good way to demonstrate interop
Pierre: Yes, more is better, but not necessary
w3c/webvtt#512 Proposal from Apple about a WebVTT metadata format for describing when flashing and strobing lights occur in video.
<Github> w3c/
Gary: Two issues, the main one here is about Apple proposing a specific metadata format
… for WebVTT to describe when media has strobing or flashing lights so that players or whatever
… could handle it in some way such as dimming the screen or switching to an alternate video for that section.
… My main thought is that it probably shouldn't be in WebVTT itself, such a format.
… Maybe another spec, or something else. I don't know what are all the deliverables available for something like this.
… Also maybe, I didn't invite him for today but it might be worth inviting them to a future call.
Nigel: Reminder that they are members - they might just need advance notice of the agenda item
Gary: Yes. That's what I mean.
Chris: There is the issue of a constraint about VTT metadata format, which Gary and I both have
… responded to say it risks breaking existing implementations that use other formats.
… We're asking if there's some other way to signal the metadata format used in the VTT metadata fields.
… It's open to suggestions about what might be possible.
… The other part is where such attributes or metadata schema should be specified.
… Strobing is a pretty small feature in itself. Are there other use cases that would warrant,
… e.g. a video metadata specification?
… This feels to me like what we have with WebVMT where it's a separate application
… that extends WebVTT. An alternative approach to adding into WebVTT itself.
Pierre: Wholeheartedly agree.
Chris: Not sure if this has a relationship to DataCue
Pierre: My interpretation is that WebVTT cues are the only way to synchronise with the video element,
… so people are using it for everything.
Gary: Yes
Chris: So having an API more tailored to metadata?
Pierre: Yes exactly
Chris: I'll respond and ask about that
Pierre: Maybe now the time is right to have that discussion, to figure out how to synchronise metadata
… with the video element.
Gary: That makes me think maybe one of the related enhancements is on the Cue object, some
… format like JSON that can be automatically parsed, for use as metadata.
Chris: Good thought, I'll capture that.
… Probably on DataCue if we want to encourage use of that rather than VTTCue. But that's a separate discussion.
Gary: Yes
TPAC 2023
Nigel: We need to decide by 8 May. IBC is adjacent to TPAC. If anyone knows they'll attend or know they can't, please let me know
… Or if you have agenda topics
Pierre: Agree
Chris: I expect to be there
Gary: I will likely not be there in person. But is also overlaps the Jewish new year
Nigel: Strange decision, first time that's happened in my 10+ years with W3C.
Meeting close
Nigel: Thanks everyone, we packed a lot in today. See you in 2 weeks. [adjourns meeting]