[FFmpeg-devel] lavfi state of affairs
Michael Niedermayer
michaelni
Sun Feb 8 15:54:36 CET 2009
On Sun, Feb 08, 2009 at 01:39:02PM +0100, Vitor Sessak wrote:
> 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.
so it works if you remove slicify ?
anyway, its well possible this could be a bug in the scaler but i fear i
have no time to look into this any time soon, especially as you do not
provide the information i asked for. You dont even tell what "problem"
is.
If i have spare time for sws that would go into issues blocking the
imgconvert removial not into things that imgconvert/resample doesnt support
anyway
>
> -Vitor
> Index: vf_scale.c
> ===================================================================
> --- vf_scale.c (revision 4019)
> +++ vf_scale.c (working copy)
> @@ -133,10 +133,26 @@
> {
> ScaleContext *scale = link->dst->priv;
> int outH;
> + int vsub, hsub;
> + uint8_t *data[4];
>
> - outH = sws_scale(scale->sws, link->cur_pic->data, link->cur_pic->linesize,
> + avcodec_get_chroma_sub_sample(link->format, &hsub, &vsub);
> +
> + data[0] = link->cur_pic->data[0] + y * link->cur_pic->linesize[0];
> + data[3] = link->cur_pic->data[3] + y * link->cur_pic->linesize[3];
> +
> + if (link->format != PIX_FMT_PAL8) {
> + data[1] = link->cur_pic->data[1] + (y >> vsub) * link->cur_pic->linesize[1];
> + data[2] = link->cur_pic->data[2] + (y >> vsub) * link->cur_pic->linesize[2];
> + } else {
> + data[1] = link->cur_pic->data[1];
> + data[2] = link->cur_pic->data[2];
> + }
PAL8 is not the only format that has a palette
a simple link->cur_pic->data[2] == NULL check might work better
except that the patch looks good
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/3776c366/attachment.pgp>
More information about the ffmpeg-devel
mailing list