[FFmpeg-devel] [PATCH] Add null video filter

[Michael Niedermayer]

On Sun, Oct 18, 2009 at 12:25:41PM +0200, Stefano Sabatini wrote:
> On date Thursday 2009-10-08 00:18:25 +0200, Michael Niedermayer encoded:
> > On Thu, Oct 08, 2009 at 12:04:48AM +0200, Stefano Sabatini wrote:
> > > On date Wednesday 2009-10-07 23:45:19 +0200, Michael Niedermayer encoded:
> > > > On Wed, Oct 07, 2009 at 09:42:21PM +0200, Stefano Sabatini wrote:
> > > > > Hi all,
> > > > > 
> > > > > in attachment a zen null video filter.
> > > > > 
> > > > > Pedagogically useful.
> > > > 
> > > > it looks like it would break direct rendering, not passing
> > > > get_video_buffer() through but rather ending in a malloc()
> > > 
> > > That's true if we assume that this patch depends on the
> > > get_video_buffer() change patch.
> > > 
> > > Patch updated accordingly.
> > > 
> > > Regards.
> > > -- 
> > > FFmpeg = Faboulous and Furious Mortal Peaceful Eccentric Game
> > 
> > >  doc/vfilters.texi        |    4 +++
> > >  libavfilter/Makefile     |    1 
> > >  libavfilter/allfilters.c |    1 
> > >  libavfilter/vf_null.c    |   56 +++++++++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 62 insertions(+)
> > > be718603bac4691e58b1a2ab660a3b1db00073fe  lavfi-add-vf-null.patch
> > 
> > probably ok if extensively tested (for example benchmarks that it does not
> > cause slowdown which would be an indication of extra memcpy being done
> > somewhere)
> 
> With ffplay I didn't noticed significant slowdowns even with an insane
> number of null filters (256).
> 
> But I noticed some slowdowns with ffmpeg, even with a relatively small
> number of null filters:
> 16:  utime=4.876s
> 17:  utime=6.368s
> 18:  utime=9.501s
> 19:  utime=15.745s
> 20:  utime=28.246s
> 21:  utime=53.067s
> 
> With 32 null filters the process seems to hangs, a quick inspection
> with gdb revealed that the processing hangs in avfilter_poll_frame(),
> anyway since the problem is not related to the present filter I
> committed.

please elaborate
what did you test, if not what was be commited?

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20091018/26c95d5f/attachment.pgp>