[MEncoder-users] new doom9 codec comparission (submission)
bugfood-ml at fatooh.org
Thu Dec 15 21:12:38 CET 2005
Wow, long email. I only have a little bit to respond to, way down at the
Doom9 Feedback Hotline wrote:
>>>I'm confused... something other than lavc was used to decode lavc when
>>>doing the quality tests? If so, that will *OBVIOUSLY* make lavc look bad
>>>due to tiny differences in the idct implementations. The only way to do a
>>>fair comparison for any codec is to use the exact same idct for decoding
>>>the one that was used for encoding.
>>>Can you get doom9 to clarify this, if you're not already clear on it?
>>I missed that when I read the paragraph last time, but I'm CC'ing Doom9
>>right now so he can respond. I'll continue relaying replies to the list.
> I'm using the ateme decoders for all codecs. I meant to use ffdshow but did
> not due to the following two issues:
> 1) discoloration whith the VMR9 renderer. Overlay is not affected but
> overlay makes screenshots impossible and has other issues (try playing
> multiple videos at once.. not pertinent to the comparison but pertinent for
> other scenarios.. there are lenghty discussions about merits of alternative
> renderers than overlay in my forum).
> 2) problems with seeking. The go to frame X functionality is extremely
> important for a codec comparison.
> In the past, Michael asked me repeatedly to use libavcodec for all codecs.
> 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..
> 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?
> 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
> than lavc. I realize that the decoder does matter, but I'm confident that
> there is no inheritent skew towards the competition in this case.. the
> rating looks the same regardless of the decoder. The only question remaining
> is which decoder, given the same source, would look the most visually
> pleasing, but that would be an issue for a decoder comparison.
> 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.
>>>this could be the reason he doesn't think lavc is good, if he's looking
>>>single screenshots and zooming in real close. See the discussion recently
>>>on the ffmpeg lists regarding the same bad quality with xvid when
>>>using lavc's default idct, or the discussions of it on multimedia.cx.
> The review has nothing to do with screenshots. Never has, never will. I've
> written about that many times
>>Take your codec comparison for example (once more, thanks a lot for
>>doing them, you're truely doing an amazing job there), it did not
>>feature lavc in the 2004 test session (when it was there in the 2003
>>test). This surely did not help to promote the very existence of lavc
> The reason for that is simple: lack of support, and very unfavorable results
> in a previous comparison, plus then lavc fans bashing me in public forums.
> I've created the qualification phase to counter the unfavorable results bit,
> but there's no substitute for support (and I must say compared to the
> 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
> single point of contact and somebody who truly knows the codecs (the two
> pass situation in Snow just outline that it has never really been done)),
> and we're all human, if you get attacked for no good reasons that colors
> your opinion. Call a test unfair and biased and you're likely to receive the
> exact same riposte, it is human nature. I'm glad that most people are
> professional about this and remain factual. It's only appropriate when I
> temporarily suspend my own codec preferences.
>>Yeah, that does happen sometimes. I'm temporarily mirroring the
>>attachments (with zip file extracted) at:
> I'm glad I'm not seeing things. It was a very hard decision to make, as an
> engineer I like to be able to properly put a finger on things, and it's not
> that apparent. I guess the untrained eye could even miss it.
>>Preparing for this comparison has been the first time I've done any
>>intensive video encoding tests in quite a while. I'm curious to try your
>>XviD encoding parameters and compare the result to my best lavc MPEG-4
> 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.
More information about the MEncoder-users