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

[burek]

[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/src/mlp_data.c <- data
[11:54:53 CEST] <atomnuker> https://github.com/xiph/opus/blob/e6704abcad486c9966e79fda3663074a36870c0f/src/mlp.c <- 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/nlmeans.cl
[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=e93cfccc2a6d62cfaf3623bf459cebc03656664c;hb=HEAD#l2509 real-world use-case (corresponding C: https://git.videolan.org/?p=x264.git;a=blob;f=common/mc.c;h=65af5b9e25ad25290451e7df600acc4b12fe7632;hb=HEAD#l527 )
[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