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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from George Kiagiadakis <gkiagia at tolabaki.gr> ---
(In reply to Sebastian Dröge (slomo) from comment #4)
> (In reply to George Kiagiadakis from comment #3)
> > No. There must be an equal number of frames on the input and output at the
> > moment.
> 
> That would be a regression then, maybe from moving to the vpxenc base class.
> I implemented that a long time ago

Maybe I misunderstand something, but I fail to see how this would have worked
in the past. GstVideoEncoder allocates a GstVideoCodecFrame internally in its
chain() function. It then passes it down to the handle_frame() vfunc, while at
the same time it stores it in an internal queue (priv->frames). GstVpxEnc
afterwards in handle_frame() uses that GstVideoCodecFrame to call the encode
function and then unrefs it (but without removing it from the queue). Later, in
the gst_vpx_enc_processs() function, GstVideoCodecFrames are retrieved from the
queue, filled with an output buffer and sent to the finish_frame() function,
which properly releases the GstVideoCodecFrame and removes it from the queue as
well.

Now, aiui, this is a 1-to-1 match. There is no way for GstVpxEnc (or any other
encoder) to create a new GstVideoCodecFrame, since
gst_video_encoder_new_frame() is not public API, therefore if you get more
frames on the output than how many you have on the input, you are going to run
out of GstVideoCodecFrames.

I don't fully understand why GstVideoEncoder is designed this way, but it looks
like it would have been simpler to separate the input from the output frame
objects and just release the input as soon as it is not needed, while at the
same time create new objects on demand at the output. This would have avoided
this bug, and possibly others.

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