On Tue, Oct 30, 2018 at 3:54 PM Daniil V. Kolpakov <d...@progmeistars.lv> wrote:
> Hello! I was told on the kdenlive mailing list that I might have better > luck asking this on mlt-devel. > > I'm using the latest Kdenlive/mlt on Arch Linux. > > I've found that adding a color channel mixer effect, even with default > settings, changes pixel values to broadcast range (16-235). Adding > another Colorchannelmixer on top of it compresses the levels further to > 28-223, and so on. I've tried ticking the "full range" on the clip, but > it makes no influence. I wonder how it's meant to be used? That is an override to indicate the clip uses full range in case of missed signaling or detectiion. > What is the > general approach? Am I missing something? Is it a bug? As far as I > understood, Colorchannel mixer is an ffmpeg effect. > > I reproduced it. This is a bug in the MLT libavfilter adapter due to limitations between FFmpeg and MLT, but the colorchannelmixer is one of the rare avfilters that only operates in RGB, which is when this problem appears. The limitations are MLT does not support the yuvj422p pixel format, and FFmpeg does not support yuvj422 (which MLT can support). As a result, this bug appears whenever the downstream MLT component requests a YUV image instead of RGB because libavfilter does a RGB to YUV conversion at MPEG (broadcast) ranges. Thus, a simple workaround is to add the frei0r squareblur (with size 0) after the colorchannelmixer. This has very low overhead. I do not have a code fix yet; I have to learn more about libavfilter.
_______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
