Two pass encoding and MB-tree

[OpasanNekiLik]

I made several tests to see how MB-tree mechanism affects two pass encoding quality gain. I made tests with default libx264 settings.

When MB-tree is turned off two pass comparing to one pass encoding gains about 0.5dB of quality (PSNR). When MB-tree is turned on (with default lookahead window of 40 frames), the gain is 0.3dB or less for higher bitrates. Increasing lookahead window would probably make the resulting quality difference between one pass and two pass encoding even smaller. As I understand, but maybe I'm wrong, MB-tree works somehow similar to first pass encoding in two pass method, looks in advance what visual complexity is to come after current frame (not for whole movie but for limited lookahead window) and use this info for rate optimization. This way we have smaller difference in quality gain between two pass encoding and one pass with MB-tree.

There are some other effects of MB-tree on encoding speed for first pass encoding in two pass method.

Some tests you can find here (http://www.avcoding.com/2011/06/test-one-or-two-pass-encoding.html).

The question is, is two pass comparing to one pass encoding (almost double encoding time) worth this gain of 0.2dB or it is better to achieve this gain with changing some other options in one pass encoding?

I'd be glad to see what are your comments about this.

[Lam3rD]

Comparing quality with PSNR is flawed. Use your eyes.

[Groucho2004]

there's no difference between first pass parameter turbo=1 and turbo=2
:confused::confused::confused:
There is no such option for x264.

[OpasanNekiLik]

Comparing quality with PSNR is flawed. Use your eyes.I agree that PSNR is not the best measurement especially when we talk about rate optimization, but SSIM or any other objective assessment method would give similar conclusion (probably with different quality levels). Subjective assessment, if that's what you suggest, could not help with quality differences of 0.2dB.

[OpasanNekiLik]

:confused::confused::confused:
There is no such option for x264.
This is from mencoder man page for -x264encopts:
turbo=<0-2>
Fast first pass mode. During the first pass of a two or more
pass encode it is possible to gain speed by disabling some op‐
tions with negligible or even no impact on the final pass output
quality.
0 disabled (default)
1 Reduce subq, frameref and disable some inter-macroblock
partition analysis modes.
2 Reduce subq and frameref to 1, use a diamond ME search
and disable all partition analysis modes.
Level 1 can increase first pass speed up to 2x with no change in
the global PSNR of the final pass compared to a full quality
first pass.
Level 2 can increase first pass speed up to 4x with about +/-
0.05dB change in the global PSNR of the final pass compared to a
full quality first pass.

[Groucho2004]

mencoder[/CODE]

Ah, you didn't mention that you were using mencoder and not x264.

[nm]

This is from mencoder man page for -x264encopts:
turbo=<0-2>
Fast first pass mode.

That's from an old manual. If your MEncoder build is more recent, it will complain that turbo is a deprecated option and then turbo=1 and turbo=2 are both equivalent to not specifying turbo at all: fast first pass. For a slow first pass, you'd need to use option slow_firstpass (or the deprecated turbo=0).

From your article:
There is one interesting thing with encoding time of first pass. When MB-tree is off, first pass (for turbo={1,2}) encoding time is similar to second pass encoding time and rises on higher bitrates. Contrary to that when MB-tree is turned on, first pass encoding time is much less then first pass encoding time when MB-tree is turned off and it is almost constant regardless of bitrate used.

I don't see this happening in the graphs. Note that your first speed graph (the one with MB-tree off) doesn't even go low enough to show the fast first pass lines.

[OpasanNekiLik]

That's from an old manual... Thank you very much nm, you're right with both. It seems there's no three types of first pass in two pass encoding process. Also I made stupid mistake in my graph (I thought the measure was hidden behind other measure line).

I corrected my data and graphs. According to all this, it seems to me that MB-tree functionality has the same effect on one pass encoding as first pass in two pass encoding but on much smaller scale. I'd like to hear am I wrong if I say the bigger lookahead MB-tree window is in one pass encoding the more this one pass encoding with MB-tree looks as two pass encoding.

[LoRd_MuldeR]

I agree that PSNR is not the best measurement especially when we talk about rate optimization, but SSIM or any other objective assessment method would give similar conclusion (probably with different quality levels). Subjective assessment, if that's what you suggest, could not help with quality differences of 0.2dB.

Even if you are aware of the limited expressiveness of PSNR/SSIM values, you still cannot use them with x264, unless you have specified "--tune psnr" or "--tune ssim" (or whatever the corresponding MEncoder parameters are) in your encoder options. That's because x264 has psychovisual optimizations enabled by default, which optimize against PSNR/SSIM and thus your results will be flawed...

[Dark Shikari]

Even if you are aware of the limited expressiveness of PSNR/SSIM values, you still cannot use them with x264, unless you have specified "--tune psnr" or "--tune ssim" (or whatever the corresponding MEncoder parameters are) in your encoder options. That's because x264 has psychovisual optimizations enabled by default, which optimize against PSNR/SSIM and thus your results will be flawed...They're not particularly bad to use to measure the effects of MB-tree, as none of the psychovisual optimizations are related to ratecontrol.

[OpasanNekiLik]

They're not particularly bad to use to measure the effects of MB-tree, as none of the psychovisual optimizations are related to ratecontrol.How's that none of the psychovisual optimizations are related to ratecontrol!? For example ratecontrol (RDO) uses higher QP for scenes with more movement and lower QP for more static scenes because HVS can recognize more details in static scenes and less in dynamic ones. Saving some bits on dynamic scenes this way these bits can be used elsewhere and this ratecontrol results in better psychovisual distribution and general perception of quality. (Of course, having higher QP for dynmic scene does not mean that in dynamic scene less bits than in static scene will be used. No, because dynamic scenes will have much more MVs. It only means that ratecontrol will save some extra amount of bits on dynamic scenes.) On the other hand PSNR and SSIM assesments do not take into account dynamicity of scene, they just calculate how encoded pixels differ from pixels in reference frame regardless of its dynamicity nature.