|Anonymous | Login||2016-07-26 07:04 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001216||Kdenlive||Rendering||public||2009-10-16 21:00||2010-11-08 03:02|
|Platform||Core 2 Duo (64bit)||OS||Ubuntu Linux||OS Version||9.10|
|Target Version||Fixed in Version|
|Summary||0001216: video freezes between clips in rendered file|
|Description||I joined several HDV clips from 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
|Steps To Reproduce|| - Import any HDV clips, for example |
- Drag them to the timeline
- Render video to DVD or HDV mpeg2, problem is the same in both formats.
|Tags||No tags attached.|
|Build/Install Method||3rd party package|
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?
Stepan Roucka (reporter)
|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)|
|I believe this is a side effect of the dvgrab autosplit.|
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:
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.
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 :-(
autosplit on HDV is tricky. See this old patch:
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.
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
"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.
|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 - 2016 MantisBT Team|