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

[Roger Pack]

>> 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.

> 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].

> Zeranoes forums a bit, do you know why he uses pthreads?

I don't.  I can ask.
-r
[1] http://mingw-w64.sourceforge.net/