RTSP Unicast and Multicast on the same pipeline using different mountpoints

[Mert Can Ergun]

The scenario I am trying to achieve is like this. Server has 2 mountpoints like:

rtsp://IP:port/unicast
rtsp://IP:port/multicast
while one of them servers only unicast, and the other serves only multicast. The source element is a bit problematic one and I have to use a single pipeline in order to minimize the amount of problems I might face when 2 of the streams are requested simultaneously.

I tried to build 2 similar mediafactories and attached different mountpoints to each other. Then after the first client connects, I saved the RTSPMedia and media pipeline using media-constructed signal and tried to force it to the other one but the framework doesn't allow me to do so.

[Sebastian Dröge-3]

On Sat, 2016-10-29 at 00:22 -0700, Mert Can Ergun wrote:

> The scenario I am trying to achieve is like this. Server has 2 mountpoints
> like:
>
> rtsp://IP:port/unicast
> rtsp://IP:port/multicast
> while one of them servers only unicast, and the other serves only multicast.
> The source element is a bit problematic one and I have to use a single
> pipeline in order to minimize the amount of problems I might face when 2 of
> the streams are requested simultaneously.
>
> I tried to build 2 similar mediafactories and attached different mountpoints
> to each other. Then after the first client connects, I saved the RTSPMedia
> and media pipeline using media-constructed signal and tried to force it to
> the other one but the framework doesn't allow me to do so.

The easiest here might be to either use a single mount point and let
the clients decide whether they want multicast or not, or to run your
source in a separate pipeline and only feed two appsrc inside the RTSP
media from that separate pipeline.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mert Can Ergun]

Is it possible to manually set up 2 GstRTSPMedia objects with the same pipeline and have them listen different paths on the server?
I am trying to explore that possibility but the following code is not working for me:

payloader = gst_element_factory_make("rtph264pay", "pay0");

rtsp_server = gst_rtsp_server_new();
gst_rtsp_server_set_service(rtsp_server, "8554");

if(!pipeline || !src || !converter || !encoder || !payloader)
g_print("creation failed!\n");

gst_bin_add_many(pipeline, src, converter, encoder, payloader, NULL);
rtsp_media = gst_rtsp_media_new(pipeline);
payloader_sink = gst_element_get_static_pad(payloader, "sink");
uni_stream = gst_rtsp_media_create_stream(rtsp_media, payloader, payloader_sink);

guint n_cnt = gst_rtsp_media_n_streams(rtsp_media);

g_print("number of streams = %d\n", n_cnt);

GstRTSPMediaStatus status = gst_rtsp_media_get_status(rtsp_media);
g_print("GstRTSPMediaStatus = %d\n", status);

if(!gst_rtsp_media_prepare(rtsp_media, NULL))


I get errors at _prepare():

(mt-gst-auth-rtsp-server:7889): GStreamer-CRITICAL **: gst_element_get_bus: assertion 'GST_IS_ELEMENT (element)' failed

(mt-gst-auth-rtsp-server:7889): GStreamer-CRITICAL **: gst_bus_create_watch: assertion 'GST_IS_BUS (bus)' failed

(mt-gst-auth-rtsp-server:7889): GStreamer-CRITICAL **: gst_object_unref: assertion 'object != NULL' failed

(mt-gst-auth-rtsp-server:7889): GLib-CRITICAL **: g_source_set_callback: assertion 'source != NULL' failed.

I tried to make sure that pipeline is properly initialized on the RTSPMedia object by getting the pipeline from it and then using gst_element_get_bus and it doesn't return any errors.

[Mert Can Ergun]

Quick Update: My payloader is actually named as pay0. I forgot about that detail, but changing it doesn't fix the problem

Mert Can Ergun wrote

Is it possible to manually set up 2 GstRTSPMedia objects with the same pipeline and have them listen different paths on the server?
I am trying to explore that possibility but the following code is not working for me:

payloader = gst_element_factory_make("rtph264pay", "pay0");

rtsp_server = gst_rtsp_server_new();
gst_rtsp_server_set_service(rtsp_server, "8554");

