RTCWEB March 14, 2013
Chairs: Magnus Westerlund, Ted Hardie, Cullen Jennings
AD: Gonzalo Camarillo
Jabber logs: http://www.ietf.org/jabber/logs/rtcweb/2013-03-14.html
Audio recording: http://www.ietf.org/audio/ietf86/ietf86-caribbean4-20130314-0900-am1.mp3
MeetEcho: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB
NB:  There were initial issues with the audio levels, but were resolved within the first 10 minutes.

Agenda:  

JSEP Update
Presentation:  http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-13.pdf
Justin Uberti presenting
 
During the discussion, Eric Rescorla raised a question on the ICE candidate gathering, suggesting that the proposal was over-specified.  Martin pointed out that it had been discussed in the W3C; he argued that it did not further discussion here.  Cullen asked whether the allocation of resources was occurring during the ICE candidate gathering.  Justin replied that there had been no consensus on this point.

On the topic of rollback, Eric asked whether it was possible to rollback once in the stable state; Justin confirmed, and Eric asked that this be better documented.  Justin agreed.  Martin asked about PRANSWER; Justin noted that it had been agreed that PRANSWER was not out of scope, but the initial focus was on offer rollback.

The group then moved to the discussion of rehydration.  Justin noted that one way this could be modeled was as if it were a re-invite, and that this limited the “magic” needed.  Cullen said that it might not be strictly a re-invite but “invite with replaces” or similar--but he was basically positive toward the essential approach.   Question on whether MSID had already been approved; Cullen noted that it had not seen a consensus call, but that it was a working group draft and it was expected that progress would be made.  Eric Rescorla noted that there were other approaches to rehydration, and though the current version was not objectionable, it was not settled.  Justin asked if there were specific concerns; Eric replied that he was concerned about the consequences of having one side experience a call restart and another side not, in the case of permissions grants.  Martin Thomson suggested that an updated draft with new state diagram would be appropriate.  He also asked how long the property of stable MSIDs would be required.   Justin noted that it could arbitrarily long.  Martin noted that the media stream is a transient object for grouping and that to create that stability was going to require work.  Eric and Justin then discussed what the “plumbing” object is for browser-level constructs to the underlying media stream.  Eric asked where the agreement was that MSIDs should be this object?  Justin asked what handles are available.  Martin suggested that this topic be moved to the list.  Paul Kyzivat then asked what happens if signalling occurs during the middle of this rehydration?  Reply is that this fails.  Justin believes that this is two RTT amount of time and that if a re-invite occurs, this just failed.  Giri commented that some of these discussions belong in the W3C, perhaps in the media stream capture task force.  He also asked whether a new tab was considered a new context and thus out of scope for the rehydration.  Justin said that it was possible to persist across this, but that it was much more work for the application.  Cullen asked whether it would be possible to move the state from one device to another.  Justin it’s a little more dicey, but it could work, and it would be an interesting call handoff choices.  Martin believes that it won’t work when these are being generated on the fly.  Justin notes that this presumes that this is being set, not generated on the fly.  Eric notes that he’d like to see more detail as the use case Cullen’s raised would not be possible in the other approaches, so he’d like to see more detail on this.  Ted Hardie asked from the floor how separable is this problem?  Can it move out of JSEP or is it better to keep it in a single document?  Justin answered that the whole MSID stuff needs to be worked out and other W3C work needs to be coordinated, but that it still belongs in JSEP.  Eric said he didn’t care much about what document it is-he wants to keep this idea in mind as we do the rest of the protocol.  Keeping that page of spec in JSEP does that.  Andy Hutton said that he did not want to park the decision.

Mandatory to Implement Video Codec discussion
VP8 Technical: http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-9.pdf
Harald Alvestrand presenting

During the discussion of testing, Bo Burman asked whether the tests used x264, and Harald confirmed.  He noted that the x264 tool has a tune parameter and that when they ran similar tests, they did not get similar results.  Gaelle disagreed with the averaging of chroma and luma and said that MPEG would not do so; she also said that use of rate control was not appropriate.  Harald noted that for MPEG, they had agreed to run a set of tests without rate control.  During the discussion of performance testing, Cullen asked from the floor whether the reflected numbers were from the same parameters as those on the previous test slide.  Harald replied that there was a larger set reflected here, which included the set from the previous slide.  There was a comparison slide; Xavier Marjou noted the slide indicated lots of hardware support and that these were important for battery life.  Harald agreed and noted thats why they were there, but that it works well without it, in part because of better uniformity on the VP8 side--variation is not an advantage here. Justin pointed out that all the realtime apps for mobile except for Facetime, which is part of a vertically integrated stack, use the software methods--the cpu draw is not significant in the face of the other power draws.  Xavier noted that the advantage VP8 has from uniformity may fade as it becomes more popular.  Cullen, from the floor, challenged the availability, saying that there were terms he could not agree to (sharing Cisco’s marketing plans and publishing them ahead of time); Harald said he had not seen that.  Matt Frost then spoke to say that it was just dropped, not that it was not being available to Cisco.  He then said that the hardware designs for H.264 were a lot harder to get than VP8.  Bo Burman noted that it was being maintained, but also that it was frozen.  Harald clarified that there have been no bug fixes that required changes to the bitstream.  If there become some, they can be evaluated then.  Gaelle then spoke, saying that the venue is wrong, that the MPEG is the right place.  She wants to be sure that the test are accurate, and that the test set is problematic. Mo Zanaty noted that most applications don’t use the hardware implementations, but disagreed with the reasoning.  The APIs are wrong--the APIs can’t control the right parameters.  Daryl noted that it was not objective. The reply was that it was not intended to be.  He asked about deployment of WebRTC vs. H.264 devices.  Kalyani commented that the implementation of VP8 in hardware for mobile--she says that it may be in the chipsets, but it is not yet available to applications.  Justin noted that there are 2 billion VP8-capable implementations shipping Chrome and Firefox.

