[FFmpeg-devel] [PATCH] libavfilter-soc: implement pad filter

[Stefano Sabatini]

On date Monday 2009-07-27 06:15:47 +0200, Vitor Sessak encoded:
> Stefano Sabatini wrote:
[...]
>> Now I'm posting other patches, what I'd like to discuss are these two
>> points:
>>
>> * I tried both to put the information required for padding (x, y, h,
>>   w, exp_h, exp_w) in the link and pass it in the get_video_buffer()
>>   params, they're pretty equivalent but the second method (as in the
>>   patch) seems more flexible, as the information is not stored
>>   statically in the links, so it doesn't need a reconfiguration when
>>   changing it.  (BTW maybe we can as well remove w/h from the link,
>>   that should make simpler to implement variable size filters, I still
>>   have to experiment with this).
>
> Just a question: does it works when linesize is negative?

I believe that should work (not 100% sure though, I shuld double-check
it), note that the vflip filter as it is currently doesn't work for
another reason.

>> * I tinkered about the vflip problem much time, and I could'nt find 
>> some   way to keep the previous behavior with the new system.
>>   The new system assumes that the position of the area to pad
>>   (referred by the x/y params in the picref) needs to be invariant
>>   when passing a picref to the next filter.
>>   That's because the pad filter expects this:
>>
>> static void start_frame(AVFilterLink *link, AVFilterPicRef *picref)
>> {
>>     PadContext *pad = link->dst->priv;
>>     AVFilterPicRef *ref2 = avfilter_ref_pic(picref, ~0);
>>     link->dst->outputs[0]->outpic = ref2;
>>
>>     ref2->data[0] -=  pad->x             + (pad->y * ref2->linesize[0]);
>>     ref2->data[1] -= (pad->x>>pad->hsub) + (pad->y * ref2->linesize[1]>>pad->vsub);
>>     ref2->data[2] -= (pad->x>>pad->hsub) + (pad->y * ref2->linesize[2]>>pad->vsub);
>>     if (ref2->data[3])
>>         ref2->data[3] -= pad->x + pad->y * ref2->linesize[3];
>>     ref2->x -= pad->x;
>>     ref2->y -= pad->y;
>>     ref2->w = pad->out_w;
>>     ref2->h = pad->out_h;
>>
>>     avfilter_start_frame(link->dst->outputs[0], ref2);
>> }
>>
>> to work.
>
> Unless I'm misunderstanding something, this forbids, for ex., chainning  
> two pad filters. Am I right?

Of course padding/cropping chaining is supported, that was a
prerequisite for it to be acceptable, so let me clarify the problem.

The pad filter takes in input a video buffer, and knows that it is
offeset with respect to the area when it has to write.
So we have:

            [exp_w, exp_h]
+--------------------------------------+
|                                      |       
|  (padx, pady)                        |
|    +------------------------+        |
|    |                        |        |
|    |        [w, h]          |        |
|    |                        |        |
|    +------------------------+        |
+--------------------------------------+

It assumes that the data in the passed reference of the video buffer
points to the top-left corner of the internal area of the padded area,
and so it "moves back" in the new video buffer reference the pointers
to the buffer, so they point to the top-left corner of the padded
area.

The vflip filter on the other hand, puts in the passed buffer
reference the pointers to the bottom-left corner of the input buffer,
and invert the linesizes, which is not what the pad filter assumes.
Negative linesizes shouldn't be a problem, the problem would be with
the pady value which should be changed (also for all the following pad
filters).

Now I'm thinking about the possibility to convey this simple
information to the pad filters (maybe an additional flag?) but that
looks rather inelegant, and I wonder if this is worth the complexity
it demands.

Thanks for the reply, regards.
-- 
FFmpeg = Frightening & Fast Multimedia Philosophical Efficient Glue