[FFmpeg-user] Strange results with delogo filter, maybe a bug

[Moritz Barsnick]

Hi James,

On Tue, Aug 26, 2014 at 12:43:53 +0200, James Darnley wrote:
> Did you try adding yuvj420p?  What about the other yuvj* "colourspaces"?

I didn't try, but I reckoned that if the target format PNG implies
non-YUV colorspaces (does it?) and RGB24 is quite common (is it?),
there would be a conversion from yuvj420p -> rbg24 somewhere along the
way in the chain anyway.

But indeed there's no obvious reason for me to omit those.

> I'm not familiar the filter at all but using interleaved RGB data could
> be very wrong if it treats neighbouring samples as separate pixels.

That's why I noted that I have no idea what I am doing. ;-)

Indeed, now I tried adding those AV_PIX_FMTs to the delogo source as
well. The "scaler" is now auto-inserted behind delogo with this log:

[auto-inserted scaler 0 @ 0xb3db7e0] w:854 h:480 fmt:yuvj420p sar:1/1 -> w:854 h:480 fmt:rgb24 sar:1/1 flags:0x4

Using the delogo filter (with w=0:h=0), the result of these conversions
is still identical whether the filter uses yuvj420p or rgb24.

By the way, trying this hint with the original unhacked filter:

https://trac.ffmpeg.org/ticket/225#comment:9

> A way to skirt this "problem", which I don't know if it is one
> actually, is to use the option
>
>   -vf mp=eq=0:0
>
> It's an equaliser filter used to adjust brightness and contrast
> ported from mplayer.
> As you can see it does no modification to the values of contrast and
> brightness but helps leaving untouched the pixel values range.

did not help with the result. (This was an attempt to find a way to
preserve the contrast despite the colorspace conversion, regardless of
the delogo filter "hack".)

Moritz