Live Blogging – IETF 88 – MTI Video Codecs

Chair: Taking the discussion back to the list.

Harold: We are witnessing a massive abuse of IETF policies. We have spent months on this.

Long line at the mic now

IMG_3040

IMG_2053

IMG_3706

Consensus Call:

NEITHER CODEC WAS SELECTED

Consensus Call:

VP8 – about 30% of the room

Jabber: 30 for VP8 and 10 for 264

Consensus Call:

H.264 – about half the room

Chair / Ted Hardie:

Regarding the consensus call, raise your hand for either or both but not neither. This is not a call but simply calrification

IMG_2892

Chair / Cullen: Agreed, hugs coming your way.

Martin: Keep in mind there are some that can’t get up and talk about that.

Chair / Cullen: We want to ask if you can’t live with either one of these codecs please get to the mic.

Tim Terryberry: Re: JR we need a royalty bearing codec if webrtc is to take off. I don’t think I need to tell the people in this room how excited everyone is about video in a browser without a plugin, ll of those are VP8.

Justin ? : Risk and Trust. Free codecs sounds good but today that’s not a reality. One of the advantages of going through an SVDO process is that the members must declare IPR, free codecs do not go through that. VP8 is not a free and the wind codec, it’s owned by Google. Google controls all of what VP8 is, can they be trusted. Who has implemented VP8 from the spec, not source.

?? – Technology is for people. The decision is for what we have today, not yesterday. Google has done a great job.

Harold Alvestrand: If people think that this announcement from Cisco of “later to be provided code” then I have real issues with the IETF process. Sooner or later we should find a way forward to rely on un-encumbered patent- less codecs, and if not now, then when?

Eric Rescorla: Mozilla intends to support 264 and VP8. We intend to support 264 via Cisco’s code/plugin on desktop. We will try hard to use the hw codecs since that works better on mobile. The user experience, during the install the codec will be installed (part of the install process). VP8 will be shipped with both mobile and desktop.

Bernard Aboba: It’s ok JR we do love you, hugs later.

Blackberry ?: Like the idea we would have a track towards better quality. The license is a big issue. VP8 is not a specification in the MPEG LA, but since it’s not there we have no mitigation there so we can’t make VP8 the MTI.

Randell Jesup: Those who are not making a browser but instead a server like asterisk or the like, their users would also have to download this plugin codec as well. It’s unclear if this would fall into the personal non-commercial use category. IT is not going to like this either, dealing with plugin codecs will make their lives potentially rather difficult.

JR: Arguing that we must choose a MTI codec or they can’t ship

Robin Raymond: I think it’s great that this new 264 codec is out there but if we make it mandatory the little guys lose. Mobile can’t download a binary, it must be part of the app before deployed. If you need H.264 you can add it if you need it but don’t force that royalty bearing codecs on all of us.

JR: Users don’t need to get plugins, apps do that.

Dean Willis: I don’t build browsers. For the last 7 years I have made my career on IPR consulting. If we were to pick 264 as MTI and since Cisco is not part the MPEG LA there seems to be risk there. Seems to me no choice works as well.

Roman Mahy: The most compelling items were the embedded platforms. My experience it was at one point very hard to find hw accelerated encoding, in the past.

Peter Thatcher: We turned on transcoding for a well known chat service and no one noticed. We are better off allowing the market to decide as Martin indicated months ago.

Justin Uberti: Regarding Adam’s comments regarding someone recording calls does not the understand the current laws. If you want to ship h.264 you can, no one is stopping you but not as the MTI codec.

John Peterson: This Wg has made plenty of decisions re: interop and we have saddled this WG with SIP /OA, but I think we should go with H.264

Roberto ?: The bias seems to be present, that larger companies have an easier time sending people here. If you choose to make 264 the MTI you are cutting out the small guys. I think the best option is to choose neither.

Matt ?: There are plenty of lawsuits against 264 so to say there is no risk with 264 that is simply not true. External plugins are not cool.

Ted Hardie (independent) : I offered JR a hug as he seemed to feel the free 264 effort was not appreciated. One of things we were trying to avoid is a plugin scenario and this (other things were added) is the reason we can’t invoke 264 as the MTI video codec. Royalties will push away numerous developers, big and small. Since 264 is now free (not free from royalty), we can add that codec as a non-mti codec.

JR: Transcoding degrades quality.

Martin Thompson: Let’s stop messing about with semantics, 264 is clearly the correct choice here so let’s get on with it.

Chair / Cullen Response: That was put to the list months ago and no one came forth with a proposal so that is not on the table today.

Jeremy ?: We could also consider both codecs.

Jean ?: Calling Nokia to the mic to clarify why there is a patent claim on VP8 and not on 264.

Peter Thatcher: Seems there are 2 broad categories, H.264 is better and the patent argument. The first is simply perspective and the second the patent being mentioned with Nokia is not resolved and if we are making a decision to implement 264 maybe those making that decision should wait until that is resolved.

Justin Uberti: Interop is misunderstood. Transcoding is cheap so that does not hold in the commercial world. VP8 is shipping in plenty of endpoints. Hardware Codecs are quite a ways off, there is LOTS of works that needs to be done here.

Monty Montgomery: If we go down this 264 path we are staking our future on a binary law environment.

Harold: To Cisco, please publish your findings

Cisco: Certainly

—-

Open Mic

JR / Cisco Conclusion

IMG_1202

JR Arguing Risk Analysis

IMG_5547

JR Arguing Risk Assessment

IMG_3772

JR Arguing Distribution

IMG_2881

JR arguing the results in Germany (re: Nokia VP8 patent being put down in Germany) may or may not be a consideration

JR arguing that VP8 is a target for patent trolls

JR arguing patent risk

IMG_0272

Distribution

IMG_6600

JR arguing both codecs perform nearly the same so let’s get past that

IMG_0263

Justin asking, which of these represent (slide below) actual Real-time encoode/decode

Cisco response: much smaller percentage

IMG_3488

H.264 vs VP8 Deployment & Standard

IMG_9582

H.264 Shipping Date

IMG_4600

Jonathan Rosenberg on H.264 for Cisco is at the mic

IMG_2914

—- that was fast, thanks Harold! —-

Harold is at the mic..

IMG_2913

NOTE: This post may not be entirely accurate. I am not the fastest typist in the world and I ad-lib when I can to get the general gist in the post.

Tags: , , , , ,

2 responses to “Live Blogging – IETF 88 – MTI Video Codecs”

  1. Adam Roach (@adambroach) says :

    C’mon, Erik. You left out my response to Justin: the cost of transcoding is far more than the 1 cent per hour required to run the transcoders. The big costs are user experience and security. When Apple changed Facetime to use network relays for all calls, they got over 60,000 user complaints about the diminished quality — and that was just for relaying, never mind the latency and quality implications of the transcoding. And, even bigger, transcoding decimates security: by requiring a node in the middle of the network to decode your media, you have added an intercept point; also, because you’re terminating the security association in the middle of the network, you lose the ability to identify the remote party through your media.

    • Erik Lagerway says :

      My bad Adam, thanks for the clarification.

      There are likely other omissions, just not fast enough to keep up with the barrage of activity in the room.

%d bloggers like this: