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

[burek]

[00:42:02 CET] <kierank> J_Darnley: I guess if BBB or Gramner don't object to your h264 patch you should push it
[01:24:16 CET] <kierank> one for the cosmetic lawyers, does GBRAP12 go with GBRP12 in swscale or GBRAP16?
[01:25:42 CET] <cone-089> ffmpeg 03Michael Niedermayer 07master:1693336aed39: avfilter/af_apulsator: assert that pathes leaving uninitialized variables do not occur
[01:25:42 CET] <cone-089> ffmpeg 03Eran Kornblau 07master:1bbfaba196b3: avformat/mov: dont print frma warning when format is the same
[01:25:42 CET] <cone-089> ffmpeg 03Trevor \\\\ Higgins 07master:6632802aa00c: x11grab: fixed next frame capture time calculation
[01:28:37 CET] <atomnuker> kierank: the latter
[01:28:58 CET] <kierank> bugger
[01:30:04 CET] <atomnuker> then again I'm not an !%34%4()#3 expert, but makes more sense to bundle formats with the same #planes together
[01:50:05 CET] <Timothy_Gu> I'm beginning to suspect that reindl guy has some problems...
[01:52:56 CET] <kierank> llogan: can we stop that discussion
[01:54:00 CET] <llogan> kierank: i don't think any got passed the regex filter since i added it
[01:54:06 CET] <kierank> ok thanks
[01:54:15 CET] <llogan> should have done it earlier...
[01:55:20 CET] <llogan> Timothy_Gu: yeah. anger. he makes the list a bad experience.
[02:14:22 CET] <Timothy_Gu> alright. proposal to remove the old fate & request for root sent. 
[08:35:51 CET] <kierank> michaelni: so, how do I make fate pass?
[08:49:28 CET] <nevcairiel> you hammer it until succcess falls out
[08:53:02 CET] <nevcairiel> kierank: looks like you should only flag input support for the time being in swscale, its probably trying to convert to gbrap12 which isnt implemented
[12:45:50 CET] <durandal_170> can I get comments?
[12:50:16 CET] <wm4> on what
[12:56:07 CET] <durandal_170> wm4: on luascript
[13:33:58 CET] Action: J_Darnley curses his ISP
[13:34:22 CET] <J_Darnley> durandal_170: I'm reading your luafilter right now.
[14:03:26 CET] <J_Darnley> durandal_170: can you explain how to use the filter?
[14:08:56 CET] <J_Darnley> I'm going to email.
[15:08:06 CET] <rcombs> jkqxz: your VAAPI patches don't build if X11 isn't present
[15:08:51 CET] <rcombs> you've got a `Display*` declared without a `HAVE_VAAPI_X11` guard, and also include va/va_x11.h unconditionally
[15:12:12 CET] <BtbN> I wouldn't even bother with X11 for VAAPI. It works just fine via DRM
[15:18:18 CET] <wm4> BtbN: in theory you can use some other vaapi drivers than intel's with x11
[15:18:29 CET] <wm4> but it's probably not worth the trouble
[15:18:51 CET] <BtbN> I think the native mesa ones also work with drm
[15:19:00 CET] <BtbN> and the vdpau wrapper is dead anyway
[15:19:07 CET] <cone-122> ffmpeg 03James Almer 07master:16af350ac5b1: avcodec/dcadsp: replace intptr_t with ptrdiff_t
[15:24:15 CET] <J_Darnley> durandal_170: were you able to successfully encode the output of your script?
[15:24:41 CET] <J_Darnley> libx264 complains that the width (640) is greater than the stride (0)
[15:25:21 CET] <J_Darnley> And other encoders just segfault
[15:26:20 CET] <Daemon404> well... 0 stride is not exactly vaid
[15:26:21 CET] <Daemon404> valid
[15:26:41 CET] <J_Darnley> I did wonder(!)
[15:26:47 CET] <J_Darnley> Also, I'm going to send you a diff to get the AV_LOG constants in the environment.  (I'm sick of the fatal colors)
[15:44:48 CET] <cone-122> ffmpeg 03Mats Peterson 07master:9556446623d6: lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut
[15:55:20 CET] <durandal_170> J_Darnley: query_formats is wrong, you need to use format filter after lua one, ...
[16:03:03 CET] <J_Darnley> Ah.  Sure
[16:24:16 CET] <J_Darnley> Good job avfilter!  A fiter can return an error and you will just blindly continue and let ffmpeg say everything was successful!
[16:24:58 CET] <wm4> trollol
[16:25:15 CET] <wm4> but maybe ffmpeg.c is ignoring one of the many return values?
[16:26:02 CET] <J_Darnley> Perhaps to ffmpeg it isn't an error.  It managed to connect one testsrc input to format which did run sicessfully.
[16:26:14 CET] <J_Darnley> *sucessfully
[16:27:52 CET] <jkqxz> You want VAAPI/X11 if you're thinking of magic around picking DRM surfaces out of the X server.
[16:29:49 CET] <jkqxz> rcombs:  Thanks for noticing that; I will fix it.
[16:30:10 CET] <Gramner> kierank: assuming if it works, yeah I guess.
[16:30:14 CET] <rcombs> cool
[16:30:38 CET] <kierank> J_Darnley: ping
[16:31:24 CET] <J_Darnley> pong
[16:33:30 CET] <J_Darnley> kierank: pong
[16:37:01 CET] <J_Darnley> If it is about the h264 assembly then I'll ping my message on the ML.
[16:38:14 CET] <kierank> Gramner says you can push it
[16:38:26 CET] <J_Darnley> ah okay
[16:38:58 CET] <J_Darnley> Tell him thanks.
[16:39:05 CET] <Gramner> I'm here you know
[16:39:16 CET] <J_Darnley> Then thank you.
[16:39:22 CET] <Gramner> and yes, go ahead and push assuming that it works
[16:39:36 CET] <J_Darnley> (Did I not say that it does pass fate?)
[16:40:20 CET] <Gramner> no, I don't think you did. at least not in the most recent version
[16:51:58 CET] <J_Darnley> durandal_170: yay! successful output!
[17:12:52 CET] <wm4> durandal_170: so why can't there be something like sub-graphs, instead of shuffling the data manually between 2 graphs?
[17:14:40 CET] <durandal_170> wm4: what filter?
[17:16:52 CET] <wm4> lua and conditional
[17:24:49 CET] <durandal_170> wm4: subgraphs? how would it work?
[17:34:40 CET] <cone-122> ffmpeg 03James Darnley 07master:7042a55c55d7: avcodec/h264: mmxext 4:2:2 chroma deblock/loop filter
[17:36:02 CET] <wm4> durandal_170: don't know, it'd somehow directly access the filters, instead of going over buffersink/src, but I don't know if this is possible at all
[17:39:50 CET] <atomnuker> J_Darnley: mmxext? isn't that pretty much ancient at this point?
[17:40:09 CET] <J_Darnley> Yes but the 420 one is still only mmxext
[17:40:18 CET] <nevcairiel> atomnuker: some data is just too small to realistically use more than 64-bit at a time
[17:42:16 CET] <atomnuker> nice to know mmx still has its place
[17:42:36 CET] <drv> emms will live forever
[17:43:28 CET] <J_Darnley> I'm sure many of these older DSP functions could be updated to use sse2 and avx but I doubt they will get much faster.
[17:43:43 CET] <J_Darnley> You just need to check how much data they're writing.
[17:45:23 CET] <Gramner> starting with skylake mmx is actually slower than sse for certain instructions though
[17:45:26 CET] <J_Darnley> I guess you also need to check what loads are being done to prevent tracking down assembler errors later.
[17:46:31 CET] <Gramner> i'm not sure if they're intentionally making mmx worse just to get people away from it or it there's a legit reason for it being slower
[17:47:42 CET] <J_Darnley> There are a few macros hiding places where 3-op instructions could be used.
[17:47:51 CET] <wm4> they're probably moving it from hardcoded logic to microcode or something to free up space for useless avx512?
[17:48:21 CET] <Gramner> it's not microcode. microcode is really slow - it's not that slow
[17:50:28 CET] <Gramner> asl avx-512 isn't useless. it's just that there's diminishing returns for increasing vector sizes
[17:51:14 CET] <J_Darnley> Just wait for the fabled 64x64 blocks I heard about at FOSDEM.
[17:54:01 CET] <Gramner> need to go above and beyond! at least 4096x4096 px blocks because larger numbers are better
[17:54:21 CET] <kierank> J_Darnley: you were there for that?
[17:54:35 CET] <kierank> ninja
[17:54:45 CET] <J_Darnley> Yes.  I was hiding in many of the open media talks
[17:54:58 CET] <J_Darnley> I missed your camera one though.
[17:55:06 CET] <J_Darnley> The room was full when I got back to it
[17:58:52 CET] <jamrial> and avx512 with the VL extension will make it interesting to rewrite some 16/32 byte wide functions thanks to the new instructions
[17:59:05 CET] <jamrial> like that pshufb on steroids one
[18:00:04 CET] <nevcairiel> will only be interesting if those migrate into mainstream hardware
[18:01:11 CET] <jamrial> well, VL and a couple other extensions are going to be introduced with the first avx512skylake xeon
[18:01:16 CET] <nevcairiel> you can also use 32 xmm registers using those instructions, so... maybe some very complex things can benefit =p
[18:01:27 CET] <Gramner> vpermi2b is avx512vbmi
[18:01:30 CET] <jamrial> hopefully kabylake/cannonlake introduces avx512 on desktop
[18:01:34 CET] <jamrial> oh
[18:01:36 CET] <Gramner> which is not part of skx
[18:01:46 CET] <Gramner> it's cl afaik
[18:01:49 CET] <Gramner> cnl*
[18:01:51 CET] <nevcairiel> thats cannonlake, yes
[18:01:52 CET] <jamrial> i thought it was BW
[18:01:55 CET] <jamrial> ah well
[18:02:03 CET] <atomnuker> considering how long avx2 took I wouldn't bet on avx512 in kabylake
[18:02:13 CET] <Gramner> kbl wont have avx-512, no
[18:02:21 CET] <nevcairiel> kabylake sounds more like a minor refresh, no big feature changes
[18:02:28 CET] <jamrial> so no avx512 on desktop until cannonlake?
[18:02:39 CET] <Gramner> on desktop cnl is the first µarch with avx-512
[18:02:57 CET] <nevcairiel> and that is still hoping, or did they confirm that officially?
[18:03:16 CET] <Gramner> it's as confirmed it's going to get
[18:03:39 CET] <jrosser> cineform and dirac would benefit from wider instructions, probably
[18:04:07 CET] <Gramner> I'm going by what intel's SDE supports when emulating various µarchs, and that's usually accurate so
[18:04:07 CET] <jrosser> where the transform size is not the same as the bitstream slice size
[18:04:09 CET] <nevcairiel> i hope their mainstream line also gets more than 4 cores then, waiting for the -E line would be another year at least
[18:04:43 CET] <nevcairiel> or they give Skylake-E avx512
[18:04:44 CET] <Gramner> skylake-E is like Q3'17 or something like that
[18:05:18 CET] <Gramner> skylake-e should have avx-512, yes, considering the -E series are basically rebranded xeons
[18:05:47 CET] <nevcairiel> intels timeline has shifted quite a bit over the last year, if skylake-E is only going to come out in Q3'17, then its two generations behind the mainstream at that point
[18:05:51 CET] <Gramner> but CNL should also be out at around the same time as Skylake-E
[18:06:57 CET] <nevcairiel> hence h oping that CNL gets at least a 6 core option
[18:07:51 CET] <Gramner> it's possible at least. considering that they're running out of things to improve aside from the iGPU increasing core count would be a good way of getting people to upgrade
[18:07:52 CET] <nevcairiel> I dont need the other "advantages" of the -E platform, I mostly wanted more cores
[18:08:29 CET] <kierank> jrosser: tried the Xeon-D platform?
[18:08:43 CET] <kierank> quite a lot of cores for 45W
[18:09:10 CET] <jrosser> i was looking today actually
[18:09:16 CET] <Gramner> i should get a dual socket xeon just to compile stuff faster
[18:09:20 CET] <jrosser> you have the supermicro stuff?
[18:09:27 CET] <nevcairiel> personally while I like more cores, for my desktop usage I also like some remnant of single-threaded performance =p
[18:09:35 CET] <kierank> jrosser: not yet, plan to get one soon
[18:09:46 CET] <wm4> nevcairiel: you still don't want to push your main 10 patch?
[18:09:57 CET] <jrosser> there was an amazing mini itx board with 2x 10gig
[18:10:13 CET] <kierank> yeah
[18:11:04 CET] <rcombs> jkqxz: also, you should probably do something to autodetect when `-ldrm` and/or `-ldrm_intel` are required
[18:11:05 CET] <nevcairiel> wm4: maybe on the weekend
[18:12:01 CET] <kierank> jrosser: http://www.supermicro.nl/products/system/1U/5018/SYS-5018D-FN4T.cfm
[18:12:05 CET] <kierank> not clear what chipset on the 10gig
[18:12:31 CET] <jrosser> its on the cpu isnt it?
[18:12:39 CET] <jrosser> but isw
[18:12:42 CET] <jrosser> ym
[18:17:28 CET] <jamrial> wow, dcadec's lfe_fir_float_c compiled on x86_32 is two times slower when gcc uses x87 fp math compared to -mfpmath=sse
[18:18:10 CET] <kierank> yeah x87 sucks
[18:19:57 CET] <Gramner> good thing there's literally no reason to x87 nowadays aside from some argument passing stuff in 32-bit x86 as required by the ABI
[18:21:54 CET] <jamrial> default x86_32 builds use x87. not even choosing an specific cpu during configure changes that it seems. you need to pass -mfpmath=sse to extra-cflags
[18:21:58 CET] <Gramner> -mfpath=sse -msse -msse2 ought to be the default in gcc
[18:22:11 CET] <Daemon404> it is in clang iirc
[18:22:25 CET] <Gramner> it is in msvc and icl at least
[18:22:37 CET] <Gramner> or well, the corresponding options
[18:24:32 CET] <jamrial> two years ago there was an user that was still rocking an Athlon thunderbird to play one of those dvd resolution bdrips with dts audio and reported a crash that ended up being a misplaced sse2 instruction
[18:25:14 CET] <jamrial> or was it an Athlon xp, not sure. still, no sse2 and of course x86_32
[18:25:57 CET] <Gramner> I mean, SSE has been available since -99 and SSE2 since -00? if someone's still using a such an ancient CPU I feel that "go buy a new computer" is a perfectly justifiable answer
[18:26:09 CET] <jamrial> heh
[18:26:23 CET] <wm4> <Gramner> good thing there's literally no reason to x87 nowadays aside from some argument passing stuff in 32-bit x86 as required by the ABI <- what about 80 bit floats
[18:26:52 CET] <Gramner> we don't pretend that those exists
[18:33:25 CET] <jkqxz> rcombs:  Are those only relevant for static linking?  (libva wants to depend on them?)  I haven't run into that at all.
[18:33:57 CET] <rcombs> probably, yeah
[18:34:49 CET] <rcombs> jkqxz: also usually you could rely on pkgconfig for this but I checked and the relevant pkgconfig scripts are extremely lacking
[18:35:24 CET] <rcombs> (they don't declare those dependencies like they should)
[18:47:00 CET] <durandal_170> michaelni: is FFmpeg going to candidate for this year GSoC?
[18:49:01 CET] <jkqxz> The whole thing isn't really amenable to static linking anyway given that different parts have to dlopen() each other.  Tempting to just ignore this problem for ffmpeg, and users can sort it themselves for lav*.
[18:53:16 CET] <wm4> since libva is just a dlopen wrapper, static linking really won't work?
[18:55:24 CET] <jkqxz> Well, it can "work" (that is, link and run).  But it will still have runtime dependencies on shared libraries, which is probably exactly what the user didn't want.
[19:02:02 CET] <durandal_170> I'm paying to port mvtools...
[19:07:37 CET] <durandal_170> michaelni: there are open tickets requesting for sponsor's, can't ffmpeg spend money on such tickets?
[19:26:16 CET] <Timothy_Gu> J_Darnley: seems like your h264 patch broke something: http://fatebeta.ffmpeg.org/report/x86_32-msvc14-dll-windows-native/20160205165837#failed_tests
[19:26:53 CET] <J_Darnley> Oh no
[19:32:22 CET] <J_Darnley> hm x86_32 msvc
[19:35:49 CET] <J_Darnley> I should have pushed a few minutes earlier then other ones would have tested it too.
[19:56:59 CET] <Gramner> hmm, the H.264 deblock strides are int, not ptrdiff_t. but that shouldn't break on 32-bit
[19:57:26 CET] <Gramner> should be changed before something breaks on 64-bit though
[20:08:59 CET] <BBB> jamrial: I really dont like the define m8 m0 etc. in that patch
[20:09:12 CET] <BBB> jamrial: since it only seems to be used in one block and thus will be confusing for people following register data flow
[20:09:36 CET] <BBB> jamrial: can you just make that one block use if 64 { if fma3 .. else .. } else .. ?
[20:16:32 CET] <durandal_170> fine to push streamselect?
[20:16:50 CET] <durandal_170> ^ubitux
[20:17:19 CET] <jamrial> BBB: sure, but it will be even uglier than it already is :p
[20:17:43 CET] <durandal_170> ubitux: also nlmeans
[20:19:10 CET] <BBB> jamrial: ugly but easier to understand, or uglier and more difficult to understand?
[20:22:29 CET] <BBB> J_Darnley: on x86-32, the stack alignment is different, youre probably movaing from/to buf0/1
[20:22:33 CET] <BBB> J_Darnley: you cant do that on x86-32
[20:24:22 CET] <BBB> ah its even better
[20:24:37 CET] <BBB> J_Darnley: the problem is that youre assigning r0m/r2m and using them in the actual assembly code
[20:24:46 CET] <BBB> J_Darnley: that cant be done if youre omitting the stack pointer (negative stack size)
[20:25:01 CET] <BBB> J_Darnley: negative stack size means no stack pointer means you cannot, repeat, CAN NOT, use r0m/r2m anywhere in your code
[20:25:34 CET] <BBB> Id use a positive stack size and just deal with the fact that it needs a stack pointer on x86-32, that should be ok
[20:25:48 CET] <BBB> its only x86-32 msvc that suffers anyway :)
[20:26:09 CET] <BBB> cglobal deblock_h_chroma422_8, 5, 6, 0, 0-(1+ARCH_X86_64*2)*mmsize -> cglobal deblock_h_chroma422_8, 5, 6, 0, 0+(1+ARCH_X86_64*2)*mmsize
[20:27:04 CET] <Gramner> ah yes, the wonders of having an unaligned stack. having buf0/1 unaligned is fine though (except for some performance hit, but whatever) since this is mmx
[20:28:18 CET] <Gramner> don't think the 0+ is required though, the reason for using 0- is because yasm doesn't consider negative numbers to be numbers.
[20:28:27 CET] <kierank> J_Darnley: just make it an x86-64 function =p
[20:29:16 CET] <Gramner> I fixed that yasm problem in https://github.com/yasm/yasm/commit/32ad9c46cebd5bf07af9c05383d3c16e6cb1f17d btw, but the fix is not in any released version
[20:32:07 CET] <jamrial> BBB: found a way to make it less ugly and easier to understand, so neither
[20:32:21 CET] Action: J_Darnley can never focus on anything in this place in the evening
[20:32:59 CET] <BBB> Gramner: nah, the isnumber is not the issue, it has to be positive, not negative
[20:33:12 CET] <BBB> Gramner: if you use the stack arguments (r%dm), you need a stack pointer
[20:33:18 CET] <BBB> Gramner: i.e. positive stack size
[20:33:28 CET] <BBB> Gramner: negative stack size is only ok if you dont use stack arguments (r%dm)
[20:34:11 CET] <Gramner> yes, I knows. I referred to the fact that you need to write negative numbers as 0-x in yasm instead of -x
[20:34:32 CET] <J_Darnley> How can you not have a stack pointer?
[20:35:03 CET] Action: J_Darnley has too many windows open again
[20:35:39 CET] <BBB> imagine that your rsp is A, and you want N bytes of 16-byte aligned memory, and we dont have aligned stack
[20:36:00 CET] <Gramner> rNm is an alias for [rsp+<some_value], so it doesn't work if you modify rsp in a way that isn't known at compile-time
[20:36:12 CET] <BBB> save rsp to [rsp+sz]
[20:36:21 CET] <BBB> then you can restore the pre-aligned stack by mov rsp, [rsp+sz]
[20:36:29 CET] <BBB> but you cant have r%dm
[20:36:34 CET] <J_Darnley> FUCK CYGWIN!  STOP FAILING TO FORK!
[20:36:44 CET] <BBB> if you want r%dm, simple save rsp pre-align to a register and call that the stack pointer
[20:36:47 CET] <BBB> now r%dm works
[20:37:02 CET] <BBB> and Im sorry that youre forced to use cygwin :D
[20:37:29 CET] <J_Darnley> I don't need or want to align.
[20:37:42 CET] <J_Darnley> I thought that was the whole point of overloading the value with negative numbers.
[20:38:08 CET] <Gramner> using negative numbers mean that you store the original stack pointer on the stack instead of in a register
[20:38:39 CET] <BBB> if you dont want to align, just sub rsp manually
[20:38:41 CET] <J_Darnley> Revert if you want.  I'm going off to reboot.
[20:38:49 CET] <BBB> :D
[20:39:04 CET] <BBB> Id just sub manually in his cse
[20:39:07 CET] <BBB> he doesnt need alignment
[20:39:30 CET] <BBB> SUB and ADD, right?
[20:39:33 CET] <jamrial> other similar functions in that same file do that, yeah
[20:39:48 CET] <BBB> yeah so lets use SUB/ADD then
[20:39:56 CET] <BBB> instead of the complex stuff he doesnt want
[20:43:26 CET] <Gramner> will you send a patch or should I?
[21:00:35 CET] <BBB> can you?
[21:00:37 CET] <BBB> Im lazy :-p
[21:00:44 CET] <Gramner> sure
[21:01:30 CET] <Gramner> I ok:ed the patch so it's kind of my fault
[21:04:14 CET] <BBB> jamrial: lfe patch is ok like this, ty
[21:14:26 CET] <cone-122> ffmpeg 03Paul B Mahol 07master:b1fe794033c8: avfilter/split: support any channel count for asplit filter
[21:18:55 CET] <J_Darnley> Now where was I?  Oh yes.  My bad code.
[21:19:12 CET] <Gramner> J_Darnley: I'll send a patch in a few seconds
[21:21:20 CET] <Gramner> sent
[21:22:27 CET] <JEEB> J_Darnley: btw in cygwin I fixed forking failures by switching to 64bit cygwin on win8+. not sure why exactly it's working better for me, though :D
[21:22:35 CET] <J_Darnley> I am on 64 bit
[21:22:41 CET] <JEEB> oh well
[21:22:44 CET] Action: JEEB pats J_Darnley 
[21:23:01 CET] <J_Darnley> I must remain calm.
[21:23:28 CET] <drv> i think the cygwin fork failures are usually because some DLL gets loaded in the way of some existing address space
[21:23:42 CET] <J_Darnley> I already know about the BLODA
[21:23:51 CET] <J_Darnley> I don't think I have any instaled
[21:24:23 CET] <J_Darnley> The fork failure is intermittent
[21:25:33 CET] <J_Darnley> It only occurs, or occurs more often, if I have a lot of windows open and/or a lot of cygwin programs running or suspended.
[21:27:12 CET] <J_Darnley> Unfortunately that is usually when I am in the middle of doing things.
[21:27:31 CET] <Gramner> somewhat related, my steelseries mouse driver crashes every time I do something that results in heavy cpu usage in msys.
[21:28:02 CET] <Gramner> I have absolutely no idea how those two things are related. high cpu usage outside of msys is perfectly fine
[21:28:23 CET] <J_Darnley> :D
[21:39:37 CET] <cone-122> ffmpeg 03Marton Balint 07master:7e6b788f7c4d: lavf/asfenc: add AVClass to context
[21:39:37 CET] <cone-122> ffmpeg 03Marton Balint 07master:046476730102: lavf/asfenc: check the number of streams in header
[21:39:38 CET] <cone-122> ffmpeg 03Marton Balint 07master:79e42936137a: lavf/asfenc: add support for storing languages
[21:39:40 CET] <cone-122> ffmpeg 03Marton Balint 07master:22bbd6e8b754: lavf/asfenc: add support for storing creation time
[21:39:40 CET] <cone-122> ffmpeg 03Marton Balint 07master:6d14e32555ef: lavf/asfenc: add support for setting packet size
[21:40:22 CET] <J_Darnley> kierank: before I ragequit earlier you mentioned writing simd for another codec.  which one was what?  cineform?  c-something.
[21:41:20 CET] <kierank> Dirac Encoder?
[21:41:37 CET] <J_Darnley> Oh d-something then.
[22:00:53 CET] <BBB> Gramner: ty for the patch
[22:02:42 CET] <cone-122> ffmpeg 03Henrik Gramner 07master:aa751573fef5: avcodec/h264: Fix segfault in 4:2:2 chroma deblock with 32-bit msvc
[23:07:35 CET] <kierank> could someone test this on fate
[23:07:36 CET] <kierank> http://paste.ubuntu.com/14897412/
[23:07:41 CET] <kierank> I lack the ability to do that currently
[23:10:29 CET] <durandal_170> you need to update fate refs also you nowhere extract alpha IIRC
[23:12:13 CET] <kierank> but gbrap16 doesn't either?
[23:18:36 CET] <michaelni> durandal_170, ffmpeg will candidate for GSoC if someone submits it to google fills out the forms and volunteers as admin, i think someone should do this. I do voluneer as backup admin if there are 1-2 other admins who are wiling to do a significant part of the work
[23:19:52 CET] <durandal_170> michaelni: what's all needed?
[23:20:24 CET] <michaelni> also if someone does the submit thing then ask me/saste/reynaldo for the list of awnsers used previously, it likely can be reused to a large extend
[23:21:38 CET] <michaelni> i dont know whats needed for this year, last time it was filling out some forms, making sure the wiki page is in shape before the deadline as google checks it, find people to volunteer for mentoring
[23:22:56 CET] <Gramner> https://msdn.microsoft.com/en-us/library/mt240585.aspx why microsoft? their way of doing 4:4:4 H.264 is apparently to split a 4:4:4 stream into two 4:2:0 streams and then recombining them again in the decoder
[23:23:36 CET] <michaelni> also about the previous awnsers iam not sure where i put them maybe reynaldo or saste remember/have them
[23:23:58 CET] <Gramner> why use standardized 4:4:4 mode of H.264 when you can do some crazy hacks instead?
[23:26:55 CET] <wm4> Gramner: lol
[23:32:25 CET] <durandal_170> michaelni: do I need prove me is me, sign up forms, etc...
[23:32:30 CET] <Gramner> at least they finally realized that encoding the screen as a video stream is way superior to the existing remote desktop protocol. might be able to get more than 0.5 fps over slow connections with the new rdp version
[00:00:00 CET] --- Sat Feb  6 2016