Video Fast Update
- Kelli Higdon
When a Codec sends out a video frame, it initially will transmit frames described as I frames (reference frames). The I Frame contains the complete information needed to display a picture. To save on bandwidth, a technique is used where the subsequent video packets sent after the I Frame are just updates to the initial picture instead of continuously transmitting the I frames. These updates which are labeled P Frames are sent to minimize the amount of video data that need to be transmitted from one video system to another. Occasionally the P Frames become corrupted through different issues such as packet loss, jitter, or too much information. At this point the far end receiving the video would request a Video Fast Update request. The VFU requests that a complete new I Frame be sent with the full reference frame of video information. Once the new I-Frame is sent, any subsequent packets sent after the updated I Frame will be P-Frames. The VFU feature is always running on the IMG 2020 and cannot be disabled.
Call Flow Diagram (SIP to SIP)
The call flows below display the Video Fast Update feature with both transcoding and no transcoding.
Video Fast Update (No Transcoding)
Video is being transmitted from the Video Source to the SIP Video Receiver through the IMG 2020. First the I-Frame is sent then subsequent P-Frames are sent.* This cycle continues until a video loss/corruption occurs. The subsequent P-Frames sent under certain circumstances can get corrupted and video loss can happen. In this instance the receiver of the video will send out a VFU request to the transmitter of the video.* The VFU request is initially sent in a SIP INFO message to the Video Controller of the IMG 2020. The Video Controller interworks the VFU request and sends the request out to the SIP Video Source.* Once the VFU Request is received by the Video Source, the source then transmits an I Frame to the Video Receiver over the RTP stream. Once the I-Frame is received, subsequent P-Frames will follow.
Video Fast Update (Transcoded)
Video is being transmitted from the Video Source to the SIP Video Receiver through the IMG 2020. The IMG 2020 accepts the video using the H.263_2000 codec. The video is interworked and transmitted to the video receiver using the H.264 codec. First the I-Frame is sent then subsequent P-Frames are sent.
This cycle continues until a video loss/corruption occurs. The subsequent P-Frames sent under certain circumstances can get corrupted and video loss can happen. In this instance the receiver of the video will send out a VFU request to the transmitter of the video.
The VFU request is initially sent in a SIP INFO message to the Video Controller of the IMG 2020. The Video Controller interworks the VFU request and sends the request out to the SIP Video Source.
The IMG 2020 Video Controller then transmits an I-Frame and subsequent P-Frames using the H.264 codec back to the Video receiver.
While this is happening, the Video source receives the VFU request from the IMG 2020 and transmits the I-Frame and subsequent P-Frames back to the IMG 2020 using the H.263_2000 codec.
The IMG 2020 interworks these frames into the H.264 Codec and sends an I-Frame with its subsequent P-Frames back to the Video Receiver.
VFU Request Delay Handling
VFU Delayed handling is a functionality that allows the IMG 2020 to handle ill-behaved applications that may flood the IMG 2020 with VFU requests. The IMG 2020 would in turn flood the remote video transmitter by interworking and sending it these requests. The remote video receiver would also get flooded with I-Frame requests from the IMG 2020. The SIP VFU object is used to handle this type of issue. The IMG 2020 can configure in a time delay where the IMG 2020 will not handle any additional VFU requests until after the delay expires. Refer to information below.
Call Flow Diagram VFU Delay Handling
The call flow below demonstrates what happens when an I Frame request is received while the Request Delay Timer is still active.
An I-Frame is transmitted from the Video Source to the Video Receiver through the IMG 2020. The generated I-Frame could have been the result of normal I-Frame generation or from a previous VFU request message.* As the IMG 2020 generates the I-Frame to send to the video receiver, it also starts a Request Time Delay and Periodic Time delay Timer. The Request Time Delay timer was initially configured in the VFU Delay field of the SIP VFU Web GUI object.* The Video receiver then generates a VFU Request A due to some type of video issue. The IMG 2020 receives the request and interworks it to the Video Source. At the same time, the Request Time Delay Time and Periodic Time Delay Timers are started.* The Video Source generates an I-Frame from the VFU Request A and sends it back to the IMG 2020. The 2020 receives the I-Frame but waits until the Request Delay Timer expires. Once the timer expires, the IMG 2020 then transmits the I-Frame received from the Video Source to the Video Receiver.* The Periodic Time Delay Timer is then canceled and the two timers are then restarted.
VFU Request Monitoring
Part of the Video Fast Update feature is monitoring the number of VFU requests that are received within a given time interval. When the IMG 2020 receives more VFU requests in a specific time interval, an alarm event is logged. The logged events will indicate the number of VFU requests, the time of the events, and information needed to identify the remote device transmitting the VFU requests. The VFU Request monitoring feature is configured in the SIP VFU object using the VFU Interval and VFU Limit fields. The VFU Request Monitoring functionality is described below. The example below will set the VFU Interval field at 5 seconds and the VFU Limit field at 5 requests.
As displayed in the diagram above, an entity in the SIP network is sending the IMG 2020 lots of VFU Requests. The IMG 2020 is set so that if within one 5 second interval if the threshold configured in the VFU Limit field is exceeded, the IMG 2020 will generate an alarm log event.
As displayed above, as the VFU requests are received that the five second interval between 0 and 5 seconds that five VFU requests are received. This does not exceed the threshold set in the VFU Limit field so no alarms are generated.
During the interval between the 2.5 and 6.5 seconds six VFU requests are received. This exceeds the threshold set in the VFU Limit field so and Alarm is generated and sent to the EventView application.
At this point the VFU requests in the list are cleared.
In the 5 second interval between 7 seconds and 12 seconds, 6 more VFU requests are received. This will generate a second alarm and is sent to the EventView application.This process continues as long as the VFU Requests are being received. During any 5 second interval if the value configured in the VFU Limit field is exceeded during the interval set in the VFU Interval field, an alarm is generated and the list is cleared. Refer to the topic for more information on each of these fields.