[MEncoder-users] new doom9 codec comparission (submission)
dalias at aerifal.cx
Sat Dec 17 01:09:56 CET 2005
On Fri, Dec 16, 2005 at 11:16:09PM +0100, Mathieu Monnier wrote:
> >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
> 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.
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
> >We do not endorse quicktime (aka mp4) format whatsoever. In fact it's
> > widely considered the be the absolute worst container format out
> 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.
More information about the MEncoder-users