Re: [rtcweb] More H.264 vs VP8 tests

Rate control is typically a different beast from congestion control, and any coupling is typically very loose. Rate control is primarily adaptive quantization to optimize perceptual quality based on content statistics, with little or no coupling to transport statistics. Any such coupling is often loose, like a target average bit rate over coarse timescales inappropriate for congestion control like seconds or longer. Constraining rate control to also perform congestion control over tight timescales like a frame time will result in suboptimal video quality, because content statistics are inherently uncorrelated with transport statistics, so forcing any coupling degrades perceptual quality. Hence why congestion control is often implemented as a pacer/shaper outside the encoder rate control, with a slower feedback loop to adapt the target rate of the encoder rate control less frequently than congestion controlled packet transmission.

Anyone interested in congestion control or its coupling to rate control should participate in RMCAT.

Mo

On Jun 26, 2013, at 11:35 AM, "Eggert, Lars" <lars@netapp.com> wrote:

Hi,

On Jun 25, 2013, at 0:00, Harald Alvestrand <harald@alvestrand.no> wrote:
> This would seem to me to be an argument for including the rate control.... what we are looking for is the codec where people can demonstrate the best performance for our specific situations, not the codec that is best able to fulfil a set of conditions that are inappropriate for Real Life.

I'd agree with this argument *if* we actually had some idea of what congestion control algorithm(s) RMCAT will propose. If we did, looking at congestion-controlled output quality would make a lot of sense.

But, we don't know what RMCAT will recommend, and - with my RMCAT chair hat on - progress is slow, because participation is not exactly stellar. RTCWEB folks with an interest in this topic should start participating in RMCAT. Pretty please.

But, I digressed. Since we don't know what algorithm RMCAT will recommend, comparing different codec/congestion-control pairs makes it very hard to figure out whether quality differences are due to the codec, or due to the congestion controller.

So as a baseline, it would make sense to eliminate the congestion controller from this comparison, at least initially. Once we have some candidate congestion controllers on the table in RMCAT, comparing encoder-controller pairs makes sense, e.g., VP8 with controller A against MPEG with controller A, VP8 with controller B against MPEG with controller B, etc.

Because in the end, as you say, congestion-controlled output quality is what matters in the real world. So IMO any final decision on a codec needs to wait until we know what the congestion controller is doing.

Lars
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb