FFMPEG libx264 processing maxes out

[pangerang]

Hi - I hope this is the right place to ask. I've downloaded the latest version of FFmpeg created by Zeranoe on 7/6/12. The issue I'm having is that the process will randomly max out my cpu(s) and hang for x number of seconds and then continue. There's no consistency as to when or what causes this, but it happens on most files (and even if it runs fine once, running it again on the same exact file can reproduce this symptom).

Processing will resume, but the delay is having an adverse affect with my other programs.

This is the command that I'm running:
ffmpeg.exe -i input.ts -c:v libx264 -preset medium -b:v 2500k -r 30000/1001 -vf scale=960:-1 -f mp4 -c:a aac -strict experimental -b:a 28k -ar 24000 -ac 2 -threads 8 -y output.mp4

the input.ts file is a 2 minute recording off a qam channel with the following details:
Video:
mpeg2
1280x720
119.88... frame rate
20Mb br
audio:
ac3
48000 hz
448 kb br

I've run this on multiple systems; they are all windows 7 64bit, i7 2600 or greater, and at least 4 mb of memory. I've also tried both 64bit and 32bit versions of ffmpeg.

I've tried removing almost all of the options above, but this behavior still occurs. I'm utilizing an older version of FFmpeg where this behavior does not exist. I'm hoping someone could shed some light as to what is going on and if there's anything that can be done.

Thanks in advance.

[rogerdpack]

virus scanner maybe? Do you get the same behavior in a linux box?

[pangerang]

No virus scanner. Haven't tried on a linux machine. I don't have one in a testing or production environment, but it needs to work on a windows box.

[arad85]

I too get this problem.

I've run ffmpeg for a number of years and upgraded to the latest version from a build from September last year that worked well for me until a few days ago when I had to convert a file that caused a segfault. I just downloaded the latest version from this site, converted the command line arguments in my scripts as the previous versions used the old preset file.

The symptom is the system goes to 100% CPU for 5 or so seconds, the frame counter freezes until the CPU drops. It is always in the first pass (I haven't seen this happen on the second pass of an encode).

My command line is:

Code: Select all

 ffmpeg -y -loglevel info -i 7416_20120706232700.mpg -r 25 -ss 0:3:43 -t 0:28:32 -map 0:0 -pass 1 -filter:v yadif=0:-1 -c:v libx264 -fastfirstpass 1 -b:v 1200k -threads 8 -f mp4 -an nul


Running the same encode twice gives wildly differing encode times (I time the encodes).

This is the result of two encodes of exactly the same file with exactly the same parameters:

Code: Select all

Encode 1:
Pass 1 took   0:3:12 (8.91x)
Pass 2 took   0:4:11 (6.81x)
In total took 0:7:23 (3.86x)

Code: Select all

Encode 2:
Pass 1 took   0:4:18 (6.63x)
Pass 2 took   0:4:11 (6.81x)
In total took 0:8:29 (3.36x)

As you can see, the second pass is consistent, the first pass is wildly different (nothing else running on the box).

This is Win7 64, all updates installed. i7-2600K clocked at 4.3GHz.

If I replace the ffmpeg with the older one from last year (and revert the command lines), I don't get the pauses.

[arad85]

So as mentioned I have the same problem.

Trying out the builds here: http://ffmpeg.zeranoe.com/builds/win64/static/

The December 26th 2011 binary works correctly, The Jan 5th 2012 has the pauses. Now to work out why as looking at the build manifest they use the same external libraries and the same minGW toolchain.

[arad85]

I've tracked this to the commit:

Code: Select all

xbmc at pain:~/source/ffmpeg/ffmpeg$ git bisect bad
e4e30256f87f177decf59b59e923d05ef64147df is the first bad commit
commit e4e30256f87f177decf59b59e923d05ef64147df
Author: Janne Grunau <janne-libav at jannau.net>
Date: Sun Dec 25 11:45:05 2011 +0100

threads: default to automatic thread count detection


A compile from the checkin before doesn't show this lockup, from this commit it does. Interestingly, two binaries are built - avconv and ffmpeg. avconv shows the problem, fmpeg doesn't.

See: http://ffmpeg.org/pipermail/ffmpeg-user ... 07921.html

for more information.

[arad85]

Just as a FYI at the moment, compiling with --disable-pthreads rather than --disable-w32threads (you also have to recompile x264) fixes the CPU spiking and increases the 1st pass encode speed by ~10%.

I'm not compiling in all the libraries Zeranoe is but here's my config for reference:

Code: Select all

ffmpeg version N-42432-gb27c7d7 Copyright (c) 2000-2012 the FFmpeg developers
  built on Jul 11 2012 16:54:29 with gcc 4.7.1
  configuration: --arch=x86_64 --prefix=/home/xbmc/source/ffmpeg/build --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-libmp3lame --enable-libx264 --enable-zlib --enable-libfaac --extra-cflags=-I/home/xbmc/source/ffmpeg/build/include --extra-ldflags=-L/home/xbmc/source/ffmpeg/build/lib --enable-nonfree


[rogerdpack]

@zeranoe is there any specific reason that pthreads are used instead of w32threads? I mean theoretically they are the same speed, right?
-roger-
ref: this thread (I was told to ask
http://ffmpeg.org/pipermail/ffmpeg-user ... 07976.html

[arad85]

ref: this thread (I was told to ask )
http://ffmpeg.org/pipermail/ffmpeg-user ... 07976.html

No you weren't I asked you if you knew and you volunteered to ask :p

[rogerdpack]

True, true