Re: [rtcweb] Alternative decision process in RTCWeb

[Silvia Pfeiffer <[e-mail]>]

On 3 Dec 2013 07:16, "Basil Mohamed Gohar" <[e-mail]>
wrote:
>
> On 12/02/2013 02:27 PM, Bjoern Hoehrmann wrote:
> > * Ron wrote:
> >> 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.
> >
> > I have not seen a convincing argument that H.261 performs well enough to
> > permit real-time video communication at reasonable quality and bitrates.
> >
> > 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.
> >
>
> 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.
>
> It's a codec of last resort, and should not be compared against the
> state of the art that's available elsewhere.
>
> It also has the added bonus of being ridiculously simple to implement,
> both for encoding and decoding, compared to what's out there.
>
> It really fits the bill as being something to serve as the worst case
> scenario that's not catastrophic.
>
> And as stated elsewhere on this list, some tests have been done on CIF
> videos (352x288) at lower framerates at 256kbps, and got acceptable
> results.  In fact, it was designed in the area of ISDN (64k + 64k), so
> it will, in fact, work at the stated bitrates you're talking about here.
>  We'd need also to add only about 16kbps for a killer Opus speech
> channel, and you'd be set.
>
> 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.
>

I guess one thing that the vote should determine is whether implementers
are more accepting of falling back to an old codec (Theora, h.261, etc)
over implementing decoding for 2 modern codecs (h.264 & vp8) plus encoding
of one of them.

Is the vote set up in a way that will let us answer this question in the
end?

Silvia.