On Wed, 6 Sep 2017 16:49:11 +0100 Mark Thompson <[email protected]> wrote:
> On 06/09/17 15:33, wm4 wrote: > > On Tue, 5 Sep 2017 23:59:30 +0100 > > Mark Thompson <[email protected]> wrote: > > > >> --- > >> Saves the VA config, the frame pool, and the VA context (in that order). > >> The device reference is held so that freeing the persistent data is > >> possible (the transient context is already gone when it happens). > >> > >> > >> libavcodec/vaapi_decode.c | 241 > >> +++++++++++++++++++++++++++++++++------------- > >> libavcodec/vaapi_decode.h | 18 ++++ > >> 2 files changed, 192 insertions(+), 67 deletions(-) > >> > > > > Doesn't this also discard the frames context if the decoder context > > changes? That seems unnecessary. Can't it just reuse the frames context > > whenever the frames parameters are the same? > > What case do you want to cover here? The VA config change is rare > (codec/profile change in the stream, codec isn't actually supported because > of other lavc stuff but it could work), and is large enough that the user > might want to apply different settings in init_hw_frames. VA context depends > on frames so must always be remade if the frames change. It depends on how the config change is done. There were cases in the past where libavcodec called get_format() on every IDR or so. If it can check the cached decoder fine-grained "enough", fine. It still seems unnecessary to conflate the decoder and the frames. Also what about use cases such as the user wanting to use an existing frames context on a new decoder context? (Not my use case, but IMO something that shows that the current API might be too inflexible.) > For normal cases: > * Flush with the same extradata (e.g. seeking) reuses everything. > * Resolution change reuses the VA config and makes new frames and VA context. > > > Also, it would be possible to implement frames context reuse without > > having to change each hwaccel implementation. > > Maybe? It would need some amount of change around management of > hw_device_ctx / user-set hw_frames_ctx / legacy hwaccel_context cases, since > all of the choices between those are currently made by the individual > hwaccels. Not really. The invariant is that you _can_ provide an existing frames context to a hwaccel, and that frames context could be simply cached by the shared code. One requirement is that the shared code could get the needed frame parameter in advance. That would still require new per-hwaccel code, but only to the extent of what dxva_adjust_hwframes() (as well as current API users) need to know. In particular, this is independent from creating an actual decoder. So why can't we just export something like dxva_adjust_hwframes()? The only problem is that this would need a new entry point, as the user somehow select the AVHWaccel implicitly with the get_format() return. > > Can the API user manually stop a reuse in certain cases? > Yes, by changing hwaccel_flags (can be changed inside get_format(), as > documented in avcodec.h). OK _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
