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