|
subscribe |
A. Trouble- shooting |
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
Internet TV with CU-SeeMe: Appendix A - Troubleshooting
Appendix A
Troubleshooting
This chapter contains the answers to questions frequently asked by newcomers. Answers have, for the most part, been provided by the CU-SeeMe community and the CU-SeeMe Development Team. This chapter is divided like this:
CU-SeeMe in general
Commonly-asked questions
If you don't like something you see, close that window. That'll cause the reflector to stop sending that video stream to you. If noone else is watching that stream, the reflector will stop accepting it from the source. By closing boring video you may be doing everyone a favor.
Usually it's the bandwidth limit of your network. The default transmission cap, 80 kbps, is sensible unless you know that there is additional unused network capacity between the machines. The cap is automatically adjusted on the fly within the user-settable range on the basis of packet-loss reports returned by each CU-SeeMe client receiving your video stream. At some point, if you have a very "wide pipe" between machines, the processing power of your computer will become the limiting factor.
No discussion of CU-SeeMe bandwidth usage would be complete without considering what behavior is appropriate when bandwidth is limited. For example, is it good network behavior to broadcast the inside of an empty office? No, it's not good behavior to broadcast an empty office when bandwidth is limited, but it's also somewhat irrelevant since CU-SeeMe doesn't actually broadcast. The CU-SeeMe reflector only sends video to machines that want it, to clients who have that window open. A video source will stop transmission to the reflector if no one is watching.
Interestingly, the implication of this is that video receivers are just as responsible for bandwidth consumption as are video sources. A responsible bandwidth consumer closes uninteresting windows. A far greater sin than sending video of your office while you're at lunch is leaving CU-SeeMe running with several video windows when you're not there.
This point bears repition because CU-SeeMe behavior is contrary to that of broadcast television.
No, the bandwidth limit applies only to your transmission. The only way you can reduce the incoming rate is by closing windows. The CU-SeeMe Development Team has indicated that eventually you'll be able to set a reception rate cap, and then allocate that bandwidth as you desire to the video resolution, window size, frame rate, and the number of windows displayed. In short, you'll have to manage the trade-off between watching several tiny windows at a slow frame rate or a single large window at a high frame rate.
Because the answer depends upon a subjective evaluation of "fluid motion" and the subject matter being sent, this is a very tough question to answer. A "talking head" - a typical office shot - takes about 100 kbps. That's because there's not that much difference between frames. (This is a good number to remember when you're connecting to a reflector with a 14.4 kbps or 28.8 kbps modem.)
At the other extreme, consider some video stream where each frame is completely different from the preceeding frame. There are 75 kbits in an uncompressed 120 x 160 frame, which would translate to about 45 kbps with the lossless spatial compression. If you're willing to call 15 fps fluid motion, you'd need 675 kbps!
As Tim Dorcey said when dealing with these concerns, "since the software is free, the best thing to do is try it out on the sorts of video you have in mind."
Since CU-SeeMe only transmits the portions of a picture that have changed significantly from the preceding frame, it's entirely possible when the picture is not moving much. Of course, 22 fps is no more impressive than 1 fps when all the frames are the same.
Tim Dorcey of the CU-SeeMe Development Team explains:
The first step in the CU-SeeMe video encoding, is to represent the video image using 4 bits/pixel (16 shades of gray). The image is then subdivided into 8x8 pixel squares, which are treated as independent units. When a new frame of video is acquired, a square is transmitted if it differs sufficiently from the version of that square that was most recently transmitted i.e., if it differs from what the recipients are currently displaying (assuming no packet loss). The index used to determine how different a square must be in order to trigger updating is roughly the sum of the absolute values of all 64 pixel differences in an 8x8 square, with a multiplicative penalty for differences that occur near each other within the square. The cut-off value can be adjusted by the "Tolerance" control under "Compression" controls, and should be set as high as possible without corrupting the picture too much.
Since CU-SeeMe uses an unreliable ("best-effort") transport mechanism (UDP), squares are sent on a periodic basis even if they haven't changed, insuring that a lost update won't corrupt the picture indefinitely. How often this forced update occurs is controlled by the "Refresh Rate" control, which specifies the number of frames that will be allowed to pass before a square is updated.
Once the decision to transmit a square has been made, a locally developed lossless compression algorithm is applied to each individual square. The algorithm is designed to exploit spatial reduncancy in the vertical direction i.e., works well if each row in the square is not too different from the one above it. Based on informal observations, the algorithm averages around a %60 compression rate (compressed size is about 60% of the original).
The main objective in designing these algorithms was to be fast enough for operation on average Macintosh computers. This is achieved by operating on rows of 8 4-bit pixels as 32-bit words throughout the algorithms, achieving a degree of parallelism, in effect. Written down in mathematical terms with respect to individual pixels, the algorithms look rather goofy, but become appealing when represented in 680x0 assembly language.
As with any compression algorithm, your mileage will vary depending on the nature of the data to compress. In the case of CU-SeeMe, the most important factor is the amount of motion in the video.
Tim Dorcey of the CU-SeeMe Development Team explained: "DNS didn't seem particularly important as long as there was an ability to assign nicknames to IP's. And the nickname feature was essential since many desktop machines aren't registered for DNS. However, as it becomes increasingly common to advertise reflector addresses, it's clear that DNS would be useful. It's on the list of things to add."
Video
The way you illuminate the scene has a great impact on image quality. Flourescent light "flashes" at the frequency of the alternating current; if your camera's synchronization is close to that frequency you'll see light and dark horizontal lines. (This is the reason you see "marching bands" when you point a camera at your display monitor, or when you see wagon-wheels going backwards on
Using natural or incandescent light to prevent this from happening.
I've seen this happen when you're using a camera that doesn't automatically adjust to available light (such as the Connectix QuickCam). During the day you have a mix of daylight and office fluorescent light, in the evening you have only the latter. When the lights are out of sync with the camera, the camera sees drastic changes in the brightness of the scene (see previous item).
These oscillations annoy the viewer and completely defeat CU-SeeMe's image compression algorithm by causing the image to change completely each frame, causing huge amounts of data to be sent, and consequently droping the frame rate.
Cameras that are able to automatically adjust to available light have their own set of problems. Minor changes in the scene can change the amount of light reaching the lens, causing it to open or close, and introducing spurious changes in parts of the image that have not changed at all. I've seen an autofocus mechanism do the same thing, again dropping the frame rate dramatically.
Short answer: What you're seeing isn't flickering from intensity variations in the displayed images, but rather the difference in the synchronization between the "top left" of the image being displayed and the "top left" of the camera that's watching. Professional videographers use dedicated hardware to synchronize the two.
Detailed answer: Video cameras scan the scene between 24 and 30 times per second (depending upon the video standard used); each of these "frames" are made up of two screen redraws which are interlaced to make up the whole picture. The flicker you see when recording a computer screen with a video camera is the mismatch of that scan rate to the redraw rate of the computer display (which varies considerably from one computer to the next). There are several things you can do to eliminate this flicker:
Canon's VC-C1 is an integrated camera/mic/pan/tilt unit with an RS-232 interface. You can get its specifications sheet from Canon's automated call-back fax server at +1.516.328.5960. (I don't know if it'll call overseas numbers.)
Audio
The short answer is that the encoding method takes more bandwidth than is available.
The best encoding scheme used by CU-SeeMe (and Maven), a scheme known as delta-mod, requires at least 16 kbps. There are other schemes, such as GSM (the standard in European cellular communications) and Intel DVI, but they're not available through CU-SeeMe. (You may want to check out NetPhone, or Philip Zimmermann's PGPfone, both of which work over 14.4 kbps modems.) There are better compression schemes on the horizon, but they require far greater CPU power; they may work over 14.4 kbps modems, but you'll require a PowerPC to use these audio encoding schemes.
According to one of the Apple software engineers who wrote MacTCP, PPP has a five percent overhead to handle multiple protocols. Switching to SLIP will theoretically give you extra five percent throughput - useful elsewhere but it won't help you getting audio in this case.
Macintosh
Video
This error means "CU-SeeMe's attempt to open the Sound Parameter Block - how it initializes the Sound Manager, failed". These are some of the reasons you're seeing this error:
All Macintoshes work with CU-SeeMe, the AV (audio-visual) series, the Quadras, PowerBooks, and the PowerPCs. You'll have to set the monitor to 256 colors (or less), use the correct video digitizer ('vdig') component, power down to reset a VideoSpigot card, etc. (Read on for explanations of these requirements.)
The original AV Macintosh had a video digitizer ('vdig') component that didn't allow for adjusting the brightness and contrast of the image. So CU-SeeMe modified the image "on the fly". The new PowerMac AVs allow control of the brightness and contrast through the 'vdig' but the current version of CU-SeeMe doesn't know about the new AV capabilities. It leaves the brightness and contrast set to their default values (which end up being low and muddy). The next release of CU-SeeMe should detect whether or not brightness and contrast are directly supported, and work correctly in either case.
This happens when your monitor is set to display more colors (or greys) than CU-SeeMe can handle. The Video RAM (VRAM) in your Macintosh limits the number of colors (or greys) that can be simultaneously show. On a Macintosh 660AV, which has 1 MB of VRAM, you can display "thousands of colors"; when using CU-SeeMe, however, you'll have to use 256 colors (or greys).
CU-SeeMe usually updates the video images by drawing directly to the screen, which is the fastest method. When CU-SeeMe concludes that it must instead use the general Macintosh toolbox drawing method, CopyBits, a slower method, it draws the black border to warn you of this performance degradation (which may or may not be significant depending on how many windows you have open, how often they are being updated, how fast your machine is, and so on).
What causes CU-SeeMe to conclude it can't draw directly to the screen?
Audio
Yes. Pre-MacOS 7.5 users should get the Sound Manager 3.0 from ftp.support.apple.com. Without it you'll get annoying clicking during sound output, and your Macintosh will run very, very slowly while you're receiving audio. The Sound Manager is included in MacOS 7.5 and later.
This usually is an indication you're trying to push too much data through a modem connection. Setting your transmission rate to 40 or less (depending on the Mac you're using) should prevent this from happening.
(Cultural note: "maven" means "knowledgeable person" in Yiddish.) On the Maven discussion list. Subscribe by sending email to listserv@cnidr.org with a message body that consists of
Third-party hardware
That's because versions over 1.0 don't work with CU-SeeMe. Sadly, the VideoSpigot has been discontinued in favor of more pricey models; the manufacturer has chosen not to support CU-SeeMe despite some rather energetic email lobbying by the CU-SeeMe community.
That's because Apple didn't implement the TV Tuner correctly. Rather than looking at all the video digitizers present, and selecting the appropriate one, it incorrectly uses the first one it finds.
The work-around is easy. Launch a program that uses the QuickCam, such as CU-SeeMe. This will keep the QuickCam drivers in use. Then launch a program that uses the TV Tuner card, such as VideoPlayer. It'll look for the next available video digitizer, which should be the TV Tuner vdig.
Not until an appropriate video digitizer is written.
Connectix QuickCam
That depends upon a chain of variables, the weakest link of which determines the number of frames per second you'll get. The links in the chain are:
Connectix has said "QuickCam will produce about 15 fps on most Macs in a window size of 120x160. FYI - Saturday morning cartoons are twelve frames per second. A few Macs will only achieve 10-12 fps. These include the SE/30, IIcx, IIvx, and PowerBook 165c. At smaller window sizes, frame rates are higher (e.g., 30 fps at 80x120), at larger window sizes frame rates are lower (e.g., about 4 fps at 320x240)."
Remember that using QuickCam's built-in microphone will require that the audio data compete with the video data; the cable can carry only a fixed amount of data. For this reason it's recommended you use the Macintosh's built-in microphone for audio and QuickCam for video.
QuickCam is manufactured in the United States by an experienced manufacturing subcontractor to Connectix. (For trivia buffs: QuickCam is manufactured in the building that housed Apple's old Fremont factory, where many Macintosh innovations first saw the light of day).
No, QuickCam will only work plugged into a serial port on the Macintosh's motherboard.
Yes. The cable should not extend beyond 12 feet. At longer lengths you will see black "snow" in the video image.
With the current software, only one QuickCam will be recognized at a time. You may manually switch between multiple QuickCams with a serial switchbox, if the switchbox correctly switches all eight pins of the cable and the total cable length from the computer to the camera is no more than 12 feet.
Yes, because QuickCam uses direct digital video instead of NTSC or PAL, QuickCam will work on all QuickTime-compatible Macintoshes. Since it draws its power from the computer, you do not need special power adapters.
Fixed focal means that anything greater than a fixed distance is in focus. With QuickCam anything at a distance of greater than 18 inches is in focus. There's no need for you to focus.
QuickCam has a tripod mount on the bottom and is spherical. It would be easy to build a case in which it fit (remember to leave room for the cable to escape). Mount the camera to the case via the tripod socket.
The CCD is probably the most temperature-sensitive element and is rated by its manufacturer as being capable of working from -10 C to 40 C. In the course of Connectix's testing for various certifications, the camera was subjected to extended testing from 32*F to 90*F.
No.
Connectix has had reports from users who have successfuly used QuickCam on an Amiga running the Emplant Mac Emulator, but has done no testing on Amigas.
Under special cases we will release this information. You must sign a non-disclosure and special license agreement. Send your request to quickcam@connectix.com.
Yes, Connectix has implemented the VOX (voice activated recording) feature of the Apple's Macintosh Sound Manager.
You should use QuickCam's microphone, not the built-in microphone. Apple designed PowerBooks so that the hard drive is automatically spun down whenever the built-in microphone is activated.
Your PowerBook doesn't have enough power on the serial port to run the camera. Call Connectix's technical support to order a power adapter for your computer, available for a $9.95 shipping and handling charge.
About one-third of the Quadra 605/475 motherboards cannot hold communications with QuickCam. We have a software patch available that corrects this problem. Call Connectix technical support to obtain a copy. This patch is included with all QuickCams starting with version 1.0.2.
Connectix has announced that it is working on a color version of QuickCam and will offer an upgrade path to current QuickCam owners. Since color cameras will produce more data, your storage requirements for movies will at least double.
Connectix is investigating the feasability of producing a Newton version. However, the Newton's current screen is incapable of displaying grayscale pictures, so it is probably impractical at this time.
By the time you read this book the Connectix QuickCam for PCs should be shipping.
QuickCam will work with any Macintosh that has at least a Motorola 68020 processor, one available serial port on the motherboard, 4 MB of RAM available, hard disk space available for the QuickCam's supporting software (and resultant pictures and movies), and is running at least MacOS 7.0. QuickCam won't therefore work with:
Windows
Configuration
CU-SeeMe for Windows requires three dynamically-linked libraries (DLLs):
CU-SeeMe for Windows also looks for a cuseeme.ini, but doesn't require that it exist.
WSACleanup() is a function that Winsock networking applications call when they quit. If for some reason CU-SeeMe crashes, it won't clean up after itself. You'll have to restart Windows to clean up.
***** Begin Note *****
The CU-SeeMe Development Team moved WSACleanup() to the WM_DESTROY section of the hidden NETWORK procedure in the hopes that Windows will have a better change to call WSACLeanup() in case of a crash.
***** End Note *****
There are a variety of reasons that you aren't able to connect to a CU-SeeMe reflector, including:
CU-SeeMe for Windows currently requires that your computer have a hostname.
In your Windows Sockets (Winsock) directory, where winsock.dll resides, there should be a file named hosts. If there isn't, create one with your favorite text editor or the Notepad. If your assigned IP address is 204.182.15.100 and you want your computer to be named "guildenstern", then the hosts file would look like this:
(Don't use these values, these are from my hosts file.) When you restart Windows you're machine will have a hostname.
Verify that you've only got one hosts file by searching your entire hard drive with Windows File Manager. (Choose the File menu, select Search, start from c:, check the "Search All Subdirectories" checkbox.) If you find other files named hosts, consider removing them.
If you're using Winsock Customization software to give your computer a hostname, ensure that you don't include your domain name in the hostname input area. For example, my computer's complete name is guildenstern.jungle.com; guildenstern is the hostname, jungle.com is the domain name.
If you're using FTP Software's PC/TCP software, ensure that you've provided your domain name in the Domain Completion input area.
Video cards
Call Reveal at 1-800-4-REVEAL and say you're interested in having them fix this problem. They've said if enough interest were shown and it became clear to them that they were losing sales to competitors, Reveal would likely develop a fix for this problem.
Media Vision has said they'll "be unable to provide the additional support that has been requested". Send email to Media Vision's technical support at techsupc@mediavis.com and let them know that without a bug fix your next card won't be one of theirs.
Steve Bernstein of Cisco Systems worked with the developers at Nogatech to fix this problem. You can obtain the appropriate DLL via the World-Wide Web, check http://www.jungle.com/CU-SeeMe/, or by sending Steve email at sbernste@cisco.com.
Turn the camera over.
Networking
Your firewall doesn't know what CU-SeeMe traffic is, and is filtering it out. Your firewall administrator can remedy this by adding filtering rules that explain what CU-SeeMe traffic looks like (i.e. for which port its destined). Following are sample filtering rules. Your firewall may use a slightly different syntax, but your firewall administrator will know what to do.
Replacing the xxx.xxx.xxx.xxx with the address of your computer will allow CU-SeeMe traffic only to and from your computer, everyone else on your network will be unable to use CU-SeeMe. Replacing it with a broadcast address will allow everyone on your network to use CU-SeeMe. The safest arrangement allows CU-SeeMe traffic to a computer that's not connected to your remaining network, or one protected by a router that's properly-configured to provide very tight network security.
|
Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me email. Thanks! |