On 11/1/19, Christopher Kennedy <ckenn...@ellation.com> wrote: > On Wed, Oct 30, 2019 at 10:57 AM Paul B Mahol <one...@gmail.com> wrote: >> >> On 10/30/19, Christopher Kennedy <ckenn...@ellation.com> wrote: >> > On Wed, Oct 30, 2019 at 10:07 AM Paul B Mahol <one...@gmail.com> wrote: >> >> >> >> On 10/30/19, Christopher Kennedy <ckenn...@ellation.com> wrote: >> >> > On Sat, Oct 26, 2019 at 9:15 AM Paul B Mahol <one...@gmail.com> >> >> > wrote: >> >> >> >> >> >> On 10/26/19, Christopher Kennedy <ckenn...@ellation.com> wrote: >> >> >> > On Sat, Oct 26, 2019 at 8:22 AM Paul B Mahol <one...@gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> On 10/26/19, Christopher Kennedy <ckenn...@ellation.com> wrote: >> >> >> >> > This is a reference/encode comparison filter with two files >> >> >> >> > input >> >> >> >> > like >> >> >> >> > the psnr or vmaf filter. >> >> >> >> > So it is completely different and uses the C++ OpenCV API >> >> >> >> > since >> >> >> >> > this >> >> >> >> > img_hash library is not in the C API. >> >> >> >> > It's unique to what the OCV filter does, and has more research >> >> >> >> > implications from my talk at Demuxed 2019. >> >> >> >> >> >> >> >> I do not see how that is relevant. >> >> >> >> >> >> >> >> There should be generic opencv filter which could do this above >> >> >> >> in >> >> >> >> generic way, and not by adding yet another filter that uses only >> >> >> >> some >> >> >> >> part of opencv. >> >> >> > >> >> >> > Is it really possible to do framesync() operations like dual >> >> >> > input >> >> >> > filters >> >> >> > like psnr/vmaf and also handle input/output rendering of the >> >> >> > frames >> >> >> > too? >> >> >> > This sounds odd to me but I would love to understand how this is >> >> >> > possible. >> >> >> >> >> >> framesync is nothing special, its just used a lot, there are video >> >> >> filters that do not use it and still operate on multiple inputs. >> >> >> >> >> >> > >> >> >> > The C OpenCV API is not recommended so this does the OpenCV part >> >> >> > in C++ which allows it to be fully utilized and supported. So >> >> >> > that >> >> >> > seems >> >> >> > better to me than using the API OpenCV won't really support and >> >> >> > doesn't >> >> >> > allow usage of img_hash (it is NOT in the C API of OpenCV, >> >> >> > impossible >> >> >> > to >> >> >> > use). >> >> >> > >> >> >> > The OpenCV C++ img_hash library is the fastest implementation and >> >> >> > does >> >> >> > work best in OpenCV. So implementing this in C directly isn't a >> >> >> > task >> >> >> > I >> >> >> > believe >> >> >> > is good to do. >> >> >> >> >> >> I do not care how generic opencv filter is done, it can be C++ just >> >> >> fine. >> >> >> >> >> >> > >> >> >> > So should the current OpenCV stuff be merged into this filter, is >> >> >> > that >> >> >> > possible? >> >> >> >> >> >> Current opencv stuff in libavfilter is pretty dead and not >> >> >> maintained >> >> >> at >> >> >> all. >> >> >> So I'm not really fond of adding yet another opencv filter that not >> >> >> gonna be maintained. >> >> > >> >> > Well I would maintain it, but maybe I should instead run a Fork of >> >> > FFmpeg >> >> > with >> >> > C++ and OpenCV properly done. >> >> > >> >> > Yes the current OCV stuff is dead and not supported by OpenCV or >> >> > maintained >> >> > it sounds like. >> >> > >> >> > So if we can't put C++ into FFmpeg (yet we already have with >> >> > decklink >> >> > filters, >> >> > so that is unfair to say). >> >> > >> >> > And we can't switch to use OpenCV C++ yet the C API is dead and not >> >> > supported. >> >> >> >> Who said that? >> >> C++ module filter in libavfilter dealing with latest OpenCV and well >> >> maintained is always welcome. >> > >> > >> > So I should be moving the functionality of the current ocv filter into >> > a >> > C++ file for filters to use like phqm, the current ocv transforms? >> > >> > Is this a good plan, separate the C++ from the vf_ filter as I have >> > done >> > with img_hash.cpp (yet make it a more generic set of OpenCV C++ >> > helper functions to plug into C vf_filters which can be separated by >> > function yet unified in code used from the C++ base code)? >> >> IMHO filter file can be cpp file without issues. And even if not use >> ff_ prefixed functions, > > Okay how about this layout... > > libavfilter/opencv.cpp (all OpenCV code, using C++ API, helper > functions for use by the filters) > > libafilter/vf_libopencv.c current filter, but uses opencv.cpp > functions for OpenCV code > > libavfilter/vf_phqm.c uses OpenCV functions from opencv.cpp
This also should be in libopencv filter. > > Since OpenCV ranges in varying functions we may need, and doing > it as C++ cleanly separately in one place sharing with the C filters seems > nice. > > I agree the duplication of OpenCV in C and C++ APIs seems bad, and > using just the C++ > API is what I see as best according to the OpenCV devs statements > against using the C API. > > > Is that acceptable or is a better layout suggested? > > Thanks, > Christopher > >> >> > >> > Wanting to clarify exactly what is acceptable so I can do it and not >> > waste >> > time / effort doing stuff that isn't right. >> > > >> >> > >> > > _______________________________________________ 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".