[FFmpeg-devel-irc] IRC log for 2010-04-25

[irc at mansr.com]

[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-hook  :(
[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_first_free_software_bluray/  http://news.ycombinator.com/item?id=1293135 http://slashdot.org/submission/1223280/x264-Project-Announces-Blu-ray-Encoding-Support
[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 at 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 at signal7.d3 | sed -e 's/3/e/g').