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

[Hendrik Leppkes]

On Thu, Jan 7, 2016 at 12:44 PM, Christophe Gisquet
<christophe.gisquet at gmail.com> wrote:
> 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.

This is the dumb C fallback, I prefer to err on the side of caution here.

>
> +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.

Indeed, its probably pretty simple, and I might try my hand at it
later, but so far I didn't have the motivation yet.

>
> 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.
>

Microsoft specifically described the format to alias to P016 with less
precision for simplicity, however I opted to convert to "true" 10-bit
in sws by shifting so format selection algorithms don't get confused
later, and actually treat it like 10-bit and not 16-bit.

- Hendrik