[Ffmpeg-devel] more libswscale questions....

Luca Abeni lucabe72
Thu Nov 16 13:12:35 CET 2006


Hi Steven,

On Thu, 2006-11-16 at 21:51 +1100, Steven Johnson wrote:
> Hi,
> 
> The more i muck with libswscale, the more questions I have.
Yes, it happens to me too ;-)

> Q1,
> When I was messing with imgresample, it seemed quite straight forward.
> If there was a way to convert from Format X to Y, through W, it just
> worked, It wasn't necessary to have a Format X to Y converter for every
> permutation.  For example:
> 
> If I want to convert YCrCb 422 to PAL8, it goes YCrCb 422 -> RGB32 ->
> PAL8.  All that is required is that YCrCb 422 can be converted to RGB32
> and RGB32 can be converted to PAL8. (This may not be the exact set of
> steps, but it is the idea I got from the code when I was playing with it).
> 
> But it seems if I want to convert from X to Y using libswscale, then
> there needs to be a converter for every possible permutation.  Is that
> correct?
I still have to understand all the libswscale internals (so, I apologize
in advance if my answer to your question is imprecise, or wrong, or I
misunderstand something), but my undestanding is that you do not need a
converter for every permutation. You can provide a "direct" converter
from format X to format Y to speed up the conversion, but that's just an
optimization.

My understanding is that if no "direct converter" from X to Y exists,
then libswscale does X ---> YUV420 ---> Y. So, for every supported
format you just have to provideo a converter to and from YUV420 (all the
other converters will just be optimizations).

> Q2,
> When it comes to scaling, how does the image end up in the format the
> scaling code uses, and how does it go from there to the dest format.  I
> tried tracking the code, but I can;t work out the path.
I think the YUV420 format is internally used (as said above), and I
think the X ---> YUV420 is done by the hcscale() and hyscale() functions
called by swScale, by using the *ToUV() functions (all these functions
are in swscale_template.c. After that, swScale() takes care of the
YUV420 ---> Y conversion by calling the yuv2*() functions (starting from
line 3179 of swscale_template.c).

> Eg, I want to go from RGB24 to BGR32 and scale the image from 1024x768
> down to 320x200.  How does libswscale convert from RGB24 -> YV12 ->
> Scaled YV12 -> BGR32?  It seems for the src I need to add the format to
> hcscale an hyscale?
I think RGB24  is already supported in hyscale/hcscale, no?

>  Is that correct?  But it seems the dest is always YV12?
My impression is that the conversion to RGB* is handled in swScale(),
starting from line 3215

> In my example here, where is the scaled YV12 converted to BGR32 in imgresample?
AFAIK img_resample() only works with YUV420. So, you have to explicitly
call img_convert() from RGB24 to YUV420 before rescaling, and you have
to call img_convert() from YUV420 to BGR32 after rescaling (see the
sws_scale() emulation code I wrote in imgresample.c

> Q3,
> I am wondering if the lack of horizontal and vertical resolution in YV12
> is the culprit for the blockiness I am experiencing?  Is there a HQ
> setting for libswscale, so the U and V channels have full resolution, to
> maintain image quality equivalent to imgresample?
In ffmpeg.c, sws_flags is always set to SWS_BICUBIC. Try to play with
this value, and you probably will be able to have better quality (sorry,
I have no suggestions about possible values for sws_flags... Maybe
someone else can comment on this)


			Thanks,
				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !





More information about the ffmpeg-devel mailing list