02:26 <ndufresne> mjourdan, ok, I reproduced it, and I have a patch

02:32 <ndufresne> mjourdan, if it apply, you could include this patch to you yocto recipe, https://gitlab.collabora.com/nicolas/gst-plugins-good/commit/d9a6045db2f929bf64ec83dd91b4dfe02fb07b90

02:34 <ndufresne> I also made a hack to increase the number of capture buffers to a minimum of 8. when I query V4L2_CID_MIN_BUFFERS_FOR_CAPTURE I get value 0, and later on, when I do REQBUFS, I get 4 buffers (the number I have requested)

02:34 <ndufresne> So the pipeline stall, this one is on your side I believe (assuming there is no race between the header parsing and this call of course)

02:37 <ndufresne> after that, seek kind of work, but the content of the buffers is messed up, let's me record the output you'll see

02:44 <ndufresne> mjourdan, https://people.collabora.com/~nicolas/amlogic/seek.mov

02:44 <ndufresne> (this is an HDMI capture, it plays for few seconds and seek around 1min, then keep playing)

02:54 <ndufresne> mjourdan, after this fixe, I could not reproduce the kernel crash, or I was just lucky

02:54 <ndufresne> though it does not mean the crash no longer exist ;-D

02:55 <ndufresne> interesting, this dash streams (h264) seems to works, http://www.bok.net/dash/tears_of_steel/cleartext/stream.mpd

02:56 <ndufresne> most other fails with an EBUSY from the driver

02:59 <ndufresne> these HEVC samples don't seem to work, both mp4 and mpd

03:04 <ndufresne> when it fails we can read "alloc_contig_range: [73800, 73900) PFNs busy" on kernel logs

03:04 <ndufresne> an example that fails sometimes, gst-play-1.0 https://devstreaming-cdn.apple.com/videos/streaming/examples/img_bipbop_adv_example_ts/master.m3u8

03:07 <ndufresne> mjourdan, seeking on the transformer file caused "meson-vdec c8820000.video-decoder: Buffer 7 done but it doesn't exist in m2m_ctx"

03:10 <ndufresne> seek with HEVC seems to hang systematically

03:20 <ndufresne> that's it for tonight, I'll test this fix on CODA and Venus, and if it's all good, I'll put that in stable, for 1.14.5

08:23 <mjourdan> ndufresne: Thanks for the patch. On my end I'm guessing I should drop support for create_bufs as you said.

08:24 <mjourdan> Oh boy, that video is trippy :D .

08:25 <mjourdan> Thanks for all the testing, I'll try to reproduce and fix today

