gstreamer 1.20: v4l2bufferpool spams "newly allocated buffer is not free"

[Nicolas Dufresne]

Le lundi 04 juillet 2022 à 15:17 +0200, Michiel Konstapel a écrit :
> 
> On 04-07-2022 01:48, Nicolas Dufresne wrote:
>  
> >  
> > 
> >  
> > Le ven. 1 juill. 2022, 15 h 09, Michiel Konstapel <michiel at aanmelder.nl> a
> > écrit :
> >  
> > > 
> > >  On 30-06-2022 18:04, Nicolas Dufresne via gstreamer-devel wrote:
> > >  >
> > >  >>
> > >  >> I'd be curious to see the value or &pool->buffer_state[group-
> > > >buffer.index] when
> > >  >> that warning triggers. I fail to see how we actually endup in that
> > > situation. I
> > >  >> wonder if there is a relation with:
> > >  >>
> > >  >> https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1087
> > >  >>
> > >  >> And associated merge request. Did you already tried ?
> > >  >>
> > >  >>
> > > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2007
> > >  
> > >  
> > >  I've changed the logging to
> > >  
> > >  GST_WARNING_OBJECT (pool, "newly allocated buffer %u is not free: %x",
> > >             group->buffer.index, &pool->buffer_state[group-
> > > >buffer.index]);
> > >  
> > >  and this prints
> > >  
> > > gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:
> > > src> 
> > >  newly allocated buffer 0 is not free: 32b48
> > >  v4l2bufferpool 
> > > gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:
> > > src> 
> > >  newly allocated buffer 1 is not free: 32b4c
> > >  v4l2bufferpool 
> > > gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:
> > > src> 
> > >  newly allocated buffer 2 is not free: 32b50
> > >  v4l2bufferpool 
> > > gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:
> > > src> 
> > >  newly allocated buffer 3 is not free: 32b54
> > >  
> > >  That seems... incorrect. A gint is just an int, so %x is correct, right? 
> > >  This has a lot more bits set than are defined in the _GstV4l2BufferState 
> > >  enum.
> > > 
> > 
> > I think the & should not be there.
> > 
> > 
> Ah, of course, my bad. My C is rather rusty :) After fixing that it just
> prints 1, so indeed the BUFFER_STATE_OUTSTANDING bit is set.

Thanks, matches my expectation, now I just need to find the time to fix it.
Fortunately, as said, it fallsthrough when it detect this, and does that right
thing.

Nicolas

> 
>