[00:00:13] <Kovensky> binutils also doesn't help [00:00:25] <Kovensky> lots of libtool workarounds are because of ld stupidities [00:00:42] <mru> ld is fine [00:00:59] <mru> gnu binutils as a whole actually work pretty well [00:01:09] <mru> appalling code aside [00:01:29] <Honoome> mru: have you looked at gold at all? [00:01:34] <mru> no [00:01:38] <mru> and I don't intend to [00:01:47] <mru> all I've heard is that it doesn't work [00:01:52] <Honoome> “it's fast because it's in C++!!!” [00:01:54] <mru> and exists only to solve a problem I don't have [00:02:12] <Honoome> when actually the reason it's fast is because it doesn't use either bfd or ldscripts (focuses on ELF only) [00:02:30] <Honoome> I'm curious to see what Drepper will pull out of his ass with elfutils' ld
 right now only supports x86 though [00:02:42] <Kovensky> loldrepper [00:02:43] <mru> scripts are very useful with elf too... [00:02:56] <mru> lolrich drepper... [00:03:46] <Honoome> mru: true, but they don't care, it is indeed one of the worst parts of ld (yes, I *did* benchmark ld at one point
) [00:04:04] <mru> I've never noticed ld taking any substantial amount of time [00:04:07] <mru> even for c++ [00:04:07] <Honoome> so from one point of view it makes sense to sacrifice the scripts for the most common case [00:04:09] <astrange> the author of gold doesn't claim it's faster because it's in c++, it's because it only does as many passes as needed [00:04:26] <astrange> he did seem really proud of templating to avoid endian swaps, i think it's because he works with too many plan 9 people [00:04:27] <Honoome> try linking webkit-gtk or chromium then tell me how ld performs :P [00:04:51] <astrange> wow, aac sbr is really good [00:05:00] <Honoome> astrange: beside the author a lot of people insisted gold was fast because it's C++ or because of the templates
 [00:05:13] <astrange> people are weird [00:05:34] <Honoome> C++ fanboys are very weird :P [00:05:50] <astrange> everyone i meet except the actual developers of llvm have some weird idea about it replacing gcc all over the world, like gcc killed their dog by being gpl [00:05:58] <Dark_Shikari> lol [00:06:07] <Dark_Shikari> astrange: it's not really unusual [00:06:29] <pasteeater> Dark_Shikari: you mean a unique firstpass for each preset? [00:06:38] <Honoome> astrange: yet another class of zealots that should really learn how to code instead of going around “evangelising” [00:06:58] <Dark_Shikari> pasteeater: yes [00:07:10] <Dark_Shikari> the idea being that a user can just add -firstpass to the preset [00:07:13] <Dark_Shikari> to get the, er, first pass version [00:08:06] <pasteeater> Dark_Shikari: that does make thinks a bit easier for the user i suppose. [00:08:19] <pasteeater> ...and "things". [00:11:31] <jez9999> BBB: hey... could you check in the patch for issue 1740? [00:12:15] <mru> there, libc.a manually updated instead [00:12:18] <mru> much easier [00:12:55] <pasteeater> Dark_Shikari: i think _firstpass (ex: lossless_ultrafast) would follow convention more so than -firstpass. [00:13:25] <Dark_Shikari> agreed. [00:14:47] <Honoome> Twinings English Breakfast tea
 the second best friend of the late-night developer [00:15:26] * mru prefers earl grey [00:15:44] <Honoome> mru: earl grey has a better taste but this has more caffeine power :P [00:15:52] <mru> I have coffee too [00:16:16] <Honoome> I already got three today, can't get too much coffee because of the fat content :( [00:16:21] <pasteeater> Tea. Hot. Earl Grey. [00:16:33] <mru> wrong order [00:16:54] <Honoome> and I seriously hope you don't refer to the classic English coffee as that's *not* coffee [00:17:00] * mru drinks coffee without additives [00:17:08] <kierank> tea > coffee [00:17:41] <Honoome> only realistic coffee I found in London was Costa and Nero
 [00:17:42] <mru> I usually make coffee in one of those octagonal pressure boilers [00:17:52] <mru> freshly ground of course [00:17:58] <Honoome> okay, that's _coffee_ ;) [00:18:02] <astrange> people give me too much instant coffee in england [00:18:04] <Honoome> [although I prefer espresso] [00:19:42] <mru> I don't have an espresso machine [00:21:16] <Honoome> when you'll pass by Italy, I'll show you what real coffee is like :D [00:25:13] <Honoome> (and not what they have in Turin :P I had to suffer through when I went at lu_zero's :P] [00:25:42] <mru> so where do I go for the Real Stuff? [00:26:14] <ohsix> you find anyone that will mainline it and has the kit to do it [00:27:00] <kierank> that cafe in venice in st marks square [00:27:21] <kierank> the one where it's €50 a cup [00:27:33] <Honoome> kierank: that's if you want to be made poor quite quickly :P [00:27:48] <Kovensky> ^@50 a cup? [00:27:59] <Honoome> I definitely prefer getting it at the Venice train station ^^;; [00:28:34] <Honoome> just in north-east we have something like six or seven different brands of coffee, for all tastes ;) [00:48:08] <Honoome> EC2 (library) nonsense: x['reservationSet']['item'][0]['instancesSet']['item'][0]['instanceState']['name'] == 'running' [00:48:16] <Honoome> this tells me whether an instance is running (after getting x of course) [00:58:45] <Kovensky> sure is overengineered [00:58:50] <Kovensky> plus >python [01:01:22] <Honoome> KotH: uh? python? [01:02:28] <Kovensky> Honoome: that looks like python syntax [01:02:39] <Honoome> that's a very generic syntax :) it's ruby anyway in my case :D [01:02:49] <Kovensky> =p [01:03:09] <Kovensky> python was the only language I knew that used undecorated variables and quoted strings between [] [01:04:28] <Honoome> after dealing with EC2, writing direct queries on psql console really feels like a welcome change [01:05:20] <Kovensky> lol [01:11:22] <mru> Kovensky: javascript does that too [02:11:18] <peloverde> Anyone have any fancy tips or tricks about going from tables in a specification to some sort of machine readable format [02:12:19] <mru> pdf? [02:12:32] <peloverde> I have it in pdf and doc [02:12:45] <mru> copy&paste? [02:13:15] <kierank> copy&paste to excel usually works well [02:13:18] <kierank> with paste special [02:14:51] <CIA-34> ffmpeg: michael * r21860 /trunk/libavcodec/ (h264.c h264.h h264_cavlc.c h264_cabac.c): [02:14:51] <CIA-34> ffmpeg: Move check for and call of predict_field_decoding_flag() from the mb code to [02:14:51] <CIA-34> ffmpeg: the row code. This function would only be needed on a MB basis for MBAFF+FMO [02:17:05] <Honoome> since Ruby does not compile, I found the conveniente excuse while working with that [02:17:10] <Honoome> “Deploying on EC2!” [02:17:39] <kierank> the python library is better [02:17:40] <kierank> boto [02:21:16] <peloverde> excel seems to choke in binary strings longer than 10 bits [02:22:47] <mru> I usually use some combination of emacs and perl [02:24:24] <Honoome> and perl? who needs perl when you got emacs? [02:24:31] <peloverde> I don't understand how all these corporate types like excel, I always run into issues like this [02:25:03] <mru> sometimes perl is easier than emacs [02:25:18] <Honoome> peloverde: there are things that are definitely working better on Excel than, say, OpenOffice Calc [02:25:45] <peloverde> yes, but excel also works better than an abacus [02:25:47] <mru> there are things that smell better than a turd [02:25:59] <CIA-34> ffmpeg: michael * r21861 /trunk/libavcodec/ (h264.c h264.h): [02:25:59] <CIA-34> ffmpeg: Move predict_field_decoding_flag() from h264.h to .c as its only used there and belongs [02:25:59] <CIA-34> ffmpeg: there as well. [02:26:44] <peloverde> Replace excel with spreadsheets in general if it makes you feel better [02:32:37] <Dark_Shikari> common/macroblock.c:281: confused by earlier errors, bailing out [02:32:39] <Dark_Shikari> never seen that before [02:32:50] <Honoome> peloverde: simpler to use than gnuplot :P [02:33:19] <peloverde> I find matplotlib to be an adequate replacement for both [02:38:02] <Honoome> okay I just screwed up my EC2 setup by mistake stopping the wrong instance =_= [02:38:29] * kierank has done that before [04:17:53] <peloverde> Anyone know what static_size is in INIT_VLC_STATIC? [06:47:04] <elenril> morning [06:49:13] <kshishkov> hej [06:50:30] <elenril> i knew i shouldn't have involved myself with asf [06:50:51] <kshishkov> too bad M$ didn't have that feeling [06:53:12] <elenril> they still use it? [06:54:54] <kshishkov> probably yes [06:58:13] * thresh waves [06:58:27] <thresh> kshishkov: for a self-unemployed person you wake up too early! [06:58:43] <kshishkov> I used to wake up even earlier [08:12:52] * av500 waves to the east [08:13:37] * kshishkov waves back [08:13:53] * av500 waves to the west [08:14:16] * kshishkov waits much more time to wave back [08:18:07] <pJok> mornings :) [08:18:15] <kshishkov> goda morgnar [09:18:49] * pross-au nods [09:21:47] * kshishkov bows [13:36:03] <elenril> how can i get to files in incoming? [14:08:18] <Dark_Shikari> kshishkov: short response sent [14:08:23] <Dark_Shikari> thanks for the comments on my review [16:06:07] <twnqx> i think i obsereved rockbox devels here recently... [16:06:15] <mru> yep [16:06:28] * twnqx needs a rockbox for nano 4th gen :X [16:06:44] <kshishkov> we don't produce it (yet) [16:06:57] <twnqx> alternatively 5th [16:06:59] <twnqx> :X [16:07:12] <twnqx> i lost my 2nd gen locng time back [16:07:19] <twnqx> and sold my 3rd... [16:07:49] <av500> twnqx: the encryption is not yet broken, no way to put rockbox [16:07:56] <twnqx> oh [16:08:14] <twnqx> there's encryption involved? [16:08:58] <kshishkov> av500: why do someone need it broken? It's like saying that you can't fit a screw with hammer [16:09:31] <av500> twnqx: apple firmware is encrypted/signed [16:09:42] <twnqx> i thought rockbox just replaces it completely. [16:09:53] <av500> twnqx: try to convince the bootloader :) [16:10:06] <twnqx> oh, it's THAT evil. [16:10:20] <av500> unless the sig is valid, it will not update to the new firmware [16:10:29] <mru> replace the bootloader too ;-) [16:10:33] <KotH> patch the bootloader [16:10:39] * KotH blames mru for being faster [16:10:40] <av500> locked [16:10:54] <KotH> remove the lock bit [16:10:55] * mru wields lockpick [16:10:59] <av500> u cant [16:11:04] <KotH> replace teh hardware [16:11:09] <twnqx> wait... [16:11:16] * av500 waits [16:11:17] <twnqx> now THAT would be... [16:11:23] <mru> not even with a plasma beam? [16:11:36] <mru> like that guy who hacked the TPM [16:11:39] <twnqx> heh [16:11:43] <av500> mru: for a nano? [16:11:52] <av500> bit of too much effort [16:12:11] <twnqx> just build a quantum computer to break the digital signature [16:12:18] <mru> might be fun using a slightly higher power plasma beam on one... [16:12:36] <av500> twnqx: do that and pass the key to rb team.... [16:13:12] <KotH> the encryption cant be that hard [16:13:20] <av500> rsa... [16:13:24] <av500> the usual [16:13:27] <KotH> how many bits? [16:13:38] <mru> most secret encryption schemes have stupid flaws [16:13:39] <av500> no idea, enough I guess [16:14:07] <merbzt> samsung soc with encryption in the cpu [16:14:34] <KotH> go for the flaws in the chip [16:14:34] <av500> we use the same scheme, locked bootloader and signed firmware images [16:14:44] <av500> (at least we used too) [16:14:48] <KotH> why? [16:14:58] <KotH> dont you want your users to use your devices? [16:15:11] <KotH> do you want them to switch to your competitors instead? [16:15:11] <av500> god gracious, no [16:15:20] <av500> KotH: ya, to apple := [16:15:22] <av500> KotH: ya, to apple :) [16:15:25] <mru> someone promised /me an unlocked nexus... [16:15:42] <av500> they should be unlocked by default [16:15:47] <KotH> mru: i guess he took your money and run away [16:16:13] <mru> av500: no firmware locks? [16:16:20] <av500> I dont think so [16:16:25] <kshishkov> me found a hidden stash of unlocked Nexuses and want to secretly transport them from Nigeria [16:16:32] <mru> hehe [16:16:35] <av500> http://androidandme.com/2010/01/hacks/video-how-to-unlock-and-root-a-nexus-o... [16:16:57] <av500> make no sense for gg to lock them, they want them used for dev stuff [16:17:20] <mru> they want people to write shitty java apps, yes [16:17:26] <mru> not replace their OS [16:17:51] <av500> g1 dev phone was also not locked, so nexus isnt either it seems [16:18:16] <av500> mru: what other OS do you propose to put instead? :) [16:18:28] <mru> rockbox ;-) [16:18:47] <kshishkov> mru: it can't run FFmpeg [16:18:48] <twnqx> on a... phone? [16:18:51] <av500> a 500$ mp3 player, not bad [16:19:05] <mru> I was to get it for free... [16:19:16] <mru> well, we'll see if it materialises [16:19:18] * av500 got one for free [16:22:53] <twnqx> can rockbox play .tta+.cue and .ape+.cue? [16:23:05] <Dark_Shikari> hope it can. [16:23:08] <kshishkov> ape - yes [16:23:09] <Dark_Shikari> TTA+cue is really important [16:23:15] <kshishkov> tta - probably not [16:23:15] <Dark_Shikari> .... for the touhou lossless music collection ;) [16:23:23] <Dark_Shikari> why do the japanese use their own formats for everything anyways [16:23:23] <mru> ape is rather cpu-hungry... [16:23:38] <mru> Dark_Shikari: ever heard of NIH? [16:23:45] <twnqx> Dark_Shikari: just converting all the alstromeria records from it to flac >_> [16:23:48] <kshishkov> mru: and still has not got NEON speedup in lavc [16:23:48] <av500> NineInchHails? [16:24:03] <twnqx> alstroemeria* [16:24:07] <mru> av500: sounds like fun, no? [16:24:11] <Dark_Shikari> mru: yup, ffmpeg is break isn't it [16:24:15] <kshishkov> twnqx: rejoice - TTA is unsupported http://www.rockbox.org/wiki/SoundCodecs [16:24:23] <Dark_Shikari> twnqx: just get the lossy collection [16:24:24] <Dark_Shikari> fuck flac [16:24:33] <twnqx> nah [16:24:41] <av500> fluck [16:24:42] <Dark_Shikari> v2 mp3 is enough for me [16:24:45] <kshishkov> Dark_Shikari: it's got worse. Some of them use TAK now [16:24:53] <twnqx> yeah... [16:25:30] <Dark_Shikari> also [16:25:35] <Dark_Shikari> the latest lossless music collection is so large [16:25:37] <Dark_Shikari> that it breaks utorrent [16:25:41] <Dark_Shikari> one more reason to get the lossy instead [16:26:03] <kshishkov> or use Touhou music generator instead [16:26:23] <Dark_Shikari> 626127863211 bytes [16:26:26] <mru> http://xkcd.com/411/ [16:26:50] <Dark_Shikari> of course. [16:27:01] <kshishkov> Dark_Shikari: ask andome, I think he can prod uTorrent author [16:27:05] <kshishkov> *andoma [16:27:10] <mru> or use rtorrent [16:27:15] <Dark_Shikari> kshishkov: they already know [16:27:18] <Dark_Shikari> it will be fixed in 2.0.1 [16:27:30] <Dark_Shikari> mru: today's xkcd is rather good [16:27:38] <mru> yeah [16:27:40] <twnqx> it breaks utorrent? [16:27:44] <Dark_Shikari> twnqx: yes [16:27:53] <twnqx> nooo i just have it queued up in 2.0 ;_; [16:27:54] <Dark_Shikari> almost 600 gigabytes [16:28:02] <Dark_Shikari> http://www.nyaatorrents.org/?page=torrentinfo&tid=113174 [16:28:03] <Dark_Shikari> read the info [16:28:06] <twnqx> yeah, that one [16:28:11] <elenril> wtf is TAK? [16:28:14] <Dark_Shikari> This torrent is so large it breaks all uTorrent versions up to and including 2.0 [16:28:17] <Dark_Shikari> Also possibly affected: Bitcomet and others. Verified unaffected: Azureus. [16:28:19] <twnqx> doesn't matter, i only have 190G disk space anyway. [16:28:20] <Dark_Shikari> Symptoms: on nonzero completion connections drop off in handshake phase. [16:28:32] <kshishkov> elenril: crappy lossless codec designed for Hydrogenaudio [16:28:50] <elenril> don't we have enough crappy lossless codecs already? [16:29:03] <kshishkov> it seems no [16:29:23] * av500 invents PCMROT13 [16:29:28] <av500> losless [16:29:35] <mru> Dark_Shikari: that facebook group is currently at 8100 members [16:29:48] <Dark_Shikari> lol [16:29:53] <kshishkov> av500: don't forget custom container for it [16:30:08] <elenril> btw [16:30:15] <elenril> anyone can apply nut metadata conv table for me? [16:30:40] <av500> kshishkov: of course [16:34:23] <KotH> Dark_Shikari: wtf? a 500G torrent? [16:34:28] <Dark_Shikari> KotH: 580GB [16:34:52] <kshishkov> that's more than capacity of all my HDDs combined [16:34:58] <Dark_Shikari> those are some very small hard drives [16:35:32] <twnqx> av500: the flash is put in in a way it's not writeable at all? [16:35:48] <twnqx> or is it locked? [16:35:54] <kshishkov> Dark_Shikari: why, two of them are whopping 160GB! [16:36:17] <twnqx> :S [16:36:25] <Dark_Shikari> kshishkov: I got a 2GB external for, like, $170 [16:36:25] <twnqx> i still have 3 of them, too [16:36:30] <Dark_Shikari> er [16:36:31] <Dark_Shikari> 2TB [16:36:41] <Dark_Shikari> a 160GB isn't even worth the space it takes up [16:36:47] <KotH> Dark_Shikari: i dont have that much free diskspace on a single disk anymore ^^' [16:36:55] * mru has a _spare_ 1TB drive [16:36:57] <Dark_Shikari> then get more disks [16:37:03] * twnqx too [16:37:05] <Dark_Shikari> my boss at facebook was setting up a 40-disk Raid Z [16:37:08] <mru> and piles of smaller ones [16:37:09] <Dark_Shikari> for his pirated movies [16:37:22] <KotH> Dark_Shikari: i know.. i dropped below 10% free diskspace quite some time ago [16:37:22] <Dark_Shikari> and he wasn't sure it would be big enough [16:37:29] <twnqx> lol [16:37:41] <kshishkov> Dark_Shikari: at least _I_ have free diskspace on all of them [16:38:11] <av500> twnqx: usually you can lock parts of the flash [16:38:20] <twnqx> i have a combined space of 553G on my two major arrays [16:38:28] <av500> this is a SW lock that you apply right after boot [16:38:32] <twnqx> i see [16:38:36] <av500> but it cannot be reversed [16:38:46] <av500> unless you power cycle the flash chip [16:38:46] <twnqx> only by cold start? [16:38:49] <twnqx> ok... [16:38:49] <av500> yup [16:39:02] <av500> difficult to do on a bga board [16:39:06] <Dark_Shikari> well this is why I use the lossy collection [16:39:07] <Dark_Shikari> it's only 110GB [16:39:12] <av500> and it would only help 1 player, not all of them [16:39:13] <twnqx> and i guess the ipod doesn't have a jtag interface? [16:39:15] <Dark_Shikari> leaves me more free space to waste on raw yuv [16:39:27] <twnqx> lol DS :P [16:39:36] <av500> twnqx: nice try [16:39:52] <twnqx> Dark_Shikari: /dev/mapper/raws 3.5T 3.4T 117G 97% /srv/nfs2 <- blurays are evil, too [16:39:56] <av500> we dont put jtag on production boards, only on debug [16:40:19] <twnqx> av500: many companied leave them in, just don't polace connectors on [16:40:40] <Dark_Shikari> yeah, blu-rays too. [16:40:41] <av500> twnqx: well, the ones that start with A dont [16:40:43] <Dark_Shikari> but those are at least compressed [16:41:02] <twnqx> flac is compressed, too. [16:41:17] <av500> 50GB plyray should have lot of place to uncompressed qvga yuv..... [16:41:18] <thresh> ur torrent so fat [16:41:19] <av500> bluray [16:41:55] <twnqx> unsoldering BGA is PITA [16:42:33] <twnqx> also, beyond the gear i (currently) have [16:42:44] <mru> unsoldering isn't so hard [16:42:51] <mru> it's putting it back that's a bitch [16:43:11] <twnqx> depends, if you have components on both sides and want to reuse the pcb... [16:43:39] <mru> you didn't say keeping the rest of the parts intact was a requirement [16:43:54] <twnqx> obviously it qould be if you want to "crack" an ipod [16:44:29] <mru> I'll show you how to crack it, see this brick here? [16:44:34] <kshishkov> use two of them ;) [16:44:55] <av500> twnqx: even if you unsolder one, if the boot code is good, it will not help you to open all of them [16:45:05] <twnqx> indeed [16:45:18] <av500> it might help you to find an exploit.... [16:45:35] <twnqx> unless you have a quantum computer and you only need the public part of the key :P [16:46:32] <twnqx> oh well, wanted to move away from crapple anyway [16:47:46] * twnqx needs to look at the B&O player [16:47:50] <Kovensky> <@Dark_Shikari> it's only 110GB <-- larger than my largest part :( [16:48:07] <Dark_Shikari> ? [16:49:14] <mru> twnqx: a quick look at their price tags is usually enough for me [16:50:32] <twnqx> "only mp3 and wma" was enough for me. [16:50:55] <twnqx> and i really doubt anyone even tries to put rockbox on :P [17:15:08] <superdump> Dark_Shikari: did you just say that your boss at facebook has a 40-disk RAID Z for pirated movies in a logged channel? [17:15:20] <superdump> :) [17:15:23] <elenril> lol [17:16:44] <Dark_Shikari> lol [17:16:50] <Dark_Shikari> this was like a year ago [17:16:59] <Dark_Shikari> and meh, logs [17:17:03] <kshishkov> superdump: and it's easy to find DS resume with whom to refer at FB. Hope MPAA won't hear about that [17:17:12] <Dark_Shikari> by pirated movies, of course, I mean pirate movies [17:17:22] <superdump> yarrr [17:17:25] <Dark_Shikari> yarr harrrrrrr [17:17:28] <superdump> boy does he like pirates? [17:17:31] <Dark_Shikari> lol [17:17:35] <superdump> fetish? [17:17:36] <elenril> isn't downloading legal in eagleland? [17:17:40] <Dark_Shikari> no [17:17:40] <superdump> well, that's his business [17:18:39] <elenril> w00t, mass effect 2 on zero punctuation [17:18:53] <Dark_Shikari> exactly [17:19:02] <Dark_Shikari> it's quite funny, and highly accurate [17:21:36] <kshishkov> would you believe that Bink Video decoder usually takes less CPU than audio? [17:21:42] <mru> there's still time for the bofh to purge the logs [17:21:59] <mru> of course that will require a small contribution from the offended party... [17:23:22] <av500> hmm, for AAC HE sample rate is 0 after avcodec_open() ?!? [17:23:31] <av500> so SDL seems to default to 22050 [17:24:04] <kshishkov> mru: do you think that KotH needs that kind of income? [17:24:25] <mru> KotH is not the irc log bofh [17:24:36] <kshishkov> av500: could be set after first decoded frame [17:24:52] <av500> yes [17:25:05] <av500> so, it is correct before we open, then 0, then correct again [17:25:59] <av500> and we do SDL_audio foo when it is 0.... [17:28:30] <thresh> where's a 'slow down a bit' button for that yahtzee guy [17:28:58] <kshishkov> thresh: we've discussed that today. "Turbo" buttons are gone now. [17:44:28] <elenril> lol, chest-high walls [17:45:11] * kshishkov remembers how "low wall" is translated into German [17:51:03] <av500> kshishkov: how? [17:51:27] <kshishkov> quite similar to certain Austrian last name [17:51:40] <superdump> niedermayer? [17:51:57] <superdump> wall is mauer isn't it? [17:52:05] <kshishkov> it is [17:52:11] <superdump> and low is...? [17:52:20] <superdump> nieder? :p [17:52:24] <kshishkov> that's why firewall is called "brandmauer" in Russian [17:52:39] <superdump> i only knew because i'd been to berlin [17:53:18] <superdump> niedrige mauer according to google [17:53:23] <superdump> well... pizza! [17:53:54] <kshishkov> superdump: you could also have learnt Ukrainian word for ham in Stockholm [18:00:11] <av500> kshishkov: more like "lower wall" [18:09:06] <BBB> anyone here good at ASF? [18:09:20] <BBB> would anyone know how caption streams are detectable in asf? [18:09:21] <jez9999> BBB: yep, as long as a patch gets checked in [18:09:32] <jez9999> my expertise is fully available :-D [18:09:53] <av500> BBB: have sample? [18:09:58] <kshishkov> av500: could be, Ich kenne Deutsche nicht [18:10:37] <kshishkov> BBB: apply patch from elenril and he'll tell you what he knows about asf [18:11:17] <BBB> av500, rtsp://live.cumulusstreaming.com/KFOG-FM [18:11:34] <BBB> and apply the following one-liner to libaformat/rtp_asf.c, at the end: [18:11:48] <BBB> +RTP_ASF_HANDLER(asf_pvd, "x-asp-pf", CODEC_TYPE_DATA); [18:12:02] <BBB> the last stream has captions [18:12:18] <BBB> I'm trying to figure out if we can support those without any more icky hacks in the rtp code, i.e. only modify asfdec.c [18:15:23] <BBB> jez9999, keep pinging me if I don't reply to bugs, I'm busy reviewing various patches so I sometimes forget [18:15:30] <BBB> I just added a response to issue1740 [18:17:43] * elenril doesn't know a thing about asf [18:18:04] <jez9999> BBB: what's the point in copying the filename into a local buffer? [18:25:51] <av500> BBB: ok, I see 2 streams, one audio, one unknown.. [18:28:18] <BBB> av500, right, the unknown is captions [18:28:39] <BBB> jez9999, other parts of ffmpeg might expect the filename to remain unmodified [18:29:18] <jez9999> BBB: its modification is opaque [18:29:27] <jez9999> it's modified right back after the open() [18:38:05] <BBB> jez9999, I know, it's why I didn't make an issue of it [18:38:13] <BBB> jez9999, but it's modified, although even just for a split second [18:38:16] <jez9999> lol [18:38:20] <BBB> jez9999, that's not good for threaded applications [18:38:26] <BBB> which is what Michael is concerned about [18:38:34] <BBB> just change it, it's the right thing, even though it might sound odd [18:38:50] <jez9999> you want me to submit a new patch? you know it would take you 5 seconds to add it in [18:39:05] <BBB> submit it, I'm OK with it, so wait for Michael to say yes [18:39:08] <BBB> and I'll apply it [18:39:11] <BBB> that's all I do apparently :) [18:39:29] <jez9999> why does this have to go through Michael? most stuff doesnt [18:39:33] <BBB> note that michael didn't say "yes" or "no", he said nothing :) [18:39:37] <BBB> because michael maintains file.c [18:39:44] <jez9999> so he doesnt mind then [18:39:45] <jez9999> :-) [18:39:52] <BBB> that's not how he works :) [18:39:53] <jez9999> neutral from Michael is a ringing endorsement [18:40:36] * kierank likes the logic [18:47:40] <Dark_Shikari> kshishkov: got v2 to review yet? [18:48:15] <kshishkov> I should have attached it [18:50:52] <kshishkov> it seems I did - in reply to your short mail [18:51:17] <Dark_Shikari> ah there. [19:05:45] <Dark_Shikari> kshishkov: what's with the weird run length coding in block types [19:07:43] <Dark_Shikari> kshishkov: mind if I give you some suggestions here on IRC instead (with the assumption of quick response)? [19:08:34] <kshishkov> it's not weird [19:08:48] <kshishkov> it just uses some different scan orders [19:08:55] <kshishkov> I even posted about it once [19:09:06] <Dark_Shikari> I meant that the only run lengths allowed are 4,8, 12, and 32 [19:09:15] <kshishkov> ah, those [19:09:31] <BBB> who's root? [19:09:39] <BBB> I would like a svn account for someone [19:09:42] <kshishkov> BBB: KotH+mru+DonDiego [19:09:48] <kshishkov> ask any of them [19:09:51] <BBB> ok [19:10:18] <BBB> mru: ping, dondiego: ping </massping> [19:10:24] <kshishkov> Dark_Shikari: yes, IIRC it's just high 4 of 16 possible symbols in some Huffman coding scheme are used for denoting runs [19:10:46] <Dark_Shikari> that's weird. [19:10:53] <Dark_Shikari> ok, so first idea [19:10:59] <Dark_Shikari> "i" is only used as the loop counter, not in the loop [19:11:02] <Dark_Shikari> so try this [19:11:10] <Dark_Shikari> end = b->cur_dec + t [19:11:16] <Dark_Shikari> while( b->cur_dec < end ) [19:11:22] <Dark_Shikari> then you don't need the i += line [19:11:32] <Dark_Shikari> wait, something is weird there [19:11:39] <Dark_Shikari> why does the run code increment i, but the first bit doesn't? [19:11:43] <Dark_Shikari> oh, because of the i++. [19:11:53] <Dark_Shikari> ok, so this will get faster with a while instead, simpler too. [19:12:07] <BBB> end = b->cur_dec + t is still an initialization, so use for(end = ..; .. < ..;) [19:12:13] <kshishkov> indeed [19:12:17] <Dark_Shikari> BBB: works too. [19:12:27] * BBB is a for()-fan [19:12:40] * kshishkov is "whatever works" fan [19:12:44] <BBB> :) [19:12:46] <Dark_Shikari> ok, so that fine? [19:13:01] <Dark_Shikari> same with read_patterns [19:13:01] <kshishkov> yes, looks ok [19:13:11] <Dark_Shikari> you have a lot of similar loops in which the loop counter is not used for anything [19:13:12] * kshishkov likes approving reviews on his patches [19:13:34] <Dark_Shikari> it might be a little bit uglier to remove the loop counter, but there's really no reason to have it. [19:13:39] <mru> BBB: pong [19:13:41] <Dark_Shikari> You should probably bench read_patterns for starters though [19:13:51] <Dark_Shikari> because it's so simple that it's a good benchmark case to see if this is actually a good idea. [19:14:02] <BBB> mru: can martin have svn access? [19:14:08] <mru> not my call [19:14:15] <mru> but I don't mind [19:14:17] <BBB> who's call is that? [19:14:21] <BBB> michael was ok with it [19:14:45] <Dark_Shikari> lines 1039 and 1040 in the patch can be merged [19:14:51] <Dark_Shikari> same with 1026/1027 [19:14:57] <mru> DonDiego usually handles that stuff [19:15:45] <BBB> ok, I'll bug him then, thanks though [19:16:04] <Dark_Shikari> kshishkov: errors like 1086 should probably have error messages, like in h264 decoding [19:16:38] <Dark_Shikari> 1063-1072 seems a bit silly, why not just do v = get_bits(gb, start_bits - has_sign) ? [19:16:47] <Dark_Shikari> and then if(has_Sign && v) [19:16:58] <Dark_Shikari> it looks like the code doesn't run a lot, so it doesn't need to be optimized at the expense of size. [19:18:18] <kshishkov> I don't like adding avctx as a parameter to each function needing it only for av_log() [19:18:27] <Dark_Shikari> ah. [19:18:36] <Dark_Shikari> you don't need avctx to log [19:18:41] <Dark_Shikari> it'll just say @ NULL [19:19:14] <kshishkov> it's frowned upon here [19:19:40] <Dark_Shikari> is read_dct_coeffs faster if you make mode_list a 2D array instead of packing nibbles like that? [19:19:55] <Dark_Shikari> not saying it would be for sure, but since it's local stack data only, it's not like it has cache effects [19:19:58] <Dark_Shikari> so you should test. [19:20:23] <kshishkov> ok [19:20:52] <Dark_Shikari> same with read_residue [19:21:09] <Dark_Shikari> 1238-41 can be branchless maybe? [19:21:12] <BBB> kshishkov, don't forget gcc inlines everything into one huge big function anyway, so it's not like function arguments matter... [19:21:43] <Dark_Shikari> this is true. [19:21:56] <Dark_Shikari> 1265 can be branchless [19:22:01] <Dark_Shikari> 1281 too [19:22:12] <kshishkov> no, I think 1238-41 will be too obfuscated then [19:22:35] <kshishkov> for 65 and 81 - yes [19:23:12] <Dark_Shikari> why didn't you take into account my scaled block idea, i.e. sclaed blocks work exactly like normal ones [19:23:15] <Dark_Shikari> and use the same code [19:23:17] <Dark_Shikari> rather than duplicated code [19:23:20] <Dark_Shikari> or is there some reason that won't work [19:23:49] <kshishkov> first of all - they need intermediate storage [19:24:11] <Dark_Shikari> 1402-1403: why do these lines exist? [19:24:14] <kshishkov> second, I need to add some checks on unallowed block types [19:24:49] <kshishkov> err, because there's no corresponding function in dsputil and I'm not sure it should be there? [19:24:58] <CIA-90> ffmpeg: rbultje * r21862 /trunk/libavformat/rtsp.c: [19:24:58] <CIA-90> ffmpeg: Add functions to send RTSP commands with content attached to them. This will [19:24:58] <CIA-90> ffmpeg: be used eventually in the RTSP muxer (see thread "[PATCH] RTSP muxer, round [19:24:58] <CIA-90> ffmpeg: 3" on mailinglist). [19:24:58] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>. [19:25:15] <Dark_Shikari> there's no put_pixels_unclamped? [19:25:53] <kshishkov> no [19:25:59] <Dark_Shikari> there's a clamped, right? [19:26:01] <Dark_Shikari> so make an unclamped. [19:26:22] <Dark_Shikari> and why "unfortunately" [19:26:38] <kshishkov> more work for me, obviously [19:26:47] <Dark_Shikari> lol [19:26:56] <Dark_Shikari> ok, moving on from there... pattern blocks [19:27:01] <Dark_Shikari> this can be done far far more efficiently [19:27:23] <Dark_Shikari> col0 = get_value() [19:27:25] <Dark_Shikari> col1 = get_value() [19:27:36] <Dark_Shikari> pattern = col0 + (col1<<8) [19:27:37] <kshishkov> and multiply by two masks? [19:28:02] <Dark_Shikari> uint64_t patternlarge = pattern * 0x10001000 .... ULL [19:28:05] <Dark_Shikari> *(uint64_t*)ublock = pattern [19:28:16] <Dark_Shikari> or, er, 0x000100010001 [19:28:31] <Dark_Shikari> hell, just fuck that and use fill_rectangle [19:28:33] <Dark_Shikari> that's what it's _for_ [19:28:42] <kshishkov> it's random, not checkerboard [19:29:00] <Dark_Shikari> ahhhh [19:29:32] <Dark_Shikari> ok, ignore that. [19:29:37] <Dark_Shikari> but consider fill_rectangle as an option in other places. [19:30:19] <Dark_Shikari> dst[(pos & 7) + (pos >> 3) * stride] = v; [19:30:21] <kshishkov> too small for fill_block, hence two new funcs in dsputil [19:30:22] <Dark_Shikari> I thought you got rid of that? [19:30:57] <kshishkov> only for scaled blocks [19:31:02] <Dark_Shikari> why not for regular [19:32:01] <kshishkov> they output straight to output plane instead of 64-byte buffer and keeping two version of 16 scans is not good [19:32:13] <Dark_Shikari> you're already keeping two versions [19:32:18] <Dark_Shikari> one for scaled, one for unscaled [19:32:27] <kshishkov> same data [19:32:34] <Dark_Shikari> ah. [19:32:50] <Dark_Shikari> then make some nice macro to hide it [19:32:55] <Dark_Shikari> it looks ugly and duplicated code [19:33:42] <kshishkov> ok [19:34:22] <Dark_Shikari> 1783/1784 should use write-combining [19:34:56] <Dark_Shikari> 1787/1788 should just have linesize be <<=1 at the start [19:34:59] <Dark_Shikari> rather than doing it in each iteration [19:35:05] <kshishkov> AV_WN16(dst, pix*0x0101) ? [19:35:09] <Dark_Shikari> I guess. [19:35:15] <Dark_Shikari> depending on whether or not the destination is aligned or not [19:35:24] <Dark_Shikari> pick the aligned vs unaligned macro [19:35:28] <kshishkov> it is always 8-aligned [19:35:48] <kshishkov> we operate on 8x8 blocks at least [19:35:52] <Dark_Shikari> meaning each block of 2 is always 2 aligned [19:35:56] <Dark_Shikari> which is good enough [19:38:55] <Honoome> elenril: is the metadata/mov artist fix in svn already, or should I look into it? :P [19:40:30] <kshishkov> Honoome: IIRC he begged to apply his patch for something, so you can help [19:40:58] <elenril> Honoome: not yet [19:41:10] <Honoome> kshishkov: if nobody beats me I'll do that during the weekend, no time today :/ but if it was in svn I would have asked the gentoo maintainer for a new snapshot ;) [19:41:12] * elenril is pretending to be studying atm, will look at it tomorrow [19:41:26] <Honoome> anyway, I'm signing off since tomorrow morning I have to wake up [19:43:24] <DonDiego> gnite [19:43:37] <kshishkov> as you Diegos say [19:45:56] <twnqx> are language tags for streams possible in avi? [19:48:09] <elenril> iirc yes [19:51:36] <elenril> http://abcavi.kibi.ru/infotags.htm i think IAS* are supposed to do this [19:52:11] <elenril> why would you want to create such an abomination though? [19:52:46] <twnqx> see main channel. guy is asking how to set language tags for his avi >_> [19:54:32] <twnqx> put_le16(pb, 0); /* language */ [19:54:33] <twnqx> hmmmm [19:55:28] <elenril> don't expect any more documentation than that ;) [19:58:23] <mru> that's not even doxygen [20:03:53] <mru> anyone know what compilers do/don't support aligning stack variables to 8/16 bytes on x86? [20:04:17] <BBB> DonDiego, ping! [20:05:12] <DonDiego> pong [20:07:29] <DonDiego> what's up? [20:09:40] <Dark_Shikari> mru: MSVC, ICC [20:09:43] <Dark_Shikari> er [20:09:47] <Dark_Shikari> yeah, and ICL [20:09:59] <mru> of the ones relevant for ffmpeg? [20:10:02] <Dark_Shikari> ICC [20:10:06] <mru> can or can't? [20:10:09] <Dark_Shikari> can't [20:10:13] <Dark_Shikari> those are ones that can't [20:10:18] <mru> and gcc can? [20:10:20] <Dark_Shikari> yes [20:10:26] <mru> icc can't even 8? [20:10:29] <Dark_Shikari> not sure. [20:10:31] <mru> guess not [20:10:35] <mru> abi requires only 4 [20:15:59] <pengvado> err, I thought ICC can align variables, it just doesn't align the stack pointer, thus breaking a few asm functions that do it the gcc way. [20:17:58] <BBB> DonDiego, can you give martin storsjo a svn account? [20:22:39] <Dark_Shikari> pengvado: oh, you're right [20:22:41] <Dark_Shikari> yeah, that's true [20:22:43] <Dark_Shikari> same with MSVC [20:22:48] <Dark_Shikari> so yeah, both MSVC and ICC align variables but not stack [20:23:05] <Dark_Shikari> btw, random bug report, not sure if anyone knows about this sort of thing [20:23:13] <Dark_Shikari> suppose I have two files [20:23:17] <Dark_Shikari> 1.mp4: h264 + aac in mp4 [20:23:21] <Dark_Shikari> 2.mp4: mjpeg in mov [20:23:37] <Dark_Shikari> I merge these into a single mp4 using ffmpeg and vcodec copy, acodec copy, newvideo/vcodec copy. [20:23:43] <Dark_Shikari> when muxing, for the h264 video track, it says "vidoe: 0x0021" [20:23:47] <Dark_Shikari> instead of "video: h264" [20:23:56] <Dark_Shikari> But it does it correctly, and when you use ffmpeg -i on the resulting file, it says h264. [20:27:59] <DonDiego> BBB: yes [20:28:05] <DonDiego> i can [20:28:11] <DonDiego> now what? :) [20:37:06] <CIA-90> ffmpeg: mru * r21863 /trunk/libavcodec/dsputil.c: [20:37:06] <CIA-90> ffmpeg: Simplify some declarations of aligned arrays [20:37:06] <CIA-90> ffmpeg: If DECLARE_ALIGNED_16 works on uint64_t it will work smaller types too. [20:37:06] <CIA-90> ffmpeg: mru * r21864 /trunk/ (configure libavcodec/dsputil.h): Add LOCAL_ALIGNED() macro for declaring aligned local arrays [20:37:06] <CIA-90> ffmpeg: mru * r21865 /trunk/configure: PPC and x86 support aligning variables on stack [20:37:07] <CIA-90> ffmpeg: mru * r21866 /trunk/libavcodec/ (7 files): Use LOCAL_ALIGNED macro for local arrays [20:38:47] <BBB> dondiego: if possible, could you actually do it? :) [20:39:30] * DonDiego makes up username and password from thin air [20:40:20] <DonDiego> isn't the procedure clear by now? [20:40:25] * janneg hands DonDiego /dev/random [20:41:44] <ohsix> mstorsjo `uuidgen` [20:44:29] <peloverde> Was just changing the test specs on those demuxers really the correct answer? [20:44:49] <mru> michael says so [20:45:20] <peloverde> I look at for instance PVA demux and it does not look right: http://fate.multimedia.cx/index.php?test_result=44445708 [20:45:50] <peloverde> mpeg_decode_postinit() failure with 6 errors and half the previous frames [20:46:08] <mru> send email [20:46:29] <DonDiego> BBB: i need username and pw for martin [20:48:21] <peloverde> I did, I tracked down the commit and michael tried to shift the blame [20:49:03] * DonDiego bites his tongue :) [20:49:10] <mru> bitching here won't help [20:49:33] <mru> at least not until michael reads the logs [20:49:39] <mru> they are mailed at midnight UTC [20:49:58] <peloverde> I figure maybe when he greps for his name he will see it and give it another look [20:54:36] <BBB> dondiego: dondiego: how would I know these? [20:54:49] <DonDiego> BBB: well, how would i? [20:54:58] <DonDiego> 21:40 <@DonDiego> isn't the procedure clear by now? [20:55:03] <BBB> dondiego: not sure :) do you want me to ask him to email you? [20:55:24] <DonDiego> this makes me assume the answer is "no" [20:55:31] <BBB> indeed :) [20:55:38] * BBB assumes there's a doc that he missed or so [20:55:40] <DonDiego> well, then just say so :) [20:55:47] <BBB> I have no idea :) [20:58:22] <DonDiego> i need to have username and pw sent to me, encrypted with my gpg key [20:58:46] <ohsix> mash his name together for the username and generate a password [20:58:47] <DonDiego> where would be a good place to document this? [21:01:38] <janneg> DonDiego: developer policy [21:03:52] <janneg> s/er/ment/ [21:05:46] <CIA-90> ffmpeg: mru * r21867 /trunk/libavcodec/dsputil.h: 10l: remove stray '(' I don't know where it came from [21:06:41] <Dark_Shikari> it came from the parenthesis factory [21:07:29] <mru> maybe it leaked in from some lisp code [21:07:43] <BBB> dondiego: you're talking black magic to me [21:08:00] <BBB> dondiego: but I'll forward the msg to him anyway :) [21:09:10] <DonDiego> what part could be black magic? [21:09:19] <DonDiego> you do have a user account yourself.. [21:09:23] <BBB> your gpg key, for example [21:09:35] <BBB> back then you sent me the pwd as a text msg to my cell phone [21:09:37] <BBB> I think [21:09:49] <BBB> I added it to my keychain and have no idea what it is [21:09:51] <BBB> but it still works [21:09:51] <DonDiego> that's a possibility as well [21:10:02] <mru> BBB: yeah, but gsm encryption was hacked since then [21:10:10] <DonDiego> i assume you do know what gpg is, don't you? [21:10:19] <peloverde> hmm.... The mpeg_decode_postinit happens in r21624, sorry michael! fate needs a better way of tracking this stuff [21:10:20] <mru> gpg is a misnomer [21:10:22] <mru> you mean pgp [21:10:42] <mru> gpg is but one implementation [21:10:52] <DonDiego> true that.. [21:11:07] <DonDiego> but it's the free one, and the default one in our circles.. [21:11:16] <mru> so? [21:11:29] <mru> it's like saying x264 when you mean h264 [21:11:56] <peloverde> PGP is a registered trademark h.264 isn't [21:12:12] <mru> linux is a registered trademark [21:12:18] <mru> and unix [21:12:37] <peloverde> yes and when we say Linux to refer to Linux that is legit [21:12:42] <mru> lots of standards have trademarked names [21:12:50] <peloverde> If we use the name Linux to refer to FreeBSD that isn't [21:12:58] <Dark_Shikari> mru: doesn't gpg use its own format? [21:13:03] <Dark_Shikari> even though it's the same algorithm [21:13:19] <mru> Dark_Shikari: it supports the standard key exchange format [21:13:26] <Dark_Shikari> ah k [21:13:31] <mru> although it normally keeps keys in a different format [21:13:36] <mru> as does the commercial pgp app [21:13:41] <peloverde> PGP is a program, GPG is a program OpenPGP is a format [21:14:13] <mru> back in the old days, it was all just pgp [21:14:23] <peloverde> it isn't 1991 anymore [21:14:30] <mru> and you got it in printed books [21:21:34] <CIA-90> ffmpeg: alexc * r21868 /trunk/libavcodec/get_bits.h: get_bits: Fix spelling and grammar in GET_VLC() comment. [21:21:38] <peloverde> DonDiego: I'm surprised you never caught that one ^^ [21:21:56] <DonDiego> :) [21:22:17] <peloverde> if...than makes my eyes bleed [21:22:22] <mru> he's obviously never used the macro [21:32:57] <BBB> dondiego: I sort of know pgpgpg [21:33:00] <BBB> but I don't use it :) [21:33:09] <BBB> DonDiego, but don't forget, this is not for me, it's for martin [21:33:17] <BBB> might be easier if you discuss with him, perhaps by email? [21:38:23] <CIA-90> ffmpeg: mru * r21869 /trunk/configure: configure: allow setting strip tool with --strip [21:38:23] <CIA-90> ffmpeg: mru * r21870 /trunk/tests/regression-funcs.sh: Use stripped executable in regression tests [21:40:17] <twnqx> is there a high chance that mjpeg in swf is broken? [21:40:29] <twnqx> decoder, that is [21:40:35] <Dark_Shikari> mjpeg can go in swf? [21:40:43] <twnqx> Input #0, swf, from 'nj_chapterninjai11_bb.swf?cpcode=35395': [21:40:43] <twnqx> Duration: 00:19:18.59, bitrate: 128 kb/s [21:40:44] <twnqx> Stream #0.0: Audio: mp3, 44100 Hz, 2 channels, s16, 128 kb/s [21:40:44] <twnqx> Stream #0.1: Video: mjpeg, yuvj420p, 600x250 [PAR 72:72 DAR 12:5], 24 tbr, 24 tbn, 24 tbc [21:41:20] <peloverde> Dark_Shikari: it doesn't seem like a surprise a lot of garbage can go in an swf [21:41:22] <twnqx> just resolution flips all around, ffplay hangs after a second [21:41:30] <twnqx> mplayer just segfaults [21:41:54] <Dark_Shikari> maybe it's actually a bunch of jpegs [21:42:43] <twnqx> it's chapter 11 of ninjai :X [21:43:25] <mru> jai? [21:43:28] <mru> ninja? [21:43:29] <mru> hmm... [21:44:39] <twnqx> plays in constant resolution in flash [21:51:09] <Vitor1001> peloverde: BTW, sorry for the red herring [21:51:10] <Vitor1001> :( [21:51:47] <peloverde> Vitor1001: It's alright, I think I flew off the handle a little bit there [21:52:35] <peloverde> I'm trying to get SBR landed before I finish PS [21:53:24] <peloverde> and separating the div cases which I needed to do to try the inplace butterflies did give me a speed up so i kept that part [21:57:04] <Vitor1001> You're working already in PS? [21:57:07] <Vitor1001> Nice \o/ [21:57:24] <peloverde> PS is what I'm getting paid for, and I haven't been paid in quite a while [21:57:57] <Vitor1001> Nice, even better than doing it for free ;) [21:58:04] <peloverde> indeed [21:58:58] <twnqx> what is that PS thing, actually? mpeg program stream? [21:59:06] <Kovensky> Parametric Stereo [21:59:11] <Kovensky> HE-AAC+ [21:59:13] <twnqx> ah [21:59:16] <peloverde> mpeg4 parametric stereo [22:00:21] <peloverde> I wonder if it's in 13818-7, that's generally 100x easier to read [22:00:40] <peloverde> except lately 14496-3 and 13818-7 have gotten lazy about cross referencing each other [22:01:21] <kierank> i hate it when specs cross reference each other [22:01:30] <mru> and you have to pay for both [22:01:32] <mru> grrr [22:02:05] <kierank> I'm almost certain the spdif ones are deliberately done so you have to pay for about 10 specs [22:02:25] <mru> 1. take 10 specs [22:02:32] <mru> 2. interleave the pages [22:02:46] <mru> 3. split the lot in equal-size chunks [22:02:48] <mru> 4. ... [22:02:57] <mru> 5. profit [22:02:59] <janneg> profit [22:03:12] <twnqx> as in "5. profit \o/" [22:03:21] <drv> add salt to taste and serve on lightly toasted bread [22:03:39] <kierank> it's nice however when the local government has paid for full access to all british specs. It's nice downloading one massive spec with price £350 or something and just thinking haaa screw you standards bodies [22:04:30] <mru> which govt is that? [22:04:38] <kierank> essex county council [22:04:51] <kierank> only found out about it a few weeks ago [22:04:59] <mru> you work at the council? [22:05:02] <kierank> no [22:05:09] <kierank> through the public library [22:05:12] <mru> ah [22:05:19] <mru> nice [22:06:31] <kierank> I wonder what the most expensive spec is [22:08:04] <mru> no "sort by price" option? [22:08:27] <kierank> doesn't seem to be available [22:13:47] <peloverde> blol after giving up on editing mpeg-4 audio related articles on wikipedia they are now citing stuff I wrote for wiki.multimedia.cx [22:13:49] <twnqx> VP6F... how many VP6 variants are there? :S [22:14:11] <mru> at least 6 ;-) [22:32:36] <tborg> mru, you could do me a big favor and test the just posted patch for "Buffer overflow in ALS decoder" while I'm still online today... approx. one hour left... [22:33:38] <mru> on it [22:33:57] <tborg> :) [22:36:16] <mru> runs cleanly now [22:36:36] <tborg> thank you! [22:54:17] <CIA-90> ffmpeg: thilo.borgmann * r21871 /trunk/libavcodec/alsdec.c: Fix wrong buffer allocation for MCC in ALS. [23:27:40] <CIA-90> ffmpeg: thilo.borgmann * r21872 /trunk/libavcodec/alsdec.c: Fix sizeof()-statement to use the actual pointer type. [23:44:37] <BBB> Vitor1001, I'm affraid postfilter will take a while, I don't understand anything of that fft stuff [23:44:48] <BBB> Vitor1001, any advice on the best way to figure out what that fft stuff is doing? [23:45:11] <Vitor1001> Did you suceeded in using FFmpeg fft funcs? [23:46:02] <BBB> no [23:46:07] <BBB> or well, I can use them [23:46:09] <Vitor1001> :( [23:46:12] <BBB> but the output is completely different [23:46:24] <BBB> I tried mdct, fft, rdft and something else [23:46:35] <BBB> I still think it's rdft [23:46:40] <Vitor1001> And the problem is beyond some scaling? [23:46:43] <BBB> but it probably does something after rdft [23:46:45] <BBB> yes [23:46:59] <Vitor1001> which func? [23:47:05] <BBB> com_wmsfft.c, all three [23:47:21] <Vitor1001> none of them was something familiar? [23:47:21] <BBB> I'm working on the second now [23:47:31] <BBB> it looks like rdft [23:47:32] <BBB> a lot [23:48:04] <Vitor1001> do you have something easily compilable? [23:48:13] <BBB> ? [23:48:23] <Vitor1001> Some patch I can give a look [23:48:27] <BBB> ah [23:48:37] <BBB> I can give you the RE-version of my postfilter patch [23:48:46] <BBB> but it includes all kind of fuzzy code from the binary [23:48:48] <BBB> is that ok? [23:48:57] <Vitor1001> sure [23:51:24] <BBB> you want it by mail? [23:51:33] <Vitor1001> yes, its better... [23:51:57] <BBB> sent [23:52:17] <BBB> there's some debug code in com_wmsapf.c, don't pay attention to that please :) [23:52:30] <BBB> and there's a lot of cruft in com_wmsfft.c, which is what I'm trying to do [23:52:53] <BBB> I was thinking of making a float version of the first function and just look how similar it is to rdft in float [23:53:09] <Vitor1001> sure, I'll give a look at it now [23:56:34] <Vitor1001> I wonder what the hell they are doing, there are not a thousand ways to do a FFT :p [23:58:13] <BBB> my guess is that the two bottom functions are the inverse of one another, like rdft vs. irdft [23:58:24] <BBB> and then the top function is the fft_permute/calc [23:58:49] <BBB> but like I said, very confusing [23:59:53] <CIA-90> ffmpeg: mru * r21873 /trunk/libavcodec/ (get_bits.h x86/mathops.h mathops.h): Move NEG_[US]SR32 macros to mathops.h