RTP fragmentation issue Re: please help, we've got some strange problem with RTP/RSTP

Mailing List SVR lists at svrinformatica.it
Mon Jul 25 11:10:13 PDT 2011

Il 25/07/2011 14:27, Farkas Levente ha scritto:
> On 07/22/2011 03:43 PM, Farkas Levente wrote:
>> hi,
>> in short our rtsp server not working:-(
>> but neither:
>> - gst-rtsp-server,
>> - vlc's rtsp server,
>> - mplayer's live555.
>> in a bit more detail, the setup:
>> - we've got high resolution 2MP, 3MP, 5MP and high fps 12-25 fps ip
>> cameras which has buildin rtsp server and can stream the video in rtsp.
>> - our network is not perfect. there are a few pc which are behind 2-3-4
>> switch (ie. the shortest path from one server to the client goes through
>> 2-3-4 switch).
>> what is always working:
>> - if we connect from a pc directly to the ip cameras('s rtsp server)
>> then we can get the proper video stream even with gstreamer, vlc etc.
>> what is not always working:
>> - if we create an rtsp server on pc (eg Wim's gst-rtsp-server) which do
>> nothing just re-transmit the rtp stream from the camera with this
>> pipeline on the server side:
>> rtspsrc location=rtsp://admin:12345@ !
>> rtph264depay ! rtph264pay name=pay0 pt=96
>> and on the client side with this:
>> gst-launch rtspsrc location="rtsp://" !
>> decodebin2 ! xvimagesink
>> then on some network segment we've got gray images most of the time.
>> we try to replace both the client and then server to vlc and mplayer
>> (just to know whether it's a gstreamer bug or not) and neither
>> combination working. but if we connect directly to the camera it's
>> always working with all clients.
>> an even strange thing if we start to stream on the server side from an
>> mkv file (with the high resolution high fps file) than the same thing
>> happened on the client side. so the problem is not the source of the
>> rtps server.
>> one small tipp: if we lower the mtu to 300 (!) then it's working, but
>> obviously we can't use this settings in a real environment.
>> so what can be the problem? any help would be useful.
> more info. if we also test with h263pay. is we leave the ffenc_h263p
> encoders bitrate at the default value (300000) than one udp packet size
> is about ~300bytes and in this case the video is perfect. if we rise the
> bitrate to 1800000 then one udp packet size is not enough for one
> gstbuffer. in this case the video is unusable on the receiver side.
> so is there any rtp (de)fragmentation algorithm in gstreamer? how does
> it works? we wireshark the rtp stream from the ip camera and it contains
> fragmented rtp packet. while we wireshark the rtp stream from gst's rtsp
> server the it's just a bunch of udp packets and wireshirk do not
> recognize them as fragmented rtp packets.
> is there any docs about how rtp fragmentation should have to do?
> what is implemented in gstreamer?
> fyi the encoder pipeline:
> rtspsrc location=rtsp://admin:12345@ !
> decodebin2 ! queue2 ! ffenc_h263p bitrate=1800000 ! rtph263ppay
> name=pay0 pt=96

try this pipeline:

rtspsrc location=rtsp://admin:12345@ !

rtph264depay ! rtph264pay name=pay0 pt=96

let me know,


> thanks in advance.
> regards.

More information about the gstreamer-devel mailing list