On Sat, Oct 31, 2015 at 9:59 AM, Clément Bœsch <u...@pkh.me> wrote: > On Sat, Oct 31, 2015 at 08:47:37AM -0400, Ganesh Ajjanagadde wrote: >> On Sat, Oct 31, 2015 at 6:19 AM, Nicolas George <geo...@nsup.org> wrote: >> > Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> >> Sample benchmark (x86-64, Haswell, GNU/Linux): >> >> File: original from https://trac.ffmpeg.org/ticket/1430 >> >> command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=rx=64:ry=64 -f >> >> null - >> >> >> >> Timer truncated at 1024 runs. >> >> new: >> >> 39676 decicycles in qsort, 1024 runs, 0 skips >> >> >> >> old: >> >> 86783 decicycles in qsort, 1024 runs, 0 skips >> > >> > What was inside the start/stop_timer block? I see that the qsort call is >> > after a very expensive loop, I suspect those few thousand cycles may be >> > completely negligible in front of the loop itself. >> >> Entirely possible. I just did this as a low hanging fruit. I highly >> suspect that the algorithm can be improved (see Michael's comment). > > deshake is a filter that overall needs large rework. Aside from the fact > that it doesn't work well (it's an unmaintained half assed simplified > version of what vid.stab does), it is also IIRC easily crashable. > > Ticket #1430 may be of interest.
Just now pushed, and have a remark about it in the commit message brought up by Nicolas's comment before reading your email :). > > [...] > > -- > Clément B. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel