- From: David Ronca <dronca@netflix.com>
- Date: Mon, 2 Apr 2018 07:05:57 -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-Fjrd5uMqj8ioPJ-P2jo2-n3jUeEJaE4xKdXsOAfWMPcNg@mail.gmail.com>
> 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 14:06:31 UTC