- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 2 Sep 2021 16:35:48 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <3D45E3CE-49F4-4B26-942E-22F02555F03A@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2021/09/02-tt-minutes.html
We resolved to:
1. Jointly meet with APA to discuss SAUR
2. Adopt the same process for test repo changes as for spec repo changes
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
02 September 2021
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2021/07/22-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/196
[4] https://www.w3.org/2021/09/02-tt-irc
Attendees
Present
Andreas, Atsushi, Chris, Chris_Needham, Cyril, Gary,
Glenn, Mike, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
cyril, nigel
Contents
1. [5]This meeting
2. [6]Joint meeting requests
3. [7]Charter
4. [8]TTML Tests
5. [9]IMSC HRM
6. [10]Meeting close
7. [11]Summary of action items
8. [12]Summary of resolutions
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]
Summary of action items
1. [13]Nigel to apply the same branch protection rules to the
test repos as the spec repos
Summary of resolutions
1. [14]We accept the meeting with APA to discuss SAUR
2. [15]The group adopts the same process for test repo changes
as for spec repo changes
Minutes manually created (not a transcript), formatted by
[16]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[16] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 2 September 2021 16:36:09 UTC