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(-) >>>> >>> >>> 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.)
I think should be regarded as opportunistic, and may make a new one at any time with no warning. If there are hard requirements about the frames then hw_frames_ctx should be used instead. >> 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? >>> 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
