[XviD-devel] [FRONTEND UPDATE] mplayer modules.

[Edouard Gomez]

Guillaume POIRIER (guigui-nospam at laposte.net) wrote:
> It does not seem to affect encoding time, and increases PSNR quite a bit.

Not much in fact.

> without bvhq:
> Video stream:  644,510 kbit/s  (80563 bps)  size: 1601607 bytes  19,880 secs  500 frames
> The value 99.99dB is a special value and represents the upper range limit
> xvid:     Min PSNR y : 39,11 dB, u : 43,57 dB, v : 44,06 dB, in frame 374
> xvid: Average PSNR y : 41,12 dB, u : 44,43 dB, v : 44,54 dB, for 495 frames
> xvid:     Max PSNR y : 45,30 dB, u : 46,90 dB, v : 47,14 dB, in frame 250
> 
> with bvhq:
> Video stream:  652,880 kbit/s  (81610 bps)  size: 1622407 bytes  19,880
> secs  500 frames
> The value 99.99dB is a special value and represents the upper range limit
> xvid:     Min PSNR y : 39,14 dB, u : 43,68 dB, v : 43,96 dB, in frame 386
> xvid: Average PSNR y : 41,20 dB, u : 44,49 dB, v : 44,59 dB, for 495 frames
> xvid:     Max PSNR y : 45,30 dB, u : 46,90 dB, v : 47,14 dB, in frame 250

0.1dB is a good improvement, but not really perceivable by
HVS...

> The slight problem I see here is it affects target size by 1.3%, but I
> guess that's not much.

Your sequence length was too short for 2pass to be really
efficient at predicting, so i guess it's just the result of
some misprediction errors on a few frames that take a big
importance given the small number of frames.
 
> What is bvhq supposed to do anyway? Google and grep didn't help me
> much...

bvhq is VHQ for bframes. In 1.0.x series, vhq was implemented
for P frames. For 1.1.x series, bframes can use vhq too.

So the real question is: what is vhq ?
 - The name... only sysKin knows why it's called vhq. Sounded
   cool iirc
 - the magic behind the scenes is simple:

ME step tries to figure out what vector is best for a block.
But, most of ME routines use SAD which gives the distance
between two blocks in the usual YUV space. That's sub-optimal
because of one thing:
 - what the coder encodes is not the YUV difference between
   the prediction and the coded block, it's DCTed coefficients,
   rearranged as (run,last,level) tuples.

VHQ is the answer to this simple problem, it does
Rate-Distortion optimized decision. Rate-Distortion optimized
means that for a decision, the (rate,distortion) tuple is a
local minimum (rate is bits spent to code the block,
distortion is the energy of the residual of the block, squared
sum of pixel distance):
 - vhq1 looks what block mode for the *chosen* candidate is RD best
 - VHQ>1 uses RD decision for choosing *candiates*. The bigger VHQ,
   the more RD decisions (and thus costly RD operators) are
   used. VHQ4 makes use of RD operators for nearly all
   decisions.

bvhq, as stated in my frontend update announce is now just
bvhq=(0|1), which means vector candidates for bframes are
choosed the usual SAD operator way, but the final decision
made to choose which to use for the coding is done using a RD
optimized operator.

More than a small PSNR increase, i think this option brings
better looking bocks for bvops, even if that isn't directly
appearing in the "articificial" PSNR value.

For me, bvhq is just more pleasant bvops.

-- 
Edouard Gomez