Possible v4l2src regression bug with consecutive recordings

[Alfonso Rodriguez]

Hello everyone,

We are using GStreamer to record video on our opensource software called
Galicaster, and we had an issue when starting several recordings in fast
succession. We narrowed it down to the GStreamer pipeline in C, and we
discovered what seems to be an issue with the gstv4l2allocator when a
recording closes. When this issue happens, the device is 'busy' for the
next pipeline.

The script we used for testing is the following:
http://paste.ubuntu.com/23284568/

It executes a simple pipeline over and over using the same device until it
fails.

We executed the script with GST_DEBUG=3 and we got the following error
(full output in http://paste.ubuntu.com/23284592/):

0:00:27.492185197 11963      0x25bc830 ERROR          v4l2allocator
gstv4l2allocator.c:1245:gst_v4l2_allocator_qbuf:<gc-v4l2-src:pool:src:allocator>
failed queueing buffer 1: Invalid argument
0:00:27.492207147 11963      0x25bc830 ERROR         v4l2bufferpool
gstv4l2bufferpool.c:1127:gst_v4l2_buffer_pool_qbuf:<gc-v4l2-src:pool:src>
could not queue a buffer 1


This was reproduced on an Ubuntu 16.04.1 machine with GStreamer version
1.8.2 using the Logitech HD Webcam C910 and the HD Pro Webcam C920. We
could also reproduce this behaviour with lower quality Logitech cameras,
but it would take longer to reproduce. It seems that the chance to
reproduce the issue is proportional to the video bandwidth.

We think it's a regression bug, because we were not able to reproduce said
behavior on the GStreamer 0.10 and 1.2 versions.

I attached a gist with more information about the tests we did:
https://gist.github.com/Alfro/d94deab6b5b5314f2cee8167019c7239

Should we create a bug in bugzilla with this information? Does anyone have
a similar experience?

Regards,


*Alfonso Rodríguez PereiraTELTEK Video Research*
http://teltek.es/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161006/5d4a57af/attachment.html>