Hi, 2016-01-07 12:11 GMT+01:00 Hendrik Leppkes <h.lepp...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel