From: Claus R. F. O. <cla...@ab...> - 2014-02-19 15:46:00
|
Hi, I have a problem with inserting still frames in a video. The brightness of the frozen/still frame changes compared to the rest of the video. What I do is: Extract a frame from a clip. Than insert that frame as a still. The same happens when I use the original clip and the freeze effect. One can see this in the project preview but also in the rendered video. My problem seems to be very similar to this: https://forum.kde.org/viewtopic.php?f=270&t=116531&sid=1ae1f924705dcf0755177a39731fea19 I have placed a test project, that shows the issue, at http://overbeck-it.de/tmp/kdenlive-test.tgz When you play the project you can see changes in brightness. It also occurs in the rendered output. Is this a known issue and is there a workaround? I am trying to finish an urgent project and would hate to have to switch to a different software now but I really cannot live with the "blinking". Thanks for your help! Claus P.S.: I love kdenlive, thanks for the great work! -- Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 |
From: Dan D. <da...@de...> - 2014-02-19 17:19:54
|
On Wed, Feb 19, 2014 at 7:28 AM, Claus R. F. Overbeck <cla...@ab...> wrote: > Hi, > > I have a problem with inserting still frames in a video. The brightness > of the frozen/still frame changes compared to the rest of the video. > What I do is: Extract a frame from a clip. Than insert that frame as a > still. The same happens when I use the original clip and the freeze > effect. One can see this in the project preview but also in the rendered > video. My problem seems to be very similar to this: > https://forum.kde.org/viewtopic.php?f=270&t=116531&sid=1ae1f924705dcf0755177a39731fea19 > > I have placed a test project, that shows the issue, at > http://overbeck-it.de/tmp/kdenlive-test.tgz > When you play the project you can see changes in brightness. It also > occurs in the rendered output. > > Is this a known issue and is there a workaround? > I am trying to finish an urgent project and would hate to have to switch > to a different software now but I really cannot live with the "blinking". > > Thanks for your help! > > Claus > > P.S.: I love kdenlive, thanks for the great work! I do not have time to test this now, but please take a look at this bug, which might be related: http://sourceforge.net/p/mlt/bugs/204/ And here is a current 64-bit build you can test that includes the bug fix: http://builds.meltytech.com/kdenlive/kdenlive-ubuntu12.04-x86_64-20140215.tar.bz2 P.S. You did not say anything about your OS and versions. |
From: Claus R. F. O. <cla...@ab...> - 2014-02-19 17:33:59
|
On 19.02.2014 18:19, Dan Dennedy wrote: > And here is a current 64-bit build you can test that includes the bug fix: > > http://builds.meltytech.com/kdenlive/kdenlive-ubuntu12.04-x86_64-20140215.tar.bz2 I use debian with kdenlive 0.9.6 and $ dpkg -l |grep -i mlt ii libmlt++3:i386 1:0.8.8-dmo1 i386 MLT multimedia framework C++ wrapper (runtime) ii libmlt-data 1:0.8.8-dmo1 all multimedia framework (data) rc libmlt3 1:0.6.2-0.0 i386 multimedia framework (runtime) ii libmlt5:i386 1:0.8.8-dmo1 i386 multimedia framework (runtime) ii libsmltk0 3.4.0.16.7-1 i386 library for SyncML-DS (SyncML Data Sync) clients (shared libraries) ii libxmltok1 1.2-3 i386 XML Parser Toolkit, runtime libraries ii python-mlt5 1:0.8.8-dmo1 i386 multimedia framework (python bindings) If you can provide a 32bit build I will test it! Does that build include MLT? Yours Claus -- Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 |
From: Dan D. <da...@de...> - 2014-02-19 18:12:28
|
On Wed, Feb 19, 2014 at 9:32 AM, Claus R. F. Overbeck <cla...@ab...> wrote: > On 19.02.2014 18:19, Dan Dennedy wrote: >> And here is a current 64-bit build you can test that includes the bug fix: >> >> http://builds.meltytech.com/kdenlive/kdenlive-ubuntu12.04-x86_64-20140215.tar.bz2 > > I use debian with kdenlive 0.9.6 > > and > > $ dpkg -l |grep -i mlt > ii libmlt++3:i386 1:0.8.8-dmo1 > i386 MLT multimedia framework C++ wrapper (runtime) > ii libmlt-data 1:0.8.8-dmo1 > all multimedia framework (data) > rc libmlt3 1:0.6.2-0.0 > i386 multimedia framework (runtime) > ii libmlt5:i386 1:0.8.8-dmo1 > i386 multimedia framework (runtime) > ii libsmltk0 3.4.0.16.7-1 > i386 library for SyncML-DS (SyncML Data Sync) clients > (shared libraries) > ii libxmltok1 1.2-3 > i386 XML Parser Toolkit, runtime libraries > ii python-mlt5 1:0.8.8-dmo1 > i386 multimedia framework (python bindings) > > > If you can provide a 32bit build I will test it! 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! -- +-DRD-+ |
From: Claus R. F. O. <cla...@ab...> - 2014-02-19 20:06:55
|
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. I really appreciate your help! Claus -- Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 |
From: Dan D. <da...@de...> - 2014-02-19 21:44:38
|
On Wed, Feb 19, 2014 at 12:05 PM, Claus R. F. Overbeck <cla...@ab...> 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. > I am not able to look into this for a while. I suggest you adjust the brightness to at least make it close. There are a few adjustment effects you can try to use. |
From: Dan D. <da...@de...> - 2014-02-20 06:31:02
|
On Wed, Feb 19, 2014 at 12:05 PM, Claus R. F. Overbeck <cla...@ab...> 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. -- +-DRD-+ |
From: Dan D. <da...@de...> - 2014-02-20 08:05:12
|
On Wed, Feb 19, 2014 at 10:30 PM, Dan Dennedy <da...@de...> wrote: > On Wed, Feb 19, 2014 at 12:05 PM, Claus R. F. Overbeck > <cla...@ab...> 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-+ |
From: Claus R. F. O. <cla...@ab...> - 2014-09-17 13:05:32
|
Hi List, Dan fixed the problem mentioned below for me in the beginning of the year. Now I have a new computer, I got Ubuntu 14.04 on it and installed the recent kdenlive version from the ppa. And now the initial problem returned. Didn't the fix make it into the new kdenlive version? Any help on how to fix the blinking is appreciated. Thanks Claus On 20.02.2014 09:05, Dan Dennedy wrote: > On Wed, Feb 19, 2014 at 10:30 PM, Dan Dennedy <da...@de...> wrote: >> On Wed, Feb 19, 2014 at 12:05 PM, Claus R. F. Overbeck >> <cla...@ab...> 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 > -- Claus R. F. Overbeck Geschäftsführer Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 USt.-IdNr.: DE291391750 |
From: Steve G. <s.g...@db...> - 2014-09-17 15:27:45
|
Are you referring to this problem? > 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. From Dan's answer it sounds as if the fix was applied to MLT. Do you know if that was the case? On 09/17/2014 05:48 AM, Claus R. F. Overbeck wrote: > Hi List, > > Dan fixed the problem mentioned below for me in the beginning of the > year. Now I have a new computer, I got Ubuntu 14.04 on it and installed > the recent kdenlive version from the ppa. And now the initial problem > returned. Didn't the fix make it into the new kdenlive version? > > Any help on how to fix the blinking is appreciated. > > Thanks > Claus > > On 20.02.2014 09:05, Dan Dennedy wrote: >> On Wed, Feb 19, 2014 at 10:30 PM, Dan Dennedy <da...@de...> wrote: >>> On Wed, Feb 19, 2014 at 12:05 PM, Claus R. F. Overbeck >>> <cla...@ab...> 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 >> > -- Steve Guilford http://www.dbplugins.com |
From: Claus R. F. O. <cla...@ab...> - 2014-09-17 15:44:49
|
On 17.09.2014 17:27, Steve Guilford wrote: > Are you referring to this problem? > >> 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. Yes. I get a change in brightness on the transition from a still "frozen" frame to the moving picture. > From Dan's answer it sounds as if the fix was applied to MLT. Do you > know if that was the case? As I am not an MLT/kdenlive developer I have no idea, sorry... Where you able to reproduce the problem? The small testfiles are still available on my server. Yours Claus -- Claus R. F. Overbeck Geschäftsführer Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 USt.-IdNr.: DE291391750 |
From: Brian M. <pez...@ya...> - 2014-09-17 16:11:28
|
This is the commit for the fix (Feb 20): https://github.com/mltframework/mlt/commit/4fd6c14958ac5bd739c8d2b66b86cbf99ae68c23 It was released in MLT 0.90 (June 2): https://github.com/mltframework/mlt/releases/tag/v0.9.0 The sunab kdenlive-release PPA has MLT versions for both 0.90 and 0.88: https://launchpad.net/~sunab/+archive/ubuntu/kdenlive-release The 0.90 build has a date of May 20. I'm not sure how that works out. Minimally, make sure that your installed MLT version is 0.90 or newer. Or use the latest daily build: http://builds.meltytech.com/kdenlive/latest.rss Or use the latest unstable build from sunab: https://launchpad.net/~sunab/+archive/ubuntu/kdenlive-svn ~BM ________________________________ From: Claus R. F. Overbeck <cla...@ab...> To: For kdenlive developers <kde...@li...> Sent: Wednesday, September 17, 2014 10:44 AM Subject: Re: [Kdenlive-devel] Problem: Brightness changing when using still frames On 17.09.2014 17:27, Steve Guilford wrote: > Are you referring to this problem? > >> 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. Yes. I get a change in brightness on the transition from a still "frozen" frame to the moving picture. > From Dan's answer it sounds as if the fix was applied to MLT. Do you > know if that was the case? As I am not an MLT/kdenlive developer I have no idea, sorry... Where you able to reproduce the problem? The small testfiles are still available on my server. Yours Claus -- Claus R. F. Overbeck Geschäftsführer Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 USt.-IdNr.: DE291391750 ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Kdenlive-devel mailing list Kde...@li... https://lists.sourceforge.net/lists/listinfo/kdenlive-devel |
From: Claus R. F. O. <cla...@ab...> - 2014-09-17 16:39:23
|
On 17.09.2014 18:11, Brian Matherly wrote: > Minimally, make sure that your installed MLT version is 0.90 or newer. I got 0.9.0-3 : dpkg -l | grep -i mlt ii libmlt++3 0.9.0-3 amd64 MLT multimedia framework C++ wrapper (runtime) ii libmlt-data 0.9.0-3 all multimedia framework (data) ii libmlt6 0.9.0-3 amd64 multimedia framework (runtime) Claus -- Claus R. F. Overbeck Geschäftsführer Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 USt.-IdNr.: DE291391750 |
From: Brian M. <co...@br...> - 2014-09-17 16:49:32
|
>> Minimally, make sure that your installed MLT version is 0.90 or newer. > I got 0.9.0-3 : > dpkg -l | grep -i mlt > ii libmlt++3 0.9.0-3 amd64 MLT multimedia framework C++ > wrapper (runtime) > ii libmlt-data 0.9.0-3 all multimedia framework (data) > ii libmlt6 0.9.0-3 amd64 multimedia framework (runtime) My next piece of advice would be to try the daily build or the unstable package. Maybe there is something wrong with the sunab 0.90 package (I have some suspicion since the date was wrong). ~Brian |
From: Claus R. F. O. <cla...@ab...> - 2014-09-17 19:55:47
|
On 17.09.2014 18:49, Brian Matherly wrote: >>> Minimally, make sure that your installed MLT version is 0.90 or newer. >> I got 0.9.0-3 : >> dpkg -l | grep -i mlt >> ii libmlt++3 0.9.0-3 amd64 MLT multimedia framework C++ >> wrapper (runtime) >> ii libmlt-data 0.9.0-3 all multimedia framework (data) >> ii libmlt6 0.9.0-3 amd64 multimedia framework (runtime) > > My next piece of advice would be to try the daily build or the unstable > package. Maybe there is something wrong with the sunab 0.90 package (I > have some suspicion since the date was wrong). Hi Brian, thanks for your help! The problem seems to be fixed in the latest daily build! Claus -- Claus R. F. Overbeck Geschäftsführer Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 USt.-IdNr.: DE291391750 |
From: Claus R. F. O. <cla...@ab...> - 2014-02-20 08:29:56
|
On 20.02.2014 07:30, Dan Dennedy wrote: > 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. THANK YOU! Thank you for taking the time to look into this! This works, the blinking is gone and I am a really happy user :-) As I am no expert on colorspaces (I know what they are, but not all the details and implications): Is there any downside to using this workaround? Thanks! Claus -- Abovo-IT UG (haftungsbeschränkt) Zeisigweg 41 52146 Würselen Germany Geschäftsführer: Claus R. F. Overbeck Phone: +49 2405-4074455 Amtsgericht Aachen HRB 18473 |
From: Steinar H. G. <sgu...@bi...> - 2014-02-20 09:38:44
|
On Thu, Feb 20, 2014 at 09:28:12AM +0100, Claus R. F. Overbeck wrote: > As I am no expert on colorspaces (I know what they are, but not all the > details and implications): Is there any downside to using this workaround? Yes; your colors will be subtly off if you show them on anything that expects Rec. 709 or sRGB primaries, which means almost any modern HDTV or computer monitor (although YMMV here, especially if your project is not in HD to begin with). /* Steinar */ -- Homepage: http://www.sesse.net/ |