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

[burek]

[00:07:44 CEST] <BtbN> jamrial, yes, that built now
[16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:d4d4629dfe72: libavcodec/texturedsp : add rgtc1u_alpha decoding func
[16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:50a20de6b9ed: libavcodec/texturedspenc : add rgtc1_u_alpha encoding func
[16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:92500c7bc53b: libavcodec/texturedsp : indent after add rgtc1u_alpha func
[16:36:01 CEST] <cone-500> ffmpeg 03Martin Vignali 07master:7480f232d24a: libavcodec/texturedspenc : indent after add rgtc1u_alpha func
[16:44:46 CEST] <J_Darnley> Gramner (or anyone else) do you have a good reference for which processors have which AVX-512 variations?
[16:52:20 CEST] <jkqxz> J_Darnley:  <https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512>?
[16:52:57 CEST] <jkqxz> Or do you mean 1 vs. 2 functional units?
[16:52:57 CEST] <J_Darnley> Yeah, I saw that but I never trust Wikipedia to be accurate.
[16:53:22 CEST] <nevcairiel> there is basically only two active sets for now
[16:53:24 CEST] <J_Darnley> I just need to know whether a CPU will have the BW variant or not.
[16:53:32 CEST] <nevcairiel> the desktop-set in purley and skylake-e
[16:53:41 CEST] <nevcairiel> and the knights-landing set that noone  cares about
[16:54:13 CEST] <jkqxz> s/noone/noone with anything to do with multimedia/, but yes.
[17:01:45 CEST] <J_Darnley> Are those Xeon E5-26xx v5 processors released or not?
[17:05:33 CEST] <Gramner> J_Darnley: https://pbs.twimg.com/media/DMA38RyW4AAIzNm.png:large
[17:05:34 CEST] <jkqxz> Skylake?  It's all rebranded.
[17:07:39 CEST] <J_Darnley> I don't know.  I don't keep track of processor shenanigans these days.
[17:07:57 CEST] <J_Darnley> I'll just quote Wikipedia in the email and hope for the best.
[17:08:00 CEST] <Gramner> F+CD+BW+DQ+VL is what you can use as a baseline (that's the "avx512" cpuflag in x264) for anything that isn't xeon phi
[17:31:19 CEST] <jamrial> Gramner: is cannon lake still going to feature avx512 plus those two new subsets now that it's been revealed to be a laptop only die shrink of coffe lake?
[17:32:51 CEST] <nevcairiel> i could see them leave it out if its laptop only
[17:42:11 CEST] <Gramner> jamrial: yes, gotta spend those extra transistors a die shrink gives on something
[17:43:03 CEST] <Gramner> could possibly be a gimped variant with 256-bit data paths (like AMD) though
[17:43:26 CEST] <Gramner> e.g. AMD does AVX/AVX2 with 128-bit vector units
[17:47:27 CEST] <Gramner> the latest "Architecture Instruction Set Extensions and Future Features Programming Reference" from this months reaffirms that CNL is the first client platform with AVX-512
[17:47:54 CEST] <jamrial> cool
[17:48:52 CEST] <kierank> J_Darnley: shared you a doc
[17:48:56 CEST] <kierank> you'll need to translate betwee nthe marketing
[17:56:09 CEST] <J_Darnley> so in addition to model numbers there are also tiers: Bronze, Silve, Gold, and Platinum.
[17:58:24 CEST] <jkqxz> Suggest ignoring them - the model numbers carry more information (the 1 vs. 2 AVX-512 functional units change is in the middle of the "gold" tier).
[18:04:26 CEST] <J_Darnley> So, these model numbers.  Have Intel dropped their old E numbers on Xeons?
[18:10:29 CEST] <jkqxz> Yes, it's all changed.
[18:38:26 CEST] <J_Darnley> jkqxz: unless there is a typo in Intel's docs for this processor https://ark.intel.com/products/120475/Intel-Xeon-Gold-5122-Processor-16_5M-Cache-3_60-GHz then the change from 5xxx to 6xxx doesn't mark where it goes from 1 to 2 units.
[18:46:37 CEST] <jkqxz> Probably there to mess with people trying to make generalisations.
[18:47:41 CEST] <nevcairiel> the new xeon lines are quite a mess
[18:48:11 CEST] <nevcairiel> i'm sure they have a cpu for every use-case imaginable
[18:48:16 CEST] <nevcairiel> but its just so hard to find it
[18:48:23 CEST] <J_Darnley> At this point they should build CPUs to order like a car.  Choose instruction sets, choose speed, choose core count.  Then the'll grow you one.
[18:48:55 CEST] <nevcairiel> they probably even have every combination, just need a wizard to find it .p
[18:50:26 CEST] <jkqxz> Probably half the SKUs never get bought by anyone at all.
[18:51:03 CEST] <jkqxz> (That feels true with the proliferation of mobile SKUs as well.)
[21:32:56 CEST] <JEEB> jamrial: currently having a user test https://github.com/jeeb/ffmpeg/commit/71b92aa9f92c89c8c7f5552d0caddb9aaadc6142
[21:33:18 CEST] <JEEB> does that look correct'ish?
[21:33:54 CEST] <jamrial> JEEB: you can remove the quotes from alsa, but yes, looks good
[21:34:13 CEST] <JEEB> k
[21:34:14 CEST] <jamrial> does the pkg-config file add some extra library?
[21:34:22 CEST] <JEEB> it has Libs.private actually correct
[21:34:35 CEST] <JEEB> (yes, another case of "I was building static and shit broke" on #ffmpeg)
[21:34:46 CEST] <JEEB> almost brought me to tears btw https://pastebin.com/7jFZBX0x
[21:34:56 CEST] <JEEB> > actually has -ldl in Libs.private
[21:35:04 CEST] <JEEB> > also has pthread and math
[21:35:20 CEST] <jamrial> and lrt
[21:35:37 CEST] <jamrial> yeah, i welcome the pkg-config addition, then
[21:36:26 CEST] <JEEB> waiting for the guy to get back to me if it worked for him, as I tested with the shared lib
[21:42:31 CEST] <jamrial> JEEB: it should, assuming he runs configure with --pkg-config-flags=--static
[21:47:04 CEST] <JEEB> yes, he did that
[21:49:24 CEST] <JEEB> can anyone spot why this thing fails to enable pthreads? https://bpaste.net/show/490903f961fa
[21:49:31 CEST] <JEEB> I see two checks which both seem to pass?
[21:49:43 CEST] <JEEB> (why he's trying to use pthreads on windows is a separate question of course)
[21:50:41 CEST] <hanetzer> << dude with the pthreads issue :)
[21:52:43 CEST] <jamrial> sounds like you used --enable-pthreads but didn't use --disable-w32threads
[21:52:54 CEST] <JEEB> ah
[21:52:58 CEST] <JEEB> so you have to disable the other alternative
[21:53:04 CEST] <JEEB> (which is the default)
[21:53:07 CEST] <hanetzer> jamrial: hrm... lemme see if I can inject it into the build easily.
[21:53:56 CEST] <jamrial> just add --disable-w32threads. that should make configure run all the pthreads checks
[21:54:41 CEST] <JEEB> hanetzer: unless you really want your pthreads I recommend you just drop that enable-pthreads from there then :D
[21:55:31 CEST] <jamrial> was going to say, w32threads is usually more than enough for a windows build
[21:56:08 CEST] <hanetzer> true that may be, but I'd rather like to know the underlying cause as to why our ffmpeg ebuild doesn't work for mingw-w64 before I start slinging fixes :)
[22:02:05 CEST] <JEEB> jamrial: posted the ALSA patch on the ML
[22:02:30 CEST] <JEEB> the guy on #ffmpeg drifted away
[22:02:33 CEST] <hanetzer> ok, testing with USE="-threads" to see if it will compile, and will file a bug with gentoo itself.
[22:03:28 CEST] <hanetzer> so, basically what you're saying is I need to either --enable-pthreads --disable-w32threads or just not --enable-pthreads at all, then?
[22:03:57 CEST] <JEEB> or --enable-w32threads --disable-pthreads if you want to be explicit
[22:04:12 CEST] <JEEB> (which is the default)
[22:04:38 CEST] <hanetzer> yep. USE="-threads" gets to the point of compilation.
[22:04:52 CEST] <JEEB> and that doesn't actually disable threads? :D
[22:05:02 CEST] <JEEB> because that's another option which I would expect "-threads" to do
[22:05:21 CEST] <jamrial> hanetzer: for pthreads, --enable-pthreads and --disable-w32threads. for w32threads, nothing at all since it's default on windows, but adding --enable-w32threads doesn't hurt
[22:05:22 CEST] <hanetzer> -useflag disables a use flag on gentoo.
[22:05:46 CEST] <JEEB> hanetzer: so it doesn't mean an explicit flag the other way gets added?
[22:05:50 CEST] <JEEB> because some things do it that way
[22:06:13 CEST] <JEEB> jamrial: what were the other patches that you needed checked?
[22:06:27 CEST] <JEEB> the libm thing I LGTM'd
[22:06:34 CEST] <hanetzer> so USE="-x264" emerge media-video/ffmpeg will build it without the x264 library.
[22:07:04 CEST] <JEEB> hanetzer: yea but there's a world of difference if you do --enable-libx264 and then leave it out. or set --disable-libx264
[22:07:14 CEST] <JEEB> although in this case I guess it works because you want to disable pthreads anyways :P
[22:10:34 CEST] <hanetzer> I'm unsure if -threads just does no diddling at all or actively inverts the diddling.
[22:11:41 CEST] <jamrial> ok, i think this in some way can be considered a regression since 8aad209c13c
[22:12:45 CEST] <hanetzer> did my last message get through?
[22:12:55 CEST] <jamrial> so better open a ticked in our bug tracker
[22:13:00 CEST] <jamrial> hanetzer: the diddling one? yes
[22:14:31 CEST] <JEEB> hanetzer: the main point though was to make sure that it didn't completely disable all threading
[22:14:35 CEST] <JEEB> :)
[22:14:45 CEST] <JEEB> since that's also something -threads could in theory do
[22:14:54 CEST] <JEEB> if you could check the config.log kthx
[22:15:23 CEST] <jamrial> why are you experiencing this now? the commit that seemingly started this has been in the tree for almost a year now
[22:15:35 CEST] <hanetzer> k. also looks like it gets past making ffmpeg and ffprobe but 'no target to make tools/aviocat' later on.
[22:16:12 CEST] <JEEB> hanetzer: can you check what I noted btw? just to double-check that your config is still sane
[22:16:38 CEST] <hanetzer> JEEB: one sec.
[22:17:46 CEST] <jamrial> sounds like it should be aviocat.exe for windows?
[22:18:15 CEST] <hanetzer> maybe, but if the make target is changing per os that's a bit fucky in my book.
[22:20:21 CEST] <hanetzer> JEEB: USE="-threads" i686-w64-mingw32-emerge media-video/ffpmeg builds with --disable-pthreads and does not futz with w32threads at all.
[22:20:54 CEST] <JEEB> hanetzer: so no --disable-threads or some global disablement?
[22:21:11 CEST] <hanetzer> not that I'm finding with a string search.
[22:22:15 CEST] <nevcairiel> the ebuild sounds very much designed for linux only
[22:22:38 CEST] <hanetzer> nevcairiel: nah. it does some freebsd and mingw handling. just not all of them.
[22:23:05 CEST] <jamrial> nevcairiel: still, the commit i mentioned above did change the behavior of --enable-pthreads when used alone
[22:23:11 CEST] <hanetzer> so does the make target for aviocat actually change for windows?
[22:23:16 CEST] <jamrial> yes
[22:23:23 CEST] <jamrial> every binary target on windows needs .exe
[22:23:27 CEST] <jamrial> it's always been like that
[22:23:33 CEST] <hanetzer> well that's dumb :P
[22:23:51 CEST] <nevcairiel> make targets files, so yeah
[22:24:20 CEST] <hanetzer> well it looks like the aviocat fix is fairly simple.
[22:51:38 CEST] <cone-976> ffmpeg 03James Almer 07master:ae6fe04bee60: configure: add missing optional deps on gcrypt and openssl to the hls muxer
[23:39:29 CEST] <cone-976> ffmpeg 03Jun Zhao 07master:2e9449022590: ffmpeg: remove hwaccel_lax_profile_check option
[00:00:00 CEST] --- Tue Oct 17 2017