Meeting minutes
This meeting
Nigel: Lots to get through today.
… TTML2 open issues,
… IMSC HRM issues,
… and an IMSC Tests issue
… For AOB there's TPAC 2021 - anything else?
group: [no other business]
Shear calculations and origin of coordinate system. w3c/ttml2#1199
github: https://
Nigel: Glenn informed me earlier today that he is planning to open a pull request to address this, and is doing implementation work.
… I asked him to share his thoughts on the issue before opening the pull request, and he said he would.
… He summarised it as "don't optimise too soon", which I think means "you don't have to implement the ideal end result".
… I'm interested to see what flexibility he wants to clarify in implementations.
Cyril: I also have an update.
… I talked to Glenn! He told me he wanted to write a PR.
… I had the action, though I'm late doing it.
… The agreement we had was that I would clarify the origin and axis in the case of tblr and we said we could leave
… it undefined for other writing modes. That's my recollection.
… Glenn told me he verified his TTPE implementation and is satisfied with it.
… My understanding is he wanted to clarify the spec based on that implementation.
… My original comment was about the lack of clear definition of the origin of the transform or the orientation of the axes,
… and if any scaling or transformation needs to be done.
… He told me he wants to clarify the same things.
… It might go beyond what I thought we would do, but that was because of a lack of agreement
… on what to do for the other writing modes.
… If we have a proposal we can decide if we want to adopt it (for the other writing modes)
Nigel: Thanks, anyone else want to raise anything on this issue now?
Atsushi: Nothing from me
SUMMARY: Waiting on Glenn @skynavga for a pull request to review
Mention fingerprinting vectors in privacy considerations. w3c/ttml2#1189
Nigel: This has been merged, there's nothing more to do here.
Clarify if the first ISD must/may be constructed when empty w3c/ttml2#1232
github: https://
Nigel: This has had a pull request open for >2 weeks, and we do not have consensus to merge it.
… In fact there are objections to merging the pull request, despite it saying what I thought had been agreed in the issue.
… It seems that the best action here is to close the PR and the issue, marking as "not doing".
… The motivation was to try to help other downstream groups. We agreed there is flexibility in TTML2.
Pierre: It could be worth text that says "it is always possible to create an ISD everywhere, it just might be an empty ISD"
… It's a useful observation because then it removes some difficult to define concepts such as root temporal extent.
… You just run a procedure and then you always get something.
… That's one useful outcome from the thread.
… It's particularly useful when you put a TTML document on a timeline,
… where that timeline could start before the begin on a body element for instance and could
… end after the end time on the body element.
Cyril: You mentioned MPEG. It would be good for MPEG to have the text you proposed but not strictly necessary.
… As long as we all agree, then we're good.
… I like the text you suggested.
… The only unclear part is what Pierre mentioned about the root temporal extent.
… The rest is uncontroversial.
… What's missing is the definition of an empty document.
… There's some convergence on the empty TTML document defined by EBU.
… But there's no definition of an empty ISD, is there?
Nigel: No, I don't think so.
… I get the sense that no change is required but some change is helpful.
… Should we continue the discussion and working on the pull request?
Pierre: My issue with the current pull request is that it suggests that there is a correct ISD sequence.
… I think everyone can agree that for every T between 0 and infinity there is always an ISD.
Cyril: The wording proposed by Nigel is good, that defers to application.
… I think the mention of root temporal extent was the problem for Glenn.
Pierre: That's my objection too.
Cyril: Maybe if we just remove that part.
Pierre: You can just say that for all time there is an ISD, rather than depending on an unclear begin and end, which don't matter.
Nigel: Trying to understand, so you want to say that a sequence of ISDs can be created from any TTML document such that
… there is always an ISD for every positive time T, but that not all applications need to make that whole sequence.
Pierre: But the spec should not say "the ISD before some start time is undefined" : it's just empty.
Cyril: It's worth giving this a shot, understanding the objections better, now that we understand the objections from Pierre better.
Nigel: Okay, thank you, I'll continue to put effort into this.
SUMMARY: Nigel @nigelmegitt to attempt to resolve objections to the current PR text.
NBG(R_i) counts transparent backgrounds w3c/imsc#570
github: https://
Pierre: The issue here is the algorithm makes a difference if the background is not specified or is transparent,
… but those two are really equivalent.
… It doesn't make sense for two documents to result in different complexity just based on initial value or specified value, where they're the same.
Nigel: This is about the computed value rather than the specified value, because initial can change the default?
Pierre: Right, but right now the HRM is defined in terms of specified values if I'm not mistaken.
Nigel: That's weird!
Pierre: That was before initial, where for things that are not inherited it makes a difference.
… That may be a separate issue that we need to fix.
Nigel: The two things go together.
Pierre: Sure, but even if initial is transparent, there should be no difference in complexity if one document specifies backgroundColor="transparent"
… and the other one doesn't.
Nigel: If you change this to be based on computed values and change the algorithm to ignore transparent background values, that
… would solve both issues?
Pierre: I agree, we could solve both at once that way.
Nigel: I think that makes the case for a change here more concrete.
… My discussion comments before were based on reluctance to change HRM because it will create
… new values, with new thresholds etc. so it could be costly for implementations.
Pierre: These three issues I filed were as a result of trying to implement the spec.
… I'm not aware of any other implementation of the HRM.
… Of course I was running my HRM code against sample documents.
Nigel: Any other questions or comments?
Pierre: I'll generate a pull request based on this.
SUMMARY: Pierre @palemieux to open a pull request as per the above discussion.
span elements are included in NBG(R_i) w3c/imsc#571
github: https://
Nigel: This is about where you count the background colour of spans.
Pierre: The problem with the current spec is that the cost of drawing a background on span
… is the same as the cost of drawing a background on the entire region.
… That seems to scale the wrong way.
… Intuitively you'd think that the cost of drawing the background of a span
… should roughly scale with the number of characters in the span, not the area of the region.
Nigel: My feeling is "kinda" and "maybe" and "it's not that bad is it?"
… I mean, some spans might be as big as a region, but it's unusual.
… As a worst case scenario, it's not so bad. We're just looking for a complexity value.
Pierre: It is bad though because a p with one span, compared to the same p with the same text in multiple spans,
… generates a higher complexity value.
Nigel: You mean there are documents that fail compared to the threshold now, that should pass?
Pierre: Yes, there are cases where there are 2 documents with the same rendered output,
… and one fails and one passes, based on how many spans are in the p output.
Nigel: It'd be good to see test cases.
… Although the rendered output is the same, that doesn't mean that the rendering complexity was the same.
Pierre: Imagine an implementation that uses fixed width bitmap characters.
… The cost of applying a background to a span should never scale as the area of the region,
… because the background would scale with every character drawn.
… You would not redraw the entire background of the region every time you blit a character.
… it would just be the area of the character.
Nigel: It would be useful to have test cases. Am I right that there are no HRM tests in imsc-tests?
Pierre: Right, so the project I'm doing could probably add them.
Nigel: Any other thoughts on this?
SUMMARY: Continue the discussion on the issue
Add test for fillLineGap when background is semi-transparent w3c/imsc-tests#99
github: https://
Nigel: Just to alert people to this, and mention the motivation.
… I was experimenting with varying the opacity of tts:backgroundColor on span and found that when fillLineGap is enabled,
… there's a high visual sensitivity to exact boundaries of spans, but no test cases, so I opened the pull request for this issue to add one.
… May also be somewhat relevant for linePadding.
… Please take a look.
SUMMARY: Group asked to review pull request
TPAC 2021
Nigel: I keep raising this because we need to make a decision, by 10 September, but we should try to do it sooner.
… The list of topics we have is at w3c/ttwg#191, which has one entry on it now.
Pierre: We could decide not to meet at TPAC
Nigel: Yes, that's a valid decision for us to make.
Atsushi: We can meet as a group any time, joint meetings might be helpful at TPAC.
Pierre: And it may be more convenient outside TPAC
Atsushi: Strong +1
Nigel: +1 from me too.
… Is the thing we have to do by 10 September for both joint and group meetings?
Atsushi: 2 weeks are allocated for TPAC, one week for joint meetings, and the other for groups.
… In that week we can propose joint meetings.
… Not sure if that answers your question?
Nigel: I was thinking about the Chair's admin task to register by 10 Sep
Atsushi: Could we do what we did last time?
Nigel: Yes, would you like to take that on?
Atsushi: I can try to coordinate with the Chairs
Nigel: Sounds good to me, sort me and Gary out. Gary?
Gary: Sounds good
AOB: IMSC HRM
Pierre: It just occurred to me having this discussion about HRM, it would be awesome if for instance HbbTV, which I assume has
… a lot of actual content, were to try the HRM.
… There is actual a web app at hrm.sandflow.com and you can give it an ISOBMFF track file.
Cyril: Did I understand that the tool does not just single files but also multiple files?
Pierre: Thanks a lot for mp4box.js - you can give the tool a single document, a sequence of documents with a manifest json file, or an ISOBMFF file.
Cyril: I'll study it, because we only recently tried to define the behaviour of HRM for multiple documents in an MP4 file.
… It would be interesting to see if you implemented it the same as MPEG specified it or not.
Pierre: Is there someone I could reach at HbbTV before this is made public and run some tests through it.
Nigel: Let me put you in touch with someone offline.
Pierre: Super, thanks. And Cyril, happy to discuss the processing of ISOBMFF track files.
Cyril: Sure, and I'm happy to run Netflix documents through too.
Nigel: I'd be interested to run BBC files through as well.
Pierre: I already found some bugs, so let's kick the tyres/
Cyril: One question I had is: the HRM is about a single document, but in practice the problem is the peak.
… Do you do any indication of the peak?
Pierre: Right now it reports every time the HRM is exceeded, and provides the temporal offset.
Cyril: I'd be interested in the raw numbers across the whole file.
Pierre: If you set logging to debug then it does that.
Cyril: I could try to correlate that with statistics on sessions where subs are missed.
Pierre: I'm not sure if the web app does but the command line does allow you to get the complexity of every single ISD.
Cyril: Excellent, looking forward to testing that, thank you.
Nigel: I wonder if it would be worth arranging some kind of session where we can discuss the HRM values for our content,
… particularly if we change the HRM, so we can revalidate the threshold values.
Cyril: Doesn't have to be a session, can be offline.
… I wouldn't invalidate Netflix content if it is fine in the field but fails the HRM
Pierre: Which is precisely why we should try it.
Meeting close
Nigel: We're 5 minutes over, let's adjourn. Thank you everyone. [adjourns meeting]