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. BTW - my problem yesterday turned out to be multiple serious bugs in the iDoubs package actually sending out RTP packets with 0 0 1 due to searching for 0 0 0 1 in the encoded buffer (the encoder embedded 0 0 1 to delineate slices), and consequently not ever finding or replacing any of the embedded start codes. <div class="gmail_quote">On Thu, Mar 28, 2013 at 10:16 AM, Tim-Philipp Müller <<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thu, 2013-03-28 at 10:00 -0400, Chuck Crisler wrote: Hi Chuck, <div><div class="h5"> > In the rtph264pay element, the packetized structure member is set to > true iff codec_data is specified. Why? I realize that in many uses, > when this element is used the sprops data is available and can be > supplied. In many cases where the sprops data isn't available, the > stream should be bytestream. However, the application programmer knows > the use of the element in the pipeline, so the element should allow a > property (such as bytestream in the h264parse element) that allows the > user to set the type, with the current behavior as the default if > nothing is set. In many use cases, including video conferencing, you > don't know the codec data apriori, or even care. Also, while a stream > is running, the resolution often changes, invalidating the sprops > data. However, those changes are signaled in the bitstream. </div></div>Sorry, but what exactly is the problem you are trying to solve or use case you're trying to support, and that rtph264pay doesn't handle currently? rtph264pay accepts both byte-stream and AVC as input. The presence of a codec_data field implies that the input is AVC, which will be nicely packetised. If the input is byte-stream format, the codec data (SPS/PPS) will be signalled in the byte stream. Cheers -Tim _______________________________________________ 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> </blockquote></div>