EPIPE (Broken pipe) when using stateful decoder and format changes

[FallingSnow]

I have a video stream that changes from 800x600 to 640x480. I'm using the stateful decoder and I expect the set_capture_format_cb function to be called when this happens but instead I get a bunch of broken pipe errors and CPU usage goes to 100%. I'm using the raspberry pi's v4l2mem2mem hardware decoder.

This is an strace of the process when this happens.

...
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
epoll_pwait(16, [{EPOLLIN, {u32=0, u64=4294967296}}], 4, -1, NULL, 8) = 1
ioctl(14, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE}) = -1 EPIPE (Broken pipe)
^Cstrace: Process 11318 detached

[Gnurou]

Hi,

Does the pi driver actually trigger the resolution change event? The V4L2 documentation mentions this about EPIPE:

VIDIOC_DQBUF returns this on an empty capture queue for mem2mem codecs if a buffer with the V4L2_BUF_FLAG_LAST was already dequeued and no new buffers are expected to become available.

A DRC event normally implies the event being sent, then a CAPTURE buffer with the LAST flag being returned (at which point user-space can check pending V4L2 events to know whether this is a DRC or the end of the stream). After this sequence of events v4l2r should not be trying to dequeue CAPTURE buffers anymore and should certainly not end up in a busy loop.

Could you attach the output of strace -f run on your decoding process to understand if the problem might come from the driver itself?

[FallingSnow]

Well it seems to trigger the initial resolution change at least since the feed initially works, but I'm not sure about resolution changes mid stream. I did come across this post recently that describes some of the inner workings of the RPi v4l2 decoder and makes references to the EPIPE error I'm seeing.

The post response by Raspberry Pi Foundation's 6by9 suggests the same process you described so I assume the RPi does do this.

Question:

if a V4L2_EVENT_SOURCE_CHANGE event with changes set to V4L2_EVENT_SRC_CH_RESOLUTION is pending, the Dynamic Resolution Change sequence needs to be followed,
if a V4L2_EVENT_EOS event is pending, the End of Stream sequence needs to be followed.

Response:

So you can dequeue the appropriate pending event and act accordingly.

Either way I'll double check if the pi is actually submitting a V4L2_EVENT_SRC_CH_RESOLUTION event for v4l2r to pick up on.

Could you attach the output of strace -f run on your decoding process to understand if the problem might come from the driver itself?

I'll get this for you.