MPEG-4 Video Transfer with SCTP-Friendly Rate Control Mohamed N. El Derini

Transcription

1 MPEG-4 Video Transfer with SCTP-Friendly Rate Control Mohamed N. El Derini Amr A.Elshikh Faculty of Engineering, Alexandria University, Egypt Computer Science and Automatic Control Department ABSTRACT Multimedia applications are known to consume network bandwidth in a greedy manner because they depend on the UDP transport protocol which doesn t pay attention to resource sharing nor congestion state of the network. In this paper a modified version of SCTP protocol is used to transfer video data, it tries to make best use of different existing features of SCTP such as partial reliability, partial order and multiple streams. It deploys a new algorithm that tries to share bandwidth fairly and resolves network congestion by detecting congestion state of the network and adapt transfer rate of the video data according to this congestion state. It takes into consideration the nature of MPEG-4 data that was encoded into 3 different types of frames with different weights of importance. At the end of this paper, a simulation experiments using NS-2 show that adapting such algorithm would reduce data send rate and increase data receive rate in congestion periods with little price to pay in slight delay of frames which could be compensated by deploying buffering. Such algorithm has no side effect on non-congested network during normal operations. Keywords: Congestion Control, MPEG-4, SCTP, Video Streaming. 1. INTRODUCTION SCTP (Stream Control Transmition Protocol) is a relatively new IP transport protocol which provides flexible delivery and reliable transfer within IP networks [1]. SCTP provides numerous advantages over user datagram protocol (UDP) and transmission control protocol (TCP). For instance, SCTP combines the datagram orientation of UDP with the sequencing and reliability of TCP. Additionally, SCTP uses multi-stream, message-oriented routing in multi-homed environments [2]. As it is still relatively new transport protocol, very few research is done to explore its features comparing to other protocols as shown in Figure 1 and Figure 2. Figure 1: SCTP Number of Citations [12] Figure 2: TCP Number of Citations [12] MPEG-4 standard is becoming a popular format for streaming multimedia on the Internet. MPEG- 4 encodes the video bit-stream in groups of different frame types (I, P and B frames), where the I frame is independent, while the P frames depend on the previous I or P frame and B frames depend on the previous and the next I or P frames in the group. This means that loosing I or P frame (for example due to network congestion) causes a noticeable worsening of the video quality of all the frames in the group. The transport protocol utilized by MPEG-4 is RTP/UDP. RTP, being concerned with real-time traffic, does not provide reliable delivery. 1

2 The idea of this paper is to use previous work results [5, 8, 1] by giving reliability and priority to I frames and deploying new algorithm to detect congestion state of the network, This is done by adding a congestion state variable which monitors timeouts, fastrtx and SACKs to reflect how much the network is congested and use this new variable to control the reliability level and the rate of the video data and tells which type of frames to be sent (only I frames, I/P frames or all I/P/B frames), This gives an advantage over UDP by paying attention to the congestion state of the network and telling in case of congestion which type of frames would worsen this congestion so M-SCTP (Modified-SCTP) would be able to use the limited bandwidth available during congestion more than UDP. 2. BAKGROUND 2.1 SCTP Definition: Stream control transmission protocol (SCTP) is an end-to-end, connection-oriented protocol that transports data in independent sequenced streams[1]. The fundamental SCTP properties include the following [1]: Acknowledgement Mechanisms Within an association, selective acknowledgement (SACK) chunks acknowledge the receipt of data chunks. SACK chunks are also used to inform the endpoint of duplicated or missing chunks. Path Selection and Monitoring SCTP packets are routed to the destination IP address of a peer endpoint through a "primary path". The primary path allows the user to determine the primary route for data flow. In addition, alternate paths exist for each IP address supported by the peer endpoint. SCTP closely monitors the transmission paths to the peer endpoint using HEARTBEAT chunks that test the connectivity of a path. Multi-Streaming Feature- It separates and transmits user data on multiple SCTP streams. These streams are capable of independent, sequenced delivery. Message loss in a particular stream will only delay delivery within that stream. Therefore, other streams within an association are not affected. Through multi-streaming, SCTP eliminates unnecessary blocking that often occurs in TCP transmissions. Flow and Congestion Control While SCTP flow control is based on each association, congestion control is established within each transmission path. The peer endpoint assigns a receiver-window variable for flow control. The receiver-window variable alerts the endpoint of the amount of space available in the peer endpoint's inbound buffer. SCTP deploys congestion control within each stream using a congestion-window variable. This variable limits the number of bytes that may be sent before an acknowledgement is received. A set of flow and congestion control parameters is retained within the association and each transmission path. SCTP packet structure The common header consists of 12 bytes includes the following as shown in Figure 3: The source port address The destination port address The verification tag The checksum of the entire packet 2

