On Mon, Jun 06, 2011 at 12:12:00PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Jun 6, 2011 at 12:04 PM, Diego Biurrun <[email protected]> wrote:
> > On Mon, Jun 06, 2011 at 11:45:38AM -0400, Ronald S. Bultje wrote:
> >> ---
> >>  libswscale/swscale.c          |  201 
> >> ++++++++++++++++-------------------------
> >>  libswscale/swscale_internal.h |    4 -
> >>  2 files changed, 76 insertions(+), 129 deletions(-)
> >
> > A bit of explanation why you do this and why you can do this would
> > be welcome.
> 
> How about:
> 
> "these are hacks added so you can use functions for multiple purposes.
> E.g. Say you have the following: YUYV, or UYVY, setting offset += 1
> means you can use the same function to read both.
> 
> Unfortunately, that only works if alignment of the address is of no
> concern, and breaks even further if you set multiple function pointers
> in different places. Imaging the C function setting a YUYV reader for
> UYVY with offset=1, and then an optimized simd reader (optimized for
> unaligned access also) sets it back toa  UYVY reader, then it
> completely and utterly breaks.
> 
> This is mostly used for alpha or BE vs LE 16 bit reading, where the
> benefit disappears as soon as you want to maintain full-bitdepth
> precision (which is what I'm working on), so let's just remove it."
> 
> Wanna summarize that? :).

They are hacks added to use functions for multiple purposes, e.g. if you have
YUYV or UYVY, setting offset += 1 means the same function can read both.

Unfortunately, that only works if alignment of the address is of no concern,
and breaks even further if you set multiple function pointers in different
places. Imagine the C function setting a YUYV reader for UYVY with offset=1,
and then an optimized SIMD reader (optimized for unaligned access also) sets
it back to a UYVY reader. It will completely and utterly break.

The hacks are mostly used for alpha or BE vs LE 16-bit reading, where the
benefit disappears as soon as you want to maintain full-bitdepth precision.
As this is being worked on right now, it is better to just remove the hacks.

Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to