trying to analyze RTP

[Olivier Crête]

Hi,

You should instead feed the pcap file to GStreamer directly using
pcapparse, you can tell pcapparse which src/dest ip/port tuple to use.
Then you get the packets properly timestamped and delimited.

Olivier

On Thu, 2013-03-14 at 07:55 +0000, Thomas Greenwood wrote:
> I think your issue may relate to packetizing of the rtp.  In udp each
> packet is delineated by the udp packet, but when put into a file the
> information of where each packet ends isn't available. So I guess the
> file source will just read  chunks that don't match a single whole rtp
> packet.  It's the same issue with sending rtp over tcp - take a look
> at what it says in the spec http://www.ietf.org/rfc/rfc3551.txt
> 
> Btw I haven't looked at your file so I am making some presumptions.
>
> -----Original Message-----
> 
> From: Chuck Crisler
> Sent: 13 Mar 2013 19:06:55 GMT
> To: Discussion of the development of and with GStreamer
> Subject: trying to analyze RTP
> 
> 
> I am trying to establish tools to analyze RTP streams. I have a
> wireshark packet capture that has RTP video that successfully
> displayed. In wireshark I decoded the specific UDP as RTP, then set
> the default H264 RTP payload type properly to analyze the packets has
> H264. I then selected 'follow conversation' to only select that
> particular stream. I verified that the resulting wireshark display
> only contained the entire RTP payload from all of the selected
> packets, the UDP headers had been removed. To do that I simply
> compared the isolated stream display to the standard wireshark display
> for the selected packet and matched where the initial bytes lined up.
> I then saved that isolated stream to a file that I gave the 'rtp'
> extension to. I then used a gstreamer based script to read the file,
> rtp depay, h264 decode and display the stream. But the depay operation
> failed. Here is my pipeline to process the file:
> 
> gst-launch -v filesrc location=$1 !
> 'application/x-rtp,media=video,payload=104,clock-rate=90000,encoding-name=H264' \
>          ! queue ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace !
> xvimagesink
> 
> Here are the initial log messages from the script. I had debugging for
> rtph264depay:5
> 
> /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps =
> application/x-rtp, media=(string)video, payload=(int)104, clock-rat
> e=(int)90000, encoding-name=(string)H264
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps
> = video/x-h264
> /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps
> = application/x-rtp, media=(string)video, payload=(int
> )104, clock-rate=(int)90000, encoding-name=(string)H264
> WARNING: from
> element /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: Could
> not decode stream.
> Additional debug info:
> gstbasertpdepayload.c(368): gst_base_rtp_depayload_chain
> (): /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0:
> Received invalid RTP payload, dropping
> WARNING: from
> element /GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0: Could
> not decode stream.
> 
> I can do this process for MP2T packets. I know that RTP is not a valid
> 'container' for this but I would think that by isolating the RTP
> portion of each packet, writing them to a binary file, reading the
> packets and passing them to the RTP H264 depayloader should address
> those problems.
> 
> In attempting to isolate problems, I also captured video from a
> webcam, H264 encoded it, ran it through the rtph264payloader and wrote
> it to a file. This same script fails the same way with that file.
> 
> Can anyone suggest where I have goofed? BTW - ffplay also fails.
> 
> Thank you,
> Chuck Crisler
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
Olivier Crête
olivier.crete at collabora.com