video mp2t -> rtp

Chuck Crisler ccrisler at mutualink.net
Thu Dec 27 07:12:37 PST 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20121227/f0d529e5/attachment.html>


More information about the gstreamer-devel mailing list