[FFmpeg-user] Zeranoe Windows builds spiking CPU to 100% randomly
sheen.andy at googlemail.com
Fri Jul 13 09:31:53 CEST 2012
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
shows the problem (averages ~50% CPU use with spikes and the counter
ffmpeg -i 7416_20120706235700.mpg -pass 2 -c:v libx264 -b:v 1200k -c:a
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
ffmpeg version N-42347-g299387e Copyright (c) 2000-2012 the FFmpeg
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
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)
More information about the ffmpeg-user