[MPlayer-cvslog] r27822 - trunk/libmpcodecs/vf_palette.c

Uoti Urpala uoti.urpala at pp1.inet.fi
Mon Oct 27 15:05:53 CET 2008


On Mon, 2008-10-27 at 13:21 +0100, Michael Niedermayer wrote:
> On Sun, Oct 26, 2008 at 02:19:30PM +0200, Uoti Urpala wrote:
> > On Sun, 2008-10-26 at 12:54 +0100, Michael Niedermayer wrote:
> > > On Sat, Oct 25, 2008 at 02:07:59AM +0200, uau wrote:
> > > > vf_palette: Fix compilation after libswscale API changes
> > > > 
> > > > Patch from Guillaume Poirier. 
> > > 
> > > > I didn't test the functionality of the
> > > > filter but at least it fixes compilation.
> > > 
> > > right, dont bother, just commit the first best change that makes things
> > > compile. Who needs working code anyway ...
> > 
> > Making the whole MPlayer compile is a lot more important than the
> > functionality of a little used filter. Even if it it was known _not_ to
> > work correctly fixing compilation would still take priority.
> 
> i agree but why in gods f* sake could you not simply have attempted to
> asked/waited for someone who knows the code?

Because then compilation would have been broken longer. I could have
waited for someone else to check the patch or read enough of the code to
verify its correctness myself. But that would have had the significant
downside of leaving compilation broken longer and not have had any
significant advantages.

> Or if not (or the hypothetical case of noone awnsering) at least have
> put a printf/mp_msg() in there saying that the code might not be correct.
> 
> As it is (if it would be left that way) someone might eventually spend alot
> of time debuging a "wrong color" bug.

I doubt a printf would speed up debugging much. And most of the filters
I've looked at have some questionable parts that would deserve "might
not be correct" tags...

> > Feel free to test the functionality of the filter as much as you like.
> > My actions were still better than those of any developer who left
> > compilation broken, which includes you. So your flaming is misguided.
> 
> Sorry but i was not aware of the swscale change breaking compilation
> before i saw your commit. Had you attempted to contact me or waited until
> ive read mplayer-dev i would have fixed it properly.

You still can create a version that uses swscale correctly according to
whatever API you want it to have. I don't believe that my commit makes
that any more difficult. But palette support is not important enough to
leave the rest of MPlayer waiting while it's being worked on.




More information about the MPlayer-cvslog mailing list