Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002049KdenliveUser Interfacepublic2011-03-02 16:142011-03-24 20:33
Reportersunab 
Assigned Toj-b-m 
PrioritynormalSeverityminorReproducibilityalways
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product VersionRecent git 
Target VersionFixed in Version 
Summary0002049: Project preview turns black ONLY when proxy is enabled
DescriptionPlaying a clip in the timeline with proxy option activated is fine until you seek backward and play again. At this moment the project monitor preview turns black.

Tested with HDV (Canon HV20) footage and with AVCHD (Sony Nex-5).

When proxy is disabled on the clip, the project monitor plays fine again.
Steps To Reproduce1. put HD clip on the timeline with proxy enabled.
2. play the project once.
3. seek backward some seconds.
4. play the project a second, third time and the project monitor turns black.
TagsNo tags attached.
Build/Install Method(select)
Attached Files? file icon proxy.avi [^] (1,393,868 bytes) 2011-03-04 20:42

- Relationships

-  Notes
(0006513)
sunab (developer)
2011-03-02 17:47
edited on: 2011-03-02 17:49

Additional information :

I used a sample file provided by jmpoure captured with a canon hv20 camcorder, so it will be easier for someone to reproduce the problem.

http://www.poure.com/footage/canon/hv20/hdv-1080-25p-001.m2t [^]

I played the proxy avi file produced by kdenlive :
With ffplay (version 0.6.2), playing and seeking with no problems.
Then I played it with melt (git head) and the last frames appear white. Seeking backward a dozen frames all appear white.

(0006529)
sunab (developer)
2011-03-04 19:22

I have investigated a bit more my problem :

I have encoded the same sample with the same encoding options (stock proxy options in kdenlive) with the latest ffmpeg git : same problem.

The proxy option in kdenlive defaults with the AVI container, just changing this to MPEGTS container results in no more problems to play/seek the file with melt or kdenlive.
(0006538)
j-b-m (administrator)
2011-03-04 23:44

Confirmed. We should probably change the default to mpegts container and .ts... will do in the next days unless someone finds another issue with mpegts container.
(0006623)
j-b-m (administrator)
2011-03-22 18:24

Fix committed in svn rev. 5517, I hope the mpegts container will work for everyone...
(0006624)
ddennedy (developer)
2011-03-23 17:53

ffmpeg dev Michael Niedermayer often compares their transport stream (de)muxer to their program stream when criticizing the inferior implementation of mpegts.
(0006625)
ddennedy (developer)
2011-03-23 17:55

IOW, the program stream (de)muxer is considered a better choice and slightly more efficient. However, I have not tested this specifically within this feature/use-case.
(0006628)
j-b-m (administrator)
2011-03-24 13:11

Made a few tests and there is one issue with MPEG TS and MPEG PS:

When transcoding the file mentionned in first comment, the resulting file is one frame shorter than original file. This does not happen with AVI file format.

Having the transcoded file shorter than original is a big problem, since in Kdenlive's timeline we replace original files with proxies, the timeline will then be corrupted. Not yet sure how to manage this but for the proxy feature, we must be sure to have the same length as original clip...
(0006631)
ddennedy (developer)
2011-03-24 20:33
edited on: 2011-03-24 20:35

Duration provided by MLT via FFmpeg is only an estimate based on muxer metadata. A more accurate duration can only be determined by trying to decode the file and stopping on end-of-stream or failure.

I resolved a bug reported here recently for A/V sync problems when people put untrimmed clips on the timeline. http://kdenlive.org/mantis/view.php?id=2003 [^]

As a result all duration estimates are now 3 - 4 frames shorter in the forthcoming release, and that will have an impact here as well.

However, I can see this being a big general problem because IIRC ffmpeg does not use the estimated duration for transcoding. Rather, it uses end-of-stream or failure. So, you can not really expect equivalent results between ffmpeg and melt/mlt. It seems the best solution is to do the transcode with melt. Then, you should get equivalent, reliable results between proxy generation, proxy usage on the timeline, and rendering against original files. You do not need to worry about melt's more stringent seeking requirements; render using the original files is going to need that anyways.


- Issue History
Date Modified Username Field Change
2011-03-02 16:14 sunab New Issue
2011-03-02 17:47 sunab Note Added: 0006513
2011-03-02 17:48 sunab Note Edited: 0006513 View Revisions
2011-03-02 17:49 sunab Note Edited: 0006513 View Revisions
2011-03-04 19:22 sunab Note Added: 0006529
2011-03-04 20:42 sunab File Added: proxy.avi
2011-03-04 23:44 j-b-m Note Added: 0006538
2011-03-04 23:44 j-b-m Assigned To => j-b-m
2011-03-04 23:44 j-b-m Status new => acknowledged
2011-03-22 18:24 j-b-m Note Added: 0006623
2011-03-22 18:24 j-b-m Status acknowledged => feedback
2011-03-23 17:53 ddennedy Note Added: 0006624
2011-03-23 17:55 ddennedy Note Added: 0006625
2011-03-24 13:11 j-b-m Note Added: 0006628
2011-03-24 20:33 ddennedy Note Added: 0006631
2011-03-24 20:34 ddennedy Note Edited: 0006631 View Revisions
2011-03-24 20:35 ddennedy Note Edited: 0006631 View Revisions


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker