- From: Gary Katsevman <me@gkatsev.com>
- Date: Mon, 24 Jun 2019 16:00:29 -0400
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, Public TTWG List <public-tt@w3.org>
- Message-ID: <CAFnUpLZg_e9b7PnavVPd6RZcQ7h92LyFvAhtFd8i5h_qF3na5w@mail.gmail.com>
That makes sense. It'll create the least amount of friction to progressing the current version of the spec. On Thu, Jun 20, 2019 at 5:13 PM Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > > 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 >> >>
Received on Monday, 24 June 2019 20:01:30 UTC