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

[Farkas Levente]

On 07/25/2011 02:39 PM, Marc Leeman wrote:
>>> 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
> 
> You need to re-insert the configuration data in the stream. See the
> config-interval parameter in the rtph264pay element. Some encoders
> pass sps/pps out of band (not in the rtp stream) and only in the RTSP
> negociation. If you want to send the data back out; re-insert the
> config data in the stream.
> 
> Note that if you start the decoder before the encoder; you might have
> missed this effect because (IIRC), the payloader will send sps/pps
> once at startup.

this is not working.
anyway we test with stream from a h264/mkv file with wim's rtsp-server
but the result was the same if the video is high resolution, high fps
then the client always got gray video. and in this case it's not a resend.


>> 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?
> 
> RTP packets the data under the MTU. It is reassembed on the receiving
> side. Can you verify that you do not have any packet loss, that would
> also explain the 'gray' images.

we measure with iperf and there is no pocket loss on the lan:-(

>>
>> 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
> 
> IIRC, only mpeg4videopay and rtph264pay (mpeg4 and h264) use the
> config data. However, H263 has different payload schemes (1998/2000)
> and two different payloaders (h263pay and h263ppay); make certain
> those are matches for your tests.

we need h264, and test with it, but after we've no more idea we also
test with h263, but none of them working:-(

it seems gstreamer do not implement rtp fragmentation which cause all of
these problems. but the other problem we do not find any kind of docs on
the net about how rtp fragmentation should have to right...

-- 
  Levente                               "Si vis pacem para bellum!"