On Thu, Jan 7, 2016 at 12:44 PM, Christophe Gisquet
<christophe.gisq...@gmail.com> wrote:
> 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.
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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
