[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