Buz/Linux - Home

Must sites:

Netscape Communications Inc. Freshmeat: Software/Linux Dr. Ozones Backgrounds & Images
Hosted by:

Visit Gernot

FAQ - Frequently asked questions

Please 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
Chrominance In: 1
Luminance In: 2
Chrominance Out: 3
Luminance Out: 4
Composite Out: 5
Ground: 6, 7, 8, 9, 10
Not connected: 11, 12, 13, 14, 15
As you can see, Composite in and Chrominance in are hardware coupled.

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

When watching overlay video suddenly the video goes black and nothing beside a reboot brings it back. What is going on ?

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:

  • you should be able to watch the overlay after a fresh reboot (but as mentioned above, this might not be the case with certain h/w configurations)
  • the image should reappear when you make the xawtv-window very narrow, height doesn't matter

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:

  • seems to depend on h/w config, but it comes sooner or later on all platforms.
  • comes earlier when a part of the overlay is obscured by another window (so a overlay mask is needed by the Zoran chip)
  • comes immediatly if a overlay mask is needed AND I am doing heavy disk I/O
  • comes more seldom if I am switching off DMA to disks in the kernel

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 !

Which motherboards are supported ?

The VP3 motherboard has serious problems with showing overlay video, and has low transfer rates for transmitting MJPEG. I recommend to upgrade to an Aladdin V, for example.
Generally, there shouldn't be any trouble with your motherboard, if you have bought it after the second quarter of '99.
Some verified motherboards:
  • Asus 97TX Smart
  • AOpen AX6B
  • Abit BH6 works fine (BX chipset I think, use the Natoma workaround).
  • VT 82C585 Apollo VP1/VPX (rev 35).
  • Aopen ax63 works fine.
  • Soyo SY-6BB (but don't overclock it !).
  • Athlon Motherboard BIOSTAR M7MKA
  • ASUS P5a-b
  • ASUS TX97Smart. CPUcbuz 233MMX (intel), Chipset 430TX

Why not write video in full resolution and uncompressed ? This should maintain highest quality, shouldn't it ?

Yes, but:

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)

Which JPEG compression should I use

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)

How do I create a device file ?

For those who don't know how to create the /dev/video file:
To create /dev/video, you should create /dev/video0 first:
  • cd /dev
  • mknod video0 c 81 0
  • create a symlink with "ln -s video0 video"

How can I get support for my graphics card in the buz driver ?

I am not sure if it works, please tell me if it does:
  • For a quick fix, always run v4l-conf in X (included in the buz_tools) before you start buz_video. This will set the framebuffer adress by retrieving it from XF86DGA, which is an XFree-Server library for Direct Graphics Access.
  • When you got this working, have a look at the address v4l-conf reported when configuring the framebuffer. This address can be different from computer to computer, therefore you have to look up which memory region number the card is using for this address. Use lspci -vvx or cat /proc/pci to get a list of your PCI units, and find your graphics card. It occupies several memory regions, each with a number. Find the one that matches your card. Report the card, PCI id (in the beginning line of the entry) and the memory region to the developers.
Note: None of these methods will work for non-Xfree86 servers (like Accelerated X, Metro X), because they don't support XF86DGA. Try to set the framebuffer address by hand, and when you succeeded, report the address and card info to the driver developers:
You will need the PCI-ID of the card (shown in lspci), and which memory region number (the one to the left of the working address) the card has its framebuffer in.

(Answer by Gernot Ziegler)

Is the device driver V4L-compliant ?

Yes, the driver is V4L-compliant, and it improves the "normal" V4L-API with Motion JPEG (MJPEG) extensions, that are now (May 2000) the official standard API calls for MJPEG compression/decompression.

(Answer by Gernot Ziegler)

What about Video 4 Linux II (V4L2) ? Wouldn't that fit better ?

Yes, it certainly does, and the driver will migrate to V4L2 (or any more advanced API that will become the new standard) in the long term. But, as you certainly know, reprogramming a kernel driver is time consuming, and Rainer (the main developer in the moment) is already working with full effect :-) ! But before rebuilding he wants to implement some new features, and waits until V4L2 goes into the developer kernels (2.5.x ?)....(May 2000) Our new plans are now to unify all the MJPEG drivers into one, and go into the kernel as soon as possible, where we then will switch to new API:s as they arise ...
And, remember: V4L2 has not been integrated into the kernel - even if we released a V4L2-driver for the Buz now, it would be quite difficult to install (even worse than for this version ; ) )

(Answer by Gernot Ziegler)

Other useful sources of information:

The Buz/Windows FAQ
The Buz Usage Tips Page

This page is maintained by .
V 0.3. Latest update .
Copyright © 1999 by Gernot Ziegler.
Page has been accessed times. (Recent Changes)
Corrections, Error reports, Suggestions are always welcomed.