Re: [rtcweb] A different perspective on the video codec MTI discussion

+1 to both Chris and Erik's follow-up.

--Daryl

From: Erik Lagerway <erik@hookflash.com<mailto:erik@hookflash.com>>
Date: Thursday, March 14, 2013 8:17 PM
To: Chris Wendt <chris@chriswendt.net<mailto:chris@chriswendt.net>>
Cc: "rtcweb@ietf.org<mailto:rtcweb@ietf.org>" <rtcweb@ietf.org<mailto:rtcweb@ietf.org>>
Subject: Re: [rtcweb] A different perspective on the video codec MTI discussion

+1

Well said Chris, this is pretty much what I wrote earlier today...
http://blog.webrtc.is/2013/03/14/rtcweb-webrtc-mti-video-codec-debate-continues/

The WG has been through this debate many times and it seems rather obvious that this is not likely to get resolved anytime soon.

Let's remove the MTI video codec requirement now and get on with life.

/Erik

On Thu, Mar 14, 2013 at 3:41 PM, Chris Wendt <chris@chriswendt.net<mailto:chris@chriswendt.net>> wrote:
As mostly an observer over the past year or two, this issue of MTI has come a long way, both good and bad.

First, I will state, my employer, Comcast, has millions of boxes deployed and more in the pipeline where one could imagine webrtc capabilities being utilized.
Short term, VP8 does pose us the most challenge in terms of either suboptimal or total lack of support because of limited cpu/gpu capabilities, etc.
Longer term, this would be less of an issue, certainly, but perhaps in that time frame we will be talking the virtue of a brand new set of codecs anyway.

In terms of quality per bit/cpu/transistor, I believe nobody can credibly say that either codec is a horrible choice.  To me, any further argument or quantitative/perceptual testing on that is wasting time.

IPR, I'm not going to comment, because the clarity of the IPR situation is in the eye of the beholder.

While it would be wonderful if everybody agreed on a single video codec, I don't see any possibility that one can satisfy all use-cases in any practical way.  Whether it's browser to browser or browser to terminal, one can argue that her use-case is more valuable than the other, but we can't all agree on that either.

To me, the only choice left, and I think many others agree and some have stated it already, is either to make both codecs MTI or remove the MTI requirement.  The former, likely would take an act of God and for various reasons I don't think is the right choice anyway.  So, I would strongly encourage the latter, in full acknowledgement that there have been decisions made against this.
(ASCII codec being a third choice, but I haven't seen the draft )
Note, regardless of either choice, we would likely be required to implement both codecs anyway to avoid the transcoding penalty if we want to reasonably support interoperability.

In the end, we currently sit in the likely position that the market will decide this debate anyway, it already seems to be underway, so why keep wasting time debating.  Besides being a complete waste of valuable brain cycles, and delaying more important work to resolve, I think it has become or is close to becoming much more destructive to the process than the value of having a half-supported, forced choice MTI codec.

-Chris

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb