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.
For your comparison, are assuming that the objective is best quality, e.g. that you'd accept 10x the computation even if it gave only a 2% quality improvement?
(I can see how this could make sense, if you're encoding a file once and it will be viewed many times. But I could imagine other situations, e.g. where most files are viewed once or never, and only a few files are very popular.)
> For your comparison, are assuming that the objective is best quality, e.g. that you'd accept 10x the computation even if it gave only a 2% quality improvement?
The difference is more like 150% encoding time for half the filesize at same SSIM - depending on configuration and video type of course. And that ignores the fact that a server machine with 64-core Threadripper or equivalent can handle parallel encoding of many more videos at massively lower dollar cost than using nvenc. Especially at current GPU prices and GPU power consumption.
There's a reason why all online services are encoding in software (usually with x264 & co.) for mainstream most used profiles (that is, SD/HD, many also for 4K).
It just doesn't make sense from product quality, user experience or financial perspective. It only makes sense if you never check the results of your production.
It just doesn't make sense to save a few minutes of encoding time (a one time operation) when that costs you and users money every single time that file is streamed.
Slightly faster? Sir, I do think you are mistaken.
There are other variables go that into it such as choosing between constant or variable bitrates & variable or constant frame rate, and profiles obviously. There's a crapload of other directives that you can tweak as well.
I see what you mean though, you're right if you have CPU with lot of cores/threads/horsepower then you should use that instead of hardware-accel transcoding. I don't.
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.