[gst-devel] sending raw stream over rtp

Kocsis Tibor ikt011 at gmail.com
Thu Jan 6 09:13:05 CET 2011


The RTSP server is written by me and my team. I'm using gstreamer
elements for creating rtp packets: gstrtpbin and some udpsrc/udpsink
elements, based on the gstreamer doc's example pipelines:
http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-gstrtpbin.html

The rtsp messages are handled through tcp connection, you need to
implement the communication messages in the RTSP spec, for example if
the client sends you the DESCRIBE message, you have to return the
specifications of your stream in the sdp format.

So if you want to handle the rtsp messages, you need to write an
application. Gstreamer already has an rtsp server (gst-rtsp-server),
and it is great for start, but you probably need your own in short
time.

Regards,
Tibor

On Wed, Jan 5, 2011 at 8:50 PM, Suneet Shah <suneets at gmail.com> wrote:
> Hi Kocis-- what RTSP server are you using?
> I'm trying to do the opposite of what you're doing. I have a gstreamer
> pipeline creating RTP packets, but need to package them with RTSP and create
> an SDP file.
> Thanks,
> Suneet
>
> On Wed, Jan 5, 2011 at 5:48 AM, Wim Taymans <wim.taymans at gmail.com> wrote:
>>
>> On Wed, 2011-01-05 at 14:38 +0100, Kocsis Tibor wrote:
>> > I created a command line to test the problem, the result is the same,
>> > I got a lot of messages like this:
>> >
>> > 0:00:27.686127192 14222       0xf1bd50 WARN            rtpvrawdepay
>> > gstrtpvrawdepay.c:378:gst_rtp_vraw_depay_process:<rtpvrawdepay0>
>> > clipping length 726, offset 398
>> > 0:00:27.686175449 14222       0xf1bd50 WARN            rtpvrawdepay
>> > gstrtpvrawdepay.c:378:gst_rtp_vraw_depay_process:<rtpvrawdepay0>
>> > clipping length 438, offset 494
>>
>> Those are normal. I will change them to LOG.
>>
>> Wim
>> > The pipelines:
>> >
>> > Sender:
>> >
>> > gst-launch -v  v4l2src !
>> > video/x-raw-yuv,width=640,height=480,framerate=10/1 ! clockoverlay !
>> > rtpvrawpay ! udpsink host=... port=5000 sync=false
>> >
>> > Receiver:
>> >
>> > gst-launch -v udpsrc port=5000 caps="application/x-rtp,
>> > media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW,
>> > sampling=(string)YCbCr-4:2:0, depth=(string)8, width=(string)640,
>> > height=(string)480, colorimetry=(string)SMPTE240M, payload=(int)96,
>> > ssrc=(uint)2464304599, clock-base=(uint)342261484,
>> > seqnum-base=(uint)47511" ! rtpvrawdepay ! xvimagesink sync=false
>> >
>> > Caps copied from udsink.sink on the sender side.
>> >
>> > So is this warning message normal and should be info or maybe a
>> > rawdepay bug or something else?
>> >
>> > Regards,
>> > Tibor
>> >
>> >
>> >
>> > On Wed, Jan 5, 2011 at 10:13 AM, Kocsis Tibor <ikt011 at gmail.com> wrote:
>> > > The sdp I linked was wrong, my version is here:
>> > >
>> > >  medias:
>> > >  media 0:
>> > >   media:       'video'
>> > >   port:        '0'
>> > >   num_ports:   '4294967295'
>> > >   proto:       'RTP/AVP'
>> > >   formats:
>> > >    format  '96'
>> > >   information: '(NULL)'
>> > >   key:
>> > >    type:       '(NULL)'
>> > >    data:       '(NULL)'
>> > >   attributes:
>> > >    attribute 'rtpmap' : '96 RAW/90000'
>> > >    attribute 'control' :
>> > >
>> > > 'rtsp://10.30.0.8:1554/Live/trackID=0?channelID=98d16963-877f-4446-bb69-3aeada917523'
>> > >    attribute 'fmtp' : '96
>> > > width=640;height=480;sampling=YCbCr-4:2:0;depth=8'
>> > >    attribute 'appversion' : '5.0.0'
>> > >
>> > >
>> > > On Wed, Jan 5, 2011 at 9:07 AM, Kocsis Tibor <ikt011 at gmail.com> wrote:
>> > >> Hi,
>> > >>
>> > >> I have a basic rtsp server, and I try to use to send a raw stream to
>> > >> the client. On the receiver side I use a simple gstreamer pipeline
>> > >> like this: rtspsrc ! rtpvrawdepay ! xvimagesink. On the server there
>> > >> are gstreamer elements, too, some source connected to a rtpvrawpay,
>> > >> and to the gstrtpsink elements. The sending is started, and I can
>> > >> watch something live view, but it is not fluency. These messages
>> > >> appear on the client:
>> > >>
>> > >> 0:00:03.233100336 24189 0x7f654000bd20 WARN            rtpvrawdepay
>> > >> gstrtpvrawdepay.c:378:gst_rtp_vraw_depay_process:<rtpvrawdepay0>
>> > >> clipping length 540, offset 460
>> > >> 0:00:03.233134052 24189 0x7f654000bd20 WARN            rtpvrawdepay
>> > >> gstrtpvrawdepay.c:378:gst_rtp_vraw_depay_process:<rtpvrawdepay0>
>> > >> clipping length 1086, offset 278
>> > >> 0:00:03.233192201 24189 0x7f654000bd20 WARN            rtpvrawdepay
>> > >> gstrtpvrawdepay.c:378:gst_rtp_vraw_depay_process:<rtpvrawdepay0>
>> > >> clipping length 252, offset 556
>> > >> 0:00:03.233232346 24189 0x7f654000bd20 WARN            rtpvrawdepay
>> > >> gstrtpvrawdepay.c:378:gst_rtp_vraw_depay_process:<rtpvrawdepay0>
>> > >> clipping length 798, offset 374
>> > >> ...
>> > >>
>> > >> What can it cause?
>> > >>
>> > >> My guess was I missed from the sdp (or built it up wrong), but the
>> > >> params I send over in the fmtp is the same as on the payloader's
>> > >> source pad (width, height, sample, even as depth, but as I see depth
>> > >> is not parsed on the client side). Btw my rtsp server works with
>> > >> h264/mpeg4 fine, so the elements are correctly linked.
>> > >>
>> > >> The full rtsp communication is here: http://pastebin.com/fC8MsJkx
>> > >>
>> > >> Any idea is welcomed
>> > >>
>> > >> Regards
>> > >> Tibor
>> > >>
>> > >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Learn how Oracle Real Application Clusters (RAC) One Node allows
>> > customers
>> > to consolidate database storage, standardize their database environment,
>> > and,
>> > should the need arise, upgrade to a full multi-node Oracle RAC database
>> > without downtime or disruption
>> > http://p.sf.net/sfu/oracle-sfdevnl
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
>> to consolidate database storage, standardize their database environment,
>> and,
>> should the need arise, upgrade to a full multi-node Oracle RAC database
>> without downtime or disruption
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>




More information about the gstreamer-devel mailing list