Re: {Minutes} TTWG Meeting 2019-06-20

On Fri., 21 Jun. 2019, 3:19 am Nigel Megitt, <nigel.megitt@bbc.co.uk> wrote:

> Thanks all for attending today’s 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
>
>
My suggestion is to Not add it to the REC spec, but add it to the next
editors draft. It would initiate a lot of extra reviews and tests on REC.

Just my 2c worth.

Cheers,
Silvia.




>
>    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
>
>