[SOLVED] FFmpeg so slow after updating

michijo · 12-01-2012, 10:11 PM

Anyone noticed ffmpeg slowing down lately in recent updates I got through slackware?

I have used ffmpeg for years to strip mp3s out of flv videos with a simple command

# ffmpeg -i video.flv song.mp3

And that often worked very fast. Recently I got some updates through SBOPKG and it drags so slow and uses 100% CPU power while working.

Cant understand this new disturbance in ffmpeg.

gapan · 12-02-2012, 04:50 AM

Most probably nothing to do with ffmpeg itself and the flv videos you were using before included mp3 audio. So, ffmpeg just copied over the mp3 stream to the new file. The ones you are trying now probably have a different kind of audio encoding (probably aac) so the aac stream needs to be transcoded to mp3. So, that would be normal. If you had posted the complete output of ffmpeg when you run it, it would have provided more info.

414N · 12-02-2012, 04:59 AM

Also note that, to perform an audio stream copy you'd need to use

Code:

ffmpeg -i input.flv -acodec copy output.mp3

but only if the source flv file contained an mp3 audio track.

tuxbg · 12-02-2012, 05:22 AM

What version is ffmpeg.
I have a problem with ffmpeg-0.11.2 -vpre lossless_ultrafast ffmpeg report that there is no such option
And also use 100% of my cpu,when i perform a screen record
Sorry for my english

GazL · 12-02-2012, 05:37 AM

Using 100% of cpu is normal for something like ffmpeg. It just means it's making full use of your machines capabilities. If you want to maintain interactivity while your encode is running you may want to use nice, chrt, and/or ionice to drop its relative priority. I have an alias setup for convenience when doing this sort of stuff:

Code:

alias niceterm='chrt -i 0 ionice -c 3 xterm -T niceterm'

Also, the command line syntax was changed a while back. Try doing it like this:

Code:

... -vcodec libx264 -profile high -preset veryslow -tune film "out.mp4"

tuxbg · 12-02-2012, 06:24 AM

Quote:

Originally Posted by GazL

Using 100% of cpu is normal for something like ffmpeg. It just means it's making full use of your machines capabilities. If you want to maintain interactivity while your encode is running you may want to use nice, chrt, and/or ionice to drop its relative priority. I have an alias setup for convenience when doing this sort of stuff:

Code:

alias niceterm='chrt -i 0 ionice -c 3 xterm -T niceterm'

Also, the command line syntax was changed a while back. Try doing it like this:

Code:

... -vcodec libx264 -profile high -preset veryslow -tune film "out.mp4"

Thank you that work

Martinus2u · 12-02-2012, 07:32 AM

Quote:

Originally Posted by GazL

Using 100% of cpu is normal for something like ffmpeg. It just means it's making full use of your machines capabilities. If you want to maintain interactivity while your encode is running you may want to use nice, chrt, and/or ionice to drop its relative priority. I have an alias setup for convenience when doing this sort of stuff:

Code:

alias niceterm='chrt -i 0 ionice -c 3 xterm -T niceterm'

Another way is to operate console windows at lower priority by default. To that end I say

Code:

if [ "$TERM" = "xterm" ]; then
# renice 19 $$ > /dev/null
  schedtool -D $$
  ionice -c 3 -p $$
fi

in my ~/.profile (and I source ~/.profile from ~/.bashrc).

Note on a vanilla kernel you would uncomment the "renice" line and comment out the "schedtool" line. The schedtool line is for a kernel with BFS, an advanced scheduler that makes the desktop experience smoother. Like I can compile kernels in the background on all hyperthreads and won't feel the slighteste difference to my desktop/sound/3D gaming.

GazL · 12-02-2012, 12:06 PM

Quote:

Originally Posted by Martinus2u

Another way is to operate console windows at lower priority by default. To that end I say

I use the "renice -p $$" trick in many of my scripts. I don't think I'd be inclined to add it to a .bashrc, but that's just me.

michijo · 12-02-2012, 06:16 PM

Quote:

Originally Posted by 414N

Also note that, to perform an audio stream copy you'd need to use

Code:

ffmpeg -i input.flv -acodec copy output.mp3

but only if the source flv file contained an mp3 audio track.

No, I have tried that before. It doesnt work.

All I am doing is downloading youtube videos, then ripping the mp3 out of them. Nothing has changed about my practice doing this for years. But immediately after updating or upgrading ffmpeg, it suddenly became slow.

The basic command

#ffmpeg -i video.flv song.mp3

has always worked extremely well, as I can boast an mp3 collection of some size as a result! And all of these mp3s are solid, which play on portable mp3 players.

michijo · 12-02-2012, 06:20 PM

Quote:

Originally Posted by tuxbg

What version is ffmpeg.
I have a problem with ffmpeg-0.11.2 -vpre lossless_ultrafast ffmpeg report that there is no such option
And also use 100% of my cpu,when i perform a screen record
Sorry for my english

I am using this

Code:

ffmpeg version 0.11.1 Copyright (c) 2000-2012 the FFmpeg developers
  built on Nov 29 2012 12:54:37 with gcc 4.7.1
  configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib --mandir=/usr/man --disable-debug --enable-shared --disable-static --enable-pthreads --enable-libtheora --enable-libvorbis --enable-gpl --enable-version3 --enable-postproc --enable-swscale --enable-x11grab --enable-avfilter --enable-gnutls --enable-libcdio --arch=i486 --enable-libmp3lame --enable-libx264
  libavutil      51. 54.100 / 51. 54.100
  libavcodec     54. 23.100 / 54. 23.100
  libavformat    54.  6.100 / 54.  6.100
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 77.100 /  2. 77.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100

