Thank you for all the good info and I apologize for the lack of clarity.
Your explanation about the three limits was very helpful and I was finally able to get it to work (see end of post).
Regarding my previous statement:
leaky=upstream does seem to drop frames as desired, but it significantly slows down the pipeline. Meaning, a pipeline that was previously able to keep up is now unable to keep up.
What I observe is that if I add a
leaky parameter to
queue leaky=downstream max-size-buffers=25 anywhere in the pipeline, it takes more CPU resources, or more time if the CPU resource is limited, for the GStreamer pipeline to process each frame. This is not what is expected. I can see that simply by measuring the time between each frame’s retrieval. When adding
leaky=upstream , the interval between frame retrievals from the pipeline exceeds 1/(camera fps). I suspect
leaky breaks something in the pipeline in my case.
Regarding this previous statement:
…retrieved frames become progressively older, eventually reaching about 10 minutes in delay. At that point, the buffer flushes, resulting in the loss of that chunk of data.
What I observe is that when the interval between frame retrievals is longer than 1/(camera fps), the elapsed time between when a frame is captured and when it is retrieved from the pipeline gets longer. That interval grows to several minutes. The interval peaks at approximately 10 minutes and then suddenly drops to about 2 seconds. This means that several minutes’ worth of video frames are lost.
Now, thanks to your explanations, I finally got it to work.
The key was to put a
queue on each side of
videoconvert, specifying all three limits on each side, and
leaky on the left side. I admittedly have no idea why, but by process of elimination, this is the winning pipeline:
rtspsrc protocols=tcp tcp-timeout=5000000 retry=5 location="rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp/" ! rtph264depay ! h264parse ! avdec_h264 ! queue leaky=downstream max-size-buffers=250 max-size-bytes=0 max-size-time=0 ! videoconvert ! video/x-raw,format=BGR ! queue max-size-buffers=250 max-size-bytes=0 max-size-time=0 ! appsink max-buffers=250 drop=true sync=1 name=appsink
If I remove or add anything to both queues’ parameters, the pipeline misbehave. Now, this pipeline has a 10s buffer after which it starts dropping frames piecemeal. Sweet!