if(!pipeline || !src || !converter || !encoder || !payloader)
g_print("creation failed!\n");

gst_bin_add_many(pipeline, src, converter, encoder, payloader, NULL);
rtsp_media = gst_rtsp_media_new(pipeline);
payloader_sink = gst_element_get_static_pad(payloader, "sink");
uni_stream = gst_rtsp_media_create_stream(rtsp_media, payloader, payloader_sink);

guint n_cnt = gst_rtsp_media_n_streams(rtsp_media);

g_print("number of streams = %d\n", n_cnt);

GstRTSPMediaStatus status = gst_rtsp_media_get_status(rtsp_media);
g_print("GstRTSPMediaStatus = %d\n", status);

if(!gst_rtsp_media_prepare(rtsp_media, NULL))


I get errors at _prepare():

(mt-gst-auth-rtsp-server:7889): GStreamer-CRITICAL **: gst_element_get_bus: assertion 'GST_IS_ELEMENT (element)' failed

(mt-gst-auth-rtsp-server:7889): GStreamer-CRITICAL **: gst_bus_create_watch: assertion 'GST_IS_BUS (bus)' failed

(mt-gst-auth-rtsp-server:7889): GStreamer-CRITICAL **: gst_object_unref: assertion 'object != NULL' failed

(mt-gst-auth-rtsp-server:7889): GLib-CRITICAL **: g_source_set_callback: assertion 'source != NULL' failed.

I tried to make sure that pipeline is properly initialized on the RTSPMedia object by getting the pipeline from it and then using gst_element_get_bus and it doesn't return any errors.

[Sebastian Dröge-3]

On Tue, 2016-11-01 at 08:51 -0700, Mert Can Ergun wrote:
> Is it possible to manually set up 2 GstRTSPMedia objects with the
> same pipeline and have them listen different paths on the server?
> [...]

No, because each media instance has its own pipeline. If you need them
to share something, you would have to handle a separate pipeline with
the shared part and feed the 2 media pipelines from there, e.g. with an
appsrc.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mert Can Ergun]

Hi Sebastian
I've decided to use the first route you suggested "The easiest here might be to either use a single mount point and let
the clients decide whether they want multicast or not,"
After checking test-multicast2.c example, it seems to allow all transfer methods and enables multicast addresses when media is constructed. This is close to what I need but it seems to start multicasting no matter which protocol the user uses.

I am using "GST_DEBUG=2 gst-launch-1.0 rtspsrc location=rtsp://10.0.0.10:8554/test protocols=PROTOCOL_NAME ! fakesink" to start using a specific method.

Since the server starts multicast no matter what, I am not really sure if the client(a client with unicast needs) is able to gather it from unicast or not.

Is there a point I'm missing?

[Sebastian Dröge-3]

On Thu, 2016-11-03 at 06:00 -0700, Mert Can Ergun wrote:

> Hi Sebastian
> I've decided to use the first route you suggested "The easiest here
> might be
> to either use a single mount point and let 
> the clients decide whether they want multicast or not,"
> After checking test-multicast2.c example, it seems to allow all
> transfer
> methods and enables multicast addresses when media is constructed.
> This is
> close to what I need but it seems to start multicasting no matter
> which
> protocol the user uses.
>
> I am using "GST_DEBUG=2 gst-launch-1.0 rtspsrc
> location=rtsp://10.0.0.10:8554/test protocols=PROTOCOL_NAME !
> fakesink" to
> start using a specific method.
>
> Since the server starts multicast no matter what, I am not really
> sure if
> the client(a client with unicast needs) is able to gather it from
> unicast or
> not.
>
> Is there a point I'm missing?

With rtspsrc you can specify that via the protocols property.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mert Can Ergun]

The problem is that even though I specify TCP or UDP as protocols property from the client, I can see packets floating on wireshark sent from my server's IP.

Is this the default behavior or am I doing something wrong? (even though I am just using example code right now)

[Sebastian Dröge-3]

On Mon, 2016-11-07 at 02:13 -0800, Mert Can Ergun wrote:
> The problem is that even though I specify TCP or UDP as protocols
> property from the client, I can see packets floating on wireshark
> sent from my server's IP.

