Question about swscale

[koliva]

Hi all,

I am currently using swscale to convert my RGB frames to YUV420 frames. Here is my code part:

As you see, the input width&height is the same as output width&height in sws_getContext function. This means that I don't do any scaling at all. However, I see a problem with 1 pixel wide lines on the screen. If I use SWS_POINT, I see that, for example, 1 pixel red line goes to black if I move the line bit by bit. However, I don't see this effect that much if I use SWS_FAST_BILINEAR. Could you please verify my if SWS_FAST_BILINEAR or SWS_POINT are the algorithms for the scaler? Since I am doing no scaling here, why do I see change?

I know, I see these effects just because of 420 format but could you please tell me if there is a way of getting rid of it completely?

[paradoxical]

You have the parameters right. It may just be a side effect from the chroma downscaling based on how those two filters work different. I really doubt there is anything you can do other than maybe try to shift the chroma. *shrug*

[Dark Shikari]

RGB->4:2:0 YUV requires chroma downscaling -- just because the resolution isn't being changed doesn't mean there's no scaling.

RGB->4:4:4 YUV doesn't require downscaling.

[xooyoozoo]

swscale's color conversions have been "known" to have idiosyncrasies for a while now. I solved most of my own issues (at least with ffmpeg's swscale) following a helpful tip (http://cbloomrants.blogspot.com/2010/10/10-14-10-image-comparison-part-2.html?showComment=1287261207381#c2478219315443609932) Charles Bloom wrote: add -sws_flags +accurate_rnd+full_chroma_int and maybe throw in +full_chroma_inp or +bicubic where necessary.

The above might or might not deal with your issue, but if you're especially concerned about this, there's always other ways to subsample: Hyperluma (http://ronja.twibright.com/hyperluma.php). However, you're gonna have to modify that code to suit your own needs.