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

[burek]

[00:04:14 CEST] <BBB> durandal_1707: probably
[00:04:24 CEST] <BBB> durandal_1707: theres various ways to write it, this one is probably fairly easy to follow
[00:04:35 CEST] <BBB> durandal_1707: I can teach you other methods as we go and you can choose which one you like most :)
[00:06:38 CEST] <durandal_1707> lets continue tomorrow, its late
[00:07:59 CEST] <BBB> ok, g'nite
[00:41:58 CEST] <rcombs> looks like some fate tests are borked
[00:42:19 CEST] <rcombs> filter-separatefields, filter-select-alternate, filter-tblend, others
[00:53:53 CEST] Action: rcombs spins wheel
[00:53:55 CEST] <rcombs> I blame wm4
[00:58:28 CEST] <wm4> I accept the blame
[00:58:43 CEST] <wm4> I have a solution: remving 200kloc of code
[00:58:49 CEST] <wm4> removing even
[00:59:47 CEST] <rcombs> actually it might just be me forgetting to `make install` because dylibs are silly
[00:59:54 CEST] <rcombs> so& never mind, then
[01:00:09 CEST] <wm4> I noticed the same problem on linux
[01:00:46 CEST] <wm4> due to rpath ffmpeg is picking up the installed libs, not the locally compiled ones
[01:00:59 CEST] <rcombs> yeah
[01:01:07 CEST] <rcombs> doesn't happen if you only build static libs, but&
[01:12:27 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:dabea74d0e82: avcodec/vp8: Do not use num_coeff_partitions in thread/buffer setup
[01:21:34 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:9e9d731b5106: avcodec/pngdec: mark previous_picture as done on end of decode_frame_common()
[01:25:12 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179207.html <-- nobody seems to object to this, so should I just push?
[01:38:24 CEST] <wm4> rcombs: should be ok IMO
[01:40:59 CEST] <wm4> you could ping it if you're unsure
[01:51:33 CEST] <jamrial> BBB: you're not really using pw_4095 on vp9lpf_16bpp, yet you moved it to constants.c to include it there.
[02:10:06 CEST] <rcombs> hmm, I can't connect via ssh for git
[02:10:17 CEST] <BBB> jamrial: I am, I think?
[02:10:23 CEST] <BBB> jamrial: I must be using it for clipping pixels
[02:10:55 CEST] <BBB> jamrial: https://github.com/rbultje/ffmpeg/commit/32a0178737312ed551a66ad11ac769c34f70eeb2#diff-15a4e36ff9001a7cf03b25f899e393f7R217
[02:11:07 CEST] <BBB> and then look for pw_ %+ %%maxusgn
[02:11:49 CEST] <jamrial> oh, i see, i looked for pw_4095 and only found the cextern line
[02:11:51 CEST] <jamrial> nevermind then
[02:12:46 CEST] <BBB> jamrial: sorry, its a little bit convoluted maybe
[02:14:33 CEST] <BBB> Gramner: your patch is totally obscure
[02:16:04 CEST] <BBB> so you get one flag field after the &, then you ^ it with the flag itself, so its flag if not set, or 0 if set, then you -1, so its -1 if set, or something relatively small if set, then you >>31 to get -1 if set or 0 if not set, and then you &1 to get 1, right?
[07:52:44 CEST] <Gramner> BBB: cpuflags_xxx is not a single flag bit, it's multiple, so & gives a bunch of bits. that's why the ^ is neccessary. otherwise correct
[07:53:14 CEST] <Gramner> since x ^ y == 0 iff x == y
[11:41:05 CEST] <ubitux> wm4: c368538667121fb20c5414dfaf0fb273035a0854
[11:41:16 CEST] <ubitux> wasn't buf[1] supposed to be buf[0]?
[11:43:54 CEST] <ubitux> somehow unrelated but it appears that sometimes there are other stuff after the event number
[11:43:57 CEST] <ubitux> that's so insane&
[11:44:05 CEST] <ubitux> https://trac.ffmpeg.org/attachment/ticket/4898/events_export.srt
[11:44:31 CEST] <ubitux> anyway, the probing need to be more lenient&
[11:45:45 CEST] <wm4> ubitux: you might be right...
[11:45:56 CEST] <ubitux> ok
[11:45:59 CEST] <ubitux> i'll fix in a moment
[11:50:30 CEST] <cone-572> ffmpeg 03Clément BSsch 07master:d161a2a72b08: avformat/srtdec: fix number check for the first character
[11:50:30 CEST] <cone-572> ffmpeg 03Clément BSsch 07master:7218352e0228: avformat/srtdec: more lenient first line probing
[11:51:27 CEST] <Daemon404> ubitux's favourite passtime: SRT
[11:51:43 CEST] <wm4> srt seems to make a lot of work
[11:51:55 CEST] <Daemon404> because it's a bad format that was just kinda madeup 
[11:51:59 CEST] <Daemon404> but teh subrip guy
[11:52:09 CEST] <Daemon404> was never intended to distro, i think?
[11:52:12 CEST] <ubitux> it's actually pretty fine
[11:52:12 CEST] <Daemon404> (i could be wrong)
[11:52:22 CEST] <wm4> seems like a very bad format to me
[11:52:27 CEST] <ubitux> i mean, fixing them is not that much work
[11:52:38 CEST] <Daemon404> ubitux, dealing with users' srt files make me hate it, i guess
[11:52:39 CEST] <ubitux> i think the format is fine, except maybe the numbering of events
[11:52:45 CEST] <Daemon404> 90 million workarounds for bad srt files
[11:52:52 CEST] <ubitux> :)
[12:21:57 CEST] <nevcairiel> srt is pretty simple, the only annoying part is the subset of html tags people like to throw in it
[12:22:12 CEST] <nevcairiel> but even simple string parsing and C don't like each other very much
[12:49:25 CEST] <durandal_170> BBB: hi, I wrote asm that memset buffer to zero
[12:52:01 CEST] <BBB> durandal_170: \o/
[12:52:05 CEST] <BBB> very good
[12:52:49 CEST] <JEEB> I should hone my asm skills some day, I haven't written a line of asm since '12
[12:52:53 CEST] <BBB> try to write a multiply
[12:53:01 CEST] <BBB> JEEB: didnt we practice asm a few years ago?
[12:53:05 CEST] <JEEB> yeah
[12:53:06 CEST] <BBB> I thought we did
[12:53:08 CEST] <BBB> ah, ok
[12:53:13 CEST] <BBB> I thought I was getting forgetful
[12:53:25 CEST] <BBB> durandal_170: or, actually, start with a copy
[12:53:28 CEST] <JEEB> I did manage to do some left-prediction
[12:53:30 CEST] <BBB> durandal_170: and then try to write a multiply of some sort
[12:53:37 CEST] <BBB> durandal_170: youll get the hang of it pretty quickly
[13:00:44 CEST] <wm4> holy shit, libavdevice/decklink_common.cpp is ifdefferied to work on both win32 and OSX (using some native APIs on both)
[13:02:02 CEST] <durandal_170> BBB: what should I use to subtract what I get from punpcklbw?
[13:06:33 CEST] <BBB> psubw
[13:06:39 CEST] <BBB> theres also paddw
[13:06:45 CEST] <BBB> (add word)
[13:06:51 CEST] <BBB> and theres paddb, paddd, etc.
[13:07:00 CEST] <BBB> and sub counterparts
[13:07:20 CEST] <BBB> theres also a variety of multiply or multiply-and-add variants
[13:23:53 CEST] <durandal_170> BBB: what to use for multiply and add?
[13:28:44 CEST] <BBB> durandal_170: try pmaddwd
[13:28:51 CEST] <BBB> durandal_170: theres also pmaddubsw, which is ssse3
[13:29:10 CEST] <BBB> durandal_170: pmaddwd takes words as input and outputs the sum of two adjacent word-multiplies in a single dword
[13:29:48 CEST] <BBB> durandal_170: so for input a1,a2,a3,a4,a5,a6,a7,a8 and b1-8, it returns dwords: a1*b1+a2*b2, a3*b3+a4*b4, a5*b5+a6*b6, a7*b7+a8*b8
[13:30:05 CEST] <BBB> durandal_170: pmaddubsw is the same ish for byte to word
[13:30:36 CEST] <BBB> durandal_170: but for pmaddubsw you typically care about signedness, so dst/src1 should be unsigned and src2 should be signed
[13:30:43 CEST] <BBB> durandal_170: whereas for pmaddwd I believe theyre both signed
[13:33:54 CEST] <durandal_170> BBB: but I need to add 128, how can this be done?
[13:35:29 CEST] <BBB> two ways
[13:35:36 CEST] <BBB> you typically want to add a constant
[13:35:40 CEST] <BBB> for that, we have rodata
[13:35:50 CEST] <BBB> so you can have a RO_DATA segment with pw_128: times 8 dw 128
[13:35:58 CEST] <BBB> and thats exactly that
[13:36:11 CEST] <BBB> we probably already have that in another file so then you can share it with the other file by using cextern pw_128
[13:36:17 CEST] <BBB> but in avfilter maybe not
[13:36:29 CEST] <BBB> then, you typically shift, right? like psraw m0, 8
[13:36:37 CEST] <BBB> psraw=signed shift, psrlw=unsigned shift
[13:36:41 CEST] <BBB> psllw=left-shift
[13:36:58 CEST] <BBB> but you can also merge the add a shift together, by using pmulhrsw
[13:37:25 CEST] <BBB> look up what that instruction does and how vp9/vp8 ssse3 code uses it and youll get quickly enough how that allows merging an add+shift into a single instruction
[13:55:15 CEST] <Gramner> BBB: cpuflags_* is not a single flag bit, it's multiple, so & results in several bits. that's why the ^ is neccessary (since x ^ y == 0 iff x == y). otherwise correct
[13:59:31 CEST] <BBB> ohright
[13:59:32 CEST] <BBB> ok
[14:35:46 CEST] <durandal_170> BBB: I did it but thing can overflow 16 bit when adding 128
[14:35:56 CEST] <BBB> nah
[14:36:07 CEST] <BBB> having a pixel of 8 bit max value=0xff
[14:36:15 CEST] <BBB> multiply by 256 gives 0xff00
[14:36:19 CEST] <BBB> adding 0x80 gives 0xff80
[14:36:22 CEST] <BBB> easily fits 16bit
[14:37:46 CEST] <durandal_170> yes but last addition is also xff
[14:41:21 CEST] <BBB> you could try a saturated add
[14:41:35 CEST] <BBB> http://x86.renejeschke.de/html/file_module_x86_id_229.html
[14:41:39 CEST] <BBB> paddusw
[14:44:05 CEST] <durandal_170> I pushed wip to github
[14:48:12 CEST] <durandal_170> well I don't think overflow do happen
[14:52:52 CEST] <durandal_170> BBB: can you spot obvious bug?
[14:53:14 CEST] <BBB> link to actual patch?
[14:57:47 CEST] <durandal_1707> BBB: https://github.com/FFmpeg/FFmpeg/compare/master...richardpl:mm
[15:40:33 CEST] <ubitux> ./configure --help|grep enable-hwaccel
[15:40:41 CEST] <ubitux> ./configure --enable-hwaccel=vdpau --fatal-warnings
[15:40:43 CEST] Action: ubitux sadness
[15:41:59 CEST] <wm4> ?
[15:42:42 CEST] <ubitux> the option --enable-hwaccel is not recognized
[15:43:32 CEST] <durandal_170> this broke?
[15:44:06 CEST] <ubitux> maybe, still trying to figure out what's going on
[15:44:49 CEST] <ubitux> enable d3d11va dxva2 vaapi vda vdpau videotoolbox xvmc  i wonder why these global vars are not prefixed by hwaccel_*
[15:45:30 CEST] <ubitux> or maybe suffixed, i don't remember the convention
[15:46:17 CEST] <BBB> durandal_1707: looks ok to me
[15:46:31 CEST] <BtbN> It's codec_api_hwaccel
[15:46:38 CEST] <BtbN> so for example hevc_vaapi_hwaccel
[15:47:08 CEST] <nevcairiel> ubitux: those are not the hwaccels themself, but the depedency "libraries"
[15:47:13 CEST] <nevcairiel> dependency*
[15:47:24 CEST] <durandal_170> BBB: using unsigned shift I get better results
[15:47:40 CEST] <ubitux> nevcairiel: ah yeah i remember now...
[15:47:54 CEST] <BBB> durandal_170: unsigned shift (psrlw) should be right, yes
[15:47:56 CEST] <ubitux> i need --enable-<hwaccel>
[15:48:10 CEST] <durandal_170> But some super white become black
[15:48:22 CEST] <BBB> hm& let me see
[15:48:58 CEST] <BBB> so you have pixels, right?
[15:49:01 CEST] <BBB> you subtract
[15:49:10 CEST] <BBB> so you get a word range of -0xff,0xff
[15:49:12 CEST] <durandal_170> Yes
[15:49:18 CEST] <BBB> then you multiply with 0-0xff
[15:49:32 CEST] <BBB> so you get something along the range of -0xff00,0xff00
[15:49:37 CEST] <BBB> ?
[15:49:54 CEST] <BBB> so that doesnt fit in anything
[15:49:58 CEST] <BBB> you may want to do two pmullws then
[15:50:35 CEST] <BBB> so ignore the bilinear trick that I mentioned earlier (a*b+(256-a)*c+128>>8 = c+(a*(b-c)+128>>8)
[15:50:40 CEST] <BBB> since that only works if you have a bit left
[15:50:45 CEST] <BBB> so just do two pmullws
[15:51:03 CEST] <BBB> and then the range of the output result should be 0-0xff00 again
[15:52:40 CEST] <BBB> you should be able to use this trick for 10-14bpp
[15:52:52 CEST] <BBB> just not for 8bpp
[16:16:15 CEST] <durandal_170> BBB: what instruction do uint8 clipping?
[16:16:25 CEST] <BBB> packuswb clips signed word to unsigned byte
[16:16:40 CEST] <BBB> and at the same time moves them from word to byte packing
[16:17:54 CEST] <durandal_170> now I can write simd for few blend modes
[16:53:28 CEST] <BBB> durandal_170: ah so its working? cool
[16:54:15 CEST] <durandal_170> I'm out of machine
[16:54:56 CEST] <wm4> ubitux: should srt be able to handle entities? like ">"
[16:55:24 CEST] <ubitux> are you crafting a file to tease me?
[16:55:42 CEST] <RiCON> http://j.fsbn.eu/The.Daily.Show.2015.09.30.Chris.Christie.720p.CC.WEBRip.AAC2.0.x264-BTW.mkv_00_00_02.536_1.jpg
[16:55:57 CEST] <RiCON> subs with these seem to only come from comedy central
[16:56:03 CEST] <ubitux> wm4: if you have a file like this, i suppose it has to
[16:56:12 CEST] <ubitux> omg
[16:56:14 CEST] <ubitux> :((
[16:56:51 CEST] <BBB> hehe :)
[16:57:26 CEST] <nevcairiel> ubitux: i can make you any crazy-ass thing you want, if you're looking for busy-work
[16:57:38 CEST] <ubitux> i'm really not :(
[16:58:59 CEST] <nevcairiel> any semi-spec you find only mentions b/i/u/font tags, no mention of html entities
[16:59:06 CEST] <nevcairiel> what even renders those
[16:59:59 CEST] <RiCON> well, vsfilter doesn't
[17:00:29 CEST] <RiCON> nor mpc-hc's internal renderer
[17:00:53 CEST] <wm4> RiCON> subs with these seem to only come from comedy central <- so over youtube-dl? then it might be youtube-dl's fault
[17:01:44 CEST] <nevcairiel> some players had problems with <> in the text in the past. someone might have thought its a smart idea to escape them
[17:01:46 CEST] <RiCON> dunno if the group uses ytdl to rip it, nor can i test since CC videos aren't acessible here
[17:02:44 CEST] <ubitux> rcombs had some escaping code no?
[17:02:57 CEST] <ubitux> if it gets upstream maybe we could use it for srt
[17:03:03 CEST] <ubitux> probably harmless
[17:03:59 CEST] <wm4> RiCON: there must be at least one player which handles it
[17:07:41 CEST] <RiCON> http://sprunge.us/XYHS?json
[17:07:54 CEST] <RiCON> comedy central's flash player, I guess
[17:09:04 CEST] <RiCON> so it is probably ytdl's issue
[17:09:25 CEST] <RiCON> since they should convert the entities when converting from vtt to srt(?)
[17:09:55 CEST] <wm4> I'd say so (and here I bet ffmpeg's vtt code doesn't handle this either?)
[17:10:21 CEST] <kierank> lol webvtt
[17:10:35 CEST] <kierank> I'd have loved wm4 and j-b in the same room as the webvtt people 3 years ago
[17:10:40 CEST] <nevcairiel> fucking webvtt
[17:10:53 CEST] <nevcairiel> because everything is a web browser these days
[17:11:25 CEST] <ubitux> we could easily escape all the < &gtl &quot etc
[17:11:44 CEST] <ubitux> but well, what about é etc
[17:12:08 CEST] <ubitux> http://webdesign.about.com/od/localization/l/blhtmlcodes-fr.htm  random fun
[17:17:11 CEST] <cone-099> ffmpeg 03Sven Dueking 07master:5d4a3563f23d: qsvenc.c: use query to catch all kind of setting issues
[17:22:08 CEST] <RiCON> ytdl uses ffmpeg to convert the subs, so I guess ffmpeg vtt code is supposed to deal with it
[17:24:41 CEST] <RiCON> ubitux: you probably only need these escapes: http://dev.w3.org/html5/webvtt/#dfn-webvtt-escape-state
[17:28:18 CEST] <ubitux> RiCON: ok
[17:28:20 CEST] <ubitux> error: 'UTGetOSTypeFromString' is unavailable: not available on iOS
[17:28:22 CEST] <ubitux> FU
[17:28:24 CEST] <ubitux> FUUUU :(
[17:28:31 CEST] <ubitux> vtb doesn't work anymore on ios
[17:29:13 CEST] <nevcairiel> thats only part of ffmpeg_videotoolbox.c, not the actual hwaccel
[17:29:17 CEST] <nevcairiel> so if you dont need that..
[17:29:23 CEST] <ubitux> except the dep is actually hard
[17:29:50 CEST] <nevcairiel> fixing the dep should be easy
[17:30:43 CEST] <ubitux> there is no dependency granularity between videotoolbox and ffmpeg_videotoolbox
[17:30:51 CEST] <nevcairiel> yes, add one
[17:30:52 CEST] <nevcairiel> :D
[17:32:24 CEST] <nevcairiel> or even better, make the code to select a pixfmt dependent on that only
[17:33:04 CEST] <ubitux> yeah, it's simpler
[17:33:26 CEST] <ubitux> or maybe i'll add a ff_fuapple_UTGetOSTypeFromString
[17:42:58 CEST] <ubitux> it's curious how the link on CoreServices doesn't complain though
[17:55:35 CEST] <Gramner> BBB: i was thinking about adding a comment above the cpuflag() code in x86inc. how does "; Returns a boolean value expressing whether or not the specified cpuflag is enabled." sound?
[17:56:22 CEST] <BBB> it sounds like adding a comment // a counter that iterates from 0 to num above a line int i;
[17:56:43 CEST] <BBB> I dont think its necessary, its pretty obvious what it does
[17:56:52 CEST] <BBB> how it does it, is a little bit convoluted
[17:58:23 CEST] <Gramner> the macros in x86inc are basically an API though
[17:59:53 CEST] <BBB> true
[18:00:26 CEST] <BBB> ok, I guess the comment is fine
[18:00:31 CEST] <BBB> for api doc purposes
[18:00:45 CEST] <BBB> it still doesnt explain the elaborate set of operands that implements the api ;)
[18:00:46 CEST] <Gramner> I thunk it makes sense to be more verbose there than in a random piece of code
[18:02:03 CEST] <Gramner> x86inc is in general poorly documented but that's fairly standard when it comes to open source stuff
[18:03:22 CEST] <Gramner> the go-to answer is basically "look at and/or copy some existing code and work from there"
[18:03:37 CEST] <ubitux> we need a warning or something when a explicitely requested element is not actually enabled in the configure
[18:04:13 CEST] <ubitux> --fatal-warnings mitigates some of it (if we typo), but not if a requested element is not enabled because of a missing dep
[18:04:33 CEST] <ubitux> like, --enable-ffplay but missing sdl or sth like that
[18:07:24 CEST] <BBB> Gramner: thats certainyl how I started
[18:07:35 CEST] <BBB> Gramner: ask durandal_1707, he just started writing assembly today
[18:13:00 CEST] <BBB> Gramner: and patch remains ok of course (I dont feel like responding on ML :-p)
[18:13:31 CEST] <Gramner> ok, I'll just push it I guess, thanks
[18:14:16 CEST] <BBB> ty!
[18:14:22 CEST] <BBB> (it allows me to push one of my patches)
[18:14:39 CEST] <BBB> or, well, at least makes it work
[18:14:47 CEST] <BBB> the dir intra pred simd one
[18:21:48 CEST] <cone-099> ffmpeg 03Henrik Gramner 07master:17710550c483: x86inc: Make cpuflag() and notcpuflag() return 0 or 1
[18:22:54 CEST] <BBB> Gramner: do you know if theres anything alongside pmaddqd?
[18:23:01 CEST] <BBB> Gramner: if you see what I mean
[18:23:31 CEST] <Gramner> 128-bit add?
[18:23:37 CEST] <BBB> pmaddwd
[18:23:45 CEST] <BBB> but dq instead of wd
[18:23:59 CEST] <BBB> does that exist? can I emulate it somehow?
[18:25:04 CEST] <Gramner> probably need to do separate multiplies and adds
[18:29:57 CEST] <Gramner> pmuldq, psrlq, pmuldq, paddq or something
[18:31:28 CEST] <durandal_170> cpuflags are global?
[18:31:33 CEST] <Gramner> there's really not much consistency in the x86 instruction sets. some instructions are really good but nobody bothered porting them to other data types
[18:34:57 CEST] <kierank> http://demuxed.com/live.html
[18:34:59 CEST] <Gramner> durandal_170: the cpuflags variable is set by INIT_MMX/INIT_XMM/INIT_YMM and remains until the next invocation of INIT_*
[19:28:15 CEST] Action: DHE is bisecting a regression/bug in libavformat/hlsenc.c
[19:47:45 CEST] <J_Darnley> durandal_1707: You define the linesize arguments as integer so on x86_64 you need to sign-extend (movsx or the macro movsxifnidn) the registers before using the quadword versions.
[19:56:13 CEST] <jamrial> no, he should use ptrdiff_t
[19:57:03 CEST] <J_Darnley> Or that.  I just sent an email with that comment and another
[19:58:51 CEST] <cone-099> ffmpeg 03Carl Eugen Hoyos 07master:aea5db97f794: lavf/rawdec: Autodetect raw mlp streams.
[20:00:47 CEST] <durandal_1707> I just fixed it
[20:20:53 CEST] <durandal_1707> jamrial: what to use to copy one m to another?
[20:21:04 CEST] <jamrial> mova
[20:22:06 CEST] <durandal_1707> I do and it crashes
[20:22:55 CEST] <jamrial> weird, can i see the code? pastebin or github
[20:30:12 CEST] <durandal_1707> I changed order, perhaps thats problem?
[20:30:26 CEST] <durandal_1707> function args*
[20:31:53 CEST] <jamrial> ah, could be. if you change the prototype you'll have to change the cglobal line accordingly
[20:40:48 CEST] <durandal_1707> jamrial: putting back lea fixes it
[20:43:43 CEST] <jamrial> that's odd
[20:43:59 CEST] <jamrial> are you replacing "lea reg, [reg + linesize]" with "add reg, linesize"?
[20:45:35 CEST] <durandal_1707> oops, no
[20:47:37 CEST] <DHE> I'll see if I can make a fix for #4900
[20:53:24 CEST] <durandal_1707> jamrial: can this function make use of newer instructions?
[20:55:18 CEST] <jamrial> if you need them sure, but you'll have to duplicate the function to make sure the correct version runs on supported targets
[20:55:54 CEST] <jamrial> the sse2 version of the function must not use newer instructions
[21:00:28 CEST] <wm4> michaelni: apparently cbbd906be6150be38dfc14b6bc67dcac8da8aea4 break rtmpe
[21:00:48 CEST] <wm4> and of course the commit doesn't indicate what the heck it's needed for
[21:00:53 CEST] <wm4> (classic)
[21:01:47 CEST] <wm4> especially fun because the flv data is muxed by lavf itself in this case
[21:04:19 CEST] <superware> is cehoyos here?
[21:04:47 CEST] <BtbN> Just look at the userlist?
[21:06:59 CEST] <superware> maybe a different name here... this is his "tracker" name
[21:07:50 CEST] <durandal_1707> he is not on irc
[21:08:36 CEST] <durandal_1707> jamrial: what instructions?
[21:09:42 CEST] <jamrial> anything newer than sse2. you asked if you could use newer instructions, so i assumed you had some in mind that could be used for this function
[21:10:57 CEST] <Gramner> ssse3 and sse4 could possibly be useful
[21:16:10 CEST] <durandal_1707> well I need exact instruction
[21:16:19 CEST] <Gramner> see ML
[21:19:47 CEST] <jamrial> Gramner: pmovzx is useful mainly when you can't afford having a register containing all zeroes (or with avx2 when you need to zero extend across lanes). It's not faster than punpck, so not really worth adding an sse4 version of the function just for that
[21:21:36 CEST] <Gramner> that might be true I guess, I haven't used any of the sign/zero extension instructions from SSE4 in ages
[21:26:25 CEST] <BBB> you x264 kids get to play all day with haswells and skylakes
[21:26:52 CEST] <BBB> you dont understand us responsible adults who have to dig in the dungeons of realworld cpus [tm]
[21:27:10 CEST] <BBB> *grumble*
[21:27:13 CEST] <nevcairiel> i live in the real world and i have 2 haswells in my house :(
[21:27:16 CEST] <Gramner> I don't have an skylake xeon with AVX-512... yet ;)
[21:27:31 CEST] <nevcairiel> (and another in a remote server)
[21:27:52 CEST] <BBB> yo intel wheres my skylake?
[21:27:57 CEST] Action: BBB shouts in the void
[21:28:55 CEST] <nevcairiel> i didnt buy skylake because the specs seemed rather underwhelming
[21:29:05 CEST] <Gramner> normal skylakes aren't that interesting for writing asm though
[21:29:20 CEST] <nevcairiel> simd wise it got nothing over a haswell anyway
[21:29:24 CEST] <nevcairiel> and even performance wise it doesnt
[21:29:26 CEST] <nevcairiel> so there is that
[21:29:27 CEST] <nevcairiel> :D
[21:29:30 CEST] <BBB> its interesting if the last thing you had was a core2
[21:29:38 CEST] <nevcairiel> buy a broadwell
[21:29:47 CEST] <BBB> yo intel wheres my broadwell
[21:29:55 CEST] <Gramner> it has more execution engines for some SIMD stuff, but doesn't really affect how you write code
[21:29:59 CEST] <BBB> silence, still
[21:30:14 CEST] <Gramner> it also has LESS execution engins for some MMX SIMD which is interesting
[21:30:20 CEST] <nevcairiel> i was offered some intel hardware once, but silly me was honest and admitted in already having everything thats needed
[21:30:24 CEST] <Gramner> i believe they're starting to deprecate mmx
[21:30:54 CEST] <nevcairiel> they should just like emulate mmx in sse execution units
[21:31:02 CEST] <Gramner> so porting some mmx to sse2 might be useul on skylake even if you only use half of the xmm registers
[21:31:20 CEST] <nevcairiel> i wonder if we still have a b unch of code thats mmx-only
[21:31:29 CEST] <nevcairiel> porting mmx to sse/sse2 isnt that big of a deal
[21:31:33 CEST] <BBB> nevcairiel: ...
[21:31:42 CEST] <BBB> nevcairiel: can you forward these emails to me? :-p
[21:31:49 CEST] <nevcairiel> it was years ago
[21:31:52 CEST] <BBB> the correct response is not I alreeady have it
[21:32:02 CEST] <nevcairiel> and about gpu decoding support, not simd
[21:32:04 CEST] <BBB> the correct response is I dont need it, but BBB here[CCed] does"
[21:32:28 CEST] <BBB> he wants a new macbook pro, his old one is crapping out
[21:32:33 CEST] <BBB> (or so)
[21:32:48 CEST] <Gramner> you can get their compiler for free if you do non-profit open source things. isn't that enough?!
[21:33:04 CEST] <nevcairiel> i just bought a macbook last year as a tax writeoff :(
[21:33:05 CEST] <BBB> no
[21:33:21 CEST] <BBB> oooooh thats right I can subtract macs from taxes
[21:33:31 CEST] <BBB> can I subtract both a mbp as well as a mac pro?
[21:33:33 CEST] <BBB> or is it either or?
[21:33:40 CEST] <nevcairiel> what do i know
[21:33:45 CEST] <nevcairiel> i dont think they would care here
[21:33:51 CEST] <BBB> here=?
[21:33:55 CEST] <nevcairiel> not US
[21:33:55 CEST] <nevcairiel> :D
[21:33:58 CEST] <BBB> crap
[21:34:29 CEST] <nevcairiel> writing off individual hardware upgrades is always a bit harder, so a complete thing like a macbook was easier
[21:34:36 CEST] <nevcairiel> and i needed something for some mac testing anyway
[21:34:42 CEST] <nevcairiel> better than my old hackintosh, i guess
[21:38:00 CEST] <BtbN> philipl, that 940M doesn't seem to support nvenc at all. At least OpenEncodeSessionEx fails with ERR_UNSUPPORTED_DEVICE
[21:38:31 CEST] <nevcairiel> speaking about nvenc, i setup OBS the other night, and the nvenc encoder produces nothing but odd looking garbage :(
[21:38:49 CEST] <BtbN> It worked for me when i wrote it.
[21:39:00 CEST] <BtbN> No idea what they did to it though after i left.
[21:39:14 CEST] <nevcairiel> x264 still worked, so i just used that for the time being
[21:39:29 CEST] <BtbN> Did you set it to some strange lossless mode?
[21:39:30 CEST] <nevcairiel> it just blocked me for like an hour when i was debugging the other end of my  streaming chain =p
[21:39:32 CEST] <Daemon404> BtbN, they follow MS naming...?
[21:39:36 CEST] <nevcairiel> BtbN: nah just defaults
[21:39:39 CEST] <Daemon404> (FunctionEx)
[21:39:47 CEST] <nevcairiel> i should test ffmpeg and see if that works
[21:39:51 CEST] <nevcairiel> or my driver maybe being screwed
[21:39:56 CEST] <BtbN> Daemon404, yeah, seems like it
[21:40:29 CEST] <Daemon404> when do we get OpenEncodeSessionW
[21:40:31 CEST] <Daemon404> and A
[21:40:54 CEST] <BtbN> As all functions are dynamicaly loaded, they can be named whatever you like anyway.
[21:41:36 CEST] <Daemon404> 9
[21:41:37 CEST] <Daemon404> o
[21:42:09 CEST] <BtbN> I wonder if it's just some unsupported parameter, some weirdness with this optimus laptop, or if there actualy is no nvenc unit in this GPU
[21:45:06 CEST] <BtbN> yep, it actualy has no video engine. The hell
[21:45:10 CEST] <nevcairiel> hm which header do i have to collect again for nvenc
[21:45:13 CEST] Action: nevcairiel looks
[21:45:17 CEST] <BtbN> nvEncodeApi.h
[21:45:40 CEST] <BtbN> somewhere inside that 300MB zip archive
[21:46:05 CEST] <nevcairiel> wasnt that the thing which actually hides somewhere in the samples folder
[21:46:08 CEST] <BtbN> yes
[21:46:09 CEST] <nevcairiel> not in a prominent "includes" folder
[21:47:02 CEST] <nevcairiel> hey its only 92mb
[21:47:21 CEST] <BtbN> oh, they removed the tons of sample yuv videos?
[21:47:27 CEST] <nevcairiel> dunno
[21:47:36 CEST] <nevcairiel> nvenc_5.0.1_sdk.zip .. 92.1mb
[21:53:35 CEST] <Gramner> durandal_1707: oh another minor thing, it's customary to vertically align asm so that the first comma in each row is at the same column (exceptions for long lines are fine, stores are usually the main culprit)
[21:56:44 CEST] <BBB> if anyone ever thought libvpx encoding was slow with vp9
[21:56:54 CEST] <BBB> try a vp10 encode compiled at -O0 running under valgrind
[21:56:56 CEST] <cone-099> ffmpeg 03Paul B Mahol 07master:0701ff2c321e: avfilter/x86/vf_psnr.asm: fix typo
[21:57:09 CEST] <DHE> what's your SPF rate?
[21:57:32 CEST] <gnafu> Enough to prevent sunburn, that's for sure!
[21:57:45 CEST] <Gramner> do you need 64-bit integers to measure SPF?
[21:57:51 CEST] <Gramner> ;)
[21:57:59 CEST] <nevcairiel> vp9 at least seems to have gotten a bit faster since I tested it a couple years ago
[21:58:12 CEST] <DHE> Seconds Per Frame  (1/fps)
[21:59:03 CEST] <BBB> I think Im at multiple minutes per frame
[21:59:06 CEST] <BBB> I might be approaching HPF
[21:59:15 CEST] <BBB> its pretty painful
[21:59:24 CEST] <nevcairiel> well no opts and valgrind
[21:59:29 CEST] <nevcairiel> :D
[22:00:04 CEST] <Gramner> is it possible to run valgrind valgrind <something>?
[22:00:36 CEST] <BBB> Id like intel to reinstate moores law
[22:00:41 CEST] <BBB> this isnt going anywhere
[22:00:44 CEST] <BBB> its all intels fault
[22:01:01 CEST] <ubitux> valgrind: You cannot run 'valgrind' directly.
[22:01:13 CEST] <Gramner> that's lame
[22:01:35 CEST] <BBB> if something takes 10 years to finish (1YPF), then according to moores law, it makes more sense to wait 2 years to run it, since then it finishes in 2.5 years
[22:02:00 CEST] <BBB> take that, xkcd compiling!
[22:02:57 CEST] <Gramner> doesn't moore's law only cover transistor density though? while that correlates somewhat with performance it's not linear
[22:05:25 CEST] <kurosu_> iirc, most of the remaining mmx code is related to mpeg2 (grep -l '%%m' ../libavcodec/x86/*.c)
[22:05:57 CEST] <JEEB> the libmpeg2 legacy?
[22:06:06 CEST] <JEEB> aka the mpeg-2 GPL code :D
[22:06:31 CEST] <BBB> no, native mpegvideo code also
[22:06:35 CEST] <kurosu_> I don't know, might be code written during michael's first years on ffmpeg
[22:07:45 CEST] <kurosu_> I have equivalent crime with vc1, but seeing how it is broken anyway and the existence of h/w acceleration for it...
[22:08:19 CEST] <nevcairiel> wtf is wrong with my ffmpeg
[22:08:59 CEST] <nevcairiel> http://pastebin.com/7zvnkDhN .. am i too dumb to use it today, or did something magical break somewhere
[22:09:40 CEST] <wm4> ffmpeg maps to ffprobe?
[22:09:40 CEST] <JEEB> o__O
[22:09:47 CEST] <wm4> look at the version header
[22:09:48 CEST] <JEEB> oh
[22:09:49 CEST] <JEEB> yeah
[22:09:51 CEST] <nevcairiel> wtf
[22:09:51 CEST] <JEEB> lol
[22:09:53 CEST] <nevcairiel> how did that happen
[22:09:56 CEST] <nevcairiel> fucking make
[22:10:06 CEST] Action: nevcairiel cleans
[22:10:33 CEST] <nevcairiel> make still randomly barfs up on windows when using high concurrency (-j12 or such)
[22:12:56 CEST] <jamrial> on windows, make might fail running strip on any of the binaries if i also have the build folder open in windows explorer, with an error about lacking permision to rename files or some such
[22:13:18 CEST] <nevcairiel> ...and then replace ffmpeg.exe by ffprobe?
[22:13:30 CEST] <jamrial> no, that never happened to me :p
[22:14:14 CEST] <nevcairiel> anyway encoding with ffmpeg nvenc works
[22:14:18 CEST] <nevcairiel> must just be obs being fucked
[22:16:27 CEST] <BBB> kurosu_: you can try android cross-compiler
[22:16:35 CEST] <BBB> kurosu_: (for arm/neon compiles)
[22:33:32 CEST] <cone-099> ffmpeg 03Paul B Mahol 07master:f5afd1c738d4: configure: check rubberband version, allow only latest one
[00:00:00 CEST] --- Fri Oct  2 2015