[gst-devel] gstV4L2src: Issue with blocking VIDIOC_QBUF
amal_p_98 at yahoo.com
Thu Aug 23 09:46:31 CEST 2007
I created the following pipeline:
gstV4L2src ! tee ! queue ! videosink
The videosink is an experimental one.
The gstV4L2src is launched with default configuration.
This pipeline works like a viewfinder. However I am
seeing some problem once the queue is introduced.
It seems that very frequently the queue accumulates a
bunch of frames and then sends them to the videosink.
The problem happens because the gst_pad_push() call
seems to be blocked.
The gst_pad_push() renders the buffer in the videosink
and then unrefs the buffer. The unref call ends up
calling VIDIOC_QBUF of the v4l2 camera driver.
At some point during data flow the gstv4l2src switches
to a mode where it does a memcpy before sending out
buffer downstream. This is when the number of buffers
de-queued is equal to the total number of buffers
allocated by the driver.
In this mode gstv4l2src immediately calls VIDIOC_QBUF.
So the pipeline gets into a situation where two
threads are calling VIDIOC_QBUF at the same time.
The problem I am seeing is that the VIDIOC_QBUF called
by the unref in the videosink seems to block for a
while. I see a multiple of the other VIDIOC_QBUF calls
happening during this time. Due to this the buffers
get pushed downstream, the queue gets full at some
point and this unblocks the blocked VIDIOC_QBUF. Hence
a bunch of the queued raw frames get displayed in a
Is this a problem with the implementation of the
driver I am using? or is it a general V4L2 issue? Does
it happen due to priorities of the two threads?
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
More information about the gstreamer-devel