On Sun, 09 Mar 2025 00:26:08 +0100,
Kirill A. Korinsky <kirill@korins.ky> wrote:
> 
> On Sat, 08 Mar 2025 21:31:06 +0100,
> Marcus Glocker <marcus@nazgul.ch> wrote:
> > 
> > I would like to cleanup the queuing in small steps.  Hence, not
> > removing SIMPLEQ yet.  Would this diff fix your issue when receiving
> > multiple frames in one transfer?  It looks my devices don't do that
> > very often, so difficult for me to test.
> >
> 
> I just tested your diff. It's again frozes the system completley, and with
> added some print I was able to prove that it is again, inside the queue.
> 
> It iterates here:
> 
> 	while (!SIMPLEQ_EMPTY(&sc->sc_mmap_q))
> 		SIMPLEQ_REMOVE_HEAD(&sc->sc_mmap_q, q_frames);
> 
> and by my printf here I see that the cause that sc_mmap_q contains an
> element which points to itself as the next one.
> 
> I really think that the root cause that ffmpeg / ffplay uses 4-6 buffers
> when streams from this device, and we have insert and remove from parallel
> threads to the same queue.
> 
> Thuis, if I enable debug, I can reproduce it not each time, and if I
> increase uvideo_debug, I can't reproduce it at all.
> 
> All of this smells like issue from non thread-safe code.
>

Ha, I just had frozes the machine with my patch as well from ffplay in X11.

-- 
wbr, Kirill