[Kdenlive-devel] Problem: Brightness changing when using still frames

Dan Dennedy dan at dennedy.org
Thu Feb 20 08:05:05 UTC 2014


On Wed, Feb 19, 2014 at 10:30 PM, Dan Dennedy <dan at dennedy.org> wrote:
> On Wed, Feb 19, 2014 at 12:05 PM, Claus R. F. Overbeck
> <claus.overbeck at abovo-it.com> wrote:
>> On 19.02.2014 19:12, Dan Dennedy wrote:
>>> Here is today's 32-bit version. I do not recall if it runs on Debian
>>> stable. I think it might depend on a newer glibc such that it will
>>> work on Debian testing or unstable tho. Well, you can try:
>>>
>>> http://builds.meltytech.com/kdenlive/kdenlive-ubuntu12.04-x86-20140219.tar.bz2
>>>
>>>> Does that build include MLT?
>>>
>>> Yes, and x264, lame, frei0r, and FFmpeg. :o) You do not need to
>>> install this. You simply extract it anywhere you like and run the
>>> start-kdenlive script. You must use this launch script and not try to
>>> run the binary in bin/ directly!
>>
>> Hi Dan,
>>
>> thanks for the build. It runs on my debian (which has some packets from
>> testing and unstable).
>>
>> However the problem persists. Could you check my project
>> (http://overbeck-it.de/tmp/kdenlive-test.tgz)? The error is easily
>> reproduced:
>> Open 00038_53.MTS in the clip monitor.
>> 1. Extract some frame from the middle to a PNG and add this to the project.
>> 2. Add the png to the timeline (track1)
>> 2. Add 00038_53.MTS to the timeline (track2)
>> The change in brightness can be easily seen on the switch from track 1
>> to track 2
>>
>> The same goes for overlapping 00038_53.MTS with a frozen version of
>> 00038_53.MTS.
>>
>
> Claus, I started looking into this. I do not have a fix yet, but it
> looks like a workaround (with the build I provided) is to make the
> project use the ITU-R 601 colorspace. You will need to create a custom
> project profile under Settings, switch the project to it using Project
>> Project Settings, and save (Save As?) the project. I recommend you
> restart Kdenlive after that and load the new project. Hope that helps
> for now.

OK, I found and fixed the bug. When the project called for an ITU 709
YCbCr colorspace, MLT also requested that colorspace for the RGB side
of a YCbCr-to-RGB conversion. But, libswscale in FFmpeg needed the
default 601-based coefficients.

Now, I want to warn you about an unresolved problem using the freeze
effect in Kdenlive preview. You see, Kdenlive via MLT uses SDL for
video playback. Normally, during playback, it is using YCbCr, but when
paused it switches to RGB mode. When you switch back and forth between
paused scrubbing/stepping over the freeze and playing through it
several times, it causes the "frozen" frame within the effect to
render between RGB and YCbCr respectively. There are slight
inaccuracies in the YCbCr<->RGB conversions that will accumulate on
the frozen frame's image each time you do this. This is not a problem
when you Render as it makes one pass through the freeze effect using
the same image format throughout, but it will manifest in the preview
depending upon how often you review the effect in different modes.

By mid-day Thursday, you can get a new build:

http://builds.meltytech.com/kdenlive/kdenlive-ubuntu12.04-x86-20140220.tar.bz2

-- 
+-DRD-+




More information about the Kdenlive mailing list