I am working with video that is generally in MP2T format/protocol (yuck) but I need to convert it to RTP (H264). I have tried a couple of pipelines and nothing is working. Here are my test pipelines. gst-launch udpsrc port=$1 ! mpegtsdemux ! video/x-h264 ! \ rtph264pay pt=96 ! udpsink host=$2 port=$3 The other pipeline is similar but has a decoder and encoder stuck in between the demux and mux. The idea here is that the MPEGTSDEMUX should (according to my thinking) generate a buffer that is ready for an H264 decoder, which should be the same as the output of an H264 encoder. Hence, I feed it directly into the RTP payloader. The resulting stream can't be decoded by a gstreamer pipeline or VLC. If I try decoding the MP2TDemux output and routing that to an H264 Encoder, then the RTP payloader, it still doesn't work (which really surprises me). In this case the RTP payloader generates constant 88 byte packets that do seem to be valid RTP packets. If I simply capture, encode and transmit, either MP2T or RTP, then decode/display, it works fine (even though with RTP none of the packets have the marker bit set). I can also capture, encoder, MP2T mux, transmit, MP2T demux, RTP payload, transmit, RTP deplayload, decode and display - works fine. All of my testing so far has been with an 'ancient' version of gstreamer and plugins. I am working to move to later versions but am limited to CentOS 6.0 and, with the inter-dependencies in gstreamer, I am not sure how far forward I can move. Even one version is difficult to do. I haven't yet looked at the source code to understand what the MP2T demux and RTP mux are doing. I know RTP pretty well but don't know anything about MP2T (and I would rather not, but that seems unavoidable at this point). I was thinking about (after learning what is going on) maybe writing a plugin to sit between the MP2T demux and RTP mux to collect the pieces from those ridiculously small MP2T packets to produce valid H264 packet slices for the RTP muxer since it seems that the muxer isn't doing that. (Where/how does the RTP payloader get the slice information for each frame? Does it scan the buffer looking for MB ends and generate it's own slices? If so, does the MTU default to 1400 bytes?) Would any protocol gurus please shed some light on what is happening and some insight into what could be going wrong and/or how to investigate this? Thank you, Chuck Crisler