[FFmpeg-devel] [PATCH 2/2] swscale: add P010 input support

Christophe Gisquet christophe.gisquet at gmail.com
Thu Jan 7 12:44:44 CET 2016


Hi,

2016-01-07 12:11 GMT+01:00 Hendrik Leppkes <h.leppkes at gmail.com>:
> +static void p010LEToY_c(uint8_t *dst, const uint8_t *src, const uint8_t *unused1,
> +                        const uint8_t *unused2, int width, uint32_t *unused)
> +{
> +    int i;
> +    for (i = 0; i < width; i++) {
> +        AV_WN16(dst + i * 2, AV_RL16(src + i * 2) >> 6);
> +    }
> +}

Seeing log2_chroma_[wh], this is 4:2:0, so the above loop could be
unrolled, as it specifically refers to P010 and width should be even.
But maybe it has to handle those weird cases where it is odd, I don't
know.

+static void p010LEToUV_c(uint8_t *dstU, uint8_t *dstV,
+                       const uint8_t *unused0, const uint8_t *src1,
const uint8_t *src2,
+                       int width, uint32_t *unused)
+{
+    int i;
+    for (i = 0; i < width; i++) {
+        AV_WN16(dstU + i * 2, AV_RL16(src1 + i * 4 + 0) >> 6);
+        AV_WN16(dstV + i * 2, AV_RL16(src1 + i * 4 + 2) >> 6);

I could see an AV_RL32 being used here, but it's probably not worth your time.

Also, all those conversion functions are very easily SIMD-able for
those that want to try their hand.

Last thing unrelated to the code: do you have any idea why that shift?
An obvious reason would be no-op conversion to P016, but extra work
for a lot of other stuff.

-- 
Christophe


More information about the ffmpeg-devel mailing list