GNOME Bugzilla – Bug 735386
bufferpool: size check on release triggers unwanted buffer free in many situations
Last modified: 2014-12-16 03:20:34 UTC
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: gst-launch-1.0 --gst-debug='bufferpool:6' souphttpsrc location= http://absolut.zogzog.org/share/samples/avi/big_buck_bunny_720p_surround.avi ! avidemux ! avdec_mpeg4 ! videoconvert ! 'video/x-raw, format=NV12' ! fakesink The problem is that the size set on the config parameter for video frame buffer pools is usually set to the *theoritical* size of the frame for the video format, ie without taking the stride into account. I also see this issue on my decoder plugin elements, since I have no way of knowing in advance the stride of each video frame. So in my case the size is actually useless. IMHO it is actually generally useless when dealing with video frames when they have the video meta attached to them. Unfortunately the check added on size on buffer release hurts performance in my case.
(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.
*** This bug has been marked as a duplicate of bug 741420 ***