Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001330KdenliveRenderingpublic2009-11-30 18:202010-02-20 08:16
Reporterttill 
Assigned Toddennedy 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platform64 bitOSArch LinuxOS Versioncurrent
Product VersionRecent git 
Target VersionFixed in Version0.7.7 
Summary0001330: Rendered video flickers
DescriptionA video rendered as MPEG2 or H.264 flickers.
I can't test other formats because of http://www.kdenlive.org/mantis/view.php?id=1250 [^]

For an example see: http://ttill.de/untitled.mp4 [^]

Titles will look normal.
Additional InformationKdenlive: rev. 4152
MLT: commit 1e9f16c45b608c3c6058c352ea7b16a5564d1e64
FFmpeg: SVN-r20667

The problem exists both with mlt 0.4.6 from git and mlt 0.4.7 from git.

The problem exists since about 2 to 3 weeks.
TagsNo tags attached.
Build/Install MethodManual build from SVN
Attached Files

- Relationships

-  Notes
(0004384)
Granjow (developer)
2009-11-30 19:43

Correct project settings (progressive/interlaced)? Rendering preview correct?
(0004388)
ttill (developer)
2009-11-30 22:59

The videos look correct both in clip and in project monitor.
Project settings are correct (interlaced).

I forgot to mention that non-AVCHD footage works.
(0004398)
ttill (developer)
2009-12-03 21:18

I have to add something regarding clip and project monitor.
Sometimes the problem also occurs in clip and project monitor.
Sometimes in the project monitor only.
I'm however not able to reproduce it. It seems very random to me.
(0004541)
ddennedy (developer)
2010-01-20 07:02

Example no longer available and not able to reproduce.
(0004542)
ddennedy (developer)
2010-01-20 07:04
edited on: 2010-01-20 07:05

Oops, I had downloaded this example earlier, but I have not ever seen this with my AVCHD samples. It might be related to your device's AVCHD output. If you do not see this when playing the AVCHD in ffplay and can provide a sample AVCHD clip, then please reopen this.

(0004545)
ttill (developer)
2010-01-20 18:32

The AVCHD clips play correct both in ffplay and melt.
However it always flickers in project monitor and if rendered.
On the other hand transcoding works flawless.
My camera is a Panasonic HDC SD 100.

Source file: http://ttill.de/00018.MTS [^]
Rendered video: http://ttill.de/rendered.mp4 [^]
(0004553)
ddennedy (developer)
2010-01-22 04:21

I downloaded the AVCHD and am still unable to reproduce it. I put the clip on kdenlive timeline using project settings both HD 1080p 25 and 1080i 50. I trimmed a very small amount from each end of the clip by itself on the timeline. I rendered to single pass H.264 MP4 8000k.

I am using FFmpeg SVN-r21322, latest MLT from git, and Kdenlive r4157.
I highly doubt Kdenlive version matters. I believe this is an issue in MLT and/or FFmpeg that has been resolved.

Also, I tested with and without VDPAU enabled in MLT. Neither one reproduced. And I tested several times trying different things.
(0004578)
ttill (developer)
2010-01-25 14:58

Thanks for your intensive tests!

This weekend I made sure there is nothing left from old versions of ffmpeg/mlt/kdenlive.
With x264/ffmpeg/mlt/kdenlive from git/svn I tried the same things you did and got the same results schown in my videos above.
(0004580)
ddennedy (developer)
2010-01-25 18:44

Strange, but this is certainly not the first time I have not been able to reproduce bugs. Thank you for upgrading to try it. Maybe you can better describe how you are testing with details of project setting, timeline placement, render profile.
(0004648)
ttill (developer)
2010-02-05 15:51

I just figured out that disabling the option "drop b frames..." solves the problem partly.
Additionally to clip monitor AVCHD footage also works in project monitor again. However now rendering AVCHD videos crashes. After rendering 99% the log "window" appears only saying rendering failed.
(0004649)
ttill (developer)
2010-02-05 16:20
edited on: 2010-02-05 16:21

After downgrading MLT to the revision I compiled on January 30. rendering AVCHD clips (with "drop b frames..." disabled) works, too.
I tested rendering H.264 and MPEG4 (8000k single pass)
-> they fail with AVCHD + MLT GIT from today
-> they work with AVCHD + MLT GIT from January 30.
-> other source material works anyway

(0004650)
ddennedy (developer)
2010-02-05 18:38

What timing. Yesterday I posted a message to the kdenlive-devel mailing list about a problem with the drop b-frames setting being incorrectly serialized into the XML for rendering. For me this was causing the video to play at double framerate and end well before the audio track.

