[FFmpeg-devel] lavfi state of affairs

Vitor Sessak vitor1001
Sun Feb 8 13:39:02 CET 2009

Michael Niedermayer wrote:
> On Sat, Feb 07, 2009 at 07:19:17PM +0100, Vitor Sessak wrote:
>> 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
>> Index: ffmpeg.c
>> ===================================================================
>> --- ffmpeg.c	(revision 16968)
>> +++ ffmpeg.c	(working copy)
>> @@ -918,7 +918,9 @@
>>          padding_src = NULL;
>>          final_picture = &ost->pict_tmp;
>>          sws_scale(ost->img_resample_ctx, formatted_picture->data, formatted_picture->linesize,
>> -              0, ost->resample_height, resampling_dst->data, resampling_dst->linesize);
>> +              0, ost->resample_height/2, resampling_dst->data, resampling_dst->linesize);
>> +        sws_scale(ost->img_resample_ctx, formatted_picture->data, formatted_picture->linesize,
>> +              ost->resample_height/2, ost->resample_height, resampling_dst->data, resampling_dst->linesize);
> this looks broken in many ways
> first the data pointers just dont point to the slices ...
> second srcSliceH is the height of the slice and thus the sum of this values
> must equal the picture height not be larger IIRC
> also dont forget that resampling causes input and output slices borders to
> shift as line X output needs X-i .. X+i input in some cases (not an issue
> here but may be in other cases

Ok, I've got a patch that works fine for almost all formats. The only 
problems I had was when converting to/from YUV410, GRAY8 or PAL8 and I 
really don't understand why. To test, since I know that vf_scale works 
fine for non-sliced data, I use

ffmpeg -i in.avi -vfilters "format=rgb32, scale=256:256,format=rgb32, 
fifo,slicify=128, format=yuv410p, fifo" out.avi

Where the idea is to test the sliced conversion of RGB32 -> YUV410p 
using a 256x256 frame.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vf_scale.diff
Type: text/x-diff
Size: 1174 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090208/e66e648b/attachment.diff>

More information about the ffmpeg-devel mailing list