Previous: Communicating with other UCL Codec Controllers
Up: Using the UCL H261 Codec Controller
Next: Communicating with the UiO Bitfield Gateway
Previous Page: Communicating with other UCL Codec Controllers
Next Page: Communicating with the UiO Bitfield Gateway
The current version of IVS (IVS3.2) will not display all the images it decodes when receiving from a codec running the UCL codec software, unless the packet size is set to it's minimum value (4). (This may have been fixed by the time you read this).
Obviously, as IVS is decoding in software, it is fairly easy to overload the receiving machine. It is worth running a perfmeter on the receiving machine, and endeavor to keep the CPU load below 100the receiving machine exceeds 100delay will increase drastically, and it will eventually start dropping packets. If the receiving machine is also encoding video, the CPU load will almost certainly exceed 100this. The amount of processing power IVS needs for image decompression can be reduced, if necessary, by displaying the image in black and white (click on the decoding window for the menu), and by reducing the size of the displayed image.
Most versions of IVS 3.2 have a bug in the file video_coder.c, causing IVS to incorrectly encode the Kbit is the RTP H261 header. This results in image corruption when received on a GPT/BT codec causing the codec to lose sync. This generally happens when there is a lot of motion in the scene, and still or near still images get decoded correctly. A new version of IVS is available from INRIA that fixes this problem.
As a rough guideline, on a Sparc 10/41, IVS3.2 can decode 30fps QCIF, and around 10fps CIF at 192Kb/s.