On Mon, Dec 2, 2013 at 2:27 PM, Bjoern Hoehrmann <derhoermi@xxxxxxx> wrote:
* Ron wrote:I have not seen a convincing argument that H.261 performs well enough to
> 2. Can anybody show a sustainable objection for why we _can't_ use H.261.
>
> If they can, we're probably doomed. If they can't we have an initial
> choice for MTI.
permit real-time video communication at reasonable quality and bitrates.
That is irrelevant.
MTI does not need to be a good choice, it merely needs to achieve interoperability.
If someone can support HD video over a 300 BAUD connection, the technology is almost certain to be proprietary. That does not mean that the IETF has to accept the proprietary technology as MTI because it is the only one that supports the needs of 300 BAUD users, it means that that group of users may not be supported by the MTI CODEC.
MPEG2 will come out of patent in the nearish future and it is a not terrible choice. It is certainly not the best choice but it isn't a horrible one.
I have not seen recent statistics for Germany but I suspect it is common
that household members share a line with an upstream of around 640 kbps,
that would basically allow for two 320x240 H.264 CBP + Audio streams at
30 fps in good quality. Would H.261 permit at least one stream at the
same quality? If not, then nobody would use H.261-only WebRTC products,
and people are not going to appreciate if a VP8 product connecting with
a H.264 product falls back to H.261 to avoid negotiation failure.
People would use H.261 if that is all the clients at either end supported. The value of the H.264 patent pool would be reduced from the ability to perform the application to a quality issue for some subset (a clear minority) of the user base.
We knew that there were real security and performance problems with 3DES when we made it MTI in TLS 1.0 but that was the best choice available at the time.
If there was an optimal technical choice that had no other consideration there would be no need for MTI clauses at all.
Website: http://hallambaker.com/