[FFmpeg-devel] [PATCH] lavfi: add geq filter.

[Clément Bœsch]

On Sun, Nov 04, 2012 at 08:23:26PM +0100, Marton Balint wrote:
> 
> 
> On Thu, 1 Nov 2012, Stefano Sabatini wrote:
> 
> >On date Wednesday 2012-10-31 20:40:15 +0100, Clément Bœsch encoded:
> >>TODO: bump minor
> >>---
> >>Another portage from MPlayer filters. It seems to work, but I still have some
> >>issues with ffplay when the filter is complex/heavy. Try for instance this one
> >>(stolen from a random guy on #mplayer):
> >>
> >>    ffplay -f lavfi -i 'testsrc,geq=p(lt(X\,W/2)*X*(1+sin(N*PI/100))+not(lt(X\,W/2))*(W-X)*(1+sin(N*PI/100))\,lt(Y\,H/2)*Y*(1+sin(N*PI/100))+not(lt(Y\,H/2))*(H-Y)*(1+sin(N*PI/100)))'
> >>
> >>mplayer seems to deal relatively well with slow filters contrary to ffplay, but
> >>I have no idea how to avoid the current frame drop (playing with the options
> >>didn't help).
> >
> >-noframedrop may help
> >
> 
> Yes, or use -sync video. In fact, only since a recent change ffplay
> forces realtime display of the video when no audio is present.
> 
> If you want realtime display AND useable output use this:
> 
> ./ffplay -f lavfi -i 'testsrc' -vf 'geq=p(lt(X\,W/2)*X*(1+sin(N*PI/100))+not(lt(X\,W/2))*(W-X)*(1+sin(N*PI/100))\,lt(Y\,H/2)*Y*(1+sin(N*PI/100))+not(lt(Y\,H/2))*(H-Y)*(1+sin(N*PI/100)))'
> 
> It is better, because ffplay can detect that the filter processing
> is taking too much time and drop frames before passing them to the
> filter.
> 

Indeed, that's much better, thanks a lot.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121107/45d332ec/attachment.asc>