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

[Peter BOCZ]

Hi,

On 07/25/2011 08:10 PM, Mailing List SVR wrote:
> 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
>

We tried, but the result is the same. In few minutes i'll make a lot of 
more detailed log with wireshark, samplecode and screenshoot maybe it 
helps to find out, what is the problem.

Thanks for the help in advance.
Regards.

>
>>
>> thanks in advance.
>> regards.
>>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel