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

[burek]

[00:11:18 CEST] <Mysoft> has anyone here, have heard or seen, some acceleration for x264 
[00:11:24 CEST] <Mysoft> using OpenGL shaders?
[00:11:37 CEST] <Mysoft> like plain simple 2.1 shaders to speed up x264 tasks using the GPU
[00:11:52 CEST] <Mysoft> as alternative methods :)
[00:17:09 CEST] <nevcairiel> people tried using OpenCL compute shaders instead, and the benefit was barely zero
[00:17:34 CEST] <Mysoft> yes
[00:17:43 CEST] <Mysoft> because cards that have OpenCL
[00:17:54 CEST] <Mysoft> also have nvidia and dxva/dxva2 and etc..
[00:18:05 CEST] <Mysoft> and they are being used on multi-ghz computers
[00:18:05 CEST] <nevcairiel> and thats related to encoding with x264 how? :)
[00:18:34 CEST] <Mysoft> but for old cards... and 1ghz computers that barely have OpenGL2.0 cards
[00:18:40 CEST] <Mysoft> those DO help
[00:18:43 CEST] <Mysoft> much more hehe
[00:18:47 CEST] <nevcairiel> so you assume
[00:18:57 CEST] <nevcairiel> but you dont have any evidence of that, or do you?
[00:19:15 CEST] <Mysoft> nop, because nobody attempted
[00:19:24 CEST] <nevcairiel> copying data to and from the gpu costs a lot of overhead
[00:19:35 CEST] <nevcairiel> so the advantage would have to be significant to not vanish in overhead
[00:19:48 CEST] <Mysoft> so you reduce the amount that need to be copied
[00:20:10 CEST] <nevcairiel> .. and there probably just are not enough processing steps in x264 that are simple enough and parallel enough that shaders could do them properly
[00:20:40 CEST] <Mysoft> well i don't know that much about encoding to guess deep enough
[00:20:51 CEST] <Mysoft> but the part that actually use the quantizers to generate the blocks
[00:20:58 CEST] <Mysoft> that math could be done entirely with shaders
[00:21:14 CEST] <Mysoft> so the final image would be generated directly on the GPU
[00:21:29 CEST] <iive> using pixel shader is a bit problematic, because it outputs a single pixel of information.
[00:21:58 CEST] <Mysoft> the part of the algorithm that decodes the 8x8 blocks
[00:22:07 CEST] <Mysoft> doesnt require to repeat the same "math" for each pixel?
[00:22:11 CEST] <Mysoft> on that block...
[00:22:35 CEST] <Mysoft> or they need to be synchronous/recursive?
[00:23:04 CEST] <Mysoft> i tought it do that because of the ffplay option... that allow to decode at smaller resolution
[00:23:22 CEST] <Mysoft> so i assume that instead of decoding to blocks of 8x8 ... it would decode to blocks of 4x4
[00:23:27 CEST] <nevcairiel> lowres decoding doesnt work with h264
[00:23:35 CEST] <Mysoft> yeah i noticed that too :P
[00:23:43 CEST] <Mysoft> which would be wonderful if it did
[00:23:51 CEST] <nevcairiel> but it never will
[00:23:59 CEST] <iive> you can have lowres decoding if you decode only dc coefficients , aka all 8x8 block have same color.
[00:23:59 CEST] <Mysoft> beacuse my old laptop can't handle 1920x1080 hehe
[00:24:06 CEST] <nevcairiel> h264 is too complex for that, it has various features that are fundamentally incompatible with that
[00:24:10 CEST] <Mysoft> so you can have 1/8 only?
[00:24:31 CEST] <Mysoft> does that mean that could be used for 4k decoding?
[00:24:32 CEST] <Mysoft> hahaha
[00:24:44 CEST] <iive> it would still look bad
[00:24:45 CEST] <Mysoft> or 4k uses bigger blocks? :P
[00:24:57 CEST] <nevcairiel> you would still run into a bunch of trouble with prediction
[00:24:59 CEST] <iive> h264 can have 4x4 blocks
[00:25:25 CEST] <Mysoft> ah yeah... true :)
[00:25:40 CEST] <nevcairiel> someone else asked about lowres for h264 just a few weeks ago, and we determined that its just not possible to do that for h264
[00:25:42 CEST] <iive> are you familiar with fourier transformation?
[00:25:57 CEST] <nevcairiel> any result from that would just be horrible :)
[00:26:53 CEST] <Mysoft> yeah a bit... since i used it for DTMF signal decoding
[00:28:53 CEST] <iive> ok, dct is descrete cosine transformation, aka ignoring the sine part.
[00:29:55 CEST] <iive> to get it to 2d, you do 8 rows, then 8 colums (or vice versa). basically to get 1 pixel you have to process all 8x8 input samples for every shader.
[00:31:56 CEST] <Mysoft> ok
[00:32:15 CEST] <Mysoft> altough hq2x scalers also have to do something similar
[00:32:55 CEST] <iive> you actually might have more luck with trying to some of the existing speed up options.
[00:33:20 CEST] <iive> e.g. you can try to disable the loopfilter entirely.
[00:33:32 CEST] <nevcairiel> you can also skip frames
[00:33:34 CEST] <Mysoft> deblocking?
[00:33:36 CEST] <Mysoft> and skip frames
[00:33:39 CEST] <nevcairiel> but of course that degrades quality
[00:33:48 CEST] <Mysoft> i did that with ffplay 
[00:34:06 CEST] <Mysoft> so i could run 1280x720 at 60fps on that notebook
[00:34:22 CEST] <Mysoft> altough ffplay is considerable slower than mpc-hc for obvious reasons
[00:34:53 CEST] <Mysoft> but no matter what i try... it sems to not keep the video playing at 100%
[00:35:11 CEST] <Mysoft> maybe because the frameskip on ffdshow and internal decoders of those are limited to 1 frame
[00:35:22 CEST] <Mysoft> while on ffplay it seems to be doing multiple frameskip
[00:35:46 CEST] <iive> there is also a way to use halfpel motion compensation. that might not always be fast, i've heard the hpel is mmx, while h264 qpel have sse/avx, but since your laptop is old... 
[00:35:50 CEST] <Mysoft> which would be acceptable since i'm getting about 92% of the speed
[00:36:05 CEST] <Mysoft> it has SSE... but not SSE2
[00:37:24 CEST] <iive> frameskip is probably used to drop b-frames, since they are (usually) not used for prediction
[00:37:38 CEST] <Mysoft> i wish i could use DXVA... but seems the card there doesnt have dxva for h264...
[00:37:44 CEST] <iive> so the number of droppable frames depends how the steam is encoded.
[00:37:55 CEST] <Mysoft> and seems the twitch stream despite being x264 isnt DXVA compatible (on source quality)
[00:37:58 CEST] <iive> dxva is windows, are you on windows?
[00:38:03 CEST] <Mysoft> yes
[00:38:37 CEST] <TD-Linux> you could also visit your local electronics recycling center and pick up a better laptop
[00:38:38 CEST] <nevcairiel> skip has various modes, most prominently non-ref (b-frames only mostly) and non-key (everything but I frames really)
[00:38:53 CEST] <Mysoft> TD-Linux i prefer smart solutions :)
[00:39:00 CEST] <TD-Linux> that was a smart solution.
[00:39:03 CEST] <Mysoft> no
[00:39:06 CEST] <Mysoft> that is the dumb solution
[00:39:38 CEST] <iive> nevcairiel: sure, but i frames tend to be 10 seconds away.
[00:39:53 CEST] <Mysoft> you know people don't win at olympics... by doing easy decisions do you? :)
[00:40:09 CEST] <nevcairiel> noone is going to come up with a fancy solution for hardware from two decades ago
[00:40:15 CEST] <Mysoft> well i will :)
[00:40:18 CEST] <nevcairiel> so either replace it or watch slowmo
[00:40:21 CEST] <Mysoft> i always do :)
[00:40:28 CEST] <Mysoft> hence why my main computer is still using windows XP
[00:40:59 CEST] <Mysoft> despite being a new computer
[00:41:46 CEST] <Mysoft> and so similar i created several compatibility modules so apps like even ffmpeg can run as if it was vista+
[00:41:57 CEST] <Mysoft> but with the lightweight conditions of XP... and so on
[00:42:10 CEST] <nevcairiel> ffmpeg still runs fine on XP, you must be misinformed :p
[00:42:22 CEST] <Mysoft> then try to download the lastest 32bit version
[00:42:23 CEST] <Mysoft> and run on XP
[00:42:25 CEST] <Mysoft> :)
[00:42:37 CEST] <nevcairiel> we dont offer binaries
[00:42:53 CEST] <nevcairiel> how any inofficial binaries are built is out of our control
[00:42:59 CEST] <Mysoft> yes i know
[00:43:02 CEST] <nevcairiel> but the ffmpeg code requires nothing that is not present on XP
[00:43:14 CEST] <nevcairiel> although that may as well change
[00:43:16 CEST] <Mysoft> yup, hence why i'm not complaining of that problem
[00:43:39 CEST] <Mysoft> i'm just saying that the binaries out there uses mingw64 
[00:43:52 CEST] <Mysoft> that requires _s versions from msvcrt.dll that is something exists on vista+
[00:44:03 CEST] <Mysoft> same goes for python... and a bunch of other GNU compiled stuff
[00:44:06 CEST] <Mysoft> since they don't care...
[00:44:12 CEST] <nevcairiel> nor should they
[00:44:23 CEST] <Mysoft> well i think they should
[00:44:26 CEST] <Mysoft> but i wont demand they do
[00:44:31 CEST] <nevcairiel> XP is a security hole waiting to be exploited now
[00:44:42 CEST] <Mysoft> statistically
[00:44:48 CEST] <Mysoft> XP has less security exploits than win7
[00:45:01 CEST] <iive> Mysoft: what is your video card?
[00:45:05 CEST] <nevcairiel> but in 7 they still get fixed :p
[00:45:10 CEST] <Mysoft> they do?
[00:45:16 CEST] <Mysoft> are you sure? :D
[00:45:40 CEST] <Mysoft> if i was downgrade to 7... in a year they would force me to downgrade even more to 10
[00:45:43 CEST] <Mysoft> so it's a dead end
[00:45:52 CEST] <iive> nevcairiel: actually, no updates are installed until you upgrade to win10 ;)
[00:46:12 CEST] <Mysoft> the only reason that i don't use linux 
[00:46:16 CEST] <Mysoft> is because i like the windows freedom
[00:46:24 CEST] <iive> LOL
[00:46:34 CEST] <iive> Mysoft: what is your video card?
[00:46:36 CEST] <nevcairiel> windows 7 still has security support until at least 2020
[00:46:40 CEST] <Mysoft> oh sorry :)
[00:46:51 CEST] <Mysoft> so on my main computer i have geforce 8800 GTX
[00:47:06 CEST] <Mysoft> that has all nvidia kind of acceleration so for the main computer everything is fine
[00:48:11 CEST] <Mysoft> on the laptop i have an ATI Radeon Xpress 
[00:48:37 CEST] <iive> i guess you can watch h264 on the main desktop computer
[00:48:50 CEST] <Mysoft> well i use the notebook as a secondary monitor
[00:48:56 CEST] <Mysoft> while i do my main things on the main computer
[00:49:11 CEST] <iive> gf 8800 does support hw h264 decoding. pure video or something
[00:49:13 CEST] <Mysoft> so as i said i'm not here really trying to solve a problem
[00:49:24 CEST] <Mysoft> but i got curious about the capabilities of those :)
[00:49:39 CEST] <Mysoft> but on the main computer being a core2quad i can do 1280x720 at 60
[00:49:45 CEST] <Mysoft> with <100% of a single core
[00:49:50 CEST] <Mysoft> so having hw acc there is irrelevant hehe
[00:50:06 CEST] <Mysoft> altough it would help for full HD or 4k :P
[00:50:30 CEST] <Mysoft> and yeah i have the nvidia thing working fine on mpc-hc/vlc-hc etc... here
[00:50:53 CEST] <Mysoft> i was just curious about if anyone tried to push the limits of it for old hardware
[00:50:54 CEST] <Mysoft> :)
[00:51:13 CEST] <Mysoft> like you know we always do that.... trying to have stuff running on old computers :)
[00:51:57 CEST] <Mysoft> but i'm very thankful for the patience for  the input on the matter :)
[00:52:42 CEST] <Mysoft> as most of the time when i try such stuff i only get negative and useless "upgrade it" solutions :P
[00:53:52 CEST] <Mysoft> now i just have to dig deep into libav code... and see how i can do a tiny footprint mpegts -> mp4 (container converter)
[00:53:53 CEST] <nevcairiel> you are free to try anything you want, but unless its directly related to development of ffmpeg itself, maybe try somewhere else? :)
[00:54:13 CEST] <Mysoft> and where is that place
[00:54:15 CEST] <jamrial> Mysoft: sse without sse2 just wont do for video codecs beyond mpeg2
[00:54:19 CEST] <Mysoft> that would have people that understand about x264
[00:54:23 CEST] <Mysoft> to give me hints? :)
[00:55:18 CEST] <Mysoft> jamrial you mean "easily do" 
[00:55:48 CEST] <jamrial> no, just wont do. no integer simd beyond mmx
[00:56:18 CEST] <Mysoft> yeah but it can be adapted
[00:56:47 CEST] <Mysoft> to work with floats and so on
[00:57:08 CEST] <Mysoft> either way... i know it's not simple, or that it would easily give results
[00:57:11 CEST] <nevcairiel> 99.9% of all video codecs dont use floats
[00:57:18 CEST] <Mysoft> that's a implementation problem
[00:57:24 CEST] <Mysoft> not a "potential"
[00:57:37 CEST] <Mysoft> they do because obviously SSE lack of lot to make that easy
[00:57:58 CEST] <nevcairiel> they dont use floats because floats are inaccurate and slow
[00:58:10 CEST] <Mysoft> slower than not using SSE?
[00:59:12 CEST] <Mysoft> i think pairing SSE floats with CPU registers
[00:59:18 CEST] <Compn> asm is fastest
[00:59:19 CEST] <Mysoft> is faster than only use CPU registers
[00:59:21 CEST] <Compn> so they use asm :P
[00:59:34 CEST] <nevcairiel> if you need to convert back and forth just to use SSE float, then yes, its going to be slower :p
[00:59:55 CEST] <Mysoft> yeah so it requires a complete redesign of something that is already very complex
[01:00:04 CEST] <Mysoft> and so it's very costly for little to no effort 
[01:00:08 CEST] <Compn> you dont want to 100% cpu thread anyways. will melt your motherboard caps :P
[01:00:28 CEST] <Mysoft> no
[01:00:39 CEST] <Mysoft> not on those old notebooks they are sturdy warriors!
[01:01:31 CEST] <Mysoft> because they don't do tradeoffs to increase batter life as much as newer ones do
[01:01:50 CEST] <Mysoft> otherwise this 2004 notebook would be dead by now
[01:02:07 CEST] <Mysoft> yet it's outliving 3 generations of "desktops" of mine :P
[01:02:39 CEST] <Mysoft> anyway, i think my next year resolution would make a jpeg decompressor from scratch
[01:02:55 CEST] <Mysoft> and by the end of year having a full x264 decoder writtein by from scratch
[01:03:15 CEST] <nevcairiel> good luck with that
[01:03:19 CEST] <Mysoft> thanks :D
[01:04:40 CEST] <Mysoft> *written by me
[01:20:40 CEST] <Mysoft> ok, i gotta keep going with my work
[01:21:09 CEST] <Mysoft> thanks for the input... and congrats, because ffmpeg is one of the few programs that looks bloated (because the windows binary is now 35mb)
[01:21:33 CEST] <Mysoft> but that in reality has capabilities enough to worth that size :)
[01:22:25 CEST] <nevcairiel> those binaries probably include a whole lot of externa libraries
[01:22:34 CEST] <Mysoft> they do
[01:22:42 CEST] <Mysoft> but ffmpeg also uses a lot of them for a lot of stuff
[01:22:55 CEST] <Mysoft> and supporting that many formats... filters.... codecs... protocols
[01:23:17 CEST] <Mysoft> it really worth the size :)
[01:23:23 CEST] <Mysoft> i was very happy that i could use it to stream to twitch... altough i had to use a "buffering step" on the rtmps:// upload :)
[01:23:35 CEST] <Mysoft> because otherwise it wasnt reaching my internet cap of 60kb/s
[01:23:54 CEST] <Mysoft> since the capture -> encode -> stream steps are synchronous 
[01:25:43 CEST] <Mysoft> but using intermediate buffers worked very nice so i don't use the ugly,slow,bloated OBS useless software that requires Windows 20
[01:25:52 CEST] <Mysoft> so again, congrats :)
[13:40:13 CEST] <ubitux> i'm going to push the merge with michael's patch undoing the behaviour change unless someone wants to look deeper into the issue
[13:40:16 CEST] <ubitux> nevcairiel, michaelni ^
[13:49:24 CEST] <michaelni> ubitux, i agree
[13:52:24 CEST] <michaelni> ubitux, probably best if you add a NOTE or TODO comment about moving the call
[13:58:39 CEST] <cone-091> ffmpeg 03Anton Khirnov 07master:61f168ae348f: h264: factor out setting the parameter sets for a frame
[13:58:40 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:f512e4a39037: Merge commit '61f168ae348f94f39e7afc6971654455a5de0e4d'
[13:58:45 CEST] <ubitux> michaelni: done & applied
[13:58:50 CEST] <ubitux> thanks
[14:06:04 CEST] <cone-091> ffmpeg 03Anton Khirnov 07master:90f469aa2b98: lavc: add H.264 MVC profiles
[14:06:05 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:775389fc59bc: Merge commit '90f469aa2b98a868cdbe35170c24272de10e1341'
[14:08:14 CEST] <cone-091> ffmpeg 03Anton Mitrofanov 07master:a833ff68f6bf: h264: Fix decoding delay for Intra only streams
[14:08:15 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:b4abf0e396d8: Merge commit 'a833ff68f6bf9dc72c3ef0ddf830ebed743c0703'
[14:16:18 CEST] <ubitux> ok so we have "smpte428-1" and libav has "smptest428-1"
[14:16:21 CEST] <ubitux> should we alias them?
[14:16:43 CEST] <ubitux> oh well, maybe we shouldn't care
[14:23:54 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:bcc07e2576cb: pixdesc: Use C99 array to list color properties names
[14:23:55 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:1cfa350429a5: Merge commit 'bcc07e2576cb723007bea1238afd019ae2d1b005'
[14:26:33 CEST] <ubitux> opinions on 05a4bacb?
[14:27:41 CEST] <ubitux> i remember we have a different politic wrt 0-alloc
[14:28:24 CEST] <ubitux> apparently it breaks vorbis test
[14:30:06 CEST] <ubitux> (in lavf/oggdec we can have new_metadata allocated with a zero size)
[14:31:10 CEST] <ubitux>         os->new_metadata = av_malloc(1);
[14:31:12 CEST] <ubitux>         os->new_metadata_size = 0;
[14:31:26 CEST] <ubitux> probably due to this (oggparsevorbis)
[14:44:30 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:05a4bacbf7ec: avpacket: Error out when creating 0-sized side data
[14:44:31 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:415072605b38: Merge commit '05a4bacbf7ece618553d339afe1d0b57bc87aea8'
[14:45:42 CEST] <cone-091> ffmpeg 03Diego Biurrun 07master:84b2d3fb68ca: h264: Drop unused function check_opcodes()
[14:45:43 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:a7ce5b25c03a: Merge commit '84b2d3fb68caf71cff4b80b44ff865d7ae2531ce'
[14:48:41 CEST] <cone-091> ffmpeg 03Diego Biurrun 07master:d6c2c2796d88: LICENSE: Fix silly typo
[14:48:42 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:3536493082be: Merge commit 'd6c2c2796d8885e99fc90793cdd7937826f82fab'
[14:50:09 CEST] <cone-091> ffmpeg 03Diego Biurrun 07master:a2ddfadc2d9e: avdevice: Ignore timefilter test program
[14:50:10 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:1ad3ffadd910: Merge commit 'a2ddfadc2d9e91cf70aa7430a7340b418bdb5b42'
[14:55:10 CEST] <cone-091> ffmpeg 03Martin Storsjö 07master:f1a9eee41c4b: x86: Add missing movsxd for the int stride parameter
[14:55:11 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:84ecbbfb2727: Merge commit 'f1a9eee41c4b5ea35db9ff0088ce4e6f1e187f2c'
[15:07:28 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:75872d77d215: lavc: Document AV_PKT_DATA_NEW_EXTRADATA
[15:07:30 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:187d719760bd: h264: Support AV_PKT_DATA_NEW_EXTRADATA
[15:07:30 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:46bd0e8e0dfb: Merge commit '75872d77d215d64b8d9430df23c6c74ff921227b'
[15:07:31 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:c67aa7f287e7: Merge commit '187d719760bd130f848194ec4a6bd476341914bb'
[15:08:45 CEST] <ubitux> anyone wants to merge the multiple stsd mov thing?
[15:16:42 CEST] <ubitux> michaelni: in #3962 the hash d0b27fe8f13d56f409448f27c4c08fc9a49bad4d looks wrong
[15:16:53 CEST] <ubitux> i'm also looking for the sample
[15:18:17 CEST] <ubitux> ah, i actually commented with the correct hash bein  02f7665a3ce703217ae1cbbc7baa29c438d61456
[15:18:30 CEST] <ubitux> i was smarter 21 months ago :(
[15:20:56 CEST] <michaelni> there a link to the sample in ticket 3962 http://stfcc.org/misc/dolby_atmos_truehd_sample.m2ts
[15:24:49 CEST] <ubitux> mmh?
[15:25:04 CEST] <ubitux> i'm talking about multiple_stsd.mp4
[15:25:15 CEST] <ubitux> i thought i had that one though...
[15:27:11 CEST] <michaelni> on samples.ffmpeg.org ffmpeg-bugs/trac/ticket3962/multiple_stsd.mp4
[15:27:43 CEST] <michaelni> also if i should test some branch ?
[15:27:54 CEST] <ubitux> i didn't start merging it
[15:28:24 CEST] <ubitux> thx for the sample
[15:34:47 CEST] <michaelni> for stsd related files and tickets "git log --grep stsd libavformat/mov.c | grep -i fix" might work
[15:38:08 CEST] <michaelni> also if you search for a file, try locate whateverfile on ffmpeg.org, it often finds files
[15:38:19 CEST] <ubitux> alright
[15:38:52 CEST] <ubitux> i won't merge that commit until a few hours
[15:38:59 CEST] <ubitux> so anyone is free to take over
[15:40:30 CEST] <michaelni> ok, ill go afk a bit too then :) should be back soon / in a few h
[15:51:57 CEST] <nevcairiel> ubitux: it appears h264.c now has duplicate handling for AV_PKT_DATA_NEW_EXTRADATA
[15:54:10 CEST] <ubitux> oh i missed that, my bad
[15:56:52 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:3cdd5f4b7c02: Revert "Merge commit '187d719760bd130f848194ec4a6bd476341914bb'"
[15:58:14 CEST] <nevcairiel> not sure why specifically we only allow it in avc mode, but probably has reasons
[15:58:26 CEST] <nevcairiel> annexb formats shouldnt have out of band extradata anyway
[19:31:48 CEST] <jamrial> https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116 looks like some projects using ffmpeg are disabling tree vectorization to fix crashes
[19:33:17 CEST] <jamrial> guess we should disable it for good. it's brought more problems than potential performance improvements
[19:35:33 CEST] <nevcairiel> with gcc 6.1 it also doesnt build on windows
[19:35:41 CEST] <nevcairiel> because inline asm and registers
[19:36:08 CEST] <nevcairiel> (doesnt build on x86 if you use -msse or higher)
[19:36:19 CEST] <jamrial> yeah, happened to me
[19:36:36 CEST] <jamrial> -march=haswell on mingw x86_32 = cabac fails to compile
[19:37:52 CEST] <jamrial> also with 5.x
[21:05:04 CEST] <cone-091> ffmpeg 03James Almer 07master:fd6dbc53855f: Revert "configure: Enable GCC vectorization on e4.9 on x86"
[22:43:30 CEST] <cone-091> ffmpeg 03James Almer 07release/3.0:4774eb8128ea: Revert "configure: Enable GCC vectorization on e4.9 on x86"
[22:43:31 CEST] <cone-091> ffmpeg 03James Almer 07release/3.1:f9a150fc31c5: Revert "configure: Enable GCC vectorization on e4.9 on x86"
[00:00:00 CEST] --- Sun Jul 10 2016