[FFmpeg-devel-irc] IRC log for 2010-08-29

[irc at mansr.com]

[00:02:19] <BBB> lu_zero: (A) it is nicer to read and (B) it makes marking registers as clobbered much easier than inline asm (particularly because most inline asm uses multiple smaller blocks instead of one big block, in which case it's impossible to mark registers since they'd lose their value at the end of the block) - this isn't an issue on osx/linux, but is a big issue that prevents using optimizations on win64, so it's a big issue for apps such as vlc
[00:04:12] <lu_zero> uhm
[00:04:41] <BBB> you know, like it or not, ~90% of people use windows :-p
[00:05:01] <lu_zero> so instead of merging blocks or make gcc preserve register values
[00:05:11] <BBB> it's not that easy
[00:05:12] <lu_zero> you rewrite the whole function ^^
[00:05:16] <BBB> it's C mixed with asm
[00:05:34] <BBB> I didn't rewrite it, I just copied it
[00:05:57] <lu_zero> from the gcc generated code?
[00:05:57] <BBB> "statement src, dst\t\n\r" \ becomes statement dst, src
[00:06:02] <Dark_Shikari> lu_zero: we only have a single developer who is willing to work with inline asm
[00:06:06] <BBB> no, from the inline source
[00:06:08] <Dark_Shikari> and he isn't doing any actual work
[00:06:09] <Dark_Shikari> end of story
[00:06:22] <BBB> yeah, that ^^^
[00:06:33] <BBB> loren, jason, me, vitor and so on can all read and write yasm
[00:06:36] <BBB> it's easier to maintain
[00:06:42] <BBB> I'm sure more people can write yasm
[00:06:49] <BBB> it'll get more developers interested in optimizing
[00:07:18] <BBB> if michael dies one day (god forbid), half of ffmpeg is unmaintained and a quarter is not-understood ;)
[00:07:33] <lu_zero> as I stated "optimizing" in asm is a single target endeavour.
[00:07:37] <Dark_Shikari> "gets hit by a bus" is the technical terminology
[00:07:49] <Dark_Shikari> lu_zero: what do you mean?
[00:08:34] <lu_zero> that I'd rather see C optimizations
[00:08:46] <Dark_Shikari> C alone is useless
[00:08:47] <BBB> right, but you need both
[00:09:10] <lu_zero> and once you got intrinsics up to a working state I'd move back to them
[00:09:12] <Dark_Shikari> it does no good to optimize the primary C functions if 90% of your time is spent in 3 DSP functions that are 4 lines long
[00:09:20] <Dark_Shikari> intrinsics are worthless even if the compiler is perfect
[00:09:40] <lu_zero> Dark_Shikari: vmx ones shown me the opposite ^^
[00:09:41] <Dark_Shikari> First of all, they don't solve the problem of targets
[00:09:49] <lu_zero> how so?
[00:09:55] <Dark_Shikari> the only way to get good intrinsic performance is to use arch-specific ones
[00:10:01] <Dark_Shikari> generic vector SIMD systems ALWAYS SUCK.
[00:10:14] <Dark_Shikari> because every arch has its unique, bizarre, cool instructions that nothing else has quite the same.
[00:10:19] <Dark_Shikari> and you can't magically use them
[00:10:23] <Dark_Shikari> without explicitly doing so
[00:10:29] <BBB> pshufw <3
[00:10:29] <Dark_Shikari> See Orc.
[00:10:38] <Dark_Shikari> afaik, Yuvi wrote his own ffdirac
[00:10:41] <Dark_Shikari> it's like 2x faster than orc
[00:10:42] <BBB> hehe, I was about to mention orc, that's liboil, right?
[00:10:46] <Dark_Shikari> er, than the real dirac
[00:10:48] <Dark_Shikari> BBB: no
[00:10:51] <Dark_Shikari> it's to replace liboil
[00:10:58] <Dark_Shikari> orc is an extremely barebones generic simd system
[00:10:59] <BBB> ...
[00:11:04] <Dark_Shikari> it can't even do things like tranposes iirc
[00:11:12] <lu_zero> ehm
[00:11:21] <lu_zero> then it's unfair evaluating orc now
[00:11:33] <Dark_Shikari> now, I don't doubt a generic simd system can be better than orc is now
[00:11:39] <Dark_Shikari> And it's useful for one reason
[00:11:46] <Dark_Shikari> you can write once, and get _half-decent_ opts on a dozen architectures.
[00:11:55] <Dark_Shikari> They won't be anywhere near optimal in many cases, but they'll be far better than C.
[00:11:58] <BBB> I guess generic simd sounds fantastic and if one ever exists that's great, I'll use it
[00:12:04] <BBB> but they don't exist... :-p
[00:12:04] <Dark_Shikari> That is, if an MC function takes 1000 clocks in C
[00:12:08] <Dark_Shikari> and 70 clocks in optimal asm
[00:12:12] <Dark_Shikari> orc might get you 150.
[00:12:15] <lu_zero> BBB: gcc provides one, stay clear of it
[00:12:17] <Dark_Shikari> compared to the C, that's really nice.
[00:12:27] <Dark_Shikari> And if it's on an arch you'll never ever write real simd for, that's nice too.
[00:12:35] <Dark_Shikari> But it's not a replacement for writing the code properly.
[00:12:43] <lu_zero> agreed
[00:12:48] <Dark_Shikari> Now, the primary problem with arch-specific intrinsics
[00:13:00] <Dark_Shikari> even if the compiler was perfect
[00:13:05] <Dark_Shikari> is that the place a barrier between you and the output asm
[00:13:07] <Dark_Shikari> For example
[00:13:21] <Dark_Shikari> suppose you're writing some SIMD, and you realize that the way you've written it, it'll need 10 xmm registers, and you only have 8.
[00:13:28] <Dark_Shikari> So you'll have to throw stack stores/loads all over the place.
[00:13:37] <Dark_Shikari> But you realize that if you just tweak a few small things, you can get down to 8.
[00:13:45] <Dark_Shikari> If you wrote intrinsics, you'd never know that your code actually took 10 registers.
[00:13:52] <Dark_Shikari> And how many it took would depend on the compiler's mood that day.
[00:14:00] <Dark_Shikari> So you wouldn't be able to go tweak it to eliminate the stack accesses.
[00:14:05] <lu_zero> that's up to the compiler
[00:14:17] <Dark_Shikari> the thing is, "tweaking it" is an algorithmic change
[00:14:19] <Dark_Shikari> a change the compiler cannot make
[00:14:31] <lu_zero> I mean emit a warning
[00:14:43] <BBB> it might be on purpose
[00:14:45] <BBB> warning is bad
[00:14:45] <Dark_Shikari> there are compilers that emit warnings about needing the stack?
[00:14:50] <Dark_Shikari> that would be a lot of warnings
[00:14:54] <BBB> :)
[00:15:04] <BBB> warning, int i is located on the stack
[00:15:16] <BBB> warning, for (int i=0;i<h;i++) access stack loads of times
[00:15:18] <Dark_Shikari> or in the case of gcc
[00:15:26] <Dark_Shikari> "warning: everything has been tossed on the stack, for no reason"
[00:15:38] <BBB> yeah it tends to do that
[00:15:45] <BBB> and then directly after storing it, it loads it again
[00:15:53] <lu_zero> Dark_Shikari: I think openmp or tree-vectorze had some warning about failing to do stuff like that
[00:16:03] <Dark_Shikari> tree-vectorize is hilarious
[00:16:11] <lu_zero> is a wishful thinking
[00:16:24] <lu_zero> same for openmp
[00:16:38] <Dark_Shikari> what's openmp, that thing that automatically turns loops into threads?
[00:16:51] <lu_zero> more or less
[00:16:53] <BBB> lu_zero: well, keep working on good optimization systems, I'll always use the best tool for the job... (un?)fortunately, today that's yasm
[00:16:59] <BBB> and yasm is quite pleasant
[00:17:08] <Dark_Shikari> oh, also, yasm lets you do certain things that a compiler will never, ever be able to output
[00:17:13] <Dark_Shikari> at least not with C
[00:17:18] <BBB> SWAP!!!
[00:17:19] <lu_zero> Dark_Shikari: I don't doubt that
[00:17:21] <Dark_Shikari> (or, better said, at least not with anything higher level than asm)
[00:17:23] <Dark_Shikari> Specifically
[00:17:25] <Dark_Shikari> computed jumps
[00:17:32] <Dark_Shikari> no compiler I have ever seen is capable of doing that.
[00:18:14] <lu_zero> I guess we digressed a lot
[00:18:22] <BBB> yeah
[00:18:30] <lu_zero> you asked me what I meant with single target
[00:18:36] <Dark_Shikari> speaking of which, computed jumps are awesome
[00:18:42] <Dark_Shikari> every time I do one, I feel extra leet
[00:18:42] <lu_zero> and why I'm concerned about overusing it
[00:18:46] <lu_zero> theheh
[00:18:55] <BBB> is that like jmp x ? thislocation : thatlocation?
[00:18:58] <Dark_Shikari> no
[00:19:11] <Dark_Shikari> lea tmp, [r1+r2*4]
[00:19:14] <Dark_Shikari> jmp/call tmp
[00:19:28] <BBB> segfault?
[00:19:36] <Dark_Shikari> it's like calling a function pointer array, except instead there's no lookup
[00:19:43] <Dark_Shikari> it's used in x264 in two places for cacheline-split stuff
[00:19:43] <lu_zero> with tmp not being a label in any case?
[00:19:47] <Dark_Shikari> correct
[00:19:47] <j0sh> isnt a computed jump basically what a switch statement does
[00:19:51] <Dark_Shikari> j0sh: no
[00:19:52] <Dark_Shikari> that's a jump table
[00:19:59] <Dark_Shikari> computed means there's no table
[00:20:01] <Dark_Shikari> here's a simple example
[00:20:06] <Dark_Shikari> suppose you have code to handle 16 possible alignments
[00:20:07] <lu_zero> j0sh: switch are implemented in  hmm
[00:20:11] <Dark_Shikari> each alignment case is 64 bytes long
[00:20:13] <lu_zero> 3 ways I think
[00:20:14] <Dark_Shikari> and aligned accordingly
[00:20:30] <Dark_Shikari> you jump to (FirstCase + (Alignment*64))
[00:20:45] <BBB> I've seen that once
[00:20:50] <BBB> in a quicktime binary
[00:21:02] <BBB> I think
[00:21:03] <j0sh> hmm ok
[00:21:04] <lu_zero> that is nice till you don't change one case after that
[00:21:08] <lu_zero> and you forget ^^;
[00:21:12] <Dark_Shikari> ?
[00:21:20] <Dark_Shikari> well the cases are just a single macro repeated 16 times
[00:21:24] <Dark_Shikari> and this only even exists because intel is LAME
[00:21:27] <kierank> [01:17] <@Dark_Shikari> no compiler I have ever seen is capable of doing that. --> couldn't you do that with conditional gotos?
[00:21:30] <Dark_Shikari> and pslldq/psrldq/palignr only take immediates
[00:21:41] <lu_zero> ah
[00:21:53] <Dark_Shikari> kierank: that's just a jump table in disguise, and way slower than a jump table
[00:22:09] <Dark_Shikari> you'd have to branch for each one
[00:22:32] * lu_zero see another digression branching out
[00:22:45] <kierank> we need threaded irc
[00:22:45] <Dark_Shikari> there is nothing wrong with digressions
[00:22:47] <BBB> digresisons are fun
[00:22:51] <lu_zero> yup
[00:22:59] <BBB> wasn't google wave supposed to fix irc?
[00:23:03] <BBB> until they canned it
[00:23:06] <kierank> yes
[00:23:13] <kierank> it was meant to fix everything else too
[00:23:20] <lu_zero> but then we'll all know lots of interesting thing
[00:23:20] <Dark_Shikari> just like everything google does
[00:23:31] <lu_zero> but not the main point
[00:23:54] <lu_zero> that's you optimize for one target that might get too specific
[00:24:24] <Dark_Shikari> it's the job of maintainers of other arches to optimize for them
[00:24:57] <lu_zero> so once other similar but not quite appears you might have to spend more than necessary time recycling
[00:25:03] <Dark_Shikari> I do x86.  I don't do ppc.
[00:25:10] <Dark_Shikari> If I do lots of x86, that doesn't take away from ppc.
[00:25:20] <lu_zero> eh eh
[00:25:36] <BBB> if only there was someone caring about ppc
[00:25:42] <BBB> people only care about arm and x86 nowadays
[00:25:54] <j0sh> Dark_Shikari: but won't some things possibly regress in say, whatever comes after nehalem
[00:25:55] <lu_zero> BBB: ppc got less cpus around
[00:25:58] <j0sh> if you optimize too closely
[00:26:15] <j0sh> for the timing of particular instructions, etc
[00:26:18] <lu_zero> j0sh: regress/break/subtly/break in order
[00:26:43] <BBB> j0sh: if that's a reason to not optimize, then what was the point?
[00:26:44] <Dark_Shikari> j0sh: doesn't work that way
[00:26:49] <lu_zero> was fun with Cell
[00:26:54] <Dark_Shikari> "optimizing more" doesn't increase the chance of regression
[00:27:12] <lu_zero> when the C compiler wasn't exactly perfect
[00:27:30] <j0sh> well im referring more along the lines of optimizing already optimized code
[00:27:34] <lu_zero> and you didn't consider which instruction got microcoded and which is not
[00:28:19] <lu_zero> (same happened with g3 vs g4 vs g5 and multiple load/store)
[00:30:09] <lu_zero> Dark_Shikari: if in one target you can use some nifty instructions to do cache manipulation and in the next one those instructions luckily map to nops you just have a regression
[00:30:25] <lu_zero> if you have a nice instruction to wipe a cache line
[00:30:49] <lu_zero> and then in the next cpu the cache line size changes you have surprises ^^
[00:31:27] <Dark_Shikari> that doesn't happen with x86
[00:31:42] <lu_zero> yet
[00:31:44] <Dark_Shikari> "luckily map to nops"
[00:31:48] <Dark_Shikari> no.
[00:31:57] <lu_zero> how so?
[00:31:59] <Dark_Shikari> we do not change our optimization strategy because of some hypothetical thing that "may happen"
[00:32:09] <Dark_Shikari> godzilla may hypothetically eat all of our sse-supporting chips
[00:32:11] <lu_zero> s/may/had/
[00:32:12] <Dark_Shikari> but we don't worry about that.
[00:32:23] <BBB> if the cache size increases, it means we can micro-optimize even better for future cpus
[00:32:50] <BBB> basically the big problem with x86 optimizations is that "soon", there'll always be a "yet newer" set of simd insturctions that you'll have to support
[00:32:59] <Dark_Shikari> anyways you're acting as if somehow development isn't an ongoing process
[00:32:59] <lu_zero> BBB: then you have to branch optimizations
[00:33:01] <j0sh> what about for things like OOE
[00:33:04] <BBB> other than that, I don't think any of the problems you explained exist for lu_zero
[00:33:09] <j0sh> like atom
[00:33:13] <BBB> lu_zero: function pointers, like the dsp setup :)
[00:33:24] <Dark_Shikari> j0sh: for that you have to write a custom version of everything you care about
[00:33:30] <Dark_Shikari> though really, you can get most of the benefit just by not using pshufb
[00:33:31] <lu_zero> BBB: I'm describing what is happening
[00:33:44] <j0sh> yeah i suppose so
[00:33:49] <Dark_Shikari> lu_zero: what color is the sky in your world?
[00:33:50] <lu_zero> Dark_Shikari: and that's why I'm wary of abusing that
[00:33:50] <BBB> what's so bad about pshufb?
[00:33:58] <Dark_Shikari> BBB: 6/6 on atom
[00:34:08] <BBB> now in english?
[00:34:09] <Dark_Shikari> lu_zero: um... it takes one line to say "don't use this on atom"
[00:34:10] <Dark_Shikari> done
[00:34:15] <Dark_Shikari> BBB: um, you know that notation....
[00:34:30] <Dark_Shikari> latency/invthroughput
[00:35:22] <BBB> I've probably seen it and forgotten about it straight after
[00:36:15] <BBB> can someone review my patches? I want to commit and say \o/ yay as the win64 fate results come in
[00:37:24] <Dark_Shikari> maybe a bit later
[00:37:31] <Dark_Shikari> honestly it's prolly fine
[01:09:20] <kierank> hmmm oktoberfest or stockholm, i can't decide where to visit
[01:10:02] <Dark_Shikari> ffbeer
[01:12:32] <kierank> hmmm vienna looks nice as well
[07:53:45] * elenril pokes siretart 
[07:53:52] <elenril> what happened to x264 in debian main?
[10:17:44] <CIA-11> ffmpeg: mstorsjo * r24962 /trunk/libavformat/rtsp.c:
[10:17:44] <CIA-11> ffmpeg: rtsp: Check the RTCP file handle for new packets, too
[10:17:44] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[10:20:33] <CIA-11> ffmpeg: mstorsjo * r24963 /trunk/libavformat/rtpdec.c:
[10:20:33] <CIA-11> ffmpeg: rtpdec: Read RTCP compound packets
[10:20:33] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[10:21:07] <CIA-11> ffmpeg: mstorsjo * r24964 /trunk/libavformat/rtpdec.c:
[10:21:07] <CIA-11> ffmpeg: Reindent
[10:21:07] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[10:26:11] <CIA-11> ffmpeg: mstorsjo * r24965 /trunk/libavformat/ (rtsp.c rtsp.h rtpdec.c):
[10:26:11] <CIA-11> ffmpeg: rtsp: Return AVERROR_EOF when all streams have received an RTCP BYE packet
[10:26:11] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[13:16:37] <DonDiego> moin
[13:22:17] <BBB___> mru: ping
[14:45:58] <lu_zero> BBB: what news?
[14:46:08] <BBB> no news?
[14:51:48] <lu_zero> =|
[14:55:33] <BBB> lu_zero: I meant: what news are you expecting me to bring?
[14:56:22] <lu_zero> this night you were preparing stuff to thin asm file of unasked stuff iirc
[14:56:41] <BBB> I need mru to fix me a config.asm for that
[14:56:51] <BBB> I'll discuss briefly with him to see if he likes the idea
[14:57:04] <BBB> the problem isn't quite as easy as it seems, b/c it's not just h264/vc1/rv40...
[14:57:11] <lu_zero> hm?
[14:57:30] <BBB> rv3/4 uses h264/rv40 depending on i-dont-know-what, vp6 uses h264, mpeg uses h264, and some other formats use h264 also
[14:57:38] <BBB> I don't want to create an #ifdef hell
[14:57:49] <BBB> so I'll ask mru for suggestions on how to better do this in configure or so
[14:58:35] <lu_zero> uhm
[14:59:07] <lu_zero> I'd look at the makefile if you have a deps problem
[14:59:39] <BBB> it's not a deps problem
[14:59:41] <BBB> it's the opposite
[14:59:45] <lu_zero> uhm?
[14:59:49] <BBB> right now, we always compile in all mc functions
[14:59:56] <BBB> so you get a big chunky fat binary
[14:59:59] <lu_zero> yes
[15:00:30] <BBB> I'm wondering if we can trim it down if, say, the user disabled most decoders except e.g. vp8 or h264 or
[15:00:53] <BBB> clearly if you have only vp8, you don't need any... if you have only vp6, you need h264 chromamc[0][0] at least. if you have h264, you need them all
[15:00:59] <lu_zero> so you need a way to trace what uses what
[15:01:04] <BBB> right
[15:01:11] <BBB> and I don't want to split the .asm file in 10 smaller ones
[15:01:27] <BBB> so I'm going to ask mru for suggestions whether a configure trick like for h264pred can be done here
[15:01:29] <lu_zero> and the configure should already know
[15:01:47] <BBB> no, because this problem has always been there :(
[15:01:55] <lu_zero> uhm
[15:01:56] <BBB> all mc was always compiled in
[15:01:58] <lu_zero> basically
[15:02:01] <lu_zero> you need to have
[15:02:02] <BBB> just because it was in dsputil
[15:02:17] <lu_zero> h264_mc_dep="something"
[15:02:32] <lu_zero> vp6_mc_dep="h264_mc"
[15:02:35] <lu_zero> and such
[15:02:38] <BBB> yes
[15:02:47] <BBB> that's the first half
[15:02:59] <BBB> then the second half is that in the asm file, you only want to compile those bits that you need
[15:03:11] <BBB> this one asm file now contains functions for rv, vc1 and h264
[15:03:18] <BBB> if vc1 is disabled, you want to disable vc1 functions
[15:03:21] <BBB> right?
[15:03:27] <BBB> but yasm cannot include config.h
[15:03:36] <BBB> so we need a config.asm that is like config.h except asm'ified
[15:03:40] <BBB> *yasm'ified
[15:03:58] <lu_zero> ok
[15:04:14] <lu_zero> test_deps is probably what you want =)
[15:04:28] * BBB not familiar with configure at all
[15:04:32] <BBB> that's why I ping mru :-p
[15:05:10] <lu_zero> ^^
[15:05:27] <BBB> :-p
[15:05:34] <lu_zero> do you have already a list of deps?
[15:06:00] <lu_zero> you will end up with something like
[15:06:33] <lu_zero> vp6_decode_select="huffman h264_mc"
[15:06:49] <lu_zero> s/decode/decoder/
[15:07:22] <lu_zero> how much space you'd spare this way?
[15:30:58] <lu_zero> mru: btw would make sense have a way to autogenerate the configure help out the _LISTs ?
[15:47:26] <CIA-11> ffmpeg: vitor * r24966 /trunk/libavcodec/ws-snd1.c: Include stdint.h instead of inttypes.h, it is enough for what this file need.
[16:19:13] <CIA-11> ffmpeg: aurel * r24967 /trunk/libavformat/ (raw.c Makefile aacdec.c): move ADTS AAC demuxer to its own file
[16:36:36] <CIA-11> ffmpeg: aurel * r24968 /trunk/libavformat/ (raw.c Makefile raw.h idroqenc.c): move id roq muxer to its own file
[16:37:45] <BBB> lu_zero: sorry, ran away for a bit... I don't think it'd save much, maybe a few kb, but that's always a few kb
[16:38:27] <CIA-11> ffmpeg: aurel * r24969 /trunk/ (4 files in 2 dirs): rename idroq.c to idroqdec.c
[16:41:03] <lu_zero> uhmm
[16:59:52] <BBB> lu_zero: the whole file is 16kb, about half of that is h264 and a quarter (each) is rv40 and vc1
[16:59:56] <BBB> so removing vc1 would save 4kb
[16:59:59] <BBB> (this is all stripped)
[17:03:12] <lu_zero> give me the deps relations
[18:28:56] <CIA-11> ffmpeg: aurel * r24970 /trunk/libavformat/Makefile: 10l: aacdec and idroqenc still depend on raw.o
[18:34:29] <CIA-11> ffmpeg: aurel * r24971 /trunk/libavformat/raw.c: simplify code by using the AV_NE() macro
[19:01:36] <CIA-11> ffmpeg: aurel * r24972 /trunk/libavformat/ (dtsdec.c raw.c Makefile raw.h): move DTS demuxer to its own file
[19:16:59] <CIA-11> ffmpeg: aurel * r24973 /trunk/libavformat/ (raw.c ingenientdec.c Makefile raw.h): move ingenient demuxer to its own file
[19:45:40] <lu_zero> yawn
[19:45:46] <lu_zero> BBB: you there?
[19:46:37] <drecute> question: what can I do when client refuse to pay on time for service rendered
[19:47:39] <lu_zero> ask till he paid
[19:47:45] <lu_zero> or use lawyers
[19:48:06] <drecute> great
[19:48:30] <lu_zero> uhm?
[19:58:58] <Compn> drecute : install backdoors and blackmail them! :P
[19:59:12] <drecute> lol
[19:59:28] <drecute> then they will stop being ur client
[19:59:33] <drecute> then i will lose money
[19:59:42] <drecute> i want to maintain a relationship
[19:59:45] <Compn> can you call them a client if they dont pay ? :P
[20:00:00] <drecute> they dont pay on it
[20:00:04] <drecute> they dont pay on time
[20:00:12] <drecute> that's it
[20:00:15] <Compn> well then just expect not to get paid on time
[20:00:28] <drecute> even thouugh they like the service
[20:00:31] <Compn> heh
[20:00:36] <Compn> charge them double next time
[20:00:37] <Compn> :P
[20:02:44] <lu_zero> that works as well
[20:37:18] <CIA-11> ffmpeg: aurel * r24974 /trunk/libavformat/ (raw.c mpegvideodec.c Makefile): move mpegvideo demuxer to its own file
[20:44:24] <BBB> lu_zero: pong
[20:44:34] <BBB> sorry, little busy, not in front of the screen all the time
[21:15:48] <CIA-11> ffmpeg: aurel * r24975 /trunk/libavformat/ (raw.c Makefile cavsvideodec.c): move cavsvideo demuxer to its own file
[21:24:22] <CIA-11> ffmpeg: aurel * r24976 /trunk/libavformat/ (raw.c Makefile m4vdec.c): move m4v demuxer to its own file
[21:24:22] <CIA-11> ffmpeg: aurel * r24977 /trunk/libavformat/m4vdec.c: cosmetic
[21:29:46] <CIA-11> ffmpeg: aurel * r24978 /trunk/libavformat/ (raw.c Makefile h264dec.c): move h264 demuxer to its own file
[21:35:14] <CIA-11> ffmpeg: aurel * r24979 /trunk/libavformat/ (raw.c Makefile h263dec.c): move h263 demuxer to its own file
[21:38:29] <CIA-11> ffmpeg: aurel * r24980 /trunk/libavformat/ (raw.c h261dec.c Makefile): move h261 demuxer to its own file
[21:45:19] <CIA-11> ffmpeg: aurel * r24981 /trunk/libavformat/ (raw.c Makefile diracdec.c): move dirac demuxer to its own file
[21:52:40] <CIA-11> ffmpeg: aurel * r24982 /trunk/libavformat/ (raw.c Makefile dnxhddec.c): move dnxhd demuxer to its own file
[22:03:37] <CIA-11> ffmpeg: aurel * r24983 /trunk/libavformat/ (raw.c Makefile ac3dec.c): move ac3/eac3 demuxer to its own file
[22:07:39] <CIA-11> ffmpeg: aurel * r24984 /trunk/libavformat/raw.c: cleanup includes which are not used anymore in raw.c
[22:16:41] <CIA-11> ffmpeg: aurel * r24985 /trunk/libavformat/ (raw.c Makefile nullenc.c): move null muxer to its own file
[22:22:29] <CIA-11> ffmpeg: aurel * r24986 /trunk/libavformat/raw.c: simplify code by using the AV_NE() macro
[23:07:24] <BBB> hi j0sh, how's the startup going? :-p
[23:11:53] <Dark_Shikari> 1
[23:11:59] <Dark_Shikari> bah, irssi local editing fail
[23:17:24] <j0sh> BBB: excellent
[23:18:08] <j0sh> dont have much to show for it yet, but hopefully soon enough :)
[23:37:10] <BBB> saste: nice catch on the preprocessor thingy ;)