[Bug 758522] New: Video freezes with v4l2 error when dynamically changing pipeline

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 758522
           Summary: Video freezes with v4l2 error when dynamically
                    changing pipeline
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: tony.buckley000 at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 316075
  --> https://bugzilla.gnome.org/attachment.cgi?id=316075&action=edit
Program to replicate issue (Makefile included as comments)

I have c program that will draw over a camera video stream (v4l2) using a cairo
overlay element when the user selects a menu option. Un-selecting the option
will stop the drawing. Program (see attached) uses a blocking pad to
dynamically alter the pipeline.

This problem causes the video to freeze (need to restart once it happens) with
the error message:-

libv4l2: error turning on stream: Invalid argument

sometimes showing on the console. Things will often work for a while before
freezing.
Problem can occur on either the 'switch on' action to start drawing over the
video or the 'switch off' action, but 'switch off' never shows the error
message, just freezes.

Problem did not occur using the laptop's built-in camera, but did occur using 2
other external USB cameras.
NB. Remember the code defaults the device to '/dev/video0' so may need to
change.
Problem went away when the video sink was changed from 'xvimagesink' to
'ximagesink'.
Unsure whether this is specific to dynamically adding a Cairo overlay and just
dynamically adding in general.

Have tried enabling (following a forum suggestion) some debug thus:

echo 0xff > /sys/module/videobuf2_core/parameters/debug

to check for kernel issues and set GST_DEBUG=1 but these did not look to show
anything significant AFAICS.
Problem appears to occur directly after the 'return GST_PAD_PROBE_REMOVE' in
'pad_probe_cb' (see attached program).

Of course, my method for dynamically adding / removing may be flawed although I
think I've kept the basics from various samples I've looked at. Please advise
if I'm doing something stupid!

I have attached a program to reproduce the error. The pipeline in the sample
isn't exactly the same as my original code which also has GUI interface (too
large and involved to post), but is cut down and does replicate the issue.

Regards.
Tony

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