bcm2835_codec fixes #3790
bcm2835_codec fixes #3790
Conversation
The allocated input and output buffers are initialised in buf_init and should only be cleared up in buf_cleanup. stop_streaming was (incorrectly) cleaning up the buffers to avoid an issue in videobuf2 that had been fixed by the orphaned buffer support. Remove the erroneous cleanup. Signed-off-by: Dave Stevenson <[email protected]>
…fernum start_streaming passes a count of how many buffers have been queued to videobuf2. Allow this value to update the number of buffers the VPU allocates on a port to avoid buffer recycling issues. Signed-off-by: Dave Stevenson <[email protected]>
start_streaming enabled the VPU component if ctx->component_enabled was not set. stop_streaming disabled the VPU component if both ports were disabled. It didn't clear ctx->component_enabled. If seeking, this meant that the component never got re-enabled, and buffers never got processed afterwards. Signed-off-by: Dave Stevenson <[email protected]>
|
@popcornmix I don't know whether these will fix FFmpeg/Kodi as well. The second patch is working around an issue in GStreamer that has been fixed in 1.16, but I believe is still valid within the V4L2 API, so we ought to support. |
|
I can test with ffmpeg/kodi. |
|
Not sure - I didn't analyse the packet that GStreamer fed back in after the seek. We have done a full codec shutdown on the VPU, however video_decode updates an internal structure which may be enough to restore the codec state after the seek. |
|
If FFmpeg doesn't work, then the way I read the V4L2 M2M spec, as long as it follows the specified procedure then the codec is responsible for remembering the header bytes. That's based on the warning regarding H264 and seeking over a change of SPS/PPS - that wouldn't be necessary if the codec was expected to drop the header bytes. GStreamer shuts down both OUTPUT and CAPTURE queues on seek, therefore I'd view that as reasonable to forget everything. |
kernel: bcm2835_codec fixes See: raspberrypi/linux#3790 kernel: FKMS - correct possible_crtcs flags, and increase the number of planes See: raspberrypi/linux#3740 kernel: config: Add USB gadget support to bcm2711 config kernel: overlays: Regenerate upstream-pi4 kernel: ARM: dts: Add required USB power domain for XCHI
kernel: bcm2835_codec fixes See: raspberrypi/linux#3790 kernel: FKMS - correct possible_crtcs flags, and increase the number of planes See: raspberrypi/linux#3740 kernel: config: Add USB gadget support to bcm2711 config kernel: overlays: Regenerate upstream-pi4 kernel: ARM: dts: Add required USB power domain for XCHI
|
Still waiting on tenterhooks to know if worked with Kodi! |
|
Had some build issues and ended up having to do a clean build. |
|
Got an LE build running, but no joy. H264 video plays but I don't get any video frames out after a seek. |
|
Not sure if there's any useful info here, but after a seek, there are complaints in dmesg (not immediately but after a few seconds). |
|
Hmm, unfortunately, the problem persists. I tested on Raspberry pi 3b+ with youtube playing 1080p video on wpewebkit-fdo platform. Tested on kernel 5.4.59. |
|
I don't understand enough details in this topic, but this patch fixed the seeking issue for me: #3325 (comment) |
|
I believe this issue is also related to this one #3791, where I posted the full dmesg |
These are from investigating seeking not working with gst-play. It does now.