On Sun, Oct 23, 2016 at 02:29:37PM +0200, Nicolas George wrote: > The framework will allocate a buffer and copy the data to it, > that takes time. But it avoids constently creating and > destroyng the shared memory segment, and that saves more time. > > On my setup, > from ~200 to ~300 FPS at full screen (1920×1200), > from ~1400 to ~3300 at smaller size (640×480), > similar to legacy x11grab. > > Plus, shared memory segments are a scarce resource, > allocating potentially many is a bad idea. > > Note: if the application were to drop all references to the > buffer before the next call to av_read_frame(), then passing > the shared memory segment as a refcounted buffer would be > even more efficient, but it is hard to guarantee, and it does > not happen with the ffmpeg command-line tool. Using a small > number of preallocated buffers and resorting to a copy when > the pool is exhausted would be a solution to get the better > of both worlds. > > Signed-off-by: Nicolas George <geo...@nsup.org> > --- > libavdevice/xcbgrab.c | 65 > +++++++++++++++++++++++++++------------------------ > 1 file changed, 35 insertions(+), 30 deletions(-)
Tested-by: Michael 126fps -> 141 here [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