What packets? There will always be the TCP RTSP connection between the
server and the client.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mert Can Ergun]

I am sorry I was talking about multicast packages sent to the standart multicast IP set by the example code(224.3.0.1).

Here's what happens:  
-I start the app on host computer.(C1)
-I use one of the following pipelines on another computer.(C2)
"GST_DEBUG=2 gst-launch-1.0 rtspsrc location=rtsp://10.0.0.10:8554/test protocols=GST_RTSP_LOWER_TRANS_TCP ! fakesink"
"GST_DEBUG=2 gst-launch-1.0 rtspsrc location=rtsp://10.0.0.10:8554/test protocols=GST_RTSP_LOWER_TRANS_UDP ! fakesink"
-Client is able to capture the stream.(C2)
-On another computer I start wireshark and watch the network.(C3)
-I can see packets sent to 224.3.0.1 from C1 on the network.

Sebastian Dröge-3 wrote

On Mon, 2016-11-07 at 02:13 -0800, Mert Can Ergun wrote:
> The problem is that even though I specify TCP or UDP as protocols
> property from the client, I can see packets floating on wireshark
> sent from my server's IP.

What packets? There will always be the TCP RTSP connection between the
server and the client.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


signature.asc (949 bytes) <http://gstreamer-devel.966125.n4.nabble.com/attachment/4680512/0/signature.asc>

[Sebastian Dröge-3]

On Mon, 2016-11-07 at 04:55 -0800, Mert Can Ergun wrote:

> I am sorry I was talking about multicast packages sent to the
> standart multicast IP set by the example code(224.3.0.1).
>
> Here's what happens:  
> -I start the app on host computer.(C1)
> -I use one of the following pipelines on another computer.(C2)
> "GST_DEBUG=2 gst-launch-1.0 rtspsrc
> location=rtsp://10.0.0.10:8554/test
> protocols=GST_RTSP_LOWER_TRANS_TCP ! fakesink"
> "GST_DEBUG=2 gst-launch-1.0 rtspsrc
> location=rtsp://10.0.0.10:8554/test
> protocols=GST_RTSP_LOWER_TRANS_UDP ! fakesink"
> -Client is able to capture the stream.(C2)
> -On another computer I start wireshark and watch the network.(C3)
> -I can see packets sent to 224.3.0.1 from C1 on the network.

Can you get a debug log from the C2? C2 should fail to play anything
here if it is really only capturing from the multicast address. Or are
there packets going to multicast and directly to C2's IP?

Also make sure to use gst-rtsp-server 1.10, there were bugs in the
multicast code before.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mert Can Ergun]

I did the tests on 1.9.90 and yes there were direct packets as well as multicast messages coming from the server.
Yesterday I ran the same test with 1.6.0 on my SBC and it produced expected results. When clients don't request multicast, it doesn't broadcast multicast packets.

I will try the test on 1.10 when I can

Sebastian Dröge-3 wrote

On Mon, 2016-11-07 at 04:55 -0800, Mert Can Ergun wrote:
> I am sorry I was talking about multicast packages sent to the
> standart multicast IP set by the example code(224.3.0.1).
>
> Here's what happens:  
> -I start the app on host computer.(C1)
> -I use one of the following pipelines on another computer.(C2)
> "GST_DEBUG=2 gst-launch-1.0 rtspsrc
> location=rtsp://10.0.0.10:8554/test
> protocols=GST_RTSP_LOWER_TRANS_TCP ! fakesink"
> "GST_DEBUG=2 gst-launch-1.0 rtspsrc
> location=rtsp://10.0.0.10:8554/test
> protocols=GST_RTSP_LOWER_TRANS_UDP ! fakesink"
> -Client is able to capture the stream.(C2)
> -On another computer I start wireshark and watch the network.(C3)
> -I can see packets sent to 224.3.0.1 from C1 on the network.

Can you get a debug log from the C2? C2 should fail to play anything
here if it is really only capturing from the multicast address. Or are
there packets going to multicast and directly to C2's IP?