3 Figure 3: SCTP Packet Header Structure 2.1 MPEG-4 MPEG (Moving Picture Experts Group) is the ISO committee which is responsible for defining the various MPEG video specifications [7]. MPEG-4 is intended for video conferencing, Internet distribution and similar applications using low bandwidths, but it is also a contender for HDTV. MPEG-4 Frame Types MPEG-4 Movie contains a complete image sequence, possibly hundreds or thousands of frames. These frames are grouped into GOP (Group of Pictures), The GOP contains a small number of frames (typically 12) coded so that they can be decoded completely as a unit, without reference to frames outside of the group. There are three types of frames: I-frames (Intra coded frames) use DCT (Discrete Cousine Transform) encoding only to compress a single frame without reference to any other frame in the sequence. Typically I-frames are encoded with 2 bits per pixel on average. This gives a compression ratio of 24:1. For random playing of MPEG video, the decoder must start decoding from an I-frame not a P-frame. I-frames are inserted every 12 to 15 frames and are used to start a sequence, allowing video to be played from random positions and for fast forward/reverse. Decoding of video can start only at an I- frame. P-frames (Predicted frames) are coded as differences from the last I or P frame. The new P-frame is first predicted by taking the last I or P frame and 'predicting' the values of each new pixel. The P-frames use Motion Prediction and DCT encoding. As a result the P-frames will give a compression ratio better than the I-frames but depending on the amount of motion present. The differences between the predicted and actual values are encoded. Most prediction errors will be small since pixel values do not have large changes within a small area. The error values will therefore compress better than the values themselves. B-frames (Bi-directional frames) are coded as differences from the last or next I or P frame. The B-frames use prediction as for the P-frames but for each block either the previous I or P frame or the next I or P frame is used. The P-frames use Motion Prediction and DCT encoding. Because the B-frames require both previous and subsequent frames for correct decoding, the order of MPEG frames as read is not the same as the displayed order. This gives improved compression compared with the P-frames, because it is possible to choose for every macroblock whether the previous or the next frame is taken for comparison. Figure 4 shows frames that are interleaved in a sequence IBBPBBP or IBPBPBPBP. The former is more difficult to encode but provides a higher compression ratio than the latter. 3

