On 06/09/17 21:28, wm4 wrote: > On Wed, 6 Sep 2017 21:07:53 +0100 > Mark Thompson <[email protected]> wrote: > >> On 06/09/17 17:27, wm4 wrote: >>> 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(-) >>>>>> >>>> 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. >> >> I'm not really sure what you are suggesting here. Can you explain a bit >> further what you mean? > > Exporting a function like dxva_adjust_hwframes() for every hwaccel, > dispatched in a similar way hwaccel use is. (So I guess something like > avcodec_adjust_hwframes(ctx, pix_fmt).)
Forgive my stupidity here, but I'm still not understanding what you mean at all. When does the user call this function? What does it do? I think of dxva_adjust_hwframes() as modifying the parameters of the created frames context so that it works at all, not as something optional which can meaningfully not be called. - Mark _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
