So I'm curious as to why this is happening. When I'm making a webm for posting on Jow Forums with ffmpeg, sometimes with the encoding with libvpx, the last several frames before looping back to the beginning artifact pretty badly where the rest of the webm is smooth and clean. Why would this be?
The arguments I use is
ffmpeg -framerate XX -start_number XX -i %04d.png -c:v libvpx -b:v 12500k -quality best -auto-alt-ref 0 name.webm
Other urls found in this thread:
libvpx is pretty broken. It doesn't offer effective bitrate control when using only a single pass. Try 2-pass encoding. That should help.
webm.py -i your_gay_shit.mp4 -vp8 -an -l 3.0 out.webm
2 pass encoding by default
-l 3.0 means I want it to be 3MB.
accepts most ffmpeg parameters (filters, time params etc.)
github.com
This sucks, it doesn't do what I want. I have a series of images I'm turning into a webm, not cropping a video.
I was trying this but I just kept getting a bunch of errors, "nothing read from output file" among one of them.
>I was trying this but I just kept getting a bunch of errors, "nothing read from output file" among one of them.
What were the exact commands you used?
Fuck, it's gone now, but it was something to the effect of
ffmpeg -y -framerate 30 -start_number 22 -i mpv_ss_%04d.png -c:v libvpx -b:v 12500k -quality best -auto-alt-ref 0 -pass 1 -f webm NUL && ^ ffmpeg -framerate 30 -start_number 22 -i mpv_ss_%04d.png -c:v libvpx -b:v 12500k -pass 2 output.webm
Exact message is "Output file is empty, nothing was encoded"
I'm honestly not sure what that command even does, a load of pngs a video file does not make. It's doing a lot of implicit shit that is weird and undebuggable without knowing the codec internals. I'd recommend throwing them into some kinda lossless format maybe before putting into webm.
>Exact message is "Output file is empty, nothing was encoded"
That's normal as your output file is indeed empty after the 1st pass. However it seems like this doesn't count as successful execution as far as the && operator is concerned. That would prevent the 2nd command from being executed.
Btw auto-alt-ref is quite useful for 2-pass encodes and you should be able to also bypass the transparency/auto-alt-ref incompatibility by forcing no transparency via -pix_fmt yuv420p.
It works as a method I've discovered for making .gif's and webm's larger without video codec upscaling, making it as close to lossless upscaling as possible in many cases, though not all.
I don't get it. Would this make the command go through?
just test it out with a -c:v libx264 -crf 0 and see if that shows the same container problems. It's almost certainly some weird timestamping issue where your file's reported video length is not matching up to the data precisely.