[FFmpeg-devel] lavfi state of affairs

[Vitor Sessak]

Stefano Sabatini wrote:
> On date Friday 2009-02-06 01:24:34 +0100, Michael Niedermayer encoded:
>> On Thu, Feb 05, 2009 at 11:57:42PM +0100, Stefano Sabatini wrote:
>>> On date Thursday 2009-02-05 14:28:05 -0800, Baptiste Coudurier encoded:
>>>> On 2/5/2009 2:02 PM, Michael Niedermayer wrote:
>>>>> On Thu, Feb 05, 2009 at 12:36:55PM -0800, Baptiste Coudurier wrote:
>>> [...]
>>>>>> 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 ?
>>> Well, one of the problem is that currently in libavfilter-soc it's not
>>> possible to select the sws_scale flags (which is possible in the
>>> official SVN), furthermore is not possible to set the other swscale
>>> context parameters as well.
>>>
>>> One of the side-effects of this is that regression tests don't pass in
>>> libavfilter-soc, but the problem here is that we need to find some way
>>> to specify the swscale parameters (flags + filter vectors + whatever)
>>> in the command line then pass them to the vf_scale filter.
>> hmm, i see now that AVOptions with sws is slightly unpretty, it seems i didnt
>> realize this previously, ill look at your patch (i think there was one)
>> itmight not have been that bad ...
>>
>> to make AVOptions work nicer the sws init should possibly be split so
>> that the context is allocated then the user (via AVOptions) has a chance
>> to set various values and then the actual init is done.
> 
> Yes, maybe something like:
> 
> struct SwsContext *sws = sws_allocContext();
> 
> /* fill the context with AVOptions... */
> 
> sws->flags = ...;
> 
> if (sws_initContext(sws) < 0)
>    failed...
> else
>    ...
> 
>>> Then I stumbled across libswscale and I'm still there (I even have a
>>> documentation patch for it, but I don't want to post it before to have
>>> a better grasp of it).
>>>
>>> Related thread:
>>> http://thread.gmane.org/20090122230630.GC621 at geppetto
>>>
>>> Another big problem which I already mentioned in this thread is that
>>> slicification doesn't work when converting the format, for example:
>>> ffplay -f video4linux /dev/video -s 640x480 -vfilters  "slicify=16, format=rgb32"
>> try with and without scaling do both fail? does rgb32 outputfail for all
>> input pixfmts?
> 
> Yes I tried with all the input formats and output formats, the only
> one which seems to work is yuv420p.
 >
> Also things like this seems not to work
> ffplay -f video4linux /dev/video -vfilters  "format=rgb32, slicify=32, format=rgb32"
> ffplay -f video4linux /dev/video -vfilters  "format=rgb32, slicify=32, scale=160:120, format=rgb32"
> ffplay -f video4linux /dev/video -vfilters  "format=rgb32, scale=160:120, slicify=32, format=rgb32"

The problem is not with slicify filter but with the scale filter. You 
forget the when you write

ffplay -f video4linux /dev/video -vfilters  "format=rgb32, slicify=32, 
format=rgb32"

your actual filter is either

input -> format -> slificy -> format -> output

or

input -> format -> slificy -> format -> format -> output

where the second format was added to feed the output the right pixfmt. 
Also, if you try any of the following:

-vfilters "format=gray,slicify=32, format=gray, fifo"
-vfilters "format=rgb24,slicify=32, format=rgb24, fifo"
-vfilters "format=rgb32,slicify=32, format=rgb32, fifo"

(where fifo pratically does the inverse of slicifying), it works. So it 
means that the slicify works fine for several formats. The problem shows 
up if you do

  -vfilters "format=PIXFMT1,slicify=32, format=PIXFMT2, fifo"

where PIXFMT1 and PIXFMT2 are two different pixfmts. For me this shows 
that the problem is that the scale filter do not work with slices. See 
also 
http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2008-February/002597.html .

-Vitor