https://bugs.kde.org/show_bug.cgi?id=476186
--- Comment #8 from Adam Fontenot <adam.m.fontenot+...@gmail.com> --- (In reply to Noah Davis from comment #7) > From all the reading of encoder documentation I've done in the past, 31 is > not low, it's average and actually looks decent when doing fullscreen > recording. In my own tests, there was not a significant difference in > quality between 20 CRF and 31 CRF when doing fullscreen recording either. > For me, fullscreen is 1080p@60Hz or 4K@60Hz. For some reason, recording a > smaller region has a strong negative effect on recording quality, so we may > need to scale quality with region size inversely. I think the issue is more likely to lie elsewhere. There are very few actual frames in my screencast, which is an issue not only for seeking, but also for the efficiency of the encoder. This is probably not as noticeable with full motion 24 fps or 60 fps video, but in the case of my screencast, there are only 90 actual frames in the file, because KPipeWire seems to be dropping duplicate frames rather than sending them to the encoder. In a 15.35 second clip with a nominal framerate of 60 fps, you expect to see 921 frames. So ffmpeg has only encoded 1 in 10 frames, due to the missing duplicates. The low number of frames means that the quality of the video depends on the quality of the individual frames much more. At a relatively low quality CRF like 31, the encoder is probably cheating too much on these frames. This is combined with the fact that video encoders are optimized for full motion video, not screencasts, so their quality metrics cheat heavily on flat fields (regions of nearly solid color) because they can be smoothed out and encoded at a very small size. That's clearly visible in my screencast. The recommendation for CRF 31 seems to come from Google, and I'm skeptical of their figures. They consistently underestimate bitrates needed for reasonable quality, as is readily apparent if you watch their encodes for YouTube. Interestingly, they recommend a CRF of 15 for 4K video, so VP9's CRF metric does not seem particularly consistent. For what it's worth, their example encode of "Tears of Steel" (the open source Blender film) at CRF 31 and 1080p strikes me as rather poor, and that has the advantage of being a two-pass encode. [1] I'm not trying to be overly debate-y here; there's not going to be a single one-size-fits-all value for all resolutions and all use cases. The correct approach is probably to allow setting the CRF directly in the Spectacle settings and passing the value to KPipeWire. [1] https://developers.google.com/media/vp9/settings/vod/ -- You are receiving this mail because: You are watching all bug changes.
