[FFmpeg-devel-irc] IRC log for 2010-06-21

[irc at mansr.com]

[01:04:29] <saintdev> peloverde: where should i put this sample?
[01:06:21] <CIA-92> ffmpeg: bcoudurier * r23672 /trunk/tools/qt-faststart.c: fail if input and output are the same
[01:07:30] <bcoudurier> just ported hqdn3d to avfilter
[01:08:17] <peloverde> saintd3v,  incoming
[01:08:26] <saintdev> can i upload there?
[01:08:38] <peloverde> yes
[01:08:47] <peloverde> incoming is write-only
[01:09:42] <saintdev> i knew that i just didn't know if anonymous had write permission
[01:12:19] <peloverde> let me know the filename when it is done
[01:12:40] <saintdev> ok, trying to get one that does it :P
[01:24:18] <saintdev> woohoo, got one
[01:24:37] <saintdev> peloverde: incoming/chan_elem_not_alloc/
[01:28:28] <peloverde> ok
[01:29:54] <mru> wtf is the matter with michael?
[02:01:56] <Kovensky> what happen
[02:05:11] <saintdev> somebody set up us the bomb
[02:06:24] <Kovensky> o rly
[02:07:32] <peloverde> o_O ಠ_ಠ
[02:08:29] * saintdev asplodes
[02:13:23] <astrange> i see faulty dts detection in ffplay, what kind of file could have non-monotonic dts?
[02:42:39] <peloverde> saintd3v, what's wrong with that file?
[02:43:32] <astrange> http://samples.mplayerhq.hu/archive/container/mpeg/mpeg%2bmpeg2video%2bac3%2b%2bnon_monotone_timestamps.mpg this one
[02:44:40] <peloverde> saintd3v, it spams some garbage but that's because it has a broken frame upfront, faad wont even play it
[02:45:00] <mru> why the hell does michael suddenly not want to optimise things?
[02:45:29] <peloverde> I wish he felt the same way about PS
[02:47:49] <saintdev> peloverde: ok, that's what it was. i suspected it was an incomplete frame. I just wasn't sure.
[02:53:05] <peloverde> In fact this is actually a pretty good example of the error tolerance of ffaacdec
[02:53:59] <peloverde> faad just worthlessly says "Error: Channel coupling not yet implemented"
[02:54:20] <mru> lol yet
[02:55:35] <saintdev> peloverde: how about a sample that causes a segfault?
[02:55:46] <saintdev> probably the same issue (incomplete leading frame)
[02:56:00] <peloverde> yes, segfaults are more interesting
[02:56:19] <saintdev> ok, do you want a bt, or not?
[02:56:54] <peloverde> bt?
[02:56:58] <saintdev> backtrace
[02:57:00] <mru> gdb
[02:57:10] <peloverde> ahh
[02:57:18] <peloverde> I can make my own/valgrind it
[02:57:22] <saintdev> ok
[02:58:57] <peloverde> "chan_elem_not_alloc-and-gt_1_rdb.aac" seems valgrind clean
[03:06:39] <saintdev> peloverde: incoming/ffmpeg_aacdec_segfault/
[03:06:46] <peloverde> ok
[03:49:11] <peloverde> Wow, that segfault file is behaving strangely
[03:51:08] <saintdev> should i have kept the gnomes out of my computer then?
[03:52:45] <peloverde> The first frame is an empty frame, wow!
[03:56:25] <peloverde> try_decode_frame handles the first frame fine because channel count is zero, then the second frame sets the channel count, and in spectral to sample it's called with the second channel count
[04:05:58] <CIA-92> ffmpeg: alexc * r23673 /trunk/libavcodec/aacdec.c: aacdec: Handle the first frame being empty case.
[04:06:13] <saintdev> \o/
[04:06:30] <peloverde> That should fix it
[04:07:03] <saintdev> sure does
[04:07:08] <astrange> ffmpeg -i <something with subtitles.mkv> -scodec xsub f.mkv creates a track with no codec type
[04:07:17] <astrange> at least according to mkvinfo
[04:08:06] <peloverde> saintd3v, and faad says "Error: Invalid number of channels"
[04:08:07] <CIA-92> ffmpeg: alexc * r23674 /trunk/libavcodec/aacdec.c: aacdec: Factorize if (elem_type < TYPE_DSE).
[04:09:58] <saintdev> yeah :P
[04:10:22] <saintdev> thanks again, i'll let you know if i have any more issues
[04:10:30] <peloverde> ok
[04:11:07] <CIA-92> ffmpeg: alexc * r23675 /trunk/libavcodec/aacdec.c: aacdec: cosmetics: whitespace
[04:15:08] <CIA-92> ffmpeg: alexc * r23676 /trunk/libavcodec/aacdec.c: aacdec: cosmetics: (more) whitespace
[04:16:07] <CIA-92> ffmpeg: astrange * r23677 /trunk/ffmpeg.c: ffmpeg: cosmetics: combine two variable declarations
[06:54:01] <Tjoppen> "Georgia To Become IT Tax Haven"
[06:54:59] <thresh> we should've invaded Tbilisi when we had a chance..
[06:58:58] <kshishkov> thresh: then Georgia wouldn't have its
[07:00:37] * kshishkov is very glad not to live in Ukraine now though
[07:01:17] <elenril> did they go bankrupt already?
[07:04:20] <thresh> kshishkov: you moved?
[07:04:48] <av500> he did
[07:04:51] <kshishkov> elenril: who? I f you mean Ukraine then it's almost bankrupt for two decades
[07:05:01] <av500> he, like greece
[07:07:27] <elenril> kshishkov: almost
[07:07:37] <kshishkov> av500: Greece is luckier, it just borrowed a lot of money and will enjoy watching Germans paying its debts
[07:07:47] <elenril> lolgreece
[07:09:10] <elenril> fun fact: slovakia (with much worse hdi/quality of life) had to borrow tons of money so they can give them to greece
[07:10:15] <elenril> at least cz is not in eurozone
[07:11:29] <Tjoppen> ooh, BBB applied my http patch. I'll have to test it and provide some feedback
[07:13:26] <av500> kshishkov: greece already payed all money it borrowed back by buying german submarines
[07:15:35] <kshishkov> elenril: really? Do they still use krona?
[07:15:55] <elenril> yes
[07:23:02] <wbs> elenril: any progress on them changing to euro? estonia is changing next year iirc
[07:25:08] <av500> is it "progress"?
[07:25:22] <elenril> ^this
[07:25:34] <elenril> our goverment doesn't want to change
[07:26:18] * kshishkov thought that Estonia had kronor for currency as any proper country
[07:26:53] <elenril> a few weeks ago our national bank got a new governor, and his first official statement was that we won't be switching to euro anytime soon
[07:27:40] * kshishkov still has a few thousand SEK to spend on lucky occasion
[07:27:50] <Tjoppen> :)
[07:27:52] <wbs> kshishkov: they have at the moment, yes
[07:28:00] <Tjoppen> sweden is still on SEK
[07:28:19] <wbs> av500: well, at least for those travelling a lot, it simplifies things ;P
[07:28:31] <kshishkov> Tjoppen: last year Sweden also used öre
[07:28:54] <Tjoppen> öre will be dropped in about a year or two
[07:29:08] <kshishkov> I thought it was already
[07:29:28] <av500> Tjoppen: dropped into the öresund?
[07:29:31] <Tjoppen> nope. but they switched to cheaper and smaller 50 öre coins a couple of years ago
[07:30:37] <iive> Tjoppen: would you mind switching your client to utf8 encoding. you are outputting latin1.
[07:32:20] <superdump> no one gives a crap about öre it seems
[07:32:28] <Tjoppen> not until next time this server restarts
[07:32:40] <Tjoppen> restarting screen+irssi is quite a pain
[07:32:56] <superdump> it's like a half-penny
[07:32:58] <wbs> Tjoppen: you can easily change what charset it outputs to a given channel
[07:33:00] <elenril> you don't need to restart anything
[07:33:17] <superdump> well, more like 5p i guess
[07:33:22] <Tjoppen> wbs: irssi - yes. screen - no (I think)
[07:33:31] <superdump> but 5p isn't useful really, except for 5p sweets
[07:33:42] <kshishkov> superdump: yes, more like fivepence
[07:33:45] <wbs> Tjoppen: yes, and you can use latin1 for your screen, but still making irssi recode all you write into utf8 for this channel
[07:33:48] <elenril> screen isn't utf-8 by default?
[07:33:58] <wbs> elenril: depends on your locale
[07:34:04] <Tjoppen> nope. it needs -U
[07:34:28] * elenril hopes they'll purge anything non-unicode soon
[07:34:31] <Tjoppen> oddly enough, my terminal has UTF-8. somewhere along the line it changes the encoding
[07:36:29] <siretart> moroning
[07:37:09] * kshishkov moves siretart to MKAD
[07:38:04] <elenril> so what's up with switching to git? are we waiting for end of gsoc or not?
[07:38:20] <superdump> kshishkov: what amuses me is watching "who wants to be a millionaire?" on swedish tv knowing that they'll get ~11x less than one would in england
[07:40:05] <kshishkov> superdump: it should be funnier in Russia - if they use the same numbers they get ~5 times less than in Sweden
[07:40:20] <superdump> :)
[07:46:37] <KotH> moin
[07:46:45] <kshishkov> gruess dich
[07:46:52] <av500> grüezi
[07:49:48] <siretart> kshishkov: what's MKAD?
[07:55:50] <benoit-> Moscow or Minsk?
[08:18:53] <kshishkov> benoit-: stupid question, MKAD in Minsk is not a state border
[09:01:35] <twnqx> hm. how would i run gdb on a program that reads from stdin - or rather, how do i pipe so that the piped data hits the debuged program and not gdb? :X
[09:02:20] <pross-au> cat foo | gdb --args ./a.out
[09:03:16] <twnqx> no, in that case gdb reads the data...
[09:03:51] <twnqx> and i get stuff like (gdb) warning: bad breakpoint number at or near '|20100611000255|6|21|ftp|754|867'
[09:05:51] <twnqx> oh well, coredump debugging will do
[09:06:01] <Tjoppen> use a named pipe?
[09:07:16] <twnqx> i'd have to rewrite the program. also, problem already solved :)
[09:08:06] <janneg> twnqx: write it into /proc/PID/fd/0
[09:08:32] <twnqx> hm
[09:08:41] * twnqx will try to remember when the program crashes again
[09:18:12] <CIA-92> ffmpeg: diego * r23678 /branches/0.6/RELEASE: Fix two small typos.
[09:24:56] <Kovensky> <@Tjoppen> wbs: irssi - yes. screen - no (I think) <-- C-a : utf8 on
[09:31:24] <Tjoppen> räksmörgås
[09:31:39] <spaam> Nice
[09:31:42] <Tjoppen> \o/
[09:31:56] <Tjoppen> ☃
[09:32:04] <iive> Tjoppen: congratulations :)
[09:32:09] <Tjoppen> that didn't seem to work
[09:32:33] <Tjoppen> (unicode snowman)
[09:32:37] <iive> looks like ring or a bomb
[09:32:52] <Tjoppen> I can paste it, but it doesn't show up correctly here
[09:33:10] <Tjoppen> http://unicodesnowmanforyou.com/
[09:33:39] <Tjoppen> or http://☃.net
[09:34:42] <iive> it shows correctly here, but antialiasing makes horrible things with it. inverted (selected) looks much better.
[09:38:54] <spaam> Tjoppen: using windows?
[09:40:29] <Tjoppen> nope, ubuntu
[09:40:46] <Tjoppen> the machine the screen is on run who-knows-what
[09:41:01] <Tjoppen> ah, solaris 10
[09:41:20] <spaam> what terminal do you use ? :)
[09:41:39] <Tjoppen> gnome terminal
[09:41:44] <spaam> urxvt is better with unicode stuff  :)
[09:42:12] <Tjoppen> bah, now all other channels encoding-fail
[09:45:20] <wbs> Tjoppen: like I said, you don't need to change it all for once, and it doesn't need to be the same as for other channels
[09:45:33] <wbs> Tjoppen: irssi has a flexible recoding framework, and you can set which charset to send to each channel
[09:46:08] <KotH> unfortunately, that framework does not allow channels with mixed encodings
[09:46:17] <Tjoppen> maybe so, but screen doesn't
[09:46:30] <Tjoppen> or.. hm
[09:46:44] <wbs> KotH: it handles latin1 and utf8 just fine at least
[09:47:01] <wbs> Tjoppen: yes, but screen should be set up to use the same as your terminal
[09:47:43] <wbs> if you've got a latin1 terminal and write åäö on a utf8-channel, irssi sends it encoded as utf8 over the line to the other users, but still displays it using latin1 on your own terminal
[09:48:04] <wbs> and likewise, when receiving things that other write, it detects which one of the charsets it uses and recodes it back to the charset your terminal uses
[09:48:11] * Tjoppen head asplode
[09:50:20] <wbs> you could just have done /recode add #ffmpeg-devel utf-8
[09:50:53] <wbs> and /set recode_out_default_charset latin1 so that it doesn't mess with your other channels
[10:36:38] <CIA-92> ffmpeg: diego * r23679 /trunk/libavutil/ (mips avr32): Ignore compiled headers.
[11:09:14] <twnqx> hm. are two-dimensional arrays implemented via pointers to pointers extremely inefficient?
[11:10:29] <Tjoppen> depends on how you iterate over it
[11:11:22] <mru> twnqx: why would you do that?
[11:11:47] <mru> the speed inefficiency obviously depends on how you access it
[11:12:09] <twnqx> http://pastebin.com/UXYheAZ5 - both function have the same absolute runtime in the profiler :X
[11:12:33] <mru> what should be looking at?
[11:12:38] <mru> *I
[11:12:46] <twnqx> the insert_line function...
[11:12:59] <twnqx> if if-clause hits about 26 times out of 120000 calls
[11:13:30] <twnqx> still it has the same absolute runtime as the parser below with lots of ascii-to-integer conversions
[11:13:43] <twnqx>  53.52      0.24     0.24  4801308     0.00     0.00  insert_line
[11:13:43] <twnqx>  42.37      0.43     0.19  4802382     0.00     0.00  parse_line
[11:13:46] <twnqx> if not worse.
[11:13:59] <mru> don't tell me you're using gprof
[11:14:04] <twnqx> i was...
[11:14:09] <mru> gprof cannot be trusted
[11:14:16] <mru> use oprofile
[11:14:27] <twnqx> meh, my kernel is not profiling enabled...
[11:14:32] <twnqx> but well.
[11:15:23] <mru> anyhow, accessing a single element from two-level pointer needs two memory loads
[11:15:27] <mru> only one with a flat array
[11:15:38] <twnqx> mh
[11:15:40] <mru> some CPUs have stupidly long load latencies
[11:16:27] <mru> if you're traversing it row-wise and cache the row pointers in local variables, it shouldn't make much difference
[11:16:28] <twnqx> the flat array would have 254*65535 never-to-be-used elements though
[11:16:37] <mru> sparse array?
[11:16:41] <twnqx> yes
[11:16:46] <mru> why didn't you say so
[11:16:52] <mru> that's a different story entirely
[11:16:52] <twnqx> 254 * 1 element, 2* 65536
[11:17:13] <twnqx> but fully random access anyway, and the memory to flatten it should be available
[11:17:23] <mru> are the rows also sparse?
[11:17:33] <twnqx> no
[11:17:46] <mru> so rows that exist have lots of things in them?
[11:17:59] <twnqx> each "element" is two longs
[11:18:11] <twnqx> (64bit long)
[11:18:32] <mru> how many in each row?
[11:18:47] <twnqx> either 1 (254 times), or 65536 (2 times)
[11:19:21] <mru> I don't get it
[11:19:35] <mru> if your 2d array were flat, how would you declare it?
[11:19:53] <twnqx> go non-sparse and waste the memory.
[11:20:05] <mru> just for sake of argument
[11:20:17] <mru> how would you declare the flat array?
[11:20:19] <mru> non-sparse
[11:20:32] <twnqx> mh. long array [256*65536*2];
[11:20:48] <mru> hmm flat was the wrong word
[11:20:58] <mru> how would you declare a simple 2D non-sparse array
[11:21:00] <mru> ?
[11:21:23] <twnqx> ugh. long array [256][65536]
[11:21:37] <mru> you said each element was two longs
[11:21:44] <twnqx> yeah.. i have a type for that...
[11:21:47] <mru> I'm guessing that struct at the top of your paste
[11:21:57] <twnqx> yes
[11:22:25] <twnqx> let me reboot quickly to use oprofile.
[11:27:11] <mru> so, you have 256 rows of 64k elements
[11:27:54] <mru> now, how are the populated elements distributed?
[11:28:58] <twnqx> in row 6 and row 17 about about 1-65535, in row 1, 41, 47 and 50 element 0
[11:29:21] <mru> I can't parse that
[11:29:45] <mru> are you saying only a few rows have any elements at all?
[11:29:52] <twnqx> it's about ip protocols (256 possible protocols), and ports for tcp and udp.
[11:30:03] <twnqx> yes, that's what i'm saying.
[11:30:47] <mru> and for the rows that exist, how many elements do they have?
[11:32:38] <twnqx> as i said, 6 and 17 will have 65536. all others will have one.
[11:32:48] <twnqx> (even if never used those will be allocated)
[11:33:31] <twnqx> for (i=0; i<256; i++) insert->volume[i] = calloc (sizeof(volume_t), (i == tcp || i == udp) ? 65536 : 1);
[11:33:35] <twnqx> this is the allocator...
[11:33:54] <mru> I'm starting to think this is the wrong approach
[11:33:55] <KotH> twnqx: if you want to store sparce matrices, there are data structures for exactly that
[11:34:02] <KotH> s/sparce/sparse/
[11:34:10] <av500> XML?
[11:34:39] <mru> av500: xml is for padding the unused cells
[11:34:42] <twnqx> let me just see if gprof was totally wrong first... and figure out how to use profile
[11:34:50] <twnqx> profile*
[11:34:53] <twnqx> oprofile*
[11:36:31] <mru> KotH: a generic sparse matrix isn't the right solution here
[11:37:15] <twnqx> well, i could remove the first level of pointers directly...
[11:38:17] <KotH> mru: hmm.. i havent read everything
[11:38:20] * KotH is lazy
[11:38:41] * KotH just wants to sound important by stating the obviously right and disapear again
[11:38:41] <mru> KotH: a generic data structure is almost never the best solution
[11:38:55] <mru> because reality is rarely generic
[11:40:09] <mru> twnqx: for tcp and udp, how many ports will actually be used?
[11:40:13] <mru> probably not all
[11:40:27] <twnqx> uh... just assume about all
[11:40:34] <mru> sure, lets pretend
[11:40:46] <twnqx> some hundred k user + P2P will cause it to be about exhaustive
[11:40:58] <mru> here's what you do
[11:41:03] <KotH> twnqx: what kind "thing" are you designing?
[11:41:13] <mru> flat array of 256+2*65k elements
[11:42:16] <mru> if (tcp) index=256+port; else if (udp) index 256+64k+port; else index=protocol;
[11:42:33] <KotH> that'll be 128MB of data
[11:42:38] <mru> no
[11:42:56] <mru> 1MB
[11:43:18] <KotH> oh.. right
[11:43:19] <mru> ~128k * sizeof(elem)
[11:43:39] <mru> if most of them are used, it's good enough
[11:44:41] <twnqx> port statistics generator... for a somewhat larger network operator
[11:47:19] <mru> hang on, this ain't right
[11:47:24] <mru> other protocols have ports too
[11:47:27] <mru> sctp for one
[11:49:32] <mru> but maybe you don't care about ports for the more obscure protos
[11:53:35] <av500> twnqx: so, you will censor us all soon....
[11:54:11] <mru> av500: we can trick him to include a buffer overflow to unlock it
[11:55:04] <twnqx> heh
[11:55:19] <twnqx> i built saudi arabias filter though :X
[11:55:42] * mru sends twnqx a turbomb
[11:55:52] <av500> I guess that was easy, apply wire cutters to uplink
[11:59:36] <mru> http://www.theregister.co.uk/2010/06/21/amiga_x1000/
[11:59:38] <mru> whyyyyyyyyyyyyy
[12:00:22] <av500> dont show basty_CDGS
[12:01:11] <mru> http://acp.atari.org/
[12:01:59] <mru> there's something fundamentally wrong with designing old computers
[12:02:43] <mru> running an original vintage machine is one thing
[12:03:21] <KotH> friend of mine once designed a pdp-11 "emulator" on a fpga
[12:03:45] <mru> pdp-11 implementations are a special case
[12:04:10] <mru> it's the hw equivalent of running doom on as many devices as possible
[12:05:32] <KotH> mru: either these guys have nothign else to do or too much time at hand
[12:05:38] <KotH> or both
[12:05:52] <KotH> mru: and th company who's doing that is just a few km south of zh
[12:06:31] <mru> you know what you have to do
[12:06:44] <KotH> call them and ask them for a sample? ;)
[12:07:45] <av500> join them?
[12:09:18] <Tjoppen> are you supposed to only set AVPacket::pts before interleaving? av_interleaved_write_frame() nags about pts < dts otherwise. I'm guessing it infers better values for dts
[12:10:16] <Tjoppen> max_b_frames = 2 -> dts = 0, 1, 2, 3; pts = 0, 3, 1, 2
[12:13:00] <Tjoppen> works if only setting pts. I guess it does some kind of sorting maneuver
[12:13:40] <wbs> Tjoppen: yes, lavf does that internally, see lavf/utils.c, compute_pkt_fields2 or something similar
[12:13:53] <wbs> Tjoppen: it sets dts = -2, -1, 0, 1, in that case, iirc
[12:14:04] <mru> Tjoppen: that's what you get with an IBBP sequence
[12:15:44] <Tjoppen> ok. that makes sense
[12:16:20] <Tjoppen> I think I'll stick to only setting pts then. either using pts or dts, depending on which is AV_NOPTS_VALUE
[12:16:32] <Tjoppen> but wait a minute.. how the hell does that work with VFR?
[12:17:08] <Tjoppen> if I have pts = 0, 10, 1, 5..
[12:17:22] <wbs> Tjoppen: then it produces -2, -1, 0, 1, 5, 10
[12:17:37] <wbs> the source has it all
[12:17:50] <Tjoppen> right, it doesn't matter too much exactly when decoding happens, as long as it's before presentation
[12:56:12] <mru> Dark_Shikari: ping
[12:56:28] <Dark_Shikari> mru: pong
[12:56:54] <mru> do you have any statistics of block_last_index for typical videos?
[12:57:01] <Dark_Shikari> Depends heavily on the video format.
[12:57:19] <Dark_Shikari> But if you want to make a custom idct, I've seen 3 types of shortcut-idct:
[12:57:25] <Dark_Shikari> (and on the bitrate)
[12:57:29] <Dark_Shikari> 1: idct dc (easy)
[12:57:48] <mru> but not all too common in high-bitrate video
[12:57:52] <Dark_Shikari> no, still quite common
[12:57:55] <Dark_Shikari> totally worth it
[12:58:00] <Dark_Shikari> 2) idct that handles block_last_index 2 or so (coreavc does this one)
[12:58:18] <Dark_Shikari> 3) idct for the top left of the dct (i.e. 10 coeffs, due to the zigzag pattern), theora does this
[12:58:24] <Dark_Shikari> 3) is very very useful even at high bitrates
[12:58:52] <mru> yes, I suspected as much
[12:59:18] <Dark_Shikari> also, keep in mind for non-bit-exact idcts, shortcut idcts tend to be easier.
[12:59:38] <Dark_Shikari> e.g. for coreavc's 2-coeff idct, it still has to emulate a transpose
[12:59:44] <Dark_Shikari> it can't e.g. add basis functions
[13:00:20] <mru> I'm just thinking about the interfaces
[13:00:54] <mru> passing block_last_index to the idct makes sense
[13:01:15] <Dark_Shikari> absolutely
[13:01:18] <mru> so each implementation can choose whatever shortcuts it wants
[13:02:15] <mru> and call the same function even for dc-only
[13:02:28] <mru> some codecs already have a special idct_dc pointer
[13:05:06] <av500> mru: what was the name of that env var that pkgconfig does not honour?
[13:06:11] <mru> av500: pick any name
[13:06:19] <av500> lol
[13:07:03] <av500> never mind, coworker found the fix: rm -rf $(BUILD_DIR)/lib/pkgconfig
[13:08:05] * mru likes that style
[13:20:43] <mru> Dark_Shikari: do you understand michael's latest reply?
[13:22:55] <Dark_Shikari> Nope.
[13:22:57] <Dark_Shikari> lol
[13:29:31] <kshishkov> I think he hints on the fact that 63th 1-bit element will cause noise less than rounding value for DC, so it'ssafe to ignore it
[13:30:06] <mru> a 1 in the 63rd coeff scatters +-1 over the block, yes
[13:30:10] <mru> but the spec mandates it
[13:30:29] <mru> otherwise we could just skip it entirely
[13:30:40] <mru> and he rejected that
[13:30:50] <mru> rightfully
[13:30:55] <mru> I hadn't checked the spec
[13:34:34] <Dark_Shikari> kshishkov: It isn't less than rounding value for DC at high quants
[13:39:51] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/83HxCxGQ ?
[13:39:58] <BBB> that's the idct_dc_add
[13:40:18] <BBB> I unrolled the loop also, made no difference
[13:40:32] <Dark_Shikari> for that you should unroll the loop, it will basically be shorter
[13:40:38] <Dark_Shikari> oh, you're doing it the slow way!
[13:40:41] <Dark_Shikari> you need to see the fast way to do it.
[13:40:46] <BBB> ?
[13:40:53] <BBB> I'm a beginner
[13:41:02] <BBB> there's a fast way?
[13:41:18] <Dark_Shikari> x264: common/x86/dct-a.asm
[13:41:22] <BBB> the problem is that the DC is 16-bit, so I do byte->word->byte
[13:41:23] <Dark_Shikari> lines 315 to 350
[13:41:36] <Dark_Shikari> Aka how to about the punpck.
[13:42:39] <Dark_Shikari> if you can't figure out why it works, ask questions until you do.
[13:43:49] <Dark_Shikari> Now unroll it and it'll only be 4 load, 8 add/sub, 4 store.  plus init code.
[13:44:17] <BBB> there's no sub
[13:44:18] <BBB> only add
[13:44:22] <BBB> ?
[13:44:34] <BBB> I probably have to read your code first :-p
[13:45:00] <Dark_Shikari> I gave you the lines of code
[13:45:00] <Dark_Shikari> read them
[13:45:09] <Dark_Shikari> and yes there's sub.
[13:46:46] <BBB> dc = (block[0] + 4) >> 3; (16x) av_clip_uint8(dst[0] + dc)
[13:46:49] <BBB> wheres the sub?
[13:47:06] <BBB> and why do you calculate the negative dc?
[13:47:31] <BBB> you do mm0=(block+32)>>7, mm1=-mm0
[13:47:37] <Dark_Shikari> You need to add a 9-bit signed integer to a uint8_t.
[13:47:44] <Dark_Shikari> Right?
[13:48:11] <Dark_Shikari> One way to do this is to do an add with saturation, then a subtract with saturation.
[13:48:41] <Dark_Shikari> for example.
[13:48:55] <BBB> I think I get it
[13:49:00] <Dark_Shikari> suppose dc is 130
[13:49:01] <BBB> if it's negative, the add is 0
[13:49:03] <Dark_Shikari> 80 += 130
[13:49:05] <BBB> because it's saturated?
[13:49:05] <Dark_Shikari> 80 -= 130
[13:49:06] <Dark_Shikari> Yeah
[13:49:17] <BBB> if postiive, the sub is 0
[13:49:19] <Dark_Shikari> yup
[13:49:21] <BBB> because you saturated it
[13:49:41] <BBB> interesting
[13:49:48] <BBB> my blocks are only 4x4 though
[13:50:14] <BBB> let me test that
[13:50:17] <BBB> it makes a little sense
[13:50:25] <Dark_Shikari> still works on 4x4
[13:50:28] <BBB> have to make sure it's faster for a 4x4 block
[13:50:36] <BBB> right, but for a 4x4 I'm not 100% sure it's still faster
[13:50:37] <Dark_Shikari> already confirmed for h264
[13:50:37] <BBB> it might be
[13:50:40] <BBB> have to test :)
[13:50:49] <Dark_Shikari> ffmpeg already does it for h264
[13:50:54] <BBB> ok
[13:50:58] <BBB> I'll check that function
[13:51:08] <Dark_Shikari> which is 4x4.
[13:52:25] <Dark_Shikari> it's 5 extra psub to save 4 punpck and 4 packuswb
[13:52:28] <Dark_Shikari> so 3 instructions less
[13:53:03] <BBB> true
[13:53:56] <BBB> I noticed psubusb/paddusb, but wasn't sure how helpful they'd be because the DC is short, not 8-bit, I didn't know it was 9-bit (8+sign?)
[13:54:12] <BBB> but I guess it doesn't matter
[13:54:16] <BBB> because it's saturated
[13:54:17] <BBB> ...
[13:54:20] * BBB needs to think more
[13:54:30] <BBB> I guess learning asm is good ;)
[13:54:36] <BBB> we should do sse2 some day now
[13:54:56] <BBB> also, if pshufw is absent, it's a mmx-only function, right? no mmxext
[13:55:01] <twnqx> mru: how would you access that suggested array, something like #define indexof(prot, port) (prot == 6 ? 256 + port : prot == 17 ? 256 + 65536 + port : prot) ?
[13:55:05] <BBB> I tried to write it without pshufw, which is actually faster
[13:55:33] <twnqx> it actually is way faster indeed, i just wonder if there's a better way
[13:55:50] <mru> twnqx: calculate the index however you want
[13:56:00] <mru> I gave you one option
[13:56:07] <twnqx> i tried different ones
[13:56:08] <mru> you quote another above
[13:56:16] <mru> I doubt it makes much difference
[13:56:46] <twnqx> yeah, ?: or if...else shouldn't make much difference
[13:57:02] <twnqx> i just wondered if there's a way around code
[13:57:06] <twnqx> but well, so be it
[13:57:22] <twnqx> 250k lines/second now
[13:57:33] <mru> and before?
[13:57:37] <twnqx> ~170k
[13:59:23] <Dark_Shikari> BBB: there are other mmxext-only things
[13:59:34] <Dark_Shikari> always check before you list it as one or the other
[13:59:46] <BBB> I need a cheatsheet for that
[13:59:49] <BBB> intel's docs are of no use
[14:04:00] <Dark_Shikari> http://alien.dowling.edu/~rohit/nasmdocb.html
[14:04:15] <Dark_Shikari> if it's listed as "williamette, sse2" in that doc, it's mmxext
[14:04:20] <Dark_Shikari> if it's listed as "katmai, mmx", it's mmx
[14:04:33] <Dark_Shikari> er, oops
[14:04:34] <Dark_Shikari> I mean
[14:04:38] <Dark_Shikari> katmai, mmx -> mmxext
[14:04:44] <Dark_Shikari> pent, mmx -> mmx
[14:04:55] * mru hates intel codenames
[14:05:55] * BBB too
[14:08:26] <Dark_Shikari> http://x264dev.multimedia.cx/?p=472
[14:13:01] <BBB> Dark_Shikari: I don't think it'd be faster
[14:13:09] <BBB> notice how my loop is only five calls
[14:13:34] <BBB> (I didn't try yet, I just am waking up with coffee)
[14:14:24] <Dark_Shikari> "my loop is only 5 calls"?
[14:14:37] <Dark_Shikari> keep in mind also that punpck is slow
[14:14:47] <Dark_Shikari> even in mmx, where it's 1 cycle, punpck and pack share a single execution unit
[14:14:53] <Dark_Shikari> you can only execute one per cycle on any cpu prior to the i7
[14:15:02] <Dark_Shikari> by comparison you can execute three adds/subs per cycle
[14:15:37] <mru> does i5 differ from i7 in any of this?
[14:15:40] <Dark_Shikari> no
[14:15:52] <Dark_Shikari> let's get some terminology straight
[14:15:56] <Dark_Shikari> everything iWhatever is "nehalem"
[14:16:00] <Dark_Shikari> 45nm core 2 is "penryn"
[14:16:03] <Dark_Shikari> 65nm core 2 is "conroe"
[14:16:19] <Dark_Shikari> yes they use different codenames for some permutations of those, but three is enough to cover all of what matters
[14:16:33] <Dark_Shikari> i.e. all variations on the nehalem are just different numbers of cores and jazz, not actual ALU changes
[14:16:54] <mru> my i5 is allegedly an "arrandale"
[14:17:28] <Dark_Shikari> the codenames are easy to deal with if you stick with one per generation
[14:17:37] <Dark_Shikari> "conroe" is much easier than "that 65nm core 2 chip that had a slow shuffle unit"
[14:17:56] <mru> but how am I supposed to know that arrandale means nehalem?
[14:19:13] <Dark_Shikari> you don't.  you just know it's an iWhatever
[14:19:15] <Dark_Shikari> so it's a nehalem.
[14:19:48] <av500> mru: you need a wiki :)
[14:21:30] <mru> Dark_Shikari: unlike you, I wasn't born with the intel codename table hardwired in my brain
[14:21:50] <av500> there was no space left beside the gcc standard yu swalloed as a kid...
[14:22:17] <Dark_Shikari> mru: you at least know about the generations
[14:22:20] <Dark_Shikari> iWhatever -> nehalem
[14:22:23] <Dark_Shikari> 45nm core 2 -> penryn
[14:22:24] <mru> no I don't
[14:22:25] <Dark_Shikari> 65nm core 2 -> conroe
[14:22:29] <Dark_Shikari> That's it.
[14:22:31] <Dark_Shikari> That's all you need to know.
[14:22:43] <mru> and how do I know what my core2 is?
[14:22:54] <Dark_Shikari> Does it have SSE4.
[14:22:55] <Dark_Shikari> ?
[14:22:57] <Dark_Shikari> If so, it's a penryn.
[14:23:00] <Dark_Shikari> If not, it's a conroe.
[14:23:02] <mru> don't remember
[14:23:07] <Dark_Shikari> cat /proc/cpuinfo
[14:23:10] <Dark_Shikari> let your linux remember for you
[14:23:10] <mru> not powered on
[14:23:13] <Dark_Shikari> lol
[14:23:27] <mru> I do have another that's running...
[14:23:36] <mru> a T7200
[14:24:12] <mru> which sss*e[0-9] is aka pni?
[14:24:50] <kshishkov> mru: use electronic microscope then
[14:24:56] <mru> the other core2 is a Q6700 iirc
[14:27:24] <janneg> T7200 should be 65nm, pni is sse3
[14:28:06] <mru> not that I really care
[14:29:38] <pJok> note to self: 4TB disks in winxp... no go...
[14:29:49] <mru> there are 4TB disks?
[14:29:53] <mru> or some fancy hw raid/
[14:29:56] <janneg> raid0?
[14:30:09] <pJok> raid0
[14:30:17] <pJok> some WD hardware raid box
[14:30:39] <mru> I take it you don't value your data much
[14:30:51] <av500> it'S just pron
[14:30:58] <mru> ah
[14:31:15] <pJok> mru, its not my data... im a sysadmin... to me data is just protocol overhead
[14:31:20] <mru> the first company I worked for had a 3TB array with mostly porn
[14:31:23] <mru> this was in 2003
[14:31:27] <mru> 3TB was a lot
[14:31:29] <av500> MPEG4 sprites would encode it nicely in a few MB...
[14:35:17] <pJok> mru, that and its really just a drive for transport
[14:35:24] <pJok> the data is multiple places already
[15:01:40] <av500> BBB: did you look into that android violator app?
[15:01:45] <BBB> not yet
[15:01:50] <BBB> busy with other things right now
[15:01:51] <BBB> but I will
[15:01:54] <av500> k
[15:01:57] <BBB> I spend like a full day on that every couple of weeks
[16:39:14] <BBB> if I want to do a 32-bit store (in C, not asm), would I normally do a #if BIG_ENDIAN ... #else ... #endif and then AV_WN32(), or would I just load the value in some order and use AV_WL/B32?
[16:39:20] <BBB> this is in performance-critical code
[16:40:11] <BBB> (or maybe not, it's a _c version of some function basically)
[16:40:23] <mru> huh?
[16:40:27] <mru> what are you trying to do?
[16:41:15] <av500> is it impolite here to ask if ppl want to earn $ with windows coding job (non-ffmpeg)?
[16:41:16] <Dark_Shikari> you mean a 32-bit copy?
[16:41:25] <mru> av500: you already did
[16:41:59] <av500> doh
[16:44:37] <BBB> Dark_Shikari: 4 8-bit copies
[16:44:44] <BBB> x[0]=bla;
[16:44:48] <BBB> x[1]=otherbla;
[16:44:49] <BBB> etc.
[16:45:02] <Dark_Shikari> *(uint32_t*)x = *(uint32_t*)y
[16:45:04] <BBB> (and that repeated at different rows, so x[stride+0]=bla
[16:45:15] <Dark_Shikari> oh you mean the values need to be packed up
[16:45:19] <BBB> yes
[16:45:23] <Dark_Shikari> is it a splat, or a pack?
[16:45:28] <BBB> pack
[16:45:30] <BBB> they're different
[16:45:44] <Dark_Shikari> what's this for
[16:45:51] <BBB> vertical prediction
[16:46:01] <Dark_Shikari> that's easy
[16:46:03] <Dark_Shikari> look at h264
[16:46:18] <Dark_Shikari> uint32_t top pixels  = *(uin32t_t*)top
[16:46:30] <mru> AV_RN32A please
[16:47:11] <BBB> it's a little different
[16:47:21] <BBB> vp8 doesn't copy top
[16:47:27] <BBB> it does some math on each pixel
[16:47:33] <BBB> so I end up with 4 values, probably 8-bit
[16:47:44] <BBB> mru: ok
[16:47:52] <Dark_Shikari> er, what?  what does it do then?
[16:48:07] <BBB> look at david's vp8 patch, pred4x4_vertical_vp8_c
[16:48:21] <Dark_Shikari> I do'nt have it
[16:48:24] <BBB> src[0+0/1/2/3*stride] = (lt + 2*t0 + t1 + 2) >> 2;
[16:48:42] <BBB> and then different lt/t0/t1/etc combinations for 1/2/3+...
[16:49:16] <BBB> lt=pixel topleft, t1 = pixel topright, t0 = pixel on top
[16:49:23] <av500> mru: btw, if anybody ever mentions OMX, just run...
[16:49:41] <Dark_Shikari> BBB: don't pack it, just assign it directly
[16:49:43] <Dark_Shikari> and write asm later
[16:49:51] <BBB> michael wants 32-bit stores
[16:49:55] <BBB> I want to commit the basic decoder
[16:50:02] <BBB> so I need 32-bit stores :-p
[16:50:09] <Dark_Shikari> that's stupid
[16:50:12] <BBB> yes
[16:50:17] <Dark_Shikari> then you need a pack8to32 macro
[16:50:18] <BBB> but I still need 32-bit stores
[16:51:17] <BBB> it makes some sense, I write the same 4 values in each row, so packing them and writing them as a 32-bit value (per row) is likely faster
[16:51:47] <Dark_Shikari> packing them takes a ton of ops
[16:51:51] <Dark_Shikari> you're not memory-bound here
[16:52:20] <BBB> so the pack8to32() macro is a if (BIG_ENDIAN) { ... } else { .. }?
[16:52:54] <BBB> or, well, BIG_ENDIAN ? x<<24|y<<16|etc : y|y<<8|etc;?
[16:53:04] <BBB> and then have the compiler figure it out
[16:53:34] <mru> av500: yeah, I know omx is bad
[16:54:20] <mru> is it one of those "standards" that everybody does differently?
[16:54:27] <mru> or does it just suck anyway?
[16:54:44] <av500> can u imagine that the arm side OMX wrapper around an MPEG2 dsp codec is 8000 lines of C?
[16:55:54] <mru> easily
[16:56:08] <mru> and that's the app code _calling_ omx, right?
[16:56:19] <av500> no
[16:56:33] <av500> MPEG2 decoder on DSP, running under brdige
[16:56:34] <mru> only 8k lines for omx itself?
[16:56:38] <av500> yes
[16:56:42] <av500> for the OMX self wank
[16:56:58] <av500> to expose this dsp side mpeg2 decoder to an OMX app
[16:57:13] <av500> of course the code is also dead ugly
[16:57:29] <KotH> av500: i hope you're not surprised. it's comercial code after all
[16:58:53] <av500> only mildly surprised
[16:59:29] * mru doesn't get surprised anymore
[17:02:15] <CIA-92> ffmpeg: reimar * r23680 /trunk/ (4 files in 2 dirs):
[17:02:15] <CIA-92> ffmpeg: mathematics.h no longer needs config.h, so update tablegen code and
[17:02:15] <CIA-92> ffmpeg: documentation to use it where appropriate.
[17:28:04] <j0sh_> wbs: thanks for the tips on depacketizer samples
[17:33:43] <wbs> j0sh_: I hope I don't scare you to death with untangling the aac/rtp stuff - I guess you start seeing the dire need of getting that code out of rtsp.c? :-)
[17:38:07] <verb3k> wbs, will you commit the libvorbis patch for fixing the packet dropping issue?
[17:41:54] <j0sh_> wbs: i was actually afraid i missed some things. i saw that code, but wasn't sure if it was used by other formats, so just left it there
[17:44:00] <wbs> verb3k: yeah, I'll wait and see if I can get another explicit ok out of Yuvi, but if I don't see him here, I'll probably just apply it in a few days
[17:44:27] <wbs> j0sh_: yeah, that's the problem, it looks all generic and fine, litters the generic code with format specific stuff
[17:47:48] <j0sh_> alright
[17:50:58] <wbs> j0sh_: I added another task on the wiki checklist btw, that I think I've mentioned - sharing code for sdp line parsing, since many of the rtp depacketizers have a quite similar parsing loop
[17:54:32] <j0sh_> ok cool
[17:54:56] <j0sh_> is there any reason one would make multiple reads/writes from the same ffhttp handler?
[17:55:27] <wbs> multiple separate connections you mean? no
[17:55:41] <j0sh_> on the same connection
[17:56:13] <j0sh_> eg, send POST header, get reply, send POST data, get more replies, etc
[17:56:25] <wbs> ah, I see
[17:56:43] <wbs> no, for normal HTTP, you send the full POST header and the POST data, and don't get back any reply until you've sent all that
[17:56:54] <j0sh_> thats what i thought, alright
[17:57:20] <j0sh_> i think it should be safe to reuse chunksize, then
[17:57:35] <wbs> yeah, I've got a patch for that coming up
[17:57:48] <j0sh_> i think that multiple reads/replies is why i added that is_chunked, since i didnt want replies to overwrite our chunked preference
[17:59:39] <wbs> yeah... semantically, I'd rather use something like is_chunked or chunked_post or whatever for the posts, to keep it clear (and setting chunksize for posts feels unintuitive), but I'm ok with it for now
[17:59:46] <wbs> I'm preparing a patch for that right now
[18:00:01] <j0sh_> indeeed
[18:02:26] <Kovensky> wbs: no pipelining?
[18:05:07] <j0sh_> isn't pipelining a matter of reusing the tcp connection, not the http connection?
[18:06:14] <wbs> Kovensky: posts and such shouldn't be pipelined anyway
[18:22:39] <BBB> wbs: almost correct ;-) your patch just reverted my fixing tjoppen's bug yesterday :-p
[18:23:01] <wbs> BBB: uhm, no?
[18:25:55] <wbs> BBB: for get, it first sets chunksize to 0 in http_open, which doesn't matter at all since it's overwritten with -1 in http_connect again, just exactly as you fixed it yesterday, I just moved the s->chunksize = -1; down to below the if (post)
[18:26:24] <wbs> BBB: for POST, it sets chunksize to 0 (default to chunked) in http_open so that it can be overwritten with -1 if we want to disable chunking, before calling http_connect
[18:41:43] <CIA-92> ffmpeg: mstorsjo * r23681 /trunk/libavformat/http.c: HTTP: Clarify a comment
[19:00:22] <BBB> I see waht you're doing, patches are fine then
[19:00:33] <wbs> ok, great!
[19:02:26] <CIA-92> ffmpeg: mstorsjo * r23682 /trunk/libavformat/http.c: HTTP: Get rid of the is_chunked variable, use the chunksize variable instead
[19:03:03] <CIA-92> ffmpeg: mstorsjo * r23683 /trunk/libavformat/http.c: HTTP: Compact the code for writing chunked post data
[19:03:03] <CIA-92> ffmpeg: mstorsjo * r23684 /trunk/libavformat/http.c: Reindent
[19:24:13] <mru> I can't believe we're having this stupid idct discussion
[19:24:33] <mru> for 10 fuckin years nobody has bothered to optimise based on last coeff
[19:24:49] <mru> and now it's hinging on some ridiculous "feature" of mpeg2
[19:25:47] <mru> just setting the last_coeff correctly would give no slowdown at all compared to _not bloody optimising it_
[19:26:37] <mru> and _all other cases_ would get faster
[19:30:52] <mru> Dark_Shikari: ping
[19:40:06] <Dark_Shikari> mru: pong
[19:40:24] <mru> Dark_Shikari: I'm getting tired of idct bikeshedding
[19:40:40] <Dark_Shikari> yes it's retarded
[19:41:06] <mru> forget about mpeg2
[19:41:20] <CIA-92> ffmpeg: mstorsjo * r23685 /trunk/libavformat/ (http.c http.h): HTTP: Add a method for initializing the authentication state from another connection
[19:41:27] <Dark_Shikari> it's not my job
[19:41:29] <Dark_Shikari> if you want to do it
[19:41:30] <Dark_Shikari> just do it
[19:41:58] <CIA-92> ffmpeg: mstorsjo * r23686 /trunk/libavformat/rtsp.c: RTSP: Use the same authentication for the HTTP POST session as for the GET
[19:42:04] <mru> but I can't optimise the idct with invalid last_coeff
[19:42:19] <mru> and michael stubbornly refuses to FIX A BUG
[19:42:45] <Dark_Shikari> Remember when you rolled back my commit access because I tried to fix a bug?
[19:42:51] <Dark_Shikari> Now you know how it feels.
[19:43:02] <Dark_Shikari> Michael thinks your concerns are invalid
[19:43:06] <Dark_Shikari> and is bikeshedding to avoid fixing the problem.
[19:43:28] <mru> isn't the the one who makes a huge ordeal over 0.00000001% speed difference?
[19:43:33] <Dark_Shikari> It doesn't matter who is right -- what matters is development is being held up because nobody can decide who is right.
[19:43:41] <Dark_Shikari> mru: yes, that's michael
[19:43:52] <Dark_Shikari> He will not lose 0.00001% speed, even to gain 10% speed.
[19:44:03] <Dark_Shikari> That's why the ffmpeg decoders are still so slow and unoptimized
[19:44:05] <mru> fixing this will not lose _any_ speed
[19:44:19] <mru> it's like THREE INSTRUCTIONS_ per MB
[19:44:26] <mru> per block, sorry
[19:44:26] <Dark_Shikari> no, per block, not per mb
[19:44:41] <Dark_Shikari> The fact that I was able to trim 30-40% off the ffmpeg decoder in one or two days is proof that michael's attitude is holding up development
[19:45:13] <mru> you also threw out 90% of functionality
[19:45:23] <Dark_Shikari> I did, but it still decoded FLV correctly
[19:45:29] <Dark_Shikari> If it had been templated, you could have gotten all the speed boost
[19:45:33] <Dark_Shikari> with none of the functionality loss
[19:45:40] <Dark_Shikari> also, most of the speed boost was from functions that would have been trivial to template
[19:46:06] <Dark_Shikari> For example, the mere fact that the flv escape coeff decoding isn't inlined into the h263 block decode loses a few hundred clocks per mb
[19:49:14] * kshishkov eagerly awaits for another burst of troll-driven speedups
[19:50:32] <peloverde> jesus, that's a huge vpx changeset
[19:50:58] <Dark_Shikari> peloverde: lots of minor changes
[19:51:09] <Dark_Shikari> oh
[19:51:10] <Dark_Shikari> trailing whitespace
[19:51:26] <peloverde> sounds like somebody nevere learned about git-hooks
[19:51:44] <mru> someone committed trailing whitespace?
[19:52:12] <Dark_Shikari> yes
[19:52:30] <peloverde> What with renaming *.asm to *.S?
[19:52:37] <Dark_Shikari> peloverde: retards
[19:52:50] <peloverde> @redhat.com
[19:52:51] <peloverde> , what do you expect
[19:53:23] <mru> .S is the standard suffix for c-preprocessed assembler
[19:53:40] <Dark_Shikari> of course, it isn't c-preprocessed
[19:59:34] <mru> Dark_Shikari: since there are multiple shortcut cases, do you think passing last_coeff to the idct func is better than a separate idct_dc function?
[20:00:19] <Dark_Shikari> Yes.
[20:10:43] <Dark_Shikari> mru: new candidate for "most annoying type of developer"
[20:10:49] <Dark_Shikari> the developer who does git format-patch | sendmail.
[20:10:57] <Dark_Shikari> a guy just dumped 50 patches from a git local tree onto the vp8 mailing list
[20:11:20] <Dark_Shikari> "it includes such great commits as "rename" "Forgotten .asm->.S fixups." "Finish the merge."
[20:11:23] <Dark_Shikari> "
[20:11:34] <BBB> yeah my inbox was stuffed
[20:11:38] <BBB> fortunately it was only 49
[20:11:38] <Dark_Shikari> Oh, and he converted all the asm unlaterally to GAS syntax,.
[20:11:42] <Dark_Shikari> For no apparent reason.
[20:11:50] <Dark_Shikari> 04:11 < derf> My personal favorite "heavy". That's the entire commit message.
[20:12:02] <mru> what syntax was it before?
[20:12:05] <Dark_Shikari> yasm
[20:12:16] <Dark_Shikari> Yes, going from yasm _to_ gas, for x86.
[20:12:26] <mru> where's the sense in that?
[20:12:28] <twnqx> at&t lover :S
[20:12:30] <Dark_Shikari> There is none!
[20:12:32] <Dark_Shikari> it's retarded!
[20:12:35] <peloverde> wtf, how is the mediacoder guy ranked 90 on ohloh?
[20:12:44] <Dark_Shikari> peloverde: ohloh is a popularity competition
[20:12:46] <mru> can we downvote him?
[20:12:52] <Dark_Shikari> it's like facebook
[20:12:54] <Dark_Shikari> 'I like this'
[20:13:02] <mru> facebook sucks
[20:13:05] <Dark_Shikari> exactly
[20:13:08] <Dark_Shikari> ohloh is facebook for open source
[20:13:19] <mru> whoever has more imaginary friends when he dies, wins
[20:13:45] <mru> a friend IRL is worth 1000 on facebook
[20:13:59] <Dark_Shikari> I'm pretty sure 1000 facebook friends actually has negative worth
[20:14:20] <mru> I don't know anyone who has that many
[20:14:21] <BBB> I agree with that one
[20:14:37] <mru> I know some people well into the triple digits
[20:14:43] <BBB> imagine that you place a message "I'm depressed", and it gets 50 likes
[20:14:47] <BBB> what the hell do you do with that
[20:14:49] <peloverde> I dunno, facebook makes a pretty good evite replacement
[20:15:25] <mru> at least it's not myspace
[20:16:35] <peloverde> Is there a way we can hostile takeover the FFmpeg facebook page?
[20:17:03] <mru> they're using the logo without permission
[20:17:56] <peloverde> Either "Pretending to be me or someone I know" or "This violates my intellectual property"
[20:18:07] <mru> the logo is _not_ under gpl
[20:18:27] <BBB> there's a facebook ffmpeg person? :-p
[20:18:32] <BBB> that's hilarious
[20:18:34] <peloverde> http://www.facebook.com/#!/pages/FFmpeg/45535533634
[20:18:35] <BBB> I wonder who owns it
[20:18:39] <BBB> maybe it's the mediacoder guy
[20:19:09] <peloverde> Would people mind if I try to take it over under "impersonating"?
[20:19:20] <mru> how do you do that?
[20:19:27] <BBB> maybe one of the devs opened it?
[20:19:28] <peloverde> There is a report page link
[20:19:32] <BBB> ask on the ML before taking it over :)
[20:19:54] <peloverde> good call
[20:21:52] <janneg> http://www.facebook.com/photo.php?pid=1295707&id=45535533634 doesn't look like it's from a developer
[20:22:36] <mru> whoever built that ffmpeg has no clue
[20:23:31] <Dark_Shikari> "built ffmpeg" and "has no clue" are highly correlated
[20:24:03] <mru> they pile up bizarre configure flags yet always manage to omit the ones they should have used
[20:24:06] <mru> like --cpu
[20:24:19] <Dark_Shikari> --extra-cflags="-funroll-all-loops"
[20:25:42] <Honoome> Dark_Shikari: so have you heard about gcc 4.6's -Ofast ?
[20:25:51] <Honoome> [and I'm not frigging kidding you!]
[20:26:06] <mru> how is that different from -O9 -fricer?
[20:26:09] <Honoome> -O3 -ffast-math …
[20:26:16] <mru> fast-math is dangerous
[20:26:26] <Honoome> why -O3 is not?
[20:26:36] <mru> O3 doesn't alter semantics
[20:26:37] <Honoome> [especially on x86, since it enables -ftree-vectorize ...]
[20:26:38] <mru> fast-math does
[20:26:45] <saintdev> i prefer -fzomg-fast-speed
[20:27:05] <Honoome> mru: the point of -Ofast is that ti makes it “faster” even though it'll break semantics :|
[20:27:05] <mru> fast-math assumes you will have no infs or nans
[20:27:18] <Honoome> if it sounds batshit crazy it's because it is!
[20:27:30] <mru> if your code is carefully written to not have any such things, -ffast-math is safe
[20:27:38] <mru> there's something else it assumes too
[20:27:44] <peloverde> reciporcal math?
[20:29:17] <Dark_Shikari> what's -Ofast?
[20:29:26] <Dark_Shikari> ffast-math makes sense
[20:29:30] <Dark_Shikari> because it does very specific things
[20:29:31] <Dark_Shikari> but -Ofast?
[20:29:33] <mru> -fbreak-my-code
[20:29:35] <Dark_Shikari> wtf does that do
[20:29:40] <Honoome> -Ofast => -O3 -ffast-math right now
[20:29:50] <Dark_Shikari> ah
[20:29:55] <Dark_Shikari> here's the problem with that
[20:30:01] <Dark_Shikari> breaking semantics is fine as long as you know what breaks
[20:30:04] <mru> a lot of code breaks with -ffast-math
[20:30:06] <Dark_Shikari> -ffast-math breaks very specific things
[20:30:10] <Dark_Shikari> and the developers can code with that in mind
[20:30:11] <Dark_Shikari> BUT
[20:30:19] <Dark_Shikari> -Ofast could, someday, be updated to break ANYTHING
[20:30:24] <Dark_Shikari> so developers cannot safely use it
[20:30:31] <Dark_Shikari> i.e. it's not well defined.
[20:30:47] <Honoome>     This tells GCC to disregard strict standards compliance and to enable all speed optimizations.  In particular it turns on -O3 and -ffast-math.
[20:31:17] <Honoome> this is from today's post by Nick Clifton
[20:31:21] <peloverde> In theory new things could be added to -ffmast-math, you really should use the options taht it currently is equivalent to
[20:32:42] <peloverde> I've heard rumours taht ICC uses something like -ffast-math by default, is that true?
[20:32:55] <mru> it uses -fbreak-ffmpeg by default
[21:02:34] <mru> Dark_Shikari: who's that and why did you ban him?
[21:02:41] <Dark_Shikari> spambot
[21:02:50] <Dark_Shikari> it's rotating freenode channels
[21:02:57] <Dark_Shikari> so I did a pre-emptive ban on all channels I have op on
[21:02:58] <mru> ah, thanks
[21:13:14] <BBB> so...
[21:13:17] <BBB> now I have this patch
[21:13:33] <BBB> I have checked out and am committing to yuvi's git repo
[21:13:45] <BBB> and I've committed several things like asm optimizations to my local version
[21:13:52] <BBB> but I don't want to mess up his repo yet
[21:13:59] <BBB> now I have a patch which I do want to push
[21:14:03] <BBB> what do I do / how do I do that?
[21:14:08] <BBB> so git push only this patch
[21:14:16] <BBB> ideally using git gui or so
[21:14:29] <mru> create a new branch and put only that commit in it
[21:14:35] <mru> then push that to the remote master
[21:15:06] <mru> suppose you have some commits on your local master branch
[21:15:18] <mru> so git status tell you you're X commits ahead
[21:15:19] <janneg> git checkout -b push-branch origin/master
[21:15:25] <mru> then do this
[21:15:34] <mru> git checkout -b temp
[21:15:38] <mru> git rebase -i origin
[21:15:51] <mru> [remove the commits you don't want to push]
[21:15:59] <mru> git push temp:master
[21:16:02] <janneg> and git cherry-pick the commit you want to push
[21:16:26] <mru> use janneg's method if you have many commits you don't want to push
[21:16:32] <BBB> yeah it's many
[21:16:46] <BBB> I guess I sort of made a mess of my local repo
[21:16:50] <BBB> bt I always did that to my svn also
[21:17:00] <mru> if you have many you do want to push, cherry-picking one by one gets old quickly
[21:17:11] <BBB> no, only one
[21:17:17] <BBB> so I commit this patch, then do what janneg said?
[21:17:21] <BBB> or I do not commit this patch?
[21:17:27] <mru> commit it
[21:17:44] <mru> then branch from origin/master and cherry-pick it
[21:17:57] <mru> push, switch back to master and git pull --rebase
[21:19:38] <BBB> how does git cherry-pick work?
[21:19:41] <BBB> is there a UI?
[21:19:45] <Dark_Shikari> git cherry-pick <hash>
[21:19:47] <Dark_Shikari> it cherry picks it
[21:19:48] <Dark_Shikari> that's it
[21:19:53] <Dark_Shikari> I don't see what you'd need a gui for
[21:20:15] <mru> gitk has cherry-pick in a popup menu if you insist
[21:20:55] <BBB> gitk
[21:21:01] * BBB has git gui and GitX
[21:21:04] <BBB> let's try gitk
[21:21:20] <BBB> no port for gitk
[21:21:27] <BBB> how do I figure out the hash?
[21:21:36] <BBB> and how do I do a diff against origin/master again?
[21:21:51] <mru> git diff origin/master
[21:22:21] <BBB> hm... not sure why I couldn't figure that out myself :-p
[21:23:19] <mru> Dark_Shikari: there are a lot of calls to idct_{put,add} ...
[21:23:23] <ohsix> y helo
[21:23:50] <janneg> git log shows the hashes
[21:24:15] <Dark_Shikari> mru: ?
[21:24:30] <BBB> I guess I should've branched against origin/vp8
[21:24:36] * BBB kicks himself
[21:24:38] <BBB> now what?
[21:24:48] <mru> Dark_Shikari: idct_put and idct_add are called from many places
[21:25:05] <Dark_Shikari> I thought it was just mpegvideo?
[21:25:14] <BBB> can I do git checkout -b push-branch origin/vp8 without breaking things?
[21:25:23] <mru> a quick grep counts 73 places
[21:25:33] <janneg> BBB: yes
[21:25:42] <Dark_Shikari> mru: holy fuck
[21:25:59] <BBB> janneg: it says "failed, branch already exists"
[21:26:16] <mru> maybe adding a new function with the extra arg is simpler
[21:26:49] <Dark_Shikari> ugh,.
[21:26:52] <Dark_Shikari> that's a bad solution too
[21:26:53] <Dark_Shikari> more bloat
[21:27:01] <Dark_Shikari> you could convert all of the current ones to ( , 63)
[21:27:03] <BBB> "fatal: git checkout: branch push-branch already exists"
[21:27:26] <janneg> BBB: of course checkout -b creates a new branch, use a different name
[21:27:31] <mru> Dark_Shikari: and benchmark it to prove no slowdown?
[21:27:43] <Dark_Shikari> lol
[21:27:44] <BBB> janneg: can't I overwrite the old one? I mean, I'm not gonna use it anymore
[21:27:46] <Dark_Shikari> <3 michael
[21:27:51] <janneg> or delete the branch first
[21:28:35] <BBB> how do I delete a branch
[21:28:44] <BBB> again, ideally without screwing up where I am
[21:28:50] <BBB> (is that master?)
[21:29:25] <janneg> you could rebase it against origin/vp8 but I'm not sure if that resets the remote pull/push branchs
[21:29:36] <janneg> git checkout master
[21:29:50] <janneg> git branch -d push-branch
[21:30:47] <janneg> if it complains make sure that push-branch holds no important commits and git branch -D push-branch
[21:31:01] <BBB> libavcodec/h264pred.c: needs merge
[21:31:01] <BBB> libavcodec/vp8.c: needs merge
[21:31:02] <BBB> error: you need to resolve your current index first
[21:31:15] <BBB> why isn't there a -f switch or so?
[21:31:41] <BBB> (there is no libavcodec/vp8.c, that's how I noticed I was in the wrong origin/branch)
[21:34:20] <BBB> hm, the git howto on kernel.org helped me there
[21:35:17] <BBB> bash-3.2$ git checkout -b push-branch origin/vp8
[21:35:17] <BBB> error: Entry 'libavcodec/vp8.c' would be overwritten by merge. Cannot merge.
[21:36:05] <janneg> BBB: still in the push-branch after the cherry-pick? what was the last command
[21:38:40] <BBB> I switched back to master
[21:38:43] <BBB> all my files are fine
[21:38:49] <BBB> now I want to recreate the push-branch
[21:38:54] <BBB> same command as last time
[21:38:56] <BBB> but now it's not working
[21:39:10] <CIA-92> ffmpeg: stefano * r23687 /trunk/Makefile:
[21:39:10] <CIA-92> ffmpeg: Update documentation dependencies, make ff* tools manpages and HTML
[21:39:10] <CIA-92> ffmpeg: pages depend of fftools-common-opts.texi.
[21:39:10] <CIA-92> ffmpeg: stefano * r23688 /trunk/doc/libavfilter.texi:
[21:39:10] <CIA-92> ffmpeg: Replace multitable for the unsharp filter option table with a simple
[21:39:11] <CIA-92> ffmpeg: @table @option.
[21:39:12] <CIA-92> ffmpeg: Allow pod rendering, as texinfo multitables are not supported by
[21:39:12] <CIA-92> ffmpeg: texi2pod.pl, also improve plain texinfo file readability.
[21:39:28] <BBB> I did git checkout master
[21:39:36] <BBB> then git branch -d push-branch
[21:39:45] <BBB> then git checkout -b push-branch origin/vp8
[21:39:47] <BBB> and that's not working
[21:42:45] <janneg> BBB: check that you're working copy and index are clean with git status
[21:43:01] <janneg> after make distclean
[21:47:33] <BBB> huh?
[21:47:40] <BBB> it thinks libavcodec/vp8.c is a new commit
[21:47:40] <BBB> n
[21:47:41] <BBB> ow wh
[21:47:43] <BBB> now what?
[21:47:51] <BBB> do I commit it as-is?
[21:47:57] <BBB> or will I screw up everything if I do that?
[21:49:08] <janneg> first check that you're actually in your master branch with git branch
[21:49:09] <peloverde> do you have a leftover libavcodec/vp8.c in a branch that doesn't contain it?
[21:49:17] <peloverde> what does git status say?
[21:49:46] <janneg> the active branch is marked by ^*
[21:52:01] <BBB> grrrrrrrrr
[21:52:12] <BBB> I think it committed to the remote branch push-branch instead of origin/vp8
[21:52:18] <BBB> git really needs some serious usability love
[21:52:33] <Dark_Shikari> I've never had such problems
[21:52:36] <Dark_Shikari> then again, I don't use branches
[21:52:50] <mru> branches are easy
[21:52:54] <BBB> http://github.com/yuvi/ffmpeg/tree/push-branch
[21:53:01] <BBB> I fucked up yuvi's git repo
[21:53:02] <BBB> :)
[21:53:09] <peloverde> I use branches all the time without problem, though I only have one pushable location
[21:53:10] <BBB> damn git, no wonder MN doesn't want to switch
[21:53:13] <BBB> what the fuck
[21:53:35] <mru> BBB: "git push +:push-branch" to delete it remotely
[21:54:10] <BBB> before or after switching back to master?
[21:54:13] <BBB> or does not matter?
[21:54:18] <mru> doesn't matter
[21:54:35] <BBB> ssh: Could not resolve hostname +: nodename nor servname provided, or not known
[21:54:36] <BBB> fatal: The remote end hung up unexpectedly
[21:54:43] <mru> ah, sorry
[21:55:20] <mru> git push origin +:push-branch
[21:56:05] <BBB> thanks
[21:56:06] <janneg> mru: the '+' shouldn't be needed
[21:56:18] <mru> yeah, probably not
[21:56:30] <BBB> so I suppose that pushing git push push-branch :vp8 would've committed it to the right branch?
[21:57:29] <mru> no, it would have delete the remote vp8 branch
[21:57:47] <mru> you want git push origin push-branch:vp8
[21:58:08] <mru> it's git push $repo $local:$remote
[21:58:24] <BBB> let me try
[21:58:29] <BBB> I seriously hope I don't fuck up again :-p
[21:59:35] <BBB> that looks quite sane
[21:59:37] <BBB> thanks!
[22:06:31] <BBB> eeeeeeeeeek all my files are missing :(
[22:07:02] <Dark_Shikari> git fsck
[22:07:21] <Dark_Shikari> I have no idea why you're doing all this complex stuff
[22:07:26] <Dark_Shikari> I only use about 4 git commands
[22:07:37] <Dark_Shikari> rebase, commit, log, format-patch, push
[22:07:44] <BBB> that's 5
[22:07:48] <Dark_Shikari> 5 is about 4.
[22:08:24] <BBB> git checkout vp8, I guess I was in the wrong branch
[22:09:57] <CIA-92> ffmpeg: stefano * r23689 /trunk/ (5 files in 2 dirs):
[22:09:57] <CIA-92> ffmpeg: Make the ffmpeg and ffplay man pages show the list of lavfi filters,
[22:09:57] <CIA-92> ffmpeg: sinks and sources, and document the -vf option.
[22:16:53] <bcoudurier> [14:52]  <BBB> git really needs some serious usability love < you sound like the average ffmpeg user
[22:17:19] <BBB> git is seriously complex and obscure
[22:18:17] <Dark_Shikari> it's complex, but you don't have to use the complexity...
[22:18:31] * j0sh_ agrees on the complexity
[22:18:51] <peloverde> I use "rebase apply commit log format-patch push diff pull checkout branch blame"
[22:19:37] <mru> stash send-email
[22:19:49] <mru> add
[22:19:56] <peloverde> forgot send e-mail, I don't use stash, I'll create a temp branch instead
[22:20:05] <peloverde> git-apply behaves the way I wish patch did
[22:20:15] <mru> if the branch would live for 30s or less, I use stash
[22:20:19] <peloverde> I use git-apply with svn
[22:20:57] <peloverde> "add -p" is excellent
[22:20:58] * j0sh_ has been meaning to write a blogpost about my ffmpeg/git workflow...
[22:21:24] <Dark_Shikari> peloverde: temp branch?  I use diffs
[22:21:30] <Dark_Shikari> I have 500+ diffs
[22:21:34] <Dark_Shikari> I upload them online so anyone can view them
[22:22:45] <mru> I have some 40 branches of ffmpeg
[22:22:48] <mru> most of them junk
[22:23:06] <Dark_Shikari> maybe 1/3 of my diffs are stuff that was appliede
[22:23:10] <Dark_Shikari> most of the rest are ideas I never finished, or failed
[22:23:15] <Dark_Shikari> but I keep them around, because sometimes I need them later
[22:24:01] <BBB> now there's a conflict in a file
[22:24:07] * BBB kicks git
[22:24:48] <peloverde> Then resolve the confict and continue
[22:25:33] <Dark_Shikari> what's the git link for that repo?
[22:25:38] <Dark_Shikari> once you push your asm I'd like to go write some asm
[22:26:53] <mru> Dark_Shikari: care to reply to michael?
[22:27:47] <BBB> the sad thing is that after every git checkout, it rebuilds everything
[22:28:05] <mru> then you're doing it wrong
[22:28:07] <BBB> Dark_Shikari: github.com/yuvi/ffmpeg/vp8
[22:28:33] <BBB> Dark_Shikari: I'll send a new plain-C patch to ffmpeg-devel, Michael said it could be applied to continue work in SVN
[22:28:39] <Dark_Shikari> mru: ok
[22:28:40] <BBB> I'll do that, and then send patches for my initial asm
[22:30:35] <Dark_Shikari> mru: done
[22:31:38] <lu_zero> hi
[22:31:53] <mru> lo
[22:31:58] <lu_zero> damn
[22:32:06] <lu_zero> looks like I'm missing lots of fun today
[22:32:24] * lu_zero spent yesterday running from Torino to Milano
[22:32:41] * lu_zero _hates_ korean vdrs
[22:32:53] <lu_zero> and windows =_=
[22:33:16] <mru> hehe koreans...
[22:33:29] <Dark_Shikari> brb, meeting
[22:34:20] <lu_zero> security cameras using a strange vdr
[22:34:35] <lu_zero> dnat doesn't seem to work
[22:35:02] * mru doesn't use nat much
[22:36:23] <lu_zero> I have to make those thing a little more secure using a vpn
[22:36:48] <lu_zero> _but_ the stock rule for suck services isn't working =_=
[22:39:38] <j0sh_> lu_zero: was it a fun run?
[22:40:07] <mru> he was running from the cops
[22:40:46] <j0sh_> vdrs: violent death reporting system? no wonder you were running
[22:41:31] <j0sh_> (thefreedictionary.com acronyms)
[22:42:18] <Honoome> lu_zero: could be worse
[22:42:25] <Honoome> you could have been running away from ME ...
[22:43:18] <lu_zero> Honoome: ...
[22:43:50] <lu_zero> that reminds me that you still have to pick a date for that meeting
[22:43:54] <Honoome> lu_zero: what? should I not be at least slightly pissed? ¬_¬
[22:45:44] <lu_zero> uh?
[22:49:55] <CIA-92> ffmpeg: stefano * r23690 /trunk/doc/filters.texi:
[22:49:55] <CIA-92> ffmpeg: Re-add the list of parameters for the unsharp filter, I somehow lost
[22:49:55] <CIA-92> ffmpeg: it in the previous commit.
[22:51:17] <BBB> is there some way to "cherry-pick" a patch but not apply it, but rather print it to stdout?
[22:51:23] <BBB> (using git)
[22:51:56] <mru> show
[22:51:56] <saintdev> git diff?
[22:52:21] <Honoome> git show $sha
[22:55:42] <CIA-92> ffmpeg: cehoyos * r23691 /trunk/libavdevice/x11grab.c: Remove stray semicolon.
[22:57:37] <ohsix> BBB: once you get over managing the working copy its a breeze
[22:58:07] * BBB decides to go home and take a break
[22:58:14] <BBB> I'll submit a new VP8 patch tomorrow
[22:58:47] <mru> what's the state of the decoder?
[22:59:01] <ohsix> you can also create a local tree to push to that you can fuck up
[22:59:10] <ohsix> derp
[23:35:32] <peloverde> youtube is selling video downloads now?
[23:42:28] <Honoome> peloverde: has been for a while yeah
[23:42:50] <peloverde> I didn't notice until today
[23:43:14] <Honoome> I still can't understand how some people pretend to "sell" their videos..
[23:52:30] <peloverde> I guess it's time for me to start vlogging to cash in on this