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

[Michael Niedermayer]

Hi

On Fri, Dec 02, 2005 at 01:24:34PM -0800, Corey Hickey wrote:
> Michael Niedermayer wrote:
[...]
> > 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 try fspp 


> 
> > 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.

hmm cvs up and RTFS ;)
no seriously, i think just forget about it, its not worth it, but if you have
spare time then try it, but IIRC it only works with mpeg2, the mpeg4 case isnt
implemented and it would only work if the files was encoded with slices
thats always the case for mpeg2 but generally not for mpeg4

[...]

-- 
Michael