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

[Michael Niedermayer]

On Thu, Oct 01, 2009 at 01:00:16AM +0200, Stefano Sabatini wrote:
> Sorry for the slow reply.
[...]
> 2) the buffer obtained by the pad filter with get_video_buffer() is
> inverted and passed to the previous filter, as Vitor and IIUC Michael
> proposed (check the patch: fix-vflip-logic+vitor.patch).
> 
> Consider the filterchain: "crop=0:0:WIDTH:100, vflip"
> 
> In this scenario the crop filter will take the top 100 lines of the
> image in input.
> 
> 
> This is the picref received in input by vflip.c:get_video_buffer():
> 
>   [fig. 4]
> 
>  O----------+
>  | crop     |
>  |  area    |
>  |          |
>  v          |
>  +----------+
>  |          |
>  |          |
>  |          |
>  |          |
>  |          | 
>  |          |
>  +----------+
> 
> The vflip filter moves the origin to the bottom left corner of the
> input area, and inverts the linesizes, so this is what
> vf_crop.c:get_video_buffer() obtains:
> 
>    [fig. 5]
> 
>  .
>  .
>  .
>  +----------+
>  ^ crop     |
>  |  area    |
>  |          |
>  |          |
>  O----------+
>  |          |
>  |          |
>  |          |
>  |          |
>  |          | 
>  |          |
>  +----------+


i would have expected:

>  +----------+
>  |          |
>  |          |
>  |          |
>  |          |
>  |          |
>  |          |
>  |          |
>  |          |
>  |          | 
>  |          |
>  O----------+

about the crop area shown in your figs, i dont understand how the
get_video_buffer() code could even know about croping that is done
at later stages. As an example assume a cropdetect filter that analzes
the picture content and then crops the black borders, it could in no way
know about where and what to crop when allocating the buffers


[...]
> Maybe there is some way to avoid this constraint, but my question is
> if this is really worth to strive for such a solution which adds
> complexity to the system, especially considering that the only case
> where it seems to make sense to invert a picref is with the vflip
> filter.

i still dont see where the problem comes from, i dont end up with the
issue in my thought experiment ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20091001/0a196474/attachment.pgp>