After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 407369 - [v4l2src] Wrong way of EIO error handling
[v4l2src] Wrong way of EIO error handling
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal critical
: 0.10.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-02-13 06:52 UTC by Andrey Plotnikov
Modified: 2007-02-19 12:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
v4l-info output (17.03 KB, text/plain)
2007-02-13 11:32 UTC, Andrey Plotnikov
Details

Description Andrey Plotnikov 2007-02-13 06:52:22 UTC
New way of EIO error handling (v4l2src_call.c, rev 1.51) leads to loosing buffers
(I mean buffers which are queued for grabbing frames) and as a result it leads to
total application crash (when last buffer has been lost).

The source of the problem is a new way of processing error during buffer
reenqueueing.
Formerly (v4l2src_call.c, rev 1.50), v4l2src element sent error message and it was 
possible to catch this message and restart pipeline. Now this situation just skipped and as a result we lost buffers.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2007-02-13 10:20:27 UTC
Andrey, what v4l2 driver are you using? Can you attach the output of 'v4l-info'? The sv4lsrc needs to handle EIO. IMHO the change is right, as it re-enques the buffers. the buffers were lost in the v4l2 srivers FIFO before when an EIO occured.

http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/sys/v4l2/v4l2src_calls.c?r1=1.50&r2=1.51

Can you maybe also attach a log?
Comment 2 Andrey Plotnikov 2007-02-13 11:31:38 UTC
In my case I have situation when periodically VIDEOC_QBUF call in EIO error processing block is unsuccessful. I mean this code:

195       GST_DEBUG_OBJECT (v4l2src, "reenqueing buffer");
196       if (ioctl (v4l2src->v4l2object->video_fd, VIDIOC_QBUF, &buffer) < 0) {
197         GST_WARNING_OBJECT (v4l2src,
198             "Error queueing buffer on device %s. system error: %s",
199             v4l2src->v4l2object->videodev, g_strerror (errno));
200       }


During debugging I found out that after each such occasion the number of active buffers decreases.

Before, in this situation v4l2src element sent error message. Old code:

qbuf_failed: 	 
 { 	 
  GST_ELEMENT_ERROR (v4l2src, RESOURCE, WRITE, 	 
    (_("Could not exchange data with device '%s'."), 	 
       v4l2src->v4l2object->videodev), 	 
    ("Error queueing buffer on device %s. system error: %s", 	 
       v4l2src->v4l2object->videodev, g_strerror (errno))); 	 
  return -1; 	 
 } 

Now error which rises during reenqueing buffer is skipped and it leads to 
total application crash during the time.
Comment 3 Andrey Plotnikov 2007-02-13 11:32:40 UTC
Created attachment 82454 [details]
v4l-info output
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2007-02-19 12:23:29 UTC
2007-02-19  Stefan Kost  <ensonic@users.sf.net>

	* sys/v4l2/v4l2src_calls.c: (gst_v4l2src_fill_format_list),
	(gst_v4l2src_grab_frame), (gst_v4l2src_set_capture),
	(gst_v4l2src_capture_init):
	  Readd GST_ELEMENT_ERROR if we can't reenque buffers after EIO,
	  fixes #407369