Also make sure to use gst-rtsp-server 1.10, there were bugs in the
multicast code before.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


signature.asc (949 bytes) <http://gstreamer-devel.966125.n4.nabble.com/attachment/4680551/0/signature.asc>

[Sebastian Dröge-3]

On Tue, 2016-11-08 at 06:04 -0800, Mert Can Ergun wrote:
> I did the tests on 1.9.90 and yes there were direct packets as well as
> multicast messages coming from the server.
> Yesterday I ran the same test with 1.6.0 on my SBC and it produced expected
> results. When clients don't request multicast, it doesn't broadcast
> multicast packets.
>
> I will try the test on 1.10 when I can

There were no relevant changes between 1.9.90 and 1.10.0, only during
1.9.x before.

So you're saying that the server *always* sends multicast packets and
additionally it sends unicast if the client requested that? And it
sends multicast even if no client requested that? That would be a bug.

Can you provide a short testcase for that, especially the server-part?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mert Can Ergun]

I ran the same test with 1.10 today and the results haven't changed.

server side:
GST_DEBUG=2 ./test-multicast2
stream ready at rtsp://127.0.0.1:8554/test
0:00:10.605464791 24520      0x15ffcf0 WARN               rtspmedia rtsp-media.c:3606:gst_rtsp_media_suspend: media 0x7f1f2403e180 was not prepared

client side:
GST_DEBUG=2 gst-launch-1.0 rtspsrc
location=rtsp://10.0.0.10:8554/test protocols=GST_RTSP_LOWER_TRANS_UDP ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://10.0.0.10:8554/test
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (request) SETUP stream 1
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
0:00:00.346565985 27470 0x7fa89803e9e0 WARN                 basesrc
gstbasesrc.c:2943:gst_base_src_loop:<udpsrc3> error: Internal data flow
error.
0:00:00.346604018 27470 0x7fa89803e9e0 WARN                 basesrc
gstbasesrc.c:2943:gst_base_src_loop:<udpsrc3> error: streaming task
paused, reason not-linked (-1)

Screenshot_from_2016-11-11_10_12_03.png

I also uploaded a screenshot from wireshark. I don't have any decoders installed on the second computer so I had to use fakesink and it gave me not-linked warning. If I use a computer with correct decoder and parsers I can get a video stream out of the packets.

By the way, 10.0.0.10 is my server and 10.0.0.50 is the client.

Sebastian Dröge-3 wrote

On Tue, 2016-11-08 at 06:04 -0800, Mert Can Ergun wrote:
> I did the tests on 1.9.90 and yes there were direct packets as well as
> multicast messages coming from the server.
> Yesterday I ran the same test with 1.6.0 on my SBC and it produced expected
> results. When clients don't request multicast, it doesn't broadcast
> multicast packets.
>
> I will try the test on 1.10 when I can

There were no relevant changes between 1.9.90 and 1.10.0, only during
1.9.x before.

So you're saying that the server *always* sends multicast packets and
additionally it sends unicast if the client requested that? And it
sends multicast even if no client requested that? That would be a bug.

Can you provide a short testcase for that, especially the server-part?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


signature.asc (949 bytes) <http://gstreamer-devel.966125.n4.nabble.com/attachment/4680567/0/signature.asc>

[Sebastian Dröge-3]

On Thu, 2016-11-10 at 23:09 -0800, Mert Can Ergun wrote:

>
> Screenshot_from_2016-11-11_10_12_03.png
> <http://gstreamer-devel.966125.n4.nabble.com/file/n4680610/Screenshot
> _from_2016-11-11_10_12_03.png>  
>
> I also uploaded a screenshot from wireshark. I don't have any decoders
> installed on the second computer so I had to use fakesink and it gave me
> not-linked warning. If I use a computer with correct decoder and parsers I
> can get a video stream out of the packets.
>
> By the way, 10.0.0.10 is my server and 10.0.0.50 is the client.

Ok so there's clearly a bug here. It sends multicast in addition to
unicast although no client requested multicast (yet).

Can you file a bug please?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel