- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 8 Jul 2021 16:52:50 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <3FD5A2F9-1214-45C2-92D6-D9F367141D0D@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2021/07/08-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
08 July 2021
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2021/06/24-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/192
[4] https://www.w3.org/2021/07/08-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Mike, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]IMSC HRM Strategy
3. [7]Fix #1232 by clarifying the [resolve timing] procedure
w3c/ttml2#1233
4. [8]Tests
5. [9]Meeting Close
Meeting minutes
This meeting
Nigel: Today we have:
… * IMSC HRM Strategy
… * one open TTML2 issue, and
… * Tests
… * Plus AOB: TPAC.
… Is there any other business, or anything to make sure we
cover?
group: [silence]
IMSC HRM Strategy
Pierre: The problem is straightforward.
… There are 3 versions of IMSC that are current: 1.0.1, 1.1 and
1.2.
… 1.0.1 and 1.1 are maybe most used.
… They all define the Hypothetical Render Model that
… allows the complexity of documents to be bounded.
… In the process of writing an HRM validator I have found some
issues.
… In all cases, the question is: if we modify the HRM, how do
we propagate it throughout all the versions, or not?
… What's the right way?
… Errata against each?
… Revise each?
… Factor out the HRM?
… I'd appreciate people's input and thoughts.
Cyril: Factoring it out seems like the best option to me,
avoiding discrepancies.
… Is it totally possible? Are there features that need specific
provisions in the HRM?
Pierre: Yes, I think the answer is yes actually, there are
differences, which also could be factored out.
… 1.1 added text shadow. So there's at least one difference.
… That had to be included in the HRM.
… In terms of process, how difficult is it to revise an
edition?
Nigel: It's doable. The choice is to revise three Recs or
publish a 4th Rec and revise 3 Recs. But I think it might be
worth it. It's certainly tempting.
Pierre: What's the process for revising an edition?
Nigel: I think all those Recs were published before we could
adopt the new mechanism for making candidate changes in Recs.
… Does that mean we cannot now start doing that?
… Or can we say "hey, we're going to work like this now" on
these existing Recs?
Atsushi: I need to check. In any case we need to go through CR
-> Rec for substantive changes.
… When we go to CRS we can adopt the new mechanism.
… I suppose the answer is Yes, or it will be automatically
applied.
… As an example, CSS [something] published in 2020 went through
that change. I can't recall exactly which.
[10]6.2.4. Updating Mature Publications on the Recommendation
Track
[10] https://www.w3.org/2020/Process-20200915/#update-reqs
<atsushi> [11]CSS containment module level 1
[11] https://www.w3.org/TR/2020/REC-css-contain-1-20201222/
Atsushi: This is the first one that was updated under Process
2020. You can see in the history...
Nigel: Oh yes, it went from Rec to Rec.
… I see, Candidate Corrections were inserted.
Atsushi: It may be possible to follow this since it is the same
situation.
Mike: The challenge is if the HRM is different across versions,
then it gets trickier and harder to reference.
Nigel: Is the text shadow change one where there's something
countable where the count comes to zero when the feature is
prohibited?
Pierre: Yes, that's a really easy one. I think it's the only
one, so it makes the refactoring option not impossible.
Nigel: Is now a good time to push a message out to the world to
say we're thinking about an HRM Rec and asking for interested
implementers
… to come forward?
Pierre: Are two implementations needed?
Nigel: The rules in 6.2.4.1 are stricter than 6.2.2
deliberately. It may actually be easier to justify a separate
Rec track document.
Andreas: Are existing implementations meeting the spec?
Pierre: This is a good moment to check.
Andreas: At the moment the most used implementations are imscJS
or TTPE so this would be two implementations
Pierre: But the HRM tests complexity of documents so if we want
to make sure the reference implementation is correct we would
… have to test against creation tools.
Mike: It's a constraint on the encoder rather than the player.
Pierre: This is the time to do this, whatever we do if we are
going to modify the specs, part of the implementation
… experience is to get confidence that it works against
implementations in the wild.
Nigel: Thinking out loud, I wonder if there's a way of framing
this that we have both a validating implementation
… and a player implementation where the player can play
documents of the maximum complexity.
Nigel: Just to remind ourselves of the changes...
[12]Issues labelled HRM
[12] https://github.com/w3c/imsc/issues?q=is:issue+is:open+label:hrm
Pierre: There are 3 issues.
Nigel: One was uncontroversial, one has an action to prepare
the pull request and the third needs further discussion.
Pierre: From an Editor's perspective, thinking out loud,
refactoring might be less work, because keeping
… track of changes across 3 documents might be harder than
keeping it all in one document.
… 4 documents need to be modified, but for 3 it is just
deleting a section.
… We're talking about conformance though. Today, conformance of
the Processor
… is that it should be able to decode all documents that pass
the HRM.
… If we move the HRM to a separate document I don't know how
that works.
Mike: You'd have to reference it normatively.
Pierre: [wonders if the HRM references IMSC]
Mike: The end result has to be the same outcome modulo any
changes we want to make.
… We don't want to make a version of IMSC 1 that no longer
requires the HRM.
Pierre: Exactly. I just want to avoid circular references.
… It's possible that the HRM only refers to TTML, in which case
that would work.
Nigel: Wonder if we should factor the threshold values out of
the HRM and pass them in as parameters from the referring spec.
… That could make it easier to publish future versions of IMSC
with greater threshold values.
Pierre: We could do that.
Mike: We need to increment the versions somehow so that
referring specifications are clear.
Pierre: One option is to update 1.1 and 1.2 but not 1.0.1
Mike: That would work for the things I'm concerned about.
Pierre: There are HRM bugs that affect 1.0.1, but I'm not sure
there's much risk in having a 2nd edition of 1.0.1
Mike: Maybe that'd be okay, but it's still different. I'm not
sure how they would finesse that.
Nigel: It could be 1.0.2, right? It would fix the referencing
issue.
… What would be annoying would be to go from 3 active Recs to 6
though!
Pierre: I don't sense a particular preference from the group.
Mike: Remember the players are in devices that have a lifetime
of several years.
… Proliferation of IMSC specs is not ideal.
Pierre: My suggestion is to start with pull requests on 1.1 and
see how it goes.
Nigel: I think signals, even private ones, about intent to
implement the HRM would be really helpful here.
Pierre: Why not announce that?
… My proposal is to make a plan to edit 1.1, to create a new
edition, that addresses those issues identified in the HRM,
… and solicit both other HRM implementations, but even more
importantly, sample documents, and help from the industry
… to test at least the existing HRM implementation.
Nigel: One question I have is what the actual benefit is to
fixing the bugs - even though the HRM might be imperfect,
… it could that it is nevertheless good enough to achieve its
goal.
Pierre: Yes, it could be there is a problem or no problem.
Mike: I think there is generally low knowledge of the HRM, but
it is being socialised more at the moment.
Pierre: So start with 1.1, and announce the work, and start
doing it.
Nigel: That sounds like an action for me to start work on an
announcement.
… We can defer the decision about exactly how we do it.
Pierre: Exactly
Mike: Several specs are locked to 1.0.1 and 1.1 so there would
be some logistics to keep this straight and not mess up MPEG,
ATSC and DVB.
Nigel: Thanks, let's wrap this topic up.
Fix #1232 by clarifying the [resolve timing] procedure w3c/ttml2#1233
github: [13]https://github.com/w3c/ttml2/pull/1233
[13] https://github.com/w3c/ttml2/pull/1233
Nigel: After we discussed this last, Pierre, Glenn and I talked
about it directly and worked on a change, which I pushed.
… Glenn approved it, 13 days ago, and nobody else has done.
… I want to know if we can merge this. It's beyond our normal
process time for reviewing, and has one approval.
… Does anyone want more time to review?
Pierre: It's a great improvement by the way. The only thing
that's not clear to me is the wording about the
… Root Temporal Extent, which has a begin and an end.
Nigel: In our discussions, Glenn and I understood that the
Temporal Extent is a duration.
Pierre: But it's in the definition, the Root Temporal Extent
has a begin and an end.
Cyril: +1 it has a begin and end
Pierre: If Root Temporal Extent did not have a begin and end,
then the application could not modify the begin, and that would
be unhelpful.
Nigel: Please could you add the comment to the PR?
Pierre: Yes, sorry for not doing it earlier.
SUMMARY: More review time requested.
Tests
Nigel: This is a plea from me as Chair!
… In many ways the tests we have are almost more important than
the spec text!
… Many implementers look at tests first.
… A number of tests have been added to TTML2 Tests and merged
without review, by Glenn.
… Also there are open pull requests to add tests to IMSC Tests
that have not had review.
… So my request is please everyone do take a look at the tests
that are added either directly or by opening pull requests,
… and watch those repos.
[14]TTML2 Tests
[14] https://github.com/w3c/ttml2-tests/
[15]TTML2 Tests merged without review
[15] https://github.com/w3c/ttml2-tests/pulls?q=is:pr+is:closed+label:"merged+without+review"
Nigel: There are 4 recently that I noticed.
Pierre: Looking at #270 and #271 I don't even understand what
the issue is.
… I think it's unfair to ask everyone to review things that
can't really be reviewed.
Nigel: I understand. The situation is different on imsc-tests
by the way.
[16]IMSC Tests repo
[16] https://github.com/w3c/imsc-tests/
Pierre: Yes, I apologise for not reviewing them
Nigel: I see that there are 5 open PRs that no doubt are all
good, going back to October 2019, by 3 different contributors.
… Let's try to carve out time to get those done.
Pierre: I agree
Meeting Close
Nigel: Thanks everyone, apologies for going 5 minutes over.
… [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[17]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[17] https://w3c.github.io/scribe2/scribedoc.html
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 8 July 2021 17:09:56 UTC