14

I am trying to convert a video from WMV to MP4 with FFmpeg but it takes couple of hours. If I try to convert it to AVI it only takes about 10-15 minutes.

ffmpeg version

ffmpeg version N-43206-gf857465
built on Aug  4 2012 16:10:39 with gcc 4.7.1 (GCC)

Conversion to MP4

ffmpeg -i input.wmv -vcodec libx264 output.mp4

libavutil      51. 66.100 / 51. 66.100
  libavcodec     54. 49.100 / 54. 49.100
  libavformat    54. 22.100 / 54. 22.100
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3.  5.102 /  3.  5.102
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, asf, from 'input.wmv':
  Metadata:
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    IsVBR           : 0
    encoder         : Lavf54.22.100
  Duration: 01:14:23.06, start: 0.000000, bitrate: 324 kb/s
    Stream #0:0: Video: msmpeg4 (MP43 / 0x3334504D), yuv420p, 1280x720, 15 tbr,
1k tbn, 1k tbc
[libx264 @ 03427620] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle Cac
he64
[libx264 @ 03427620] profile High, level 3.1
[libx264 @ 03427620] 264 - core 125 r2208 d9d2288 - H.264/MPEG-4 AVC codec - Cop
yleft 2003-2012 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deb
lock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 m
e_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chro
ma_qp_offset=-2 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 i
nterlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=15 scenec
ut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=
0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'output.mp4':
  Metadata:
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    IsVBR           : 0
    encoder         : Lavf54.22.100
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1280x720, q=-1--
1, 15 tbn, 15 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (msmpeg4 -> libx264)

Conversion to MP4 with copy

ffmpeg -i input.wmv -c:v:1 copy output.mp4

  libavutil      51. 66.100 / 51. 66.100
  libavcodec     54. 49.100 / 54. 49.100
  libavformat    54. 22.100 / 54. 22.100
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3.  5.102 /  3.  5.102
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, asf, from 'input.wmv':
  Metadata:
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    IsVBR           : 0
    encoder         : Lavf54.22.100
  Duration: 01:14:23.06, start: 0.000000, bitrate: 324 kb/s
    Stream #0:0: Video: msmpeg4 (MP43 / 0x3334504D), yuv420p, 1280x720, 15 tbr,
1k tbn, 1k tbc
[libx264 @ 03437620] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle Cac
he64
[libx264 @ 03437620] profile High, level 3.1
[libx264 @ 03437620] 264 - core 125 r2208 d9d2288 - H.264/MPEG-4 AVC codec - Cop
yleft 2003-2012 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deb
lock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 m
e_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chro
ma_qp_offset=-2 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 i
nterlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=15 scenec
ut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=
0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'output.mp4':
  Metadata:
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    IsVBR           : 0
    encoder         : Lavf54.22.100
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1280x720, q=-1--
1, 15 tbn, 15 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (msmpeg4 -> libx264)

Conversion to AVI with copy

ffmpeg -i input.wmv -c:v:1 copy output.avi

Input #0, asf, from 'input.wmv':
  Metadata:
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    IsVBR           : 0
    encoder         : Lavf54.22.100
  Duration: 01:14:23.06, start: 0.000000, bitrate: 324 kb/s
    Stream #0:0: Video: msmpeg4 (MP43 / 0x3334504D), yuv420p, 1280x720, 15 tbr,
1k tbn, 1k tbc
Output #0, avi, to 'output.avi':
  Metadata:
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    IsVBR           : 0
    ISFT            : Lavf54.22.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1280x720, q=2-31, 20
0 kb/s, 15 tbn, 15 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (msmpeg4 -> mpeg4)

Are there some additional parameters I need to pass?

slhck
  • 223,558
  • 70
  • 607
  • 592
Giorgi
  • 641
  • 2
  • 7
  • 18
  • Of course it's faster if you're just copying the bitstream — with `copy`, you're not re-encoding anything. What hardware do you have, e.g. CPU? What's your OS and which version of FFmpeg is that? – slhck Aug 10 '12 at 08:44
  • @slhck: The computer is not very fast E5400 2.7GHz but why is it slow for mp4 while it is fast for avi? – Giorgi Aug 10 '12 at 09:04
  • I don't see any AVI output in your question. Could you update it with the full output? – slhck Aug 10 '12 at 09:07
  • @slhck: added avi output – Giorgi Aug 10 '12 at 09:19

