[00:58:43 CEST] <atomnuker> is there a short and easy way of swapping the high 64 bits of each lane in a 256bit reg? [00:59:16 CEST] <kierank> pshubf? [00:59:26 CEST] <atomnuker> it does crosslane? [00:59:36 CEST] <kierank> ah crosslane i dunno [01:00:43 CEST] <atomnuker> so 0-64 and 128-192 stay as-is but 64-128 and 192-256 get swapped [01:01:32 CEST] <atomnuker> I got 4 registers I need to haddps and 2 of them are in reverse of what they need to be [01:02:57 CEST] <atomnuker> (and I'd rather avoid doing 4 haddps on each register when 2 gets them almost right) [01:15:34 CEST] <iive> atomnuker: check "vpermps", it's avx2 [01:16:24 CEST] <iive> 3 latency and 1 throughput [01:17:40 CEST] <atomnuker> doesn't seem too bad [01:17:51 CEST] <JEEB> hmm, where was the service_name stuff defined for MPEG-TS? [01:17:52 CEST] <atomnuker> my code's already using some avx2 unnecessarily [01:24:49 CEST] <iive> atomnuker: what are you working on? [01:27:29 CEST] <atomnuker> mdct15 postrotate and (un)folding [01:27:51 CEST] <atomnuker> though really I just want to see how slow vgather is [01:29:20 CEST] <iive> :D [02:39:58 CEST] <kierank> atomnuker: any idea why you do this in vc2enc_dwt? [02:39:59 CEST] <kierank> s->buffer = av_malloc(2*p_width*p_height*sizeof(dwtcoef)); [02:40:02 CEST] <kierank> 2*? [02:44:12 CEST] <atomnuker> not a clue, can't remember [02:47:05 CEST] <kierank> looks very unnecessary [02:49:56 CEST] <atomnuker> yep, it does [03:17:59 CEST] <atomnuker> huh, haddps interleaved the coefficients but the chinese graphs I look on google images every time I need to visualize say it doesn't [03:18:46 CEST] <atomnuker> how come these chinese graphs (http://www.officedaytime.com/tips/simdimg/punpckhwd.png) are the only good graphs anyone has made [03:37:18 CEST] <J_Darnley> I remember some like that from the intel manual but I think many of the new instructions miss them. [04:37:51 CEST] <atomnuker> vpermps is awesome, it does cross lane stuff [04:49:48 CEST] <cone-829> ffmpeg 03Kaustubh Raste 07master:36ea41de3736: libavcodec/mips: Improve avc dequant-idct luma dc msa function [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:08c073434e25: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:ffcc82219cef: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:2c630d159ffe: avcodec/takdec: Fix integer overflow in decode_subframe() [04:49:48 CEST] <cone-829> ffmpeg 03Michael Niedermayer 07master:c0220c768c7f: avcodec/diracdec: Fix integer overflow in divide3() [06:51:03 CEST] <atomnuker> things were going so great, I wrote some nice asm and it barely took me a few hours and now it turns out that I can't overwrite my output [06:52:57 CEST] <atomnuker> and all this could have been avoided if the voip megasperglords fixed their crap to work with a non-integer amount of frames per second [06:54:07 CEST] <atomnuker> I think you need to do some effort to even make your crap _not_ work with a non-interger amount of frames per second [08:00:30 CEST] <atomnuker> ah well, bodged it to save and restore the area +-mmsize around the output [08:03:57 CEST] <atomnuker> holy fucking shit, 2 vgathers of 4 doubles cost me around 2700 decicycles [08:04:33 CEST] <atomnuker> without them the function is 1200 decicycles [09:50:29 CEST] <durandal_1707> atomnuker: whats missing in your audio denoiser filter? [09:53:02 CEST] <atomnuker> the actual business part (detection and subtraction) [09:53:25 CEST] <atomnuker> plus jmspeex posted a very good noise reduction filter based on neural nets [09:54:27 CEST] <atomnuker> https://jmvalin.ca/misc_stuff/noisy.wav vs https://jmvalin.ca/misc_stuff/denoised1.wav [09:56:05 CEST] <atomnuker> he's training it with various types of noises atm so might be a better idea to borrow it instead [09:56:48 CEST] <Blubberbub_> atomnuker, is there a text about how its done? [09:57:13 CEST] <atomnuker> nope, its neural nets so its magic [09:58:22 CEST] <Blubberbub_> but what are the inputs to the network? layout of the network? how is it trained? [09:59:40 CEST] <atomnuker> not a clue, ask jmspeex in #opus [10:02:47 CEST] <Gramner> >(@atomnuker) is there a short and easy way of swapping the high 64 bits of each lane in a 256bit reg? [10:02:53 CEST] <Gramner> vpermq for int, vpermpd for float [10:03:28 CEST] <Gramner> takes an imm8, so no need for .rodata shuffle masks [10:05:34 CEST] <atomnuker> Gramner: why can I only multiply by 8 in e.g. [inq + offsetq*8] ? [10:05:51 CEST] <atomnuker> 16 and above don't wok [10:05:56 CEST] <atomnuker> *work [10:06:33 CEST] <Gramner> the multiplier is really a shift, and it's encoded in 2 bits so there's only 4 possible values. 1, 2, 4, and 8 [10:07:03 CEST] <atomnuker> so its not a preprocessor thing? that explains a few things [10:07:21 CEST] <Gramner> no, it's an integral part of x86 addressing [10:08:19 CEST] <atomnuker> (I thought the preprocessor handled them an expected some speedup if I got rid of them, but I got a slight slowdown instead) [10:12:11 CEST] <Gramner> iirc simple addresses (like [reg]) results in shorter latency on some cpu:s, but if some address calculation needs to be made it's generally best to let the addressing unit deal with it as much as possible [10:21:03 CEST] <atomnuker> btw Gramner, could you review the pyramid vector quantization SIMD on the ML? [10:39:45 CEST] <durandal_1707> atomnuker: wheres rhat code? [10:42:02 CEST] <atomnuker> durandal_1707: the noise reduction one? its still being trained, that was just a wip with limited training [11:40:18 CEST] <durandal_1707> atomnuker: is there code for training? [11:42:30 CEST] <atomnuker> tensorflow, though if you ask him he'll probably give you the script he's using [11:43:04 CEST] <atomnuker> though he's training on a 32 core machine with a gpu with water cooling [11:47:36 CEST] <durandal_1707> atomnuker: and how are such networks appllied? [11:48:00 CEST] <durandal_1707> also it requires big files, no? [11:54:01 CEST] <atomnuker> durandal_1707: https://github.com/xiph/opus/blob/e6704abcad486c9966e79fda3663074a36870c0f/s... <- data [11:54:53 CEST] <atomnuker> https://github.com/xiph/opus/blob/e6704abcad486c9966e79fda3663074a36870c0f/s... <- usage [13:05:38 CEST] <ZeroWalker> is it possible to get the length of the audio/video when encoding/capturing to a file. As i need to sync the audio as it will be shorter than the video over time, so i need ot add silence [13:16:42 CEST] <kierank> Use timestamps for that [13:33:27 CEST] <ZeroWalker> you mean the pts? [13:33:42 CEST] <ZeroWalker> that would work, quite obviously -_-, thanks [16:02:51 CEST] <durandal_1707> neural networks are overrated [17:44:42 CEST] <ElementalBlack> How does slice threading work? Are multiple threads opened for each row of pixels in an image or something? [17:45:47 CEST] <ubitux> in libavfilter? [17:45:58 CEST] <ElementalBlack> yeah [17:46:28 CEST] <ubitux> you define how much slices you can have [17:46:34 CEST] <ubitux> in the filter itself [17:46:47 CEST] <ubitux> it's generally something like the number of lines [17:46:59 CEST] <ubitux> or if you're working with 8-pix height block it's height/8 [17:47:13 CEST] <ubitux> so that's your maximum of threads [17:47:35 CEST] <ubitux> then you pick as much threads as the user specified (or automatically picked by the number of core) [17:47:40 CEST] <ubitux> and clamp it to that value [17:48:16 CEST] <ubitux> in your thread function process, you then defined the range according to the number of threads and the thread id [17:48:24 CEST] <ElementalBlack> I think nlmeans supports slices, but I was only seeing like 2% CPU usage last I checked. [17:48:29 CEST] <ubitux> in nlmeans_slice, this is jobnr / nb_jobs [17:49:28 CEST] <gh0st__> In vp9 for example, num of threads = num of tiles there are in a frame. [17:50:55 CEST] <gh0st__> So each tile is decoded in a separate thread. [17:51:21 CEST] <ubitux> ffmpeg -lavfi testsrc2=s=hd1080,nlmeans -f null - [17:51:35 CEST] <ubitux> i have about 50% cpu use on each core with this currently [17:52:01 CEST] <ubitux> maybe hiting a memory bus factor or something [17:52:59 CEST] <ElementalBlack> ubitux: lemme test [18:08:53 CEST] <ElementalBlack> seems better, 80% usage. .4fps for 1080p, .1fps for a 4k input [18:10:26 CEST] <ElementalBlack> do those fps's seem low, or is that just what it is [19:02:09 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07master:bf8ab72ae95b: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [19:19:36 CEST] <ubitux> ElementalBlack: nlmeans is not meant for real time [19:19:44 CEST] <ubitux> that said, yeah it should probably be optimized [19:20:00 CEST] <ubitux> i'm still looking into making the map created with simd [19:20:09 CEST] <ubitux> not sure what else can be done to improve speed [19:21:05 CEST] <ElementalBlack> ubitux: do you know which function is eating up comp time? [19:21:53 CEST] <ubitux> "nlmeans_slice()" :p [19:24:25 CEST] <ubitux> basically 85% in nlmeans_slice(), 15% in nlmeans_plane() [19:24:41 CEST] <ElementalBlack> lol [19:24:47 CEST] <ubitux> making the integral faster will decrease that 15% [19:25:00 CEST] <ElementalBlack> ubitux: I still don't see 100% usage on 8 cores [19:25:08 CEST] <ElementalBlack> ubitux: 70% for 4k [19:25:17 CEST] <ubitux> yeah, same here [19:25:33 CEST] <ElementalBlack> is 100% possible? [19:26:18 CEST] <ubitux> who knows [19:26:32 CEST] <ElementalBlack> ubitux: i've heard positive results on GPU nlmeans. working on that now [19:26:52 CEST] <ubitux> sure, good luck :) [19:27:05 CEST] <ubitux> not sure if the integral method is appropriate for a gpu though [19:27:17 CEST] <ubitux> you may attempt a different approach [19:28:10 CEST] <ElementalBlack> ubitux: This is currently my reference kernel https://github.com/opencv/opencv/blob/master/modules/photo/src/opencl/nlmean... [19:37:17 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:aadfec7d6ca9: avcodec/pixlet: Simplify nbits computation [19:37:18 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:d40bb6f5e934: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH() [19:37:19 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:0d2b67d17c9b: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [19:37:20 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:6de5ec8ef818: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [19:37:21 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:38d9a782a585: avcodec/takdec: Fix integer overflow in decode_subframe() [19:37:22 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:934878f2a62f: avcodec/diracdec: Fix integer overflow in divide3() [19:37:23 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:4f714352488d: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [19:37:24 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.3:9079c70d2095: Changelog:update [19:48:43 CEST] <durandal_1707> what filter you find missing in lavfi? [19:50:50 CEST] <ubitux> "good ones"© [19:50:59 CEST] <ubitux> ’ improve existing [19:53:25 CEST] <durandal_1707> which ones? [19:56:07 CEST] <ElementalBlack> what is this 'const int w = i ? s->chroma_w : inlink->w;' in 'for (i = 0; i < s->nb_planes; i++)' actually doing? does that just mean that the first plane is a luma plane? [19:57:53 CEST] <ubitux> durandal_1707: fieldmatch? :° [19:58:07 CEST] <ubitux> ElementalBlack: yes [19:59:15 CEST] <durandal_1707> ubitux: whats wrong with it? [19:59:39 CEST] <ubitux> sync with upstream [19:59:49 CEST] <ubitux> more extensive tests [20:00:17 CEST] <ubitux> pretty sure something needs to be done about deshake or any related filter [20:00:29 CEST] <ubitux> i always forget if we have a decent slowmo filter [20:00:51 CEST] <ubitux> we need to port the remaining features from the mpeg dec to codeview [20:01:10 CEST] <ubitux> (and probably add more features such as the ones used in vp9 and hevc) [20:01:14 CEST] <ubitux> (’ segmentation) [20:21:13 CEST] <jamrial> ubitux: https://pastebin.com/GNU1FFUU after adding a bunch of noinline attribute to functions [20:21:38 CEST] <ubitux> diff? [20:22:31 CEST] <jamrial> ubitux: https://pastebin.com/gENtTgY4 [20:23:29 CEST] <jamrial> writing simd for ssd_integral_image would help quite a bit [20:26:25 CEST] <ubitux> funny [20:26:50 CEST] <ubitux> well, i still plan to write the simd for aarch64 [20:27:03 CEST] <ubitux> i think i have a branch for that [20:27:34 CEST] <ubitux> i'd say it's 2-3h of work max [20:28:46 CEST] <ubitux> i'll have time in 2 weeks [20:29:54 CEST] <ElementalBlack> should be interesting to compare that to a GPU one [20:32:04 CEST] <ElementalBlack> might be a #git question, but is there a way to update my master branch and merge the changes to my local branch before commiting? [20:45:00 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07n3.3.3:HEAD: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [20:52:31 CEST] <ubitux> damn, where is wm4, i have a surprise for him [20:53:50 CEST] <JEEB> he's enjoying a long-needed vacation [20:54:00 CEST] <ubitux> sounds reasonable [20:54:31 CEST] <ubitux> anyway, i improved the subrip engine [20:54:40 CEST] <ubitux> it should be much less shitty for end users [21:18:43 CEST] <DHE> ElementalBlack: if you have your own branch, update the master branch first, switch to your custom branch and run "git rebase master" [22:39:51 CEST] <atomnuker> more opus simd on the ML, gives around 8% decoder speedup on CBR constant frame-size [22:40:19 CEST] <atomnuker> jamrial: could you take a look at it? and the pvq SIMD patch iive posted? [22:43:03 CEST] <iive> that chunk @@ -253,13 +283,14 @@, seems to have some cosmetics embedded. [22:44:45 CEST] <atomnuker> no idea what those numbers mean [22:44:53 CEST] <atomnuker> "s->imdct_half = imdct15_half;"? [22:45:17 CEST] <atomnuker> that's because postrotate was longer than any of the rest so I had to realign them otherwise it would look ugly [22:48:37 CEST] <iive> oh, ok. [22:53:16 CEST] <ubitux> durandal_1707: please submit new filters with a doc, or at least a description in the commit message for the review if it's a WIP/RFC [22:53:52 CEST] <durandal_1707> never [22:54:18 CEST] <ubitux> well, if you don't want reviews just push them without sending them to the ml [22:54:45 CEST] <durandal_1707> nooo, im trolling [22:56:33 CEST] <iive> atomnuker: so, is the LUT__LOAD_4D faster than the vgather ? [22:58:37 CEST] <atomnuker> yep [22:58:50 CEST] <iive> another win for Intel /sarcasm [22:59:10 CEST] <atomnuker> it was around 2x faster than what I had before [22:59:10 CEST] <iive> atomnuker: btw, the macro has small issue, it doesn't use %2 anywhere. it works because you use %1 and %2 as same register. [22:59:21 CEST] <atomnuker> yeah [22:59:27 CEST] <atomnuker> I can't do anything about it though [22:59:45 CEST] <iive> yes you can :D [22:59:49 CEST] <atomnuker> the arguments are replaced by the preprocessor before they're replaced by the macro [23:00:01 CEST] <atomnuker> so I can't mix e.g. %2 and x%2 [23:00:17 CEST] <atomnuker> since that'll become ymm2 and xymm2 [23:00:33 CEST] <iive> xmm%1 would give you the xmm variant of the register [23:00:45 CEST] <atomnuker> yeah, but then I'd have to pass numbers [23:00:52 CEST] <iive> NO [23:00:53 CEST] <atomnuker> I'll do it for v2 [23:01:20 CEST] <atomnuker> I'll have to pass numbers [23:01:25 CEST] <iive> x86inc has them as redefines of xmmymm0 [23:01:38 CEST] <atomnuker> ? [23:01:40 CEST] <iive> aka xmmymm0 -> xmm0 [23:02:08 CEST] <atomnuker> huh, wasn't aware of that [23:02:11 CEST] <iive> xmm%1 when %1==ymm => xmmymm0 => xmm0 [23:03:11 CEST] <iive> it's very clever and neat :D [23:05:28 CEST] <Gramner> atomnuker: what gather sequence did you compare LUT_LOAD_4D to? movdqa + pcmpeqd + vgatherdps? [23:08:05 CEST] <Gramner> err, vgatherdpd I mean [23:09:34 CEST] <atomnuker> pcmpeq for the mask, then a movu [lut_offset] for the address, then vgatherqpd m1, [inq + m4*8], m3 for the loads [23:09:51 CEST] <atomnuker> all this 2x for the negative and positive offset parts [23:10:18 CEST] <Gramner> on what cpu? [23:10:35 CEST] <atomnuker> i7-6700HQ [23:11:26 CEST] <Gramner> qpd? aren't the lut values 32-bit? [23:12:35 CEST] <atomnuker> they were 64 bit ones since I wanted to use bytes for offset_p/n and wanted to look up the indices the same way I did exp values [23:12:48 CEST] <atomnuker> but I ended up just multiplying everything by 8 [23:13:10 CEST] <atomnuker> and that saved me having a separate counter register [23:13:37 CEST] <atomnuker> and then I could just multiply the offsets by 4 to switch to having 32 bit values [23:14:07 CEST] <atomnuker> I'll try to measure it again now, its just a few instructions [23:15:23 CEST] <Gramner> gathers seem to have a high additional latency penalty over individual loads. I guess they're mostly only useful with zmm regs in combination with scatters in a load-modify-store scenario for now [23:15:52 CEST] <durandal_1707> so there is simd for lut ? [23:17:28 CEST] <Gramner> you can do some crazy lut simd stuff with avx-512. even with conflict detection for overlapping indices, but that part is insanely slow on SKL-X unfortunately [23:21:26 CEST] <Gramner> vpconflict* instructions are µcoded on SKL-X and are like 30/10 (compared to 3/1 on KNL) [23:21:49 CEST] <Gramner> which eats up pretty much all the performance gain [23:22:02 CEST] <Gramner> 30/20 even [23:22:58 CEST] <Gramner> I'm guessing that will be resolved in the next µarch [23:23:07 CEST] <atomnuker> Gramner: did another test, vgather 1000 to 1700 decicycles slower on 20ms frames [23:23:58 CEST] <atomnuker> what do you need vpconflict for? [23:24:26 CEST] <Gramner> if it's that bad on skylake it's gong to be atrocious on haswell and zen [23:25:26 CEST] <atomnuker> do you know if any microcode updates speed up any complex instructions? [23:25:27 CEST] <Gramner> if you have overlapping indices. say you want to load 8 values, add some other value to them, and store write them back [23:25:48 CEST] <Gramner> that will break if you just do gather+add+store [23:25:58 CEST] <Gramner> if two values have the same address [23:26:51 CEST] <Gramner> conflict detection allows you to detect if two indicies are identical and deal with it [23:27:24 CEST] <atomnuker> I can't see how that's useful, you're better of redoing your luts and making sure you have no identical indices [23:28:09 CEST] <atomnuker> (and I don't know of any luts I've done that have had repeating indices) [23:28:14 CEST] <Gramner> if your indices are calculated dynamically you don't know if they're going to overlap or not [23:29:10 CEST] <atomnuker> that's going to be very slow anyway, can't do much about it [23:29:15 CEST] <iive> how is the store done? [23:31:07 CEST] <Gramner> https://git.videolan.org/?p=x264.git;a=blob;f=common/x86/mc-a2.asm;h=e93cfcc... real-world use-case (corresponding C: https://git.videolan.org/?p=x264.git;a=blob;f=common/mc.c;h=65af5b9e25ad2529... ) [23:32:07 CEST] <Gramner> it's just not that beneficial over doing that part in scalar at the moment due to vpconflictd being slow as hell. it's like a third of the runtime of the entire function in that instruction [23:36:23 CEST] <Gramner> microcode updates tends to be about bug fixes [23:37:03 CEST] <iive> avx2 doesn't have scatter and "conflict" opcodes [23:37:13 CEST] <Gramner> no, avx2 doesn't [23:38:13 CEST] <iive> also, i don't understand what is the problem if 2 indexes are the same, if all you do is add same constant to all of them. (if it was different then yeh) [23:38:48 CEST] <durandal_1707> what about undocumented instructions ? [23:38:52 CEST] <iive> i mean, the result might be written twice, but with the same value. [23:39:43 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:e5d9f0c3cd05: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output [23:39:44 CEST] <cone-843> ffmpeg 03Anton Mitrofanov 07release/3.2:312f96053ae5: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4 [23:39:45 CEST] <cone-843> ffmpeg 03Anton Mitrofanov 07release/3.2:b36c97a0aea7: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264 [23:39:46 CEST] <cone-843> ffmpeg 03Anton Mitrofanov 07release/3.2:f7addaece89b: avcodec/h264: Fix mix of lossless and lossy MBs decoding [23:39:47 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:66735ddd7220: avcodec/htmlsubtitles: Replace very slow redundant sscanf() calls by cleaner and faster code [23:39:48 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:27ad04e128cb: avcodec/aacdec_fixed: Check s for being too small [23:39:49 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:9125bbb3e58d: avcodec/wavpack: Fix undefined integer negation [23:39:50 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:b97e0e98b4e5: avcodec/lpc: signed integer overflow in compute_lpc_coefs() (aacdec_fixed) [23:39:51 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:dd4fd80fe68b: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation [23:39:52 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:80dc5b497e5d: avcodec/hevc_filter: Fix invalid shift [23:39:53 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6d951be24de8: avcodec/cfhd: Fix undefined shift [23:39:54 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:9bca2f698bbc: avcodec/cfhd: Check bpc before setting bpc in context [23:39:55 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:220ee7e58369: avcodec/tiff: Update pointer only when the result is used [23:39:56 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:00a6211b458a: avcodec/takdec: Fix integer overflow [23:39:57 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a7c0243e2f61: avcodec/wavpack: Fix integer overflow [23:39:58 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a2bde1363c93: avcodec/mpeg4videodec: Fix GMC with videos of dimension 1 [23:39:59 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:fc24783c6d19: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo() [23:40:00 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:5bb861d45b86: avcodec/apedec: Fix integer overflow [23:40:01 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:bbf911b660b9: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [23:40:02 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:20ce366feefc: avcodec/vb: Check vertical GMC component before multiply [23:40:03 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:d986096963fc: avcodec/cfhd: Fix invalid left shift of negative value [23:40:04 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:2b85709bee16: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets [23:40:05 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:aaecd2ef68d9: avcodec/h264_slice: Fix signed integer overflow [23:40:06 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a954b531f63b: avcodec/wavpack: Fix invalid shift [23:40:07 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:a76db7176ab8: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise() [23:40:08 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6405c66a5142: avcodec/ylc: Fix vlc of 31 bits [23:40:09 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:1268784d9f6c: avcodec/aacps (fixed point): Fix multiple signed integer overflows [23:40:10 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:fa427bdb5999: avcodec/mjpegdec: Clip DC also on the negative side. [23:40:11 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:aa01a35dd507: avcodec/magicyuv: Check that vlc len is not too large [23:40:12 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:3abe6554c1eb: avcodec/aacdec_template: Fix undefined integer overflow in apply_tns() [23:40:13 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:13c0467c4923: avcodec/ffv1dec_template: Fix signed integer overflow [23:40:14 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:97e35bc40be7: avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later [23:40:15 CEST] <cone-843> ffmpeg 03Vodyannikov Aleksandr 07release/3.2:539dc1746a8b: avcodec/cfhd: Fix decoding regression due to height check [23:40:16 CEST] <cone-843> ffmpeg 03Brice Waegeneire 07release/3.2:79f6269fd0ac: doc/filters: typo in frei0r [23:40:17 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:c368f0756536: avcodec/dirac_vlc: Fix undefined shift [23:40:18 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:7f638d56bde9: avcodec/aacdec_fixed: fix: left shift of negative value -1 [23:40:19 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:b905d2948a0e: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20() [23:40:20 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:00b0d595eb4e: avcodec/ylc: Fix shift overflow [23:40:21 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6cc7777d4bcb: avformat/oggparsecelt: Do not re-allocate os->private [23:40:22 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:efb649467cb8: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [23:40:23 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:6a10b962e305: avcodec/dnxhddec: Move mb height check out of non hr branch [23:40:24 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:8c7b477b97fb: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH() [23:40:25 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:f2a6f41dd7b9: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [23:40:26 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:b375cc8bb74a: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [23:40:27 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:bae812711ad2: avcodec/takdec: Fix integer overflow in decode_subframe() [23:40:28 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:7827b06d7731: avcodec/diracdec: Fix integer overflow in divide3() [23:40:29 CEST] <cone-843> ffmpeg 03Michael Niedermayer 07release/3.2:e8893979249a: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [23:42:23 CEST] <Gramner> if you add something to the same destination multile times you generally want to have them be additative and not arbitrarily just add one of the values and overwrite the rest [23:43:45 CEST] <Gramner> e.g. a+=b; a+=c; is not equivalent to tmp=a; a=tmp+b; a=tmp+c; [00:00:00 CEST] --- Sun Jul 30 2017