On 8/13/2012 8:31 PM, NightStrike wrote: > On Wed, Aug 8, 2012 at 2:49 PM, Kyle <kshawk...@gmail.com> wrote: >> It's *very* slow. If you compare the speed to that of a older FFmpeg, >> the debug build is practically unusable. > > I'm coming into this very late, and I probably can't be of much help, > but just a thought. Have you tried profiling ffmpeg to see where it's > wasting all of its time? For instance, if it's seeing tons of delays > just trying to get mutexes, then that's a problem.
Thank you for the help. Ive been forced to switch over to w32threads because of this issue and I'm willing to offer any help to get it fixed. I think winpthreads is a great package for not only FFmpeg but also other high cpu usage apps, and prefer it over any of the other pthread wrapper libraries. With that said, I haven't tried to profile FFmpeg. I'm not sure how I would go about doing that either. > Compiling with -pg and using gprof would be a help, as would throwing > some instrumentation in the code at various key points. I can supply a build with -pg, I haven't used gprof yet but I believe it works along with a build that is compiled with -pg. I'm a bit rusty in C, but I'm very motivated to fix this so just walk me though anything you would like tested and I'll see that it's done. > Have you used gprof before? It can be daunting with the output that it gives. Any progress on this bug is a huge help to me. Best regards, Kyle Schwarz ------------------------------------------------------------------------------ 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
