Hi The Pi has a use for a fast RGB24->YUV420P path for encoding camera video. There is an existing BGR24 converter but if I build a RGB24 converter using the same logic (rearrange the conversion matrix and use the same code) I get a fate fail on filter-fps-cfr (and possibly others) which appears to decode a file to RGB24, convert to YUV420P and take the CRC of that so almost any change to the conversion breaks this (unrelated?) test.
My initial assumption was that if the code to conversion in libswscale/rgb2rgb_template:bgr24toyv12_c was good enough for BGR24->YUV then it should be good enough for RGB24->YUV too. However it breaks this fate case - what is an acceptable way to resolve this? A further question assuming that the above can be resolved - I have also written aarch64 asm for this (RGB24/BGR24->YUV420P). It costs nothing in the asm to round the output values to nearest rather than just rounding down as the C template does and doing so improves the accuracy reported by tests/swscale - however at that point the asm and the C don't produce identical results. I assume that the x86 asm for BGR24 conversion does match the C. What is the best thing to do here? I've tested by hand with libswscale/test/swscale but fate integration would be obviously better - I'm currently a bit lost in fate, where/how should I do this? Many thanks John Cox _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
