mjourdan: have you tried looking at V4L2 ioctl debug logs? (the ones you enable with /sys/class/video4linux/videoX/{dev_,}debug
mjourdan: also, are you using the native v4l2 support or via a custom ffmpeg?
tfiga: using the native v4l2 support. Upon seeking, the last log from v4l2_video_decode_accelerator.cc is ResetDoneTask(), and then nothing. Visually it's just an endless loading circle over the video. I'll try with V4L2 ioctl debugging!
mjourdan: https://hverkuil.home.xs4all.nl/spec/kapi/v4l2-dev.html#video-device-debugging
hverkuil: thanks :)
tfiga: Ah.. looks like all but one capture buffers get queued back after streamoffs/streamons, but I need all of them.. I'm guessing the one not queued is the still frame displayed in the video while waiting for the seek to go through ?
paulk-leonov: ping
hverkuil, pong
Hi Paul, I wonder if you could do a quick cedrus & v4l2-compliance test for me.
I committed my Request API compliance tests yesterday, but I'd like to have it tested with the cedrus driver as well.
I know the test will fail, but I'd like to know where it will fail.
In order to make the test work correctly more work will be needed.
hverkuil, sure thing, I will give it a spin later today or tomorrow
but that will be developed first for vicodec by an Outreachy intern when she starts work on this in December.
mjourdan: that's possible
mjourdan: do you need all or you just need a fixed number? if the latter, maybe you need to return a higher value in MIN_BUFFERS_FOR_CAPTURE?
tfiga: All of them sadly. The firmware wants the full list at init and is free to write to any buffer it wants to at any time. so I have min_buffers_for_capture set to the amount of buffers allocated.
tfiga: good review of the rockchip jpeg encoder. Decided to drop the pull request and wait for your comments to be fixed.
tfiga: I know all about backlog. After spending almost two weeks full time on this I am now (mostly) on top of things again.
hverkuil: we have a no meetings week this week and so it's a chance for me to actually spend the time on reviewing
mjourdan: why do you need to re-register them after streamoff?
I suppose there is no reqbufs in the meantime?
tfiga: because both streamoffs trigger a poweroff of the IP :P
mjourdan: okay, something to fix then :)
mjourdan: also, it's MMAP mode I assume?
you know all the buffers even if they're not queued to oyu
given the restrictions, DMABUF mode wouldn't work
(which is actually not so rare for statefull decoders)
tfiga: I guess I do but I can't risk the firmware writing to buffers that are not queued in yet. And yeah it's MMAP
mjourdan: yeah, the buffers that are not queued shouldn't be written to
tfiga: oh I mistook min_buffers_for_capture with queue->min_buffers_needed. Yeah I'm trying right now to raise MIN_BUFFERS_FOR_CAPTURE
tfiga: alright, fixed it by increasing MIN_BUFFERS_FOR_CATPURE (+ a few fixes related to that), and always sending a src change event even if the resolution/dpbsize remain the same
It's overall a bit hacky though, esp. with the part where I now set min_buffers_needed to (dst_bufs_num-1).. probably won't go into the PR
hverkuil: I sent a revert for the bindings doc. That is why the bindings doc patch is on that series.
ezequielg: Ah, and that revert probably hasn't been pulled in yet. Is it even in a pull request? Can you check patchwork?
let me check
no, mchehab hasn't picked the revert patch yet.
hverkuil: the thing is, the vpu dt bindings doc will land in v4.20, unless it's reverted.
hverkuil: so I thought it was better to have that reverted in v4.20, until the driver is accepted.
Ah, it wasn't picked up by anyone.
I'll make a pull request for 4.20 for it.
thanks!
done
mjourdan: the resolution change is an interesting trick indeed, although you might need the patch to allow REQBUFS(0) with exported DMA-bufs in use
tfiga: already patched that a few days ago :D . I wouldn't have been able to even play something without it.
mjourdan: okay :)