[FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint

Anton Khirnov anton at khirnov.net
Sun Dec 13 19:22:08 EET 2020


Quoting Michael Niedermayer (2020-12-13 15:03:19)
> On Sun, Dec 13, 2020 at 02:02:33PM +0100, Anton Khirnov wrote:
> > Quoting Paul B Mahol (2020-12-13 13:40:15)
> > > Why? Is it so hard to fix them work with latest API?
> > 
> > It is not exactly obvious, since coded_frame is gone. I suppose you
> > could instantiate an encoder and a decoder to work around that, but it
> > all seems terribly inefficient. Lavfi seems to have some ME code, so
> > perhaps that could be used for mcdeint. Or if not, maybe someone could
> > get motivated to port something from avisynth or vapoursynth. Similarly
> > for uspp, surely one can do a snow-like blur without requiring a whole
> > encoder.
> > 
> > In any case, seems to me like a good opportunity to find out whether
> > anyone cares enough about those filters to keep them alive. I don't
> > think we should keep code that nobody is willing to maintain.
> 
> I might do the minimal changes needed to keep these working when i 
> find the time and if noone else does. Certainly i would not be sad
> if someone else would do it before me ;)
> 
> Also if redesign happens, what looks interresting to me would be to
> be able to export the needed information from encoders.
> Factorizing code from one specific encoder so only it can be used
> is less general but could be done too of course
> 
> if OTOH encoders in general could export their internal buffers for filters
> or debuging that seems more interresting. 

TBH I am very skeptical that this can be done in a clean and
maintainable way. Splitting off individual pieces and making them
reusable is a better approach.

> 
> Are there other issues with these filters which need work besides this
> coded_frame use ?

>From what I can see only the old encoding API use, which should be
straightforward to replace.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list