[FFmpeg-devel] [PATCH] libavfilter-soc: implement pad filter
Michael Niedermayer
michaelni
Sat Oct 3 03:58:05 CEST 2009
On Sat, Oct 03, 2009 at 01:38:59AM +0200, Stefano Sabatini wrote:
> On date Thursday 2009-10-01 02:28:37 +0200, Michael Niedermayer encoded:
> > 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----------+
>
> So the correct solution would be to invert the reference of the
> *whole* allocated buffer.
>
> The problem is that the vflip filter, as well as all the other ones,
> has no idea of the bottom left corner of the allocated buffer. Maybe
> if the position of the returned buffer in the allocated buffer would
> be known (for example it could be stored in the picref itself) than it
> would be possible to perform the correct inversion.
>
> I'll try to give a try at this approach tomorrow.
>
> > 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
>
> Michael, with the actual architecture that wouldn't be even possible.
>
> The whole recursive get_video_buffer()+pad filter thing may work only
> if a filter can specify to the next filter *the exact area of the
> buffer it will use*, which is specified by the x, y, w, and h
> parameters which are passed to the get_video_buffer() function.
in svn:
AVFilterPicRef *(*get_video_buffer)(AVFilterLink *link, int perms);
more precissely no x,y,w,h
width & height clearly would have to be added, for others i dont know
you arent explaining things much and what you do try to explain i cant
make too much sense of ...
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.
>
> Indeed when the filter writes to the buffer, it has been already
> allocated, the best you can do in your scenario would be a 2-pass
> processing e.g.:
if its not possible to do this in 1pass, not even with extra memcopies
then i think thats a quite nasty limitation and id like to know where
this limitation comes from.
also i like to repeat what i said many times, libavfilter MUST be moved
into main svn as soon as possible
>
> * to have a cropdetect filter which writes to a log file the detected
> crop area for each frame
>
> * to run a new filterchain, applying for each frame the crop values in
> the log file: the crop size will affect the size of each allocated
> frame.
>
> I want to clarify this point, as this is actually one of the tricky
> points of the pad filter.
>
> The geometry of the area of buffer used by a filter needs to be
> conveied to the pad filter, because on that depends how the pad filter
> will request a new area.
output_width= input_width + h_pad
same for height
>
> Consider this:
>
> x1 x1+w exp_w x1+w+padright
> O--->---------------.-----------.---------+ - - - - - - . - - - -
> | . . | .
> | . . | .
> | . . | .
> v +------.-----------.---------+-------------+
> | | x,y . | |
> | | +-----------+ | |
> | | | previous | | |
> | | | filter | | |
> | | | area | | |
> | | | | | |
> | | +-----------+ | |
> | | | |
> | +----------------------------+-------------+
> | |
> +-----------------------------------------+
> | exp_h
i do not know what all these variables are, sorry
>
> |
>
> |
>
> The x, y, h, w informations are used to detect the dimension of the
> buffer to request to the next filter.
>
> Check vf_pad.c:get_video_buffer():
>
> static AVFilterPicRef *get_video_buffer(AVFilterLink *link, int perms,
> int x, int y, int w, int h, int exp_w, int exp_h)
thats not what we have in svn, not ffmpeg nor soc, so iam sorry but i
cant help, i do not know what these parameters are or why they are there.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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/20091003/4b9fcaf4/attachment.pgp>
More information about the ffmpeg-devel
mailing list