On 6/7/11 3:37 AM, Kostya wrote:
On Tue, Jun 07, 2011 at 10:20:25AM +0200, Diego Biurrun wrote:
On Mon, Jun 06, 2011 at 03:58:43PM -0400, Ronald S. Bultje wrote:
Hi,
On Mon, Jun 6, 2011 at 1:04 PM, Diego Biurrun<[email protected]> wrote:
On Mon, Jun 06, 2011 at 12:12:00PM -0400, Ronald S. Bultje wrote:
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.
Too long.
I don't see how a log message could be too long at barely a dozen lines, but
here goes:
[...]
My attempt:
swscale: Remove alp/chr/lumSrcOffset.
They are hacks added to reuse the same scaling function for different formats
and they may cause problems when SIMD implementation of the same functions are
used along with pure C functions.
I like kostya's better =)
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
