[gst-devel] sending raw stream over rtp

[Wim Taymans]

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