<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Exchange Server"> <style></style> </head> <body> <div class="PlainText">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 <a href="http://www.ietf.org/rfc/rfc3551.txt">http://www.ietf.org/rfc/rfc3551.txt</a> Btw I haven't looked at your file so I am making some presumptions. I hope this helps. -----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 </div> <div>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 </div> </body> </html>