[00:01:10] <Yuvi> dmesg? [00:02:07] <Dark_Shikari> ugh. I can't get oprofile to work on vmware [00:02:17] <Dark_Shikari> everything I read on the internets says it works if you use the timer interrupt [00:02:20] <Dark_Shikari> which I set on [00:02:32] <Dark_Shikari> but when I try to start it, it says "couldn't start oprofiled. check the logfile and kernel syslog" [00:02:35] <Dark_Shikari> but BOTH are empty [00:02:44] <Dark_Shikari> --verbose=all does nothing [00:02:48] <Dark_Shikari> it does not print any information anywhere [00:04:19] <Dark_Shikari> oh. apparently I have to manually specify -e=timer or else it won't figure it out, even though it's the only event avialable [00:08:31] <Dark_Shikari> oh sweeeeet [00:08:38] <Dark_Shikari> oprofile correctly gets the symbols of asm functions, while callgrind doesn't [00:09:01] <Dark_Shikari> ... on the other hand, it doesn't seem to provide any information about the call stack... [00:09:50] <Dark_Shikari> Is there anything special I have to do with oprofile to get it to track the stack ? [00:40:14] <Dark_Shikari> is there a good way to infinitely cat a file into an app? [00:40:20] <Dark_Shikari> e.g. the equivalent of cat file file file file ... | app [00:40:23] <Dark_Shikari> without typing "file" a thousand times [00:43:36] <trollski> Dark_Shikari: while :; do cat file | app; done [00:43:45] <Dark_Shikari> won't that repeatedly start app over again? [00:43:47] <Dark_Shikari> I don't want to do that. [00:43:50] <trollski> yeah [00:48:10] <trollski> Dark_Shikari: maybe in two steps? while :; cat file >> newfile; done ...... and second separate step: cat newfile | app .... dunno if that'll work [00:48:18] <Dark_Shikari> Too large [00:48:23] <Dark_Shikari> I don't have disk space for that [00:48:27] <Dark_Shikari> I'm piping terabytes around [00:48:31] <trollski> oh [00:49:02] <hyc> just do all the cats inside a script [00:49:07] <hyc> or subshell [00:49:08] <astrange> i wrote a program to do it in haskell and accidentally evaluated the tail of an infinite list [00:49:20] <Dark_Shikari> hyc: how does that help me? [00:49:37] <hyc> (while :; do cat foo) | app [00:49:46] <hyc> then there's only a single pipe / app [00:50:08] <Dark_Shikari> also, -loop_input doesn't work in ffmpeg [00:50:42] <Dark_Shikari> hyc: that gives a syntax error [00:50:49] <hyc> well duh [00:50:53] <hyc> it also only has a single filename [00:51:01] <Dark_Shikari> huh? [00:51:01] <hyc> you need to tailor it to your actual usage [00:51:06] <Dark_Shikari> um, but I only want a single file [00:51:10] <Dark_Shikari> ... [00:51:14] <hyc> oh? [00:51:20] <hyc> it's the same file over and over? [00:51:34] <hyc> I thought you wanted to cat a bunch of files [00:51:49] <Dark_Shikari> .... [00:51:52] <Dark_Shikari> that's what I said like 5 times [00:52:03] <Dark_Shikari> I'm saying your syntax is simply wrong, irrespective of what I'm trying to do [00:52:06] <Dark_Shikari> because it isn't valid bash [00:52:17] <hyc> then just this (while 1; do cat foo; done) | app [00:52:48] <Dark_Shikari> s/1/true [00:53:10] <hyc> right [00:53:52] <Dark_Shikari> woot, works [00:53:57] <Dark_Shikari> just got past the first repeat point [00:53:59] <hyc> you're supposed to know the syntax, I was just telling you that using a subshell is the right approach [00:54:04] <Dark_Shikari> k, thx [00:57:01] <hyc> oprofile has been pretty fragile in my experience [00:57:12] <hyc> works on one install, do an upgrade, it's broken [00:57:47] <hyc> and yes, to get stacks recorded, you need to set other oprofile options [00:57:52] <hyc> probably an opcontrol switch [00:57:58] <Dark_Shikari> I did, -c=20 [00:58:07] <Dark_Shikari> Still doesn't actually work. [00:58:32] <hyc> oh well. [00:58:45] <hyc> what are you profiling? [00:58:56] <hyc> and what data do you want to extract from the profile? [00:58:59] <Dark_Shikari> x264, I'm trying to get a proper CallMap profile, i.e. that really nice kcachegrind interface [00:59:18] <Dark_Shikari> valgrind-based callmap profile works great, but it doesn't read the names of asm functions correctly [00:59:21] <Dark_Shikari> and the results are very inaccurate [00:59:29] <Dark_Shikari> oprofile-based profile is highly accurate and good, but callmap doesn't work [00:59:47] <hyc> that's odd. I've used valgrind trace before with success. though, no asm functions. [01:00:40] <hyc> It must depend on your binary, if the assembly code doesn't provide stack usage hints then the tools can't backtrace thru it [01:00:49] <Dark_Shikari> No, no, it can't even READ THE SYMBOLS [01:01:02] <Dark_Shikari> and oprofile doesn't provide callmap information _even for C functions_ [01:01:13] <hyc> yeah well, oprofile breaks a lot [01:02:14] <Dark_Shikari> well callgrind not being able to read symbols sorta sucks too [01:02:36] <hyc> what architecture are you running? [01:02:40] <Dark_Shikari> x86_64 [01:02:58] <hyc> got a 32 bit machine handy? that will probably work better [01:03:01] <Dark_Shikari> why [01:03:12] <hyc> generally x86 is better supported than x86-64 [01:03:25] <Dark_Shikari> doubt that symbol formats differ that much [01:03:56] <hyc> no, probably not. but libbfd and friends are more mature for 32 bit [01:04:01] <Dark_Shikari> it's easy enough to test though, just cross-compile [01:07:52] <hyc> also if all you want is the callmap, turn off all optimization [01:08:01] <Dark_Shikari> why? [01:08:13] <Dark_Shikari> as long as you don't use -fomit-frame-pointer, it shouldn't prevent the callmap from working [01:08:17] <hyc> because stuff like omit-frame-pointers really interferes [01:08:37] <hyc> and -fomit-frame-pointers is the default on -O2 and up [01:08:57] <Dark_Shikari> oh true, x86_64 [01:09:07] <Dark_Shikari> wait, I thought it was the default _because_ it didn't interfere on x86_64 [01:09:23] <hyc> false, it is still a problem [01:09:38] <hyc> look at a stack trace in gdb... [01:09:58] <Dark_Shikari> then why is it on by default in x86_64 but not x86_32? [01:10:07] <hyc> dunno [01:10:40] <hyc> whatever, do what you like [01:10:50] <hyc> it's your time not mine... [01:13:19] <Dark_Shikari> wrong [01:13:20] <Dark_Shikari> didn't work [01:13:27] <Dark_Shikari> even in debug mode, the callee map doesn't show up. [01:13:29] <Dark_Shikari> (-O1 -g) [01:15:44] <saintd3v> what about adding "-g dwarf2" to ASFLAGS? [01:15:59] <hyc> dwarf2 ought to be the default format [01:16:09] <Dark_Shikari> doesn't matter anyways, _even the C functions_ don't have callmap [01:16:13] <saintd3v> oic [01:16:31] <saintd3v> hyc: but iirc you have to pass _something_ to yasm if you specify -g [01:16:53] <hyc> ah, dunno. [01:16:53] <saintd3v> ie you can't do just yasm -g it has to be yasm -g foo [01:17:04] <hyc> I just use gas [01:17:28] <saintd3v> but if C functions aren't showing up it's moot anyway [01:18:25] <hyc> yep. I've submitted patches for oprofile in the past, but for whatever reason that thing keeps breaking [01:18:48] <hyc> have no idea why valgrind wouldn't work, usually it's pretty good [01:19:43] <hyc> the only reason it fails to show symbols, for my work, is because of shared libs that got unloaded [01:20:04] <hyc> it's still too stupid to record the sharedlib info at the time of load [01:21:32] <saintd3v> Dark_Shikari: i doubt it'll help, but -g3? [01:22:23] <saintd3v> and what about disabling all optimizations? [01:22:38] <hyc> btw, are you using the latest? valgrind 3.5? [01:23:23] <Dark_Shikari> I'm not using valgrind, I'm using oprofile [01:23:35] <Dark_Shikari> and yes when I did try valgrind, I used 3.5 [01:35:52] <Dark_Shikari> http://x264.nl/x264_Demo_Blu-ray.torrent <--The first free Blu-ray [01:35:55] <Dark_Shikari> download, seed [01:36:00] <Dark_Shikari> official announcement is coming on monday [01:36:13] <pentanol> hello, could someone point me which of these options important for usage? http://codepad.org/BEeo3wsm [02:28:40] <astrange> -fomit-frame-pointer still breaks frame pointer backtraces on x86-64, yeah [02:28:53] <astrange> i don't remember its defaultness changing on either arch [02:29:31] <astrange> valgrind _could_ maintain a separate call stack, or it could read dwarf unwind info (with the weirdly named -fasynchronous-unwind-tables or whatever) [02:29:43] <Dark_Shikari> valgrind works even if fomit-frame-pointer is set [02:31:40] <astrange> i don't remember any specific situations but i'm pretty sure it hasn't worked for me before [04:30:08] <mru> Dark_Shikari: while :; cat file; done | app [04:30:21] <mru> maybe you figured it out by now though... [04:31:08] <Dark_Shikari> yeah, I did [10:38:51] <twnqx> in which include is NULL defined? :X [10:45:34] <jai> twnqx: linux/stddef.h [10:45:41] <twnqx> thanks [10:47:57] <jai> on *bsds, i think it is in sys/null.h [10:51:00] <twnqx> btw jai, my syscall hook works now :P [10:51:07] <jai> twnqx: yay [10:51:10] <jai> :) [10:51:53] <twnqx> sadly the driver doesn't. [10:52:05] <twnqx> it also fubared my kernel. gotta reboot... [10:52:11] <jai> twnqx: oh :| [10:53:06] <twnqx> seems i have to modify some undocumented private ioctls as well. fun :D [10:53:27] <twnqx> but computers MUST NOT win against humans. [10:54:27] <kshishkov> twnqx, you're sooo wrong [10:54:53] <twnqx> true, in this case it's not the computer [10:54:59] <twnqx> but two companies that must not win. [10:55:28] <kshishkov> I'm pretty sure each of them agrees that another one should not win [10:56:00] <jai> twnqx: perhaps you'll reach a point where you might just want to pay them money for an x86_64 build :) [10:56:29] <twnqx> jai: the 64bit is not the real problem [10:56:49] <twnqx> the problem is that EITHER WAY i don't have a driver for post-2.6.16 kernels [10:57:15] <twnqx> i got myself a demo version of the current windriver 10 now [10:57:19] <jai> twnqx: ah [10:57:39] <twnqx> however... the app says "oh, you need > version 8.02" and i have 10.11 [10:57:54] <twnqx> i have the strong feeling that they do numerical comparison on the chars [10:58:11] <twnqx> so, 1 < 8 => fail [10:58:57] <twnqx> and since the driver is a blob again... with some exra fail like embedded integrity checks... [10:59:21] <twnqx> *sigh* [11:00:33] <twnqx> the good news for today is that my favorite german radio station does have a pure mp3 http stream with no protection, so i can skip the crappy flash plugin on their site and just use mplayer. [12:08:00] <BastyCDGS> hi @ all [12:16:48] <DimStar> how "final" is Michael's not liking anything as decision wether a patch is being merged or not? ( https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/087300.html ) [12:49:38] <BastyCDGS> I got stuck with START/END_TIMER...it doesn't output anything [12:49:56] <BastyCDGS> START/STOP_TIMER [13:29:55] <Kovensky> In file included from libavdevice/oss_audio.c:31: [13:29:55] <Kovensky> /usr/include/sys/soundcard.h:243:5: error: unknown type name 'u_long' [13:30:08] <Kovensky> ^ ffmpeg's or the system's fault :S [13:30:59] <elenril> your =p [13:31:16] <Kovensky> =p [13:31:32] <Kovensky> just wondering if sys/soundcard.h demands that some header is included before it but even then it's weird [14:05:56] <nfl> does anyone now how to modify the post commit email payload in github? [14:05:57] <nfl> I was asked to look at github for hosting my soc code but the post commit mail doesn't include the diff [14:07:50] <Kovensky> libavcodec/h264.h:1256:13: warning: unused function 'decode_mb_skip' [-Wunused-function] [14:08:22] <Kovensky> nfl: hmm, does it include a bit.ly link? at least their cia.vc module does [14:08:28] <Kovensky> the bit.ly link points to the diff on github.com [14:10:26] <nfl> Kovensky: it does include a link to the diff but i suppose reviewing wouldn't be as easy [14:18:57] <nfl> perhaps the soc repo should be moved to git ;) [14:22:17] <Kovensky> hmm [14:22:25] <Kovensky> you should bug the github people then :) [14:22:30] <Kovensky> don't know how to contact them though [14:23:22] <BastyCDGS> so hope my iff optimize patch is now ready for git ;) [14:23:29] <BastyCDGS> just submitted it to ml [14:23:43] <BastyCDGS> also included benchmarks [14:24:15] <nfl> Kovensky: http://support.github.com/discussions/post-receive-issues/16-diff-in-email-h... :( [14:25:04] <Kovensky> bug them again? :) [14:25:07] <Kovensky> that ticket is almost a year old [14:26:08] <nfl> I'll have to try that [14:28:37] <CIA-7> ffmpeg: stefano * r22961 /trunk/ (20 files in 2 dirs): [14:28:37] <CIA-7> ffmpeg: Mark av_metadata_set() as deprecated, and use av_metadata_set2() [14:28:37] <CIA-7> ffmpeg: in its place. [14:28:37] <CIA-7> ffmpeg: av_metadata_set() is going to be dropped at the next major bump. [15:06:10] <CIA-7> ffmpeg: stefano * r22962 /trunk/libavcodec/utils.c: [15:06:10] <CIA-7> ffmpeg: Make avcodec_check_dimensions() return AVERROR(EINVAL) rather than -1 [15:06:10] <CIA-7> ffmpeg: in case of invalid picture size. [15:44:04] <BastyCDGS> just a question regarding interleaved stereo audio output [15:44:26] <BastyCDGS> can I call av_new_packet(pkt, PACKET_SIZE) twice? [15:44:33] <BastyCDGS> one for left channel and one for right channel? [15:46:56] <Kovensky> not in the same pkt [15:47:08] <Kovensky> look in libavcodec/avpacket.c for what it does [15:48:13] * Kovensky fails at understanding "if((unsigned)size < (unsigned)size + FF_INPUT_BUFFER_PADDING_SIZE)" (isn't that always true except for negative size, and wtf allocates a negative sized buffer) [15:50:32] <elenril> Kovensky: overflow [15:51:44] <Kovensky> elenril: doesn't check for overflow either, unless (unsigned) has lower precedence than + [15:53:20] <elenril> whatever, i don't know c anyway ;) [15:53:25] <Kovensky> lol [15:55:29] <elenril> srsly i don't [15:55:31] <pengvado> yes it's for overflow [15:55:53] <mru> that code is wrong [15:56:08] <mru> the test checks for unsigned overflow [15:56:17] <mru> then it goes ahead and does a signed addition [15:57:00] <Kovensky> what mru said [15:57:45] <Kovensky> and you couldn't have an unsigned int overflow anyway with an int var [15:58:11] <Kovensky> not with regular casts at least ._. [15:59:28] <mru> if there is signed overflow, behaviour is undefined or unspecified, don't remember which [15:59:54] <mru> the size argument should have been unsigned [16:00:53] <Kovensky> mru: wouldn't INT_MAX+1 go to INT_MIN [16:00:57] <mru> no [16:01:02] <mru> it's undefined [16:01:07] <Kovensky> hmm [16:01:18] <Kovensky> I guess that's just the case with x86 then ._. [16:01:22] <BBB> this works: 1+((int64_t)INT_MAX) [16:01:31] <mru> don't even think about that [16:01:38] <BBB> I didn't say you should use it ;) [16:01:42] <BBB> I just said it works ;) [16:01:52] <BBB> but please don't take my svn commit access away [16:01:56] <Kovensky> you cheater :P [16:01:57] <elenril> lol [16:02:00] <Kovensky> lol [16:03:39] <BastyCDGS> can anyone tell me what's wrong with this small piece? [16:03:45] <BastyCDGS> if ((ret = get_buffer(pb, sample_buffer, PACKET_SIZE >> 1)) < 0) [16:03:45] <BastyCDGS> return AVERROR(EIO); [16:03:45] <BastyCDGS> old_pos = url_fseek(pb, iff->body_size >> 1, SEEK_CUR); [16:03:45] <BastyCDGS> if ((ret = get_buffer(pb, sample_buffer + (PACKET_SIZE >> 1), PACKET_SIZE >> 1)) < 0) [16:03:45] <BastyCDGS> return AVERROR(EIO); [16:03:46] <BastyCDGS> url_fseek(pb, old_pos, SEEK_SET); [16:04:04] <BastyCDGS> I'm just fixing the interleaved stereo support for IFF-8SVX [16:04:30] <BastyCDGS> and I added the fseek stuff to seek to the right channel [16:04:39] <BastyCDGS> but when I run it plays only one frame and then silence [16:04:54] <jai> ? [16:04:58] <Kovensky> ugh, reminds me that I still must figure out wtf I'm doing wrong in my stuff... [16:05:09] <Kovensky> for some reason the mp2 decoder is dying with Broken Header when decoding the 3rd frame ._. [16:05:16] <jai> as i said in the mail earlier, just use the ff_interleave code [16:10:25] <BastyCDGS> jai, you mean the interleave_sample from iff.c or another interleave stuff? [16:10:44] <jai> BastyCDGS: lavf/audiointerleave.c [16:10:46] <BBB> how do I compile/run 64-bits code on a macintel? [16:10:53] <BBB> (assuming it can run it...) [16:11:19] <BBB> not which configure command, but which gcc command? [16:11:22] <jai> after that you can remove the interleaving code in iff.c [16:11:32] <BastyCDGS> btw, is my new patch regarding optimizing okay? [16:12:36] <mru> I'd rather you separated the structural changes from the unsigned/shift ones [16:14:04] <BastyCDGS> you mean the structural changes I did because of getting rid of branch prediction inside the loops? [16:14:53] <BBB> what's the difference? it's ~1% if I read it correctly, for this particular function? [16:14:58] <BBB> that's not very much [16:15:20] <jai> :) [16:15:46] <BastyCDGS> no this is only for plane decoding...i think the overall diff will be around 2% [16:16:01] <jai> well ..../ [16:18:43] <BastyCDGS> a mispredicated branch prediction is 10-20 clock cycles [16:19:25] <BastyCDGS> I removed 4 branches in the main loop decoding the image that's a save of 40-80 clock cycles per pixel [16:20:02] <mru> branch prediction isn't really the issue here [16:20:22] <mru> after a couple of iterations the predictor will have learned which branch is being taken [16:20:27] <mru> since it's the same each time around [16:20:47] <BastyCDGS> you think I should revert the changes there I made? [16:20:50] <mru> no [16:21:12] <BastyCDGS> so just split the patch up and it will be fine? [16:21:16] <mru> I'm just saying branch _prediction_ is not the reason for making such changes [16:21:34] <mru> you simply want to reduce the number of instructions in tight loops [16:22:21] <mru> in an otherwise small loop, a few branches can increase the size significantly [16:22:30] <mru> running more instructions obviously takes longer time [16:22:30] <BastyCDGS> this is a neat side-effect here anyway, removing branches completely will do this ;) [16:22:40] <mru> and spreading the loop body over more cache lines is bad [16:25:26] <BastyCDGS> I did take a look on the disasm output, too. it really looks much better [16:25:50] <mru> I'm not disputing that [16:25:52] <BastyCDGS> so finally, what I shall do now for getting this patch into mainline git tree? [16:26:06] <mru> as I said, do the loop restructuring as one patch [16:26:18] <BastyCDGS> okey, wait a minute, plz ;) [16:26:19] <mru> and the micro-opts as another [16:34:25] <BastyCDGS> the micro opts only patch is finished, can I send both patches in one post? [16:35:14] <BBB> I normally wouldn't [16:35:16] <BBB> but you can try [16:35:21] <mru> use git send-email [16:36:05] <BastyCDGS> btw, should I put my copyright notice also in a separate patch? [16:36:34] <kshishkov> no [16:45:18] <BastyCDGS> btw, what is the difference between git checkout and git pull? [16:45:33] <BastyCDGS> I noticed that I had to do git pull to get the data from the mainline repo [16:45:36] <mru> everything [16:45:46] <BastyCDGS> while git checkout said merged my local changes [16:45:52] <mru> pull is the same as fetch followed by merge [16:46:04] <mru> read the documentation [16:46:12] <mru> it's all explained there better than I could do here [16:46:24] <BastyCDGS> ok I should do this, but I was trying to find that out by myself by doing git --help ;) [16:46:52] <BastyCDGS> after all I can now work a bit with git...I didn't use svn since then, btw [16:47:05] <elenril> why would you want to ;) [16:48:21] <BastyCDGS> so both patches now on ml [16:50:01] <jai> how is your qualification task coming along? [16:50:55] <BastyCDGS> it slowed down a bit due the case I want to do EHB/HAM first in plain ILBM [16:51:09] <BastyCDGS> thus fix the plain ILBM decoder first [16:51:23] <BastyCDGS> before I have to do everything twice... [16:51:50] <BastyCDGS> EHB will be finished today [16:52:46] <kshishkov> good, FFmpeg is about fringe formats [16:53:27] <kshishkov> with some fast decoders for standard codecs added for cheap popularity [16:55:00] <BastyCDGS> mru, dropped the spaces in [] and updated patch in ml [16:55:19] <mru> you don't need to resend patches for such tiny changes [16:55:31] <mru> it's better to wait for more reviews first [16:55:41] <BastyCDGS> okay [16:59:44] <kshishkov> hej [17:00:08] <BastyCDGS> so the rest is fine then? [17:00:49] <kshishkov> just wait for more replies [17:04:40] <BastyCDGS> regarding ff_audio_rechunk_interleave, the two AVPacket's there are one for left and right channel right? [17:06:39] <BBB> BastyCDGS: learn to wait 24-48 hrs for reviews [17:06:43] <BBB> reviews can take time :) [17:07:05] <BastyCDGS> ok, I'll continue then with EHB now [17:07:23] <kshishkov> yes, the more you can deliver the better [17:09:29] <BBB> so kshishkov, do you want crashers I see in vc1dec as I add wvp2? [17:09:33] <BBB> kshishkov: there's quite a few [17:09:46] <BBB> kshishkov: basically every single wvp2/wmvp sample crashes the vc1 decoder ;) [17:10:02] <kshishkov> no error messages? [17:10:06] <BBB> Bus Error [17:10:12] <BBB> which is like a segfault [17:10:16] <kshishkov> that's strange [17:10:24] <kshishkov> IIRC it should fail on parsing extradata [17:10:30] <BBB> it does [17:10:34] <mru> BBB: what system is that on? [17:10:35] <BBB> if I remove that, vc1dec crashes [17:10:38] <BBB> mru: mac [17:10:45] <mru> hmm [17:10:49] <BBB> kshishkov: I added etradata parsing [17:10:59] <BBB> kshishkov: but the actual decoding is still in progress [17:11:09] <kshishkov> good! [17:11:13] <BBB> not really :) [17:11:16] <BBB> but anyway [17:11:28] <kshishkov> what gdb says? [17:11:30] <mru> bus error usually means either invalid unaligned access or access to some kind of totally invalid address [17:11:47] <BBB> I didn't run it in gdb [17:11:49] <BBB> I'm lazy [17:11:56] <BBB> if I give you a crashing sample will you look at it? [17:12:07] <BBB> if you say no, I won't bother [17:12:12] <BBB> if you say yes, I'll file some reports [17:12:13] <kshishkov> no [17:12:23] <mru> wrong answer [17:12:27] <kshishkov> I've moved to another town and all I have now is Gdium [17:12:37] <BBB> :) [17:12:38] <BBB> what is gdium? [17:12:45] <mru> sorry excuse of a netbook [17:12:59] <kshishkov> and a portable stove! [17:13:07] <mru> yeah, all in one [17:13:17] <jai> lol [17:13:18] <mru> only missing the kitchen sink [17:13:38] <jai> better than what richard stallman uses i'd say [17:13:50] <mru> what does he use? [17:13:54] <kshishkov> does he still use Lisp machine? [17:13:57] <BBB> a kitchen cave [17:13:58] <mru> does he code directly on his ego? [17:14:23] <mru> oh, wait.. rms doesn't actually write code [17:14:32] <mru> he just jumps up and down and shouts a lot [17:14:43] <kshishkov> worked fine for GCC [17:15:02] <mru> I doubt there's a single line of code in gcc he wrote [17:15:29] <kshishkov> and Emacs was written by Sun guy who later worked on Java [17:15:36] <mru> that was vi [17:15:44] <kshishkov> Emacs [17:15:56] <mru> emacs has been worked on by very many people [17:16:08] <mru> but the sun guy is famous for vi [17:16:19] <kshishkov> yes, but first opensource version was written by some Sun guy [17:17:27] <jai> yeelong actually : http://richard.stallman.usesthis.com/ [17:17:39] <kshishkov> mru: yep, Gosling [17:18:00] <kshishkov> jai: that's even more Chineese that Gdium but of the same source [17:18:31] <jai_menon> meh [17:18:45] <mru> what an idiot [17:18:54] <mru> why doesn't he get a pc and put seabios on it? [17:19:01] <jai> anyway, so he uses a yeelong - http://richard.stallman.usesthis.com/ [17:19:34] <jai> and yeah, after the egcs merge i dont think there is any significant gcc code written by him left [17:19:38] <kshishkov> heh, even I use better netbook :) [17:19:49] <BBB> no wonder the guy doesn't code [17:19:55] <BBB> his laptop is a PoS [17:20:08] <mru> isn't yeelong the one with incompatible cpu and northbridge? [17:20:22] <mru> how they made it run at all is a bit of a mystery [17:20:55] <kierank> [18:20] <@BBB> his laptop is a PoS --> yes but it's "free" [17:21:05] <BBB> freetard argument alert [17:21:19] <mru> but the cpu itself isn't free [17:21:26] <kierank> tell him that [17:21:42] <kshishkov> why don't we have anything useful Sparc-based? [17:21:49] <kshishkov> _that_ CPU is free [17:21:49] <mru> and there are much better systems with fully free software [17:23:05] <mru> oh, and I think it's about time rms accepted that linus stole the show [17:23:24] <kshishkov> you just wait for GNU Hurd! [17:23:30] * kierank waits [17:23:42] <jai> Real Soon Now [17:23:48] <kshishkov> kierank: you can make a cup of coffee meanwhile [17:23:54] <mru> and either way, the insistence on saying gnu/linux is insane [17:24:06] <kshishkov> from the beans of plantation you ground this day [17:24:23] <mru> if we want to be accurate, we should say, gnu/bsd/x/kde/gnome/mozilla/linux [17:24:26] <mru> or something [17:25:06] <drv> average joe desktop/gui user probably doesn't even touch the GNU stuff anyway [17:25:16] <jai> plan 9 ftw? [17:25:20] <BBB> gnume/linux [17:25:35] <mru> I installed plan9 in a vm once [17:25:42] <mru> most useless system ever [17:27:31] <jai> lol [17:27:41] <jai> i used it for werc at some point [17:28:15] <kshishkov> so you agree? [17:30:03] <jai> in a way, yeah. perhaps i'm not able to appreciate the awesomeness [17:31:26] <kshishkov> not piped for it [17:37:59] * _av500_ welcomes kshishkov back from whereever he has been [17:38:22] <kshishkov> _av500_: at least now it's 200km closer to Stockholm [17:39:07] <_av500_> they physically moved kharkov? [17:39:16] <kshishkov> no, I physically moved from there [17:39:35] <_av500_> for vacation? [17:39:37] <kshishkov> had to get a work for that though [17:39:53] <_av500_> a work [17:40:10] <kshishkov> yep [17:40:21] <pJok> its alive and back! [17:40:28] <pJok> god kväld, kshishkov :) [17:40:42] <pJok> err [17:40:44] <pJok> kväll [17:40:51] <kshishkov> and a bunch of good evenings to you too [17:41:03] <_av500_> kiev? [17:41:44] <kshishkov> karlsruhe [17:43:27] <_av500_> wow [17:44:53] <kshishkov> Kiev sucks, so I'd move there only at gunpoint [17:45:22] <_av500_> who do you work for? [17:45:31] <kshishkov> Cinemo [17:46:40] <BastyCDGS> one question, how do I do the following with git? [17:46:57] <BastyCDGS> I have now the noindent patch ready of restructuring optimization patch [17:47:12] <BastyCDGS> I want now to commit this locally and just correct indentation and create a correct patch [17:47:48] <_av500_> kshishkov: nice [17:48:16] <kshishkov> _av500_: yes, I think so [17:48:33] <BastyCDGS> can I do sth. like git diff file1 local_repo? [17:49:01] <mru> just create the commits in your local repo [17:49:10] <mru> the git svn dcommit them all at once [17:49:24] <_av500_> kshishkov: you are herewith invited to a non-alcoholic beverage of your choise here any time [17:49:27] <BastyCDGS> svn dcommit? [17:49:46] <BastyCDGS> I'm not using git-svn [17:49:49] <BastyCDGS> just plain git [17:49:56] <mru> oh, wait... you don't have commit rights do you? [17:50:05] <kshishkov> _av500_: oh, thanks [17:50:11] <BastyCDGS> no I haven't commit rights [17:50:25] <mru> BastyCDGS: still, do the commits locally [17:50:45] <mru> then "git format-patch origin" should give you a nice patch series [17:51:18] <elenril> even better, git send-email [17:51:33] <mru> yeah, that's even better [17:51:44] <BastyCDGS> I prefer writing mails to ML with thunderbird so I have all sent/received mails in one program [17:52:10] <mru> you'll get them back from the ML [17:52:14] <elenril> sending multiple patches is :effort: [17:52:24] <BastyCDGS> oh then I didn't say anything ;) [17:52:51] <mru> git send-email will ask you for an address to send to [17:53:07] <mru> you can set a default in the repo configuration [17:53:14] <_av500_> git cant figure that out by itself? bah [17:53:16] <mru> man git-send-email should say how [17:53:20] <BastyCDGS> I have already configured git for using my email adress and name for sending [18:07:49] <Dark_Shikari> calling on the cabal [18:07:54] <Dark_Shikari> http://www.reddit.com/r/programming/comments/bvwi5/x264_project_announces_fi... http://news.ycombinator.com/item?id=1293135 http://slashdot.org/submission/1223280/x264-Project-Announces-Blu-ray-Encodi... [18:07:58] <Dark_Shikari> upvote me [18:08:11] <kshishkov> ask xiph [18:08:14] <BastyCDGS> mru, short question regarding your critics...shall I do the correct indentation from start only for larger blocks of new code, or can I do that with any line marked by the patch as + ? [18:08:23] <Kovensky> <@mru> you'll get them back from the ML <-- not if you use gmail :( [18:08:32] <Kovensky> at least it completely ignores ML echoes [18:08:37] <mru> Kovensky: wtf? [18:08:47] <kshishkov> good night, I'll try to come here more often [18:08:57] <BastyCDGS> I also didn't get back the messages I sent to ml [18:09:19] <BastyCDGS> but they're at least in my sent folder [18:18:16] <BastyCDGS> so noindent patch should be fine now, mru ;) [18:18:17] <jai> BastyCDGS: btw, are you french? [18:19:03] <BastyCDGS> my native language is german, but since I moved to french speaking part of belgium 1.5f years ago, I have switched locale from de_DE to fr_BE for better learning of french [18:22:07] <jai> BastyCDGS: ah [18:22:20] <jai> should be fun [18:22:25] <BastyCDGS> you were wondering about my a ecrit in my reply messages, right? ;) [18:22:30] <jai> yep [18:23:19] <jai> using it for everyday communication should help a lot [18:23:40] * jai 's french is pretty rusty :( [18:24:21] * BastyCDGS can read a french newspaper and that stuff quite well now, but acoustical understanding is still very hard to me [18:26:25] <BastyCDGS> btw, is it safe to set bit_per_coded_sample to 12 (HAM6) resp. to 18 (HAM8)? [18:26:46] <BastyCDGS> because I wouldn't need any extra fields then...I just would have to check in the decoder if it's 12 or 18 [18:27:41] <BastyCDGS> 12 because HAM6 is 4096 color image and 18 because HAM8 is 262144 color image [18:27:53] <BastyCDGS> this way we can still differ from 16 bit images and 24 bit images ;) [18:28:08] <BastyCDGS> but I'm not sure if this breaks something else in ffmpeg [18:28:13] <BBB> no, that should be fine [18:28:20] <BastyCDGS> perfect :D [18:29:00] <BastyCDGS> should I provide here two patches also? one for EHB alone and one for HAM? [18:29:18] <BBB> yes [18:29:21] <jai> if they are independent, then yes [18:29:23] <BBB> because they're completely different things [18:29:44] <BastyCDGS> okey [18:29:49] <BastyCDGS> they are [18:30:52] <BastyCDGS> btw, sometime ago I posted a patch for fixing the IFF reading [18:31:05] <BBB> ping it, I'll review that also now [18:31:06] <BastyCDGS> will this be commited or shall I still change anything there? [18:31:24] <BastyCDGS> wait I'll create a new one with git ;) [18:48:31] <CIA-7> ffmpeg: stefano * r22963 /trunk/libavdevice/v4l2.c: Remove unnecessary width and height variables from v4l2_read_header(). [18:49:55] <BastyCDGS> BBB, just submitted to ml [18:50:14] <BBB> ok [19:03:32] <BastyCDGS> fixed the critics on restruct noindent patch [19:09:41] <BastyCDGS> ooohh, I found a bug... [19:09:54] <BastyCDGS> when displaying an IFF image and you resize the window it goes simply black [19:10:29] <BastyCDGS> is this because the IFF decoder and demuxer doesn't currently using scaling? [19:12:21] <BastyCDGS> just tried out with a jpeg image, same happens there too... [19:15:28] <drv> that's just ffplay + image in general [19:16:17] <BastyCDGS> oh so I shouldn't worry about that in de(muxer|coder)? [19:18:10] <drv> right [19:19:17] <BastyCDGS> then the issue is probably that ffplay doesn't react to window resize messages? [19:21:51] <BBB> it does, but it only updates after the next frame [19:22:03] <BBB> and these videos are 1 frame :) [19:22:38] <BastyCDGS> is a fix appreciated for this? [19:23:27] <wbs> if it's clean and doesn't interfere with anything else, it may be appreciated, I guess that's mostly up to michael [19:31:40] <elenril> BastyCDGS: you should really use git format-patch [19:31:51] <elenril> it includes the commit message into the patch [19:33:37] * Kovensky wonders why does his code fail with mp2 but works with aac [19:34:30] <elenril> Kovensky: witches [19:35:27] <Dark_Shikari> but witches don't exist [19:35:35] <Dark_Shikari> there is no 19th person! [19:36:28] <elenril> got any proof? =p [19:36:50] * elenril wonders why do so many people thinks it's mystery [19:37:39] <Kovensky> oh, got it to work! [19:37:43] <Kovensky> but I had to use a goto D: [19:39:11] <drv> don't worry, raptor-proofing specialists will be at your workstation shortly [19:39:27] <Kovensky> :P [19:39:33] <Kovensky> well, I'm working on getting rid of it [19:39:33] <Kovensky> Decoded 1 [19:39:33] <Kovensky> Decoded 2 [19:39:33] <Kovensky> [mp2 @ 0x60dfd0]Header missing [19:39:33] <Kovensky> lavfsource [error]: error decoding audio [19:39:36] <Kovensky> Decoded 4 [19:39:39] <Kovensky> no idea why mp2 whines about that though [19:39:48] <BastyCDGS> BBB: fixed your issues on my patch [19:39:56] <Kovensky> (the %d are the frame number) [19:40:07] <Kovensky> it then goes without issue until EOF ._. [19:54:42] <BBB> what do you mean "should I change both patches"? [19:54:57] <BBB> submit the case in a separate patch, is what I would say [19:55:04] <BBB> so that the first patch becomes simpler [19:56:15] <wbs> one way of getting rid of all the "how to send proper patches" problems is reading the mailing list for a long time before actually sending anything ;P [19:57:52] <BastyCDGS> I've fixed it...it was already in the other patch [19:57:58] <BastyCDGS> just submitted to ml [20:02:16] <BBB> wbs: I was surprised you never ran into this ;) [20:02:53] <BBB> and now that I work like this, I'm ashamed of earlier patches I've sent to e.g. the linux mailinglist [20:03:01] <BBB> where basically half of my patch was reindenting of a driver [20:03:06] <BBB> and the other half was functional changes [20:03:13] <BBB> nobody could ever have reviewed that AND be sane [20:04:33] <wbs> BBB: i've been subscribed to -devel (and read most mails) for almost a year, and have been browsing the list on and off for quite some time before that, too ;P [20:04:58] <BBB> that's better indeed [20:07:20] <wbs> I ran into some of your past within gstreamer, btw... I had tried making some custom filter using the template perhaps 18 months ago.. now when I looked at the code again, your name is in the copyright list of that template ;P [20:07:32] <BBB> indeed ;) [20:07:50] <BBB> you can go further back, before gstreamer I did mjpegtools and a mjpeg-capture-card linux kernel driver [20:08:06] <BBB> and during gstreamer I did a lot of gnome also [20:08:31] <wbs> ah [20:08:42] <BBB> what do you use gstreamer for? [20:08:46] <BBB> gst-ffmpeg wrapper + filters? [20:09:04] <BastyCDGS> BBB, just read your mail about the 4 more indent [20:09:05] <wbs> nah, interfacing with proprietary codecs and capture devices for work stuff [20:09:07] <BastyCDGS> it seems correct to me [20:09:13] <BastyCDGS> at least in decode_ilbm [20:09:38] <BBB> that might be, I didn't check that very carefully [20:09:44] <BBB> the first one is definitely wrong though :) [20:10:08] <BBB> if you send the cosmetics patch along with it, it becomes easier to check which is wrong and which is right [20:11:09] <BastyCDGS> just compared with original, it's correct [20:11:24] <BastyCDGS> I even copied the original line to new one to compare [20:11:33] <BastyCDGS> the thing is that I removed one if/else completely [20:12:21] <BastyCDGS> or was i looking at wrong pos? [20:12:24] <BBB> maybe [20:13:34] <BastyCDGS> there is only one such a line in decode_frame_ilbm [20:13:59] <BastyCDGS> ohh i think i have it [20:14:34] <BBB> hehe :) [20:21:34] <BastyCDGS> you were correct on both parts but the first one one line was ok [20:21:38] <BastyCDGS> i'll submit to ml now [20:22:43] <BastyCDGS> sent [20:23:24] <BastyCDGS> for doing the remaining indentation it's best way to do a local git commit and then just correct indentation and then git diff right? [20:24:17] <wbs> for indentation stuff, personally i do the changes immediately, but then make patches using git format-patch -w, so that it ignores whitespace changes from the diff [20:25:21] <wbs> but if BBB wants a whitespace-only patch, too, you can e.g. apply the patch from format-patch -w on a separate branch, and diff that against the original branch [20:25:25] <wbs> or something like that ;P [20:25:46] <BastyCDGS> yes that's what he want [20:26:03] <BBB> you can also ask me to do it myself, I tend to not mind so much [20:26:39] * BBB thinks it's funny he responds "okay" but then doesn't actually attached the cosmetics patch ;) [20:28:05] <BastyCDGS> uhh what's wrong, did I miss sth.? [20:30:13] <BBB> no :) you're fine on this one [20:31:14] <BastyCDGS> so both are fine now...fine ;) [20:31:31] <BastyCDGS> then I'll do a local git commit and do the remaining indent stuff [20:31:59] <wbs> BastyCDGS: btw, learn to commit often in git, you're always able to rewrite the commit and change them later [20:32:11] <wbs> instead of working many days on one thing without ever committing inbetween [20:32:37] <BastyCDGS> hmm [20:32:40] <BastyCDGS> basty@cdgs-basty:~/src/ffmpeg$ git commit [20:32:40] <BastyCDGS> # On branch master [20:32:40] <BastyCDGS> # Changed but not updated: [20:32:40] <BastyCDGS> # (use "git add <file>..." to update what will be committed) [20:32:40] <BastyCDGS> # [20:32:41] <BastyCDGS> # modified: libavcodec/iff.c [20:32:41] <BastyCDGS> # modified: libavformat/iff.c [20:32:48] <wbs> please read the fine manual [20:33:31] <BastyCDGS> thought git add is only for new files [20:34:07] <wbs> git has this enormously useful feature called "staging" changes, learn to use it [20:34:35] <BastyCDGS> git commit -a [20:34:39] <BastyCDGS> is the way, right? [20:34:46] <wbs> if that's what you want to do, yes [20:35:13] <wbs> git however gives you the freedom to stage only some of the changes for committing in the current commit [20:35:24] <wbs> for separating logically distinct parts into separate commits [20:36:22] <elenril> read some tutorials at http://git-scm.com/ [20:38:17] <elenril> you'll spend like 20 minutes on one [20:38:31] <elenril> and it'll make everyone's life easier [20:38:37] <elenril> prevent global warming etc [20:39:39] <Kovensky> BastyCDGS: learn to use git gui too, it's very useful for selecting individual lines / chunks to commit [20:39:41] <elenril> btw anyone knows tikz? [20:39:52] <elenril> Kovensky: nah, git add -p is better =p [20:39:58] <elenril> guis are overrated [20:40:17] <BastyCDGS> I successfully were able to commit both libavcodec/iff.c and libavformat/iff.c as separate ;) [20:41:12] <elenril> now you just git format-patch -2 and :magic: [20:50:48] <BBB> BastyCDGS: good work! [20:50:55] <BastyCDGS> so both indent patches done [20:51:11] <BBB> we need someone with channel admin status here [20:51:15] <BBB> I think he needs a voice now [20:51:39] * BastyCDGS searches the unmute button in his face [20:52:21] <BBB> people who have submitted patches which have been accepted in svn/trunk get voice status in the channel, it's a sign of pure awesomeness [20:52:53] <BBB> or something like that [20:52:56] <BastyCDGS> well these patches aren't the first which got into trunk ;) [20:53:10] <BBB> well tell that to the channel admin who didn't know ;) [20:53:22] <BastyCDGS> but thank you very much [20:53:30] <BastyCDGS> what's the difference with a voice status? [20:54:20] <BBB> nothing [20:54:30] <BBB> you get this awesome yellow button in front of your name in xchat [20:54:41] <BBB> that's all :-p [20:54:48] <BastyCDGS> I'm using kvirc not xchat [20:55:12] <iive> you'll also be moved upper in the list, so it would be easy to spot your presence. [20:55:34] <BastyCDGS> ahh now I understand it's these guys listened with a prefixed V icon [20:56:01] <BBB> yes that! [20:56:17] <drv> well, the real purpose of voice is to be able to speak when the channel is +m, but not to have any other permissions [20:56:24] <drv> but usually this channel doesn't get +m anyway [20:58:02] <BastyCDGS> what is the reason here for muting this channel? [20:59:12] <drv> well, it usually never is, that's just a general irc tool [20:59:29] <drv> you can use it for things like a moderated chat with many listeners and a few speakers or something similar [20:59:53] <iive> well, few months ago, muting channel was needed to silence the horde of spam bots [21:00:15] <iive> it took week or two for freenode to roll out the final solution (tm). [21:00:25] <BastyCDGS> damn these fucking spammers [21:00:52] <BastyCDGS> btw, we've forgotten one patch, the minor-op patch...is there anything to do? [21:04:25] <BBB> I haven't reviewed that one yet [21:05:38] <BastyCDGS> mru reviewed it and he didn't found any negative except one indentiation which I should since it's a new line anyway fix with the patch and that I've done [21:05:59] <BastyCDGS> but he didn't reply to the fix, so from his point of view it's probably okay now [21:07:24] <wbs> BastyCDGS: no reply does NOT mean "ok for me" [21:07:47] <BastyCDGS> that's clear but he was complaining just one thing which I've fixed [21:08:11] <wbs> yes, but that does not mean that he's ok with the way that you've solved it, unless he has said "ok if you change it to FOO" or something like that [21:08:45] <wbs> but that's mostly relevant when you've got commit access so that you accidentally could be too triggerhappy and commit stuff before he gets a chance to say something [21:08:52] <BastyCDGS> > + for(i = 0; i < b; i++) { \ [21:08:52] <BastyCDGS> > >> + dst[ i ] |= get_bits1(&gb) << plane; \ [21:08:52] <BastyCDGS> > >> [21:08:52] <BastyCDGS> > [21:08:52] <BastyCDGS> > Since you're anyway rewriting that line, please drop the spaces inside []. [21:08:59] <wbs> ah, well such stuff is trivial [21:09:02] <BBB> ah, mru already said that [21:09:03] <BastyCDGS> that's all he complained ); [21:09:05] <BastyCDGS> ;) [21:09:09] <BBB> I complained about that too just now [21:11:10] <BastyCDGS> but I've tried to apply that patch now and it causes conflicts [21:11:43] <BastyCDGS> is that because I applied it after indentation? [21:13:31] <BastyCDGS> I just compared it and found out that it's exactly the lines where you have been complaining for before I did the indentiation as a second patch ;) [21:13:37] <BastyCDGS> now I finally understand why you want it this way... [21:13:57] <BastyCDGS> it avoids conflicts just because of indentation... [21:14:00] <BastyCDGS> right? [21:24:15] <BBB> yes [21:24:32] <BBB> but it's fine, I'll get them in eventually :) [21:25:02] <BastyCDGS> about the const thing what's exactly your issue there? [21:25:18] <BastyCDGS> b isn't going to be changed ever [21:31:38] <BBB> it's not necessary to mark it const, and I think it's in violation of the C spec to do so [21:31:44] <BBB> the second part is more severe than the first part [21:31:54] <BastyCDGS> why it's a violation of C spec? [21:31:55] <BBB> mru would be able to tell you for sure [21:32:04] <BBB> because it changes if bps/buf_size changes [21:32:06] <BastyCDGS> well, he didn't complain that when he reviewed it ;) [21:32:10] <BBB> const means it never changes :) [21:32:17] <BastyCDGS> but bps/buf_size doesn't change [21:32:23] <BBB> imagine you have a video player that plays video files [21:32:24] <BastyCDGS> only I and dst are changing [21:32:29] <BBB> first it plays one file with bps=X [21:32:32] <BBB> then one with bps=Y [21:32:36] <BBB> bps changed [21:32:46] <BastyCDGS> const means that it's just constant within function scope [21:32:52] <BastyCDGS> or block scope for that matter [21:33:12] <BBB> hmm... mru is that true? [21:33:22] <BBB> of course he went to sleep... [21:33:27] <BastyCDGS> http://tigcc.ticalc.org/doc/keywords.html#const [21:35:34] <BBB> "In this case, the const modifier allows you to assign an initial value to a variable that cannot later be changed by the program" [21:35:40] <BBB> that's ambiguous [21:35:47] <BBB> could be either what you said or what I said :) [21:36:10] <BastyCDGS> please reminder that const unsigned b is just local scope on stack ;) [21:36:18] <BastyCDGS> it will be killed when the function exits [21:36:29] <BastyCDGS> and within this scope it should be const [21:37:23] <BBB> I know, but that doesn't mean it's not in violation of the C spec [21:37:40] <BBB> although gcc doesn't appear to care... [21:37:49] <BastyCDGS> what should be the violation be? [21:37:57] <BBB> we'll have to ask mru tomorrow [21:38:10] <BBB> my personal opinion is that it's not needed, but if he's ok then we'll keep it :) [21:38:29] <BastyCDGS> this one is for me much more likely a violation: [21:38:29] <BastyCDGS> *(int*)&my_age = 35; [21:38:35] <BastyCDGS> when my_age ist const [21:38:39] <BastyCDGS> but I don't use that ;) [21:39:24] <BBB> that's because the (int*) itself is a violation [21:39:32] <BBB> a const int can only be addressed to as const int* [21:39:38] <BastyCDGS> Quoting from the ANSI C standard(8.2), "The purpose of const is to announce objects that may be placed in read-only memory, and perhaps to increase opportunities for optimization. ... Except that it should diagnose explicit attempts to change const objects, a compiler may ignore these qualifiers." [21:39:48] <BastyCDGS> http://www.ae.iitm.ac.in/pipermail/ilugc/2004-August/011781.html [21:40:02] <BBB> again ambiguous, can be either [21:40:04] <BBB> :) [21:40:07] <BBB> wait for mru tomorrow [21:40:23] <BBB> if it's read-only memory, then you have a problem [21:40:31] <BastyCDGS> const on float for example allows the compiler to put the value in the constant fp regs [21:40:32] <BBB> it's not like a static lookup table [21:43:09] <BastyCDGS> here is more detailed info:http://www.ericgiguere.com/articles/ansi-c-summary.html [21:43:13] <BastyCDGS> Special Modifiers [21:43:16] <drv> the compiler can usually prove constness of a local variable anyway [21:44:12] <BBB> gotta go now [21:44:17] <BastyCDGS> Initialization, however, is allowed ;) [21:44:19] <BBB> my recommendation is to remove it ;) [21:44:33] <BBB> because the compiler knows it isn't used in the loop [21:44:34] <BBB> anyway [21:44:35] <BBB> ... [21:44:46] <iive> "expecting gcc to do something right is exception, rather than rule" [21:45:04] <BastyCDGS> yes, it's even such dumb not moving out the calculation [21:45:14] <BastyCDGS> that's why I declared it const [21:45:22] <BastyCDGS> and moved out by hand [21:47:45] <BastyCDGS> well any optimization manual I read so far says that const should always be used when you don't change the variable in its life scope [21:48:05] <BastyCDGS> that's also what my professors say [21:49:00] <BastyCDGS> besides this const increases readibility...that was a huge discussion just recently ;) [21:49:09] <BastyCDGS> it tells the programmer that this variable shouldn't be changed [21:55:45] <BastyCDGS> drv, do you know where in which include lut resides? [21:56:06] <BastyCDGS> v= lut[get_bits(&gb, 4)]; [22:01:22] <drv> which file is it referenced in? if it doesn't have av_/ff_ prefix, it's probably not outside that file [22:02:38] <BastyCDGS> I dunno, Michael Niedermeyer recommended me to use this code to speed up [22:02:40] <drv> ah, i see the mail now, that's probably just michael meaning to create your own lookup table (lut), not an actual name of an existing array [22:03:38] <drv> i would guess since it's 4 bits, just make an array with all 16 possible inputs mapped to their corresponding output [22:04:02] <drv> (i.e. the index is the input and the content of that array location is the output) [22:04:24] <BastyCDGS> what does AV_WN32A and AV_RN32A do? [22:05:34] <drv> write/read 32-bit integer (the A means aligned, i think, and N means native endianness) [22:05:40] <drv> but grep the headers just to be sure :) [22:06:22] <BastyCDGS> #define AV_RNA(s, p) (((const av_alias##s*)(p))->u##s) [22:06:22] <BastyCDGS> s is 32 for WN32A [22:15:58] <BastyCDGS> looks to me that I should do the lookup table the following way [22:16:14] <BastyCDGS> for each set bit do an 1 << plane [22:17:14] <BastyCDGS> 0000 = 0, 0001 = 1 << plane, 0010 = 8 << plane, 0011 = 1 << plane | 8 << plane, etc. [22:21:51] <BastyCDGS> instead 8 = 0x100 sorry [23:36:54] <CIA-7> ffmpeg: stefano * r22964 /trunk/ffprobe.c: [23:36:54] <CIA-7> ffmpeg: Make ffprobe show stream->nb_frames if that info is known. [23:36:54] <CIA-7> ffmpeg: Patch by Robert Kr?ger $(echo kru3g3r@signal7.d3 | sed -e 's/3/e/g').