About qpfile and similar questions

[sirt]

Hi everybody,

I come with a few questions :

1) As I want to experiment, I read about qpfile parameter ; then I decided to use that to see "what happens". As explained on the dedicated settings page, you can decide what will be a I, P or B frame while assigning a quantizer if needed. But, it is said I should not abuse of setting myself such frames in so far it would affect x264's perfomances. Anyway, let's say I have a progressive source which I analyse on AVSP ; how could I decide to mark such and such frame as a I, P or B frame trougth my qpfile ? More precisely, is it possible to make such decisions according to your eye perception or is there another criteria to take into account ? Please don't tell me "let x264 assume the right decisions" because I know I should do this though.

2) Something still strikes me : let's say I encode with some parameters. Then, after the encode is done, imagine I redo it again with same parameters. Does that necessarly mean same I, P and B frames will be used trough both process ? Actually, I wonder if I will optain the "same" video if I encode it twice in the same way.

[turab]

2) Unless the encoded file is lossless, it's not guaranteed, since there will be distortions that affect the encoder's decision. I don't know how x264 decides frame types, but if the video isn't too distorted, I'd say that frame type is quite likely to be retained. The video overall is less likely to stay the same, due to quantising (and any other lossy process I don't know) a second time as well.

[Blue_MiSfit]

If you encode something, and then encode literally the same video with the same settings again, you will have the same GOP structure.

I believe x264 is in deterministic mode by default - meaning if you do the above, you will get exactly the same output. There is the --non-deterministic mode which should give slightly better quality when using threads, at the cost of 100% repeatability.

@turab: Which distortions are you referring to?

Derek

[turab]

By "distortion" I just meant the output being lossy. I might have misunderstood the question, though. I thought he meant re-encoding the output, not the input again.

[ajp_anton]

I believe x264 is in deterministic mode by default - meaning if you do the above, you will get exactly the same output. There is the --non-deterministic mode which should give slightly better quality when using threads, at the cost of 100% repeatability.If it increases quality, why would it be turned off (or on, however you see it)? How big is this difference?

[Blue_MiSfit]

I would imagine that x264 operates in deterministic mode by default for benchmarking purposes, but I could be wrong.

I would also imagine that the difference in any case is negligible, especially when using sane numbers of threads (i.e. less than ~36). Again, I haven't tested this, but it seems reasonable.

Derek

[sirt]

Thanks guys. Any idea for the first point ? I particulary wonder how x264 decides which frames will be a I, P or B frame. Of course, it depends on the video but do you know if there is a rule to follow ? In so far as I want to make the control myself, I want to know if that is really reasonable and usefull.

[sneaker_ger]

Your idea of manually setting all the frames? A 90 minutes movie has ~130,000 frames. You think you can manually set them?
People use that feature first and foremost for putting keyframes on chapter marks. Nobody would be so insane as to manually mark all kinds of I, P, B frames.

[sirt]

No, you misunderstood me sneaker_ger. What I want to know is how to manually mark such and such frame. Otherwise, is it possible to emulate x264 by taking the decisions oneself ? and how ? As I asked, I want to understand how x264 makes its decisions.

[sneaker_ger]

If you want to understand the math behind it, you will probably have to read the source code. These things are weighted and and have different modes/weightings. It's not something you can easily do by looking at a frame. Simplest to understand are I frames, which don't reference other frames, so x264 will try to put them on scene changes and on --keyint if necessary.

[Warperus]

sirt
how to manually mark such and such frame
For example, you have a file of 200 frames with scene changes at 40 and 100 frames. Make text file (e.g. myqpfile.txt) like this:
1 I
40 I
100 I
Then you add option --qpfile myqpfile.txt to command line and enjoy the result.

Is it possible to emulate x264 by taking the decisions oneself? Yes, it's possible, but unpractical.
Greedy to size decision is to make IPB*(repeat B frame up to maximum B frames count)PB* GoP structure. Greedy to quality is to make every frame I frame. Not that both choises are anywhere good ones though. Encoder takes into account restrictions of GoP structure, VBV buffer, scene cuts and last but not least desired quality/size. To make things harder quality depends of similarities in consecutive frames and can't be generally predicted by eyes.
You can tweak some things if you know better, but I doubt even x264 authors will be able to do it without deep math upon some source.

