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
Is the basis for DAPT IMSC 1.1 or is it an independent spec with common provisions?
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> https://
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]