[Ffmpeg-devel] Eliminating some memcpy() & memory allocations from the v4l2 input
Luca Abeni
lucabe72
Wed Feb 1 16:21:00 CET 2006
Hi all,
now that the v4l2 input format has been committed, I am working on
making it more efficient.
I know that the "suggested method" would be to use the "user pointers"
I/O method provided by video4linux2, but it crashes my test machine, so
I am still trying to work with mmap-based I/O...
The idea is that video4linux2 provides two ioctl() calls:
- VIDIOC_DQBUF, to get a buffer containing a captured video frame (the
call blocks if the frame is not ready yet)
- VIDIOC_QBUF, to "return to buffer back" to the video4linux2 driver
once the application used it
The current (naive) code, on read_frame():
1) Allocates a new AVPacket (by using av_new_packet())
2) gets a video buffer with VIDIOC_DQBUF
3) copies the video buffer contents in the newly allocated packet
4) releases the buffer with VIDIOC_QBUF
Now, considering that av_new_packet() dynamically allocates memory for
the packet and zeroes it (not to count the fact that we then do a
memcpy()), you can see that there is space for some optimizations... ;-)
So, my idea is to avoid dinamically allocating the memory for the
packet, and to set pkt->data = <pointer to buffer returned by
VIDIOC_DQBUF>. VIDIOC_QBUF will be called only when libavformat does not
need the packet anymore, and I am planning to use the destruct() method
of AVPacket for this. Does this usage of AVPacket (and of its destruct()
method) make sense? Or am I misunderstanding its purpose?
To better explain what I mean, I cooked up the attached patch (not
submitted for inclusion yet - it still needs some comments and
cleanups... It is just for having some comments and reviews).
The patch seems to work well (I can capture video without seeing any
core dump :), and its performance seem promising:
when I run
time ./ffmpeg -y -vd /dev/video0 -ad /dev/dsp0 -pix_fmt yuv420p -s 720x576 -f yuv4mpegpipe - > /dev/null
with an unpatched libavformat, I get
real 2m50.774s
user 0m2.895s
sys 0m2.190s
while after applying my patch I get
real 2m50.589s
user 0m2.044s
sys 0m0.075s
(repeating the experiment more times give consistent results).
Luca
--
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
N O W A R ! ! !
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
I migliori software per tutti i cellulari da Jamba!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=4611&d=1-2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zerocopy-1.diff
Type: text/x-patch
Size: 2232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060201/6e501fea/attachment.bin>
More information about the ffmpeg-devel
mailing list