4 Figure 4: MPEG-4 GOP The main purpose of the GOP is to allow editing and splicing of video material from different sources and to allow rapid forward or reverse searching through sequences. A GOP usually represents about half a second of the image sequence. Figure 4 also shows that the coded frames depend on each other. The first frame of the GOP is always I frame, which may be decoded without needing data from any other frame. At regular intervals through the GOP, there are P frames, which are coded relative to a prediction from the previous I or P frame in the GOP. Between each pair of I / P frames there 3. MPEG-4 Video Transfer with SCTP-Friendly Rate Control 3.1 Proposed Solution Error in the transmission of I-frame data will cause degradation of quality not only for the I- frame, but also in all P-frames and B-frames that are predicted from the I-frame and also error in P frames would make the same with the B-Frames, which are predicted from them. If the error on I or P frame data is high enough to cause the decoder to drop the I or P frame, the playout quality of the video stream will be affected severely. Under these considerations, SCTP s features of variable reliability, out of order delivery, multistreaming, prioritization and chunk bundling can be used to optimize the quality of the transmitted MPEG-4 video stream The next algorithm is used to maximize the receive rate and minimize the send rate of video data in congestion periods without affecting normal receive & send rate in normal cases: If Network Not Congested & High bandwidth available Send I frame with reliability 1 Send B/P frame with reliability If Network Not Congested & Low bandwidth available Send I frame with reliability 1 Send P frames with reliability Don t send B frames If Network Congested Send I frame with reliability Don t send B/P frames To detect network congestion status a new variable is added called CongestionState, which takes value from 1 to 1 1 to 3: Considered to be Congested 4 to 7 : Considered to be Non-Congested with Low bandwidth 8 to 1: Considered to be Non-Congested with High bandwidth if (econgestionstate <= 3) { if (type_ == 1) { /*I Frames*/ usreliability = ; send_frame;} else /*Do Nothing*/} else if (econgestionstate >= 4 && econgestionstate <= 7) { if (type_ == 1) { /*I Frame*/ 4

5 usreliability = 1; send_frame;} else if (type_ == 2) { /*P Frame*/ usreliability = ; send_frame;} else /*Do Nothing*/} else if (econgestionstate >= 8) { if (type_ == 1) { /*I Frame*/ usreliability = 1; send_frame;} else { /*B,P Frame*/ usreliability = ; send_frame;} } CongestionState is modified as followed: Initialize: CongestionState = 4 Timeout: CongestionState = 1 FastRTX (Fast Retransmission): CongestionState = CongestionState - 2 SACK Received: CongestionState = CongestionState + 1 CongestionState has been chosen to start at low value (4) not to pump too much data in the network and creates a false congestion state if the network has low bandwidth in the first place. Starting CongestionState at 4 would give the opportunity for the algorithm to probe the network state gradually. Also not starting with value (1) would give the algorithm the opportunity to check for the network status and maintain a good quality for the picture if we have high bandwidth network. At each FastRTX the CongestionState is reduced by value 2 to reflect rapidly bottlenecks in the network and hence would reduce the send rate and not to worsen the network congestion. While increasing the CongestionState by only value 1 would make it more conservative on judging the network congestion. Timeouts would put CongestionState to value 1 to reduce sending rate to minimum and participate in resolving the network congestion. 1) Algorithm for calculation of received data Read Video data file If frame sent and received If type is I then Add frame to receive table If type is P or B frame and its reference frame(s) is received then Add frame to receive table 2) Algorithm for calculation of sent data Read Video data file If frame sent then Add frame to sent table 3) Algorithm for calculation of delay Read Video data file If frame sent and received then 5

6 Update delay table by time difference between time sent and received Unordered delivery is enabled, so that the SCTP receiver passes data to the application as it arrives on the interface. Chunk bundling is enabled to bundle different types of frames which would be beneficial in consecutive frames with little motion. Multistreaming is one of the main features to enable each type of frames to be sent on a different stream to have maximum control over the parameters of that stream. 3.2 Simulation Results Used Tools CYGWIN: Work environment for simulation package to simulate UNIX environment on windows platform. NS 2.8: Object-oriented, discrete event driven network simulator developed at UC Berkely written in C++ and OTcl. NS (Modification): Add CongestionState variable to SCTP.h (header file) Modify TrafficTrace.cc code to implement previous algorithm, read new structure of trace file (time, size, type) and write back to an output file for which packet is sent and which type and size Modify SCTP.cc to use CongestionState variable NAM: The network animator NAM is a simple tool for animating packet trace data. Trace data Analysis tool (Developed tool): A tool developed to analyze data from NS trace files and record number of bytes received/sent for UDP & SCTP connections taking into consideration frame data Bundling process, IP header size, SCTP header size and Dropped packets influence (I or B/P packet) on the number of received frames Model: Different simulation experiments have been executed with different models and different network implementations but only one group is shown here due to space limitation as shown in Figure 5 the simulation model is built as follows: 1 client node, 3 server nodes (1 main server and 2 traffic nodes) and a router. Link between router and client has queue limit of 5 and bandwidth of.5 Mbyte and delay of 2 ms and of type DropTail. SCTP agent is linked to each server and a sink agent is linked to the client and each agent has a traffic generator linked to a trace file In UDP experiment UDP agent is linked to each server and a sink agent is linked to the client Trace files is 2 second of a sample video data (die hard movie is used) for the main server and 5 seconds for both traffic nodes. Main server data starts at and stops after 2 seconds, Traffic 1 starts at second 3 and stops at second 8, Traffic 2 starts at second 5 and stops at second 1 6

