i.MX ProcessorsのトピックRe: mfw_v4lsrc discards captured image when queue-size property set to value 3 or below

mfw_v4lsrc discards captured image when queue-size property set to value 3 or below

gauthamkanthara — Mon, 14 Dec 2015 09:35:39 GMT

Hello, Using below mentioned gstreamer pipeline for image capturing,

gst-launch mfw_v4lsrc device=/dev/video0 queue-size=[2 | 3 | 4] ! fakesink -v

When mfw_v4lsrc queue-size property is set to value 3 or less, based on timestamp, got to know that the captured image are been discarded. It works fine with queue-size property value set to 4. Find the logs attached

Gstreamer version: 0.10.36

MFW_GST_V4LSRC_PLUGIN version: 4.0.2

Regards,

Gautham

Original Attachment has been moved to: gst_fakesink_log.zip

Re: mfw_v4lsrc discards captured image when queue-size property set to value 3 or below

Yuri — Fri, 18 Dec 2015 09:20:42 GMT

Hello,

The following - in section “Finding the Buffer Leak” from the linked below –

may explain the issue :

“ […] v4l2src has a buffer pool of a fixed number of buffers which are recycled along
the whole pipeline lifetime. This means that if the pool runs out of buffers, it must
wait until a buffer is freed to write a new image to it.

If v4l2 buffers are not returning fast enough you will lose images waiting for them
to free.”

Embedded GStreamer Performance Tuning - RidgeRun Developer Connection

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: mfw_v4lsrc discards captured image when queue-size property set to value 3 or below

gauthamkanthara — Fri, 18 Dec 2015 09:54:43 GMT

YuriMuhin_ng,

Thank you for the reply and link.

So to keep up to 30 fps, it is clear that, need to configure queue-size property of v4lsrc plugin with value 4 or more.

Regards,

Gautham