I used the following format this time:

ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 0 -b:v 0 -an output.webm

I also tried using libopus and libvorbi when doing a few test conversions but ran into problems. Those libraries were enabled but command line kept telling me that libopus and libvorbis were invalid.

There's flag reason for inferior version, so always prefer given reasons over custom whenever possible to keep things and searchability consistant.

Alia said:
I used the following format this time:

ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 0 -b:v 0 -an output.webm

I also tried using libopus and libvorbi when doing a few test conversions but ran into problems. Those libraries were enabled but command line kept telling me that libopus and libvorbis were invalid.

OK, so, -crf 0 will give you as high quality as possible without going to lossless mode, but there's good reason why nobody uses that - it bloats the file immensily. You will get diminishing returns, bitrate with this one is 10 times higher now, but the quality increase is not even twice better, partially thanks to source file being so extremely compressed to begin with.

Let's just leave this one as it is. There's absolutely zero point on fine tuning it more from the last post thanks to it being extremely compressed MP4 made out of GIF to begin with. You can do testing locally and there's bunch of people on discord to throw files at to ask if things look allright. Just in future, stick with more sane ranges, with extremely small, detailed and/or simple stuff use lower values and with larger, less refined and/or already compressed material go with higher values. Compare the results visually after encode, range I have seen to be useful is around 12-20.

and -c:a libopus works just fine over here.

Mairo said:
There's flag reason for inferior version, so always prefer given reasons over custom whenever possible to keep things and searchability consistant.

OK, so, -crf 0 will give you as high quality as possible without going to lossless mode, but there's good reason why nobody uses that - it bloats the file immensily. You will get diminishing returns, bitrate with this one is 10 times higher now, but the quality increase is not even twice better, partially thanks to source file being so extremely compressed to begin with.

Let's just leave this one as it is. There's absolutely zero point on fine tuning it more from the last post thanks to it being extremely compressed MP4 made out of GIF to begin with. You can do testing locally and there's bunch of people on discord to throw files at to ask if things look allright. Just in future, stick with more sane ranges, with extremely small, detailed and/or simple stuff use lower values and with larger, less refined and/or already compressed material go with higher values. Compare the results visually after encode, range I have seen to be useful is around 12-20.

-c:a libvorbis

and -c:a libopus works just fine over here.

Thanks and that explains a lot. I was wondering why the file size was bloating. I also had neglected to use -c:a before the libopus.

16 BITS Nunca había visto algo como esto <3

Why it is never one easy simple file to watch?
Why not a GIF?

P-aws089 said:
Why it is never one easy simple file to watch?
Why not a GIF?

It's because GIFs use a compression type that causes a poorer quality video output, if I remember that right from my computer class