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

Stefano Sabatini stefano.sabatini-lala
Sat Oct 3 13:24:12 CEST 2009


On date Saturday 2009-10-03 03:58:05 +0200, Michael Niedermayer encoded:
[...]
> thus to summarize, (please correct me if iam wrong)
> * there is NO problem in the current system and vflip
> * you added parameters to your private get_video_buffer() that break vflip
> * i am not aware of why these parameters would be needed or usefull
> * mplayer can do direct rendering, copyless vflip, pad and crop.

What I'm trying to solve is the following problem.

Consider this filterchain:
crop, pad


+----------------------------------+ - - +
|                                  |     |
|        source filter             |
|        area                      |     |
|                +-----------------+-----+
|                | pad area        |     |
|                |                 |     |
|                |    +------------+     |
|                |    |            |     |
|                |    |    crop    |     |
|                |    |    area    |     |
+----------------|----+------------+     |
                 |                       |
|                |                       |
                 |                       |
|                |                       |
+- - - - - - -  -+-----------------------+

When I request the buffer for the pad filter I have to know the
relative position of the crop area, so the buffer finally requested by
the pad filter won't simply be the cropped area + padding area, but it
will contain also the source filter area.

I addresses this problem passing the position of the write area of the
filter to the next filter, which works quite well but it has still
problems with vflip, as this cannot perform the correct inversion with
respect to the allocated area, as it doesn't know which are the
dimensions of the returned allocated big-buffer.

As I already told this problem could be solved, simply retrieving that
information and passing it in the returned picref.

Now libmpcodecs solves the problem without the need to pass these
parameters from one filter to the next one, and it looks to work well
with the vflip filter too, so I tend to believe that the solution I
conceived is not the simplest one.

I tried to figure out how libmpcodecs addresses this problem, but
every time I look at that code my eyes twist and my head spins.

If someone can give some advice on how libmpcodecs addresses this
problem I'd be grateful, otherwise I'll try again to figure it out
myself.

Regards.
--
FFmpeg = Faithful & Foolish Minimal Problematic Ecstatic Governor



More information about the ffmpeg-devel mailing list