[FFmpeg-devel-irc] IRC log for 2010-08-03

[irc at mansr.com]

[00:00:12] <DonDiego> the ogg demuxer depends on flagdec.o?
[00:00:19] <DonDiego> oh, the xiph horrors..
[00:01:01] <siretart> hi!
[00:01:05] <peloverde> chromium patches that locally
[00:01:07] <BBB> j0sh: other than that I think it's fine, as long as you've tripple-checked and you actually know for sure that it complies to the spec now ;)
[00:01:27] <BBB> what's flagdec?
[00:02:02] <mmu_man> lu_zero really, if I can port ALSA why not, but I'm too used to linux-only stuff to think it's easy
[00:02:16] <peloverde> flacdec i presume
[00:02:21] <mmu_man> just see what I had to patch on util-linux-ng to get it build on OSX
[00:02:31] <mmu_man> (and I just wanted sfdisk)
[00:02:46] <mmu_man> OSS4 still has some bugs on Haiku but it mostly works at least
[00:04:41] <lu_zero> mmu_man: it would be more interesting porting pulse IMHO
[00:05:33] <DonDiego> BBB: lol, i meant flaCdec.o ..
[00:05:55] <mmu_man> does it have drivers ?
[00:06:03] <mmu_man> I don't care about yet another API
[00:06:08] <lu_zero> ah
[00:06:10] <mmu_man> Haiku has its own native API
[00:06:20] <lu_zero> you was porting the backend not the frontend
[00:06:25] <mmu_man> actually soundcard.h is not public on Haiku
[00:06:36] <mmu_man> Haiku is not UNIX, it doesn't need the OSS API
[00:06:51] <mmu_man> though it can be used but since native drivers don't use the same...
[00:07:12] <lu_zero> mmu_man: you need pulse or anything else to provide a compat layer IMHO
[00:07:22] <mmu_man> maybe gstreamer or pulse wrappers to the Media Kit would be nice though
[00:07:49] <Dark_Shikari> ok, found the bug
[00:07:58] <Dark_Shikari> h264 decoding with threads is broken for at least streams with disable_deblock_idc == 2
[00:11:25] <mmu_man> hmm sndio
[00:11:48] <mmu_man> OpenBSD folks were too afraid to put OSS4 vmix in the kernel so they came up with their own stuff again :(
[00:16:24] <mmu_man> not like solaris didn't fork OSS4 though
[00:16:31] <mmu_man> (Boomer)
[00:16:42] <mmu_man> (which is stupid)
[00:19:55] <Honoome> mmu_man: wouldn't parted have worked more quickly than sfdisk, to port?
[00:22:29] <mmu_man> Honoome I used sfdisk in the Haiku arm port to generate the mmc image because it takes command on stdin
[00:22:41] <Honoome> ah that explains it
[00:22:46] <mmu_man> I used linux at that time so didn't bother on portability
[00:22:54] <mmu_man> (always the trouble on linux...)
[00:23:06] <Honoome> don't I know that..
[00:23:19] <Honoome> which reminds me I have yet to finish the build-sys rewrite
[00:23:29] <mmu_man> I tried porting parted to OSX too, but it needs other dependencies...
[00:23:56] <Honoome> hm? is it not in macports?
[00:24:19] <mmu_man> nope
[00:26:00] <CIA-92> ffmpeg: alexc * r24675 /trunk/libavcodec/vorbis_dec.c:
[00:26:00] <CIA-92> ffmpeg: vorbisdec: Prevent a potential integer overflow.
[00:26:00] <CIA-92> ffmpeg: If sizeof uint_fast8_t > 1 and sizeof size_t <= 4, the expression that mallocs
[00:26:00] <CIA-92> ffmpeg: classifs is susceptible to integer overflow.
[00:26:28] <Dark_Shikari> mru: thanks for posting your cavs patch
[00:26:31] <Dark_Shikari> now to get the other billion of them
[00:26:39] <mmu_man> Honoome hmm ah yes now I remember, I'm stuck on ./bootstrap for it on OSX...
[00:26:53] <mmu_man> had to hack in to use glibtoolize instead of libtoolize...
[00:27:03] <Honoome> aaaargh that stuff is obnoxious indeed
[00:27:07] <Honoome> hmm
[00:27:10] <mmu_man> and now it fails on some $(subst)
[00:27:23] <mmu_man> want the diff ?
[00:27:26] <Honoome> somebody remebers if there is a signal to send pid 1 to shutdown?
[00:27:48] <Honoome> mmu_man: nah, was just curious 'cause I've been floating around util-linux-ng myself for unrelated reasons lately
[00:27:49] <mmu_man> dunno, on which OS ? ;)
[00:28:44] <CIA-92> ffmpeg: alexc * r24676 /trunk/libavcodec/vorbis_dec.c:
[00:28:44] <CIA-92> ffmpeg: vorbisdec: Return AVERROR(ENOMEM) on malloc() failure.
[00:28:44] <CIA-92> ffmpeg: This is especially important because classifs can be very large.
[00:28:47] <Honoome> linux, possibly :P
[00:29:18] <mmu_man> I contributed genext2fs to macports the other day
[00:30:18] <mmu_man> now, what did parted complain about on Haiku...
[00:36:13] <j0sh> lu_zero: how about rtp for speex? http://tools.ietf.org/html/rfc5574
[00:40:08] <j0sh> basically like raw rtp, except with a few extra 1 bits at the end to maintain alignment
[00:40:40] <kierank> we should submit things to the ietf
[00:41:41] <mmu_man> write an RFC :)
[00:49:27] <mmu_man> ah yes, parted wants libuuid
[00:49:46] <Honoome> which is provided by... util-linux-ng
[00:50:07] <mmu_man> and on macport it doesn't get installed because it comes with e2fsprogs but macports wrongly install a separate libuuid which isn't compatible...
[00:50:26] <mmu_man> I reopened a ticket about it
[00:51:15] <mmu_screen> https://trac.macports.org/ticket/16271
[00:52:58] <Dark_Shikari> ffffffffffffffff
[00:53:04] <Dark_Shikari> autoconf scripts on windows
[00:53:12] <Dark_Shikari> 1.5 seconds per "checking for double..."
[00:54:13] <Honoome> windows hid it and it had to search _very_ very carefully
[00:54:23] <mmu_man> autoconf on *anything* :p
[00:54:25] <Dark_Shikari> more like "fork takes 1.5 seconds"
[00:55:02] <Honoome> oh yeah.. I forgot how long it takes to fork on windows
[00:55:09] <mmu_man> well it's a hack on win32
[00:55:10] <Honoome> for windows to fuck (up) instead you have to wait near to nothing
[00:56:12] <mmu_man> then there are all the people that do not use autoconf correctly (if it's at all possible)
[00:56:30] <mmu_man> like doing stupid checks but forgetting simple checks for like, libm ;)
[00:56:59] <Honoome> mmu_man: checks should really be minimal and you should run tests only when they actually matter
[00:57:32] <Honoome> given that most people, with all due respect, won't give a damn about haiku, I'd rather they don't test for libm rather than run 1024 tests because autoscan said so
[00:58:32] <mmu_man> thanks for not caring about others...
[00:59:52] <Honoome> mmu_man: you got the wrong person to be ironic about that with...
[01:00:02] <Honoome> the problem is that autoscan is utter crap
[01:00:11] <mmu_man> never tried that
[01:00:23] <mmu_man> still you don't need autofools for that
[01:00:30] <mmu_man> you need a lib ? check for ti
[01:00:34] <mmu_man> simple
[01:00:41] <Honoome> no...
[01:00:49] <Honoome> because then you had tons of checks that have _no_ value
[01:01:02] <mmu_man> or make a case on $os
[01:01:05] <Honoome> "you need a lib? check for it _if there is case to need for it_"
[01:01:06] <Honoome> even worse
[01:01:16] <mmu_man> well they have a value, that is portability
[01:01:19] <mmu_man> anyway
[01:01:32] <Honoome> ... not really, if you don't have a case for them, they have no value
[01:01:35] <mmu_man> at least don't hardcode it 30 times in the makefiles
[01:01:42] <mmu_man> I tell you it's painful to fix
[01:01:53] <Honoome> if you have nobody to support haiku, just adding a test for it won't help you the slightest.
[01:02:11] * mmu_man raises hand
[01:02:57] <mmu_man> usually command line things build quite well on Haiku
[01:03:03] <mmu_man> appart things like -libm actually
[01:03:21] <mmu_man> or hacks like #!/usr/bin/env python
[01:03:50] <mmu_man> because people think env is there everytime and will help them find python... ironically :)
[01:04:07] <Honoome> that's unix standard I think
[01:04:20] <mmu_man> Haiku is not UNIX
[01:04:44] <Honoome> well that shebang is following unix
[01:04:55] <Honoome> as I said you cannot pretend that everybody feels like supporting haiku just for the sake of it
[01:05:12] <mmu_man> it's not the point
[01:05:41] <mmu_man> even on UNIX sometimes things do'nt work
[01:05:47] <mmu_man> usually stuff comming from Linux
[01:05:58] <mmu_man> because they don't care about others
[01:06:16] <mmu_man> so it's just about portability
[01:06:19] <mmu_man> anyway
[01:06:20] <Honoome> by personal experience the problem is not "they don't care about others" but rather "they have no idea how to support others out of the blue"
[01:06:23] <mmu_man> hmm 3am...
[01:06:42] <Honoome> portability does not mean making EVERYTHING conditional because "you never know if there is an operating system not supporting that"
[01:06:50] <Honoome> that's just silly voodoo programming
[01:06:53] <mmu_man> well usually things get much more portable when you follow standards
[01:07:07] <Honoome> sure.. you just complained about /usr/bin/env which _is_ standard
[01:07:18] <mmu_man> it's not in POSIX AFAIK
[01:07:28] <mmu_man> nor is libm
[01:07:56] <mmu_man> I don't ask everyone to know socket() is in libnetwork on Haiku
[01:08:38] <mmu_man> I just expect them to at least not hardcode -lc and have checks at one point where it's simpler to change an AC_CHECK_LIBS() than fix Makefiles at 20 places
[01:08:59] <Honoome> see, you don't know autotools there I guess
[01:09:04] <Honoome> AC_CHECK_LIBS is not what you're looking for anyway
[01:09:11] <Honoome> it's AC_SEARCH_LIBS instead
[01:09:18] <mmu_man> whichever
[01:09:27] <mmu_man> it's 3 am :p
[01:09:32] <Honoome> there is a lot of difference
[01:09:35] <Honoome> one is voodoo programming
[01:09:42] <Honoome> the other is actually writing proper code
[01:10:18] <mmu_man> it's just about making provisions so others don't have to read the whole code just to fix a lib
[01:10:42] <Honoome> "making provisions" can't be done by making every bloody function optional...
[01:11:53] <mmu_man> no, but using standard ones first, having a clean design usually helps a lot
[01:12:07] <mmu_man> anyway
[01:12:43] <mmu_man> yeah AC_CHECK_LIB sux, parted just complains about libdl missing on Haiku while dlopen() is actually in libroot already
[01:12:45] <Honoome> you can't pretend a linux-aimed project to stick to POSIX when they are implementing _linux_ utils...
[01:13:08] <Honoome> the dlopen stuff is the same on FreeBSD, correct macro is AC_SEARCH_LIBS([dlopen], [dl dld])
[01:13:31] <Honoome> it will stop right away wherever no lib is needed, it'll proceed to check the two in series until it finds it
[01:14:18] <mmu_man> well that's not a portability issue it's a project decision issue, linux-specific tools along with partition tools and other generic things that should go to coreutils
[01:14:45] <Honoome> heh... coreutils... gnulib is one of the worst voodoo programming pieces of shit I ever saw in a long time
[01:14:53] <mmu_man> +1
[01:18:33] <mmu_man> seems AC_SEARCH_LIBS is newer, I rarely see it used
[01:19:09] <mmu_man> instead lots of recursive AC_CHECK_LIB() with ugly shell code
[01:19:25] <Honoome> no it's more like it's not documented anywhere, including the new book by nostarch afaics, because people trust autoscan instead
[01:19:57] <Honoome> which reminds me I should write about it on autotools mythbuster when I have time
[01:20:25] <mmu_man> well autofools is not the most appealing thing so usually ppl just copy from (bad) stuff
[01:20:45] <Honoome> which is why I insist on proper portability and build systems
[01:20:49] <Dark_Shikari> mru: ping
[01:20:58] <Honoome> and I can write (and teach to write) sanish autotools
[01:23:01] <mmu_screen> well feel free to survey http://ports.haiku-files.org/wiki/PortingTips for mistakes
[01:23:32] <mmu_screen> and http://ports.haiku-files.org/wiki/CommonProblems
[03:17:16] <saintdev> hmm, KMFDM-Dogma is interesting
[03:26:19] <saintdev> tbh, i can't really tell who is correct here.
[03:37:29] <saintdev> peloverde: this is interesting. itunes inserts a 1 block delay, i thought this was just padding at first.
[03:38:14] <saintdev> however on dogma, it allows them to catch an attack in the very first frame by switching on silence
[03:44:26] <peloverde> we also insert a one block delay
[03:44:45] <saintdev> well itunes actually inserts it in their bitstream
[03:45:55] <peloverde> We have a one block delay in the bitstream, do they have a two block delay?
[03:46:25] <peloverde> if you want to add another block that's fine, I don
[03:46:44] <peloverde> 't really think boundary conditions are the most important thing at the moment
[03:47:19] <saintdev> i guess, if we already do one block. that means nero does 3 o.O
[03:47:55] <saintdev> fair enough, just thought it was curious that they actually make use of their delay for something like that.
[03:48:37] <peloverde> Yeah, it's the only way to use block switching to help attacks before sample 512
[03:50:16] <peloverde> It's something that probably should be done eventually but right away it's probably more of a burden
[05:18:56] <thresh> moroning
[06:18:58] <saintdev> peloverde: what do you think is a sensible range of quality? 0-10 sound good?
[06:19:13] <peloverde> I have no idea
[06:24:15] <saintdev> peloverde: imo, 0-10 or 0-100 would be a good idea. much better than what it is currently (lambda = -aq * FF_QP2LAMBDA)
[06:24:32] <saintdev> that's not negative, that is the -aq switch
[07:00:57] <funman> morgen
[07:01:13] <kshishkov> god morgon
[07:01:52] <mru> moronings
[07:02:09] <benoit-> moin
[07:02:17] <av500> dobro jutro
[07:02:18] <kshishkov> funman, any new codecs? E.g. for Playmobil?
[07:02:29] <av500> Fischer Technik!
[07:02:51] <funman> no :p
[07:03:02] <kshishkov> fixedpoint WMA decoding?
[07:03:06] <funman> i still have to send the lego adpcm patch, found no tester
[07:03:48] <kshishkov> buy some for yourself :)
[07:04:36] <funman> yeah i considered it but they are quite expensive, and i doubt i'd have as much fun as i had when i was a kid
[07:05:07] <funman> mt: ping
[07:05:10] * kshishkov looks at nickname
[07:05:27] <funman> kshishkov: exactly, not 'funkid' anymore
[07:05:54] <av500> funman: I will take it after you are done testing
[07:07:11] <funman> http://shop.lego.com/Product/?p=8547  €299 :/
[07:09:59] <kshishkov> no problem for me (as I'm not the one who's going to buy it)
[07:11:51] <mru> Dark_Shikari: pong
[07:17:20] <benoit-> funman: USD 279.99
[07:23:11] <Dark_Shikari> mru: I've noticed some functions aren't getting inlined in vp8 that really should be
[07:23:19] <Dark_Shikari> possibly because gcc is hitting its stupid inlining caps
[07:23:21] <Dark_Shikari> for example...
[07:23:22] <Dark_Shikari> av_clip
[07:23:31] <mru> oh dear
[07:23:38] <mru> what about always_inline?
[07:23:47] <Dark_Shikari> Do you want to make all of the av_clips always_inline?
[07:23:49] <Dark_Shikari> those are in avutil.
[07:23:57] <Dark_Shikari> arch-specific, too.
[07:23:58] <mru> I think that's a good idea
[07:24:07] <Dark_Shikari> How about do that to every single thing in avutil that's a one-liner or near so?
[07:24:08] <mru> tiny functions like those should always be inlined
[07:24:21] <mru> a lot of things already are
[07:24:21] <Dark_Shikari> I'm not going to bikeshed myself into that, I think you should do that.
[07:24:28] <Dark_Shikari> You're more experienced with avutil math functions than I am anwyays.
[07:24:51] <mru> remind me tonight (europe time)
[07:24:54] <Dark_Shikari> k
[07:25:02] <Dark_Shikari> the other question is about the cabac functions
[07:25:06] <Dark_Shikari> there are two variants
[07:25:08] <Dark_Shikari> branchy, and non-branchy
[07:25:11] <Dark_Shikari> branchy is always-inlined
[07:25:17] <Dark_Shikari> non-brahcy is just inline -- and gcc doesn't inline it ever
[07:25:25] <mru> seems wrong
[07:25:26] <Dark_Shikari> because it's hit the inline limit
[07:25:32] <Dark_Shikari> always_inline is the right thing to do...
[07:25:39] <Dark_Shikari> but I don't want to force it
[07:25:45] <mru> the branchy one won't hurt from another branch to reach it
[07:25:54] <Dark_Shikari> as unlike in the avutil case, there may be a sane reason to not inline it
[07:26:02] <mru> how big is it?
[07:26:07] <mru> is this the x86 asm one?
[07:26:13] <astrange> branchy inlining might remove a compare+branch against the result of the function
[07:26:13] <Dark_Shikari> no, there's no asm version, it's C
[07:26:19] <saintdev> ugh, constant quality needs work :/
[07:26:25] <Dark_Shikari> it's not called as much as cabac in h264
[07:26:35] <Dark_Shikari> but I mean, for enable small, I'd want it not inlined
[07:26:47] <astrange> doesn't enable small undefine always_inline?
[07:26:56] <Dark_Shikari> oh, it does?
[07:27:18] <mru> it does but that's wrong imo
[07:27:26] <mru> we need a new qualifier
[07:27:40] <mru> for always inline if not small
[07:27:51] <astrange> i don't think we have any really_always_inline functions that need it to compile properly
[07:28:04] <Dark_Shikari> yeah but we have things like the ones in avutil
[07:28:05] <mru> astrange: Dark_Shikari says av_clip etc do
[07:28:06] <Dark_Shikari> one-liners
[07:28:08] <Dark_Shikari> one-instructioners
[07:28:18] <astrange> those are purely compiler bugs
[07:28:18] <Dark_Shikari> mru: only if other stuff in vp8 has forced us to hit the inline limit
[07:28:24] <mru> things that are _bigger_ if not inlined
[07:28:36] <mru> yeah, but still
[07:28:44] <mru> oneliners should be force-inlined
[07:28:49] <astrange> there shouldn't be a limit for inlining of functions that are smaller than call overhead
[07:28:54] <saintdev> no_i_really_i_do_want_this_inlined_seriously
[07:29:00] <Dark_Shikari> astrange: well, I'm only using gcc 4.3
[07:29:02] <astrange> of course this all depends on compiler version and i can't remember what they do here
[07:29:03] <Dark_Shikari> was this fixed any time recently?
[07:29:03] <mru> astrange: tell that to gcc devs
[07:29:22] <mru> the simple solution is to always_inline them
[07:30:27] <Dark_Shikari> can you try compiling ffmpeg with a newer gcc and see if av_clip is inlined or not in vp8.o?
[07:30:40] <Dark_Shikari> the rac is still an issue as well
[07:31:19] <astrange> checking...i don't have 4.5 though, and that would be useful
[07:31:34] <astrange> (we can get them to backport inlining fixes if there's something wrong there)
[07:36:57] <Dark_Shikari> btw, in just about 5 minutes I stripped >300KB off dsputil
[07:37:01] <Dark_Shikari> without breaking h264 decoding
[07:37:13] <Dark_Shikari> (or slowing it down)
[07:38:45] <astrange> http://trac.perian.org/browser/trunk/Patches/0004-Hardcode-results-of-runtime-cpu-detection-in-dsputil.patch well, this slows it down on other cpus
[07:39:49] <mru> astrange: you know that's not going anywhere near svn
[07:40:17] <Dark_Shikari> lol
[07:40:31] <Dark_Shikari> I didn't even do that, I just removed everything not used by h264
[07:41:14] <astrange> yeah
[07:41:34] <Dark_Shikari> Just removed the function pointer assignments
[07:41:43] <Dark_Shikari> gcc optimizes out the static functions
[07:41:57] <astrange> but changing --enable-runtimecpudetection so that disabling it hardcodes the value of mm_support would be interesting for some people
[07:42:08] <Dark_Shikari> why is mm_support a global anyways?
[07:42:21] <mru> Dark_Shikari: it is referenced in emms()
[07:42:40] <mru> which I tried to get removed
[07:43:00] <mru> the discussion is somewhere at the back of a bikeshed
[07:43:10] <astrange> http://pastebin.com/f2zBidPq
[07:43:36] <KotH> hoi zäme
[07:43:50] <kshishkov> шо?
[07:43:51] <Dark_Shikari> astrange: holy crap, it inlines all the noncritical header-reading stuff too
[07:43:58] <Dark_Shikari> er, the vp8_get_sint stuff
[07:45:15] <astrange> there's some new stuff for larger functions (partial inlining, cloning of functions called with constant parameters) but none of that showed up here
[07:45:26] <Dark_Shikari> er yeah, we really shouldn't inline those.
[07:48:28] <Dark_Shikari> any objections to
[07:48:29] <Dark_Shikari> http://pastebin.org/444366
[07:48:29] <Dark_Shikari> ?
[07:48:38] <Dark_Shikari> remove inlining from header functions
[07:48:42] <Dark_Shikari> add always_inline to rac functions
[07:59:48] <Dark_Shikari> ?
[08:02:04] <astrange> fine with me
[08:02:14] <astrange> not that i've read the uses of that header
[08:02:47] <Dark_Shikari> wondering if the always inline is bad at all
[08:07:04] <CIA-92> ffmpeg: darkshikari * r24677 /trunk/libavcodec/vp56.h:
[08:07:04] <CIA-92> ffmpeg: VP5/6/8: tweak some arithcoder inlining
[08:07:04] <CIA-92> ffmpeg: Always inline the arithmetic coder, except in the case of header-parsing stuff,
[08:07:04] <CIA-92> ffmpeg: in which case don't inline it at all to save code size.
[08:55:31] <saintdev> omg, i just realized some of the offsets for the fir were completely wrong
[08:55:42] <saintdev> wow, surprised this worked
[09:03:07] <CIA-92> ffmpeg: stefano * r24678 /trunk/libavfilter/avfilter.h: Make avfilter_copy_picref_props() copy w and h from src to dst.
[09:03:47] <mru> saste: http://fate.ffmpeg.org/report.cgi?slot=x86_32-linux-gcc-valgrind&time=20100802095026
[09:04:11] <saintdev> goodie, now i get to reverify all my samples
[09:06:12] <lu_zero> yawn
[09:10:54] <saste> mru: OK now I see there are problems in lavfi-shofiltfmts
[09:11:22] <saste> mru: do you have an idea about why only valgrind is showing that?
[09:11:40] <mru> because only valgrind is checking that
[09:11:48] <mru> I didn't look at it carefully
[09:12:20] <saste> I'll look at that this evening... quite busy right now
[09:12:35] <mru> ok
[09:12:44] <saste> btw the new fate is great :)
[09:12:52] <mru> thanks
[09:13:10] <kshishkov> and not written in Python!
[09:16:11] <lu_zero> kshishkov: bad troll =P
[09:16:24] <lu_zero> "and written in bash!"
[09:16:26] <mru> this comes to mind: http://www.thinkgeek.com/tshirts-apparel/unisex/frustrations/374d/
[09:16:34] <lu_zero> that would be the nice statement =P
[09:16:36] <mru> lu_zero: it's not bash, it's posix shell
[09:16:44] <lu_zero> even better =)
[09:17:03] <mru> all the actual work is done in shell scripts
[09:17:11] <mru> the web view is all perl
[09:17:27] <lu_zero> if I have time I'll prepare an alternate front-end in python just to make kshishkov happier =)
[09:17:43] <mru> over my dead server
[09:18:18] <lu_zero> mru: who cares about your server (may it remain alive and well)
[09:19:14] <mru> lu_zero: well, I care a bit
[09:19:57] * KotH blames DonDiego 
[09:20:10] <DonDiego> how convenient :)
[09:20:36] <lu_zero> jokes aside
[09:20:48] <lu_zero> I'll try to add few bits to the current one
[09:20:54] <mru> like what?
[09:20:59] <saintdev> cool, it didn't affect castanets. seems to have fixed the remaining issues in fatboy
[09:22:14] <KotH> DonDiego: ofc, i cannot always blame spaam for everything :)
[09:25:22] <spaam> KotH: so you blame DonDiego for the other thing that you cant blame me for ? :P
[09:26:33] <KotH> spaam: there is nothing i cannot blame you for... though i just felt like blaming DonDiego for once
[09:28:01] <lu_zero> error highlighting/location on logs
[09:36:05] <saintdev> peloverde, kshishkov: requesting pre-review before i send this to the ML http://pastebin.org/444666
[09:38:18] <merbzt> saintdev: just for block switching descisions ?
[09:38:27] <saintdev> merbzt: so far, yes
[09:38:51] <saintdev> peloverde wanted me to submit smaller patches
[09:40:03] <merbzt> saintdev: compared to other encoders is it matching ?
[09:40:33] <kshishkov> saintdev: okay, looking at it
[09:40:42] <merbzt> the descisions that is
[09:40:48] <saintdev> merbzt: it comes very close to itunes
[09:41:20] <kshishkov> hmm, Lame channel in 3gpp channel - it's, err, lame
[09:41:22] <saintdev> merbzt: it has a few more false-positives, but in general also switches out of short sequences sooner
[09:41:51] <saintdev> *switches out sooner when it should
[09:42:23] <saintdev> comes close to nero, but nero also makes a few horrible decisions
[09:42:30] <lu_zero> mru: beside that it's already really nifty =)
[09:43:17] <lu_zero> with the switch with git would be nice having the link-back to the commit and broken file
[09:43:46] <lu_zero> but those are just nice to have but not really _that_ important
[09:43:50] <saintdev> in general it is _much_ _much_ better than the current 3gpp  window switching
[09:43:54] <merbzt> saintdev: ok, well I think that false positives are less bad then false negatives
[09:44:06] <saintdev> both are bad
[09:44:10] <mru> lu_zero: all good ideas
[09:44:20] <saintdev> false positives burn bits
[09:44:22] <mru> though I'd like to avoid it sprawling out too quickly
[09:44:32] <saintdev> false negatives hurt quality
[09:45:00] <saintdev> although you should see how well nero does when it completely misjudges an attack
[09:45:03] <mru> I want to be reasonably sure the overall architecture is stable before going mad with features
[09:45:04] <saintdev> all because it has TNS
[09:45:46] <merbzt> saintdev: true true
[09:46:10] <kshishkov> saintdev: on the first glance it's OK, nice and clean - except shoving one channel struct into another
[09:46:15] <merbzt> mru:  where is my warning counter ????
[09:46:21] <saintdev> kshishkov: yeah i know about that. really i wanted to keep them separate
[09:46:27] <mru> merbzt: not implemented yet
[09:46:35] <DonDiego> saintdev: indentation is off on lines 203/204 and some of those lines could be shorter
[09:46:53] <saintdev> as now i have to modify lame windowing just to get it to work with the lame psymodel :/
[09:47:28] <saintdev> DonDiego: thanks
[09:48:26] <kshishkov> mru: and where's Diegos Doxygen warning counter?
[09:48:40] <mru> DoxDiego?
[09:49:13] <av500> DonDoxie?
[09:49:29] <av500> DocDoxy
[09:49:36] <mru> DonDioxo
[09:49:37] <merbzt> saintdev: is the quality improvment audible ?
[09:49:54] <saintdev> at low bitrates, more than likely
[09:50:00] <kshishkov> mru: those of Spanish origin can have a lot of names
[09:50:21] <Kovensky> and where's Diego's aspell filter on comments and commits
[09:50:31] <Kovensky> altough the commits part wouldn't really be useful for fate
[09:50:45] * kshishkov tries to remember first words in the name of Buenos Aires
[09:52:00] <saintdev> merbzt: i haven't done any listening tests, other than listening the output isn't b0rked
[09:52:20] <saintdev> also, if you do test, stereo _is_ b0rked
[09:52:39] <saintdev> not because of the psymodel, it's broken with 3gpp also
[09:53:23] <kshishkov> so you're implying I've implemented it right?
[09:53:31] <saintdev> no
[09:54:00] <kshishkov> fin
[09:54:02] <kshishkov> *fine
[09:55:20] <saintdev> there's a bug somewhere, but i haven't looked yet
[09:56:05] <kshishkov> probably energy reallocation for joint stereo
[09:56:32] <saintdev> well when you switch on stereo you get MASSIVE post-echo in castanets
[09:56:38] <saintdev> that's all the more i know so far ;)
[09:57:44] * elenril blames kshishkov 
[09:58:55] * kshishkov blames himself and elenril for not helping
[09:59:19] <elenril> me? i don't know a thing about codecs
[09:59:29] <Dark_Shikari> learn
[09:59:38] <elenril> :effort:
[09:59:43] <Dark_Shikari> yes.  put some in
[09:59:49] <funman> the trick is nobody knows a thing. everyone fakes
[09:59:50] <elenril> and no real motivation, they workforme
[09:59:59] <Dark_Shikari> and what funman said
[10:00:10] <saintdev> fakes, i admit i don't know anything
[10:00:13] <funman> it's easy, really
[10:00:32] <funman> "i have moved the qpel coeff into the DCT params and it's 2 cycles faster"
[10:00:55] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/Technobabble
[10:00:57] * funman could throw 1 or 2 more acronyms in this
[10:02:17] <Kovensky> are they TLA?
[10:02:24] <kshishkov> funman: that works better with non-tech people, see some XKCD strip
[10:02:29] <Honoome> there are a few FLA as well
[10:02:38] <Dark_Shikari> kshishkov: see BOFH
[10:02:51] <Dark_Shikari> BOFH did it years before xkcd's author got weened
[10:02:58] <funman> kshishkov: works perfectly with non-codec-tech people
[10:03:18] <Kovensky> the BOFH should be made part of the jargon file
[10:03:33] <kshishkov> Dark_Shikari: *dummy mode on*
[10:03:49] <DonDiego> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-August/065663.html
[10:03:57] <Dark_Shikari> kshishkov: well, you see, solar flares can cause interference in your floppy drive.
[10:03:58] * DonDiego stares in disbelief
[10:04:07] <DonDiego> an openbsd guy who wants to fix nm...
[10:04:07] <Dark_Shikari> you need to periodically demagnitize it.
[10:04:37] <Honoome> DonDiego: he's probably not an obsd guy enough :P
[10:04:37] <kshishkov> Dark_Shikari: I've turned dummy mode on already.
[10:05:22] <kshishkov> Honoome: yes, he'd rather fork MPlayer for BSD then
[10:05:38] <Dark_Shikari> and by fork, you mean rewrite a horribly inferior version
[10:05:42] <Dark_Shikari> that only plays DV files
[10:05:52] <Dark_Shikari> remember, mplayer is GPL!
[10:05:53] <Dark_Shikari> can't have that.
[10:06:02] <KotH> DonDiego: they exsist... i've heart about sighting for years... nearly as often as sighting of a yeti ;-)
[10:09:34] <kshishkov> Dark_Shikari: first thing for BST is to drop half of options and rename the rest
[10:09:54] <Dark_Shikari> and declare all the dropped ones to be "GNUisms"
[10:10:00] <Dark_Shikari> regardless of whether they originated in GNU software or not
[10:12:45] <kshishkov> well, I think that The Year of BSD on Desktop will come shortly (in few aeons) after Linux one
[10:13:25] <Honoome> just the year before The Year of Gentoo QA
[10:13:30] * Honoome is in a sour mood
[10:14:07] * kshishkov remebers a story when Gentoo issued ebuild for kernel with IDE (or SATA) disabled by default
[10:14:36] <funman> optimization: IDE is slow anyway
[10:14:42] <Honoome> kshishkov: then you probably remember wrong
[10:14:54] <Honoome> given that we only have ebuilds for kernel _sources_
[10:14:59] <DonDiego> please don't be unjust - the bsds never made any desktop claims whatsoever
[10:15:17] <Honoome> DonDiego: pc-bsd has
[10:15:21] <Dark_Shikari> DonDiego: there are enough BSDs that at least one has
[10:15:27] <saintdev> pclinuxos?
[10:15:34] <saintdev> erm
[10:15:45] <saintdev> a little tired to think strait
[10:15:46] <Honoome> otoh there is nothing I can think of worse than debian gnu/kfreebsd
[10:15:56] <Kovensky> PC-BSD
[10:15:59] <Honoome> [and before somebody says anything, no it has _nothing_ in common with gentoo/freebsd]
[10:15:59] <saintdev> off2bed
[10:16:34] <Dark_Shikari> kfreebsd?
[10:16:36] <kshishkov> Honoome: yes, but I remember the outcome - guy updates Gentoo and PC stops working because something essential was turned off by default
[10:16:38] <Dark_Shikari> is that like kubuntu vs ubuntu?
[10:17:02] <Honoome> Dark_Shikari: no, it means freebsd kernel.. with glibc and GNU userland
[10:17:13] <Kovensky> wny don't they call the other one gnu/klinux
[10:17:15] <Dark_Shikari> Where's the k come from?
[10:17:22] <saintdev> KDE
[10:17:27] <Dark_Shikari> Klinux?  Kli-nux
[10:17:31] <Honoome> [where the main reason one could prefer freebsd to gnu/linux is that you have a tight kernel/libc integration, blah]
[10:17:38] <saintdev> oh once again lack of sleep strikes
[10:17:42] <Dark_Shikari> stop saying gnu/linux
[10:17:49] <Dark_Shikari> or I will have to paste the stallman copypasta
[10:17:59] <Kovensky> no, debian *insists* that you must say gnu/linux
[10:18:00] <Honoome> Dark_Shikari: I'm actually using it proper there
[10:18:12] <Honoome> as I'm actually despising glibc
[10:18:13] <Dark_Shikari> I would just like to interject for a moment.
[10:18:13] <Dark_Shikari> What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux.
[10:18:16] <Dark_Shikari> Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
[10:18:21] <Dark_Shikari> Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
[10:18:26] <Dark_Shikari> There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run.
[10:18:29] <Honoome> and I don't want uclibc taken into the shitstorm
[10:18:31] <Dark_Shikari> The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux.
[10:18:35] * Honoome kicks Dark_Shikari
[10:18:36] <Dark_Shikari> </Stallman>
[10:18:38] <Dark_Shikari> All the so-called "Linux" distributions are really distributions of GNU/Linux.
[10:18:49] <Dark_Shikari> Now stop saying GNU/Linux.  It annoys Stallman when we don't do it.
[10:18:58] * kshishkov looks at Linux + BusyBox and thinks what finger to show to Stallman
[10:19:26] <Honoome> kshishkov: that happens with _any_ distro... on the other hand, last night I saved half the gentoo users from un-updatable systems ... that wasn't funny at all, given that it was one single developer's fault
[10:19:32] <Honoome> and not for the first time
[10:19:56] <Honoome> Dark_Shikari: if _I_ write gnu/linux is because I'm referring to the glibc-based flavour; if I'm referring to _any_ flavour (and nowadays we got at least three), I use Linu
[10:19:57] <Honoome> +x
[10:20:18] <Dark_Shikari> since when does the libc determine that much about the system?
[10:20:35] <Honoome> Gentoo is officially Gentoo _Linux_ because we very well support using uclibc (and can call ourself off stallman's pretenses)
[10:20:36] * kshishkov looks at ARM distros
[10:20:50] * Kovensky points at freebsd's libc and its outstanding C99 support
[10:20:52] <Honoome> Dark_Shikari: since it actually changes a lot between the two
[10:21:22] <kshishkov> Kovensky: yes, since we have to reimplement half of standard functions, it's outstanding indeed
[10:21:29] <Dark_Shikari> Kovensky: freebsd is the Microsoft of *nix OSs
[10:21:32] <Dark_Shikari> "standards?  what standards?"
[10:21:52] <funman> kshishkov: http://www.gnu.org/gnu/gnu-linux-faq.html#justlinux
[10:21:56] <Kovensky> they're standards-dree
[10:22:00] <Kovensky> s/d/f
[10:22:39] <DonDiego> kshishkov: busybox is just a bunch of small tools, you can start showing a finger when you have replaced glibc, not before
[10:22:52] <Kovensky> I remember seeing patches for the C99 log functions over 5 years old, never got merged and the thread just died
[10:23:30] <Kovensky> the major benefit of not using glibc is you don't have to deal with drepper
[10:23:39] <Kovensky> +that
[10:23:54] * funman used glibc for years, never had any problem with drepper
[10:24:37] <Honoome> DonDiego: uclibc and whatever android uses
[10:24:41] <Kovensky> you don't as an user, you do as a maintainer though :P
[10:24:53] <Kovensky> well, you do as an user too, but only very rarely
[10:25:13] <funman> Honoome: android use bionic libc
[10:25:19] <CIA-92> ffmpeg: darkshikari * r24679 /trunk/libavcodec/ (vp8data.h vp8.c):
[10:25:19] <CIA-92> ffmpeg: VP8: unroll MB mode decoding tree
[10:25:19] <CIA-92> ffmpeg: ~50% faster MB mode decoding, plus eliminate a costly switch.
[10:25:25] <Honoome> DonDiego: what funman said :P
[10:25:43] <Kovensky> Dark_Shikari: you must now do barrel rolls to compensate for the unrolling
[10:25:54] * Dark_Shikari presses Z twice
[10:25:55] <Honoome> you played too much ... wipeout?
[10:26:30] <Kovensky> there are barrel rolls in wipeout? o_O
[10:26:42] <Honoome> hd yeah
[10:27:01] <Dark_Shikari> starfox
[10:33:49] <lu_zero> btw
[10:34:02] <lu_zero> anybody tried the bionic libc w/out android?
[10:35:36] <lu_zero> "The Bionic libc routines do not handle C++ exceptions."
[10:35:38] <lu_zero> oh
[10:37:19] <av500> why oh?
[10:37:35] <av500> it looks like a sane concept to me
[10:38:04] <CIA-92> ffmpeg: darkshikari * r24680 /trunk/libavcodec/ (vp8data.h vp8.c):
[10:38:05] <CIA-92> ffmpeg: VP8: unroll splitmv decoding tree
[10:38:05] <CIA-92> ffmpeg: Much faster splitmv mode decoding.
[10:38:36] <funman> lu_zero: afaik, bionic deviates from posix in a few places
[10:39:03] <funman> (in pthread_something)
[10:40:31] <funman> http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html -> or perhaps it's only some stuff non implemented and what's implemented is done correctly
[10:41:54] <av500> "...uClibC is considerably smaller it is encumbered by the LGPL.."
[10:41:58] <av500> encumbered?
[10:43:58] <lu_zero> there is something really strange in that article
[10:44:33] <kshishkov> av500: if you use it you must acknowledge that and give source code :P
[10:44:44] <Dark_Shikari> "encumbered by the LGPL"
[10:44:48] <Dark_Shikari> OH NO I CANT STEAL IT
[10:44:51] <Dark_Shikari> AND NOT GIVE CREDIT
[10:44:57] <Dark_Shikari> WHAT WILL I EVER DO
[10:45:00] <av500> kshishkov: I know what I have to do
[10:45:31] <av500> i just wonder why a hw maker that has to ship a GPL kernel would have an issue with a LGPL libc
[10:45:57] <Honoome> since when hw makers ship gpl kernel modules?
[10:46:07] <Dark_Shikari> It's Linux.
[10:46:09] <Dark_Shikari> It's GPL.
[10:46:19] <Honoome> yeah but they ignore it
[10:46:24] <Dark_Shikari> And they get sued.
[10:46:26] <Dark_Shikari> And they lose.
[10:46:37] <Honoome> when they are chinese?
[10:46:41] <thresh> like nvidia GPLed their module, riight.
[10:46:43] <Dark_Shikari> Nobody cares about the chinese.
[10:46:59] <Dark_Shikari> All the good phones are made in Taiwan.
[10:47:02] <lu_zero> uhmm
[10:47:10] <av500> Honoome: when they are chinese, their EUS retailers get sued
[10:47:14] <av500> Dark_Shikari: lol
[10:47:42] <Dark_Shikari> inb4 some PRC guy with "taiwan is part of china!!11!"
[10:47:43] <av500> you mean outsorced from taiwain
[10:47:55] <Honoome> av500: even gpl-violations dropped the ball on the guys who manufacture sw/hw for cnm
[10:47:56] <Dark_Shikari> it doesn't matter where they construct it, it matters where the company is =p
[10:48:03] <av500> Honoome: of course
[10:48:06] <Honoome> and I'm quite sure one of my customers is not respecting any (l)gpl at all
[10:48:15] * cartman grabs popcorn , its GPL t
[10:48:15] <cartman> i
[10:48:17] <cartman> time :P
[10:48:29] <Dark_Shikari> Honoome: these are the same companies that pirate commercial software
[10:48:32] <Dark_Shikari> so it's not really surprising
[10:48:39] <Honoome> I know
[10:48:46] <Dark_Shikari> I mean, there's nothing really special about the GPL here
[10:49:49] <funman> lu_zero: http://android-platform.googlegroups.com/attach/0f8eba5ecb95c6f4/OVERVIEW.TXT?gda=QFZfJ0UAAAB1RXoVyyH5sRXFfLYnAq48KOFqr-45JqvtfiaR6gxIj-gMse5yWxznC0BYAJoIzA6O3f1cykW9hbJ1ju6H3kglGu1iLHeqhw4ZZRj3RjJ_-A&view=1&part=4 : "we do not claim to be Posix-compliant"
[10:50:16] <Dark_Shikari> "we do not claim to be posix-compliant" is like "we do not claim that our cars drive on the road"
[10:51:25] * Dark_Shikari mutters something about http://www.urbandictionary.com/define.php?term=yard%20cars
[10:51:34] <Kovensky> <@Dark_Shikari> OH NO I CANT STEAL IT <@Dark_Shikari> AND NOT GIVE CREDIT <-- you can't do that either in BSDL
[10:51:59] <Dark_Shikari> Kovensky: yeah, isn't the BSD incredibly horribly encumbered?
[10:52:16] <Kovensky> <+av500> you mean outsorced from taiwain <-- not really, HTC is legit taiwanese
[10:52:20] <iive> Dark_Shikari: more like "we do not claim that our autonomous moving machines are cars"
[10:53:19] <funman> "except in our ads"
[10:53:34] <av500> Kovensky: I know
[10:53:47] <av500> still most .tw manufs have moved production to .cn
[10:54:54] <funman> how do you move production to a TLD? o:
[10:55:15] <kshishkov> I heard that most countries don't officialy recognize Taiwan in order not to anger China
[11:00:18] <lu_zero> ^^
[11:04:51] <DonDiego>  kshishkov yes, taiwan is only recognized by a small handful of states..
[11:05:44] <lu_zero> and taiwan itself is china by their definition
[11:06:02] <lu_zero> is the rest un-chinese
[11:06:10] <lu_zero> (and barbaric)
[11:06:54] <kshishkov> common approach
[11:07:03] <Dark_Shikari> no, the rest is chinese, not barbaric at all
[11:07:13] <Dark_Shikari> they would of course not want to claim responsibility over "barbaric" people
[11:07:20] <Dark_Shikari> it applies both ways
[11:07:32] <Dark_Shikari> neither side can admit the other side is bad in any way, because they both consider the other side to be part of them
[11:11:46] <CIA-92> ffmpeg: darkshikari * r24681 /trunk/libavcodec/ (vp8data.h vp8.c):
[11:11:46] <CIA-92> ffmpeg: VP8: unroll partition type decoding tree
[11:11:46] <CIA-92> ffmpeg: ~34% faster partition type decoding.
[11:12:56] <funman> commit log is properly aligned/indented. perfect.
[11:16:33] <_skal_paris_> i see an unrolling spree
[11:17:12] <Dark_Shikari> the vp8 tree idea thingy is a trap
[11:17:17] <Dark_Shikari> A TRAP.
[11:17:24] <Dark_Shikari> it looks like it makes everything simpler
[11:17:28] <Dark_Shikari> but really, it just makes everything slower.
[11:17:31] <funman> Dark_Akbar
[11:18:07] <_skal_paris_> yeah, it's rather elegant, and the tree traversal loop is tiny as in one-liner
[11:18:17] <_skal_paris_> but yeah, hardcoding pays off it seems
[11:18:29] <Dark_Shikari> hugely
[11:18:35] <Dark_Shikari> so much that I would, as I said, declare trees to be a trap.
[11:19:17] <_skal_paris_> now, you seem to have put the deepest branch first
[11:19:36] <_skal_paris_> if (bit) { if (bit) { if (bit) { ... } else { ..} } ...
[11:19:52] <_skal_paris_> what about if (!bit) {} else { if (!bit) {} else { ... }}}
[11:19:56] <_skal_paris_> ?
[11:20:17] <Dark_Shikari> why would that be any better?
[11:20:24] <Dark_Shikari> gcc iirc by default assumes that ifs are not taken
[11:20:24] <_skal_paris_> branch prediction
[11:20:34] <Dark_Shikari> why would it be any better for branch prediction?
[11:20:35] <Dark_Shikari> it just inverts it.
[11:22:14] <_skal_paris_> the code you're most likely to take is prefetch'd
[11:22:18] <CIA-92> ffmpeg: darkshikari * r24682 /trunk/libavcodec/x86/vp56_arith.h: VP5/6/8: add one inline missed in r24677
[11:22:33] <Dark_Shikari> _skal_paris_: are you saying you're most likely to take the deeper branches?
[11:22:41] <Dark_Shikari> I don't really agree with that
[11:22:53] <DonDiego> libavcodec/vp56.h:297: warning: ‘vp8_rac_get_sint’ defined but not used
[11:23:02] <_skal_paris_> the short ones
[11:23:05] <Dark_Shikari> DonDiego: what am I supposed to do?
[11:23:09] <Dark_Shikari> If I don't inline them, gcc bitches.
[11:23:13] <Dark_Shikari> If I do inline them, they bloat code needlessly.
[11:23:25] <Dark_Shikari> _skal_paris_: if the shorter ones are more likely, my code is right.
[11:23:26] <DonDiego> Dark_Shikari: seppukku?
[11:23:33] <DonDiego> :)
[11:23:33] <Dark_Shikari> lol
[11:23:37] <DonDiego> let me have a look
[11:23:39] <Dark_Shikari> seriously, is there some way to make gcc shut the hell up?
[11:23:44] <Honoome> blame lu_zero, works for me most of the time
[11:23:59] <Dark_Shikari> DonDiego: those functions are only used for header parsing
[11:24:05] <Dark_Shikari> so inlining them is braindead
[11:25:09] <DonDiego> i think you can move them to vp8.c
[11:25:14] <DonDiego> or wherever they are used
[11:25:21] <Dark_Shikari> er... but some are used in vp5 and vp6
[11:25:27] <Dark_Shikari> shared between the two
[11:25:31] <Dark_Shikari> some are used in vp5, vp6, and vp8
[11:25:37] <DonDiego> the vp8 one? no..
[11:25:47] <Dark_Shikari> Yes, but that doesn't fix all the warnings
[11:25:54] <Dark_Shikari> libavcodec/vp56.h:313: warning: 'vp56_rac_gets_nn' defined but not used
[11:26:30] <DonDiego> but it does reduce their number?
[11:26:39] <Dark_Shikari> yes, but I don't think it's a solution
[11:26:46] <Dark_Shikari> it would be better to just make the functions av_unused or something
[11:26:51] <Dark_Shikari> than to arbitrarily split up code
[11:26:52] <lu_zero> there isn't an used attribute for that?
[11:27:10] <Honoome> __attribute__((unused)) -> tells the compiler that $whatever is possibly unused and known
[11:27:11] <lu_zero> that =P
[11:27:19] <DonDiego> why is that one not inline?
[11:27:28] <Dark_Shikari> DonDiego: because it's header parsing only
[11:27:28] <lu_zero> Honoome: btw
[11:27:31] <Dark_Shikari> and it was bloating the code
[11:27:32] <lu_zero> how's going?
[11:27:51] <DonDiego> vp56_rac_gets_nn bloating the code?
[11:28:01] <Dark_Shikari> All of the header-parsing arithcoder functions were being inlined.
[11:28:01] <Honoome> lu_zero: bad
[11:28:03] <Dark_Shikari> Repeatedly.
[11:28:04] <Dark_Shikari> In dozens of places.
[11:28:08] <Dark_Shikari> This is bad.
[11:28:23] <DonDiego> i think by now the vp56.h header is misnamed
[11:28:29] <Dark_Shikari> it should be vp568.h
[11:28:30] <DonDiego> it should be vpx.h or whatever
[11:28:34] <Dark_Shikari> and when we add vp7
[11:28:37] <Dark_Shikari> it will be vp5678.h
[11:28:57] <DonDiego> vpx.h
[11:28:59] <Dark_Shikari> and when google releases vp9
[11:28:59] <DonDiego> anyway
[11:29:01] <Dark_Shikari> vp56789.h
[11:29:18] <Dark_Shikari> why was vp6 afraid of vp7?  because vp7 vp8'd vp9.
[11:29:30] <mru> DonDiego: or it's just showing how vp8 is really just a tweaked vp6
[11:29:34] <DonDiego> if the functions are only ever used in vp8.c i see no reason for them not to be static functions in that file
[11:29:48] <Dark_Shikari> DonDiego: because the header is self-contained
[11:29:55] <Dark_Shikari> you shouldn't have bitstream functions outside of that
[11:30:01] <Dark_Shikari> it's conceptually wrong
[11:30:09] <mru> uh?
[11:30:13] <Dark_Shikari> I want all my bitstream code in one place
[11:30:20] <Dark_Shikari> I don't want little bits of arithcoder here, there, and all over
[11:33:08] <DonDiego> then mark as av_unused or whatever
[11:33:29] <Dark_Shikari> ok one moment
[11:35:14] <CIA-92> ffmpeg: darkshikari * r24683 /trunk/libavcodec/vp8.c:
[11:35:14] <CIA-92> ffmpeg: VP8: make another RAC call branchy
[11:35:14] <CIA-92> ffmpeg: 1-2 clocks faster.
[11:36:29] <CIA-92> ffmpeg: darkshikari * r24684 /trunk/libavcodec/vp56.h: Silence unused function warnings in vp56.h
[11:40:03] <Dark_Shikari> should we make decode_frame_header av_cold?
[11:47:00] <lu_zero> Dark_Shikari: does it make a difference?
[11:49:24] <_skal_paris_> Dark: decode_block_coeffs() is unrolled the other way round
[11:49:40] <mru> anti-clockwise?
[11:50:00] <_skal_paris_> un-un-unrolled?
[11:50:06] <mru> if you unroll a loop anti-clockwise, does it use negative amount of cycles?
[11:50:20] <_skal_paris_> depends on which hemisphere you're running the code in
[11:50:44] <lu_zero> that's why australians have custom versions
[11:53:17] <_skal_paris_> and if you unroll too fast, your code get back in time
[11:53:25] <_skal_paris_> and functions start to return before they're called
[11:55:58] <_skal_paris_> get_num_non_zero_coeffs(s) = nz;
[11:56:07] <_skal_paris_> that'd be cool
[12:00:17] <mru> http://news.ycombinator.com/item?id=1569559
[12:01:23] <kshishkov> sounds like a trolling
[12:01:43] <mru> there's actually some sane discussion there
[12:02:10] <mru> in the end it does of course reinforce my existing perception of bsd
[12:02:58] <kshishkov> BSD being a pure server OS?
[12:03:14] <mru> bsd being intentionally full of old cruft
[12:09:32] <lu_zero> but
[12:09:42] <lu_zero> they state that innovation starts there!
[12:09:44] <lu_zero> =P
[12:11:49] <av500> ...If I need to work with a digital camera or a flash drive, I just reboot into Ubuntu and do it quickly there. FreeBSD is strictly for work (in theory)....
[12:12:32] <av500> ....And it's a single community, without the balkanization of GNU/Linux....
[12:13:10] <mru> I don't see a problem with multiple communities
[12:13:35] <av500> and I see one Linux maintained kernel, not 5
[12:13:41] <mru> I'm _happy_ to have the debian people tucked away in their own corner
[12:13:42] <av500> ->Linus
[12:13:52] <av500> :)
[12:14:22] <mru> I guess you could call all the free, open, net, etc "bsd distros"
[12:14:29] <mru> each with their own community
[12:14:33] <av500> of course
[12:14:44] <mru> so in fact bsd is _more_ fragmented than linux
[12:14:53] <mru> since they don't even share the same kernel
[12:15:06] <thresh> that argument doesnt work on bsd zealots
[12:15:27] <thresh> philosophy is what they share
[12:16:09] <mru> oh no, openbsd is _totally_ different from netbsd
[12:16:20] <mru> just ask theo de rant
[12:16:23] <av500> wow, 12k more memory will make chrome explode....
[12:16:56] <DonDiego> av500: ?
[12:17:07] <av500> http://code.google.com/p/chromium/issues/detail?id=50811
[12:18:32] <DonDiego> this is the most trollish, out-of-context misquote i have heard in years..
[12:18:55] <DonDiego> "ff vp8 takes 12423 bytes more memory (per instance); A drawback but not enough to be a show stopper."
[12:19:17] <DonDiego> he puts it into perspective in the *next sentence*...
[12:19:39] <av500> tl;dr :)
[12:20:53] <siretart> FYI: http://video.debconf.org:8000/davis_auditorium.ogv will show at 9:30 (in about an hour) a probably interesting talk by Eben Moglen
[12:21:44] <spaam> siretart: about what?
[12:21:50] <av500> btw, why add more --disable-* stuff after --disable-everything?
[12:21:53] <mru> gpl presumably
[12:22:18] <siretart> http://penta.debconf.org/dc10_schedule/events/641.en.html
[12:22:26] <mru> av500: everything doesn't disable quite everything
[12:22:40] <mru> it still builds the skeleton of each lib
[12:22:40] <av500> --disable-almost-everything?
[12:23:10] <av500> mru: ok, but do I need --disable-decoders after --disable-everything?
[12:24:02] <lu_zero> the last numbers look strange at best
[12:24:38] <kierank> wow, google are actually getting rid of libvpx
[12:24:57] <kierank> credit must go to them for not being NIH for once
[12:25:12] <av500> well, ffmpeg by itself is NIH for them
[12:25:51] <av500> they have no issue to write their own player framework for e.g. android
[12:26:18] <mru> av500: no everything includes "decoders" etc
[12:26:32] <av500> so the configure line can be much shorter
[12:26:36] <av500> the gg one
[12:26:41] <mru> oh yes
[12:27:13] <av500> is the configure line part of the binary?
[12:27:19] <mru> yes
[12:27:27] <av500> so, they can save on size there :)
[12:28:05] <lu_zero> the android one came from a partner
[12:28:13] <spaam> whynot add --small-binary-plix  and everything will get removed..
[12:28:13] <av500> stagefright?
[12:28:20] <av500> lu_zero: ^^^
[12:28:30] <lu_zero> and we didn't step up in time to replace it
[12:29:04] <av500> http://freepine.blogspot.com/2010/01/overview-of-stagefrighter-player.html
[12:29:11] <av500> they replaced it themselves it seems :)
[12:29:44] <av500> ...which seems to be quite simple and straightforward compared with the OpenCORE solution....
[12:29:49] <av500> yes: http://2.bp.blogspot.com/_QB83bh_YCwU/S0G5-sigfRI/AAAAAAAAABk/5ee0fijMFXs/s1600-h/StageFrighter+overview.bmp
[12:30:21] <kierank> when we understand that diagram we win the war
[12:30:26] <av500> yeah
[12:30:41] <mru> omg omx
[12:30:58] <mru> but it has AWESOME!!!
[12:31:02] <av500> mru: yep, for the codecs!
[12:31:33] <av500> AFAIK, they wrote that to play flash video
[12:31:57] <av500> the whole stagefright thing, after they did not find a place to plug flashvideo into PacketVideo player
[12:34:45] <cartman> AwesomePlayer? really?
[12:34:46] <cartman> hahah
[12:35:13] <av500> mostAwesome
[12:35:20] <KotH> av500: wtf is taht?
[12:35:40] <cartman> an awesome design
[12:35:47] <mru> reminds me of http://blogs.adobe.com/penguin.swf/linuxaudio.png
[12:36:14] <av500> KotH: its StageFright
[12:36:23] <av500> you live under a rock or what?
[12:36:24] <mru> frightful indeed
[12:36:24] <cartman> OpenAL works the simple way out
[12:36:59] <av500> mru: I bet there is a math transform to get one block diagram into the other
[12:37:57] <lu_zero> av500: pff
[12:38:06] <lu_zero> still their design sounds...
[12:38:09] <kshishkov> av500: I cherish my ignorance of StageFright, GStreamer and such
[12:38:12] <lu_zero> bad?
[12:38:30] <av500> lu_zero: no idea, I have not looked into it
[12:38:35] * mru had not heard of stagefright until 5 minutes ago
[12:38:36] <kshishkov> av500: and it's not math transform, it's XSLT :P
[12:38:50] <av500> there is a reason our products ship with our own media stack
[12:39:01] <lu_zero> maybe I'm wrong but it could be simpler
[12:39:17] <kshishkov> lu_zero: you're wrong, it should be more complicated
[12:39:27] <kierank> [13:38] <+av500> there is a reason our products ship with our own media stack --> NIH
[12:39:28] <lu_zero> and I wonder how ffmpeg would look on the same graph style
[12:39:47] <lu_zero> kierank: I think AIH
[12:40:01] <lu_zero> and AWH
[12:40:05] <lu_zero> even more important
[12:40:32] <av500> kierank: ours goes back to 1999/2000
[12:41:01] <av500> (written in Cobol etc..)
[12:41:17] <mru> that's before the beginning of time (aka ffmpeg r1)
[12:41:26] <kshishkov> hmm, written in Cobol == goes back to 1960s
[12:41:40] <cartman> Cobol media framework, lol :D
[12:42:17] <av500> mru: well, at that time it was a loop that pushed bytes into a HW mp3 decoder :)
[12:42:29] <kshishkov> I hope codecs were written in Fortran with APL for DSP parts
[12:42:30] <av500> and cobol was a joke
[12:42:33] <mru> av500: memcpy?
[12:42:46] <av500> no, serial with DMA
[12:51:07] <benoit-> funman's gone... too abd
[12:51:08] <benoit-> bad
[12:51:11] <benoit-> http://www.talkandroid.com/9044-video-lego-mindstorm-remote-control-for-android-2-1-1-6/
[12:59:44] <KotH> av500: quite literally yes. you know, switzerland has huge rocks, called "the alps" :-)
[13:01:09] <Honoome> mru: Mike's graph is incomplete
[13:01:16] <Honoome> it lacks the alsa-to-pulseaudio link
[13:01:24] <Honoome> and the alsa-to-jack as well
[13:02:00] <kshishkov> KotH: .ch is not alone, I've seen Alps in Germany, Bayern and I heard there're also Alps in Austria
[13:02:49] <lu_zero> kshishkov: also here
[13:03:21] <kshishkov> lu_zero: not in Torino though, I think
[13:03:40] <lu_zero> kshishkov: ehm...
[13:03:57] <lu_zero> do you know where Torino is?
[13:04:17] <av500> in small italian cars?
[13:05:09] <kshishkov> lu_zero: ah, I see. I thought it would be somewhere in the middle of Italy
[13:05:24] <lu_zero> nope
[13:05:44] <kshishkov> yes, I've looked at the map
[13:06:32] <lu_zero> =)
[13:06:52] <kshishkov> av500: looks like Fiat was popular in underdeveloped countries - Serbia, USSR, India, Italy
[13:07:15] <Honoome> didn't fiat buy gm not too long ago?
[13:07:36] <kshishkov> two words: im-possible
[13:08:16] <lu_zero> Chrysler
[13:08:29] <Honoome> ah thanks got the wrong american manufacturer
[13:08:38] <Honoome> gm only had a deal back in 2003 and backed off
[13:08:58] <kshishkov> the company that even Daimler-Benz didn't find any use of?
[13:08:59] <lu_zero> and Alfa Romeo is apparently popular in UK, Japan and Germany...
[13:09:40] * lu_zero never bought fiat btw
[13:09:57] * kshishkov had Alfa Romeo slippers once, not very fast nor convenient
[13:10:06] <lu_zero> slippers?
[13:10:27] <av500> lu_zero: my dad drove alfas for 40ys...
[13:10:35] <kshishkov> lu_zero: houseshoes
[13:10:39] <av500> nice engines....
[13:11:06] * Honoome doesn't even have a driver's license
[13:11:25] <kshishkov> Honoome: no wonder with all those Fiats around
[13:11:41] * kshishkov has neither driver license nor intent to get one
[13:11:41] <Honoome> kshishkov: I don't think I would buy Fiat anyway
[13:11:58] <Honoome> I'd rather go with something without a stick shift
[13:12:01] <lu_zero> http://green.autoblog.com/2008/06/09/mito-convertible-coming-to-the-us-in-2010/
[13:27:36] <twnqx> ffprobe: libavutil/mathematics.c:79: av_rescale_rnd: Assertion `c > 0' failed.
[13:27:36] <twnqx> Aborted
[13:27:38] <twnqx> ahahahaha
[13:27:39] <twnqx> :]
[13:28:08] <kshishkov> you probed too deep, it seems
[13:28:28] <twnqx> so... how do i extract subs from .avi?
[13:28:38] <av500> dd?
[13:28:43] <twnqx> Oo
[13:29:06] <cartman> O_o
[13:29:24] <twnqx> i bet there's no support for these avi hacks yet...
[13:29:31] <twnqx> this is a dual-audio with subtitles file...
[13:29:45] <twnqx> soft subtitles.
[13:30:30] <lu_zero> in avi?
[13:30:34] <twnqx> yes, in avi
[13:30:44] <lu_zero> and does play?
[13:30:54] <av500> didnt avi get an ASS demuxer just last week?
[13:30:58] <twnqx> i think vlc supports it...
[13:31:05] * lu_zero wonders when we'll have audio+video+subs in tar
[13:31:26] <lu_zero> and random xml files in nut as odt alternative =E
[13:31:38] <siretart> http://video.debconf.org:8000/davis_auditorium.ogv starts now
[13:31:55] <thresh> does it have nice looking girls?
[13:32:07] <Honoome> siretart: ogv in this channel? :P
[13:32:47] <thresh> and it froze :(
[13:33:24] <av500> twnqx: [FFmpeg-devel] [PATCH 8/8] avidec: demux ASS and SRT tracks
[13:33:33] <twnqx> oh wow
[13:33:38] <twnqx> time to update!
[13:33:58] <av500> twnqx: your file available as a sample?
[13:34:12] <twnqx> prolly not
[13:34:17] <twnqx> i have more than one, though...
[13:34:29] <twnqx> prefer hentai or normal anime? :P
[13:34:42] <twnqx> this one is 700+MB
[13:34:43] <av500> your choise
[13:34:57] <av500> so I can say, I was not involved :)
[13:35:02] <twnqx> but it has dual audio and crashes ffprobe.
[13:35:17] <DonDiego> hmm
[13:35:23] <DonDiego> does the stream work for anyone?
[13:35:31] <av500> it worked for 3s
[13:35:48] <av500> then I realized my browser has no audio and when I retried it was gone
[13:36:03] <av500> but ogv is good for streaming, right?
[13:37:39] <kshishkov> is it good for anything?
[13:37:55] <janneg> I couldn't connect
[13:38:04] <av500> kshishkov: it's good for a 404
[13:40:31] <twnqx> still crashes with assertion failed
[13:42:14] <DonDiego> j-b: can you tell me how to force vlc to use libmpeg2 for decoding?
[13:42:29] <DonDiego> i'm hunting down a libmpeg2 crash in mplayer
[13:45:20] <kshishkov> maybe it's another reason to switch to lavc?
[13:45:28] <mru> what kshishkov said
[13:46:48] <BBB> please dump libmpeg2
[13:47:06] <BBB> the developer of libmpeg2 is such an incredible asshole that you should just reject any of his software outright
[13:47:07] <BBB> </flame>
[13:47:22] <mru> there's a developer?
[13:47:30] <kshishkov> like we did to liba52 ?
[13:47:38] <kshishkov> or swscale parts?
[13:49:10] <cartman> vlc still uses those libraries, interesting given ffmpeg could decode those
[13:49:21] <cartman> a52, libmad, libfaad, etc.
[13:49:25] <Honoome> xine also used to use a (hacked) libmpeg2
[13:49:26] <thresh> mru: and you've seen him on VDD
[13:50:02] <thresh> well, one of current maintainers that is
[13:50:18] <merbzt> who is it
[13:50:41] <thresh> do you promise not to shoot him in the head?
[13:50:52] <KotH> BBB: i dont know about know. but a year or two back, it was said that libmpeg2 has less trouble with broken files than lavc has
[13:51:07] <thresh> Meuuh was on VDD last year
[13:51:23] <mru> KotH: that's one of those myths that refuses to die
[13:51:28] <DonDiego> BBB: umm, the maintainer of libmpeg2 is j-b, so watch your step
[13:51:38] <mru> DonDiego: since when?
[13:51:53] <DonDiego> since some time, sam has become inactive
[13:51:59] <BBB> DonDiego: I don't mean the current
[13:52:04] <mru> DonDiego: it was sam before?
[13:52:12] <DonDiego> BBB: then who are you talking about?
[13:52:19] <BBB> the oldies, the original developers
[13:52:28] <DonDiego> and since when does the character of the author affect sw choice?
[13:52:30] <mru> the guy whose name is plastered in the copyright headers of course
[13:52:33] <KotH> mru: uhmm.. it was reimar (iirc) who said that.. and i trust his judgement :)
[13:52:34] <mru> I forget the name
[13:52:35] <cartman> oh the ones that let linux users watch pr0n
[13:52:40] <cartman> those were the good guys!
[13:52:44] <kshishkov> walken
[13:52:46] <BBB> KotH: then fix that bug in lavc, and dump libmpeg2 still
[13:53:08] <KotH> BBB: i've a couple of open bugs from mplayer on my table.. havent time to fix them
[13:53:09] <BBB> KotH: also, please point me to the roundup bug#
[13:53:21] <BBB> KotH: and mplayer bug#s don't count
[13:53:30] <KotH> lol
[13:53:43] <KotH> BBB: it's the only player i use, so it counts for me :)
[13:54:18] <KotH> BBB: and dont tell me to use vlc. because i failed to compile it last time i tried ;-)
[13:54:18] <cartman> decode to PPM and use display(1) in a loop :-P
[13:54:28] <KotH> ^^'
[13:54:34] <BBB> KotH: I was going to suggest to use ffplay
[13:54:38] <BBB> but I'll not say anything
[13:54:47] <KotH> BBB: i'm not enough a masochist to use sdl
[13:54:52] <BBB> hehehe :)
[13:55:02] * Honoome is having a very evil idea
[13:55:09] <Honoome> use gource over ffmpeg... and produce a vp8 file! :P
[13:58:55] <lu_zero> Honoome: uhm
[14:36:47] <kierank> does anybody understand ac-3 lowcomp?
[14:39:27] <kshishkov> probably not, what's the matter?
[14:40:09] <kierank> well i need to write lowcomp for dolby e (last major piece) and bit allocation as a whole is very similar to ac-3
[14:40:46] <kshishkov> good chances Dolby people didn't understnad it either and just copied it
[14:41:07] <kierank> their code is very very ugly
[14:41:26] <kshishkov> no, it's moderately ugly
[14:41:56] <kierank> the one in the binary i mean
[14:42:19] <kshishkov> that's true
[14:42:52] <kshishkov> still, it should be rather easy to reshape it into the form in AC-3 spec
[14:43:10] <kierank> well sometimes it is different
[14:46:40] <kshishkov> I still see no problems with that - it you can present it in the same form, differences will be obvious
[15:32:36] <av500> mru: I knew for #33 :)
[15:33:39] <mru> it was practically asking for it
[15:36:48] <lu_zero> ?
[15:37:09] <mru> http://26-26-54.hardwarebug.org/?id=33
[15:37:48] <mru> I assume that's what he's referring to
[15:38:10] <av500> yep
[15:38:27] <av500> btw, TI writes fun code: http://ffmpeg.pastebin.com/jJ0L6sH9
[15:38:58] <mru> makes me wonder what 'msg' is...
[15:39:07] <av500> 20 bytes struct
[15:39:16] <mru> unpossible
[15:39:29] <mru> it must be an array or a pointer
[15:39:36] <mru> or possibly an int
[15:39:42] <av500> 20 bytes struct
[15:39:48] <mru> you can't cast a struct to a pointer
[15:40:52] <mru> there are a lot of bugs in that code snippet...
[15:40:53] <av500> http://ffmpeg.pastebin.com/7rZzkQzs
[15:41:07] <mru> so it's a pointer to a struct
[15:41:11] <mru> huge difference
[15:41:18] <av500> yeah, sorry
[15:41:32] <mru> and now I see even more bugs
[15:41:33] <lu_zero> that would be even more unsettling
[15:41:37] <mru> let's see...
[15:41:46] <mru> sizeof(msg) obviously wrong
[15:42:06] <funman> i assume arg* are 'for extensions purposes' ?
[15:42:17] <av500> command arguments
[15:42:25] <av500> you never need more than 4! ever!
[15:42:35] <mru> int err is wrong; should be ssize_t
[15:42:59] <mru> if (err < 0) is wrong; should be == -1
[15:43:09] <mru> (ssize_t)-1 even
[15:43:18] <lu_zero> that's nitpicking
[15:43:24] <mru> missing p += err
[15:43:32] <av500> mru: yep
[15:43:48] <mru> writing pointer values makes no sense
[15:43:54] <mru> x4 for that one
[15:44:23] <mru> and indentation is beyond fucked up
[15:44:27] <av500> :)
[15:44:35] <lu_zero> av500: something left?
[15:46:11] <av500> lu_zero: I've had enough :)
[15:46:19] <lu_zero> one more
[15:46:23] <lu_zero> it's C++
[15:46:34] <lu_zero> so using pointers that way is a bit...
[15:46:38] <lu_zero> strange?
[15:46:53] <av500> which ones?
[15:47:06] <lu_zero> all
[15:47:21] <lu_zero> C++: you don't use pointers that way
[15:47:39] <mru> then how do you call write()?
[15:47:51] <funman> this->Write();
[15:47:58] <Honoome> mru: you don't, just as you can't call any printf() variant
[15:48:26] <mru> Honoome: then wtf do you do?
[15:48:31] <Honoome> because it's MUCH nicer to do something like std::cout << hex << digits(8) << val; rather than printf("%08x", val)
[15:48:44] <mru> that doesn't work with file descriptors
[15:49:01] <mru> and yes, I sense the sarcasm
[15:49:13] <Honoome> ignore file descriptors for a moment, how the heck are you supposed to use crap like that FOR STDOUT?
[15:49:21] <mru> indeed
[15:49:44] <mru> besides, stdout is hardly enterprisey in the first place
[15:50:21] <kshishkov> Honoome: but it would be fun to print next number to cout!
[15:50:48] * Honoome still can't think of any good sense in using iostream
[15:50:53] <av500> lu_zero: so how do you do it in the above case?
[15:51:11] * mru throws a BufferedOutputStreamFactoryStream at Honoome 
[15:51:12] <kshishkov> to display you're hardcore C++ programmer and not some C newbie
[15:52:35] <lu_zero> av500: using proper C++ ?
[15:52:49] <av500> lu_zero: one more, -EINTR is treated as fatal
[15:53:00] <funman> please leave aside the C/C++ war. some are trying to install Java here.
[15:53:23] <kshishkov> so you wanna be flamed, eh?
[15:53:29] <av500> lu_zero: /me does not know proper CPLUSPLUS
[15:53:32] <lu_zero> funman: use jruby!
[15:53:35] <thresh> jfjfmpeg?
[15:53:42] <av500> ffjpeg
[15:53:46] <funman> gfmpeg
[15:53:55] <kshishkov> JFFmpeg EE
[15:53:58] <av500> slowpeg
[15:54:01] <thresh> av500: but wouldnt that mean still images only :(
[15:54:09] <funman> av500: slowpig?
[15:54:11] <av500> thresh: with the speed of java, yes
[15:54:14] <thresh> well, if one codes a decoder in java, it probably will
[15:54:15] <thresh> yeah
[15:54:21] <kshishkov> On2 did
[15:54:29] <Honoome> lu_zero: don't talk about jruby with me around... please
[15:54:34] <av500> kshishkov: and look where it got them :)
[15:54:44] <lu_zero> av500: the code should take the whole struct and serialize on a socket?
[15:54:53] <kshishkov> av500: to the Heaven^W Google?
[15:55:12] <lu_zero> or pick the content of the struct and push it?
[15:55:17] <av500> kshishkov: see, write white papers and java and you get rich quick
[15:55:21] <lu_zero> that alone makes me wonder ^^;
[15:55:49] <lu_zero> and I just know what is a no-no in C++ but not how to fix it since I do not like to touch it
[15:56:00] <lu_zero> (and I have somebody doing that kind of stuff for me)
[15:56:16] <av500> sudo make me a c++ code
[15:56:20] <funman> "go forth and fix this C++, minion"
[15:56:29] <kshishkov> go Forth?
[15:56:30] <lu_zero> funman: not that far
[15:56:47] <lu_zero> it's more "C++ sucks, prove me I'm wrong and fix this mess"
[15:56:59] <funman> kshishkov: seems that it means "go to the battlefield" or something
[15:57:26] <funman> lu_zero: did this person ever prove you wrong?
[15:57:27] <lu_zero> followed a solution with "see, it's not the language"
[15:57:46] <kshishkov> funman: I know, but Forth was also a language, popular on raw hardware and known for Yodaspeak
[15:58:10] <funman> ah i only know forthran
[15:58:19] <av500> so Yoda is stack based?
[15:58:37] <kshishkov> that could he be
[15:59:02] <kshishkov> Japanese language is stack-based, for example
[15:59:02] <lu_zero> kshishkov: your stack is upsidedown
[15:59:39] <kshishkov> lu_zero: so?
[16:00:00] * lu_zero started to parse from the right, not the left
[16:00:21] * kshishkov just used shuffle for that example
[16:00:33] <lu_zero> japanese is more or less implicit-free-form
[16:00:59] <kshishkov> nope
[16:00:59] <lu_zero> since you have most of the time ellipsis of
[16:01:02] <lu_zero> subject
[16:01:04] <lu_zero> verb
[16:01:10] <lu_zero> subject and verb
[16:02:24] <DonDiego> bye
[16:02:29] <lu_zero> oh
[16:02:39] <kshishkov> <some word>particle <some word>particle <end operation>
[16:03:03] <funman> e
[16:03:18] <lu_zero> you have <verb> as end operation most of the time
[16:04:36] <kshishkov> see
[16:05:07] <lu_zero> but you can omit it
[16:05:08] <kshishkov> so it's "push word", "modify word with particle", "invoke verb on stack"
[16:05:39] <lu_zero> and the canonical form require you to have a subject declared at the start
[16:05:52] <lu_zero> subject/theme
[16:05:59] <lu_zero> since it isn't completely a subject
[16:06:41] <funman> /media/bordel/rockbox/apps/codecs/libwma/wmafixed.h:97: error: redefinition of 'fixmul32'
[16:06:43] <lu_zero> and you have stuff like
[16:06:44] <funman> /media/bordel/rockbox/apps/codecs/libwma/wmafixed.h:97: note: previous definition of 'fixmul32' was here
[16:06:56] <funman> worth bashing gcc?
[16:07:13] <lu_zero> kore wo futatsu
[16:07:20] <lu_zero> that's a phrase
[16:07:27] <lu_zero> missing theme and verb
[16:07:53] <lu_zero> funman: only if that line doesn't have void fixmul(); int fixmul();
[16:08:19] <funman> no the declaration is ok, but the the file is included twice
[16:08:43] <funman> gcc 4.6 will bring nicer error/warnings report btw
[16:08:52] <av500> file is included twice, that must never happen!
[16:08:59] <funman> twice the fun!
[16:09:03] <av500> its like crossing the beams!
[16:23:55] <peloverde> Hmmm.... refdec has no option to export MDCT coefs
[16:30:09] <peloverde> What to people think about adding some debug code to aacdec for aacx?
[16:37:09] <Compn> is it beams or streams?
[16:38:20] <av500> streams
[16:38:24] <av500> sorry
[16:41:31] <funman> you can/should genetically cross the beans though
[16:43:22] <mru> in soviet russia stream crosses you
[17:38:36] <j0sh> lu_zero: wbs: got your emails
[17:38:52] <j0sh> im biking to the beach right now, will address them once im back later this afternoon
[17:46:35] <av500> beah? the laptop can get wet
[17:46:39] <av500> +c
[17:47:23] <kshishkov> better use somebody's else laptop
[17:50:05] <av500> or stay away from untreated silicon
[17:55:05] <kshishkov> silicon is fine for fanless models, non-chemical clean water is not
[18:03:44] <mru> beaches seem to go better with silicone
[18:07:45] <av500> these bumpers people keep talking about?
[18:09:47] <kierank> any ideas as to what this is trying to achieve: http://pastebin.org/446106
[18:10:08] <av500> confuse people?
[18:12:04] <peloverde> Does anyone have any good ideas on how to best export data from the aac decoder to aacx?
[18:12:18] <av500> aacx is what?
[18:12:43] <peloverde> A clone of this for AAC http://lame.sourceforge.net/images/gpsycho.gif
[18:12:48] <mru> kierank: looks equivalent to y = x > 0 ? x : 0;
[18:12:50] <funman> kierank: y = (x > 0) ? x : 0; // ?
[18:13:11] <peloverde> Ideally to help people working on the encoder
[18:13:13] * funman likes parenthesis more
[18:13:17] <mru> which I'd write as y = x & ~(x >> 31)
[18:13:42] * funman throws a 16 bits int at mru
[18:13:53] * mru uses a 32-bit cpu
[18:14:06] <av500> funman: you gave no types at all, it could be pointers....
[18:21:42] <kierank> meh way more simple than i thought then
[18:23:17] <mru> kierank: what's this? some "spec"?
[18:25:38] <kierank> some asm
[18:25:51] <Dark_Shikari> holy shit
[18:25:56] <Dark_Shikari> I just got an email from...
[18:25:58] <Dark_Shikari> "
[18:25:58] <Dark_Shikari> As you may know, I'm founder and chairman of Real.   I'm also now working with a start-u company that is using FFMPEG and that may be interested in your consulting help.
[18:26:05] <av500> glaser?
[18:26:08] <Dark_Shikari> Yeah
[18:26:12] <av500> wow
[18:26:40] <av500> you famous!
[18:27:00] <kierank> make one more buffering joke and he'll explode
[18:27:03] <Dark_Shikari> lol
[18:27:08] <av500> lol
[18:27:18] <av500> kshishkov: your chance!!!
[18:27:20] * Dark_Shikari makes note to not mention that word
[18:27:41] <kierank> maybe you're related to him Dark_Shikari
[18:27:47] <Dark_Shikari> Doubtful, but who knows
[18:27:55] <Dark_Shikari> actually I wonder.  maybe.
[18:28:02] <Dark_Shikari> is he jewish?
[18:28:16] <Dark_Shikari> (the "Glaser" side of my family is)
[18:28:28] <kierank> yes he's jewish
[18:28:50] <janneg> ReligionJewish[
[18:28:50] <Dark_Shikari> Oh.  He might actually be related to me then.
[18:29:13] <kshishkov> janneg: I'd say it's a lifestyle, not a religion
[18:29:24] <Guest94165> dont mention it, or he'll expect a family discount :-)
[18:29:26] <kierank> kshishkov: it's a state of fine
[18:29:29] <kierank> mind*
[18:29:44] <kshishkov> kierank: not only mind, but that too
[18:29:57] <Dark_Shikari> There are a lot of Rob Glasers though.
[18:29:57] <av500> Dark_Shikari: facebook is one of the companies :)
[18:30:19] <kshishkov> Dark_Shikari: I'd like to troll him though
[18:30:59] <Dark_Shikari> anyways, I'll ring him up.
[18:31:18] * kshishkov wonders how "I've reverse-engineered some of your shit" would look on resume
[18:31:25] <StinkerInker> apparently the guy was worth 2 billion 10 years ago
[18:31:42] <av500> does wealth rub off over the phone?
[18:31:49] <kierank> no
[18:32:03] <kshishkov> it's buffered somewhere else
[18:32:27] <Dark_Shikari> lol.  he didn't expect me to call him back so fast
[18:32:34] <Dark_Shikari> was on another call, so I'll talk to him this afternoon.
[18:32:38] <av500> live transcript?
[18:32:40] <StinkerInker> lol
[18:32:41] <kierank> lol
[18:32:53] <kierank> Dark_Shikari: get him to pay for 10-bit
[18:32:56] <Dark_Shikari> kierank: lol
[18:32:56] <kierank> h.264
[18:32:59] <kierank> and anything else we need
[18:33:05] <Dark_Shikari> Speaking of which, I just got another company emailing me who wants 4:4:4
[18:33:08] <Dark_Shikari> for the exact same reason my company does
[18:33:24] <av500> easier to type?
[18:33:25] <Dark_Shikari> I wonder how long it would take to get it done in lavc and x264 if I could get, say, $50000.
[18:34:37] <kierank> get aac encoder sorted, vc-1 interlaced etc
[18:34:49] <kierank> he probably has pillows worth more than the total cost of those
[18:34:53] <funman> no one want to sponsor Lego ? :(
[18:35:34] <Dark_Shikari> http://en.wikipedia.org/wiki/Rob_Glaser
[18:35:36] <Dark_Shikari> he has a wikipedia page
[18:36:06] <kierank> the founder of on2 is on reddit
[18:36:13] <kshishkov> funman: I'd donate you a brick or two but they are not here
[18:36:17] <Dark_Shikari> well obviously, he need to promote his vpshit
[18:36:33] <kshishkov> and buffer enough of RV hype
[18:36:44] <kierank> he doesn't talk about video compression
[18:36:44] <funman> kshishkov: thanks
[18:36:51] <kierank> and i think he left long before vp7/8
[18:37:20] <kshishkov> funman: just bring a fresh juicy codec :-E~~~
[18:37:31] <kierank> also I just realised vp3 was open source in 2001
[18:37:38] <kierank> that's AN ETERNITY ago
[18:38:17] <av500> kierank: url?
[18:38:21] <kshishkov> that's year 0 AF (Anno FFmpegi)
[18:38:29] <kierank> av500, wikipedia
[18:38:40] <av500> [20:36:43] <kierank> the founder of on2 is on reddit
[18:40:43] <kierank> reddit has a crap user search
[18:43:25] <kierank> his username was dmiller or something like that
[18:43:32] <av500> k
[19:14:06] <kierank> http://lwn.net/Articles/398592/
[19:14:13] <kierank> "and an order requiring Westinghouse to turn over all infringing equipment in its possession to the plaintiffs, to be donated to charity"
[19:14:24] <kierank> hahahahaha
[19:14:47] <av500> free tvs
[19:15:33] <kierank> should be donated to ffmpeg's foundation so we can do "research" on them
[19:16:01] * funman waits until porn companies are reported to infringe on ffmpeg
[19:18:50] <av500> what "equipment" are you after?
[19:19:27] <funman> Hi-Def masters
[19:19:42] <av500> ic
[19:20:45] <kierank> well funman likes lego so maybe he wants other toys
[19:21:10] <funman> remote controlled dildo?
[19:22:05] * BBB should ask for a HDTV
[19:22:10] <BBB> that'll be fun ;)
[19:22:17] <funman> seems to exist already :/
[19:22:43] <funman> http://www.youtube.com/watch?v=17b2FcnU8pc
[19:23:04] <kierank> i presume that needs an nsfw warning
[19:23:13] <funman> it's on youtube so no
[19:23:24] <av500> and its in ffmpeg-devel, so no
[19:23:35] <funman> :)
[19:23:37] <thresh> funman: Russians even attacked Kasparov (world chess champion) with flying dildo.
[19:24:00] <thresh> http://www.youtube.com/watch?v=RjAf5qviH-A
[19:24:22] <funman> kasparov is very famous
[19:24:45] <av500> japan is very pixelated
[19:25:41] <av500> thresh: dildo UAV came unarmed?
[19:26:23] <thresh> av500: regrettably, yes :(
[19:26:30] <thresh> I wish it was armed with milk or something.
[19:26:55] <thresh> funman should know better the ingridients for that kind of thing.
[19:42:05] <peloverde> So we need AACX. It should make working on the encoder much easier. Right now AACX uses the reference decoder but the reference decoder doesn't export all the info we need, so my options are to extend the reference decoder or to find a way to pull information from ffaacdec into the grapher which is written in python, does anyone have any suggestions?
[19:42:15] <peloverde> The reference decoder sucks because the reference decoder is slow and broken on 64-bit systems
[19:42:39] <peloverde> But I don't really know a good way to get the info I need from ffaacdec without forkng it
[19:43:22] <wbs> BBB: what was the url to the rtsp stream with mp4a-latm that you posted a few days ago?
[19:43:37] <wbs> BBB: and do you have time to look at the applehttp demuxer sometimes soon?
[19:43:54] <BBB> rtsp://qt-ar.as34763.net/ar32.sdp
[19:43:58] <peloverde> Just sicking dprintfs everywhere seems very ugly
[19:44:06] <BBB> wbs: please ping it
[19:44:17] <BBB> wbs: I'll look at it, have more time now than last week
[19:44:23] <peloverde> not to mention duplicate message aggregation is annoying
[19:46:28] <BBB> peloverde: I'd still stick in dprintf()s in ffaacdec
[19:46:43] <BBB> I mean, if we can't use our decoder for such purposes, basically our decoder isn't very useful
[19:46:58] <BBB> even if that purpose isn't exactly the decoding of a bytestream into pcm
[19:47:21] <peloverde> Is there a way to turn duplicate message aggregation off?
[19:48:41] <mru> someone whould revert michael's last "fix" to that
[19:49:17] <BBB> you could always use a local hack so yuo don't use av_log but #undef printf and then printf()
[19:49:32] <mru> or put a counter in the message
[19:49:51] <BBB> lol :)
[19:56:16] <peloverde> I've managed to make the messages unique in a semihacky manner
[19:56:49] <av500> added a timestamp?
[19:57:23] <kierank> http://www.burwenaudio.com/AUDIO_SPLENDOR.html
[19:57:49] <av500> xls?
[19:58:14] <kierank> yes
[19:58:27] <av500> is there something very wrong?
[20:02:15] <kierank> av500: the dsp calculations are done in excel
[20:02:32] <kierank> and apparently it's not a troll
[20:02:40] <sjhor> kierank: Price $14,000 including shipping.
[20:02:58] <av500> ....2.  On the Security Tab, Macro Security, select Low....
[20:03:21] <cartman> xlib burns my eyes
[20:04:39] <av500> lol
[20:04:41] <av500> http://www.burwenaudio.com/A_S_Tips_on_Windows.html
[20:05:40] <mmu_man> tips on windows ?
[20:05:45] <mmu_man> tip 1: uninstall
[20:05:55] <mmu_man> tip 2: install a real OS (GNU/Linux, Haiku...)
[20:06:33] <Dark_Shikari> >GNU/Linux
[20:06:39] <cartman> bad trolll baddddd
[20:06:48] <cartman> Steve/Leopard
[20:06:49] <cartman> :p
[20:07:30] <mmu_man> ;)
[20:08:07] <av500> Steve/Leotard
[20:08:31] <cartman> SlowLeopard maybe
[20:10:02] <mmu_man> slow & buggy ;)
[20:39:46] <funman> mt: ping
[20:40:14] <mt> funman:  pong
[20:40:42] <funman> please tell them you are the rockbox wma/codecs guy, these people keep asking me about this stuff :'(
[20:40:56] <av500> mru: you stole my line! :)
[20:41:24] <mru> I challenge you to take it back
[20:41:48] <av500> I donate it for the cause
[20:41:56] <mt> Okay what funman said :)
[20:42:22] * av500 asks mt about wma/codecs stuff
[20:42:26] <mt> although saratoga is the wma guy :P
[20:42:58] <funman> you are the pro wma guy then
[20:43:05] <funman> even better :)
[20:43:11] <av500> a pro! cool
[20:43:19] <mt> oops
[20:43:21] * mt hides
[20:43:51] <mru> does he gues well?
[20:43:53] <mru> +s
[20:44:11] <av500> shall we put him to the test?
[20:44:43] <mru> sure
[20:44:48] <mru> mt: I demand an answer
[20:44:56] <av500> it's not proday though....
[20:46:26] <mt> mru : http://upload.wikimedia.org/wikipedia/commons/5/56/Answer_to_Life.png
[20:46:49] <mt> This should answer everything
[20:46:54] <mru> wrong answer
[20:46:56] <mru> it's 54 now
[20:47:17] <mru> oh, and that gimp effect is kinda 90s
[20:47:41] <av500> mru: free and open source SW sometimes takes longer
[20:47:50] <mru> av500: no, that's bsd
[20:47:56] <mt> 54 is just a hype
[20:48:08] <funman> this 42 would look better in gif
[20:48:08] <mru> av500: and bsd is free _or_ open, not both
[20:48:19] * av500 throws a 26mhz crystal at mt
[20:48:24] <mt> everyone will eventually realize it actually _is_ 42
[20:49:02] <funman> http://www.google.fr/search?&q=26+%2B+26
[20:50:22] <av500> extreme way to hide
[20:50:27] <mt> haha
[20:53:26] <saintdev> peloverde: did you get a chance to look over my patch?
[20:54:13] <peloverde> briefly, I'm almost done with AACX :) then I can give it my full attention
[20:54:35] <saintdev> ok :)
[20:59:53] <CIA-92> ffmpeg: mru * r24685 /trunk/libavcodec/ (10 files in 2 dirs): Move cavs dsp functions to their own struct
[22:30:30] <CIA-92> ffmpeg: mru * r24686 /trunk/libavcodec/arm/asm-offsets.h: ARM: update struct offsets
[22:39:52] <kierank> Dark_Shikari: how hard would it be to add 4:2:2 to ffh264. let's say progressive only
[22:40:26] <mru> 42.2
[22:41:01] <Dark_Shikari> kierank: let's see
[22:41:05] <Dark_Shikari> on a scale from 1 to 10
[22:41:21] <mru> Dark_Shikari: you'll like a patch I just sent...
[22:41:36] <Dark_Shikari> mru: where
[22:41:40] <mru> ml
[22:41:43] <Dark_Shikari> I don't see it
[22:41:47] <Dark_Shikari> kierank: 6
[22:42:06] <kierank> hmmm harder than i thought
[22:42:18] <Dark_Shikari> mbaff makes everything harder
[22:42:26] <Dark_Shikari> I'd say $5k-$20k of work.
[22:43:05] <Dark_Shikari> mru: damnit now you'll break my patch
[22:43:25] <mru> what patch?
[22:43:30] <Dark_Shikari> where I strip lavc to the bone
[22:43:55] <Dark_Shikari> http://pastebin.com/4ch1tiaM
[22:44:01] <Dark_Shikari> aka "remove everything from every .o I don't like"
[22:44:17] <Dark_Shikari> and stub out almost every function that gets compiled with disable-everything
[22:44:24] <Dark_Shikari> and av_cold half of h264
[22:45:35] <mru> I don't see how removing some duplicated code prevents that
[22:46:07] <Dark_Shikari> patch conflict
[22:46:23] <mru> so update yours
[22:46:35] <Dark_Shikari> meh, I know, just sayin'
[22:46:44] <Dark_Shikari> you have a lot more to go
[22:46:52] <mru> one piece at a time
[22:46:53] <Dark_Shikari> there's hundreds and hundreds of k of junk in lavc
[22:46:55] <Dark_Shikari> --enable-small is a joke
[22:46:59] <Dark_Shikari> for example
[22:47:08] <Dark_Shikari> you notice all those codec description strings which are nulled if small, right?
[22:47:14] <Dark_Shikari> options.c has 40 KILOBYTES of strings that aren't.
[22:47:15] <mru> heh
[22:47:35] <peloverde> Early preview screenshot of AACX: http://i.imgur.com/WfVP8.png
[22:47:38] <Dark_Shikari> --enable-small should give me a 150 kilobyte lavc
[22:47:44] <Dark_Shikari> not a 1.5 megabyte lavc
[22:47:47] <Dark_Shikari> (when I enable one codec)
[22:47:57] <bcoudurier> I agree
[22:48:23] <Dark_Shikari> and because of the way options.c works, it's impossible to kill the options table without breaking lavc
[22:48:36] <mru> you could kill the help strings
[22:48:49] <Dark_Shikari> Got a regex to do that?
[22:52:41] <Dark_Shikari> GAH
[22:52:44] <Dark_Shikari> GAHAHSFHHDLAKSDFJLAKSDJF
[22:52:45] <Dark_Shikari> GCC
[22:52:48] <Dark_Shikari> http://pastebin.org/446518
[22:52:57] <Dark_Shikari> have you ever heard of loops?
[22:53:15] <Dark_Shikari> I think gcc is fully unrolling large memcpies
[22:53:17] <mru> loop unrolling man, it's the way of the future
[22:53:39] <peloverde> http://funroll-loops.info/
[22:53:52] <saintdev> peloverde: real men use -funroll-all-loops
[22:54:31] <Dark_Shikari> where does av_cold go?
[22:54:35] <Dark_Shikari> av_cold static int name?
[22:54:37] <Dark_Shikari> static av_cold int name?
[22:54:41] <Dark_Shikari> static int av_cold name?
[22:54:57] <mru> what's most common?
[22:55:16] <Dark_Shikari> Fun fact: gcc will inline av_cold functions, but they stay av_cold when it does so.
[22:55:43] <Dark_Shikari> Or maybe not.  Holy fuck it's still unrolling memcpies AGH
[22:55:48] <Dark_Shikari> Code size got 6K smaller though.
[22:56:02] <mru> why are you copying so much?
[22:56:08] <Dark_Shikari> memcpy(s->put_pixels_tab, s->vp8dsp.put_vp8_epel_pixels_tab, sizeof(s->put_pixels_tab));
[22:56:26] <Dark_Shikari> another 3K smaller if I make it stop inlining it (even though it's only called once)
[22:56:52] <Dark_Shikari> .... and it's still unrolling memcpies with av_cold.
[23:11:14] <kierank> so have you called mr. buffering yet Dark_Shikari?
[23:11:22] <Dark_Shikari> Yeah, it was a pretty normal conversation
[23:11:28] <Dark_Shikari> they're doing Yet Another Videoconferencing Startup
[23:11:34] <Dark_Shikari> who gets fucked by Everything Everyone Else Has Issues with
[23:11:37] <Dark_Shikari> in short, the three big issues:
[23:11:47] <Dark_Shikari> 1) Your endpoints are shit.  Their encoders are shit.  Their decoders are shit.
[23:12:01] <Dark_Shikari> 2) Many of your endpoints can't do compositing because you don't control them.  How do you display multiple people on your screen?
[23:12:23] <Dark_Shikari> 3) If you don't want to transcode every stream for every user, and a new person joins the conversation with limited bandwidth, do you lower the resolution/bitrate for everyone else too?
[23:12:34] <Dark_Shikari> 4) Flash sucks
[23:12:41] <mmu_man> +1
[23:12:52] <Dark_Shikari> of course, flash is better than almost everything in 1)
[23:12:56] <Dark_Shikari> so in many cases, you're wishing you had flash
[23:17:19] <bcoudurier> haha so true
[23:22:36] <CIA-92> ffmpeg: darkshikari * r24687 /trunk/libavcodec/ (vp8data.h vp8.c): VP8: slightly faster DCT coefficient probability update
[23:29:54] <_skal_paris_> TODO(later) => DONE>
[23:30:51] <Dark_Shikari> btw, that part of vp8 is completely braindead
[23:30:57] <Dark_Shikari> >1000 arithcoder decodes per frame
[23:31:07] <Dark_Shikari> almost all of which have near-zero probability
[23:31:16] <Dark_Shikari> and of course the probabilities are hardcoded in such a way that completely ignores the effect of resolution/bitrate
[23:31:26] <Dark_Shikari> (i.e. more bits per frame ---> worth spending more bits per frame on dct prob updates)
[23:34:48] <_skal_paris_> 1000 arithcoder = just to update dct probs?
[23:35:05] <Dark_Shikari> yes
[23:35:10] <Dark_Shikari> 3*8*4*11
[23:35:37] <Dark_Shikari> obligatory, every frame
[23:38:08] <_skal_paris_> we could probably use a selector bit on the bands
[23:38:47] <Dark_Shikari> how about doing a bit of RLE?
[23:38:55] <Dark_Shikari> you did it everywhere in VP3
[23:39:00] <Dark_Shikari> did On2 become allergic to RLE around the time of VP6?
[23:39:45] <J_Darnley> Dark_Shikari: Do you still want a regex for NULL_IF_CONFIG_SMALL in options.c
[23:40:16] <Dark_Shikari> J_Darnley: I don't really care that much no
[23:40:22] <_skal_paris_> RLE too, probably
[23:40:40] <Dark_Shikari> then again, vp8 is horribly designed with respect to minimizing the number of bits sent through the arithcoder
[23:40:44] <Dark_Shikari> no cbp
[23:40:44] <_skal_paris_> these 1000 calls are just a speed problem
[23:41:04] <Dark_Shikari> 24 EOB bits per coded MB
[23:41:07] <Dark_Shikari> for no reason
[23:42:05] <_skal_paris_> arith coder is taking care of aggregating the 'bits'
[23:42:15] <_skal_paris_> but yes, that's a lot of calls to rac_get
[23:42:17] <Dark_Shikari> yes, that's the point, it's a speed issue
[23:42:25] <Dark_Shikari> ironically, a good arithcoder should minimize its compression ratio
[23:42:32] <Dark_Shikari> that is, get the worst compression possible
[23:42:38] <Dark_Shikari> because if you have extremely good compression
[23:42:43] <Dark_Shikari> that means you were inefficient in the bits you gave to it
[23:42:58] <Dark_Shikari> and thus you are hurting your speed
[23:44:33] <_skal_paris_> btw: cat1 and cat2[] are fixed constnats
[23:44:36] <_skal_paris_> constants
[23:44:42] <Dark_Shikari> what about it?
[23:45:00] <_skal_paris_> could be hardcoded in decode_block_coeffs()
[23:45:08] <_skal_paris_> not sure it helps gcc, but
[23:45:21] <Dark_Shikari> gcc can mostly inline static const arrays.
[23:45:39] <_skal_paris_> the good days i guess
[23:55:39] <_skal_paris_> Dark: i've been trying to figure out how gcc organizes the branches
[23:55:45] <Dark_Shikari> However it feels like.
[23:55:47] <Dark_Shikari> Flip some coins.
[23:55:50] <Dark_Shikari> Add some unlikely() if you want.
[23:56:10] <_skal_paris_> well, it gets complicated with all these rac_get() inlined
[23:56:20] <Dark_Shikari> no it doesn't
[23:56:23] <Dark_Shikari> make an unlikely and likely version
[23:56:57] <_skal_paris_> anyhow: trees unrolled in decode_splitmvs() and decode_block_coeffs() are not in the same order
[23:57:11] <_skal_paris_> some might be better than the other
[23:57:46] <_skal_paris_> but it's not longer a 1:57am thing to try
[23:58:02] <_skal_paris_> so
[23:58:21] <_skal_zZzZZzz_> see you
[23:59:43] <J_Darnley> If anyone is interested: sed 's/^\({"[^"]\+"\), *"\([^"]\+\)"/\1, NULL_IF_CONFIG_SMALL("\2")/g'