[01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:bd8d28e2d271: avcodec/hnm4video: check dimensions for validity [01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:5c4aa72b75c1: avformat/hnm: check chunk_size == 0 [01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:ffe31c654d0e: avcodec/hnm4video: check writeoffset in decode_interframe_v4a() [01:28] <llogan> how can i get access to files in upload.ffmpeg.org? [01:33] <BBB> hah it compiles [01:33] <BBB> that's about time [01:33] <BBB> ofc it crashes, but that's fixable [01:39] <beastd> BBB: congrats! keep on going :) [03:01] <Compn> hmmm llogan [03:01] <Compn> i thought i sent him infos [09:58] <cone-821> ffmpeg.git 03Reimar Döffinger 07master:97a0bad87c8d: Add --enable-rpath option to add -Wl,-rpath to pkg-config files. [12:18] <cone-821> ffmpeg.git 03Diego Biurrun 07master:c16bfb147df8: swscale: x86: Consistently use lowercase function name suffixes [12:18] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:8733b363ac3b: Merge commit 'c16bfb147df8a9d350e8a0dbc01937b78faf5949' [13:29] <ubitux> i don't understand this vdpau thing& [13:30] <ubitux> why isn't it an output device like sdl & xv? [13:30] <ubitux> also, what's the use case? [13:31] <nevcairiel> what vdpau thing [13:31] <ubitux> what has just been comitted to avconv [13:31] <nevcairiel> oh that [13:31] <ubitux> vdpau "decoding" [13:31] <ubitux> but with x11 stuff [13:31] <nevcairiel> isnt that just an implementation of the hwaccel [13:32] <ubitux> there are 2 things about vdpau; decoding, and presentation, right? [13:32] <nevcairiel> primary motiviation was being able to test hwaccels [13:32] <nevcairiel> no idea [13:32] <ubitux> this one seems to be about presentation [13:33] <ubitux> well i don't even get how it works, so i'll wait for the merge [13:34] <nevcairiel> i dont know stuff about vdpau, but it looks like it does about the same things you would do when you implemented dxva hwaccel decoding [13:35] <ubitux> it looks like something that belongs in ffplay to me but well [13:36] <nevcairiel> such APIs usually require an X session to function, which is where the X11 stuff comes in i guess [13:36] <ubitux> we already have some accelerated *decoding* through the <codec>_<accel> [13:36] <ubitux> ok [13:36] <nevcairiel> those codecs are ugly hacks and shouldnt exist [13:36] <ubitux> ah, they're meant to be replaced by this new thing? [13:37] <nevcairiel> i dunno, since libav doesnt really have th em [13:37] <ubitux> they do [13:37] <ubitux> at least they show up with ./configure --list-hwaccels [13:37] <nevcairiel> and what was added here just makes use of those hwaccels [13:38] <nevcairiel> since you cant just enable it without user-app code to handle it [13:38] <nevcairiel> or well, of one hwaccel [13:39] <nevcairiel> which is why the hwaccels are generally never tested properly [13:39] <nevcairiel> since no native ffmpeg/libav tool supported them [13:41] <ubitux> mmh [13:42] <cone-821> ffmpeg.git 03Tim Walker 07master:b53285462263: ac3: implement request_channel_layout. [13:42] <iive> one of hwaccel work like parsers. the applications links to x11, allocates buffers, the avcodec just parses packets and extrancts the relevant bitstreams. [13:42] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:2e5780a53f43: Merge commit 'b53285462263ef8a795f0e289abd5799b4c57652' [13:42] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:2cbf27b08a49: libavcodec/ac3dec: fix channel_layout [13:42] <ubitux> indeed, it seems i can't naively do ffmpeg -c:v h264_vdpau -i foobar.mp4 -f null - [13:43] <iive> other hwaccel (vaapi i think) do the allocation on their own, this however means that avcodec should link to X and call X functions. [13:43] <nevcairiel> i thought that might still work, since michael didnt merge the removal of the old vdpau decoders [13:43] <ubitux> i have some decoding errors here [13:43] <ubitux> "no frame!" [13:43] <ubitux> "decode_slice_header error" [13:43] <nevcairiel> hm, i dunno, no idea if it needs user app code as well [13:43] <ubitux> and various other errors following [13:44] <nevcairiel> there are others that can work out of the box [13:44] <iive> now, some of the hwaccels can do the decoding on card, then read it back to the system memory. [13:44] <nevcairiel> vda i think has one [13:44] <iive> some don't. [13:44] <nevcairiel> but they really shouldnt exist [13:44] <ubitux> all that hwaccel stuff looks quite messy :) [13:44] <nevcairiel> either the user app should make use of the AVHWAccel, or someone should propose a HWAccel v2 that takes care of all plumbing as well [13:44] <ubitux> btw, somehow unrelated, how hard is the move from sdl to sdl2? [13:45] <ubitux> (wondering about our ffplay) [13:46] <iive> i though the plan is putting the X functions into libavdevice, It already handles X functions and it could be provided as default allocation/decoding for the applications. [13:46] <ubitux> http://wiki.libsdl.org/MigrationGuide mmh [13:46] <wm4> ubitux: yeah that stuff was supposed to test hwaccel [13:47] <wm4> ubitux: and for testing it's probably also better to actually read the decoded data back to memory [13:47] <wm4> so you can verify the results [13:47] <wm4> hacking vdpau display into ffplay would probably be half a nightmare [13:48] <wm4> and the old pseudo decoders like vdpau_h264 were indeed removed from Libav, but not from ffmpeg [13:48] <wm4> no idea why [13:48] <wm4> they're redundant [13:48] <ubitux> i see them in libav [13:48] <wm4> they just have a slightly different API [13:48] <wm4> where [13:48] <ubitux> maybe it was an old checkout, just a sec [13:48] <wm4> hm or was it h264_vdpau [13:48] <iive> well, in case you want to have vdpau decoding that outputs yuv420 raw image, how are you going to do it? [13:49] <ubitux> wm4: 13:37:38 <@ubitux> at least they show up with ./configure --list-hwaccels [13:49] <wm4> iive: do the same thing as avconv just did [13:49] <wm4> iive: and in general, this is completely useless and slow [13:49] <wm4> for video conversion uses I mean [13:49] <iive> ?? [13:49] <wm4> ubitux: ok, hwaccel != pseudo decoder [13:49] <wm4> as in AVCodec [13:49] <wm4> iive: ??? [13:49] <iive> please explain. [13:50] <wm4> what's there to explain [13:50] <wm4> it's just slow [13:50] <wm4> slower than software decoding, usually [13:51] <iive> well, it is not done by the cpu, so more cpu for the encoder :P [13:51] <cone-821> ffmpeg.git 03Tim Walker 07master:d4df02131b55: ac3dec: Remove write-only channel_layout field from AC3DecodeContext [13:51] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:94194bdcd7bf: Merge commit 'd4df02131b5522a99a4e6035368484e809706ed5' [13:51] <wm4> iive: it also lets the cpu wait [13:52] <wm4> well, not sure, maybe ffmpeg has some multithreading weirdness so that this won't matter [13:52] <wm4> but all in all supporting readback seems to be rather questionable [13:52] <wm4> so it's fine if this is not natively supported by libavcodec [13:53] <iive> well, there is no reason for the readback to be slow. Unless the raw image is in nv12 form in the card and the drivers do naive nv12->yv12 conversion. [13:53] <iive> pcie bandwidth is big enough in both directions, afaik [13:54] <wm4> there are various reasons why this would be slow [13:54] <wm4> including hw decoders made for realtime use, not for being as fast as possible [13:54] <wm4> +being [13:54] <wm4> but yeah, this exposed pathetic libswscale speed for nv12->yv12 [13:55] <ubitux> this should be fixed [13:55] <wm4> patches welcome [13:55] <ubitux> no i mean, it's fixed [13:55] <iive> as I said, you don't need it to be fast, in order to be useful. There are just too many presumptions based on the current perks, that could be easily improved. [13:55] <wm4> didn't elenril complain it's still slow? [13:55] <iive> i though michael fixed it. [13:55] <ubitux> wm4: dunno [13:55] <iive> the swscale conversion. I remember some commits for nv12/21 [13:56] <wm4> also I remember mentioning this idea (testing hwaccel through readback) with reimar on the mailing list, and he considered it not useful for multiple reasons [13:56] <wm4> ubitux, iive: yes AFAIK elenril used these patches [13:57] <wm4> iive: when we implemented proper vda support (native display instead of readback via the ffmpeg "decoder") we actually observed 2-2.5x reduction in CPU usage [13:57] <wm4> I mean, implemented it in mpv [13:57] <wm4> ffmpeg has a proper vda hwaccel [13:59] <iive> once again. this is not theoretical limitation. [14:01] <iive> pcie bandwidth should have same in both directions. This means that it should take the same cpu utilization to upload yv12 image, as it is to read a raw image to the card. [14:01] <wm4> I don't think it's that simple [14:01] <iive> if there is such huge slowdown, then it is probably driver issue, that tries a naive conversion. [14:01] <wm4> GPU memory is a weird thing [14:01] <wm4> for example, I'm pretty sure vdpau/nvidia stores video internally as separate fields, and probably even in a tiled way [14:02] <iive> this could be improved by the driver. [14:02] <iive> well... then swscale would support tiled formats too. [14:02] <pigoz> wm4: iirc ffmpeg's vda decoder also does a memcpy [14:02] <pigoz> so readback + memcpy [14:04] <iive> look. it is ok to don't use a feature that is slow. [14:05] <iive> it is not OK to design an API in a way that doesn't allow that feature at all. especially when there is no theoretical reason for it to be slow. (Some features are slow on theory too...). [14:05] <wm4> what if it's slow in practice [14:06] <iive> then, find out why it is slow in practice. [14:08] <iive> sometimes it is slow, because nobody uses it. if you don't use it, it would never be optimized. [14:08] <wm4> sigh [14:09] <wm4> nobody would introduce such complicated APIs like they did with hardware decoding if the easier way (i.e. readback) would have been just as fast [14:09] <wm4> but it's designed this way because shuffling memory from the GPU to the CPU is inherently slow [14:10] <iive> it is not just as fast. because in the best case it involves 2 memcpy. one from the card and one to the card. [14:10] <iive> it doesn't mean it is not useful. [14:11] <pigoz> iive: it is slow because whoever contributed to mplayer's is misguided and just wants their gui to work with shitty mmap. since they need readback anyway, they thought it was a good idea. [14:11] <pigoz> in practice it's so wasteful that software decoding is almost as fast! [14:40] <cone-821> ffmpeg.git 03Anton Khirnov 07master:07fd0a221928: avconv: add infrastructure for using hwaccels [14:40] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:62e10c375968: Merge commit '07fd0a22192805d56c635eb294dc26b0a54ae325' [14:52] <cone-821> ffmpeg.git 03Anton Khirnov 07master:7671dd7cd7d5: avconv: add support for VDPAU decoding [14:53] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:3e641b4842b8: Merge commit '7671dd7cd7d51bbd637cc46d8f104a141bc355ea' [15:00] <cone-821> ffmpeg.git 03Alexandra Khirnova 07master:6f270da61b8c: libschroedingerenc: do not assert on values from external libraries [15:00] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:f63ee2aa14ec: Merge remote-tracking branch 'qatar/master' [17:05] <ubitux> meh #2835 is fun [17:13] <ubitux> -hwaccel none ’ 530 fps [17:13] <ubitux> -hwaccel vdpau ’ 50 fps [17:13] <ubitux> fun [17:21] <ubitux> it crashes if hwaccel can not be initialized [17:24] <wm4> anton already has a patch for this [17:30] <ubitux> it's not an assert [17:31] <ubitux> it doesn't happen all the time (threading related) [17:32] <ubitux> http://pastie.org/pastes/8503519/text [17:33] <nevcairiel> its possible threading with hwaccel is broken in ffmpeg, i dont think it was ever tested [17:34] <ubitux> mmh? [17:35] <nevcairiel> the real question however is, why is exit_program being called from a frame worker thread? :p [17:35] <nevcairiel> that seems like bad karma [17:38] <ubitux> it's hard to reproduce with valgrind [17:38] <ubitux> it happens with libav as well [17:43] <wm4> nevcairiel: supposedly, vlc uses threading + hwaccel just fine [17:44] <wm4> mplayer also tries to do, but its code is literally full of hacks, including comments that curse libavcodec's threading behavior [17:45] <nevcairiel> comments which are probably completely out of date now [17:45] <wm4> likely [17:59] <cone-821> ffmpeg.git 03James Zern 07master:6819eaf31bf8: libvpxdec: set CODEC_CAP_DR1 for vp9 [17:59] <cone-821> ffmpeg.git 03James Zern 07master:34e32d646413: libvpxenc: update cpu-used default [18:22] <rexbron> Does ffmpeg copy over all metadata from a Broadcase Wave file when trimming? Timecode and Frame Rate from a Sound Devices 664T got stripped out. It show up in ffprobe but -codec:a copy only seems to carry over some of it. Would uploading a sample of the input and output to the tracker be helpful? [18:27] <JEEB> there was IIRC a way to force ffmpeg to copy over all metadata as well, codec:a copy should have copied all of the in-band actual audio data [18:30] <rexbron> JEEB: I'll file a bug on the tracker [18:31] <JEEB> try the full metadata copy at first [18:31] <JEEB> since -c/codec:a doesn't really touch that [18:32] <rexbron> JEEB: I'm not familiar with how to do that [18:33] <JEEB> -map_metadata <number of the input> [18:34] <JEEB> as far as I can see [18:36] <rexbron> JEEB: Same results [18:36] <JEEB> k [18:36] <rexbron> I wonder if it is because the wav muxer doesn't support the writting of those fields yet [18:37] <JEEB> anyways, search for similar issues on trac, and if there's none feel free to report it with a sample [18:37] <JEEB> possibly [18:38] <rexbron> hmm, well it shows up in the output metadata of the encoding ffmpeg command, but ffprobe doesn't see it and neither does Davinci Resolve [18:42] <rexbron> ffprobe also sees the metadata in the original file [18:46] <rexbron> what is the ffmpeg ftp server for samples? Trac limits attachments to 2.5mb [18:50] <wm4> apropos wav, is ac3 in wav standard? [18:50] <wm4> especially if it uses the same format tag as s16? [19:05] <kierank> yes [19:05] <kierank> it's designed to go over spdif or aes3 [19:05] <kierank> neither of those cables have any concept of data format [19:05] <kierank> they just send out stereo bytes [19:05] <kierank> s/bytes/pairs [19:06] <JEEB> btw, how does lavf/lavc handle possible spdif content muxed into a PCM audio track? [19:07] <wm4> kierank: interesting and disgusting [19:07] <JEEB> can I just push it out of the demuxer as PCM, or do I have to do something special? [19:07] <wm4> yes that would be interesting to know [19:07] <kierank> should work as pcm [19:07] <JEEB> ok [19:07] <kierank> alignment is important though [19:08] <JEEB> then I can pretty much rewrite the earthsoft dv demuxer stuff compared to the Japanese guy's patch [19:08] <JEEB> because he had some really funky checks in the demuxer for various spdif'd stuff [19:08] <JEEB> (IIRC unrelated to alignment) [19:09] <kierank> alignment is effectively the pts [19:09] <JEEB> alrighty [19:11] <JEEB> oh right, the demuxer tries to extract it I think... :| not something I'd do in the demuxer to be honest if lavc in general can handle it [19:11] <JEEB> /* search for IEC 61937 Burst-preamble */ [19:11] <JEEB> etc. [19:12] <wm4> well, the demuxer has to signal the correct codec [19:12] <wm4> because on the decoder side, it's too late for that [19:13] <JEEB> ok, so "should work as pcm" doesn't mean that [19:13] <wm4> AFAIK not, if you're talking about what AVStream->codec will identify [19:59] <kierank> JEEB: yes the burst preamble is what signals the codec [19:59] <kierank> lavc can't deal with it [19:59] <JEEB> ok [21:07] <cone-984> ffmpeg.git 03Michael Niedermayer 07master:321b33876262: avcodec/hnm4video: allocate frame only when theres a coded frame [21:07] <ubitux> HOSTCC doc/print_options.o [21:07] <ubitux> HOSTCC? really? oO [21:14] <ubitux> BBB: since the dc-only patch, most of the time is spent in 32x32 and the loop filters [21:14] <ubitux> they really are slow [21:14] <ubitux> i'm almost tempted to look at them :p [21:23] <ubitux> BBB: i'm going to start on lf instead of idct 16 [21:43] <ubitux> BBB: http://b.pkh.me/0001-avcodec-vp9dsp-remove-unused-stride-parameter-in-loo.pa... opinion? [21:55] <wm4> why are people trying to coerce a muxer API into a video player output API [21:55] <wm4> his deserves the "fucking retarded" label [21:55] <wm4> +this [21:57] <Plorkyeran> playing and muxing are conceptually vaguely similar things [21:57] <Plorkyeran> and programmers love reusing abtractions [22:02] <BBB> ubitux: sure [22:03] <BBB> ubitux: and yes 32x32 I know [22:03] <ubitux> BBB: so what's the trick with lf? [22:03] <ubitux> i'm looking at loop_filter_h_4_8() [22:03] <BBB> ubitux: to make things slightly easier for us to develop step-by-step, I was considering the following: have a (non-vp9dsp) set of function ptr tables that take a VP9DSPContext argument, and then have them select which specialization to take [22:03] <ubitux> the c version looks like this: http://pastie.org/8503989 [22:04] <BBB> the default implementation for dc-only would be your specialcase code, and for all other cases the current c base full versions [22:04] <BBB> but then we could easily specialize a 2x2 32x32 or 4x4 16x16 without needing to dig our eyes out to complete all assembly before it can be committed [22:04] <BBB> that would help e.g. with writing a super-fast ssse3 dc-only for all [22:04] <BBB> that would speed up 16x16 and 32x32 by a lot also [22:05] <BBB> and a 2x2 and 4x4 does cover most practical 32x32 cases [22:05] <BBB> we can leave the rest as C then [22:05] <BBB> wdyt? [22:05] <BBB> the trick with lf is: do the vertical filter (horizontal edge between a top/bottom block) first [22:05] <ubitux> will the dc only really benefit from the asm versions? [22:06] <BBB> no they all will [22:06] <BBB> but the dc is easier to write [22:06] <BBB> I'm trying to get stuff out faster rather than slower, and adjust code/development to that end [22:06] <BBB> then the filter: you'll notice there's 8px 4/8/16wd versions [22:06] <ubitux> main benefit of this would be to ease the writing of those functions [22:07] <ubitux> so i'm not against [22:07] <BBB> these are not called often but meant for mmx or so [22:07] <BBB> then there's 16px functions, same idea [22:07] <BBB> they are 16wd, or a mix2 of 4/4 or 8/8 or 4/8 or 8/4 wd [22:07] <ubitux> right [22:07] <BBB> that's because edges between these types of lfs only have a length of 8px [22:08] <BBB> so we merge 2 so we can do sse2/ssse3 (16byte) registers [22:08] <BBB> do everything in bytes, obviously [22:08] <BBB> ignore 8px maybe, focus on 16px first (maybe 4wd) [22:08] <BBB> and you'll see it's not hard to do it without stack on x86-64 [22:09] <BBB> 8wd is basically 'do some threshold trick to see whether we do 8wd or 4wd loopfilter' (i.e. 4wd is a strict subset of 8wd) [22:09] <BBB> runtime selected [22:10] <ubitux> ETOOMUCHINFO [22:10] <ubitux> just a sec [22:10] <BBB> oh [22:10] <BBB> well, start with 4/4wd 16px [22:10] <BBB> it's easy [22:10] <BBB> or, well, about as easy as a loopfilter will ever get [22:11] <ubitux> i was ignoring the 16 and mix2 so far [22:11] <ubitux> since 16 was calling 8 [22:11] <BBB> that's just a c'ism [22:11] <BBB> ignore c, it's stupid [22:11] <ubitux> mmh [22:12] <BBB> I prepared it that way for asm purposes [22:12] <BBB> sse2/ssse3 is 16bytes right [22:12] <BBB> so we want to do 16 bytes (if 1 byte is 1 pixel) per call to the simd function [22:12] <BBB> that's why we mix 2 [22:12] <ubitux> but, the 8 versions are supposed to be called as well, right? [22:12] <BBB> yes, but not as often [22:12] <BBB> look at the backtrace of the callers [22:13] <ubitux> oh indeed [22:13] <BBB> most of the time, the backtrace of 8 is 16 [22:13] <BBB> once in a while, it's mix2 [22:13] <BBB> very rarely is it called in and by itself [22:13] <BBB> that's expected, it makes sense for non-random noise content [22:14] <BBB> (non-'random noise') [22:14] <ubitux> ok [22:14] <ubitux> al'right, so i need to focus on 16 directly [22:16] <ubitux> 22:08:19 <@BBB> do everything in bytes, obviously // what do you mean? no simd? [22:16] <ubitux> oO [22:16] <BBB> byte-wise simd [22:16] <BBB> i.e. use all byte instructions [22:16] <BBB> paddb, paddusb, etc. [22:16] <ubitux> ah, ok [22:17] <ubitux> that's cool if i can do that :) [22:17] <BBB> that way you can do it loopless [22:21] <cone-984> ffmpeg.git 03Clément BSsch 07master:bea93944653f: avcodec/vp9dsp: remove unused stride parameter in loop_filter(). [22:21] <ubitux> ok [22:22] <ubitux> let's try this then [22:22] <BBB> \o/ [22:22] <BBB> I have an almost-working patch for mt [22:22] <BBB> that is, it works in single-threaded mode [22:22] <ubitux> haha [22:22] <BBB> (I know, that sounds entirely useless) [22:22] <BBB> (but really, it's quite something IMO) [22:23] <ubitux> :) [22:30] <ubitux> BBB: v version will be calling h version with a transpose? [22:30] <ubitux> or they will be more [22:30] <ubitux> ? [22:31] <BBB> exactly right [22:31] <BBB> I don't know how we'll do a 16x16 transpose btw [22:31] <BBB> but we'll figure that out [22:31] <BBB> probably 2x16x8 or so [22:32] <BBB> or maybe imaginatively speaking it's not that hard, never thought much about it [22:52] <durandal_1707> gmake: *** No rule to make target ibavcodec/dct32_fixed.o'. Stop. [22:53] <durandal_1707> gmake: *** No rule to make target `libavcodec/dct32.c', needed by `libavcodec/dct32_fixed.o'. Stop. [22:55] <ubitux> durandal_1707: the dependency thing again [22:55] <ubitux> you need to make distclean / git clean -fdx [22:56] <ubitux> or just edit/drop the .d [22:59] <nevcairiel> I dont get why people dont just clean when they get such an error instead of complain [23:00] <durandal_1707> i dont get why people change stuff [23:02] <nevcairiel> we should totally stop developing, change is bad! [23:03] <durandal_1707> developing is not K&R [23:05] <ubitux> nevcairiel: re-running configure should be enough, but it doesn't work [23:05] <ubitux> those rename are a pita [23:06] <nevcairiel> configure doesnt generate d files, make does, but it fails at tracking changes to its own make files [23:08] <lukaszmluki> Hi, is Stefano online? [23:09] <ubitux> he left a few hours ago (nickname: saste) [23:09] <nevcairiel> he doesnt appear to be here right now [23:09] <lukaszmluki> maybe some else know... he mentioned "custom widget filter", do you know what it is? [23:10] <ubitux> which thread? [23:10] <lukaszmluki>  Move ffplay engine to separate library, 7th post [23:12] <durandal_1707> ffprobe.c:348:15: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] [23:17] <ubitux> lukaszmluki: i guess he just invented a name for this potential special purpose filter [23:18] <lukaszmluki> so it doesn't exist yet? :D [23:18] <ubitux> yes, it seems to be your job :) [23:19] <lukaszmluki> ok, i'll try to catch him tommorow to confirm that, but I greped and nothing similar to it found :] [23:19] <lukaszmluki> ok, thx [23:25] <cone-984> ffmpeg.git 03Paul B Mahol 07master:638d79a9d080: ffprobe: use designated initializer for AVClass [23:36] Action: BBB agrees with durandal_1707 [23:37] <BBB> I don't care about whether people do k&r or not, but please let's not call it development [23:37] <Daemon404> let's not call it k&r [23:37] <ubitux> let's not [23:37] <BBB> diego&r? [23:37] <ubitux> diego&luca&koda [23:44] <lukaszmluki> what is k&r? [23:57] <{V}> lukaszmluki, Kernighan and Ritchie probably. [00:00] --- Sun Nov 24 2013