[FFmpeg-devel] lavfi state of affairs

[Michael Niedermayer]

On Thu, Feb 05, 2009 at 02:28:05PM -0800, Baptiste Coudurier wrote:
> On 2/5/2009 2:02 PM, Michael Niedermayer wrote:
> > 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" ?
> 
> Yes, a little, however you are pushing for something some people don't 
> want to do, otherwise imgconvert would have been dropped.

iam pushing away from 2 (redundant) scalers ...


> 
> It's a bit like honoring the latest comment in a patch review.
> 
> > 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.
> 
> Here some people disagree. Look at the mess which happened when != s16 
> resampling feature happened. People patched in their own corner, I even 
> did, however I'm dedicated to FFmpeg so I submited the patch as soon as 
> I could. Did you see someone jump in ?

hmm, you have a point here


> 
>  >>> [...]
>  >>>
> >>> 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
> 
> Don't get me wrong, I'm not asking for specific routines to be 
> "schoolbook" like, what I'd like is to have the common code clean and 
> simple.
> 
> Like a neat func pointer array, with simple selection based on 
> architecture.

/me points to an empty area with one brick ehm i mean gsoc


> 
>  >> [...]
>  >>
> >> Also libswscale does not support palette output, this makes GIF encoder
> >> _useless_.
> >
> > swscale supports 4bit and 8bit palette output with a fixed palette
> 
> Huh ? PAL8 is not mentioned in isSupportedOut(). Is this a mistake ?

yes and no
PAL8 in sws means generic PAL8 with arbitrary palette or maybe optimized
by sws palette, neither we support.
fixed palette that imgconvert calls pal8 is bgr8/rgb8 but with a different
palette than imgconvert (swss is simpler to quantize to)


> 
> > 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
> 
> This is true if you say so.
> 
> > and gif.c has the imgconvert palette hardcoded. Which id say is not such
> > a bright idea ...
> 
> ?? Not libavcodec/gif.c definitely.

static const rgb_triplet gif_clut[216]
gif_clut_index() in gif.c, duplicated in libavcodec/imgconvert.c so
technically it doesnt use code from gif.c but ohh well ...
and static void glue(RGB_NAME, _to_pal8)() from 
libavcodec/imgconvert_template.c then uses it


> 
>  >> [...]
>  >>
> >> 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 ...
> 
> Robert knows it.

/me casts a look at an agent nearby who nods, checks his gun and leaves ...


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20090206/e6448f13/attachment.pgp>