Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2010

1 participants
28 discussions

IRC log for 2010-02-17
by irc＠mansr.com 18 Feb '10

18 Feb '10

[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-… [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

1 0

IRC log for 2010-02-16
by irc＠mansr.com 17 Feb '10

17 Feb '10

[00:02:02] <Kovensky> I have only seen two options in ffms2theora when I tried it [00:02:09] <Kovensky> both were ratecontrol related [00:02:16] <Dark_Shikari> yes, you can pick the bitrate or quality [00:02:18] <Dark_Shikari> and 2-pass or not [00:02:20] <Dark_Shikari> and gop size. [00:02:21] <Dark_Shikari> and that's it. [00:02:30] <Dark_Shikari> vbv? why would anyone want _that_? [00:02:32] <Kovensky> oh, there was gop size [00:03:01] <Kovensky> Dark_Shikari: the 2-pass thing is moot, at least according to Daiz [00:03:11] <Kovensky> ffms2theora instacrashes on pass=2 [00:04:02] <Dark_Shikari> lol [00:04:07] <Dark_Shikari> don't compare moot to theora [00:04:10] <Dark_Shikari> moot is much better [00:04:12] <Yuvi> you can also choose to do no ME or disable fast skip [00:04:44] <mru> lol [00:10:28] <CIA-34> ffmpeg: michael * r21844 /trunk/libavcodec/h264_cabac.c: Drop a few redundant slice_num checks. [00:17:41] <peloverde> Odd that the FOSDEM talks are all in xvid avi... At least it's not ogg [00:18:08] <Dark_Shikari> lol xvid [00:18:27] <Yuvi> the live broadcast was wmv with swapped uv planes iirc [00:18:31] <Dark_Shikari> lol [00:18:35] <Dark_Shikari> WMV [00:18:38] <Dark_Shikari> from FOSDEM [00:18:39] <Honoome> uhm interesting read about extern inlines and SunCC… although I still find the whole thing braindamaged [00:18:59] <Honoome> Yuvi: really? okay next year me and lu_zero need to manage that :P [00:19:50] <peloverde> Dark_Shikari: the freetards love WMV because you can buy a plugin from fluendo [00:20:07] <Dark_Shikari> lol [00:20:17] <BBB> I always found that funny [00:20:26] <BBB> fluendo can just use free software, like ffmpeg, stamp a license on it [00:20:29] <BBB> and we're all happy [00:20:45] <BBB> but somehow they reagainreinvented the wheel and everyone is happy [00:21:00] <Dark_Shikari> no, pretty much just the freetards are happy [00:21:01] <peloverde> some people question that interpretation of theLGPL2 [00:21:08] <Dark_Shikari> all the people who actually care about open source aren't happy [00:21:21] <Dark_Shikari> it's sad that the biggest threat to open source is from people who claim to support it [00:21:23] <Honoome> BBB: I guess it's sorta like the RMS and his selling of indulgences for dual-licensed software [00:21:42] <Dark_Shikari> but I guess that's always true. [00:23:12] * Honoome had a fight tonight as well with an acquaintance of his… “Silverlight is proprietary, Flash was better”… [00:23:29] <Dark_Shikari> lol [00:23:34] <Dark_Shikari> Technically, flash actually is open [00:23:35] <Honoome> too bad that we have a silverlight-compatible full implementation that works, and is free software… yet we have none complete for Flash… [00:23:47] <BBB> when the tax stuff is done, I'll go to the sflc and put some stuff on paper for good money [00:23:54] <BBB> then fun starts [00:24:09] <BBB> put it on planet.gnome, just a scan, and let hell break loose [00:24:32] <peloverde> I tend to try to avoid both of them when possible [00:24:34] <Dark_Shikari> BBB: want a contribution? [00:24:59] <BBB> always [00:25:10] <Honoome> peloverde: me as well but if I have to choose I pick the one that I can look at the source of ;) [00:25:10] <BBB> patent numbers are welcome ;) [00:26:30] <peloverde> OTOH, flash is proliferated enough that I need it [00:26:38] <peloverde> Also I thought moonlight doesn't support silverlight DRM [00:26:53] <Honoome> I think they are working on it [00:27:03] <Dark_Shikari> lol [00:27:09] <Dark_Shikari> freetards supporting drm [00:27:26] <Honoome> but for the case in place that I ended up fighting about (Italian national TV) there is no DRM [00:27:29] <Honoome> and works pretty well with Moonlight [00:27:49] <peloverde> If hulu offered silverlight and didn't require the DRM I'd gladly choose that option [00:28:07] <peloverde> but my guess is that they would require it should they go that route [00:28:24] * Honoome lives outside US so … nothing there anyway [00:30:01] <peloverde> Also another thing that irks me about silverlight is streaming sites that require it and just stream mp4, why not offer quicktime plugin or flash or <video>, why do i need to install yet another plugin to view your shit. You can serve the same assets to all of the above [00:30:41] <mru> and then there's the theora decoder running on the mono vm... [00:30:55] <Dark_Shikari> lol [00:31:01] <mru> it's been done [00:31:07] <Honoome> peloverde: I love greasemonkey for that [00:31:28] <mru> I don't know exactly what he did [00:31:34] <peloverde> the quality of theora with the speed of managed code, you can't lose [00:32:43] <Dark_Shikari> lol [01:58:41] <Yuvi> I could've sworn clang required an = with -isysroot, now it only works without one [02:52:24] <CIA-34> ffmpeg: michael * r21845 /trunk/libavcodec/h264_cabac.c: 2 cpu cycles faster context calculation for decode_cabac_intra_mb_type() [06:38:40] <elenril> morning [06:42:48] <kshishkov> god morgon [06:43:08] <KotH> moikka moi [06:47:05] * elenril looks around for volunteers to apply his patch [06:47:37] <kshishkov> try with banana [06:49:19] * elenril puts a <banana> in the channel [07:17:51] <andoma> mru: a classic ... imagine what happend at the office when the ppl around here found out :) [09:23:07] <mru> morning [09:23:15] <kshishkov> god morgon [09:24:36] <pJok> god morgen [09:25:40] <av500> Guten Morgen [09:29:29] <kshishkov> mate! [09:30:46] <pross-au> Hey [09:32:45] <kshishkov> looks like BIKb should be made as totally separate decoder [09:34:04] <pross-au> Yeah? [09:34:20] <pross-au> there is no dct [09:34:35] <kshishkov> that's not the problem [09:34:49] <CIA-34> ffmpeg: pross * r21846 /trunk/libavcodec/iff.c: Support <8-bit ILBM uncompressed bitmaps [09:34:54] <kshishkov> coding methods could be piled up during those years [09:35:35] <kshishkov> but in your case almost everything differs [09:36:46] <pross-au> oh okay [09:37:35] <pross-au> so we'll need CODEC_ID_BINK_B ? [09:37:41] <kshishkov> yes [09:38:28] <pross-au> imho you should s/CODEC_ID_BINK/CODEC_ID_BINKVIDEO/g [09:38:49] <kshishkov> I do already [09:39:01] <pross-au> some years ago, i searched high & low for other BIK'x' revisions [09:39:10] <pross-au> couldnt find any [09:40:46] <kshishkov> you can try the whole list of games using RAD codecs [09:41:48] <pross-au> I've tried a lot [09:41:52] <pross-au> haha [09:42:01] <pross-au> BIKd ? [09:42:41] <kshishkov> never seen that [09:42:49] <kshishkov> let's see for the samples... http://radgametools.com/binkgames.htm#games [09:42:59] <pross-au> somebody has put it on the multimedia wiki [09:43:21] <pross-au> ah it was vlad [09:56:47] <CIA-34> ffmpeg: pross * r21847 /trunk/libavformat/iff.c: Support IFF ANNO (annotation) chunk type [10:20:55] <B4gder> regarding my previous visit here about a "Rockbox and ffmpeg coordination effort", here's what's been discussed in the R camp http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-02/0019.shtml [10:22:01] <Dark_Shikari> avoiding forks sounds good [10:22:19] <B4gder> yes indeed, nobody wins on forks in the long run [10:22:42] <mru> good, first objective achieved [10:22:50] <B4gder> Mike and Mohamed to reply in that thread are both codec hackers [10:22:56] <B4gder> who reply [10:23:54] <mru> why do you guys split the codecs like that? [10:24:00] <B4gder> split? [10:24:03] <mru> "Porting codecs to rockbox generally entails isolation of the codecs, ..." [10:24:07] <av500> mru: there is infrastructure in ffmpeg to select fixed vs float codec? at build time? [10:24:28] <mru> all codecs in ffmpeg are either fixed-only or float-only [10:24:29] <B4gder> ah yes, because we pick each codec on their own merit [10:24:41] <B4gder> so when we get a codec from ffmpeg, we get only that single one [10:24:44] <mru> ffmpeg has configure flags to enable only what you want [10:25:44] <B4gder> and also, I think those are questions and thoughts worth to discuss if we can find a way to better work so both teams get happier [10:26:09] <mru> if our configure options are not sufficient, that's something we can work on [10:26:17] <mru> I know they can be improved in some areas [10:26:42] <av500> there is the no-malloc issue of rb codecs, no? [10:26:48] <B4gder> yes [10:26:54] <mru> we don't use malloc all that much [10:27:05] <Dark_Shikari> why no malloc? malloc-everything-at-start is equivalent to alloca [10:27:11] <B4gder> but the truth is we actually have some "fake malloc" to work with some of them [10:27:19] <Dark_Shikari> no _dynamic allocation_ makes sense [10:27:21] <Dark_Shikari> no _malloc_ does not [10:27:21] <B4gder> we have no malloc at all [10:27:28] <Dark_Shikari> B4gder: sure you do [10:27:29] <B4gder> we have fixed buffers [10:27:32] <Dark_Shikari> you have things that are effectively malloc [10:27:40] <Dark_Shikari> a fixed buffer is a kernel malloc on load [10:27:52] <B4gder> not quite [10:28:00] <mru> Dark_Shikari: that assumes you *have* a kernel [10:28:08] <Dark_Shikari> mru: rockbox runs on ipods, not 8-bit microcontrollers [10:28:26] * mru is working on a project with ffmpeg on a tiny rtos [10:28:31] <Dark_Shikari> Yeah, but this isn't that =p [10:28:44] <mru> there is malloc though... [10:28:55] <mru> or enough of one at least [10:29:06] <av500> you can always fake a malloc from a small fixed heap... [10:29:13] <B4gder> exactly [10:29:14] <Dark_Shikari> again [10:29:15] <mru> av500: that's not fake [10:29:18] <av500> tear down the heap after your tear down the codec [10:29:21] <Dark_Shikari> there are two things meant by malloc [10:29:23] <Dark_Shikari> "dynamic allocation [10:29:26] <Dark_Shikari> and "allocation" [10:29:31] <Dark_Shikari> banning dynamic allocation is fine [10:29:38] <Dark_Shikari> banning allocation just means the coder will find another way to do it [10:29:43] <mru> on blackfin I use a dedicated chunk of ram for ffmpeg heap [10:29:45] <Dark_Shikari> which will be a malloc disguised under a different name [10:30:01] <Dark_Shikari> and NO decoder in ffmpeg should use dynamic allocation [10:30:03] <mru> and another chunk for bss [10:30:05] <Dark_Shikari> without very good reason [10:30:05] <B4gder> Dark_Shikari: I said no malloc, I didn't say no allocation [10:30:05] <av500> B4gder: but your codecs dont all use the "fake" approach, right? [10:30:13] <Dark_Shikari> B4gder: malloc is allocation [10:30:15] <B4gder> most of them don't [10:30:17] <Dark_Shikari> other forms of allocation are disguised mallocs [10:30:24] <B4gder> Dark_Shikari: ? [10:30:30] <Dark_Shikari> alloca increases stack size [10:30:30] <B4gder> read my words again [10:30:34] <Dark_Shikari> increasing stack size results in a kernel malloc [10:30:37] <B4gder> we have allocation, not malloc [10:30:42] <mru> Dark_Shikari: not necessarily [10:30:46] <Dark_Shikari> All allocations are mallocs somewhere [10:30:51] <Dark_Shikari> mru: yes obviously if the stack is already large enough, etc [10:30:51] <KotH> Dark_Shikari: "no malloc" == no heap [10:30:59] <Dark_Shikari> KotH: there's always a heap [10:31:02] <B4gder> no allocations do not imply malloc [10:31:04] <KotH> Dark_Shikari: nope [10:31:04] <Dark_Shikari> it just might not be _your_ heap. [10:31:13] <mru> Dark_Shikari: and you can easily forbid growing the stack [10:31:22] <Dark_Shikari> mru: but you still declare a static stack size [10:31:26] <Dark_Shikari> and that static stack size is a malloc [10:31:29] <KotH> Dark_Shikari: in embedded apps you avoid heaving a heap because of its properties to fail allocation [10:31:29] <Dark_Shikari> it's just in kernelspace. [10:31:34] <mru> Dark_Shikari: not always [10:31:38] <Dark_Shikari> KotH: again, you're entirely missing the point [10:31:41] <Dark_Shikari> static allocation cannot fail [10:31:42] <KotH> Dark_Shikari: could be [10:31:43] <mru> it can be a static link-time allocation [10:31:46] <Dark_Shikari> even if you're using malloc [10:31:55] <KotH> Dark_Shikari: yes [10:32:02] <Dark_Shikari> link-time allocation is done in the kernel. [10:32:04] <Dark_Shikari> ... via malloc [10:32:06] <mru> no [10:32:09] <mru> it's done by the linker [10:32:12] <mru> static linker [10:32:17] <B4gder> exactly [10:32:27] <Dark_Shikari> mru: but it still has to allocate something somewhere [10:32:28] <Dark_Shikari> it's not magic [10:32:31] <mru> output is a flat image you can dump wherever you like [10:32:42] <Dark_Shikari> mru: and the image has to be allocated [10:32:50] <KotH> Dark_Shikari: have you ever worked with deep embedded apps ? ie apps that do run on bare metal, no OS, no kernel, no helper libs? [10:32:57] <mru> in embedded systems its commonplace to statically link *everything* into a single image [10:33:01] <mru> OS and all [10:33:11] <Dark_Shikari> KotH: but we're not on such an app. [10:33:16] <mru> we can be [10:33:17] <Dark_Shikari> the ipod is not a "deep embedded" system [10:33:21] <B4gder> it is [10:33:23] <KotH> Dark_Shikari: er.. rockbox is such an app [10:33:34] <Dark_Shikari> KotH: er, no... [10:33:40] <Dark_Shikari> I'm pretty sure rockbox doesn't run on 8-bit microcontrollers [10:33:42] <Dark_Shikari> with no ram [10:33:50] <mru> no, but it runs on 32-bit micros [10:33:52] <av500> Dark_Shikari: it runs on 32bit micros with no ram [10:33:55] <KotH> Dark_Shikari: you dont need an 8 bit uC to do such stuff [10:33:57] <Dark_Shikari> the ipod has ram [10:34:05] <av500> it runs on 2MB, no os [10:34:05] <mru> nothing runs w/o ram [10:34:14] <Dark_Shikari> the ipod runs without an OS? [10:34:16] <pross-au> nothing runs without tape [10:34:17] <Dark_Shikari> then how can it run apps? [10:34:23] <mru> Dark_Shikari: old ipod [10:34:23] <Dark_Shikari> magic pixie dust? [10:34:26] <av500> Dark_Shikari: it is not an ipod app [10:34:27] <Dark_Shikari> Ah, old ipod [10:34:28] <KotH> Dark_Shikari: at the company i work for, we only write such apps... on arm7 and cortex-m3 uC [10:34:30] <Dark_Shikari> av500: I know [10:34:31] <mru> not the touch [10:34:48] <Dark_Shikari> also, really, 2MB? I recall hearing that the ipod software was >1mloc [10:34:59] <av500> Dark_Shikari: rb runs on jb6000 with 2mb [10:35:03] <mru> Dark_Shikari: which ipod? [10:35:07] <Dark_Shikari> mru: true, don't know about that. [10:35:14] <Dark_Shikari> av500: well 2mb should be enough for anyone. [10:35:16] <mru> the original ipod was tiny [10:35:32] <Dark_Shikari> and really, all you have to do is as follows: [10:35:43] <Dark_Shikari> 1) Ensure the audio decoder has static allocation only (i.e. mallocs all at start, predictable) [10:35:46] <av500> Dark_Shikari: well, the 2mb are only there for buffering, the original design had 256k :) [10:35:50] <Dark_Shikari> 2) Calculate how much it will need. [10:35:54] <B4gder> Dark_Shikari: I think you're missing the point [10:36:00] <Dark_Shikari> 3) Make a wrapper function that overrides malloc and runs off a static heap [10:36:06] <Dark_Shikari> 4) Bam, done, now you don't have to rewrite ffmpeg [10:36:14] <B4gder> and that attitude is not helping [10:36:16] <mru> replacing malloc in ffmpeg is trivial btw [10:36:19] <Dark_Shikari> mru: exactly [10:36:26] <Dark_Shikari> my point being you should never have to modify decoder code to do that [10:36:27] <mru> configure --malloc-prefix=foo [10:36:36] <Dark_Shikari> all you have to do is calculate how much space you need [10:36:37] <av500> mru: or at link time [10:36:38] <Dark_Shikari> override malloc [10:36:54] <Dark_Shikari> obviously the decoders have to be well-behaved, but that's a separate issue [10:36:54] <B4gder> if this is gonna work, you need to realize that we're willing to cooperate, not simpyl doings things the way you think is the best [10:37:02] <Dark_Shikari> B4gder: I'm making a suggestion [10:37:12] <B4gder> yes, but you're not listening [10:37:16] <Dark_Shikari> no, you're not listening [10:37:21] <B4gder> I do [10:37:23] <Dark_Shikari> I'm telling you in 3 lines of code or so, you can eliminate all the mallocs [10:37:26] <Dark_Shikari> and get your static heap [10:37:29] <Dark_Shikari> without modifying ffmpeg [10:37:32] <B4gder> hahaha [10:37:38] <B4gder> ok, forget I tried [10:37:40] <Dark_Shikari> As long as the decoder is well-behaved. [10:37:58] <mru> some people just don't want to talk [10:38:02] <Dark_Shikari> pretty much. [10:38:16] <Dark_Shikari> seriously, come into a channel and tell the project how they should run things [10:38:20] <Dark_Shikari> how they should write their code [10:38:28] <mru> that's not quite what he was doing [10:38:41] <mru> he was saying they have to modify our code to be able to use it [10:38:46] <mru> and didn't give good reasons for it [10:39:22] <Dark_Shikari> sounds like a lot of projects that use ffmpeg [10:39:24] <Dark_Shikari> for that matter, a lot of distros [10:40:14] <Honoome> distros get to it mostly from the projects [10:40:44] <Honoome> when we have need to have a specific FFmpeg revision, say, trunk rather than 0.5 branch, is often because some other project only works with that, e.g. x264, to call up one :P [10:41:47] <pross-au> its far easier to fork stuff then to cooperate [10:41:52] <pross-au> that's why it happens [10:41:54] <merbzt> yes :/ [10:44:37] <mru> pross-au: easier short-term [10:44:42] <mru> long-term it's pure pain [10:44:54] * mru used work in a fork shop [10:45:16] <pross-au> rockbox is hardly short-term [10:46:22] <mru> hi Zagor [10:46:32] <Zagor> hi [10:48:56] <KotH> Zagor: Zagor as the comic Zagor? [10:49:57] <Zagor> heh, no. Zagor as the randomly invented name sometime in the mid-80s. [10:51:57] <KotH> then you might want to read the comic once, as it predates you :) [10:52:25] <Zagor> yeah, I know about it [10:52:54] <Zagor> I didn't for the first 15 years of using the nick, though :) [10:53:49] <merbzt> we sort of scared away your brother a few minutes ago [10:54:09] <mru> he'll be back [10:54:17] <merbzt> :) [10:54:26] <Dark_Shikari> he will. I've been chatting to him via pm. [10:55:09] <mru> did you explain that you're a bull-headed, arrogant bastard, and there's nothing to be done about that? ;-) [10:55:10] <Zagor> yeah, I sort of wanted to listen to the discussion [10:55:37] <Dark_Shikari> mru: lol [10:55:52] <Dark_Shikari> we talked and we went over various things e.g. what ffmpeg needs from rockbox for this [10:55:54] <merbzt> mru talking to himself again :) [10:56:03] <Dark_Shikari> here's a paste of one bit [10:56:04] <Dark_Shikari> 18:48 <Dark_Shikari> I would start by putting together: [10:56:04] <Dark_Shikari> 18:49 <Dark_Shikari> 1) a set of rockbox patches (i.e. what rockbox changes) [10:56:08] <Dark_Shikari> 18:49 <Dark_Shikari> 2) a set of things that would be necessary for rockbox to use libavcodec directly instead of slashing out codecs [10:56:11] <Dark_Shikari> 18:49 <Dark_Shikari> for example, "disabling codecs needs to work better" would [10:56:15] <Dark_Shikari> 18:50 <Dark_Shikari> 3) a set of needs that rockbox has, i.e. things it would like ffmpeg devs to keep in mind when writing new audio decoders [10:56:18] <Dark_Shikari> 18:50 <Dark_Shikari> 4) a set of specific things that it would like changed (can probably be included as a summary of 1) ) with regard to any existing decoders that it makes significant use of. [10:56:22] <Dark_Shikari> 18:51 <Dark_Shikari> the eventual goal should be to make ffmpeg Do What You Need without changes. [10:56:47] <merbzt> ffmpeg needs fixed point execution paths [10:56:52] <kshishkov> or add a bit of glue to FFmpeg to replace RockBox completely :P [10:57:27] <Zagor> kshishkov: haha, good luck with that [10:57:49] <kshishkov> fair enough, MPlayer goes first [10:57:52] <Dark_Shikari> lol [10:58:45] <Zagor> Dark_Shikari: 2) will likely never happen. we run each codec separately in order to optimize them as much as we can [10:59:05] <Zagor> for example sram usage is a major issue [10:59:17] <mru> codecs in ffmpeg *are* separate [10:59:24] <mru> they just share some common code [10:59:46] <Zagor> ok, then what does "slashing out codecs" mean? [11:00:05] <mru> what rockbox is doing ;-) [11:00:32] <mru> picking out just the files needed by a specific codec and patching it up to build [11:00:56] <av500> Zagor: hi [11:01:13] <Dark_Shikari> Zagor: we want to optimize them as much as we can too [11:01:14] <Zagor> av500: hi [11:01:17] <av500> KotH: and I thought I am the only other person that read Zagor comics... [11:02:33] * kshishkov wonders what happened to make so many RockBox devs come here [11:03:30] <av500> kshishkov: friendly chatter [11:04:02] <Compn> someone must have offered them some beer at fosdem? :P [11:04:15] <twnqx> lol [11:04:22] <kshishkov> av500: still a bit suspicious [11:05:33] <KotH> av500: in late 70s, early 80s, they were quite famous in .tr... and that's the way i got my hands on them [11:05:46] <av500> KotH: they were too in .yu :) [11:05:51] <Dark_Shikari> beer? more like whiskey, they must be on some serious alcohol to consider dropping by here ;) [11:05:52] <mt> kshishkov: I've been around for months, I just don't talk that much. :) [11:05:55] * Dark_Shikari runs [11:06:05] <Zagor> I feel a bit like I'm restarting the discussion from scratch here, which was not my intention. [11:06:15] <KotH> Dark_Shikari: you are aware that optimizing for low ram footprint can mean to make a codec less cpu efficient? [11:06:21] <Honoome> Dark_Shikari: you lost on lu_zero bringing Troll Beer :P [11:06:27] <kshishkov> mt: yes, I know [11:06:30] <Dark_Shikari> KotH: you can do both. [11:06:43] <Dark_Shikari> we have CONFIG_SMALL [11:06:44] <KotH> Dark_Shikari: but not always [11:06:46] <Dark_Shikari> why not CONFIG_LESS_RAM? [11:06:51] <KotH> ah.. ok [11:06:54] <KotH> that'd be a good idea [11:06:56] <Dark_Shikari> :) [11:07:01] <kshishkov> KotH: golden rule of computing - you can lose in memory or speed (or both) [11:07:13] <KotH> kshishkov: lol [11:07:17] <Dark_Shikari> also, I doubt most decoders use that much ram [11:07:20] <Dark_Shikari> I mean, it's audio, it's easy [11:07:27] <Dark_Shikari> does rockbox do video at all btw? [11:07:32] <Dark_Shikari> if not, they have it easy ;) [11:07:32] <Honoome> kshishkov: the “or both” refers to theora I guess? :D [11:07:46] <Zagor> Dark_Shikari: some, but not in the same codec structure [11:07:55] <Zagor> we have an mpeg player plugin [11:07:55] <KotH> Dark_Shikari: "that much" depends highly on your enviroment [11:08:00] * kshishkov fears ot tell Honoome there are reference decoders in existence [11:08:01] * Dark_Shikari looked at rockbox for his crappy $30 player but it didn't really support it properly, it required reinstalling original firmware to use USB [11:08:09] <KotH> Dark_Shikari: something that uses 1k of mem in one of our apps here, is _A_DAMN_LOT_ [11:08:19] <Dark_Shikari> KotH: yeah, but music players generally have more than 1k. [11:08:30] <KotH> Dark_Shikari: how much do you think? [11:08:36] <Honoome> kshishkov: oh shush I'm just taking a cheap shot at xiph as usual ^^;; yes I'm definitely ranty about them since I had to deal with libtheora/libvorbis in Gentoo and with FLAC format on xine [11:08:39] * twnqx recently saw a mp3 player software for the commodore c64 [11:08:41] <KotH> Dark_Shikari: the one i have has a coupl of 10k of ram [11:08:46] <Dark_Shikari> KotH: 32K to 2MB I would guess [11:08:48] <Dark_Shikari> is the distribution [11:09:16] <Dark_Shikari> at 32K I'd start getting worried though, ffmpeg is not exactly efficient at code size [11:09:24] <Dark_Shikari> data would be the least of my concerns [11:09:26] <kshishkov> Honoome: personally I just know that Theora exists but I've not touched it for yeats [11:09:29] <kshishkov> *years [11:09:54] <Honoome> lucky you… libtheora used to have this nice feature that the stuff they released actually _missed some source files_ … [11:09:56] <Dark_Shikari> (do such devices have separate EEPROM for data or similar?) [11:09:58] <Zagor> theora is another codec ripe for code sharing... [11:10:15] <Dark_Shikari> well, ffmpeg's theora decoder is getting completely overhauled anyways [11:10:20] <Dark_Shikari> because xiph being better than ffmpeg at anything is a bit embarassing [11:10:28] <KotH> Dark_Shikari: definitly less then 1MB [11:10:35] <KotH> Dark_Shikari: though, i cannot find the numbers anymore [11:10:36] <Honoome> so for instance you disabled MMX support, or built on 64-bit, and you would have an unbuildable libtheora :P [11:10:56] <KotH> Dark_Shikari: and the smallest mp3 players work on 8kB ram [11:11:17] <Zagor> KotH: but they don't decode in the cpu then [11:11:18] <Dark_Shikari> 8kb is probably not even enough to hold the framebuffer on mine... [11:11:28] <Dark_Shikari> and you can't get much smaller than a $30 4GB player [11:11:29] <KotH> Zagor: that i dont know [11:11:34] <Zagor> I do :-) [11:11:44] <kshishkov> Dark_Shikari: what a wonderful opportunity to optimize x264 for MP3 players ;) [11:11:49] <Dark_Shikari> kshishkov: lol [11:11:54] <Dark_Shikari> you can encode one frame per day [11:12:05] <av500> depends on the frame size [11:12:21] <av500> tamagotchi live streaming... [11:12:29] <KotH> lol [11:12:33] <KotH> do tamagochis still exist? [11:12:37] <av500> yes, new ones [11:12:38] <KotH> havent seen one in ... decades [11:12:45] <KotH> o_0 [11:12:49] <KotH> they still build them? [11:12:58] <av500> http://www.engadget.com/2010/02/15/tamagotchi-renamed-tamatown-tama-go-no-c… [11:13:01] <kshishkov> you'd be ashamed to be seen with one anyway [11:13:01] <Honoome> they are laid, not produced [11:17:02] <KotH> o_0 [11:17:09] <KotH> av500: holy... egg... [11:17:20] <KotH> kshishkov: well, target market is .jp anyways [11:17:45] <KotH> kshishkov: and giving that japanese people carry their cell phone on a strap aroudn their neck... [11:17:45] <Dark_Shikari> which is a "special" market [11:17:58] <KotH> s/special/totally insane/ [11:18:00] <KotH> ^^' [11:18:42] <kshishkov> s/insane/culturally different/ [11:18:55] <kshishkov> it's insane _here_ [11:19:08] <KotH> it's a different form of insanity [11:19:11] <KotH> believe me [11:19:14] <KotH> i've lived there [11:19:18] <KotH> i've seen it [11:19:21] <KotH> i've survived it [11:19:46] <Dark_Shikari> go to akihibara every day for one week. [11:20:22] <mru> Dark_Shikari: have you been there? [11:20:42] <Dark_Shikari> no, but I've heard scary stories from people who have. [11:21:01] <Dark_Shikari> and when I go to japan, I will go there, so I can tell scary stories to everyone else too. [11:21:06] * mru has been there [11:21:11] <Dark_Shikari> And so I can fill my backpack with doujins. [11:21:13] <Dark_Shikari> but that's secondary [11:21:29] <mru> it's not nearly as scary as the stories make it out to be [11:21:36] <Dark_Shikari> well it is a bit more toned down lately [11:21:38] <mru> but telling stories is more fun [11:21:45] <Dark_Shikari> they kicked a lot of the prostitution off the street [11:21:56] <Dark_Shikari> and now instead we have a "rent a girlfriend" service [11:28:28] <twnqx> mru: it is scary! just watch durarara!! [11:29:34] <mru> as I said, I've been there, wasn't scary at all [11:30:06] <kshishkov> welcome here! [11:31:42] <Dark_Shikari> mru: http://www.engadget.com/2010/02/15/st-ericssons-u8500-brings-dual-core-1-2g… [11:35:29] <av500> the Ghz race on the phones will be much more fun than on the desktop :) [11:36:03] <Dark_Shikari> And people wonder why I decided to make ARM a priority for x264... =p [11:36:24] <Dark_Shikari> now we just need a good compiler [11:36:38] <twnqx> nah, a 3ghz octocore arm [11:37:08] <av500> Dark_Shikari: well, all these beasts coming out these days have stuff like 1080p enc/dec in HW.... [11:37:36] <Dark_Shikari> usually not encode [11:37:43] <Dark_Shikari> and usually not a very good or flexible encoder [11:37:45] <av500> encode is coming too [11:38:16] <Dark_Shikari> and plus, TI wants to work with us [11:38:17] <Dark_Shikari> so... [11:40:48] <mru> the coming TI video hw is quite programmable [11:42:14] <Dark_Shikari> still doesn't have a sad16x16 instruction ;) [11:42:36] <Dark_Shikari> sad16x16 result, src, srcstride, ref, refstride [11:42:43] <Dark_Shikari> 5 argument instructions, easy enough [11:43:19] <mru> Dark_Shikari: what makes you say it doesn't? [11:43:43] <Dark_Shikari> last I recall it was still all async units [11:43:53] <mru> so? [11:44:06] <Dark_Shikari> async units can't be called synchronously by CPU instructions [11:44:13] <mru> so? [11:44:19] <Dark_Shikari> that means there's no sad16x16 instruction [11:44:31] <mru> the accelerator can have such an instruction [11:45:45] <Dark_Shikari> it's asynch, it doesn't have latency of just a couple clocks [11:45:51] <Dark_Shikari> thus it's not going to be useful to call for a single SAD [11:47:37] <mru> that's not you it's supposed to be used [11:47:51] <mru> and you don't know the latency [11:47:59] <Dark_Shikari> asynch units aren't going to have single-digit-clock latencies [11:48:19] <mru> you're thinking about it in the wrong way [11:48:33] <Dark_Shikari> it's useless to simply say "here are 10,000 SADs that I need done" [11:48:40] <Dark_Shikari> you need complex logic behind those SADs [11:48:45] <mru> the async unit is programmable [11:48:53] <Dark_Shikari> then how is it any different from a CPU? [11:48:58] <mru> you code your ME algorithm on it [11:49:17] <mru> the main code running on the arm then fires off a command like "find the best MV for this block" [11:49:31] <mru> that will of course have considerable latency [11:49:39] <Dark_Shikari> order of magnitude? [11:49:45] <Dark_Shikari> 100 clocks? 1000? 10000? [11:49:48] <Dark_Shikari> 100,000? [11:49:59] <mru> depends on the algorithm [11:50:01] <mru> obviously [11:50:28] <Dark_Shikari> er [11:50:32] <Dark_Shikari> I mean the latency to the unit [11:50:47] <mru> sending a command should take a few cycles [11:50:53] <Dark_Shikari> just a few cycles? that's it? [11:50:55] <Dark_Shikari> and the results? [11:51:01] <mru> it's a memory write [11:51:05] <Dark_Shikari> so basically if it's only a few cycles [11:51:05] <mru> or looks like one [11:51:10] <Dark_Shikari> then what I do is like this: [11:51:16] <Dark_Shikari> 1) send ME search commands [11:51:20] <Dark_Shikari> 2) do intra search, etc on main CPU [11:51:26] <Dark_Shikari> 3) spinlock to wait until 1) completes [11:51:30] <Dark_Shikari> 4) mode decision based on results [11:52:18] <Dark_Shikari> that would fit the x264 model very well [11:52:21] <mru> "it is capable of executing a reasonable algorithm within 900 cycles per macroblock" [11:52:23] <Dark_Shikari> it would avoid having to split the encoding completely [11:52:25] <Dark_Shikari> ..... Wow [11:52:35] <Dark_Shikari> 900 cycles per MB as in throughput or latency? [11:52:44] <Dark_Shikari> and are those CPU clocks, or asynch unit clocks? [11:53:25] <Dark_Shikari> basically I'm wondering if that means "if we run 1000 MBs through, it takes 900,000 clocks" [11:53:25] <mru> accelerator clocks of course [11:53:38] <Dark_Shikari> or "if we run 1 MB through, it'll take 900 clocks" [11:53:42] <Dark_Shikari> and what does the accelerator run at? [11:53:44] <Dark_Shikari> 50mhz? 500mhz? [11:54:10] <mru> 500 is probably not far off [11:54:21] <Dark_Shikari> so that means this actually fits the x264 model [11:54:26] <Dark_Shikari> now harass them to get me some hardware and a toolkit [11:54:30] <Dark_Shikari> I want to write code for this thing =p [11:55:45] <mru> oh, and there's a special accelerator for intra pred [11:57:14] <Dark_Shikari> what exactly does it do? [11:57:25] <Dark_Shikari> I mean, it can do "intra pred", but one intra pred takes like 5-20 cycles [11:57:38] <Dark_Shikari> so that doesn't make sense to put on an accelerator except for decoding (with the whole chaining idea) [11:59:11] <mru> many of these units have their own arm core [11:59:59] <Dark_Shikari> why not just multithread the encoder then? [12:00:03] <Dark_Shikari> and abuse the arm cores? [12:00:14] <mru> they are arm9 or m3 [12:00:18] <mru> no fancy stuff [12:05:47] <Dark_Shikari> anyways, we need to get their help and get x264 optimized on an OMAP [12:13:37] <mru> and the netra [12:13:53] <Dark_Shikari> netra? [12:14:08] <mru> successor to davinci [12:14:24] <mru> triple video accels [12:15:33] <mru> 1GHz A8 and C674x dsp too [12:17:01] <mru> http://wiki.neurostechnology.com/index.php/OSD3.0 [12:19:26] <mru> omap4 is dual-A9, single video accel, dsp [12:28:49] <KotH> Dark_Shikari: toned down is an understatement. most of the maid cafes are gone [12:29:08] <Dark_Shikari> :/ [12:29:09] <KotH> Dark_Shikari: other than that.. you dont stumble on the really weird stuff unless you look for it... [12:29:12] <Dark_Shikari> that's what made it good [12:29:21] <Dark_Shikari> now it's just a really big shop for touhou doujins [12:29:47] <KotH> i liked it better before the maid cafes came [12:30:25] <merbzt> mru: is this you ? http://www.flickr.com/photos/koenkooi/2692388640/ [12:30:41] <mru> damn, you found me [12:31:20] * kshishkov has the most unrecgnozable photo of Måns [12:31:44] <KotH> kshishkov: show us [12:32:27] <kshishkov> let me find it [12:32:46] <Dark_Shikari> mru: obnoxious cdecl question [12:32:50] <Dark_Shikari> I have [12:32:52] <Dark_Shikari> const int16_t (*l1mv0)[2] = (const int16_t (*)[2]) &h->fref1[0]->mv[0][ h->mb.i_b4_xy ]; const int16_t (*l1mv1)[2] = (const int16_t (*)[2]) &h->fref1[0]->mv[1][ h->mb.i_b4_xy ]; [12:32:58] <mru> omg [12:33:02] <Dark_Shikari> I want to be able to address these as l1mv[0] and l1mv[1] [12:33:05] <Dark_Shikari> instead of l1mv0 and l1mv1 [12:33:11] <Dark_Shikari> how the hell would I declare that? [12:33:22] <thresh> how the hell do you read that [12:33:27] <Dark_Shikari> thresh: you start by adding the missing line break [12:33:42] <thresh> i'm actually lost after the third space [12:33:46] <Dark_Shikari> lol [12:33:50] <thresh> okay, fifth [12:33:54] <Dark_Shikari> it's a pointer to a const int16_t mv[2] [12:35:12] <mru> Dark_Shikari: try const int16_t (*l1mv[2])[2] = { (const int16_t (*)[2]) &h->fref1[0]->mv[0][h->mb.i_b4_xy], (const int16_t (*)[2]) &h->fref1[0]->mv[1][h->mb.i_b4_xy] }; [12:35:30] <mru> those casts look scary though [12:35:42] <Dark_Shikari> impressive. [12:35:43] <kshishkov> KotH: http://shishkov.homeunix.net/mans.jpg [12:35:44] <Dark_Shikari> Yeah [12:35:51] <Dark_Shikari> thanks [12:35:58] <Dark_Shikari> yeah, that's a seriously obnoxious set of declarations [12:35:59] <mru> kshishkov: lol [12:36:03] <Dark_Shikari> I mean seriously, that's like 3 dereferences each [12:36:25] <Dark_Shikari> well, it compiled [12:36:35] <kshishkov> mru: I can guarantee it's you - April 7th, KTH [12:36:40] <mru> take that, java [12:36:51] <mru> kshishkov: I recognise the place very well [12:37:09] <mru> and I own a coat that colour [12:40:32] <Dark_Shikari> well, I just shrunk a loop by about a factor of 2 with that [12:40:45] <mru> nice [12:40:56] <Dark_Shikari> I'm being inspired by michael's optimizations [12:41:00] <Dark_Shikari> to go back and optimize those annoying parts of x264 [12:41:17] <kshishkov> to make them incomprehensible? [12:41:23] <Dark_Shikari> lol [12:41:38] <Dark_Shikari> I love some of michael's mini-opts [12:41:45] <Dark_Shikari> like the whole "if the mv is 0, you can skip half of spatial direct" [12:41:50] <Dark_Shikari> which triggers shockingly often [12:42:18] <kshishkov> yeah, the hard part is to predict what happens often [12:46:59] <twnqx> ain't that profilers are for? [12:47:06] <twnqx> +what [12:47:57] <kshishkov> they are of little help in that case [12:48:19] <kshishkov> since they usually work on whole functions, not conditions [12:48:22] <twnqx> so you'd have to implement performance counters for yourself to do statistics? [12:48:39] <twnqx> mh [12:48:40] <Dark_Shikari> printf [12:48:42] <Dark_Shikari> not hard., [12:48:47] <twnqx> no, just annoying [12:48:57] <Dark_Shikari> not really [12:49:16] <mru> some cpus have sw counters [12:49:28] <mru> write to a register to trigger an event [12:49:40] <mru> probably not useful here though [12:51:21] <Dark_Shikari> on a vaguely related note, I have a class this semester on OSs [12:51:36] <Dark_Shikari> fun stuff, like writing kernel-level synch primitives [12:51:42] <Dark_Shikari> semaphores, mutexes, cvs [12:51:51] <Dark_Shikari> pretty easy though :/ [12:52:02] <Dark_Shikari> especially if you're allowed to be lazy and just turn off interrupts during the synch code [12:52:30] <mru> what kernel are you using? [12:52:31] * twnqx orders the second core to write to the memory location [12:52:38] <Dark_Shikari> mru: OS/161, simulated MIPS kernel [12:52:43] <mru> sim, bah [12:52:47] <Dark_Shikari> designed for a system that only exists in simulation [12:52:52] <Dark_Shikari> with a bus that's never been implemented in hardware [12:52:56] <kshishkov> pure fiction then [12:52:59] <mru> typical academia [12:53:01] <Dark_Shikari> though it's actually arch-generic [12:53:11] <Dark_Shikari> the arch-specific parts are obviously for the sim [12:53:17] <Dark_Shikari> but it would not be hard to port [12:53:21] <mru> we actually got to play with real hardware in uni [12:53:23] <Dark_Shikari> it's chosen because it's _incredibly_ small [12:53:29] <av500> Dark_Shikari: will you port x264 to it? [12:53:30] <Dark_Shikari> we do too, but that's not what this class is for [12:53:33] * twnqx remembers his simulated assembler classes [12:53:40] <Dark_Shikari> 1) it's an entire OS in ~17kloc [12:53:44] <mru> better to use something real like ucos or atomthreads imo [12:53:46] <Dark_Shikari> 2) It has almost nothing--and we have to fix that [12:53:54] <kshishkov> we had to write CPU emulator and assembler for one of our projects [12:53:57] <Dark_Shikari> scheduler, synch primitives, execve, etc [12:53:58] <twnqx> optimizing data structures to the point where one of the authors of the simulator didn't understand why the code worked :P [12:54:09] <Dark_Shikari> mru: is it an OS in 17kloc? ;) [12:54:19] <mru> less [12:54:24] <Dark_Shikari> o.0 [12:54:29] <mru> ucos is tiny [12:54:35] <mru> a few k lines [12:54:44] <Dark_Shikari> an OS smaller than h264.c [12:55:07] <Dark_Shikari> btw, it was chosen because we can more easily focus on writing the code instead of debugging shit when we can trivially attach gdb to a simulator [12:55:21] <Dark_Shikari> and while debugging a real chip is nice and fun... it's also aggravating [12:55:22] <Dark_Shikari> and painful [12:56:02] <twnqx> help me debug my FPGA [12:56:11] <twnqx> i think i need a JTAG reding software [12:57:56] <mru> a good jtag debugger is much easier to use than gdb on a sim [12:58:02] <mru> gdb is pain [12:58:30] <Dark_Shikari> dunno, it's not too bad [12:58:39] <Dark_Shikari> it works pretty well [13:01:58] <mru> maybe you've never used a good jtag debugger [13:02:36] <Dark_Shikari> hmm. is there any less shitty way to structure code like this? [13:02:37] <Dark_Shikari> http://pastebin.com/m1dca8a98 [13:02:56] <Dark_Shikari> if(A) {do X} else {do Y} if(B) {do X} else {do Y} if(!A && !B) {do Z} [13:03:15] <Dark_Shikari> if/else is sometimes a bit limiting of a paradigm [13:06:05] <Kovensky> on that case, you could split Z and put on the else cases of A and B [13:06:09] <Kovensky> in* [13:07:06] <Kovensky> hmm, nvm [13:07:09] <janneg> no, that would do Z two times for !B && !B [13:07:19] <Kovensky> I said split [13:07:38] <Dark_Shikari> oh, and I don't want to increase code size [13:07:40] <Dark_Shikari> so no duplicating shit [13:07:43] <Kovensky> but it would also do a part of Z if !A && B or A && !B [13:08:03] <kshishkov> loop is most obvious [13:08:06] <Kovensky> http://pastebin.com/m1be43e60 <-- this is what I had in mind, but it changes the logic [13:08:14] <Dark_Shikari> won't work [13:08:19] <Dark_Shikari> the spec says what it say [13:08:36] <janneg> it could be just moved as if (!A) do Z; to else of the if (B) [13:08:40] * av500 proposes a goto, hides [13:09:04] <Dark_Shikari> how about http://pastebin.com/m3ffc6ba7 [13:09:42] <av500> wouldnt nm insist you replace that all with "? :" stuff? [13:09:46] <kshishkov> it should work [13:09:48] <KotH> kshishkov: rotfl [13:10:06] <Kovensky> http://pastebin.com/m14727281 [13:10:09] <Dark_Shikari> also, notably the "else" branches are rare [13:10:15] <Dark_Shikari> and to take _both_ the elses is about 1% of the time [13:10:27] <Dark_Shikari> which is why Kovensky's solution is bad [13:10:27] <twnqx> tmp = 0; if (a) tmp|=1; if (b) tmp|=2; switch(tmp) {case....} [13:10:28] <twnqx> :P [13:10:50] <Dark_Shikari> so I guess hiding it inside a branch nobody cares about works [13:11:03] * Kovensky fails [13:11:10] * Dark_Shikari should have said that first [13:11:33] <Kovensky> <@Dark_Shikari> and to take _both_ the elses is about 1% of the time <-- shouldn't the if be the exceptions, and else the rule? [13:11:36] <Dark_Shikari> oh wow. I'm a phenomenal idiot. there is a loop right above that, which I can merge all this code with [13:11:42] <Kovensky> at least I remember reading something to that effect [13:11:53] <Dark_Shikari> Kovensky: oh, good question. mru, doesn't gcc have fuckwitted rules for this? [13:11:54] <twnqx> tmp = (a?1:0) | (b?2:0); switch (tmp) { case ...} [13:12:18] <mru> rules for what? [13:12:33] * twnqx does too much verilog, which allows to evaluate multiple variables in one case statement quite neatly [13:12:42] <Dark_Shikari> mru: which side of the if it inlines [13:12:53] <mru> I've seen gcc do all kinds of things [13:12:54] <janneg> twnqx: tmp = (!!a<<) | (!!b); [13:13:10] <janneg> twnqx: tmp = (!!a<<1) | (!!b); [13:13:27] <av500> switch((!!a<<1) | (!!b)){... [13:13:33] <twnqx> janneg: tmp = (!a<<1) | (!b); and invert the meanings [13:13:35] <Dark_Shikari> die die die die die [13:13:48] <Kovensky> DIE THE DEATH [13:13:48] <Kovensky> etc [13:14:23] <Dark_Shikari> great equalizer, etc, etc [13:17:58] <Dark_Shikari> 21:16 < ksf> "It takes about ten gigabytes or so of disk space to check out and build the source tree." [13:18:01] <Dark_Shikari> 21:17 < benmachine> which source tree is this [13:18:04] <Dark_Shikari> 21:17 < Dark_Shikari> homo sapiens? [13:18:11] <Dark_Shikari> (apparently, chromium) [13:18:51] * Kovensky wonders how dreadfully big would mozilla-central be if it used git [13:19:50] * KotH remembers that m14 or m15 filled his 1.5G scratch partition when compiling [13:19:58] <Honoome> Dark_Shikari: chromium-os? [13:20:11] <Honoome> because not sure about the check-out, but the build for chromium sure does not arrive to 10GBs… [13:20:20] <Dark_Shikari> dunno [13:20:27] <Dark_Shikari> just copying random stuff from another channel [13:20:37] <Honoome> [which would sound bloody strange, because OpenOffice just takes about 8GB or so to build…] [13:20:52] <Dark_Shikari> 8gb to build [13:20:52] <Dark_Shikari> lol [13:20:58] <Dark_Shikari> for a fucking text editor [13:21:05] <Dark_Shikari> (ok, so I'm trolling with that) [13:21:19] <Honoome> Dark_Shikari: for a fucking text editor with a chart software that is unable to understand dates… [13:21:23] <Dark_Shikari> lol [13:21:27] <Honoome> and that has feature regressions against Microsoft Chart for DOS! [13:21:29] <bilboed-pi> the actuall OOo isn't that big, it's just that they ship a truckload of their own copies of dependencies [13:21:31] <Dark_Shikari> for a fucking chart software that can't handle more than 2^16 rows [13:21:52] <kshishkov> Honoome: IIRC, MS Office itself had feature regressions against Write for Windows [13:22:19] <Honoome> for a drawing application that exports spellchecker underlines when exporting images, and for which the fix is targeted for 3.3 milestone… [13:22:19] <kshishkov> bilboed-pi: they copied that from Mozilla [13:22:38] <kshishkov> WYSIWYG [13:23:23] <elenril> lol [13:23:35] <Honoome> kshishkov: really, what good is a spreadsheet/charting application that doesn't understand that by-date graphs can't have the same distance between feb 2-feb 3 and feb 3-feb 10? [13:23:44] <elenril> text editor << ooo can do that? [13:24:58] <Dark_Shikari> elenril: no syntax highlighting though [13:24:59] <Dark_Shikari> kinda sucks [13:25:02] <kshishkov> elenril: even Emacs can do that [13:25:13] <Honoome> fwiw gnuplot is cryptic, but now that I've been given the scripts to do the generation, it takes magnitudes of memory and time less to use that =_= [13:25:17] <Kovensky> lolemacs [13:25:20] <kshishkov> Honoome: well, I don't like charting [13:25:25] <Kovensky> I know one emacs shortcut \o/ [13:25:38] <kshishkov> Honoome: but it's drawing sucks too [13:25:41] <mru> Kovensky: which one? [13:25:45] <kshishkov> vi? [13:25:47] <Kovensky> C-x C-c [13:25:55] <mru> come try it on my emace ;-) [13:25:57] <mru> emacs [13:25:59] <Dark_Shikari> eight megabytes and constantly swapping [13:26:06] <Kovensky> cheater :> [13:26:14] <mru> emacs makes any computer slow [13:26:21] <Honoome> kshishkov: the only thing that it does *better* than inkscape is flowcharts [13:26:32] * mru likes xfig [13:26:34] <kshishkov> Dark_Shikari: not funny anymore. Unless your OS still swaps it with 2GB RAM free [13:26:43] * mru doesn't have swap [13:26:58] <kshishkov> Honoome: yes, and I'd say it's better to enhance Inkscape [13:27:08] <Dark_Shikari> eventually munches all computer storage [13:27:14] <Kovensky> IIRC windows doesn't allow you to completely remove swap [13:27:14] <mru> inkscape is a pile of stink too [13:27:25] * mru doesn't run windows [13:27:27] <kshishkov> mru: xfig was fine unless you tried Cyrillic captions [13:27:31] <Honoome> kshishkov: probably… but I tried talking with inkscape upstream and almost had a rude answer to them ;_; [13:27:38] <Kovensky> some guy solved the problem by putting the swap on a ramdisk [13:27:38] <Kovensky> lol [13:27:39] <Dark_Shikari> emacs makefiles annihilate C shells [13:27:56] <Honoome> [emacs for the win, by the way :P] [13:27:56] <KotH> Honoome: if you think that gnuplot is cryptic, you have never used ploticus :) [13:28:09] <Honoome> KotH: not even heard of that before ;) [13:28:11] <elenril> Dark_Shikari: what editor do you use btw? [13:28:17] <mru> gnuplot is nice too [13:28:18] * Kovensky didn't like emacs too much [13:28:21] <Dark_Shikari> emacs macht alle computer sheisse [13:28:26] <Dark_Shikari> elenril: notepad++ [13:28:29] <KotH> Honoome: it's the tool, when gnuplot is just not flexible enough anymore :) [13:28:30] <kshishkov> good German [13:28:35] <mru> emacs is useless out of the box [13:28:38] <Kovensky> "emacs eats all your computer's cheese" [13:28:39] <mru> you need to customise it [13:29:05] <kshishkov> elentril: the only way to make Dark_Shikari use something different is to convince Touhou author to release all games for Linux only [13:29:09] <mru> escape meta alt control shift [13:29:09] <Honoome> KotH: I don't think the problem with gnuplot is lack of flexibility in my case… it's more a matter of having no idea where the heck to find the documentation [13:29:15] <Kovensky> <@mru> emacs is useless out of the box <-- I could tell that far [13:29:20] <Honoome> mru: have you tried emacs 23 yet? [13:29:23] <mru> no [13:29:40] <Dark_Shikari> I prefer vim 1972 [13:29:47] <Honoome> KotH: at the end, to do a stacked area chart the solution I've been given is to chart the first line normally, and the second as the sum of the first and second :P [13:29:48] <Dark_Shikari> but that's beaten by ed 93876492 [13:30:04] <kshishkov> cat +infinity [13:30:22] <kshishkov> or quantum butterfly [13:31:39] <KotH> Honoome: there is a ps file that is the documentation [13:31:49] <KotH> Honoome: you have to read all of it to find the one command you need [13:32:14] <Honoome> KotH: I even read gnuplot in action, but half of tha stuff assumes you completed your statistics course at university [13:32:14] <KotH> Honoome: after having it read a couple of dozen times, you'll know in which section the thing you are looking for could proably be [13:32:28] <KotH> of course [13:32:34] <Honoome> given I almost failed statistics in high school and I didn't proceed to university, that's a bit too far out for me :P [13:32:39] <KotH> none said that gnuplot doesnt assume prior knowledge [13:33:00] <KotH> uh.. then you're lost but for the most simple graphs [13:33:19] <KotH> beside: not going to uni might not be the worst idea [13:33:45] <Honoome> KotH: I started working right after high school, didn't care about italian university… would have been different had it been german or british [13:33:50] <KotH> i was quite good in statistics in highschool... i couldnt even figure out what the prof was talking about at the uni ^^' [13:34:04] <mru> most of what I learned in uni, I wasn't taught [13:34:06] <KotH> Honoome: oh.. italian... [13:34:16] <KotH> Honoome: well.. i dont blame you then :) [13:34:58] <Honoome> heh :) -- but yeah gnuplot I don't really want to learn extensively ;) just is nice to produce the graphs for benchmarks and similar stuff… an image makes it much more clear to the users what you're talking about [13:35:24] <Honoome> luckily for now I found someone who gave me the two scripts that produces the graphs I need to show the Ruby packaging in Gentoo :D [13:35:31] <mru> ascii-art ftw [13:36:58] <KotH> Honoome: ppt? ;-> [13:37:23] <Honoome> KotH: that's something I have to consider for the next FOSDEM or something like that :P [13:37:55] <KotH> Honoome: make a video and play it on a video wall... much more impressive [13:37:58] <KotH> :) [13:39:12] <mru> we need to think of some new features for the wall [13:43:00] <KotH> dont play a single video, but orchestrate the different displays to a show [13:46:48] <kshishkov> done by mru already [13:47:34] <KotH> nope [14:08:21] <av500> KotH: video mirror: each BB encodes one 6th with a webcam, they pass it to the "other side", decode there and display [14:08:22] <janneg> re-render BBB in 3840x2.048 [14:08:31] <av500> janneg: I looked into that [14:08:42] <av500> BBB took like 50000h on a sun cloud [14:08:48] <av500> for 1080 [14:10:22] <janneg> 50k h real time? [14:10:47] <kshishkov> of course not [14:11:10] <kshishkov> that's >5 years after all [14:16:04] <av500> http://www.bigbuckbunny.org/index.php/our-renderfarm-and-how-it-works/ [14:16:31] <av500> ...Luckily they were generous and gave us 50′000 hours, allowing an optimistic 4-5hrs per frame. .... [14:16:50] <kshishkov> they were in parallel [14:16:52] <janneg> reading that already. looks like the final rendering was just 1-2 hours [14:17:25] <janneg> per frame [14:19:56] <av500> for 1080 [14:20:25] <janneg> does the rendering scales linearly with the number of pixels? [14:20:30] <av500> kshishkov: yes, in parallel :) have your gdium join the renderfarm? [14:20:43] <av500> janneg: no idea [14:21:28] <kshishkov> av500: no, but I sometimes use my 1GHz ARM (NEONless) to transcode from 1280x760 H.264 to something better playable [14:22:06] <mru> sheeva? [14:22:23] <kshishkov> yes [14:23:02] <kshishkov> too lazy to use BeagleBoard for that [14:23:38] <av500> mru: BB rendercluster? how many will TI give us :) [14:23:58] <av500> they sold 10k so far, we need them all [14:24:06] <twnqx> lol [14:24:15] <janneg> I fear they would be ram and limited [14:24:21] <janneg> -and [14:24:32] <av500> for 1 frame? [14:24:33] <kshishkov> 640k is enough [14:25:09] <av500> ok, we render in libaa [14:25:16] <av500> and we make a vt100 wall [14:27:45] <kshishkov> yes, someone should lend some power to that Kiwi guy to finish asciiart version of star wars [14:28:18] <janneg> argh, blender uses scons [14:30:33] <av500> scones? [14:30:43] <mru> with jam [14:31:07] <av500> clotted cream ftw [14:31:24] <janneg> no, autohell replacement [14:31:41] <mru> yeah, replaced with a hotter hell [14:32:05] <kshishkov> mozilla/oo.o-style [14:34:06] <CIA-34> ffmpeg: rbultje * r21848 /trunk/libavcodec/Makefile: [14:34:06] <CIA-34> ffmpeg: Add missing dependency. Patch by James Darnley <$firstname dot $lastname at [14:34:06] <CIA-34> ffmpeg: gmail dot com>. [14:35:08] <Kovensky> lolautohell [14:35:21] <kshishkov> autocrap too [14:36:02] * Kovensky maintains an autohell build system ._. [14:36:09] <kshishkov> and you always need the latest version to build it [14:37:09] <Honoome> janneg: there's a cmake-based buildsystem available as user patch as well [14:37:15] <Honoome> [still better than the crap that is called scons :P] [14:39:15] <lu_zero> well [14:39:24] <lu_zero> scons in blender works well enough [14:39:27] <lu_zero> and no [14:39:48] <lu_zero> I'm not so sure the cmake stuff in blender is anyway superior than the scons one [14:39:49] <kshishkov> "good enough is an enemy of good" [14:40:22] <lu_zero> kshishkov: the main problem with blender is that has a code layout a bit annoying [14:41:41] * kshishkov used Blender twice - once on PocketPC [14:44:49] <DonDiego> BBB: i hereby grant you the useless commit message award [14:45:01] <DonDiego> "Add missing dependency." [14:45:20] <DonDiego> for the makefile that's about as useful as "bug fix" is for a C file [14:45:43] <mru> it's worse even [14:45:50] <mru> you can't add something that's missing [14:46:10] * lu_zero will put "add missing dependency on a C commit and a bug fix on a makefile commit [14:46:12] * kshishkov runs svn commit -m "change characters in some file(s)" [14:46:25] <mru> I've seen worse [14:46:29] <mru> I've seen "..." [14:46:30] <lu_zero> kshishkov: s/change/switch/ [14:46:37] <merbzt> bring out the champagne !! \o/ [14:47:07] <kshishkov> mru: some people use single space for commit message [14:47:08] <lu_zero> the worst would be feeding the diff to svn message [14:47:18] <DonDiego> in that case it would be better [14:47:27] <DonDiego> because it would at least explain *something* [14:47:28] <lu_zero> DonDiego: the wrong diff [14:47:29] <kshishkov> merbzt: nothing stronger than Pommac for you :P [14:47:46] <merbzt> I want trocadero [14:47:58] * kshishkov sighs [14:47:59] <mru> I worked at a place where policy was that after a commit, the developer had to _manually_ send an email to a list [14:48:15] <mru> and the email was to contain the cruft cvs ci prints to the console [14:48:17] <merbzt> :) [14:48:19] <lu_zero> mru: you got 1commit per day? [14:48:53] <DonDiego> BBB: *please* don't treat commit messages as just a bump on the road [14:48:55] <CIA-34> ffmpeg: thilo.borgmann * r21849 /trunk/libavcodec/alsdec.c: Limit the Rice parameter used for progressive decoding in ALS. [14:48:56] <mru> then you had to do the same commit again in a different repo using a different, even worse, vcs [14:49:10] <DonDiego> BBB: you should be communicating with *us* in them [14:49:15] <Kovensky> worse than cvs? wtf [14:49:24] <mru> oh, there are plenty [14:49:25] <lu_zero> Kovensky: there are plenty [14:49:30] <DonDiego> and with your future self that forgot what you did in mid-february 2010 [14:49:44] <kshishkov> Kovensky: ever heard of Microsfot Source Safe? [14:49:57] <Kovensky> yes, never dealt with it though [14:50:07] <lu_zero> like monotone... [14:50:15] <av500> clearcase [14:50:21] <lu_zero> monotone is orrible [14:50:31] <lu_zero> I'm not sure clearcase is that bad [14:50:35] <mru> I am [14:50:45] <lu_zero> as bad as monotone? [14:50:45] <av500> I am [14:50:47] <mru> clearcase is cvs with lots of brick walls added [14:50:53] <lu_zero> uh [14:50:56] <lu_zero> wonderful [14:51:08] <lu_zero> and there is somebody paying to use it [14:51:08] <av500> I know people that work with clearcase and they go to a clearcase admin to have a file/folder created.... [14:51:15] <Kovensky> <@mru> clearcase is cvs with lots of brick walls added <-- nice, they even give the place you should bang your head against [14:52:01] <kshishkov> SourceSafe has an additional point of being able to crash DB and losing _all_ your data [14:52:16] <av500> kshishkov: that is a M$ core feature [14:52:31] <mru> clearcase is built around a db made by a company that's gone bankrupt _twice_ [14:52:38] <mru> and they print that in the manual [14:52:53] <kshishkov> av500: yes, they made it with Jet engine used for other data loss product like Access [14:52:55] <KotH> what db? [14:53:00] <mru> don't remember [14:53:11] <av500> stillalivedb [14:53:11] <lu_zero> sigh... [14:53:32] <Kovensky> kshishkov: loljet [14:53:33] <av500> it must be a good db to survive 2 bankruptcies [14:53:36] * kshishkov looks at wikipedia [14:53:40] <mru> clearcase _requires_ a full-time _team_ to look after it [14:53:42] <Kovensky> kshishkov: microsoft itself said they won't port jet to 64bit [14:53:47] <kshishkov> what? IBM product? bleh [14:53:49] <thresh> clearcase awwwwwwwwwwww [14:54:12] <kshishkov> developed by Rational Software? that's even sickier! [14:54:50] <KotH> mru: taht's strategy [14:54:55] <mru> anyway, what's that magic git command to take two branches and interleave the histories? [14:54:57] <KotH> mru: selling a product wont give you any profit [14:55:05] <KotH> mru: selling an SLA will give you lots of profit [14:55:41] <elenril> a seven letter acronym? [14:56:13] <Kovensky> mru: git merge? [14:56:17] <mru> no [14:56:22] <mru> git merge creates a merge commit [14:57:04] <Honoome> mru: interleave? hm I did something before but it was a real mess… rebase is not enough? [14:57:20] <mru> no [14:57:26] * thresh got interleaving history in ffmpeg+swscale git repo [14:57:30] <KotH> elenril: service level agreement [14:57:34] <mru> I want two histories interleaved in the order they happened [14:57:34] <elenril> what's so wrong with a merge commit [14:57:36] <KotH> elenril: aka, a support contract [14:57:36] <thresh> though those arent 'branches' really, just a subtries [14:57:43] <thresh> subtree [14:58:11] <mru> thresh: how'd you do it? [14:59:15] <thresh> nothing magical. http://www.kernel.org/pub/software/scm/git-core/docs/howto/using-merge-subt… [14:59:51] <thresh> hmm wait [15:00:43] <thresh> i do have merge commits. [15:01:04] <thresh> sorry, my brain melts in the end of a workday [15:04:00] <janneg> mru: the general history rewriting command is git filter-branch. I don't think it will trivially interleave brnaches in commit order but it should be possible [15:04:14] <mru> I know of filter-branch [15:04:27] <mru> but I can't seem to figure out a way to make it do what I want [15:05:42] <janneg> I think you have to script around it [15:06:28] <janneg> well, cherry pick is probably enough [15:06:47] <mru> I don't want to cherry-pick thousands of commits [15:09:22] <mru> surely someone has done this before... [15:09:41] <lu_zero> mru bilboed-pi did something iirc [15:10:09] * bilboed-pi reads backlog [15:10:38] <janneg> ask in #git. I don't see a solution not acting on single commits [15:10:53] <bilboed-pi> oh, merging ffmpeg and swscale git commits together ? [15:11:03] <mru> same kind of thing [15:11:09] <bilboed-pi> tricky [15:11:12] <BBB> oops [15:11:17] <BBB> DonDiego: will fix [15:11:18] <BBB> sorry [15:11:22] <mru> that's what I keep telling people [15:11:26] <mru> that it's tricky [15:11:31] <mattg> mru: just wondering if you managed to reproduce the green issue i was having on ARM with that file i sent over the other day? [15:11:54] <mru> mattg: I tried decoding it on arm/linux and had no problems [15:12:05] <mru> apart from some error messages you said you always got [15:12:22] <mru> there's an alignment problem somewhere but I can't find it [15:13:24] <mattg> ok, thanks for your help. i'm still getting the green unfortunately - i've turned on the various error_recognition and error_concealment flags so not sure why libavcodec is still throwing out such strange frames. [15:13:40] <mattg> any advice on where i should look? [15:13:57] <mru> my guess is it's the error concealment that has the misalignment [15:14:06] <mru> try turning it off entirely [15:14:14] <snatches> who might I speak with regarding the development to support alpha channel in the H264 codec for Flash? [15:14:24] <mattg> will try that mru - thanks [15:14:30] <mru> h264 doesn't support alpha [15:15:01] <av500> snatches: alpha? [15:15:09] <BBB> av500: transparency [15:15:20] <janneg> mru: http://dustin.github.com/2008/12/31/archaeology.html [15:15:26] <av500> BBB: I know what that is :) [15:15:32] <BBB> well you asked :) [15:15:39] <snatches> yes. I'm working on a green screen project and trying to include ffmpeg [15:15:48] <BBB> a friend of mine did something cool to enable a z-channel (3d) in a mpeg1/2 stream [15:16:04] <av500> snatches: ok, and? [15:16:45] <snatches> The issue now is file size. Our current method gives us a great video, but file size is much larger than when I use ffmpeg. [15:16:58] <snatches> here's the example: http://hamhock.wildentity.com/green_test_jason.html [15:17:25] <janneg> mru: not pretty but at least the script for reordering the commit is already written [15:18:01] <av500> snatches: so, replace the green by background, no? [15:18:11] <snatches> exactly [15:18:27] <av500> so why do you need alpha? [15:19:08] <snatches> because the background is all in flash. This keeps video size down. [15:19:21] <av500> yes [15:19:38] <av500> encode front + green in h264, decode h264, replace green by background [15:20:06] <av500> h264 does not have an alpha channel, so you need to add one post decode [15:21:27] <mru> janneg: I think I forgot to mention I want to preserve tags... [15:22:19] <snatches> unless I'm not understanding you, I don't want to put my background into the video. i want to leave it in flash. the only way to isolate the subject of my video and include it in flash is if I can eliminate the green background of the src video. [15:22:36] <mru> which you can't [15:22:37] <av500> snatches: yes [15:22:47] <av500> [16:19] <av500> encode front + green in h264, decode h264, replace green by background [15:23:24] <av500> if flash does not let you convert green to transparent you have a problem [15:23:59] <snatches> then i think that I have a problem :) [15:24:10] <av500> :) [15:24:16] <av500> you can keep it :) [15:24:35] <snatches> what? you don't want my problems? I give them away free of charge :) [15:24:51] <janneg> mru: I think you would have to retag. but unless there are very important reason to do it I would just say it's tricky and might mangle history without anyone noticing [15:24:57] <av500> unless you pay money to get rid of them. I dont want them [15:25:21] <snatches> well, that segues into the next question. [15:25:23] <av500> snatches: u sure flash has no "mask" feature or so? [15:27:00] <snatches> it does, but in order to truly immerse a live actor into a 3D office environment, it just seems that this green screen/alpha channel method is the way to go. We have it working, i'm just trying to optimize it now with ffmpeg [15:27:22] <av500> how do you use ffmpeg from flahs? [15:28:59] <snatches> Currently, we are using Final Cut Pro to key out all of the green behind our actor. FCP exports to an flv using the On2 VP6 codec, which is what you see in that example [15:29:49] <av500> ok [15:29:51] * Kovensky wonders why did movie production go for green color key instead of pink color key like game programmers [15:30:04] <av500> Kovensky: think porn [15:30:08] <av500> too much pink [15:30:15] <snatches> this works great, but this project must be viewed over the web, so we are trying everything we can to reduce the file size of these videos. ffmpeg has proven to be a huge asset to us in reducing file sizes of videos in other projects. [15:30:16] <Kovensky> =p [15:30:41] <av500> snatches: you dont make sense, sorry [15:30:48] <av500> is this a video or a swf file? [15:31:03] <av500> if its a video, yes you can use ffmpeg to compress it, actor and office included [15:31:05] <snatches> you are referring to the link I sent you? [15:31:30] <av500> if you want actor + green and static office, you need e.g. flash - if flash supports that [15:31:36] <snatches> The office backgound is a swf. The swf then pulls in an flv video file [15:31:55] <av500> well, then find out if in flahs you can replace green with alpha.... [15:31:59] <av500> it is a FLAHS issue [15:32:10] <snatches> flv video is strictly the actor isolated [15:32:31] <snatches> Flash can't do it, it must be down in video production [15:32:32] <av500> and what is around the actor? [15:32:35] <merbzt> only VP6A supports the needed alpha channel [15:32:49] <av500> snatches: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [15:32:59] <av500> I knew flash has some alpha stuff [15:33:19] <merbzt> only on2 supports it [15:33:20] <snatches> merbzt, yes I read that, but that codec doesn't seem to be included in my version of ffmpeg [15:33:32] <snatches> yes, and that's what were using currently http://hamhock.wildentity.com/green_test_jason.html [15:33:46] <merbzt> there is on vp6 encoder in FFmpeg [15:34:03] <av500> snatches: so what is the problem? [15:34:43] <snatches> I guess the problem now is how to use the vp6 codec in my version of ffmpeg. [15:34:57] <snatches> if I can use that, I can convert my videos without a problem [15:35:06] <av500> snatches: but why not use the vp6 codec from e.g. adobe? [15:35:11] <merbzt> there is no vp6 encoder :) [15:35:31] <merbzt> only on2 or adobe [15:36:24] <snatches> if we have to use adobe, we will. I'm just trying to see if ffmpeg can offer me a smaller file size for these videos. This content will be going out to many different companies, with various connection speeds. gotta get it as small as possible [15:36:56] <snatches> mebzt, there is only a decoder, right? [15:37:19] <av500> snatches: even great ffmpeg will not reduce vp6 size by 10x.... [15:38:05] <snatches> I believe you av500, but I'm a firm believer in seeing it for myself :) [15:38:34] <av500> well, lacking a vp6 encoder, the comparison is easy... [15:38:39] <av500> what bitrate do you get? [15:42:15] <snatches> trying to figure that out [15:47:24] <merbzt> snatches: the only option is to use h264, but then I'm not sure it would be possible to use alpha channels [15:47:45] <Kovensky> there's no alpha in h.264 [15:48:59] <snatches> Kovensky, that's what I keep hearing. Does that mean that it is physically impossible to do alpha channel in h.264, or is it just that there isn't an encoder available that does it? [15:49:19] <Kovensky> IIRC it's not in the specs [15:50:14] <Kovensky> IIRC it only uses planar 4:2:0 YUV, with some profiles supporting 4:2:2 and 4:4:4 [15:51:18] <snatches> this is getting to the edge of my abilities. Kovensky, does either 4:2:2 or 4:4:4 support alpha channel, or is that un-related? [15:54:09] <kierank> there's some alpha blending support iirc but nobody supports it [15:54:21] <av500> snatches: it is not supported [15:54:58] <snatches> kierank: which codec supports alpha blending? [15:55:07] <av500> VP6A, the one you are using [15:55:34] <kierank> h.264 as well in one of the newer spec revisions [15:55:51] <snatches> av500: to answer your earlier question about my current bitrate, the video was exported at 700 [15:57:22] <DonDiego> BBB: please, if you write a one-line commit message that includes the patch sender credits, that should be a red flag [15:57:56] <kshishkov> red flags with hammer and sickle or red flag with stars? [15:58:00] <DonDiego> BBB: take a moment to think about your message, then make it explicit and concise.. [15:58:59] <DonDiego> but not generic please [15:59:26] <Honoome> kshishkov: rotfl :) [15:59:52] <av500> "this is my commit, there are many like it but this one is mine...." [16:00:22] <KotH> lol [16:00:29] <KotH> boys, you're nuts! [16:00:30] <lu_zero> brrr... [16:01:04] <Honoome> lu_zero: still snow-ing? :P [16:01:19] <lu_zero> Honoome: I'm taking a break from the pony [16:01:29] <lu_zero> your branch passes the feng-destroyer test [16:01:31] <kshishkov> Honoome: maybe it's h264-ing instead [16:01:32] <Honoome> sigh, I'm still fighting with EC2 [16:01:54] <kierank> what's the problem Honoome [16:01:54] <DonDiego> BBB: if your commit message could be used to describe many of the changes to a particular file, then it's pointless [16:01:58] <Honoome> lu_zero: did you have any doubt? [16:01:59] <lu_zero> kshishkov: I have h264.c and h264_loopfilter.c open in fact [16:02:05] <lu_zero> Honoome: obviously. [16:02:09] <Honoome> … [16:02:13] <Honoome> thanks… [16:03:28] <Honoome> kierank: with EC2? the fact I feel it's a bad hack :| [16:03:35] <lu_zero> (I'm trying to figure out that leak so I was hoping that would trigger it...) [16:05:25] <kierank> Honoome, ec2's great [16:05:31] <kierank> for some things [16:06:33] <mru> like wasting time [16:09:06] <Honoome> definitely for wasting time [16:09:30] <kierank> well theres nowhere else that will let you just fire up 1000 servers to do your bidding [16:09:49] <Honoome> kierank: sure, if you're enough with a stock server [16:09:57] <Honoome> when you're setting up something custom's a mess [16:10:10] <kierank> the image upload thing is a bit awkward [16:10:13] <Honoome> the eu zone errors out more often than not [16:10:29] <Honoome> the only modern linux distro supported seems to be ubuntu [16:10:41] <Honoome> but the doc does not correspond then because ubuntu (obviously) have no root [16:11:36] <Honoome> you cannot start up s system with a device pre-connected… [16:11:41] * elenril looks around for volunteers to apply his patch [16:12:13] <kshishkov> elenril: try BBB, he has to perfrect his commit messages anyway [16:15:23] <snatches> everyone, thank you for at least helping me tackle my alpha channel requests. It would seem that VP6A is my only hope at the moment [16:16:03] <snatches> There is no VP6A encoder, is that correct? only a decoder? [16:16:22] <kshishkov> there is but not in FFmpeg [16:16:29] <_av500_> or obi wan [16:16:46] <merbzt> :) [16:17:06] <snatches> kshishkov: is it a matter of funding a developer to create an encoder? [16:17:31] <Honoome> kierank: and the support software is even better! I'm trying to use rudy that does most of the work I'm needing… the problem being “private key file not found” … point it to the right file “key already exists” [16:17:33] <kshishkov> no [16:17:48] * KotH wonders why anyone would want to use an encoder for a format that has been proved to be worse than other available formats that are already available for free [16:18:21] <twnqx> beacuse... no alpha channel in h264? :P [16:18:30] * kshishkov forgets about his MSVideo1 encoder again [16:18:45] <merbzt> snatches: buying flix would be cheaper [16:18:48] <lu_zero> twnqx: and? [16:19:18] <twnqx> if someone now really wants an alpha channel in his video he has to resort to some otherwise inferior codec [16:20:20] <snatches> twnqx: that is exactly my situation. I don't want to go with vp6a, but to use ffmpeg that seems to be what I have to do [16:20:50] <lu_zero> flash does support alpha just on vp6 anyway... [16:21:31] <twnqx> uhhh i broke my ffmpeg :X [16:21:49] <twnqx> uh. and more. [16:21:52] <BBB> DonDiego, I fixed it, didn't I? [16:22:07] <BBB> elenril, which patch? [16:22:14] * BBB seriously needs to start using git [16:22:19] <KotH> BBB: btw: did you get your website for ffmtech? [16:22:36] <BBB> KotH, I'm waiting for you to give me login credentials [16:22:41] <KotH> ARGH [16:22:43] <KotH> damn... [16:22:45] <KotH> sorrry! [16:22:47] <KotH> ^^' [16:22:59] * KotH blames root for being lazy [16:23:00] <BBB> that's ok :) [16:23:03] <Honoome> lu_zero: feel like playing with genshi? :P [16:23:15] <KotH> BBB: i'll try to have a look at it this evening [16:23:19] <DonDiego> BBB: git does not write commit messages for you [16:23:49] <merbzt> DonDiego: but it does, at least my version of git [16:23:54] <merbzt> or I as drunk [16:23:58] <merbzt> *was [16:24:04] <snatches> this is one of the more entertaining channels I've been on. I may have to grab some popcorn and just watch [16:24:14] <DonDiego> haha [16:24:15] <twnqx> >_> [16:24:56] <_av500_> qoutes... [16:25:01] <merbzt> snatches: we are not only just crazy, we are brilliantly crazy [16:26:01] <BBB> dondiego: git allows me to have multiple changesets in a tree [16:26:21] <BBB> dondiego: believe me, I have lots of random crap in my tree and I can't commit small changes for other people just like that :( [16:26:26] <BBB> painful [16:26:31] <elenril> BBB: thread set lavf ident string globally [16:26:33] <snatches> well, I'm hoping the brilliance, no matter how crazy, rubs off on me a little. my business seems to be going more and more towards streaming video and I need to get all the info I can to make sure I can service my clients [16:26:43] <Kovensky> git gui is p. useful to select chunks to commit [16:26:53] <Kovensky> there's also git format-patch :3 [16:26:55] <BBB> elenril, need topic title [16:27:21] * siretart notices that mobile internet in train isn't exactly reliable… [16:27:23] <elenril> BBB: that's it [16:27:28] <BBB> oh [16:27:30] <BBB> let me see [16:27:33] <BBB> was it approved? [16:27:35] <Honoome> siretart: still better than in planes ;) [16:27:37] <elenril> yes [16:27:46] <mru> and spaceships [16:28:04] <BBB> elenril, was the asf patch applied? [16:28:06] <kshishkov> good trains have own Internet though. Like X2 or X40 [16:28:09] <DonDiego> BBB: how does that prevent you from writing useless commit messages? [16:28:22] <DonDiego> IOW, how is this related to what i said in any way? [16:28:29] * elenril thought git creates commit messages too [16:28:41] <elenril> by the power of its awesomeness [16:28:45] <BBB> dondiego: it wasn't related, that's what I meant to say [16:28:49] <siretart> Honoome: oh, my last experience with an delta domestic flight wasn't bad at all. at least they had a pretty reliable dns service :-) [16:28:52] <BBB> dondiego: but I fixed the commit msg already :) [16:29:02] <BBB> elenril: ok, hold on then [16:29:15] * elenril holds on [16:29:19] * Kovensky wonders if being unable to edit commit messages is a blocker in git's adoption [16:29:20] <DonDiego> yes, but i hadn't seen the change yet [16:29:31] <DonDiego> Kovensky: for me, it definitely is [16:29:43] <BBB> DonDiego, is the new one ok? [16:29:54] <DonDiego> yes [16:29:55] <Kovensky> DonDiego: well, you CAN edit commit messages [16:30:01] <DonDiego> Kovensky: nope [16:30:04] <Kovensky> it will just break everyone else's history if you push [16:30:15] <DonDiego> exactly --> useless [16:30:39] <DonDiego> BBB: please train yourself on not writing pointless commit messages in the first place [16:30:46] <BBB> dondiego: ok [16:30:47] <elenril> you can do it like kernel people [16:30:58] <Kovensky> the kernel way is the Right Way [16:31:06] <merbzt> DonDiego: everyone know you shouldn't mess with the history [16:31:13] <DonDiego> yes [16:31:22] <kshishkov> Kovensky: we don't have spare Linus [16:31:23] <BBB> elenril, any suggested commit msg? [16:31:27] <KotH> merbzt: history is written by the winners [16:31:28] <merbzt> you will disrupt the space time continuum [16:31:30] <elenril> BBB: it's in the patch [16:31:33] <BBB> oh I see [16:31:44] * BBB tries to compile [16:31:50] <kshishkov> merbzt: guess what's called a country with constantly changing past? [16:32:02] <Honoome> Italy? [16:32:03] <merbzt> kshishkov: Ukraine ? [16:32:06] * elenril <3 git-format-patch [16:32:09] <kshishkov> Soviet Union [16:32:16] <Kovensky> elenril: s/-// [16:32:25] <Kovensky> elenril: git-commands have been removed since 1.6 :P [16:32:31] <kshishkov> Honoome: from what I know you have not got a country till 1871 or so [16:32:34] <KotH> Kovensky: INGSOC! [16:32:45] <Kovensky> BofH: what [16:32:49] <elenril> Kovensky: http://tvtropes.org/pmwiki/pmwiki.php/Main/EntirelyMissingThePoint [16:33:05] <Kovensky> elenril: http://tvtropes.org/pmwiki/pmwiki.php/Main/SpellMyNameWithAnS [16:33:15] <elenril> err [16:33:15] <Honoome> kshishkov: which is exactly why they keep on saying that our history is Roman/Celtic/Barbaric/WhateverSuitsThemThisTime [16:33:16] <CIA-34> ffmpeg: rbultje * r21850 /trunk/libavformat/ (avi.c mp3.c metadata.c utils.c avienc.c metadata.h): [16:33:16] <CIA-34> ffmpeg: Set lavf identification string globally in av_write_header(), rather [16:33:16] <CIA-34> ffmpeg: than inside the muxers. Remove special handling of "encoder" tags from [16:33:16] <CIA-34> ffmpeg: AVI and MP3 muxers. [16:33:16] <CIA-34> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [16:33:26] <KotH> er.. Kovensky, kshishkov: please change your nicks in a way that the first letters are different... thanks [16:33:35] <kshishkov> Honoome: Etruskian :P [16:33:42] <elenril> BBB: thanks [16:33:44] <BBB> anything else I can help with? [16:33:47] <kshishkov> KotH: begin with yourself [16:33:55] <Kovensky> KotH: or just type two letters before hitting tab? :P [16:34:07] <KotH> kshishkov: nah.. i hardly ever type my own nick, so no problem there :) [16:34:17] <elenril> no, that's all for now [16:34:21] <KotH> Kovensky: that's *effort* [16:35:57] <mru> /rename KotH BofH [16:36:03] <kshishkov> KotH: just don't answer one of us. That's less effort for everyone [16:36:07] <elenril> KotH: and you're calling _me_ lazy [16:36:16] <elenril> mru++ [16:36:35] <mru> hey, it worked [16:36:38] <BofH> bah! [16:36:43] <BofH> this nick is already taken! [16:36:51] <elenril> :/ [16:36:53] * KotH blames mru [16:37:01] * mru blames BofH [16:37:02] <KotH> elenril: ofc.. you are lazy [16:37:46] <elenril> that's politically incorrect [16:37:59] * elenril is motivation impaired [16:38:14] <KotH> ADHD? [16:38:27] <KotH> or just ADD? [16:38:37] <mru> MUL [16:38:59] <mru> SDHC [16:39:19] <KotH> waht was it? IAIAO? [16:39:22] <elenril> http://en.wikipedia.org/wiki/Secure_Digital#SDHC ? [16:39:22] <kshishkov> RLWINM [16:41:01] <mru> EIEIO? [16:41:23] <kshishkov> what's that? [16:41:34] <mru> a ppc instruction [16:41:47] <mru> http://en.wikipedia.org/wiki/EIEIO [16:43:11] <kshishkov> hmm [17:26:09] <BBB> libavcodec/x86/dsputil_mmx.c:726: error: can't find a register in class ?GENERAL_REGS? while reloading ?asm? [17:26:20] <BBB> who added that function (transpose4x4)? [17:26:21] <kshishkov> well done, GCC! [17:26:35] <kshishkov> it should be very old [17:26:42] <kshishkov> svn/git blame is your friend [17:27:24] <BBB> I can't compile it anymore :( [17:28:14] * kshishkov thanks himself for using PowerPC [17:31:21] <mru> we should move the code to yasm [17:31:32] <kshishkov> good gsoc task? [17:32:11] <Dark_Shikari> Yes [17:32:13] <Dark_Shikari> absolutely absolutely yes [17:32:16] <Dark_Shikari> holy shit yes [17:32:18] <Dark_Shikari> do it [17:32:22] <Dark_Shikari> fund it [17:32:23] <Dark_Shikari> etc [17:32:58] <kshishkov> next thing - make yasm part of FFmpeg to prevent external dependency ;) [17:33:34] <mru> ffasm [17:34:32] <kshishkov> good thing too [17:34:53] <J_Darnley> Then what? ffcc? [17:35:08] <kshishkov> excellent idea! [17:35:14] <mru> then ffcpu [17:35:33] <elenril> ffkernel? [17:35:41] <mru> no, that's ffos [17:36:53] <kshishkov> we need other ffutils for ffos [17:37:09] <kshishkov> running on FFcpu [17:38:26] <Dark_Shikari> ffcpu for cpu detection? =p [17:39:42] <BBB> I'll buy beer for whoever fixes these issues forever and ever after [17:39:56] <BBB> I keep having GENERAL_REGS compilation errors whenever someone touches the mmx files [17:40:27] <Dark_Shikari> make it a soc project [17:41:11] <Compn> heh [17:41:28] <elenril> wouldn't that be a gcc soc project? [17:41:48] <Compn> for all the amount of complaining about gcc... one could hack up tcc enough to just compile ffmpeg, then include it internally, make gcc compile tcc and tcc compile ffmpeg ;) [17:42:28] <Kovensky> <+elenril> wouldn't that be a gcc soc project? <-- no [17:42:29] <Compn> i mean, whats one more wheel? [17:42:33] * elenril heard clang/llvm is NotBad [17:42:33] <Kovensky> porting all the asm to yasm would fix that problem [17:42:36] <Kovensky> no gcc, no problem [17:42:57] <Kovensky> * elenril heard clang/llvm is NotBad <-- so did I, but atm it miscompiles ffmpeg [17:43:06] * Kovensky is actually building a new clang right now [17:43:21] <elenril> yeah, because it doesn't support asm or something [17:46:07] <Andrius> when talking about clang, it's not "it doesn't support", it's "it doesn't support yet" [17:46:25] <Andrius> unless you're talking about some horrible gcc extention [17:46:34] <mru> and with gcc it's "it no longer supports" [17:57:13] <astrange> transpose4x4 failure is because it doesn't add -mdynamic-no-pic [17:57:56] <astrange> i meant to reply to that thread again. though in practice it'd probably end up with commiting the fix and then finding out if openbsd broke later [17:58:03] <astrange> (was it openbsd? i can't remember the problem anymore) [17:58:58] <kshishkov> and you'll still have broken Apple compiler I think [18:00:04] * kshishkov wants x86* buried [18:00:42] <astrange> apple gcc 4.0 is broken but not 4.2 [18:01:13] <peloverde> apple gas is still broken [18:02:32] <BBB> kshishkov, you sound like one of those people that thinks maemo or moblin is going to b the next iphone killer :-p [18:02:59] <kshishkov> BBB: no, I'm firm believer in people stupidity [18:03:32] <Dark_Shikari> unsigned comparisons are amazing. I just cut a loop's size by half by abusing unsigned casts [18:04:04] <Kovensky> BBB: maemo merged with moblin IIRC [18:04:14] <Kovensky> or it was some other random merge but one of those two were involved [18:04:19] <BBB> Kovensky, that's why I mention it :-p [18:04:33] <Dark_Shikari> if( x < 0 || (y >= 0 && y < x ) x = y; ---> if( (unsigned)y < (unsigned)x ) x = y; [18:04:36] <Dark_Shikari> magic [18:04:59] <kshishkov> employed in lavc for, say, bounds detection [18:05:04] <Dark_Shikari> yup [18:09:04] <Compn> Dark_Shikari : yeah, but until you optimize by half a cpu cycle .... [18:09:35] <peloverde> Is there any chance of GCC's uninitialized warnings ever being not retarded? [18:09:43] <mru> no [18:10:26] <Dark_Shikari> no [18:10:26] <astrange> there seems to have been a failed soc project about that [18:10:29] <astrange> http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [18:10:36] <Dark_Shikari> ll [18:10:37] <peloverde> Why did they even bother adding it when it spits out so many false positives [18:10:38] <Dark_Shikari> *lol [18:10:44] <Dark_Shikari> peloverde: it _is_ useful [18:10:48] <Dark_Shikari> the problem is there's no way to shut it up [18:10:50] <kshishkov> is there _not failing_ GCC project? [18:10:53] <astrange> clang just moves it into their "static analysis" option but the warning is just as bad [18:12:02] <peloverde> I don't think it's ever caught a real bug for me, and to shut it up i have to initializers that just slow things down [18:13:31] <Kovensky> kshishkov: weight-p [18:13:37] <Kovensky> oh, gcc [18:13:39] <Kovensky> I read taht as gsoc [18:13:44] <Kovensky> that* [18:20:20] <CIA-34> ffmpeg: rbultje * r21851 /trunk/libavformat/rtp_asf.c: [18:20:20] <CIA-34> ffmpeg: Don't return 0 if buffer setup failed. That signals the RTSP demuxer that [18:20:20] <CIA-34> ffmpeg: the packet was filled in, leading to virtually random behaviour in the [18:20:20] <CIA-34> ffmpeg: decoder later on. Instead, return a negative value. [18:22:05] <BBB> shit that's a bad one [18:22:08] * BBB hides in shame [18:22:10] <BBB> let me revert that [18:22:28] <BBB> that whole code seems broken anyway [18:24:13] <kshishkov> <CIA-34> ffmpeg: rbultje * r21852 /trunk/libavformat (3 files): revert RTP completely, it's broken anyway [18:25:54] <CIA-34> ffmpeg: rbultje * r21852 /trunk/libavformat/rtp_asf.c: Revert r21851. [18:26:02] * BBB kicks kshishkov [18:26:09] <BBB> I actually thought that was real for a second [18:26:28] <kshishkov> <CIA-666> ouch! [18:26:45] <Dark_Shikari> lol [18:27:28] <Dark_Shikari> <CIA-34> ffmpeg: darkshikari * r21853 /trunk/libavformat (21 files): revert RTP completely, it sucks anyway [19:16:05] <peloverde> What's going on with FATE these days? Is all that yellow still from the character set issues? [19:16:30] <mru> no, this is some other vague breakage [19:16:50] <peloverde> Is anybody working on it? [19:17:06] <mru> some say the references need updating [19:17:32] <peloverde> Isn't the point of FATE so we can track down exactly where things broke? [19:17:55] <mru> we know what broke it [19:18:10] <mru> it was some change related to -t handling [19:18:21] <mru> some files now get one frame less than they used to [19:18:39] <mru> go badger mike to update the refs [19:18:46] <peloverde> So either the change is correct and we need to update the test specs or the change is wrong and we need to revert? [19:19:06] <mru> or both [19:20:38] <peloverde> I count both as the former [19:21:36] <BBB> is url_open_dyn_packet_buf() broken? [19:22:00] <kshishkov> who uses it beside you? [19:22:03] <BBB> I get the weirdest output, where the data is preceeded by a 4-byte integer consisting of the max_packet_size value I fed it [19:22:17] <BBB> url_open_dyn_buf() works just fine [19:22:24] <peloverde> Some of the videos are coming out significantly shorter [19:22:27] <peloverde> like pva [19:22:49] <kshishkov> BBB: maybe you don't pass an AVPacket pointer to it? [19:23:22] <kshishkov> since output lookslike AVPacket contents [19:24:27] <BBB> I think it is intended [19:24:35] <BBB> the code very intentionally writes the packet size in there [19:24:41] <BBB> no idea how this ever worked [19:24:44] <BBB> maybe it didn't [19:24:53] <kshishkov> what code uses it? [19:25:10] <kshishkov> for example, nothing uses SHA-1 [19:26:55] <BBB> rtsp [19:27:04] <BBB> I think problem is fixed now [19:27:39] <CIA-34> ffmpeg: rbultje * r21853 /trunk/libavformat/rtp_asf.c: [19:27:39] <CIA-34> ffmpeg: Fix two problems (no idea how this ever worked): [19:27:39] <CIA-34> ffmpeg: - the return value of url_open_dyn_*buf() is 0 on success, so using [19:27:39] <CIA-34> ffmpeg: if (!(res = url_open_dyn_*buf())) return res; is not going to work [19:27:39] <CIA-34> ffmpeg: - url_open_dyn_packet_buf actually writes the max_packet_size before [19:27:39] <CIA-34> ffmpeg: each piece of data. Feeding this to the ASF demuxer will never work. [19:27:39] <CIA-34> ffmpeg: Therefore, use url_open_dyn_buf() instead. [19:31:57] <Dark_Shikari> mru: does ffmpeg have proper 16 byte alignment macros for arm? [19:32:14] <kshishkov> yes [19:33:42] <Dark_Shikari> k [19:33:47] <Dark_Shikari> kshishkov: you're getting a patch review [19:35:37] <kshishkov> thanks [19:38:22] <mru> Dark_Shikari: what do you mean? [19:39:44] <Dark_Shikari> I meant that it allocates 15 extra bytes on stack [19:39:48] <Dark_Shikari> and does a &~15 with the pointer [19:39:49] <Dark_Shikari> and all that [19:40:00] <mru> I have a patch for that [19:40:04] <mru> it was bikeshedded [19:40:09] <Dark_Shikari> .... it's still not in? [19:40:21] <Dark_Shikari> that's pathetic [19:41:10] * Kovensky remembers something about apple's gcc not respecting ARM's ABI that demands alignment for smth [19:41:32] <mru> arm abi requires 8-byte aligned stack on external function calls [19:41:36] <mru> apple ignores that [19:41:40] <kshishkov> Apple's GCC respects something? [19:41:47] <Dark_Shikari> steve jobs [19:41:59] <mru> no arm compiler can provide 16-byte alignment on stack [19:42:27] <kshishkov> Dark_Shikari: Apple history shows that they will get rid of him at first opportunity [19:43:39] <Dark_Shikari> mru: x264 has it though ;) [19:44:29] <mru> I know [19:44:38] <mru> we discussed it here back then [19:45:33] <Dark_Shikari> kshishkov: review sent [19:48:19] <Yuvi> mru: llvm svn can kinda, it lost the stack pointer when I tried it with ffmpeg though [19:48:33] <kshishkov> Dark_Shikari: got it [19:48:45] * kshishkov pauses "Yes, Minister" episode to read mail [19:49:22] <Dark_Shikari> also, wow, bink is really simple [19:49:29] <Dark_Shikari> like, everything in it actually makes sense as far as I can see [19:49:31] * Kovensky has spent the past 8 hours waiting for his vm to compile llvm+clang [19:49:33] <Dark_Shikari> every single mode is done as simple as possible [19:49:50] <Dark_Shikari> it's like what would happen if you gave On2 some sense [19:51:48] <kshishkov> Kovensky: make it swappy [19:52:06] * Kovensky is still waiting for it to finish compiling [19:52:09] <kshishkov> answering your question - get_bits(0) does not work on x86 [19:52:19] <Kovensky> it's on tools/clang/lib/Frontend now [19:52:30] <Dark_Shikari> kshishkov: ok [19:52:32] <Dark_Shikari> one more note [19:52:35] <Dark_Shikari> that I didn't note in that message [19:52:35] <kshishkov> Kovensky: that way it will take even longer. And if you could run that VM on different arch... [19:52:41] <Dark_Shikari> if you make that 8x8->16x16 DSP function as I said, you can remove a ton of code [19:52:43] <Kovensky> lol [19:52:47] <Dark_Shikari> i.e. the entire if(scaled) section [19:52:55] <Dark_Shikari> since you just do an 8x8 decode and, if(scaled), convert to 16x16 [19:53:01] <mru> get_bits(0) does a >>32 [19:53:04] <mru> which is undefined [19:53:13] <Kovensky> kshishkov: vmware server 2's defaults is to allow swapping [19:54:49] <kshishkov> Kovensky: not allow but really make it use swap instead of RAM [19:55:30] <Kovensky> http://www.houseofsixten.com/hcstaff/?p=1351 [19:55:49] <mru> buy more ram [19:56:23] <kshishkov> mru: his goal is to make it compile longer [19:56:41] * kshishkov remembers the times when computers had "Turbo" button [19:57:20] <kierank> kshishkov: was that last month in .ua ;) [19:58:16] <kshishkov> kierank: no, they all gone around 2000 or a few years later [19:58:35] <kshishkov> not after 2005 at least [19:58:50] <Kovensky> * kshishkov remembers the times when computers had "Turbo" button <-- mine switched between 20/40 MHz [19:58:55] <Kovensky> or at least that's what the display said [19:58:55] <Kovensky> :> [19:59:18] <mru> my current computer has a speed dial on the front [19:59:20] <mru> for the fan [19:59:27] <mru> and water pump [20:00:23] * Kovensky thinks C++ + g++ explain a lot of the slowness on llvm's compilation [20:00:43] <peloverde> >>32 works fine if you specify -fdo-what-i-mean-not-what-i-say [20:00:45] <kshishkov> huh? compiling C compiler with g++? [20:00:55] <astrange> llvm is written in c++ [20:01:20] <kshishkov> so I guessed [20:01:26] <Kovensky> llvm[4]: Compiling LLVMConventionsChecker.cpp for Debug build [20:01:26] <Kovensky> llvm[4]: Compiling MallocChecker.cpp for Debug build [20:01:27] <kshishkov> why not Lisp? [20:02:21] <astrange> http://pastebin.com/m2dd06ce9 "addl $0, %esi"? [20:03:00] <kshishkov> it's faster than cmp? [20:10:52] <mru> Dark_Shikari: aligned stack macros re-posted [20:14:07] <jez9999> BBB: hey... could you check in the patch for issue 1740? [20:15:31] <kshishkov> jez9999: have you provided patch approval, ID card and filled form 26-stroke-B ? [20:15:42] <jez9999> yup [20:15:53] <jez9999> papers are correct [20:16:43] <mru> and the $10k in a brown bag? [20:16:59] <mru> ah, "papers"... I see [20:18:39] <CIA-34> ffmpeg: stefano * r21854 /trunk/libavutil/ (pixdesc.h pixdesc.c): [20:18:39] <CIA-34> ffmpeg: Move read_line() and write_line() definition from pixdesc.h to [20:18:39] <CIA-34> ffmpeg: pixdesc.c, which are now not anymore marked as static inline. [20:18:39] <CIA-34> ffmpeg: Fix the inclusion of the private header intreadwrite.h in the public [20:18:39] <CIA-34> ffmpeg: header pixdesc.h. [20:57:02] <Dark_Shikari> I should patch review more often [20:57:04] <Dark_Shikari> take some load off michael [20:57:13] <Dark_Shikari> it's a good way to make it look like I'm doing something without actually doing work [21:02:04] <elenril> or you could fix remuxing h264 from matroska [21:02:06] * elenril hides [21:25:23] <Dark_Shikari> for int8_t ref[2] [21:25:24] <Dark_Shikari> if( (M16( ref ) & 0x8080) == 0x8080 ) [21:25:33] <Dark_Shikari> why is this not the same as if( ref[0] < 0 && ref[1] < 0 ) ? [21:25:39] <Dark_Shikari> where M16() is a uint16_t-reading macro. [21:28:47] <mru> hmm [21:29:04] <mru> ah, weird whitespace around your () [21:29:07] <mru> that's got to be it [21:30:36] <Dark_Shikari> lol [21:32:32] <astrange> it looks ok to me, debug it [21:33:06] <peloverde> Is ff_imdct_half supposed to be able to work with the same input and output? [21:36:45] <Dark_Shikari> astrange: er, that's weird. when I compiled it again it fixed itself. [21:37:19] <Dark_Shikari> ok, now that I have that structure [21:37:25] <Dark_Shikari> what's a better way to do ref[0]&&ref[1]? [21:37:30] <Dark_Shikari> i.e. if(ref[0]&&ref[1]) [21:37:34] <Dark_Shikari> given that we can now do an M16() [21:39:09] <astrange> r = M16(ref); if (r & 0xFF00) + [21:39:12] <astrange> oops [21:39:22] <astrange> r = M16(ref); if ((r & 0xFF00) + (r + 0xFE)) [21:39:33] <Dark_Shikari> I doubt that's faster... [21:39:37] <astrange> + 0xFF [21:39:40] <astrange> yeah, it's kind of lame [21:39:50] <Dark_Shikari> it's annoying, you can easily do || butnot && [21:45:19] <Dark_Shikari> hmm, can the < 0 double-check be done in one instruction? [21:45:24] <Dark_Shikari> I guess not without simd [22:01:07] <BBB> did any students come in yet for the summer of code? [22:02:14] <astrange> someone new came to ask about h264 decoder tuning, didn't say if he was a student [22:02:24] <astrange> i haven't heard anyone ask about it specifically [22:02:37] <BBB> hmmm... need to advertise more :) [22:39:36] <CIA-34> ffmpeg: stefano * r21855 /trunk/ffplay.c: [22:39:36] <CIA-34> ffmpeg: Rename the "enc" variable, which refers to the AVCodecContext of a [22:39:36] <CIA-34> ffmpeg: decoder, to "avctx". [22:39:36] <CIA-34> ffmpeg: See the thread: [22:39:36] <CIA-34> ffmpeg: Subject: [FFmpeg-devel] [PATCH] enc is not a good name for a decoder context [22:39:37] <CIA-34> ffmpeg: Date: Mon, 28 Dec 2009 22:56:25 +0100 [22:45:05] <peloverde> hurray for satisfying another required SBR "optimization" that actually makes the code 1% slower [22:45:24] <Dark_Shikari> what's that? [22:45:36] <peloverde> eliminating qmf_filter_scratch from sbr_qmf_synthesis [22:45:56] <peloverde> I've lost nearly 20% from the "optimizations" requested during review [22:46:02] <peloverde> it's kind of ridiculous [22:46:27] <Dark_Shikari> it does make sense if the optimizations allow DSPutil stuff [22:46:28] <Dark_Shikari> e.g. more SIMD [22:46:43] <peloverde> some of them do [22:46:51] <peloverde> some of them don't [22:47:16] <Dark_Shikari> why not say that they made it slower? [22:47:42] <peloverde> because I don't want to argue, i want to land SBR so I can finish and land PS so I can pay rent and buy things [22:47:57] <peloverde> I'm paid for PS, SBR is just a roadblock on the way [22:48:10] <peloverde> I can fix it later when I have more free time [22:48:25] <Dark_Shikari> lol [22:48:29] <Dark_Shikari> how much are you getting for PS? [22:48:37] <peloverde> 2000 Eur [22:49:40] <Dark_Shikari> .... that's it? [22:49:46] <Dark_Shikari> I thought it would be more work than that [22:50:16] <peloverde> PS is fairly straight forward [22:50:39] <Dark_Shikari> hmm, I guess. [22:50:48] <Dark_Shikari> I'm just surprised you wouldn't be able to squeeze more for that feature [22:52:55] <BBB> lucky guy whoever contracted him for that :) [22:53:03] <BBB> but peloverde, thanks for doing sbr :) [22:53:17] <CIA-34> ffmpeg: rbultje * r21856 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec.c): [22:53:17] <CIA-34> ffmpeg: When using RTP-over-UDP, send dummy packets during stream setup, similar to [22:53:17] <CIA-34> ffmpeg: what e.g. RealPlayer does. This allows proper port forwarding setup in NAT- [22:53:17] <CIA-34> ffmpeg: based environments. [22:53:17] <CIA-34> ffmpeg: Patch by Martin Storsj? <$firstname at $firstname dot st>. [22:53:57] <Dark_Shikari> BBB: indeed [22:54:43] <Honoome> oh fantastic now I start getting fingerprint collision [22:54:50] <astrange> you could leave out the ones that aren't faster and leave their patches as small tasks [22:54:51] <Honoome> one has to love ec2 to actually wish to work with that stuff [23:00:55] <CIA-34> ffmpeg: rbultje * r21857 /trunk/libavformat/ (rtpdec.h rtpdec.c): [23:00:55] <CIA-34> ffmpeg: Remove first_rtcp_ntp_time. This is used to prevent overflow of the timestamp, [23:00:55] <CIA-34> ffmpeg: but doesn't actually do that. What's worse, it creates timestamp adjustments [23:00:55] <CIA-34> ffmpeg: that are different per stream within a session, leading to a/v sync issues. [23:00:55] <CIA-34> ffmpeg: See discussion in thread "[FFmpeg-devel] rtp streaming x264+audio issues (and [23:00:55] <CIA-34> ffmpeg: some ideas to fix them)". Patch suggested by Luca Abeni <lucabe72 email it>. [23:02:50] * BBB just played his first rtsp/wmavoice strea [23:05:08] <CIA-34> ffmpeg: siretart * r21858 /branches/ (0.5 0.5/doc/ffmpeg-doc.texi): [23:05:08] <CIA-34> ffmpeg: misc. manpage updates, fixes LP: #501729, Debian: #570050 [23:05:08] <CIA-34> ffmpeg: Update ffmpeg documentation regarding metadata setting. -title, [23:05:08] <CIA-34> ffmpeg: -author, -copyright, -track, -album, and -year options have been [23:05:08] <CIA-34> ffmpeg: dropped in favor of -metadata. [23:05:08] <CIA-34> ffmpeg: Add an explanation and complete the metadata usage example. [23:05:09] <CIA-34> ffmpeg: backported revisions r19285, r19287 and r19320 by stefano. [23:15:18] <peloverde> Also why does PS live in subpart 8? [23:16:59] <mru> not enough subparts otherwise [23:17:59] <astrange> peloverde: you attached the simd patch instead of the sbr one [23:18:15] <peloverde> today is not my day [23:19:20] <peloverde> thanks [23:44:00] <CIA-34> ffmpeg: michael * r21859 /trunk/libavcodec/h264_cabac.c: [23:44:00] <CIA-34> ffmpeg: 2x faster ff_h264_init_cabac_states(), 4k cpu cycles less. [23:44:00] <CIA-34> ffmpeg: Sadly this is just per slice so the speedup with normal files should be negligible. [23:45:09] <Dark_Shikari> negligable.... ehehehheeh he hasn't seen our 20-mb-per-slice files ;) [23:46:18] <janneg> or he just doesn't consider them normal [23:46:24] <astrange> peloverde: the loop 'while (k <= sbr->n_lim)' has a stray ; at the end, my gcc warns new_bw may be uninitialized in sbr_chirp (fixed with av_uninit or a default switch case) [23:46:41] <astrange> peloverde: no other complaints. ...except ffplay plays everything at half speed [23:49:29] * mru wants to kill someone [23:49:49] <Dark_Shikari> janneg: of course [23:50:40] * Honoome hands some Amazon sysadmins to mru [23:51:06] <mru> any autohell devs in sight? [23:51:11] <mru> they'd better hide fast [23:52:02] <Honoome> mru: uhm may I help somehow? [23:52:18] * Honoome is no autohell developer, but is an autohell supporter [23:52:19] <mru> configure.ac:26: error: Please use exactly Autoconf 2.59 instead of 2.63. [23:52:23] <Honoome> … [23:52:26] <Honoome> no that's not autohell developers [23:52:29] <mru> configure.in:11: error: Autoconf version 2.60 or higher is required [23:52:37] <Honoome> taht's definitely the project being stupid, what project is that? [23:52:41] <mru> newlib [23:52:49] <Honoome> ouch :| [23:53:04] <Honoome> redhat/ex-cygnus… I think autotools people hate them as much as you do [23:53:07] <mru> all I want to do is add one small file... [23:53:32] <Honoome> mru: newlib, gcc, use a bastardised autotools buildsystem… which is much worse than autotools :/ [23:53:47] <mru> any idea how to "fix" it? [23:54:41] <Honoome> I'm afraid, not… the very fact that it has two configure.(ac|in) files with different extension says that the whole thing is screwed :( [23:54:56] <mru> different subdirs [23:55:06] <Honoome> yeah I guessed that [23:55:11] <Honoome> latest version in gentoo is from 2007 o_o [23:56:11] <Kovensky> I don't hate autotools but I sure hate libtool <_< [23:56:41] * Kovensky is workarounding at least three different libtool bugs, two of which are considered features [23:57:08] <Kovensky> "two of which"... I wonder if that even makes sense lol [23:57:41] <mru> perfect sense it makes [23:58:11] <Honoome> really, I don't dislike autotools because I have seen much worse stuff [23:58:33] * Kovensky remembers the dreaded cmake build system that was in ffms2 [23:58:33] <Honoome> but the autotools devs should get their shit together and have a *single* tool, not autoconf+automake+libtool with _slightly_ different ideas on how to do stuff =_= [23:58:37] <mru> I dislike bad things, even if worse things exist [23:58:51] <mru> and wildly incompatible versions [23:58:58] <Honoome> that as well [23:59:02] <mru> and of course each fucking package depends on a different version [23:59:17] <Honoome> why should they have multi-level incompatibilities one with the other? just make it a single fucking project that follows a single idea :|

1 0

IRC log for 2010-02-15
by irc＠mansr.com 16 Feb '10

16 Feb '10

[01:03:54] <astrange> two days of ffmpeg-mt debugging and i think it's going to result in 2 one-line commits [01:03:57] <astrange> oh well [01:04:24] <Dark_Shikari> it happens. [01:04:56] * Kovensky pets astrange [01:05:07] <mru> one line per day, not bad [01:05:16] <Dark_Shikari> the most annoying deadlock I ever dealt with was a one line fix [01:05:55] <mru> those are always the most annoying [01:06:02] <Dark_Shikari> >Last Name is invalid. Name cannot contain numeric or special characters (i.e. %,$,#).Last name is required [01:06:04] <mru> especially when it's the hardware that deadlocks [01:06:06] <Dark_Shikari> Fuck you, I have a hypenated name [01:06:40] * mru hands Dark_Shikari a dehyphenator [01:06:54] <astrange> i signed up for a bioware account using astrange+bw@gmail, then found you couldn't type + in the xbox keyboard... [01:06:55] <mru> now you have a camelcased name [01:07:20] <Kovensky> Dark_Shikari: http://www.cracked.com/article_17575_7-true-stories-that-prove-airlines-hat… <-- #4 [01:08:06] <Dark_Shikari> mru: yup [02:04:00] <saintdev> Dark_Shikari: that deadlock that we spent a few days debugging =p [02:04:05] <Dark_Shikari> yup [03:42:17] <astrange> ==91450== Source and destination overlap in memcpy_chk(0x11bd6ab08, 0x11bd6ab08, 40) [03:42:29] <astrange> is memcpying something to itself forbidden? [03:42:42] <astrange> the warning is technically wrong anyway, darwin memcpy is memmove [03:45:21] <astrange> oh, it is undefined. that's a pain, i have to add boilerplate to handle it [04:06:03] <astrange> hm, it'd be easier to debug mt seeking if regular seeking didn't already deadlock [04:15:35] <elenril> Honoome: ? [05:38:17] <elenril> lol@xkcd [05:41:35] <astrange> Kovensky: try theora seeking now (mpeg1 was broken too, i half-fixed it but just turned it off for now anyway) [05:46:20] <saintd3v> moose and squirrel =D [06:47:59] <pJok> mornings jai :) [06:50:49] <jai> good morning pJok :) [06:51:58] <benoit-> Good morning [07:38:06] <jai> http://fate.multimedia.cx/index.php?stderr=181631 [07:38:07] <jai> heh [07:41:34] <siretart`> good morning [07:42:05] <av500> gm [07:44:51] <KotH> salut [07:53:38] <av500> KotH: about the player, I think I have to pass [07:54:00] <av500> 64g I can only offer in a hdd based pmp [07:54:26] <av500> hmm, I could offer 60gb in an a5 though, 1.8" hdd [08:29:47] <siretart`> FYI, I've prepared test packages for ubuntu lucid with ffmpeg 0.5+libx264 API version 84 in my PPA. testers/comments welcome [08:29:49] <siretart`> Dark_Shikari: ^^ [08:33:40] * Dark_Shikari doesn't use ubuntu [08:33:42] <Dark_Shikari> but nice. [08:38:53] <siretart`> Dark_Shikari: I didn't try yet (I think), but what behavior do you expect if the updated presets are used with an libx264 api version 67? just work or weird behavior? [08:39:47] <Dark_Shikari> it will work fine [08:39:55] <Dark_Shikari> it _won't_ work with an old _ffmpeg_ [08:40:34] <superdump> people shouldn't mix presets between ffmpeg packages anyway... [08:40:47] <siretart`> Dark_Shikari: that's interesting to know, because I have to declare that dependency manually (and my test packages don't have them) [08:40:58] <Dark_Shikari> why do you have to? [08:41:01] <Dark_Shikari> they're part of the package [08:41:35] <siretart`> actually not [08:41:57] <siretart`> hm. I could probably move the presets from the 'ffmpeg' package to 'libavcodec' [08:42:03] <Dark_Shikari> agreed. [08:42:06] <Dark_Shikari> they don't make sense with anything else [08:42:18] <superdump> where's the parsing code? [08:42:44] <siretart`> that'd be a bit of waste for users that don't install 'ffmpeg', but only install libavcodec via some dependency [08:42:58] <siretart`> the presets are only useful for the /usr/bin/ffmpeg binary [08:43:05] <siretart`> that's why I've placed them there in the first place [08:43:51] <Dark_Shikari> a bit as in 10 kilobytes [08:43:53] <Dark_Shikari> big whoop [08:45:20] <siretart`> I'm just stating my rationale for why I did so that time [08:45:36] <siretart`> I don't think it's a big deal to change that [08:45:44] <Dark_Shikari> ah k [08:47:06] <siretart`> Dark_Shikari: I've posted your patch to ffmpeg-devel. maybe you want to comment on that :-) [08:49:56] <KotH> av500: hmm.. i'm looking rather for something like an a2 [08:50:18] <av500> 8gb only [08:50:20] <KotH> av500: so i guess, i have to wait another year or so until flash sizes double [08:50:29] <KotH> .o0(quatruple) [08:50:48] <av500> wait 18mo for 2x (simple moore [08:50:51] <av500> wait 18mo for 2x (simple moore) [09:04:25] <KotH> currently it's a bit faster, as prices for flash chips are dropping rapidly due to larger volumes [09:04:55] <av500> yes [09:05:05] <av500> still I doubt "simple" mp3 players will be 64GB soon [09:05:13] <av500> that will be pmp with video etc.. [09:05:22] <KotH> yeah.. [09:05:41] <KotH> though, there are "simple" players on the market with taht size [09:05:46] <Dark_Shikari> you can already get a 2GB mp3 player for $10 [09:05:49] <KotH> like the iaudio x5 and the ipod [09:05:56] <Dark_Shikari> you can get a $30 mp3 player with video support and a screen [09:05:58] <superdump> i saw a toshiba development where they're using short range radio EM and stacking chips with controllers to make a 1TB SSD with a footprint the size of a stamp [09:06:11] <superdump> i guess they're a bit chunkier as the chips are stacked though [09:06:31] <KotH> superdump: nope, stacked chips are not much bigger than normal chips [09:06:32] <superdump> data cube [09:06:38] <superdump> oh [09:06:48] <superdump> even if it's 8 chips stacked? [09:06:49] <KotH> the little bit of additional height is neglicible in most applications [09:06:59] <Dark_Shikari> remember the silicon itself is thin [09:07:09] <twnqx> a fully cased IC can be less than 1mm [09:07:15] <KotH> a die is usualy 0.5mm-1mm [09:07:17] <superdump> nifty [09:07:23] <KotH> you can thin it down to 0.1mm [09:07:38] <superdump> a 1TB stamp [09:07:40] <superdump> :) [09:07:43] <twnqx> yeah, the once used for wirebonding to PCBs are like that :P [09:07:45] <twnqx> ones* [09:07:50] <Dark_Shikari> datacube ftw [09:07:55] <superdump> lol [09:09:44] <superdump> they said it'd be 2012 before they roll out a proof of concept though [09:09:47] <av500> KotH: ok, I stand corrected [09:10:35] <superdump> a computer stuff retailer in the uk had an offer on a 32GB SSD and 1TB HDD the other week [09:10:50] <superdump> i think that's being encouraged as the way to go for the time being [09:11:24] <superdump> i also saw an in-one-package SSD/HDD combination that used some kind of 'smart' (yeah... right) caching [09:13:42] <KotH> av500: ? [09:14:18] <av500> [10:05] <KotH> though, there are "simple" players on the market with taht size [09:14:19] <av500> :) [09:14:30] <KotH> superdump: that has been done on bigger nfs servers for years [09:14:45] <KotH> av500: :-) [09:15:00] <KotH> av500: did you find any with flash storage? or just the x5 and the ipod? [09:15:46] <superdump> it would be nice to eliminate all audible noise from electrical devices [09:16:01] <av500> KotH: 60gb in the x5... [09:16:10] <av500> thats flash [09:16:22] <av500> or a drive? [09:16:34] <KotH> av500: 1.8" drive [09:16:40] <KotH> av500: i have one :) [09:16:40] <av500> ah [09:16:57] <av500> so the same drive we use in the a5/60gb [09:17:16] <superdump> av500: you work for cowon? [09:17:32] <KotH> unfortunately, the battery needs to be replaced and the software has problems with more than 10k files [09:17:47] <av500> KotH: 65536 ftw! :) [09:17:55] <av500> superdump: nope :) [09:18:04] <Bagder> KotH: rockbox doesn't! [09:18:14] <KotH> Bagder: yeah.. i know, i should switch somewhen [09:18:28] <KotH> Bagder: and i will if i cannot find another mp3 player within a reasonable time [09:18:32] <av500> Bagder: I remember a "max # of files per folder" setting, no? [09:18:45] <Bagder> yes but that's not quite like the X5's problem [09:19:08] <KotH> but that means i have to replace the battery, which means i have to find a PL553450 compatible single cell lion pack with electronics [09:19:49] <av500> with? [09:19:50] <KotH> and finding single cell lion packs with electronics is difficult if you need just one [09:19:59] <KotH> av500: schutzelektronik [09:20:07] <av500> feigling [09:20:14] <KotH> ^^' [09:20:40] <av500> superdump: I work for a competitor ... :) [09:20:46] <superdump> aha [09:20:50] <KotH> av500: the current cell has one, hence i'm not going to replace it with one that hasn't [09:20:59] <av500> reuse the one you have [09:21:24] <KotH> av500: have you worked with single cell lion packs? [09:21:51] <av500> yup [09:22:08] <av500> never with such tiny one though :) [09:22:09] <KotH> then you know how easy to solder they are ^^' [09:22:37] <av500> no idea, we have MMe Lam for that [09:24:01] <KotH> ^^' [09:33:04] <Dark_Shikari> siretart`: new x264 is up. [09:33:12] <Dark_Shikari> give it a few days of testing and hopefully we'll be good for beta release [09:33:34] <siretart`> Dark_Shikari: you mean you have a candidate for lucid? [09:35:05] <Dark_Shikari> I was thinking of just making the latest the candidate for now, plus any bugfixes after [09:35:28] <siretart`> sounds reasonable to me [09:35:43] <Dark_Shikari> 26 commits at once ftw [09:35:58] <siretart`> Dark_Shikari: btw, perhaps you can suggest a better version string than '1:0.svn20100213+gitfcf70c' (that's what I'm currently using) [09:36:23] <siretart`> how about a proper release number? [09:36:45] <Dark_Shikari> why not use the output of version.sh? [09:36:50] <Dark_Shikari> i.e. what x264 itself uses? [09:37:05] <siretart`> that would be "" [09:37:16] <Dark_Shikari> erm... [09:37:20] <Dark_Shikari> look a tad more carefully [09:37:46] <siretart`> my packaging branch is not based on 'your' x264 branch. I'm importing tarballs from yours [09:37:53] <siretart`> for consistency reasons [09:37:55] <Dark_Shikari> what difference does that make? [09:37:59] <Dark_Shikari> and we don't have branches [09:38:16] <Dark_Shikari> as long as you have .git, you can get a valid version number [09:38:17] <siretart`> branch as in 'a series of commits' [09:38:20] <Dark_Shikari> #define X264_VERSION " r1442 781d300" [09:38:21] <Dark_Shikari> #define X264_POINTVER "0.85.1442 781d300" [09:40:31] <siretart`> hm. even in the upstream branch ./version.sh gives me "" [09:40:33] <siretart`> not helpful [09:40:47] <Dark_Shikari> it writes it to config.h [09:41:12] <siretart`> so I need to build it to get a version number? that's clumsy [09:41:18] <Dark_Shikari> no [09:41:25] <Dark_Shikari> you could just run version.sh and read config.h [09:41:25] <Dark_Shikari> lol [09:41:34] <siretart`> can't you just use 'git tag' and I'm basing the package version on that? [09:41:43] <Dark_Shikari> we don't do tags or branches [09:41:51] <siretart`> that'd be helpful [09:41:55] <Dark_Shikari> if it would be useful, maybe we could tag every single revision with its number [09:42:00] <Dark_Shikari> scripts welcome [09:42:22] <siretart`> tagging each and every revision is not helpful [09:42:30] <siretart`> tagging revision you expect distros to use would be [09:42:37] <Dark_Shikari> sure it's helpful [09:42:37] <siretart`> that's not scriptable [09:42:42] <Dark_Shikari> it lets you match revision numbers with revisions [09:43:20] <siretart`> I guess I miss what you mean with 'revision' [09:43:55] <Dark_Shikari> I'm just saying people have complained about that [09:43:57] <twnqx> x264 revisions are git revisions, there's nothing else [09:44:02] <Dark_Shikari> hard to convert "r1283" to a git rev number [09:44:05] <Dark_Shikari> er, git rev hash [09:44:09] <jez9999> Are there any known problems when piping packets through Windows ICS that cause video decoding problems in ffmpeg? I'm having a problem where, when the same camera is routed through a Linux box or router, its data decodes OK, but when through Windows ICS, avcodec_decode_video2 fails. [09:44:11] <Dark_Shikari> twnqx: we use rev numbers though [09:44:30] <twnqx> which are derived from the number of git commits, if i read the script correctly :) [09:44:35] <jez9999> it's UDP (RTP), by the way [09:44:42] <Dark_Shikari> twnqx: yes, but they're based off the svn numbers [09:45:26] <siretart`> #define X264_VERSION " r40+9 4e3eff0" and #define X264_POINTVER "0.84.40+9 4e3eff0" is what ./version.h produces in 'my' packaging branch. that's nonsense [09:45:43] <Dark_Shikari> lol [09:45:44] <twnqx> no [09:45:46] <Dark_Shikari> wtf did you do to it [09:46:27] <siretart`> Dark_Shikari: i'm cloning from http://git.debian.org/?p=pkg-multimedia/x264.git;a=summary and use the 'ubuntu' branch [09:46:45] <siretart`> as said, ./version.h is pretty useless to me in its current form [09:46:58] <siretart`> oh, I didn't push my revision there yet, btw [09:47:06] <Dark_Shikari> um [09:47:08] <Dark_Shikari> you could like [09:47:08] <Dark_Shikari> run it [09:47:14] <Dark_Shikari> and copy the output by hand (omg!) [09:47:20] <Dark_Shikari> once every 6 months when you update the package (what!) [09:47:26] <Dark_Shikari> that's what I originally suggested [09:47:34] <Dark_Shikari> it's 20 extra seconds for each update [09:47:36] <Dark_Shikari> 20 seconds every 6 months [09:47:54] <siretart`> yes, but you have sucessfully distracted from my original question [09:48:03] <Dark_Shikari> no I haven't [09:48:05] <Dark_Shikari> that's the format I recommend [09:48:32] <siretart`> please state an example. what should the version number look like instead of '0.svn20100213+gitfcf70c' [09:48:35] <twnqx> 0.79.1330M af612d7... hm, i should update, too [09:49:11] <Dark_Shikari> siretart`: what does ubuntu use for ffmpeg for example? [09:49:41] <siretart`> currently lucid is at: 4:0.5+svn20090706-5ubuntu4 [09:50:02] <siretart`> to indicate that the 0.5 branch is tracked and last updated at that date [09:50:17] <siretart`> 5 revisions in debian, +4 in ubuntu [09:50:35] <Dark_Shikari> something like 0.85.r1442 git781d300, maybe with a date stuck in there somewhere [09:50:42] <elenril> why do you use tarballs btw? [09:50:44] <siretart`> spaces are not allowed [09:50:54] <siretart`> elenril: I need to compile a source package, which requires a tarball [09:50:55] <Dark_Shikari> siretart`: whatever, use a - [09:50:58] <Dark_Shikari> I didn't mean literally that [09:51:05] <twnqx> wait, source packages require tarballs? [09:51:17] <twnqx> oh well. [09:51:39] <elenril> can't you just git archive or whatever that's called [09:52:16] <twnqx> what the hell did my 264 update just do [09:52:28] <siretart`> Dark_Shikari: 1:0.85.r1442+git781d300 would indeed be an option. [09:52:28] <Dark_Shikari> basically siretart` [09:52:41] <Dark_Shikari> would it be too unreasonable to find a way to get a datestamp there too? [09:52:50] <Dark_Shikari> though that's already freaking long [09:52:50] <siretart`> though '1:0.85.r1442' might do as well [09:52:57] <Dark_Shikari> people would complain about r1442 [09:53:01] <Dark_Shikari> no immediate match to git [09:53:20] <Dark_Shikari> unless we implemented autotagging/etc [09:53:23] <siretart`> you can look that up from /usr/share/doc/libx264/changelog.Debian.gz [09:53:38] <siretart`> elenril: that's what I'm using [09:54:11] <twnqx> my live ebuild is broken :( it build the new x264 executable against the old lib... [09:55:06] <twnqx> Dark_Shikari: 0.85.1442M <- wouldn't the M indicate local changes? :S [09:55:13] <Dark_Shikari> Yes [09:55:55] <elenril> siretart`: i mean why isn't git://git.debian.org/pkg-multimedia/x264.git a fork of official repo [09:56:33] <elenril> iirc for ffmpeg you said it was because of svn externals [09:56:43] <elenril> but that doesn't apply here [09:56:52] <siretart`> elenril: for consistency reasons. x264 is team maintained and having different repo styles on team git archives is not helpful [10:01:32] <elenril> and that is worth losing history/making it unmergeable with official repo? :/ [10:03:57] <siretart`> elenril: have you ever worked with packaging branches? [10:05:48] <elenril> no [10:06:01] <siretart`> I imagined so [10:06:17] <elenril> well explain it to me then (if you have time) [10:07:20] <siretart`> in short: yes, it is worth, we use quilt to manage upstream changes. [10:07:55] <siretart`> sorry, no time for more elaborated explanation [10:10:17] <elenril> ok, maybe later [10:10:30] <elenril> i was just wondering why some repos track upstream and some don't [11:15:55] <Compn> cmt FlixEngineLinux_8.0.15.3 (www.on2.com) [11:16:06] <Compn> hah, i found a flix-encoded-mp4 file :D [11:16:20] <Compn> too Lavf52.16.0 [11:16:46] <jez9999> Are there any known problems when piping packets through Windows ICS that cause video decoding problems in ffmpeg? I'm having a problem where, when the same camera is routed through a Linux box or router, its data decodes OK, but when through Windows ICS, avcodec_decode_video2 fails. [11:16:49] <jez9999> it's UDP (RTP), by the way [12:00:15] <pross-au> wb kshishkov [12:01:13] <kshishkov> howdy cobber [13:35:49] <mru> Dark_Shikari: why 3 mails per commit on x264-devel? [13:36:20] <kshishkov> mru: one for devs, one for public and one for archival purposes [13:42:54] <merbzt> how do I define a vararg function pointer ? [13:43:05] <mru> ... [13:43:12] <kshishkov> void (*func)(int arg0,...) [13:43:28] <Honoome> mru: yeah that's the right answer in this case ;) [13:45:12] <elenril> Honoome: you wanted something about metadata? [13:45:44] <Honoome> elenril: ah yeahâŠ the ffmpeg snapshot in gentoo has been updated a couple of days ago, and now my flacâalac recording drops the Artist field [13:46:11] <Honoome> before I go knocking on the maintainer's door, can you tell me whether something changed/was broken recently? :) [13:46:34] <elenril> yeah, you should probably blame me [13:46:56] <elenril> what container? [13:47:17] <merbzt> so I need at least one argument and the the ...? [13:47:20] <Honoome> flacâm4a[alac] -- can alac be encoded in anything else? :P [13:47:37] <merbzt> hmm int (*callback)(, ...); seemed to work [13:47:39] * elenril has no idea wtf alac is [13:47:50] <Honoome> -f ipod fwiw as that's the only way to get it to be seen by an ipod to begin with (and my only reason to use alac in the first place) [13:47:54] <merbzt> apple lossless [13:48:23] <merbzt> mov/mp4 [13:48:39] <elenril> yeah, somebody forgot to change author->artist in the mov muxer [13:48:48] * elenril wonders who could that be :) [13:50:21] * Honoome gets ready to ask for a new snapshot/backport of FFmpeg for Gentoo :D [13:50:46] <Kovensky> someone should ask for a new snapshot of mplayer on fbsd [13:50:51] <Kovensky> they still have rc2 on ports [13:50:52] <Kovensky> lol [13:50:53] <Honoome> I wouldn't have noticed at all if it wasn't that I'm ransacking Magnatune after getting a subscription ;) [13:51:06] <Kovensky> (they somehow managed to beat debian stale) [13:51:13] <Honoome> Kovensky: I'm afraid until the next 7.x release is out they have frozen ports [13:51:22] <Kovensky> I'm on 8.0 [13:51:48] <Kovensky> well, I'm actually on win7, since it's the only OS that SiS still supports <_< [13:52:11] <Kovensky> I thought about putting fbsd as main but they don't have sis191 drivers [13:52:24] <Kovensky> so I'm with it on a vm ._. [13:53:06] <elenril> write one for linux ;) [13:56:47] <mru> merbzt: variadic functions need at least one fixed argument [13:56:52] <Kovensky> linux already has one =p [13:56:56] <Kovensky> just not a video one [13:59:49] <elenril> Kovensky: you had some autoaway on detach script, right? [14:00:09] <Kovensky> it's some script on scripts.irssi.org [14:01:18] <merbzt> mru: msvc didn't choke on int (*callback)(, ...); [14:01:33] <merbzt> does that mean the first argument is void ? [14:04:33] <kshishkov> merbzt: IIRC, first arg is needed for varargs to access the rest of them [14:04:56] <mru> merbzt: that's not valid C [14:05:01] <mru> never trust msvc [14:05:02] <merbzt> :) [14:05:15] <mru> there is no such thing as a void arg [14:05:34] <kshishkov> mru: but I trust MSVC to not compile vanilla FFmpeg [14:06:59] <Honoome> kshishkov: something along the lines of âif it builds with MSVC there's something fundamentally wrong with itâ? [14:08:29] <kshishkov> Honoome: no, not necessary. Helloworld should work fine with it, for example [14:08:45] <Honoome> ah true [14:08:49] <KotH> is MSVC finally c99 compatible? [14:08:55] <mru> no [14:09:00] <KotH> or are they still stuck with c89+extensions? [14:09:03] * Honoome has had some nefarious experience with MSVC and C++âŠ [14:09:12] <Honoome> last time I had to develop under Windows I went for Borland^W CodeGear [14:09:26] <mru> it's still c89+extension-amputations [14:11:08] * KotH knows hwy he doesnt develop apps for windows [14:11:34] <Kovensky> they will never get c99 compatible [14:11:54] <Kovensky> they're a Visual C compiler, and that's C++ with extensions [14:12:03] <Kovensky> c89 just happens to compile on it ._. [14:14:17] <KotH> so, c will move on and they will be stuck with their old cruft? [14:14:26] <KotH> .o0(why does that sound so familliar?) [14:14:50] <kshishkov> KotH: because it's usual lifecycle? [14:15:49] <Kovensky> well, the only way they'll be c99 compatible is if c++0xA allows it [14:15:54] <KotH> depends, most systems get rid of such stuff quite fast [14:15:56] <Kovensky> or is it 0xB? =p [14:16:30] <KotH> unlike windows, which could run 16bit os/2 apps until vista [14:17:15] <kshishkov> Kovensky: the funniest thing is MSVS _Embedded_ - it compiles only C++ (and refuses to take .c completely) but does not allow using any of standard C++ headers or libraries [14:17:38] <Kovensky> lol? [14:17:46] <Kovensky> how the hell are you supposed to do anything on it [14:18:06] <kshishkov> use <stdio.h> instead of <fstream.h> in C++, of course [14:18:48] <Kovensky> =p [14:19:23] <kshishkov> I found that gcc ported to WinCE served me better [14:19:43] <KotH> eh.. same here [14:19:47] <kshishkov> (and it's hard to type on that small onscreen keyboard) [14:19:51] <KotH> we use lcc for windows apps :) [14:20:40] <Kovensky> it [14:20:44] <Kovensky> hurf [14:22:42] <kshishkov> offtopic - if SMART reports error reading sector, does that mean HDD has badblock? [14:23:41] <mru> it can mean that [14:23:48] <Kovensky> probably, specially if the error repeats itself [14:23:53] <av500> kshishkov: replace hdd [14:24:01] <merbzt> most likely the HD shouldn't be used for vital info [14:24:23] <av500> some people need anime to live, no? :) [14:24:25] <kshishkov> and if I hear click, system freezes for a second and reports read error? [14:24:45] <kshishkov> and that can be reliably reproduced? [14:24:47] <Kovensky> definitely something bad is going on [14:24:47] <mru> I always replace drives on the first sign of error [14:24:56] * Kovensky used to get that with maxtor drives [14:25:08] <mru> unless I know I accidentally nudged a cable or something [14:25:11] <Kovensky> I had all 4 of my maxtors die on me on the same way [14:25:25] <mru> always the same story with maxtor [14:25:29] <kshishkov> I gave that netbook to warranty service center. Thay haven't found a thing and touchpad stopped working. [14:25:48] * kshishkov had Fujitsu MPG [14:26:28] <elenril> how do i check why the regtests are dying? [14:26:53] <elenril> is ffmpeg's stdout/stderr logged somewhere? [14:28:06] <kshishkov> yes [14:28:23] <mru> elenril: make test V=2 [14:28:42] <elenril> thanks [14:28:54] * thresh doesnt run any build commands without |& tee logfile [14:30:46] * Kovensky detects bashism [14:31:00] <thresh> nope, a zshism [14:31:09] * KotH detects people who do not believe in being bourne again [14:31:27] * mru bashes shell extensions [14:32:06] <av500> dash ftw! [14:32:27] <KotH> mru: are you a solaris 6 user? ;) [14:33:09] * Kovensky is reminded to leech a solaris iso [14:33:17] * Kovensky wants to experiment with more OSes [14:33:21] <KotH> kshishkov: dont! [14:33:31] <KotH> kshishkov: do not follow the path to darknes! [14:33:45] <av500> Kovensky: I have signed minix3 cd, willing to sell it :) [14:33:46] * thresh somehow feels KotH's IRC client sucks [14:33:47] * Kovensky pets kshishkov [14:33:56] <KotH> av500: lol [14:34:10] <KotH> er.. [14:34:12] <KotH> well... [14:34:23] <KotH> tab complete, you know ^^' [14:34:26] <Kovensky> I have toyed with DOS, win3.11, win9x, winnt, several flavors of linux2.6, now fbsd [14:34:31] <Kovensky> next on the list are solaris and osx [14:34:59] <KotH> Kovensky: os/2 missing! [14:35:08] <KotH> beos too! [14:35:23] * mru has messed with OSE [14:39:04] <elenril> lawl, asfdec can't read files written by asfenc [14:39:15] <elenril> if there's any metadata in them [14:39:30] <av500> M$ does not want anybody to convert from ASF, so that makes sense :) [14:39:32] * elenril wonders if he broke it himself [14:42:59] <elenril> it seems asfenc is used really often :) [14:43:14] <elenril> mplayer plays them fine though [14:58:33] <elenril> anyone knows what asf version does asfenc write? [15:01:14] <kshishkov> do you expect anyone to remember the whole version GUID? [15:01:49] <elenril> no, i expect 1.0 or 2.0 [15:01:57] <kshishkov> 1.0 then [15:02:02] <elenril> you sure? [15:02:09] <kshishkov> "version 2 is patented and nobody uses it" [15:02:11] <elenril> it has no docs [15:03:20] <BBB_> version 2 is documented by MS and unused [15:03:25] <BBB_> version 1 is undocumented and used [15:03:35] <BBB_> so presumably we write 1.0 [15:04:00] <elenril> actually 2.0 describe what the muxer is doing quite well [15:05:51] <elenril> pecifies an array of Unicode characters that contains [15:06:11] <elenril> pure w00tnes, didn't they hear there are multiple representations of unicode? [15:06:27] <kshishkov> yes, M$ way and right way [15:06:37] <Kovensky> no, to microsoft there is only one way [15:06:39] <Kovensky> that is UTF-16LE [15:06:40] <kshishkov> IIRC they always used UCS-16 for Unicode [15:06:48] <elenril> then we're DoingItWrong [15:06:54] <elenril> not that anybody cares [15:06:55] <Kovensky> kshishkov: was UCS2 until win2k, when they changed to UTF16LE IIRC [15:07:09] <Kovensky> they're almost identical, except UTF16 supports surrogate pairs [15:07:17] <kshishkov> Kovensky: oh yeah, what about bug-for-bug compatibility? [15:07:24] * justlooking if Kovensky likes obscure OS's to try then he should perhaps look at #aros irc://irc.freenode.net/aros.dev http://aros.sourceforge.net/ [15:12:50] <elenril> hmm, so asfdec fails at reading the extended content header [15:13:01] * elenril wonders why is he wasting time at this [15:14:53] <Honoome> self-hatred? [15:15:33] <elenril> probably [15:16:14] <Honoome> that's my answer when I ask myself why I keep on working on Ruby [15:16:28] <elenril> lol [15:32:06] <BBB> grin @ last line of peloverde message on ffmpeg-devel@ [15:32:43] <peloverde> BBB that actually is/was an issue [15:33:53] <bilboed-pi> peloverde, alex converse ? [15:34:17] <bilboed-pi> peloverde, saying some software is bad because you don't understand it doesn't really help [15:35:24] <bilboed-pi> (unless you meant demuxers from gst-plugins-bad :) ) [15:35:49] <KotH> .o0(round one! fight!) [15:36:02] <peloverde> bilboed-pi, I believe you said the same thing [15:36:15] <peloverde> then I explained to you exactly in what cases you need to set needs parsing for aac [15:36:23] <Honoome> KotH: should we provide weapons or leave them at using punches? [15:36:23] <peloverde> and then... nothing happened [15:36:31] <bilboed-pi> peloverde, maybe we've got other things to do ? [15:36:37] <bilboed-pi> peloverde, you can blame me for not reactin [15:36:57] <peloverde> bilboed-pi, comments in your code still says that my code is broken [15:37:03] <bilboed-pi> peloverde, anyway, having OOB fixes is always a good thing imho [15:37:11] <peloverde> true [15:37:32] <KotH> Honoome: we want them to stay alive, so no weapons [15:37:58] <bilboed-pi> Honoome, I choose fencing then ! [15:38:23] * elenril agrees with KotH, peloverde needs to stay alive until sbr is committed [15:38:33] <Honoome> bilboed-pi: you can use the unlootable dagger given at character creation then :P [15:38:34] <Kovensky> then he'll be disposable? [15:38:52] <siretart`> peloverde: do you think that and/or similar patches should go to the 0.5 branch as well? [15:39:15] <peloverde> siretart`: probably makes sense [15:40:35] <merbzt> is Baptiste on holiday or something ? [15:41:40] <peloverde> I've had that patch kicking around since around when 0.5 was released [15:43:58] <superdump> peloverde: so what does need fixing in gst demuxers with respect to aac? [15:45:49] <bilboed-pi> superdump, the fixing's been done in demuxers [15:45:53] <peloverde> superdump, http://bugzilla.gnome.org/show_bug.cgi?id=566250 [15:46:49] <bilboed-pi> the demuxers now properly include in the caps how the aac data is packetized (or not) [15:47:06] <bilboed-pi> so basically we only want to use the AVParser IFF it's raw ADTS [15:48:47] <superdump> bilboed-pi: yup [15:52:42] <peloverde> mru, which const is misplaced? [15:52:52] <mru> one of them [15:53:04] <mru> const char const * should be const char *const [15:53:10] <mru> but it should all be const char foo[] [16:02:20] <peloverde> superdump, Can I tag decode_pce() as av_cold? We only call it once now [16:02:33] <superdump> sure [16:02:35] <mru> once per stream? [16:02:38] <mru> then it should be av_cold [16:02:55] <peloverde> mru, yes, unless there is garbage at the beging of the stream than it is until we get a valid frame [16:03:03] <peloverde> but i'm not worried about optimizing for broken streams [16:03:05] <mru> same thing [16:03:47] <Honoome> hmm it has been quite a while since I last ran cowstats over ffmpeg [16:04:12] <peloverde> Decreases aac.o size by ~3.1% [16:04:27] <kshishkov> Honoome: try also sheepstats and pigstats [16:05:00] <Honoome> kshishkov: is that Position Indipendence Gruesomness statistics? :P [16:05:18] <KotH> pigs? [16:05:32] <KotH> isnt' that a short for certain countries with money problems [16:05:34] * kshishkov values pigs over cows [16:05:34] <KotH> ? [16:05:41] <Kovensky> http://multimedia.cx/eggs/call-for-samples/ <-- are SSA/ASS samples that hard to find? :V [16:05:53] <kshishkov> KotH: you are thinking of financial black holes [16:06:10] <Honoome> Kovensky: Mike doesn't watch anime, I guess [16:06:45] <kshishkov> he stated it in his blog too [16:07:12] <kshishkov> that's the reason he's not a MPlayer dev for a long time [16:07:26] <mru> mike was never an mplayer dev iirc [16:08:02] <Honoome> he was xine ;) [16:08:07] <mru> yep [16:08:08] <BBB> that's what I thought also [16:08:20] <kshishkov> mru: he was [16:08:25] <BBB> but mike is corporate now :) [16:08:40] <mru> that's irrelevant [16:13:13] <KotH> kshishkov: nope, mike never worked on mplayer [16:13:47] <kshishkov> I may be wrong but I think he mentioned one or two patches for MPlayer [16:13:57] <KotH> oops.. he was [16:14:11] <KotH> at lest he's been mentioned in AUTHORS [16:14:28] <Honoome> well, if it's one or two patches, I think I have one or two patches in VLC :P on the other hand I'm pretty sure I can only be classed as a xine dev :P [16:14:50] * kshishkov is MPlayer dev of Compn-class [16:14:50] * KotH wonders why he doenst remember mike working on mplayer [16:14:54] * mru has patches in all kinds of scary places [16:15:07] <KotH> mru: nope [16:15:15] <KotH> mru: you're lacking the mplayer trophy [16:15:29] <mru> are you sure? [16:16:15] <thresh> having patches in mplayer is like having a black label if you're a pirate [16:16:50] <thresh> or is it called a black spot? [16:17:16] <kshishkov> black mark or black subpoena ;) [16:17:58] <kshishkov> at least the source calls it "black spot" [16:18:53] * elenril headdesks [16:18:54] <mru> KotH: there are entire files in mplayer with my (c) [16:19:31] <KotH> mru: what have you done?!? [16:19:36] <kshishkov> elenril: try Russian traditional way of facepalming - killing yourself with a wall [16:19:59] <kshishkov> KotH: from external repos like libavcodec ;) [16:20:36] <CIA-34> ffmpeg: alexc * r21833 /trunk/libavcodec/aac.c: AAC: Mark functions that are only called when the output configuration is not locked as av_cold. [16:20:39] <mru> KotH: some 3dlabs drivers [16:21:12] <KotH> mru: ...you're tainted.... [16:21:25] <elenril> kshishkov: i'd rather kill the person who wrote this stuff [16:21:27] <kshishkov> KotH: says matrox driver man [16:21:56] <kshishkov> elenril: what stuff? ASF? [16:22:16] <elenril> kshishkov: yeah [16:22:49] <Honoome> elenril: if you can get the guys who wrote RTSP as well, I'd be happy to lend a hand [16:22:49] <kshishkov> throw a chair at them [16:23:14] * thresh repairs a 19T partition [16:23:18] * kshishkov counts: Adobe, M$, Buffering Inc., what else [16:23:24] <elenril> why can't they use utf8 like all sane people do [16:23:43] <Honoome> because it makes soooo much sense to re-use HTTP, which has the protocol identifier at the end of the request lineâŠ [16:23:57] <Honoome> so you cannot validate it until you reach the end, and then you start back overâŠ [16:24:32] <mru> you don't need to parse the whole line to extract the last word [16:24:44] <KotH> kshishkov: you're just jealous that you dont have so many matrox cards yourself [16:24:59] * mru has a matrox card that KotH doesn't have [16:25:02] <Honoome> mru: I still need to backtrack though [16:25:13] <mru> Honoome: strrchr(req, " ") [16:25:17] <kshishkov> KotH: but I had Trident and S3 Virge! [16:25:29] * mru has a dual-vga g400 on agp [16:25:31] <mru> rare stuff [16:25:56] <Honoome> mru: yeah but since I need to parse the first two tokens anyway (but differently depending on the third, last one)âŠ [16:26:08] <Honoome> plus I'd need to have the lines split already, to use strrchr [16:26:34] <Honoome> so the best method I can come up with is to âvalidateâ the first two tokens, parse the third, then backtrack and parse (with the correct parser) the first two again [16:26:35] <mru> I agree it's annoying, but not *that* annoying [16:26:54] <Honoome> not especially bad, but it would have made much more sense to have the protocol identifier at the *beginning* of the line [16:30:35] <CIA-34> ffmpeg: alexc * r21834 /trunk/libavcodec/aac.c: [16:30:35] <CIA-34> ffmpeg: AAC: Mark che_configure() as av_cold. [16:30:35] <CIA-34> ffmpeg: It is also only called when the output configuration is not locked. [16:32:02] <KotH> mru: right, you didnt bring it to fosdem [16:33:43] <mru> if you really wanted it you'd come and collect it here [16:35:28] <av500> mru: I think I have 3 of those here, want any? :) [16:36:06] <mru> one's plenty [16:36:28] <mru> I have only 2 agp slots in the house [16:36:41] <av500> kitchen and loo? :) [16:36:50] <mru> and the mga only works in one of them [16:37:01] <mru> and that one will probably never be rebooted [16:37:22] <mru> it's running now, but when it goes down I probably won't bother fixing it [16:37:23] <av500> and does not need dualhead anyway? :) [16:38:02] <CIA-34> ffmpeg: stefang * r21835 /trunk/libavcodec/cavs.c: avoid using DECLARE_ALIGNED on stack variable as suggested by Reimar [16:44:35] <CIA-34> ffmpeg: stefang * r21836 /trunk/libavcodec/ (cavs.h cavsdec.c): [16:44:35] <CIA-34> ffmpeg: add heuristic to discern the old sample clips from streams encoded [16:44:35] <CIA-34> ffmpeg: with rm52j encoder, a marker_bit has been added in the I-Frame syntax [16:47:43] <KotH> huh? you dont have a video wall in your toilet? [16:48:04] <av500> now that got me thinkine [16:48:05] <av500> now that got me thinking [16:48:18] <av500> prolly the only place my wife lets me put it :) [16:48:30] <superdump> she might get suspicious [16:48:31] <KotH> hehe [16:49:14] <benoit-> and anyway, that's often a (too?) small wall [16:50:59] <KotH> you dont know the german toilets! [16:51:25] <av500> I park my S600 in there too :) [16:58:19] <KotH> no BMW? [16:58:36] <KotH> you disappoint me! [16:59:53] <av500> BMW, in the loo? are you crazy? [17:00:42] <KotH> well, would you leave it outside instead? [17:00:47] <mru> crap cars, bmw... [17:00:49] <KotH> in germany, none the less [17:01:01] <mru> KotH: nonetheless is one word [17:01:07] <KotH> thanks [17:01:23] <av500> KotH: it's in the shed (color open for discussion) [17:01:33] <KotH> lapisblau! [17:01:41] <kshishkov> mru: do you prefer English cars? [17:01:56] <Honoome> are there English cars? o-O [17:02:01] <mru> there used to be some good english cards [17:02:05] <mru> cars [17:02:14] <kierank> rolls royce [17:02:20] * kshishkov knows the only true (bike)shed is FalurÃ¶da [17:02:20] <mru> bentley [17:02:26] <kshishkov> the same thing [17:02:36] <av500> mru: did I mention I know somebody who collects bentley....sigh [17:02:38] <kshishkov> what about Vauxhall? Morris? [17:02:48] <KotH> now, that i've painted the shed, it's time for me to leave the battlefield [17:03:05] <KotH> readya tomorrow [17:16:50] <Kovensky> http://esr.ibiblio.org/?p=1705 <-- the story of GCC [17:17:03] <Kovensky> it's fun how he recommends building with -O0 though; does ffmpeg even build with -O0? IIRC it runs out of registers... [17:17:25] <kshishkov> it does so with -O3 as well [17:18:15] * elenril wonders if anybody maintains asfenc [17:18:25] <av500> you? :) [17:18:39] <kshishkov> elenril: we have _default_ maintainer [17:18:52] * elenril sighs [17:18:52] <kierank> [17:02] <@kshishkov> what about Vauxhall? Morris? --> I guess by .ua standards they are godlike cars [17:18:56] <Honoome> Kovensky: it doesn't fail because of the registers [17:19:04] <elenril> why do all my patches have to go through mn [17:19:07] <Honoome> Kovensky: it fails earlier because of the missing DCE [17:19:24] <kshishkov> kierank: no, what was designed here (FIAT ripoffs) cannot be considered cars at all [17:19:26] <Kovensky> DCE? [17:19:38] <Honoome> Dead Code Elimination phase [17:19:56] <kshishkov> av500: just wondering, do ICE trains have power outlets and Internet access? [17:20:08] <Kovensky> oic [17:20:12] <av500> yes [17:20:13] <Honoome> if ( 0 ) call_undefined_function(); â no problem if DCE is done, but it's a problem at -O0 [17:20:20] <av500> internet access not on all line [17:20:21] <av500> internet access not on all lines [17:20:30] <av500> but I prefer my 3g anyway [17:20:41] <av500> power in all 1st class for sure, 2nd at some places I think [17:20:54] <av500> kshishkov: you come and visit me? [17:20:55] <kshishkov> our trains don't even have standard cell coverage for even major lines :P [17:21:03] <kshishkov> av500: unlikely [17:22:20] <BBB> Honoome, that's not true, afaik [17:22:33] <Honoome> BBB: hm? what do you mean? [17:22:34] <BBB> Honoome, I've used if (0) and -O0 and afaics the code is being removed [17:22:40] <Kovensky> gl even finding trains around here ._. [17:22:41] <BBB> (by gcc) [17:22:53] <Honoome> BBB: uhm okay maybe I cannot guarantee about proper if ( 0 ) [17:23:09] <Kovensky> and I remember I once was on a car trip to a neighboring state; we only had cellphone signal on two or so hub towns [17:23:12] <Honoome> it definitely is the case that it's not dropped for if ( something_always_false() ) [17:23:19] <Kovensky> everywhere else was dead phone ._. [17:23:48] <kshishkov> Kovensky: http://en.wikipedia.org/wiki/Railway_stations_in_Brazil [17:24:20] <Kovensky> lulz [17:24:24] <Kovensky> yes, that's very incomplete [17:25:09] <kshishkov> only "Planning" section is incomplete [17:25:12] <Kovensky> but the only railway in this entire region is Vale do Rio Doce's CarajÃ¡s road, which brings iron from the carajÃ¡s mine to the port in my city [17:25:43] <Kovensky> the only reason it transports passengers is because there's a law that mandates that private railroads must transport at least a certain amount of passengers [17:25:53] <BBB> Honoome, might be true, never tried :) [17:26:11] <Dark_Shikari> mru: videolan git server was broke [17:26:32] <Kovensky> the 1st class has AC, somewhat comfy seats and a tv passing boring documentaries [17:26:36] <Honoome> BBB: last I checked, FFmpeg failed at -O0 because of similar constructs in the initialisation of codecs [17:26:36] <Kovensky> 3rd class doesn't even have seats [17:27:03] <mru> Kovensky: in sweden 3rd class doesn't even have trains [17:27:11] <Kovensky> mru: lol [17:27:11] <kshishkov> same here [17:27:24] <kierank> why is there a contest to see who's country is the crappiest? [17:27:25] <Kovensky> well '3rd class' because there's no 2nd class [17:27:35] <kshishkov> looks like we have only 64th, 63th and 62th classes [17:27:41] <Kovensky> we only count '1st class' and '3rd class' (don't ask me where the 2 has gone to) [17:28:08] <Kovensky> kierank: dunno [17:28:15] <Kovensky> kierank: though our contries ARE crappy :P [17:28:22] <mru> kierank: http://www.youtube.com/watch?v=Xe1a1wHxTyo [17:28:31] <Kovensky> well, not mru's [17:28:44] <Kovensky> since both me and kshishkov want to escape to there [17:28:44] <kshishkov> the only place where we have "1st" and "2nd" classes are "expresses" to capital. 1st class is actually much worse [17:29:01] <kshishkov> Kovensky: mru lives in GB [17:29:28] <kierank> mru: yes, I know ;) [17:29:51] <BBB> Honoome, syntax checking, including code references, come before DCE [17:29:56] <BBB> so I'd expect it to warn about that [17:29:58] <Kovensky> kshishkov: o rly [17:30:01] * Honoome would love to escape to GB [17:30:04] <BBB> anyway [17:30:09] <Kovensky> kshishkov: I thought he lived in .se [17:30:10] <Honoome> BBB: note undefined and not undeclared :) [17:30:27] <Honoome> BBB: symbol definition is resolved at link time, not compile time [17:31:39] <Kovensky> kshishkov: http://www.mangafox.com/manga/mudazumo_naki_kaikaku/v02/c011/22.html [17:33:31] <kshishkov> Kovensky: quite predictable. For the second candidate to appear in manga you need Photoshop from another 20 years in future [17:33:46] <Kovensky> lol [17:34:07] <Kovensky> kshishkov: read a few pages [17:35:53] <kshishkov> Kovensky: I think of her as of female version of Hugo Chavez, dunno if you heard about that guy [17:37:16] <Kovensky> oh yes, a lot [17:37:27] <Kovensky> lolvenezuela [17:37:35] <Kovensky> kshishkov: did you see page 24? [17:37:51] <kshishkov> yes [17:38:28] <Kovensky> heh [17:38:32] <CIA-34> ffmpeg: cehoyos * r21837 /trunk/libavcodec/ivi_common.h: [17:38:32] <CIA-34> ffmpeg: Remove outdated comment. [17:38:32] <CIA-34> ffmpeg: Patch by Maxim, max_pole gmx de [17:38:46] <Kovensky> I started reading that manga a few days ago; it's pretty awesome [17:39:12] <Kovensky> will get an OVA later this year [17:39:43] <astrange> i always thought she looked like saber [17:41:10] * Kovensky often gets pretty lost on the mahjong sections [17:41:21] <Kovensky> I have studied a bit of mahjong but I don't get the riichi rules at all [17:41:54] * kshishkov used it to play solitaires long before he got computer [17:42:00] <Dark_Shikari> Kovensky: [17:42:03] <Dark_Shikari> 1) watch Akagi [17:42:07] <Dark_Shikari> 2) play Touhou Mahjong [17:42:08] <Dark_Shikari> 3) ??? [17:42:11] <Dark_Shikari> 4) Play on Tenhou! [17:42:34] <Kovensky> Dark_Shikari: lol [17:42:41] <Kovensky> Dark_Shikari: if you don't already, read that manga :D [17:42:46] <Dark_Shikari> touhou mahjong is awesome though [17:43:07] <Dark_Shikari> surprisingly good music. [17:57:16] * BBB thinks dark_shikari should spend more time optimizing ffmpeg's h264 decoder [17:59:00] <BBB> Dark_Shikari, would you optimize ff's h264 decoder for money? (and how much?) [18:03:31] <j-b> BBB: hello :) [18:16:35] <kshishkov> j-b: BBB - ping timeout [18:23:44] <BBB> I'm still here [18:23:46] <BBB> hi j-b :) [18:23:58] <BBB> I think jason is timeout'ing [18:24:10] <iive> no, he is still counting. [19:01:20] <Compn> i think its more that ass samples are buired within 400mb mkv files [19:01:38] <Compn> errrr [19:02:41] <kshishkov> huh? ass buried in itself? [19:02:50] <av500> ass deep [19:03:57] * kshishkov has another synonym for 'arse' - Ukraine [19:05:43] <elenril> fun fact: mplayer -demuxer lavf doesn't work with ass [19:06:15] <Compn> i remember some ffmpeg devs didnt like ass or the way it was stored [19:06:15] <kshishkov> yes, FFmpeg is not good with subtitles (yet) [19:06:22] <Compn> i think theres a flame about ass in -devel [19:06:28] <Kovensky> Compn: aurel [19:06:32] <elenril> yes, aurel wanted his own format [19:06:39] <elenril> which nobody else likes/uses [19:06:47] * Compn wont point any fingers in a logged chat ;p [19:06:47] <Kovensky> everybody called him on it but michael [19:06:57] <Kovensky> michael just told him to do wtf he wanted to since he was the maintainer [19:07:14] <elenril> btw anyone wants to apply a few patches for me? [19:07:15] <Kovensky> Compn: :P [19:08:15] <Kovensky> http://blogs.msdn.com/oldnewthing/archive/2010/02/15/9963387.aspx#9963721 [19:09:39] <elenril> hmm, using subversion to overthrow goverment... [19:10:03] <elenril> maybe this is the reason ffmpeg still hasn't switched to git [19:10:44] <Kovensky> are there even merikan devs, other than loren and dark? [19:11:04] <Kovensky> or compn [19:11:14] <Kovensky> [[AndZoidberg Compn]] [19:11:49] <kshishkov> Mike [19:11:58] <Compn> a few of us around , surely [19:12:00] <elenril> Kovensky: http://tvtropes.org/pmwiki/pmwiki.php/Main/TvTropesWillRuinYourVocabulary [19:12:10] <kshishkov> Ronald Bultje [19:12:11] <Kovensky> elenril: inorite [19:13:02] <kshishkov> Justin "flac" Ruggles [19:14:10] <Kovensky> <@Watarase_Jun> http://saber.kawaii-shoujo.net/~jun-chan/MSDOS6.22.rar [19:14:10] <Kovensky> <@Watarase_Jun> for whoever wants it [19:14:17] * elenril wonders if kshishkov is grepping some secret KGB db [19:14:26] <Kovensky> < twnqx> -rw-r--r-- 1 charlie users 123148 1996-01-14 09:46 WIN101-1.ZIP [19:14:26] <Kovensky> < twnqx> -rw-r--r-- 1 charlie users 181434 1996-01-14 09:46 WIN101-2.ZIP [19:14:26] <Kovensky> < twnqx> -rw-r--r-- 1 charlie users 156209 1996-01-14 09:47 WIN101-3.ZIP [19:14:26] <Kovensky> < twnqx> -rw-r--r-- 1 charlie users 168145 1996-01-14 09:47 WIN101-4.ZIP [19:14:27] <Kovensky> < twnqx> -rw-r--r-- 1 charlie users 101806 1996-01-14 09:48 WIN101-5.ZIP [19:14:29] <Kovensky> < twnqx> :> [19:14:32] <Kovensky> lol [19:14:43] * twnqx slaps Kovensky [19:14:55] <twnqx> ZIS CHANNEL IS BUGGED [19:15:01] <kshishkov> elenril: nope, just memory. I'd like to keep blackmailing DB on others [19:15:03] <Compn> get your warez out of here [19:15:20] <twnqx> Compn: make ffmpeg work on that. [19:15:26] <Kovensky> twnqx: indeed [19:15:36] <Kovensky> just found it somehow appropriate since we were discussing weird OSes earlier today [19:15:40] <Kovensky> lol [19:15:43] <Compn> sherpya has built mplayer on some kind of extended dos [19:15:48] <twnqx> cool [19:15:51] <Compn> and someone runs ffmpeg on dos fate [19:15:55] <twnqx> likely freedos, though [19:16:09] <Compn> check fate page for dos ffmpeg status ;p [19:16:40] <Dark_Shikari> BBB: hmm. maybe put out a $1000 per % bounty for speedups (with some particular test sample used for testing) [19:17:17] <Compn> someone should enter michael's h264 speedups into roundup [19:17:21] <Compn> and add whos working on what [19:17:33] <Compn> i mean, the suggested speedups [19:18:50] <Kovensky> Dark_Shikari: $_$ [19:19:18] <Dark_Shikari> that means it'll only cost $50k to be as fast as coreavc. [19:19:33] <Dark_Shikari> oh, and like a $20k bounty for multithreading [19:19:52] <twnqx> >_> [19:20:08] <Honoome> Dark_Shikari: and penalties if somebody get the speed down? :P [19:20:15] <elenril> lol [19:20:21] <Dark_Shikari> lol [19:20:24] <Dark_Shikari> awesome [19:20:24] <Kovensky> â¬_â¬ [19:21:03] <kshishkov> in your case it's Kr_Kr or something [19:21:12] <twnqx> more like [19:21:14] <twnqx> 0_0 [19:21:15] <kshishkov> (or Cr) [19:21:32] <mru> Â£_Â£ [19:21:39] <CIA-34> ffmpeg: michael * r21838 /trunk/libavcodec/h264_cabac.c: [19:21:39] <CIA-34> ffmpeg: Merge decode_cabac_mb_type_b() into calling code. [19:21:39] <CIA-34> ffmpeg: This avoids a conditional branch and is about 3 cpu cyclues faster. [19:21:46] <twnqx> lol [19:21:48] <Honoome> I wonderâŠ if it's M$, should we have Adobâ¬ then? :P [19:21:53] <twnqx> speaking of h264 speedups :D [19:22:07] <elenril> so how much money was that commit worth [19:22:09] <mru> and GoogÂ£e [19:22:16] <Honoome> lol [19:22:32] <Kovensky> kshishkov: â¢_â¢ ? [19:22:46] <Kovensky> kshishkov: that stopped being used in the 60s [19:22:50] <Kovensky> current currency is R$ [19:23:02] <CIA-34> ffmpeg: michael * r21839 /trunk/libavcodec/h264_cabac.c: [19:23:02] <CIA-34> ffmpeg: Simplify decode_cabac_mb_intra4x4_pred_mode(). [19:23:02] <CIA-34> ffmpeg: same speed [19:23:03] <Kovensky> which started being used in the 90s [19:23:11] <kshishkov> el dollaro real? [19:23:21] <Kovensky> Real / Reais [19:23:22] <kierank> any mxf experts around? [19:23:35] <Kovensky> http://pt.wikipedia.org/wiki/Cruzeiro_real <-- lol, this was used for less than a year [19:24:04] <kshishkov> Kovensky: I haven't heard even of Cruzado [19:24:15] <Kovensky> lol [19:24:33] <Kovensky> brazil used like o9k currencies between the 40s and the 90s [19:25:42] <astrange> http://github.com/astrange/ffmpeg/commit/cc9a11d728aa0e8a0dd0ee8d34793c4f17… i think this will be 2-3% faster if rewritten to not be incredibly ugly [19:26:06] <astrange> i need to stop rebasing that branch, i had to cherry-pick that commit out of the detached gt objects [19:26:10] <astrange> i [19:26:12] <kshishkov> so now it's 6% faster? [19:26:23] <Kovensky> kshishkov: perharps even more weirdly, my keyboard has a â¢ key [19:26:45] <Kovensky> kshishkov: apparently they thought it was more useful for you to have a key for typing a 40-years-old outdated currency than a key for typing a slash or question mark [19:26:53] <Kovensky> I need to use altgr to type those if I use br-abnt2 [19:27:01] <Kovensky> thankfully I use US layout [19:27:03] <kshishkov> altbr key [19:27:14] <Dark_Shikari> astrange: oh wow, that messy patch [19:27:20] <Dark_Shikari> it doesn't help on normal builds that aren't cpu-specific though :/. [19:27:44] <astrange> well, most arches will have an equivalent, but x86-32 generic isn't one of them unfortunately [19:28:10] <Dark_Shikari> easy, default to i686 when on x86-32 ;) [19:28:14] <Dark_Shikari> like we do for x264 [19:28:16] <astrange> it could use AV_COPY128, but i wrote that using explicit asm to avoid having to benchmark lots of compilers [19:28:20] <astrange> so it always reloads the input [19:28:23] * Kovensky makes uau a pull request in astrange's stead [19:28:35] <mru> looks like fill_rectangle needs to be broken out into lavc/$arc/foo.h [19:28:42] <mru> arch [19:28:44] <astrange> yes, that'd be the first step [19:29:03] <kshishkov> mru: lavu/intrectwrite.h :P [19:29:51] <Kovensky> talking about intwhateverwrite [19:30:00] <Kovensky> there's a public header that includes intreadwrite.h [19:30:11] <mru> there's an ongoing bikeshed about that [19:30:19] <Dark_Shikari> lol [19:30:20] <Dark_Shikari> indeed [19:30:21] <mru> expect it to be fixed in 6-8 months [19:30:25] <Kovensky> lol [19:30:39] <Kovensky> meanwhile, every time I compile ffms2 I get warnings about a deprecated function :( [19:31:08] <Kovensky> it was moved to libavutil but the avutil header that defined it includes intreadwrite.h [19:31:12] <Dark_Shikari> mru: and by "fixed" we mean "solidified" not "solved" [19:31:20] <Kovensky> lol [19:31:28] <mru> paint dried in can [20:00:22] <BBB> Dark_Shikari, holy shit, $1000 per %? [20:00:38] <BBB> buying a license for avc is cheaper then :-p [20:00:40] <Kovensky> BBB: Â¥_Â¥ [20:01:10] <Kovensky> \_\ <-- I swear those are two yen signs [20:01:19] <Dark_Shikari> BBB: making something as good as coreavc isn't worth $50k? =p [20:01:21] <BBB> I saw then yens in (1) [20:01:36] <mru> Kovensky: funny thing is, that sign is not used in japanese [20:01:36] <BBB> Dark_Shikari, maybe... I don't have that much money though [20:02:03] <BBB> Dark_Shikari, can't you move to alabama? I hear cost-of-living is much lower there [20:02:07] <Dark_Shikari> lol [20:02:22] <Dark_Shikari> I mean, if I'm not going to get paid at least $80-100 an hour, it's not worth working for money [20:02:29] <BBB> true [20:02:37] <BBB> what if we did it grant-wise? [20:02:52] <BBB> if I paid $1000 in advance, how much more would you be motivated to work on it than now? [20:03:00] <BBB> and what's the current level? [20:03:14] <Dark_Shikari> advance or after doesn't matter [20:03:15] <kierank> we should get EU grants [20:03:21] <Dark_Shikari> and also, you overestimate how much I could go do :/ [20:03:40] <Kovensky> Dark_Shikari: you could what? [20:03:51] <BBB> well, you complain most, I'm hoping that means that you have direct means of improving it [20:04:03] <BBB> Dark_Shikari, also, you are into x264, so you have some pre-existing knowledge [20:04:06] <av500> Dark_Shikari: couldnt u use like char for loop vars to speed it up :) [20:04:29] <BBB> like, if you gave me 1 week, I would probbaly be able to figure out the main 10 functions in decoding of the first packet + extradata [20:04:32] <Kovensky> wouldn't that make it slower, or at best not change speed at all? [20:04:37] <BBB> that would be 1 week of work, with no change in code at all [20:05:18] <j-b> it shouldn't be 1000$ per %, but 1000$ per 5%, then per 4%, then 3%, then 2% etc... since the more it goes, the more difficult it would be, no? [20:05:57] <Honoome> j-b: depends if you change the reference point or not [20:06:28] <j-b> indeed. [20:06:31] <j-b> lu_zero: ping [20:07:14] <Dark_Shikari> j-b: I was thinking compounded [20:07:20] <Dark_Shikari> e.g. 1% faster means 100fps -> 101fps [20:07:27] <Dark_Shikari> and 1% again means 101 -> 102.01fps [20:07:32] <Dark_Shikari> etc [20:07:32] <lu_zero> j-b: pong [20:07:51] <Honoome> lu_zero: I'll send you the bill as personal assistant, don't worry :P [20:08:53] <lu_zero> Honoome: I guess I'll bill the support calls as well [20:08:57] <j-b> lu_zero: sorry, do you still have this pthread/mutex patch for mozilla?? [20:09:03] <lu_zero> somewhere sure [20:09:05] <lu_zero> why? [20:09:15] <lu_zero> it got missed? [20:09:37] <j-b> I was in holiday :) [20:09:47] <lu_zero> ah [20:09:53] <Honoome> lu_zero: j-b was almost _here_ and didn't tell us >_< [20:10:04] <lu_zero> Honoome: venice I guess [20:10:12] <lu_zero> and you went there by train? [20:10:16] <j-b> nope [20:10:19] <j-b> Flew [20:10:29] <lu_zero> ah, then just next to diego =P [20:10:40] <lu_zero> I hope you had a good time [20:11:20] <j-b> well, yeah. It was a bit hard to not have Internet for a week though... [20:11:28] * j-b feels like a drug addict [20:11:32] <lu_zero> thehehe [20:11:51] * Honoome spent â¬50 to have internet in Bruxelles -- that's definitely a fix! :P [20:12:14] <Honoome> [given I left the phone connected since Friday night till we left, with Google Maps, it's not even a bad price, I'd say] [20:12:17] * Kovensky once had to spend 3 days without internet while at home [20:12:30] <Kovensky> it's a good way to watch anime though [20:12:32] <Kovensky> :D [20:12:35] <lu_zero> pff [20:12:41] <Honoome> Kovensky: yeah if you have them already downloaded ;_; [20:12:47] <Kovensky> Honoome: indeed ;_; [20:12:55] <lu_zero> j-b: I guess I'll have to redo it ^^' [20:13:17] <twnqx> that's why i'm always havona at least a TB unwatched! [20:13:17] <Honoome> lu_zero: which patch are we talking about? [20:13:19] <Kovensky> <Chii[AR]> MYSTATS: kovensky (uid: 285185) (10h old) - 155 anime, 1924 eps (1410 / 73.28% watched) and 2070 files in mylist (545 GB, 1.8% of AniDB, 1.3% watched, taking 23 days, 6 hours and 4 minutes of your life). [20:13:20] <j-b> Honoome: lu_zero: but it was for a good cause: Surprise holidays for Carneval in Venise for my g/f => 6 month of geeking without problem! [20:13:30] <twnqx> cute, kov, cute [20:13:42] <lu_zero> j-b: =) [20:14:01] <lu_zero> I fully approve the choice ^^ [20:14:22] <Honoome> j-b: for when I'll find a gf, you'll have to organise something else in Paris then ;) [20:14:23] * Kovensky has 36GB of unwatched anime on the craptop, 16GB elsewhere [20:14:34] <Honoome> (okay s/when/if/ :P) [20:14:52] <lu_zero> Honoome: work hard on it, she'll capitulate soon [20:15:13] <Honoome> lu_zero: yeah sure, I'll keep on tryingâŠ =_= [20:15:17] <j-b> Honoome: why do you think VDD were in Paris? :) [20:15:46] <KotH> Kovensky: i can top that [20:16:04] <Honoome> j-b: eh okay, but I couldn't use the excuse last december! :P make sure you do it again next december and that'd be fine ;) [20:16:10] <Kovensky> KotH: I'm not comparing sizes, just stating my situation =p [20:16:14] * lu_zero is pondering of having a FFconf in Torino sooner or later [20:16:26] <Kovensky> I used to have 200GB of unwatched stuff when I had a big HDD, but that's still much less than twnqx [20:16:31] <lu_zero> maybe september could be an useful time hmmm [20:17:23] <KotH> lu_zero: it looks like it'll be paris this time :) [20:18:57] <lu_zero> KotH: paris, when? [20:19:06] <KotH> lu_zero: ask j-b [20:19:07] <KotH> :) [20:19:13] * lu_zero should catch up with emails =_- [20:19:23] <KotH> this has not been announced yet [20:19:27] <lu_zero> today I spent most of my time in a looong meeting [20:19:33] <KotH> so, no way you can catch up on that :) [20:20:20] <lu_zero> ahh [20:20:22] <lu_zero> hmm [20:20:35] <mru> w/o faster-than-light broadband at least [20:20:53] <mru> fiber is so slow ;-) [20:21:27] <Honoome> mru: does BT offer that now? [20:21:44] <av500> FF fast fiber [20:21:48] <KotH> Honoome: dont believe mru [20:21:53] <Honoome> [note: offer, not provide] [20:21:53] <KotH> Honoome: he uses out of band communication [20:22:03] <kierank> [20:21] <Honoome> mru: does BT offer that now? --> not yet [20:22:16] <j-b> lu_zero: I believe that we will try to have VDD at the same time of the FFconf [20:22:43] <KotH> j-b: try? well, why not just do it? :) [20:22:55] <lu_zero> ah [20:23:10] <av500> ffconf in paris, i am all for it! [20:23:25] <Honoome> lu_zero: next time I'll try to board the plane at the Marco Polo though :P [20:23:29] <j-b> KotH: because I am not an omnipotent chief [20:23:34] <KotH> av500: btw: would your employer be a sponsor? :) [20:23:34] <mru> guys, it's FFcon [20:23:37] <KotH> j-b: who is? [20:23:41] <j-b> KotH: noone [20:23:48] <KotH> ^^' [20:23:52] <mru> ffconf is the replacement-to-be for autoconf [20:23:55] <av500> j-b: what do we need to get lacantine? [20:23:57] * Honoome hands j-b pointy hairs [20:23:58] <j-b> decisions are collegial [20:24:02] <Honoome> mru: oooh! I want that! :D [20:24:15] <KotH> j-b: well.. [20:24:36] <j-b> KotH: anyway, more seriously, I don't see anyone opposing the coupling from our part [20:24:40] <KotH> j-b: so you mean i have to bring chocolate for all vlc devels for them to do something in my favor? :) [20:24:44] <j-b> and if it is not in Paris, we will follow [20:24:53] <KotH> .o0(that'll be expensive) [20:24:58] * kierank votes south of france [20:25:06] <KotH> hmm.. [20:25:10] <lu_zero> KotH: I could help you a bit =P [20:25:14] <j-b> kierank: doable, at my place, if we are less than 20 [20:25:31] <KotH> j-b: is your place at the sea? [20:25:36] <j-b> no :'( [20:25:40] <KotH> doh! [20:25:47] <lu_zero> j-b: where are you? [20:25:54] <KotH> if south france, we need a beach! with girls and everything! ;) [20:26:11] <j-b> Paris, but my parents have a place near Orange. [20:26:39] <av500> j-b: would LaCantine be an option? they love like open source, no? [20:26:46] <lu_zero> ah [20:26:59] <j-b> av500: well, of course, like for this year, we would use LaCantine for a night [20:27:21] <av500> j-b: I alsmost feel like at home there now :) [20:27:33] <j-b> av500: :) [20:27:54] <j-b> KotH: if it is expensive, only the important devs will go, then. [20:28:00] <av500> and there are nice pubs close by.... [20:28:08] <KotH> j-b: there is always sponsoring :) [20:28:50] <j-b> KotH: well, this year, we didn't pay the hotel and LaCantine, this helped quite abit [20:29:22] <KotH> j-b: i talked with linuxhotel and they gave quite nice numbers [20:29:52] <KotH> j-b: 1keur for 20 people, all inclusive [20:29:57] <j-b> nice. [20:30:00] <Dark_Shikari> plane flights are more of an issue. [20:30:02] <av500> KotH: nice [20:30:13] <j-b> food is an issue too. [20:30:13] <av500> Dark_Shikari: there is always bug bounties :) [20:30:14] <Dark_Shikari> imagine the cost of a round trip flight from the US [20:30:14] <KotH> but they have only 20 beds... [20:30:27] <av500> j-b: Aldi ftw! [20:30:28] <KotH> another 20 can be accomodated using cheaper means, but that depends on the people [20:30:29] <j-b> KotH: how many ffmpeg folks are from the US ? [20:30:34] <lu_zero> Dark_Shikari: around 200e from time to time [20:30:45] <KotH> j-b: hmm... 5-6 i suppose [20:30:49] <lu_zero> (well depends on the coast) [20:30:52] <KotH> j-b: very few [20:30:55] <kierank> 200 euro flight! [20:31:01] <mru> lu_zero: east coast? west coast? [20:31:02] <peloverde> Dark_Shikari: I booked my FOSDEM flight fairly last minute and it was pretty cheap [20:31:06] <Dark_Shikari> 200 EUROS?! [20:31:06] <KotH> j-b: so far, i got only word from peloverde that he'd come [20:31:10] <lu_zero> east coast -> ita [20:31:10] <Dark_Shikari> isn't that cheaper than the fuel? [20:31:16] <j-b> KotH: ok [20:31:26] <Dark_Shikari> where did you find a flight for 200 euros? [20:31:28] <lu_zero> alitalia from time to time had such offers [20:31:38] <kierank> no wonder they're bust [20:31:39] <Dark_Shikari> of course we'd need very advance notice to get our passports in line [20:31:50] <lu_zero> kierank: the other way round [20:31:53] <peloverde> Dark_Shikari: get your passport now, it's worth having [20:31:56] <Dark_Shikari> I have one [20:31:59] <Dark_Shikari> I just don't have it _with_ me [20:32:00] <mru> I can usually find flights anywhere in europe for less than Â£200 [20:32:13] <Dark_Shikari> mru: cross atlantic costs more [20:32:16] <Dark_Shikari> also lol [20:32:18] <Dark_Shikari> we started at $ [20:32:19] <Dark_Shikari> then we went to euros [20:32:21] <Dark_Shikari> then pounds [20:32:29] <j-b> KotH: anyway, December in Paris was not the best idea we have had. [20:32:35] <lu_zero> eu is about 99e now [20:32:51] <j-b> KotH: and I guess that if we can do a VDD one day after/before the FFconf, that would be cool. [20:32:55] <lu_zero> right now [20:33:00] <Dark_Shikari> well at the rate things are going the euro will be worthless in a few months [20:33:01] <lu_zero> Milano - Chicagodâ¬ 418e [20:33:03] <Dark_Shikari> so we better buy tickets soon [20:33:25] <lu_zero> Milan - Boston is 417e [20:34:05] <KotH> j-b: ffcon is planned to be 2-3 days on a long weekend [20:34:10] <KotH> j-b: so that we have time [20:34:23] <KotH> j-b: what is the purpose of vdd? [20:34:29] <mru> BEER [20:34:37] <lu_zero> mru troll beer? [20:34:40] <lu_zero> theheh [20:34:40] <KotH> j-b: wouldnt it make sense to just merge both ffcon and vdd? [20:34:50] <mru> I think it would [20:35:01] <Dark_Shikari> I just did a bing travel search, the cheapest flight from LA area to Paris and back, June 20th-25th (random dates), is $1506 [20:35:12] <lu_zero> Dark_Shikari: ?? [20:35:16] <lu_zero> bing is broken [20:35:28] <kierank> that price sounds about right [20:35:30] <j-b> KotH: we just need to have a room for 1 day for VLC folks to take decisions about how we can improve porn searching in VLC [20:35:40] <KotH> j-b: ah... [20:36:12] <KotH> j-b: that'd be a 10min task if you'd had the right people from mplayer around to show you how it is done correctly ;-> [20:36:13] <j-b> and that can be at the same time as other discussions are around [20:36:21] <Dark_Shikari> lu_zero: what would you recommend? [20:36:31] <lu_zero> uhmmm [20:36:43] <lu_zero> seems that is the offer now [20:36:46] <mru> KotH: invite gabu? [20:36:49] * lu_zero is a bit puzzled [20:37:18] <KotH> mru: uh.. that'd be fun [20:37:30] <lu_zero> which is the dollar/eu exchange rate now? [20:37:37] <peloverde> CLE<->Paris 8/5 to 8/10 from $1315, my guess is that prices will drop then come back up. CLE to BRU cost me less than $800 [20:37:38] <KotH> mru: though, it might be a good idea to invite some people from the old team :) [20:37:46] <Dark_Shikari> 1.36 dollars to the euro [20:37:49] <KotH> mru: like arpi, .so, lgb... [20:38:12] <Dark_Shikari> I tried over a weekend and it's "only" $1394 [20:38:13] <av500> peloverde: BRU to Paris is cheap too :) [20:38:14] <Dark_Shikari> using british airways [20:38:35] <KotH> Dark_Shikari: try swiss, they are cheaper :) [20:38:47] <KotH> if not by price, then by service [20:39:08] <lu_zero> west coast seems about a 2x the price [20:39:25] <lu_zero> alitalia.it has an USA website I'm watching [20:39:30] <Dark_Shikari> swiss was more [20:39:34] * mru likes flying with virgin atlantic [20:39:38] <Dark_Shikari> lu_zero: I can get very cheap cross country flights if necessary [20:39:45] <Dark_Shikari> if they're far enough in advance [20:39:47] <av500> Dark_Shikari: for when did you search? [20:39:51] <KotH> j-b: btw: the alternative would be to make ffcon/vdd in .jp :) [20:39:52] <av500> I find 737â¬ [20:39:56] <Dark_Shikari> av500: june 18-21 [20:40:00] <Dark_Shikari> as a random example of a cross-weekend set of dates [20:40:05] <Dark_Shikari> KotH: lol [20:40:11] <kierank> british airways will lose your bags [20:40:13] <kierank> fact [20:40:25] <mru> av500: 737 is a bit small for transatlantic flights [20:40:26] <j-b> KotH: would be great. [20:40:31] <mru> 747 or 777 is much better [20:40:38] <av500> Dark_Shikari: june cost more, I get 1052 [20:40:42] <av500> with UA [20:40:46] <Dark_Shikari> lol, to tokyo is even more [20:40:48] <Dark_Shikari> or wait [20:40:49] <Dark_Shikari> no it isn't [20:40:52] <Dark_Shikari> $887 to tokyo, roundtrip [20:41:01] <Dark_Shikari> Guess it makes sense, given I'm on the west coast. [20:41:02] <lu_zero> $ 628 ny-rome [20:41:04] <KotH> j-b: if we want that, i could organize places to stay [20:41:07] * mru avoids flying with us-based airlines [20:41:23] <Dark_Shikari> I like united because I have a free premiere membership [20:41:27] <av500> mru: I guess it is a codeshare with 15 different airlines.... [20:41:27] <KotH> j-b: but then i'd need to start asking the right people soon [20:41:29] <j-b> KotH: Dubai has lots of hotels too. [20:41:31] <Dark_Shikari> and my mother has so many free upgrades that she just gives them to me [20:41:39] <Dark_Shikari> because she doesn't fly enough inside the country to use them [20:41:40] <KotH> j-b: who cares about arabs? [20:41:41] <KotH> ;) [20:41:48] <Dark_Shikari> so I get first class for nothing [20:41:53] <mru> JIHAD [20:41:58] <av500> lol [20:42:11] <KotH> mru: when did you join gods army? ;) [20:42:24] <lu_zero> hmm [20:42:25] <av500> KotH: I try to image how he looks like when he yells it.... [20:42:38] <lu_zero> vdd+ffcon in tokyo sounds interesting [20:42:46] <mru> not realisting imo [20:42:50] <KotH> lu_zero: nah.. tokyo is too expensive [20:42:57] <lu_zero> better kyoto =P [20:42:59] <av500> j-b will have an issue to get his posse over there, no? [20:42:59] <Dark_Shikari> lol [20:43:01] <KotH> lu_zero: ok, not as expenisve as zürich, but still [20:43:05] <lu_zero> pff [20:43:11] <Dark_Shikari> we could go into germany, then I might have a chance of understanding people [20:43:14] <lu_zero> tokyo about lodging? [20:43:19] <av500> Dark_Shikari: I am all for it [20:43:30] <KotH> lu_zero: there are a few nice places in shikoku, that are quite cheap [20:43:30] <lu_zero> we could takeover a internet/book cafe [20:43:34] <mru> I think europe is the only realistic option [20:43:36] <av500> thats KotHs linuxhotel [20:43:49] <kierank> that linuxhotel looks quite nice [20:43:54] <av500> old europe ftw! [20:44:00] <lu_zero> thehe [20:44:01] <kierank> we should have the conference at cern [20:44:02] <Dark_Shikari> lol wait what [20:44:06] <Dark_Shikari> a flight march 18-21 [20:44:09] <Dark_Shikari> is cheaper than june 18-21 [20:44:12] <av500> yes [20:44:16] <Dark_Shikari> what the fuck is with that [20:44:18] * lu_zero loves Geneve [20:44:20] <av500> june is holidays, no? [20:44:31] <KotH> kierank: difficult to arange [20:44:35] <lu_zero> Dark_Shikari: depends on their statistics [20:44:37] <av500> Dark_Shikari: I got 737â¬ for a random May weekend [20:44:57] <twnqx> you know Dark_Shikari... a flight riyadh -> frankfurt -> riyadh with lufthansa is like half the cost of frankfurt -> riyadh -> frankfurt... [20:45:05] <twnqx> don't ask me for the reasons [20:45:06] <Dark_Shikari> twnqx: lol [20:45:16] <BBB> what is vdd? [20:45:19] <BBB> videolan dev days? [20:45:20] <kierank> welcome to the world of international airfare pricing [20:45:28] <twnqx> it's like that for the past 5 years [20:45:37] <mru> BBB: Vss and Vdd, didn't you take electronics in school? [20:45:41] <Dark_Shikari> kierank: it's bad enough in the US [20:45:46] <Dark_Shikari> so, here's my insane airline story [20:46:07] <Dark_Shikari> 1) $1600+ for a direct flight across the country, economy class [20:46:16] <kierank> at least in eu there are very strong consumer protection laws when the airlines bump you off [20:46:17] <iive> Dark_Shikari: i've heard about some ticket system, where you can get extremely cheap price for air traver, something around 30-40euro, for flight in europe. the trick is that you don't have exact date for travel, and they stuff you in when there are unused seats. [20:46:23] <Dark_Shikari> iive: ryanair? [20:46:29] <Dark_Shikari> but there is one good story I had [20:46:31] <kierank> he means standby [20:46:34] <Dark_Shikari> due to the huge snow storm like 2 months ago [20:46:41] <Dark_Shikari> my flight was cancelled and I had to stay overnight [20:46:46] <Dark_Shikari> then, the next day, when I got on my replacement flight [20:46:48] <Dark_Shikari> they had swapped the planes [20:46:54] <Dark_Shikari> an international 777 was doing the domestic flights [20:46:56] <BBB> mru: I sucked at most things non-math/bio [20:46:59] <Dark_Shikari> and as it happened, I had a free upgrade for that flight [20:47:07] <Dark_Shikari> but the original flight was only economy/first [20:47:09] <BBB> bleh $1200 for a weekend munich [20:47:10] <BBB> darn [20:47:14] <BBB> too expensive [20:47:14] <Dark_Shikari> and upgrades are supposed to be one +class [20:47:19] <Dark_Shikari> But they made a mistake [20:47:26] <Dark_Shikari> and I got a first-class seat on an international 777, for free [20:47:44] <Dark_Shikari> I don't think I'll ever end up in one of those for the rest of my life [20:48:12] <Dark_Shikari> You know, the kind with the chairs that recline all the way back [20:48:26] <Dark_Shikari> apparently one of those on an international flight is $19000 [20:48:34] <BBB> even my sister had those [20:48:37] <kierank> yes, something ludicrous like that [20:48:44] <BBB> I flew for 6 years, 10 times/year, and never had an upgrade :( [20:48:57] <mru> likewise [20:49:00] <Dark_Shikari> BBB: my mother has 100K club (100,000 miles per year) with united [20:49:02] * BBB decides he hates flying [20:49:04] <j-b> KotH: sorry to be stupid, but why not during the OpenVideoConference? [20:49:05] <Dark_Shikari> they give her like 8 free domestic upgrades per year [20:49:07] <mru> you need to fly 10 times/month to get that [20:49:07] <Dark_Shikari> plus various other things [20:49:12] <Dark_Shikari> and a ton of systemwide upgrades [20:49:12] <Compn> Dark_Shikari : oh , thats a hell of a plane [20:49:16] <BBB> mru: so I heard [20:49:17] <Dark_Shikari> mru: 4 times a year is enough [20:49:20] <BBB> mru: I'm not that rich :) [20:49:26] <Dark_Shikari> as long as it's east coast of the US -> china and back each time ;) [20:49:30] <peloverde> I got a free business upgrade on a 777 from Heathrow to BRU [20:49:31] <Compn> Dark_Shikari : did it have tvs in every seat or is that still a damn myth they put on every air travel advertisement? [20:49:45] <kierank> economy has that too [20:49:47] <Dark_Shikari> Compn: they have that for the international planes [20:49:50] <mru> 777 from LHR to BRU? [20:49:53] <mru> wtf? [20:49:56] <kierank> most of them run linux as well [20:50:02] * Compn has flown internationally, still on 727/737 tho, no tv, no completely flat chairs etc [20:50:14] * Kovensky gets mighty confused when people use three-letter code for airports [20:50:17] * Kovensky is used to ICAO notation [20:50:26] <Compn> well its kind of easy [20:50:26] <mru> every intercontinental flight I've been on in recent years had seatback screens [20:50:29] <Kovensky> <-- flight sim fag [20:50:29] <Compn> bru = brussles ? [20:50:31] <Compn> ;p [20:50:50] <Compn> lhr = london heathrow ? ;p [20:51:04] <Compn> mru : must be a european thing [20:51:24] <kierank> not really [20:51:26] <Compn> what am i jealous of anyhow, nothing on tv to be sure [20:51:32] <mru> I fly intercontinental only with european or asian airlines [20:51:56] <mru> any decent airline has ~50 films or so to choose from [20:52:14] <Compn> in usa flights, they try to terrorize people with julia roberts movies [20:52:23] <Compn> i was on one flight ... three julia roberts movies in a row. [20:52:30] <mru> you don't get to choose? [20:52:37] <Compn> one big screen at the front [20:52:38] <KotH> j-b: the idea was to have something seperate from the usual conferences, so that the developers have time to talk with each other, instead of other people [20:52:39] <Compn> projector [20:52:47] <mru> that's so 1980s [20:52:57] <Compn> KotH : i think people get confused because you call it a conference, call it a meetup [20:53:19] <KotH> ffmeet then? [20:53:22] <kierank> google could host us [20:53:23] <KotH> or ffmeat? ;) [20:54:17] <peloverde> conference sounds more formal, I like it better [20:54:30] <Compn> but then you get into arguing about booths [20:54:32] * kierank prefers pissup [20:54:41] <Compn> there wont be any booths! [20:54:41] <av500> Compn: like a booth per codec? [20:54:43] <Compn> heh [20:54:54] <av500> flamebooth [20:55:01] <mru> what, no booths? can we at least keep the booth babes? [20:55:20] * Compn daydreams of showing up to ffmpeg booth and trolling about including ffmpeg in some proprietary software without giving credit or source [20:55:23] <av500> yv: ? [20:56:08] <mru> av500: did you learn about plural forms in school? [20:56:22] <av500> mru: I can try to recruit the former Archos booth babe... [20:56:27] <av500> prularl? [21:03:28] <iive> Compn: julia roberts... I wonder if that have some connection with that man whom underwear ignited. [21:15:36] <CIA-34> ffmpeg: cehoyos * r21840 /trunk/libavformat/asfdec.c: [21:15:36] <CIA-34> ffmpeg: workaround for broken files created by previous versions of asfenc. [21:15:36] <CIA-34> ffmpeg: Patch by Anton Khirnov, wyskas gmail [21:20:32] <CIA-34> ffmpeg: cehoyos * r21841 /trunk/libavformat/asfenc.c: [21:20:32] <CIA-34> ffmpeg: Strings in extended content header are UTF16, [21:20:32] <CIA-34> ffmpeg: so terminating NULLs are 2 bytes long, not 1. [21:20:32] <CIA-34> ffmpeg: Patch by Anton Khirnov, wyskas gmail [21:42:58] <av500> j-b: #meego was so much fun today... [21:43:14] <j-b> av500: trolling? :D [21:43:19] <av500> just a little [21:43:28] <j-b> av500: so, it is going to be Qt based? .deb or .rpms? [21:43:35] <av500> but no need, they all run around like headless chickens by themselves.... [21:43:40] <av500> qt, rpm [21:43:47] <av500> instread of gtk, debian and .deb [21:43:59] <av500> so, world ends, epxect cheap N900s soon [21:44:24] <j-b> based on what then? Fedora? [21:44:41] <av500> moblin [21:44:45] <av500> based on mobin [21:44:48] <av500> based on moblin [21:44:48] <j-b> ok [21:44:56] <j-b> ok, I'll live with it [21:52:07] <BBB> everybody that cares already has an android phone [21:52:14] <BBB> everybody else already has an iphone [21:52:19] <BBB> you are TOOO FUCKING LATE [21:52:26] <BBB> ^d^d [21:52:57] <av500> BBB: join in :) [21:53:03] <BBB> no thanks [21:53:08] <BBB> my time is more precious than that :) [21:53:21] <BBB> let them waste money [21:53:31] <av500> yes [21:53:55] <BBB> also, check the new york subway around rush hours [21:54:14] <BBB> the ads are crazy [21:54:25] <BBB> for samsung SMARTphones, for LG SMARTphones [21:54:30] <BBB> there's only two not being advertised [21:54:37] <BBB> iphone and nexus [21:54:46] <av500> no use to advert iphone in nyc I guess :) [21:54:49] <BBB> and, conveniently, that's the only ones you see in people's hands [21:54:58] <BBB> actually, nexus not that much [21:55:01] * av500 should move to ny... [21:55:01] <BBB> but I've seen 1 or 2 [21:55:17] <BBB> the kindle and barnes and nobles ebook reader are quite popular [21:55:25] <BBB> but 95% of devices are iphones or blackberry [21:55:51] <j-b> BBB: agreed. [21:55:52] <BBB> but blackberry is losing quickly, it used to be just blackberry :) [21:56:57] <j-b> av500: anyway, it will be fun to watch [21:57:05] <av500> yes [21:57:16] <av500> I watch it all day, cant take much more [21:57:21] <j-b> av500: I just hope we don't loose the OpenMax IL layer [21:57:32] <av500> j-b: i dont think so [21:57:43] <av500> I guess the guts will mostly stay the same [21:57:56] <j-b> I'll pray for it [21:58:03] <j-b> but I won't cry over Moblin [21:58:28] <av500> I stopped following moblin changes of ui, distro etc... [21:58:53] <j-b> but, that is a bad day for GTK [21:59:08] <av500> and is that bad? [21:59:17] <j-b> no. [21:59:23] <j-b> :) [21:59:26] <av500> :) [21:59:45] <j-b> but loosing Nokia, Google and Intel support in a few month is quite bad [22:00:16] <av500> dragging your heels for years doing nothing is deserves that [22:07:56] <CIA-34> ffmpeg: michael * r21842 /trunk/libavcodec/ (h264.h h264_cavlc.c h264_cabac.c): [22:07:56] <CIA-34> ffmpeg: Split setting neighboring MBs from fill_decode_caches() [22:07:56] <CIA-34> ffmpeg: no speed change. [22:10:39] <J_Darnley> Um... [22:10:54] <J_Darnley> I think there might me a missing dependency for wmavoice [22:12:00] <J_Darnley> When building with lots of stuff disabled, this happens: [22:12:03] <J_Darnley> libavcodec/wmavoice.c:971: undefined reference to `ff_acelp_lspd2lpc' [22:17:09] <astrange> missing lsp.o dep [22:17:22] <astrange> you could add it to the makefile and send a patch [22:17:27] <TheFluff> 20:30:36 < Kovensky> meanwhile, every time I compile ffms2 I get warnings about a deprecated function :( <-- which one, the av_get_pixfmtwhatever one? [22:17:27] <astrange> too bad those deps aren't transitive [22:17:41] <TheFluff> what is it supposed to have been replaced with? [22:18:28] <J_Darnley> So be it [22:36:12] <J_Darnley> Is there also something in configure which controld dependencies? [22:37:38] <J_Darnley> *controls [22:40:37] <astrange> yes, for things that can be --disabled [22:44:36] <mru> sounds like wmavoice_decoder_select="lsp" in configure is needed [22:45:04] <mru> hmm no [22:45:07] <mru> that's lpc [22:45:15] <mru> damn, this stuff needs cleaning up [22:46:35] <J_Darnley> Should I still send an email with what I did and the first change? [22:49:39] <BBB> I can add stuff that's missing [22:49:41] <BBB> give me a second [22:49:52] <mru> andoma: http://www.youtube.com/watch?v=r9X3K2dRMdM [22:50:07] <BBB> it depends on lzo and lsp [22:50:13] <BBB> lzo is in libavutil [22:50:18] <BBB> is that a dependency or is that always on? [22:50:51] <mru> I think it's always on [22:51:30] <BBB> ok [22:51:35] <BBB> then we only need lsp.c in Makefile [22:52:02] <BBB> anyone can commit that, so I don't have to change trees or quilt remove add all my patches [22:52:09] * BBB still grumbles at his failed git experiment [23:05:02] <CIA-34> ffmpeg: michael * r21843 /trunk/libavcodec/h264_cabac.c: [23:05:02] <CIA-34> ffmpeg: Drop compute_mb_neighbors() and move fill_decode_neighbors() up to take its [23:05:02] <CIA-34> ffmpeg: role. [23:05:02] <CIA-34> ffmpeg: Should be faster as this is a strict code removial. [23:10:37] <Dark_Shikari> Direct temporal skiped MBs dont need fill_decode_caches() at all so dont call it [23:10:40] <Dark_Shikari> for them. [23:10:42] <Dark_Shikari> wow, I didn't even realize that [23:10:47] <Dark_Shikari> they really require _no_ neighbor information [23:15:32] <mru> "skiped", you talk like michael now? [23:15:43] <Dark_Shikari> that was a copy paste [23:15:45] <Dark_Shikari> from the commit message [23:16:13] <mru> he did say other's english had got worse... [23:16:46] <Dark_Shikari> no, his is still just bad [23:19:25] <Honoome> mru: you definitely are picking up the British way ;) [23:28:29] <mt> Are atrac3 streams in wav always stereo, or could they be joint-stereo ? [23:39:07] <Yuvi> astrange: ideally it should allocate a blank frame instead of requiring a keyframe to be seen, especially since it looks like they're hacking in PIR to theora [23:39:54] <Yuvi> but I haven't really looked at copy buffers / the mpegvideo buffer model [23:42:13] <Dark_Shikari> lol they're adding PIR to theora? [23:42:23] <Dark_Shikari> and they don't even have proper VBV management yet? [23:42:36] <Dark_Shikari> or threading [23:43:07] <mru> pir? [23:44:05] <Dark_Shikari> periodic intra refresh [23:44:08] <Dark_Shikari> aka keyframeless [23:44:12] <mru> ah [23:44:47] <Yuvi> best part is that it breaks nearly seeking algorithms in ogg [23:44:55] <Yuvi> *nearly all [23:45:03] <Dark_Shikari> I wonder if they'll enable it by default [23:45:07] <Dark_Shikari> since they insist on having no options whatsoever [23:45:16] <Dark_Shikari> which makes it practically impossible to construct any real streaming system [23:45:19] <mru> self-destruct by default, I like it [23:49:55] <iive> no options?

1 0

IRC log for 2010-02-14
by irc＠mansr.com 15 Feb '10

15 Feb '10

[00:57:37] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/ ran the analyzer again [00:57:45] <astrange> it's as noisy as ever though [00:58:03] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/report-I1qORD.html#EndPath but this one looks like a real problem... [01:01:18] <j-b_Venice> BBB? [01:08:17] <Honoome> j-b: are you in venice? o_O [01:09:14] <j-b> Honoome: I just came back from Carneval! [01:09:24] <Honoome> j-b: and you don't warn! >_< [01:09:44] <j-b> Honoome: you are in Venice? [01:09:55] <Honoome> I live in the mainland of Venice ;) [01:10:02] <j-b> OMG? Fuck [01:10:13] <j-b> I had no idea they were geeks in Venice [01:10:28] <j-b> Honoome: be', ho fatto la setimana sanza computer [01:10:47] <j-b> una cosa che non faccio mai, in tempo normale [01:10:54] <j-b> ma lì, ero stanchissimo [01:11:14] <Honoome> j-b: buona idea ;) -- but yeah there are very few devs around here :P [01:11:36] <Honoome> I think I have the media-related exclusive, even with me barely being involved nowadays :P [01:11:59] <j-b> Honoome: so, next FOSS-multimedia meeting will be in Venice? [01:12:18] <Honoome> hmm more likely Turin if lu_zero can be prodded enough ;) [01:12:40] <j-b> buon idea [01:12:50] <Kovensky> lolitaly [01:12:59] <Kovensky> I think my great grandfather was from italy ._. [01:13:36] <Honoome> Kovensky: that's something people try not to be known ;) [01:13:45] <Kovensky> :P [01:13:48] <Honoome> j-b: would also work out fine to get libnemesi integration in that case [01:14:08] <Kovensky> there are lots of italians in brazil, actually [01:14:16] <j-b> Honoome: well, did you speak to ivoire? he was testing libnemesi integration back at FOSDEM [01:14:34] <Kovensky> they floodes sÃ£o paulo before the japanese did [01:14:40] <Kovensky> flooded* [01:15:04] <Honoome> j-b: had a brief chat :) I was a bit spaced out at fosdem to be honest ;) mru and the others can definitely tell [01:15:43] <j-b> anyway, Venice was nice [01:15:48] <j-b> and my g/f loved it [01:16:06] <j-b> so, I believe i have now 6 months of bonus for extra-geeking [01:16:46] <Honoome> hah, that's why you wanted to have the next conference in venice ;) [01:18:27] <j-b> :) [01:21:00] <Honoome> I'm afraid the only conference in Venice is OpenCon [01:21:10] <Honoome> if it's still organised, which I'm not ready to bet on [03:29:53] <astrange> Yuvi: i think your removal of pixel_addresses_initialized actually made the vp3 decoder more resilient [03:30:48] <astrange> i have -mt artificially failing in get_buffer to test something, the decoder crashes afterwards by trying to access null golden_frame.data[0] [03:30:57] <astrange> since it didn't check that until your patch and i haven't merged yet [06:35:51] <josh> i want to take a shot at the direct temporal/spatial mv fixes from michael's low-hanging fruits h264 email [06:36:06] <kshishkov> send a patch then [06:36:08] <josh> is it ok to ask for help with that on here? the code is pretty dense [06:36:57] <kshishkov> yes [06:39:02] <elenril> morning [06:39:05] <astrange> grab http://www.savedonthe.net/avc_regression.7z, i think it has all the h264 conformance streams [06:39:08] <kshishkov> hej [06:39:27] <josh> alright [06:39:58] <astrange> you can test stuff with ffmpeg -i f.h264 -vsync 0 -f framecrc blah and check the output is the same before/after [06:40:06] * elenril sighs [06:40:12] <elenril> nobody want a nut conversion table :( [06:40:15] <elenril> *wants [06:40:19] <Dark_Shikari> and conformance vectors are very bad speed test cases [06:40:20] <Dark_Shikari> generally [06:40:25] <Dark_Shikari> it's best to use a Real World Stream for that [06:40:31] <Dark_Shikari> (but they're critical to test compliance of course) [06:40:42] <astrange> i use x264 streams for benchmarking [06:40:55] <astrange> don't have anything great that's representative of interlaced [06:40:58] <Dark_Shikari> Yeah I know, was poking to josh [06:41:00] <josh> will "time ffplay <video>" be a good way to benchmark? [06:41:13] <josh> for speed [06:41:29] <astrange> time ffmpeg is ok if you run it in a loop a few times and pick the minimum, and use user time [06:41:43] <astrange> (not time ffplay, though) [06:41:50] <josh> alright [06:41:51] <astrange> for smaller changes look at START_TIMER/STOP_TIMER [06:44:27] <Dark_Shikari> yeah, in general timer is far more reliable [06:45:02] <josh> okay cool, got a while to go before i do any testing though [06:45:18] <josh> trying to figure out just what the existing code does first [06:45:47] <astrange> it's heavily optimized but maybe still more readable than that part of the spec [06:46:00] <Dark_Shikari> it decodes h264, duh ;) ;) [06:47:57] <josh> heh yeah i'm just getting started in the video coding space, so there [06:48:05] <josh> 's quite a bit to learn [06:48:11] <Dark_Shikari> feel free to ask questions [06:48:17] <Dark_Shikari> it's how everyone else learned [06:48:36] <josh> will do, didnt think of reading the spec... doh, looking at that part now [06:48:46] <Dark_Shikari> spec is good to have on hand, just don't look too much at it [06:48:51] <Dark_Shikari> it can cause permanent brain damage [06:48:57] <josh> :) [06:48:59] <Dark_Shikari> it is known to the state of california to cause cancer [06:49:14] <josh> use the JM decoder as the authoritative reference? [06:49:17] <Dark_Shikari> yes [06:49:22] <josh> ok cool [07:08:59] <josh> hm [07:09:36] <josh> spec only defines spatial/temporal direct prediction for 16x16 and 8x8, and JM only implements it for 8x8 as far as i can tell [07:09:51] <Dark_Shikari> that isn't what he means [07:09:58] <Dark_Shikari> if you have a 16x16 direct block [07:10:08] <Dark_Shikari> based on type_col, your MV/ref choices may match up with a 16x16 block [07:10:09] <Dark_Shikari> 16x8 [07:10:09] <Dark_Shikari> 8x16 [07:10:10] <Dark_Shikari> or 8x8 [07:10:26] <Dark_Shikari> one optimization is to consider this when doing direct calculations. [07:30:45] <josh> hm guess i dont understand this as well as i thought i did [07:31:00] <josh> need to digest this for a bit (not to mention its almost 3am here) [07:31:10] <Dark_Shikari> the MVs for, say, a temporal direct block [07:31:20] <Dark_Shikari> are calculated by using the MVs/refs in the colocated block in the L1 ref frame. [07:31:24] <josh> right [07:31:25] <Dark_Shikari> If that block is 8x16 [07:31:36] <Dark_Shikari> then the MVs calculated will form an effective 8x16 block too. [07:31:44] <Dark_Shikari> and motion compensation can be simplified accordingly [07:31:50] <Dark_Shikari> instead of doing 4 8x8 blocks, you can do 2 8x16s [07:32:04] <Dark_Shikari> I think ffmpeg already does the simplified motion compensation, but not the simplified direct MV calculation [07:32:07] <josh> so its doing 4 8x8 blocks now [07:32:15] <josh> for a 8x16 mb [08:30:53] <josh> about the scan8 table, i understand the zigzag pattern but not the numbers [08:31:33] <Dark_Shikari> the numbers are the mapping [08:32:03] <josh> yeah, but the mappings dont make sense [08:32:16] <josh> a lot of it is like [08:32:25] <josh> &h->ref_cache[0][scan8[0]] [08:32:32] <Dark_Shikari> what's wrong with that [08:32:36] <josh> which is ref_cache[0][12] [08:32:39] <Dark_Shikari> scan8[0] means "the top left partition" [08:32:55] <Dark_Shikari> so ref_cache[0][scan8[0]] means the mv of the first partition of any block [08:32:59] <Dark_Shikari> er, the ref [08:33:05] <Dark_Shikari> since the first partition will always include scan8[0] [08:34:14] <josh> just trying to understand at a fundamental level, how does the number 12 (scan8[0]) translate to the first partition [08:34:28] <Dark_Shikari> Ignore the 12. [08:34:46] <josh> heh ok [08:34:49] <Dark_Shikari> perhaps this bit of ascii art will help [08:34:51] <Dark_Shikari> here's x264's [08:34:58] <Dark_Shikari> 0 1 2 3 4 5 6 7 [08:34:59] <Dark_Shikari> 0 [08:34:59] <Dark_Shikari> 1 B B L L L L [08:34:59] <Dark_Shikari> 2 B B L L L L [08:34:59] <Dark_Shikari> 3 L L L L [08:35:01] <Dark_Shikari> 4 R R L L L L [08:35:03] <Dark_Shikari> 5 R R [08:35:12] <Dark_Shikari> note there is a column to the left of each one, and a row to the top [08:35:18] <Dark_Shikari> that's for top/left values to be cached [08:35:33] <Dark_Shikari> the top left "L" is 12 because 4 + 8 = 12 [08:36:12] <Dark_Shikari> that ascii art represents how the data is stored in memory [08:36:17] <Dark_Shikari> L being luma, B being U, R being V [08:36:21] <josh> ah ok [08:36:48] <Dark_Shikari> so this might also be [08:36:49] <josh> 4:2:0, ok that's clearer [08:36:49] <Dark_Shikari> 0 1 2 3 4 5 6 7 [08:36:49] <Dark_Shikari> 0 b b l l l l [08:36:49] <Dark_Shikari> 1 b B B l L L L L [08:36:51] <Dark_Shikari> 2 b B B l L L L L [08:36:54] <Dark_Shikari> 3 l L L L L [08:36:56] <Dark_Shikari> 4 r R R l L L L L [08:36:59] <Dark_Shikari> 5 r R R [08:37:01] <Dark_Shikari> er, oops, forgot the two rs above the Rs [08:37:04] <Dark_Shikari> but whatever [08:37:06] <Dark_Shikari> you get the idea [08:37:09] <Dark_Shikari> lowercase are cached from previous MBs [08:37:12] <Dark_Shikari> uppercase are decoded/calculated for this MB [08:37:27] <josh> yeah i think so, it stores mvs for each of the planes [08:37:33] <Dark_Shikari> no it doesn't [08:37:53] <Dark_Shikari> the B/R sections are only used for data relevant to them, like nnz [08:37:59] <josh> nnz? [08:38:01] <Dark_Shikari> mvs, refs, etc are luma only [08:38:05] <Dark_Shikari> since they apply equally to chroma [08:38:08] <Dark_Shikari> nonzero count [08:38:14] <Dark_Shikari> Number of NonZero coefficients [08:38:25] <josh> gotcha [08:38:47] <josh> thats a lot clearer now, thanks [08:38:48] <Dark_Shikari> so scan8[0] means "the location in the array corresponding to the first L" [08:39:01] <Dark_Shikari> the array is constructed so that scan8[n]-1 is the value to the left of n [08:39:09] <Dark_Shikari> and scan8[n]-8 is the value to the top of n. [08:39:36] <josh> yup, ok, so thats how the mv_cache stuff is laid out in memory, right? [08:40:36] <Dark_Shikari> yes [10:09:17] <DonDiego> h264_direct.c:153: warning: ISO C90 forbids mixed declarations and code [10:09:24] <DonDiego> the world is coming to an end.. [10:11:05] <twnqx> finally that brokenness stops. never liked it. [10:27:17] <KotH> DonDiego: the world has already ended long ago, and we are but shadows of the past [10:45:49] <_av500_> amen.. [10:49:42] <KotH> _av500_: ah.. while you're here [10:50:14] <KotH> _av500_: does archos plan any mp3 player that is 1) not a big brick (aka non-video) and has 2) at least 64G memory ? [10:50:30] <KotH> _av500_: i'm looking for a replacement for my venerable cowon iaudio x5 [11:12:44] <pross-au> Hmm, iam i seeing things, or is PIX_FMT_RGB32 'alpha' handled differently between x86 and ppc [11:13:08] <pross-au> when alpha=0, x86 swscaler routines treat it as non-transparent (good) [11:13:23] <pross-au> when alpha=0, ppc swscaler treats it as fully transparent (bad imho) [11:21:46] <kshishkov> IIRC either was no settlement on how to treat alpha values or it has been changed later [11:23:33] <pross-au> thanks k-man. (urgh disregard, i figured it out) [11:26:24] * kshishkov wonders where that alpha is actually used except for textures [11:30:42] <pross-au> tsk tsk kshishkov [11:30:51] <pross-au> you forgot MPEG-4 object encoding [11:31:04] <kshishkov> who hasn't? [11:31:36] <pross-au> it has alpha masks [11:33:44] <Kovensky> alpha is one of the main reasons people use lagarith on fansubbing (other than stupidity) [11:34:06] <Kovensky> for storing after effects overlays for applying with avisynth [11:34:42] <kshishkov> oh [11:35:24] <pross-au> IIRC you can compress the alpha with MPEG-4 ASP [11:35:44] <pross-au> ooops, not ASP, one of the other brain dead profiles [11:36:08] <kshishkov> http://engrishfunny.files.wordpress.com/2010/01/engrish-funny-no-translatio… [11:37:40] <pross-au> That's a bit presumptuous of them [11:41:05] * Kovensky wonders if llvm svn still miscompiles ffmpeg [12:36:07] <j-b> BBB? [12:55:26] <DonDiego> Kovensky: only one way to find out.. [13:01:01] <Kovensky> heh [13:01:10] <Kovensky> first I need to compile it :S [13:01:28] <elenril> they don't have binary packages on fbsd? =p [13:02:36] <Kovensky> elenril: they have of 2.6 [13:11:30] <DonDiego> mru: the table generator naming scheme in libavcodec is a mess [13:59:05] <mru> DonDiego: I know [14:01:05] <DonDiego> mru: fix it :) [14:02:58] <elenril> anybody wants to write some readable documentation for -map? [14:19:10] <KotH> i guess that someone is you ;) [14:19:31] * elenril would have to understand it first =p [14:27:19] <justlooking> "elenril> anybody wants to write some readable documentation for -map?" "over on ffmpeg you said * elenril was recently enlightened about how -map works" you perhaps ? or you can just take DS's text ? "woxidu_home> I tried doing -map 0.8:0.4 [14:27:19] <justlooking> <woxidu_home> but I think that wasn't enlightened enough of me [14:27:19] <justlooking> <Dark_Shikari> no [14:27:19] <justlooking> <Dark_Shikari> -map stream1 -map stream2 -map stream3... [14:27:20] <justlooking> <Dark_Shikari> i.e. -map every stream you want in the output [14:27:22] <justlooking> * paltman has quit (Quit: paltman) [14:27:24] <justlooking> <woxidu_home> so if I want video stream 0.1 and audio stream 0.4, I'd do -map 0.1 -map 0.4 ? [14:27:26] <justlooking> <Dark_Shikari> yes..." [14:27:46] <J_Darnley> Simple use is simple! [14:31:12] * justlooking unless OC your alexander the meerkat http://www.youtube.com/watch?v=4Ust9YBlEfY "Simples" [14:34:21] <J_Darnley> "unless overclock your alexander"? [14:37:55] <justlooking> LOL, if your Personal Computers called alexander Yes Of Course. [15:19:57] <J_Darnley> Has anyone tested my flac-tag writing patch? [15:21:21] <J_Darnley> I need some help finding out why av_freep() causes a segmentation fault [15:23:24] <kshishkov> because you forgot ampersand before p0, silly [15:23:38] <kshishkov> also since variable is local, av_free() is enough [15:24:43] <J_Darnley> /facepalm [15:29:44] <J_Darnley> I wonder why it worked fine when I didn't write into p [15:36:15] <kierank> is there a macro/function to convert from channel mapping to number of channels? [15:36:47] <kshishkov> __builtin_clz() :) [15:37:26] <kshishkov> in channel mapping each bit represents one channel IIRC [15:44:27] <kierank> then i need something to count bits set [15:45:40] <Kovensky> clz =p [15:45:57] <Kovensky> unless the bits aren't packed [15:46:15] <kshishkov> why not use channel counnt directly? [15:46:20] <Kovensky> (count leading zeros) [15:46:48] <kshishkov> unfortunately, those bits are sparse [15:46:53] <Kovensky> ic [15:47:09] <Kovensky> too bad :( [15:52:38] <kierank> [15:46] <@kshishkov> why not use channel counnt directly? --> because for example 6 channels in dolby e could mean 6xmono, 3xstereo or 5.1 etc [15:55:22] <J_Darnley> kshishkov: If I don't need to set p0 to NULL, does the same apply to p? [15:57:09] <kshishkov> of course [16:02:22] <elenril> any news about bink decoder? [16:02:47] <kshishkov> works fine on newer files after some changes [16:02:57] <kshishkov> still have to add BIKb support [16:04:11] <elenril> when will it be merged? ;) [16:06:08] <kshishkov> who knows? [16:06:44] <elenril> you? [16:07:28] <kshishkov> no [16:08:10] <iive> when would you start sending patches to ML so it could be merged? [16:08:20] <kshishkov> I sent one [16:08:45] <iive> so, it's all in michael's hands. [16:10:59] <kshishkov> yes, and those are busy with H.264 [16:11:54] <elenril> did anyone benchmark latest improvements? [16:15:58] <kshishkov> only for the first few [16:17:19] <elenril> i know about those, it was ~10% faster [16:51:58] <kierank> found the function to find number of channels finally [16:51:59] <kierank> avcodec_channel_layout_num_channels [16:58:15] <josh> doing the spatial/temporal dpred h264 optimizations. direct blocks are always the same size as their ref block? [17:00:37] <kshishkov> should be, I think [17:01:33] <josh> ok [17:03:19] <pengvado> temporal direct blocks are the same size as their L1 ref [17:03:28] <pengvado> spatial direct blocks need not share any size with anything [17:09:28] <josh> alright [17:37:22] <josh> can someone take a look at this and let me know if i'm on the right track, or totally off base? this is just for 16x8 temporal dpred. http://pastie.org/824526 [18:07:32] <siretart> Dark_Shikari: I'm trying to compile 0.5 with your patch against an updated libx264 without luck: http://pbot.rmdir.de/47829498a2e7662d2610acab56ada447 [18:11:48] <J_Darnley> siretart: it looks like he might have missed modifying configure [18:12:23] <J_Darnley> change x264_encoder_open for x264_encoder_encode [18:41:38] <Dark_Shikari> siretart: your x264.h is screwed up [18:41:50] <Dark_Shikari> remember, the x264.h you include and the libx264 you link MUST MATCH VERSIONS [18:42:06] <Dark_Shikari> do remember that ld _prefers shared_, even if static is newer [18:43:40] <Honoome> unless it finds a static archive alone in a directory passed through -L [18:44:16] <siretart> Dark_Shikari: 'my' x264.h? that is the version from current tip :-) [18:44:25] <Dark_Shikari> siretart: this is a common newbie mistake [18:44:30] <Dark_Shikari> a user has an old x264 installed, and a new x264 installed [18:44:43] <Dark_Shikari> in your case, ffmpeg has #included an old x264.h header [18:44:47] <Dark_Shikari> but you are linking to a new libx264 [18:46:23] <siretart> Dark_Shikari: I have package current x264, and that package replaced /usr/include/x264.h [18:46:52] <Dark_Shikari> either way, something is broken, because x264.h redefines x264_encoder_open in any recent version [18:46:55] <Dark_Shikari> so you're using a year-old x264.h [18:47:49] <siretart> hm. but where does that come from? [18:48:11] <siretart> obviously not from /usr/include [18:48:32] <Dark_Shikari> probably local [18:48:42] <siretart> Dark_Shikari: I'd rather say that ffmpeg 0.5's configure doesn't work with current x264 [18:48:57] <siretart> there is no "local" x264.h around here [18:49:10] <Dark_Shikari> Oh, simple [18:49:15] <Dark_Shikari> we need to modify configure very slightly [18:49:16] <josh> siretart, you might have an older version of x264 lying somewhere? "locate libx264" [18:49:17] <Dark_Shikari> my mistake. [18:49:28] <Honoome> the configure is checking the symbol, not the definition, I guess [18:49:30] <siretart> afk, (1-2h) [18:49:31] <Dark_Shikari> s/x264_encoder_open/x264_encoder_encode in configure [18:49:35] <Dark_Shikari> that will fix it [18:49:41] <Honoome> [as in, not including x264.h so can't get the x264.h redefinition] [18:50:07] <siretart> Dark_Shikari: I imagined something like that, thanks for confirming that [18:50:23] <siretart> Dark_Shikari: can you propose a patch that would work with both api versions 67 and 84? [18:50:38] <Dark_Shikari> that will work with both [18:50:55] <siretart> ok, I'll try later. cu around [19:05:57] <kierank> How would request_channel_layout work if there are multiple tracks with the same track layout in one stream? [19:06:29] <kshishkov> huh? [19:06:41] <kshishkov> sounds like terminology collision [19:09:10] <kierank> e.g. 4 x stereo tracks (in the one dolby e "stream"). Each track has an AVStream but how do you signal to each decoder to decode tracks 0-1, 2-3, etc [19:15:19] <kshishkov> tough luck, I think [19:19:48] <kierank> hmmm I thought me and merbzt had this worked out but it turns out we dont... [19:21:23] <kshishkov> maybe you should further split that stream? [19:22:33] <kshishkov> ah, you do that (tracks) [19:23:05] <kshishkov> well, you provide data, FFmpeg decides which AVStreams from it to decode [19:24:19] <kierank> My idea was to send it the whole packet from which the decoder is told to decode x channels in y configuration. [19:24:34] <kierank> but there's no current way to signal the index [19:24:40] <kshishkov> why? [19:25:00] <kshishkov> I mean, what for? [19:26:25] <kierank> since a given packet can have 4 x stereo for example the current system won't work because the channel maps are the sample. On the other hand the demuxer could parse the dolby e packet [19:26:58] <kshishkov> the second way is better [19:28:13] <kierank> yes [19:29:12] <kierank> however there will be no way to deal with the metadata [19:29:37] <kshishkov> split it as well ;) [19:37:56] <kierank> merbzt, ping [19:45:46] <kierank> nice, lavc has support for afd [20:55:44] <josh> latest attempt at 16x8 temporal direct prediction here. http://pastie.org/824731 [20:56:05] <josh> it runs fine but the framecrcs are a bit off, not sure how to track that down. any tips? [20:56:06] <Dark_Shikari> the is intra part is pointless [20:56:10] <Dark_Shikari> either the type_col is intra, or it isn't [20:56:13] <Dark_Shikari> you can't have part of it be intra [20:56:22] <Dark_Shikari> an intra type_col counts as 16x16 [20:56:43] <josh> oh wasnt sure if you could have a 16x8 intra part [20:56:48] <Dark_Shikari> no [20:56:50] <josh> ok [20:58:17] <Dark_Shikari> for reference, it seems ref_cache[1] is always set to 0 [20:58:28] <Dark_Shikari> that should be split out of the per-partition code [20:58:33] <Dark_Shikari> since it's constant [20:58:42] <Dark_Shikari> i.e. a single 4x4 fill_rectangle [20:58:49] <Dark_Shikari> faster too [20:59:28] <josh> alright will do that [20:59:46] <Dark_Shikari> it can probably be done first before anything else [21:00:01] <Dark_Shikari> for reference, you should look at x264_mb_predict_mv_direct16x16_temporal in x264's code [21:00:04] <Dark_Shikari> it's not as optimized [21:00:05] <Dark_Shikari> but you may get some ideas [21:00:11] <Dark_Shikari> it's in common/macroblock.c [21:00:19] <Dark_Shikari> note how the _first_ thing it does is x264_macroblock_cache_ref( h, 0, 0, 4, 4, 1, 0 ); [21:00:33] <Dark_Shikari> (oh, and do note it's simplified--and explains in comments how it is--in ways that wouldn't work in ffh264) [21:01:14] <josh> i'll check it out, my first dive into x264 code, heh [21:01:23] <Dark_Shikari> It's also much shorter. [21:45:21] <Dark_Shikari> hmm, how do I run backtrace on all threads in gdb? [21:47:17] <thresh> thread apply all bt [21:48:40] <Dark_Shikari> ah k, thx [21:49:30] <Dark_Shikari> hmm. any reason why code would segfault in gdb but not outside of gdb? [21:49:47] <Honoome> Dark_Shikari: are you sure it's a segfault and not a SIG33 or something like that? [21:49:55] <Dark_Shikari> SIGSEGV [21:51:43] <Dark_Shikari> worse, it's inside a nested macro [22:52:55] <mt> Are there any available samples of joint-stereo atrac3 streams in rm ? [22:54:18] <mru> if so, we have a winner for obscure sample of the month [22:55:23] <Honoome> elenril: uhm I heard you saying something about map_meta_data and artist mapping lately? [22:56:30] <mt> mru: So it would be impossible to test whether the decoder actually works correctly for such samples, however rare/obscure ? :)

1 0

IRC log for 2010-02-13
by irc＠mansr.com 14 Feb '10

14 Feb '10

[00:34:51] <Dark_Shikari> astrange: that encoder was xvid avc? [01:16:08] <Dark_Shikari> Yuvi: you have a profile of theora now? [01:16:20] <Dark_Shikari> I wonder how much time init_frame is taking up, it seems wholly unnecessary [01:17:47] <Dark_Shikari> or at least inefficient [01:22:06] <Yuvi> Dark_Shikari: http://pastebin.com/m23eed1c8 3.5% [01:22:17] <Dark_Shikari> holy shit that's slow [01:22:21] <Yuvi> and yeah, it isn't necessary [01:22:29] <Yuvi> or won't be necessary [01:22:31] <Dark_Shikari> some of it might be [01:22:32] <Dark_Shikari> ah ok [01:22:35] <Yuvi> it's needed for the moment [01:22:37] <Dark_Shikari> so you've already factored that out in your planned overhaul? [01:22:43] <Yuvi> yeah [01:22:56] <Dark_Shikari> ah good. [01:23:07] <Dark_Shikari> did you come up with a way to make the MV decoding handling less shit? [01:23:13] <Dark_Shikari> e.g. not copying data all over the place [01:24:18] <Yuvi> figure out how many MVs there are when unpacking mb modes, decode that # in unpack_vectors and nothing else, do the rest immediately before actual MC [01:25:24] <Dark_Shikari> good, k [01:25:40] <Dark_Shikari> this already done and waiting for commit? [01:26:19] <Yuvi> done as in it's in my github repository, not done as in a clean diff from current svn [01:27:33] <Dark_Shikari> ah k [01:27:55] <Dark_Shikari> have you found a good way to deal with [01:27:55] <Dark_Shikari> #define DC_COEFF(u) (s->coeffs[u].index ? 0 : s->coeffs[u].coeff) //FIXME do somethin to simplify this [01:28:33] <Yuvi> currently, I simply store the actual DC in the fragment structure [01:28:53] <Dark_Shikari> k [01:29:00] <Dark_Shikari> so that simplifies that [01:31:40] <Dark_Shikari> any reason we don't have an sse loopfilter? [01:32:21] <Yuvi> it can't be done with width 16 due to the retarded ordering [01:32:29] <Dark_Shikari> it might be worth unpacking on faster CPUs though [01:32:34] <Dark_Shikari> to limit the amount of bitmath [01:32:43] <Dark_Shikari> penryn, nehalem, and phenom [01:32:51] <Dark_Shikari> i.e. doing it in 16-bit math [01:33:38] <Yuvi> might be worth doing, neon certainly does it with 16-bit math [01:33:57] <Dark_Shikari> note unpack in sse is very slow on core 2 conroe [01:34:07] <Dark_Shikari> and probably not worth it on anything older [01:34:10] <Dark_Shikari> but definitel worth trying [01:35:25] <Dark_Shikari> also did you fix the fixed-size tables thingy? [01:36:14] <Dark_Shikari> also,w hat are the different %s in the profile? [01:37:13] <Dark_Shikari> also put_no_rnd_pixels8_l2_c being at 4.5% is serious [01:38:00] <Yuvi> I did for the emu_edge_buffer, not qscale table [01:38:26] <Yuvi> the first % is self, second is total including sub functions [01:39:49] <Yuvi> and yeah, I haven't written dsp functions that don't need that branch, and don't really want to write asm versions of _l2 when they'll be replaced by them [01:40:10] <Dark_Shikari> the branch is nasty [01:40:24] <Dark_Shikari> unpredictable [01:41:17] <Dark_Shikari> ugh, it's hard to find things to optimize because you're changing so much of it [01:41:32] <Dark_Shikari> oh, a note about the loop filter [01:41:43] <Dark_Shikari> the loop filter code is called under if( y > 0 ) [01:41:51] <Dark_Shikari> therefore, I don't think we need the y > 0 check in the loopfilter [01:43:24] <Yuvi> (y>>3)-1 [01:44:00] <Yuvi> it's called on the previous row, so it needs the y>0 check outside so we don't call it on negative rows [01:44:04] <Dark_Shikari> oh, ew [01:45:47] <Dark_Shikari> hmm, I just realized that if you wanted to be an utter dick, you could do something trashy like this [01:45:54] <Dark_Shikari> have reference frame be the same thing as the current frame [01:46:14] <Dark_Shikari> and decode blocks in an order such that you never overwrite critical data [01:46:27] <Dark_Shikari> but the logic would probably not be worth it to save memory/cache [01:47:46] <Dark_Shikari> oh btw, what's the longest possible VLC code for a motion vector? [01:48:08] <ohsix> 42 sam hocevars [01:48:32] <Yuvi> how would that work / what would it gain? [01:48:42] <Yuvi> and 12 bits iirc, I'll check [01:49:05] <Dark_Shikari> it would save massive amounts of cache and memory. how would it work? now that I think about it, probably pretty badly [01:49:18] <Yuvi> nope 8 bits [01:49:36] <Dark_Shikari> can't we make the VLC reading function better then? [01:49:39] <Dark_Shikari> and do a direct table lookup? [01:49:59] <Dark_Shikari> motion_vector_table[show_bits(8)]; [01:50:32] <Yuvi> isn't that what get_vlc2 does if you change it to 8,1 instead of the current 6,2? [01:51:53] <Dark_Shikari> sorta but you can do better [01:51:59] <Dark_Shikari> if MIN_CACHE_BITS >= 16 [01:52:04] <Dark_Shikari> UPDATE_CACHE before reading the MV [01:52:08] <Dark_Shikari> and then SHOW_BITS(8) for the first MV [01:52:10] <Dark_Shikari> SKIP_BITS(8) [01:52:15] <Dark_Shikari> and SHOW_BITS(8) again for the second MV [01:52:27] <Dark_Shikari> this is what coreavc does for its entire cavlc code [01:52:32] <Dark_Shikari> and cabac [01:52:41] <Dark_Shikari> manual cache tracking to minimize update_cache calls [01:53:07] <Dark_Shikari> do all the bitstream readers have a MIN_CACHE_BITS of 16 or higher? [01:53:18] <Dark_Shikari> Yup they do [01:53:24] <Dark_Shikari> you're good then [01:53:57] <Dark_Shikari> also, coding_mode doesn't vary per frame, right? [01:54:02] <Dark_Shikari> you can get rid of that branch I think [01:54:40] <Dark_Shikari> i.e. merge them into the same thing, and specially construct the fixed table such that it works with a show_bits [01:54:54] <Dark_Shikari> unless the fixed mode is _common_ in which case it should probably be optimized [01:55:03] <Dark_Shikari> oh, and skip_bits(8) is obviously wrong, ignore that [01:55:42] <Dark_Shikari> this would make the VLC table bigger though. [01:55:49] <Dark_Shikari> I don't think we're lacking for cache though. [01:57:07] <Yuvi> well, the fixed mode is used if most MVs are longer than 4 pixels [01:58:25] <Yuvi> cache probably isn't too important given that only one type of data is decoded at once [01:58:58] <Dark_Shikari> true [01:59:08] <Dark_Shikari> how often is the fixed mode used in practice? [01:59:50] <Yuvi> dunno [02:03:35] <Dark_Shikari> could test it [02:11:16] * Dark_Shikari looks at unpack_vlcs [02:11:26] <Dark_Shikari> I think in general this could benefit a lot from larger VLC tables with fewer levels [02:12:43] <Yuvi> fixed is used from between 1/5 and 1/2 of the time depending on source ofc [02:21:48] <CIA-17> ffmpeg: michael * r21784 /trunk/libavcodec/h264_direct.c: [02:21:48] <CIA-17> ffmpeg: Pack MVs together from the begin for spatial direct, this simplifies the code [02:21:48] <CIA-17> ffmpeg: and is a bit faster (5-10 cpu cycles depending on what is meassured). [02:30:54] <Dark_Shikari> Yuvi: hmm. maybe the code could be templated? [02:31:17] <astrange> 19:35 <@Dark_Shikari> astrange: that encoder was xvid avc? <- it wrote XVID into a sei [02:31:35] <Dark_Shikari> astrange: or pascal just liked xvid =p [02:31:37] <astrange> it might have been a joke, i know skal did write his own h264 codec though [02:31:49] <astrange> it was on his old site [02:32:08] <astrange> er, the codec wasn't, but "i wrote one" was [02:35:06] <Dark_Shikari> yeah, templated code makes the most sense. [02:35:10] <Dark_Shikari> since it's run on the whole frame at a time [02:35:47] <Dark_Shikari> if (run_length == 4129) <--seriously needs a comment [02:48:30] <CIA-17> ffmpeg: michael * r21785 /trunk/libavcodec/h264_direct.c: [02:48:31] <CIA-17> ffmpeg: Special case for spatial direct MV predictor being 0. [02:48:31] <CIA-17> ffmpeg: a little less than 200 cpu cycles faster with the cathedral sample. [03:44:05] <CIA-17> ffmpeg: cehoyos * r21786 /trunk/libavcodec/libgsm.c: [03:44:05] <CIA-17> ffmpeg: Fix compilation with --enable-libgsm on Gentoo and OpenSUSE. [03:44:05] <CIA-17> ffmpeg: Patch by Ramiro [03:50:26] <CIA-17> ffmpeg: michael * r21787 /trunk/libavcodec/h264_direct.c: [03:50:26] <CIA-17> ffmpeg: Split spatial and temporal direct MV generation. [03:50:26] <CIA-17> ffmpeg: A little faster and needed for future optimizations. [03:50:26] <CIA-17> ffmpeg: This sadly leads to some code duplication (which i hope i can factor out [03:50:26] <CIA-17> ffmpeg: again after the optimizations on the direcr mv code are done) [03:59:35] <Yuvi> ...wow, unpack_vectors does four full traversals of the coded blocks for each 4mv macroblock [03:59:44] <Yuvi> I did not realize that [03:59:49] <Dark_Shikari> Yeah. That. [04:01:58] <Yuvi> (it doesn't in my tree, so it'll be fixed soon) [04:01:59] <Yuvi> but ugh [04:24:28] <Dark_Shikari> Yuvi: another idea is some loop unrolling or special casing in order to eliminate edge checks [04:24:35] <Dark_Shikari> or just setting up the arrays with edge buffers [04:24:47] <Dark_Shikari> reverse dc pred is a particularly good target for this [04:27:25] <Dark_Shikari> hmm. I wonder if there's a nice bitmath version of if( abs(x-y) > 128 ) taking advantage of the fact that 128 is a nice round number [04:30:26] <astrange> peloverde: some (all?) of the constant divides i noted are still there, could they not be made reciprocal multiplies? [04:33:09] <astrange> int f = abs(x-y)>128; is already branchless with a copy cr -> gpr instruction [04:33:16] <astrange> what's the if body? [04:33:37] <Dark_Shikari> if (FFABS(predicted_dc - vu) > 128) [04:33:37] <Dark_Shikari> predicted_dc = vu; [04:33:37] <Dark_Shikari> else if (FFABS(predicted_dc - vl) > 128) [04:33:37] <Dark_Shikari> predicted_dc = vl; [04:33:37] <Dark_Shikari> else if (FFABS(predicted_dc - vul) > 128) [04:33:40] <Dark_Shikari> predicted_dc = vul; [04:33:53] <Dark_Shikari> has to be done for basically every block [04:33:58] <Dark_Shikari> despite it triggering basically 0% of the time [04:34:02] <Dark_Shikari> thus, it annoys me [04:35:05] <astrange> predictably false is faster than branchless (maybe?), but three compares instead of one isn't great [04:35:20] <Dark_Shikari> but the checks themselves aren't very fast either [04:35:59] * Dark_Shikari checks the asm [04:42:20] <Yuvi> Dark_Shikari: yeah, haven't really looked at that quite yet [04:42:32] <Yuvi> the edges that is [04:42:58] <Yuvi> http://github.com/yuvi/ffmpeg/commit/01da0d178c3499f1ac6d87d644327a101f29b7… did some stuff to dc pred including only running those 3 checks for the 1 case they matter [04:43:19] <Yuvi> but which happens to be nearly every block for keyframes still [04:44:02] <Dark_Shikari> http://pastebin.com/m41ea818b [04:44:28] <Dark_Shikari> how much faster was that? [04:44:32] <Dark_Shikari> oh [04:44:34] <Dark_Shikari> I see... [04:44:46] <Dark_Shikari> btw, for reference, transform == 15 is by far the most common case [04:44:48] <Dark_Shikari> I did statistics on this [04:45:22] <Dark_Shikari> which is why the switch isn't too useful [04:47:00] <Yuvi> makes sense [04:47:11] <Dark_Shikari> oh, another thing [04:47:15] <Dark_Shikari> if we keep the current system [04:47:16] <Dark_Shikari> we could do [04:47:20] <Dark_Shikari> if( predictor_transform[transform][3] == 116 ) [04:47:29] <Dark_Shikari> it's already in a register from before, and simplifies the logic [04:47:47] <Dark_Shikari> btw, for reference, are we allowed to commit trivial optimizations to vp3 without discussion as long as we bench it? [04:48:07] <astrange> ask mike [04:48:21] <Dark_Shikari> ok [04:48:27] <astrange> btw gcc assumes if (x == y) is untaken [04:48:41] <astrange> i don't think that affects many things though [04:48:59] <Dark_Shikari> interesting. [04:49:54] <Yuvi> mike didn't say anything when michael suggested I just commit directly [04:50:22] <astrange> http://gcc.gnu.org/viewcvs/trunk/gcc/predict.def?revision=154645&view=markup [04:50:33] <Yuvi> but I guess I'll send my next set since there isn't really any speed improvement, just -100 LOC and less memory usage [04:51:38] <Yuvi> gnu commit messages... [04:52:17] <astrange> i looked for an anchor to skip it but didn't see one [04:52:41] <Dark_Shikari> hmm crap, I need a vp3/theora sample to test on again [04:52:48] <astrange> they're nice sometimes if you don't have log --stat [04:52:52] <Dark_Shikari> oh nvm, got one [04:53:52] <Yuvi> btw, tell me if you get a speedup with http://pastebin.com/m27da8328 [04:54:00] <astrange> huh, i was going to write an "enable malloc_aligned" patch for configure but it's already there [04:54:41] <Dark_Shikari> Yuvi: overall benchmarks are hard [04:54:45] <Dark_Shikari> any function you want me to test? [04:55:05] <Dark_Shikari> I'm not exactly on a system that gives stable results for large benchmarks [04:55:36] <Dark_Shikari> but even getting rid of all those stupid bad macroblock number messages is a good idea [04:55:53] <Dark_Shikari> and I like the patch [04:57:42] <Yuvi> unpack_modes/vectors I guess, but I was more interested in overall speedup [04:57:56] <Yuvi> guess I'll see if it helps on arm [05:01:35] <Dark_Shikari> hmm. I wonder how useful making keyframes long term refs would be in x264 [05:01:41] <Dark_Shikari> isn't the golden frame just the last keyframe? [05:01:48] <Yuvi> yeah [05:01:59] <Dark_Shikari> what's GOLDEN_MV vs USING_GOLDEN? [05:02:10] <Yuvi> latter impies 0,0 [05:11:21] <Dark_Shikari> hmm, I should go back through michael's optimizations and backport the relevant ones to x264 [05:11:25] <Dark_Shikari> I really like his 0,0 spatial direct one [05:11:29] <Dark_Shikari> I never thought of that before. [05:12:13] <astrange> splitting temporal and spatial up is nice. but now i have to wait until it's done again before i can merge into -mt [05:12:44] <astrange> and the theora changes probably broke that too. luckily draw_horiz_band does the same thing as what it broke so it can just go in there [05:16:36] * Dark_Shikari commits backport of mv0 spatial change [05:30:40] <Dark_Shikari> Yuvi: see my email [05:32:33] <Yuvi> I guess I should add a sample that uses multiple quants to what I check [05:33:26] <Dark_Shikari> good idea [05:45:30] <Dark_Shikari> looking through all of michael's changes, it's scary how much stuff there is [05:46:16] <Dark_Shikari> what does flatten attribute do? [05:46:33] <Yuvi> inlines everything it can that that function calls [05:46:42] <Dark_Shikari> ah, interesting [05:46:48] <Dark_Shikari> so it offers a way to inline from the opposite perspective [05:46:54] <Dark_Shikari> that might be useful. [05:46:59] <Dark_Shikari> do any other compilers support it? [05:47:04] <Yuvi> llvm doesn't [05:47:07] <Dark_Shikari> icc? [05:47:14] <astrange> llvm doesn't and tends to inline in the wrong direction too [05:47:17] <Dark_Shikari> lol [05:47:20] <astrange> didn't check icc [05:47:32] <Yuvi> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-June/072008.html doesn't look like it [05:47:33] <astrange> llvm inlines get_cabac_residual*dc back into one get_cabac_residual somehow [05:47:56] <astrange> i'll send an always_inline patch for that in a sec [06:33:56] <pJok> mornings [06:34:13] <kshishkov> goda morgnar [07:31:19] <_av500_> gm [07:32:06] <kshishkov> wyaat? [07:39:10] <astrange> 4.2%1447 memset(h->non_zero_count[mb_xy], 0, 32); [07:39:20] <astrange> hmm, that should be zero128 * 2 [07:40:03] <astrange> gcc 4.2 generates rep stosw instead [08:43:23] <siretart> Dark_Shikari: okay, now that I have tested that your proposed libx264.c works with x264 in ubuntu, can you please suggest me a newer git revision that you would think would be fit for the next ubuntu release? [08:50:30] <Dark_Shikari> what architectures will the release be on? [08:52:07] <Dark_Shikari> siretart: ? [08:57:10] <Dark_Shikari> and what's the deadline [09:07:57] <siretart> Dark_Shikari: http://wiki.ubuntu.com/ReleaseSchedule, at 'FeatureFreeze' the new version must have arrived the archive. [09:08:27] <siretart> Dark_Shikari: as for architectures, the most important are i386, amd64, and armel [09:08:55] <Dark_Shikari> armel? [09:08:56] <Dark_Shikari> what's arm el [09:09:06] <kshishkov> ARM little-endian [09:09:11] <siretart> arm with EABI and little endian. aka 'the new arm port' [09:09:27] <Dark_Shikari> oh, so you're saying I have to pick a version from before dec. 3? [09:10:03] <siretart> no, I'm saying the new version must be in the archive before next thursday [09:10:08] <Dark_Shikari> Oh [09:10:14] <Dark_Shikari> whoops, was looking in the wrong place [09:10:23] <Dark_Shikari> ok, we have an arm compile fix locally [09:10:27] <Dark_Shikari> currently arm compilation is broken [09:10:57] <Dark_Shikari> possible plan: [09:11:00] <siretart> and I'll be on a buisness trip from next wednesday to friday with probably limited internet connection [09:11:02] <Dark_Shikari> 1) feature freeze today [09:11:05] <Dark_Shikari> 2) get commits in this weekend [09:11:14] <Dark_Shikari> 3) give until tues/wed for any reported bugs [09:11:18] <Dark_Shikari> 4) upload that [09:11:29] <Dark_Shikari> of course this depends on whether pengvado shows up [09:11:37] <Dark_Shikari> I have a number of "potentially stable" revisions sitting around to pick from if he doesn't [09:11:44] <siretart> okay, that sounds reasonable. [09:11:47] <Dark_Shikari> and of course we could pick 1416 and backport the single arm fix if necessary [09:11:57] <siretart> btw, feature freeze doesn't mean that we cannot update the package anymore [09:12:12] <siretart> it is rather a syncronisation point for 'no radical changes from this point on' [09:12:18] <Dark_Shikari> ah ok [09:12:23] <Dark_Shikari> so we can still add minor fixes/etc [09:12:40] <siretart> sure [09:12:53] <Dark_Shikari> ah k. [09:14:49] <siretart> this means for me that I can just package current x264 tip and test your patch against that, is that correct? [09:14:55] <Dark_Shikari> yes. [09:15:02] <Dark_Shikari> we have no API changes planned in the near future [09:15:09] <Dark_Shikari> well, we have one locally, but nothing ffmpeg will use [09:15:10] <siretart> ok, that's what I need to know [09:15:15] <Dark_Shikari> nor does it change ABI [09:15:25] <Dark_Shikari> it just changes the capabilities of encoder_reconfig [09:15:29] <Dark_Shikari> so it's sort of a "free API change" [09:15:34] <siretart> I see that I find some time for that tonight [09:15:38] <Dark_Shikari> great [09:16:09] * thresh raises a letter plate saying 'fix arm already' [09:16:49] <Yuvi> l;o [09:17:00] <Dark_Shikari> thresh: do you want the patch? [09:17:03] <Dark_Shikari> pengvado is afk and it's annoying [09:17:35] <thresh> Dark_Shikari: i have a hack locally that worksforme (tm), so it wouldnt really change anything [09:17:45] <Dark_Shikari> k [09:19:58] <Dark_Shikari> just tell pengvado to stop disappearing randomely [09:20:04] <Dark_Shikari> or find us another BDFL [09:20:34] <kshishkov> you can always steal fenrir back ;) [09:20:44] <Dark_Shikari> that would require money [09:20:50] <Dark_Shikari> like, enough to outbid ateme [09:21:35] <kshishkov> can't you give him say 50% of your overall x264 profit? [09:22:33] <Dark_Shikari> lol [09:22:38] <Dark_Shikari> iirc the allocation is like 15% [09:29:51] <kshishkov> still, offer him CEO position, 25% shares [09:30:54] <Dark_Shikari> he hasn't done anything in 5 years [09:30:54] <Dark_Shikari> -.- [09:31:13] <kshishkov> maybe it's _your_ fault? [09:31:17] <Dark_Shikari> lol [09:31:23] <Dark_Shikari> because I was totally on the project 5 years ago ;) [09:31:29] <Dark_Shikari> (more likely, it's ateme's fault ;) ) [09:39:43] <thresh> Dark_Shikari: why do you need someone to control your patches? [09:39:57] <thresh> usually angry users with failing compiles and / or encodes do that :-) [09:42:48] <Dark_Shikari> thresh: the way we keep code quality is simple [09:42:53] <Dark_Shikari> _ALL_ changes are reviewed by both me and pengvado [09:42:56] <Dark_Shikari> no matter who wrote them [09:43:06] <Dark_Shikari> though nowadays we're adding to that, usually bugmaster reviews too. [09:43:16] <Dark_Shikari> and sometimes yuvi, kierank, and/or kemuri9. [09:43:26] <Dark_Shikari> but the main restriction is that both of the lead devs should review the code. [09:43:39] <Dark_Shikari> and I don't like violating that, it's bad form [09:43:44] <Dark_Shikari> and bad for code quality [09:44:38] <thresh> okay, maybe there should be a 'closing window' for that [09:45:45] <thresh> i mean if someone is absent and the review was done by other team members, commit those anyway [09:46:06] <thresh> but you know better, i'm sure [09:47:17] <Dark_Shikari> just from experience, everyone always has at least one thing they want changed [09:47:22] <Dark_Shikari> and in a large set of patches, it's usually more than one [09:47:33] <Dark_Shikari> so if you don't wait for them, you end up committing a fix afterwards anyways [10:37:17] <astrange> /home/fate/fate64/source/libavcodec/h264_direct.c:441:11: warning: incompatible pointer types assigning 'int16_t (*)[2]', expected 'int16_t const (*)[2]' [10:37:21] <astrange> l1mv1 = &h->ref_list[1][0].motion_val[1][h->mb2b_xy [mb_xy]]; [10:37:29] <astrange> is there a point to this warning? [10:45:28] <pJok> it expected a const rather than a non-const [10:48:09] <astrange> other way round [11:15:06] <kshishkov> pross-au: can you send me your BIKb decoder in exchange for your name in libavcodec/bink.c ? [11:17:31] <pross-au> wilco [11:18:28] <Dark_Shikari> roger [11:18:59] * kshishkov remembers Space Quest series immediately [11:19:13] <kshishkov> thanks [11:22:57] <neo01124> can someone tell me some starting points for creating/porting a demuxer for the sony playstation portable format PMP [11:22:59] <neo01124> ? [11:23:35] <kshishkov> google.com was always a good starting point for anything [11:24:38] <kshishkov> it says "skip 124 bytes of PSP metadata and decode it as an ordinary JPEG" [11:24:46] <andoma> anyone know anything about a FFmpeg implementation of WMA lossless? [11:25:10] <kshishkov> andoma: well, unless jai does it, we've BBB to do it [11:25:25] <kshishkov> andoma: also Mike showed some interest but that's all [11:26:26] <andoma> hm ok .. i see [11:26:30] <andoma> i was just curious [11:29:16] <neo01124> kshishkov: could you give me the link for that [11:30:14] <Dark_Shikari> www.google.com [11:30:19] <kshishkov> neo01124: here, first link from Google search on "PMP format" - www.klingebiel.com/tempest/hd/pmp.html [11:36:32] <neo01124> kshishkov: i was asking about the playstation portable pmp format, that is some sony camera format [12:15:57] <DonDiego> neo01124: look at other simple demuxers, check out the multimedia wiki [12:16:04] <DonDiego> and the developer documentation [14:10:42] <DonDiego> what is libaacplus? [14:10:59] <DonDiego> i stumbled across a libaacplus glue patch for ffmpeg [14:11:21] <kshishkov> reference 3GPP encoder glued to FFmpeg [14:11:55] <kshishkov> http://tipok.org.ua/node/17 [14:12:03] <mru> DonDiego: did that nellymoser guy go silent? [14:12:22] <kshishkov> (it's like a doorstop since everybody stumbled on it) [14:13:24] <tipok> ? [14:14:02] <DonDiego> mru: yes [14:14:30] <tipok> it's encoder only [14:15:02] <kshishkov> yes, but its license prevents from using it in FFmpeg [14:15:29] <tipok> hmm... it's better than nothing [14:15:50] <kshishkov> yes, it the same way as it was with AMR [14:19:20] <twnqx> what i never was sure abou [14:19:20] <twnqx> t [14:19:46] <twnqx> is using dlopen() and friends to runtime use a library the same as linking against it, licensewise? [14:20:34] <kshishkov> how much are you going to pay? [14:20:43] <twnqx> lol [14:20:48] <twnqx> i don't care enough :> [14:20:55] <thresh> you're allowed to do that [14:20:59] <thresh> IIRC [14:21:30] <kshishkov> if you are not, just tip any cop around and do it anyway [14:21:45] <twnqx> i have no intention to write a program at the moment [14:21:48] <twnqx> i just wondered. [14:22:09] <twnqx> i thought among the lines of "if the program really requires it to do anything it surely would violate the liecense, otherwise... maybe. [14:22:11] <DonDiego> twnqx: yes, it's the same, why would there be a difference [14:22:41] <kshishkov> manual dynamic linking [14:23:46] <DonDiego> the license does not care about the type of linking [14:24:01] <kshishkov> neither do I [14:24:17] <DonDiego> people keep thinking that because there is a technical difference there must be a legal difference [14:24:22] <DonDiego> this is not the case [14:24:45] <DonDiego> the law is not aligned along the same boundaries as C code [14:24:55] <twnqx> i thought the difference is "must be there" or "the user can place it there" [14:25:20] <mru> dlopen can make a difference if there are multiple libs with the same interface but different licences [14:25:30] <twnqx> as in "if the user puts the amr liberaries there we can use it, but we don't need them" [14:25:41] <DonDiego> yes [14:25:51] <DonDiego> but the difference is not the technical interface [14:25:59] <DonDiego> the difference is that in one case you ship the libs [14:26:03] <DonDiego> in the other you don't [14:26:04] <twnqx> true, but you can't to that with static linking [14:26:18] <DonDiego> but do you see the difference? [14:26:28] <twnqx> ig it's about shipping, yes [14:26:30] <twnqx> if* [14:26:36] <twnqx> but i was thinking of GPL impact, e.g. [14:27:27] <twnqx> i mean, as e.g. ffdshow enables the use of GPL'd code on windows, used by closed source players... [14:27:47] <kshishkov> DonDiego: tainted Linux kernel serves an example [14:32:24] <DonDiego> dshow is a system interface that passes data on to codec implementations that may be free or proprietary [14:32:31] <DonDiego> how would the calling application know? [14:32:45] <DonDiego> the calling app is not derived from the gpl codec code [14:35:05] * justlooking notices theres 24 patches in x264dev that look interesting once they pass review peloverde [14:37:02] * justlooking opps wrong window [16:37:22] <DonDiego> mru: why ifdef CONFIG_MPEGAUDIO_HP [16:37:26] <DonDiego> and not ifeq? [16:37:32] <DonDiego> in libavcodec/Makefile [16:37:48] <kshishkov> maybe because nobody has canged code for it? [16:37:51] <kshishkov> *changed [16:39:38] <mru> DonDiego: ifdef is correct [16:40:21] <mru> ifeq ($(FOO),) is ugly [16:41:00] <kshishkov> had anybody read MN mail to MPlayer-dev-eng ML about binary codec support in FFmpeg? [16:41:29] <DonDiego> oops [16:41:35] <DonDiego> what happened there? [16:41:39] <mru> kshishkov: that's been out of the question forever [16:42:00] <kshishkov> mru: and if I read it correctly, he is in favor of adding it [16:42:16] <mru> well, I'm not [16:42:25] <mru> it doesn't belong there [16:43:02] <kshishkov> yes, it seems to be counterproductive [16:43:11] <kshishkov> yet it's strange to see that message at all [16:44:21] <mru> subject? [16:45:34] <kshishkov> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-February/063622.ht… [16:46:33] <mru> ffmpeg is not supposed to be the one wrapper to use them all [16:47:53] <Compn> yes, but thats what ffmpeg has become [16:48:07] <Compn> and we know people like the unified api that ffmpeg gives to x264/xvid/faac/etc [16:48:23] <kshishkov> it does not permit knowlingly lowsy code to be executed though [16:49:07] <mru> I'm all for dropping the xvid wrapper [16:49:21] <Compn> seems like an anti-user opinion [16:49:26] <mru> ffmpeg policy has always been to wrap only clean libs [16:49:27] <kshishkov> you don't like redundancy? [16:49:32] <mru> and then only when no native support exists [16:49:33] <Compn> kshishkov: think of it as using binary codecs for testing (which is what you do now, just with mplayer..) [16:50:07] <kshishkov> Compn: too bad avidemux is dead [16:50:29] <kshishkov> mru: but in that case lavc encoder is also better [16:53:56] <Honoome> kshishkov: don't name avidemux again when I'm around please :P [16:55:03] <kshishkov> Honoome: why? [16:55:21] <Honoome> had a bad experience with the author… [16:55:38] <kshishkov> ah, understood [16:55:42] <astrange> lavc is better at slower settings, i don't know if it's better at xvid speeds [16:56:07] <kshishkov> more feature-complete too [16:56:11] <astrange> maybe just because i could never figure out good settings for that, it needs an AI preset generator [16:56:14] <Honoome> basically when I first joined Gentoo I was looking at fixing the bundled-libs issues with it… so I rewrote the configure to have switches to disable stuff [16:56:35] <Honoome> sent upstream… he merged part of it and broke the rest… re-did the patch from scratch on the new version… again only partly merged and broke the rest =_= [16:57:00] <mru> reminds me of broadcom [16:59:04] <Honoome> with the crystalhd stuff? [16:59:28] <mru> no [16:59:43] <mru> with their stb chips [17:00:06] <Honoome> oh, okay… sorry but my last contact with broadcom has been at the time of the iBook g4 :P [17:13:52] * elenril wonders if he should try gsoc this year [17:14:14] <kshishkov> do we have GSoC tasks on metadata? [17:14:34] <elenril> no, but we can make some :) [17:15:01] <elenril> and i'm not just meta guy [17:22:46] <kshishkov> well, what are your other achievements? [17:23:40] <elenril> a failed matroska ordered chapters patch ;) [17:24:51] <elenril> normal chapters for matroska [17:45:46] <Honoome> elenril: you name matroska and chapters and beandog appears :P [17:45:57] <beandog> whut? [17:45:59] <beandog> whatd I miss [17:46:15] <Honoome> nothing really, just poking fun :) [17:47:01] <beandog> Aww [17:47:08] * elenril doesn't see the connection [17:47:20] <kshishkov> let's see [17:47:21] <beandog> chapters are good for you [17:47:24] <Honoome> elenril: I remember beandog fighting hard about matroska chapters before :P [17:47:33] <beandog> Ah, si [17:47:56] <beandog> and metadata [17:48:15] <Kovensky> ordered chapters where =p [17:49:37] <elenril> Kovensky: repo.or.cz/mplayer =p [19:27:58] <lu_zero> .... [19:28:18] <lu_zero> seems that their service got updated in a quite annoying way... [19:29:32] <Honoome> lu_zero: their as in Freenode's? [19:29:46] <lu_zero> yes... [19:29:53] <Honoome> lu_zero: are you sure it's not tiscali? :P [19:30:00] <lu_zero> yes I am. [19:30:08] <lu_zero> I'm in too many channels [19:54:47] <DonDiego> Yuvi: i see you started merging your theora branch :) [19:54:55] <DonDiego> Yuvi: or is this something else? [21:01:05] <elenril> J_Darnley: why did you add those two mappings to vorbiscomment conv table? [21:04:35] <J_Darnley> date-year because the vorbiscomment docs suggest date [21:05:07] <elenril> and the corresponding generic tag also happens to be date [21:05:13] <elenril> so no conversion is necessary [21:05:17] <elenril> same for artist [21:05:41] <J_Darnley> But if I use -metadata year=1982 nothing is converted [21:06:05] <elenril> because you're not supposed to use year [21:06:22] <J_Darnley> That won't stop people [21:06:23] <elenril> we don't have a year tag anymore [21:06:28] <elenril> blame bcoudrier [21:06:45] <elenril> i wanted to add a compatibility layer, but he didn't [21:07:11] <J_Darnley> And I did author-artist because sources seem to be conflicted about what to use [21:07:18] <Yuvi> DonDiego: yep [21:07:20] <elenril> huh? [21:07:21] <elenril> where [21:07:38] <J_Darnley> avformat.h and metadata_compat.c [21:08:05] <elenril> metadata_compat is legacy stuff [21:08:09] <J_Darnley> oh [21:08:23] <J_Darnley> (why is it still there) [21:08:26] <elenril> it will be removed on next lavf major bump [21:08:30] <elenril> for compatibility [21:08:34] <elenril> (as the name suggests =p ) [21:09:16] <J_Darnley> I will use that argument too, "it's for compatibility" [21:10:06] <elenril> adding the date<->year mapping would convert all 'date' tag demuxed from ogg files into 'year' generic tags [21:10:15] <elenril> but there is no year generic tag anymore [21:11:31] <elenril> s/anymore// [21:13:41] <J_Darnley> oh, that is a problem [21:16:17] <elenril> feel free to send a patch adding a compatibility layer if you think it's needed [21:16:39] * elenril doesn't feel like arguing with Baptiste over this [21:19:20] <J_Darnley> Is anything printed if sonone uses a not-recommended key? [21:19:25] <J_Darnley> *someone [21:19:57] <J_Darnley> Or will anything be printed? [21:20:05] <elenril> no [21:20:16] <elenril> all keys that aren't mapped to anything will be left as is [21:24:20] <DonDiego> Yuvi: is it merged completely already? [21:24:58] <Yuvi> DonDiego: nope, still a lot left [21:29:43] <DonDiego> do you have an eta? [21:36:19] <Yuvi> probably a week or two before most of it's merged [21:37:54] <DonDiego> excellent, so we will have it for 0.6 [21:38:01] <DonDiego> "works with html 5" :) [21:42:40] <Honoome> somebody got to send me the files of the design so I can get one shirt with that myself :P [21:42:52] <DonDiego> Yuvi: did you run any benchmarks with your latest version? [21:42:55] <DonDiego> Honoome: ask mru [21:43:03] <_av500_> mru might have some left... [21:43:21] <Yuvi> DonDiego: http://pastebin.com/m3916b277 [21:43:30] <Yuvi> that's BBB 1080p [21:43:55] <elenril> nice [21:47:31] <DonDiego> Yuvi: cool, that's considerably faster... [21:47:35] <DonDiego> congrats [21:51:37] <_av500_> so theora is good for html5 after all.. :) [21:52:32] <DonDiego> gnite [21:58:20] <iive> Yuvi: do you have blog? [22:10:36] <peloverde> Has anyone ever tried to patch gecko to use ffmpeg? [22:11:49] <ShadowJK> they're working on gstreamer I think.. [22:13:00] <peloverde> But gstreamer refuses to talk to our aac decoder and probably our theora decoder as well [22:16:26] <iive> are they really doing it? [22:18:31] <ShadowJK> https://bugzilla.mozilla.org/show_bug.cgi?id=422540 [22:19:36] <peloverde> wow blizzard seemed to be way against such ideas at FOSDEM [22:21:39] <Dark_Shikari> they will probably just make it only work with theora [22:23:36] <peloverde> They seem to be pushing fluendo h.264 [22:23:46] <peloverde> why do all these people like fluendo so much? [22:24:29] <Honoome> 'cause they have good PR? :P [22:24:54] <Dark_Shikari> peloverde: because they are pro-proprietary software [22:24:56] <Dark_Shikari> and anti-open source [22:25:06] <Dark_Shikari> and they have commandeered the "free software" movement to push proprietary solutions [22:26:03] <Honoome> Dark_Shikari: which is kinda silly … if it's a Free license it's bad because patented, but if it's a proprietary license, it's okay o_O [22:26:12] <Dark_Shikari> they don't care about patents [22:26:17] <Dark_Shikari> they're all about subverting free software [22:26:31] <Dark_Shikari> and promoting proprietary binary blobs on linux is a good way to do it. [22:26:51] <Honoome> Dark_Shikari: I meant the stance that a lot of zealots seem to take nowaday [22:26:52] <Dark_Shikari> moreso, they're also anti-ffmpeg [22:26:56] <Dark_Shikari> Honoome: yes, that's the point [22:27:00] <Dark_Shikari> the zealots are anti-free-software [22:27:03] <Dark_Shikari> they're pro-whatever-they-like [22:27:36] <Honoome> Dark_Shikari: I actually meant the same zealots that send me shit because I happen to like Mono [22:27:53] <Dark_Shikari> yes, mono is free software [22:28:38] <Dark_Shikari> the zealots would rather you use microsoft .net than mono. [22:30:05] <iive> actually i think RMS should have allowed distribution with patents and mandate that each user obtain license on its own. [22:30:22] <Dark_Shikari> that's how it already is [22:30:29] <Dark_Shikari> SFLC agrees [22:30:31] <Dark_Shikari> don't bother them about it [22:30:32] <Honoome> Dark_Shikari: actually, they'd rather use Flash than Mono :P [22:30:49] <Dark_Shikari> the zealots prefer microsoft .net to mono [22:30:51] <Dark_Shikari> Flash to Gnash [22:30:54] <iive> no, it's not mandated. [22:30:57] <Dark_Shikari> Silverlight to Moonlight [22:31:12] <Dark_Shikari> they are quite simply anti-free-software [22:31:20] <Honoome> I talk of different zealots here ;) [22:31:27] <Dark_Shikari> no, they're the same. [22:31:28] <iive> the point is, when all people start paying to some other people, they would start asking question, why i should pay them? [22:31:50] <Honoome> iive: “to have something better” is the answer they give themselves… [22:32:09] <Honoome> now of course… _sometimes_ that's true (*cough* openoffice sucks big time *cough*) [22:34:12] <iive> well, my point is to make visible the hidden cost of patents. [22:34:48] <iive> and let people think of patents not in term of how profitable it is, but how much they cost them. [22:35:24] <iive> on the other hand... nobody thinks this way for health insurance... so it may be bad plan. [22:36:33] <Honoome> iive: depends in which part of the world you live of course :D [22:50:23] <Yuvi> iive: no, I keep meaning to start one maybe sometime in the future [22:51:24] <iive> Yuvi: i've been urging people around to describe all theora shortcommings. So far I got only one big list with short descriptions. [22:52:21] * Honoome should really try to find the time to set up a Planet Multimedia or something >_< [22:52:42] <iive> Explaining this so people could understand it... entirely different task. And I'd be happy if I could not mess with theora. [22:53:51] <iive> My point. You can make description of all problems you had to solve in order to make theora faster. [22:54:55] <iive> And it would be good read, even if it doesn't try to smash theora into the dust. [22:56:00] <iive> usually it is better to don't have any smashing. [22:58:25] <peloverde> Not all the problems with theora are speed related [23:09:53] <iive> peloverde: i know

1 0

IRC log for 2010-02-12
by irc＠mansr.com 13 Feb '10

13 Feb '10

[00:00:39] <CIA-17> ffmpeg: mru * r21767 /trunk/configure: Add "tomi" architecture [00:09:00] <janneg> hmm, http://www.tomicpu.net/ is not that informative [00:09:48] <mru> heh, no it's not... [00:10:08] <mru> that patent is quite detailed though [00:12:33] <janneg> but a pain to read on a 3.7" screen [00:14:19] <mru> it's a pain to read on any screen [00:15:19] <mru> I have better docs [00:59:34] <iive> isn't it wonderful when you confess that you have read some patent on channel that is logged and archives are indexed by search engines. [01:08:58] <beandog> nobody can prove who was typing though [01:09:12] <beandog> not that I've thought these things through, or anything .. [01:33:48] <mru> those are patents on a cpu design [01:34:00] <mru> the owners hired me to do some work [01:34:11] <mru> everything is fine [01:38:45] <CIA-17> ffmpeg: michael * r21768 /trunk/libavformat/riff.c: Add GEOV fourcc (issue971). [02:02:34] <BBB> ok, so I fuzz'ed until it complained that it couldn't parse any frames anymore [02:02:39] <BBB> still no valgrind [02:02:41] <BBB> can I apply now? [02:31:16] <Compn> hehe [02:31:32] <BBB> damn you again :) [02:31:53] <Compn> is it... binary identical ? [02:32:08] <Compn> or 'bit-exact' as you people would say [02:33:54] <BBB> no [02:33:57] <BBB> postfilter is missing [02:34:03] <BBB> and several decoder bugs were fixed along the way [02:34:11] <BBB> apart from the binary bugs, it's bit-identical [02:34:17] <Compn> lol [02:34:23] <BBB> as in: it once was bit-identical, until I started fixing its bugs [02:34:26] <Compn> did you send your bug report to microsoft? :D [02:34:36] <BBB> I blog about them to publically ridicule ms [02:35:13] <BBB> if ms reads my blog, then they know about the bugs [02:35:22] <BBB> if they don't, well, yeah, then they don't know :) [03:48:12] <neo01124> hey! [03:48:35] <neo01124> where will i find demuxers in ffmpeg source? [03:49:28] <Dark_Shikari> libavformat [06:55:30] <siretart_> good morning! [06:57:20] <av500> gm [06:59:00] <kshishkov> as you say [07:06:04] <Dark_Shikari> siretart_: ping [07:07:13] <siretart_> Dark_Shikari: yes? [07:07:27] <siretart_> Dark_Shikari: I'm still awaiting your libx264.c patch for 0.5.1 :-) [07:07:35] <Dark_Shikari> that's what this is about [07:07:43] <Dark_Shikari> I'm nice, so I made it work with every libx264 up to the latest [07:07:51] <Dark_Shikari> and I minimized the ifdeffery [07:07:54] <siretart_> wow [07:07:56] <Dark_Shikari> and actually made clean code [07:08:21] * thresh pokes Dark_Shikari to push fixes [07:08:23] <Dark_Shikari> however, I will need you to test it [07:08:33] <siretart_> ok, will do [07:08:37] <Dark_Shikari> I assume you can do that ? :) [07:08:56] <siretart_> I can testcompile it against both x264 in ubuntu and an updated snapshot [07:09:14] <siretart_> but I'm not that interested in testing each and every intermediate version [07:09:20] <Dark_Shikari> I can give you the hashes of each to test [07:09:24] <Dark_Shikari> there's only about 5. [07:09:29] <siretart_> okay [07:09:44] <siretart_> can you please post the hashes and the patch to ffmpeg-devel@? [07:09:55] <siretart_> prefix the subject with [PATCH][0.5], so that I can easily find that [07:09:57] <Dark_Shikari> not done yet [07:10:12] <Dark_Shikari> also, I may have fucked up, so I'll give it to you on IRC first ;) [07:10:30] <Dark_Shikari> also, I'm on Windows, so configuring is so slow here that you could finish all the tests in the time it takes to configure ffmpeg [07:10:47] <siretart_> okay, but I'm now hurrying to work and will be stuck in meeting half of the day today (damn, it's friday...) [07:10:54] <Dark_Shikari> heh [07:13:08] <siretart_> okay, bbl! [07:17:34] <Dark_Shikari> 1) patch http://pastebin.com/m4fee05f6 [07:19:14] <Dark_Shikari> 2) x264 revisions to test: http://pastebin.com/m61a71336 [07:19:16] <Dark_Shikari> siretart_: ^ [07:21:28] <Dark_Shikari> ping me when you're back. [07:47:00] <kshishkov> Compn: you around? [07:52:29] <Dark_Shikari> oh wait, siretart_, I forgot the defaults from the cmdutils or whatever. [07:54:02] <Dark_Shikari> http://pastebin.com/m62729da updated patch [08:07:46] <siretart> Dark_Shikari: I've mailed me that patch now and will look at it probably this afternoon. from the very first look, I spotted some spurious cosmetic only changes [08:08:20] <siretart> I need to do regression tests with ubuntu's current libx264 [08:08:39] <Dark_Shikari> it's not spurious [08:08:44] <Dark_Shikari> the intention is to update the libx264.c to the latest libx264.c [08:08:49] <Dark_Shikari> and then backport support for all previous x264s [08:08:58] <Dark_Shikari> in other words, it's a whole-file replacement [08:10:16] <siretart> oh, I see. OTW, it is not a patch but a replacement. [08:10:33] <Dark_Shikari> yes [08:10:38] <Dark_Shikari> though it's really neither [08:10:46] <Dark_Shikari> I tried to make the new file as simple as possible [08:10:51] <Dark_Shikari> i.e. as few ifdeffed code sections as necessary [08:11:32] <siretart> what about having these ifdef's in trunk, maybe only until the 0.6 branch opens? [08:11:41] <Dark_Shikari> no [08:11:50] <Dark_Shikari> we don't do this for any other codec [08:11:53] <Dark_Shikari> why do it for x264? [08:11:57] <Dark_Shikari> and for that matter [08:12:00] <Dark_Shikari> why aren't you whining about theora? [08:12:07] <Dark_Shikari> ffmpeg broke API to support theora 1.1 [08:12:12] <Dark_Shikari> theora 1.0 will no longer work with new ffmpeg [08:12:17] <Dark_Shikari> and theora 1.1 won't work with old ffmpeg and so forth [08:12:24] <Dark_Shikari> nobody has asked to ifdef that [08:13:51] <siretart> you claim that ffmpeg 0.5 didn't compile against libtheora 1.1? interesting that I didn't notice that [08:13:58] <Dark_Shikari> I thought it was [08:14:01] <Dark_Shikari> or maybe it's the other way around [08:14:04] <Dark_Shikari> i.e. 1.1 is backwards compatible [08:14:08] <Dark_Shikari> but you dont' get the new features without the api break [08:14:11] <Dark_Shikari> like 2-pass [08:14:45] <siretart> anyway, my idea was probably just a brainfart [08:14:57] <Dark_Shikari> we don't really do that kind of ifdeffing in trunk [08:15:02] <Dark_Shikari> otherwise you get VLC [08:15:10] <Dark_Shikari> have you even seen the x264 module in VLC? it's insnae [08:15:14] <Dark_Shikari> it tries to work with x264 back to 2005 [08:15:19] <Dark_Shikari> it has more ifdefs than lines of code [08:15:43] <siretart> still, we now have a rather non-trivial change proposed against ffmpeg 0.5, which diego and I will consider [08:15:59] <siretart> no promises, though [08:16:05] <Dark_Shikari> I did this for you [08:16:09] <Dark_Shikari> if you want to reject it, I lose nothing [08:16:34] <siretart> well, distros loose the oppurtunity to update x264 [08:16:44] <siretart> which I would find rather sad [08:16:55] <Dark_Shikari> I know. You care about that, so you will get this committed [08:17:03] <Dark_Shikari> and if you don't, you can patch ffmpeg in the distro packages. [08:17:13] <siretart> as said, I need to do regression tests [08:17:24] <Dark_Shikari> yes of course [08:17:31] <Dark_Shikari> test those revisions, both for compilation and encoding [08:43:48] <KotH> moin [08:44:11] <av500> grüezi wohl [08:44:40] <kshishkov> god morgon [09:00:04] <osaft> habe die ehre [09:00:35] <kshishkov> wir habt [10:04:26] <kshishkov> mate! [10:07:28] <KotH> club mate? [10:08:28] <kshishkov> no, just Australian cobber ;) [10:11:54] <pross-au> Hi [10:34:10] <kshishkov> pross-au: I'd like to integrate your BIKb decoder [10:52:53] <pross-au> ok [10:53:14] <pross-au> its 20% complete [10:53:25] <kshishkov> my decoder seems not to handle BIKb at all [10:53:34] <pross-au> yeah, its a rare beast [10:53:51] <pross-au> do you have samples? [10:53:52] <kshishkov> fould old Heroes of Might and Magic III disc [10:53:58] <pross-au> Ah [10:54:25] <pross-au> That's the only game that I am aware of [10:54:35] <pross-au> (and there is no sound IIRC in the BIKb files) [10:55:32] <kshishkov> well, your demuxer reports sound (but your decoder can't handle it though) [10:58:15] <kshishkov> (if lavc decoder would also support BIKb, that will be a big "take this!" to RAD tools) [10:58:46] <pross-au> Not even the current RAD Tools support BIKb [10:59:15] <pross-au> It must be the ugly duckling of the BINK clan :D [10:59:16] <kshishkov> exactly [10:59:32] <kshishkov> no, just too outdated [10:59:35] <pross-au> I mean to say, the HOMM3 bik files do no contain audio [10:59:37] <pross-au> *not [11:00:13] <kshishkov> of all 4 biks in there only one does not contain audio [11:00:23] <kshishkov> the rest at least should [11:01:07] <kshishkov> for example, NWCLOGO.BIK: Stream #0.1: Audio: binkaudio_rdft, 22050 Hz, 2 channels, s16 [11:03:45] <pross-au> Oh cool [11:03:50] <pross-au> Maybe i only have the HOMM3 demo [11:14:07] * kshishkov curses for his code to draw pattern block in Bink hath coordinates swapped [11:15:54] <jez9999> question: getaddrinfo() provides a struct sockaddr * to describe the address it's parsed. how does this fit in with sockaddr_storage, which is larger? [11:17:32] <kshishkov> you can fit smaller thing into bigger thing, what's the problem? [11:17:55] <jez9999> how does it return an ipv6 addy? i thought the whole idea of the storage struct was that it could hold ipv65 [11:17:57] <jez9999> *6 [11:19:02] <kshishkov> maybe you can treat it as a union [11:19:50] <pross-au> getaddrinfo() returns a pointer to 'something' [11:21:09] <jez9999> manpages say struct sockaddr* [11:21:34] <kshishkov> first two fields are common to all sockaddr_ structs [11:21:45] <jez9999> so you're saying to cast it [11:21:54] <kshishkov> the rest can be parsed from memory by those ss_len and ss_family [11:22:01] <kshishkov> yes [11:22:12] <kshishkov> you have ss_len which tells you real size [11:22:28] <kshishkov> and ss_family gives you real struct type as well [11:22:54] <jez9999> i dont understand why _storage has to exist at all then [11:22:58] <kshishkov> so just recast returned pointer to another struct pointer type, that's all [11:23:00] <jez9999> why not just use a struct sockaddr* [11:23:49] <kshishkov> because it defines maximum sockaddr* size [11:24:00] <twnqx> mmhh [11:24:29] <jez9999> but i don't want to cast to it [11:24:35] <jez9999> i want to cast to something like sockaddr_in [11:24:49] <kshishkov> as you like [11:24:57] <jez9999> so.... i'm never actually gonna use _storage [11:25:08] <kshishkov> could be so [11:25:14] <jez9999> so what's the point in it [11:25:18] <kshishkov> at least I've not [11:25:19] <jez9999> when would you need to practically use it? [11:26:18] <kshishkov> when you work with different sockaddr and need to pass it explicitly, not pointer [11:30:52] <jez9999> c#'s so much easier :-) [11:31:25] <kshishkov> now guess why most developers here are not so fond of C#, Java or similar? [11:32:29] <CIA-17> ffmpeg: pross * r21769 /trunk/libavformat/anm.c: Make DeluxePaint Animation demuxer actually return the find_record() error code (issue 1739). [11:32:38] <Dark_Shikari> kshishkov: http://www.chunder.com/text/ididit.html ;) [11:33:52] <pross-au> Nice Dark_Shikari [11:34:01] <kshishkov> Dark_Shikari: my favourite is where C claimed to be a joke [11:34:33] <kshishkov> http://www-users.cs.york.ac.uk/susan/joke/c.htm [11:37:41] <kshishkov> Dark_Shikari: I know you'll love it - Bink idct_add is not clamped [11:38:04] <Dark_Shikari> yup, just like VP8 [11:38:09] <Dark_Shikari> designed for shit systems with no saturating math [11:38:20] <Dark_Shikari> e.g. systems without simd [11:38:27] <kshishkov> no, Because Clamping Takes Cycles! [11:38:43] <kshishkov> and yes, it was designed for all kinds of systems [11:38:58] <pross-au> VP8 is the Duke Nukem Forever of video coding :D [11:39:13] <Honoome> pross-au: I thought snow was that already [11:39:19] <pross-au> or should that be: VP(n+1) [11:39:24] <kshishkov> pross-au: no, that's x264 [11:39:37] <pross-au> Haha [11:39:45] <Dark_Shikari> but x264 exists [11:39:51] <Honoome> so we basically have so many candidates… [11:39:57] <kshishkov> wake me up when it reaches 1.0 [11:40:12] * pross-au is waiting for x264-mvc [11:41:10] <Dark_Shikari> kshishkov: we're at 84.0 [11:41:14] <Dark_Shikari> 85.0 will come out in the next release [11:41:40] <kshishkov> ah, point taken [11:42:11] <bilboed-pi> Dark_Shikari, *awesome* link ! [11:42:13] * kshishkov moves x264 into "versions crazier than Emacs" category [11:43:30] <Honoome> kshishkov, for the *crazy* versions you should look at tex [11:43:57] <kshishkov> Honoome: _that_ is sane even if a bit transcedental [11:44:53] <pross-au> The world needs x264-mvc for making Avatar 3D backups [11:45:12] <Honoome> kshishkov, I'd say that its sanity is opinable [11:45:22] <kshishkov> pross-au: your sentence lacks several other popular buzzwords [11:45:28] <Dark_Shikari> pross-au: you don't need mvc [11:45:35] <Dark_Shikari> there's an SEI for that [11:45:42] <Dark_Shikari> you just stick the two views next to each other [11:45:47] <Dark_Shikari> encode at 1920x2160 [11:45:51] <Dark_Shikari> er, on top of each other [11:45:55] <kshishkov> Honoome: next thing you'd tell me that Lewis Carrol was not sane [11:46:01] <pross-au> Great [11:46:10] <Dark_Shikari> and you stick in the SEI [11:46:16] <Dark_Shikari> we could add support if anyone ends up supporting the sei [11:46:28] <kshishkov> I saw several stereoscopic movies encoded with WMV3 [11:53:42] <pross-au> Do we have a way of decoding such streams with FFmpeg? [11:54:46] <kshishkov> of course, they are just two pictures in one frame [11:56:05] <kshishkov> do you think I'd watch it with decoder by somebody else? [11:56:19] <pross-au> the SEI flags are reported back through AVCodecContext [11:56:20] <pross-au> ? [11:56:37] <kshishkov> unlikely [11:57:42] <pross-au> we have interlacing info reported back, so the same would be required for 3d [11:57:53] <pross-au> or more generically, multi-view. [12:02:16] <kshishkov> yep, 5-field video accompanied with 9.3 audio [12:04:41] <pross-au> That was be awesome for sports [12:04:48] <pross-au> *would be [12:04:59] * kshishkov has not interest in sports [12:05:11] <kshishkov> not even in cricket [12:05:12] <pross-au> Not even Australian Rules Football (AFL) ? [12:06:10] <kshishkov> of course not [12:06:19] <jai> you mean rugby? [12:06:43] <pross-au> jai: nope [12:06:46] <kshishkov> the only good thing in AFL is that it's not shown here and has not much fans here either [12:06:47] <jai> hmm [12:07:17] <pross-au> jai: it is unlike anything you've probably seen before [12:08:04] * KotH wonders whether australian rules allow the use of weapons [12:08:45] <jai> pross-au: i guess :) [12:36:04] <merbzt> http://www.youtube.com/watch?v=mkaeU-8b2jE [12:37:07] <kshishkov> not very original [12:38:08] <kshishkov> there was a similar Russian dub focused on the fact Russian 2G providers tried to butcher Skype [12:41:23] <merbzt> the funny part is that it is true [12:46:30] <kshishkov> indeed [12:47:23] <merbzt> http://www.youtube.com/watch?v=_K9AxO5t4BE [12:49:12] <kshishkov> Bollywood Action Film #1 ? [12:49:27] <twnqx> i know that the company where i currently sits tries to block skype's voicecalls, too [12:49:33] <twnqx> sit* [12:52:07] <iive> btw, isn't it better to code 3D movies as interlaced? [12:52:27] <KotH> instead of? [12:52:37] <KotH> twnqx: uhmm.. are tehy allowed to do that? [12:52:50] <iive> i mean, left picture as top field, right picture as bottom field [12:52:53] <pross-au> interlaced mvc haha [12:53:11] <twnqx> KotH: the contract explicitly says "no voice over ip of any kind" [12:53:35] <iive> instead of 2 separate pictures on the screen. it should allow to compensate from the other picture without need for huge vectors. [12:54:33] <KotH> twnqx: the contract can say a lot of things, but still, are they allowed? [12:54:50] <twnqx> it wasn't tried in court yet [12:55:00] <twnqx> but iguess they have a legal department to sort that out [12:55:03] <KotH> twnqx: afaik in .ch no telco carrier is allowed to restrict access to the net in any kind unless absolutely necessary for the working of the network [12:55:13] <KotH> lol [12:55:32] <KotH> half of the contracts we get in .ch contain stuff that are not legally allowed [12:55:45] <KotH> most of them made by large, multinational companies [12:56:35] <KotH> heck, even my work contract contains passages that contradict the law [12:57:22] <twnqx> :P [13:00:12] <KotH> hoi DonDiego [13:00:50] <av500> hey DonDiego [13:00:57] <DonDiego> heyho [13:01:13] <DonDiego> say, have you guys talked to the rockbox people at fosdem? [13:01:19] <av500> yes [13:01:27] <av500> alex has [13:01:39] <av500> and they are here a couple of days ago [13:01:41] <av500> were [13:03:10] <DonDiego> yes, that's why i'm asking.. [13:03:14] <DonDiego> good :) [13:03:25] <DonDiego> let's see if we get some results from this, i sure hope so.. [13:03:49] <av500> there is a thread on their devel ml [13:04:15] <av500> http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-02/0019.shtml [13:43:57] <Compn> kshishkov :? [13:45:03] <kshishkov> Compn: nevermind [13:45:17] * kshishkov has compiled MPlayer with Bink audio and video support [13:45:41] <Compn> what will the bink guy say?! :) [13:46:11] <Dark_Shikari> do remember the various versions of bink for different arches ;) [13:47:29] <kshishkov> mine runs on MacOSX/PPC [14:19:28] <kshishkov> BBB: why wmavoice is not in main SVN yet? [14:19:42] <BBB> I said I' dapply today [14:19:45] <BBB> so I'll apply now [14:19:52] <BBB> people wanted me to run zzuf on it [14:19:59] <BBB> and see if it crashes [14:20:06] <DonDiego> BBB: don't forget to: [14:20:06] <kshishkov> you did. it didn't [14:20:15] <DonDiego> proprietary_codecs--; [14:20:28] <BBB> DonDiego, which header is that variable in? [14:20:49] <kshishkov> probably multimedia wiki category [14:22:16] <DonDiego> BBB: it's a global variable [14:22:23] <DonDiego> and i mean *global* [14:22:27] <BBB> :) [14:22:37] <DonDiego> as in planet-wide [14:22:38] <DonDiego> :) [14:22:53] <BBB> oh right I should remove it from the undiscovered codecs page on the wiki [14:24:03] <CIA-17> ffmpeg: rbultje * r21770 /trunk/ (8 files in 3 dirs): WMAVoice decoder. [14:24:21] <BBB> better? [14:24:49] * kshishkov waits for mail [14:24:52] <Dark_Shikari> oh nice. [14:25:25] <Dark_Shikari> BBB: now we can bug you to do WVP2 [14:25:38] <kshishkov> hear! hear! [14:25:41] <jez9999> BBB: morning [14:25:46] <Compn> so is it a feature that lavf bails when it cant recognize a fourcc ? [14:26:02] <BBB> Dark_Shikari, I'm first working on the postfilter [14:26:05] <Dark_Shikari> k [14:26:09] <BBB> I did some wor yesterady [14:26:13] <BBB> won't take too long [14:26:14] <kshishkov> Compn: it does not, framecopy works [14:26:15] <BBB> I sort of get it now [14:26:19] <mru> Compn: what would you have it do? [14:26:28] <Compn> kshishkov : must be mplayer problem then [14:26:37] <superdump> BBB: is it at all similar to the AMR and QCELP post filters? [14:26:40] <jez9999> BBB: kindly check out patch3 for issue 1740, i addressed problems you raised [14:27:29] <Compn> Playing geov.avi. [14:27:29] <Compn> libavformat file format detected. [14:27:29] <Compn> [avi @ 0p1d58010]Could not find codec parameters (Video: GEOV / 0x564F4547, 720x240) [14:27:29] <Compn> LAVF_header: av_find_stream_info() failed [14:28:29] <Compn> yeah probably mplayer problem using lavf hmmmmm [14:29:04] <kshishkov> Compn: should be cured by "svn up libavformat/riff.c" [14:29:13] <Compn> yes that particular problem should be [14:29:20] <Compn> but i am speaking generally :) [14:29:27] <Compn> michael didnt close that bug on roundup [14:29:30] <Compn> thanks for reminding me [14:29:39] <mru> http://img.thedailywtf.com/images/201002/errord/errory.png [14:30:02] <av500> a tiff exploit :) [14:30:26] <BBB> jez9999, yes, will do [14:30:39] <DonDiego> mru: rotfl :-) [14:31:07] <BBB> superdump, it's similar, they all use tilt correction, but the WMAVoice one is a little more extended from what I could see... it's huge, probably the biggest part of the decoder (hence me skipping it :) ) [14:31:12] <kshishkov> av500: easier than you think [14:31:20] <Compn> mru : just pass the fourcc onto the application for it to handle? [14:31:37] <kshishkov> BBB: it's not rv40, so the codec should work fine even without it [14:31:59] <mru> Compn: what a ridiculous thing to do [14:32:14] <BBB> kshishkov, it works fine without [14:32:23] <BBB> just a little bit of clipping here and there [14:32:39] <Compn> mru : in most cases for avi , the video codec doesnt require any more parsing... [14:32:48] <mru> oh god.... [14:32:51] <Compn> heh [14:32:54] <mru> the world is not made of avi [14:32:54] <kshishkov> Compn: you have Matroska [14:33:40] <kshishkov> why it's so hard to make codec handling in container independent on codec type? [14:33:58] <Compn> padding ? [14:34:15] <Compn> timestamps ? [14:34:35] <av500> granule [14:34:57] <kshishkov> ogg to you too [14:38:45] <lu_zero> BBB: did you ever try to issue ffmpeg -i rtsp://some/valid/url ? [14:39:15] <BBB> I only use ffplay, to be honest [14:39:18] <BBB> why, doesn't it work? [14:40:05] <lu_zero> it has a fun behaviour when you forget a / [14:40:21] * lu_zero is messing a bit with ffmpeg and feng eventually [14:40:41] <mru> kshishkov: it's not hard [14:40:50] <mru> but there is no standard on codec identifiers [14:40:58] <DonDiego> BBB: don't listen to the italian please! [14:41:02] <mru> or there are several [14:41:21] <DonDiego> wherever you have to go with him, make sure you know the way yourself! [14:41:22] <lu_zero> hi DonDiego =P [14:41:23] <mru> the mpeg registration descriptor is standard of course [14:41:26] <BBB> lu_zero, I thought I fixed that? [14:41:34] <DonDiego> lu_zero: ;-p [14:41:36] <BBB> lu_zero, earlier, I applied a patch to add the '/' when missing [14:41:41] <BBB> lu_zero, are you using latest svn? [14:41:43] <lu_zero> BBB: it works it's just funny [14:41:50] <lu_zero> let me sync [14:41:55] <lu_zero> it's 2-3 days ago [14:41:58] <BBB> what's the fun bejaviour? [14:42:06] <BBB> s/j/h/ [14:42:18] <Compn> mru : what about continuing when audio is known and just drop video stream ? [14:42:41] <bilboed-pi> BBB, congrats on getting wmavoice in [14:42:45] <mru> Compn: you can do that [14:42:48] <BBB> bilboed-pi, ty [14:42:49] <Compn> bilboed-pi : we tried to stop him :D [14:42:50] <mru> might need -vn [14:42:52] <lu_zero> rtsp:/path/to/resource gets feed as /path/path/to/resource [14:42:53] <bilboed-pi> Compn, :) [14:43:01] <mru> lavf doesn't care [14:43:14] <Kovensky> mru: http://esr.ibiblio.org/?p=1694 :D [14:43:38] <Compn> mru : ok, then probably hitting mplayer bug [14:44:20] <lu_zero> btw [14:44:26] <lu_zero> how was the troll beer? [14:44:36] <BBB> lu_zero, really? [14:44:49] <BBB> lu_zero, that sounds like a bug [14:44:55] <BBB> lu_zero, does it work? [14:44:56] <lu_zero> BBB: I was wondering [14:45:02] <lu_zero> rtsp:// works correctly [14:45:23] <BBB> submit an issue on roundup, probably a silly bug somewhere [14:47:13] <lu_zero> where is the code for parsing uris and how did you touch it? [14:47:50] <BBB> is this the time where I run away trying to stay alive? [14:48:03] <BBB> I think it's control uri parsing [14:49:00] <lu_zero> sigh [14:49:05] * lu_zero got preempted again [14:49:24] <lu_zero> anyway it should just error out if you feed rtsp:/ instead of // [14:55:24] <Compn> that it should [14:56:50] <Compn> mru : oops, it was my fault, lavf does pass the fourcc to mplayer, just the audio was broken too [14:56:54] <Compn> so it passed nothing :) [14:57:27] <Kovensky> Compn: btw, does ffmpeg://http:// work for you (on mplayer)? [14:57:31] <Kovensky> or whatever other protocols [15:00:22] <DonDiego> one quick user question: is it possible to pass mp3lame-specific params to ffmpeg, e.g. --preset normal? [15:00:38] <DonDiego> i find no hint in libavcodec/libmp3lame.c [15:00:52] <Compn> Kovensky : lets take this to #mplayer.. [15:04:02] <superdump> BBB: you're the rtsp person aren't you? well, and luca abeni [15:04:04] <superdump> rtsp://video2.multicasttech.com/AFTVSciFiH2641000.sdp [15:04:07] <superdump> have fun with that [15:05:30] <BBB> works for me? [15:06:16] <Compn> outputs 56 bytes and then dies with mplayer [15:06:17] <Compn> rtsptext [15:06:17] <Compn> rtsp://63.105.122.35:80/AFTVSciFiH2641000.sdp [15:07:09] <BBB> that's because mplayer's rtsp stack sucks [15:07:13] <BBB> works fine for me [15:07:15] * BBB ducks [15:08:30] <BBB> superdump, how long is that? :) [15:08:46] <BBB> btw the sync is bad, I think it's because it's h264, waiting for that fix luca and I were discussing on the mailinglist [15:08:47] <bilboed-pi> it's a live stream [15:08:51] <BBB> lu_zero: can you apply? [15:09:09] <superdump> BBB: works fine for you? [15:09:15] <BBB> it's live? [15:09:18] <BBB> it's an old movie! [15:09:18] <superdump> i'm using trunk ffmpeg and ffplay doesn't play anything [15:09:21] <superdump> it just sits there [15:09:34] <BBB> I'm forcing tcp, that may be why [15:09:34] <bilboed-pi> BBB, it's a tv station, that's what I meant [15:09:41] <BBB> bilboed-pi, oh, ok [15:09:43] <BBB> that makes sense [15:09:49] <BBB> superdump, try forcing tcp [15:10:01] <BBB> add ?tcp at the end [15:11:13] <Compn> lol live-old-movie [15:11:13] <Compn> :D [15:13:06] <BBB> I'm assuming that means it works for you :) [15:13:07] <BBB> \o/ [15:13:12] <BBB> let's work on the postfilter then [15:13:36] <bilboed-pi> shouldn't it figure out it should switch to tcp though ? [15:14:28] <BBB> martin has patches that lead there [15:14:32] <BBB> so that'll land [15:14:47] <BBB> (so yes) [15:16:02] <DonDiego> yv: so you remembered your nickserv pw? [15:16:04] <DonDiego> :) [15:16:25] <DonDiego> fellow fosdem visitors, say hello to yvonne.. [15:16:54] <yv> hey everybody :) [15:17:25] <mru> yv: hi [15:18:27] <av500> yv: hi [15:18:32] <av500> err, hello [15:18:41] <mru> there's a difference? [15:18:55] <av500> [16:16] <DonDiego> fellow fosdem visitors, say *hello* to yvonne.. [15:19:15] <mru> I would've assumed any synonym would do [15:19:54] <av500> yv: hallo [15:20:21] <DonDiego> av500: this somehow reminds me, where does your nickname come from? [15:20:57] <av500> its my root pwd :) [15:21:43] * av500 sees incomming traffic spike [15:22:18] <av500> DonDiego: it is one of our earlier product names [15:22:34] <mru> so you're an old model? [15:22:38] <av500> yes [15:23:04] <Compn> still under warantee? [15:23:21] <av500> voided that one long ago [15:23:36] <Compn> ack , cant spell [15:24:02] <mru> removed the sticker? [15:33:24] <av500> which of the 3 ways to specify aspect ratio in mp4 is considered the authorative? [15:33:53] <kshishkov> the one written in standard in less ambiguous way [15:35:43] * av500 sighs [15:42:13] <mru> reynaldo: http://www.theregister.co.uk/2010/02/12/chiiean_mint/ [15:45:35] <BBB> does anyone know what the meaning of applying lpcs to the synthesized speech samples is in voice codecs? [15:45:55] <kshishkov> to make it sound more realistic? [15:46:04] <BBB> like applying lpcs to the excitation signal is "speech synthesis", what happens if you apply the lpcs again to the speech synthesis? [15:46:11] <ohsix> smooth out discontinuities? [15:46:23] <BBB> hmm... [15:46:42] <mru> is that what politicians use? [15:47:30] <kshishkov> no, they simply shape noise [15:47:46] <ohsix> like fox news [15:49:12] * kshishkov thinks they should have named original company "XX century weasel" in the first place [15:50:00] * av500 watches http://hci.rwth-aachen.de/~jansen/swords.mov [15:51:30] * kshishkov watches "Monkey Dust" series [15:52:24] <BBB> seems a smoothening method indeed [15:52:29] <BBB> weird [15:53:25] <kshishkov> sounds like an analog of LTP [15:53:59] <BBB> long-term potentiation? [15:54:16] <BBB> the math is identical to speech synthesis, which is funny [15:54:23] <BBB> why would they write two functions doing the exact same thing? [15:54:43] <kshishkov> long-term prediction, you know - an additional MDCT in AAC for example [15:54:47] <BBB> the only difference is that one caches its own history through a copy to internal buffers, whereas the other uses the external buffer for history caching [15:55:08] <kshishkov> BBB: look at fspp filter in MPlayer [15:55:51] <kshishkov> applying two functions out of phase sorta cancels edge artifacts [15:57:28] * jez9999 is about to go home from work [15:57:52] <BBB> jez9999, I [15:58:01] <BBB> jez9999, I'll review the patch, but not right now yet [15:58:19] <BBB> actually, let me do it right now [15:58:21] <BBB> better that way [15:58:48] <kshishkov> BBB: if you have another codec patch, I'll review it. Especially WM-based ;) [15:59:18] <BBB> yeahyeahyeah, I'll do wvp2 if no soc student shows up [15:59:50] <kshishkov> :) [15:59:57] <kshishkov> WMAL? [16:01:53] <BBB> I thought jai was doing that [16:01:55] <BBB> I could, though [16:02:03] <BBB> I have the whole thing setup already [16:02:08] <BBB> same binary [16:04:02] <jez9999> BBB: thanks, i'll address those points soon [16:04:03] * kshishkov wants something to debug WMV decoding dll [16:04:16] * pJok hands kshishkov a hammer [16:04:32] <kshishkov> you can't hit dll with a hammer :( [16:04:48] <pJok> not directly, no [16:04:49] <kshishkov> otherwise I would have used it [16:04:54] <pJok> but you can debug things with a hammer [16:06:27] * kshishkov would like to debug WMV creators with a hammer [16:14:28] <Compn> so does wvp2 store the text in text or bitmaps or just combine them together crazily ? [16:14:46] <kshishkov> who knows? Probably bitmaps [16:15:09] <kshishkov> and it's not vector either [16:23:50] <astrange> BBB: do you know if flip4mac has a noisy wmavoice decoder? [16:24:08] <astrange> i always wondered if they used ms code [16:26:29] <kshishkov> they did [16:26:42] <DonDiego> av500: haha, the swords one is funny.. :) [16:26:47] <kshishkov> same as Linspire [16:27:17] <kshishkov> IIRC, there are only two independent decoders for Windows Media - FFmpeg and M$ [16:27:54] <av500> kshishkov: for x86 maybe [16:28:19] <kshishkov> Linspire used their source for pocketpc version [16:28:34] <av500> DonDiego: beats the usual "chicks with guns" vids :) [16:28:58] <kshishkov> av500: Windows Mobile plays .wmv on ARM after all... [16:29:32] <reynaldo> mru: good one. Didn't know about it. will see if I can find one :) [16:29:37] <DonDiego> av500: lol :) [16:36:57] <BBB> astrange, they don't have any [16:37:05] <BBB> astrange, see their website [16:38:29] <kshishkov> BBB: flip4mac features are presented at microsoft.com [16:39:10] <BBB> http://www.telestream.net/flip4mac-wmv/tech-specs.htm - bottom [16:39:24] <BBB> "Unsupported codecs: [..] voice [..]" [16:39:29] <kshishkov> http://www.microsoft.com/windows/windowsmedia/player/wmcomponents.mspx [16:39:48] <kshishkov> from some link at flip4mac.com [16:40:09] <BBB> right, so as you can see, no voice/speech [16:40:27] <kshishkov> nor MSS[12] or WMVP/WVP2 [16:40:32] <BBB> right [16:40:41] <BBB> also on that tech-specs page I just pasted [16:40:43] <BBB> unsupported: [16:40:47] <BBB> * Screen (ACELP.net) [16:40:48] <BBB> * Image [16:40:48] <BBB> * Voice [16:40:48] <BBB> * Direct Show AC3 Filter [16:40:48] <BBB> * GoToMeeting (G2M) [16:40:48] <BBB> * GoToWebinar [16:41:04] <kshishkov> WTF is the first one?!?! [16:41:56] <BBB> I dunno, it sounds like a maerge between sipro anc svp2 [16:41:59] <BBB> er, wvp2 [16:42:07] <BBB> maybe it's so complex they couldn't imlpement it [16:42:28] <kshishkov> maybe it reconds screen to speech? [16:42:52] <kshishkov> I'm pretty sure they used the same code as Linspire [16:44:21] <BBB> I have a lossless codec impl, might look into that also if jai doesn't [16:45:47] <BBB> first postfilter though [16:45:52] <BBB> it doesn't look too complicated [16:45:58] <BBB> lots of memory duplication [16:46:09] <BBB> I think the postfilter was developed separately from the codec [16:46:11] <BBB> looks horrible [16:46:28] <BBB> private memory caches for every variable, etc. [16:55:02] <kshishkov> copy-pasted from somewhere else, I think [17:00:22] <av500> mru: android switches from gcc to llvm [17:00:53] <kshishkov> av500: still better than javac [17:00:59] <mru> I still haven't figured out how to build an llvm arm cross-compiler [17:01:09] <av500> wait for gg to release one :) [17:01:47] <mru> and I'm not going to fuck around with svn checkouts that may or may not work at all [17:02:17] <peloverde> ahh, what we ask others to do [17:02:42] <kshishkov> peloverde: FFmpeg is much easier to compile [17:02:45] <mru> the difference is that our svn usually works fine [17:02:53] <av500> peloverde: we do releases now, no? :) [17:02:55] <peloverde> VP6 has been broken for quite a while now [17:03:07] <mru> and building it doesn't involve combining a dozen pieces that usually don't fit [17:04:02] * kshishkov once tried compiling Firefox on Celeron-800, 256MB RAM, ~GB free HDD [17:05:33] <av500> kshishkov: still compiling? [17:05:52] <kshishkov> av500: of course not, it ran out of disk space pretty soon [17:06:18] <kshishkov> maybe producing five copies of each component during making is not a good idea [17:07:30] <jai> llvm-svn targeted for x86 seems to work pretty decently [17:07:33] <jai> fwiw [17:07:49] <jai> (i update twice a week, no problems so far) [17:08:18] <mru> my only attempt at configuring an arm compiler still only compiled to x86 [17:08:36] <kshishkov> jai: so you update right after it finished compiling? [17:09:04] <jai> kshishkov: the compile times are quite okay, < 10mins on a core2 [17:09:20] <jai> that includes clang as well [17:09:30] <kshishkov> what is core2? [17:09:44] <mru> one more than core1 [17:09:50] <av500> jai: I can imagine that gg sits on a shitload of patches for llvm that will magically appear soon [17:10:14] <merbzt> gg ? [17:10:14] <jai> core2 duo @ 2Ghz to be precise :) [17:10:20] <av500> google [17:10:33] <av500> [18:00] <av500> mru: android switches from gcc to llvm [17:11:06] <jai> av500: hmm, well if they did have a patchset, the very least they could do is publish it somewhere [17:11:08] <kshishkov> jai: and I don't have _anything_ > 1.5GHz. And nothing x86 >= 1GHz [17:11:37] <av500> jai: yes, they will, but they like to develop for themselves and then drop it all in one [17:11:56] <jai> av500: yep, seen them do that with webkit before [17:12:07] <av500> they are "open", but not more than needed :) [17:12:15] <peloverde> I projects people that do big code dumps like that [17:13:00] <__gb__> kshishkov, what non x86 is > 1 GHz? Some newe Godson 2g or 3? :) [17:13:03] <av500> I guess they dont want to give a hint what they work on... [17:13:18] <av500> __gb__: snapdragon is 1.5 [17:13:55] <kshishkov> __gb__: 1.42GHz PowerPC of course [17:14:32] <jai> we can assign all the endianness issues on roundup to kshishkov ;) [17:14:45] <__gb__> kshishkov, all, all G4 :) [17:14:55] <__gb__> s/all/old/ [17:15:15] <av500> err, ps3 or xbox has >1 ghz powerpc, no? [17:15:24] <kshishkov> jai: you have mru for that [17:16:09] <kshishkov> __gb__: the only state of the art CPU I have is Loongson 2F. Too bad that art is Chinese. [17:16:11] * mru has a ppc g4 available to all ffmpeg devs [17:16:23] <mru> chinese state art... [17:16:31] <Honoome> haha :) [17:16:39] <DonDiego> peloverde: what about vp6? [17:16:44] <jai> kshishkov: loongson based netbook? [17:17:02] <kshishkov> jai: yes, that Gdium I occasionally mention [17:17:09] <jai> kshishkov: ah, ok [17:17:18] <kshishkov> DonDiego: it segfaults of some platforms - see FATE [17:19:34] <DonDiego> bah [17:20:28] <DonDiego> bye [18:19:28] <CIA-17> ffmpeg: reimar * r21771 /trunk/libavcodec/iff.c: Use int8_t instead of char, the signedness of char can differ between systems. [18:36:27] <peloverde> Is there ever a valid reason to use memalign-hack on linux+glibc? [18:36:42] <kshishkov> should be none [18:36:42] <mru> no [18:37:48] <peloverde> that's what I thought, they turned it on for chromium's ffmpeg for some reason [18:37:56] <mru> idiots [18:38:02] <peloverde> probably cargo-cult ./configure [18:38:15] <peloverde> I already told them to turn it off [18:38:37] <mru> did they pass --disable for every ppc and arm cpu extension too? [18:39:22] <kshishkov> probably the same configure line for all arches [18:39:57] <peloverde> no they didn't disable all that stuff [18:55:33] <Kovensky> why is memalign-hack a configure option anyway [18:55:52] <mru> so people can turn it on if it's not detected [18:56:22] <Kovensky> and why do we have to turn it on when configure does detect it is needed instead of turning it on automatically (warn, whatever, but why abort?) [18:56:39] <mru> that I don't know [19:11:28] <peloverde> It was proposed at one point but someone made a big stink about it [19:12:48] <mru> as always [19:21:24] <Compn> is the contact at chrome a google employee? [19:21:30] <Compn> chromium* [19:24:19] <peloverde> yes [19:24:32] <peloverde> why? [19:25:50] <peloverde> Also I enjoy how the changes I've made to statisfy people' [19:25:59] <peloverde> s SBR complains have made the decoder 10% slower [19:26:15] <CIA-17> ffmpeg: michael * r21772 /trunk/libavcodec/ (h264.c avcodec.h options.c): [19:26:15] <CIA-17> ffmpeg: Try to support truncated h264 frames mixed with mpeg pes headers in mkv. [19:26:15] <CIA-17> ffmpeg: Fixes issue1585 [19:26:21] <kshishkov> we can manage [19:27:10] <kshishkov> maybe it's good to be able to disable SBR decoding in runtime for lousier systems though [19:27:20] <kshishkov> (just a thought) [19:28:27] <Compn> erm , i was just hoping someone would bug another google contact re ffmpeg + youtube :D [19:29:07] <kshishkov> bug On2 about TM2X [19:30:43] <peloverde> To a degree the changes will probably make it faster in the long run but not until a huge pile of SIMD code is written [19:31:49] <astrange> youtube doesn't admit they use ffmpeg so it'd be hard to have a contact [19:32:07] <astrange> but it'd be skal anyway, i think he knows what's going on already [19:32:53] <Compn> i dont need them to admit it [19:32:55] <peloverde> I've asked the chrom(e|ium) people for youtube patches a few times [19:33:12] <Compn> i just want samples and maybe anonymous patches :P [19:38:57] <astrange> i think youtube would just sandbox absolutely everything rather than do an audit, anyway [19:39:58] <_av500_> btw utube delivers still while it uploads, nice [19:40:07] <_av500_> stills [19:54:08] <Compn> hehe [19:54:21] <Compn> kshishkov : why are you so interested in tm2x? for that one sample we have? [19:54:31] <Compn> of the upsidedown bat... :) [19:55:10] <kshishkov> two samples and proprietary_codecs-- sake [20:12:58] <Compn> hehe [20:23:05] <thresh> love it: http://9gag.com/photo/18395_full.jpg [20:27:42] <Dark_Shikari> siretart: got a chance to try my patch yet? [20:29:50] <siretart> I'm looking at it right now [20:30:20] <Compn> thresh : looks racist somewhat... [20:30:55] <mru> only if you want to [20:31:35] <mru> it's a matter of fact that tribal wars occupy a large part of africa [20:32:27] <mru> there's absolutely nothing wrong with african people [20:32:36] <mru> but the society there is pretty fucked up [20:32:53] <kierank> because europeans arbitrarily divided the country [20:32:57] <Compn> except in that picture they are represented as still being unevolved? [20:33:00] <kierank> continent* [20:33:03] <thresh> Compn: yeah, I hate how they painted Russians as kalashnikov holders [20:33:05] <mru> their society is unevolved [20:33:40] <mru> so let's all laugh at the american [20:33:42] <mru> that's safe [20:33:47] <Compn> haha [20:33:58] * Compn should lose some weight [20:34:52] <Compn> google has a killer website optimizer project going now [20:34:58] * Compn watches 5 minute demo [20:35:28] <Compn> variable html with visitor tracking statistics! [20:35:59] <twnqx> self-modifying hmtl? [20:36:22] <CIA-17> ffmpeg: michael * r21773 /trunk/libavformat/ (img2.c utils.c avformat.h): [20:36:22] <CIA-17> ffmpeg: Add flag so muxers not needing width/height can signal this. [20:36:22] <CIA-17> ffmpeg: Add this flag to img2 (fixes -vcodec copy to image2 in some cases) [20:37:03] <Compn> no, i think you just add google's tracking html [20:42:31] <siretart> Dark_Shikari: can you perhaps explain me the ffpreset changes? you mentioned two days ago that your patch doesn't bring any new functionality to libx264.c? [20:42:47] <Dark_Shikari> it allows you to use the new x264 options [20:43:03] <Dark_Shikari> If they're available. [20:44:16] <thresh> Dark_Shikari: sorry for being an ass, but what's your ETA to push x264 fixes? [20:44:40] <Dark_Shikari> what x264 fixes, you mean the backport to 0.5? [20:44:44] <Dark_Shikari> I already gave the patch to siretart [20:44:52] <Dark_Shikari> brb lunch [20:45:00] <thresh> no, that's totally unrelated, i mean arm fixes for libx264 itself [20:52:05] <BBB> Compn, re: google & youtube, I'm still trying [20:52:09] <BBB> but not getting any response [20:52:13] <BBB> just a "we'll ask" [20:52:14] <BBB> and then nothing [20:52:15] <BBB> :( [20:52:37] <lu_zero> hi tresh [20:55:37] <thresh> hey lu_zero [20:58:18] <Dark_Shikari> thresh: oh, that one [20:58:21] <Dark_Shikari> I'm waiting on pengvado [20:58:24] <Dark_Shikari> I now have 15 local commits or so [20:58:47] <Dark_Shikari> siretart: ? [20:58:53] <Compn> BBB : dang, i've been mailing daniel berlin from google and getting the same results. [20:59:03] <siretart> Dark_Shikari: yes? [20:59:15] <mru> Compn, BBB: what are you probing google about? [20:59:41] <Dark_Shikari> siretart: I answered your question about the option changes and so forth... any issues with that? [21:01:24] <siretart> Dark_Shikari: I'm still trying to do an estimation on the regression potential [21:02:13] <Dark_Shikari> siretart: well, the _reason_ why we need the changes [21:02:21] <Dark_Shikari> is that if wpredp is left at default instead of made an option [21:02:27] <Dark_Shikari> people will not be able to encode for any baseline profile device [21:02:29] <Dark_Shikari> like ipods. [21:02:35] <Dark_Shikari> because wpredp is main profile and they won't be able to turn it off. [21:02:43] <Dark_Shikari> that's why the presets have to be changed as well [21:03:38] <siretart> ah, I see [21:05:06] <Compn> mru : trying to get access to unplayable/crashing/strange samples from youtube, or any patches they may have made to ffmpeg (or its decoders, if its using mencoder) [21:05:18] <Compn> since google bought youtube... [21:05:38] <Compn> and since google has been so nice to open source these past few years [21:06:09] <mru> I thought it was official google policy to not mention ffmpeg wrt yt [21:06:40] <Dark_Shikari> yeah [21:06:42] <Compn> if so, we would still accept anonymous patches and/or samples [21:06:50] <Dark_Shikari> google official policy is to not admit they use open source [21:06:51] <Dark_Shikari> whenever possible [21:06:52] <Dark_Shikari> >_. [21:06:53] <Dark_Shikari> >_> [21:06:54] <Compn> doesnt have to be from blah(a)google.com [21:07:00] <Dark_Shikari> of course [21:07:01] <Compn> can be from joeblow(a)not-google.com [21:07:10] <Dark_Shikari> but you can feel free to harass pascal to send something anonymously if yo uwant [21:07:10] <mru> @gmail [21:07:15] <Dark_Shikari> lol [21:07:48] <Compn> is pascal high up in google heirarchchy ? [21:08:09] <Compn> daniel is google code manager... [21:08:12] <Compn> i think [21:08:17] <mru> doesn't matter where he is [21:08:23] <mru> anyone with access to the code can send patches [21:08:38] <Compn> does he have access to the code? [21:08:40] <Dark_Shikari> pascal is one of the main guys on the youtube backend [21:08:45] <Compn> ah [21:08:46] <Dark_Shikari> he wrote their bad h264 encoder [21:09:18] <mru> how bad is it? [21:09:30] <Compn> its so bad... <insert joke here> [21:09:33] <mru> "it's not x264" isn't a valid answer [21:09:54] <mru> why'd they write their own? [21:10:04] <siretart> Dark_Shikari: http://pbot.rmdir.de/81aef377e36912dd36ad70c78da6a6ce [21:11:20] <kierank> harrass the people from @youtube.com on ffmpeg/x264 mailing lists ;) [21:11:23] <Dark_Shikari> siretart: oops [21:11:26] <Dark_Shikari> one mistake in the patch [21:11:51] <Dark_Shikari> siretart: change [21:11:52] <Dark_Shikari> + x4->params.i_bframe_pyramid = avctx->flags2 & CODEC_FLAG2_BPYRAMID; [21:11:52] <Dark_Shikari> to [21:11:55] <Dark_Shikari> + x4->params.b_bframe_pyramid = avctx->flags2 & CODEC_FLAG2_BPYRAMID; [21:11:57] <Dark_Shikari> done. [21:12:47] <siretart> indeed, that helps [21:17:22] <twnqx> meh, stupid atom [21:17:26] <astrange> skal wrote an h264 encoder (xvid avc) before joining google [21:17:35] <twnqx> has problems playing video while compiling gentoo updates [21:22:51] <mru> my latest arm is probably faster [21:23:00] <mru> dual 1GHz cortex-a9 [21:23:28] <thresh> what's the device? [21:23:35] <mru> tegra2 devboard [21:26:16] <siretart> Dark_Shikari: it seems that at least "basic" encoding does work with 0.5 and x264 api version 67 [21:42:20] <Kovensky> wow, that's ancient :D [21:44:44] <siretart> Dark_Shikari: please have a look at http://pbot.rmdir.de/2b1028414d0e87dd7e3457303c1cd860 [21:45:17] <siretart> Dark_Shikari: should the preset encode to main profile? according to the output, its baseline profile [21:47:49] <twnqx> mru: you got the 250? [21:49:41] <mru> yeah [21:51:35] <twnqx> cool [21:54:23] <mru> it's a bit unfriendly [21:58:25] <Kovensky> mru: heck, your a9 is probably faster than my pentium dual-core =p [22:01:20] <CIA-17> ffmpeg: conrad * r21774 /trunk/libavcodec/vp3.c: Remove unused code that's moved elsewhere [22:02:10] <CIA-17> ffmpeg: conrad * r21775 /trunk/libavcodec/vp3.c: Theora 3.4 doesn't exist; these fields were misunderstandings of the spec [22:02:11] <CIA-17> ffmpeg: conrad * r21776 /trunk/libavcodec/vp3.c: Export Theora colorspace info if present [22:02:14] <CIA-17> ffmpeg: conrad * r21777 /trunk/libavcodec/vp3.c: Move apply_loop_filter above render_slice, it'll be used by the latter soon [22:02:14] <CIA-17> ffmpeg: conrad * r21778 /trunk/libavcodec/vp3.c: [22:02:14] <CIA-17> ffmpeg: Do loop filter per-row rather than per-frame [22:02:14] <CIA-17> ffmpeg: 3% faster on Elephants_Dream_HD-q7-aq7.ogg on my penryn [22:02:15] <CIA-17> ffmpeg: conrad * r21779 /trunk/libavcodec/vp3.c: Cosmetics: reindent [22:02:15] <CIA-17> ffmpeg: conrad * r21780 /trunk/libavcodec/vp3.c: Implement CODEC_CAP_DRAW_HORIZ_BAND for VP3 decoder [22:02:16] <CIA-17> ffmpeg: conrad * r21781 /trunk/libavcodec/vp3.c: [22:02:16] <CIA-17> ffmpeg: Don't pre-calculate first_pixel [22:02:17] <CIA-17> ffmpeg: 3.6% faster on Elephants_Dream_HD-q7-aq7.ogg on my penryn [22:02:17] <CIA-17> ffmpeg: conrad * r21782 /trunk/libavcodec/utils.c: Special case VP5/6 chroma alignment on x86 as well [22:17:44] <J_Darnley> Can someone explain a value printed in the first line of a seek test? Specifically, the "pos" value. [22:18:46] <mru> I guess it's the pos [22:20:05] <J_Darnley> Of what? I'm trying to make sure that when I cause a change, it is correct [22:20:29] <mru> rtfs [22:21:35] <J_Darnley> Yeah, thanks [22:21:48] <mru> sorry, I don't know it any better than you do [22:22:08] <mru> and now I'm going out [22:42:54] <siretart> Dark_Shikari: seems that I didn't quite grok the preset and your patch seems to work so far [23:29:26] <CIA-17> ffmpeg: michael * r21783 /trunk/libavcodec/h264.c: [23:29:26] <CIA-17> ffmpeg: Dont drop B frames without last_picture. [23:29:26] <CIA-17> ffmpeg: Fixes issue1722

1 0

IRC log for 2010-02-11
by irc＠mansr.com 12 Feb '10

12 Feb '10

[00:00:34] <DonDiego> how come nobody can be arsed to fix warnings nowadays? [00:12:50] <Honoome> DonDiego: I should really try to find time to come back for that :P [00:31:58] <DonDiego> gnite [01:10:46] <peloverde> Is there a good way to do a fractional frequency shift on the FFT of an all real signal? [01:11:45] <peloverde> There is definitely symmetry in the FFT so it should be exploitable but I don't know how [01:20:08] <ramiro> mru: do you happen to know why sometimes when "make -j2" or "make -j3" is run, some .o files get deleted at the end? For example I just got this: rm doc/ffserver.pod ffmpeg.o doc/ffplay.pod doc/ffmpeg.pod [01:20:39] <ramiro> that ffmpeg.o doesn't seem to belong there. [02:33:54] <Compn> [21:41] <bjsnider> thbe entire ubuntu multimedia system from gstreamer to vlc to mplayer all uses external shared ffmpeg [03:38:24] <BBB> merbzt, I've started writing wmavoice specs for the wiki, comments would be appreciated if you have time [04:20:50] <justlooking_> /msg NickServ identify [06:44:13] <KotH> bonjour! [06:44:21] <kshishkov> gruss dich [06:46:47] <elenril> http://news.slashdot.org/story/10/02/10/2347257/Subversive-Groups-Must-Now-… wait, what? [06:47:02] <kshishkov> subversive, not SVN [06:47:26] <elenril> also morning [06:47:40] <KotH> elenril: old! :) [06:51:02] <pJok> mornings :) [06:51:09] <superdump> morning [06:51:19] <kshishkov> morgnar [06:52:09] <KotH> ah.. people wake up! :=) [06:53:27] <kshishkov> okay, now what? [06:57:30] * kshishkov prepares for sleep mode again [06:57:31] <KotH> let's start a revolution and overthrow a goverment [06:57:58] <kshishkov> nah, we had that several times already [06:59:03] * elenril overthrows KotH [06:59:09] <kshishkov> there were half a dozen of different governments in Ukraine during 1917-1919 for example and there were also revolutions in 1991 and 2004 [06:59:53] * KotH is no goverment [07:00:17] <KotH> lets overthorw the UN! [07:00:29] <KotH> they are standing in our way to world domination anyways! [07:00:30] <kshishkov> KotH: how else can we call root then? [07:00:47] <KotH> kshishkov: benelovent dictator for lifetime? ;-) [07:02:03] <kshishkov> KotH: that is the definition of government, yes [07:02:29] <KotH> no, i dont govern you, i just dictate ;) [07:02:47] <kshishkov> nobody governs me [07:03:10] <kshishkov> here you quickly learn the differences between country and homeland [07:03:23] * elenril kicks intel drivers for randomly disabling lvds yet again [07:04:16] <KotH> lol [07:04:24] <KotH> kshishkov: get your ass moving and move out of ua [07:04:56] <kshishkov> KotH: I try, but there are issues with receiving side :( [07:22:10] <superdump> kshishkov: what issues are there on the receiving side? [07:22:57] <kshishkov> superdump: well, in order to move to another country one need some permit [07:23:07] <kshishkov> in your case citizenship is enough [07:23:24] <kshishkov> in my case I need explicit permit [07:23:43] * pJok makes the ukraine a member of the EU [07:23:50] <kshishkov> had I such thing, I'd move without any hesitation [07:24:02] <superdump> how can you get a permit? [07:24:17] * kshishkov tells pJok that even omnipotent deity can't do that [07:24:50] <kshishkov> superdump: that's a tricky question [07:24:59] <pJok> looking at which countries that got into the eu, ukraine has a fair chance [07:25:02] <superdump> but i guess it's the one you want answered [07:25:32] <kshishkov> pJok: nope, it does not have any chances because it's screwed its chance already [07:27:19] <pJok> is the ukraine in a worse economic condition than greece? [07:27:47] <kshishkov> superdump: here, for example - http://swedenabroad.com/Page____48659.aspx [07:27:59] <kshishkov> probably it is [07:28:24] <kshishkov> where can I compare stats? [07:30:18] <superdump> kshishkov: does that apply to _anyone_ visiting sweden regardless of where they come from? [07:30:36] <DonDiego> libavcodec/indeo5.c:676: warning: implicit declaration of function ‘ivi_calc_band_checksum’ [07:30:45] <DonDiego> kshishkov: please don't ignore such warnings [07:31:00] <DonDiego> they're trivial enough to fix.. [07:31:14] <kshishkov> DonDiego: ok, will fix [07:31:27] <DonDiego> but please don't just ignore warnings [07:31:43] <pJok> kshishkov, wiki has a lot of different comparisons between countries [07:31:47] <DonDiego> the number of warnings has skyrocketed lately [07:32:00] <kshishkov> superdump: probably not, there are certain advantages for EU members and even more advantages for .no/.dk/.fi [07:32:26] * pJok can become a swedish citizen in april [07:32:41] <pJok> not that i have any need for that [07:33:43] <pJok> thats because in april i've lived two years in sweden [07:33:50] <superdump> kshishkov: why is there this special case: International passport (for ukrainian citizens) ? [07:34:06] <superdump> do ukranian citizens not have to provide the copies of all pages? [07:34:27] <kshishkov> pJok: .ua inflation >12%, .gr inflation < 3% [07:34:54] <superdump> aaah [07:34:56] <superdump> i see [07:35:02] <superdump> it was the ukraine specific page [07:35:02] <pJok> well, greece is in big trouble at the moment [07:35:04] <superdump> :) [07:35:06] <kshishkov> superdump: ask DonDiego for more details, they also have that system with internal and international passports [07:35:39] <pJok> germany has that as well [07:35:47] <pJok> personenausweiss and passport [07:36:14] <kshishkov> I like Swedish way though [07:36:45] <pJok> in sweden, as in denmark, you only have an international passport [07:37:15] <pJok> the id you either get from the government or what ever bank you are stuffing your moneey into [07:37:25] <kshishkov> or post [07:37:54] <superdump> kshishkov: http://swedenabroad.com/Page____63492.aspx [07:38:01] <superdump> looks like it's a little easier for me [07:38:28] <superdump> i move here, within 3 months of moving here i tell them i'm here and i have a right to be here [07:38:49] <superdump> then i sort out the swedish ID number within my first year though the sooner the better [07:38:50] <kshishkov> told you [07:38:51] <superdump> awesome [07:38:59] <kshishkov> that's because you're EU citizen [07:39:03] <superdump> i was a bit concerned when looking at the work permit thing [07:39:21] <superdump> for that your company has to advertise the job here and blah [07:39:35] <superdump> it's actually easier to just move here and sort out the job stuff afterwards [07:40:04] <kshishkov> yes, but in my case there is no easy way to move at all [07:40:21] <superdump> aaah [07:40:32] <superdump> advertised the job vacancy in sweden and the EU [07:41:47] <superdump> kshishkov: working in sweden as an EU/EEA citizen - http://swedenabroad.com/Page____101519.aspx [07:42:39] <superdump> kshishkov: have you applied for a permit? [07:43:42] <kshishkov> superdump: how? Benjamin has not adopted me yet, no company has sent me an offer and my self-unemployment plan is not good either [07:44:01] <superdump> pJok: i thought ID cards only allowed one to travel around the EU and they weren't valid outside, where you would actually need a passport [07:44:37] <superdump> merbzt: is it legal to have two wives (well, a wife and a husband) in sweden? [07:44:39] <superdump> :) [07:45:30] <superdump> kshishkov: hrm, i dunno. but your programming skills should make you hirable [07:46:09] <kshishkov> superdump: I've heard it was only legal in Stockholm in sixties [07:46:50] <kshishkov> superdump: but my status of citizen of third-world country blocks hiring me [07:48:04] <superdump> why? [07:48:23] <superdump> some open source friendly company with a brain could see that you're very capable from your work on ffmpeg [07:48:33] <kshishkov> because of aforementioned procedure of hiring [07:49:29] <superdump> thanks for the link to that page by the way [07:49:37] <superdump> i had been looking for information on how to move here [07:50:35] <DonDiego> ffmpeg branch in sweden? [07:51:01] <kshishkov> I saw all people who form that branch [07:55:29] <CIA-17> ffmpeg: kostya * r21752 /trunk/libavcodec/indeo5.c: [07:55:29] <CIA-17> ffmpeg: Move band checksum verifying into preprocessor condition, so compiler won't [07:55:29] <CIA-17> ffmpeg: complain about missing function prototype. [07:59:48] <kshishkov> DonDiego: okay, one warning less [07:59:53] <kshishkov> N to go ;) [08:00:17] <CIA-17> ffmpeg: kostya * r21753 /trunk/libavcodec/indeo5.c: Move 'chksum' declaration to the only block where that variable is used [08:05:00] <astrange> the h264 warnings are easy to remove, some entirely unused variables and two missing &s in (*blah)[x] stuff [08:08:14] <DonDiego> it's just a shame that michael doesn't give a hoot about warnings [08:08:32] <kshishkov> GCC does not help either [08:09:02] <DonDiego> all of these are correct warnings [08:11:11] <astrange> i introduced two of them myself and forgot to send the patch fixing them [08:11:24] <astrange> guess i'll do it friday [08:11:42] <DonDiego> just commit.. [08:12:03] <DonDiego> what's so controversial about removing unused vars? [08:12:21] <astrange> well, nothing [08:15:57] <siretart> god morgon [09:17:51] <av500> hi guys [09:18:23] <merbzt> hello [09:18:24] <kshishkov> hi guy [09:18:43] <andoma> hej [09:19:05] <av500> btw, there is another ffmpeg groupie? http://www.youtube.com/watch?v=iIalNEW-LQ8&feature=fvw [09:20:28] <kshishkov> we are official at least [09:26:00] <iive> what? uau forked ffmpeg too? [09:27:09] <elenril> http://kotaku.com/5469239/hey-korean-kids-lets-learn-leetspeak-and-internet… << lol [09:27:31] <elenril> iive: i think he has a mirror on repo.or.cz with some -mt related patches [09:27:54] <elenril> +merged libswscale [10:00:11] <merbzt> av500: awesome video :) [10:05:24] <av500> merbzt: what is also fun is to search ebay.com for ffmpeg :) [10:07:26] <kshishkov> what "FFmpeg r20359, one owner, slightly used"? [10:58:47] <mru> I have a suggestion [10:58:55] <mru> let's find out what's broken on fate and fix it [11:03:03] <kshishkov> FATE should print that [11:03:13] <mru> fate doesn't say why [11:07:14] <kshishkov> look at the tests, something ate away last frames [11:07:35] <mru> some tests are failing only on some configs [11:09:05] <kshishkov> still it has something to do with time handling changes in ffmpeg.c [11:09:23] <mru> so find out what's correct and fix what's not [11:09:28] <mru> we can't keep it like this [11:10:26] <kshishkov> well, 307 passed seems normal [11:10:43] <kshishkov> 303 passed means VP6 segfaulted [11:11:10] <mru> and 304? [11:11:29] <kshishkov> I meant 304 [11:11:37] <mru> well, 303 then? [11:11:49] <kshishkov> for 303 it's full regtest failing too [11:12:02] <mru> ah, those are 304 + old failures [11:12:08] <kshishkov> in mp2 decoder [11:14:10] <kshishkov> it's funny that on BeagleBoard full regtest fails because of mpeg4 asp encoder [11:14:27] <mru> with rvct? [11:14:53] <kshishkov> yes [11:14:59] <mru> compiler bug [11:15:02] <mru> already fixed [11:18:03] <av500> kshishkov: wrt ebay, mostly webhosting with ffmpeg preinstalled... [11:22:48] <kshishkov> av500: yay, so now it's like ImageMagick [11:23:32] <merbzt> ___gb___: have you done any work with the CrystalHD rstuff ? [11:27:50] <jez9999> kshishkov: you have ffmpeg checking access? [11:27:52] <jez9999> *checkin [11:28:05] <merbzt> all ops should have [11:28:09] <jez9999> ok [11:28:13] <jez9999> could you check in a minor bugfix? [11:28:24] <jez9999> i've submitted the patch1.diff in https://roundup.ffmpeg.org/roundup/ffmpeg/issue1740 [11:28:24] <kshishkov> theoretically yes [11:29:09] <merbzt> no note that it is ok'd [11:29:21] <merbzt> didn't look at the actual patch [11:29:22] <jez9999> note from whom [11:29:32] <jez9999> it's so small it should be easy to quickly review [11:29:47] <merbzt> from the maintainer that the patch is ok [11:29:53] <mru> FFmagick [11:30:56] <kshishkov> mru: well, certain Compn always wanted FFmpeg to be an ubiquitious image converter as well [11:31:33] <jez9999> and the maintainer is...? [11:32:05] <kshishkov> Michael Niedermayer [11:32:15] <kshishkov> (at least I think so) [11:32:22] <jez9999> then why was BBB saying he'd "accept" the patch? [11:32:22] <merbzt> if not in the MAINTAINERS it is MN [11:32:28] <kshishkov> aka default dev/maintainer [11:33:29] <jez9999> [15:52] <@BBB> jez9999, I said, add a ?opt=val to the sdp file [11:33:29] <jez9999> [15:53] <@BBB> ./ffplay file.sdp?opt=val [11:33:54] <merbzt> jez9999: I guess because he knows that the patch is correct [11:33:54] <jez9999> [15:57] <jez9999> the sdp handler doesn't get invoked, the file protocol handler fails [11:33:54] <jez9999> [15:57] <@BBB> hm, I guess the file doesn't exist... crap, this is how rtsp fixes these issues [11:33:55] <jez9999> [15:58] <@BBB> ok, then go fix that bug also then as part of this bug ;) [11:33:58] <merbzt> I don't [11:34:34] <jez9999> well you have his word for it now :-) [11:34:37] <jez9999> dont you trust him? [11:34:45] <kshishkov> on the contrary [11:34:52] <kshishkov> we trust him to commit this patch [11:35:15] <kshishkov> in the case of something, he'll be able to explain what is it for and why it was done so [11:35:24] <jez9999> gah [11:35:31] <merbzt> :) [11:35:44] <jez9999> that means i have to wait for him to get out of dozyland in the damn USA [11:35:56] * kshishkov does not know a thing about protocols, especially RT*P [11:36:00] <merbzt> yes [11:36:18] <jez9999> they should just adjust their clocks to be in line with ours and work at night [11:36:39] <jez9999> where does he live, NY? [11:36:42] <merbzt> suggest that to the appropriate place [11:37:13] <kshishkov> jez9999: nah, be thankful _they_ did not make you adjust your clock [11:37:26] <kshishkov> Airstrip One [11:37:56] <__gb__> merbzt, not yet, just compiled the driver on my system for now :) [11:38:09] <jez9999> is it NY? [11:38:59] <kshishkov> jez9999: no, it's how Great Britain is called in British Government Development Plan (aka "1984") [11:39:11] <jez9999> where he lives i mean [11:39:21] <merbzt> __gb__: there was a post on ffmpeg-devel about it, might be possible to fund the work [11:39:59] <kshishkov> yes, your guess is correct [11:40:05] <superdump> donation offer for crystal hd support in ffmpeg on the ML [11:40:08] * superdump looks at GB [11:40:11] <jez9999> probably 2-3 hours then..... at least.... [11:40:14] <superdump> __gb__: ^ [11:40:20] * jez9999 twiddles thumbs [11:42:31] <kshishkov> superdump: quite an ambiguous two-letter abbreviation, isn't it? [11:42:35] <merbzt> __gb__: well I've only just installed it in my machine [11:43:40] <merbzt> lspci finds the card [11:43:48] <superdump> may as well get the funding for th ework [11:43:50] <superdump> the work* [11:44:09] <superdump> as it's being offered [11:44:17] <superdump> is it just a hardware decoder card? [11:44:20] <kshishkov> well, "donation" usually hints at smaller sums [11:44:22] <superdump> why is there so much noise about it? [11:44:23] <merbzt> yes [11:44:37] <merbzt> because they released drivers for it [11:44:41] <merbzt> and it works [11:44:51] <kshishkov> and it's rather opensource [11:45:31] <elenril> is there any sane reason why they didn't use vdpau or vaapi? [11:45:53] <kshishkov> is there any sane reason to use it? [11:46:25] <elenril> to not have yet another acceleration api? [11:46:41] * elenril heard that vdpau is NotTerrible [11:46:55] <CIA-17> ffmpeg: kostya * r21754 /trunk/libavutil/sha.c: [11:46:55] <CIA-17> ffmpeg: Make SHA digest function write digest value with AV_WN32 instead of assuming [11:46:55] <CIA-17> ffmpeg: that output may be written as uint32_t since output buffer may not be aligned [11:46:55] <CIA-17> ffmpeg: (and it's silly to force alignment on it) and it does not work in that case [11:46:55] <CIA-17> ffmpeg: properly on some architectures. [11:47:04] <__gb__> vdpau or vaapi are decode+display APIs, not really suitable to crystalhd, which needs the whole bitstream [11:47:16] <superdump> is crystalhd hella cheap or something? [11:47:34] <merbzt> 21$ was what I payed for my card [11:47:38] <__gb__> crystalhd is not quite opensource, the whole stuff is hidden in a big 1 or 2 MB firmware [11:47:39] <superdump> :) [11:47:45] <superdump> that's the answer then [11:47:48] <kshishkov> elenril: also both those APIs look like inhouse API released for public [11:48:02] <superdump> $21 is quite a bit cheaper than a vaapi/vdpau supporting card i guess [11:48:04] <__gb__> yes, this is the same api for windows, linux and macos x [11:48:36] <merbzt> __gb__: would it be possible to wrap it under vaapi ? [11:49:00] <__gb__> this could be hard because crystalhd needs the whole bitstream, vaapi or vdpau work at picture level [11:49:07] <merbzt> ok [11:49:26] <__gb__> e.g. you'd have to reconstruct sps and pps headers, which can be hard without much changes to vaapi or vdpau [11:49:50] <__gb__> but I not thought much about it yet [11:49:51] <merbzt> then I guess the best way is to hook it up into the ffmpeg api [11:50:02] <__gb__> yes, but there might also be a problem [11:50:18] <__gb__> iirc, scott told me that crystalhd requires a few encoded frames prior to emitting the first decoded frame [11:50:42] <__gb__> but I probably misunderstood the thing [11:50:52] * __gb__ is going to cook and eat -- see you later :) [11:53:49] <CIA-17> ffmpeg: siretart * r21755 /branches/0.5/ (libavcodec/avcodec.h Changelog): [11:53:49] <CIA-17> ffmpeg: reverting objected hunks from previous commit [11:53:49] <CIA-17> ffmpeg: as discussed with diego on irc, the spurious newline deletion and the [11:53:49] <CIA-17> ffmpeg: LIBAVCODEC_VERSION_MINOR bump are being reverted based on comments on [11:53:49] <CIA-17> ffmpeg: ffmpeg-cvslog by ramiro, uoti and michael. [11:53:50] <CIA-17> ffmpeg: See http://comments.gmane.org/gmane.comp.video.ffmpeg.cvs/28112 for the [11:53:51] <CIA-17> ffmpeg: full context. [11:54:09] <ramiro> DonDiego: ping. did you read the gsm thread? [12:13:38] <superdump> merbzt: they're going to put out an expresscard version so people can munge it into their laptops and netbooks :D [12:13:54] <superdump> i wonder what the power usage is on one of those broadcom doodads [12:14:36] <merbzt> they are doing pciexpress cards also [12:15:16] <superdump> yup [12:19:34] * kshishkov would like low-power system solely for 1280x760 H.264 playback though [12:20:00] <twnqx> too small! [12:20:41] <twnqx> though i'd like a PoE dongle with a HDMI connector on the other end, and sp/dif in the middle. [12:21:14] <mru> kshishkov: omap3 [12:24:53] <superdump> does anyone here watch much 1080p content yet? [12:25:26] <DonDiego> ramiro: no [12:25:34] <Dark_Shikari> I do [12:25:44] <twnqx> superdump: i dop [12:25:46] <twnqx> do* [12:25:50] * mru too [12:25:51] <Dark_Shikari> thanks to hdbits [12:26:29] <twnqx> do they give out invites again, btw? [12:27:10] <kshishkov> mru: BB seems to be slow for that :( [12:27:28] <ramiro> DonDiego: please do. it's currently inconsistent. [12:27:28] <Dark_Shikari> twnqx: still no [12:27:34] <twnqx> we should make michael optimize ffmpeg until HE can watch 1080p content [12:27:37] <mru> you need av500's 800MHz omap3 and some fancy codecs [12:27:39] <mru> it can be done [12:28:19] <twnqx> someone told me of an anime rip where the end exceeds 100mbit bitrate in the end... [12:28:29] <twnqx> foir one scene [12:29:07] <Dark_Shikari> not surprising [12:29:38] <twnqx> 100mbit is realistic with (numerically) low CRF and high movements, i guess? [12:29:40] <superdump> big buck bunny plays fine using one core on my core 2 vpro 1.83GHz [12:29:46] <Dark_Shikari> BBB is _EASY_ [12:29:50] <Dark_Shikari> I encoded that at 1mbps [12:29:51] <superdump> i thought as much [12:29:52] <Dark_Shikari> looks great [12:29:54] <superdump> ha [12:29:56] <superdump> :) [12:30:00] <Dark_Shikari> with weightp, even moreso [12:30:03] <mru> BBB has mostly static backgrounds [12:30:04] <superdump> it's very low motion really [12:30:05] <Dark_Shikari> because at 1mbps the only noticably awful scene was the fade [12:30:37] <mru> the zoom at the start and the pan where the rat barely avoids various traps are the hardest parts [12:31:01] <Dark_Shikari> btw [12:31:06] <Dark_Shikari> here's my two awesome "quality" images [12:31:07] <Dark_Shikari> http://i48.tinypic.com/2rnhf06.png [12:31:11] <Dark_Shikari> dvd source [12:31:16] <Dark_Shikari> due to the "requires 100mbit" phenomenon [12:31:24] * Dark_Shikari uploads similar example from blu-ray [12:31:30] <Dark_Shikari> http://i46.tinypic.com/2nu0nqv.png [12:32:12] <superdump> urrrgh [12:32:31] <twnqx> haruhi! [12:32:47] <twnqx> with horrible artefacts >_> [12:32:52] <superdump> i don't have the hard drive space on this laptop to get 1080p stuff [12:33:05] <superdump> nor a 1080p cable subscription or whatever [12:33:15] <twnqx> no bittorent? [12:33:28] <twnqx> 1080p bluray rips are in the range of 8-11G [12:33:28] <superdump> nor the bandwidth to be bothered to wait for 1080p stuff to download [12:33:30] <twnqx> (normally) [12:33:54] <superdump> plus i don't have a 1080p screen here yet :) [12:34:19] <superdump> i wondered if maybe there were some bravia + ps3 bundles to save me getting a BD player [12:34:21] <mru> superdump: get job, get money, get screen [12:34:29] <mru> don't buy a bravia [12:34:32] <mru> waste of money [12:34:33] <superdump> have job, getting money, will get screen shortly [12:34:38] <superdump> i have a samsung at home [12:34:43] <mru> samsung or lg are as good and half the price [12:34:49] <superdump> hehe [12:34:54] <superdump> which should cover a ps3 anyway [12:34:58] <Dark_Shikari> WDTV is $80 [12:35:00] <Dark_Shikari> it plays 1080p [12:35:01] <mru> ps3 is good [12:35:02] <superdump> i did want an led backlit one, but.... [12:35:02] <Dark_Shikari> you do not need anything else [12:35:19] <superdump> Dark_Shikari: can you plug in a BD drive? :D [12:35:28] <Dark_Shikari> why would you need a BD drive? [12:35:54] <superdump> in case i bought some blu ray discs [12:35:56] <Dark_Shikari> >implying that people actually buy blu-ray movies [12:36:37] <mru> Dark_Shikari: where did you think the rips came from? [12:38:01] <superdump> Dark_Shikari: does the wdtv have any fans or anything or is it passive? [12:38:09] <Dark_Shikari> mru: yes, but _one_ person buys it [12:38:10] <Dark_Shikari> at most [12:38:12] <KotH> Dark_Shikari: what's teh source of these two images? [12:38:12] <Dark_Shikari> superdump: dunno [12:38:15] <Dark_Shikari> it's a hardware player [12:38:18] <Dark_Shikari> KotH: 1st is a Haruhi DVD [12:38:22] <Dark_Shikari> not sure about the blu-ray one [12:38:31] <superdump> it would be nice to have no fans, no moving parts and no electrical whining either [12:38:42] <twnqx> <Dark_Shikari> >implying that people actually buy blu-ray movies <-- i do [12:38:45] <KotH> Dark_Shikari: the second image is from utawarerumono [12:39:02] <superdump> but i guess using an SSD as mass storage isn't advisable yet [12:39:02] <janneg> superdump: it has a harddisk [12:39:07] <KotH> Dark_Shikari: eh.. you mean that was professionaly produced stuff?? [12:39:08] <superdump> janneg: right [12:39:24] <superdump> what kind of ui does it have? what software? [12:39:33] <Dark_Shikari> KotH: yes [12:39:37] <superdump> have people hacked it? [12:39:45] <superdump> can you stick a bittorrent client on it? :) [12:39:57] <Dark_Shikari> the first one simply ran out of bitrate, combined with a bad MPEG-2 encoder [12:40:03] <Dark_Shikari> because that scene will exceed ~9mbps [12:40:06] <Dark_Shikari> it hit QP31 [12:40:14] <Dark_Shikari> The second one is inexcusable, but also MPEG-2 [12:40:27] <Dark_Shikari> R2 DVDs were better for Haruhi, that scene was just lowpassed instead of blocked to hell [12:42:06] <KotH> Dark_Shikari: i've to have a look at the fansub... but i dont remember seeing anything that bad ... [12:42:32] <Dark_Shikari> it probably wasn't blu-ray based [12:43:28] <av500> superdump: wdtv no fans afaik [12:44:56] <peloverde> good morning [12:45:00] <av500> gm [12:47:08] <superdump> so, basically you need a wdtv and some kind of NAS which runs a bittorrent client and has a usb port on it so that all its storage can be accessed as mass storage [12:47:29] <superdump> the only thing then is whether the wdtv presents the stuff on the drive in some useful way [12:47:40] <superdump> i suspect xbmc or so might be a nicer interface [12:47:46] * twnqx uses a atom/ion htpc [12:48:10] <kshishkov> superdump: theoretically gigabit network performance should be enough [12:48:34] <superdump> indeed, having the whiney storage elsewhere is an option [12:49:02] * kshishkov uses NAS made from SheevaPlug+2.5" USB HDD [12:50:38] <av500> superdump: wdtv live has eth, so u need a san somewhere... [12:51:46] <Dark_Shikari> gigabit is plenty [12:51:49] <Dark_Shikari> the decoder can't even handle that much [12:52:04] <av500> h264 UHP? [12:52:41] <superdump> http://www.trustedreviews.com/multimedia/review/2009/10/29/Western-Digital-… <--- the video here recommends the asus hd pr1 or something like that as it's just as good but quite a bit cheaper [12:53:50] <Dark_Shikari> cheaper than ~80-100$? [12:53:51] <av500> superdump: but my guy "in the know" tells me that these days the xstreamer is a better choise than wdtv life: http://www.xtreamer.net/ [13:44:45] <lu_zero> yawn [13:46:54] <KotH> bon giorno lu_zero [13:48:09] <lu_zero> hi KotH [13:55:06] <neo01124> asd [14:09:35] <CIA-17> ffmpeg: kostya * r21756 /trunk/libavutil/sha.c: Simplify expression as suggested by M?ns Rullg?rd [14:28:54] <jez9999> just to check (and i doubt this), are there functions already in ffmpeg to 1) split a query string from a URL, and b) break up the query string's key/value's into some kind of array? [14:29:23] <kshishkov> 1) url_parse() [14:29:34] <kshishkov> 2) probably none [14:29:54] <KotH> tr /12/ab/ [14:31:30] <jez9999> url_parse looks PHPish [14:31:59] <kshishkov> wanna pick a fight? [14:32:04] <jez9999> where is it defined? [14:32:50] <KotH> kshishkov: i'd take that as a yes ;) [14:32:59] <kshishkov> libavformat/avformat.h - url_split() [14:36:06] <jez9999> kshishkov: i dont see that giving you the query string back anywhere [14:36:47] <kshishkov> probably in path [14:37:31] <jez9999> oh well. that's doing a lot more work than i need anyway [14:38:17] <kshishkov> it's so trivial nobody ever bothered to write a support for it in URL splitter [14:39:15] <jez9999> yeah [14:39:20] <jez9999> i wrote something to do it [14:41:21] <KotH> y [15:00:37] <jez9999> BBB: hi [15:08:49] <BBB> hi jez9999 [15:09:07] <jez9999> so from yesterday: [15:09:25] <jez9999> [15:52] <@BBB> jez9999, I said, add a ?opt=val to the sdp file [15:09:26] <jez9999> [15:53] <@BBB> ./ffplay file.sdp?opt=val [15:09:26] <jez9999> [15:57] <jez9999> the sdp handler doesn't get invoked, the file protocol handler fails [15:09:26] <jez9999> [15:57] <@BBB> hm, I guess the file doesn't exist... crap, this is how rtsp fixes these issues [15:09:26] <jez9999> [15:58] <@BBB> ok, then go fix that bug also then as part of this bug ;) [15:09:42] <jez9999> i have a patch to fix that bug, can you commit it? [15:10:15] <BBB> submit it to the mailinglist [15:10:20] <BBB> or to the issue tracker [15:10:25] <BBB> let's see if michael's ok with it [15:10:28] <BBB> I have no strong opinion [15:10:38] <BBB> he might say "no, go work on codec/format-specific options" [15:11:37] <jez9999> it's already in the issue tracker. [15:14:27] <jez9999> https://roundup.ffmpeg.org/roundup/ffmpeg/issue1740 [15:14:33] <jez9999> patch2.diff [15:14:35] <jez9999> so what now? [15:14:50] <jai> drink beer? [15:15:01] <andoma> yes! [15:15:06] <KotH> no! [15:15:41] <andoma> ok, in a few hours .. [15:16:16] <jai> andoma: what time is it there? [15:16:55] <andoma> 16:16 [15:17:16] <jai> ah, k [15:17:31] <BBB> jez9999, oh, I was sick yesterday so I missed it - will check [15:34:16] <jez9999> BBB: thanx [16:04:02] <BBB> Vitor1001, wmavoice patch ok with you? [16:04:18] <Vitor1001> have to go now, but not yet :( [16:05:15] <Vitor1001> I have just one more comment, but I really think it would be nice to get another pair of eyeballs to look at three funcs [16:05:23] <Vitor1001> aw_parse_coords() [16:05:34] <Vitor1001> aw_pulse_set{1,2}() [16:05:56] <Vitor1001> I cannot see any more how to improve them, but maybe I just read them too many times [16:06:07] <BBB> Reimar also commented a lot on them [16:06:12] <BBB> I think they're a lot prettier already [16:06:16] <Vitor1001> and when one do that one miss some things... [16:06:22] <BBB> right :) [16:06:31] <BBB> http://wiki.multimedia.cx/index.php?title=Windows_Media_Audio_Voice#Frames [16:06:35] <BBB> trying to document also [16:06:48] <Vitor1001> yeah, but it really would be nice if someone looked at it for the first tine after all the simplifications [16:06:53] <Vitor1001> \o/ [16:07:09] <BBB> you shoudl document sipro [16:07:11] <Vitor1001> My comment about it is in aw_parse_coords() [16:07:15] <BBB> I'd like to link to it for relevant stuff [16:08:09] <Vitor1001> I think (s->aw_n_pulses[idx] == 0), (first_idx[n] > 0) and (s->aw_first_pulse_off[idx] == NO_OFFSET) are equivalent [16:08:24] <Vitor1001> IMHO, using everywhere just the first one is clearer if it is the case [16:08:37] <BBB> yeah [16:08:39] <BBB> ok [16:08:45] <Vitor1001> I'm lazy about documentation [16:08:51] <Vitor1001> writing text in general [16:08:56] <BBB> also, the first loop (where I set nmin/nmax) and the second (where I use them) can probably be merged [16:08:58] <BBB> I'll try that [16:08:59] <Vitor1001> ideally I should document also TwinVQ :( [16:09:20] <Vitor1001> Have to go now, be back in ~ 30 min [16:09:22] <kshishkov> ideally you should document every codec in existence [16:21:08] <jez9999> BBB: you taken a look yet? [16:23:52] <CIA-17> ffmpeg: siretart * r21757 /branches/ (0.5 0.5/libavcodec/snow.c): [16:23:52] <CIA-17> ffmpeg: Fix crash when max_ref_frames was out of range. [16:23:52] <CIA-17> ffmpeg: This might have been exploitable. [16:23:52] <CIA-17> ffmpeg: Fixes first crash of issue840. [16:23:52] <CIA-17> ffmpeg: backport r18388 by michael [16:25:25] <BBB> jez9999, working on other things right now, I will [16:25:31] <jez9999> k [16:35:46] <Vitor1001> I'm back [16:36:12] <kshishkov> what about new thoughts on WMASpeech? [16:36:26] * kshishkov want FFmpeg to decode all formats ASAP [16:36:51] <Vitor1001> kshishkov: ? [16:36:54] <kierank> need moar samples [16:36:59] <jai> instant world domination eh? [16:36:59] <kierank> ;) [16:37:30] <kshishkov> Vitor1001: I meant WMS review [16:37:50] <Vitor1001> Read my conversation with BBB 20 min ago [16:38:01] <kshishkov> I read [16:38:02] <Vitor1001> I was just looking for someone else to review three functions [16:38:33] <Vitor1001> Do you volunteer to review them after BBB applies my suggestions? [16:38:35] <BBB> I simplified aw_parse_coords() [16:38:40] <Vitor1001> Nice [16:38:41] <BBB> it has one loop now [16:38:42] <BBB> instead of two [16:38:46] <BBB> I think you'll like it [16:38:48] <BBB> let me pastebin it [16:38:51] <kshishkov> Vitor1001: ok, I am [16:39:28] <Vitor1001> BBB: did you suceed in removing the first_off[] array? [16:39:54] <BBB> http://ffmpeg.pastebin.com/m9dd635d [16:39:55] <BBB> Vitor1001, yes [16:39:56] <Vitor1001> And removing the use of NO_OFFSET in aw_parse_coords() [16:40:00] <BBB> no [16:40:06] <BBB> NO_OFFSET should stay, at least for now [16:40:10] <Vitor1001> Why? [16:40:15] <superdump> KotH, mru : i'm going to be running some progressive download tests on mphq samples for all the files for a few container formats, is that ok? [16:40:16] <BBB> no time yet :] [16:40:20] <BBB> will work on it [16:40:31] <superdump> i won't need to read the entire file in any case, so i shouldn't be using too much bandwidth [16:40:41] <BBB> (I know, you want me to use aw_n_pulses[] and leave aw_first_pulse_off uninitialized [16:40:52] <superdump> but just to let you know in case you see someone hammering the http access to samples.mphq [16:41:02] <BBB> nmin/nmax also removed again [16:41:05] <BBB> should've known :) [16:41:09] <BBB> anyway [16:41:09] <KotH> superdump: ip? [16:41:13] <Vitor1001> BBB: What I suggested was instead of " if (first_idx[n] > 0)" [16:41:15] <superdump> errrm [16:41:23] <Vitor1001> doing "if (s->aw_n_pulses[idx])" [16:41:25] <KotH> superdump: ip range is ok too :) [16:41:29] <BBB> Vitor1001, that's not equivalent [16:41:30] <Vitor1001> and removing the first_idx[] array [16:41:50] <BBB> don't forget that this is positioning of a repeating pulse [16:41:59] <BBB> first_idx simply tells us where the first pulse was: [16:42:03] <BBB> before the start of block1 [16:42:04] <Vitor1001> I see [16:42:05] <BBB> in block1 [16:42:07] <BBB> or in block2? [16:42:14] <BBB> I can make that a variable also [16:42:25] <Vitor1001> wouldn't (s->aw_first_pulse_off[n] != NO_OFFSET) do it them? [16:42:36] <BBB> no [16:42:48] <BBB> I could store the offset = start_offset[bits] value [16:42:50] <BBB> that would do [16:42:58] <BBB> if <0, then first_idx>0 for both [16:43:14] <Vitor1001> ugh, the negative coefficients again :p [16:43:14] <BBB> if >= 0 but < MAX_FRAMESIZE /2, only for [1] [16:43:18] <BBB> else for neither [16:43:27] <BBB> hey I didn't design this codec :) [16:43:29] <Vitor1001> I understand... [16:43:31] <Vitor1001> I know ;) [16:43:38] <BBB> let me try getting rid of first_idx[] [16:43:39] <BBB> sec [16:43:55] <Vitor1001> But that's why I want someone else to look at it... I'm starting to misread this func... [16:45:39] <Vitor1001> BTW, kshishkov, thanks :) [16:47:50] <BBB> same uri has next version [16:47:59] <BBB> I caled the variable first_off [16:48:03] <BBB> as opposed to first_idx[] [16:48:12] <BBB> maybe the loop at the end can be simplified also now [16:48:42] <BBB> since it makes no sense to continue the loop for n=0 if it was false for n=1 [16:48:56] <BBB> so I should do for (n = 1; n >= 0; n--) if .. else break; [16:49:19] <BBB> but I could just as well manually unroll it [16:49:21] <BBB> hmm... [16:49:49] <BBB> anywyay, let me know if this is better [16:49:52] <kshishkov> hmm, why can't you replace first for() loop with division? [16:50:10] <Vitor1001> Nice [16:50:12] <BBB> hmm... I don't need n anymore [16:50:14] <BBB> let me remove it [16:50:25] <BBB> kshishkov: because I thought I needed n [16:51:03] <Vitor1001> Just do not try to optimize it if it makes less readable [16:51:12] <Vitor1001> doesn't looks like a very speed critical func. [16:51:20] <kshishkov> have you corrected line 39 to offset += pitch[idx] ? [16:51:39] <BBB> done [16:51:59] <BBB> division you mean offset %= pitch[0];? [16:52:08] <kshishkov> yes, like that [16:53:04] <Vitor1001> MS engineers designed this part of wmav during a trip in hell :p [16:53:36] <kshishkov> see XKCD for "Ballmer's peak" definition [16:54:33] <Vitor1001> I know it ;) [16:56:11] <BBB> the %= doesn't work for negative numbers [16:56:15] <kshishkov> also it looks like whole loopn on lines 31-40 can be boiled into directly setting pulse offsets and s->aw_n_pulses by dividing MAX_FRAMESIZE/2 by pitch [16:57:26] <BBB> kshishkov, how do I know aw_first_pulse_off[]? [16:58:17] <kshishkov> the only thing you need for it is offset [16:58:57] <kshishkov> for the zeroeth pulse it's first offset >= 0, right? [16:59:15] <kshishkov> for the first pulse it's first offset >= MAX_FRAMESIZE /2 [16:59:55] <kshishkov> which can be derived from initial_offset and number of times pitch[0] is used [17:00:16] <kshishkov> which will also be the number for s->aw_n_pulses[0] [17:00:27] <BBB> Vitor1001, ok, NO_OFFSET removed [17:00:48] <kshishkov> determining that number is just one integer division [17:01:09] <kshishkov> like (MAX_FRAMESIZE/2 + pitch[0] - 1 - first_offset)/pitch[0] [17:01:24] <kierank> is twolame better than the ffmpeg mp2 encoder? [17:01:47] <kshishkov> almost everything is [17:01:53] <jai> most encoders are [17:01:57] <jai> yep [17:02:09] <jai> +audio [17:02:17] <KotH> why doesnt ffmpeg have a mp1l3 encoder already? [17:02:17] <kshishkov> I've heard our AC3 encoder is not bad [17:02:32] <kshishkov> KotH: some political decision, I think [17:02:57] <KotH> kshishkov: agreement with frauenhofer? [17:03:03] <jai> KotH: we could write a simple one which outputs a valid bitstream [17:03:28] <jai> but unless the psy stuff is working.... [17:03:30] <kshishkov> KotH: no, but personally I'd like to see MP3 buried. It's a very awful format [17:03:43] <peloverde> I agree [17:04:24] <kshishkov> and having data not bound to frames is maybe the worst thing ever [17:05:46] <BBB> http://ffmpeg.pastebin.com/m6e294f05 [17:05:55] <BBB> is what I have now [17:06:08] <BBB> the %= didn't work for the first loop, so tell me what it should be instead :) [17:06:36] <mru> %, ouch [17:07:24] <BBB> hey, he suggested it, not me :) [17:07:27] * BBB ducks [17:07:32] <Vitor1001> BBB: Nice about the NO_OFFSET! \o/ [17:07:52] <Vitor1001> mru: % is faster than doing a loop for evaluating it. [17:08:12] <kshishkov> still, the second loop boils down to: [17:08:15] <mru> only if you must do the calculation in the first place [17:09:07] <kshishkov> set first_pulse_off[0]; set s->aw_n_pulses[0]; set s->aw_first_pulse_off[1]; set s->aw_n_pulses[1]; [17:10:11] <kshishkov> first can be done out of loop, second can be calculated by one division, third may be calculated from the second, tthe last can be calculated by simple division again [17:11:09] <kshishkov> theoretically you can replace first loop with if(start_offset < 0) offset = (start_offset % pitch[0]) + pitch[0]; [17:11:58] <kshishkov> well, it has some flaws but demonstrates my idea [17:14:14] <superdump> KotH: do you know if http://samples.mplayerhq.hu/allsamples.txt is up-to-date? [17:15:14] <BBB> kshishkov, flaws? [17:15:26] <BBB> kshishkov, you're talking to someone that didn't know the restrict keyword until two days ago [17:15:46] * kshishkov does not know about that thing even now [17:16:20] <kshishkov> well, it misses "else" clause for one thing [17:16:51] <Compn> superdump : its not up to date, but i can update it now if you want [17:16:54] <BBB> is it going to be faster? [17:17:07] <superdump> Compn: yes please [17:17:09] <kshishkov> yes, and more branch predictable too [17:17:10] <BBB> I mean, a simple while loop that executes (mostly) 0-1 times can't be that much slower than a "%" [17:17:27] * BBB feels a wristslap coming [17:17:28] <kshishkov> ah, in that case leave it as is [17:17:30] <KotH> superdump: nope, it's not [17:17:37] <KotH> superdump: 2009-11-11 [17:17:41] <mru> BBB: depends on how % is implemented [17:17:57] <BBB> mru: uhm, by getting edx after idiv? [17:18:06] * BBB feels another wristslap coming [17:18:09] <Compn> superdump : refresh it [17:18:15] <mru> you need to stop thinking in x86 [17:18:26] <BBB> it's the only asm I know :( [17:18:29] <mru> and even there, the compiler might use a loop [17:18:32] <KotH> superdump: now it's up to date :) [17:18:41] <mru> is either operand a constant? [17:18:46] <superdump> Compn: thanks :) [17:19:14] <Compn> KotH : is there any specific command i should use to generate that file btw? :P [17:19:15] <kshishkov> BBB: for the first loop it does not worth the salt, but you have still to replace the second one [17:19:22] <KotH> Compn: no idea [17:19:32] * Compn just using find | grep -v md5sum > allsamples.txt [17:19:34] <KotH> Compn: i dont even know what for it is there :) [17:19:41] <Compn> easy searching for files [17:19:54] <Compn> like say you want to find all acelp samples [17:20:02] <Compn> some are in A-codecs, some maybe in /mov/ or /real/ etc [17:20:15] <BBB> kshishkov, ok, will try [17:20:16] <KotH> there should be a database [tm] [17:20:28] <Compn> then there are some other non-sorted dirs like A-codecs/suite or fate samples [17:20:31] <jai> and xml! [17:20:40] <BBB> so it's then (MAX_FRAMESIZE / 2 - offset) / pitch[0] for n_pulses? [17:20:43] <KotH> Compn: ack [17:20:54] * KotH gtg [17:21:09] <kshishkov> BBB: probably + pitch[0] - 1 [17:21:40] <kshishkov> so offset will go over MAX_FRAMESIZE/2 [17:21:47] <kshishkov> as it's supposed [17:22:38] <BBB> kshishkov, that's for offset, yes [17:22:44] <BBB> but for n_pulses? [17:22:51] <BBB> let me try [17:22:56] * BBB no good at any of this [17:22:58] <kshishkov> for n_pulses as well [17:23:07] <kshishkov> but yes, I'd also try it [17:26:46] <BBB> wow, it went correct the first time :) [17:26:57] <BBB> completely loopless except for that thingy at the end [17:28:12] <kshishkov> well, it could also be simplified in that way but it's shaving pigs [17:29:38] <superdump> KotH: i find 2085 files i want to test [17:29:42] <BBB> not worth it because (again) the loop will run 0-1 times, usually [17:29:47] <superdump> does that file list symlinked files too...? [17:29:56] <superdump> or just actual files [17:29:56] <BBB> the middle loop that we just did runs 4-5 times on average [17:29:59] <superdump> Compn: ^ [17:30:02] <kshishkov> BBB: that's why I said it's shaving pigs [17:30:29] <kshishkov> superdump: probably it does, you can compare checksums though [17:30:33] <BBB> http://ffmpeg.pastebin.com/m21e26d60 [17:30:37] <BBB> that's what I have now [17:30:44] <superdump> bleh [17:31:04] <BBB> Vitor1001, is the bottom of that OK with you? [17:31:19] <BBB> Vitor1001, I'm unrolling it for the compiler b/c then I can inline the second if in the first [17:31:28] <BBB> Vitor1001, apparently you never know with gcc [17:31:39] <BBB> anyway, this function is about 10LOC less than the original [17:32:12] <BBB> from 59 in my v1 patch to 45 now [17:32:20] <kshishkov> BBB: looks more or less ok to me [17:32:49] <BBB> want to do set2() also? [17:32:52] <BBB> let me c/p it [17:33:09] <kshishkov> maybe remove hash inside comment? [17:33:17] <BBB> http://ffmpeg.pastebin.com/m671c3e4d [17:33:31] <BBB> oh yeah, the hash is doxy leftovers, doxy links with the hash [17:33:33] <BBB> but it's not doxy [17:33:34] <BBB> so ok [17:34:58] <Vitor1001> BBB: If it ok to kshishkov, I'm fine too. [17:35:10] <BBB> it's a lot nicer now [17:35:28] <kshishkov> Reimar would ask to use memset(use_mask + 5 instead of memset(&use_mask[5] [17:35:32] <Vitor1001> BBB: I don't know if you need to unroll the loop, the code is not very speed critical [17:35:45] <kshishkov> and sizeof(use_mask[0]) [17:35:47] <BBB> well I already did [17:36:06] <BBB> kshishkov, he did, he didn't mind when I said I preferred this way [17:36:07] <Vitor1001> BBB: If it is not less readable, fine for me too [17:36:11] <BBB> ok [17:36:44] <Vitor1001> But nice job you two, aw_parse_coords() is really neat now :D [17:36:53] <BBB> sizeof(use_mask[0]) done [17:37:11] <kshishkov> I'll look at the rest later, in 20-30 mins [17:37:12] <kshishkov> bbl [17:37:18] <BBB> sure, thanks! [17:41:40] * Kovensky just saw http://hardwarebug.org/2010/02/10/1080p-video-on-beagle/ on reader [17:41:50] * Kovensky recognizes nobody, probably because he doesn't know how anybody looks like [17:42:21] <BBB> is there a reason to cache first-off? or is the compiler smart enough to know that start_off[bits] doesn't change given that all are local variables? [17:43:30] <BBB> let's compare [17:46:30] <BBB> aha, it's smaller [17:46:32] <BBB> perfect [17:53:52] <mru> Kovensky: I'm at the far right [17:54:09] <mru> peloverde is at the other end [17:54:12] <mru> the rest you can interpolate [17:56:48] <mru> hmm... getopt(..., 'r:o:f:l:...') [18:04:43] <kshishkov> BBB: in aw_pulse_set2 you can replace horrible idx adjust ment by simple loop checking on nonzero mask and idx = (mask_num << 4) + 0xF - av_log2(use_mask[mask_num]) [18:04:54] <kshishkov> (lines 50-56) [18:08:02] <kshishkov> also if fcb->pitch_lag allows, it may be better to split idx into two variables - for lower 4 bits and high bits [18:08:54] <kshishkov> two places it's used as one value are lines 49 and 61 [18:10:00] <BBB> kshishkov, it used to be that [18:10:03] <BBB> kshishkov, this seemed faster [18:10:09] <BBB> (although slightly more code) [18:10:30] <BBB> reimar said that the loop code itself would require more registers than an unlooped version in total [18:10:37] <BBB> which I tend to agree with [18:10:41] <kshishkov> then make constants on lines 50-54 as hex values [18:10:48] <kshishkov> it's clearer that way [18:10:57] <BBB> 16*x+15? [18:11:03] <BBB> (where x = use_mask idx) [18:11:06] <BBB> ok [18:11:07] <kshishkov> yes [18:11:42] <Kovensky> mru: which right [18:11:59] <mru> observer [18:11:59] <kshishkov> Kovensky: photo right [18:12:11] <Kovensky> ic [18:12:16] <BBB> http://ffmpeg.pastebin.com/m58c7f2e4 [18:12:17] <mru> peloverde is the one with the beard [18:12:25] <Kovensky> and ffmpeg shirt [18:12:56] <BBB> unless you want me to write out 16 as 16 * 1 and . as 16 * 0 [18:12:57] <BBB> :) [18:13:04] <BBB> (which I thought was sort of overkill) [18:13:34] <kshishkov> BBB: btw, idx_sh and idx_mask meanings are kinda swapped [18:14:11] <kshishkov> and I'd accept even simple 0x0F, 0x1F, 0x2F, 0x3F, 0x4F ;) [18:14:33] <BBB> I think reimar & vitor disliked me using hes values [18:14:37] <BBB> well anyway [18:14:43] <BBB> I guess it doesn't matter so much [18:15:02] * BBB will use hex then [18:15:03] <BBB> smaller [18:15:07] <kshishkov> still, I think you've got swapped names for idx_sh and idx_mask [18:15:49] <BBB> I think the var names just suck [18:16:07] <BBB> idx_sh = shifted index [18:16:18] <kshishkov> still, I'd expect idx_sh used for shifts and idx_mask for mask index, not vice versa [18:16:22] <BBB> idx_mask is silliest name ever [18:17:42] <BBB> those names are just as bad [18:17:45] <BBB> I agree though [18:17:46] <BBB> bad names [18:17:49] <BBB> let me think :) [18:18:33] <BBB> idx_mask could be first_off [18:18:35] <kshishkov> even simple 'mask' and 'shift' would be better [18:18:36] <BBB> or no [18:18:46] <BBB> mask should be off or so [18:18:56] <BBB> and idx_sh just mask_idx [18:19:01] <BBB> use_mask_idx [18:19:02] <BBB> or so [18:19:17] <BBB> I'll use a pointer into use_mask instead [18:21:08] <kshishkov> the last two lines seems also the task for the Superhero who knows modular arithmetics [18:21:59] <BBB> I was about to ask [18:22:22] <BBB> probably (MAX_FRAMESIZE / 2 + pitch - 1 + offset) / pitch? [18:22:26] <BBB> or something along those lines [18:22:51] <kshishkov> pitch_lag - (FRAMESIZE/2 - start) % pitch_lag is more likely [18:24:13] <kshishkov> n = (MAX_FRAMESIZE / 2 - start_off) % pitch_lag; if(n) n = pitch_lag - n; [18:26:50] <BBB> n = (fcb->pitch_lag - 1 + MAX_FRAMESIZE / 2 - start_off) / fcb->pitch_lag;? [18:27:09] <kshishkov> no, you don't need to divide here [18:27:19] <BBB> you're doing a modulo, same thing [18:27:20] <BBB> no? [18:27:40] <kshishkov> you want to know a residue over HALF_MAX_FRAMESIZE [18:27:54] <BBB> yes [18:27:58] <Vitor1001> BBB: I dislike hex when not doing bit-based tricks [18:28:29] <Vitor1001> for masks I have nothing against it. [18:28:38] <kshishkov> Vitor1001: for traking compound variable whose low 4 bits have separate meaning it's fine too [18:28:42] <BBB> Vitor1001, it's not a mask where kshishkov pointed it out [18:28:59] <BBB> but it works fine here [18:30:54] <BBB> kshishkov, your trick works too [18:30:56] <BBB> and is shorter [18:30:59] <BBB> I think I'll keep it [18:31:08] <BBB> n = (MAX_FRAMESIZE / 2 - start_off) % fcb->pitch_lag; [18:31:08] <BBB> s->aw_next_pulse_off_cache = n ? fcb->pitch_lag - n : 0; [18:31:12] <kshishkov> and only one modulo instead of division and multiplication [18:31:20] <BBB> trure [18:32:50] <kshishkov> well, just throw a comment about 'idx' structure and that it's faster and it's fine with me [18:35:04] <BBB> that its index in the 80-bit use_mask bit-array and thus (given that use_msk is 16-bit[5]) idx>>4 is the uint16_t index and the remainder (&15) is the bit index within? [18:35:07] <BBB> or something else? [18:35:47] <kshishkov> yes [18:36:22] <kshishkov> saves some seconds on deciphering it and some minutes on answering the question why it was done so [18:39:10] <BBB> got it [18:45:36] <BBB> shall I resubmit this to the mailinglist? or is there more? [18:45:49] <BBB> (you could also review the patch on the mailinglist to get the complete picture) [18:46:05] <kshishkov> aw_get_pulses1() I suppose [18:46:17] <kshishkov> the rest was fine I heard [18:46:51] <BBB> aw_pulse_set1()? [18:46:52] <kshishkov> and after that you can commit it directly I think [18:47:32] <BBB> http://ffmpeg.pastebin.com/m6d4a52b6 [18:47:43] <kshishkov> yes, aw_pulse_set1() [18:49:29] <peloverde> Do we have a knowlegebase of FFT or other transform tricks? [18:49:47] <kshishkov> BBB: looks ok [18:50:09] <kshishkov> peloverde: Wikipedia seems to have rather good theoretical articales on FFT [18:50:23] <kshishkov> for the rest we have FFmpeg source code [18:50:50] <peloverde> Wikipedia is actually pretty basic [18:51:02] <mru> there are these things called books too... [18:51:09] <BBB> oops [18:51:50] <peloverde> I'm looking for fancy things like an FFT of an all real signal translated half a bin in the frequency domain [18:51:57] <kshishkov> peloverde: I've looked at FFT there this morning, seems much nicer than usual coverage to me [18:52:13] <kshishkov> BBB: that's a bad sign. What's happened? [18:52:53] <kshishkov> peloverde: RDFT? [18:52:55] <peloverde> kshishkov: There is nothing on the wikipedia page that isn't in my junior level text books [18:53:05] <peloverde> shifted half a bin? [18:53:35] <BBB> kshishkov, uhm, I tried to close a tab in my browser and then somehow focus was still on xchat [18:53:57] <BBB> typical case of pebkac [18:54:13] <kshishkov> peloverde: well, take generic formula, use zeroes where appropriate and get your new SBR transform [18:58:40] <kshishkov> I suspect you can simply perform N/2 transform with post-twiddle [19:01:10] <kshishkov> peloverde: wikipedia says you can do it as two-dimensional FFT - 2x(N/2), transpose and perform (N/2)x2 tranform [19:01:59] <peloverde> kshishkov: The half bin translation [19:02:03] <peloverde> I know how an RDFT works [19:02:05] <BBB> kshishkov, Vitor1001: can you guys ok the patch? :) [19:02:07] <peloverde> I wrote rdft.c [19:02:11] <BBB> that way reimar will do stuff also [19:02:13] <kshishkov> it's either whole N/2 transform may be skipped entirely or you can al least use 2-point FFT on (0; x) as special case [19:02:35] <kshishkov> BBB: yes, fine [19:02:55] <peloverde> The half bin translation is done by multiplying by a complex exponential in the time domain [19:03:07] <peloverde> making the resulting signal no longer real [19:03:22] <kshishkov> you can discard imaginary part [19:04:08] * kshishkov wonders how FAAD(2) could get it [19:05:30] <peloverde> I think I can still solve it like a normal RDFT only instead of transposing I have to do some adding [19:05:51] <peloverde> I should still be able to demultiplex in the FFT domain because there is still symmetry [19:29:45] <BBB> kshishkov, so if I have your code: [19:29:45] <BBB> n = (MAX_FRAMESIZE / 2 - start_off) % fcb->pitch_lag; [19:29:45] <BBB> s->aw_next_pulse_off_cache = n ? fcb->pitch_lag - n : 0; [19:30:23] <Dark_Shikari> Yuvi: very very nice [19:30:26] <BBB> would it be faster if I do something silly like s->aw.. = (fcb_pitch_lag * MAX_FRAMESIZE / 2 - MAX_FRAMESIZE / 2 + start_off) % fcb->pitch_lag;? [19:30:39] <BBB> i.e. is the conditional something that slows it down considerably? [19:30:53] <kshishkov> benchmark it! [19:31:13] <BBB> time thinks that any variant I try takes +/- 0.4 sec to decode my 4 test files [19:31:16] <BBB> it's not very accurate :) [19:33:01] <kshishkov> hmm [19:33:03] <BBB> I might need a benchmarking guide or so [19:33:31] <kshishkov> look at START_TIMER/STOP_TIMER in FFmpeg code [19:33:35] <astrange> run 5x in a row, take the 'user' time and then take the minimum [19:33:38] <astrange> for large changes [19:33:44] <astrange> otherwise use START/STOP timer [19:33:48] <BBB> ok [19:33:59] * BBB goes figure stuff out again [19:34:05] <astrange> that's not absolutely accurate (it prints 600 dezicycles even if you do nothing) but relatively it's ok [19:40:24] <Vitor1001> peloverde: The stuff I explained to you didn't work? [19:41:58] <Vitor1001> BBB: ok'ed on list. [19:42:00] <BBB> 1185 dezicycles in bla, 128 runs, 0 skips [19:42:00] <BBB> 1177 dezicycles in bla, 256 runs, 0 skips [19:42:00] <BBB> 1167 dezicycles in bla, 512 runs, 0 skips [19:42:05] <Vitor1001> BBB: I'd say commit it :D [19:42:40] <BBB> trying one more thing, then I'll commit I guess [19:43:04] <kshishkov> BBB: in any case you can improve it later in SVN ;) [19:43:43] <peloverde> Vitor1001: the Feb 2 e-mail? I must have missed it in the shuffle before FOSDEM, I'll give it another look [19:44:07] <BBB> 1269 dezicycles in bla, 128 runs, 0 skips [19:44:07] <BBB> 1260 dezicycles in bla, 256 runs, 0 skips [19:44:07] <BBB> 1256 dezicycles in bla, 512 runs, 0 skips [19:44:19] <BBB> so more dezicycles is bad right? [19:44:24] <BBB> ok, kshishkov, yours is better :) [19:44:30] <kshishkov> sorry [19:44:36] <Vitor1001> peloverde: Yes, that one. [19:45:14] <BBB> ohwell [19:45:20] <BBB> at least I finished something [19:45:29] <peloverde> But that only seems to handle the real part of the output [19:45:52] <Vitor1001> No [19:45:56] <Vitor1001> F_k is complex [19:46:21] <Vitor1001> When I say "F_k + F_k-1" I mean a complex substraction [19:46:42] <Vitor1001> The only thing that is not obvious is to find the complex part of F_0 [19:47:12] <Vitor1001> That you have to actually do sum_n X_n sin(...) [19:47:46] <iive> BBB: the code you pasted. are you sure you haven't replaced == into = ? [19:48:25] <iive> hum, my bad [19:48:30] <kshishkov> no, it's all assignments [19:49:04] <iive> i took it for (cache=n)?-n:0 [19:49:21] <iive> instead of cache= (n?-n:0) [19:49:43] <iive> today is not my day. [19:51:15] <BBB> :) [19:51:19] <kshishkov> yes, go RE some codec [19:51:26] <_av500_> Kovensky: i'm the somewhat tall guy in the back :) [19:51:32] <BBB> have to do postfilter first [19:51:36] <BBB> then a video codec or so [19:52:04] <kshishkov> lol, there's _always_ speech codec postfilter left to be done [19:53:31] <Dark_Shikari> BBB: WVP2! [19:53:53] * kshishkov grins [19:55:55] <Kovensky> _av500_: heh [19:56:13] <_av500_> you might not have extrapolated that... [19:57:09] <kshishkov> _av500_: okay, which of you disguised as a girl then? [19:58:14] <_av500_> for i think she was genuine [19:58:29] <_av500_> i think she was genuine [19:58:33] <Kovensky> http://somafm.com/play/missioncontrol [19:58:36] <kshishkov> genuine FFmpeg dev?! [19:59:03] <_av500_> she does study cs, but i doubt she gave birth to a patch yet [20:00:30] <kshishkov> my group at university had ~12 girls who got B.Sc. in CS [20:01:01] <kshishkov> not that any of them actually _knew_ CS [20:01:24] <Kovensky> lulz [20:01:34] <peloverde> Vitor1001: I got it working [20:02:02] <peloverde> but I'm still convinced there has fo be a clever way to game f[0].im [20:02:06] <kshishkov> Kovensky: that's why I don't value our education [20:02:23] * Kovensky doesn't value his education either [20:02:33] <Vitor1001> peloverde: :D [20:02:54] <Kovensky> I'm on supposedly the best college in town (scholarship), but I still haven't learned anything of value in it for the past 2 years other than calculus [20:03:08] <Vitor1001> peloverde: I spent some time thinking about it, not really trivial :( [20:03:17] <Dark_Shikari> Kovensky: that's not a very good college then [20:03:29] <Dark_Shikari> I'm learning haskell \o/ [20:03:34] <Kovensky> I know [20:03:34] <twnqx> >_> [20:03:34] <Kovensky> lol [20:03:41] <Kovensky> this semseter I'll be taught HTML <_< [20:03:43] <Kovensky> and PHP >_> [20:03:44] <Dark_Shikari> LOL [20:03:45] <twnqx> time for an x264 port! [20:03:48] <Dark_Shikari> what the fuck [20:03:49] <Kovensky> then next semester CSS [20:03:51] <Dark_Shikari> wait wait [20:03:52] <twnqx> to haskell, i mean. [20:03:58] <Dark_Shikari> that's not a CS program [20:04:01] <Dark_Shikari> that's a web development program [20:04:02] <Kovensky> no, it's not [20:04:06] <Dark_Shikari> aka utterly useless bullshit [20:04:16] <Kovensky> my course isn't exactly CS though, it's information systems [20:04:17] <kshishkov> ours included Java EE [20:04:21] <Dark_Shikari> which won't get you a job as anything other than a codemonkey [20:04:27] <Dark_Shikari> earning minimum codemonkey wage [20:04:30] <Kovensky> (one more reason I want that japan scholarship, I could at least study (or pretend to study) real CS) [20:04:47] <Dark_Shikari> if a CS program has classes "on a language", it's not a CS program [20:04:48] <kshishkov> Dark_Shikari: our companies prefer undergraduated codemonkeys, thank you [20:04:53] <Kovensky> well [20:04:58] <Kovensky> it's "Web Developent" [20:05:08] <Kovensky> we had "Object Oriented Language" last semester, which was just Java [20:05:29] <Dark_Shikari> even my "haskell" class is "programming languages" [20:05:32] <Kovensky> several of the questions on the tests asked about supposed object oriented stuff that if I did answer thinking only of the basic OO concepts would be wrong [20:05:32] <Dark_Shikari> where we learn to write parsers, compilers, etc [20:05:38] <Dark_Shikari> and we just use haskell because it's bloody easy to write parsers in [20:05:46] <Kovensky> or asked stuff that only existed in Java [20:06:05] <kshishkov> Dark_Shikari: everything is bloody easy with Perl! [20:06:08] <Kovensky> then before that it was "Structured Language", which taught C, but nobody learned shit because the professor sucked [20:06:10] <Dark_Shikari> kshishkov: not as easy as haskell [20:06:14] <Dark_Shikari> haskell has automatic pattern matching [20:06:21] <Dark_Shikari> for any expression whatsoever [20:06:25] <kshishkov> Kovensky: it was Pascal for us [20:06:35] <_av500_> begin ftw [20:06:38] <Kovensky> and even before "Structured Language" there was "Programming Techniques II", with Pascal [20:06:41] <Dark_Shikari> EvaluateExpression Num ArithOp Num [20:06:53] <Dark_Shikari> or EvaluateExpression Exp Arithop Exp [20:06:56] <Kovensky> and before it "Programming Techniques", with some shitty language [20:07:05] <Dark_Shikari> you can write an infix parser in about 3 lines of code [20:07:06] <Kovensky> that was basically Pascal in portuguese [20:07:18] <kshishkov> Kovensky: now, your program seems to be closer and closer to ours [20:07:18] <Kovensky> considering how much I hate portuguese, you can guess how fun the classes where... [20:07:25] <Kovensky> were* [20:07:27] <Dark_Shikari> pascal :/ [20:07:40] <Kovensky> our C manuals were hillarious [20:07:49] <Kovensky> our professor kept confusing C and Pascal syntax [20:07:57] <kshishkov> well, we have an official Pascal translated into Russian, called "Ershov's [programming] language" [20:08:15] <kshishkov> it's nice nobody remembers about it [20:08:15] <Kovensky> I wonder if his actual code was like that, every single array of his would be short allocated and the 0th element would always be unused [20:08:50] <Dark_Shikari> pascal/C strings are the best [20:08:51] <Kovensky> some of my colleagues actually complained when I told them what was the Right Thing, saying that if it's in the manual it's because it's like that ._. [20:08:55] <Dark_Shikari> i.e. lenght header + zero-terminated [20:09:39] <_av500_> Dark_Shikari: also 64byte cache line padded? [20:09:43] <Kovensky> my C professor also frequently wrote code that either didn't compile at all or had blatant errors [20:09:52] <kshishkov> DOS strings - dollar sign terminated! [20:09:53] <Dark_Shikari> my PLs professor confuses haskell and ML syntax [20:09:55] <Dark_Shikari> but he admits it [20:09:58] <Dark_Shikari> and they're practically the same anyways [20:10:03] <Kovensky> there was one time where he opened Dev-C++ and wrote an entire program in Pascal [20:10:10] <Kovensky> (yes we are forced to use Dev-C++) [20:10:45] <kshishkov> it was Borland C++ 4.5 for us [20:10:54] <Kovensky> heh [20:11:05] <Kovensky> I wonder if I can convince the new manager to at least pretend to do stuff right <_< [20:11:27] <Kovensky> also see if they finally can give us direct MSDNAA access instead of asking the manager for every single key that we want [20:11:55] * _av500_ has to remember to renew his msdnaa.... [20:12:10] <Kovensky> the manager doesn't even have the keys that I want :/ [20:12:13] <Kovensky> namely win7 ultimate [20:12:22] <_av500_> yep, for that ;) [20:12:32] <Kovensky> the college's MSDNAA subscription does give win7 access though [20:12:40] <Kovensky> he had win7 home basic keys [20:12:48] <superdump> Compn: is the archive dir the dir with all the symlinks? [20:13:07] <superdump> i.e. http://samples.mplayerhq.hu/archive/ [20:15:36] * kshishkov has managed to live without MSDN even when he programmed ActiveX controls using VfW [20:16:21] <kshishkov> *yawn* [20:41:44] <Vitor1001> Kovensky: Just for curiosity, where is your college? [20:42:55] <Kovensky> northeastern brazil [20:43:15] <Kovensky> they have much better colleges in the southeast, which is pretty much the only part of the country that pretends to be developed [20:43:24] <Vitor1001> Are u brazilian? [20:43:24] <ramiro> Kovensky: Vitor1001 is brazilian too =) [20:43:54] <Kovensky> o rly [20:44:13] <Kovensky> and yes, I'm stuck in sao luis =p [20:44:21] * Kovensky was born in salvador though [20:44:24] <ramiro> do maranhao [20:44:31] <ramiro> Kovensky: doesn't make it much better, hehehe [20:44:50] * Kovensky wonders why must everyone append "do maranhao" to "sao luis" [20:44:57] <Vitor1001> Nice... [20:44:58] <Kovensky> not like there is any other "sao luis" that you should know about [20:45:16] <Vitor1001> I was there not so long ago, to go to the lençois [20:45:42] <Vitor1001> Really nice, but one should run away of the CVC (a tourist company) trap [20:46:19] * Vitor1001 is from SP [20:46:36] * Kovensky has lived in several parts of the country [20:46:42] <ramiro> Vitor1001: my sister used to work for cvc [20:46:45] * Kovensky got stuck in sao luis since 2000 [20:46:47] <ramiro> but she says the same thing... [20:47:55] <Vitor1001> ramiro: Nothing against it, but for lençois they have the "10 days at lençois" that is actually 3 days at lençois and 7 at sao luis [20:49:33] <Vitor1001> Kovensky: I wonder why there is not more people from the NE that do the univ. entrance exams in the southeast... [20:50:07] <ramiro> well, ufpe in recife doesn't seem to be that bad, and it's closer. [20:50:59] <Vitor1001> it's fun to go a few thousand km away from home sometimes ;) [20:51:08] <Kovensky> I know [20:51:58] <Kovensky> it's mostly that I'm poor (or I wouldn't be stuck here)._. [20:52:02] <Kovensky> + [20:53:02] <Vitor1001> I see... I know that at least in SP it is pretty hard to get university housing... [20:53:25] <Vitor1001> And I don't say "decent university housing" because there is no such a thing [20:54:01] <ramiro> Vitor1001: from what I've been told, only "uncontroversial" people (that don't party and don't protest) get university housing in usp. basically only crentes. [20:54:27] <Vitor1001> ramiro: No, you just have to be poor [20:54:31] <Vitor1001> I mean _really_ poor [20:54:56] <Vitor1001> It's paperwork [20:55:13] <Vitor1001> there will be no "do you like to party?" question in the forms [20:55:25] * Kovensky is not poor enough for most stuff [20:55:48] <Kovensky> specially since the main measure of poverty here is the power bill, and mine is pretty high [20:55:57] <Kovensky> R$400, R$500 [20:56:44] <ramiro> Kovensky: incredible, you manage to spend even more than me. [20:57:12] <Vitor1001> Kovensky: I spend less than that, and I need some serious heating here in paris! [20:57:22] <ramiro> and I have a quad core running FATE boxes on the living room and a broken fridge that eats electricity. [20:58:51] <CIA-17> ffmpeg: siretart * r21758 /branches/ (0.5 0.5/libavcodec/snow.c): [20:58:51] <CIA-17> ffmpeg: Make sure the block array is of the correct size. [20:58:51] <CIA-17> ffmpeg: This might have been exploitable. [20:58:51] <CIA-17> ffmpeg: backported r18393 by michael [20:58:52] <Kovensky> I have 5 Sempron 2800+ boxes + my craptop + tv + fridge + microwave [20:59:02] <Kovensky> we run an improvised lan house @ home ._. [20:59:02] <Vitor1001> no AC? [20:59:13] <Kovensky> no AC, and to install one we'd have to rebuild the house [20:59:17] <thresh> heating in paris? stop joking :-) [20:59:46] <Vitor1001> thresh: lol, where are you? [20:59:57] <Kovensky> also, for heating, just run f@h, compile something, transcode, etc [21:00:00] <Kovensky> :) [21:00:06] <thresh> Moscow Area, sadly [21:00:50] <Vitor1001> thresh: Yeah, I can imagine some serious cold there [21:01:39] * Kovensky wants to escape to yurop or jewpan [21:01:40] <BBB> Vitor1001, I'm writing specs for a little, then I'll commit [21:01:53] <Vitor1001> BBB: nice! [21:01:56] <Vitor1001> congrats! [21:02:05] <thresh> the average monthly pay for public heating services and other stuff like water rarely exceeds 100 EUR here [21:02:07] <Vitor1001> Pretty complex for a first decoder :) [21:02:45] <Vitor1001> thresh: That quite a bit, supposing gas is cheap there [21:03:03] <Vitor1001> I pay around 800 EUR / year [21:03:15] <thresh> well, that's for a 3-room flat with 4 people living in it [21:03:33] <Vitor1001> thresh: But then, it is a Paris sized appartment for 2 [21:03:35] <thresh> for 1-room one, i'd say around 40 EUR [21:04:13] <thresh> however it is pretty warm here when it's -30°C outside [21:04:19] <thresh> provided you have proper windows of course [21:04:24] <CIA-17> ffmpeg: siretart * r21759 /branches/ (0.5 0.5/libavcodec/mlpdec.c): [21:04:24] <CIA-17> ffmpeg: Fix crash in MLP decoder due to integer overflow. [21:04:24] <CIA-17> ffmpeg: Probably only DoS, init_get_bits sets buffer to NULL, thus causing a [21:04:24] <CIA-17> ffmpeg: NULL-dereference directly after. [21:04:24] <CIA-17> ffmpeg: backport r21426 by reimar [21:04:46] <_av500_> thresh: windows7? [21:05:17] <Kovensky> Vitor1001: how did you escape the banana republic [21:05:40] <Vitor1001> A partnership between USP and a french university [21:05:49] * Kovensky should try and escape to sweden [21:06:03] <Kovensky> nice climate and cool music [21:06:08] <Kovensky> plus good economy [21:06:10] <thresh> nice climate?? [21:06:15] <thresh> it's cold out there [21:06:21] <Honoome> that's good [21:06:29] <Vitor1001> Kovensky: If you are into studing, you can try doing a master of science and them a PhD abroad [21:06:30] <Kovensky> thresh: compare to the 45C in Santos, or 33C in here [21:06:32] <Honoome> you can overclock more [21:06:53] <thresh> Kovensky: well, yeah, oz is a bit warm [21:07:04] <thresh> although i'd prefer melting rather than icing [21:07:24] <mru> wizards like it warm? [21:07:35] <mru> or was that lizards? [21:08:09] <mru> the oz govt seems to be controlled by the lizard army at least [21:08:16] <Kovensky> Vitor1001: my current plan is trying for a scholarship in japan [21:08:44] <Honoome> mru: take us to your lizard? [21:09:07] <Kovensky> oz? [21:09:38] <Vitor1001> Kovensky: could work [21:10:17] <Kovensky> Vitor1001: what will you do once the partnership finishes btw? [21:10:44] <Vitor1001> Kovensky: It has finished a long time ago... That was for college, I'm finishing my PhD now. [21:10:51] <Kovensky> oic [21:11:19] * Kovensky dislikes his mother language and is currently studying japanese [21:11:34] <Kovensky> studying in japan would be ideal [21:11:44] <mru> s/ideal/essential/ [21:12:05] <Kovensky> mru: well, not for learning japanese; I could just go to Liberdade [21:12:25] <Kovensky> (an almost completely japanese neighborhood in Sao Paulo) [21:12:27] <Vitor1001> Kovensky: It is still quite far from sao luis [21:12:32] <Kovensky> Vitor1001: true =p [21:14:46] <Kovensky> it's been raining the whole day in here and it's still freaking hot q_q [21:15:57] * Kovensky foobar2000 (v1.0): Amon Amarth [2008 Twilight of the Thunder God #1.04/1.10] Where Is Your God? [0:22/3:11] 281kbps MP3 VBR <-- example of cool swede music [21:22:30] <peloverde> Amon Amarth is pretty solid [21:26:08] <superdump> is it metal? [21:26:14] <superdump> it sounds like a metallish name [21:26:20] <Kovensky> melodic death metal about vikings [21:26:39] <Kovensky> Amon Amarth is an alternative name for Mordor in LoTR [21:26:42] <Kovensky> LotR* [21:26:45] * Kovensky is case sensitive [21:27:34] <Kovensky> (well, or so wikipedia says) [21:39:28] <_av500_> ramiro: forget the pools and use heap [21:39:40] <_av500_> that saves you from having to track each buffer size you use [21:40:53] <_av500_> note that you have to change one Memory_alloc() param for heap [21:41:20] <superdump> Kovensky: aha, i thought i recognised it [21:42:01] <_av500_> ramiro: also, the loadmodules.sh values are way oversized, they can be cut down a lot [21:44:56] <ramiro> _av500_: doesn't the h264 decoder allocate that memory internally? do I have control on how it allocates it? [21:47:58] <ramiro> _av500_: and I don't know how much I can cut them down. as I said on the list the documentation says the sizes, but not how many buffers of each are needed. [21:54:57] <CIA-17> ffmpeg: cehoyos * r21760 /trunk/ffmpeg.c: [21:54:57] <CIA-17> ffmpeg: Remove recording_time check which is no longer necessary after r21687. [21:54:57] <CIA-17> ffmpeg: Patch by Wolfram Gloger, wmglo A dent D med D uni-muenchen D de [21:59:50] <_av500_> ramiro: what cpu are u on? [22:00:05] <ramiro> _av500_: dm365 [22:00:42] <_av500_> hm that might differ from arm plus dsp setup... [22:11:02] <_av500_> ramiro: do you compile code that allocs cmem? [22:11:09] <_av500_> or is that object code you use? [22:12:24] <mru> there's a difference? [22:12:38] <_av500_> well, source is easier to change :) [22:12:52] <mru> then you need a better hex editor [22:12:59] <_av500_> i dont know how dm36x sdks do it [22:13:05] <ramiro> _av500_: how will I get contiguous memory from the heap without cmem pools though? [22:13:21] <_av500_> you can setup cmem to use a heap instead of pools [22:13:38] <_av500_> in that case it has one big heap and allocsfrom there [22:13:45] <_av500_> much like malloc [22:13:50] <mru> you can have a mix too [22:13:53] <_av500_> yes [22:14:04] <_av500_> pro is that you dont need to worry aboutbuffer sizes [22:14:14] <_av500_> con is that ti is afraid the pool will fragment... [22:14:15] <ramiro> and con? [22:14:16] <mru> if you have only a few different sizes pools are better [22:14:21] <mru> faster and no fragmentation [22:14:31] <mru> pools don't fragment, heaps do [22:14:35] <_av500_> but we use a heap since 4 ys and never saw any [22:14:55] <mru> if your usage pattern clears it out from time to time you're fine [22:15:11] <_av500_> we could not define a set of pools that matches 10 different codecs [22:15:25] <ramiro> another problem I'm having is the oom killer killing vlc [22:15:35] <_av500_> ;) [22:15:36] <mru> _av500_: do you free everything after playing a file? [22:15:54] <ramiro> the idle system with top running syays some 68Mb of memory is being used. with vlc uses up to 20% memory it's killed [22:15:57] <_av500_> mru: most of it [22:16:10] <ramiro> how do I find out who's hogging all those 68Mb on the idle system? [22:16:21] <mru> ps? [22:16:23] <_av500_> mru: yes, heap state after play is more or less the same as before [22:16:32] <_av500_> its not like you star a video while one is playing... [22:16:35] <_av500_> start [22:16:48] <mru> what, no pip? [22:16:49] <_av500_> that would fragment, but has little real world use... [22:17:06] <ramiro> if I add up the memory from all the programs from ps or top it goes to about 10%... much different from the 90% [22:26:46] <mru> Dark_Shikari: ping [22:26:53] <Dark_Shikari> pong [22:27:12] <mru> do you still have that collection of h264 test streams up somewhere? [22:27:36] <Dark_Shikari> http://www.mediafire.com/download.php?mi2zjoynymi [22:29:45] <mru> thanks [22:33:36] <CIA-17> ffmpeg: michael * r21761 /trunk/libavformat/iv8.c: Fix timestamps. [22:34:30] <mru> is that supposed to fix fate? [22:38:51] <BBB> bleh [22:38:54] <BBB> enough spec writing for today [22:40:29] <Honoome> BBB: what about rspec writing? :D I could use someone to do that on a few packages :P [22:42:57] <BBB> not my thing [22:43:00] <BBB> ;) [22:43:32] <Honoome> not masochist enough, uh? [22:52:59] * /join #ffmpeg-devel ... [22:53:01] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5 has been released! | this chat is now publicly logged. [22:53:01] *** TOPICINFO: Compn, 1264791848 [22:53:06] <BBB> no more comments on the wmavoice codec? [22:53:07] <BBB> going once... [22:53:09] <BBB> going twice... [22:53:20] <Compn> you ran the fuzzer on it ? [22:53:27] <BBB> what is the fuzzer? [22:53:32] <mru> and valgrind? [22:53:38] <Compn> fuzzed input to test if it crashes or leaks memory [22:53:38] <DonDiego> tools/trasher ? [22:53:45] <BBB> oh you guys suck, now you come up witht hat? [22:53:45] <Compn> zzuf [22:53:47] <Compn> lol [22:53:59] <BBB> I don't do valgrind, no linux here [22:54:00] <Compn> BBB : isnt it in developer documentation ? [22:54:13] <Compn> if its not, DonDiego should put it in there [22:55:03] <ramiro> BBB: no linux? what do you develop on? [22:55:30] <Compn> we can guess he devels on windows :P [22:55:45] <DonDiego> no, os x [22:55:46] <mru> if no linux, get linux [22:56:00] <ramiro> IIRC valgrind now claims to work on osx [22:59:32] <BBB> ramiro: macosx [23:00:00] <BBB> let me check [23:00:18] <BBB> $ sudo port install valgrind [23:00:18] <BBB> Password: [23:00:18] <BBB> Error: Port valgrind not found [23:00:19] <BBB> no [23:00:47] <Compn> sudo port update? :P [23:01:04] <ramiro> 19 August 2009: valgrind-3.5.0, for X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux and X86/Darwin (Mac OS X) is available. [23:01:06] <Compn> Valgrind's Mac OS X support is now part of Valgrind's main development trunk. [23:01:31] <DonDiego> http://trac.macports.org/browser/trunk/dports/devel/valgrind/Portfile [23:02:16] <BBB> why isn't it here then? [23:02:20] <BBB> maybe time to update my ports [23:03:34] <BBB> I did just download several more files from random locations on internet [23:03:36] <BBB> and they all play [23:03:46] <BBB> I even found a second sample file using WMAPro-in-WMAVoice [23:03:52] <BBB> maybe I should implement that some day [23:04:34] * Compn runs afk after botching up BBB's attempted commit [23:04:48] <BBB> damn you :) [23:05:21] <BBB> installing valgrind will take ages [23:05:56] <DonDiego> try valgrind after committing then.. [23:06:17] <BBB> no, I'll valgrind it tonight [23:06:19] <BBB> gives me something fun to do [23:06:28] <BBB> did zhentan feng come online today? [23:07:20] <BBB> checking for a supported OS... ok (darwin10.2.0) [23:07:20] <BBB> checking for the kernel version... unsupported (10.2.0) [23:07:20] <BBB> configure: error: Valgrind works on Darwin 9.x (Mac OS X 10.5) [23:07:27] <BBB> valgrind is majorly confused, I'm running 10.6 [23:07:59] <BBB> this won't work [23:08:11] <BBB> I'll do fuzz thingy tonight instead [23:08:15] <BBB> how does trasher work? [23:08:25] <BBB> makes random modifications in files [23:08:25] <BBB> ? [23:13:59] <lu_zero> BBB: you need valgrind svn I'm afraid [23:14:18] <lu_zero> your os is newer than the one supported ^^; [23:14:34] <BBB> I'll valgrind after commit, as diego suggested [23:14:42] <BBB> I'm gonna fuzz tonight and see what that does [23:14:44] <BBB> should be fun [23:14:45] <peloverde> BBB: I don't know about trasher but here is a zzuf tutorial: http://caca.zoy.org/files/zzuf/zzuf-20070225.pdf [23:16:22] <astrange> you need the patch from https://bugs.kde.org/show_bug.cgi?id=205241 [23:19:58] <BBB> damn these developers that can't write portable software [23:20:04] <BBB> even zzuf doesn't compile straight from ports [23:20:44] <astrange> valgrind can't be written portably [23:21:07] <peloverde> http://caca.zoy.org/attachment/wiki/zzuf/zzuf-osx-0.13.tar.gz [23:22:15] <mru> most of it can [23:22:34] <BBB> \o/ [23:22:38] <BBB> thanks peloverde [23:22:40] <BBB> will play tonight [23:22:47] * BBB -> home [23:41:28] <CIA-17> ffmpeg: mru * r21762 /trunk/configure: configure: make mdct and rdft select fft and update other deps [23:41:28] <CIA-17> ffmpeg: mru * r21763 /trunk/configure: configure: add missing mdct deps [23:41:29] <CIA-17> ffmpeg: mru * r21764 /trunk/libavcodec/fft.c: Fix build with --disable-mdct [23:41:30] <CIA-17> ffmpeg: mru * r21765 /trunk/configure: [23:41:30] <CIA-17> ffmpeg: ffplay depends on rdft [23:41:30] <CIA-17> ffmpeg: Spotted by Ramiro. [23:58:40] <CIA-17> ffmpeg: mru * r21766 /trunk/configure: configure: require --arch and --target-os when cross-compiling

1 0

IRC log for 2010-02-10
by irc＠mansr.com 11 Feb '10

11 Feb '10

[01:31:18] <mfg> Is there an example (other than mov and DV) of a demuxer opening another demuxer? I need this for a shoutcast demuxer, but it doesn't really look like that sort of thing is supported (except for dv/mov, but that is too specific). [01:32:24] <Dark_Shikari> I know a format that requires that (vorbis in ogg in avi) but ffmpeg doesn't do that [01:34:03] <mfg> any other suggestions? [01:34:14] <mfg> I think I've run out of ideas. [01:53:42] <Yuvi> Dark_Shikari: pretty soon, I'm merging & sending patches now actually [02:02:56] <CIA-17> ffmpeg: conrad * r21736 /trunk/libavcodec/x86/dsputil_mmx.c: [02:02:56] <CIA-17> ffmpeg: Enable SSE2 (put|avg)_pixels_16_sse2 [02:02:56] <CIA-17> ffmpeg: SVQ1 chroma has been special-cased aligned to 16-bytes since at least r15466 [02:02:56] <CIA-17> ffmpeg: Other architectures also assume 16-byte alignment here too but set STRIDE_ALIGN [02:02:56] <CIA-17> ffmpeg: to 16. [02:21:23] <Dark_Shikari> k [02:23:00] <Dark_Shikari> Yuvi: ah nice, horizontal band approach [02:23:06] <Dark_Shikari> 64 pixel high bands? [02:23:34] <Dark_Shikari> how did you handle the weird deblock ordering where it's required that you deblock the bottom row in that weird order [02:23:34] <Yuvi> 16 for the moment, rendering in coding order is next which will be 64 pixels high [02:24:07] <Yuvi> by deblocking up to current block row - 1, then doing a separate run for the last row [02:24:30] <Dark_Shikari> works [02:25:58] <Yuvi> I'm tempted to just screw the order and do it sanely, but I'd imagine it would become something new for others to bitch at us about [02:26:21] <Dark_Shikari> well it's not bit exact [02:26:46] <Dark_Shikari> and unlike say mpeg-2, we can't get away with non-bit-exactness [02:29:31] <Yuvi> yeah, though it'd be pretty much invisible [02:29:55] <Yuvi> I mean, completely disabling the loop filter doesn't look horrible even at low rates surprisingly [02:31:01] <Compn> mfg : i think thats all of them. both wmv (asx/wmx) and rm (smi/smil) have redirectors, but both of those are sane text formats... [02:31:17] <Compn> well, more sane than binary anyways. damn xml [02:31:38] <mfg> Compn: its not redirection. I'm trying to cover the ogg/vorbis of shoutcast [02:31:59] <mfg> *of=over [02:32:04] <Compn> why would it need two demuxers ? [02:32:18] <Compn> shoutcast is stream like http ? [02:32:45] <mfg> yes, over http. but interleaved in normal stream data are blocks of metadata [02:33:03] <Compn> ah [02:33:26] <mfg> so, the shoutcast demuxer needs to rip them out, and then pass a "normal" stream along to the child demuxer (mp3/ogg/etc) [02:33:32] <mfg> at least, this is how I envision it. [02:33:47] <Compn> mfg : you should actually ask ffmpeg devs how they want it [02:34:10] <Compn> because i know mplayer does shoutcast w/ metadata and its not calling two demuxers iirc [02:34:35] <mfg> yes. FFMPEG doesn't call any demuxers. It handles the stream outside of ffmpeg (from what I recall) [02:34:38] <Compn> something in the streaming just says if metadata do this if mp3 pass to mp3... [02:35:08] <mfg> sorry, mplayer doesn't call any demuxers [02:35:15] <mfg> in teh case of shoutcast, the stream is handled in mplayer. [02:35:40] <Dark_Shikari> Yuvi: put it under lavdopts fast? [02:37:02] <Yuvi> does that set skip_loop_filter? [02:39:07] <Dark_Shikari> dunno [02:39:12] <Dark_Shikari> probably skiploopfilter=all does =p [07:00:11] <benoit-> good (snowy) morning [07:00:42] <kshishkov> bonjour [07:01:04] <kshishkov> here we have ordinary slippery icey morning [07:01:45] <thresh> moroning [07:01:46] <thresh> i'm not even sleepy, though i slept for 12 hours [07:02:25] <kshishkov> thresh: зимняя спячка значит, как у медведей [07:06:38] <thresh> kshishkov: это да, я спать раза в полтора стал зимой больше, чем летом [07:40:05] <KotH> salut [07:40:13] <kshishkov> hej [07:44:27] <_av500_> ho [07:45:17] * _av500_ tries to decypher secret russian code [07:46:04] <kshishkov> _av500_: why not learn Russian instead. It seems to be not that hard when you know German [07:48:23] <_av500_> kshishkov: something about winter, bears, and summer (knowing cyrillic serbian helps) [07:49:03] <kshishkov> _av500_: yes [07:49:23] <_av500_> your secrets are safe with me [07:51:23] <kshishkov> nah, I don't have much secrets anyway [07:53:16] * kshishkov wonders why Serbian uses "код" and "са" particles while their counterparts in Russian are "к" and "с" [07:53:44] <_av500_> so russian compresses more :) [07:54:08] <kshishkov> but it does not have no-vowel words for some reasons [07:54:52] <_av500_> it has not? [07:55:00] <kshishkov> no [07:55:56] <kshishkov> for example archaic word for earth is "твердь" [07:56:25] <_av500_> sounds like "hard" [07:57:02] <kshishkov> yep, they should be related [07:57:12] <kshishkov> and IIRC you have simply "tvrd" [07:57:19] <_av500_> hard(m): tvrd [07:57:35] <_av500_> yep [08:47:57] <merbzt> jez9999: run it through patcheck [08:48:21] <merbzt> ops [08:48:25] <merbzt> abit late [08:48:41] <kshishkov> yes [08:49:26] * kshishkov wonders if some Diego will make patcheck less GNU tools dependent [08:50:51] <kshishkov> DonDiego: as I've said just before your join, any interest to make patcheck run well in non-GNU environment? [08:51:09] <DonDiego> i can look at it [08:51:55] <DonDiego> what's the error? [08:52:16] <kshishkov> different errors with grep on BSD systems, for example [08:52:52] <kshishkov> like MacOSX [08:52:59] <DonDiego> paste please [08:53:11] <DonDiego> does not look unposixlike at a glance [08:53:27] <DonDiego> hmm, --color might not be supported [08:54:13] <kshishkov> "egrep: Unmatched ( or \(" [08:54:21] <DonDiego> line? [08:54:24] <kshishkov> "xargs: illegal option -- d" [08:54:34] <kshishkov> it does not print where though [08:59:11] <Honoome> kshishkov: uhm… grep should be GNU grep… [08:59:29] <Honoome> yeah just confirmed, 10.6 has GNU grep still [09:00:02] <kshishkov> yep, it is [09:00:25] <kshishkov> maybe something wrong with shell itself? [09:00:35] <Honoome> that might be it [09:00:43] <Honoome> the xargs one is definitely GNUism [09:07:26] <siretart> morning [09:07:47] <kshishkov> guten morgen [09:09:07] <siretart> :-) [12:09:57] <KotH> does anyone know a mp3 player with >64GB that isnt a complete pc? [12:11:32] <kshishkov> new iPods? [12:13:22] <DonDiego> Andrius: bentkus? [12:14:06] <Andrius> since I have no clue what you're talking about, probably not [12:14:08] <kshishkov> KotH: Google seems to know, for example - http://www.china-usb.cn/productinfo.asp?id=546 [12:14:39] <KotH> kshishkov: i want an mp3 player, not shackles [12:14:47] <elenril> why do you need that much anyway [12:15:29] <J_Darnley> KotH: a device that supports removable memory [12:15:31] <kshishkov> well, it's mostly the question of 128GB flash cards [12:15:53] <J_Darnley> (but I don't know of one) [12:16:08] <KotH> elenril: because i have about 50G of mp3s [12:16:32] <KotH> J_Darnley: nah.. i dont want to continously change the storage media [12:17:14] * elenril 29G music/ [12:17:48] <mru> 147G [12:17:54] * elenril should pirate mo4r [12:18:17] * kshishkov has it mostly as Flac and APE [12:18:55] <KotH> elenril: i dont pirate [12:19:00] <KotH> elenril: all was legaly downloaded! [12:19:06] <elenril> orly [12:19:10] <KotH> ya rly [12:19:13] <elenril> you don't use torrents at all? [12:19:17] <KotH> i do [12:19:23] <KotH> lots of them [12:19:43] <kshishkov> elenril: if you have not been prosecuted for it, it's legal [12:19:52] <KotH> er.. [12:20:04] <KotH> kshishkov: no, i live in a sane country, where downloading is _not_ illegal [12:20:08] <elenril> KotH: so sharing is legal in chocolateland? i somehow doubt that [12:20:19] <KotH> elenril: nope, uploading is illegal ;) [12:20:20] <mattg> mru: i'm having second thoughts about if that file i sent you works on arm without asm (i said it worked without asm but not with). it's still working on x86 but not on arm though, so something strange is happening for sure. i'll keep you posted [12:20:22] <elenril> or you've disabled sharing [12:20:28] <elenril> then you're even more evil =p [12:20:48] <kshishkov> KotH: well, I don't know what's not illegal here. [12:20:57] <KotH> kshishkov: breathin? [12:21:07] <thresh> not voting for stupid persons [12:21:08] <elenril> do they even have copyright laws in ukraine? [12:21:37] <kshishkov> KotH: well, only because there's nothing worth to breathe either [12:21:40] <elenril> last time i was there people were selling pirated cds in normal shops [12:21:46] <kshishkov> elenril: of course [12:21:55] <kshishkov> they are not pirated :( [12:22:09] <elenril> ofc they are. they even had cracks on them [12:22:17] <kshishkov> when we have pirated CDs they were cheaper and you could easily return or exchange one [12:22:31] <elenril> so it's not done anymore? [12:22:35] <elenril> how sad [12:22:36] <kshishkov> now they all should bear that holographic sticker and cost more [12:22:54] <kshishkov> (not talking about content though) [12:23:29] <kshishkov> elenril: unlike some uncivilized countries, our crime is usually organized and run by government [12:25:24] <elenril> not really [12:25:34] <elenril> same here [12:28:13] <iive> it's the opposite here. our crime is organized and owns the government. [12:28:37] <kshishkov> iive: looks like it would be the way here too very soon [12:30:31] <iive> by government i mean the whole bureaucratic legal judicial and power branches of the country. [12:30:48] <mru> aka criminals [12:30:48] <kshishkov> of course [12:31:22] <kshishkov> mru: not necessarily. They could be blatant idiots instead. [12:31:38] <iive> our current government tries to change the things. Just today there was some hi-profile arrests. [12:31:56] <mru> kshishkov: they are usually both [12:32:37] <iive> they usually pretend to be idiots, while they are pure criminals. [12:33:20] <kshishkov> mru: no, those are just ordinary citizens here. Just think about Rinkeby or Skärholmen [12:34:33] <mru> those are the unlicensed crims [12:35:11] <kshishkov> licensed ones work as police force here [12:40:42] <iive> same here. [12:42:33] <kshishkov> iive: yes, we seem to share a lot of common in recent history [12:45:09] <CIA-17> ffmpeg: andoma * r21737 /trunk/libavformat/mp3.c: mp3: ftell() file offset for VBR tags before ID3v1 parser messes it up. [12:52:26] <Bagder> what's the ffmpeg position on fixed point codecs? are you guys interested in that "for real" ? I'm in the Rockbox camp and we only do fixed point and we're not quite sure what kind of feedback/code you want from us in terms of codec improvements etc [12:53:10] <kshishkov> well, we always wanted to backport your WMA decoder [12:53:33] <DonDiego> Bagder: we're anxiously waiting for your patches [12:53:44] <DonDiego> also, our mp3 decoder is fixed-point and much faster than libmad [12:53:56] <DonDiego> Bagder: what do you use for mp3 decoding in rockbox? [12:54:19] <Bagder> it is libmad based [12:54:27] <Bagder> although rather optimized [12:55:03] <Bagder> we use your flac I believe [12:55:31] <kshishkov> we use your APE decoder [12:56:25] <DonDiego> Bagder: have you compared performance of your libmad fork to ffmp3? [12:57:02] <Bagder> I don't think so. We need a bit of work to get your code into our framework too so its a little more than "just test" [12:57:31] <Bagder> like we work hard to never malloc [12:57:40] <Bagder> which tend to be a bit of fiddle [12:58:14] <jai> who forked libmad? rockbox? [12:58:16] <DonDiego> ffmp3 is 2-3x faster than libmad in my tests on x86 [12:58:28] <DonDiego> so it should be worth investigating [12:58:39] <Bagder> indeed [12:59:00] <Bagder> libmad is in fact already very fast [12:59:18] <DonDiego> no, it's slow as a dog ;) [12:59:18] <Bagder> we're having mp3 playback in something like 30MHz arm [12:59:36] <Bagder> well, our libmad [12:59:44] <mru> last I checked ffmpeg was faster than libmad on arm [12:59:54] <mru> even with hq enabled [13:01:06] <_av500_> Bagder: hi [13:01:11] <DonDiego> ok, a quick check shows i was exaggerating [13:01:15] <Bagder> hey _av500_ ! [13:01:32] <DonDiego> it's more like 50% with the one sample i tested, not >200% [13:01:39] <DonDiego> but still it's very noticeable [13:01:50] <DonDiego> and if you use ffmpeg anyway, then it's one lib dependency less [13:02:10] <Bagder> well, we playback mp3 at 200% realtime in 21mhz arm [13:02:27] <Bagder> and we don't use ffmpeg "libs" anyway [13:02:58] <Bagder> anyway [13:03:13] <Bagder> I wasn't here to compare codecs, but to see what kind of exchange we should get going [13:03:16] <DonDiego> if you can play it at 300% realtime you will use less battery [13:03:29] <DonDiego> ok, let's leave that issue aside for a moment [13:03:35] <DonDiego> we welcome you contacting us [13:03:45] <DonDiego> we have always been hoping for this to happen [13:03:59] <DonDiego> so, in short: we want your code [13:04:00] <DonDiego> :) [13:04:25] <_av500_> DonDiego: spell checked! [13:04:48] <Bagder> DonDiego: ok, fine. That's a really good first step. [13:04:58] <DonDiego> _av500_: urm, what? [13:05:15] <DonDiego> we would like to see all external patches integrated [13:05:21] <_av500_> spelling, no :) [13:05:42] <Bagder> well, our prolem is that our code is usually a bit away from the ffmpeg original [13:05:55] <Bagder> due to our no-malloc and only fixed-point [13:06:04] <DonDiego> http://wiki.multimedia.cx/index.php?title=Interesting_Patches#Fixed_point_c… [13:06:11] <DonDiego> this might interest you as well [13:06:20] <Bagder> right, we have a fixed point cook decoder [13:06:30] <_av500_> ys pls merge that one :) [13:06:36] <DonDiego> http://wiki.multimedia.cx/index.php?title=Interesting_Patches#G.729_decoder… [13:06:46] <DonDiego> that's fixed-point as well i think [13:07:03] <DonDiego> Compn: why isn't the rockbox patch on the interesting patches page? [13:07:22] <DonDiego> Bagder: i think your wma patch was submitted at some point, but never finished.. [13:07:43] <Bagder> I seem to recall that too [13:08:18] <DonDiego> well, submit it again.. [13:08:22] <Bagder> anyway, I'll work on setting up some kind of team of people to get something going [13:08:32] <Bagder> I think we need to work on both ends [13:09:06] <DonDiego> what do you want us to work on? [13:09:10] <andoma> Bagder: btw, me and merbzt are planning to attend the #foss-sthlm event [13:09:16] <Compn> DonDiego : the wma fixed patch ? [13:09:24] <DonDiego> Compn: yes [13:09:25] <Bagder> DonDiego: I need to get back on that, I'm not really a codec guy [13:09:26] <Compn> its on small tasks page i think [13:09:39] <Bagder> andoma: ah right, cool! [13:09:58] <DonDiego> Compn: add it to interesting patches please :) [13:10:15] <merbzt> Bagder: the main issue is we have no good framework for fixed-point [13:10:16] <DonDiego> Bagder: ok, let's get the ball rolling [13:10:42] <Compn> DonDiego : but its not a patch? [13:10:45] <Bagder> right, people in our camp expressed a concern about the fixed/float point situation it might end up in [13:10:52] <merbzt> and then we need dsp routines [13:10:53] <Compn> i mean, where is the patch ? all i see is a repo [13:10:55] <Bagder> but we'll sort it [13:11:16] <DonDiego> Compn: then just link to that.. [13:11:51] <DonDiego> Bagder: i'm sure there will be bumps on the road but nothing that we should not be able to work out.. [13:11:53] <merbzt> regtests would be so much more nice with fixed point codecs [13:12:03] <Compn> DonDiego : done [13:12:09] <Bagder> DonDiego: indeed! [13:12:14] <_av500_> Bagder: btw [13:12:31] <_av500_> our latest players are rk26xx based [13:12:44] <_av500_> and seem to be ugly to programm... [13:12:46] <merbzt> DonDiego: hmm, how about we added a fixed-point fft/mdct as a SoC project [13:13:03] <Compn> DonDiego : wasnt acelp/sipro originally fixed-point too ? [13:13:52] <kshishkov> merbzt: it's rather trivial, just replace multiplications in existing one [13:14:33] <andoma> trivial or not, it would be rather useful for the community I guess [13:14:38] <DonDiego> kugel: hi [13:14:43] <DonDiego> another rockbox guy.. [13:14:51] <kugel> ;) [13:15:03] <Bagder> surely fixed-point fft/mdct stuff can be re-used from Rockbox too? [13:15:14] <DonDiego> i suppose [13:15:18] <Compn> is it lgpl ? :P [13:15:31] <Bagder> its GPLv2+ [13:15:41] <Compn> not really a problem, just curious [13:15:43] <peloverde> Bagder, kugel: I enjoyed your guy's talk at FOSDEM btw [13:15:58] <Bagder> cool [13:16:10] <Compn> did anyone attend html5 talk ? [13:16:23] <kugel> peloverde: that guy was Bagder :) [13:16:30] <kshishkov> Compn: they said it was very crowded [13:16:45] <DonDiego> we could not get in (html 5) [13:18:34] <Compn> hehe [13:18:35] <merbzt> kshishkov: well I think it is a little bit harder then that [13:18:46] <kshishkov> merbzt: why? [13:19:13] <peloverde> Can we reuse the fixed point mdct from tremor, that's BSD [13:19:58] <DonDiego> Bagder: can you get it relicensed? [13:20:11] <merbzt> peloverde: well it doesn't match the float *_half stuff [13:20:29] <Bagder> DonDiego: not likely, most of our stuff is based on upstream stuff [13:20:55] <Compn> DonDiego : tired of maintaining a set of gpl and a set of lgpl code ? [13:21:13] <merbzt> kshishkov: you need to be careful about precision and scaling [13:22:18] <DonDiego> Bagder: that does not necessarily make it unlikely, where does the code come from? [13:22:22] <pJok> how hard would it to do a fixed point mdct at all? [13:22:57] <merbzt> kshishkov: some fft algos are better in that sense [13:23:01] <Bagder> DonDiego: well, pretty much all of our codecs come from different places, so it all differs. [13:23:36] <DonDiego> well, find out about that particular piece of code [13:24:28] <kshishkov> merbzt: could be. BTW, have I mentioned that I had not learnt anything about DSP at university? [13:24:30] <Bagder> which code are you referring to? [13:25:19] <merbzt> Bagder: any code :) [13:25:39] * Bagder throws a tomato at merbzt [13:26:13] <merbzt> anyway, wma and cook needs a fp mdct routine [13:26:36] <peloverde> Looking at this it looks like a slightly modified version of the Tremor code: http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/lib/mdct2.c?revision=23… [13:26:40] <merbzt> Bagder: I'll through it back the 24:th [13:27:01] * Bagder makes a note to bring suitable armor [13:27:26] <kugel> aren't we going to replace the tremor mdct with something better? [13:28:04] <Bagder> yes, that's in a branch [13:28:22] <merbzt> the ffmpeg way ? [13:28:37] <merbzt> mdct_half etc [13:29:16] <Bagder> http://svn.rockbox.org/viewvc.cgi/branches/mdctexp/apps/codecs/lib/mdct.c?v… [13:29:20] <merbzt> I guess saratoga would know [13:29:23] <Bagder> yes [13:29:30] <Bagder> he and stripwax [13:30:00] <Bagder> "In your face Tremor MDCT : now 1.5MHz faster than trunk" :-) [13:30:08] <peloverde> "This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License" Is that correct? :) [13:30:13] <DonDiego> Bagder: i was referring to the fixed-point dcts you talked about.. [13:31:26] <Bagder> I'd really not actually comment too much about specific codec works as I'll just make a fool of myself [13:31:30] <merbzt> Bagder: ok that code looked really good [13:31:56] <merbzt> or the comments [13:32:01] <Bagder> "Copyright (c) 2002 The FFmpeg Project" even :-) [13:32:39] <merbzt> the ffmpeg code is based on Public Domain code [13:32:50] <superdump> andoma: when is that stockholm foss meet up again? [13:32:58] <merbzt> 24:th [13:33:02] <superdump> right [13:33:21] <superdump> it's looking like i'll still be here so i'll probably wander along too ;) [13:33:48] <andoma> cool :) [13:33:59] <kugel> http://www.rockbox.org/wiki/FasterMDCT if it helps [13:34:00] <andoma> Bagder: btw, are the presentations in swedish? [13:34:08] <superdump> i may need reminding though [13:34:17] <Bagder> andoma: yes, they'll be in Swedish [13:34:24] <andoma> good, superdump needs to learn some [13:34:29] <Bagder> haha [13:34:38] <superdump> :) [13:34:46] <superdump> i may be able to follow little bits of it [13:35:25] <kshishkov> superdump: you can recognize "cos" even in Russian [13:37:53] <andoma> ok .. but who will volunteer to implement SBR in fixedpoint? :) [13:38:04] * peloverde hides [13:38:16] <kshishkov> superdump, of course [13:38:30] <superdump> not_peloverde: the low complexity stuff is a bit simpler than the normal sbr [13:38:57] <not_peloverde> It's computationally less complex, But it adds new tools like aliasing detection [13:39:01] <superdump> though i guess it's still float [13:39:02] <superdump> right [13:39:22] <superdump> iirc it ditches the imaginary parts and fixes it with aliasing? [13:39:30] <not_peloverde> yes [13:39:31] <superdump> anti-aliasing rather [13:40:18] <superdump> still, we'd have to have a fixed point lc decoder [13:40:57] <superdump> kugel, Bagder: does faad have a fixed point mode or did you port it or...? [13:41:09] <not_peloverde> Faad has fixed point [13:41:16] <not_peloverde> faad2 anyway [13:42:35] <superdump> ok [13:43:09] <superdump> kugel, Bagder: mdct_half brings a significant speed benefit [13:43:13] <superdump> it's worth looking into [13:47:16] <not_peloverde> http://arstechnica.com/media/news/2010/02/royalty-free-codec-still-needed-d… : "Although Ogg Theora still has some technical limitations, it is advancing rapidly and could have the potential to become a competitive alternative to h264." [13:47:27] * not_peloverde facepalm [13:48:18] <kshishkov> why not? If they switch bitstream format away from VP3... [13:48:31] <mru> yeah, if they switch codec [13:48:35] <merbzt> to h264 [13:48:39] <mru> vp8 [13:48:47] <mru> vp8, if it exists, is probably not far off h264 [13:49:00] * kierank doesn't think it exists [13:49:40] <not_peloverde> If it exists it may step on other peoples' IP [13:51:20] <kugel> we're not really the codec guys of rockbox so we can't comment on most things [13:52:19] <merbzt> Bagder: anyway this new code looks like it would be possible to merge into ffmpeg [13:53:18] <DonDiego> http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-late… [13:53:27] <merbzt> license wise and performance wise [13:54:47] <merbzt> DonDiego: too bad they never answer my emails ... [13:55:10] <kierank> they don't answer anybody's emails [13:56:01] <merbzt> feels more like a publicity stunt then something for the OS community [13:57:29] <kierank> iirc they got goverment money to do that [14:05:07] <superdump> a few billion lines of code? how about a few billion lines of text that i'm not going to read [14:05:43] <kshishkov> superdump: you are lucky. We had to study "War and Peace" at school [14:06:48] <superdump> :) [14:07:12] <not_peloverde> superdump, How do you feel about outputting the first AAC frame? http://ffmpeg.pastebin.ca/1792552 [14:07:24] <DonDiego> bye [14:09:00] <kshishkov> not_peloverde: I always thought that zeroing delay is enough [14:09:02] <twnqx> nice article, nonetheless :) [14:09:46] <Honoome> it doesn't say much more o much different than the Static Analysis book I read recently [14:09:50] <Honoome> although I haven't tried Fortify :/ [14:11:28] <not_peloverde> kshishkov, zeroing? [14:12:12] <kshishkov> not_peloverde: yes, what could be a reason for decoding delay? [14:12:57] <not_peloverde> That's not a delay it's an advance [14:13:13] <not_peloverde> Presumably it's to match the delay on a particular encoder [14:13:54] <not_peloverde> However the right way to handle that is 14496-24 [14:19:55] <superdump> not_peloverde: go for it [14:20:03] <superdump> iirc, that should be needed for full compliance [14:20:13] <superdump> so i don't know why it's there in the first place really [14:21:10] <superdump> i mean removing that code is needed for compliance [14:26:53] <CIA-17> ffmpeg: michael * r21738 /trunk/libavformat/mpeg.c: [14:26:53] <CIA-17> ffmpeg: Dont give up after 100kb of zero bytes but returnd EAGAIN [14:26:53] <CIA-17> ffmpeg: fixes issue1729 [14:52:47] <CIA-17> ffmpeg: alexc * r21739 /trunk/libavcodec/aac.c: Output the first AAC frame. This is needed for SBR conformance. [15:01:20] <kierank> does anyone know of any system that actually uses anything other than DTS/AC-3/PCM over SPDIF? [15:01:41] <merbzt> there is a pioneer rig that uses wmapro [15:03:15] <merbzt> and many receivers support mpeg also [15:05:32] <twnqx> emess claims he built something on his own :> [15:05:37] <twnqx> that can also do flac [15:07:27] <kierank> there's no reason why it couldn't work; there are a few flags codec ids that are still reserved [15:10:26] <twnqx> my soundcard can output 6mbit on spdif... but i don't have a receiver that understands the signal [15:10:42] <_av500_> peloverde: made it back nicely? [15:11:05] <peloverde> yes, travel was pretty smooth [15:11:08] <_av500_> twnqx: you could stream H264 HD over SPDIF :) [15:18:06] <kierank> aes3 in the broadcast world seems to be a place where you just dump stuff you can't invent another transport mechanism for [15:18:47] <kshishkov> for non-broadcast world we have Matroska [15:42:46] <kierank> Any idea what ATRAC-X is? [15:43:25] <kshishkov> merbzt may have some ideas [15:47:35] <kshishkov> it may be multichannel extension of ATRAC-3 [15:47:50] <Tass`> I'm looking through the source... what's exactly 'mdat' ? [15:48:10] <kshishkov> an atom in MOV? [15:48:34] <Tass`> I'm trying to fix an 3gp... and trying to get if it's imporant for mplayer to fail [15:50:55] <jai> also seems to be geared towards n/w streaming [15:52:02] <kierank> hmm maybe i'll just leave some of these other codecs alone because they need codec-specific demuxing [15:52:26] <KotH> btw: anyone already working on the elf muxer/demuxer? [15:52:55] <merbzt> I did something like it one time [15:53:25] <kshishkov> KotH: muxer? self-converting executable? [15:53:45] <merbzt> it added symbols to a stripped binary [15:54:02] <KotH> kshishkov: mux a video(incl audio+subs) and ffmpeg into an elf binary, so that it self-playing :) [15:54:20] <jai> merbzt: where did you get the symbols from? [15:54:31] <kshishkov> KotH: s/ffmpeg/ffplay/ then [15:54:47] <KotH> or maybe s/ffplay/mplayer/ ;) [15:55:21] <merbzt> jai: another binary or just out of thin air [15:55:40] <jai> merbzt: :) [15:55:40] <kshishkov> KotH: then it's a feature for mencoder :P [15:57:13] <merbzt> objdump uses those names [15:57:24] <merbzt> and gdb [15:57:42] <merbzt> made it easier to debug something [15:57:47] <merbzt> I can't really remember [15:59:44] <jai> merbzt: you suggested this approach to me once, i forgot all about it :| [16:00:55] <merbzt> I forgot I even suggested that to you [16:01:43] <kshishkov> merbzt: ever thought about adding debug capabilities to MPlayer DLL loader? [16:02:32] <merbzt> debug how ? [16:03:09] <kshishkov> to make it possible print register data at certain addresses, for example [16:03:23] <kshishkov> 'twas quite useful for RV4 [16:04:31] <merbzt> ah ok, I have just patches the wrapper when I messed with mplayer [16:08:12] <kierank> Any idea what the difference between "7.1" and "7.1 Screen" is? [16:08:28] <kshishkov> " Screen" [16:08:54] <kierank> :/ [16:08:58] <KotH> wtf... [16:09:08] <kshishkov> if you talk about audio codec maybe it's studio processing and final output difference [16:09:27] <KotH> i just looked up when linuxtag is... and was greeted by a pic of us at linuxtag community party 2007 [16:10:28] <bilboed-pi> google, now with brainreading features [16:11:10] <kshishkov> bilboed-pi: if it also develops conscience it'll prefer kill itself than read our minds [16:11:28] <bilboed-pi> or grow up into skynet [16:11:33] <bilboed-pi> dunno which one is worse [16:11:56] <mru> KotH: wasn't that the 2008 party? [16:12:04] <kshishkov> Terminators were cool [16:18:50] <KotH> mru: ack, 2008 [17:21:41] <CIA-17> ffmpeg: rbultje * r21740 /trunk/ (6 files in 2 dirs): RTP/AMR depacketizer, by Martin Storsj? <$firstname at $firstname dot st>. [17:29:35] <_av500_> kshishkov: berlin is like ukraine, except for major roads, all the rest is ice fields [17:30:08] <kshishkov> what do you expect from East Germany? [17:30:24] <_av500_> right [17:30:54] <kshishkov> it seems to me the best part of Germany is South-West [17:30:59] <_av500_> each year i get more and morre strange looks calling it that [17:31:15] <_av500_> kshishkov: !east :) [17:31:36] <kshishkov> call it ex-DDR then [17:32:04] <kshishkov> _av500_: also I'd like to add that North Germany seems to be less clean than South [17:32:30] <_av500_> huh [17:32:52] <mru> KotH would say it's further from .ch... [17:33:27] <KotH> juup, that's definitly a disadvantage [17:34:04] <kierank> biggest shock when going to germany is the lack of bins [17:34:18] <kshishkov> I've been to Bavaria once [17:34:24] <kierank> and weird road signs with pictures of tanks [17:34:25] <_av500_> mru: brussels is north, eh? [17:34:36] * _av500_ likes his tank [17:34:46] <mru> that's .be, which is in a league of its own [17:35:07] <kshishkov> mru: and who wrote that "Belgium" is the worst curse in the Universe? [17:35:33] <_av500_> the 42 guy [17:36:17] <kshishkov> then it must be true [17:36:46] * _av500_ has not seen many planets though.... [17:36:56] <_av500_> except through lens [17:38:59] <kshishkov> don't panic [17:39:54] <Honoome> lu_zero: back home? [17:48:27] <lu_zero> sort of [17:48:45] <BBB> hi lu_zero [17:48:49] * lu_zero still needs to discover how to fix his idiotic router... [17:48:50] <BBB> is the rtp/theora spec done? [17:49:03] <lu_zero> BBB: not yet [17:49:04] * Honoome keeps from laughing [17:49:09] <BBB> :) [17:49:14] <Honoome> what about snow? :D [17:49:17] <BBB> Honoome, why do you think I keep asking? [17:49:32] <Honoome> BBB: hehe yeah I know :) [17:49:43] <lu_zero> what's with snow? [17:49:50] <lu_zero> snow is a michael toy [17:49:51] <BBB> it'll make us look good in the freetard community [17:50:02] <BBB> ^d^d^d [17:50:14] <lu_zero> with almost no will to be mainstream let alone useful [17:50:51] <lu_zero> BBB: I'd rather mess a bit with the latest flurry of patches about rtp/rtsp etc [17:50:56] <lu_zero> (muxer included) [17:51:28] <elenril> snow is patent encumbered and therefore evil! [17:51:32] * elenril hides [17:51:34] <lu_zero> how so? [17:51:37] <lu_zero> which patent? [17:51:44] <BBB> I didn't review martin's latest round yet [17:51:48] <BBB> (muxer) [17:52:12] <BBB> ps please please let me apply my rtp-crash-on-unknown-codec patch, even if you don't like it [17:52:16] <BBB> it only removes code [17:52:18] <BBB> doesn't add any [17:52:36] <elenril> dunno, but somebody here said wavelets were patented beyond the impossible [17:52:53] <lu_zero> give me a ref [17:53:04] <_av500_> &p [17:53:40] <Honoome> lol [17:54:04] <elenril> wait until Dark_Shikari wake up, he probably knows something [17:54:10] <BBB> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/074943.html [17:54:29] <BBB> I really want that patch in :) [17:54:58] * BBB should also resume work on getting the svq1/qdm2 depayloaders in [17:55:03] <BBB> those are easy [17:56:27] * Honoome should find time to make the metadata hash table generic and move it to libavutil so that feng/libnemesi can use it :P [17:56:46] <elenril> what metadata hash table? [17:57:06] <Honoome> elenril: well libavformat uses an hash table for metadata, doesn't it? [17:57:14] <jai> key-value pairs [17:57:37] <elenril> avmetadataconv? [17:57:57] <elenril> why would you want to use it? [17:58:32] <kierank> would be nice if you could make per packet metadata while you're at it ;) [17:58:32] <jai> because any serious media framework needs to use av prefixed stuff ;) [17:59:04] <Honoome> elenril: for libnemesi we're needing an hash table (key/value pairs, dictionary, call it what you wish :P) for parsing the headers… right now in feng we use glib's, but we wanted to avoid glib in libnemesi [18:00:42] <jai> calling it a "hash table" doesnt seem right to me, because you cant do lookups in O(1) [18:01:32] <jai> though i guess you cant hash everything perfectly :) [18:01:37] <jai> so meh [18:02:03] <jai> kierank: btw, do you have a bigger AOB sample? [18:04:06] <Honoome> jai: well, it's still an hash… identity hash :D [18:04:27] <lu_zero> s/libnemesi/robust and flexible rtsp parsing [18:04:35] <mru> hash tables are a subset of key/value mapping systems [18:04:48] * _av500_ wants to avoid glib in everything [18:05:17] <mru> also in glibc [18:05:19] <jai> Honoome: as mru said [18:05:24] <mru> plain c is much better [18:05:42] * _av500_ remembers libmms that invokes glib to do a couple of frakin gstrdups... [18:06:01] <jai> a well designed hashing scheme would still be better, and i assumed you wanted something like that [18:06:05] <Honoome> potato, potato… at the end, once generic it can as well be a hash map rather than just a lookup :P [18:06:21] <elenril> doesn't hash table have to be sorted? [18:06:34] * elenril has zero theoretical knowledge about programming [18:06:35] <kshishkov> nope [18:06:37] <jai> elenril: ? [18:06:38] <jai> no [18:06:43] <Honoome> what we need for libnemesi is not much different from what is needed for metadata handling [18:07:02] <jai> Honoome: does libnemesi already use libavutil? [18:07:03] <kshishkov> elenril: hash just maps larger keys into smaller table [18:07:19] <Honoome> jai: should, and if not it will ;) [18:07:39] <lu_zero> jai: libnemesi doesn't use anything right now [18:07:46] <jai> Honoome: right, k [18:08:06] <lu_zero> and I'd be way happier to have it merged inside libavformat in the end [18:08:16] <jai> tbh, i dont know much about it, except that lu_zero works on it :) [18:08:56] <lu_zero> (but given that could be a looong route because of the use of generated parsers better do that step by step...) [18:09:57] <jai> lu_zero: while you are around, quick question : how hard would it be to paginate roundup such that i can jump to page N directly from the listing [18:10:37] <_av500_> or offer to not paginate? [18:10:55] <jai> or that :) [18:11:06] <BBB> lu_zero, did you check the patch? [18:11:11] * _av500_ has motorized mouse wheel [18:11:55] <lu_zero> jai: I need to try to see [18:11:57] <lu_zero> btw [18:12:05] <lu_zero> I'd need to update it soonish [18:12:33] <jai> lu_zero: at your pace of course :) [18:12:44] <jai> infact maybe recent versions of roundup already do it? [18:13:27] <lu_zero> jai: think about roundup as a library [18:13:41] <lu_zero> BBB: still I'm not so fond of it, commit anyway [18:13:51] <lu_zero> it shouldn't break much stuff [18:13:58] <lu_zero> now... [18:14:30] * lu_zero syncs and checks the new roundup [18:15:41] <ramiro> lu_zero: with michael's bug bounty system you can get quite a lot of cash from fixing your old roundup bugs =) [18:16:58] <jai> ramiro: hehe :) [18:17:09] <jai> bugrot == profit [18:17:28] <KotH> bug bounty? [18:17:34] <KotH> did i miss something? [18:17:45] <mru> only a proposal [18:18:02] <jai> KotH: the thread is "[RFC] Bug Bounty" [18:18:40] <Compn> KotH / mru : we probably need a new tag in roundup for that [18:18:46] <Compn> bug bounty tag :) [18:19:05] <KotH> Compn: roundup is lucas thingy [18:19:15] <Compn> ah [18:19:19] * Compn forgot [18:20:58] <lu_zero> ramiro: eh... [18:22:53] <mru> http://www.youtube.com/watch?v=9BnLbv6QYcA [18:24:50] * _av500_ is on 56k :( [18:25:35] * jai is on 56k as well [18:26:59] * kshishkov is on Gdium [18:27:07] <mru> kshishkov wins [18:27:13] <_av500_> http://www.youtube.com/watch?v=9BnLbv6QYcA&vo=libaa [18:27:23] <mru> lol [18:27:40] * BBB commits quickly before lu_zero changes his mind [18:27:53] <mru> _av500_: hey, they should do that [18:28:15] <mru> it's no sillier than the comment text2speech preview [18:29:03] <kshishkov> well, if you can get that proposal to xkcd, it will be implemented [18:31:46] <CIA-17> ffmpeg: rbultje * r21741 /trunk/libavformat/rtsp.c: [18:31:46] <CIA-17> ffmpeg: Don't forget to set known audio parameters (samplerate, etc.) if the codec is [18:31:46] <CIA-17> ffmpeg: not supported in FFmpeg. This will cause crashes later because the samplerate [18:31:46] <CIA-17> ffmpeg: is used to initialize the timebase. [18:32:35] <CIA-17> ffmpeg: rbultje * r21742 /trunk/libavformat/rtsp.c: Reindent after r21741. [18:35:15] <BBB> another crash fixed... [18:35:17] <BBB> hmm... [18:40:52] <_av500_> the 1st class in this train has thinkpad ratio of 95% [18:41:26] <kshishkov> DB Regio? [18:41:44] <_av500_> berlin frankfurt ice [18:42:03] <_av500_> and they are doing ppt, I am the only one to write code :) [18:42:18] <kshishkov> loser [18:42:36] <peloverde> Which bug resolution in roundup is closest to "NOT A BUG"? invalid? wont_fix? [18:42:48] <kshishkov> invalid [18:42:54] <_av500_> works_for_me [18:47:08] <jai> i'd say invalid [18:48:24] <peloverde> I went with invalid [18:49:00] <peloverde> issue1401 if anyone is interested [18:55:23] <Spulit> Hi there! [18:55:32] <peloverde> hello [18:56:11] <Spulit> Any main developer here? I want to ask if there's any work being done in order to support Broadcom's CrystalHD... [18:56:31] <kshishkov> no, main developer never appears here [18:56:56] <_av500_> i am main non-dev here! [18:57:10] <Spulit> or any one that can reply to this question? :) [18:57:11] <Honoome> kshishkov: Fabrice? :P [18:57:27] <kshishkov> for CrystalHD ask gb [18:57:40] <kshishkov> Honoome: not anymore. MN [18:57:59] <Honoome> kshishkov: yes I know I was just kidding ;) [18:58:47] <Spulit> My company is developing a new product that needs CrystalHD working with VLC and is willing to donate to have this implemented ASAP... [19:01:04] <ramiro> mike melanson tried: http://multimedia.cx/eggs/installing-crystalhd-drivers-in-linux/ [19:01:31] <ramiro> someone might be interested in being hired to implement it. contact the ffmpeg-devel mailinglist. [19:01:34] <_av500_> Spulit: what is the price of this one? [19:02:21] <Spulit> I already saw that link...the problem for now are not the drivers, but the players support for the card... [19:02:50] <Spulit> _av500_: what is the price of what? [19:02:56] <kshishkov> I've heard that XBMC supports it already [19:03:45] <Spulit> Indeed, but it only works with files. I needed it play IPTV streams (mostly interlaced contents), and xbmc doesn't handle that well... [19:34:12] <CIA-17> ffmpeg: lucabe * r21743 /trunk/libavformat/rtpenc.c: [19:34:12] <CIA-17> ffmpeg: Fix syncronisation for streams with a high encoding delay. [19:34:12] <CIA-17> ffmpeg: Patch by Timo Ter?s (timo DOT teras AT iki DOT fi) [19:44:47] <CIA-17> ffmpeg: reimar * r21744 /trunk/libavformat/seek.c: [19:44:47] <CIA-17> ffmpeg: Use av_compare_ts from libavutil instead of the locale compare_ts, the [19:44:47] <CIA-17> ffmpeg: calculations in the later one are not correct with large time stamps. [19:47:48] <CIA-17> ffmpeg: reimar * r21745 /trunk/ffmpeg.c: [19:47:48] <CIA-17> ffmpeg: Use av_compare_ts to compare against the -t end time instead of using [19:47:48] <CIA-17> ffmpeg: floating point. [19:47:48] <CIA-17> ffmpeg: Should fix different results between PPC and x86 for the idroq-video-encode [19:47:48] <CIA-17> ffmpeg: FATE test. [19:53:10] <twnqx> is the status of a variable used in a for-loop undefined on exit? [19:53:27] <_av500_> no [19:53:30] <_av500_> err [19:53:45] <_av500_> where is it defined? [19:54:16] <twnqx> http://pastebin.com/d4559e251 - i is defined at the beginning of the function [19:54:17] <_av500_> int i is defined after the loop [19:54:33] <twnqx> i don't lkike this new style stuff :P [19:54:54] <twnqx> but even if the opcode is not in the array... the printf never triggers [19:55:00] <twnqx> without the break it does [19:55:10] <twnqx> sadly, always. [19:55:33] <_av500_> err, you miss {} [19:55:43] <_av500_> you always break [19:55:57] <twnqx> *head -> desk* [19:56:08] * _av500_ throws pillow [19:56:18] <twnqx> thanks... [19:56:36] <twnqx> both for the heads up and the pillow. [19:56:51] <_av500_> :) [19:57:07] * twnqx goes to add more than "NOP" to the opcode table [19:57:25] <ramiro> the nopcode table? [19:57:30] <_av500_> what do you build? [19:57:32] <twnqx> currently it is ;) [19:57:42] <twnqx> just a debugging tool for my radeon GPU stalls [19:58:06] <_av500_> it stalls on NOP? [19:58:24] <twnqx> actually i'm trying to giure that out, so i need to decode all the opcodes the driver sends [19:58:28] <twnqx> figure* [20:07:41] <mru> HCF? [20:07:45] <mru> halt and catch fire [20:27:45] <CIA-17> ffmpeg: daniel * r21746 /trunk/libavformat/wav.c: Fix demuxing of wav files with broken data header [20:28:12] <Compn> where is kostya [20:28:22] <Compn> i want to complain that his side of the world is sending snow to my side of the world [20:28:44] <CIA-17> ffmpeg: daniel * r21747 /trunk/libavformat/wav.c: Reindent [20:30:59] <elenril> snow is great [20:32:05] * elenril has tons of snow around [20:32:10] <peloverde> elenril, the codec or the stuff that's shut down the eastern US? [20:32:18] <elenril> both [20:46:19] <mru> btw, I got my tegra2 board today [20:47:03] <_av500_> mru:rooted and jailbricked? [20:47:21] <mru> haven't booted it yet, need psu [20:47:37] <mru> I can steal one off something else or buy one tomorrow [20:47:43] <_av500_> 12v? [20:48:09] <mru> says 15V [20:48:19] <mru> I'd be surprised if it didn't work at 12 though [20:48:22] <_av500_> use 3 usb posrts :) [20:52:33] <_av500_> 15v sounds supicious for mobile platform... [20:52:38] <_av500_> +s [21:10:04] <peloverde> When did fate turn all yellow? [21:13:29] <Honoome> peloverde: it's having some problem with the liver… [21:13:47] <kierank> too much drinking [21:14:02] <peloverde> It's not just a FATE bug, a bunch of streams are actually crashing like crazy [21:18:40] <peloverde> or maybe Yuvi [21:43:07] <Yuvi> the number of frames decoded by -t changed recently [21:44:55] <peloverde> Yuvi, vp6 is hard crashing [21:45:06] <peloverde> on the first frame [21:45:16] <Yuvi> yeah, looking at it now [21:45:28] <Yuvi> but most of the other failing tests are due to -t [21:46:07] <peloverde> yes but vp6 didn't start crashing until you screwed with (put|avg)_pixels_16_sse2 [21:46:19] <peloverde> which is coincidentally where the crash occurs [21:51:33] <Yuvi> I really wanted to up STRIDE_ALIGN to 16 for that, but michael is dead set against it :/ [21:52:05] <mru> many platforms already have it at 16 [21:52:35] <Yuvi> I know, and it ought to be at 16 for sse too, but instead svq1 is special cased in get_buffer [21:52:48] <mru> insane [21:52:50] <Dark_Shikari> that's retarded [21:52:55] <Dark_Shikari> for x264 we use up to 64 :/ [21:53:06] <mru> cachesplit stuff? [21:53:08] <Dark_Shikari> yes [21:53:23] <Dark_Shikari> 16 base, 64 max [21:53:40] * mru points at comments in av_malloc() [21:54:15] <Dark_Shikari> we don't actually align to 64, but we align the stride to 64 [21:54:44] <mru> what good does that do? [21:55:02] <mru> yeah, of course [21:55:41] <Dark_Shikari> aligning the stride lets you use cachesplit sad functions [21:55:47] <Dark_Shikari> which assume each line of the image has the same (mis)alignment [21:55:53] <mru> I realised that [21:56:25] <mru> i7 finally fixed that, right? [21:56:31] <Dark_Shikari> yes [21:56:47] <mru> and i5 I presume [21:57:23] <Dark_Shikari> yes, nehalem in general [22:15:14] <CIA-17> ffmpeg: mru * r21748 /trunk/configure: configure: fix cosmetic typo in check_mathfunc [22:15:15] <CIA-17> ffmpeg: mru * r21749 /trunk/configure: [22:15:15] <CIA-17> ffmpeg: Stricter check for math.h functions [22:15:15] <CIA-17> ffmpeg: GCC is sometimes able to optimise constant calls to these functions, [22:15:15] <CIA-17> ffmpeg: incorrectly indicating that they exist. Unoptimised calls will then [22:15:15] <CIA-17> ffmpeg: fail to link. [22:34:48] <KotH> night boys [22:34:51] <andoma> nite [22:36:58] <_av500_> ramiro: welcome to linux-davinci :) [22:39:02] <ramiro> _av500_: I've been in it for years, I've just never used it much =) [22:39:41] <_av500_> :) [23:09:00] <pengvado> we don't actually align to 64 <-- but I think my weird performance in plane_copy has to do with mod64, so maybe we should [23:09:11] <pengvado> course I still don't know why the weirdness happens [23:09:19] <CIA-17> ffmpeg: diego * r21750 /trunk/libavutil: Ignore generated header avconfig.h. [23:37:29] <CIA-17> ffmpeg: stefano * r21751 /trunk/cmdutils.c: [23:37:29] <CIA-17> ffmpeg: Extend show_pix_fmts(), make it show input/output support for [23:37:29] <CIA-17> ffmpeg: conversion and other information exposed by the pixdesc API.

1 0

IRC log for 2010-02-09
by irc＠mansr.com 10 Feb '10

10 Feb '10

[00:22:55] <CIA-17> ffmpeg: michael * r21694 /trunk/libavcodec/h264_direct.c: Reorder and factorize mb_type ifs, 1 cpu cycle faster and simpler. [00:24:25] <astrange> 1? [00:44:46] <Dark_Shikari> 1? lol [00:48:49] <Honoome> mru: so right now the metadata handling has an hash table in libavformat… could we get that to use a general implementation in libavutil to make it usable by libnemesi, pretty please? :D [00:50:04] <Honoome> and after this request (checked on ffmpeg's code this morning with Luca, I got home about at 2300), I think I'll resume the usual schedule: shower, then bump, hack, do stuff a bit, then sleeeep ^^;; [04:57:22] <Dark_Shikari> I think elecard's decoder may have eclipsed quicktime as the most buggy h264 decoder [04:57:44] <Dark_Shikari> I'm up to at least the 5th bug found just through x264 streams [04:58:11] <Dark_Shikari> someone should make a stream analyzer that uses libavcodec, so that it isn't as broken [05:01:49] <Compn> you still test quicktime? :P [05:02:49] <Dark_Shikari> no [06:39:30] <Dark_Shikari> michael posted a response to IRC on the ML [06:39:31] <Dark_Shikari> how many known sec holes does 0.5 have? [06:39:31] <Dark_Shikari> do you guys want to backport all security fixes or just release a 0.5.1 [06:39:32] <Dark_Shikari> with 12 months of unfixed secholes? [06:39:40] <Dark_Shikari> siretart: ^ [07:16:28] <benoit-> hej [07:16:34] <kshishkov> hejsan [07:39:40] <siretart_> Dark_Shikari: I just wrote michael a private mail, asking for a few more days. I'm not really available today [07:39:56] <Dark_Shikari> I think he's asking which one you intend to do [07:40:47] <siretart_> the one that I already have in the package? [07:41:03] <siretart_> in fact, there is about a dozen of patches [07:51:45] <superdump> is this re: michael's re to the irc log? [07:51:53] <Dark_Shikari> yes [07:51:57] <superdump> about backporting sec fixes [07:56:10] <CIA-17> ffmpeg: kostya * r21695 /trunk/ (8 files in 3 dirs): Indeo 5 decoder [07:56:31] <superdump> \o/ [07:56:58] <Dark_Shikari> \o/ [07:57:00] <superdump> today is a truly great day [07:57:03] <superdump> :) [07:57:17] <superdump> i remember all those years ago when i actually wanted to decode indeo 5 [07:57:22] * kshishkov goes to update issue 142 [07:57:27] <Dark_Shikari> it's still the second most popular missing video format in ffmpeg [07:57:38] <kshishkov> same with me, but it turned out I wanted more to decode Indeo 4 [07:57:43] <superdump> i don't remember what it was actually used for [07:58:13] <astrange> oh, i meant to write a comment about the bink decoder, but i forgot it [07:58:30] <astrange> i think it was about if(get_bits1(&gb)) x = -x; [08:00:56] <kshishkov> I've just looked at it, seems fine [08:01:16] <astrange> it seemed like it could be branchless [08:01:35] <Dark_Shikari> int bit = get_bits1(&gb); [08:01:44] <Dark_Shikari> x = (x + bit) ^ bit; or something similar [08:01:48] <Dark_Shikari> forgot the exact sequence [08:02:30] <kshishkov> it can - get_bits1() * 2 - 1 [08:02:38] <kshishkov> and multiply by x [08:03:00] <Dark_Shikari> slower [08:03:03] <Dark_Shikari> my method is two ops [08:03:12] <Dark_Shikari> it's the same method as absolute value [08:03:14] <Dark_Shikari> conditional negation [08:03:21] <Dark_Shikari> x = (x - sign) ^ sign; [08:03:23] <Dark_Shikari> is absolute value [08:03:39] <Dark_Shikari> oh, you have to do "int bit = -get_bits1(&gb);" [08:03:48] <Dark_Shikari> since "sign" must be -1 if negative, 0 if positive [08:03:54] <Dark_Shikari> so that's three ops [08:03:58] <Dark_Shikari> negate, subtract, xor. [08:04:09] <kshishkov> isn't -x = ~x + 1 ? [08:04:33] <Dark_Shikari> that's how the trick works [08:04:46] <Dark_Shikari> (x - sign) ^ sign [08:04:50] <Dark_Shikari> if sign == 0, it == x [08:04:56] <Dark_Shikari> if sign == -1, (x + 1) ^ -1 [08:05:00] <Dark_Shikari> which results in ~x + 1 [08:05:06] <astrange> too bad there's an fp copysign() but not an integer one [08:05:14] <kshishkov> it should be other way around - x^sign - sign [08:05:42] <kshishkov> calculate it for x = 1 for example [08:06:48] <Dark_Shikari> (x - sign) ^ sign [08:06:53] <Dark_Shikari> (x - -1) ^ -1 [08:06:59] <Dark_Shikari> (0) ^ -1 [08:07:00] <Dark_Shikari> -1 [08:07:01] <Dark_Shikari> correct. [08:07:13] <kshishkov> x - -1 = 2 [08:07:27] <Dark_Shikari> er, then it's (x+sign)^sign. [08:08:24] <kshishkov> that could work [08:09:34] * kshishkov suspects that in Bink video decoder performance would be #1 priority [08:10:32] <Dark_Shikari> I would say compatibility is [08:10:38] <Dark_Shikari> we don't intend to provide a replacement for bink's libraries [08:10:43] <Dark_Shikari> for games, etc [08:14:00] <kshishkov> but at least one engine uses it alreadt [08:14:03] <kshishkov> *already [08:14:22] <KotH> salut! [08:14:22] <Dark_Shikari> isn't that rather pointless? [08:14:32] <Dark_Shikari> assuming bink owns patents, games will probably still want to buy the royalty [08:14:36] <Dark_Shikari> er, buy the license [08:14:41] <Dark_Shikari> at which point there's no benefit gained by not using official software [08:15:03] <kshishkov> I mean opensource recreation of game engine [08:15:16] <Dark_Shikari> ah. [09:20:15] <jez999> pross-au: now i'm thinking of implementing the source address limitation by adding it to the URL in string form [09:20:26] <jez999> like "file.sdp?sourceaddr=1.2.3.4&sourceaddr=2.3.4.5 [09:20:27] <jez999> " [09:21:31] <pross-au> rgr [09:21:38] <pross-au> thats another optiom [09:21:44] <pross-au> *option [09:31:37] <jez999> apparently more platform-independent [10:49:55] <mru> morning [10:50:40] <kshishkov> god engelsk morgon [10:51:16] <benoit-> good morning [12:01:49] <ramiro> siretart: ping [13:55:07] <jez9999> this place is a morgue today [13:59:32] <_av500_> let the dead rest in piece [14:00:07] <mru> rest in pieces? [14:00:14] <_av500_> mru: ys [14:00:21] <mru> pisces? [14:00:56] <_av500_> yuck [14:01:17] <kshishkov> depends on if you are in astrology or Quake [14:02:03] <_av500_> or a fishmonger [14:05:11] <mru> in swedish "the fishes" and "the fishermen" have the same translation [14:05:19] <mru> "fiskarna" [14:06:04] <kshishkov> "far, f\aar f\aar f\aar? nej, f\aar f\aar lamm" [14:07:10] <mru> "buffalo buffalo buffalo buffalo buffalo buffalo buffalo buffalo" [14:07:13] <mru> add punctuation [14:07:27] <_av500_> ,.,.!?1 [14:07:41] <kshishkov> IIRC, some of the b's were capital [14:08:03] <_av500_> mru: guess what, gg writes their own media fw.... [14:08:13] <mru> "dogs dogs dog dog dogs" [14:08:37] <_av500_> patches patchesp patches patches [14:09:05] * kshishkov thinks it will reduce to "developers developers developers" [14:09:14] <thresh> ехал гитлер через гитлер [14:15:20] <KotH> kshishkov: but you'd have to jump around and shout for 5 min [14:15:46] <kshishkov> KotH: not me [14:15:49] <kierank> who said sit down! [14:16:36] <kshishkov> throw a chair! [14:16:52] * KotH throws Jag0 trough the channel [14:18:34] <kshishkov> do you know him? [14:18:45] <KotH> no [14:18:47] <mru> now he knows KotH... [14:18:56] <kshishkov> or just testing how far you can trust him? [14:18:57] <KotH> do i have to know him to be able to throw him? [14:19:09] * KotH doesnt trust anyone [14:19:48] <kshishkov> and you are rumored to have visited MN [14:20:07] <KotH> i never acknowledeged it [14:20:13] <KotH> and i never said i trust mn [14:20:42] <_av500_> KotH: jihad, jihad, jiahd? [14:21:45] <KotH> _av500_: nope [14:21:55] <KotH> _av500_: JIHAD! JIHAD! JIHAD! [14:21:56] <KotH> ;) [14:21:58] <_av500_> right [14:22:28] * KotH did that once at a party [14:22:33] <KotH> after that, everyone knew me :) [14:22:39] * kshishkov remind KotH that Turks were always afraid of Ukrainians [14:22:44] <jai> way to break the ice... [14:22:57] <KotH> kshishkov: afraid? i doubt so [14:23:13] <KotH> kshishkov: but who wants a country that's in worse state than iraq? [14:24:31] <kshishkov> KotH: it was since Turkey foundation and till XVIIth century, I think [14:28:11] <benoit-> KotH: and you wonder why I don't want you at my wedding :) [14:28:39] <_av500_> benoit-: the turks bring a lot of gold to weddings [14:28:52] <KotH> benoit-: lol [14:29:35] <kshishkov> _av500_: too bad those Turks hhaven't heard of that [14:30:08] <_av500_> at least they bring schoggi [14:30:25] <mru> _av500_: gold... hmm, might invite KotH to mine then, if it ever happens [14:30:27] <kshishkov> kebab [14:30:38] <kshishkov> mru: too gold mine [14:30:42] <kshishkov> *to [14:30:45] <_av500_> mru: gold plated DB9? [14:31:13] <mru> you said "a lot" [14:31:23] <KotH> gold plated db25? [14:31:28] <drv> lol [14:32:03] <drv> must be sure to buy an aston marton serial port for my next box [14:32:12] <kshishkov> a simple 100g gold bar is enough [14:32:18] <KotH> mru: and you cannot complain, with all the schoggi you got :) [14:32:57] <KotH> kshishkov: i'd send you one, if i could make sure it would reach you and not got.. "displaced" at customs [14:33:30] <kshishkov> KotH: send me a swiss resident permit instead [14:36:45] <_av500_> kshishkov: it is called "a million dollar" and might be hard to send to you as well [14:37:14] <kshishkov> _av500_: there should be other ways [14:37:52] <kshishkov> if I had $1m I could apply as political refuge [15:02:23] <_av500_> kshishkov: if you had $1m you could apply as anybody :) [15:05:31] <kshishkov> _av500_: it's next to impossible to earn that kind of money here and not be tangled into politics [15:11:43] <mru> well, go buy some red tape and get started [15:13:10] <KotH> _av500_: well.. i dunno how it is in .de, but in .ch someone with $1m is considered poor ;-) [15:14:16] <twnqx> in .de it's RICHFAG [15:14:24] <twnqx> because, you know, taxes :P [15:15:07] <KotH> twnqx: taxes? [15:15:17] <mru> if you have that kind of money you don't pay taxes [15:15:18] <twnqx> exactly. [15:15:19] <KotH> twnqx: i thought every german has an account in .ch? :) [15:15:25] <twnqx> well *i* do [15:15:31] <_av500_> KotH: could you ask if i am on the CD? [15:15:44] <KotH> _av500_: i'm not data broker ;) [15:16:08] * KotH only deals in money, weapons, women and drugs [15:16:20] <twnqx> one nuclear warhead, please [15:16:33] * KotH doesnt sell these [15:16:45] <twnqx> :( [15:16:45] <_av500_> twnqx: ask kshishkov, he is closer to them [15:16:54] <KotH> i wouldnt want to give anyone something that might kill all my prospective customers, would i? [15:24:45] <jez9999> BBB: hey [15:28:05] <kshishkov> twnqx: ask thresh, he is the closest to them [15:28:47] <thresh> i know a guy who knows a guy who knows another guy and i think we can make a deal [15:29:18] <kshishkov> otherwise, you can always buy one at North Korea, ask mru for help [15:30:13] * mru doesn't know any north koreans [15:30:36] <kshishkov> well, you know south koreans [15:31:20] <mru> they're not allowed anywhere near the border [15:31:20] <_av500_> only need to s/nor/sou/ [15:31:28] <KotH> or just go diving in florida [15:31:49] <KotH> there is still a bomb liying there, waiting to be found [15:31:49] <jez9999> BBB: slight problem with the idea of putting valid source IP(s) in the URI's query string. not all URIs support query strings. :-) [15:32:48] <BBB> jez9999, ? [15:32:58] <jez9999> most problematically, file: [15:33:04] <BBB> you mean http://uri?opt=x would be problematic? [15:33:05] <BBB> we know that [15:33:07] <BBB> it sucks [15:33:18] <mru> jez9999: files don't have a source address [15:33:19] <BBB> I've been sitting on a solution for that for a while, and it's not done yet [15:33:22] <mru> so why does it matter? [15:33:28] <jez9999> they do if they represent a stream (sdp) :-) [15:33:33] <mru> eh? [15:33:44] <jez9999> sdp demuxer parses the sdp file and opens a udp port [15:33:49] <BBB> mru: sdp files is a "hack" for rtsp without the manager connection [15:33:56] <mru> omg [15:33:56] <BBB> mru: it's quite common, even apple does it [15:34:19] <BBB> think of sdp as rtsp without the rtsp control connection [15:34:42] <BBB> it sucks major ass, and he's having problems with it that are common for this kind of ... hack? :) [15:34:52] <BBB> but we'll support it someday [15:34:56] <BBB> (we already do) [15:35:00] <BBB> (but not perfectly) [15:36:42] <jez9999> i'm thinking that reverting to plan C is the last bad option [15:36:52] <jez9999> specify valid source address(es) in AVFormatContext [15:37:02] <jez9999> s/last/least/ [15:38:05] <mru> when something seemingly trivial doesn't have an obvious solution you're usually looking in the wrong place [15:38:28] <jez9999> i didnt say it was seemingly trivial [15:38:41] <mru> filtering by source address is seemingly trivial [15:38:56] <jez9999> not when the ffmpeg developers are anal about what goes in the API :-) [15:39:01] <mru> if it doesn't seem that way to you, you're probably doing the wrong thing [15:39:33] <jez9999> i already have a workable solution... in proof-of-concept [15:39:42] <jez9999> that's how trivial it is [15:40:03] <mru> but an incorrect one [15:40:09] <jez9999> bleh [15:40:31] <BBB> jez9999, I won't accept that either [15:40:35] <BBB> jez9999, it's too complicated [15:41:01] <BBB> I don't want a list of source IPs in avformatcontext, or worse yet, a source ip in avpacket [15:41:20] <BBB> if the sdp lacks information that rtsp has (ssrc, or source ip), then we should add that to the sdp [15:41:28] <BBB> if it's not part of sdp, then add it to the uri containing the sdp [15:41:32] <BBB> seems pretty simple to me [15:41:36] <jez9999> so what, we invent a new RFC for SDP then? :-) [15:41:50] <BBB> I don't want to bloat avformatcontext with stuff that's wrong just in sdp [15:41:51] <jez9999> the uri containing the SDP does not support a mechanism to do that [15:42:09] <BBB> I'd like to enhance the sdp RFC [15:42:17] <BBB> if you look on google, several people have asked about this [15:42:26] <jez9999> heh [15:42:32] <BBB> (look for ssrc sdp collision, for example) [15:42:43] <BBB> it's apparently a common theme [15:42:53] <jez9999> so all that needs to be done is go through the whole process of composing, submitting, and getting accepted a new SDP RFC [15:43:08] <jez9999> well im sure it's the technically correct ideal but there's no way i have that kind of time or manpower to get it implemented [15:43:55] <jez9999> i'm not RealNetworks [15:44:16] <kshishkov> why do you mention that name? [15:44:30] <jez9999> just strikes me as a company that would have the time and inclination to do that [15:44:35] <jez9999> if they needed to [15:45:02] <mru> lol [15:45:15] * kshishkov strongly dislikes Buffering Inc. [15:45:22] <mru> the realnetworks solution is to drop all packets and display "Buffering..." [15:45:54] <kierank> you forgot about opening the Real MessageCentre (TM) [15:46:17] <jez9999> anyway your assertion is that the only acceptable solution is a revised SDP RFC, right? [15:46:23] <jez9999> any devs around that don't think that? [15:46:34] <jez9999> if not, i'll try and get a more sane patch into Xuggler [15:49:58] <kshishkov> then you should stalk for aclarke, not BBB [15:50:11] <jez9999> i know, im just asking ffmpeg devs first [15:50:13] * mru counter-stalks aclarke [15:50:54] <_av500_> mru: I managed to show the videowall to key ti ppl here in nice, inside one of their demos :) [15:51:30] * mru looks around... beagles are still here... [15:51:45] <BBB> jez9999, ??? [15:51:45] <kshishkov> _av500_: thanks for saving them money on advertising [15:51:47] <BBB> I never said that [15:51:51] <_av500_> well, they saw the utube video :) [15:51:58] <BBB> jez9999, I said, add a ?opt=val to the sdp file [15:52:07] <BBB> 99% of the time, you'll be reading the sdp file locally [15:52:08] <merbzt> _av500_: where did you get all the screens ? [15:52:09] <jez9999> 'to the file'? [15:52:16] <jez9999> you mean inside the file? [15:52:21] <BBB> I'm aware that for http, that might not work, but I'm aware of that issue and in the process of fixing it [15:52:22] <_av500_> merbzt: no, i showed them the utube video [15:52:24] <BBB> no, as part of the uri string [15:52:33] <BBB> ./ffplay file.sdp?opt=val [15:52:41] <jez9999> how does that work for file:/path/to/file.sdp [15:52:41] <jez9999> ? [15:52:41] <_av500_> they wanted to demo android utube player over 3g, i entered the right url for them :) [15:52:53] <BBB> or xuggler: av_open_input_file("file://file/file.sdp?opt=val"); [15:53:01] <mru> _av500_: well played [15:53:03] <_av500_> so, it was a demo inside a demo [15:53:04] <BBB> maybe I'm missing a / there [15:53:12] <merbzt> but at FOSDEM [15:53:20] <merbzt> where did you get those ? [15:53:20] <jez9999> BBB: as far as i can tell, the file protocol handler expects file:/path/to/file.sdp [15:53:28] <jez9999> BBB: if file: is missing, it adds it [15:53:30] <_av500_> merbzt: i brought them there [15:53:36] <merbzt> ok [15:53:37] <jez9999> so you can say /path/to/file.sdp [15:53:38] <_av500_> in all their 60pounds glory [15:53:48] <BBB> jez9999, yes [15:53:59] <jez9999> then it passes that through to open(), which doesnt like a query string being at the end [15:54:13] <mru> easy to fix [15:54:14] <jez9999> nor should it. in the URL RFC, file: isn't meant to have query strings [15:54:21] <jez9999> so it would be incorrect to support thewm [15:54:23] <jez9999> them [15:54:25] <_av500_> merbzt: I had 5 unused in the office and one from ebay [15:56:01] <BBB> jez9999, I'm aware of all that. but it works, and we're trying to separate string "options" from the uri, but that's not done yet [15:56:05] <BBB> so for now, it's ok to do that [15:56:26] <jez9999> it doesnt work... where is the code that separates out the query string for file: URIs? [15:56:43] <BBB> you would add it to the sdp handler? [15:56:59] <jez9999> the sdp handler doesn't get invoked, the file protocol handler fails [15:57:17] <BBB> hm, I guess the file doesn't exist... crap, this is how rtsp fixes these issues [15:57:26] <BBB> ok, then go fix that bug also then as part of this bug ;) [15:57:50] <jez9999> except that that 'bug' is a correct implementation of RFC 1738 :-) [15:57:50] <BBB> I will, again, not accept new stuff being added to avformatcontext specifically for source ips [16:00:06] <jez9999> if the SDP and URL RFCs provide no mechanism to pass this data through, the logical conclusion would be that ffmpeg needs to provide its own mechanism [16:00:14] <jez9999> not that you break RFC 1738 [16:00:39] <mru> or that the rfc is broken [16:00:56] <jez9999> possibly [16:04:33] <mattg> mru: i've been using libavcodec on arm (iphone 3gs, so has neon) and am getting green frames when there's "too many reference frames" errors, but plays fine when compiled with --disable-asm and also plays fine on x86 ffmpeg. have you come across this at all? [16:04:39] <jez9999> how long until ffmpeg accepts passing options separately from the URI? [16:04:58] <mru> mattg: I don't have an iphone, so no ;-) [16:05:15] <mattg> have you seen it on any neon device though? [16:05:19] <mru> no [16:05:44] <mattg> gcc has issues with stack alignment on arm, could it be related do you think? [16:05:45] <mru> do you get those error messages even when it displays correctly? [16:05:49] <mattg> yes [16:06:05] <mattg> exactly the same error messages [16:06:09] <mru> do you have a sample file I could try? [16:06:29] <mattg> yes i can provide one - let me try and create a decent one for you [16:06:35] <mattg> where should i mail to? [16:07:00] <mru> upload as per the bugreports page [16:07:15] <mattg> ok sure [16:08:10] <jez9999> BBB: what're some examples of other protocol-specific options passed via a query string? [16:08:15] <mattg> mru: thankyou [16:11:00] <BBB> jez9999, rtsp://bla?tcp is one [16:11:12] <BBB> to force rtsp/tcp instead of the default rtsp/udp [16:11:21] <BBB> I might've broken that [16:11:26] <BBB> but that's the general idea of how to make it work [16:13:03] <jez9999> lol [16:13:21] <jez9999> how long until ffmpeg accepts passing options separately from the URI? [16:13:27] <jez9999> that would render this hack obsolete [16:13:32] <BBB> whenever I have time? [16:13:38] <BBB> you can fund me </hint> [16:13:51] <BBB> nobody else but me has volunteered to do that one, so far at least [16:14:13] <CIA-17> ffmpeg: mru * r21696 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised put_pixels functions except xy2 variants [16:14:13] <CIA-17> ffmpeg: mru * r21697 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs16 [16:14:14] <CIA-17> ffmpeg: mru * r21698 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs16_x2 [16:14:15] <CIA-17> ffmpeg: mru * r21699 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs16_y2 [16:14:15] <CIA-17> ffmpeg: mru * r21700 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs8 [16:14:15] <CIA-17> ffmpeg: mru * r21701 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised get_pixels [16:14:16] <CIA-17> ffmpeg: mru * r21702 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised diff_pixels [16:14:16] <CIA-17> ffmpeg: mru * r21703 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised sse16 [16:14:17] <BBB> at least I didn't add a rtsp_lower_transport option to avformatcontext [16:14:17] <CIA-17> ffmpeg: mru * r21704 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_norm1 [16:14:18] <CIA-17> ffmpeg: mru * r21705 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_sum [16:14:30] <elenril> m-m-monster kill [16:14:43] <BBB> in fact, I think I removed that option, which was a global constant before [16:14:52] <BBB> ugly as hell [16:15:12] <jez9999> global constant? how does that work with calling code? [16:15:33] <BBB> it wasn't exported in a header [16:15:46] <mattg> mru: it's in /MPlayer/incoming/mattg_neon_green/ [16:15:53] <BBB> so they'd declare it themselves as "extern int rtsp_lower_transport;" [16:16:08] <BBB> and then set it to 1, 2 or 4 depending on whether they wanted tcp or udp [16:16:25] <BBB> I removed that for obvious reasons [16:17:56] <BBB> anyway, codec-specific options, format-specific options [16:17:59] <BBB> all of this is ugly as hell [16:18:06] <BBB> someone needs to step up and do it :) [16:20:07] <jez9999> that's a pretty massive job [16:20:17] <jez9999> at least, for someone who isn't a regular ffmpeg coder [16:20:43] <BBB> it's massive for us also [16:21:03] <jez9999> so theoretically if you were funded to start now, how long would it take you? [16:22:21] <DonDiego> anybody seen yuvi around? [16:22:35] <kshishkov> he was here yesterday or so [16:22:53] <DonDiego> k, let's see if he shows up.. [16:26:20] <jez9999> BBB: you see that? [16:28:50] <BBB> yes [16:29:06] <BBB> your question is: how long would I spend on it? [16:29:10] <jez9999> no [16:29:12] <BBB> probably 2-4 weeks [16:29:21] <jez9999> well ok you rephrased it i guess lol [16:29:32] <BBB> :) [16:30:03] <jez9999> and that would just be on being able to pass another argument in the av_open* functions? [16:31:05] <BBB> jez9999, two variants have been proposed [16:31:10] <BBB> jez9999, one is what you're saying [16:31:41] <BBB> jez9999, the second is that another call before that is necessary to initialize default "private options", and then you can change those in the application, and call the open() function just as regularly [16:31:55] <BBB> i.e. they're semantically slightly different but do exactly the same thing [16:33:03] <BBB> stefano has been working on that for longer than me, if you want to fund actively [16:33:12] <BBB> dark_shikari also wants it, but for x264 [16:33:20] <BBB> I want it for rtsp, as said before [16:36:23] <jez9999> these guys work for other companies? [16:36:33] <jez9999> or is it purely for personal use? [16:36:42] <BBB> Dark_Shikari is consulting [16:36:48] <BBB> I don't know about stefano [16:37:09] <jez9999> does part of the consulting fee comprise ffmpeg development? [16:37:19] <BBB> ? [16:37:31] <BBB> he does whatever people want that he has contracts with [16:37:38] <BBB> that could be ffmpeg developer, or anything [16:38:11] <BBB> you could ask him to sign a contract to do codec/format-specific implementation of two options: "log_level" in x264 and "source" in sdp [16:38:16] <BBB> that would be sufficient to get the whole system in [16:39:35] <jez9999> well the large bulk of the work would be the format-specific options implementation [16:39:51] <jez9999> the 'source' bit would be easy in comparison [16:41:44] <BBB> correct [16:44:56] <jez9999> hang on....... [16:45:00] <jez9999> what is AVFormatParameters? [16:46:31] <BBB> jez9999, it's deprecated, don't even start touching it :) [16:46:49] <jez9999> oh... that would seem to be one of the proposed solutions [16:46:55] <jez9999> or would the proposed solution be a string [16:47:04] <BBB> yes [16:47:16] * elenril wonders why it isn't marked as deprecated [16:47:28] <BBB> avformatparameters suffers from the same problem as putting it in avformatcontext: it's not codec-specific, since it's there for all codecs [16:47:32] <BBB> except only one uses it [16:47:45] <BBB> "introspectibility" of that is missing [16:48:15] <BBB> the proposed solution would ideally be introspectable, but at the very least it shouldn't increase the binary size of formats it does not apply to [16:48:27] <BBB> avformatparameters fails that last condition [16:48:33] <BBB> so does avformatcontext [17:22:14] <mattg> mru: have you had any luck with my sample file? [17:24:31] <mru> mattg: sorry, haven't had time to look at it yet [17:25:19] <mattg> absolutely no problem [17:25:34] <mru> I'll get to it eventually [17:25:48] <mru> keep poking every 24h or so until I do [17:25:59] <mru> hopefully it's an easy one [17:28:04] <mattg> ok, will do. yeh it's hopefully easy. i had a quick look myself but got stuck. i had issues with libx264 arm asm as well which was alignment related, so i've been hunting to see if that's the case here. [17:35:26] <Dark_Shikari> mru: did you ever get any of my messages about Green Hills Software? [17:35:34] <Dark_Shikari> if I pick them for this summer's internship, I'll have to test their compiler on ffmpeg [17:35:39] <Dark_Shikari> and see how much it beats armcc [17:36:27] <mru> messages from you about green hills? [17:36:31] <siretart_> ramiro: pong [17:37:15] <jez9999> BBB: what's required for a patch to ffmpeg to be accepted, some kind of test scripts? [17:37:25] <CIA-17> ffmpeg: siretart * r21706 /branches/ (0.5 0.5/libavcodec/aac.c 0.5/libavcodec/aac.h): [17:37:25] <CIA-17> ffmpeg: fix aac playback regression [17:37:25] <CIA-17> ffmpeg: Discussed at http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/103768 [17:37:25] <CIA-17> ffmpeg: related reports: [17:37:25] <CIA-17> ffmpeg: - http://bugs.debian.org/540729 [17:37:26] <CIA-17> ffmpeg: - https://roundup.ffmpeg.org/roundup/ffmpeg/issue800 [17:37:27] <mru> Dark_Shikari: messages where? [17:37:37] <ramiro> siretart: I replied to your commit to gsm [17:37:41] <jez9999> say one that allowed the file: protocol handler to accept a query string with format-specific custom args? [17:38:18] <Dark_Shikari> mru: oh, it was a few days ago [17:38:24] <Dark_Shikari> when I was up in santa barbera interviewing for them [17:38:25] <siretart_> ramiro: oh, yes, now I remember, I'm looking at the issue right now [17:38:28] <Dark_Shikari> they have some pretty awesome software [17:38:39] <mru> awesomely buggy, yes [17:38:42] <siretart_> ramiro: it was basically diego who committed it, I did lend him my laptop [17:38:58] <mru> it was their compiler that accessed data below the stack pointer [17:39:11] <_av500_> siretart_: that messes up the svn history, no? :) [17:39:51] <ramiro> siretart_: well then let's ping diego =) [17:39:55] <ramiro> DonDiego: ping [17:40:04] * Honoome looks up [17:40:06] <Honoome> ah not me… [17:40:53] <siretart_> ramiro: it seems that the libgsm upstream makefile does not come with *any* proper installation rules [17:41:11] <ramiro> I know... [17:41:15] <siretart_> ramiro: the installation is defined by debian/rules [17:41:23] <mru> siretart_: then go with plain <gsm.h> and have the user supply -I flags as necessary [17:42:30] <siretart_> mru: that sounds reasonable to me [17:42:53] <siretart_> oh, wait, that would break the build on debian [17:43:01] <ramiro> how? [17:43:11] <siretart_> sorry, my bad, it doesn't [17:43:31] <siretart_> /usr/include/gsm.h -> gsm/gsm.h [17:43:52] <ramiro> yeah, that's weird... I just apt-got the source to see if there was any comment in debian/rules about that... [17:44:21] <DonDiego> ramiro: pong [17:44:39] <siretart_> DonDiego: it's about our gsm.h change at fosdem [17:44:41] <ramiro> DonDiego: we're talking about the gsm commit [17:45:02] <DonDiego> weren't there two different rules in the package? [17:45:32] <siretart_> the package ships a symlink that 'makes things work' [17:46:01] <siretart_> I wonder what the situation in other distro packages is [17:46:52] <siretart_> opensuse: http://www.novell.com/products/linuxpackages/opensuse/libgsm-devel.html [17:47:21] <DonDiego> hrmpf [17:47:33] <DonDiego> peloverde_: yo [17:47:41] <DonDiego> peloverde_: back in the states? [17:47:43] <peloverde_> yeah [17:48:08] <DonDiego> hope you had a good flight and enjoyed old europe :) [17:48:17] <peloverde> I did [17:48:41] <mru> next time we need to show him some of the shadier parts [17:48:43] <mru> it's tradition... [17:48:49] <siretart_> hmrpfs about rathan not being around. he seems to be maintaining libgsm in fedora [17:49:06] <mru> hmrpfs, is that a new filesystem? [17:49:09] <kshishkov> mru: shadier? welcome here! [17:49:58] <siretart_> ah, here we go for fedora: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1450127 [17:50:31] <siretart_> can someone check if there is such a compat symlink /usr/include/gsm.h -> gsm/gsm.h in gentoo as well? [17:50:35] <DonDiego> haha [17:50:50] <DonDiego> yes, we shall show our us friends the shadier parts of the continent :) [17:50:56] <siretart_> hi peloverde! [17:50:58] <BBB> jez9999, well, that's a workaround for lack of format-specific options... I'm not sure that'd be accepted anyway [17:51:02] <BBB> jez9999, but you could try... [17:51:52] <jez9999> heh [17:51:55] <mru> hmm, gentoo does dosym ../gsm/gsm.h /usr/include/libgsm/gsm.h [17:52:14] <jez9999> so basically the best use of my time is to complete my patch to add to avformatcontext. [17:52:34] <BBB> ? [17:52:37] <siretart_> mru: does this mean that there is no /usr/include/gsm.h in gentoo at all? [17:52:39] <BBB> no, make it a format-specific option [17:52:45] <BBB> you'll make a lot of people happy [17:52:50] <mru> siretart_: it would appear so [17:52:51] <jez9999> why? you probably wont accept it anyway and i need to get it done in 2 weeks [17:52:53] <ramiro> why does suse install private.h? that seems wrong. [17:52:55] <mru> it's not installed on my machine [17:53:03] <BBB> if you want something xuggler-specific, you could just use the patch you have already [17:53:06] <mru> ramiro: suse is wrong, that's why [17:53:17] <BBB> I'll accept the format-specific option patch [17:53:26] <BBB> (assuming done correctly) [17:53:31] <siretart_> mru: that's interesting, given that opensuse, debian and fedora all seem to include that [17:53:33] <BBB> (i.e. AVOption-based, etc.) [17:53:33] <jez9999> oh you mean the massive amount of work one? :-) [17:53:37] <jez9999> lol [17:53:42] <jez9999> yeah, no time to do that [17:53:53] <Dark_Shikari> mru: did you get the bug fixed? [17:53:56] <Dark_Shikari> and do you have the compiler? [17:53:56] <BBB> dude, RDT (a simple variation of RTP) took me two years because of massive restructuring in rtsp to get it in "nicely" [17:54:04] <mru> Dark_Shikari: that was at the old job [17:54:09] <BBB> I know what shitload-of-work is :) [17:54:14] <Dark_Shikari> ah. [17:54:14] <BBB> but sometimes it's best in the longer term [17:54:34] <mru> they had some kind of policy against ever updating a compiler [17:54:38] <mru> so a bugfix would be useless anyway [17:55:01] <jez9999> BBB: how nice that you have an employer that can fund you for 2 years on that :-) [17:55:05] <jez9999> or the spare time... [17:55:37] <Dark_Shikari> mru: lol [17:55:38] <Dark_Shikari> idiots. [17:55:48] <ramiro> so we have 3 in include/gsm/, 1 in include/libgsm/, and 2 in include/, the official says nothing about it. [17:56:04] <mru> Dark_Shikari: that's what I told them, then I quit [17:56:09] <Dark_Shikari> lol [17:56:24] <Dark_Shikari> apparently the guys at green hills have a similar attitude--they have customers that use some ANCIENT versions [17:56:27] <Dark_Shikari> and they hate it [17:56:32] <Dark_Shikari> because that means they have to _support_ them [17:57:14] <ohsix> they keep old projects and toolchains in a nice old bundle so someone can still do maintenance if they have to [17:57:32] <mru> end result was one week of my time wasted hunting that damn bug [17:57:48] <ohsix> high-rel stuff sometimes has to rely on a known bad than an unknown "better" [17:58:00] <mru> this was TV set top boxes [17:58:06] <mru> about as flaky as it gets [17:58:22] <ohsix> nice [17:58:58] <BBB> jez9999, spare time :) [17:59:00] <kierank> zero nines [17:59:09] <BBB> jez9999, if I were my own employer, I'd have fired myself, most likely [17:59:14] <BBB> anyway, this won't take 2 years [18:00:39] <siretart_> ramiro: replied [18:01:03] <ramiro> siretart_: thanks [18:01:12] <ramiro> but it seems gentoo does a symlink, doesn't it? [18:01:46] <ramiro> ah, but not to include/ . ok... [18:10:55] <CIA-17> ffmpeg: siretart * r21707 /branches/ (0.5/libavformat/avformat.h 0.5 0.5/libavformat/utils.c): [18:10:55] <CIA-17> ffmpeg: Make arguments of av_set_pts_info() unsigned. [18:10:55] <CIA-17> ffmpeg: Fixes issue1240/mpeg1/smclockmpeg1.avi.3.1 [18:15:25] <peloverde> I noticed someone added LATM to the 0.6 wiki entry? Is anyone actively still working on LATM? [18:15:46] <Honoome> we just got LATM support requested on libnemesi the other day o_O [18:17:03] <peloverde> I know a lot of people want LATM but does it make sense as a release goal if no one is working on it? [18:19:13] <kshishkov> DonDiego: ^ [18:20:11] <siretart_> DonDiego: you rejected http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=blob;f=debian/patches/… on the basis that it was a feature backport that we don't want. now I remember why I included it in the package: [18:20:30] <siretart_> DonDiego: reason is: it introduces a variable 'field_size', which is used in later patches [18:20:58] <siretart_> DonDiego: on that basis, do you still object to that patch? [18:21:23] <peloverde> siretart_, I haven't looked at that recently but IIRC the vulnerability was caused by the addition of field_size [18:23:59] <siretart_> peloverde: oh. could you perhaps invest some minutes? if you're right, then all patches from here should be dropped: http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=tree;f=debian/patches/… [18:25:23] <CIA-17> ffmpeg: siretart * r21708 /branches/ (0.5/libavformat/oggdec.c 0.5): [18:25:23] <CIA-17> ffmpeg: Disable parsing for ogg streams where no ogg header was found, [18:25:23] <CIA-17> ffmpeg: if no header was found the parser was not initialized and thus will [18:25:23] <CIA-17> ffmpeg: crash when trying to use it. [18:33:40] <peloverde> siretart, http://roundup.ffmpeg.org/roundup/ffmpeg/file469/smclockmp4aac_1_0.mp4 is not crashing on the 0.5 branch for me [18:34:22] <peloverde> That was the file attached to the bug referenced in: 0001-check-entries-against-field_size-potential-malloc-ov.patch [18:35:16] <peloverde> 0002-add-one-missing-check-for-stream-existence-in-read_e.patch has no dependency on 0000 or 0001 [18:35:43] <peloverde> In 0003-check-stream-existence-before-assignment-fix-1222.patch field_size only appears in the context lines [18:37:27] <siretart_> peloverde: excellent analysis. working on that now [18:42:08] <CIA-17> ffmpeg: siretart * r21709 /branches/ (0.5 0.5/libavformat/mov.c): [18:42:08] <CIA-17> ffmpeg: add one missing check for stream existence in read_elst, fix #1364 [18:42:08] <CIA-17> ffmpeg: backported patch r19792 by bcoudurier [18:45:41] <CIA-17> ffmpeg: siretart * r21710 /branches/ (0.5 0.5/libavformat/mov.c): [18:45:41] <CIA-17> ffmpeg: check stream existence before assignment, fix #1222 [18:45:41] <CIA-17> ffmpeg: backported r19259 by bcoudurier [18:51:49] <DonDiego> ok, nice to see some 0.5 branch activity :) [18:51:55] <DonDiego> thx everybody for helping out.. [18:52:03] <CIA-17> ffmpeg: siretart * r21711 /branches/ (0.5 0.5/libavformat/oggparsevorbis.c): [18:52:03] <CIA-17> ffmpeg: Fix possible buffer over-read in vorbis_comment, fix it double to be sure. [18:52:03] <CIA-17> ffmpeg: First, make s signed, so that comparisons against end - p will not be made as [18:52:03] <CIA-17> ffmpeg: unsigned, making the check incorrectly pass if p is beyond end. [18:52:03] <CIA-17> ffmpeg: Also ensure that p will never be > end, so the code is correct also if [18:52:04] <CIA-17> ffmpeg: buf is not padded. [18:52:05] <CIA-17> ffmpeg: backported r20014 by reimar [18:52:09] <DonDiego> some people highlighted me, what's up? [18:52:26] <DonDiego> i'm supposed to be at work and cannot read all the backlog now ;) [18:52:39] <kshishkov> somebody with nick "Yuvi" has logged in [18:53:05] <siretart_> DonDiego: peloverde already cleared the issue and my mov patches are already comitted [18:53:20] <siretart_> so, I'm done for libavformat, now attacking avcodec [18:53:31] <BBB> woohoo, I think google will pay ius for 2008 also [18:53:53] <BBB> we should all buy mike a drink and then maybe suggest I take over gsoc admin for 2010 [18:53:58] <siretart_> BBB: great news! :-) [18:54:35] <jez9999> pay who?: [18:54:50] <mru> BBB: mike doesn't drink [18:55:16] <kshishkov> mru: water? cola? [18:55:31] <mru> "buy someone a drink" implies beer or better [18:56:31] <CIA-17> ffmpeg: siretart * r21712 /branches/ (0.5/libavcodec/ffv1.c 0.5): [18:56:31] <CIA-17> ffmpeg: Fix a possibly exploitable buffer overflow. [18:56:31] <CIA-17> ffmpeg: backported r18640 by michael [18:57:36] <kshishkov> mru: for me water is better. Or Trocadero [18:58:02] <DonDiego> kshishkov: thx for the hint [18:58:23] <DonDiego> Yuvi: you around now? [18:58:51] <CIA-17> ffmpeg: stefano * r21713 /trunk/doc/APIchanges: Add an entry for the recently added av_compare_ts() function. [18:59:19] <BBB> mru: I'll buy him a virgin mojito [18:59:29] <BBB> or a hot chocolate, if he insists [18:59:47] <BBB> jez9999, mike melanson, ffmpeg's google summer of code admin of the past few years [19:00:11] <Yuvi> DonDiego: yo [19:00:18] <BBB> koth: did we agree on dns already? [19:00:19] <DonDiego> Yuvi: i wanted to inquire about the status of your theora speedup branch [19:00:24] <CIA-17> ffmpeg: stefano * r21714 /trunk/libavformat/avio.h: Doxument url_fopen(). [19:00:27] <BBB> koth: or someway I can get access to the website? [19:00:33] <DonDiego> as you know we were at fosdem this weekend [19:00:44] <DonDiego> and the release name for 0.6 is going to be.. [19:00:51] <DonDiego> ... * drumroll * ... [19:01:03] <DonDiego> " works with HTML 5 " [19:01:04] <kshishkov> nonexistent [19:01:13] <Dark_Shikari> DonDiego: do it [19:01:13] <Dark_Shikari> lol [19:01:19] <Yuvi> chroma's broken, but once that's fixed I can start merging [19:01:29] <DonDiego> it's what mans put on our ffmpeg t-shirts [19:01:29] <Yuvi> it's at 20-27% faster [19:01:33] <DonDiego> anyway [19:01:44] <DonDiego> the point, the point, back to the point :) [19:01:50] <DonDiego> html 5 is the hotness right now [19:01:59] <DonDiego> and ffmpeg is being scorned for its handling of theora [19:02:00] <Dark_Shikari> Yuvi: get that done =p [19:02:10] <BBB> I love it [19:02:11] <BBB> do it [19:02:21] <DonDiego> so let's have world-class theora support in 0.6 [19:02:22] <BBB> and send out more t-shirts :-p [19:02:54] <DonDiego> if we can write that apart from the fastest vorbis decoder we now also have the fastest theora decoder [19:03:10] <DonDiego> then we will rock and make a lot of people shut up :) [19:03:30] <peloverde> DonDiego, they will still flame us for supporting H.264 [19:03:32] <CIA-17> ffmpeg: siretart * r21715 /branches/ (0.5/libavcodec/h264.c 0.5): [19:03:32] <CIA-17> ffmpeg: Check num_units_in_tick/time_scale to be valid and within the range we support. [19:03:32] <CIA-17> ffmpeg: based on a patch by chrome [19:03:32] <CIA-17> ffmpeg: backported r19979 by michael [19:03:55] <Yuvi> ofc, they also want 4:2:2, 4:4:4 and that stupid left/top cropping [19:04:08] <DonDiego> Yuvi: so if you could prioritize your work on the theora branch a bit, that would be awesome [19:04:12] <kshishkov> DonDiego: but not the fastest Bink decoder :P [19:04:35] <DonDiego> Yuvi: yes, implementing missing features would of course also be welcome [19:04:50] <DonDiego> as well as fixing that annoyance with keyframes while seeking [19:04:54] <peloverde_> Not the fastest HE-AAC decoder [19:05:22] <Yuvi> DonDiego: certainly, I was planning on 4:2:2/4:4:4 after the speedup; it needed keeping a few things in mind [19:05:33] <DonDiego> i.e. artifacts after seeking [19:05:42] <DonDiego> peloverde_: which is the fastest? [19:06:13] <DonDiego> peloverde_: we cannot shut up everybody about everything, but we certainly can shut up certain people about certain things [19:06:29] <peloverde_> DonDiego, Probably nero for among those available to the general public [19:06:32] <DonDiego> and let's face it: theora *will* become more widespread now [19:06:40] <mru> coreaac is pretty fast too [19:06:45] <DonDiego> peloverde_: private aac decoders exist? [19:06:46] <peloverde_> I'm still hoping for IE9 with H.264 [19:07:03] <DonDiego> we shall see [19:07:17] <DonDiego> Yuvi: anyway, great that you have all that in the queue.. [19:07:17] <peloverde_> DonDiego, yeah AAC is very important in embedded space [19:07:24] <DonDiego> k [19:07:42] <DonDiego> while we're at it, does anybody have that seeking in ogg/theora bug covered? [19:08:18] <peloverde_> What about broken continuation oggs? [19:08:38] <BBB> that is hell :) [19:08:38] <mru> that has got to be one of the worst misfeatures ever [19:08:54] <BBB> you can add or remove streams after a continuation (you mean catted ogg files, right?) [19:08:57] <Yuvi> peloverde_: fixed yesterday or the day before [19:09:03] <BBB> s/can/mean/ [19:09:13] <DonDiego> all hail Yuvi :-) [19:09:17] <peloverde_> Yuvi, ahh I've been out of the loop since FOSDEM [19:09:40] <peloverde_> kind of funny how that works out [19:09:53] <DonDiego> ok, i'll pretend to work again [19:10:03] <CIA-17> ffmpeg: siretart * r21716 /branches/ (0.5 0.5/libavcodec/mpegaudiodec.c): [19:10:03] <CIA-17> ffmpeg: check data_size in decode_frame() [19:10:03] <CIA-17> ffmpeg: backported r19986 by michael [19:10:05] <DonDiego> there's an autobuilder in need of fixing :) [19:21:18] <CIA-17> ffmpeg: siretart * r21717 /branches/ (0.5 0.5/libavcodec/mpegaudiodec.c): [19:21:18] <CIA-17> ffmpeg: Check data_size in decode_frame_mp3on4(). [19:21:18] <CIA-17> ffmpeg: backported r19987 by michael [19:23:11] <CIA-17> ffmpeg: siretart * r21718 /branches/ (0.5 0.5/libavcodec/mpegaudiodec.c): [19:23:11] <CIA-17> ffmpeg: Set data_size to 0 to avoid having it uninitialized. [19:23:11] <CIA-17> ffmpeg: based on 31_mp3_outlen.patch by chrome. [19:23:11] <CIA-17> ffmpeg: backported r19988 by michael [19:25:56] <DonDiego> does anybody how 0.5 was faring wrt fate? [19:26:11] <DonDiego> and yes, the autobuilder is fixed ;) [19:27:35] <CIA-17> ffmpeg: siretart * r21719 /branches/ (0.5 0.5/libavcodec/vp3.c): [19:27:35] <CIA-17> ffmpeg: Fix init_get_bits() buffer size. [19:27:35] <CIA-17> ffmpeg: 18_fix_theora_header_bit_len.patch by chrome [19:27:35] <CIA-17> ffmpeg: backport r19993 by michael [19:31:59] <CIA-17> ffmpeg: siretart * r21720 /branches/ (0.5 0.5/libavcodec/vp3.c): [19:31:59] <CIA-17> ffmpeg: Make sure that all memory allocations succeed. [19:31:59] <CIA-17> ffmpeg: Based on 28_theora_malloc_checks.patch from the Google Chrome team. [19:31:59] <CIA-17> ffmpeg: backport r20008 by melanson [19:37:49] <DonDiego> siretart_: have you looked at the patch benjamin from geexbox sent us? [19:38:23] <DonDiego> Dark_Shikari: while we're at it, did you look at patching the x264 glue code for the 0.5 branch? [19:39:20] <siretart_> DonDiego: yes, it basically just adds some callbacks in ffmpeg, so that the application can do proper locking [19:39:22] <Dark_Shikari> DonDiego: yes, I'll do that later today [19:39:32] <Dark_Shikari> I'm working on a paper peer review that I've been putting off atm [19:39:42] <siretart_> DonDiego: it doesn't look too unreasonable to me [19:39:48] <DonDiego> Dark_Shikari: cool, thx [19:40:19] <DonDiego> siretart_: i have the same impression, so it should be good to go [19:40:31] <DonDiego> that's settled then [19:41:16] <siretart_> DonDiego: :-) [19:43:28] <CIA-17> ffmpeg: siretart * r21721 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:43:28] <CIA-17> ffmpeg: Check dimensions against 0 too. [19:43:28] <CIA-17> ffmpeg: 39_vorbis_zero_dims.patch from chrome [19:43:28] <CIA-17> ffmpeg: backport r19976 by michael [19:44:55] <CIA-17> ffmpeg: siretart * r21722 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:44:55] <CIA-17> ffmpeg: = -> == typo. [19:44:55] <CIA-17> ffmpeg: 27_vorbis_residue_loop_error.patch by chrome [19:44:55] <CIA-17> ffmpeg: backport r19982 by michael [19:46:06] <CIA-17> ffmpeg: siretart * r21723 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:46:06] <CIA-17> ffmpeg: Sanity checks for magnitude and angle. [19:46:06] <CIA-17> ffmpeg: 26_vorbis_mag_angle_index.patch by chrome [19:46:06] <CIA-17> ffmpeg: backport r19983 by michael [19:47:10] <CIA-17> ffmpeg: siretart * r21724 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:47:10] <CIA-17> ffmpeg: Fix book_idx check. [19:47:10] <CIA-17> ffmpeg: 25_vorbis_floor0_index.patch by chrome. [19:47:10] <CIA-17> ffmpeg: backport r19984 by michael [19:48:30] <CIA-17> ffmpeg: siretart * r21725 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:48:30] <CIA-17> ffmpeg: Check classbook value. [19:48:30] <CIA-17> ffmpeg: 11_vorbis_residue_book_index.patch by chrome. [19:48:30] <CIA-17> ffmpeg: r19989 by michael [19:50:11] <Dark_Shikari> heh, cia spam [19:50:18] <CIA-17> ffmpeg: siretart * r21726 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:50:18] <CIA-17> ffmpeg: Add checks for per-packet mode indexes and per-header mode mapping indexes. [19:50:18] <CIA-17> ffmpeg: 12_vorbis_mode_indexes.patch by chrome [19:50:18] <CIA-17> ffmpeg: maybe exploitable [19:50:18] <CIA-17> ffmpeg: r19990 by michael [19:51:45] <CIA-17> ffmpeg: siretart * r21727 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:51:45] <CIA-17> ffmpeg: Check masterbook index and subclass book index. [19:51:45] <CIA-17> ffmpeg: 14_floor_masterbook_index.patch by chrome [19:51:45] <CIA-17> ffmpeg: r19991 by michael [19:53:17] <CIA-17> ffmpeg: siretart * r21728 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:53:17] <CIA-17> ffmpeg: Check res_setup->books. [19:53:17] <CIA-17> ffmpeg: 15_more_residue_book_indexes.patch by chrome. [19:53:17] <CIA-17> ffmpeg: r19992 by michael [19:55:34] <CIA-17> ffmpeg: siretart * r21729 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:55:34] <CIA-17> ffmpeg: Check begin/end/partition_size. [19:55:34] <CIA-17> ffmpeg: 23_vorbis_sane_partition.patch by chrome. [19:55:34] <CIA-17> ffmpeg: Also this should be better documented but i prefer not to leave potential [19:55:34] <CIA-17> ffmpeg: security issues open due to missing documentation. [19:55:34] <CIA-17> ffmpeg: r19996 by michael [20:00:05] <CIA-17> ffmpeg: siretart * r21730 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [20:00:05] <CIA-17> ffmpeg: Check submap indexes. [20:00:05] <CIA-17> ffmpeg: 10_vorbis_submap_indexes.patch by chrome. [20:00:05] <CIA-17> ffmpeg: I am applying this even though Reimar had some comments to improve it as it fixes [20:00:05] <CIA-17> ffmpeg: a serious security issue and I do not want to leave such things unfixed. [20:00:06] <CIA-17> ffmpeg: backport r20001 by michael [20:29:34] <CIA-17> ffmpeg: siretart * r21731 /branches/ (5 files in 4 dirs): (log message trimmed) [20:29:34] <CIA-17> ffmpeg: Add a lock manager API to libavcodec. [20:29:34] <CIA-17> ffmpeg: Allows an application to register a callback that manages mutexes [20:29:34] <CIA-17> ffmpeg: on behalf of FFmpeg. [20:29:34] <CIA-17> ffmpeg: With this callback registered FFmpeg is fully thread safe. [20:29:35] <CIA-17> ffmpeg: backport r19025 by andoma [20:29:36] <CIA-17> ffmpeg: NB: This is a feature backport with little regression potential. It was [20:32:17] <DonDiego> bye [20:32:46] <andoma> bye [20:33:11] <siretart_> byebye [20:33:16] <mru> byebyebye [20:34:53] <aclarke> int i;for(i=0;i<4;i++) printf("bye"); [20:35:42] <mru> ah, that did it [20:37:00] <ohsix> int i=5;while(i--) puts("bye"); [21:27:09] <astrange> Yuvi: you should put a blank line after the first line in git commit messages [21:27:55] <astrange> Yuvi: also re http://github.com/yuvi/ffmpeg/commit/ad4d07e8f3bacce1096f50db00fb1ccfe080cb…, the xvid idct has no transpose so it was much easier to add complicated skipping [21:51:58] <Yuvi> astrange: yeah.. I noticed the obscenely long subject after the emails were sent [21:52:29] <Yuvi> and that makes sense, I was trying to figure how to add the skipping without branching on zzi [21:53:08] <Yuvi> but probably using zzi is the only way that makes sense for theora [21:53:19] <Dark_Shikari> zzi? [21:53:33] <Dark_Shikari> oh yeah, we still need a dc-only idct for theora. [21:53:40] <Yuvi> last coeff index in zigzag order, forget what other codecs call it [21:53:48] <Dark_Shikari> which makes extra sense because the encoder refuses to decimate dc coeffs [21:54:46] <Yuvi> actually, I noticed a fair number of dc-only blocks with 0, due to the stupid restriction of uncoded blocks having no MV [21:55:19] <Dark_Shikari> oh you mean a dc only block with no real coefficients? [21:55:24] <Yuvi> yep [21:55:47] <Dark_Shikari> ah, theora allows that in the entrop coder? [21:55:51] <Dark_Shikari> *entropy [21:56:01] <Dark_Shikari> that's a pretty obnoxious inefficiency [21:56:16] <Dark_Shikari> I mean it makes sense in that case given the whole uncoded blocks restriction [21:56:22] <Yuvi> yeah, mark the block as coded in the first section then EOB it immediately when decoding coefficients [21:56:24] <Dark_Shikari> but in all other cases it's horribly inefficient [21:56:34] <Dark_Shikari> forces redundant eobs [21:57:31] <Dark_Shikari> so basically I think there are three things needed: [21:57:36] <Dark_Shikari> 1) don't call idct on empty blocks that are coded [21:57:42] <Dark_Shikari> i.e. mark uncoded coded blocks as uncoded [21:57:45] <Dark_Shikari> 2) dc-only idct [21:57:49] <Dark_Shikari> 3) "idct small", if it's useful [21:58:00] <Dark_Shikari> the fact that we have the last nnz values "for free" should help [21:58:22] <Dark_Shikari> also, maybe some statistics of inter/intra dct coeffs [21:58:47] <Dark_Shikari> could even swap code paths based on frame quantizer [21:59:12] <Yuvi> http://pastebin.com/m4f43dbed some stats, I didn't separate empty from DC-only or inter/intra [21:59:35] <Dark_Shikari> 10e? [21:59:58] <Yuvi> last nnz is < 10 [22:00:04] <Dark_Shikari> ah k [22:00:05] <Yuvi> i.e. right and bottom halves of the block are 0 [22:48:02] <KotH> night boys and girls [22:51:28] <_av500_> nighty nighty [22:55:59] <CIA-17> ffmpeg: mru * r21732 /trunk/configure: configure: allow 'none' as target OS [22:56:00] <CIA-17> ffmpeg: mru * r21733 /trunk/ (configure cmdutils.c): Check for setrlimit() [22:56:01] <CIA-17> ffmpeg: mru * r21734 /trunk/configure: [22:56:01] <CIA-17> ffmpeg: Special check for math.h functions [22:56:01] <CIA-17> ffmpeg: These are often, contrary to standards, implemented only as macros [22:56:01] <CIA-17> ffmpeg: or compiler-builtin functions without an actual symbol definition. [22:56:02] <CIA-17> ffmpeg: mru * r21735 /trunk/libavutil/internal.h: [22:56:02] <CIA-17> ffmpeg: Define missing llrint() as macro instead of inline function [22:56:03] <CIA-17> ffmpeg: This fixes building on some broken systems. [22:56:32] <_av500_> mru: do I smell dsp? [22:56:52] <mru> yes and no [22:57:14] <mru> this fixes both dsp and something else I'm being paid for [22:57:14] <_av500_> yes and no os :) [22:58:43] <Dark_Shikari> that may help cygwin [22:58:49] <Dark_Shikari> lrintf that is [22:59:23] <mru> quite possible [22:59:27] <mru> it uses newlib, right? [22:59:46] <Dark_Shikari> dunno [22:59:48] <Dark_Shikari> it just warns all over about lrintf [22:59:54] <Dark_Shikari> no errors just warnings [23:00:41] <_av500_> gcc: warning: line of C code encountered [23:00:51] <mru> _av500_: no, that's lint [23:00:56] <andoma> :) [23:00:56] <_av500_> ah [23:01:12] <Dark_Shikari> lol [23:29:59] <mru> hey guys, check out linuxtag.org [23:30:07] <mru> watch the banner photo for a while [23:31:31] * Kovensky sees a bunch of heads, some orange thing and jpeg artifacts [23:31:53] <mru> one of the photos has the ffmpeg/ogp crew [23:33:25] <kierank> the one sitting at the table? [23:33:40] <mru> yeah [23:33:43] <mru> at the party [23:34:06] <mru> that's from 2008 [23:34:49] <Kovensky> thought it was that one [23:34:56] <Kovensky> and I had to enable scripts ._. [23:35:47] <Dark_Shikari> Yuvi: btw, any rough eta on when the theora optimizations you're working on will go in? [23:35:59] <Dark_Shikari> I'd like to do a bit of work as well but I don't want to touch it until you've committed your trees [23:36:02] <Kovensky> http://images.4chan.org/g/src/1265753532999.jpg <-- lol japan [23:36:04] <Kovensky> er, wrong channel [23:36:29] <Dark_Shikari> Kovensky: toradora: it sells graphics cards. [23:36:47] <Kovensky> but that's k-on... [23:37:00] <Dark_Shikari> oh wait, your'e right [23:37:01] <Dark_Shikari> shit [23:37:06] <Dark_Shikari> I confused my generic moeshit again [23:37:18] <Kovensky> lol [23:37:25] <Kovensky> toradora wasn't generic moeshit [23:37:26] <Dark_Shikari> and toradora has a meme associated with it and AMD [23:37:28] <Dark_Shikari> for some weird reason [23:37:28] <Kovensky> it was tsundereshit though [23:37:28] <Kovensky> :P [23:37:35] <Kovensky> oh, didn't know about that meme [23:37:36] <Dark_Shikari> all the /g/ tards photoshoppsed images of AMD and whatever her name was [23:38:19] <Kovensky> what hair color [23:38:29] <Dark_Shikari> the main tsundora [23:38:40] <Kovensky> taiga

1 0

IRC log for 2010-02-08
by irc＠mansr.com 09 Feb '10

09 Feb '10

[00:00:21] <lu_zero> hi [00:00:24] <lu_zero> I'm back home [00:00:36] <Compn> wb [00:00:48] <iive> lu_zero: i hope you had changed your irc client. [00:00:55] <Compn> lol [00:08:54] <CIA-17> ffmpeg: michael * r21681 /trunk/libavcodec/ (h264.c h264_direct.c): Set x264_build so that checks are simpler. [00:13:30] <lu_zero> iive: changed? [00:14:25] <iive> bitchx is not maintained and there are known exploits. [00:14:46] <iive> you were quitting few days ago with message "excess flood" [00:17:17] <lu_zero> I have irssi here [00:17:27] <lu_zero> yet I'm missing bx [00:21:16] <iive> well, fork and maintain it, if you like it. Just make sure you won't be exploited. [00:23:21] <Compn> lu_zero : anyone have any interesting comments or questions at fosdem ? [00:23:22] <Compn> hehe [00:30:54] * lu_zero is currently sleeping more or less [00:33:13] <Compn> oh sorry :) [00:40:33] <iive> lu_zero: you'd better make it more soon, than make it less later. [00:44:03] <CIA-17> ffmpeg: michael * r21682 /trunk/libavcodec/ (h263dec.c mpeg4videodec.c): Change xvid/divx/lavc build variables to be consistent to x264_build. [02:10:19] <CIA-17> ffmpeg: michael * r21683 /trunk/libavcodec/h264_direct.c: [02:10:19] <CIA-17> ffmpeg: Replace call to pred_motion() in direct spatial mv pred by code [02:10:19] <CIA-17> ffmpeg: and simplify cases that cannot happen away. [02:10:19] <CIA-17> ffmpeg: 8 cpu cycles faster [02:11:49] <CIA-17> ffmpeg: michael * r21684 /trunk/libavcodec/h264_direct.c: Remove incorrect fixme, i see no case that is missing. [03:23:19] <CIA-17> ffmpeg: michael * r21685 /trunk/libavcodec/h264_direct.c: [03:23:19] <CIA-17> ffmpeg: Branchless calculation of ref_offset. [03:23:19] <CIA-17> ffmpeg: 7 cpu cycles faster. [04:25:48] <CIA-17> ffmpeg: michael * r21686 /trunk/libavcodec/h264.h: [04:25:48] <CIA-17> ffmpeg: Remove an apparently unneeded && !FRAME_MBAFF. [04:25:48] <CIA-17> ffmpeg: This should speed the affected cases (MBAFF temporal direct MBs) up. [05:06:23] <astrange> Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption [05:06:32] <astrange> i guess clang analyzer can't run on ffmpeg anymore [05:07:09] <Dark_Shikari> lol [06:17:16] <jai> kierank: ping [06:53:58] <benoit-> good morning [06:55:11] <jai> bonjour [06:56:02] <kshishkov> god morgon [07:12:56] <kshishkov> wow, now PayPal loves Indians almost as much as Ukrainians [07:13:03] <astrange> http://github.com/chattama/ffmpeg-s60/ [07:56:05] <andoma> morning [07:56:08] <andoma> superdump: ? [07:56:11] <kshishkov> god morgon [07:56:16] <superdump> god morgon [07:56:20] <andoma> :) [07:56:37] <superdump> andoma: did you see my queries? [07:56:39] <andoma> yeah [07:57:15] <andoma> btw, can i remove the files? :) [07:58:25] <superdump> yes [07:58:35] <andoma> okei [09:04:59] <CIA-17> ffmpeg: benoit * r21687 /trunk/ffmpeg.c: [09:04:59] <CIA-17> ffmpeg: Stop reading input file when -t option value is reached. [09:04:59] <CIA-17> ffmpeg: Patch by Wolfram Gloger wmglo (chez) dent med uni (minus) muenchen de [09:29:40] <siretart> hi! [09:30:08] <Dark_Shikari> so, siretart, given the discussion earlier [09:30:13] <Dark_Shikari> what's the best solution? [09:30:24] <Dark_Shikari> oh, I guess you were away so you missed the logs [09:30:37] <siretart> Dark_Shikari: I don't have the backlog available, and I fell immediately to bed yesterday [09:30:58] <siretart> I guess you are referring on how to handle libx264.c for ffmpeg 0.5.1? [09:31:20] <Dark_Shikari> http://pastebin.com/m10fe0819 [09:31:38] <siretart> .o( referring to? - hmm. oh my english ...) [09:32:28] <kshishkov> siretart: yes, German as native language may spoil any other language skills [09:32:31] <twnqx> i thought the discussion went more along the lines of "the 0.5 branch is old, doesn't receive updates e.g. codecs, doesn't receive bugfixes except for security things, don't use it"? :P [09:32:37] <siretart> kshishkov: I fear so. [09:32:39] <twnqx> kshishkov: it does :( [09:33:16] <DonDiego> twnqx: i'm sure there was all sorts of discussion, the question is whether or not the discussion is relevant [09:33:31] <siretart> Dark_Shikari: I don't think it is necessary to support each and every version in between since the release of ffmpeg 0.5. However not supporting the x264 version that 0.5 did support would be an undesireable regression [09:33:31] <DonDiego> i'm the release manager for the 0.5 branch with siretart as second in command [09:33:44] <siretart> oh, hi DonDiego :-) [09:34:03] <Dark_Shikari> siretart: so you're fine with forcing everyone to use "latest git x264, OR 0.5 x264?" [09:34:07] <twnqx> DonDiego: i see. well, if you think it's worth your time, i won't stop you. [09:34:19] <DonDiego> i think it is [09:34:38] <siretart> Dark_Shikari: replace 'latest git x264' with 'latest x264 as of $today' with a clear definition of today, and I think that would sound fine [09:35:04] <Dark_Shikari> That sounds like a great idea [09:35:06] <siretart> the point is to avoid regressions for users [09:35:10] <Dark_Shikari> yet anoter way to force people to upgrade! [09:35:43] <twnqx> i wouldn't consider "hey, i can compress better" or "hey, i can play those blurays i couldn't before" a regression. but that's just me. [09:35:47] <siretart> ffmpeg 0.5 requires x264 API 67 AFAIUI [09:36:11] <Dark_Shikari> ok, I guess I'll go do that tomorrow then [09:36:21] <siretart> if fmpeg 0.5 works with *both* API v67 and 85 (or whatever you consider recent enough), that would work for me [09:36:43] <Dark_Shikari> ok [09:42:57] <DonDiego> ping luca b about this please [09:43:07] <DonDiego> they have a x264 version in gentoo [09:43:13] <DonDiego> that is not compatible with 0.5 [09:43:27] <siretart> DonDiego: I talked with him about that saturday night [09:43:45] <DonDiego> ok, then you are already taking it into account, good [09:44:02] <siretart> DonDiego: in the 'stable' 'branch', they already moved away from 0.5 to a newer snapshot exactly because of x264 requiring a newer ffmpeg [09:44:22] <siretart> which is now a bit unfortunate, but I think we can avoid that in future [09:45:58] <siretart> bilboed-pi: around? I hear that you care for gst-ffmpeg? Is that information correct? [09:46:13] <bilboed-pi> I'm the maintainer of gst-ffmpeg, so yes :) [09:46:23] <siretart> bilboed-pi: ah excellent. [09:46:39] <siretart> bilboed-pi: AFAIUI gst-ffmpeg currently tracks the 0.5 branch of ffmpeg. is that still the case? [09:46:42] <bilboed-pi> siretart, why do I have this feeling I know you from somewhere ? [09:46:51] <bilboed-pi> siretart, no, trunk gst-ffmpeg has switched to a more recent checkout [09:47:11] <siretart> bilboed-pi: I maintain the debian&ubuntu package, and now joined ffmpeg to help out with releases [09:47:28] <siretart> bilboed-pi: can you please elaborate why you moved to a more recent revision? [09:47:46] <Dark_Shikari> because people like wmapro support and bugfixes ? ;) [09:47:51] <bilboed-pi> siretart, due to lack of ffmpeg releases basically [09:48:28] <siretart> bilboed-pi: well, the plan is to have a 12 month release cycle. is that too slow for gst-ffmpeg needs? [09:48:55] * Kovensky thinks that is too slow for ffmpeg's development pace [09:48:56] <bilboed-pi> siretart, count the average number of commits per day to ffmpeg, multiply by 365, then think [09:49:31] <bilboed-pi> and yes, I'd much prefer a 3month release cycle of ffmpeg.. but hey... what can I do about it :( [09:49:36] <superdump> 6 months? 4 months? 3 months? [09:49:57] <bilboed-pi> 6 months was the initial idea iirc [09:50:02] <siretart> bilboed-pi: well, I see the picture of a distribution perspective. there it is undesireable to have gst-ffmpeg to build against a private ffmpeg copy, and having the internal copy going out of sync with the system ffmpeg has provoked lots of crashes in the past [09:50:10] <bilboed-pi> siretart, it's not a private copy [09:50:19] <bilboed-pi> siretart, it's a specified unmodified upstream svn revision [09:50:21] <Dark_Shikari> 3 months sounds good to me [09:50:30] <Dark_Shikari> with a one week feature freeze before release [09:50:32] <bilboed-pi> s/specified/specific/ [09:50:33] <siretart> bilboed-pi: which from a distro perspective, is an internal/private copy [09:51:07] <siretart> Dark_Shikari: 3 months is way too fast for a) distros, b) what we can bring up manpower for [09:51:15] <bilboed-pi> err... no, 3 months is fine [09:51:30] <Dark_Shikari> siretart: x264 does a 1 week release cycle generally [09:51:34] <bilboed-pi> Dark_Shikari, eheheh :) [09:51:42] <bilboed-pi> Dark_Shikari, you're no longer releasing at every commit ? :) [09:51:48] <Dark_Shikari> we release at every weekly commit spree [09:51:55] <superdump> commits come in lumps [09:51:58] <bilboed-pi> right [09:52:00] <siretart> Dark_Shikari: which is ridiculus from a distro perspective. it seems to work for you, though... [09:52:03] <Dark_Shikari> no other commits are made except for critical fixes/regression tests [09:52:17] <Dark_Shikari> siretart: the distro can pick any particular "release" and use it. [09:52:22] <siretart> Dark_Shikari: you also have to consider that distro releases tend to be much longer around than we care for [09:52:42] <Dark_Shikari> I mean, conceptually, think about ffmpeg [09:52:45] <superdump> i don't think keeping up with weekly x264 is necessary for a main distro repo [09:52:51] <siretart> releases are syncronisation points. if we make too many, then they are pointless for coordination [09:52:53] <Dark_Shikari> in practice, it doesn't matter which version is made the "release" [09:52:56] <superdump> that's more a ppa type-thing [09:52:57] <Dark_Shikari> superdump: of course. [09:53:02] <Dark_Shikari> I don't intend anyone to update every week [09:53:11] <Dark_Shikari> I intend people to pick a week, and make that their release [09:53:12] <bilboed-pi> Dark_Shikari, give or take regressions, but yes [09:53:27] <bilboed-pi> Dark_Shikari, the tricky part is figuring out regressions when making releases. [09:53:34] <Dark_Shikari> the point being that how often a distro chooses to release shouldn't have any relation to how often an application is released [09:53:41] <Dark_Shikari> it should have to do with the distro's practices [09:53:43] <Dark_Shikari> and nothing else [09:54:01] <superdump> Dark_Shikari: i often see that one week a bunch of new features come in and then the next week fixes for those features land where mistakes were made [09:54:08] <Dark_Shikari> This is true [09:54:15] <DonDiego> i've come to think that x264 is what gives us the reputation of breaking api often.. [09:54:18] <superdump> for a distribution it would be better to freeze features and make sure things are fixed [09:54:19] <siretart> bilboed-pi: which release of gst-ffmpeg moved away from ffmpeg 0.5? [09:54:30] <Dark_Shikari> DonDiego: the people who complain about breaking api are calling apps [09:54:32] <Dark_Shikari> not people compiling things [09:54:41] <bilboed-pi> siretart, trunk [09:54:44] <Dark_Shikari> and almost all the complaints are likely due to two things [09:54:46] <bilboed-pi> siretart, i.e. the upcoming one [09:54:48] <Dark_Shikari> 1) the really big break a while back [09:54:53] <Dark_Shikari> 2) the option name changes, oh god the option name changes [09:54:57] <Dark_Shikari> ffmpeg is far worse than x264 at that [09:55:03] <siretart> bilboed-pi: when is it scheduled for release? [09:55:11] <bilboed-pi> siretart, within a few weeks (a month max) [09:55:20] <jai> kierank: ping ^ 2 [09:55:37] <siretart> bilboed-pi: okay. then you should note that we intend to branch 0.6 in that time frame [09:55:52] <jai> was the policy decided for 0.6? [09:55:56] <bilboed-pi> siretart, then we'll update it when that happens, not before [09:55:56] <Dark_Shikari> what? 0.6 is already coming? [09:56:01] <jai> superdump: ^ [09:56:02] <bilboed-pi> also, this is news for me [09:56:08] <siretart> bilboed-pi: that sounds great [09:56:08] <twnqx> <siretart> Dark_Shikari: which is ridiculus from a distro perspective. it seems to work for you, though... <-- the reason is simple. x264 adds relevant features or bugfixes in regular intervals. [09:56:22] <twnqx> which are way below 3month cycles [09:56:30] <siretart> twnqx: true. but they won't be included in distro releases [09:56:33] <bilboed-pi> siretart, but I don't want us to detect 12 months of regressions at once [09:56:44] <bilboed-pi> siretart, which is why we've currently updated to a more recent checkout [09:56:55] <twnqx> siretart: that's why i use gentoo. my system ffmpeg is svn, updates weekly, my system x264/mplayer/many others as well. [09:57:16] <bilboed-pi> twnqx, afaik, the gst-ffmpeg ebuild doesn't use the system ffmpeg [09:57:27] <siretart> bilboed-pi: experimenting with an updated trunk to spot regression is of course necessary. I'd like to avoid having distros package gst-ffmpeg that come with an internal copy of avcodec [09:57:32] <twnqx> neither does mplayer. i couldn't make the switch to ffmpeg-mt as system lib yet :( [09:58:05] <siretart> twnqx: that's more a '-snapshot' package. this is of course fully ligitimate, but not what I'm talking about [09:58:13] <jai> twnqx: write your won ebuild ;) [09:58:16] <jai> *own [09:58:27] <Dark_Shikari> well there needs to be a balance somewhere [09:58:29] <twnqx> jai: i do have one, but the API changes break everything :P [09:58:32] <Dark_Shikari> 1) you need people on recent versions to catch regressions [09:58:41] <siretart> jai: as for 0.6, we intend to get 0.5.1 out of the door RSN, and then start working on 0.6 [09:58:42] <Dark_Shikari> 2) but you want most people to not deal with regresions [09:58:49] <jai> twnqx: thats ofcourse a problem till mt is merged into trunk [09:59:00] <Dark_Shikari> :/ mt [09:59:31] <jai> siretart: ah, i'm more "concerned" about 0.6 because 0.5.x isnt something where things can be improved/changed [09:59:54] <kshishkov> jai: it will be merged before Duke Nukem Forever is revived and finished ;) [10:00:05] <jai> kshishkov: hehe :) [10:00:20] <siretart> bilboed-pi: I'd really appreciate it if you would ping me before you release the next gst-ffmpeg release, so that we can discuss the 0.6 'situation' and status again. would that work for you? [10:00:49] <Dark_Shikari> it's like dll hell all over again [10:00:58] <siretart> jai: I have a couple of approved patches for 0.5.1, which I'll work on committing this week. [10:00:58] <bilboed-pi> siretart, you could start testing the current gst-ffmpeg trunk [10:01:11] <twnqx> Dark_Shikari: in certain ways, yes, sadly [10:01:15] <Dark_Shikari> except worse [10:01:16] <bilboed-pi> siretart, otherwise we do pre-releases 1-2 weeks before releases [10:01:18] <Dark_Shikari> because dll hell was the _solution_ [10:01:23] <bilboed-pi> siretart, which is common to all gstreamer modules [10:01:30] <jai> siretart: so did you get the whole bugfixes issue sorted out [10:01:35] <siretart> bilboed-pi: okay, in that case, please inform me about such a pre-release, ok? [10:02:05] <bilboed-pi> siretart, I'm pretty sure slomo updates the debian gst-ffmpeg package within hours of pre-releases [10:02:08] <siretart> jai: yes, DonDiego and I went through 'my' distro packages and figured out what is acceptable for 0.5 and what not [10:02:32] <twnqx> Dark_Shikari: the problem also is a difference in user expectation, with people like me wanting to have the latest features and accepting the occasional bug, while others put stability first and don't care about features [10:02:33] <jai> siretart: could this criteri[on|a] be made public please? [10:02:50] <Dark_Shikari> twnqx: well yes. for the latter, we have debian stable [10:03:01] <siretart> bilboed-pi: I'd be pretty disappointed of him if he decided to not use the system ffmpeg packages anymore for gst-ffmpeg. [10:03:02] <Dark_Shikari> where "stability" means "unchanging" as opposed to "not broken" [10:03:02] <jai> i understand you are "The Release Guys" but we would love to know as well [10:03:10] <jai> :) [10:04:18] <siretart> jai: well, the general plan is to include everything that helps distro packages. we want distros to use the release branch and not have them carry tons of regression fixes around [10:04:22] <kshishkov> jai: in this case they are "the distro guys" [10:04:40] <siretart> jai: which means that regression fixes are qualified (almost) automatically [10:05:14] <siretart> jai: as for feature backports, that is to be decided on a case-by-case basis. we need to do a risk estimation for regression potential [10:05:22] <siretart> jai: does this help? [10:05:22] <Dark_Shikari> and effort requirement [10:05:26] <Dark_Shikari> backporting new features is harder [10:05:43] <pross-au> Dark_Shikari: git solves that for us [10:05:44] <pross-au> :D [10:05:49] <Dark_Shikari> no, it's still more work [10:06:00] <siretart> Dark_Shikari: depends on the feature. the/your libx264.c backport seems to me a less risky one than e.g. the proposed wmapro backport I have on the table [10:06:04] <jai> siretart: yes, thats why i didnt mention anything about new features (decoders|demuxers|...). i meant going over closed roundup issues and commiting those changes to the branch [10:06:40] <Dark_Shikari> siretart: yes, by features I meant things in ffmpeg [10:06:49] <Dark_Shikari> if you wanted me to, say, backport _new x264 features_ [10:06:53] <Dark_Shikari> to an old x264 revision [10:06:56] <Dark_Shikari> that would be equally hard [10:06:57] <siretart> jai: let's say, I'd be happy to review and consider nomination for changes targeted at 0.5 :-) [10:06:58] <Dark_Shikari> if not harder than wmapro [10:07:09] <siretart> Dark_Shikari: agreed [10:07:11] <Dark_Shikari> so, siretart, it's been nearly a year [10:07:14] <Dark_Shikari> why are we focusing on 0.5? [10:07:18] <Dark_Shikari> isn't it better to get 0.6 out? [10:07:26] <Dark_Shikari> why do we need to backport to stone age releases? [10:07:36] <twnqx> actually, do you use "3 month" or "3 months" in english? [10:07:45] <Dark_Shikari> twnqx: depends on context [10:07:50] <jai> siretart: excellent, and how would you like this to work? should we just reply to a specific commit on cvslog indicating this [10:07:51] <twnqx> oh [10:07:56] <siretart> Dark_Shikari: a) it's not stone-age, it is not even 12 months old. b) I'm not going to go for 0.6 for the next debian&ubuntu release [10:08:06] <jai> siretart: or separate thread on devel [10:08:12] <Dark_Shikari> siretart: do you have firefox 3.5 in the latest ubuntu? [10:08:24] <Dark_Shikari> If so, why? It's much newer than ffmpeg 0.5. [10:08:26] <siretart> jai: I think a new thread on devel prefixed with [PATCH][0.5] would work best for me [10:08:38] <twnqx> siretart: an x264 is stoneold not by age, but by features. anything before mb-tree should be considered stone-age. [10:08:42] <jai> siretart: cool [10:08:55] <jai> twnqx: +1 [10:08:58] <Dark_Shikari> why is there such an inconsistent application of rules? [10:09:03] <bilboed-pi> siretart, the problem is that we (gst/gst-ffmpeg developers) can't offer any support if you build gst-ffmpeg with a different checkout than the one we specify [10:09:04] <Dark_Shikari> things like firefox get updated instantly [10:09:08] <bilboed-pi> siretart, for obvious reasons [10:09:17] <Dark_Shikari> and yet ffmpeg stays a year old [10:09:39] <siretart> Dark_Shikari: please don't compare the firefox package to the ffmpeg package [10:09:51] <siretart> Dark_Shikari: AFAIUI canonical pays full time developers to care for the package [10:09:57] <jai> thats tied to fanboi count [10:10:06] <jai> and aggressiveness [10:10:10] <siretart> Dark_Shikari: we could reconsider such decisions if we had more manpower [10:10:17] <Dark_Shikari> and yet firefox is still buggy and slow [10:10:26] <siretart> but currently I think we need to stay realistic [10:10:33] <Dark_Shikari> stay realistic: treat all the packages the same way [10:10:36] <twnqx> more so than any ffmpeg/x264 i've encountered so far, living on the edge :P [10:10:43] <siretart> Dark_Shikari: that's not realistic in my book [10:11:00] <Dark_Shikari> what isn't realistic about it? [10:11:11] <twnqx> Dark_Shikari: in siretard's defense, apps are not always upgraded to svn head [10:11:16] <Dark_Shikari> twnqx: yes, I said 0.6 [10:11:17] <Dark_Shikari> not svn head [10:11:22] <siretart> bilboed-pi: I fully understand that. But I just ask you to also understand the distro perspective. you see, I'm actively trying to work out a solution that works for everyone [10:11:28] <Dark_Shikari> i.e. "Focus on latest release, not on backporting to old releases" [10:11:48] <siretart> bilboed-pi: and I consider gst-ffmpeg one of the most important downstreams of ffmpeg [10:11:55] * bilboed-pi waits for flames [10:12:03] * twnqx considers aegisub more important [10:12:12] * jai considers ffdshow more important [10:12:13] <superdump> never heard of aegisub [10:12:14] * jai hides [10:12:19] <bilboed-pi> jai, :) [10:12:43] <Dark_Shikari> siretart: another issue that I notice is that you do releases based on time, rather than based on features [10:12:48] * twnqx doesn't have gstreamer installed [10:12:52] <Dark_Shikari> for example, VLC 1.0.5 was released primarily because of the ffmpeg h264 decoding improvements [10:12:54] <twnqx> what does one use it for? [10:12:58] <Dark_Shikari> This was useful enough for most users that they made an entire release for it [10:13:13] <jai> twnqx: to build pipelines [10:13:19] <siretart> Dark_Shikari: different projects have different release models and therefore different release cycles. there is no 'one size fits all' model nor approach [10:13:25] <Dark_Shikari> of course there isn't [10:13:28] <Dark_Shikari> but there's certainly _wrong_ models [10:13:31] <Dark_Shikari> and _wrong_ approaches [10:13:45] <Dark_Shikari> updates should be pushed when there is a benefit users will gain from them [10:13:51] <Dark_Shikari> not when a clock ticks the right number of times [10:13:52] <siretart> depends on the project, but in general, I tend to agree [10:13:55] <CIA-17> ffmpeg: conrad * r21688 /trunk/libavformat/ (oggdec.c oggdec.h): [10:13:55] <CIA-17> ffmpeg: Fix playback with invalid files that don't set the continuation flag for [10:13:55] <CIA-17> ffmpeg: pages that continue packets started in prior pages. [10:13:55] <CIA-17> ffmpeg: Fixes issue1248 [10:14:20] <siretart> Dark_Shikari: I think we agree on the very next steps, I'd like to start working on them. ok? [10:14:35] <Dark_Shikari> next steps: release 0.6, update to 0.6 [10:14:45] <siretart> yes, among other things [10:15:05] <superdump> as siretart has said, 0.6 won't go into the lucid release - right? [10:15:25] <siretart> superdump: I don't have the ressources to push that, so yes [10:15:50] <siretart> superdump: I plan on working an automatically updated -snapshot package for lucid though [10:15:52] <superdump> which means lucid will be using an ffmpeg that is over a year old [10:16:05] <Dark_Shikari> yup, just like debian all over again [10:16:08] <Dark_Shikari> and like mplayer rc2 (lol) [10:16:13] <Dark_Shikari> This is why I disagreed with the 0.5 release [10:16:17] <siretart> Dark_Shikari: debian ships mplayer rc3 ;-) [10:16:22] <Dark_Shikari> it gives distros an excuse to use outdated, broken software [10:16:36] <Dark_Shikari> if 0.5 didn't exist, a newer ffmpeg would be used by ubuntu. [10:16:44] <twnqx> lol [10:16:55] <siretart> Dark_Shikari: I understand that you are asking distros to not ship ffmpeg, x264 and mplayer at all. Thanks for your support [10:17:08] <jai> lol [10:17:08] <Dark_Shikari> siretart: but they've been doing quite a good job for a while [10:17:11] <Dark_Shikari> at least, good distros have [10:17:13] <twnqx> why are you so fixed on RELEASES? [10:17:20] <Dark_Shikari> x264 doesn't have releases, yet you ship it [10:17:22] <twnqx> just ship a working svn checkout, done [10:17:28] <Dark_Shikari> mplayer doesn't have releases [10:17:30] <Dark_Shikari> yet it gets shipped [10:17:34] <Dark_Shikari> ffmpeg didn't have releases for years [10:17:36] <Dark_Shikari> yet it got shipped [10:17:39] <Dark_Shikari> And then ffmpeg came out with a release [10:17:42] <Dark_Shikari> AND YOU STOPPED SHIPPING [10:17:47] <Dark_Shikari> notice a pattern? [10:18:02] <jai> it called a "sync point" iirc [10:18:05] <siretart> Dark_Shikari: but still you complain that distro release come with horribly outdated packages [10:18:15] <twnqx> uh [10:18:27] <siretart> Dark_Shikari: I'm working on limiting the number of versions of horribly outdated packages [10:18:32] <twnqx> he is just saying that the horribly old version is BECAUSE OF the 0.5 release [10:18:43] <twnqx> and wouldn't happen if there was no release [10:18:46] <Dark_Shikari> yes, before 0.5, ubuntu did not ship 0.49 [10:18:52] <Dark_Shikari> because 0.49 was Horribly Outdated [10:19:00] <siretart> has anyone looked at other distros? e.g. what version of ffmpeg is shipped by say, openbsd or opencsw (solaris)? [10:19:01] <superdump> 0.4.9* methinks [10:19:06] <Dark_Shikari> siretart: gentoo has a pretty sane system [10:19:20] <twnqx> gentoo uses svn 20373 as stable [10:19:32] <thresh> gentooo doesnt care about packages being rebuildable in a whole distro [10:19:39] <twnqx> they doo [10:19:39] <siretart> Dark_Shikari: I discussed the situation with luca yesterday [10:19:41] <twnqx> do* [10:19:44] <twnqx> at least within stable. [10:19:44] <Dark_Shikari> it's actually rather sad that gentoo has the most reliable media backend package-wise [10:19:47] <siretart> anyway, I need to get back to work now [10:20:04] <siretart> if there is something pressing, please query or ping me, or better, mail it to ffmpeg-devel@ [10:20:12] <Dark_Shikari> then again, this kind of thing is what fuels the anti-binary-distros flames [10:20:23] <Dark_Shikari> ancient packages, release obsession [10:20:37] <DonDiego> siretart: what about the wiki page? [10:21:06] <twnqx> having a version you can compile your apps against has some valid point, that's why the never ffmpeg versions are hardmasked on gentoo [10:21:12] <twnqx> newer* [10:21:39] <siretart> DonDiego: yes, I'll work on that. either tonight or tomorrow [10:22:46] <jai> siretart: to avoid any duplication, do you already have a patchset which proposed? [10:22:50] <jai> for the next version that is [10:23:04] <superdump> Dark_Shikari: well, i use a number of ppas to get more current packages of things i want [10:23:14] <jai> because i'd like the theora and vorbis related fixes go in [10:23:15] <superdump> but, maybe average joe wouldn't do that [10:23:22] <superdump> or wouldn't know to do that [10:23:30] <siretart> jai: it is published on git.debian.org, look for the ffmpeg branch, in the debian/patches/security subdirectory [10:23:45] <siretart> jai: almost all patches there are approved, with 2 exceptions that are not marked [10:23:50] <jai> siretart: right, k [10:23:55] <superdump> so while snapshots would be a nice supplement, using year old ffmpeg is too old really [10:24:11] <jai> siretart: maybe this can be maintained on something closer to home later [10:24:22] <jai> on mphq for example [10:24:35] <siretart> jai: probably [10:25:15] <twnqx> superdump: there are "compile yourself" docs for debian all over the web, there must be thousands of users being forced to do that anyway [10:25:23] <siretart> superdump: the main use I envision for distro packages is to have something application can be linked against. ideally, users will install -snapshot packages over them and have additional functionality for existing applciation instantly [10:25:58] <Dark_Shikari> siretart: in that case wouldn't it be sensible to have two versions of ffmpeg? [10:26:04] <Dark_Shikari> or better said [10:26:11] <Dark_Shikari> one version of ffmpeg, one, stable version of libav* [10:26:26] <Dark_Shikari> of course this gets tricky for applications like gst that just wrap ffmpeg [10:27:02] <bilboed-pi> Dark_Shikari, having the various libav* separated would be nice tbh [10:27:17] <siretart> Dark_Shikari: yes, I intend to have 2 packages: one called 'ffmpeg' the other one 'ffmpeg-snaphsot'. the latter is not for distro releases at all but only for add-on repos to replace the distro ones [10:27:19] <bilboed-pi> (side effect would be spotting the numerous cross-depencies) [10:27:30] <siretart> anyway, lunchtime.now [10:48:59] <jez9999> does ffmpeg redefine things like 'struct sockaddr_storage' from its original POSIX definition? [10:54:28] <pross-au> jez9999: NO [10:55:56] <jez9999> then what's struct sockaddr_storage doing in network.h? [11:27:57] <jai> i havent looked, but i'm sure its #ifdef'd out for systems which have it [11:30:34] <jez9999> in the form of #if !HAVE_STRUCT_SOCKADDR_STORAGE [11:30:46] <DonDiego> yes, so? [11:30:50] <jez9999> HAVE_STRUCT_SOCKADDR_STORAGE is something that i can't find anywhere, seems to be ffmpeg-specific or something [11:30:58] <DonDiego> configure sets it [11:31:13] <jez9999> point is, i'm getting a build error about redefinition of 'struct sockaddr_storage' [11:31:38] <DonDiego> in network.h? [11:31:41] <jez9999> yep [11:32:48] <DonDiego> wait [11:32:55] <jez9999> if i remove the include for network.h it says it hasn't been defined. heh. [11:32:57] <DonDiego> what business do you have with network.h? [11:33:08] <DonDiego> that's an internal ffmpeg header [11:33:12] <jez9999> passing a network address into the libavformat api. [11:33:30] <DonDiego> that header should not be necessary [11:33:40] <jez9999> how else do i store a sock addr? [11:33:56] <DonDiego> sockaddr_storage is a standard POSIX thing [11:34:07] <jez9999> yeah, but i thought the point about network.h was that ... [11:34:09] <jez9999> hmm [11:34:24] <jez9999> so you're not defining it for the purpose of making it non-POSIX. [11:34:27] <jez9999> that's a problem [11:34:47] <jez9999> i kinda need it to be non-POSIX if it's gonna be added to the libavformat API [11:35:16] <DonDiego> i just see that it's not posix [11:35:42] <DonDiego> netinet/in.h on my system [11:35:56] <DonDiego> use that header [11:36:20] <jez9999> sure, but that *is* posix [11:36:53] <DonDiego> no, socket.h actually [11:37:39] <jez9999> that's system-specific [11:37:44] <DonDiego> that's the header you need [11:38:23] <jez9999> you can pass system-specific stuff into the ffmpeg API? [11:38:50] <DonDiego> you still have not told us what you are doing [11:39:03] <DonDiego> (except for messing with libavformat internals, which you should not) [11:39:18] <jez9999> why not? i need to add fundamentally new functionality. :-) [11:39:22] <pross-au> jez9999: we discussed this last week mate [11:39:26] <jez9999> yep [11:39:37] <jez9999> i'm allowing a network address to be passed into ffmpeg as a member of AVFormatContext [11:39:58] <DonDiego> well, ok, then you guys who know the context take it from here [11:41:35] <jez9999> this is a mess. ffmpeg does use sockaddr_storage internally, but not in the API [11:41:47] <jez9999> and because it's a POSIX thing, it includes its own definition for it just in case [11:41:56] <jez9999> the system doesn't have POSIX support [11:42:09] <jez9999> however i need to turn it into a public struct... and use it in the public API [11:42:15] <mru> you can't do that [11:42:24] <mru> I've told you why before [11:43:03] <jez9999> because it's a posix struct? [11:43:28] <mru> the api must be plain C [11:43:31] <mru> no extensions [11:43:44] <jez9999> which is why im wanting to use the version defined in ffmpeg itself [11:43:57] <pross-au> jez9999: use void*, as we discussed last week [11:43:59] <mru> that doesn't work [11:45:05] <pross-au> { void *address_list; int nb_addresses; int sizeof_sockaddr; } [11:47:07] <jez9999> and then both the calling code and ffmpeg use the POSIX sockaddr_storage? [11:48:05] <mru> you'd better pray they do [11:48:34] <jez9999> yeah...... you can't guarantee that the calling code will pass in the right structure [11:48:45] <jez9999> that's an acceptable risk in the public api? [11:51:57] <jez9999> in fact, how do you even specify what structure should be passed in? [11:52:03] <jez9999> it's not posix, it's not defined in ffmpeg itself [11:53:27] <pross-au> i think its acceptable. sa_family is always a char. [11:53:36] <pross-au> ** for the bulk of platforms ** [11:54:08] <mru> what makes you think there will even be an sa_family on all platforms? [11:55:09] <pross-au> show me a platform that doesnt have sa_family.. [11:55:30] <mru> there are all sorts of weird tcp/ip implementations [11:55:42] <pross-au> example [11:55:55] <pross-au> strawman arguments have no place here [11:55:58] <jez9999> pross-au: but isn't sa_family defined inside the posix-specific sockaddr? [11:56:11] <jez9999> which means you've got posix-specific stuff in the api [11:56:12] <pross-au> jez9999: yes, and its the first byte [11:56:18] <mru> various embedded stuff [11:56:50] <jez9999> pross-au: so.... you're saying to rely on posix functionality for this feature, but make sure it will complie no matter what by using a void* [11:57:01] <jez9999> however on platforms where it wouldnt compile, this functionality would be unusable too [11:58:01] <pross-au> thats what i said [11:58:07] <jez9999> (where it wouldn't have compiled if you actually put sockaddr in AVFormatContext) [11:58:15] <jez9999> ok [11:58:20] <pross-au> you're already using posix functionailty. char *filename; <-- what the hell is that?? :D [11:58:37] <jez9999> and just for future reference, was there a way for me to know that network.h was an internal and not an API header? [11:58:46] <jez9999> or is it something you 'just need to know'? :-) [11:58:48] <pross-au> the syntax of the filename is operating system dependant. [11:59:01] <pross-au> so why is sockaddr any different? [12:00:03] <mru> pross-au: I have never so much as heard of a system where filenames are not null-terminated strings [12:00:12] <mru> although on windows they are sometimes utf16-encoded [12:00:18] <mru> we've had some trouble with that [12:00:39] <pross-au> mru: ive never heard of a tcp/ip implementation that doesnt use sa_family [12:01:05] <mru> network stuff is much more diverse [12:01:09] <pross-au> filename or sockaddr, they are just a buffer you pass to the operating system [12:01:23] <mru> I've certainly seen tcp implementations with incompatible address structs [12:01:32] <mru> I don't remember if they all had sa_family or not [12:01:42] <mru> but the exact name is irrelevant [12:01:55] <mru> sometimes it's a byte, sometimes 16 bits [12:02:03] <pross-au> mru: fair point [12:02:46] <pross-au> given that your passing the filename to fopen() or whatever. then the same rules could apply to bind() or recvfrom() [12:03:26] <pross-au> i.e. Rule: FFmpeg will pass this onto the operating system. [12:03:54] <pross-au> we're not unpacking sockaddr_storage [12:04:47] <mru> I was under the impression this address was to be examined by lavf [12:05:34] <mru> the portable way to represent an IPv4 address is ascii a.b.c.d notation [12:07:37] <jez9999> needn't be an ipv4 [12:07:38] <jez9999> :-) [12:07:47] <jez9999> and just for reference guys, was there a way for me to know that network.h was an internal and not an API header? [12:08:17] <mru> that it's not installed by make install [12:10:41] <jez9999> any convenient list of what is installed by make install? [12:10:44] <jez9999> in one place? [12:10:50] <mru> the makefile [12:11:47] <DonDiego> mru: how hard would it be to have FATE track the 0.5 branch for a little while? [12:11:48] <pross-au> Sockaddr <-> ASCII representations should be performed by the sockets library, not FFmpeg. [12:12:17] <DonDiego> or possibly in addition to trunk? [12:12:21] <DonDiego> or should i ask mike? [12:14:44] <jez9999> mru: that was kind of my point, there's a bunch of files constituting the makefile [12:16:15] <DonDiego> run 'make -n install' [12:16:57] <DonDiego> ok, i'm out, cu [12:17:04] <jez9999> bye [13:03:44] * _av500_ is in ADL2010 with ffmpeg FOSDEM tshirt [13:06:16] <CIA-17> ffmpeg: michael * r21689 /trunk/libavcodec/h264_direct.c: [13:06:16] <CIA-17> ffmpeg: Detect equal 4x4 blocks in spatial direct MBs. [13:06:16] <CIA-17> ffmpeg: 19 cycles slower MV generation [13:06:16] <CIA-17> ffmpeg: 575 cycles faster MC [13:13:23] <twnqx> uh, ffmpeg is building a h264 encoder of its own? [13:13:32] <mru> no [13:13:34] <kshishkov> no [13:13:40] <twnqx> mh [13:14:47] <andoma> no [13:15:02] <_av500_> no [13:15:05] <Compn> no [13:15:22] <elenril> yes! [13:15:24] * elenril runs [13:15:24] <kshishkov> you can try to fork x264 and rewrite it for FFmpeg (preferaby LGPL) though [13:15:50] <Compn> U.S. Department of Defense LPC-10 2400 bps Voice Coder Release 1.0 October 1993 [13:16:13] <Compn> lots of speech codecs from the 90s to be implemented :) [13:16:21] <mru> :-) [13:17:04] * Compn collects some samples and decoders and puts it on small tasks page [13:18:11] <twnqx> so for my understanding of the last commit, the decoder has do generate motion vectors? [13:18:42] <kshishkov> for prediction or something [13:18:48] <andoma> twnqx: from the coded bitstream yes [13:19:02] <twnqx> oh [13:20:01] <Compn> This packet contains the C source for a mixed-radix FFT routine. [13:20:06] <Compn> NOTE : This is copyrighted material, NOT public domain. See below. [13:20:06] <Compn> bah [13:20:27] <mru> ? [13:20:42] <Compn> Non-commercial use of the source code is free. [13:21:09] <Compn> strange license [13:21:20] <Compn> ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/analysis/ [13:22:03] <kshishkov> Compn: when I was young I collected those, DoD LPC-10 is very famous [13:27:18] <Compn> still have the samples somewhere ? if so, upload them ? [13:27:22] <Compn> 2.4 kbps MELP Proposed Federal Standard speech coder [13:27:47] <kshishkov> samples were in reference implementation package [13:27:57] <kshishkov> male/female voice or something [14:43:39] <justlooking_> hmm given that 10 Jan 17:42 "Diego Biurrun said:How about making 2010 the year of performance improvements?" Michael Niedermayer replyed "Prerequesite to that would be keeping h264 discussions where the only person [14:43:40] <justlooking_> who works on our decoder (yeah thats me) sees them Its really sad, how often do i have to repeat that i cannot do all the work [14:43:40] <justlooking_> alone. Now if people refuse to send cleanly split patches, could they at least [14:43:40] <justlooking_> _please_ keep their h264 discussions on ffmpeg-dev!" is 3 months fine grained enough, and as Michael requested it, when will ffmpeg be updated to take generic $todays=NOW x264cli command line arguments directly. [14:43:57] <justlooking_> http://thread.gmane.org/gmane.comp.video.ffmpeg.cvs/26814 [14:45:48] <Compn> justlooking_ : erm, whats your point ? [14:46:06] <Compn> or your question, i got lost [14:47:24] <superdump> i don't think michael has ever requested ffmpeg being able to accept x264 cli options [14:47:41] <superdump> not directly [14:48:04] <superdump> but maybe justlooking_ meant just having all api options that are relevant being visible [14:48:14] <superdump> and alterable [14:50:15] <justlooking_> Michael's updating h.264 a lot and has commited to speed improvements and yes it seems all available x264 options should be available to ffmpeg as soon as is possible, however that make be done, perhaps Michael can do that? [14:50:47] <merbzt> perhaps you can do it ? [14:51:10] * kshishkov wonders if it's blasphemy to prepend MN name with unprintable characters [14:51:20] <mru> kshishkov: those are tabs [14:51:44] <elenril> aren't tabs forbidden on irc? ;) [14:51:55] <mru> only on #ffmpeg-svn [14:51:59] <merbzt> the better business bureau [14:52:11] <superdump> lo BBB_ [14:52:15] <BBB_> hello [14:52:32] <superdump> justlooking_: i wouldn't want michael to spend his time on such relatively trivial tasks [14:52:39] <justlooking_> its in the log bot nowm i cant change it. [14:53:02] <elenril> can anyone with access to git.ffmpeg.org make a git-svn mirror for nut? [14:53:04] <BBB> there's #ffmpeg-svn? [14:53:10] <kshishkov> BBB: you better hide, that "RTP filtering" guy is after you [14:53:13] <BBB> any more #ffmpeg-channels I should know about? [14:53:19] <BBB> kshishkov, that's ok [14:53:20] <kshishkov> BBB: it's ML [14:53:25] <BBB> oh, ok [14:53:44] * BBB just had his honeymoon vacation [14:54:11] <superdump> when did you get married? [14:54:16] * BBB will take care of google money today [14:54:26] <kshishkov> superdump: it's in his blog [14:54:32] <BBB> actually it is [14:54:36] <BBB> august last year [14:54:40] <kshishkov> BBB: what, all of Google money? [14:54:41] <BBB> but never had a honeymoon [14:54:46] <BBB> kshishkov, the 2009 one [14:54:51] <superdump> well, belated congratulations [14:54:53] <BBB> the 2008 one is in process, we're 11 months past deadline [14:55:04] <BBB> so I have to jump through some hoops [14:55:04] <merbzt> :) [14:55:11] <BBB> but I think it'll work [14:55:17] <BBB> leslie is very nice [14:55:33] <BBB> I guess we're not the only project that is... horrible at planning this kind of stuff [14:55:43] <BBB> let's get 2010 rolling [14:55:49] <mru> +t [14:55:49] <BBB> did everyone advertise it on his blog? [14:56:20] <mru> BBB: do we have bank accounts now? [14:56:21] <merbzt> #join #openwrt [14:56:39] <kshishkov> merbzt: advertised for GSoC [14:57:18] <merbzt> ok ? [14:57:31] <BBB> mru: yes [14:58:01] <mru> BBB: good, let's fill 'em up! [14:58:17] <merbzt> BBB: both eu and us ? [14:58:25] <BBB> us only for now [14:58:36] <BBB> I think reimar might be working on the eu, but that'll take another while [14:58:39] <BBB> it's in progress [14:58:48] <kshishkov> BBB: he does [14:58:58] <kshishkov> BBB: in the best part of Europe actually [14:59:08] <BBB> if anyone can help quickly setting up a FREE FREE FREE (no monthly charge) account, that'd be very helpful [14:59:09] <kshishkov> although some Turks may disagree [14:59:14] <BBB> sve is ok [14:59:23] <BBB> (reimar is sve, right?) [14:59:27] <kshishkov> yes [14:59:28] <mru> yes [15:00:10] <kshishkov> well, I have some free accounts but good luck _putting_ money to them or withdrawing later [15:00:57] <BBB> being able to take money off of it would be a nice bonus [15:01:32] <kshishkov> yep [15:01:44] <kshishkov> it's hard to withgraw money here [15:01:52] <kshishkov> only Hrivnias [15:02:41] * BBB goes catch up with some work [15:05:47] <superdump> whereabouts in sweden is reimar? [15:06:03] <kshishkov> Lund [15:09:53] <pJok> must kill reimar.... [15:10:06] <pJok> (its about 20 minutes south of where i live) [15:10:38] <mru> whatever did reimar do to you? [15:10:45] <pJok> nothing :) [15:11:05] <pJok> i just had to say it, since he's so close [15:11:16] <pJok> i better be going back to doing actual work again [15:12:35] <mru> yes, or else reimar might come for you [15:25:15] <_av500_> mru: back? [15:25:20] <mru> airport [15:25:22] <_av500_> ah [15:25:25] <_av500_> with the cat? [15:25:39] <mru> no [15:26:04] <mru> the cat is on a later flight [15:26:24] <jez9999> hum [15:27:00] <jez9999> pross-au recommended I pass { void *address_list; int nb_addresses; int sizeof_sockaddr; } into the libavformat API [15:27:08] <jez9999> to pass a list of sockaddr's in [15:27:21] <jez9999> i'm using the first 2, but why would he suggest I pass in sizeof_sockaddr? [15:27:23] <mru> I still don't see why you want/need to do that [15:27:32] <jez9999> well assuming there were a valid reason [15:27:32] <jez9999> :-) [15:27:38] <mru> pass addresses, that is [15:27:54] <mru> if you must pass addresses, you obviously must also pass the size [15:28:17] <jez9999> why? the idea is to rely on the system defining things like sockaddr_storage for us [15:28:34] <jez9999> so the calling code and ffmpeg both just assume address_list is an array of sockaddr_storage [15:28:51] <mru> many systems don't provide such a thing [15:29:01] <jez9999> yep, and this mechanism isnt going to work on such systems [15:29:08] <jez9999> (actually i bet most are posix-compliant) [15:29:08] <mru> many systems provide no networking at all as part of the system itself [15:29:16] <jez9999> so be it. [15:29:27] <jez9999> what about on poxis-compliant systems? [15:29:29] <mru> so if you want networking you need bring your own lib [15:29:58] <jez9999> yeah but im having to assume posix compliance here [15:29:59] <mru> ffmpeg's networking code could be easily extended to run on top of any reasonable tcp stack [15:30:10] <jez9999> easily? [15:30:47] <mru> assuming it has the usual set of socket/connect/send/recv functions [15:31:04] <jez9999> they're posix. [15:31:29] <mru> if you're doing tcp they are the natural way to do it [15:31:43] <mru> the exact format of an address varies, however [15:31:57] <mru> that's why there are functions for translating ascii strings into addresses [15:32:15] <mru> ideally the app using lavf shouldn't need to care what networking lib is used [15:32:35] <jez9999> sigh [15:32:41] <jez9999> why did that guy recommend a void* list then [15:35:04] <_av500_> mru: gee, bb ml wants to know about the vw [15:35:31] <jez9999> if the code is to be compliant with non-POSIX systems, doesnt that mean more complex code in ffmpeg? [15:35:45] <jez9999> like preprocessor defs to check what kind of system it is and perform different behaviour? [15:35:46] <mru> _av500_: most of it is in OE [15:35:53] <_av500_> yes [15:36:08] <_av500_> ill write up a page with a few pics etc and put links to the relevant stuff [15:36:20] <mru> jez9999: we support only posix systems _now_ [15:36:34] <_av500_> perfect op to make my 1st blog post [15:36:41] <mru> if/when someone wants to use ffmpeg on some obscure tcp stack, there should be nothing stopping that [15:36:48] <_av500_> (if I remember the pwd..) [15:36:55] <jez9999> mru: what? i'm confused. [15:37:10] <jez9999> i thought the whole point was that you supported non-posix systems [15:37:16] <jez9999> thats why you cant put posix stuff in the api [15:37:29] <mru> exactly [15:37:40] <jez9999> so why did you say you support only posix systems [15:37:45] <mru> and if it's not posix, how is the calling app supposed to figure out the format of an address [15:37:55] <mru> jez9999: the code inside lavf only works with posix for now [15:38:06] <mru> because nobody has had the need to run it elsewhere [15:38:39] <jez9999> so... it's ok to add more code that only works with posix [15:38:52] <mru> not what you're thinking of [15:39:09] <mru> that exposes non-portable data structures through the api [15:39:27] <mru> void * or not, the contents are system-specific [15:39:36] <jez9999> i dont get why posix defines that you have to have some data structure, but then leaves it to you to determine the format [15:39:37] <jez9999> :-) [15:39:46] <jez9999> why didnt they just say "represent it this way, damnit" [15:40:42] <mru> the tcp spec only defines the wire protocol [15:40:54] <mru> not the memory representation [15:41:03] <jez9999> posix isnt the tcp spec [15:41:22] <mru> I know that [15:41:38] <mru> the posix socket api is transport-independent [15:42:28] <jez9999> so it tells you to define sockaddr 'in some way' [15:42:46] <mru> gtg go catch my flight [15:42:47] <mru> back later [15:43:19] <BBB> jez9999, if that were the case, ipv6 would never have happened [15:43:36] <jez9999> so it tells you how to define sockaddr [15:43:58] <BBB> not to mention the possibility of having something else as tcp/ip, e.g. novell's thingy(?) or microsoft's netbeui(?) [15:44:22] <BBB> I'm not saying those are good ideas, I'm just saying that the api allows all of that in a single one [15:46:09] <jez9999> BBB: if what were the case? [15:46:20] <jez9999> you mean a fixed representation [15:46:23] <BBB> yes [15:46:39] <BBB> look, the callback is not going to be part of the ffmpeg api [15:46:43] <BBB> I told you that, michael did [15:46:46] <BBB> luca also, I think [15:46:51] <BBB> stop thinking of that [15:46:53] <BBB> it's bad api [15:46:55] <BBB> it won [15:46:57] <BBB> t happen [15:47:07] <jez9999> this isn't a callback, this is passing addresses in [15:47:18] <BBB> won't happen either [15:47:22] <BBB> it doesn't address the issue [15:47:29] <jez9999> pun intended [15:47:34] <BBB> :) [15:47:42] <_av500_> :) [15:47:44] <BBB> I want something that does not require the application to do something [15:47:57] <BBB> I want rtsp.c and rtpdec.c to handle it internally [15:48:02] <BBB> I explained in the bug report how to do that [15:48:07] <BBB> it's a little bit more difficult to code [15:48:12] <jez9999> we've discussed this. sdp does not provide a surefire mechanism for specifying the ssrc [15:48:16] <BBB> but it address the issue much more beautifully [15:48:29] <BBB> I want ssrc collission detection [15:48:35] <jez9999> and what then? [15:48:39] <jez9999> so you've detected a collision [15:48:41] <BBB> then rtsp can - for my part - export it as two streams [15:48:42] <jez9999> how does it resolve it [15:48:50] <jez9999> 2 streams....... [15:49:04] <jez9999> you've opened 1 stream [15:49:11] <BBB> the source - according to the spec - is responsible for new ssrc setup once a collission within a session has been detected [15:49:17] <jez9999> via av_open_input_file [15:49:20] <BBB> you open one session (av_open_*()) [15:49:33] <BBB> a file/session can have multiple streams (ctx->streams, AVStream) [15:49:56] <BBB> just like an avi can have one video and one audio stream [15:50:01] <BBB> or an english and a french soundtrack [15:50:08] <BBB> or subtitles in different languages [15:50:15] <BBB> or a dvd can have lpcm + mp2 music [15:50:46] <jez9999> it would have to be added dynamically [15:50:50] <BBB> but whatever representation, I want rtsp to do the collision handling and detection [15:50:55] <BBB> yes, dynamic stream adding is supported [15:51:00] <BBB> in fact, rtsp already uses it [15:51:02] <BBB> (see rdt.c) [15:51:22] <jez9999> btw you shouldnt refer to it as rtsp [15:51:22] <jez9999> :-) [15:51:45] <BBB> well, you know what I mean [15:51:51] <BBB> rdt is at a same level as rtp [15:51:56] <BBB> called by rtsp/sdp [15:51:59] <BBB> so you'll get the idea [15:53:10] <jez9999> so the calling code gets 2 streams [15:53:17] <jez9999> how does it know which to discard? [15:53:53] <BBB> one solution might be to provide two streams [15:54:05] <BBB> the other is to add logic to rtp so it simply rejects one [15:54:13] <BBB> either way collission detection is the first step [15:55:55] <jez9999> im presuming that the solution is that ffmpeg provide 2 streams [15:56:00] <jez9999> how does the calling code know which to discard? [15:56:45] <BBB> it depends what the streams are [15:57:14] <jez9999> ? [15:59:07] <jez9999> howso? [15:59:21] <BBB> you're telling me the streams are from different cameras right? [15:59:39] <BBB> so then they're different content, i.e. one must be rejected [15:59:49] <jez9999> yep [16:00:02] <BBB> if they were the same camera or different angles, i.e. it's intended and they represent same content, then you'd want 2 streams [16:00:28] <BBB> so for this particular case, once the ssrc collision is handled, you want to reject one [16:00:36] <BBB> the logic for which one to reject can be discussed [16:01:58] <jez9999> very short discussion [16:02:03] <jez9999> base it on source IP [16:02:28] <BBB> the simplest would be to open the file as file.sdp?source_ip=ip.ip.ip.ip [16:02:29] <BBB> or host [16:03:02] <BBB> then you don't need all that creepy stuff that you just said about void * address, int num_addresses; struct size; I_get_scared_by_this; [16:03:43] <BBB> but that can only be done if the ssrc collision has been handled [16:03:57] <BBB> before that, the source data from ips can be intended, as luca abeni explained in the issue tracker entry [16:04:29] <jez9999> "the source data from ips can be intended"? [16:04:31] <lu_zero> hi [16:04:35] <jez9999> hello [16:05:19] <lu_zero> how's going? [16:05:25] * lu_zero now is in Geneve [16:05:35] <jez9999> snowing here [16:05:36] <jez9999> :-) [16:06:33] <BBB> the fact that data is coming in from several (different) source ips can be intended [16:06:43] <BBB> we want to continue handling that correctly [16:07:25] <jez9999> if a source ip is specified in the url, then why do you need to worry about collision detection? [16:07:36] <jez9999> you're asking to limit it to the specified IP(s) anyway [16:09:52] <jez9999> in fact it would be misleading to decode and return a stream of data from a different address [16:10:33] <BBB> at the very least you're not asking me to put a source ip in AVPacket anymore [16:10:34] <BBB> :) [16:10:34] <lu_zero> still I'm missing if the rtpdec does filter by ssrc or not [16:10:45] * BBB notices progress [16:10:50] <jez9999> :-) [16:10:54] <lu_zero> the problem is better defined now [16:11:03] <jez9999> i don't believe it does at the moment, lu_zero [16:11:21] <jez9999> it has nothing to go on... no ssrc is provided to it [16:12:01] <lu_zero> ok, that should implemented nonetheless [16:12:12] <jez9999> that's a different feature though [16:12:40] <BBB> for rtsp, it's needed, since the ssrc is known [16:12:45] <BBB> sdp is kinda of more problematic [16:12:48] <jez9999> i dont do rtsp [16:12:51] <BBB> I know [16:12:51] <jez9999> :-) [16:13:01] <BBB> I'm just supporting lu_zero's case that we should implement it [16:14:16] <jez9999> well that's a separate discussion as it's a separate feature [16:14:35] <jez9999> so what about with regards to specifying source address? [16:15:02] <jez9999> you're talking about limiting it to an IP address. one of the nice things about using sockaddr_storage was that it (theoretically) supports any network address [16:15:47] <BBB> udp also goes over ip addresses [16:15:51] <BBB> so does tcp [16:15:56] <jez9999> it can do [16:15:56] <BBB> so I don't see where you're going [16:16:02] <lu_zero> hmm [16:17:04] <jez9999> unix domain sockets? [16:17:08] <BBB> to specify the ssrc (or source ip) if you're opening a sdp is ok with me [16:17:15] <BBB> unix domain sockets don't do udp [16:17:18] <BBB> they also don't do tcp [16:17:19] <lu_zero> jez9999: that's a feature I want to implement [16:17:36] <lu_zero> BBB: but is _quite_ nice to have unix sockets supported [16:17:54] <lu_zero> (loopback drops udp) [16:18:35] <BBB> you really want that? [16:18:39] <BBB> hmk then [16:19:25] <BBB> anyway, any argument in public api using that is not ok [16:19:30] <BBB> I want it as part of the uri, if anything [16:19:39] <BBB> since for rtsp, it's implicity in the uri / data stream [16:19:51] <BBB> it's logical that for sdp, you'd include it as part of the uri (optionally) [16:20:17] <BBB> filename.sdp?ssrc=X or filename.sdp?srcip=X.Y.Z.z [16:20:32] <jez9999> BBB: http://pastebin.com/m1e941c78 [16:20:45] <jez9999> 2 of 37 are IP ;-) [16:20:58] <BBB> yes [16:20:59] <lu_zero> ^^; [16:21:07] <BBB> which of those support rtp? [16:21:27] <jez9999> any which is connectionless, theoretically [16:21:38] <jez9999> erm [16:21:39] <lu_zero> rtp is over dccp, sctp, udp, tcp, rtsp, http, [16:21:42] <jez9999> what am i talking about, they all arer [16:21:56] <lu_zero> at least I know implementations of that [16:22:05] <BBB> tcp is ip, i.e. inet or inet6 [16:22:08] <BBB> http is also [16:22:36] <jez9999> theoretically you could put RTP over any of those socket types i'd guess [16:22:57] <lu_zero> yup [16:23:43] <BBB> why don't we do it this way: you go discuss with michael an api that allows all of those be supported as part of your api proposal [16:24:00] <CIA-17> ffmpeg: michael * r21690 /trunk/libavcodec/h264_direct.c: [16:24:00] <CIA-17> ffmpeg: Detect spatial direct MBs partitioned smaller than 16x16 that can be partitioned [16:24:00] <CIA-17> ffmpeg: as 16x16 (except ones changing interlacing relative to the colocated MB). [16:24:00] <CIA-17> ffmpeg: 20 cycles slower during MV generation [16:24:00] <CIA-17> ffmpeg: 175 cycles faster during MC [16:24:07] <BBB> once you're done with him rejecting you, we'll talk again about the simple filename.sdp?source=string api that I suggest [16:24:31] <BBB> we can word it such that in theory string can be a nonip thing [16:24:40] <BBB> that way everyone is happy [16:26:00] <jez9999> source=ipv4:1.2.3.4 [16:26:01] <jez9999> ? [16:27:29] <BBB> anything that getaddrinfo() supports is fine with me [16:28:47] <BBB> (don't forget that rtp/rtsp/sdp use getaddrinfo() practically everywhere to figure out this kind of stuff) [16:30:31] <jez9999> ?sourceaddr=x [16:30:34] <lu_zero> brb [16:30:42] <jez9999> where x is a string dropped straight into getaddrinfo() [16:33:54] <BBB> source, sourceaddr, sourceip [16:33:57] <BBB> you get what I mean [16:34:05] <BBB> I don't mind much what you prefer to call it [16:34:24] <BBB> as long as it's documented what it is [16:41:49] <jez999> BBB: what about specifying multiple source addresses? [16:55:13] <kierank> [14:52] <@merbzt> the better business bureau --> I always thought it was big buck bunny [17:00:16] <Compn> where is the wishlist again ? [17:00:23] <Compn> it was on the wiki... is it now in roundup ? or svn ? [17:05:59] <elenril> J_Darnley: btw does your patch add support for writing ogg metadata too [17:06:03] <elenril> or just raw flac? [17:24:11] * BBB curses as google sends him openoffice template files [17:24:23] <BBB> the one thing that is worse than receiving MS Office files, is receiving OpenOffice files [17:24:24] <kshishkov> wanna get .docx instead? [17:24:29] <BBB> YES [17:24:35] <BBB> I happen to have MS Office installed [17:24:44] <kshishkov> the latest? [17:24:51] <BBB> I'm not gonna download a 2TB software package that is slow, crippled and bloated [17:24:59] <BBB> 2007, I think [17:25:03] <BBB> should be relatively new [17:25:08] <BBB> free from uni :) [17:25:09] <kshishkov> and you happen to have MS Office installed? [17:26:31] <kshishkov> have you tried AbiWord instead? [17:26:50] <CIA-17> ffmpeg: michael * r21691 /trunk/libavcodec/h264_direct.c: [17:26:50] <CIA-17> ffmpeg: Set partitioning to 16x16 for spatial direct MBs with mixed interlacing. [17:26:50] <CIA-17> ffmpeg: 11cylcles slower MV generation [17:26:50] <CIA-17> ffmpeg: 98cycles faster MC [17:27:00] <BBB> I could install kword [17:27:04] <BBB> or nword [17:27:05] <BBB> or bword [17:27:07] <BBB> or lword [17:27:11] <BBB> or curseword [17:27:15] <BBB> but I want a frigging pdf [17:27:15] <kshishkov> [a-z]word [17:27:35] <ohsix> abiword :> [17:27:36] <BBB> can anyone here convert the ods to pdf (or doc) for me? [17:27:53] <kshishkov> yes, never trust a format that connot be read by <2 opensource implementations [17:28:23] <kierank> [17:27] <@BBB> can anyone here convert the ods to pdf (or doc) for me? --> yes [17:28:37] <BBB> great! where do I email it? [17:29:23] <kshishkov> BBB: can't you open it with GoogleDocs online? [17:30:07] <J_Darnley> elenril: at present, just raw flac. but see an older email of mine which has another patch which adds tags for ogg-flac and ogg-speex [17:30:10] <BBB> gmail has no "view" button for this [17:36:29] <BBB> googledocs worked [17:36:31] <BBB> yay [17:43:36] <elenril> J_Darnley: cool [17:43:45] * elenril summons jruggles from depths of hell [17:45:33] <kshishkov> North Carolina is not "depths of hell" I think [17:45:37] <kshishkov> try different location [17:45:45] <elenril> depends on who you ask [17:46:45] <Compn> BBB : i agree, i'd love to see a 2mb doc/odf viewer [17:46:50] <Compn> or smaller :) [17:47:12] * Compn looks at all his word for windows 2.0 documents and then looks at openoffice.org cant open them [17:47:39] <Compn> course, i dont think new office can open them either, but its been a hwile since i tried [17:47:58] <kshishkov> elenril: ask me then [17:48:49] <elenril> heh [17:48:53] <elenril> that's cheating [17:49:21] <_av500_> kshishkov: btw, did you vote for the right guy? [17:49:24] <elenril> btw election over yet? [17:49:30] <_av500_> elenril: I think so [17:49:35] <kshishkov> it is [17:49:41] <_av500_> now they haggle over how much it was tweaked [17:50:04] <elenril> what a surprise [17:50:11] <kshishkov> _av500_: between two evils 'tis not worth to choose [17:50:48] <kshishkov> so I didn't [17:52:43] * elenril wonders why would anybody want to be a president of ua [17:52:52] <elenril> there's still things to steal? [17:53:05] <kshishkov> yes [17:53:10] <kshishkov> land [18:03:48] * pJok has a suggestion for ffmpeg... [18:04:00] <pJok> adopt a codec [18:05:06] <_av500_> theora! [18:05:09] * _av500_ hides [18:05:11] * _av500_ hides deeper [18:06:13] * mru digs [18:06:27] <elenril> we already have snow [18:06:29] <BBB> you're dead meat dude [18:06:57] <_av500_> I survived 2 days next to mru, should do fine [18:07:02] <_av500_> (days, not nights!) [18:07:23] <kshishkov> _av500_: I survived with him around almost up to midnight [18:08:04] <_av500_> and at midnight he ran away, leaving a shoe? [18:08:41] <kshishkov> nah, it was me lurching away actually [18:29:41] <kierank> What could the "29DF" mean in this timecode: http://dl.dropbox.com/u/2701213/Dolby%20E/timecode.png [18:30:35] <kshishkov> the same in hex? [18:31:22] <kshishkov> you know, like in AC3 [18:31:54] <kierank> didn't know ac3 had builtin timecodes [18:32:25] <kshishkov> there is - two 14-bit timecodes for date and time [18:32:34] <kshishkov> summon jruggles for details ;) [18:33:09] <kierank> there's supposedly full 80-bit timecodes in dolby e but they seem to have mungified it somehow [18:34:19] <kshishkov> IIRC, in AC3 there are special bits to tell what parts of timecode are present [18:42:05] <kierank> ah the DF means "drop frame" [18:49:02] <CIA-17> ffmpeg: rbultje * r21692 /trunk/libavformat/ (os_support.c network.h): [18:49:02] <CIA-17> ffmpeg: Implement gai_strerror() for systems lacking such functionality. Patch [18:49:02] <CIA-17> ffmpeg: by KO Myung-Hung <komh challion net>. [18:49:51] <BBB> oops, misspelled name - fixed [18:50:45] <kshishkov> bad knowledge of Korean? [18:54:40] <Dark_Shikari> just yell "zerg rush" really loudly while covering your eyes [18:54:43] <Dark_Shikari> you'll pass for a korean just fine [18:54:59] <kshishkov> ke ke ke [19:13:44] <BBB> j-b: ping [19:13:54] <BBB> oh shit [19:13:57] <BBB> j-b_Venice, ping [19:21:58] <kshishkov> BBB: in your mail you have not explained why you still accept marriage proposals [19:36:33] <mru> kshishkov: http://imagebin.ca/view/x6Tdu5C.html [19:38:17] <kshishkov> mru: send a sixpack to RAD Software [19:38:24] <BBB> what is the svnroot of ffmpeg.org? [19:38:31] <_av500_> mru: it is clear where your emphasis was in this shot... [19:38:37] <BBB> kshishkov, in some cultures it's ok to marry multiple times [19:38:39] <BBB> even at the same time [19:39:37] <kshishkov> BBB: yes, but usually it boils to whether your wives don't mind [19:39:47] <_av500_> they have a say? [19:40:03] <mru> not in those cultures [19:40:23] <BBB> I was about to say [19:40:30] <kierank> you have to treat them equally iirc [19:40:51] <kshishkov> swell, more wives = more mothers-in-law [19:40:52] <BBB> the wives, respectively to each other, yes [19:40:59] <BBB> however, that's only on paper [19:41:19] <BBB> I can always claim that in my world, a valentine's dinner has the same value as a slap in the face [19:41:20] <BBB> or so [19:41:40] <BBB> I still need the svnroot for ffmpeg.org [19:41:41] <BBB> :) [19:41:53] <BBB> oh, it's ffmpeg.org [19:41:54] <BBB> d'oh [19:42:04] <kshishkov> svn.ffmpeg.org/ffmpeg.org/trunk or something [19:44:59] <BBB> yes, thanks [20:03:24] <BBB> how do I update the website? [20:03:34] <BBB> am I supposed to upload something somewhere? [20:03:48] <kshishkov> no, commit is enough [20:26:27] <CIA-17> ffmpeg: reimar * r21693 /trunk/libavformat/oggdec.c: [20:26:27] <CIA-17> ffmpeg: Make sure the header value used to avoid repeating headers on seeking to the [20:26:27] <CIA-17> ffmpeg: start and to avoid initializing codecs with missing headers is set for all streams. [20:26:27] <CIA-17> ffmpeg: Fixes issue 1723. [21:23:21] <KotH> grüezi [21:23:26] <KotH> elenril: ask mru [21:23:33] <KotH> elenril: and i wasnt in hell, but it was nearly as cold [21:24:01] <elenril> hey BofH [21:24:07] <elenril> colder than in chocolateland? [21:24:38] <mru> ask me about what? [21:25:31] <elenril> git mirror for nut [21:26:33] <mru> someone working on nut?!?!? [21:27:38] <KotH> http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2010/02/07#stt_gnu_ifunc [21:27:50] <KotH> mru: must be nuts [21:28:37] * elenril tries to hack nut sometimes for the lulz [21:37:31] * elenril rotfls@FFmpeg/libavcodec H.264 output inferiorto QuickTime thread [21:41:03] <mru> where? [21:41:04] <mru> user? [21:41:21] <elenril> http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2010-February/024043.html [21:45:42] <BBB> I don't see the difference (?) [21:45:50] <BBB> QT is just darker [21:46:02] <BBB> I don't see a clear decrease in quality [21:46:07] <mru> they look different [21:46:14] <mru> but it's hard to call one or the other better [21:46:25] <astrange> probably ffmpeg is using the sd colorspace [21:46:48] <astrange> qt assumes hd if the input is large enough, and i think it does some kind of unhelpful gamma conversion [22:10:22] <BBB> the delta shows that in his example (http://tomvision.blogspot.com/2010/01/i-think-i-found-flaw-in.html the tire), the only real difference that cannot be attributed to rounding is the region just above the tire [22:10:30] <BBB> this is more nisy in qt than in lavc [22:10:33] <BBB> noisy* [22:10:48] <BBB> this explains the lesser compressibility in qt than in avc [22:10:53] <BBB> other than that, the two are identicl [22:13:25] <kierank> what resolution was that beagleboard videowall? [22:18:09] <mru> the monitors are 1280x1024 [22:18:29] <mru> the videos were 1920x800 scaled up to the full size [22:20:41] <saratoga> how does one build fft-test in ffmpeg? i can't seem to find a makefile for it [22:22:20] <mru> make libavcodec/fft-test [22:23:48] <saratoga> do I need to have already built ffmpeg in the same directory? [22:23:58] <DonDiego> just try the command [22:24:08] <saratoga> i have and it does not work, hence the question ;) [22:24:25] <DonDiego> your ffmpeg tree needs to be configured [22:24:39] <saratoga> it is [22:24:53] <DonDiego> then it should work [22:25:54] <mru> works here [22:28:29] <saratoga> trying a new folder fixed it, probably just some makefile weirdness on my system [22:33:53] <saratoga> do I need to do make bin or make install to actually get the binary? [22:34:57] <mru> of course not [22:35:01] <saratoga> ah nevermind it ends up in libavcodec not the build dir [22:35:44] <mru> where else? [22:36:10] <mru> the target you give make is typically a filename [22:40:31] <saratoga> my usual project has a policy against doing builds in the source tree, so i wasn't expecting that [22:41:15] <mru> so don't do it there [22:41:40] <mru> if you run make in the source tree you get output in the source tree [22:41:50] <mru> run configure and make elsewhere, output goes elsewhere

1 0