[MEncoder-users] new doom9 codec comparission (submission)

[Rich Felker]

On Thu, Dec 15, 2005 at 12:12:38PM -0800, Corey Hickey wrote:
> > In the past, Michael asked me repeatedly to use libavcodec for all codecs. 

How far in the past? These issues weren't known until September 2005.
BTW here are screenshots of XVID decoded with both XVID IDCT and
ffmpeg's default mpeg4 idct:

XviD: http://img39.imageshack.us/img39/3341/154xvid6xt.png
libavcodec: http://img39.imageshack.us/img39/4590/154avcodec2da.png

XviD: http://img39.imageshack.us/img39/6135/283xvid3tg.png
libavcodec: http://img39.imageshack.us/img39/573/283avcodec5xl.png

As you can see, the ones decoded with the 'wrong' idct look bad in the
same way (or at least a very similar way) that lavc mpeg4 looked bad
in the doom9 tests!

I am by no means positive that this is the problem, but I definitely
think it's worth investigating more.

> > So you see where I'd be having a problem with your argumentation that the 
> > comparison isn't fair. If it isn't fair, the what Michael asked me is to 
> > skew the results of the entire comparison in favor of lavc. Is that what 
> > you're saying?  And consider the implications of that..

Unless this was recent, the issue was simply not known at the time.
Also lavc has configurable idct implementation, and you can select it
in ffdshow's gui too. Note (IMPORTANT!) that I do not know what
ffdshow's default is, or if its default is the same as ffmpeg's
orginary default.

> > According to this logic, since I used the ateme decoder, ateme should've had 
> > a significant advantage over the two other ASP codecs in the qualification. 
> > Yet why is it that I would put it in place 3 out of 3?

Probably because the ateme encoder sucks. Matching idct implementation
will not make up for an encoder that otherwise sucks.

> > But the last straw is that I actually tried ffdshow. I watched the lobby 
> > shootout again, XviD and lavc only. Now that makes two scenarios where XviD 
> > would have a so called disadvantage, yet despite that it still looks better 

I thought you said that you weren't able to get proper screenshots
using ffdshow...?

> > Last but not least, while in AVI we have the fourCC to make the codec 
> > selection, there's no such thing for MP4 so unless you deactivate filters 
> > for each clip you play, or mess around with filter merits, it's one filter 
> > to decode them all.

We do not endorse quicktime (aka mp4) format whatsoever. In fact it's
widely considered the be the absolute worst container format out
there.

> > competition, the two libavcodec codecs required way more of my time than 
> > most of the other contestants together.. it is much easier if there's a 

The opposite is true for unix users, of course. I acknowledge that you
use Windows and most of your audience does. If we've publicly flamed
you in the past, it's been because of a perception that you're biased
towards Windows tools and codecs which we have always found (through
everyday use and experience, not formal testing) to perform much
worse. I now don't believe that you have such a bias, but I do have my
doubts about whether your testing methodology is perfect.

> > There's one thing to keep in mind: the only proper XviD implementation is 
> > the VfW one. I actually implemented XviD support based on mencoder in MeGUI, 
> > and the people who dared to try and go ahead with it, came back to the XviD 
> > VfW after a few attempts as they found severe issues with XviD in mencoder. 
> > One of them is that there is an issue hitting the target size (for whatever 
> > reason, the VfW is dead accurate), mencoder writing unplayable files (if the 
> > filesize goes beyond 2 or 4 GB.. I'm not sure but if you search for megui 
> > and xvid in my forum you'll find these things), and there are many options 
> > missing as well. This may be migitated when the updated xvid_encraw becomes 
> > available, but seeing that on Linux people tend to use mencoder, ffmpeg or 
> > vlc for encoding, it would still require a shift in tools, and human beings 
> > are animals of habit.
> 
> I'll try to reproduce those problems later. They may not be an issue
> anymore -- mencoder has opendml support now and, as far as I know, the
> xvid support is up-to-date.

Reports indicate that OpenDML support may be broken. :(

BTW to Corey: I think all the situations in which lavc seems to have
done poorly in the first round might be improved significantly by
using *cmp=10. This improves preservation of tiny detail at the
possible expense of overall quality, but postprocessing should
(hopefully) be masking those losses.

Rich