[Bug 764319] New: videorate : avoid useless buffer copy un drop-only mode
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Mar 29 16:17:08 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=764319
Bug ID: 764319
Summary: videorate : avoid useless buffer copy un drop-only
mode
Classification: Platform
Product: GStreamer
Version: git master
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-base
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: fred.bertolus at gmail.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created attachment 324956
--> https://bugzilla.gnome.org/attachment.cgi?id=324956&action=edit
Proposed patch
The videorate element has a reference to the last buffer in videorate->prevbuf.
In gst_video_rate_flush_prev, before push the buffer, videorate has to change
the timestamp of the buffer so it make it writable with
gst_buffer_make_writable. Before that, videorate take another reference on the
buffer because one of these ref will be transfered at the push pad and the
other one is for the videorate->prevbuf.
So when gst_buffer_make_writable is call, the ref count of the buffer is at
least 2 and the buffer will be copied. If the memory is not sharable, there
will be a deep copy.
This is the expected behavior but it's not optimal in the drop-only mode.
In drop only mode, videorate will never duplicate a buffer so it don't have to
keep a reference on the previous buffer. In fact, video rate don't keep the
previous buffer : just after calling gst_video_rate_flush_prev, it release its
ref to the buffer :
/* No need to keep the buffer around for longer */
gst_buffer_replace (&videorate->prevbuf, NULL);
However this is done after taking the ref for the push pad and after the
gst_buffer_make_writable, so the copy is already done, and the videorate never
use this copy.
The proposed patch release the useless reference to prevbuf before make the
buffer writable, in the case we are in drop-only mode.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list