udpsrc input failover

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

udpsrc input failover

haris
Hi everyone!

Is there any solution about implementing failover for 2 input transport streams?
It is of a small importance if the failover is smooth nor if input streams are syncronised from enduser's stand point. It is important however that when the 1st input is unavailable that the second input is switched to automaticaly, and possibly when the 1st input comes back online to switch back to it automaticaly again.

If this is not available, where would you suggest to implement this in the gstreamer pipeline?


kind regards
Haris
Reply | Threaded
Open this post in threaded view
|

Re: udpsrc input failover

haris
I have read about dynamic pipeline changes... in this article
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html

Would anyone say that could be a good way to handle input failover between 2 udpsrc elements?

Reply | Threaded
Open this post in threaded view
|

Re: udpsrc input failover

Michael Gruner
In reply to this post by haris
Hi Haris,

You might want to take a look at the 'timeout' property of the udpsrc.
Basically, if X microseconds passed and no data was received, a message
will be posted to the bus. You can use that message to switch to your
other udpsrc.

Michael

On 03/31/2014 05:02 AM, haris wrote:

> Hi everyone!
>
> Is there any solution about implementing failover for 2 input transport
> streams?
> It is of a small importance if the failover is smooth nor if input streams
> are syncronised from enduser's stand point. It is important however that
> when the 1st input is unavailable that the second input is switched to
> automaticaly, and possibly when the 1st input comes back online to switch
> back to it automaticaly again.
>
> If this is not available, where would you suggest to implement this in the
> gstreamer pipeline?
>
>
> kind regards
> Haris
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/udpsrc-input-failover-tp4666216.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: udpsrc input failover

Sebastian Dröge-3
In reply to this post by haris
On Do, 2014-05-08 at 10:23 -0700, haris wrote:
> I have read about dynamic pipeline changes... in this article
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html
>
> Would anyone say that could be a good way to handle input failover between 2
> udpsrc elements?

Yes, you need to dynamically change the pipeline whenever you notice
that you need to do failover or alternatively you could have both
sources running all the time and use an input-selector element. But
dynamic pipelines, and the failover source only enabled when necessary,
is going to be more efficient.

For detecting when no data was received for a while you can use the
watchdog element from gst-plugins-bad, or as Michael said the timeout
property on udpsrc.

--
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source

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

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: udpsrc input failover

haris
Thank you for these good pointers.

I certainly agree the best option would be to have only 1 input running (receiving) all the time and activate the other first on failure. If I want to switch back to "primary" udpsrc after a failover to "backup" udpsrc, how would you suggest to (re)check if the "primary" udpsrc is again receiving correctly? The meaning is to avoid trying to switch back until the primary is actually confirmed to have recovered.




On 08/05/14 23:53, Sebastian Dröge-3 [via GStreamer-devel] wrote:
On Do, 2014-05-08 at 10:23 -0700, haris wrote:
> I have read about dynamic pipeline changes... in this article
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html
>
> Would anyone say that could be a good way to handle input failover between 2
> udpsrc elements?

Yes, you need to dynamically change the pipeline whenever you notice
that you need to do failover or alternatively you could have both
sources running all the time and use an input-selector element. But
dynamic pipelines, and the failover source only enabled when necessary,
is going to be more efficient.

For detecting when no data was received for a while you can use the
watchdog element from gst-plugins-bad, or as Michael said the timeout
property on udpsrc.

--
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source

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

signature.asc (985 bytes) Download Attachment



If you reply to this email, your message will be added to the discussion below:
http://gstreamer-devel.966125.n4.nabble.com/udpsrc-input-failover-tp4666216p4666876.html
To unsubscribe from udpsrc input failover, click here.
NAML

--

Haris Zukanovic
Reply | Threaded
Open this post in threaded view
|

Re: udpsrc input failover

Sebastian Dröge-3
On Fr, 2014-05-09 at 15:01 -0700, haris wrote:
> Thank you for these good pointers.
>
> I certainly agree the best option would be to have only 1 input running
> (receiving) all the time and activate the other first on failure. If I
> want to switch back to "primary" udpsrc after a failover to "backup"
> udpsrc, how would you suggest to (re)check if the "primary" udpsrc is
> again receiving correctly? The meaning is to avoid trying to switch back
> until the primary is actually confirmed to have recovered.

You could have the primary udpsrc running in the background and
connected to e.g. a fakesink, or appsink and check with a pad probe (or
the appsink signal) if data is arriving there.

--
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source

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

signature.asc (985 bytes) Download Attachment