[FFmpeg-devel] Fwd: framebuffer device demuxer

Luca Abeni lucabe72
Wed Feb 24 10:29:51 CET 2010


Stefano Sabatini wrote:
>>  * You should have received a copy of the GNU Lesser General Public
>>  * License along with FFmpeg; if not, write to the Free Software
>> Which looks like a contraddiction (contains code from GPLed, but
>> is released under LGPL).
>> I did not check which part of the comment is wrong, but I
>> think that something has to be fixed, there :)
> I removed the attributions which are IMO wrong, as I can't see much
> similarity between fbgrab.c and the new code.
> As for what regards x11grab.c, the part in read_header() which
> computes the timestamp looks just wrong or at least badly obfuscated,
> I'm trying to understand it in the meaningwhile if you have some
> insight on it please share :).

Looks like the timing code confused me, but it is correct (the only
questionable part is the "if (delay < INT64_C(-1000000) *
av_q2d(fb_ctx->time_base)) ...").

The framerate problem I was seeing is due to ffmpeg consuming 100%
of the CPU in "memcpy(pkt->data, fb_ctx->data, fb_ctx->frame_size);"
in frame_buffer_read_packet(). I do not know why this memcpy() is
so slow...
If I try
	ffmpeg -re -s 1280x1024 -y -r 25 -pix_fmt bgra -f rawvideo -i /dev/zero test.nut
ffmpeg does not consume 100% of the CPU. And the input is
	Stream #0.0: Video: rawvideo, bgra, 1280x1024, 25 tbr, 25 tbn, 25 tbc
If I try
	ffmpeg -y -r 25 -f framebuffer -i /dev/fb0 test.nut
ffmpeg consumes 100% of the CPU in the memcpy() mentioned above,
and the input is
	Stream #0.0: Video: rawvideo, bgra, 1280x1024, 1048576 kb/s, 25 tbr, 1000k tbn, 25 tbc
So, I do not know where the overhead is coming from (the two commands
mentioned above should do about the same thing...).

I guess that implementing 0-copy input (as in v4l2.c) would be
a possible solution to this problem.

> BTW there is some particular reason for which both in v4l.c and v4l2.c
> we open the fd using O_RDWR, rather than just O_RDONLY?
I do not know about v4l.c; for v4l2.c, this is just what the video4linux2
video capture example code did when I wrote the input. I suspect O_RDWR
is required for performing some of the v4l2 ioctl()s.


More information about the ffmpeg-devel mailing list