On Sun, 6 Feb 2000, Jan Kneschke wrote:
> On Sat, Feb 05, 2000 at 04:46:58PM -0500, teunis wrote:
> > On -video- capture (ie stream of messages): No. Absolutely not.
> > Frame grabbing has -terrible- problems with two things:
> > 1. It goes very fast. Hard to capture 30fps at 640x480
> > straight into a raw buffer...
> ggitv gets 25fps in 640x480 by video-card->X->gfx-card (NO overlay).
Scary. Lucky you - it's slower on my Celeron 366, 3DFX Banshee, XFree86
3.97 (4.0 prerelease, 3D accelerated opengl :)
I typically lose a few frames with ggitv, though Broadcast 2000 generally
works perfectly when it doesn't crash.... (30% operational, 30% driver
crashes and Broadcast 2000 recovers (but ggitv crashes system), and 30%
locks system solid)
> > 2. Drivers aren't very stable... *sigh* [for bttv]
> which driver are you using (driver-version, hardware) ??
Zoltrix TV-card;
Linux-2.3.39 (2.3.41 doesn't change the code any)
No special drivers. And I run 2.3.x due to USB and -stable- HD drivers.
I got tired of losing data with 2.2.
Incidentally, if power goes out on my system (or it locks), 2.2 -always-
loses the most recently touched files on my computer.
After losing 2 weeks of work, I went to 2.3 and have never looked back.
Except that AFAIK the bttv driver's more stable in 2.2.14 IIRC.
> > Anyways, you'd have to do a different interface for -video- capture than
> > for image capture anyways. Mostly due to latency problems.
> > I want that personally....
> > (mind you, I don't use GGI to -play- videos either other than to supply a
> > frame to write to ... it doesn't fit the purpose)
Trust me, there's latency problems. Unless you have a really fast
computer.... *grin*. My old Cyrix 200+ was -way- too slow for motion
capture. My Celeron 366 can barely handle capturing into motion JPEG...
*grin*. Great format for video. WMX2 is good for audio :)
1. Never copy the data; just store to a buffer. If you're going to change
data, keep a running buffer of as many frames as you can afford.
(is it possible to create a guaranteed no-swap memory area?
And to tell how much physical memory is available so you can tune?)
2. Threads are your friends here. Or processes if you have good IPC.
-> shared memory for buffers, and keep running positions on
where things are....
Enables all kinds of special effects, mixing, et al without prob.
(I'm developing IPC communications now. Anyone got a good lib? :)
3. It gets big if you have any kind of resolution.
320x240; 16bpp; 16-bit stereo uncompressed; 5 min == ~500megs;
Compressed motion-JPG,WMX2 == ~50megs
Compressed MPEG 1.0/layer 2 == ~30megs
Compressed MPEG 2.0; == whatever. You can control it.
The higher the compression the lower the quality.
Also CPU load:
uncompressed: duable (barely) on Cyrix 200+/32mb ram Linux
windows/98: Celeron 366; 64MB ram to barely handle 15fps
Compressed/Motion JPG/WMX2: Celeron 366/64MB ram realtime
MPEG - Celeron 366/64MB - roughly 10* length of movie
MPEG2 - roughly same.
Arguments are welcome :)
G'day, eh? :)
- Teunis
