Previous: Running it all
Up: Running it all
Next: Troubleshooting
Previous Page: Running it all
Next Page: Troubleshooting

Usage

The controls are as follows:

• - allows the current state of the codec controller to be saved or a previously saved state to be loaded. The state files are stored in the current directory the user interface was run from on the machine running the user interface.
• - Allows the ``nice" level of the codec controller process to be changed. The more negative the value, the higher the priority of the codec controller, and the lower the likelihood of other processes causing synchronisation loss.
• - Disconnect the user interface from the remote codec controller leaving the remote codec controller transmitting/receiving in its current state.
• - Kill both the remote codec controller and the user interface.
• - A pull down menu allowing the codec controller to work with both GPT system 261 codecs and BT VC2300 codecs. This only really affects intra frame requests, but getting it wrong could mess up the RS232 control link to the codec. For our purposes a BT VC2100 is a GPT system 261 codec.
• Sets the data rate the H221 stripping and adding software will use. The window next to Baudrate lists the rate you set. The window lists the data rate the codec is running at. If they are different, this could be due to another interface controlling the codec, or simply that the diagnostic reply reporting the was lost.
• A pull down menu specifying which RS232 port on the workstation to use for codec control. This only really affects intra frame requests. Getting it wrong will cause intra frame requests to go out of the wrong RS232 port. If you have any equipment connected there, this may cause a problem.
• Pops up a window allowing you to set the unicast or multicast address of the machine or group you want to transmit to. Presently you need to specify a dotted decimal IP address.
• Pops up a window allowing you to set the unicast or multicast address of the machine or multicast group you want to transmit to. Presently you need to specify a dotted decimal IP address. (Actually this doesn't handle groups properly right now, so if more than one host is sending to a multicast group, this can cause it to get confused - this is a bug and will be fixed (eventually))
• Set the time to live on packets sent to a multicast group. This does not affect packets sent to a unicast address. For multicast addresses, it should be set before starting sending
• Sets the video port to send to and to receive on. This should be set before starting sending and before receiving. Control packets are sent to the next higher port but one, as in the same way IVS 3.2 does.
• Sets the minimum packet size to use for video packets. See the section on communication with other codecs for more details.
• Saves the current state, kills off all the LWPs except the original and user interface ones, restarts them from scratch, waits 10 seconds, and then reloads the original state. This should be a last resort, but press it whenever the codec or codec controller has gone into a strange state.
• Every two seconds or so, the codec controller sends a fast update request to the RS232 control line of the codec, asking for a full intra frame to be inserted. This will correct any image corruption caused by packet loss. If there is no packet loss, or if you need to manually configure the codec via the RS232 line, you should disable these intra requests. The button toggles between and .

The feedback windows are:

• - whether the codec controller is correctly seeing H221 frames. If it's red, there could be a number of causes, but most likely either the interface has failed to connect (see activity), or the data rate is inconsistent between the device driver, the codec, and the codec controller. Under some circumstances, this may be green even though the data rates are inconsistent, so read this together with H261 sync. Reasonably accurate.

• - whether the codec is correctly seeing H261 CRC frames. Similar causes to loss of H221 sync, plus possibly the codec is generating user data or audio in the H221 stream. Accurate.

• - whether the codec is actually transmitting. This light is still buggy - though if it says the codec is transmitting, then it is. However sometimes it says it's not sending when it actually is. If the and are being periodically updated, then it is definitely transmitting.

• - whether the codec is receiving packets. Accurate.

• - what the codec controller thinks the data rate is set to. (as opposed to the display which can be inaccurate.) generally is correct and is wrong if they say different things. Generally accurate.

• - the number of the last 100 packets that should have been received that were lost. Accurate most of the time, but ignore any numbers over 100.

• - the number of pictures per second being transmitted. Accurate when minimum packet size is set to 4. Useless otherwise.

• - the number of kilobits per second actually transmitted (including IP, UDP and RTP headers). This may be less that due to padding being removed (particularly at low frame rates in QCIF mode), or greater than due to the addition is packet headers. Accurate.

• - flashes for every n reads from the codec. If it doesn't flash, the interface is not in contact with the codec controller. If it flashes very quickly, part of the codec controller has crashed and pressing is in order.