I have found an issue/bug with the GStreamer 1.0 implementation of imxv4l2src, I'm looking for a solution and more generally to understand the correct place to post such bugs/questions.
I have created a very simple gst1.0 application based on input-selector-test.c example, modified such that the pipeline looks like this:
imxv4l2src ! caps ! valve ! imxv4l2sink
The application changes the state of the valve from drop=false to drop=true after a specified number of seconds. Unfortunately this results in the following error:
** Message: Valve is now set to drop
0:00:12.083723335 712 0x3ff260 ERROR imxv4l2src
gst1.0-fsl-plugin/4.0.2-r0/gst1.0-fsl-plugins-4.0.2/plugins/v4l2/gstimxv4l2src.c:463:gst_imx_v4l2src_decide_allocation:<src1>
using v4l2 source allocator.
0:00:12.487820001 712 0x3ff260 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.2-r0/gst1.0-fsl-plugins-4.0.2/libs/v4l2_core/gstimxv4l2.c:1429:gst_imx_v4l2_allocate_buffer:
No more v4l2 buffer for allocating.
0:00:12.488049335 712 0x3ff260 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.2-r0/gst1.0-fsl-plugins-4.0.2/libs/v4l2_core/gstimxv4l2.c:1429:gst_imx_v4l2_allocate_buffer:
No more v4l2 buffer for allocating.
0:00:12.492420668 712 0x3ff260 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.2-r0/gst1.0-fsl-plugins-4.0.2/libs/v4l2_core/gstimxv4l2.c:1398:gst_imx_v4l2_find_buffer:
Can't find the buffer 0x766EF508.
0:00:12.492524001 712 0x3ff260 ERROR imxv4l2src
/gst1.0-fsl-plugin/4.0.2-r0/gst1.0-fsl-plugins-4.0.2/plugins/v4l2/gstimxv4l2src.c:586:gst_imx_v4l2src_acquire_buffer:<src1>
Queue buffer 0x75c09db8 failed.
0:00:12.492610335 712 0x3ff260 WARN basesrc
gstreamer1.0/1.4.1-r0/gstreamer-1.4.1/libs/gst/base/gstbasesrc.c:2933:gst_base_src_loop:<src1>
error: Internal data flow error.
0:00:12.492679335 712 0x3ff260 WARN basesrc
gstreamer1.0/1.4.1-r0/gstreamer-1.4.1/libs/gst/base/gstbasesrc.c:2933:gst_base_src_loop:<src1>
error: streaming task paused, reason error (-5)
Got error message
Error: Internal data flow error.
(video:712): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object->refcount > 0' failed
0:00:12.493453335 712 0x400ee0 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.2-r0/gst1.0-fsl-plugins-4.0.2/libs/v4
l2_core/gstimxv4l2.c:1398:gst_imx_v4l2_find_buffer: Can't find the buffer 0x00000000.
Using gst1.0-fsl-plugin/4.0.3-r0 also results in this similar error:
** Message: Valve is now set to drop
0:00:12.386593002 750 0x1eb8460 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1452:gst_imx_v4l2_allocate_buffer:
No more v4l2 buffer for allocating.
0:00:12.386899668 750 0x1eb8460 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1452:gst_imx_v4l2_allocate_buffer:
No more v4l2 buffer for allocating.
0:00:12.387092668 750 0x1eb8460 ERROR imxv4l2 ERROR:
v4l2 capture: VIDIOC_QBUF: buffer already
queuedgst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1452:gst_imx_v4l2_allocate_buffer:
No more v4l2 buffer for allocating.
0:00:12.387223335 750 0x1eb8460 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1452:gst_imx_v4l2_allocate_buffer:
No more v4l2 buffer for allocating.
0:00:12.455394002 750 0x1eb8460 WARN imxv4l2
gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1686:gst_imx_v4l2_queue_gstbuffer:
new buffer (0x75c09e58) use the same memblk(0x75004a64) with queued buffer(0x75c09958)
0:00:12.455493668 750 0x1eb8460 WARN imxv4l2
gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1689:gst_imx_v4l2_queue_gstbuffer:
gstbuffer(0x75c09958) for (0x7696c750) not dequeued yet but queued again, index(1975556440).
0:00:12.461249002 750 0x1eb8460 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1571:imx_v4l2_do_queue_buffer:
queue v4l2 buffer failed.
0:00:12.461293335 750 0x1eb8460 ERROR imxv4l2
gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/libs/v4l2_core/gstimxv4l2.c:1693:gst_imx_v4l2_queue_gstbuffer:
queue gstbuffer (0x75c09e58) failed.
(video:750): GStreamer-CRITICAL **: gst_buffer_get_meta: assertion 'buffer != NULL' failed
(video:750): GStreamer-CRITICAL **: gst_buffer_add_meta: assertion 'buffer != NULL' failed
I believe the change in 'drop' state results in a reconfigure event reaching imxv4l2src which it doesn't appear to handle correctly. Replacing imxv4l2src with videotestsrc results in the expected behaviour when the valve is set to drop.
Furthermore, when modifying gstimxv4l2src.c to override the default GST_EVENT_RECONFIGURE event such that it only clears the event (gst_pad_check_reconfigure) it then works as expected.
This appears to be a bug - has this been seen before or already fixed?
Are there any suggestions for the correct way of fixing this?
Is there a mailing list for this component or a place to contribute/question/discuss?
Andrew Murray
The reconfigure work around that I described (override GST_EVENT_RECONFIGURE event) was sufficient for my needs so I have not explored this in more detail.
I have found another issue which relates to a more complex pipeline, this results in the 'ERROR: v4l2 capture: VIDIOC_QBUF: buffer already queued' error. This relates to a bug in libs/v4l2_core/gstimxv4l2.c as follows:
- At start of day gst_imx_v4l2_set_buffer_count uses the VIDIOC_REQBUFS ioctl instruct the kernel to allocate 'buffer_count' number of buffers.
- Throughout the life of the filter, gst_imx_v4l2_allocate_buffer and gst_imx_v4l2_free_buffer are called to mmap and munmap the buffers
- The v4l2_buffer->index member is used to refer to the specific buffers previously allocated by VIDIOC_REQBUFS - this index is assigned in the gst_imx_v4l2_allocate_buffer function - however the index isn't assigned suitably, it is assigned to the total number of buffers currently allocated. This index assignment scheme makes assumptions about the ordering of gst_imx_v4l2_allocate_buffer and gst_imx_v4l2_free_buffer calls. To illustrate this...
Upon start up, the filter allocates initial buffers, thus the first 4 buffers allocated have an index which match the number of the total number of buffers allocated at that time (handle->allocated):
v4l2_buffer's present with indexes: 0, 1, 2, 3
handle->allocated is now set to 4
In a dynamic pipeline (where elements are added/removed etc) - its seems that gst_imx_v4l2_free_buffer may be called to release a specific buffer index, thus imagine index 0 is now free'd:
v4l2_buffer's present with indexes: 0, 1, 2, 3
handle->allocated is now set to 3
Now watch what happens when gst_imx_v4l2_allocate_buffer is next called:
v4l2_buffer's present with indexes: 0, 1, 2, 3, 3
handle->allocated is now set to 4
We now have two different v4l2_buffer's with the same index. Thus you can imagine how you end up with 'buffer already queued' errors.
I've overcome this issue by creating a map that keeps track of index numbers that are available for use - this seems to work for me. I have no idea how other filters manage index numbers.
I could provide a patch, however I suspect your version (4.0.7) of this project has moved on from the latest publicly available version?
I know this is an old thread, but I think the problem you describe still exists in 4.0.7 (and 4.0.8).
Can you share your fix?
I think a simple imxv4l2src ! queue ! videorate ! fakesink shows the problem.
I don't believe 4.0.7 is publicly available - I get a 404 if I try http://www.freescale.com/lgfiles/NMG/MAD/YOCTO//gst1.0-fsl-plugins-4.0.7.tar.gz.
I'd like to test this, is it possible to gain access to this version?