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);
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 (
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
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
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
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
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
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
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,
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
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.
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
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)
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]#
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
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
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.
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
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
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
39 matches
Mail list logo
