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.
6.2.4. Updating Mature Publications on the Recommendation Track
<atsushi> CSS containment module level 1
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...
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: https://
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.
TTML2 Tests 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.
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]