EPIPE (Broken pipe) when using stateful decoder and format changes about v4l2r HOT 2 OPEN

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?

from v4l2r.

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.

from v4l2r.