On Wed, 6 Sep 2017 21:07:53 +0100 Mark Thompson <s...@jkqxz.net> wrote:
> On 06/09/17 17:27, wm4 wrote: > > On Wed, 6 Sep 2017 16:49:11 +0100 > > Mark Thompson <s...@jkqxz.net> wrote: > > > >> On 06/09/17 15:33, wm4 wrote: > >>> On Tue, 5 Sep 2017 23:59:30 +0100 > >>> Mark Thompson <s...@jkqxz.net> 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. That's fine, I'm just looking for a way you can do this without hardcoding things specific to a decoding API/wrapper, like what surface format to use and how to pad surfaces. > >> 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).) _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
