[Ffmpeg-devel] swscale.h in libavcodec and libswscale

[Luca Abeni]

Hi Diego,

On Mon, 2006-10-16 at 10:53 +0200, Diego Biurrun wrote:
> On Mon, Oct 16, 2006 at 10:07:33AM +0200, Luca Abeni wrote:
> > 
> > On Sun, 2006-10-15 at 19:38 +0200, Diego Biurrun wrote:
> > > We curently have two headers called swscale.h, one in libswscale and one
> > > in libavcodec.
> > Yes, I created libavcodec/swscale.h some time ago.
> > The fact is that now ffmpeg provides the swscale interface for image
> > rescaling / pixel format conversion even if libswscale is not compile.
> > This permits to have a consistent interface that can be used regardless
> > of the fact that --enable-swscaler has been configured or not.
> > 
> > In my opinion, this is not a problem: unless I am missing something, the
> > correct swscale.h is always included, and "make install" installs the
> > correct file. Of course, I might be wrong... Let me know, and I'll fix
> > the problem.
> 
> Yes, it works.  It's just the ugliness resulting from having two largely
> redundant subsystems ..
I see... And I agree. But unfortunately I did not find any better way to
address the problem (always using the "original" swscale.h did not
work... I do not remember the details).


[...]
> > > I can easily fix the warnings by adding -I$(SRC_PATH)/libswscale to
> > > CFLAGS before -I$(SRC_PATH)/libavcodec.
> > Did you configure with "--enable-swscaler"?
> > If yes, "-I$(SRC_PATH)/libswscale" should already be before "-I
> > $(SRC_PATH)/libavcodec" (at least, I think it was when I initially
> > committed the swscale support). 
> 
> Only in the top-level Makefile, not in any of the subdirectories.  vhook
> is a bit special in that it does not use common.mak in any case.
Opsss. I missed it, sorry about that... Anyway, I see that you already
fixed this problem :)

> > If not, then the warning is showing a real problem, and adding "-I
> > $(SRC_PATH)/libswscale" would just hide it (you would not see any
> > compilation warning, but the resulting .so file would reference a
> > non-existing function, and would be unusable). The real fix is to
> > implement 'sws_getCachedContext' in the swscale emulation. If noone
> > disagree with this statement, I'll provide a patch in few days.
> 
> OK
I see that someone else already noticed this problem... I hope to be
able to work on it this evening, and to post a patch tomorrow.

> > >   While it be removed eventually?
> > My idea is that it will be removed when swscale will become the default
> > (and --enable-swscaler will disappear). 
> 
> Are you planning to do this soon?  :)
I was planning to do this soon, but I've been distracted by other "real
life" issues, so it is taking longer than I expected :(

I think the last remaining issue with "--enable-swscale" is the
licensing... Or am I missing something else?
My plan is:
	1) Enable the compilation of non-SIMD code with LGPL
	2) Increase the proper version number (I have to check which 
          one :) so that user programs can detect if the swscale 
          interface is present
        3) After some time, enable swscale by default (changing 
          --enable-swscaler in --disable-swscaler)
        4) After some other time, remove --disable-swscaler

For point 1), I have a preliminary patch somewhere (I am going to
search, update, and test it again), and I thought I sent an email to all
the swscale authors asking for the permission to use non-SIMD code under
LGPL. But I find no trace of that email, so I probably pressed "cancel"
instead of "send" (or there has been some smtp problem, I do not know).
I'll send the email for real this evening.


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