[00:32] <cone-376> ffmpeg.git 03Diego Biurrun 07master:a63ac1106d2e: build: Do not redundantly specifiy H.263-related object files for MSMPEG4v* [00:32] <cone-376> ffmpeg.git 03Michael Niedermayer 07master:c4c5351f0857: Merge remote-tracking branch 'qatar/master' [03:32] <cone-376> ffmpeg.git 03Michael Niedermayer 07master:b5005def8a8f: avcodec/h264: avoid using lost frames as references [05:06] <Zeranoe> Looks like there might be a bug in 2.1.4: http://paste.debian.net/84274/ [05:10] <Zeranoe> Looks like it's vidstab related [05:16] <Zeranoe> Fixed, I just saw https://trac.ffmpeg.org/ticket/3296 [08:08] <cone-763> ffmpeg.git 03Michael Niedermayer 07master:64bb64f704f7: avcodec/h264: fix droped frame handling also for threads > 1 [09:35] <ubitux> OperationalError: database is locked [09:35] <ubitux> *RAGE* [10:48] <cone-763> ffmpeg.git 03Anton Khirnov 07master:291e49d4e7db: af_compand: add a dependency on strtok_r [10:48] <cone-763> ffmpeg.git 03Michael Niedermayer 07master:33a2b45c2e18: Merge remote-tracking branch 'qatar/master' [11:56] <cone-763> ffmpeg.git 03Michael Niedermayer 07master:649686d89bfa: avcodec/h264_refs: remove lost frames instead of disfavoring them [11:57] <ubitux> ah, trac repaired [11:57] <nevcairiel> sounds more like an issue that fixes itself briefly and then re-occurs a day later [11:58] <ubitux> :( [12:06] <b_jonas> (stupid bug came back) [14:14] <ubitux> michaelni: i think that's better if we keep the av_strtok code [14:14] <ubitux> libav is replacing the strtok_r with av_get_token but i don't think that's a good idea to follow that [14:16] <ubitux> also, about the incoming frei0r crash fix, iirc i fixed that problem already [14:16] <ubitux> not sure if it's done the same, but you probably want to be careful about it when merging [14:18] <ubitux> it seems libav is going to not tolerate unset parameters [14:18] <ubitux> if you prefer that version, you could revert e85ea7d387a34328c44a2e06c7098ffca341e310 [14:18] <ubitux> but i think it's ok not to have mandatory parameters [14:19] <ubitux> iirc this crash was actually a regression, and it was tolerated originally, but i might be wrong [14:22] <funman> http://pastebin.com/39c1qpeb (backtrace from vlc) [14:28] <ubitux> funman: can we reproduce with ffmpeg? [14:30] <ubitux> funman: like maybe ffmpeg -f alsa -i hw:0,0 -ar 44100 -ac 1 -b:a 128k out.mp3 or something? [15:00] <plepere> ubitux : in VP9, the 2D 8-tap filter is only done by doing 2 successive 1D filters. is it not possible to blend them in a single function / loop ? [15:02] <ubitux> plepere: BBB wrote those filters so i don't know [15:02] <plepere> ok thanks. :) [15:03] <plepere> I'll try doing it here. :) [15:06] <ubitux> are you sure it's actually done by 2 successives 1d? [15:06] <plepere> in vp9dsp_init it's like that at least [15:07] <plepere> its 1D into a temp then 1D again [15:07] <ubitux> vp9dsp_init? [15:07] <plepere> yes [15:08] <plepere> line 97 [15:10] <ubitux> i guess we could save the 2 calls yes [15:10] <ubitux> not sure about the impact on code size [15:11] <plepere> well it's to save a loop and memory impacts [15:32] <kurosu_> plepere: btw I think I've seen your MC code unpacking coefficients everytime the code is run [15:32] <kurosu_> typically, asm code uses separate, unpacked arrays [15:33] <plepere> kurosu_, you'd rather have a table with already unpacked filter coefficients ? [15:33] <kurosu_> as said, this could save you regs for when you need them (x86_32) - and sometimes loading them into xmm7-15 is not a win [15:33] <kurosu_> plepere: yes, almost every other codec asm does that [15:33] <kurosu_> I don't know for vp9 as there are different interpolation filters [15:33] <plepere> ok [15:33] <kurosu_> (bilinear and 2 kinds of 8 taps?) [15:34] <plepere> bilinear can have 2 different filters, yes [15:34] <plepere> it's too easy otherwise. :) [15:34] <kurosu_> I have copied vp8dsp for rv40dsp to great success [15:34] <kurosu_> (and for great justice, too) [15:35] <plepere> I'll do asm filter tables to avoid the unpacks [15:35] <kurosu_> typically, the coeffs are interleaved because you are going to use pmaddusb or pmaddwd (or whatever the insn names are) [15:36] <plepere> yes [15:36] <plepere> so are the loads [15:37] <plepere> well I'm working on the 4-tap bilinear. [15:37] <plepere> the unrolling part. [15:37] <plepere> it's easy up to 8, but it's less obvious afterwards. (AVX2 is going to be so liberating) [15:39] <kurosu_> 4 taps bilinear? you mean 2 taps vertical and 2 tap horizonta? Because 4 taps doesn't sound like a bilinear 1D kernel [15:41] <kurosu_> (might be lanczos2 for instance) [15:42] <plepere> talking about 4tap h + 4-tab V [15:42] <plepere> epel hv [15:43] <kurosu_> ok, so it's not bilinear but dctif4 [15:43] <plepere> I must understand dct wrong then. :/ [15:44] <plepere> and I'm most likely using "bilinear" wrong too [15:45] <kurosu_> bilinear by definition is a 4-taps 2D filters or 2 1D 2-tap filters if separable [15:45] <kurosu_> dctif4 is a 4-taps 1D filter, as a result of a separable 2D filter [15:46] <kurosu_> dcitf4 is for hevc chroma, dcitf8 si for hevc luma [15:46] <kurosu_> vp9 uses an actual bilinear 2taps 1D filter afaik [15:47] <kurosu_> s/uses/may use/ [15:47] <BtbN> What does it mean when avcodec_decode_audio4 return with -22? [15:48] <BtbN> The same happens with avcodec_decode_video2. I'm migrating the application from an older ffmpeg version [15:49] <BtbN> It most likely refers to EINVAL, but i don't know what it's trying to tell me with it [15:49] <kurosu_> plepere: anyway, "A rose by any other name would smell as sweet" so it's quite a smaller deal that my lengthy explanations make it to be [16:01] <Misiek> can I set what IP does ffmpeg use to connect to input? [16:10] <plepere> BBB : I'm unrolling all of my stuff, but I'm not sure I've got significant speed-ups. :/ [16:11] <plepere> I think that once I'm past 8 or 16, since I need to repeat the loads and all, I'm going to have significant changes only if I start using AVX2 (halving the number of instructions) [16:17] <mateo`> slomo: Hello, would implementing a deinterlace interface would be something that makes sense ? [16:17] <mateo`> /implementing/adding [16:18] <mateo`> oups sorry for the noise, wrong chan :( [16:18] <ubitux> hello slomo, i don't know who or where you are, but welcome [16:48] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:622d24e4ebde: avformat/mov: simplify code setting needs_parsing [16:48] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:4f4cc43fd851: avcodec/h264: allow mixing idr and non idr slices with frame threading again [16:48] <Daemon404> 1/g 50 [16:49] <ubitux> michaelni: thx! [16:50] <nevcairiel> sounds like all the regressions are being fixed. i shall update thr version of avcodec i use :) [16:51] <ubitux> http://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~regression&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&order=priority [16:52] <ubitux> i see #3260 in regressions related to h264 [16:53] <ubitux> maybe #3326 [16:53] <nevcairiel> oh i fixed that manually by simply not using the J pix fmts, so no reinit when only range flag changes [16:53] <nevcairiel> die J formats, die! [16:53] <Daemon404> dont you still need it for some ops/ [16:54] <Daemon404> and some decoders output it [16:54] <nevcairiel> my code doesn't need them [16:54] <nevcairiel> local patch ahoy [16:54] <Daemon404> evil [16:54] <nevcairiel> i have like 100 patches [16:55] <nevcairiel> maybe less now, got rid of a few recently [16:56] <Daemon404> i feel like a lot of those could be squashed, or upstramed [16:56] <Daemon404> 10 of tem are "do x to haali" [16:56] <Daemon404> s/10/like 10/ [16:56] <nevcairiel> yeah probably morr [16:57] <nevcairiel> liked to keep a bit of history there [16:58] <nevcairiel> i upstreamed a bunch of dxva fixes recently. but already collected a few new ones... [17:04] <Compn> j formats , forever [17:05] <Compn> how else are we going to let users convert videos with incorrect luma ? [17:08] <nevcairiel> let them set color_range? [17:09] <JEEB> or more like, have swscale look at the color_range tag :P [17:09] <JEEB> because currently it only converts if the pix_fmt is not the same [18:30] <Daemon404> ... [18:30] <Daemon404> carl you fucktard [18:30] <JEEBsv> :D [18:33] <Daemon404> even if it is cymk, its n being detected as such [18:33] <Compn> Daemon404 : so just upload it to 2799 [18:33] <Compn> dont cause troubles :P [18:35] <Daemon404> its not the same bg [18:35] <Daemon404> or problem [18:35] <Daemon404> see my recent comment [18:35] <Daemon404> carl just doesnt fucking anayze anything properly [18:36] <Compn> [mjpeg @ 00ee4934]Unhandled pixel format 0x11111111 [18:36] <Daemon404> see my comment [18:36] <Daemon404> read it [18:36] <Daemon404> like [18:36] <Daemon404> in english [18:36] <Compn> i know [18:36] <Compn> i'm just bugging you :) [18:36] <Compn> trying to get it working in mplayer... [18:37] <Compn> libjpeg fails [18:37] <Daemon404> in mplayer. [18:37] <Compn> in mplayer [18:37] <Daemon404> yes [18:37] <Compn> yes [18:37] <Daemon404> because mplayer doesnt have cmyk [18:38] <Daemon404> the issue is that it isnt being detected as cmyk [18:38] <Daemon404> its being detected as yuva444p [18:38] <Daemon404> and ths producing broken output [18:38] <Daemon404> instead of porperly failing [18:38] <Compn> ok then title bug is wrong [18:38] <Daemon404> yes [18:38] <Daemon404> il lfix [18:38] <Compn> 'cymk misdetected ' [18:39] Action: iive tales more popcorn [18:39] <iive> takes :/ [18:39] <Compn> maybe carl could stop closing Daemon404's bugs, i think that would help :P [18:39] Action: Compn waves to carl [18:39] <Daemon404> iive, its no secret i dont liek carl [18:39] <Daemon404> and his terribl hacks [18:39] <Daemon404> and most of all hs hypocrisy re: patch formatting [18:40] Action: Daemon404 is not the only one [18:40] <iive> tell me more... [18:40] Action: Daemon404 invokes poe's law on that last statement [18:41] <wm4> fun [18:41] <Compn> cmyk misdetected as yuva444p sounds easier to understand, whatever. [18:41] <Daemon404> fails to fail is more fun [18:41] <Daemon404> and more broken english-y [18:42] <Daemon404> suits ffmpeg better [18:42] <Compn> lol [18:45] <Compn> Daemon404 : do you have any trouble on libav bugtracker ? [18:45] <Daemon404> yes [18:45] <Daemon404> because filing bugs on it is useless [18:45] <Daemon404> its like throwing them into a pit [18:45] <Compn> bugzilla tends to do that [18:45] <wm4> yeah, they don't care about the bug tracker [18:45] <Compn> no one likes bugzilla :P [18:45] <Daemon404> well yes, aslo i hate bugzilla. [18:45] <wm4> may as well use a pastebin to file bug [18:46] Action: Compn hasnt checked mplayer bugzilla in 1 year [18:46] <Daemon404> wm4, if i report a bug i do it on irc [18:46] <Daemon404> with a knife [18:46] <Daemon404> because of said not caring [18:46] <wm4> Compn: it uses trac niw [18:46] <wm4> *now [18:47] <Compn> wm4 : oh yeah, i remember that [18:47] <Compn> i think i logged in once [18:48] <Compn> argh why havent i been checking the trac [18:48] <Daemon404> FUCK [18:48] <Daemon404> OFF [18:48] <Daemon404> CARL [18:48] <wm4> sorry but he owns the bug tracker [18:48] <Compn> he does [18:49] <Compn> bug will be fixed when 2799 is fixed :p [18:51] <Daemon404> wm4, i cant tell if he's just an ass [18:51] <Daemon404> or functionally retarded [18:53] <Daemon404> this is why i never submit bugs [18:53] <Daemon404> because of carl. [18:53] <Daemon404> i know at least 5-10 people who also dont for this reason. [18:55] <Daemon404> ................... [18:55] <Daemon404> ok i am sending an angry email to ffmpeg-devel [18:56] <ubitux> http://cl.samdmarshall.com/U9Kt inside atom... [18:57] <ubitux> (so i heard atom is going to be half-closed source?) [18:58] <Daemon404> ... am i banned from ffmpeg-devel? [18:59] <Daemon404> my email isn't showing up [19:00] <Zeranoe> Are the release versions subjected to testing before they are finalized? If so, what tests are run? [19:00] <JEEBsv> > implying they are not just randomly picked commits [19:01] <JEEBsv> (which just pass FATE, as usual) [19:01] <Daemon404> 'When I closed this ticket, I had not yet done a complete analysis and I was not 100% sure if it is really a duplicate." [19:01] <Daemon404> seriously? [19:01] <Daemon404> fuck right off. [19:01] <wm4> lol [19:01] <Daemon404> wm4, my email has not made it to ffmpeg devel [19:01] <Daemon404> so im either banned or somethign or what [19:02] <JEEBsv> Daemon404: my condolences of you having to deal with ceho [19:02] <JEEBsv> *for [19:02] <Daemon404> who moderates the ML [19:02] <ubitux> llogan at least [19:03] <ubitux> maybe you got flagged as spam for spouting dirty talks ;) [19:03] <Daemon404> not possible [19:03] <Daemon404> the email is swear-free [19:03] <Daemon404> oh, nope, one. [19:04] <ubitux> time for repentance [19:04] <Daemon404> ill resent withotu swears [19:04] <ubitux> one is enough [19:04] <ubitux> just wait for llogan to come back [19:05] <ubitux> did you just get upset and went berzerk because Carl made a mistake? [19:05] <Daemon404> ook [19:05] <Daemon404> this one made it through [19:05] <Daemon404> ubitux, its not a mistake [19:05] <Daemon404> it's methodical [19:05] <Daemon404> and constant [19:05] <Daemon404> and unacceptable ehavior [19:06] <Daemon404> im not the only one who feels this way [19:06] <Daemon404> by a longshot. [19:06] <Daemon404> e.g. paul [19:06] <Daemon404> oh [19:06] <Daemon404> 1st made it through [19:07] <Daemon404> 2nd hasnt yet [19:07] <Daemon404> llogan, you cn delete the 2nd [19:07] <Daemon404> if you want [19:14] <llogan> Daemon404: i only see 11 spams in -devel [19:15] <Daemon404> yeah sorry [19:15] <Daemon404> my bad [19:15] <llogan> no problem [19:23] <llogan> maybe the occassional trac database lock is due to the daily database dumps [19:24] <Daemon404> hey at least we have backups [19:24] <Daemon404> a lot of foss stuff i used to file bugs against just went "lol woops db is gone" [19:45] <Zeranoe> Does FFmpeg follow standard C? I know it's C99, but is it all standard C? [19:47] <wm4> Zeranoe: you can't do anything useful in 100% standard C [19:47] <wm4> so what is this question even about? [19:47] <wm4> there are always certain areas where you have to do platform or compiler specific things [19:49] <Daemon404> ffmpeg is pretty standard [19:49] <Daemon404> we dont outride abuse stuff afaik [19:50] <wm4> there's compiler specific use of attributes and atomics, inline asm, use of POSIX stuff (which strictly spoken is outside of C) [19:51] <Daemon404> ah yes atomics [19:51] <Daemon404> clearly we should update to C11 [19:51] <Zeranoe> Or C++, kidding [19:52] <Daemon404> boost.atomics [19:52] <Daemon404> duh [19:52] <Zeranoe> Og god [19:52] <Zeranoe> Oh [19:52] <Daemon404> Zeranoe, did you ever get your x265 issue solved? [19:52] <Zeranoe> FFmpeg could use a Boost [19:53] <Zeranoe> Yeah, it was because hg pull doesnt apply update [19:53] <Daemon404> yeah [19:53] <Daemon404> hg is annoying like thta [19:53] <Daemon404> that [19:53] <Zeranoe> I thought my code was updated, it wasnt [19:55] <Zeranoe> Are there plans for a multithread x265 implementation? [19:55] <Daemon404> ? it is multithreaded [19:56] <Zeranoe> Might just be x265 then: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=10&t=1812&start=10#p6302 [19:56] <Daemon404> yes it is very slow [19:56] <Daemon404> even multithreaded [19:57] <Zeranoe> Is it supposed to replace x264? I'm still new to it [19:59] <Daemon404> yes [19:59] <Daemon404> but its not there [20:05] <Zeranoe> If HEVC replaces H.264, what replaces AAC? [20:05] <kierank> opus [20:06] <Zeranoe> Still the .mp4 container? [20:10] <Daemon404> sorry for weirdly-wrapped email [20:10] <Daemon404> my main mail client is out of reach, and gmail's web interface is... meh [20:18] <llogan> better than some Android mail clients that omit in-reply-to and references. [20:18] <Daemon404> that is evil [20:19] <Daemon404> on os x, mail.app doesnt let you rely easily to specific mails [20:19] <Daemon404> it lists everything 'flat' [20:19] <Daemon404> threads dont exist [20:19] <Daemon404> i hate it [20:23] <Zeranoe> Are there plans to update ffplay for SDL api 2.x? [20:26] <cone-400> ffmpeg.git 03Carl Eugen Hoyos 07master:3ba056017f97: Fix http authentication. [20:26] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:7e8be7081fed: avcodec/mjpegdec: Print human readable string for APPx [20:26] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:681e72a668ab: avcodec/mjpegdec: parse adobe_transform [20:26] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:6904168c79f2: avcodec/mjpegdec: Print error in case of CMYK [20:28] <llogan> Zeranoe: you could make it an enhancement/wish on the bug tracker. add keyword sdl. [20:29] <llogan> maybe marton has plans for it. you could ask him but i don't think he's on irc. [20:47] <Compn> Zeranoe : same tests as performed on nightly builds :P [20:48] <Zeranoe> Compn: Are there some for nightly builds? Fate? [20:52] <Compn> Zeranoe : probably fate tests [20:52] <Compn> Zeranoe : actually releases are right when people commit a bunch of private tree stuff so its 'in' before the release gets out [20:52] <Compn> which is probably really untested :) [20:53] <Zeranoe> How comforting to know lol [20:54] <Compn> google tests the hell out of each release/commit [20:54] <Zeranoe> Google? [20:55] <Compn> what exactly are you looking for? a complete 80gb samples.ffmpeg.org test with ffmpeg? [20:55] <Compn> google/youtube [21:03] <Zeranoe> Not really looking for anything, just wondering if they are supposed to be more stable because of more testing [21:06] <Compn> have ta ask michaelni if he does more testing on them [21:06] <Compn> before a release [21:06] <Compn> all of us devs are supposed to do stuff [21:06] <Compn> test, before the release [21:17] <Daemon404> michaelni, re: 6904168c79f2 [21:17] <Daemon404> thats not a terrible nice way to do it [21:17] <Daemon404> explode mode enables a bunch of failures that would otherwise produce ok images [21:18] <Daemon404> but a cmyk jpeg is not going to look at all ok [21:18] <Daemon404> ever [21:18] <Daemon404> the way we do it [21:18] <Daemon404> see e.g. my example [21:18] <Daemon404> it's one line. [21:18] <Daemon404> of purple [21:19] <Daemon404> it's cmyk but go ahead and decode as yuv444a because somebody might be able to decipher something in the bad output? just... :| [21:20] <Daemon404> thats not why explode mode exists [21:21] <wm4> how should it be fixed anyway? [21:21] <Daemon404> by error on cmyk [21:22] <Daemon404> its actually even doing it wrong [21:22] <Daemon404> c, m, and y use chroma qmats [21:22] <wm4> I mean if it were to be implemented properly [21:22] <Daemon404> its not hard, but we have no pix_fmt for it [21:22] <Daemon404> i think pretending it is yuva444p by default is bad [21:22] <wm4> maybe one could just scratch that and do conversion in the decoder? [21:22] <Daemon404> there's no possibility of it being correct [21:22] <Daemon404> due to qmat usage [21:23] <wm4> so even adding a special colorspace is out? [21:23] <Daemon404> doing conversion in the decoder is feasible [21:23] <Daemon404> but this fix is bad [21:23] <Daemon404> provides no usefulness [21:23] <Daemon404> only downsides [21:24] <wm4> yeah, I agree that should be taken care of now, instead of waiting until it's implemented [21:26] <beastd> Daemon404: Why only downsides? It does not hinder you or anyone to implement it correctly? Aren't you overstating a bit? [21:27] <Daemon404> no [21:27] <beastd> Or do you mean downside because one might overlook the error if not set to "explode"? [21:27] <Daemon404> any sort of automated o user facing system shouldnt except blatantly wrong stuff [21:27] <Daemon404> explode mode is not meant to disable hacks like "pretend cmyk is yuva444p' [21:27] <Daemon404> so as a user [21:27] <Daemon404> you end up with 2 options [21:28] <Daemon404> 1) use explode mode and lose a lot of legitimate functionality [21:28] <Daemon404> 2) dont use explode mode, and the ver common cae of cmyk will silently succeed with garbage output [21:28] <Daemon404> and there is no possibility of output being replote correct in this case [21:28] <beastd> well, maybe it should then be switched to act the other way around [21:28] <Daemon404> that makes even less sense [21:29] <beastd> Daemon404: i wasn't finished [21:29] <Daemon404> o [21:30] <beastd> maybe it should then be switched to act the other way around and error out normally but provide a hint to force incorrect decoding (not sure we have a good switch for that though) [21:30] <beastd> and i would not like to add a new one just for that hack. [21:30] <Daemon404> that seems more reasonable [21:30] <Daemon404> decoder have private options [21:30] <Daemon404> such things already exist [21:30] <beastd> Daemon404: that is possibility [21:31] <Daemon404> a private option is less bad than silently doing something so ridiculous imo [21:31] <Daemon404> not that i think its useful in the first place [21:32] <beastd> I have no strong opinion. but erroring out on default seems more reasonable to me too. [21:32] <Daemon404> yep. [21:33] <beastd> I have some other stuff to do today and didn't read -cvslog yet, but you could write there that you disagree and propose to change behaviour and use a private option to enable the hack or just to revert the commit [21:34] <Daemon404> beastd, problem is im not subscribed to cvslog [21:35] <Daemon404> and thus cannot repl [21:35] <Daemon404> y [21:35] <Daemon404> michaelni will likely read irc [21:35] <Daemon404> if he doesnt show up before i get my mail client box back up, ill send a mail [21:36] <beastd> ok. or just sent a mail to -devel and cite the commit. but maybe michaelni will read it here before. [21:36] <Daemon404> well id like to use my mail client [21:36] <Daemon404> gmail's web interface is crap at proper mail [21:37] <beastd> I can understand that :) [21:40] <Daemon404> he still closed it as a duplicate [21:40] <Daemon404> what the fuck is wrong with that guy [21:40] <ubitux> lol [21:41] <llogan> Daemon404: you can reply via the archives. the email address link will provide the in-reply-to. [21:41] <Daemon404> ah ok [21:41] <Daemon404> i didnt know that [21:41] <Daemon404> i learned something ne w! [21:41] <llogan> yeah. it took me a long time to realize too. [21:44] <beastd> Daemon404: the duplicate in the close may also have beend caused by some browser hiccup . give Carl Eugen at least the benefit of the doubt. [21:44] <Daemon404> years of dealing with carl have taught me differently [21:44] <Daemon404> this isnt something new. [21:45] <beastd> true story: once managed to just close a bug with no resolution at all [21:45] <ubitux> beastd: well, Carl definitely has a grudge against Derek [21:46] <beastd> I see no need to have any grudges. IIRC I have seen offense from both sides. [21:46] <Daemon404> carl holds grudges for a long time [21:47] <Daemon404> there used to be one against paul [21:47] <Daemon404> dunno what happened to that [21:47] <Daemon404> paul kinda left. [21:47] <beastd> not sure this is a black and white matter [21:48] <Daemon404> he has a long history of this [21:48] <Daemon404> this is not hearsay [21:48] <beastd> and ussually by holding grudges for a long time you hurt yourself the most [21:48] <Daemon404> of course [21:49] <beastd> anyway, this is a different matter. and sorry i really have not time as i have mentioned before :( [21:49] <beastd> no time* [21:49] <Daemon404> re: cmyk erroring, i will mail tonight [21:49] <Daemon404> if nothing pops up [21:49] <beastd> negative tine :P [21:49] <ubitux> beastd: btw, you aware of the random db lock on the trac? [21:49] <Daemon404> ubitux, it locks for backup [21:50] <Daemon404> you mean that? [21:50] <Daemon404> during sql dumping [21:50] <ubitux> seriously? [21:50] <Daemon404> lol yep [21:50] <Daemon404> or so ive been told [21:50] <ubitux> i backups for a long time... [21:50] <ubitux> it was frozen for a few hours today [21:50] <Daemon404> our trac db is not small [21:50] <Daemon404> oh hours is a bit much [21:50] <beastd> yes [21:50] <beastd> ubitux: how long? [21:51] <Daemon404> maybe im wrong [21:51] <ubitux> 09:35:01 < ubitux> OperationalError: database is locked [21:51] <ubitux> 11:57:17 < ubitux> ah, trac repaired [21:51] <ubitux> probably not exactly accurate [21:51] <ubitux> but i tried several times regularly [21:51] <ubitux> (and maybe it was already locked for a while) [21:53] <beastd> ubitux: from what i can see backup takes about a minute currently [21:53] <ubitux> 1 minute is fine [21:53] <ubitux> but that's not exactly what happened& [21:53] <ubitux> assuming that was the cause [21:54] <beastd> must have been something else [21:54] <beastd> we will investigate [21:54] <ubitux> it's "often" in that state recently afaict [21:54] <ubitux> thx [21:54] <Daemon404> do we have any monitoring on it [21:54] <Daemon404> like cpuload graphs [21:54] <Daemon404> or stuff [21:58] <beastd> Daemon404: Sorry, I am not aware of it, if we have it. [21:58] <Daemon404> :/ [21:58] <Daemon404> would be useful [21:58] <beastd> As you might have experience from your work. Can you recommend tools for recording the samples and visualizing the data afterwards? [21:59] <ubitux> Resolution changed from fixed to duplicate [21:59] <ubitux> olol [21:59] <Daemon404> i dont do that stuff at work [21:59] <ubitux> Daemon404: you duplicated your comment btw ;) [21:59] <Daemon404> by accident [21:59] <Daemon404> beastd, ganglia is a popular one [21:59] <ubitux> "This is not a duplicate. This is not a duplicate." [22:00] <Daemon404> ............................................................. [22:00] <Daemon404> you know\ [22:00] <Daemon404> fuck ffmpeg [22:00] <ubitux> haha this is so stupid [22:00] <beastd> :8 [22:00] <beastd> :( [22:00] <ubitux> i lost it at latest carl answer [22:03] <llogan> ubitux: did you ditch your old nick? [22:03] <ubitux> what old nick? [22:03] <llogan> i mean did you rename it or something because ChanServ didn't op you [22:04] <ubitux> you prefer like that? [22:04] <llogan> doesn't matter to me. i was just curious. [22:05] <ubitux> i have no idea what old nick you're refering too though [22:05] <llogan> because i am screwing around instead of working like i should be [22:19] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:501beae6f991: avcodec/mjpegdec: fix decoding 4th plane [22:19] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:a05635ee0158: avcodec/mjpegdec: convert CMYK to GBRAP [22:20] <Compn> whoa [22:20] <Compn> super trolling gets results [22:21] <wm4> lol [22:21] <wm4> 10/10 [22:26] <Compn> so uh [22:27] <Compn> nah nevermind. back to looking for garden supplies [22:58] <cone-400> ffmpeg.git 03James Almer 07master:fbf98375e481: x86/imdct36: don't build imdct36_float_sse on x86_64 targets [00:00] --- Fri Feb 28 2014