VP8 IPR: http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-10.pdf
Serge Lachapelle presenting
Gaelle reiterated that more details are needed on the recent announcement and noted that there are many more patent holders for H.264 that are not in MPEG.  She asked if the IETF could send letters to solicit information from them.  Ted Hardie referred her to the IETF process documents on IPR and asked her to contact the area directors if she had questions on how it works.   Gonzalo noted that the area directors had already spoken to her and pointed her to the same BCPs.  Cullen Jennings from the floor then disagreed with Serge’s characterization of the difficulty of getting an H.264 license.  Serge said that it matched his experience. Cullen noted that there were only four browsers and that all but Mozilla had a fully paid license for H.264 already, so the administrative overhead was zero. Serge asked if he did not want to see a fifth browser.  Cullen reiterated his disagreement with the characterization.  Hadriel then asked why this discussion was happening at this meeting, since the list had been told that there would be only technical discussions.  The chairs cut the line at that point.  Eric first thanked Google for arranging the MPEG-LA agreement, and asked if the upcoming statement would list from whom the sublicenses derived.  Serge replied that it would. Markus Isomaki noted that since there were some IPR discussion, he wanted to repeat his statement from the list that Nokia believes it has IPR on VP8 and it is preparing an IPR disclosure.  Stephan Wenger noted that it was mentioned that the IPR situation is different for different profiles; yes it is, there are non-pool patents needed for certain profiles, but that the vast majority of IPR is licensable in the pool.  He also disagreed with the presentation’s characterization of the difficulty.  Randell Jessup noted that it was not just browser, but anything that needs to work with browsers and they would not be covered by browser licenses.  Cullen Jennings, from the floor, said that if the working group goes with H.264, Cisco will open source an H.264 video codec that was not GPL, since they believe it is a relevant issue.  Jonathan Lennox relayed from the jabber room that servers don’t have H.264, asterisk can’t do anything with H.264; it’s not that asterisk users don’t want to pay, there’s simply no agreement.  Tim Terriberry then spoke in support of Randell’s point that it is not just browser that are at issue, but the whole ecosystem.

H.264 MTI presentation: http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-12.pdf
Bo Burnam presenting
Ted Hardie from the floor thanked Bo for the clarity for his proposal on what profile of H.264 was proposed as MTI.  He then said he didn’t think there was an agreement to additionally have a Recommended profile; that is, the working group would have both MUSTs and SHOULDs.  Its a base part of the system that negotiation is possible, and that negotiation might well be to the profile he indicated, and that could be the case no matter what the MTI.  Tim Terriberry wanted to be clear that the profile proposed is the one that is one that is worse than VP8. Bo agreed. He went on to explain that this a trade-off between implementation efficiency and compression efficiency; the MTI correct working point is designed to allow for very constrained devices.  Randell Jessup commented on the interoperablity issue; most of the uses of video conferencing (not systems) may use H.264, but are not interoperable with anything.  Facetime is an example--it uses H.264, but it is not interoperable.  Harald asked if the selection of test clips would be made public.  Bo said that they would; Harald thanked him, saying that the selection of test clips was important.  He then asked whether he understood correctly that the tests were run outside of the profile.  Bo clarified that the tests were run against the recommended profile, not the mandatory to implement.  Peter St. Andre indicated that he was uncomfortable with the argument from uncertainty presented.  How can you ever know you have found all the patent holders after you have licensed from the known pool?  Eric asked whether there were corresponding CPU numbers for the measurements given.  Bo said no, but they could get them. Eric noted that it is important to know whether constrained baseline simply allows for a lower CPU utilization or it is actually worse than the other profiles.  Gaelle responded to Randell saying that the Interop issue is not an issue anymore if it is made MTI.  She also clarified the IPR slide by saying that the ITU database is a consistent list of known patent holder.  The MPEG-LA pool is a subset.  She re-iterated her view that the IETF is not the place for clarifying this.  Stephan Wenger gave his belief that 5 people from the room could detect the difference between 30% difference given on the measurements; even expert viewers find it hard.  He suggests that performance numbers are not the main decision criteria, at this order of magnitude.  If we do decide to do a shoot out; the meaningful way to do it is a subjective test.

H.264 comparison: http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-11.pdf
Cullen Jennings presenting (as an individual)

