[MEncoder-users] new doom9 codec comparission (also questions for Doom9)

[Corey Hickey]

Michael Niedermayer wrote:
>>1. I don't know much about postprocessing. On the encoding I'm doing
>>right now, pp=ac looks a little less blocky than pp=fa. Does anyone have
>>a good recommendation?
> 
> i would recommand against pp=fa its just based on filters invented by me
> which are supposed to be fast and not perfect, if you want more speed try
> without the dering filter (pp=ha:128:7,va) but whatever you choose
> test it first, dont blindly trust my suggestion ...

I forgot to mention: I can't see any difference between pp=de and pp=ac.
Decoding speed of pp=de and pp=ac is ok -- if Doom9 is doing to test on
an Athlon64 the postprocessing overhead of each of those will be negligable.

> also definitly try to add some noise, it might look better, something on
> windows, does add noise by default, i never could figure out what part it
> was (the noise was vissible with ffdshow even though it had all noise adding
> filters disabled ..., but that was long ago)

Thanks for mentioning that -- I forgot about noise.

> if possible also test with TFT & CRT monitors (btw, doom9 which do you use,
> ive seen quite some differences in artifact vissibility between CRT and TFT)

I know what you mean. Blocking artifacts really stand out when I play
video on my laptop. The postprocessing should alleviate that problem.

> also try the newer spp based postprocessing filters if the CPU is fast enough

I'm starting to really like spp=2,noise=3ah
- spp seems to deblock without smearing as much of the original detail
- adding noise masks the smeared parts and makes places where the film
grain managed to get encoded stand out a bit less.

> also see http://guru.multimedia.cx/?p=8 for some pp compaission, maybe ill
> add more variants ...
> 
> 
> [...]
> 
>>3. I seem to recall that multithreaded encoding incurs a slight penalty
>>to quality (or, at least, psnr). Do any particular lavcopts make
>>multithreaded encoding better or worse? If not, I'm just going to find
>>the best options I can with only one thread and, as a final step, test
>>threads=2 to make sure nothing blows up.
> 
> 
> hmm, a larger last_pred and preme=2 might help a little for the multithreading
> stuff, someone could also try to do just the motion estimation or just the
> bitstream encoding multithreaded (needs code change, maybe ill take a look but
> dont hold your breath ...)
> 
> and maybe try multithreded decoding too

Are you referring to something I should try or something you should
write? :) I don't see anything in the man page about multithreaded decoding.

>>
>>------------------------------------------------------------------------
>>Last, some comments.
>>
>>Right now I'm testing the following command:
>>for i in 1 2 ; do
>>  time mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \
>>-vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \
>>vcodec=mpeg4:vbitrate=581:vratetol=1000:psnr:vpass=$i:mbd=2:mv0:trell:\
>>cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv \
>>-ofps 24000/1001
>>done
> 
> 
> dont forget to remove psnr in the final suggestion, it eats some precious cpu
> time, also try NSSE maybe

Got it.

-Corey