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

[irc at mansr.com]

[05:48:24] <_av500_> strange atrac-tors?
[05:49:16] <kshishkov> it's a Sony!
[05:49:22] <kshishkov> (really)
[05:53:42] <_av500_> i gave up on sony after the WM DD II
[05:57:06] <kshishkov> well, they produced the best CRTs
[05:57:54] <kshishkov> the rest of Sony products - nah, I'd rather buy something else
[06:09:14] <KotH> moin
[06:09:43] <KotH> .o0(why is it, that my name pops up in every discussion about food?)
[06:25:50] <_av500_> KotH: coz you got +v on #ffood
[06:28:40] <KotH> and why is that ? ^^'
[06:29:52] <kshishkov> because .ch got third world-best cheese and maybe second world-best chocolate
[06:30:48] <KotH> .o0(kshishkov seems to have a strange cheese and chocolate ranking)
[06:31:19] <kshishkov> KotH: cheese - Sweden, Holland, Switzerland
[06:32:23] <KotH> and choco?
[06:32:33] <kshishkov> as for chocolate, French or Italian might be better than Swiss
[06:33:01] * KotH heavily disagrees there
[06:34:16] * kshishkov doesn't question the right of KotH to disagree
[06:34:58] <KotH> as for the cheese, i dont think that dutch cheese is better, never had swedish chese
[06:35:14] <KotH> though, imho turkish cheese is by taste and variety much better than swiss
[06:36:10] <kshishkov> depends on what cheese type you like
[06:36:30] <KotH> good cheese ;)
[06:36:36] * kshishkov still has a bit of Greve
[06:38:12] <kshishkov> KotH: Russian cheese then - it's homogenous and has no taste
[06:38:31] <KotH> that's not exactly my definition of good
[06:38:51] <kshishkov> neither is mone, but you haven't provided yours
[06:39:09] <KotH> come to turkey once, and we'll have a selection :)
[06:42:18] <kshishkov> Turkish is not in my definition of good either
[06:58:49] <KotH> kshishkov: it seems like you are traumatized in your early childhood in that regard
[07:12:52] <kshishkov> KotH: wrong. In early childhood "Turkish" didn't mean crap or counterfeit to me, it was a bit later
[07:14:08] <kshishkov> in general, it was below Polish quality
[08:42:37] * lu_zero points French cheese as solution
[08:43:14] <lu_zero> kshishkov: if you happen to pass by Torino I'll have you try some border products ^^
[09:25:31] <funman> http://www.ipaddress.su/
[11:08:29] <mru> those flac numbers from felipec are weird
[11:08:43] <mru> fflac is already 50% faster than libflac
[11:08:47] <mru> on beagle
[11:08:51] <Dark_Shikari> That doesn't surprise me
[11:09:10] <mru> and I have a couple of patches making it 25% faster again
[11:09:31] <mru> comparing ffmpeg command line to flac command line btw
[11:09:38] <Dark_Shikari> have you written asm for lpc?
[11:09:55] <mru> I have asm for an order-8 fir filter
[11:10:14] <mru> that's where it spends most of the time
[11:10:32] <Dark_Shikari> why only order 8?
[11:10:36] <Dark_Shikari> order depends on the block lpc order
[11:10:43] <mru> I was too lazy to write the others
[11:10:45] <Dark_Shikari> lol
[11:11:21] <mru> and profiling showed order 8 was used vastly more than any other
[11:12:39] <Dark_Shikari> that may depend on the flac files you're testing
[11:12:42] <Dark_Shikari> and who encoded them
[11:12:48] <Dark_Shikari> s/who/what
[11:12:52] <mru> well, sure
[11:13:04] <mru> still have to start somewhere
[11:16:52] <Dark_Shikari> in the case of order 7, does it call the asm with 8 equal to zero?
[11:16:55] <Dark_Shikari> er, the 8th lpc
[11:17:15] <mru> no, not yet at least
[11:17:22] <mru> but sure, that could be done
[11:17:41] <Dark_Shikari> that would be a good way to get some of them done "for free"
[11:17:47] <Dark_Shikari> you could do e.g. 12, 8, and 4
[11:17:50] <Dark_Shikari> and do the rest via zeros
[11:31:11] <mru> it's not like doing 7 would be faster than 8 with simd
[11:31:35] <Dark_Shikari> exactly
[11:31:38] <Dark_Shikari> well, it depends
[11:31:49] <Dark_Shikari> I guess 7 wouldn't be, 6 might be.
[11:32:08] <mru> if you can do only 2 muls, yes
[11:32:40] <Dark_Shikari> Or if 2 muls are faster than 4.
[11:32:48] <mru> same thing
[11:32:52] <Dark_Shikari> are these 16-bit or 32-bit?
[11:32:59] <Dark_Shikari> 16x16->32?
[11:37:49] <funman> none of the fate machines running gcc 4.6.0 use -flto?
[11:39:03] <Dark_Shikari> -fmakemyprogramslower
[11:39:07] <Dark_Shikari> -fuck-up
[11:39:13] <Dark_Shikari> -fubar
[11:39:49] <mru> 16x17
[11:39:53] <mru> at least sometimes
[11:39:59] <Dark_Shikari> Oh, it's *THAT* one.
[11:40:06] <Dark_Shikari> the obnoxious "look at me, I don't fit in simd"
[11:41:04] <mru> 15x17 actually
[11:41:06] <funman> Dark_Shikari: i think it's nothing more than -O* but at link time..
[11:41:16] <Dark_Shikari> funman: yes.  and it's gcc, so it sucks
[11:41:24] <Dark_Shikari> (and yes I've confirmed it.  lto makes x264 slower)
[11:41:29] <mru> that's not exclusive to gcc
[11:41:34] <funman> not only x264
[11:41:47] <Dark_Shikari> what other compilers have broken as fuck lto?
[11:41:54] <mru> all that have it at all
[11:42:01] <Dark_Shikari> really?
[11:42:04] <Dark_Shikari> why
[11:42:14] <Dark_Shikari> there's nothing inherently hard about lto.  if anything it's easier
[11:42:17] <mru> lto is a big, ugly monster built to scare some speed into c++
[11:42:20] <Dark_Shikari> though -fwhole-program is probably easier for that
[11:42:21] <mru> you don't need it with c
[11:42:30] <Dark_Shikari> In theory, it lets you make smarter aliasing decisions
[11:42:38] <Dark_Shikari> and lets you take non-exported non-static functions and optimize them
[11:42:51] <Dark_Shikari> based on how they are called
[11:42:59] <funman> yes it reduces a bit binsize
[11:43:01] <Dark_Shikari> e.g. param passing etc
[11:43:06] <mru> that's theory
[11:43:08] <Dark_Shikari> gcc of course is still incredibly retarded
[11:43:10] <Dark_Shikari> with aliasing
[11:43:16] <Dark_Shikari> I've tested this with its debug capabilities for aliasing
[11:43:38] <Dark_Shikari> if a is a pointer to a struct
[11:43:42] <Dark_Shikari> and b is a function pointer
[11:43:54] <Dark_Shikari> a->b(); will cause gcc to reload the pointer to be into a register
[11:44:00] <Dark_Shikari> *to b
[11:44:01] <Dark_Shikari> under the assumption b could have modified it.
[11:44:08] <Dark_Shikari> this is perfectly reasonable -- a compiler has to do this
[11:44:14] <Dark_Shikari> But if LTO is on...
[11:44:20] <Dark_Shikari> oh it still does it anyways.
[11:44:29] <Dark_Shikari> even though it should "know" all the code and be able to be smart.
[11:45:01] <Dark_Shikari> but hey, gcc
[11:45:11] <Dark_Shikari> Oh yeah, and the fact that gcc cannot have "pure" function pointers is retarded.
[11:45:58] <Dark_Shikari>  /me wonders what the point of a "this function has no side effects" option is if you can't use it
[11:47:09] <Dark_Shikari> (and yes, the answer is "because libc")
[11:47:28] <mru> ?
[11:47:42] <Dark_Shikari> __attribute__((pure)) says that a function doesn't have side effects
[11:47:49] <Dark_Shikari> this is REALLY useful for DSP functions and such
[11:47:56] <mru> yes, I know
[11:47:59] <Dark_Shikari> Or, it would be -- but you can't apply it to function pointers.
[11:48:01] <Dark_Shikari> Only functions.
[11:48:04] <mru> yes
[11:48:07] <Dark_Shikari> Why?  Because it was only created for the benefit of libc.
[11:49:09] <mru> gcc and glibc only care about each other
[11:49:54] <pJok> the lovely world of RMS and GNU
[11:50:38] <Dark_Shikari> mru: >implying that glibc cares about ANYONE.
[11:51:03] <mru> they only care about working with gcc
[11:51:09] <funman> Ulrich Drepper is a nice guy
[11:51:15] <mru> their headers don't work with many other compilers
[11:52:28] <Dark_Shikari> portability?  we don't need that, that sounds like something ships need to dock.
[11:53:09] <mru> but it's all in line with the larger fsf agenda
[11:53:22] <mru> locking people into their software
[11:54:09] <mru> their goal is that no other software should exist
[11:54:21] <mru> and thus other compilers etc are of no concern to them
[11:54:31] <funman> it's an admitted goal at least
[11:56:54] <Dark_Shikari> mru: the sad part is that a lot of those claiming to try to break the attempted GNU monopoly are even less competent
[11:57:02] <Dark_Shikari> like llvm
[11:57:19] <mru> llvm is trading rms for jobs
[11:57:25] <mru> I don't know which is worse
[11:57:51] <Dark_Shikari> I don't think jobs has quite as much control as rms does.
[11:58:24] <mru> almost all useful development on llvm has been done by apple
[11:58:32] <mru> they can choose to stop at any time
[11:58:35] <Dark_Shikari> >useful
[11:58:35] <mru> and they will
[11:58:36] <Dark_Shikari> >llvm
[11:58:50] <mru> come on, it actually does compile stuff
[11:59:28] <Dark_Shikari> my racecar moves very fast.
[11:59:31] <Dark_Shikari> it only does so when falling off a cliff
[11:59:35] <Dark_Shikari> but nevertheless, it moves very fast.
[11:59:56] <mru> it builds ffmpeg correctly
[12:00:01] <Dark_Shikari> oh, it does now?
[12:00:04] <mru> yes
[12:00:08] <Dark_Shikari> impressive.
[12:00:13] <mru> fate says so at least
[12:00:24] <Dark_Shikari> so they fixed the inline asm?
[12:00:37] <mru> they fixed some, we fixed some
[12:00:52] <mru> and setting stack alignment to 16 magically fixed one
[12:00:54] <Dark_Shikari> of course the obvious joke there is
[12:01:01] <Dark_Shikari> yes, we fixed it -- by moving it to yasm
[12:03:09] <mru> btw suncc hates our inline asm for bswap64
[12:03:48] <mru> which I suspect could actually be replaced with __builtin_bswap64
[12:03:50] <Dark_Shikari> suncc claims to support gcc inline asm?
[12:03:54] <Dark_Shikari> mru: "beware the builtins"
[12:04:00] <mru> I know
[12:04:05] <mru> but bswap on intel is fine
[12:04:33] <mru> when they work, there is no reason not to use them
[12:06:06] <mru> hmm, it works since gcc 4.3
[12:06:20] <mru> I wonder which gcc suncc pretends to be
[12:06:33] <mru> and whether the bswap builtins work
[12:21:04] <lu_zero> worth trying
[12:21:32] <lu_zero> Dark_Shikari: do you know a compiler that is either working the way you like or that appears fixable btw?
[12:22:24] <funman> yasm? :)
[12:22:40] <mru> imo compiler developers should strive to make the compiler do as well as possible the things a compiler can reasonably do
[12:23:02] <mru> instead of, as now, try really hard to make them do things they'll never be particularly good at
[12:23:08] <lu_zero> funman: yasm isn't a C compiler =P
[12:23:31] <mru> maybe Dark_Shikari can write a C compiler in yasm macro language
[12:23:43] <lu_zero> mru: _don't_ give him ideas!
[12:23:49] <Dark_Shikari> C is not a very good language
[12:24:06] <lu_zero> do you have something better?
[12:24:32] <mru> I'd be fine with parts of ffmpeg being written in fortran
[12:25:12] <Dark_Shikari> mru: HCEnc is an mpeg-2 encoder (one of the best) written entirely in fortran
[12:25:15] <Dark_Shikari> well, and yasm
[12:25:55] <mru> now most people bitching about C haven't even heard of fortran
[12:26:12] <mru> they prefer to talk about python, ruby, and managed runtimes
[12:26:24] <mru> all of which are totally useless for codec work
[12:26:52] <Dark_Shikari> fortran's only advantage over C is the lack of aliasing issues
[12:26:54] <lu_zero> uh, there is even a f2008
[12:27:11] <Dark_Shikari> and bad array handling of gcc
[12:27:18] <Dark_Shikari> and lack of write-combining etc
[12:27:36] <mru> it is possible to write a bad compiler for any language
[12:28:02] <Dark_Shikari> it's possible for a language to exacerbate the problem
[12:28:06] <Dark_Shikari> or make the problem easier to handle
[12:28:10] <Dark_Shikari> <pengvado> gcc fails to optimize it because gcc has always sucked at arrays
[12:28:14] <Dark_Shikari> <pengvado> that's *the* benefit of fortran
[12:28:19] <mru> what I'm getting at is that fortran doesn't have a huge inherent overhead like all these modern so-called languages
[12:29:00] <mru> one strong point for C is that it's reasonably easy to manipullate the compiler into doing what you want
[12:29:07] <Dark_Shikari> Yeah
[12:36:25] <KotH> i think most languages suck because they were either designed by CS people who wanted to prove some point or by pragmatics who had no clue what they were getting into
[12:37:05] <Dark_Shikari> I think most languages suck because of sturgeon's law
[12:37:07] <Dark_Shikari> 90% of everything is crap
[12:37:21] <mru> C was designed by smart people to solve a real problem
[12:37:31] <Dark_Shikari> for every Fortran, C, ML, or Python, there are a dozen Rubys or Javas.
[12:37:44] <Dark_Shikari> It's also because there are far more languages than are necessary
[12:37:46] <mru> python isn't all that great
[12:37:48] <Dark_Shikari> therefore, they necessarily overlap in capabilities
[12:37:53] <Dark_Shikari> and thus some will be better than others
[12:38:10] <Dark_Shikari> Python is pretty much the best language in its niche
[12:38:16] <lu_zero> s/python/perl/ if you like better
[12:38:28] <Dark_Shikari> I would argue that readability is in fact a plus here.
[12:38:29] <lu_zero> still python right now is nicer to hack with
[12:39:26] * KotH disagrees strongly
[12:39:51] <Dark_Shikari> fffffff my connection is ACK-bottlenecked
[12:40:01] <Dark_Shikari> that is,  my download speed is being limited because I can't send enough ACKs.
[12:40:23] <KotH> mru: i'm not saying that the pragmatics are not smart, but rather they tend to be too focusted on their problem to see the problems their solution might cause
[12:40:52] <KotH> Dark_Shikari: you definitly need an ackelerator
[12:40:57] <Dark_Shikari> Oh, interesting.  Steam doesn't use standard TCP
[12:41:03] <Dark_Shikari> No wonder it's so much faster than any normal download method
[12:41:04] <KotH> steam?
[12:41:13] <Dark_Shikari> It's not sending ACKs
[12:41:14] <lu_zero> what's using?
[12:41:16] <lu_zero> ah
[12:41:21] <lu_zero> id-tcp
[12:41:38] <iive> Dark_Shikari: if you have big enough window, you can send very few ack's
[12:41:49] <lu_zero> iirc is what was used since quake or something like that
[12:41:51] <iive> big windows are tcp extension.
[12:41:52] <KotH> iive: only if the host on the other side support it
[12:42:09] <KotH> iive: and even then....
[12:42:19] <Dark_Shikari> steam is downloading at 70-90mbps and uploading at about 5kbps
[12:42:47] <KotH> iive: with today DBP it's not easy to max out inet connections w/o compromising the security of the host
[12:43:02] <Dark_Shikari> I don't think you can get that kind of ratio with normal TCP
[12:43:14] <Dark_Shikari> that's a 20,000 to 1 DL:UL ratio
[12:43:20] <KotH> Dark_Shikari: which steam are you talking about?
[12:43:35] <Dark_Shikari> that thing you buy games from
[12:43:53] <Dark_Shikari> http://en.wikipedia.org/wiki/Steam_%28software%29
[12:44:38] <iive> with the extension you can have 4gb window, and confirm it with one ack. with sack ext you can avoid retransmission of few dropped packets.
[12:45:43] <KotH> iive: as i said above, that highly depends on the os you are using. and most os dont allow tweaking those values for mere mortals
[12:48:19] <iive> windows supports it for 10 years, linux long before that. If I remember correctly, the window size could be re-negotiated, in case it is not big enough.
[12:48:53] <iive> it's been years since i touched tcp, so I may be wrong.
[12:51:09] <KotH> well.. sofar i've only seen linux hosts support it correctly
[12:51:24] <KotH> windows seems to mess something up, hence never uses window scaling
[13:16:30] <mru> hmm, would it make sense to use a huge window, ack everything as received, then fill in any lost/damaged packets in a second pass?
[13:16:49] <Dark_Shikari> mru: dual-tree acking
[13:17:10] <Dark_Shikari> i.e. if you have 1024 packets, and you lost the 530th, 720th, and 721th
[13:17:23] <Dark_Shikari> You say "01" (first 512 are fine, second are not)
[13:17:33] <Dark_Shikari> then 10 (first 256 are fine, second 256 are not)
[13:17:34] <Dark_Shikari> etc
[13:17:44] <Dark_Shikari> er, I mean, first 256 are not fine, second 256 are
[13:17:44] <Dark_Shikari> etc
[13:40:57] <lu_zero> hi BBB
[14:51:51] <pengvado> Dark_Shikari: I'd call that binary tree. or do you see some connection to some other definition of dual tree?
[14:58:01] <Dark_Shikari> pengvado: dual tree as opposed to other trees.
[14:58:02] <Dark_Shikari> like, quad tree.
[14:58:07] <Dark_Shikari> but yeah, binary tree is dual tree.
[14:59:36] <pengvado> <derf> I just meant that neighboring blocks can only differ in block size by one level.
[14:59:44] <pengvado> so now there's a third definition of dual-tree?
[15:00:25] <pengvado> I thought "binary tree" is the 1D version of "quad tree", and "dual tree" isn't.
[15:00:58] <mru> "dual tree" sounds like something using two trees
[15:02:52] <iive> as I also already told, there is selective ack (sack) that would do it much better.
[15:02:53] <KotH> pengvado: in scientific lingo, you always have to check what definition the one talking is using :)
[15:03:17] <mru> if any
[15:20:30] <Dark_Shikari> pengvado: I was just following the generalization of "quad"
[15:20:38] <Dark_Shikari> binary -> quaternary
[15:20:39] <Dark_Shikari> dual -> quad
[15:53:41] <ohsix> Dark_Shikari: awful unsearchable name (i checked all the extensions in most categories looking for something like it :( ) https://addons.mozilla.org/en-US/firefox/addon/67651/
[16:05:25] <Dark_Shikari> LOL
[16:28:20] <mru> someone just reinvented bookmarks
[16:51:44] <_av500_> bookwhats?
[16:52:08] <mru> bookcookers
[18:23:45] <hemanthm> MSG saste hi
[18:25:41] <mru> monosodium glutamate?
[18:53:32] <lu_zero> hi
[18:54:56] <mru> hi
[18:56:10] <spaam> hi
[19:03:47] <_av500_> hi
[19:05:50] <cartman> you had me at ehlo
[19:07:38] <mru> anyone know how to run 32-bit icc 10.1 on a 64-bit system?
[19:08:37] <cartman> mru: Debian or Buntu?
[19:08:42] <mru> gentoo
[19:08:53] <cartman> you need some shit called ia32-libs afaik
[19:08:58] <mru> running the compiler is not the problem
[19:09:06] <mru> making it link to the 32-bit libs is
[19:09:28] <cartman> oh
[19:10:16] <mru> if all else fails, I can make an evil ld_preload wrapper to rewrite the filenames
[19:10:25] <mru> but I'd rather not do that
[19:10:50] <cartman> icc was piece of rpm crap back in time, still so I guess
[19:10:57] <mru> installing it is easy
[19:11:02] <mru> gentoo has ebuilds
[19:11:31] <cartman> right, I packaged icc myself back in time
[19:11:35] <cartman> for Pardus Linux
[19:11:41] <cartman> never tested 64bit mode sadly
[19:11:50] <mru> that seems to "work"
[19:32:48] <mru> tricked it
[19:32:54] <mru> shell wrapper around ld did it
[19:36:13] <cartman> :>
[19:37:01] <BBB> mru: will you add an icc 10.1 system to fate?
[19:37:08] <mru> 64-bit is already there
[19:37:14] <BBB> oh you already did
[19:37:16] <BBB> awesome :)
[19:37:23] <BBB> vc1 is broken :(
[19:37:26] <mru> yes
[19:37:36] <BBB> that can be fixed probably
[19:37:45] <mru> iirc it's a known icc bug
[19:37:54] <mru> one they're not going to fix
[19:38:02] <mru> well, have fixed in v11
[19:38:16] <BBB> oh ok, won't look at it then
[19:38:47] <cartman> http://fate.ffmpeg.org/x86_64-linux-icc-11.1 shows more failures
[19:38:50] <BBB> it might be useful to sort of mark certain bugs as "known bug, see this issue tracker entry" or "known bug, fixed in compiler version xyz"
[19:39:05] <BBB> cartman: go fix 'em!
[19:39:12] <cartman> BBB: I just did
[19:39:17] <cartman> I am using gcc/clang
[19:39:19] <cartman> there fixed it
[19:39:41] <BBB> I fixed those
[19:39:43] <BBB> you owe me
[19:39:49] <BBB> can you fix the failures on icc 11.1 on x86-64:
[19:39:49] <cartman> I am on 64bit ;)
[19:39:51] <cartman> sorry
[19:39:59] <cartman> you didn't fix anything for me :P
[19:40:06] <BBB> oh right, that's true
[19:40:13] <cartman> I still owe you somehow :P
[19:40:22] <cartman> win64 fixes make happy in some weirdo way
[19:40:32] <mru> btw if you add fate.ffmpeg.org/$slot/latest works
[19:40:51] <cartman> nice tip
[19:40:59] * cartman goes and runs fate
[19:41:08] * BBB is figuring out if he can speed up h264 more
[19:41:20] <BBB> it'd be nice somehow if michael reviewed my patches
[19:43:30] <mru> evil icc accepts the stack alignment flag but ignores it
[19:43:42] <cartman> LOL :>
[19:44:09] <cartman> #### FIXME: ignores alignment
[19:44:15] <cartman> or similar probably
[19:45:03] <mru> which makes testing for it actually working somewhat harder
[19:46:22] <Vitor1001> mru: Just by curiosity: are you adding a HAVE_ALIGNED_STACK define?
[19:48:07] <BBB> nooooooooooooooooooooooooo
[19:48:23] <BBB> just stop supporting shitty compilers
[19:49:06] <lu_zero> =P
[19:49:20] * lu_zero still wonders if ffcc would appear sooner or later
[19:51:35] <mru> Vitor1001: I was thinking along those lines
[19:54:47] <BBB> first ask on intel forums
[19:54:50] <BBB> maybe there's a different flag
[19:55:35] <mru> gah, I hate forums
[19:57:06] <kierank> mru: just think of them as a trolling ground
[20:01:58] <kierank> having said that intel forums people are quite helpful
[20:02:10] <mru> I still hate the medium
[20:03:40] <mru> argh, the -falign-stack option isn't even documented
[20:04:18] <BBB> therefore: ask ;)
[20:04:22] <BBB> don't add crazy configure hacks
[20:04:31] <BBB> I can ask if you don't want to
[20:04:36] <mru> please
[20:04:42] <mru> I don't do forums
[20:04:45] <mru> full stop
[20:05:57] <BBB> ok
[20:08:00] <cartman> mru: Google says -falign-stack=assume-16-byte and -falign-stack=maintain-16-byte exists as options
[20:08:09] <mru> now I found a document saying it's new in v11
[20:08:21] <cartman> yup seems so
[20:08:35] <mru> intel documentation is usually decent but impossible find
[20:11:02] * mru fails to find manual for icc 10.1
[20:15:48] <DonDiego> moin
[20:15:53] <mru> hi DonDiego
[20:16:15] <DonDiego> i have a report about an ffmpeg-related mplayer build failure on opensolaris:
[20:16:23] <DonDiego> libxvidff.c: In function `ff_tempfile':
[20:16:23] <DonDiego> libxvidff.c:101: error: `O_BINARY' undeclared (first use in this function)
[20:16:23] <DonDiego> libxvidff.c:101: error: (Each undeclared identifier is reported only once
[20:16:23] <DonDiego> libxvidff.c:101: error: for each function it appears in.)
[20:16:23] <DonDiego> gmake[1]: *** [libxvidff.o] Error 1
[20:16:43] <DonDiego> ffmpeg has a configure check for O_BINARY
[20:16:58] <DonDiego> ermm, no
[20:17:24] <DonDiego> in libavformat/file.c there is
[20:17:32] <DonDiego> #ifdef O_BINARY
[20:17:46] <mru> this machine doesn't have mkstemp?
[20:17:50] <DonDiego> but in libxvidff.c it is used without check
[20:18:12] <DonDiego> apparently no mkstemp, yes..
[20:18:20] <mru> mkstemp is standard
[20:18:25] <mru> broken system
[20:18:27] <mru> not supported
[20:18:52] <mru> besides, I doubt they really need libxvid
[20:30:09] * mru is getting bored of the macro troll
[20:30:23] <BBB> so stop responding
[20:30:34] <BBB> it's funny how people believe that they are right when they have the last word
[20:30:52] <mru> it's not about having the last word
[20:35:44] <funman> it's about him not having the last one O:-)
[20:39:48] <lu_zero> hi j0sh
[20:42:20] <lu_zero> mru: still your leaner AV_IF isn't bad
[20:42:28] <mru> of course it is
[20:42:33] <mru> I never suggested it be used
[20:42:39] <mru> is bad
[20:43:07] <mru> it's very fragile
[20:43:22] <lu_zero> agreed
[20:43:30] <mru> the condition has to be a single macro defined as 0 or 1
[20:43:47] <mru> which is kind of restrictive
[20:44:11] <lu_zero> still I'm wondering what that guy is trying to get
[20:44:17] <mru> beats me
[20:44:21] <lu_zero> beside self-pride points
[20:44:35] <mru> I'm seeing to it that he gets none of those either
[20:45:08] <lu_zero> putting boost in the mix wasn't smart
[20:48:07] <BBB> this was discussed before
[20:48:13] <BBB> deadcode elimination just is required
[20:48:32] <mru> that's too simple an explanation for the boost troll
[20:48:36] <BBB> he didn't ever touch upon things like "what to do about if (HAVE_MMX) dsputil_init_mmx(); if (HAVE_NEON) dsputil_init_neon();"
[20:48:48] <BBB> does he want to add #ifdefs there?
[20:49:34] <mru> he didn't have a solution, so he ignored the problem
[20:52:25] * lu_zero is wondering
[20:53:00] <BBB> I wonder a lot of things
[20:53:06] <BBB> like, how to make h264 decoding 50% faster
[20:53:14] <lu_zero> BBB: why 50%?
[20:53:18] <BBB> random number
[20:53:24] <mru> why stop at 50?
[20:53:29] <BBB> great question
[20:53:34] <BBB> I'll wonder about that once I reach 50
[20:53:42] <lu_zero> and why h264?
[20:53:47] <BBB> :D
[20:54:00] <BBB> I think vp8 is already plenty fast
[20:54:06] <BBB> ffmpeg is the fastest vp8 decoder by far
[20:54:19] <BBB> I don't think we're quite the fastest h264 decoder by far, although it's generally quite fast
[20:54:45] <mru> no, not by far
[20:54:45] <funman> BBB: if you only want the fastest h264 decoder, another option is making all the others slower
[20:55:06] <BBB> mru: which are faster?
[20:55:12] <BBB> I'd be interested in plugging in a few to compare
[20:55:22] <BBB> and then steal^dborrow their ideas
[20:55:30] <mru> I've tested corecodec and nero
[20:55:49] <funman> isn't there comparisons on doom9?
[20:56:06] <mru> not with my unreleased asm included :-)
[20:56:30] <BBB> you test arm
[20:56:33] <BBB> I want to test x86
[20:56:38] <BBB> because I can't fix arm yet :-p
[20:57:09] <lu_zero> BBB: do you want to play with arm as well?
[20:57:17] <BBB> sure why not
[20:57:21] <BBB> I'm still young, I can learn
[20:57:31] <BBB> once I'm old and alzheimerish I wish I'd done this ten years earlier
[20:57:50] <lu_zero> =)
[20:57:50] <funman> why learn at all?
[20:58:08] <funman> once you're old and alzheimerish you'll wish you had done that earlier anyway, regardless if you did it or not
[20:58:33] <funman> </crazy>
[20:58:50] <cartman> funman: thats a trap :P
[21:00:12] <BBB> and what if I don't become alzheimerish?
[21:00:53] <funman> ARM will be obsolete by then :p
[21:01:24] <lu_zero> pfff
[21:01:27] <mru> depends on how old he is
[21:01:35] <mru> has anyone met him?
[21:01:37] <cartman> go learn some ARM already
[21:01:43] <cartman> mru: he is young
[21:02:03] <funman> by his own standards, so what does this really mean?
[21:02:29] <funman> BBB: learn ARM, and join the rockboxers!
[21:02:43] <thresh> or red army
[21:02:46] <thresh> hi guys
[21:02:56] <funman> hi david
[21:04:01] <cartman> thresh: lo
[21:04:22] <cartman> thresh: [ot] do you know/remember damn.ru ?
[21:04:30] <mru> funman: rockboxers? http://neighbr.net/images/belarussian-special-forces-brick-smash.jpg
[21:04:35] <thresh> cartman: no, never been there
[21:04:39] <cartman> thresh: ok :/
[21:04:42] <thresh> I remember the days of fuckru.net though
[21:05:11] <cartman> thresh: was a very interesing reverse engineering team
[21:05:29] <BBB> mru: I'm 28
[21:05:32] <DonDiego> mru: how does ffh264 compare to corecodec and nero (rough idea, no exact numbers needed)
[21:05:39] <thresh> cartman: mmmm, DAMN?
[21:05:44] <cartman> thresh: yup
[21:06:02] <mru> DonDiego: I don't remember
[21:06:09] <mru> and it's a while since I measured
[21:06:12] <thresh> I vaguely remember the org name from like 2000s?
[21:06:20] <cartman> thresh: heh ok :(
[21:06:22] <cartman> thresh: :)
[21:06:35] <cartman> thresh: those were the time I wished I knew Russian
[21:06:45] <thresh> cartman: why do you need them?
[21:06:56] <cartman> thresh: no need, just wondering what happened to them
[21:06:59] <thresh> I think I have some connections to old scene guys...
[21:07:06] <DonDiego> mru: do you remember if they were faster or not?
[21:07:14] <mru> a lot faster
[21:07:18] <thresh> they probably got a decent jobs, credits, cars... life
[21:07:19] <cartman> thresh: their lead Ivanapulo was a interesting guy :)
[21:07:25] <BBB> mru: that was on arm right?
[21:07:27] <cartman> thresh: sure :(
[21:07:28] <cartman> :)
[21:07:28] <BBB> mru: or on x86?
[21:07:30] <mru> arm
[21:07:30] <BBB> mru: or both?
[21:07:34] <mru> x86 also
[21:07:37] <BBB> how does it compare on x86?
[21:07:37] <mru> at least corecodec
[21:07:38] <BBB> oh
[21:07:41] <BBB> hm...
[21:07:45] <mru> haven't tested nero on x86
[21:08:31] <BBB> mru: so when will you "fix" ffmpeg's h264 decoder? :-p
[21:08:44] <cartman> make corecodec slower :P
[21:08:48] <thresh> cartman: yeah I remember that Ivanopulo guy
[21:08:50] <BBB> I already made x86 1.25% faster and am working on more
[21:08:51] <mru> cartman: I could do that...
[21:08:55] <thresh> never met in life ofc
[21:09:21] <cartman> thresh: oh, neato :)
[21:09:57] <thresh> and i remember hanging out in dalnet in early 2000s
[21:09:59] <thresh> :(
[21:10:03] <cartman> lol ;)
[21:10:38] <thresh> somehow that was an IRC network of choice for russian sceners, I still wonder why
[21:10:40] <cartman> BBB: I think corecodec uses threads btw.
[21:10:52] <mru> cartman: it's faster in single thread
[21:10:54] <cartman> thresh: dunnow, I was there back in time
[21:11:04] <cartman> mru: you'll make it slower, we trust you
[21:11:39] <mru> cartman: if you pay me more than them...
[21:11:54] <cartman> mru: thats unpossible in all Simpsons sense
[21:14:49] <lu_zero> pff
[21:16:04] <j0sh> lu_zero: hi
[21:43:20] <j-b> mru: for your information, the Evil fruit company has approved it :)
[21:56:05] <spaam> j-b: what did they approve? :)
[21:56:28] <j-b> :)
[21:58:44] <thresh> sweet
[22:14:27] <mru> BBB: did you ask about alignment on the icc forums?
[22:15:12] <mru> ah, see it
[22:17:51] <lu_zero> j-b: uhm
[22:19:16] * lu_zero will force some people to try it
[22:22:12] <j-b> lu_zero: :)