[sirt]

Thanks for those answers.

Warperus let's say I have a video with scene changes at 10,20,100,1000 for example. Then I type 10 I,...1000 I in a myqpfile.txt and start the encode. Do tou think that is suitable ? Can I be sure x264 will place the I frames at the same places ? Will the encode be better if I choose myself such I Frames like I visionned below ? In the other hand, it seems it is not possible to choose B Frames and P Frames like I Frames, isn't it ? I mean I Frames may be palced at scene changes but it doesn't seems to be as clear for B and P frames (pr even Key Frames).

[Warperus]

Do tou think that is suitable ?
Not really. You need new keyframe to seek somewhere and it's good to have one at the beginning of chapter, but you don't really need every little scene to have one. In your example it's better to let x264 to decide if 10/20 frames need to be IDR-frames (I in qpfile) or non-IDR I-frames (i in qpfile) or even P frames. You see, IDR-frame doesn't allow anything after to refer to something before it. That is, if you make x264 to set 10 as IDR-frame, compression virtually starts over from this point.
On the other side, 1000 I looks quite appropriate from a first glance. You will be able to seek there in no time and it's good thing.

Can I be sure x264 will place the I frames at the same places ?
No. For example, min-keyint restricts I-frames in succession. If you have min-keyint at 50, x264 will not place I-frame at 10 or 20 frames. I believe qpfile overrides this, but I don't believe x264 is capable to changing I-frame it placed before (I might be wrong). In your example I-frame at 998 will not probably be demoted to P frame after you set up I-frame at 1000.

Will the encode be better if I choose myself such I Frames like I visionned below ?
Probably not. In previous question you can see possible example of 2 IDR frames nearly next to each other. It's obviously bad for compression. I might be wrong and this concrete example might be addressed in rate control, but ovbiously there are a bit more thin examples of compression degradation.

I Frames may be palced at scene changes but it doesn't seems to be as clear for B and P frames (pr even Key Frames).
Yes, it's not clear. There are some patterns, but I'd not try to set up frame types from scratch. Trials and errors method can help sometimes. You can use the information of processed file, for example, decypher stats file from in multipass, but still it's questionable if efforts are worth it.

[akupenguin]

Greedy to size decision is to make IPB*(repeat B frame up to maximum B frames count)PB* GoP structure.
Lots of B-frames doesn't usually improve even size. There is an optimal number of B-frames in each scene, and forcing a number that's too high costs almost as much as one that's too low.

Greedy to quality is to make every frame I frame.
If you force constant QP, no IP-ratio, and deadzone-inter = deadzone-intra, then IPPP is not just smaller but also higher quality than IIII. (Not that any of those are good choices for an actual encode, but they make for a fair comparison in this contrived scenario.)

This was obvious from first principles (though I also confirmed by experiment): Inter frames allow better prediction, thus smaller residuals, thus the DCT coefs are more likely to be already very close to an integer (namely zero), thus they take less damage from any given amount of quantization. Plus there's psy effects where intra coding produces quantization noise that's independent from one frame to the next, whereas inter coding tends to produce the same artifacts in each frame of the same object, and the latter looks better because it blends in with the object's own texture.

[sirt]

akupenguin let's ask you the crucial question : can I choose myself what will be a I, P, B and Key Frame only by my eye perception or not even though it may require some specifical knowledge ?

[akupenguin]

No. Choosing between P and B frames takes math. Lots of it. No way you can match the algorithm's performance by hand.

[sirt]

akupenguin but is that algorithm really adaptative ? As I asked there, can I be sure that if I encode the same video twice same P, I, B and Key Frames will be used or is there a risk the encoder takes another - similar - decisions ?

[MasterNobody]

Slicetype decisions are deterministic so if you encode same source with same params and same x264 build on same CPU you should get same frame types (and if you didn't use VBV or --non-deterministic than output stream should be identical also).

[sirt]

Then to sum up, it appears using that qpfile parameter is useless, isn't it ? Or are they a few cases when it is usefull though ?

[turab]

If you think you're smarter than the encoder, then I suppose it is useful.

[poisondeathray]

Then to sum up, it appears using that qpfile parameter is useless, isn't it ? Or are they a few cases when it is usefull though ?

Did you read sneaker_ger's response above? Most common use is for chapters