[Bug 772521] New: [v4l2src] Regression bug with consecutive recordings

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=772521

            Bug ID: 772521
           Summary: [v4l2src] Regression bug with consecutive recordings
    Classification: Platform
           Product: GStreamer
           Version: 1.8.2
                OS: Linux
            Status: NEW
          Severity: critical
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: arodriguez at teltek.es
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 337081
  --> https://bugzilla.gnome.org/attachment.cgi?id=337081&action=edit
Simple c program to replicate the bug.

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 one second 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


If you need any extra data to be added here, please let me know.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.