- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 10 Jun 2021 16:25:48 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <7EAED7A6-0B65-4860-B1FD-B44BE33BFF64@bbc.co.uk>
Thanks all for attending today's action-packed TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2021/06/10-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
10 June 2021
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2021/05/27-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/187
[4] https://www.w3.org/2021/06/10-tt-irc
Attendees
Present
Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
Andreas, Glenn
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]Shear calculations and origin of coordinate system.
w3c/ttml2#1199
3. [7]Mention fingerprinting vectors in privacy
considerations. w3c/ttml2#1189
4. [8]Clarify if the first ISD must/may be constructed when
empty w3c/ttml2#1232
5. [9]NBG(R_i) counts transparent backgrounds w3c/imsc#570
6. [10]span elements are included in NBG(R_i) w3c/imsc#571
7. [11]Add test for fillLineGap when background is
semi-transparent w3c/imsc-tests#99
8. [12]TPAC 2021
9. [13]AOB: IMSC HRM
10. [14]Meeting close
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: [15]https://github.com/w3c/ttml2/issues/1199
[15] https://github.com/w3c/ttml2/issues/1199
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: [16]https://github.com/w3c/ttml2/issues/1232
[16] https://github.com/w3c/ttml2/issues/1232
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: [17]https://github.com/w3c/imsc/issues/570
[17] https://github.com/w3c/imsc/issues/570
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: [18]https://github.com/w3c/imsc/issues/571
[18] https://github.com/w3c/imsc/issues/571
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: [19]https://github.com/w3c/imsc-tests/issues/99
[19] https://github.com/w3c/imsc-tests/issues/99
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]
Minutes manually created (not a transcript), formatted by
[20]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[20] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 10 June 2021 16:28:24 UTC