0000730: Rendering with transitions degrades quality unacceptably

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000730

Kdenlive

Rendering

public

2009-03-22 16:55

2009-06-18 01:44

Reporter

gnomeking

Assigned To

ddennedy

Priority

normal

Severity

major

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

0.7.2

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

Relationships

Notes
(0002574) gnomeking (reporter) 2009-03-22 16:57	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.

(0002667) subik (reporter) 2009-04-06 19:05	I can confirm this behaviour. I can "workaround" it a bit when I set "Scanning: Force Progressive" in the Rendering dialog

(0002681) ddennedy (developer) 2009-04-09 09:26	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.

(0002700) ddennedy (developer) 2009-04-11 08:52	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.

(0002701) ddennedy (developer) 2009-04-11 08:58	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.

Issue History
Date Modified	Username	Field	Change
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