{Minutes} TTWG Teleconference 2023-04-27

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


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

27 April 2023

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

      [2] https://www.w3.org/2023/04/13-tt-minutes.html

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

      [4] https://www.w3.org/2023/04/27-tt-irc


Attendees

   Present
          Andreas, Chris_Flick, Chris_Needham, Cyril, Eric,
          Eryk_Vershen, Gary, James, Nigel, Pierre

   Regrets
          Atsushi

   Chair
          Gary, Nigel

   Scribe
          Chris_Needham, cpn, nigel

Contents

    1. [5]This Meeting
    2. [6]DAPT
    3. [7]IMSC HRM
    4. [8]WebVTT issue 512
    5. [9]TPAC 2023 planning
    6. [10]Meeting close

Meeting minutes

  This Meeting

   Nigel: On the agenda today we have DAPT, IMSC-HRM CR,
   … [11]WebVTT#512 (metadata)
   … and TPAC 2023 planning
   … Any other business or things to make sure we cover?

     [11] https://github.com/w3c/WebVTT/issues/512


   no other business

   Nigel: Anyone want to switch the order around?

   no order changes

  DAPT

   Nigel: We published FPWD, thank you everyone

   [12]FPWD

     [12] https://www.w3.org/TR/2023/WD-dapt-20230425/


   [13]W3C Blog post

     [13] https://www.w3.org/blog/news/archives/9896


   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: [14]w3c/webvtt#512

     [14] https://github.com/w3c/webvtt/issues/512


   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 [15]apple/VideoFlashingReduction

     [15] https://github.com/apple/VideoFlashingReduction/


   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> [16]https://developer.apple.com/

   accessibility/#whats-new

     [16] https://developer.apple.com/accessibility/#whats-new


   [17]Apple Accessibility What's New Page

     [17] https://developer.apple.com/accessibility/#whats-new


   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]


    Minutes manually created (not a transcript), formatted by
   [18]scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).

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