[FFmpeg-devel] Fwd: framebuffer device demuxer

[Stefano Sabatini]

On date Wednesday 2010-02-24 10:29:51 +0100, Luca Abeni encoded:
> Hi,
> 
> 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.

Updated with many fixes, in particular the output packet was misaligned
so the image resulted corrupted (weird that I hadn't the problem the
last time I tried it...).

Not yet for commit, I want to clean it up still a bit (and maybe add
some more features), review is welcome of course.

Regards.
-- 
FFmpeg = Fanciful and Fundamentalist Mastodontic Puristic Elitarian Guru