- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 20 Jun 2019 17:19:05 +0000
- To: Public TTWG List <public-tt@w3.org>
- Message-ID: <D9317E6B.46F75%nigel.megitt@bbc.co.uk>
Thanks all for attending todays TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2019/06/20-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
20 June 2019
[2]Agenda. [3]IRC log.
[2] https://github.com/w3c/ttwg/issues/43
[3] https://www.w3.org/2019/06/20-tt-irc
Attendees
Present
Cyril, Gary, Nigel
Regrets
Andreas, Glenn, Mike, Philippe, Pierre, Thierry
Chair
nigel
Scribe
cyril, nigel
Contents
* [4]Meeting minutes
1. [5]this meeting
2. [6]WebVTT
3. [7]TTML2 luminance gain
4. [8]TTML Profile Registry The codecs parameter should
have a formal definition of the use of the combination
operators. #71
5. [9]PNG in PQ HDR
6. [10]AOB - Karaoke
7. [11]Meeting close
Meeting minutes
<nigel> Log: [12]https://www.w3.org/2019/06/20-tt-irc
[12] https://www.w3.org/2019/06/20-tt-irc
this meeting
nigel: we have WebVTT
for TTML we don't have the right people
profile registry
Mike declined for this meeting
progress on PNG PQ
update on charter
AOB: karaoke
WebVTT
nigel: gary has done a snapshot
gkatsev: it's marking 4 things at risk
text combine upright, text wrap balance, line and position
alignment
the last 2 are probably supported in Firefox and vtt.js but
it's safer to mark them at risk
nigel: what are we doing with unsigned long?
gkatsev: silvia mentioned that there is not int in WebIDL?
we can use the regular long, it's the right range but allows
negative values
however the spec says that negative values should throw
for now I've split the test into an int range that passes
nigel: [does some binary maths] your change should work
gkatsev: I should update my PR to remove the second test
nigel: In a way it was a weird thing for the spec to say that
it should throw for neg values when they were not possible
gkatsev: I'll update that today
nigel: to see the snapshot what do we have to do?
<gkatsev> [13]current at-risk snapshot
[13] https://htmlpreview.github.io/?https://github.com/w3c/webvtt/blob/f071ae65389148c8195102e3fb2483de7e408dd0/archives/2019-06-19/Overview.html
nigel: we'll review that
nigel: the summary for this week is you made tests, we approved
but they are not merged yet
could you review them?
gkatsev: yes they pass in Safari and Firefox
there was the issue regarding the cue box sizes
and it seems a reasonable change
but I probably don't want to do it now
yet another moving part
Is make such change just before CR ok?
nigel: It can be done but it depends on the impact of the
change
I'm not clear on the impact for this one
I would like to have PLH's input on this one
If you can demonstrate 2 implementations
is it related to writing direction?
gkatsev: if you have text alignment left or right, the position
is correct
but if start or end, it won't be aligned properly
nigel: so it's a bug
gkatsev: start and end were added a bit later
nigel: the implementations do what the spec says?
gkatsev: yes
nigel: so if you fix the spec, the implementations will have to
change?
gkatsev: yes
making a normative change feels that it would take longer to
get the CR out
I will ping PLH on the issue directly
nigel: yes that needs more thought
the impact is that for right to left if you rely on start or
end it won't work
so there is a work around?
gkatsev: yes
nigel: it doesn't sound that the impact is massive if we don't
fix it now
gkatsev: yes, the workaround is use right or left instead of
start or end, depending on the writing direction
nigel: anything else on VTT?
TTML2 luminance gain
github: [14]https://github.com/w3c/ttml2/issues/1117
[14] https://github.com/w3c/ttml2/issues/1117
Cyril: The context is that I started discussing internally at
Netflix
with teams who implement HDR on games consoles, asking how to
render luminanceGain.
People looking at the spec for the first time were confused
by the term "gain".
It's an absolute luminance but called a gain. Initially they
thought it was gain relative to graphics white.
You can discuss with the TV to know what its graphics white
luminance is. They interpreted it
as compared to that and not compared to 18 nits which the
spec says.
The spec is not unclear, but they had an assumption.
We agree with what is written in the spec and Fox proposed
this clarification. We think
it is a good one.
Nigel: Will you propose a pull request?
Cyril: Yes, it will be a Note saying that the gain is relative
to 18 nits and not to a relative value
corresponding to the device graphic white, or something along
those lines.
Nigel: Ok, looking forward to seeing the pull request for that.
TTML Profile Registry The codecs parameter should have a formal
definition of the use of the combination operators. #71
github: [15]https://github.com/w3c/tt-profile-registry/issues/
71
[15] https://github.com/w3c/tt-profile-registry/issues/71
Nigel: It's been a while since we opened this and we haven't
managed to get to it.
Cyril: I haven't had a chance to work on it.
Nigel: Comment from 11 April, we need Cyril, Mike and Glenn on
the call. Let's move on for today, since we don't have all
those people.
github-bot, end topic
PNG in PQ HDR
cyril: this seems purely editorial
nigel: yes
I have changed the link on the repo, as requested on the repo
and I have created a PR to add link to the editor's draft in
the readme
<nigel> [16]Pull request #9
[16] https://github.com/w3c/png-hdr-pq/pull/9
AOB - Karaoke
Cyril: I have made a first editor's draft of the Karaoke
module.
For the record, I'm uneasy with the term Module, and have had
lengthy conversations with Glenn.
My position is if we promote the term Module to a bigger
state, to be more visible, we will have
terms like Specifications (TTML), Profiles (IMSC), Features
(feature designators),
and my view is the term is only in TTML in the two tables in
§5 which list the modules as a collection
of elements or attributes. I think it is confusing for a new
specification to say it is a module.
What people will care about is the module defines one or more
features, which a profile can then
include. That's the only thing that is needed.
I'll follow what the group decides but I think it's
confusing.
I know CSS uses the term Module so maybe people are familiar
with that.
It is related to the text in TTML3 that talks about
public/private modules and the module registry.
To me this is too much, we don't need to introduce all these
notions to define a new specification.
I called this an extension not a module, with reference to
HTML5 MSE and EME.
Glenn noted we have extension designators already in TTML so
the term is used.
I'm open to a different terminology.
Gary: I agree there are a lot of different names and limiting
the terminology is a plus.
I'm not sure the best direction.
Nigel: I agree that we don't need the additional terminology in
TTML3, and have made that pretty clear
in a comment on TTML2 pull request 1066
[17]pull request 1096 comment
[17] https://github.com/w3c/ttml2/pull/1096#pullrequestreview-242593523
Cyril: We merged the change to TTML3 though?
Nigel: Yes I feel we were pushed into that and I don't like it.
So I agree about using less terminology where we can.
Where I think I do agree with Glenn is the word "module" to
be a specification that defines some
additional features seems fine to me, especially since those
features are grouped by some
technical theme.
If using Module means less change to TTML that's a good
thing.
Cyril: You would say the new spec is the Karaoke module but
don't introduce internal/external,
and just remain silent. We don't need to define what the
module is?
Nigel: Yes
Cyril: Okay I could live with that.
Nigel: I think we just can say in the Karaoke module that it is
a specification that defines some TTML2
features. We don't need anything more.
Cyril: I won't define any profile.
Nigel: That's clean
Cyril: My intention is we would add a new profile elsewhere,
IMSC1.1K or whatever (don't know the name)
I tried to define this module by adding the minimum number of
elements and attributes.
There are no new elements, only 3 attributes.
One of them is a styling attribute tts:imageEmphasis,
building on the semantics of textEmphasis
but replacing the text by an image when textEmphasis is set
to "auto".
Initially you could have thought about changing textEmphasis
to add a URL but that would have been
backwards-incompatible and existing implementations would
break.
So I preferred creating a new attribute. If it is ignored the
emphasis will be a text not an image,
so there is graceful degradation.
Nigel: I like the sound of that!
Cyril: Glenn asked if an attribute should be a parameter or a
style attribute, saying we only put
parameter attributes on the root element so it should be a
style attribute.
<cyril> [18]Karaoke module
[18] https://w3c.github.io/tt-module-karaoke/
Nigel: I see, ttp:karaoke to define a _section_, no, I agree
that doesn't look like a parameter attribute.
Cyril: Styling properties have a notion of inheritance and
applicability, but that doesn't apply here.
A karaoke section allows the presentation processor to
override the semantics for the relevant section.
For example a song inside some other content that is used for
karaoke
I wanted to raise the general question - what is the
philosophy behind a parameter attribute?
Nigel: My understanding is that a parameter attribute sets up
the processor with some settings or
constraints that apply when processing the entire document,
so it only makes sense to have them
on the root element.
This karaoke attribute does not feel like a parameter
attribute.
Cyril: Ok, I'll change it.
Nigel: But what to?
Cyril: A styling attribute, applicable only to body and div
Nigel: That works, or you could use a new namespace
Cyril: No, we have enough of those!
The last thing is the general philosophy of the spec is that
you could do limited karaoke with TTML2
today, because you have a set and animate element.
Two problems:
1. When the processing engine sees an animation it does not
know it is karaoke, so no semantics
associated with it. The engine cannot apply its own settings
on the basis that it is karaoke.
We want to detect if content is karaoke.
2. TTML2 is limited - the bouncing ball above the text cannot
be specified.
This spec adds semantics to identify where the karaoke
content starts and animations can be
overridden, and adds more animation types.
karaokeMode allows the emphasis to be applied with text
emphasis or with colour.
Please read, open issues and I will propose changes.
Nigel: We should find a way to get the word out on this.
Gary: Maybe Crunchyroll?
I know a lot of people in anime community do karaoke for the
opening songs. They might be interested.
Nigel: It would be good to get input from this as soon as
possible.
Cyril: Glenn said this should be TTML1 applicable not just
TTML2. Nigel what do you think?
Nigel: If you need textEmphasis you have to depend on TTML2, it
isn't in TTML1
Gary: Maybe say "if textEmphasis available then this applies"
rather than the direct dependency on TTML2.
Cyril: Yes
Nigel: Good idea, if that can work
Cyril: I may define one feature for emphasis based karaoke and
another for colour based and in TTML1
only the colour based karaoke could work.
Nigel: Good idea
Cyril: Please open issues and we can discuss that.
Nigel: OK, thank you!
Meeting close
Nigel: Thanks everyone, we couldn't discuss the charter etc
because Philippe couldn't make it - he tells
me by IRC that he is in the thick of some deep discussion. So
we'll adjourn for today. [adjourns meeting]
Minutes manually created (not a transcript), formatted by
Bert Bos's [19]scribe.perl version Mon Apr 15 13:11:59 2019
UTC, a reimplementation of David Booth's [20]scribe.perl. See
[21]history.
[19] https://w3c.github.io/scribe2/scribedoc.html
[20] https://dev.w3.org/2002/scribe/scribedoc.htm
[21] https://github.com/w3c/scribe2/commits/master/scribe.perl
Received on Thursday, 20 June 2019 17:19:31 UTC