7 Figure 5: Experiment Model in NS-2 4. RESULTS Performance parameters that have been monitored to measure impact of the new algorithm on the performance of SCTP are listed here. A- Send Rate As shown in Figure 6 the send rate of video data is almost the same using UDP and M-SCTP in normal cases but in congestion state between second 3 and second 1 when the traffic nodes starts to pump the data (shaded curves) the M-SCTP reduces the send rate as it sensed the network congestion during this period and depending on how bad the congestion is, the M-SCTP sends only I frames with reliability or I/P frames and I frames with reliability Sent Bytes time M-SCTP' 'Traffic_1' 'Traffic_2' 'UDP' Figure 6: Send Rate B- Congestion State In figure 7 congestion state variable is illustrated, It starts with value 4 and starts to grow until it hits the ceiling 1 and stays like that until traffic nodes start and the congestion state variable reflects these actions rapidly as it s reduced by 2 and starts to go down and become unstable until the traffic nodes stop and in return congestion state goes back to value 1 again 7

8 time Figure 7: Congestion State C- Receive Rate Although the send rate for M-SCTP is reduced during the congestion period but the receive rate enhanced during the same period as shown in Figure 8 as reducing the send rate will give the sent packets a better chance and a high probability to use the available bandwidth, also only useful packets are sent. This gives the client a good chance to use the received packets without dropping them if their reference packets are not received. In this experiment we found that the send rate is reduced by about 19% and the receive rate is increased by about 23%. In normal congestion states the receive rate would almost be the same time M-SCTP' 'UDP' Figure 8: RECEIVE RATE It is reasonable to mention here that the previous enhancement have prices to pay which are - The control packets for SCTP (Heart beat, SACK, etc ) but it is still a reasonable price as during congestion state it is compensated by the non-sent packets and during non-congestion state it would be a slight increase of used bandwidth. Delay in time of receiving packets but it is still a reasonable price because of the following reasons 1) only I frames are partial reliable with 1 reliability 2) unordered delivery ensures immediate delivery of received packets 3) multiple streams (no head of line blocking) 4) during congestion state unsent packets make best use of congestion window 5) data buffer in the client side 8

9 But it s also worth mentioning that when adequate bandwidth is available most of the UDP and M-SCTP curves are identical as in our example after second 1 which proves that UDP and M- SCTP functions almost the same under good bandwidth availability. D- Packet Delay As shown in figure 9 the delay in packets are almost the same in both experiments using UDP, M- SCTP except during congestion period where packet delay would be increased because of the retransmission of the I frames but it is still compensated by buffering video data by the client Delay in ms TSN M-SCTP' 'UDP' Figure 9: Packet Delay E- Quality of transmitted MPEG-4 video The quality of video is mostly subject to personal opinion, but there are 2 main scientific criterions to evaluate the quality of video. The MOS (mean opinion score) for the average opinion but in order to measure it lots of people had to be involved which makes it so hard to use as a measurement. Another criterion is PSNR (Peak Signal to Noise Ratio) which focuses on frame per frame the difference between the original and received data which is not applicable here in this paper as we don t concern about the content of the frame itself but more on the frame has been received or not. So another approach is being used which is the number of frames per GOP received. Figure 1 shows that in case of congestion period M-SCTP is nearer to the no-error line more than UDP which means more frames are received per GOP. It should be mentioned here that the more number of frames received in GOP the less flicker and smoother the video would be Number of Frames 'GOP' GOP Figure 1: Video Quality 'M_SCTP' 'UDP' Ideal 9

