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

[burek]

[00:13:40 CEST] <atomnuker> jamrial: what alignment should I use? 16
[00:14:02 CEST] <jamrial> 16 is default and impled, so just don't write any number
[00:14:39 CEST] <atomnuker> also, isn't the function avx2?
[00:14:46 CEST] <atomnuker> rather than avx?
[00:15:26 CEST] <atomnuker> I'm confused on the whole avx2 and avx matter
[00:15:35 CEST] <atomnuker> which one does 256bit registers?
[00:15:36 CEST] <nevcairiel> you wrote float code, so hopefully avx? x86inc should yell at you if you use instructions that are not in that instruction set
[00:15:37 CEST] <iive> atomnuker: it's like sse1 vs sse2
[00:15:45 CEST] <nevcairiel> atomnuker: both, avx is fl oat, avx2 is integer
[00:15:50 CEST] <iive> avx1 have only float point 256 registers
[00:15:51 CEST] <nevcairiel> (in broad general terms)
[00:16:54 CEST] <iive> nevcairiel: if x86inc doesn't overload avx2, then it won't tell you if you use it improperly
[00:18:12 CEST] <nevcairiel> maybe it only does that for sse thingys
[00:20:02 CEST] <jamrial> atomnuker: avx added ymm regs that can be used for float instructions. avx2 added the possibility to use the ymm regs on integer instructions
[00:20:28 CEST] <jamrial> you're only using float instructions, so they work on any avx cpu
[00:21:33 CEST] <jamrial> fma3 adds the fused multiply add instructions, and is available on less CPUs than avx
[00:22:05 CEST] <atomnuker> confusing, I thought avx2 to be a superset of avx
[00:22:17 CEST] <iive> it is
[00:22:26 CEST] <jamrial> it is. it adds stuff on top of avx
[00:22:34 CEST] <atomnuker> and I thought avx added 256bit regs but without any instructions which actually did 256bit regs
[00:22:42 CEST] <nevcairiel> what would be the point of that :D
[00:22:45 CEST] <jamrial> why would it do that? :P
[00:22:47 CEST] <iive> btw, sse1 also lacked integer ops for 128 registers
[00:23:54 CEST] <nevcairiel> at least with avx512 they did float and int on the same cpu right away - even though its technically split into different feature sets, no cpu (so far) only implements one of them and not the other
[00:44:54 CEST] <atomnuker> jamrial: ok, patch v3 sent, all should be good now
[01:22:16 CEST] <rcombs> nevcairiel: never mind how the avx512 feature sets are a mess
[01:24:07 CEST] <rcombs> wm4: someone with the relevant access should lock that PR's thread; there's no productive discussion to be had in there
[01:24:52 CEST] <wm4> maybe jamrial 
[01:37:24 CEST] <jamrial> wm4: i have no control over the github mirror
[01:38:12 CEST] <wm4> oh
[01:38:43 CEST] <nevcairiel> rcombs: the only thing that really matters is what cpus they actually make (also, just ignore the knights landing stuff)
[01:39:08 CEST] <wm4> michaelni, BtbN have
[01:48:27 CEST] <Gramner> well, xeon phi only support 32 and 64 bit int math in it's avx-512 subset, but nobody outside of HPX cares about that so whatever.
[01:48:33 CEST] <Gramner> HPC*
[01:49:16 CEST] <Gramner> all "normal cpus" will have a sensible avx-512 feature subset
[01:55:45 CEST] <atomnuker> unless there are any more issues I'll be pushing the fft15 asm soon
[01:56:21 CEST] <iive> atomnuker: the commens once again doesn't mirror the code :P i'm talking about the movsd section...
[01:57:25 CEST] <iive> the start of fft5,
[01:57:28 CEST] <atomnuker> oh ffs I'll drop the bloody comment
[01:57:54 CEST] <iive> maybe it is not the comment that is wrong
[01:58:25 CEST] <atomnuker> it doesn't help anyway, I need to stare at that code for an hour until I know what 2 instructions do
[01:59:08 CEST] <iive> and...
[01:59:53 CEST] <jamrial> atomnuker: chill
[02:01:16 CEST] <atomnuker> rcombs: got some aac-eld/ld samples?
[02:01:39 CEST] <atomnuker> I'd also like some aac960 samples
[02:01:51 CEST] <iive> atomnuker:  i found this quite useful https://software.intel.com/sites/landingpage/IntrinsicsGuide/#
[02:02:03 CEST] <rcombs> my laptop and phone generate that for bluetooth headphones, but I don't have anything to capture it
[02:04:32 CEST] <atomnuker> huh, fdk_aac apparently supports them
[02:05:03 CEST] <iive> atomnuker: once again, are you sure that "movsd xm2,...." should not be simple "movups" ? 
[02:05:09 CEST] <iive> same for following xm3
[02:05:50 CEST] <kierank> atomnuker: ask mathias for aac960 samples
[02:07:13 CEST] <jamrial> iive: he changed it from movups to movsd at my request
[02:07:24 CEST] <iive> jamrial: but that's wrong
[02:07:27 CEST] <jamrial> why do you say it should be movups?
[02:07:48 CEST] <iive> movsd loads only 64 bits and zeroes the high 64
[02:07:52 CEST] <jamrial> yes
[02:08:06 CEST] <iive> he needs to load 4 floats, 128 bits
[02:08:12 CEST] <jamrial> no
[02:08:24 CEST] <jamrial> he needs 64 at that offset, 64 at the offset xm1 loads from
[02:08:28 CEST] <iive> in[5].re/in and in[6].re/in
[02:08:30 CEST] <jamrial> then shufps puts them together
[02:09:01 CEST] <jamrial> if you're basing this on the comments, then i guess they are wrong
[02:09:38 CEST] <Gramner> could use movsd+movhps instead of 2x movsd+shufps
[02:09:50 CEST] <jamrial> that's probably slower
[02:10:02 CEST] <iive> well, i do hope it is the comments that are wrong
[02:10:09 CEST] <jamrial> movhps with reg as dst is pretty slow
[02:10:17 CEST] <jamrial> iive: fate-opus would fail if it was wrong
[02:10:31 CEST] <Gramner> why? both are 2 loads + one shuffle µop
[02:10:32 CEST] <iive> maybe....
[02:10:48 CEST] <Gramner> but one is shorter code size
[02:11:29 CEST] <iive> avx have huge prefixes... it bloats the code out of proportion
[02:11:36 CEST] <Gramner> also vbroadcastsd instead of movddup + vinsertf128
[02:12:12 CEST] <Gramner> vex (avx) has the same instruction length as legacy sse for the vast majority of instructions
[02:12:21 CEST] <Gramner> some are one byte longer
[02:12:39 CEST] <Gramner> evex instructions are long as fuck though
[02:16:12 CEST] <iive> ok, minor nitpic 2*16+16 -> 3*16
[02:18:29 CEST] <iive> I just cannot remember if there is any pentaly for loading register as double and then using it as float.
[02:18:46 CEST] <Gramner> there isn't
[02:19:29 CEST] <Gramner> there's only a difference between integer and floating-point, not between single- and double-eprecision floating-point
[02:20:23 CEST] <Gramner> so there's no reason to ever use movapd over movaps for example
[02:21:43 CEST] <iive> i'm sure i've read something about these... in the intel documentation
[02:21:48 CEST] <iive> but can't find it atm
[02:22:03 CEST] <Gramner> it says "use movaps"
[02:22:30 CEST] <Gramner> iirc
[02:23:24 CEST] <jamrial> movapd/unpck[lh]pd are superfluous, yeah, and i think they are also one byte longer than the alternatives
[02:24:45 CEST] <Gramner> vmovaps in avx-512 (evex) has a use can when using opmasks since they are size-specific, but it's irrelevant in legacy sse and avx (vex)
[02:24:48 CEST] <iive> "because movaps is one byte shorted than movapd "
[02:24:49 CEST] <Gramner> vmovapd*
[02:35:07 CEST] <RiCON> just sent a patch to:ffmpege-devel at ffmpeg.org ...
[02:37:25 CEST] <jamrial> oh boy, i predit bikeshedding for it
[02:37:41 CEST] <jamrial> predict*
[02:38:29 CEST] <RiCON> the libvorbis one?
[02:38:46 CEST] <jamrial> the libgme one
[02:38:58 CEST] <RiCON> hm, 2013 too soon?
[02:44:38 CEST] <iive> atomnuker: i think somebody said that it is better to use 2 "movaps xmm" instead of "movaps ymm + vextractf128"
[02:44:50 CEST] <iive> vexractf128 have 3 cycles latency
[02:45:09 CEST] <Gramner> I replied to the ML instead
[02:45:30 CEST] <iive> Gramner: oh, i didn't see your email yet.
[02:45:47 CEST] <Gramner> yeah, cross-lane shuffles are slow. memory loads are pretty fast on the other hand (can do 2 per cycle on most modern cpus)
[02:46:19 CEST] <jamrial> i didn't get anything yet. guess the ml is slow today
[02:46:29 CEST] <Gramner> just sent it
[02:52:27 CEST] <atomnuker> iive: yes, it was slower
[02:52:49 CEST] <iive> it's still in your code.
[02:53:28 CEST] <atomnuker> yes, it was slower to do 2 movaps
[02:54:05 CEST] <atomnuker> I'll test it again though
[02:54:06 CEST] <RiCON> jamrial: there, sent the use_pkg_config for libgme too
[02:54:13 CEST] <RiCON> should be easier to accept
[03:04:03 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:27f80ab0160d: avcodec/tiff: Update pointer only when the result is used
[03:04:03 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:0c2ef4f6b4d5: avcodec/takdec: Fix integer overflow
[03:04:03 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:24e95f9d4de0: avcodec/wavpack: Fix integer overflow
[03:07:49 CEST] <atomnuker> Gramner: holy crap, removing the 2 shuffles at the start gave around 80 decicycles
[03:08:03 CEST] <atomnuker> "Adding m1 and m3 before shuffling" <- do you mean the addps m0, m1?
[03:08:20 CEST] <iive> no
[03:08:38 CEST] <iive> you do m0+m1, then m0+m3 , or something like that
[03:09:54 CEST] <atomnuker> hold on, I could just adjust my twiddles and remove both, I think
[03:10:17 CEST] <iive> are twiddles constants?
[03:10:38 CEST] <atomnuker> I already permute them in the init function
[03:11:09 CEST] <atomnuker> q2301 -> this exchanged real and imaginary, didn't it?
[03:11:47 CEST] <iive> why are you asking me, and yes :)
[03:12:21 CEST] <atomnuker> because I already forgot and I'm not used to the q<stuff> notation
[03:12:36 CEST] <atomnuker> (the q<stuff> notation is awesome though)
[03:21:22 CEST] <atomnuker> crap, didn't notice those were mulps, not movs
[03:28:03 CEST] <atomnuker> nevermind, I saw what he meant
[03:30:46 CEST] <iive> sorry, I thought i typed the longer explanation...
[03:52:09 CEST] <atomnuker> iive: sent a v4 to the ML, this time I can absolutely say the comments are correct
[03:52:24 CEST] <iive> :)
[03:52:46 CEST] <iive> i'll check it tomorrow :)
[04:06:18 CEST] <jamrial> michaelni: you run all the netbsd fate slots. could you post the output of for example "make libavfilter/x86/af_afir.o V=1" somewhere?
[04:06:27 CEST] <jamrial> also the contents of the "X86ASMDEP=" line in config.mak
[04:07:07 CEST] <jamrial> or even see if you can find what's wrong since you can actually test it...
[04:07:57 CEST] <jamrial> i'm guessing it could be either bash or make in your netbsd environment. no other system seems to have this problem
[04:25:24 CEST] <michaelni> jamrial,  https://pastebin.com/fnaja4U8
[04:25:53 CEST] <jamrial> wtf, why is it failing then
[04:33:23 CEST] <jamrial> michaelni: does yasm -v succeed?
[04:38:06 CEST] <jamrial> the "-MD file.d" part shouldn't be in the second call to yasm, that's what making it fail
[04:38:09 CEST] <jamrial> but configure is supposed to make sure it's only added to nasm...
[04:38:45 CEST] <jamrial> michaelni: can you do a "grep X86ASM" to config.mak as well?
[04:40:34 CEST] <michaelni> yasm: warning: unrecognized option `-v'
[04:41:22 CEST] <jamrial> why the hell is it adding flags from the configure section that requires -v to succeed then...
[04:41:51 CEST] <michaelni> https://pastebin.com/iamypCvh
[04:43:00 CEST] <jamrial> yeah, X86ASM_DEPFLAGS should be blank
[04:43:14 CEST] <jamrial> i have no idea how this is happening
[04:43:16 CEST] Action: michaelni falls asleep ... ping me tomorrow if theres more i shoud test
[04:43:50 CEST] <jamrial> sure, thanks
[07:04:28 CEST] <LokerPoker> Does ffmpeg offer space for beginners who want to contribute ?
[07:05:08 CEST] <LokerPoker> Space as in - Is there any scope for beginners wishing to contribute ?
[07:16:08 CEST] <DHE> if you can write a patch that's worthwhile and meeting the guidelines, it can be accepted.
[07:16:23 CEST] <DHE> I submitted my first patch as a nobody and it was accepted
[07:21:06 CEST] <LokerPoker> DHE: I am a bit naive to all this. But I have used ffmpeg and ffserver before too. A little more direction on what to learn, what to focus on, can be a great help for me.
[07:21:51 CEST] <DHE> well, in general I would ask, what is ffmpeg missing or what bugs are you running into? then fix them.
[07:22:17 CEST] <DHE> a bit of "necessity is the mother of invention", but usually more rewarding than just crawling the issue tracker and picking something
[09:35:58 CEST] <jya> is it common in a H264 stream, to have a SPS before every I-frame, that are almost identical to the previous one but with changing num_units_in_tick?
[09:40:21 CEST] <rcombs> jya: it's pretty common to repeat SPS periodically (usually before keyframes [either IDRs or Is with recovery SEI]); not sure about the num_units_in_tick changing
[09:40:44 CEST] <jya> rcombs: well, this is in a MP4
[09:41:10 CEST] <jya> so far I had only ever seen repeating SPS/PPS in front for each keyframe
[09:41:11 CEST] <wm4> mp4s don't normally have sps in stream
[09:41:16 CEST] <rcombs> it's less common but not exactly rare in MP4
[09:41:17 CEST] <jya> but they were identical
[09:41:20 CEST] <wm4> (not sure if they're allowed or forbidden)
[09:41:29 CEST] <rcombs> wm4: they're allowed afaik
[09:41:46 CEST] <wm4> rcombs: even if they're not in the avcc data?
[09:41:58 CEST] <jya> wm4: I think it's just a quick and dirty conversion from mpeg-ts to mp4... they dont bother changing the streams (other than converting from annexb to avcc)
[09:42:05 CEST] <rcombs> generally if you remux from MPEGTS to MP4, the first SPS and PPS get copied to the avcc, but they're often not actually removed from the packets
[09:42:07 CEST] <wm4> (not sure if they are in this case, but if they subtly change every time...)
[09:42:22 CEST] <rcombs> yeah, not sure if that's legal, but it's definitely possible
[09:42:30 CEST] <rcombs> and players handle it fine in my experience
[09:42:51 CEST] <wm4> did I mention yet that I hate how the h264 extradata is defined
[09:43:00 CEST] <jya> in this video they keep changing, absolute pain... https://people-mozilla.org/~jyavenard/mediatest/Firefox%20%f0%9f%a6%8a%f0%9f%8c%8d%20-%20What's%20multi-process%20Firefox-1.mp4
[09:43:02 CEST] <wm4> it seems to cause so many issues and problems
[09:43:04 CEST] <rcombs> I don't think so but yeah it's bad
[09:43:15 CEST] <jya> wm4: you have AVC3
[09:43:19 CEST] <wm4> jya: so, what's the actual problem?
[09:43:32 CEST] <jya> it's like avcc but no extradata in the demuxer
[09:44:02 CEST] <wm4> does apple's VT API support that? (that's when this stuff gets real horrible)
[09:44:02 CEST] <jya> well, i have to detect change of contents mid-stream (as we've had videos not playing once a change occurred)
[09:44:13 CEST] <jya> apple VT doesn't support that exactly
[09:44:15 CEST] <wm4> the ffmpeg decoder handles this transparently
[09:44:19 CEST] <jya> that's why it's such a pain
[09:44:27 CEST] <jya> and I have to use Apple VT
[09:44:37 CEST] <rcombs> oh man
[09:44:39 CEST] <rcombs> I'm so sorry
[09:44:42 CEST] <wm4> me too
[09:44:53 CEST] <wm4> ffmpeg's VT wrapper is also not working too well too
[09:45:04 CEST] <rcombs> VT's a clusterfuck
[09:45:07 CEST] <jya> so I added some code that look for SPS, and if they change I must drain the decoder, destroy it, create a new one and continue my merry way
[09:45:22 CEST] <jya> but with that video, as it looks like we have a new and different SPS
[09:45:30 CEST] <wm4> I think there was a patch on ffmpeg-devel that solves soemthing with sps changes and VT
[09:45:39 CEST] <jya> i end up draining + destroying + create a new decoder every i-frame
[09:45:54 CEST] <wm4> drain what?
[09:45:57 CEST] <rcombs> this actually sounds a lot like an issue I've seen on Apple TV
[09:46:07 CEST] <wm4> the VT API has no concept of that because you need to reorder frames yourself
[09:46:26 CEST] <rcombs> wm4: it can still be async
[09:46:31 CEST] <jya> drain the decoder, which is from our re-order queue (still have to wait for the async VT task to complete if any pending
[09:46:47 CEST] <wm4> rcombs: true
[09:46:49 CEST] <rcombs> a lot of commercial blu-ray streams have superfluous SPS changes like that
[09:46:55 CEST] <rcombs> and Apple TV shits itself on those
[09:46:56 CEST] <jya> we use the VT decoder in full async mode, (ffmpeg doesn't) 
[09:47:10 CEST] <wm4> ffmpeg can't because of its design
[09:47:14 CEST] <wm4> although we'd like it to
[09:47:38 CEST] <wm4> (we've been thinking of making VT a full decoder instead of hwaccel in ffmpeg)
[09:47:53 CEST] <rcombs> I've got a patch for that laying around, it just falls apart on reorder
[09:48:04 CEST] <wm4> ffmpeg does do partial SPS change detection, so that reminded me of it
[09:48:13 CEST] <wm4> (but it also seems to cause issues sometimes, hurr)
[09:48:26 CEST] <jya> well, I'm going to do a dirty hack, decode the SPS into my structure, and compare every fields but num_units_in_tick that will do for now
[09:48:36 CEST] <ubitux> rcombs: honestly, i'd rather have basic reordering based on packet pts data and be done with that
[09:48:48 CEST] <wm4> SIN
[09:49:01 CEST] <ubitux> than waiting forever for an architectural change that will never happen
[09:49:01 CEST] <rcombs> ubitux: yeah, I've got that, but it's not reliable in all containers, so it'd regress in some cases
[09:49:30 CEST] <wm4> I'm more worried about decoder delay, but could always force 16 I guess
[09:49:43 CEST] <jya> rcombs: we only use the pts as marked in the container for reorderning the frames.
[09:49:47 CEST] <jya> it's never caused us issue
[09:49:57 CEST] <rcombs> jya: your use-case is much narrower, though
[09:50:23 CEST] <rcombs> you don't have to support broken AVIs, for instance
[09:50:31 CEST] <rcombs> or raw .264 files
[09:50:42 CEST] <ubitux> wasn't the main use case raised mpeg ts?
[09:51:12 CEST] <rcombs> or certain mpegts streams, yeah
[09:51:13 CEST] <jya> rcombs: that's true
[09:51:15 CEST] <ubitux> is anyone able to identify where that code even lie currently?
[09:51:27 CEST] <rcombs> sure, it's right here
[09:51:30 CEST] <ubitux> "lavf/utils.c"?
[09:51:36 CEST] <ubitux> no i mean, the reordering thing
[09:51:41 CEST] <rcombs> https://gist.github.com/93f7e4ab4f97ead9f8ce87c3a6bc7039
[09:51:46 CEST] <rcombs> oh that, uh
[09:51:49 CEST] <rcombs> ¯\_(Ä)_/¯
[09:52:29 CEST] <jya> actually just had a video, where the SPS change in the middle in such a way that the Microsoft H264 MFT crash big time
[09:52:29 CEST] <rcombs> I think I suggested to jkqxz that he might make a bsf to automatically generate missing timestamps in h264 streams based on the internal reordering data
[09:52:35 CEST] <rcombs> jya: nice
[09:52:47 CEST] <jya> so detected change of SPS on windows too is useful
[09:52:49 CEST] <rcombs> ~closed-source implementations~
[09:53:01 CEST] <jya> but I don't want too many false positive.
[09:53:22 CEST] <rcombs> jya: is the teardown+reconfigure particularly expensive, then?
[09:54:18 CEST] <wm4> I wrote a MF wrapper too and it could do h264, but it wasn't too useful after all
[09:54:18 CEST] <ubitux> libavformat/avc.c:static const uint8_t *ff_avc_find_startcode_internal(const uint8_t *p, const uint8_t *end)
[09:54:23 CEST] <jya> well, it's kind of a pain becaus on windows the H264 MFT has a super high latency
[09:54:27 CEST] <ubitux> why is this currently in the codebase with ff + static
[09:54:27 CEST] <jya> it buffers 30+ frames
[09:54:32 CEST] <ubitux> and duplicated in rcombs patch :3
[09:54:55 CEST] <jya> so when you drain , you get a big memory usage spike ...
[09:54:57 CEST] <ubitux> ah, lavf, lavc.
[09:55:22 CEST] <jya> not sure if it's expensive or not, but the handling of failure is pain as we now run the decoding process in another process in its own jail
[09:56:13 CEST] <ubitux> rcombs: did you try hevc with that decoder?
[09:56:24 CEST] <rcombs> haven't installed 10.13 yet
[09:56:36 CEST] <jya> rcombs: that video https://bug1313398.bmoattachments.org/attachment.cgi?id=8805171
[09:56:59 CEST] <jya> if you seek, you end up on a frame with a different SPS than what was found in the extradata
[09:57:16 CEST] <jya> for some reason, if you play continuously, the H264 MFT handles it properly
[09:57:25 CEST] <jya> but feed it data from a random keyframe, and boom
[09:58:28 CEST] Action: jya sad about Apple decision on hevc
[10:00:38 CEST] <wm4> jya: so, why not stop input until the decoder is drained naturally?you'd still need to buffer input (or have a "spike" of requested packets the demuxer), but presumably overall memory won't grow?
[10:00:56 CEST] <wm4> also what apple decision on hevc?
[10:01:34 CEST] <rcombs> supporting it as opposed to VP9, presumably?
[10:02:01 CEST] <rcombs> ETA on a decent encoder?
[10:02:03 CEST] <jya> as opposed to AV1 :)
[10:02:16 CEST] <nevcairiel> AV1 is still years away from real-world use =p
[10:02:19 CEST] <rcombs> well AV1's mostly vaporware atm, so&
[10:02:36 CEST] <jya> oh we're getting some demo going
[10:02:49 CEST] <wm4> anyway, hevc has the same avcc nonsense
[10:02:53 CEST] Action: wm4 groans
[10:03:00 CEST] <rcombs> "demo" is a long way from "suitable for use right now"
[10:03:09 CEST] <nevcairiel> the bitstream isnt even done yet, so you can demo all you want, its just not close to real-world use
[10:03:11 CEST] <jya> in partnership with bitmovin.
[10:03:20 CEST] <rcombs> what are the odds that AV1 ends up with an encoder that actually competes with x264
[10:03:31 CEST] <rcombs> in all seriousness, that's good to hear
[10:03:52 CEST] <jya> just yet another codec, with an even more silly licensing model
[10:04:11 CEST] <rcombs> but the only remotely sane alternative to HEVC right now is VP9, and the encoder situation there is even worse
[10:07:57 CEST] <jya> anyone in SFO next week?
[10:08:15 CEST] <jya> There's a Video Tech meetup on Thursday evening
[11:05:51 CEST] <BtbN> wm4, you mean lock the "No PRs on this repo PR", or some other one?
[11:06:45 CEST] <thebombzen> don't forget that google is trying to patent the entropy encoding in av1, even though they didn't invent it
[11:06:57 CEST] <thebombzen> which is kind of contrary to the whole fking point of av1
[11:07:58 CEST] <nevcairiel> in todays world, someone will patent it, so getting a defensive patent first is the only way to defend against that
[11:08:31 CEST] <thebombzen> That doesn't change the fact that you cannot patent something you didn't invent
[11:08:48 CEST] <BtbN> how can you patent something that someone else made and decided not to patent? If that's possible, the whole system is flawed.
[11:08:50 CEST] <thebombzen> or rather, shouldn't. You should not be awarded patents for things you didn't invent, and you shouldn't try anyway
[11:09:17 CEST] <nevcairiel> BtbN: it occurs to you only now that the patent system is flawed? :p
[11:09:33 CEST] <BtbN> I'm pretty sure it's not possible to do that in europe
[11:09:38 CEST] <BtbN> No idea how fucked up it is in the US
[11:09:43 CEST] <BtbN> but that would be pretty messed up
[11:09:44 CEST] <thebombzen> BtbN: and yes, really. Google is trying to patent Asymmetric Numeral Systems entropy coding, in the US Patent Office
[11:09:47 CEST] <thebombzen> https://encode.ru/threads/2648-Published-rANS-patent-by-Storeleap/page3
[11:10:28 CEST] <thebombzen> Here's the patent (which is, ironically, on google patents): https://www.google.com/patents/US20160248440
[11:11:10 CEST] <thebombzen> Someone on Reddit did the hard work of aggregating some articles, if you want to see their list: https://www.reddit.com/r/programming/comments/6h08z5/google_is_currently_trying_to_patent_video/
[11:12:49 CEST] <nevcairiel> the internet sure is slow, the patent was filled over a year ago =p
[11:12:59 CEST] <thebombzen> didn't become public over a year ago
[11:13:54 CEST] <thebombzen> I think the big deal is that Jarek Duda found out like a week ago about this. He is the one who invented it and was never informed
[11:19:02 CEST] <wm4> <BtbN> wm4, you mean lock the "No PRs on this repo PR", or some other one? <- yes
[11:19:14 CEST] <BtbN> I can do that. Anyone objects?
[13:43:24 CEST] <cone-943> ffmpeg 03Jun Zhao 07master:ea1d07aed96a: lavc/golomb: add value range comment for set_ue_golomb().
[14:08:38 CEST] <atomnuker> RiCON: can you check if http://trac.ffmpeg.org/ticket/6484 breaks minigw builds?
[14:08:48 CEST] <atomnuker> (we have fate instances of that, right?)
[14:10:30 CEST] <RiCON> at least nevcairiel's
[14:12:06 CEST] <RiCON> and there's no issue with msys2 mingw GCC, 32 or 64-bit, at least
[14:14:44 CEST] <nevcairiel> my mingw-w64 builds with a very recent binutils and gcc still work at least
[14:15:29 CEST] <JEEB> that bug report has no further information on it so it's almost as good as useless
[14:15:38 CEST] <RiCON> was this with yasm or nasm, or does it even matter?
[14:15:52 CEST] <nevcairiel> mine probably build with nasm now that the default was changed
[14:16:07 CEST] <nevcairiel> but it also passed before that change
[14:16:10 CEST] <nevcairiel> where yasm was still used
[14:16:29 CEST] <nevcairiel> more annoyingly however, msvc shared builds are broken with nasm
[14:16:57 CEST] <nevcairiel> nasm must somehow produce odd object files
[14:16:57 CEST] <RiCON> i compiled yesterday before going to bed, which used nasm
[14:20:14 CEST] <RiCON> objdump -t on .o files from .asm tells me the same formats (pe-i386 and pe-x86-64) as with .o from C
[14:20:18 CEST] <RiCON> is that it?
[14:46:27 CEST] <iive> and Daemon404 is back.
[14:47:04 CEST] <Daemon404> well i had planned to lurk, but i see the very first line after rejoining is iive being an asshole, so.
[14:48:37 CEST] <atomnuker> iive: he promised to buy everyone a beer at VDD if your PVQ simd gets merged
[14:48:57 CEST] <atomnuker> so no wonder he's pissed
[14:49:08 CEST] <iive> well, I'd like some benchmarks :P
[14:49:21 CEST] <iive> i'll send updated patch later today.
[14:49:34 CEST] <atomnuker> k, should I wait for those?
[14:49:48 CEST] <iive> yes
[14:50:17 CEST] <iive> but if you can give me some info about the problem you have with avx2, it'd be useful.
[14:51:00 CEST] <atomnuker> are you actually using avx2?
[14:51:11 CEST] <atomnuker> like, 256bit integer instructions?
[14:52:30 CEST] <iive> yes
[14:54:03 CEST] <kierank> derek should just ignore iive
[14:54:09 CEST] <kierank> iive on ignore is a great decision
[14:54:56 CEST] <Compn> just to be clear
[14:54:57 CEST] <Compn> [08:46] <iive> and Daemon404 is back.
[14:54:57 CEST] <Compn> [08:47] <Daemon404> well i had planned to lurk, but i see the very first line after rejoining is iive being an asshole, so.
[14:55:10 CEST] <Compn> saying "and Daemon404 is back." is not "being an asshole"
[14:55:20 CEST] <Compn> saying "being an asshole" is "being an asshole"
[14:56:21 CEST] <Compn> the maturity level of some people is quite low around here.
[14:56:42 CEST] <nevcairiel> if you knew the hsitory, you would realize that it kinda was being an asshole
[14:57:06 CEST] <Compn> its not wise to fan the flames either
[14:57:21 CEST] <Compn> as you cannot assume iive's intent with that message
[14:58:50 CEST] <iive> nevcairiel: would you explain to me, how this is so?
[14:58:53 CEST] <Compn> if people would stop assuming there is some hidden insult in every sentence, there would be less fights
[14:59:09 CEST] <BBB> guys, guys
[14:59:10 CEST] <BBB> enough
[14:59:14 CEST] <BBB> please stop this discussion
[14:59:17 CEST] <Compn> iive : from now on, greet english speakers as "hello ____, nice to see you again"
[14:59:29 CEST] <Compn> iive : otherwise they will assume the worst intent from any other greeting
[15:00:00 CEST] <iive> they are free to assume whatever they want. In only reflects what they are.
[15:00:16 CEST] <Compn> yes, but also its nice to be nicer than they
[15:00:48 CEST] <Compn> because usually it makes them twice as angry...
[15:00:49 CEST] <Compn> ;)
[15:01:00 CEST] <BBB> Compn: lets not make assumptions about peoples maturity level, lets just accept that some people cant get along and accept that silence is better than fights :(
[15:01:10 CEST] <nevcairiel> [14:57:06] <Compn> its not wise to fan the flames either <-- and wtf are you doing now? :D
[15:01:12 CEST] <BBB> some things cannot be fixed :(
[15:01:42 CEST] <BBB> brb
[15:01:46 CEST] <Compn> nevcairiel : explaining to iive what has happened. asking him to use nicer greetings. and asking you to not assume intent based on 4 words...
[15:02:01 CEST] <nevcairiel> if that helps you sleep at night :)
[15:02:02 CEST] <Compn> as well as kierank, but i think he will not change 
[15:02:43 CEST] <Compn> BBB : you're saying not to ask people to be nicer? ok then
[15:04:44 CEST] <Compn> BBB : one idea i had was to do away with all discussions and only communicate via patches and patch reviews :D
[15:04:53 CEST] <Compn> with all developers
[15:05:10 CEST] <Compn> run it all through a moderating team that destroys any mail with non technical / code replies
[15:05:38 CEST] <Compn> j-b might be interested in that :D
[15:05:57 CEST] <iive> As Cardinal Richelieu has said "If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him."
[15:06:14 CEST] <iive> Compn: calm down. it's over. let's talk about code.
[15:08:39 CEST] <Compn> fair enough
[15:08:50 CEST] <TMM> Cardinals finding reasons to hang honest people is also not particularly noteworthy :P
[15:12:27 CEST] <Compn> i actually agree with kierank though, devs ignoring non technical discussions would be good idea 
[15:12:38 CEST] Action: Compn runs
[15:38:23 CEST] <cone-943> ffmpeg 03jerett 07master:82a8724df2a5: lavc/videotoolboxenc: fix loadVTEncSymbols crash when symbol not found
[15:38:24 CEST] <cone-943> ffmpeg 03jerett 07master:9f26d670e447: lavc/videotoolboxenc: fix open videotoolbox bug on iOS8.4
[16:16:46 CEST] <jamrial> michaelni: i think i foud what's wrong. the "graceful" fallback when nasm is too old is faulty
[16:18:26 CEST] <jamrial> your netbsd environment must have a nasm < 2.03 and a recent enough yasm
[16:20:12 CEST] <cone-943> ffmpeg 03Paul B Mahol 07master:04aa09c4bcf2: Revert "lavfi/buffersrc: push the frame deeper if requested."
[16:24:15 CEST] <durandal_1707> anybody can lend me hand in REing atrac9?
[16:28:13 CEST] <atomnuker> durandal_1707: need help with the transforms?
[16:32:31 CEST] <durandal_1707> atomnuker: i need general help, i found bitstream stuff reading, but cant recognize stuff and what does it use for compression
[16:32:48 CEST] <durandal_1707> it uses mdct for sure 
[16:32:55 CEST] <durandal_1707> up to 2 bands
[16:33:08 CEST] <durandal_1707> and with bunch of subbands
[16:33:35 CEST] <atomnuker> ah, that crap, it uses QMF to feed into ffts like mp3, right?
[16:36:20 CEST] <mateo`> jamrial: hello, would http://sprunge.us/egGQ fix the sum_square test on x86 ? (i'm not familiar with x86 at all, and i was not able to reproduce the issue on my side)
[16:37:54 CEST] <jamrial> mateo`: yes, but you can prevent adding that instruction if you instead replace the mov r2, r1 into mov r2d, r1d
[16:38:47 CEST] <jamrial> r2 will have the higher 32 bits cleared that way
[16:39:16 CEST] <jamrial> r1 gets and'd later in the function, so no need to do anything else to it
[16:43:59 CEST] <mateo`> jamrial: updated version http://sprunge.us/jJYR
[17:01:44 CEST] <durandal_1707> atomnuker: dunno, it calls mdct twice for each 1024 samples that are in block align
[17:06:33 CEST] <durandal_1707> complexity is much lower than other atrac decoders afaik
[17:07:06 CEST] <atomnuker> do you know what coding it uses? huffman?
[17:14:51 CEST] <jamrial> mateo`: yeah, that should do it
[17:15:14 CEST] <jamrial> make sure your checkasm test passes on x86_64 before pushing, of course
[17:26:35 CEST] <jamrial> michaelni: patch on the ml for the netbsd failure
[17:27:28 CEST] <durandal_1707> atomnuker: no i dont know
[17:28:37 CEST] <atomnuker> well, send me what you have on the bitstream and I'll see what I can figure out
[17:32:23 CEST] <durandal_1707> atomnuker: i dont have anything worth posting, i only have .idb file if you interested in whats decompiled and i named few functions because i know what are they doing
[17:34:25 CEST] <atomnuker> yep, that'll be alright
[17:40:16 CEST] <durandal_1707> atomnuker: for example this doesnt call bitstream functions: https://pastebin.com/Mc3WTsuz
[17:41:47 CEST] <durandal_1707> til it uses superframes of 4x256 samples
[18:03:03 CEST] <kierank> atomnuker: bulgaria's first communication satellite launches today
[18:21:32 CEST] <jamrial> durandal_1707: 04aa09c4bc broke fate-lavf-ffm and fate-lavf-mxf
[18:22:25 CEST] <durandal_1707> how so?
[18:25:23 CEST] <jamrial> durandal_1707: http://fate.ffmpeg.org/report.cgi?time=20170623145756&slot=x86_64-mingw-w64-windows-native 
[18:25:24 CEST] <jamrial> durandal_1707: https://pastebin.com/qZM8XPbH
[18:25:31 CEST] <jamrial> one byte changes
[18:27:15 CEST] <atomnuker> kierank: oh yeah, forgot about that, they delayed it a bunch of times last week
[18:27:17 CEST] <jamrial> at least in the mxf test. didn't check what changed in the ffm one
[18:38:20 CEST] <iive> spacex launch?
[19:01:40 CEST] <aasif>  Hello, everyone.  I'd like to learn about FFmpeg and its documentation. I tried diving in the huge codebase first. But it's too technical. I would highly appreciate any advice. Thanks. :)
[19:04:54 CEST] <durandal_1707> aasif: what you know?
[19:06:29 CEST] <aasif> durandal_1707: Actually to be honest, I don't know anything. I studied the FFmpeg command line's basic uses. I studied the portion about filtergraphs. That's mostly all. 
[19:07:23 CEST] <atomnuker> what would you like to know about?
[19:12:11 CEST] <aasif> atomnuker: I'd like to learn about the documentation. The basic code flow. which modules affect while modules.  I'm new to open source development. Me being a noob, would apprecite some help on where to get started in understanding the codebase for the whole software. Should I try learning the whole functionality of the software first, and the theory behind it and then look into code? And if so, what's the place to learn theory about FFmpeg? (By theor
[19:12:11 CEST] <aasif> y, I mean basic structure of it all.)
[19:12:39 CEST] <aasif> *which modules affect which modules. 
[19:18:46 CEST] <durandal_1707> aasif: i you want to do programming you need to learnt it first. and also read ffmpeg manuals
[19:21:04 CEST] <aasif> durandal_1707: thanks. I'll try to learn the functioning of ffmpeg from the manuals first and then move on to the codebase i guess. 
[19:36:12 CEST] <Compn> aasif : the code flow is basically the 4 main libraries
[19:36:46 CEST] <Compn> er more than 4 now
[19:39:29 CEST] <aasif> Compn: libavutil, libavformat,  libswresample, libavcodec, libavfilter, libavdevice, libavswscale?
[19:40:38 CEST] <Compn> yea
[19:40:44 CEST] <Compn> format, util and codec are the main ones
[19:40:46 CEST] <Compn> swscale too
[19:42:08 CEST] <Compn> those are what enable people to decode/encode video
[19:42:17 CEST] <Compn> well video files
[19:42:45 CEST] <Compn> then ffmpeg.c is what uses those libs to encode, thread, filter, display, stream, etc
[19:46:22 CEST] <aasif> Compn: okay. thanks. how should i proceed on learning more about these files? like what methods do they use to encode and decode? also, a quick question, how does any program run as a command line utility? which function or specifically which file handles the input that goes into the command line as the user puts it? (this is a very basic question. but i'm a noob. i couldn't figure it out myself.)
[19:48:42 CEST] <aasif> Compn: in case of ffmpeg, which file has the responsibility to take in the input "ffmpeg -i ... "
[19:49:09 CEST] <atomnuker> ubitux: a zombie just appeared on the ML!
[19:49:27 CEST] <Compn> right
[19:50:32 CEST] <Compn> aasif : there is some developer documentation on the site that explains the various api calls
[19:51:02 CEST] <Compn> aasif : http://ffmpeg.org/documentation.html
[19:51:18 CEST] <ubitux> atomnuker: oh
[19:51:45 CEST] <Compn> aasif : e.g. how to decode a file, http://ffmpeg.org/doxygen/trunk/group__lavc__decoding.html
[19:52:00 CEST] <Compn> aasif : its quite complicated process haha :)
[19:52:41 CEST] <aasif> Compn: thanks. :D okay. i'll try to learn it somehow. :)
[19:52:42 CEST] <ubitux> atomnuker: i'm not it's a good idea to define _GNU_SOURCE globally
[19:53:09 CEST] <ubitux> (as it impacts various functions)
[19:53:24 CEST] <ubitux> you generally want it locally to the function usage
[19:53:35 CEST] <atomnuker> I tried to do it there, but the damn thing doesn't work
[19:53:46 CEST] <atomnuker> even when I do it right at the top
[19:53:58 CEST] <ubitux> i'd say you have to move ff_thread_setname() in a dedicated .c
[19:54:04 CEST] <ubitux> where you define _GNU_SOURCE on top
[20:01:10 CEST] <wm4> in certain situations using _GNU_SOURCE will break ffmpeg's code
[20:01:24 CEST] <wm4> at least in libavutil/error.c
[20:04:03 CEST] <atomnuker> we define it there actually
[20:04:10 CEST] <atomnuker> as well as in libavutil/cpu.c
[20:04:39 CEST] <wm4> #undef _GNU_SOURCE
[20:04:43 CEST] <wm4> are you sure about that
[20:04:50 CEST] <wm4> this is the first non-whitespace line in error.c
[20:04:53 CEST] <atomnuker> hm, maybe it would work if the functions themselves were compiled and exposed rather than inlined
[20:05:05 CEST] <atomnuker> oh, I didn't notice it was undef
[20:05:31 CEST] <wm4> you should put this ff_... thing into its own source file, where it calls the pthread function
[20:05:59 CEST] <wm4> either that, or configure checks that it's somehow available by default and that's it
[20:07:06 CEST] <atomnuker> yep, I'll make thread.c and put stuff there, thread.h can serve as a header file interface for those
[20:55:37 CEST] <iive> SpaceX 14 minutes to launch.
[20:56:23 CEST] <durandal_1707> iive: since when you care about that ?
[20:56:50 CEST] <iive> durandal_1707: I always have, I just had no idea people here do.
[20:58:39 CEST] <BBB> atomnuker: s/ff/avpriv/?
[20:58:44 CEST] <BBB> atomnuker: since its shared between libraries
[21:36:09 CEST] <atomnuker> "implicit declaration of function 'pthread_setname_np' is invalid in C99"
[21:36:15 CEST] <atomnuker> how is it implicit
[21:36:43 CEST] <atomnuker> the program literaly defines _GNU_SOURCE, includes pthreads and has a wrapper function to call the damn thing
[21:36:52 CEST] <atomnuker> nothing else, nothing else included or anything
[21:37:18 CEST] <atomnuker> probably some evil cflags
[21:37:28 CEST] <atomnuker> can't do anthing about that
[21:38:06 CEST] <atomnuker> except try to undef them
[21:38:53 CEST] <atomnuker> haha, it works
[21:40:43 CEST] <atomnuker> actually nevermind, does clang really not define __GLIBC__
[21:41:19 CEST] <iive> does it compile using glibc?
[21:41:48 CEST] <atomnuker> why wouldn't it?
[21:46:50 CEST] <iive> because it is gnu? does bsd/osx use glibc?
[21:47:00 CEST] <durandal_1707> no
[21:51:24 CEST] <rcombs> atomnuker: __GLIBC__ is defined by glibc itself, not by the compiler
[21:51:56 CEST] <iive> btw, satelite successfully deployed. first stage also landed safely.
[21:52:09 CEST] <rcombs> spent most of the crush core, apparently came in pretty hot
[21:54:34 CEST] <atomnuker> screw it, I'm using prctl
[22:00:16 CEST] <atomnuker> k, posted a new version of the patch
[22:00:57 CEST] <BBB> lavu: add ff_pthread_setname() <- title still says ff
[22:01:01 CEST] <BBB> (I know patch does avpriv now)
[22:02:05 CEST] <ubitux> atomnuker: why is ptrctl code under HAVE_PTHREAD_SETNAME_NP?
[22:02:35 CEST] <atomnuker> granted, technically on linux that will always be defined
[22:02:52 CEST] <atomnuker> but its there also to serve as a comment since its only needed for pthread name setting
[22:02:54 CEST] <ubitux> always "since Linux 2.6.9"
[22:03:08 CEST] <atomnuker> that's like, 30 year old linux version, right?
[22:03:22 CEST] <ubitux> i'd say more like 7-8?
[22:03:32 CEST] <ubitux> but sure, that should be fine :)
[22:13:24 CEST] <atomnuker> someone pl0x lgtm my fft15 asm patch, its been reviewed by 2 elder gods already
[22:13:43 CEST] <durandal_1707> just push
[22:25:41 CEST] <atomnuker> michaelni: what does make DBG=1 say?
[22:26:21 CEST] <Gramner> atomnuker: use 4-arg vinsertf128. should hopefully fix it
[22:28:24 CEST] <iive> michaelni: DBG=1 is make variable, it compiles the assembler manually in 2 stages, the first one runs just pre-processor to expand the macros (and strip debug info).
[22:29:18 CEST] <Gramner> having dst implicitly being equal to src1 in vex instructions is an assembler feature. it has bugs with older nasm versions with some instructions
[22:29:35 CEST] <Gramner> maybe yasm is affected too, I don't remember
[22:30:31 CEST] <iive> so increase the minimum required nasm version?
[22:31:05 CEST] <Compn> did we drop yasm then?
[22:31:12 CEST] <Compn> we might want to make a news release on this ...
[22:31:22 CEST] <Compn> news entry and maybe twitter/facebook
[22:31:25 CEST] <Gramner> no, both should be supported afaik
[22:31:26 CEST] <Compn> if lou is around
[22:31:36 CEST] <Gramner> default was changed to nasm
[22:32:19 CEST] <Compn> right, but iirc yasm died as well ?
[22:32:30 CEST] <Compn> i mean the yasm project itself haha
[22:32:35 CEST] <Compn> nevermind
[22:32:36 CEST] Action: Compn runs
[22:33:00 CEST] <Gramner> yeah, it doesn't get new features so it lacks support for things like avx-512
[22:33:45 CEST] <michaelni> atomnuker, make V=1 says: nasm -f elf64 -g -F dwarf -I./ -I.// -Ilibavcodec/x86/ -Pconfig.asm -MD libavcodec/x86/mdct15.d  -o libavcodec/x86/mdct15.o libavcodec/x86/mdct15.asm
[22:33:45 CEST] <michaelni> libavcodec/x86/mdct15.asm:116: error: invalid combination of opcode and operands
[22:34:36 CEST] <iive> DBG is specific for yasm/nasm compilation.
[22:35:04 CEST] <michaelni> DBG=1 does nothing, make DBG=1 shows nothing diferent from no DBG=1
[22:35:07 CEST] <ubitux> damn, wasn't the multiple pgs subtitles issue fixed long ago?
[22:35:17 CEST] <ubitux> it looks all broken with several files i have here
[22:35:20 CEST] <ubitux> it's really annoying :(
[22:35:44 CEST] <Gramner> related nasm commit http://repo.or.cz/nasm.git/commit/ae707bace4406788714597ec5b4f1a427c9ad9c7 so contracted 3-arg vinsertf128 breaks in nasm versions older than 2.13
[22:36:06 CEST] <michaelni> ubitux, i dont remember but add fate tests, more tests make regressions less likely
[22:36:49 CEST] <ubitux> dunno if it's a regression
[22:38:00 CEST] <atomnuker> michaelni: does changing line 66 in libavcodec/x86/mdct15.asm to "vinsertf128 m%3,  m%3, xm3, 1" fix this?
[22:49:37 CEST] <iive> michaelni: the code for DBG handling is the first few lines in ffmpeg/ffbuild/common.mak 
[22:50:10 CEST] <iive> there's been a merge that touches it, but I can't see anything wrong with the new version.
[22:52:44 CEST] <jamrial> that is meant for .dbg.asm targets, not .o targets
[22:53:21 CEST] <jamrial> it creates pre processed .asm files that can then be assembled to get more readable errors
[22:55:51 CEST] <cone-545> ffmpeg 03James Almer 07master:f66086adac5e: configure: fix assignment of assembler specific flags
[23:00:19 CEST] <michaelni> atomnuker, yes but it fails on x86-32: src/libavcodec/x86/mdct15.asm:116: error: symbol `xmmm8' undefined
[23:01:19 CEST] <durandal_1707> we should drop x86-32 support
[23:02:56 CEST] <atomnuker> jamrial: what's the best way of ifdeffing the asm code for 32 bit systems?
[23:03:06 CEST] <jamrial> atomnuker: just wrap the whole asm function in a %if ARCH_X86_64 check
[23:03:08 CEST] <michaelni> libavcodec/x86/mdct15.dbg.asm:27: error: symbol `xmmm8' undefined
[23:03:31 CEST] <atomnuker> jamrial: wouldn't that result in a compilation error, or do you mean inside the cglobal declaration?
[23:04:37 CEST] <jamrial> atomnuker: wrapping everything below the include line should be good
[23:08:24 CEST] <Compn> durandal_1707 : still a few billion computers running that :P
[23:08:30 CEST] <Compn> maybe
[23:08:55 CEST] <durandal_1707> Compn: yes, spam farms
[23:09:45 CEST] <DHE> or just stop offering updated asm for 32 bit mode?
[23:09:55 CEST] <atomnuker> jamrial: ah, because of DCE in the init function, got it
[23:11:32 CEST] <jamrial> atomnuker: yeah, the init is DCE'd away in the .c file, and the .asm file doesn't assemble anything after you wrap things in a check for x86_64
[23:12:35 CEST] <Compn> DHE : split 32bit and 64bit asm ? i dont think too much x86 asm is being written now anyway
[23:12:43 CEST] <Compn> unless thats what atomnuker was doing :D
[23:13:46 CEST] <durandal_1707> Compn: never reveal your weakness
[23:14:34 CEST] Action: Compn runs
[23:14:45 CEST] <atomnuker> michaelni: sent a new patch to fix this
[23:14:49 CEST] <DHE> Compn: on a personal note dropping 32 bit support seems a bit much, but I also agree that no half-modern system should be running 32 bit hardware or operating systems anymore...
[23:14:58 CEST] <durandal_1707> Compn: why you have supreme powers at all...
[23:16:15 CEST] <atomnuker> if we drop 32 bit support we'd never see the work and lengths people went to make do with barely 7 usable registers
[23:16:32 CEST] Action: Compn stuffs durandal_1707 into 7 regs
[23:17:07 CEST] <durandal_1707> that reminds me, when will be next irc supreme meeting?
[23:17:07 CEST] <DHE> even Atom CPUs have been available in 64 bit variants since 2011 (I have one)
[23:17:23 CEST] <atomnuker> (though yeah, the majority of 32 bit users are all on non-x86 platforms)
[23:17:51 CEST] <iive> you mean arm phones?
[23:18:33 CEST] <Compn> durandal_1707 : i cant remember who calls those to order. maybe ubitux ?
[23:19:09 CEST] <durandal_1707> Compn: i call for it!
[23:19:25 CEST] <Compn> post to -devel with a proposed date/time ?
[23:20:01 CEST] <jamrial> why would there be one right now?
[23:20:24 CEST] <Compn> e.g. what topic would durandal_1707 want to discuss ?
[23:20:26 CEST] <durandal_1707> first need to find out if anybody will come
[23:20:37 CEST] <Compn> durandal_1707 : are you coming to VDD this year ?
[23:21:07 CEST] <jamrial> unless there are several subjects to discuss about, please don't try to call a meeting
[23:21:24 CEST] <durandal_1707> Compn: proposig new security officers and new irc admins
[23:21:58 CEST] <jamrial> that sounds more like a vote, and we added new people to sec a few months ago
[23:22:13 CEST] <Compn> oh you mean why am i founder of this channel ehhe
[23:23:28 CEST] <Compn> possibly because i dont mess with the channel at all
[23:23:33 CEST] <durandal_1707> 32tb of win code leaked
[23:23:45 CEST] <Compn> durandal_1707 : who are you proposing to be irc admin? 
[23:23:50 CEST] <Compn> if you have any suggestions
[23:25:17 CEST] <Compn> durandal_1707 : VDD dates for paris,france this year  > 22-24 Sept.
[23:25:17 CEST] <durandal_1707> Compn: only me, ubitux and michaelni 
[23:26:00 CEST] <Compn> i have no objection...
[23:26:02 CEST] <durandal_1707> VDD is irrelevant
[23:26:13 CEST] <Compn> yes is unrelated, just letting you know
[23:27:14 CEST] <Compn> durandal_1707 : if you think i've done something wrong in irc, you can tell me.
[23:27:26 CEST] <atomnuker> durandal_1707: holy shit
[23:27:27 CEST] <Compn> or even ban me, i wont ban evade...
[23:27:52 CEST] <Compn> atomnuker : are you coming to vdd ?
[23:28:19 CEST] <durandal_1707> Compn: nooo, you are only remaining legacy left
[23:28:28 CEST] <Compn> oh its windows 10 :
[23:28:53 CEST] <atomnuker> Compn: I'm giving another talk there, so yeah
[23:29:21 CEST] <durandal_1707> about what?
[23:31:53 CEST] <atomnuker> opus
[23:34:37 CEST] <BBB> not av1?
[23:34:42 CEST] <BBB> then who will talk about av1?
[23:34:50 CEST] <atomnuker> oh crap
[23:35:08 CEST] <BBB> :D
[23:35:34 CEST] <atomnuker> erm, derf's hopefully going there, he needs like an hour to write slides and prepare
[23:35:55 CEST] <durandal_1707> i will talk about lavfi filters, decoders, encoders, reing ...
[23:36:05 CEST] <atomnuker> (though it'll be recycled and somewhat cynical)
[23:36:13 CEST] <atomnuker> durandal_1707: do it, I'd listen
[23:37:02 CEST] <durandal_1707> and nobody else...
[23:37:49 CEST] <durandal_1707> seriously, devs just do wxwidgets stuff
[23:38:45 CEST] <atomnuker> durandal_1707: not at VDD
[23:40:10 CEST] <Compn> durandal_1707 : i'd listen to re stuff for sure :)
[23:40:57 CEST] <BBB> atomnuker: & h& m & m &. m. &.. .. .. I dont know
[23:40:59 CEST] <durandal_1707> why? its complex and daunting
[23:41:24 CEST] <BBB> atomnuker: can monty make his slides and add some graphics/schematics/etc.? like the daala blogs
[23:42:34 CEST] <atomnuker> BBB: AFAIK xiphmont hates going anywhere, though who knows, go ahead and ask him
[23:46:53 CEST] <durandal_1707> we should organize FFDD
[23:50:50 CEST] <atomnuker> michaelni: does the latest patch fix x86_32 builds?
[00:00:00 CEST] --- Sat Jun 24 2017