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 725886 - v4l2/gst_v4l2_object_poll handle POLLERR
v4l2/gst_v4l2_object_poll handle POLLERR
Status: RESOLVED DUPLICATE of bug 731015
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-07 10:54 UTC by matthieu
Modified: 2014-07-04 11:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for the issue (972 bytes, patch)
2014-03-07 14:08 UTC, matthieu
reviewed Details | Review
patch v2 (1.26 KB, patch)
2014-03-10 09:30 UTC, matthieu
none Details | Review

Description matthieu 2014-03-07 10:54:15 UTC
If there is no buffer if kernel, v4l2 api can report it with
POLLERR. Catch it instead of waiting forever on VIDIOC_DQBUF.
Comment 1 Nicolas Dufresne (ndufresne) 2014-03-07 13:49:58 UTC
Would it be possible to give more details, e.g. some steps to reproduce, HW you are running on etc. Or maybe you are going to provide a patch ?
Comment 2 matthieu 2014-03-07 14:08:09 UTC
Created attachment 271233 [details] [review]
patch for the issue
Comment 3 matthieu 2014-03-07 14:09:18 UTC
@Nicolas
oops the patch wasn't attached. It should be better now.
Comment 4 Nicolas Dufresne (ndufresne) 2014-03-07 16:32:32 UTC
Review of attachment 271233 [details] [review]:

::: sys/v4l2/gstv4l2bufferpool.c
@@ +658,3 @@
+        ret = gst_poll_fd_has_error(v4l2object->poll, &pollfd);
+        if (ret)
+       	  goto stopped;

I'm not sure returning GST_FLOW_FLUSNING is right here, can you explain your decision ?
Comment 5 matthieu 2014-03-10 09:29:01 UTC
I agree GST_FLOW_ERROR seems better.

But I don't understand why GST_FLOW_FLUSHING is called in case of EBUSY. According to http://v4l-test.sourceforge.net/spec/r14169.htm EBUSY is returned in case of multiple read/write.
Comment 6 matthieu 2014-03-10 09:30:34 UTC
Created attachment 271404 [details] [review]
patch v2
Comment 7 Nicolas Dufresne (ndufresne) 2014-03-10 14:19:12 UTC
(In reply to comment #5)
> I agree GST_FLOW_ERROR seems better.
> 
> But I don't understand why GST_FLOW_FLUSHING is called in case of EBUSY.
> According to http://v4l-test.sourceforge.net/spec/r14169.htm EBUSY is returned
> in case of multiple read/write.

From documentation from gst_poll_set_flushing():

"When flushing is TRUE, this function ensures that current and future calls to gst_poll_wait() will return -1, with errno set to EBUSY."
Comment 8 Nicolas Dufresne (ndufresne) 2014-03-10 14:24:47 UTC
Review of attachment 271404 [details] [review]:

::: sys/v4l2/gstv4l2bufferpool.c
@@ +679,3 @@
+    GST_ELEMENT_ERROR (v4l2object->element, RESOURCE, READ, (NULL),
+        ("poll return pollerr"));
+    return GST_FLOW_ERROR;

Does errno has something meaningful in this case ?
Comment 9 matthieu 2014-03-11 16:58:18 UTC
(In reply to comment #8)
> Review of attachment 271404 [details] [review]:
> 
> ::: sys/v4l2/gstv4l2bufferpool.c
> @@ +679,3 @@
> +    GST_ELEMENT_ERROR (v4l2object->element, RESOURCE, READ, (NULL),
> +        ("poll return pollerr"));
> +    return GST_FLOW_ERROR;
> 
> Does errno has something meaningful in this case ?

No in this case gst_poll_wait return with ret == 1 and errno is not set.
Comment 10 Nicolas Dufresne (ndufresne) 2014-05-31 02:00:12 UTC
Marking as a dup. Next time please report the problem you are seeing, would help.

*** This bug has been marked as a duplicate of bug 731015 ***
Comment 11 Nicolas Dufresne (ndufresne) 2014-05-31 02:00:28 UTC
Thanks for reporting.
Comment 12 matthieu 2014-07-04 11:36:10 UTC
Thanks for taking care of this bug after some much time.

The setup was complex, that why I only reported the problem in gst_v4l2.