Re: [Mlt-devel] [issues@roundup.ffmpeg.org: [issue2092] crash at libswscale/rgb2rgb_template.c:1370
Brought to you by:
ddennedy,
lilo_booter
From: Mikko R. <mik...@ik...> - 2010-07-15 19:10:58
|
On Thu, Jul 15, 2010 at 10:16:29AM -0700, Dan Dennedy wrote: > On Thu, Jul 15, 2010 at 8:50 AM, Mikko Rapeli <mik...@ik...> wrote: > > On Wed, Jul 14, 2010 at 11:48:31PM -0700, Dan Dennedy wrote: > >> On Tue, Jul 13, 2010 at 3:31 PM, Mikko Rapeli <mik...@ik...> wrote: > >> > Hello, > >> > > >> > Just hit this bug with kdenlive and repeated with melt. Backtrace points to > >> > libswscale but maybe there's something going bad in mlt too. I'm using latest > >> > ffmpeg and mlt from git. > >> > > >> > -Mikko > >> > >> I just fixed it in git commit 0d8eb5b. > > > > Thanks, this fixes the crash from mlt's side and no need for the libswscale > > I posted into the bug report. > > > > When playing with melt, frames 70 and 71 in the sample clip are empty white > > frames, and the last frame 72 seems to a copy of last real frame 69. Is this > > how they really are in the stream? > > I do not know. All I know is that 70 and 71 are failing to decode by > the white frames. Then, frame 72 is determined to be a duplicate frame > by the framerate algorithm. With the bug, it was using a bad cached > AVFrame from the prior decode failures to render the duplicate frame > resulting in the crash. After the change, it does not use this bad > AVFrame, skips rendering the cached frame, and attempts to re-read a > frame that happens to decode successfully. I am not sure how it > happens that frame 69 is the one that was re-read. It is a bit > strange, but shortening the duration of the clip by 3 frames makes it > look clean. Ok. > > mplayer does not show any white frames in the end. > > Maybe it has a different notion of the duration of the video. It will > be helpful if you can use ffmpeg, mplayer, and melt to dump image > sequences (using the same framerate) to see if they output different > total frames and if the last frames are not duplicates or corrupt. Actually I see some flickering white frame when playing the original ( http://mcfrisk.kapsi.fi/media/2010/00109.m2ts ) with melt but not when seeking back frame by frame, and ffplay seems to keep playing the audio tracks for ever. So something wrong in ffmpeg side, or in the file format. I converted them to dnxhd with command: ffmpeg -i in.m2ts -vcodec dnxhd -b 120000k -deinterlace \ -acodec copy -r 25 out.mov I thought the audio track might as well be copied but it seems to be the causing this since converting to default audio codec fixes the white frame problems. But I will go back to editing now, thanks again for the fix. -Mikko |