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

[D Richard Felker III]

On Tue, Sep 14, 2004 at 10:09:19AM +0400, Vladimir Mosgalin wrote:
> On Mon, 13 Sep 2004, D Richard Felker III wrote:
> 
> DRFI>> His methods must be incorrect (well, not really, but they aren't showing
> DRFI>> the real situation, because this is comparsion of the worst case with
> DRFI>> the best case). With the method "encode with qp=2 and compare the
> DRFI>> difference in filesize" I get insignificant difference. Up to 1%, maybe.
> DRFI>
> DRFI>your test is not valid. you need to compare the psnr for both files
> DRFI>too. the psnr for the incorrect-sized file will be much worse
> DRFI>because the partial blocks at the edge don't encode well!
> 
> I understand this, but doesn psnr really matter as long as they look
> good? Say, with height 360 352 pixels must be the same, remaining 8 must
> be encoded _worse_ and lower overall psnr,

if they look really bad (which they will!!) then why do you insist on
keeping them there?? an ugly distraction at the edge of the picture is
a lot worse than just throwing the pixels away. you really seem to
have some kind of hangup about throwing pixels away...if it's a pixel,
it matters, but if it's all the bits of precision lost from misaligned
dct at the edge of the picture, those don't matter. i don't get it...

> but they look ok - so there
> are no problems with it.

_maybe_ not if you use constant-q encoding. but if you've specified a
bitrate, lots of bits _will_ be wasted on those extra 8 lines and
lower the quality of the rest of the picture. there's also the fact
that motion estimation will fail at the boundaries, and thus a lot
more of the picture will get encoded with texture. now it's not
necessarily true, but in general texture can have much higher error,
and it's best to use motion vectors for as much as you can...

> PSNR test must be mathematically correct, but video isn't about math..
> The psnr difference isn't meaningful in this case, just like in many
> others.

psnr difference is almost always meaningful, if you're using it
correctly.

> DRFI>mod4 is useless, and mod8 barely helps. at least you're not stupid
> 
> Not really. Who knows, maybe I'm encoding interlaced video and don't
> want any chroma problems?

at least you understand enough to know that you must use at least
h%4==0 for interlaced video...

> DRFI>at this point, you've repeatedly insisted on doing things that are
> DRFI>proven to lower quality significantly, and then you complain about
> DRFI>lavc being low quality without any proof, when all my experience has
> DRFI>shown the opposite. this conversation is getting really stupid. if you
> DRFI>want to continue it, post a sample "challenge" file with your xvid
> DRFI>encode and the original, and i'll encode with lavc.
> 
> OK, just wait a few more days. I barely have free time right now. And I
> waste half of it on these mails...

ok...

rich