[FFmpeg-devel] [PATCH] lavfi: add geq filter.
ubitux at gmail.com
Wed Nov 7 22:50:46 CET 2012
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
Indeed, that's much better, thanks a lot.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: not available
More information about the ffmpeg-devel