[gst-devel] gstV4L2src: Issue with blocking VIDIOC_QBUF

[Amal Prabhu]

Hi, 

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
spurt. 

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? 

Thank you
Best Regards
Amal



       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469