rerendered from the mp4 off inkbunny to match the quality of the original file. the old one loses half the frames this one keep it at 60fps from the original mp4.

For spits and giggles I took the original source and did a two-pass ffmpeg transcode at crf12, I got a 30MB file, as opposed to this 92MB file. For some reason ffmpeg ended up darkening the colors of the final product slightly, and I can't be arsed to try to figure out why.

If anyone is curious to play with this, here's the commands I used

ffmpeg -i 4513147_Sfan_chip_and_gadget_buzya_1.mp4 -c:a libopus -b:a 128k -c:v vp9 -crf 12 -b:v 0 -pass 1 -f null NUL
ffmpeg -i 4513147_Sfan_chip_and_gadget_buzya_1.mp4 -c:a libopus -b:a 128k -c:v vp9 -crf 12 -b:v 0 -pass 2 -row-mt 1 gadget-buzya-crf12.webm

catchoftheday said:
rerendered from the mp4 off inkbunny to match the quality of the original file. the old one loses half the frames this one keep it at 60fps from the original mp4.

We are now at the point where I would highly suggest people like you, ask for replacement beta access from admin to replace exsisting post.
Also thank you for being one of those who see these kind of things, because sometimes I feel like I'm the only one.

tredfg543 said:
For spits and giggles I took the original source and did a two-pass ffmpeg transcode at crf12, I got a 30MB file, as opposed to this 92MB file. For some reason ffmpeg ended up darkening the colors of the final product slightly, and I can't be arsed to try to figure out why.

If anyone is curious to play with this, here's the commands I used

ffmpeg -i 4513147_Sfan_chip_and_gadget_buzya_1.mp4 -c:a libopus -b:a 128k -c:v vp9 -crf 12 -b:v 0 -pass 1 -f null NUL
ffmpeg -i 4513147_Sfan_chip_and_gadget_buzya_1.mp4 -c:a libopus -b:a 128k -c:v vp9 -crf 12 -b:v 0 -pass 2 -row-mt 1 gadget-buzya-crf12.webm

I do agree on notion that CRF 12 is super high quality target, but even for me, if source is that much higher bitrate, I would sometimes go lower even down to 8, just to brute force the quality to be as close to source as possible.
However in this case, the source is most likely overshooting to ridiculous degree that even CRF 12 would be basically identical.

Color stuff, I have mostly given up on, because they make absolutely no sense to me most of the time and even when I try to properly search for it, the blogs and forums I find are mostly "well, I did this thing and now it magically works" level of nonsense.
One thing I have noticed is that FFmpeg and many others do not do colorspace conversion properly most of the time, so you need to use filters for those, but then additionally the colorspace might not be what you wanted so you need to additionally tell it to use the colorspace you want and are using the filter for.
At least with FFmpeg it tries to match output to input unless nothing is specified, which with color stuff should be what you want 99% of the time and basically always if you have YUV420 source and YUV420 output.

One thing your command is missing at least is audio quality/bitrate, Opus I think at least used to default to 96kbps which is technically fine for stereo audio streaming, but if you have the bitrate, 160kbps is what youtube also uses for highest quality audio and it's above 128kbps that's with Opus is transparent/audibly lossless. Source audio is 317kbps AAC so it's still higher quality from even that.
Even if 96kbps was fine, please don't leave crusial settings to default. The default for videos without any settings applied was constant bitrate of 1mbps. That's not great for majority of things.

mairo said:

One thing your command is missing at least is audio quality/bitrate, Opus I think at least used to default to 96kbps which is technically fine for stereo audio streaming, .......

The -b:a 128k tells the audio codec to aim for 128kbit. There's a reason I put that right next to the -c:a libopus statement

mairo said:
We are now at the point where I would highly suggest people like you, ask for replacement beta access from admin to replace exsisting post.
Also thank you for being one of those who see these kind of things, because sometimes I feel like I'm the only one.

I do agree on notion that CRF 12 is super high quality target, but even for me, if source is that much higher bitrate, I would sometimes go lower even down to 8, just to brute force the quality to be as close to source as possible.
However in this case, the source is most likely overshooting to ridiculous degree that even CRF 12 would be basically identical.

