memory leak in x264 multi thread only, increase, because, version

andy

i use x264 for some time and i have a dual athlon config.
i'm testing multithread for 3 days (because before a had a lot of transcoding to do and to launch 2 parallel encoding was quicker than use 2 thread on one encoding).

when i set threads on more than one, the memory used by x264 (cli and vfw are the same) increase and increase and crash vdub or the x264 gui ones theres no more memory left.

just wanted to ask if it's only my config or if it's a x264 bug...

i use x264 version 270

++

Are you trying to invoke x264.exe in same folder twice (to achieve your 2 parallel encoding)? If this is the case, have you ever tried to launch the program in different folder (i.e. one x264.exe in folder 1 and the other in folder 2)?

Did this solve your problem?

i might have not be clear.
i've used a lot 2 session of x264.exe or x264 vfw at the same time with no bug.
but when i use one x264.exe or one x264 vfw, and set up threads on more than 1, the used memory and handle of x264 increase and increase and then crash.

so there's a memory leak in the multithread option of x264, that's all, i just wanted to say it so it could be solved.

++

Alright, I did a test on my dual core machine and I cannot confirm a memory leak. Using 1 thread or two threads, and comparing to my single core machine (same source, same settings) I see no significant difference in memory use. It creeps up to about 200 megs and stays there (I have 1 GB). So it's not a generic problem.. now you should try and trace it down to settings or source.. go down to the most basic settings (x264 --b 700 and your input and output, nothing else), switch sources and see what you get.

Is it safe to quot;forcequot; 4 threads always? Maybe I'll add code to detect how many CPU the user runs...

I've only tested 2 threads on a single core box but in my short test both test encodes behaved exactly the same. Though, sliced encoding has a quality impact, so I'd suggest to make this an optional parameter the user has to set (unless you do the CPU detection all the way through.. dual cores, actual SMP setups, actual SMP with dual core chips, HyperThreading, dual core with Hyperthreading, dual cpu with hyperthreading, dual cpu with dual core with hyperthreading.. there's tons of possible combinations). And it's not even so sure that HT is beneficial.. the EE benchmarks showed that at times the non HT capable dual core chips were actually faster.