I have chosen the mp4 container because of how widely supported it is. To prevent users having to fetch whole files, i use the fast start option, where the container's metadata is written at the beginning of the file, instead of at the end.
Next, I have picked h264 codec because of how widely supported it is. VP8/VP9/AV1/x265/x266 are certainly better but the h264 software encoding is often beating hardware encoding due to highly optimized and time-proven code and supported hardware. And the uploaded videos are already compressed, users won't be uploading some 8k raw videos where most advanced codes would be useful for preserving "quality".
For audio, i have picked opus codec. Seems like good value over others. Not much else to add.
I run the ffmpeg to convert video with command like this:
ffmpeg -hide_banner -loglevel error -i input.mp4 -g 52 -c:v h264 -maxrate:v vbr -bufsize vbr -s HxW -c:a libopus -af aformat=channel_layouts=7.1|5.1|stereo -maxrate:a abr -ar 48000 -ac 2 -f mp4 -movflags faststart -map 0:v:0 -map 0:a:0 output.mp4
where vbr is video bitrate like 1024k(1mbps), abr is audio bitrate like 190k and HxW is video dimensions in case of resizing.
I wonder how are folks that handle video encoding process and generate their videos?
How did you pick your settings, what issues have you encountered and any tips you can share are certainly appreciated.
Quite a niche segment when it comes to operations and not being merely consumer/customer.
My ffmpeg how-to/examples/scratchfile can be viewed here: https://paste.travisflix.com/?ce12a91f222cc3d7#BQPKtw6sEs9cE...
They're made to be realtime, but for any kind of delayed playback where there's time to encode, software encoders win without any kind of effort. For web delivery especially, hw encoders have no business being used because quality per expended bandwidth is paramount and costs money.
The hardware encoders are designed to be fast (at least realtime), small (in component count) and power efficient so they usually don't have the ability to do extensive searches for similarities in frames to really squeeze out the best compression. Pretty much all of them are also largely fixed in supported operations during encode so you can't really implement better algorithms with software updates on them.
Making them better would mean growing their (sillicon) size which would make the graphics cards more expensive to produce and take space away from actual GPU cores. Most customers don't buy a GeForce for its video encoder. And once you'd grow them enough, you'd get something similar to a CPU anyway.
And this is how we get back full circle - even enterprise "encoder-in-a-box" providers have lately gone from boxes with ASICs in them to essentially seling proprietary servers with normal CPUs and proprietary OS on them. With the current prices of 64-core+ CPUs, it just doesn't make much sense to design ASICs and HW encoding blocks for these types of encodes.
Realtime encoding is, of course, another game.