[Bug 724481] bufferpool: Doesn't reset buffers when releasing them to the pool

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=724481
  GStreamer | gstreamer (core) | git

--- Comment #8 from Wim Taymans <wim.taymans at gmail.com> 2014-02-26 09:29:08 UTC ---
(In reply to comment #7)
> My solution here is to have reset_buffer() calls gst_buffer_remove_all_memory()
> and re-assemble the buffer & memory(s) in acquire_buffer().

It sounds like a good fallback option. You really don't want to do that all the
time because then the advantage of the bufferpool is no more.

(In reply to comment #6)
> The only gap I see is about memory, the buffer might come back to the pool
> before the memory is released. In this case the buffer is not invalid, it's
> just not yet ready to be reused.

Do you mean that someone is holding a ref to the memory still? If this ref was
non-exclusive, this would mean that the memory can change between mappings (and
that would be desired then). If is was locked for exclusive use, the memory
would not be writable and you can check that before releasing the buffer
(memory) in the pool.

I have another experiment where the reset_buffer would check if the buffer is
still good:

 - reset timestamps + metadata
 - has memory of the right size and type and is writable

If it returns TRUE, which would put the buffer back into the pool for reuse.
If it returns FALSE, it would free the buffer and alloc_buffer would be called
when more buffers are needed.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.