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

[Corey Hickey]

Wow, long email. I only have a little bit to respond to, way down at the
end.

Doom9 Feedback Hotline wrote:
> Hi
> 
>>>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 
>>>as
>>>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.
> 
>>>IMO
>>>this could be the reason he doesn't think lavc is good, if he's looking 
>>>at
>>>single screenshots and zooming in real close. See the discussion recently
>>>on the ffmpeg lists regarding the same bad quality with xvid when 
>>>decoding
>>>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
>>IMHO.
> 
> 
> 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:
>>http://fatooh.org/files/doom9tmp/attach/
> 
> 
> 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
>>encode.
> 
> 
> 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.

-Corey