On Thu, Jul 22, 2010 at 12:09 PM, Simon Eugster <simon.eu at gmail.com> wrote: > 2010/7/21 Dan Dennedy <dan at dennedy.org>: >> On Wed, Jul 21, 2010 at 12:16 PM, Simon Eugster <simon.eu at gmail.com> >> wrote: >>> 2010/7/21 Dan Dennedy <dan at dennedy.org>: >>>> On Wed, Jul 21, 2010 at 10:51 AM, Simon Eugster <simon.eu at gmail.com> >>>> wrote: >>>>> Dear friends, >>>>> >>>>> I've just added an RGB parade to kdenlive. While testing I found >>>>> something interesting: Although I'm painting on a rect with height 256 >>>>> (as atm we're dealing with 8 bits per channel only) and scaling the >>>>> parade afterwards to the target height, I got kind of scanlines. >>>>> Compare these two images: >>>>> http://granjow.net/uploads/kdenlive/kdenlive-mlt-rgbparade-noeffect.png >>>>> http://granjow.net/uploads/kdenlive/kdenlive-mlt-rgbparade-witheffect.png >>>>> With the MLT effect there are scanlines, without it there are none. >>>>> >>>>> This is quite interesting, as this visualizes how color information >>>>> gets lost when converting between different color spaces (according to >>>>> [1], MLT is using YUV422, the input image is RGB). >>>> >>>> It does not operate exclusively in YUV422. The color/image-format >>>> conversion implementation depends on your build and your version of >>>> libswscale (>= 0.7.2) whether MLT uses libswscale or inbuilt routines. >>>> Maybe the problem is in the composite transition. >>> >>> libswscale is at 0..6 here in debian sid. >> >> I do not believe that is correct. Maybe you are looking at a package >> version. What does 'ffmpeg -version' show as the libswscale version? > > Something different. > ?libswscale ? ? 0.11. 0 / ?0.11. 0 >
So your MLT should be using libswscale for colorspace and image format conversion as well as scaling. This is generally a good thing. -- +-DRD-+
