> No, you don't need to recompile. Is the application really stucked, > or is it just very slow? Have you tested that it response on '?' key > stroke? As for me the encoding works - slowly - but it works.
Ok I tried the latest .dll, same thing here (still shows pauses): Basically, you should see console output once every second while it is running. For instance if you use http://rogerdpack.t28.net/incoming/ffmpeg_distros/ffmpeg-distro-static-3865ec2acea976da695b9d4c8375d1af1449a446.7z it works and always outputs console output once per second (this particular build uses windows native threads, not pthreads, for reference--the pthreads implementation seems to run fine on linux, however, so I don't know for sure but I think ffmpeg's pthread usage is ok). With the latest win32_pthreads revisions, it basically "pauses" or "hangs" once in a while, then continues on--its the hangs that are the problem. Also if you revert win32_pthreads to a revision before, say, 5250, then run it, you'll (probably) see that it runs faster than what you see with the latest revisions, and freezes less often, but still freezes. If you don't see this then perhaps try it with "-threads 6" or the like (also I presume you're running it on a multiple core machine?) Thanks much. -roger- ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
