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

[Michael Niedermayer]

On Sat, Oct 03, 2009 at 01:24:12PM +0200, Stefano Sabatini wrote:
> 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.

my example of width+= pad works in this case, you would allocate a larger
than needed buffer but it should work. basically you would allocate
a padded source filter area ignoring the crop 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.

it shouldnt be too hard to add printf() to find out what it does ...


> 
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20091003/0dc610ef/attachment.pgp>