I have to convert 76 mp4 files to webm for the purpose of a website that uses HTML5 videos. I'm talking about 10 Gb of mp4 files... I know I can simply ask ffmpeg to do that using:

ffmpeg -i input_file.mp4 output_file.webm

Of course I'll do it recursively by:

find ./ -name '*.mp4' -exec bash -c 'ffmpeg -i "$0" "${0%%.mp4}.webm"' {} \;

I even tried something I found somewhere on the internet:

ffmpeg -i input_file.mp4 -cpu-used 4 -threads 8 output_file.webm

But the thing is that it won't take me less than a week!!! What am I doing wrong? Is there any possible way to speed that up? If I convert to ogg will I gain on speed? Please help!!!

  • 2
    See FFmpeg Wiki: vpx (WebM) Encoding Guide.
    – llogan
    Mar 21, 2013 at 0:01
  • @LordNeckbeard you should write up an answer based on that guide. Also, it should be noted that the vpx encoder is slow as molasses, even with sane settings etc., compared to x264... unless you are willing to sacrifice a lot of quality, lit is impossible to get really fast encodes with it.
    – evilsoup
    Mar 24, 2013 at 16:12
  • The problem is about compatibility.. This is a little compatibility table: {x264: IE(+) Safari(+) Chrome(+) Firefox(-) Opera(-)} {webm: IE(-) Safari(-) Chrome(+) Firefox(+) Opera(+)} I know they say Safari and IE hold the biggest part of the market but I seriously doubt it and would bet on Firefox and Opera! ;)
    – pr.nizar
    Mar 24, 2013 at 22:40
  • @pr.nizar Thanks to Cisco releasing OpenH264 under BSD, firefox now supports h.264.
    – Wyatt Ward
    Mar 16, 2015 at 16:49

3 Answers 3


Double that or half cut that? So it's a dead end.. I won't be playing with bitrates, I never know what to expect from quality or size.. I think I'll stick to this one and make the client hold on till conversion is over..

find ./ -name '*.mp4' -exec bash -c 'ffmpeg -i "$0" -vcodec libvpx -acodec libvorbis -cpu-used 5 -threads 8 "${0%%.mp4}.webm"' {} \;

I'm posting it for future users, actually I gained on speed but my CPU is working like hell: 60 to 80% on each core! Now I think it will take less time: 3 days instead of 6 or 7.. I hope it won't break it down.. ^_^

Thank you anyway man!

Edit: Removed the switch -sameq after comments from LordNeckbeard and neon_overload -sameq does not mean same "quality"

  • 4
    -sameq does not mean "same quality" and has been removed upstream. Do not use it. Refer to the link in my comment to your question for detailed libvpx encoding instructions.
    – llogan
    Mar 21, 2013 at 18:21
  • 2
    -sameq means same quantizer, however it's impossible to compare quantizers between h.264 and VP8, so even if this did work, you almost certainly would get broken results if you used it - so don't. Mar 23, 2013 at 6:33
  • 2
    Thank you man for bringing my attention to that! I edited my response.. ;) Actually I did not use that switch cause I saw it was getting it even slower.. I even dropped ffmpeg and used avconv: IT'S WAY FASTER! The job was done in one day and a half with this: find ./ -name '*.mp4' -exec bash -c 'avconv -i "$0" -vcodec libvpx -acodec libvorbis -cpu-used 5 -threads 8 "${0%%.mp4}.webm"' {} \; I know I'm diverting the subject with this comment but I thought it was worth saying it.. ^_^ Hope it helps someone out! ;)
    – pr.nizar
    Mar 24, 2013 at 15:27
  • For the quality really I can't tell the differences between the original files and those webm trancoded: it's almost the same audio and video qualities!
    – pr.nizar
    Mar 24, 2013 at 15:42
  • 1
    It's still recommended that you either set a crf or bitrate value as opposed to using ffmpeg/avconv's defaults, whatever that may be. Mar 25, 2013 at 6:54

Transcoding video takes time. It also takes a lot more knowledge about encoding parameters; ffmpeg's defaults are unlikely to be suitable for you and may not even create a usable output file.

Here's a start:

Encoding webm using ffmpeg (Archived)

Those settings will encode to a particular average bitrate (video bitrate of 3900kbit), so there will be spikes in the bitrate.

MP4 and WebM use different video codecs, so there is no short-cut; video must be transcoded.

Encoding speed, of course, will vary immensely depending on the frame size, frame rate, and quality settings. For a 720p encode you might expect to be able to encode roughly 1:1 (ie 10 hours of video in 10 hours) on a CPU from the last couple of years. If you do two-pass ABR encoding like in the example given in the link, almost double that.


I use optimizeVideo, which automatically detects the conversion settings that have the best speed vs quality balance according to Google.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .