[Ffmpeg-devel] [PATCH] introduce swscale interface inlibavcodec
Thu Apr 6 01:36:09 CEST 2006
On Wed, Apr 05, 2006 at 12:32:12PM +0200, Luca Abeni wrote:
> 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?)
yes, its that simple ...
> 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?
sounds ok, i or attila will take care of step 1 as soon as the other things
seem to have reached "applyable" state
also dont forget mplayer, it should stay compileable too :)
though breakage for a short time (a few hours) isnt a problem and might
happen due to murphies law anyway with such a big move
In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is
More information about the ffmpeg-devel