.. I succesfully encode a h264 frame, but it segfaults with a back trace ..
Summary: Num frames encoded = 1 Encoding Time = 0.04 sec, 23.68 fps Overall Time = 0.04 sec, 22.77 fps Average CPU usage = 0.00% Encoded Size = 31245 bytes Compression Ratio = 14.75 EncodedSize/ExpectedSize = 74.99 *** glibc detected *** ./umc_video_enc_con: double free or corruption (!prev): 0x09fcf5f0 ***
In the Mafile in ipp-samples/audio-video-codecs I added -ggdb to CFLAGS, ran the above line again with coredumps enabled and my stack trace is
#0 0x0063e416 in __kernel_vsyscall () #1 0x00249460 in raise () from /lib/libc.so.6 #2 0x0024ae28 in abort () from /lib/libc.so.6 #3 0x00286fed in __libc_message () from /lib/libc.so.6 #4 0x0028d3a4 in malloc_printerr () from /lib/libc.so.6 #5 0x0028f356 in free () from /lib/libc.so.6 #6 0x00f6aa85 in ippFree () from /opt/intel/composerxe/ipp/lib/ia32/libippcore.so.7.0 #7 0x08d155f0 in ?? () #8 0x00000002 in ?? () #9 0x081381c3 in UMC_H264_ENCODER::H264CoreEncoder_Close_8u16s (state=0x0) at ./include/umc_h264_gen_enc_tmpl.cpp.h:2086
I see in the bug fixes (http://software.intel.com/en-us/articles/intel-ipp-70-library-bug-fixes/) that a similar issue was recently fixed ..
IPP v7.0 update 2 (20 Jan 2011) .. "Fixed crash with double memory free in h264 encoder when calling core encode destructor after Close() method."
.. however I'd assume that the version of the samples I have (ipp-samples_p_7.0.3.040) would contain this update 2 fix.
In case this is related, I didn't seem to get IPPROOT setup correctly. Each time I ran the app it ended up not finding a library in another directory path, so to get the binary running at all I set LD_LIBRARY_PATH to
It should be not direct result. I doubt there is conflict when use Intel OpenMP and GNU openMP. So disable it.Do you have chance to try intel C++ compiler to build the sample?, it seems works fine with the 1 frame encoding.