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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
24 matches
Mail list logo
