[FFmpeg-devel] [PATCH] make img_convert symbol conditional on lavc version, not libswscale
Sat Jul 5 22:51:35 CEST 2008
On Sat, Jul 05, 2008 at 07:07:07PM +0200, Michael Niedermayer wrote:
> On Sat, Jul 05, 2008 at 03:32:49PM +0200, Diego Biurrun wrote:
> > Somehow I fail to see what exactly the problem with my patch is.
> Ive said it a few times already, I like to spend my time moving ffmpeg
> forward, these patches do not move us forward. And neither do they
> move applications using ffmpeg forward.
> They rather make a case that should not be used more useable.
> If someone wants this, he can review and maintain these #if 0 patches and
> apply them, i will NOT spend a day reviewing the scalers and the code
> using them to check if these hacks might work.
> The reason is simply that i could make ffmpeg with the regresson tests fully
> functional with the new scaler in the same time. And then drop the old
Very well. Then let us move forward and drop the old scaler. The
current unclear situation is not helping anyone and the new scaler is
not receiving the attention it could receive.
> > Right now we *do* have a problem. The problem is in our code, not in
> > some distro tree.
> And there are many solutions:
> * remove the old scaler with a version bump
> * mark --enable-swscale as experimental and not for production use
> * bump the version when --enable-swscale is used.
> If we really want to allow both scalers to be enabled we at least need
> someone reviewing the scalers and code using them to ensure they dont
> conflict. Noone seems to volunteer so what is it that you want?
> That i should NOT fix all remaioning issues in the new scaler but rather
> figure out a way to make the old scaler (slow) and the new (half working)
> scaler supported at the same time?
I vote for removing the old scaler. Distros can make legacy FFmpeg
packages for legacy applications that require the old scaler.
I'm sure that the new scaler will get plenty of attention if the
More information about the ffmpeg-devel