[01:34:09] <saintdev> awww, he just left http://danbooru.donmai.us/post/show/859807 [01:37:41] <saintdev> gah, keep doing that [05:17:52] <saintdev> peloverde: ping [05:31:27] <saintdev> actually, also ruggles: ping [06:52:07] <saintdev> lol "(float)1.0f" [06:52:41] <superdump> where's that? [06:52:51] <saintdev> 3gpp source [06:53:17] <saintdev> superdump: check your blog [06:53:39] <superdump> already responded [06:53:55] <saintdev> i guess emails are off :/ [06:54:09] <superdump> i'll check [06:55:05] <saintdev> superdump: dmcrypt is a gentoo init script included with the cryptsetup packages to handle automic setup/open/close of encrypted volumes [06:55:19] <saintdev> check out /etc/conf.d/dmcrypt [06:56:00] <saintdev> *automatic even [06:59:21] <superdump> saintdev: interesting... [06:59:25] <saintdev> superdump: i use it for encrypted swap [06:59:29] <superdump> is that only in openrc or in older stuff? [06:59:53] <superdump> i just had a look through and it seems like it could do what i want quite simply [07:00:27] <superdump> although... it's in /etc [07:00:34] <saintdev> afaik openrc, but the scripts belong to sys-fs/cryptsetup [07:00:48] <superdump> so i need to unlock root before i can access this [07:01:02] <saintdev> yeah, that's why i don't know if it can handle encrypted root [07:01:19] <saintdev> probably not, but you can use it for the other partitions/swap [07:01:52] <superdump> i don't think i really had to do anything for the other partitions as they're all lvm volumes inside the crypt partition [07:02:08] <superdump> once the crypt partition is unlocked, lvm does the rest [07:02:19] <saintdev> oh, you're doing lvm on top of the encrypted partition [07:02:20] <superdump> (though it doesn't seem to be unmounting them properly at the end) [07:02:23] <superdump> yes [07:02:53] <superdump> not really necessary as it's a laptop and i just have root, home and swap in there, but hey [07:03:45] <superdump> it means i only have to remember and type one passphrase [07:05:59] <superdump> hmm [07:06:01] <saintdev> also theoretically ctr mode can be faster than cbc mode. not sure if the actual implementation is or not [07:06:29] <superdump> i don't see any options anywhere to make wordpress send email to users who commented on a post [07:06:36] <superdump> only to me [07:07:37] <saintdev> lol, and i have almost nothing in my control panel :/ [07:09:06] <superdump> hrm [07:09:09] <superdump> sorry about that [07:09:39] <saintdev> i can see your askimet stats, though! [07:09:40] <saintdev> lol' [07:10:03] <superdump> you can? [07:10:12] <superdump> brooooooken [07:10:18] <superdump> how? [07:10:31] <saintdev> clicking on Dashboard from my control panel [07:51:37] <cartman> moin [08:24:57] <saintdev> we lost that netsplit, big time [08:26:29] <wbs> indeed [08:32:41] <pJok> kshishkov, not if using a cattleprod [08:33:54] <KotH> does saintdev have kids? if so, using a catleprod would be a moderate psychological pressure ;) [08:34:21] <kshishkov> KotH: no, he seems to be a good developer [08:34:26] <saintdev> what were you guys talking about, i ended up on the loosing side of the netsplit [08:34:47] <saintdev> getting me to fix aacenc? [08:34:52] <kshishkov> saintdev: how to make you into making ffaacenc being faster and better than faac [08:35:03] <kshishkov> saintdev: before 0.7 release preferably [08:35:07] <saintdev> o.O [08:35:39] <KotH> kshishkov: so no gf either? damn! [08:35:57] <saintdev> pe = inf, desired = 613.749878 [08:35:57] <saintdev> en = 4149235.750000, thr = 25190834.000000, nz = 3.105415, act = 3.105415, ah = 2 [08:35:57] <saintdev> en = 3235864.000000, thr = 402199.812500, nz = 12.661351, act = 12.661351, ah = 2 [08:35:58] <saintdev> ;) [08:36:29] <kshishkov> looks like debug dump from ffaacpsycho [08:38:04] <saintdev> that's what i'm currently looking at in my console ;) [08:39:19] <superdump> what do each of the values mean? [08:39:32] <kshishkov> they are meaningless [08:39:41] <kshishkov> though somehow realted to signal energy [08:40:11] <saintdev> pe = perceptual entropy, desired = target pe [08:41:21] <saintdev> en = scalefactor energy, thr = scalefactor threshold, nz = number of non-zero spectral lines, act = number of active spectral lines, ah = hole avoidance flag [08:43:51] <kshishkov> saintdev: have you tried rewriting psymodel from scratch after 3GPP spec? [08:44:22] <saintdev> kshishkov: no need. what's there is correct, just incomplete [08:44:40] <peloverde> saintdev: I'm sure at some point people will mention some details about CELT preserving energy in all bands, I recommend you ignore them until you have something 3GPPish working first [08:44:42] <saintdev> also the spec is incomplete [08:46:12] <saintdev> peloverde: are you against adding feedback between the coder and the psymodel to FFPsyContext? [08:46:49] <peloverde> I'm against being more ambitious than 3GPP until we have something working [08:46:55] <saintdev> the coder needs the frame-wide PE, and the psymodel needs the state of the bitreservoir [08:47:42] <peloverde> there is nothing wrong with the psymodel having access to the bit reservoir [08:48:26] <saintdev> i just want to make sure putting it in FFPsyContext is ok. [08:49:03] <peloverde> yeah [08:49:38] <kshishkov> s/having access/making encoder report/ [08:52:24] <saintdev> yay, pe is no longer ∞ [08:57:22] <ubitux> http://undeadly.org/cgi?action=article&sid=20110223045047 [08:59:18] <kshishkov> saintdev: it's infinity when some NAN occures somewhere (and with my sloppy coding and poor understanding of standards...) [09:01:34] <Tjoppen> hm [09:01:51] <Tjoppen> does ffmpeg indeed only do straight filter graphs? [09:02:14] <saintdev> kshishkov: it was my fault. stupid bug. [09:02:16] <Tjoppen> reading over the it seems that way [09:03:54] <kshishkov> saintdev: but in most cases you can blame it all on me [09:04:33] <saintdev> oh wow, even in functions that i wrote completely myself! thanks! [09:12:31] <saintdev> well, that's...decidedly worse [09:43:24] <Kovensky> http://i.imgur.com/ZyeCO.jpg [09:45:19] <kshishkov> meh [09:54:14] <Kovensky> mru: what the... britland is changing timezones? [09:54:43] <kshishkov> Kovensky: they are obviously following Russian example [09:55:37] <kshishkov> Kovensky: see http://en.wikipedia.org/wiki/Decree_time too [09:56:57] <Kovensky> вреЌя is time? [09:57:00] * KotH doesnt mention that .fr should actually move it's time zone back one hour [09:57:04] * Kovensky will probably promptly forget it in 10 minutes [09:57:17] <kshishkov> Kovensky: yep [09:57:41] <Kovensky> why so many ya/yo/ye sounds, they're annoying to pronounce :D [09:57:47] <kshishkov> KotH: sounds wrong. French people should adjust timezone by 79 minutes [09:58:11] <kshishkov> Kovensky: try French with its é,Ú and ê [09:58:40] <Kovensky> well, I know é and Ú because the diacritics happen to do exactly the opposite of what they do in portuguese [09:58:43] <Kovensky> no idea about ê though [09:59:21] <kshishkov> it's long e IIRC [09:59:33] <Kovensky> actually... not very sure about é either, since there's no ` diacritic in portuguese, and when it existed, it only applied to a, and it didn't change its sound [09:59:55] <ubitux> 'ê' sounds a bit like the "heh?" in japanese [10:00:13] <ubitux> or like a sheep, as you prefer [10:00:21] <Kovensky> baa [10:01:33] <kshishkov> wikipedia says it's a tombstone for dead consonants [10:01:43] <kshishkov> http://en.wikipedia.org/wiki/Circumflex#Deletion [10:09:11] * siretart likes http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-p... [10:11:15] <kshishkov> time to switch to Ruby? [10:11:43] <jannau> or C++ [10:12:09] <kshishkov> that would generate much profanity by itself [10:26:46] <pross-au> They didnt cover common lisp [10:28:08] <kshishkov> it's hard to swear with parentheses [10:28:23] <pross-au> (Asshole) [10:30:13] <kshishkov> nay, that's too lame [10:30:30] <kshishkov> at least Russians seldom swear [11:43:37] <mru> the total amount of profanity is constant [11:43:53] <mru> those languages with little of it in comments simply have it in the code [11:45:19] <kshishkov> mru: there's Russian where people can completely speak in profanities [11:46:01] <kshishkov> computer code analogy would be probably corporate code [11:47:24] <BBB> siretart: that mostly sounds what my lawyers came to conclude also - but so you think the license allows it to be redistributed? [11:48:02] <BBB> siretart: not that I care a lot of course, all I care about is that lavcodec+faac is not allowed to be linked together [11:48:35] <kshishkov> BBB: your lawyers? You're very evil man then [11:50:59] <BBB> SFLC :) [11:51:03] <BBB> they're "good" lawyers [11:51:21] <siretart> BBB: TBH, I don't care that much either, but this is the conclusion of the ubuntu technical board [11:52:28] <siretart> I'm currently thinking about an answer to that [11:53:06] <BBB> from my point of view, you can tell them I'm happy to see they concluded libavcodec cannot legally link to libfaac :) [11:53:22] <siretart> nobody really proposed that anyway [11:53:36] <BBB> DonDiego: please look at https://roundup.ffmpeg.org/issue455 [11:54:09] <siretart> BBB: would you still veto a libfaacbin wrapper that loads faac bin at runtime, similar to other wrappers we already have? [11:54:17] <BBB> yes [11:54:34] <BBB> the libfaac glue code can stay [11:54:36] <kshishkov> maybe other binary loaders as well [11:54:37] <BBB> the code is not illegal [11:54:44] <BBB> neither is building it yourself [11:54:49] <BBB> but you cannot redistribute the combination [11:55:11] <siretart> that's not what's happening [11:55:34] <siretart> they are still distributed seperately [11:55:38] <BBB> you're trying to create a libfaacbin so people can compile/install libfaac themselves and ffmpeg will pick it up [11:55:48] <BBB> I don't think that is the right message to send to people [11:55:58] <BBB> the right message is: please help us make ffaacenc better [11:56:12] <BBB> but if others think it's a good idea I can be overruled of course [11:56:30] <BBB> I don't like the libfaacbin idea, but I hate vetos more :) [11:56:33] <siretart> we trying to send that message out for years. in reality, people rather fetch (broken) packages that illegally dynamically link against libfaac [11:56:42] * kshishkov doesn't like any binary lib loader [11:56:44] <siretart> I'd like that to stop. fast. [11:57:05] <kshishkov> siretart: I can tell you how to get to Nero [11:57:24] <siretart> kshishkov: I doubt they would help to improve ffaac [11:57:34] <mru> kshishkov: shall I tell them about the backdoor I left? :) [11:58:18] <kshishkov> mru: next time they invite you to work [12:01:06] <kshishkov> siretart: well, Ivan Dimkovic said that Polish guy virtually rewrote faac making it much better that original Menno's [12:01:39] <mru> doesn't matter, as long as that file with the bad licence is there [12:02:12] <kshishkov> mru: well, faac AUTHORS file contains your name too! [12:04:21] <mru> what? [12:04:21] <siretart> kshishkov: how does this help getting ffaac improved? [12:05:17] <kshishkov> mru: yep, in contributors section [12:05:41] <mru> I must have sent a patch some time [12:06:46] <kshishkov> siretart: in no way [12:06:56] <kshishkov> siretart: but maybe you can work on improving it? [12:07:23] <kshishkov> siretart: I suspect it's on reference decoder level, i.e. any change would only improve it [12:08:17] <wbs> BBB: would you mind pushing the win/errno patch you queued yesterday, so we could close the roundup ticket? [12:08:32] <siretart> kshishkov: I put it on my list [12:08:46] <siretart> kshishkov: but don't expect me to get to that in the next 2 years ;-) [12:10:34] <kshishkov> BTW, what's the status with Bink-b audio patches? [12:22:01] <BBB> wbs: done [12:22:20] <CIA-15> ffmpeg: Martin Storsjö <martin@martin.st> master * r28c4741a66 ffmpeg/ (8 files in 2 dirs): (log message trimmed) [12:22:20] <CIA-15> ffmpeg: libavformat: Remove FF_NETERRNO() [12:22:20] <CIA-15> ffmpeg: Map EAGAIN and EINTR from ff_neterrno to the normal AVERROR() [12:22:20] <CIA-15> ffmpeg: error codes. Provide fallback definitions of other errno.h network [12:22:20] <CIA-15> ffmpeg: errors, mapping them to the corresponding winsock errors. [12:22:21] <CIA-15> ffmpeg: This eases catching these error codes in common code, without having [12:22:22] <CIA-15> ffmpeg: to distinguish between FF_NETERRNO(EAGAIN) and AVERROR(EAGAIN). [12:22:22] <BBB> wbs: sorry I hadn't done it before, I had it patch -p1'ed instead of git am'ed, so it didn't show up as a queued patch, my fault [12:22:39] <mru> why would you do that? [12:22:40] <wbs> BBB: np, and thanks for pushing [12:22:48] <BBB> mru: accident [12:22:58] <mru> strange accident [12:23:06] <BBB> not sure why I did that [12:23:31] <BBB> kshishkov: if they're OK'ed, I can apply [12:26:19] <kshishkov> BBB: let's see... [12:26:36] <BBB> I first have to apply elenril's patches though [12:26:42] <BBB> I still don't like put_tag() [12:27:35] <kshishkov> you prefer pull_tag()? [12:28:50] <BBB> I feel that with proper work, avio_wl32() could write 4 bytes at once, and most put_tag() uses could then use avio_wl32() with a MKTAG fourcc, possibly as a macro so it's easier to write [12:29:25] <BBB> for the few remaining cases, we could use avio_put_str() (which should be avio_write_str()), with an extra argument indicating if we want to write the terminating zero [12:29:59] * elenril doesn't really like adding one more argument [12:30:07] <elenril> but we can decide that later [12:31:55] <BBB> we can keep that version internal [12:32:12] <BBB> just like put_tag [12:35:39] <mru> has anyone looked into that vp8 clang bug? [12:36:33] <kshishkov> we have cartman for clang [12:38:37] <mru> yeah, but has he looked at it? [12:41:11] <mru> elenril: http://abstrusegoose.com/342 [12:43:22] <kshishkov> mru: rather silly question. He should have started with physical meaning of acceleration - it's meters divided by SQUARE SECONDS!!! [12:44:12] <mru> there's more than one time dimension, you know [12:44:26] <mru> a square second is one second in each of two time dimensions [12:44:34] <kshishkov> explain that to a man who rejects math [12:45:21] * Kovensky prefers round seconds [12:45:51] * mru multiplies Kovensky's seconds by pi [12:45:59] <mru> Kovensky: better? [12:46:13] * Kovensky confuzzled [12:47:32] <mru> Kovensky: when's your birthday? I was thinking of getting you a square pie plate [12:47:47] <Kovensky> lol [12:58:23] <BBB> cartman: ping [12:58:28] <BBB> mru: I've told him how to debug it [12:58:31] <BBB> mru: he didn't do it [12:59:05] <BBB> michael kostylev gave me shell on a system having that bug [12:59:09] <BBB> maybe I should look at it [12:59:42] <BBB> mru: also, are you sure vc1 idct can be done in words/17bit? because if counting from 12bit input (see specs), range can go up to 23-24 bits, if I count correctly [13:01:44] <kshishkov> BBB: he's implemented NEON VC-1 transform, I think, so he should know [13:01:58] <mru> I could have made a mistake [13:02:27] <mru> such as believeing ivan when he said 17 bits was enough [13:02:32] <mru> -e [13:02:55] <mru> kshishkov: look at your mmx/sse code [13:03:01] <mru> iirc it uses 16 bits all the way [13:03:08] <mru> and hopes for the best [13:04:15] <kshishkov> mru: it wasn't mine, I did altivec only [13:04:28] <mru> kshishkov: yours as in your employer's [13:04:59] <cartman> BBB: I am busy with real $job atm, clang thing is not easy to debug (at least for me) [13:06:01] <kshishkov> mru: yes, that one seems to be pure 16-bit [13:07:47] <kshishkov> probably because everybody ignores that BS about overlap transform extending range to 10 bits [13:07:57] <kshishkov> s/transform// [13:08:29] <mru> the spec says input to the transform is 12-bit signed [13:08:40] <mru> output of first stage is 13-bit signed [13:08:52] <mru> says spec [13:09:15] <kshishkov> indeed [13:09:23] <mru> and output is 10-bit signed [13:09:45] <BBB> I don't see the output being 13-bit [13:09:54] <mru> the spec says it must be [13:09:56] <BBB> if you take the first line, 16+15+9+4*some input [13:10:04] <BBB> then that's 12-bit*(16+15+4+9) [13:10:09] <BBB> =12+6 bits [13:10:11] <BBB> =18 bits [13:10:16] <kshishkov> BBB: intermediate matrices are in -4096..4095 range - i.e. 13 bits [13:10:29] <BBB> first part similar [13:10:33] <BBB> so input before >>3 is 19 bits [13:10:37] <BBB> so after >>3 16 bits [13:10:39] <BBB> how did it become 12? [13:10:47] <kshishkov> clipping [13:11:05] <BBB> hm... [13:11:11] <BBB> so is it all done in words [13:11:20] <BBB> or is it done in dwords and then intermediate clipping to words? [13:11:30] <BBB> as in, how much can I clip? [13:11:37] <mru> anyhow, in the second stage the coeffs sum to 90 [13:11:57] <kshishkov> and 96 in the first stage [13:11:58] <BBB> 90 *13bits > 16 bits [13:12:02] <BBB> so I don't see it fitting [13:12:07] <mru> you're right, it doesn't [13:12:09] <BBB> 90 = 7 bits [13:12:10] <BBB> so it's 20 [13:12:17] <BBB> ok, I'll do it in dwords then [13:12:45] <BBB> altivec code is in ints btw [13:12:46] <mru> I had some doubts, but ivan said it was fine... [13:12:54] <BBB> ivan just told me it wasn't fine [13:13:02] <mru> different ivan [13:13:04] <BBB> oh [13:13:04] <BBB> ok [13:13:19] <mru> one of the ivans in kshishkov's office [13:14:39] <BBB> as in, there's ten of them, and this is #7? [13:15:07] <mru> not quite that many [13:15:29] <kshishkov> aac one and smoking one [13:24:13] <lu_zero> o_O [13:24:18] * lu_zero is still on break [13:25:56] * iive wonders what is the family name of the smoking one [13:26:15] <BBB> "cigarette man" [13:26:37] <kshishkov> BBB: nope, he prefers cigars [13:26:55] <kshishkov> iive: not Bulgarian [13:35:59] <elenril> mru: spin is a certain feature of our mathematical models of reality [13:36:05] <elenril> it doesn't get much better than that [13:36:07] <mru> elenril: iKnow [13:36:30] <kshishkov> elenril: I always remeber Feynman's quote about electron [13:36:35] <kshishkov> *remember [13:37:17] <cartman> kshishkov: feel free to share Feynman quotes [13:38:04] <kshishkov> cartman: "when I think about an electron I imagine a bunch of graphics and formulae" [13:38:27] <cartman> lol :> [13:38:50] <kshishkov> that's the only way to imagine it properly [13:39:27] <cartman> true :) [13:48:06] <lu_zero> ^^; [13:49:18] <elenril> nah, electron is a rotating yellow point [13:49:47] <kshishkov> * NielsBohr stabs elenril [13:49:50] <mru> actually, it's white now [13:51:09] <mru> sorry, old kth joke [13:52:07] * kshishkov remembers SL joke on KTH [13:52:14] <elenril> kth? [13:52:24] <mru> kth.se [13:53:12] <elenril> meh, engineers [13:53:39] <pJok> elenril, spin is what politicians do... [13:53:56] <deppan> engineers are cool [13:53:58] <deppan> especially kth ones [13:54:23] <elenril> theoretical physicists are way cooler [13:54:29] <deppan> no [13:54:33] <mru> bullshit [13:54:39] <mru> engineers actually do shit [13:54:46] * kshishkov is also an engineer from KTH but different one [13:54:52] <deppan> theoretical physicists just whines and claims stuff wont work [13:55:01] * deppan has watched lots of stargate [13:55:01] * cartman is distinguished slacker [13:55:13] <mru> engineers get stuff done, whether possible or not [13:55:21] <deppan> många kth'are här eller? [13:55:33] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BeyondTheImpossible [13:55:39] <kshishkov> deppan: those are experimenters, theoreticians don't care about real world at all [13:55:41] <mru> deppan: minst tvÃ¥ iaf [13:56:00] <deppan> tre då+ :) [13:56:04] <mru> tre? [13:56:30] <deppan> kshishkov också? [13:57:05] <mru> kshishkov Àr frÃ¥n kharkov [13:57:06] <kshishkov> deppan: for me it was Kharkivska Tekniska (inte-so-)Högskolan [13:57:22] <mru> deppan: elektro? [13:57:25] <deppan> oh. [13:57:27] <deppan> mru: nä data [13:57:30] <mru> meh [13:57:47] <deppan> håller på med exjobbet atm [13:58:55] <spaam> kth.. tacka vet ja bth ;P [13:59:12] <spaam> </ironi> [13:59:28] <elenril> so when are the engineers who actually do stuff going to commit my patches [13:59:43] <elenril> oh wait, BBB isn't an engineer [13:59:47] <elenril> makes sense now [13:59:50] <spaam> hohohoh [14:17:53] <Dark_Shikari> http://news.ycombinator.com/item?id=2253945 [14:20:12] <mru> solution: be that "perfect candidate" instead [14:20:57] <Dark_Shikari> That's the best bet, indeed~ [14:21:22] <mru> and the best jobs are never advertised at all [14:21:30] <Dark_Shikari> Except because of #3. [14:21:37] <mru> those are not the best jobs [14:21:49] <mru> simply because the best jobs are not in companies with such policies [14:21:58] <Dark_Shikari> true. [14:22:23] <lu_zero> or the best job is for hr-type and the job is reorganize that part [14:22:50] <mru> self-obsoleting jobs... [14:23:08] <mru> do your job too well, and you won't have one [14:24:16] <lu_zero> you do your job well and move to something else [14:24:27] <lu_zero> then if the need arise they'll call you back =P [14:32:21] <kshishkov> lol at MN's mail: ".. but if you think[,] you are smarter than the previous people who worked on it." [14:37:24] <mru> he has a point [14:37:42] <mru> and jpeg2k is dead anyway [14:38:00] <mru> or is it still used by dcinema? [14:38:45] <Dark_Shikari> used by "professional" shit [14:38:53] <Dark_Shikari> i.e. still matters despite being awful [14:38:56] <kshishkov> but it's _wavelets_! [14:39:30] <mru> like any codec, with a low enough quantiser it gives decent picture [14:39:46] <mru> except maybe theora [14:40:02] <mru> theora has some really ugly artifacts [14:40:28] <kshishkov> mru: it's called design [14:40:52] <Dark_Shikari> theora should work fine as well [14:40:57] <Dark_Shikari> unless you're using like some version using the old VP3 encoder [14:41:02] <Dark_Shikari> which had insane fdct/idct mismatch [14:41:04] <Dark_Shikari> due to being written by on2 [14:41:50] <mru> sure, but haven't you noticed the peculiar artifacts you get with theora? [14:41:58] <mru> they're not like anything I've seen elsewhere [14:42:02] <Dark_Shikari> eh? nothing that looks atypical for an 8x8dct format [14:42:24] <Dark_Shikari> Pre-1.2 it had some really obnoxious artifacts at low rates in motion due to overzealous ungated skip decision [14:42:43] <kshishkov> mru: scalable JPEG? [14:43:05] <mru> Dark_Shikari: it uses a slightly different dct than the mpeg family [14:43:10] <mru> maybe that's the reason [14:43:12] <mru> I don't know [14:43:12] <Dark_Shikari> it's still an 8x8dct [14:43:23] <mru> or maybe it's the mismatch you mentioned [14:43:24] <Dark_Shikari> sure it's not exactly the same but neither is h264's or vc-1's [14:43:29] <Dark_Shikari> mismatch was fixed years ago [14:43:38] <mru> h264 isn't even a dct strictly speaking [14:43:49] <Dark_Shikari> It's close. Vaguely. [14:43:56] <mru> it has similar properties [14:44:03] <mru> which makes it a good choice for video coding [14:44:06] <mru> but it's not a dct [14:44:40] <Dark_Shikari> how close to a dct does it have to be for you to call it a dct? [14:44:51] <mru> dct has a precise mathematical definition [14:44:57] <mru> either something is one or it isn't [14:44:59] <Dark_Shikari> so simpledct isn't a dct? [14:45:11] <Dark_Shikari> it's not quite exactly equivalent. [14:45:30] <mru> it uses approximate values for the coeffs [14:46:01] <skal> at least it's orthogonal [14:46:05] <skal> could be worse [14:46:18] <mru> the h264 transform is all shifts and adds [14:46:22] <mru> no multiplications [14:46:27] <mru> with is wonderful to implement of course [14:46:33] <mru> but it's not a dct by a far cry [14:46:41] <Dark_Shikari> <insert snarky comment about how multiplications are just shifts and adds> [14:46:50] <mru> right [14:47:00] <mru> shifts by _one_ [14:47:27] <mru> coeffs of 1, 2, and 3 don't make a dct [14:47:42] <Dark_Shikari> the h264 dct has more complex coeffs than that [14:47:49] <Dark_Shikari> they're just factored into quant/dequant instead [14:48:43] <kshishkov> look at VC-1 [14:49:29] <mru> a dct decomposes a signal into a sum of cosines [14:49:37] <mru> a transform that doesn't do that isn't a dct [14:49:59] <Dark_Shikari> You can factor multiplication factors from a DCT into quant/dequant too [14:50:00] <Dark_Shikari> i.e. a real DCT [14:50:03] <Dark_Shikari> Not all of them, but many of them [14:50:09] <mru> first stage yes [14:50:12] <Dark_Shikari> And last stage [14:50:15] <Dark_Shikari> iirc [14:50:26] <Dark_Shikari> Oh, depends what you're calling first and last of course. [14:50:45] <mru> first stage for inverse, last stage for forward [14:50:56] <mru> or decode/encode if you will [14:50:56] <Dark_Shikari> yeah [14:52:59] <mru> I don't see any cosine-like coeffs in any stage of the h264 transform [14:53:33] <Dark_Shikari> http://cerezo.name/blog/2011/02/16/automatic-exploit-generation/ [14:53:57] <mru> only shifts by one or two and add/sub [14:53:59] <Dark_Shikari> a program that, given an input, finds vulnerabilities in said input program, and automatically generates exploits. [14:54:37] <mru> btw, is libjpeg or omx more likely to have a weird idea of dct? [14:56:04] <mru> plugging an omx idct into libjpeg needs a dc bias [14:59:09] <skal> jpeg's DC value is 0-centered [14:59:51] <mru> and mpeg is 128 [14:59:54] <mru> apparently [15:01:54] <skal> well, that's not counting with the various predictors [15:02:13] <skal> but yes [15:02:32] <Dark_Shikari> He's referring to the first block. [15:05:09] <BBB> elenril: why prevent deprecating symbols? [15:05:16] <BBB> elenril: I oppose that patch a little [15:05:51] <BBB> elenril: can't you just replace all put_tag by a pretty printed macro doing a avio_wl32(pb, MKTAG(str[0],str[1],str[2],str[3]))? [15:05:58] <BBB> elenril: otherwise I have to do it and I AM LAZY :-p [15:06:07] <BBB> elenril: plus all the stuff you just said [15:07:30] * Kovensky deprecates elenril [15:09:05] <elenril> BBB: ? [15:09:57] <BBB> elenril: instead of renaming put_tag and being silly, I'd like to get rid of it [15:10:02] <BBB> I think it's a silly function [15:10:19] <elenril> :effort: [15:10:26] <elenril> ok, i'll try [15:10:49] <BBB> how about for each non-four-letter one, we introduce an internal function called ffio_write_str(AVIOContext *pb, const char *str, int include_terminating_zero) [15:10:58] <elenril> btw [15:10:59] <BBB> then have avio_put_str() use that internally [15:11:06] <elenril> what to do about avio_put/get_strfoo [15:11:27] <BBB> and for each four-letter one have an internal macro ffio_write_fourcc() that calls avio_wl32() [15:11:38] <BBB> elenril: leave them for now [15:11:45] <BBB> naming is sub-ideal but it's ok, not a big deal [15:12:45] <BBB> we can change it if you feel like it, but then let's figure out if we want avio_write_str(AVIOContext *, const char *str) or avio_write_str(AVIOContext *, const char *str, int include_terminating_zero) [15:12:56] <BBB> important distinction [15:13:39] <elenril> meh, let's keep them [15:14:06] <BBB> :) [15:14:31] <elenril> yeah, i'm lazy [15:14:45] * BBB high-fives elenril [15:14:46] <elenril> can you commit url_fopen/fclose? [15:14:54] <BBB> I'll have a look [15:17:22] <BBB> they look good [15:17:24] <BBB> let me queue 'em [15:19:17] <BBB> queued [15:20:44] <elenril> avio_wl32(pb, MKTAG(str[0],str[1],str[2],str[3])) << will that work properly on all the weird archs? [15:22:05] <BBB> (str)[n] [15:22:07] <BBB> not str[n] [15:22:10] <BBB> (said mru) [15:22:18] <BBB> and yes it'll work on all weird archs [15:22:23] <BBB> MKTAG() automatically writes a LE tag [15:22:37] <cartman> where is av500 ? http://feedproxy.google.com/~r/Techcrunch/~3/e2gCRFfuUDs/ [15:31:16] <BBB> cartman: please find clang 2.9 bug thanks! :-p [15:32:04] <elenril> char tag[5]; put_tag(&tag[0]) << wtf [15:32:17] <cartman> BBB: I would if I could just fix this damn Android bug [15:35:58] <BBB> elenril: where? [15:36:08] <elenril> BBB: avienc [15:37:40] <ruggles> saintdev: you pinged? [15:38:10] <BBB> avi_stream2fourcc looks buggy with >10 streams [15:38:54] <mru> ruggles: isn't the past tense of "ping" "pang"? [15:39:00] <mru> compare "ring" [15:39:53] <ruggles> :) [15:41:19] <ruggles> google says it's "pinged" [15:41:33] <ruggles> first definition: hit with a pinging noise; "The bugs pinged the lamp shade" [15:41:57] * elenril pours some hate on mov [15:42:04] <mru> ruggles: different ping [15:42:25] <kshishkov> pingeth? [15:43:22] <kshishkov> mru: also http://www.learnersdictionary.com/search/ping [15:44:00] <mru> that's an archaic form [15:45:11] <CIA-15> ffmpeg: Anton Khirnov <anton@khirnov.net> master * r22a3212e32 ffmpeg/ (14 files in 2 dirs): [15:45:11] <CIA-15> ffmpeg: avio: rename url_fopen/fclose -> avio_open/close. [15:45:11] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [15:45:19] <CIA-15> ffmpeg: longstone <zhibing.min@hotmail.com> master * r4acc94e97a ffmpeg/libavformat/ (avi.h avienc.c): [15:45:19] <CIA-15> ffmpeg: avienc: fix AVI stream index for files with >10 streams [15:45:19] <CIA-15> ffmpeg: Fixes issue 2563. [15:45:19] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [15:46:51] <pJok> thou shalt not pingeth? [15:47:16] <kshishkov> "du ska inte pingar" even [15:47:35] <elenril> BBB: all the remaining uses of put_tag use constant strings [15:47:45] <elenril> so we can just put_buffer(sizeof()) [15:47:59] <elenril> no need to modify put_str [15:48:11] <BBB> elenril: really? [15:48:21] <BBB> elenril: if others are OK with that, then I am too [15:49:24] * elenril compiles [15:49:29] <BBB> and thanks for pointing out that avienc code to me [15:49:35] <BBB> I had a pending patch on roundup for that [15:49:41] <mru> elenril: sizeof("string") includes the null terminator [15:49:49] <elenril> iKnow [15:50:04] <mru> just checking, wasn't sure which you wanted [15:59:14] <elenril> BBB: patch sent [16:00:37] <BBB> awesome [16:02:00] <ruggles> kshishkov: is there any easy way to get the number of samples in a wavpack frame before the decoder starts writing the output? [16:02:14] <ruggles> the source is driving me crazy [16:02:22] <BBB> x?"AIFF":"AIFC" <- I wonder if the compiler does silly shit like MKTAG(x?'A':'A', etc.) [16:02:29] <ruggles> kshishkov: or even maximum number of samples [16:16:51] <BBB> elenril: commented [16:17:15] * BBB tihnks elenril will top our commit stats over 2011 [16:17:36] <spaam> cool guy [16:17:48] <spaam> BBB: who won last year? [16:17:56] <BBB> dunno [16:18:16] <BBB> mans, it seems [16:18:35] <BBB> (lines of code changed) [16:22:40] * mru goes to find some more tables [16:22:59] <mru> in fact, I have a patch messing with the twinvq tables somewhere [16:25:15] <merbzt> gotta love those [16:25:32] <merbzt> boom, ffmpeg got 500kb larger [16:25:42] <lu_zero> uhm? [16:25:50] <mru> my patch should make them a little smaller (compiled) [16:25:56] <mru> more efficient packing [16:26:08] <mru> perhaps I should dig it out again [16:27:40] <BBB> holy shit 500kb tables? [16:28:03] <BBB> does it load those tables if you don't actually use 'em? [16:28:21] <mru> depends on the OS [16:30:08] * mru tries to build ffmpeg with pcc, finds loads of bugs [16:30:11] <mru> in pcc [16:33:07] <lu_zero> pcc? [16:33:43] <mru> http://pcc.ludd.ltu.se/ [16:33:48] <lu_zero> http://pcc.ludd.ltu.se/news/ [16:33:52] <lu_zero> ok =) [16:35:42] <lu_zero> I wasn't aware it was still developed actively [16:36:02] <Flameeyes> decisions are made or taken? :| I never remember [16:36:18] <mru> made [16:36:30] <mru> actions are taken [16:36:32] <mru> and hostages [16:36:42] * elenril takes a cookie [16:36:43] <Flameeyes> thanks [16:36:59] <mru> cookies can also be made [16:37:51] * elenril prefers taking them [16:38:40] <Flameeyes> I think I'll go make some tea [16:48:05] <elenril> BBB: i'll send a separate patch for &tag[0] [17:01:35] <BBB> elenril: fine, I'll apply this then, looks good from my angle [17:05:16] * BBB stabs elenril for almost breaking fate [17:05:39] <elenril> what did i do again [17:06:02] <BBB> put_tag("FLV") != ffio_wfourcc() [17:06:14] <elenril> oops [17:06:17] <elenril> this is evil [17:06:22] <elenril> i thought i caught them all [17:34:29] <merbzt> http://www.h-online.com/open/news/item/Unicode-6-adds-astonished-face-119587... [17:35:46] * mru would use one but doesn't have the font [17:38:11] <merbzt> ☃ [17:40:52] <kshishkov> ruggles: yes, it's in frame header [17:42:01] <ruggles> kshishkov: is the samples_left stuff just for multichannel? [17:43:02] <kshishkov> nope [17:43:19] <siretart> merbzt: for me that looks more like a turd than a snowman
 [17:43:51] <kshishkov> ruggles: lossy wavpack files also tend to have more samples in a block than can fit default av buffer [17:45:00] <ruggles> ok, is the only thing samples_left is for? [17:45:50] <kshishkov> it's for signalling there are still some samples left undecoded in this block [17:46:04] <ruggles> and they're only left undecoded because of the output buffer size? [17:46:12] <kshishkov> yep [17:46:35] <ruggles> wow, that can go away completely with get/release_buffer() [17:46:56] <kshishkov> indeed [17:47:37] <ruggles> it looks like mkv mode and multichannel are the only cases where wavpack_decode_block() is called more than once for a frame. [17:47:50] <ruggles> and mkv mode has samples in the frame header [17:48:09] <kshishkov> all of them have\ [17:48:27] <kshishkov> mkv just stores them in first block, lavf demuxer - in all blocks [17:49:49] <kshishkov> and mono/stereo is just trivial case of multichannel :) [17:51:06] <ruggles> right, but it only has 1 block correct? the decoder sets frame_size = buf_size in the first loop iteration. [17:52:10] <kshishkov> yep [17:52:21] <ruggles> but multichannel has multiple blocks for multiple sets of 1 or 2 channels? [17:52:45] <kshishkov> yes [17:53:17] <ruggles> ok. so sample count is the same in each block, it just sets a different channel offset in the output buffer correct? [17:53:43] <kshishkov> yes [17:54:14] <ruggles> ok good. that samples_left part was throwing me for a loop... thanks for clarifying it. [17:55:18] <ruggles> nice solution for getting around the buffer size limit though :) [17:55:29] <kshishkov> it was rather obvious [17:55:44] <kshishkov> luckily it doesn't need that much of context to save [18:06:31] <therealgalen> irock: what's the status of your 10-bit ffmpeg code? is it usable for playing back h.264? [18:35:39] <saintd3v> ruggles: do you plan on using the psymodel at all (psymodel.{ch})? [18:37:44] <kshishkov> I fear it's not usable right now for AC3 [18:38:51] <saintd3v> kshishkov: well of course not [18:39:38] <ruggles> saintd3v: possibly if it improves it could be useful [18:40:12] <saintd3v> ruggles: i just mean the wrapper, not the stuff in aacpsy [18:41:59] <ruggles> saintd3v: oh, maybe. it depends on how complex a secondary psy model for ac3 would need to be. that just has critical band structure and function prototypes correct? [18:43:06] <ruggles> saintd3v: oh, the wrapper needs to support float samples though. now it just takes int16_t. [18:44:39] <saintd3v> ruggles: hmm, good point. [18:45:15] <kierank> hehe that mpeg-ts demuxer for flash remuxes the file into an flv in-memory [18:45:25] <kierank> I thought it was a bit dubious [18:45:48] <saintd3v> ruggles: if you're planning on using it, i was going to run some api changes by you (once i get back home). if not, i'll just do my own thing. [18:48:11] <ruggles> saintd3v: it would be good to see what you have in mind [18:51:12] <saintd3v> ruggles: ok, nothing big. just feedback from quantization for the state of the bitresevior (ac3 is pure cbr, isn't it?) and a way to pass frame-wide PE to quantization. [18:52:08] <mru> there's nothing to stop you changing bit rate between frames in ac3 [18:52:15] <ruggles> the ac3 encoder is currently pure cbr, and that's pretty much all that is used in practice. [18:52:16] <mru> don't know if that's allowed by the spec though [18:52:18] <ruggles> but it can be vbr [18:52:23] <ruggles> spec doesn't address it [18:52:29] <ruggles> aften does vbr ac3 [18:52:31] <mru> then it's allowed [18:52:49] <ruggles> i haven't gotten enough feedback to know what device support is like though [18:53:18] <ruggles> which probably means nobody is using it or that it doesn't break anything [18:53:52] <mru> I can imagine it breaking various spdif receivers [18:54:29] <saintd3v> mru: that was my first thought, lol [18:55:20] <mru> the receiver has to derive its clock from the signal, and I don't know how it would do that with vbr [18:55:35] <ruggles> what does it do when the program changes? [18:55:59] <ruggles> it would just be a program change every frame. :) [18:55:59] <mru> resyncs to the new rate I guess [18:56:12] <mru> but a frame is too short to sync properly [18:56:17] <ruggles> yeah, probably so [19:00:56] <kierank> mru: the spdif muxer can pad the frames out [19:01:12] <mru> but then it's cbr [19:01:28] <mru> and you'd be better off using those bits for actual audio instead [19:05:19] <ruggles> saintd3v: it looks like the psymodel api can only report bit allocation per band, correct? [19:14:29] <irock> therealgalen: yes, it works with 8-10 bits depth. [19:15:21] <irock> what's left to do is basically clean up and some refactoring [19:16:12] <irock> but it's usable as is right now [19:20:45] <saintd3v> ruggles: currently yes. [19:21:16] <saintd3v> which seems rather useless, imo. [19:21:41] <ruggles> yeah. ac3 does bit allocation per bin based on the energy estimate for that bin and the masking threshold for the corresponding band. [19:22:26] <ruggles> and the snr offset "quality" setting, which is adjusted to fit the cbr frame [19:22:43] <therealgalen> irock: good, i'm trying to package it up into a useful player, but i'm sure i'm doing something stupid at the moment [19:54:20] <irock> well, ask any question you like if it doesn't work for you [19:54:31] <irock> therealgalen: ^ [19:55:07] <therealgalen> irock: i think ffplay is not building for stupid local reasons, missing a library or something [19:55:27] <therealgalen> irock: i'm going to sort it out further but i have a few other things distracting me right now [19:55:40] <irock> ok, :) [20:08:26] <elenril> hmm, make fate fails on ./tests/data/vsynth1/flashsv.flv for me [20:09:39] <Kovensky> it's fate [20:09:56] <spaam> hohoh Kovensky was funny [20:10:19] * Kovensky spams spaam away [20:10:39] <spaam> instantrimshot.com [21:08:19] * elenril pokes BBB [21:11:05] * mru hands elenril a pointy stick [21:11:44] <elenril> mru: why does fate hate me? [21:12:40] * elenril wonders if he should blame clang [21:17:38] <mru> elenril: how does it hate you? [21:21:16] <elenril> http://pastebin.com/RViQ5jyY [21:22:15] <mru> it died during decoding [21:22:23] <mru> look for a .err file with more details [21:22:48] <mru> tests/data/vsynth1/flashsv.err or something [21:25:20] <elenril> http://pastebin.com/jLUXtFYk weird [21:26:28] <mru> the encoding step worked fine [21:26:49] <mru> since the checksum there didn't change [21:28:42] <mru> seems like something failing miserably reading the header [21:28:56] <elenril> well that happens on master [21:29:04] <mru> blame clang [21:30:50] * mru updates his copy of clang [21:30:54] * elenril tries gcc [21:35:37] <elenril> still fails with gcc [21:35:48] * mru blames elenril [21:36:52] * elenril wonders [21:39:44] * elenril sleeps [21:51:50] <ruggles> BBB: does wmavoice support stereo? [22:55:56] <BBB> shit [22:56:21] <BBB> clang-2.9 is definitely compiler bug, it's reproducible at -O2/3, not -O0/1 [22:56:25] <BBB> I wonder how to debug that [22:56:49] <mru> a new one? [22:57:12] <Yuvi> http://llvm.org/docs/HowToSubmitABug.html#miscompilations [22:59:19] <BBB> Yuvi: that's a massive document [22:59:31] <BBB> btw, Yuvi, weren't you buried in work at apple? is the iphone/ipad finished? :-p [22:59:42] * BBB checks pre-order to see if it shipped [23:00:28] <BBB> I wonder if they accept a bug if I tell them "ffmpeg version git-#@%&!$#(^&!#(%&!@% fails at make fate-vp8, but succeeds if compiling this one file at -O1, and this happens since this patch was applied" [23:00:58] <mru> BBB: same old bug? [23:01:28] <BBB> the clang-2.9 one failing vp8-fate since dark_shikari's patch [23:02:05] <mru> that's the one I meant [23:03:09] <BBB> yes that one [23:03:20] <BBB> is there an existing bug report for it? [23:03:42] <mru> are we sure it's not a bug in our code? [23:05:20] <Kovensky> well, he did say it only happens on -O2 and -O3 [23:05:27] <Kovensky> -O1 / -O0 don't trigger it [23:06:37] <mru> doesn't mean it's not our bug [23:07:04] <iive> aliasing? [23:08:00] <mru> or just about anything else [23:08:49] <kierank> [22:59] BBB: btw, Yuvi, weren't you buried in work at apple? is the iphone/ipad finished? :-p --> should I ask a friend of mine who told me about it early last time? [23:09:18] <mru> who cares about rotten fruit anyway? [23:09:23] <mru> nothing personal, Yuvi [23:09:24] <BBB> I love apple :) [23:09:30] <kierank> mru: women [23:12:55] <Yuvi> BBB: no comment on potential future hardware ;) [23:13:03] <BBB> well d'uh [23:13:08] <BBB> but good to have you back anyway :) [23:17:07] <Yuvi> actually, is it clang only or does it happen with llvm-gcc too? [23:17:50] <mru> llvm-gcc seems fine [23:19:20] <superdump> lu_zero: ping? [23:20:06] <Yuvi> it looks like the llvm-gcc configs on fate are r123173 and the clang 2.9 configs are r 125085 or newer [23:20:32] <mru> updating [23:20:40] <BBB> mru: thanks [23:20:48] <BBB> I could compile with llvm-gcc on kostylev's machine also [23:20:59] <BBB> locally I only have clang 1.5/2.8 and that works fine [23:21:08] <mru> those are ancient [23:21:24] <BBB> 2.9 isn't released yet [23:21:30] <mru> they could have added an optimisation that exposes a bug in our code since then [23:21:39] <BBB> probably [23:21:48] <mru> released or not, there have been a lot of changes since 2.8 [23:22:03] <BBB> or they could have added a bug that specifically creeps up when compiling ffmpeg [23:22:07] <BBB> wouldn't be the first time :-p [23:22:31] <BBB> brb [23:29:44] <mru> now I remember why llvm-gcc is stuck at an old version [23:30:00] <mru> linker crashes building it [23:56:31] <mru> anyone know a good gcc/binutils combination for building llvm-gcc? [23:56:45] <mru> everything I've tried fails