NETVC Workgroup Meeting Minutes IETF 102 - Montreal, CA 2018-Jul-19 15:50-17:50 EDT/UTC-4 https://datatracker.ietf.org/doc/minutes-102-netvc Chairs: Mo Zanaty, Matthew Miller Area Director: Adam Roach Agenda: Administrivia and Requirements (draft-ietf-netvc-requirements) - chairs Testing and Evaluation Criteria (draft-ietf-netvc-testing) - Thomas Daede xvc Video Codec Update (draft-samuelsson-netvc-xvc) - Jonatan Samuelsson Thor/AV1 Update/Comparisons (draft-fuldseth-netvc-thor) - Steinar Midtskogen Future Work/Direction Discussion - chairs ---------------------------------------- Administrivia and Requirements ---------------------------------------- Drafts: https://tools.ietf.org/html/draft-ietf-netvc-requirements Slides: https://datatracker.ietf.org/doc/slides-102-netvc-chair-slides Milestones for requirements and testing drafts are a little bit late but still doable. First two can be hit with slight adjustments: April 2018 - Requirements July 2018 - Testing But the big problem is the last three milestones which are lacking a single merged codec candidate and reference codebase. July 2018 - Codec Specification July 2018 - Single Reference implementation Dec 2018 - Storage Format Will discuss further at the end of the session. Requirements draft had minor changes to profiles. No further changes expected. Chairs will issue a last call for comments on the list. ---------------------------------------- Test and Evaluation Criteria ---------------------------------------- Drafts: https://tools.ietf.org/html/draft-ietf-netvc-testing Slides: https://datatracker.ietf.org/doc/slides-102-netvc-draft-ietf-netvc-testing Adam Roach (as AD): Next step is writing up and asking for publication? Thomas Daede: Yes Matt Miller (as chair): Chairs were planning on asking for last call either this week or right after this week. ---------------------------------------- xvc Video Codec Update ---------------------------------------- Drafts: https://tools.ietf.org/html/draft-samuelsson-netvc-xvc Slides: https://datatracker.ietf.org/doc/slides-102-netvc-xvc-video-codec-update Slide 5: Mo Zanaty: The RF baseline profile was an interesting development. That seems to make this much closer to the charter, my major question is how did you arrive at the subset of tools to define the RF baseline. And what, if any, IPR vetting was done to have confidence in that list. Jonatan Samuelsson: We have done a limited analysis of the IPR situation. We are focused more on finding the toolset that gives good performance and seem to be generally well known from a certain time back. We have not done a thorough IPR analysis. It is more relying on our process for dealing with licensing issues when they arrive. If we were to discover that actually there was someone who had a patent on a tool which we would not be able to provide under RF terms, then instead of using 25 tools, we would only use 24 after removing or disabling the patent-encumbered tool. Mo Zanaty: So the tools you have enabled is a rough stab at a set of tools that will perform good enough, and that you think will not have any issues. Jonatan Samuelsson: Yes. We were trying to find a good balance between the risk and performance, that is a good question. Slide 7: Jonathan Lennox: Can the royalty-free baseline be directly compared to other codecs? The draft only includes a comparison with full xvc? Jonatan Samuelsson: I didn't include it in the slides, or have the results. But we do have the runs on our AWCY instance [they don't need to do any new runs, it's just a matter of picking which pairs you compare]. Slide 9: Thomas Daede: I was looking at the codebase and couldn't find the baseline profile. Is that included in the reference encoder? Jonatan Samuelsson: Yes, you should be able to run with -profile and set it to 1 instead of 0. Thomas Daede: Okay that is probably why I didn't see it, thanks. Mo Zanaty: The JS version of the decoder that you have on the demo page. Can you give more detail on how that was developed? Was it using WASM or Emscripten? Is it based on the reference code or something else? Jonatan Samuelsson: It is based on the reference code. It is using Emscripten. Mo Zanaty: You are not using ASM.js or WebAssembly? Jonatan Samuelsson: Yes ASM.js Mo Zanaty: So you are using the old version. I am asking because there are some results in Steinar's presentation and there is a question of is it good enough to use. Can you decode high resolution, like 1080p? Jonatan Samuelsson: What we have is 360p because we think that is what is safe for all players. We are single threaded and you might want to run multi-threaded if you do 1080p. ---------------------------------------- Thor/AV1 Update and Comparisons ---------------------------------------- Drafts: https://tools.ietf.org/html/draft-fuldseth-netvc-thor Slides: https://datatracker.ietf.org/doc/slides-102-netvc-thorav1-updatecomparisons Slide 4: Jonathan Lennox: The one thing I'd say is it is probably worth sending the list of SIMD instructions you want to the people doing the SIMD project so they know what people will actually use if they defined it. Steinar Midtskogen: Actually the SIMD library in Thor is using that. Jonathan Lennox: I would actually suggest asking the guy behind me (Tim Terriberry) who works for a browser company. Tim Terriberry: Yes, there are people working on the SIMD for WebAssembly. Steinar Midtskogen: Do you know if that is floats or integers? Tim Terriberry: Yes, it will support both but just 32-bit integers which I suspect is not what you want. Steinar Midtskogen: Yes. Tim Terriberry: The question I have is. If you are going to make a codec that you change on the fly as you see fit, what is the point of standardizing it in a working group like this? Steinar Midtskogen: You would standardize how you do it by sending that byte code. Mo Zanaty: The chairs have had some discussion on this point, esp. with the AD. The majority of that work would not be done here. It would be shard across a bunch of groups in ECMA, W3C, IETF, etc. You may need some umbrella effort to integrate the work. You may need IETF work to bind the codec to IETF standards like RTP, RTCWEB, etc. What NETVC could do is very vague. Tim Terriberry: I think that not just me, but a lot of other people would like to see something less vague, and what you would actually need is a different charter. Mo Zanaty: Yes, it definitely is not in charter. Slide 7: Mo Zanaty: Jonatan, I suspect the numbers you were presenting were with the maximum compression. Jonatan Samuelsson: Yes we were using the highest compression. Slide 9: Jonatan Samuelsson: Just for clarification, when you compare xvc and thor, was that with the RF? Steinar Midtskogen: Yes, that was with the 51 tools disabled as specified in the draft, no other changes. Jonatan Samuelsson: One comment on the SIMD, there is a little bit of SIMD in xvc as well, when it comes to interpolation filtering for example. [slide showed now SIMD in xvc] Mo Zanaty: The core take away is that at the last meeting we asked the xvc proponents to come up with a RF baseline, and we asked them what the relative performance to Thor would be, because the Thor team thought they were taking RF into account and not as an after thought. It seems like the xvc and Thor people are in agreement on what the performance would be for a RF code base. Steinar's testing seems to agree. Mo Zanaty: The net of it is that the technical requirements are being met. The other half of this is what are the IPR concerns with this baseline. I want to get a sense of the room as to what the IPR landscape looks like and if others are comfortable with this approach. Tim Terriberry: I thank you guys for taking the effort to create the RF baseline. I think the level of analysis that has been done has not changed since the last time. There are a lot of details here and the details matter. As Mo knows from the Thor work it is very difficult to have a degree of confidence that something really is RF. Adam Roach (as individual): I share Tim's concerns. Mo Zanaty (as individual): I think I also share the same concerns. Speaking for the work that was done on the Thor team, not the majority but a large chunk of the effort was getting the IPR story right. IF we had spent that time on technical progress instead, we probably would have gotten a better codec out. I have some concerns about short-circuiting the IPR analysis and doing it in only a few weeks time. I don't have a good comfort feeling about publishing a standard and having people implement that. Tim Terriberry: I just want to add that, to give some people an idea of what we are talking about, just on the Mozilla side, the amount of time we spent on the IPR review for AV1 was on the order of man years. That doesn't speak for the other alliance members. This really does take a lot of effort to get right. ---------------------------------------- Future Work/Direction Discussion ---------------------------------------- Mo Zanaty (as chair): I think Jonatan has done a good job answering the questions we had back in March. He has done a good job coming up with a technical proposal. The real concerns are about the IPR story. We started off this workgroup with two candidates, Thor and Daala. Both of those teams have stopped active development on those, there has been a little bit of work on Thor as Steinar summarized, but has stopped because both of those teams started working on AV1. The idea was that AV1 might be published here, but that will be done in a separate forum. So while both of those teams are working in this other forum, there will be no more work done here. That really leaves just xvc, and the IPR story here does not have enough confidence to move forward. I have only heard 3 opinions but all 3 had low confidence about moving forward. So that leaves us with a dilemma here, we really don't have any good candidates to move forward. We are considering to pause the WG to see what happens with the industry and other standards bodies like MPEG, but don't anticipate doing something unless things change. Adam Roach (as individual): You are speaking about the technical ability to come up with a standard to publish. Given that AV1 will be in the market soon, there is a question of "if this is good or bad". I would say it is a net positive that AV1 is out there. I am sad that the work was not done in an open standards body, but I am happy that it got done. Even if we could publish a codec here, it wouldn't be a good thing. Mo Zanaty: Adam's comment is that it wouldn't be a good idea to fragment the market with multiple RF codecs. Stephen Botzko: I would agree with that. Tim Terriberry: Pretty much +1. Mo Zanaty (as chair): Does anyone feel we should be progressing a candidate while AV1 is in the market? I am surprised Jonatan is not saying yes. Jonatan Samuelsson: We are happy to continue pursing xvc, but we want to work with others. If there is no interest, we don't want to pursue it. Adam Roach (speaking as an individual): I am really pleased to see the progress in getting this to work in JavaScript, but I don't think this is the place to progress. If you need something, work with the W3C to have those ABIs defined. There is probably additional work to do around sending JS defined codecs. Knobs in WebRTC to get this to work in browsers if you want real-time, or the audio and video graphics frameworks we have. So there would be a lot of work to do there, but most of it is not IETF work. Jonatan Samuelsson: Okay yes. Matt Miller (as chair): So what happens now is that we would issue last calls for the requirements and testing drafts. And send those to the IESG. But after that we would pause for 6 months to see what happens. No more physical meetings. Jonathan Lennox: 6 months is not a unit number of IETF meetings. Matt Miller (as chair): Lets call it two meeting cycles. Mo Zanaty (as chair): We would not meet in November and probably not March. We may meet in July if needed. What we are looking for is clarity around AV1 or MPEG efforts to see if there is a need. Matt Miller: We are adjourned. Mo Zanaty: See you in 6 months or never.