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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
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 <[hidden email]> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
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 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
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 <[hidden email]> 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 <[hidden email]> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
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 <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >> > [hidden email] >> > 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |