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.
>just test it out with a -c:v libx264 -crf 0
In the second pass section and on it's own with no others?
just on its own from the pngs not related to other guy's attempts at 2pass (which is always a good idea)
I'm confused. The command is very convoluted now. Without the second pass option, the command runs fine and I get an output, so if you're saying it's something going on in the first pass step, I don't think it's that.
ffmpeg -framerate XX -start_number XX -i %04d.png -c:v libx264 -crf 0 name.mp4
>It works as a method I've discovered for making .gif's and webm's larger without video codec upscaling
The video codec doesn't have anything to do with upscaling. ffmpeg applies the upscaling filter on the decoded footage and then encodes the output. Also I fail to see the benefit, unless we're talking upscaling via tools like waifu2x, especially when you're going to fuck the quality anyway by encoding as VP8.
>I don't get it. Would this make the command go through?
Try executing the commands separately, without combining them with the && operator.
-pix_fmt yuv420p will not fix your current problem. I assumed you were (rightfully) using -auto-alt-ref 0, because of a libvpx bug that prevents input with an alpha channel from getting encoded, unless you explicitly disable the alternate reference frame.
Ok, so that worked.
>Also I fail to see the benefit, unless we're talking upscaling via tools like waifu2x, especially when you're going to fuck the quality anyway by encoding as VP8.
That's exactly what I'm doing, and it's for 2d stuff only. The effect and loss of quality is so minimal even with the encoding that there is no perceptible difference when in motion. And it has to be VP8 anyways because all this shit site supports.
Gimme a sec on that second part.
just see if the mp4 has the artifacts you got from the webm, if not convert the mp4 to webm instead of pngs.
>Gimme a sec on that second part.
Ok, so it did seem to go through now as separate commands. However it's too big to post now. It fixed the artifacting, so it's a sacrifice.
It suffered the same problem I originally had. Postable size now, but still the same artifacting at the very end only.
I meant the mp4 conversion to webm. The mp4 was flawless.
Looks good.
I'm hijacking this thread.
Do the structured blue and red stripes that appears at the start look like artifacting, or is it more likely something the video creator put there?
Oh and unless you couldn't tell, colors are cranked to max.
try and beat this webm quality/size
there's not a lot of movement in there, so that's cheating. Do the same for something with shit flying all across the screen.
>use single image
>loop at 1fps
Nothing beats that.