1. video mp2t -> rtp (Chuck Crisler)

Thu Dec 27 12:52:37 PST 2012

Today's Topics:

----------------------------------------------------------------------

>Message: 1
>Date: Thu, 27 Dec 2012 10:12:37 -0500
>From: Chuck Crisler <ccrisler at mutualink.net>
>To: Discussion of the development of and with GStreamer
> <gstreamer-devel at lists.freedesktop.org>
Subject: video mp2t -> rtp
Message-ID:
    <CALXOHKpomrjnTpXS6zH8aVyzc1HdAkdWFN61AtJh+iyBsScEFQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

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-0001.html>

------------------------------

Hello,

Run the following...

gst-launch udpsrc port=$1 ! filesink location=myfile.ts

...you should see the file fill up with MPEGTS packets...

...also, with the pipeline in your e-mail, do this...

GST_DEBUG=mpegtsdemux:5 GST_DEBUG_NO_COLOR=1 gst-launch udpsrc port=$1 ! 
mpegtsdemux ! video/x-h264 ! \
  rtph264pay pt=96 ! udpsink host=$2 port=$3 >mytrace.txt 1>mytrace.txt 
2>mytrace.txt

...mytrace.txt should become populated with debug prints from the mpegtsdemux 
plugin...

Best Regards,

Rob Krakora

_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

End of gstreamer-devel Digest, Vol 23, Issue 88
***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20121227/eb040a99/attachment.html>