Can you reproduce the problem with another video codec, such as the internal MPEG4 encoder, or maybe even with -f null? I tested this using internal mp4, as well as libvpx. In both cases the

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. Unfortunately the system is running Windows 7 and we have no option of running linux (users not linux friendly). What do you mean that your own solution is using multithreading? As you will notice from the attached logs the pipeline is based on Ruby. The whole objective of it is to ingest files from the capture servers, rename them, create branding, compress & watermark, and distribute compressed output to client machines as well as HTML5 web app. Which should explain testing libvo_aac and VP8. The Ruby app creates runs multiple threads based on the size of the queue. What OS? Windows 7 Full uncut complete console and output please? Logs from FFMPEG attached. One of a comression which completed fine, and 3 which got stuck. Getting stuck seems a bit random, as force closing and reopening the thread usually allows the compression to complete fine. If not on the 1st try, then 2nd. Usually 1st re-run is enough. We're trying another approach - building timeout into the multithreading

Hello, Thanks for your responses. pipeline completed without a glitch on a sample of 1400 videos. process. However it would be quicker and more efficient if we were able to run FFMPEG without a glitch.

Also gdb backtraces of stuck threads? Correct me if I'm wrong, but I won't be able to get it in Windows, will I?

Many thanks for your help, *Luke Niejadlik* Audiomotion Studios Ltd. T: +44 (0)8701 600 504 F: +44 (0)1865 725 651 www.audiomotion.com <http://www.audiomotion.com/> Develop Awards - Best Services Winner 2011, 2009 & 2004 */JOIN THE MOVEMENT!/* - www.facebook.com/audiomotion.studios <http://www.facebook.com/audiomotion.studios> - twitter.com/audiomotion <http://twitter.com/audiomotion> - http://www.join-the-movement.co.uk/

This sounds vaguely familiar...f it fails with libx264 but works well with the others, you may be running up against a threading issue we're trying to resolve in the zeranoe builds. Could you try with this build and see if it works? http://x32.elijst.nl/FFmpeg-20120622.7z I tried this, but the overlay filter did not work in it. However going along theses lines I worked my way down the previous builds and found one that works without a glitch. Which probably confirms what you suspected anyway. Believe it or not the mingw people have ported gdb to windows, and it works quite well. http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages... It can even attach to remote processes. You'll want to be running a debug version of ffmpeg, though even a non debug version of it might show some interesting material.

basically start gdb, then (gdb) attach<pidd> (gdb) thread apply all bt GL! I didn't have a need to do this in the end. I tested the build in most

likely scenarios off line. I also replaced the build on the live compression system and ran it all day yesterday - older build worked like a charm. However if you'd find the outcome of thread traces useful for your purposes I'm happy to do some testing for you. Once again, thank you for your help. Fewer late nights for me now! All the best, Luke

Hi Guys, I've a similar problem with frozen ffmpeg instances, 2 of 8 instances is frozen, cpu usage on each instance drops to 0. I've tried to remove -threads parameter or set -threads 1, result is the same. I've uploaded video file and 8 cmds to fileshare: http://turbobit.net/7ff93nfen4pw.html You can use start.bat to start 8 instances at once. I've attached a log files of frozen ffmpegs: http://ffmpeg-users.933282.n4.nabble.com/file/n4652259/log_6.txt log_6.txt http://ffmpeg-users.933282.n4.nabble.com/file/n4652259/log_7.txt log_7.txt -- View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Encoding-x264-hangs-in-a-high-turn-... Sent from the FFmpeg-users mailing list archive at Nabble.com.