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

Fri Jun 23 03:05:04 EEST 2017

[00:00:24 CEST] <atomnuker> durandal_170: seems I dirty my output somewhere
[00:01:10 CEST] <atomnuker> OH, NEVERMIND
[00:01:41 CEST] <atomnuker> I gave the function the original twiddles
[00:01:46 CEST] <atomnuker> fate passes
[00:04:10 CEST] <BBB> jamrial: thats hilarious :D
[00:05:08 CEST] <jamrial> BBB: what, msvc and nasm not being nice to each other?
[00:05:34 CEST] <BBB> that netbsd error
[00:05:38 CEST] <jamrial> oh
[00:05:54 CEST] <jamrial> more like annoying, though :p
[00:07:10 CEST] <BBB> kind of, yes
[00:07:33 CEST] <jamrial> guess it's some bash problem in netbsd. it's printing the contents meant for the .d file to strerr
[00:08:03 CEST] <jamrial> or something like that. i can't really test...
[00:35:27 CEST] <atomnuker> patch for fft15 asm sent to the ML
[00:36:45 CEST] <atomnuker> this was quite fun to write, not nearly as impossible as I thought it would be
[00:38:53 CEST] <iive> hum
[00:40:51 CEST] <atomnuker> the reason why I shuffle the twiddles is because I went one way first, rewrote the C code to use it and realized it wasn't good at all
[00:41:12 CEST] <atomnuker> and now its too complicated to untangle and go directly to what they have to be
[00:42:00 CEST] <iive> movddup that the asm starts with, doesn't do what the commends say, and you do use xmm register.
[00:42:21 CEST] <iive> it loads a single double into both parts of the register.
[00:43:11 CEST] <atomnuker> its not a double, its 2 floats
[00:43:43 CEST] <atomnuker> saves a shuffle
[00:44:23 CEST] <iive> some cpu track the float double status...
[00:44:44 CEST] <iive> even so, it still doesn't do what the comment says
[00:45:37 CEST] <iive> it would load in[0].rq/im in high and low
[00:50:45 CEST] <atomnuker> okay, the comment is wrong
[00:51:36 CEST] <iive> next comment is also wrong
[00:52:10 CEST] <iive> you load only the low part of the register and store 0 in the high, don't you?
[00:52:57 CEST] <atomnuker> yes
[00:53:08 CEST] <atomnuker> the comments were made back when all loads there were movups
[00:53:31 CEST] <atomnuker> in hindsight only movddup makes a difference
[00:54:00 CEST] <atomnuker> movups and movsd have the same performance on my cpu
[00:55:07 CEST] <iive> there is severe penatly on older cpu if you cross cache line (64 byte)
[00:55:57 CEST] <iive> also, shuffle is mostly 1 cycle on anything newer than p4...
[00:56:25 CEST] <atomnuker> well, this is avx2 only (since anything that does fma3 will support avx2)
[00:56:36 CEST] <atomnuker> no reason not to save a shuffle though
[00:57:38 CEST] <atomnuker> its possible to do the butterflies with 128bit regs but you'll need all 16 regs
[00:59:45 CEST] <iive> i haven't looked into fma stuff closely, but I think this function could easily be done with sse2 only :P
[01:00:13 CEST] <atomnuker> patches accepted after it gets merged
[01:00:37 CEST] <iive> :D
[01:02:20 CEST] <iive> random nitpick, imul r4q,2 ; maybe use shift to left. or lea
[01:05:32 CEST] <iive> another minor nitpick, could you number the macro arguments (in the comment) with 7 of them it is fairly easy to lost count :D
[01:07:03 CEST] <atomnuker> yeah, I'll just move the description at the line above
[01:07:37 CEST] <atomnuker> (by that I mean I'll add a new line above with numbers)
[01:08:15 CEST] <atomnuker> it is easy to lose count especially since macros are 1-indexed rather than 0 indexed
[01:08:30 CEST] <atomnuker> its annoying, who thought to do that?
[01:10:37 CEST] <iive> masm?
[01:12:24 CEST] <iive> btw, fma3 does not imply avx2, x86inc does the opposite (I think)
[01:12:56 CEST] <iive> your code specifies fma3
[01:14:21 CEST] <jamrial> avx2 implies fma3, but fma3 does not imply avx2, yeah
[01:16:47 CEST] <iive> avx2 is mostly integer ops, and gather
[01:18:18 CEST] <iive> perm and broadcast
[01:34:11 CEST] <atomnuker> so what do I do?
[01:34:16 CEST] <atomnuker> is it correct or not?
[01:36:04 CEST] <jamrial> atomnuker: yes, you're not using any avx2 instructions
[01:37:21 CEST] <J_Darnley> I don't know about newer instructions but x264asm will warn you if you use an sse4 instruction when you only specify sse2, for example.
[01:37:55 CEST] <iive> unfortunately it doesn't overload avx2 instructions
[01:38:06 CEST] <iive> so you won't get warning for them.
[01:38:29 CEST] <iive> it might complain that you are not using  the v* prefix... but
[01:38:50 CEST] <iive> that's only if the legacy form is forbidden for new avx2 ops
[01:39:56 CEST] <J_Darnley> Well I guess you can ignore me
[01:43:58 CEST] <jamrial> J_Darnley: that's what iive said, it doesn't work on avx+ instructions
[01:44:40 CEST] <iive> J_Darnley: no worries :)
[01:45:37 CEST] <iive> i think it works on avx1
[01:53:18 CEST] <iive> atomnuker: final nitpick (for today). if you expect your register size to be 256bit, then it might be better idea to use the ym0 form, instead of m0
[01:53:35 CEST] <iive> the idea is that m0 is sued when the code could handle any size.
[01:53:56 CEST] <iive> sued/used
[01:59:54 CEST] <jamrial> iive: no need to do that, he initialized the function with INIT_YMM and is not changing it in the middle of it
[02:00:21 CEST] <iive> it's just semantics.
[02:00:33 CEST] <iive> that's why i said it is a nitpick, nothing major.
[02:48:04 CEST] <atomnuker> jamrial: nope, seems like doing 2 loads instead of a single load + vextractf128 is just slightly slower
[02:48:22 CEST] <jamrial> i see. alright then
[03:05:14 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:5a950f4e32a9: avcodec/cfhd: Fix undefined shift
[03:05:14 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:6f1d2355a7e4: avcodec/cfhd: Check bpc before setting bpc in context
[03:37:55 CEST] <cone-971> ffmpeg 03Anton Mitrofanov 07release/3.1:8ead0d380674: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4
[03:37:56 CEST] <cone-971> ffmpeg 03Anton Mitrofanov 07release/3.1:ac86dc7716bf: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264
[03:37:57 CEST] <cone-971> ffmpeg 03Anton Mitrofanov 07release/3.1:70b714792649: avcodec/h264: Fix mix of lossless and lossy MBs decoding
[03:37:58 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:5cd693fd426b: avcodec/htmlsubtitles: Replace very slow redundant sscanf() calls by cleaner and faster code
[03:37:59 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:1124df46393b: avcodec/aacdec_fixed: Check s for being too small
[03:38:00 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:48b0e94a6cb5: avcodec/wavpack: Fix undefined integer negation
[03:38:01 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:feefeb4df1c1: avcodec/lpc: signed integer overflow in compute_lpc_coefs() (aacdec_fixed)
[03:38:02 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:af1f0f815b9a: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation
[03:38:03 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:fc30465bcb35: avcodec/hevc_filter: Fix invalid shift
[03:38:04 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:46842f6de995: avcodec/cfhd: Fix undefined shift
[03:38:05 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:9c52cf95ee35: avcodec/cfhd: Check bpc before setting bpc in context
[03:38:06 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:a2d9595a4b4e: Changelog: update
[04:04:09 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07n3.1.9:HEAD: avcodec/cfhd: Check bpc before setting bpc in context
[10:31:43 CEST] <cone-632> ffmpeg 03Matthieu Bouron 07master:067e42b851a7: checkasm/aarch64: fix tests returning a float
[11:20:17 CEST] <wm4> does anyone have an idea why DBL_EPSILON seems to be missing there? https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/crt/float.h
[11:20:24 CEST] <wm4> some filters require this
[11:20:33 CEST] <wm4> though it seems C99 should provide it anyway
[15:20:47 CEST] <BBB> j-b: what are the plans for vdd17?
[16:04:32 CEST] <j-b> BBB 3rd weekend of September, paris.
[16:05:26 CEST] <BBB> 16-17?
[16:05:40 CEST] <BBB> ok very good
[16:06:19 CEST] <BBB> I guess I should look into av1 at this point
[16:06:24 CEST] <BBB> but its sooooo slow
[16:07:11 CEST] <j-b> no
[16:07:17 CEST] <j-b> 23-24
[16:07:39 CEST] <j-b> IBC is 14-19
[16:07:41 CEST] <JEEB> BBB: yea I've been meaning to run some tests :V
[16:07:52 CEST] <JEEB> but the speed and not yet specified format
[16:08:02 CEST] <JEEB> unless they froze the bit stream while I wasn't looking :D
[16:08:21 CEST] <nevcairiel> no they postponed the freeze
[16:08:29 CEST] <JEEB> ah
[16:08:45 CEST] <JEEB> I only noticed the new MPEG format when I found a dude talking about it @ NHK
[16:09:04 CEST] <BBB> ah they have an annexb style format now?
[16:09:25 CEST] <BBB> so sad, I like ivf
[16:09:36 CEST] <BBB> now we have to do escaping :(
[16:09:56 CEST] <BBB> will they at least not require escaping when you use a real container?
[16:10:06 CEST] <BBB> i.e. move escaping into the annexb instead of into the codec
[16:10:10 CEST] <JEEB> I'd be surprised if that wasn't the case
[16:10:21 CEST] <JEEB> we have containers to keep things sane
[16:10:35 CEST] <BBB> dude, they messed up so often with h26x that its not even funny anymore
[16:10:41 CEST] <JEEB> true
[16:10:47 CEST] <nevcairiel> being able to find startcodes in arbitrary streams is an advantage if you want your format to see widespread usage
[16:10:47 CEST] <BBB> every time Im like theyll get it right this time and every time its as bad as before
[16:11:21 CEST] <JEEB> well, isn't 14496-15's AVCc format pretty much the one where you remove the start code insanity?
[16:11:26 CEST] <JEEB> unless it's some other insanity
[16:15:01 CEST] <BBB> from what I recall, the escaping is still there
[16:15:04 CEST] <BBB> I dont mind the startcode
[16:15:08 CEST] <BBB> I mind the escaping :)
[16:16:25 CEST] <nevcairiel> well the one exists because of the other
[16:16:55 CEST] <nevcairiel> but yeah even mp4 format requires escaping
[16:17:43 CEST] <DHE> regarding that QSV ticket just there, I want to reply with "You have it backwards. The -level parameter is to constrain the parameters to meet a maximum, not to raise the parameters to meet a minimum."
[16:17:54 CEST] <DHE> That's how it works, right? It's what libx264 does
[16:31:55 CEST] <jamrial> ubitux: nasm in djgpp doesn't like section rodata aligned to anything but the default, so unless someone cares enough to find out how to fix x86inc for it, I'd say make that fate client force the usage of yasm
[16:35:03 CEST] <BBB> nevcairiel: were going in circles ;)
[16:35:29 CEST] <BBB> nevcairiel: I understand all that, but in reasonable containers and/or delivery systems, we dont need escaping (or start codes)
[16:35:35 CEST] <BBB> I dont care about start codes
[16:35:39 CEST] <BBB> keep them, remove them, whatever
[16:35:44 CEST] <BBB> I care about escaping, because its stupid
[16:36:16 CEST] <BBB> (in that scenario)
[16:36:45 CEST] <BBB> I also understand theres scenarios where escaping is useful, so allow it at the annexb level only for those circumstances, and allow unescaped content in other scenarios :)
[17:40:38 CEST] <ubitux> jamrial: mmh okay
[18:08:37 CEST] <atomnuker> jamrial: I don't think it would be worth replacing the haddps in BUTTERFLIES_DC
[18:09:01 CEST] <iive> atomnuker: don't assume, test it.
[18:09:24 CEST] <atomnuker> 2 adds and a few shuffles can't be less performant than an haddps
[18:09:31 CEST] <jamrial> atomnuker: two are worth removing, one can probably stay
[18:10:06 CEST] <atomnuker> grr, I'll redo the DC twiddles and try to do it like the AC butterflies
[18:10:17 CEST] <iive> atomnuker: on my cpu 2 haddps are slower than 2 shifts and 2 addps
[18:10:51 CEST] <atomnuker> what CPU do you have?
[18:11:36 CEST] <iive> i've complained before, from intel making nice new ops that work slower than equivalent code :D
[18:11:41 CEST] <iive> atomnuker: just test it.
[18:12:21 CEST] <jamrial> atomnuker: try https://pastebin.com/k4adeh3e
[18:12:47 CEST] <jamrial> that's one that can be removed and is going to be faster
[18:12:57 CEST] <iive> also, the xor idea is quite good. xor are very fast and your cpu could probably do 4 in a single cycle.
[18:13:25 CEST] <atomnuker> oh yeah, that too
[18:13:44 CEST] <atomnuker> how does an xor invert the sign?
[18:14:09 CEST] <atomnuker> doesn't it just remove the sign bit? I need to invert the sign too
[18:14:32 CEST] <iive> "and" would remove the sign, "or" would add it.
[18:14:44 CEST] <iive> xor inverts it.
[18:14:56 CEST] <iive> 0 x 1 -> 1
[18:15:04 CEST] <iive> 1 x 1 -> 0
[18:15:54 CEST] <jamrial> atomnuker: https://pastebin.com/FGnAaeFs this removes two haddps
[18:16:07 CEST] <jamrial> the other can also be removed, probably
[18:17:26 CEST] <atomnuker> whoa
[18:17:53 CEST] <iive> is that the sound of a benchmark going though the roof :D
[18:19:29 CEST] <atomnuker> pretty much, thanks, that saved around 80 decicycles
[21:14:05 CEST] <cone-632> ffmpeg 03James Almer 07master:505cb8e390f2: avformat/oggenc: check for stream private data in ogg_free()
[22:09:14 CEST] <BBB> michaelni: can you respond faster to the idct-related patches? youre the single person holding them up so Id like to move them forward
[22:09:54 CEST] <BBB> michaelni: e.g. for vf_spp, if you want to extend avdct to do that in other ways - go for it, but it shouldnt block idct-related patches as-is because avdct design is totally unrelated to the idct implementations
[22:10:38 CEST] <durandal_1707> spp nobody uses
[22:19:54 CEST] <kevmark> BBB, looks like push access isn't in the cards for now (according to the M/L) but thanks for the suggestion anyway. I'll just ping my patches once they get stale.
[22:20:02 CEST] <BBB> sgtm
[22:20:19 CEST] <BBB> Im happy to push patches, and am usually fairly pokeable (?)
[22:21:28 CEST] <kevmark> Haha, I'll keep that in mind. Nothing I'm patching is particularly urgent but at the same time nothing particularly complex. I found that the scale2ref filter was nearly useless and I've just been working on stuff from there
[22:28:29 CEST] <kevmark> I'm getting ERR_CERT_REVOKED in Chrome 61 for ffmpeg.org's cert. Anybody else?
[22:29:28 CEST] <JEEB> it's a startcom cert so I am not surprised
[22:29:35 CEST] <jamrial> works fine for me on firefox, but a week or so ago someone mentioned the cert was raising alarms on some ssl checker
[22:29:48 CEST] <jamrial> because, yeah, startcom
[22:29:51 CEST] <JEEB> yea, mozilla and google will be blocking it soon
[22:29:52 CEST] <kevmark> I think I was there for that
[22:30:19 CEST] <jamrial> time to hit up letsencrypt i guess
[22:30:53 CEST] <JEEB> that's a good idea
[22:30:59 CEST] <kevmark> GlobalSign is also an option if the 3 month expiry isn't palatable
[22:31:21 CEST] <JEEB> crontab entry should keep the cert nicely around
[22:31:39 CEST] <JEEB> so the 3 months thing shouldn't be a problem
[22:32:02 CEST] <kevmark> Kinda :P
[22:32:31 CEST] <JEEB> the only issues are pieces of software that think that warning you about certs going out in 2-3 months is a good idea :)
[22:32:44 CEST] <JEEB> I think outlook or so herp a derp about that?
[22:32:45 CEST] <JEEB> some MS tool
[22:33:02 CEST] <kevmark> Not sure, I knew a few tools didn't like the chain for LE but that might've been handled now
[22:33:20 CEST] <kevmark> I've been using 15 3 * * * root /usr/bin/certbot renew --quiet --renew-hook "/bin/systemctl reload nginx"
[22:33:22 CEST] <JEEB> LE's chain should be OK. they're hooking onto another CA which is how they got up
[22:33:31 CEST] <JEEB> kevmark: very similar to mine
[22:33:45 CEST] <JEEB> also I thought you needed restart for cert updates?
[22:34:03 CEST] <kevmark> JEEB, I don't /think/ so, but I'll be honest that I never checked
[22:34:07 CEST] <kevmark> I can try real quick
[22:34:45 CEST] <durandal_1707> Compn: hey, gonna add gremlin codecs to mplayer?
[22:35:18 CEST] <Compn> what codecs ?
[22:35:21 CEST] <Compn> my power just died lol
[22:35:27 CEST] <kevmark> I tried the nginx plugin for certbot but it doesn't seem to work very well at all. Best way seems to be to point servers to the live certificate locations and then do a certbot renew and restart server
[22:36:23 CEST] <JEEB> kevmark: yea I chose the same way. if you have a scriptable DNS thing that's another way
[22:36:29 CEST] <JEEB> that way no config needs to be touched
[22:36:38 CEST] <durandal_1707> Compn: gdv gremlin digital video and gremlin dpcm, needs demuxer hack probably
[22:37:28 CEST] <Compn> wheres codecs and samples? sorry i wasnt paying attention
[22:38:02 CEST] <durandal_1707> Compn: on wiki.multimedia.cx use search
[22:38:08 CEST] <kevmark> JEEB, According to this ( https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html ) Chrome was going to keep trusting certs until the ones that were already issued had expired. I guess something happened that moved up their timetable.
[22:39:22 CEST] <Compn> you know, untrusting certs is going to bite the internet in the ass
[22:39:34 CEST] <Compn> so many websites i've been denied to access because of cert time date problems
[22:39:49 CEST] <Compn> which is why i dont use chrome anymore.
[22:40:08 CEST] <kevmark> Apple and Mozilla both implemented a similar policy fwiw
[22:40:26 CEST] <atomnuker> jamrial: fixed most things you mentioned, sent a v2 of the patch
[22:41:17 CEST] <jamrial> mozilla apparently still honors certs that were issued before startcom went full retard, though
[22:42:07 CEST] <kevmark> So does Apple. But they've both said that they reserve the right to deviate from the plan
[22:42:32 CEST] <kevmark> So they could follow suit any day now
[22:45:51 CEST] <Compn> so this is how the internet dies, cert wars
[22:49:01 CEST] <BBB> michaelni: still sounds like an enum to me :-p so would you like me to add an enum to avdct as public api?
[22:49:13 CEST] <BBB> michaelni: I _personally_ prefer the checksum approach TBH
[22:49:31 CEST] <kevmark> JEEB, According to this https://nginx.org/en/docs/control.html I think a reload would be sufficient. Potentially zero downtime as the current requests are served with the old certs and new requests get fresh nginx processes with new certs
[22:49:32 CEST] <BBB> e.g. a crc of the permtable in vf_spp to check against
[22:49:49 CEST] <BBB> michaelni: that wouldnt need changes to avdct and is fairly safe I think, WDYT?
[22:51:57 CEST] <JEEB> kevmark: would make sense
[22:55:38 CEST] <kevmark> Looks like Apache works in the same way (graceful is reload) https://httpd.apache.org/docs/2.4/stopping.html
[22:56:45 CEST] <wm4> would anyone mind if we changed the TLS improper disconnection error messages to verbose level? (CC wbs)
[23:03:35 CEST] <wbs> wm4: if you can limit it only to that case and not all tls errors, then +1 from me
[23:04:40 CEST] <wm4> yeah I think there's even a special error code for that for gnutls, though didn't check
[23:05:57 CEST] <michaelni> BBB, if you like the checksum more, lets go with the checksum.
[23:06:09 CEST] <BBB> do you like it also?
[23:06:17 CEST] <wm4> also the fucking fuck? https://github.com/FFmpeg/FFmpeg/pull/153#pullrequestreview-45843387
[23:06:23 CEST] <michaelni> iam fine with either
[23:06:45 CEST] <BBB> ok
[23:09:09 CEST] <BBB> wm4: lol :D how did he get write access to approve pull requests?
[23:09:45 CEST] <atomnuker> BBB: approve == "+1"
[23:09:56 CEST] <atomnuker> some newfangled github thing
[23:11:10 CEST] <wm4> no idea
[23:11:18 CEST] <wm4> maybe anyone can become a reviewer
[23:14:43 CEST] <durandal_1707> we got hacked!
[23:17:24 CEST] <BBB> Ill go spam-approve anything I hate
[23:18:28 CEST] <durandal_1707> huh? like what?
[23:19:10 CEST] <BBB> durandal_1707: just joking
[23:38:29 CEST] <cone-632> ffmpeg 03Rostislav Pehlivanov 07master:7e98da9c4f42: opus_celt: do not use double precision exp2
[00:00:00 CEST] --- Fri Jun 23 2017