Commenting on the comparison between the two videos, Justin Uberti noted that it was not even the same scene. Adam Roach noted that VP8 took twenty pounds off him, given that they weren’t the same aspect ratio or resolution.  Cullen agreed that there were very many different ways to cook videos.  He went through a series of objections.  Tim Terriberry if you think we should be using something other than baseline, why haven’t you proposed that?  Cullen what do you think the minimum resolution should be?  Tim answered 360p.  Cullen said, okay, but that’s not what we’re going to test to--we’re going to test against the common user experience, not the minimum.  Tim that doesn’t make sense to me, but maybe have others have other impressions. Ted Hardie from the floor then said that the point of an MTI in this working group was to avoid negotiation failure and that you would always be able to negotiation away to a different one you share with the peer.  That means that if you are testing the codec you have to test it for the case of negotiation failure; that means you are testing the MTI itself.  Cullen disagreed and said that he thought we were picking which codec would be broadly implemented and so we had to think about what’s the user experience between a or b.  Ted said that this is fundamentally different from the guidelines for the group from the beginning.  Henning’s guideline on this was the guideline from the beginning.  Tim said that Ted’s point was the one he had expressed as well.  Randell then said that the question before the group is whether the MTI is sufficiently good to cover the needs of negotiation failure; the other questions are the side effects of that choice to browsers, non-browsers members of the ecosystem.  Keith Moore if the MTI is not good that you want to use it, its worse than negotiation failure.  Justin Uberti we don’t want to limit ourselves to QVGA.  Do we really think people will ship high profile?  Cullen said yes, it’s the same license, and there will be open source available.  Justin disagreed. Eric Rescorla first said he like the shirt in the example.  Then he asked Cullen to restate Cisco’s commitment to provide an open source.  Cullen said they would open source an H.264 AVC implementation on terms that work for firefox.  Eric:  High profile?  Cullen:  Yes?  Eric:  I am concerned about this testing methodology because this looks so bad, where Harald’s stuff looked identical.  Why?  Cullen went into some reasons, including different cameras.  Gaelle said that we will not have an MTI.  Can we agree on a Recommended at this meeting?  Ted answered that it is not a chartered work item, so it will not be asked at this meeting.  Hadriel Kaplan it is about failure to negotiate; it could be ascii art animation.  If they just want to see something, that’s what they want.  Our role is to make the SDP negotiation to not fail.   I suggest that if it weren’t for the IPR issue, we’d pick both.  That would be the best chance of not failing negotiation.  Cullen noted that it is not about whether ascii art is okay; for WebRTC to succeed, I have to build stuff that is commercially viable (Brief ascii art digression).  With that goal, if WebRTC has video quality and audio quality that is grossly inferior, it won’t succeed.  It has to be a commercially viable codec.  Stephan Wenger comments that the presentation methodology would not support scientific methodology; Cullen said plus one.  Cullen said that very simple testing showed him a huge difference; he encouraged others to go get more data. He, as an individual, asked if people were interested in getting more data (no response).  Justin suggested that we get subjective testing for the existing clips as an next store.

In the general discussion,  Kalyani noted the support of the 3gpp and GSMA community and asked that H.264 be chosen as MTI.  Justin Uberti noted that Youtube is also a user of VP8 and they found the quality of it, bit for bit, is better for a large scale video application.  Eric Rescorla liked Justin’s suggested was good, with the addition that re-encoding by folks who have other H.264 settings in mind.  Jeremy Fuller said that there is an entrenched beauty contest here, and that there will be groups unhappy with either choice.  That tends to mean either you move on to having none or two; when do we get to that?  Xavier commented that the use case of Youtube was not the same as the WebRTC use case.  Gaelle asked what the next step was.  Next step:  listen to Martin, then listen to the AD’s question.  Then we’ll work out the next step based on what data is needed (either on an IPR basis or technical basis).  Martin, I don’t believe anything we do about a beauty contest will have any influence on what will get implemented; we should let the market decide.

Sense of the room query: http://www.ietf.org/proceedings/86/slides/slides-86-rtcweb-14.pdf
Robert Sparks (as a favor to the chairs)

The questions to be asked were put on the slides.  If you can’t answer these question, think about what you really need.  Come articulate that at the mic after the questions.  If you want H.264 or can live with it had on the order of 70 hands raised; if you want vp8 or can live with had on the order of 50 hands raised.  New items raised at the mic lines:  Dan didn’t see any discussion on performance in the presence of packet loss or bandwidth constraints.  Why is that not part of the selection criteria.  Keith Moore, if you don’t test this over cheap hotel internet, you haven’t done justice.  Peter St. Andre noted that we have a clear winner: it’s the ascii one.  Adam Roach:  the elephant in the room is the licensing.  Darryl:  should we ask about no MTI?  Robert:  the group spent a great deal of time developing that consensus.  Jonathan Lennox:  there may be people who have “no mti” as second best, after their preference.  

Ted Hardie thanked folks for coming and said the chairs would be working with ADs on next steps.  After some of the expected statements are in, it is likely we’ll come back to the working group to see what that has changed.