<p>An MP4 file normally contains H.264 video and AAC audio, both of which are compatible with the FLV container. You could simply copy over the streams:</p>

<pre><code>ffmpeg -i input.mp4 -c copy output.flv
</code></pre>

<p>Since you're copying the streams, this will be as close to instantaneous as you're going to get and will not result in any loss of quality.</p>

CC BY-SA 3.0
2014-10-07T07:37:44.423Z
2014-10-07T07:37:44.423Z
evilsoup
<p>RAM is not the critical part of a transcode, CPU is.  Since it is working stream to stream, fairly minimal memory actually has to be required if the encoder is operating efficiently.  The memory speed does matter for scratch space for the processor, but not so much the quantity.</p>

<p>The CPU (or GPU if using GPU optimized encoding) is what does all the work and most likely your VPS has insufficient processing power.  Video encoding is <em>extremely</em> intensive.  It is one of the primary reasons that video editing workstations tend to be large powerful computers, often with multiple graphics cards to spread the load to GPU processing or dedicated hardware encoding peripherals.</p>

<p>Depending on the length of video represented by that 500mb file, this isn't at all surprising.   Even on my 2.9ghz quad core i7, it still takes roughly 2 to 3 times the length of the original video to complete a high quality 2 pass VBR encoding (and all 8 virtual cores are at 99% non-stop the entire time).  You may not be doing two pass, but you also likely don't have nearly as much processing power being thrown at it.</p>

CC BY-SA 3.0
2014-07-13T07:48:57.120Z
Hello @AJ Henderson, thank you for the detailed information. I really appreciate it.
user3583903
CC BY-SA 3.0
2014-07-12T16:50:42.930Z
2014-07-12T16:50:42.930Z
AJ Henderson
<p>Given your are using a VPS this is no suprise (guessing you only have a single core with 1-3GHz) and you won't be able to crunch the conversion down to a few minutes. You can try using <code>-c:v libx264 -presets ultrafast</code> but I'd guess it will still take you about 45-60 minutes to encode.</p>

<p>Also remove the <code>-crf</code> option when using a preset (they choose a default that produces a very good balance between speed and quality, I only recommend to modify that value when you know what it really does)</p>

<p>Be advised that the quality you get from that preset is not exactly great. If you NEED fast encoding speed over everything then go for it, if it's not THAT important I'd suggest using <code>fast</code> oder <code>faster</code> instead of the <code>ultrafast</code> preset.</p>

