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

Sat Feb 25 03:05:02 EET 2017

[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