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

[Corey Hickey]

Doom9 Feedback Hotline wrote:
> Hi
> 
> Thanks for the commandlines. Unfortunately I didn't implement all the 
> options you're using for lavc so I had to do it on the commandline, and I 
> accidentally forgot to put in -lavcopts, which resulted in encoding, but an 
> error at the end (thank god I test with a 2000 frame clip prior to main 
> encoding). That's all sorted and the lavc pass is now running.

Good you caught that. :) It would have resulted in very fast and very
very bad looking encodes.

> I have a question regarding your snow commandline: is vqcomp really 
> supported in Snow? Once upon a time when I added snow support to MeGUI, I 
> asked around which parameters were supported and vqcomp wasn't amongst these 
> options.

vqcomp is listed in DOCS/tech/snow.txt (in the mplayer source), so I
thought it was supported. I used vqcomp=0.6 on the basis of liking it
better on my mpeg-4 tests. I just tested a clip, however, and it had no
effect. If Michael sees this on mencoder-users he'll probably tell you
for sure.

>>Please let me know if that
>>is not still the case; I can provide parameters for adding a bit of
>>noise that slightly improves perceptual quality.
> 
> 
> It is still not the case, however, adding noise at any point is not allowed, 
> unless the codec filters out noise when encoding and saves a parametric 
> representation of the noise, which the decoder will use to reconstruct it 
> (AVC High profile allows that, and I have one ASP codec that does this as 
> well). But to the best of my knowlege libavcodec cannot do that and adding 
> noise to the source at encoding time is not permissible.
> 
> It is correc that you cannot place Snow into MP4 so it will use AVI instead.
> This means Snow is a bit at a disadvantage because MP4 has lower overhead, 
> but that's just a reflection of how unfair life really is (and other codecs 
> in the non MPEG-4 group will have that disadvantage (VP7) or even use their 
> own container (VC-1, Theora, and Dirac isn't really supported anywhere)). 
> The Matroska team has been pestering me about that (obviously hoping that 
> I'd be using their container instead), but future hardware is likely to 
> handle MP4 on the side of AVI but not MKV, and it is impossible to 
> accurately predict the overhead the Matroska container incurrs (for that you 
> need to know the distribution of I, P and B frames in advance) and this thus 
> makes an accurate bitrate prediction impossible, and since I put final 
> filesizes int he comparison, that would give a bad reflection of a codec's 
> rate control.

Eventually, I suspect that snow's preferred container will be nut, if
and when they're both finished. For now, it seems like it should be
possible to mux snow into most containers. MEncoder and MP4Box can both
mux snow into mp4, but Media Player Classic can't play it. I don't know
how close such files come to being standards compliant, though.

> Last but not least, I noted that you didn't use the threads parameter for 
> lavc. I take it then you feel the speed gain by this parameter is not 
> significant enough (it doesn't change much in my tests, unlike x264 via 
> mencoder where the difference is considerable), or that it hurts quality?

Yes. In this case, threads=2 incurs a 0.04 dB loss in PSNR and a slight
but visible drop in quality. There was considerable discussion on the
mailing list on this subject. I myself vacillated several times before
deciding I didn't want to include it. In particular, none of us could
get a good idea of how much performance would be improved. I don't have
any multiprocessor/multicore hardware to test with, and neither did
anybody else on mencoder-users.

If you say that performance doesn't change much, then I guess we made
the right decision.

-Corey