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

[Andy Sheen]

Kyle Schwarz wrote on Fri 13 Jul at 1:32 UK time

>> 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.
> 
> I'm unable to reproduce this error. It could be because I'm not on my
> powerful desktop, or it could be something else.
> 
> Could you give me the most basic command line that still produces the
> issue with my latest builds (299387e)?

ffmpeg -i 7416_20120706235700.mpg -c:v libx264 nul.mp4

That short enough?

It's much easier to see the spikes with -pass 1 though.

ffmpeg -i 7416_20120706235700.mpg -pass 1 -c:v libx264 nul.mp4

where the file is a MPEG TS file. I have reproduced where the data file
is a .mkv file too (although interestingly, the spiking does seem to be
little less frequent). If you want an upload of the data, please let me
know where/how much you want (it'll probably need to be a fair chunk to
really show the problem - I don't think a 10M dump will show it).

The command line I normally use is:

ffmpeg -y -loglevel info -i 7416_20120706232700.mpg -r 25 -ss 0:0:0 -t
0:10:00 -map 0:0 -pass 1 -preset fast -tune film -profile high
-fastfirstpass 1 -c:v libx264 -b:v 1200k -threads 8 -f mp4 -an nul

Funnily enough, I have never seen the problem with -pass 2 in the
command line. I.e.

ffmpeg -i 7416_20120706235700.mpg -pass 1 -c:v libx264 -b:v 1200k -c:a
copy nul.mp4

shows the problem (averages ~50% CPU use with spikes and the counter
freezes) whilst:

ffmpeg -i 7416_20120706235700.mpg -pass 2 -c:v libx264 -b:v 1200k -c:a
copy nul.mp4

works correctly (uses ~100% of the CPU, but never freezes the counter).
Just to prove I'm using your latest build, here's the first part of the
output:

ffmpeg version N-42347-g299387e Copyright (c) 2000-2012 the FFmpeg
developers
  built on Jul  8 2012 15:48:29 with gcc 4.7.1
  configuration: --enable-gpl --enable-version3 --disable-w32threads
--enable-runtime-cpudetect --enable-avisynth --enab
le-bzlib --enable-frei0r --enable-libass --enable-libcelt
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable
-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut
--enable-libopenjpeg --enable-librtmp --enable-libschro
edinger --enable-libspeex --enable-libtheora --enable-libutvideo
--enable-libvo-aacenc --enable-libvo-amrwbenc --enable-
libvorbis --enable-libvpx --enable-libx264 --enable-libxavs
--enable-libxvid --enable-zlib
  libavutil      51. 64.100 / 51. 64.100
  libavcodec     54. 33.100 / 54. 33.100
  libavformat    54. 15.102 / 54. 15.102
  libavdevice    54.  1.100 / 54.  1.100
  libavfilter     3.  1.100 /  3.  1.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100

> 
> The reason I use pthread/winpthreads instead of w32thread is because
> many more packages on Linux support pthread then do w32thread. I also
> believe the code base to be stable and a good thread management solution.
>

Fair point... well made :)

> You can also compile gdb with the toolchain you used to compile FFmpeg,
> if your interested.
>

Good idea. I'll try that over the weekend :)

> Best regards,
>   Kyle Schwarz (Zeranoe)

Thanks for providing all this - it is appreciated (your mingw script was
the first time I managed to configure a build environment that worked
*properly* for Windows builds of ffmpeg)

Andy