Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
Why? Is it so hard to fix them work with latest API? On Sat, Dec 12, 2020 at 5:05 PM Anton Khirnov wrote: > Hi, > as we are approaching the next major bump, vf_mcdeint and vf_uspp > filters are still using deprecated libavcodec APIs. > > Does anyone care about preserving and maintaining them? If so, please > step forward and make them work with non-deprecated APIs. > > -- > Anton Khirnov > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
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. Are there other issues with these filters which need work besides this coded_frame use ? thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
On Sun, Dec 13, 2020 at 3:03 PM Michael Niedermayer wrote: > 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. > > Are there other issues with these filters which need work besides this > coded_frame use ? > > I think that adding extra API to workaround this issues in filters is ugly direction. IMHO filters should not use lavc code at all. For example what uspp needs/steals from lavc to post-process frames? Also what mcdeint uses from snow encoder in lavc to motion interpolate frames? > thx > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
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. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Call for maintainers: vf_uspp, vf_mcdeint
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. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
