[MEncoder-users] new doom9 codec comparission (submission)
bugfood-ml at fatooh.org
Tue Dec 13 09:54:36 CET 2005
On Mon, December 12, 2005 23:21, Loren Merritt wrote:
>>> I'm starting to think that maybe I should
>>> do this:
>>> First pass: vqscale=1
>>> Second pass: vqmin=1:lmin=1:vbitrate=581
>>> I'm testing this now...
>> ...and it doesn't work well. The bitrate ends up being fine, but PSNR
>> drops from 43.01 to 42.54. Low-motion parts look a bit better (probably
>> from the lower vqmin), but high-motion parts are much worse.
>> I'm currently testing a few possibilities:
>> - without vqmin=1:lmin=1
>> - vqmin=1:lmin=1.5
>> - vqmin=2:lmin=1.5
>> - starting over again with vqscale=1.5 for the first pass
>> I don't know which of those is the right approach, but we'll see.
>> I'd really like to come up with a generic two-pass method of snow
>> encoding so it isn't necessary to find a specific vqscale value for the
>> first pass of each encode. If I can't, than I think I'd rather see snow
>> disqualified than look bad because I can't work around the lack of first
>> pass ratecontrol.
> Another possibility is
> which should avoid the defecit of bits in high-motion parts.
Thanks for the suggestion. I did some experimenting with vqcomp ealier,
though, and found that 0.6 is a very good value. I think that what was
(a) Using lmin=1 for the second pass meant snow was using a quantizer of 1
where 2 would have looked just fine, thereby further starving the
high-motion scenes. A high vqcomp would have worked for this, but...
(b) Removing lmin=1 from the second pass worked well, but the PSNR was still
considerably lower than when the first pass was closer to the target bitrate
(42.82 vs. 43.01). Doom9 mentioned that 3-pass would be acceptable, and
that's what I'm trying now. It's turning out well, and I'll have a final
> Note: snow ignores vqmin. The limit is only lmin.
Thanks -- I didn't realize that.
More information about the MEncoder-users