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

[D Richard Felker III]

On Sun, Sep 12, 2004 at 12:26:17AM +0400, Vladimir Mosgalin wrote:
> DRFI>> You just haven't tried right xvid options or saw only very old xvid
> DRFI>> versions, that's why you are saying so.  I encoded a lot with lavc
> DRFI>> before, and now I can say for sure: lavc sucks a lot comparing with
> DRFI>> xvid.
> DRFI>i still maintain you're doing something wrong.
> 
> How about this. Let's bet. In some days, I'll upload some parts of vobs
> and post xvid & lavc options that result in visible quality difference.
> Then, you try to modify lavc options in order to make the quality the
> same or better at the same bitrate. If you will succeed, I'll change my
> mind and won't be saying that xvid is better anymore. If you won't, you
> will stop saying that xvid is worse than lavc and admit that in some
> cases (I already wrote them: high bitrate & no postprocessing) it gives
> better quality.

the challenge is on, when i have some time. remind me once you've
uploaded some clips if i don't get around to it right away.

> DRFI>> But when making high-quality dvd-rips, you can't even compare lavc and
> DRFI>> xvid. With postprocessing, hq rips look bad - all the details are
> DRFI>i never use postproc. too slow anyway.
> 
> Hmm.. Imho pp filter isn't slow. It's faster than mpeg4 decoding in
> twisted cases, like: xvid + qpel decoded by xvid (it can't be decoded by
> lavc),

huh? lavc decodes any xvid file you throw at it. are you sure you're
not using an _ancient_ libavcodec that's not getting updated when you
cvs update? that would explain all your problems with lavc.....

> which eats about 50% of my athlon 3200+ cpu on dvd resolution.

pp filter doesn't work, in my experience. it still has blocks. you
have to use spp (at least level 3 or 4 and preferably 5 or 6) which is
very slow.

> DRFI>> blurred away. So I always make rips that do not need postprocessing
> DRFI>> (1700-2500kbit/s depending on material is enough to make very hq rip
> DRFI>normal bitrate for a dvdrip is 1300-1500, at least for anime. i've
> 
> I only encode normal movies, not anime. The amount of anime titles
> licensed in Russia on dvds is extremly small (probably 20 or so), the
> only way to get anime is collect fansubs.
> 
> DRFI>been away from hollywood crap so long i don't even remember what
> DRFI>you want for that... keep in mind anime is normally 4:3 or 16:9
> 
> Well, does it really matter if it is a "crap" or not when it comes to
> codec comparison?

no, but there could be serious differences between the codec needs of
the two.

> DRFI>rather than 64:27, so you have more pixels to encode.
> 
> 64/27? Heh.. My personal preference is 2.3, not 2.35 or 64/27...
> 
> I always try to keep original dvd resolution, without rescaling, to keep
> all the details. When width and height aren't multiplies of 8 (16 is too
> harsh) and I don't want to crop too much, I scale, say, from 708 to 704
> pixels - eye can't tell the difference.

and your eye can tell the difference between cutting off 4 pixels? :)

> DRFI>i'll try using eq2 with gamma boosted to 5.0 or something like your
> DRFI>monitor to see if they appear... :)
> 
> My gamma is fine, thanks ;)

;)

> So, how about that bet? I work at ISP now, so I can upload large parts
> of dvds without problems..

i tried this, and saw blocks in two distinct places, with q=2:
1) wherever the dvd already had blocks (yes dvds often have blocks!)
2) in near-solid-black areas, where adjacent blocks only had the dc
coefficient (solid color) and even 1 level difference between them was
made visible by the insane gamma correction.

imo there's absolutely no way to fix 2 with a block-based codec,
unless you want to do idiotic things like adding noise to the picture
to hide the difference in dc coefficients. i guess you could also use
a higher precision dct and do dithering when you decode... but the
real solution is to abandon block-based codecs.

rich