On Thu, Mar 16, 2023 at 01:13:54PM -0300, James Almer wrote: > On 3/15/2023 8:34 PM, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer > > --- > > configure | 1 - > > libavfilter/vf_uspp.c | 49 ++++++++++++++++++++++++++++++++++++------- > > 2 files changed, 41 insertions(+), 9 deletions(-) > > > > diff --git a/configure b/configure > > index 03d3c429a5..0370e25577 100755 > > --- a/configure > > +++ b/configure > > @@ -7359,7 +7359,6 @@ enable frame_thread_encoder > > # they are kept disabled for now, but will be removed if > > # nobody updates and re-enables them > > disable mcdeint_filter > > -disable uspp_filter > > enabled asm || { arch=c; disable $ARCH_LIST $ARCH_EXT_LIST; } > > diff --git a/libavfilter/vf_uspp.c b/libavfilter/vf_uspp.c > > index 051de00771..43114e1b50 100644 > > --- a/libavfilter/vf_uspp.c > > +++ b/libavfilter/vf_uspp.c > > @@ -53,6 +53,7 @@ typedef struct USPPContext { > > int outbuf_size; > > uint8_t *outbuf; > > AVCodecContext *avctx_enc[BLOCK*BLOCK]; > > + AVCodecContext *avctx_dec[BLOCK*BLOCK]; > > Wouldn't it be more efficient to try to implement recon_frame support on > more encoders, including snow, and limit this filter to those in patch 2/2? recon_frame support makes sense, but i think we should have generic support first. Then when recon_frame is available use it. First make it work then make it work fast where an optimization is possible > I suggest this mainly seeing how you're creating 256 encoders and now also > 256 decoders, all of which might be threaded since you're not forcing them > to use a single thread, and in patch 3 you'll add slice threading on top of > that. ill add a thread_count = 1 so we dont multiply the threading. if another variant is faster, of course that should be preferred [...] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin