[FFmpeg-devel] lavfi state of affairs
Sat Feb 7 09:13:11 CET 2009
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)
>>> 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,
your actual filter is either
input -> format -> slificy -> format -> output
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
More information about the ffmpeg-devel