Use nv15 as intermediate format for 2-pass rkrga scaling #13313
Conversation
It seems like RKRGA is expecting no zero padding bits during 2 pass scaling which distorts P010 frames after scale. This breaks trickplay image generation for HDR videos. Workaround this by specifying nv15 frame format. This might cause issues with other ffmpeg implementations, as NV15 is not supported everywhere. However, rockchip users should use jellyfin-ffmpeg for proper hardware acceleration anyway.
The trailing columns of pixels will get distorted for frames not having a divisible by 4 width.
|
RGA3 does support nv15 and p010 inputs, but there is a kernel issue that needs to be fixed via a patch. Most common distros include it. Without it RGA3 will treat p010 as nv15. armbian/linux-rockchip@03384d1 https://github.com/search?q=repo%3Aarmbian%2Flinux-rockchip+nyanmisaka&type=commits) |
Now the million dollar question: how can we tell from the server? Because most if not all kernels shipped by board vendors are affected and buggy and those are the kernels being used most. |
Just memcmp one rawvideo frame of p010 testsrc with the p010->p010 output after the rkrga filter. Their checksums are the same when there is no glitches. |
Use nv15 as intermediate format for 2-pass rkrga scaling Original-merge: 5c6317f Merged-by: crobibero <cody@robibe.ro> Backported-by: Bond_009 <bond.009@outlook.com>
It seems like RKRGA is expecting no zero padding bits during 2 pass scaling which distorts P010 frames after scale. This breaks trickplay image generation for HDR videos. Workaround this by specifying nv15 frame format.
This might cause issues with other ffmpeg implementations, as NV15 is not supported everywhere. However, rockchip users should use jellyfin-ffmpeg for proper hardware acceleration anyway.
Changes
Issues
Fixes this:
