x264 forced frametypes/keyframe use in analysis patch

[kieranrk]

What does this patch do?

Currently forced frametypes and keyframes are not taken into consideration as part of b-frame/mbtree/vbv-lookahead analysis. This patch uses forced frametypes and keyframes as part of slicetype analysis. This should improve the decisions analysis makes. It also paves the way for field coding because analysis needs to be aware of the special case field which follows an I/IDR frame. This field is a special case field because it references a frame of the opposite parity.

Patch (on latest x264-devel): http://pastebin.com/Kcvti4eE
Binary (cygwin): https://dl.dropbox.com/u/2701213/x264/forcedframes-x264-dev.zip

I would appreciate it if this could be tested with a variety of qpfile and keyframe intervals since the patch touches a lot of slicetype decision.

Updated: 1843BST 24/11/12

[benwaggoner]

What does this patch do?

Currently forced frametypes and keyframes are not taken into consideration as part of b-frame/mbtree/vbv-lookahead analysis. This patch uses forced frametypes and keyframes as part of slicetype analysis. This should improve the decisions analysis makes. It also paves the way for field coding because analysis needs to be aware of the special case field which follows an I/IDR frame. This field is a special case field because it references a frame of the opposite parity.
What impact on the output do you anticipate this patch might have? Does it only impact frame type selection?

I imagine it would mainly provide better frame type decisions around forces frames. For example, a forced (non-IDR) I-frame could eliminate the need for a "natural" I-frame the frame before, letting that I-frame become a reference B-frame.

Visually, I'd hope it would offer an overall improvement in visual quality (probably quite subtle in most cases), and reduce keyframe pop.

It'd be lovely if someday MB-Tree could cross IDR boundaries and be used to match artifacts on either side of the IDR. That would be the most effective way to reduce keyframe popping.

[akupenguin]

MB-Tree does cross IDR boundaries, precisely because not doing so would exacerbate keyframe popping. What it doesn't do is match artifacts (or deal with artifacts at all. It's a scalar-valued importance metric). Matching artifacts would have to be done during quantization, and I don't see what it has to do with MB-Tree.

[kieranrk]

What impact on the output do you anticipate this patch might have? Does it only impact frame type selection?

Visually, I'd hope it would offer an overall improvement in visual quality (probably quite subtle in most cases), and reduce keyframe pop.


It doesn't make much difference to closed GOPs with forced keyframes. It appears to improve open GOPs with b-adapt=2 because b-adapt=2 now knows that the frame at the end of the GOP is an I-frame, not a P-frame.

Probably after PAFF I'll work on reducing keyframe pop. That'll be many many months away though - it's something I've wanted to do for most of this year. :(