09:01 <mjourdan> ndufresne: With your patch, I still get the 31 buffers. And if I comment out support for create_bufs, then the CAPTURE queue is not restarted on seek (it's only stopped). Were there any important changes in 1.14.3/4 ?

09:07 <mjourdan> ndufresne: Oh, and yocto has 3 patches for plugins-good but none seem of any importance really.

09:53 <mjourdan> ndufresne: ah, I see what's happening. You're requeuing up to min_buffers instead of all the allocated buffers (which is a valid case, but I can't start streaming on the capture queue until all allocated buffers are queued).

09:53 <mjourdan> ndufresne: because of the hack I made to have 8 buffers, the same one you hacked user-side with the 8 minimum

09:55 <mjourdan> I'm trying to understand why you don't queue all allocated buffers, instead of either creating them up to 32 (before your patch), or queuing only the minimum (after your patch).

10:40 <mjourdan> ndufresne: I pushed out fixes for:

10:40 <mjourdan> - hangs when userspace used create_bufs to make more buffers than allocated via reqbufs (although I don't think you should call that anyway)

10:40 <mjourdan> - wrong MIN_BUFFERS_FOR_CAPTURE value (was too low).

10:43 <mjourdan> seeking no longer hangs (same as you), but I haven't dumped the frames yet to see if I have the same trippy effect as you.

10:45 <mjourdan> Yeahh I also have it. *looking at what's wrong*

10:49 <mjourdan> ndufresne: there doesn't seem to be something wrong with the decoder. What I think is happening is that you keep refs on old buffers (than you then replace with create_bufs or something?) and keep displaying them.

13:42 <ndufresne> mjourdan, it's the Gst core that make my life a pity, the GstBufferPool class in core is way too opaque, I'll rework the patch to poke at the allocator for the number of allocated buffers then

13:42 <ndufresne> mjourdan, my hack was to increase min_buffers, so I was not testing the same ....

13:44 <ndufresne> mjourdan, I really don't get why you get 32 buffers after my patch, maybe it triggers a bug in the min threshold, so it keeps increasing the allocation

13:44 <ndufresne> When you return more buffers to reqbufs, gstreamer v4l2 turns into a state where it will maintain a minimum number of buffers in the drivers, and copy-out the frames is it's too low

13:45 <ndufresne> but before copying out, it will try and call create_bufs, this was tested with camera's, but never with codecs

13:47 <ndufresne> mjourdan, about the trippy effect, reminder that same code works on venus and coda, so I'm pretty sure the referencing and frame picking is working

13:50 <mjourdan> ndufresne: it's just so weird, because some of the frames that "flash" during the effect are from before the seek. But when seeking, the decoder is fully reset in HW...

13:50 <mjourdan> it's like the fds sent to drm are still pointing to old buffers

13:51 <ndufresne> It needs more investigation, when I get more time, I'll try and see if I can find some clue

13:53 <mjourdan> ndufresne: sure, thanks a bunch, this one is tough..

13:53 <ndufresne> great progress though

13:54 <ndufresne> removing CREATE_BUFS would re-assure me, since clearly the crash on null ptr I had was triggered by that

13:54 <mjourdan> I understand it only happens on this platform, but from the decoder point of view, seeking with gst is like a full reset as if you had opened another file. There's no way these old frames end up in the buffers I'm returning as DONE :S .

13:55 <ndufresne> small tiny detail, I don't think we reallocate the buffers

13:55 <mjourdan> yeah that's the only thing

13:55 <ndufresne> so it's not a new set of buffers (that would be way too slow)

13:55 <mjourdan> ah nvm I have an idea

14:00 <ndufresne> long term, we'd like drivers to accept sets of buffers from larger width high, for lower resolution playback, but this is not supported by any drivers atm

14:01 <ndufresne> CREATE_BUFS was also an attempt to allow allocate buffers of a new size while running, but there is no way to free the old one, so it's kind of useless

14:01 <mjourdan> Ah I see

14:02 <mjourdan> being able to keep larger buffers to decode lower res would be nice indeed

14:06 <ndufresne> note that for iommu based hw, it's less of a problem to re-allocate

14:18 <mjourdan> ndufresne: so, to solve the flashy effect I need to remove create_bufs (which needs to be off anyway). Right now it messes with buffer IDs and I no longer have HW<->v4l2 buffer ID mapping.

14:18 <mjourdan> But if I remove it, then the gst pipeline freezes during seek because the capture buffers aren't queued back in.. :<

14:19 <mjourdan> It's the last thing and then we'll have proper seeking with gst

14:21 <ndufresne> so, I'll check if in my test create_bufs was still called, I'll probably add a patch that ensure it's never called for decoder as clearly that is broken on both sides

14:22 <ndufresne> mjourdan, it's quite obvious you should stick with 1.14.4 and newer 1.14 btw, I have no idea why Yocto people are so slow maintaining GStreamer, all major distros stay on latest stable these days except Yocto

14:25 <mjourdan> Yeah I know .. I have to cross compile so many things with various patches that yocto ends up being the faster solution for me, alas poky is not always up to date for everything

18:21 <steev> narmstrong: just a random ping, had a chance to think about the 1366/1360 issue? No biggie if you haven't, i've been super busy with other things and haven't even had a chance to look and see if something was done if you had

18:22 <narmstrong> steev: sorry. No :-/

18:22 <narmstrong> steev: I’m adding it right no to my new formal todo list !

18:22 <steev> all good, like i said i've been busy with other stuff. i don't even have it plugged in to that screen at the moment

18:26 <narmstrong> It’s an hdmi screen right ?