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

[burek]

[00:00:46 CEST] <ubitux> rcombs: cool, going to try that out in a moment, thx
[00:08:21 CEST] <ubitux> rcombs: http://pastie.org/pastes/10477574/text
[00:08:30 CEST] <ubitux> it's weird that crypto is so slow
[00:08:38 CEST] <ubitux> since they do seem to have special asm for that
[00:08:45 CEST] <rcombs> yeah, I'm definitely weirded out
[00:10:53 CEST] <nevcairiel> meh why doesnt this work
[00:10:54 CEST] <rcombs> still better than our C, mind
[00:10:59 CEST] <nevcairiel> guess i need to fix my tracer tool again
[00:11:12 CEST] <rcombs> (and I'm not quite bored enough to want to rice our C)
[00:11:44 CEST] <rcombs> (nor write a plain SSE2/AVX2 implementation)
[00:14:19 CEST] <ubitux> more complete test (-a "AES-128 AES-192 AES-256"): http://pastie.org/pastes/10477583/text
[00:16:01 CEST] <rcombs> I'm particularly amused (but not surprised) by how we're a little faster than gcrypt
[00:16:17 CEST] <rcombs> because I used their code as a reference
[00:17:15 CEST] <rcombs> we're faster because the block-cipher work is done within the ASM instead of jumping in and out each block (or every 4 blocks), and that also lets us do fewer memory accesses
[00:18:05 CEST] <rcombs> michaelni_: that reminds me, is en/decrypting multiple blocks with a NULL iv supposed to work?
[00:18:37 CEST] <rcombs> I matched the C behavior but it'd be a bit quicker if I could ignore that case (and error in the C wrapper on it)
[00:18:56 CEST] <rcombs> (or just have it be UB; it wouldn't crash)
[00:19:53 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:97437bd17a8c: avcodec/mips/aaccoder_mips: Disable ff_aac_coder_init_mips() to prevent build failure
[00:19:54 CEST] <cone-163> ffmpeg 03Christophe Gisquet 07master:9f3bfe30dd99: mpegvideo: dnxhdenc: permute 10bits content
[00:26:57 CEST] <cone-163> ffmpeg 03Rostislav Pehlivanov 07master:65f5b96dd805: aacenc: increase size of s->planar_samples[] from 6 to 8
[00:27:48 CEST] <Timothy__Gu> opencl does do /tb
[00:27:51 CEST] <Timothy__Gu> oops
[00:30:58 CEST] <BBB> Gramner: so, do you want to do one more review round, or should I ask someone else, or is it ok to push?
[00:34:13 CEST] <cone-163> ffmpeg 03Rostislav Pehlivanov 07master:93e6b23c9f48: aacenc: shorten name of ff_aac_adjust_common_prediction
[00:40:50 CEST] <BBB> nevcairiel: do you want me to send that patch to the ML for review? or do you prefer to merge in your changes before we submit a useful version?
[00:41:39 CEST] <nevcairiel> i can send my amended version if you want
[00:45:21 CEST] <michaelni_> rcombs, the documentation doesnt forbid ECB with count > 1
[00:46:46 CEST] <rcombs> OK, I'll leave it then
[00:47:06 CEST] <rcombs> it's already faster than any other version I'm aware of
[00:49:50 CEST] <nevcairiel> mm this spec is 5 days old .. what are the chances that its just the drivers fault that its not working
[01:24:32 CEST] <cone-163> ffmpeg 03Christophe Gisquet 07master:e9a68b0316ab: x86: prores: templatize 10 bits simple_idct
[01:46:46 CEST] <BBB> kurosu: check const in x86inc.asm
[02:13:43 CEST] <cone-163> ffmpeg 03Christophe Gisquet 07master:2fd14dd8eb66: avcodec/simple_idct10: improve precision
[02:32:33 CEST] <rcombs> ubitux: https://gist.github.com/2a91ab246c3a99c15b3a CBC benchmarks
[04:06:14 CEST] <cone-163> ffmpeg 03Christophe Gisquet 07master:f1181e466062: fate: add 10bits YUV4:2:2 dnxhd test
[04:24:16 CEST] <jamrial> holy shit, all those libavutil headers that haven't been installed all this time...
[04:37:33 CEST] <rcombs> Gramner: apparently calling AES-NI "AES-NI" in cpu.c breaks shit
[05:41:21 CEST] <jamrial> great, gcc trunk is miscompiling libavcodec/aaccoder.c
[05:42:04 CEST] <jamrial> i spend most of today bisecting gcc svn to find the commit that broke jpeg2000 and avui, and now this
[05:52:51 CEST] <atomnuker> jamrial: works fine with 227716
[05:53:03 CEST] <atomnuker> though it's been about a month since I compiled mine :|
[05:53:31 CEST] <jamrial> yeah, it's most likely a recent regression
[05:53:41 CEST] <atomnuker> what's the error message?
[05:53:47 CEST] <jamrial> the one that broke jpeg2000 and avui is less than a week old
[05:54:05 CEST] <jamrial> no error message
[05:54:08 CEST] <jamrial> stddev: |580.98 - 582| >= 1
[05:54:14 CEST] <jamrial> and stddev: |752.37 - 745| >= 5
[05:54:38 CEST] <jamrial> compiling aacencoder.c with -O2 using that same compiler makes the test pass
[05:55:09 CEST] <jamrial> *aaccoder.c
[05:55:14 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20151013025849&slot=x86_64-archlinux-gcc-experimental
[05:56:06 CEST] <atomnuker> well, it's probably the twoloop coder
[05:56:14 CEST] <atomnuker> that could really use some splitting up
[05:56:56 CEST] <jamrial> doesn't change the fact it's being miscompiled by gcc trunk but is just fine with gcc stable :p
[07:31:01 CEST] <Gramner> rcombs: oh, that's interesting, I wonder why that happens. I guess you have to revert the cpu.c part then
[07:32:30 CEST] <rcombs> Gramner: I'd imagine the `-` is a special character there
[07:32:36 CEST] <Gramner> probably
[07:38:36 CEST] <Gramner> rcombs: btw, report() is a bit spammy in the aes checkasm test, it's enough to use it once at the end (and just call it "crypt" or something). any failure detected should print the function name in question anyway
[07:39:20 CEST] <rcombs> OK
[08:03:12 CEST] <Timothy__Gu> what's wrong with using fabs(f)?
[08:22:04 CEST] <ubitux> rcombs: oh
[08:22:32 CEST] <rcombs> oh?
[08:28:41 CEST] <ubitux> rcombs: so you're able to make openssl/crypto more efficient
[08:29:00 CEST] <ubitux> or i'm mistaken?
[08:29:21 CEST] <ubitux> the difference with lavu looks larger than in my tests
[08:29:49 CEST] <rcombs> libcrypto's AES is apparently slightly faster in CBC mode than ECB
[08:30:09 CEST] <rcombs> (at least, with the way crypto_bench runs ECB mode, which might not be optimal)
[08:31:48 CEST] <thardin> more spam via the mailing list
[08:43:22 CEST] Action: rcombs calculates
[08:43:40 CEST] <rcombs> apparently we're getting at least 2 instructions per clock on this
[08:43:52 CEST] <rcombs> (on muh Haswell)
[09:06:00 CEST] <TimNich> thardin: what spam are you seeing?
[09:06:09 CEST] <thardin> bitcodin
[09:06:42 CEST] <thardin> not on the list I realize, but they're getting addresses from there
[09:07:34 CEST] <TimNich> Not sure we can do anything about that then
[09:07:59 CEST] <thardin> yeah
[09:08:07 CEST] <thardin> beyond not doing business with them
[09:46:32 CEST] <rcombs> Gramner: somewhat confused why CBC mode ends up significantly slower than ECB
[09:46:38 CEST] <rcombs> in crypto_bench
[10:46:09 CEST] <__gb__> hi Compn, you pinged me?
[11:38:14 CEST] <cone-757> ffmpeg 03Ganesh Ajjanagadde 07master:9ab98b580eb5: avfilter/af_agate: replace FFABS with fabs
[11:38:14 CEST] <cone-757> ffmpeg 03Ganesh Ajjanagadde 07master:ac6b7c47cc56: avfilter/af_astats: replace FFABS with fabs
[11:38:15 CEST] <cone-757> ffmpeg 03Ganesh Ajjanagadde 07master:3b336ec2fbd4: avfilter/af_sidechaincompress: replace FFABS with fabs
[13:23:30 CEST] <cone-757> ffmpeg 03Christophe Gisquet 07master:e652f69b354b: x86: simple_idct10_template: fix overflow in pass
[13:41:17 CEST] <superware> can someone please try to reproduce a critical issue I'm having? http://trac.ffmpeg.org/ticket/4893
[13:41:35 CEST] <nevcairiel> user support is in #ffmpeg
[13:43:45 CEST] <superware> is "cehoyos" a user? :)
[13:44:39 CEST] <iive> he is developer
[13:44:40 CEST] <superware> I think a developer (or related) should reproduct this, I opened this ticket so obviously I'm able to reproduct.
[13:44:54 CEST] <superware> *reproduce
[13:45:22 CEST] <superware> so why #ffmpeg?
[13:45:23 CEST] <nevcairiel> the point is, this channel is for talk about development of ffmpeg, if you use ffmpeg and have problems with it, you should go to #ffmpeg
[13:45:52 CEST] <superware> hmmm, this issue is much more related to development than to "using" ffmpeg..
[13:46:02 CEST] <nevcairiel> irrelevant
[13:46:11 CEST] <nevcairiel> you're a user, you belong in #ffmpeg
[13:47:19 CEST] <iive> superware: even development using ffmpeg libraries is forwarded to #ffmpeg
[13:47:58 CEST] <superware> ok, I'm there now, but I can't see how any user can help ticket 4893 be reproduced by a developer and changed from "new" to "open".
[13:48:24 CEST] <superware> "development using ffmpeg" is "using ffmpeg"
[13:48:37 CEST] <nevcairiel> if a developer has an interest in the ticket, he will do that, but coming here isnt going to make that happen any sooner
[13:50:11 CEST] <superware> well cehoyos is actually interested, but he's not here, since this ticket involves a network capture (pcap) then it's not a conventional issue to reproduce.
[13:53:03 CEST] <superware> nevcairiel: isn't the process of ticket handling divided to: 1) reproduce and change status to open and 2) fix or change status to other.. ?
[14:08:24 CEST] <kierank> why don't you run the test case under gdb and post a backtrace
[14:08:58 CEST] <kierank> and does it happen with ffmpeg the main program
[14:08:58 CEST] <kierank> etc
[14:09:05 CEST] <iive> it doesn't crash,
[14:09:49 CEST] <iive> it just never recovers from the bitstream error
[14:09:57 CEST] <superware> no crash
[14:12:15 CEST] <kierank> If it really is critical then I would recommend https://ffmpeg.org/consulting.html
[14:14:13 CEST] <superware> I had a few weeks to get this at least reproduced by someone, but two weeks have already passed :)
[14:15:40 CEST] <Compn> __gb__ : rxt posted a patch on mplayer-dev-eng to merge mplayer-vaapi :)
[14:15:49 CEST] <superware> I guess any decent decoder should never get to a situation which it cannot recover from
[14:16:25 CEST] <ubitux> rcombs: apparently the openssl api we use is too low level, and we're supposed to use EVP api or whatever that is
[14:17:45 CEST] <kierank> superware: well if ffmpeg.c doesn't have the problem then it's not a decoder issue
[14:17:54 CEST] <kierank> and people here are volunteers
[14:17:57 CEST] <kierank> etc
[14:18:30 CEST] <Compn> superdump : contact carl directly, hes generally not on irc.
[14:18:38 CEST] <Compn> if you want to talk to him , that is
[14:18:38 CEST] <Compn> arg
[14:18:47 CEST] <Compn> superware : contact carl directly via email, hes generally not on irc
[14:18:53 CEST] <superdump> hellos :)
[14:19:01 CEST] Action: Compn ducks
[14:21:42 CEST] <Compn> superware : btw this is freenode , not efnet server :P
[14:21:54 CEST] Action: Compn afk
[14:21:55 CEST] <superware> oops
[14:24:41 CEST] <ubitux> rcombs: https://www.openssl.org/docs/manmaster/crypto/evp.html
[14:24:52 CEST] <ubitux> > Although low level algorithm specific functions exist for many algorithms their use is discouraged. They cannot be used with an ENGINE and ENGINE versions of new algorithms cannot be accessed using the low level functions. Also makes code harder to adapt to new algorithms and some options are not cleanly supported at the low level and some operations are more efficient using the high level interface.
[14:27:29 CEST] <__gb__> Compn, oh, ok. Never tried to do that, too heavyweight process (from here), so mplayer-vaapi was in "trivial bug fix" only mode.
[14:28:07 CEST] <__gb__> if someone wants to merge, why not, but don't bother with the various rendering options (useful for testing APIs only), only keep the vaPutSurface() variant
[14:30:13 CEST] <Compn> __gb__ : you could reply to rxt on mplayer-dev-eng
[14:39:14 CEST] <BBB> Gramner: pokey
[14:39:52 CEST] <Compn> or just mail him direct :)
[14:40:00 CEST] <Compn> maybe test his patch ? :)
[14:40:46 CEST] Action: __gb__ added that to the TODO list for "after"
[14:50:53 CEST] <wm4> __gb__: do you still want to update the vaapi API in libavcodec?
[14:53:41 CEST] <__gb__> yes, though wanted to add other codecs to assess this new infrastructure but my test platform died, so I guess I will borrow from colleagues'
[14:56:05 CEST] <wm4> ok nice to hear
[14:56:19 CEST] <wm4> Compn: maybe let that mplayer guy know
[14:56:40 CEST] <wm4> vaapi lavc API usage might be significantly easier once __gb__ is done
[15:16:11 CEST] <Compn> wm4 : thanks.  i will
[15:19:21 CEST] Action: Compn grumbles about src/index patch not including a date in the news entry
[15:19:30 CEST] <Compn> whoever adds the next entry can fix it :P
[15:19:31 CEST] Action: Compn runs
[15:20:04 CEST] <Compn> wm4 : done
[15:34:05 CEST] <cone-757> ffmpeg 03Christophe Gisquet 07master:4369b9dc7b2b: x86: simple_idct(_put): 10bits versions
[15:52:24 CEST] <t4nk861> im using ffmpeg library in windows , vs2012,  Is there any option to write output file to memory instead of disc?
[15:53:46 CEST] <BBB> t4nk861: #ffmpeg please
[16:04:15 CEST] <cone-757> ffmpeg 03Christophe Gisquet 07master:7ece8b50b19e: x86: simple_idct: 12bits versions
[16:39:56 CEST] <Gramner> BBB: poke'd
[16:40:23 CEST] <BBB> what shall I do with the patches?
[16:42:00 CEST] <Gramner> if you addressed my comments feel free to push. I've glanced through all of them (I think)
[16:42:36 CEST] <BBB> yeah sorry its quite a few of them
[16:42:46 CEST] <BBB> inverse transform really is the biggest piece of code in vp9
[16:42:46 CEST] <Gramner> can always change stuff afterwards and I don't want to hold up things for forever
[16:42:54 CEST] <BBB> ok ty, Ill push
[16:43:02 CEST] <BBB> nevcairiel: what about the header patch?
[17:03:31 CEST] <cone-757> ffmpeg 03Michael Niedermayer 07master:a745d1a9e4c4: avcodec/dct-test: Print failure notice below the failed *dct
[17:03:32 CEST] <cone-757> ffmpeg 03Christophe Gisquet 07master:b6594a9605de: x86: dct-test: add more idcts
[17:06:49 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:1c3be32533e5: vp9: add 10/12bpp mmxext-optimized iwht_iwht_4x4 function.
[17:06:50 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:6b579cf547a7: vp9: add 10bpp simd (mmxext/ssse3) for idct_idct_4x4.
[17:06:51 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:f76423d0975d: vp9: add x86 simd (sse2/ssse3) for iadst4 10bpp functions.
[17:06:52 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:235e76aeb877: vp9: initial attempt at a idct_idct_4x4 12bpp x86 simd (sse2) impl.
[17:06:53 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:a35f6bdb38aa: vp9: add 12bpp sse2 versions of iadst4.
[17:06:54 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:e0610787b2ef: vp9: add 10/12bpp sse2 SIMD for idct_idct_8x8.
[17:06:55 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:cb054d061a3e: vp9: add 10/12bpp sse2 SIMD versions of iadst8x8.
[17:06:56 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:1338fb79d4fd: vp9: add 10/12bpp sse2 SIMD version for idct_idct_16x16.
[17:06:57 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:0e80265b0a2a: vp9: refactor 10/12bpp dc-only code in 4x4/8x8 and add to 16x16.
[17:06:58 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:3d0ca2fe89ea: vp9: 10/12bpp sse2 SIMD for iadst16.
[17:06:59 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:488fadebbc4b: vp9: add 10/12bpp idct_idct_32x32 sse2 SIMD version.
[17:07:00 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:eb4b5ff738db: vp9: add itxfm_add eob shortcuts to 10/12bpp functions.
[17:07:01 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:408bb8556fde: vp9: refactor itx coefficients and share between 8 and 10/12bpp.
[17:07:02 CEST] <cone-757> ffmpeg 03Ronald S. Bultje 07master:e57863838230: vp9: use registers for constant loading where possible.
[17:08:09 CEST] <nevcairiel> BBB: i need to squash and cleanup, then i can send my amended versions to the ML
[18:16:53 CEST] <cone-757> ffmpeg 03Nedeljko Babic 07master:de262d018d7d: avcodec/mips/aaccoder_mips: Sync with the generic code
[18:37:40 CEST] <kierank> atomnuker: oh i didn't notice klaussfreire :(
[18:44:43 CEST] <cone-757> ffmpeg 03Pedro Arthur 07master:5bd62a1b3c33: swscale: fix ticket #4881
[19:03:05 CEST] <jamrial> atomnuker: the aaccoder.c miscompilation was the same gcc bug as the one that broke jpeg2000 and avui
[19:03:07 CEST] <jamrial> it's fixed now
[19:25:49 CEST] <iive> jamrial: link? is it gcc x.y.0 bug again?
[19:27:27 CEST] <cone-757> ffmpeg 03Michael Niedermayer 07master:147b12162da6: avutil/fifo: Fix thread saftey of av_fifo_generic_peek()
[19:31:27 CEST] <jamrial> iive: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920
[19:31:49 CEST] <jamrial> and it was found and fixed long before release, so no
[19:33:37 CEST] <jamrial> the gcc 4.9.0 flac miscompilation was not fixed before release becase we reported it too late
[19:35:00 CEST] <iive> oh, that one. I thought there is new one with the latest gcc
[19:36:17 CEST] <nevcairiel> they are testing gcc trunk, not release versions :d
[19:39:21 CEST] <iive> uff, it is new bug. good thing fate got it. :)
[19:57:54 CEST] <jamrial> BBB: vp9 itx \o/
[19:58:10 CEST] <jamrial> will you add sse4 versions using pmuldq? assuming they would be faster than the pmaddwd workaround
[19:59:00 CEST] <BBB> I dont think theyll be faster :(
[19:59:58 CEST] <BBB> pmuldq has the issue that you can only put 2 values in there, so the throughput is very small
[20:00:14 CEST] <BBB> but then admittedly I havent tested that
[20:00:23 CEST] <BBB> (because it seemed so unlikely itd be faster)
[20:01:36 CEST] <jamrial> it's as fast as every other mult instruction (except pmulld, which is very slow)
[20:01:42 CEST] <jamrial> but yeah, only two values
[20:10:24 CEST] <BBB> pmaddwd allows 8 multiplies, plus the add
[20:10:31 CEST] <BBB> now, every multiply is split in 2, so its really only 4
[20:10:34 CEST] <BBB> but still, 4 > 2
[20:11:18 CEST] <BBB> however, avx2 would have amazing effects here
[20:11:23 CEST] <BBB> like, mind-blowingly good
[20:12:02 CEST] <BBB> (not specifically for this multiply/bits issue, but in general, allowing for optimizing the decoder)
[20:12:15 CEST] <BBB> (because theres SO MUCH STUFF going on in there)
[20:12:45 CEST] <cone-757> ffmpeg 03Pedro Arthur 07release/2.8:bb3b4ad46030: swscale: fix ticket #4881
[20:15:45 CEST] <reynaldo> Compn: thanks for pushing the one to -web but you should try not to overwrite the author in patches sent to the ml
[20:15:57 CEST] <reynaldo> not a biggie anyway
[20:16:02 CEST] <reynaldo> thanks for taking care of it
[20:31:05 CEST] <Compn> reynaldo 
[20:31:06 CEST] <Compn> e r
[20:31:16 CEST] <Compn> reynaldo : i dont use git properly , manual patches and stuff....
[20:31:36 CEST] <Compn>  yes, i am "that guy"...
[20:32:11 CEST] <reynaldo> No worries, I knew it was unintended
[20:32:15 CEST] <reynaldo> Compn ^
[20:32:25 CEST] <Compn> i should have said patch by reynaldo...
[20:32:25 CEST] <Compn> :P
[20:32:31 CEST] <reynaldo> just something you might wana look into firther down the road
[20:32:37 CEST] <reynaldo> further/
[21:14:35 CEST] <cone-757> ffmpeg 03Michael Niedermayer 07release/2.8:40934e0e9b63: Update for 2.8.1
[22:06:52 CEST] <kurosu> jamrial, might have found the issue, see patch on ml
[22:07:11 CEST] <kurosu> although it's not tested under valgrind
[22:08:27 CEST] <jamrial> kurosu: i'll test it in a moment
[22:08:39 CEST] <kurosu> thanks
[22:09:18 CEST] <BBB> kurosu: thank you for using x86inc.asm const!
[22:09:28 CEST] <BBB> kurosu: very lovely indeed
[22:09:31 CEST] <kurosu> I don't pretend I can write better code, but at least kostya's prores encoder looks a lot better
[22:09:49 CEST] <kurosu> BBB, didn't know about that const thing, less error prone
[22:10:12 CEST] <kurosu> (hint: I forgot about the endianness when declaring the C constants)
[22:11:39 CEST] <kurosu> BBB, what's weird is all the stuff built when trying just to get prores (ended up with h263 & co when disabling all encoders and decoders and just selecting prores)
[22:12:15 CEST] <BBB> with constants.c? or the new x86inc constants?
[22:12:23 CEST] <BBB> constants.c is unconditionally built, afaik
[22:13:23 CEST] <kurosu> I don't think it matters, but with x86inc's as I wanted to make absolutely sure prores selecting idctdsp therefore simple_idct didn't have a strange edge case
[22:14:39 CEST] <kurosu> nevcairiel/jamrial, have you ever reported a msys2 issue? if yes, where?
[22:14:42 CEST] <kurosu> I've contacted the github guy and I'm only seeing a SF mailing list, msys2-users or something
[22:14:43 CEST] <BBB> idctdsp is the new name of simple_idct?
[22:15:01 CEST] <kurosu> no, that's the dependency laid in configure & co
[22:15:39 CEST] <kurosu> probably needed for all the scantable init, permutation etc
[22:15:47 CEST] <peloverde> BBB: do you have any general idea of token_decode_time:extrabits_decode_time in ffvp9?
[22:16:16 CEST] <BBB> uhm& no
[22:16:23 CEST] <BBB> Im going to guess its almost exclusively tokens
[22:16:32 CEST] <BBB> but I have no solid data
[22:17:04 CEST] <kurosu> peloverde, hi ;)
[22:17:11 CEST] <jamrial> kurosu: no, but someone else did by commenting on the corresponding commit that broke something in the author's github repo: https://github.com/Alexpux/
[22:17:33 CEST] <kurosu> not the guy I reached
[22:17:36 CEST] <kurosu> but ok
[22:18:33 CEST] <peloverde> kurosu: hey
[22:19:24 CEST] <jamrial> d3d11 is still broken on their mingw-w64 headers package for that matter
[22:24:06 CEST] <rcombs> ubitux: seems like using the high-level OpenSSL API can't possibly be better for perf, can it?
[22:24:41 CEST] <nevcairiel> jamrial: did upstream fix that yet?
[22:24:58 CEST] <kurosu> jamrial, got a more precise link? I assume this is not a gcc issue as much as a mingw header or whatever the package is?
[22:25:24 CEST] <nevcairiel> mingw-w64 is terribly slow at adopting new features into their headers
[22:25:31 CEST] <nevcairiel> sometimes it feels like its run by monkeys
[22:25:41 CEST] <jamrial> yes, it's mingw-w64 headers. or rather, msys2's package of it
[22:25:50 CEST] <jamrial> https://github.com/Alexpux/MINGW-packages/commit/262196808193c6e9abe406ad4a72a800a44ef638 
[22:26:53 CEST] <jamrial> that's the latest commit to their mingw-w64 package. the custom patch they added is not right
[22:27:31 CEST] <jamrial> config.log from ffmpeg shows lots of "/mingw64/x86_64-w64-mingw32/include/d3d11.h:8595:9: error: unknown type name 'ID3D11VideoContext' ID3D11VideoContext* This," errors when probing the functionality
[22:27:59 CEST] <nevcairiel> so i assume even mingw trunk is still broken, if a custom patch is even needed
[22:28:35 CEST] <ubitux> rcombs: "ENGINE versions of new algorithms cannot be accessed using the low level functions."
[22:28:41 CEST] <ubitux> i'm assuming it will actually be faster
[22:28:43 CEST] <rcombs> oh, huh
[22:28:54 CEST] <rcombs> you want to update that or should I?
[22:29:13 CEST] <ubitux> i won't take the time to, sorry
[22:33:45 CEST] <jamrial> kurosu: looks like the dnxhd patch works
[22:33:53 CEST] <jamrial> let me try valgrind as well
[22:35:19 CEST] <kurosu> thanks
[22:36:28 CEST] <kurosu> would be nice if gcc had a 'random poisoining' option or the like
[22:36:47 CEST] <kurosu> At least under windows, I don't get a lot of errors due to uninitialized access after arrays
[22:36:58 CEST] <kurosu> s/after/around
[22:54:09 CEST] <kurosu> jamrial, I'm about to leave, so please lgtm the patch (or even apply it)
[22:54:11 CEST] <kurosu> thanks
[22:55:11 CEST] <BBB> doesnt valgrind have poisoning?
[22:55:33 CEST] <cone-757> ffmpeg 03Christophe Gisquet 07master:74c414202f0e: x86: simple_idct10_template: use const
[22:55:39 CEST] <kurosu> I don't have valgrind under windows
[22:55:43 CEST] <jamrial> kurosu: valgrind is happy, so should be ok
[22:55:44 CEST] <BBB> ah, right
[22:55:50 CEST] <kurosu> (and my laptop is almost dead)
[22:56:00 CEST] <BBB> :(
[23:17:41 CEST] <atomnuker> kierank: klaussfreire just pinged you on the ticket, just so you know
[23:18:13 CEST] <nevcairiel> Triggering an assert seems somewhat equally unwanted as a crash
[23:18:18 CEST] <nevcairiel> application still exits
[23:27:03 CEST] <rcombs> ubitux: https://gist.github.com/626f883ca67f6f4a0a38
[23:27:38 CEST] <rcombs> vs. ENGINE libcrypto
[23:27:44 CEST] <ubitux> looks better :)
[23:28:08 CEST] <rcombs> their ECB code does some parallelization, which is why it comes out a little faster
[23:28:50 CEST] <rcombs> I think I'll add decryption in crypto_bench
[23:29:20 CEST] <rcombs> we pay a penalty for CBC encryption that probably doesn't apply when decrypting (their ASM's comments mention that)
[23:53:49 CEST] <cone-757> ffmpeg 03Christophe Gisquet 07master:234369d0fd04: dnxhdenc: fix access outside of image
[00:00:00 CEST] --- Wed Oct 14 2015