10 3.2.4 Related Work There have been previous attempts to use SCTP in transmitting MPEG-4 data but most of these attempts only concentrated on the usage of partial reliability and partial order advantages of SCTP [5, 8, and 1]. This paper is built on previous work and extending it to use the new explained algorithm to control the sending rate and enhance throughput during congestion periods and make it more network friendly protocol, Figure 11 shows a comparison between M-SCTP and SCTP (send all frames and make I frame with reliability 1) and UDP, The comparison criteria is the number of frames per GOP received, It shows that M-SCTP excels SCTP in congestion period Number of Received Frames GOP 'M_SCTP' SCTP' 'UDP' Ideal Figure 11: M-SCTP, SCTP, UDP Quality Comparison CONCLUSION In this paper a modified version of SCTP protocol is proposed to be used instead of UDP transport protocol to transfer video data. This modified-sctp depends on a congestion variable which reflects the congestion status of a network to selectively send video data. An evaluation for such proposal is presented which showed an enhancement of the receiving rate although reduction the send rate during congestion state and almost no change during normal operation mode of the network. FUTURE WORK An extension to such work is to change the send rate of the I frames and the P frames according to the congestion state variable that in turn could be enhanced to reflect more accurately the status of the network by incorporating RTT (Round Trip Time) change to calculate it Also an encapsulation of all the code into SCTP agent code to release a new SCTP agent in NS would be a field of investigation. Monitor RTX policy and modify it according to congestion state would be an advantage to get more enhancements in the send and the receive rate. More investigation should be done regarding when to activate the algorithm to control the send rate and when not as the receive rate were found to be enhanced in the range between -5% to 25%. 1

11 REFERENCES [1] R. Stewart and Q. Xie et. al., Stream control transmission protocol. IETF RFC 296, October 2. [2] R. Stewart and C. Metz, SCTP: New transport protocol for TCP/IP, IEEE Internet Computing, vol. 5, no. 6, pp , November/December 21 [3] A. Jungmaier, Performance evaluation of the stream control transmission protocol, Proceedings of the IEEE Conference 2 on High Performance Switching and Routing, Heidelberg, Germany, pp , June 2. [4] A. Jungmaier, E.P. Rathgeb, and M. Tuxen, On the use of SCTP in failover-scenarios, International Conference on Information Systems, Analysis and Synthesis, Orlando, Florida, pp , July 22. [5] A.L. Caro, P.D. Amer, P.T. Conrad, and G.J. Heinz, Improving multimedia performance over lossy networks via SCTP, ATIRP 21, College Park, MD, March 21. [6] NS-2 SCTP Module home page [7] Naoki Wakamiya, Masaki Miyabayashi, Masayuki Murata, Hideo Miyahara MPEG- 4 Video Transfer with TCP- Friendly Rate Control 4th IFIP/IEEE International Conference on Management of Multimedia Networks and Services [8] M. Molteni and M. Villari_ Using SCTP with Partial Reliability for MPEG-4 Multimedia Streaming BSDCon Europe 22 [9] SCTP for the Linux Kernel (LKSCTP). lksctp.sourceforge.net/index.html. [1] Alex Balk, Marc Sigler, Mario Gerla, M. Y. Sanadidi Investigation of MPEG- 4 Video Streaming over SCTP The International Journal of Computer and Telecommunications Networking Volume 44, Issue 4 (March 24) [11] Shaojian Fu and Mohammed Atiquzzaman SCTP: State of the art in Research, Products, and Technical Challenges IEEE Communications Magazine, April 24, Vol.42 No.4 [12]