[FFmpeg-devel] swscale dither

[Thomas Worth]

> Also you still use 32bit buffers all over the place for handling 10bit
> data. ffmpegs code uses 32bit buffers only when needed to maintain
> precission and 16bit otherwise. Which should make ffmpegs swscale
> twice as fast on 10bit data once its all done with SIMD :)
> I dont mind at all if it stays that way :))))
> nor do i if you reimplement or take my code as its then less work for
> me to maintain the 16/32bit buffer feature :)))))

Wouldn't 32 bit be faster since you can pack a single 10 bit R,G,B
pixel into 32 bits with padding? You're probably referring to separate
R,G,B planes, but wouldn't it be better for performance to manipulate
packed RGB rather than 16 bits for discrete R,G,B? Is there any
provision for doing it this way?