[MPlayer-users] MPlayer-1.0pre4 bug with divx4 multipass filter

[Yang Yang]

hi Vladimir:

	thanks for the info

well, the problem I have now, is that lavc produces an avi file with 
very apparent mosaic, I just used the single vcodec=mpeg4 to lavcopts,
at a slightly larger file size, divx4 gives a very smooth avi, 
what's more, divx4 seems to use the "segmentation" algorithm ( I have a
vague impression that mpeg4 does compression by singling out segments
from pictures ) better. this is achieved by giving vbr=2:pass=1 to 
divx4opts option, 

do you have an idea how to get rid of the mosaic?



unfortunately the second pass (and futher passes) of divx4 doesn't
work, previously I had experience with the "original 2 pass" (
instead of the vbr=2/3 n-pass ) mode, that quality wasn't very well.
vbr=2/3/5/6 is not documented yet, I checked the code, it is only
avaiable from  version 5200 (5.2.0??) , i.e. divx4linux20030428,
after a long while of fiddling with gdb, I found out the weird
program behavior was due to my gdb, ------ I did some crude
"printf" check, the parameters seem correct all the way till entry
to encore(),  then the bug is in encore, provided by divx,


anybody in the developer team could check if the bug is on the
libdivxencore.so or is it in mencoder interface? ------- or is it just a
"Pro feature " that divx intentinally left out from us?


Yang

On Sat, Sep 11, 2004 at 12:26:52PM +0400, Vladimir Mosgalin wrote:
> On Fri, 10 Sep 2004, D Richard Felker III wrote:
> 
> DRFI>> Try xvid. It's much better than both of them on high bitrate. I'm
> DRFI>> pretty
> DRFI>
> DRFI>false. lavc is the best, just try comparing psnr or double-blind.
> 
> I learned this a long time ago - never ever compare psnr, it's quite
> meaningless. Large difference in psnr values can easily be seen, and
> small differences can't be trusted at all.
> 
> DRFI>perhaps you're just using dumb options.
> 
> You just haven't tried right xvid options or saw only very old xvid
> versions, that's why you are saying so.  I encoded a lot with lavc
> before, and now I can say for sure: lavc sucks a lot comparing with
> xvid. lavc _can_ be sometimes better than xvid: when you need realtime
> encode, or when you are encoding to low or average bitrate and aim for
> postprocessing with pp or spp filters.
> 
> But when making high-quality dvd-rips, you can't even compare lavc and
> xvid. With postprocessing, hq rips look bad - all the details are
> blurred away. So I always make rips that do not need postprocessing
> (1700-2500kbit/s depending on material is enough to make very hq rip
> with the right settings). Sadly, on most types on content it's nearly
> impossible with lavc. Scenes with qp=2 look extremly bad (and I don't
> want to discuss my monitor, gamma, brightness and eyes - they are
> perfectly well). In a lot of scenes, you can see blocks everywhere!
> With xvid, qp=2 will lead to perfect result. The bitrate will be
> ~1.3-1.5 times higher than with lavc, though; but with qp=3, the result
> is still much better than lavc's and bitrate is smaller.
> 
> That's where b-frames kick in and improve quality a lot. With the
> "regular" xvid settings for the first pass, i/p frames with qp=2 and 2
> b-frames with qp=4, the quality almost always is very good.  On the
> second pass, bitrate can be reduced by 20-30% without visible quality
> loss. At the same bitrate, lavc produces only low-quality video that can
> either be watched with postprocessing (thus with washed out details), or
> with a lot of blocking.
> 
> With xvid, it's extremly hard to find the content that will lead to
> blocks at the same bitrate. The still frames everywhere, even on fast
> motion scenes look exactly like original ones.  When switching between
> two, eye can't tell the difference. With lavc, it is only possible with
> qp=1 and insanely high bitrates (higher than original ones).
> 
> -- 
> 
> Vladimir
> 
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-users