I have been working on a single problem for several weeks. I think that I now know the source and need some guidance to implement the solution. I am using gstreamer 0.10.30 and can't change right now. Our system distributes video using multicast MP2T. We are adding support for iPads. The iPads run a program called iDoubs which uses x264 and ffmpeg. iDoubs only supports RTP. Our system does provide conversion to/from RTP to bring video in or send it out. If we generate video in the system and transmux it to RTP for an iPad, it works fine. If an iPad generates video for our system it also works fine on our systems. However, video sent back to another connected iPad fails to display the video. This stream originated as RTP, was transmuxed to MP2T and then transmuxed back to RTP. The RTP stream isn't perfect but it is legal. I can insert a system running a gstreamer script and successfully display the stream. Also, I have displayed the stream using other technologies. The problem is that every RTP packet has the marker bit set rather than just the last one in a frame. iDoubs keys off of the marker bit to call the decoder, so it is calling the decoder with partial frames. The problem seems to be that when we convert from RTP to MP2T the MPEG muxer treats different RTP packets as separate frames and actually inserts start codes at the beginning of the data from the next packet. That doesn't seem to cause display problems but does cause problems in the conversion back to RTP. The h264parse element searches the input buffer for the next start code and assumes that the subsequent data is a new frame, so it sets the marker bit. It will accumulate multiple MP2T packets to make a MTU sized RTP packet. Typically you should fix a problem at the source, which means that the MPEG parser should also parse the next input buffer to see if the first macroblock ID is zero. If not, perhaps it should assume that the buffer is still part of the original frame and not insert the start code. My concern about that approach is that the current display of the MP2T stream works and I don't want to break that. Also, that buffer might not begin on a macroblock boundary, so I would have to parse the stream to find the macroblock. A second approach is to modify the h264parse element to do the same thing. After finding a start code, look to see if the next macroblock ID is zero. If not, effectively ignore and remove the start code. My concern here is that I have seen that packets are broken inside of macroblocks (I thought that was a no-no) so I can't assume that the beginning of a buffer is also the beginning of a macroblock. I would have to parse the entire stream, skipping the start code to see if it parsed and if the macroblock ID was non-zero. Not easy given the variable coding of H264. I don't know much about MP2T and I am not sure which approach is 'better'. I would greatly appreciate guidance and info from those who know these protocols. Thank you, Chuck Crisler