Meeting minutes
This Meeting
Nigel: On the agenda today we have DAPT, IMSC-HRM CR,
… WebVTT#512 (metadata)
… and TPAC 2023 planning
… Any other business or things to make sure we cover?
no other business
Nigel: Anyone want to switch the order around?
no order changes
DAPT
Nigel: We published FPWD, thank you everyone
Nigel: Some open issues to address
… Atsushi is setting up auto-publication
… We'll need to request horizontal and wide review, and address any comments
… Shall I rebase open pull requests?
Cyril: Feel free to do it now, or I can next week
Nigel: Anything else to say on DAPT?
IMSC HRM
Nigel: TAG review has been open a long time. I messaged Amy and Hadley to find out what's happening
… We also need to sort out CR exit criteria. I proposed a change, want to make sure we think about it properly, given the charter changes
… [reads current text]
… I think one of each should be enough, without needing two of one
… Either one content-producing implementation and one validating implementation or two validating implementations
Pierre: I think that's a reasonable change
Nigel: So let's go with that, in absence of TAG review
Pierre: I'd like to get a date for CR
Nigel: I suggested 8 weeks after publication
Pierre: As soon as we agree to publish, someone will modify it to reflect the actual publication date
Nigel: A feature request for respec to specify relative dates? I might suggest that!
… Anything else on IMSC HRM?
Pierre: Should I ask Atsushi to pick a publication date, do we need a CfC?
Nigel: We will, but nervous about doing that without TAG review, as they're a horizontal review group
Pierre: They had comments, suggesting to make it a note
Nigel: I disagreed with that, then discussion stopped
Gary: They asked for clarification on what specifically needed review
Nigel: I replied to that in the issue
Gary: On making it a note is more of a personal thought than a TAG consensus
Nigel: I think so
Pierre: What's the right process? We can demonstrate review, let's say we're about to go to CR, set a date for them to do something
Nigel: This discussion is enough for me to go back to TAG, to say we're being held up
Pierre: Having a date makes it more concrete
Nigel: May 16?
Pierre: Sounds good
Nigel: Any more on this topic?
(nothing)
WebVTT issue 512
github: w3c/
James: There seems to be a negative response to #511, so should we close that?
… This is on the ambiguity of metadata, and there being no path to know
… if it is metadata or a caption.
… I suggested either a JSON block or a URI, but others are using other types of metadata
… so it is not always clear
Chris_Needham: I'm wondering what other alternative options for signalling the format we could think of.
Gary: I suggested a Metadata block akin to the Region block, should be backwards compatible.
… I haven't tested that, but generally WebVTT says to ignore stuff you don't know about.
… My main concern is backwards compat
… General idea of having an in-file signal for the type of file is a valid request
James: OK, I'll leave that one open and Eric and I will look into it more.
Gary: Do you want to give an overview of this proposal?
James: Sure. [shares screen showing issue]
… A few weeks ago Apple released the ability for Apple hardware devices like a Mac, AppleTV or iOS device
… to automatically dim the screen by looking a few frames ahead at the flash patterns.
… We released an open source library for this on GitHub as well.
… The idea is to help anyone who has a negative reaction to the flashing,
… as an alternative to only having a content warning.
… We'd like to timecode where the flashing is.
… We have an HLS proposal that Eryk V worked on. More information about that soon.
… We would ideally like a way to specify the algorithm optionally.
… In my VTT proposal it just says "level" without defining what that means.
… If we were to include a test-uri and a test-version we could specify unambiguously what that level meant.
… We could do a number of things with this, most obviously adjusting the timeline in some degree.
… Like skipping over the flashes.
… Thank you all who contributed to the discussion.
… It seems like the general consensus is to not use WebVTT for this.
… I'm not as familiar with WebVMT - Eric might want to add more context.
… Happy to try to answer any more questions.
… I know there were some HLS questions in the channel that haven't been answered yet.
Chris_Needham: WebVTT in terms of metadata is completely generic, and does not define any semantics
… about metadata. WebVMT is an example for synchronising location and orientation data with video media.
… It's a standalone specification that builds on top of WebVTT,
… and defines the JSON object carried in the VTT file and its semantic.
… The approach is to define it in its own specification as an application
… rather than being in the WebVTT spec itself.
Gary: Yes, WebVMT also is a bit of a fork because it adds extra features to WebVTT.
… If we go that route this metadata format would be simpler because it would not need
… to redefine what WebVTT already defines, it would point to them directly.
Gary: I was asking about how it would be represented in HLS.
… How do you put it in the manifest, and how do you represent it in the TextTracks object.
Eryk: We use the DATERANGE tag in HLS. For conveying this data we have a specific class
… and an added attribute that denotes the risk.
… That's it, in the multi-variant playlist.
James: And the class mentioned is more or less the same as the type value.
Eryk: Yes, it's a little more verbose.
Gary: So the HLS wouldn't be a segmented version of this WebVTT?
James: It's different.
Gary: That sounds fine.
James: The similarity is the timecode and the level - the type would be equivalent but not the same.
… We chose that because general flash, red flash, and spatial pattern definitions are common in WCAG so we could expand
… it to that pattern.
Gary: It's exposed how HLS and Safari expose DATERANGE on the video element?
Eric: We expose DATERANGE as a data cue
Gary: That answers my questions.
Nigel: Is this an Apple only feature, are other implementers interested?
James: We hope others will be interested, users seem to be excited about it, so we'd like to have other platforms benefit from the idea
… And we'd like to enable it for Apple's services on other platforms, Android apps and TV+ content for Samsung TVs etc
Eryk: We'll be publishing it at the developers conference
Nigel: I'm supportive of the idea it should be a separate spec. A good approach could be to draft a spec for this, and try to get support
… Consider whether it's a Rec track document or a Note
James: I'd defer to Eric or any of you on that
Eric: Not sure there's a benefit to it being on the Rec track, it's more work, and may not be a benefit to anyone else
Nigel: There's a lower bar for publishing a Note
… A Note isn't normative, it doesn't carry any imprimatur of W3C as a whole, it's a document that people may find useful
… We've used it for things that look normative, but things useful for industry more than things that are a recommendation
??? maybe ChristopherF?: Would a Note be a link to an external document?
Chris_Needham: A Note is its own document rather than a note within a different document.
James: Yes. It's a W3C Document type
Gary: You can't reference a Note normatively from a Rec
Nigel: The status of the document on a Note will say nobody should reference it normatively.
Andreas: That's definitely a good activity that I would support.
… More generic question. We're discussing the syntax and the transport container.
… Is there any more thought about a generic semantic model
… that could be used for other formats.
… Is the model already there? Or would it be useful to define it in a way that
… could be used in other syntaxes or containers?
Gary: Like in IMSC?
Andreas: Yes
Eric: Do you mean specifically this kind of metadata or more generically to define a way to be able
… to have other types of metadata in a VTT file?
Andreas: This specific flashing metadata
James: I'm not sure I fully understood that
… We can dig into that
Andreas: It's independent of format, it's just a thought that this kind of information
… would be structured specifically somewhere so it could be used regardless of format.
… The semantics and expected behaviour could be similar.
James: The data itself is not so complex that it would be difficult to do that transformation into other formats.
… We're using it a different way in HLS.
… I'm not opposed to a reusable structured format, that e.g. MPEG DASH could choose to implement,
… using a format that this group defines, say, but I would not want a requirement to have a pass-through
… format that would need to be supported. If we did want that we would need a Rec track document.
… But a JSON block that can be used elsewhere, I'm all for that.
Eric: Or is the suggestion more to have a document that defines a value range, the elements of the metadata
… so that in this case we could use it in JSON form, but it could also be used in XML form, pointing
… back to a document that defines how to interpret them.
Andreas: Yes, thank you that's exactly what I had in mind.
James: Seems reasonable to me. I don't think value should be defined in the transfer format
… because it will be different depending on the algorithm that's used.
… we think Apple's general flash algorithm outperforms Harding in some specific ways.
… I could see there being multiple tracks, one using Harding, one the Apple open source algorithm,
… another some other algorithm.
… Though perhaps it's unlikely that a media publisher would want to support all three for and specific video. [Update: more likely when it is fully automated.]
… The algorithm would define it, not the transport format.
Eric: Do we have a document that defines these things for our new algorithm?
Eric: If we do write up a Note or a Rec track document I don't think it needs to mention WebVMT.
… It is just another type of metadata track.
<jcraig> OSS project apple/
James: Posting some links here. The above is an algorithm.
… There are also ePubs and PDFs that explain more, the first two links on the Whats New page:
<jcraig> https://
Apple Accessibility What's New Page
James: The ePub embeds a video.
Chris_Needham: Coming back to the Note/Rec track question.
… If this does become something more widely adopted across implementations,
<jcraig> Those are also linked in Issue 512
Chris_Needham: is there anything that prevents a Note from being promoted to the Rec track?
… Once there are multiple implementations you would want the benefits of a Rec track.
James: I can't think of anything that would prevent us from promoting a Note to a Rec
Nigel: Are there any IPR considerations here?
James: Good question, I will have to get back to you on that one.
… We did an IPR review before I posted this issue and the algorithm and open source project.
… If it were within the TTWG I think it would be covered by the W3C patent policy, but I will take a note to follow up internally.
Pierre: Whatever is submitted to this group (by members) is subject to the IPR policy.
… There's an exclusion that starts with the FPWD.
… I've never heard that publishing a Note relaxes the constraints for a Rec track.
… At a high level, a WG Note is a WG decision, really. The consensus body and review will be a lot
… narrower than for a Rec track document.
… You'll get much less attention, and there will be a lot less overhead.
… We talked about IPR. Typically, what I've mostly seen in Notes is application of existing standards
… Something with its own applications, process and technology is typically better as a Rec track document.
… I don't have a strong opinion, just trying to answer the question.
James: Maybe the alternative is to take this as an incubator and not decide on Note or Rec track until
… later in the process.
… We can publish in WICG and bring into TTWG if that's the appropriate place for it to land.
Pierre: That's true too.
Nigel: WICG isn't the only place to incubate, can do in WG or another CG
… We have a broad charter in terms of applications of timed text
James: Easier for us to participate where other organisations have joined already
Nigel: Publishing a Note in a WG is a bit like an incubation
James: My typical process in WICG is write in a wiki page, hence a reason to prefer that. The other benefit is you get people who are just interested in the one topic, which helps with organising meetings
Nigel: Any final thoughts on this topic?
James: Thank you all
SUMMARY: Apple to think about next steps for incubation
TPAC 2023 planning
Gary: I did not submit the questionnaire yet. We have some time.
… My main question is: we want to do the joint meetings with MEIG and MediaWG.
… How much time do we want for TTWG itself?
… I think we're probably more constrained because of the overlap with IBC.
Nigel: I would propose we allocate no more than 1 day for TTWG, which
… could include joint meetings, and try to be efficient in the time that we get.
… We normally go for 2 days but that's difficult for some.
Chris_Needham: Would you want one joint meeting with MEIG and MediaWG or two separate joint meetings?
Gary: I'm not sure. One of the agenda topics we're thinking about is the TextTrack API, so having
… the Media WG would be worth it there.
Nigel: Works for me.
Chris_Needham: Sounds good. For MEIG I'm proposing we do a morning, and then have
… agenda time allocated within that block.
… I'm concerned that we request enough timeslots in the overall schedule so
… the MediaWG joint meeting can be a dedicated session. Then if needed we can have time in the MEIG
… session for any TTWG relevant agenda topics.
Meeting close
Nigel: We're out of time for today. Thanks everyone, next call in 2 weeks.
… Thanks to those who attend less often but came today - you're always welcome.
… [adjourns meeting]