[FFmpeg-devel] [PATCH 0/2]: allow hwaccel vda module to manage its buffers lifetime.

[Xidorn Quan]

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>
> wrote:
> > This patchset fixes memory leaks of vda core video buffers while seeking.
> > It allows hwaccel modules to set a custom callback for freeing av
> buffers.
> > 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(-)
> >
> > --
> > 1.7.9.6 (Apple Git-31.1)
> >
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> You set frame->data[3] 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.

-- 
Xidorn Quan
GnuPG fingerprint: 6F1E DF9A D250 7505 63E2  345E 7570 8D3F 7C9A 1209