On Mon, Dec 8, 2008 at 12:57 AM, Adrian Ulges <[EMAIL PROTECTED]> wrote:
> ==15353== Invalid write of size 1
> ==15353==    at 0x639494F: (within /usr/lib/libswscale.so.0.5.0)
> ==15353==    by 0x638624A: sws_scale (in /usr/lib/libswscale.so.0.5.0)
> ==15353==    by 0x407AC7: iupr::VidIn::readFrame(iupr::narray<unsigned
> char>&, iupr::narray<unsigned char>&, iupr::narray<unsigned char>&)
> (vidio.cc:254)
> ==15353==    by 0x4058D1: main (fastkeyframes.cc:152)
> ==15353==  Address 0xb31fbf8 is 0 bytes after a block of size 229,440 alloc'd
> ==15353==    at 0x4C2582C: operator new[](unsigned long)
> (vg_replace_malloc.c:274)
> ==15353==    by 0x406C7B: iupr::VidIn::init() (vidio.cc:116)
> ==15353==    by 0x406CD1: iupr::VidIn::VidIn(char*) (vidio.cc:52)
> ==15353==    by 0x405870: main (fastkeyframes.cc:145)
> ...
Hi Adrian,

Just a guess, but looks like you're using new and not av_malloc() to
allocate memory.  SWScale, with MMX assembly extensions, requires
passed-in buffers to be aligned on a 128-bit boundary.  av_malloc
ensures this is always the case.  The default C++ new[] operator does
not.

If this is your issue, you have three general ways to solve (in
increasing order of difficulty):
1) disable all mmx and mmx2 (--disable-mmx --disable-mmx2) in your
ffmpeg builds; this will slow down your code A LOT on resizing though.
2) Change your code to use av_malloc/av_free for large buffers
3) Implement an overridden version of new[] on your class that ensures
any memory passed on is aligned on a 128-bit version.

Hope that helps.
- Art
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user

Reply via email to