Quoting Mark Thompson (2016-02-16 12:39:59) > On 16/02/16 11:08, wm4 wrote: > > On Mon, 15 Feb 2016 23:24:31 +0000 > > Mark Thompson <[email protected]> wrote: > > >> ... > >> +static void vaapi_buffer_free(void *opaque, uint8_t *data) > >> +{ > >> + AVHWFramesContext *hwfc = opaque; > >> + AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx; > >> + VASurfaceID surface_id; > >> + VAStatus vas; > >> + > >> + surface_id = (VASurfaceID)(uintptr_t)data; > >> + > >> + vas = vaDestroySurfaces(hwctx->display, &surface_id, 1); > >> + if (vas != VA_STATUS_SUCCESS) { > >> + av_log(hwfc, AV_LOG_ERROR, "Failed to create surface %#x: " > >> + "%d (%s).\n", surface_id, vas, vaErrorStr(vas)); > >> + } > >> +} > > > > If this uses the AVVAAPIDeviceContext, doesn't it need to be unreffed > > here? > > Hmm. AVVAAPIDeviceContext is not reference counted (it's the one supplied by > the user when creating the AVHWDeviceContext, which is what we have a > reference > to here). Given that it contains the VADisplay, the user has to manage its > lifetime appropriately - even if we made a copy of it, the user could still > close it. If you wanted to guard against that possibility, adding reference > counting to it would be a top-level API change entirely independent of VAAPI. > > > Or... I'm not sure if it's sane to access the AVHWFramesContext here, > > because if the AVFrame is supposed to keep it alive, the correctness > > depends on the order AVFrame.buf or AVFrame.hw_frames_ctx is unrefed. > > (IMO it shouldn't matter.) > > I think we have to guarantee that the AVHWFramesContext reference (hence > transitively the AVHWDeviceContext) is still present when we deal with buf[0]? > Otherwise, we are just forced to keep another reference somewhere - that ends > up > being buf[1] in the absence of anywhere else to put it.
The buffer free callback is invoked when the pool is being destroyed -- which is the first thing done in the AVHWFramesContext free callback. So it is guaranteed that the AVHWFramesContext (and consequently also the AVHWDeviceContext) is still ok to access at this point. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
