[Ffmpeg-devel-irc] ffmpeg-devel.log.20191026

[burek]

[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