CC BY-SA 3.0
2014-07-13T07:47:46.073Z
Hi, this solved the time issue. But, the .flv file being generated after conversion is about twice the size of the original .mp4 file in "ultrafast" mode, and thrice the size of the original .mp4 in "fast" mode. :(
user3583903
CC BY-SA 3.0
2014-07-13T12:21:07.980Z
Thats one of the trade offs you get for the fast conversion, you can't have small good looking files and a good compression.
In ultrafast it also uses a smaller bitrate afaik, which would explain the smaller size.

-crf 28 what you used before is a rather aggressive compression. Normally you use something around 20-22 when encoding with constant quality.
timonsku
CC BY-SA 3.0
2014-10-12T19:15:25.753Z
Why do you recommend removing `-crf` when using a `-preset`? If removed, then the default of `-crf 23` will be used.
llogan
CC BY-SA 3.0
2014-10-12T19:42:58.027Z
Because the presets work very well with the settings they provide in that case crf 23. There is barely a reason to modify that value. Compression will increase with a higher preset even though the crf value is the same for all presets. I'm assuming amateur knowledge here, if you want do more you will not have to ask basic questions as you will very quickly discover how these (basic) settings actually work and will make your own fine tuned settings tailored to your content.
timonsku
CC BY-SA 3.0
2014-10-12T19:45:58.230Z
edited the question to refelect that
timonsku
CC BY-SA 3.0
2014-07-12T10:55:40.723Z
2014-10-12T19:45:49.363Z
2014-10-12T19:45:49.363Z
timonsku
<p>I am converting .mp4 files to .flv using ffmpeg in centos. But the conversion time is extremely too slow! It takes about 1.5 hours to convert 500MB .mp4 file into .flv. I am using a linux vps with 2 GBs dedicated RAM.</p>

<p>I am using the following code:</p>

<pre><code>ffmpeg -i source.mp4 -c:v libx264 -ar 22050 -crf 28 destination.flv
</code></pre>

<p>Is there any way I can fasten the conversion time? Any help/suggestions will be appreciated.</p>

<video><ffmpeg><conversion>
FFmpeg MP4 to FLV too slow
user3583903
# FFmpeg MP4 to FLV too slow

(Asked by: username_0 on 2014-07-12)

I am converting .mp4 files to .flv using ffmpeg in centos. But the conversion time is extremely too slow! It takes about 1.5 hours to convert 500MB .mp4 file into .flv. I am using a linux vps with 2 GBs dedicated RAM.
I am using the following code:
ffmpeg -i source.mp4 -c:v libx264 -ar 22050 -crf 28 destination.flv

Is there any way I can fasten the conversion time? Any help/suggestions will be appreciated.

**Tags:** video, ffmpeg, conversion


---

## 3 answers

### Answer by username_3 on 2014-07-12. Score: 2 | Accepted answer

Given your are using a VPS this is no suprise (guessing you only have a single core with 1-3GHz) and you won't be able to crunch the conversion down to a few minutes. You can try using `-c:v libx264 -presets ultrafast` but I'd guess it will still take you about 45-60 minutes to encode.

Also remove the `-crf` option when using a preset (they choose a default that produces a very good balance between speed and quality, I only recommend to modify that value when you know what it really does)

Be advised that the quality you get from that preset is not exactly great. If you NEED fast encoding speed over everything then go for it, if it's not THAT important I'd suggest using `fast` oder `faster` instead of the `ultrafast` preset.

> **Comments:**
> **username_0**: Hi, this solved the time issue. But, the .flv file being generated after conversion is about twice the size of the original .mp4 file in "ultrafast" mode, and thrice the size of the original .mp4 in "fast" mode. :(  
> **username_3**: Thats one of the trade offs you get for the fast conversion, you can't have small good looking files and a good compression. In ultrafast it also uses a smaller bitrate afaik, which would explain the smaller size.  -crf 28 what you used before is a rather aggressive compression. Normally you use something around 20-22 when encoding with constant quality.  
> **username_4**: Why do you recommend removing `-crf` when using a `-preset`? If removed, then the default of `-crf 23` will be used.  
> **username_3**: Because the presets work very well with the settings they provide in that case crf 23. There is barely a reason to modify that value. Compression will increase with a higher preset even though the crf value is the same for all presets. I'm assuming amateur knowledge here, if you want do more you will not have to ask basic questions as you will very quickly discover how these (basic) settings actually work and will make your own fine tuned settings tailored to your content.  
> **username_3**: edited the question to refelect that  

---

### Answer by username_1 on 2014-10-07. Score: 2

An MP4 file normally contains H.264 video and AAC audio, both of which are compatible with the FLV container. You could simply copy over the streams:
ffmpeg -i input.mp4 -c copy output.flv

Since you're copying the streams, this will be as close to instantaneous as you're going to get and will not result in any loss of quality.


---

### Answer by username_2 on 2014-07-12. Score: 1

RAM is not the critical part of a transcode, CPU is. Since it is working stream to stream, fairly minimal memory actually has to be required if the encoder is operating efficiently. The memory speed does matter for scratch space for the processor, but not so much the quantity.

The CPU (or GPU if using GPU optimized encoding) is what does all the work and most likely your VPS has insufficient processing power. Video encoding is *extremely* intensive. It is one of the primary reasons that video editing workstations tend to be large powerful computers, often with multiple graphics cards to spread the load to GPU processing or dedicated hardware encoding peripherals.

Depending on the length of video represented by that 500mb file, this isn't at all surprising. Even on my 2.9ghz quad core i7, it still takes roughly 2 to 3 times the length of the original video to complete a high quality 2 pass VBR encoding (and all 8 virtual cores are at 99% non-stop the entire time). You may not be doing two pass, but you also likely don't have nearly as much processing power being thrown at it.

> **Comments:**
> **username_0**: Hello @username_2, thank you for the detailed information. I really appreciate it.  

---

