rwill
11th August 2026, 04:48
Hi,
in the last couple of weeks I tried to implement a software realtime HEVC encoder (realtime as in... 1080p@60fps on some small Ryzen 5600) for maybe offering an additional option for streaming boxes or the like. I am doing this for learning stuff regarding realtime software encoders etc.
So while it was easy to push over x265 in its veryfast or superfast mode quality wise I took an arrow to the knee when I compared Nvidias hardware HEVC encoder to mine on this test sequence at 4Mbit CBR with 2 seconds buffer:
https://media.xiph.org/video/derf/twitch/Uncompressed/CSGO.mov
For comparisons you can imagine x265's superfast mode to perform similar to my encoder mechanics wise. The problem zones are the HUD elements, especially the crosshair. The crosshair fades in and out, wiggles around a bit on the moving background etc. This is caused because it is perfectly in the picture center, thus being 3 pixels wide its spread over 4 CU boundaries, and not doing overlapped ME makes the encoder 'forget' about it being an important detail.
The Nvidia encoder is reproducing the HUD and crosshair almost perfectly while blurring the game field a little. I am pulling my hair out trying to come up with a theory how they might accomplish this. Maybe its something like non motion compensated MBTree thats working on individual pixel, but this would be specific to games with a HUD only and I cannot imagine them implementing something like this in their general purpose encoder.
While Nvidia wins on PSNR slightly its loosing in SSIM, so they seem to be mostly tuning for PSNR. They have more compute available but even when I do an exhaustive RD Mode Decision I cannot fix the damn crosshair and the other HUD elements....
So what are they doing?
in the last couple of weeks I tried to implement a software realtime HEVC encoder (realtime as in... 1080p@60fps on some small Ryzen 5600) for maybe offering an additional option for streaming boxes or the like. I am doing this for learning stuff regarding realtime software encoders etc.
So while it was easy to push over x265 in its veryfast or superfast mode quality wise I took an arrow to the knee when I compared Nvidias hardware HEVC encoder to mine on this test sequence at 4Mbit CBR with 2 seconds buffer:
https://media.xiph.org/video/derf/twitch/Uncompressed/CSGO.mov
For comparisons you can imagine x265's superfast mode to perform similar to my encoder mechanics wise. The problem zones are the HUD elements, especially the crosshair. The crosshair fades in and out, wiggles around a bit on the moving background etc. This is caused because it is perfectly in the picture center, thus being 3 pixels wide its spread over 4 CU boundaries, and not doing overlapped ME makes the encoder 'forget' about it being an important detail.
The Nvidia encoder is reproducing the HUD and crosshair almost perfectly while blurring the game field a little. I am pulling my hair out trying to come up with a theory how they might accomplish this. Maybe its something like non motion compensated MBTree thats working on individual pixel, but this would be specific to games with a HUD only and I cannot imagine them implementing something like this in their general purpose encoder.
While Nvidia wins on PSNR slightly its loosing in SSIM, so they seem to be mostly tuning for PSNR. They have more compute available but even when I do an exhaustive RD Mode Decision I cannot fix the damn crosshair and the other HUD elements....
So what are they doing?