[Ffmpeg-devel] [PATCH] introduce swscale interface inlibavcodec

Luca Abeni lucabe72
Wed Apr 5 12:32:12 CEST 2006

Hi Michael,

On Wed, 2006-04-05 at 12:00 +0200, Michael Niedermayer wrote:
> > @@ -1494,8 +1495,8 @@ static int rgb2rgbWrapper(SwsContext *c,
> >  		case 0x83: conv= rgb15to32; break;
> >  		case 0x84: conv= rgb16to32; break;
> >  		case 0x86: conv= rgb24to32; break;
> > -		default: MSG_ERR("swScaler: internal error %s -> %s converter\n", 
> > -				 vo_format_name(srcFormat), vo_format_name(dstFormat)); break;
> > +		default: MSG_ERR("swScaler: internal error %d -> %d converter\n", 
> > +				 srcFormat, dstFormat); break;
> ideally we should use avcodec_get_pix_fmt_name here but that would add a
> dependany to lavc ...
Yes, that's the problem. The only solution I could think about is moving
avcodec_get_pix_fmt_name() to libavutil...
But we can address this problem later :)

> maybe duplicating the pix_fmt names table in the binary (use #include
> somehow to avoid duplication in the source) would be a solution?
> anyway IMHO leave a function which turns pix_fmt into a string even if it 
> just puts the integer value into it
Ah, ok. It seems I misunderstood you. So, the problem with
vo_format_name() was just the name of the function, right? I'll use
something like sws_format_name(). 

> anyway, except that patch looks ok ...
Good! So, we are almost ready for importing swscale :)

Now, the problem is how to do the import in practice.
Here is my proposal:
step 1: import the postproc subdir "as is" from mplayer. I think a
person with admin powers can do this preserving the history (at least, I
seem to remember seeing an admin moving a directory from a CVS
repository to another without loosing the history... But I do not know
what he did. Maybe he just copied all the *,v files?)
step 2: apply a cosmetic mega-patch removing all tabs and trailing
whitespaces from the imported directory (is this needed?)
step 3: apply libswscale.diff so that swscale is compilable in the
ffmpeg tree
step 4: apply the "configure and Makefile" part of the ffmpeg patch
(I'll split the patch), so that swscale compilation can be actually
step 5: apply the padding/cropping patchset, after I re-reviewed it (I
want to be really sure that it does not create troubles).

Does this sound like a good plan? Has anyone alternative ideas?

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

More information about the ffmpeg-devel mailing list