On 8/6/2012 3:56 PM, Kai Tietz wrote: > 2012/8/6 Kyle <kshawk...@gmail.com>: >> On 8/6/2012 1:59 PM, Kai Tietz wrote: >>> 2012/8/6 Kyle <kshawk...@gmail.com>: >>>> On 8/4/2012 3:38 AM, Kai Tietz wrote: >>>>> 2012/8/4 Kyle Schwarz <kshawk...@gmail.com>: >>>>>> On 7/27/2012 5:37 PM, Kai Tietz wrote: >>>>>>>> I have tried it, thanks for the patch! >>>>>>>> >>>>>>>> Unfortunately it appears that (ffmpeg + libx264 using it at least) >>>>>>>> appears to deadlock (?) after a few seconds. >>>>>>>> >>>>>>>> Here's an example trace: >>>>>>>> >>>>>>>> Thanks for your help in this! >>>>>>>> -roger- >>>>>>> >>>>>>> Hmm, it seems that this time conditional variables are causing the >>>>>>> dead-locking. I will continue on that tomorrow. But good to hear >>>>>>> that now at least some seconds are running ;) >>>>>> >>>>>> Any chance for an estimate on how long fixing this might take? If >>>>>> winpthreads are no longer the best option I'm just curious as to if it's >>>>>> worth it to try other options. >>>>> >>>>> Well, as long as I don't get a testcase (and I mean here a reduced >>>>> one) I can't do much. I tested all error-cases I can think of so far, >>>>> and current version passes it. >>>> >>>> It appears that the latest version completely locks up ffmpeg.exe so >>>> that x264 in FFmpeg can't even use threads. FFmpeg seems to max out at >>>> 100% and then every so often move ahead. The only thing I changed was to >>>> update my toolchain and winpthreads and recompile both x264 and FFmpeg. >>>> There are no debug symbols in this archive but it shows the problem: >>>> <http://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-20120804-git-f857465-win32-shared.7z>. >>>> >>>>> The statement "it doesn't work" doesn't help me to track down this >>>>> issue. Maybe a testapplication using the DLL version of winpthread >>>>> (compiled with -g) could be helpful to track down this issue. >>>> >>>> What sort of test application? x264 is rather slim, if I provided debug >>>> builds of x264 and the issue was with it would that help? I could also >>>> provide FFmpeg with debug symbols plus x264. Just let me know what you >>>> need to help fix this and I'll compile it right away. >> >>> thanks for the ffmpeg build. It would be a great help to get a >>> compiled version of it, which is using shared (means DLL) version of >>> winpthread. So I would be able to do some debugging by it. Of course >>> it would be helpful to have debug-information for ffmpeg, but this >>> isn't essential. >> >> Here is a FFmpeg debug build: >> <http://zeranoe.com/df3I0KYRqXBrYMjf/ffmpeg-debug.7z> FFmepg and x264 >> should have debug symbols. > Thanks, does it uses winpthread as DLL-version? As this is for me > important to be able to test my changes locally.
Yes, winpthread is compiled in shared and has a .dll. ------------------------------------------------------------------------------ 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