Color stuff, I have mostly given up on, because they make absolutely no sense to me most of the time and even when I try to properly search for it, the blogs and forums I find are mostly "well, I did this thing and now it magically works" level of nonsense.
One thing I have noticed is that FFmpeg and many others do not do colorspace conversion properly most of the time, so you need to use filters for those, but then additionally the colorspace might not be what you wanted so you need to additionally tell it to use the colorspace you want and are using the filter for.
At least with FFmpeg it tries to match output to input unless nothing is specified, which with color stuff should be what you want 99% of the time and basically always if you have YUV420 source and YUV420 output.

One thing your command is missing at least is audio quality/bitrate, Opus I think at least used to default to 96kbps which is technically fine for stereo audio streaming, but if you have the bitrate, 160kbps is what youtube also uses for highest quality audio and it's above 128kbps that's with Opus is transparent/audibly lossless. Source audio is 317kbps AAC so it's still higher quality from even that.
Even if 96kbps was fine, please don't leave crusial settings to default. The default for videos without any settings applied was constant bitrate of 1mbps. That's not great for majority of things.

tredfg543 said:
For spits and giggles I took the original source and did a two-pass ffmpeg transcode at crf12, I got a 30MB file, as opposed to this 92MB file. For some reason ffmpeg ended up darkening the colors of the final product slightly, and I can't be arsed to try to figure out why.

If anyone is curious to play with this, here's the commands I used

ffmpeg -i 4513147_Sfan_chip_and_gadget_buzya_1.mp4 -c:a libopus -b:a 128k -c:v vp9 -crf 12 -b:v 0 -pass 1 -f null NUL
ffmpeg -i 4513147_Sfan_chip_and_gadget_buzya_1.mp4 -c:a libopus -b:a 128k -c:v vp9 -crf 12 -b:v 0 -pass 2 -row-mt 1 gadget-buzya-crf12.webm

this is a vp9 codec which is more efficient than h.264. i could have done a more efficient render and ended up with the same quality but i decided it was best to keep the file as original looking as possible. i didnt want to look like i was posting a inferior file since not every person knows how video rendering works. this is how i do all my renders for this site.

mairo said:
We are now at the point where I would highly suggest people like you, ask for replacement beta access from admin to replace exsisting post.
Also thank you for being one of those who see these kind of things, because sometimes I feel like I'm the only one.

i actually do have replacements beta already but the one time i tried it for a video it ended up getting denied so i just did it the old fashion way. and thank you!

This is AMAZING work! You'd swear that it had actually come right out of "House of Mouse" studios.

What a unique and totally understandable comment section

That arm aint right

tredfg543 said:
The -b:a 128k tells the audio codec to aim for 128kbit. There's a reason I put that right next to the -c:a libopus statement

...I should not write comments while half asleep...or at least test the commands and see there's no errors around this. Regardless I would make it much higher considering the source quality and leeway on bitrate, but at least 128kbps should be fine (also I'm not audiophile, so with audio I have harder time hearing stuff but I have had people complain how things sound worse at 96kbps compared to source).
Codecs default to VP9 and Opus with most recent builds so that is fine.

catchoftheday said:
i actually do have replacements beta already but the one time i tried it for a video it ended up getting denied so i just did it the old fashion way. and thank you!

With post #330879, you were replacing GIF with WebM.

Site accepts multiple differend fileformats for animations, so in this kind of instance we could approve Flash SWF, GIF, WebM and APNG, at which point replacing GIF is not correct.
Additionally it seems there was still interactive elements visible on the WebM conversion, so it didn't meet guideline requirements and could be treated as screencap instead of conversion.

This is one reason why replacements are still in beta, as we do not have e.g. place to provide rejection reason like we do on posts.

mairo said:
...I should not write comments while half asleep...or at least test the commands and see there's no errors around this. Regardless I would make it much higher considering the source quality and leeway on bitrate, but at least 128kbps should be fine (also I'm not audiophile, so with audio I have harder time hearing stuff but I have had people complain how things sound worse at 96kbps compared to source).
Codecs default to VP9 and Opus with most recent builds so that is fine.

With post #330879, you were replacing GIF with WebM.

Site accepts multiple differend fileformats for animations, so in this kind of instance we could approve Flash SWF, GIF, WebM and APNG, at which point replacing GIF is not correct.
Additionally it seems there was still interactive elements visible on the WebM conversion, so it didn't meet guideline requirements and could be treated as screencap instead of conversion.

This is one reason why replacements are still in beta, as we do not have e.g. place to provide rejection reason like we do on posts.

ah ok got it. i actually didnt know that reguarding the interactive elements id upload the swf if i could but those are dead. i could de compile the swf and remove those elements though. thanks for the tip.

It's nice to see on-model stuff.