DTL
16th May 2026, 08:09
To check with AVS+ mvtools we need AVS+ version of that filter. Also export of the MVs from RIFE may be good to offload some computing from CPU but may be not great for quality:
1. I think optical flow (at least at some implementations) is not based on block motion analysis and compensation (even with overlapping workarounds to fix some block-based artifacts). The neural networks may use different ways of motion/image interpolation. So export of MVs and usage with mvtools-based motion compensation filters (MCompensate or MDegrain) may result in lower (different) quality.
2. The previous years testing of RIFE for denoise (but with +-delta source frames input in AVS+ RIFE filter) shows that (that tested versions) are not significantly better in motion analysis in comparison with MAnalyse onCPU at the complex areas (low contrast and high noise levels) or not better at all.
The request at some repository at github about RIFE development to make a special version of RIFE engine for denoising (several frames analysis and real motion compensation of reference frames to current timestamp using current frame only as objects views sources) received zero replies and was closed after several years as getting no activity. The initial design of RIFE may be mostly for fast motion interpolation for 'smooth playback' and not for precise motion compensation at complex sources for high quality denoise work.
So after someone (Asd-g ?) will make AVS+ version of this filter interface (and also compatible with AVS+ mvtools branch by MVs clip format if it has some difference from VS branch ?) it may be good to test how RIFE-MAnalyse works in performance/quality in comparison with mvtools MAnalyse.
Anyway it will be the 3rd known ME engine for mvtools in addition to onCPU MAnalyse (mvtools internal) and DX12-ME (system hardware MPEG encoder) and now we may have RIFE-based. It may be used as 3 different sources of MVs for averaging processing with new filters like MAverage for possible refining of the MVs quality from 3 or more different sources.
1. I think optical flow (at least at some implementations) is not based on block motion analysis and compensation (even with overlapping workarounds to fix some block-based artifacts). The neural networks may use different ways of motion/image interpolation. So export of MVs and usage with mvtools-based motion compensation filters (MCompensate or MDegrain) may result in lower (different) quality.
2. The previous years testing of RIFE for denoise (but with +-delta source frames input in AVS+ RIFE filter) shows that (that tested versions) are not significantly better in motion analysis in comparison with MAnalyse onCPU at the complex areas (low contrast and high noise levels) or not better at all.
The request at some repository at github about RIFE development to make a special version of RIFE engine for denoising (several frames analysis and real motion compensation of reference frames to current timestamp using current frame only as objects views sources) received zero replies and was closed after several years as getting no activity. The initial design of RIFE may be mostly for fast motion interpolation for 'smooth playback' and not for precise motion compensation at complex sources for high quality denoise work.
So after someone (Asd-g ?) will make AVS+ version of this filter interface (and also compatible with AVS+ mvtools branch by MVs clip format if it has some difference from VS branch ?) it may be good to test how RIFE-MAnalyse works in performance/quality in comparison with mvtools MAnalyse.
Anyway it will be the 3rd known ME engine for mvtools in addition to onCPU MAnalyse (mvtools internal) and DX12-ME (system hardware MPEG encoder) and now we may have RIFE-based. It may be used as 3 different sources of MVs for averaging processing with new filters like MAverage for possible refining of the MVs quality from 3 or more different sources.