Linux: Specify rate control params for software encoding

[deiteris]

No description provided.

[nowrep]

LGTM now

[deiteris]

Wait, why divide by 10? The buffer is going to be huge at some point (it's basically a 10 seconds buffer now). What is wrong with 1 frame buffer size?

[nowrep]

What is wrong with 1 frame buffer size?

It degrades image quality a lot with sw encoder (x264).

[deiteris]

I think better logic would be to use encoder_ctx->bit_rate / settings.m_refreshRate * n then, where n is number of buffered frames and find the number that is ok, just to make it consistent. For our case, it normally should be 1.1 frame because of low latency requirement (and maybe for all other encoders too actually. AMD's LCVBR suggests using from 1.1 to 3 frames here), but if some other value works better for x264, then we can keep it more than 1.1.

[nowrep]

encoder_ctx->bit_rate / settings.m_refreshRate * 1.1 actually does work, but the result is exactly the same as bit_rate/10 or leaving it at the default value.
In any case, "improving" sw encode is pointless until it works without forcing all idr anyway. openh264 works fine with p-frames but also the encoder is very slow.

[deiteris]

Well, it's not only about improving sw encoding, but also other encoders should have this value set properly :) It can be better in terms of quality, but is it the same in terms of latency? Because /10 is a 10 seconds buffer (basically refresh rate * 10 number of frames), and default is whatever the codec uses (it may be large for some bitrate and may be small for the other).

[nowrep]

The latency and image quality is exactly the same for any value >= encoder_ctx->bit_rate / settings.m_refreshRate * 1.1

[deiteris]

I'll try experimenting on Windows with different setups. I think that's the value that we might want to use for all encoders (and maybe min_bitrate is actually useless in that case).