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

[Michael Niedermayer]

seems iam a little late with replying :)

On Sun, Jul 19, 2009 at 01:17:09AM +0200, Stefano Sabatini wrote:
> On date Thursday 2009-07-16 01:59:37 +0200, Michael Niedermayer encoded:
> > On Thu, Jul 16, 2009 at 12:49:21AM +0200, Stefano Sabatini wrote:
> > > On date Wednesday 2009-07-15 01:03:12 +0200, Stefano Sabatini encoded:
> > > [...]
> > > > I changed the logic of the patches, now the buffer informations are
> > > > stored in the link rather than in the params.
> > > > 
> > > > This allows for simpler API usage, also makes it possible crop/pad
> > > > chains which caused troubles before. I'll provide a better explanation
> > > > with a further patchset, since these ones need to be cleaned up
> > > > /fixed.
> > > > 
> > > > Since the last version:
> > > > * fixed ffmpeg.c
> > > > * fixed hflip
> > > > 
> > > > Yet to come:
> > > > * fix vflip
> > > > * fix for leaks?
> > > > * add a regression test
> > > > * direct rendering is not implemented, it would be better to post it
> > > >   as a separate patchset since this is hard enough
> > > 
> > > I added a pix_fmt field to the get_video_buffer, as this information
> > > is not known in the links (i.e. when configuring the chain).
> 
> That wasn't true, my mind was obfuscated when I conceived that thing.

honestly quite a bit of this thread sounds a little foggy ...


> 
> > > Also added a regression test for the pad.
> > > 
> > > > I also suspect the exp_w, exp_h, x, y params in the picref are not really
> > > > required.
> > > 
> > > Patches updated.
> > 
> > would it be possible to split that stuff up a little?
> > (self contained changes with explanations of why its done as is done and
> >  so on)
> > 
> > that is assuming you want this reviewed ...
> 
> Uhm, no the patches were not still ready for review but I wanted
> backup / share my progress in the meaningwhile.
> 
> 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.  

yes


>   (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).

maybe


> 
> * 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:

i really honestly must admit that i couldnt figure out after a quick read of
the mails what problem you have with vflip, maybe thats because there should
be no problem ...

let me explain my view, maybe you could tell me where iam wrong or where you
think there is a problem

in an abstract view the filters pass get_video_buffer calls in one direction
and various calls to draw into the image in the other direction.

a vflip filter can surely flip the reference it gets from get_video_buffer()

to the right of vflip

0--------------------------------
T
v-L-->0-----w------>
      hXXXXXXXXXXXXX
      vXXXXXXXXXXXXX


---------------------------------
----linesize--------------------->

between pad and vflip

---------------------------------

      AXXXXXXXXXXXXX
      hXXXXXXXXXXXXX
A-L-->0-----w------>
T
|
0--------------------------------
<----linesize--------------------

left of pad (padding at the top)

---------------------------------

      hXXXXXXXXXXXXX
A-L-->0-----w------>
|
T
|
0--------------------------------
<----linesize--------------------

and for drawing instead of get_video_buffer its the exact reverse

i see no problem

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/20090917/91483313/attachment.pgp>