GStreamer-devel

please help, we've got some strange problem with RTP/RSTP

Classic

List

Threaded

9 messages Options

Farkas Levente

please help, we've got some strange problem with RTP/RSTP

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.

--
Levente "Si vis pacem para bellum!"
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Farkas Levente

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

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!"
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Marc Leeman

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

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

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

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

--
br, marc

The best approach for you requires two steps. The first step is
reading the Manual.
Wolfgang Denk - u-boot mailing list
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Farkas Levente

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

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!"
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Mailing List SVR

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

In reply to this post by Farkas Levente

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Marco Ballesio

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

In reply to this post by Farkas Levente

Hi,

On Fri, Jul 22, 2011 at 6:43 AM, Farkas Levente <[hidden email]> wrote:

Do you mean 100% gray images (same color for all the pixels) or a
grayscale version of the images generated from the camera?

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

How are you proxying the stream? Maybe you can share some code.

Regards

>
> so what can be the problem? any help would be useful.
>
>
> --
> Levente "Si vis pacem para bellum!"
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Peter BOCZ

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

In reply to this post by Mailing List SVR

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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Peter BOCZ

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

In reply to this post by Marco Ballesio

Hi,

here is some detailed information about the problem:

On 07/25/2011 10:22 PM, Marco Ballesio wrote:

> Hi,
>
> On Fri, Jul 22, 2011 at 6:43 AM, Farkas Levente<[hidden email]> 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.
> Do you mean 100% gray images (same color for all the pixels) or a
> grayscale version of the images generated from the camera?
>

Images look like iframes are missing, i attached one.

>> 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.
> How are you proxying the stream? Maybe you can share some code.
>

I attached some wireshark log maybe it is helpful.

client_camera.txt includes the wireshark log when we connect directly to
the camera.
pipeline on the client: gst-launch playbin2
uri=rtsp://admin:12345@192.168.209.209:554/h.264/ch1/main
the picture is clear and good

client_rtsp.txt includes the wireshark log when we connect to our rtsp
server. We are using Wim's gst-rtsp-server. Here are the code from the
rtsp server:

#include <gst/gst.h>
#include <gst/rtsp-server/rtsp-server.h>

int main (int argc, char *argv[])
{
GMainLoop *loop;
GstRTSPServer *server;
GstRTSPMediaMapping *mapping;
GstRTSPMediaFactory *factory;

gst_init (&argc, &argv);

loop = g_main_loop_new (NULL, FALSE);

server = gst_rtsp_server_new ();
mapping = gst_rtsp_server_get_media_mapping (server);
factory = gst_rtsp_media_factory_new ();
gst_rtsp_media_factory_set_launch (factory, "( rtspsrc
location=rtsp://admin:12345@192.168.209.209:554/h.264/ch1/main !
rtph264depay ! rtph264pay name=pay0 pt=96 )");
gst_rtsp_media_factory_set_shared (factory, TRUE);
gst_rtsp_media_mapping_add_factory (mapping, "/test", factory);
g_object_unref (mapping);
gst_rtsp_server_attach (server, NULL);

g_main_loop_run (loop);

return 0;
}

pipeline on the client: gst-launch playbin2
uri=rtsp://admin:12345@192.168.209.209:554/h.264/ch1/main
the picture is gray as you see in rtsp.png

if you need any more information, don't be shy to ask
thanks for your help in advance
best regards

Peter Bocz

> Regards
>
>> so what can be the problem? any help would be useful.
>>
>>
>> --
>> Levente "Si vis pacem para bellum!"
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

client_camera.txt (34K) Download Attachment

client_rtsp.txt (21K) Download Attachment

rtsp.png (396K) Download Attachment

Peter BOCZ

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

Hi,

On 07/26/2011 08:51 AM, Peter BOCZ wrote:

> Hi,
>
> here is some detailed information about the problem:
>
> On 07/25/2011 10:22 PM, Marco Ballesio wrote:
>> Hi,
>>
>> On Fri, Jul 22, 2011 at 6:43 AM, Farkas Levente<[hidden email]>
>> 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.
>> Do you mean 100% gray images (same color for all the pixels) or a
>> grayscale version of the images generated from the camera?
>>
>
> Images look like iframes are missing, i attached one.
>
>>> 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.
>> How are you proxying the stream? Maybe you can share some code.
>>
>
> I attached some wireshark log maybe it is helpful.
>
> client_camera.txt includes the wireshark log when we connect directly
> to the camera.
> pipeline on the client: gst-launch playbin2
> uri=rtsp://admin:12345@192.168.209.209:554/h.264/ch1/main
> the picture is clear and good
>
> client_rtsp.txt includes the wireshark log when we connect to our rtsp
> server. We are using Wim's gst-rtsp-server. Here are the code from
> the rtsp server:
>
> #include <gst/gst.h>
> #include <gst/rtsp-server/rtsp-server.h>
>
> int main (int argc, char *argv[])
> {
> GMainLoop *loop;
> GstRTSPServer *server;
> GstRTSPMediaMapping *mapping;
> GstRTSPMediaFactory *factory;
>
> gst_init (&argc, &argv);
>
> loop = g_main_loop_new (NULL, FALSE);
>
> server = gst_rtsp_server_new ();
> mapping = gst_rtsp_server_get_media_mapping (server);
> factory = gst_rtsp_media_factory_new ();
> gst_rtsp_media_factory_set_launch (factory, "( rtspsrc
> location=rtsp://admin:12345@192.168.209.209:554/h.264/ch1/main !
> rtph264depay ! rtph264pay name=pay0 pt=96 )");
> gst_rtsp_media_factory_set_shared (factory, TRUE);
> gst_rtsp_media_mapping_add_factory (mapping, "/test", factory);
> g_object_unref (mapping);
> gst_rtsp_server_attach (server, NULL);
>
> g_main_loop_run (loop);
>
> return 0;
> }
>
> pipeline on the client: gst-launch playbin2
> uri=rtsp://admin:12345@192.168.209.209:554/h.264/ch1/main

sorry the right pipeline is:
gst-launch playbin2 uri=rtsp://192.168.209.200:8554/test

> the picture is gray as you see in rtsp.png
>
> if you need any more information, don't be shy to ask
> thanks for your help in advance
> best regards
>
> Peter Bocz
>> Regards
>>
>>> so what can be the problem? any help would be useful.
>>>
>>>
>>> --
>>> Levente "Si vis pacem para bellum!"
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

thanks for your help in advance
best regards

Peter Bocz
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel