View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000840KdenliveUser Interfacepublic2009-05-22 14:332010-02-02 10:38
Assigned Toddennedy 
StatusclosedResolutionno change required 
PlatformOSOS Version
Product VersionRecent git 
Target VersionFixed in Version0.7.6 
Summary0000840: Some bad quality video clips crash kdenlive and inigo/melt
DescriptionI have generally observed that some of my video clips will crash kdenlive. Some of the clips are low quality as described below. It would be nice to be able to "harden" kdenlive/mlt/dvgrab so that they give errors instead of crashing. For example "This file has errors and cannot be processed". The crashes don't usually give me any backtrace.

1) I copied an old vhs tape (maybe even 2nd generation) to raw DV using my miniDV imput and dvgrab. (VHS -> HV30 input -> firewire -> dvgrab). Most of of the video captured fine (captured in 1GB segments), but a few frames cause crashes. It is very hard to find the problem areas of the file and exclude them. In one instance I was able to get around this by using mencoder to convert the files to a different format before using in kdenlive. There was the inevitable loss of quality but at least I was able to use the video.

2) Dvgrab also sometimes crashes when the VHS input is very low quality (older generation or fuzzy or tracking problems).

3) I generally don't have problems with this process using high quality VHS input or recently capture DV directly with the camera so my guess is that it is due to problems with the original tapes. Maybe loosing frame sync?? I really don't know much about the details.

I summary, I don't think kdenlive should crash. It would be nice to support these types of files, but an error message saying they are damaged would be reasonable also.

Thanks, Geoff
TagsNo tags attached.
Build/Install MethodManual build from SVN
Attached Files

- Relationships

-  Notes
ddennedy (developer)
2009-05-27 08:21

Do they crash in ffplay? If so, please report the bug to FFmpeg project. If not, we need a sample to download so we can diagnose.

Also, we will need to constrain this bug to just dealing with bad DV, otherwise it is too general and not really managing the process. When another format is encountered, we need a separate bug to track its specific issues.

I suppose eventually, we can consider to add a manually triggered "validate" process that would let the user run the video in its entirety through melt as a child process and then invalidate the clip if the child process fails.
gsking1 (reporter)
2009-05-28 04:25

They do not crash ffplay, but the screen goes black until the end of the video.
I'll try to find a small clip to share, but may take a few days.
gsking1 (reporter)
2009-08-15 15:16

Here's an example of a troublesome clip. [^]

It crashes kdenlive (0.7.5) but not ffplay (0.5), but does stutter and I get a few "error while seeking". The crash comes in kdenlive, while scrolling across the blue screen at 3:25. This is from an old vhs tape copied to dv using current dvgrab. This is common as I'm converting some old vhs segments to digital. The old program changes on the vhs and tracking problems usually cause this.

When played with a more current mplayer (MPlayer SVN-r29464-4.3.3) it plays fine.

What I can usually do to work around this is after the crash to restart and quickly cut out the bad section in kdenlive and then its okay since you never seek over it.

Hope this helps. I'm only leaving it up a few day so please grab it soon if you want it. Also, my connection can be slow so may take a while.

Thanks, Geoff
gsking1 (reporter)
2009-08-15 16:26

This was the dvgrab capture log for this file.

sudo dvgrab --format dv1 --noavc --autosplit --size=1024 tdf1992-
Found AV/C device with GUID 0x0000850001a0acc6
Capture Started
[cut out a bunch, most had none or few errors]
"tdf1992-045.avi": damaged frame near: timecode ??:??:??.?? date 2009.08.14 09:52:58
This means that there were missing or invalid FireWire packets.

"tdf1992-045.avi": damaged frame near: timecode ??:??:??.?? date 2009.08.14 09:54:21
This means that there were missing or invalid FireWire packets.
"tdf1992-045.avi": 1023.89 MiB 8944 frames timecode ??:??:??.?? date 2009.08.14 09:54:29
Warning: 2 damaged frames.
ddennedy (developer)
2009-08-15 23:40

There is a bug in FFmpeg v0.5 that causes this "stalling" on bad DV in ffplay and a crash in MLT. This was recently debugged with the Debian maintainers of Kdenlive and FFmpeg, and patched in their package: [^]

See if your distro can apply this patch or upgrade their package beyond v0.5.

There is nothing more dvgrab can do when it does not receive data it is expecting. Sure, it should not crash, but I have made some improvements in the latest release (3.4) and not been able to reproduce it further as tracked here: [^]
ddennedy (developer)
2009-08-15 23:42

Fixed in FFmpeg beyond their 0.5 release: [^]

See also: [^]

- Issue History
Date Modified Username Field Change
2009-05-22 14:33 gsking1 New Issue
2009-05-22 14:33 gsking1 Build/Install Method => Manual build from SVN
2009-05-27 08:21 ddennedy Note Added: 0002938
2009-05-27 08:21 ddennedy Status new => feedback
2009-05-27 08:21 ddennedy Status feedback => assigned
2009-05-27 08:21 ddennedy Assigned To => ddennedy
2009-05-28 04:25 gsking1 Note Added: 0002952
2009-08-15 15:16 gsking1 Note Added: 0003788
2009-08-15 16:26 gsking1 Note Added: 0003789
2009-08-15 23:40 ddennedy Note Added: 0003792
2009-08-15 23:42 ddennedy Note Added: 0003793
2009-08-15 23:42 ddennedy Status assigned => resolved
2009-08-15 23:42 ddennedy Resolution open => fixed
2009-09-10 01:41 xzhayon Resolution fixed => no change required
2009-10-08 20:21 j-b-m Fixed in Version => 0.7.6
2010-02-02 10:35 j-b-m Fixed in Version 0.7.6 => 0.7.7
2010-02-02 10:37 j-b-m Fixed in Version 0.7.7 => 0.7.6
2010-02-02 10:38 j-b-m Status resolved => closed

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker