[FFmpeg-devel] lavfi state of affairs

[Baptiste Coudurier]

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.

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 ?

 >>> [...]
 >>>
>>> 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.

 >> [...]
 >>
>> 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 ?

> 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.

 >> [...]
 >>
>> 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.

>> Imgconvert is _complete_, simpler, easier to code on, albeit a lot slower.
>
> sws is complete as well.

Well, see PAL8. If it's a mistake, then yes.

> 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.

I do think that clean common code (init for example) with separated per 
arch files, also with consistent file names, not having like yuv422p to 
uyvy422 in rgb2rgb2_template.c, would seriously help.

Yes, I know I should do it if I want it...

>>> 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.

Okey this is constructive. Stefano can you comment on this ?

>> 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

Yes, and what you just said earlier will help people knowing what to _do_.

> 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.

imgconvert is not really maintained and nobody works on it since it is 
deprecated. Still it has been deprecated since a long time and nobody 
wants to work on it, so this means it satisfies everybody, right ?

I don't see much more people working on libswscale either.

Still I agree with you.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org