Video encoding is weird
-
Video encoding is weird, man.
It just gets weirder and weirder. This time I ran the script overnight on a 10-minute lossless video of Portal 2 gameplay, and also tested crf values of 15 and 20 in addition to lossless (crf=0). The results are really strange in all respects.
The black bars separate the color grading - the whole left side is the same data as the right side, but the left is individual comparison and the right is comparison across both encodings at the same crf value.
Worth noting is that libx265 has visually worse quality than libx264 for the same settings (except for lossless where the quality is the same of course) so to get the same quality as libx264 crf=20, you'd want to use something like libx265 crf=15 (or a slower preset, apparently). But when you look at that exact scenario for preset=ultrafast or preset=superfast, libx265 crf=15 has a smaller size than libx264 crf=20.
From what I can tell, libx264 mostly uses the speed preset as a tradeoff between speed and compression, with slower presets resulting in smaller file sizes. On the other hand, libx265 seems to also throw quality into the mix for some reason, so slower presets result in higher quality even though the crf is supposed to determine the quality. Either way, the results are bizarre - just look at that diagonal stripe of green for libx264 on the left,
is up with that? And as with the earlier post, faster presets result in smaller file sizes for lossless libx265, which is backwards from how it's supposed to be. And no, the presets aren't reversed, faster really does take less time than slower when I sit and watch the progress, yet it also results in better compression even at lossless.If anyone understands some video encoding basics, I'd love to learn what is happening here. Otherwise I'm just going to use this table to judge all my future encoding habits. (Specifically, using veryfast for libx264 and superfast for libx265 with a slightly lower crf).
-
@lb_ said in Video encoding is weird:
the whole left side is the same data as the right side, but the left is individual comparison and the right is comparison across both encodings at the same crf value.
From a casual glance I was about to comment that this isn't true and there's something wrong with the data, since I can't find the weird green stripe on the right hand side. But that's just an artefact of the color mappings being different, the data is the same.
Looks really weird, apparently crf is not the only factor determining quality for x265.
-
I found a thread where people seem to be just as confused as me:
Why does x265 preset fast get the smallest file size by const. quality?
I tried many videos to test with x265. I set crf to 23.0 and found preset fast always get the smallest files than other presets. Why do slow, slower or
The main takeaway seems to be that CRF is not an absolute measurement of quality, and that libx265 instead cheats by upping the bitrate at slower presets. Still doesn't explain the lossless results, though.
It doesn't seem to be possible to adjust compression ratio without also adjusting quality. I really wonder if this was the original intention behind libx265 or not, because it's really confusing to have two different ways to adjust the quality. Supposedly libx264 is guilty too, but I really can't tell if so.
-
@lb_ said in Video encoding is weird:
so slower presets result in higher quality even though the crf is supposed to determine the quality.
How much does the quality vary? Have you compared the videos via some standard measure (SSIM or something)? I'd be curious to what that spits out.
Some differences are to be expected, I guess, since the presets also change the type of encodings that are used/attempted. Besides, it sounds like CRF would use some sort of heuristic measure anyway, since it has to determine the image quality somehow. Either way, completely separating image quality from the performance presets seems impossible.
Then again, that the faster presets result in much better compression seems a bit fishy. I'd ask again about the quality, but then you mention that you see this even with running lossless.
If anyone understands some video encoding basics, I'd love to learn what is happening here.
Have you checked what the underlying options that the presets select actually do?
The other question would be how the presets were selected. Probably somebody has(*) a set of test videos for which the performance+quality of the various presets was tested and the parameters were adjusted based on. But if the test videos are very different (in content, but perhaps also in stuff like resolution), the presets may not really carry over to your type of videos that well. (A somewhat oversimplified comparison would be jpg vs png. The former works really well [with sane settings] for photography, whereas it's not very good for computer generated images with fine details like text.)
(*) Or ... perhaps rather "had", that is, they determined the presets at some point during development and then never revisited them... It's been known to happen.
