I have two implementations of video capture and display using SDL,
and I am trying to figure out the reason for differences in
performance and appearance between them. Everything here is
using the V4L2 driver for Videum boards.
Implementation 1: Native DirectFB
Primary Surface in video memory.
Secondary surface in system memory.
- grab video frame, copy it into secondary surface.
- image process the data in the secondary surface.
- Stretched blit of secondary surface into primary surface.
Code timing show that I am churning through 30fps,
though I don’t think that this is the rate at which
frames are actually appearing on the screen
(maybe frames are being clobbered between refreshes?)
Implementation 2: Over SDL over DirectFB
(modelled using the effectv code).
- grab video frame, bring it into system memory.
- stretch it by pixel doubling using the CPU.
- copy data into primary SDL surface.
Code timing show that I am churning through 21 fps,
I think that this is the rate at which frames are
actually appearing on the screen. (If I don’t do
the pixel doubling step, I get 30fps).
Bottom line: implementation 2 looks much smoother on the
screen than implementation 1, and I am trying to figure out
why. I moved to DirectFB because I am using a Matrox G400
and I figured that on-board stretched blits would be much
faster than CPU-based pixel doubling. Frame rates show that
the DirectFB implementation chews through frames much faster,
but qualitatively, the SDL over DirectFB implementation looks
much smoother. I suspect it may be because I am blitting
several frames to the Matrox card before it has a chance to
actually show them to me on the screen–is this possible?
Can someone offer some suggestions–obviously the folks who
wrote the back end of SDL -> DirectFB know how to do it right.
Chat with friends online, try MSN Messenger: http://messenger.msn.com