2 Answers2

21

Stream copying

When you call -c:v:1 copy, FFmpeg will take the existing video bitstream and stream copy it. The video bitstream is just encapsulated in the outside container, e.g. WMV, AVI or MP4 – your actual video bitstream is msmpeg4 and will stay like this.

If you want to know more about what I'm talking about, see here: What is a Codec (e.g. DivX?), and how does it differ from a File Format (e.g. MPG)?

When copying the bitstream, FFmpeg doesn't need to actually decode and re-encode the actual video. It just needs to merge the video bitstream into a new container format, which is often a rather simple operation and therefore doesn't take long.

Encoding

In contrast to that, if you call -vcodec libx264 (or -c:v libx264, the syntax you should use because vcodec is deprecated), FFmpeg will be forced to decode the video bitstream from msmpeg4 to a raw format, then pipe it into x264, a H.264 encoder.

x264 is fast, but still, encoding video takes time – especially when it's 720p content. And it might take more than one hour, especially if your input is already longer than one hour. Also, your CPU might not be the fastest. This is the main reason older MPEG-4 Visual encoders like XviD are still around and very popular: They take less time to encode than H.264 codecs. They might not give you the best performance in terms of quality vs. file size, but they are fast.

That all being said: You can speed up x264 encoding by forcing a preset. Presets are encoder optimization settings and range from: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow. Your command could then look like this:

ffmpeg -i input.wmv -c:v libx264 -preset fast out.mp4

It should run faster than without the preset. The only drawback is that it doesn't achieve as good quality for the same compression rates in comparison to, for example, -preset veryslow.

Apart from that, there's not much you can do except for investing in a speedy CPU, and making sure you're running a recent build of FFmpeg with x264 support.

For more info see FFmpeg Wiki: H.264 Encoding Guide.

