I'm trying to add HEVC hardware decoding to Chromium. Currently, the V4L2 decoder gets to the stage where it is applying the resolution change, but fails to set the format because of an EBUSY error. The V4L2 docs suggest that this is because the stream has not been stopped, but I can see from the logs that both queues have been stopped.
Here's the dmesg output, showing the calls to VIDIOC_STREAMOFF, before the failed call to VIDIOC_S_FMT:Looking at (what I think is) the kernel driver, EBUSY is returned when there are still buffers queued. But, if I'm not mistaken, the driver should have freed them up when the stream was stopped.
Is my understanding correct? Is this unexpected or is there some difference in sequence of events between the H.264 and HEVC codecs?
Here's the dmesg output, showing the calls to VIDIOC_STREAMOFF, before the failed call to VIDIOC_S_FMT:
Code:
[20584.943290] rpivid feb10000.codec: rpivid_h265_stop[20584.947407] video19: VIDIOC_STREAMOFF: type=vid-out-mplane[20584.947536] video19: VIDIOC_STREAMOFF: type=vid-cap-mplane[20584.947633] video19: VIDIOC_G_FMT: type=vid-out-mplane, width=1920, height=1088, format=S265 little-endian (0x35363253), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0[20584.947662] plane 0: bytesperline=0 sizeimage=1048576[20584.947675] video19: VIDIOC_S_FMT: error -16: type=vid-out-mplane, width=320, height=240, format=S265 little-endian (0x35363253), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0Is my understanding correct? Is this unexpected or is there some difference in sequence of events between the H.264 and HEVC codecs?
Statistics: Posted by ewanr-bbc — Thu Feb 29, 2024 4:10 pm — Replies 1 — Views 25