Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001216KdenliveRenderingpublic2009-10-16 21:002010-11-08 03:02
ReporterStepan Roucka 
Assigned Toddennedy 
PrioritynormalSeveritymajorReproducibilityalways
StatusassignedResolutionopen 
PlatformCore 2 Duo (64bit)OSUbuntu LinuxOS Version9.10
Product Version0.7.6 
Target VersionFixed in Version 
Summary0001216: video freezes between clips in rendered file
DescriptionI joined several HDV clips from Sony HDR-HC9
http://www.kdenlive.org/video-editor/sony-hdr-hc9 [^]
captured using dvgrab --autosplit
In the resulting file, the video allways freezes between
two scenes for approximately 20 frames.
In kdenlive 0.7.5, screen turned black between clips,
now it only freezes, which is better, but still not
usable.
Steps To Reproduce - Import any HDV clips, for example
http://www.roucka.eu/hdv/ [^]

 - Drag them to the timeline
 - Render video to DVD or HDV mpeg2, problem is the same in both formats.
TagsNo tags attached.
Build/Install Method3rd party package
Attached Files

- Relationships

-  Notes
(0004173)
ddennedy (developer)
2009-10-18 06:35

Are you trimming the clips at all or just placing the captured clips side-by-side on the timeline?
Your steps say "Render." Is it only when you render or also in kdenlive Project monitor before rendering?
(0004175)
Stepan Roucka (reporter)
2009-10-18 11:19

I am not trimming the clips at all, just placing them side-by-side on the timeline. In the project monitor, it looks similar. First few frames of each clip show some random frame with squares moving over it (looks like missing keyframe)
(0004185)
ddennedy (developer)
2009-10-19 02:15

I believe this is a side effect of the dvgrab autosplit.
(0004186)
ddennedy (developer)
2009-10-19 03:44

I made some observations after some testing. dvgrab always seems to output several garbage transport stream packets at the beginning, which should be ignore by most demuxers. All clips start on an I frame; however, some clips show clean starts in VLC and Avidemux while others do not. This makes me wonder if HDV (or some HDV) is open GOP instead of closed. These links seem to confirm it:
http://support.apple.com/kb/TA23119?viewlocale=en_US [^]

http://boldeafcp.wordpress.com/tag/hdv/page/2/ [^]

The Apple support note mentions Sony, but I am looking at my Canon HV20 footage where I believe this might be the case.

In that case, it is out-of-scope for dvgrab to ensure no references outside the first GOP. It is out-of-scope because dvgrab does not and should not do the decoding required to locate a closed GOP, not to mention that location may too far from the split location. Meanwhile, some clips with clean beginnings in VLC and Avidemux do not have clean beginnings in ffplay and melt, which indicates a problem in FFmpeg libs.

In summary, it seems there are several issues, but ultimately, it is rather a problem inherent in the nature of open GOP HDV that can only be rectified by trimming.
(0004238)
ddennedy (developer)
2009-11-03 07:31

http://www.videohelp.com/glossary?O#Open%20GOP [^]
(0006003)
dschwen (reporter)
2010-10-25 05:19

I have a very similar problem (new clips after an autosplit do not start on a keyframe). However there is one more Symptom which I believe is crucial:

The previous clip ends on what should be the first frame of the new clip.

So to me it looks like a one-off bug in dvgrab. The split is made _after_ the first frame of the new recording (a keyframe) when it should be made _before_.

The missing keyframe explains the lag when entering a new scene. Too bad this bug hasn't been active in about a year. Last dvgrab release was more than a year ago. I was trying to track down active developers, but no luck so far. Might have to dig into the source myself :-(
(0006004)
ddennedy (developer)
2010-10-25 05:51

autosplit on HDV is tricky. See this old patch:

http://sourceforge.net/tracker/?func=detail&aid=1823128&group_id=14103&atid=314103 [^]

It has not been vetted enough to be applied officially. I believe the last time I tested this, my camcorder, Canon HV20, was not affected by the problem you describe, but I could be wrong. The bug might be intermittent or only affect streams created by some camcorders and not others. If you can offer any assistance, it is appreciated. I am the active developer of dvgrab.
(0006025)
dschwen (reporter)
2010-11-08 03:02

