[FFmpeg-devel] lavfi state of affairs

[Vitor Sessak]

Michael Niedermayer wrote:
> On Sat, Feb 07, 2009 at 09:13:11AM +0100, Vitor Sessak wrote:
>> 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 .
> 
> could you please use unambigous command lines that do not depend on
> automatcally inserted scale filters!

Ok, I gave a look at it and looks like either Bobby misunderstood the 
swscale API when writing vf_scale.c or the swscale do not work very well 
with slices. If the assumptions of vf_scale.c are correct, the following 
patch should work, but it fails for any sample that uses swscale. What 
would be the right way to call swscale twice in ffmpeg.c to cut the 
scaling in two slices?

-Vitor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: broken.diff
Type: text/x-diff
Size: 850 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090207/98f9df9e/attachment.diff>