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

[burek]

[01:11:45 CEST] <durandal_170> BBB: I don't get any speedup when packing instructions
[01:32:07 CEST] <llogan> was there ever a summary or something of the results of the discussions at VDD? 
[01:37:02 CEST] <llogan> the delay from sending a message to the ML, then it showing up seems greater than before (the server move?)
[01:39:05 CEST] <durandal_170> it must be kept secret from rest of people to not hurt 
[01:39:45 CEST] <BBB> durandal_170: pairing, you mean?
[01:39:50 CEST] <durandal_170> add rest of sentence
[01:40:11 CEST] <durandal_170> BBB: yes
[01:40:24 CEST] <BBB> ok, thats ok, its a little cpu dependent
[01:40:28 CEST] <BBB> its more a convention than anything else
[01:40:34 CEST] <BBB> so dont worry about it
[01:41:03 CEST] <llogan> durandal_170: FFcabal. but probably just FFlazy and me being afk lately.
[01:42:57 CEST] <llogan> 17 mins, no email. who is the mail maintainer around here?
[01:43:29 CEST] <durandal_170> Huh?
[01:45:13 CEST] <llogan> it just showed up. i was dreading figuring out why if it never showed up.
[01:47:34 CEST] <cone-617> ffmpeg 03Michael Niedermayer 07master:e34ba5ec53b9: avformat/flvdec: Remove dead loop
[04:11:00 CEST] <cone-617> ffmpeg 03Michael Niedermayer 07master:d1c8368e4031: avfilter/af_extrastereo: Fix shadowed variable
[04:29:16 CEST] <Zeranoe> The GitHub mirror is theoretically always up to date, correct?
[04:31:08 CEST] <jamrial> yeah
[04:36:05 CEST] <rcombs> always*
[05:12:11 CEST] <Daemon404> i dont think it is autosync'd anymore
[07:15:34 CEST] <Compn> the mails take longer to send because now there are more tubes to travel through. also ubitux's cloud server probably has to make the required copy to NSA servers first.
[07:27:32 CEST] <rcombs> so I'm not super clear on whether or not QSV is GPL-compatible
[07:27:54 CEST] <rcombs> also, whether or not distributing an ffmpeg built with a GPL-incompatible lib but without --enable-gpl is legal
[09:57:39 CEST] <cone-400> ffmpeg 03Paul B Mahol 07master:755242b91213: avfilter:audio: fix shadowed AVFrame *out
[09:57:40 CEST] <cone-400> ffmpeg 03Paul B Mahol 07master:a342c2a5317f: afilter/af_extrastereo: remove dead initialization
[11:02:20 CEST] <JEEB> lol libutvideo
[11:04:33 CEST] <wm4> why does it exist etc.
[11:52:56 CEST] <blue112> Hi here. I have a problem with ffmpeg libav avcodec_open2 returning junk in avctx structure, like 48000 in channels and 0 in sample_rate.
[11:53:39 CEST] <BtbN> sounds like you're using the library with headers for a diffrent version.
[11:54:46 CEST] <blue112> Sounds possible, let me check that.
[12:55:16 CEST] <nevcairiel> rcombs: the qsv stuff seems to be licensed under BSD 3-clause, isnt it. whats the problem exactly? :d
[13:37:05 CEST] <cone-400> ffmpeg 03Ganesh Ajjanagadde 07master:9ecfcfe481ff: README: replace http with https
[14:28:46 CEST] <ubitux> wm4: do you still object to the VT iOS compilation patch?
[14:29:58 CEST] <wm4> ubitux: no
[14:30:03 CEST] <wm4> but I don't like it
[14:30:15 CEST] <wm4> on that note, I wonder what that OSX function even does
[14:30:43 CEST] <ubitux> i told you; it's a apple str2pixfmt()
[14:31:55 CEST] <wm4> yeah, but what kind of names does it take?
[14:34:17 CEST] <ubitux> wm4: something like "420v" iirc
[14:35:05 CEST] <wm4> ok
[14:35:15 CEST] <ubitux> (i never used it)
[14:36:27 CEST] <nevcairiel> the entire option is probably more of a debug tool than anything else
[14:36:30 CEST] <nevcairiel> but just push it ubitux
[15:43:34 CEST] <BBB> nevcairiel: ty for testing
[15:46:29 CEST] <nevcairiel> np
[15:46:56 CEST] <nevcairiel> if i dont, chances are that noone will
[15:48:15 CEST] <Daemon404> :D
[15:50:30 CEST] <BBB> we should just remove 32bit support in a few years
[15:50:35 CEST] <BBB> and see if anyone notices
[15:50:52 CEST] <BBB> I bet nobody will until debian releases their next stable
[15:51:07 CEST] <kierank> vlc will notice
[15:51:08 CEST] <nevcairiel> plenty windows users with 32-bit software still
[15:51:10 CEST] <wm4> didn't mobile crap put us back into the stone age?
[15:51:29 CEST] <BBB> wm4: I meant x86 32bit, not global 32bit, sorry
[15:51:39 CEST] <j-b> yes
[15:51:47 CEST] <j-b> Android ATOM are often x86 32bits
[15:51:54 CEST] <BBB> omg
[15:51:57 CEST] <j-b> thanks for nothing, Google.
[15:52:14 CEST] <nevcairiel> blame intel for pushing 32-bit cpus into that space
[15:52:17 CEST] <BtbN> Aren't they are usualy amd64, but running 32bit Android, because reasons?
[15:52:38 CEST] <nevcairiel> well it took google some time to get 64-bit x86 android going, but they have that now at least
[16:06:05 CEST] <Daemon404> people run x86 android?
[16:06:05 CEST] <Daemon404> lies
[16:07:24 CEST] <j-b> it's even worse than that
[16:07:32 CEST] <j-b> they run x86 android and pretend to be ARM
[16:07:40 CEST] <j-b> especially the zenphone
[16:08:02 CEST] <j-b> or the Samsung Galaxy tab, where some versions of the same models are ARM, the other x86
[16:08:57 CEST] <Gramner> tons of x86 software is still 32-bit, even if it usually runs on a 64-bit os
[16:09:04 CEST] <Daemon404> chrome
[16:09:26 CEST] <BtbN> Chrome does offer a 64bit version though. It doesn't offer it by default though.
[16:10:05 CEST] <TheRyuu> https://www.chromium.org/getting-involved/dev-channel unlike firefox they actually have a 64-bit client for their stable branch/channel
[16:10:09 CEST] <Gramner> hell, firefox still hasn't released a 64-bit windows version. it's only in nightly builds and such
[16:10:12 CEST] <wm4> j-b: how do they pretend it's ARM?
[16:10:18 CEST] <Gramner> also steam
[16:10:21 CEST] <wm4> also, is Bionic still the worst POS ever?
[16:10:33 CEST] <TheRyuu> Gramner: I don't get it because they release betas in 64-bit (firefox)
[16:10:39 CEST] <Gramner> steam uses libavcodec and libx264 and is 32-bit only
[16:11:40 CEST] <j-b> wm4: well, they have ARM emulation and both CPU and CPU2 fields return ARM
[16:11:59 CEST] <wm4> but why
[16:12:02 CEST] <j-b> because
[16:12:05 CEST] <j-b> other question?
[16:12:07 CEST] <Daemon404> "compatability"
[16:12:14 CEST] <j-b> wm4: and no, it's not the worst POS ever, it's 10x worse than that
[16:12:18 CEST] <Gramner> TheRyuu: yeah, 64-bit progress in firefox is really slow. they even declared they were going to drop 64-bit builds completely some time ago but retracted that due to massive user backlash
[16:12:33 CEST] <j-b> wm4: but sorry, they are working at Google, so they are 10 times more clever than you are.
[16:12:41 CEST] <BtbN> But why? 64bit firefox works fine on various linux distros since forever.
[16:12:56 CEST] <wm4> I know, I could never figure out these interview questions in time
[16:13:15 CEST] <flux> fact is that 64-bit code, in particular if it's pointer-happy, can consume a lot of more memory than 32-bit
[16:13:17 CEST] <durandal_170> like?
[16:13:33 CEST] <j-b> but, they release code with asserts on invalid files, and abort your process
[16:13:48 CEST] <Daemon404> [15:12] <@j-b> wm4: but sorry, they are working at Google, so they are 10 times more clever than you are. <-- i loled irl
[16:13:48 CEST] <flux> and I think firefox will have very many pointers :)
[16:14:17 CEST] <Gramner> firefox consumes silly amount of memory anyway
[16:14:23 CEST] <wm4> flux: true, I've been on 32 bit x86 until a few months ago
[16:14:26 CEST] <Gramner> big deal if it uses a few gigabytes more
[16:14:39 CEST] <TheRyuu> if you open a lot of tabs to get it to a few gigabytes
[16:14:44 CEST] <TheRyuu> firefox proabbly uses less than chrome
[16:14:45 CEST] <flux> usually firefox just comes so slow when it's 6 gigabytes that it needs to be restarted
[16:14:46 CEST] <wm4> flux: 2GB RAM was just not enough for 64 bit
[16:15:07 CEST] <Daemon404> i must be the only person who doesnt keep the entire internet open in tabs 24/7
[16:15:10 CEST] <Daemon404> and actually closes the browser
[16:15:15 CEST] <Gramner> i have to restart firefox once every few days because it get sluggish after a while
[16:15:29 CEST] <flux> daemon404, god damn, you're not doing your duty as maintaining the backup of the internet in teh browser
[16:15:31 CEST] Action: Daemon404 even shuts down his laptop at night
[16:15:42 CEST] <fritsch> Daemon404: no suspend?
[16:15:55 CEST] Action: durandal_170 uses elinks
[16:15:58 CEST] <Daemon404> suspend makes no difference
[16:16:47 CEST] <j-b> Daemon404: sorry, but that's an actual argument that was pointed to me
[16:17:14 CEST] <j-b> that the android-media/stagefright engineers were more clever than us/me
[16:17:19 CEST] <j-b> that was 3 years ago
[16:17:43 CEST] <Daemon404> j-b, no, i know exactly what you speak of
[16:17:44 CEST] <j-b> https://www.google.fr/search?q=CVE+stagefright
[16:17:45 CEST] <Daemon404> which is why i laughed
[16:17:52 CEST] <Daemon404> ive had the exact same experiences dealing with google
[16:18:13 CEST] <Daemon404> and years ago when i interviewed, the interviewer said "dont worry, i can follow your code, im much smarter than you"
[16:18:17 CEST] <Daemon404> when introducing himself
[16:18:19 CEST] <Daemon404> before whitebiarding
[16:18:59 CEST] <j-b> bionic, not thread-safe, not reentrant, wrong pthread implementation, broken utf-8, broken pipe2 and localtime
[16:19:32 CEST] <j-b> stagefright, asserting and aboring the media server (and all processes using it), because it finds a MKV tag it cannot parse
[16:19:36 CEST] <j-b> etc...
[16:19:39 CEST] <wm4> hey at least you can actually enumerate what's wrong with bionic, without being kicked for spam
[16:19:42 CEST] <j-b> Daemon404: so much surprising
[16:20:02 CEST] <j-b> wm4: well, there is not much in it, so it's easy to list :)
[16:32:29 CEST] <Compn> there seriously needs to be a light weight web browser :\
[16:33:49 CEST] <Daemon404> Compn, netcat/telnet
[16:36:58 CEST] <Compn> >half of web doesnt even display without javascript now :(
[16:38:00 CEST] <J_Darnley> If a website is broken (or worse: blank) without javascript, is it worth your time?
[16:38:24 CEST] <Compn> usually not
[16:45:36 CEST] <kierank> BBB: can you try logging back into avdev
[16:46:19 CEST] <kierank> atomnuker: ping, how did you send me public key again?
[16:47:12 CEST] <kierank> ah found the email
[16:47:25 CEST] <BBB> works
[16:47:57 CEST] <kierank> atomnuker: can you try please
[16:48:16 CEST] <kierank> fate-suite is available in /usr/share/fate-suite/
[16:49:17 CEST] <BBB> ty!
[16:59:24 CEST] <atomnuker> kierank: doesn't work, (Permission denied (publickey).)
[17:00:48 CEST] <kierank> atomnuker: weird
[17:01:26 CEST] <kierank> atomnuker: try now
[17:05:40 CEST] <atomnuker> yep, works
[17:05:42 CEST] <atomnuker> thanks
[17:05:53 CEST] <atomnuker> WHOA
[17:05:56 CEST] <kierank> let me know if you both need new packages
[17:05:57 CEST] <atomnuker> 14.04
[17:06:03 CEST] <kierank> no 12.04
[17:06:14 CEST] <atomnuker> ah, got confused by the MOTD
[17:32:32 CEST] <Daemon404> nevcairiel, fyi patch looks ok to me
[17:32:38 CEST] <Daemon404> its more or less been OK'd on irc
[17:41:42 CEST] <wm4> is there any chance that the w32 threads stuff could be made self-initializing?
[17:42:14 CEST] <Daemon404> btw uh
[17:42:19 CEST] <Daemon404> for OS/2....
[17:42:26 CEST] <Daemon404> i assume we'll just wait for the korean guy to fix it?
[17:42:30 CEST] <wm4> yes
[17:42:34 CEST] <Daemon404> \o/
[17:42:36 CEST] <wm4> he event sent him a mail
[17:42:56 CEST] <wm4> which I guess protects him from being accused of whatever
[17:43:10 CEST] <Daemon404> nobody is going to accuse someone of sabotaging OS/2
[17:43:15 CEST] <Daemon404> thats far too much effort for a dead os
[17:51:01 CEST] <nevcairiel> wm4: we could get a DllMain function through the bikeshed for dlls
[17:51:06 CEST] <nevcairiel> static linking is still screwed
[17:51:20 CEST] <nevcairiel> interestingly it will still work if the init is never called
[17:51:28 CEST] <nevcairiel> just use the fallback impls
[17:52:02 CEST] Action: Daemon404 just disables all fallbacks by settign winnt
[17:52:07 CEST] <Daemon404> xp so ded
[17:52:43 CEST] <nevcairiel> i think its called in avcodec_register_whatever anyway
[17:52:44 CEST] <wm4> unfortunately I'm interested in static linking
[17:52:47 CEST] <nevcairiel> so you cant really not call it
[17:52:59 CEST] <wm4> I'm interested in using it in libavutil
[17:53:06 CEST] <wm4> which lazily generates some tables in the crc code
[17:53:24 CEST] <wm4> although I'm not sure if pthread_once is good enough
[18:04:10 CEST] <BBB> so how do I do dword*(d)word ->qword multiplies in simd (signed)?
[18:04:24 CEST] <BBB> I found pmuludq but thats unsigned
[18:04:29 CEST] <BBB> do I really have to emulate this crap?
[18:06:28 CEST] <jamrial> pmuldq?
[18:06:39 CEST] <jamrial> sse4, though
[18:12:35 CEST] <BBB> sse4 is probably ok
[18:12:42 CEST] <BBB> I mean, I gotta work with what I got, right?
[18:13:00 CEST] <BBB> I wish there was a pmadddq
[18:16:46 CEST] <jamrial> avx-512 introduces pmullq and the weird vpmadd52{h,l}uq instructions
[18:17:22 CEST] <jamrial> "Multiply packed unsigned 52-bit integers in each 64-bit element of b and c to form a 104-bit intermediate result. Add the low or high 52-bit unsigned integer from the intermediate result with the corresponding unsigned 64-bit integer in a, and store the results in dst."
[18:18:20 CEST] <BBB> huh
[18:18:28 CEST] <nevcairiel> 52 is rather specific
[18:18:41 CEST] <BBB> yeah
[18:18:41 CEST] <jamrial> after almost twenty years one would hope intel would fill all the gaps left by the not-so-thorougly planned sse sets, but guess not
[18:19:07 CEST] <BBB> Im still waiting for a pmulhrsw version of packssdw
[18:19:23 CEST] <BBB> i.e. one that does a rounded shift before packing dwords to words
[18:46:50 CEST] <nevcairiel> wm4: looking at it, i think the w32thread_init function is actually not called in enough places, especially if its supposed to be used for pthread_once, guess i should spread the love a bit =p
[18:51:13 CEST] <wm4> meh
[18:51:44 CEST] <wm4> is it not possible to do some sort of weak DLL import?
[18:52:04 CEST] <nevcairiel> no
[18:53:11 CEST] <BtbN> Just put it in some static initializer in every library?
[18:53:45 CEST] <nevcairiel> weirdos do static linking where you cant run such things
[18:54:27 CEST] <wm4> we could add a C++ source file that runs a ctor?
[18:55:17 CEST] Action: Daemon404 stabs wm4
[18:55:23 CEST] <nevcairiel> static linking probably blows that up too
[18:55:40 CEST] <Daemon404> or drop xp support
[18:55:43 CEST] <Daemon404> and this all goes away
[18:56:41 CEST] <Daemon404> BBB, see pm when you come back from lunch
[18:57:34 CEST] <wm4> wait
[18:57:42 CEST] <wm4> vista+ code has no need for such a static init function, right
[18:57:52 CEST] <nevcairiel> not if you build it linked to that
[18:58:00 CEST] <nevcairiel> (which is not the default)
[18:58:06 CEST] <wm4> so why not use the atomic poll loop for the all-compatible code
[18:58:35 CEST] <wm4> (same method as you use for pthread_once on XP)
[19:01:52 CEST] <nevcairiel> i dont understand what you mean
[19:01:58 CEST] <nevcairiel> drop the dynamic loading entirely?
[19:03:25 CEST] <wm4> always run the dynamic loading on entry points (like when creating a mutex, or running pthread_once), and guard the loading with such a loop
[19:03:41 CEST] <nevcairiel> that seems annoying
[19:03:44 CEST] <wm4> maybe you could even use pthread_once for it
[19:03:49 CEST] <wm4> how is it annoying?
[19:04:21 CEST] <nevcairiel> dunno, seems like a bunch of overhead
[19:04:37 CEST] <Daemon404> as opposed to the normal overhead of this ridiclous farce to support a dead os
[19:04:55 CEST] <nevcairiel> well this is runtime overhead even on a  modern os
[19:05:00 CEST] <wm4> nevcairiel: IMO less bad than littering everything with init calls
[19:05:21 CEST] <wm4> just an additional atomic... for each mutex creation or pthread_once call
[19:05:24 CEST] <nevcairiel> you really only need to throw it into avcodec_register_all
[19:05:29 CEST] <wm4> no
[19:05:41 CEST] <wm4> you can use a bunch of things that may use these primitives outside of lavc
[19:05:50 CEST] <wm4> and avcodec_register_all should die in the first place
[19:05:55 CEST] <nevcairiel> i dont care about theoretical problems =P
[19:06:07 CEST] <wm4> also, you can disable XP support if you're worried about overhead
[19:06:15 CEST] <nevcairiel> for all I care it goes into a DllMain and the problem is done
[19:06:17 CEST] <wm4> they're not theoretical
[19:06:23 CEST] <nevcairiel> static linking on windows is worse than xp support
[19:07:41 CEST] <nevcairiel> the whole point here is to fix avcodec_open2 .. avcodec_open2 only works with registered codecs .. so  avcodec_register_all needs to be called first
[19:07:50 CEST] <nevcairiel> its not like it breaks down entirely if the init wasnt called first
[19:07:55 CEST] <nevcairiel> it just uses the less efficient path
[19:08:38 CEST] <bofh__> 12:18 <@nevcairiel> 52 is rather specific
[19:08:49 CEST] <wm4> these are generic primitives, which are potentially used by more than avcodec_open2
[19:08:56 CEST] <nevcairiel> theoretical!
[19:09:03 CEST] <bofh__> oh I see they just exposed the multiplier for the double-precision fp mantissa
[19:09:10 CEST] <nevcairiel> ffmpeg is potentially used on a 8088 8-bit cpu
[19:09:27 CEST] <bofh__> (fwiw djb has been trying to get folks to do that for years, I bet he'll be happy :P))
[19:09:30 CEST] <bofh__> -)*
[19:09:38 CEST] <wm4> I don't know why you resists so much against a simple fix
[19:09:57 CEST] <nevcairiel> because its runtime overhead for a dumb-ass usecase (static linking on windows)
[19:10:30 CEST] <wm4> (only if you actually go and add a DllMain... for all 9 libs)
[19:11:01 CEST] <nevcairiel> thats not too hard
[19:11:06 CEST] <bofh__> wm4: obvious dumb question, but why not just hardcode the CRC tables? they aren't that big anyway, the full set is only something like 64k of rodata
[19:11:25 CEST] <bofh__> assuming that's all you care about from lavutil
[19:11:29 CEST] <bofh__> (if not, nevermind)
[19:11:30 CEST] <Daemon404> [18:09] <@nevcairiel> because its runtime overhead for a dumb-ass usecase (static linking on windows) <-- xp is the dumbass usecase
[19:11:32 CEST] <wm4> it was only an example
[19:11:33 CEST] <Daemon404> get your facts straight
[19:11:40 CEST] <nevcairiel> Daemon404: static linking on windows is worse
[19:11:54 CEST] <nevcairiel> "but one .exe" is a stupid reason =p
[19:11:59 CEST] <Daemon404> PGO
[19:12:04 CEST] <Daemon404> er
[19:12:05 CEST] <Daemon404> i mena
[19:12:06 CEST] <Daemon404> LTCG
[19:12:09 CEST] <nevcairiel> like that works
[19:12:11 CEST] <bofh__> Daemon404: xp, despite being very EOL, is still quite widely used in the world. not in north america sure, but a lot of stuff in east asia for instance still runs it.
[19:12:28 CEST] <wm4> I think those CRC tables are 2MB total
[19:12:48 CEST] <Daemon404> bofh__, they use an unupdated os, they can use unupdated decoders
[19:12:54 CEST] <nevcairiel> if they are global static data, then they should take up that space already anyway, just not initialized, dont they?
[19:12:55 CEST] <Daemon404> they wont miss hevc or vp9
[19:13:09 CEST] <wm4> nevcairiel: again, just disable XP support at compile time, and you don't need any global init funcs, DllMains, or additional runtime checks
[19:13:26 CEST] <bofh__> wm4: my back of the hand calc was 256 entries * 4 bytes/int * 8 (slicing-by-8 implementation) * 8 (8 different polynomials: CRC8, 2 CRC16s, le ver of one of those, 4 CRC32s)
[19:13:45 CEST] <bofh__> not sure how you're getting 2M
[19:14:01 CEST] <wm4> AVCRC av_crc_table[AV_CRC_MAX][CRC_TABLE_SIZE];
[19:14:11 CEST] <wm4> dammit wrong constants
[19:14:14 CEST] <bofh__> yeah, and AV_CRC_MAX is like 8
[19:14:34 CEST] <wm4> it's 13
[19:14:53 CEST] <wm4> so I get 104KB
[19:15:06 CEST] <wm4> except I used the wrong type
[19:15:11 CEST] <wm4> I guess I'm way too confused right now
[19:15:33 CEST] <wm4> so 52KB, plus minus 1 MB
[19:15:36 CEST] <bofh__> okay, yeah, that looks right.
[19:15:40 CEST] <bofh__> lol.
[19:15:40 CEST] <wm4> (can't be wrong)
[19:16:26 CEST] <nevcairiel> wm4: bring it up on the ML, if others agree i'll build it
[19:16:46 CEST] <wm4> which ML?
[19:16:49 CEST] <wm4> libav I guess
[19:17:37 CEST] <Daemon404> nevcairiel's time is divided up by democratic process?
[19:17:44 CEST] <rcombs> nevcairiel: that's just a wrapper lib
[19:17:58 CEST] <Daemon404> btw the biggest question i have is
[19:18:05 CEST] <Daemon404> why do all the other pthreads impls for windows suck so much
[19:18:12 CEST] <Daemon404> i tried to read 2 of them... dear lord.
[19:18:18 CEST] <nevcairiel> rcombs: but it and all its headers are licensed under BSD, you dont actually link against anything or use any non BSD header file
[19:18:22 CEST] <rcombs> nevcairiel: the actual meat of the code is in Intel proprietary binaries
[19:18:25 CEST] <nevcairiel> and you dont distribute anything
[19:18:29 CEST] <nevcairiel> so how can it be wrong
[19:18:41 CEST] <wm4> Daemon404: because those try to be compatible with pre-XP and POSIX
[19:18:58 CEST] <nevcairiel> Daemon404: because we have a minimal subset of pthreads
[19:19:00 CEST] <Daemon404> wm4, theyre terrible in ways other than that, wm4
[19:19:01 CEST] <rcombs> you need to ship the Intel libs
[19:19:03 CEST] <Daemon404> i linked you yesterday.
[19:19:11 CEST] <nevcairiel> rcombs: you dont, they come with the driver .. at least on windows
[19:19:14 CEST] <wm4> ok that mingw code was something else
[19:19:29 CEST] <nevcairiel> let the user gather the binaries themself
[19:19:36 CEST] <rcombs> nevcairiel: are you talking about vaapi or qsv?
[19:19:40 CEST] <nevcairiel> qsv of course
[19:19:46 CEST] <nevcairiel> that was the entire point wasnt it
[19:19:50 CEST] <rcombs> yeah
[19:20:03 CEST] <rcombs> on Linux Intel makes the qsv binaries a pita to get
[19:20:09 CEST] <rcombs> dunno about Windows
[19:20:17 CEST] <nevcairiel> windows they just get installed with the intel driver
[19:20:26 CEST] <nevcairiel> so no fuss at all
[19:21:53 CEST] <nevcairiel> dunno what the license situation with distributing the binaries is
[19:22:02 CEST] <nevcairiel> but ffmpeg is fine either way
[19:22:53 CEST] <nevcairiel> you wouldnt say that vdpau is not compatible just because it only works with the closed source nvidia driver
[19:24:07 CEST] <rcombs> probably not, because the nvidia driver is a "system library" or is used via one
[19:24:21 CEST] <wm4> lol all these fuzzy definitions and terms
[19:24:32 CEST] <Daemon404> its nto a system lib unless it ships with the os
[19:24:39 CEST] <Daemon404> IANAL, but j-b kinda is.
[19:26:42 CEST] <j-b> are you still discussing the nvenc header issue?
[19:26:53 CEST] <nevcairiel> no
[19:27:05 CEST] <Daemon404> we're discussing stupid xp workarounds
[19:27:09 CEST] <j-b> pff, I need to readd above then
[19:27:19 CEST] <Daemon404> context is for weenies
[19:27:19 CEST] <nevcairiel> similar though, qsv
[19:27:31 CEST] <j-b> QSV is a genius evil legal thingie
[19:28:00 CEST] <nevcairiel> apparently the headers and  wrapper library being BSD isnt enough to make rcombs happy because you need some binary blob to make it work
[19:28:29 CEST] <Daemon404> j-b, i personally enjoy the way slysoft worked around foss licenses
[19:28:31 CEST] <j-b> well, yes/no
[19:28:36 CEST] <Daemon404> they pass frames and packets via IPC
[19:28:39 CEST] <Daemon404> to encoder/decode
[19:28:41 CEST] <Daemon404> and such
[19:28:45 CEST] <j-b> it's the GStreamer and Telepathy thing over again
[19:28:53 CEST] <rcombs> j-b: I'm not sure if it's GPL (or LGPL)-friendly to redistribute a version that supports qsv along with libmfxhw64.so and friends
[19:29:01 CEST] <j-b> it's not
[19:29:12 CEST] <nevcairiel> well distributing intels binary is another matter
[19:29:14 CEST] <j-b> but if you don't distribute the .so it's ok.
[19:29:41 CEST] <nevcairiel> thats why I like it on windows, the damn lib just comes with the driver and you never worry
[19:29:47 CEST] <rcombs> so you have to just tell the user "go get libmfxhw64.so"?
[19:30:08 CEST] <nevcairiel> maybe intel will make that a bit better available eventually
[19:30:21 CEST] <j-b> rcombs: yes
[19:30:47 CEST] <rcombs> that's not gonna work for most of my users
[19:31:01 CEST] <nevcairiel> thats too bad for them
[19:31:18 CEST] <wm4> j-b: GStreamer and Telepathy?
[19:31:25 CEST] <nevcairiel> imagine, linux multimedia being plug-n-play one day
[19:31:36 CEST] <j-b> wm4: yes.
[19:31:44 CEST] <nevcairiel> but today, everyone that runs multimedia on linux needs to know that a lot of manual labor is involved =p
[19:31:50 CEST] <j-b> wm4: I'll explain when we meet IRL
[19:31:53 CEST] <j-b> now I need to run
[19:33:46 CEST] <rcombs> nevcairiel: a lot of people on NAS platforms wouldn't know what a linux is if you asked them
[19:45:48 CEST] <nevcairiel> wm4: https://github.com/Nevcairiel/FFmpeg/commits/pthread_once
[19:46:03 CEST] <nevcairiel> i re-structured the first commit to make the fallback impl available directly
[19:48:37 CEST] <Gramner> BBB: ugh, mixing mmx and sse. not necessarily anything wrong with it, but it just feels so wrong (and hard to follow since I mentally mix up the registers all the time)
[19:48:50 CEST] <wm4> nevcairiel: hm, I like
[19:48:51 CEST] <BBB> Gramner: sorry, that function sucks
[19:49:12 CEST] <BBB> Gramner: I do the same for 8bit, since theres not enough mmx registers to do it without stack and then it gets slow
[19:49:22 CEST] <BBB> Gramner: I promise I only do it for iadst4
[19:49:26 CEST] <BBB> Gramner: not for anything else
[19:49:42 CEST] <nevcairiel> cant you just do it with sse and leave half the regs empty
[19:49:59 CEST] <BBB> evil
[19:50:08 CEST] <Gramner> personally i would like to kill mmx with fire tbh (and that seems to be what intel is starting to do)
[19:50:26 CEST] <BBB> hm...
[19:50:28 CEST] <BBB> well...
[19:50:31 CEST] Action: BBB stares at swscale
[19:50:33 CEST] <BBB> good luck
[19:50:42 CEST] <BBB> :-D
[19:51:07 CEST] <Gramner> yeah, there's quite a lot of existing code that's not really worth the time it takes to rewrite it
[19:53:06 CEST] <Gramner> I don't think I'm going to write any new mmx code though since using the lower half of xmm regs is better on new (and probably future) Intel µarchs
[19:56:43 CEST] <BBB> I wonder why intel didnt just implement mmx like that on skylake
[19:56:59 CEST] <Gramner> because they're different registers
[19:57:06 CEST] <Gramner> you can't just alias them
[19:57:25 CEST] <Gramner> (they should probably have done that initially when they created sse though)
[19:58:02 CEST] <BBB> didnt mmx share space with x87fpu or so?
[19:58:07 CEST] <nevcairiel> it does
[19:58:08 CEST] <BBB> muhahaha at emms
[19:58:31 CEST] <Gramner> yes, emms is evil. if you get rid of mmx you can rid of that crap too
[19:58:31 CEST] <BBB> they probably didnt want to do that again
[19:58:55 CEST] <nevcairiel> i wonder how much software would break if mmx was suddenly not available anymore
[19:59:45 CEST] Action: BBB stares at swscale again
[19:59:51 CEST] <nevcairiel> only reason amd could remove 3dnow is because it was never available everywhere anyway
[20:00:40 CEST] <Gramner> honestly I'm guessing not that much probably. aside from old games and open source multimedia stuff is probably the largest codebase using mmx
[20:00:52 CEST] <BBB> let me first try to write a 64bit (blegh) 12bpp idct4x4
[20:01:07 CEST] <nevcairiel> i dunno, if some compilter vectorized with mmx, it might show up everywhere
[20:01:15 CEST] <nevcairiel> but they probably dont do that because of the fpu shit
[20:01:33 CEST] <Gramner> exactly. it's hard to accidentaly end up with mmx
[20:01:57 CEST] <Gramner> you kind of have to explicitly implement it
[20:02:09 CEST] <jamrial> nevcairiel: and unlike mmx, which is still somewhat useful even with sse2, 3dnow became completely superfluous with sse
[20:03:26 CEST] <Gramner> the fact that intel ddn't implement 3dnow probably helped to kill it. same with xop, which was actually useful
[20:03:31 CEST] <jamrial> i'm surprised amd still hasn't removed those sse4a instructions. they are pretty much worthless, unlike xop which is nice
[20:03:42 CEST] <jamrial> yeah
[20:04:11 CEST] <jamrial> xop was nice, and they kill it. sse4a is worthless, and it's still available even on Zen
[20:04:23 CEST] <Gramner> sse4a might use an insignificant amount of die space so they might not gain anything from dropping it
[20:04:24 CEST] <nevcairiel> i wodner how Zen works out, the CPU world could use some high-end competition
[20:04:57 CEST] <Gramner> Zen seems quite nice from what I've seen, but it's like 2 years too late to the party
[20:05:28 CEST] <nevcairiel> Intel did a similar thing with Core after the netburst debacle, but that was at the right time
[20:05:43 CEST] <nevcairiel> AMD has been carrying their current arch way too long
[20:06:14 CEST] <JEEB> yeah
[20:06:39 CEST] <Gramner> indeed, AMD:s current µarch is really bad
[20:07:20 CEST] <nevcairiel> when is Desktop Zen supposed to arrive? early 2016 already wasnt it?
[20:07:38 CEST] <Gramner> doubt it's that soon
[20:08:31 CEST] <nevcairiel> yeah probably not
[20:08:44 CEST] <nevcairiel> with a bit of luck middle 2016
[20:09:15 CEST] <Gramner> probably Q3/Q4'16 if there's no significant delays (which is a large possibility). I'd bet on early 2017 but I hope I'm wrong
[20:09:48 CEST] <nevcairiel> in the mean time, Intel also found some delays and pushes another 14nm release
[20:09:57 CEST] <Gramner> the CPU market really needs better competition because right now it's basically intel vs intel vs intel
[20:10:01 CEST] <nevcairiel> which will again be underwhelming at best
[20:10:04 CEST] <jamrial> they gave up on bulldozer long ago. Excavator (latest iteration) was released without much noise, and like steamroller only as 4 core apu
[20:10:36 CEST] <nevcairiel> doesnt help that skylake isn't worth talking about, unless you get a xeon with avx512
[20:10:51 CEST] <Gramner> SKX is 2017
[20:11:09 CEST] <jamrial> seriously?
[20:11:14 CEST] <Gramner> yes
[20:11:15 CEST] <BBB> why does amd still exist
[20:11:18 CEST] <BBB> they do nothing useful
[20:11:25 CEST] <Gramner> not sure when ES:es starts dropping though
[20:11:36 CEST] <jamrial> BBB: they prevent another netburst from happening
[20:11:41 CEST] <BBB> they ship cpus roughly like intel that perform roughly like intel except worse, five years after intel, for the same price as intel
[20:11:47 CEST] <Gramner> BDW-E/EP is Q1'16
[20:11:54 CEST] <Gramner> but that's really nothing interesting about that
[20:12:18 CEST] <nevcairiel> I have a HSW-E, so  BDW-E offers nothing of interest
[20:13:55 CEST] <Gramner> most up to date xeon roadmap (afaik): https://news.xfastest.com/intel/11749/intel-purley-platform-mini-preview-10052015/
[20:43:23 CEST] <Compn> shouldnt we be at 16 cores by now, in all cpu ? :P
[20:43:47 CEST] <Daemon404> g/ 42
[20:44:19 CEST] <Gramner> not really, very few use cases is heabily threaded
[20:44:50 CEST] <Compn> web browsing , each tab new core :P
[20:44:50 CEST] <jamrial> with alac 16bit the decoder allocs some temp buffer that is then dumped into avframe->extended_data, but with 24bit samples it works direcly in avframe->extended_data, which is apparently not padded
[20:44:54 CEST] <jamrial> the asm functions i wrote could in theory overread in that case
[20:45:00 CEST] <Gramner> I laugh every time i see one of those 8-core phones. I mean seriously?
[20:45:28 CEST] <jamrial> how to handle this? make the decoder also use a temp buffer?
[20:45:30 CEST] <jamrial> i find it odd that the avframe alloc functions don't add padding
[20:47:31 CEST] <Gramner> some games are starting to utilize 4 cores quite well nowadays though, but they are few. 6 or 8 cores could start making sense for high-end desktops
[20:47:32 CEST] <rcombs> Gramner: more bigger numbers, boosts scores on multicore benchmarks (which of course don't reflect real phone usage)
[20:47:47 CEST] <rcombs> Gramner: cheaper than sourcing better cores
[20:48:38 CEST] <Gramner> exactly, it's just marketing bs.
[20:49:04 CEST] Action: Daemon404 is more interested in battery than cpu on his phone
[20:49:07 CEST] <Gramner> i liked the Intel gag about that where they taped a xeon phi die onto a phone
[20:50:04 CEST] <BBB> jamrial: just add padding
[20:50:16 CEST] <BBB> jamrial: I think its fine to enforce padding in extended_data, we already do that for other buffers
[20:50:43 CEST] <rcombs> seems like Apple's the only one in mobile trying to actually make powerful ARM cores
[20:53:09 CEST] <jamrial> BBB: how do i do that? the decoder sets avframe->nb_samples then calls ff_thread_get_buffer(). how do i force padding?
[20:53:21 CEST] <jamrial> i may be missing something
[20:53:26 CEST] <BBB> youll have to change the allocation functions
[20:53:33 CEST] <BBB> i.e. this is an api change
[20:53:33 CEST] <nevcairiel> hm
[20:53:35 CEST] <BBB> sort of
[20:53:39 CEST] <nevcairiel> we pad video frames, but not audio?
[20:53:40 CEST] <nevcairiel> kinda odd
[20:53:43 CEST] <jamrial> yeah, not touching those, lol
[20:53:43 CEST] <Compn> in phones, of course battery over cpu
[20:53:44 CEST] <BBB> right
[20:53:49 CEST] <Compn> but in desktop, more cpu!!!!!
[20:53:49 CEST] <BBB> jamrial: then youre screwed :D
[20:54:00 CEST] <jamrial> i'll just make it use a temp buffer like with 16bit samples
[20:54:41 CEST] <jamrial> i'll let someone else deal with avframe :P
[20:55:10 CEST] <Daemon404> g 42
[20:55:35 CEST] <BBB> I keep wondering what g 42 is
[20:55:43 CEST] <BBB> irc script?
[20:55:51 CEST] <nevcairiel> its his irc client
[20:55:57 CEST] <nevcairiel> he switches windows with a command
[20:56:01 CEST] <nevcairiel> and keeps forgetting the /
[20:56:06 CEST] <Daemon404> 42 is my work irc channel for my team
[20:56:11 CEST] <Daemon404> it'sa lso the meaning of life
[20:56:14 CEST] <Daemon404> also*
[21:07:29 CEST] <cone-400> ffmpeg 03Paul B Mahol 07master:ac74e857a265: avfilter/vf_stereo3d: add x86 SIMD for anaglyph outputs
[21:24:57 CEST] <durandal_1707> BBB: trying to add avx2 for scalarproduct int16
[21:25:54 CEST] <durandal_1707> how to extract to wax from m2?
[21:26:11 CEST] <durandal_1707> s/wax/eax
[21:26:50 CEST] <Gramner> movd eax, xm2
[21:26:51 CEST] <BBB> movd
[21:30:08 CEST] <BBB> omg I actually got it working in two tries
[21:30:29 CEST] <Gramner> you're supposed to get it first try, duh
[21:30:33 CEST] <BBB> I have this hideously evil scheme to emulate a 48bit (well, 46 bit, technically) pmadddq using pmaddw
[21:30:59 CEST] <BBB> I guess its pmaddqd
[21:31:29 CEST] <BBB> I mixed up sign between t2 and t3 in my first try, sorry
[21:31:30 CEST] <BBB> Im a failure
[21:31:52 CEST] <BBB> its still very pretty
[21:32:13 CEST] <Gramner> that's by the way the secret to debugging assembly; make everything work perfectly from the start
[21:32:23 CEST] <nevcairiel> lol
[21:32:33 CEST] <nevcairiel> that works for other code too
[21:32:47 CEST] <BBB> Gramner: thanks, thats great advice, Ill keep that in mind
[21:32:59 CEST] <BBB> durandal_1707: did you hear that? ^^
[21:32:59 CEST] <Gramner> you're welcome
[21:33:11 CEST] <Daemon404> eh
[21:33:19 CEST] <Daemon404> that's what the Debian seucirty people told us to do
[21:33:24 CEST] <Daemon404> dont write bugs.
[21:35:31 CEST] <BBB> right, use java instead of c
[21:35:34 CEST] <BBB> stupid devs
[21:35:41 CEST] <BBB> or python
[21:35:47 CEST] <BBB> we all know python is better than c
[21:38:15 CEST] <Gramner> asm.js
[21:38:46 CEST] <Gramner> (and no you're not allowed to compile anything else to it, write it directly)
[21:39:59 CEST] <BBB> because we all love debugging in our browsers
[21:40:00 CEST] <BBB> hm...
[21:40:16 CEST] <J_Darnley> Does FFmpeg have a wrapper for using zlib or any other stream compressors?
[21:40:17 CEST] <BBB> innertia FTW
[21:40:32 CEST] <BBB> J_Darnley: I think using comrpess() directly is acceptable
[21:40:39 CEST] <BBB> J_Darnley: various codecs and demuxers do it
[21:40:48 CEST] <J_Darnley> But that looks so complicated.
[21:40:50 CEST] <BBB> or decompress
[21:40:56 CEST] <BBB> well& yeah
[21:41:05 CEST] Action: J_Darnley sighs
[21:41:36 CEST] <BBB> sorry :(
[21:41:45 CEST] <BBB> maybe you can copypaste it from another piece of code that already uses it?
[21:41:55 CEST] <BBB> thats usually how people develop software anyway
[21:41:58 CEST] <J_Darnley> Unless you wrote the zlib API then it isn't your fault.
[21:42:27 CEST] <J_Darnley> Maybe I'll search for a "zlib for dummies" guide
[21:44:01 CEST] <BBB> Im pretty sure I can claim innocence here
[21:48:51 CEST] <J_Darnley> That was fairly quick: http://zlib.net/zlib_how.html
[21:48:59 CEST] <J_Darnley> I like annotated source.
[21:55:50 CEST] <Daemon404> J_Darnley, teh zlib api isnt very complicated
[21:55:55 CEST] <Daemon404> i mean, i used it
[22:01:39 CEST] <nevcairiel> its a bit counter-intuitive, i found
[22:01:46 CEST] <nevcairiel> but once you understand that, its ok
[22:04:55 CEST] <Daemon404> i suppose
[22:05:01 CEST] <Daemon404> the bigger issue is the generic names
[22:05:09 CEST] <BBB> deflate()
[22:05:11 CEST] <Daemon404> but i guess zlib pretty much 'owns' those function names now
[22:05:12 CEST] <BBB> nice namespace
[22:05:41 CEST] <nevcairiel> if you are the first, you just declare that your namespace
[22:05:55 CEST] <nevcairiel> constants etc are all Z_ at least
[22:11:22 CEST] <durandal_1707> BBB: how to do hardmix from blend vf?
[22:12:29 CEST] <BBB> uh
[22:12:39 CEST] <BBB> well if I tell you how to do it, its no fun, right?
[22:12:56 CEST] <BBB> Ill look at it and you first tell me how you think you should do it, and then Ill tell you youre wrong :-p
[22:12:59 CEST] <BBB> ok?
[22:16:51 CEST] <BBB> durandal_1707: how long do you want to think before I give you the answer? :-p
[22:27:55 CEST] <J_Darnley> git log
[22:40:43 CEST] <durandal_1707> BBB: there is no unsigned variant for pcmpgtb
[22:40:57 CEST] <BBB> so make the arguments signed
[22:41:07 CEST] <Gramner> there is... in avx-512
[22:41:08 CEST] <BBB> pxor m0, [pb_128]
[22:41:24 CEST] <BBB> does avx512 fix world hunger?
[22:41:37 CEST] <Gramner> no, that's planned for a future extension
[22:41:46 CEST] <BBB> pff, so late
[22:41:57 CEST] <BBB> if they wait ny longer, amd will implement it before them
[22:48:07 CEST] <Gramner> my favorite avx-512 instruction is probably vpermt2b. it's like pshufb on crack. arbitrary byte-shuffle spanning the full width of two input vector registers
[22:48:55 CEST] <jamrial> durandal_1707: you mean something like http://pastebin.com/xqPTy89a?
[22:51:56 CEST] <durandal_1707> jamrial: removed
[22:52:13 CEST] <jamrial> remove the ? at the end of the link
[22:52:15 CEST] <jamrial> sorry
[22:54:49 CEST] <bofh__> jamrial: Gramner: correspondingly I'm surprised they added most of BMI1. I mean why use, say, BLSI when I could just use NEG + AND and the former is almost certainly microcoded to the latter.
[22:55:48 CEST] <bofh__> BEXTR is nice and MULX is sorely needed (and was sorely needed for like a decade), but everything else in BMI1/BMI2 just seems... superfluous.
[22:55:55 CEST] <bofh__> (SHRX as well)
[22:59:43 CEST] <Gramner> many of the instructions are useful just because they're non-destructive i guess
[22:59:58 CEST] <jamrial> shr/lx is great. it makes sha hashing much faster
[23:00:34 CEST] <jamrial> of course it wont matter much once the new cpus with the sha intruction sets roll out
[23:00:40 CEST] <Gramner> and gpr instructions require like no die space, so it doesn't really matter if they're not that useful
[23:01:46 CEST] <Gramner> the bmi shift instructions are great pretty much everywhere and compilers probably use them heavily
[23:02:08 CEST] <Gramner> the variable shifts pre-bmi are kinda dumb
[23:05:38 CEST] <BBB> durandal_1707: did you figure hardmix out already?
[23:05:46 CEST] <BBB> durandal_1707: Im still waiting for your answer sheet so I can grade it :-p
[23:06:40 CEST] <jamrial> durandal_1707: in any case, seeing that the samples need to be shifted by 8 at the end (so them being in a temp buffer or in avframe.extended_data will not really matter), and considering i saw some slight performance increase with the ml patch, wouldn't it be better to apply that instead?
[23:08:17 CEST] <Gramner> the least useful bmi instructions are BLSMSK and BLSR since they can be done in two basic 1-cycle instructions that are also non-destructive
[23:11:52 CEST] <durandal_1707> jamrial: test with longer sample, test my approach
[23:12:30 CEST] <jamrial> durandal_1707: the pastebin above is good then?
[23:12:49 CEST] <Daemon404> peloverde, will demuxed videos be up anywhere
[23:14:25 CEST] <durandal_1707> jamrial: should be, fate passes?
[23:15:32 CEST] <peloverde> They should go up on demuxed.com in the next few days
[23:15:46 CEST] <Daemon404> cool
[23:16:27 CEST] <Daemon404> there's some twitter videos on snappytv
[23:16:36 CEST] <Daemon404> but i cant figured how to actually get to the clip pages
[23:16:40 CEST] <Daemon404> since i dont wanna watch it on twitter
[23:28:52 CEST] <BBB> Daemon404: see you in a bit, going home and then off there
[00:00:00 CEST] --- Wed Oct  7 2015