michijo · 12-02-2012, 06:28 PM

It seems it is now cycling through frames in such a way that it has never done in the past, taking many minutes to rip out one mp3:

Code:

frame= 1205 fps= 27 q=0.0 Lsize=     763kB time=00:00:40.20 bitrate= 155.4kbits

It goes through a billion "frames" and runs at 100% cpu for a good 5 minutes on one little song. My computer sounds like a jet taking off whenever I use it now.

michijo · 12-02-2012, 07:37 PM

I see actually a new version that isnt in slackbuilds.org called "Angel" 1.0. I will install this directly from ffmpeg site and see if it is this version 0.11 that comes with slackware 14 that is the problem.

michijo · 12-02-2012, 09:48 PM

Okay! That did it, I upgraded to Angel and this "frames" problem is gone. Now it rips the mp3 out very fast with minimal noise. I doctored the slackbuild from sbo.org to point to the new version angel 1.0 and also installed a bunch of other stuff with it, namely every variable available:

Code:

ASS=yes|no (default: no), requires libass
BLURAY=yes|no (default: no), requires libbluray
CELT=yes|no (default: no), requires celt
DC1394=yes|no (default: no), requires libdc1394
FAAC=yes|no (default: no), requires faac (creates non-redistributable binary)
FREI0R=yes|no (default: no), requires frei0r
GSM=yes|no (default: no), requires gsm
JP2=yes|no (default: no), requires openjpeg
LAME=yes|no (default: yes), requires lame
OPENAL=yes|no (default: no), requires OpenAL
OPENCORE=yes|no (default: no), requires opencore-amr
OPENSSL=yes|no (default: no), creates non-redistributable binary
RTMP=yes|no (default: no), requires rtmpdump
SCHROEDINGER=yes|no (default: no), requires schroedinger
SPEEX=yes|no (default: no), requires speex
VPX=yes|no (default: no), requires libvpx
X264=yes|no (default: yes), requires x264
XVID=yes|no (default: no), requires xvidcore

After installing all of those and adding them to the package, it rips like a charm. It no longers says "frames" but says

"size= 116kB time=00:00:14.76 bitrate= 64.5kbits/s"

That is what it always said before. It never said frames before. It only takes a few seconds to rip an mp3 from an flv now like the good old days.

414N · 12-03-2012, 02:16 AM

Quote:

Originally Posted by michijo

No, I have tried that before. It doesnt work.

All I am doing is downloading youtube videos, then ripping the mp3 out of them. Nothing has changed about my practice doing this for years. But immediately after updating or upgrading ffmpeg, it suddenly became slow.

The basic command

#ffmpeg -i video.flv song.mp3

has always worked extremely well, as I can boast an mp3 collection of some size as a result! And all of these mp3s are solid, which play on portable mp3 players.

I beg to differ.
If you don't tell ffmpeg to actually copy the audio stream as-is then it will perform a stream conversion even if the input stream was in the same format of the output stream (mp3). You won't probably notice it if your system sports a fast CPU, because audio conversion is generally performed orders of magnitude faster than an audio+video conversion.
On my system, performing

Code:

time ffmpeg -i input.flv output.mp3

on a flv file with an mp3 audio track returns this:

Code:

real	0m6.165s
user	0m5.770s
sys	0m0.068s

while, on the same input file

Code:

time ffpmeg -i input.flv -acodec copy output2.mp3

yields:

Code:

real	0m0.270s
user	0m0.121s
sys	0m0.098s

I guess it's kinda obvious that the first command performed something heavier on the CPU while the second one went a lot lighter on the system.
You can read more about "stream copy" in this chapter of the ffmpeg documentation.
You'll find that the option for selecting an audio codec is not "-acodec" but "-c:a": this is because the syntax of some options is changing for the sake of consistency.

michijo · 12-03-2012, 10:18 AM

Quote:

Originally Posted by 414N

I beg to differ.
If you don't tell ffmpeg to actually copy the audio stream as-is then it will perform a stream conversion even if the input stream was in the same format of the output stream (mp3). You won't probably notice it if your system sports a fast CPU, because audio conversion is generally performed orders of magnitude faster than an audio+video conversion.
On my system, performing

Code:

time ffmpeg -i input.flv output.mp3

on a flv file with an mp3 audio track returns this:

Code:

real	0m6.165s
user	0m5.770s
sys	0m0.068s

while, on the same input file

Code:

time ffpmeg -i input.flv -acodec copy output2.mp3

yields:

Code:

real	0m0.270s
user	0m0.121s
sys	0m0.098s

I guess it's kinda obvious that the first command performed something heavier on the CPU while the second one went a lot lighter on the system.
You can read more about "stream copy" in this chapter of the ffmpeg documentation.
You'll find that the option for selecting an audio codec is not "-acodec" but "-c:a": this is because the syntax of some options is changing for the sake of consistency.

Interesting, and it does work faster as you say, almost instantaneous. I will probably do this from now on with acodec option, where it works of course.

Nevertheless, what I wrote about the current version of ffmpeg shipped with Slackware 14 being broken is true. I had to upgrade beyond what was supplied by slackbuilds.org in order to get a non-broken ffmpeg. It might be something to look into at SBO. The acodec option didnt even work with the current ffmpeg that ships with slackware 14.