Actually, as I have been working on this over time I have come to realize that the current gstreamer (or any RTP code) cannot possibly work. There is important information in the first RTP stream that is lost in the conversion to MP2T. Specifically the fact that there are multiple RTP packets required for the frame which is signaled via the FU-A construct. However, that seems to be OK for the MP2T. When the conversion back to RTP is made, it is only processing those MP2T packets that were created from each single RTP packet in the original stream. I don't think that there is any way in the normal scheme to correct that. I think that to correct it I will need to modify h264parse (my first element in the conversion back to RTP) to collect input buffers until the first_mb_in_slice == zero. Then the previous data can be processed and pushed out as a single buffer for rtph264pay to process. I have seen other places in the code of both elements that make that same assumption, so it seems safe to me. <div class="gmail_quote">On Thu, Mar 28, 2013 at 2:25 PM, Olivier Crête <<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Thu, 2013-03-28 at 10:44 -0400, Chuck Crisler wrote: > I specifically need rtph264pay to generate packetized data regardless > of the input. At least, I *THINK* that is what I need. Currently in > converting from MP2T to RTP (when the original source was also RTP) > every packet has the marker bit set. I have seen in many traces that > rtph264pay is classifying the stream as bytestream. I have tried > setting the h264parse element (before the rtph264pay element in the > pipeline) to '0' and the access-unit to true, but that generated some > internal failure which I did not investigate. I am hoping that by > forcing 'packetized' I can get the marker bit set correctly. > Everything else if good. </div>The concept of bytestream vs packetized does not apply to the RTP payload format, it is a distinct 3rd format. The RTP packets always contain either a full NAL unit, more than one NAL unit or fragments on a NAL unit if the NAL unit is larger than the MTU. This should all happen automatically from your point of view. The marker bit should be set on any RTP packets that represents the end of an Access Unit (which is one or more consecutive NAL units that make up a frame). A bug that made the marker bit be set too often was fixed in gst-plugins-good 0.10.31, so make sure you have that version at least. -- Olivier Crête <a href="mailto:olivier.crete@collabora.com">olivier.crete@collabora.com</a> <div class="HOEnZb"><div class="h5"> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </div></div></blockquote></div>