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

[Erik Lagerway <[e-mail]>]

+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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>