What is FFmpeg?
ffmpeg.org/about/html
>FFmpeg is the leading multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything that humans and machines have created. It supports the most obscure ancient formats up to the cutting edge.
>Documentation:
ffmpeg.org
>Wiki:
trac.ffmpeg.org
>How to make reaction webms from video:
wiki.installgentoo.com
Other urls found in this thread:
just use script for mpv.
OP, you should probably take this discussion to . At least that's where I learned all my skills. Here's a screencap of the occasional Webm Academy threads. That's basically all you need to get mad ffmpeg skills.
In essence, always specify minimum quality metrics. If the very start of your reaction webm is pixelated, pass a "-qmax 40" option. This option sets what the lowest permissible video quality can be. Higher values mean lower allowed quality. I use anywhere between 40 and 55.
Second, make use of the "-crf" option, which sets an average quality metric. 23 is a good default option. Lower values mean better quality.
Lastly, pay attention to the average bitrate shown by ffmpeg and compare it to the bitrate you asked it to. If the encoder consistently chooses higher bitrates than what you specify in the "-b:v" option, this means that it is incapable of maintaining such low bitrates while also maintaining the quality settings. In such cases you can either reduce the quality or simply resize output via a video filter: "-vf scale=-1:480". The "-1" here tells the encoder to maintain the aspect ration; this way you avoid squishing the video.
That's my 2ยข. I'll stick around if you have any questions.
t-thanks thats a lot of help
>t-thanks thats a lot of help
Glad to be of help.
I just remembered another thing, be prepared for failing quite a lot, especially in cases where your video's filesize ends up too big for the chans.
Here's what I do: I always calculate the necessary bitrate for some video. You can do it like this:
(4096 - [size of audio track if available]) * 8 / (video length in seconds)
4096 is the 4M size limit for /wsg/ and /gif/. You can substitute it for 3072 if you're making webm-s for other boards.
To get the audio size you can make an initial encode without video via specifying "-vn" - no video track. The resulting file's size will only include the size of the audio track and 2-3KB of overhead.
Speaking of audio, many /webm/ denisens make the following mistake: they leave the audio quality far too high for the purpose of their clip. If you're not sharing pristine high-fidelity music, then you can shave off as many KB as you can. OGG vorbis scales really well with low bitrates. The options I typically use are: "-q:a 1 -ac 1". "q:a" is audio quality, lower values mean lower quality; "ac" specifies the number of audio channels. I personally cannot tell the difference between "-q:a 1" and literally any higher audio quality value; only "-q:a 0" is noticeably worse.
If you set the audio channels to 1, then the OGG encoder automatically downmixes the audio to what amounts to "joint stereo" in the lingo of mp3-s - more room for gorgeous video.
when are we getting vp9 support, lads?
>when are we getting vp9 support, lads?
With Hiro at the helm?? Absolutely fucking never! I bet we won't even get AV1 support once it finally hits and blows vp9, HEVC and apple's stuff out of the water.
Such is the burden of maintaining a site older than half its userbase.
no bully
about screencaps
I'm a dev.
What new features would you like to see.
how can I convert a a video to webm with a fixed target size and variable quality? That's all I'm asking for.
Just take screenshots in VLC.
>how can I convert a a video to webm with a fixed target size and variable quality? That's all I'm asking for.
Math + fine tuning.
(4096 - [size of audio track if available]) * 8 / (video length in seconds)
Refer to the other posts in this thread.
doest work for me, help
command I'm using for a 30 second video:
ffmpeg -i video.mov -codec:v libvpx -b:v 800K -threads 3 -an output.webm
video ends up with 4.4MB
>video ends up with 4.4MB
You still don't seem to be reading the thread to the end:
>If the encoder consistently chooses higher bitrates than what you specify in the "-b:v" option, this means that it is incapable of maintaining such low bitrates while also maintaining the quality settings. In such cases you can either reduce the quality or simply resize output via a video filter: "-vf scale=-1:480". The "-1" here tells the encoder to maintain the aspect ration; this way you avoid squishing the video.
>reduce the quality or simply resize output via a video filter: "-vf scale=-1:480"
Also, you're not giving any info on the quality, stick a "-crf 23" somewhere in you ffmpeg command.
You can also post a link to the original video so that we can have a go at it and share ffmpeg commands.
>it is incapable of maintaining such low bitrates
so it's shit. I just set the bitrate to 400K and it literally manages to keep 800K now.
Fuck ffmpeg.
>Here's what I do: I always calculate the necessary bitrate for some video. You can do it like this:
That's not really a reliable formula, because there's no account for container overhead that increases based on video length, video bitrate and audio bitrate. For short videos this formula may be passable, however longer ones will fail to match the desired size. There's a lazy option to simply repeat encode using smaller bitrate that multiple user-friendly encoding applications use, however it's a timewaste, moreso on slower systems like mine.
What I do, is first determine potential container overhead size, then derive overall allowed media bitrate from that. Using media bitrate I can determine how much of the bitrate to give to audio. If the media bitrate is too low, audio gets considerably compressed, channels removed. What's left gets given to video.
Here comes my own laziness, the container overhead determination is a shitty approximate formula, proper option would be to actually study the mkv+webm specification. Currently though it's this:
[duration] * 1000 * ( [if audio is used [180] else [150]] / [duration] + 1 ) / 4
For long videos this is quite a good match, shorter videos that are allowed higher bitrates may be off by about 500Ks in the final filesize.
Knowing video bitrate I attempt to determine video resolution allowed based on motion present gathered through vmafmotion filter and the bitrate given. Video resolution here stands for total macroblock count allowed, as further process may then make the video anamorphic to increase vertical resolution so the video appears bigger when viewed in a non-resizable player, like on Sup Forums.
43 * power( power( [videobitrate] / [vmafscore],1.35 ), 0.5)
If the bitrate is small enough, any high-framerate videos get limited to 30fps.
As you can see this is pretty hacky and misses wider functionality but it's what a more accurate approach would be like.
Don't use lossy PNG compression. Use pngcrush for lossless PNG compression.
Or optipng. Just heard about this one. Both pngcrush and optipng are FOSS, and they don't quantize (aka lossy compression) colors.
it's a screen cap, you can hardly tell the difference, what do you need lossless for in this case?
Try 2-pass encoding without the quality target. Make sure to either use -quality best or -quality good with the latter using -cpu-used between 0 and 2. cpu-used is meant to adjust encoding speed and also how well the encoder can control the rate. Higher values have encoding hacks that may not maintain the given bitrate and overshoot. -quality itself sets an encoding preset to use; best is slower than good while not always producing considerable quality difference. Beside those there's also 'realtime', which isn't meant for bitrate constraint situations but for encoding speed.
You may have a point, but many screencaps have pictures in them. If the entire point is to get the caps under 4 MB, then lossless should be the first goto. If the point is reducing data transmission, then lossy is fine.
brb gonna write a script for lossless compression, then it will check file size. If larger than 4 MB, it will do your lossy compression.
>quality target
ok sorry, meant -crf or -q:v target. The further -quality things given should be used. I'd suggest -quality good -cpu-used 0.
>screencaps have pictures
either a graph (with single colours) then no visual degradation
or a face / IRL pic (with shades) then possible visual degradation but those IRL pics are rarely the important part of the screen cap and pngquant actually does a really good job to preserve them (not degrade them like the imagemagick alternative, which is crude by comparison)
>brb gonna write a script
Can you please consider these?
pngoptim.cmd
optipng %~1 && IF %~z1 GEQ 4194000 pngquant --nofs %~1
pngoptim.sh
optipng "$1"
if [ $(wc -c < "$1") -ge 4194000 ]; then
pngquant --nofs "$1";
fi
Pic related is testing an image of 4193910 bytes, which is close to 4194304 bytes (4 MB).
Whoops, fixed Windows version
pngoptim.cmd
optipng "%~1" && IF %~z1 GEQ 4000000 pngquant --nofs "%~1"
Fixed fixed version, dammit.
optipng "%~1" && IF %~z1 GEQ 4194000 pngquant --nofs "%~1"
bump
for Sup Forums i made a simple script with this two steps, adapted from:
trac.ffmpeg.org
ffmpeg -i input.mp4 -c:v libvpx -b:v 600k -pass 1 -speed 4 -f webm /tmp/null
ffmpeg -i input.mp4 -c:v libvpx -b:v 600k -pass 2 -speed 1 output.webm
Nice try, but it's hard to make a one-size-fits-all script. Some videos can afford higher bitrates, while others cannot. You also need to convert the audio into Vorbis and specify the audio bitrate (otherwise the defaults are used). (Use libopus for other websites, as Sup Forums doesn't allow Opus audio).
Turn your script into a 1-liner with && (Linux and Windows). This will prevent the 2nd pass from executing if pass 1 throws an error.
ffmpeg -i input.mp4 -c:v libvpx -b:v 600k -pass 1 -speed 4 -c:a libvorbis -b:a 128k -f webm /dev/null && ffmpeg -i input.mp4 -c:v libvpx -b:v 600k -pass 2 -speed 1 -c:a libvorbis -b:a 128k output.webm
I recently installed ffmpeg and it's so dope
i don't even know that Sup Forums accepts audio, i take off with the subtitles in a previous step.
>some videos can afford higher bitrates
it's just for shitposting on Sup Forums
Oh, my bad. I'm used to encoding stuff on /wsg/. -an to remove audio.
ffmpeg -i input.mp4 -c:v libvpx -b:v 600k -pass 1 -speed 4 -an -f webm /dev/null && ffmpeg -i input.mp4 -c:v libvpx -b:v 600k -pass 2 -speed 1 -an output.webm
If you want to shitpost on Sup Forums, you may want to get used to the -ss and -t xor -to options for cutting up videos.
when to use different modes:
CBR: fixed-bandwidth streaming, such as television, where you have no reason to diverge from the limit
CRF: when an approximate quality level is desired, with no particular requirement for size or bandwidth, good for permanent storage on arbitrary-size storage like hdd's and internet clips
constrained CRF: like above but with a bandwidth cap, good for streaming on a shared link, such as over the internet
1-pass ABR: use CRF
2-pass ABR (VBR): for fixed-sized storage media, such as dvd's, to make the most of the available space
you should use CRF in most cases when posting on Sup Forums or other websites, unless the video is difficult to fit within the limits, in which cases 2-pass ABR can be used. using 2-pass ABR for things that easily fit within limits is overkill and a waste of space/bandwidth