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

[Michael Niedermayer]

On Mon, Dec 14, 2020 at 11:41:58AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-12-14 00:52:06)
> > 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.
> 
> I am not convinced that passing video through an entire encoder is a
> meaningful filtering method, if one wants specific and well-defined
> results. Not to mention it will most likely be incredibly slow.

I think "incredibly" is not accurate but more important
there are 2 rather different cases. (if we limit ourselfs to the wavelet postprocess)

the first is to apply a specific wavelet postprocess filter.
Your comments make sense for this use case

the second is to have a generic filter which averages cyclically shifted encodings
of an image. 

I do not know what people do with this code/filter. So i can just speak about
myself.

Am i interrested in applying uspp to some video ? maybe

do i care about the speed of this ? i dont think so, i do care in the case of other
pp filters though but not uspp

Am i interrested in testing a wide range of encoders with this cyclic shift averaging
or maybe even extend this and try something else entirely than averaging to maybe
get some other cool effect unrelated to postprocess. Yes definitly if i find the time,
its just that maybe i will not find the time ...
Another idea with a encoder + decoder filter would be to introduce intentional
errors after the encoder to create artifacts, if multiple such streams are averaged
this could also generate an interresting effect.
In this sense the principle of running this through a full encoder-decoder chain
certainly would have users. There are people that use such intentional damage for
artistic purposes.

Thanks

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/774e5964/attachment.sig>