[MEncoder-users] new doom9 codec comparission

[Michael Niedermayer]

Hi

On Wed, Dec 07, 2005 at 05:41:57PM -0800, Corey Hickey wrote:
[...]
> >>Unfortunately, the quality drop from using threads=2 is, in my opinion,
> >>unacceptable.
> > 
> > Definitely. I'm against using threads.
> 
> Last night, on a whim, I decided to test qpel. Tests published by Rémi
> Guyomarch a few years ago showed a definite PSNR improvement from using
> qpel. My own tests confirmed that. Later on, I found that qpel was
> decreasing PSNR, and tests by a few other people confirmed that.
> 
> Now, oddly enough, adding qpel raised the PSNR from 42.66 to 42.96, with
> a definite corresponding quality improvement. I can't say whether qpel
> should be recommended in general, but it obviously helps under these
> specific circumstances.
> 
> Meanwhile, Michael had fixed the PSNR calculation for multithreaded
> encoding (thanks, Michael), so I ran a test with threads=2 and qpel.
> This brought PSNR down to 42.92, and I can see only a very very slight
> decrease in overall quality. Although "qpel" is the best,
> "qpel:threads=2" still looks a little better than omitting both options.
> 
> Unfortunately, adding qpel brings the second pass' fps down from 29 to
> 18. The first pass is the same (92), so the average drops from 44 to 30.

you could try subq if you still have time ...


> 
> Can anyone give me a general estimate of how much of a performance
> improvement to expect from using threads=2 on a dual-core machine? I
> don't have access to any multiprocessor/multicore setups so I can't test
> it myself. If the improvement is better than 40% or so, then I think
> qpel and threads=2 is worth it. Otherwise, I think it would be good to
> leave them both out. I'm going to wait a bit longer before I send the
> results to Doom9, but I would appreciate it if anybody gave me some
> feedback about this ASAP.

i dunno but my feeling is that the threads=2 speedup will be below 40%

[...]

> Also, my test with last_pred=2 came up identical to the default (diff
> 1.avi 2.avi). Should that be happening? DOCS/tech/snow.txt says
> last_pred has "negligible effect on both speed and quality", but I was
> expecting the files to be at least a little different. I only ended up
> testing last_pred because Michael thought it might help with
> multithreaded encoding. Of course, he was referring to mpeg-4, but I
> thought I'd try it anyway.

snow + last_pred seems broken, dont use it, i will _maybe_ look at it
tomorrow

[...]
-- 
Michael