trying to analyze RTP

Chuck Crisler ccrisler at mutualink.net
Thu Mar 14 11:56:19 PDT 2013


This plugin sounds wonderful but I can't get it to work. I am using
gstreamer bad plugin v. 0.10.20 Here is my script:

#!/bin/sh

export GST_DEBUG=pcapparse:5,filesrc:5

gst-launch filesrc location=$1 ! 'raw/x-pcap' ! queue ! pcapparse src-ip=$2
src-port=$3 dst-ip=$4 dst-port=$5 ! \

'application/x-rtp,media=video,payload=104,clock-rate=90000,encoding-name=H264'
! \
    rtph264depay byte-stream=true ! video/x-h264 ! ffdec_h264 ! xvimagesink
sync=false

I checked with wireshark to get the correct src/dst ip/port and payload
type. Filesrc runs and seems to read the capture file. But pcapparse never
logs anything. Here is the end of the output:

0:00:00.218694929 10625  0x91b3d90 LOG                  filesrc
gstfilesrc.c:842:gst_file_src_create_read:<filesrc0> Reading 4096 bytes at
offset 0x12f000
0:00:00.218949155 10625  0x91b3d90 LOG                  filesrc
gstfilesrc.c:842:gst_file_src_create_read:<filesrc0> Reading 616 bytes at
offset 0x130000
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 372957 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

Thank you for any further guidance. This should be a wonderfully helpful
plugin.

Chuck

On Thu, Mar 14, 2013 at 11:23 AM, Chuck Crisler <ccrisler at mutualink.net>wrote:

> WOW! Thank you! :-)
>
>
> On Thu, Mar 14, 2013 at 10:59 AM, Olivier Crête <
> olivier.crete at collabora.com> wrote:
>
>> 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
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130314/ee49c26f/attachment.html>


More information about the gstreamer-devel mailing list