How to fast convert mp4 to webm using ffmpeg?

Question

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!!!

Solution 1

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.

Solution 2

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"

Comments

[llogan]

See FFmpeg Wiki: vpx (WebM) Encoding Guide.

[evilsoup]

@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.

[Wyatt Ward]

@pr.nizar Thanks to Cisco releasing OpenH264 under BSD, firefox now supports h.264.

[Ciro Santilli OurBigBook.com]

Related: stackoverflow.com/questions/43612424/… | superuser.com/questions/1211786/…

[doug]

HTML5 supports mp4...

[llogan]

-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.

[thomasrutter]

-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.

[pr.nizar]

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]

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!

[thomasrutter]

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.