[SOLVED] "--ipratio" "--pbratio"+"--scenecut" "--minkeyint" / "--keyint

[Kdmeizk]

Hello,

Is it possible to explain to me these both parameters ? I tried many researches but anything (when I find something about this) for 45mins of research tell me things so blur. So may be here, you have a really good explanation.

I'm pretty sure you will say "usually, don't touch these parameters" but I hope you will say why.

Thanks in advance.

[pandy]

coefficients for adjusting quantization relation - what is relation between quantizer on I and P, P and B frames (to high difference may lead to unwanted artifacts).

You can change defualt quantizer ratio and for example bias that I should have lower quantizer (i.e. higher quality) than P or opposite - bias lower quantizer on P when related to I - directly affecting quality and bitrate.
Usually default values are best for most cases, sometimes if you know your source you may wishing to adjust them.

[Kdmeizk]

For information I use Hybrid and its author (Selur) wrote :
--ipratio : "Specifies the factor between the quantization of an I-frame and a P-frame using it as a reference."
--pbratio : "Specifies the factor between the quantization of an P-frame and a B-frame using it as a reference."


I think I don't understand "quantization" in this case. I see as "Encoding mode : Constant quantizer" and here "coefficient to adjust quantization".
I know there is a type for each frame in this order :
I-frame ("raw" quality, big size) > P-frame (predicted from I-frame with high quality, medium size) > B-frame (predicted from P-frame with low quality, low size).

So, with these informations, it seems :
if "--ipratio" > "--pbratio" then there is more I-frame and P-frame as a reference frame.

I understand this but I'm nearly sure it isn't it :/

[jagabo]

Think of the quantizer as how much information is thrown away from each frame. The higher the quantizer the more information is thrown out, the less detailed the picture gets, and the lower the bitrate gets. The ratios are how much bigger quantizers are used for one frame type compared to the other. For example, if you elect to make a constant quantizer encoding at qp=21, and use a ipratio of 1.4 (the default), then P frames will use a quantizer 21 and I frames will use a quantizer of 15 (21 / 1.4). And with the default pbratio of 1.3, B frames will use a quantizer of ~27 (21 * 1.3). So I frames are encoded with higher quality than P frames, and B frames are encoded with a lower quality than P frames.

constant quantizer encoding:
https://en.wikibooks.org/wiki/MeGUI/x264_Settings#qp

ipratio and pbratio:
https://en.wikibooks.org/wiki/MeGUI/x264_Settings#ipratio

[Kdmeizk]

Oh thanks jaga, I didn't see this documentation. I understand now this setting. But I would like know, I trying some tests with amazing values like --pbratio=10 or --pbratio=1 with cfr=18 but it seems I see no visual changes.

I assume it's normal. If it's normal, I assume too change this settings for amazing values like these aren't a good idea, right ?

[poisondeathray]

Oh thanks jaga, I didn't see this documentation. I understand now this setting. But I would like know, I trying some tests with amazing values like --pbratio=10 or --pbratio=1 with cfr=18 but it seems I see no visual changes.

I assume it's normal. If it's normal, I assume too change this settings for amazing values like these aren't a good idea, right ?

--pbratio is not affected if you have mb-tree enabled (it's enabled on the default "medium" preset)

If you have a high bitrate scenarios , then you might want to reduce ipratio - it can reduce a slight temporal "fluttering" as the frames fluctuate in quality . That's about the only scenario where it might be commonly adjusted. Overall the default values are pretty balanced for the majority of situations, hence it's usually not a good idea to adjust them

[Kdmeizk]

Well. Experts worked in this codec and even if generally I don't believe in many people, I believe in this team which helped by many people too. So, I think I let this settings with default values.

A documentation with tests of this type of settings is available somewhere ? I saw several documentations of 300 pages but I'm not sure tests about this setting are into it.

[poisondeathray]

There is no comprehensive collection of tests. They are scattered all over the internet, a few there a few here . Often they are difficult to find - sometimes there are buried in a post of another topic . Many are "lost" at the (dead) doom10 site but might still be available through the wayback machine. The best thing to do if you want to "learn" how the encoder "behaves" is to do the tests yourself in various test scenarios (various types of content sources, various bitrate ranges) . If you find some interesting or unexpected behaviour, then please share it

[poisondeathray]

Crap.

I just realized you are talking about x265, not x264 . What I mentioned above applies specifically to x264 - I do NOT know if they can be applied to x265 , but I suspect so. There are differences like cutree instead of mbtree , but the concepts are analgous

[Kdmeizk]

Don't worry, concepts are analogous yes.

I will think more about these settings but by the way, I would like know one thing about "--scenecut" and "--minkeyint" / "--keyint".
I understood like this : After "--keyint", a key frame is put.

(Keyframe : Raw image + image displayed if I need to go for 4 second of a video -> Please tell me if this is right, I've really difficulties to understand what is a key frame.)


In the case of I'm right :

(If "--scenecut" is setted properly (for example, for someone who needs to navigate for a real change in the video), - we can take --scenecut 40 -, we don't need "--keyint" ?

Plus, set "--keyint 0" (= infinite) and "--scenecut 0" = impossible to navigate in a video or really really hardly ?)

[poisondeathray]

Don't worry, concepts are analogous yes.

I will think more about these settings but by the way, I would like know one thing about "--scenecut" and "--minkeyint" / "--keyint".
I understood like this : After "--keyint", a key frame is put.

(Keyframe : Raw image + image displayed if I need to go for 4 second of a video -> Please tell me if this is right, I've really difficulties to understand what is a key frame.)


In the case of I'm right :

(If "--scenecut" is setted properly (for example, for someone who needs to navigate for a real change in the video), - we can take --scenecut 40 -, we don't need "--keyint" ?

Plus, set "--keyint 0" (= infinite) and "--scenecut 0" = impossible to navigate in a video or really really hardly ?)

https://en.wikipedia.org/wiki/Group_of_pictures

"keyframe" is an independently encoded frame. It can exist alone, without other frames. B and P frames rely on information from other frames (temporal compression) . As such , "keyframes" usually are much larger in coding size. Usually keyframes are known as "I" frames. However, in x264, there are 2 types of "I" frames, IDR frames which are "true" keyframes, and "i" frames which do no limit a GOP - they are used when you have open GOP's and you've hit the --keyint limit

-keyint just places a maximum number limitation on the size of the GOP, then an IDR frame is place. For example, if --keyint is 250, then the maximum IDR frame interval is 250 frames apart. However, if --scenecut detects an IDR frame should be placed earlier, then it will, and you start counting again for keyint.

The larger the GOP size, the more difficult to seek. Some devices cannot handle very long GOPs . It's also a mistake to think a longer GOP past a certain number always improves efficiency. It does, but only up to a certain number. In many cases there are diminishing returns, and even negative consequences (lower quality) past a certain point . The "optimum" number is going to be different for different types of content, different scenarios and bitrate ranges

We talk about "frames", but that's not how it really works - it's just a gross oversimplification and easy way to think about it - it actually works on a macroblock level

[Kdmeizk]

So we can just put "--scenecut" and let "--keyint infinite" ?

[jagabo]

So we can just put "--scenecut" and let "--keyint infinite" ?

It depends on your playback software/device and personal preference. Many devices have a limit on GOP size. At playback you will get very slow seeking when seeking to the middle of very long GOPs. With most material the additional compression with GOPs longer than the default is negligible.

[pandy]

So we can just put "--scenecut" and let "--keyint infinite" ?

Yes, overall distance between keyframes will be shaped by codec limitation (or rather design) and by real 'deltas' measured trough scene detection.
However in extreme cases such stream can be unseekable (i.e. only one keyframe maybe present at start).

[Kdmeizk]

Yes I repeat, in the case of "--scenecut" has a good choice only. So it's possible to work without "--keyint".