23:47:26 RRSAgent has joined #tt 23:47:26 logging to https://www.w3.org/2019/09/18-tt-irc 23:47:28 RRSAgent, make logs public 23:47:28 Zakim has joined #tt 23:47:30 Meeting: Timed Text Working Group Teleconference 23:47:30 Date: 18 September 2019 23:47:33 rrsagent, this meeting spans midnight 23:53:14 cyril has joined #tt 23:56:22 atsushi has joined #tt 23:59:20 pal has joined #tt 00:01:33 scribe: cyril 00:01:37 present+ 00:01:38 Present+ Nigel_Megitt 00:01:44 Chair: Nigel 00:01:55 nigel: 2 days of meeting 00:02:03 ... a lot of different topics to cover 00:02:07 present+ 00:02:12 -> https://www.w3.org/wiki/TimedText/tpac2019#Agenda_and_Schedule Agenda 00:02:14 Agenda: https://www.w3.org/wiki/TimedText/tpac2019#Agenda_and_Schedule 00:02:15 atai has joined #tt 00:02:32 ... we have a bunch of documents that we want to progress 00:02:41 ... and we haven't begun horizontal review 00:02:54 ... a goal is to decide which documents should get to WD to trigger HR 00:03:08 ... the new process requires 3 months between WD and CR 00:03:24 ... second goal is deciding what to do with TTML3 00:03:28 ... 3rd WebVTT 00:03:37 ... and 4th MIME types for embedded media 00:04:09 pal: I'd like to resolved on the font file size issue 00:04:31 nigel: we have several TTML2 topics 00:04:36 atsushi_ has joined #tt 00:05:38 ... I listed CSS properties but I don't know when we will discuss it 00:05:56 ... for Danmaku, we will meet the Chinese IG tomorrow 00:07:46 present+ 00:08:22 ... the schedule is arranged to cover for people departure times 00:09:20 atai: we probably need 45 min for 360 00:10:22 atai: we could have a short slot for demoing 00:10:33 ... I would be interested in giving a 5-10min demo 00:11:40 nigel: the schedule does not include anything about charter 00:11:46 ... the WBS survey is closed 00:11:59 ... do you know if anybody is planning to explain to us about the charter? 00:12:42 atsushi: I have no information from PLH 00:18:15 nigel: [tweaking the agenda] 00:19:32 Topic: M&E IG follow-up 00:20:02 atai: we could also have followups of the break out sessions to prepare for the next meeting 00:20:28 -> https://www.w3.org/2019/09/16-me-minutes.html#item11 M&E IG joint meeting minutes 00:20:33 inamori_ has joined #tt 00:20:35 cyril: how many topics were adressed ? 00:20:42 atai: most of the time we discussed 360? 00:20:46 s/?// 00:21:07 pal: my take away is that there was no extension to support for text in MSE 00:21:40 s/extension/objection/ 00:21:52 ... no objection, some support but this needs implementation 00:22:29 cyril: Some details to sort out, main problem is native parsing support, TextTrackCue v2 00:22:40 .. Want to discuss MSE, DataCue and v2 TextTrackCue. 00:22:42 .. Mental model: 00:23:04 .. DataCue is the API used to surface events or information contained inband e.g. in an MP4 file 00:23:18 .. The major use case is emsg box and metadata in general, not subtitles 00:23:26 i/cyril:/scribe: nigel 00:23:31 .. DataCue is how you surface thing 00:23:46 .. TextTrackCue v2 is how you pass information in the other direction. 00:23:53 .. DataCue flows browser -> app 00:24:03 .. TextTrackCue flows app -> browser 00:24:29 Glenn: The native platform could be parsing the inband subtitling then surfacing it as a TextTrackCue if it wanted to. 00:24:49 .. The immediate use case is to allow the script to do the parsing by getting data from DataCue or something like that. 00:25:08 .. Somehow you need to get the data into the javascript to construct the data model to populate the TextTrackCue which 00:25:11 .. can then be presented. 00:25:18 Cyril: Continuing model. 00:25:36 .. The content of the text track does not flow into the app. 00:25:44 .. MSE controls the synchronisation and what text track is used and so on. 00:25:54 .. The added value is management of buffering and synchronisation more properly. 00:26:07 Pierre: It has more opportunity to do sync more accurately. 00:26:28 Cyril: Because little browser support for TTML, how can you have MSE support for Text Tracks without native support. 00:26:48 .. Wondering if MSE calls the app to do the parsing in Javascript and the result is a TextTrackCue object passed to 00:26:55 .. MSE that handles buffering, pre-rendering and synchronisation. 00:27:09 scribe: cyril 00:27:23 pal: unless it's encrypted, applications can do the extraction 00:27:32 ... why do ask browsers to do parsing? 00:27:38 ... just do it yourself 00:28:01 nigel: that's based on the model that the raw data that MSE exposes could be an IMSC document 00:30:10 ... for example unwrapping mp4 containe 00:31:49 cyril: MSE could do the unwrapping, pass the IMSC/WebVTT doc to the app, the app would create an object and pass it back to MSE 00:32:05 nigel: what about accessibility? 00:32:20 ... the BBC player always puts the right attributes on the div that displays the subtitles 00:32:31 ... so that an assistive technology would read this out 00:32:39 ... we would do adhoc repositioning when controls appear 00:33:01 i/cyril: Some details to sort out,/scribe: nigel/ 00:33:05 ... I'm trying to think whether any of these proposals would have impact 00:33:34 rrsagent, please make log public 00:33:57 gkatsev: you can also change the size of the div 00:34:06 rrsagent, please make log public 00:34:08 nigel: that's not enough to deconflict the UI from the text 00:34:13 rrsagent, please draft public 00:34:13 I'm logging. I don't understand 'please draft public', atsushi. Try /msg RRSAgent help 00:34:20 rrsagent, please draft minutes 00:34:20 I have made the request to generate https://www.w3.org/2019/09/18-tt-minutes.html atsushi 00:34:44 nigel: I'm concerned that if you pass it down you don't have controls 00:35:23 cyril: on the other hand, if you pass it to the browser, it can handle PiP, fullscreen, second screen 00:35:24 inamori_ has joined #tt 00:35:41 gkatsev: people who use captions would not want screen readers over captions 00:35:56 nigel: not everybody who can't hear can't see 00:36:04 pal: what can this group do? 00:36:06 s/can't see/can see 00:36:16 ... that's a media WG discussion 00:36:58 atai: to understand Cyril's model, is the rendering of the cue done by the browser? 00:37:01 cyril: yes 00:37:37 atai: this whole makes sense with the improvment about integrated rendering 00:38:00 nigel: the 2 problems seem to have some symmetry 00:38:12 ... why audio/video are not treated as subtitles? 00:38:24 pal: if you encrypt subtitles, then there is an issue 00:38:42 ... you'd have to discuss how to expose it back or not to the app 00:39:10 cyril: I've never heard of encrypted subs 00:39:33 nigel: the synchronization seems difficult in the browsers 00:39:44 ... the DataCue breakout was interesting 00:39:58 ... foolip said you misread the time marches on algorithm in the HTML spec 00:40:26 gkatsev: the timeupdate event firing is limited 00:40:33 nigel: I think that spec needs to be updated 00:40:51 ... he's view is that the intent was that the time marches on should be run more frequently 00:41:23 ... and a good implementation should be able to trigger the onenter/onexit close to the actual time 00:41:53 ... Chris Cunningham assigned a Chrome bug to himself 00:42:55 ... if you give it to MSE you may have more accurate timing but if the cue events are fired at a better time 00:43:10 gkatsev: I think there is benefit to having that 00:43:29 ... but maybe less of an advantage once the time marches on thing is fixed 00:44:05 scribe: nigel 00:44:25 Cyril: Relying on cue event timing isn't going to be as good as relying on native. 00:44:44 .. Implementation is really painful at the moment relying on maintaining synchronisation with timeupdate events etc 00:45:12 gkatsev: In video.js we use timeupdate but we're thinking of adopting RequestAnimationFrame 00:45:14 scribe: cyril 00:45:27 gkatsev: it's been working fairly well so far 00:46:15 nigel: have we got any request for the Media WG? 00:46:27 gkatsev: we can talk about that with them 00:46:44 ... they are all tied together? 00:46:56 cyril: is it a good idea to present my model? 00:47:02 gkatsev: yes 00:47:20 pal: we could discuss separation of work between WICG, TTWG and Media WG 00:47:34 ... if it deals with Timed Text format and accessibility 00:47:57 ... if it is an API question it's the WICG or Media WG 00:48:18 ... that means that if they see a need to extend the formats or accessbility aspects, they should come back to us 00:48:52 ... in this group, we will not have sufficient browser vendors representation 00:49:00 ... and vice versa 00:49:31 atai: the WICG is the place where the 2 communities would meet 00:50:27 nigel: the WICG allows people to develop micro features without process 00:51:27 atai: any activity yet on the WICG? 00:51:38 pal: Tess took the action item to get that started 00:52:16 cyril: this will be on discourse? 00:52:19 pal: yes 00:52:43 gkatsev: should we discuss that with the Media WG tomorrow? 00:52:50 cyril: yes, I can draft some slides 00:53:02 -> https://discourse.wicg.io/ WICG discourse 00:53:02 Topic: CSS WG meeting follow-up 00:53:11 nigel: that was a good meeting, very constructive 00:53:29 ... it went better that previous meetings 00:53:39 ... there was good progress on all of the issues 00:53:54 ... the specs will be updated 00:54:11 ... but their feedback was that either we should implement the proposed changes 00:54:17 ... or ask someone to do it 00:54:22 gkatsev: we could add tests 00:54:50 nigel: well it was not mentionned 00:55:27 gkatsev: adding tests is good because browser vendors do pay attention to failures in WPT 00:55:52 glenn: what features? 00:56:06 nigel: line alignment (multiRowAlign) and line padding 00:56:29 pal: if somebody cared enough, PR against Chromium or Firefox 00:56:33 ... would help 00:56:42 ... they care about doing good rendering 00:58:12 nigel: that's where we are with the CSS WG and we should be happy about that 01:00:10 -> https://github.com/w3c/csswg-drafts/issues/4319 CSS Issue 4319 01:00:43 atsushi: this was discussed in JLTF 01:01:09 ... it was mentioned that it may have conflicts with boutens 01:01:46 pal: we could say that text emphasis is not allowed on upright text 01:02:00 glenn: they showed examples of prints that had that 01:02:21 ... put the emphasis on the tate chu yoko block 01:06:20 atsushi: there is a new property that allows specifying a limit to the number of characters in Tate Chu Yoko 01:07:11 pal: where should the discussion happen? 01:07:27 atsushi: from an HTML and CSS point of view, you should not use TCY for long text 01:10:25 pal: I'm told that in DCinema 4digits years are displayed upright 01:12:33 cyril: Netflix's style guide says do not use combine for more than 2 characters 01:18:09 -> https://github.com/w3c/jlreq/issues/109 JLREQ issue 109 01:20:32 -> https://github.com/w3c/i18n-activity/issues/726 i18n issue 726 01:23:47 Topic: break until 1045 01:49:31 https://github.com/w3c/charter-timed-text/issues 01:52:35 glenn has joined #tt 01:52:35 Topic: IMSC 1.1 issues 01:52:37 scribe: atai 01:53:12 Topic: forcedDisplay and visibility="hidden" imsc#484 01:53:18 github: https://github.com/w3c/imsc/issues/484 01:53:55 Nigel: This was discussed in CSS WG and with APA 01:54:28 ...there is a view that CSS speech spec is tended for this kind of purpose 01:55:33 -> https://www.w3.org/TR/css3-speech/#speaking-props-speak speak css property 01:55:35 ...erika from CSS WG Commented if you set visibility to hidden but speak property ? it is supposed to be sent to the screen reader 01:56:02 ...it was not clear from me from the spec that it should behave that way 01:56:12 gkatsev: spec is ambiguous 01:56:29 Nigel: I now think there is something needed 01:56:29 cyril has joined #tt 01:57:02 ...CSS WG had volunteers to look at it 01:57:25 gkatsev: Currently this is defined in CSS3 speech 01:57:45 nigel: It is a buggy spec 01:58:07 rrsagent, pointer 01:58:07 See https://www.w3.org/2019/09/18-tt-irc#T01-58-07 01:58:24 rrsagent, draft minutes 01:58:24 I have made the request to generate https://www.w3.org/2019/09/18-tt-minutes.html cyril 01:58:25 ...values for speak property are possibly wrong 01:58:59 gkatsev: The alway value is confusing and needs update 01:59:25 nigel: they may have thought of the difference between visibility and display but it is not clear 02:00:02 ...action: we need to wait for the result of the a11y task force 02:00:13 ...after we have an outcome we can see what to do next 02:00:44 glenn: in ttml we ended up merging the properties 02:01:07 ...we have values like normal, fast 02:01:22 Nigel: There is a difference in CSS: 02:01:48 ...if you use speech representation that is how it should be styled 02:02:07 glenn: I thought auto is display none 02:02:51 Nigel: The idea in for CSS speak that you can direct screen reader for audio representation even if they 02:03:02 ...do not have a pixel representation 02:03:46 ...I now see that is a retired note in annotation in the spec 02:04:33 Summary: Wait what the CSS a11y TF come up with 02:05:25 Topic: Support `#font` TTML2 feature #imsc472 02:05:41 s/merging the properties/merging voice-rate semantics into tta:speak/ 02:05:44 github: https://github.com/w3c/imsc/issues/472 02:06:20 ericc has joined #tt 02:06:33 Nigel: It is about font feature in IMSC 1.1 02:06:40 s/I thought auto is display none/.../ 02:06:46 ...Pierre question is about ressource limit 02:07:29 pal: questions: 02:07:35 ...should processors support a minimum set of font formats 02:07:45 ....should @type be limited to a certain set of values? 02:07:52 ...should the number of resources be limited in a document? 02:07:58 ...should the size (in bytes) of each resource be limited? 02:08:10 ...regarding should @type be limited to a certain set of values? 02:09:04 ...my recommendation is to not require to constraint @type but the browsers need to support a minimum list of font ressources 02:09:35 ...for the start of the spec the limit for the number of ressources my proposal is 2 02:09:46 Nigel: Why should we limit? 02:09:54 pal: Download time 02:10:25 cyril: we could make a difference between the number of ressources in the document 02:10:36 ...and the number that should be loaded at begin time 02:11:09 pal: do we have a strategy of effective font loading in ttml 02:11:49 glenn: we have a strategy and named it 02:11:59 ...lazy loading in our discussion 02:12:12 ...it is an implemenation dependent feature 02:12:47 Nigel: Number of number font elements can be restricted 02:13:48 ...you expect each one font element just one font ressource to be loaded 02:14:18 ...if you want to restrict it you should restrict number of font element 02:16:02 glenn: I would not like to constraint neither font element nor ressources 02:16:35 ...the application can decide on the basis the referenced font information what to fetch 02:17:23 pal: if you use fetch mechanism you can make the limitation bytes 02:17:48 ...the downside of fetch it requires full processing of the document 02:18:08 ...full processing like styke resolution etc. 02:18:35 glenn: This is a constraint you can only test during presentation processing 02:18:45 glenn: coult it be a constraint in the HRM 02:18:49 pal: yes 02:19:14 ...as info: digital cinema sets fetch limit to 10 MB 02:19:28 ...spoke with adobe colleague 02:19:42 ...this is no coincidence 02:20:02 ...it just works there 02:20:38 atsushi: In Japan we provide only a subset of a font 02:20:46 ...this limits the size 02:21:07 cyril: I don't think that we at netflix we would do font subsetting 02:21:08 Zakim has left #tt 02:21:30 ...especially for the first episode you have to provide all 02:21:49 Zakim has joined #tt 02:22:36 glenn: noto sans font 8.6 mb for simplfied chinese 02:23:04 gkatsev: We can start with 10 MB and then see if anybody is complaining 02:23:17 ...in that case we increase the limit 02:24:08 Pal: everybody agrees to have 10 MB as limit 02:25:05 PROPOSAL: For FPWD limit fetched font resource to 10 megabytes 02:25:12 Nigel: Any objections? 02:25:22 RESOLUTION: For FPWD limit fetched font resource to 10 megabytes 02:25:39 pal: Constraint on @type 02:25:48 ...my suggestion no constraint 02:26:39 ...but require IMSC to support minimum set of font formats 02:27:32 PROPOSAL: no constraint on @type but IMSC processors need to support minimum set of font formats 02:27:52 RESOLUTION: No constraint on @type but IMSC processors need to support minimum set of font formats 02:28:05 pal: But...which font format? 02:28:07 i/RESOLUTION: Nigel: Any objections? 02:28:14 ...we need to be careful 02:28:19 i/RESOLUTION: /Nigel: Any objections? 02:28:26 s|i/RESOLUTION: Nigel: Any objections?|| 02:28:31 ...there are couple of formats woff woff2... 02:28:38 i/RESOLUTION/group: [no objections] 02:28:54 ...I have not the expertise to decide what is hard not hard 02:30:12 cyril: We need one compressed and one uncompressed format 02:30:30 Nigel: There is an example in the DVB spec 02:30:31 https://caniuse.com/#search=woff 02:30:43 OTF's SVG table defined at https://docs.microsoft.com/en-us/typography/opentype/spec/svg 02:32:24 ...font download it supports OFF (Open font format) and WOFF 02:32:34 ...that is where I would start 02:32:42 cyril: we can discuss about woff2 02:32:50 ...it is broadly supported 02:33:24 ...and compresses better 02:33:28 andreas: It would be good to get a view from Vladimir Levantovsky from Monotype who is a member of this group too. 02:34:04 pal: we wanted to specify requirement of processorts 02:34:54 s/processorts/processors/ 02:36:18 cyril: we should constraint it to not support svg-outline 02:37:05 PROPOSAL: Require minimally processor support for font/otf with cff and ttf (i.e. no svg outline) plus woff 02:37:20 Nigel: Any objections? 02:38:08 RESOULTION: Require minimally processor support for font/otf with cff and ttf (i.e. no svg outline) plus woff 02:38:24 s/RESOULTION/RESOLUTION 02:38:54 gkatsev: woff2 has 30% better compression (as a data point) 02:40:30 cyril: about unicode range 02:41:26 ...I am satisfied with the current solution in Pierres PR 02:42:08 nigel: I have an example with two fonts and different sources 02:42:14 ...but overlapping sources 02:42:23 ...should we constraint this? 02:42:34 ...is there a use case for this? 02:42:54 glenn: Usually we leave it to the implementation what make sense 02:43:40 pal: In this case we constraint the size of fetch ressource 02:44:03 ...are we asking the implementation to find out the minimum set need 02:44:08 ...seems complicated 02:45:43 glenn: we have font slelection strategy in in TTML2 02:46:00 nigel: this is orthogonal to this discussion 02:46:40 pal: what we can do 02:47:01 ...we can forbid different fonts with the same font family 02:47:46 nigel: we may have different fonts and ressources for the same font family because they are for different faces 02:48:01 ...e.g. bold, italics ... 02:48:50 Nigel: we can try to constraint font family together with different properties like weight 02:49:35 pal: how do unicode range goes together with fetch 02:50:27 ...it needs to be validated by the processor when the size is exceeded 02:50:48 ...the typical usecase is one font and one font family, right? 02:51:42 Nigel: 02:52:21 atai: NPO in Netherlands have the requirement to have two fonts in one document (one for Arabic and one for Dutch version of the subtitle) 02:52:59 pal: even if you have two fonts it make sense 02:53:34 ...to constraint the combination for ranges, family, stylee and weight 02:54:05 s/stylee/style/ 02:55:51 Nigel: I see two propsoals 02:57:36 ...you forbid to have unicode range overlab between different font elements with the same values for font famliy, style and weight 02:57:45 ...or to have no constraint 02:58:31 glenn: There may have identical font elements with different kerning tables 02:58:46 pal: you can forbid that 02:59:25 https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#font-style-matching 03:00:43 glenn: I would recommend that implementation follow the algorithm defined by css 03:01:47 the HRM should use this algorithm 03:01:56 pal: this would solve that issue 03:02:40 glenn: ttv does some (not all) HRM checking 03:02:48 ericc has joined #tt 03:03:17 nigel: You can not specifiy the HRM constraint 03:03:55 ...you can not statically validate this as font resssouces may change dynamically 03:04:54 pal: idea of hrm is to provide basic guidlines so things are going to work 03:08:57 see https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#composite-fonts for text on handling overlapping ranges 03:09:47 s/overlab/overlap/ 03:09:51 PROPOSAL: Unicode range overlab between different font elements are permitted even they have identical values for style, family and weight 03:10:10 Nigel: Any objection? 03:10:13 No objections 03:10:43 Resolution: Unicode range overlap between different font elements are permitted even they have identical values for style, family and weight 03:11:14 TOPIC: IMSC 1.1 FPWD 03:11:16 s/overlab/overlap/ 03:11:35 rrsagent, please draft minutes 03:11:35 I have made the request to generate https://www.w3.org/2019/09/18-tt-minutes.html atsushi 03:12:55 Proposal: Once we merged the open PR we go to PPWD 03:13:01 Nigel: Any objections? 03:13:03 s/PPWD/FPWD 03:13:05 No objections 03:13:24 Resolution: Once we merged the open PR we go to FPWD 03:13:39 s/PPWD/FPWD/ 03:13:47 s/IMSC 1.1/IMSC 1.2 03:20:00 Topic: Lunch 04:02:46 atai has joined #tt 04:03:37 atsushi has joined #tt 04:05:16 Topic: Live Extensions 04:05:40 scribe: gkatsev 04:06:00 nigel: [pulls up repo] 04:06:11 nigel: there's a few things we need to cover 04:06:26 ... last time we talked about it pal asked for some offical communication from EBU 04:06:30 ... they had already done so 04:06:37 ... in the reflector 04:07:05 ... I've taken on the role of editor 04:07:21 cyril has joined #tt 04:07:22 pal has joined #tt 04:07:32 ... three docs 04:07:38 ... 1. one is normative part 04:07:44 ... 2. live carriage 04:07:50 ... 3. live extensions guide 04:07:58 ... take first two to req and 3rd one as a note 04:08:03 glenn has joined #tt 04:08:36 rrsagent, pointer 04:08:36 See https://www.w3.org/2019/09/18-tt-irc#T04-08-36 04:08:42 ... atsushi: how do you do PR preview in repos with respect to make it easier to review 04:08:54 atsushi: there is a tool for preview 04:09:07 nigel: how to make it work with multiple docs in the same repo? 04:09:14 inamori_ has joined #tt 04:09:39 ... maybe pr-preview can be configured 04:09:44 ... can you look into it, atsushi? 04:09:47 atsushi: yes 04:10:07 nigel: currently no PRs or issues against it, only editorial notes 04:10:25 ... as a reminder, the scope is for contribution of live streamed subs to distribution encoder 04:10:40 ... the idea is not that these extensions would apply to a wide number of users 04:10:57 ... if you've got an IMSC distribution encoder with a live distribution mechanism such as HLS or DASH 04:11:04 ... this provides a way to get the content to that 04:11:19 ... approach taken is to define some extension features 04:11:25 ... key things are: 04:11:42 ... introduces concept of a sequence with an identifier and number 04:11:49 ... to resolve temporal issues 04:12:01 ... tt-live is the main specification 04:12:10 ... has anyone reviewed it? 04:12:22 atai: yes 04:12:26 others: no 04:12:39 atai: I have comments on the basic structure 04:12:53 nigel: let me continue briefly and hear it late 04:12:57 s/late/later/ 04:13:06 nigel: describes temporal overlap resolution mechanism 04:13:21 ... defines processing semantics which are important for usecases in the scnearios of live 04:13:32 ... the ability to delay delivery of documents or time within documents 04:13:35 ... handling reference clocks 04:13:44 ... the ability to hand over between subtitlers 04:14:00