L'octidi 8 thermidor, an CCXX, Luke a écrit :
We are testing ffmpeg in our compression pipeline as our commercial software does not provide the functionality we need.
We run a multithreaded compression (ffmpeg multithreading isn't used, our own solution is) using the following command: ffmpeg -i #input# -f mp4 -vcodec libx264 -s 1024x576 -b:v 2000k -g 33 -acodec libmp3lame -b:a 128k -ar 44100 -vf "movie=#logo# [wm]; [in][wm] overlay=10:main_h-overlay_h-10 [out]" -y #output#
Approx. 75% threads complete without any problems, the remaining ones get stuck - cpu usage on each thread drops to 0, memory usage gets stuck at around 300MB.
Can you reproduce the problem with another video codec, such as the internal MPEG4 encoder, or maybe even with -f null? Can you try to find out where ffmpeg is stuck? A way to do that would be to run the debug version (ffmpeg_g), and when it is stuck, attach it with gdb (gdb ffmpeg_g $(pidof ffmpeg_g)), get a backtrace and then detach it: a few iterations of that would show where ffmpeg spends most of its time.
Initially we used aac and libvo_aacenc coders for audio, but the hangs seemed more frequent.
You will probably get more quality out of lame anyway. Regards, -- Nicolas George