Error in using 2-pass rate control scheme in x264

[Redhat_doom]

Hi All,

I used the following command to encode video Foreman (CIF) at 256kbps:
x264 --bitrate 256 --pass 1 -o foreman.264 forman.yuv 352x288

Then I used the following command:
x264 --bitrate 256 --pass 2 -o foreman.264 forman.yuv 352x288

but I got the following error:
x264[error]: requested bitrate is too low. estimated minimum is 262 kbps.
x264[error]:x264_encoder_open failed.

I tried higher bitrate like 356kbps but again I get a similar error
("estimated minimum is 371 kbps").
But what is the problem? and how can I solve that? Thanks,

[LoRd_MuldeR]

Usually I'd say that when you get that error your bitrate simply is too insanely low for the source you are encoding.

But in this case I know that the "foreman" sample can be encoded at 128 kbps or even lower :confused:

[Redhat_doom]

yes, exactly. 256kbps for Foreman (CIF) is enough! It sounds like a bug in x264!

[LoRd_MuldeR]

yes, exactly. 256kbps for Foreman (CIF) is enough! It sounds like a bug in x264!

Or a borked build. What revision do you use? And did you try different builds?

And I assume you don't use "super fast" settings?

[Redhat_doom]

I used "x264 --version" and I got this: "x264 0.65.X". I downloaded this version on Jan 2009. Is that ok?

[LoRd_MuldeR]

That's a pretty old version. Before complaining about problems in such an old version, you should probably try a less antiquated build...

[nurbs]

Why would you use a one and a half year old version. Maybe there was a bug in that specific version that has been fixed. Try an up to date version.

[Redhat_doom]

The problem is that I have already implemented a lot of extra functions in that old version and I cannot easily migrate to the latest version. But I remember even in that time (Jan 2009) people were talking about 2-pass RC in x264!

Anyway, the main problem is this: I have implemented a new motion estimation method in x264 but interesting is that the PSNR performance of my own method is higher than the x264's exhaustive motion search algorithm. I used --bitrate 256 --psy-rd 0:0 and --me "esa" in my experiments. I expect that --me "esa" should always get the best PSNR performance because it is an exhaustive search! but it seems that it is not the case. Although, my method doesn't use any exhaustive search but in some frames, the average PSNR-Y is higher than the corresponding PSNR value when using --me "esa" (at the same bitrate). Should I use the 2-pass RC scheme for my comparisons?

[LoRd_MuldeR]

Well, if you even hacked your own modifications into the x264 code, then chances are good that the problem is caused by your modifications (either directly or indirectly) rather than by the original x264 code.

And about comparisons I can only give the advice to NOT rely on metrics too much, especially not on PSNR ;)

[Redhat_doom]

ok, where can I find the latest snapshot of x264 for MS VC++? Thanks,

[LoRd_MuldeR]

ok, where can I find the latest snapshot of x264 for MS VC++? Thanks,

The x264 project does not support the MSVC compilers. You should use the GCC/MinGW compiler instead.

If you really want to compile an up-to-date x264 with MSVC then you will need unofficial patches, which again potentially breaks something.

[Redhat_doom]

ok but could you give me the link for a recent version of x264 compatible with MS VC++? Thanks,

[LoRd_MuldeR]

ok but could you give me the link for a recent version of x264 compatible with MS VC++? Thanks,

Nope. As it doesn't exist. The last version with MSVC support was r1280. All MSVC support was removed in r1281.

[EDIT]

It seems roozhou has created MSVC project files. Have a look here:
http://forum.doom9.org/showthread.php?t=154946

Of course you cannot expect support for that from the x264 developers. So I'd still recommend to use MinGW/GCC.

[Dark Shikari]

Nope. As it doesn't exist. The last version with MSVC support was r1280. All MSVC support was removed in r1281.And it didn't actually work; the support was removed because it didn't work.

[roozhou]

It seems roozhou has created MSVC project files. Have a look here:
http://forum.doom9.org/showthread.php?t=154946

Of course you cannot expect support for that from the x264 developers. So I'd still recommend to use MinGW/GCC.
The code from official git contains lots of C99 features which are not supported by MSVC. On each update I have to modify hundreds of lines of code to make it compile with MSVC without breaking GCC compliation. So simply copy my projects won't work. Plz also remember that my code contains my own hack and new input/output features. I am not planning to make a MSVC patch against the official git in the near future.

[Redhat_doom]

ok, I decided to use the latest version of x264 in MingW. But I don't like to use the text-based GDB. Is there any graphical debugger (IDE) for gcc in Windows? Thanks,

[LoRd_MuldeR]

Qt Creator maybe?

http://www.jbkempf.com/blog/public/VideoLAN/VLC_Qt_Creator.png

[Redhat_doom]

Qt Creator maybe?

http://www.jbkempf.com/blog/public/VideoLAN/VLC_Qt_Creator.png

But can it compile x264? because x264 doesn't have any QT-project file.

[LoRd_MuldeR]

But can it compile x264? because x264 doesn't have any QT-project file.

Good question. Doesn't it work with Makefiles? :confused:

[Redhat_doom]

It seems that we need to create a QT project first. But how to do that is another problem!