x264 Keyframe placement issues in Multithreading mode

[DeathTheSheep]

The videos I encoded with x264 with threads=0 (baseline profile) resulted in keyframes exactly 500 frames apart (which I designated to be the MAX interval), whereas identical encodes with threads=1 resulted in proper keyframe placement (every scene change, more or less).

Has anyone else had this problem? It seems to occur on all sources I use at QVGA resolution.

[akupenguin]

It's caused by --pre-scenecut, which is forced on if you enable multithreading.
Since pre-scenecut is recent, it hasn't been tuned as much as the original scenecut algorithm. And it's inherently a bit less precise since it operates on the lowres pre-pass instead of the real encode.

[check]

As I understand it, a P frame can be made completely out of non predicted macroblocks, so the only quality loss would be from inopportune IDR frame placement. Is this correct, and what sort of quality loss does this entail?

[Manao]

There's a usability loss : IDR, inserted on scene cuts, allow a better editability. Most people don't care about that - I for one - but it still a loss. As for the efficiency loss itself, in average, I'd say an I frame is 3 times bigger than a P frame, for the same quality. So, if you use a maximum IDR interval of 500, and that IDR are only inserted every 500 frames, you'll end up with a 0.4% bitrate increase, which can be translated in PSNR by a 0.02 dB loss : you won't notice it.

Were the interval 100, the bitrate increase would be 2%, the quality loss 0.1 dB. That's hardly noticable either.

So there's no real big quality loss for intra insertion mechanism.

However, it's also good to notice that Pframe on scene cuts may be less efficient than Iframe. It's a close call for CABAC, but for CAVLC it's likely to be true.

Furthermore, x264 lowers the quantizer on I frame. There's a reason for that. If scenecuts are encoded as P frames, they won't be improved, and that will hurt the quality ( much more than everything else described previously ).

[DeathTheSheep]

There is quite a noticeable quality loss at my end.

I use one-pass constant quantizer on ultra-low-bitrate anime content (often in CAVLC). P-frames are *not* the "same quality" as I-frames in this mode, with a keyframe boost of 40.

I usually let x264 decide on where to put the keyframes, and it usually does so at every scene-change, resulting in awesome quality static backdrops/backgrounds (due to keyframes being placed appropriately on them) along with hardly-noticeable P degradation (it's anime, the backdrops matter a lot).

I also let max I-interval be 1500 frames on this material so x264 places keyframes only at scene-changes, where the quality jumps up for the new scene and stays at that level until the end of the scene, whereupon a new keyframe is placed at the start of the next, contributing to overall high quality.

But what the new multi-threading mode entails is:
1. Absolutely *no* keyframe detection on constant quantizer (1-pass) mode--not simply reduced accuracy, but none at all.
2. If max IDR interval is set to less (say 300), allowing a normal amount of keyframes to be placed, the backdrops will have terrible quality until suddenly the quality skyrockets at random (because it will have been 300 frames at that point), and then later at a scenechange, the backdrops will have terrible quality again. At high quantizers, remember, motion trails, artifacts, washing, etc become very apparent.

Is the new multi-threading mode is therefore next-to-useless for these purposes?

[akupenguin]

So help me improve the algorithm:
Compile x264 with this patch (http://akuvian.org/src/x264/x264_prescenecut_debug.0.diff).
For each encode that makes good decisions when single-threaded and bad decisions when multithreaded: Run the encode with the patched x264, in single-threaded mode, with the addition of "-v" to the comandline. (In a 2pass, you only need to run the 1st pass for this, since that's when scenecut decisions are made.) Save everything that x264 prints (should be multiple lines of text per frame), and send it to me.

[bob0r]

http://x264.nl/x264_622.exe
http://x264.nl/x264_622_prescenecut_debug.exe

[DeathTheSheep]

Done. Test pack with both clips, both logs, commandline used, and all debug info, taken from MeGUI's log screen too.

http://www.gabextreme.com/testpack.zip (< 20MB)

I think it should be pretty obvious on this clip (just snap to keyframes or scroll through it with TCPMP to see what it means for this clip visually)...

On actual, stiller things like full anime episodes, it becomes much more of a problem (as I'd said above) than on a high pace music vid that I included for practical reasons :)

[akupenguin]

Thanks, that log instantly pointed out the problem, which had nothing to do with the difference between the scenecut algorithms themselves. It just wasn't running at all, since I put it in with the B-adapt code and you didn't use B-frames.
623.

[DeathTheSheep]

No problem, anytime! :)

And thanks for the work you put into x264!

[DeathTheSheep]

Oh, I just have one more problem (for now, at least):

ESA and MT don't seem to be compatible. I use ESA (along with --subme 7) occasionally for very low-bitrate anime, and it seemed to slightly reduce motion trails and artifacting at obscenely low bitrates in CAVLC.

In addition, ESA seems quite fast now (I get encoding speeds of 60fps at 320x208 in single-threaded mode on my Core2Duo). However, when I use MT, the log gives me some sort of warning about threads and ESA, but completes the encode anyway. What does this mean?

[akupenguin]

There's nothing inherently incompatible about ESA and MT, I just haven't implemented it. So x264 uses UMH instead.