ENCAPSULATION OF MPEG-I STREAMS INTO RTP PACKETS (December 13, 1999) ================================================ Project Description: =================== MPEG streams are quite complex in implementation since there are several layers to it. One must understand thoroughly how the layers combine together to form a complete stream. The same holds when decoding an MPEG stream. The project is to decode an MPEG stream and wrap the necessary RTP header information around it, hence forming RTP packets with an MPEG payload. The packetization is based on RFC2250. To summurize the contents of an RTP packet with MPEG payload: the RTP packet contains the fixed 8 byte RTP header, followed by a 4-byte MPEG video specific header. The contents of the header are explained in detail in RFC2250, but here is a summury of the contents of the two headres: RTP fixed header: version: 2 bits : protocol version p: 1 bit : padding flag x: 1 bit : header extension flag cc: 4 bits: CSRC count m: 1 bit : GOP end present or 1st talkspurt flag pt: 7 bit : payload type seq: 16 bits : sequence number pts: 32 bits : timestamp MPEG video specific header: MBZ : 5 bits : unused T : 1 bit : video specific head extension flag TR: 10 bits : Temporal Reference AN: 1 bit : Active N bit N: 1 bit : N bit; used in MPEG 2 S: 1 bit : sequence header present flag B: 1 bit : set if start of payload is slice start code E: 1 bit : set if last byte of payload is slice end code P: 3 bits : picture type; 1=I,2=P,3=B,4=D FBV: 1 bit : full_pel_backward_vector BFC: 3 bits : backward_f_code FFV: 1 bit : full_pel_forward_vector FFC: 3 bits : forward_f_code How the decoding works: ====================== The program reads 1Kbyte of data from the input (MPEG file). It then searches for a 32 bit startcode. The startcodes are byte aligned, and each MPEG video layer has its own start code (eg. GOP startcode, picture startcode, slice startcode, etc..) According to the value of the startcode, the proper information is extracted from the bits that follow the startcode. That info is then placed in the proper bits in the headers. Once the whole buffer is processed, it is then ready to be sent together with the two headers that have been formed. Proper checking is made at the end of the payload as follows: it is not allowed to have a startcode at the end of the payload. Also if a picture ends in a payload, no more data is placed following the end of the picture. The reason for that is the next picture could be of different type, and there's only one place for the picture type in the Mpeg Fixed header. Given the above checking on the payload, the payload size may varry. The size can be upto 1 Kbyte though ( which can be changed in the program, in the header file). Limitations of the code: ======================== 1) Only MPEG I streams can be encapsulated. 2) The MPEG stream is encapsulted only at the video sequence layer (top layer) and not at the picture or the slice layer. The reason is that RFC2250 did not specify fields for several vital information. Such information is necessary to reconstruct a stream encoded at the picture layer or GOP layer. These fields are: muxrate, the SCR (System Clock Reference), the MPEG Packet Length (packet layer), buffer size, and the DTS (decoding timestamp). 3) RFC2250 specified a 32 bit in the rtp header for the presentation timestamp (PTS). However, in MPEG streams, the PTS is 33 bits long. 4) As of December 1999, no known player exists (yet) that plays MPEG encapsulted in RTP. However, there are players for which the SDK (system development Kit) is provided. As a separate project, one may write a pluggin to for the player to accept RTP packets. An example of such players is the MpTV. Developer: Joseph Hazboun (973) 428-7720