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

[irc at mansr.com]

[00:38:00] <peloverde> ot: I really hate HTML http://spectralhole.blogspot.com/2010/09/aac-channel-model-revisited.html
[00:39:03] <roxfan> cute
[00:39:29] <roxfan> looks fine in user mode, so it's probably css
[00:39:37] <peloverde> yes it is CSS
[00:40:00] <peloverde> I feel like floating boxes with rotations isn't the best way to organize content
[00:42:31] <peloverde> I've replaced the table with "I can't seem to get the CSS right to display it here."
[00:49:31] <peloverde> The wonderful thing about sideways text in a table is the cell is sized as if the text were horizontal... but the blog post should be interesting to anyone who has been bitten by the AAC channel model
[00:50:18] <kierank> what i never understood is why aac doesn't allow channel map changes
[01:12:03] <peloverde> It kind of does via the pce or adts but is underspecified
[01:26:26] <peloverde> I'm still kind of curious about PS in iTunes
[01:50:13] <saintd3v> Dark_Shikari: maybe a project for doom10?
[05:05:51] <Tjoppen> god morgon
[05:44:44] <KotH> ohayou gozaimasu!
[05:46:30] <_av500_> wakarimas
[06:26:10] <superdump> http://news.slashdot.org/story/10/09/21/0428259/Codec2-mdash-an-Open-Source-Low-Bandwidth-Voice-Codec?from=rss
[06:26:58] <Dark_Shikari> Sounds a lot shittier than SILK.
[06:28:56] <Tjoppen> how does celt compare to these?
[06:37:59] <superdump> 2.24kbps
[07:09:51] <Tjoppen> looks like he's coding the cepstrum of the signal
[07:10:11] <kshishkov> so do a lot of other codecs
[07:10:14] <Tjoppen> not a bad idea since it and lpc are quite relate
[07:10:15] <Tjoppen> d
[07:10:23] <saintdev> cepstrum?
[07:10:36] <Tjoppen> cepstrum = spectrum of spectrum
[07:11:39] <kshishkov> hmm, that sounds rather dubious
[07:11:41] <Tjoppen> there are a bunch of variants. quite populer with the audio classification crowd, where they dft normalized coeffs on a bark scale
[07:12:57] <Tjoppen> on a linear scale it seems like a decent way to code harmonics?
[07:13:07] <kshishkov> nope
[07:13:22] <kshishkov> dft(dft(x)) = x
[07:13:40] <saintdev> kshishkov: exactly what i was thinking
[07:14:11] <Tjoppen> more like abs(dft(log(abs(dft(x))))
[07:14:15] <saintdev> but i'm a noob, so i wasn't sure if i was right :P
[07:14:26] <Tjoppen> maybe I should have clarified that :)
[07:14:45] <kshishkov> that still sounds bad
[07:14:47] <Tjoppen> dtf of the log of the power spectrum
[07:16:17] <kshishkov> personally I don't believe in that approach at all
[07:16:44] * kshishkov hasn't studied theory so he may be wrong
[07:17:12] <kshishkov> from description this codec seems to employ standard speech codec scheme
[07:18:45] <saintdev> well they say it's from one of the speex guys, so i would think it would work similar to speex
[07:19:01] <saintdev> just with better decisions based on lessons learned from speex
[07:19:15] <kshishkov> not the main Speex guy though, looks like this one worked on pre/postprocessing stuff
[07:19:57] <kshishkov> still, since I've read Brooks, I'll wait for the third codec
[07:21:28] <saintdev> Brooks?
[07:21:39] <kshishkov> yes, "The Mythical Man-month"
[07:22:05] <KotH> the third codec?
[07:22:12] <saintdev> ok
[07:22:36] <kshishkov> KotH: lifecycle of software
[07:22:44] <kshishkov> first version is usually may be faulty
[07:23:01] <kshishkov> second version is usually packed with too many features to be usable
[07:23:09] <kshishkov> the third one may be just right
[07:23:19] <kshishkov> (since they really worked on it)
[07:23:26] <KotH> so, ffmpeg is the second version ? ;)
[07:23:52] <kshishkov> it depends
[07:32:26] <Tjoppen> his observation that the spectrum is priodic threw me a bit off track. but he does seem to be doing lpc on the spectrum, so I wan't too far off
[08:24:33] <mru> and still nothing on the intel forums
[08:24:38] <mru> I told you it was a bad idea
[08:27:56] <cartman> LOL
[08:28:05] <cartman> open a bug report maybe
[08:28:18] <mru> I doubt it's considered a but
[08:28:22] <mru> bug
[08:28:31] <mru> just a missing feature
[08:28:36] <mru> one they added in v11
[08:28:44] <cartman> might be :/
[08:28:50] <mru> btw, where can one find icc 12 beta?
[08:32:57] <lu_zero> http://www.rowetel.com/blog/?page_id=452 <- interesting?
[08:35:43] * _av500_ waits for codec3
[08:36:45] <lu_zero> uhm
[08:37:07] * cartman waits for "the codec"
[08:38:50] <kshishkov> cartman: DPCM - it codes audio and video
[08:39:22] <kshishkov> so it must be the ultimate codec
[08:39:42] * mru wants the universal codec they have in star trek
[08:39:58] <mru> the one where all you need to do is say "on screen"
[08:40:03] <funman> mru: http://abstrusegoose.com/303 this one?
[08:40:44] <mru> funman: can you compensate?
[08:41:15] <mru> one of the producers must have _really_ liked that word
[08:41:23] <cartman> funman: lol
[08:41:38] <kshishkov> mru: on2 screen?
[08:41:44] <funman> i don't think i ever watched star trek
[08:41:53] <cartman> oooh
[08:43:46] <kshishkov> funman: okay, what classic series have you seen then?
[08:44:07] <_av500_> ulysse31
[08:44:34] <kshishkov> _av500_: sounds like login, what's the password?
[08:44:36] <funman> yeah :)
[08:44:42] <mru> swordfish
[08:45:07] <_av500_> funman: i have the dvd box set :)
[08:45:11] <kshishkov> why is that word _always_ the password?
[08:45:23] <funman> TV was only sparsely allowed at home when i was a child
[08:45:37] <funman> until we got a NES and my dad started playing Super Mario 3
[08:45:37] <cartman> funman: good idea
[08:45:40] <_av500_> kshishkov: marx brothers reference
[08:46:01] <kshishkov> funman: was it called "crazy invention of American devils"?
[08:46:19] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/ThePasswordIsAlwaysSwordfish
[08:46:27] <funman> more "mind-alterating shit box"
[08:47:05] * mru didn't watch tv much as a kid but has still seen at least some of the classics
[08:47:07] <kshishkov> _av500_: I know only three Marx brothers - Karl, Friedrich and Vladimir Illitch. None of them used it
[08:47:30] <funman> i have watched a lot of simpsons
[08:48:44] <cartman> funman: http://nelsonhaha.com/
[08:48:46] * kshishkov did too - mostly in RM format and horrible Russian dub
[08:48:47] <cartman> there you go
[08:49:12] <kshishkov> cartman: at least you've never watched South Park, have you?
[08:49:19] <thresh> :)
[08:49:22] <cartman> kshishkov: never ever sir
[08:49:54] <funman> was the motivation behind RM work, "watch simpsons"?
[08:50:03] <kshishkov> funman: nope
[08:50:31] <cartman> watch RM pr0n?
[08:50:34] <kshishkov> actually I had no particular interest in RM by that time
[08:50:41] <cartman> rm anime maybe
[08:50:54] <kshishkov> yes, with Chinese hardsubs
[08:51:17] * funman read "RM pr0n with Chinese hardsubs"
[08:51:31] <cartman> must be hard
[08:51:37] <thresh> woah, new house md episode
[08:51:51] <kshishkov> funman: RM is pornography by definition
[08:52:52] <kshishkov> cartman: well, Chinese is not that hard, especially if you know Japanese and can ignore them ;)
[08:53:02] <cartman> kshishkov: right :P
[08:59:49] <funman> mru: did you think about this libmp3lame version detection?
[09:01:09] <mru> I'm inclined to just test for the function we actually need
[09:01:31] <mru> ignoring that the first release which has it was broken
[09:02:38] <mru> does anyone know a way to find specific versions of intel compilers?
[09:02:55] <mru> like, say, the latest in the 10.1 series
[09:04:56] <cartman> mru: http://software.intel.com/en-us/articles/older-version-product/ google is too helpful ;)
[09:05:12] <mru> what did you search for?
[09:05:22] <cartman> intel old software
[09:05:23] <cartman> :)
[09:31:58] <mru> wtf is wrong with michael?
[09:33:04] <kshishkov> where is proper bugreport on him?
[09:33:23] <_av500_> resolution: wontfix?
[09:34:30] <kshishkov> everybody suspects so
[09:38:00] <cartman> whats up with niedermayer?
[09:38:14] <mru> he's on a ranting rampage
[09:38:35] <cartman> any link so I can have fun too?
[09:38:40] <mru> ml
[09:38:46] <cartman> subject?
[09:40:11] <cartman> a #flame tag is needed
[09:40:18] <cartman> just too much signal in ml
[09:40:55] <funman> signal-to-flame ratio?
[09:41:32] <cartman> yeah
[09:42:07] <cartman> aha found it
[09:50:29] * Sho_ spots a cartman
[09:51:47] <mru> do we care about icc 11.0 and/or 10.0?
[09:52:50] * kshishkov looks if Carl Eugen is around
[09:52:52] <kshishkov> no
[09:53:41] <kshishkov> though it would be nice to support them (probably)
[09:55:14] <cartman> Sho_: lo!
[09:55:23] <Sho_> :)
[09:56:22] <cartman> Sho_: I am always trolling around here :D
[09:57:09] * kshishkov takes a pity on cartman
[09:57:39] <cartman> kshishkov: I am having a good time, thanks :P
[09:58:09] <kshishkov> cartman: if you call that "trolling", you deserve some pity. Ask av500 for example
[09:58:34] <cartman> kshishkov: trolling as in I am doing much useful ffmpeg work
[09:59:09] <kshishkov> cartman: that phrase was trolling indeed
[09:59:25] <cartman> see, it works
[10:00:16] * cartman bows to the master troll
[10:00:55] * kshishkov simply continues sitting next to him
[10:02:30] <_av500_> err
[10:02:51] <funman> kshishkov: is trolling contagious?
[10:02:52] <kshishkov> _av500_: you are too small to be considered one
[10:02:59] <cartman> lol
[10:03:00] <kshishkov> funman: no
[10:03:37] <kshishkov> cartman: av500 serves as our smallest troll
[10:03:43] <_av500_> kshishkov: i was refering to the highlight above
[10:03:55] <_av500_> ocourse i know who the master troll is
[10:03:56] <pJok> troll'r'us?
[10:04:11] <cartman> _av500_: ;>
[10:04:38] <pJok> and there the master troll is
[10:04:50] <funman> quick, someone /nick mru
[10:05:00] <_troll_> funman: it's registered
[10:05:18] <spaam> all hail _troll_ !
[10:05:28] <Sho_> cartman: nice to see you're still involved with the FOSS fray then :)
[10:05:53] <cartman> Sho_: I am trying KDE releases from time to time, still brings my nvidia to its knees
[10:06:01] <Sho_> heh
[10:07:16] <cartman> not fun
[12:38:06] <Dark_Shikari> BBB___: Just commit the doc/optimization change.
[12:38:08] <Dark_Shikari> Fuck michael.
[12:38:34] <Dark_Shikari> In fact, how about we just ignore all of his emails in every thread related to asm?
[12:38:38] <Dark_Shikari> We'll hellban him.
[12:38:45] <Dark_Shikari> problem solved.
[12:39:31] <BBB___> hahaha :)
[12:40:00] <Dark_Shikari> seriously.  if he wants to whine about things without doing any real work, then we can ignore him
[12:40:39] <mru> +1
[12:41:17] <Dark_Shikari> Hellbanning is a very effective technique
[12:41:55] <Dark_Shikari> Also, Civilization 5 comes out in 2 hours, so I may disappear around that time.
[12:42:48] <BBB> sounds like me and starcraft 2
[12:42:53] <BBB> but I already finished it :(
[12:44:08] <elenril> except you can't really 'finish' civilization ;)
[12:44:35] <mru> you can finish it off
[12:44:49] <mru> ask skynet
[12:46:04] <elenril> <insert some tropes here>
[12:46:39] <Dark_Shikari> damn, I have so much shit I need to do this week.
[12:46:43] <BBB> I wish michael would whine less and review my patches more
[12:46:50] <Dark_Shikari> BBB: JUST COMMIT
[12:46:51] <Dark_Shikari> we reviewed it
[12:46:59] <Dark_Shikari> Ignore michael, he is not an asm maintainer
[12:47:01] <BBB> you didn't review my idct unroll patches :-p
[12:47:04] <Dark_Shikari> Also, in the meantime, you could get to work on xvp8
[12:47:07] <BBB> but I'll commit anytime
[12:47:27] <Dark_Shikari> BBB: If it's faster, you should feel free to commit without discussion.
[12:47:35] <Dark_Shikari> Unless there's a good reason you think that it needs discussion.
[12:47:59] <Dark_Shikari> OK, your macro name should be all caps.
[12:48:00] <Dark_Shikari> But that's it.
[12:48:15] <Dark_Shikari> And it should be commented.
[12:48:17] <Dark_Shikari> Then commit ti.
[12:49:22] <Dark_Shikari> tl;dr I trust you, go make things better. ignore michael.
[12:49:30] <Dark_Shikari> And stop stalling on xvp8.
[12:50:43] <BBB> yeah yeah yeah
[13:28:22] <lu_zero> ^^
[13:30:36] <wbs> stop trolling michael already so he can go on and troll me on the g722 encoder so that I can commit it sometimes this decade ;P
[13:41:10] <Compn> wbs : any interest in working on g729 patch after you are done with 722 ?
[13:41:12] <kshishkov> wbs: you can always ask say Vitor or Ronald for review and commit on their approval - they are speech codec guys here after all
[13:42:12] <wbs> Compn: hmmm, if I have spare time after this, perhaps
[13:42:39] <Compn> while all the ffmpeg rules and speech codec stuff is fresh in your mind :P
[13:42:40] <Compn> ehe
[13:42:49] <wbs> kshishkov: true, but if you've seen the encoder review lately, it hasn't been much about the actual speech coding, only about perhaps optimizing one loop a bit
[13:43:32] <wbs> perhaps, as in, the total execution time hasn't really changed much
[13:44:31] * kshishkov wonders what other G.7xx codecs FFmpeg lacks
[13:47:53] <wbs> kshishkov: I think there may be a few of them left still
[13:53:16] <pJok> G.711 · G.718 · G.719 · G.722 · G.722.1 · G.722.2 · G.723 · G.723.1 · G.726 · G.728 · G.729 · G.729.1 from what wiki says of G.7XX standards
[13:53:44] <cartman> all of them useful as in used somewhere?
[13:54:03] <kshishkov> G.711 is widely supported
[13:54:14] <kshishkov> used virtually everywhere
[13:54:34] <cartman> kshishkov: voice codec or?
[13:54:41] <kshishkov> cartman: aka PCM
[13:54:48] <cartman> ah :>
[13:55:14] <kshishkov> G.722* is in progress
[13:55:24] <wbs> kshishkov: isn't g711 mulaw/alaw and not plain pcm?
[13:55:43] <lu_zero> wbs: regarding select + windows
[13:56:12] <kshishkov> wbs: those too
[13:56:16] <lu_zero> I'm thinking to factorize the poll code among the protocols
[13:56:59] <wbs> lu_zero: sure, if you can clean it up without breaking the current apis, feel free to propose patches :-)
[13:58:17] <kshishkov> wbs: also look at G.711.0
[13:58:28] <lu_zero> wbs: since every place we have a select we should apply your fix
[13:58:51] <wbs> not necessarily all of them, but perhaps in some other, too
[13:59:14] <lu_zero> (and given our fd set doesn't change switching to poll might be an option)
[14:03:30] <kierank> seen this http://www.rowetel.com/blog/?page_id=452 ?
[14:04:12] <kshishkov> congratulations! You've managed to get into top 10 of people who posted this link today
[14:04:31] <kierank> what is my prize
[14:05:35] <kshishkov> |-C
[14:05:36] <spaam> a night with mru ! :D
[14:06:12] <kshishkov> kierank: that's your trophy cup, keep it nice and clean
[14:10:43] * kierank puts it on his mantlepiece
[14:14:24] <BBB> Dark_Shikari: I think he almost agrees now
[14:14:39] <mru> no
[14:14:41] <mru> far from it
[14:17:57] <BBB> he'll never agree with "all non-inlined asm should be external asm (e.g. yasm)"
[14:18:13] <Dark_Shikari> Just commit it.
[14:18:36] <Dark_Shikari> also, civilization 5 is done.  fffffffffffffffffff
[14:18:49] <kierank> see you tomorrow Dark_Shikari
[14:18:53] <BBB> bye bye Dark_Shikari
[14:18:56] <BBB> :-p
[14:19:00] <mru> kierank: you're very optimistic
[14:19:20] <Dark_Shikari> hahahahaha tomorrow hahahahahaha
[14:37:37] <BBB> "I'm only arguing the feature if we implement it nicely, I'm not saying we implement it nicely"?
[14:37:43] <BBB> does that mean he hates the feature as-is currently?
[14:38:38] <kshishkov> could be
[14:52:13] <mru> BBB: I don't think anyone will answer your question on the intel forums
[14:56:52] <BBB> mru: I figured :(
[14:56:59] <BBB> mru: what do you suggest we do now?
[14:57:41] <mru> disable the offending code for compilers that don't support alignment
[14:59:08] <BBB> ok, I guess... do you have your patch handy?
[14:59:13] <mru> not yet
[14:59:22] <BBB> I don't mind if we disable mmx altogether for those cpus btw
[14:59:26] <BBB> not cpus
[14:59:30] <BBB> compilers
[14:59:34] <mru> wrong solution
[14:59:38] <BBB> but I guess that's a little extreme
[15:00:18] <kshishkov> yes, why my build for i386 doesn't feature MMX by default?
[15:00:27] <kshishkov> been there
[15:00:42] <mru> this is about old icc versions
[15:02:44] <kshishkov> bug Carl until he gives you patches
[15:02:50] <mru> he won't
[15:02:57] <mru> he'll only provide hacks
[15:03:58] <kierank> BBB: as soon as it drops off the first page you won't stand a chance of getting the question answered
[15:15:36] <BBB> kierank: that's rather sad
[15:15:37] <BBB> but ok
[15:16:35] <mru> BBB: that's forums
[15:16:38] <mru> forums are sad
[15:16:42] <mru> QED
[17:10:00] <kierank> ok now i see why civ5 takes a long time...
[17:22:22] <mru> BBB: ping
[17:22:28] <mru> kierank: and why is that?
[17:22:48] <kierank> because I downloaded the demo and had a go
[17:23:14] <mru> and what did you find?
[17:23:47] <kierank> you could spend weeks playing it without even noticing
[17:24:00] <mru> oh, one of those games
[17:24:06] <mru> what's the appeal?
[17:24:32] <mru> I mean, real life is just like that
[17:24:34] <kierank> building a civilisation, going to war
[17:24:35] <mru> and far more realistic
[17:24:57] <kierank> but most people aren't PM/president/emperor/king etc
[17:25:23] <mru> most people don't try
[17:27:04] <BBB> mru: pong
[17:27:18] <mru> BBB: which functions need 16-byte aligned stack?
[17:27:31] <BBB> all sse2 functions that use stack
[17:27:37] <BBB> except vp8
[17:27:39] <mru> d'uh
[17:27:46] <BBB> heh :) ok that wasn't helpful
[17:27:51] <BBB> let's try again
[17:28:09] <BBB> do we have a broken fate machine that I can peek at?
[17:28:09] <mru> I was hoping to not have to read thousands of lines of asm to figure which ones use the stack
[17:28:14] <mru> yes
[17:28:24] * BBB checks fate
[17:28:28] <mru> icc 10.1 x86_32
[17:28:51] <mru> I know of the h264 loop filter
[17:29:02] <mru> but there's at least one more
[17:29:06] <BBB> vsynth
[17:29:06] <BBB> yeah
[17:31:04] <mru> something that's used only in mpeg2 and mpeg4adv tests
[17:31:38] <BBB> on x86-32, hadamard8x8_diff_sse2/ssse3
[17:32:01] <BBB> in dsputilenc_mmx.c and dsputilenc_yasm.asm
[17:32:25] <mru> yeah, -cmp satd
[17:33:09] <_av500_> mru: lol, one of your git commit was just given to us from TI :)
[17:33:26] <_av500_> the user space ple one
[17:33:26] <mru> what commit?
[17:33:31] <mru> heh
[17:33:59] <mru> the ple is hard to use efficiently from userspace
[17:34:01] <_av500_> it was gone from some ti kernel and we asked and they told us to see your commit on how to get it back :)
[17:34:13] <BBB> mru: and the deblock sse2 ones are the only ones I see for h264
[17:34:22] <BBB> mru: together that should fix fate on icc 10.1
[17:34:29] <mru> BBB: yes, that's the ones that were disabled before
[17:34:33] <BBB> yes
[17:34:38] <BBB> that's all from what I can see
[17:34:44] <BBB> the rest of simd functions using stack are all mmx
[17:34:47] <BBB> they don't need aligned stack
[17:35:19] <BBB> if it doesn't fix the vsynth tests, please get me a backtrace and I'll look further :)
[17:35:24] <BBB> (although you probably don't need me for that)
[17:36:17] <mru> both ff_hadamard8_diff and ff_hadamard8_diff16?
[17:36:23] <mru> sse2 and ssse3?
[17:37:30] <BBB> yes
[17:37:37] <BBB> only on x86-32 all of them
[17:37:45] <BBB> the x86-64 ones don't use stack
[17:37:55] <mru> stack is 16-byte aligned there anyway
[17:46:07] * BBB loves x86-64
[17:46:09] <BBB> so smart
[17:46:17] <BBB> now if only it was 32-byte aligned
[17:46:19] <mru> so full of hacks
[17:46:22] <BBB> (for avx)
[17:46:41] <cartman> BBB: avx needs 32byte alignment?
[17:58:26] <CIA-63> ffmpeg: mru * r25151 /trunk/configure:
[17:58:26] <CIA-63> ffmpeg: Add HAVE_ALIGNED_STACK config setting
[17:58:26] <CIA-63> ffmpeg: This is set to 1 if the stack is guaranteed to be suitably aligned
[17:58:26] <CIA-63> ffmpeg: for the strictest access mode of the machine.
[17:58:26] <CIA-63> ffmpeg: mru * r25152 /trunk/configure: Disable ALIGNED_STACK with icc 10 or prior on x86_32
[17:58:27] <CIA-63> ffmpeg: mru * r25153 /trunk/libavcodec/x86/ (dsputilenc_mmx.c h264dsp_mmx.c):
[17:58:28] <CIA-63> ffmpeg: x86: disable SSE functions using stack when stack is not aligned
[17:58:28] <CIA-63> ffmpeg: This fixes crashes with ICC 10.1.
[17:58:59] * mru waits for fate to run
[17:59:35] <spaam> :)
[18:01:10] <mru> there goes the cron job
[18:01:19] <mru> now we wait
[18:01:26] <mru> 3 minutes per compiler
[18:07:27] <cartman> my fate is green ;(
[18:07:30] <cartman> ;P
[18:28:30] <mru> it's green :-)
[18:32:46] <wbs> BBB: any objections to the tcp/select patch I posted earlier today?
[19:29:00] <mru> hey look, latest icc passes the als tests
[19:30:16] <cartman> si senior
[19:31:06] <cartman> mru: whats up with sipr though?
[19:31:12] <mru> busted
[19:34:56] <cartman> http://safecode.cs.illinois.edu/index.html maybe interesting
[19:45:26] <lu_zero> uhm
[19:45:45] <lu_zero> llvm seems getting more and more nifty stuff
[19:49:35] * mru would rather have _useful_ stuff
[19:50:37] <mru> Honoome: ping
[19:55:25] <lu_zero> mru: clang is quite useful
[19:55:37] <mru> it compiles code
[19:55:41] <mru> so do most other compilers
[19:55:48] <lu_zero> yup
[19:56:00] <lu_zero> what else you'd like from llvm?
[19:57:05] <mru> fast code
[19:57:11] <mru> correct code
[19:57:14] <kierank> less fanboism
[19:57:18] <mru> that too
[19:57:32] <kierank> fanboism is unsuprising considering apple fund it
[19:57:33] <mru> but it comes from apple, so what else is there to expect?
[19:57:48] <lu_zero> I wasn't aware of fanboism
[19:57:59] <mru> fanbois never are
[19:58:07] <lu_zero> maybe just because I started looking at it loong ago
[19:58:13] <cartman> it has nothing to do with being an Apple fan
[19:58:23] * lu_zero isn't an apple fan =P
[19:58:23] <cartman> coming from Apple is a negative thing for me
[19:58:45] <kierank> reddit, hacker news etc love it
[19:58:51] <lu_zero> pff
[19:59:04] <cartman> because its fast & good error reporting
[19:59:39] <mru> geez, when was the last time you had a syntax error?
[20:00:14] <lu_zero> what's with error reporting btw?
[20:00:46] <cartman> Guess why tools like http://www.bdsoft.com/tools/stlfilt.html exist
[20:01:21] <lu_zero> C++
[20:01:30] <lu_zero> I don't use and do not care
[20:02:24] <cartman> guess you are alone lu_zero :P
[20:02:42] <cartman> one of the clang developers is from C++ committee
[20:02:47] <cartman> maybe two ;)
[20:03:48] <lu_zero> so?
[20:04:07] <cartman> the world needs a better C++ compiler, so clang plugs the hole for me
[20:04:15] <cartman> Apple or Orange whatever
[20:04:16] <cartman> its good
[20:04:35] <lu_zero> the world needs to make C++ go the way of perl3
[20:04:44] <cartman> in your dreams ;)
[20:04:48] <cartman> Java should die first :P
[20:05:10] <lu_zero> groovy and javascript are doing a wonderful job
[20:05:21] <lu_zero> (regarding java)
[20:05:36] <mru> boost::detail::graph::dot_skipper::definition& boost::spirit::impl::get_definition<boost::detail::graph::dot_skipper, boost::spirit::parser_context<boost::spirit::nil_t>, boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char, char, std::char_traits<char>, long>, boost::spirit::multi_pass_policies::input_iterator, boost::spirit::multi_pass_policies::ref_counted, boost::spirit::multi_pass_policies::buf_id_check, boost::spirit::multi_p
[20:05:47] * mru did not make that up
[20:05:50] <cartman> mru: boost is the best
[20:06:11] <lu_zero> mru: boost is the Glaring example why you shouldn't use C++
[20:06:23] <cartman> or why we need better C++ compilers ;)
[20:06:41] <lu_zero> cartman: or uncruft the language
[20:06:49] <cartman> lu_zero: sadly not happening
[20:06:54] <cartman> time to run! bye.
[20:07:11] <lu_zero> sigh
[20:07:47] <mru> http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
[20:11:01] <BBB> wbs: don't really remember, if I didn't reply it's probably ok or so?
[20:11:09] <BBB> wbs: or if you want input, you could kick it
[20:11:16] * BBB was a little busy last few weeks
[20:11:44] <wbs> it was earlier today, but I don't think there's much to be said on it really, it's quite straightforward
[20:11:48] <wbs> I'll apply it then
[20:14:41] <mru> Vitor1001: did anyone reply about that pgi compiler?
[20:14:43] <BBB> I don't see it... I probably missed it, but yeah, if you're confident it's right I trust you that it's fine
[20:14:50] <Vitor1001> mru: No reply atm
[20:15:00] <BBB> mru: hey, you're on intel developer network now? :)
[20:15:40] <mru> it was the simplest way to find the unprotected urls to download icc
[20:15:56] <Vitor1001> BTW, is the general hatred against C++ in ffmpeg related to the language itself or to overexposure to bad c++ code?
[20:16:06] <BBB> wbs: oh that one, yes it's fine
[20:16:10] <mru> Vitor1001: those two are related
[20:16:18] <wbs> ok
[20:16:40] <BBB> wbs: sorry for not seeing it earlier
[20:16:53] <wbs> BBB: no problem :-)
[20:17:05] <Vitor1001> mru: Bad c++ code is more related about the lowest bottom of the C++ users
[20:17:35] <Vitor1001> things like "OO is the answer for everything" or "let's break ffmpeg into classes" is unrelated to c++
[20:18:29] <mru> _ZGVZN5boost6spirit4impl17escape_char_parseIcE5parseINS0_7scannerINS0_10multi_passISt16istream_iteratorIccSt11char_traitsIcElENS0_19multi_pass_policies14input_iteratorENSB_11ref_countedENSB_12buf_id_checkENSB_9std_dequeEEENS0_16scanner_policiesINS0_27no_skipper_iteration_policyINS0_28skip_parser_iteration_policyINS_6detail5graph11dot_skipperENS0_16iteration_policyEEEEENS0_12match_policyENS0_13action_policyEEEEENS0_18escape_char_parserILm1EcEEEENS0_13pars
[20:18:32] <CIA-63> ffmpeg: mstorsjo * r25154 /trunk/libavformat/tcp.c:
[20:18:32] <CIA-63> ffmpeg: tcp: Check both wfds and efds when waiting for the result from connect
[20:18:32] <CIA-63> ffmpeg: On windows, a connection failure doesn't trigger wfds as it does on unix.
[20:18:32] <CIA-63> ffmpeg: This fixes issue 2237, based on code by yeyingxian.
[20:18:37] <mru> ^^ that is one reason to hate c++
[20:18:54] <Vitor1001> mru: I bet can do it with C if I try hard enough ;)
[20:19:05] <spaam> Vitor1001: do it
[20:19:08] <mru> I know of no other language capable of producing such incomprehensible gibberish
[20:19:55] <Vitor1001> mru: Can't this code be translated line-by-line to java or OO-forced C?
[20:20:14] <mru> that's a single symbol
[20:20:18] <Vitor1001> by "OO-forced" I mean structs with tons of function pointers
[20:20:20] <mru> no code at all
[20:20:45] <BBB> aiyoh
[20:20:46] <Vitor1001> How was that generated?
[20:20:46] <BBB> oops
[20:20:58] <mru> nm libboost.so
[20:21:14] <mru> I figured that would be a good place to find a nasty one
[20:22:17] <Vitor1001> In C it would be hidden in a maze of function pointers, but the symbol would have a nice name
[20:22:46] <mru> no C programmer would come up with such a contorted design
[20:22:53] <pJok> mru, i want to believe that that post with Bjarne saying that C++ was a joke is true
[20:24:12] <Vitor1001> mru: Yes, because C++ turned into the language of choice for overengineering.
[20:24:47] <ohsix> but its fun to stub out classes
[20:24:58] <mru> so why have I never seen one single well-written c++ app?
[20:24:59] <Vitor1001> mru: But IMHO it has more to do with the way people teach OO in college...
[20:25:26] <mru> http://pastie.org/928309
[20:25:31] <mru> debug that!
[20:26:23] <Vitor1001> How ifdef misuse is C++ specific?
[20:26:54] <mru> wow, there's a symbol in that lib whose demangled name is 21901 bytes
[20:26:54] <Dark_Shikari> mru: you haven't seen many wellw-ritten apps period
[20:26:58] <Dark_Shikari> ffmpeg certainly isn't a well-written C app
[20:27:08] <mru> a fucking 20k SYMBOL NAME!
[20:27:18] <thresh> awesome
[20:27:23] <ohsix> thats what you get when you share an encoded namespace with c ;]
[20:28:00] <BBB> Dark_Shikari: at least it does something for the 3MB that the binary takes on my HD
[20:28:11] <BBB> Dark_Shikari: as opposed to 90% of the libs on a standard linux dist
[20:28:13] <mru> http://pastebin.ca/1946106
[20:28:20] <BBB> *ugh* gnome
[20:28:55] <BBB> wrappertiewrappertiewrap
[20:29:00] <Vitor1001> mru: Language feature abuse IMHO. C++ don't forces you into that mess.
[20:29:13] <mru> it does pull really hard
[20:29:17] <mru> or so it seems
[20:29:28] <Dark_Shikari> mru: "big apps tend to be a mess"
[20:29:35] <mru> true
[20:29:49] <Vitor1001> mru: It is more likely that people that likes this mess is attracted to c++
[20:29:51] <mru> but with C you stand at least some chance to cut through the mess
[20:30:28] <mru> Vitor1001: whatever, I simply don't see how c++ would solve any of my problems in a simpler way
[20:30:40] <mru> however, I have often seen c++ _create_ problems
[20:30:42] <ohsix> the part that bugs me is for all the sugar it offers it ends up being in lots of lines of crap that don't do anything but add indirection that you have to fight through
[20:30:44] <Vitor1001> mru: For me, it looks more like that C++ just gives you more features if you want to obfuscate your code.
[20:31:02] <Vitor1001> mru: In ffmpeg there would be no point.
[20:31:25] <lu_zero> 22:28 <@Vitor1001> mru: Language feature abuse IMHO. C++ don't forces you into  that mess.
[20:31:30] <lu_zero> ehm
[20:31:36] <Vitor1001> Maybe templates for having floating-point and fixed point versions of the same codec but that's it.
[20:31:36] <mru> more often than not when confronted with c++ code, I struggle to find the parts that actually do anything useful
[20:31:42] <lu_zero> the symbol mangling happens always...
[20:31:44] <mru> rather than being wrappers around each other
[20:32:10] <mru> what I posted is the unmangled name
[20:32:13] <lu_zero> Vitor1001: you can try using clang abberration
[20:32:16] <lu_zero> pardon extension
[20:32:18] <mru> that's what the damn thing is actually called
[20:32:32] <Vitor1001> mru: I know you that plain-C is almost always valid c++. You don't _have_ to use anything else if there is no point.
[20:32:53] <mru> then why bother?
[20:32:58] <mru> like to wait longer for builds?
[20:33:05] <mru> like your binaries larger?
[20:33:11] <mru> like more bugs in the compiler?
[20:33:24] <Vitor1001> mru: You might use the other features _when it is worth it_
[20:33:27] <mru> like to have the sky fall down every time you switch compilers?
[20:33:30] <Vitor1001> and not just for the sake of it
[20:33:38] <mru> Vitor1001: I have never seen a case where they were
[20:33:51] <ohsix> its not a foregone conclusion that there is, either
[20:34:03] <lu_zero> Vitor1001: we tried to figure out which is the compelling feature
[20:34:04] <ohsix> but in the realm of all possibility you never know
[20:34:05] <lu_zero> none found
[20:34:46] <Vitor1001> For some kinds of programs, OO is useful (again, not ffmpeg)
[20:35:08] <mru> found an even longer one
[20:35:14] <mru> 36056 chars
[20:36:29] <lu_zero> Vitor1001: OO is perfectly attainable using C
[20:36:42] <Vitor1001> lu_zero: yes, but uglier.
[20:36:53] <Dark_Shikari> mru: pastebin it
[20:36:54] <mru> no
[20:37:20] <lu_zero> Vitor1001: how so?
[20:37:26] * lu_zero points boost
[20:37:29] <ohsix> at the very least doing it yourself keeps it from rigidly being one paradigm; you can compose the best to suit the situation
[20:37:30] <mru> Dark_Shikari: waiting for it to upload
[20:37:32] <lu_zero> uglier?
[20:37:38] <mru> http://pastebin.ca/1946114
[20:37:40] * lu_zero points gobject
[20:37:44] <lu_zero> is that uglier?
[20:38:12] <ohsix> RAII is like the only thing i can think of off the top of my head thats worth it; and thats just from the unwind/scope rules
[20:38:18] <Vitor1001> lu_zero: Haven't seen gobject.
[20:39:17] <mru> you don't need to emulate c++ syntax to be OO
[20:39:35] <Honoome> mru: half-pong, please mail me, today I'm feverish so not really here
[20:39:41] <mru> ffmpeg is rather OO
[20:39:55] <Dark_Shikari> mru: no, ffmpeg largely uses the "big struct of stuff" method
[20:40:03] <Dark_Shikari> Look at, say, the h264 decoder.
[20:40:08] <mru> Honoome: I noticed your name in the icc ebuilds
[20:40:15] <mru> Honoome: still got anything to do with those?
[20:40:20] <Dark_Shikari> the "big struct of stuff" involves a struct with all state stored in it
[20:40:26] <Dark_Shikari> instead of information-hiding as in OO
[20:40:34] <mru> Dark_Shikari: I was thinking of the API
[20:40:36] <Honoome> mru: nope, once they began charging or requiring non-commercial licenses I gave u
[20:40:38] <Honoome> +p
[20:40:50] <Dark_Shikari> is there a programming term for the "big struct of stuff"?
[20:41:02] <mru> BSOS
[20:41:07] <lu_zero> tortellini coding?
[20:41:26] <Dark_Shikari> It's not a big ball of mud, because it's not necessarily a bad design
[20:41:34] <Dark_Shikari> and it's not necessarily thrown together
[20:41:41] <Dark_Shikari> (but usually is)
[20:41:43] <ohsix> variable clearinghouse
[20:41:57] <Dark_Shikari> lol
[20:42:09] <twnqx> The Core
[20:42:20] <ohsix> graduation
[20:42:47] <Dark_Shikari> A classic example of something that's hard to represent in OO
[20:42:56] <Dark_Shikari> in x264, the OO way of doing MC would be something like
[20:43:10] <Dark_Shikari> MCPixelBuffer mc = new MC(mvx, mvy);
[20:43:21] <Dark_Shikari> to do motion compensation
[20:43:34] <Dark_Shikari> but in x264, there are some cases where an MC is done as part of analysis that can be re-used during the final encode.
[20:43:35] <mru> few real-world problems decompose into a clean hierarchy of "objects"
[20:43:42] <Dark_Shikari> how would you "stash" that?
[20:43:49] <Dark_Shikari> how would you "remember" that you had done it?
[20:43:58] <Dark_Shikari> it doesn't fit cleanly into OO.  as mru said.
[20:43:58] <mru> they rather tend to be interrelated in very non-hierarchical ways
[20:44:04] <ohsix> tagged buffers ftw
[20:44:15] <Dark_Shikari> i.e. when you start doing optimization, OO starts to break apart
[20:45:18] <ohsix> thats one of the reasons its important to have freedom of composition
[20:45:29] <Dark_Shikari> But... OO is the one true standard!
[20:45:42] <Dark_Shikari> everyone should develop OO!
[20:45:51] <lu_zero> uhmm
[20:45:58] <lu_zero> ACC might be interesting
[20:46:19] <ohsix> they like to teach it because Oranges are Orange, and .color() is familiar to the uninitiated
[20:47:07] <ohsix> the comprehensibility from drawing from irl junk gets idiots pretty hot and bothered right up front, entheusiasm is important for teaching
[20:48:23] <BBB> Dark_Shikari: big struct of stuff (BSS) is already reserved for mod playback
[20:48:24] <BBB> :-p
[20:49:02] <lu_zero> BBB: don't recall that
[20:49:31] <BBB> vitor would remember
[20:49:31] <spaam> How does it go with that libavseq thing ? :D
[20:49:35] <NTQ> hi there. is ffmpeg able to make a video from pictures which are streamed through stdin?
[20:49:49] <Dark_Shikari> yes.  now ---> #ffmpeg
[20:50:22] <BBB> spaam: it's finished, it's called pinkskybluecows
[20:50:48] <spaam> BBB: haha ;D
[20:50:49] <NTQ> Dark_Shikari: no questions here?
[20:50:59] <spaam> NTQ: read the topic .9
[20:51:24] <NTQ> sorry
[21:34:49] <lu_zero> mru: ever had a look at aspectC?
[21:40:42] <BBB> isn't there a language called D?
[21:40:45] <_av500_> yes
[21:41:02] <_av500_> lu_zero: i used aspectR
[21:42:28] <lu_zero> BBB: D is something aspectC something else
[21:42:34] <lu_zero> _av500_: R with aspects?
[21:43:14] <_av500_> lu_zero: sorry, it was aspect_n and aspect_d
[21:43:43] <lu_zero> aspectC looks like the preprocessor we were discussion or not
[21:44:12] <lu_zero> uh actually aspectR does exist and is the ruby flavor of aspectJ
[21:52:21] <lu_zero> s/discussion/discussing
[22:01:09] <iive> am I the only one who can't compile current svn?
[22:06:11] <lu_zero> which error?
[22:06:16] <lu_zero> which arch?
[22:09:37] <iive> "Makefile:61: *** target pattern contains no `%'.  Stop."
[22:10:07] <iive> make --version is 3.82
[22:12:14] <lu_zero> 3.81 works
[22:14:45] <mru> iive: make 3.82 is intentionally subtly incompatible with 3.81
[22:14:48] <mru> because they can
[22:15:38] <mru> moreover, that error makes no fucking sense
[22:15:52] <mru> lu_zero: never heard of aspectc
[22:16:52] <iive> that line is all I get...
[22:17:07] <mru> it's a perfectly normal rule
[22:17:13] <mru> on line 61
[22:17:25] <mru> not a pattern rule of any kind
[22:22:07] <CIA-63> ffmpeg: diego * r25155 /trunk/libavformat/Makefile: cosmetics: Place concat protocol entry in alphabetical order.
[22:27:26] <iive> downgraded to 3.81 and it compiles.
[22:33:33] <lu_zero> mru: http://research.msrg.utoronto.ca/ACC
[22:33:58] <lu_zero> I'm not sure if it's fun or overdesigned
[22:35:59] <kierank> lu_zero: the word "research" in the url should give you a clue
[22:37:39] <mru> wtf @ their hello world example
[22:39:15] <mru> looks great for spaghetti code
[22:42:04] <lu_zero> mru: the example is a bit ill conceived
[22:42:31] <lu_zero> kierank: in itself is quite compact
[22:43:32] <lu_zero> mru: it could replace most of our preprocessor-template usage
[22:43:50] <mru> standard C preprocessor is fine
[22:44:38] <lu_zero> mru: s/fine/works-till-a-point
[22:45:03] <lu_zero> tracking bugs on macros can be annoying
[22:45:19] <mru> so don't put bugs there
[22:45:19] <CIA-63> ffmpeg: iive * r25156 /trunk/libavcodec/mpegvideo.c:
[22:45:19] <CIA-63> ffmpeg: The debug text output of macroblocks can indicate MB_TYPE_INTERLACED,
[22:45:19] <CIA-63> ffmpeg: but it used to do it only for h264 codec.
[22:45:19] <CIA-63> ffmpeg: Allow it for other codecs, as mpeg2 and mpeg4 also set this flag.
[22:46:10] <mru> having a function call hijacked by unseen code in a different file looks scary
[22:46:40] <mru> nor do I see what it would be good for
[22:46:57] <mru> it's a "research" project, ignore it
[22:47:03] <astrange> the general use is logging other people's code you don't want to touch, i think
[22:47:10] <astrange> which is the kind of thing java people want to do
[22:48:22] <mru> and which we couldn't care less for
[22:50:07] <lu_zero> it can be used for code that has a common chunk to factorize it
[22:50:24] <mru> in a most incomprehensible way
[22:50:45] <mru> would it be so hard to just put that function call where you want it?
[22:51:16] <iive> ok, it wasn't make 3.82 fault. The pathname of the source contained ":"
[22:52:09] <mru> instead of writing a complicated description of how what you wrote should be altered to do what you really meant
[22:52:23] <mru> isn't that what #pragma dwim is for?
[22:53:47] <lu_zero> uh?
[22:54:24] <mru> if you want function foo() to call bar() and then baz(), write that
[22:54:51] <mru> don't write a function foo that calls baz() and write in another file that, actually, before foo calls baz it should call bar
[22:55:24] <lu_zero> like PIXOP2 ...
[22:55:37] <mru> I see no resemblance
[22:56:43] <lu_zero> that macro generates a batch of function with small differences
[22:56:55] <mru> so?
[22:57:01] <mru> that's a completely different thing
[22:57:20] <mru> it's easy enough to expand it
[22:57:31] <mru> and obvious that something like that is going on
[22:58:18] <mru> there's no code appearing perfecly normal, but altered by code _in another file_ without prior warning
[22:58:38] <mru> if anything, it resembles swscale
[22:58:44] <lu_zero> ok, I agree that way to implement it has this shortcoming
[22:58:44] <mru> and look how maintainable that is
[22:59:00] <lu_zero> mru: swscale had bitten me a lot
[23:02:04] <mru> exactly my point
[23:03:28] <mru> template systems are fine if when looking at a template, it is immediately obvious that it is one
[23:03:36] <mru> well, for certain values of fine
[23:04:16] <mru> if you can't tell an actual function from something that will be rewritten by god knows what, you're in trouble
[23:06:29] <lu_zero> aspects might help if you have a way to tell where they are applied, I do agree
[23:06:43] <lu_zero> (and that's why I like way better python decorators)
[23:13:43] <mru> it's a bit like the intercal comefrom directive
[23:25:43] <bcoudurier> hey guys\
[23:26:04] <saintdev> i'm confused, it has a typo, is it really an onjoin
[23:26:15] <mru> same typo as yesterday
[23:26:25] <saintdev> lol, didn't see it yesterday
[23:26:55] <saintdev> hey bcoudurier's onjoin script\
[23:27:12] <bcoudurier> lol
[23:31:09] <mru> hey look, icc on ia64
[23:31:22] <mru> and it's not pretty
[23:32:08] <kierank> I didn't even notice ia64 in fate till now ;)
[23:32:47] <mru> we have quite a collection
[23:33:11] <bcoudurier> does anybody know zencoder ?
[23:33:20] <Dark_Shikari> Yes
[23:33:30] <Dark_Shikari> what about them?
[23:34:32] <bcoudurier> what are they using ?
[23:34:38] <kierank> x264
[23:34:38] <Dark_Shikari> ffmpeg, x264
[23:34:51] <bcoudurier> • We fix edge cases. To date, we’ve solved more than 50 problems compared to a typical transcoding process using a tool like ffmpeg. Without these fixes, you’ll run into unsupported codecs, audio/video sync problems, intermittent failures, aspect ratio distortion, interlaced content, rotated content, corrupt files, and more. If you just use ffmpeg alone, for example, you won’t be able to support dozens of codecs, including some that ar
[23:34:51] <bcoudurier> e commonly used. Don’t expect to support WPV2, MSS2, files with Quicktime edit lists, etc.
[23:35:28] <bcoudurier> this is actually true, though I was wondering what they did to remedy these ? Like using OSX/Windows as a fallback
[23:35:30] <kierank> lol biting the hand that feeds you
[23:35:51] <bcoudurier> yeah
[23:35:52] <bcoudurier> kinda lame
[23:35:55] <mru> shall we troll them?
[23:36:00] <mru> mediacoder style
[23:36:01] <bcoudurier> we should troll them IMHO
[23:36:10] <mru> overlays ftw
[23:36:17] <Dark_Shikari> bcoudurier: I can contact them and tell them to tell their marketing department to stop being dicks.
[23:36:22] <Dark_Shikari> I've worked with them before.
[23:36:41] <Dark_Shikari> They _do_ have workarounds for a lot of these issues
[23:36:44] <Dark_Shikari> and their point is perfectly valid
[23:36:49] <Dark_Shikari> but what they're providing is a _value-add_
[23:36:53] <Dark_Shikari> not a _replacement_
[23:36:58] <mru> have they patched ffmpeg?
[23:37:02] <Dark_Shikari> No
[23:37:14] <Dark_Shikari> They have your typical Youtube/Facebook-style hackaround script.
[23:37:17] <mru> 'cause if they have, sharing would be nice
[23:37:36] <Dark_Shikari> Though, arguably, they're not lying
[23:37:43] <Dark_Shikari> "compared to a typical transcoding process using a tool like ffmpeg"
[23:37:47] <Dark_Shikari> TECHNICALLY, this doesn't imply that they don't use ffmpeg.
[23:37:51] <Dark_Shikari> It's saying that their process isn't typical.
[23:38:06] <mru> true or not, it's a bit rude
[23:38:30] <mru> so if you think you can make them stop, please
[23:41:10] <BBB> they don't distribute ffmpeg do they?
[23:41:16] <BBB> otherwise I'd ask aaron to piss them off
[23:42:15] <Dark_Shikari> of course not
[23:42:19] <Dark_Shikari> They're open-source friendly
[23:42:23] <Dark_Shikari> it's likely just their marketing being a bit silly
[23:42:32] <Dark_Shikari> I poked their CEO
[23:42:44] <Dark_Shikari> or main guy, whatever.  they're just a startup
[23:44:17] <BBB> introduce him to me sometime
[23:46:58] <DonDiego> bcoudurier: alternatively, you could finally fix edit lists in mov :)
[23:47:14] <DonDiego> mike did that for xine 10 years ago i think...
[23:47:36] <Dark_Shikari> lol
[23:53:42] <bcoudurier> DonDiego, yeah I should and bug them afterwards ;)
[23:54:40] <DonDiego> oh yes, please, let's fix all the issues they mention promptly..
[23:54:54] <DonDiego> and then complain wtf they are talking about..
[23:54:56] <DonDiego> :)
[23:56:10] <astrange> my youtube uploads would work a lot better if it supported edit lists deleting the beginning of the video track
[23:56:13] <astrange> aka negative pts
[23:57:35] <Dark_Shikari> even if that's fixed, youtube won't update until 2015