[Bug 744303] bufferpool: Don't free GstBuffer if memory isn't writable

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=744303

--- Comment #4 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Olivier Crête from comment #2)
> @nicolas: This is how sub-buffering worked in 0.10. I guess Wim had a good
> reason to remove it. 

I'll ask.

> 
> I understand the current design is that the GstBuffer object just isn't
> poolable in that case, making the buffer pools pretty much useless for a lot
> of cases. That said, the GstMemory is just a small structure coming out of
> the slice allocator, so it shouldn't matter much. And frankly, I'd like to
> see some number about the usefulness of the pooling behavior of
> GstBufferPool in 1.x.

We can do measurement of course. The point here is to realign the design.
Unlike what you seem to think, I doubt there is a way to remove buffers pools
that would not break the API. Pooling is broken for many uses cases, and I
think we have an opportunity to fix it. Pooling in most allocators makes very
little sense, since the allocator does not know if allocation of size A still
have a meaning compare to an allocation of size B. Pooling in the allocator is
a limited option, and only apply to allocator with
GST_ALLOCATOR_FLAG_CUSTOM_ALLOC flag in real life.

> 
> Parenting one buffer to another means that even if only one GstMemory of a
> GstBuffer is still in use, then all GstMemories in it would be stuck.

It won't be stuck for a very long time. Also, if you look at payloaders and
GstAdapter, they append into a child, and leave the parent untouched. This is
the most common case, and parenting is a good fit.

Kevin, I don't really get your arguments though. V4L2 and VPU are excellent fit
for Allocator side pooling. As a proof, the generic v4l2 elements implement
that. It does not change anything to the fact I think we should be able to pool
GstBuffer as per design, and reduce as much as possible the amount of
round-trip to the OS in order to re-allocate for.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.