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

[burek]

[00:00:34 CEST] <atomnuker> yep, there's that gcc flag to use it instead (if you really wanted to)
[00:00:55 CEST] <nevcairiel> i've only used that the other way around, to make x86 use sse
[00:01:30 CEST] <atomnuker> I don't think intel will ever scrap the old x87, some people will run dos on skylake-x
[00:01:35 CEST] <TD-Linux> I wonder when we'll see execution lanes that only support <80 bit precision
[00:01:55 CEST] <nevcairiel> well 32-bit x86 mode requires x87 anyway
[00:02:10 CEST] <nevcairiel> they could emulate it through sse execution  units, no clue if they possibly do that anyway
[00:02:45 CEST] <TD-Linux> you can't emulate it (well) with sse because of the reduced precision
[00:03:55 CEST] <nevcairiel> i suppose, 80-bits is quite a bit higher then 64
[00:04:14 CEST] <nevcairiel> clearly we need 128-bit floats in avx1024
[00:04:17 CEST] <nevcairiel> :D
[00:05:22 CEST] <nevcairiel> (apparently POWER9 gets that)
[00:06:00 CEST] <TD-Linux> I'm starting to see posts on fedora-devel about 32-bit packages breaking because upstream only tested with sse2 float, not x87
[00:07:11 CEST] <nevcairiel> i wonder if I can dig up some benchmarks of the difference
[00:11:49 CEST] <iive> atomnuker: btw, could you make pvq_search return int, instead of float. sum of Y^2 is integer.
[00:15:50 CEST] <jamrial> nevcairiel: x87 was four times slower than sse in compiler generated non-vectorized code of dcadec lfe functions last time i checked
[00:16:34 CEST] <jamrial> imo, we should just say fuck pentium 2s and athlon thunderbirds and force -msse -mfpmath=sse as a bare minimum for x86_32
[00:17:08 CEST] <iive> what is the point of forcing sse for C code, just because it is slow on slow cpu's?
[00:17:11 CEST] <nevcairiel> some random benchmarks i found seem to suggest that without -msse2 gcc seems not to really use it well
[00:18:15 CEST] <nevcairiel> one of these days I should fix the remaining parts so that a -msse2 build on windows doesnt crash all the time
[00:18:24 CEST] <nevcairiel> stupid stack alignment
[00:18:45 CEST] <nevcairiel> (more precisely, a gcc dll used from msvc app)
[00:18:46 CEST] <jamrial> iive: x87 is slow on new cpus as well,a nd x86_32 builds will always use it unless you pass custom CFLAGS to configure
[00:19:19 CEST] <iive> jamrial: i think it depends on the default cpu
[00:19:29 CEST] <iive> --cpu 
[00:19:53 CEST] <nevcairiel> i dont think that gets overriden by -march on gcc
[00:21:38 CEST] <atomnuker> iive: sure, if that's easier
[00:21:57 CEST] <jamrial> --cpu sets -march on GCC, and that doesn't override -mfpmath, which on x86_32 is always x87 by default
[00:24:12 CEST] <iive> atomnuker: in the C code, it converts the int to float, before returning it... and on win32 it needs tmp memory to store and load x87 register
[00:24:21 CEST] <Shiz> march should set mfpmath
[00:24:25 CEST] <iive> i am talking about the ffmpeg --cpu
[00:24:31 CEST] <Gramner> -msse2 -mfpmath=sse makes all floating-point C code faster by a decent amount on most cpus on 32-bit x86 if can stand the complaints of people who insist doing multimedia stuff on pentium 2:s is the way to go
[00:24:56 CEST] <nevcairiel> my problem is that -msse2 makes my DLLs crash due to windows stack alignment crappyness
[00:25:07 CEST] <nevcairiel> and ffmpeg doesnt compile with -mstackrealign
[00:25:18 CEST] <atomnuker> iive: just return an int, it'll get converted automatically when sqrtfing it
[00:25:39 CEST] <atomnuker> (I gotta check that asm you sent me)
[00:25:46 CEST] <iive> atomnuker: i'm not sure the assembler works like this.
[00:26:15 CEST] <iive> atomnuker: it returns float, i tested it on linux 32 too, so it probably works :D
[00:27:27 CEST] <iive> nevcairiel: there are attributes that could realign specific functions, does ffmpeg use that for api entry functions?
[00:27:39 CEST] <nevcairiel> only for the main api
[00:27:44 CEST] <nevcairiel> like decode and filtering
[00:27:53 CEST] <nevcairiel> but the crashes happen in all sorts of random functions that use floats
[00:28:04 CEST] <nevcairiel> like options setting
[00:28:38 CEST] <nevcairiel> let me build such a binary and see
[00:28:40 CEST] <iive> hum... that's strange, sse does have a bunch of scalar operations and could be used without needing stack alignment
[00:28:56 CEST] <nevcairiel> it only happens with -msse2
[00:29:11 CEST] <nevcairiel> maybe gcc got smarter and -mstackrealign works now with ffmpeg
[00:29:16 CEST] <nevcairiel> lets see
[00:31:15 CEST] <iive> atomnuker: on the other side, i could just return sqrt(syy)...
[00:31:52 CEST] <iive> then it would be float
[00:35:09 CEST] <kiroma> May I have a small question?
[00:36:13 CEST] <iive> go ahead kiroma 
[00:36:26 CEST] <kiroma> Have you considered changing from autoconf to cmake?
[00:36:40 CEST] <nevcairiel> we dont use autoconf
[00:37:06 CEST] <kiroma> Oh.
[00:38:12 CEST] <nevcairiel> configure is a big custom shell script
[00:38:21 CEST] <nevcairiel> its not autotools, even if it shares the configure name
[00:38:32 CEST] <iive> and options style
[00:39:02 CEST] <kiroma> yeah since it shares name I just assumed it used autoconf.
[00:40:56 CEST] <iive> always check your assumptions
[00:41:55 CEST] <kiroma> Is there a reason you created a whole custom script for generating a makefile instead of using tools like cmake/autoconf?
[00:42:35 CEST] <nevcairiel> we dont generate the makefiles, we just configure them
[00:43:06 CEST] <nevcairiel> also, autotools is horrible and cmake probably didnt even exist back then
[00:43:45 CEST] <nevcairiel> cmake also doesnt deal very well with massive configurable build like ffmpegs, in my experience anyway
[00:43:57 CEST] <nevcairiel> its configuration syntax is terrible
[00:45:50 CEST] <J_Darnley> BBB: It looks like the 10-bit is doing the vertical transform first.  Am I reading this right?
[00:46:51 CEST] <kiroma> Does it? I had no problem compiling stuff like blender.
[00:47:18 CEST] <kiroma> And yeah, it seems that cmake had its initial release right before ffmpeg was created.
[00:48:42 CEST] <J_Darnley> Is there any build tool that isn't utter shit?  I honestly think ffmpeg's hand written one is one of the least worst around.
[00:49:01 CEST] <nevcairiel> most of them are a bit crappy in some area
[00:52:38 CEST] <kiroma> Well ffmpeg's one has been created for ffmpeg, while I imagine most build tools need to be as universal as possible.
[00:56:06 CEST] <kiroma> Also, the thing I like about cmake is the configurability.
[00:57:16 CEST] <kiroma> As an end-user, I have no problem changing any part of the build environment, finding missing dependencies, etc...
[01:01:00 CEST] <J_Darnley> Argh.  I don't get it.  This is totally doing vertical transform first.  Furthermore it looks like 8-bit should work if I give the right options to these macros.
[01:02:27 CEST] <nevcairiel> i wonder if gcc is disobeying me, i can clearly see it using x87 instructions, even though I told it not to
[01:04:09 CEST] <nevcairiel> these functions take floats as parameters, so i guess it has no choice because of the calling convention, but should it then decide to keep using x87?
[01:04:37 CEST] <wm4> lol as if cmake isn't garbage
[01:04:40 CEST] <wm4> and autotools
[01:04:56 CEST] <wm4> though suffering through configure's cryptic shit isn't nice either
[01:06:31 CEST] <wm4> basically everything sucks and is terrible
[01:06:34 CEST] <rcombs> ^
[01:08:17 CEST] <wm4> maybe I should try meson again
[01:09:09 CEST] <J_Darnley> I've been meaning to try that on my own project since FOSDEM
[01:16:07 CEST] <nevcairiel> hm, apparently gcc has gotten smarter
[01:16:11 CEST] <nevcairiel> it fixes these problems on its own now
[01:17:21 CEST] <J_Darnley> Wow, gcc improves quickly.
[01:18:14 CEST] <jamrial> if only people upgraded as quickly
[01:18:25 CEST] <jamrial> we keep getting bug reports of builds done with 4.x gcc :p
[01:18:47 CEST] <nevcairiel> it can build ffmpeg with -mstackrealign now, and it even automatically enables that option if you enable sse/sse2 on windows
[01:19:26 CEST] <nevcairiel> with -msse2 and -mno-stackrealign it still crashes as before, to confirm
[01:19:54 CEST] <nevcairiel> hm weird
[01:20:02 CEST] <nevcairiel> instead of aligning the stack it just seems to stop using sse2
[01:20:07 CEST] <nevcairiel> wonder if thats intended =p
[01:20:16 CEST] <atomnuker> iive: I meant in the C code, not the asm
[01:21:07 CEST] <iive> atomnuker: well, i'm not quite sure how the linker would know know what the asm function returns...
[01:21:37 CEST] <J_Darnley> I had to look deep into the manual to find a stack align attribute.  Luckily the project mentioned above only has one entry point from Windows.
[01:21:48 CEST] <atomnuker> iive: by changing it to return an int..
[01:22:16 CEST] <iive> you mean, the definition :)
[01:22:33 CEST] <iive> or is it declaration... i always swap these.
[01:22:39 CEST] <nevcairiel> still seems very odd that it would just stop using sse2, does it like deduce that the prologue is more expensive then not using sse2?
[01:23:05 CEST] <nevcairiel> (this is on gcc 6.3)
[01:31:42 CEST] <BBB> J_Darnley: I believe so, yes
[01:31:53 CEST] <BBB> J_Darnley: and then the coefficients are written in the array pre-transposed already
[01:40:53 CEST] <rcombs> nevcairiel: I've been using -mstackrealign for windows for a while, yeah
[01:41:20 CEST] <nevcairiel> rcombs: then tell me why it just disables sse/sse2 instruction use :D
[01:41:26 CEST] <rcombs> didn't realize -msse2 triggered that by default, though
[01:41:28 CEST] <nevcairiel> instead of aligning the stack
[01:41:36 CEST] <rcombs> wait wat
[01:41:46 CEST] <rcombs> in my experience it aligns the stack like it's supposed to
[01:41:55 CEST] <nevcairiel> thats what i'm seeing here right now
[01:41:55 CEST] <rcombs> else we'd be seeing crashes in ASM functions
[01:42:16 CEST] <nevcairiel> everything using yasm code has the explicit align  flag in the code
[01:42:27 CEST] <nevcairiel> so the compiler is forced to do it
[01:42:30 CEST] <rcombs> oh huh
[01:42:41 CEST] <rcombs> isn't aligning the stack like, one instruction
[01:42:52 CEST] <nevcairiel> it eats a register
[01:42:55 CEST] <rcombs> and esp, 0xsomething?
[01:43:22 CEST] <rcombs> I guess it forces you to have a frame pointer where you might not otherwise
[01:43:54 CEST] <nevcairiel> i'm looking at av_reduce because thats something I just had crash, with -mno-stackrealign it uses xmm regs
[01:43:59 CEST] <nevcairiel> with -mstackrealign it doesnt
[01:44:06 CEST] <nevcairiel> but the prologue doesnt otherwise change at all
[01:44:21 CEST] <rcombs> and with -msse2 it has the -mstackrealign behavior?
[01:44:32 CEST] <rcombs> (if you don't explicitly specify one way or the other)
[01:44:35 CEST] <nevcairiel> it has that no matter what -m i pick
[01:44:40 CEST] <nevcairiel> but yea
[01:44:55 CEST] <nevcairiel> obviously with -mno-stackrealign it just crashes
[01:45:04 CEST] <nevcairiel> but it does use sse2
[01:45:30 CEST] <nevcairiel> gcc is weird
[01:45:47 CEST] <nevcairiel> i wonder if i can somehow find out if it actually uses sse2 anywhere outside of asm functions
[01:47:39 CEST] <rcombs> nm, grep for movdq?
[01:48:02 CEST] <nevcairiel> next test, actually disable attribute_align_arg from doing anything and see if gcc realigns anywhere at all
[01:48:09 CEST] <nevcairiel> i should grab gcc 7 and see if something changed
[01:49:59 CEST] <nevcairiel> hm yeah that crashes
[01:50:04 CEST] <nevcairiel> i think -mstackrealign doesnt do shit
[01:50:20 CEST] <nevcairiel> well, other then disabling sse(2)
[01:50:24 CEST] <rcombs> I think I'm on a somewhat old gcc
[01:51:39 CEST] <rcombs> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02133.html
[01:52:50 CEST] <nevcairiel> so they only align the stack when needed, and cant really figure it out properly?
[01:52:53 CEST] <nevcairiel> sounds...useful
[01:55:17 CEST] <nevcairiel> you can force it to do it everywhere by using -mincoming-stack-boundary, but that explodes in various inline asm things
[01:55:52 CEST] <nevcairiel> at least enabling -msse2 should be s omewhat save then
[01:56:32 CEST] <rcombs> welp
[01:56:48 CEST] <rcombs> we're improving our build tools so hopefully I can start making an x86_64 windows build soon
[01:57:06 CEST] <rcombs> and then if the x86 build is performing poorly because of this shit I can just tell people to use that instead
[01:57:30 CEST] <rcombs> (I mean, I already know switching to x86_64 should yield a significant improvement in x264 perf)
[01:57:32 CEST] <nevcairiel> well its only for generic C code anyway
[01:57:45 CEST] <nevcairiel> so the difference is probably minimal either way
[01:57:48 CEST] <rcombs> yeah, so probably not a huge deal
[01:57:50 CEST] <rcombs> but still
[01:58:50 CEST] <nevcairiel> was just surprising me
[01:59:27 CEST] <rcombs> same
[01:59:53 CEST] <nevcairiel> it seems to generally work though otherwise
[02:00:20 CEST] <nevcairiel> i checked stuff like the dca dsp that jamrial suggested to gain a speed improvement from using fpmath=sse, and it has the align header
[02:01:09 CEST] <nevcairiel> (even though technically not necessary, since its shielded behind the explicit align from decode_audio)
[02:12:43 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:75697b500c3e: avcodec/tiff: reset sampling[] if its invalid
[02:12:44 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b147ded288ea: avcodec/svq3: Fix runtime error: left shift of negative value -6
[02:12:45 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:72e5ccfe3783: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[02:12:46 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:21d50c185db0: avcodec/scpr: mask bits to prevent out of array read
[02:12:47 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b7b28b6aadd4: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int'
[02:12:48 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f34dc82d566c: avcodec/takdec: Fix  runtime error: left shift of negative value -42
[02:12:49 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:6e788fadaee9: avcodec/mlpdec: Fix runtime error: left shift of negative value -1
[02:12:50 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:6ebb9e7b7765: avcodec/flicvideo: Check frame_size before decrementing
[02:12:51 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:fedd8b65077d: avcodec/fmvc: Fix off by 1 error
[02:12:52 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:41867021840d: avcodec/aacdec_template: Fix fixed point scale in decode_cce()
[02:12:53 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:72e5607c8758: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int'
[02:12:54 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b6c0ad571f60: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[02:12:55 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:686eb3b1ed5b: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[02:12:56 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:fc7c37906077: avcodec/pixlet: Fix reading invalid numbers of bits
[02:12:57 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f254c7ea1397: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int'
[02:12:58 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:e46bc3052dc1: avcodec/mimic: Use ff_set_dimensions() to set the dimensions
[02:12:59 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f3b6ea14081a: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int'
[02:13:00 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:e605faaabcf8: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context
[02:13:01 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:9c65a87bd48e: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 170 is too large for 32-bit type 'int'
[02:13:02 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f397613f0595: avcodec/sbrdsp_fixed: fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[02:13:03 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a5875f8a1e55: avcodec/mlpdsp: Fix runtime error: signed integer overflow: -24419392 * 128 cannot be represented in type 'int'
[02:13:04 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:ff4f52590529: avcodec/takdec: Fix runtime error: left shift of negative value -63
[02:13:05 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f832d7361d03: avcodec/aac_defines: Fix: runtime error: left shift of negative value -2
[02:13:06 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:3cfb01607144: avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int'
[02:13:07 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:0ea475942e75: avcodec/vmnc: Check location before use
[02:13:08 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:d11c686204b4: avcodec/vp9block: fix runtime error: signed integer overflow: 196675 * 20670 cannot be represented in type 'int'
[02:13:09 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a7442f8d357d: avcodec/mpeg4videodec: Check for multiple VOL headers
[02:13:10 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:e73efe469112: avcodec/aacdec_fixed: Fix runtime error: shift exponent 34 is too large for 32-bit type 'int'
[02:13:11 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:17a4e791bfe5: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -32767 * 130560 cannot be represented in type 'int'
[02:13:12 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:abd5277318c5: avcodec/ivi_dsp: Fix multiple runtime error: left shift of negative value -71
[02:13:13 CEST] <cone-477> ffmpeg 03Max Justicz 07release/3.3:6b839e9aa336: avcodec/fmvc: Fix use of uninitialized memory when the first frame is not a keyframe
[02:13:14 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:ba7ea7c4b1aa: avcodec/jpeglsdec: Check get_bits_left() before decoding a picture
[02:13:15 CEST] <cone-477> ffmpeg 03Max Justicz 07release/3.3:861c05b286f2: avcodec/sanm: Fix uninitialized reference frames
[02:13:16 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:38fd2a33b93c: avcodec/jpeg2000dec: Check tile offsets
[02:13:17 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:80cebb992c2d: avcodec/jpeg2000dec: Fix copy and paste error
[02:13:18 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:190787a02630: avcodec/diracdec: Fix off by 1 error in quant check
[02:13:19 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a49743407bc6: avcodec/smc: Check remaining input
[02:13:20 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f85a71527a8b: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int'
[02:13:21 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:4e8c5721b356: avcodec/clearvideo: Check buf_size before decoding frame
[02:13:22 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:42163d4c551d: avutil/internal: Do not enable CHECKED with DEBUG
[02:13:23 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:92a23e2a639c: avformat/mux: Fix copy an paste typo
[02:13:24 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:dbff2d602d86: avcodec/pixlet: Fix runtime error: signed integer overflow: 2147483647 + 32 cannot be represented in type 'int'
[02:13:25 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b803624aae4c: avcodec/ra144dec: Fix runtime error: left shift of negative value -17
[02:13:26 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:75d881f1a979: avcodec/mlpdec: Do not leave invalid values in matrix_out_ch[] on error
[02:13:27 CEST] <cone-477> ffmpeg 03Kevin Mark 07release/3.3:573e40e8f1c3: doc/filters: Clarify scale2ref example
[02:13:28 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f5626db24e78: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2
[02:13:29 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:c0895d64f5fa: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int'
[02:13:30 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:d2476bd465a1: avcodec/libfdk-aacdec: Correct buffer_size parameter
[02:13:31 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:1d589a93b07c: avcodec/wnv1: More strict buffer size check
[02:13:32 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b330fec1ced7: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int'
[02:13:33 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:3e18f0fddde8: avcodec/sheervideo: Check input buffer size before allocating and decoding
[02:13:34 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:cd3314552b24: avcodec/jpeg2000dec: Check tile offsets more completely
[02:13:35 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:bc2cbb307761: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int'
[02:13:36 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:586e00d7d3ec: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int'
[02:13:37 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b419c7564c5f: avcodec/ylc: Check count in build_vlc()
[02:13:38 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:be9268e35044: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[02:13:39 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:080edf29e74a: avcodec/webp: Fixes null pointer dereference
[02:13:40 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b578ba915f07: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro
[02:13:41 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:22dab0f4e1b8: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int'
[02:13:42 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:3a0e4368ec5a: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int'
[02:13:43 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:722cc62baa98: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[02:13:44 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:ece91a3918ca: avcodec/truemotion2: Fix passing null pointer to memset()
[02:13:45 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:0a0eec60c878: avcodec/jpeg2000dec: Use ff_set_dimensions()
[02:13:46 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:d59e6cef7902: avcodec/dds: Fix runtime error: left shift of 145 by 24 places cannot be represented in type 'int'
[02:13:47 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:c1074aea7131: avcodec/ansi: Fix frame memleak
[02:13:48 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a24cd04074c8: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int'
[02:13:49 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:795f65eed59d: avcodec/wavpack: Check float_shift
[02:13:50 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:003cce421da6: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float'
[02:13:51 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:1998147f2ebc: avformat/avidec: Limit formats in gab2 to srt and ass/ssa
[02:13:52 CEST] <cone-477> ffmpeg 03Micah Galizia 07release/3.3:771206c0dbb4: libavformat/http: Ignore expired cookies
[02:13:53 CEST] <cone-477> ffmpeg 03Micah Galizia 07release/3.3:e5e01d24773d: libavformat/hls: Observe Set-Cookie headers
[02:42:02 CEST] <kierank> av500: https://stackoverflow.com/users/1559108/av501
[02:42:06 CEST] <kierank> you have some kind of secret admirer
[04:20:16 CEST] <KGB> [13FFV1] 15dericed opened pull request #67: upgrading to a working group document (06master...06wg-document) 02https://git.io/vHuEK
[06:23:58 CEST] <av500> kierank: !
[09:18:01 CEST] <thebombzen> the copyright date in ffmpeg.c is listed as 2000-2003. is this intentional
[09:18:15 CEST] <thebombzen> specifically it's copyright Fabrice Bellard 2000-2003
[09:18:34 CEST] <thebombzen> should the copyright info be updated?
[09:44:16 CEST] <alevinsn> thebombzen:  That may be correct for Fabrice's involvement
[09:44:28 CEST] <alevinsn> and other people that have worked on this file haven't bothered to alter the copyright statement
[09:51:47 CEST] <ubitux> is AAC PS a subsystem or it belongs in decoders? (tests/checkasm/Makefile)
[09:51:54 CEST] <ubitux> it looks only used by the AAC decoders
[09:51:56 CEST] <ubitux> -s
[09:52:25 CEST] <ubitux> OTOH the dsp init doesn't even explicit aac ("PSDSPContext")
[09:52:41 CEST] <ubitux> it doesn't look used outside of AAC currently, but maybe it could?
[09:53:05 CEST] <ubitux> i see that h264 stuff is actually considered a "subsystem" thing
[09:53:18 CEST] <ubitux> just like flac and vp8
[09:53:32 CEST] <ubitux> are they that much shared that they belong in the "subsystem" category?
[10:00:37 CEST] <ubitux> (lol @ "MMX implied by specified flags" when running aarch64 tests)
[10:05:07 CEST] Action: mateo` starts to add emms_c calls all around the aarch64 codebase
[11:05:10 CEST] <wm4> nevcairiel: "Unable to decrypt message (error 0x80090330) " -> seems like this is SEC_E_DECRYPT_FAILURE
[11:10:00 CEST] <nevcairiel> does that happen with a particular server or something?
[11:12:00 CEST] <wm4> it happens with our media server, but only for 1 user
[11:13:57 CEST] <nevcairiel> is he like on XP or something crazy
[11:14:39 CEST] <wm4> "Windows 7 SP 1"
[11:14:44 CEST] <wm4> so, almost
[11:20:20 CEST] <nevcairiel> without being able to reproduce it, i have no idea
[11:24:55 CEST] <nevcairiel> does it like not work at all for that guy? or is that a random failure?
[11:25:12 CEST] <wm4> doesn't seem to work at all
[11:25:34 CEST] <wm4> the error always happens when it tries to read data from the newly opened https connection, I think
[11:28:28 CEST] <nevcairiel> can anything else access the server over https then? maybe the cert got screwed up?
[11:31:00 CEST] <nevcairiel> i'm not claiming tls_schannel is possibly the most error free code ever, but a single user with a odd problem .. experience shows, it may not be your code =p
[11:31:27 CEST] <wm4> yeah, that's what I'm thinking too
[11:31:42 CEST] <wm4> it worked fine for too many users in too many places
[11:45:51 CEST] <stevenliu> What about add time into line head of every line log?
[11:46:40 CEST] <stevenliu> for example:  [2017-06-02 17:46:32] frame=  137 fps=4.5 q=-1.0 Lsize=    2323kB time=00:00:05.44 bitrate=3497.0kbits/s speed=0.179x
[11:48:30 CEST] <stevenliu> user can recover the problem message from which time (YYYYMMDD hhmmss)
[11:49:03 CEST] <nevcairiel> real time is not necessarly useful for that
[11:51:54 CEST] <stevenliu> some stream is always online, some people pull the stream by ffmpeg, and there have problem sometimes, they maybe need find the problem happend time, be used to seek the error log on server.
[11:52:11 CEST] <stevenliu> they usually run ffmpeg background
[11:52:34 CEST] <stevenliu> or, add an option to control it?
[11:53:00 CEST] <stevenliu> control if they need the real time header?
[11:53:17 CEST] <ubitux> doesn't -report print the time?
[11:54:00 CEST] <ubitux> i'd rather have it in the report, which is what you're supposed to log i think
[11:54:40 CEST] <stevenliu> no, not that mean
[11:55:08 CEST] <stevenliu> ffmpeg-20170603-015319.log   this is time of log file create time?
[11:55:45 CEST] <stevenliu> i mean the context of the log, every line or warning line, or error line
[11:57:41 CEST] <stevenliu> for example:    the line of log "cur_dts is invalid (this is harmless if it occurs once at the start per stream)", if show this log, people maybe need know "what the time dose this problem happend?
[11:59:04 CEST] <stevenliu> add the real time into -report? ubitux
[11:59:37 CEST] <ubitux> i guess
[12:00:02 CEST] <stevenliu> ah, that's a better way :D let me try it 
[12:38:17 CEST] <ubitux> so ld* on lower part of the reg trashes the higher? (aarch64)
[12:39:02 CEST] <ubitux> :(
[12:39:04 CEST] <ubitux> i'm sad :(
[12:43:53 CEST] <stevenliu> Inner peace :)
[12:44:50 CEST] <stevenliu> What about add the time string into av_log_format_line2 ?
[12:45:17 CEST] <stevenliu> or add it into log_callback_report at cmdutils.c ?
[12:45:25 CEST] <nevcairiel> if anywhere it should be in ffmpeg.c or wherever, the log things in avutil are not configurable
[12:46:15 CEST] <wbs> ubitux: yes, most operations on a wX register explicitly clears the upper half of the register
[12:46:47 CEST] <wbs> (which means that it's easy to miss to sign extend registers because the cases where the upper half contains garbage is prety rare)
[12:47:02 CEST] <wbs> but checkasm tests that at least, for anything that is hooked up there
[12:47:26 CEST] <wm4> stevenliu: yeah, I'd also prefer tom put it outside of the libs
[12:47:31 CEST] <wm4> *to
[12:47:53 CEST] <ubitux> wbs: yeah that's how i figured it out (with checkasm)
[12:48:01 CEST] <ubitux> i was reading in lower part of v8
[12:48:41 CEST] <wbs> ah right, for vector registers as well - yes
[12:48:48 CEST] <wbs> you can't treat them as two halves any longer
[12:49:03 CEST] <ubitux> :(
[12:49:23 CEST] <stevenliu> wm4, ok, let me try add it into cmdutils :)
[12:49:42 CEST] <ubitux> in checkasm, what is the purpose of the name argument for check_func()?
[12:49:48 CEST] <ubitux> it doesn't seem to be displayed
[12:50:18 CEST] <wbs> for benchmarking
[12:50:52 CEST] <wbs> if you run with --bench or --bench=<prefix> it will list the names, and only benchmark and list the functions starting with prefix, respectively
[12:51:09 CEST] <ubitux> mmh, ok
[12:51:23 CEST] <ubitux> i can't test --bench right now with qemu it seems
[12:51:30 CEST] <ubitux> i'll try it out on a board
[12:51:31 CEST] <ubitux> thanks
[12:51:43 CEST] <wbs> there's no point in using --bench unless on a real cpu
[12:51:58 CEST] <wbs> and even then, you need to enable user mode access to cycle counters, which you need to do from kernel space
[12:52:02 CEST] <ubitux> except to test how the name is printed :p
[12:52:13 CEST] <ubitux> it was more about testing the bench option more than anything else
[12:53:08 CEST] <wbs> ah, k
[12:53:20 CEST] <wbs> well it will probably still give you a quick SIGILL :P
[12:53:38 CEST] <wbs> testing the string output is probably easier done on an x86 system
[13:07:19 CEST] <ashk43712> Hi, how to get the path of a main/ref video in ffmpeg through filters?
[13:49:11 CEST] <J_Darnley> ashk43712: I doubt you can.
[14:04:55 CEST] <wm4> I doubt you should...
[14:23:39 CEST] <nevcairiel> man this guys reponses are literally unreadable
[14:23:43 CEST] <nevcairiel> how can some mail clients be so crappy
[14:25:00 CEST] <BtbN> Looks like some really bad web mailer or something
[14:25:27 CEST] <BtbN> but yeah, I am unable to find the response in his responses
[14:25:36 CEST] <BtbN> I'll probably just do that patch myself, properly.
[14:25:43 CEST] <BtbN> Use static if available, otherwise shared, otherwise error.
[14:26:09 CEST] <BtbN> But some way to select on specifically would be nice
[14:26:58 CEST] <BtbN> That beeing said... what about just deprecating the scale_npp thing? We have scale_cuda now.
[14:27:01 CEST] <nevcairiel> we dont really allow that for anything, its basically up to you to expose the library you want to link against
[14:27:12 CEST] <nevcairiel> be it shared or static
[14:27:23 CEST] <BtbN> well, libnpp has diffrent names for shared and static
[14:27:28 CEST] <BtbN> and both are available usually
[14:27:47 CEST] <nevcairiel> and yeah, if scale_cuda works equally well, should just get rid of npp
[14:28:15 CEST] <BtbN> libnpp has the algorithm selection thing, but it's broken anyway and most of them just end up with the exact same result
[14:36:14 CEST] <BBB> hmm& https://www.wired.com/2017/06/diversity-open-source-even-worse-tech-overall/
[14:38:11 CEST] <nevcairiel> i think its silly to say "open source has work to do", its not like we block anyone, but should it be our job to lobby to get more women? we should lobby to get competent devs of all types and colors
[14:38:56 CEST] <BtbN> Specially with potentially anonymous open source contributions, nobody really cares
[14:39:12 CEST] <BtbN> Usually projects take any good contribution they can get
[14:39:34 CEST] <Compn> wait
[14:39:48 CEST] <Compn> the article should be complaining about women in the software field at all
[14:40:04 CEST] <Compn> this isnt an open source problem, but closed source as well
[14:40:06 CEST] <BBB> were so perfect :)
[14:40:15 CEST] <BBB> the numbers speak differently, compn
[14:40:20 CEST] <BBB> read the numbers
[14:40:29 CEST] <BBB> or if you disagree with them, thats ok also, but explain why
[14:40:42 CEST] <BBB> but the numbers suggets opensource is worse than software overall
[14:41:30 CEST] <Compn> i see no numbers from closed source companies, BBB
[14:41:38 CEST] <BBB> overall
[14:42:08 CEST] <BBB> Of that randomly selected cohort, a full 95 percent of respondents were male. Only three percent identified as female and one percent as non-binary. According to Bureau of Labor Statistics, about 22.6 percent of professional computer programmers are female.
[14:42:17 CEST] <BBB> 3 and 22.6 are very different
[14:42:33 CEST] <Compn> yes thats the open source and labor numbers
[14:42:36 CEST] <BtbN> "negative interactions such as rudeness", I have never seen a project that's not equally rude to everyone.
[14:42:43 CEST] <Compn> i'm asking about closed source, specifically
[14:43:10 CEST] <BBB> why would closed source be fundamentally different from professional computer programmers overall?
[14:43:12 CEST] <nevcairiel> BtbN: presumably being rude to other males is ok while being rude to females is well .. rude. you know how this goes =p
[14:43:44 CEST] <BBB> anyway, lets not start a fight just yet, we need some matches left for VDD this year ;)
[14:43:47 CEST] <Compn> BBB : hue hue hue
[14:43:58 CEST] <BBB> :D
[14:44:19 CEST] <Compn> BBB :  you've worked at various closed source companies
[14:44:26 CEST] <BBB> I have
[14:44:31 CEST] <Compn> whats the male-female programmer ratio you've personally seen ?
[14:44:35 CEST] <nevcairiel> I also always thought things like Outreachy are the wrong way to go. Isn't it discrimenating against the average male if they can't join such a program just because they are "normal"? :P
[14:44:52 CEST] <BBB> very team-dependent
[14:44:56 CEST] <Compn> nevcairiel : meh, another double standard i dont mind :P
[14:45:00 CEST] <BBB> in my team @ google, I dont think it was 20%, but probably well over 10%
[14:45:14 CEST] <Compn> BBB : overall numbers, count totals
[14:45:24 CEST] <Compn> not per team
[14:45:28 CEST] <BBB> Im pretty sure 20% would not be a bad guess for google
[14:45:40 CEST] <Compn> not bad
[14:45:41 CEST] <Compn> hehe
[14:45:48 CEST] <BBB> but variance is important also, if certain teams are women-only and others are men only, that suggests you didnt really solve the issue
[14:46:02 CEST] <nevcairiel> truth be told, i 've never actually directly worked with a female developer, I saw some in other teams, but its rare
[14:46:09 CEST] <nevcairiel> I know a female sysadmin =p
[14:46:28 CEST] <Compn> i've known a female sysadmin , AND i was rude to her!
[14:46:28 CEST] <thardin> this will change, but fairly slowly
[14:46:43 CEST] <nevcairiel> she is routinely rude to everyone, so its ok!
[14:46:46 CEST] <thardin> the gender distribution in CS does seem to be improving
[14:46:52 CEST] <thardin> partly due to outreach programs
[14:46:58 CEST] <Compn> she only had one eye, so i was also rude to a disabled!
[14:47:10 CEST] <Compn> i dont discriminate in my rudeness :D
[14:47:23 CEST] <BBB> thats not nice at all
[14:47:29 CEST] <nevcairiel> yeah this entire thing has to start in education first, can't expect the numbers in the industry to drastically change before universitys do
[14:47:46 CEST] <Compn> enter the exciting world of .... programming
[14:48:01 CEST] <thardin> yes. but I suspect it has to start much earlier. this all start extremely early. like pre-school early
[14:48:11 CEST] <thardin> sexist bullshit etc
[14:48:18 CEST] <nevcairiel> I think it is exciting, instead i find watching sports rather boring, everyone their own =p
[14:49:11 CEST] <Compn> irc numbers are low as well, for the womens
[14:49:31 CEST] <thardin> depends on the channel
[14:49:31 CEST] <nevcairiel> irc is a dying medium, all the cool kids dont use it anymore
[14:49:38 CEST] <Compn> i take a look at my life and see that a lot of my hobbies and such have low ratios of females hah
[14:49:51 CEST] <J_Darnley> You mean women aren't dumb enough to do labour for free?
[14:50:03 CEST] <BBB> you get paid J_Darnley 
[14:50:04 CEST] <nevcairiel> way to put the fail onto us J_Darnley
[14:50:07 CEST] <thardin> they already do J_Darnley 
[14:50:23 CEST] <Compn> did you just assume my gender?! :P
[14:50:41 CEST] <Compn> hmm maybe is too rude
[14:50:47 CEST] <thardin> edgy
[14:50:50 CEST] <nevcairiel> everyone knows Compn is a genderless Amoeba
[14:51:21 CEST] <J_Darnley> BBB: sure, now
[14:51:26 CEST] <BBB> \o/
[14:51:31 CEST] <BBB> how is the idct?
[14:51:39 CEST] <BBB> making progress? or need help
[14:51:40 CEST] <BBB> ?
[14:51:57 CEST] <J_Darnley> Not right now.
[14:52:41 CEST] <J_Darnley> I tried passing the "right" options to the 10-bit macros but that didn't work so now I am looking more closely.
[14:53:11 CEST] <stevenliu> Women programmer numbers less then men ...
[14:53:55 CEST] <BBB> when you initalize the function pointer, did you set the idct_perm correctly?
[14:54:07 CEST] <stevenliu> there have lots women programmer in China, and use ffmpeg :D 
[14:54:19 CEST] <J_Darnley> Ah, I probably didn't
[14:54:26 CEST] Action: J_Darnley goes to try that again
[14:55:09 CEST] <BBB> J_Darnley: so, you need to set the idct_perm for the sse2 version based on the 10bit macros to the same values as the ones for the 10bit functions, not the one for the mmx2 function you ported earlier
[14:55:39 CEST] <BBB> I Can try to explain but it may be more confusing
[14:56:11 CEST] <J_Darnley> I understand that.  I've seen the different flag.
[14:58:09 CEST] <J_Darnley> Oh wow.  That does work.
[14:58:12 CEST] <BBB> \o/
[14:58:16 CEST] <BBB> very cool
[14:58:18 CEST] <BBB> is it faster?
[14:59:05 CEST] <J_Darnley> Yes, a little
[14:59:19 CEST] <J_Darnley> But I take back the "working" statement.
[14:59:42 CEST] <J_Darnley> The dct test passes but it isn't the same as the C and MMX
[15:00:34 CEST] <J_Darnley> (It is about 40% faster)
[15:00:51 CEST] <J_Darnley> Now I better check the rest of fate.
[15:03:04 CEST] <BBB> the rounding may be a little bit different
[15:03:14 CEST] <BBB> I dont think its hard to fix that
[15:03:33 CEST] <BBB> it can probably be done using the correct macro arguments, but I dont recall exactly how to do that or what they should be
[15:03:49 CEST] <BBB> if you send a patch I can try to fix the rounding
[15:03:56 CEST] <BBB> 40% is pretty great
[15:04:13 CEST] <BBB> esp. because it doesnt optimize for zero in any way (or even dc-only)
[15:04:17 CEST] <J_Darnley> Maybe.  Also two of the coeffs differ by +1 and -1
[15:05:31 CEST] <BBB> coefs?
[15:05:35 CEST] <BBB> you mean residual post-idct?
[15:05:45 CEST] <BBB> or input coefs?
[15:05:57 CEST] <J_Darnley> Input I think.  The constants
[15:06:04 CEST] <BBB> aha
[15:06:06 CEST] <BBB> hm...
[15:06:07 CEST] <J_Darnley> 16383 vas 16384
[15:06:08 CEST] <BBB> thats not good
[15:06:13 CEST] <J_Darnley> and the 22k one
[15:06:19 CEST] <BBB> well that would explain part of the problem
[15:07:50 CEST] <J_Darnley> Oh, I mean the 19k one: 19265 vs 19266
[15:08:54 CEST] <BBB> I bet that if you change the constats, some other fate results break, but does it make the results more compliant?
[15:09:00 CEST] <BBB> (for the mpeg/dct tests)
[15:09:12 CEST] <J_Darnley> They do look closer, yes
[15:14:46 CEST] <BBB> Im suspicious of the rounding
[15:14:55 CEST] <BBB> if you need help, send me a patch and Ill see what I can do
[15:14:57 CEST] <BBB> nice work so far :)
[15:15:17 CEST] <J_Darnley> I will do that today.
[15:15:47 CEST] <J_Darnley> Nice clean patches from the latest master.  Not that horrible crap I showed you before.
[15:17:04 CEST] <BBB> hehehehhe
[15:17:14 CEST] <BBB> we all understand "wip"
[15:17:58 CEST] <J_Darnley> Sigh.  It does break fate.
[15:18:09 CEST] <J_Darnley> I'll still make those patches
[15:18:41 CEST] <BBB> of course it breaks fate, the prores dsp has different hardcoded coefficients
[15:18:45 CEST] <BBB> Im not sure which are more correct
[15:18:57 CEST] <BBB> we can make them different based on codec, thats not a terrible thing to do
[15:47:17 CEST] <mateo`> ubitux: here are you result: http://sprunge.us/beTc 
[15:47:26 CEST] <ubitux> :((
[15:48:12 CEST] <jamrial> huh, that's weird
[15:48:29 CEST] <ubitux> yeah :')
[15:48:36 CEST] <jamrial> stereo_interpolate_neon that ubitux wrote looks exactly the same as the x86 one
[15:48:40 CEST] <jamrial> it can't be slower than c...
[15:48:53 CEST] <ubitux> is it faster on x86? :D
[15:48:57 CEST] <nevcairiel> arm isnt x86, so maybe thats the problem :p
[15:48:59 CEST] <ubitux> oh well, i can test that one :3
[15:49:06 CEST] <ubitux> it may be because of the stores
[15:49:08 CEST] <ubitux> i need to profile
[15:49:30 CEST] <jamrial> i know, but i'd expect the exact same vectorization to be faster than non vectorized c :p
[15:50:57 CEST] <ubitux> stereo_interpolate_c: 28472.8
[15:50:58 CEST] <ubitux> stereo_interpolate_sse3: 13195.6
[15:51:00 CEST] <ubitux> stereo_interpolate_ipdopd_c: 27576.8
[15:51:02 CEST] <ubitux> stereo_interpolate_ipdopd_sse3: 12769.7
[15:51:04 CEST] <ubitux> x86 is indeed faster
[15:51:19 CEST] <kierank> J_Darnley: nice
[15:59:04 CEST] <ubitux> jamrial: isn't the stride missing an extend in ps hybrid analysis? (x86)
[15:59:10 CEST] <ubitux> maybe we should change that to ptrdiff_t
[15:59:18 CEST] <ubitux> i had to extend in the arm
[16:00:35 CEST] <jamrial> ubitux: no, i did shl strided, which zero extends it implicitly
[16:00:46 CEST] <ubitux> ah, interesting, ok
[16:01:27 CEST] <jamrial> but yeah, changing it to prtdiff_t is a good idea in any case
[16:10:08 CEST] <cone-651> ffmpeg 03James Almer 07master:b5a0971ff041: x86/aacps: add ff_ps_stereo_interpolate_ipdopd_sse3()
[16:10:32 CEST] <jamrial> i forgot i hadn't push that
[16:11:25 CEST] <atomnuker> jamrial: how much overall % did that improve aac decoding speed?
[16:11:37 CEST] <ubitux> oh i'm an idiot i was testing the same function
[16:11:47 CEST] <nevcairiel> you are hardpressed to even find a file that uses ipdopd :p
[16:12:00 CEST] <jamrial> was going to say :p
[16:12:22 CEST] <jamrial> there's like all of one sample that i knows uses it
[16:14:03 CEST] <jamrial> ubitux: do you have a repo with the aacps checkasm tests you wrote?
[16:14:19 CEST] <ubitux> yes, just a moment i'll push a fix for ipdopd
[16:14:32 CEST] <jamrial> sure
[16:15:01 CEST] <ubitux> aarch64-aac on github/ubitux/ffmpeg
[16:15:43 CEST] <ubitux> note: it doesn't test exactness yet, but benchmarking works
[16:16:00 CEST] <mateo`> ubitux: should i run the tests again ?
[16:16:18 CEST] <ubitux> mateo`: sure, you can shame me as much as you want :3
[16:16:36 CEST] <ubitux> i'd love a perf record+report on the slow functions though
[16:17:10 CEST] <mateo`> i thought you had a fix, anyway i'll do the record+report
[16:17:15 CEST] <ubitux> jamrial: 
[16:17:17 CEST] <ubitux> ps_stereo_interpolate_c: 27760.5
[16:17:19 CEST] <ubitux> ps_stereo_interpolate_sse3: 13162.2
[16:17:21 CEST] <ubitux> ps_stereo_interpolate_ipdopd_c: 57883.0
[16:17:23 CEST] <ubitux> ps_stereo_interpolate_ipdopd_sse3: 21136.0
[16:17:45 CEST] <ubitux> mateo`: the "fix" was just about checking the correct function for ipdopd
[16:26:32 CEST] <jamrial> ps_add_squares_sse: 4184.9
[16:26:33 CEST] <jamrial> ps_add_squares_sse3: 4183.8
[16:26:39 CEST] <jamrial> bah
[16:27:01 CEST] <jamrial> so much for haddps :p
[16:27:44 CEST] <Gramner> horizontal adds are slow¨
[16:28:34 CEST] <jamrial> i know, but this one was a case where haddps was perfect
[16:28:38 CEST] <Gramner> haddps is essentially two shuffles and one addition on most cpus
[16:29:21 CEST] <Gramner> no idea why they never bothered to optimize them. should've been trivial in hardware
[16:29:55 CEST] <Gramner> instead they removed those instructions completely in EVEX
[16:31:21 CEST] <Gramner> they're basically only useful for some slight code size reduction when they happen to do exactly what you want
[16:40:10 CEST] <BBB> they removed them?
[16:40:11 CEST] <BBB> bah
[16:40:21 CEST] <BBB> I like hadds
[16:40:29 CEST] <BBB> (in some situations)
[16:41:05 CEST] <J_Darnley> Removed them?  They now/will be illegal instructions?
[16:50:30 CEST] <Prelude2004c> hey guys.. sorry didn't get answers in the regular channels. Does ffmpeg currently support key rotation for AES key ? I want to change up key say ever 1 hour without having to restart the transcoding. Is it as simple as just modifying the keyfile ? how does ffmpeg know to create new key entry in the m3u8 ?
[16:56:07 CEST] <DHE> Prelude2004c: still not appropriate to ask in this channel
[17:15:40 CEST] <ubitux> jamrial: moving the zips out of the loop helped
[17:15:57 CEST] <ubitux> at least i'm faster now
[17:16:20 CEST] <ubitux> so i basically replace 2 zip with 1 add in the inner loop
[17:16:44 CEST] <ubitux> with the tradeoff of requiring one more reg, and 4 zip in the init
[17:17:01 CEST] <ubitux> dunno if you do that already in the x86
[17:18:09 CEST] <Prelude2004c> Anyone here want to do a bit of dev. work with me on ffmpeg ? need an expert ffmpeg guy .. Message me privately. 
[17:18:27 CEST] <Prelude2004c> normally i work with UPWORK
[17:19:58 CEST] <Gramner> J_Darnley: removed as in they don't have any EVEX-encoded version so you can't use them with zmm registers or with (x|y)mm16-31
[17:20:09 CEST] <Gramner> I'm more annoyed that they removed psign*
[17:20:36 CEST] <Gramner> legacy versions will still work
[17:25:48 CEST] <Gramner> fwiw google compute engine now have skylake xeons publically available if you want to do avx-512 stuff and don't have such a cpu of your own yet
[17:27:42 CEST] <nevcairiel> i'm somewhat happy it appears they have avx512 in the skylake-x cpus, although apparently they were not quite clear yet if there is a avx512 unit per core or a central shared one
[17:31:19 CEST] <DHE> I didn't know they were for sale yet... I thought they were still months out
[17:31:31 CEST] <Gramner> doing off-core per-instruction computations would result in horrible latencies and is totally unfeasible
[17:31:57 CEST] <Gramner> they're not for sale, but you can rent them as a cloud VM from google
[17:32:07 CEST] <nevcairiel> yeah it sounded odd, but some people t hat otherwise seemed smart about such things said something to that effect
[17:32:19 CEST] <nevcairiel> review NDA lifts next week, i think
[17:32:36 CEST] <jamrial> ubitux: i don't, but just tried that and it's indeed faster :D
[17:32:42 CEST] <ubitux> :)
[17:32:59 CEST] <ubitux> i'm still slower on the ipodpdpdpd
[17:33:11 CEST] <ubitux> but anyway, i'll dig that later
[17:33:35 CEST] <Gramner> feel free to ask me whatever once the NDA ends. I've had one for months
[17:36:30 CEST] <Gramner> although I think it's kind of silly to have NDA on things anyone can already rent and use. but I guess that's how it is
[17:39:57 CEST] <atomnuker> that's just stupid
[17:40:23 CEST] <atomnuker> what's to stop anyone from reviewing it anyway? not like they can trace it
[17:40:51 CEST] <atomnuker> unless they encode serial number as an arbitrary 1-cycle delay on instructions
[17:41:07 CEST] <nevcairiel> those people get free samples, and that would be the last time, so serious reviewers wouldnt
[17:42:57 CEST] <atomnuker> wait, are they reviews for intel or reviews for normal people?
[17:44:10 CEST] <nevcairiel> often it feels like the NDAs just exist to give everyone a decent chance to finish a decent review, instead of rushing half-assed things out to be the first to have it online
[17:45:16 CEST] <atomnuker> does it take months to write a decent review?
[17:45:41 CEST] <Gramner> afaik there's no NDA to what you can rent from google so you are free to run whatever benchmarks you want there.
[17:45:54 CEST] <Gramner> reviewers dont have them for months
[17:46:00 CEST] <Gramner> more like a week or so
[17:46:18 CEST] <Gramner> although it can probably vary a lot from product to product
[17:46:21 CEST] <nevcairiel> the xeons also  dont really get that much reviewer attention then the consumer CPUs, ie. the skylake-x announced last week
[17:48:27 CEST] <atomnuker> does amd do that?
[17:48:43 CEST] <Gramner> well yeah, xeons are aimed at data centers and the people in charge of their purchasing decisions don't just buy whatever got good reviews in the latest magazine
[17:49:47 CEST] <nevcairiel> as silly as it may be, datacenters are more likely to just blindly buy from spec sheets =p
[19:19:56 CEST] <wm4> "This is a bug in the edit list fix index code. " hehe
[19:20:12 CEST] <kierank> yeah big lol
[19:20:25 CEST] <nevcairiel> just one? :)
[20:05:46 CEST] <J_Darnley> Gramner: I see, thanks.  (Re: horizontal adds)
[20:16:41 CEST] <kevmark> <@BBB> kevmark: cehoyos will probably close it
[20:16:46 CEST] <kevmark> Thanks for the heads up
[20:27:43 CEST] <BBB> did he close it?
[20:27:55 CEST] <BBB> kevmark: ^
[20:28:19 CEST] <kevmark> BBB, not yet, no
[20:28:36 CEST] <BBB> whats the link?
[20:28:38 CEST] <BBB> I can close it for you
[20:28:40 CEST] <kevmark> https://trac.ffmpeg.org/ticket/5392
[20:28:50 CEST] <BBB> what commit fixed it?
[20:29:10 CEST] <kevmark> michaelni asked for an accompanying fate test so perhaps cehoyos is waiting on that?
[20:29:21 CEST] <BBB> no, the bug tracker is just for bugs
[20:29:33 CEST] <BBB> I mean, I agree a fate test would be a good idea
[20:29:39 CEST] <kevmark> 3385989b98be7940044e4f0a6b431a0a00abf2fa https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/3385989b98be7940044e4f0a6b431a0a00abf2fa
[20:29:42 CEST] <BBB> but if the bug is fixed in and by itself, the bug should be closed
[20:30:20 CEST] <michaelni> kevmark, i can add you to the list of developer n trac then you can close it yourself
[20:30:28 CEST] <michaelni> also anyone else that needs to be added ?
[20:30:31 CEST] <BBB> I already closed it
[20:30:31 CEST] <kevmark> Gotcha. There was a short discussion in the patch thread about if the behavior was truly a "bug" or not, but at this point it's not much of an issue
[20:30:49 CEST] <BBB> but if he wants to be added Im fine with that also
[20:31:19 CEST] Action: BBB kicks fflogger
[20:31:29 CEST] <BBB> kinda slow today...
[20:31:58 CEST] <kevmark> michaelni, sure, I'd have no issue with that
[20:32:04 CEST] <kevmark> Register first?
[20:32:27 CEST] <kevmark> Nice anti spam filter
[20:32:57 CEST] <michaelni> long ago i remember going over all user accounts and added everyone i recognized as having contributed but i think the number of accounts is a bit large these days
[20:34:04 CEST] <kevmark> GitHub claims 883 total contributors on the project
[20:34:07 CEST] <kevmark> Username is kmark
[20:36:24 CEST] <michaelni> kevmark, added
[20:36:28 CEST] <kevmark> ty
[20:37:44 CEST] <kevmark> I respect that you give developer permissions on the tracker to those who contribute. I've always been wary to do that myself.
[20:38:35 CEST] <michaelni> ffmpeg trac has 4899 registered users btw
[20:41:23 CEST] <kevmark> That's pretty good although I'm not too surprised since you need an account there to add a ticket
[21:10:26 CEST] <philipl> BtbN: fix for bframes seems obvious in retrospect.
[21:12:24 CEST] <BtbN> well, they don't have a context bound there in any of their own examples
[21:15:58 CEST] <philipl> Yeah. They were very unclear about context usage.
[21:16:33 CEST] <BtbN> this could also have been settles within a single mail of them telling us to bind a context
[21:17:03 CEST] <BtbN> Also, not entirely happy with the patch, it looks rather uggly. With that many calls, it almost needs a wrapper
[21:17:17 CEST] <BtbN> it's always the same few lines, could just be a mcro
[21:17:20 CEST] <BtbN> *macro
[21:17:44 CEST] <BtbN> Anyway, going to apply it as-is, and fix that later.
[21:23:46 CEST] <BtbN> philipl, also, I don't understand how this happened to work before the change of the initialization order
[21:23:53 CEST] <BtbN> I confirmed multiple times that no CUDA context leaks
[21:24:03 CEST] <BtbN> it also works with frames supplied by hwupload_cuda
[21:37:27 CEST] <cone-651> ffmpeg 03Ganapathy Kasi 07master:43c417ac1adb: avcodec/nvenc: fix hw accelerated transcode with bframes
[21:50:53 CEST] <cone-651> ffmpeg 03Ganapathy Kasi 07release/3.3:9b351d0d888d: avcodec/nvenc: fix hw accelerated transcode with bframes
[21:51:44 CEST] <philipl> BtbN: undefined behaviour working out in our favour
[00:00:00 CEST] --- Sat Jun  3 2017