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

[Mailing List SVR]

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@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

try this pipeline:

rtspsrc location=rtsp://admin:12345@192.168.209.209:554/h.264/ch1/main !

rtph264depay ! rtph264pay name=pay0 pt=96

let me know,

Nicola


>
> thanks in advance.
> regards.
>