01:46 <ndufresne> mjourdan, not much progress on my side tonight, the driver prints "[ 75.445668] meson-vdec c8820000.video-decoder: Res. changed (1920x1080), DPB size 10", which seems correct, but when gst get the CID, the returned value is 0, no 10

01:46 <ndufresne> and so it hangs

01:49 <ndufresne> mjourdan, I believe the CREATE_BUFS calls you are seeing are "index=0, count=0", this is just a hack to check if the ioctl is supported

01:51 <ndufresne> mjourdan, oh, interesting, no matter how long I wait, it seems that the trace "Res. changed (1920x1080), DPB size 10" only comes after video0: VIDIOC_STREAMON: type=vid-cap-mplane"

01:52 <ndufresne> the parser should be running as soon at we do streamon on OUTPUT

01:52 <ndufresne> at least, this is what all the other codecs do atm

01:53 <ndufresne> because otherwise, I'm stuck with having to allocate some buffers, just for the sake of calling streamon, and will likely have to reallocate them

02:29 <ndufresne> mjourdan, strange, after the flush in a seek, gstream reverse the order or STREAMON, it does qbuf(capture, all), STREAMON(capture), qbuf(out), STREAMON(out)

02:30 <ndufresne> could that be the reason is hangs now ?

02:53 <ndufresne> mjourdan, btw, I have changed the yesterday's fix to use the number of allocated buffers, this way, if REQBUFS changes the value, it should behave correctly

02:54 <ndufresne> I also do this hack to workaround the MIN_BUFFERS being 0, https://paste.fedoraproject.org/paste/Ca2GD6gp04c4bcmPstuRnQ

08:50 <mjourdan> ndufresne: You can only expect V4L2_CID_MIN_BUFFERS_FOR_CAPTURE to have a relevant value after a "Res changed" log. In your case, it should return 10 once you see that "DPB size 10" message.

08:50 <mjourdan> But on my end it doesn't look like the control is queried after I send the src_change event

08:51 <mjourdan> I'd love to be able to support streaming only the OUTPUT queue but for now it's a limitation as this mode can't work with older codecs :(. MPEG2 & co require to have both queues up before running.

08:52 <mjourdan> The only other implementation that supports src_change is chromium, and they setup a dummy capture queue + streamon at init., which is what I initially tested with

09:05 <poulecaca> j

09:05 <poulecaca> oups sorry

11:58 <ndufresne> mjourdan, well, you're drive should take care of the dummys then, since it's specific to this hw

11:58 <ndufresne> mjourdan, it make no sense to allocate random size and impose this on usespace

11:59 <ndufresne> specially when the buffers are contiguous

12:00 <ndufresne> mjourdan, anyway, the point is that even if I implement the size change, I'll never receive it from your driver unless I implement this dummy buffers hack, I'm not sure I want this to be the general case

12:02 <ndufresne> mjourdan, and about the streamon order, do you have some input ? do you impose that streamon must be OUTPUT follow by CAPTURE ?

12:06 <ndufresne> anyway, for later ....

12:16 <mjourdan> ndufresne: oh yeah no problem, I'm just telling you how it's now, I understand it's not optimal at all for userspace to have to allocate those dummy buffers.

12:16 <mjourdan> ndufresne: there's no particular order in which to stream the queues

12:18 <mjourdan> There's just one thing at the moment: without any hack for min buffers, then gst doesn't query V4L2_CID_MIN_BUFFERS_FOR_CAPTURE after it receives the SRC_CHANGE event, and doesn't seem to reconfigure the capture queue.

12:34 <ndufresne> mjourdan, that's correct

12:35 <ndufresne> mjourdan, and I guess there is no by-pass atm if the capture queue is streaming already with the right amount of buffers ?

12:35 <ndufresne> I think you said that one must reset all queues, I think I'm starting to understand ;-D

12:42 <mjourdan> ndufresne: if you already set the resolution and you have enough buffers for DPB, then the event isn't fired and the decoder keeps running.

12:42 <mjourdan> If you receive the event, then you must streamoff/querybuf/streamon the capture queue

12:42 <mjourdan> You don't have to reset the output queue

12:43 <mjourdan> reqbufs* sorry not querybuf

12:45 <mjourdan> In the scenario that I'm looking at right now: gst streams both queues, with 4 CAPTURE buffers allocated. Then my driver fires the SRC_CHANGE event and V4L2_CID_MIN_BUFFERS_FOR_CAPTURE is set to 10 (the DPB size for this bitstream).

12:45 <mjourdan> Then I wait until userspace has reset the capture queue

12:47 <mjourdan> (which doesn't seem to happen)

13:45 <ndufresne> mjourdan, right, same behaviour, I then hacked up something to gst thinks that the driver said 10, but on seeks it still hang, from the traces, I'm pretty sure all 10 buffers have been requeued, I'll check if the event is fired, that would be an indicated that it's not happy with the current state

13:46 <ndufresne> with my hacks yesterday, it didn't hang, something must be different

13:46 <ndufresne> all this needs a rework in gst, that I admit

13:48 <ndufresne> I'm pulling 15years of ancient code, it takes a lot of time to change this without breaking camera captures

13:50 <ndufresne> anyway, whenever I get some time, I got some big plan, for the dummy buffers, I guess if we don't figure-out anything, we should consider this as valid quirk, but add a device flag to tell userspace, so I don't need to hardcode random strings/driver names

13:50 <ndufresne> if chromium does this, it means there is at least one other driver that does not function without

14:02 <mjourdan> ndufresne: the seeks "worked" (with the trippy effect) with create_bufs enabled, but they no longer do since I disabled it.

14:02 <mjourdan> ndufresne: hehe no worries

14:02 <mjourdan> ndufresne: about the dummy buffers, we'll see how the spec turns out, but ultimately we want to make your life simpler