[MPlayer-users] lavc vs. xvid (and improving lavc quality)

[rcooley]

On Sat, 29 May 2004 14:49:16 -0400
Jason Tackaberry <tack at sault.org> wrote:

> I did try a number of lavc options suggested on this
> list and others, including H263 quantizers

H.263 quant is the default.  I suppose you mean mpeg_quant, which I
recomend myself for sharp detail (doubt it helps with
blockiness).

> After reading an article on doom9 that stacked up a number of codecs,

Rich already said it himself.  I'll second that, and I'm sure you cound
find many others who would agree.  Doom9's codec comparison is a
ridiculous sham.
 
> Unfortunately, xvid is also nearly an order of magnitude slower than
> lavc.  I wonder if I've messed something up.  Encoding at 3fps is
> terribly frustrating when lavc gives me 25fps. :)

Xvid seems to be about 1/3rd as fast as lavc in my experience.  Perhaps
you are using a beta version, or passing weird options to it via
mplayer?
 
> I picked xvid 5 out of 5 times, although 2 of the clips were close
> calls.

Could possibly still be wishful thinking.  You've really only proven
that you are able to tell the difference between lavc and xvid encoded
video.  Different codecs have different artifacts, so this isn't
groundbreaking.

>    qpel:precmp=3:cmp=3:subcmp=3:vmax_b_frames=1:vlelim=-2:vcelim=7:lu
>    mi_mask=0.05:vqcomp=0.7:mbcmp=2 

With vqcomp, I recomend going with smaller values, not larger ones. 
That gives more bits to motion.  Since not having enough bits for a
still-scene is rarely ever a problem, I can't see any reason for
vqcomp>0.5.  Then again, I don't see any benefit from it when encoding
in 2-pass mode.


> I'm wondering if there's some magic lavc option I haven't discovered.
> The get_rid_of_blocky_artifacts=1 option.  

Have you even searched through the man-page?  

       scplx_mask=<0.0-1.0>
              spatial complexity  masking.   Larger  values  help
              against *blockiness*, if no deblocking filter is used
              for decoding.

Try with lowest values first, and work your way up.  It actually didn't
work well for me when I last tried it.  It was very low quality,
and wouldn't produce a larger file even when I increased bitrate.  Hope
it works out better for you.

Incidentally, why aren't you using 2-pass mode and post-processing? 
Allowing a codec to dynamically change the quant results in much more
bits being allocated where they are needed, and postprocessing would
solve your blockiness problem completely, without any real drawbacks.