[FFmpeg-devel] lavfi state of affairs

[Michael Niedermayer]

On Thu, Feb 05, 2009 at 12:36:55PM -0800, Baptiste Coudurier wrote:
> Hi Michael,
> 
> On 2/5/2009 12:21 PM, Michael Niedermayer wrote:
> > On Thu, Feb 05, 2009 at 08:48:08PM +0100, Stefano Sabatini wrote:
> >> On date Tuesday 2009-02-03 13:57:47 +0100, Diego Biurrun encoded:
> >>> On Tue, Feb 03, 2009 at 10:52:20AM +0100, Benjamin Larsson wrote:
> >>>> Reinhard Tartler wrote:
> >>>>> Benjamin Larsson<banan at ludd.ltu.se>  writes:
> >>>>>
> >>>>>>> you have my approval to drop/disable/svn rm vhook
> >>>>>>>
> >>>>>> As suggested in another thread can we do that after the upcoming release ?
> >>>>> better drop it before the release. Otherwise user might actually use
> >>>>> that feature...
> >>>> I don't really care my only argument is that there are users out there
> >>>> who still uses vhook. Giving them an official release where it was last
> >>>> supported/working could be nice.
> >>> I agree with Benjamin.  I'll add a note to the release notes that
> >>> mentions that vhook will go away immediately after the release.
> >> (Sorry to chime in just now, I had some (dis)connettivity problems in
> >> the last days...).
> >>
> >
> >> What about to drop VHOOK just after *all* its functionality is
> >> implemented in lavfi? That would be definitively nicer towards the
> >> users.
> >
> > iam VERY VERY VERY VERY strongly against this
> > that way we would in 5 years still not have half of vhook ported to lavfi
> >
> > look at swscale&  imgconvert/resample, NO-ONE is rewriting the few lines
> > of GPL code. If i would have ignored people and droped imgconvert/resample
> > someone would have rewriten that one file in less than a week.
> 
> Sorry but if _you_ want imgconvert dropped, _you_ have to make some 
> efforts too.

Dont you think its a little offensive to ask the one who probably spend more
efforts on sws than anyone else to make some effort "too" ?
Also i dont mind fixing technical issues and cleanliness ones, but i will
not rewrite the GPL code. There are people who want the yuv table generator
to be under LGPL, they can rewrite it but IMHO they should not block the
removial of cruft if they decide not to.
And i know you are an excelent developer, you could likely rewrite the darn
table generator in less than 2 hours.


> 
> > people arent crying "ohh no its just 99% LGPL please give us more time
> > to work on the 1%" there where in reality "ohh no its just 99% LGPL i
> > dont want to spend a day rewriting the 1%". But really the last is
> > that people do NOT want to rewrite it and they wont unless there is a
> > reason for them to.
> > I dont care about the license so i wont work on it others as well either
> > dont care or if they do care have no reason at all to do it as long as
> > the old code is still useable with svn.
> 
> I'll relaunch the flames but still, I know _many_ people thinking that 
> libswscale is a _mess_. IMHO if you want it adopted you have to make 
> some efforts toward this direction too, ie making libswscale cleaner and 
> easier to code in.

swscale is messy and cleanup is welcome but thats hardly a reason not
to remove imgconvert/resample which isnt any better.
Also you are comparing a very basic and slow schoolbook implementation
against a highly optimized one, its clear the schoolbook one is
easier to understand and looks cleaner

But then i guess you wouldnt want our FFT replaced by a schoolbook
fourier transform just because thats much easier to understand, and
work with? O(n^2) vs O(n log n) ...


> 
> Also libswscale does not support palette output, this makes GIF encoder 
> _useless_.

swscale supports 4bit and 8bit palette output with a fixed palette
imgconvert supportes 8bit with a fixed palette
swscale supports ordered dither providing MUCH higher quality over imgconvert
imgconvert uses only 216 of 256 colors, swscale uses all.
imgconvert does 6 divisions and modulo operations per pixel for pal8
output swscales does 0
and gif.c has the imgconvert palette hardcoded. Which id say is not such
a bright idea ...
besides imgconvert calls functions from gif.c (much cleaner design than
sws, which is selfcontained ;)


> Also IIRC there is problem on 64bits arch with rounding or 
> something like that.

i remember "something" too but as neither of us seem to remember it
exactly this isnt a good argument either way ...


> 
> Imgconvert is _complete_, simpler, easier to code on, albeit a lot slower.

sws is complete as well.
and imgconvert being easier to code on is simply because imgconvert has no
optimizations and supports no slices also it does not combine scaling and
convertion.


> 
> > The price though is payed by every devel as they have to deal with 2
> > scalers and soon 2 video filter APIs ...
> 
> The situation is different vhook is crap, lavfi is good.
> We need to do one thing in concept, _enable_ lavfi in ffmpeg and ffplay.

> I asked you several times what was needed to actually _do_ this.

cleanup the command line parsing code and submit a patch.


> 
> You keep saying that we must _drop_ vhook. I'd like a '+' not a '-' here.

i as well like a '+' but my experience says that a '+' only happens if there
is some incentive that makes people work and without the '-' there is not

another example would be the matroska demuxer in mplayer, it ended in the
same idiotic deadlock as swscale vs. the old scaler

Also the problem is that there are 2 scalers that cause work maintaining
and supporting to be split. A '-' of one would solve this.

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/ffmpeg-devel/attachments/20090205/c905f62e/attachment.pgp>