[00:00:19] <Compn> i heard people get dumber after being hired at google [00:00:25] <Compn> its probably the good food and atmosphere [00:01:31] <skal> ahm [00:02:07] <iive> BBB: are you going to move to another city? [00:02:10] <Dark_Shikari> everything about on2 staff can be summed up by "after nearly a year, plus 5-10 years of prior development, it's still 50% slower than ffvp8, which has less than a man-month invested in it." [00:02:35] <Compn> skal probably knows :D [00:02:57] <gnafu> Dark_Shikari: I'd say you play that up too much, but I can't. You have every right to be proud about that and gloat :-D. [00:03:01] <Compn> Dark_Shikari : thats not fair, the code ffvp8 uses has many man months invested in it [00:03:17] <Compn> e.g. all the h264 and idct whatnot code [00:03:17] <Dark_Shikari> you mean like... the h264 pred code copied from the spec? [00:03:22] <Dark_Shikari> idct is new to ffvp8 [00:03:27] <Dark_Shikari> the h264 pred is trivial and takes 1 hour to write [00:03:31] <Dark_Shikari> and half of it needed to be changed [00:03:36] <Dark_Shikari> and for emulated edge, like most was rewritten [00:03:49] <Compn> thats the only h264 shared code ? [00:03:58] <Dark_Shikari> yes [00:04:46] <Dark_Shikari> there's a bit of code imported from vp5/6, but that was mostly rewritten [00:04:51] <Dark_Shikari> for speed optimizations [00:05:08] <Compn> ah i thought it reused a lot more code [00:05:24] <Compn> since the commit was < thousand lines [00:05:30] <Compn> er < few thousand [00:05:46] <Dark_Shikari> the asm was another few thousand [00:05:56] <Dark_Shikari> but yes, it's a pretty small decoder. [00:08:32] <Sean_McG> hey folks [00:09:05] <gnafu> Sean_McG: Howdy! [00:09:11] <Sean_McG> :) [00:10:42] <BBB> Compn: vp8 isn't as elaborate as h264, you could compare it to h264 baseline in complexity. that's nice because it's much easier to write a full vp8 decoder, whereas our h264 decoder is massive and still doesn't implement everything [00:11:15] <mru> vp8 could be a bit less bizarre in place though [00:11:17] <BBB> it shares a little here and there, things like edge emulation, it will share edge extension when I implement it, h264 prediction, a few other minor things, but by and large it's new code [00:11:19] <mru> *places [00:11:29] <BBB> oh absolutely, some things are a little funky [00:11:52] <mru> saturating in strange places, unusual rounding, etc [00:12:07] <BBB> the edge default values for prediction are a little weird [00:12:39] <BBB> "slices" (what was that called again?) is implemented in a funny way that isn't as easy to implement as h264 or vc1 slices [00:12:46] <BBB> partitions, I believe [00:13:26] <BBB> because partitions can depend on each other and aren't contiguous, but rather interleaved on a line-by-line basis [00:13:47] <mru> what's the point in that? [00:13:55] <BBB> you could use it for threading [00:14:05] <BBB> but because they depend on each other it'll be much more complex than h264 slice threading [00:14:05] <mru> you said they depend on each other [00:14:08] <BBB> right [00:14:17] <BBB> so you need pthread_cond_() stuff [00:14:24] <mru> that's not all [00:14:38] <mru> slices are typically used for some error resilience as well [00:14:47] <mru> a damaged block doesn't ruin the entire picture [00:14:56] <BBB> good point [00:14:59] <BBB> I hadn't thought of that [00:15:14] <mru> that's why they were invented in the first place [00:49:34] * lu_zero wonders how intepolation/enhancement layers could work [00:51:07] <lu_zero> (as in pick just the even pixels instead of doing slices) [01:36:15] <mru> fate is compiling on haiku [01:39:47] <saintdev> mru: would have been better if you had made a haiku out of it [01:47:53] <mru> testing [02:03:09] <saintdev> whoa! gentoo bugzilla has a new color theme [02:18:26] <lu_zero> saintdev: bugzie4 [02:18:38] * lu_zero is __really__ thinking about it [02:18:54] * lu_zero recently update 3.6 on lscube and it went _really_ smooth =P [02:19:59] <saintdev> it looks, gasp, modern! [02:54:06] <siretart> moroning [03:46:39] <Sean_McG> o_O; [04:31:59] <xxthink> I have ever downloaded a ffmpeg version: ffmpeg-r22950 [04:32:14] * Sean_McG claps [04:32:17] <xxthink> How can I find the corresponding git version now? [04:36:20] <pengvado> git log --grep='Originally committed as revision 22950' [04:39:20] <xxthink> pengvado, Great!!! [08:44:58] <Tjoppen> morrn [08:45:05] <kshishkov> god morgon [08:45:46] <thresh> moroning, fellow ffmpeg developers [08:46:16] <kshishkov> moronings are for VLC, här har vi bara goda morgnar [08:46:34] <thresh> har har something something reminds me of Jar Jar Binks [08:47:03] * kshishkov has a special codec for that [09:18:12] <pross-au> Bink Bink [09:21:43] <kshishkov> indeed [09:33:13] * KotH blinks [09:33:36] <kshishkov> KotH KotH Blinks is our new hero? [09:33:59] <pross-au> thats a cool name for a codec [09:34:16] <pross-au> But we dont have five CCs, only four [09:34:45] <kshishkov> BLNK then [09:35:25] <saintdev> why do we need the 'L', just abbreviate it BINK....oh, erm wait.. [09:38:07] <kshishkov> saintdev: finish ffaacenc soon, ffbinkaudioenc awaits! [09:38:48] <saintdev> not touching that with a 39.5' pole [09:39:00] <kshishkov> which one? [09:39:46] <saintd3v> the latter [09:39:57] <kshishkov> there are two of them [09:40:04] <kshishkov> RDFT and FFT-based [09:41:35] <saintd3v> yeah, still not dealing with a bink audio encoder.. [09:42:25] <kshishkov> saintdev: AAC then? [09:44:54] <pross-au> Urgh [09:44:59] <saintd3v> guess it'll have to be.. [09:45:11] <pross-au> Waiting for 'Bink Mk II' [09:45:11] <saintd3v> :p [09:45:31] <kshishkov> pross-au: we had it supported long before Bink Mk I aka Bink-b [09:46:44] <saintd3v> ghost might be interesting, once monty gets to work on it. [09:46:55] <kshishkov> and aoyumi [09:48:27] <saintd3v> you think he'll help out with ghost like he did vorbis? [09:48:43] <kshishkov> I think otherwise it would be futile [09:48:53] <Tjoppen> isn't celt close to being frozen? [09:48:57] <KotH> kshishkov: aoyume? [09:49:02] <Tjoppen> -> ffceltdec [09:49:40] <pross-au> its frozen [09:49:42] <saintd3v> KotH: AoTuV Vorbis [09:50:51] <KotH> ok, then it's aoyume :) [09:52:17] <kshishkov> KotH: that should demonstrate again how far I am from psychoacoustics [09:52:40] <KotH> kshishkov: it only demonstrates that you are far from japan :) [09:52:58] <kshishkov> KotH: well, http://www.geocities.jp/aoyoume/aotuv/ says "(c)2003-2011 蒼弓／AOYUMI" [09:54:26] <KotH> hmm.. ok... [09:54:35] * KotH should read the whole page... not just the url [10:37:49] <kierank> _av500_: http://news.ycombinator.com/item?id=2301439 [10:40:35] <av500> you troll my BFF [10:40:40] <av500> outrageous! [10:41:31] <kshishkov> av500: no, he didn't troll TI [10:41:56] <av500> bah [10:42:28] <kierank> av500: not a troll [10:42:31] <kierank> a statement of fact [10:44:00] <kierank> av500: wow your post of http://parliamentfights.wordpress.com/ is brilliant [10:44:36] <av500> thats why so many ppl upvoted it [10:58:16] <CIA-36> ffmpeg: Anton Khirnov <anton@khirnov.net> master * rfb61a7c534 ffmpeg/libavformat/id3v2.c: [10:58:16] <CIA-36> ffmpeg: id3v2: fix typo in error message [10:58:16] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [12:14:26] <mru> all hail kostylev, we have win64 on fate again [12:14:48] <BBB> wbs: I thought you had push access? [12:14:56] <BBB> mru: indeed, I noticed yesterday night, I'm so happy [12:15:08] <BBB> finally I will know again when I break win64 [12:15:16] <BBB> I still miss ramiro though [12:15:46] <mru> well, apparently he _likes_ being oppressed [12:16:23] <spaam> Nice.. no red stuff :D [12:17:32] <spaam> nice segfault on icc / ia64. [12:17:49] <wbs> BBB: no, I don't [12:38:11] <lu_zero> meanwhile I'm finishing prepping up minw32 cross autobuilds [12:44:29] <spaam> lu_zero: Nice.. for ming64 also? [12:45:55] <lu_zero> spaam: never tried mingw64 [12:46:48] <lu_zero> cross compiling for windows something that does not have autotools or proper build system is quite problematic [12:47:52] <lu_zero> (ffmpeg is good, autotools are usually good, cmake does not, many homebrew not as well) [12:48:23] <lu_zero> brb [12:57:41] * mru curses haiku a little [12:58:40] <kshishkov> too small OS? [13:08:27] <mru> hah, cursing helped [13:09:36] <kshishkov> because it's toy oS [13:09:53] <kshishkov> people constantly curse in Russia but nothing improves there [13:10:17] <mru> well, hopefully fate/haiku should be self-running now [13:11:34] <kshishkov> any other OSes to consider? [13:11:43] <kshishkov> like plan9 [13:12:14] <kshishkov> or RISC OS [13:12:25] <mru> plan9 is too fucked up [13:12:32] <mru> it can't talk to anything but plan9 [13:12:44] <spaam> but plan9 works [13:12:48] <spaam> cool name.. [13:12:53] <mru> and it doesn't have a C compiler [13:13:13] <kshishkov> depends on C value [13:13:25] <mru> they removed the #if directive [13:14:18] <av500> and #else? [13:14:29] <mru> they have #ifdef, not #if [13:14:52] <kshishkov> well, they say "greatly simplified preprocessor" [13:14:54] <av500> #if considered harmful? [13:15:17] <mru> and they have obsession with ugly guis [13:15:21] <mru> +an [13:15:27] <Zor> many people believe that the #if preprocessor directive is the root of all the evil pp forests [13:15:31] <kshishkov> av500: too lazy to compute conditions in preprocessor I suspect [13:15:42] <mru> no, they consider it unnecessary [13:15:47] <mru> and therefore it must go [13:15:48] <kshishkov> Zor: no, it's #define [13:16:06] <Zor> kshishkov: #define is not bad if you can only #ifdef [13:16:10] <Zor> in that mindset anyway [13:16:12] <mru> it's not hard at all to write bad code without #if [13:16:15] <mru> witness java [13:17:24] <kshishkov> mru: it's easy to write bad code in any language [13:17:34] <mru> exactly [13:17:49] <mru> so removing features in an attempt to make it harder is misguided [13:19:50] <kshishkov> BCPL? [13:21:05] * av500 forces kshishkov to write bink encoder in CICS [13:22:09] <kshishkov> av500: after xvp8 [13:34:12] <kierank> silly fruit company [13:34:14] <kierank> not fixing its bugs [13:38:35] <kshishkov> do they acknowledge them at all? [13:39:09] <mru> kshishkov: they are infallible [13:39:17] <mru> they are the very definition of perfection [13:40:14] <kshishkov> indeed! [13:40:31] <av500> you are just holding it wrong [13:40:32] * kshishkov still doesn't go to buy their products [13:46:08] <mru> mmu_man: is there an ntp client for haiku? [13:49:42] <mmu_man> mru: don't think so [13:50:01] <mru> what kind of a joke os is this? [13:50:17] <kshishkov> mru: joke os [13:50:47] <mmu_man> http://ports.haiku-files.org/wiki/net-misc/ntp [13:51:05] <mmu_man> you can send a patch [13:51:16] * kshishkov thinks Haiku is intended for pleasing all three of its developers by the fact it exists, nothing else [13:53:30] * mmu_man thinks kshishkov should just send patches instead of complaining [13:53:45] <mru> mmu_man: not complaining, mocking [13:53:50] <mru> there's a difference [13:54:00] <mru> diff -u haiku linux | sendmail mmu_man [13:55:20] <kshishkov> mmu_man: why should I complain? I don't use it and not sure if I've ever touched it [13:56:31] <mmu_man> mru: you'll be over quota [13:57:08] <kshishkov> yes, send shell script for replacing Haiku with stage3 instead [14:13:30] <mru> ruggles: ping [15:21:44] <Ayad123> i need begin to configure the ffmpeg, i need have the best option or synthaxe to convert and optimize a best quality of my video avi to swf or flv [15:22:46] <av500> -> #ffmpeg [15:30:57] <lu_zero> could be interesting having haiku using pkgcore or portage [15:31:34] <mru> shouldn't be too hard to put gentoo prefix on it [15:31:41] <lu_zero> mru: sure [15:31:54] <kshishkov> just replace it completely with Gentoo [15:31:57] <lu_zero> but they could use pkgcore and leverage what we provide [15:32:23] * lu_zero usually offer that to every os starting to think about package management [15:32:32] <lu_zero> sad minix preferred pkgsrc [15:32:42] <mru> they'd be better off porting the gui and filesystem to linux [15:32:48] <lu_zero> and haiku decided to make a workalike [15:32:58] <lu_zero> mru: I prefer having variety [15:33:26] <lu_zero> linux can be wrong, freebsd can be wrong, having both wrong at the same time is less likely ^^; [15:33:50] <mru> the only variety you get with these fringe OSes is different levels of non-support for mainstream modern hardware [15:34:12] <mru> they lack the manpower to write drivers for every device that comes out [15:34:37] <mru> better to put it on top of a kernel that does all that for you and focus on what makes it different [15:35:52] <kshishkov> lu_zero: minix is sad indeed [15:36:04] <mru> minix can't do that for obvious reaons [15:36:17] <mru> having a different kernel being the entire point of their existence [15:36:54] <kshishkov> well, that's the point [15:37:02] <kshishkov> every OS should have some goal [15:37:24] <kshishkov> for Minix it's to demonstrate The Holiest Microkernel Architecture [15:37:24] <ubitux> i don't know if roundup maintainers have been noticed by it, but i was unable to register with a message telling maintainers will get noticed [15:37:31] <ubitux> can anyone confirm it? [15:37:45] <kshishkov> for Haiku - to provide more shiny and useless OS than MacOS X [15:37:48] <mru> a minix-like architecture might be good for building highly reliable systems [15:38:04] <mru> for 99% of cases performance is more imporant though [15:38:44] <mru> engineering is all about making tradeoffs [15:38:50] * av500 wishes he could reboot the linux usb subsystem only [15:39:09] <mru> all these fringe systems tend to take at least one of these tradeoffs to the very extreme in one direction or other [15:39:19] <mru> av500: modprobe -r usb? [15:39:36] <mru> av500: don't do it with a usb keyboard [15:40:17] <mru> in a modular linux kernel, many subsystems can be restarted like this [15:40:47] <av500> modules in "strange" states often refuse to unload [15:40:52] <mru> if any core data structures have been corrupted you're stuffed of course [15:40:59] <mru> av500: modprobe -rf [15:41:12] <mru> the -rf flag works with many commands... [15:41:28] <av500> mru: I know all that [15:41:38] <av500> still I had cases where it did nothing [15:41:47] <mru> yes, I've had those too [15:42:05] <mru> and sometimes the hardware itself gets into a nasty state and needs a power cycle to reset properly [15:42:15] <av500> so it would be nice to be able to tell linux: forget that subsystem and make a new one :) [15:43:18] <kshishkov> mru: I believe Minix would encourage Windows approach to drivers, i.e. "crash at your heart desire" [15:43:56] <av500> kshishkov: sadly the other option fails as well [15:44:04] <av500> "this driver is bugfree" [15:44:06] <av500> lol [15:44:25] <kshishkov> but it's more appealing to me [16:15:49] <BBB> astrange: ping [16:19:16] <spaam> http://who-t.blogspot.com/2011/03/how-to-dos-developer.html [16:19:28] <mru> old [16:19:55] <spaam> mru: good [17:25:10] <ruggles> mru: pong [17:26:25] <mru> ruggles: I'm optimising ac3 for arm [17:26:33] <mru> and I'm seeing simd potential everywhere [17:27:15] <ruggles> yes, there is a lot of potential. [17:27:46] <ruggles> i would certainly be interested in where you see it though [17:28:24] <mru> well, the float scale_coefficients() would be an obvious one [17:28:37] <mru> neon has an instruction for that [17:28:50] <ruggles> yeah, i have that written already [17:28:54] <mru> cool [17:29:06] <ruggles> just need to submit it. it's kinda ugly due to the float param, but it works [17:29:14] <mru> float params? [17:29:22] <ruggles> the scalar [17:29:27] <mru> scalar? [17:29:33] <mru> I see a 24 [17:30:02] <mru> that needs to be a constant for neon [17:30:03] <ruggles> oh, i wanted to make it more generic. [17:30:11] <ruggles> for use with format conversion as well [17:30:18] <mru> the float to fixed takes only an immediate for the fractional bits [17:31:33] <ruggles> maybe a generic float scale factor is not needed then. [17:31:50] <mru> not if you want twice the speed [17:33:09] <ruggles> i don't think x86 has that though. we would have to scale the float to the proper range first. [17:33:31] <ruggles> but still the function could take an int [17:33:33] <mru> if you don't have that instruction you obviously have to do it the hard way [17:34:50] <mru> got any more unsent patches? [17:35:09] <mru> and don't bother doing neon stuff, I'm paid to do that [17:35:24] <ruggles> no other asm [17:36:24] <mru> that loop we were talking about yesterday could be simded I think [17:36:49] <ruggles> yeah, i tried once and it was slower, but i was thinking about trying again [17:36:59] <mru> and apply_rematrixing() [17:37:06] <ruggles> yeah, i tried that too [17:37:23] <ruggles> 1) none of the bands are on a 16-byte boundary [17:37:30] <BBB> mru: why don't you mentor a soc project? [17:37:46] <mru> BBB: I get 10x more money doing it myself [17:38:04] <ruggles> 2) the first 3 bands are only 12 coefficients wide [17:38:05] <BBB> you get a person doing it for you, and you can earn money doing something else in the mean time [17:38:27] <mru> I'll probably be mentoring for beagleboard again [17:38:30] <ruggles> but doing the whole thing in asm might be better. [17:38:50] <mru> apply_rematrixing should be easy to do in pure asm [17:40:21] <ruggles> i'm trying to focus on getting my feature patches done right now, but i'm keeping a list of where i think asm optimization will help. [17:52:04] * iive mark [18:06:00] <jb_holidays> hello [18:06:18] <jb_holidays> av500: kshishkov: at CeBIT, people have asked for Bink support :D [18:06:57] <mru> jb_holidays: you didn't recognise av500 in his disguise? [18:08:28] <jb_holidays> I didn't ! [18:09:34] <ruggles> mru: what other good optimization opportunities do you see for ac3enc? [18:09:45] <mru> I see loops everywhere [18:09:59] <mru> need to figure out which ones are taking time [18:11:28] <mru> now in ac3_exponent_min(), what are the rules for nb_coefs? [18:14:12] <ruggles> i'll double-check. it was multiple of 16, but then i changed something in the loop so it doesn't have to be. but i forget what the exact behavior is. [18:14:40] <ruggles> unfortunately, that will have to change anyway for channel coupling [18:14:57] <mru> what will have to change? [18:15:48] <ruggles> my current patch always calls it with nb_coefs=256 for simplicity, but i might have to just special-case the coupling channel. [18:16:12] <ruggles> because it doesn't start on 16-byte boundary [18:16:32] <mru> non-aligned is easy enough to handle [18:16:44] <mru> not multiple of 16 is worse [18:18:38] <ruggles> well, it only operates on multiples of 8 or 16. and rounds up due to how it is implemented. [18:18:48] <ruggles> that probably needs to be documented [18:18:49] <jb_holidays> michaelni: ping [18:20:44] <mru> ruggles: there's a bug somewhere [18:20:53] <michaelni> pong [18:20:55] <mru> it's not giving the same result as the C version [18:21:07] <michaelni> jb_holidays, pong [18:21:24] <ruggles> really? it passes regression testing. [18:21:49] <mru> maybe that's just luck [18:22:41] <ruggles> and the result would not decode if it didn't work properly. [18:24:43] <mru> well, I'm seeing nb_coefs=223 here [18:24:53] <ruggles> yes, that's correct [18:25:01] <mru> that's not a multiple of 16 [18:26:14] <ruggles> right [18:26:58] <mru> so the simd functions write more than they should [18:27:01] <mru> and the output differs [18:27:33] <ruggles> it's ok for it to write more than it should [18:27:47] <mru> the encoded output differs [18:28:12] <mru> so either md5 is wrong or you're wrong [18:28:14] <ruggles> ah, that would be the exponent grouping. [18:28:39] <ruggles> i can fix that. the extra exponents are not decoded, but they are encoded. [18:29:41] <ruggles> exponents are encoded in groups of 3, 6, or 12 so sometimes more are encoded than are actually used [18:32:56] <mru> so how do we fix it? [18:33:13] <ruggles> several ways... [18:33:53] <ruggles> 1) require multiple of 16 for nb_coefs [18:34:31] <ruggles> 2) handle it in group_exponents() [18:34:48] <ruggles> 3) handle it in encode_exponents_blk_ch() [18:35:26] <mru> 4) require the simd functions to handle a non-multiple of 16 [18:42:52] <ruggles> 5) pass nb_coefs+3 [18:47:28] <spaam> ??? [18:47:35] <spaam> PPROFIT [18:49:18] <ruggles> mru: i can't reproduce the differing md5 even with a big file... which x86 version of the function are you using? [18:54:54] <ruggles> maybe it's just luck. it's probably a rare case. [18:59:54] <ruggles> mru: could you check if passing nb_coefs+3 fixes your sample? [19:05:39] <mru> ruggles: all the x86 functions give the same differing output here [19:06:32] <ruggles> what about nb_coefs+3? [19:07:44] <jermy> ugh. I'm not having as much fun as I'd hoped with the smoothstream decoder. [19:08:23] <kshishkov> try RealMedia [19:08:55] <BBB> astrange: ping [19:09:18] <kshishkov> BBB: use ping-mt [19:09:27] <BBB> might have race conditions [19:09:39] <jermy> I've got a parser for the metadat files, but having a demuxer in the same style as applehttp is doomed since the chunks don't decode properly [19:09:46] <lu_zero> jermy: smoothstream -> ms-segmented-asf? [19:10:03] <lu_zero> jermy: use the protocol approach [19:10:09] <jermy> nah. Segments of mp4 [19:10:09] <mru> ruggles: different again [19:10:16] <lu_zero> of mp4? [19:10:16] <mru> why would +3 fix anything? [19:11:03] <lu_zero> segments of mp4.... [19:11:08] <jermy> and the audio is seperate, so it probably needs a demuxer to sync, no? [19:11:17] <lu_zero> so you must use the demuxer approach [19:11:18] <ruggles> mru: because it would ensure that at least that many exponents are processed. and none after that will be used. [19:11:43] <jermy> yeah. little packets with a moof header and a mdat [19:12:06] <mru> well, the c and simd versions still differ [19:12:47] <jermy> I'm just wondering at what point do I copy some bits of the mov demuxer and create my own codec context [19:13:46] <ruggles> mru: the encoded output differs even with nb_coefs+3? [19:13:51] <mru> yes [19:14:33] <ruggles> ah. i just thought of another thing... [19:14:40] <ruggles> an issue i came across during channel coupling [19:15:08] <ruggles> exponent strategy decision does sum of all 256 exponents [19:15:55] <ruggles> so rare cases it could be putting it above or below the threshold [19:17:11] <mru> and I just had to choose a sample where it did [19:18:03] <ruggles> part of my coupling patch changes the exponent strategy decision to work for any number of coefficients. [19:18:34] <ruggles> but that should be fixed ASAP [19:33:22] <vcs> where can i find documentation on the int64 timestamp used in *_read_seek functions? Is it some predefined format? [19:34:45] * mru attempts to complete the census form [19:35:03] <kierank> not meant to do it yet mru [19:35:17] <mru> only opened it now [19:35:31] <kierank> do it online [19:35:37] <kierank> you're meant to do it on the 12th iirc [19:35:42] <mru> 27th [19:35:46] <mru> but most of it won't change [19:35:58] <kshishkov> name - mru, nationality - troll, occupation - see above [19:36:16] <mru> it's not like my age or place of birth will change before the end of the month [19:39:50] <kierank> still should sent it electronically, way more efficient [19:39:56] <mru> of course [19:40:37] <mru> the website doesn't require all at once [19:40:52] * kierank has been waiting on the oyster card helpline for 30 mins now [19:41:52] <kshishkov> kierank: isn't British service known to be relaxed? [19:42:07] <kierank> dunno [19:43:12] <ruggles> kierank: how is dolby e decoding coming along? [19:43:43] <kshishkov> it's for gsoc 2011 [19:48:02] <BBB> vcs: what do you mean? [19:48:13] <BBB> vcs: it's a time units as set in AVStream->time_base [19:48:47] <BBB> vcs: so if time_base is num=1,den=1000000, then it's in microseconds, if time_base is num=1,den=44100, then it's an audio sample counter, etc. [19:49:20] <BBB> vcs: and so on for whatever is your favourite way to handle timestamps, it's supposed to maintain timestamp accuracy regardless of source timebase [19:49:30] * mru sets timebase to 1 aeon [19:49:36] <vcs> ahh so its dependant on that [19:50:24] <kierank> lol BBB too many people editing the wiki [19:53:37] * kierank wonders what happens if you send the census paperwork as well as filling it out online [19:54:24] <mru> they compare them, and if different come and take you away [19:55:33] * kierank won't mind being shipped to australia [19:56:22] <kshishkov> shackled? [19:56:35] <mru> kierank: http://www.youtube.com/watch?v=hnzHtm1jhL4 [20:02:22] <mru> ruggles: I'm getting 4% cycles in memcpy [20:02:27] <mru> I find that disturbing [20:03:48] <ruggles> mru: what about deinterleave_input_samples()? [20:04:16] <mru> I think I need to turn off some inlining to get sensible numbers [20:05:16] <ruggles> the others can probably be addressed with some restructuring, but that memcpy() is necessary [20:06:02] <mru> I guess [20:06:27] <mru> unless running on a dsp with modulo addressing [20:06:31] <mru> neat stuff, that [20:09:16] <ruggles> mru: one of the things on my list to try is having a reference block for exp and bap rather than copying them. [20:15:29] <mru> ffs, I can't make this damn thing not inline everythign [20:19:34] <mru> what is it with gcc and function names? apply_window.clone.4.clone.14 [20:27:09] <mru> that one can be simded [20:28:36] <BBB> kierank: not seeing it (?) [20:28:54] <kierank> works now [20:29:10] <kierank> for a while the database had an error [21:13:16] <kierank> mru: http://users.softlab.ece.ntua.gr/~ttsiod/cpp.html [21:13:19] <kierank> </troll> [21:14:33] <mru> aaaauuuuggh, WHY do some people prefix all struct names with 'tag'? [21:14:37] <mmu_man> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011 [21:14:43] <mmu_man> "This Account Has Been Suspended" [21:14:48] <mmu_man> !? [21:15:02] <gnafu> kierank: "to say something in less words, means that you are wise about it" [21:15:04] <mmu_man> mru: cause M$ said so [21:15:07] <gnafu> That's a lesson I need to learn :-P. [21:15:22] <BBB> mru: because it's short and awesome [21:15:54] <mru> I've even seen it _mandated_ by corporate coding standards [21:16:06] <superdump> perhaps that happened because mike started mirroring the samples archive [21:16:12] <gnafu> mmu_man: Ooh, looks like someone's been hitting the samples mirror a bit too hard. [21:16:18] <mru> here's the funny part, I ignore said coding standards and nobody noticed [21:16:20] <superdump> and someone found it objectionable / it used too much bandwidth [21:16:46] <gnafu> Does anyone know what hosting provider he uses? [21:17:02] <mru> a crappy one [21:17:06] <mru> by the looks of it [21:17:53] <BBB> I emailed mike [21:17:55] <BBB> he'll fix it [21:18:55] <gnafu> BBB: Give it to Mike(y). He'll [fix] anything! [21:20:16] <mru> kierank: some ideas in c++ are good, templates perhaps being one of them if used in moderation [21:20:27] <mru> but the syntax is disgustingly ugly [21:20:52] <mru> and typical c++ coders tend to write more code than average c programmers to solve the same problem [21:21:21] <mru> I guess I dislike how it is used at least as much as the language itself [21:23:49] <Flameeyes> mru: I actually like C# better than C++ :| [21:24:04] <mru> never used it so I can't say [21:24:07] <Dark_Shikari> A<B>> [21:24:55] <Flameeyes> mru: it has most of the concepts of C++, but reduced syntax complexity, and a saner standard library [21:25:26] <elenril> and it's inherently evil by virtue of its creator =p [21:25:42] <mru> microsoft have done a few good things [21:26:25] <DonDiego> greetz from tel aviv [21:26:34] <Flameeyes> hi DonDiego [21:26:39] <Dark_Shikari> C# is actually rather less awful than java [21:26:48] <DonDiego> and don't ask me about anything ffmpeg-related, my email is bust :) [21:27:13] <elenril> less awful than java << that carries no information [21:27:25] <Flameeyes> elenril: C++ is more awful than java [21:27:37] <elenril> is it? [21:27:38] <mru> depends [21:27:42] <elenril> you can use it like C [21:27:49] <elenril> then it's certainly less awful than java [21:27:49] <mru> in c++ you're not forced to do all that crap [21:27:53] <mru> people just do it anyway [21:28:04] <Flameeyes> elenril: C++ used as stroustrup and company wants it to be done is much more awful than java [21:28:11] <mru> oh, for sure [21:29:28] <Dark_Shikari> BBB: ugh [21:29:29] <Dark_Shikari> in vp8.c [21:29:30] <Dark_Shikari> if (!nnz4) break; [21:29:35] <Dark_Shikari> we're only breaking out of the inner loop. [21:29:37] <Dark_Shikari> oooops. [21:29:44] <Dark_Shikari> I want a break statement that breaks out of two loops. [21:30:10] <elenril> goto! [21:30:12] <Flameeyes> Dark_Shikari: that's called goto [21:30:15] <Dark_Shikari> I know [21:30:23] <Dark_Shikari> But then I have to start making labels [21:30:24] <Dark_Shikari> end1 [21:30:26] <Dark_Shikari> end2 [21:30:27] <Dark_Shikari> end3 [21:30:31] <Dark_Shikari> because labels aren't scoped. [21:30:50] <Flameeyes> after_$action [21:30:55] <Flameeyes> or done_$action [21:31:08] <Dark_Shikari> after_for [21:31:10] <Dark_Shikari> after_for1 [21:31:12] <Dark_Shikari> after_for [21:31:14] <Dark_Shikari> *after_for2 [21:31:20] <Flameeyes> the for is doing something isn't it? [21:31:22] <Dark_Shikari> true [21:31:54] <Flameeyes> done_parsing, done_checking, found_maximum ... [21:40:12] <Dark_Shikari> another problem [21:40:14] <Dark_Shikari> libavcodec/vp8.c:1293: error: label at end of compound statement [21:40:19] <Dark_Shikari> you can't put a label at the end of a {} block [21:41:43] <mru> put a ; after [21:42:06] <Dark_Shikari> chroma_idct_end: ; makes me want to stab myself [21:42:17] <mru> then stab yourself and write it [21:43:32] <Flameeyes> I usually add it _after_ the {} block [21:43:57] <Dark_Shikari> the structure is: [21:43:58] <mru> that doesn't work if the block is a loop [21:44:21] <Dark_Shikari> for0 { if1 { if2 { for3 { for4{ stuff } } } } } [21:44:28] <Dark_Shikari> we need to break out of "stuff" and go to the next iteration of "for0" [21:44:28] <mru> if you have triple-nested loops and want to break from the innermost and continue the outer, that's the sane way [21:44:49] <Flameeyes> mru: right sorry I didn't consider that [22:20:22] <kierank> http://www.cnx-software.com/2011/03/09/video-wall-with-beagleboards-and-ffmp... [22:24:24] <roxfan> oh i saw that one at fosdem [22:24:49] <Compn> i think mru owns one of those [22:25:17] <mru> av500 owns the displays of the mark 1 aka "the beast" [22:25:24] <kierank> mru is mentioned in the video [22:28:05] <Shu> the age limit on GSoC is still bugging me ;-; [22:28:28] <mru> paying minors is always a hassle [22:28:40] <Shu> by the time i get paid it's okay [22:28:41] <kierank> Shu: did you get your t-shirt [22:28:42] <Shu> just not at the start [22:28:46] <Shu> i did lol [22:28:52] <kierank> got mine today in a massive box [22:29:00] <mru> or should I say minors are such a hassle... [22:29:13] <Shu> kierank: mine was XXL <_< [22:29:19] <Shu> kierank: forgot to say what size [22:29:19] <kierank> mine was too small [22:29:31] <kierank> should have chosen medium [22:29:39] <Shu> did you get small? [22:29:46] <kierank> yup [22:30:09] * kierank thought it was going to be american small [22:30:12] <Shu> i shoulda gotten small [22:30:40] <kierank> Shu: you could come up with an "arrangement" with someone for gsoc [22:30:43] <mru> kierank: I made the same mistake with gsoc last year [22:30:45] <kierank> if you catch my drift [22:31:06] <Shu> i do have a job this summer [22:35:08] <Shu> oh, one of the projects is optimzing h264. [22:54:43] <kierank> I wonder if kshishkov will be interested in reverse engineering Harmonic RTP [23:03:06] <Flameeyes> Harmonic RTP? [23:03:33] <kierank> yes they seem to have made their own proprietary implementation [23:04:02] <Flameeyes> used where? [23:04:13] <kierank> in harmonic products [23:05:04] <kierank> and also i need to write/find a way of making ffmpeg just open a udp port and accept udp/rtp data [23:05:07] * Flameeyes doesn't know harmonic [23:05:24] <kierank> big broadcast company [23:05:43] <mru> from what little I've seen, they seem as annoying as any other such company [23:07:23] <Flameeyes> kierank: uhm based off where? /me really never heard of it and wikipedia doesn't help [23:07:32] <kierank> USA [23:07:51] <Flameeyes> that explains it [23:08:39] <kierank> there seems to be a dll with the protocol in it [23:08:44] <kierank> and some documentation of the api [23:21:12] * lu_zero is pondering to write a small subset of rtp/rtsp in javascript... [23:21:19] * lu_zero should go back to sleep [23:28:09] <Sean_McG> o_O; [23:30:06] <lu_zero> Sean_McG: consider it an inside joke [23:30:11] <Sean_McG> will do [23:30:14] <Sean_McG> ;) [23:30:30] <lu_zero> even if it's feasible and shouldn't be _that_ bad [23:31:11] <lu_zero> (given you hardcode mkv headers)