[10:36:40 CEST] <cone-657> ffmpeg 03Paul B Mahol 07master:9130028d8754: avfilter/vf_lut3d: allocate 3d lut dynamically [10:36:40 CEST] <cone-657> ffmpeg 03Paul B Mahol 07master:a2210f10d37e: avfilter/vf_lut3d: increase max level to upper limit defined by cube format specification [10:36:40 CEST] <cone-657> ffmpeg 03Paul B Mahol 07master:4447aeaac2be: avfilter/vsrc_testsrc: increase max level of haldclutsrc [15:17:00 CEST] <cone-629> ffmpeg 03James Almer 07master:1aa4fc1ec204: avfilter/avf_showfreqs: free input frame after using it [15:33:01 CEST] <cone-629> ffmpeg 03Linjie Fu 07master:e1d993d829a6: lavc/qsvdec: remove unused check_dec_param [16:02:30 CEST] <cehoyos> Is slice threading overlay really negligible? [16:02:41 CEST] <cehoyos> Should it be added for v210? [17:44:01 CEST] <JEEB> durandal_1707: btw did you already have an idea of how a generic opencv filter would work? do they have a filter chain syntax or? [17:44:31 CEST] <JEEB> or was that just a way of you telling the person to eff off without actually telling the person that :P [17:45:25 CEST] <durandal_1707> opencv have functions that operates on images, no nice way to use it like graphs [17:46:34 CEST] <JEEB> but yes, I do agree that all the OpenCV things should share as much common code as possible :P [17:47:52 CEST] <JEEB> just that if someone notes that a "generic" filter should be made, it should be at that point be clear what level of genericness is required [17:48:35 CEST] <durandal_1707> look at current obsolete libopencv filter that use obolete C api [17:48:40 CEST] <JEEB> yes [17:48:42 CEST] <JEEB> I noted that in my reply [17:49:09 CEST] <JEEB> only thing I didn't (yet) specifically note was that yes - opencv filters should share common code base [17:49:19 CEST] <JEEB> mostly because I didn't know what you meant with "generic" [17:49:36 CEST] <JEEB> since generic usually means something like being able to call all the functionality of the underlying thing like with filter chains :P [17:49:46 CEST] <JEEB> which I'm not sure how well OpenCV lets you do it [17:50:23 CEST] <JEEB> I wonder if ubuntu patches the opencv code already [17:51:33 CEST] <durandal_1707> besides those hashing functions stuff should be native filters to ffmpeg, they seems very trivial [17:52:01 CEST] <JEEB> oh huh, no patches in the debian tarball [17:52:03 CEST] <JEEB> color me surprised [17:52:15 CEST] <JEEB> right, they just don't build opencv :D [17:52:46 CEST] <JEEB> https://packages.ubuntu.com/disco/libavfilter7 [17:52:47 CEST] <JEEB> yea [17:53:03 CEST] <JEEB> they did with 4.0 tho [17:53:17 CEST] <cehoyos> I wonder what you mean with "pretty sure"... [17:54:27 CEST] <JEEB> as in, if my memory serves me right but not saying it outright as I did not just run a git grep on the code base [17:55:24 CEST] <cehoyos> There is objective-c code, there should be no c++ code [17:55:38 CEST] <durandal_1707> what? [17:56:04 CEST] <JEEB> pretty sure decklink was c++ but lemme check [17:56:13 CEST] <cehoyos> decklink, yes you are right [17:56:26 CEST] <JEEB> aye [17:57:55 CEST] <JEEB> anyways, I was just mostly trying to bring out the notion that unless someone really starts advocating for OpenCV to maintain C interfaces, telling people wanting to add OpenCV things into FFmpeg that they should use the C interfaces is not productive. [17:58:12 CEST] <cehoyos> no other opinion here... [17:58:42 CEST] <JEEB> and the other thing is what I just asked durandal_1707 regarding what was meant regarding "generic" filter [17:59:08 CEST] <JEEB> so that possibly the guy could be helped to understand what would be required from him [18:27:21 CEST] <cehoyos> jamrial, jkqxz: Please review libavcodec/v4l2_m2m_enc:free v4l2 encode session properly when initialiZzation fails Fix ticket 8285 bug [19:03:41 CEST] <cone-015> ffmpeg 03ManojGuptaBonda 07master:1054752c563c: Add support for VP9 VDPAU hwaccel decode [00:00:00 CEST] --- Sun Oct 27 2019