[01:11:08 CET] <cone-087> ffmpeg 03Michael Niedermayer 07master:76ba09d18245: avcodec/mpeg4videodec: Check the other 3 sprite points for intermediate overflows [01:11:09 CET] <cone-087> ffmpeg 03Michael Niedermayer 07master:e98dfeb27c2a: avcodec/jpeglsdec: check shift for values that cause overflow later [01:11:10 CET] <cone-087> ffmpeg 03Michael Niedermayer 07master:0d85c7bb5a4c: avcodec/ituh263dec: Fix runtime error: left shift of 1342177279 by 1 places cannot be represented in type 'int' [06:52:16 CET] <nevcairiel> BtbN: most hwaccel have that limitation, you have to define a number of frames it has access to, and when the decoder needs some and they are still in use somewhere, bad things happen - its not a cuvid-exclusive problem [08:15:39 CET] <cone-335> ffmpeg 03Rostislav Pehlivanov 07master:22b8ada7b5e0: opus_pvq: improve PVQ search for low Ks [08:15:39 CET] <cone-335> ffmpeg 03Rostislav Pehlivanov 07master:f19442c06992: opus_pvq: remove unneeded assert [08:16:12 CET] <atomnuker> RiCON: this survived 2 hours of fuzzing well outside the normal operating conditions of the search [08:19:19 CET] <atomnuker> this algorithm _will_not_crash_ unless the compiler messed up [08:19:44 CET] <nevcairiel> you said that the first time =p [08:25:45 CET] <atomnuker> yeah well now me and the 100-odd expended watts up stand to prove me right [11:05:09 CET] <cone-335> ffmpeg 03Carl Eugen Hoyos 07master:560f5188c624: lavc/utils: Make second parameter to apply_param_change() const. [11:35:13 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:fa3e49568dc8: avcodec/aic: unbreak decoding of files with slice_width != 16 [11:39:26 CET] <durandal_1707> trac is utter garbage [11:44:55 CET] <wm4> yeah, github's issue tracker works actually pretty well [12:03:45 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:178cd50c47aa: avcodec/scpr: make sure that component value is <= 0x1F for 16 bpc [12:09:54 CET] <Compn> ok time to look at scpr for durandal_1707 :) [14:13:25 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:8696f254444c: avcodec/rv34: Simplify and factor get_slice_offset() code [14:13:26 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:2b8b7921c55a: avcodec/vp3dsp: Fix multiple signed integer overflow: 46341 * 47523 cannot be represented in type 'int' [14:13:27 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:c87ea47481d3: tools/target_dec_fuzzer: Fix misaligned read [14:13:58 CET] <kierank> wm4: anything interesting on ffmpeg-security? [14:14:26 CET] <wm4> kierank: you've read the ML thread? [14:14:50 CET] <kierank> i thought you were added? [14:14:59 CET] <kierank> or is it $realname stuff? [14:15:07 CET] <wm4> still pending [14:15:09 CET] <wm4> also http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207544.html [14:18:34 CET] <ismail> so basically he wants to fix security bugs all by himself? :) [14:22:17 CET] <RiCON> that's not an issue, didn't wm4/kierank just want to review patches? [14:23:07 CET] <wm4> RiCON: yes [14:23:47 CET] <wm4> smells a bit like trying to come up with whatever reason to deny access, but maybe I shouldn't make such presumptions [14:24:39 CET] <Compn> wm4 : very rarely have i ever seen michaelni say what he likes to do in ffmpeg [14:24:54 CET] <Compn> so if he says he likes security, let him enjoy that [14:24:55 CET] <wm4> *shrug* [14:25:03 CET] <wm4> I don't want to take that from him [14:25:12 CET] <wm4> <RiCON> that's not an issue, didn't wm4/kierank just want to review patches? [14:25:15 CET] <Compn> wm4 : if you just want to review bugs so you can fix them in mpv , say that too :P [14:25:16 CET] <wm4> and I've said that before [14:25:43 CET] <Compn> its also possible that this is an income source ... [14:25:49 CET] Action: Compn doesnt want to speculate [14:26:40 CET] <funman> Compn: i can sell you cheap FFmpeg 0days [14:29:15 CET] <Compn> i mean fixing them = bounties [15:30:26 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:0a28c505063f: avcodec/scpr: improve motion vectors checking for out of buffer write [15:34:25 CET] <RiCON> atomnuker: hehe https://i.fsbn.eu/gO9c.txt [15:40:55 CET] <RiCON> y array still has those INT_MAX INT_MIN first two values [15:41:36 CET] <iive> atomnuker: I was wondering, if the bug might be hidden somewhere is ffmpeg defies, like FFABS, MIN, MAX or something like that. [15:42:22 CET] <durandal_1707> michaelni: see ^ [15:49:04 CET] <michaelni> durandal_1707, thx but ATM oss-fuzz finds about 10 new undefined behavior cases each day so iam not short of ones to fix [15:49:59 CET] <ismail> durandal_1707: make oss-fuzz guys report it instead :p [15:51:46 CET] <michaelni> they just recently enabled ubsan ... [15:53:36 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:c583e701bd52: avcodec/fmvc: initialize opcode to 0 [16:42:22 CET] <adeel_> I wish to make contributions to the 'libswscale' module. Could anyone here please point me in a direction? [16:52:03 CET] <jamrial> adeel_: a good start is to check https://ffmpeg.org/developer.html#Contributing [16:56:07 CET] <adeel_> Thanks, James. I am going through Bug tracker. After fixing a small bug, I plan on moving to a qualification task. [16:57:08 CET] <durandal_1707> anybody wants to sponsor atrac9 decoder? [17:01:37 CET] <adeel_> durandal_1707, for what purpose do you wish to use atrac9 decoder for? [17:02:29 CET] <durandal_1707> to play fancy game music [17:36:10 CET] <kierank> BBB: is there any stuff J_Darnley can do to speed up h264? [17:36:16 CET] <kierank> cabac bmi2 perhaps like x264? [17:36:30 CET] <BBB> decoding? [17:37:10 CET] <BBB> kierank: decoding? [17:37:13 CET] <kierank> yes [17:39:14 CET] <BBB> I think avx2 is the most obvious one [17:39:41 CET] <kierank> ok he is working on that already [17:42:07 CET] <BBB> MC at 16x16 blocks can use avx2 [17:42:19 CET] <funman> avx264 [17:42:20 CET] <BBB> and transform_block (2x2 8x8s or 4x4 4x4s) can use avx2 [17:42:37 CET] <BBB> if you use high bitdepth (10bit), you can avx2 a ton more [17:42:42 CET] <BBB> but you already know that probably [17:42:57 CET] <BBB> depending on bitrate or intra frequency, intra pred may be interesting also [17:46:23 CET] <atomnuker> iive: there is no damn bug anymore, its RiCON and his crappy compiler now [17:46:37 CET] <atomnuker> I dare someone to replicate it with another compiler [17:46:49 CET] <kierank> what compiler [17:47:37 CET] <iive> atomnuker: compiler bugs are still bugs, that have to be traced, reported and fixed. [17:47:59 CET] <iive> kierank: msys gcc 6.3.0 [17:48:44 CET] <RiCON> mingw* [17:48:56 CET] <RiCON> but the latest backtrace was using nevcairiel's gcc [17:50:35 CET] <RiCON> i could also try with clang, but i've never done it [17:50:37 CET] <nevcairiel> well then you know where to get older versions of my builds as well to check :) [17:51:18 CET] <iive> that's actually good idea. my distro is still using 5.4.0 [17:54:09 CET] <nevcairiel> kierank: cabac would always be a really good target to get faster, but its probably also one of the hardest thigns to target :) [17:54:52 CET] <nevcairiel> RiCON: which sample are you using for the opus test? [17:55:50 CET] <RiCON> https://i.fsbn.eu/instantcrash.flac [17:56:11 CET] <nevcairiel> thanks, lets see if it also happens [17:58:52 CET] <RiCON> oh, there's a new r25 build, hadn't noticed [17:59:19 CET] <nevcairiel> oh yeah just a minor fix in the crt that made ffmpeg fate fail otherwise [17:59:36 CET] <RiCON> unlikely to be that since it also happens with git mingw-w64 [18:00:19 CET] <nevcairiel> interesting [18:00:25 CET] <nevcairiel> for me it doesnt crash, it just hangs [18:00:38 CET] <nevcairiel> or its *really really* slow =p [18:01:22 CET] <RiCON> you trying on windows or wine? [18:01:28 CET] <nevcairiel> windows [18:02:56 CET] <nevcairiel> seems to infini loop in or around celt_pvq_search [18:03:49 CET] <RiCON> it always instantly segfaults here with 64-bit [18:03:55 CET] <RiCON> 32-bit yeah, some loop [18:03:57 CET] <nevcairiel> i tried 32 [18:04:13 CET] <RiCON> 32-bit used to trigger the assert atomnuker had before [18:04:56 CET] <nevcairiel> i put a breakpoint on that function, and it enters a couple times and then never exits [18:08:15 CET] <nevcairiel> (or at least not in any deterministic time) [18:10:12 CET] <jamrial> i'm also getting segfaults on this encoder with msys2's gcc 6.3.0 package and nevcairiel's gcc 6.2.0 package using a standard wav file here [18:10:23 CET] <jamrial> x86_64, didn't try x86_32 [18:10:41 CET] <RiCON> i'm trying with nev's 5.4 now [18:12:01 CET] <kierank> 4.9.4 works [18:12:26 CET] <jamrial> tried an aac file as source and it didn't crash [18:15:43 CET] <RiCON> same endless loop with nev's 5.4 32-bit, same segfault/backtrace with 64-bit [18:19:58 CET] <RiCON> also tried converting to aac and using that instead, no segfault then [18:31:00 CET] <nevcairiel> it seems to produce really odd values for K sometimes, taking the function for ever to finish by basically iterating through a full integer range [18:32:00 CET] <nevcairiel> i think the function works as expected, but the input is just odd [18:37:45 CET] <RiCON> i can reproduce the segfault with a ton of files randomly taken from my music library [19:05:10 CET] <RiCON> https://i.fsbn.eu/pub/ffopus-segfault-samples/ [19:05:23 CET] <RiCON> all cut to 5s [19:07:19 CET] <atomnuker> nope, not a single crash with any of them here and not even getting a single valgrind warning [19:08:00 CET] <RiCON> :( [19:09:20 CET] <jamrial> atomnuker: can't reproduce it with wine? [19:10:41 CET] <atomnuker> I don't have wine, the most exotic thing I have is an odroid c2 with some old gcc, I'm trying that now [19:14:31 CET] <RiCON> sample 11 doesn't actually crash, mistakenly added [19:16:51 CET] <peloverde> atomnuker: I can reproduce on -m32 builds [19:42:05 CET] <atomnuker> nope, I can't replicate it on an odroid c2 with gcc 6.3.1 [19:42:21 CET] <RiCON> might be a mingw-only bug then [19:42:37 CET] <atomnuker> how was it that you compiled ffmpeg for a 32 bit system on a 64 bit one? [19:43:04 CET] <RiCON> -m32 with multilib or just use a i686 gcc? [19:45:30 CET] <peloverde> I just did --extra-cflags=-m32 --extra-ldflags=-m32 [19:45:37 CET] <peloverde> I think it's a multilib solution [19:54:27 CET] <cone-476> ffmpeg 03Paul B Mahol 07master:e01c32f260fa: avcodec/scpr: remove 4 dead store [19:55:28 CET] <kierank> durandal_1707: you want more than https://support.apple.com/kb/DL480?viewlocale=en_US&locale=en_US [19:56:34 CET] <durandal_1707> kierank: i got it already [19:56:58 CET] <kierank> there is also apple h264 with alpha channel [19:57:01 CET] <kierank> might be interesting to RE [19:57:11 CET] <durandal_1707> ugh [19:57:21 CET] <durandal_1707> there are samples? [19:57:45 CET] <peloverde> atomnuker: What is celt_pvq_search supposed to do when res is 0 or near-zero? [20:03:47 CET] <atomnuker> nothing special, pulse allocation passes to the slow search which iterates over all positions and puts them one at a time [20:08:49 CET] <atomnuker> oh crap [20:08:59 CET] <peloverde> what? [20:15:01 CET] <cone-476> ffmpeg 03Rostislav Pehlivanov 07master:70259737cbad: opus_pvq: prevent division by 0 [20:15:40 CET] <peloverde> yeah, that's what I saw [20:16:27 CET] <peloverde> It's even worse because res*X[i] is inf*0 = NaN [20:18:23 CET] <atomnuker> libopus dealt with that in its pvq search by using a yet another hack and setting the entire input to 0 except at one position it would put a 1 [20:19:38 CET] <atomnuker> right, so RiCON, you know what to do, prove me wrong once again that this fixes nothing [20:20:21 CET] <RiCON> heh [20:40:08 CET] <RiCON> atomnuker: i think that did the trick [20:41:49 CET] <RiCON> i'll check with the full-length samples, just in case [20:48:49 CET] <RiCON> yeah, this bug's fixed, congrats atomnuker [22:04:01 CET] <iive> \o/ [22:24:01 CET] <cone-476> ffmpeg 03Michael Niedermayer 07master:5d81616be332: avcodec/mpegaudiodec_template: Correct return code on id3 tag discarding [22:24:02 CET] <cone-476> ffmpeg 03Michael Niedermayer 07master:513a3494396d: avcodec/vp56: Fix sign typo [22:26:34 CET] <durandal_1707> michaelni: what is needed to apply that security patch? [22:36:52 CET] <michaelni> durandal_1707, what security patch ? the addition of people to the alias one ? [22:37:21 CET] <durandal_1707> yes [22:39:17 CET] <DHE> durandal_1707: just figured it out. I'm also feeding it AAC audio instead of AC3, and AC3 does support in-codec downmixing but AAC does not... [22:39:26 CET] <michaelni> I wanted to give enough time so everyone can comment. It didnt seem to me to be important to apply it within 2 days of being posted [22:39:32 CET] <DHE> oh wrong channel. sorry. [00:00:00 CET] --- Sat Feb 25 2017