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

[burek]

[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