[Kdenlive-devel] Color spaces and MLT

Dan Dennedy dan at dennedy.org
Sat Jul 31 17:44:48 UTC 2010


On Sat, Jul 31, 2010 at 5:27 AM, Simon A. Eugster <simon.eu at gmail.com> wrote:
> On 22.07.2010 22:57, Dan Dennedy wrote:
>> 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.
>
> By the way, what happens when rendering to a file? If the input is in RGB,
> and no filters/effects operating in YUV only are put on top of it, will it
> remain RGB until being written to the output file?

Same thing happens regardless of output - it all depends. BTW,
sdl_preview as used by kdenlive is both RGB and YUV. I can not be any
more specific unless you are.

-- 
+-DRD-+




More information about the Kdenlive mailing list