Re: [rtcweb] Alternative decision process in RTCWeb

[Bjoern Hoehrmann <[e-mail]>]

* Basil Mohamed Gohar wrote:
>The problem with your problem is that you've set an ambiguous bar that
>is also irrelevant - "reasonable quality".  That is not the purpose of
>an MTI codec.  Rather, an MTI codec is there to prevent the absolute
>worst case of two endpoints being unable to communicate via video at all
>due to codec negotiation failure.  And MTI codec is also not mandating
>that it be the ONLY codec or even the BEST codec to be used.  It's there
>specifically to ensure communication can ALWAYS happen, no matter what.

I think it is highly relevant whether the mandatory-to-implement codec
supports two people in typical German households communicate via video
in sign language, and how it does so relative to non-mandatory options,
as a simple example. If H.264 supports the scenario and H.261 does not,
then selecting H.261 does not in fact prevent the absolute worst case
and does not ensure that communication via video can always happen.

>The fight against H.261 as MTI is really not about quality or
>efficiency, but rather, about forcing a royalty-bearing format on what
>should be an open standard and to save a few big players some
>implementation dollars because they might want to reuse some existing
>hardware, all of which are secondary points in this charter compared to
>a universally applicable MTI video codec.

Like I said, I have not seen a convincing argument that H.261 performs
well enough, and the implementation techniques that can reasonably be
assumed to be unencumbered are old enough that I think it is fair to
assume without investigating myself that selecting H.261 as only manda-
tory-to-implement video codec could work on paper, but not in practise.

I read the "irrelevant" responses as essentially advocating that we may
just as well make sending raw and unencoded RGB data the MTI codec. I'm
more than willing to hear better arguments. The same goes for the H.263
option that has been suggested.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/