Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2010

1 participants
29 discussions

IRC log for 2010-05-08
by irc＠mansr.com 09 May '10

09 May '10

[11:26:12] <BastyCDGS> greetz to all [11:26:17] <BastyCDGS> have good news [11:26:25] <BastyCDGS> no need for reverse engineering dctv IFF-ANIM [11:26:31] <BastyCDGS> found the specs for it in IFF-DEEP [11:27:03] <BastyCDGS> it's called tvdc there but I'm pretty sure it's the same ;) [11:27:51] <iive> \o/ [11:28:33] <mru> forgive if I'm not quite so excited [11:28:36] <mru> *me [11:29:22] <BastyCDGS> I would wonder anyway, as you aren't an amiga user and have probably not much usage for such stuff ;) [11:29:50] <mru> indeed, never had an amiga [11:29:55] <mru> never "got it" [11:30:40] <BastyCDGS> as I dunno of any law which forces you to have one, it should be fine ;) [11:31:15] <Compn> BastyCDGS : find the specs to vivo :) [11:33:25] <BastyCDGS> what's the problem with vivo? [11:35:26] <mru> vivo used to be a cheap swedish supermarket [11:35:50] <mru> got bought out by lidl or something [11:36:19] <Compn> vivo uses some non standard h263 which ffmpeg bails on iirc [11:37:38] <Compn> not to mention, porting the demuxer from mplayer [11:39:27] <BastyCDGS> you mean those with fourcc viv2? [11:43:46] <Kovensky> hm, shouldn't all codecs return decoded audio in the SMPTE channel order? [11:46:54] <BastyCDGS> btw, I found a copy of old DeluxePaint2 for DOS [11:46:55] <BastyCDGS> http://iaedq.tripod.com/ [11:47:00] <BastyCDGS> it creates IFF-PBM files [11:47:08] <BastyCDGS> should be good for testing ;) [11:47:42] <Kovensky> lol [11:55:25] <Kovensky> nvm @ previous question, I should read specs more [11:56:17] <BastyCDGS> hi jai :) [11:56:33] <BastyCDGS> have good news, I found the dctv anim specs in the IFF-DEEP stuff [11:56:44] <BastyCDGS> they're called tvdc here [12:12:48] <jai> hello BastyCDGS [12:12:56] <BastyCDGS> how are u? [12:17:27] <BastyCDGS> can someone tell what's the remaining problem with the heavy-opt-dp8 patch? [12:55:20] <thresh> OT: anyone tried vdpau on ion-based eeepc 1201n? [12:55:36] <twnqx> no, only on acer revo :X [14:14:46] <tiger108> hello there, i would need some support to install and configure qt-faststart, any one can help me??? [14:16:54] <tiger108> ??? [14:19:00] <tiger108> anyone? [14:41:52] <BastyCDGS> hey saste :) [14:41:56] <BastyCDGS> how are u? [16:01:39] <BastyCDGS> yeah [16:01:44] <BastyCDGS> peter sent me a IFF PBM raw [16:02:55] <BastyCDGS> and my latest HAM changes work with it ;) [16:10:57] <pJok> BastyCDGS, i haven't seen anyone working so furriously at something as you :) [16:11:28] <BastyCDGS> just want get it fine ;) [16:20:02] <_av500_> pJok: he needs to be fast before the last amiga decays forever.. [16:20:27] <BastyCDGS> av500, there's still UAE ;) [16:20:40] <BastyCDGS> even the C64 didn't die out totally yet [16:21:08] * twnqx still has two of them [16:21:12] <twnqx> sadly, no ffmpeg on them. [16:21:19] <BastyCDGS> ?? [16:21:24] <BastyCDGS> ffmpeg works fine on amiga [16:21:27] <twnqx> on the c64s [16:21:30] <BastyCDGS> ami_stuff uses ffmpeg on amiga [16:21:33] <BastyCDGS> oh ok [16:23:33] <BastyCDGS> av500, apart from this IFF ILBM can also be created by popular PC software [16:23:44] <BastyCDGS> dpaint2e adobe photoshop, etc. [16:24:01] <BastyCDGS> although photoshop has a bug writing IFF ILBM files in the byterun1 encoder [16:24:14] <BastyCDGS> it doesn't handle byterun1 byte -128 as nop [16:24:31] <BastyCDGS> btw, what's the best way to handle such stuff in ffmpeg? [16:24:37] <BastyCDGS> should I provide some config stuff? [16:24:53] <BastyCDGS> like byterun1=nop? [16:25:22] <CIA-7> ffmpeg: reimar * r23057 /trunk/libavcodec/avcodec.h: Another try for fixing/improving decode_video documentation. [16:32:54] <CIA-7> ffmpeg: reimar * r23058 /trunk/configure: [16:32:54] <CIA-7> ffmpeg: Remove hardcoded-tables hack for IA-64: with latest binutils that now actually [16:32:54] <CIA-7> ffmpeg: causes linking errors instead of avoiding them. [16:34:04] <pJok> twnqx, 8bit ffmpeg? [16:34:13] <twnqx> :> [16:34:32] <BastyCDGS> patch is welcome ;) [16:34:47] * mru has a long-term plan to put ffmpeg on C64x though [16:34:55] <mru> that's a TI DSP [16:35:11] <_av500_> after DNF? [16:35:19] <mru> no, week before [16:35:31] <BastyCDGS> DNF? [16:36:24] <BastyCDGS> hi BBB :) [16:36:28] <BBB> hola [16:36:32] <BBB> good set of patches you got there [16:36:45] <pJok> mru, TI DSP isn't a bad idea... but doesn't that mean that you'd have to code instead of troll? ;) [16:36:46] <BBB> it's a jungle again, I didn't pay attention for a few days and completely lost track :) [16:36:54] <BastyCDGS> yeah and I just got an IFF-PBM raw encoded [16:37:00] <BastyCDGS> so I could just test my HAM changes with it [16:37:04] <BastyCDGS> and it works like a charm ;) [16:37:10] <BastyCDGS> peter replied today [16:37:28] <mru> pJok: nobody pays me to troll [16:37:57] * BastyCDGS hastly revokes payment to mru *gg* [16:39:46] <BBB> mru: I'd love to pay you to troll xiph [16:39:47] <BastyCDGS> BBB, I just posted the latest patch for HAM today [16:39:48] * BBB runs [16:40:08] <pJok> BBB, doesn't mru troll xiph for free? [16:40:09] <_av500_> BBB: i think he has a discount for that... [16:40:24] * BBB loves discounts [16:40:25] <_av500_> buy one, troll one free [16:40:26] <mru> BBB: like the results so far? [16:40:39] <BBB> mru: couldn't have asked for more [16:40:46] * BBB brings out popcorn [16:40:54] <BBB> anything new on the shelves for today, sir? [16:41:04] * BastyCDGS adds some red whine to it [16:41:16] <BBB> wine? [16:41:25] <BBB> (whine == "nag") [16:41:30] * _av500_ hear a wining noise [16:41:35] <_av500_> s [16:41:35] <BBB> not completely, but sort of [16:41:44] <mru> BBB: maybe it was a pun [16:42:04] * BBB needs to get native english better [16:42:06] <BastyCDGS> yes why? [16:42:39] <BastyCDGS> BBB, didn't mean the win32 API wrapper here ;) [16:42:44] <mru> just remember, under the strict aliasing rules an english word may never alias a french word [16:43:02] <BBB> BastyCDGS: wine = the drink [16:43:12] <BastyCDGS> it's not even an alias in french, mru [16:43:13] <BBB> BastyCDGS: whine = to be a pain in the ass :) [16:43:16] <BastyCDGS> wine = vin [16:43:25] <BastyCDGS> vin rouge = red wine [16:43:34] * mru knows that much french [16:43:35] <_av500_> no, thats an editor. no? [16:44:18] <BBB> poke me if I have to review specific patches [16:44:18] <BBB> ot [16:44:27] <BBB> otherwise I'll be off thinking of random stuff to do next [16:44:37] <mru> you could RE something [16:44:45] <BastyCDGS> BBB: please review dp8 heavy opt patch and latest HAM ;) [16:45:56] <BastyCDGS> BBB, as said, the new HAM code also handles IFF PBM raw files correctly [16:46:04] <BastyCDGS> which was unclear until today [16:46:12] <BastyCDGS> btw, should I add the new files to the issues? [16:51:32] <BBB> no, don't triplicate patches [16:51:35] <BBB> it adds to the noise [16:51:45] <BBB> maybe start new threads once I've reviewed these [16:51:47] <BBB> too many patches [16:51:56] <BastyCDGS> I didn't mean the patches but the IFF files peter sent to me [16:51:57] <BBB> mru: trying to RE WVP2, but not much time right now [16:52:02] <BBB> oh [16:52:03] <BBB> no [16:52:11] <BBB> contact koth and add them to samples.mplayerhq.hu [16:52:52] <BastyCDGS> ok...will start new threads when review is done [16:53:24] <BastyCDGS> although the heavy opt dp8 patch should be fine...there haven't been any critics quite a long time ago on it... [16:53:50] <mru> that doesn't mean it's fine [16:53:57] <mru> it's only fine when someone says it is [16:54:08] <BastyCDGS> yes and that michael said already multiple times [16:54:30] <BastyCDGS> that he's fine with it [16:54:53] <BBB> I remember that one being ok, but I'll look and apply [16:54:55] <BBB> after lunch though [16:54:56] <BBB> brb [16:55:05] <BastyCDGS> ok bon appetit [16:56:34] <BastyCDGS> mru, there's still decodeplane32 there... [16:57:18] <BastyCDGS> I want to change this reading a whole byte at once too and using an 8-bit table for it [16:57:43] <BastyCDGS> by using 64-bits as in dp8 the lut has to be changed a little bit [16:58:03] <BastyCDGS> would you like to assist me in the final #define stuff for declaring the table, too? [16:58:25] <mru> if you post something too ugly I'll probably complain [17:00:48] <BastyCDGS> the #define stuff will probably be pretty ugly [17:01:13] <mru> well, watch and learn [17:01:45] <mru> every ffmpeg dev knows to embrace the macro [17:02:03] <mru> and if macros are good, then nested macros are better [17:02:17] <BastyCDGS> it's just that I'm not experienced with #define hackery [17:02:32] <mru> how did you ever get anything done? [17:02:36] <mru> copy&paste? [17:03:23] <BastyCDGS> actually, I did this sometimes, yes...but I needed only primitive #define's up to now... [17:03:39] <mru> but where's the fun in that [17:03:47] <mchinen> anyone on intel mac 10.5 and want to paste me their config flags/changes? --disable-optimizations --disable-mmx --disable-stripping has those GENERAL_REGS errors in libswscale for me [17:04:19] <mchinen> (trying to get a build that plays well with gdb) [17:04:39] <mru> forget gdb [17:05:15] <BastyCDGS> mru, I just didn't need that often enough to consider complex #define macros useful enough [17:05:26] <mru> fair enough [17:06:14] <mchinen> mru: what do you use? [17:06:19] <BastyCDGS> in TuComposer I backported that 100% asm stuff to C, since the original asm code doesn't need macros, too, I didn't create (except LE/BE stuff) for the C port, too... [17:06:26] <mru> mchinen: use for what? [17:06:37] <BastyCDGS> for debugging I suggest... [17:06:39] <mchinen> mru: for debugging [17:06:41] <mru> brain [17:08:11] <mchinen> okay, i'll look into getting one of those later :) [17:09:59] <spectral_hole> mchinen, valgrind is great for debugging crashes, much better than gdb [17:10:01] * BastyCDGS adds intuition to brain [17:10:44] <mru> spectral_hole: only when it's the kind of crash valgrind catches [17:10:57] <mchinen> spectral_hole: what about as a regular debugger for inspection? [17:11:08] <mru> why would you want that? [17:11:17] <mru> printf is much better [17:11:48] <spectral_hole> Mru, not necessarily: I've had valgrind pick up on bad behavior leading to assert failures and whatnot [17:11:52] <BastyCDGS> printf + objdump ;) [17:12:23] <BastyCDGS> at least that does very fine for me now... [17:13:40] <mchinen> I guess its just a convenience really. For multithreaded apps it can be a nice one though. [17:14:05] <mru> for multithreaded apps gdb is _completely_ useless [17:14:12] <BBB> mchinen: I use 10.6 [17:14:26] <BBB> mchinen: svn with regular configure compiles for me [17:14:29] <BBB> which file fails for you? [17:14:41] <mchinen> BBB: yeah regular configure works for me [17:15:14] <BBB> so which file fails? [17:15:15] <mchinen> BBB: but adding --disable-mmx --disable-stripping --disable-optimizations breaks libswscale/rgb2rgb.c [17:15:19] <BBB> ok [17:15:50] <BastyCDGS> mchinen, I'll test it here, too. now [17:15:51] <mchinen> there are some guys on windows that this fails for too, but the workaround looks involved so I thought to ask [17:15:52] <BastyCDGS> with x86 [17:15:55] <mchinen> yeah [17:16:07] <mchinen> but if no one uses gdb here maybe I should take a hint [17:16:19] <BBB> I use gdb all the time [17:16:34] <BBB> even with -O0, rgb2rgb builds fine for me [17:16:55] <BBB> hm, what's the complete compile line? [17:16:55] <mchinen> mru: (at least apple's) gdb lets you navigate through threads [17:17:13] <BBB> linux gdb also [17:17:15] <BastyCDGS> mchinen it does on ubuntu too [17:17:16] <BBB> thread 1 [17:17:17] <BBB> thread 2 [17:17:18] <BastyCDGS> yes [17:17:20] <mchinen> CClibswscale/rgb2rgb.o [17:17:20] <mchinen> libswscale/rgb2rgb_template.c: In function ‘rgb24toyv12_MMX’: [17:17:20] <mchinen> libswscale/rgb2rgb_template.c:2081: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ [17:17:20] <mchinen> make: *** [libswscale/rgb2rgb.o] Error 1 [17:17:21] <BBB> thread apply all .. [17:17:25] <mru> yes, but it totally messes up timing between threads [17:17:30] <BBB> mchinen: gmake V=1 [17:17:31] <mru> and that's usually where the problem is [17:18:06] <BBB> mchinen: I need the actual gcc command line :) [17:18:46] <mchinen> ah sorry [17:18:47] <mchinen> cc -I. -I"/Users/admin/svncheckouts/ffmpeg" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -DHAVE_AV_CONFIG_H -std=c99 -fPIC -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wundef -Wmissing-prototypes -fno-math-errno -fno-tree-vectorize -MMD -MF libswscale/rgb2rgb.d -MT libswscale/ [17:18:56] <mchinen> *thats gcc [17:19:31] <mchinen> sorry, my paste is messed up. [17:19:48] <BBB> send it to me by mail [17:19:53] <BBB> rsbultje at gmail com [17:21:04] <mchinen> okay, sent [17:21:45] <BBB> can reproduce now :) [17:21:51] <BastyCDGS> mchinen just compiled fine for me [17:22:34] <BBB> there's a -mdynamic-no-pic there on my compile [17:22:37] <BBB> which fixes it [17:22:39] <BBB> but shouldn't be there [17:22:42] <BBB> that's an ugly hack [17:22:44] <BBB> who added that? [17:23:18] <mchinen> hm, but it isn't in svn? [17:23:54] <mchinen> or you mean its in your configure? [17:24:25] <BBB> it's configure [17:24:32] <BBB> you probably use ./configure --enable-shared or so [17:24:41] <mchinen> yeah [17:24:42] <BBB> anyway, -mdynamic-no-pic fixes this [17:24:45] <BBB> not a great fix [17:25:03] <BBB> that breaks sharedlibs though, to my best understanding [17:25:11] <BastyCDGS> --enable-pic causes problems on x86 too [17:25:14] <BBB> but it'll work in gd [17:26:55] <BBB> let's see if I can read this myself [17:27:15] <BBB> reimar flamed me a while ago for not being able to fix this myself [17:27:19] <BBB> should be able to fix it now :) [17:27:28] <mchinen> okay thats fine so I'll just debug with static builds [17:33:12] <mchinen> yep, static build compiled fine, thanks! [17:33:34] <BBB> ok [17:33:52] * BBB would have to actually change the asm to change register constraints and is too lazy for taht :) [18:53:58] <j-b> ramiro: I love you... [18:55:18] <BastyCDGS> ohhhh...just as I love my jessica ;) [18:55:36] <mru> you have a jessica? [18:56:07] <BastyCDGS> mru, not yet but I'm working on that ;) [18:59:17] <DonDiego> can somebody point me at a 5.1 channel ac-3 sample? [18:59:32] * mru points at the nearest dvd [18:59:58] <BastyCDGS> well I know you can create surround by doing a right channel = ~left channel [19:00:18] <BastyCDGS> ~ being NOT [19:00:18] <jai> canyon.ac3 [19:00:27] <jai> or whatever is the actual name [19:00:39] <mru> Canyon-5.1-48khz-448kbit.ac3 [19:00:46] <jai> yep, that [19:00:52] <BastyCDGS> that's how I create surround with TuComposer [19:00:59] <mru> that's not surround [19:00:59] <DonDiego> oddly, mplayer tells me that it has 2 channels.. [19:01:03] <mru> that's phase shift [19:01:12] <mru> DonDiego: use ffmpeg [19:01:38] <BastyCDGS> yes but that does rch = ~lch does, create a surround signal [19:01:45] <BastyCDGS> see IT docs and specs [19:02:02] <mru> one cannot create what one does not have [19:02:03] <J_Darnley> What? How is 2 channel surround sound? [19:02:05] <jai> who uses impulsetracker anyway [19:02:10] <BastyCDGS> it's not true 3D surround [19:02:21] <DonDiego> mru: impossible, i need to benchmark mplayer.. [19:02:22] <mru> 2D surround is good enough for me [19:02:42] <BastyCDGS> because you can just tell the tracker if using surround subwoofer etc. sth. alike that [19:02:44] <mru> otherwise I'd have speakers mounted in the ceiling [19:03:05] <BastyCDGS> but it works [19:03:14] <mru> my downstairs neighbour doesn't like my subwoofer [19:03:22] <mru> it turns her ceiling into a speaker [19:03:26] <BastyCDGS> but converting that stuff to mono will just kill out any surround channels at well [19:03:40] <BastyCDGS> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFff [19:03:45] <BastyCDGS> 0xFF... [19:03:46] <mru> uck [19:04:15] <BastyCDGS> that causes pure silence when converts to mono [19:04:27] <mru> or if you stand in the wrong spot [19:04:53] <BastyCDGS> it's not the spot, it's really the mod handling this this way [19:05:25] <BastyCDGS> even if you have a 64ch module [19:05:36] <BastyCDGS> i.e. having 64 instruments playing sth. [19:05:50] <mru> you're confusing concepts [19:05:52] <BastyCDGS> if you tell just one of them using surround panning [19:05:59] <mru> 64 voices is not the same as 64-channel sound [19:06:03] <BastyCDGS> it's not hearable anymore if converted to mono [19:06:13] <mru> then it's not surround [19:06:15] <mru> but something else [19:06:15] <BastyCDGS> 64 voices == 64 channel [19:06:22] <mru> you are confused [19:06:36] <BastyCDGS> no I'm not, I just repeating IT specs [19:06:37] <mru> around here "channel" means physical speaker [19:07:09] <BastyCDGS> oh ok [19:07:15] <jai> voices == more like tracks [19:07:26] <BastyCDGS> in IT of course 64ch doesn't mean 64 physical channels ;) [19:07:28] <mru> tracks is a bad word to use too [19:07:32] <jai> :) [19:07:35] <mru> can be confused with tracks on a cd [19:07:46] <jai> i meant protools style tracks [19:07:47] <BastyCDGS> lol you're right [19:07:49] <BastyCDGS> BUT [19:07:54] <mru> voices is unambiguous [19:08:01] <BastyCDGS> the term channels was used in mods 20 years before CDs [19:08:08] <mru> mods are fringe [19:08:33] <BastyCDGS> mods are really a great way to encode music [19:08:36] <Dark_Shikari> even midi was more popular than mod =p [19:08:46] <BastyCDGS> MIDI is just a subset of MOD [19:08:49] <BastyCDGS> in fact [19:08:55] <BastyCDGS> MIDI = MOD + custom samples [19:09:16] <mru> not really [19:09:24] <mru> midi is much more than a file format [19:09:38] <mru> midi is a standard for connecting digital musical equipment [19:09:39] <jai> yes, kb wrote a nice article on that too [19:09:50] <BastyCDGS> EIDE is also more popular than SCSI, does it mean that EIDE is better? ;) [19:10:04] <mru> no, and neither is one a subset of the other [19:10:06] <BastyCDGS> mru, it isn't a standard really [19:10:11] * drv runs off to find some betamax tapes [19:10:20] <mru> depends on what you mean by standard [19:10:26] <BastyCDGS> unless you stick to 128 samples world-wide [19:10:27] <mru> every goddamn synth has it [19:10:41] <mru> that's standard to me [19:11:11] <BastyCDGS> just try to bring music which you sing yourself with your voice to midi... [19:11:15] <BastyCDGS> MOD? no problem [19:11:26] <BastyCDGS> you have to break the "MIDI"-standard for doing this [19:11:33] <mru> midi is not concerned with the actual samples [19:11:41] <BastyCDGS> yes and that's the problem! [19:11:57] <mru> midi only specifies the voice, time, and various parameters [19:12:02] <mru> like attack and decay [19:12:05] <BastyCDGS> in fact the actual samples are set in stone [19:12:15] <mru> yes and no [19:12:24] <mru> there are a number of predefined voices [19:12:31] <BastyCDGS> it doesn't specify only that [19:12:32] <mru> like piano etc [19:12:47] <mru> it doesn't specify exactly what the piano has to sound like [19:12:59] <mru> and it's often used with synths where you can build whatever sound you like [19:13:41] <mru> of course if you record the events, you'll only be able to play it back with the same settings [19:14:06] <Dark_Shikari> and midi brought us the 80s [19:14:15] <Dark_Shikari> so it's impossible to argue against. [19:14:29] <BastyCDGS> sorry lost connection [19:14:31] <mru> mod is a collection of voice samples and a midi-like list of instructions for playing them [19:14:33] <BastyCDGS> did I miss sth. [19:14:37] <Dark_Shikari> 03:14 <@Dark_Shikari> and midi brought us the 80s [19:14:37] <Dark_Shikari> 03:14 <@Dark_Shikari> so it's impossible to argue against. [19:14:47] <mchinen> some computer music guys used it for real time synthesis too [19:15:03] <mru> that's possible [19:15:12] <mru> it's still much narrower in scope than midi [19:15:14] <jai> BastyCDGS: we are just saying that midi is more than "general midi + soundbanks" [19:15:23] <mchinen> i mean midi [19:15:25] <BastyCDGS> jai, I know this [19:15:27] <jai> BastyCDGS: http://www.kebby.org/articles/fr08snd1.html [19:15:29] <Dark_Shikari> http://www.youtube.com/watch?v=A9ol1qLyYwE [19:15:32] <Dark_Shikari> \o/ midi \o/ [19:15:35] <mru> mchinen: of course [19:15:38] <BastyCDGS> but MIDI = 128 samples shared amonst all files [19:15:49] <mru> what files? [19:15:50] <BastyCDGS> MOD = each module has the samples it exactly needs [19:16:03] <jai> farbrausch's softsynth uses midi like notation [19:16:05] <BastyCDGS> .MID files [19:16:09] <jai> compresses quite well with kkrunchy [19:16:22] <BastyCDGS> ok [19:16:38] <BastyCDGS> try to create a song where some guy sings with voice with PLAIN midi [19:16:56] <mru> that's not a valid argument [19:17:03] <mru> try to play guitar music on a piano [19:17:04] <jai> BastyCDGS: though it can be done ... :) [19:17:20] <BastyCDGS> it it a valid argument, mru [19:17:22] <mru> midi means Musical Instrument Digital Interface [19:17:31] <mru> it's for connecting INSTRUMENTS [19:17:39] <mru> like connecting a keyboard to a synth [19:17:41] <BastyCDGS> yes, that's true [19:17:47] <mru> and then performing live [19:17:49] <mru> with a singer [19:18:01] <BastyCDGS> MOD = MIDI + custom samples [19:18:03] <BastyCDGS> ;) [19:18:10] <mru> recording midi events for later playback is just a side-effect [19:18:25] <mru> mod = midi subset + custom samples [19:18:25] <BastyCDGS> with MOD I have both worlds in once [19:18:44] <BastyCDGS> better: [19:18:47] <mru> go find a midi spec [19:18:57] <mru> there's way more to it than just rendering a song on a computer [19:18:59] <BastyCDGS> mod = (midi subset || mod subset) + custom samples [19:19:40] <BastyCDGS> duh? I investigated MOD/MIDI stuff over 10 years ago, I know what both advantages/disavantages are there [19:20:02] <mru> don't the proof by old age on me [19:20:12] <BastyCDGS> old age? [19:20:18] <mru> "over 10 years ago" [19:20:24] <jai> search the ml archives for context [19:20:26] <jai> ;) [19:20:33] <mru> as it happens, I was toying with a midi synth 20 years ago [19:20:41] <Dark_Shikari> http://encyclopediadramatica.com/At_least_100_years_ago [19:20:43] <mru> without a computer I might add [19:20:52] <BastyCDGS> or ok to be more mathematically: [19:20:56] <jai> mru: rs232? [19:21:02] <mru> jai: MIDI [19:21:02] <BastyCDGS> MOD = (MIDI UNION samples) [19:21:09] <mru> it's a 5-pin DIN plug iirc [19:21:22] <mru> MOD doesn't specify an electrical interface [19:21:27] <mru> so there [19:21:31] <BastyCDGS> MOD = MIDI & ~samples; [19:21:36] <BastyCDGS> sry [19:21:38] <jai> mru: but over a serial interface right? [19:21:42] <BastyCDGS> MIDI = MOD & ~samples [19:21:54] <mru> jai: I assume it's some kind of serial protocol [19:22:16] <BastyCDGS> mru, should a music format specifiy an external interface? [19:22:19] <mru> there's a clock somewhere in there too [19:22:23] <mru> BastyCDGS: no [19:22:31] <mru> but midi is more than a music file format [19:22:39] <BastyCDGS> I know [19:22:47] <BastyCDGS> I'm not saying that MIDI is bad [19:22:49] <mru> so wtf are you arguing about [19:23:11] <mru> http://www.midi.org/techspecs/index.php [19:23:24] <BastyCDGS> but being 100% MIDI compliant just means that all 10000000 songs on the world are based on 128 instruments [19:23:40] <BastyCDGS> didn't you ever wonder why almost everything from music industry sounds the same? [19:23:48] <BastyCDGS> it's not lack of creativity [19:23:54] <mru> did you ever see a band with more than 128 performers? [19:23:55] <twnqx> DonDiego: did you allow mplayer to use more than 2 channels? [19:24:03] <BastyCDGS> it's using the same standard 30 years ago with restriction to 128 samples [19:24:17] <BastyCDGS> yes, I did! mru [19:24:24] <BastyCDGS> but that's not MIDI anymore [19:24:37] <mru> a large symphony orchestra might have such numbers [19:24:41] <twnqx> *with more than 128 performers each playing different instruments or notes [19:24:45] <BastyCDGS> it's not MIDI as an 24bpp BMP file which was originally designed only for <= 8bpp [19:25:10] <BastyCDGS> remember, in MIDI samples are FIXED [19:25:32] <mru> next time you visit the 80s, watch a live band carefully [19:25:42] <mru> you should notice them tweaking the synths all the time [19:25:46] <BastyCDGS> you can of course assign a completely different sample to a midi instrument, but it isn't portable anymore [19:25:56] <mru> it was never meant to be [19:26:11] <BastyCDGS> yes and that's the problem ;) [19:26:18] <mru> not really [19:26:21] <twnqx> and you can load a 100kbyte or 1gbyte piano sample set [19:26:26] <twnqx> and it will sound totally different [19:26:28] <twnqx> but who cares? [19:26:29] <mru> it works fine for a musician who wants to create some music [19:26:30] <BastyCDGS> yes [19:26:38] <BastyCDGS> you can even play MIDI on OPL2/3 ;) [19:26:43] <mru> well... [19:26:53] <mru> that's a simple fm synth [19:26:58] * twnqx bought a terratec 32/96 soundcard last year [19:27:05] <twnqx> just for the mpu401 sample roms [19:27:20] <BastyCDGS> AWE32 has an huge advantage upon MIDI playback ;) [19:27:20] <twnqx> just great to play duke nukem 3d on it :P [19:27:30] <mru> midi was designed to be used by musicians [19:27:33] <mru> not by consumers [19:28:02] <BastyCDGS> yeah, like MOD ;) [19:28:09] <mru> errr, no [19:28:18] <mru> mod is the distribution format [19:28:22] <mru> midi is not [19:28:29] <twnqx> mod doesn't even allow panning :> [19:28:39] <BastyCDGS> twnqx LOL [19:28:40] <mru> you're arguing that a cd player is better than a piano [19:28:46] <mru> because the piano can only play piano music [19:28:52] <BastyCDGS> this is untrue twnqx [19:29:04] <mru> there are many different mod formats too [19:29:09] <BastyCDGS> ImpulseTracker supports 256 bit pan + surround sound pan [19:29:10] <mru> some with more features than others [19:29:17] <twnqx> rally? last i checked you needed it, s3m or the like for .mod [19:29:29] <twnqx> err for pannig [19:29:42] <twnqx> impulse tracker uses .it files :P [19:30:14] <BastyCDGS> mru, yes there are tons of MOD formats around [19:30:22] <BastyCDGS> and all being not good documented [19:30:34] <BastyCDGS> that's why I was developing TuComposer ;) [19:30:47] <BastyCDGS> TuComposer should unifiy all those like as MIDI ;) [19:31:10] <BastyCDGS> funny...really funny... [19:31:36] <BastyCDGS> you're just complaing that I was solving 10 years ago with TuComposer (that's even the only reason I invented it ;-)) [19:32:24] <BastyCDGS> and that is the reason I want to use TuComposer's engine in FFmpeg for playback modules [19:32:50] <BastyCDGS> because I have adressed all your issues 10 years ago [19:32:54] <mru> I'm not complaining [19:33:05] <BastyCDGS> I know the bad things about mod files [19:33:19] <BastyCDGS> it's exactly that what you're complaing right now [19:33:26] <mru> I'm not complaining [19:33:26] <BastyCDGS> non-standard conforming etc. [19:33:39] <mru> I couldn't care less about mod files [19:34:21] <BastyCDGS> mru, I don't wonder about this really... [19:34:55] <BastyCDGS> like you coudn't care less about any amiga stuff, right? ;) [19:35:00] <BastyCDGS> that's okay for me... [19:35:04] <mru> I had a couple of friends who'd spend all day in front of their amigas playing mods [19:35:09] <mru> I never saw the point [19:35:13] <mru> I had a cd player [19:35:48] <BastyCDGS> well just try to get 18096 songs on a CD with CDDA ;) [19:36:18] <mru> I'll rather have just one album of real music than a lifetime of mashed-up mods [19:36:19] <drv> 18096 songs of dubious quality [19:36:20] <BastyCDGS> 18096 that's the number of MODs (i.e. totally different songs) on the MODs anthology [19:36:46] <BastyCDGS> why dubious quality? [19:36:48] <ramiro> j-b: hm, what did I do this time? [19:36:55] <drv> there are a few really god mods, and many more mediocre ones [19:36:58] <mru> ramiro: he found your old liborc flame [19:37:12] <drv> s/god/good/ :) [19:37:21] <BastyCDGS> god == good ;) [19:37:50] <mru> a skilled composer can of course create a good song using the mod features [19:38:03] <ramiro> oh =) [19:38:13] <BastyCDGS> yes, almost all mod trackers can deal with MIDI directly [19:38:21] <j-b> ramiro: those people don't seem to understand what Xcompilation is [19:38:22] <BastyCDGS> i.e. you can combine them perfectly [19:38:23] <ramiro> it's still not fixed though. lib<whatever the name is now> doesn't work for win64 [19:38:27] <BastyCDGS> but not the other way around [19:38:31] <mru> can they take input from my physical keyboard in realtime? [19:38:38] <BastyCDGS> yes [19:38:41] <BastyCDGS> they can [19:38:46] <mru> I mean a piano-like thing [19:38:51] <mru> connected to the midi port [19:38:55] <BastyCDGS> you can even use the original midi instrument or a custom sampled one [19:38:59] <mru> (no, I don't actually have one) [19:39:00] <ramiro> j-b: he seriously considers it "not a bug" that a build system should silently fail on cross-compilation [19:39:07] <drv> some trackers do have midi input [19:39:28] <j-b> ramiro: You _really_ should read their autogen.sh script [19:39:29] <mru> and can they output over the midi port to control a real synth? [19:39:32] <BastyCDGS> drv, ehmm which one? I haven't seen any tracker for over 10 years ago which can't do this [19:39:38] <BastyCDGS> IT can handle MIDI perfectly [19:39:51] <BastyCDGS> yes mru, they can [19:39:55] <BastyCDGS> IT can do this [19:39:55] <drv> i think modplug can [19:40:03] <drv> but it's been a long time since i messed with it [19:40:33] <BastyCDGS> IT was able to do this in 1998 [19:40:46] <BastyCDGS> on a 486 with 64 channels [19:40:51] <BastyCDGS> with max. quality [19:40:54] <mru> eh, wasn't mod pretty dead by then? [19:40:58] <BastyCDGS> MIDI + sampled [19:41:15] <BastyCDGS> MIDI is still the 1st standard in the demo scene [19:41:22] <BastyCDGS> even many games use it [19:41:38] <BastyCDGS> oops [19:41:42] <drv> well, the demo scene and the real world seldom intersect [19:41:43] <j-b> ramiro: depending on the result of whoami, the configuration is different... [19:41:47] <BastyCDGS> meant MOD is still the 1st standard... [19:41:52] <Dark_Shikari> games still use it? I haven't seen it used in games for ages [19:42:00] <Dark_Shikari> the last game I saw that used midi was the older touhou games [19:42:01] <drv> most gams just use vorbis or something these days [19:42:06] <Dark_Shikari> and those are indie, made by a PC-98-age guy [19:42:08] <ramiro> j-b: ah, that's liboil, right? I remember seeing that some time ago [19:42:13] <ramiro> sad, very sad. [19:42:14] <BastyCDGS> dark_shiraki: was writing wrong meant MODs sry [19:42:16] <Dark_Shikari> and even he stopped releasing midi versions of his tracks [19:42:19] <Dark_Shikari> BastyCDGS: never seen a game use mods ever [19:42:23] <Dark_Shikari> Not a modern game at least [19:42:28] <Dark_Shikari> where "modern" means "since windows 95" [19:42:48] <BastyCDGS> apogee games [19:43:03] <mru> doesn't sound modern [19:43:14] <ramiro> not to mention that it has --disable-static forced in autogen.sh [19:43:25] <aaronl_> there's a pretty cool platformer that came out recently called vvvvvv [19:43:29] <aaronl_> and it has some great chiptunes [19:43:37] <ramiro> he "not a bug"d my bug report that it didn't build statically [19:43:44] <aaronl_> but i was disappointed to find out that they're all prerendered [19:43:46] <ramiro> even though configure doesn't fail [19:43:49] <j-b> ramiro: no, schroedniger too [19:43:50] <aaronl_> what has the world come to? :( [19:44:19] <BastyCDGS> mru, yes I know that apogee was morely known to titles like Duke Nukem 3D and alike (although DN3D used MIDI nod MOD) [19:44:30] <twnqx> <3 [19:44:43] <BastyCDGS> but there were lots of games from them during this time which used MOD [19:44:51] <twnqx> i payed >300DM for my soundcard in those days, for the hardware wavetable... [19:44:52] <mru> eh, duke nukem was 3drealms [19:45:13] <BastyCDGS> apogee bought 3drealms [19:45:13] <twnqx> and i bought it again, used, for 2€ :X [19:45:26] <BastyCDGS> if i remember correct at least [19:45:28] <ramiro> twnqx: what's a DM? [19:45:33] <BastyCDGS> all that's been long time ago [19:45:34] <twnqx> german mark. [19:45:42] <BastyCDGS> maybe I'm remembering sth. wrong [19:46:47] <BastyCDGS> but, MIDI isn't really cheap, instead it's really expensive [19:47:13] <mru> there's cheap midi gear and expensive midi gear [19:47:19] <BBB> ok, time for review [19:47:22] <BastyCDGS> I read countless of interviews with DJs / etc. who had to pay much much money for getting all the software together just to compose [19:47:25] <BastyCDGS> >= 10000 € [19:47:31] <BBB> where's the patch? [19:47:37] <BastyCDGS> with mod you'll get the same with a usual 486 PC [19:47:44] <mru> I don't think so [19:48:01] <mru> midi is just what ties it all together [19:48:23] <BastyCDGS> ok, then tell my why such software like adobe audition (former CoolEdit) requires an Pentium 3/4 for 8ch realtime mixing while IT can do 64ch on 486SX-25? [19:48:25] <mru> a good keyboard or a good synth is still expensive [19:48:30] <ramiro> BastyCDGS: were you part of multimedia mike's blog's flame war on trackers? [19:49:04] <BBB> mru: any progress on making the sine table generator a separate file? [19:49:06] <mru> I bet the mixing quality of the former is far better than the latter [19:49:17] <mru> BBB: was I working on that? [19:49:27] <BastyCDGS> I mean realtime mixing for playback [19:49:28] <BBB> one of the two of us should [19:49:32] <BBB> and it's not me [19:49:42] <BastyCDGS> IT had way better algorithms for disc recordings [19:49:42] <BBB> so I freely volunteered you ;) [19:49:49] <mru> well, a pro DJ might have slightly higher standards than a basement kid with an amiga [19:50:03] <BastyCDGS> I'm talking of PC tracker software [19:50:06] <BastyCDGS> not of amiga [19:50:11] <mru> kid with a pc then [19:50:13] <BastyCDGS> the amiga was just the start of this [19:50:29] <mru> and the middle and most of the end [19:50:35] <BastyCDGS> IT was never available on amiga [19:50:40] <mru> it only came to pc because they stopped making amigas [19:50:45] <twnqx> neither s3m or ft2, right? [19:50:45] <BastyCDGS> and most amiga trackers could just handle 4ch at maximum [19:50:49] <mru> I mean mod stuff in general [19:51:06] <mru> and anything else of the amiga mindset [19:51:13] <BastyCDGS> twnqx, yes the trackers itself were never available to amiga [19:51:26] <BastyCDGS> but amiga had (although bad) players for 'em [19:51:41] <jai> ft2 sucked on my 386 [19:51:48] <twnqx> mru: in those days you couldn't handle 20MB .mp3 [19:52:13] <twnqx> so if you wanted decent music, tracked was the only real way [19:52:19] <mru> or play CDs [19:52:24] <twnqx> err [19:52:32] <twnqx> i meant as background music in games, etc [19:52:36] <BastyCDGS> mru, you're talking of playback, we're talking of recording [19:52:39] <jai> ut used mods iirc [19:52:44] <drv> some PC games used CD as background music ;) [19:52:45] <BastyCDGS> yes UT did [19:52:45] <mru> twnqx: games often used CD music actually [19:52:50] <BastyCDGS> and a lot of other games too [19:52:56] <twnqx> few [19:53:10] <twnqx> also there where days before cd-roms... [19:53:14] <twnqx> were* [19:53:24] * mru remembers when cdroms attached to the soundblaster [19:53:44] * twnqx remember QIC80 streamers connected in parallel to floppy drives [19:53:44] <BastyCDGS> even in the CD-ROM time they used mods...the CDDA tracks were MODs pretty often [19:53:59] <BastyCDGS> just they were using 16-bit samples like S3M/XM/IT offered [19:54:16] <BastyCDGS> mru, I had a CD-ROM drive needed to attach on SB ;) [19:54:20] <BastyCDGS> I know all this ;) [19:54:23] <mru> not the ones where you could pop the game disc in a cd player, skip to track 2 and hear the game music [19:54:47] <BastyCDGS> mru, you didn't need that even on mod [19:54:50] <jai> i still have the nascar racing cdrom with a bunch of skidrow tracks :) [19:55:05] <BastyCDGS> you can change to 10000 different songs even without switching CDs ;) [19:56:03] <BastyCDGS> hey guys [19:56:18] <BastyCDGS> please DO NOT mix damn old MOD format from 1980 with 2010 module formats [19:56:18] <mru> nevertheless, midi was designed as tool for musicians [19:56:23] <BastyCDGS> or even 1998 like IT [19:56:49] <drv> who needs mods in 2010? we have terabyte hard disks, gigabytes of RAM, megabit/s internet... [19:56:53] <twnqx> then don't call it mod, 'cause mod is just that old format from amiga [19:56:58] <BastyCDGS> mru, as said: MIDI = MOD + samples [19:57:02] <mru> for live performance or recording onto studio tapes [19:57:19] <jai> drv: tracked music is still very important [19:57:20] <twnqx> drv: and they all sound like crap compared to some nice c64 chiptunes. [19:57:22] <BastyCDGS> twnqx you're right, but I did just for sake of less complexity [19:57:32] <mru> I know what midi is, and it's got very little to do with mod [19:57:32] <BastyCDGS> do you want me writing each time: [19:57:43] <BastyCDGS> MOD/S3m/XM/IT/669/MMM/etc.? [19:57:54] <mru> do you play an instrument? do you know any real musicians? [19:57:55] <BastyCDGS> I just collect them to mod [19:58:19] <BastyCDGS> me? I do tracking, yes. [19:58:23] <twnqx> i collect them to tracked music [19:58:28] <mru> I mean instruments [19:58:35] <twnqx> but whatever :] [19:58:38] <mru> the kind you pluck, strike, etc [19:58:59] <BastyCDGS> partially I do, but it's more basic stuff like piano [19:59:04] <jai> i do, and i use a MIDI controller too ;) [19:59:36] <jai> BastyCDGS: again, general midi is the spec which defines soundbanks, and is not to be confused with the original midi spec [20:00:01] <BastyCDGS> jai, I know this, but the soundbanks are pressed in stone [20:00:07] <mru> I'm talking about the one that has phycical cables [20:00:17] <mru> plugging into physical machines [20:00:18] <BastyCDGS> i.e. sample 0x8C is always a piano for example. [20:00:21] <jai> BastyCDGS: mru is not referring to general midi [20:00:26] <mru> that people press keys on to produce notes [20:00:34] <jai> i think... [20:01:12] <BastyCDGS> yes and that causes MIDI all the trouble with it, there are samples defined from 0-255 [20:01:22] <BastyCDGS> but they're all set in stone by official standard [20:01:41] <BastyCDGS> changing from this causes all incompatibilities you could think off [20:01:50] <twnqx> so? [20:01:58] <twnqx> what exactly is your point? [20:02:12] <BastyCDGS> that MOD was designed to solve these issues [20:02:15] <twnqx> no [20:02:28] <BBB> BastyCDGS: the 16-bit rounding was applied right? [20:02:28] <BastyCDGS> just attach the stuff you need custom to your song file and it's fine. [20:02:56] <twnqx> both have very different foundations, as mru pointed out [20:03:03] <BastyCDGS> BBB, dunno understand...what you mean with 16-bit rounding here? [20:03:20] <BBB> I think carl eugen applied it [20:03:22] <BBB> word-alignment [20:03:29] <twnqx> .mid was never (really) meant to be exchanged, but for local storage in your setup [20:03:31] <mru> general midi is a standardised set of voices and whatnot [20:03:38] <BastyCDGS> oh ok word-alignment patch was applied already [20:03:49] <BastyCDGS> but I was talking about dp8 heavy opt patch [20:03:57] <BastyCDGS> i.e. the one doing AV_WN64A etc. [20:04:34] <BastyCDGS> yes twnqx and that is what mod differs, it is designed esp. for exchange ;) [20:04:48] <BastyCDGS> but even here lots of mod tracker writers fail [20:05:00] <BastyCDGS> they don't document their formats as they should be [20:05:13] <BastyCDGS> and so every player outputs different stuff as it should [20:05:27] <BastyCDGS> and then I had enough of this and TuComposer was born [20:05:36] <BastyCDGS> (The united Composer = TuComposer) [20:05:48] <mru> mod is a midi-inspired distribution format for electronic music [20:06:03] <mru> midi is a studio tool [20:06:19] <mru> or stage as the case may be [20:06:58] <BastyCDGS> both are studio tools indeed ;) [20:07:12] <mru> those who have only encountered midi as annoying background music on web pages c 1996 don't know what it really is [20:07:16] <BastyCDGS> mods are much more free in doing music [20:07:23] <mru> eh? [20:07:25] <BastyCDGS> it's like freedom compared from windows to linux [20:07:29] <ramiro> BastyCDGS: you didn't answer, but this is the post I was talking about http://multimedia.cx/eggs/renoise-xrns/ [20:07:29] <mru> bollox [20:08:31] <BastyCDGS> mru, as I already said [20:08:40] <BastyCDGS> MOD = MID + free samples [20:08:48] <BastyCDGS> attached to file [20:09:00] <ramiro> free samples like the ones we get on the market? [20:09:01] <mru> free? wtf? [20:09:06] <BastyCDGS> FREE samples [20:09:19] <BastyCDGS> this includes these you record with your own micros [20:09:27] <ramiro> free samples suck. the package is always much smaller than the ones they sell on the store. [20:09:29] <BastyCDGS> .WAV/.FLAC/.VOC/etc. [20:09:33] <mru> I could make a mod file and forbid extraction and reuse of the samples [20:09:36] <BastyCDGS> anything you want...ANYTHING! [20:09:48] <BastyCDGS> not just stuck to a 128 set [20:10:06] <ramiro> BastyCDGS: anything really? can you put goatse in it? [20:10:15] <drv> goatse for your ears [20:10:16] <BastyCDGS> YES! it's PCM!!! [20:10:24] <mru> goatse is jpeg... [20:10:32] <BastyCDGS> of course you can produce shice with PCM recording [20:10:41] <BastyCDGS> but is that a fault of MOD standard or the recorder? [20:11:17] <mru> I'm not saying MOD is bad at what it does [20:11:29] <mru> but calling it "better" than MIDI is senseless [20:11:31] <BastyCDGS> oh then I probably got you wrong [20:11:37] <mru> they serve different purposes [20:11:44] <BastyCDGS> yes they indeed do ;) [20:12:04] <mru> like I said, you can't claim a CD player is better than a piano because the piano can only play one kind of music [20:12:07] <BastyCDGS> that's what I'm try to tell you about an hour ;) [20:12:15] <BastyCDGS> I never did this [20:12:50] <mru> no, but close [20:12:56] <BastyCDGS> I just was comparing a fixed 128 samples format to any samples format [20:13:04] <mru> midi isn't fixed [20:13:08] <mru> it's unspecified [20:13:15] <mru> you can program your synth as you see fit [20:13:22] <BastyCDGS> yes that's what my problems with it are actually ;) [20:13:29] <mru> no, that's not a problem [20:13:34] <mru> it's not an interchange format [20:13:41] <_av500_> gee [20:13:54] <BastyCDGS> oh I remember times where it was told MIDI is just that ;) [20:13:55] <mru> if you stick the general midi constraints, yes you get some interoperability [20:14:05] <mru> *stick to [20:14:17] <BastyCDGS> I understand you, no panic ;) [20:14:32] <mru> so why do you keep telling me that mod is better than midi [20:14:34] <mru> ? [20:14:47] <BastyCDGS> because mathematically midi is a subset of mod [20:14:47] <mru> cars are better than apples too? [20:15:02] <mru> I'd argue the opposite [20:15:09] <BastyCDGS> i.e. you can represent EVERYTHING in midi what is possible with mod but not the way other around [20:15:21] <mru> that makes midi a superset [20:16:04] <mru> a mod file is a sequence of midi events + voice samples [20:16:10] <mru> or midi-like [20:16:12] <BastyCDGS> I'm talking about pure note data [20:16:25] <BastyCDGS> in these parts MIDI and MOD are on same level [20:16:45] <mru> I don't know the exact details on either so I can't argue about that [20:16:51] <BastyCDGS> but where MOD is far ahead is that you can reprogram the samples to anything you want [20:16:58] <mru> but the MIDI 1.0 spec says nothing at all about voices [20:17:32] * _av500_ hears voices in his head, does not know the spec though [20:17:55] <BastyCDGS> whenever I want to sing something I just take a quality microphone record it i.e. with audacity [20:17:59] <mru> you're expected to program the voices yourself [20:18:03] <BastyCDGS> and add that just to a MOD [20:18:15] <BastyCDGS> this isn't possible with MOD without breaking MIDI standard [20:18:21] <mru> the noly problem is if you want to distribute your work _as raw midi data_ [20:18:34] <_av500_> you have to ship the synth too [20:18:40] <mru> and that's what mod does [20:18:44] <BastyCDGS> it's not a problem, with MOD I can do this without worrying anything [20:18:55] <jai> yes, smf+softsynth could be used for interchange [20:19:12] <mru> or a real synth, if the recipient has the same model [20:19:21] <jai> sure [20:19:33] <_av500_> BastyCDGS: in fact you cant, unless you ship a sample of every note played [20:19:53] <_av500_> as the synth defines the sound in the end [20:20:01] <BastyCDGS> av500, that's why I use mod instead ;) [20:20:22] <_av500_> thats like shipping the pcm then [20:20:29] <BastyCDGS> I just ship the same stuff as I would with MIDI just the custom samples I created attached with it ;) [20:20:36] <BastyCDGS> no it's not! [20:20:39] <_av500_> but that is one sample per note [20:20:46] <BastyCDGS> no it isn't [20:21:06] <mru> "it isn't" or "it's not"... make up your mind [20:21:22] <BastyCDGS> you can play ANY sample with ANY note with an mod [20:21:36] <mru> only the samples included in the file [20:21:44] <BastyCDGS> you don't have to recreate your samples for each different note you play! [20:21:53] <_av500_> BastyCDGS: yes, but the synth coudl [20:22:02] <_av500_> therefore midi does not define it [20:22:12] <ramiro> this channel has been seeing a lot of caps lately... [20:22:47] <_av500_> BastyCDGS: i could have that totally cool song with my random note synth [20:22:49] <BastyCDGS> av500: sorry didn't understand you right now, what you mean by not defining it? [20:23:07] <BastyCDGS> av500: perfectly possible with mods [20:23:08] <_av500_> as i said, note c does not have to be a slower d [20:23:23] <BastyCDGS> av500: this isn't with mods... [20:23:55] <mru> a synth is allowed to behave in all sorts of non-linear ways [20:24:15] <BastyCDGS> formula: f = base_freq * pow(transpose,1/12); [20:24:15] <_av500_> and to put it in a mod file you need to toall characterise it [20:24:23] <_av500_> totally [20:24:27] <_av500_> BastyCDGS: no [20:24:39] <_av500_> that assumes each sample is the same [20:24:46] <_av500_> just faster/slower [20:24:48] <_av500_> how lame [20:24:48] <BastyCDGS> nope [20:24:48] <mru> a traditional synth is a piece complex analogue electronics [20:25:00] <BastyCDGS> base_freq is sampling rate of original sample [20:25:11] <_av500_> yes, one per note [20:25:37] <BastyCDGS> av500: I know there are problems with mod formats ;) [20:25:42] <mru> there are many more parameters too [20:25:46] <BastyCDGS> esp. these you're mentioning here [20:26:01] <BastyCDGS> and that's just why I invented TuComposer [20:26:03] <_av500_> and i even dont know what .mod is :) [20:26:09] <mru> most importantly velocity [20:26:13] <_av500_> until i read this backlog [20:26:37] <_av500_> ffmpeg-devel took my evening away... [20:26:52] <BastyCDGS> btw, TuComposer can play much more notes per channel than MIDI [20:27:01] <BastyCDGS> it supports NNAs etc. [20:27:13] <_av500_> mru: dont forget the voltage instability in that small shady club... [20:27:20] <BastyCDGS> NNA = New Note Action [20:27:37] <BastyCDGS> this means that the composer can decide what happens exactly when a new note is being played [20:27:47] <BastyCDGS> normally old notes are simply being cut [20:27:50] <mru> mod is basically a patch mixer [20:28:10] <mru> you can have midi without a single sound patch [20:28:15] <BastyCDGS> with NNA you can tell the tracker what do do exactly if you're playing a new note on the same channel what happens with old note [20:28:29] <mru> as is the case with an analogue synth [20:28:32] <mru> or a digital one [20:28:53] <BastyCDGS> there's NNA cut (old behaviour), NNA off (keyoff), NNA fade (trigger fadeout) and NNA continue (just continue playing note) [20:28:54] <mru> or in the extreme, a real, electrically actuated piano [20:29:08] <BastyCDGS> with TuComposer there's even a NNA synth [20:29:22] <mru> I bet tucomposer doesn't contain an actual piano [20:29:32] <BastyCDGS> i.e. trigger a synth assembler code on this where you can exactly decide what to happen on assembly language level [20:29:47] <_av500_> oh, a vm [20:29:59] <_av500_> you send java sound event :) [20:30:10] <BastyCDGS> yes it's a kind of VM but such fast it even can do larger programs on 68040/25 [20:30:19] <BastyCDGS> (which equals to 486SX_25) [20:30:57] <mru> but can I enter the schematics for a moog synth and have the right sound pop out? [20:31:04] <BastyCDGS> my "VM" is fast enough to do 64ch realtime mixing on CD quality on an old 486 [20:31:51] <BastyCDGS> mru, what do you mean with moog synth exactly? [20:31:56] <mru> rotfl [20:32:02] <BastyCDGS> as said it's an real assembler [20:32:14] <ramiro> geez, you play with electronic music and you don't know what a moog is? [20:32:18] <BastyCDGS> so as long as your plans are turing possible it should be possible ;) [20:32:22] <_av500_> lol [20:32:46] <mru> reminds me of the guy who'd never "experienced the halting problem" [20:32:57] <_av500_> brookie [20:33:03] <_av500_> ftw [20:33:16] <BastyCDGS> who tells you I'm not knowing this? maybe I just know this under a different name, possibly? [20:33:29] <mru> not likely [20:34:02] <mru> http://www.vintagesynth.com/moog/moog.php [20:34:03] <BastyCDGS> btw, there's no halting problem, actually, just put off the power supply and everything will halt: 100% ;) [20:34:11] <mru> there you go, bit of history [20:34:39] <mru> of course, those didn't have midi interfaces [20:34:52] <mru> but that could be easily added [20:35:15] <BastyCDGS> just looked at your side, and of course you can do this with tucomposer's synth assembler [20:35:16] <mru> with a uC and some DACs [20:35:24] <BastyCDGS> it will be just some lot of code, though [20:35:43] <BastyCDGS> remember it's a complete assembly language like x86 / m68k [20:35:46] <mru> realtime simulation of a non-linear circuit [20:35:48] <mru> I don't think so [20:36:22] <mru> and I don't even play music.... [20:36:25] <_av500_> mru: not even if we overclock that 486? [20:36:33] <ramiro> lol [20:37:19] <BastyCDGS> well go here for a small example: [20:37:20] <BastyCDGS> http://forum.cdgs-crew.com/viewtopic.php?t=16 [20:37:35] <BastyCDGS> it shows you of capabilities of tucomposer's synth asm [20:37:47] <BastyCDGS> and I already use it for playback of FC13/14 modules [20:38:30] <BastyCDGS> av500: overclocking? of the 486? why? [20:38:41] <_av500_> nvm [20:38:45] <BastyCDGS> it isn't needed for high quality sound output [20:39:27] <BBB> was the dp8 optimization applied? [20:39:38] <BastyCDGS> just because we today know shice soft like adobe stuff doesn't mean we can get hq sound output on old processors ;) [20:39:49] <BastyCDGS> BBB, not yet :( [20:39:52] <BBB> hm [20:39:53] <BBB> why? [20:40:06] <BBB> I thought that one was well-tested? [20:40:06] <BastyCDGS> I dunno, Carl Eugen didn't say anything why [20:40:16] <BBB> he didn't reply in that thread [20:40:22] <BBB> michael and I both ok'ed it [20:40:31] <BastyCDGS> yes that wondered me too [20:40:39] <BBB> did you test that on BE/LE? [20:40:43] <BastyCDGS> yes I did [20:40:48] <BastyCDGS> thanks to mru ;) [20:40:54] <BastyCDGS> he did provide an BE machine [20:40:58] <BastyCDGS> and I tested it there [20:41:33] <BastyCDGS> after all the BE/LE issues was the reason he did a patch for endianess constants [20:41:36] <BBB> I think it's because your last message in the thread sayd: [20:41:37] <BastyCDGS> for tables [20:41:41] <BBB> "Could the revert this patch, please? [20:41:42] <BBB> I just found a serious bug in the original code, which I believe which [20:41:42] <BBB> is the cause that some IFF images (like MRLake.iff) are displayed [20:41:42] <BBB> partially incorrect." [20:41:43] <_av500_> bobby? [20:41:56] <BBB> you didn'ty reply after, so we assume you're still working on it [20:42:02] <BastyCDGS> oh... [20:42:09] <BBB> better fix that :) [20:42:10] <BastyCDGS> could be possible [20:42:21] <BastyCDGS> it's been done since some time ;) [20:42:33] <CIA-7> ffmpeg: michael * r23059 /trunk/libavutil/ (log.c log.h avutil.h): Add means to adjust the log level per context. [20:42:37] <BastyCDGS> I was writing this when I wasn't sure for myself what is was [20:43:05] <BastyCDGS> but the latest patch to git/svn shows that it's ok [20:43:14] <BBB> hm [20:43:16] <BBB> why is it inline? [20:43:17] <BastyCDGS> in fact we do just divide the loop by 8 [20:43:25] <BastyCDGS> and do an WN64A [20:43:58] <BastyCDGS> I was doing this inline on the first attempts because it really made a difference upon that time [20:44:05] <BastyCDGS> but today it's not required anymore [20:44:17] <BBB> the code here does a AV_W32() in dp8 [20:44:21] <BastyCDGS> gcc just inlines because we shortened sooo much for itself [20:44:25] <BBB> W64() is for dp32 right? [20:44:31] <BastyCDGS> ehhmm... [20:44:43] <BastyCDGS> we replaced it with WN64A long time ago ;) [20:44:55] <BBB> then the patch I'm looking at is old [20:44:57] <BastyCDGS> mru did optimization of table for this [20:45:06] <BastyCDGS> yes looks so ;) [20:45:09] <BBB> I think you're confusing dp32/dp8 [20:45:18] <BBB> dp8 looks like an ideal candidate for W32 [20:45:23] <BastyCDGS> nope dp8 has to be revised completely [20:45:26] <BastyCDGS> 32 [20:45:27] <BastyCDGS> sry [20:45:38] <BastyCDGS> dp32 I meant [20:45:58] <BBB> ok so start back at the beginning [20:46:05] <BBB> I'm talking about the following patch: [20:46:07] <BBB> decodeplane8() [20:46:10] <BBB> where is the latest version? [20:46:13] <BastyCDGS> dp32 has to be rewritten completely [20:46:19] <BBB> the one Michael and I ok'ed was using W32 [20:46:23] <BastyCDGS> wait a moment, will get it out [20:47:03] <BBB> start a new thread [20:47:06] <BBB> I'm majorly confused [20:47:09] <BBB> and do ONE SINGLE PATCH [20:47:10] <BBB> no more [20:47:12] <BBB> just one [20:47:21] <BBB> if anything else is necessary, start a new thread and put the thread on hold [20:47:30] <BBB> don't ever post more than one patch in a thread [20:47:34] <BBB> 2 is ok, 3 is a mess [20:47:38] <BBB> more than three is where we are now [20:47:45] <BBB> i.e. totally confusing the hell out of me :) [20:47:52] <BBB> (and everyone else) [20:48:21] <BBB> also, if you can, install the google "oops" plugin, the one that lets you cancel sent messages [20:48:31] <BBB> you have a lot "oops this patch wasn't right" 5-second-afters [20:49:01] <BBB> ok, let's look at the real patches now ;) [20:49:09] <BastyCDGS> I just submitted to ml [20:50:22] <BBB> the title of the email is: "[FFmpeg-devel] [PATCH] Fix non-rounding up to next 16-bit aligned bug in IFF decoder" [20:50:31] <BBB> how am I supposed to guess that this is an optimization email? [20:50:45] <BastyCDGS> that's correct [20:51:00] <BastyCDGS> sorry did post it before reading your IRC stuff [20:51:04] <BBB> you probably want to change the subject :) [20:51:38] <BastyCDGS> I was adding this in the past to this thread because my patch depended on this patch in this thread [20:52:05] <BastyCDGS> but since my original patch is already applied I should change this maybe... [20:52:38] <BastyCDGS> sorry I'm just getting hard to follow here (thanks to wine) [20:53:29] <BBB> ok, so all the int -> unsigned is not ok, they make no difference (see michael's earlier comment on ffmpeg-svn mailinglist) [20:53:43] <BBB> as long as they're not used in a division, there is no reason really [20:53:47] <BBB> bps is unused anyway [20:54:23] <BBB> plane is only used as a table index, and buf_size isn't used anywhere relevant also [20:54:24] <BastyCDGS> ??? i dunno understand [20:54:30] <BastyCDGS> was just looking at my patch [20:54:42] <BBB> I'd in fact recommend to change the buf_size * 8 into a buf_size << 3, if you want ot do anything at all :) [20:54:46] <BastyCDGS> it justs adds a table [20:54:55] <BastyCDGS> << 3???? [20:54:58] <BBB> that *might* (probably wouldn't, but might) make a difference [20:55:05] <BastyCDGS> that's completely unnecessary [20:55:14] <BBB> the int->unsigned changes are also [20:55:27] <BastyCDGS> I'm having here: [20:55:29] <BastyCDGS> + const unsigned b32 = b & ~3; [20:55:29] <BastyCDGS> + const uint32_t lut[] = {0x0000000, [20:55:29] <BastyCDGS> + 0x1000000 << plane, [20:55:38] <BastyCDGS> but there's no << 3... [20:56:10] <BBB> iff-decoder-fix-heavy-dp8.patch [20:56:13] <BastyCDGS> just wondering where it originates from... [20:56:14] <BBB> +#define LUT8_PART(plane, v) \ [20:56:15] <BBB> + AV_LE2ME64C(UINT64_C(0x0000000)<<32 | v) << plane, \ [20:56:16] <BBB> [..] [20:56:20] <BBB> +#define LUT8(plane) { \ [20:56:20] <BBB> + LUT8_PART(plane, 0x0000000), \ [20:56:21] <BBB> [..] [20:56:26] <BBB> +static const uint64_t plane8_lut[8][256] = { [20:56:26] <BBB> + LUT8(0), LUT8(1), LUT8(2), LUT8(3), [20:56:28] <BBB> [..] [20:56:35] <BBB> and then the changes to decodeplane8() [20:56:39] <BBB> that is the patch, right? [20:56:42] <BastyCDGS> yes and in the main I have only: [20:56:42] <BastyCDGS> + const uint64_t *lut = plane8_lut[plane]; [20:56:42] <BastyCDGS> + for(; --buf_size != 0; dst += 8) { [20:56:42] <BastyCDGS> + const uint64_t v = AV_RN64A(dst) | lut[*buf++]; [20:56:42] <BastyCDGS> + AV_WN64A(dst, v); [20:57:02] <BastyCDGS> but your table doesn't fit [20:57:21] <BastyCDGS> it should be: [20:57:21] <BastyCDGS> +#define LUT8_PART(plane, v) \ [20:57:21] <BastyCDGS> + AV_LE2ME64C(UINT64_C(0x0000000)<<32 | v) << plane, \ [20:57:24] <BBB> check before that [20:57:25] <BastyCDGS> and: [20:57:33] <BastyCDGS> +#define LUT8(plane) { \ [20:57:33] <BastyCDGS> + LUT8_PART(plane, 0x0000000), \ [20:57:33] <BastyCDGS> + LUT8_PART(plane, 0x1000000), \ [20:57:51] <BBB> go to the patch [20:57:51] <ramiro> BastyCDGS: pastebin [20:57:52] <BBB> not the code [20:57:54] <BBB> but the patch [20:58:05] <BastyCDGS> did I apply the wrong patch then? [20:58:09] <BBB> hm [20:58:09] <BBB> nm [20:58:16] <BBB> mru already replied to the mailinglist saying what I said :) [20:58:23] * BBB pokes mru [20:58:37] <BastyCDGS> I just took a look in my mail I sent [20:58:49] <BastyCDGS> and it still shows the stuff I mentioned above [20:58:54] <BastyCDGS> what did I do wrong? [20:59:47] <BBB> you change the function prototype [20:59:52] <BBB> there's no reason to [21:00:02] <BastyCDGS> you mean this? [21:00:03] <BastyCDGS> +static void decodeplane8(uint8_t *dst, [21:00:03] <BastyCDGS> + const uint8_t *buf, [21:00:03] <BastyCDGS> + unsigned buf_size, [21:00:03] <BastyCDGS> + const unsigned bps, [21:00:03] <BastyCDGS> + const unsigned plane) [21:00:16] <BBB> yes [21:00:25] <BBB> they're all only used as index or not at all [21:00:31] <BBB> so unsigned/int makes no difference [21:00:52] <BastyCDGS> this is not true, it does for plane e.x. [21:00:57] <mru> and const even less so [21:01:10] <BastyCDGS> since that's used as index [21:01:26] <mru> not to mention the gratuitous line breaks [21:01:42] <BBB> you only use plane once [21:01:48] <BBB> so const or no const makes no difference [21:01:55] <BBB> bps is unused [21:02:04] <BBB> so const makes no difference [21:02:09] <mru> const can only make a difference on pointers [21:02:27] <BastyCDGS> oh bps is unused, thank you mentoning that [21:02:44] <BBB> I bet you he will send a patch removing it in the same patch as adding the optimization now [21:02:46] <BastyCDGS> that's really sth. to remove from func [21:02:47] <BBB> :-p [21:02:51] <_av500_> compiler would still complain if you modify "const plane", no? [21:03:09] <BBB> _av500_: -Wall doesn't work anyway [21:03:15] <BBB> so it's not like anyone would notice [21:03:23] <BBB> -Werror, I meant [21:03:35] <mru> modifying a const is an error [21:03:43] <mru> but it doesn't affect optimisation [21:03:55] <mru> it's only an aid to avoid accedentally changing something [21:04:06] <BastyCDGS> mru, all my optimizations tutorial tell me to use const for optimizing [21:04:09] <_av500_> yep, that is what i meant [21:04:15] <_av500_> BastyCDGS: ??? [21:04:16] <mru> BastyCDGS: burn those tutorials [21:04:22] <BBB> BastyCDGS: probably in tables, as mru said [21:04:24] <drv> const on local scalars is completely pointless [21:04:29] <BBB> for tables, const is good [21:04:38] <BBB> it puts it in .rodata (or whatever it's called) [21:04:40] <mru> const is good on global data [21:04:50] <BastyCDGS> av500, I already seen diffs on this [21:05:00] <mru> it also means the compiler can assume it won't change over time [21:05:10] <BastyCDGS> I thought that it's unnecessary quite a long time [21:05:23] <BastyCDGS> I used non-const in TuComposer too... [21:05:34] <BastyCDGS> until I learned that it can make a diff [21:05:41] <mru> hard to get anything done with only const data [21:05:47] <BBB> *grin* [21:05:55] <BBB> BastyCDGS: show us that the output changes [21:06:09] <mru> optimising C is a bit like breaking md5 [21:06:19] <mru> keep trying inputs until you get the desired output [21:06:28] <BastyCDGS> BBB, I can show this for my TuComposer source compiling with StormC [21:07:04] <wbs> StormC wasn't one of the supported ffmpeg compilers, last I checked [21:07:09] <wbs> or is it? [21:07:10] <mru> please give the author of that compiler a ticket here [21:07:13] <mru> one-way is good enough [21:07:18] <mru> he won't be needing the return [21:07:22] <BastyCDGS> mru, Haage & Partner [21:07:41] <BBB> BastyCDGS: you're only using plane once [21:07:48] <BBB> BastyCDGS: const or not const makes no difference in this case [21:07:52] <ramiro> BastyCDGS: what's the link to tucomposer again? [21:07:59] <mru> even if he used it a million times const would make no difference [21:08:11] <mru> nothing external to the function can modify a local variable [21:08:12] <BBB> I just tried on iff.o [21:08:13] <BastyCDGS> ramiro: http://forum.cdgs-crew.com/viewforum.php?f=11 [21:08:13] <_av500_> StromC: The progressive C/C++ development system for the Amiga's future [21:08:23] <BBB> making int plane -> const in decodeplane8() in current svn changes the md5 [21:08:29] <BBB> that's about as much as I tested :) [21:08:36] <mru> BBB: with debug symbols? [21:08:43] <BBB> god damn you :) [21:08:51] <mru> strip the files before comparing [21:09:03] <mru> if it still differs, extract the .text section [21:09:12] <ramiro> BastyCDGS: Wed 01 Jun, 2005 ? [21:09:22] <BastyCDGS> yeah stripping and comparing them was that I was doing all the times when devloping TuComposer [21:09:48] <BBB> mru: in progress [21:10:06] <BastyCDGS> ramiro, that date was when I putted them in WWW, but actual coding was done in 1996-98 [21:10:30] <ramiro> I thought tucomposer was a modern tracker [21:10:38] <mru> that's an oxymoron [21:10:40] <BastyCDGS> it is ramiro [21:10:59] <mru> just like there are no modern steam engines [21:11:06] <ramiro> mru: I read that expression in mike's blog, it was supposed to be funny =) [21:11:12] <mru> never mind the nuclear stuff [21:11:40] <BastyCDGS> ramiro, just because I didn't hat in 2010 doesn't mean it's not modern [21:11:46] <ramiro> BastyCDGS: is there any recent code for it? [21:11:54] <ramiro> released somewhere... [21:12:01] <BastyCDGS> the most recent code you find exactly there [21:12:09] <ramiro> pre-ALPHA? [21:12:18] <BastyCDGS> the only caveat is though it's amiga only [21:12:19] <mru> code that old tends to a) not compile and b) be ugly as sin [21:12:46] <BastyCDGS> that's the reason I declared it pre-ALPHA [21:12:57] <BastyCDGS> on amiga itself it's rockstable [21:13:00] <ramiro> since 1996? [21:13:09] <BastyCDGS> it decodes over 1000+ mods without crash [21:13:11] <mru> ramiro: yes, that's pre-alpha... I got my first alpha machine ~2000 [21:13:26] <BastyCDGS> it all them plays absolutely and I mean absolutely perfectly [21:14:12] <BastyCDGS> just try it to bring tucomposer's decoder to crash, just try it ;) [21:14:48] <BastyCDGS> it handles mods/s3ms/xms/its which cause even up-to-state linux decoders to crash [21:14:55] <BastyCDGS> like opencubicplayer etc. [21:15:15] <mru> I thought you said there were 18096 MODs [21:15:48] <mru> and let's compile it first, shall we? [21:15:48] <BastyCDGS> well I tested them with just of my 1000 main modules [21:16:22] <BastyCDGS> and of course I sometimes tried them with my mods anthology CD [21:16:31] <mru> did you try a fuzzer? [21:16:31] <BastyCDGS> but until now it was always finee [21:17:23] <BastyCDGS> do you mean a tool which corrupts mods in order to check if they're correct? [21:17:45] <mru> well... something like that [21:17:49] <mru> you're on the right track [21:17:58] <mru> guaranteed no pun intended [21:17:59] <mru> hahaha [21:18:01] <BBB> mru: md5 changes [21:18:14] <BastyCDGS> well I didn't use that directly, but what I did was to load tons on modules which even don't comply to standard and I had to ensure conversation issues in order to get them right [21:18:34] <BBB> mru: will look at .text in a bit [21:18:38] <BBB> first trying another control [21:20:48] <BastyCDGS> I just can tell that I wasn't able to trigger fatal bugs in TuComposer between the time from 1994-1998 [21:21:11] <mru> testing can only prove the presence of bugs, never their absence [21:21:37] <BastyCDGS> I know ;) [21:22:02] <_av500_> bugs can prove the absence of testing though :) [21:22:39] <BastyCDGS> guys, I'm writing about 4 years of consequence testing... [21:22:54] * mru is not impressed [21:23:02] <BastyCDGS> not just of starting a tool and see: uhm, there's an error [21:23:05] <BBB> hm [21:23:10] <BBB> the actual disassembly didn't change [21:23:13] <BBB> did a quick diff [21:23:15] * mru is not easily impressed [21:23:24] <mru> BBB: see, told ya :-) [21:23:36] <BBB> why did the md5 change? [21:23:42] <BBB> stupid false negative [21:23:45] <BBB> or false positive [21:23:49] <BastyCDGS> mru, you should be that skeptical as you are right now ;) [21:24:00] <drv> maybe the object file has a timestamp in it or something? [21:24:17] <mru> do a binary diff and see [21:25:20] <BBB> I don't give a shit :) [21:25:20] <mru> so I open a random file in tucomposer, and what do I see? [21:25:24] <mru> UNDEFINED BEHAVIOUR [21:25:41] <BBB> BastyCDGS: I just showed the const didn't make a difference [21:25:48] <BBB> BastyCDGS: so please remove the const :) [21:25:49] <mru> nevermind the ugly style [21:25:58] <BBB> and while you're at it, change the unsigned back to int as mru suggested [21:26:14] <BBB> rest of patch looks good, so I'll apply once that's done [21:26:34] <BBB> mru: no more comments on the patch right? [21:26:38] <BastyCDGS> wait a minute, I'll do that now [21:26:41] <mru> nothing more from me [21:27:22] <BBB> ok [21:27:34] <BBB> what was the next patch [21:27:35] <BBB> ? [21:27:38] <BBB> ham decoding, right? [21:27:42] <BastyCDGS> yes HAM [21:27:46] <BBB> I'll take that home with me to review, will send it back tonight or so [21:29:07] <BastyCDGS> just one question [21:29:20] * BBB awaits question [21:29:27] <BastyCDGS> do you mean I should convert all unsigned to int? [21:29:37] <BBB> no [21:29:42] <BBB> just the ones in the function prototype [21:29:45] <BastyCDGS> -static void decodeplane8(uint8_t *dst, const uint8_t *const buf, int buf_size, int bps, int plane) [21:29:46] <BBB> there's no reason to change them [21:29:50] <BBB> yes [21:29:52] <BBB> just as it was [21:30:35] <BastyCDGS> I disagree that there's no reason to change them but if you force me to do so... [21:30:52] <BBB> if you give us a good reason and show it, then you may change them [21:31:09] <BBB> until you do so, let's leave it as-is, going by our rule that "patches should be as simple as possible" [21:31:18] <BastyCDGS> from user's point of view: [21:31:20] <BBB> for new code, you may do as you wish, of course :) [21:31:27] <BBB> (since it makes no difference) [21:31:39] <BastyCDGS> I should anywhere know if some value should be designed to be signed/unsinged, right? [21:31:40] <BBB> although smaller sourcecode size is always better [21:31:54] <BBB> values aren't signed or unsigned alone [21:31:57] <BBB> they have a valid range [21:32:03] <BBB> some values can have 0-5 as valid range [21:32:06] <BBB> such as log_level [21:32:06] <BastyCDGS> yes that's what I meant ;) [21:32:14] <BBB> signed or unsigned are both wrong [21:32:18] <BBB> so it's irrelevant which you choose [21:32:20] <BastyCDGS> and that's what I mean with plane etc. [21:32:28] <BastyCDGS> a plane < 0 makes no sense right? [21:32:31] <wbs> BastyCDGS: doing readability/understandability changes that have no impact on performance doesn't belong in an optimization patch, it's as simple as that [21:32:34] <BBB> plane is 0<plane<=8 [21:32:46] <BBB> so signed is as wrong as unsigned [21:32:51] <BastyCDGS> yes, therefore plane is unsigned [21:32:58] <BastyCDGS> since 0<plane... ;-) [21:32:59] <BBB> the proper way to specify a value is to properly document the value [21:33:13] <BastyCDGS> the base here is IFF-ILBM [21:33:14] <BBB> no, because unsigned can be 12, or 0x80000000, or something else [21:33:23] <BastyCDGS> and IFF-ILBM is ALWAYS unsigned on that [21:33:23] <BBB> it's a false sense of security [21:33:32] <BBB> the proper way to do it is to document the correct values [21:33:37] <BBB> and check for them in the function body [21:33:42] <BBB> (where appropriate) [21:33:48] <BBB> in your case, you do that in decode_init() [21:33:50] <BBB> so you're fine [21:33:51] <_av500_> BastyCDGS: plane < 0 makes as much sense a plane = INT_MAX [21:33:52] <BastyCDGS> yes I agree to this totally BBB [21:34:39] <BastyCDGS> plane < 0 will trigger nothing, while pane = INT_MAX will segfault [21:34:50] <BastyCDGS> and thus showing us all that something is really wrong [21:35:20] <BBB> let's just agree it doesn't matter much ;) [21:35:29] <BBB> learn to properly document values, not look at type [21:35:31] <BastyCDGS> we can of course! [21:35:40] <BastyCDGS> but I really don't like that [21:35:41] <BBB> whether a user sees signed or unsigned, in both cases it's incomplete [21:35:49] <BBB> only 8 of the 1<<32 values possible are correct [21:35:56] <BBB> regardless of signed/unsigned [21:36:12] <BastyCDGS> remember that uint/int stuff causes already a lot of trouble [21:36:30] <BastyCDGS> some hw doesn't support FAT files with 4GB some do etc. [21:36:39] <BBB> btw where is the patch? [21:36:57] <mru> FAT itself doesn't support >2G [21:37:17] <BastyCDGS> it does but the unsigned/signed stuff is causing problems [21:37:31] <BastyCDGS> FAT can handle 4GB if cluster size => unsigned [21:38:20] <BastyCDGS> I know that most of you don't deal much with that stuff (unsigned <=> singed) [21:38:30] <mru> careful what you say [21:38:30] <BBB> ? [21:38:36] * BBB smiles a bit [21:38:39] <BastyCDGS> but the days when we devel'ld on amiga we had to really care ab't that [21:39:08] <_av500_> why? [21:39:10] <BastyCDGS> on amiga UWORD was really UWORD and handling this as WORD was FATAL! [21:39:24] <mru> funny you should say that [21:39:32] <BastyCDGS> the structures we had there was designed for such stuff... [21:39:39] <mru> because that is *exactly* what I randomly say you doing in tucomposer just now [21:40:04] <BBB> BastyCDGS: let's get back to the patch, please submit it [21:40:12] <BBB> BastyCDGS: and then submit a second patch where you remove the int bps parameter [21:40:22] <BastyCDGS> mru, no in TuComposer I showed for each variable and decided for each if it should be unsigned or not [21:40:23] <BBB> then I'll look at ham [21:40:26] <BastyCDGS> do not mix that up [21:41:00] <CIA-7> ffmpeg: stefano * r23060 /trunk/ffplay.c: [21:41:00] <CIA-7> ffmpeg: Fix auto-scaling. [21:41:00] <CIA-7> ffmpeg: Use the numeric value assigned to sws_flags for the sws_flags set in [21:41:00] <CIA-7> ffmpeg: the graph, rather than the string "bilinear", which is not even [21:41:00] <CIA-7> ffmpeg: parsable by the scale filter. [21:41:19] <mru> WORD *OldWaveData = WaveformStr->tcyw_WaveData; [21:41:23] <mru> WORD WavePoint; [21:41:26] <BastyCDGS> mru, if you change TuComposer's code regarding this, you can be 99,99% sure that it will break playback [21:41:27] <mru> WavePoint = (UWORD) *OldWaveBuf++; [21:41:32] <mru> wtf is that then? [21:41:47] <BastyCDGS> looks like m68k C code ;) [21:42:05] <mru> looks clueless to me [21:42:20] <BBB> uword looks portable [21:42:21] <mru> you're probably hoping the cast will do nothing [21:42:25] <mru> and it probably won't [21:42:28] <BBB> as opposed to int, int16_t or so :) [21:42:30] <BastyCDGS> UWORD = uint16_t [21:42:33] <mru> but it is undefined [21:43:20] <BastyCDGS> mru, my TuComposer source result is designed carefully on what compiler result (in his case StormC) [21:43:30] <mru> rotfl [21:43:39] <mru> does the term "portable code" have a meaning to you? [21:43:44] <BastyCDGS> I tried a hell to get most performing result [21:43:48] <mru> how about "ISO C"? [21:44:10] <BastyCDGS> mru, I know there have to be changes [21:44:32] <BastyCDGS> and I know that the current code isn't perfect regarding this [21:44:33] <BBB> I love gcc [21:44:36] <BBB> look at this: [21:44:38] <BBB> libavcodec/iff.c:145: error: increment of read-only location [21:44:45] <BBB> now, guess what what this line does [21:45:04] <BBB> ... [21:45:04] <BBB> ... [21:45:05] <BBB> ... [21:45:05] <BBB> const uint64_t v = AV_RN64A(dst) | lut[*buf++]; [21:45:25] <drv> which thing is const? [21:45:29] <BBB> const uint8_t *const buf [21:45:33] <_av500_> BastyCDGS: wrt FAT, you are again wrong, for FAT using uint32_t matters, for plane it does not [21:45:39] <drv> well, that's incorrect code then [21:45:40] <mru> BBB: all of it is const there [21:45:51] <BBB> it's a little lol :) [21:45:53] <BBB> too many consts [21:45:56] <BBB> I'll remove them all [21:45:57] <mru> "const type *foo' is pointer to const [21:45:58] <BBB> they do nothing [21:46:01] <BastyCDGS> av500, ehm that's my code ;) [21:46:04] <mru> "type *const foo" is const pointer [21:46:48] <mru> "Please read everything in this section carefully, all of the words are important." [21:46:53] <mru> ^^ found in the FAT spec [21:46:55] <BastyCDGS> but av500 I'm not saying that a plane is > 2^311 [21:47:02] <BastyCDGS> but it's always >= 0 [21:47:13] <BastyCDGS> and that's why I'm using unsigned here [21:47:30] <_av500_> no, plane is a small number [21:47:32] <_av500_> line int i [21:47:36] <_av500_> like int i; [21:47:42] <_av500_> u dont care, so it is int [21:47:47] <BastyCDGS> yes it is [21:47:57] <mru> "Please don’t draw an incorrect conclusion here." [21:48:00] <mru> that spec is funny [21:48:15] <BastyCDGS> FAT is really "nice" here [21:48:17] <drv> sounds like "it's ok if you do that elsewhere, just not here" [21:48:31] <BastyCDGS> depending on target OS you have max. file size 4GB or 2GB [21:48:56] <_av500_> BastyCDGS: no, there are just broken implementations [21:49:09] <_av500_> and they have been there a long time [21:49:28] <_av500_> so other asumed that was correct... [21:49:33] <BastyCDGS> really hard to answer, if that's broken or M$ specs [21:49:45] <CIA-7> ffmpeg: rbultje * r23061 /trunk/libavcodec/iff.c: Optimize decodeplane8(), patch by Sebastian Vater <cdgs basty googlemail com>. [21:49:45] <_av500_> fat supports 4gb files just fine [21:50:01] <BastyCDGS> yes that's what I was just assuming [21:50:11] <BastyCDGS> 4GB files are correct (uint32_t) [21:50:22] <_av500_> sure, as i said, there it matters [21:50:22] <mru> Reserved for use by Windows NT. Set value to 0 when a file is created and never modify or look at it after that. [21:50:24] <BastyCDGS> but they aren't when you do int32_t (<= 2GB) [21:50:50] <_av500_> but this is not relevant for your unsigned issue [21:51:08] <BastyCDGS> av500, you're right here also [21:51:16] <BastyCDGS> but what we should do finally? [21:51:38] <BastyCDGS> just assume that everything is unsigned [21:51:57] <BBB> I already applied the patch [21:51:57] <BastyCDGS> and then wonder why any example which requires this goes bad? [21:52:01] <BBB> let's go to the ham patch [21:52:28] <_av500_> BastyCDGS: no [21:52:28] <BastyCDGS> I know you're all from x86 where unsigned isn't hat an issue [21:52:31] <_av500_> no [21:52:33] <_av500_> no [21:52:35] <BastyCDGS> but let me tell you [21:52:35] <drv> everything unsigned can have unintended consequences too [21:52:39] <BastyCDGS> I'm from amiga [21:52:39] <_av500_> use it where it matters [21:52:43] <BastyCDGS> and I can tell you [21:52:52] <BastyCDGS> UNSIGNED makes here a big difference [21:52:55] <_av500_> dont use it where it does not [21:53:01] <BastyCDGS> if in doubt just read IFF specs [21:53:29] <BastyCDGS> drv, you're totally right !!! [21:53:45] <BastyCDGS> and amiga formats really are dependent on this! [21:53:52] <drv> well, that's not really what i meant [21:54:01] <drv> like if you write a count-down loop with an unsigned iterator [21:54:15] <drv> or other less than/greater than comparisons don't do what you expect [21:54:27] <BastyCDGS> yes and even this can make a huge diff between a normal signed counter [21:54:56] <BastyCDGS> drv, that's WHY i use unsigned because they act different (and also are faster one some machines) [21:54:58] <mru> ok, FAT spec says filesize is unsigned 32-bit [21:55:09] <mru> anything pretending otherwise is by definition wrong [21:55:26] <BastyCDGS> mru, you see? do you now understand a little bit why I'm so picky on this? [21:55:33] <mru> not at all [21:55:38] <_av500_> BastyCDGS: no [21:55:39] <mru> I simply misremembered [21:56:10] <_av500_> BastyCDGS: if the number needs 32 bit, you have to use uint32 [21:56:21] <_av500_> if the number needs a few bits, just use int [21:56:22] <BastyCDGS> yes I know [21:56:23] <mru> unless it needs signed 32-bit... [21:56:30] <BastyCDGS> av500: I use int [21:56:38] <BastyCDGS> but unsigned if it's never <= 0 [21:56:48] <mru> no [21:56:50] <_av500_> and this is useless [21:56:53] <mru> depends [21:56:56] <_av500_> and or dangerous [21:57:00] <BastyCDGS> no it's not useless [21:57:02] <mru> I've seen horrible bugs caused by that [21:57:18] <BastyCDGS> any value never be < 0 (i.e. negative) should be declared unsigned [21:57:22] <mru> unsigned foo = some_random_data; [21:57:34] <mru> while (foo - 2 > 0) { ...; foo--; } [21:57:35] <BastyCDGS> it shows the programmer that this value never has to be neg. [21:58:06] <_av500_> BastyCDGS: the programmer does not matter, its not like he does the computation on paper [21:58:23] <BastyCDGS> av500: the programmer just writes the stuff [21:58:25] <mru> that turns into an infiniloop if foo is odd [21:58:54] <BastyCDGS> hey guys, I don't tell you this to argue you [21:59:07] <mru> you're suppose to be learning from us [21:59:12] <drv> mru: maybe foo -= 2? otherwise i think it would terminate [21:59:17] <BastyCDGS> I just want to help from my experiences [21:59:22] <BastyCDGS> mru, I know [21:59:24] <mru> drv: well, yeah [21:59:30] <BastyCDGS> and I'm learning a lot from you [21:59:34] <BastyCDGS> you know this [21:59:38] <mru> well, the amiga experience isn't of much use to us [21:59:54] <BastyCDGS> yes that what is understanding to me [22:00:14] <BastyCDGS> but where not discussing about how great the amiga was/it ;) [22:00:24] <mru> the real bug I saw was slightly different [22:00:26] <mru> it was like this [22:00:28] <BastyCDGS> we're discussing about import of formats [22:00:35] <mru> unsigned short foo = blah; [22:00:48] <mru> while (foo - 2 > 0) { ...; foo -= 2; } [22:01:00] <BastyCDGS> and in the case of formats it simply counts how the origin was defined [22:01:08] <mru> then someone decided to "fix" a lint warning [22:01:08] <BastyCDGS> and therefore you simply look at BMHD etc. [22:01:13] <BastyCDGS> and you see: [22:01:17] <mru> made it while (foo - 2u > 0u) [22:01:21] <BastyCDGS> EVERYTHING is unsigned [22:01:21] <mru> and it inifinilooped [22:01:23] <BastyCDGS> NOT signed [22:01:36] <mru> bmhd? [22:01:38] <_av500_> BastyCDGS: you dont want to understand [22:01:47] <BastyCDGS> FORM-ILBM => BMHD [22:02:08] <BastyCDGS> av500: don't panic, I understand your concerns too [22:02:20] <_av500_> panic, moi? [22:02:25] <mru> without the u suffix, the unsigned short was promoted to signed int and the comparison worked [22:02:31] <BastyCDGS> but it's not really that easy as we ALL (that includes me too) might believe [22:02:34] <BastyCDGS> at first glance [22:04:18] <BastyCDGS> mru, which WORD to UWORD conversation you mean? [22:04:46] <BastyCDGS> resp. UWORD => WORD? [22:04:58] <mru> ConvertWaveform.c [22:05:04] <mru> it's full of casts [22:05:31] <BastyCDGS> you mean in TuComposer? [22:05:35] <mru> yes [22:05:50] <BastyCDGS> mom have to start UAE to look on this... [22:06:08] <mru> huh? [22:06:20] <mru> the zip file unpacks reasonably well on any machine [22:06:30] <mru> half the files are executable for no reason, but nevermind [22:06:51] <_av500_> mru: but it is signed vs unsigned char for the src code :) [22:06:59] <_av500_> changes the meaning totall [22:07:00] <_av500_> y [22:07:28] <BastyCDGS> oh I got the casts [22:07:46] <BastyCDGS> I added them to allow any C++ compiler to compile them just fine [22:08:28] <mru> why do you compile c code with a c++ compiler? [22:09:24] <BastyCDGS> because I was naive enough during this time [22:09:47] <BastyCDGS> mru, I won't do this anymore today [22:10:09] <BastyCDGS> I have already told my problems with my old stuff [22:10:57] <BastyCDGS> please never forget.... [22:11:13] <BastyCDGS> I have translated all this from 100% m68k asm to C [22:11:18] <BastyCDGS> line by line [22:11:42] <BastyCDGS> every line you read there is pratically one asm line on m68k [22:14:20] <mru> why the heck did you write it in asm first? [22:14:36] <BastyCDGS> mru, very good question [22:14:50] <BastyCDGS> assign this to the stupiest ideas of mankind ;) [22:14:51] <mru> writing critical parts in asm makes sense of course [22:15:00] <mru> but I'd always write it in C first [22:15:15] <BastyCDGS> mru, you're completely right here [22:15:35] <BastyCDGS> but I was naive and idotic enough to don't do that this way ;) [22:16:09] <BastyCDGS> I know it might sound strange to you [22:16:24] <BastyCDGS> but that's what I can tell you for truth [22:16:26] <mru> I've done silly things too [22:16:38] <mru> but I don't use them as reference now [22:17:11] <BastyCDGS> I understand this pretty well now [22:17:25] <BastyCDGS> but still I know I do some hazardous stuff for now [22:20:17] <BastyCDGS> do you know what me really wonders? [22:20:26] <mru> no [22:20:40] <BastyCDGS> the picy stuff about unsigned/signed here... [22:21:44] <BastyCDGS> why where wasting lots of time upon this, etc.? [22:22:04] <mru> I believe it was you who started changing them [22:22:17] <BBB> BastyCDGS: we want small patches [22:22:20] <BBB> as small as possible [22:22:23] <BastyCDGS> yes, indeed and no for bad reason ;) [22:22:29] <BBB> imagine that you do a huge performance-enhancing patch to h264 [22:22:34] <BBB> we would REALLY REALLY WANT THAT [22:22:35] <BBB> ok [22:22:41] <BBB> now, half of the patch is int->unsigned changes [22:22:44] <mru> I know you have good intentions [22:22:47] <BastyCDGS> I understand why you want signed stuff as much was possible [22:22:48] <BBB> and the patch is like 10k [22:22:51] <BBB> we will not look at it [22:22:55] <BBB> because it's too much [22:23:03] <BBB> we're tyrying to teach you good patch-handling techniques here [22:23:23] <BBB> so that when you go do bigger projects, (hopefully here), the patches will not be of good, but of outstanding quality [22:23:37] <BBB> signed/unsigned is irrelevant [22:23:41] <BastyCDGS> BBB, are my patches really causing so much big additions? [22:23:49] <BBB> the patch should be as small as possible [22:24:10] <wbs> if there's no practical reason for changing something, don't change it, even if you think it is better some other way [22:24:22] <wbs> if you really, really, really want to change it, change it in a separate bikeshed patch [22:24:30] <BBB> BastyCDGS: and at some point, yes, you will give us huge patches, at least I hope so [22:24:51] <BastyCDGS> if I change something to uint instead int I know why I'm doing so [22:25:01] <BBB> you might [22:25:06] <BBB> but we have to review it nonetheless [22:25:13] <BastyCDGS> but I also understand why you're such criticial about this [22:25:16] <BBB> and int>uint in the same patch as adding a lut, is noise [22:25:16] <wbs> and if it isn't essential, don't change it! [22:25:29] <BBB> the point of decodeplane8() optimization was the lut [22:25:32] <BBB> the patch should add a lit [22:25:38] <BBB> not change int->unsigned :) [22:25:50] <BBB> (you could do that, but as wbs suggested, separate patch) [22:26:20] <BastyCDGS> BBB, thank you for that [22:26:24] <BBB> by the way, note how the optimization patch was reviewed several times, how people really get what the patch does [22:26:30] <BBB> and the 32->64bit change made it even more fast [22:26:48] <BBB> if the patch had random stuff in it, or we weren't knowledgeable, we wouldn't have done that [22:27:02] <BBB> ffmpeg is high-quality because we go through it, in iterations, in this maddening way :) [22:27:04] <BastyCDGS> yeah we spent all together lots of time to get this going on ;) [22:27:10] <BBB> and that way we're 20% faster than everyone else out there [22:27:14] <BBB> because we bikeshed too much [22:27:20] <BastyCDGS> BBB, I love youj! [22:27:32] <BBB> holy shit ;) [22:27:40] <BastyCDGS> that's what ffmpeg is about ;) [22:28:05] <BastyCDGS> hey, we're crazy [22:28:10] <BastyCDGS> we're all crazy [22:28:23] <BBB> ok, I just reviewed the ham patch, it's a lot again, but we'll get it in in a few iterations [22:28:26] <BastyCDGS> but: that's gooooooood! [22:28:32] <BBB> and yes we're crazy [22:28:59] <BastyCDGS> that what I'm saying ;) [22:29:15] <BBB> ok, my wife will come home in a bit [22:29:20] <BBB> I'd better be there when she does [22:29:21] <BBB> so I'm off now [22:29:31] <BastyCDGS> hehe I understand [22:29:41] <BastyCDGS> so you know what I mean with my Jessica ;) [22:29:55] <BBB> you're married too? [22:30:00] <BBB> how old are you? :) [22:30:07] <mru> amiga age obviously [22:30:15] <BastyCDGS> not married yet, but could happen very soon ;) [22:30:29] <BastyCDGS> I'm 30 [22:30:45] <BBB> and still not married? [22:30:51] <BBB> :-p [22:30:52] * BBB runs [22:30:53] <mru> I would've thought you a few years older with the amiga stuff [22:31:02] <mru> BBB: I'll be 30 this year [22:31:12] <mru> no marriage in sight [22:31:19] * BBB throws mru some women [22:31:20] <BastyCDGS> mru, I got 30 on 4th feb 2010 [22:31:32] <BBB> ok, really off now ;) [22:31:50] <BastyCDGS> BBB, wish me some luck with jessi ;) [22:31:51] <mru> BBB: thanks, but the women all bounced [22:31:57] <mru> BastyCDGS: good luck [22:32:04] <BastyCDGS> hey thanks [22:32:05] <BBB> good luck indeed [22:32:08] <BBB> propose tonight ;) [22:32:09] <_av500_> send pics [22:32:41] <BastyCDGS> av500 can't she didn't send px to me [22:32:48] <BastyCDGS> but what I can [22:32:53] <BastyCDGS> sending a mod [22:32:54] <BastyCDGS> ;) [22:33:54] * _av500_ goes to sleep, listening to canyon.mid... [22:34:17] <BastyCDGS> lol canyon.mid I know this one very well :D [22:35:21] <BastyCDGS> if someone of you are goa freaks, though...

1 0

IRC log for 2010-05-07
by irc＠mansr.com 08 May '10

08 May '10

[00:05:27] <Dark_Shikari> wow. ffmpeg mpeg-2 did a surprisingly good job [00:08:35] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/mpeg2.png [00:09:51] <Dark_Shikari> like, seriously, I'm shocked [00:10:37] <Dark_Shikari> wait. that isn't mpeg-2. that's mpeg-1. [00:12:18] <Dark_Shikari> so http://mirror05.x264.nl/Dark/compare/mpeg1.png [00:13:26] <kierank> that looks quite good [00:13:40] <Dark_Shikari> better than theora, worse than dirac. [00:13:50] <Dark_Shikari> I underestimated michael's encoder =p [00:15:53] <kierank> who needs theora then... [00:16:02] <Dark_Shikari> In motion mpeg1 looks kinda bad [00:16:03] <Dark_Shikari> very smeary [00:16:05] <Dark_Shikari> but so does theora [00:16:19] <Dark_Shikari> I do largely think that the reason ffmpeg is better is because of better algorithms though [00:16:29] <Dark_Shikari> theora is definitely better than mpeg-1. [00:16:59] <astrange> you could implement psy-rd in the mpegvideo encoder without much work, do that and see if it gets better [00:17:14] <Dark_Shikari> AQ is probably more useful [00:17:28] <Dark_Shikari> mbtree is also ridiculously powerful on this clip [00:44:32] <peloverde> the faac inspired quantizer search doesn't use psybands? how did I not know this? [01:25:54] <CIA-7> ffmpeg: michael * r23039 /trunk/libavfilter/ (vsrc_buffer.h vsrc_buffer.c): [01:25:54] <CIA-7> ffmpeg: Add "Memory buffer source filter" from SOC. [01:25:54] <CIA-7> ffmpeg: This is needed by the current SOC-ffmpeg.c code. [01:38:29] <Compn> theora always reminds me of vivo and rv30 for some reason [01:39:07] <Compn> am i the only person who cares about vivo support anymore? [01:51:53] * Kovensky never even saw a vivo file [01:58:32] <Compn> gahh [01:59:31] <Compn> vivo was so out there, it was a top 4 in the format war (mov/asf/rm/vivo) [01:59:41] <kierank> it was? [01:59:42] <Compn> at least, i think thats how i remember it [02:03:30] <peloverde> I remember the other three [02:04:21] <kierank> there was some vividas thing iirc [02:06:15] <Compn> The Vivo format, obsolete today, was one of the first to be designed and used for internet streaming. [02:06:23] <Compn> well, according to wikipedia ;p [02:16:40] <astrange> vividas, hm [02:16:42] <astrange> http://vividas.com/xml/player/osxia32lib.jpeg [02:17:14] <astrange> seems to be vivo + xiph something, [02:17:56] <kierank> the files were obfuscated somehow [02:18:01] <kierank> mru wrote a descrambler iirc [06:06:59] <KotH> moikka moi [06:10:01] <av500> ja [06:10:42] <merbzt> tere homikost [06:45:42] * elenril stabs new sidebar at google [06:46:20] * av500 notices google sidebar [06:46:34] <elenril> that thing is pure EVIL [06:48:43] <Tjoppen> bah [06:49:03] <Dark_Shikari> what's so wrong with it [06:51:34] <elenril> i just don't like [06:51:35] <elenril> it [06:51:48] <av500> cant your greaemonkey it away? [06:51:54] <av500> you [06:52:11] <elenril> installing yet another ff extension => another 300 mb ram lost [06:52:25] * elenril just got rid of adblock yesterday for great justice [06:53:25] <elenril> also wtf is with the search buttong using system colors for text, but forcing white as background [06:54:22] <Tjoppen> does anyone have/know where to find any documentation for the AliasHandle (alis) tag in MOV? the specs mention it, but doesn't contain its definition. googling around didn't help [06:55:00] <Tjoppen> reverse engineering what the demuxer does only resulted in the file being playable in ffplay, not any other player :/ [06:58:06] <wbs> I had the same issue, I tried hacking qt-faststart to create compressed moov atoms.. and the official qt player didn't play it, while ffplay worked just fine. ;P [06:58:24] <Dark_Shikari> qt is hardly a very good or compatible player =p [06:59:06] <wbs> no, but I'd think it should handle stuff in the qt spec [06:59:20] <wbs> on the other hand, I haven't got any clue whether cmov is part of any official spec [06:59:38] <av500> elenril: was it you who wanted to seek in flac? [07:00:44] <elenril> there are people who don't want to seek in flac? [07:00:53] <elenril> (except mru) [07:01:18] <av500> this is quick and dirty rejectware: http://ffmpeg.pastebin.com/YBxmYhc4 [07:01:32] <Yuvi> chances are that there's some other atom you're not taking into account, for alis you have to change both dref and mdhd off the top of my head [07:02:24] <Dark_Shikari> ok, I need more comedy options for the codec comparison [07:02:30] <Dark_Shikari> bink and svq1 are pretty awesome [07:02:41] <av500> there is always libcaca [07:02:42] <Dark_Shikari> mpeg1, mpeg4, xvid, x264, dirac, theora are all up [07:02:47] <Yuvi> the specs say it's an AliasHandle, which helpfully appears to be an opaque struct... [07:02:48] <Dark_Shikari> but those aren't very good for comedy options [07:03:28] <av500> Dark_Shikari: there is a nice url for all of there? [07:03:31] <elenril> av500: nice [07:03:32] <av500> of these [07:03:35] <Yuvi> msvideo 1 [07:03:37] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare [07:03:41] <elenril> btw what happened to negative pts stuff? [07:03:47] <av500> ah right [07:03:53] <av500> need to pick up on that [07:04:32] <av500> Dark_Shikari: bitrate? [07:04:38] <Dark_Shikari> 14mbps at 1080p50 [07:07:12] <av500> why is xvid less? it refused? [07:07:26] <Dark_Shikari> ohit is? [07:07:37] <av500> 9.2M, all others are like 17 [07:07:38] <Dark_Shikari> wait, whoa [07:07:55] <Dark_Shikari> the fuck is with xvid [07:08:06] <Dark_Shikari> it must have thought the fps was 25 [07:08:22] <Dark_Shikari> let me fix that [07:09:04] <Dark_Shikari> well xvid is going to get a lot better now. [07:12:58] <av500> hmm, mpeg1 scores higher than the t-codec here [07:13:14] <av500> or is that mpeg2? [07:13:49] <Dark_Shikari> mpeg-1 [07:13:51] <Dark_Shikari> same thing anyways [07:14:10] <Dark_Shikari> and yes it does, probably because ffmpeg is a better encoder [07:14:35] <av500> but mpeg1 patents expired, no? so why use T? :) [07:14:51] <Dark_Shikari> not until 2015 [07:14:57] <Dark_Shikari> also, because it's not xiph [07:15:13] <av500> also, I rate vp7 as the 2nd best to x264 [07:15:25] <av500> so, vp8 must be awesome!!! [07:15:27] * av500 hides [07:15:28] <Dark_Shikari> lol [07:15:40] <Dark_Shikari> I haven't gotten out any decent competitors yet though =p [07:16:14] <kshishkov> PNG? [07:16:46] <av500> strange, the face of the front guy is better in vp7, the one of the woman in black is better in x264 [07:16:55] <av500> x264 likes women more.. [07:17:13] <kshishkov> it was tuned for Touhou Project clips anyway... [07:17:31] <av500> well, she does not have huge eyes... [07:17:49] <kshishkov> it will be fixed in upcoming version of x264 [07:18:46] <av500> I want x264 to replace the lead female actor in every movie with River Tam [07:20:26] <Dark_Shikari> I thought megan fox was the usual target of that [07:20:34] <ohsix> thumbsy [07:20:54] <elenril> she does not have huge eyes << at least she has a hat [07:20:59] <Tjoppen> oops, forgot about my question here [07:21:24] <Tjoppen> but yeah, the qt spec is quite lacking, despite (or because of?) its large scope [07:21:35] <av500> Dark_Shikari: I expect it to be a configure option [07:33:59] <kierank> Tjoppen: you could also on the mov mailing list; maybe even mp4-tech if you want [07:36:16] <Tjoppen> I'm going to try staring at hexdumps of proper files muxed by final cut pro first [07:38:36] <mru> Dark_Shikari: where did the pics go? [07:39:46] <Dark_Shikari> mru: moved, I'm going to do a proper blind psy test on doom9 [07:41:07] <Dark_Shikari> http://forum.doom9.org/showthread.php?p=1397981 [07:50:22] <superdump> yey for svt [07:50:24] <superdump> :) [07:50:42] <Dark_Shikari> and 65mm film and absurdly short exposure times [07:50:56] <kierank> hehe "VP8 (if you have the encoder for this, please contact me directly and we can arrange for just the decoded output to be uploaded)" [07:51:21] <kierank> but yes afaik there are many non-google entities with an encoder [07:51:34] <spaam> superdump: what did svt do this time ? :) [07:52:07] <Dark_Shikari> spaam: create the most insanely high quality 2160p sources ever [07:52:31] * superdump looks forward to the results [07:52:49] <spaam> Dark_Shikari: ok :D [07:55:19] <mru> Dark_Shikari: why mpeg1? [07:55:22] <mru> why not mpeg2? [07:55:32] <mru> does mpeg1 even allow such resolutions? [07:57:50] <Dark_Shikari> ffmpeg defaulted to mpeg1 [07:57:58] <Dark_Shikari> and I doubt mpeg2 will give any different results [07:58:02] <Dark_Shikari> they're nigh-identical on progressive content [07:58:08] <mru> sure [07:58:18] <Dark_Shikari> also, for some reason, mpeg-1 had more coherent motion vectors (less smearing) in ffmpeg than mpeg-4 [07:58:19] <mru> ffmpeg doesn't encode D-frames iirc [07:58:31] <Dark_Shikari> maybe it's MV costs/mv pred [07:58:34] <Dark_Shikari> wtf is a d-frame [07:58:40] <mru> something they dropped in mpeg2 [07:58:53] <Dark_Shikari> what is it though [07:59:02] <mru> don't remember [07:59:12] <kierank> dc only frame, to aid fast seeking [07:59:21] <Dark_Shikari> wait what [07:59:32] <kierank> http://en.wikipedia.org/wiki/MPEG-1#D-frames [07:59:33] <Dark_Shikari> wouldn't dc only look a bit crap? [07:59:36] <mru> sounds useless [07:59:50] <kierank> well consider the crap equipment at the time [08:09:01] <CIA-7> ffmpeg: michael * r23040 /trunk/libavformat/asfdec.c: [08:09:01] <CIA-7> ffmpeg: Favor chunk size over hitting the correct position after reading the chunk size in asf. [08:09:01] <CIA-7> ffmpeg: Fixes issue1923 [08:09:10] <Dark_Shikari> oh yeah, so anyone want to fix theora decoding? [08:09:12] <Dark_Shikari> currently borked [08:09:18] <Dark_Shikari> decoder ignores the pixel offset [08:09:27] <mru> oh that misfeature [08:09:28] <Dark_Shikari> i.e. the cropflags [08:09:35] <Dark_Shikari> mru: h264 has the same feature [08:09:45] <mru> still a misfeature [08:09:51] <Dark_Shikari> true. [08:09:53] <mru> you only need bottom/left cropping [08:09:56] <mru> never top/right [08:10:00] <Dark_Shikari> yeah but theora decoder ignores bottom too. [08:10:03] <mru> s/left/right [08:10:36] <Dark_Shikari> this should really be fixed before 0.6 [08:14:10] <superdump> then poke siretart about it [08:14:30] <mru> and Yuvi [08:15:41] <Dark_Shikari> it was responsible for fucking up MSU's theora test btw [08:15:51] <Dark_Shikari> they got hliariously low psnr/ssim scores on their 1080p clip [08:15:56] <Dark_Shikari> because ffmpeg ignored the offsets [08:16:20] * mru blames them for not checking better [08:16:27] <mru> and for using the stupid offset in the first place [08:16:52] <Dark_Shikari> yes its their fault for being idiots [08:32:21] <kshishkov> isn't that a side effect of using Windows DIB decoding order somewhere? [08:33:32] <mru> so don't do that then [08:33:46] <kshishkov> ok, I won't, now tell Monty [08:33:55] <mru> don't be monty then [08:34:03] <kshishkov> I'm not [08:34:46] <wbs> dib decoding order, as in, bottom to top? [08:35:15] <kshishkov> yes [08:35:22] <wbs> gah [08:35:24] <kshishkov> in traditional Russian way [08:35:27] * wbs facepalm [08:35:41] <kshishkov> IIRC it occurs in some lousy JPEG hacks too [08:42:49] <mru> no jpeg hack can beat the mad stuff that ijg guy is dreaming up [08:43:54] <kshishkov> but that's also jpeg hacks [08:44:31] <kshishkov> or do you treat it like theorazed JPEG? [08:45:17] <mru> I wonder if that guy reads my blog... [08:45:22] <mru> probably not [08:45:58] <kshishkov> why should he read anything? [08:46:16] <mru> when he can make stuff up [08:47:18] <mru> he and monty should get together and design a codec [08:47:33] * kshishkov thinks that Netherlands is the biggest supplier of popular information medium [09:02:18] <Dark_Shikari> hmm. xvid beats dirac. [09:02:37] * Dark_Shikari thinks the decision to switch fullpel-only in dirac by default was _retarded_ [09:02:49] <av500> Dark_Shikari: url? [09:02:55] <av500> (for the xvid) [09:03:28] <Dark_Shikari> http://mirror05.x264.nl/Dark/Flash/compare/xvid.png [09:05:43] <mru> fixed the bitrate? [09:05:53] <Dark_Shikari> yes [09:05:58] <Dark_Shikari> beats the shit out of ffmpeg mpeg4 too [09:06:05] <Dark_Shikari> largely because it doesn't have the lolsmearing [09:06:51] <mru> rather bad ringing though [09:07:03] <Dark_Shikari> ringing? in my 8x8dct-based video format? [09:07:12] <superdump> Dark_Shikari: hmm, vp7 doesn't actually look too bad compared to theora [09:07:18] <mru> and what's the patchy quality of the grass with all the codecs? [09:07:29] <mru> superdump: _anything_ looks good beside theora [09:07:30] <Dark_Shikari> mru: well, except for x264 [09:07:52] <Dark_Shikari> grass looks outright flawless in x264 [09:07:52] <mru> yes, except that [09:08:01] <Dark_Shikari> two reasons [09:08:03] <Dark_Shikari> AQ, MB-tree [09:08:08] <Dark_Shikari> the grass predicts nearly perfectly from frame to frame [09:08:13] <Dark_Shikari> unlike the trees, which occlude [09:08:20] <mru> why do they turn some parts into a total blurfest and leave loads of detail in others? [09:08:24] <Dark_Shikari> Thus, MB-tree says "make the grass really high quality, because it predicts so well between frames" [09:08:32] <Dark_Shikari> mru: no AQ [09:08:40] <mru> I mean the grass between the path and the water [09:08:44] <Dark_Shikari> Yes [09:09:09] <av500> Dark_Shikari: I will blog post now that theora beats svq1... [09:09:13] <Dark_Shikari> lol [09:09:20] <Dark_Shikari> I think we knew that [09:09:36] <mru> why is the quality so variable across the grass? [09:09:46] <Dark_Shikari> as I said, lack of AQ [09:10:04] <Dark_Shikari> constant quantizer != constant visual quality [09:10:28] <Dark_Shikari> if you have some value X, and you quantize it to some level of precision, the relative error depends on the magnitude of X [09:10:35] <Dark_Shikari> thus, small values of X will have high relative error [09:10:38] <Dark_Shikari> and large values will have low relative error [09:10:47] <Dark_Shikari> thus, small values of X need to be quantized to higher precision than large values of X [09:10:57] <Dark_Shikari> thus, to keep constant relative error, you need variable quantizer. [09:10:58] <Dark_Shikari> qed. [09:11:43] <mru> xvid does better on the bright areas [09:11:55] <Dark_Shikari> constant quant codecs do better on the bright areas [09:12:02] <Dark_Shikari> With the bits they stole from the grass ;) [09:12:18] <mru> I mean the brighter parts of the grass [09:12:22] <mru> are better than the dark parts [09:12:25] <mru> of the grass [09:12:26] <Dark_Shikari> Yes [09:12:29] <Dark_Shikari> because they're higher-contrast [09:12:32] <Dark_Shikari> higher-variance [09:12:39] <Dark_Shikari> thus, they have lower relative error [09:12:51] <av500> wanst dirac supposed to be good, but cpu extreme? [09:12:53] <mru> x264 has some horrible ringing on the people [09:13:12] <Dark_Shikari> it has lots of ringing everywhere [09:13:16] <Dark_Shikari> that's just where it's most noticable [09:13:25] <mru> yes [09:13:28] <Dark_Shikari> the rest of the image masks it awa [09:13:29] <Dark_Shikari> *away [09:13:40] <Dark_Shikari> also, mb-tree hurts the people [09:13:45] <Dark_Shikari> because they don't predict well between frames [09:13:46] <mru> it's hard to tell ringing from actual grass [09:13:47] <Dark_Shikari> (sorry, people) [09:13:57] <mru> are they women by any chance? [09:14:04] * mru always had trouble predicting women [09:14:06] <Dark_Shikari> lol [09:15:07] <Dark_Shikari> the really amazing thing is that x264 clip has quants through the roof (35-40) [09:15:14] <Dark_Shikari> but you wouldn't guess it from the visual results. [09:15:48] <Dark_Shikari> I'm curious how well the h265 proposals do [09:17:35] * Kovensky never heard of anything about h265 other than "it exists" [09:17:39] <Kovensky> or "will exist" [09:17:59] * av500 waits for h666 [09:18:20] <Dark_Shikari> there are about 25 proposals [09:18:30] <Dark_Shikari> the bbc one looks good. [09:18:58] <superdump> gooooo bbc [09:19:05] <superdump> if they actually make something good [09:19:08] <astrange> http://ftp3.itu.int/av-arch/jctvc-site/2010_04_A_Dresden/ ? [09:19:14] <Dark_Shikari> maybe I should have taken their offer to work on it [09:19:26] <superdump> Dark_Shikari: really? 35-40? i would _not_ have guessed that at all [09:19:29] <superdump> that's impressive [09:19:29] <Dark_Shikari> astrange: yes [09:19:39] <Dark_Shikari> A124 is the interesting one [09:19:40] <Dark_Shikari> Oh. [09:19:43] <Dark_Shikari> A125 was the real BBC one [09:19:49] <Dark_Shikari> T. Davies' one [09:20:46] <kierank> have you tried the A125 software on that svt clip? [09:20:55] <Dark_Shikari> superdump: yeah, P-frames are 30-45, centered around 35-45 [09:20:58] <Dark_Shikari> kierank: software? [09:21:12] <kierank> I mean A124 [09:21:12] <Dark_Shikari> the proposal came with software [09:21:13] <Dark_Shikari> ? [09:21:22] <kierank> a124 has software [09:21:27] <Dark_Shikari> oh sweeet [09:21:32] <Dark_Shikari> will do that [09:21:36] <CIA-7> ffmpeg: michael * r23041 /trunk/libavfilter/vf_scale.c: Support setting flags for sws. [09:21:46] <Dark_Shikari> superdump: 40-45 quant in the b-frame [09:21:50] <superdump> :) [09:21:55] <superdump> x264 voodoo magic [09:22:16] <superdump> it's clear x264 wins, but maybe vp8 won't be godawful [09:22:25] <Dark_Shikari> I think it will be. too psnr-optimized [09:22:48] <superdump> but maybe the if the specs are opened and the source opened, something can be done about it [09:23:18] <Dark_Shikari> Maybe. [09:23:20] <CIA-7> ffmpeg: michael * r23042 /trunk/libavfilter/ (Makefile allfilters.c): Enable vsrc_buffer [09:23:29] <Dark_Shikari> I think it's just going to cause even more incompatibility [09:23:32] <Dark_Shikari> apple and microsoft won't adopt it [09:23:33] <astrange> it sounds like there might not be a base to improve from [09:23:37] <Dark_Shikari> and yeah, that [09:23:38] <merbzt> maybe the flying pigs are getting back from skiing vacation in hell also [09:23:43] <astrange> if it doesn't have b-frames or better delta quant [09:23:59] <astrange> (i know it doesn't have b-frames, but it might at least have skippable ones) [09:24:00] <kshishkov> merbzt: you mean Iceland? [09:24:14] <merbzt> kshishkov: about right [09:24:15] <Dark_Shikari> oh sweet. kierank, they have source [09:24:35] <kierank> C++ ;) [09:24:57] <lu_zero> as usual... [09:25:05] * lu_zero points dirac [09:28:50] <Dark_Shikari> what. only a visual studio project file? :/ [09:29:36] <kierank> that too [09:29:48] <Dark_Shikari> at least it compiled without errors [09:30:05] <Kovensky> lol [09:30:19] <mru> that's highly unusual [09:31:09] <Dark_Shikari> .... this is going to take a long, long time. [09:32:00] <Dark_Shikari> all of their samples are absurdly short [09:32:14] <Dark_Shikari> this doesn't bode well for encoding a 1080p sample that's 500 frames [09:32:36] <Dark_Shikari> wooohooo singlethreaded encoder with no asm [09:32:46] <mru> the sample needs to be a few times longer than your rate control window [09:32:54] <Dark_Shikari> it does constant qp only [09:32:56] <lu_zero> btw what do they propose? [09:32:57] <superdump> Dark_Shikari: well, they only need to encode one gop, right? and that's at most (being generous) 20 frames, right? [09:33:06] <superdump> how many frames do they need?:) [09:33:20] <Dark_Shikari> 24 frames is enough for anyone. [09:33:33] * Dark_Shikari opens motion search file [09:33:36] * Dark_Shikari sees 4000 lines of C++ [09:33:39] * Dark_Shikari runs like a little girl [09:33:45] <mru> pirate rips use ~250-frame gops [09:33:51] <kierank> a124 has rotation in it [09:33:54] <lu_zero> I'd run faster [09:33:58] <Dark_Shikari> holy fuck, a124 even has rotation? [09:34:02] <superdump> i liked one of the comments on a slashdot article about ceph, the very high capacity distributed filesystem [09:34:13] <superdump> something like 640 petabytes is enough for anyone [09:34:14] <Dark_Shikari> a guy implemented that in x264 the other day [09:34:24] <Dark_Shikari> it gave ~9% compression improvement on elephant's dream, apparently [09:34:27] <Dark_Shikari> (and in libavcodec) [09:34:33] <superdump> nifty [09:34:39] <mru> and you can very well need many gops to properly test the rate control [09:34:41] <superdump> how does that work? [09:34:45] <Dark_Shikari> I don't fully trust his results, but either way it's pretty cool [09:35:00] <Dark_Shikari> mru: I just use constant quality for any encoder which doesn't give good results ratecontrol-wise [09:35:13] <iive> Dark_Shikari: h264 have rotation too? [09:35:30] <mru> Dark_Shikari: but constant quality is mostly useless for practical purposes [09:35:30] <Dark_Shikari> iive: no [09:35:42] <mru> you almost always have some constraints [09:35:44] <Dark_Shikari> mru: I'd say capped constant quality is useful for the vast majority of purposes [09:36:25] <Dark_Shikari> oooh fun, they have in-intra motion vectors [09:36:29] <superdump> for audio (music) constant quality is fine because the variability is insignificant compared to the space available on the storage medium [09:36:31] <superdump> usually [09:36:40] <mru> we're talking about video [09:36:43] <superdump> right [09:36:49] <mru> video will always be pushing the limits [09:36:52] <mru> all the limits [09:37:08] <superdump> i'm still not fond of constant quality modes for video [09:37:14] <mru> instantaneous rate, total size, decoder speed etc [09:37:22] <superdump> because some content will come along that will be much larger than i wanted [09:37:31] <Dark_Shikari> oh dear. [09:37:33] <Dark_Shikari> it's been 10 minutes [09:37:36] <Dark_Shikari> output file is still 0kb [09:37:39] <mru> lol [09:37:41] <superdump> :) [09:37:42] <Dark_Shikari> oh nevermind, it's 96kb now. [09:37:46] <av500> Dark_Shikari: extrapolate [09:37:50] <superdump> lol [09:37:54] <Dark_Shikari> POC 0 ( I-SLICE, QP 35 ) 811576 bits [Y 34.1849 dB U 35.6192 dB V 3 [09:37:57] <Dark_Shikari> 7.8339 dB] [ET 333 ] [L0 ] [L1 ] [09:38:00] <Dark_Shikari> One frame outputted, woohoo [09:38:11] <kierank> lol [09:38:13] <Dark_Shikari> And since it has only constant quant, getting the right bitrate is going to require newton's method [09:38:29] * Kovensky pats D_S [09:38:39] <Dark_Shikari> oh yeah, and this is using diamond motion search [09:38:40] <iive> Dark_Shikari: somehow i hoped it would be 10 minutes in 94kb. [09:38:41] <Dark_Shikari> not even full search [09:38:58] <Dark_Shikari> oh wait, that was an I-frame. I wonder how long P-frames take. [09:39:26] <Kovensky> iive: can x264 do that for an absurdly long gop blankclip with dedup? =p [09:39:44] <Dark_Shikari> "ET" I wonder if that means encoding time [09:39:59] <mru> I think we all know what ET means... [09:40:19] <mru> was this codec submitted by the area51 guys? [09:40:36] <Dark_Shikari> samsung. close enough [09:40:51] <mru> those crazy koreans [09:41:00] <Dark_Shikari> and bbc. [09:41:19] <av500> those crazy brits [09:41:32] <mru> the koreans are good people [09:41:40] <mru> don't know if the same can be said of the brits [09:41:47] <Dark_Shikari> the brits are funny people [09:42:04] <Dark_Shikari> kierank: you deleted nutjobs.png! [09:42:44] <kierank> gimme a minute to restore it [09:43:17] <Dark_Shikari> still encoding the first P-frame. [09:43:26] <kierank> https://dl.dropbox.com/u/2701213/nutjobs.PNG [09:43:30] <Dark_Shikari> I think by the time this is done h265 will already be out [09:43:37] <Dark_Shikari> mru: see above link [09:43:58] <Kovensky> Dark_Shikari: what was it tuned for, cif? =p [09:43:59] <kshishkov> Dark_Shikari: aren't they going to evaluate all encoders by committee? [09:44:13] <CIA-7> ffmpeg: michael * r23043 /trunk/ffmpeg.c: avfilter support for ffmpeg [09:44:14] <Dark_Shikari> a very very slow committee [09:44:25] <Dark_Shikari> \o/ [09:44:28] <Dark_Shikari> \o/ \o/ \o/ [09:44:29] <wbs> \o/ [09:44:32] <Dark_Shikari> \o/ \o/ \o/ \o/ \o/ [09:45:00] <astrange> http://ftp3.itu.int/av-arch/jctvc-site/2010_04_A_Dresden/JCTVC-A023.doc want to order 4k test sequences? [09:45:08] <astrange> or maybe you have to be in jvtvc [09:45:26] <Dark_Shikari> let's take bets on the encoding time of this first P-frame at 1080p [09:45:39] <kshishkov> well, if you test 16CIF or better you may end doing bad job on sub-DVD videos [09:45:47] <Dark_Shikari> I will bet 800 seconds. [09:46:18] <av500> Dark_Shikari: at least they pinned large target marks at the right place... [09:46:40] <Dark_Shikari> and I thought "seconds per frame" was slow [09:46:44] <av500> I like it how ffplay handles the dirac sample: http://imagebin.ca/view/39LOqr2.html [09:46:55] <av500> almost prefer it to the bink rendering [09:46:59] <Dark_Shikari> ffmpeg handles it fine here [09:47:08] <kshishkov> Dark_Shikari: well, you'll get reasonable "annual frames" rate though [09:47:21] <Dark_Shikari> ugh, I think my 800 will end up being wrong [09:49:04] <Dark_Shikari> >RD picture selection [09:49:05] <Dark_Shikari> oh dear. [09:49:11] <Dark_Shikari> >Max QP for RD picture selection [09:49:13] <Dark_Shikari> oh dear oh dear. [09:49:23] <Dark_Shikari> I get the feeling they're doing bruteforce RD of each B-frame's QP [09:49:38] <mru> av500: wtf is that? [09:50:08] <kshishkov> "it's your FFmpeg decoder on drugs^W^Wmiscompiled with icc" [09:50:17] <av500> that is my ~1y old system ffmpeg [09:50:50] <av500> ffmpeg-0.5.20592svn-0.pm.1.5 [09:50:55] <Dark_Shikari> god damn this thing is so slow that x264 better lose to it [09:51:19] <astrange> decoding is 2.4x slower than jm, not surprising [09:51:37] <Dark_Shikari> 12-tap luma interpolation [09:51:40] <Dark_Shikari> <3 [09:51:41] <mru> ouch [09:51:49] <Dark_Shikari> up to 64x64 transform size [09:51:59] * mru wants wider simd [09:52:04] <mru> much wider [09:52:08] <Dark_Shikari> Yeah, at least this will make wide SIMD useful [09:52:26] <mru> 128 bits is starting to look small [09:52:27] <astrange> much wider than avx and you'll have a gpu [09:52:38] <Dark_Shikari> astrange: gpu isn't much wider than avx [09:52:43] <Dark_Shikari> usually it's like 16-wide or 32-wide [09:52:46] <mru> hopefully it can be done in 16-bit arith [09:52:49] <Dark_Shikari> which is only 16*8 = 128-bit [09:52:51] <Dark_Shikari> or 256-bit [09:52:57] <Dark_Shikari> mru: yes it can [09:53:04] <Dark_Shikari> it's a combination of a 16-bit 16x16 transform, plus lifting [09:53:13] <astrange> but there's a very wide pipeline for each warp [09:53:18] <astrange> not sure how wide [09:53:20] <Dark_Shikari> 16 or 32 is "very wide"? [09:53:38] <Dark_Shikari> 970 seconds! The first P-frame finished! [09:53:46] <Dark_Shikari> POC 8 ( P-SLICE, QP 36 ) 501680 bits [Y 34.1692 dB U 35.5716 dB V 3 [09:53:49] <Dark_Shikari> 8.4446 dB] [ET 970 ] [L0 0 ] [L1 ] [09:54:13] <iive> so ET is elapsed time ? [09:54:21] <mru> faster than rendering BBB at least [09:54:23] <Dark_Shikari> I think so. [09:54:55] <iive> Dark_Shikari: i think it would be faster if you port/write some asm, while waiting for the next 10 frames. [09:54:58] <Dark_Shikari> lol [09:55:02] <Dark_Shikari> that's probably true. [09:55:12] <Dark_Shikari> pengvado said it was faster to optimize JM than to wait for it to finish [09:55:18] <av500> binary patch the running encoder.... [09:55:41] <Dark_Shikari> also, we apparently scared the shit out of the x264 ppc maintainer [09:55:44] <Dark_Shikari> I showed him the NV12 patch [09:55:46] * mru like binpatching stuff [09:55:55] <Dark_Shikari> and said "you need to port the altivec" [09:56:07] <mru> who's the maintainer? [09:56:13] <Dark_Shikari> guilliame poirier [09:56:14] <astrange> http://www.mysif.ru/Files/SIF1_v_1_01.exe you can encode through that while you're waiting [09:56:19] <Dark_Shikari> (I can never spell that right) [09:56:27] <mru> guillaume? [09:56:28] <Dark_Shikari> astrange: oh, good point. I should totally test SIF1 [09:56:49] <Dark_Shikari> astrange: encoder and decoder? [09:56:58] <astrange> i haven't looked but i think so [09:57:13] <Dark_Shikari> oh, its vfw [09:58:05] <Dark_Shikari> >height must be a multiple of 16 [09:58:06] <Dark_Shikari> fuck you [09:58:23] <Dark_Shikari> ugh, now I need code to pad the bottom of the frame in avisynth by repeating the last line [09:59:16] <Dark_Shikari> aha. I can use stackvertical because I'm a horrible person [09:59:35] <astrange> stackvertical(c, flipvertical(c)) [10:01:01] <Dark_Shikari> I did: [10:01:02] <Dark_Shikari> a=b.converttorgb().crop(0,1080-1,1920,1) [10:01:02] <Dark_Shikari> a=stackvertical(a,a) [10:01:02] <Dark_Shikari> a=stackvertical(a,a) [10:01:02] <Dark_Shikari> a=stackvertical(a,a).converttoyv12() [10:01:04] <Dark_Shikari> stackvertical(b,a) [10:01:07] <Dark_Shikari> aka "lol" [10:02:53] <Dark_Shikari> woohoo, sif1 is about 1000 times faster than a124 [10:03:20] <Dark_Shikari> mru: by the way, an nv12 internal representation is faster than yv12 for many purposes. [10:03:28] <Dark_Shikari> especially on cpus with small caches. hint hint. [10:03:35] <iive> i missed the introduction. are these h265 candidates? [10:03:44] <Dark_Shikari> sif1 is some random russian guy's codec [10:03:48] <Dark_Shikari> a124 is an h265 candidate from bbc+samsung [10:03:49] <CIA-7> ffmpeg: michael * r23044 /trunk/libavfilter/ (avfilter.c avfilter.h vf_scale.c vsrc_buffer.c defaults.c): Try to keep track of interlaced and top field first. [10:04:14] <Dark_Shikari> a124 has encoded two frames so far. [10:05:36] <mru> Dark_Shikari: nv12, is that the one with an interleaved uv plane? [10:05:44] <Dark_Shikari> yes [10:05:56] <mru> yeah, that should be faster in some cases [10:06:02] <Dark_Shikari> it's 1% faster in x264, overall [10:06:04] <Dark_Shikari> on x86 [10:06:09] <iive> Dark_Shikari: are you using it as native format? [10:06:12] <Dark_Shikari> 4% faster on Some Magical Mystery CPU That Pengvado Can't Talk About [10:06:13] <Dark_Shikari> iive: yes [10:06:47] <mru> it also lets you do both chroma planes in parallel sometimes [10:07:00] <Dark_Shikari> yes it helps for chroma motion search [10:07:04] <Dark_Shikari> but nobody does fullpel chroma ME anyways [10:07:15] <iive> Dark_Shikari: have you tested to have one line luma and one line chroma samples, using stride/linesize arithmetic? [10:07:33] <Dark_Shikari> that won't help [10:07:36] <siretart> superdump: Dark_Shikari: fix it in trunk and make a remark in the commit message! [10:07:41] <mru> it's not just in ME it's useful [10:07:52] <Dark_Shikari> mru: chroma MC is complicated enough that it doesn't help there either, [10:07:55] <Dark_Shikari> since you have to unpack to 16-bit anyways [10:07:58] <Dark_Shikari> It does help in deblocking though. [10:08:12] <mru> and sometimes transform [10:08:31] <Dark_Shikari> no [10:08:42] <Dark_Shikari> requires way too much munging for that [10:08:53] <Dark_Shikari> in x264, we store frame data as NV12 [10:08:57] <Dark_Shikari> but cache data as YV12 [10:09:09] <Dark_Shikari> chroma MC thus effectively performs deinterleaving [10:09:20] <mru> I'm not talking about x264 specifically [10:09:36] <mru> 128-bit simd can do two 4x4 transforms in parallel [10:09:55] <Dark_Shikari> you can do that without NV12 [10:10:04] <mru> sure [10:10:09] <Dark_Shikari> it doesn't help you there imo [10:10:21] <mru> doesn't harm either [10:10:28] <Dark_Shikari> er... yes it does [10:10:33] <mru> why? [10:10:34] <Dark_Shikari> interleaved data is more messy to transform [10:10:41] <Dark_Shikari> you can't do horizontal arithmetic as easily [10:10:55] <mru> suppose my simd doesn't do horizontal arithmetic [10:10:56] <Dark_Shikari> because a horizontal arithmetic operation becomes an operation between U and V [10:11:02] <Dark_Shikari> instead of between adjacent U/V [10:11:06] <Dark_Shikari> Sure, in that case maybe [10:11:08] <Dark_Shikari> but that's shitty simd =p [10:11:15] <mru> it's non-x86 simd [10:11:29] <Dark_Shikari> blackfin? [10:11:34] <mru> arm, ppc, anything [10:11:45] <kshishkov> SWAR too [10:11:49] <Dark_Shikari> neon has horizontal arithmetic [10:11:50] <Dark_Shikari> vhadd, etc [10:11:57] <mru> that's average [10:12:07] <mru> vertical average [10:12:07] <Dark_Shikari> er, whatever the one is that adds horizontally [10:12:19] <mru> the only horizontal operation is vpadd [10:12:22] <mru> pairwise add [10:12:26] <Dark_Shikari> that's it? [10:12:32] <mru> not useful in transform [10:12:36] <Dark_Shikari> good thing transpose is fast then I guess [10:12:55] <mru> it transposes pretty quickly, yes [10:13:15] <mru> and the vertical ops are much better than x86 [10:13:30] <mru> vaddl and vaddw are very useful [10:13:46] <mru> add and widen resp add to wide [10:14:01] <mru> saves a separate unpack [10:18:16] <CIA-7> ffmpeg: mru * r23045 /trunk/configure: [10:18:16] <CIA-7> ffmpeg: SPARC: disable VIS for Niagara CPU [10:18:16] <CIA-7> ffmpeg: The Niagara/T1 supports only a subset of VIS, and even this is very slow. [10:18:16] <CIA-7> ffmpeg: Patch by Michael Kostylev <michael kostylev gmail> [10:28:46] <Dark_Shikari> sif1 is done [10:28:59] <Dark_Shikari> http://mirror05.x264.nl/Dark/Flash/compare/sif1.png [10:29:36] <mru> a bit blurry [10:29:53] <Dark_Shikari> It's surprisingly good [10:30:00] <mru> yeah, it's not too bad [10:30:05] <mru> much better than most [10:30:10] <mru> what is that codec? [10:30:11] <Dark_Shikari> oh, forgot to crop it [10:30:13] <Dark_Shikari> sif1 [10:30:24] <mru> wtf is that? [10:30:35] <Dark_Shikari> this random russian guy's custom codec [10:30:44] <mru> oh, one of those [10:30:56] <Dark_Shikari> Yeah. [10:31:03] <Dark_Shikari> It's based on very large DCTs and an adaptive interpolation filter [10:31:12] <mru> let me guess, no spec, no source [10:31:18] <Dark_Shikari> yes source for the decoder [10:31:21] <Dark_Shikari> Which is mostly inline asm. [10:31:26] <mru> about to say [10:31:37] <Dark_Shikari> It's One Of Those. [10:31:41] <Dark_Shikari> But the idea is pretty sound. [10:31:46] <Dark_Shikari> he isn't stupid [10:31:58] <mru> that's why it's better than theora [10:32:07] <Dark_Shikari> I'm really curious how it does in blind tests on the 0-10 scale [10:32:11] <Dark_Shikari> it's much less sharp than vp7 [10:32:17] <Dark_Shikari> But it doesn't lose detail as badly in many areas [10:32:22] <Dark_Shikari> IMO it may actually be better than vp7 [10:32:45] <mru> less sharp is better than full of block edges [10:32:45] <Dark_Shikari> the quality is much more consistent [10:33:07] <Dark_Shikari> x264 of course beats the shit out of it, but that's hardly surprising [10:34:08] * av500 didnt know thresh wrote a codec in secret... [10:34:09] <Dark_Shikari> damn, still only 2 frames done on the h265 encode [10:34:18] <Dark_Shikari> I managed to do the entire SIF1 test in the time that one h265 frame was encoding [10:35:03] <thresh> sounds like Dark_Shikari wrote one too just yet [10:36:25] <Dark_Shikari> hmm, what other silly codecs can I test? [10:36:26] <thresh> or does h265 exist? [10:36:32] <mru> no [10:36:34] <Dark_Shikari> thresh: I'm using the samsung+bbc A124 proposal [10:36:39] <Dark_Shikari> and calling it "h265" for short [10:36:43] <thresh> mmkay [10:37:05] <mru> the final h265 will be some random picking of pieces from the various proposals [10:37:08] <Dark_Shikari> yup [10:37:24] <mru> such that everybody gets their share of patents in the pool [10:37:26] <av500> Dark_Shikari: sif is patented! mozilla will never adopt it [10:38:08] <Dark_Shikari> oh my god [10:38:12] <Dark_Shikari> I just looked at their option handler [10:38:16] <Dark_Shikari> the C++ one in A124 [10:38:21] <Dark_Shikari> They wrote their own option parser... using C strings. [10:38:24] <Dark_Shikari> in a C++ program. [10:38:35] <Dark_Shikari> It's like the worst possible combination of bad ideas ever. [10:38:39] <thresh> maybe they just CP it [10:38:48] <thresh> like, reusing code is good. [10:40:14] * av500 assumes academic people suck at option parsers [10:41:06] <mru> what's wrong with getopt? [10:41:34] <mru> ~100 options ought to be enough for anyone [10:43:15] <av500> hmmm "I assept the agreement (Download)", does it have a legal implication if I "assept" something? [10:48:54] <Dark_Shikari> AGHHHHHHHHHHHHHHHH [10:48:59] <Dark_Shikari> POC 4 ( B-SLICE, QP 37 ) 158488 bits [Y 30.9774 dB U 34.4570 dB V 3 [10:49:02] <Dark_Shikari> 7.6592 dB] [ET 2734 ] [L0 0 8 ] [L1 8 0 ] [10:49:45] <Dark_Shikari> if I was involved in ITU I would disqualify these guys just for giving me an encoder that is so slow it's impossible to test [11:10:04] <Tjoppen> hah. appearently my .mov files cause dumpster to segfault [11:13:13] <Kovensky> your dumpster segfaults? [11:16:22] <Tjoppen> it's a program for "diving into" MOV/MP4 files (heh) [11:17:12] <Tjoppen> hexdump sort of thing. causing it to segfault is rather odd [11:18:49] <Tjoppen> ah. "if (len&1) len += 1;", so I have to write a dummy NUL byte if the length is odd [11:48:05] <CIA-7> ffmpeg: michael * r23046 /trunk/libavfilter/ (Makefile vf_pad.c allfilters.c): Add pad filter. [11:51:47] <CIA-7> ffmpeg: mru * r23047 /trunk/configure: [11:51:47] <CIA-7> ffmpeg: configure: update suncc SPARC CPU name mapping [11:51:47] <CIA-7> ffmpeg: Patch by Michael Kostylev <michael kostylev gmail> [11:52:54] <CIA-7> ffmpeg: michael * r23048 /trunk/ (configure tests/lavf-regression.sh): Enable libavfilter by default and fix pading for mxf-d10 [12:06:14] <CIA-7> ffmpeg: michael * r23049 /trunk/ffmpeg.c: Make sure get_filtered_video_pic() doesnt loose interlacedframe/ttf. [12:17:13] <CIA-7> ffmpeg: michael * r23050 /trunk/ffmpeg.c: [12:17:13] <CIA-7> ffmpeg: Remove messy pading hack in ffmpeg.c. [12:17:13] <CIA-7> ffmpeg: Use avfilters if you want padding! [12:43:27] <CIA-7> ffmpeg: stefano * r23051 /trunk/cmdutils.h: Document cmdutils.c:print_error(). [12:53:36] <CIA-7> ffmpeg: stefano * r23052 /trunk/doc/libavfilter.texi: Document the pad filter. [13:01:45] <CIA-7> ffmpeg: michael * r23053 /trunk/libavfilter/vf_scale.c: c99 sucks. Replacing scanf("%i") by strtoul() [13:24:15] <BBB> why can't I download from upload.mphq.hu anymore? koth? [13:25:37] <mru> how are you accessing it? [13:25:46] <kshishkov> usual permission problem [13:26:02] <kshishkov> I've tried - some files from /incoming are downloading fine, some have 550 error [13:26:47] <mru> can you tell me the name of one with a problem? [13:26:52] <BBB> issue1502/ [13:26:54] <BBB> in incoming [13:27:25] <BBB> I'm accessing it using the regular login, ftp://youknow@upload.mplayerhq.hu/ [13:27:36] <mru> try again [13:27:42] <Dark_Shikari> so far the record is 4955 seconds for one frame [13:27:45] <Dark_Shikari> :awesome: job samsung [13:27:48] <BBB> that was quick [13:27:54] <BBB> thanks mru [13:27:56] <Dark_Shikari> I think their strategy is to make encoding take so long that everyone has to trust their tests on faith [13:28:05] <mru> for some reason the file had absurd permissions [13:28:06] <Dark_Shikari> since nobody has time to replicate their results [13:30:11] * BBB has problems where his fingers want to send the email to sflc already, but his head thinks he should wait a few minutes [13:32:30] <mru> that file has ffmpeg written all over it [13:34:00] <BBB> I know [13:34:09] <BBB> I did nm and all symbols in my terminal were from ffmpeg [13:34:12] <BBB> (without a grep) [13:34:19] <BBB> which is a little funny and excessive [13:34:40] <BBB> also, it's a radio app [13:34:47] <BBB> why are there h264 symbols in it? [13:34:52] <BBB> the thing doesn't even play video [13:35:05] <Dark_Shikari> because disabling h264 doesn't disable the h264 stuff in dsputil? [13:35:16] <BBB> hm... [13:35:20] <BBB> fix it? :) [13:35:47] <mru> some of that has been fixed [13:35:56] <mru> I moved a bunch of h264 stuff out of dsputil [13:36:06] <iive> isn't some of h264 stuff used by other codecs too? [13:36:15] <mru> yes, those parts are still in dsputil [13:36:18] <iive> svq3, vc1, rv34 ? [13:37:56] <jai> btw, i still can't access samples.mphq :| [13:38:21] <mru> jai: why is that? [13:39:18] <jai> mru: HTTP request sent, awaiting response... 403 Forbidden [13:39:38] <mru> url? [13:39:47] <jai> mru: http://samples.mplayerhq.hu/Matroska/haruhi.mkv [13:41:24] <mru> try again [13:41:56] <jai> mru: works :) [13:41:58] <jai> mru: thanks [13:42:13] <mru> just shout if there are permission problems [14:37:02] <Penumbra> Just wanted to say thanks for getting us a DV100 Decoder / Demuxer guys. Any thoughts on a timeframe for an encoder? Is there an ffmpeg roadmap somewhere I can refer to? [14:37:28] <mru> roadmaps are for wimps [14:37:38] <mru> heck, _roads_ are for wimps [14:37:53] <Penumbra> so true [14:38:29] <Dark_Shikari> mru: the first minigop finished! [14:38:36] <Dark_Shikari> only took it about 4-5 hours [14:39:13] <av500> \\\ooo/// [14:39:17] <av500> Dark_Shikari: what PC? [14:40:02] <Dark_Shikari> core i7, 1.6ghz, with turbo boost (notable since it uses only one thread) [14:40:07] <av500> Dark_Shikari: ask janneg if you can have his BBB cluster when he is done rendering :) [14:40:16] <Dark_Shikari> can't cluster it really [14:40:24] <Dark_Shikari> so, interesting notes about the compression results so far [14:40:39] <Dark_Shikari> edge-wise it seems to be very good [14:40:42] <Dark_Shikari> very minimal ringing [14:40:53] <Dark_Shikari> probably due to the improved intra prediction [14:41:08] <Dark_Shikari> no blocks whatsoever [14:41:12] <Dark_Shikari> Also, blurry as hell. [14:42:27] <Dark_Shikari> no banding either, due to the higher internal bit depth iirc [14:42:59] <twnqx> 1. take green greid with 1 px spacing [14:43:05] <twnqx> 2. add red pixels in between [14:43:15] <twnqx> grid* of course... 3. encode [14:43:22] <twnqx> 4. if result is ok, codec is ok :P [14:43:53] <av500> twnqx: you forgot 3.5. decode [14:44:10] <twnqx> well...ok. [14:44:38] <av500> otherwise I have a very optimal encoder for you :) [14:45:05] <kshishkov> mru: "heck, _roads_ are for wimps" <- so you're finally moving to Russia? [14:46:42] <Penumbra> Or jamaica, omg.. Try driving out there in a rain storm. [14:47:18] <kshishkov> try driving in Russian in any weather [14:47:33] <Penumbra> Hmm.. To drive in Russian, must I think in Russian? [14:48:01] * Penumbra fires forward missiles. [14:48:02] <av500> thinking is not required [14:48:26] <Penumbra> Oh good - I'm well prepared then. [14:48:44] <kshishkov> http://www.tema.ru/travel/ee-7/_MG_0049.jpg [14:49:05] <kshishkov> http://www.tema.ru/travel/ee-7/_MG_0055.jpg [14:50:28] <kshishkov> and that's a rather major road through Siberia finished maybe two years ago [14:51:46] <Penumbra> Hey, at least there's a guard rail :) [14:52:27] <Penumbra> And those look about as bad as Jamaica roads. When it rains, the busses forge their own roads. [14:52:58] <av500> Penumbra: ffmpeg roadmap here: http://imagebin.ca/view/ptn3MsN4.html [14:54:10] <av500> kshishkov: potholes are smaller than cars, counts a good road! [14:54:27] <kshishkov> av500: FFmpeg road is E4 :P [15:07:11] <mru> this is my idea of ffmpeg roadmap: http://imagebin.ca/view/RrbiZf.html [15:07:58] <av500> so all that is left is OZ and argentina? [15:09:45] <Compn> kshishkov : potholes! reminds me of detroit roads :) [15:10:59] <av500> mru: the image you uploaded just before that is also not bad... [15:11:01] <kshishkov> Compn: when Ford engineers went to USSR to build GAZ, local roads reminded them of Detroyt twenty years before that [15:11:57] <mru> av500: that wasn't me... you wouldn't get such a small, grainy pic from me [15:12:12] * mru has _standards_ [15:12:44] <av500> http://xkcd.com/598/ [15:12:52] <mru> is that the modem one? [15:12:56] <av500> yup [15:12:57] <kshishkov> those standards should mention small grainy pics, at least ITU T.80 [15:50:12] <peloverde> Did hulu just dump rtmpe or whatever didn't work on flash linux 64? [15:51:30] <peloverde> Also, no spectral holes http://i.imgur.com/9Fo19.png [16:21:43] <chris_c> I'm having some difficulty compiling ffmpeg. I'm getting the following error: undefined reference to `sws_isSupportedOutput'. Is this the right place to ask for help? [16:23:39] <mru> no [16:23:51] <av500> #ffmpeg [16:23:58] <Dark_Shikari> your version of swscale likely doesn't match your version of ffmpeg [16:24:29] <peloverde> if you checkoout and old version or from git swscale must be updated manually [16:24:43] <chris_c> I'm trying to compile ffmpeg without swscale using --disable-swscale [16:25:08] <av500> ah, the cmdutils bug [16:25:28] <chris_c> known issue? [16:26:00] <mru> av500: what bug? [16:26:03] <av500> show_pix_fmts() [16:26:26] <av500> misses some #if CONFIG_SWSCALE or so [16:26:38] <av500> I had that when I compile audio decoders only I think [16:26:54] <chris_c> any workaround? [16:28:56] <av500> try: http://ffmpeg.pastebin.com/eH5PVatt [16:31:06] <chris_c> I'll try your patch av500. Thank you for the help. [16:35:29] <av500> mru: I think all these are needed: http://ffmpeg.pastebin.com/rUQK7Ki6 [16:35:54] <mru> send 'em to the ml, build some cred [16:36:02] <av500> k [16:37:10] <av500> hey you sent one already :) [16:37:23] <mru> yeah, but it ifdefs a bit too much I think [16:37:36] <av500> thats what I thought [16:37:43] <mru> feel free to reply then [16:37:45] <av500> ok [17:54:19] <CIA-7> ffmpeg: mru * r23054 /trunk/libavfilter/vf_pad.c: vf_pad: fix mixed code and declarations [19:16:59] <mru> Dark_Shikari: your blog post is on HN now [19:25:07] <BBB> what is hn? [19:26:49] <janneg> news.ycombinator.com/ [19:41:23] <Dark_Shikari> oh wow [19:41:30] <Dark_Shikari> someone is stalking my blog and submitting it to hn =p [20:05:06] <KotH> jai: yes, i block certain ips [20:05:21] <KotH> jai: if you've problems downloading, please tell me which ip you're comming from [20:05:32] <KotH> Dark_Shikari: hn? [20:05:58] <jai> KotH: hi, no problems now, mru did something that fixed it :) [20:06:45] <mru> KotH: one file wasn't readable by the web server [20:06:46] <KotH> jai: probably unblock your ip :) [20:06:51] <KotH> oh.. [20:06:54] <jai> ah [20:07:01] <BBB> it was a permission issue right? [20:07:04] <KotH> that's a different issue [20:07:10] <BBB> I suppose mru did an elegant version of chmod a+r ... [20:07:23] <jai> ah, my guess was wrong then, sorry for the noise [20:07:23] <KotH> there are certain files, that can only be downloaded if you use the developer login [20:07:39] <KotH> (because they are downloaded so often, that they create too much traffic) [20:07:47] <jai> right, will try with that next time before complaining :) [20:08:02] <mru> Kovensky: is Matroska/haruhi.mkv one of those? [20:08:50] <mru> KotH: ^^ [20:08:55] <ramiro> which filter does avfilter-lavf enable? [20:08:55] <mru> damn tab completion [20:08:56] <KotH> i think so [20:09:15] <mru> what's in that file? [20:09:43] <KotH> it's probably just the name that does it [20:09:49] <jai> good for checking subtitle sync [20:10:01] <KotH> haruhi is one of the more popular animes of the last 2-3 years [20:10:48] <jai> that too :) [20:12:03] <KotH> looks like a full version of the ending of haruhi, with complex ass subs [20:12:16] <KotH> and part of the subs are rendered wrong [20:12:19] <KotH> ^'' [20:12:54] <_av500_> bouillabaisse ftw!!! [20:13:06] <KotH> gesundheit! [20:13:10] <mru> not a word you see every day [20:13:46] <_av500_> yup [20:13:50] <KotH> not a dish you eat everyday either [20:14:35] * KotH remember having cooked one in secondary school or so [20:14:40] <mru> a dish I'd rather never eat [20:14:43] <KotH> or maybe highschooll... dont remember [20:14:50] <KotH> why not? [20:15:00] <mru> shellfish, blegh [20:18:43] <KotH> oh.. i forgot... you dont eat any sea food [20:19:21] * mru doesn't eat insects [20:19:27] <mru> doesn't matter if they live in the sea [20:20:31] <ramiro> http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html is mostly boring, but there's a brilliant quote: "1940s - Various "computers" are "programmed" using direct wiring and switches. Engineers do this in order to avoid the tabs vs spaces debate." [20:22:09] <mru> I thought most of that was funny [20:22:27] <mru> maybe you need to read up on computer history [20:23:03] <jai> KotH: in mplayer? [20:23:23] <KotH> jai: ack [20:23:30] <ramiro> yes, probably. but most of the parts I understood were "meh.." jokes... [20:23:35] <KotH> jai: though an quite old version, ahvent updated in ages [20:24:46] <jai> KotH: ah, renders fine here btw [20:24:47] <mru> "LISP remains an influential language in key algorithmic techniques such as recursion and condescension" [20:24:57] <mru> so that's what cond means... [20:26:10] <KotH> jai: also the kanji on the right side? [20:26:18] <KotH> jai: those are turned by 90° here [20:31:11] * elenril finds the brief history more funny each time he reads it [20:31:12] <astrange> erik naggum is gone so the level of lisp programmer anger has gone down [20:31:57] <mru> "1983 - Bjarne Stroustrup bolts everything he's ever heard of onto C to create C++." [20:32:17] <mru> probably the most accurate description ever [20:33:28] <Dark_Shikari> lol [20:39:37] <mru> hi mmu_man [20:39:51] <mmu_man> plop [20:39:51] <mru> what's the status of ffmpeg on beos/haiku these days? [20:39:57] <KotH> jai: current mplayer still renders the kanjis wrong [20:40:19] <mru> I haven't seen any fixes or patches since my last threat to delete stuff [20:40:37] <mmu_man> mru I had to hack some more *INT64_C() and PRI*() crap around, thx :^) [20:40:57] <mru> haiku doesn't have a working libc? [20:41:07] <mmu_man> it does [20:41:15] <mru> then no hacks should be needed [20:41:23] <mmu_man> Haiku should have those stupid macros now [20:41:25] <mmu_man> BeOS doesn't [20:41:31] <mru> screw beos [20:41:50] <mru> I'll only go so far to support a dead OS [20:42:28] <mmu_man> I tried to add them from configure as -D to avoid patching but passing quotes screws up anyway [20:42:40] <mru> patch the system, not ffmpeg [20:43:14] <mmu_man> I'm not the vendor [20:43:20] <mmu_man> (not anymore :p) [20:43:23] <mru> but it's your computer, no? [20:43:34] <jai> KotH: oh, /me doesn't grok kanji :) [20:43:35] <mmu_man> ... [20:44:15] <KotH> jai: learn some ;) [20:44:27] * mru knows a handful, but probably not that one [20:44:58] <mmu_man> a hangul ? [20:45:01] <mmu_man> ah, handful ;) [20:45:08] * mru knows all hangul [20:45:44] <mru> except the historic ones no longer used [20:45:50] <mmu_man> want to contribute a korean translation in Haiku ? [20:46:01] <mru> I said I know hangul, not korean [20:46:18] <mmu_man> contribute an input method then ;) [20:46:33] <mru> XIM supports it [20:46:42] <mru> oh right... you don't run X :-) [20:46:42] <mmu_man> X ? as in X11 ? [20:46:43] <mmu_man> bleh [20:46:54] <mru> X is great [20:47:03] <mmu_man> aren't you the one talking all day long about ditching antique stuff ? ;) [20:47:09] <mmu_man> X is great [20:47:22] <mru> X is used today [20:47:24] <mru> beos is not [20:47:26] <mru> that's the difference [20:47:30] <mru> C is also old [20:47:43] <mmu_man> not the pile of overly colorful crap you usually put atop [20:47:58] <saintd3v> mru: that whole paragraph on C++ is gold. [20:48:12] <mmu_man> don't get me started on C++ I'm not in the mood [20:48:37] <saintd3v> mmu_man: only if it involves skynet... [21:00:32] <mmu_man> btw, what's up with this Orange thingy ? [21:00:37] <peloverde> It is a syntax error to write FORTRAN while not wearing a blue tie. [21:00:42] <mmu_man> I could try to contact them in french directly [21:02:18] <mru> let our lawyers handle it [21:03:02] <mmu_man> Yeah Go Eben, Go :) [21:04:01] <ramiro> I'm curious. how are developers supposed to test their iphone apps if all programs must come from the app store? [21:04:46] <mru> I think it's possible to run your own apps with the phone in the dock or something [21:05:02] <mru> probably a tad more inconvenient [21:05:13] <mmu_man> cool, so if you want to test a battery indicator ;) [21:05:25] * mru has no apple gear [21:05:50] * mmu_man only has a macbook pro but he had no choice on it, and he can still install what he wants, including another OS if needed [21:05:52] <wbs> when you pay up for a iphone developer account, you can get developer provisioning profiles for your device, so you're able to install apps through xcode onto your device, and run it both connected and disconnected [21:06:01] <_av500_> if you sign up to the appl dev foo, you can self sign test apps [21:06:10] <_av500_> and give them to a few ppl [21:06:19] <mmu_man> pay ? [21:06:23] <mmu_man> did he say pay ? [21:06:25] <mmu_man> bleh [21:06:28] <mru> pay for the right to write apps? [21:06:30] <mru> no thanks [21:06:44] <_av500_> $99 afaik [21:06:45] <wbs> you can also sign apps for so called "ad hoc distribution", that they can install through itunes, but you're limited to a max of 100 devices or so [21:06:49] <mmu_man> didn't Steevo criticise Flash for notr being open ? ;) [21:06:57] <_av500_> what wbs said [21:06:58] <ramiro> per year? [21:07:05] <_av500_> iirc [21:07:08] <wbs> ramiro: yeah [21:07:13] <ramiro> yikes [21:07:16] <mru> mmu_man: did anyone ever say his jobsness had to be rational? [21:07:27] <ramiro> and how hard is it to jailbreak? =) [21:07:34] <mru> not [21:07:38] <mmu_man> mru he's anything but rational [21:07:50] <mru> of course not [21:07:55] <mru> no cult leaders are ever rational [21:07:55] <wbs> ramiro: not hard for a techy guy, but it's a bit limited market to distribute apps on [21:08:54] <wbs> and the best thing is of course that dynamic linking is forbidden, so if you want to use third party libs, they have to be statically linked, so to comply with lgpl, you have to hand out object files [21:08:57] <ramiro> hm, I was more interested in running an ssh deamon for FATE [21:09:25] <wbs> ah, that should be very well possible, you're usually able to install openssh-server with a few clicks [21:09:30] <mru> ramiro: I've been told that's impossible [21:10:05] <ramiro> why? [21:10:10] <_av500_> mru: should work on a jailbroken one [21:10:16] <_av500_> i sshed into mine [21:10:22] <mru> because it's against the will of the jobs I guess [21:10:32] <mru> will it do nfs though? [21:10:40] <mru> that's pretty much required for fate [21:10:42] <wbs> not easily at least [21:10:50] <mru> or some network filesystem [21:10:56] <ramiro> sshfs? [21:10:58] <_av500_> mru: it wont netboot :) [21:11:47] <ramiro> anyways, that would be fun to try, if I do get an iPhone... [21:11:51] <wbs> I tried hacking something together to run regtests by transferring samples/binaries back and forth without any network filesystem, but the connection was so unreliable so I wasn't able to run a full test round [21:12:06] <mmu_man> mru well, in case you didn't notice you assumed the role of (benevolent ?) dictator on ffmpeg recently :p [21:12:25] <ramiro> I'm not using it on the streets. I'm fine with my nokia 1108, the flashlight that supports SMS. [21:12:27] <wbs> it was android in that case; the connection utility adb (used for doing remote commands or file transfers) gave spurious errors every 100 executions or so ;P [21:12:29] <ramiro> and calls too [21:12:30] <mru> mmu_man: not at all [21:12:36] <mmu_man> tss tss [21:12:36] <mru> I only rule over a couple of provinces [21:13:04] <mmu_man> ah so you're a vassal ? :p [21:14:43] <_av500_> lol http://www.theregister.co.uk/2006/01/11/exception_handling/page2.html [21:15:14] <mru> "When should you raise an exception?" [21:15:18] <mru> why, never of course [21:15:26] <mru> unless you're hardware [21:15:50] <_av500_> wbs: yes, adb can suck [21:16:19] <mru> wbs: but android can run anything, no? [21:16:36] <_av500_> anything? [21:16:56] <wbs> anything, as in runs binaries and whatnot without jailbreaking, yeah [21:17:47] <mru> so you could install sshd [21:18:05] <_av500_> network is tricky [21:18:15] <_av500_> android polices net access [21:18:20] <ramiro> gprs! [21:18:29] <wbs> you don't have root on devices (unless you root it, which is more or less like jailbreaking i guess) [21:18:29] <mru> but why bother? it's just linux anyway [21:18:50] <wbs> with a very special libc ;P [21:19:00] <_av500_> wbs: just put another one [21:19:11] <mru> if we wanted to test stuff on android, I'd suggest doing a custom-built one with ssh and nfs support [21:19:33] <_av500_> compiling ffmpeg gainst bionic [21:19:34] <mru> or link against the android libc on top of a normal linux install [21:20:01] <Yuvi> ramiro: it's possible, but when I tried running fate on my ipod it still wasn't done after 6 hours [21:20:09] <BBB> ramiro: developer program allows you to install profiles on your phone [21:20:15] <BBB> with a profile installed, you can test self-compiled apps also [21:20:20] <BBB> no dock or anything necessary [21:20:24] <BBB> it's just like a regular app [21:21:13] <ramiro> Yuvi: well the ipod has no neon right? [21:21:15] <Yuvi> doesn't help that each ssh connection took ~5 seconds to setup for some reason [21:21:17] <BBB> you install it directly in xcode, it is pretty well-integrated and has "export to device" functionality built-in [21:21:23] <Yuvi> ramiro: ipod touch 3g does [21:21:41] <ramiro> oh, you have one of the good ones... [21:21:45] <mru> not the 8GB one [21:21:48] <Yuvi> no, mine's first gen [21:22:05] <ramiro> mine's whatever was cheapest in 2008 with 80gb [21:22:20] <Yuvi> so a classic, without iphone os [21:22:23] <ramiro> an ipad might be interesting to test. [21:22:37] <peloverde> I feel like the pre iphone OS ipods are no longer relevant [21:23:04] <BBB> you can't install apps on them, so what's the point? [21:23:16] <ramiro> what os do the classic ipods have? [21:23:19] <BBB> peloverde: target audience was teen-twenty kids [21:23:22] <ramiro> BBB: you can play music! [21:23:23] <ramiro> hehe [21:23:25] <BBB> peloverde: they play games [21:23:31] <BBB> peloverde: they want the ipod touch nowadays [21:23:42] <BBB> I sometimes see grandpas in the subway with a classic ipod [21:23:46] <BBB> otherwise they've vanished [21:23:50] * _av500_ wants the classic [21:23:54] <BBB> my wife has one, she never uses it, uses the iphone instead [21:24:05] <mmu_man> if anyone has a spare iPad... I'd port Haiku to it :p [21:24:07] <Yuvi> ramiro: no real os afaik [21:24:14] <peloverde> I don't use my ipod video anymore [21:24:16] <mmu_man> hmm well I'm too busy anyway [21:24:18] <peloverde> ramiro, rockbox [21:24:21] <peloverde> at least on mine [21:24:31] <mru> ipad is just a bigger iphone [21:24:39] <BBB> cannot call [21:24:42] <mru> here's a cheaper option: http://appadvice.com/appnn/2010/04/humor-free-iphonetoipad-upgrade/ [21:24:42] <_av500_> heretics [21:25:05] <Yuvi> mru: I thought so too until I used one [21:25:25] <mru> I guess it's slightly more effective in a bar fight [21:25:41] <peloverde> I really don't know what I'd do with an iPad if I had one [21:25:43] <_av500_> in a german beer bar? [21:25:57] <mru> there's usually no fight without beer [21:26:11] * mru usually stays out of fights [21:26:24] <ramiro> unless they're virtual [21:26:32] * mru lacks the required physique [21:26:41] <mru> don't know about _av500_ ... [21:27:06] <KotH> not roughless enough [21:27:39] <ramiro> KotH could kill us with his bare hands. [21:27:52] <mru> no doubt [21:28:06] <KotH> yes, i could... unless you put up a fight ;) [21:28:52] * mru thought KotH practised some form of martial arts [21:29:00] <mru> don't they teach the force choke there? [21:29:13] <_av500_> marsian arts? [21:29:17] <KotH> nope... [21:29:28] <mru> _av500_: martian [21:29:29] <KotH> and even if they would, it's not of much use [21:29:34] <mru> is the adjective form of mars [21:29:54] <KotH> the one who wins isnt the one who is stronger or better trained, it's the one who has more will to win [21:29:58] * _av500_ prefers martini [21:30:09] <mru> shaken, not stirred [21:30:22] <_av500_> what mru said [21:30:24] * KotH stirs up som edust [21:30:31] <KotH> s/ e/e / [21:32:59] <KotH> mru: next time you're in .ch, i'll take you to our training [21:33:18] <KotH> mru: to see and learn, with eyes unclouded :) [21:34:51] <_av500_> wipe on wipe off... [22:13:01] <CIA-7> ffmpeg: stefano * r23055 /trunk/libavfilter/vf_scale.c: [22:13:01] <CIA-7> ffmpeg: Log input size, input format and swscale flags used for conversion in [22:13:01] <CIA-7> ffmpeg: config_props(). [22:13:01] <CIA-7> ffmpeg: Useful for debugging. [22:13:01] <CIA-7> ffmpeg: stefano * r23056 /trunk/libavfilter/vf_scale.c: [22:13:02] <CIA-7> ffmpeg: Make config_props() show conversion information before to create the [22:13:03] <CIA-7> ffmpeg: swscale context. [22:13:03] <CIA-7> ffmpeg: This makes eventual warnings issued in case of swscale context [22:13:04] <CIA-7> ffmpeg: creation failure to be shown after the conversion information rather [22:13:04] <CIA-7> ffmpeg: than before, which is slightly less confusing. [23:18:48] <mru> there's a hole in the spectrum, dear alex, dear alex... [23:30:28] <spaam> oh no [23:32:03] <kierank> haha monty is speaking at streaming media east [23:32:09] <kierank> http://blog.streamingmedia.com/the_business_of_online_vi/2010/05/adobe-cbs-… [23:34:09] <mru> what's the matter spaam? [23:34:15] <mru> did you miss the traam? [23:35:06] <spaam> mru: mm :( [23:35:37] <mru> poor spaam, now he has to walk home [23:35:43] <mru> because pigs can't fly... [23:36:20] <spaam> can you make them fly dear mru ?:O [23:36:39] <spaam> make them fly for me. plz mr mru [23:37:07] <mru> pig who can fly, that would be a lie [23:38:18] <mru> but for those who are nice, I'll put devils on ice

1 0

IRC log for 2010-05-06
by irc＠mansr.com 07 May '10

07 May '10

[00:03:25] <ramiro> thanks [00:52:44] <ramiro> did google just add an annoying and ugly left sidebar? [00:53:12] <kierank> they are probably a/b testing it [00:54:03] <ramiro> i had seen it in google.com.br, which I usually avoid, but not in normal google.com [00:54:18] <astrange> i think it was already present but optional, and now they're testing making it default [00:55:20] <ramiro> is it removable? [00:55:34] <ramiro> I'm still not happy about the bigger search box [03:26:13] <Kovensky> ramiro: google.com insists on redirecting to .com.br for me, and also insists on enabling hl=pt-BR unless I set the hl=en-US cookie [03:26:41] <Kovensky> <@astrange> i think it was already present but optional <-- Labs feature? [03:32:27] <saintdev> Kovensky: you can set your language settings in the preferences [03:32:44] <Kovensky> that's what I meant by setting the cookie [03:33:36] <saintdev> well it sounded like you were setting the cookie manually :p [03:33:50] <Kovensky> :p [04:31:42] <Dark_Shikari> hmm, we need to add intra refresh and crf max to ffmpeg [04:52:21] <Dark_Shikari> http://pastebin.org/204244 [04:52:27] <Dark_Shikari> quick patch review, anyone feel free to complain [04:52:38] <Dark_Shikari> oh, I need to bump minor version number right? [04:57:39] <Dark_Shikari> anyone? [04:58:50] <astrange> PIR can't be a flags2? [04:58:56] <Dark_Shikari> oh, good point [05:02:32] <Dark_Shikari> astrange: http://pastebin.org/204254 [05:04:46] <astrange> it doesn't matter that it's not !!(avctx->flags2 & CODEC_FLAG_PASS1) ? [05:04:52] <astrange> i don't see anything else [05:04:56] <Dark_Shikari> x264 boolifies itself. [05:05:33] <Dark_Shikari> oops, need to update the help text [05:11:43] <Dark_Shikari> lol, pass1 [05:11:45] <Dark_Shikari> oops [05:26:18] <KotH> god morgon [06:02:15] <elenril> o_0 chromium? in debian main? [06:03:50] <saintdev> must be v1.0* [06:03:52] <saintdev> :P [06:04:08] <saintdev> because it's *moar stable* [06:04:39] * elenril wonders why doesn't it depend on ffmpeg [06:05:25] <saintdev> because it uses an internal library. [06:15:36] <benoit-> moin [06:30:42] <scaphilo> how does this work: Lets say you have a interleased mpeg2 intra field picture (top field) and a following p field picture (bottom field). the p field picture refers a past past bottom field . Is this a reconstructed value then? [06:31:12] <Dark_Shikari> the p field picture references the top field [06:31:13] <scaphilo> or does it refer the top field of the past intra? [06:31:17] <Dark_Shikari> yes, bottom field can reference top field [06:31:25] <Dark_Shikari> this is only allowed in field coding (not mbaff obviously) [06:31:29] <astrange> you found an mpeg2 with field pictures? [06:31:42] <astrange> i never did remember where i got one [06:32:28] <scaphilo> am yes i think unforunatly my testvideos have some of them [06:32:34] <Dark_Shikari> for some reason it's not used very often [06:32:37] <Dark_Shikari> I'm not quite sure why [06:32:40] <Dark_Shikari> paff is rather popular in h264 [06:32:52] <Dark_Shikari> Maybe it's because mbaff is really fucking difficult to implement in h264, while it's trivial in mpeg-2 by comparison [06:33:01] <scaphilo> :-) [06:33:59] <scaphilo> thx for help [07:54:35] <elenril> lol@chromium proxy settings redirecting me at http://code.google.com/p/chromium/wiki/LinuxProxyConfig [10:09:06] <j-b> 'morning [10:11:07] <av500> gm [10:12:41] <av500> j-b: beer was even paid for my microsoft :) [10:12:49] <av500> err, by microsoft [12:01:58] <lu_zero> beer? [12:01:59] <lu_zero> where? [12:02:06] <lu_zero> (good $morning) [12:02:18] <mru> no beer here... :-( [12:02:20] <kshishkov> in Redmond, Massachusets :) [12:02:45] <lu_zero> mru: here just tonic water =) [12:03:01] <mru> without gin? [12:03:09] <lu_zero> just tonic water [12:03:22] * mru likes it better with gin and lemon [12:03:24] <kshishkov> mru: they really have to be careful when driving FIATs [12:04:08] <lu_zero> kshishkov: they who? [12:04:27] <kshishkov> lu_zero: Italians, especially near Torino [12:04:38] <lu_zero> kshishkov: here we know better =P [12:05:08] * lu_zero doesn't use fiat [12:05:22] <kshishkov> good for you [12:05:26] <lu_zero> AND after they messed up putting wince on their new models I think I won't. [12:05:30] <lu_zero> ever [12:06:01] <av500> lu_zero: beer in paris last night [12:06:07] <lu_zero> oh [12:06:13] <lu_zero> too far from me =P [12:06:19] * kshishkov hates iat for licensed Fiat 124 clones [12:06:19] <av500> j-b missed getting free beer paid by M$ [12:06:32] <mru> why where they handing out beer? [12:06:38] <thresh> doesnt that make you some kind of a renegade? [12:06:50] <av500> mru: ex-coworker is M$ now [12:07:03] * lu_zero wants to organize something here sooner or later [12:07:12] <av500> so we talked shop for 5min and it was a business meeting :) [12:07:39] <av500> he could have told j-b about how to add PlayReady to vlc :) [12:07:52] <lu_zero> PlayReady? [12:07:58] <av500> M$ drm [12:08:17] <j-b> av500: shit... [12:08:28] <j-b> av500: does anyone still care about PlayReady ? [12:08:30] <lu_zero> PlayNever, PayAlready? [12:08:45] <av500> j-b: it seems to be pickung up [12:11:00] <j-b> av500: again? fuck. [12:11:05] <j-b> av500: for videos? [12:11:06] <lu_zero> I wonder why [12:11:08] <lu_zero> it's pointless [12:11:22] <av500> j-b: yes [12:12:26] <j-b> av500: so like FairPlay, its usage is picking up [12:13:23] <av500> is it? [12:13:43] <av500> i thought all appl video stuff was drmed from the start, no? [12:14:03] <kshishkov> only on iPods [12:15:01] <j-b> av500: all iTunes things are DRM'd now [12:15:09] <j-b> it wasn't always the case [12:17:02] <spaam> j-b: not all things are DRM'd . didnt they remove it from the music ? [12:17:23] <av500> j-b: ok [12:17:51] <av500> m$ guy said its also due to larger resolutions now [12:18:37] <kshishkov> i.e. they finally got stuff with quality worth protecting [12:20:40] <j-b> spaam: integrally yes. [12:23:46] <Kovensky> mru: lol @ that __STDC_CONSTANT_MACROS patch [12:24:27] <spaam> time to change ffmpeg to c++ ?;P [12:24:38] <mru> no, time to change c++ to ffmpeg [12:26:52] <Kovensky> nah, TRWTF is that he undeffes _STDINT_H so he can include stdint again [12:26:52] <Kovensky> lol [12:27:23] <mru> yeah [12:27:42] <mru> which is in itself multiple WTFs [12:32:07] <spaam> Tjoppen: got a new name? ;) [12:34:20] <Kovensky> lol, on arch-general ML: [12:34:24] <Kovensky> "I was reading the "about" page (http://www.archlinux.org/about/) in the archlinux website and I noticed that this line is a little outdated: "Arch also offers an [unsupported] section in the Arch Linux User Repository (AUR), which contains over 9,000 build scripts" It should say "over 21.000 build scripts"." [12:35:02] <kshishkov> it's still true, 21000 > 9000 [12:35:55] <Kovensky> missing the point :( [12:36:27] <spaam> :) [12:36:29] <kshishkov> deliberately [12:41:54] <j-b> av500: does an open-source lib break those DRM ? [12:42:10] <Tjoppen> spaam: ? [12:42:49] <spaam> Tjoppen: look what declan harrison called you.. tom.. i though your name was Tomas.. ;D [12:43:22] <Tjoppen> oh. hah :) [12:44:26] <av500> j-b: an open src lib by itself does not break anything [12:44:47] <av500> but I doubt playready spec is open to open src imlementation [12:44:53] <Tjoppen> he brings up a good point though; I should put that patch up on the list for people to look at [12:45:37] <Tjoppen> but at the moment I have more pressing matters: fika [12:48:40] <spaam> Tjoppen: fika <3 [13:00:07] <ramiro> we should change libavfilter/parseutils.c:color_table to follow http://xkcd.com/color/rgb.txt [13:00:32] <ramiro> (based on http://blog.xkcd.com/2010/05/03/color-survey-results/ ) [13:01:14] <av500> ramiro: it misses one color: "bikeshed" [13:02:16] <ramiro> av500: we already have that one, its rand(). [13:02:36] <ramiro> (we actually do somewhere in libavfilter, I'm not kidding =) [13:05:17] <janneg> indeed if (!strcasecmp(color_string, "random") || !strcasecmp(color_string, "bikeshed")) { [13:37:27] <Kovensky> "A couple dozen people embedded SQL ‘drop table’ statements in the color names. Nice try, kids." <-- blame yourself [13:37:30] <Kovensky> lol [13:37:51] <mru> bobby tables... [13:37:58] <kshishkov> yes [13:38:03] <thresh> :-) [13:40:44] <thresh> nice trolling, http://www.youtube.com/watch?v=B4n7wo8rvTM [13:41:39] <kshishkov> nice timing on reporting it too, BBB has just joined [13:41:48] <BBB> hi [13:41:56] <thresh> kshishkov: well, mru is always around here also ;-) [13:43:11] <thresh> [root@ntpd /]# mkdir [13:43:11] <thresh> Segmentation fault [13:44:00] <spaam> eh? [13:44:04] <kshishkov> try "ls /lib" [13:44:24] <thresh> nah, this is VPS after some FS corruption on a host node [13:55:09] <BBB> kshishkov: what was I needed for? [13:55:37] <kshishkov> for watching http://www.youtube.com/watch?v=B4n7wo8rvTM [13:57:05] <BBB> oh [13:57:17] <BBB> the guy screaming was a lunatic homeless person apparently [14:41:55] <BBB> is it just me or is this avctx extradata "thing" heavily overengineered? [14:42:09] <av500> its a char buffer [14:42:36] <mru> it's as simple as it can possibly be [14:43:03] <BBB> that's fine [14:43:14] <BBB> but his patch has 100 lines of code in iff.h to "get" these chars [14:43:20] <BBB> I meant that part [14:43:33] <av500> that is codec dependent [14:43:48] <av500> no? [14:43:59] <BBB> the GET_EXCTX_INT8/16/32/64, PUT_EXCTX_INT*, EXTRA_CONTEXT_*, etc. [14:44:07] <av500> for lavf xtradata is an opaque char array [14:44:36] <mru> wtf, that looks wrong [14:44:38] <BBB> it'd be much less code to just write a 10-line doxy in iff.h documenting this [14:44:43] <mru> he should be using the bytestream.h stuff [14:44:59] <BBB> and then implement it without this bloatware plainly using bytestream api [14:46:24] <peloverde> also WTF is the deal with those NULL checks? [14:47:55] <BBB> I'll review it later today [14:48:09] <BBB> wanted to make sure it wasn't something people told him to do for some maybe-good reason [14:48:41] <av500> ppl told him to store his stuff portably [14:48:54] <av500> as in dont memcpy a struct to xtradata [14:49:12] <BBB> right, I remember that [14:49:15] <BBB> which is good [14:49:21] <BBB> and then mru told him to use bytestrea.h right? [14:49:24] <BBB> so what happened [14:49:27] <BBB> where did it go wrong? :) [14:49:51] <av500> bytestrea.h not found :) [14:49:55] <wbs> he wrote more than 5 lines of own code without consulting anybody? ;P [14:50:00] <mru> he strikes me as a bit oldschool/amiga [14:50:07] <mru> we have to get him out of that mindset [14:50:07] <wbs> mru: oh, really? ;P [14:50:45] <av500> he lacks the 5y lurk and learn bit [14:51:03] * av500 is in year 2... [14:51:09] <merbzt> mru: you truely are the master of sarcasm [14:51:22] * BBB agrees with mru [14:51:23] <BBB> he will learn [14:51:34] <BBB> I think he has great potential [14:51:52] <av500> at least he can keep the amiga port alive [14:52:09] <BBB> av500: where's your next ptch? :) [14:52:13] <kshishkov> BBB: don't say that until he delivers something really impressive, preferably REd [14:52:21] <av500> BBB: hmm, another one? [14:52:41] <BBB> lol :) [14:53:53] * av500 svn ups [14:54:10] <lu_zero> yawn [14:57:58] <kshishkov> each time you svn up, lu_zero yawns [14:59:25] <lu_zero> kshishkov: not that often [14:59:41] * lu_zero is bored [15:00:19] * av500 svn ups [15:00:48] <mru> lu_zero: try flaming the c++ fool [15:01:58] <peloverde> I don't see why he considers "#define __STDC_CONSTANT_MACROS" / "-D__STDC_CONSTANT_MACROS" so burdensome [15:02:18] <mru> seems pretty light compared to coding in c++ in the first place [15:02:59] <Tjoppen> incidentally, I also noticed that C++ issue but instead of nagging the list I simply added -D__STDC_CONSTANT_MACROS. that enabled me to remove a bunch of such #defines from my code, since other libs also require it [15:05:46] * lu_zero did that in flux [15:06:28] <lu_zero> mru: seems others are doing as well [15:06:38] <lu_zero> and overall it's a pointless exercise [15:06:51] <mru> oh, come on [15:06:59] <mru> it's not every day you get a FRENCH C++ troll [15:07:24] <janneg> if I weren't working on a ffmpeg using C++ application I would vote to rename a few variables class and new in avcodec.h [15:07:42] <lu_zero> janneg: that's evil [15:07:48] <mru> I'd approve it [15:08:01] <lu_zero> eh... [15:08:04] <mru> next time I write a library I'm going to do that [15:09:25] <lu_zero> in order to actively deprecate C++ we'd need something that works good for that task [15:09:53] <lu_zero> the problem is that we cannot see any use for C++ beside causing headache [15:14:50] <kshishkov> mru: but it looked to me that we got more treaullaux that trolls [15:15:19] <mru> kshishkov: eau only works in the last syllable [15:15:29] <mru> at least that's my heuristic [15:15:36] <j-b> Lol, it is Eric Valette... [15:15:41] <mru> actual french-speakers can correct me [15:15:47] <kshishkov> j-b ? [15:15:49] <mru> j-b: you know that troll? [15:15:55] <j-b> s/troll/moron [15:16:51] <kshishkov> mru: I remember several French lasting trolls, both independent and from Divx and Google [15:17:17] <mru> you mean robux4? [15:17:23] <mru> he's alright [15:17:29] <mru> he came to his senses [15:17:37] <kshishkov> what about Frank? [15:17:59] <mru> does he wear a rabbit suit? [15:18:19] <j-b> well, robux4 is nice, but the bloat MKV can be is a bit his fault [15:18:31] <mru> it is his fault [15:18:41] <j-b> like, DVD menus inside MKV [15:19:04] <mru> but he's listening to my advice on an update to the format [15:19:11] <kshishkov> well, he could end with ISO image inside MKV [15:19:42] <lu_zero> sounds interesting [15:19:47] <lu_zero> pointless but interesting [15:19:48] <av500> when can I have that feature [15:20:22] <lu_zero> citing libc as an example of "good behaviour for C++" is quite strange [15:20:39] * kshishkov checks pig airports [15:20:46] <kshishkov> av500: not today, I fear [15:20:54] <peloverde> use of libc headers from C++ is deprecated [15:21:11] <mru> talk about reinventing the wheel [15:21:49] <peloverde> Basically they have wrappers now that are preferred [15:22:04] <lu_zero> mostly because they hide the define stuff [15:22:19] <mru> they could do that without changing the names [15:22:54] <peloverde> but they threw the C compatibility angle out ages ago when they broke "char *foo = malloc(16);" [15:23:04] <mru> by using a different header search path and compiler extensions like include_next [15:23:17] <lu_zero> #include <cfoo> instead #define __I_M_A_FOOL #include <foo.h> [15:23:32] <kshishkov> mru: please add " [15:23:41] <kshishkov> int new" somewhere into FFmpeg headers [15:23:55] <mru> it's tempting [15:24:22] <mru> we could screw with people using gnu99 mode too by calling something asm [15:24:24] <kshishkov> or "int class", it can be fitted in many places [15:25:12] <lu_zero> bettalso *_cast [15:26:19] <j-b> You C++ haters! You French haters! You FT haters! Bad people, bad! [15:26:26] <lu_zero> FT? [15:26:30] <j-b> France Telecom [15:26:42] <lu_zero> I don't care much [15:26:46] <j-b> orange-ftgroup.com [15:26:54] <j-b> Eric est toujours aussi con :) [15:27:07] <peloverde> I recall them being responsible for one of the more obnoxious parts of 14496-3 [15:27:15] <peloverde> so yes I do hate them [15:27:18] <peloverde> them and NTT [15:27:42] <peloverde> NTT who decided a twinVQ variant belonged in 14496-3 [15:27:59] <kshishkov> well, VQF was purely their creation [15:28:36] <peloverde> yes but do we need a non VQF twinvq format in 14496-3 sp 04? [15:29:09] <kshishkov> because MPEG-4 Audio is versatile [15:29:12] <peloverde> they are just shoehorning shit in there to try to get patent royalties [15:30:33] <av500> they have little kids to feed [15:30:37] <av500> think about the children [15:30:45] <wbs> gah, even after being hinted that one shouldn't use structs for writing extradata, he _still_ uses that [15:30:57] <wbs> regarding the iff/amiga stuff... [15:31:07] <peloverde> I hope their children are forced to implement all of -3, especially the underspecified parts [15:32:35] <lu_zero> wbs: where? [15:32:51] <wbs> lu_zero: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088036.html [15:32:51] <kshishkov> peloverde: children labour is prohibited in many countries [15:33:08] <wbs> lu_zero: the one BBB mentioned a while ago [15:33:31] <lu_zero> ah [15:34:09] <mru> kshishkov: great, then we can have them arrested [15:35:05] <lu_zero> mru: the children or the vqf shoehorners? [15:42:27] <mru> if we're lucky, both [15:45:44] <av500> BBB: there: http://ffmpeg.pastebin.com/YBxmYhc4 [15:46:12] <mru> isn't there generic code for that? [15:46:51] <av500> pcm_Read_seek() with blockalign=1 maybe [15:48:27] <av500> thats what I used and simplified [15:52:47] <mru> I thought there was some shared code for such things [15:54:04] <av500> looking for it [15:55:33] <jai> av500: isnt there a seektable ? [15:56:47] <av500> seems not [15:57:13] <jai> av500: http://flac.sourceforge.net/format.html#seekpoint [15:57:15] <mru> flac has an optional index [15:57:41] <jai> yes, and we should use that if present [15:57:55] <av500> never saw one [15:59:29] <av500> hmm, why does av_index_search_timestamp() works for .mp3? [15:59:35] <av500> and not for flac [17:11:55] <peloverde> I can't believe I wasted the whole morning trolling on the ML [17:12:12] <Dark_Shikari> what's wrong with trolling [17:13:40] <pJok> trolling is never waste [17:13:45] <pJok> if applied correctly that is [17:19:56] <Kovensky> peloverde: "So you are asking our project to behave more like glibc? Be careful" [17:20:00] <Kovensky> what you wish for... [17:20:02] <Kovensky> lol [17:20:04] <Kovensky> durf @ irssi breaking the quote [17:21:23] <BBB> peloverde: well done though \o/ [17:21:34] <BBB> some memorable quotes [17:24:57] <Kovensky> "You're dangerously close to invoking Godwin's law there." <-- lol mru [17:25:43] * elenril thinks hitler would have used c++ [17:25:56] <Kovensky> durf, why are so many messages that appear, then get broken in the middle by o9k mail headers, then get included all over again but correctly [17:26:02] * Kovensky blames thunderbird [17:26:16] * jai rues the fact that libmatroska is written in c++ [17:26:28] <elenril> who uses libmatroska [17:26:40] <jai> vlc native demuxer [17:26:53] <elenril> why not use lav....nvm [17:27:07] <elenril> why not use mplayer ;) [17:27:09] <jai> lavf can be sued as well [17:27:11] <jai> err [17:27:12] <jai> *used [17:27:19] <Kovensky> please dont sue us [17:27:37] <jai> maybe it could even be bump up to default [17:27:42] <jai> *bumped [17:27:50] * Kovensky still considers lavf completely unusable for matroska until aurel fixes ASS demuxing [17:27:56] <elenril> ^this [17:28:09] * Kovensky also still considers it completely unusable while aurel and michael block ordered chapters [17:28:09] <jai> wasn't that fixed? [17:28:24] <elenril> nobody is blocking ordered chapters [17:28:24] <Dark_Shikari> and that whole thing about ffmpeg going into an infinite loop when decoding dirac from matroska [17:28:32] <Dark_Shikari> and other similar bugs [17:28:36] * Compn considers embedded subtitles blah anyways, external ass !! [17:28:46] <Dark_Shikari> oh, and the fact that muxing raw h264 -> mkv is broken [17:28:53] <elenril> broken? how? [17:28:55] <jai> maybe i'm completely missing the bugreports. anyone have a roundup link? [17:28:59] <Kovensky> Compn: can't embed fonts if you use external ass [17:29:01] <Dark_Shikari> elenril: it doesn't _work_ [17:29:11] <Dark_Shikari> it just stops with a timestamp error [17:29:19] <Kovensky> jai: aurel marked it as NOTABUG [17:29:28] <jai> Kovensky: huh [17:29:32] <Kovensky> jai: however, his demuxer is the *only* matroska demuxer that corrupts the ASS packets [17:29:37] <jai> Kovensky: do you have a link btw? [17:29:46] <Compn> Kovensky : why not? also i dont think ffmpeg supports muxing fonts either [17:29:48] <Kovensky> hmm, no; it's what I remember from the fflames [17:30:08] <Dark_Shikari> Compn: can't mux h264, can't mux fonts, bugged with ASS.... aka impossible to use =p [17:30:14] <Kovensky> Compn: nobody uses libavformat for muxing [17:30:19] <Kovensky> not matroska [17:30:23] * elenril does [17:30:30] <Kovensky> elenril is a nut [17:30:35] <Compn> who has raw h264 anyhow ? [17:30:40] <elenril> right, i forgot [17:30:40] * Compn curious [17:30:52] <Kovensky> Compn: x264 input -o output.264 [17:31:00] <Compn> and if you say mencoder -ovc x264 -of rawvideo ... [17:31:38] <Kovensky> there's also a plan to move x264's mp4 muxer to libavformat but it doesn't support certain atoms [17:31:42] <Kovensky> according to VFR Maniac [17:31:43] <Dark_Shikari> Yeah, that too [17:31:54] <Dark_Shikari> that is a good candidate for troll-driven development imo [17:31:59] <Compn> heh [17:32:00] <Dark_Shikari> bcoudurier LOVES being told his mp4 muxer sucks [17:32:18] <Compn> isnt atom support fairly easy to add ? [17:32:20] <Kovensky> lol [17:32:23] <Compn> why mp4 has a million atoms anyways [17:32:27] <Dark_Shikari> Compn: requires API support too [17:32:27] <Compn> ugh [17:32:29] <Kovensky> Compn: blame apple [17:32:44] <jai> Kovensky: https://roundup.ffmpeg.org/issue588 ? [17:34:07] <BBB> he still kept the GET_* macros [17:34:11] * BBB bangs head against wall [17:53:15] <peloverde> GET_* is gone now :) [17:55:53] * _av500_ hums "you can't always GET_* what you want..." [19:20:42] <BastyCDGS> hi [19:20:46] <mru> lo [19:20:51] <BastyCDGS> 32 or 64? :D [19:20:59] <mru> 8 [19:22:11] <BastyCDGS> have you read my post almost 10 mins ago? [19:22:17] <BastyCDGS> maybe this changes things a little bit... [19:22:20] <peloverde> talk about spectral holes: http://i.imgur.com/Y2N1T.png :( [19:24:11] <BastyCDGS> to review the problem, if codec_id == CODEC_ID_RAWVIDEO and read_packet has been called, when decode_init is called then? [19:27:34] <BastyCDGS> or is never called and that's the reason why it calls read_palette of decoder by itself in the demuxer? [19:28:42] <jai> Connecting to samples.mplayerhq.hu|213.144.138.186|:80... connected. [19:28:43] <jai> HTTP request sent, awaiting response... 403 Forbidden [19:28:47] <jai> ^^ :( [19:29:06] <_av500_> u are not allowed :) [19:29:16] <_av500_> you have too many samples already [19:29:24] <BastyCDGS> hey jai, maybe you can help with the CODEC_ID_RAWVIDEO issue? [19:29:25] <jai> need moar samples [19:29:59] <jai> BastyCDGS: i can? :) [19:30:08] <BastyCDGS> is it even correct to add the palette data to a RAWVIDEO codec id? [19:30:10] <jai> what's the issue? [19:31:00] <BastyCDGS> issue is that the decoder's read color palette is called within read_packet in demuxer only if it's CODEC_ID_RAWVIDEO [19:33:25] <jai> and why is that a problem? [19:33:32] <jai> also, which code is this? [19:33:49] <BastyCDGS> see my latest post in ml I pasted it there [19:34:07] <BastyCDGS> what RAWVIDEO means exactly? that the raw input data is just copied over? [19:34:21] <BastyCDGS> plus extradata? [19:36:25] <jai> the rawvideo codec id hooks up to raw pixel data [19:36:49] <BastyCDGS> only the pixel data without colormap? [19:37:06] <jai> yes [19:37:14] <BastyCDGS> then the code is wrong anyway ;) [19:37:33] <BastyCDGS> and I can remove the call in the demuxer to the colormap [19:39:42] <BastyCDGS> the current decoder does the following when it's RAWVIDEO codec it, it either copies the plane data bit by bit or if byterun1 just decompresses and then copies plane data bit by bit [19:39:57] <BastyCDGS> the demuxer appends the palette data to it [19:40:07] <BastyCDGS> is that correct and intended behaviour? [19:43:42] <BastyCDGS> BBB, good you're here [19:43:44] <BBB> BastyCDGS: to get back to the discussion before I unplugged my cable to help someone else: don't rely on order of calling, it's bad habit :) [19:44:38] <BastyCDGS> jai just said that adding the palette data for CODEC_ID_RAWVIDEO is not expected [19:45:07] <BastyCDGS> that would mean I can complete remove the call to avcodec read_cmap_palette in demuxer ;) [19:45:23] <BastyCDGS> jai said it should just be the raw pixel data [19:45:37] <BBB> data[1] should be the palette IIRC [19:46:17] <jai> yeah, data[1] should be the colormap if pixfmt == pal8 [19:46:21] <BastyCDGS> but looking at the current decoder implementation shows me that it just copies plane data or if byterun1 it just decompresses and copies that 1:1 [19:46:44] <jai> BastyCDGS: data[0] should be raw pixel data [19:47:15] <BastyCDGS> after if'ing if it's RAWVIDEO, the current demuxer does: [19:47:17] <BastyCDGS> if(av_new_packet(pkt, iff->body_size + AVPALETTE_SIZE) < 0) { [19:47:17] <BastyCDGS> return AVERROR(ENOMEM); [19:47:17] <BastyCDGS> } [19:47:17] <BastyCDGS> [19:47:17] <BastyCDGS> ret = ff_cmap_read_palette(st->codec, (uint32_t*)(pkt->data + iff->body_size)); [19:47:23] <BastyCDGS> that's wrong then, right? [19:47:30] <BBB> looks weird [19:47:32] <BBB> let me relook [19:47:37] <BastyCDGS> ff_cmap_read_palette is in decoder [19:48:37] <BastyCDGS> do I have to handle cmap for RAWVIDEO in demuxer at all? [19:48:55] <BastyCDGS> i.e. is decode_init from decoder called somewhere when it's RAWVIDEO? [19:49:17] <BastyCDGS> because if it's I just can remove demuxer cmap handling stuff and it's all fine ;) [19:49:29] <BBB> that code looks weird [19:49:33] <BBB> try to remove it and see what happens [19:49:45] <BBB> although I have to admit I'm confused because it never sets the palette data anywhere else [19:49:54] <BastyCDGS> I have to use ffmpeg -i infile.iff -f rawvideo to test, right? [19:49:59] <BBB> no [19:50:12] <BastyCDGS> how then? [19:50:14] <BBB> you have to find an iff file that has the rawvideo codec instead of ilbm [19:50:17] <BBB> iblm [19:50:29] <BBB> it's like a divx avi versus a mjpeg avi [19:50:37] <BBB> you can't play the mjpeg avi with -f divx [19:50:43] <BBB> you have to find an actual divx avi [19:51:31] <BastyCDGS> seems to be set if it's not ILBM but PBM file [19:51:44] <BBB> yes [19:51:50] <BastyCDGS> oh and I see, only if no compression is used [19:51:50] <BBB> so find a pbm file [19:52:19] <jai> KotH: does samples.mphq block certain ip ranges? [19:52:27] <kierank> it does iirc [19:52:55] <BastyCDGS> then try tor ;) [19:52:57] <jai> meh :/ [19:53:06] * peloverde looks at at faac and lavc (faac inspired quantizer search) side by side and can't figure out what inspired this super buggy termination condition [19:53:47] <jai> i'll try with a different ip [19:55:15] <jai> no luck :( [19:55:29] <peloverde> also whoever taught menno his tab/space style deserves a beating [19:55:56] <mru> he has a defined style? [19:56:08] <Kovensky> lol [19:56:18] * Kovensky just uses whatever emacs gives him ._. [19:56:25] <Kovensky> though I tweaked settings a lot [19:56:30] <Kovensky> what settings do you use btw mru [19:56:42] <mru> depends on what I'm working on [19:56:59] <Kovensky> what's your init.el [19:57:06] <BastyCDGS> don't find any IFF-PBMs :( [19:57:34] <peloverde> his style appears to be tabs = 8 spaces, on alternating indentation levels use tabs for the bulk and spaces for change, and each indentation level is 1d6 spaces [19:57:54] <Kovensky> 1d6? lol [19:58:18] * Kovensky never played traditional rpgs :( [19:58:39] <Kovensky> actually, I have played pen-and-paper ones, but never one of the traditional ones [19:58:59] <Kovensky> they were made up on the spot by whoever was the game master lol [19:59:38] <BastyCDGS> got one! [20:02:31] <mru> Kovensky: http://pastie.org/949043 [20:02:40] <BastyCDGS> damn, this is a byterun1 PBM [20:02:47] <BastyCDGS> so rawvideo stuff isn't called [20:02:59] <BastyCDGS> it just uses RAWVIDEO for raw PBM [20:05:13] <BastyCDGS> but doing a: [20:05:13] <BastyCDGS> ./ffmpeg -i ../patches/ASH.LBM -f rawvideo /tmp/test.raw [20:05:16] <BastyCDGS> does the trick [20:05:45] <BastyCDGS> oh no just for output not for input :( [20:06:17] <BastyCDGS> do you think it's safe to just remove that part and let handle raw IFF-PBM files like it would handle raw IFF-ILBM files? [20:06:42] <BastyCDGS> in the demuxer [20:06:55] <BastyCDGS> because for byterun1 IFF-PBM it doesn't do that ugly stuff too [20:07:57] <BastyCDGS> well wait what file handles CODEC_ID_RAWVIDEO? [20:08:14] <BastyCDGS> it's not handled by the IFF decoder at all I just see because the codec id isn't listened here [20:09:20] <Kovensky> mru: short ._. [20:09:37] * Kovensky has a lot of file-lock and cperl-mode specific configs [20:09:51] <mru> Kovensky: that's just the C-related part [20:10:01] <mru> the whole thing is 320 lines [20:10:09] <mru> not including other .el files it pulls in [20:10:14] <BBB> BastyCDGS: try it, and just see if output is the same [20:10:16] <Kovensky> heh [20:10:23] <Kovensky> I *think* I put my .emacs.d on github [20:10:44] <BastyCDGS> I haven't a file with IFF-PBM raw data [20:10:49] <Kovensky> hmm no, just the cperl-mode mods I did [20:11:06] <BastyCDGS> I don't even find any usable information about IFF-PBM raw...but IFF-PBM byterun1 just works fine [20:11:11] <BastyCDGS> and is handled by the IFF decoder [20:11:30] <BastyCDGS> like IFF ILBM [20:11:48] <BastyCDGS> so from pure logic it should the same for IFF PBM raw (handled like IFF ILBM raw) [20:17:04] <BBB> well look, if we support it, there must be some file that uses it [20:18:27] <BastyCDGS> well I just dropped that else if stuff [20:18:33] <BastyCDGS> testing with all files seems to be ok [20:19:29] <BastyCDGS> is it safe to remove avformat/iff.h [20:19:29] <BastyCDGS> int ff_cmap_read_palette(AVCodecContext *avctx, uint32_t *pal); [20:19:39] <CIA-7> ffmpeg: alexc * r23035 /trunk/libavcodec/aaccoder.c: Make the faac inspired quantizer search make sense for a slightly narrower definition of "make sense." [20:19:39] <BastyCDGS> and make the only remaining ff_cmap_read_palette static? [20:20:00] <BastyCDGS> or might ff_cmap_read_palette be called from outside? [20:20:20] <BastyCDGS> i.e. an external application (thus part of public API) [20:20:23] <BastyCDGS> in ffmpeg [20:21:56] <BBB> no [20:22:00] <BBB> it's ff_*() [20:22:04] <BBB> public api is avi_*() [20:22:06] <BBB> er... [20:22:08] <BBB> av_*() [20:22:20] <BBB> but ehm, make sure that the files you're testing with actually use this codepath [20:22:23] <BBB> otherwise it's useless [20:22:53] <BastyCDGS> well looking at IFF PBM byterun1 file I have (the only one) shows me it's the same as ILBM [20:23:06] <BastyCDGS> there's a new chunk in it though, TINY (guess it's thumbnail) [20:23:12] <BastyCDGS> otherwise it's exactly the same [20:23:13] <mru> put in a deliberate error and make sure the output changes [20:23:56] <BastyCDGS> you mean instead of setting codec id to RAWVIDEO dump a format not supported error? [20:26:56] <BastyCDGS> mru [20:26:59] <BastyCDGS> I got the difference! [20:27:04] <BastyCDGS> between PBM and ILBM [20:27:23] <BastyCDGS> it only differs that you don't do decodeplane in PBM [20:27:35] <BastyCDGS> at least the IFF-PBM byterun1 decoder shows that [20:28:02] <BastyCDGS> it does the same as the bpp <= 8 stuff from ILBM except a missing call to decodeplane8 [20:28:15] <BastyCDGS> so these two format probably just differ in chunky/planar bitmap data [20:28:30] <BastyCDGS> very probably ;) [20:36:36] <CIA-7> ffmpeg: alexc * r23036 /trunk/libavcodec/aacenc.c: Error out when too many bits per frame are requested. [20:39:30] <BastyCDGS> If someone can confirm that COCEC_ID_RAWVIDEO is for chunky data the issue is solved ;) [20:39:35] <CIA-7> ffmpeg: alexc * r23037 /trunk/libavcodec/aaccoder.c: 10l: store the result of clipping added in r23035 [20:40:21] <BastyCDGS> example for chunky data: 3a 3b 3f 37 1f 3c [20:40:21] <BastyCDGS> would mean pixel 0 = color index 3a, pixel 1 = color index 3b etc. [20:40:42] <BastyCDGS> if that's what CODEC_ID_RAWVIDEO decodes for PIX_FMT_PAL8 then I have solved the issue [20:52:18] <BastyCDGS> patch submitted to ml [20:52:27] <BastyCDGS> please review carefully [21:03:35] <peloverde> Now this is what I call a spectral hole! http://i.imgur.com/WUlG5.png [21:05:13] <mru> watch your step, you could trip over that [21:05:37] * Dark_Shikari sees the troll [21:05:43] <Dark_Shikari> in before a comment on how ffaac sucks [21:08:03] <peloverde> and it only took 8.5 minutes to dig that hole [21:10:03] <pJok> [insert comment here about fixing ffaacenc] [21:10:05] <mru> peloverde: look what you let out [21:10:20] * BastyCDGS added HAM6/8 support now to PBM files also [21:10:28] <BastyCDGS> unfortunately no files to test with [21:10:28] <Dark_Shikari> btw guys, I need a quick ABX from you all [21:10:41] <mru> Dark_Shikari: sure, #2 looks best [21:10:55] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/a.png [21:10:57] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/b.png [21:10:58] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/x.png [21:11:00] <Dark_Shikari> x is source [21:11:04] <mru> don't tell us that [21:11:06] <Dark_Shikari> Which is better, A or B? [21:11:10] <Dark_Shikari> mru: it's blindingly obvious [21:12:07] <peloverde> A [21:12:18] <mru> A [21:12:24] <mru> no question there [21:12:29] <mru> but both are pretty poor [21:12:40] <Dark_Shikari> B seems to do better on the bottom [21:12:46] <Dark_Shikari> it's less willing to destroy detail completely [21:12:53] <Dark_Shikari> but A seems overall better [21:12:56] <BastyCDGS> GREAT! IFF-ILBM/PBM now decodes _all_ files correctly I have (and that's quite a lot) [21:13:05] <mru> A is blurrier [21:13:07] <BastyCDGS> except those with masking (not supported yet) [21:13:18] <Dark_Shikari> mru: now, guess which codecs the two are. [21:13:30] <mru> B has lots of nasty edge artefacts [21:13:36] <peloverde> The reflection on the bottom of the red thing is terrible in B [21:14:03] <pJok> A looks less blocky [21:14:42] <Dark_Shikari> so yeah, now let's play the Guess The Codec game [21:14:52] <ramiro> vorbis? [21:14:53] <peloverde> x264 and dirac? [21:15:01] * Kovensky didn't look at the pics but shoots xvid and theora [21:15:08] <Kovensky> dirac wouldn't have blocks [21:15:08] <Dark_Shikari> peloverde: vp7 and dirac [21:15:15] <Kovensky> it does? lol [21:15:22] * Kovensky didn't expect blocks on wavelets [21:15:27] <Dark_Shikari> they're not quite blocks [21:15:33] <peloverde> who cares about vp7? [21:15:33] <pJok> ITS VP8!!!!1111111one [21:15:36] <pJok> [/troll] [21:15:41] <Kovensky> I just saw "blurry" and "blocky" [21:15:48] <Dark_Shikari> peloverde: well then the conclusion is: [21:15:53] <mru> A doesn't have much blocks [21:15:54] <Dark_Shikari> x264 >>>>>>>>>>>>>>>>>>> vp7 >>> dirac >>>> theora [21:16:05] <Dark_Shikari> x264: http://mirror05.x264.nl/Dark/x264_parkjoy.png [21:16:06] <ramiro> isn't the codec name h.264? [21:16:14] <Dark_Shikari> ramiro: we're testing encoders [21:16:17] <Kovensky> ramiro: we're talking about the encoders [21:16:35] <ramiro> I thought the names would then be diracenc or somesuch [21:16:36] <Kovensky> since vp7, dirac and theora only have one implementation each, there's not much poin-- [21:16:40] <Dark_Shikari> ramiro: schro [21:16:41] <Kovensky> which dirac implementation did you use Dark_Shikari [21:16:43] <Dark_Shikari> dirac has two [21:16:52] <Dark_Shikari> 1.0.9 schro with recommended settings by ds [21:16:57] <Dark_Shikari> after fixing ffmpeg's wrapper to not be shit [21:17:08] <ramiro> can't you use schro directly? [21:17:33] <Dark_Shikari> there's no schrocli [21:17:45] <ramiro> oh, I wasn't aware of that [21:18:31] <ramiro> ot: is there anywhere we can get the list of gsoc'ers for each project? the official list only has the student/mentor names [21:19:23] <Dark_Shikari> hmm, I need more codecs for this test [21:19:27] <Dark_Shikari> hmm, let's try ffmpeg mpeg4! [21:19:30] <Dark_Shikari> or xvid [21:20:07] <mru> mpeg2 [21:20:10] <ramiro> make it 1d and pass it through vorbis! [21:20:46] <Dark_Shikari> mru: unfortunately HCenc, the best mpeg-2 encoder I know of, won't take gop sizes over 18 [21:20:49] <Dark_Shikari> which is a bit unfair [21:21:05] <Dark_Shikari> ok, the best one which I could get my hands on easily =p [21:21:08] <Dark_Shikari> legally, at least [21:21:15] <Dark_Shikari> I think the latest cce or whatever is pretty good too [21:24:59] * BastyCDGS added another patch for PBM HAM decoding (forget it with my last one sorry folks) [21:29:21] <Dark_Shikari> oh wow. xvid is going to look hilarious [21:31:29] <BastyCDGS> if someone wants to assist me in testing new PBM stuff... [21:31:52] <BastyCDGS> write a ILBM to PBM converter [21:32:02] <BBB> send an email to peter ross (he wrote that codec originally, no?) [21:32:06] <BBB> ask him for the source file [21:32:21] <BastyCDGS> I doubt he has an HAM PBM source file ;) [21:32:56] <BastyCDGS> ILBM => PBM converter, just copy every chunk in file except BODY [21:33:20] <BastyCDGS> for BODY: decodeplane8 it and write result instead of planar stuff (one byte, no word-padding per line) [21:34:52] <BastyCDGS> maybe somebody already has a nice tool which can convert IFF ILBM to IFF PBM ;) [21:35:03] <BastyCDGS> but do not mix IFF PBM with plain PBM ascii files [21:35:07] <BastyCDGS> they're totally different [21:38:15] <Dark_Shikari> mru / peloverde http://mirror05.x264.nl/Dark/compare/xvid.png [21:39:04] <BBB> BastyCDGS: no, but I mean for rawvideo [21:39:11] <BBB> BastyCDGS: there must be some case where tawvideo is used [21:39:21] <BBB> so iff.c in avformat is used, but not iff.c in avcodec [21:39:27] <BBB> I want to see that file work [21:39:39] <BastyCDGS> regarding this I just sent the mail ;) [21:40:02] <BBB> ok [21:40:25] <BastyCDGS> I'll do a grep maybe I find the decoder [21:41:51] <BBB> rawdec.c [21:41:56] <BBB> it means "no codec" [21:42:13] <BBB> e.g. the data is literally paletted video [21:42:16] <BBB> or RGB24 [21:42:18] <BBB> or so [21:43:03] <BastyCDGS> i.e. chunky 8-bit data with PAL8? [21:44:51] <Dark_Shikari> I need a comedy option for this codec comparison [21:44:54] <Dark_Shikari> svq1? [21:45:30] <BastyCDGS> sebastian vater quirk1? :D [21:46:18] <BBB> Dark_Shikari: snow1!1112 [21:46:22] <Dark_Shikari> that isn't comedy though [21:46:25] <Dark_Shikari> "comedy" must be much worse than theora [21:46:32] <elenril> bink? [21:46:32] <BBB> snow!!112 [21:46:34] <Dark_Shikari> in before "theora is the joke" [21:46:52] <BBB> you're telling me snow is better than theora? [21:46:57] <Dark_Shikari> elenril: that would work [21:46:59] <Dark_Shikari> lemme try bink [21:47:05] <BBB> otherwise [21:47:06] <BBB> wmv1 [21:47:10] <BBB> that sucks quite a lot [21:47:18] <Dark_Shikari> better than mpeg4 isn't it? [21:47:28] <BBB> you're confused with wmv3 [21:47:48] <Dark_Shikari> msmpeg4 was based on mpeg4 [21:47:55] <Dark_Shikari> and that went through like 3 iterations of new features [21:47:56] <Dark_Shikari> then wmv1 [21:47:57] <Dark_Shikari> then wmv2 [21:48:00] <Dark_Shikari> then finally wmv3 was a rewrite [21:48:08] <janneg> rv10 [21:48:16] <Dark_Shikari> those are all mpeg4-generation [21:48:21] <BastyCDGS> wmv1 + rot13? [21:48:24] <Dark_Shikari> none will be significantly different from mpeg4 [21:49:11] <BBB> hm.... [21:49:22] <BBB> how about... h261? [21:49:26] <BBB> do we have a h261enc? [21:49:46] <Dark_Shikari> h261 is resolution-restricted iirc [21:50:05] <BBB> it sucks ass [21:50:13] <BBB> I thought that was the predecessor of all mpeg codecs [21:50:35] <Dark_Shikari> yes [21:50:39] <Dark_Shikari> but it's still transform-based [21:50:44] <Dark_Shikari> imo the comedy option should be not primarily transform-based [21:50:53] <mru> svq1 then [21:50:59] <Dark_Shikari> Yeah, svq1 is encoding now [21:51:01] <Dark_Shikari> it's hysterically slow [21:51:06] <Dark_Shikari> yay for vector quant [21:51:12] <Dark_Shikari> oh, yeah, and bink too [21:51:25] <Dark_Shikari> svq1 is going to be fun, I'll need newton's method to get the right bitrate [21:51:42] <mru> some indeo version [21:51:46] <BBB> mjpeg [21:51:49] <Dark_Shikari> I don't think that will even hit the target bitrate [21:51:50] <Dark_Shikari> For either of those [21:51:57] <Dark_Shikari> 14mbps at 1080p50 [21:52:10] <BBB> mjpeg should give pretty crappy results [21:52:13] <BBB> it's I-frame only [21:52:15] <Dark_Shikari> I know [21:52:19] <Dark_Shikari> that's beyond comedy and just stupid =p [21:52:25] <mru> that's not enough for mpeg2 either [21:52:27] <BBB> you asked for it [21:52:30] <Dark_Shikari> mru: mpeg2 will work [21:52:30] <BBB> apng? :-p [21:52:44] <Dark_Shikari> BBB: no ability to adjust bitrate [21:52:45] <mru> mpeg2 would need about twice as many bits to look good [21:52:49] <Dark_Shikari> mru: more [21:52:51] <Dark_Shikari> source is hard [21:52:58] <Dark_Shikari> 4 times, minimum [21:53:06] <mru> yeah probably, for that source [21:53:21] <Dark_Shikari> I was shocked how good x264 came out [21:54:00] <BBB> you can stop pampering yourself now :-p [21:54:06] <Dark_Shikari> lol [21:54:09] <BBB> is it lgpl yet and integrated in the ffmpeg trunk? [21:54:12] * BBB runs [21:54:20] <Dark_Shikari> is it proprietary yet and being sold to microsoft? [21:54:21] * Dark_Shikari runs [21:54:47] <Dark_Shikari> also, apparently I made bink go nuts by feeding it an avisynth source file [21:54:52] <Dark_Shikari> file size: Projecting: 17,534,507 bytes (0.0 to 1) [21:54:57] <Dark_Shikari> 0.0 to 1 compression, hell yes [22:02:25] <BastyCDGS> well I know a compression method which compresses infinity non-repeatable bytes to just one [22:02:36] <BastyCDGS> "compression method" [22:03:10] <BastyCDGS> unpack(PI) => 3.14159265... [22:03:19] <BastyCDGS> one symbol (1 byte) unpacks to infinity unique bytes :D [22:03:46] <BastyCDGS> unpack(e) => 2.7182818... [22:03:48] <BastyCDGS> works too ;) [22:03:51] <BastyCDGS> so it's flexible ;) [22:04:22] <BastyCDGS> the other way is compressing infinite unique bytes to just one (huffman's dream) [22:24:54] <Tjoppen> speaking of comedy options and such, maybe I should get around to implementing a cinepak encoder? I have one sketched down on paper [22:25:07] <Dark_Shikari> lol [22:25:59] <Tjoppen> I even though about using SSIM for it - even the VQ step. that'd be interesting [22:27:30] <Tjoppen> but then again.. that's almost being serious :o [22:27:43] <Dark_Shikari> comedy option is almost done [22:27:45] <Dark_Shikari> you will lol [22:27:53] * Dark_Shikari waits for pngout to do its magic [22:30:46] * BastyCDGS 's bed is waiting for me going to sleep [22:30:53] <BastyCDGS> so I will you all a good night and nice dreams [22:31:22] <Dark_Shikari> hey, bink makes like a 3x smaller png [22:31:56] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/bink.png [22:32:09] <Dark_Shikari> Now that's fucking funny [22:32:34] <mru> that's comedy [22:32:56] <Tjoppen> hah. nasty :) [22:32:56] <BastyCDGS> yes never seen such a sharp image ;) [22:33:40] <elenril> lol [22:33:46] <Tjoppen> bedtime here as well [22:35:16] <BBB> uh [22:35:17] <BBB> wtf [22:35:21] <BBB> :) [22:35:28] <BBB> I suppose you're telling us the encoder is broken? :) [22:36:27] <Dark_Shikari> no, the encoder works quite fine [22:39:16] <CIA-7> ffmpeg: darkshikari * r23038 /trunk/ (4 files in 2 dirs): [22:39:16] <CIA-7> ffmpeg: Add intra refresh and crf-max support to the libavcodec libx264 wrapper. [22:39:16] <CIA-7> ffmpeg: Minor version bump. [22:42:36] <BBB> Dark_Shikari: it looks like shit [22:42:38] <BBB> all blocks are even [22:42:45] <BBB> with a few exceptions [22:42:54] <Dark_Shikari> the way it compresses the trees is rather interesting [22:43:04] <BBB> shitty [22:44:59] <astrange> 13:28 <@Dark_Shikari> oh, and the fact that muxing raw h264 -> mkv is broken <- it doesn't work for mp4 either, it just doesn't error (silently generating an invalid file is actually worse) [22:45:14] <Dark_Shikari> oh dear :/ [22:45:16] <Dark_Shikari> when was this broken? [22:45:31] <astrange> it never worked, the h264 parser doesn't set dts [22:45:38] <astrange> on at least some kinds of files [22:46:09] <kierank> it's been broken for ages [22:46:27] <astrange> i also want the mpeg4 parser to turn divxvid into real mpeg4 [22:46:41] <Dark_Shikari> why don't we have some intermediate filter that adds dts ? [22:46:46] <mru> astrange: difference? [22:46:49] <Dark_Shikari> so we don't have to write dts-generation code to every single parser? [22:46:59] <Dark_Shikari> mru: elimination of packed b-frames [22:47:00] <astrange> xvid has no global header, no dts, packed b-frames [22:47:22] <mru> "xvid has no dts" makes no sense [22:48:01] <astrange> the encoder doesn't emit dts, it just assumes a 1 frame delay and reordering in the decoder [22:48:06] <mru> and mpeg4 can store the vol header either out of band or repeated in-band (with I-frames) [22:48:24] <astrange> so it doesn't support mp4 without a parser [22:48:49] <astrange> now that i think about it, i haven't tried libx264 -> .mp4, but i'm pretty sure it doesn't work [22:50:00] <peloverde> WHAT! "Canonical has tried to clarify how — if not why — it has licensed a *closed-source* and patented codec for video on PCs running its Linux." [22:50:05] <mru> lately _everything_ I've tried has resulted in that dreaded non-monotone timestamp error or duplicated frames [22:50:18] <mru> peloverde: reading the register? [22:50:32] <peloverde> slashdot [22:50:46] <mru> I read that exact sentence in the register [22:51:06] <mru> and they've been smoking some serious crack lately [22:52:08] <astrange> i know ("know") a slashdot editor, nobody in the register though [22:52:16] <Dark_Shikari> wow, I guessed the qscale almost exactly on my svq1 encode [22:52:28] <peloverde> Being the original asker I feel a bit like this: http://www.smbc-comics.com/index.php?db=comics&id=1851#comic [22:52:41] <mru> peloverde: ah, /. is quoting the register [22:53:03] <Dark_Shikari> oh god svq1 is hilarious [22:57:06] <Dark_Shikari> http://mirror05.x264.nl/Dark/compare/svq1.png [22:57:16] <Dark_Shikari> bink actually beats it [22:57:37] <BBB> the trees look better though [22:57:47] <Dark_Shikari> eh, I prefer the bink trees [23:00:54] <Dark_Shikari> so, what else should I test [23:01:49] <BBB> snow :) [23:02:35] <Dark_Shikari> going ffmpeg mpeg-2 now [23:03:56] <janneg> s/mpeg-2 /s/ [23:07:06] <drv> the bink trees look like bizarro-world color by numbe [23:07:06] <drv> r [23:09:08] <Dark_Shikari> bink does at least seem very good at getting edges right [23:21:02] <kierank> test quicktime's svq [23:22:00] <Dark_Shikari> last I heard it was a disaster [23:22:04] <Dark_Shikari> at low bitrates, that is [23:22:06] <Dark_Shikari> the ratecontrol completely breaks

1 0

IRC log for 2010-05-05
by irc＠mansr.com 06 May '10

06 May '10

[00:00:04] <mru> alloca is every bit as dangerous as VLAs [00:00:10] <mru> in fact, it _is_ VLAs [00:00:16] <mru> calloc is malloc+memset [00:04:16] <Dark_Shikari> you should never be mallocing more than a constant number of times [00:04:29] <Dark_Shikari> If you have a set of data that's variable-size based on whenever the function is called, keep a scratch buffer [00:04:41] <Dark_Shikari> If you don't know the max size of the scratch buffer in advance, realloc (doubling size each time) if necessary [00:04:46] <Dark_Shikari> it's still a constant number of malloc calls. [00:06:39] <Dark_Shikari> for example, x264 has a big scratch buffer that's used by 5 different parts of the program. not at the same time obviously. [00:06:55] <Dark_Shikari> This gets you the advantage of alloca (cache coherence: they share the same scratch space) [00:07:00] <Dark_Shikari> without the shittiness of alloca [00:09:08] <BBB> hmk... [00:09:11] * BBB goes home to sleep [00:09:12] <BBB> tired [00:09:25] <BBB> oh, and I won the prize for best talk in my school just now! \o/ [00:09:31] <BBB> time to celebrate [00:09:33] <BBB> bye :) [00:22:29] <mru> Dark_Shikari: and you know the size of that buffer [00:22:35] <mru> you don't know the size of your stack [00:22:59] <Dark_Shikari> mru: that was my point exactly [00:23:04] <mru> the stack is possibly the most dangerous invention in the history of computing [00:23:13] <Dark_Shikari> Now, personally, I think alloca _should_ be fine [00:23:18] <Dark_Shikari> in that, if systems weren't shit [00:23:19] <Dark_Shikari> it would be fine [00:23:25] <Dark_Shikari> the two practical reasons it sucks being: [00:23:35] <Dark_Shikari> er, ok, 3 practical reasons [00:23:55] <Dark_Shikari> 1) on systems with crappy address spaces (too small), the stack is often not given enough space. Or the system just sucks and won't grow the stack beyond like 2MB. [00:23:57] <astrange> -fstack-protector is default on some systems now, isn't it? [00:24:09] <astrange> doesn't solve the problem of an actual stack overflow crash though [00:24:09] <Dark_Shikari> 2) I don't think it has a defined failure mode [00:24:24] <Dark_Shikari> 3) gcc sucks, and fomit-frame-pointer doesn't work in functions using alloca. [00:24:47] <astrange> also, you could av_fast_malloc a static buffer. iirc init_vlc doesn't have to be thread safe [00:25:34] <Dark_Shikari> static writable buffers are kinda evil [00:26:18] <Dark_Shikari> hmm. how does linux handle growing the stack? [00:26:35] <mru> page fault, swipe new page from system, map it in [00:26:44] <Dark_Shikari> yes, but how does it guarantee a page fault? [00:26:50] <Dark_Shikari> suppose you have 2mb of guard pages [00:26:53] <Dark_Shikari> and your stack usage is 3mb [00:26:54] <Dark_Shikari> what happens? [00:27:12] <Dark_Shikari> on windows, in functions with large stack usage, it calls a function at the start that touches each page that it's about to use for the stack [00:27:23] <Dark_Shikari> and thus it'll page fault if it goes beyond the currently allocated stack size [00:27:30] <Dark_Shikari> and windows will allocate more pages for the stack [00:27:50] <Dark_Shikari> I don't think linux has such a loop, so it's not guaranteed to be able to tell the OS how many pages it needs. [00:27:57] <Dark_Shikari> so I'm curious what it does instead. [00:28:12] <Dark_Shikari> ("just dies if the stack allocation is too large" is a perfectly valid, albeit stupid, answer) [00:29:04] <mru> that's not really a windows vs linux thing [00:29:09] <astrange> pretty sure it just dies [00:29:22] <Dark_Shikari> mru: I know for a fact linux must do something different [00:29:31] <Dark_Shikari> the windows ABI _requires_ you call that function if the stack usage > X, for some X I don't recall [00:29:34] <mru> the kernel doesn't give a shit [00:29:48] <astrange> os x x86-64 has a 56MB stack guard before the main thread, but it doesn't use it to extend it, and secondary threads only get 4kb stack guards [00:29:51] <Dark_Shikari> So you're saying it just dies? [00:29:51] <astrange> which is weird [00:29:53] <mru> it's easy to write a function in windows that doesn't call that thing [00:30:04] <Dark_Shikari> mru: then you've violated ABI, and your program crashes [00:30:15] <Dark_Shikari> the point is, windows has a mechanism for automatically growing the stack. as far as I can tell linux doesn't [00:30:19] <mru> just like on linux, you _could_ explicitly touch every page [00:30:30] <Dark_Shikari> but that doesn't help if you if the kernel isn't aware of it [00:30:41] <Dark_Shikari> from astrange's description, it sounds like the stack is statically allocated in terms of virtual address space [00:31:02] <Dark_Shikari> i.e. "you have this much address space for the stack. we'll allocate the physical pages on demand. if you run out of virtual address space, we'll kill your program." [00:31:11] <mru> historically the unix virtual address space looked like this: [00:31:38] <mru> |text|rodata|data|bss|heap brk> <stack top| [00:32:06] <mru> the heap grew linearly upward and the stack downward [00:32:08] <Dark_Shikari> so in theory there should be no limitations on stack usage [00:32:15] <mru> if they met in the middle, you died [00:32:15] <Dark_Shikari> other than (heap + stack) < some max [00:32:27] <Dark_Shikari> But I imagine that if you allocate, say, 200MB on the stack [00:32:29] <Dark_Shikari> even if you have 2GB free [00:32:31] <Dark_Shikari> it'll segfault [00:32:35] <mru> try it [00:32:38] <Dark_Shikari> because it won't know that you're trying to allocate a page on the stack [00:32:44] <Dark_Shikari> It'll think it's just a random invalid pointer [00:32:49] <Dark_Shikari> and segfault [00:32:50] <mru> there may well be some heuristic to kill such behaviour [00:32:57] <Dark_Shikari> ok, I'll try it [00:33:17] <mru> allocating more than 1k per frame is stupid anyway [00:33:25] <Dark_Shikari> well you need 4k [00:33:26] <mru> even that is a lot [00:33:27] <Dark_Shikari> a page ;) [00:33:42] <mru> I've worked on systems where stack was 2k per process [00:33:53] <mru> except for the rare ones that needed 4k [00:35:14] <Dark_Shikari> it segfaults with 200MB allocated [00:35:24] <Dark_Shikari> segfaults with 20MB [00:35:32] <Dark_Shikari> works with 2MB [00:35:57] <Dark_Shikari> it dies with about 8MB or above. [00:36:15] <Dark_Shikari> You know, this really bugs me. Because this is an x86_64 system and it should have all the address space in the fucking world to work with. [00:36:41] <Dark_Shikari> I mean, sure, you shouldn't _do_ that, but it's not like the OS doesn't have the resources to handle it right. [00:37:49] <mru> well, if you have a 4TB hole below the stack, at some point you'll have to assume a pointer has gone wild [00:38:00] <Dark_Shikari> well 4tb is one thing [00:38:03] <Dark_Shikari> 8mb is another =p [00:39:02] <Dark_Shikari> interesting. Windows has a max of 1MB by default, but you can set it in the linker. [00:39:32] <Dark_Shikari> it has two values you can set: initially committed size and maximum size. [00:39:37] <Dark_Shikari> which sorta makes sense. [00:40:12] <mru> http://www.opengroup.org/onlinepubs/009695399/functions/setrlimit.html [00:40:18] <mru> RLIMIT_STACK [00:40:30] <mru> ulimit -s in the shell [00:40:33] <Dark_Shikari> oh cool [00:51:28] <astrange> In function 'skip_bits': warning: variable 're_cache' set but not used [-Wunused-but-set-variable] [00:51:30] <astrange> so it is [00:54:23] <astrange> huh, is that being emitted after optimization? if so it should be suppressed in macros [00:54:58] <pengvado> astrange: init_vlc has to be as threadsafe as any other single-threaded piece of a codec. iirc libavcodec as a whole wants to be reentrant, right? [00:56:39] <pengvado> Dark_Shikari: well, you could check %rsp whenever anything segfaults. though at some point you have to assume that something clobbered the stack pointer rather than that it actually allocated 4tb. [00:57:00] <astrange> yeah, avcodec_open is explicitly not reentrant but the rest is [00:57:35] <astrange> it would have to be thread-local which is annoying to use unfortunately [01:00:18] <mru> pengvado: it's perfectly normal to pass addresses on the stack as pointers to other functions [01:00:26] <mru> then the access wouldn't be through the stack pointer [01:01:12] <astrange> i saw a valgrind tool that could track origins of pointers pointers but it bitrotted [01:01:51] <pengvado> I didn't say anything about how the address was generated. rather, compare the address that segfaulted against the current value of the stack pointer. [01:17:14] <mru> why does the current value of the stack pointer matter? [01:17:34] <mru> there's a certain amount of virtual address space reserved for the stack [01:17:41] <mru> stay within, and you're good [01:20:49] <pengvado> so the no storing of data below the stack pointer (or below the redzone, if there is one) is entirely due to it getting clobbered by exception handlers, not memory allocation? [01:22:44] <mru> yes [01:26:25] <mru> ok, I don't know for sure that linux doesn't compare to the stack pointer on page fault [01:26:59] <mru> but doing that would have little benefit, if any [01:43:07] <Dark_Shikari> mru: ping [01:43:39] <mru> pong [01:43:51] <Dark_Shikari> so, I found out why their decoding was too slow [01:43:57] <Dark_Shikari> YUV->RGB conversion in software, no asm [01:44:02] <mru> hehe [01:44:03] <Dark_Shikari> since swscale has no neon [01:44:09] <Dark_Shikari> So, suppose they're not able to get access to the hardware for this [01:44:17] <Dark_Shikari> How fast do you think you could do YV12->RGB32? [01:44:24] <mru> *FAST* [01:44:25] <Dark_Shikari> compared to C [01:44:31] <Dark_Shikari> like, 5x-10x faster? [01:44:40] <mru> 5x at least [01:44:52] <Dark_Shikari> and how much work would it be? i.e. what would you charge [01:45:02] <Dark_Shikari> and could you add it to swscale? [01:46:17] <astrange> iphone os 4.0 supports opencl [01:46:39] <astrange> or so i'm told by an unreliable blog post, anyway [01:46:43] <ohsix> peloverde: have you tried 10.04 yet? [01:52:11] <RTFM_FTW> LOL you do NOT need OpenCL to blit from YUV <-> RGB :P [01:52:20] <RTFM_FTW> complete overkill IMHO [01:52:32] <Dark_Shikari> astrange: and yet it doesn't give you access to native conversion apis? [01:52:35] <RTFM_FTW> specifically on a < iPhone, iPod Touch, iPad > [01:53:01] <RTFM_FTW> you can do this sort of thing trivially through existing 3D APIs if its necessary [01:53:02] <astrange> what's a native conversion api? [01:53:06] <astrange> opengl works fine, yeah [01:53:12] <Dark_Shikari> oh, you can, from appspace? [01:53:14] <Dark_Shikari> that'll work then [01:53:40] <RTFM_FTW> and ultimately OGL is likely how they are doing it (in a number of cases)... [01:53:59] <RTFM_FTW> since the HW block isn't viable for everything :) [01:54:06] <RTFM_FTW> *isn't necessarily [01:54:15] <astrange> it would be interesting if libswscale had a libhwscale for that [01:54:46] <astrange> as long as enough maintainers own programmable gpus [01:55:07] <RTFM_FTW> in any case doing HW YUV -> RGB even in ES1 is significantly faster than through a SW path... 6x or more on average [01:55:12] <RTFM_FTW> is what I've found [01:55:30] <Dark_Shikari> would you have to use a shader to do the conversion? [01:55:38] <Dark_Shikari> or can it do it on ipad natively? [01:55:39] <RTFM_FTW> ES2 is likely better... OTOH you are killing the CPU with useless work in EITHER case [01:55:58] <RTFM_FTW> anything capable of supporting ES2 can use the programmable fragment pipeline for this [01:56:14] <RTFM_FTW> ES1 is fixed function so the work is slightly more challenging [01:56:18] <RTFM_FTW> but its still quite possible [01:56:36] <RTFM_FTW> I did both [02:00:09] <Compn> libvo has lots of hw rgb scaling [02:00:20] <Compn> opengl shaders ... [02:00:29] <Compn> maybe d3d but i dunno... [02:01:43] <RTFM_FTW> doing it in either API is pretty trivial [02:11:47] <ohsix> RTFM_FTW: is a subset of quartz extreme available? [02:12:32] <RTFM_FTW> QE has nothing to do with this on iPhone [02:12:40] <mru> wtf, facebook popped up an error message in spanish [02:12:42] <RTFM_FTW> i.e. its entirely irrelevant [02:13:09] <ohsix> no doubt; just wondering if its available, they use it for a lot of stuff on osx [02:13:35] <RTFM_FTW> in any case on iPhone etc. one has access to < ES1 and / or ES2 > through a dedicated 3D (i.e. MBX, SGX) path [02:13:54] <RTFM_FTW> and with this one also has indirect access to a dedicated (HW) video decode pipeline [02:14:04] <RTFM_FTW> which supports MP4 and H.264 [02:14:13] <RTFM_FTW> for anything else you are in SW land [02:14:37] <RTFM_FTW> in any case QE just implies the use of GL for compositing [02:15:29] <RTFM_FTW> on the desktop this means that the QE accelerated system has a HW renderer with support for GL_APPLE_client_storage, GL_APPLE_texture_range, GL_APPLE_ycbcr_422 and GL_EXT_texture_rectangle [02:15:39] <ohsix> i know what gl can do; it was more of an aside, i haven't seen anything confirming or denying quartz composer could be used for stuff [02:16:06] <RTFM_FTW> a very small subset of those (the last one) is currently available on iPhone [02:16:31] <RTFM_FTW> QC doesn't exist on iPhone as far as clients are concerned [02:16:42] <RTFM_FTW> and it wouldn't be used for this anyway [02:16:59] <kierank> i wonder if the native h.264 interface will support the crazy number of slices Dark_Shikari is using [02:17:04] <ohsix> i know, and i know what you can do with gl too; don't need to convince me :D [02:17:17] <RTFM_FTW> on the desktop one also has access to GL_APPLE_rgb_422 [02:17:45] <RTFM_FTW> which gives you a direct (4:2:2) texture interface w/o server side YUV -> RGB color-space conversion [02:18:06] <RTFM_FTW> since in a number of cases the server side color-space conversion isn't necessarily adequate [02:24:12] <ohsix> nod [02:25:06] <ohsix> a "hwscale" library would be kind of tricky if you actually needed readbacks [02:26:44] <mru> depends on the hardware [02:26:53] <mru> I've used hardware where it was very simple [02:27:05] <mru> shared memory of course [02:27:29] <ohsix> its about being worth it in terms of time in flight; it can get really expensive [02:27:30] <astrange> opengl 2.0 has pixel buffers [02:27:30] <astrange> *2.1 [02:27:48] <astrange> it does depend on the system bus but modern pcs can certainly handle it [02:27:54] <mru> when your cpu is a 300MHz MIPS almost anything is worth it [02:28:39] <ohsix> theres probably a local framebuffer on something like that [02:28:51] <mru> shared memory [02:28:54] <mru> all of it [02:30:33] <RTFM_FTW> reading the FB is *always* going to be a losing proposition [02:30:38] <RTFM_FTW> WRT performance [02:30:49] <mru> look, there is no FB on this system I'm talking about [02:30:53] <mru> it's all the same dram chip [02:31:06] <RTFM_FTW> the best suggestion is to structure your algorithm(s) such that you don't have to do this [02:31:08] <ohsix> i knowl but its not typical [02:31:17] <mru> it's very typical of embedded systems [02:31:26] <RTFM_FTW> if you are looking to target any GPU accelerated system [02:31:37] <mru> like an omap3 [02:31:42] <RTFM_FTW> like anything [02:31:49] <mru> arm and gpu share the same memory there [02:32:01] <mru> and the display driver is quite separate [02:32:12] <RTFM_FTW> even SoC suck ass when it comes to this particular feature [02:32:15] <mru> also using the same ram of course [02:32:26] <RTFM_FTW> and they suck ass not necessarily due to where the DRAM interface happens to be :P [02:32:37] <ohsix> even with local memory, gpu regions are usually set uncached and readbacks still suck [02:32:44] <mru> dedicated graphics memory is often better when you don't need readback [02:32:58] <mru> only lazy people do that [02:33:03] <RTFM_FTW> having to flush context state in order to read from FB memory isn't a cheap operation [02:33:16] <RTFM_FTW> no matter *how* the memory interface is structured [02:33:29] <ohsix> its cheaper with pbo's and fences though [02:33:52] <RTFM_FTW> its only cheaper if you can interleave additional client side work with that operation [02:33:56] <mru> cache flushes aren't *that* expensive [02:34:00] <mru> if done right [02:34:00] <RTFM_FTW> if you cannot then its not any cheaper [02:34:11] <ohsix> nod; thats what fences let you do [02:34:40] <RTFM_FTW> and that is entirely algorithm dependent [02:34:48] <ohsix> mru: its more like a wait until fifo empty operation where almost everything is async [02:35:07] <RTFM_FTW> WRT cache flushing being cheap that really depends upon the processor in question [02:35:33] <ohsix> with fences though; you can query if your marker has made it out instead of implicit flush [02:35:44] <RTFM_FTW> yup [02:36:22] <mru> sometimes setting caches to write-through works best [02:36:32] <RTFM_FTW> but as I said above this is still entirely algorithm dependent... [02:36:44] <mru> if most writes are missing the cache anyway [02:36:52] <RTFM_FTW> (concerning the efficiency of PBO etc.) [02:37:08] <RTFM_FTW> that also BTW doesn't exist in ES :P [02:37:49] <ohsix> its way too classy for ES :D [02:38:13] <mru> generally speaking, sending a job off to another processing unit is worth it if the cost of communication is less than the cost of doing it yourself [05:34:09] <KotH> god mordor! [05:35:48] <elenril> morning [06:00:07] <pJok> god morgon kshishkov :) [06:00:47] <Dark_Shikari> kshishkov: see advice given earlier on yuv2rgb [06:00:49] <Dark_Shikari> by pengvado [06:07:23] <pJok> KotH, kshishkov simply walks into mordor! [06:29:11] <peloverde> <insert obligatory comment about post-communist Ukraine being like Mordor> [06:30:58] <Dark_Shikari> no, no, no [06:31:22] <wbs> RTFM_FTW: btw, care to describe how you do yuv->rgb using ES1? [06:31:36] <Dark_Shikari> russia == mordor (putin is sauron) [06:32:24] <ohsix> you could snag it from gstreamers gl renderer :] [06:38:04] <wbs> ohsix: I've actually looked at it, and it doesn't seem to support ES1 [06:38:29] <ohsix> if it has a fixed pipeline one its just a manner of moving some stuff around [06:40:27] <ohsix> moblin has some stuff too [06:43:02] <_av500_> bonjour mes enfants [06:50:04] <astrange> matrix multiply can be done in es1.1 using glTexEnv [06:50:07] <astrange> see http://developer.apple.com/iphone/library/samplecode/GLImageProcessing/List… hue() [06:50:50] <ohsix> is imaging not optional with ES? [06:51:41] <ohsix> i guess if its the iphone, and its right there; it doesn't matter [06:52:29] <astrange> yeah [06:52:40] <wbs> ah, I see, sneaky to do it in multiple passes. :-) [06:53:12] <astrange> don't know how to do it in es1.0. maybe GL_MODULATE + additive blend + a lot of passes but it wouldn't be very accurate [06:59:52] <siretart> buna diminaca [07:19:19] <kshishkov> Dark_Shikari: ok, I'll try to implement it. Loongson has MMX too :) [08:42:01] <CIA-7> ffmpeg: conrad * r23020 /trunk/libavformat/mov.c: mov: Read nero chapters [08:42:01] <CIA-7> ffmpeg: conrad * r23021 /trunk/libavformat/movenc.c: movenc: Swap positions of mov_write_header and mov_write_packet [08:42:02] <CIA-7> ffmpeg: conrad * r23022 /trunk/libavformat/movenc.c: movenc: Write QuickTime chapters [09:39:50] <BastyCDGS> is there a nice macro for creating a grayscale RGB8 color value, i.e. FFGRAY(0xAB) will decode to 0xFFABABAB? [09:40:21] <kshishkov> nope, *0x010101 | 0xFF000000 would do [09:40:49] <BastyCDGS> I did this, but find this ugly: [09:40:50] <BastyCDGS> const uint32_t gray_col = (i * 255 / count) & 0xFF; [09:40:51] <BastyCDGS> pal[i] = 0xFF000000 | gray_col | (gray_col << 8) | (gray_col << 16); [09:41:29] <wbs> #define GRAY(x) (0xff000000 | (x) | ((x) << 8) | ((x) << 16) [09:41:33] <kshishkov> well, 0xFF000000 | (gray_col * 0x010101) is a bit more compact [09:41:52] <wbs> no need to have the framework define it for you if it isn't something that's universally useful [09:42:02] <kshishkov> I don't think we had the need for such macro [09:42:27] <_av500_> we wants colors, not grayscales [09:42:55] <kshishkov> and if we want grayscales we output it as grayscale format [09:42:58] <BastyCDGS> the thing is that if the IFF ILBM has no color map the standard defines to assume a default grayscale palette according to the formula above... [09:44:34] <Kovensky> astrange: that sample you gave me yesterday doesn't build with suncc (cc -S test.c) [09:45:10] <Kovensky> astrange: http://pastebin.org/202902 [09:45:24] <astrange> try -D__restrict= [09:45:38] <astrange> + -fast, i think that's suncc -O3 [09:46:04] <BastyCDGS> well should I use PIX_FMT_GRAY8 instead then? [09:47:01] <BastyCDGS> and just write the gray color index one time instead using the GRAY macro as above? [09:48:03] <kshishkov> hmm, you have scaled grayscale palette [09:48:37] <kshishkov> what values can that "count" variable take? [09:49:13] <BastyCDGS> always a power of 2, i.e. 1 << bps (bps always <= 8) [09:49:19] <BastyCDGS> bps = number of bitplanes [09:49:29] <Kovensky> astrange: http://pastebin.org/202922 <-- cc -S test.c -fast -native -D__restrict= [09:49:32] <kshishkov> ah [09:49:51] <kshishkov> looks like you'll need to create that palette then [09:49:57] <kshishkov> or scale output [09:52:07] <astrange> wtf? even if it unrolls that loop all the way it doesn't need a huge stack like that [09:54:21] <Kovensky> lol [09:55:05] <astrange> the other small functions look like a generic function that was ported without using any special architecture features [09:55:12] <astrange> (no sbb, no rorw(!)) [09:55:17] <astrange> *generic compiler [09:55:31] <astrange> and unrolling a loop is useless on x86 anyway [11:30:37] <mru> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347 [11:31:45] <mru> gcc 4.5 fails to build on arm, ppc, alpha, ... [12:46:47] <freakabcd_> hi all [12:47:43] <freakabcd_> is avpicture_get_size(PIX_FMT_RGBA, sx, sy) supposed to return a value of sx*sy*4 ? [12:48:05] <kshishkov> strewth, no! [12:48:28] * twnqx wonders what other value freakabcd_ would have expected [12:48:32] <freakabcd_> kshishkov, was answer for me? i see no one called strewth here [12:48:47] <freakabcd_> twnqx, it returns a different value :( [12:49:06] <freakabcd_> eg: anim->x=320, anim->y=240, avipicture_get_size()=77824 [12:49:06] <kshishkov> freakabcd_: by golly, that answer was for you [12:49:25] <twnqx> is it talk like a fisherman day? [12:50:53] <kshishkov> have you read the comment in avcodec.h ? [12:51:46] <freakabcd> lol, ok.. makes sense. returns 0 on success, -ve otherwise [12:51:52] <freakabcd> wait no.. [12:51:55] <freakabcd> wrong function. [12:52:12] <kshishkov> it's linesize * height [12:52:26] <kshishkov> and linesize > width [12:52:40] <twnqx> the number is too small. by a factor of 4. [12:53:03] <twnqx> you have to multiply by bpp yourself, iirc [12:53:13] <kshishkov> nope [12:53:27] <freakabcd> twnqx, no it is not bpp [12:53:37] <twnqx> but 77824 would suffice for one byte per pixel, which is not quite RGBA-ish [12:54:14] <kshishkov> and with height like 240 you'd also get picture size divisible by ten [12:54:17] <mru> rgba2222 :-) [12:54:19] <twnqx> (unless you have 2 bits each for R, G, B, A) [12:54:20] <twnqx> :D [12:55:05] <kshishkov> mru: feel not free to add it to swscaler [12:55:46] <freakabcd> ok, i don;t understand linesize [12:56:15] <freakabcd> whats the definition of a 'line', sorry i'm new to ffmpeg (and video encofing/decoding, etc.) [12:56:26] <kshishkov> one line of pixels [12:56:34] <Tjoppen> linesize ~ stride [12:56:38] <kshishkov> linesize is its length in bytes [12:57:13] <kshishkov> and usually line size is made to be multiple of 16 or so [12:57:42] <twnqx> kshishkov: then i don't get why he gets 77824 for avpicture_get_size(PIX_FMT_RGBA, 320, 240) [12:58:11] <kshishkov> twnqx: neither do I [12:58:25] <twnqx> good ;) (or not so much, but...) [12:58:43] <freakabcd> yes, i don;t understand it.. i tried various multipliers to find some way to explain the difference in size but was unable to do so [12:59:10] <freakabcd> another example: anim->x=720, anim->y=480, avipicture_get_size()=346624 [12:59:11] <Tjoppen> maybe it added a palette? [12:59:22] <Tjoppen> (77824-1024)/240 = 320 [12:59:24] <twnqx> what is anim? [12:59:36] <mru> well, you're all wrong [12:59:45] <mru> because it returns 307200 [12:59:58] <kshishkov> only if you use it correctly [13:00:01] <mru> which is 320*240*4 [13:00:04] <mru> kshishkov: :-) [13:00:23] <twnqx> freakabcd: feel free to pastebin your code, not just a fragment [13:00:24] <freakabcd> twnqx, a var of a different struct [13:00:33] <freakabcd> twnqx, https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/imb… [13:00:34] <freakabcd> :D [13:01:20] <twnqx> why do people use https for crap like that if they don't have valid certs... [13:01:22] <freakabcd> its the blender code.. i'm trying to figure out why blender barfed saying FFmpeg changed alloc scheme [13:01:24] <twnqx> not opening it. [13:01:52] <mru> twnqx: probably becase getting a cert signed by a trusted authority costs $$$ [13:02:05] <twnqx> then don't use https [13:02:06] <mru> we also use self-signed certs [13:02:07] <elenril> >trusted [13:02:09] <elenril> by whom? [13:02:15] <twnqx> by my browser. [13:02:38] <freakabcd> i dunno what the issue is what 'temporarily' accepting a cert for the blender svn repo [13:02:41] <twnqx> freakabcd: might you by chance have multiple ffmpeg versions installed? [13:02:44] <elenril> which is more secure how? [13:02:47] <mru> a self-signed cert is as good as any for securing the link [13:02:47] <freakabcd> twnqx, no [13:02:55] <freakabcd> i have only latest [13:03:19] <twnqx> mru: yes, but it requires loads of clicks and just uselessly encrypts a... OSS source code. [13:03:33] <mru> twnqx: yes, in this case it's useless [13:03:48] <mru> but sometimes passwords are sent over the link [13:03:57] <mru> and then you'd rather have it encrypted [13:04:17] <twnqx> yeah, for my own stuff i just imported my ca cert [13:04:35] <twnqx> but self-signed certs are meaningless [13:04:43] <mru> no they're not [13:04:55] <twnqx> if someone can tap your link they usually can as well do mitm on your transaction [13:04:57] <mru> there are other ways you could verify the signature [13:05:02] <mru> like calling up the site admin [13:05:05] <mru> if you know him [13:08:53] <kshishkov> they should implement that on sourceforge [13:10:42] <RTFM_FTW> astrange you don't need many passes for YUV -> RGB [13:11:04] <RTFM_FTW> and you have support for DOT3 (through the FF texture environment) in ES1 [13:13:42] <freakabcd> bloody hell!! you were right.. the ubuntu guys left some libs in /usr/lib/i686/cmov [13:13:43] <freakabcd> grr.. [13:14:02] <freakabcd> and i thoguth uninstalling the packages would have removed the files completely.. [13:14:09] <twnqx> > ubuntu [13:14:10] <wbs> RTFM_FTW: but doesn't dot3 set the same value for all rgb components? how do you do do all of them in one pass? [13:14:17] <freakabcd> removed those so files by hand and now it is perfect :D [13:14:31] <twnqx> grats [13:14:41] <freakabcd> good thing i decided to check with ldd which libs blender was dynamically linked to [13:14:53] <mru> wasn't symbol versioning supposed to fix this? [13:15:15] <twnqx> he's using ubuntu [13:15:20] <twnqx> prolly means he's on 0.5 [13:15:33] <twnqx> versioning was newer, right? [13:15:34] <mru> oh, wait... he's not linking against the libs whose headers he's using [13:15:43] <thresh> symbol versioning doesnt fix the situation where you link with a library which is in its turn linked to some older library and you have some newer one [13:15:49] <thresh> that, too [13:15:59] <freakabcd> mru, i dunno what was happening.. for some reason ld was assuming the so files in /usr/lib/i686/cmov had higher (load)priority than the ones in /usr/lib [13:16:27] <freakabcd> and the ones in /usr/lib were the ones from git and had the right symlinks and all [13:17:15] <freakabcd> all i did was simply delete the so files from that other dir and everything was normal [13:52:12] <Tjoppen> odd. the mov demuxer doesn't support "url " tags in the dref tags - only alis tags [13:52:36] <kshishkov> maybe it was for security? [13:53:04] <Tjoppen> "url " is just a normal URI.. and it does the security stuff in another place [13:53:36] <kshishkov> randomly downloading stuff from elsewhere is not very secure [13:53:48] <Tjoppen> ah, right [13:54:42] <Tjoppen> one generally wants relative URIs anyway, which is what alis is for (sort of) [14:23:59] <twnqx> audacious Commando.sid [14:23:59] <twnqx> Format detected only with low score of 1, misdetection possible! [14:23:59] <twnqx> [aac @ 0x19b3790]channel element 2.8 is not allocated [14:24:03] <twnqx> >_> [14:24:24] <kshishkov> so it detected audio! [14:25:06] * twnqx demands .sid support in ffmpeg [14:25:54] * twnqx reinstalls audacious-plugins with dedicated sid support [14:26:23] <kshishkov> patchiswelcome [14:26:50] <twnqx> increasing dependies is welcome? :P [14:27:11] <kshishkov> and probably we'll get proper chiptunez support some day [14:27:35] <kshishkov> no, no more external dependencies (except for other apps on FFmpeg) [14:27:54] <twnqx> no going to copy&paste libsidplay into ffmpeg. [15:38:37] <BastyCDGS> hi jai [15:39:02] <BastyCDGS> I think I got it with extradata and backwards compatibility [15:39:37] <BastyCDGS> the new decoder now detects if it's an old iff demuxer and behaves the old way then [15:48:01] <BBB> I still think it's bad habit [15:48:08] <BBB> what if you need to add new fields? [15:48:28] <BBB> can you try using other AVCodecContext fields, or alternatively making it a single int32_t, and using it as a "flags" field? [15:49:27] <BBB> and don't worry about alignment [15:49:30] <BBB> the compiler will do that for you [15:49:36] <BBB> please don't do things the compiler knows better than you [15:49:50] <kshishkov> err, wrong channel? [15:50:10] <mru> seems on-topic to me [15:50:35] <kshishkov> "please don't do things the compiler knows better than you" - seems too rare for FFmpeg [15:50:41] <BBB> haha :) [15:50:48] <BBB> how's multirate support in .rm going? [15:51:39] <mru> kshishkov: it's still true [15:51:50] <mru> compilers get a few things right [15:54:51] <BBB> particularly since any fixed alignment only works for a limited number of archs [15:55:04] <BBB> "works" being "makes it better" [16:01:04] <kshishkov> BBB: well, everything is stalled for now [16:01:11] <BBB> :( [16:01:29] <BBB> I wish I could help you move country in some way [16:01:33] <kshishkov> and the worst part is that it seems my Gdium can't connect to WiFi anymore [16:01:59] <kshishkov> BBB: thanks, but I'll stay here in Germany for a while [16:02:13] <BBB> oh you're in a better country already [16:02:15] <BBB> that's good [16:02:19] <BBB> still not great, but good [16:02:23] <BBB> how long are you there for? [16:03:03] <kshishkov> dunno [16:04:55] <BastyCDGS> BBB, oh just read it now [16:05:23] <BastyCDGS> it's just have you read the critics from Martin on ml? [16:05:40] <BastyCDGS> the extradata stuff should be backwards compatible [16:08:11] <BastyCDGS> what is void *opaque? [16:08:22] <BastyCDGS> can I use this instead of extradata? [16:08:37] <BastyCDGS> hmm, docs say private data for user... [16:09:52] <BastyCDGS> btw, seeing this I'ld like to add: #define FF_BUG_ADOBE 32768 [16:09:52] <BastyCDGS> the thing is that adobe photoshop writes wrong byterun1 encoded IFF files... [16:10:15] <BastyCDGS> instead of handling -128 as noop it does a data decode... [16:10:23] <BastyCDGS> (encode) [16:17:39] <BastyCDGS> BBB, the new fields issue I added a comment to iff.h how to handle this (didn't create a patch yet for it): [16:17:40] <BastyCDGS> /** [16:17:40] <BastyCDGS> * IFF extra context. This structure is appended to actual palette data. [16:17:40] <BastyCDGS> * Data is always stored in big-endian format. [16:17:40] <BastyCDGS> * [16:17:40] <BastyCDGS> * If you add new data here, please add a identifier tag != 0 before it [16:17:40] <BastyCDGS> * and check for the existence of identifier before accessing the new data. [16:17:41] <BastyCDGS> */ [16:18:51] <BastyCDGS> the structure itself is always memset'd to 0 bytes before doing anything else with it [16:18:56] <BastyCDGS> so that should work fine. [16:26:38] <BBB> you're using only 1 bit per four bytes [16:26:42] <BBB> why not a flags field? [16:26:46] <BBB> at least that's expendable [16:27:37] <BastyCDGS> well I did in the first patch but Martin recommended to make them all byte only to avoid compiler aligning data structures [16:28:07] <BastyCDGS> or do you mean byte flag fields? [16:28:16] <BBB> I mean a flags field in which you store all bits [16:28:17] <BBB> not just one [16:29:29] <BastyCDGS> the thing is that transparency now starts on 4 byte boundary, if I remove ex->ehb and ex->ham it will start on 3 byte boundary [16:29:39] <BastyCDGS> transparency is uint16_t [16:30:08] <BastyCDGS> reading this will slow down if it starts on an odd address, so I either do a flags uint8_t and a uint8_t pad [16:30:30] <BastyCDGS> or I do a uint8_t[2] and have AV_RB16 it... [16:31:37] <BastyCDGS> masking and compression aren't bit flags [16:31:50] <BastyCDGS> and transparency also isn't [16:34:22] <BastyCDGS> or wait...what about this? [16:34:38] <BastyCDGS> doing 2 flags? one uint8_t named palette_flags (for EHB) [16:34:49] <BastyCDGS> and one uint8_t decode_flags (for HAM) [16:35:02] <BastyCDGS> or bitmap_flags? [16:40:32] <BBB> like I said, compilers do alignment for you [16:40:33] <BBB> don't worry [16:40:44] <BBB> compilers are really quite good at some things [16:40:57] <BastyCDGS> yes but the problem is that it shouldn't align in extradata [16:41:07] <BastyCDGS> just see Martin's comment in ml on that [16:41:23] <BastyCDGS> it should be possible that a libavcodec on a totally different machine can also handle extradata [16:41:27] <BBB> then add it to the end [16:41:31] <BBB> the pallete data is aligned [16:41:33] <BBB> first palette [16:41:35] <BBB> then flags [16:41:37] <BBB> instead of inverse [16:47:19] <BastyCDGS> it's already at the end ;) [17:04:45] <BBB> so how is it not aligned then? [17:04:50] <BBB> add one int32_t [17:05:17] <CIA-7> ffmpeg: cehoyos * r23023 /trunk/libavcodec/iff.c: [17:05:17] <CIA-7> ffmpeg: Align plane size to word-boundary. [17:05:17] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A googlemail [17:09:33] <BastyCDGS> BBB, you're misunderstanding me [17:09:53] <BastyCDGS> the data structures in between should never be aligned by the compiler as in #pragma pack(1) [17:14:42] <mru> warning: unknown pragma "pack(1)" [17:15:14] <BastyCDGS> yes that's why I'm not using it but instead just use uint8_t [17:15:31] <mru> because I don't know what it means? [17:16:14] <BastyCDGS> it tells any compiler supporting it to pad all elements in a structure to 1-byte (i.e. turn off any padding) [17:16:24] <mru> wrong [17:16:29] <mru> in some compilers it might mean that [17:16:42] <BastyCDGS> as said, any compiler supporting it ;) [17:16:47] <mru> another compiler supporting something by that name might do something different entirely [17:16:48] <Dark_Shikari> you'd use __attribute__((packed)) in gcc [17:17:13] <BastyCDGS> do we have macros for this to do this platform independent? [17:17:27] <mru> we don't do it [17:17:37] <mru> it's always wrong to do it [17:17:44] <BastyCDGS> so then it's the best way as I did it, just use uint8_t's? [17:17:59] <mru> no, that's also wrong [17:18:14] <Dark_Shikari> I can imagine it being useful to pack a struct in some cases [17:18:18] <mru> you should never, ever rely on the precise layout of a struct [17:18:20] <Dark_Shikari> but... in 99% of cases, there's a better way to do it [17:18:23] <Dark_Shikari> well that's a given [17:18:29] <Dark_Shikari> NEVER EVER assume a precise struct layout [17:18:32] <Dark_Shikari> unless you're pengvado [17:18:33] <BastyCDGS> should I remove the struct completely and do a #define OFFSET_BLABLA 0 etc.? [17:18:44] <Dark_Shikari> BastyCDGS: if you need to know specific offsets, offsetof() [17:18:48] <mru> I don't know what you're trying to do [17:19:01] <mru> Dark_Shikari: that's solving the wrong problem [17:19:08] <BastyCDGS> the thing is that the offsets have to be the same on ALL platforms/architectures ffmpeg supports/will support [17:19:09] <Dark_Shikari> mru: well I don't know what his problem is =p [17:19:22] <Dark_Shikari> BastyCDGS: why? [17:19:23] <mru> I think he's trying to read/write a fixed-format data blob [17:19:31] <Dark_Shikari> in that case you use the bitstream reading/writing functions [17:19:32] <Dark_Shikari> hurr [17:19:36] <BastyCDGS> sharing extradata [17:19:40] <mru> or bytestream if everything is byte-aligned [17:19:46] <Dark_Shikari> mru: off-topic, are there any real systems where NULL is not zero? [17:19:55] <mru> never seen one [17:19:57] <Dark_Shikari> Since we pretty much assume it is, and TECHNICALLY C doesn't require it [17:20:03] <BastyCDGS> just read the reply to my patch from Martin [17:20:05] * Dark_Shikari makes note to add it to x264's "standards.txt" [17:20:16] <mru> Dark_Shikari: depends on what mean too [17:20:43] <mru> a literal 0 in a pointer context is always a null pointer [17:20:56] <BastyCDGS> the post at around 12:30 UTC from him [17:20:56] <mru> and a null pointer always tests as false in an if() statement etc [17:21:01] <Dark_Shikari> really? [17:21:03] <mru> yes [17:21:05] <mru> that's required [17:21:17] <Dark_Shikari> so you're saying [17:21:17] <mru> however, the bit pattern of a null pointer need not be all zeros [17:21:19] <Dark_Shikari> if( pointer ) [17:21:23] <Dark_Shikari> is required to give the same results as [17:21:25] <Dark_Shikari> if( pointer == NULL ) [17:21:26] <mru> yes [17:21:34] <Dark_Shikari> hmm. I don't recall the spec saying that. [17:21:40] <mru> let me find it [17:21:51] <Dark_Shikari> er, I mean if (!pointer) [17:21:51] <Dark_Shikari> obviously [17:22:14] <mru> yeah [17:22:17] <mru> obviously [17:22:21] <mru> didn't even see that typo [17:22:33] <mru> section 6.3.2.3 [17:22:38] <BastyCDGS> well is there practically even any compiler doing NULL != 0 as int value? [17:22:54] <Dark_Shikari> mru: c99? [17:22:57] <mru> yes [17:24:30] <Dark_Shikari> oh, so 0 HAS to be null [17:24:32] <Dark_Shikari> there can be other values [17:24:40] <Dark_Shikari> but pointers assigned a value of zero are also null? [17:24:48] <mru> 0 converted to a pointer must give a null pointer [17:24:51] <mru> not the other way around [17:24:51] <Dark_Shikari> ah k [17:25:00] <Dark_Shikari> and a null pointer converted to an integer must give zero? [17:25:14] <mru> I don't think that's required [17:25:23] <Dark_Shikari> but then those two ifs I gave above aren't equivalent [17:25:29] <mru> the spec talks only about integer constant expressions [17:28:02] <CIA-7> ffmpeg: cehoyos * r23024 /trunk/libavformat/iff.c: [17:28:02] <CIA-7> ffmpeg: Parse IFF metadata. [17:28:02] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A googlemail [17:30:59] <BBB> I remember some gstreamer asf demuxer bug [17:31:07] <BBB> because someone had written it relying on padding in structs [17:31:10] <mru> also, "the first substatement is executed if the expression compares unequal to 0" [17:31:15] <BBB> he was basically doing read(fd, struct, sizeof(struct)); [17:31:17] <BBB> and it didn't work [17:31:19] <BBB> :-p [17:32:17] <mru> that's heresy [17:36:05] <BBB> let me find the commit [17:36:13] <BBB> I'm sure you'd remove my commit rights if you knew it was me [17:42:20] <BastyCDGS> well, when we were young and juvenile we did all do such kind of errors ;) [17:42:27] <BastyCDGS> no thing to worry about, BBB :) [17:43:00] <Kovensky> ffms's index file format is just a memory dump of a struct [17:43:07] <Kovensky> same for gcc's pch format, or so I heard [17:43:38] <mru> if the file will only ever be used by the same app on the same machine, that's ok [17:44:03] <BastyCDGS> yes mru and this was the problem I ran into with extradata ;) [17:44:15] <BastyCDGS> it should be transferable between different machines [17:44:36] <mru> so use the most suitable serialising tools we have [17:44:46] <mru> bytestream.h and get/put_bits.h [17:44:47] <TheFluff> the index files are not exactly supposed to be distributed [17:44:51] <Kovensky> if C had reflection one could write a struct (de|)serializer :) [17:45:03] <mru> but then it would cease to be c [17:45:09] <Kovensky> indeed [17:47:29] <mru> I once made a system where both structs and [de]serialising code were generated from a separate description [17:47:41] <mru> many such systems exist [17:48:22] <Kovensky> make each struct a linked list of key/value pairs? :) [17:48:56] <mru> the same tool that spits out struct defs can spit out code to deal with them [17:49:06] <Kovensky> struct generic_struct { char *key; void *value; intptr_t valuelen; struct generic_struct *next; }; [17:49:09] * Kovensky runs [17:50:47] <Kovensky> mru: that'd be easy to make in perl + yaml [17:52:00] <mru> oh, there's some lovely perl code in there [17:52:21] <Kovensky> <3 [17:52:24] <mru> /event\s+(\w+)\s*((\w+%([IiUufcsp](\[(.*?)\])?)\s*)*)/ [17:52:40] <mru> ^^ there's a sample [17:53:14] * mru tries to remember wtf that does [17:53:38] <mru> not the regex, but the text it matches [17:53:54] <Kovensky> \w+\s*\w+ is not really deterministic ._. [17:54:03] <Kovensky> well, it may be, but it's weird anyway [17:54:18] <mru> + and * are greedy [17:54:39] <Kovensky> so "aaaaaaaa" would be grouped as "aaaaaaa" and "a"? [17:54:51] <mru> probably [17:54:57] <mru> and that's probably a bug in the code [17:55:01] <mru> not that it ever mattered [17:55:49] <Kovensky> I think both those \s* are wrong, but if it worked, it worked [17:56:00] <mru> in fact, I'm running code generated by it right now [17:56:20] <mru> there's only one \s* [17:56:23] <mru> the other one is + [17:56:36] <Kovensky> no, there's a \s* near the end [17:56:41] <mru> right [17:56:49] <BastyCDGS> hoyos asked me if there's an OK from a maintainer for applying the heavy optimize patch for decodeplane8... [17:57:16] <Kovensky> talking about optimize, my audio stuff sure puts a lot of heap pressure... [17:57:18] * peloverde thinks he's going to have to completely replace the AAC channel configuration scheme [17:57:50] * peloverde facepalm [17:58:06] * Kovensky pats pentanol [17:58:08] <Kovensky> durf [17:58:10] <Kovensky> peloverde* [17:58:14] * Kovensky slaps irssi [18:08:36] * twnqx slaps Kovensky [18:12:02] <BBB> http://webcvs.freedesktop.org/gstreamer/gst-plugins/gst/asfdemux/asfheaders… [18:12:05] <BBB> there we go :) [18:12:07] <BBB> that was the commit [18:12:38] * BBB awaits mru to flame him [18:13:01] <BastyCDGS> hey could someone add me to the list of assignable to bug in roundup.ffmpeg.org? [18:13:07] <BastyCDGS> want to assign me to the IFF stuff [18:13:34] <kierank> oh lawd cvs [18:15:07] <BBB> http://webcvs.freedesktop.org/gstreamer/gst-plugins/gst/asfdemux/gstasfdemu… <- line 975 actually uses it for I/O [18:24:33] <jai> BastyCDGS: just attach your patches to the report [18:24:57] <BastyCDGS> also the ones which are already on git now? [18:25:36] <jai> i meant any patches which fix said issues [18:30:49] <BastyCDGS> https://roundup.ffmpeg.org/issue1727 [18:41:28] <BastyCDGS> I also was able to reproduce https://roundup.ffmpeg.org/issue1895 [18:41:28] <BastyCDGS> on x86_64 and x86_32 [18:41:51] <BastyCDGS> so I tagged this from new to open/reproduced [18:54:39] <peloverde> Implicit PS works, it's hideous but it works [18:55:01] <_av500_> and it switches from mono to stereo? [18:56:17] <peloverde> If there is SBR it always decodes mono as stereo [18:56:34] <_av500_> ok [18:56:35] <_av500_> ok/win 10 [18:57:27] <JEEBsv> hmm, not sure if this is the right place to ask, but are there any spec pdfs for mpeg transport streams? [18:57:41] <_av500_> the specs [18:57:52] <janneg> 13138-1 [18:58:39] <JEEBsv> thanks, will see if I can find that one on the 'webs :3 [18:59:20] <janneg> err 13818-1 [18:59:46] <JEEBsv> yeah, that first one got me some swimming aids ^^; [18:59:57] <_av500_> it is a kind of transport [19:00:06] <_av500_> in streams [19:00:55] <JEEBsv> I kind of thought about reading on it, since it's currently the one format where quite many apps stumble [19:01:12] <mru> it's a good read [19:01:18] <_av500_> ? [19:01:24] <mru> 13818-1 [19:01:31] <BastyCDGS> guys I did mark this one https://roundup.ffmpeg.org/issue1427 as duplicate [19:01:34] <BastyCDGS> and closed it [19:01:35] <_av500_> damn, i lag like hell [19:03:56] <janneg> JEEBsv: which apps? reading or writing? [19:06:06] <JEEBsv> janneg: well, let's just say "many" for frame-exact seeking etc. I'm not sure if ffmpeg itself is bad at it, but ffms2 and mplayer do fail gorgeously with ts files from time to time. I'm just interested to learn about the spec myself, so that I migh some day help people write better software. As for writing, I know that kierank is making a muxer at least. [19:06:59] <mru> frame-exact seeking in ts is impossible w/o pre-parsing the file or on the fly index building [19:07:22] <_av500_> or a lot of seek() ops [19:08:06] <BastyCDGS> stupid_seek() => takes one random offset in the file and trys to decode if wrong frame choose another random offset and do the same until...:D [19:08:29] <JEEBsv> mru: yeah, I know that :) [19:08:54] <BastyCDGS> will deliver a patch now *gg* [19:08:57] <mru> that's called monkeyseek [19:09:07] <mru> there's also monkeysort [19:09:14] <BastyCDGS> stupidsort yes ;) [19:09:22] <BastyCDGS> that's what I was thinking off ;) [19:12:12] * JEEBsv kills some trees with 13818-1 [19:15:04] <mru> hmm, ps reports ffmpeg using 102% cpu on a single-core system [19:15:13] <mru> rock on, ffmpeg! [19:15:38] <JEEBsv> now to get ARIB stuff for on the Japanese transport stream stuff too >_> [19:16:10] <BastyCDGS> so you applied my monkeyseek patch? :D [19:17:24] * elenril wonders what is up with seeking in flac [19:17:41] * _av500_ seeks in flac happily [19:17:49] <elenril> not with lavf [19:17:55] <BastyCDGS> btw, does ffmpeg support flac's > 4GB? [19:17:58] <mru> if you need to seek, the film/song isn't good enough [19:18:06] <BastyCDGS> or at least > 2GB? [19:18:12] <jai> elenril: is there a bugreport? [19:18:31] <elenril> dunno, Justin said it was on his todo list [19:18:31] <BastyCDGS> mru, depends I have flac files in 24bit/96kHz which are over 7h [19:18:38] <BastyCDGS> it's a DJ remix I did some years ago [19:19:12] <BastyCDGS> btw I meant encoding flacs > 2/4 GB [19:19:26] <mru> why would you have such a file? [19:19:27] <BastyCDGS> with the normal cmd line tool I was only able to do this via raw pipe [19:19:30] <mru> why not split it? [19:20:17] <BastyCDGS> because it should also be shared as one file and should be considered as one track [19:20:22] <jai> elenril: do you have a sample? [19:20:31] <elenril> jai: of what? [19:20:46] <jai> elenril: flac where seeking breaks [19:20:50] <elenril> all of them [19:21:03] <elenril> seekin is just not implemented [19:21:09] <BastyCDGS> -rw-r----- 1 basty users 2963173677 2005-12-07 10:32 DJ Sets - Basty - Flower Of Life @ Home (XXL MerKaBah RMX).flac [19:21:11] <mru> if it really should be considered one track, you should obviously listen to it from beginning to end [19:21:16] <mru> otherwise it's not a single track [19:21:45] <BastyCDGS> I usually do ;) [19:21:49] <jai> elenril: uh, yeah, sorry [19:21:50] <ohsix> thats usually what you patronize a dj for [19:21:57] <BastyCDGS> but sometimes I also want to listen to parts of it (highlights etc.) [19:22:28] <jai> elenril: i should've realized this was about raw flac [19:22:30] <jai> hmm [19:22:36] <_av500_> elenril: i just seek by bitrate and file size [19:22:42] <_av500_> nobody ever complained [19:22:51] <_av500_> but that is not pc in ffmpeg i think [19:23:06] <elenril> _av500_: send patches! [19:23:21] <_av500_> hmm [19:23:46] <_av500_> need to port my stuff to lavf [19:24:21] <BastyCDGS> I would also be glad on some infos for seeking (what ways are supposed to be to do this in ffmpeg etc.) [19:24:32] <BastyCDGS> I'll need this for mod de/encoder later and also for IFF-ANIM ;) [19:26:54] <BastyCDGS> btw, mod handling should be done in a way it either can decode to PCM or sth. alike that or to a ffmpeg mod structure which can then used by another mod encoder to convert the file [19:27:36] <jai> yes [19:28:52] <BastyCDGS> I suggest libavmodule as a name for ffmpeg mod structure ;) [19:30:08] <jai> :S [19:30:22] <Dark_Shikari> libavlibrary [19:30:29] <jai> i don't think it needs to be a separate lib [19:30:41] <Dark_Shikari> libavflame [19:30:46] <Dark_Shikari> produces mailing list flames for ffmpeg-devel [19:30:53] <BastyCDGS> lol [19:31:08] <ohsix> a bike shed that paints itself [19:31:14] <BastyCDGS> jai, but it probably would then maintain better [19:31:20] <jai> BastyCDGS: why? [19:31:23] <BastyCDGS> mod is really pretty different than usual sound/image stuff [19:31:44] <jai> maybe, but that alone isn't a good enough reason [19:31:46] <Dark_Shikari> ohsix: libavbikeshed [19:32:01] <BastyCDGS> I mean it also for the tracker stuff itself, i.e. convert from mod to mod, mod to PCM will of course be as normal as it is avformat/avcodec [19:32:27] <jai> also, you should dump all your design notes/whatever on the ML sooner rather than later, michael will surley have some comments [19:33:03] <jai> *surely [19:33:42] <BastyCDGS> maybe it's very good possible without a new libavmodule or sth. like that [19:33:54] <jai> i'd suggest that [19:34:04] <jai> of course, not my call :) [19:34:26] <elenril> so where's libavcc [19:34:52] <ohsix> libavdrcorcdspcc [19:35:07] <mru> isn't a mod file just a bunch of samples and instructions on how to combine them? [19:35:17] <jai> yes [19:35:25] <BastyCDGS> the very original mod format from amiga was ;) [19:35:39] <jai> even the later ones i'd say [19:35:47] <BastyCDGS> but newer trackers have complete synth sound handling stuff (like OPL2/3) [19:35:47] <jai> they just got more "exotic" [19:35:50] <_av500_> libavjustabunchofsamples [19:36:26] <mru> should still fit nicely into the audio decoder api [19:36:46] <mru> encoded data in, pcm samples out [19:37:02] <BastyCDGS> that's the one part, but I want it also to convert from mod to mod [19:37:10] <BastyCDGS> e.g. xm to it or vice versa [19:37:38] <BastyCDGS> maybe even PCM to it (could just create a set of pattern/orderlist/samples with a tick interval when to play next PCM sample [19:37:43] <jai> libavformat/[mod|xm|s3m].c -> AVPattern [19:38:00] <jai> AVPattern -> renderer -> pcm samples [19:38:23] <jai> and muxers could work similarly from the internal representation [19:39:02] <jai> and extend this basic design for those "exotic" trackers you mention :) [19:39:39] <BastyCDGS> here you find some millions of mod for testing for later :) [19:39:39] <BastyCDGS> http://modarchive.org/ [19:39:58] <BastyCDGS> there are still some 20 mods added per day [19:40:18] <jai> i still have an old drive with my mod collection [19:41:18] <jai> that being said, i still wonder why we want to replicate libmodplug... [19:41:56] <BastyCDGS> modplug doesn't handle mods really well [19:42:07] <Compn> i've heard that only timidity handles mods [19:42:09] <jai> so fix it :) [19:42:10] <Compn> properly [19:42:23] <BastyCDGS> most players don't, still until today mods are only guaranteed to play 100% correctly with the original program creating it [19:42:43] <BastyCDGS> but I fixed these issues in TuComposer already... [19:43:06] <jai> yeah, fixing libmodplug seems like a better approach to me [19:43:19] <Compn> ffmpeg hates external libs tho :P [19:43:20] <BastyCDGS> I probably spent way over 1000+ hours just to figure out how they should really be played, adding workaround flags etc. [19:43:34] <jai> Compn: sure, but for fringe formats... [19:43:45] <Compn> especially for fringe formats [19:43:49] <Compn> e.g. bink :P [19:43:57] <Compn> kshishkov loves bink [19:44:02] <BastyCDGS> I won't fix modplug, I have gsoc'ed here for ffmpeg doing mod stuff ;) [19:44:09] <jai> yes, and that just means that we would be duplicating all that effort across multiple codebases [19:44:26] <jai> good reasoning ;) [19:44:28] <Compn> actually , i think there are more mods/midis than a lot of codecs ffmpeg has support for [19:44:35] <jai> anyway, not my call [19:44:35] <BastyCDGS> not really, just integrate TuComposer and 99,9% of the work is already done [19:44:36] <jai> so meh [19:44:58] <BastyCDGS> this will basically change TuComposer to apply ffmpeg's style guide [19:45:06] <BastyCDGS> change names of functions and data structures mostly [19:45:24] <BastyCDGS> also some very rare amiga only stuff has to be replaced (but it's not really much) [19:49:48] <BastyCDGS> that's also why I'ld prefer sth. like libavmodule, it would have the same approach as TuComposer itself (it's a lib, too.) [19:50:39] <wbs> remember that ffmpeg and libav* isn't a dumping ground for various third party code, to be accepted, it should be properly adapted [19:53:08] <BBB> isn't modplug also c++? [19:53:09] <jai> i reiterate, i dont see the need for a separate lib [19:53:22] <jai> all this can be cleanly rolled into the current framework [19:53:22] <BBB> and yes of course it shouldn't be a separate lib [19:53:32] <BBB> did I mention I threw up when librtmp support was added to avf? [19:53:45] <jai> BBB: lol [19:54:02] <jai> BBB: yes the code is c++ [19:54:23] <jai> BBB: also, hi :) [19:55:09] <BastyCDGS> well an libavmodule library would have the benefit that it can easily be enabled/disabled with configure --disalbe-avmodule or sth. like that [19:55:37] <BastyCDGS> also don't underestimate that, it will become pretty big for proper support for all formats [19:55:49] <BastyCDGS> expect some 400k of stripped O3 binary code [19:56:15] <wbs> individual decoders/encoders already can be disabled/enabled through configure [19:56:17] <jai> BastyCDGS: that could be achieved without a separate lib [19:56:27] <saste> hi all [19:56:48] <BastyCDGS> btw, I did a test build of TuComposer using DJGPP some years ago which resulted even in 900k (twice the double than m68k amiga) and I replaced all amigaos calls with stubs [19:56:53] <BBB> yeah the separate lib idea is silly [19:56:53] <BastyCDGS> hey saste, how are u? [19:57:03] <saste> is there some technical reason for which a libavmodule would be better than a libplugmod extension? [19:57:06] <BBB> good decoders should be in lavc [19:57:15] <jai> saste: libmodplug? [19:57:22] <BastyCDGS> modplug isn't good at module decoding [19:57:26] <BBB> and again, I want to throw up when seeing ext libs being developed [19:57:29] <BBB> because THEY WILL DIE [19:57:29] <BastyCDGS> it fails esp. with it [19:57:38] <BBB> and then we have to reimplement them in lavf/c anyway [19:57:43] <BBB> better do it right from the start [19:57:52] <BBB> point in case: libmms [19:57:58] <BBB> still makes me throw up nowadays [19:58:13] <BBB> and I feel bad for the SoC student that has to reimplement something that we already did ages ago [19:58:17] <saste> well in the case of librtmp... internal support was not that good for various reasons [19:58:26] <BBB> all of these reasons could be fixed [19:58:36] <saste> also it depends on the activity/ support state of the library being "plugged" [19:58:40] <jai> yes [19:58:40] <BastyCDGS> well if we can do all this stuff what TuComposer can do without doing a new libav...why not? [19:58:41] <BBB> but the developer is lazy, incompetent, uneducated and thinks he's smarter than "us" [19:58:46] <BBB> did I mention arrogant? [19:58:51] <jai> and libmodplug _is_ maintained last i checked [19:59:02] <jai> if it has bugs, those should be fixed upstream [20:00:15] <saste> yes the problem is that we don't want to duplicate effort when possible... but this has to be checked case by case [20:00:23] <jai> of course [20:01:24] <BastyCDGS> also libmodplug is decoding only [20:01:28] <BastyCDGS> i want to both [20:01:37] <BastyCDGS> to have both in ffmpeg [20:01:40] <saste> of course [20:01:40] <BastyCDGS> encoding/decoding [20:01:55] <BastyCDGS> and it's really a bad library, even worse if it's in C++ [20:02:14] <BBB> well look regardless of whether you do modplug or tucomp or something else [20:02:19] <BBB> I think it shouldn't be a separate lib [20:02:26] <BBB> it should be in ffmpeg, and can be done rightly so [20:02:38] <BBB> a lot of functionality can always be shared with other subsystems in lavf [20:02:51] <BBB> just think about the amount of code wasted on efficient byte I/O [20:03:20] <ramiro> BBB: you have to agree that it can be rather annoying to get something integrated into FFmpeg. [20:03:49] <BastyCDGS> BBB, I just want to do this anyway, share as much as possible with ffmpeg code [20:03:50] <jai> BastyCDGS: the api is C [20:05:56] <BastyCDGS> yes placed in a bunches of extern "C" stuff which is then internally converted to class stuff [20:06:15] <BastyCDGS> all wasting time, and all the issues with C++ itself [20:06:20] <jai> to a person writing a wrapper, that shouldnt make any difference [20:06:47] <BastyCDGS> yes but it still doesn't solve the internal issues like GetFoo!Qkuao18 not found. terminating! [20:06:53] <jai> ? [20:06:57] <jai> i dont follow [20:07:02] <BastyCDGS> just because two different compilers use the same object file [20:07:10] <BastyCDGS> name mangling of C++ functions [20:07:26] <wbs> that doesn't matter as long as all the c++ is inside of the library and just expose C functions as external interface [20:07:32] <jai> how does that matter at all? [20:07:41] <wbs> as long as you don't try to compile half of their library with one compiler and half of it with another one [20:07:51] <wbs> doesn't matter the least for users of the library [20:08:27] <BastyCDGS> wbs, I'ld be glad if you were right, but even the user sees this...had this often enough with C++ stuff [20:08:40] <BastyCDGS> sometimes it's just enough to add a new repository where the new program version is x.y.z+3 [20:09:36] <wbs> and if the external interface is pure C, in which way would that be possible? [20:09:41] <BastyCDGS> with linux shared libs usually go to in /usr/lib [20:09:41] <BastyCDGS> if they're C++ and you use a new G++ your app will break [20:10:25] <wbs> what part of "the external interface is pure C" don't you undestand? [20:10:52] <BastyCDGS> I'm not talking about the external interface [20:11:27] <BastyCDGS> I'm talking about general problems with C++ libs [20:11:54] <wbs> yes, but that's a problem that doesn't exist in the case we were discussing [20:12:42] <ramiro> btw what's up with all those iff optimizations? is it this codec?: http://wiki.multimedia.cx/index.php?title=IFF [20:12:50] <BastyCDGS> besides this, libmikmod is forked multiple times already [20:12:52] <jai> yep [20:13:04] <BastyCDGS> because mikmod and modplug are such bad [20:13:11] <ramiro> is it still used that much? [20:13:21] <jai> i prefer the libmodplug api, the libmikmod api sucks [20:13:25] <BastyCDGS> schismtracker uses a totally patched again of libmikit (which is a fork of libmikmod) [20:13:29] <jai> ramiro: not really [20:14:23] <jai> don't get me wrong, i'm all for a unified native module playback engine within ffmpeg, i just want you to factor in the maintenance costs involved here [20:14:39] <BastyCDGS> and even still, schism plays IT modules very non-conforming [20:14:53] <BastyCDGS> that's the reason I still prefer original IT from 1998 in dosbox [20:15:11] <jai> not to mention convincing application devs to move over to the new zomg-awsome implementation [20:15:56] <BastyCDGS> jai, I have almost all ready which we need for it ;) [20:16:08] <BastyCDGS> we don't have to rewrite a mod engine from scratch [20:16:27] <BastyCDGS> I already done it all the last 12 years ;) [20:16:48] <BastyCDGS> we just have to adjust TuComposer to be flawlessly integrate in ffmpeg but that's not really very much [20:16:59] <jai> good :) [20:17:31] <BastyCDGS> it's mainly stuff like ULONG => uint32_t, UWORD => uint16_t etc. [20:17:52] <jai> ugh, why use those types to begin with [20:17:53] <BastyCDGS> and make TuComposer's public functions like tcmAllocModule sth. like ff_mod_alloc or sth. like that [20:17:59] <jai> mikmod used those all over the place too [20:18:02] <BastyCDGS> amiga native types ;) [20:18:17] <jai> k [20:18:24] <BastyCDGS> declared in <exec/types.h> [20:18:43] <BastyCDGS> short question [20:18:46] <jai> the closest thing to an amiga i have is a copy of winuae ;) [20:18:57] <BastyCDGS> ffmpeg has support for threading semaphores etc. already very good we'll need this [20:19:13] <BastyCDGS> have we support for platform independent dlopen, too? [20:19:42] <BastyCDGS> platform audio device in/output is already present... [20:20:48] <BastyCDGS> ffmpeg also has be/le stuff bitstream reading very good [20:20:48] <jai> there's a dlfcn-win32 or sth [20:20:52] <jai> ramiro should know [20:20:57] <jai> but that would be a dependency [20:21:12] <BastyCDGS> so the platform dependent stuff currently existing in TuComposer can easily be transferred to ffmpeg too [20:21:54] <ramiro> we'd need this discussion on ffmpeg-devel [20:22:09] <ramiro> I'm not sure everyone wants shared loadable modules. we just did the opposite with libavfilter. [20:22:17] <ramiro> vhooks were loadable, lavfilter isn't [20:22:40] <BastyCDGS> well TuComposer uses these for mod/s3m/xm/it support, internally it just handles IFF-TCM1 [20:22:41] <jai> i'm not sure about the usecase BastyCDGS intended, just saying... [20:23:01] <jai> it uses dlopen? [20:23:11] <ramiro> wikipedia doesn't know what TuComposer is, so neither do I. [20:23:13] <BastyCDGS> you can even copy a new plugable module format while it's running thanks to file system notification it will detect it and load [20:23:29] <jai> BastyCDGS: i dont think we need that flexibility [20:23:51] <jai> statically compiled route is better [20:24:22] <BastyCDGS> ramiro: http://forum.cdgs-crew.com/viewforum.php?f=11 [20:24:36] <BastyCDGS> that would be even easier, jai ;) [20:26:32] <BastyCDGS> this public function API would be required in ffmpeg [20:26:32] <BastyCDGS> http://forum.cdgs-crew.com/viewtopic.php?t=13 [20:26:52] <BastyCDGS> some of them are redundant now (since already present in ffmpeg) [20:27:52] <kierank> Will changing number of streams on the fly work properly using the libavcodec api? [20:29:10] <BastyCDGS> also read the IFF-TCM specs for becoming an idea what a module must have for data structures: [20:29:10] <BastyCDGS> http://forum.cdgs-crew.com/viewtopic.php?t=7 [21:03:36] <CIA-7> ffmpeg: conrad * r23025 /trunk/libavcodec/libschroedingerenc.c: schroenc: Don't touch gop_structure by default, it should be left adaptive [21:03:37] <CIA-7> ffmpeg: conrad * r23026 /trunk/libavcodec/libschroedingerenc.c: schroenc: Use constant quality for constant quality, not noise threshold [21:03:37] <CIA-7> ffmpeg: conrad * r23027 /trunk/libavcodec/libschroedingerenc.c: schroenc: Set keyframe interval [21:03:38] <CIA-7> ffmpeg: conrad * r23028 /trunk/libavcodec/libschroedingerenc.c: schroenc: Set open-gop [21:04:15] <Dark_Shikari> \o/ [21:04:40] <saintd3v> schro, eek [21:05:08] <Dark_Shikari> so now all I have to do to get sane defaults is -coder 1, Yuvi ? [21:05:27] <Yuvi> nope, just set the gop to something other than 12 [21:05:36] <Dark_Shikari> And that, yeah [21:05:39] <Yuvi> -coder 0 only has any effect on -g 0 [21:05:41] <Dark_Shikari> Ah [21:05:50] <Dark_Shikari> there's no VLC mode for non-lossless [21:05:51] <Dark_Shikari> ? [21:06:00] <Yuvi> no vlc for non-intra [21:06:06] <Dark_Shikari> ah [21:11:52] * mru curses nvidia [21:12:04] <Yuvi> the lack of neon? [21:12:14] <mru> the lack of sense [21:29:14] <BBB> ramiro: agreed [21:29:19] <BBB> ramiro: we all go through that though :) [21:37:15] <ramiro> well some people don't want to. they find it easier to keep their own projects [21:38:49] <CIA-7> ffmpeg: conrad * r23029 /trunk/libavcodec/libschroedingerenc.c: schroenc: Use AV_RB32 [21:38:50] <CIA-7> ffmpeg: conrad * r23030 /trunk/libavcodec/libschroedingerenc.c: schroenc: Set colorspace info [21:45:46] <CIA-7> ffmpeg: stefano * r23031 /trunk/libavutil/ (avutil.h error.c error.h): [21:45:46] <CIA-7> ffmpeg: Make av_strerror() return -1 even in the case when av_strerror_r() is [21:45:46] <CIA-7> ffmpeg: not defined. [21:45:46] <CIA-7> ffmpeg: This allows applications to check if av_strerror() cannot provide a [21:45:46] <CIA-7> ffmpeg: meaningful representation for the provided error code, without having [21:45:47] <CIA-7> ffmpeg: to actually check the filled string. [21:45:48] <CIA-7> ffmpeg: stefano * r23032 /trunk/cmdutils.c: [21:45:48] <CIA-7> ffmpeg: Make print_error() use strerror() in case av_strerror() fails. [21:45:49] <CIA-7> ffmpeg: Should provide a meaningful error message for systems which do not [21:45:49] <CIA-7> ffmpeg: support strerror_r(). [21:45:50] <CIA-7> ffmpeg: Fix roundup issue #1894. [21:45:50] <CIA-7> ffmpeg: stefano * r23033 /trunk/cmdutils.c: [21:45:51] <CIA-7> ffmpeg: Simplify print_error(), directly use av_strerror()/strerror() for [21:45:51] <CIA-7> ffmpeg: printing the error code associated to FF_NETERROR(EPROTONOSUPPORT). [21:45:52] <CIA-7> ffmpeg: stefano * r23034 /trunk/cmdutils.c: Reindent after the last commit. [22:01:22] <Dark_Shikari> woohooo [22:01:26] <Dark_Shikari> muxing of raw h264 -> mkv is broken in ffmpeg [22:01:32] <Dark_Shikari> wonder how long that's been true [22:02:53] <peloverde> is that really that much of a surprise? [22:03:02] <Dark_Shikari> furthermore, when it breaks, it makes files that crash haali's splitter's thumbnail generator [22:03:12] <Dark_Shikari> thus crashing windows explorer [22:03:48] <peloverde> haali shouldn't crash, and windows should run thumbnailers out of process [22:04:31] <Dark_Shikari> and my ass should defecate unicorns [22:05:16] <Dark_Shikari> yay, ffmpeg locks up when extracting an image from an mkv file [22:06:21] <Dark_Shikari> yup, ffmpeg locks up when attempting to decode dirac video files. [22:06:49] <Dark_Shikari> hmm, I guess I can get around it by sending it through y4m first [22:08:59] <Dark_Shikari> woohoo, it locks up when you ctrl-C it [22:09:05] <Dark_Shikari> (probably the same issue) [22:12:46] <BastyCDGS> so I'll goto bed now, wish you all a good night and wonderful dreams, see ya soon ;) [22:29:10] <Dark_Shikari> http://comparescreenshots.slicx.com/comparison/54356 [22:29:14] <Dark_Shikari> loooooooooooool [22:30:12] <_av500_> dirac is so much smoother [22:30:46] <mru> same bitrate? [22:31:22] <_av500_> dirac has a wavelength, no? [22:31:23] <Dark_Shikari> yes [22:31:28] <Dark_Shikari> actually x264 was a bit lower [22:31:38] <Dark_Shikari> I used constant quality in dirac (after yuvi fixed the ffmpeg interface to not be broken as fuck) [22:31:45] <Dark_Shikari> and then picked the same bitrate and 2-pass'd it in x264 [22:31:47] <Dark_Shikari> same gop size [22:31:51] <Dark_Shikari> otherwise, defaults [22:54:40] <Dark_Shikari> oh. and ffmpeg ignores theora's pixel offset [22:54:44] <Dark_Shikari> this is probably bad. [22:55:59] <Dark_Shikari> breaks non-mod16 decoding [23:03:58] <Dark_Shikari> mru: and http://mirror05.x264.nl/Dark/theora_parkjoy.png [23:05:45] <janneg> Dark_Shikari: you're cheating!!1!!eleven!!1one! the dirac picture is much smaller ;) [23:05:56] <janneg> compressed pngs? [23:06:07] <Dark_Shikari> yes [23:06:15] <Dark_Shikari> pngs? compressed? oh my, unheard of [23:06:34] <Dark_Shikari> (pngout'd) [23:06:54] <ramiro> pngcrush'd too? [23:06:57] <Dark_Shikari> pngout is better [23:08:00] <BBB> holy shit that dirac one looks like shit [23:08:17] <Dark_Shikari> then you haven't looked at the theora one yet [23:08:37] <BBB> comparable to the dirac one? [23:08:47] <BBB> mouseover is better to compare [23:08:49] <BBB> pretty :) [23:56:54] <bcoudurier> hi guys [23:56:56] <ramiro> Dark_Shikari: are you on ffmpeg-user? http://article.gmane.org/gmane.comp.video.ffmpeg.user/26343 [23:57:04] <Dark_Shikari> I don't read ffmpeg-user [23:57:32] <Dark_Shikari> but clearly he has no idea what he's doing [23:57:40] <Dark_Shikari> feel free to correct him [23:58:03] <Dark_Shikari> meh, I'll do that

1 0

IRC log for 2010-05-04
by irc＠mansr.com 05 May '10

05 May '10

[00:00:15] <mru> the file decodes in 16.2s [00:01:12] <mru> 13.2s with coreavc [00:01:20] <Dark_Shikari> well what matters is the peak per-frame time [00:01:23] <Dark_Shikari> it has to finish before the next frame comes [00:01:28] <mru> I can't easily measure that [00:01:31] <mru> just buffer more [00:01:41] <Dark_Shikari> we can't buffer at all [00:01:44] <mru> ouch [00:01:47] <Dark_Shikari> and so many slices ---> because one slice per packet [00:01:49] <Dark_Shikari> udp [00:01:58] <mru> the gaming thing? [00:02:00] <Dark_Shikari> yes [00:02:04] <Dark_Shikari> they want to do it on ipad. [00:02:10] <Dark_Shikari> they're getting 60ms per frame in high motion for full-res ipad [00:02:11] <saintdev> cool [00:02:26] <Dark_Shikari> Which means they either have to drop fps to 15fps or drop resolution to 640x480 [00:02:30] <Dark_Shikari> Either sucks [00:03:02] <Dark_Shikari> Note they could, if they wanted, disable cabac or deblocking [00:03:25] <Dark_Shikari> oh, mru, you think you could write an ARM version of deblock strength calculation? [00:03:28] <Dark_Shikari> currently it's only for mmx [00:03:31] <Dark_Shikari> They could probably pay. [00:04:16] <mru> how much would that gain? [00:04:59] <Dark_Shikari> A lot [00:05:09] <Dark_Shikari> more than any other single asm function by a full order of magnitude (of those left to write) [00:05:16] <Dark_Shikari> its the cornerstone of filter_mb_fast [00:05:19] <Dark_Shikari> I would guess >10% [00:05:38] <Dark_Shikari> you can easily check just by profiling and measuring the time spent in the C portion of deblocking code [00:05:39] <mru> what is the c function called? [00:05:44] <Dark_Shikari> There is none [00:06:04] <mru> the top function on that clip is ff_h264_decode_mb_cabac [00:06:07] <mru> 8% [00:06:29] <Dark_Shikari> h->h264dsp.h264_loop_filter_strength [00:06:40] <mru> and what's the C version of that called? [00:06:46] <Dark_Shikari> ff_h264_filter_mb vs ff_h264_filter_mb_fast [00:06:47] <mru> I'm staring at the oprofile output [00:06:51] <mru> but I don't see anything [00:06:54] <Dark_Shikari> the latter is a thin wrapper around loop_filter_strength [00:06:58] <Dark_Shikari> the former is very complex and messy. [00:07:04] <mru> ff_h264_filter_mb is 5.6% [00:07:10] <mru> so you won't gain more than that [00:07:18] <Dark_Shikari> oh wow, lower than I thought [00:07:24] <Dark_Shikari> michael must have improved it a lot [00:07:30] <Dark_Shikari> oh, it's because he does deblocking per-row now [00:07:33] <Dark_Shikari> thus getting rid of the icache misses [00:07:41] <Dark_Shikari> Either way, I would guess there would be a gain of about 4% then. [00:07:45] <Dark_Shikari> Which is pretty nice regardless. [00:07:48] <mru> sure [00:07:48] <Dark_Shikari> for a single function [00:07:56] <mru> I wasn't aware of this one [00:07:56] <Dark_Shikari> ok, so I'll up a cavlc one for you to bench [00:08:15] <Dark_Shikari> http://mirror05.x264.nl/Dark/test2.h264 [00:08:56] <Dark_Shikari> also, keep in mind we can also modify the spec (and the encoder/decoder) to make it faster if necessary. [00:09:18] <mru> that decodes in 14.4s [00:09:27] <Dark_Shikari> and coreavc? [00:09:41] <mru> 10.8 [00:10:27] <mru> ff_h264_filter_mb is 7.8% now [00:12:50] <Dark_Shikari> finally http://mirror05.x264.nl/Dark/test3.h264 [00:12:53] <Dark_Shikari> no cabac, no deblock [00:13:02] <Dark_Shikari> also, notable properties of these streams amenable to optimization: [00:13:07] <Dark_Shikari> 1) no sub16x16 inter partitions [00:13:09] <Dark_Shikari> 2) no b-frames [00:13:12] <Dark_Shikari> 3) Lots of skips [00:14:49] <mru> 14.3s [00:15:05] <mru> err, wrong file [00:15:23] <mru> 10.5 [00:15:45] <mru> 8.3 with coreavc [00:18:42] <mru> does anyone know what arm core the ipad uses? [00:19:16] <astrange> a8 + magic power saving circuitry [00:19:45] <mru> plain old A8? [00:19:52] <mru> same as the TI OMAP? [00:20:45] <astrange> yes i think so [00:20:50] <astrange> http://www.slashgear.com/samsung-1ghz-hummingbird-mobile-cpu-takes-on-snapd… it's pretty much the same as this [00:21:17] <mru> snapdragon is a v7 but not an a8 [00:21:31] <mru> oh, yet another one [00:21:35] <Dark_Shikari> do we know how it compares to the a8? [00:22:03] <mru> that says the samsung one is "based on the a8" [00:22:18] <mru> if that means it's an a8 with stuff around it or that it's a modified a8 is hard to tell [00:23:07] <mru> I don't think samsung is an architecture licencee though [00:23:14] <mru> which would mean it's a stock a8 from arm [00:23:39] <astrange> "cycle-accurate and Boolean equivalent to" sounds like it's the same [00:38:35] <Dark_Shikari> mru: do you think ffmpeg could benefit from arm cabac asm? [00:39:11] <mru> any asm is good [00:39:13] <Dark_Shikari> (keep in mind I can get money for all this stuff) [00:39:19] <Dark_Shikari> just wondering how much you think it would help [00:39:20] <astrange> yes [00:39:25] <Dark_Shikari> the arm equivalents of the current x86 cabac asm [00:39:29] <Dark_Shikari> i.e. sigmap decode and cabac get [00:39:41] <astrange> the c cabac code can be improved to generate better arm code though [00:39:59] <astrange> it should be split up for arches with and without conditional execution [00:40:10] <astrange> that's if you can get any compiler to reliably do it, anyway... [00:46:26] <pengvado> that's the crux, isn't it? there's nothing in the x86 cabac asm that couldn't in principle be generated by a compiler, but gcc doesn't like cmov. [00:46:35] <mru> and the sheevaplug psu dies again... [00:47:07] <mru> gcc often uses arm conditional execution [00:49:36] <astrange> i think gcc 4.3+ can generate something close, it knows the sbb trick [00:50:00] <astrange> the worst problem is that *state and cabac->bytestream are char* and alias the cabac struct [00:57:35] <Dark_Shikari> mru: so suppose you did a contract for "write arm asm for loop filter strength, cabac, and cabac sigmap" [00:57:40] <Dark_Shikari> how much would you quote that at? [01:01:04] <mru> there, sheeva back in action [01:01:06] <mru> with atx pcu [01:01:07] <mru> psu [01:02:14] <mru> Dark_Shikari: I'd have to have a look at the C code first [01:04:03] <mru> what does h264dsp.h264_loop_filter_strength do? [01:04:14] <mru> don't tell me to read the mmx code [01:05:01] <Dark_Shikari> it calculates loop filter strength values based on mvd, nnz, and ref values [01:05:08] <Dark_Shikari> you know the algorithm [01:05:14] <mru> no, I don't [01:05:23] <Dark_Shikari> if there's nnz on either side of a 4x4 block boundary, set strength for each side to 2 [01:05:40] <Dark_Shikari> else, if there's an mv difference >= 1 pixel or different ref frame, set to 1 [01:05:43] <Dark_Shikari> else, set to 0 [01:05:52] <Dark_Shikari> (and inside an intra block, set to 3, edges of an intra block, set to 4) [01:05:56] <Dark_Shikari> but those are handled outside of the asm [01:06:13] <Dark_Shikari> so e.g. [01:06:13] <mru> is there any c code that does this? [01:06:20] <Dark_Shikari> 0 | 0 | 0 | NZ | 0 [01:06:32] <Dark_Shikari> would become [01:06:39] <Dark_Shikari> 0 0 2 2 [01:06:44] <Dark_Shikari> yes [01:06:49] <mru> where? [01:06:53] <Dark_Shikari> filter_mb_dir does this [01:07:51] <Dark_Shikari> You're better off parsing the mmx at the same time you read the C [01:07:56] <Dark_Shikari> because what the MMX does is very restrictive [01:08:02] <Dark_Shikari> i.e. it explicitly doesn't handle many corner cases [01:08:03] <mru> that's a hell of a lot of c code [01:08:03] <Dark_Shikari> like, say, MBAFF [01:08:08] <Dark_Shikari> MMX is much simpler [01:08:15] <mru> full of loops and conditions [01:08:26] <mru> mmx is never simple [01:08:35] <Dark_Shikari> sure it is [01:08:45] <Dark_Shikari> it has about a dozen different instructions in this function [01:09:04] <Dark_Shikari> it's a mix of mmx and c so it should be rather obvious what it's doing [01:09:36] <mru> I can't read that [01:09:49] <Dark_Shikari> stop being retarded [01:09:55] <mru> I don't know wtf the instructions do [01:09:57] <Dark_Shikari> it even has comments to reference appropriate C code [01:10:05] <mru> comments are always wrong [01:10:08] <Dark_Shikari> No, they're right [01:10:09] <Dark_Shikari> and stop being stupid [01:10:15] <Dark_Shikari> seriously, you're being intentionally thick here [01:10:16] <Dark_Shikari> stop it [01:10:30] <mru> will not [01:10:37] <Dark_Shikari> .... [01:10:58] <mru> look, it's bloody mmx code I don't know the first thing about [01:11:01] <Dark_Shikari> do you want me to walk you through it? [01:11:06] <mru> it's gcc inline asm ugly as sin [01:11:07] <Dark_Shikari> force-feed you the code? [01:11:11] <Dark_Shikari> you don't need to read the asm [01:11:19] <Dark_Shikari> you can figure out what it does without reading a line of asm [01:11:48] <mru> if it's that easy, why don't you write a pure c function doing the same thing? [01:11:56] <Dark_Shikari> because that would be slower than the existing c code [01:12:11] <mru> as illustration only [01:12:13] <Dark_Shikari> the optimal simd way is not the optimal C way [01:12:29] <Dark_Shikari> I'll guide you through it. I'm not the one who would be paid for this anyways [01:12:38] <mru> and the optimal mmx way is usually very different from the optimal neon way [01:12:46] <Dark_Shikari> no, they're pretty much the same [01:12:53] <Dark_Shikari> each bit of asm code does a _trivial_ operation [01:13:00] <Dark_Shikari> the only reason it's large is because there is more than one trivial operation [01:13:02] <mru> says the man who's never written any neon [01:13:11] <ramiro> stop biting each other [01:13:19] <mru> mmx does a lot of things very differently [01:13:25] <Dark_Shikari> mru: you'd do each code segment differently sure [01:13:28] <Dark_Shikari> but you still have to _do_ the same things [01:13:39] <Dark_Shikari> you still have to compare ref values [01:13:41] <Dark_Shikari> you still have to compare mvs [01:13:47] <mru> whenever you'd use pshuf in mmx you'd do something else in neon [01:13:50] <Dark_Shikari> of course [01:13:54] <Dark_Shikari> I told you not to read the asm [01:13:58] <Dark_Shikari> did you listen? nooooooo [01:14:15] <mru> HOW THE FUCK AM I SUPPOSED TO KNOW WHAT THE CODE DOES THEN? [01:14:16] <mru> GUESS? [01:14:21] <Dark_Shikari> I offered to guide you through it [01:14:22] <Dark_Shikari> and you refused [01:14:28] <mru> I don't have time for that crap [01:14:30] <saintd3v> children, don't make me pull thich channel over! [01:14:35] <saintd3v> *this [01:14:36] <Dark_Shikari> You have time to yell at me for 10 minutes [01:14:42] <Dark_Shikari> And you don't have time to listen to a 2 minute walkthrough? [01:14:48] <Dark_Shikari> OK, I'll ignore you and do it anyways [01:14:49] <Dark_Shikari> shut up. [01:15:07] <Dark_Shikari> 1) Iterate over the two directions (horizontal and vertical) [01:15:13] <mru> it's the middle of the fucking night, I'm tired, and I'm trying to finish up something else [01:15:15] <Dark_Shikari> obviously, for one of them, we have to do some transposes to get what we want. [01:15:47] <Dark_Shikari> 2) apply the MV mask, based on partition type, so we only have to check the MVs that could be different. [01:15:51] <Dark_Shikari> This is optional, and simply a time-saving step. [01:16:16] <Dark_Shikari> 3) Check the reference frames [01:16:25] <Dark_Shikari> 4) Check the MV deltas across the edges [01:16:35] <Dark_Shikari> 5) Do 2-4 for both list0 and list1 [01:16:38] <Dark_Shikari> 6) do nnz [01:16:56] <Dark_Shikari> the big block of asm in the middle of the loop is 3-4 [01:17:11] <Dark_Shikari> the way it works is as follows: [01:17:31] <Dark_Shikari> we have 4 edges in our macroblock we need to filter, each 16 pixels (4 4x4 blocks) long [01:17:45] <Dark_Shikari> The edge mask tells us that we only have to filter some of these. Say, only 2, for example. [01:17:52] <Dark_Shikari> For each one we have to filter, we compare the MVs and refs on either side of it. [01:17:56] <Dark_Shikari> this is done in SIMD. [01:18:10] <Dark_Shikari> Doing the refs in simd isn't very useful, it's primarily doing the MVs that helps here. [01:18:44] <Dark_Shikari> So at some given edge, for example, in a generic asm language: [01:19:05] <Dark_Shikari> r0 = int16_t top_of_edge_mvs[4][2] [01:19:11] <Dark_Shikari> r1 = int16_t bottom_of_edge_mvs[4][2] [01:19:51] <Dark_Shikari> for each element of r0/r1, if( abs(r0[i] - r1[i]) > 4 ) r2[i]=1 else r2[i]=0 [01:20:01] <Dark_Shikari> That's the MV algorithm. [01:20:27] <Dark_Shikari> It works similarly for NZ, where it's if( r0[i] | r1[i] ) r2[i]=2 else r2[i] = 0 [01:20:53] <Dark_Shikari> and for ref, if( r0[i] != r1[i] ) r2[i] = 1 else r2[i] = 0 [01:21:07] <Dark_Shikari> Then the greatest of all three values is selected from the outputs of each of the three processes. [01:21:10] <Dark_Shikari> Done. [01:21:32] <Dark_Shikari> See, it's not that bad. [01:21:42] <Dark_Shikari> It's easily 10x less work than, say, hpel. [01:24:12] <Dark_Shikari> if you don't like the ffmpeg c code, mru, here's the x264 C code [01:24:13] <Dark_Shikari> http://pastebin.org/200078 [01:24:21] <Dark_Shikari> Not as optimized, but same thing (and simpler, no mbaff corner cases) [01:24:42] <Dark_Shikari> 1) check nz on each side of boundary, 2) check ref on each side of boundary, 3) check mv on each side of boundary [03:32:29] <KotH> salut [06:20:28] <elenril> 'We are moving the rendering of the window decorations into the app itself, so that you donât have the window manager and application drawing those pieces separately.' [06:20:36] * elenril wonders wtf are the ubuntu people smoking [06:21:24] <KotH> sauce? [06:21:30] <elenril> http://www.markshuttleworth.com/archives/333 [06:21:31] <KotH> moin btw [06:21:38] <elenril> o/ BofH-san [06:22:06] <superdump> morning [06:23:18] <KotH> elenril: well.. as i said various times in the past: the gnome, freedesktop and other people in that area have never understood and never bothered to understand what X11 is and how it works [06:24:30] <ohsix> like they cant dare put an icon in a window property and have the window manager use it, gasp! (thats what the wm already does for the app icon, olol) [06:24:47] <bilboed> KotH, erm, please, could you stop insulting the gnome/fdo people by confusing them with the canonical/spaceman community, thx. [06:25:02] <ohsix> yes, they're the people doing real work [06:27:57] <ohsix> i'm waiting for the time they rip off osx's pages for app modal dialogues :D [06:29:03] <KotH> bilboed: sorry that i put those people into the same pot [06:29:26] <KotH> bilboed: but i've talked with enough gnome and freedesktop people and came to the conclusion that they understand x11 much less than i do... [06:29:34] <KotH> bilboed: and i know hardly anything about it [06:29:56] <ohsix> then what do you draw upon to judge that they have no understanding of concepts you aren't familiar with yourself [06:30:10] <bilboed> eh :) [06:30:29] <KotH> ohsix: oh.. quite simple.. if they dont even understand what i know, then it's bad, very bad ;) [06:30:57] <ohsix> heh, i cant think of a limited scope where that'd hold [06:32:08] <bilboed> anyway, don't make it a generality. Don't forget X is part of fdo, so pretty sure the people who would know the most *are* part of fdo (but seriously doubt they're part of canonical/ubuntu) [06:33:44] <KotH> from my experience, xorg seems to be a seperate entity within fdo, with not much contact to other groups [06:33:55] <KotH> but that might be my limited view of that field [06:34:41] <ohsix> canonical/ubuntu pretty much stay out of the picture aside from their own design/integration projects for new releases [06:35:18] <bilboed> KotH, somewhat true, which is a shame [06:36:03] <KotH> does anyone have a good idea how i can get rid of "warning: cast increases required alignment of target type" if the variable (an uint8 array) is casted to an uint32 pointer and already alligned to 8 bytes? [06:36:18] <KotH> bilboed: juup [06:36:33] <Dark_Shikari> hmm, since when does gcc warn about that? [06:36:34] <bilboed> ohsix, nono, they just stay out of the picture, except for the one month before freeze when they sound the alarm at the Canonical bunker going "fuck fuck fuck, we need to get in touch with upstream to figure out wtf's been going on" [06:36:50] <KotH> bilboed: i have a very high regard for xorg people... i cant imagine how much time they must invest in building and maintaining that huge infrastructure that xorg is [06:37:09] <ohsix> bilboed: o ic, i haven't seen any of that, which projects have they done that to? did they offer money for their trouble? [06:37:09] <Dark_Shikari> KotH: well it is rather amazing [06:37:20] <Dark_Shikari> xorg is a steamping pile of shit, and yet they are so good that they've made the steaming pile of shit work incredibly well [06:37:34] <ohsix> KotH: they do a pretty good job at rewriting huge pieces of it every few years, and removing stuff [06:37:47] <bilboed> ohsix, that is at least for all the projects that aren't hosted on "THE LAUNCHPAD" (insert dramatic 1940's black and white sound effect) [06:37:48] <ohsix> its a lot of little steaming piles now; almost all optional [06:40:30] <ohsix> bilboed: oic; then i guess i'll never see until someone shows me something :D [06:42:25] <bilboed> launchpad just duplicates the amount of bug triaging/maintaining/... for any project. Imagine for one second having to handle ffmpeg bug reports/requests/code-hosting on lp in addition to what you already have... it's just the fastpath to failure [06:42:46] <ohsix> oh, right [06:42:58] <KotH> Dark_Shikari: i dont know how the internals look like. i only know how the mga driver looks like, but that is one very old and hardly maintained driver anyways [06:43:02] <ohsix> so you're talking about the stampede from launchpad at the moment that they go from not care to do care [06:43:08] <bilboed> ohsix, yah [06:43:28] <bilboed> ohsix, and then them requesting releases with all the bugs they want fixed for a given deadline [06:43:36] <ohsix> k yea i've seen half of that; launchpad is pretty dry, nobody does triage its more like first level phone support asking you to make sure your printer is plugged in [06:43:43] <bilboed> ohsix, to which your response is "I'm sorry, got other stuff to do, you're not our priority" [06:44:03] <ohsix> even distro metabugs are kind of meh [06:44:44] <bilboed> some distros actually do the triaging downstream, instead of ubuntu expecting upstream to come and triage stuff in lp [06:45:18] <bilboed> debian (and not ubuntu) is pretty good at that for ex. Same for gentoo. Fedora to a certain extent. Launchpad/ubuntu ? meh [06:45:36] <ohsix> yea [06:45:46] <bilboed> I'd say they're overwhelmed by their success [06:46:15] <ohsix> the very least they need less gladhanding and more aggressive bug closing if they aren't going to have people to triage and file upstream, or push people out to the right place to file upstream [06:46:31] <KotH> hmm..? what is launchpad exactly? it looks like a generic bugtracker site? [06:46:50] <ohsix> they don't really give extra priority to apport collected bugs or anything either; the real reason launchpad should exist [06:47:18] <ohsix> apport rules; but if user reports are ignored then its less than useless [06:50:50] <_av500_> bonjour mes enfants [06:55:08] <KotH> salut papa [07:41:17] <siretart> god morgon [07:41:21] <kshishkov> :) [07:41:23] <kshishkov> hej hej [07:41:47] <siretart> KotH: launchpad is technically a heap of zope applications that more or less collaborate with each other [07:42:13] <siretart> KotH: the bug tracker component is called 'malone', the archive and package build component 'soyuz' and so on [07:42:34] <kshishkov> what does "malone" mean? [07:42:43] <merbzt> boker tov [07:42:47] <ohsix> the same thing steve does [07:42:57] <KotH> siretart: and what's the goal of launchpad? [07:43:26] <siretart> kshishkov: no idea. but that name isn't promimently exposed. you see it in bugreports and the bzr repo is named like that [07:43:52] <kshishkov> at least "Soyuz" fits nicely on launchpad [07:43:54] <siretart> KotH: "to improve collaboration between projects" would be the buzzword-style answer [07:43:57] <kshishkov> or V2 [07:44:18] <siretart> KotH: launchpad tries to be not ubuntu-specific, although ubuntu is clearly the most important user of it [07:45:08] <siretart> KotH: these days, there are a number of non ubuntu, non distro upstream projects hosted on launchpad, that use bug managment, user support, translations managment and code hosting [07:45:13] <KotH> siretart: improve collaboration by providing a common bug tracker, mail archive,... etc pp? [07:46:24] <siretart> KotH: malone has the concept that every bug can have more than one 'bug task'. a 'task' is targeted at either a distro or at some upstream project. this way you can say 'this bug is confirmed in ubuntu, and fix released in upstream' [07:47:07] <siretart> this becomes interesting when an upstream bug task is linked to some upstream bugtracker. in that case, launchpad will poll the status of the bug from the remote bugtracker [07:48:04] <siretart> e.g. https://edge.launchpad.net/mplayer/+bugs are the bugs launchpad knows that affect 'mplayer' as upstream project. they may or may not also have a bugtask in the ubuntu distro [07:48:40] <siretart> same for https://edge.launchpad.net/ffmpeg/+bugs [07:55:37] <KotH> intersting concept [07:55:59] <KotH> and what are people complaining about launchpad? [07:56:26] <ohsix> its insulated from upstream except for the volition of people who do triage (which there aren't many, if any that i've seen) [07:56:49] <ohsix> so those people have to spend time doing triage out of launchpad which is hard cuz the bug quality is low and so is their classification [07:58:32] <KotH> but that's not a prob directly related to launchpad, but a genereal problem of bug trackers, or not? [08:00:24] <ohsix> any given bug tracker will have more narrow focus, like the redhat bugzilla has people and bug reporting directly linked to respective projects and people [08:02:16] <KotH> you mean the broad "focus" of launchpad is the cause of these low qual reports? [08:03:22] <ohsix> no, thats secondary [08:03:39] <KotH> what's primary then? [08:04:16] <ohsix> lack of people doing triage [08:04:39] <ohsix> you essentially have people doing form letters for bugs; to make sure the information is there, but the people that would use that information arent there [08:06:14] <ohsix> and thats the best case scenario; people sending form letters don't know much about what they're looking at [08:13:56] <ohsix> the way they do updates sidesteps a lot of bugs too, consequently there are is a lot of old, dead information on their wiki and in the bugs [08:14:46] <ohsix> anything targeting a milestone isn't really visible in the bug minutae; so you might have a bug thats already going to be solved or is solved at some release; but nobody has tended the bug or even classified it [08:16:47] <_av500_> siretart: i see you spend a lot of time in this launchpad [08:20:24] <siretart> KotH: I'd rather say that launchpad makes it too easy to report low-quality bugs. ubuntu developers do not manage to cope with this flood, so you almost always have to filter out the 'yet unseen' (read: untriaged) bugs [08:22:12] <ohsix> apports usefulness is marginized when there aren't people doing triage [08:38:43] <KotH> siretart: how can you make it more difficult to submit low quality reports while not making it more difficult to enter high quality reports? [08:39:54] <ohsix> you cant without people forcing bugs out [08:43:34] <KotH> so it boils down to have enough people weeding out bugreports? [08:43:36] <ohsix> what people do with retraces isn't very visible; they dont aggregate the automatic reports or anything, or link stuff with upstream, anyone can do that though; i've done it for some of my bugs, but they need staff that does just that [08:44:04] <ohsix> its all thrown in the same bin [08:59:27] <benoit-> moin [08:59:39] <kshishkov> guten morgen [09:01:13] <scaphilo> hallo [09:03:19] <KotH> echo [09:12:09] <siretart> KotH: one approach is to encourage users to not use the webinterface, but dedicated bug reporting tools. ubuntu e.g. offers the tool 'ubuntu-bug' that includes additional information about the system and the installed package. additionally, it calls hooks included in the respective package for additional, package specific information [09:12:33] <siretart> KotH: for the alsa package that is for instance the amount and settings of the mixers, etc. [09:14:03] <siretart> KotH: another bug reporting tool is 'apport', which attaches coredumps to bugs. these core dumps are then retraced in a special environment with debug symbols installed. the resulting backtrace is then hopefully understandable to developers [09:28:28] <_av500_> siretart: ffmpeg --bug-report? [09:29:54] <siretart> _av500_: sorry? what is that supposed to produce? [09:30:15] <_av500_> a good bug report of course :) [09:30:46] <_av500_> or at least a templete to paste into an emial [09:30:49] <siretart> _av500_: if there is anything that I can call or do in some apport package hook, tell me, I can include it in the package [09:31:04] <_av500_> it could give a templte for bug reports [09:31:17] <_av500_> like <enter bug descriptoin here> [09:31:28] <_av500_> liek <paste backtrack here > [09:32:19] <siretart> there is something like package specific instruction for bug reports, which serves a similar purpose like templates. but malone itself doesn't support real bug templates [09:32:56] <siretart> again, if there is information on the system that is potentially relevant for the bug and I can programatically extract it at the time the bug is filed, tell me, I'll include it [09:33:28] <siretart> requiring the user to read a template, think, do stuff and then proceed is not an option [09:33:35] <_av500_> :) [09:33:39] <siretart> well, it is an option in general, but not in launchpad [09:34:42] <_av500_> is there a way to detect we crashed (sig handler?) and at least spit out some lines that point users to what to do next? [09:35:49] <siretart> I think that should be possible. I remember that pitti added an API so that apport hook can interact with the user [09:36:32] <siretart> I haven't used it yet, it most often is used to ask the user if there is potentially something confidential in the report, but I think that can be extended to other purposes [09:37:48] <siretart> the ubuntu kernel has been modified to always call apport on every segfault. apport will then check if the segfault was in a binary that was shipped by an ubuntu package and if yes, call these apport hooks [09:38:41] <siretart> and I think that we can have some user interaction at this point. Given that the user has an graphical session open at all, that is. [10:20:50] <Honoome> lu_zero: may I prod bilboed-pi here or should I lure him somewhere more cozy? :P [10:22:44] <scaphilo> is there a way to simply ignore b frames in the input video, skip-bframes or something? [11:08:19] <scaphilo> well i found a way to simply remove them but its a hack... once again. But an other question: [11:08:33] <scaphilo> mb_type_l0 and mb_type_16x16 [11:08:53] <scaphilo> does that make sens when both of them are set for one macroblock? [11:09:16] <scaphilo> mb_type16x16 would be enough not? [11:10:13] <kshishkov> l0 means it has motion vector [11:10:24] <kshishkov> for backward reference frame IIRC [11:11:01] <kshishkov> 16x16 means something completely different [11:11:08] <scaphilo> ah i see [11:11:14] <scaphilo> i thought its line0 [11:11:17] <scaphilo> and line1 for [11:11:24] <scaphilo> mb_type_l1 [11:11:50] <scaphilo> thx for help [11:12:16] <scaphilo> ah your right line0 and line1 makes no sense [11:40:02] <ramiro> superdump: don't bother helping phil rhodes, he's just trolling [11:40:27] <superdump> what makes you say that? [11:40:38] <kshishkov> maybe he saw you helping him [11:40:53] <ramiro> superdump: he's a notorious troll on ffmpeg-user [11:40:58] <superdump> oh [11:41:27] <ramiro> he's the guy who wrote the dark shikari complaining mail [11:41:41] <ramiro> he's too dumb to google and wants every spoon-fed. [11:41:46] <superdump> ah, yes, i remember him [11:42:24] <ramiro> it's actually quite fun to troll back and see what he will reply =) [11:44:37] <kshishkov> "don't argue with a fool, you'll eventually get to his level and he'll beat you having more experience" [11:45:07] * mru points at Nietzsche [11:45:19] <mru> monsters, trolls, it's all the same [11:45:30] <_av500_> Nietzsche is on -user? [11:54:46] <KotH> why didnt anyone tell me of that Dark_Shikari complaint threat before? [11:59:09] <DonDiego> what's up with CIA-7 ? [12:01:42] * janneg kicks CIA-7 [12:01:44] <CIA-7> ow [12:05:56] <ramiro> KotH: having fun reading it? [12:06:10] <KotH> ramiro: juup [12:15:10] * Honoome today is hitting crazy stuff =_= [12:16:38] <KotH> Honoome: at least it isnt shit hitting the fan ;-) [12:17:32] <Honoome> KotH: but it's gstreamer hitting feng from one side :P [12:18:07] * Honoome wanted to update synergy-plus in GentooâŠ they moved to CMakeâŠ they now lack a dist targetâŠ they tarballed the .svn directories =_= [12:18:31] <DonDiego> given how broken the dist target implementation in automake is.. [12:18:47] <DonDiego> you have to manually remove .svn directories there, too.. [12:18:53] <mru> dist targets are useless [12:19:11] <mru> if exporting the files under version control isn't enough, something's broken [12:19:12] <Honoome> DonDiego: untrueâŠ you just have to list each file one-by-one :P [12:19:39] <Honoome> mru: *shrug* I'm fine with that as wellâŠ not so fine with downloading the whole shebang twice 'cause they don't know the --exclude '.svn' option [12:19:51] <mru> or svn export [12:20:00] <mru> which is in fact better [12:20:09] <mru> otherwise you can be sure to get a few *~ files along too [12:20:12] <Honoome> does svn export tar the stuff as well? [12:20:20] <mru> no [12:20:39] <Honoome> too bad, that would have been useful to suggest people ;) [12:20:59] <janneg> git archive does [12:21:18] <mru> if something seems useful, svn probably doesn't do it [12:22:01] <Honoome> mru: ah true [12:30:38] <mru> ugh, 43 different gcc builds installed again... [12:31:20] <kshishkov> wanna recompile gentoo with each of them? [12:31:37] <mru> mostly cross-compilers of course [12:37:41] <spaam> mru: why so many? [12:38:19] <_av500_> many cross platforms [12:41:47] <mru> and many gcc versions [12:42:35] <_av500_> how does gcc 2.9.5 run for A8 :) [12:43:04] <mru> probably not at all [12:43:21] <mru> nothing before 4.2 is worth looking at for arm [12:43:58] <_av500_> iirc we used 2.9.5 for the omap1 [12:44:44] <mru> and my ex-employer still uses armcc 1.2 [12:45:45] <Kovensky> <@mru> if something seems useful, svn probably doesn't do it <-- lol [12:51:03] <hyc> it always pissed me off that we couldn't build a single gcc frontend with multiple backends [12:51:27] <_av500_> patches welcome [12:51:35] <hyc> been there, done that, they were rejected [12:51:36] <mru> or vice versa [12:53:05] <hyc> (that was ... 15+ years ago) [12:53:50] <hyc> more like 19 years, that's when I wrote my Usenix paper on using big multiprocessor "supercomputers" as compile servers [12:54:29] <hyc> I used an Alliant FX/8 with a bunch of gcc installs, to compile code for Sparc, VAX, and a couple other systems we had [12:54:52] * mru looks at distcc [12:55:04] <mru> someone ought to fix that [12:56:59] <hyc> distcc is almost the opposite problem, instead of one machine with many compiler backemds, you want many machines with only one compiler [12:57:21] <mru> depends [12:57:35] <mru> I have one really fast machine and many slow ones [12:57:41] <hyc> but it all still ties together with parallel make, so there's a connection I guess [12:57:59] <mru> you want each machine to run as many compilers as it can manage [12:58:27] <hyc> true [12:58:46] <hyc> but you generally only care about one architecture at a time [12:58:55] <mru> says who? [12:59:30] <hyc> well, most project makefiles only build a package once. [12:59:43] <hyc> you can of course wrap anotehr build script around it to build multiple instances in parallel [12:59:57] <mru> I might be building stuff independently on many machines [13:00:45] <hyc> ok. so really you just want to be able to distribute as many cc's as possible regardless of arch or project [13:00:47] <mru> and then there are things like fate [13:01:00] <mru> I run 17 different compilers on each rev [13:01:40] <hyc> fate ... you have 17 different execution environments? [13:02:01] <hyc> or a lot of different compilers for the same platform? [13:02:05] <mru> 6 different targets, most of them with multiple compilers [13:03:44] <hyc> I need to get our cross-compile environment in shape here. currently we build for different platforms on their native hardware [13:04:00] <hyc> but our AIX machines are ancient RS6000s [13:04:02] <_av500_> we=? [13:04:16] <hyc> amy company, Symas Corp., and our products [13:04:21] <hyc> s/amy/my/ [13:04:37] <_av500_> i get get you another bunch of ancient rs6000s if you want :) [13:04:41] * mru glares at debian [13:04:47] <hyc> heck, our Sparc/solaris machines are ancient now too :P [13:05:14] <mru> who cares, Sun has turned brown dwarf [13:05:20] <hyc> _av500_: no thanks. when our company started, we picked up 4 RS6000s that Caltech was throwing away [13:05:20] <mru> didn't even go nova [13:05:39] <_av500_> hyc: mine would be uni machines too [13:05:41] <hyc> happily we have also discarded them by now. [13:06:10] * mru got alphas from uni [13:06:23] * _av500_ remembers smitty [13:06:24] <hyc> the new boxes are at least built within this decade :P but still way slower than cheap x86 machines [13:06:58] <_av500_> so why build for them? [13:07:03] <hyc> yeah, I guess sparc/solaris will become less relevant over time [13:07:11] <hyc> we still have customers on those platforms tho [13:07:24] <hyc> so we still need to provide updates/new releases for them [13:08:02] <hyc> compile would go much faster if we just cross-compiled on our x86 machines, but we still need to run the test suites on the actual boxes [13:10:29] <hyc> smitty was pretty cool. Kinda wish linux had something as good. [13:17:56] <_av500_> hyc: it has yast [13:17:59] * _av500_ hides [13:18:18] <hyc> :P [13:19:00] <hyc> I had a lifetime subscription to SuSE due to my work on Gnu stuff in the 1980s and 1990s [13:19:12] <hyc> but I finally stopped using it and switched to Ubuntu [13:19:47] <DonDiego> heh [13:19:54] <_av500_> i wonder when i will do that [13:20:02] <DonDiego> i often feel like the grandpa around here.. [13:20:09] <DonDiego> hyc: i wonder what it must be like for you.. [13:20:10] <DonDiego> :) [13:20:22] <_av500_> but coworkers wife is Mrs KDE, so i am biased [13:20:38] <hyc> don't go there. my birthday was last week, I don't need the reminder right now. ;) [13:21:02] <DonDiego> :) [13:21:16] <_av500_> DonDiego: compared to me you are a kid [13:21:29] <_av500_> im in semester 40 [13:21:40] * DonDiego is catching up.. [13:22:00] <_av500_> where are you now? [13:22:05] <DonDiego> home [13:22:06] <DonDiego> :) [13:22:21] <_av500_> in 2 years i will be 42 and ee engineer :) [13:22:33] <DonDiego> you intend to finish? [13:23:09] <_av500_> i am finished, was refering to badesalz (but that might be for hessian locals only) [13:23:36] <hyc> well, I'm 43 now :P 42 isn't bad really, especially if you liked Douglas Adams [13:23:37] <DonDiego> it did not ring a bell with me.. [13:23:40] <_av500_> of course the phd is permanently under construction [13:23:56] * DonDiego is 35 [13:23:58] <mru> you're doing a phd on geocities? [13:24:13] <hyc> lol [13:25:26] <kshishkov> mru: that's because a thesis in draconology is not welcome anymore [13:26:17] * BBB thinks kshishkov should do a PhD in sweden [13:27:16] <kshishkov> BBB: nej, tack [13:27:26] <BBB> "tack"? [13:27:36] <janneg> thanks [13:27:44] <kshishkov> "thanks" or "please" depending on context [13:28:40] <mru> or bitte/danke for you germans [13:29:20] <_av500_> thx mru [13:29:41] * mru doesn't know serbian [13:29:43] <thresh> 'Ð±Ð»Ð°Ð³ÐŸÐŽÐ°ÑÑ' in bulgarian, also [13:30:21] <kshishkov> Ð·Ð²ÑÑÐžÑ ÐºÐ°Ðº ÐŽÐµÐµÐ¿ÑÐžÑÐ°ÑÑÐžÐµ [13:30:40] <hyc> you guys are messing up my tty [13:30:55] <DonDiego> you're not on utf-8 yet? [13:31:02] <DonDiego> you really are an oldtimer ;) [13:31:08] <hyc> I am, but apparently missing some fonts :P [13:31:22] <Tjoppen> \u2603 [13:31:37] <Tjoppen> if only my tty also supported UTF-8 [13:31:40] <spaam> time to write ÃÃÃÃ¥Ã€Ã¶ ? ;) [13:31:53] <Tjoppen> räksmörgås? [13:31:58] <kshishkov> æ¥æ¬èªãã§ããŸãã [13:32:02] <thresh> kshishkov: i actually like Bulgarian, seems it is an 'older' version of Russian [13:32:04] <spaam> Tjoppen: ÃÃÃ does fuck it up more then Ã¥Ã€Ã¶ [13:32:26] <kshishkov> thresh: Church Slavic is Old Bulgarian, that's why [13:32:29] <spaam> TiAMO did have that problem before ;) [13:32:30] * elenril throws â at kshishkov [13:32:44] <kshishkov> elenril: too warm for snowmen [13:33:14] <elenril> true :( [13:33:33] <kshishkov> thresh: and new Bulgarian does not have cases. ÐÐµÑÐµÐ»ÐŸ Ð±ÑÐ»ÐŸ Ð² ÑÐºÐŸÐ»Ðµ ÑÐºÐ»ÐŸÐœÑÑÑ ÑÐžÑÐ»ÐžÑÐµÐ»ÑÐœÑÐµ ÐœÐµÐ±ÐŸÑÑ? [13:33:40] * elenril should buy some ice cream on his way from school [13:33:43] <thresh> =) [13:34:18] <kshishkov> thresh: and we did it in two languages [13:34:45] <thresh> kshishkov: here goes an obvious joke of not living in a proper country [13:35:38] <hyc> (ah, I had forgotten to enable UTF-8 in my screen session) [13:35:56] <kshishkov> thresh: I cannot argue, that's the reason I've moved [13:36:17] * thresh still notes ukrtel though [13:36:47] <kshishkov> thresh: ukrevilempiretel actually [13:37:44] <mru> english has two cases, upper and lower [13:38:46] <kshishkov> I actually meant stuff like Nominativ, Genitiv, Akkusativ und Dativ [13:40:09] <_av500_> kshishkov: most ppl here only know 3 of those anyway [13:40:20] <_av500_> rettet dem Dativ [13:40:20] * elenril remembers hearing those words a loooong time ago ;) [13:41:08] <kshishkov> _av500_: and I *don't know German at all* [13:43:26] <mru> kshishkov: it's much simpler than russian [13:43:44] <mru> russian has six cases: upper, lower, left, right, front, and back [13:44:04] <kshishkov> no, none of them is straight [13:44:20] <kshishkov> and German sometimes resembles Russian too much [13:44:51] <janneg> _av500_: should be only two then since "Der Dativ ist dem Genitiv sein Tod" [13:45:12] <mru> russian is like a cube, german is only a tetrahedron [13:45:45] <kshishkov> mru: Russian is like a corkscrew - the same straightness and associated with alcohol [13:46:09] * elenril wonders how to apply doppler shift to rgb data [13:46:23] <kshishkov> G--,B--,R++ [13:47:04] <kshishkov> or you can rebuild model of RGB correspondence to wavelength and convert it back and from [13:47:28] <kshishkov> IIRC it looked like a triangle in a loop [13:48:47] <elenril> except you miss the uv/ir parts [13:49:20] <kshishkov> and not only them [13:49:27] <elenril> i was thinking about fitting it to blackbody radiation, but it doesn't make a lot of sense for only 3 points [13:49:35] <kshishkov> for example, sky blue cannot be represented with non-negative R [13:51:42] * elenril should learn a few things about color representation [13:52:29] <kshishkov> I've read mine in the textbook for TV repairman [13:52:48] <elenril> and if i did it like you said, how would i add the resulting 3 colors together? [13:53:29] <kshishkov> to get what? [13:53:42] <elenril> the final shifted color [13:54:05] <kshishkov> depends on output format obviously [13:54:37] <kshishkov> I think it's better to operate in nanometers from the beginning [13:54:46] <elenril> you convert each of the input RGB components to a wavelength -> shift each one -> convert them back to RGB -> you're left with 3 rgb colors [13:54:56] <kshishkov> nope [13:55:10] <kshishkov> whole RGB triplet represents one single wavelength [13:55:16] <elenril> no? [13:55:24] <elenril> 'white' is not a wavelength [13:55:36] <kshishkov> it's not a colour neither [13:55:48] <elenril> (256,256,256) is white [13:55:49] <kshishkov> (for our US firends it's not a color as well) [13:56:04] <kshishkov> elenril: just mention that to Isaac Newton [13:57:22] <elenril> ? [13:57:40] <elenril> not sure what you're talking about [13:58:32] <kshishkov> you know, the guy with an apple and a prism [13:58:54] <_av500_> the prism fell on his head? [13:58:56] <elenril> how is that relevant to this? [13:59:03] * elenril throws http://bouman.chem.georgetown.edu/S02/lect23/Solar_Spectrum.png at kshishkov [13:59:22] <elenril> here's your white [14:02:29] <elenril> anyways, /me goes to school [14:02:34] <kshishkov> I remember that in 8th grade they told us "you'll learn Optics in 10th grade" and in 10th grade they said "you should've learned Optics in 8th grade already" [14:03:04] <elenril> heh [14:03:11] <elenril> optics was unexpectedly fun [14:03:20] <mru> there's this messy thing called human visual perception involved here too [14:03:50] <mru> simply shifting each of the rgb components won't do the right thing [14:04:12] <elenril> yeah, i realize that [14:04:42] <elenril> i'd need full spectrum to be physically correct [14:04:51] <mru> the eye has three kinds of colour receptors, each with a peak sensitivity at a different wavelength [14:05:25] <_av500_> beer color, meat color and flesh tones [14:05:28] * elenril away [14:05:36] <mru> any combination of inputs generating the same response from all three will be perceived as the same colour [14:05:41] <kshishkov> mru: engineers think their calculations are an approximation to reality, physicians think that reality is an approximation of their calculations and mathematicians don't see a connection between them both [14:06:04] <mru> physicists... [14:06:14] <mru> a physician is a medical doctor [14:06:57] <kshishkov> noted, thanks [14:07:04] <_av500_> j-b: ping [14:07:07] * kshishkov does not believe in them anyway though [14:07:30] * mru neither [14:07:42] <mru> but nurses can be nice... [14:08:22] * kshishkov remembers Monty Python skets involving two Gumbies calling nurse [14:09:03] <kshishkov> *sketch [17:11:05] <_av500_> j-b: pinger [17:11:23] <j-b> av500: pong [17:13:20] <j-b> shit [17:15:03] <j-b> _av500_: ping [17:17:46] <_av500_> for tonight? [17:17:54] <_av500_> propose place [17:18:08] <_av500_> needs food and beer [17:18:24] <CIA-7> ffmpeg: cehoyos * r23017 /trunk/libavformat/avidec.c: [17:18:24] <CIA-7> ffmpeg: Do not use pkt->size when it is potentially uninitialized. [17:18:24] <CIA-7> ffmpeg: Patch by Thierry Foucu, tfoucu gmail [17:18:38] <_av500_> im in massy [17:18:59] <_av500_> willing to travel somewhat [17:19:40] <j-b> where do you sleep? In massy too ? [17:19:47] <_av500_> yes [17:56:30] * Kovensky wonders how bad is sun's compiler [18:00:34] <astrange> someone gave me a copy but i seem to have lost it [18:00:52] <astrange> i had pathscale too. wonder where they went [18:00:59] <astrange> maybe i should find open64 too [18:02:02] <KotH> astrange: open64 seems mostly defunct these days [18:02:46] <KotH> astrange: if you want pathscale for testing, ask codestr0m, i'm quite sure he'll get you one [18:03:46] <KotH> Kovensky: on sparc, sun cc outperforms gcc by far (which isnt a surprise). but the quality of error messages is so bad, hardly anyone uses it during development [18:04:39] <astrange> the commercial highly-optimizing compilers (pgi, pathscale, icc) tend to be much slower than even gcc and not much better on ffmpeg [18:05:00] <astrange> they seem to advertise automatic parallelization and stuff which is useless for c, so i assume they're really meant for fortran or something [18:05:29] <Kovensky> KotH: lol [18:06:00] <Kovensky> I'll just try it anyway, and if it sucks I can make sunstudio use something else (I think) [18:06:24] <Kovensky> just learning though, don't intend to use it for long unless I end up liking, but I also guess that if people liked it they'd use and advertise it [18:06:27] <Kovensky> lol [18:06:56] <astrange> http://pastebin.org/201510 run this through it if you've got access, i'll give you a random guess at how good it is [18:08:59] <KotH> astrange: at least pathscale uses ffmpeg as test case :) [18:10:14] <mru> I've had people from arm ask how to run fate [18:10:34] <DonDiego> we need a fate replacement.. [18:11:05] <mru> doesn't sound so difficult [18:11:42] <Kovensky> astrange: through my suncc? [18:11:49] <DonDiego> it doesn't indeed; i've been toying with the idea ever since mike refused to share his code with me [18:11:53] <astrange> yeah [18:11:57] <Kovensky> astrange: how should I bench it [18:12:12] <astrange> i just want to read the asm output [18:12:13] <mru> I'd structure a replacement a bit differently [18:12:16] <Kovensky> oic [18:12:21] <Kovensky> it'll take a while to install [18:12:23] <DonDiego> mru: elaborate [18:12:28] <KotH> DonDiego: what's the prob with fate? [18:12:32] <mru> there's too much central control [18:12:33] <astrange> those are compiler testcases, i deleted the useful code from them to make it smaller [18:12:36] <Kovensky> 78MB out of 350MB [18:12:59] <Kovensky> at I-have-no-idea-how-fast-it-is-going-but-I'm-sure-it's-not-being-fast-at-all [18:13:47] <DonDiego> KotH: it is proprietary [18:13:56] <DonDiego> and the start page sucks [18:13:58] <KotH> DonDiego: ah.. [18:14:13] <KotH> DonDiego: nothing that cannot be written in a couple of days in haskel, perl or bash [18:14:30] <mru> make that one day in posix sh [18:14:37] <mru> and a bit of perl [18:14:49] <DonDiego> haskell could be fun :) [18:14:58] <Kovensky> ocaml? [18:15:11] <KotH> anyone a good idea how i can get rid of "warning: cast increases required alignment of target type" ? [18:15:14] <Kovensky> or at least I heard that ocaml is a less-lazy haskell =p [18:15:20] <mru> novelty languages are fun and all, but do real work with a real language, please [18:15:26] <KotH> (yes, the target is already alligned right, it's just gcc not getting that) [18:15:29] * Kovensky votes for perl [18:15:36] <mru> KotH: get rid of -Wcast-align [18:15:50] <Kovensky> how do you disable a warning, -w or -Q? [18:15:50] <KotH> mru: that i dont want to [18:16:01] <mru> then you have to live with the warning [18:16:05] <mru> KotH: -Wno-foo [18:16:15] <mru> Kovensky: ^^ [18:16:17] <DonDiego> Kovensky: -Wno-cast-align [18:16:37] <KotH> mru: ok.. then so be it [18:16:57] <Kovensky> oic [18:17:03] <Kovensky> clang uses -Q, at least for its own warnings [18:17:17] <mru> yeah, there's no standard [18:17:20] <KotH> ok.. code compiles, only three warnings (all bougus), testing (resp frying hardware) can wait for tomorrow [18:17:31] <KotH> time to go home \o/ [18:17:37] <KotH> have a nice evening boys! [18:18:02] <Kovensky> I suppose it supports -Wno- for gcc compatibility though [18:18:12] <Kovensky> talking about gcc compatibility, it can't compile firefox :( [18:18:15] <Kovensky> durr friend templates [18:18:39] <Kovensky> it also fails on "typodef struct Name {} Name;" if you try using "struct Name;" [18:19:03] <KotH> Kovensky: nice typo ;) [18:19:24] <peloverde> firefox? that's that theora browser? [18:20:53] <DonDiego> it had better fail on 'typodef' [18:23:30] <Dark_Shikari> http://pastie.org/945486 [18:23:34] <Dark_Shikari> this patch fixes the win64 ABI issue [18:23:41] <Dark_Shikari> (courtesy of bugmaster) [18:24:05] <Kovensky> KotH: ;) [18:24:08] <Kovensky> DonDiego: indeed :> [18:24:28] <mru> Dark_Shikari: why the ifdefs? [18:24:39] <mru> that reg is always clobbered [18:24:44] <Dark_Shikari> mru: so that it can compile on x86_32 without -msse2 [18:24:47] <mru> it was a mistake not to mark it originally [18:24:59] <mru> at least the _WIN32 ifdef should go [18:25:03] * Kovensky never understood gcc asm syntax [18:25:03] <Dark_Shikari> ok, agreed [18:25:09] <Dark_Shikari> But that's obviously a trivial find/replace to remove that [18:25:11] <mru> and tidy it up with a macro somewhere [18:25:13] <Dark_Shikari> so it's hardly something to debate about. [18:25:24] <DonDiego> Dark_Shikari: btw, if you can help with optimizing that YUV to RGB lgpl code, that would be very appreciated [18:25:28] <DonDiego> pengvado: same for you [18:25:29] <DonDiego> :) [18:26:43] <peloverde> DonDiego, what's the status on 0.6? [18:27:06] <DonDiego> looking good :) [18:27:21] <DonDiego> didn't siretart cut the branch already? [18:27:26] <peloverde> did he? [18:27:35] <peloverde> branches aren't visible anywhere [18:27:43] <peloverde> I have SBR fixes I'd like to backport [18:28:12] <DonDiego> there is no branch yet i think [18:28:15] <DonDiego> so just commit the fixes [18:28:27] <DonDiego> let us know when you're done [18:28:34] <peloverde> they are comitted [18:28:48] <DonDiego> then they will be in 0.6 [18:29:49] <peloverde> ok [18:32:12] <Kovensky> meh, why do people top-post so much in the gsoc list too :( [18:36:26] <ramiro> Dark_Shikari: is that everything that needs to be patched? I expected a much longer patch. [18:42:04] <mru> anyone heard of these guys? http://cinemo.com/ [18:42:19] <mru> just got an email from their ceo [18:47:11] <_av500_> mru: ~corbett [18:47:39] <CIA-7> libswscale: diego * r31135 /trunk/libswscale/ (x86/yuv2rgb_mmx.c Makefile yuv2rgb.c x86/yuv2rgb_template2.c): [18:47:39] <CIA-7> libswscale: alternative LGPL-licensed, MMX-optimized YUV to RGB conversion routines [18:47:39] <CIA-7> libswscale: written by Kostya Shishkov [18:47:57] <mru> _av500_: ? [18:48:00] <mru> you know him? [18:48:23] <_av500_> ask kshishkov :-) [18:48:41] <_av500_> its his outfit... [18:48:55] <mru> oh [18:49:13] <_av500_> thre nero guy [18:49:26] <mru> yeah, I got the nero connexion [18:49:40] <DonDiego> mru: kostya works for them [18:49:43] <DonDiego> what did they want? [18:50:22] <mru> talk business [18:51:04] <spaam> mru: they want you to work for them ? :) [18:52:29] <kierank> as chief troll [18:52:55] <spaam> :) [18:52:56] <mru> giving CTO a whole new meaning [18:58:06] <Dark_Shikari> ramiro: most functions don't even use more than 6 xmm regs [18:58:42] <ramiro> Dark_Shikari: isn't it about using some specific regs? [18:58:50] <Dark_Shikari> yes. xmm6 and above. [18:58:57] <Dark_Shikari> Which you only use if you've used xmm0-5 already. [18:59:02] <ramiro> ah, ok... [19:16:43] <BastyCDGS> hey wonderful evening @ all! [19:16:56] <mru> morning BastyCDGS [19:17:05] <BastyCDGS> how are u? [19:17:06] <mru> btw, what is cdgs? [19:17:17] <BastyCDGS> CDGS = Coders Develop Glorious Stuff [19:21:04] <BastyCDGS> mru, what do you think about the palette index be/le issue? [19:22:10] <mru> don't ask me [19:22:19] <mru> michael has strong opinions on those things [19:23:03] <BastyCDGS> btw, are my heavy opt patches now getting in? [19:23:18] <BastyCDGS> including the iff-decoder-fix patch [19:23:42] <BastyCDGS> which fixes all these wrong decoded iffs that don't have masking enabled [19:39:53] <BastyCDGS> mru, I'm thinking of a way to get rid from the switch cases in the HAM decoding stuff [19:40:01] <BastyCDGS> and put that into a table [19:40:13] <Kovensky> <@mru> giving CTO a whole new meaning <-- lol [19:40:55] <BastyCDGS> it seems it has to be dynamically created because of the palette data and hbits / mbits [19:42:39] <peloverde> Their product list seems very intel-centric [19:45:18] <kierank> maybe getting money from intel [20:05:15] <Kovensky> DonDiego: lend me your grammar powers [20:05:26] <Kovensky> DonDiego: how is "I found song" correct [20:06:12] <_av500_> a song? [20:06:27] <_av500_> the song? [20:06:38] <_av500_> one song? [20:07:08] <Kovensky> 17:00.40 <&Emess> I'm not following you at all [20:07:08] <Kovensky> 17:00.59 <~zfs> "found a song", "found the song", "found many songs", "found one song", but not "found song" [20:07:11] <Kovensky> 17:01.24 <&Emess> song as a collective object [20:08:12] <kierank> replace "song" with "music" and it might be clearer [20:08:25] <Kovensky> kierank: yes, but he keeps arguing that "song" isn't wrong [20:11:26] <mru> yes, song can be used like that [20:11:42] * Kovensky sees no documentation about that in the internet [20:11:48] <mru> http://www.merriam-webster.com/dictionary/song [20:11:51] <mru> first entry [20:12:26] <mru> although "I found song ..." does sound a bit odd [20:12:35] <mru> "singing" is probably better there [20:13:01] <mru> depends on context of course [20:13:23] <Kovensky> his rant-explanation is "<&Emess> she had nothing to live for, then she discovered the power of song and is now a happy musicfag~" [20:13:30] <Kovensky> s/~// [20:13:39] <Kovensky> (which still doesn't make much sense for me) [20:13:43] <mru> that is a correct sentence [20:13:52] <Kovensky> I find that 'music' would be a much less confusion-inducing noun [20:13:56] <mru> maybe missing a comma [20:15:36] * _av500_ likes the tower of song [20:15:42] <BastyCDGS> mru, I just updated my patches to represent the latest unsigned->signed changes [20:15:57] <BastyCDGS> so they apply to current git/svn again [20:16:06] <Kovensky> he keeps saying it's an expression that only natives would understand and also that it's "a fairly fucking common expression" :v [20:16:52] <mru> I wouldn't say it's that common [20:17:04] <mru> but it's not hard to understand [20:17:04] <Kovensky> me neither [20:17:10] <twnqx> let's just wait for D_S [20:17:25] <Kovensky> otherwise it would appear on a google search, or define: search, or on UD, or on TFD [20:17:55] <Kovensky> I don't find it hard to understand at all, I just think the grammar is wrong because 'song' is countable [20:19:52] <janneg> BBB: ping [20:19:57] <kierank> you can "burst into song" though Kovensky [20:21:26] <twnqx> the fucl [20:21:35] <twnqx> never heard that phrase either [20:21:46] * Kovensky neither [20:25:29] <dgux> "The file you are trying to access is temporarily unavailable." [20:26:18] <BBB> janneg: pong [20:26:31] <BBB> (sorry, I'm semi-not-here, but ask anyway and I'll respond in a few minutes) [20:27:02] <BastyCDGS> hey BBB :) [20:27:05] <dgux> Hi all, I'll probably be told that I should ask in #ffmpeg, but no activity there. I'm just wondering about a problem that I see encoding mp4's for wowza RTMP vs. FMS RTMP. (same files are fine on FMS, but not smooth on wowza). Does this ring a bell for anyone? [20:33:36] <BBB> BastyCDGS: I'll get bck to patch review at the end of this week, I'm almost done with busy work-stuff [20:34:25] <BastyCDGS> oh so it's the same as here ;) [20:35:59] <kierank> dgux: ask hyc [20:36:34] <dgux> Thanks kiernak [20:37:18] <Dark_Shikari> mru: http://pastie.org/945767 [20:37:23] <Dark_Shikari> Not as pretty as I'd hoped, but better than before [20:41:14] <lu_zero> fms? [20:41:28] <wbs> lu_zero: flash media server [20:41:30] <dgux> yea, Adobe flash media server [20:41:50] * lu_zero should learn more about rtmp =P [20:42:00] <lu_zero> wbs: hi [20:42:19] <wbs> lu_zero: hi :-) [20:42:58] <lu_zero> any news? [20:44:01] <lu_zero> today we eventually put a workaround in feng so upset udp network won't makes rippling drifts on live streaming in feng =P [20:44:16] <wbs> oh, nice :-) [20:44:21] <wbs> nothing new here, I think [20:45:36] <pengvado> BugMaster, Dark_Shikari: of the functions that are split into multiple asm blocks, do any depend on data staying in xmm6+ between blocks? if so, clobber doesn't describe that dependency, and will probably break. [20:46:03] <Dark_Shikari> ooh, good point. [20:46:06] <pengvado> also, does gcc only spill to memory, or can it spill xmm6 into xmm0 if you tell it that xmm6 is clobbered and xmm0 isn't? [20:46:16] <Dark_Shikari> Also good point. [20:46:32] <Dark_Shikari> hmm, I think we might need to do things The Right Way then (declare all clobbers) [20:46:49] <Dark_Shikari> 1) rewrite all asm functions to use incrementing numbers of xmms (i.e. to not use xmm0, xmm1, and xmm6) [20:46:58] <BugMaster> there is such blocks (but dissasm show that it is mostly ok). it seems to splitt only to memory [20:47:00] <Dark_Shikari> 2) declare macros for XMM0 ... XMM15 clobbers [20:47:15] <Dark_Shikari> ugh. I don't like relying on "the current version of gcc happens to do X" [20:48:20] <BugMaster> eh. probably the problem can occure only if changed xmm register used in section between to asm blocks [20:48:21] <mru> yeah, that's a Very Bad Idea [20:48:40] <mru> gcc makes no promises about what it does between two asm blocks [20:48:42] <pengvado> The Right Way is to declare any data passed from one block to another via "x" constraint. but that fails to compile without -msse, just like the clobbers do. [20:49:45] <mru> the right way is not have such dependencies at all [20:50:38] * Kovensky throws an yasm in the channel and runs away [20:51:44] <mru> yes, that's the best [20:51:50] <mru> for non-inlined functions [20:52:23] <lu_zero> hopefully next I'll merge the statistics stuff and add auth and tls (eventually) [20:52:59] <wbs> lu_zero: oh, what other implementations do rtsp over tls? [20:53:15] <wbs> lu_zero: and do you run that on a separate port, or is it negotiated on the fly within a normal session? [20:53:33] <lu_zero> I'd like to negotiate it on fly [20:53:49] <BugMaster> anyway if the problem of such dependence exist than it exist in current code also not only with this patch [20:54:05] <mru> yes, and it should be fixed [20:54:07] <mru> not ignored [20:54:46] <lu_zero> I'm not sure how many would do, surely I'll make sure ffmpeg will be able to interact with it =P [20:55:08] <lu_zero> btw did you read my request for comments/clues about sctp? [20:55:50] <BugMaster> I don't tell that it must be ignored. But it must be fixed separate from this patch (which must be earlier is the question but I don't want to fix this also). [20:56:29] <mru> this patch could make it worse [20:57:03] <mru> I wouldn't be at all surprised if gcc decided to reload the clobbered registers between two asm blocks [20:57:22] <mru> but leave them alone if it's unaware of anything going on with them [20:57:37] <wbs> lu_zero: didn't read it much, I know next to nothing on sctp [20:58:08] <wbs> lu_zero: on rtsp/tls, this may be a quite relevant discussion: http://www.ietf.org/mail-archive/web/mmusic/current/msg05580.html [20:58:43] <siretart> DonDiego: I'm on it right now. [20:59:06] <CIA-7> ffmpeg: siretart * r23018 /branches/0.6: Create 0.6 release branch. [21:00:24] <lu_zero> ok, Magnus suggests separate port -> less work for us =) [21:00:57] <DonDiego> the branch arrived :) [21:01:05] <DonDiego> siretart: 0.5.2 ? [21:01:28] <mru> oh, get 0.6 out there already and drop 0.5 [21:01:36] <mru> can we have it out by linuxtag? [21:01:58] <wbs> when is that? [21:02:09] <CIA-7> ffmpeg: siretart * r23019 /branches/ (31 files in 8 dirs): replace svn:externals on libswscale by a real copy [21:02:11] <mru> june [21:02:15] <mru> 9-12 iirc [21:02:27] <mru> siretart: scary... [21:03:00] <siretart> mru: 0.5 will be around in distros and other distros for quite some time, what do you exactly mean with 'drop 0.5'? [21:03:17] <mru> I mean stop maintaining it [21:03:29] <mru> not eradicate it from history [21:03:41] <Kovensky> we'd need a flux capacitor for that [21:04:05] <lu_zero> uhm [21:04:11] <elenril> Kovensky: here http://xkcd.org/730/ [21:04:15] <Kovensky> unless mru has one in his basement, along with his shotgun [21:04:20] <Kovensky> elenril: :P [21:04:41] <siretart> well, if some distro contributes clean patches, or even better, manages to nominate patches that backport cleanly and fix security issues, I don't see why they shouldn't be included in 0.5 [21:04:49] <BastyCDGS> elenril: lol [21:05:04] <siretart> but as for "active maintenance", i think we agree [21:05:14] <twnqx> mru: i'd have done that years ago [21:05:25] <twnqx> it's just old, obsolete and deprectaed [21:05:34] <BastyCDGS> for the flux though, you should just add imaginary components ;) [21:05:43] <twnqx> oh, and ridicously crappy, codecsupportwise [21:09:24] <peloverde> the current ubuntu LTS uses 0.5-branch, no? [21:09:57] <peloverde> do any of the mainstream rpm distros ship ffmpeg? [21:10:46] <Kovensky> maybe fedora, but if they do it's probably a highly crippled version [21:10:54] <janneg> peloverde: I don't think so [21:10:57] <peloverde> no ffmpeg is banned from fedora [21:11:06] <Kovensky> lol [21:11:08] <peloverde> they won't even ship the stripped down chromium version [21:11:16] <Kovensky> then it isn't in RHEL either [21:11:25] <lu_zero> what? [21:11:31] <lu_zero> and why? [21:11:41] <Kovensky> well, this is just wild guessing [21:11:43] <Kovensky> it might be, dunno [21:11:50] <Kovensky> suse? mandriva? [21:12:00] <Kovensky> they're the only other ones I can think of [21:12:39] <janneg> only hit for ffmpeg in fedora13 packages is gallery2-ffmpeg [21:12:40] <peloverde> for fedora see this issue: http://code.google.com/p/chromium/issues/detail?id=28289 [21:13:09] <DonDiego> siretart: this reminds me of the wiki page for distro status.. [21:13:51] <Kovensky> blastwave (some solaris thing) ships 0.4.9 (lolol) and 0.5 [21:14:25] <siretart> DonDiego: yeah, my fault. I still didn't get to that. I'm currently writing a mail about ffmpeg 0.6 for ffmpeg-devel [21:14:33] <DonDiego> no trouble [21:14:47] <DonDiego> it would be nice if you got to it eventually [21:14:57] <lu_zero> "Fedora won't use ffmpeg, for legal reasons" [21:15:01] <lu_zero> sad [21:15:35] <BastyCDGS> they all are worried about getting sued for patent issues [21:15:55] <BastyCDGS> time to stop this software patent bullshit [21:16:02] <peloverde> but the chromium version of ffmpeg only has ogg, vorbis, and theora decoders [21:16:32] <BastyCDGS> I was concerning fedora... [21:16:41] <peloverde> so was I [21:16:51] <BastyCDGS> but why then they write legal reasons? [21:16:52] <peloverde> fedora won't ship the stripped down chromium version of ffmpeg [21:17:30] <peloverde> cargo cult IP policy [21:17:44] <BBB> why do you guys care about freetards with a 0.1% market share? [21:17:59] <BastyCDGS> well I don't really care about fedora ;) [21:18:07] <BBB> videolan has more installations on windows95 than fedora has installations in total [21:18:09] <DonDiego> their linux market share is larger than that [21:18:16] <BBB> and believe me, not many people run windows95 [21:18:20] <Kovensky> plus, almost everyone sane uses whatever-livna-is-called-now [21:18:33] <BBB> DonDiego: all desktops, not linux [21:18:37] <kierank> wow vlc still works on w95 [21:18:42] * BastyCDGS runs win9x for doing IT music [21:19:10] * Kovensky hasn't run win9x in 8 years [21:19:15] <DonDiego> BBB: i hardly see windows desktops these days [21:19:15] <peloverde> I care about fedora because every ubuntu upgrade things break [21:19:16] <BastyCDGS> it's the only config where IT still w/o problems runs on my relatively modern machine [21:19:19] * kierank knows someone who uses windows 3.1 [21:19:27] <peloverde> I'd like a reasonable exit strategy [21:19:45] <kierank> [22:19] <@peloverde> I care about fedora because every ubuntu upgrade things break --> yes, and delete your partition sometimes [21:19:51] <BastyCDGS> pelo, are you using alien debs? [21:19:54] <BBB> DonDiego: what do people around you use then? [21:19:56] <BastyCDGS> and/or repos? [21:19:58] <peloverde> no [21:19:59] * BBB gone again btw [21:20:14] <peloverde> I use a handful of PPAs they are unrealted to what breaks [21:20:45] <BastyCDGS> well, after 2 years I prefer a fresh install anyway [21:20:55] <peloverde> I do do clean installs [21:20:55] <BastyCDGS> I'm also this LTS to LTS guy [21:21:04] <DonDiego> BBB: macs, linux, the latter equally debian and ubuntu [21:21:25] <DonDiego> i think i've only ever seen a fedora once in the wild [21:21:27] <BastyCDGS> btw, I installed kubuntu 10.04 on my laptop running it in a virtualbox machine in 64-bit mode with win7 as host [21:21:31] <peloverde> in this release, zuff is missing/fails post build tests, gvim spams shit to the console, gtkwebkit crashes constantly [21:21:50] <BastyCDGS> what I realized was that many picture decoders don't show an Image anymore [21:22:07] <BastyCDGS> or if they do only on very very small images (32x32 or alike) [21:23:03] <BastyCDGS> installed kubuntu was the final one (i.e. no RC/beta/etc.) [21:23:07] <peloverde> plus I wind up having to undo the obnoxious Ubuntu customizations like putting the close button next to the file menu [21:23:21] <BastyCDGS> I also tried to fix the issue in ffplay without luck :( [21:23:45] <BastyCDGS> I found out nice stuff how to avoid it to clear the background on window resize [21:23:55] <BastyCDGS> but on switching to fullscreen it still happened [21:25:13] <BastyCDGS> the other thing I found out is, on x86_64 the IFF demuxer/decoder segfaults if you enable libavfilter [21:25:16] <BastyCDGS> and swscale [21:25:20] <BastyCDGS> with configure [21:26:11] <BastyCDGS> but latter bug has still to be retested on x86_32 for really be sure that's a 64-bit issue [21:27:47] <BastyCDGS> I expect it though more be a kwin4 issue than be one of endianess [21:28:36] * Kovensky wonders how are kwin4 or endianess related to word width [21:32:12] <Kovensky> isn't win64 not working a regression in relation to 0.5? [21:33:23] <BastyCDGS> kovensky, I meant I'm not sure yet if it's an 64-bit issue or a window manager, I just figured that ffplay is practically unusable with 10.04 / kwin4 within virtualbox with a win7 host [21:33:38] <BastyCDGS> (for standalone pics) [22:12:33] <Kovensky> siretart: isn't ffmpeg not compiling on win64 a regression [22:12:55] <mru> it never did [22:13:04] <Dark_Shikari> it's compiled on win64 just fine. _WORKING_ is another story [22:13:13] <mru> well, yeah [22:14:00] <Kovensky> I remember people saying it worked until some commit broke win64 ._. [22:14:04] <Kovensky> but I don't remember which commit [22:14:13] <Dark_Shikari> no [22:14:14] <Dark_Shikari> it never worked [22:14:17] <mru> most of that asm is ancient [22:14:24] <Kovensky> lol [22:14:33] * Kovensky thinks working win64 should be in 0.6 [22:16:31] <ramiro> Kovensky: that's something different. it fails to compile swscale [22:16:47] <ramiro> but even when that is fixed, it won't work properly [22:17:08] <Dark_Shikari> Yeah. [22:23:43] <ramiro> mru: building for win64 spams the console with "cc1: warning: -fPIC ignored for target (all code is position independent)" for every file. is there any way to avoid it? [22:28:06] <mru> fix gcc [22:28:20] <mru> -fPIC asks for PIC, gcc gives you PIC, what's it whinging about? [22:32:19] <Kovensky> clang is worse on the unused parameter whinery :( [22:32:28] <Kovensky> IIRC you need to give -Qunused-arguments [22:34:00] <ramiro> mru: IIRC there's no off switch for that warning. I don't mind, but it worries some users... (the same that thing they found a bug because at the end of config.err it says alignment is not a power of 2) [22:34:32] <ramiro> it's amazing how many people think that fixing that alignment "bug" is the solution to all their problems. [22:34:59] <mru> ramiro: that's why I said "fix gcc" [22:35:06] <mru> it's whining about something that isn't a problem [22:35:16] <mru> it's doing exactly as it was asked [23:13:39] <pengvado> kshishkov: random idea to save about 45 instructions in yuv2rgb24: http://pastie.org/946021 (untested) [23:14:50] <pengvado> it should also be obvious how to apply pshufb to this [23:16:18] <pengvado> on x86_64, the shift/store part could also use gprs, which allows the 2 byte stores to be actually 2 bytes [23:20:41] <pengvado> why the nearest-neighbor chroma interpolation? [23:28:25] <BBB> does anyone know what 'b' means in nm output? [23:28:30] <BBB> from the top of their head [23:30:27] <astrange> probably bss [23:42:41] <DonDiego> gnite [23:56:55] <BBB> mru: (ignorantly naive etc.), but what about e.g. alloca and calloc? [23:57:00] <BBB> no good? [23:57:21] <BBB> (I'm not strictly against malloc, I'm just affraid it'll affect performance in some unpredictable way on some systems)

1 0

IRC log for 2010-05-03
by irc＠mansr.com 04 May '10

04 May '10

[04:56:40] <siretart> mru: pong [05:58:39] <CIA-7> ffmpeg: mstorsjo * r23012 /trunk/libavcodec/amrnbdec.c: [05:58:39] <CIA-7> ffmpeg: amrnbdec: Apply AMR_SAMPLE_SCALE when finishing the decoder output [05:58:39] <CIA-7> ffmpeg: The output scaling was accidentally removed in rev 22937. [06:40:11] <superdump> morning [07:53:32] <KotH> salve [07:53:49] <kshishkov> shalom [07:56:03] <pJok> god morgon kshishkov :) [08:00:32] <kshishkov> god morgon (: [08:01:11] <KotH> juten morjen kshishkov [08:01:40] <av500> KotH: eek [09:10:27] <merbzt> tere homikust [09:10:38] <wbs> tere tulemast [09:11:54] <kshishkov> ar du i Ingermanland nu? [09:12:12] <merbzt> vem jag ? [09:13:05] <kshishkov> "tere hommikust" ar estlandska for "god morgon" eller hur? [09:13:20] <merbzt> det stämmer [09:13:58] <merbzt> men, nej jag är inte i Ingermanland [09:14:28] <ohsix> ikke norsk [09:23:39] <siretart> calimera! [09:24:21] * kshishkov was right about German people being incomprehensible [09:24:59] <siretart> Does anyone know open blockers for creating the 0.6 branch? FATE looks good to me so far [09:25:10] <siretart> I'm considering creating the 0.6 branch this afternoon [09:25:44] <DonDiego> i'm afraid i may know one [09:25:55] <DonDiego> lgpl reimplementation of gpl parts in libswscale [09:26:03] <DonDiego> let me send an email.. [09:26:41] <siretart> hrmpf [09:26:42] <siretart> ... [09:27:09] <DonDiego> not hard to backport in any case [09:27:16] <DonDiego> i'll get back to you this afternoon [09:27:21] <siretart> k [09:32:04] * wbs is waiting for review of the movenc stuff that he'd be happy to have in the 0.6 branch [09:32:19] <wbs> I've pinged baptiste a few times about it now without any success ;P [09:32:54] <kshishkov> you can try catching him here late in the evening [09:33:12] <wbs> yeah, i've tried pinging him on irc, too, but then he's mostly been idle [09:33:34] <siretart> the plan is to first branch, then track and cherry-pick patches from trunk to branch and then release [09:34:19] <siretart> picking that patch seems pretty straightforward [09:49:30] <Kris_eva> Hi All, is there a way to browse patches submitted to ffmpeg? [09:50:01] <kshishkov> yes, with your eyes, browser and site like news.gmane.org [09:52:32] <Kovensky> git log? [09:52:42] <Kris_eva> nice thanks [09:53:06] <kshishkov> depends on definition of "submitted" [09:53:36] <av500> Kris_eva: there is no formal patch submission, they are posted on the ML [09:54:06] <Kovensky> you can also post them here, where you will be directed to post on the ML [09:54:11] <Kris_eva> hmm I guess you are right [09:54:40] <Kris_eva> just browsing through news.gmane.org [09:56:05] <merbzt> Kris_eva: filter on [PATCH] [09:56:52] <Kris_eva> yaa right...thanks [10:03:54] <Kris_eva> Thanks fond what Iam looking for [10:03:59] <Kovensky> or just [PATCH; people that send with git send-patch often end with [PATCH 1/n], [PATCH 2/n], etc [10:04:19] <Kris_eva> found* [10:42:41] <DonDiego> siretart: i have permission from michael to commit the lgpl code under #ifdef [10:42:47] <DonDiego> i'll do that tonight [10:42:56] <DonDiego> we're good to go then [10:43:02] <DonDiego> siretart: what about 0.5.2? [10:43:55] <siretart> DonDiego: I remember I had about 3 patches that I wanted to look at for 0.5.2, that's still open [10:44:08] <siretart> then we need to consider if what we have is 'enough' for 0.5.2 [11:36:26] <DonDiego> commit those patches then [11:36:36] <DonDiego> and ask on the ml if anything is pending [11:56:17] <av500> http://blog.kaourantin.net/?p=89 [12:00:49] <DonDiego> flash is slow nonetheless :) [12:01:23] <DonDiego> but somebody did indeed manage to light a fire under their behinds.. [12:02:16] <mru> actually, I wouldn't be sorry were flash burned at the stake [12:02:28] <mru> mike can surely find another job [12:03:31] <siretart> mru: you pinged my last night? [12:03:41] <mru> yeah, random ubuntu question [12:03:52] <mru> someone was complaining about ugly fonts [12:04:02] <siretart> i see [12:04:10] <mru> probably cheap, "free" fonts, no hinting, and overzealous AA [12:04:20] <mru> any simple remedy? [12:04:34] <mru> like a freetype package with hinting turned on? [12:04:55] <mru> and a simple way to install, say, the usual windows fonts [12:05:16] <mru> gentoo does all that of course [12:05:19] * mru hides [12:05:21] <astrange> freetype auto hinting isn't terrible especially with subpixel on (which should be default) [12:05:29] <mru> auto-hinting is terrible [12:05:36] <mru> compared to using the real hinting [12:05:36] <astrange> the default font is really bland, though. and i think it's a grotesk too [12:05:36] <ohsix> sec, i got the package name [12:05:39] <siretart> you can configure AA in settings->appearance or something. windows fonts and other goodies are installed as sideeffect by installing the metapackage 'ubuntu-restricted-extras' [12:06:13] <ohsix> apt-get instal msttcorefonts, most things install them already; and its a virtual that brings in the new package (dunno the new name) [12:06:27] <ohsix> yea what he said [12:07:21] <av500> mru: what is the exact name of yon tegra board? [12:08:14] <mru> av500: 180-81162-1000-A02 [12:08:33] <av500> a tad less exact [12:11:25] <mru> Tegra 250 Developer Kit [12:11:51] <av500> yup, just found it. [12:11:53] <av500> thx [12:12:38] <av500> it boots now? [12:12:55] <mru> it always booted with the kernel someone flashed for me [12:13:04] <mru> I haven't been able run any other kernel [12:14:11] <mru> I need to look into that again [12:14:26] <av500> ic [13:15:25] <j-b> astrange: what is the 'official' ffmpeg-mt repo now ? [14:09:58] <scaphilo> anyone knows if its possible to use qscale (not dquant) for every single macro bock in mpeg4part2. The thing is: mpeg2 to mpeg4part2 openloop transcoder could work without a quantiser if this whould be possible. [14:10:41] <scaphilo> mpeg2 can do changes in qscale from one mb to an other in every size mpeg4part2 has a maximum change possibility of +/- 2 [14:16:20] <astrange> why do you want to transcode to mpeg4part2? it's a bad idea to inflict any more of that on the world [14:16:25] <astrange> try x264 ultrafast first [14:17:19] <mru> he wants to do a bitstream conversion without full decode [14:17:26] <mru> useless if you ask me [14:17:43] <scaphilo> i dont really want to i have to :-) [14:17:58] <scaphilo> and mru is right [14:18:15] <mru> if you cannot choose what you have to do, you're doing it wrong [14:18:40] <scaphilo> contract is a contract [14:18:43] <astrange> and yes you can't convert the delta quant. but the quantizer is slightly different anyway [14:18:57] <astrange> (no mismatch control) [14:19:00] <mru> his client clearly doesn't give a toss about quality [14:19:12] <scaphilo> :-) [14:19:15] <scaphilo> right [14:19:24] <scaphilo> you sould be able to watch [14:20:08] <scaphilo> thx astrange [14:20:39] <KotH> scaphilo: you know that the cost for inflicting pain (in any form) to a ffmpeg developer is a year ration of swiss chocolate? [14:20:56] <KotH> scaphilo: so, be carefull what you ask ;) [14:21:45] <scaphilo> KotH :-) [14:22:31] <scaphilo> by the way is someone here who used ffmpeg on an ARM arch [14:22:46] <scaphilo> i compiled for a niosII without an os [14:23:18] <mru> ffmpeg is well-supported on arm [14:23:41] <scaphilo> but with linux on it? [14:23:53] <scaphilo> i mean uclinux or something [14:24:00] <mru> libavcodec doesn't need an os [14:24:41] <Kovensky> does it have an fflibc [14:25:04] <merbzt> we are getting there [14:25:15] <mru> lavc doesn't use much of libc [14:26:18] <mru> most importantly, it doesn't do file i/o [14:26:39] <mru> it needs some kind of malloc of course [14:26:45] <scaphilo> is there an arm ffmepg project open source arround? [14:26:45] <mru> which you can easily supply your own [14:27:05] <mru> plain ffmpeg svn works fine on arm [14:27:51] <scaphilo> am well didnt you build an main arround ffmpeg? [14:28:01] <mru> uh? [14:29:01] <scaphilo> difficult to describe sorry... how do you say ffmpeg to use this memory as input and an other memory as the output? [14:29:19] <mru> see avcodec.h [14:30:12] <scaphilo> k ill do that [15:15:52] <CIA-7> ffmpeg: mru * r23013 /trunk/configure: [15:15:52] <CIA-7> ffmpeg: configure: allow compiler-specific flags for --disable-optimizations [15:15:52] <CIA-7> ffmpeg: ICC needs at least -O1 to link so add this when optimisations are [15:15:52] <CIA-7> ffmpeg: otherwise disabled. [16:34:37] <lu_zero> uhmm [16:34:48] <lu_zero> our dv capture is completely outdated... [16:43:14] <ramiro> twnqx: lu_zero: outdated how? [16:43:25] <ramiro> oops, twnqx wasn't meant to be there... [16:43:32] <twnqx> thought so :P [16:44:55] <ramiro> twnqx: this is the message meant for you: I see from the logs that you had some problems with gentoo and "relocation R_X86_64_PC32 against". was that resolved? (and not the CFLAGS=-fPIC hack) [16:46:14] <lu_zero> ramiro: dv1394 had been deprecated since ages [16:46:22] <lu_zero> now you have to use raw access [16:46:43] <twnqx> ramiro: guess i solved it, but can't remember how [16:46:49] <twnqx> it's just... computers never win [16:46:55] <twnqx> as a matter of principle [16:46:58] <ramiro> lu_zero: IIRC last time I tried I had to use dvgrab... [16:48:25] <Dark_Shikari> so, this guy is hilarious [16:48:31] <Dark_Shikari> this guy I just talked to [16:48:40] <Dark_Shikari> he wants to develop a new STB middleware for a big national telco [16:48:43] <Dark_Shikari> because all the existing ones suck [16:49:01] <Dark_Shikari> So he's going to.... go find a dozen grad students who will work for pennies on the dollar and hire them all [16:49:08] <Dark_Shikari> somehow I don't see this going very well [16:49:19] <lu_zero> right now I'm trying to not use dvgrab since it seems to introduce a quite annoying desync [16:49:49] <ramiro> Dark_Shikari: is he brazilian? [16:50:06] <ramiro> that sounds a hell of a lot like where I work. [16:50:10] <Dark_Shikari> belgian, I think [16:50:12] <kierank> the word "middleware" automatically signifies failure to me [16:50:17] <_av500_> Dark_Shikari: the existing ones were written by mru [16:50:33] * _av500_ hides [16:50:38] <Dark_Shikari> ahaha [16:51:00] <peloverde> I got a new firmware update pushed to my STB and it traded a usable interface for legible text [16:51:18] <_av500_> you cannot have it all [16:52:46] <peloverde> wasn't cablecard supposed to bring competition to the cable stb market [16:53:02] <saintdev> yes, but the cablecos screwed it up [16:53:26] <saintdev> so the fcc's solution: Let's come up with a new standard! [16:53:54] <lu_zero> ... [16:53:56] <lu_zero> bleah [17:00:09] <Kovensky> ramiro: the usual workaround for that relocation thing is -Wl,-Bsymbolic [17:00:28] <Kovensky> I don't remember the implications though, mru should know since he explained to me and I forgot :E [17:01:38] <mru> it makes the linker resolve intra-lib references immediately while building the shared lib [17:01:51] <mru> so at runtime they don't go through the got/plt [17:03:12] <ramiro> Kovensky, mru: thanks [18:15:13] <DonDiego> Yuvi: btw, what about nicking some optimizations from libtheora? [18:15:54] <mru> do they have any [18:15:56] <mru> ? [18:16:01] <DonDiego> mmx IIRC [18:16:09] <DonDiego> where we (only) have mmx2 [18:16:33] <_av500_> he said the t word [18:17:31] <DonDiego> is there a contest going on to avoid the name of the codec that share letters with "the oral exam"? [18:17:35] <DonDiego> :) [18:24:12] <kierank> hmmm i wonder whether to report to bbc that this dolby app is quietly using libmxf without recognising lgpl [18:24:28] <DonDiego> do it [18:25:46] <kierank> does the use of lgpl code nullify the eula's "ban" on reverse engineering. (ignoring any local laws)? [18:25:59] <DonDiego> no [18:26:09] <DonDiego> it means that the license is violated [18:26:22] <DonDiego> because it forbids such restrictions [18:26:42] <DonDiego> the license == it == lgpl (just to clarify) [18:27:15] <DonDiego> whether it's nullified or not is a different question i suppose [18:27:49] <DonDiego> kierank: please report the violation to both the bbc and the libmxf devs [18:28:03] <kierank> libmxf devs = bbc afaik [18:28:20] <DonDiego> hmm [18:28:23] <_av500_> they voilate themselves? [18:28:34] <DonDiego> no, they cannot violate their own license [18:28:35] <mru> dolby are the violators [18:28:50] <kierank> yes neyrinck for dolby e is the app violating it [18:29:04] <DonDiego> authors are always allowed to use their software in whatever ways they see fit [18:29:12] <DonDiego> url? [18:29:29] <kierank> http://neyrinck.com/Pages/scde.html [18:29:39] <kierank> adds mxf support, which they don't mention is through libmxf [18:30:18] <kierank> would have been more fun if it was lavf though ;) [18:32:28] <DonDiego> indeed [18:48:19] <peloverde> gah, everytime I touch implicit signaling I want to stab myself in the eye [18:50:45] <iive> peloverde: you have only one eye left? [18:52:04] <saintdev> he stabbed the other one out working on SBR =p [18:53:31] <_av500_> no eye left for mp3pro then [18:55:37] <BastyCDGS> namaste [18:55:42] <BastyCDGS> how are u guys? [18:57:01] <jai> :) [19:00:10] <_av500_> slalom [19:02:56] <BastyCDGS> shalom ;) [19:03:42] <BastyCDGS> I am thinking of proper metadata handling [19:04:05] <BastyCDGS> does ffmpeg charset conservations from any source? [19:04:26] * mru fails to be enthused by metadata [19:04:29] <BastyCDGS> thing is that IFF files can have a CSET chunk which tells which charset to use... [19:05:15] <BastyCDGS> the other thing is that our method fails when a \0 appears in IFF chunk [19:05:28] <BastyCDGS> because it used C-style strings which terminate at \0 [19:05:54] <BastyCDGS> if someone stores an UTF-16 or similar then we truncate after first char on little endian [19:06:26] <BastyCDGS> oh not just le on any endianess [19:06:37] <drv> metadata must be stored as utf-8 according to the api [19:06:48] <drv> see avformat.h [19:07:03] <BastyCDGS> that sounds really good, but are there converters for alien charsets to utf-8 [19:07:09] <BastyCDGS> i.e. not just native to utf-8 [19:07:10] <drv> that i do not know :) [19:08:08] <BastyCDGS> there's always recode etc. [19:08:15] <BastyCDGS> but that means dependency of external lib [19:20:59] <elenril> BastyCDGS: there's GET_UTF16 macro [19:21:34] <elenril> but that's all [19:22:09] <BastyCDGS> so what I should do then about charset conversation? [19:22:37] <CIA-7> ffmpeg: alexc * r23014 /trunk/libavcodec/ (aacsbr.c sbr.h): 10l: The SBR refactor requires the use of 2 independent output X buffers. [19:23:14] * elenril would ignore them ;) [19:23:55] <BastyCDGS> I can store the original charsets in UTF-8 though, but what to do with \0? [19:24:29] <wbs> do you have a concrete case where you've got strings that contain null bytes that you absolutely must have represented here? [19:25:34] <BastyCDGS> no, I just generally was thinking about this. [19:28:54] <ramiro> huh? online movie rental through download? how are they supposed to keep you from pirating it? [19:29:21] <mru> some kind of encryption I guess [19:30:19] <mru> sony are doing it on ps3 [19:30:43] <ramiro> seems to me that if you have some data and some decryption key, you should always be able to decrypt it. [19:30:56] <ramiro> there would be no restriction of when you can decrypt [19:31:11] <mru> depends on the platform you're on [19:31:13] <mru> on a pc, sure [19:31:13] <BastyCDGS> mru, have you any ideas about dp24? [19:31:17] <BastyCDGS> dp32 [19:31:21] <mru> the ps3 is different [19:31:32] <mru> you can't run whatever software you want on it [19:31:38] <ramiro> hm, makes sense. it's for pc in this case (some brazilian book store) [19:33:30] <mru> then you can of course break it [19:38:34] <ramiro> apparently it uses Microsoft's PlayForSure [19:38:40] <mru> lol [19:38:58] <ramiro> some microsoft drm something... [19:39:13] <wbs> wasn't that their drm that they didn't support on their own zune? :-) [19:40:01] <BastyCDGS> PlayForSureOnDevNull ;) [19:40:16] <ramiro> wbs: wikipedia seems to confirm [19:41:39] <ramiro> 1.5 mbps wmv and stereo audio. [19:49:06] <BastyCDGS> mru, could you verify the be/le issue with rawvideo? [20:05:46] <_av500_> ramiro: m4 drm is used for video rentals [20:05:50] <_av500_> err, m$ drm [20:05:57] <_av500_> wmdrm 10 aka janus [20:05:58] <mru> m4 drm is used by autoconf [20:06:03] <_av500_> yes [20:06:03] <ramiro> lol [20:06:27] <mru> got that tegra running properly btw [20:06:43] <_av500_> k [20:06:50] <_av500_> i will see one tomorrow it seems [20:06:57] <_av500_> will try to grab it [20:07:01] <_av500_> and run [20:08:56] <mru> their ancient 2.6.29 kernel feels modern compared to the 2.6.22 I was battling yesterday [20:09:00] <mru> stupid sigma [20:11:05] <_av500_> vendor kernels ftw [20:11:53] <mru> oh well, I accomplished what I wanted [20:12:17] <_av500_> one would be surprised that .22 still runs todays binaries.... [20:12:23] <mru> it doesn't [20:12:29] <_av500_> oh well [20:12:43] <mru> had to force an old version of linux-headers [20:13:00] <mru> since I'm building everything myself it's not a problem [20:14:28] <mru> the omap3 runs ffmpeg much faster [20:14:40] <mru> might have something to do with neon... [20:14:53] <_av500_> what the sigma running? [20:15:05] <mru> mips 74kf [20:15:10] <mru> 660MHz [20:15:23] <mru> beagle @ 600 is 1.5-4x faster [20:15:43] <mru> but then again, we barely have any mips asm at all [20:16:03] <_av500_> popcorn? [20:16:12] <mru> ack [20:17:08] <_av500_> dammit, i enter mips 74kf into google and it finds your blog post... [20:17:25] <_av500_> they might be evil, but they are good [20:17:26] <_av500_> :) [20:31:21] <spaam> mru: fix some mips asm then :) [20:41:23] <DonDiego> i have a question about the 'inline' keyword [20:41:38] <DonDiego> is it wise to mark functions as inline nowadays? [20:41:45] <Dark_Shikari> don't see why not [20:42:55] <BastyCDGS> I still use inline keyword to strongly recommend the compiler to inline a function [20:43:12] <DonDiego> i thought common wisdom was to let gcc take those decisions nowadays.. [20:43:46] <DonDiego> and that later in the 4.x series gcc actually got reasonably good at inlining decisions [20:44:03] <Dark_Shikari> ALWAYS_INLINE is more useful [20:44:37] <BastyCDGS> gcc does this, but using inline higher prioritizes it a bit... [20:44:47] <DonDiego> i'm not talking about ffmpeg but in more general terms now [20:44:56] <Dark_Shikari> same here [20:45:00] <BastyCDGS> yep [20:45:08] <DonDiego> ok [20:45:46] <BastyCDGS> I use such keywords however, to indicate less quality optimizing compilers what they should do [20:49:46] <mru> inlining of non-marked funcs depends on -O level iirc [20:50:56] <peloverde> I got a huge speedup in aac main inlining a function that gcc should have been smart enough to inline on it's own [20:51:46] <BastyCDGS> I also got different speed results when using inline while we tried dp8 optimization [20:52:30] <DonDiego> k [20:58:41] * Kovensky usually puts inline on functions he expects to be inlined [21:08:36] <DonDiego> offtopic: http://www.youtube.com/watch?v=cL2QyGD1oMI [21:08:46] <DonDiego> the bane of my childhood memories [21:09:13] <DonDiego> we would go visit my uncle and aunt in paris [21:09:19] <BastyCDGS> good night guys, have to get some sleep now [21:09:40] <DonDiego> and when the kids my cousin played with heard my name, they started singing the song from this commercial.. [21:10:34] <BastyCDGS> wow [21:10:44] <BastyCDGS> nice video [21:21:35] <spaam> DonDiego: you like that song ? :) [21:22:28] <DonDiego> i hate it of course! [21:22:45] <DonDiego> it was the bane of my visits to my cousin [21:22:56] <DonDiego> well, actually nowadays it's funny.. [21:41:07] <BBB> holy shit, I'm installing xbmc and it really is like an identical twin of gstreamer, it wraps everything, I mean seriously EVERYTHING [21:41:26] <BBB> it links against all kind of libraries that provide duplicate functionality with ffmpeg [21:41:35] <BBB> it's a little weird that they don't know that [21:41:40] <_av500_> its wrappers all the way down [21:42:06] <BBB> doesn't that make you cry? [21:42:14] <BBB> I mean imagine you're on a mac, which doesn't come with any of these deps [21:42:20] <BBB> I've been sudo port install'ing for 2 days now [21:42:27] <BBB> and I'm still not at a stage where configure finishes [21:43:38] <_av500_> :) [21:44:01] <_av500_> i know, one of the xbmc guys is doing gsoc for beagle [21:44:16] <_av500_> and koen tried to cross build xbmc [21:44:30] <_av500_> the list of deps was impressive [21:44:53] <peloverde> I looked at xmbc and decided it looked like a disaster [21:45:06] <peloverde> in particular the whole "PAPlayer" vs "DVDPlayer" thing [21:45:12] <_av500_> yeah [21:45:26] <_av500_> but u know, paplayer can wrap dvdplayer [21:45:43] <_av500_> or was it the other way round [21:47:59] <peloverde> The documentation says that it falls back to DVDPlayer if PAPlayer can't play the file [21:50:13] <_av500_> dunno the details [21:50:28] <_av500_> but they have faad, vorbis, mad AND lavc [21:50:48] <BBB> what's paplayer? [21:50:57] <peloverde> http://wiki.xbmc.org/index.php?title=PAPlayer [21:51:01] <_av500_> the audio player of xbmc [21:51:09] <BBB> and what's dvdplayer? [21:51:28] <mru> _av500_: correction: the ffmpeg list of deps is impressive [21:51:35] <peloverde> the video player part of xbmc [21:51:43] <BBB> because it's minimal? :) [21:51:47] <mru> any troll can write an app that uses at least one function from every lib he has heard of [21:51:48] <BBB> ffmpeg is impressive. period. [21:51:50] <mru> in fact, many do [21:52:24] <BBB> yeah [21:52:28] <BBB> xbmc uses liblzo [21:52:35] <_av500_> gee, liba52, alac, libdca, libflac [21:52:48] <twnqx> all only if wanted! [21:53:01] <_av500_> dead or alive [21:54:02] <peloverde> My question is if they use lavc why do they need all the one codec libs, do they all offer significant features that are missing in lavc [21:54:20] <kierank> nothing can be as bad as k-lite [21:54:53] <kierank> adds an extra ac-3 decoder because of "bugs" in ffmpeg. Same with mpeg-2. Guy who runs the codec pack doesn't want to reveal said bugs :/ [21:56:29] <peloverde> meh, xbmc has external mpeg-2 and ac-3 and a ton more [21:57:18] <CIA-7> ffmpeg: stefano * r23015 /trunk/libavutil/ (error.c error.h): [21:57:18] <CIA-7> ffmpeg: Make av_strerror() print an error message mentioning the error code [21:57:18] <CIA-7> ffmpeg: number if strerror_r() did not succeed for whatever reason. [21:57:18] <CIA-7> ffmpeg: This avoids the need for the application to fill the string in case [21:57:18] <CIA-7> ffmpeg: strerror_r() fails, for example because the error code is not known. [21:57:28] <kierank> the k-lite guy also adds ACM and VCM versions where available for some bizzare reason [21:57:40] <Dark_Shikari> because more codecs is better!! [21:58:01] <BBB> well [21:58:01] <BBB> k [21:58:02] <BBB> ie [21:58:04] <BBB> oops [21:58:07] * BBB kicks irc client [21:58:31] <BBB> kierank: it's true that I've seen in the past that if you incorrectly used the mpeg video parser with the ffmpeg decoder, it'd lead to very weird behaviour [21:58:37] <BBB> I figured out a fix after a while [21:58:42] <BBB> but that could well be what he's seeing [21:58:46] <peloverde> even VLC requires MAD to be explicitly disabled [21:58:47] <BBB> it's simply incorrect use of api [21:59:03] <BBB> several people have said mad is qualitatively better than ffmpeg [21:59:09] <BBB> that is a good reason [21:59:27] <BBB> mp3 is still the biggest codec in the world [21:59:30] <peloverde> based on what? [21:59:37] <peloverde> do we not conform? [21:59:47] <BBB> we're fixedpoint, mad is floatingpoint? I dunno [22:00:09] <DonDiego> mad is fixedpoint [22:00:10] <kierank> have listening tests been done? [22:00:20] <DonDiego> slower than ffmpeg though [22:00:51] <mru> mp3 is so shit the quality of the decoder is irrelevant [22:00:54] <peloverde> strict metrics of conformance should be used, not vague sounds better [22:01:29] <mru> mad decodes to 32-bit and downscales to 16-bit with some dithering [22:01:32] <astrange> mad is fixedpoint and decodes more bits than ffmp3 [22:01:36] <mru> that's the only difference I know of [22:01:42] <mru> fixed or float is irrelevant [22:01:47] <mru> ffmp3 is fixed-point too [22:02:31] <BBB> ffmp3 is 16bit? [22:02:31] <mru> and much faster than libmad on many machines [22:02:42] <mru> ffmp3 doesn't dither [22:02:45] <mru> afaik [22:02:51] <BBB> but is is 32 or 16bit? [22:03:01] <mru> it uses more than 16 bits internally [22:03:05] <mru> output is always 16 [22:03:11] <mru> mad can output 24 bits [22:03:12] <BBB> hm... [22:03:32] <mru> but we could just slap 8 random bits after those 16 and call it 24 [22:03:36] <mru> nobody would notice [22:03:41] <mru> seriously [22:03:59] <astrange> mad outputs 28 bits in 32 bits, i think [22:04:06] <mru> 28, lol [22:04:30] <mru> most people can't even hear 16 bits worth of precision [22:04:37] <mru> and nobody can hear more than 20 [22:05:01] <kierank> [23:04] <@mru> but we could just slap 8 random bits after those 16 and call it 24 --> do that in audiphile_kiddy_mode [22:05:09] <peloverde> when most mp3 is from cd source at best, more than 16-bits is completely irrelevant [22:05:42] <peloverde> VLC also requires liba52 [22:06:22] <peloverde> is something broken about ffa52? [22:07:16] <kierank> ask j-b [22:07:22] <janneg> it's quieter [22:08:07] <peloverde> quieter? [22:09:32] <CIA-7> ffmpeg: rbultje * r23016 /trunk/libavcodec/iff.c: Revert r22974 int->unsigned parts that don't have any meaningful effect. [22:09:33] <peloverde> Is it quieter than the a52 spec? or is liba52 lounder than the a53 spec? [22:09:46] <peloverde> or does one of them ignore some sort of mixing/gain control metadata [22:13:33] <janneg> 5.1 -> stereo downsampling. I think liba52 is louder, ffa52 downsampling is spec conformant afaik [22:14:22] <j-b> peloverde: ping [22:14:38] <j-b> peloverde: IIRC, we use liba52 for some weird reasons about SPDIF [22:14:56] <j-b> and liba52 in vlc is not exactly used as a codec, but a "converter" [22:15:02] <j-b> same goes with libdca [22:15:56] <j-b> janneg: I don't see any difference now between liba52 and ffa52, but I can retry with VLC 1.1.0 and my 5.1 and 2.0 setup, if someone needs it. [22:16:30] <j-b> and I haven't followed the discusion so far, so, pelase sorryr :) [22:17:17] <mru> when sending ac3 directly to spdif, you don't need any decoder [22:18:09] <janneg> j-b: that's in mythtv. and I haven't checked in a long time [22:18:28] <janneg> you still need a parser [22:18:33] <j-b> yes [22:19:03] <j-b> I am clearly not saying it is the best solution now, I am just stating a fact. [22:19:18] <j-b> and trying to explain it. [22:19:48] <mru> liba52 doesn't provide a parser [22:20:02] <mru> there's a function to parse a frame header, sure [22:20:02] <_av500_> j-b: you got a beer drinking vlc meeting tomorrow night? [22:20:10] <mru> but you have to do all the frame splitting yourself [22:20:19] <j-b> _av500_: nope [22:20:22] <_av500_> dmn [22:20:32] <mru> _av500_: going to paris? [22:20:39] <_av500_> i am [22:20:40] <j-b> _av500_: but we can drink one [22:20:55] <_av500_> im in paris now [22:20:58] <_av500_> and tomorrow [22:21:17] <_av500_> j-b: i will ping you, need to know if boss has special plans [22:21:30] <j-b> cool, please do... [22:21:36] <_av500_> j-b: where are you in paris? [22:21:39] <j-b> vitor is in paris too, right? [22:21:48] <j-b> _av500_: mostly east of Paris [22:22:19] <_av500_> mru: get a cheap flight, there is still time, i know that irish pub... [22:23:08] <mru> hehe [22:26:04] <mru> £150 is the cheapest return... [22:27:21] <_av500_> a steal [22:27:30] <mru> expensive beer [22:28:07] <BBB> holy shit xbmc is a wrapper of everything [22:28:20] <mru> does it wrap itself? [22:28:21] <_av500_> didnt you say that already [22:28:22] <BBB> I should tell some phycisists about this, this could be what they've been looking for for ages [22:28:28] <_av500_> lol [22:28:29] <BBB> IT'S STILL CONFIGURING [22:28:44] <_av500_> is it NP complete? [22:28:55] <BBB> this is so complex, it might pass the turing test [22:29:10] <BBB> I mean, for every file you throw at it, it has so many decoders it can decode it with [22:29:16] <_av500_> speak slowly to it [22:29:18] <BBB> that's almost intelligent [22:31:52] <BBB> omg it compiles every submodule with -lmysqlclient [22:32:06] <BBB> EVEN FFMPEG AND ALL ITS INTERNAL CODECS [22:32:14] <BBB> (like dts/a52/etc.) [22:33:44] <j-b> BBB: mplayer, ffmpeg, flash, some part of xine, some parts of vlc, now their own decoder engine, some dshow loader from gstreamer [22:33:57] <j-b> and now, Boxeee is even worse [22:34:10] <BBB> the dshow loader from gst that I took from xine? [22:34:16] <BBB> (I wrote that :) ) [22:34:26] <BBB> that is hilarious [22:34:42] <BBB> you know it plays only 3 codecs: wmapro, wmavoice and qdm2 [22:34:51] <BBB> all of which are now in ffmpeg :) [22:35:06] <peloverde> BBB, ffqdm2 is a little fuzzy [22:35:06] <BBB> oh, and some video codec [22:35:14] <BBB> I think it does vc1 also [22:35:17] <BBB> which ffmpeg also does [22:35:40] <j-b> astrange: where is the official source of ffmpeg-mt? We have enabled it in VLC;.. [22:36:44] * BBB kicks xbmc [22:36:49] * j-b lols [22:36:51] <BBB> stupid system can't deal with spaces in filenames [22:37:08] <BBB> my dir was called "source full", and it fails on "cp" somewhere because it got 3 arguments [22:37:27] <BBB> maybe I should report bugs to them [22:37:49] <astrange> http://gitorious.org/~astrange/ffmpeg/ffmpeg-mt [22:37:59] <astrange> i haven't integrated that patch you gave me yet :/ [22:38:04] <j-b> astrange: no need :D [22:38:23] <j-b> astrange: no more patching of ffmpeg-mt, just the normal one + vlc git master [22:38:33] <j-b> astrange: cleaner patch :) [22:38:58] <j-b> astrange: I have around 20% speed-ups here, no idea if it is normal or not [22:39:32] <astrange> usually more if you're decoding as fast as possible [22:39:51] <j-b> ok. Still testing it. [22:42:32] <BBB> omg configure finished \o/ [22:42:39] <BBB> that took only 3 days [22:42:46] <BBB> let's see how often make bails out [22:42:47] <BBB> ... [23:28:09] <peloverde> Is there a nice way in git to fastforward an inactive (not currently checkedout) branch to a commit? [23:28:55] <Dark_Shikari> mru: ping [23:29:03] <mru> peloverde: git branch -f [23:29:04] <mru> Dark_Shikari: pong [23:29:36] <Dark_Shikari> Should the ipad (1ghz ARM Cortex-alike) be able to decode h264 realtime at 1024x768? [23:29:39] <Dark_Shikari> with ffmpeg [23:30:21] <mru> might depend on encoding parameters and memory speed [23:30:36] <mru> give me a test file and I can try on a 1GHz cortex-a8 [23:30:41] <peloverde> gratzi [23:48:37] <DonDiego> gnite [23:49:40] <peloverde> WTF C++ https://connect.microsoft.com/VisualStudio/feedback/details/520043/error-co… [23:52:04] <Dark_Shikari> mru: I just upscaled some representative content from 800x600 [23:52:06] <Dark_Shikari> should be good enough [23:52:15] <Dark_Shikari> the people testing this were reporting decoding times per frame around 60ms [23:52:20] <Dark_Shikari> which seems a bit high [23:52:55] <Dark_Shikari> I also wonder how coreavc performs by comparison [23:53:01] <Dark_Shikari> especially given our extremely specific requirements [23:53:25] <Dark_Shikari> mru: http://mirror05.x264.nl/Dark/test.h264 [23:53:37] <Dark_Shikari> contains a mix of zero-motion and high motion [23:53:45] <Dark_Shikari> I would assume that if something lags, it's going to be the high motion. [23:54:24] <Dark_Shikari> hmm, oops, forgot the multislicing. [23:54:25] <Dark_Shikari> brb [23:55:25] <Dark_Shikari> I heard you like frames with 81 slices [23:55:38] <mru> huh? [23:55:48] <Dark_Shikari> the first frame in the clip I'm uploading has 81 slices [23:57:08] <Dark_Shikari> ok, http://mirror05.x264.nl/Dark/test.h264 is up [23:57:31] <mru> Too many slices, increase MAX_SLICES and recompile [23:58:47] <mru> why so many slices? [23:59:52] <mru> ok, rebuilt with MAX_SLICES=128

1 0

IRC log for 2010-05-02
by irc＠mansr.com 03 May '10

03 May '10

[00:15:25] <Kovensky> _av500_: lol [00:15:39] <Kovensky> (and sure is late lol) [00:16:37] <mru> trololol [03:54:12] <Kovensky> why do sun people top-post :( [03:54:38] <Dark_Shikari> why does the pope shit in the woods? [03:54:43] <Kovensky> lol [03:54:50] <Kovensky> MAKES SENSE [03:55:21] * Kovensky forgot that not everyone is sane in the internet and uses inline-post [03:56:57] <ohsix> they miss the point of discussion and treat email like instant messenger :] [03:58:21] <Kovensky> heh [03:59:00] <Kovensky> another frequent thing: not snipping out the parts of the message you're not commenting on [03:59:24] <Kovensky> like top-posting and including the entire contents of the previous message quoted D: [04:02:33] <ohsix> some business types do that to keep a running log of whats been in a token ring type email discussion too; no archives or whatever for context [04:06:26] <Kovensky> http://arc.opensolaris.org/caselog/PSARC/2009/571/mail <-- you can see a lot of top-posting here :( [04:06:30] <Kovensky> and a few inline posters [04:07:01] <Kovensky> and I just saw an inline poster that didn't crop off the parts of the message it didn't comment on ;v [04:07:24] <Kovensky> meh, I'll just sleep [04:08:47] <ohsix> there a special type of top poster that doesn't even read what he's commenting on, too :] [06:22:03] <_av500_> gee, forget theora, mjpeg is the one to use: http://www.osnews.com/story/23236/Why_Our_Civilization_s_Video_Art_and_Cult… [06:22:45] <Dark_Shikari> lol [06:22:50] * _av500_ waits for libaa being advocated for free video [06:23:15] <ohsix> ttyrec 4 lif [06:31:10] * saintd3v patents libaa [06:31:12] <saintd3v> muhahaha [06:35:54] <saintd3v> good thing the uspto doesn't seem to care about prior art for software patents, hehe [07:05:13] <pJok> _av500_, libcaca... you need color once in a while ;) [07:27:08] <_av500_> pJok: no can do, i bet ansi codes are patented too... [07:29:27] <pJok> but that is what my terminal on my phone runs... [07:29:52] <_av500_> your freephone? [07:30:00] <pJok> no [07:30:03] <pJok> its covered in patents [07:30:19] <pJok> it even plays h264 [07:30:23] <pJok> err [07:30:24] <pJok> no [07:30:27] <pJok> mpeg4 only [07:30:29] <_av500_> see [07:30:41] <pJok> and of course 3gpp [07:31:09] <_av500_> we need video on freephones, made from sticks and strings only [07:31:29] <pJok> but strings and sticks are probably also patented [07:33:17] <saintd3v> _av500_: don't let apple know you're using sticks and strings, they'll come after you with lawyers [07:35:39] <_av500_> i [07:35:45] <_av500_> iGiveUp [07:36:16] <saintd3v> sorry, that is trademarked [07:36:16] * pJok has patented _av500_ [07:36:47] <ohsix> still, its a civil action to defend it [07:36:52] <ohsix> fight! [07:37:04] <saintd3v> ohsix: mortal kombat? [07:37:37] <ohsix> depends on the judge [07:37:59] <ohsix> it gets pretty wild in that patent troll jurisdiction in texas [07:38:36] <_av500_> tell me about it... [07:38:44] <pJok> i think all patents filed after something already was in use by others should be invalidated [07:39:12] <ohsix> thats the vaunted ideal [07:40:01] <ohsix> but the people accepting them don't have the capacity to do more than trivial rejection & prior art [07:40:24] <ohsix> the inventors prior art is sometimes all they look at if its in the filings [07:41:49] <ohsix> incumbent ip interests can flood them with applications for very small novelties and a certain percentage will make it no matter what; then they get down finding a way to extort people with them [07:41:53] <_av500_> we once fought a patent on a "box that has 2 connectors and converts signals between them" [07:42:33] <saintd3v> lol [07:42:33] <ohsix> did you lose? man theres only so many ways you can have a box yo [07:43:01] <_av500_> luckily our box had one connector on an attached cable.. [07:43:13] <ohsix> it would be cool if the process was merit based, but the applications are mostly treated in isolation [07:55:09] <pJok> _av500_, that is when you put a second connector on it [07:55:21] <pJok> gotta love patent trolls [08:06:54] * _av500_ patents love trolls [11:46:41] <mru> Dark_Shikari: what bs is this? http://news.ycombinator.com/item?id=1312344 [13:05:46] <_av500_> mru: its bs [13:06:23] <_av500_> afaik, anybody can get that by sending an email to mpegla [13:06:24] <mru> I thought the licence terms for h264 had been public all the time [13:09:24] <_av500_> i think ppl thought the terms were patented too and never bothered to have a look [13:10:01] <mru> if you're afraid what you see will contradict your position, better not look [13:10:42] <_av500_> if you're afraid what you see will contradict your position, burn it at a stake [13:10:49] <_av500_> on a stake? [13:11:13] <janneg> the can't be that secret if mpeg-la sends them to people without prior contact [13:11:44] <mru> steak... [13:11:54] <_av500_> right [13:12:20] <_av500_> janneg: i bet they send it to everybody that ask and has a non-aol email address [13:12:23] <mru> can I have my licence medium rare, please [13:13:15] <janneg> _av500_: or hotmal. afaik diego got them after asking per mail [13:14:02] <pross-au> discussions over patents and licensing should be banned. they just destroy productivity. [13:14:13] <_av500_> janneg: psst, dont tell [13:14:25] <_av500_> pross-au: no, they are cheap entertainment [13:14:36] <kshishkov> pross-au: agreed [13:16:13] <pross-au> better to put your energy into building a better codec [13:16:29] <pross-au> if there was a better codec then h264 available, we wouldnt be having this dicussion. [13:19:21] <_av500_> there will be h265, the race between mpeg and xiph to create it is on.. [13:32:51] <Kovensky> "If this license was a computer program I'd have to class it as spaghetti code." <-- *this* license? what other non-WTFPL or non-BSD license can you classify as non-spaghetti [13:33:33] <mru> none [15:20:04] <_av500_> ah, fsf is aiming at the consumer vs commercial thing [16:08:20] <CIA-7> ffmpeg: reimar * r23009 /trunk/libavcodec/avcodec.h: [16:08:20] <CIA-7> ffmpeg: Clarify how allocation works for the picture argument for [16:08:20] <CIA-7> ffmpeg: avcodec_decode_video3. [16:17:03] <tetsuo55> hello [16:19:48] <tetsuo55> KindDragon helped make a patch for a problem i have with the debug build of mpc-hc [16:19:49] <tetsuo55> https://sourceforge.net/apps/trac/mpc-hc/changeset/1830 [16:20:09] <tetsuo55> i'm not exactly sure how it works or what it fixes but all problems disapear with it [16:20:55] <tetsuo55> does the patc make any sense to you guys? [16:21:48] <mru> no [16:23:17] <mru> that condition can never occur [16:23:58] <mru> the for loop runs twice, each time nb_codes iterations [16:24:47] <mru> in each iteration, j is incremented only if the condition is true [16:24:55] <iive> tetsuo55: what compiler are you using, what arch (32/64) and have you tried to make that condition into assertion, aka break into debugger. [16:25:15] <mru> the two instances of the loop have complementary conditions, so j can never reach nb_codes [16:25:56] <tetsuo55> ok i found out some more, this patch makes ffmpeg compilable with msvc (there are some other patches too that where already applied before) [16:26:12] <mru> that patch does neither this nor that towards building with msvc [16:26:22] <KindDragon> crash occur with only several files http://rd.yahoo.co.jp/tokushu/5cm/teaser01/?http://i.yimg.jp/images/evt/5cm… [16:26:37] <tetsuo55> without the patch msvc throws a runtime error during compile [16:26:51] <mru> well, msvc is known not to be a compiler [16:26:52] <tetsuo55> or playback [16:26:53] <tetsuo55> lol [16:27:18] <tetsuo55> KindDragon please explain in a little more detail [16:27:37] <KindDragon> Run-Time Check Failure #4 Stack area around _alloca memory reserved by function is corrupted [16:28:08] <Yuvi> llvm writes beyond the vla too, but it didn't seem possible from the code [16:28:30] <KindDragon> Sometimes j become equal nb_codes in COPY(buf[j].bits && buf[j].bits <= nb_bits) [16:29:08] <mru> gaaaah, how did that vla get there!?!?!?? [16:29:19] <mru> haven't I told you they're evil? [16:30:03] <iive> there is something i don't get, the COPY macro is called twice, but j is zeroed only once [16:31:12] * Kovensky pats mru [16:31:29] <mru> Kovensky: if you want to please me, get rid of that vla [16:32:17] <tetsuo55> so there is a real bug of sorts there? [16:32:24] <mru> in the compiler, yes [16:32:39] <mru> VLAs are unfortunately part of the C standard [16:32:45] <tetsuo55> ok [16:32:52] <mru> no, that's not ok at all [16:33:17] <tetsuo55> ofcourse, just ok to your response [16:36:23] <iive> mru: in that code, i see that j is zeroed, then COPY is called once, at exit j==nb_codes, then there is qsort, and then copy is used again, without j been zeroed. is this how it should be done? [16:36:49] <mru> the loop counts until _i_ reaches nb_codes [16:37:17] <mru> j is only incremented when the condition in the macro invocation is true [16:37:37] <mru> the two calls have almost complementary conditions [16:37:54] <iive> j is always incremented in the loop. [16:37:54] <mru> so it will be true less than nb_codes times [16:38:02] <mru> iive: is not [16:38:04] <iive> maybe i have old copy. let me svn up. [16:38:08] <mru> there's a continue there [16:38:22] <mru> line 304 in svn [16:39:18] * Kovensky wishes mailman included a link to the public archived version of each mail in the ML signature [16:39:22] <iive> i missed that. [16:39:44] <mru> hmm wait, maybe I'm stupid too [16:41:22] <mru> no, I'm not [16:43:31] <Yuvi> looks like it writes over the end of the vla in gcc too [16:43:42] <mru> Yuvi: how is that possible? [16:45:22] <Yuvi> dunno, but http://pastie.org/942540 doesn't print the expected values [16:52:46] <Yuvi> the GET_DATA() before the condition check? [16:52:59] <mru> what of it? [16:53:19] <Yuvi> can't that run after j == nb_codes from a previous iteration [16:53:20] <Yuvi> ? [16:54:18] <mru> hmm, if all the values pass the first condition, yes [16:54:34] <KindDragon> yes, rewriting stack in for (i = 0; i < nb_codes; i++) {\ [16:54:36] <KindDragon> GET_DATA(buf[j].bits, bits, i, bits_wrap, bits_size);\ [16:54:40] <KindDragon> in GET_DATA [19:00:13] <CIA-7> ffmpeg: cehoyos * r23010 /trunk/configure: Allow to set archiver tool ar. [21:40:46] <mru> siretart: ping [21:53:16] <CIA-7> ffmpeg: rbultje * r23011 /trunk/libavcodec/wmavoice.c: Another buffer overflow, fixes issue1758.

1 0

IRC log for 2010-05-01
by irc＠mansr.com 02 May '10

02 May '10

[01:31:46] <saintdev> peloverde: i saw aacsbr and got all excited. [01:31:51] <saintdev> then i looked at the commits =p [02:12:11] <kierank> hmmm I wonder if any StreamStacker samples exist [02:31:59] <Compn> did anyone look into the ivr or whatever format that realplayer creates ? [02:48:20] * Compn finds sample [02:49:38] <Compn> KotH / mru and all devs in here : /incoming/ currently has 18mb free... [02:50:37] <saintdev> hurry, fill it up!! [02:53:25] <Compn> lol [03:14:01] <Compn> -rw-rw---- 1 mplayer ftp 389513326 Apr 16 23:30 source.zip [03:14:12] <Compn> xbmc svn snapshot?? [03:21:12] <saintdev> lol [03:54:58] <Compn> realplayer ivr samples moved to samples/real/ivr [03:55:03] * Compn sleeps [05:11:11] <Dark_Shikari> oprofiled: couldn't re-open stdout: : No such file or directory [05:11:15] <Dark_Shikari> WHAT THE FUCK? [05:14:05] <Dark_Shikari> apparently if you delete its samples folder it won't recreate it [05:14:14] <Dark_Shikari> and if you try to O_CREAT a file inside a folder that doesn't exist, open() fails [05:18:58] <hyakki> under mingw im not getting a shared file all i get is libavcodec.a shouldn't i get libavcodec.al ? [05:20:01] <hyakki> libavcodec.la* [05:28:07] <ramiro> hyakki: don't mention the l word in this channel [05:28:29] <Dark_Shikari> LLAMA! [05:28:30] <Dark_Shikari> LLAMA! [05:28:43] <Dark_Shikari> (and go fetch me a shrubbery) [05:29:30] <hyakki> should i just rename the avcodec dll to libavcodec.dll ? [05:29:31] <ramiro> hyakki: ffmpeg has its own build system. for static libraries you get .a, for shared libraries (in mingw) you get .dll. [05:29:45] <ramiro> hyakki: why rename? [05:30:35] <hyakki> im trying to build xuggle and its complaining it cant find the shared library for libavcodec [05:31:18] <astrange> you need --enable-shared [05:32:12] <hyakki> i did but it doesnt output a libavcodec.dll just avcodec.dll [05:32:48] <ramiro> hyakki: and the question is why do you need it to be libavcodec.dll? [05:33:14] <ramiro> also this is xuggler specific, you should ask aclarke (seems he's not online though) [05:34:03] <hyakki> i get this http://pastebin.com/dyFWixg0 [05:34:39] <hyakki> so i assume its looking for libavcodec.dll [05:44:57] <ramiro> hyakki: are you following http://www.xuggle.com/xuggler/downloads/build.jsp ? [05:45:18] <hyakki> im doing this one http://www.xuggle.com/xuggler/downloads/advbuild.jsp [05:45:42] <hyakki> i want an independent version of ffmpeg to use with xuggle [05:46:02] <ramiro> that's weird. I thought xuggle used ffmpeg.exe, not its libraries... [05:48:33] <hyakki> yea their ffmpeg has to much in it so i was trying to make a smaller ffmpeg to use with it ...anyways when you build with --disable-captives it should let you use your own ffmpeg [05:49:07] <hyakki> and thats where im getting this problem , since libavcodec.dll doesn't exist [05:52:04] <hyakki> i think when ffmpeg installs it converts libavcodec.dll.a to avcodec-52.dll , but i could be wrong [05:54:04] <ramiro> hyakki: libavcodec.dll.a is different from avcodec-52.dll. a dll is a shared library (with the actual code), a dll.a is an import library. [05:55:50] <hyakki> hm so should ffmpeg output a dll or la for libavcodec? maybe it is a ffmpeg problem after all [05:58:03] <hyakki> its outputting all the other dll files but for all the lib* files it only outputs lib*.dll.a, i did everything it said im even using the ms lib tool from vs2010 [06:47:20] <_av500_> happy mayday [07:02:15] <kshishkov> _av500_: and you do know what actually "mayday" means, I'm sure [07:04:47] <pJok> kshishkov, örebro->landskrona takes quite a long time [07:04:52] <pJok> so far 9 hours [07:05:07] <pJok> but then again, breaking down on the motorway doesn't really help [07:05:14] <kshishkov> huh? [07:05:48] <kshishkov> can't you hire a pack of donkeys? [07:07:05] <pJok> hehe [07:07:15] <pJok> im just waiting for a towtruck [07:22:24] <_av500_> kshishkov: indeed i do [07:22:44] <_av500_> are you going to the demonstration like a good comrade? [07:22:49] <kshishkov> nope [07:23:10] * kshishkov wonders why Germans decided that red banners are good for warding off spirits [07:23:47] <_av500_> huh? [07:25:17] <kshishkov> why else Walpurgisnacht is ended with demonstration (with red banners)? [07:26:43] <kshishkov> and don't say it was different in Yugoslavia [07:26:59] <_av500_> never been there on may 1st [07:27:04] <_av500_> :) [07:27:12] <kshishkov> and will never be [07:27:29] <_av500_> sniff [07:28:42] <kshishkov> well, in Ukraine this day is usually celebrated by going to countryside and planting potatoes or whatever [07:30:09] * _av500_ could plant tomatoes today.. [07:30:33] <kshishkov> yes, whatever [07:41:55] <kshishkov> mate! [07:42:06] <pross-au> Evening [07:42:31] <kshishkov> not here though [07:43:02] <kshishkov> es ist einen Morgen hier [07:43:23] <pross-au> Breakfast? [07:43:56] <kshishkov> maybe that too [07:47:11] <pross-au> Might go get some fish & chips [07:48:45] <kshishkov> and prawn crackers [08:08:10] * kshishkov goes exploring city [08:25:16] <CIA-7> ffmpeg: stefano * r23001 /trunk/libavdevice/v4l2.c: [08:25:16] <CIA-7> ffmpeg: Make device_open() store the VIDIOC_QUERYCAP ioctl errno, and in case [08:25:16] <CIA-7> ffmpeg: of failure return the stored value rather than the current errno, [08:25:16] <CIA-7> ffmpeg: which may be overwritten by a following call to close(). [09:54:07] <hyakki> on configure can you comma seperate on each codec? ie --enable-decoders=aac,ac3 ..etc? [09:54:14] <hyakki> or ; [09:57:34] <spaam> , [09:58:30] <Tjoppen> morrn [12:23:17] <elenril> :nunmap can also be used outside of a monastery. << lol@vim manual [12:23:59] <kshishkov> indeed, some nuns are walking on the streets too [12:24:11] <kshishkov> and may need mapping too [12:27:30] * elenril wonders why is vim refusing to remap <S-F4/5> [12:28:13] <kshishkov> may be X11/terminal hook [12:29:08] * elenril tries in vt to be sure [12:29:32] <elenril> hmm, it seems you're right [12:29:45] <kshishkov> gnome-terminal sucks [12:29:49] * elenril blames urxvt [12:33:40] <elenril> where does X keep keycode mappings? [12:35:01] <kshishkov> summon mru from the depths of Hapshire to find out [12:35:06] <kshishkov> *Hampshire [12:45:07] <_av500_> kshishkov: met any natives? [12:45:37] <_av500_> (with red banners..) [12:46:17] <zorgy> hi guys [12:46:24] <zorgy> i added my email to the mailing list [12:46:30] <zorgy> but i didnt get a mail [12:46:47] <spaam> just wait and see [12:47:07] <zorgy> does it ussually take long? [12:47:13] <zorgy> i added it a couple of days ago [12:47:22] <kshishkov> _av500_: no, I was lucky (and far away from Weimar) [12:47:26] <twnqx> wtf [12:47:34] <twnqx> why is spaam in the -devel channel [12:47:49] <spaam> twnqx: oh hey charlie :D [12:47:59] <spaam> twnqx: did you miss me? [12:48:09] <twnqx> not at all [12:48:20] <spaam> zorgy: then something is wrong. did you type in the right mail? :) [12:48:22] <kierank> zorgy: double check the mailman settings [12:48:35] <spaam> twnqx: ohh :) i did [12:48:35] <zorgy> okay [12:48:38] <zorgy> thanks [12:54:15] <zorgy> hm okay ill try again [13:50:25] <CIA-7> ffmpeg: reimar * r23002 /trunk/libavformat/ (utils.c avformat.h): Export av_probe_input_format2. [13:53:35] <elenril> hmm, so there isn't a standard way to input shift+f* in terminal? [13:55:02] <CIA-7> ffmpeg: reimar * r23003 /trunk/doc/APIchanges: Document av_probe_input_format2 API addition. [13:55:43] <kshishkov> iirc, shift-fX is a standard way for inputting f(X+10) or something [13:56:37] <elenril> that's what urxvt does [13:57:04] <elenril> but apparrently vim expects <S-F*> to be something else [15:08:41] <kierank> hehe mpeg are making a royalty free video standard [15:10:50] <mru> link? [15:11:04] <kierank> http://www.robglidden.com/2010/04/mpeg-resolution-on-royalty-free-standardi… [15:37:40] <CIA-7> ffmpeg: reimar * r23004 /trunk/libavformat/avformat.h: [15:37:40] <CIA-7> ffmpeg: Fix off-by-one errors in description of score_max argument for [15:37:40] <CIA-7> ffmpeg: av_probe_input_format2 [17:22:36] <ramiro> is there anything similar to watermark for libavfilter yet? [17:25:42] <_av500_> isnt mpeg1 (video) royalty free these days? [17:28:18] <kshishkov> it is, for years IIRC [17:28:41] <kshishkov> and don't remind me about JPEG [17:29:31] <_av500_> so, why start an effort for a royalty free codec then, mpeg1 hd ftw [17:29:57] <kshishkov> nah, it won't burn CPU [17:30:11] <kierank> [18:28] <@kshishkov> and don't remind me about JPEG --> i'l remind you about jpeg2000 then [17:30:46] <kshishkov> kierank, remind jai about it [17:31:00] * kierank reminds jai [17:38:33] <peloverde> http://techcrunch.com/2010/05/01/h-264-66-percent-web-video/ [17:39:43] <kierank> lol encoding.com [17:41:55] <peloverde> hmm... mtv uses encoding.com, are they responsible for the shitty video quality? [17:42:19] <_av500_> gee, flv is not a codec.... [17:42:40] <kshishkov> and flv1 is not video [17:42:50] <mru> flv is a codec and a format [17:42:59] <_av500_> isnt is called sprak? [17:43:10] <mru> some call it flv [17:44:15] <peloverde> you mean spark? or is there a sprak? [17:44:20] <_av500_> peloverde: spark [17:44:30] <peloverde> I just call it h.263 :) [17:44:31] <kshishkov> sorenson spark aka fancy name for h.261 [17:44:47] <_av500_> and we transcode it to mpeg4 on the fly [17:45:24] <kshishkov> in your head? [17:45:38] <_av500_> no, in the product [17:45:41] <kshishkov> or simple bitstream translation? [17:45:44] <_av500_> yes [17:45:56] <_av500_> as our dsp codec would only do mpeg4 [17:47:05] <kshishkov> yes, I guessed that [17:47:30] <_av500_> there was some lib based on ripped out part of lavc i think [17:47:42] <kshishkov> shhh! [17:51:06] <peloverde> some new chrome patches have appeared: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches… [17:52:31] <_av500_> dirac? [17:52:54] <kshishkov> that's for <video country="uk" channel="bbc" > tag [17:53:27] <peloverde> dirac is so they can build the ogg demuxer without dirac support [17:53:42] <_av500_> ah [17:54:25] <peloverde> but hey according to monty all of ogg's codec specificness has hurt nobody [17:54:53] <kshishkov> go to xiph! [17:55:23] <_av500_> xiph off! [17:55:46] <kshishkov> I don't give a xiph about Monty [17:56:18] <_av500_> bloody xiph, neither do I [17:57:37] * kshishkov saw something like Xiph today [17:58:53] <peloverde> Anyway I've already fixed the SBR bugs they found [17:59:05] <peloverde> Somebody should look at the MKV buffer overflows [18:09:48] <Yuvi> #endof ? did they compile the patch [18:10:54] <_av500_> #the_world? [18:10:54] <peloverde> blol [18:11:22] <peloverde> they also attempted to turn it on in configure three times and failed [18:12:29] <peloverde> http://src.chromium.org/viewvc/chrome/trunk/src/third_party/ffmpeg/source/c… [18:13:52] <Yuvi> not sure why they disable lzo... [18:14:07] <Yuvi> did they disable it in lavu too? [18:14:22] <peloverde> no idea [18:26:00] <kierank> [18:41] <@peloverde> hmm... mtv uses encoding.com, are they responsible for the shitty video quality? --> probably [18:27:23] <kshishkov> it's funnier with YouTube - they have their own encoder [18:31:19] <elenril> how do you know it's not x264 btw? [18:32:05] <kierank> they are migrating to x264 [18:45:51] <CIA-7> ffmpeg: rbultje * r23005 /trunk/libavcodec/wmavoice.c: [18:45:51] <CIA-7> ffmpeg: Fix buffer overrun (or, well, actually a typo, 80 should be 0x80...). [18:45:51] <CIA-7> ffmpeg: Partially fixes issue 1758. [20:09:12] <zorgy> hi guys, i tried to reenter the mailing list [20:09:15] <zorgy> but i still cant join [20:09:18] <zorgy> i got no email [20:09:28] <zorgy> i tried two different email addresses [20:09:31] <zorgy> but i got not reply [20:10:05] <zorgy> theres nothign in my junk folder either [20:10:40] <mru> I see a hotmail address resembling your nick is marked pending [20:10:42] <zorgy> i went to https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel and entered my email address then clicked on subscribe [20:10:53] <zorgy> ahh okay [20:11:07] <zorgy> i sent it a couple of hours ago [20:11:51] <zorgy> it seems to have worked though :) thanks for the info [20:12:05] <mru> our mail server is having trouble sending to hotmail [20:12:14] <zorgy> ohh [20:12:55] <zorgy> will it work if i make a google account? [20:13:04] <mru> google should be fine [20:13:09] <mru> hotmail seem to be blocking us [20:13:11] <mru> again [20:13:15] <zorgy> hahaha [20:13:18] <zorgy> :) [20:13:25] <zorgy> okay ill retry with google [21:03:13] <CIA-7> ffmpeg: mstorsjo * r23006 /trunk/tools/qt-faststart.c: [21:03:13] <CIA-7> ffmpeg: Remove unnecessary checks before calling free [21:03:13] <CIA-7> ffmpeg: Feel free to revert if you can specify a concrete case where this actually [21:03:13] <CIA-7> ffmpeg: is necessary. [21:04:42] <CIA-7> ffmpeg: mstorsjo * r23007 /trunk/tools/qt-faststart.c: Reindent after the previous commit [21:06:19] <CIA-7> ffmpeg: mstorsjo * r23008 /trunk/tools/qt-faststart.c: qt-faststart: Free ftyp_atom at all exit points [21:14:21] <_av500_> so hotmail has troll filtering now? [21:18:28] <zorgy> h [21:18:31] <zorgy> ah nice [21:18:35] <zorgy> ive been accepted [21:18:41] <zorgy> google mail worked [21:20:25] * wbs awaits flames from people with libc not handling free(NULL) ;P [21:20:55] <wbs> from all 7 of them still alive [21:21:49] <iive> wbs: i thought windows is more popular... even if it is named win7 [21:23:45] <wbs> iive: I do think msvcrt handles free(NULL) [21:24:50] <iive> wbs: well, you'd better check all msvcrt versions there are, were, and have been.... and you never know for will be. ;) [21:25:55] * wbs eagerly awaits bug reports for such, then. :-)

1 0

IRC log for 2010-04-30
by irc＠mansr.com 01 May '10

01 May '10

[00:07:27] <CIA-7> ffmpeg: michael * r22991 /trunk/ffmpeg.c: Print warnig if requested samplingrate is unsupported. [05:05:08] <astrange> http://www.macroplant.com/adapter/ sent them an email asking them to not ship ffmpeg --enable-nonfree [05:05:22] <astrange> but i doubt i can convince them to not use faac so it's probably hopeless... [06:08:04] <benoit-> moin [06:08:15] <superdump> morning [07:31:27] <Tjoppen> morning [07:31:39] <kshishkov> god morgon [07:33:01] <av500> gm [07:33:05] <Tjoppen> valborg -> halvdag \o/ [07:34:05] <pJok> st. bededag -> holiday \o/ [07:34:26] <pJok> even though i live in sweden, im still bound by danish holidays [07:34:52] <av500> I feel for you [07:35:09] <pJok> hehe [07:35:10] <kshishkov> well, Germans invented International Workers Day too [07:37:35] <av500> yes, nice thing I can go shopping tomorrow... [07:37:38] <av500> err, can't [07:37:48] <kshishkov> av500: same here [07:38:17] <av500> so you can spend another full day in irc... [07:38:45] <av500> you have a place to stay yet? [07:41:17] <kshishkov> yes, of course [07:42:02] <av500> good :) [07:42:13] <pJok> we dont have that problem here in sweden [07:42:28] <pJok> i can shop every day with a few expeptions till 22 [07:43:03] <kshishkov> yes, I miss Sweden [07:43:12] <pJok> i think may 1st and december 24th+25th [07:43:19] <pJok> are the exeptions [07:43:28] <kshishkov> you can also add that you can shop starting at 7:00 and not from 8:30 like here [07:43:36] <pJok> yup [07:43:41] <pJok> not all shops open at 7 though [07:43:48] <kshishkov> yes [07:43:52] <pJok> and in weekends the centers open at 10 or 11 [07:44:02] <pJok> my local one opens at 8 [07:44:15] <pJok> but i know the ones in malmö open at 7 [07:47:58] * kshishkov still misses Sweden [07:48:26] <pJok> weren't you getting closer? [07:49:44] <kshishkov> by about 200km, yes [07:50:00] <kshishkov> I need about 7 more relocations ;) [07:50:05] <av500> :) [07:50:42] <av500> what radius of movement does you visa allow? [07:51:03] <kshishkov> I need a map to determine that [07:51:23] <kshishkov> from Spain to Finland, I guess [07:51:26] <av500> ok [07:51:48] <av500> kshishkov: will they let you go to linuxtag? [07:51:59] <kshishkov> I hope so [07:54:58] <KotH> greetings earthling [07:55:18] <kshishkov> greetings alien [07:56:42] * KotH zapps kshishkov with his catgirl ray [07:57:18] * kshishkov has builtin resistance [07:57:44] <KotH> against cat girls? i dont think so [07:58:15] <av500> I guess he throws balls of yarn as decoys [07:58:46] <kshishkov> KotH: I even won't even call any of my machines "natsuki" [07:59:18] * elenril always thought there's something wrong with kshishkov [07:59:40] <kshishkov> elenril: I'm Ukrainian, isn't that obvious? [08:00:10] <spaam> KotH: alien? that one was new.. [08:00:57] <kshishkov> spaam: de har "alien passport" i Estland och/eller Lettland [08:01:38] <spaam> kshishkov: haha. borde fixa till KotH dÃ¥ :) [08:01:49] <spaam> kshishkov: dÃ¥ han Ã€r en alien :) [08:03:15] * KotH used to have an alien registration card [08:04:12] <spaam> KotH: so kshishkov was right then :) [08:07:11] * KotH zaps spaam with his death ray [08:07:19] <KotH> you knew too much! [08:07:39] <spaam> ouch! [08:08:24] * av500 casts ash cloud over KotH [08:08:45] * KotH doesn't fly [08:17:19] * pJok casts magic missile [08:20:15] * KotH sprinkles pixie dust all around him [08:31:11] <Tjoppen> I have been tasked with muxing MOVs that use external media. any ideas if I can adapt lavf's muxer to suit such a need? [08:32:22] <kshishkov> probably you can [08:32:25] <Tjoppen> no such API exists of course, but I imagine being able to give a muxer a AVIndexEntry array would be useful for both the MOV and MXF muxers [08:32:43] <Tjoppen> *I don't think such and API exists [08:40:39] <Tjoppen> I think I have a plan of sorts. a bit tricky though [08:41:18] <kshishkov> lycka till! [08:45:45] <Tjoppen> :) [08:46:08] <Tjoppen> I might post an RFC on the list though.. dunno if such a thing would get accepted upstream [08:57:33] <lu_zero> hi bilboed-pi [08:58:13] <bilboed-pi> yo [09:11:09] <niobos> I'll probably get flamed for being off-topic, but I'll risk it anyway: On the ffmpeg-dev mailinglist I see some post about optimization: what should/shouldn't be SSE'ed, read/write interleaving, allignment, ... Where can I find more info about these low-level things? how do you test if methodA is faster than methodB? are there general guidelines (possibly CPU/arch dependent)? [09:14:42] <av500> you implement A and B and stopwatch which one is faster [09:37:43] <astrange> http://agner.org/optimize/ [10:06:00] <niobos> astrange: that looks very promising, thx! [10:07:37] <astrange> but benchmarks are better [10:08:43] <niobos> true, but I first need to get a feel for "what optimizations are possible and which make sense in this case" [10:11:32] <bilboed-pi> Honoome, gaaah zlib :( I seriously want to murder those guys [10:13:14] * mru too [10:13:21] <mru> bilboed-pi: what did they do now? [10:13:57] <KotH> .o0(FFassassins) [10:14:14] <bilboed-pi> just the usual "here's a release and you can bite my shorts if you expect any kind of changelog. You want what ? a supository ? oh, a repository ? what's that ?" [10:14:51] <bilboed-pi> every release is the guess-o-tron deluxe [10:15:01] <kshishkov> why should anyone bother? [10:15:04] <mru> you could diff it against the previous [10:15:15] <av500> compare md5sums [10:15:26] <mru> which will probably give you a ton of whitespace changes [10:15:39] <bilboed-pi> mru, the diff is useless without context of the changes [10:17:03] <bilboed-pi> remember that link someone posted last week or the week before with points based on how much a project sucks ? zlib gets all the points [10:17:13] <mru> wow [10:17:26] <mru> that's impressive [10:17:31] <kshishkov> really? do they post release as an attachement to a message on forum? [10:17:40] <hyc> lol [10:17:41] <bilboed-pi> kshishkov, ok, maybe not that bad :) [10:17:52] <mru> hyc: some people do that [10:17:59] <hyc> amazing... [10:18:13] <bilboed-pi> screenshot of release note posted on forums [10:18:17] <hyc> well zlib is not exactly mysterious code. what's wrong with reading a diff. [10:18:29] <av500> bilboed-pi: printed screen shot on wooden table! [10:18:37] <bilboed-pi> hyc, the *actual* code is ok, the problem is all the cruft that goes with it [10:18:41] <bilboed-pi> av500, win ! :) [10:18:57] <hyc> laser-etched? [10:19:07] <mru> the code itself is rather ugly [10:19:11] <kshishkov> bilboed-pi: that's why mru has his own implementations for decoder [10:19:31] <hyc> back when I worked support in college, we had a callfrom someone who wanted to use an Apple LaserWriter to etch designs into wooden baseball bats [10:19:35] <bilboed-pi> kshishkov, sure... but what about the hundreds of other packages depending on it ? [10:19:44] <bilboed-pi> it broke wireshark for example [10:19:45] <bilboed-pi> yay [10:19:58] <av500> hyc: http://thedailywtf.com/Articles/Web_0_0x2e_1.aspx [10:20:06] <kshishkov> bilboed-pi: buy a lot of screws and send one to each package maintainer [10:20:09] <mru> I wrote that decoder mostly as an excuse for learning to use the vlc reader [10:21:28] <hyc> av500: mmm, gonna do that with my next rtmpdump release ;) [10:22:06] <av500> extra points for releasing a patch only, printed and photographed [10:22:25] <mru> on a wooden table of course [10:22:30] <av500> of course [10:22:32] <hyc> it'll be printed in a ransom-note font too [10:22:56] <kshishkov> and photo is not digital but rather scanned [10:23:09] * mru writes ransom emails by copying and pasting words from different blogs [10:23:24] <av500> mru: but they can monitor the blogs you read! [10:24:12] <av500> better take letters from SPAM you recieve [10:24:28] <mru> good idea [10:24:28] <spaam> spam spam spam :) [13:11:21] <Honoome> bilboed-pi: yeah don't tell me about zlibâŠ they are most definitely on crack! [13:11:49] <mru> as good as IJG's? [13:13:01] <Dark_Shikari> http://i41.tinypic.com/20v0sox.png [13:13:09] <Dark_Shikari> this is what happened when I press release'd and got /.ed [13:14:07] <Dark_Shikari> heh, IJG [13:15:16] <KotH> hmm... linear gorth and exponential back-off [13:15:20] <KotH> growth* [13:24:02] <Honoome> mru: nah, but stillâŠ they have been releasing again after a few yearsâŠ and broke the hell by trying to implement largefile support âproperlyâ [13:24:28] <Honoome> among other things, they inverted one if(n)def logic between .4 and .5 that broke half a dozen packages at least [13:34:18] <mru> speaking of ijg, it's apparently ok to mock them (him?), but xiph is off-limits? [13:35:01] <Honoome> mru: gnu's off-limits as well [13:35:07] <mru> ah, right [13:35:18] <Honoome> mru: have you seen the responses I had when I criticised fold.c? [13:35:54] <mru> gnu isn't nearly as dangerous as xiph [13:36:07] <mru> gnu only reimplement existing stuff they don't like the licence on [13:36:19] <mru> xiph try to invent stuff [13:36:52] <Honoome> gnu has lock-ins as wellâŠ and if you cannot even criticise their over-engineering you hit a spiral of âit doesn't matter if it's technically decent or not as long as it's FreeTheWayTheyWantItToBeâ [13:37:22] <mru> like gcc made deliberatly difficult to extend [13:37:33] <av500> gcccccc [13:37:53] <Dark_Shikari> Honoome: of course you can [13:37:57] <mru> it's all a tangled mess to stop people putting their own frontend etc on it [13:38:00] <Dark_Shikari> reddit/etc are overflowing with "gnu sucks, use llvm" [13:38:01] <lu_zero> gcc is that difficul to extend? [13:38:07] <Dark_Shikari> You just have to _ignore_ the freetards [13:38:11] <Dark_Shikari> and mention llvm at every third sentence [13:38:18] <mru> gnu != gcc [13:38:43] <lu_zero> In my experience the main issue with gcc is that doesn't use autotools [13:38:51] <Dark_Shikari> gnu â gcc [13:38:52] <mru> it does [13:38:54] <lu_zero> it rapes 3 different version of it in a quite bad way [13:39:02] <mru> only 3? [13:39:11] <lu_zero> by the time I was hacking it yes [13:39:32] <lu_zero> but adding subsystems and code generation didn't look that bad [13:39:33] <mru> and why does it run configure so many times? [13:39:48] <av500> better safe than sorry [13:39:56] <ohsix> nested projects [13:40:02] <mru> they have a million little sub-configures [13:40:12] <mru> which mostly check _again_ if you have a fortran compiler [13:40:13] <ohsix> and they can all be in or out of tree [13:40:33] <lu_zero> the fortran is due old libtool mostly [13:40:33] <ohsix> you can point it at a cache like you can with any other :> [13:40:39] <lu_zero> _now_ that had been fixed [13:41:05] <Honoome> mru: and one of the reason why I criticise coreutils is because they also rape autotools through their gnulib [13:41:31] <Honoome> Dark_Shikari: interestingly enough, I hadn't complained about GCC per-se that time ;) and the problem is I hit linuxtoday rather than reddit at that time, so was filled with freetards :| [13:41:36] <lu_zero> still I hope to have clang, ack and whatever in a better shape so gcc will cleanup [13:42:17] <Honoome> ack as in the perl-based grep-alike? [13:42:22] <lu_zero> no [13:42:29] <lu_zero> the crazy compiler you have in minix [13:42:38] <Honoome> oh shitâŠ [13:43:49] <lu_zero> uh? [13:44:31] <Honoome> lu_zero: how much time will it take for shilling to write his own compiler at this pace? :| [13:44:43] <lu_zero> shilling? [13:44:44] <lu_zero> meh [13:44:54] <ohsix> joerg [13:45:01] <mru> that troll... [13:45:15] <lu_zero> mru: envious? =) [13:45:27] <ohsix> status ;] [13:45:50] <mru> was the outcome of our battle ever decided? [13:45:58] <lu_zero> I stil wonder what would happen if we put theo, joerg and ciaran in the same room [13:46:09] <Honoome> lu_zero: add Drepper for fun [13:46:18] <lu_zero> Drepper doesn't qualify [13:46:37] <Honoome> no but it spices joerg up [13:46:45] <lu_zero> brrr... [15:52:33] <Dark_Shikari> mru: steve jobs is epic troll [15:52:35] <Dark_Shikari> "A patent pool is being assembled to go after Theora and other âopen sourceâ codecs now." [15:53:52] <kshishkov> why don't you believe that? [15:54:18] <Dark_Shikari> not a matter of believe, I just don't think Steve Jobs has any evidence to it, and is saying it intentionally to troll freetards [15:54:24] <Dark_Shikari> and is thus awesome [15:54:35] <kshishkov> :) [15:56:16] <mru> it's annoying when bad people do cool things [15:56:48] <BBB> don't you love him? [15:56:56] <Dark_Shikari> well, I have a bit more respect for steve jobs these days. it's clear that he does not believe everything he says [15:56:57] <BBB> where did he say that? [15:56:59] <Dark_Shikari> or even every decision he makes [15:57:04] <Dark_Shikari> and sometimes he just does things to piss people off [15:57:08] <Dark_Shikari> And I can stand behind that. [15:57:13] <BBB> that is totally awesome [15:57:19] <BBB> I would love to set up a garage startup [15:57:24] <BBB> own it while it becomes worth $100billion [15:57:30] <BBB> and then totally piss on people [15:57:33] <BBB> just because I can [15:57:35] <Dark_Shikari> Yes, this is what Jobs does. [15:57:38] <BBB> exactly [15:57:44] <BBB> I want to be like him (r)(c)(tm) [15:57:51] <BBB> er, ""Him"" [15:57:59] <BBB> I want to be like Him[tm](r)(c) [15:58:01] <kshishkov> BBB: get rid of Mac till it fully devours your soul! [15:58:13] <Dark_Shikari> oh you'd have to be stupid to own a mac [15:58:17] <Dark_Shikari> that means you're ACTIVELY letting him troll you! [15:58:18] * BBB stupid [15:58:25] * BBB trolled [15:58:34] <BBB> Dark_Shikari: where did he say that? [15:58:51] <kierank> s/mac/iphone [15:58:56] <Dark_Shikari> http://blogs.fsfe.org/hugo/2010/04/open-letter-to-steve-jobs/ [15:59:08] <Dark_Shikari> All video codecs are covered by patents. A patent pool is being assembled to go after Theora and other âopen sourceâ codecs now. [15:59:11] <Dark_Shikari> Unfortunately, just because something is open source, it doesnât mean or guarantee that it doesnât infringe on others patents. An open standard is different from being royalty free or open source. [15:59:16] <Dark_Shikari> Sent from my iPad [15:59:19] <Dark_Shikari> _troll_ [15:59:25] <BBB> that's a troll [15:59:29] <BBB> h264 is open [15:59:36] <BBB> the author of this piece is a freetard [15:59:37] <BBB> 'nuf said [15:59:39] <Dark_Shikari> BBB: um, DUH [15:59:41] <Dark_Shikari> it's from the FSF [15:59:45] <BBB> fuck the fsf [15:59:46] <Dark_Shikari> the point is, steve jobs' response is perfect [15:59:49] <Dark_Shikari> it knows his audience [15:59:53] <BBB> how do you know it's him? [15:59:53] <Dark_Shikari> he knew what would piss them off the most [15:59:54] <Dark_Shikari> And he said it [16:00:06] <Dark_Shikari> I love it. [16:00:38] <BBB> I want to marry steve jobs [16:00:44] <Dark_Shikari> also, if you like apple trolling [16:00:45] <Dark_Shikari> read http://www.suregottold.com/ [16:00:53] <Dark_Shikari> All about trolling apple, and apple trolling. [16:00:56] * kshishkov records BB words for further blackmail [16:02:05] <BBB> :-p [16:02:44] <BBB> here's some more, kshishkov [16:02:50] <BBB> steve jobs is awesome [16:02:52] <BBB> linux sucks [16:02:59] <BBB> macs are better than lunix [16:03:08] <BBB> anything more needed before I get kb'ed? [16:03:10] <kierank> xp > all [16:03:15] <BBB> no, that's a lie [16:03:16] <kierank> nuff said [16:03:21] <BBB> everyone knows vista is better than xp [16:09:09] <BBB> what I really love is the final sentence [16:09:18] <BBB> "since ..., >>> I think <<< I ..." [16:09:25] <BBB> this guy has absolutely no fucking clue :) [16:10:02] <BBB> (just to be clear, under american law every private conversation is (c) owned by its author and you need explicit permission to publish it, i.e. he just broke the law right there and if SJ really wanted to piss him off, he could sue him) [16:10:27] <BBB> freetards.org is still available [16:10:29] <BBB> hmm... [16:11:20] <Dark_Shikari> buy it, redirect to FSF [16:12:47] <mru> that would be fun [16:13:02] <mru> or better, proxy it, so the url stays [16:14:39] <kierank> meh $7 is too high a price for fsf trolling [16:15:04] <mru> trolling fsf isn't that much fun [16:15:08] <mru> too predictabl [16:15:09] <mru> e [16:15:28] <mru> Q: troll [16:15:34] <mru> A: freedom, freedom, freedom [16:16:32] <kierank> http://www.youtube.com/watch?v=wJPyV5KziUU [16:18:07] <BBB> mru: GNU/Freedom [16:18:57] <mru> kierank: that's cheating [16:19:27] <mru> you should troll them into saying freedom without mentioning it explicitly [16:20:21] <kierank> there's also the "freedom to steal" blooper: http://www.youtube.com/watch?v=Uta2OZUCNRA [16:20:25] <peloverde> http://github.com/aconverse/ffmpeg-heaac/tree/ps_pub [16:23:09] * BBB hugs peloverde [16:23:11] <BBB> does it work? [16:23:55] <peloverde> mostly, it only outs in mono so you get to select if you L or R manually [16:24:44] <peloverde> basically because I haven't figured out how I'm going to deal with backwards compatible signaling [16:28:22] <peloverde> I'm thinking about using faad's approach possibly [16:29:20] <peloverde> I might also write a BSF to manipulate signaling, but the BSF API seems to constricting [17:00:38] <kshishkov> BBB: I don't think your wife minds Linux but you marrying somebody else may be not tolerated that well [17:07:28] <BBB> :-p [19:05:25] <DonDiego> moin [19:06:19] <kshishkov> gruess dich [19:06:47] <DonDiego> monty has replied.. [19:06:54] <DonDiego> mru: already seen it? [19:07:01] <mru> yes [19:07:15] <mru> *sigh* [19:12:12] <kshishkov> bye [19:12:53] <BBB> are the kids playing again? [19:13:07] <DonDiego> it seems.. [19:13:22] <Dark_Shikari> BBB: apparently the freetards are already whining about apple's upcoming "patent attack" on theora [19:13:25] <Dark_Shikari> due to what jobs said [19:13:32] <BBB> that was quick [19:13:33] <BBB> where? [19:13:36] <DonDiego> WTF? [19:13:38] <Dark_Shikari> I immediately envisioned a guy surfing at the beach [19:13:44] <Dark_Shikari> and a patent coming out of the water [19:13:45] <Dark_Shikari> and eating him [19:13:58] <peloverde> Does anyone have systems refsoft newer than isolibjan08b? [19:13:58] <Dark_Shikari> and instead of a shark fin, there's the corner of a pad of paper [19:14:04] <Dark_Shikari> which moves around [19:14:07] <Dark_Shikari> and the jaws theme music plays [19:14:41] <peloverde> The reference remuxer is segfaulting on me [19:15:03] <DonDiego> mru: what do you say? [19:15:07] <janneg> DonDiego: http://hugoroy.eu/jobs-os.php [19:15:18] <Dark_Shikari> DonDiego: it was hilarious [19:15:22] <Dark_Shikari> Jobs is actively trolling freetards [19:15:27] <Dark_Shikari> thus making him awesome [19:16:19] <DonDiego> what was hilarious? [19:16:38] <Dark_Shikari> All video codecs are covered by patents. A patent pool is being assembled to go after Theora and other âopen sourceâ codecs now. [19:16:41] <BBB> his last letter in the original [19:16:42] <Dark_Shikari> Unfortunately, just because something is open source, it doesnât mean or guarantee that it doesnât infringe on others patents. An open standard is different from being royalty free or open source. [19:16:45] <BBB> "I think" [19:16:46] <Dark_Shikari> Sent from my iPad [19:16:47] <BBB> that was hilarious [19:17:01] <peloverde> no, isolib is from apple therefore jobs is satan [19:17:25] <peloverde> how hard is it to make a reference implementation that doesn't segfault on the first reference file [19:19:39] <BBB> http://blogs.msdn.com/ie/archive/2010/04/29/html5-video.aspx [19:19:42] <BBB> so I guess h264 won [19:19:45] <BBB> \o/ [19:19:50] <BBB> let's bury ogg/theora [19:20:40] <Dark_Shikari> lol [19:20:46] <Dark_Shikari> welcome to yesterday or so =p [19:33:35] <j0sh> BBB: the qt demuxer patch is listed as a gsoc todo (http://people.gnome.org/~rbultje/ffmpeg-patchset/16-rtsp-x_qt.patch) [19:33:43] <j0sh> what is left to be done with it? [19:48:07] <bcoudurier> evening guys [19:53:27] <DonDiego> moin [19:53:49] <DonDiego> mru: will you reply? [19:54:24] <mru> I am not going to engage in a flamewar [19:54:31] <BBB> j0sh: bcoudurier doesn't like it [19:54:41] <BBB> j0sh: so discuss it with him, make a plan and get it to work :) [19:54:50] <DonDiego> mru: what happened to you? :) [19:56:51] <Dark_Shikari> don't worry, steve jobs took up the job of trolling them now [20:00:08] <BBB> I don't see monty's reply [20:00:36] <BBB> or did diego mean monty's old, dated reply to mru's wonderful flametroll? [20:01:01] <BBB> (for which I'd like to extend my compliments and congratulations) [20:01:01] <mru> I guess he means the rant monty posted 2 days ago [20:03:30] <DonDiego> yes [20:03:35] <DonDiego> what do you make of it? [20:04:00] <mru> it's a rant and a sensible reply is impossible [20:04:17] <mru> they've conveniently deleted all email archives before 2002 [20:11:23] <BBB> j0sh: you'd likely want to start with qdm2/svq3 depacketizers... these are easier and I was further ahead with them at that time [20:11:31] <BBB> j0sh: leave the qt patch for after that... [20:11:43] <j0sh> ok will do [20:16:09] <DonDiego> mru: you could reply by making your own article more detailed [20:16:21] <DonDiego> fill in some more examples, clarify some things, etc.. [20:20:33] <peloverde> do people have thoughts on implicit SBR/PS? I'm at a bit of an impasse here [20:20:58] <DonDiego> bye [20:23:34] <BBB> peloverde: what's implicit ps? [20:24:16] <peloverde> Implicit PS is when parametric stereo is not mentioned in the header and just shows up in the bitstream [20:24:35] <peloverde> all signaling in ADTS (.aac files) is implicit [20:25:06] <peloverde> in .mp4/.mkv SBR and/or PS can be explicitly signaled [20:25:21] <saintd3v> so streaming radio uses implicit signaling then? [20:25:49] <saintd3v> since it's raw aac (don't remember if they use adts or not) [20:26:12] <peloverde> it depends on if they send an ASC (mp4a header) somewhere [20:26:24] <peloverde> you don't need full blown mp4 for the header [20:26:33] <saintd3v> but it _can_ be explicit also? [20:26:33] <peloverde> it's the standard extradata format [20:26:52] <BBB> so the question is, how do we signal that the samplerate (or channels) just doubled to the application? [20:27:07] <BBB> does ps always go mono->stereo? [20:27:11] <BBB> or can it go 1->5.1? [20:27:19] <saintd3v> "BOO! I nao haz 2 chanz" [20:27:35] <peloverde> ps always goes mono -> stereo [20:27:44] <peloverde> mono -> 5.1 is called mpeg surround [20:27:51] <peloverde> the successor to PS [20:27:55] <BBB> how about abusing AVCodecContext.request_channels? [20:28:04] <BBB> basically signaling more channels [20:28:09] <BBB> wait for the app to update that value [20:28:13] <BBB> and then exporting stereo [20:28:18] <BBB> until then, downmix to mono [20:28:23] <BBB> or alternatively always export stereo [20:28:29] <BBB> (which is a bit hacky) [20:29:32] <peloverde> the thing is, 3GPP AAC does have an SBR domain downmix feature [20:29:49] <peloverde> so presumably AVCodecContext.request_channels should be used for that [20:29:59] <BBB> right [20:30:03] <BBB> but I meant something along those lines [20:30:05] <peloverde> also how is the app supposed to know it wants stereo? [20:30:08] <BBB> how about just always exporting stereo? [20:30:29] <BBB> well, so for PS, you'd start with channels=1 [20:30:35] <BBB> so request_channels=1 also [20:30:45] <BBB> update channels=2 once you see PS, leaving request_channels as is [20:30:51] <BBB> wait for app to updat request_channels to 2 [20:30:55] <BBB> which means it wants stereo [20:30:58] <BBB> until then, export mono [20:31:01] <BBB> = backwards compatible [20:31:30] <peloverde> setting channels to two but exporting one would probably require a major bump [20:31:44] <BBB> ... [20:31:55] <BBB> not really [20:32:01] <BBB> because you left request_channels to 1 [20:32:11] <BBB> which takes precedence over channels=2 [20:32:13] <BBB> I think [20:32:22] <BBB> what does the api doc say? [20:33:12] <peloverde> it only says ausio only [20:33:16] <peloverde> *audio only [20:33:16] <BBB> ambiguous :) [20:33:26] <BBB> I think request_channels takes precedence over channels [20:33:32] <BBB> discuss on the ML, but I think this might work [20:33:36] <peloverde> also request_channels is inside #if LIBAVCODEC_VERSION_MAJOR < 53 [20:33:46] <BBB> right, so it'd be request_channel_layout [20:33:46] <peloverde> so it seems sill to rely on that [20:33:50] <peloverde> ahhh [20:33:51] <BBB> but same idea [20:33:59] <BBB> so LAYOUT_MONO [20:34:01] <BBB> and channels=2 [20:34:03] <BBB> = PS [20:34:08] <BBB> wait until app sets LAYOUT_STEREO [20:34:10] <BBB> whatever that is [20:34:19] <BBB> and then export undownmixed PS signal [20:34:36] <peloverde> so what would ffmpeg.c do when decoding to .wav? [20:35:00] <BBB> A) leave it as mono, or B) use a VERY LONG av_find_stream_info() [20:35:44] <BBB> s/or/and/ maybe [20:36:37] <peloverde> I think exporting stereo all the time makes more sense [20:36:43] <BBB> well yes [20:36:49] <BBB> but only if av_find_stream_info() detected it [20:37:02] <BBB> what if we pre-decoded 10MB and the PS implicit only came at 11th MB [20:37:09] <BBB> then we'd obviously leave it as mono [20:37:12] <BBB> better than nothing [20:37:21] <peloverde> also I think you are putting the cart ahead of the horse here, can I explain the full problem? [20:37:28] <BBB> but assuming the implicit PS comes rather quickly, then of course just always set request_channel_layout to LAYOUT_STEREO [20:37:36] <BBB> sure [20:37:38] <BBB> I might misunderstand [20:37:40] <BBB> sorry if I do [20:38:13] <peloverde> so right now SBR is supported PS isn't [20:38:41] <peloverde> to figure out if implicit signaled SBR is present we use try_decode_frame() [20:39:19] <peloverde> the problem is that prevents us from demuxing files the decoder doesn't support [20:39:35] <peloverde> like we've lost the ability to demux LTP and SSR [20:39:49] <peloverde> and LD [20:39:57] <peloverde> which all are supported by libfaad [20:40:38] <BBB> so what is the problem exactly, why don't they work anymore? [20:41:15] <peloverde> so let's say we have an my_ltp_file.m4a [20:42:21] <peloverde> and SBR is not signaled (aka implicit signaling) [20:42:40] <peloverde> so to try to figure out the sample rate we try to decode a frame [20:43:01] <peloverde> at which point the decoder errors [20:43:07] <peloverde> because it doesn't support LTP [20:43:20] <BBB> right [20:43:40] <peloverde> before SBR we just said the sample rate was the nominal sample rate [20:43:49] <BBB> the "faad hack" [20:44:30] <BBB> I think it's not necessarily bad that we error out [20:44:40] <BBB> I mean, if people want them, just use ./configure --enable-libfaad [20:44:50] <BBB> it's not that difficult :) [20:44:57] <BBB> I agree that it's non-ideal [20:45:08] <BBB> but in the end, AVCodecContext.sample_rate/channels are correct [20:45:20] <BBB> which imo is more important than a temporary inconvenience [20:45:35] <BBB> (eventually we'll support LTP/SSR/...) [20:45:48] <peloverde> The way it's plumbed even if -acodec libfaad is requested it still tries to use our decoder to figure out the sample rate [20:46:26] <BBB> you mean in mplayer? [20:47:18] <BBB> mplayer then doesn't use the right configure switches to ffmpeg... that's fixable [20:47:19] <peloverde> no i mean in ffmpeg [20:47:23] <BBB> really? [20:47:31] <BBB> shouldn't libfaad take precedence if it's available? [20:47:42] <BBB> I guess only if you use --disable-decoders=aac [20:47:43] <BBB> ... [20:47:45] <BBB> hmm... [20:48:03] <BBB> well, then you need both those configure switches :) [20:48:08] <BBB> still fixable [20:49:21] <peloverde> so let's assume thats all fixed for the sake of argument [20:49:27] <BBB> ok [20:50:05] <BBB> I suppose -acodec copy still is broken right? [20:50:15] <peloverde> sort of [20:50:26] <BBB> hm... well that's a tough one [20:50:32] <BBB> you'll either inconvenience players [20:50:34] <BBB> or transcoders [20:50:50] <peloverde> yeah [20:50:59] <BBB> so which is the lesser evil? [20:51:21] <peloverde> I think something to specify reconfigurability should be in the avcodec context [20:52:03] <peloverde> actually I'm not sure how much that would help [20:52:25] <BBB> I don't think it'd be all that helpful in practice [20:52:31] <peloverde> anyway the real problem is PS can only occur inside SBR [20:52:42] <BBB> although I'm sure some players would use it to if (flag & that_flag) printf("THIS FILE HAS SBR/PS!!!111\n"); [20:52:51] <BBB> and then call it "extended metadata support" [20:53:14] <BBB> ok, back to the problem [20:53:21] <BBB> I don't think it's a major issue [20:53:32] <BBB> I'll think a little about the transcoding case [20:53:38] <BBB> I think we can come up with a solution there [20:53:40] <peloverde> I'd like to be able to decode mono files to mono when possible [20:53:51] <peloverde> not running the SBR filterbank twice saves significant CPU [20:53:58] <BBB> got it [20:54:16] <BBB> I think the try_decode_frame() approach is fine then [20:54:21] <BBB> have the demuxer set channels=1 [20:54:24] <BBB> and leave it as is [20:54:35] <BBB> make sure request_channel_layout is set [20:54:36] <BBB> somehow [20:54:55] <BBB> and then use that... [20:55:12] <BBB> by the way, AAC is a little icky now that I think about it :) [20:55:33] <peloverde> The real trick is just to always use explicit signaling [20:55:56] <peloverde> I want to create a BSF to rewrite signaling [20:55:59] <BBB> right, and it'd be lovely if all avi files were CBR and so on :) [20:56:14] <peloverde> but signaling is just a field in the header [20:56:19] <peloverde> so most files are fixable [20:56:22] <BBB> the thing is, people create hacky files :) [20:56:33] <BBB> what does quicktime do with these files? [20:56:34] <BBB> do they work? [20:56:43] <BBB> that's an important question [20:56:56] <peloverde> I don't know there is no quicktime for linux [20:57:27] <peloverde> quicktime only got PS support very recently if at all [20:57:55] <peloverde> I wouldn't treat quicktime as the gold standard for this particular feature [20:58:07] <BBB> ok [20:58:39] <peloverde> QuickTime got SBR support around when 10.6 came out [21:00:04] <BBB> mru: can I add mdct to configure's wmavoice_deps to fix that dependency issue? [21:00:12] <peloverde> Does -request_channels set request_channel_layout? [21:00:36] <BBB> I don't know :( [21:00:39] <BBB> it should [21:00:43] <mru> BBB: does wmavoice use mdct? [21:00:51] <BBB> mru: it uses ff_sine_table_init() [21:00:55] <mru> that's not mdct [21:01:12] <BBB> I know, but all other codecs using ff_sine_table_init() (e.g. cook, nellymoser) use deps=mdct [21:01:13] <mru> if all it needs is the table, we should move those tables into their own files [21:01:18] <BBB> no, no [21:01:20] <BBB> not the table [21:01:21] <BBB> the function [21:01:28] <mru> difference? [21:01:29] <BBB> we init a private table and then modify it slightly [21:01:37] <BBB> we don't use ff_sine_table [21:01:55] <mru> even less reason to pull in the whole thing [21:02:06] <mru> yes, I know other codecs do it [21:02:06] <BBB> so should we move the sine functions into their own files? [21:02:11] <mru> but we've got to fix it sooner or later [21:02:16] <BBB> right, agreed [21:04:29] <peloverde> BBB, one other thing we can do in the demuxer is pretend SBR and PS were signaled off for non-LC files [21:05:01] <BBB> you mean to skip try_decode_frame()? [21:05:37] <peloverde> yes [21:05:47] <peloverde> SBR/PS is never used with non-LC [21:05:58] <BBB> how do you signal SBR again? [21:05:58] <peloverde> there isn;t any legal profile that supports that [21:06:03] <BBB> you set sample_rate=0 in the demuxer? [21:06:08] <peloverde> yes [21:06:14] <BBB> that sounds sane then [21:06:20] <BBB> I would support that [21:06:32] <BBB> are there hacked up files that use sbr in no-lc anyway? [21:06:37] <BBB> or is it physically impossible? [21:09:28] * BBB should write a blogpost about the wmavoice postfilter... [21:09:35] <BBB> I guess I'm bored or so [21:31:13] <CIA-7> ffmpeg: mru * r22992 /trunk/libavcodec/ (vp56.h vp56dsp.c vp5.c vp6.c Makefile vp56dsp.h vp56.c): [21:31:13] <CIA-7> ffmpeg: VP56: move vp56_edge_filter to new VP56DSPContext [21:31:13] <CIA-7> ffmpeg: Using macro templates allows the vp[56]_adjust functions to be [21:31:13] <CIA-7> ffmpeg: inlined instead of called through function pointers. The new [21:31:13] <CIA-7> ffmpeg: function pointers enable optimised implementations of the filters. [21:31:14] <CIA-7> ffmpeg: 4% faster VP6 decoding on Cortex-A8. [21:31:14] <CIA-7> ffmpeg: mru * r22993 /trunk/libavcodec/ (5 files in 2 dirs): ARM: NEON optimised VP6 edge filter [21:44:15] <CIA-7> ffmpeg: alexc * r22994 /trunk/MAINTAINERS: [21:44:15] <CIA-7> ffmpeg: Declare myself (Alex Converse) AAC maintainer. [21:44:15] <CIA-7> ffmpeg: Approved by the previous maintainer Rob. [21:44:15] <CIA-7> ffmpeg: alexc * r22995 /trunk/libavcodec/ (aac.c aacsbr.c aacsbr.h): [21:44:15] <CIA-7> ffmpeg: Rewrite ff_sbr_apply in a manner more friendly to PS. [21:44:15] <CIA-7> ffmpeg: This includes merging ff_sbr_dequant into ff_sbr_apply. [21:44:16] <CIA-7> ffmpeg: alexc * r22996 /trunk/libavcodec/ (aac.c aacsbr.c): Reindent [21:56:33] <BBB> peloverde: is this you? http://blog.case.edu/ajc30/ [21:56:54] <peloverde> yes from many years back [21:57:20] <BBB> do you have a more recent one? [21:58:57] <peloverde> no [21:59:12] <peloverde> I've thought about doing a new one, but haven't gotten around to it [21:59:33] <peloverde> (completely new blog, not a new entry there) [22:00:24] <BBB> well, go go go! [22:01:30] <peloverde> I just pushed a new changeset that actually decodes explicit PS to stereo (vs L or R) to http://github.com/aconverse/ffmpeg-heaac [22:04:09] <peloverde> I thought about blogging about USAC but I'm afraid if I do MPEG might clamp down on access [22:07:16] <peloverde> Are you doing some sort of ffmpeg blog aggregation or something like that? [22:07:20] <peloverde> planet ffmpeg? [22:08:52] <BBB> no [22:09:20] <BBB> just trying to link to something you in my blogpost as a "thanks to alex for (trying to) explain(ing) me what a hilbert transform is" [22:10:33] <CIA-7> ffmpeg: michael * r22997 /trunk/libavcodec/rawdec.c: [22:10:33] <CIA-7> ffmpeg: avi bgr24 padding fix. [22:10:33] <CIA-7> ffmpeg: Fixes issue1901 [22:19:29] <BBB> why don't you re-start posting on that blog? [22:19:35] <BBB> it's fun to see yourself transform over time [22:19:46] <BBB> I have blog posts about gstreamer taking over the world, or so [22:19:51] <BBB> it's fun to look back [22:36:01] <astrange> hmm, i just realized i know the author of spread open media [22:43:46] <CIA-7> ffmpeg: alexc * r22998 /trunk/libavcodec/aacsbr.c: [22:43:46] <CIA-7> ffmpeg: Increase size of patch_borders[]. [22:43:46] <CIA-7> ffmpeg: 6 patches means there can be 7 borders. Found by Chromium. [23:09:38] <CIA-7> ffmpeg: alexc * r22999 /trunk/libavcodec/aacsbr.c: [23:09:38] <CIA-7> ffmpeg: Move the SBR patch count check to prevent overwrites. [23:09:38] <CIA-7> ffmpeg: Thanks to Chromium. [23:33:37] <CIA-7> ffmpeg: alexc * r23000 /trunk/libavcodec/aacsbr.c: [23:33:37] <CIA-7> ffmpeg: Enforce time border monotonicity. [23:33:37] <CIA-7> ffmpeg: Thanks to Chromium. [23:34:29] <ramiro> 23000 \o/ [23:52:54] <j-b> nice [23:53:44] <spaam> woho [23:54:12] <spaam> when will ffmpeg hit 24000 ? sep ?

1 0