I just started to go through the source code. I added an output of the CanStartNewStream status at the beginning of DVgrab::writeFrame()

cout << ( m_frame->CanStartNewStream() ? "Y " : "N " ) << endl;

What I see puzzles me:

"dvgrab-2010.10.17_09-24-41.m2t": 99.64 MiB 921 frames timecode 00:03:55.12 date 2010.10.17 09:25:12N
"dvgrab-2010.10.17_09-24-41.m2t": 99.76 MiB 922 frames timecode 00:03:55.15 date 2010.10.17 09:25:12N
"dvgrab-2010.10.17_09-24-41.m2t": 99.85 MiB 923 frames timecode 00:03:55.15 date 2010.10.17 09:25:12N
"dvgrab-2010.10.17_09-24-41.m2t": 99.94 MiB 924 frames timecode 00:03:55.15 date 2010.10.17 09:25:12Y
"dvgrab-2010.10.17_09-24-41.m2t": 100.26 MiB 925 frames timecode 00:03:55.18 date 2010.10.17 09:25:12N
"dvgrab-2010.10.17_09-24-41.m2t": 100.34 MiB 926 frames timecode 00:03:55.18 date 2010.10.17 09:25:12N
"dvgrab-2010.10.17_09-24-41.m2t": 100.34 MiB 926 frames timecode 00:03:55.18 date 2010.10.17 09:25:12
N
"dvgrab-2010.10.17_09-27-08.m2t": 0.17 MiB 2 frames timecode 00:03:55.21 date 2010.10.17 09:27:08N
"dvgrab-2010.10.17_09-27-08.m2t": 0.26 MiB 3 frames timecode 00:03:55.21 date 2010.10.17 09:27:08N
"dvgrab-2010.10.17_09-27-08.m2t": 0.36 MiB 4 frames timecode 00:03:55.21 date 2010.10.17 09:27:08N
"dvgrab-2010.10.17_09-27-08.m2t": 0.46 MiB 5 frames timecode 00:03:55.24 date 2010.10.17 09:27:08N
"dvgrab-2010.10.17_09-27-08.m2t": 0.56 MiB 6 frames timecode 00:03:55.24 date 2010.10.17 09:27:08N
"dvgrab-2010.10.17_09-27-08.m2t": 0.65 MiB 7 frames timecode 00:03:55.24 date 2010.10.17 09:27:08N
"dvgrab-2010.10.17_09-27-08.m2t": 0.75 MiB 8 frames timecode 00:03:55.27 date 2010.10.17 09:27:08N
"dvgrab-2010.10.17_09-27-08.m2t": 0.84 MiB 9 frames timecode 00:03:55.27 date 2010.10.17 09:27:08N

A clear timecode discontinuity, but the CanStartNewStream is false before and after the discontinuity (four frames before the split it is 'true', and 12 frames after it is true again (not shown))

How can that be? If I can trust that output it would mean that my camera is not inserting keayframes after a recording stop. But that would make no sense.

- Issue History
Date Modified Username Field Change
2009-10-16 21:00 Stepan Roucka New Issue
2009-10-16 21:00 Stepan Roucka Build/Install Method => 3rd party package
2009-10-18 06:35 ddennedy Note Added: 0004173
2009-10-18 06:35 ddennedy Status new => feedback
2009-10-18 11:19 Stepan Roucka Note Added: 0004175
2009-10-19 02:14 ddennedy Status feedback => assigned
2009-10-19 02:14 ddennedy Assigned To => ddennedy
2009-10-19 02:15 ddennedy Note Added: 0004185
2009-10-19 03:44 ddennedy Note Added: 0004186
2009-11-03 07:31 ddennedy Note Added: 0004238
2010-10-25 05:19 dschwen Note Added: 0006003
2010-10-25 05:51 ddennedy Note Added: 0006004
2010-11-08 03:02 dschwen Note Added: 0006025


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker