I am running into exactly the same issue as you, but I am running Raspbian Jessie... Were you able to solve the issue?

Trying to add vflip/hflip or rotation of any kind breaks the pipeline, saying Camera took too long...

Ok I was able to solve the problem by following: #77 (comment)

There is another issue on here for a similar problem, and increasing timeout to 1500 worked for me. Good luck!

I'm facing the same issue with normal pipeline:

gst-launch-1.0 -v rpicamsrc ! video/x-h264,width=640,height=480,framerate=8/1,profile=high ! h264parse ! splitmuxsink location=/home/pi/snapshots_tmp/test.mp4 max-size-time=30000000000 max-size-bytes=2000000

this is on Pi0
@thaytan
changing the timeout to 1500 solved the issue. i believe this should be the default number not 500

Hi!
I have the same issue but I don't know how to change the timeout to 1500. Could you explain please? Thanks!

You need to edit this line:
https://github.com/thaytan/gst-rpicamsrc/blob/master/src/RaspiCapture.c#L941
and change the timeout from 500ms to 1500ms

This camera timeout needs a more comprehensive fix when I get time. I'm not sure if it's possible to make a solution that auto-adjusts the timeout, but I could make it a property with a sufficiently large default, and let people that need it smaller make it smaller.

Any update on this?

I am facing the same issue with opencv, this is my pipeline

rpicamsrc preview=false ! video/x-raw,format=BGR,width=640,height=480 ! queue name=sink leaky=2 ! appsink max-buffers=5 drop=true sync=false

[ WARN:0] global /home/pi/opencv/modules/videoio/src/cap_gstreamer.cpp (1757) handleMessage OpenCV | GStreamer warning: Embedded video playback halted; module rpicamsrc0 reported: Camera capture timed out.
[ WARN:0] global /home/pi/opencv/modules/videoio/src/cap_gstreamer.cpp (886) open OpenCV | GStreamer warning: unable to start pipeline
[ WARN:0] global /home/pi/opencv/modules/videoio/src/cap_gstreamer.cpp (480) isPipelinePlaying OpenCV | GStreamer warning: GStreamer: pipeline have not been created

Rasing the timeout to 1500 fixed the issue

I would like to make it a property, with a higher default

I correct myself, 1500 ms of timeout just delays the issue.
With raspberry 3b+ happens more often (every 5 minutes) with the standard 500 while with the increased value happens more sporadically.
While with the raspberry 4 it does not happen even with the standard value of 500.

I will try implementing what you have suggested here #77 (comment)

If I see that it works I could issue a pull request with the fix

what are your lighting conditions like? 1.5seconds before a frame arrives is a very long time!

They are pretty good, although the application runs 24/7 outdoors so it is possible to have a pitch dark environment.
It does not block only when there is no light, also when there is.

It might be because of resource consumption, the rest of the application is cpu heavy

That's pretty interesting - I do wonder what's going on when the timeout happens. 1.5 seconds is a really long time to get stuck and not get even a single packet out!

It is more than two weeks that it is working flawlessly, I added the change and I am proposing a PR, should I do that in the new version of gstreamer as well?

Simply removing the timeout isn't a fix - it's what was there before the timeout was added in the first place.

Why it was added? Are there some other tests that I can do?

I think the original request was for a CSI HDMI-input adapter board and they wanted to detect an error if the HDMI signal went away. The other use case the timeout captures is if the firmware locks up - without a timeout it's possible to get stuck forever trying to dequeue.

I think the best option is to connect the timeout to a property on the element so it can be adjusted as needed, and give it a suitably large default.

I still would like to know why you'd ever get 1.5 seconds gap between frames though. That's far too much - way more than a frame duration at any sensible framerate.