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

Tue Feb 28 03:05:04 EET 2017

[10:29:02 CET] <cone-982> ffmpeg 03Carl Eugen Hoyos 07master:f8d2079a6786: ffmpeg: Add a linebreak to an error message.
[10:58:28 CET] <pszemus> Hi, could anyone refer to http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207461.html ? I can provide more details about what I'm trying to accomplish there.
[11:04:19 CET] <kierank> https://blog.sesse.net/blog/tech/2017-02-27-01-02_10_bit_h264_tests
[11:21:27 CET] <JEEB> haha :D
[11:21:40 CET] <JEEB> yea, the bad part is that all the AVC ASICs don't support it
[11:41:34 CET] <JEEB> ugh, I still dislike the fact that the end of that article still tries to say that some things support 10bit AVC in HW, which is not true
[11:41:51 CET] <JEEB> you might get very little artifacts out of decoding some samples as 8bit
[11:41:57 CET] <JEEB> but it doesn't mean 10bit is supported
[11:42:33 CET] <JEEB> and given how <beep> expensive any ASIC that supports even intra 10bit is, it's highly unlikely that anything that costs less than 1000 euros (or so) without the brand fee included has 10bit AVC support
[11:46:35 CET] <jkqxz> Sounds like an opportunity for x264½, which encodes to H.265 using only H.264 features (and is therefore much faster and simpler than x265).
[11:47:53 CET] <JEEB> yea
[11:49:01 CET] <JEEB> although quite a few people don't want to touch HEVC with a long stick
[11:57:15 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:05aa53dc553a: avcodec/qdrw: fix decoding odd size images for 16bit case
[11:57:16 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:dc78696ea4b8: avcodec/qdrw: fix decoding odd size images for 2bpp and 4bpp
[11:57:17 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:1dcf91f2d360: avcodec/qdrw: fix decoding of odd sized images for 8bpp
[12:06:39 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:3a7f8d2a1f30: avcodec/qdrw: consume bytes when end is reached for 8bpp case
[12:22:58 CET] <wm4> jkqxz: deinterlace_vaapi gives me green (though admittedly I've only tried via mpv, so might be my fault)
[12:23:46 CET] <jkqxz> Um, try not-via-mpv?
[13:09:37 CET] <cone-982> ffmpeg 03Paul B Mahol 07h264_assembly:HEAD: avcodec/qdrw: consume bytes when end is reached for 8bpp case
[13:09:59 CET] <J_Darnley> Oh shit.
[13:10:21 CET] <J_Darnley> That's the wrong branch
[13:11:14 CET] <cone-982> ffmpeg 03Carl Eugen Hoyos 07master:1e298e772400: lavc/svq3: Remove an unused function.
[13:11:56 CET] <durandal_1707> J_Darnley: just push it to correct branch
[13:12:04 CET] <durandal_1707> if possible
[13:12:11 CET] <durandal_1707> :)
[13:14:32 CET] <atomnuker> J_Darnley: you can't delete branches too so msg thresh to remove it
[13:16:12 CET] <J_Darnley> Sorry, who?
[13:16:46 CET] <durandal_1707> thresh on #videolan
[13:22:42 CET] <cone-982> ffmpeg 03James Darnley 07master:5c56758843eb: avcodec/h264: add avx 8-bit chroma v deblock/loop filter
[13:22:43 CET] <cone-982> ffmpeg 03James Darnley 07master:ac096fc82df6: avcodec/h264: add avx 8-bit 4:2:0 chroma h deblock/loop filter
[13:22:45 CET] <cone-982> ffmpeg 03James Darnley 07master:88307b3eec01: avcodec/h264: add avx 8-bit 4:2:2 chroma h deblock/loop filter
[13:22:45 CET] <cone-982> ffmpeg 03James Darnley 07master:987ffe4b8dce: avcodec/h264: add avx 8-bit chroma v intra deblock/loop filter
[13:22:46 CET] <cone-982> ffmpeg 03James Darnley 07master:0e16b3e2be3a: avcodec/h264: add avx 8-bit 4:2:0 chroma h intra deblock/loop filter
[13:22:47 CET] <cone-982> ffmpeg 03James Darnley 07master:cd893b9307b8: avcodec/h264: add avx 8-bit 4:2:2 chroma h intra deblock/loop filter
[13:22:48 CET] <cone-982> ffmpeg 03James Darnley 07master:33de0fee2c33: avcodec/h264: enable sse2 chroma deblock/loop filter functions
[13:38:10 CET] <J_Darnley> durandal_1707: I have but I guess he is offline/afk
[13:38:20 CET] <J_Darnley> Do you know what TZ he's in?
[13:42:37 CET] <durandal_1707> J_Darnley: he was just active before you joined
[13:43:31 CET] <J_Darnley> Weird.  No response to my message.  I guess I'll do it publically
[13:59:27 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:86ab6b6e08e2: avcodec/scpr: check if total_freq is 0 in decode0
[14:07:14 CET] <durandal_1707> he might not be near machine
[14:19:51 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:26a7d6a301b9: avcodec/qdrw: check bytes per scanline for 2bpp images
[14:35:06 CET] <jkqxz> wm4:  Driver?  (I assume you intended that to be here.)
[14:36:20 CET] <jkqxz> I test with current versions of both Intel drivers and Mesa; I haven't looked at older versions beyond ensuring that it builds with old headers.
[14:37:32 CET] <wm4> jkqxz: I don't know, whatever you normally use with Intel
[14:37:54 CET] <wm4> vainfo says i965 for broadwell
[14:38:39 CET] <wm4> also I still get an assertion failure instead of an error if I try to allocate more surfaces than the pool size
[14:38:50 CET] <jkqxz> Version?  I can try on Braswell, which should be the same.
[14:39:19 CET] <wm4> how do I find out the version?
[14:45:02 CET] <jkqxz> vainfo should tell you.  (Or your package manager.)
[14:45:35 CET] <wm4> 0.39 1.7.3
[14:45:44 CET] <wm4> actually 0.39.4
[14:45:59 CET] <wm4> these are all numbers it shows
[14:46:35 CET] <jkqxz> That's it; 1.7.3 is the driver version and 0.39.4 is the API version.
[14:47:21 CET] <jkqxz> Also urgh, that is recent and should work.
[14:47:47 CET] <jkqxz> I guess I can try later?  Or you could try using a different driver and/or different hardware.
[14:47:53 CET] <wm4> oh I thought 1.7.3 was the libva release version (while 0.39.4 is the pkg-config version)
[14:48:06 CET] <wm4> I was wondering how you output 2 fields in this filter
[14:48:13 CET] <wm4> or is that missing?
[14:48:57 CET] <BtbN> that shouldn't be a problem for a filter, should it? yadif and others do it as well
[14:49:51 CET] <jkqxz> Wrt assertion failure, I forgot about that one.  It's still somewhere on the merge queue.
[14:49:56 CET] <jkqxz> (Merge it yourself if you like.)
[14:50:04 CET] <wm4> I'm just fighting with a problem with my own code where the fields seem switched or something when using something more advanced than bob
[14:50:15 CET] <wm4> jkqxz: oh ok, I thought that was merged
[14:50:46 CET] <wm4> jkqxz: why not just push it
[14:51:59 CET] <jkqxz> Because I'm not at a machine with suitable keys.
[14:58:47 CET] <jkqxz> The field handling is not there in the driver.  You put an interleaved frame in and a deinterlaced frame comes out and that's about it.
[15:02:15 CET] <BtbN> When I implemented the VPP deinterlacer for kodi, it could definitely output two progressive frames from one interlaced input frame.
[15:04:19 CET] <jkqxz> Were they different?
[15:04:26 CET] <J_Darnley> pscp --help
[15:06:56 CET] <BtbN> jkqxz, yes
[15:08:56 CET] <wm4> BtbN: I mean it works for bob
[15:09:15 CET] <BtbN> Definitely at least for Motion Adaptive DI as well
[15:09:31 CET] <wm4> but I can't get it to output in the right order for motion adaptive
[15:09:55 CET] <wm4> so when frame-stepping it appears to go backwards one frame
[15:10:16 CET] <wm4> well that can't really be, so I'm wondering wth I'm doing wrong here
[15:10:29 CET] <BtbN> Top-First vs. Bottom-First reversed?
[15:10:49 CET] <BtbN> with bob that wouldn't really matter, for for MaDi it does
[15:11:23 CET] <wm4> something like this, I just couldn't find where I would have done that wrong
[15:12:50 CET] <BtbN> Maybe it's wrong in the deinterlacer itself, and nobody ever tested it with frame-doubling before?
[15:14:06 CET] <wm4> I very much doubt that
[15:50:50 CET] <adeeln_> Could someone un-ban my original username 'adeel'?
[15:54:21 CET] <BBB> theres no such ban in the banlist afaics
[15:54:54 CET] <J_Darnley> Is there a macro that will shuffle qwords around to do this http://pastebin.com/DcqPD1NN with fewer loads?
[15:55:05 CET] <adeeln_> oh, okay. I'll check.
[15:55:34 CET] <adeeln_> durandal_1707: I manually removed the comments, but I'm still getting 'invalid data found when processing input' output
[15:56:18 CET] <BBB> J_Darnley: mova x4 and then SBUTTERFLY qdq 0, 1, tmp and 2, 3, tmp
[15:56:32 CET] <J_Darnley> thanks
[15:56:49 CET] <BBB> J_Darnley: but I doubt its faster (itll have 4 loads instead of 8, but then it adds 2x4 punpck[lh]qdq
[15:56:57 CET] <BBB> worth testing maybe
[15:57:09 CET] <J_Darnley> It also avoids the int-float transition
[15:57:20 CET] <BBB> fair enough
[16:01:23 CET] <Gramner> just make sure to do the loads in the order +0, +32, +16, +48
[16:02:03 CET] <Gramner> also movhps is p5 anyway so using sbutterfly should be preferrable
[16:02:31 CET] <Gramner> movhps when used as load that is
[16:13:38 CET] <J_Darnley> BBB: Actually, it is even worse.  I need 4 butterflies
[16:14:10 CET] <BBB> ?
[16:14:30 CET] <BBB> it shouldnt?
[16:15:18 CET] <BBB> punpckl+hqdq m0, m1 after mova m0, [mem+0] and mova m1, [mem+32] should put mem+0 in m0:low, mem+8 in m1:low, mem+32 in m0:high and mem+40 in m1:high?
[16:15:46 CET] <Gramner> mova m0, [r2+0]; mova m1, [r2+32]; mova m2, [r2+16]; mova m3, [r2+48]; SBUTTERFLY qdq, 0, 1, tmp; SBUTTERFLY qdq, 2, 3, tmp;
[16:15:57 CET] <BBB> right
[16:16:51 CET] <J_Darnley> Oh well it would help if I loaded from memory correctly
[16:16:59 CET] <J_Darnley> :D sorry
[16:17:20 CET] <BBB> typos in assembly are horrible yes
[16:17:28 CET] <BBB> (horrible = undebuggable)
[16:18:17 CET] <Gramner> I wonder if I should make some sort of printf macro
[16:18:22 CET] <Gramner> for x86inc
[16:18:42 CET] <J_Darnley> oh god.  Compile time or run time?
[16:19:06 CET] <Gramner> run time. there's asserts for compile time already
[16:19:35 CET] <Gramner> just some easy way to print values without having to user a debugger every single time
[16:19:37 CET] <BBB> I usually just have a hex_dump function built in and call that
[16:19:46 CET] <BBB> but that does indeed require me to move registers into memory
[16:20:05 CET] <BBB> printing registers outside a debugger would be very useful
[16:21:59 CET] <durandal_1707> adeeln_: you need to add code to skip C comments
[16:22:43 CET] <J_Darnley> Hey.  It might have got me 1 percentage point faster
[16:22:49 CET] <J_Darnley> (from 1 to 2)
[16:22:55 CET] <BBB> oh nice
[16:23:40 CET] <durandal_1707> is 10bit h264 path optimized enough?
[16:28:46 CET] <J_Darnley> durandal_1707: enough for who?
[16:29:16 CET] <J_Darnley> There's a similar number of lines assigning function pointers for both 8 and 10 bit
[16:29:51 CET] <J_Darnley> 10 bit may get more benefit from avx2 and its wider registers
[16:30:42 CET] <kierank> durandal_1707: J_Darnley is working on this, yes
[16:32:01 CET] <durandal_1707> awesome
[16:33:56 CET] <J_Darnley> If you have a particular function slowing you down please name it.
[16:36:27 CET] <BBB> J_Darnley: I think hes just looking for stuff for you to do :-p
[16:36:43 CET] <BBB> (btw this work is great, dont take this negatively, Im really happy someone is optimizing h264 further)
[16:37:12 CET] <J_Darnley> I've got plenty to do :)
[16:37:31 CET] <BBB> nice
[16:38:03 CET] <BBB> and yes avx2 should give some gains (for both 8 as well as 10bit, although probably more for 10bit) in things like idct_add_block and mc
[16:38:15 CET] <BBB> or I forgot what that stuff is called in h264dsp
[16:39:10 CET] <BBB> idctN_addM
[16:39:37 CET] <BtbN> I wonder how ryzen will do in terms of AVX performance
[16:39:56 CET] <BtbN> And AVX2
[16:40:18 CET] <J_Darnley> Oh, does AMD finally have it?
[16:41:01 CET] <Gramner> ryzen has 128-bit SIMD
[16:41:10 CET] <Gramner> so avx2 is useless on it
[16:41:15 CET] <adeeln_> durandal_1707: The error says "Invalid data found when processing input" which is not present in 'xpmdec.c' file
[16:41:25 CET] <adeeln_> Not sure if C comments is causing it.
[16:41:27 CET] <BtbN> Yes, but with two cycles per instruction, compared to Intel where its one
[16:41:34 CET] <BtbN> but Ryzen does not need to clock down for it
[16:41:44 CET] <jamrial> Gramner: you're shitting me
[16:41:51 CET] <jamrial> no 256bit simd?
[16:41:57 CET] <Gramner> correct
[16:42:14 CET] <durandal_1707> adeeln_: you get that error message when receiving specific error code
[16:42:15 CET] <BtbN> it supports the instructions though, but breaks it down to 128bit internally I guess, hence the two cycles
[16:42:26 CET] <jamrial> no fucking way. i thought they would finally get a decent fp unit after getting rid of bulldozer
[16:42:34 CET] <Gramner> it makes sense though for what amd is trying to do. very few applications uses avx so they spent their time and effort on the stuff that has the largest impact
[16:42:37 CET] <adeeln_> okay.
[16:43:02 CET] <BtbN> Yeah, supporting AVX and AVX2 is important, but having it super performant is more a bonus.
[16:43:25 CET] <BBB> so were going to have that crap avxslow thing again?
[16:43:28 CET] <BBB> like sseslow etc.
[16:43:29 CET] <jamrial> ugh
[16:43:31 CET] <Gramner> i'm guessing they'll widen their simd units in one of the next archs, e.g. zen+, zen++ or whatever they're gonna call it
[16:43:37 CET] <jamrial> yeah, will have to add a check for family 0x17 i guess
[16:43:53 CET] <BBB> pff&
[16:44:02 CET] <BBB> so I guess datacenters will keep using intel
[16:44:04 CET] <BtbN> Wonder if I'll be able to just upgrade on my AM4 board I ordered.
[16:44:15 CET] <BtbN> My 1800X will be here on Friday or Saturday.
[16:44:23 CET] <J_Darnley> Zen, Zen+, Zen Double Plus, Zen Double Plus Good
[16:44:47 CET] <Gramner> "datacenters" is such a generic term though. yes if you're youtube and spend all your clock cycles encoding video then yes, you're going to keep using intel
[16:44:51 CET] <jamrial> ryzen is the first cpu with the sha instruction set, though
[16:45:01 CET] <BBB> Gramner: thats all I care about ;)
[16:45:03 CET] <jamrial> at least that's what gcc says
[16:45:04 CET] <kierank> some of the kaby lake pentiums are interesting
[16:45:16 CET] <kierank> super cheap with dual core hyperthreading
[16:45:18 CET] <kierank> but no avx(2)
[16:45:50 CET] <BtbN> Once Ryzen R3 and R5 comes out those will have a hard time selling
[16:46:01 CET] <J_Darnley> I'm considering a Kaby Lake Celeron for a NAS because it supports ECC
[16:46:21 CET] <jamrial> why? high end ryzen is already like half the price of a similar performance i7
[16:46:21 CET] <BtbN> Ryzen also supports ECC. But so far no mainboard does...
[16:46:40 CET] <jamrial> low end would destroy pentium/i3 if also priced right
[16:46:51 CET] <BtbN> jamrial, well, but the cheapest ryzen is still way more expensive and overpowered than a Celeron
[16:47:01 CET] <BtbN> jamrial, that's what I meant.
[16:47:08 CET] <BtbN> The Intel ones will have the hard time, not Ryzen
[16:47:23 CET] <jamrial> oh right, misread what you said
[16:47:42 CET] <Gramner> ryzen is likely going to be awesome when it comes to performance/$
[16:47:56 CET] <BtbN> I'm upgrading to it from my i5-2500k
[16:48:03 CET] <jamrial> we're about to have a cpu with the sha instruction set and we still haven't commited the aes-ni patchset :P
[16:48:10 CET] <BtbN> I don't even care if it's the best performing CPU out there, it will definitely be fast enough.
[16:52:46 CET] <Gramner> intel extreme editions will probably still be the way to go for max performance, but they're stupidly expensive. there hasn't been any reason for intel to drop prices when they keep selling 6950X for $1700 but ryzen will likely change that
[16:53:16 CET] <BtbN> Well, the 1800X supposedly outperforms the Intel Extreme 8 core
[16:53:40 CET] <BtbN> Also, http://wccftech.com/amd-ryzen-architecture-detailed/ claims "The floating point unit is capable of performing two FMAC operations or a single 256-bit AVX operation per cycle."
[16:53:46 CET] <BtbN> no idea how accurate that is
[16:54:23 CET] <kierank> always about the float
[16:55:22 CET] <Gramner> hmm, everything I've read about ryzen so far has indicated 128-bit simd units
[16:55:42 CET] <BtbN> Guess we'll know for sure in 3 days
[16:56:15 CET] <BtbN> Would have been amazing if they supported AVX-512 right away
[16:56:49 CET] <jkqxz> jamrial:  The SHA instructions are already in Goldmont (the newest Atom arch, from last year).
[16:57:15 CET] <jkqxz> (Which also probably benefits rather more from it...)
[16:58:30 CET] <BtbN> is it useful for more than sha1?
[16:59:08 CET] <Gramner> also skylake-x is coming later this year. would be kind of funny if intel starts going the previous amd route of competing by adding more cores.
[16:59:36 CET] <BtbN> Intel can't really add more cores without dropping the clock speed
[17:00:02 CET] <Gramner> sure you can, just add more ln2 ;)
[17:02:12 CET] <kierank> skylake e5 xeons are out on google cloud
[17:02:26 CET] <kierank> dunno if we should get one
[17:03:21 CET] <BtbN> Gramner, maybe some wrong information comes from the gcc patch that adds march=znver1?
[17:03:33 CET] <BtbN> Because it says "Costs and tunings are copied from bdver4,  but we will be adjusting them later for znver1."
[17:04:05 CET] <Gramner> maybe. but as you said - we'll know soon enough for certain
[17:04:38 CET] <BtbN> I just hope they don't come up with a fixed and improved stepping or whatever in a few months...
[17:10:25 CET] <adeeln_> durandal_1707: I manually removed comments from XPM file, but it's still not working. However, I did write up some logic: https://gist.github.com/adl1995/ee41f6c27d3922150664d0964a90f146
[17:10:43 CET] <adeeln_> haven't worked with uint_8 much
[17:11:31 CET] <durandal_1707> uint8 is byte
[17:13:22 CET] <durandal_1707> adeeln_: find out where it returns error
[17:13:49 CET] <durandal_1707> does decode frame ever get called?
[17:14:35 CET] <adeeln_> probably not.
[17:16:06 CET] <durandal_1707> adeeln_: it should get called
[17:16:50 CET] <adeeln_> How would I go on about doing that?
[17:19:06 CET] <adeeln_> Error comes from "FFmpeg/libavutil/error.c"
[17:20:47 CET] <jamrial> BtbN: sha256 as well afaik
[17:22:17 CET] <adeeln_> durandal_1707: How is the workflow set up for decoder and encoders?
[17:22:23 CET] <adeeln_> where could I learn?
[17:23:47 CET] <durandal_1707> adeeln_: just add printf right at beginning of decode frame of xpm
[17:24:21 CET] <durandal_1707> adeeln_: also you could get gui debugger running
[17:26:55 CET] <adeeln_> It's always the simplest solution, isn't it? :D
[17:27:10 CET] <adeeln_> will check out gui debugger
[17:31:06 CET] <BtbN> aparently the Hyper Threading on Zen will be asymetric? Like, one thread has priority over the other.
[17:31:16 CET] <BtbN> Sounds like a lot of fun if your scheduler is not aware
[17:31:52 CET] <nevcairiel> (don't take a site like wccftech as too much authority on real infos)
[17:32:20 CET] <BtbN> Yeah, they have a bit too much info for things still under NDA
[17:32:38 CET] <nevcairiel> its a rumor mill and guess factory
[17:32:55 CET] <Gramner> wccftech posts every rumor found on the net as news. they just happen to be right occasionally
[17:33:03 CET] <nevcairiel> real infos come out friday? i think
[17:33:10 CET] <BtbN> Thursday, the 3rd
[17:33:15 CET] <BtbN> On Friday I will hopefully have mine
[17:33:24 CET] <nevcairiel> but firday is the third
[17:33:48 CET] <nevcairiel> and i don't pre-order hardware without knowing what it can do =p
[17:34:05 CET] <BtbN> Well, I need an upgrade for my PC anyway
[17:34:10 CET] <BtbN> And it will be fast enough
[17:34:26 CET] <BtbN> It releases on the 2nd, not 3rd
[17:35:52 CET] <nevcairiel> i'm mostly interested in single-thread performance, I expect it still to lack behind intel clock-by-clock, nearly all benchmarks that have been used by AMD marketing have been massive multi-threading
[17:37:52 CET] <BtbN> I'll be sure to test ffmpeg on it.
[17:38:07 CET] <BtbN> I'm positive it will outperform my SandyBridge
[18:22:03 CET] <reynaldo> get got accepted to gsoc :)
[18:22:46 CET] <reynaldo> we/ even
[18:25:33 CET] <adeeln_> durandal_1707: Just added "printf("Testing XPM decoder");" at the beginning, but it's not getting printed
[18:29:22 CET] <JEEB> you need to use av_log in lavf/c
[18:34:50 CET] <durandal_1707> printf also works
[18:39:01 CET] <durandal_1707> adeeln_: does it get probed at all?
[18:39:35 CET] <durandal_1707> add debug flags to ffplay
[20:07:36 CET] <adeeln_> durandal_1707: Getting this "[file @ 0x7f929c005760] Setting default whitelist 'file,crypto' [AVIOContext @ 0x7f929c005e00] Statistics: 1281 bytes read, 0 seeks  /test.xpm: Invalid data found when processing input"
[20:09:42 CET] <stevendz> I noticed a follow file option in the source code for ffmpeg. However, it is not documented anywhere.
[20:09:54 CET] <stevendz> It looks like it is supposed to follow a growing file.
[20:10:32 CET] <stevendz> I wrote some code to that in ffmpeg. Is it worth sumitting, or did I just reinvent the wheel?
[20:11:03 CET] <JEEB> that sounds like exactly that feature in lavf :)
[20:11:15 CET] <JEEB> and I'm pretty sure it's documented in `ffmpeg -h full`
[20:11:17 CET] <durandal_1707> adeeln_: perhaps, look how xwd probing is done
[20:17:24 CET] <adeeln_> durandal_1707: Going through this: [https://trac.ffmpeg.org/wiki/FFprobeTips]
[20:18:10 CET] <adeeln_> Gotta get to bed. See ya tomorrow
[20:20:15 CET] <stevendz> Maybe I'm mistaken. What exactly is the -follow option supposed to do?
[20:21:44 CET] <JEEB> stevendz: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/file.c#L84
[21:00:25 CET] <chatter29> hey guys
[21:00:27 CET] <chatter29> allah is doing
[21:00:34 CET] <chatter29> sun is not doing allah is doing
[21:00:35 CET] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
[21:02:56 CET] <J_Darnley> Oh wow.  The islam spam bots are back.  I haven't seen one of those in quite a while
[23:22:31 CET] <J_Darnley> lol wut.  This function changes sse2->mmx->sse2
[23:24:38 CET] <BBB> yeah we have a couple of very strange ones
[23:24:40 CET] <jamrial> J_Darnley: let me guess, using one of the obscure mov instructions that go xmm -> mmx and vice versa?
[23:24:49 CET] <BBB> movq2dq/dq2q
[00:00:00 CET] --- Tue Feb 28 2017