- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 02 Apr 2018 21:46:33 +0000
- To: David Ronca <dronca@netflix.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, Philippe Le Hegaret <plh@w3.org>, Public TTWG List <public-tt@w3.org>
- Message-ID: <CAHp8n2mUN-njM-M5Cay5VSjTxay7jCRpodV061_-2t=Wb+AyQg@mail.gmail.com>
Excellent. That will make it easy for webvtt to pick it up. Thanks, Silvia. On Tue., 3 Apr. 2018, 6:52 am David Ronca, <dronca@netflix.com> wrote: > > ... features are natively supported in html/CSS as well? > > html/css support is not complete, but fairly close, and the CSS groups has > indicated a willingness to address the missing features. We have an > internal TTML2->CSS implementation that has been well tested and seems to > cover JA subtitle feature set reasonably well, but not always a clean > mapping. > > On Mon, Apr 2, 2018 at 1:32 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com > > wrote: > >> Hi David, >> >> This is amazing! Thanks for sharing that blog post. I've not been able to >> get this much detailed information on what the requirements are around >> subtitles in Japanese before. Did you with with the i18n group on making >> sure all these features are natively supported in html/CSS as well? >> >> I think the current webvtt specification supports most of these features, >> apart from the slanting, but we would need to do a proper assessment and >> write proper test files. >> >> I'll add an issue in GitHub for it - it should be in the list for webvtt >> v2. >> >> Kind regards, >> Silvia. >> >> >> On Tue., 3 Apr. 2018, 12:05 am David Ronca, <dronca@netflix.com> wrote: >> >>> >>> > defined as "essential Japanese subtitle features"? >>> We define the essential Japanese features in this techblog >>> <https://medium.com/netflix-techblog/implementing-japanese-subtitles-on-netflix-c165fbe61989>, >>> which is based on a presentation and paper that we shared with TTWG. This >>> is based on our work to launch in Japan, and a rather large set of JA >>> subtitle assets. >>> >>> On Mon, Apr 2, 2018 at 1:55 AM, Silvia Pfeiffer < >>> silviapfeiffer1@gmail.com> wrote: >>> >>>> Hi David, >>>> >>>> What I meant was that Microsoft only supports a minimal feature set >>>> which is about as much as SRT. There's no official definition of >>>> "minimal feature set". The other browsers support more with Chrome and >>>> Mozilla basically everything except for scrolling regions. All Apple >>>> implementations are close to complete. >>>> >>>> About ruby support: it's as good as HTML's ruby support for now. >>>> >>>> Counter question: what is defined as "essential Japanese subtitle >>>> features"? >>>> >>>> Cheers, >>>> Silvia. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Apr 2, 2018 at 4:33 PM, David Ronca <dronca@netflix.com> wrote: >>>> >> 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 21:47:12 UTC