[Bug 735386] bufferpool: size check on release triggers unwanted buffer free in many situations

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #1 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-08-25 14:45:40 UTC ---
(In reply to comment #0)
> Since commit ec69ad4e8add (buffer: Only set TAG_MEMORY if the memory has been
> replaced) in gstreamer, buffers allocated in buffer pools are freed on release
> in multiple cases where they shouldn't. For example in this pipeline this issue
> happens:

Just a note that this patch do the opposite, it relax the amount of discarded
buffers in order to reduce the performance hit. I have though, left this
"light" size check, as otherwise a freshly allocated buffer may not have the
negotiated size on _acquire(). It was said that where resize is expected,
associated buffer pool should correct the buffer size in reset in order to
preserve the allocation.

The negotiated size isn't supposed to be theoretical. The decoder and converter
(in this example) should have negotiated the right size, otherwise it would
endup with potential short allocation by the pool. We might have introduced a
regression in avdec pool negotation. The size in videopool is obtained from the
video alignment (through gst_video_info_align()). The freshly calculated size
should match avdec expected size. This need further investigation, but is
unlikely a bufferpool bug. Though, I'm starting to think that the video pool
should validate that the provided size matches the calculate size.

-- 
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.