Late Feb 5, I made a large commit to MLT Git. One of the changes was to fix a crash I see in closing x264 when multi-threaded encoding is enabled. I do not believe Kdenlive is enabling that, but the builder wizard's launch script does by checking the # cpus and setting an environment variable.

Unfortunately, when you write "MLT GIT from today" I do not know if you are using this recent large commit. Please send for mlt 'git log | head -1'
(0004652)
ddennedy (developer)
2010-02-05 19:06

I found (only available on melt command line for now), that setting skip_frame=bidir on the file reproduces the problem (video too fast is how I see it). However, setting new_seek=0 prevents the problem! This new seeking code was introduced in release 0.4.6 to make seeking on AVCHD accurate and artifact-free. Furthermore, and quite interesting, is that regardless of the new_seek property value, skip_frame=bidir always indicates the frames are progressive scan defeating any deinterlace that may be necessary!

It should be noted that MLT does not do any special handling on skip_frame. This is an option that is simply passed onto the FFmpeg libs. Of course, it may affect timestamps that MLT is reading, but very strange how it affects the progressive flag. I can only say that this option does not appear to be stable.
(0004654)
ttill (developer)
2010-02-05 20:39

Well, the timing isn't incidentally: After I read your mail I had the hope that this might also be related to my issue.
I am using this large commit:
commit 92637967c8250ad3d4f6312f36e6725fc2e4a659
However I do not use the builder wizard. I build via ABS (http://wiki.archlinux.org/index.php/Arch_Build_System [^]).
What environment variable are you talking about?
Here are my compile flags:

CARCH="x86_64"
CHOST="x86_64-unknown-linux-gnu"

#-- Exclusive: will only run on x86_64
# -march (or -mcpu) builds exclusively for an architecture
CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,--hash-style=gnu -Wl,--as-needed"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j3"

Maybe this helps.

Nice to finally see some progress!
(0004655)
ddennedy (developer)
2010-02-05 21:13

OK, build process looks sound. The env var I speak of is MLT_AVFORMAT_THREADS - takes a numeric value. Looks like you are not using it.

It may be your failing to render with AVCHD clips is due to VDPAU if you have more than one process trying to access VDPAU. (Note to self to see if there is some way to fail gracefully.) Some recent version of Kdenlive sets an environment variable to disable VDPAU when launching melt to render. And of course, if you have Kdenlive open with AVC clips, and try to use melt at the command line against AVC clips, it should fail as well.

You have to set env var MLT_NO_VDPAU=1 to disable it. A recent version of kdenlive_renderer sets this. Search kdenlive/renderer/renderjob.cpp for "VDPAU".
(0004656)
ttill (developer)
2010-02-05 21:21
edited on: 2010-02-05 21:21

MLT_NO_VDPAU is used in kdenlive since r4241 (http://kdenlive.svn.sourceforge.net/viewvc/kdenlive?view=rev&revision=4241 [^])
As I use r4291 VDPAU should not cause the crash if I get you right.

(0004657)
ddennedy (developer)
2010-02-05 21:32

Yes.
Let me get this straight... When rendering from AVC to MPEG-4 segfaults near the end. Fails on single pass as well as first pass of dual pass. But render from non-AVC works OK? And this with drop b-frames disabled?
(0004658)
ttill (developer)
2010-02-05 21:44

Right.
But not only MPEG-4. I also tested MPEG-2 and H.264 so far with the same results.
It crashes after reaching 99% (also first pass of dual pass) with the following message:
Rendering of /home/till/kdenlive/untitled.mp4 crashed
(0004659)
ddennedy (developer)
2010-02-05 23:13

I am struggling to reproduce. Now I am on OS X hoping to get a different experience. I placed a 10 sec AVCHD on the timeline of a HD 720p25 project and save the .kdenlive file. I am rendering the project file at the command line hoping to catch an error or re-run in gdb:

$ melt -profile hdv_720_25p test.kdenlive -consumer avformat:test.mpg vcodec=mpeg2video b=8000k bf=2 b_strategy=1 trellis=1 acodec=mp2 ab=384k

$ melt -profile hdv_720_25p test.kdenlive -consumer avformat:test.mp4 acodec=libmp3lame ab=128k ar=44100 vcodec=mpeg4 minrate=0 b=8000k mbd=2 trellis=1 mv4=1

Both return result codes of 0 and output are playable - quite a beautiful progressive scan conversion!

What kind of AVCHD are you using, how long is it, and what is your project setting?
(0004660)
ddennedy (developer)
2010-02-05 23:19

Sorry, went back in history and am downloading your sample (again?). Still, what is your project setting? Also, I will test more on my main Linux dev workstation with different FFmpeg versions as well as another Linux install.
(0004661)
ddennedy (developer)
2010-02-06 05:25

Just a note to say that with your clip, I see the flickering now with skip_frame=bidir regardless of whether I use new_seek. A different clip plays in correct order but too fast with skip_frame=bidir and new_seek=1, but not new_seek=0.
(0004664)
ttill (developer)
2010-02-07 13:42

I use HD 1080i 50Hz as video profile.
As you are now able to reproduce is there anything left I can do?
(0004668)
ddennedy (developer)
2010-02-07 18:51

We are resolving the reported problem by removing the Drop B frames option in Kdenlive. There are deeper issues with skip_frame with a good chance they are not resolvable or will require so much new/changed code that it will make the code messier or buggier.
I just reproduced the problem with rendering by using a 1080i50 profile. Before, I was using 720p30. When I render (at command line with melt) at 1080i50 with real_time=0, then then it works. Additionally, with the default real_time=-1 (multithreaded, no frame dropping), there is a memory leak. In addition, when it succeeded, the output video played at half speed. I also notice that the source clip 00018.MTS plays at half speed with ffplay as well.
OK, I have sufficiently narrowed down the crash on render to debug this now.
(0004670)
ddennedy (developer)
2010-02-08 05:34

The render problem was just fixed in MLT Git commit a5e5065.
(0004671)
ddennedy (developer)
2010-02-08 05:47

"Drop B frames on H.264 clips" was removed from Kdenlive and render crash located and fixed in MLT.
(0004676)
ttill (developer)
2010-02-08 17:33

It works!
Thank you very much for all the effort you put into this issue.

- Issue History
Date Modified Username Field Change
2009-11-30 18:20 ttill New Issue
2009-11-30 18:20 ttill Build/Install Method => Manual build from SVN
2009-11-30 19:43 Granjow Note Added: 0004384
2009-11-30 19:43 Granjow Status new => feedback
2009-11-30 22:59 ttill Note Added: 0004388
2009-12-03 21:18 ttill Note Added: 0004398
2010-01-20 07:02 ddennedy Note Added: 0004541
2010-01-20 07:02 ddennedy Status feedback => resolved
2010-01-20 07:02 ddennedy Resolution open => unable to reproduce
2010-01-20 07:02 ddennedy Assigned To => ddennedy
2010-01-20 07:04 ddennedy Note Added: 0004542
2010-01-20 07:05 ddennedy Note Edited: 0004542 View Revisions
2010-01-20 18:32 ttill Note Added: 0004545
2010-01-20 18:32 ttill Status resolved => feedback
2010-01-20 18:32 ttill Resolution unable to reproduce => reopened
2010-01-22 04:21 ddennedy Note Added: 0004553
2010-01-25 14:58 ttill Note Added: 0004578
2010-01-25 14:58 ttill Status feedback => assigned
2010-01-25 18:44 ddennedy Note Added: 0004580
2010-02-05 15:51 ttill Note Added: 0004648
2010-02-05 16:20 ttill Note Added: 0004649
2010-02-05 16:21 ttill Note Edited: 0004649 View Revisions
2010-02-05 18:38 ddennedy Note Added: 0004650
2010-02-05 19:06 ddennedy Note Added: 0004652
2010-02-05 20:39 ttill Note Added: 0004654
2010-02-05 21:13 ddennedy Note Added: 0004655
2010-02-05 21:21 ttill Note Added: 0004656
2010-02-05 21:21 ttill Note Edited: 0004656 View Revisions
2010-02-05 21:32 ddennedy Note Added: 0004657
2010-02-05 21:44 ttill Note Added: 0004658
2010-02-05 23:13 ddennedy Note Added: 0004659
2010-02-05 23:19 ddennedy Note Added: 0004660
2010-02-06 05:25 ddennedy Note Added: 0004661
2010-02-07 13:42 ttill Note Added: 0004664
2010-02-07 18:51 ddennedy Note Added: 0004668
2010-02-08 05:34 ddennedy Note Added: 0004670
2010-02-08 05:47 ddennedy Note Added: 0004671
2010-02-08 05:47 ddennedy Status assigned => resolved
2010-02-08 05:47 ddennedy Fixed in Version => 0.7.7
2010-02-08 05:47 ddennedy Resolution reopened => fixed
2010-02-08 17:33 ttill Note Added: 0004676
2010-02-08 17:33 ttill Status resolved => feedback
2010-02-08 17:33 ttill Resolution fixed => reopened
2010-02-08 19:30 ddennedy Status feedback => resolved
2010-02-08 19:30 ddennedy Resolution reopened => fixed
2010-02-20 08:16 j-b-m Status resolved => closed


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker