[x264-devel] Bug (or bugs) in x264 rev 2334 OpenCL and one improvement proposal.

[Nihil]

Thank you from answering and doing that pretty fast.

 >> x264 [error]: malloc of size 10031104 failed
 >> x264 [error]: x264_encoder_encode failed
 >
 >Your system ran out of allocateable memory when using very
 >memory-intensive x264 settings; this is not a bug in x264. If you need
 >to use settings that require more than 4GB of address space, I suggest
 >you upgrade to 64-bit x264.

I somewhat disagree here. Here's information I got with ProcessHacker.

No -p option

Peak Working Set 1,23GB
Peak Virtual Size 1,94GB
Peak Private Bytes 1,76GB

x264 [error]: malloc of size 10031104 failed
x264 [error]: x264_encoder_encode failed

-p 1

Peak Working Set 1,14GB
Peak Virtual Size 1,78GB
Peak Private Bytes 1,59GB

And the video file was same as in my original post. 1920*1200 15fps 
fraps avi which has 255 frames and size is around 467MB.

So only thing that gets close to 2GB barrier while there isn't -p option 
used is virtual size. But even if 2GB barrier is culprit I was kind of 
expecting that x264 project has defined IMAGE_FILE_LARGE_ADDRESS_AWARE 
flag to be set in 32bit Windows makefile in which case x264 could hoard 
3GB of memory in 32bit Windows systems.

Going forward from malloc fail, is OpenCL supported in -p 2 and -p 3? If 
not then that improvement comment was valid. (of course it could be 
somewhat possible that memory handling caused OpenCL message not to be 
shown with -p 2 and -p 3)

Now out of topic. I actually do have 64bit Windows 7 Pro but sadly it 
doesn't support my old trusted NIC (3Com 3C905B). So I have been waiting 
to make some bigger HW upgrades but . . .

And installing 64bit Linux well there's other reasons against that.

 >> Add commandline option for storing ffms file index. I deal with 
large static
 >> files (not using AviSynth or some such) and when doing "Nth pass" a 
lot of
 >> time is wasted. It would be nice if file index could be saved in 
same manner
 >> as x264_lookahead.clbin x264_2pass.log x264_2pass.log.mbtree files 
so file
 >> indexing needs to be done only once.

Thank you about this. From some reason my brain didn't connect this 
parameter to ffms and storing the index. Oh well everyone needs brain 
barf from time to time.

 >This is what --index does.
 >
 >Jason