Date: Tue, 12 Dec 2000 00:41:47 -0500 (EST) From: Tommy Johnson <protius@bobdbob.com> To: jandrese@mitre.org, protius@bobdbob.com Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: Video capture Message-ID: <200012120541.eBC5flN19347@teryx.bobdbob.com> In-Reply-To: <3A312120.DB69E030@mitre.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>Tommy Johnson wrote: >> >> >Is it possible to capture video on FreeBSD into MPEG with just a BT8x8 >> >based capture card? Has anybody successfully captured video and or >> >coverted the video to DivX ;-) (MPEG4v2)? >> >> I've done video capture to mpeg 1 with a BT8x8 card, at 352x240 resolution. >> The entire scheme is capture to an uncompressed file, then compress video >> and audio seperately, then merge the two streams in to one system stream. >> >> If there is interest I can make a tarball of my alleged software and >> put it on the web. Its extremely non-pretty, but it works. The tarball can be found at http://www.bobdbob.com/~protius/software/video.tgz This is /extremely/ alpha quality, its more the proof-of-concept code than anything. I use it every week to digitize a public access TV show a friend of mine does though. The way the last month has been, attempting to get around to cleaning it up would result in just too long of a delay. >That would be great, I'm sure I'm not the only one who wants to do this. >BTW, how much space does an uncompressed video take? My back of the >envelope >calculations for a 30fps 30 minute long uncompressed video place it >around >76,032,000 bytes, ouch. Yea, 'tis a nasty volume of data. I usualy do 352x240x30fps at 16 bpp YUV, which is approxomately what NTSC does (YUV-422). That works out to about 9GB/30 minutes. Full resolution would be 36.4GB/30 minutes. Harware compression is your friend. :-) The problem I ended up spending more effort on was syncing the audio and video. My solution isn't perfect, but it at least dosn't drift badly over a 30 minute run. I have two circular buffers in shared memory, the audio buffer is fed by an independant reader process. The video buffer is fed by a signal handler, and the main body of the video process writes both buffers to disk, using a single file. The original implementation had two files, but seeks between the two writers killed performance. Every 333 frames, the writer throws away audio samples, to force the two buffers to line up. Its also dosn't write the same number of audio samples per frame, since 44100 audio samples per sec dosn't divide by 29.97 frames per sec. The least common multiple is 333 frames... On my setup, it almost always has an error of 98 audio samples per cycle. Anyway, let me know if its of any use, or how bad my code is... :-) -Tommy Johnson protius@bobdbob.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012120541.eBC5flN19347>