Meeting minutes
This meeting
Nigel: we have a topic on HRM and I'd like to move that to the end because Chris is here for 30min
… and we need to discuss joint meetings first
… there is also a discussion on how we do tests
… the last topic is the charter
… it expires at the end of the year and it might take 3 months to prepare it
Pierre: the HRM topic is really time sensitive and crucial
Mike: +1
Joint meeting requests
Nigel: TPAC is virtual only
… we've had requests/suggestions for joint meetings
… the first one with explicit request is Media Synchronization
… there is work on progress on Sync and User Accessbility
… it's a companion to MAUR
… they've asked us for time
… at 10 amET, 14UTC
… 20th October
… any objections?
Resolution: We accept the meeting with APA to discuss SAUR
Nigel: there are 3 other groups we could meet with
… MEIG: I'm not clear what agenda topic we could usefully discuss
… anybody has topics?
Chris_Needham: the IG is not planning to take updates
… if we don't have specific topics we could cancel
Gary: we could discuss unbounded cues but we can schedule those as we are doing
Chris_Needham: which reminds me to schedule the next one
Nigel: in the absence of proposal to have a joint with MEIG, we will not request one
Nigel: next group is Media WG, working on the next version of MSE
… they will publish FPWD of MSE v2, which continues to include support for Text Tracks
Cyril: only in the spec ...
Nigel: same question, any benefit in having a joint meeting, any topic worth discussing?
Chris_Needham: there was the generic text track cue proposal
… is there anything there that needs further discussion?
Gary: it could be useful if we could get more buy in from vendors
Nigel: should we start talking about it only when we have more buy in?
Gary: maybe we just need to do it offline, but it's worth reminding people about it
Glenn: we've been repeating that for 2-3 TPAC, with nods, but nothing happens
… not sure, it's worth the effort
Chris_Needham: it does not have to be a TPAC thing
… we can do it at anytime
… no pressure from the Media WG AFAIK
Gary: I can't think of anything urgent
Glenn: they should start implementing
Gary: Safari has implemented and shipped
Nigel: do we want to increase communication around it to push other implementors to implement
Gary: we can bring it to one of their working group regular meetings
Nigel: let's have the conversation between the chairs of the groups
… happy to ask Apple if they are willing to report on how it's going
… offline
Glenn: we had a few people attend this group in the past
Nigel: yeah, I know who to ask
Nigel: We will not request a joint meeting with Media WG
Nigel: next is the CSS WG
… there is a limited amount we could discuss
… in the past they have worked on feature for us, but they are not implemented
… we're a bit stuck if we are not CSS implementers
… I don't think there's been any change since last TPAC
… any topics?
(silence)
Nigel: ok, nothing to add
Nigel: We will not request a joint meeting with the CSS WG
Charter
Nigel: atsushi is not here
… but usually the chair works on a draft
… I reviewed ours
… there isn't a huge amount that we want to change
… if we want to continue TTML3 we should be clear about the goal
… we one thing we talked about doing is creating a version of TTML that is based on CSS
… WebVTT is still in there and has been in CR for the entire charter
… I don't know if there will be pressure from W3C to move it one way or the other
… the last thing is TTML profile for Audio Description
… we produced an ED but not a FPWD
… we need to understand the deliverables people want to work on
… otherwise we'll be a maintenance group
Pierre: any reason not to be a maintenance group?
Nigel: recently, W3C moved away from having maintenance group
… we could have one cycle of maintenance but maybe not 2
<nigel> [atsushi joins]
Pierre: I have a different feeling, they want to make it easy to maintain spec
Nigel: maybe without having a group
Atsushi: W3C defines a maintenance
… for example SVG
… update on specification
… restricted on non normative features
… fixing bugs is ok
… but no new features
… no large normative items
… TTML 2nd edition has not reached recommendation
Nigel: I'd like for anybody to let me, Gary and Atsushi know if they want anything specific included in the next charter
… we'll incorporate than in the draft for review
Gary: agree
Nigel: there is also the option to extend the charter, but there may be constraints
Atsushi: usually we extend for 6 months depending on how long we bring existing CR to REC
Nigel: I propose we don't try to rely on extension unless we have to
Glenn: a 6 months extension to gettting TTML2 to REC would be pointless unless we have implementation commitment
Nigel: I agree
<nigel> [chris leaves]
TTML Tests
Nigel: I don't propose to go into the details on history
… but a keen observer will get a sense of why I'm proposing that
… 2 things I want to cover
… we have a clear working mode to make changes to our spec repo
… which is that we open an issue, describe what happens, open a PR, the group has minimum 2 weeks
… and we don't merge until we have at least 1 approval
… unless there is an urgency
… it's been unclear for our test repository
… I'm proposing to adopt the same process for tests
Cyril: agree
Glenn: no issue with that
… one of the reasons we were more flexible previously was
… during the CR and implementation reports period, we were rapidly changing those and not calling for a group review
… but now that things have stabilized more, I don't have objections to following the 2 week period review
Resolution: The group adopts the same process for test repo changes as for spec repo changes
Action: Nigel to apply the same branch protection rules to the test repos as the spec repos
Nigel: next proposal is about test expectations and references
… for most tests we have some
… maybe not formally required for pass, but useful
… generated with TTPE in SVG form
… for IMSC, they are generated by IMSC in PNG form
… given that we don't generally require pixel accuracy for tests
… but things like order of glyphs are fixed and not subject to SVG renderers
… I'd suggest it to be good to have PNG renderings of the SVG versions
Glenn: the original reason I had included expectations in the TTML repo is: 1) to give an ability to view a rendering, documented in the readme of both test repos
… it clearly states it is for sample purposes, not claiming correctness
… and the group did not review those to agree or not
… 2) I needed a way to perform regression testing on TTPE
… at some point instead of storing in the TTPE repo, I decided to use submodules in git and point to the W3C repo from the TTPE repo
… that made them strongly bound together
… so if I made changes to the TTPE code that changed the rendering, e.g. grouping hierarchy, changing the SVG but not the rendering
… I was using Chrome as my sample rendering
… then I needed to change those expected renderings
… when I updated them recently, there were questions about that
… in reviewing that decision to tie the 2 repos, I made the decision to revert that dependency
… and to disconnect TTPE's repo from W3C's repo
… it's not the business of W3C to help the regression testing of one implementation
… so I removed the dependency from TTPE
… and removed expectations from W3C
… my proposal is just to leave the test without the SVG TTPE expectations
… if the group wants PNG, that can be done
Nigel: I largely agree with that. W3C are not there to support a particular implementation.
… also there has not been a review of the SVG expectations
… however they are useful
… they would create a more complete test
… I think it would be useful generally to take those as some form of reference
… implementations can compare and raise issues if they differ
… for me a test repo without some form of rendering is not that useful
… that only applies to presentation tests
Glenn: AFAIK the group has not reviewed the SVG for IMSC
… I'd prefer to remove the SVG files
… I don't intend to support them in the future
… within the W3C test repo
… I will be updating only the TTPE repo
Pierre: I think there is no need to require PNG or SVG
… I'm not sure what question is being asked at this point
Nigel: are you happy to have a test repo without rendering?
Pierre: it's much better if it is there, but requiring won't help
Cyril: it's much easier to produce a PNG than an SVG for most implemtation
… we should be clear not to require SVG
Glenn: I did actually code up a tool to convert SVG into PNG using a library called librsvg however the quality of its output is not as good as
… the renderings in Chrome, or some of the other browsers.
… It would be a degraded PNG but it would be something.
… It's probably a week or less work to generate PNG from the SVGs that are currently in the repo.
Nigel: I agree we need to be clear on the requirements to add new tests, to make it achievable
… I don't think we need a resolution
… but I would request that we don't remove the SVGs while we study how to generate PNGs
Glenn: ok, I will not merge the PR yet
IMSC HRM
Nigel: pal you said there is a time urgency, can you explain?
Pierre: there is now an HRM validator
… folks are integrating them in their workflow and files are failing
… we have one concrete report and 2 issues
… the 2 issues are: one where today the complexity of painting background behind spans is the same complexity as painting the region. It's too simple.
… the other one is the fact that clearing the root container has a cost even if the previous ISD is an empty ISD which already caused to clear
… I want to ask if there is any strong feelings on these 2 issues
… I could prepare PR
<Zakim> nigel, you wanted to ask about render success for documents that fail HRM now
Nigel: there are some real world documents that fail the HRM
… given the purpose of the HRM is to make sure that real world documents render
… do we have data that shows that these real world documents render on real world devices
Pierre: in those cases, the HRM is clearly erroneous
Nigel: the screen clearing after empty ISD, the ticket is clear that it is excluding existing authoring practice
… the span issue is not that clear
Pierre: but again, the algorithm in the HRM is non-sensical
… as the region becomes larger, it does not make sense
Mike: to your question about evidence, there is no way to quantify that for 2 reasons:
… we don't have access to all renderers in the world, finding one is not sufficient
… and the failure is not obvious
… we need to rely on the argument of what's reasonable, have we made mistakes, ...
… I don't remember how much it was modified from DECE's version
Nigel: small changes were made, but left mostly intact
Pierre: what I'm proposing to do is to fix what looks like a defect, update the code and iterate
… see if changes break players
Mike: this would be a revision to IMSC 1.x
Pierre: assuming we are ok to make those changes, what I would propose is to factor out the HRM to a separate doc
… as a WG Note first and once we're happy we can put it back
Nigel: that is a deliverable that we could add to the charter
Cyril: are there players that rely on the HRM?
Pierre: I don't know
Mike: I doubt that
Pierre: when we make that change, we might have other changes to make
… we should leave the door open
Nigel: it's a good approach to structure things to make changes easy
Mike: this has been an invaluable tool for real time transcoders
… people started creating full documents 30 times per second
… because you can point to definitive perfomance criteria
… without HRM, encoder implementors can produce documents that make decoding implementations ver difficult to get good results
Nigel: you're requesting the go ahead to make PR
… my summary is that you have the go
Pierre: and what about the WG Note?
… start with a WG Note for today, the charter can mention REC track
Nigel: you can start with a REC track document, that's in the spirit of the current charter and that's a refactoring
Pierre: ok
Pierre: can you create a new repo?
Nigel: I might need help from atsushi
… we should call imsc-hrm
Pierre: yes
Atsushi: I will work with nigel on this
Meeting close
Nigel: Thank you everyone - it's been a very productive meeting, apologies we went 5 minutes over.
… [adjourns meeting]