[Bug 783086] New: vpxenc: memory usage grows when dropframe-threshold is enabled

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 783086
           Summary: vpxenc:  memory usage grows when dropframe-threshold
                    is enabled
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gkiagia at tolabaki.gr
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 352566
  --> https://bugzilla.gnome.org/attachment.cgi?id=352566&action=edit
vpxenc: discard frames that have been dropped by libvpx

When dropframe-threshold has been set, libvpx may output less frames than the
input ones, which causes some GstVideoCodecFrames to queue up in
GstVideoEncoder's internal frame queue with no chance of ever being all
released. And because the frames keep references to the input buffers, the
input buffer pool keeps allocating new buffers and memory usage grows very
fast. For example the following pipeline's memory usage grows at a rate of
about 1GB per minute!

videotestsrc ! capsfilter
caps=video/x-raw,width=1920,height=1080,framerate=30/1,format=I420 ! vp8enc
target-bitrate=1000000 end-usage=cbr dropframe-threshold=95 ! fakesink

The attached patch attempts to solve the issue.
I'm not very fond of it, though. The patch assumes that an input frame will
either result immediately in exactly 1 output libvpx packet or no packet at
all, but libvpx gives no such guarantees and it's quite unclear what happens
when gst_vpx_enc_process() is being called from gst_vpx_enc_drain(). Can there
be more packets at the end?

It works, though... and solves the issue.

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