FAQ

    Operating Systems and CPUs

  1. What operating systems support Ultra-Videoconferencing?
  2. What are the CPU requirements for Ultra-Videoconferencing?

    Network

  3. How much network bandwidth is needed for the various modes supported by Ultra-Videoconferencing?
  4. Is Ultra-Videoconferencing RTP-compliant?

    Video

  5. What video modes are supported by Ultra-Videoconferencing?
  6. Why do I see frequent reports of bad frames or missing fragments when receiving video, even though I believe I have plenty of network capacity?
  7. Why do my attempts to transmit video result in a strange (non-) image even though everything looks fine with xawtv?

    Audio

  8. What audio modes and interfaces are supported by Ultra-Videoconferencing?
  9. What should I do if I'm seeing an error "Unsupported sample frequency 44100; card suggests -f 44101"?
  10. Why am I seeing an occasional "Broken pipe" message or losing my audio connection spontaneously after a short period?

    DV

  11. Why do I receive apparent error messages from the software when trying to transmit DV and see the images often freezing or apparently corrupted?
  12. Why am I experiencing serious data loss (dropout) under DV?
  13. Why does my machine lock up occasionally when running DV?

    Latency

  14. How do I achieve minimum latency for interactive applications?
  15. Can I achieve lower latency by building a low-latency kernel?

    Promotional

  16. We are running a public demo and wish to acknowledge your contribution to the project. Where can we find a logo for the McGill Ultra-Videoconferencing system?


    Operating Systems and CPUs

  1. What operating systems support Ultra-Videoconferencing?
    Ultra-Videoconferencing currently runs only under Linux systems. The release version has been compiled under RedHat 8 and is upward compatible to Redhat 9, Fedora Core, and Mandriva systems. We've received a successful report of the software running under SuSE but have not tested under other Linuces; feedback from the user community would be welcome as to the success or failure of the software in other environments.

  2. What are the CPU requirements for Ultra-Videoconferencing?
    The CPU requirements depend entirely on what modes of transport and coding are involved. Ultra-Videoconferencing requires fairly minimal CPU power for audio-only transport but is very demanding for DV decoding, JPEG encoding or decoding, and full-frame uncompressed video processing. These tasks require a PIII-1GHz or better CPU. Because of system scheduler issues, it is strongly recommended that full-frame uncompressed video be run on a separate machine from that used for audio transport; otherwise, performance and stability are likely to suffer.

    Network

  3. How much network bandwidth is needed for the various modes supported by Ultra-Videoconferencing?
    PCM audio with default sampling (44.1 kHz, 16 bit) requires approximately 706 kbps per channel. DV camera output (audio and video) consumes approximately 25 Mbps; JPEG-encoded full-frame video is similar. Uncompressed analog or dc1394 video at full-frame requires anywhere from 148-270 Mbps depending on colorspace employed; this may be reduced to as low as 37 Mbps by selecting quarter-frame size with -w 320 -h 240. Note also the importance of increasing your IP buffer on the receiving machine, as
    described below.

  4. Is Ultra-Videoconferencing RTP-compliant?
    No. Ultra-Videoconferencing is not RTP-compliant, nor do we have any immediate plans to make it so. The software uses its own transport mechanism that was developed specifically for our needs, some of which are incompatible with RTP.

    Video

  5. What video modes are supported by Ultra-Videoconferencing?
    Ultra-Videoconferencing supports video input from either frame grabbers using v4l or v4l2 interfaces (e.g. Bt878 chipset), digital video (DV) cameras, raw 1394 devices, and standard or high-definition Serial Digital Interface (SDI).

  6. Why do I see frequent reports of bad frames or missing fragments when receiving video, even though I believe I have plenty of network capacity?
    The default IP buffers provided by the system are generally far too small to support the demands of video reception, even for compressed video such as DV. In order to correct this, you should (as root) increase the buffer temporarily with sysctl -w net.core.rmem_max=500000 or permanently, by adding the following line to /etc/sysctl.conf:
    net.core.rmem_max=500000

    Note that the latter goes into effect only after a reboot.

  7. Why do my attempts to transmit video result in a strange (non-) image even though everything looks fine with xawtv?
    The Ultra-Videoconferencing software defaults to the first valid video channel as reported by the frame grabber to the operating system. Some cards seem to report a valid channel for configurations that produce invalid video; in this case, you may wish to experiment with the -C flag (./uv -v -C <#> with <#> ranging between 0 and 4.

    Audio

  8. What audio modes and devices are supported by Ultra-Videoconferencing?
    Ultra-Videoconferencing supports audio using either the Open Sound System (OSS) or Advanced Linux Sound Architecture (ALSA) interface. If your audio device is supported by OSS or ALSA drivers, it will likely work with Ultra-Videoconferencing. We have been particularly happy with the M-Audio Delta series devices for multichannel audio, although have been noticing "broken pipe" problems with ALSA under certain Delta interfaces. See
    this FAQ entry if this applies to you.

  9. What should I do if I'm seeing an error "Unsupported sample frequency 44100; card suggests -f 44101"?
    Low-cost consumer sound cards and built-in motherboard audio are often tempermental with respect to the audio frequencies they claim to support. In such a case, you can instruct Ultra-Videoconferencing to use a different sampling frequency with the -f flag, as in ./uv -a -f 44.101.

  10. Why am I seeing an occasional "Broken pipe" message or losing my audio connection spontaneously after a short period?
    We've seen these problems under relatively recent versions of ALSA on the 2.4 kernel, presumably because of slight inconsistencies as ALSA was moving toward the 2.6 model, although the situation may persist under 2.6. In such situations, you should try running in OSS mode (by forcing the audio device with ./uv -a -A /dev/dsp0 or upgrading to a more recent ALSA distribution. User feedback regarding these issues would be most welcome, as our own testing has so far been inconclusive.

    DV

  11. Why do I receive apparent error messages from the software when trying to transmit DV and see the images often freezing or apparently corrupted?
    If you're seeing complaints on the server side as well as on the client, then the problem source is at the video input rather than the network interface. Our experience is that the firewire drivers themselves are far from perfect under Linux (although they have been improving). We suggest you ensure that the computer being used is relatively current (e.g. P4-2GHz or better) and not experiencing any transient load due to other processes, in particular as related to interrupt requests.

  12. Why am I experiencing serious data loss (dropout) under DV?
    If you're using a Pentium 4, the hyperthreading support of the hardware makes the machine appear as a logical multiprocessor, which causes havoc with the DV libraries. Our advice in this case is to disable hyperthreading (HT) by making sure that you are running a single-processor kernel.

  13. Why does my machine lock up occasionally when running DV?
    The DV device driver is known to have some stability issues, particularly under dual-processor systems. If you are primarily using the software for DV transport, we strongly suggest running the Ultra-Videoconferencing server on a powerful single-processor machine.

    Latency

  14. How do I achieve minimum latency for interactive applications?
    Many factors dictate end-to-end latency in audio and video transport. These include characteristics of the audio and video devices, the audio and video interface buffers, CPU scheduling, PC bus and network bandwidth, and network path delay. While most of these factors are beyond the control of typical users, general tips are to avoid video codecs (i.e. DV or JPEG encoding) as these may add anywhere from 10-60 ms of latency and low-cost sound cards as these typically employ fairly large buffers, thus increasing audio latency. Note that apart from DV, which bundles together audio and video, Ultra-Videoconferencing makes no effort to synchronize the two streams. Users wishing to adjust synchronization manually may do so using the -l parameter.

    We have measured end-to-end video latency at approximately 75ms for analog video, 100ms for DV, and 120ms for JPEG. Audio latency can be lower than 20ms when using professional sound cards, as these allow for minimal buffering.

  15. Can I achieve lower latency by building a low-latency kernel?
    Our experience has been that the low-latency kernel provides no discernable improvement with respect to reducing audio and video latency and suffers from a decrease in stability. We would be interested to hear of more recent user experience with respect to this factor.

    Promotional

  16. We are running a public demo and wish to acknowledge your contribution to the project. Where can we find a logo for the McGill Ultra-Videoconferencing system?
    Our logo can be downloaded in either
    gif or eps format.

Last updated 29 September 2005