>add -cpu-used 5 for the 1st pass and -cpu-used 0 for the 2nd one >use classic VBR (-b:v ) + qmax if you want to hit a specific file size limit >decide to encode Vorbis or suppress audio output Right now you suppress it during the 1st pass and encode Opus (in case of an input audio stream) during the 2nd one. >use the null demuxer (-f null -) for slightly better 1st pass performance >calculate target bitrate based on video length and file size limit Just off the top of my head.
Alexander Kelly
That's absolutely abhorrent. Try this one instead: mkdir out for f in *.{mp4,mkv,webm}; do ffmpeg -i "%%f" -pass 1 -y -an -c:v libvpx -auto-alt-ref 1 -lag-in-frames 25 -bf 16 -b:v 256k -deadline best -cpu-used 0 -f webm /dev/null ffmpeg -i "%%f" -pass 2 -y -an -c:v libvpx -auto-alt-ref 1 -lag-in-frames 25 -bf 16 -b:v 256k -deadline best -cpu-used 0 -f output.webm; done
Jason Campbell
whoops, -i "$f"
Zachary Brooks
Kinda pointless to write a loop and output each encode to the same file. Also VP8 has no B-frames.
>Kinda pointless to write a loop and output each encode to the same file. elaborate, I'm 3/rds tarded when it comes to batch script
>Also VP8 has no B-frames. It does when you enable alternate ref frames I believe. It makes a difference to me.
Nicholas Long
Okay I gotchu user, what do you need to do to output each encode to a different file? "-f webm $f_2pass.webm" ?
Brody Cruz
btw, you can run bash scripts on your android smartphone through the Termux app currently on the playstore, just download ffmpeg and give it storage access permissions.
FFmpeg will automatically choose the right muxer based on the file extension.
>elaborate, I'm 3/rds tarded when it comes to batch script Say you have a.mp4, b.mp4 and c.mp4. You run your loop. ffmpeg will convert all three videos, but will always write the output to output.webm. Since you also use the -y flag, it won't even prompt you, whether you want to overwrite the file or not. So in the end you'll have one output file, which is c.mp4 transcoded to WebM. Use something like ${f%.*}_convert.webm instead. With the previous example you'd end up with a_convert.webm, b_convert.webm and c_convert.webm. >It does when you enable alternate ref frames I believe. It makes a difference to me. Alternate reference frames (which are also reference frames, but not B-frames) will be used if you utilize 2-pass encoding and have -auto-alt-ref 1 set. Also I just ran your commands on a test file. Once with -bf 16 and once without. diff says that they are identical.
Isaac Cook
So you only need that for the /dev/null on pass 1?
Leo Bailey
In this case, yes. Although you don't need to discard the output to /dev/null. If you use the null muxer (-f null -) you avoid the overhead of writing to a file (even if said file immediately discards the data).
Ian Roberts
You are but a babe import os from subprocess import call from PIL import Image
finishedPath = os.path.abspath(".")+"/converted_gifs/" directory =os.listdir(".") if not os.path.isdir(finishedPath): os.makedirs(finishedPath) print "can't find dir" for o in directory: if ".gif" in o: loadedgif= Image.open(o) bitrate=1.96*loadedgif.size[1]-320.4 if bitrate < 200: bitrate = 200 fullpath = os.path.abspath(o).replace(" ","\ ") newfilename = finishedPath+o[:-4].replace(" ","\ ")+".webm" call(["ffmpeg", "-i", fullpath,"-auto-alt-ref","0", "-an","-b:v",str(bitrate)+"k","-c:v", "libvpx",newfilename])
This is why the freetarded community can't have nice things.
Chase Johnson
My gf kyoko is so cute
Jason Torres
I meant mine was abhorrent not that it was great
Andrew Jones
>"The so-called alternate reference frames (altref) can serve as reference-only frames for displaying them can be deactivated. In this case the encoder can fill them with arbitrary useful image data, even from future frames, and thereby serve the same purpose as the b-frames of the MPEG formats."
Follow the link that was provided as source for the statement. The wording in the wiki article is somewhat misleading. blog.webmproject.org/2010/05/inside-webm-technology-vp8-alternate.html >The lack of B frames in VP8 has sparked some discussion about its ability to achieve competitive compression efficiency. VP8 encoders, however, can make intelligent use of the golden reference and the alternate reference frames to compensate for this. The VP8 encoder can choose to transmit an alternate reference frame similar to a "future" frame, and encoding of subsequent frames can make use of information from the past (last frame and golden frame) and from the future (alternate reference frame). Effectively, this helps the encoder to achieve results similar to bidirectional (B frame) prediction without requiring frame reordering in the decoder. Alternate reference frames are definitely not the same as B-frames and whether their efficiency is comparable to B-frames is doubtable. It's difficult to say where the shortcomings of a standard begin and the problems of the only available encoder end, but we do know that VP8 via libvpx compresses worse than AVC via libx264.