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

[Guillaume POIRIER]

Hi there,
Le dim 05/09/2004 à 16:19, Edouard Gomez a écrit :
> 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.
I agree. Small increase of encoding time, and small PSNR increase. 
To me, it looks like a win-win option that is worth being activated all
the time, totally the opposite of qpel, which can sometimes harm.

> 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.
I re-encoded the video (a 30-min camcorder clip with lots of movements).
There might me a little bit of jitter on encoding time as there were
other process running during the encoding process.

with bvhq:
2nd pass at 9fps, total encoding time: 1hrs 51min 56sec
Video stream: 1375,072 kbit/s  (171884 bps)  size: 332183093 bytes 
1932,600 secs  48318 frames
The value 99.99dB is a special value and represents the upper range
limit
xvid:     Min PSNR y : 37,35 dB, u : 46,05 dB, v : 46,89 dB, in frame
8398
xvid: Average PSNR y : 43,47 dB, u : 46,33 dB, v : 46,42 dB, for 48313
frames
xvid:     Max PSNR y : 48,01 dB, u : 47,00 dB, v : 47,98 dB, in frame 0

without bvhq:
2nd pass at 9fps, total encoding time: 1hrs 46min 49sec
Video stream: 1375,080 kbit/s  (171885 bps)  size: 332184983 bytes 
1932,600 secs  48318 frames
The value 99.99dB is a special value and represents the upper range
limit
xvid:     Min PSNR y : 37,57 dB, u : 45,32 dB, v : 45,53 dB, in frame
48026
xvid: Average PSNR y : 43,40 dB, u : 46,30 dB, v : 46,40 dB, for 48313
frames
xvid:     Max PSNR y : 48,01 dB, u : 47,00 dB, v : 47,98 dB, in frame 0

For the sake of comprehensiveness, the encoding options were:
me_quality=6:chroma_me:chroma_opt:gmc:trellis:closed_gop:
max_bframes=2:hq_ac:vhq=4:qpel:autoaspect:psnr
(apart from bvqh, off course)


So we'got a Y +0.07, U +0.03, V -0.02 dB gain, and the video is
slightly smaller. Not bad!

Regarding the quality of the output with my very own eyes, I couldn't say...
That's maybe because the input video was a little bit noisy.
I should try it on a whole hollywood movie.
If you have other test-cases suggestions, please let me know (but no
"The Matrix", scene xxx test! ;-))

> 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.
[..]
Thanks for the explanation. Although I have little video knowledge, I
understood it very well.
Did you ever though about being a teacher instead of an engineer? ;-)

> 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.
Do you plan to add other "incremental modes" to bvhq, just like vhq?

> 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.
Does that means that it reduces the likelihood of having a blocky video?

Regards,
Guillaume