[Bug 735386] New: 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

           Summary: bufferpool: size check on release triggers unwanted
                    buffer free in many situations
    Classification: Platform
           Product: GStreamer
           Version: 1.4.0
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: rawoul at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

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