On Thu, 11 Apr 2013, Diego Biurrun wrote:
---
libavcodec/x86/h264_qpel.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavcodec/x86/h264_qpel.c b/libavcodec/x86/h264_qpel.c
index f909825..2d1c443 100644
--- a/libavcodec/x86/h264_qpel.c
+++ b/libavcodec/x86/h264_qpel.c
@@ -28,17 +28,20 @@
#include "dsputil_mmx.h"
#if HAVE_YASM
-void ff_put_pixels4_mmxext(uint8_t *block, const uint8_t *pixels, int
line_size, int h);
-void ff_avg_pixels4_mmxext(uint8_t *block, const uint8_t *pixels, int
line_size, int h);
-void ff_put_pixels8_mmxext(uint8_t *block, const uint8_t *pixels, int
line_size, int h);
+void ff_put_pixels4_mmxext(uint8_t *block, const uint8_t *pixels,
+ ptrdiff_t line_size, int h);
+void ff_avg_pixels4_mmxext(uint8_t *block, const uint8_t *pixels,
+ ptrdiff_t line_size, int h);
+void ff_put_pixels8_mmxext(uint8_t *block, const uint8_t *pixels,
+ ptrdiff_t line_size, int h);
I guess this is a missed part of 25841dfe? Thus it should be ok I guess...
The same C function signature in qpel.asm should be updated as well (that
one also seems to be missed), and the movsxdifnidn could be dropped there.
But that conflicts with the hpeldsp patchset, so I'd rather postpone that
to after that patchset is in.
static void ff_put_pixels16_mmxext(uint8_t *block, const uint8_t *pixels,
- int line_size, int h)
+ ptrdiff_t line_size, int h)
{
ff_put_pixels8_mmxext(block, pixels, line_size, h);
ff_put_pixels8_mmxext(block + 8, pixels + 8, line_size, h);
}
static void ff_avg_pixels16_mmxext(uint8_t *block, const uint8_t *pixels,
- int line_size, int h)
+ ptrdiff_t line_size, int h)
{
ff_avg_pixels8_mmxext(block, pixels, line_size, h);
ff_avg_pixels8_mmxext(block + 8, pixels + 8, line_size, h);
--
1.7.9.5
These ones should be ok (but shouldn't really matter either way, since I
don't see these assigned to any function pointers anywhere).
Also, these functions shouldn't be named ff_ when they're static - a patch
fixing that after these ones would be welcome, I'll see if I can get to
that as well.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
