[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
Ronald S. Bultje rsbul...@gmail.com added the comment: av_picture_copy(pict, pict_src, -vp-pix_fmt, vp-width, vp-height); +vp-pix_fmt, dst_width, dst_height); #else sws_flags = av_get_int(sws_opts, sws_flags, NULL); is-img_convert_ctx = sws_getCachedContext(is- img_convert_ctx, -vp-width, vp-height, vp-pix_fmt, vp-width, vp- height, +vp-width, vp-height, vp-pix_fmt, dst_width, dst_height, dst_pix_fmt, sws_flags, NULL, NULL, NULL); Doesn't the top half of the #if/#else truncate the picture unscaled? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: Doesn't the top half of the #if/#else truncate the picture unscaled? The values stored in vp-width and vp-height are larger than the actual buffer size allocated by libSDL. Which is why a buffer overrun occurs. If the ffplay-requested image size is too large, the libSDL behavior is to allocate the largest buffer size compatible with the user's video system. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Do you know where this behaviour is documented? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: Doesn't the top half of the #if/#else truncate the picture unscaled? I just noticed you were asking about the partial-fix-1.patch. This first attempt wasn't successful libSDL doesn't reduce bmp-w and bmp-h if it decides to return a smaller buffer then requested. I consider this an SDL bug. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: Do you know where this behaviour is documented? The libSDL API does not discuss the exception behavior of SDL_CreateYUVOverlay at all. And a google search of their discussion forum turns up nothing related to this topic. So that leaves us the actual behavior of the source code. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: The attached patch prevents the buffer overrun and resulting segfault by exiting with an error message. This patch is standalone, and does not depend on my earlier patch from 7/24. issue2079-avoid-segfault-v1.patch FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079 issue2079-avoid-segfault-v1.patch Description: Binary data
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: I'm really into inserting swscale, or modifying swscale into the filter loop instead. It seems fairly simple, except that the Libraries appear to parse ffplay command line. It also appears that the video wxh is not known at the time the filter is created. BTW: also, if you scale to a size larger than screen, then ffplay will also die a horrible malloc death. Also posted a BUG complaint to the SDL folks. appears something similar has been reported for the SDL overlay call. Oh well. On 07/31/2010 02:43 PM, scheutzo wrote: scheutzomike.scheut...@alcatel-lucent.com added the comment: The attached patch prevents the buffer overrun and resulting segfault by exiting with an error message. This patch is standalone, and does not depend on my earlier patch from 7/24. issue2079-avoid-segfault-v1.patch FFmpeg issue trackeriss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079 FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: I'd like to move this discussion to ffmpeg-user. I answered there, using subject line video back-end in ffplay.c. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/30/2010 09:45 AM, scheutzo wrote: scheutzomike.scheut...@alcatel-lucent.com added the comment: I'd like to move this discussion to ffmpeg-user. I answered there, using subject line video back-end in ffplay.c. BTW: you have not said what u expected from the SDL overlay call in this particular scenario. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: BTW: you have not said what u expected from the SDL overlay call in this particular scenario. Yes, there is an SDL bug. SDL tells ffplay that it created a Y plane that is 1920x1080 pixels, at 1 byte/pixel, but then SDL allocates an actual buffer that is 1024x768 bytes. I would guess this is because your video hardware can support a maximum of 1024x768 bytes. Even if you get SDL to fix their bug, ffplay will *still* not work because SDL will likely return a buffer smaller than ffplay requested, which violates the ffplay design. You are fighting an uphill battle if you expect others to rewrite code to support old video hardware that almost nobody would attempt to play High Def on. Earlier in the thread, you even said you don't expect it to decode at full frame rate. You should be happy the -vf trick works, because otherwise you would not be able to see video at all. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/30/2010 11:13 AM, scheutzo wrote: You are fighting an uphill battle if you expect others to rewrite code to support old video hardware that almost nobody would attempt to play High Def on. Earlier in the thread, you even said you don't expect it to decode at full frame rate. So far there is no evidence that my hardware is involved at all. Or any hardware from anywhere. Or any deficiency in the hardware. So far the software crashes, which is inappropriate by any standard. FFPLAY will never know why it crashed, because it just does not check if the info, which appears to have been illegally gleaned from SDL, is appropriate for its own usage. So long as it does not crash, the developers appear to be quite content. Ya, in 2000, there was just the expectation that this laptop has just enough cpu to play a dvd without any hiccups. With avchd, my quad core amd @ 3.2Ghz/win 7 has just enough cpu to play it. Rendering video, my quadcore is just to sloo. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
Ronald S. Bultje rsbul...@gmail.com added the comment: FWIW, I can reproduce this. Whatever causes the bug should be fixed in ffplay.c. Please refrain from further bitchfighting and fix the actual bug. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: Is there some reason why the scaling is not auto majically inserted when video is larger than screen size? It seems like u have to introduce some scaling if windows are resized. Yes, you are right that a fit-to-window-rescaling is often necessary. The ffplay code delegates this particular responsibility to the SDL library. My guess is that the developer(s) assumed that SDL has the information to make the best choice between 'video card hardware scaling' and 'cpu software scaling'. So, the ffplay code assumes that a video overlay can always be created that is big enough to hold the entire unscaled image from the compressed stream. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: -noframedrop -an -vf scale=1024:693 this works Good. That's progress! - Because of chroma subsampling, I suggest you specify even width and height values (i.e. 693 might cause trouble). - The values you picked look like they distort the display aspect ratio, which should be 1.77 for 1920x1080 source. Your values of 1024/693 gives 1.48, so circles will display as ovals. - be aware that if your laptop is too slow, the -noframedrop is going to cause the video to get out of sync with the audio. It's a good option to use when testing, but not good when watching a movie. - this buffer-is-too-small issue is not easily fixable in ffplay. Since it does not affect most systems, probably the most reasonable tradeoff I can do is submit a patch to warn user they need to reduce video size using the scale filter, then exit ffplay. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/27/2010 09:47 AM, scheutzo wrote: Your values of 1024/693 gives 1.48 Calculator was set to HEX. so a little boo boo. Is there some reason why the scaling is not auto majically inserted when video is larger than screen size? It seems like u have to introduce some scaling if windows are resized. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment:
i used this:
-noframedrop -an -vf scale=1024:693
/home/gat/DIESEL/TEST_FP24/PF24_60Seconds.MTS
this works, and appears to be fairly fast on a pIII/700Mhz laptop.
It does seem like one has to feed in the minimum of screen size and
video frame size. Feeding in a large video frame size seems to screw up
things.
==
Breakpoint 3, alloc_picture (opaque=0xb7238020) at ffplay.c:1328
1328 vp-bmp = SDL_CreateYUVOverlay(vp-width, vp-height,
(gdb) n
1332 SDL_LockMutex(is-pictq_mutex);
(gdb) p *vp
$12 = {pts = 0, target_clock = 0, pos = 0, bmp = 0x8c53820, width = 1024,
height = 693, allocated = 0, pix_fmt = PIX_FMT_YUV420P, picref = 0x0}
(gdb) p *vp-bmp
$13 = {format = 842094169, w = 1024, h = 693, planes = 3, pitches = 0x8c304a8,
pixels = 0x8c55f08, hwfuncs = 0x86b4a40, hwdata = 0x8c3e6d0, hw_overlay = 1,
UnusedBits = 0}
(gdb) p vp-bmp-pitches[0]
$14 = 1024
(gdb) p vp-bmp-pitches[1]
$15 = 512
(gdb) p vp-bmp-pitches[2]
$16 = 512
(gdb) l
1327
1328 vp-bmp = SDL_CreateYUVOverlay(vp-width, vp-height,
1329 SDL_YV12_OVERLAY,
1330 screen);
1331
1332 SDL_LockMutex(is-pictq_mutex);
1333 vp-allocated = 1;
1334 SDL_CondSignal(is-pictq_cond);
1335 SDL_UnlockMutex(is-pictq_mutex);
1336 }
(gdb)
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment:
It looks like my first guess was wrong.
Next experiment: Please put a breakpoint on the for statement in
ff_img_copy_plane, and set the breakpoint condition to width dst_wrap.
(gdb) list ff_img_copy_plane
900 }
901
902 void ff_img_copy_plane(uint8_t *dst, int
903const uint8_t
904int width, in
905 {
906 if((!dst) || (!src))
907 return;
908 for(;height 0; height--) {
909 memcpy(dst, src, width);
(gdb) break 908
Breakpoint 1 at 0x80bd6eb: file imgconvert.c, line 908.
(gdb) cond 1 width dst_wrap
(gdb) run -nodropframe -nostats -an hd-test.ts
This breakpoint should trigger before you get the fatal glibc error. Please show
me the output of backtrace command.
(gdb) bt
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment:
did u want me to run this as is run -nodropframe -nostats -an hd-test.ts
Since my lines are outta sync, I went up the stack and listed each
reference to show where it was called.
There are actually 2 calls: the first one goes through without any issues:
But the second set, which looks just like the first:
Default(3): b3851020
Malloc (80):8f6c530 for libavfilter/avfilte...@49 P(1) 0B f=0/0
APC(0):dst(b36d1000,1024),src(b4be4a30,1952),bw:1920,h:1080
APC(1):dst(b3811000,512),src(b4df59e8,976),bw:960,h:540=0/0
*** glibc detected *** /home/gat/MPLAYER/git/ffmpeg.0/ffplay_g: free():
invalid pointer: 0xb3851020 ***
=== Backtrace: ==0KB vq= 3660KB sq=0B f=0/0
SO:
first call to ff_img...:
(gdb) bt
#0 ff_img_copy_plane (dst=0xb3b74000 , dst_wrap=1024,
src=0xb44e4a30
73*,08iihhhg...@de?6292100;DABB@ADHJJJIE=917CIAABCCDEE?77???=;;7.*!#'))#'19;?@@?...@?;9:@AAA@@?=:85,%((.;ACCBBBAAAB95:AA@@??50\)//)5;HNJJKLLMNNEAJURPMK=89@DN]_ce...,
src_wrap=1952,
width=1920, height=1080) at libavcodec/imgconvert.c:905
#1 0x08216e0a in av_picture_copy (dst=0xb66ff15c, src=0xb66ff190,
pix_fmt=PIX_FMT_YUV420P, width=1920, height=1080)
at libavcodec/imgconvert.c:986
#2 0x0804f2e7 in queue_picture (is=0xb7238020, src_frame=0x8bd6ac0,
pts=0.47774, pos=-1) at ffplay.c:1434
#3 0x0804f53c in output_picture2 (is=0xb7238020, src_frame=0x8bd6ac0,
pts1=0.47774, pos=-1) at ffplay.c:1501
#4 0x0805074f in video_thread (arg=0xb7238020) at ffplay.c:1888
#5 0x005d8aff in ?? () from /usr/lib/libSDL-1.2.so.0
#6 0x00623d7e in ?? () from /usr/lib/libSDL-1.2.so.0
#7 0x00836ab5 in start_thread () from /lib/libpthread.so.0
#8 0x0052283e in clone () from /lib/libc.so.6
(gdb) n
906 if((!dst) || (!src))
(gdb) n
909 memcpy(dst, src, width);
(gdb) n
9101.97 CHECK_AV_SEARCH_DEFAULT();aq=0KB vq= 3770KB sq=0B f=0/0
(gdb) up
#1 0x08216e0a in av_picture_copy (dst=0xb66ff15c, src=0xb66ff190,
pix_fmt=PIX_FMT_YUV420P, width=1920, height=1080)
at libavcodec/imgconvert.c:986
986 ff_img_copy_plane(dst-data[i], dst-linesize[i],
(gdb) l
981 if (i == 1 || i == 2) {
982 h= -((-height)desc-log2_chroma_h);
983 }
984 av_log(NULL,
AV_LOG_INFO,APC(%d):dst(%x,%d),src(%x,%d),bw:%d,h:%d\n,i,
985 dst-data[i], dst-linesize[i], src-data[i],
src-linesize[i], bwidth, h);
986 ff_img_copy_plane(dst-data[i], dst-linesize[i],
987 src-data[i], src-linesize[i],
988 bwidth, h);
989 CHECK_AV_SEARCH_DEFAULT();
990 }
(gdb) up
#2 0x0804f2e7 in queue_picture (is=0xb7238020, src_frame=0x8bd6ac0,
pts=0.47774, pos=-1) at ffplay.c:1434
1434 av_picture_copy(pict, pict_src,
(gdb) l
1429 pict_src.linesize[1] = src_frame-linesize[1];
1430 pict_src.linesize[2] = src_frame-linesize[2];
1431
1432 CHECK_AV_SEARCH_DEFAULT();
1433 //FIXME use direct rendering
1434 av_picture_copy(pict, pict_src,
1435 vp-pix_fmt, dst_width, dst_height);
1436 CHECK_AV_SEARCH_DEFAULT();
1437 #else
1438 sws_flags = av_get_int(sws_opts, sws_flags, NULL);
(gdb) up
#3 0x0804f53c in output_picture2 (is=0xb7238020, src_frame=0x8bd6ac0,
pts1=0.47774, pos=-1) at ffplay.c:1501
1501 z = queue_picture(is, src_frame, pts, pos);
(gdb) l
1496 av_get_pict_type_char(src_frame-pict_type), pts, pts1);
1497 #endif
1498 {
1499 int z;
1500 CHECK_AV_SEARCH_DEFAULT();
1501 z = queue_picture(is, src_frame, pts, pos);
1502 return z;
1503 }
1504 }
1505
(gdb) up
#4 0x0805074f in video_thread (arg=0xb7238020) at ffplay.c:1888
1888 ret = output_picture2(is, frame, pts, pos);
(gdb) l
1883
1884 pts = pts_int*av_q2d(is-video_st-time_base);
1885 CHECK_AV_SEARCH_DEFAULT();
1886
1887 #if CONFIG_AVFILTER
1888 ret = output_picture2(is, frame, pts, pos);
1889 CHECK_AV_SEARCH_DEFAULT();
1890 #else
1891 ret = output_picture2(is, frame, pts, pkt.pos);
1892 CHECK_AV_SEARCH_DEFAULT();
(gdb) up
#5 0x005d8aff in ?? () from /usr/lib/libSDL-1.2.so.0
(gdb)
=Second call where it dies=
APC(0):dst(b36d1000,1024),src(b4de4a30,1952),bw:1920,h:1080
Breakpoint 1, ff_img_copy_plane (dst=0xb36d1000 , dst_wrap=1024,
src=0xb4de4a30
73*,08iihhhg...@de?6292100;DABB@ADHJJJIE=917CIAABCCDEE?77???=;;7.*!#'))#'19;?@@?...@?;9:@AAA@@?=:85,%((.;ACCBBBAAAB95:AA@@??50\)//)5;HNJJKLLMNNEAJURPMK=89@DN]_ce...,
src_wrap=1952,
width=1920, height=1080) at libavcodec/imgconvert.c:905
905 {
(gdb) bt
#0 ff_img_copy_plane
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: == (gdb) cond 1 width dst_wrap (gdb) run -nodropframe -nostats -an /home/gat/DIESEL/TEST_FP24/PF24_01Seconds.MTS Starting program: /home/gat/MPLAYER/git/ffmpeg.0/ffplay_g -nodropframe -nostats -an /home/gat/DIESEL/TEST_FP24/PF24_01Seconds.MTS [Thread debugging using libthread_db enabled] FFplay version git-3f8caf9, Copyright (c) 2003-2010 the FFmpeg developers built on Jul 24 2010 14:49:54 with gcc 4.4.2 20091027 (Red Hat 4.4.2-7) == AND === /home/gat/MPLAYER/git/ffmpeg.0/ffplay_g: unrecognized option 'nodropframe' Program exited with code 01. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: unrecognized option 'nodropframe' That should be -noframedrop FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment:
===
Malloc (80):b5aa7520 for libavfilter/avfilte...@49 P(0)
APC(0):dst(b4797000,1024),src(b52c1a30,1952),bw:1920,h:1080
[Switching to Thread 0xb7237b70 (LWP 1758)]
Breakpoint 1, ff_img_copy_plane (
dst=0xb4797400 7O_WVVUUSOKGA?ADDD@;50-*'(
\036\035\034\035\035\035\035\036\037\037
!\\#$%(*,/,,-/.01344333468889::863-.488899888776532100/..,,++*)%$$$#!
\036\035\037$((9GL\\XQNA?;852/,++**\033\033\033\033\033'Jcitz\204\207\215\220\224\215~wlcPGB?:7+\034\027
+AL[du~\213\215\220\222\220\210zo..., dst_wrap=1024,
src=0xb52c21d0
95,(*.6:iihhhg...@de?6292100;dffec??adgijjie=917ciaabccdee?77...@?=;;7.*#%)++%)39;?@@??@@@:;=ABCBBBA?:6-)'-:@BBAA@@?...@73883)%*00*4:GMIIJLLMNNGCLWUSPN89@DN[]ac...,
src_wrap=1952,
width=1920, height=1080) at libavcodec/imgconvert.c:908
908 for(;height 0; height--) {
(gdb) bt
#0 ff_img_copy_plane (
dst=0xb4797400 7O_WVVUUSOKGA?ADDD@;50-*'(
\036\035\034\035\035\035\035\036\037\037
!\\#$%(*,/,,-/.01344333468889::863-.488899888776532100/..,,++*)%$$$#!
\036\035\037$((9GL\\XQNA?;852/,++**\033\033\033\033\033'Jcitz\204\207\215\220\224\215~wlcPGB?:7+\034\027
+AL[du~\213\215\220\222\220\210zo..., dst_wrap=1024,
src=0xb52c21d0
95,(*.6:iihhhg...@de?6292100;dffec??adgijjie=917ciaabccdee?77...@?=;;7.*#%)++%)39;?@@??@@@:;=ABCBBBA?:6-)'-:@BBAA@@?...@73883)%*00*4:GMIIJLLMNNGCLWUSPN89@DN[]ac...,
src_wrap=1952,
width=1920, height=1080) at libavcodec/imgconvert.c:908
#1 0x08216e0a in av_picture_copy (dst=0xb723715c, src=0xb7237190,
pix_fmt=PIX_FMT_YUV420P, width=1920, height=1080)
at libavcodec/imgconvert.c:986
#2 0x0804f2e7 in queue_picture (is=0xb7238020, src_frame=0xb6700480,
pts=0.47774, pos=-1) at ffplay.c:1434
#3 0x0804f53c in output_picture2 (is=0xb7238020, src_frame=0xb6700480,
pts1=0.47774, pos=-1) at ffplay.c:1501
#4 0x0805074f in video_thread (arg=0xb7238020) at ffplay.c:1888
#5 0x0012faff in ?? () from /usr/lib/libSDL-1.2.so.0
#6 0x0017ad7e in ?? () from /usr/lib/libSDL-1.2.so.0
#7 0x001c9ab5 in start_thread () from /lib/libpthread.so.0
#8 0x002b883e in clone () from /lib/libc.so.6
==
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: Well, it is crashing is queue_picture() just as I suspected. You wrote that in queue_picture() vp-bmp-w is 1920 (pixels), but a few lines of code later vp-bmp-pitches[0] is 1024 (bytes). This situation should not be possible. Are you resizing the video window with the mouse? What happens if you run ffplay with -x 400 -y 300 arguments, making sure not to modify the size of the video window? What happens if you comment out the SDL_VIDEORESIZE case in ffplay.c:event_loop()? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: The sequence of events are: 1) gdb ffplay_g 2) set beakpoints, if any. 3) run with options. 4) watch the terminal 4a) When ffplay displays the (blacked) x11 window, Watch Processor Usage 5) when processor usage drops to nothing, MINIMIZE the ffplay window, as it blocks most other windows. 6) See where gdb has stopped. If u dont want the window minimized ( after cpu usage goes to 0 ), then I need to do something else. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment:
At the one breakpoint u suggested.
You wrote that in queue_picture() vp-bmp-w is 1920 (pixels), but a few lines
of code later vp-bmp-pitches[0] is 1024 (bytes). This situation should not
be
possible.
Breakpoint 2, queue_picture (is=0xb7238020, src_frame=0xb6700480,
pts=0.47774, pos=-1) at ffplay.c:1405
1405 if(vp-picref)
(gdb) p vp-bmp
$15 = (SDL_Overlay *) 0x8bd8170
(gdb) p *vp-bmp
$16 = {format = 842094169, w = 1920, h = 1080, planes = 3, pitches =
0x8bd74c8, pixels = 0x8bd80f0, hwfuncs = 0xca2004,
hwdata = 0x8bd8290, hw_overlay = 1, UnusedBits = 0}
(gdb) p *vp-bmp-pitches
$17 = 1024
(gdb) p *vp-bmp-pitches[0]
Cannot access memory at address 0x400
(gdb) p vp-bmp-pitches[0]
$18 = 1024
(gdb) p vp-bmp-pitches[1]
$19 = 512
(gdb) p vp-bmp-pitches[2]
$20 = 512
(gdb)
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/25/2010 12:31 PM, scheutzo wrote: You wrote that in queue_picture() vp-bmp-w is 1920 (pixels), but a few lines of code later vp-bmp-pitches[0] is 1024 (bytes). This situation should not be possible. btw that was with the -x 400 -y 300 arguments FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: That procedure sounds ok, but we should try to avoid the minimize operation anyway. What happens if you run ffplay with -x 400 -y 300 arguments, making sure not to modify the size of the video window? Did you try this? -x and -y set the initial size of the video window, in pixels. Make it small enough that you don't have to minimize it. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment:
(gdb) p *vp-bmp
$16 = {format = 842094169, w = 1920, h = 1080, planes = 3, pitches =
0x8bd74c8, pixels = 0x8bd80f0, hwfuncs = 0xca2004,
hwdata = 0x8bd8290, hw_overlay = 1, UnusedBits = 0}
(gdb) p vp-bmp-pitches[0]
$18 = 1024
The vp-bmp structure is created entirely by SDL library, and it does not match
the ffplay assumptions. Either your installed version of SDL has a bug, or your
video driver has some very unusual limitation.
You could try compiling the latest 1.2 version of SDL (1.2.14) for yourself.
It's not difficult. Download from www.libsdl.org.
./configure --prefix=/usr
make
make install # as root
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/25/2010 02:35 PM, scheutzo wrote: The vp-bmp structure is created entirely by SDL library, From watt u say: 1325 vp-pix_fmt = is-video_st-codec-pix_fmt; 1326 #endif 1327 1328 vp-bmp = SDL_CreateYUVOverlay(vp-width, vp-height, 1329 SDL_YV12_OVERLAY, 1330 screen); 1331 1332 SDL_LockMutex(is-pictq_mutex); I guess I'll see when i drop in a debugable createoverlay, and see whats what. BTW my SDL here is /usr/lib/libSDL-1.2.so.0 /usr/lib/libSDL-1.2.so.0.11.2 /usr/lib/libSDL.so so its not tooo . ooo old. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: On 07/25/2010 02:35 PM, scheutzo wrote: You could try compiling the latest 1.2 version of SDL (1.2.14) for yourself. It appears that latest SDL does much of the same thing.At least in terms of vp-bmp It still core dumps It takes a bit longer to core. I get a partial small picture. ===SO= Continuing. APC(0):dst(b40f4000,1024),src(b427ba30,1952),bw:1920,h:1080 APC(1):dst(b4234000,512),src(b448c9e8,976),bw:960,h:540 APC(2):dst(b41f4000,512),src(b45124b8,976),bw:960,h:540 FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: UGeorge - I have uploaded issue2079-partial-fix-1.patch. Let me know if it fixes the crash on your system. I had to use the -noframedrop argument with ffplay when I tested this on a slower machine. -nostats and -an were also useful. This patch does not properly re-scale the video, but you should correctly see the upper left region of the original video. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079 issue2079-partial-fix-1.patch Description: Binary data
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: It all so interesting, and so messy. Tried this morning to have it crash at same locations as before. No so lucky as before. It still crashes, it still appears to be a buffer overrun of a malloc buffer. Tried ElectricFence (-lefence). Seems like efence does not understand the posix_memalign() call. when that was resolved, i get a ill instruction error on a system call (__kernel_vsyscall () ) why?I am so confused. Later on i'll apply patches, if I can find them. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: Breakpoint 2, queue_picture (is=0xb7238020, src_frame=0x8bd6ac0, pts=0.47774, pos=-1) at ffplay.c:1401 1401 int dst_width = FFMIN(vp-width, vp-bmp-w); (gdb) p vp-width $4 = 1920 (gdb) p vp-bmp-w $5 = 1920 (gdb) n 1402 int dst_height = FFMIN(vp-height, vp-bmp-h); (gdb) p vp-height $6 = 1080 (gdb) p vp-bmp-h No symbol bmp in current context. (gdb) p vp-bmp-h $7 = 1080 (gdb) Lines dont match. BUT as u see they both have the same values FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: re: xorg.conf Well, there isn't any there. there is an xorg.conf.bak which has ( en toto ): [r...@mylaptop X11]# cat xorg.conf.bak Section Device Identifier Videocard0 Driver vesa EndSection [r...@mylaptop X11]# == lspci shows: VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 13) FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: svn backtrace still missing. I don't think anyone has claimed this is a regression. The 0.5 source has the same bad assumption. -- nosy: +scheutzo FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Backtrace made from FFmepg's current svn version is still missing. (Is this clearer?) FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: UGeorge - can you tell me what video driver you have loaded? I'm trying to replicate the issue, but on my machine SDL is happy to create a YUV Overlay larger than the desktop. This may explain why most people do not get this crash. The video driver or amount of video memory may have something to do with the cause. On linux, the video driver info is in xorg.conf file. On my system, this is in /etc/X11 directory. In that file, in Section Device, I want to know what the parameter named Driver is set to. Thanks. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
Reimar Döffinger b...@reimardoeffinger.de added the comment: On Fri, Jul 23, 2010 at 06:06:17PM +, scheutzo wrote: UGeorge - can you tell me what video driver you have loaded? I'm trying to replicate the issue, but on my machine SDL is happy to create a YUV Overlay larger than the desktop. This may explain why most people do not get this crash. The video driver or amount of video memory may have something to do with the cause. This is on Windows, and on Windows it is not possible to create a Window larger than the screen size without tricks. I suspect the real issue is that SDL does not use that trick and thus ends up with a smaller window than requested. I guess ffplay should check for this anyway, but still SDL could be improved there. IIRC WM_WINDOWPOSCHANGING needs to be handled explictly (or possibly just WM_GETMINMAXINFO). FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
scheutzo mike.scheut...@alcatel-lucent.com added the comment: Further investigation by UGeorge determined that the root cause of this problem is that the coded video dimensions are larger than his desktop. This leads to a buffer overrun during an image copy into the YUV Overlay buffer. The bug is that ffplay.c assumes that the call to SDLCreateYUVOverlay() will always return the requested image buffer size, but evidence indicates that it does not. It won't create a buffer larger than the desktop. Fixed title and reopened this issue since it appears to be a valid report, and I didn't find an existing roundup issue for this situation. Issue1672 might be the same, but there's not enough information in that report to be sure. -- status: closed - open title: ffplay: munmap_chunk(): invalid pointer - ffplay: segfault if coded video WxH dimension larger than desktop FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
[issue2079] ffplay: segfault if coded video WxH dimension larger than desktop
UGeorge netbe...@gatworks.com added the comment: do u just have the patchs so I can apply to my heavily modified DEBUG of ffmpeg/ffplay? -- title: ffplay: segfault if coded video WxH dimension larger than desktop - ffplay: segfault if coded video WxH dimension larger than desktop FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2079
