V4L2_BUF_FLAG_LAST is set and epipe is returned
Opened this issue · 9 comments
I wonder whether we could skip this flag to avoid epipe errors.
All the buffer operations are done here. It would be necessary to see in which of those operations they want that flag to be added. Anyway, it seems that it will be patched in the kernel (as I understand), so patching it in my code does not seems to be that much necessary.
what might be the patch here if the kernel is too old, and cannot be easily updated? thanks!
You can see here a list of all kernel versions maintained by the Linux developers, those are the only versions supported by akvcam, all those versions will receive the patch soon or later, and you are most probably using one of those kernels right now, if not just upgrade your system, also v4l2-compliance isn't reporting any bug in the driver, so this is most probably an edge case, therefore, there is not any reason to care about that patch.
If you still insist on applying the patch you can trace the code starting from here and look where that function is being used.
Also, didn't figured until now but
Dec. 8, 2017, 2:01 p.m. UTC
That bug was patched 5 years ago. Again there is not any reason to care about.
I am not sure why I still see epipe error then.
Give me the code snippet that is failing, also uname -r.
This is wine read v4l2 frame.
# uname -r
5.4.0-1065-gke
Which program did you tested? Also, I need the debugging log.
Also 1, if it's failing in the reading, the flag should be marked at akvcam_buffers_buffer_prepare, or akvcam_buffers_stop_streaming, or a combination of both, not sure which one yet.
Also 2, here are the list of drivers using V4L2_BUF_FLAG_LAST:
https://github.com/torvalds/linux/blob/master/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/allegro-dvt/allegro-core.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/st/sti/delta/delta-v4l2.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/qcom/venus/vdec.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/qcom/venus/hfi_msgs.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/chips-media/coda-jpeg.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/chips-media/coda-bit.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/chips-media/coda-common.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c
https://github.com/torvalds/linux/blob/master/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateful.c
I've to trace the code to understand how it's being used. I can't do it now because I'm busy with other things, in the best case I won't return to this until a couple of months.
It is an internal project, which I cannot share just yet.
streaming_stopped
I can test a patched akvcam version without explicit streaming_stop. ie. it just starts on module init, and we never call stop in any case. I am not sure how to do that yet.
It is an internal project, which I cannot share just yet.
Ok, but did you tried running a working program like ffmpeg/ffplay, or a working code example to discard a bug in your code?
I can test a patched akvcam version without explicit streaming_stop. ie. it just starts on module init, and we never call stop in any case. I am not sure how to do that yet.
What you expect to happen by removing a key function? if the program have a bug, you must fix the but, not removing code at random expecting the code to be fixed magically.