Best way to indicate loss of live camera signal

[Allan Chandler]

I have an application that creates a pipeline of the form "rtspsrc location=rtsp://user:password@192.0.0.X/chY/Z latency=0 retry=65535 timeout=0 tcp-timeout=0 drop-on-latency=True ! rtph264depay ! h264parse ! imxvpudec ! imxipuvideosink window-x-coord=0 window-y-coord=0 window-width=1024 window-height=768 sync=false". This is done with gst_parse_launch.

So, obviously, this is getting low latency streaming data from an IP camera.

However, I'm looking for a way to detect loss of signal from the camera and ensure it gets indicated somehow to the viewer. I also need to recover reasonably quickly and re-establish the stream if the camera comes back online.

=====

I actually have two issues here. The first has to do with how to easily switch between a live stream and a "signal lost" stream. The thoughts I've had about this come down to a few options:

1/ Have a text overlay on the stream which is usually invisible but, when the signal disappears, this is changed to something like "signal lost", or a big red "X" in the middle of the screen. This may be doable but it means we have to put pango into our embedded system to do text rendering. I'm also not sure of the process of finding and manipulating the textoverlay component when all I gave is the pipeline returned from gst_parse_launch().

2/ On loss of signal, shut down the current stream and simply run an equivalent "videotestsrc pattern=snow ! imxvpuvideosink ...". This is slightly problematic in that I no longer have the camera stream to detect whether it starts playing again. That means I'll have to poll it periodically (maybe to a fakesink) and, if it works, replace the test pattern with the proper stream.

I'd appreciate any guidance from others who have already done this sort of thing, or indeed ANY ideas on how best to approach this.

=====

The second issue has to do specifically with message capture, in that GStreamer doesn't appear to be calling my callbacks.

Keeping in mind this is a Qt application (no Gtk windowing stuff), I first call gst_init() from the main thread then start up a separate thread to do all the GStreamer stuff. Within that thread, I basically do the following:

GstElement *playBin = gst_parse_launch("<gstreamer pipeline>");
GstBus *bus = gst_pipeline_get_bus(GST_PIPELINE(playBin));
gst_bus_add_signal_watch(bus);
g_signal_connect(bus, "message::state-changed", (GCallback)Cb, NULL);
gst_element_set_state(playBin, GST_STATE_PLAYING);

GMainLoop *mainLoop = g_main_loop_new(NULL, FALSE);
g_main_loop_run(mainLoop);

The callback function simply outputs some debug messages at the moment:

static gboolean Cb(GstBus *bus, GstMessage *msg, gpointer data) {
    std::cout << "g_sig, bus = " << (void*)bus
              << ", msg = "      << (void*)msg
              << ", data = "     << (void*)data
              << std::endl;
    return TRUE;
}

Now, despite the fact I *think* I'm following the rules for message capture, nothing is output by the callback function so I'm assuming it's not being called. I've also tried it with the eos, error and element messages with similar results, and by using the more general gst_bus_add_watch() which I believe will fire for all messages.

I'd be grateful for any assistance as to why the callback is apparently being ignored.

Cheers.


Allan Chandler | Software Engineer

DTI Group Ltd | Transit Security & Surveillance

31 Affleck Road, Perth Airport, WA 6105, AU

P | F | allan.chandler at dti.com.au



Visit our website www.dti.com.au<http://www.dti.com.au>

The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161108/fd38eca3/attachment.html>