[MPlayer-users] Re: divx 6

[Rich Felker]

On Wed, May 03, 2006 at 11:30:17AM +0200, Matthias Wieser wrote:
> Am Dienstag, 2. Mai 2006 16:48 schrieb Rich Felker:
> > On Tue, May 02, 2006 at 10:35:45AM +0200, Matthias Wieser wrote:
> > > >> > "The archives" refers to mplayer-users mailing list and possibly
> > > >> > -dev-eng and ffmpeg-* lists.
> > > >>
> > > >> I'm subscribed to all of those. URL?
> > > >
> > > > Not my job. Go read it yourself.
> > >
> > > YOU claim that there have been testing fallacies which doom9 refused
> > > to acknowledge. I followed the disussion and did not see those. Others
> > > on lis list did not see them, too. So either prove your claim or stop
> > > to allege that others are liars or did not read the discussion.
> >
> > Apparently you're just as stupid as doom9 himself and don't understand
> > the words IDCT mismatch.
> 
> The IDCT topic has been discussed to death. This effect is way to small to 
> explain the worse quality (in comparison to xvid, divx) of lavc. You have 
> not been able to show that the differences are so large that they matter.

It's not my job to show that they matter. If doom9 is going to use the
wrong IDCT it's HIS JOB to show that there's no difference. Otherwise
his testing methodology is invalid.

Furthermore, the EXACT SAME ISSUE caused significant visual problems
the other way around, when decoding XVID using the default lavc idct
or the C (non-MMX) XVID IDCT (which is stupidly not the same as their
MMX one). This issue was discussed in depth on ffmpeg-devel and
eventually an XVID-compatible IDCT was added for decoding XVID files
with maximal quality.

I have no evidence that the quality differences in doom9's test came
from IDCT discrepency, but the types of errors look VERY SIMILAR
visually to the IDCT discrepency problem described on the ffmpeg-devel
list with XVID.

> > Or the fact that doom9 was using broken windows tools (with possibly
> > different semantics and bugs)
> 
> Which bug numbers are you refering to? Or just plain FUD?

Huh?

> > to do the  
> > lavc encode rather than using the mencoder commandline he was given,
> > and HIDING this fact from everyone.
> 
> 1. HINT: Doom9 did a codec comparison (=> libav codec), not a video tool
>    (mencoder) comparison. That's why they call it "Codec shoot-out 2005".

There are exactly two programs with which lavc encoding can be tested
validly: ffmpeg and mencoder. ffdshow, which I believe doom9 used, is
a MODIFIED version of libavcodec with DIFFERENT DEFAULTS and has
historically had bugs and misbehavior that made it produce bad output.
We do not trust it.

In any case, doom9 was misleading from the very beginning about what
software he was using, etc. He was intentionally being evasive because
he knew his procedures were controversial and didn't want to admit it.

> 3. They used MP4 format:
>    "To level the MPEG-4 playfield somewhat, this year all MPEG-4 codecs will
>     be using the MP4 container. Non MPEG-4 codecs will use the AVI container
>     or their native container."  (Does mencoder 1.0pre7 support MP4? :-)

The container is absolutely irrelevant to testing codecs. If he really
cared he could have remuxed into .mp4 with another program, but the
very fact that he wanted to use .mp4 proves his technical
incompetence.

> 4. They are not HIDING anything but they clearly state what software they 
> used:
> 	"To encode I used the following software:
> 	 DGIndex 1.4.5 & DGDecode
> 	 AviSynth 2.55 for frameserving (avs2yuv doesn't support 2.56)
> 	 VirtualDub 1.6.11 for VfW encoding
> 	 Nandub 1.0 RC2 lumafix to multiplex AVI
> 	 Mp4box CSV dated November 24th to multiplex MP4"

I'm talking about what he revealed at the time when we initially
questioned his methodology, not in the end. If he used VirtualDub/VfW
for lavc testing then he was using ffdshow which is NOT LIBAVCODEC but
a MODIFIED VERSION.

Rich