On Wed, Feb 19, 2014 at 10:30 PM, Dan Dennedy <d...@dennedy.org> wrote: > On Wed, Feb 19, 2014 at 12:05 PM, Claus R. F. Overbeck > <claus.overb...@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-+ ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
