is it allowed to change updsink host property dynamically without stopping pipeline?

[alcosar]

Hello,
I have a pipeline:
constexpr char kSenderPipeline[] =
    "alsasrc  ! "
    "deinterleave name=d d.src_1 ! "
    "audio/x-raw,format=S16LE,channels=1 ! "
    "audioresample ! "
    "opusenc bandwidth=narrowband ! "
    "rtpopuspay ! "
    "udpsink name=ptt_udpsink";
Depending on network availability I want to be able to change IP addrress on udpsink element. Right now I'm doing it like this:
// Updates an IP address on udpsink element. The audio stream will be sent to
// different IP address.
void UpdateUdpsinkHostAddress(const gpointer udpsink,
                              const ::std::string &host) {
  g_object_set(udpsink, "host", host.c_str(), "port", kPort, nullptr);
}
This function could be called from different threads, and I'm using mutex to ensure that only one thread can call it at a time.

But I don't know what happens with a thread that runs udpsink. Is it safe to do so without stopping pipeline?

[Baby Octopus]

Which threads are you referring to? Are they streaming threads(threads created by gstreamer)? If it is your own threads(application threads) or g_main_loop(attached to the bus), it should be perfectly safe to change the property of udpsink dynamically AFAIU

~BO

[alcosar]

I'm sorry for not being explicit. I have 2 application threads. One is responsible for DNS name resolution, it resolves name to IP address and changes IP address with g_object_set(). The other, my main thread, decides whether to switch to local network or to use LTE. It will set IP address for local network with g_object_set(). The third thread is gstreamer's which streams audio.
When IP address changes how does it impact gstreamer udpsink thread?
My question is it legitimate to change IP address with g_object_set() while udpsink is in PLAYING state?

[Baby Octopus]

Why not just give it a try and see if it works :)

[alcosar]

Yes, I tried it.It seems to be working.
Though it is not a prove that it is legitimate, and it has not concurrency issues.

[Mailing List SVR]

Il 02/08/2017 17:56, alcosar ha scritto:

Yes, I tried it.It seems to be working.
Though it is not a prove that it is legitimate, and it has not concurrency
issues.

I think it is thread safe, please take a look here:

https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/udp/gstudpsink.c#n167

the actual client is removed using gst_multiudpsink_remove and the new client is added using gst_multiudpsink_add,

both this methods are thread safe (note lock = TRUE passed to gst_multiudpsink_add_internal)


https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/udp/gstmultiudpsink.c#n1669
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/udp/gstmultiudpsink.c#n1675

for audio only stream you need no additional steps, if you add video you need to ensure that the new host receive a keyframe as first packet (it will be unable to display video until the first keyframe anyway)

Nicola



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/is-it-allowed-to-change-updsink-host-property-dynamically-without-stopping-pipeline-tp4684038p4684069.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[alcosar]

Thank you!