[FFmpeg-devel] lavfi state of affairs
Michael Niedermayer
michaelni
Sun Feb 8 03:36:23 CET 2009
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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090208/3d729f48/attachment.pgp>
More information about the ffmpeg-devel
mailing list