GNOME Bugzilla – Bug 743338
gstv4l2bufferpool: handle -EPIPE from DQBUF to signal EOS
Last modified: 2015-06-10 01:58:48 UTC
Created attachment 295160 [details] [review] gstv4l2bufferpool: handle -EPIPE from DQBUF to signal EOS At the media summit at ELC-E 2014, we agreed that for mem2mem decoders, additionally to setting a (not yet specified) flag for the last buffer, VIDIOC_DQBUF should return -EPIPE after the last buffer has been dequeued on the capture queue. We can use this in the V4L2 decoder to signal EOS after -EPIPE was received.
Review of attachment 295160 [details] [review]: This patch look good. There has been no object so far on the media mailing list. I'll give it a little time, but it seems like a good way to handle EOS. Also it's backward compatible, which makes this even nicer.
Seems like there are no further comments...
The related kernel patch is queued in the media tree as c16218402a00 ("[media] videobuf2: return -EPIPE from DQBUF after the last buffer") now: http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=c16218402a000bb25c1277c43ae98c11bcb59bd1
Great news ! Thanks for the update, I'll soon try to find time to review and merge this.
Note, I have imported latest headers from media tree. You can read _LAST flag now, even though EPIPE in general should do.
Looking at the kernel patch, we really don't need to care about the flag.
Review of attachment 295160 [details] [review]: gstv4l2allocator.c: In function 'gst_v4l2_allocator_dqbuf': gstv4l2allocator.c:1300:12: error: incompatible types when returning type 'void *' but 'GstFlowReturn {aka enum <anonymous>}' was expected return NULL;
Attachment 295160 [details] pushed as 95bab88 - gstv4l2bufferpool: handle -EPIPE from DQBUF to signal EOS
I fixed it myself before pushing. Please, don't disable gst-indent or build warning when submitting patches.