Contents: Must sites: 
Hosted by: Visit Gernot |
FAQ - Frequently asked questionsPlease check Rainers Driver Tips, too. What can the Buz and associated tools do?How does good quality capture of full-resolution, full frame-rate (720x576 50 field/sec PAL) video (with synchronised 44100Hz audio) and scrunching the lot down to disk-driveable data rates in real-time with neglible (5 or 6, perhaps) dropped frames over a movie-length piece grab you? It'll also play stuff it has compressed back for you with only modest CPU load. Technically, it is a hardware MJPEG compressor/decompressor with on-board video codec's. However, it has no tuner so it only takes proper composite or (better) SVideo feeds. My configuration hangs it off the back of my mechanically worn but electronically sound (stereo) VCR to use that to tune channels. You get a reasonably nice SCSI interface on the card too!(Answer by Andrew Stevens) So why don't I rush out and buy one of these for the ridiculously low prices that are being charged for second-hand or ex-stock kit? Why on earth did Iomega stop supporting this little gem on the PC?Well, basically, the hardware is picky about its environment so read on before sending off $100...(especially Other hardware constraints).How do I get my Buz working properly under Linux?See setup answers below.What are the hardware requirements?There isn't an exhaustive list (have you ever bothered to fill in one of those "my working configuration surveys"?). However, my experiences and a little semi-informed extrapolation suggest the answers below.What is the slowest CPU that will work?The CPU requirements of the Buz are modest. High-quality capture seems to require less than 30% of a Celeron 366. Usually it is much less but for real-time video business it is the peaks that count. I'm sure anything better than (say) a Pentium 166MMX would do. Capture uses no floating point so those cheap WinChip's and Cyrix chips should work nicely. However, CPU load during capture is really the least of your worries. Firstly, cheap CPU's are often associated with cheap and nasty motherboards which may be an issue (see below). If you want to do more than capture and playback a little later you'll want to MPEG compress the results. The mjpeg tools now include decently fast MPEG encoders producing good quality MPEG-1 and (experimentally) MPEG-2. However, for tolerable compression times you will definately need a 300Mhz+ CPU supporting at least MMX.(Answer by Andrew Stevens) How good does my disk drive need to be?Now we're talking. The Buz generates around 5 MB/sec in its highest quality setting. This is total over-kill for most domestic video sources. However, sensible settings can still produce well over 1MB/sec. Worse, the issue is not the disk's average performance but worst-case scenario's where the disk goes off and has to update some other file-system information during a capture. Recent (it is May 2000 as I write) IDE disk drives (the 15GB and up generation) deliver 10MB/sec sustained linear read/write or better when properly configured (DMA etc) and around 10mSec seek times. These work well. However, judging by what happens when you add other traffic to these disks I suspect that you would find it hard to avoid occasional frame drops on drives delivering less than (say) 5MB/sec susutained linear read. In short, previous generation (6GB and up) of IDE drives will manage too, but not with much head room if you want to do capture with zero perceptible quality loss. If the drive is delivering less than 4M/sec you probably want to look into Linux's software RAID goodies or consider a new drive. You'll need the space anyway. N.b. doing VHS or a bit better requires a good deal less performance than the above. Also, I have achieved good results with a decent disk drive accessed via kernel nfs over 100Mbps ethernet.(Answer by Andrew Stevens) How much disk space will I need?Slightly better than VHS quality recording uses around 500KB/sec. Top quality around 1.3MB/sec. That's around 20GB bytes to record "Terminator II" from a TV broadcast in top quality. I have a 30GB drive dedicated for recording to before compression.What Soundcard do I need?The Buz uses your soundcard to record and play audio. If you have a decent stereo decoder and audio setup for your video watching you will want to use a decent sound-card. On-mother board and el cheapo (Eu/$)15 stuff is usually (audibly) noisy/poor fidelity when capturing. Spend (Eu/$)40 on an OEM AWE-64 or a decent PCI sound card and you won't regret it! Never mind the video - you'll grin as you notice how much nicer your MP3's sound too.The sound driver situation under Linux seems to have got steadily better these days. Almost any card with reasonably complete drivers (either ALSA, OSS/Free, or commercial OSS) should work. However, the mjpeg tools do use the fancier facilities of the Linux sound interfaces (mmap-ed buffers, block completion triggering). It is not inconcievable that rough and ready early drivers may not work. However, earlier difficulties relating to the requirement for more than two buffers have now been solved. As a result up-to-date drivers for popular cards like the Aureal Vortex series and Soundblaster live should work nicely. As ever the SB-16 and AWE-32/64 family are know to work very well. Finally, if you're a happy lavtools user out there and have a sound-card setup that works (or was a disaster) let me know and I'll post a summary here. How much memory do I need?Capture works much better if you can give the software lots of memory for buffers. For high quality I found 16MB or so worked wonders for reliability. So a 32MB machine is probably a bare minimum for fully exploiting the Buz.(Answer by Andrew Stevens) Any other hardware constraints?This is the show stopper. The Buz is a bridged PCI card. The SCSI adaptor and other chips share a little on-card PCI bus that talks to your machine's PCI bus via a bridge chip. This is obviously a much more demanding configuration than ordinary unbridged stuff. Worse, the bridge chip used appears to be particularly picky. The end result is that if your motherboard has a not-so-good PCI implementation you will tend to drop frames. Hearsay (confirmed my own experiences) suggests that VIA's VP3 and MVP3 chipsets are not-so-good PCI personified. I had endless problems until I shoved the Buz into an Intel 440BX based board. ALI based stuff is also mentioned as working well. My experience of PCI problems (even under Microsoft's O.S.es) on new KX133 Athlon boards suggests it would be wise to suspect the worst on these too until later revisions prove them innocent. I suspect that these difficulties were, in part, responsible for Iomega dropping PC support for the Buz. I bet their support guys were weeping into their beer nightly...Update: Some tweaking of the final buz driver may solve some of these problems. Contact Andrew Stevens for further info. The latest combined DC10/LML33/buz driver may also be worth a try. (Answer by Andrew Stevens) Are there any special motherboard / chipset setup considerations for setting up the Buz hardware?The Buz appears to be very demanding in that it requires low interrupt latency. Given the that same problems appear to occur under big Bill's operating systems too I suspect this is a weakness of the underlying hardware. Certainly, for really good results I found I needed to ensure the buz video chip did not share its interrupt with another driver. N.b. the buz card takes two PCI INT's one for on-board SCSI controller a second for the video. You'll probably need to experiment with shuffling PCI boards around to achieve an unshared video IRQ. N.b. I found one of my motherboards had an evil habit of not allocating different hardware IRQ's to the PCI INT's (A-D). Technically, the damned thing appeared to allocate INT's B and C to the same IRQ. I could only get things how I wanted when I specified a manual IRQ->INT mapping. Similarly, you don't want the kernel masking interrupts for a long time. So active devices whose drivers do this are a big no-no during capture. In particular you definately want to "hdparm -u 1" your IDE disks to stop these drivers masking interrupts during disk I/O. Obviously, using (U)DMA is the right way to go too.(Answer by Andrew Stevens) How do I generate standard MPEG files so video is in a manageable size and/or playable using standard players?The latest version of the mjpeg tools (the merged follow-on to the Linux Audio-visual tools -lavtools has got what you need.(Answer by Andrew Stevens) What are the connections inside the breakout box of the Buz ?Composite In: 1 How can I measure the throughput rate of my disk drive ?(Answer by August Black I got the following from the lml33 site.
In order to estimate the performance of the disk subsystem use the
following command:
time dd if=/dev/zero of=/tmp/dummy.test bs=1024k count=100
Make sure you have at least 100Mb free on a disk drive mounted on /tmp.
If you have more space available on /tmp, change to count=500 or more.
Then calculate the transfer rate in Mb/sec.
For example:
time dd if=/dev/zero of=/tmp/dummy.test bs=1024k count=120
120+0 records in
120+0 records out
0.01user 8.99system 0:40.16elapsed 22%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (199major+271minor)pagefaults 6swaps
That gives 120Mb / 40sec = 3 Mb/sec
The biggest unsolved question about the Buz under Linux
is the fact, that when watching overlay video (with xawtv or
some other tool, which doesn't matter) suddenly the video
goes black and nothing beside a reboot brings it back.
If you are trying uncompressed image grabbing this doesn't
work either from that moment on (xawtv reports a timeout).
It seems to be better on some systems and worse on other ones,
reportedly VIA chipsets behave worse than Intel chipsets.
You might never be able to see a full res overlay video
with certain VIA chipsets.
So how can you tell that you are having this problem
and not some other graphic card related troubles:
This seems to be a Buz specific problem, I am suspecting a
hardware bug in the meantime since I really tried every
switch in the config registers which looked like it could
be related to this problem.
Some observations I have made about that problem:
Thats all I know about that problem, I have tried everything
I could imagine and I have nearly given up to solve this problem.
I hope you all bought your Buz for making MJPEG videos
and not for watching TV on your computer screen, there
are better cards for doing that, anyways !
Let's suppose you want the "full quality" video on your computer.
And
when I mean "full quality" I mean -> uncompressed full screen. Now you are using NTSC so we will consider it. NTSC is 30 frames per second (60 half-frames, also called fields). We are not
considering sound, because it is the smallest problem here.
But uncompressed, means -> 3 bytes per pixel,
and you are under NTSC ->720x480 at 30 frames per second.
Let's use the calculator -> 3 x 720 x 480 x 30 = 31104000 bytes/second
31104000 bytes/second = 31.10 MB/second
Hey I don't have any hd that can do 31.1 MB/second so if you are not
using a raid HD configuration (and a good ultra-wide SCSI controller,
better if ultra2wide) I don't think you are not able to capture at
full screen/uncompressed. :-O
Now consider the bytes needed for your 30 minutes long video tape.
31.1 * 30 * 60 = 55987 MB (about) = 56 GB.
That means you have to experiment with the MJPEG compression and with
various parameters.
(Answer by Paolo Di Francesco)
About quality and parameters. I don't know which is best, but I can
tell
you one thing: Jpeg is subjective, so this means that you have to try
to
tune the parameters. You have also to consider another thing...when
you
use a parameter for a video that does not mean you will have the same
visual quality with another one. The problem is the observer's ability to catch the movements of the objects and the image quality. What I am trying to explain is that one image compressed, could be ugly even
with
a 50% quality for me, but not for you. And with other images, we could of the same opinion that 50% is less than acceptable.
(Answer by Paolo Di
Francesco)
(Answer by Gernot Ziegler)
(Answer by Gernot Ziegler)
(Answer by Gernot Ziegler)
|
V 0.3. Latest update
Copyright © 1999 by Gernot Ziegler.
Page has been accessed
Corrections, Error reports, Suggestions are always welcomed.