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

[Farkas Levente]

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@192.168.209.209:554/h.264/ch1/main !
> rtph264depay ! rtph264pay name=pay0 pt=96
> 
> and on the client side with this:
> gst-launch rtspsrc location="rtsp://192.168.209.200:8554/test" !
> 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@192.168.209.209:554/h.264/ch1/main !
decodebin2 ! queue2 ! ffenc_h263p bitrate=1800000 ! rtph263ppay
name=pay0 pt=96

thanks in advance.
regards.

-- 
  Levente                               "Si vis pacem para bellum!"