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

[Doom9 Feedback Hotline]

I have just added the following FAQ question, based on the instructions for 
the comparison I sent to each participiant:

Q20: How do you judge video quality?

Purely on watching the video in full screen mode, sitting at the regular 
working distance from the screen (not the distance you'd pick to normally 
watch a video). I divide review scenes in smaller parts and look at the 
various scenes one after another, going back and forth between codecs to 
find differences, and intermittently looking at the source as well, to get a 
feeling of how codecs rate against the source (the AviSynth script, thus 
having the exact same resolution and size as the encoded video).

The review phase is concluded well before screenshots are even taken. 
Screenshots are published for two reasons: 1) I can often use them to 
outline a certain property a codec has (but I mention if a screenshot does 
not do a codec justice, be it in the positive or negative sense), 2) Who 
would read a text only comparison?

Hence, all comments with regards to quality (including those about reviewing 
the lobby shootout again using ffdshow rather than the ateme decoder) have 
nothing to do with the screenshots. In fact, even today I don't know which 
shots look better, the lavc or xvid ones, and I don't care either, 
screenshots mean nothing to me when I'm only concerned with what I see while 
watching the video. Using screenshots and judge a codec based on that for a 
subjective comparison, would be the most unprofessional thing I could 
imagine.

For various reasons, the ASP codecs will use the AVI container in the main 
round and thus each their own decoder. However, I expect (from my official 
contact, Corey, or Michael if he decides to step in as the creator of 
libavcodec) a solution to the screenshot problem in ffdshow, or lavc 
screenshots will be taken using another decoder (he can even chose which 
one) and I'll make sure to stress the apparent disadvantage of ffdshow 
because it discolors depending on the renderer (that's an important 
usability issue.. there are various reasons to not use overlay). And I need 
those things by Monday evening as I'm almost done encoding for the main 
round so the review phase will start shortly.

If time permits, I will post a sample from the xvid and lavc streams that 
clearly show that xvid performs superior in the lobby shootout. And that's 
based on the huge amount of blocks I see in lavc, be it decoded with ffdshow 
or the ateme decoder, versus very little blocking in xvid, be it decoded via 
ffdshow or ateme, or xvid's own decoder for that matter. You can't explain 
those away, and as Michael said, you had the chance at the settings prior to 
the submission deadline, or in his own words:

> if you dont do that, then shut up and dont complain about what doom9 will
> say about libav*/mencoder

>not the idct missmatch but ateme still might be a bigger disadvantage
>for lavc then lavc is for xvid, the reason is that lavc will use the xvid
>idct for xvid so, theres no missmatch if ffdshow is used but an unknown one
>for atemeActually, the auto idct selection seems not to work when you use 
>the MP4 container (see this: 
>http://forum.doom9.org/showthread.php?t=104143)And from past experience and 
>experience during this comparison, I actually find the result of decoding 
>xvid decoded by xvid more visuallypleasing than when xvid is decoded by 
>lavc (and that's in the avi container where the auto idct selection works 
>just fine).XviD stands a lot less to lose by being decoded by the ateme 
>decoder than being decoded by lavc.>hmm, i remember that i wanted the same 
>decoder to be used for all mpeg4
>codecs a long time ago as in some comparission lavc was compared with
>ffdshow and pp disabled against other mpeg4 codecs with their own decoders
>with pp enabled (their decoders may actually not have had an option to 
>disable
> pp), also note thats how i remember it and my memory might be wrong, if so
>please someone correct meHere's a quote from the mail in question, you sent 
>it to me on February 17th 2005>wie auch immer, ich würde auch vorschlagen 
>dass du beim vergleich der MPEG-4 >encoder den selben decoder mit den 
>selben postprocessing settings benuzt, >beim lezten vergleich war das 
>glaube ich nicht der fallIn English, you're asking to use the same decoder 
>and the same postprocessing settings.I've always used the same 
>postprocessingsettings for all codecs (deblocking turned on, deringing 
>turned off, film grain turned off).Note that whenever I speak about 
>quality, I mean perceived quality when watching videos.. this may not hold 
>true at all whenyou take screenshots and compare them, but that's something 
>I just don't do.Last but not least, whoever blasts MP4 has obviously never 
>used B-frames in AVI. AVI works until B-frames enter the picture, but then 
>you are screwed and have to resort to hacks like backed bitstream. B-frames 
>also introduce decoder delays so you need to write your filter to 
>compensate for that or you end up with a few black frames at the beginning 
>of each videoand finally and losing frames in the encoded output. The hacks 
>to compensate for some of these disadvantages have been incorporated into 
>some codecs using AVI output, but not all. If you want a container 
>discussion, you'll find much more knowledgeable people on the subject than 
>I am in my container forum:http://forum.doom9.org/forumdisplay.php?f=74 . 
>When you go AVC, the only containers that work without all these issues 
>areMP4 or MKV. RegardsDoom9