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 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
