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

[Rich Felker]

On Fri, Dec 16, 2005 at 11:16:09PM +0100, Mathieu Monnier wrote:
> Hi,
> 
> >XviD: http://img39.imageshack.us/img39/3341/154xvid6xt.png 
> >libavcodec: http://img39.imageshack.us/img39/4590/154avcodec2da.png
> 
> Fair example
> 
> >>XviD: http://img39.imageshack.us/img39/6135/283xvid3tg.png
> >libavcodec: http://img39.imageshack.us/img39/573/283avcodec5xl.png
> 
> Not so fair, both are as worthy imho

Look closer, the lavc-decoded one is splotchy. I can even see it on my
CRT if I look closely. Admittedly I wouldn't care whatsoever while
watching it in motion, I'm sure.

> Btw, how did you get that posterized look for your screenshots ? Did the
> source looked like that ?

I didn't make them, they're from the thread on ffmpeg-devel where the
'bug' was first reported.

> >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!
> 
> Definitely not. In Doom9 test, when he criticizes FMP4, it's for a lack
> of details. Idct mismatches don't make details disappear. They create
> chroma drifts, and additionnal noise. What I see on screenshots where 
> Doom9 points a lack of detail is flat blocks ( and that's without 
> zooming, but on a LCD ).

The above pictures also show lack of detail, with splotchiness in its
place.

> Loren has given a possible reason for the assumed inferioty of FMP4 in 
> Doom9 test ( bframes ). Here's another : rate control.

Yes I read those and also offered another possible reason (*cmp!=10).

> You don't know the quantizer at which the frames have been taken, you 
> don't know the quality of their preceding frames nor their type. So why 
> care about what they look like.

Eh?
BTW that's another issue. With motion compensation working really
well, it's possible for a codec to make a near-perfect representation
of a frame even with q=3 or 4. However postprocessing will then
destroy that perfection by blurring it out. I doubt that's the issue
here, but personally I'd prefer to compare without postproc (I never
use postproc myself anyway).

> >>>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...?
> 
> So it has been invastigated more, yet you don't think it's enough, and
> you even doubt his words ?

I'm confused about what he means.

> Where did he say he made screenshots ? Why 
> would he need to make some to spot the lack of details ? Can't he simply 
> use the pause button ?

No. You can only compare the two codecs if you can switch back and
forth between the two images identically positioned. Even if you could
compare two positioned side-by-side, video cards only have one overlay
device, so the second movie would be rendered without overlay and
would thus look quite different, making comparison impossible.

> >>>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.
> 
> Yeah of course it sucks. You can also read the test to from head to tail
> and see that it is 5 times faster than FMP4. So perhaps it only has a
> different speed quality tradeoff.

FMP4 will be 5 times faster than ateme if you turn off all the
insane-quality options, and probably still will look better than
ateme..

> >We do not endorse quicktime (aka mp4) format whatsoever. In fact it's
> > widely considered the be the absolute worst container format out 
> >there.
> 
> First time I heard that one.

Sorry, actually it's about tied with ogg. :)

> He raised an issue which is present
> with any container anyway since it's the mpeg4 standard fault.

How so? Anyway all the mpeg4 codecs I know include information in the
bitstream to identify which implementation it was encoded with, even
without fourcc. I was just ranting about doom9 basing his argument on
a need to work with the hideous mp4 format.

Rich