2

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.

Improve this question

3 Answers 3

Reset to default
2

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.

Improve this answer
5
  • 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
    Jul 13, 2014 at 7:47
  • 1
    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
    Jul 13, 2014 at 12:21
  • 1
    Why do you recommend removing -crf when using a -preset? If removed, then the default of -crf 23 will be used.
    – llogan
    Oct 12, 2014 at 19:15
  • 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
    Oct 12, 2014 at 19:42
  • edited the question to refelect that
    – timonsku
    Oct 12, 2014 at 19:45
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.

Improve this answer
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.

Improve this answer
1
  • Hello @AJ Henderson, thank you for the detailed information. I really appreciate it.
    – user3583903
    Jul 13, 2014 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.