[FFmpeg-user] Zeranoe Windows builds spiking CPU to 100% randomly

[Andy Sheen]

Roger Pack wrote on Wed 11 Jul at 21:54 UK time
>>> It would be interesting to know why pthreads fails but win32threads
>>> succeeds.  Also I assume that if you compile it with w32threads
>>> enabled and use -threads 0 I presume it does use all the available
>>> cores?
>>
>> I agree it would be interesting - and even more interesting why the
>> commit the git bisect causes the issue (and only with the avconv build
>> and not the ffmpeg from the same source tree).
> 
> That commit (if I'm thinking of the right one) set the thread default
> to "0", which means "auto detect" (i.e. use all the cores available),
> so basically, it was forcing multi-threaded behavior by default.  Why
> avconv and not ffmpeg, I have no idea, but my guess is that you'd see
> the same behavior with builds previous to that (and have to search for
> a new "offending commit") if you passed them the -threads 0 parameter.
> 

but I'm specifying -threads 8 in all my command lines, so there should
be no difference.

>> I'm at a bit of a loss to
>> debug further - monitoring the process changes the behaviour - I don't
>> think gdb will do anything useful (I installed mingw gdb and it still
>> doesn't recognise the file - I guess as it's a 32bit build of mingw...)
>> as you can't CTRL-C the process when it is in this state.
> 
> Maybe you could build a 32-bit build (does it exhibit the same
> features), or possibly the mingw-w64 peeps have a 64 bit gdb
> available, I haven't checked [1].
>

Can't easily see a 64-bit gdb, yes, I can build a 32 bit version and see
if the same problem occurs, but it does point to a race condition in the
wingw implementation of pthreads at the moment.