slhck
  • 223,558
  • 70
  • 607
  • 592
  • Thanks for the answer. I'm not sure if I was clear or not but if I use copy it is still very slow. I tried your command and it has processed only 4 second after 5 minutes. My video is about 75 minutes long and converting to avi takes only 15 minutes but mp4 takes several hours. – Giorgi Aug 10 '12 at 09:59
  • so which one the best for encoding, libx264 or h264? – Yohanim Jul 09 '18 at 09:55
  • @NPE There is no difference as ffmpeg by default uses `libx264` when you specify ´h264` as the encoder. – slhck Jul 09 '18 at 10:12
  • @slhck When I trying to use this parameter `-y -i fileSource -s 1920x1080 -vcodec libx264 crf 20 fileOutput` takes more than an hours. To make this faster, what a recommendation parameter should I add based on your experience? Does `-preset fast` parameter enough? – Yohanim Jul 09 '18 at 10:26
  • @NPE The only way to make it faster (with the same hardware) is to use a faster preset, yes, e.g. `-preset faster`. – slhck Jul 09 '18 at 10:27
  • @slhck Is it possible to use multi thread or if possible using graphic card to make it more faster? – Yohanim Jul 09 '18 at 10:39
  • @NPE Multithreading is already enabled, but encoding cannot be easily parallelized that way. Several hardware-accelerated encoders are available, see https://trac.ffmpeg.org/wiki/HWAccelIntro — easiest would be NVIDIA. – slhck Jul 09 '18 at 11:07
  • I wouldn't recommend `ultrafast` for anything; it cares so little about quality that the output is pretty crap. It's ok for lossless encoding, where it just means a bit more bitrate. But for normal lossy encoding, `superfast` is significantly better and almost as fast. (At the extreme end of trading quality for speed, you're very far from the diminishing returns of slower vs. medium.) – Peter Cordes Mar 14 '19 at 02:53
  • 1
    @PeterCordes I changed it to `fast`. Some interesting statistics (if VMAF can be trusted here): https://streaminglearningcenter.com/blogs/saving-encoding-adjust-encoding-configuration-increase-capacity.html – slhck Mar 14 '19 at 06:47
  • @slhck: That spike in VMAF quality metric at `superfast`, and getting worse (per bitrate?) beyond medium is *highly* suspicious. I'm guessing it's either from CRF and not controlling for bitrate (superfast sets rc-lookahead=0), and/or the quality metric hates the psy decisions that x264 is making on purpose, but superfast's subme=1 or no-mbtree somehow helps by making not taking time to consider most psy or aq? (And at slower settings, higher subme makes more psy-dependent encoding decisions, which do even worse on this metric but look (hopefully) subjectively better.) – Peter Cordes Mar 14 '19 at 07:06
  • TL:DR: Unless VMAF tries to account for psy, the author of that blog is probably making the mistake that `x264 --psnr` or SSIM warns about: `--psnr used with psy on: results will be invalid!`. Tune=PSNR does `--aq-mode 0 --no-psy`, Tune=SSIM does `--aq-mode 2 --no-psy`. (As well as maybe making the mistake of not controlling for bitrate; he doesn't mention anything about rate-control settings, but his next blog entry is recommending CRF+VBV (I think from the title). That's a good choice for conversion throughput in production, but not good for benchmarking quality. – Peter Cordes Mar 14 '19 at 07:11
  • His x265 superfast recommendation is crazy, IMO, and its rc-lookahead=10 is way too short for content with varying complexity. If you're going to spend so little time encoding h.265, you might as well not use it at all and only have a good h.264 stream that you made with better settings for x264 (unless you're starving the bitrate). Except maybe for 4k, but high quality 1080p (with quality upscaling by the client...) will probably get you better quality for some choice of encode-time and bitrate than 2160p. I find that x265 is most worth using if you let it use much more time than x264. – Peter Cordes Mar 14 '19 at 07:21
  • (But I'm mostly encoding stuff on a quad-core desktop, and where quality per bitrate is the only thing I really care about. I hate low quality per bitrate video on the Internet that wastes everyone's disk space and/or has artifacts even at the highest bitrate you can DL, and the fact that blogs like this will lead to more of it. And it's impossible to xcode without losing *some* quality, so transcoding a well-compressed copy to keep is a hard decision to make. I'm a digital packrat...) – Peter Cordes Mar 14 '19 at 07:25
  • 1
    @PeterCordes There are some RC optimizations that VMAF does not handle well such as AQ: https://github.com/Netflix/vmaf/issues/21. I agree with the high-quality 1080p vs. crappy UHD part. The author of the blog is very open to suggestions on how to improve his testing; I already commented on some misconfiguration for x265 a while ago. – slhck Mar 14 '19 at 15:23
  • @slhck: That's good. And x264 faster is not *horrible*, it's not like 1080p or 2160p Baseline (nocabac nobframes), or Main profile (no 8x8dct hurts most at high rez, and sometimes without B-frames or without cabac from some sites). And yes I really have seen 4k Baseline at like 20Mbps. Android *still* doesn't guarantee High profile support (so it's a major contributor to really inefficient video on the Internet), but I doubt that any device capable of playing 1080p at 8Mbps lacks support for High profile, let alone 4k rez. – Peter Cordes Mar 14 '19 at 16:01
  • `-preset ultrafast` is pretty fast, faster than `-preset fast`. – Eric May 18 '20 at 04:28
3

AS I was playing (endless hours) with WMV->MP4 conversion, I found a superfast way to do it. But it has a price: a storage price. If you convert WMV to lossless, then from lossless to MP4, it does the full conversion in no time. But you need 100 times HDD space to store the lossless version, which is painful.

So it turns out you can chose from very slow or very HDD intensive versions of WMV->MP4 conversion and you have no other choice.

Converting a WMV to lossless AVI: ffmpeg.exe -i screen.wmv -vcodec ffv1 screen.avi Then converting lossless AVI to MP4 (or WebM, it doesn't matter) ffmpeg.exe -i screen.avi screen.mp4

Superfast!

Marcell Foti
  • 131
  • 1