[issue1800] SWScale, memory allocation problem resulting in crash.
New submission from Pavel i-love-s...@yandex.ru: I was comparing results of different algorithms and noticed that after some amount of time I got crashes inside swscale function. I tried to debug it and the reason for that appears that VirtualAlloc returns NULL inside: c-chrMmx2FilterCode = VirtualAlloc(NULL, c-chrMmx2FilterCodeSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE); [c-chrMmx2FilterCode is NULL, @err is 8, not enough memory] strangely, I didn't have any memory problems at all (a couple of gigs free)! But I noticed that after a few minutes of running tests at 100%cpu my app would take like 150MB of ram (same size for virtual memory). I tried to debug, and it appears that both VirtualFree calls inside sws_freeContext always fail. VirtualFree(c-lumMmx2FilterCode, c-lumMmx2FilterCodeSize, MEM_RELEASE); // @err=87 ERROR_INVALID_PARAMETER VirtualFree(c-chrMmx2FilterCode, c-chrMmx2FilterCodeSize, MEM_RELEASE); From MSDN: If the dwFreeType parameter is MEM_RELEASE, this parameter must be 0 (zero) Therefore, it has to be changed to: VirtualFree(c-lumMmx2FilterCode, 0, MEM_RELEASE); VirtualFree(c-chrMmx2FilterCode, 0, MEM_RELEASE); Also, there must be some code to handle case when virtualalloc returns 0 so that entire app wouldn't crash because of that (in my case I'm just using it for stretching simple images and I don't care what happens, but I don't need any aborts,coredumps etc, in case of some problem it simply shouldn't do anything. -- messages: 9685 priority: normal status: new substatus: new title: SWScale, memory allocation problem resulting in crash. type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1800
[issue1800] SWScale, memory allocation problem resulting in crash.
Pavel i-love-s...@yandex.ru added the comment: Fixed by Reimar in rev. 30863 30864 -- status: new - closed substatus: new - fixed FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1800
[issue1976] Memory leaks from av_interleaved_write_frame
New submission from Pavel i-love-s...@yandex.ru: I don't know if some underlying code was changes, but since my last update to ffmpeg's svn I started to get leaks in different places in code that previously was leak free. I traced the problem thinking that there some new code added in ffmpeg and I had to add some extra cleanup on closing output context. I couldn't find any problem in my code and the only way to fix that was to add flush_packet_queue(ptrAVFormatContext); just the same way as av_close_input_stream does. But I'm using AVFormatContext for output of flv streams and it doesn't none of the functions would free up the AVPacketList queue. -- messages: 10665 priority: normal status: new substatus: new title: Memory leaks from av_interleaved_write_frame type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1976
[issue1976] Memory leaks from av_interleaved_write_frame
Pavel i-love-s...@yandex.ru added the comment: I don't know if some underlying code was changes, but since my last update to ffmpeg's svn I started to get leaks in different places in code that previously was leak free. I traced the problem thinking that there some new code added in ffmpeg and I had to add some extra cleanup on closing output context. I couldn't find any problem in my code and the only way to fix that was to add flush_packet_queue(ptrAVFormatContext); just the same way as av_close_input_stream does. But I'm using AVFormatContext for output of flv streams and none of the functions would free up the AVPacketList queue. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1976
[issue2113] SWScale, does not convert from YUV444 to RGB565
New submission from Pavel i-love-s...@yandex.ru: I use ffmpeg to load images. At some point I noticed that some of them show as random colorful pixel or just plain black. I tried to see what's wrong and ... everything was ok! So, I had to debug the code to find out what was wrong. It appears that sws_scale cannot convert from YUV444 to RGB565 and it silently returns height (which indicates success). I tried to run in debug and it asserts at the end of yuv2rgbXinC_full. At the same time, sws_getContext has to fail if sws_scale cannot do its job. The original image was 1.5M jpeg file. The attached image is the thumbnail generated with ffmpeg. Both have that problem when loading into rgb565 surface. -- files: 121652-pavel1.jpg messages: 11263 priority: normal status: new substatus: new title: SWScale, does not convert from YUV444 to RGB565 type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113 attachment: 121652-pavel1.jpg
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: I don't get it... I always get asked this same question. I think it was quite clear that I'm using libswscale directly. I don't know how to use ffmpeg, but if you know how to convert input image into RGB565 bitmap, then you can easily reproduce it with ffmpeg cli. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: What command line do you use to make that test which works for you??.. The reason it works for you is probably because PC has optimized code to do the conversion. I get that error on mobile when loading images (arm cpu). FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: To reproduce that error with ffmpeg cli, you need the following params ffmpeg attachedimage.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int (swscale full_chroma_int is the one required parameter for hq pics, otherwise high quality pics will look bad). The other catch is that if you have avfilter compiled in then you don't get that error. I don't know what avfilter does and how it works, but the problem only happens with regular libswscale when converting from yuv444 to rgb565 with SWS_FULL_CHR_H_INT. And the only way to reproduce it with ffmpeg cli it to compile without avfilt support, or simply do it in c code directly. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: To reproduce that error with ffmpeg cli, you need the following params ffmpeg attachedimage.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int (swscale full_chroma_int is the one required parameter for hq pics, otherwise high quality pics will look bad). The other catch is that if you have avfilter compiled in then you don't get that error. I don't know what avfilter does and how it works, but the problem only happens with regular libswscale when converting from yuv444 to rgb565 with SWS_FULL_CHR_H_INT. And the only way to reproduce it with ffmpeg cli it to compile without avfilt support, or simply do it in c code directly. -- status: closed - open FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: There is no output. It asserts without any messages (in debug build it doesn't show everything below Stream mapping). In release build here's the output (no need to comment about unsupported compiler, simply check if you get the same results with realse ffmpeg compiled without avfilt. Attached is the results of release build): \ffmpeg\binffmpeg -i img.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int FFmpeg version SVN-r20069, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 20 2010 05:08:31 with icl 1110 configuration: icl v.1110 build libavutil 50.22. 0 / 50.22. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.75. 0 / 52.75. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0.11. 0 / 0.11. 0 Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding frame=1 fps= 0 q=0.0 Lsize= -0kB time=0.04 bitrate= -4.4kbits/s video:14kB audio:0kB global headers:0kB muxing overhead -100.153610% FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2113] SWScale, does not convert from YUV444 to RGB565
Pavel i-love-s...@yandex.ru added the comment: There is no output. It asserts without any messages (in debug build it doesn't show everything below Stream mapping). In release build here's the output (no need to comment about unsupported compiler, simply check if you get the same results with realse ffmpeg compiled without avfilt. Attached is the results of release build): \ffmpeg\binffmpeg -i img.jpg -f image2 -vcodec bmp -pix_fmt rgb565 img565.bmp -sws_flags bilinear+full_chroma_int FFmpeg version SVN-r20069, Copyright (c) 2000-2010 the FFmpeg developers built on Jul 20 2010 05:08:31 with icl 1110 configuration: icl v.1110 build libavutil 50.22. 0 / 50.22. 0 libavcodec52.84. 0 / 52.84. 0 libavformat 52.75. 0 / 52.75. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0.11. 0 / 0.11. 0 Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding frame=1 fps= 0 q=0.0 Lsize= -0kB time=0.04 bitrate= -4.4kbits/s video:14kB audio:0kB global headers:0kB muxing overhead -100.153610% FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113 attachment: img565.bmp
[issue2117] MJPEG decoder crash
New submission from Pavel i-love-s...@yandex.ru:
Some damaged pictures crash MJPEG decoder from ffmpeg.
Latest svn (july 21) crashes. Output doesn't have any messages.
ffmpeg -i 1279729383-BLUE01.jpg -f image2 -vcodec bmp out.bmp
crashes inside
/* decode block and dequantize */
static int decode_block(MJpegDecodeContext *s, DCTELEM *block,
...
for(;;) {
UPDATE_CACHE(re, s-gb); // -- here
GET_VLC(code, re, s-gb, s-vlcs[1][ac_index].table, 9, 2)
File '1279729383-BLUE01.jpg' not attached - you can download it from
https://roundup.ffmpeg.org/file992.
--
files: 1279729383-BLUE01.jpg
messages: 11326
priority: normal
status: new
substatus: new
title: MJPEG decoder crash
type: bug
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2117
[issue2118] BUG tracker is unusably TOO slow.
New submission from Pavel i-love-s...@yandex.ru: reproducible with current svn of ffmpeg cli. Does the bug tracker try to fix the bugs itself and that's why the web interface is extremely unresponsive. Or is it to prevent some bug reporters from filling their reports (that one the other way to fix bugs as well) ... -- messages: 11329 priority: normal status: new substatus: new title: BUG tracker is unusably TOO slow. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2118
[issue2117] MJPEG decoder crash
Pavel i-love-s...@yandex.ru added the comment: The reason it crashes is because the bitreader reads way past the end of GetBitContext buffer. As a workaround for my case I made a temporary patch like this: GET_VLC(code, re, s-gb, s-vlcs[1][ac_index].table, 9, 2) if(s-gb.buffer + (re_index3) s-gb.buffer_end) return -1; The problem is that this test isn't appropriate for this place for performance reason I think. I put a static variable to see how many time that code gets executed and it runs like 3.5M times for the attached image. There must be some proper test before that to see if there is enough data can be read, or the bitreader somehow should allocate bigger buffer with zeros so that at least the reader won't read past the end. I tried to debug, and I don't know where to put proper test to se FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2117
[issue2113] SWScale output junk converting YUV444 - RGB565 using bilinear+full_chroma_int
Pavel i-love-s...@yandex.ru added the comment: just a side note about my experience about libswscale and libavcodec. avcodec has arm optimizations for encoders/decoders but swscale destroys it all if libavcodec+libswscale used to decode/convert/scale pictures on mobile devices: colorspace conversion or scaling takes way more cpu than video decoding. I think at some point there was a message by Siarhei Siamashka and his patch had jit optimized version of most common csp conversion routines for mobiles (probably i420/yv12-r565). His code had identical interface to swscale api. I believe it's now part vlc distribution. Ok, I just found it, it is here: http://bit.ly/9FFz65 It appears to be swscale-like scaler for yuv images, no csp though. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2113
[issue2126] AVFORMAT leaks 1KB for every missing file.
Pavel i-love-s...@yandex.ru added the comment: free allocated context on failure -- type: - patch FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126 libavformat_leak_file_not_exist.diff Description: Binary data
[issue2126] AVFORMAT leaks 1KB for every missing file.
Pavel i-love-s...@yandex.ru added the comment: I use: int ret = av_open_input_file(format_ctx, invalidfile.png, NULL, 0, NULL); if invalidfile.png doesn't exist, then on return format_ctx is 0 and ret contains a error return (-2). At this point, I can't do anything anymore. The only way to fix it was to free context on error. I don't know internals of avio, but the next line after my patch, there is av_free(st); after that st-codec is leaked, so I addredd free just before that. valgrind ffmpeg_g -i /tmp/unexisting_file /tmp/out.avi : It doesn't necessarily use the same way to open files, and may go some other code path. I can't comment on ffmpeg cli FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2126
[issue2235] PNG decoder doesn't handle properly some png formats
New submission from Pavel i-love-s...@yandex.ru: decoded picture looks wrong. Also, if palette-based png is used, there is no way (or api in libavcodec) to specify what color for transparent (key color) should be used: It fills it with black instead. ...ffmpeg-r25128.exe -v 9 -loglevel 99 -i default.png -f image2 -vcodec bmp -pix_fmt rg b24 default.bmp FFmpeg version SVN-r25128, Copyright (c) 2000-2010 the FFmpeg developers built on Sep 16 2010 04:13:19 with gcc 4.4.2 configuration: --enable-gpl --enable-version3 --enable-libgsm --enable-pthreads --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libopencore_amrwb --enable- libopencore_amrnb --enable-libvpx --arch=x86 --enable-runtime-cpudetect --enable-libxvid --enable-libx264 --extra-libs=' -lx264 -lpthread' --enable-librtmp --extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --target-os=mingw32 --enable-avisyn th --cross-prefix=i686-mingw32- --cc='ccache i686-mingw32-gcc' --enable-memalign-hack libavutil 50.27. 0 / 50.27. 0 libavcore 0. 9. 0 / 0. 9. 0 libavcodec52.89. 0 / 52.89. 0 libavformat 52.78. 5 / 52.78. 5 libavdevice 52. 2. 2 / 52. 2. 2 libavfilter1.39. 0 / 1.39. 0 libswscale 0.11. 0 / 0.11. 0 Input #0, image2, from 'default.png': Duration: 00:00:00.04, start: 0.00, bitrate: N/A Stream #0.0, 1, 1/25: Video: png, pal8, 256x256, 1/25, 25 tbr, 25 tbn, 25 tbc [buffer @ 00332d30] w:256 h:256 pixfmt:pal8 [ffmpeg_output @ 0033fe90] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out' [scale @ 01778740] w:256 h:256 fmt:pal8 - w:256 h:256 fmt:bgr24 flags:0x4 Output #0, image2, to 'default.bmp': Metadata: encoder : Lavf52.78.5 Stream #0.0, 0, 1/9: Video: bmp, bgr24, 256x256, 1/25, q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0.0 - #0.0 Press [q] to stop encoding frame=1 fps= 0 q=0.0 Lsize= -0kB time=0.04 bitrate= -4.4kbits/s video:192kB audio:0kB global headers:0kB muxing overhead -100.011187% -- files: default.png messages: 11948 priority: normal status: new substatus: new title: PNG decoder doesn't handle properly some png formats type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2235 attachment: default.png
[issue2235] PNG decoder doesn't handle properly some png formats
Pavel i-love-s...@yandex.ru added the comment: Excuse me, what avfilter has to do with this report? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2235
[issue2117] MJPEG decoder crash
Pavel i-love-s...@yandex.ru added the comment: Why is the status needs more info? I saw in logs other photos also crash mjpeg decoder (all these photos are broken uploads from iPhone just like the one attached). djpeg from libjpeg correctly identifies that the image corrupted (Premature end of JPEG file) but ffmpeg crashes on that image. This image crashes also on arm the same way. I also tried that on pre armv5te build and it also crashes (pre armv5te uses different bistream reader). So, I think decode_block should check if bit context has enough bits before reading it. Can I change the status to approved/reproduced? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2117
[issue2117] MJPEG decoder crash
Pavel i-love-s...@yandex.ru added the comment: It does not happen on Linux, but happens only on windows. 1) is irrelevant to this issue. 2) I'm able to reproduce and anyone who can run win32 build from http://ffmpeg.arrozcru.org/autobuilds/ can do so as well. Do you intentionally ignore message by compn, who reproduced the crash months ago? cmd line to reproduce: ffmpeg -loglevel 99 -i http://roundup.ffmpeg.org/file992/1279729383-BLUE01.jpg -f image2 -vcodec bmp test.bmp What can I do to help identify the problem and fix it? I tried to dig through the code, but it's unlikely that I can fix it properly, someone with knowledge of this jped decoder code should be able to tell where it is the right place to check if the read buffer contains enough data. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2117
[issue2117] MJPEG decoder crash
Pavel i-love-s...@yandex.ru added the comment: In windows it reads way after the buffer end: Unhandled exception at 0x10251115 (avcodec-52.dll) in ffmpeg.exe: 0xC005: Access violation reading location 0x00d3a000. at this point s-gb.buffer_end is: 0x00d38ed4 as you see, it went too far away from the buffer end (4384 bytes), it tried to cross page boundary and that caused access violation. So, I decided to check what's going on differently on linux box and I got quite surprising results. I added some test code (see attached MJPEG_CRASH.diff) and I got quite surprising results: mjpeg reader on linux reads !!40236!! bytes past the buffer end!! Quite remarkable. Stuff like that definitely causes access violation on windows, I have no idea who something like that doesn't coredump ffmpeg on linux. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2117 MJPEG_CRASH.diff Description: Binary data
[issue2117] MJPEG decoder crash
Pavel i-love-s...@yandex.ru added the comment: It's pure luck that on linux it goes on reading memory previously allocated by other parts of ffmpeg. At least don't ignore your own valgrind result: ERROR SUMMARY: 21921 errors from 10 contexts (suppressed: 3 from 3) Most of the read uninlitialized memory come from the fact that the buffer of MJpegDecodeContext wasn't initialized with some values. I made that simple chagne ( memset(s- buffer, 0, s-buffer_size + FF_INPUT_BUFFER_PADDING_SIZE); ) only to reduce number of reported errors and the valgrind report below is what I'm getting. My understanding is this simple chunk means that consequitive reads (each of size 4) were started from the end of allocated buffer and kept reading 886 times in a row. ==19911== 886 errors in context 2 of 2: ==19911== Invalid read of size 4 ==19911==at 0x8280E4A: ff_mjpeg_decode_sos (bswap.h:42) ==19911==by 0x82833FA: ff_mjpeg_decode_frame (mjpegdec.c:1470) ==19911==by 0x838EF04: avcodec_decode_video2 (utils.c:620) ==19911==by 0x8127690: av_find_stream_info (utils.c:2064) ==19911==by 0x8075A69: opt_input_file (ffmpeg.c:3081) ==19911==by 0x8081E5E: parse_options (cmdutils.c:204) ==19911==by 0x807D83E: main (ffmpeg.c:4197) ==19911== Address 0x41d42c7 is 825,863 bytes inside a block of size 825,866 alloc'd [r...@localhost ffmpeg]# valgrind -v --error-limit=no ./ffmpeg_g -loglevel 50 -i ../1279729383-BLUE01.jpg ==19911== Memcheck, a memory error detector ==19911== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==19911== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==19911== Command: ./ffmpeg_g -loglevel 50 -i ../1279729383-BLUE01.jpg ==19911== --19911-- Valgrind options: --19911---v --19911----error-limit=no --19911-- Contents of /proc/version: --19911-- Linux version 2.6.33.3-85.fc13.i686 (mockbu...@x86-06.phx2.fedoraproject.org) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Thu May 6 18:44:12 UTC 2010 --19911-- Arch and hwcaps: X86, x86-sse1-sse2 --19911-- Page sizes: currently 4096, max supported 4096 --19911-- Valgrind library directory: /usr/lib/valgrind --19911-- Reading syms from /lib/ld-2.12.1.so (0x331000) --19911-- Reading syms from /usr/local/dev/ffmpeg/ffmpeg_g (0x8048000) --19911-- Reading syms from /usr/lib/valgrind/memcheck-x86- linux (0x3800) --19911--object doesn't have a dynamic symbol table --19911-- Reading suppressions file: /usr/lib/valgrind/default.supp --19911-- REDIR: 0x3488d0 (index) redirected to 0x3803e023 (vgPlain_x86_linux_REDIR_FOR_index) --19911-- Reading syms from /usr/lib/valgrind/vgpreload_core-x86-linux.so (0x4001000) --19911-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so (0x4003000) ==19911== WARNING: new redirection conflicts with existing -- ignoring it --19911-- new: 0x003488d0 (index ) R- 0x04006920 index --19911-- REDIR: 0x348aa0 (strlen) redirected to 0x4006d40 (strlen) --19911-- Reading syms from /lib/libm-2.12.1.so (0x505000) --19911-- Reading syms from /lib/libz.so.1.2.3 (0x53c000) --19911--object doesn't have a symbol table --19911-- Reading syms from /lib/libpthread-2.12.1.so (0x4e8000) --19911-- Reading syms from /lib/libc-2.12.1.so (0x353000) --19911-- REDIR: 0x3ca010 (index) redirected to 0x4006890 (index) --19911-- REDIR: 0x3cb4b0 (memchr) redirected to 0x4007480 (memchr) --19911-- REDIR: 0x3cabf0 (rindex) redirected to 0x40067a0 (rindex) --19911-- REDIR: 0x3c6980 (posix_memalign) redirected to 0x4004e19 (posix_memalign) --19911-- REDIR: 0x3ca180 (strcmp) redirected to 0x4001400 (_vgnU_ifunc_wrapper) --19911-- REDIR: 0x484c30 (__strcmp_ssse3) redirected to 0x4007300 (strcmp) --19911-- REDIR: 0x3cba40 (memset) redirected to 0x4001400 (_vgnU_ifunc_wrapper) --19911-- REDIR: 0x47b8e0 (__memset_sse2) redirected to 0x40080f0 (memset) --19911-- REDIR: 0x3cd580 (strchrnul) redirected to 0x40081e0 (strchrnul) FFmpeg version SVN-r25605, Copyright (c) 2000-2010 the FFmpeg developers built on Oct 30 2010 20:37:08 with gcc 4.4.4 20100630 (Red Hat 4.4.4-10) configuration: libavutil 50.32. 3 / 50.32. 3 libavcore 0. 9. 1 / 0. 9. 1 libavcodec52.93. 0 / 52.93. 0 libavformat 52.84. 0 / 52.84. 0 libavdevice 52. 2. 2 / 52. 2. 2 libavfilter1.53. 0 / 1.53. 0 libswscale 0.12. 0 / 0.12. 0 --19911-- REDIR: 0x3ca780 (strlen) redirected to 0x4001400 (_vgnU_ifunc_wrapper) --19911-- REDIR: 0x3ca7c0 (__strlen_sse2) redirected to 0x4006d00 (strlen) --19911-- REDIR: 0x3ca240 (strcpy) redirected to 0x4006d80 (strcpy) --19911-- REDIR: 0x3c6a10 (free) redirected to 0x4005771 (free) --19911-- REDIR: 0x3c6e90 (realloc) redirected to 0x4005c06 (realloc) --19911-- REDIR: 0x3c5e40 (malloc) redirected to 0x4005b57 (malloc) --19911-- REDIR: 0x3cd4b0 (rawmemchr) redirected to 0x4008210 (rawmemchr) --19911-- REDIR: 0x3ca840 (__GI_strlen) redirected to 0x4006d20 (__GI_strlen) --19911-- REDIR: 0x3d1670 (__GI_strncmp
[issue2117] MJPEG decoder crash
Pavel i-love-s...@yandex.ru added the comment: Also, these two lines alone deserve attention: [mjpeg @ 0x402b540] buffer too small, expanding to 825858 bytes [mjpeg @ 0x402b540] marker parser used 836843 bytes (6694742 bits) which means that parser used 836843 bytes out of 825858 allocated. As a result: [mjpeg @ 0x402b540] mjpeg decode frame unused -11684 bytes FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2117
