- From: David Ronca <dronca@netflix.com>
- Date: Sun, 1 Apr 2018 23:33:22 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, Philippe Le Hegaret <plh@w3.org>, Public TTWG List <public-tt@w3.org>
- Message-ID: <CAMjV-FhBq6NQR+htPmLKukMHJXQksg09F5p+DHcM+dqAjWUhag@mail.gmail.com>
> because the browsers don't provide sufficient support (specifically Microsoft's browsers - the others support the minimal feature set) How to reconcile this with David Singer's statement that "*VTT is supported in all major browsers"? *Also, the how is "minimal feature set" defined. Must be more than SRT, I expect. I am especially curious about WebVTT support for Japanese subtitles. We have not seen a WebVTT implementation that can properly the essential Japanese subtitle features. Is there such an implementation that someone can point us to? On Thu, Mar 29, 2018 at 7:55 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Congratulations on the resolution for webvtt to move to CR! I'll help > where I can. > > About the question of interest: many video player publishers had to write > their own webvtt interpreters & renderers because the browsers don't > provide sufficient support (specifically Microsoft's browsers - the others > support the minimal feature set). At FOMS we consistently hear the request > by the player vendors and content publishers who don't want to have to > write and maintain their own captioning library but the state of > implementation in browsers is a problem. It's a chicken and egg thing and > it's my hope that a push for CR/REC will change that. > > I hope this helps. > > Cheers, > Silvia. > > On Fri., 30 Mar. 2018, 3:25 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/2018/03/29-tt-minutes.html >> >> In text format: >> >> [1]W3C >> >> [1] http://www.w3.org/ >> >> Timed Text Working Group Teleconference >> >> 29 Mar 2018 >> >> See also: [2]IRC log >> >> [2] https://www.w3.org/2018/03/29-tt-irc >> >> Attendees >> >> Present >> Cyril, Pierre, Nigel, dsinger, Thierry, Philippe >> >> Regrets >> Andreas >> >> Chair >> Nigel >> >> Scribe >> nigel >> >> Contents >> >> * [3]Topics >> 1. [4]This meeting >> 2. [5]F2F meetings >> 3. [6]TTML1 3rd Edition CR >> 4. [7]IMSC >> 5. [8]Update feature list per TTML2 imsc#350 >> 6. [9]Clarify the use of recommended character sets >> imsc#354 >> 7. [10]TTWG Charter >> 8. [11]WebVTT >> 9. [12]TTWG Charter >> 10. [13]Travis >> 11. [14]Audio Profile of TTML2 >> 12. [15]Meeting Close >> * [16]Summary of Action Items >> * [17]Summary of Resolutions >> __________________________________________________________ >> >> <scribe> scribe: nigel >> >> This meeting >> >> Nigel: Next week I'm able to make the call, but the week after, >> the 12th, I can't. >> >> Cyril: I also can't make the 12th. >> >> Pierre: Regrets for me for the 19th. >> >> Nigel: For today, we have TTWG Charter, if there's more to >> discuss on that - will wait for >> ... staff to join before confirming. >> ... We also have TPAC, and a possible F2F in Munich in May, >> ... TTML1 3rd Edition CR needs to be discussed. >> ... Not sure if there's anything to discuss on TTML2. >> ... For IMSC there is one agenda point, a pull request, which >> we may be able to resolve with >> ... a brief conversation. >> ... If we have time we can go through the IMSC vNext Reqs pull >> requests, which have been >> ... open for a while. >> ... I don't think there's anything to discuss on CSS. >> ... Do we have something for WebVTT? >> >> David: Yes, we should approve the transition to CR. >> >> Nigel: Any preferences about what order we do these in? >> >> Pierre: I'd really like to close the IMSC ticket, because it is >> blocking CR. >> ... If there's anything missing on that push-back on TTML1 we >> should address that ASAP. >> >> Nigel: We should be able to get through everything today - >> we're scheduled for 2 hours. >> >> F2F meetings >> >> Nigel: Thierry wants us to discuss if we wish to meet at TPAC >> in Lyon, which is at the end >> ... of October this year. >> ... I expect us to be getting towards the end of our Rec >> transitions for all our specs at that >> ... time, but I expect there will be a lot to discuss, so I >> propose that we ask for what we >> ... usually ask for, i.e. 2 days. >> >> Pierre: Sounds good. >> >> Nigel: Okay, I'll complete the WBS for TTWG asking for that. >> ... There will be a request for any groups we don't want to >> clash with, or want to have joint >> ... meetings with. I would at least propose that we ask for a >> joint meeting with CSS WG like >> ... we did last time, on the basis that we expect to have made >> some progress. >> ... Any other thoughts? >> >> group: [silence] >> >> Nigel: The next proposal is that we have a f2f on May 22 and >> 23rd at IRT in Munich. Andreas >> ... has kindly offered to make space available there before the >> IRT subtitle technology symposium, >> ... and I think the timing will be good to iterate over TTML2 >> and IMSC 1.1 tests for the test suite. >> >> Cyril: I might be able to make that. >> >> Pierre: It's unlikely I'd be able to make it. >> >> Nigel: Okay, I'll send an email round about this; for now it is >> a proposal. I think if we >> ... intend to talk about test suites we need the right people >> in attendance. >> >> TTML1 3rd Edition CR >> >> Nigel: We submitted the transition request to CR for TTML1 >> Third Edition and Ralph >> ... responded expressing surprise that no new tests have been >> created to verify that implementations >> ... conform to the clarifications and error corrections. He >> asked if the test suite has been >> ... updated at all. He's basically asking us to update the test >> suite to demonstrate it. >> >> Pierre: I think it only needs to be updated selectively to >> cover the areas changed. >> >> Nigel: I think that's right. >> >> Pierre: I think that's possible to do. >> >> Nigel: I think if we're claiming that implementations meet the >> updates already then we need >> ... to provide evidence. >> >> Pierre: My recommendation is to change the SOTD to include exit >> criteria that require >> ... passing tests, and then create those test suites. >> Alternatively I could provide GitHub >> ... pointers to issues on imsc.js, but that might be a lot of >> work with no guarantee of success. >> >> Nigel: That would work. >> ... If we're going to do that we need to make the updates and >> re-file the transition request. >> >> Pierre: I'll make the SOTD updates. >> >> Nigel: When that's done, please let me and Thierry know so >> Thierry can update the transition request. >> >> IMSC >> >> Nigel: we have one pull request on the agenda. >> >> Update feature list per TTML2 imsc#350 >> >> github: [18]https://github.com/w3c/imsc/pull/350 >> >> [18] https://github.com/w3c/imsc/pull/350 >> >> Nigel: I think the main issue here is the syntax permitted for >> tts:extent. >> ... I don't understand why the `auto` value is permitted for >> `tts:extent` on `tt:tt`... >> >> Pierre: It was permitted before. >> >> Nigel: But has its meaning changed? It used to be defined as >> the Root Container Region, >> ... now it is defined as "contains" whose meaning is defined by >> appendix H. >> >> Pierre: When I went through this before I decided that >> "contains" ends up meaning the same >> ... as "auto" used to mean in TTML1 - it yielded the right >> outcome. >> ... Note that in IMSC pixelAspectRatio is prohibited, so >> "contains" resolves as the display >> ... aspect ratio of the root container region. >> >> Cyril: And the algorithm in H.1 and H.2 match? >> >> Pierre: Yes, if there's no DAR and PAR then it's H.1.1 which >> corresponds to TTML1 100% 100%, >> ... i.e. auto semantics. >> >> Nigel: So Pierre you're arguing that contain and auto resolve >> to the same so it is better to >> ... have a single syntax option rather than allow the >> semantically more precise "contain"? >> >> Pierre: Yes. >> >> Cyril: There may be cases where auto and contain resolve >> differently? >> >> Pierre: Outside the tt element, maybe, but on the tt element >> they are identical. >> >> Cyril: Yes, the spec says if the value is auto, and its the tt >> element, then it maps to contain. >> ... So they are equivalent. >> ... I think the constraint on IMSC is correct. >> >> Nigel: Okay, I'm persuaded. >> ... The next comment here is about extends and restricts. >> Pierre commented that >> ... there's no requirement for them, and presumably there's no >> benefit identified for them here? >> >> Pierre: No, I have not. >> >> Nigel: I can see that from an implementation perspective it may >> add a fair amount of code >> ... and tests to allow extends and restricts. >> >> Pierre: Also this new TTML2 syntax was not broken out as a >> specific feature designator. >> ... I think I raised an issue on TTML2 for that. >> ... Maybe later it will be made a feature and we can then >> refactor this text. >> ... It would be a lot clearer. >> >> Nigel: Ok, there are conflicts here but I'm happy to approve >> the changes. >> >> SUMMARY: @nigelmegitt to approve the pull request >> >> Pierre: The conflicts are super-boring, I'll fix those. >> >> github-bot, end topic >> >> Clarify the use of recommended character sets imsc#354 >> >> github: [19]https://github.com/w3c/imsc/pull/354 >> >> [19] https://github.com/w3c/imsc/pull/354 >> >> Nigel: You're waiting on someone from i18n on this, Pierre? >> >> Pierre: Yes, during the call people used the term "safe" but >> the comments were against that. >> ... Instead, I've proposed to use "common" and am waiting for a >> response on that. >> >> Nigel: That change was made on the pull request, but there's no >> comment about it, but >> ... there is on the issue? >> >> Pierre: Oh yes, I could prompt Addison to review with a comment >> on the pull request. I'll just do that. >> >> Nigel: I'm not sure what we can do more on this at the moment. >> >> Pierre: It is only a matter of finding the right terminology >> now, I think we're good on the rest. >> >> Nigel: Looks that way. >> >> SUMMARY: WG awaiting review feedback from i18n. >> >> Pierre: We should communicate to them that we plan to request >> transition to CR in 7 days >> ... so they need to come back soon if they have a strong >> concern. >> >> Nigel: That sounds like an action for me to send a message >> immediately after this meeting. >> >> github-bot, end topic >> >> TTWG Charter >> >> Thierry: Not much to discuss - I have submitted the draft >> charter to W3M, and I think they >> ... were supposed to review it yesterday but I have nothing to >> report yet. >> >> WebVTT >> >> <scribe> Chair: David >> >> David: At TPAC we looked at the transition request, and the >> actions requested have been >> ... done. We were waiting on closing out some issues on the >> spec which Nigel was unable >> ... to get to for the first few weeks of this year. My feeling >> is that the remaining issues can >> >> <dsinger> >> [20]https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133 >> .html >> >> [20] https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133.html >> >> David: be closed off in CR. I would like to ask for the formal >> agreement of the group to do >> ... the final transition. I sent the final draft of the request >> a couple of days ago. >> ... I updated the wide review page a couple of days ago to >> reflect the current status. I hope >> ... we're at the formal stages now - we had the [scribe loses >> track] >> ... There will likely be some changes to be made during CR, >> which are not major changes >> ... for implementors but may for example require a change to >> the computed CSS property value for something. >> ... I think we need an updated version of the spec with SOTD >> etc for CR, which Silvia and/or >> ... Thierry can do. >> >> <dsinger> The remaining edits are clarification, warning, and >> so on and don’t represent technical changes to the >> specification, so I think it’s safe to do them along with any >> other disambiguations needed by implementers during CR. >> >> Nigel: What I normally do at this point is ask Thierry what is >> needed now for the transition request? >> >> Thierry: For the SOTD there are a few things that need to be >> put in, first the exit criteria. >> ... From David's statement, that is like what we have been >> using within this group, 2 implementations >> ... for each feature, so that sound good. >> ... The second thing I have not seen are the features at risk, >> because there are some features >> ... that are not implemented like regions and some others. >> >> David: We discussed this, it's at the end of point 1, and as >> discussed, we don't want to drop >> ... them so we aren't marking them as at risk. They are not >> features to drop if they are not >> ... implemented. The group wanted to wait until they're >> implemented, and have no features at risk. >> >> Thierry: Okay. Another thing is for the test suite and the >> implementation report. Of course >> ... we have to fill the implementation report in later. We >> should have a link to a test suite >> ... or something if it is incomplete. >> >> David: Yes, that's also in the transition request, there's a >> fairly thorough test suite in >> ... web platform tests, which generates automated reports for >> browsers, and we're going to >> ... have work out how to do that for non-browser >> implementations during CR. That's for >> ... me and the group to do during CR. >> >> Nigel: We don't normally ask for that at this stage? >> >> Thierry: We don't need the whole thing, just a link to whatever >> is there. >> >> David: We believe it is pretty thorough at this point, I'm sure >> there are bugs that people will >> ... find during implementation work. >> >> Thierry: The last bit is the wide review, I guess it is done, >> we have a URI, and it will be up >> ... to the Director to review it. >> ... The last thing is WG approval for transitioning. >> ... I need a link to point to. >> >> PROPOSAL: Agree to the CR transition to WebVTT >> >> Pierre: For clarity, that's based on the gh-pages branch on >> GitHub? >> >> David: Yes, that's correct, Silvia will need to update that. >> >> Pierre: And all the licence and IPR issues have been addressed >> and there's not going to be >> ... any drama there? >> >> David: I don't think so, no exclusions have been filed so far >> and we asked for FSA from all >> ... the CG contributors. >> >> Pierre: And some of the contributions have been from the CG >> since then, or all from members of the WG? >> ... (after that commitment was received) >> >> David: Even if they came from the CG they did sign a CLA. The >> only issue would be if they >> ... contributed someone else's IPR and that's a door I don't >> know how to close. There's nothing >> ... that's giving me any anxiety. >> >> Pierre: So the next step is to create a CR branch for the group >> to review the final version. >> ... When will that be available? >> >> David: You'd like a formal branch in GitHub? >> >> Pierre: Normally that's what happens, so there's a formal >> document to review. >> ... I'm encouraging you to do this as soon as possible so there >> aren't any surprises? >> >> David: I'll see what we can do - is there anyone on the team >> who can help? >> >> Thierry: I can help on the SOTD of course. >> >> Pierre: I don't have any a priori objections, thank you for >> doing all this additional work. >> >> Nigel: I'd second Pierre's request, let's have the actual >> document that we are going to approve on the table. >> >> Thierry: It has to be a CR version for approval by the >> Director. >> >> Pierre: And to be clear, on the open issues you do not expect >> any formal objections? >> >> David: I'm not seeing any clouds on the horizon for the >> remaining issues. >> >> Nigel: Me neither. >> ... David, you've been clear that you have limited resource for >> chairing and editing. Will there >> ... be the effort available to make any changes and to work on >> it post-CR so that it can get >> ... to Rec? My concern is that it could linger in CR forever. >> >> <dsinger> PROPOSAL: The editor and the team to prepare the CR. >> The WG approves the CR transition, with said prepared CR to be >> presented to the Director for approval, using the transition >> request in >> [21]https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133 >> .html >> >> [21] https://lists.w3.org/Archives/Public/public-tt/2018Mar/0133.html >> >> David: I share your antipathy to specs staying in CR >> indefinitely, I would suggest that if >> ... we cannot get to Rec within the next Charter period then at >> that point we publish the >> ... spec as a Note and stop working on it in the WG. >> >> Nigel: Thank you, by time-boxing the CR that addresses my >> concern. >> >> Pierre: I think you can confidently create a CR ready spec and >> state a resolution to proceed >> ... with CR with this draft, intended to be the CR. >> ... Then there's no surprise. Otherwise we could take a >> resolution today, and in 2 weeks there's >> ... something objectionable to someone and then we restart the >> clock in 2 weeks. >> >> David: I was expecting the group to approve transition today. >> Thierry, can you prepare the >> ... CR version of the document today? >> >> <dsinger> Can Thierry do the pull request for the SOTD section >> in the next 24 hours? >> >> Thierry: I can work on it, and probably not in the next 2 >> hours, but tomorrow morning. >> ... We also need in the SOTD the date for earliest advancement >> beyond CR. Probably we can >> ... put 3 months or whatever. >> >> Nigel: Good point. >> >> Thierry: I propose at least 2 months. >> >> David: It's not going to happen for at least 6 months. We need >> implementations of the changes >> ... and of regions. Give it 6 months. >> >> Thierry: You don't need to do that, you can do it in 3 if those >> criteria are met. >> >> David: Okay, put 3 months then, that's fine. >> >> Philippe: Hello, I apologise for arriving late. >> ... I don't mean to derail this meeting, but I have one >> question. We have not started review >> ... of the TTWG charter already, but I have one question: How >> is WebVTT used on the web >> ... today? Not an implementation question, a usage question. Is >> it actually used on the web, >> ... or only as an input format so video services can do their >> own thing with captions. >> ... TTML is used as an input format, and then there's client >> side JS that takes that and displays >> ... the subtitles and captions at the right time. YouTube, >> Netflix and others don't use TTML or WebVTT, >> ... they use their own code to present the captions. >> ... So you don't need native implementation of captions. >> ... The second question is how are we going to be able to get >> out of CR for WebVTT? >> ... If my assumption is correct, there is no incentive for >> browser implementers to update >> ... their implementations. That's part of the questions that we >> are asking ourselves generally >> ... about the future of captions on the web. >> >> David: I agree a lot of captions are done with polyfills and >> HTML/CSS created on the fly. >> ... One of the issues with WebVTT is that it is not used for >> presentation. >> ... I do know that in [apple products] we take the WebVTT >> natively. [sorry, scribe subject to a lot of local background >> noise] >> >> Philippe: Ok, I didn't find any statistics, for example in >> Chrome, of how often the native >> ... implementations are used today. >> >> David: Okay, I'll try to find out. >> >> Philippe: The fear is that it is not used so we will never get >> to the top of the priority list for browsers. >> >> David: I share your concern, if you can do an adequate job with >> polyfills then who needs to >> ... do a native implementation. >> >> Philippe: Yes, that doesn't undermine it as an input format. >> ... For example I do not know if the WebVTT implementation >> natively would allow positioning >> ... of captions on the fly like YouTube allows. >> ... We may be chasing something that the market out there is >> not interested in having in terms >> ... of native implementation. >> >> David: Right. Yes. >> >> Nigel: In terms of resolutions, I think the next steps are to >> produce the CR version of the >> ... document and then for David as Chair to send a message to >> the group specifying the >> ... resolution that he believes has been made, and highlighting >> the review period under the >> ... group charter decision policy (which is 10 working days). >> >> Philippe: At the moment we could try to run the transition >> request in parallel as long as it >> ... is clear to the Director that there is an opportunity for >> the decision to be reversed. >> ... On the IPR question, if there's a question about CG/WG >> working, here it is the same >> ... as if a contribution comes in on the WG public mailing >> list, where we have to figure out >> ... how substantive the contribution is and address that. It >> doesn't change the risk >> ... associated with IPR in the spec that is not directly from a >> contributor. If you have concerns >> ... about that then we can engage with our legal team here and >> make an assessment. >> ... If you tell us that everyone who contributed is in the CG >> and the WG then we don't have >> ... an issue. >> >> TTWG Charter >> >> Philippe: A comment - the agreement you described before is >> that if you do not have Rec >> ... of WebVTT by the end of the next Charter then you would >> drop it. If the theory is correct >> ... that WebVTT is used as an input format rather than a native >> implementation then it would >> ... be no surprise if that happens. >> >> David: One question is if you would accept two implementations >> from Apple as being >> ... independent, because this is in fact the case. >> >> Philippe: Interesting question, I don't know the answer but I >> can ask and get back to you. >> >> Nigel: I have asked this recently, as an issue on the Process. >> >> Philippe: Yes, you would need to have some evidence that the >> two teams creating the implementations >> ... did so by interpreting the specification directly without >> any other communication. >> >> Nigel: Any other questions or comments on the Charter? >> >> Philippe: Not as far as I know. Thank you by the way for >> providing the draft Charter. >> >> Travis >> >> Philippe: I'm in communication with Travis to try to make the >> pull request smoother. >> ... I do not know why the repositories have been deactivated. >> We are reaching peaks of 60 concurrent >> ... jobs on travis at the moment and it keeps increasing. They >> are doing some of our jobs >> ... in batches and they can get delayed before they are even >> started. So there's both a delay >> ... and then a long queue before they run. So the plan is to >> conduct an experiment on travis >> ... to give them a bit of money to provide small guarantees and >> see how it affects our jobs >> ... being run. In parallel I've been talking to the web >> platform tests people because they are >> ... consuming more than half our jobs, just for testing >> purposes, and we cannot separate >> ... them because they are on the same organisation on GitHub. >> We're potentially considering >> ... moving them to a "separate" organisation on GitHub because >> that project is going to >> ... grow more and more. Then we can separate testing from >> production of recommendations >> ... more easily. Every time a pull request on WPT is done it >> triggers 12 concurrent jobs. >> >> Nigel: Thanks for that. >> >> Audio Profile of TTML2 >> >> Nigel: I've been in discussion with various organisations >> (we're up to 12 right now) about >> ... setting up a CG to produce a profile of TTML2 for audio >> description, and hope that will >> ... go ahead in the next few weeks. >> ... Just noting it here in case people want to join. >> >> Pierre: That's in a CG not the WG? >> >> Nigel: Yes, and hopefully bring it to a future iteration of the >> TTWG Charter when there is >> ... a document to work on. This is partly about WG mechanics - >> getting onto the Charter >> ... without a document as the basis of a specification seems >> harder these days, so this way >> ... we can have easy participation from the interested parties >> and then there's a path towards >> ... getting to Rec later, albeit one that requires more W3C >> membership in the case that the >> ... contributors are not currently members. >> >> Pierre: And the domain is all applications? >> >> Nigel: Yes, not only broadcast, also web, and not making any >> assumptions about where in >> ... the distribution chain any audio mixing might happen. >> >> Pierre: Thanks. >> >> David: What I did with WebVTT is I got a FSA signed by the CG >> participants - if you're >> ... expecting them to give IPR away for free then they don't >> get anything back. >> >> Nigel: Right, and I've highlighted this to the participants >> right from the beginning. >> >> David: It took me months to get this for WebVTT. >> >> Pierre: Yes, when the legal team looks at it things could take >> longer. >> >> Meeting Close >> >> Nigel: Thanks everyone! [adjourns meeting] >> >> Summary of Action Items >> >> Summary of Resolutions >> >> [End of minutes] >> __________________________________________________________ >> >> >> Minutes formatted by David Booth's [22]scribe.perl version >> 1.152 ([23]CVS log) >> $Date: 2018/03/29 16:23:30 $ >> >> [22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm >> [23] http://dev.w3.org/cvsweb/2002/scribe/ >> >>
Received on Monday, 2 April 2018 06:34:20 UTC