talosh
commented
2 years ago Hi Artem, RIFE works in 32fp RGB, hope that helps.
On 27 Oct 2022, at 06:44, Artem Frolov @.***> wrote:
10-bit video content is becoming more and more common with a lot of modern TVs, displays, and cameras (mobile phones or dedicated) being capable of recording or playing 10 bit video files. Populate standards like HDR10 have 10 bit video as a requirement.
Currently, RIFE doesn't support source frames with more than 8 bit pixel depth per component. It would be very useful if RIFE could read and write 10-bit frames without losing color information during the interpolation. Having 12/14/16-bit support for the future may also be useful, but supporting at least 10-bit content would be a big improvement, since such content is very common already.
rgb48le is one of the suitable pixel formats for the internal processing to support up to 16 bits (x3 components). But when Practical-RIFE receives such rgb48le frames instead of rgb24 frames from the ffmpeg-based reader, the pixel data gets truncated and corrupted back to the 8-bit format while going through the inference logic.
Would it be possible to make the inference logic compatible with 10+ bit content?
Thank you for your work on RIFE!
— Reply to this email directly, view it on GitHub https://github.com/hzwer/Practical-RIFE/issues/21, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMBGYKFUBJGY4C3OL4P5JR3WFIJEHANCNFSM6AAAAAARPVQ5BU. You are receiving this because you are subscribed to this thread.
10-bit video content is becoming more and more common with a lot of modern TVs, displays, and cameras (mobile phones or dedicated) being capable of recording or playing 10 bit video files. Popular standards like HDR10 have 10 bit video as a requirement.
Currently, RIFE doesn't support source frames with more than 8 bit pixel depth per component. It would be very useful if RIFE could read and write 10-bit frames without losing color information during the interpolation. Having 12/14/16-bit support for the future may also be useful, but supporting at least 10-bit content would be a big improvement, since such content is very common already.
rgb48leis one of the suitable pixel formats for the internal processing to support up to 16 bits (x3 components). But when Practical-RIFE receives suchrgb48leframes instead ofrgb24frames from the ffmpeg-based reader, the pixel data gets truncated and corrupted back to the 8-bit format while going through the inference logic.Would it be possible to make the inference logic compatible with 10+ bit content?
Thank you for your work on RIFE!