diff options
author | Nicolas George <george@nsup.org> | 2016-10-23 13:57:41 +0200 |
---|---|---|
committer | Nicolas George <george@nsup.org> | 2016-11-03 21:23:55 +0100 |
commit | 0bd1be65e88d6a4f367e698d7a2b105424eb1905 (patch) | |
tree | 69cb89e9bfccaa3d67787261f351e78f9b994ebf /tests/fate | |
parent | 4abe1ff08f1fb2a909c4a99bd9e44a81e2c3cc3d (diff) | |
download | ffmpeg-0bd1be65e88d6a4f367e698d7a2b105424eb1905.tar.gz |
lavd/xcbgrab: do not try to create refcounted packets.
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 and confirmed by others.
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.
Diffstat (limited to 'tests/fate')
0 files changed, 0 insertions, 0 deletions