{Minutes} TTWG Meeting 2022-06-09

Thanks all for attending today's TTWG meeting. Minutes can be found in HTML
format at https://www.w3.org/2022/06/23-tt-minutes.html

In text format:
   [1]W3C

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

                Timed Text Working Group Teleconference

23 June 2022

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

      [2] https://www.w3.org/2022/06/09-tt-minutes.html
      [3] https://github.com/w3c/ttwg/issues/220
      [4] https://www.w3.org/2022/06/23-tt-irc

Attendees

   Present
          Andreas, Atushi, Cyricl, Hewson, Pierre

   Regrets
          Nigel

   Chair
          Gary

   Scribe
          Gary, gkatsev

Contents

    1. [5]This meeting
    2. [6]TPAC update
    3. [7]DAPT
    4. [8]Rechartering status update
    5. [9]Timed Text in Low Latency Streaming applications
    6. [10]Meeting Close

Meeting minutes

  This meeting

   gkatsev: TPAC update
   … there's some time for DAPT as well
   … Rechartering status update
   … Timed Text in Low Latency Streaming applications
   … Behavior with controls
   … Are there any AOB items?

  TPAC update

   gkatsev: We have time scheduled Thursday and Friday mornings
   local time
   … 8-10am joint meeting with MEIG
   … 10:30-12:30 for just the TTWG
   … Friday, 8-13:30 joint meeting between TTWG and the Media WG

   cyril: are the events only in the morning?

   gkatsev: yeah, basically, our scheduled time is only in the
   morning to be inclusive of people who may not be in person
   … but there's other meetings in the after noon as well so that
   there isn't overlap, like the Media WG

   atai: as it stands right now, Atushi and me will not be able to
   be in person
   … I will definitely join the morning sessions
   … You should make as best usage of the time in person

   gkatsev: we want to make sure we didn't overlap with other
   groups
   … and we did it Thursday and Friday to make sure that folks
   that are at IBC beforehand can still make the meeting in person

  DAPT

   gkatsev: I saw that Cyril's PR first version PR got merged

   cyril: the PR was merged to make it easier to review
   … Nigel and Andreas opened several issues
   … Didn't have much time to review them beforehand
   … They appear very relevant
   … I will work on preparing pull requests to address those
   … There is one question (#5) about relationship about profile
   and IMSC
   … It's a valid question
   … Leaning towards DAPT being based on IMSC 1.1

   [11]Is the basis for DAPT IMSC 1.1 or is it an independent spec
   with common provisions?

     [11] https://github.com/w3c/dapt/issues/5

   cyril: Using IMSC 1.1 as a basis seems like a good start

  Rechartering status update

   gkatsev: Our charter is expiring at the end of the month
   … I'll make sure to talk catch up with Nigel on this

   Pierre: no further thoughts
   … my opinion is still the same
   … If we don't solve it now, we'll need to solve it later
   … The longer we wait the more dramatic it'll be

   atai: this PR could be accepted but it'll just delay things

   Pierre: my preference would be to solve it now
   … It's a big discussion and goes to the heart of should
   charters be able to override the process
   … I think it's an absolute bad idea, but in this specific case
   … the industry doesn't benefit from having two HRM
   implementations
   … It's bad because the charter is overriding the process and
   it's bad for this specific case

   atsushi: Several issues are open in the process CG

   <atsushi> [12]https://github.com/w3c/w3process/issues/167

     [12] https://github.com/w3c/w3process/issues/167

   atsushi: This issue targets Process 2022 version
   … Though, it's only a target
   … I'll ask to make sure it's in focus this year

   gkatsev: we should decide whether we want to merge the PR in or
   continue getting charter extensions

   Pierre: I don't want two implementations for this case
   … I don't expect a second implementation, there's no need for
   one, I think
   … if this project is going to be stopped when we'll get to PR,
   we should stop now
   … or be willing to be in CR forever
   … I don't think we should go forward expecting a second
   implementation

   gkatsev: especially with how this statement is, we can make the
   case for this implementation

   Pierre: we could as a group make a statement that we would
   welcome a second implementation but we don't expect one
   … and that we expect it to be validated via testing and
   independant content

   atai: So, this should mean that this isn't a hard requirement,
   for a second requirement
   … but might come up in the AC review
   … Maybe a compromise is to explicitly mention the HRM as an
   exception

   gkatsev: definitely a possibility, if HRM is the main issue
   with the two implemention SHOULD statement

   Pierre: would be awkward but definitely would work
   … The definition of compromise

   gkatsev: yeah, I think it's reasonable to ask whether this is a
   valid option

  Timed Text in Low Latency Streaming applications

   atai: I've got something to add for LL DASH
   … we definitely need to come back to a meeting with Mike Dolan
   and Nigel
   … Monday was a DASHjs user meeting and I attended
   … Brought up the issue we were discussing
   … From their view, they didn't see an issue
   … They were convinced it was possible to chunk ttml where you
   repeat pieces
   … They were open to collaborate on a demo case that could be
   highlighted on the DASHjs page
   … Would need an issue filed against DASHjs
   … And test materical
   … That was their official statement
   … But they don't see a need to change any specs
   … Also had a discussions with a main contributor who worked on
   a lot of subtitles
   … In Part 30 there's a limitation to only 1 document per
   fragment
   … You could have more fragements per segment
   … You could use short fragments as chunks
   … There's been also willingness on collaborating on testing and
   demos
   … The best way forward would be to collaborate with them and
   see if there's really an issue

   gkatsev: is it per fragment or per mdat with multiple mdats?

   cyrcil: I took a look since I was confused
   … it says "when resources are stored in a sample, the track
   fragment box should contain
   … entry count
   … should be set to 1, since each should contain subtitle"
   … You can still have multiple track fragments, but it's worth
   looking at, thanks

   gkatsev: yeah, I think it would be great to work with them and
   figure out the limitations

  Meeting Close

   gkatsev:

   [checks with everyone that there aren't any topics]
   … Thanks everyone, let's adjourn early today. [adjourns
   meeting]


    Minutes manually created (not a transcript), formatted by
    [13]scribe.perl version 158 (Sun Oct 17 00:40:18 2021 UTC).

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