Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-11-03 Thread Nicolas George
Le sextidi 6 brumaire, an CCXXV, Andy Furniss a écrit : > Beats legacy by a couple of fps on my old CPU and combined > with nv12 conversion makes the difference between being able > to do 1080p60 and not. Thanks to everyone for all the testing. I do not think I can take credit for beating the leg

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-27 Thread Andy Furniss
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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-25 Thread Sven C. Dack
On 23/10/16 13:29, 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 t

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-25 Thread Clément Bœsch
On Tue, Oct 25, 2016 at 07:58:56PM +0200, Nicolas George wrote: > Le quartidi 4 brumaire, an CCXXV, Clement Boesch a écrit : > > > The framework will allocate a buffer and copy the data to it, > > > that takes time. > > > Sorry if this is a dumb question but: can you describe what happens if the >

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-25 Thread Nicolas George
Le quartidi 4 brumaire, an CCXXV, Clement Boesch a écrit : > > The framework will allocate a buffer and copy the data to it, > > that takes time. > Sorry if this is a dumb question but: can you describe what happens if the > previous packet still held the same pkt->data = c->buffer? > > That is,

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-25 Thread Clément Bœsch
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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-25 Thread Clément Bœsch
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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-25 Thread Michael Niedermayer
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

[FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-23 Thread Nicolas George
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