- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 28 Feb 2019 17:32:20 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D89DCB95.3E117%nigel.megitt@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2019/02/28-tt-minutes.html In text format: [1]W3C [1] http://www.w3.org/ Timed Text Working Group Teleconference 28 Feb 2019 [2]Agenda [2] https://github.com/w3c/ttwg/issues/20 See also: [3]IRC log [3] https://www.w3.org/2019/02/28-tt-irc Attendees Present Cyril, Glenn, Gary, Pierre, Nigel, Andreas, Philippe Regrets Thierry Chair Nigel Scribe Cyril, nigel Contents * [4]Topics 1. [5]This meeting 2. [6]TTML Profile Registry Actions, Pull Requests and Issues 3. [7]TTWG Future requirements 4. [8]TTML in RTP IETF submission 5. [9]WebVTT Implementation Report 6. [10]TTWG Charter 7. [11]Hosting additional test/example resources 8. [12]TTML to WebVTT Mapping - new issue 9. [13]F2F poll 10. [14]Mercurial decommissioning 11. [15]ITU-R BT.2342 Update 12. [16]DST upcoming times 13. [17]Possible liaisons with MPEG and VR-IF about 360º subtitle positioning 14. [18]Meeting close * [19]Summary of Action Items * [20]Summary of Resolutions __________________________________________________________ <cyril> scribe: Cyril This meeting nigel: there are lots of AOB today ... profile registry, future reqs (probably nothing), TTML in RTP ... WebVTT ? gkatsev: yes nigel: charter draft, some issues with a PR ... a new issue on TTML and WebVTT mapping, poll on F2F ... historical content on mercurial ... tiny update on an ITU doc ... reminder that DST is coming to the US ahead of Europe, so meeting time shuffling needed in March atai2: possible liaisons with MPEG and the VR-IF regarding subs in VR/360 TTML Profile Registry Actions, Pull Requests and Issues nigel: thank you Glenn for getting conclusions on the previous PR, just merged ... we need some reopening discussions with the section that describes possible way of discovery ... section 4.2 ... glenn opened PR 53 that deletes the whole section ... I thought we agreed to move it to an informative annex [21]https://github.com/w3c/tt-profile-registry/issues/53 [21] https://github.com/w3c/tt-profile-registry/issues/53 glenn: there are 2 reasons to delete the section ... 1) the leading sentence is misleading at best ... it's possible that we define an algorithm not in TTML today ... but I don't want to define another one and leave it up to implementation ... if we do, we need to qualify the utility of this ... 2) it introduces another table ... that creates long-term maintenance issue ... it creates a second registry that has questionnable use ... overall, best to remove it ... seems in accordance to make the document shorter <Zakim> nigel, you wanted to note that if we keep 4.2 then we need to say it applies to content profiles not processor profiles nigel: definitely I would concur that it is confusing ... the document as a whole talks about processor profiles ... but that section seems to talk about content profiles ... and we don't talk about it ... on the point of maintenance, I don't think that's a strong point ... I don't see that as a prime factor ... the question is: is this table useful at all <nigel> scribe: nigel Cyril: I agree with Glenn, remove the section, make the document lean. <scribe> scribe: cyril nigel: any other views? ... proposal is to remove 4.2 ... any objection? ... anyone wanting to keep it in one form or moving it ... silence ... the proposal is adopted ... I will amend my PR comment glenn: that will remove a comment from cyril, we can close 2 or 3 issues as a side effect nigel: summary is there is still a bit of editorial work to solve the remaining issues glenn: I'll crunch through those ... mike asked an IANA review ... to resolve that one we'll have to get external review ... the codecs parameter is new nigel: no, it was in TTML 1 2nd edition ... the IANA page already includes codecs pal: let's not change at all if possible, no editorial change nigel: none of the PR have done so pal: great news nigel: we should treat that as a constraint for the future PR ... anything else? ... no TTWG Future requirements nigel: anything to say? ... to raise about that? TTML in RTP IETF submission nigel: 4th draft has been added <nigel> [22]latest draft [22] https://datatracker.ietf.org/doc/draft-sandford-payload-rtp-ttml/ nigel: this should resolve all the comments that we raised ... section 8 says no IANA action ... the one thing that we haven't fully concluded ... is the codecs parameter ... we now have a requirement that says it shall be in the SDP ... glenn if you could have a look at that and confirm that it removes the need for anything else glenn: ok nigel: we welcome any other feedback WebVTT Implementation Report gkatsev: after last week's meeting, I met with Silvia to talk about at risk stuffs ... we identified a couple of things to be marked at risk ... the style block is only supported by Safari and polyfilling is tricky and cannot be done on time ... collision avoidance with snap to line false ... and also some selectors ... if we remove those items from the rendering tests, we can reach 99% completion ... I'm going to work on marking those at risks and getting a new spec snapshot ... FF has basic support ... for regions ... and VLC has it too, so we have interop ... in FF, they have chosen to give a default background to boxes but Safari and VLC have not plh: is FF following the spec? gkatsev: yes pal: I think either Chrome or FF are not following the spec regarding opacity ... I don't know how precise we want to be ... what the threshold is for passing nigel: what does the spec say about the background of regions atai2: thank you gkatsev for the update ... what does basic support for FF mean? what is the target? ... do they complement each other? gkatsev: the reason I'm saying it has 'basic' support ... it's because all the tests pass ... but for the scroll tests, the sizing in FF is a bit unexpected (not incorrect) ... but you can see a portion of the first cue as it goes out of the region ... it's not perfect ... but I think it is still within tolerance ... and just filed as an implementation bug nigel: does the spec talk about clipping gkatsev: I don't think so nigel: so then it would seem acceptable gkatsev: I'll verify ... everything else that I looked at, nothing is not implementable ... VLC is not implementing some of the style stuffs because it is allows ... at risk are: cue selector function with *, cue pseudo selectors with past and future ... collision avoidance with snap to line false ... and style block within the VTT file ... and cue selectors with region nigel: the style part is a big deal plh: why? nigel: because video only players like VLC would have no way to set styles ... no mechanism inside the document gkatsev: VLC has chosen not to implement that ... and the spec says that if you don't have a style engine you can pal: do the current tests adequately represent the spec? ... that's discussion a ... and discussion b is: is the spec adequate for some use cases? ... a) is very mechanical ... you check 2 implementations for each feature ... b) is a lot more complex plh: my thinking is that we need to publish ASAP with the features at risk ... if the group is OK we should give him power to do that ... then regarding styling and accessibility, we cannot answer before publication anyway ... but we can ask accessibility people atai2: I agree with plh and pal ... if a feature is not implemented it needs to be removed ... but nigel point is also valid ... we have a lot of implementations using HLS and if there is no way to have styles ... that's a significant issue for accessibility [if colours cannot be used to indicate speakers] ... if it's not implemented what can we do nigel: to respond to plh's point, I think this group's job is to think about accessibility ... it is within our charter ... we can make the call to accept or not the features at risk because of accessibility ... we need consensus on the at risk list plh: the spec does already allow not to implement the style part today nigel: I don't think that's right plh: yes, there is a class of conformance without CSS <plh> "All processing requirements in this specification apply, except parts of §6 Parsing that relate to stylesheets and CSS," <nigel> scribe: nigel Cyril: We don't have a choice, either we publish what is implemented or we don't publish. ... We can't change what is implemented today, it is too late, whether or not we like it. <scribe> scribe: cyril gkatsev: we can mark things at risk that today don't meet the criteria, but we can decide later if we remove or not ... the style block is something we can polyfill but we need more time ... we could potential meet the 2 implementations goal ... for VLC, from what I understand, because they don't have a CSS engine, they are not implementing the style block ... this is really CSS inside the file pal: what's missing is a WebVTT spec that reflects reality ... it's a reasonable plan to take the spec, identify at risk, publish that ... if removal of a feature creates deficiencies for accessibility, those can be noted ... and then we can decide on what we do ... I'm a pretty big proponent to have a spec that matches reality nigel: plh posted some text on style ... if we mark at risk and meet exit criteria, the group would have agreed to publish without the feature ... we need to think very hard about allowing publication without any styling at all ... if you cannot indicate colors, I would need to think hard about it and would probably object: it would mean that WebVTT cannot be used to meet the accessibility requirements of the UK's audience. pal: if the spec does not meet all criteria, maybe that could be acceptable plh: if you look at HTML, it does not say you have to implement CSS ... I don't see why we should have a different approach ... I agree the experience would not be a pleasant one or acceptable one ... but we don't require a specific profile of CSS to be implemented with HTML ... what we are doing today is marking at risk ... we would be blocking ourselves to start discussing if we remove it or not today ... there may be a case to make to keep the style box ... there are lots of engines out there <nigel> scribe: nigel Cyril: The goal is to publish what is implemented today, ... it doesn't mean that it requires BBC to implement it, there are other choices. ... Publication does not endorse the feature set, we can say it reflects reality. ... It's better than not having a spec. <scribe> scribe: cyril nigel: Gary, please circulate a detailed proposal of what you want to mark at risk and we'll discuss again TTWG Charter nigel: I've been reviewing the draft charter ... and the issues ... PR40 ... plh we need to enable PR preview on this one plh: usually we don't on small repo, but sure nigel: PR40 is adding wording for TTML3 and module approach ... please have a look at if that works and look at the CSS charter for reference ... I've tried to adapt that "prior art" ... one question: there is a template section for adopting working drafts ... ... are they required? plh: yes if they have been published, otherwise use the ED and don't add the call for exlusions nigel: please look at the current draft and raise issues - I'll try to open pull requests next week Hosting additional test/example resources nigel: we made a bit of progress offline ... summary is that we are working out what we do with the video resources plh: we don't need to solve that right now on this call ... are they BSD? pal: Yes, they are referenced from the repo and have the same license as on the repo plh: I'll check with Wendy ... regarding the forking, I'm ok with it ... you'll check when you want to merge pal: let me know as soon as you can if any additional info is needed by fox TTML to WebVTT Mapping - new issue nigel: John Birch noticed a possible error and raised an issue ... anyone wanting to take the editorial role and fix the document? ... if so, please get in touch with me atai2: we said the document is on hold ... but I think I'm still one of the editor ... it's really out of date ... I'm not sure what sense it would have to fix just one error ... not sure what use it has right now ... I did not review the issue ... I assume the fix is small F2F poll nigel: still open until 23:59, Boston time on 2019-03-07 ... but I noticed while looking at our charter that says we will meet at TPAC ... which means at least I should arrange a meeting for TPAC ... I raised an issue about the charter in case we need <nigel> [23]WBS Poll [23] https://www.w3.org/2002/09/wbs/34314/2019_September-F2F/ <nigel> scribe: nigel Mercurial decommissioning Nigel: I'll send a message to the reflector - if there's anything of ours on Mercurial still that we need to migrate, please ... let me know. Pierre: Let's make a backup and store it somewhere Philippe: We're going to have access to zip files of the repos themselves. ... That's already provided. Worse case scenario is download that zip file. Pierre: Thanks Nigel: That's good to know, thank you. ITU-R BT.2342 Update Nigel: I'm in process of submitting an update to the above ITU document to bring it up to date, to be considered in ... the March ITU-R meeting. ... For info only. DST upcoming times Nigel: The US is entering DST soon, a while before Europe so I'll propose new UTC meeting times hopefully to ... minimise disruption. Pierre: For the meeting at TPAC, is the goal still to determine following March 7 the final plan based on the poll, ... regardless of the Charter? ... For those attending IBC there will be significant international flight gymnastics and we have to set the date soon. Philippe: We're rechartering between now and TPAC. Pierre: Understood, thanks. Nigel: My plan is to agree after March 7, yes. ... The draft Charter would need a pull request. Philippe: I can tell you that rule is not actually enforced! Possible liaisons with MPEG and VR-IF about 360º subtitle positioning Andreas: Let's discuss this next week. Meeting close Nigel: Thanks everyone, apologies for running 5 minutes over. [adjourns meeting] Summary of Action Items Summary of Resolutions [End of minutes] __________________________________________________________ Minutes manually created (not a transcript), formatted by David Booth's [24]scribe.perl version 1.154 ([25]CVS log) $Date: 2019/02/28 17:28:46 $ [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [25] http://dev.w3.org/cvsweb/2002/scribe/ ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ---------------------
Received on Thursday, 28 February 2019 17:32:46 UTC