<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 1 juill. 2022, 15 h 09, Michiel Konstapel <<a href="mailto:michiel@aanmelder.nl">michiel@aanmelder.nl</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 30-06-2022 18:04, Nicolas Dufresne via gstreamer-devel wrote:<br>
><br>
>><br>
>> I'd be curious to see the value or &pool->buffer_state[group->buffer.index] when<br>
>> that warning triggers. I fail to see how we actually endup in that situation. I<br>
>> wonder if there is a relation with:<br>
>><br>
>> <a href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1087" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1087</a><br>
>><br>
>> And associated merge request. Did you already tried ?<br>
>><br>
>> <a href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2007" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2007</a><br>
<br>
<br>
I've changed the logging to<br>
<br>
GST_WARNING_OBJECT (pool, "newly allocated buffer %u is not free: %x",<br>
           group->buffer.index, &pool->buffer_state[group->buffer.index]);<br>
<br>
and this prints<br>
<br>
gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:src> <br>
newly allocated buffer 0 is not free: 32b48<br>
v4l2bufferpool <br>
gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:src> <br>
newly allocated buffer 1 is not free: 32b4c<br>
v4l2bufferpool <br>
gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:src> <br>
newly allocated buffer 2 is not free: 32b50<br>
v4l2bufferpool <br>
gstv4l2bufferpool.c:477:gst_v4l2_buffer_pool_alloc_buffer:<v4l2src0:pool0:src> <br>
newly allocated buffer 3 is not free: 32b54<br>
<br>
That seems... incorrect. A gint is just an int, so %x is correct, right? <br>
This has a lot more bits set than are defined in the _GstV4l2BufferState <br>
enum.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think the & should not be there.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> Looking deeper, it might just a minor bug, and not something as problematic as<br>
> above. I can't say why, but what I believe happens is that after v4l2src pushed<br>
> the buffer, it get release, but it is now invalid:<br>
><br>
><br>
> static void<br>
> gst_v4l2_buffer_pool_release_buffer (GstBufferPool * bpool, GstBuffer * buffer)<br>
> {<br>
>    GstV4l2BufferPool *pool = GST_V4L2_BUFFER_POOL (bpool);<br>
>    GstV4l2MemoryGroup *group;<br>
>    gboolean queued = FALSE;<br>
><br>
>    if (gst_v4l2_is_buffer_valid (buffer, &group)) {<br>
>      gint old_buffer_state =<br>
>          g_atomic_int_and (&pool->buffer_state[group->buffer.index],<br>
>          ~BUFFER_STATE_OUTSTANDING);<br>
>      queued = (old_buffer_state & BUFFER_STATE_QUEUED) != 0;<br>
>      GST_LOG_OBJECT (pool, "mark buffer %u not outstanding",<br>
>          group->buffer.index);<br>
>    }<br>
><br>
>    gst_v4l2_buffer_pool_complete_release_buffer (bpool, buffer, queued);<br>
> }<br>
><br>
> Not "valid buffer" simply means it was modified in a way we could not find back<br>
> which GstV4l2MemoryGroup is was associated with. Without the group, we can't<br>
> know the buffer index, hence we can't clear the outstanding state.<br>
><br>
> Later on, the group will be released to the allocator, which the pool is aware<br>
> as it registered a callback<br>
><br>
>      pool->group_released_handler =<br>
>          g_signal_connect_swapped (pool->vallocator, "group-released",<br>
>          G_CALLBACK (gst_v4l2_buffer_pool_resurrect_buffer), pool);<br>
><br>
><br>
> But the callback only say that "a group" was released, it does not say which<br>
> one. And we have currently no mean to clear the OUTSTANDING flag, which<br>
> eventually leads us to think we just allocated an outstanding buffer. Now that I<br>
> understand how this is possible, it might be possible to fix it. Though I can<br>
> confirm it will have no side effect other then this spammy trace.<br>
><br>
> Nicolas<br>
<br>
That's good to hear! At least then I can move forward with the new <br>
version :-)<br>
Michiel<br>
</blockquote></div></div></div>