[MPlayer-dev-eng] [PATCH] fix undefined reference to `palette***

[Michael Niedermayer]

On Sun, Oct 26, 2008 at 05:36:44PM +0300, Andrew Savchenko wrote:
> Hi,
> 
> On Sunday 26 October 2008 16:26, Michael Niedermayer wrote:
> > On Fri, Oct 24, 2008 at 10:37:23PM +0200, Diego Biurrun wrote:
> > > On Thu, Oct 23, 2008 at 10:56:19PM +0200, Guillaume POIRIER 
> wrote:
> > > > Attached patch fixes undefined references due to the recent
> > > > changes in swscale.
> > > >
> > > > I'm not quite so sure that it's correct, but on the samples
> > > > I had on my machine, it seemed alright.
> > > >
> > > > Please have a look at it.
> > >
> > > Michael?  Compilation is currently broken...
> >
> > I belive the change is wrong and the code will fail on at least
> > some of big/little rgb/bgr32/24
> 
> It was reported this patch seems to works fine on x86_64 and x86. 
> At least I have no problems on my x86 box yet; maybe I'll 
> encounter them later.

That leaves one wondering what exactly "works fine" and what exactly
was tested.
Its not as if replacing functions that do something by functions that do
something else is going to work in all cases. And of course its possible
that RGB or BGR still works on little endian but i highly doubt both work.


> 
> > besides this, the true problem was caused by the direct use of
> > the rgb2rgb code. Had the swscaler been used directly no problem
> > would have happened.
> 
> If this code is broken, please be kind to provide samples to check 
> this or the way to generate them.

I have neither, i was just pointing at a problem in a patch nothing else.
If you have doubt about the code being broken you can just look at the change
in libswscale to confirm for yourself that the old and new functions do
something different.


> If you can fix this code, this 
> will be highly appreciated.

> *But* having broken, impossible to 
> compile code in prefer of possibly broken one is a really bad 
> idea, especially in the project claimed itself as "svn stable"; 
> IOW when it is highly recommended for users to use svn head 
> instead of releases, any svn revision should be at least 
> compilable and any possible fatal problems with build process 
> should be fixed ASAP.

yes, but one should not commit broken pathes to code one doesnt
even maintain or understand just to fix compilation.
The obvious solutions would have been
A. Complain to ffmpeg/libswscale about API breakage (we could then have
   discussed in how far this is part of the public API and what to do)
B. Disable vf_palette (has this filter any sense anymore anyway?)
C. make mplayer use a old libswscale

Its not as if a change in libmpeg2, libfaad, ... that breaks mplayer
would be dealt with by making mplayer use the new version and then
quickly commiting half tested code to fix compilation somehow.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081027/e7a2ed76/attachment.pgp>