We have multiple cameras and we use this thread to open and close related streams, sometimes when I close one stream and open another, the execution get stuck.
I realized that putting a sleep just before gst_element_set_state is called, makes vimbasrc run properly.
void MyThread()
{
GstElement *pipeline;
GstBus *bus;
GstMessage *msg;
gst_init(NULL, NULL);
std::string lBff;
lBff = "vimbasrc camera=";
lBff += cameraCodes[camera_id];
lBff += " settingsfile=/home/root/1500_384x242.xml ! video/x-raw,format=RGB ! videoconvert ! videoscale ! ";
lBff += "video/x-raw, format=I420, width=640, height=480 ! queue ! zmqsink endpoint=tcp://127.0.0.1:";
lBff += std::to_string(50000 + camera_id + 1);
pipeline = gst_parse_launch(lBff.c_str(), nullptr);
// Uncommenting the following line it works
//this_thread::sleep_for (chrono::milliseconds(875));
gst_element_set_state(pipeline, GST_STATE_PLAYING);
bus = gst_element_get_bus(pipeline);
msg = gst_bus_timed_pop_filtered(bus, 25, GST_MESSAGE_ERROR);
if (msg == nullptr)
// error handling
while (Camera_Occurrence_Counter[camera_id])
{
}
if (msg != nullptr)
gst_message_unref(msg);
gst_object_unref(bus);
gst_element_set_state(pipeline, GST_STATE_NULL);
gst_object_unref(pipeline);
}
Below is the output of debug prints from Gstream configured at level 5:
DEBUG basesrc gstbasesrc.c:3143:gst_base_src_set_allocation:<vimbasrc0> activate pool
DEBUG basesrc gstbasesrc.c:513:gst_base_src_wait_playing_unlocked:<vimbasrc0> live source waiting for running state
We have multiple cameras and we use this thread to open and close related streams, sometimes when I close one stream and open another, the execution get stuck.
I realized that putting a sleep just before gst_element_set_state is called, makes vimbasrc run properly.
Below is the output of debug prints from Gstream configured at level 5: