FFmpeg so slow after updating
 

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.

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.

Also note that, to perform an audio stream copy you'd need to use
but only if the source flv file contained an mp3 audio track.

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

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:

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

Thank you that work :)

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

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.

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.

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 am using this

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:

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.

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.

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:

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.

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
on a flv file with an mp3 audio track returns this:
while, on the same input file yields:
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.