[FFmpeg-devel] [PATCH 0/2]: allow hwaccel vda module to manage its buffers lifetime.
quanxunzhen at gmail.com
Thu May 23 08:46:19 CEST 2013
On Thu, May 23, 2013 at 2:29 PM, Hendrik Leppkes <h.leppkes at gmail.com>wrote:
> On Wed, May 22, 2013 at 9:53 PM, Sebastien Zwickert <dilaroga at gmail.com>
> > This patchset fixes memory leaks of vda core video buffers while seeking.
> > It allows hwaccel modules to set a custom callback for freeing av
> > Then vda decoder can flush correctly dropped frames.
> > Thanks to Xidorn Quan who gives me good feebacks about the patch I shared
> > with him in private.
> > Sebastien Zwickert (2):
> > hwaccel: allow to set a user-defined callback for releasing private
> > av buffer.
> > vda: use hwaccel custom callback for releasing private picture
> > context.
> > libavcodec/avcodec.h | 12 ++++++++++++
> > libavcodec/h264.c | 9 ++++++++-
> > libavcodec/mpegvideo.c | 9 ++++++++-
> > libavcodec/vda.h | 12 +++++++++++-
> > libavcodec/vda_h264.c | 18 ++++++++++++++++++
> > 5 files changed, 57 insertions(+), 3 deletions(-)
> > --
> > 18.104.22.168 (Apple Git-31.1)
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> You set frame->data to the same buffer that needs freeing, why not
> simply also set frame->buf appropriately to a AVBufferRef you create,
> so that it gets free'ed with a callback there?
> No extra release buffer callback needed from where i stand.
It is the solution I proposed before. You can find such patchset in this
mailing list as well.
I agree that using frame->buf isn't a bad idea since changes are only in
vda_h264 files, and no callback is required to be added, but I think using
the existing hwaccel priv_buf is a better way because it hides details from
caller, and caller can still use frame->buf for other uses.
A possible case is that some callers may have started using frame->buf
themselves because there is not forbiddance from the original usage, and
setting frame->buf may break them.
GnuPG fingerprint: 6F1E DF9A D250 7505 63E2 345E 7570 8D3F 7C9A 1209
More information about the ffmpeg-devel