trying to analyze RTP
Thomas Greenwood
tcdgreenwood at hotmail.com
Thu Mar 14 00:55:05 PDT 2013
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.
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130314/60322bf8/attachment-0001.html>
-------------- next part --------------
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list