|Anonymous | Login||2016-07-23 19:14 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000730||Kdenlive||Rendering||public||2009-03-22 16:55||2009-06-18 01:44|
|Target Version||Fixed in Version||0.7.3|
|Summary||0000730: Rendering with transitions degrades quality unacceptably|
|Description||Simple project demonstrating unacceptable (and unwarrented) degredation of quality in rendered video...|
The video in the preview interface seems perfect, but when rendering to any output format (I've tried mpeg2 at the highest bitrate and rawdv), the section of text which involves a transition is broken.
I've uploaded a test project which shows the bug with a simple text PNG (with alpha transparancy) and a colour clip.
http://gnomes.org.uk/kdenlive_bug/no_combination.png [^] shows the image from the first 5 seconds of the rendered clip, with http://gnomes.org.uk/kdenlive_bug/alpha_combination.png [^] showing the image after.
As can be seen, the text has horrible "mice teeth" type effects.
I believe that the horizontal lines are being exported in the wrong order somehow (e.g. 2, 1, 4, 3, 6, 5, 8, 7, 10, 9). Note that this test project only includes a colour clip and a png file; so I don't think it can be an issue with incorrectly specifying the input interlace order.
|Additional Information||http://gnomes.org.uk/kdenlive_bug/ [^]|
|Tags||No tags attached.|
|Build/Install Method||Distribution package|
|Attached Files|| alpha_combination.png [^] (128,848 bytes) 2009-03-22 16:55
|Just a little note to say that it appears to be that the render is inconsistent over whether to use interlaced mode or not. The project starts in progressive mode, then changes to interlaced mode when the transition starts.|
|I can confirm this behaviour. I can "workaround" it a bit when I set "Scanning: Force Progressive" in the Rendering dialog|
|This is called field-based rendering, which is appropriate when animating composites. It is on by default when the project or render setting is not progressive. MLT provides the option to disable this on a per effect basis. So, kdenlive needs an enhancement to use and expose that.|
I sat down to expose this MLT progressive rendering option in kdenlive when I realized it was already added! I reviewed the source history, and indeed it was not in 0.7.2. It is in SVN and the soon to be released 0.7.3. It is named "Force Progressive Rendering" in the Composite transition's settings window. I am considering a change to make this default to on.
Also, as subik reported, forcing progressive in the render setting does prevent this, but that is not always desirable. One often wants interlace output (e.g. DVD) but when not animating the composite, you do not want field-based rendering.
Re: I believe that the horizontal lines are being exported in the wrong order
MLT intentionally renders bottom-field-first (fyi, DV is bottom field first). This alone is not a huge issue. A more significant issue is when combining videos with different field orders. Fortunately, MLT normalizes field order to take care of this. I have confirmed correct field order normalization and field-based rendering with commerical broadcast television customers and equipment for which MLT was designed. They often need to animate titles and graphical overlays.
|2009-03-22 16:55||gnomeking||New Issue|
|2009-03-22 16:55||gnomeking||File Added: alpha_combination.png|
|2009-03-22 16:55||gnomeking||Build/Install Method||=> Distribution package|
|2009-03-22 16:57||gnomeking||Note Added: 0002574|
|2009-04-06 19:05||subik||Note Added: 0002667|
|2009-04-09 09:26||ddennedy||Note Added: 0002681|
|2009-04-11 08:52||ddennedy||Note Added: 0002700|
|2009-04-11 08:52||ddennedy||Status||new => resolved|
|2009-04-11 08:52||ddennedy||Fixed in Version||=> 0.7.3|
|2009-04-11 08:52||ddennedy||Resolution||open => fixed|
|2009-04-11 08:52||ddennedy||Assigned To||=> ddennedy|
|2009-04-11 08:58||ddennedy||Note Added: 0002701|
|2009-06-18 01:44||xzhayon||Status||resolved => closed|
|Copyright © 2000 - 2016 MantisBT Team|