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

[Michael Niedermayer]

On Sun, Dec 13, 2020 at 06:22:08PM +0100, Anton Khirnov wrote:
> 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. 

why ?
one could simply attach the decoded frame bitmap as side data to the
packet. This seems at the surface at least not really require anything
anywhere else. Its just like any other side data, just that it
would be done only when requested by the user.
I imagine this might be little more than a single call in a encoder
with the AVFrame and AVPacket as arguments ...


> Splitting off individual pieces and making them
> reusable is a better approach.

Better for these 2 specific filters yes but that also makes it harder
to change them to a different encoder or even encoder settings.

as the filters are currently, it would be reasonable easy to change them to
a different encoder, experiment around with them and things like that.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201214/a66bf198/attachment.sig>