Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2011

1 participants
28 discussions

IRC log for 2011-02-07
by irc＠mansr.com 08 Feb '11

08 Feb '11

[02:29:46] <wooster> U know wat I fink ur d ugliest gurl in d world n YEEEESSSSSS I went dere [02:49:11] <pynchon> .---------------------------------------. [02:49:11] <pynchon> | LIVE paz CAM Thu Oct 28 20:39 | [02:49:11] <pynchon> | ____ | [02:49:11] <pynchon> | ___________//__\\__________ | [02:49:11] <pynchon> | /___________________________\ | [03:08:15] <BBB> thanks Dark_Shikari [05:27:13] <ohsix> elenril: re concatenating files, sqlite has a build option for that, and it goes farther than just sticking them all together too :D it's neat [05:39:21] <drv> poor man's lto [05:39:47] <spoinks> knocks a huge amount off the binary though [06:01:14] <peloverde__> don't you have to worry about symbol collision and whatnot? [06:01:51] <ohsix> drv: it's for just throwing it in as-is into projects [06:02:10] <ohsix> theres not much to gain for the exercise beyond that, at least with sqlite [06:02:19] <cartman> moin [06:02:30] <ohsix> all the config options play out into generating the composite [06:03:56] <Sean_McG> /j #gcc [06:03:59] <Sean_McG> ewps [06:53:32] <spoinks> Sean_McG: haha jew [06:54:22] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:54:29] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:54:36] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:54:41] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:54:48] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:54:55] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:55:05] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:55:10] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:55:17] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:55:25] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:55:34] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:55:42] <spoinks> 死̓ͣ͒ͮ̃̏͋̽̈͂̋͛̀̓̽҉̷̢͇̰̟̬͔̺̺͓̘͔͎͙̙͚̟̰͠͞ͅ亡̷̛̹̼̠͇̹̫̜̰͍͉̙̩̪̗ͪ͂̅͑̌͞對̵̭̙͖͎̲̗̺̣͉̹̤̗̹̭̝̩̫̥̒ͨ͐̐͒ͬ̌ͬ̆̒̋͌̄ͅ黑̩̰̰̜͎̇̽ͨ͒͌͌͜͢͜͝͝人̸̢͖͚̘̝̙̙̮̦͓͖̺̝͕͚̟͔͙̩̍ͮ̓̓ͪͩ͛̔̎ͫ̈́ͧͣ̑̈́́̀̚̕ͅ講̛͇͔͓̩̳͇̳̙͇͚̲͗͗̌ͮ̓̓͗́̆ͥ̄̈́͆ͦ̒ͬ͡話͇̣͚̗̬̦̺͖̳̟͎̘͚̗̬̦̺͖̳̟͎̘͚̗͌ͬͨͤ̀ͭͬ͜͡ [06:55:43] <Sean_McG> what the... [06:55:45] <saintdev> wtf [06:55:46] <Dark_Shikari> bot [06:55:54] <Dark_Shikari> abusing unicode usernames [06:56:02] <Sean_McG> what an asshat [06:56:20] <elenril> wtf is with the troll invasion [06:56:34] <saintdev> failnode at it's bestest? [06:57:30] <Sean_McG> has the nerve to call me a jew, I'll have you know I'm agnostic [06:57:52] <cartman> lol [07:01:24] <elenril> wtf, they want money for the iso-8859-1 specs? [07:02:41] <pJok> elenril, it's iso, they want money for every iso standard [07:03:07] <Sean_McG> indeedly doodly [07:04:16] <peloverde__> A few like 14496-12 are free [07:04:53] <elenril> what happened to free and open standards [07:05:09] <Sean_McG> maybe in another universe [07:10:21] <Tjoppen> google with filetype:pdf ? [07:11:06] <Tjoppen> works quite well, except when google still returns paywalls [07:11:45] <Sean_McG> yeah, expert exchange can just fucking die [07:32:19] <benoit-> good morning [07:51:28] <Anssi> hmm.. are applications that hand data directly to lavf (i.e. lavf doesn't open files itself) expected to register a private URLProtocol, or should allocating a ByteIOContext suffice? [07:52:40] <Anssi> and if the latter, why isn't ff_probe_input_buffer() public? [07:57:55] <astrange> BBB: i see no reason not to commit the mt patches [07:59:58] <saintdev> omgomgomgzomg! [08:11:42] <wbs> Anssi: hmmm, for input files, it might be tricky to get the probing to use the custom ByteIOContext - I guess patches are welcome [08:11:56] <wbs> Anssi: I've used custom ByteIOContexts for output from muxers mainly [08:12:55] <elenril> which reminds me -- what should we do with ByteIOContext in the grand avio rename [08:13:51] <elenril> is it even public? [08:14:23] <wbs> yes, it's public and it's a common way of getting the output from lavf piped into what you want in memory [08:15:39] <elenril> i guess it changes into AVByteIOContext then [08:16:03] <elenril> or maybe just AVIOContext [08:16:05] <Anssi> wbs: yep, currently in xbmc we handle it by doing more manual work (e.g. calling av_probe_input_format2), but ff_probe_input_buffer() seems nice if we could use that, plus the ff_rewind_with_probe_data() trick it does nicely avoids a seek [08:16:28] * elenril paints avio purple with black dots [08:17:00] <wbs> Anssi: ah. I'm not all that familiar with the input probing functions, but I do think a better solution is welcome :-) [08:18:29] <Anssi> wbs: I'll post a patch on ffmpeg-devel@ then to see if there is opposition, thanks [09:11:42] <KotH> salut [09:13:11] <spaam> Heeey KotH [09:14:04] <av500> bonjour [09:20:47] <thresh> morning [09:20:53] <thresh> fun stuff: http://lists.debian.org/debian-devel/2011/02/msg00125.html [09:21:20] <wbs> haha [09:21:48] <cartman> man :) [09:21:56] <cartman> wbs: finally got jni hooked up :P [09:22:07] <wbs> cartman: congrats ;P [09:22:11] <wbs> cartman: that wasn't so hard, was it? [09:22:22] <cartman> wbs: it required me to actually code and read some docs [09:22:33] <wbs> cartman: aww, poor you :-) [09:22:40] <cartman> yeah yeah ;P [09:23:40] <av500> cartman: I feel your pain [09:24:22] <cartman> I am in the middle of a job transition, tough to do something useful :p [09:35:19] <av500> merbzt: please pm me the name of the E guy [09:36:30] <mmu_man> plop [09:36:35] <mmu_man> back from FOSDEM, finally [09:36:49] <mru> finally? was it that bad? [09:37:25] <mmu_man> yeah the Thalys yesterday was 15min late, missed the connection [09:37:30] <mmu_man> had to sleep in paris [09:37:40] <mmu_man> arrived an hour ago [09:37:45] <mmu_man> 14h trip :) [09:37:58] <mru> where do you live? [09:38:14] <mmu_man> valence [09:38:58] <mmu_man> http://osm.org/go/xV9_n0D1C- [09:52:36] <pross-au> kshishkov: awake? [09:52:51] <mru> xxxxxaaaan! [09:56:44] <kshishkov> pross-au: yep [09:57:25] <kshishkov> mru: wrong universe. That codec is from Xan Vader world, not Wrath of Xan [09:58:01] <elenril> what are you talking about, Xan is a necromancer from Baldur's Gate [09:58:43] <av500> what does "Too many buffered pts" mean in mplayer? [09:59:16] <mru> probably that the mplayer variant guess_pt() fucked up [09:59:20] <kshishkov> that it lost sync [09:59:22] <mru> +s [09:59:33] <av500> kshishkov: as in decoder too slow? [09:59:53] <spaam> pross-au: working on bink-b? :) [10:00:09] <kshishkov> av500: or it demuxes audio/vieo wrong - happended couple of times when playing .flv with -nosound to me [10:00:35] <av500> kshishkov: in this case, trying to play 720p on a beagle.... [10:00:43] <pross-au> spaam: done, mate [10:00:54] <spaam> pross-au: gj! :D [10:00:55] <pross-au> applying polish [10:01:28] <spaam> time to drink some trocadero? :) [10:01:29] <kshishkov> you mean shearing wool from it? [10:01:58] <kshishkov> spaam: jag, jag vill gärna [10:02:08] <kshishkov> *ja [10:02:52] <pross-au> trocadero? [10:03:09] <kshishkov> pross-au: mythical Swedish stuff [10:04:07] <spaam> pross-au: for row in spamReader: [10:04:08] <spaam> ops [10:04:12] <spaam> http://upload.wikimedia.org/wikipedia/commons/3/35/Trocadero.jpg [10:04:18] <pross-au> Is it fizzy and bubbly? [10:04:55] <Tjoppen> orange + apple, fizzy and slightly caffeinated [10:05:18] <pross-au> all my favourites drinks combined in one [10:05:43] <kshishkov> spaam: I have only http://upload.wikimedia.org/wikipedia/commons/a/a3/Trocadero_karameller.JPG [10:05:48] <Tjoppen> portello is also nice [10:06:00] <kshishkov> even Pommac is fine [10:06:04] <Tjoppen> more malty [10:06:13] <Tjoppen> and champis of course [10:06:29] <spaam> mm :) [10:13:27] <kshishkov> pross-au: Bink-i for example [10:14:42] <pross-au> i am only a peon kshishkov [10:15:32] <kshishkov> at least they've upgraded RAD video tools from 1.9z to 1.99a a month ago [10:15:49] <kshishkov> maybe we'll get BIKj to RE eventually [10:16:08] <kshishkov> so finish polishing BIKb decoder please :) [10:16:26] <pross-au> Wilco [10:16:55] * kshishkov knows it's military slang but remembers Space Quest series nevertheless [10:31:17] <elenril> mru: i wonder if using clang's __has_attribute is a good idea [10:31:59] * kshishkov wonder why mru has missed FOSDEM presentation where they talked about Clang for Minix [10:34:46] <_av500_> Clinix? [10:34:56] <_av500_> or Minilang [10:37:26] <kshishkov> also they talked about Clang almost ready for BSD [10:37:37] <kshishkov> x86[_64] [10:42:13] <pross-au> Mlang [10:45:23] <saste> Flameeyes: how can I see the branches in your flameeyes repo? [10:45:35] <saste> Flameeyes: git branch shows only "master" [10:45:42] <wbs> saste: git branch -r [10:46:06] <saste> wbs: thanks [11:00:47] <kshishkov> hmm, a new Opus draft [11:00:59] <kshishkov> http://www.ietf.org/id/draft-ietf-codec-opus-02.txt [11:07:13] <spaam> kshishkov: Do we have a decoder for it? [11:07:21] <kshishkov> nope [11:07:40] <kshishkov> and neither for its base (CELT and SILK) [11:07:56] <spaam> what are you waiting for? :) [11:08:06] <kshishkov> flying pigs, of course [11:09:12] <elenril> not for binkb? [11:09:19] <kshishkov> that too [11:09:33] <kshishkov> but since Peter claims it's almost ready... [11:31:06] <Tjoppen> I suspect large parts of it can be implemented. they seem to be mostly fine tuning parameters [11:34:20] <spaam> Tjoppen: do you mean that DonDiego can do it? [11:36:44] <kshishkov> spaam: when you mentioned that even his connection shuddered [11:37:22] <spaam> mm =/ [11:38:17] <Tjoppen> I did sort of read the spec rapidly. I was mostly interested in the PVQ stuff for other purposes [11:39:58] <DonDiego> you were saying? [11:40:28] <_av500_> DonDiego: you still want that laptop? [11:40:43] <kshishkov> DonDiego: you can finetune our Opus encoder [11:40:52] <kshishkov> _av500_: advertised by you? [11:43:29] <av500> DonDiego: http://www.flickr.com/photos/av500/5424891272/ [11:48:04] <Tjoppen> holy base64 encoded source code tarball in the opus spec batman! [11:48:13] <cartman> av500: supersonic as in the noise it makes [11:48:19] <av500> cartman: u bet! [11:48:31] <cartman> looks exactly like my first supersonic laptop [11:48:45] <av500> cartman: yeah, got it from ebay.tr [11:48:54] <av500> nice pics [11:48:56] <cartman> av500: :) [11:49:15] <av500> i guess the encrypted emails are from your pkk buds? [11:49:20] <kshishkov> av500: may I interest you in GuruPlug - ARM device with fan? [11:49:37] <cartman> av500: stop hating me [11:49:48] * av500 stops hating cartman [11:50:10] <kshishkov> av500: and why have you got Efika-MX? you are in love with TI [11:50:29] <av500> kshishkov: lu_zero forced it on me [11:50:41] <kshishkov> ah, not surprising then [11:51:17] <av500> and "in love" is the wrong word [11:51:28] <av500> its more like a hate hate relationship [11:52:42] <cartman> av500: http://www.flickr.com/photos/av500/5112199042/ is that mru on your right? [11:52:49] <kshishkov> isn't there a saying "if he shouts at you it means he loves you"? [11:53:31] <_av500_> cartman: read the comments [11:53:38] <_av500_> but yes [11:53:53] <cartman> _av500_: he is never happy [11:54:17] <av500> cartman: because ppl always break his fate [11:54:43] <cartman> http://llvm.org/bugs/show_bug.cgi?id=9123 not my fault [11:55:55] <av500> so easy to always blame others.... [11:55:58] <av500> :) [11:58:17] <cartman> av500: I bisected pffft [12:06:18] <elenril> anyone against renaming ByteIOContext into just AVIOContext? [12:06:26] <av500> go for it [12:07:16] <kshishkov> elenril: but how can we distinguish it from WordIOContext and DwordIOContext? Oh, we don't have such, go for it. [12:07:37] <av500> elenril: unless it is core functionality! [12:07:42] <pross-au> Why AV? [12:07:49] <elenril> what else [12:07:52] <kshishkov> pross-au: for libav* of course [12:08:18] <elenril> everything that belongs to public api should be av-prefixed [12:08:45] <cartman> pross-au: because they are into Japanese pr0n [12:09:14] <kshishkov> cartman: only if its subtitles have metadata [12:13:18] <pross-au> makes sense. is this proposed for ffmpeg >= 0.7 [12:16:44] * cartman notes that this tablet uses gstreamer [12:16:52] <cartman> and it seems to have OMX support hmmhmmm [12:17:22] <astrange> WordIOContext sounds like a reimplementation of icu text boundaries [12:17:52] <av500> cartman: which one? [12:18:28] <cartman> av500: some Marvell 7'' tablet from USA [12:22:41] <kshishkov> hmm, is it Moby tablet (based on Armada 6xx)? [12:24:04] <cartman> No name, engineering sample [12:24:32] * kshishkov looks at Marvell Armada 610 and 618 product brief, sees WMMX2 block next to VFP3.0, erases Marvell from his memory [12:25:12] <cartman> Processor : Marvell Mohawk rev 0 (v5l) [12:25:12] <cartman> BogoMIPS : 796.26 [12:25:14] <cartman> ARMv5 [12:25:34] <kshishkov> yuck, that's coprolith [13:32:25] <av500> lu_zero: ping [13:39:08] <cartman> awesomeness [13:39:14] * cartman pokes himself [14:03:06] <elenril> :/ [14:03:13] <elenril> srsly, WHERE ARE ALL THE ML ADINS [14:03:24] <elenril> admins even [14:03:25] <Dark_Shikari> failing [14:03:26] <av500> would the real admins please stand up? [14:03:27] <Dark_Shikari> at life [14:03:40] <Dark_Shikari> this is what happens when the "leadership team" is a bunch of incompetent fucks who just want someone else to do the job for them [14:03:49] <kshishkov> elenril: they are mostly French [14:03:50] <Dark_Shikari> (note: it was like this before, too) [14:04:17] <kshishkov> Dark_Shikari: nobody cared to seize power over ML adminship it seems [14:05:35] <elenril> ffmpeg-devel list run by baptiste.coudurier at gmail.com, benoit.fouet at free.fr, mans at mansr.com << says https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel [14:05:36] <superdump> my guess is that it is because people are travelling back from fosdem [14:05:44] <superdump> well, mans at least [14:06:18] <Dark_Shikari> mru refused to moderate it [14:06:23] <Dark_Shikari> I haven't seen benoit in ages [14:06:24] <superdump> what? [14:06:33] <superdump> benoit- is right here [14:06:36] <Dark_Shikari> oh, he is here. [14:06:38] <Dark_Shikari> I'm blind [14:07:32] <kshishkov> superdump: he appeared ponly few days ago and there's no indication he's done admin work [14:10:26] <benoit-> Dark_Shikari: well, that's OK; I love being ignored anyway :P [14:11:28] <kshishkov> benoit-: is that because most of us don't speak French? [14:11:42] <superdump> what needs moderating anyway? [14:11:45] <benoit-> is that *what* because? [14:11:56] <Dark_Shikari> there are a few trolls on the ML. [14:12:03] * elenril only sees one atm [14:12:04] <mru> Dark_Shikari: when have I refused anything? [14:12:08] <benoit-> superdump: I've begun to re administrate/moderate -devel and -cvslog [14:12:13] <Dark_Shikari> mru: I thought you said that you weren't goin to moderate the ML? [14:12:18] <Dark_Shikari> and that it wasn't your job? [14:12:24] <cartman> mru: when someone is taking a photo of you, smile :p [14:12:33] <Dark_Shikari> Or was that Diego who said that? [14:12:39] <mru> cartman: it helps if I know they're taking it [14:12:44] <benoit-> Dark_Shikari: what do you want to do as far as trolls are concerned ? [14:12:51] <cartman> mru: blame av500 then :P [14:12:53] <Dark_Shikari> benoit-: people who are trolling and who aren't developers should be banned from the list [14:12:55] <benoit-> remove them from the list ? that would be stupid [14:13:02] <Dark_Shikari> er, banned from posting [14:13:08] <kshishkov> Dark_Shikari: and he has not agreed to add mailman rule to filter out mails to ffmpeg-devel containing "leader" or "vote" :( [14:13:09] <mru> Dark_Shikari: I don't feel it's my place to decide who's a troll [14:13:10] <Dark_Shikari> ffmpeg-devel is for developers. [14:13:15] <benoit-> Dark_Shikari: just ignore them [14:13:20] <mru> especially without any written policy [14:13:27] <Dark_Shikari> benoit-: that isn't really a good solution [14:13:32] <Dark_Shikari> a) people don't ignore them, they get bites [14:13:36] <benoit-> mru: I agree it's not our role [14:13:47] <Dark_Shikari> b) they make everything worse [14:13:51] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r47fdf00a77 ffmpeg/libavformat/avidec.c: [14:13:51] <CIA-38> ffmpeg: avidec: simplify read_gab2_sub [14:13:51] <CIA-38> ffmpeg: Use avio functions instead of bytestream ones (also drops dependency on [14:13:51] <CIA-38> ffmpeg: lavc and removes a bunch of warnings). [14:13:51] <CIA-38> ffmpeg: Drop custom version of avio_get_str16 and use that instead. [14:13:52] <CIA-38> ffmpeg: Tested on mewmew-ssa.avi sample. [14:13:52] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [14:13:54] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r69ff149204 ffmpeg/libavformat/oggparseskeleton.c: [14:13:54] <CIA-38> ffmpeg: Fix compile warning. [14:13:54] <CIA-38> ffmpeg: Change int64_t into a int, which caused this compiler warning: [14:13:55] <CIA-38> ffmpeg: libavformat/oggparseskeleton.c:64: warning: passing argument 2 of ‘av_reduce’ from incompatible pointer type [14:13:55] <CIA-38> ffmpeg: Kostya Shishkov <kostya.shishkov(a)gmail.com> master * r44ddfd47d6 ffmpeg/ (6 files in 3 dirs): [14:13:56] <CIA-38> ffmpeg: Xan4 decoder [14:13:56] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [14:14:00] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * r95ec3d4cac ffmpeg/libavformat/matroskadec.c: (log message trimmed) [14:14:00] <CIA-38> ffmpeg: matroskadec: add generic element length validation. [14:14:00] <CIA-38> ffmpeg: This validate the length of a mkv element directly after reading [14:14:00] <CIA-38> ffmpeg: it. [14:14:01] <CIA-38> ffmpeg: This has the advantage that it is easy to add new limits and makes [14:14:04] <Dark_Shikari> so you're saying that you won't ban anyone from the ML for any reason? [14:14:09] <Dark_Shikari> great. what a useful moderator. [14:14:12] <benoit-> "someone" pushed his tree :) [14:14:28] <benoit-> Dark_Shikari: that's not the only part of moderation [14:14:29] * Dark_Shikari facepalms at the current roots. [14:14:44] <benoit-> Dark_Shikari: I won't do that if I were you though... :) [14:14:52] <BBB> benoit-: that would be me (the tree-pusher) [14:14:55] <Dark_Shikari> do what? [14:15:10] <benoit-> yes, there could be reason to ban, but trolling the way it is today is not *that* bad [14:15:25] <benoit-> there have been worse times anyway [14:15:35] <ubitux> please guys, ban Gabor from posting on ffmpeg-devel, he is really annoying… [14:15:49] <Dark_Shikari> ubitux: they don't believe in moderation [14:15:51] <Dark_Shikari> sorry [14:15:58] <Dark_Shikari> if you want to have a useful list for discussing such topics, make your own [14:16:02] <Dark_Shikari> ffmpeg-devel is for trolls only [14:16:03] <mru> ok, since so many of you are asking for it, I'll do it [14:16:15] <Dark_Shikari> note: I'm also fine with "moderating every post" of a particular person [14:16:20] <Dark_Shikari> but that puts a lot of extra demand on the moderator [14:16:26] <Dark_Shikari> and is useless if the moderator doesn't get to the queue often [14:16:32] <BBB> please ban or moderate gabor, +1 [14:16:39] <merbzt> I consider his posts as disruption of services [14:16:43] <BBB> I'm so sick of these .hu trolls - never any patches and always the last word [14:16:47] <Dark_Shikari> so we have... 5 votes so far? [14:16:51] <Dark_Shikari> =p [14:16:52] <BBB> ban him [14:16:56] <merbzt> so I'm in favor of unsubscribing him [14:16:59] <ubitux> he hasn't made a single useful commit, and afaik he isn't a ffmpeg developer [14:17:01] <mru> gabu is now on forced moderation [14:17:04] <Dark_Shikari> \o/ [14:17:06] <elenril> \o/ [14:17:08] <BBB> mru: thank you [14:17:10] <Dark_Shikari> see that was easy [14:17:12] <ubitux> thank you too. [14:17:12] <cartman> wtf is ubifs [14:17:20] <av500> cartman: a flash fs [14:17:25] <mru> cartman: ubifs is a filesystem for raw flash devices [14:17:25] <kshishkov> BBB: there's Alex who actually contributed (and not seen lately) [14:17:26] <benoit-> Dark_Shikari: nobody said that was hard [14:17:34] <cartman> av500, mru ah [14:17:34] <BBB> kshishkov: I didn't ask to ban him [14:17:35] <BBB> kshishkov: :-p [14:17:37] <mru> cartman: some say it's better and less buggy than yaffs2 [14:17:42] <av500> it is [14:17:50] <cartman> mru: is it read only? Can't seem to remount rw. [14:17:56] <mru> it is rw [14:18:04] <twnqx> http://pastebin.com/7qLfJVFr does any of you have an idea what this could be? [14:18:04] <av500> cartman: kernel might prevent that [14:18:07] <cartman> okies [14:18:11] <kshishkov> BBB: so there is one sane Hungarian MPlayer dev [14:18:12] <cartman> av500: probably :/ [14:18:29] <merbzt> we should add disruption of services and personal insults as reasons for unsubscription/moderation [14:18:32] <Dark_Shikari> kshishkov: which one? [14:18:40] <kshishkov> Dark_Shikari: Alex [14:18:43] <Dark_Shikari> which alex? [14:18:46] <Dark_Shikari> there are so many alexes [14:18:53] <kshishkov> Hungarian Alex [14:19:08] <mru> the only sane hungarian [14:19:11] <Dark_Shikari> Converse? [14:19:18] <Dark_Shikari> Oh [14:19:19] <av500> hungarian [14:19:27] <Dark_Shikari> Kojevnikov? [14:19:29] <av500> not hungry american [14:19:30] <kshishkov> Beregszasi [14:19:36] <mru> al3x on irc [14:19:44] <Dark_Shikari> his last commit was 2007... [14:19:46] <cartman> QDM Alex [14:19:51] <cartman> ;) [14:21:16] <kshishkov> Dark_Shikari: but he wrote your favourite TTA decoder [14:21:25] <jannau> Is someone going to post to the ml that gabu is on moderation? I think we should even if it's an invite for a troll fest [14:21:32] <jannau> I'll do it [14:22:03] <cartman> jannau: uhm no need to fire the flames [14:22:05] <Dark_Shikari> kshishkov: lol TTA [14:22:10] <Dark_Shikari> jannau: no, don't [14:22:18] <Dark_Shikari> moderation should be rare and silent. [14:22:21] <kshishkov> Dark_Shikari: APE then [14:23:38] <jannau> Dark_Shikari: I understand that but we should at least aanounce that we aren't willing to accept personal insults and disruptive trolling on the mailing lists [14:24:00] <cartman> <2>[13925.430053] UBIFS assert failed in dbg_dump_budg at 613 (pid 2661) [14:24:05] <cartman> stable, lulz [14:25:37] <Dark_Shikari> jannau: maybe. that should be obvious though. [14:25:44] <Dark_Shikari> .... though it might not be, given that it took so long [14:26:24] <spaam> cartman: did you fix that clang bug? [14:26:51] <cartman> spaam: pinpointed the revision, waiting for a response [14:27:00] <cartman> reduced the testcase too [14:27:38] <spaam> cartman: i saw that.. but have _you_ fixed that bug yet? [14:28:08] <cartman> spaam: do I look like a compiler guy from there? [14:28:24] <CIA-38> ffmpeg: Jindrich Makovicka <makovick(a)gmail.com> master * r5bea615dc3 ffmpeg/libavcodec/dvbsubdec.c: (log message trimmed) [14:28:24] <CIA-38> ffmpeg: dvbsubdec: pass correct input buffer size [14:28:24] <CIA-38> ffmpeg: In some places, dvbsubdec passes improper input buffer size to [14:28:24] <CIA-38> ffmpeg: bitstream reading functions, not accounting for reading pointer [14:28:24] <CIA-38> ffmpeg: updates. [14:28:24] <CIA-38> ffmpeg: Fixed by using buffer_end - buffer pointer instead of fixed buffer length. [14:28:25] <CIA-38> ffmpeg: Signed-off-by: Jindrich Makovicka <makovick(a)gmail.com> [14:28:49] <spaam> cartman: yes.. more then mru does, when he talks about stuff like that :) [14:29:05] <cartman> spaam: I just like clang :P [14:29:40] <spaam> cartman: time to learn how to fix things in it :D [14:30:28] <cartman> spaam: I did fix an asm bug :P [14:31:02] <spaam> Nice :) [14:31:37] <elenril> meh, now i have to recompile everything [14:31:39] * elenril blames kshishkov [14:32:14] <elenril> so...where are all the people who wanted to remove half of avcodeccontext [14:32:30] <cartman> Did you do security audit in new codec code or are you waiting for independent security people? :) [14:33:17] <cartman> http://www.pocket-lint.com/news/38311/android-2-4-april-release-date [14:33:18] <cartman> nice [14:34:22] <Dark_Shikari> elenril: hi [14:35:28] <elenril> Dark_Shikari: stop procrastinating and start deprecating stuff =p [14:36:23] <siretart> FYI: I have a patch that merges avcore into libavutil on my laptop now [14:36:42] <siretart> I'm running some additional tests to make sure it doesn't break anything, but so far it looks promising [14:36:45] <spaam> elenril: poor thing.. when will you learn how to answer an e-mail? ;P [14:37:01] * elenril stabs spaam [14:37:27] <spaam> noo : ( [14:40:16] <kshishkov> spaam: just grow some flesh and his stabs won't relly hurt you [14:40:29] <kshishkov> spaam: or at least use av500 as shield [14:41:57] <cartman> siretart: step 0. l [14:42:07] <cartman> siretart: step 0. kill the one who proposed libavcore split [14:42:21] * siretart is a pacifist [14:42:41] <siretart> but I take that as agreement to the proposed merge [14:42:58] <siretart> hm. boarding in 8 minutes. I guess I should leave now [14:43:01] <siretart> see you later! [14:43:11] <cartman> av500: are you building 2.4 images yet? [14:43:12] <kshishkov> hej då [14:43:16] <wbs> mru, or any other with push access to the repo: care to commit the approved movie source filter that stefano has worked on for ages? it was approved by michael sometime last week [14:43:35] <kshishkov> wbs: there was that BBB guy pushing stuff [14:43:44] <wbs> if he had some libavfilter-subsystem-repo, that one would be on the "please merge to master"-list [14:44:02] <kshishkov> maybe we'll have it [14:44:12] <spaam> kshishkov: hej då :) [14:44:38] <Compn> Dark_Shikari : if people are biting trolls, you should mail them and tell them to stop biting [14:44:55] <mru> or pull their teeth out [14:45:01] <kshishkov> spaam: skicka hundra Trocadero flaskor till mig, är du snall? [14:45:25] * Compn thinks its strange that Dark_Shikari lives in one of the only free-speech countries in the world and yet wants to ban people for speaking... [14:45:44] <cartman> Compn: thats not surprising [14:45:52] <mru> it's not a free-trolling country [14:46:02] <ohsix> ++ [14:46:03] <cartman> neither free tolling one [14:46:03] <Dark_Shikari> Compn: it's a private mailing list [14:46:06] <Compn> yes it is :P [14:46:08] <Dark_Shikari> there is no free speech in a private list [14:46:16] <cartman> uh oh :) [14:46:31] <mru> nobody suggested shutting down his blog [14:46:33] <Compn> yes thats a dumb argument tho [14:46:47] <mru> if he wants to troll, he can do it there [14:47:12] <Compn> hes not being off-topic, which i could see being a bannable offense :P [14:47:12] <mru> disruptive behaviour gets you thrown out of many places [14:47:25] <Dark_Shikari> ffmpeg-devel is for development [14:47:26] <Dark_Shikari> he isn't developing [14:47:29] <Dark_Shikari> therefore, he gets kicked [14:47:29] <Dark_Shikari> end of story [14:47:49] <Dark_Shikari> moreso: he isn't developing, isn't planning on developing, and never did develop. [14:48:09] <jannau> Compn: he called me a racist [14:48:16] <Compn> lol [14:48:23] <Dark_Shikari> lol [14:48:24] <Compn> jannau : then you got trolled [14:48:29] <cartman> kids [14:48:30] <Dark_Shikari> You're not a racist [14:48:30] <mru> afaik there is no hungarian race [14:48:32] <Dark_Shikari> YOU'RE A NAZI [14:48:36] <Dark_Shikari> EVIL NAZIS [14:48:49] <Dark_Shikari> mru: People who confuse "race" and "nationality" are pretty funny. [14:48:51] <av500> Compn: so this is on topic: ""We're not your nanny", so take your pissing problems elsewhere. Preferably to a urologist." [14:48:55] <Compn> the project needs people who arent devels you know. (i'm not saying it needs trolls, but to ignore non-developers is an insult really) [14:49:11] <Dark_Shikari> testing is developing [14:49:13] <Dark_Shikari> reporting bugs is developing [14:49:22] <Dark_Shikari> just because it isn't writing code doesn't make it not development [14:49:29] <Compn> gabu used to run the site ... [14:49:38] <mru> no [14:49:43] <mru> that was mplayer [14:49:58] <kshishkov> av500: that's genderism [14:50:02] <Compn> did ffmpeg use mplayer's incoming dir ? [14:50:05] <Compn> heh [14:50:14] <Compn> nevermind, i can see i'm not getting anywhere [14:50:21] * Compn knows when to quit [14:50:40] <av500> Compn: "the project needs people who arent devels you know" and these ppl are gabu? well, good luck [14:50:58] <Compn> av500 misses the second sentence directly after that sentence [14:51:02] <Compn> well done [14:51:26] <av500> Compn: "(i'm not saying it needs trolls" ? :) [14:51:37] <Compn> yes [14:51:47] <av500> and wrt "ignoring", I dont mind him unless he insults ppl on the ML [14:51:50] <av500> which he does [14:52:07] <Compn> trolls only have power when you give it to them [14:52:22] <av500> Compn: which of his latest utterances do you consider "valuable"? [14:53:09] <Compn> he reported a problem with mphq blocking half of hungary on 1-28-11 [14:53:29] <Compn> On Fri, 28 Jan 2011 09:07:17 +0100, Berczi Gabor wrote: [14:53:33] <av500> i know [14:53:41] <Compn> well i consider that valuable [14:53:47] <av500> "And the FUCK goes right back to you, for banning half of Hungary (amongst others) from accessing mplayerhq." [14:53:47] <Compn> to getting it fixed [14:53:50] <mru> blocking trolls is valuable, yes [14:53:51] <av500> nicely said [14:54:06] <cartman> av500: clear words [14:54:10] <av500> if that was his issue, he could have said that ages ago [14:54:37] <av500> people and countries have been unblocked by asking nicely here on irc [14:54:45] <Compn> i think gabu offered a host for ffmpeg as well, in his mail on 2-4-11 [14:54:55] <jannau> or by sending a mail [14:54:55] <mru> rotfl [14:55:00] <cartman> wbs: I posted a sample, playing video (via Intent) from JNI, now people won't have to ask for it :P [14:55:13] <av500> url? [14:55:20] <cartman> av500: no way showing you :P [14:56:45] <Compn> av500 : are you satisfied with those two valuable mails or no? [14:57:18] <av500> Compn: FUCK YOU, they are of great value! :) [14:57:27] <av500> did I word that OK? [14:57:37] <cartman> must be something nice in Hungarian [14:57:44] <cartman> all caps, all lovin' [14:57:48] <av500> Compn: maybe you see my point? [14:58:34] <Compn> that was in reply to a fuck you from KotH ... and yet no one calls KotH a troll :P [14:58:47] <mru> KotH is not a troll [14:58:49] <cartman> KotH is a beloved Turko [14:58:53] <Compn> hehe [14:58:54] <mru> he's a swiss turk [14:58:56] * Compn trolling now [14:59:06] <kshishkov> mru: says British Swede [14:59:07] <cartman> sounds like a swiss knife [14:59:09] <cartman> must be good [14:59:33] <KotH> Compn: i know that we block a .hu isp.. i banned him myself, after 2 weeks of hunting down this fucking shit head who thought that he can download each and every file on natsuki there is [14:59:39] <av500> Compn: right, Koth came out of hiding on the ML and started insulting people.... [14:59:55] <Compn> KotH : yeah i understand the samples nightmare you deal with. i didnt say it was wrong to ban it [15:00:02] <Compn> and i thank you for doing the admin [15:00:06] <kshishkov> cartman: that's because you've never heard of http://en.wikipedia.org/wiki/Mora_knife [15:00:10] <Compn> i'm just using that example of a bugreport [15:00:22] <av500> kshishkov: in fact, I have :) [15:00:26] <mru> kshishkov: those make nice kid's toys [15:00:36] * mru thought so at least [15:00:50] <mru> av500: do you let your kids play with knives? [15:00:57] <cartman> kshishkov: nice [15:01:05] <kshishkov> mru: with Mora knives precisely [15:01:08] <cartman> kids stab av500 for the fun of it [15:01:24] <kshishkov> cartman: nope, none of them is called elenril [15:01:39] <cartman> av500 should adopt elenril for starters [15:01:41] <cartman> :P [15:02:01] <av500> cartman: want me to say the p word again? [15:02:12] <cartman> av500: point taken! [15:02:15] * cartman shuts up [15:02:26] <KotH> Compn: i dont really get what you are complaining about then [15:02:58] <mru> KotH: Compn is just trolling [15:03:25] * av500 Compnlains about that! [15:03:37] <KotH> mru: i dont consider Compn a troll, so i'm inclined to listen to his complaints [15:04:14] <Compn> KotH : just saying that gabu brought up some valuable comments on the list and it wouldnt be good to ban that [15:04:25] <kshishkov> KotH: that's because you don't implement missing decoders he usually complains about! [15:04:27] <Compn> some even if its only one or two comments [15:04:50] <Compn> kshishkov : you know everyone else bugs you about bink, but i never do :P [15:05:11] <KotH> Compn: ah... [15:05:22] <KotH> Compn: well.. i dont think he contributed in even one point [15:05:55] <av500> he has a nice way of packaging up valuable comments [15:05:55] <KotH> Compn: as i said, i know that certain networks cannot reach natsuki at all. but this is known to us and wanted taht way [15:06:12] <kshishkov> av500: s/valuable/fertilizing/ [15:06:29] <Compn> KotH : yeah, i know . is it possible to just ban those networks from samples repo ? [15:06:43] <KotH> Compn: DonDiego is working on that [15:06:45] <Compn> ah good [15:06:51] <Compn> i think he mentioned that before :) [15:16:05] <mru> av500: http://www.joystiq.com/2011/02/06/video-angry-birds-played-in-real-life/ [15:44:33] <BBB> mru: what's up with your neon vp8 stuff? [15:45:36] <mru> BBB: I was hoping someone might look at it [15:45:49] <mru> I know you had a look, but you said you don't know much neon... [15:57:34] <kshishkov> mru: I said it looked ok and you clarified one point to me [15:58:22] <BBB> mru: I don't think I can say much more than that :) kshishkov, merbanan etc. are better people to look at it in detail than me [15:58:36] <mru> kshishkov: I don't see any replies from you in that thread... [15:58:40] <BBB> does ANYONE in this channel have win64 and can lend me ssh access? [15:58:54] <BBB> win64=mingw64 that can build and run ffmpeg and fate [15:59:06] <BBB> mru: commit http://patches.ffmpeg.org/patch/688/ also ? [16:01:24] <elenril> BBB: didn't you say -mt was ready? [16:01:30] <BBB> it is [16:01:37] <BBB> I said several times that we should commit it [16:01:46] <BBB> I'm waiting for others to actually read the patch [16:01:48] <elenril> why don't you do it then? [16:02:31] <BBB> I'm affraid of .hu trolls coming in and saying I'm unfairly biased in my reviews [16:03:09] <elenril> michaelni could read it instead of flaming [16:03:15] <kierank> BBB: seriously? [16:03:26] <BBB> michaelni was nitpicking on the doxy [16:03:42] <BBB> at least I tried to help fixing fate-under-mt [16:03:56] <BBB> let's do a vote [16:04:01] <BBB> who's inf avour of me applying -mt now? [16:05:19] <elenril> .....*silence*...... [16:05:31] <av500> wasnt votes stupid? [16:05:32] * av500 hides [16:05:56] <elenril> yeah, votes are stupid, just apply it and see if people flame you ;) [16:07:46] <spaam> BBB: how many tests does fail with -mt ? [16:16:17] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * ra1c1d3c003 ffmpeg/libavcodec/ (5 files in 2 dirs): [16:16:17] <CIA-38> ffmpeg: VP8: ARM NEON optimisations for dsp functions [16:16:17] <CIA-38> ffmpeg: This adds NEON optimised versions of all functions in VP8DSPContext. [16:16:17] <CIA-38> ffmpeg: Based on initial work by Rob Clark. [16:16:17] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:16:29] <Orphis> Hi there, I'm wondering, are there any requirements in order to make a fate test computer that reports to the main fate server ? [16:16:43] <av500> yes, you need to set one up [16:17:09] <Orphis> I mean does it have to be online 24h/24 ? [16:17:13] <av500> no [16:17:18] <av500> but it would be nice [16:17:22] <Orphis> Sure ^^ [16:17:28] <av500> since one can spot broken commits faster [16:17:36] <av500> what kind of machine is it? [16:17:41] <Orphis> Win64 :P [16:17:44] <mru> the more often it runs, the better [16:17:51] <mru> \o/ we need that [16:18:07] <Orphis> I know, I've just read Ronald message on the mailing list [16:19:21] <Orphis> I would be my personnal computer that stays on like 24h/24, it could run test during my work hours and night [16:19:26] <Orphis> Better than nothing [16:19:45] <mru> anything is better than nothing [16:20:41] <Orphis> Since I've been following the ML for months without doing anything productive, it would be my way to help [16:21:02] <mru> all ways are welcome [16:22:02] <Orphis> I hoped it would be coding-wise, but I haven't got the time to do anything with all my side projects :-/ [16:23:10] <merbzt> bad Orphis [16:23:24] <Orphis> I know merbzt ! But you won't let me help :p [16:23:28] <merbzt> :) [16:24:38] <Orphis> And I've got plenty of things to do in the emulator, now we've added automatic decryption of games, lots of optimizations on the 3D renderer and have more and more complex games running FASTER [16:25:17] <elenril> what emulator? [16:25:19] <Orphis> And we've discovered bugs^Wfeatures of the CPU we didn't think about [16:25:29] <Orphis> Jpcsp, PSP emulator, sadly written in Java [16:26:13] <Orphis> But we've made the God of War games running at playable speeds just recently [16:26:58] <Orphis> Anyway... [16:27:02] <elenril> nice [16:27:11] <Orphis> mru: Do you have a guide on how to setup a Fate machine ? [16:27:12] <elenril> there's about one psp game i wanted to play [16:27:21] <Orphis> Patapon ? Locoroco ? [16:27:25] <av500> tetris? [16:27:28] <elenril> crisis core [16:27:35] <Orphis> It's been working for months [16:28:05] <elenril> good to hear [16:28:08] <Orphis> We even play the movies with a java ffmpeg binding directly :p [16:28:46] <Orphis> And if you're on Windows, you can have an atrac3+ decoder to play most sounds ingame [16:29:03] * elenril isn't [16:29:04] <BBB> mru: \o/ [16:29:22] <mru> BBB: still 2 to go [16:29:23] <BBB> spaam: none fail, I fixed all that failed [16:29:35] <BBB> spaam: if tests fail, we debug them and fix them, what else are tests for? :) [16:29:48] <BBB> spaam: it's not like h264 decoding or mpeg decoding and MT are incompatible or something [16:31:40] <elenril> but only generic api is to be committed, right? [16:31:58] <elenril> not h264 parts [16:32:16] <BBB> h264 parts is part of that patch [16:32:20] <BBB> also mpeg [16:32:26] <BBB> vp3 is separate I believe [16:32:29] <BBB> check the patch [16:32:32] <elenril> wow, it's better than i thought [16:33:00] <Compn> Orphis : oooo psp emu?? nice. what about lumines ? [16:33:00] <elenril> commit it now and we can write a news entry/slashdot/etc [16:33:03] <BBB> hm not this patch [16:33:14] <BBB> the patch I had, included h264 and mpeg also [16:33:19] <BBB> he didn't merge them into his patch :( [16:33:37] * Compn should just checkout emu's homepage for compat page [16:33:39] <Orphis> Compn: It has been working, although it's not tested regularly and might be broken in latest rev [16:33:47] <Compn> doh [16:33:56] <spaam> BBB: ahh Nice nice :) [16:33:58] * Compn doesnt know psp games [16:33:59] <Orphis> No, the compat page has never been updated, really [16:34:17] <Compn> Orphis : ehe, you need a fate like automatic tester :) [16:34:52] <Orphis> Lumines video in the emulator : http://www.youtube.com/watch?v=0DQOOktmavI [16:35:07] <Orphis> But no way to see what version that was [16:35:22] <BBB> vp3, mimic (?), huffyuv, h264 and h263 (mpeg) [16:35:28] <BBB> but they're all separate patches [16:35:50] <Compn> BBB : probably you need michael to review all that :P [16:36:02] * Compn not paying attention [16:36:04] <BBB> I reviewed it already [16:36:07] <BBB> I also debugged it all [16:36:10] <BBB> it works now :) [16:36:19] <Compn> valgrind and fuzz too? :P [16:36:22] <Compn> or that comes later ? [16:36:44] <Kovensky> 13:25.30 Orphis: Jpcsp, PSP emulator, sadly written in Java <-- "I heard you like emulators so we put an emulator on your emulator..." [16:36:47] <Kovensky> though java isn't exactly emulated, it sorta is since it's JIT compiled [16:36:49] * Compn forgets if we are on a commitnow-valgrindlater or valgrind-fuzz-now--testlater [16:37:17] <Orphis> We even run a NES emulator fine in ours :p [16:37:35] <BBB> astrange: ping - what would you like me to do? I'm fine with the patch, shall I commit? When will you submit the rest (h263/mpeg, h264, stuff-i-dont-use) for review? [16:37:49] <BBB> astrange: also, thanks!!!!!!!! [16:38:40] <Orphis> Hmm, all the doc about setting up a fate machine seems to be in /doc, checking it right now [16:38:55] * Compn still sad that no one bothers to work on dreamcast emulator :P [16:40:35] <Orphis> Compn: There chankast and nulldc :p [16:41:32] <Compn> oh i thought nulldc was dead, now i see it on google code :) [16:41:36] <Orphis> I think the only successful console that haven't been emulated are the xbox, xbox360 and ps3 [16:42:03] <elenril> i've heard pcsx2 doesn't work all that well either [16:42:06] <elenril> (yet) [16:42:18] <Kovensky> the mac port is terrible =p [16:42:37] <Orphis> pcsx2 works well on Windows [16:42:57] <Orphis> And Linux 32 I think [16:43:25] <Kovensky> the mac port uses GTK1 [16:43:30] <Orphis> They have lots of 32bit centric code for performance [16:43:35] <Kovensky> and the only sound plugin available has huge delay [16:44:38] <Orphis> I haven't tested it on my Mac since my other computer is way more powerful [16:44:56] <Compn> ah didnt know the ps2 emu was successful [16:45:02] <Compn> thats coo [16:46:41] * Compn should try out gitaroo man [16:47:27] <Orphis> And the GC/Wii emulator is cool too [16:47:53] <Orphis> Lots of hard workers on it too [16:48:13] * Compn is happy to know emulation is still going strong [16:50:10] <Orphis> It won't be able to emulate the 360 or PS3 properly though [16:51:01] <mru> speed will be a problem, if nothing else [16:52:03] <Orphis> A BIG problem :p [16:53:10] <Orphis> It might be possible to emulate properly the xenon from the 360. But the PS3's Cell... [16:54:08] <mru> emulate it on a hacked ps3 [16:57:21] <Orphis> How big are the fate samples ? [16:58:27] <mru> about 400MB [17:02:29] <Orphis> Ok, thanks [17:06:15] <Orphis> Is Ronald S. Bultje on IRC by the way ? [17:06:36] * mru glares at BBB [17:07:59] <Orphis> BBB: What do you need beside an SSH access to the Win64 machine ? [17:12:56] <jannau> Orphis: have you found http://wiki.multimedia.cx/index.php?title=FATE already [17:13:53] <Orphis> Found it too ;) [17:40:26] <BBB> Orphis: hi, I'd like mingw64 installed, a shell, ideally you reporting to fate from the same system (but on a different account), and all build tools installed [17:40:46] <BBB> is orphis daniel verkamp? [17:40:51] <Orphis> No [17:41:17] <Orphis> But I've seen your request and thought I could help [17:41:20] <BBB> also, if you can install build tools for mingw32 also, that's even better [17:41:26] <Orphis> Yup [17:41:43] <BBB> help would be fantastic, I used to have a win64 box but it's not on fate anymore :( [17:41:56] <Orphis> I have both on my computer [17:41:57] <BBB> "used to have" = "had a shell/ssh account on", not "owned" :-p [17:42:53] <BBB> do you have RDP? [17:42:58] <BBB> RDP would be even nicer [17:43:01] <Orphis> I worked on a simple java binding for ffmpeg for my emulator that would work in a 64bit jvm, not complete but I've already compiled it [17:43:27] <Orphis> That's my personnal computer, so... [17:44:01] <BBB> hm, that sucks a little, running fate continuously will suck the life out of it [17:44:16] <BBB> do you mind if we run cpu-intensive crap on the background regularly? [17:44:32] <Orphis> I don't [17:44:42] <Orphis> I suggested to run it during the night and work hours [17:45:05] <Orphis> And I'll buy a sandy bridge soon so I might retire this machine [17:46:40] <BBB> awesome :) [17:46:41] <Orphis> And honestly, even if it was problematic during the day (which I doubt, except on weekends), I could always run it once a day, even if there's some latency, it's better than nothing [17:46:53] <BBB> absolutely [17:47:26] <elenril> BBB: did you see reimar's mail? [17:47:36] <BBB> if you can set it up so that I have an account with all development tools installed, and access to the fate samples somewhere, and write me an email/privmsg with the login credentials and so on, I'll fix the emu_edge win64 failures [17:47:39] <Orphis> I'm just waiting april for the new bugfree motherboards to buy it [17:47:40] <BBB> elenril: which one? [17:47:44] <elenril> the -mt one [17:47:50] <elenril> i read it as an ok [17:47:53] <Orphis> What username would you like ? [17:47:54] <BBB> elenril: I'm awaiting for astrange to tell me when he'll submit h264/h263 patches [17:47:58] <BBB> Orphis: rbultje [17:48:34] <BBB> elenril: mt w/o h264/h263 support could be read as us having preferential treatment for theora [17:48:40] <elenril> lol [17:48:47] <BBB> elenril: not sure if I want to be a PR penguin yet [17:48:52] <elenril> slashdot will love you for that ;) [18:07:49] <av500> BBB: elenril: old news: http://news.ycombinator.com/item?id=1907357 [18:29:04] <j-b> 'lo [18:31:29] <mru> hi j-b [18:32:29] <av500> +1 [18:36:22] <j-b> all back well? /me readies for 2 days of trolling about <video> for W3C... [18:39:58] <av500> j-b: u in berlin? [18:40:09] <j-b> av500: yes. [18:40:21] <av500> jannau: ^^^ [18:40:34] <j-b> av500: there was this nice trolling opportunity, you see... I couldn't say no :) [18:40:35] <av500> jannau: there is a lost and confused french guy near you [18:41:21] <av500> j-b: dont try public transport, its fake [18:41:32] <j-b> av500: I tried... [18:41:47] <j-b> av500: from schonefeld airport... [18:42:04] <j-b> a stupid idea it was [18:42:08] <av500> :) [18:45:38] <mru> doesn't it have s-bahn? [18:45:51] <jannau> schönefeld airport is even with non-public transport a stupid idea [18:46:08] <mru> TXL isn't all too bad [18:46:10] <jannau> yes, but the s-bahn is broken since 2 years [18:46:16] <mru> would be better if it had rail connection [18:46:29] <mru> _working_ rail [18:47:32] <av500> mru: we are speaking about the capital of western ukraine here [18:47:46] <mru> I thought it was north turkey [18:48:16] <av500> same [18:48:27] <j-b> av500: it is even more "not-in-english" than Paris... [18:48:54] <av500> mru: its cold in winter, hot and humid in summer, broke and full of cartmans [18:49:13] <jannau> instead of fixing it they will close it after (or more likely even before) schoenefeld becomes berlin-brandenburg international [18:50:17] <jannau> tempelhof was nice, it was in walking distance [18:50:27] <av500> yep [18:50:34] <av500> I landed there once in a small plane [18:50:35] <av500> fun [18:51:36] <j-b> Schoenefeld is a mess. And a fucking mess to come back to town. [18:51:38] <wbs> j-b: when I was in berlin, most of the people I spoke to switched to english even if I tried to speak german ;P [18:51:49] <wbs> I guess that was mostly along tourist routes, but still [18:51:58] <j-b> wbs: are you _that_ bad? [18:52:09] <wbs> j-b: apparently ;P [18:52:23] <mru> Flameeyes: ping [18:53:22] <jannau> j-b: if you're up to some german beer after the belgian ping me [18:55:35] <av500> waldmeister! [18:55:36] <jannau> english skills vary of course with education and age but it should be hard to find people who understand english but refuse to talk [18:55:52] <jannau> berliner weiße [18:56:44] <Flameeyes> mru: pong [18:56:47] <j-b> jannau: sure, I am. But I am not near the center, since I am near Fraunhoffer, near Moabit [18:57:15] <mru> Flameeyes: can you please search your deps database for anything using libavutil but not any other libav* [18:57:46] <Flameeyes> mru: will take a bit and I'm on the phone but I'll soonish tell you [18:57:55] <mru> no rush [18:59:48] <jannau> j-b: near Heinrich Hertz Institute? that's near center of west berlin [19:00:00] <Flameeyes> mru: I can tell you that xine-lib-1.2 would be among those ... but that's quite a strange situation [19:00:22] <mru> what does it use for video? [19:00:57] * jannau guesses internal libavcodec copy [19:01:08] <mru> then it doesn't count [19:01:26] <Flameeyes> mru: xine-lib-1.2 (never released) uses libavcodec on a plugin, and libavutil on main lib [19:02:00] <Flameeyes> but tbh I don't think xine counts too much there, I have already described the situation about its life to Diego and Reinhard last year [19:02:24] <j-b> did you write it down? [19:02:26] <Flameeyes> hm actually to get that data I need a working tinderbox, now it isn't [19:02:32] <Flameeyes> j-b: don't think so, was meaning to [19:02:54] <mru> Flameeyes: would be nice to have hard facts, that's all [19:04:18] <elenril> michaelni: does your "veto" mean that you're acknowledging the new structure and stopping your unproductive flames? [19:04:22] <Compn> so xine is still developed ? [19:04:43] <Flameeyes> Compn: that's the point :) it isn't really [19:04:47] <Compn> ah [19:04:55] <mru> nor used, I presume [19:05:08] <Flameeyes> it seems to be still slightly used [19:05:26] <Flameeyes> but the design of xine was so much messed up that's not really worth maintaining, imho [19:05:26] <mru> used as in "used car"? [19:08:18] <Compn> lots of people use totem still [19:08:26] <Flameeyes> and totem has dropped xine backend years ago [19:08:30] <Compn> ah [19:08:31] <ohsix> ^ [19:08:39] <Compn> everyone on gstreamer now ? [19:08:46] <Compn> cept ... mplayer [19:08:46] <elenril> except mplayer [19:08:47] <Flameeyes> gstreamer, vlc, mplayer [19:08:48] <ohsix> now if they'd just ditch baconvideowidget and go native [19:09:18] <Compn> totem uses mplayer as a backend ? funny, i dont remember any patches from them [19:09:29] <ohsix> xine was only in totem to do dvd stuff; and that concern went away like 5 or 6 years ago [19:09:30] <Flameeyes> no totem uses gstreamer [19:09:35] <Compn> oh :P [19:09:41] <Flameeyes> i mean in general, people use one of those three [19:09:41] <saintdev> even phonon has finally (optionally) dropped xine [19:09:46] * Compn is full of outdated information [19:09:56] <elenril> what about amarok [19:09:56] <Flameeyes> xine is simply.. unfixable for a big part [19:10:01] * elenril recalls it using xine [19:10:06] <Flameeyes> elenril: amarok uses phonon since version 2 [19:10:16] <Flameeyes> which can use xine or gstreamer or (recently) vlc [19:10:23] <elenril> yay, more wrappers [19:10:34] * elenril <3 wrappers [19:10:35] <Kovensky> 16:08.26 Flameeyes: and totem has dropped xine backend years ago <-- last time I checked a bunch of distros still had xine as the default phonon backend [19:10:37] <saintdev> and as of kde4.6 xine is finally optional \o/ [19:10:46] <Flameeyes> Kovensky: phonon!=totem [19:10:52] <saintdev> Kovensky: what does totem have to do with phonon? [19:10:52] <Kovensky> bad quote [19:10:54] <Kovensky> but you get the idea [19:11:07] <j-b> Kovensky: no, since 4.6, xine isn't the default one [19:11:08] <Kovensky> the intention of the quote was to hilight "xine backend" not "totem" :X [19:11:10] <Compn> And so with all of that in mind, and with a spare weekend to hack, I thought I'd try making a very simple build system; conceptually very similar to Make, but without hardly any features. [19:11:17] <Compn> oh you evil google bastards [19:11:19] <j-b> and in 4.5, they advised vlc backend [19:11:26] <Compn> http://martine.github.com/ninja/manual.html [19:11:37] <Flameeyes> Kovensky: I was involved in the original implementation of the xine/phonon backend [19:11:40] <Flameeyes> and found it a nasty hack [19:12:00] <ohsix> sniggle; and of phonon? [19:12:04] <j-b> 20:09 < ohsix> xine was only in totem to do dvd stuff; and that concern went away like 5 or 6 years ago [19:12:10] <j-b> ohsix: clearly not [19:12:15] <Kovensky> Flameeyes: lol [19:12:20] <j-b> togst was able to use DVD only last year. [19:12:23] <saintdev> i always wondered why they choose xine for phonon [19:12:37] <ohsix> j-b: lol what [19:12:49] <j-b> ohsix: yes. [19:13:00] <ohsix> what's "togst"? [19:13:07] <j-b> totem-gst [19:13:11] <j-b> soryr [19:13:32] <ohsix> well i was using dvdnav with totem way before that, i don't know your circumstances [19:15:46] <ohsix> though there was a broken week or so where dvd titles wouldn't start; but it had nothing to do with navigation or really even dvd stuff, but subpictures in the stream, and i reported it \m/ [19:18:31] <BBB> please stop dicscussing gst here [19:18:34] <BBB> get your own room :-p [19:18:59] <elenril> yeah, let's discuss you committing -mt [19:19:39] <Compn> did anyone fuzz/valgrind -mt ? :P [19:20:02] <BBB> there's a valgrind fate machine [19:20:04] <BBB> that's sufficient [19:20:12] <BBB> let's not overdo testing this commit [19:20:17] <BBB> it's tested, passes fate [19:20:18] <BBB> it's done [19:20:18] <BBB> commit it [19:20:22] <BBB> if it breaks, we'll figure it out [19:20:28] <BBB> astrange: ping again :) [19:21:14] <ohsix> j-b: well we get to split the difference, dvd navigation actually working to some degree was 2.5 years ago (asked someone who worked on it) [19:21:24] <ohsix> playing titles worked before that but that's cheap :D [19:23:49] <j-b> ohsix: totem-xine was removed in 2.28, according to the release notes. and according to the same, 2.26 didn't had navigation... [19:24:11] <ohsix> j-b: yea, it was removed, but it had been deprecated for like 2 years [19:24:42] <ohsix> navigation was down to the gst plugin being present and working acceptably, that's the 2.5 years ago [19:40:58] <BBB> and they're still discussing gst... [19:40:59] <BBB> blegh [19:42:24] <mru> gst is fine, they paid our dinner last night :) [19:43:00] <BBB> darnit, missed that [19:56:32] <thresh> what, arpi is a ffmpeg developer?! [19:58:25] <jannau> he was 2001-2003, at least we have commit with his account [19:58:53] <iive> [FFmpeg-devel] git blame authorship -> 1845 Arpi [19:59:29] <iive> about the same as D_S [20:00:34] <j-b> thresh: still selling popcorn? [20:01:01] <thresh> j-b: "ffmpeg-devel@, providing evening entertainment since a month" [20:02:32] <DonDiego> thresh: no [20:08:48] <mru> jannau: are those commits to ffmpeg proper or libswscale? [20:09:32] <mru> apparently some were actually to ffmpeg [20:09:37] <j-b> I see the point if libavresampler, I don't see the point in libavutil/libavcore for an external project [20:09:56] <j-b> *in* [20:15:03] <_av500_> '1 [20:15:07] <_av500_> +1 even [20:37:11] * elenril wonders if he'll find a gazillion flame mail in the morning [20:37:13] <elenril> +s [20:38:00] <KotH> elenril: dont go to sleep! keep on reading! [20:40:25] <elenril> sleep >> drama [20:40:37] <elenril> sleep is almost the awesomest thing ever [20:41:00] <elenril> and surely the most underrated [20:41:36] <elenril> KotH: and you should go review my patches if you have time to flame =p [20:44:12] <KotH> i slept too little to write straight sentences w/o hundreds of sentences, and you want me to review patches? [20:44:17] <KotH> er.. [20:44:21] <KotH> hundred of typos [20:44:27] * KotH rests his case [20:45:04] <elenril> yeah, reviews allow me to not think while writing them [20:48:44] <spaam> elenril: better if KotH code something. [21:15:05] <j-b> DonDiego: master? [21:16:14] <DonDiego> j-b: slave? [21:18:16] <Compn> back to the whos the better tree talk then ? :P [21:18:43] <_av500_> gabu_is_soooooo_funny!!! [21:18:44] <ohsix> the one with more fruit bearing nodules [21:18:58] <j-b> av500: for a certain definition of funny... [21:19:07] <_av500_> j-b: for only one [21:19:10] <_av500_> not [21:19:43] * _av500_ wonders why hundreds of gabu fans dont speak up.... [21:19:57] <SunTzuTech> is that the swinging apendage guy? [21:20:04] <ohsix> he's got an old saw to use [21:20:10] <j-b> SunTzuTech: yes [21:20:57] <j-b> av500: I am going to document on gabu's past... He seems a great potential of trolling... But that was before I cared about freesoftware [21:21:23] <SunTzuTech> heh. [21:21:28] <ohsix> right now he's just got his thing from 2004, fight fight [21:21:33] <_av500_> j-b: aint you supposed to be drunk already? [21:21:43] <j-b> av500: not tonight... [21:29:17] <Dark_Shikari> Gabor looks to be spoofing someone's email [21:29:47] <BBB> mine [21:29:47] <BBB> :) [21:29:58] <Dark_Shikari> why isn't he blocked then? [21:30:00] <_av500_> a lot of effort to contribute valuable stuff [21:30:08] <BBB> I feel proud to be recognized by the GREAT GABUCINO </sarcasm> [21:30:18] <BBB> well anyway [21:30:23] <Dark_Shikari> yay, incompetent mailing admins [21:30:30] <BBB> michaelni: please stop this madness, you're making it worse [21:30:44] <mru> Dark_Shikari: he's blocked now [21:30:57] <Dark_Shikari> how so? [21:30:58] <Dark_Shikari> IP? [21:31:03] <Dark_Shikari> /16 ? [21:31:05] <Dark_Shikari> /24? [21:31:07] <thresh> .hu [21:31:10] <mru> /20 [21:31:12] <Dark_Shikari> ok [21:31:31] <mru> he may still find a way around it of course [21:35:19] <Compn> by using any number of mail relays [21:35:28] <Compn> why waste time banning him ? [21:35:32] <Compn> or moderating [21:35:33] <Compn> whatever [21:35:41] <Compn> (sorry, wrong word ) [21:36:06] <_av500_> its a test to see who is more suited sysadmin [21:36:07] <mru> of course he can, but we'll take it one step at a time [21:36:24] <mru> I don't want to use unnecessary force [21:37:24] <SunTzuTech> sick Palin on him :-p [21:38:30] <ohsix> tiliting at windmills and or babysitting [21:46:44] <ohsix> ad hoc rule making to exclusion only results in massive failure [22:05:45] <michaelni> BBB: worse? [22:06:33] <michaelni> BBB: you speak like you are the boss, sorry but you are not :) [22:07:02] <BBB> michaelni: ok, let's do your game. which would you prefer, "us" (without you) to fork or "us" (with you) to reconciliate? [22:07:14] <michaelni> later [22:07:25] <BBB> latter? [22:07:33] <michaelni> reconciliate [22:08:07] <BBB> michaelni: then work towards it [22:08:14] <michaelni> but if we dont i want a clean fork and not 2 ffmpegs thinking they are the 1 ffmpeg [22:08:28] <michaelni> BBB, i dont know how [22:09:21] <BBB> read a howto/manpage, google it, go see a psychiatrist, talk to friends, colleagues, but don't troll [22:09:34] <BBB> does that help? [22:09:51] <iive> BBB: that was personal insult. [22:09:58] <michaelni> talk to friends? you mean gabu ? [22:10:08] <michaelni> iive, yes, you should be baned now ;) [22:10:13] <BBB> arpi sounds a little more sane [22:10:14] <jannau> michaelni: do you think gabu is in any way helping to reconciliate? [22:10:17] <michaelni> s/you/BBB/ [22:10:23] <michaelni> jannau, no [22:10:31] <michaelni> but he is funny sometimes [22:11:36] <iive> michaelni: I have no illusions that I will be banned next, if I continue speaking. Some people don't even knew I am developer. [22:11:55] * michaelni will probably be baned a bit later [22:12:16] * michaelni doesnt care all that much though [22:13:06] <jannau> stop it [22:13:22] <Dark_Shikari> jannau: he's trolling [22:13:54] <jannau> and I'm telling him to stop [22:14:01] <Dark_Shikari> he's michael, that's all he can do [22:14:09] <Dark_Shikari> he lost the ability to develop a year or two ago. [22:14:21] <jannau> stop it [22:16:24] <Dark_Shikari> michaelni: it's only common sense that developers aren't banned from using the ML. [22:16:36] <Dark_Shikari> nobody has ever proposed that or done that afaik. [22:16:44] <michaelni> yes [22:17:21] <mru> Dark_Shikari: if you started acting like gabu, I would not hesitate to ban you, developer or not [22:17:40] <Dark_Shikari> mru: the threshold for banning should be higher for people who do actual work than for people who don't [22:17:42] <mru> otoh, if you did, your mail account had probably been hijacked by gabu [22:17:47] <Dark_Shikari> lol [22:18:02] <Dark_Shikari> In before gabu starts hacking developer email accounts :> [22:18:03] <mru> Dark_Shikari: what I mean is, gabu has crossed both thresholds [22:18:07] <Dark_Shikari> Oh, I agree. [22:18:19] <Dark_Shikari> He's just trolling his heart away now. [22:19:15] * michaelni suggest something crazy, why dont you ask gabu to do something usefull for the project? like trolling with license violators? he was good at that ... [22:19:27] <mru> lol [22:19:37] * michaelni is serious [22:19:50] <mru> I prefer using the lawyers [22:20:03] <michaelni> gabu does more damage and quicker [22:20:17] <mru> he may anger them more [22:20:23] <Dark_Shikari> trolling in place of actual legal stuff can be dangerous. [22:20:25] <mru> but that's not the goal [22:20:37] <j-b> Dark_Shikari: you mean like improving H264 decoding without being at a local minima? or MVC decoding? or an awesome 2D->3D filter? [22:20:46] <Dark_Shikari> >2D -> 3D filter [22:20:48] * Dark_Shikari STABS j-b [22:20:54] <mru> minimUM please.... [22:21:07] <j-b> Dark_Shikari: :) :D [22:21:22] <j-b> mru: k [22:21:53] <mru> j-b: you're french, you should know how latin plurals work [22:22:34] <ohsix> and if you don't know the arity or specific instance? [22:22:36] <_av500_> he is in prussia atm [22:23:15] <j-b> mru: yes, but saying it, is so funny, because there is _always_ someone telling you how it should be... A bit like pizzas and "ne expletif" [22:23:25] <j-b> av500: I did my sahre of latin [22:23:55] <mru> it's a week since Dark_Shikari wrote that... [22:24:06] <mru> I managed to not say anything until now [22:24:21] <j-b> congratulation [22:24:31] <BBB> michaelni: how many violations did gabu resolve? [22:25:05] <mru> and now much money did he collect? [22:25:24] <_av500_> michaelni: if gabu is so productive and usefull, he has a damn hard time making that clear by his emails [22:25:43] <mru> or by any other means [22:25:56] <michaelni> BBB, there was just 1 or 2 violators back then IIRC [22:26:29] <mru> if that's so, you can't possibly know how good or not he was [22:26:35] <michaelni> i dont remember the details but gabu got them to pay something before diego removed him with a vote [22:26:42] <michaelni> that is IIRC [22:26:48] <michaelni> ask gabu or arpi for details [22:26:56] * _av500_ proposes to send gabu to china, tons of violators there [22:27:21] <mru> they'll probably feed him to the dragons [22:27:22] <BBB> michaelni: 1-2 isn't very much [22:27:31] <BBB> michaelni: our sflc lawyers have done more already [22:27:46] <michaelni> yes [22:27:47] <iive> _av500_: there was one devastating earthquake there, they don't need another disaster! ;) [22:27:59] <_av500_> iive: :) [22:28:16] <michaelni> but the SFLC cant deal with violators in china atm and gabu might ;) [22:28:44] <_av500_> china shrugs [22:28:47] <BBB> he can pick any one he likes and do it [22:29:07] <michaelni> BBB would he get some % of the money if he succeeds? [22:29:18] <_av500_> why? [22:29:28] <_av500_> he does it for the cause, no? [22:29:29] <BBB> we can set up an agreement for him, diego and carl eugen if they like, sure [22:29:38] <BBB> _av500_: no, lawyers get a share also [22:29:45] <michaelni> _av500_, the SFLC takes % too [22:29:56] <_av500_> iknow :) [22:30:16] <BBB> michaelni: I have no problem with them taking a cut, as long as it's the same cut for diego, carl eugen, gabu or anyone else that feels like doing something [22:30:28] <BBB> michaelni: so far, carl eugen, diego and me have done it for free because there was no agreement yet [22:31:00] <michaelni> ok ill write arpi a mail, he can tell gabu (dont have gabus email handy) [22:32:01] <BBB> troll(a)troll.hu? [22:32:03] <ohsix> didn't he use it before he was moderated? [22:34:31] <iive> michaelni: I was hoping that you are joking. [22:37:13] <BBB> michaelni: be sure to make it clear to him that trolling is not the same as solving a legal problem, just in case he didn't know that [22:38:08] <mru> trolling can actually make it worse [22:39:36] <BBB> astrange: ping again (although I'm going home now, please don't sleep yet) [22:39:55] <_av500_> mru: indeed, once they figure out who he is :) [22:41:32] <Sean_McG> meh, this Tassimo cappucino is terrible [22:44:49] <Sean_McG> tastes like I'm drinking muck (don't ask) [22:45:19] <mru> then stop drinking it [22:45:36] <Sean_McG> I suppose [23:01:10] <j-b> oh, god... [23:02:45] <astrange> <@BBB> astrange: ping again (although I'm going home now, please don't sleep yet) <- at 6pm? [23:03:43] <Jumpyshoes> is astrange also on the eastcoast? [23:03:47] <astrange> yes [23:03:56] <Jumpyshoes> \o [23:04:06] <astrange> BBB: i'm cleaning false whitespace changes from old merges, then i'll post the whole thing combined as RFC, but i expect people would want it split [23:05:27] <jannau> michaelni: please tell gabu that his mails are not welcome and if cares for ffmpeg he should just stop [23:05:49] * bcoudurier thinks that some people suddently got big mouths since the coup [23:06:39] <jannau> if you want entertainment read his blog or we can recommend some books, films, tv series, ... [23:07:07] * bcoudurier thinks maybe he should be more explicit [23:08:49] <jannau> bcoudurier: please be. I have no idea what problem you have with me [23:09:19] <bcoudurier> big mouth [23:09:53] <superdump> ? [23:15:57] <jannau> bcoudurier: will sending patches help [23:16:54] <bcoudurier> time and contributions will for sure [23:18:51] <ohsix> bcoudurier: you are always very level headed, a good thing to be! [23:19:18] <jannau> ok, I'll try my best (and yes I realize that it could interpreted as continueing bing "big-mouthed") [23:19:33] <jannau> being [23:20:18] <superdump> the transition to git was a pretty big contribution [23:20:23] <bcoudurier> ohsix, respect headed I think [23:20:30] <ohsix> i think he really meant lately, vs. the actual apparent size [23:24:52] <ohsix> calling out everyone on contributions is gonna make a mess [23:29:52] <giftgas> ohai dudz [23:30:00] <giftgas> so what up [23:30:12] <giftgas> We, the FFmpeg [1] [23:30:12] <giftgas> By the way, that is _SO_ not your trademark. You're just an average nerd, neck deep in copyright violation. [23:30:16] <giftgas> this mail didnt get through [23:30:32] <giftgas> To: koth [23:31:04] <uau> you're not very good at trolling [23:31:13] <giftgas> i love you too [23:31:24] * Sean_McG lollerblades [23:31:37] <giftgas> o//

1 0

IRC log for 2011-02-06
by irc＠mansr.com 07 Feb '11

07 Feb '11

[00:04:23] <kierank> http://www.youtube.com/watch?v=1Nrk3zOUhxc [00:36:44] <Dark_Shikari> astrange: yeah, this reduces it from 16 unpredictable branches to N predictable ones, where N is the number of coded blocks [00:41:33] <iive> Dark_Shikari: i have idea for much smaller optimization. in the single case. the old code is if( nnz) { if(nnz==1) {idct_dc} else {idct} } . Here the problem is that you have 2 branches to get to the most common and slow case. it can be just one. [00:42:34] <iive> if (nnz>1) {idct} else if(nnz==1) {idct_dc} [00:43:48] <Dark_Shikari> no, the most common case is no idct probably [00:44:00] <iive> it is also the fastest. [01:50:16] <BBB> ruggles: can you review "[PATCH 1/2] spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI" and see if it makes sense? [01:50:44] <mru> Dark_Shikari: I'll create those macros next week if you need them [01:51:11] <Dark_Shikari> mru: it's not critical, but they REALLY should eixst. [01:51:13] <Dark_Shikari> *exist [01:51:16] <Dark_Shikari> I can't imagine why they wouldn't. [01:52:51] <mru> never got round to doing it [01:53:01] <Dark_Shikari> can you do it sometime then? [01:53:17] <mru> sure, next week [01:53:22] <Dark_Shikari> k [01:53:27] <mru> at fosdem now [01:55:45] <Dark_Shikari> k [03:06:10] <Daemon405> oh mru. poke. [03:06:18] <Daemon405> i was told to poke you for arm docs [05:28:56] <Dark_Shikari> BBB: another patch up for review... [08:02:30] <elenril> Flameeyes: ping [08:38:28] <_av500_> gm [08:47:15] <Dark_Shikari> die gcc die [08:47:16] <Dark_Shikari> 36b5: c1 eb 08 shr ebx,0x8 [08:47:17] <Dark_Shikari> 36b8: 85 db test ebx,ebx [08:51:01] <iive> 4.5? [08:51:49] <Dark_Shikari> 4.3.4 [08:57:23] <astrange> i think i saw a commit about that, but i don't remember if it was in 4.5 or 4.6 [08:58:18] <Dark_Shikari> hmm, another annoying thing I ran into [08:58:27] <Dark_Shikari> if I loop over 4 dct blocks (x = 0; x < 4; x++), gcc unrolls my loop [08:58:30] <Dark_Shikari> this is good, it helps speed. [08:58:38] <Dark_Shikari> if I add an early termination condition, i.e. if(!nnz4) break; [08:58:40] <Dark_Shikari> this helps too, it's good [08:58:45] <Dark_Shikari> But now we have two REDUNDANT termination conditions [08:58:47] <Dark_Shikari> the x<4 is needless. [08:58:56] <Dark_Shikari> ... but if I remove the x<4, gcc isn't smart enough to unroll anymore. [08:59:02] <Dark_Shikari> Since, naturally, it doesn't know the loop can only go 4 times. [08:59:14] <Dark_Shikari> So one has to actively keep redundant information in the code to make gcc generate fast code, ugh. [10:30:48] <Dark_Shikari> mru: can you review the MC chroma NEON patch on x264-devel? [10:31:23] <mmu_man_> plop from the Haiku booth at FOSDEM (in front of AW1.117) [10:31:37] <mmu_man_> building ffmpeg on Haiku atm [10:32:34] <kshishkov> Dark_Shikari: too hard to review anything here, too noisy [10:34:48] <Dark_Shikari> is mru at fosdem? [10:36:28] <_av500_> yes [10:36:53] <_av500_> all the cool people are [10:37:09] <peloverde> I wish I was [10:37:52] <_av500_> you was last year, it does not rub off so quickly [10:38:57] <thresh> _av500_: hey. Met another Kostya yet? :) [10:39:40] <_av500_> thresh: nope [10:39:46] <_av500_> but i am not at the booth [10:39:53] <_av500_> personell there has been instructed [10:41:13] <mmu_man_> it worked actually \o/ [10:48:24] <mru> Dark_Shikari: I'll look at it later, hard to focus here at fosdem [10:48:33] <Dark_Shikari> k, no problem [10:48:34] <Dark_Shikari> no rush [10:48:38] <elenril> how do i disable all warning except deprecations? [10:48:39] <Dark_Shikari> already told the author review would be delayed [10:49:40] <mru> elenril: -w -Wdeprecated ? [10:49:49] <mru> or similar [10:52:05] <elenril> doesn't work [10:52:13] <elenril> good old grep to the rescue [11:13:03] <siretart> FFmpeg BOF starting right now! [11:13:43] <Dark_Shikari> BOF? [11:15:11] <siretart> birds of a feather session [11:19:41] <elenril> http://pastebin.com/eh4Sx3gi << why doesn't this work? [11:19:45] * elenril fails at macros [11:20:57] <_av500_> siretart: ben is heading your way [11:26:03] <spaam> elenril: yo dude.. can you try use an empty line between the stuff you quote and your text? :) [11:30:47] <_av500_> [11:30:48] <_av500_> ok [12:13:25] <_av500_> thresh: no pickup yet :( [12:17:57] <thresh> _av500_: meh :/ [13:07:32] <Dark_Shikari> fucking facepalmy facepalm [13:07:40] <Dark_Shikari> someone was using libx264 through lavc and they got vbv underflows every time [13:07:48] <Dark_Shikari> turned out that rc_initial_buffer_occupancy is by default 0 in libavcodec (?!?!!) [13:07:56] <Dark_Shikari> i.e. vbv starts empty, i.e. impossible situation [13:08:00] <Dark_Shikari> ... but why doesn't ffmpeg break? [13:08:03] <Dark_Shikari> because ffmpeg.c sets it. [13:08:18] <Dark_Shikari> The only thing worse than non-codec-specific defaults is defaults which are broken and have to be fixed by the calling app. [13:08:21] <Dark_Shikari> for fuck's sake. [13:08:39] <Dark_Shikari> (and by broken defaults, I mean defaults that don't even tell you that they're broken, and just silently fail) [13:08:47] <elenril> send patches! [13:16:26] <elenril> ok, time to whore some git blame points [13:18:34] <elenril> 156 files changed, 3828 insertions(+), 3741 deletions(-) bwahahaha [13:31:01] <lu_zero> uhm [13:31:37] <spaam> elenril: Nice [13:33:18] <Flameeyes> elenril: pong [13:33:45] <elenril> Flameeyes: you said something about interlib ff_ dependencies [13:33:58] <elenril> how do i find those? [13:35:31] <Flameeyes> elenril: I posted about it one or two weeks ago.. sec [13:35:55] <Flameeyes> search for "Interlib non-public dependencies" [13:36:37] <CIA-38> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * re8dcd73058 ffmpeg/libavcodec/vp3.c: [13:36:38] <CIA-38> ffmpeg: vp3: Factor out expression [13:36:38] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:36:49] <CIA-38> ffmpeg: James Zern <jzern(a)google.com> master * r60ff9de6ff ffmpeg/cmdutils.c: [13:36:49] <CIA-38> ffmpeg: cmdutils: fix codec-specific options from preset [13:36:49] <CIA-38> ffmpeg: Using a preset file caused the address of a stack variable to be stored [13:36:49] <CIA-38> ffmpeg: in opt_names/values. This change causes the strings to be dup'd then [13:36:50] <CIA-38> ffmpeg: freed in uninit_opts. [13:36:50] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:36:52] <CIA-38> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * redbb0c0708 ffmpeg/libavcodec/vp3.c: [13:36:52] <CIA-38> ffmpeg: vp3: Move table allocation code into a new function [13:36:52] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:36:54] <CIA-38> ffmpeg: James Zern <jzern(a)google.com> master * r3a6a9cdf5b ffmpeg/ (cmdutils.c ffmpeg.c): [13:36:54] <CIA-38> ffmpeg: cmdutils: fix opt_values leak [13:36:54] <CIA-38> ffmpeg: Add free to uninit_opts and relocate opt_names to same [13:36:54] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:36:56] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * re4f85b8499 ffmpeg/libavformat/wtv.c: [13:36:56] <CIA-38> ffmpeg: wtv: do not use flag in stream_guid chunk to determine if stream is valid, as this method is unreliable [13:36:56] <CIA-38> ffmpeg: This fixes roundup issue 2556. [13:36:56] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:37:05] <CIA-38> ffmpeg: Kieran Kunhya <kieran(a)kunhya.com> master * rf4a86bc981 ffmpeg/libavcodec/mpegaudiodec.c: [13:37:05] <CIA-38> ffmpeg: Set channel_layout for mpegaudio [13:37:05] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:37:07] <CIA-38> ffmpeg: Nicolas George <nicolas.george(a)normalesup.org> master * rad3cffb68f ffmpeg/libavformat/tcp.c: [13:37:07] <CIA-38> ffmpeg: Non-blocking protocol: TCP [13:37:07] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george(a)normalesup.org> [13:37:07] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:37:08] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r5a6de4e7e8 ffmpeg/libavformat/mp3enc.c: [13:37:08] <CIA-38> ffmpeg: mp3enc: write ISO8859-1 instead of UTF-16 when possible [13:37:08] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:37:12] <CIA-38> ffmpeg: Nicolas George <nicolas.george(a)normalesup.org> master * rfe174fc8fc ffmpeg/ (doc/APIchanges libavformat/avio.h): [13:37:12] <CIA-38> ffmpeg: Non-blocking protocols: flag and documentation [13:37:12] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george(a)normalesup.org> [13:37:12] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:37:14] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r74571e333c ffmpeg/libavformat/wtv.c: [13:37:14] <CIA-38> ffmpeg: reindent after last commit [13:37:14] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:37:16] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rc2fcd0a7a4 ffmpeg/ (14 files in 2 dirs): [13:37:16] <CIA-38> ffmpeg: Replace remaining occurrences of deprecated CH_* with AV_CH_* [13:37:16] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:37:19] <CIA-38> ffmpeg: Nicolas George <nicolas.george(a)normalesup.org> master * r90441276e4 ffmpeg/libavformat/ (avio.c avio.h): [13:37:19] <CIA-38> ffmpeg: Non-blocking protocol: core wrapper functions [13:37:19] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george(a)normalesup.org> [13:41:10] <elenril> Flameeyes: http://blog.flameeyes.eu/2011/01/20/hide-those-symbols this? [13:41:23] <Flameeyes> elenril: nope on the ffmpeg-devel mailing list ;) [13:42:01] <elenril> heh [13:42:15] <elenril> i guess i'll read that anyway [13:43:20] <elenril> Flameeyes: were all those patches applied btw? [13:43:31] <Flameeyes> elenril: probably not all, let me see which ones are not merged yet [13:43:34] <elenril> i think at least the id3v2 one wasn't [13:44:00] <elenril> ha, found it [13:47:26] <elenril> so what should we do with all the url_ stuff [13:48:33] <elenril> it's semi-public now [13:49:45] <Flameeyes> I suppose rename and alias it? [13:50:52] <elenril> well it's consistenly using the url_ prefix :) [13:51:16] <elenril> we could just declare it as yet another lavf-reserved prefix [13:51:25] <BBB> s/url_/avio_/g [13:51:25] <Flameeyes> likely colliding with other stuff [13:51:30] <BBB> url_ is too generic [13:51:35] <Flameeyes> what BBB said [13:51:50] <BBB> ffmpeg's "namespace" is av{,format,codec,filter,io}_* [13:52:13] <BBB> we can add more things inside that {} if necessary [13:52:24] <BBB> but url doesn't fit that description :-p [13:52:38] <Flameeyes> don't underestimate the nastiness of symbol collisions! [13:52:47] <BBB> I've seen it happen once or twice [13:53:03] <BBB> it's nearly impossible to figure out on released software [13:53:26] <BBB> in debugging mode, it's not too difficult, but then again, how many contributors debug a version of ffmpeg linked to 20 external libs? [13:53:40] <BBB> we don't, and that's exactly why this is problematic :-p [13:53:52] <Flameeyes> BBB: I learnt about it when I maintained xine [13:54:00] <Flameeyes> because of ffmpeg's linking to faad [13:54:45] <Flameeyes> xine (or amarok) crashed when reproducing an aac file.. but only on some systems.. but not on mine [13:54:59] <BBB> kshishkov: I think reimar and I are right, I know it's unlikely but src+offset can overflow if src is in the address space 0xffffxxxx [13:55:19] <BBB> kshishkov: please change it :-p and I'll apply, I'm in commit-mode anyway now [13:55:27] <Flameeyes> until I tried the -Bdirect patches coming from suse... and when looking at that I could see the symbols being loaded from the wrong objet [13:55:31] <Flameeyes> *object [13:55:53] <BBB> and you go like "YOU FUCKING #$^&#%^#%" [13:56:09] <Flameeyes> BBB: the good news are that I have tools to be able to find those situations before they even cause runtime failures :D [13:56:34] <Flameeyes> the sad news is that one xiph^Wghostscript idiot could have preemptively solved a bug three years ago but decided to ignore me [13:58:40] <elenril> BBB: feel like reading and applying my avio patches? ;) [13:58:55] <Flameeyes> elenril: http://paste.pocoo.org/show/333063/ these are those not merged and still applying fine [13:59:47] <BBB> ignore freeing opt_names? [14:00:05] <BBB> but yes they should be static [14:00:16] <BBB> that patch likely doesn't apply anymore, please re-check [14:00:41] <Flameeyes> elenril: uhm you probably don't want to break ABI there, so you'd need compatibility aliases until the abi is actually bumped, or am I missing something? [14:01:06] <Flameeyes> yes I was missing a hunk while searching, sorry [14:01:07] <elenril> Flameeyes: they're there [14:01:09] <BBB> he's right, I think mplayer uses it [14:01:34] <Flameeyes> BBB: more than that, put_buffer is actually quite used in the wild (see the other post on the ml with the list of used non-prefixed symbols) [14:01:35] <BBB> also " Make inter_rvlc and intra_rvlc static tables." had a comment that you should be looking at [14:02:14] <Flameeyes> BBB: let me check [14:02:26] <BBB> ff_init_cabac_encoder is part of the h264 "encoder" [14:02:31] <BBB> we should be removing that kind of code [14:02:35] <BBB> anyone interested? [14:02:48] <Flameeyes> BBB: uhm I think I also replied [14:02:53] <BBB> I don't see your reply [14:03:12] <BBB> maybe I screwed up and deleted the email on my iphone [14:03:24] <BBB> iphone/gmail can fuck up threading or delete individual messages [14:03:45] <Flameeyes> let me see if I find the one I sent [14:03:54] * Flameeyes is hating on OpenSSH today [14:04:44] <Flameeyes> BBB: for whatever reason it ended up just to you rather than to the list, and it was mostly a TODO for myself to make sure that they won't cause increase in the code size [14:04:51] <Flameeyes> give me a moment to restore a sane openssh on my systems [14:08:57] <BBB> ok :) [14:09:09] <BBB> that one I received, but that was indeed not a new patch [14:14:07] <elenril> +2011-02-XX - XXXXXXX - lavf 52.XX.0 - avio.h [14:14:12] * elenril diagnoses BBB with ADHD [14:15:02] <BBB> ? [14:15:09] <elenril> this is what you just committed [14:15:10] <BBB> I did that? [14:15:13] <BBB> oops [14:15:19] <elenril> fe174fc8fc4bbdb050014a945de7eb9b28ba358e [14:17:31] <BBB> got it, will fix [14:19:55] <BBB> adhd fixed [14:20:07] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * refdd67cb00 ffmpeg/ (doc/APIchanges libavformat/version.h): Update MINOR and set git rev for non-blocking flag API addition. [14:20:18] <BBB> long live cocaine^dritalin [14:20:32] * Flameeyes mutters something bad about openssh [14:21:01] <elenril> Flameeyes: what did it do to you? [14:21:58] <Flameeyes> elenril: I use my main box via ssh.. usually it's all fine, today I connect, launch a sync, it freezes [14:22:12] <Flameeyes> I reboot, try again, it freezes [14:22:53] * elenril used to see some freezing when running commands with long output, like dmesg [14:23:05] <elenril> then they just disappeared after a reboot [14:23:16] <Flameeyes> I kill it, rebuild without hpn (a Gentoo feature), and still again [14:24:59] <Flameeyes> ah shmuck, I don't have !env_reset on raven, it's still hpn-enabled.. disabling it again [14:28:55] <elenril> wtf is an avf_ prefix [14:30:07] * elenril and git blames lu_zero [14:30:40] <elenril> eew, what are those ffserver-specific hacks doing in avformat.h [14:35:43] <Flameeyes> BBB: okay.. my patch there can't make the situation worse than it was before given that inter_rvlc is used only together with inter_rvlc_run and inter_rvlc_level to declare a (non-static) rvlc_rl_inter [14:36:13] <Flameeyes> which is only ever used in mpeg4videodec [14:36:34] <Flameeyes> the same goes for intra [14:40:32] <elenril> BBB: still slighly hyperactive, you forgot the date ;) [14:45:48] <BBB> elenril: we need a git pull checker script or so [14:46:21] <elenril> indeed [14:46:52] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rae0f8a1a33 ffmpeg/doc/APIchanges: Fill in missing date. [14:47:45] <elenril> that's all folks, no more unprefixed functions in avformat.h [14:48:47] <Flameeyes> BBB: you got mail [14:50:16] <BBB> Flameeyes: oh, only one, I misread my own grep indeed [14:50:24] <BBB> keep it as a header, it's fine then [14:50:28] <Flameeyes> BBB: I suggest you add --color=auto to your grep alias :D [14:50:57] <Flameeyes> BBB: I'm still not sure why they're emitted on mpeg4video.o if they are only used by videodec though [14:52:40] <BBB> don't know [14:53:13] <BBB> will commit [14:55:08] <BBB> done [14:55:13] <CIA-38> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r84ae8936f6 ffmpeg/libavcodec/ (mpeg4data.h mpeg4video.h): [14:55:13] <CIA-38> ffmpeg: Make inter_rvlc and intra_rvlc static tables. [14:55:13] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [14:55:40] <Flameeyes> thanks, will see if it makes some difference to actually move those tables though [14:55:47] <BBB> it won't make a difference [14:55:52] <BBB> we do this for a lot of files [14:55:59] <BBB> (formats/codecs/...) [14:56:06] <BBB> e.g. wmavoice, lots of other decoders also [15:07:32] <Flameeyes> it does make a slight different: it increases the code size by 12 bytes and reduces the data size [15:40:52] <BBB> Flameeyes: stripped or unstripped binary? [15:41:09] <Flameeyes> BBB: both unstripped [15:43:22] <Flameeyes> BBB: fwiw it should make the same exact difference on the stripped ones, just the overhead would be smaller [15:43:36] <BBB> can you strip them and re-check? [15:43:54] <BBB> (nobody cares much about datasize on an unstripped binary; if you did, you'd strip them) [15:45:53] <Flameeyes> sure... not sure if you got what my stats meant though ;) [15:45:55] <BBB> elenril: probably stupid, but as you deprecate symbols and add av_() variants, can you also ensure that there's doxy in them so we actually know what they do? [15:46:02] <Flameeyes> http://paste.pocoo.org/show/333102/ [15:46:20] <Flameeyes> BBB: rbelf-size only counts allocated sections, *not* the whole file's size [15:46:30] <Flameeyes> the stuff that's stripped is never allocated [15:48:29] <BBB> I see [15:48:35] <BBB> I guess I still don't really know what it means [15:48:38] <BBB> the filesize is identical [15:48:42] <BBB> rodata is slightly changed... [15:49:06] <BBB> so bak is with header, non-bak is in source file? [15:49:20] <Flameeyes> yes [15:49:55] <Flameeyes> sections in the file are 4KiB-padded, thys why filesize is the same [15:52:18] <Flameeyes> as I said it's mostly a point of discussion; if it's just those two symbols it makes no difference [15:52:22] <Flameeyes> but 10 symbols like these? 100? [15:52:39] <_av500_> thresh: we are go!!!! [15:55:40] <Flameeyes> _av500_: you're gone? [15:57:07] <BBB> Flameeyes: it makes no sense that moving a table from h to c would change anything, except ordering... [15:57:28] <Flameeyes> BBB: sure it makes, if you also make it static contextually [15:57:35] <Flameeyes> a static symbol is not exposed [15:57:52] <BBB> it is already static and const [15:57:55] <Flameeyes> which means that the compiler can trick it a bit further _and_ you no longer have it on the PLT [15:58:01] <Flameeyes> the RLTable objects aren't [15:58:29] <BBB> ah [15:58:42] <thresh> _av500_: crap :/ [15:59:02] <BBB> so make them staticconst [15:59:08] <BBB> in the hdr [15:59:09] <Flameeyes> they don't seem to be const [15:59:16] <Flameeyes> and no I can't make them staticconst in the header [15:59:22] <BBB> ? [15:59:24] <Flameeyes> because the header is included by _another_ source file [15:59:39] <Flameeyes> which means that you have mpeg4video.o exposing the two symbols and mpeg4videodec.o using them [15:59:44] <Flameeyes> mpeg4video.o does not use them at all [15:59:52] <Flameeyes> which is why I thought it was absurd [16:04:27] <BBB> i will chech, 1 sec [16:13:47] <BBB> I see... [16:13:49] <BBB> hmm... [16:13:50] <BBB> sucks [16:13:55] <BBB> I don't want to add tables into source files [16:13:59] <BBB> I hate that [16:14:03] <BBB> can we make a new .h file? [16:23:07] <kierank> any good presentations at fosdem [16:24:29] <Flameeyes> BBB: sure thing [16:44:21] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r48545a8f72 ffmpeg/configure: [16:44:21] <CIA-38> ffmpeg: configure: check yasm/nasm for working pextrd opcode [16:44:21] <CIA-38> ffmpeg: NASM versions older than 2.08 fail to build ffmpeg with several [16:44:21] <CIA-38> ffmpeg: "error: operation size not specified" errors but this is not caught in [16:44:21] <CIA-38> ffmpeg: configure. [16:44:22] <CIA-38> ffmpeg: Fix that by checking if "pextrd [eax], xmm0, 1" works in configure. [16:44:22] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:48:34] <kierank> "Sorry for the delays but encoding 1080i streams in Theora takes a lot of CPU power." [16:49:25] <JEEB> LOL [16:55:11] <Flameeyes> michaelni: let's be clear you can dislike a change as much as you wish and call it bad, but that change isn't by itself "wrong". Especially not when I have made it clear that it's _not_ to be applied but just a point open for discussion. [16:59:24] <ohsix> isn't it implicit that one phase is for comments/discussion, and another is for requesting it be added? [17:00:34] <Flameeyes> ohsix: more or less, sometimes it's better to make it clear — in this case I was looking for comments on the general effect of doing the change, rather than simply having it reviewed [17:01:01] <Flameeyes> as it makes no sense whatsoever to do it for just two symbols: the changes are so small that don't warrant even the commit effort [17:12:12] <michaelni> Flameeyes, it says [PATCH] not [RFC] in the subj [17:12:33] <michaelni> and it is by itself wrong btw [17:14:14] <Flameeyes> and if you can see my own reply to the patch says I forgot an RFC in it [17:15:07] <Flameeyes> so instead of digging your own grave by upsetting more people who are not really concerned with the whole powergames at hand, you'd better read and explain yourself [17:16:04] <michaelni> Flameeyes, ive just now looked at the reply [17:17:16] <michaelni> Flameeyes, its because this table belongs to mpeg4 not just the decoder [17:17:38] <michaelni> the encoder side is not implemented, true but its not a big thing to implement [17:17:56] <michaelni> and it feels quite wrong to me to move such a table to the decoder [17:18:00] <Flameeyes> michaelni: that doesn't really mean that the patch is wrong; that means the patch is unclean [17:18:33] <michaelni> well so its unclean, wherfes the difference? [17:19:12] <ohsix> fit for purpose :D [17:20:02] <Flameeyes> michaelni: take a suggestion from a neutral person in the whole mess: take a vacation. [17:20:57] <michaelni> Flameeyes, not an option [17:21:01] <Flameeyes> _I_ am not partial to either side in general; _I_ haven't accused you of rejecting my patches; _I_ have submitted a patch that you shot down, and then you basically told me you're treating me like shit because somebody else accuses you of something? [17:21:19] <Flameeyes> I guess that means 'congrats, you just gave one more people an idea on the situation' [17:21:32] <ohsix> fwiw i didn't know the mail was marked PATCH vs. RFC or otherwise when i made my comment [17:21:33] <michaelni> i just explained why i thinl the patch is ehm unclean [17:21:58] <Flameeyes> michaelni: sure, you did here, so what's the bloody point of the reply to my request on ml? [17:22:16] <Flameeyes> you could well have left it without reply after explaining it here, I was satisfied enough [17:22:46] <michaelni> have people become so sensitive to flames? [17:23:26] <elenril> err....the message wasn't clear enough? [17:23:30] <ohsix> perhaps they're dessicated and highly flamable [17:23:42] <Flameeyes> I'm not "people"; I'm a specific person who's just trying to lend a hand from time to time in the little extra time I got [17:24:35] <michaelni> ohsix, you are trolling like always but this time you have a point [17:24:56] <ohsix> :\ [17:25:03] <elenril> haha [17:27:00] <elenril> michaelni: where does find_info_tag belong then? [17:28:06] <michaelni> if its small and usefull outside MM then libavutil if its big and messy libavcore [17:28:37] <elenril> what if it's big and messy, yet useful outside MM? [17:28:55] <michaelni> cleanup :) [17:29:16] <elenril> :effort: [17:29:35] * elenril has science to do [17:29:42] <BBB> what kind of science? [17:29:49] <michaelni> put in avcore when uncertain [17:30:05] <michaelni> we can move to avutil easier than the other way around [17:30:07] <elenril> BBB: exams [17:30:15] <BBB> elenril: in ... what subject? [17:30:18] <elenril> quantum field theory in curved spacetime [17:30:28] <elenril> aka the most obscure shamanism ever [17:32:18] <BBB> that sounds like stuff where you need imagination of 17 dimensions [17:32:20] <michaelni> elenril, sounds like mixing QM with gravity, do we alraedy have a consistent theory about that that matches reality? [17:33:27] <elenril> no and no [17:33:49] <elenril> or well it kinda is mixing QM with gravity, but gravity isn't quantised [17:33:59] <michaelni> ok so you do an exam of self inconsistent math that doesnt match reality? [17:34:05] <elenril> it's just there as a classical background [17:34:50] <michaelni> elenril, are there any experiments that suggest gravity needs to be quantized? [17:34:53] <elenril> well....thing is, this theory is pretty much untestable under normal circumstances [17:35:13] <elenril> we'd need some microscopic black holes around ;) [17:35:28] <elenril> michaelni: general relativity by itself predicts singularities [17:35:44] * michaelni is interrested in this stuff but doesnt have the math/physics background knowledge sadly [17:35:48] <elenril> most physicists don't believe it's possible for "real" singularities to exist [17:36:29] <michaelni> belive has historically not been very reliable [17:36:32] <elenril> therefore it's expected that a theory that quantises gravity would remove those singularitites [17:36:53] <kierank> michaelni: http://ocw.mit.edu/ [17:37:36] <michaelni> kierank, thanks, now i know what ill do when i resign :) [17:43:28] <elenril> saste: care to rebase-resend/ping the av_parse_time patch? [17:44:12] <elenril> or is there a reason it wasn't applied? [17:44:27] <iive> michaelni: create artificial black hole and throw root team in it? [17:45:15] <spaam> kierank: something you read time to time? [17:45:42] <kierank> the lectures are interesting [17:45:50] <elenril> kierank: btw how are your studies going? [17:51:08] * elenril make food [18:30:02] * Compn sends big quote mail to -devel [18:36:16] <_av500_> thresh: no, the transaction is a go! [18:36:26] <_av500_> he came with password and rubels [18:37:28] <thresh> _av500_: ha awesome, now you can buy our oil as well! [18:37:50] <j-b> 'lo trolls [18:38:40] <_av500_> j-b: hi [18:38:44] <_av500_> thresh: ok, will do [18:43:22] <mru> j-b: ping [18:44:23] <j-b> pong [18:45:10] <mru> j-b: dinner @ thai city, gretrystraat 43, 20:30 [18:45:55] <j-b> might be doable [18:50:19] <wbs> would anyone be interested in applying the movie source avfilter patch? it was ok'd sometimes last week [18:50:29] <mru> j-b: btw your phone is off [18:50:59] <wbs> sure, saste could set up a libavfilter repo somewhere as "subsystem maintainer", but stuff should be pulled into the main repo at some time, and that one should be on the "please merge to master"-queue now [18:52:35] <Daemon404> mru, ! [18:52:41] <Daemon404> happen to see my poke yesterday? [18:53:16] <mru> Daemon404: you had some arm query? [18:53:47] <Daemon404> mru, i was told to poke you for arm specs/docs (instructions, regs, etc) [18:54:52] <mru> Daemon404: infocenter.arm.com [18:55:02] <mru> has all the docs [18:55:10] <Daemon404> i know, do not want (tm) [18:55:16] <j-b> mru: I know... [18:55:17] <Daemon404> very annoying to read, couldnt find any pdfs [18:55:34] <Daemon404> i might end up going through my company trying to obtain paper versions [18:55:40] <Daemon404> cause paper is infinitely nicer [18:55:56] <mru> there are pdfs of most docs [18:56:03] <mru> some are only pdf [18:56:20] <Daemon404> i might need to get a decent ebook reader [18:56:25] <Daemon404> pdfs on monitor = :( [18:56:37] <mru> I don't think they still do paper books [18:56:45] <Daemon404> that's a shame [18:56:51] <Daemon404> i always learn better from paper stuff usually [18:56:57] <Daemon404> doont ask me why. [18:57:07] <mru> buy a printer [18:57:21] <Daemon404> i own about 10 of those [18:59:49] <mru> then I'm afraid I can't help much [19:00:32] <mru> I'd dcc you some paper but firewall won't allow it [19:01:40] <mru> j-b: well, come if you can, otherwise maybe we can meet later [19:02:15] <mru> j-b: will you turn the phone back on? [19:02:34] <Daemon404> lul [19:02:56] <Daemon404> hmm which pdf should i be looking at for good descriptions of instructions, registers etc [19:03:02] <Daemon404> tech ref pdf doesnt seem to be what i want [19:04:14] <mru> arch ref is the one you want [19:05:50] <Daemon404> mru, i need a login :V [19:05:53] <j-b> mru: no, my operator blocked my international roaming [19:06:50] <j-b> mru: I will move now then [19:06:53] <_av500_> j-b: u are french, its normal [19:07:38] <j-b> :) [19:07:43] <j-b> 20:30, I will be there. [19:07:51] <_av500_> have fun [19:08:05] <_av500_> try not to do a revolution [19:08:21] * elenril overthrows _av500_ [19:08:24] <thresh> "reports says French people finished ffmpeg coup" [19:08:35] <elenril> _av500_: you're not there? [19:08:44] <j-b> C U soon [19:09:21] <_av500_> elenril: on my way back [19:12:08] * Daemon404 waits for slow pdf to dl [19:15:31] <Daemon404> mru, thanks, this is the exact doc i wanted [19:30:14] <elenril> I found more than one project taking a library originally in a number of source files, concatenating all of them together, and then building it in a single object file [19:30:18] <elenril> Flameeyes: ^lolwut? [19:51:07] <Flameeyes> elenril: yes I know it's a mess but sme people used to do that [19:51:43] <wbs> although butt ugly, I guess it's a covenient way to bundle a library ;P [19:52:08] * elenril bundles wbs to rtmpdump [19:52:16] <wbs> :-( [19:52:39] <elenril> is it that bad? [19:53:28] <wbs> nah, it's decent, there's a few quirks I haven't had time to weed out though [19:53:58] <elenril> wait, i thought you implemented all this stuff in ffmpeg [19:54:03] <jannau> sigh, more than 300 unread mails on ffmpeg-devel [19:54:20] <elenril> hi jannau [19:54:25] <wbs> elenril: no, I've merely fixed 1-2 bugs in the lavf native rtmp code (written by kostya), I've worked most on rtsp/rtp [19:54:55] <elenril> oh [19:55:07] <wbs> jannau: I usually dread not watching the ML for a few hours, since it takes forever to catch up again [19:56:59] * elenril tries to parse Flameeyes' inline symbols mail [19:57:16] * elenril should learn more elf-fu [19:57:47] * jannau is on his way back from fosdem and hasn't checked mails mails since friday [19:58:14] <wbs> jannau: ugh, that'll take a while ;P [19:58:17] <elenril> feel free to skip all the drama [19:58:25] <elenril> that's like half of it ;) [19:59:47] <jannau> I still have 4 hours of train ride home and I've seen already parts of the drama [20:00:09] * elenril feels he's getting too many branches [20:00:26] <wbs> elenril: how many do you have? [20:00:45] <elenril> 16 [20:00:54] <elenril> but some/more are old cruft [20:00:58] <elenril> s/more/most [20:01:22] <wbs> I've got 37 ffmpeg branches locally, 55 in my private archive repo [20:01:26] <elenril> o_0 [20:01:34] * _av500_ waves to jannau in 1st class [20:01:57] <wbs> some just old cruft, some unfinished features, some almost-finished features, some useful for creating more/less broken output for testing certain conditions, etc [20:01:58] <thresh> wifi in trains? [20:02:18] <elenril> хихи in trains [20:02:26] <thresh> whut? [20:02:29] <_av500_> 3g [20:03:12] <thresh> i've got a data plan from my cell provider. 8 euro / month for 128 kbit/sec [20:03:24] <thresh> they call it 'broadband mobile internet' [20:03:46] <elenril> sound oxymoron-ish [20:03:47] <wbs> thresh: here we pay ~13 euro / month for unlimited, full speed mobile internet [20:04:13] <jannau> we could have made ad-hoc wifi in the train from brussels to cologne/franktfurt [20:04:17] <_av500_> i am on edge now, not really fast either [20:04:22] <_av500_> but the train runs 300 atm [20:04:24] <jannau> it was full of fosdem [20:04:50] <thresh> wbs: :S [20:05:11] <thresh> well the catch in my case is they limit the speed to 64 kbit/sec after first gigabyte [20:05:17] <thresh> cheapskates [20:05:36] <jannau> here is is more like 15-30 € for 5G [20:05:46] <wbs> thresh: many operators do something similar here, but at least one still has totally unlimited use [20:06:14] <_av500_> you can use bottle of wodka as potable hotspot [20:08:07] <thresh> _av500_: yep, that's what we do when there is a lot of time to be wasted and you have nothing to do, e.g. traveling by train [20:08:15] <thresh> also call it 'the time machine' [20:10:30] <_av500_> ic [20:30:24] <spaam> elenril_: yo? [20:30:39] * elenril_ kicks freenode [20:31:32] <spaam> :) [20:46:28] <jannau> what's the sudden interest in libfaac on libav-user? [20:51:49] <peloverde> "since FAAC is an LGPL modification of the ref s/w), it looks like we may get clearance from 'legal' to use libfaac also." [20:52:10] <peloverde> what? it's impossible to satisfy both licenses simultaneously [20:55:02] <jannau> es exactly [20:55:05] <jannau> yes [20:55:12] <jannau> stupid 3g [21:08:14] <elenril> wtf, arpi commenting on my patches [21:08:20] <elenril> what did i ever do to him [21:11:10] <merbanan> are the comments valid ? [21:11:38] <elenril> a little nitpicky, but yes [21:13:14] <merbanan> just address them then, end of story [21:17:46] <CIA-38> ffmpeg: Reimar Döffinger <git(a)videolan.org> master * ra351110eea ffmpeg/libavformat/ (8 files): [21:17:46] <CIA-38> ffmpeg: Always use av_set_pts_info to set the stream time base. [21:17:46] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:17:49] <CIA-38> ffmpeg: Sascha Sommer <saschasommer(a)freenet.de> master * red19fafd48 ffmpeg/ (libavcodec/avcodec.h libavformat/isom.c libavformat/mov.c): [21:17:49] <CIA-38> ffmpeg: pass QDMC extradata to the decoder [21:17:49] <CIA-38> ffmpeg: Makes playing QDMC files in MPlayer work when using the libavformat demuxer. [21:17:49] <CIA-38> ffmpeg: Problem was that the extradata was not passed from demuxer to decoder. [21:17:49] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:17:53] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * rb3190529df ffmpeg/libavformat/ (avformat.h utils.c): [21:17:53] <CIA-38> ffmpeg: Make av_set_pts_info keep previous time base if new one is invalid. [21:17:53] <CIA-38> ffmpeg: Fixes issue 2475. [21:17:53] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:18:29] <BBB> elenril: that's fantastic, a real contribution from him, that's exactly what we wanted :) [21:18:32] <BBB> (not even joking!) [21:22:35] <elenril> libavformat/mpeg.c:405:17: warning: implicit declaration of function 'ff_reduce_index' is invalid in C99 [-Wimplicit-function-declaration] [21:22:40] <elenril> who did that? [21:22:58] * elenril found this while searching for more includes he missed [21:23:19] <spaam> maybe arpi wants to join the ffmpeg team ;D [21:24:53] <thresh> or have a right of voice in fflames [21:24:58] <BBB> elenril: you, you moved ff_reduce_index from avformat.h to internal.h [21:25:03] <BBB> elenril: I didn't apply that yet [21:25:23] <elenril> oops :) [21:25:38] * BBB slaps elenril [21:25:50] <elenril> but we have so many warnings [21:26:26] <BBB> 2>&1|grep ff_reduce or 2>&1 | grep ff_the_other_symbol [21:26:30] <jannau> that's supposed to be an error [21:26:52] <elenril> i did grep implicit now [21:27:10] <jannau> get a compiler which supports -Werror=implicit-function-declaration [21:27:35] * elenril uses clang [21:27:38] <elenril> it has nice colors [21:28:17] <spaam> so thats why you use it? :) [21:28:25] <elenril> of course [21:28:33] <drv> colorgcc ;) [21:28:43] <elenril> is there any other factor in choosing a compiler? [21:29:06] <spaam> i dont think so [21:31:48] <BBB> elenril: generates faster code? [21:31:56] <BBB> then again who needs fast code [21:32:13] <elenril> fast code is overrated [21:44:55] <_av500_> home [21:58:13] <jannau> currently 13 minutes late but 1/2 coach for me alone

1 0

IRC log for 2011-02-05
by irc＠mansr.com 06 Feb '11

06 Feb '11

[00:00:09] <michaelni> ohsix, key is if its not fun one doesnt do it and rather leaves or whetever [00:00:39] <Sean_McG> y'know, something as simple as formatting could be enforced with a commit-hook [00:00:44] <ohsix> fun doesn't have any part with it [00:01:06] <ohsix> you can't get people to do things for fun; or if you can it all gets done, then the rest that needs to be done is decidedly not fun [00:01:11] <michaelni> ohsix, i wrote FOSS for fun or money [00:01:29] <michaelni> 99% fun [00:01:36] <michaelni> 1% money [00:02:00] <michaelni> if you take the fun away i loose interrest and iam not the only one [00:02:07] <ohsix> maybe your usage of the word fun doesn't match mine; i find it entertaining, but it's different from fun, whether i'm being paid or not [00:02:22] <ohsix> it's stimulating [00:02:29] <michaelni> ohsix, maybe yes fun is the wrong word [00:02:43] <kierank> michaelni: worth keeping in mind that in spite of issues in the community, ffmpeg is still a world class toolkit [00:02:49] <kierank> nothing even comes close to it [00:03:07] <Sean_McG> agreed [00:03:12] * michaelni thinks rm -rf beats ffmpeg [00:03:25] <Sean_McG> well, that trumps *anything* really :P [00:03:29] <ohsix> feature branches ftw [00:03:36] <ohsix> fighting over the tree isn't worth it [00:03:49] <The_Tick> ohsix: I find working on oss fun [00:03:52] <kierank> and as trite as it might sound it makes hundreds of millions of people's lives easier (they don't have to fumble with codecs they don't understand with vlc etc) [00:04:08] <{V}> michaelni, must be multiple rm -rf 'cause of all the mirrors and repos :) [00:04:09] <The_Tick> ohsix: I think trying to make someone simply be definitive on why they work on something [00:04:12] <The_Tick> is not helpful [00:04:25] <The_Tick> I think michaelni has a point that if he doesn't find it fun anymore [00:04:30] <ohsix> The_Tick: i was just making allusions to the fact that there are lots of things that are not fun that need to be done to progress, can't let one block [00:04:31] <The_Tick> that he doesn't want to do it [00:04:41] <michaelni> The_Tick, yes [00:04:43] <The_Tick> ohsix: and people like me [00:04:46] <The_Tick> like doing those things [00:04:47] <kshishkov> The_Tick: that's obvious, he hardly does any hard work anymore [00:05:03] <michaelni> and people kicking me out like this also is really not making me want to stay for longer than i have to [00:05:16] <ohsix> but it's a personal decision to do or not do something; i don't see whats so dramatic about running out of steam on something [00:05:29] <ohsix> once you step back for a while you find new things to do with freshened eyeballs [00:05:38] <The_Tick> ohsix: or you stop working on it [00:05:40] <kierank> michaelni: the "kicking out" was not a reflection of the quality of your work but of your leadership style [00:05:45] <The_Tick> ohsix: and then projects die [00:05:50] <ohsix> well, you do stop working on it [00:06:15] <ohsix> and projects that die are ones that aren't already self sustaining or a large enough chunk that it can't be written off and replaced wholly [00:06:23] <The_Tick> michaelni: so essentially you think people are being too hard on themselves and you, making the project feel more like work? [00:06:43] <The_Tick> sorry I lagged out so I did miss some conversation [00:06:45] <ohsix> theres another type of death thats transformative in the OSS world, too; it's cathartic [00:07:09] <iive> kierank: there was absolutely no reason to not give michael committer/puller/reviewer status. the leader position would still have been eliminated. [00:07:23] <michaelni> iive, exactly [00:07:43] <michaelni> the move was nothing but a very very strong insult [00:07:45] <The_Tick> kshishkov: regardless, he obviously has some value to the project otherwise you guys would have picked him out as a poisonous person and ejected him [00:08:12] <kierank> iive: i agree mostly but I guess the reason was that they didn't want michael to continue (in their view) flouting the rules [00:08:13] <ohsix> you know a committer/reviewer/puller isn't a position to obstruct everything, or even have technical arguments against things [00:08:24] <ohsix> they're a functionary for moving things to a blessed tree [00:08:28] <kshishkov> The_Tick: like he feels we did? [00:08:35] <The_Tick> kshishkov: most likely, yes :) [00:08:38] <iive> kierank: what rules? [00:09:04] <kierank> iive: commiting without review [00:09:05] <michaelni> ohsix, like all the cosmetics&restructuring without asking file maintgainers [00:09:21] <The_Tick> kshishkov: how do you view what you guys did? [00:09:27] <ohsix> submission dread; or thinking that effort you spend will never be returned is a bad thing [00:09:29] <iive> kierank: can you give example of michael doing that in the last 2 months? [00:09:40] <The_Tick> guys, hold on [00:09:42] <ohsix> the idea of a file maintainer is foreign to me [00:09:47] <kierank> iive: i'm not saying that's my opinion. i'm saying that's their opinion [00:09:57] <kshishkov> The_Tick: I think we did the right thing, that's why I supported it [00:10:08] <The_Tick> kshishkov: what do you view that you guys did? [00:10:09] <michaelni> ohsix, someone who know the code like the author and who works on it [00:10:20] <The_Tick> *sigh* [00:10:23] <ohsix> and if they don't "work" on it? [00:10:40] <The_Tick> ohsix: what you're asking isn't helping [00:10:43] <ohsix> the maintainers i'm familiar with do integration work; not development or review [00:11:24] <ohsix> that's why it's a foreign concept; cosmetic and structual changes aren't something a maintainer cares about [00:11:26] <The_Tick> specifically the point of this is for each person on either side to see the exact opinion of the other person on the same subject [00:11:41] <The_Tick> which essentially helps 99% of the time [00:11:46] <kierank> I think the most important thing that needs to happen is that the shit-slinging that's happened over the past few weeks needs to be put behind us [00:11:58] <The_Tick> kierank: which is what I'm attempting to help with [00:12:07] <The_Tick> so, back to my question [00:12:10] <ohsix> i'm just larting my pet goat, attracting and keeping contributors is prime; they're the one thats going to foster productive happenings [00:12:15] <The_Tick> kshishkov: what do you view that you guys did? [00:12:42] <kshishkov> ohsix: which project is that? [00:13:23] <ohsix> kshishkov: the ones with actual maintainers :D debian/redhat/ubuntu [00:13:44] <kshishkov> ohsix: that's slightly different project IMO [00:14:02] <ohsix> it's a completely different project, but there's not a large and arbitrary definition of a maintainer [00:14:58] <ohsix> in linux, there's "ATA maintainers" and other subsystem maintainers, but they're also nto concerned with cosmetics and restructuring unless they're doing it, or guiding it themselves [00:15:29] <ohsix> they just make it fit for purpose, act as a contact for broad issues with the subsystem; and triage [00:15:41] <kshishkov> The_Tick: I think I've mentioned what we did [00:15:43] <ohsix> they have pet trees but they still roll patches like anyone else [00:16:31] <The_Tick> kshishkov: I want michaelni to see it [00:16:45] <The_Tick> kshishkov: essentially he has a different opinion of the same actions [00:16:46] <ohsix> if something is literally going to explode, or didn't account for something, or is plain wrong they'll say something to that effect, but otherwise they're not a position to judge the fitness or novelty of the change [00:17:00] <The_Tick> and you guys need to reconcile that, or you'll continue to have problems [00:17:05] <ohsix> ie. aren't an automatic blocker or impediment [00:17:17] <The_Tick> I've had people drop out of projects for less percieved sleights [00:18:30] <ohsix> you can't account for taste [00:18:45] * Sean_McG sighs [00:19:14] <iive> kshishkov: would you repeat what you think you all did? I don't see it in the back log, and "the right thing" is too vague. [00:20:00] <kshishkov> iive: grew tired of the way FFmpeg was developed and restarted it with new set of rules [00:20:22] <iive> that's all? [00:20:26] <michaelni> kshishkov, i can agree with this [00:20:46] <ohsix> why fight over the carcass; this is what forks are for [00:20:54] <The_Tick> ohsix: forks always die [00:21:05] <ohsix> eh, no [00:21:23] <ohsix> you might be thinking high school or little kids playing around projects, and the indigant fork [00:21:24] <kshishkov> iive: those are facts, the rest is opinions [00:21:48] <The_Tick> ohsix: I don't know what projects you've been a part of, but if they have less than 10 people on them, then you aren't privy to this sort of problem most likely [00:21:49] <iive> kshishkov: the problem is that more things were done, than changing the rules. [00:22:02] <ohsix> projects that don't fork for spite; or fork to actually get anything done succeed in some measure, even if that is being adsorbed back into the primary project some time down the road [00:22:05] <{V}> The_Tick, stop talking about forks man. Spoon! :p [00:22:09] <kshishkov> iive: please list them [00:22:10] <The_Tick> nor how "omg contributors! patch writers!" isn't going to help [00:22:15] <kshishkov> {V}: sporks [00:22:23] <iive> kshishkov: kicking michael out of the project. [00:22:44] <ohsix> The_Tick: if a project is flagging and dying it's all about what you do about that [00:23:08] <kshishkov> iive: that's your and/or his opinion. He has repo with admin rights and he's still considered developer [00:23:29] <iive> kshishkov: not in the "reboot" [00:23:38] <iive> it is fact. [00:23:41] <michaelni> kshishkov, i have the main tree you ahev a dieing fork ;) [00:24:03] <ohsix> The_Tick: there are already a handful of de-facto forks; patches that wont get in and separate trees that wont get merged [00:24:06] <kshishkov> iive: nope. He just don't have privileges there [00:24:17] <kshishkov> michaelni: as you like [00:24:38] <The_Tick> ohsix: it's unfortunate that because of differing opinions and the capability to simply make a copy of the source code and host it somewhere [00:24:40] <ohsix> now that's the spite i'm talkin' about :] [00:24:46] <The_Tick> that people simply can't work together that have in the past [00:24:49] <michaelni> ohsix, i could merge them if people hadnt pissed me off that much and would have asked me to merge them [00:25:08] <The_Tick> we're likely going to have to freeze where we are in the ffmpeg version we have [00:25:08] <ohsix> The_Tick: of course it is, but those are i'm sure the forks you're alluding to when you say they always fail [00:25:12] <The_Tick> and look for alternatives [00:25:15] <The_Tick> this is disappointing [00:25:22] <ohsix> those aren't a serious effort in the first place [00:25:22] <The_Tick> you guys are all adults, you should act like it [00:25:55] <The_Tick> I don't want to spend my time trying to figure out your drama, but I have to because the project I love depends on it [00:26:14] <ohsix> welcome to the jungle [00:26:36] <The_Tick> this is all petty nonsense, and all of you know it [00:26:57] <The_Tick> it all distracts from actual work [00:27:02] <ohsix> that's not going to be very convincing [00:27:09] <ohsix> they're already distracted from actual work [00:28:30] <The_Tick> you guys need to talk about how to resolve this and move on [00:28:38] <The_Tick> I've tried to facilitate that [00:28:50] <The_Tick> but it's obvious that I'm wasting my time [00:29:01] <ohsix> check your messages first [00:29:09] <The_Tick> ohsix: I am, you're obnoxious [00:29:09] <iive> The_Tick: not you don't [00:29:26] <iive> The_Tick: making people talk is the first step. [00:29:32] <ohsix> i may be obnoxious but i've been here [00:29:40] <michaelni> The_Tick, i agree with iive what you do is not useless [00:29:55] <kshishkov> iive: are people in Bulgarian government not talkative? [00:29:57] <The_Tick> then what can we do to resolve this? [00:30:06] <michaelni> i dont know [00:30:12] <The_Tick> if this were an svn repo [00:30:17] <The_Tick> the actions you guys took [00:30:23] <The_Tick> would not have been an option as easily [00:30:33] <The_Tick> this cannot be a constant threat for any member of your team [00:30:38] <Compn> spoon! [00:30:40] <The_Tick> a year from now if someone disagrees with you [00:30:45] <The_Tick> they cannot think in the back of their head [00:30:45] <iive> kshishkov: there was one party that made that their policy. they didn't got enough votes to enter parlament on these elections. [00:30:50] <The_Tick> that if they are so disliked [00:30:54] <kshishkov> Compn: have you seen The Matrix? [00:30:56] <The_Tick> that they would be removed from the project in this fashion [00:31:00] <iive> and they were rulling like 8 years ago. [00:31:00] <ohsix> svn doesn't rule out a git-svn clone :] [00:31:06] <The_Tick> this is not acceptable behavior for anyone who works on a project [00:31:17] <The_Tick> ohsix: this is not helping [00:31:20] <The_Tick> ohsix: please stop [00:31:48] <michaelni> ohsix, yes please fuck with us later nit now [00:31:50] <The_Tick> you guys need to grow up, and resolve this like grown ups [00:32:24] <Compn> michaelni : i thought you were, maybe i am wrong... [00:32:36] <ohsix> it's not my fight :] [00:32:37] <Compn> kshishkov : yes, matrix, why ? [00:32:39] <iive> The_Tick: the problem so far seems that this kind of effort is one sided. The other side took what they wanted and don't see any gain from participating. [00:32:50] <The_Tick> then it's simple [00:32:54] <The_Tick> remove them from the project [00:32:59] <The_Tick> until they decide to play nice [00:33:06] <ohsix> heh [00:33:14] <The_Tick> someone please +q ohsix [00:33:15] <Sean_McG> there's an idea [00:33:31] <The_Tick> Sean_McG: unfortunately one group already did that [00:33:36] <kshishkov> Compn: for one spoon quote of course! [00:33:41] <Sean_McG> FOSS only works when everyone is playing nice in the sandbox. [00:33:42] <Compn> oh [00:33:50] <Compn> kshishkov : no, the spoon quote is from the tv show 'the tick' ... [00:33:52] <The_Tick> Sean_McG: agreed [00:34:26] <kshishkov> Compn: and cake quote is not from Portal either? [00:34:47] <Sean_McG> yes, "the cake is a lie" is from Portal [00:34:50] <Compn> which cake quote? but probably portal yes :P [00:35:20] <The_Tick> I have an idea for how to resolve this [00:35:23] <ohsix> q is not for me; i stopped as asked [00:35:25] <Sean_McG> (on a completely unrelated note, why does openssl hate me so much?!) [00:35:26] <kshishkov> Sean_McG: and "there's no spoon" is from what show? [00:35:31] * Sean_McG sighs, bangs head from table [00:35:37] <Sean_McG> kshishkov: that's from the first Matrix movie [00:35:45] <The_Tick> the main problems as I see it are management [00:35:51] <kshishkov> Sean_McG: tell that to Compn [00:36:02] <The_Tick> someone to handle infrastructure who isn't a person who actually manages the project [00:36:03] <Sean_McG> Compn: consider yourself told! ;) [00:36:24] <The_Tick> and a reorganization of the repositories [00:36:27] <kshishkov> Sean_McG: also XKCD claims Matrix was only one movie [00:36:32] <The_Tick> so that you have a single main tree [00:36:37] <ohsix> xkcd is right [00:36:42] <Sean_McG> kshishkov: in 3 parts? I could agree with that. [00:36:45] <Compn> i just said 'spoon' not 'there is no spoon' [00:37:03] <Sean_McG> Mister Anderson. [00:37:12] <ohsix> once you figured out what the matrix was and they started coming up with new sequel lore it was over [00:37:19] <Compn> i watched lord of the rings and never stopped saying mister anderson after every line [00:37:35] <Sean_McG> Compn: hahahah [00:37:42] <ohsix> theres a drum & bass album that has the movies edited together Compn [00:37:43] <michaelni> The_Tick, someone to handle infrastructure is diego & mans replacing them has not been successfull [00:38:17] <iive> that's the roots we were talking in the beginning. [00:38:46] <michaelni> They are good friends of the new team ... [00:38:55] <Sean_McG> why is mans not a part of this conversation? [00:39:05] <The_Tick> michaelni: replacing them is not the point [00:39:11] <The_Tick> michaelni: are these people developers? [00:39:14] <kshishkov> probably he's enjoing life at FOSDEM now [00:39:15] <iive> he may be sleeping, or traveling. [00:39:18] <michaelni> mans yes [00:39:21] <Sean_McG> oh, fair point [00:39:22] <ohsix> Sean_McG: 10 hours idle probably has something to do with it [00:39:25] <michaelni> diego develops only whitespaces [00:39:30] * The_Tick sighs [00:39:32] <kshishkov> Sean_McG: also he's tired of these conversations [00:39:33] <The_Tick> michaelni: it's comments like that [00:39:38] <The_Tick> passive aggresive comments [00:39:42] <Sean_McG> kshishkov: oh, crap. [00:39:50] <The_Tick> which do not help you [00:39:58] <{V}> The_Tick, remerging the two primary repos has already been suggested. In fact, it was my primary objective when I had a go at trying to find a compromise to take us out of this mess [00:40:05] <iive> The_Tick: Diego entered mplayer as documentation maintainer. [00:40:06] <michaelni> The_Tick, diego doesnt write C he never did, i had not intended to be sgressive but i see i was [00:40:18] <ohsix> why not let them breathe a while and see what actually happens [00:41:05] <kshishkov> he worked on build system at least [00:41:29] <ohsix> he can be reasoned with too, that's a huge plus [00:41:52] <iive> ohsix: not really. [00:41:57] <The_Tick> essentially you guys need someone to manage the project [00:42:02] <The_Tick> that isn't part of the whole politics [00:42:06] <The_Tick> so you guys can focus on code [00:42:17] <ohsix> iive: i'm prejudiced by a small success in doing so [00:42:22] <iive> The_Tick: yep, and somebody who everybody would respect. [00:42:45] <michaelni> And someone who would do that volunteerly [00:42:45] <The_Tick> iive: someone they wouldn't have to question the motives of [00:43:05] <The_Tick> michaelni: it's kind of what I do for perian and growl, and what I did for adium [00:43:31] <ohsix> it's worth noting, software can be stable, and not dead [00:43:46] <ohsix> flagrant comma abuse; my bad [00:43:54] <ruggles> The_Tick: what kinds of project management things are you referring to [00:44:06] <Sean_McG> I'm not sure what you're trying to add to the conversation, ohsix. [00:44:35] <The_Tick> ruggles: in general, keeping the infrastructure running, resolving disputes, setting the guidelines for going forward usually [00:44:51] <The_Tick> so this whitespace thing would have been a 10 minute conversation on my projects [00:45:04] <The_Tick> I would have had the person having issues make sure the coding document is up to date [00:45:10] <The_Tick> and that all devs agreed to that [00:45:11] <Sean_McG> it has been stretched to rather absurd proportions [00:45:13] <The_Tick> and that'd solve the problem [00:45:34] <The_Tick> generally if you use tabs for whitespace, everyone can set their editor to whatever they want for whitespace, for instance [00:45:43] <relaxed> So you're here to promote yourself as FFmpeg's project manager? [00:45:44] <ohsix> Sean_McG: o noes [00:45:46] <The_Tick> ruggles: also making sure developers get up to date hardware [00:45:48] <The_Tick> relaxed: no [00:45:53] <The_Tick> relaxed: I'm too busy [00:46:08] <The_Tick> relaxed: I have a 10 month old son, a full time job and I manage 2 projects already [00:46:24] <The_Tick> relaxed: he asked what I do [00:46:24] <michaelni> The_Tick, tabs vs space is easy we have space after specific keyword rules :) [00:46:32] <ohsix> people don't need to agree either, as long as it's not punitive and needlessly fluid [00:46:54] <Sean_McG> michaelni: and again as I pointed out, tab/space can be enforced with commit hooks :P [00:47:12] <The_Tick> michaelni: in general if everyone else agrees with that [00:47:14] <The_Tick> you're wrong [00:47:15] <michaelni> Sean_McG, yes i have no problem with tab vs space that one makes sense [00:47:31] <The_Tick> and you need to get over yourself and not make things big issues [00:47:59] <ohsix> Sean_McG: you can also put headers in the file that tell the editor what the formatting is supposed to be [00:48:00] <michaelni> The_Tick, the rules are documented by the output of indent IIRC :) [00:48:08] <Sean_McG> ohsix: that too. [00:48:19] <The_Tick> ruggles: I'd be happy to help resolve disputes if that's needed on a say, 2 hour basis per week [00:48:21] <Sean_McG> ohsix: provided everybody uses an editor that respects that. [00:48:27] <The_Tick> but that's the extent of what I could spend on ffmpeg itself [00:48:39] <The_Tick> or whatever [00:48:39] <michaelni> The_Tick, we need 2weeks per hour i fear ;) [00:48:49] <uau> The_Tick: "resolving disputes" may not be so easy, and anyone familiar enough with the code to do that well probably isn't an "neutral outsider" [00:48:54] <ohsix> Sean_McG: well, worrying about that is for the person who would edit the file, the file is neutral and does its best effort to lay down the law ;] [00:49:01] <The_Tick> uau: indeed [00:49:07] <uau> and same for "setting guidelines for going forward" [00:49:29] <The_Tick> uau: which is helpful since I'm not a coder and I force coders to make things easier for me to understand [00:49:46] <The_Tick> which makes the problem easier to agree upon [00:49:50] <The_Tick> typically :) [00:50:10] <The_Tick> anyhow, that's essentially what I do [00:50:25] <The_Tick> luckily with 2-3 people on perian, we don't have the problems of larger projects [00:50:43] <The_Tick> but I had a large number of committers on Growl, and I don't miss the 3 day arguments about a single checkbox [00:51:10] <ohsix> defer to a designer :] [00:51:24] * Sean_McG sighs, pulls out /usr/bin/truss [00:51:38] <The_Tick> ohsix: I'm not sure what you're adding to this conversation [00:51:42] <The_Tick> other people have said the same thing [00:51:50] <ohsix> letters and carriage reteurns [00:52:09] <The_Tick> ruggles, uau essentially I'm not interested in your code any longer though if you guys aren't going to get along [00:52:36] <The_Tick> so I need you to get along :) [00:52:43] <iive> The_Tick: I agree that in the end, there should be somebody to pick one solution over the other, even if it is not the perfect one. [00:52:58] <Sean_McG> thats what I think you call a mediator [00:53:11] <ohsix> i'm not party to your growl conversation; but theres someone whos' job it is to say if its appropriate, unless they're all designers, then theres TooManyCooks [00:53:14] <The_Tick> iive: I'm happy to be that person if you so need it [00:53:34] <kierank> [00:42] The_Tick: essentially you guys need someone to manage the project --> mpc-hc has this except a lot of the decisions revolve around code [00:53:34] <The_Tick> I'm not really really impartial since I'm involved in perian [00:53:48] <uau> The_Tick: what do you mean by "not interested in your code"? you'll stop using ffmpeg? [00:53:50] <The_Tick> kierank: but they can be talked about in a non-code way :) [00:53:55] <kierank> not all of them [00:54:05] <kierank> a lot of the things require a good level of understanding [00:54:07] <Sean_McG> but I think it'd be hard to find someone completely impartial [00:54:09] <The_Tick> uau: I mean that if you guys have a powerplay one month [00:54:17] <The_Tick> where someone commits code, then someone removes the commit [00:54:19] <The_Tick> back and forth [00:54:23] <ohsix> uau: he already alluded to freezing the version they use earlier [00:54:24] <The_Tick> I'm afraid of that [00:54:40] <The_Tick> and of not accepting beneficial patches [00:54:44] <The_Tick> we have a few [00:54:59] <The_Tick> hell, one of the listed trees is from astrange [00:55:01] <The_Tick> he's on perian [00:55:08] <michaelni> The_Tick, i accept all beneficial patches [00:55:21] <The_Tick> michaelni: but does everyone else [00:55:29] <michaelni> libmpcodecs ... [00:55:59] <The_Tick> do you guys have a list of who has what hardware, and a wya to use donations to help provide better hardware? [00:56:15] <The_Tick> like we bought stereo equipment, monitors, etc etc [00:56:20] <The_Tick> for people who needed them [00:56:23] <uau> The_Tick: OTOH that kind of "commit war" you're referring to is best avoided by NOT working on a common tree... [00:56:32] <ruggles> The_Tick: no we don't have such a list [00:56:34] <ohsix> uau++ [00:56:37] <The_Tick> uau: but in the end you don't get a released product [00:56:42] <Sean_McG> uau: which git helps to facilitate [00:57:01] <The_Tick> uau: it only fractures the team doing that [00:57:03] <ohsix> The_Tick: releases are still basically, pick a revision; roll with it [00:57:12] <The_Tick> ohsix: yes, then test it, then release it [00:57:15] <The_Tick> I know what a release is [00:57:21] <ohsix> but that's been improved as of late [00:57:36] <uau> The_Tick: yes it can "fracture" the team, but that doesn't mean it'd be a reason to freeze your use to the current version [00:57:37] <ohsix> The_Tick: no you misunderstand, i don't mean what ffmpeg does, i mean the people who consume ffmpeg [00:57:53] <The_Tick> uau: why not? I could avoid all of this mess entirely [00:58:01] <The_Tick> and figure out an alternative [00:58:20] <iive> maybe we should stay on topic. [00:58:24] <michaelni> The_Tick, if you find an alternative to ffmpeg tell me and ill join [00:58:34] <bryno> i've frozen my use of ffmpeg before the coup happened :( [00:58:59] <uau> why would freezing be an improvement? if there are multiple repos you could just pick one - if no opposed people share a repo there won't be commit wars, and the development is likely to be at least somewhat positive (better than using a frozen version) [00:59:18] <The_Tick> uau: which one do I pick that I don't need to spend time figuring out the politics? [00:59:27] <The_Tick> one repo has some changes [00:59:29] <The_Tick> others have others [00:59:33] <ohsix> michaelni: you probably wouldn't like any answers (or wouldn't accept them as an alternative :) [00:59:35] <The_Tick> I have to spend time figuring out what to have pulled [00:59:42] <The_Tick> why? [00:59:46] <iive> The_Tick: and you forgot conflicting changes :) [00:59:50] <The_Tick> you're wasting my developers time [00:59:52] <wooster> can't you just make branches? [00:59:54] <The_Tick> if you do that [01:00:18] <ohsix> uau has his own tree for his own stuff; i don't think he thinks he's wasting his time [01:00:38] <michaelni> The_Tick, i pull all features and bugfixes and everything else thats not worsening user experience from ffmoeg.org to ffmpeg@videolan [01:00:41] <The_Tick> and at some point that makes it into the main tree right? [01:01:03] <The_Tick> which is how branches are *supposed* to work, right? [01:01:14] <uau> The_Tick: i don't think it would be that hard to find at least one tree that's better than the "frozen" version [01:01:27] <ohsix> well theres a technical branch, which is something your source control does; and independent development [01:01:36] <The_Tick> uau: I don't disagree about better, from a technical perspective [01:01:41] <The_Tick> but say that's your tree [01:01:51] <The_Tick> and then a year from now you stop working on ffmpeg-uau [01:01:53] <ohsix> with git a branch is cheap and can either end up rebased on upstream or turned into a patch series; but it lives on its own [01:02:00] <The_Tick> now my project has to make a decision [01:02:15] <uau> the only ffmpeg tree i have has some minor tweaks (in case ohsix's comment confused someone) [01:02:40] <ohsix> i didn't mean to say you forked it or anything uau, it just wasn't useful to use myself as an example [01:02:42] <iive> i'm sorry but I'll be leaving the chat. [01:02:51] <{V}> bye iive [01:02:51] <michaelni> uau if you have patches or a tree to cherry pick from iam interrested [01:03:00] <The_Tick> uau: the point I'm making [01:03:13] <iive> kshishkov: don't forget to ask michael, if he will work with mans&diego on ffmpeg, if they are not roots anymore. [01:03:16] <The_Tick> is I want us to use the main tree+our patches [01:03:31] <The_Tick> I don't wnat to have to worry about the politics of the project [01:03:34] <The_Tick> for the main tree [01:03:46] <The_Tick> there shouldn't be politics for an oss project [01:03:47] <Dark_Shikari> BBB: which patch [01:04:05] <The_Tick> since you all likely want somewhat the same end goal [01:04:08] <kierank> there's politics in all walks of life [01:04:13] <The_Tick> so please get along so I don't have to think this way [01:04:14] <uau> michaelni: i changed optimization level from -O3 to -O2 (smaller binary, faster, and quicker to compile in my tests) and fixed a couple of errors in generated .pc files [01:04:22] <ohsix> iive: root means what it says on the tin right? [01:04:32] <Sean_McG> oh boy, libtool [01:04:35] * Sean_McG facefaults [01:04:55] <uau> Sean_McG: libtool? where? [01:05:07] <iive> n8 ppl [01:05:15] <The_Tick> anyhow, I've said my peace [01:05:17] <{V}> goodnight iive [01:05:21] <The_Tick> please figure out getting along [01:05:31] <The_Tick> I'll be happy to mediate if you guys need that [01:05:40] <Sean_McG> wait sorry I mean pkg-config [01:05:43] <Sean_McG> damn, I'm tired [01:06:12] <ruggles> The_Tick: thank you [01:06:16] <The_Tick> my email is chris(a)growl.info if anyone needs that [01:06:18] <Sean_McG> haven't had dinner yet either...maybe head out for pizza in a bit [01:06:42] <The_Tick> and I'm on freenode almost 24/7 idling :) [01:07:01] <michaelni> The_Tick, thanks for your attempts at helping :) [01:07:08] <uau> Sean_McG: you mean you'd have that reaction to pkg-config too, or was that due to the libtool confusion? (libtool would be far more deserving i think) [01:07:20] <Sean_McG> uau: the former. [01:07:35] <uau> why? pkg-config is by far the best solution there is [01:07:38] <Sean_McG> but pkg-config doesn't bring the pain as much as libtool does. [01:07:39] <Kovensky> it's lovely how the latest libtool release actually doesn't work [01:07:46] <Sean_McG> Kovensky++ [01:07:50] <Kovensky> I have to use trunk libtool [01:07:57] <Kovensky> for it to be slightly less broken [01:08:29] <Kovensky> I mean, it refused .a libraries because the objdump string wasn't exactly the one it grepped for [01:08:32] <Sean_McG> uau: but admittedly I cannot suggest an alternative. [01:08:47] <Kovensky> the difference was in one character IIRC [01:08:57] <Kovensky> either I fixed that regexp everywhere or I just used a new libtool <_< [01:09:07] <Sean_McG> you mean you aren't building all your libs *dynamically*? what's wrong with you?!! </sarcasm> [01:09:13] <Kovensky> one has to wonder wtf is libtool doing grepping .a though [01:09:20] <Kovensky> Sean_McG: no, that's the problem [01:09:24] <ohsix> uau: there's a default set of hates and gripes :] [01:09:33] <Kovensky> Sean_McG: given how distros are all obsessive compulsive about dynamic libs, they actually test that part of libtool [01:09:51] <Kovensky> static libs get shoved in the plan9 limbo :( [01:10:20] <Sean_McG> s/plan9/Duke Nukem Forever/? ;) [01:12:41] <ruggles> pross-au: nice patches :) [01:13:40] <{V}> Sean_McG, around the beginning of May, check to see if you need to find a new famous example of vapourware :) [01:14:14] <Sean_McG> {V}: so it's been suggested, but that trust has been violated so many times already :P~ [01:14:46] <Kovensky> Sean_McG: http://harmful.cat-v.org/software/dynamic-linking/ [01:15:15] <{V}> Sean_McG, yeah I certainly wouldn't start looking before May, if I were you :D [01:17:24] <ohsix> Kovensky: that carmack quote was talking about windows, heh [01:17:30] <ohsix> and getprocaddress [01:17:34] <Sean_McG> yeah [01:19:18] <ohsix> i like me some cat-v tho [01:27:16] <ohsix> all the footnotes and the article seem to completely sidestep licensing and stuff (probably rightly so, but it's worth a mention; even if it's not a technical reality but a reality reality) [01:27:26] <Sean_McG> "Of course it's kind [01:27:26] <Sean_McG> of interesting: Posix threads are used by 'date'. I had no idea that [01:27:28] <Sean_McG> printing a date could be so complex. Maybe that's why it's 40k" [01:27:33] * Sean_McG had to snicker at that one [01:35:24] <astrange> my /bin/date doesn't use pthreads [01:36:53] <drv> mine does and is actually 59K ;) [01:39:00] <astrange> cat-v is just some guy who reposts rob pike quotes that only apply if you think computers should be 3 xterms and no wallpaper [01:39:19] <ohsix> could be overlinking; date is in a large pile of utilities built with mostly the same cflags [01:39:31] <ohsix> astrange: that's a good way to put it [01:40:21] <Sean_McG> sean@mahoro:~$ ls -l `which date` [01:40:22] <Sean_McG> -r-xr-xr-x 1 root wheel 80848 18 May 2009 /bin/date [01:40:27] <Sean_McG> that's on OS X Snow Leopard [01:40:50] <ohsix> it's like reading cave meb wall paintings [01:41:19] <Sean_McG> -r-xr-xr-x 1 root bin 10840 Jan 22 2005 /usr/xpg4/bin/date [01:41:24] <Sean_McG> that's Solaris 10u8 x86 [01:41:29] <astrange> the 80kb date is tri-arch [01:41:33] <Sean_McG> aye [01:41:48] <beastd> And personal computers are a bunch of capable hardware with bloated operating systems and shitty applications that make possible the fanciest useless things while at the same time making you think your hardware is too slow. [01:42:22] <astrange> so 26kb or so x86-64, i don't feel like investigating further [01:42:49] <astrange> gnu utilities would be larger due to including locales and --version and stuff [01:43:06] <ohsix> ahh date links to stuff thats implicitly thread aware but isn't neccisarily used in such a manner in the linked application [01:43:24] <Sean_McG> that would make more sense [01:43:53] <astrange> BBB: http://pastebin.com/BFiJxArx rebased, i still see the failures [01:44:08] <ohsix> beastd: for all its largesse i don't recall waiting for date to do its thing [01:45:12] <beastd> ohsix: My statement wasn't necessarily aimed at date. Much more global. [01:45:58] <ohsix> mine wasn't either; thats just what everyone was looking at [01:46:07] <astrange> your hardware probably is too slow [01:46:13] <ohsix> all i wait for in like the last 6 years is firefox [01:46:18] <astrange> HDDs are very slow things and everything is blocked on them [01:46:30] <Sean_McG> yes, damn those spinning platters [01:47:27] <beastd> astrange: probably my hw is too slow for many things. but even for the things it would be good enough it so often can't be used. [01:47:55] <ohsix> i got by on a netbook for about 2 weeks; like as a proper daily driver [01:48:01] <ohsix> it just needed an extra gig of ram [01:55:45] <beastd> anyway, there is a lot more to the issue. google is trying to address it with chrome os but that is not the thing i am looking for (though for the bulk of users it will maybe is, there are some similarities in objectives like e.g. speeding up boot process but i visionary wise i am looking in the opposite direction). But it is OT here anyway (meaning i willl STFU now). [01:56:13] <ohsix> wat [01:57:11] <ohsix> everyone needs fast SSD's with a lot more pressure to swap stuff out; and XIP restore images for startup and deep suspends [01:59:48] <ohsix> if your disk is fast enough you can do some nutty things, ubiquitous flash storage is gonna be pretty trick in 15 years [02:06:43] <ruggles> what is below @subsection in texinfo? [02:07:08] <ruggles> chapter, section, subsection, ? [02:09:11] <ruggles> nevermind. found it. @subsubsection [02:10:01] * ruggles is writing encoders.texi for ac3enc AVOptions before sending a new patch [03:14:09] <BBB> astrange: I will compare to my tree [03:14:13] <BBB> astrange: it passes here [03:14:26] <BBB> astrange: thanks for rebasing [03:19:16] <ruggles> any suggestions for passing dB (decibels) in commandline arguments? currently dB means 0.1 bits... [03:25:12] <astrange> which arguments overload dB and bits? [03:25:52] <ruggles> none, but av_strtod() doesn't distinguish on a per-argument basis [03:26:23] <ruggles> currently B in the postfix means multiply by 8. [04:13:02] <astrange> in that case, what arguments overload dB and anything else? [04:13:14] <astrange> since you could pass "10" for 10 dB [04:13:38] <astrange> i guess dB and linear multipliers? [04:35:12] <BBB> astrange: I have the relevant changes under 1 page, I'll get you the "problem" tomorrow, do you have time to review and submit the -mt tomorrow? :) [04:36:33] <BBB> astrange: or wait, I've got it already [04:37:31] <BBB> astrange: http://ffmpeg.pastebin.com/aYmmY6V9 fixes make fate-vsynth2-wmv2 (and probably all others - untested) for me [04:38:11] <BBB> astrange: enjoy submitting the patch [04:39:33] <astrange> that'll make it draw edges twice for all decoding frames. but i'll do some gdbing and look at what state i can use [04:39:36] <astrange> s->encoding didn't work [04:42:08] <Sean_McG> gdb is a verb now? :P [04:47:24] <The_Tick> Sean_McG: it's attained google status [06:25:16] <pross-au> kshishkov: awake? [07:41:59] * elenril yawns [10:51:52] <_av500_> http://www.youtube.com/watch?v=fz_FmQ_v7Uw [11:49:30] <pross-au> _av500_: looks awesome [12:53:50] <_av500_> thx [13:02:34] <thresh> yeah looks cool [13:05:14] <_av500_> thresh: your man was not here yet [13:05:23] <BBB> astrange: ah, you sent patches, thanks :) [13:06:19] <thresh> _av500_: I can try texting him with your location, where is your booth? [13:10:31] <_av500_> thresh: in AW building [13:10:47] <_av500_> at the booth with the huge video wall [13:11:44] <thresh> ok sent [13:11:54] <kshishkov> wearing t-shirt with his nickname [13:12:41] <thresh> how's fosdem hangover this year? [13:16:51] <_av500_> thresh: not too bad, I was not there till 6am [13:17:00] <_av500_> mru gave up quickly [13:17:05] <_av500_> and so did i [13:28:01] <Compn> Dark_Shikari : i replied to your mail in the equality thread, hopefully explaining what michaelni was trying to get at in his mail [13:28:40] <Compn> michaelni : hopefully i've interpreted your mail correctly :) [14:20:48] <Flameeyes> wbs: lscube bugzy should come up again soonish... at the end I called Luca at fosdem since nobody else was around =_= [14:21:11] <kierank> is mru attending the autotools workshop? [14:22:15] <wbs> Flameeyes: ok :-) [14:31:54] <Flameeyes> kierank: oh god an autotools workshop? who the heck is supposed to handle that? [14:32:14] <ohsix> it's become self aware [14:32:57] <Flameeyes> ohsix: I just hope it's not one of those who pretended to know autotools when designing the kde3 build system [14:45:20] <lu_zero> Flameeyes: pg up again [14:45:39] <lu_zero> mru: where are you? [14:45:50] <Flameeyes> lu_zero: thanks — am I supposed to have access to that box, you sais? [14:46:01] <Dark_Shikari> http://i.imgur.com/XvEz6.png [14:48:39] <Dark_Shikari> Is it just me, or is there no AV_RL32A? [14:48:45] <Dark_Shikari> What's with that? [14:53:01] <Dark_Shikari> mru: any reason for this? [14:53:23] <Dark_Shikari> BBB: ping [15:02:36] <Dark_Shikari> ok, I had a batshit crazy idea. this is just insane, but might just work. [15:02:53] <Dark_Shikari> in x264, we use trailing zero count to loop over nonzero coefficients in a dct block, while skipping the 0s [15:03:06] <Dark_Shikari> thus making performance O(num nonzero coeffs) instead of O(last nonzero coefficient). [15:03:20] <Dark_Shikari> ... how about, in ffmpeg, doing this to loop over coded 4x4 dct blocks? [15:03:43] <Dark_Shikari> so if there's 3 coded dct blocks out of 16, it does 3 trailing zero counts on a mask of nnz values, skipping through them rapidly. [15:03:55] <Dark_Shikari> (vp8, h264) [15:33:33] <Dark_Shikari> Well, here's the incredibly evil/ridiculous code: [15:33:36] <Dark_Shikari> x = 0; [15:33:36] <Dark_Shikari> while( nnz4 ) { [15:33:36] <Dark_Shikari> int shift = __builtin_ctz( nnz4 ) >> 3; [15:33:36] <Dark_Shikari> x += shift; nnz4 >>= (shift << 3); [15:33:36] <Dark_Shikari> if ((nnz4&0xFF) == 1) s->vp8dsp.vp8_idct_dc_add(y_dst+4*x, s->block[y][x], s->linesize); [15:33:39] <Dark_Shikari> else s->vp8dsp.vp8_idct_add (y_dst+4*x, s->block[y][x], s->linesize); [15:33:43] <Dark_Shikari> nnz4 >>= 8; x++; [15:33:45] <Dark_Shikari> } [15:34:07] <Dark_Shikari> using a trailing zeroes loop for idct... makes me want to puke. [15:35:36] <mru> beware, trailing zeros isn't always a single insn [15:35:47] <mru> depends on cpu [15:35:47] <Dark_Shikari> I know [15:38:09] <Dark_Shikari> This would probably be more useful in h264 [15:38:23] <Dark_Shikari> because vp8 tends to have dc coefficients in every block due to the higher precision of the dc quant [15:38:28] <Dark_Shikari> and the hierarchical transform [15:38:52] <iive> Dark_Shikari: doesn't skipped blocks have dc component on their own? [15:38:55] <Dark_Shikari> ? [15:40:44] <iive> I'm not familiar with h264 working. But in the code above when you handle nnz4 you do either idct_add or idct_dc_add [15:41:03] <Dark_Shikari> Yes. [15:41:03] <iive> so I would assume that the skipped blocks should be handled with idct_dc_add too. [15:41:10] <Dark_Shikari> No... the skipped blocks have no DC at all. [15:41:15] <Dark_Shikari> Note the while loop SKIPS over them [15:41:17] <Dark_Shikari> because of the ctz [15:41:33] <Dark_Shikari> the original code does [15:41:45] <Dark_Shikari> if( nnz) { if(nnz==1) {idct_dc} else {idct} } [15:41:52] <iive> i was asking if this is the intension. [15:42:01] <Dark_Shikari> Yes, the intention is to skip empty blocks. [15:42:39] <Dark_Shikari> By virtue of being empty, empty blocks can be skipped. [15:43:13] <iive> aha, so nnz4 is 4 different variables combined into 1? [15:43:25] <Dark_Shikari> yes [15:43:30] <Dark_Shikari> uint32_t nnz4 = AV_RN32A(s->non_zero_count_cache[y]); [15:43:35] <Dark_Shikari> `-` [15:44:03] <Dark_Shikari> nb: my code obviously breaks on bigendian atm [15:48:54] <Dark_Shikari> hmm, interesting thought... [15:48:59] <Dark_Shikari> we can fit 16 nnz values in a uint32_t [15:49:12] <Dark_Shikari> because nnz is either 0, 1, or >1 [15:55:41] <kierank> av500: troll hunter now has english subtitles [15:55:48] <kierank> _av500_ : i mean [16:07:49] * Compn wonders why Dark_Shikari didnt read whole email :( [16:35:55] * Sean_McG returns [16:36:24] <Sean_McG> for a short bit anyways...gonna go out for breakfast methinks [16:36:45] <Flameeyes> wbs: ah sorry there is a branch in which we reworked http tunnels [16:36:54] <Flameeyes> they _should_ work now, if you can try them we'd be delighted :) [17:08:25] <wbs> Flameeyes: oh, which one do you want me to test? http-tunnel-threads or -v2? [17:08:52] <Flameeyes> -v2 please [17:11:14] <wbs> ok, I'll test it in a while. since the current master seems to work for me at the moment, I guess it's hard to say if it really works better or not, but I can at least find out if it's more broken or not :-) [17:33:33] <mmu_man> plop [17:34:04] <_av500_> mmu_man: hows fosdem? [17:38:37] <mmu_man> nice [17:38:42] <mmu_man> crowded as always [17:38:50] <mmu_man> but you know :p [17:45:14] <_av500_> yeah [17:48:59] <kierank> _av500_: did you go to the autotools talk? [17:53:02] * elenril wonders if he should bother reading the drama [18:14:09] <Sean_McG> ahahahah oh snap... "the Verizon iPhone is really good at holding on to calls, if you're into that kinda thing" [18:42:27] <Compn> are ffmpeg devs getting lots of questions at fosdem ? [18:54:57] * elenril lols@DonDiego's mail [18:55:04] <elenril> "Vive la revolution!" << awesome [18:57:05] <Compn> alienating a bunch of devels is awesome ? [18:58:33] <wbs> Flameeyes: agh, my libev (the latest in debian unstable) doesn't have EVRUN_ONCE defined [19:08:26] <lu_zero> Compn: that could be read in two different ways [19:09:06] <lu_zero> wbs: which version it is? [19:09:36] <wbs> lu_zero: 3.9 [19:10:28] <lu_zero> uhm I wasn't planning to use already the 4.0 stuff... [19:11:54] <Compn> lu_zero : thats why i asked elenril to clarify [19:15:12] <lu_zero> Compn: elf followed by vlr, that's pretty in line [19:15:46] <lu_zero> the question is, which of the two expression would alienate who? [19:20:34] <Compn> erm, overall attitude i would say instead [19:20:56] <Compn> e.g. responding to sigs , ignoring content of main message, etc [19:21:06] <Compn> if you are asking who left, you can look at ramiro [19:22:09] <Compn> i dont know who else left, i am not prepared with a list. [19:39:30] <BBB> Compn: to the best of my knowledge, ramiro is at fosdem discussing (hopefully) with the rest of the team? [19:40:23] <Flameeyes> wbs: damn.. okay need to see if I can avoid using that :/ [19:40:39] <BBB> iive = ivan kalvachev? [19:41:28] <Compn> BBB : good (if true) [19:41:40] * Compn is not in any loops and knows nothing [19:42:33] <Compn> yes iive is ivan [19:42:38] <BBB> and yes I know various people are annoyed, I'm not blind or deaf, I'm listening and hoping to do whatever's best for FFmpeg also. doing a vote between "kill me now" or "let's hang michael" is not in my list of "best for FFmpeg" [19:42:57] <BBB> cut the ridiculous crap with these votes please [19:43:06] <Compn> who are you talking to btw ? [19:43:17] <Compn> well, i guess michaelni is here [19:43:35] <iive> BBB: doing something with best intentions is not always doing the best thing. [19:44:27] <BBB> iive: could I please kindly request that you refrain from "contributing" to all these trollwars-to-be and leave that to the people that the discussion is actually about, i.e. the actual developers? thank you [19:44:46] <Compn> iive has code in ffmpeg iirc ? [19:44:50] <iive> BBB: I am actual developer. or at least used to be. [19:45:08] <iive> and I am maintainer. one or 2 files but still. I am. [19:45:23] <Compn> xvmc stuff ? [19:45:29] <iive> yep. [19:45:52] <BBB> that's great, but your comments aren't helpful, they're flamy, trolly and generally not helpful. it's BS rethoric. please don't [19:46:42] <iive> BBB: I try to keep them to the minimum. [19:47:10] <Compn> iive speaks his mind :) [19:48:02] <iive> BBB: have you actually lived under dictatorship? [19:50:10] <BBB> iive: please stop the rhetoric, again [19:50:52] <BBB> I'm said the same to michael in private, either say nothing or work towards a solution. don't troll. I won't listen, and neither will anyone else. you're just making it more likely that I'll stop listening to you altogether [19:51:09] <BBB> I don't care that someone in some country far, far away lived under a dictatorship because THAT IS NOT THE ISSUE HERE [19:51:14] <BBB> please see that [19:51:18] <BBB> then stop responding uselessly [19:51:28] <BBB> and contribute, if at all, in a useful and constructive manner [19:51:33] <BBB> so again, stop trolling, thank you [19:53:19] <iive> in order to work towards a solution, we should know what is the problem first. [19:53:37] <BBB> Dark_Shikari: that an interesting idea, if there's indeed correlation between neighbouring blocks being more likely than purely random to be zero... not sure if that's the case for vp8... can that be measured? [19:54:17] * BBB decides to stop listening to the rhetoric BS from iive [19:58:02] <elenril> isascii() is locale-independent, right? [20:00:41] <BBB> seems so from the manpage [20:01:24] <elenril> maybe i shouldn't bother with it anyway and just write my own :/ [20:11:03] <BBB> michaelni: opinions on "[PATCH 1/6] Adopt pkt_dts/pkt_pts in lavc clients"? it seems simple enough to me [20:11:26] <BBB> elenril: should be ok really, why don't you want to use it? [20:11:37] <uau> BBB: threading is a real issue [20:12:01] <uau> people haven't used it much in mplayer svn because it doesn't work for most h264 videos anyway [20:12:30] <uau> i disabled thread callbacks in mplayer2 (which i think most people needing multithreading have already been using, though not under that name) [20:12:38] <uau> and that was necessary [20:12:45] <elenril> BBB: dunno, i have an irrational distrust for them ;) [20:16:06] * elenril kicks freenode [20:16:23] <elenril> arrrgh, who told this system to accept RAs [20:17:14] <BBB> uau: uh, that sucks :) [20:17:27] <BBB> so you're telling me slice-based MT isn't really tested much [20:18:27] <uau> BBB: yes - slice-based is pretty much useless (as it only works for stuff like mpeg2 which doesn't need performance) [20:18:37] <uau> no form of threading has been tested much with svn [20:18:51] <Compn> roo had svn mt builds for a while [20:18:59] <BBB> I thought slice-based h264 was used for low-latency stuff [20:19:00] <Compn> also i think sherpya did svn-mt too [20:19:03] <uau> there have been a reasonable amount of people (at least hundreds) using mplayer2 with ffmpeg-mt [20:19:16] <uau> and that has worked without many complaints [20:19:39] <uau> (with callbacks disabled with threading) [20:20:28] <uau> BBB: there are some sliced h264 videos [20:20:30] <Compn> http://oss.netfarm.it/mplayer-win32.php [20:20:31] <BBB> I guess I had always assumed that it worked since it was out there and mplayer people tend to compain a lot about this kind of breakage [20:20:48] <BBB> uau: not just videos, dark_shikari's company uses it too and I thought it worked for them [20:20:56] <uau> but i think few people enable threading with those [20:21:14] <uau> because 1) testing slice-based threading with most videos shows no benefit, only breakage [20:21:17] <BBB> sucks :-p [20:21:29] <Compn> anyways, dont worry about mplayer [20:21:31] <BBB> please define breakage? [20:21:36] <Compn> if ffmpeg-mt breaks something, it will get fixed [20:21:41] <Compn> dont wait for mplayer to merge it [20:21:47] <uau> and 2) people who really need multithreading and know enough to search for manually-set options can find mplayer2 and use that [20:22:16] <uau> BBB: i think -vo gl in svn at least was totally broken with slice threading, as in no working picture at all [20:22:50] <elenril> anybody with WMP here? [20:22:53] <BBB> hmk, right, so that's what reimar is talking about [20:23:26] <Compn> elenril : yes ? [20:24:09] <elenril> Compn: can you please test ftp://ftp.khirnov.net/out.mp3 ? [20:24:23] <elenril> i want to know if the tags are working properly [20:24:55] * Compn wonders if wmp can ahndle ftp [20:25:01] <Compn> ok where do i get tags from ? [20:25:23] <elenril> i mean id3v2 in this mp3 [20:25:34] <elenril> wmp should display them [20:25:35] <Compn> i mean, how do i display the tags in it [20:25:40] <Compn> its scrolling them [20:25:45] <elenril> rightclick->properties iirc [20:26:04] <Compn> it lists title artist album composer and genre [20:26:18] <Compn> in the properties window [20:26:22] <elenril> it should say 梶浦由記 - storm is coming [20:26:35] <Compn> title storm is coming [20:26:42] <Compn> artist is ???? [20:26:50] <elenril> meh [20:27:08] <Compn> by ??? its boxes, probably japanese text [20:27:15] <Compn> just that no fonts installed properly [20:27:20] <elenril> ah [20:27:39] <elenril> how can you live without japanese fonts ;) [20:27:53] <elenril> i'll just assume it works fine [20:27:55] <Compn> well i cant read japanese , so boxes or japanese doesnt make much difference to me [20:28:10] <Compn> kanji i should say [20:28:12] <elenril> it looks nicer [20:44:38] <Flameeyes> elenril: Kanno? which ost is that? not .hack//sign I guess :) [20:45:11] <elenril> Flameeyes: kajiura [20:45:26] <Flameeyes> gha sorry always confuse the two =_= [20:45:27] <elenril> Tsubasa Chronicles OST III [20:45:39] <Flameeyes> but yeah the same one as .hack//sign :) [20:45:50] <elenril> an incredibly awesome ost for an incredibly crappy anime [20:46:00] <elenril> right [20:46:25] <Flameeyes> well if it is anything to go by .hack's OST... I need to track that down :) [20:46:35] * Flameeyes bought the two .hack OSTs from amazon.jp years ago [20:47:20] <elenril> wait....you mean you don't have all the music she's ever written??!! [20:47:24] <elenril> *shock* [20:47:34] <Flameeyes> ehm not yet sorry [20:47:45] <Flameeyes> I needed to complete the YUI discography first [20:48:31] <elenril> you really should get the tsubasa chronicle ost [20:48:37] <elenril> and the noir ost [20:48:50] <elenril> and the xenosaga 2 & 3 osts [20:49:36] <Flameeyes> oh speaking about which .. three new lives from YUI ¬_¬ [20:49:45] <elenril> ...who's that? [20:49:47] * elenril runs [20:49:52] <Compn> yoko kanno is great [20:49:53] * Flameeyes loves jpop, if elenril knows what he's referring to [20:50:01] <Compn> but my favorite is probably yasushi ishii [20:50:39] <Flameeyes> damn, that site has nothing from kajura :( [20:50:52] <Flameeyes> and I need coffe [20:50:56] <Flameeyes> very very much coffe [20:50:57] <elenril> yoko kanno is great, but her music isn't so good for standalone listening [20:51:16] <elenril> Flameeyes: recommend me something from yui? [20:51:20] <Flameeyes> I skipped an i here, and a u there =_= [20:51:34] <Flameeyes> elenril: holidays in the sun [20:52:18] * elenril raises the jolly roger [20:52:55] <elenril> arrr! [20:53:18] <Flameeyes> tell sony to publish their stuff in europe! >_< [20:53:28] <elenril> >sony [20:53:33] <elenril> EVIL! [20:53:33] * Flameeyes actually has all of Utada's work paid for... since _that_ is released here... [20:53:49] <elenril> also downloading music is perfectly legal, so i'm not doing anything bad ;) [20:55:46] <Compn> did you try cdjapan.co.jp ? [20:55:51] <Compn> they ship internationally [20:55:58] <Compn> but like $50 per cd isnt a very good price [20:55:59] <Compn> lol [21:07:00] <Flameeyes> Compn: plus 60% over that for import duties in italy [21:07:54] <elenril> still no usable music downloads services? [21:09:33] <Flameeyes> elenril: covering wide j-pop range? not that I know [21:09:47] <Flameeyes> itunes has some stuff (Utada, L'Arc~en~Ciel, ...) [21:10:03] <elenril> bleh, itunes [21:11:50] <elenril> wait, i've heard this one somewhere [21:12:00] <elenril> ....oh, FMA opening [21:12:32] <Flameeyes> L'Arc? second FMA opening, first GTO opening [21:12:42] <Flameeyes> and DNA² opening as well [21:12:57] * elenril np again by YUI on HOLIDAYS IN THE SUN [21:21:47] * BBB sadly notices that yet again, michaelni appears completely not interested in finding solutions to problems :( [21:39:43] <michaelni> BBB, i do try to find a solution, i just think you dont want to accept where the problem is [21:40:04] <michaelni> i dont care all that much, once my payed work is done iam out of here [21:40:22] <BBB> stop trolling, stop fueling the trollwar, I don't even read your emails anymore if this continues [21:40:40] <BBB> I've told you what I'd like you to do: figure shit out with mans - go do it [21:40:54] <michaelni> i tried, i failed [21:40:59] <BBB> I noticed [21:41:35] <uau> IMO those votes discussed on the mailing list are a bad idea, whether done with open or secret ballots [21:41:36] <CIA-38> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * r6b47495397 ffmpeg/ (ffmpeg.c ffplay.c): [21:41:36] <CIA-38> ffmpeg: Adopt pkt_dts/pkt_pts in lavc clients [21:41:36] <CIA-38> ffmpeg: No behavior change; this makes DTS reliable with the next patch. [21:41:36] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:43:02] <BBB> uau: agreed [21:43:26] <uau> democracy isn't such a useful system for opensource projects anyway - its main benefit is resistance to corruption towards obviously bad government that cannot be changed because the existing bad government decides changes [21:44:02] <uau> but in opensource projects people can fork anyway if that becomes really obvious, so there's not so much benefit from democracy [21:44:56] <uau> also who gets to vote in an opensource project if you do try to decide things "democratically"? [21:45:09] <uau> who'd get to vote here? the people who had write access to svn? IMO that would be completely arbitrary [21:47:37] <uau> if you'd want to make it really democratic you'd need to allow *anyone* to vote, not just those who got write access through some fairly arbitrary criteria and circumstances [21:48:29] <uau> but i think most people can see that allowing all the idiots on the mailing list (and elsewhere) would not be particularly likely to produce a *good* solution, even if that'd be the most democratic way [21:48:51] <uau> allowing [to vote] [21:51:53] <BBB> yeah voting gets sort of complex now [21:53:38] <kierank> is all the valgrind complaining in v_block_filter in error_resilience a false positive? [21:55:30] <astrange> i haven't read the thread in detail, but i think AVCodecContext.active_thread_type is the field the mt thread wants [21:55:46] <astrange> kierank: try --track-origins=yes [21:56:09] <BBB> astrange: I don't think that works if pthreads are disabled, does it? [21:56:15] <uau> astrange: is it set before any callbacks can be called? if so then it's probably an ok solution [21:57:25] <uau> BBB: why wouldn't it? [21:57:43] <uau> would it not be set to 0 in that case for some reason? [21:57:57] <astrange> it's set inside avcodec_open, callbacks happen after that [21:58:19] <astrange> by pthreads are disabled, do you mean thread_count=0, or --disable-pthreads? [21:58:27] <BBB> both [21:58:44] <BBB> I guess I primarily meant --disable-pthreads ./configure [21:58:51] <astrange> first - should be 0 (i didn't check), second - FF_THREAD_SLICE because of pthreads emulation [21:59:16] <astrange> which is used so the threading tests still work without threads [21:59:18] <BBB> because avctx->thread_count appears to be set to 1 regardless [22:06:38] <Flameeyes> elenril: did a good thing to get those two lives.. "Unsupported codec (id=102400) for input stream 2" =_= [22:06:41] <Flameeyes> new test files! [22:07:25] <astrange> 1 [22:42:59] <Flameeyes> somebody fancying some debugging? :D http://paste.pocoo.org/show/332816/ file is a "meager" 400M :P [22:44:36] <Flameeyes> sorry wrong paste, but the same happens with current git [22:46:48] <kierank> Flameeyes: what's the problem? [22:47:17] <Flameeyes> kierank: mostly the ong amount of bad stuff printed out ;) my script seems to be aborting, trying to understand that myself [22:47:44] <kierank> well the stuff printed out happens on virtually all h.264 ts files because they're not cut cleanly [22:48:12] <Flameeyes> uhm it seems like it's the multi-pid that throws my script out, damn :| [23:05:14] <Dark_Shikari> BBB: The speed seems to be similar, at least on this clip [23:05:22] <Dark_Shikari> it would definitely be more useful in h264 though [23:05:54] <Dark_Shikari> BBB: http://pastebin.com/2TzTDgFp [23:05:57] <Dark_Shikari> hunks 1/2 are my evil trick [23:06:10] <Dark_Shikari> hunk 3 helps, but it breaks bigendian because we have no AV_RL32A [23:06:59] <Sean_McG> htonl()? [23:11:54] <BBB> what does RL32A do? [23:12:08] <BBB> 32-bit aligned read? [23:12:27] <Dark_Shikari> yes [23:12:36] <Dark_Shikari> the & 0xFF and >>8 bits assume little-endian [23:12:54] <Dark_Shikari> but it helps a few clocks, at least. the same thing in the top part would also help. [23:22:13] <BBB> for a "few clcks", this is a little ugly :-p [23:22:21] <Dark_Shikari> The bottom part is ugly? [23:22:23] <Dark_Shikari> It's like two lines [23:22:35] <Dark_Shikari> It doesn't seem very ugly to me [23:23:07] <BBB> the top part is ugly [23:23:14] <BBB> the bottom part is fine [23:23:21] <Dark_Shikari> The top part was my idea. [23:23:25] <Dark_Shikari> The bottom part was a simple optimization. [23:23:34] <Dark_Shikari> 10:05 <@Dark_Shikari> hunks 1/2 are my evil trick [23:23:34] <Dark_Shikari> 10:06 <@Dark_Shikari> hunk 3 helps, but it breaks bigendian because we have no AV_RL32A [23:23:49] <Dark_Shikari> the "few clocks" was about the last hunk [23:24:01] <BBB> ah ok [23:24:05] <BBB> sorry, misunderstood [23:24:11] <BBB> AV_RL32() makes it significantly slower? [23:24:22] <Dark_Shikari> It's definitely less efficient than a hypothetical AV_RL32A [23:24:24] <BBB> (shouldn't make a difference on x86 anyway) [23:24:29] <Dark_Shikari> On non-x86, at least. [23:25:02] <BBB> AV_RL/B8/16/32A() is fine with me [23:25:33] <BBB> (but let's not worry about that) [23:25:46] <BBB> does the top make any difference? [23:25:49] <BBB> it's kind of ugly [23:26:19] <Dark_Shikari> I haven't done much testing [23:26:21] <Dark_Shikari> I just wanted to show it could be done [23:26:26] <Dark_Shikari> it would be more useful in h264 than in vp8 as I said [23:27:03] <Dark_Shikari> By the way, if you wanted to be a gigantic dick, you could do something crazy like iterate over all the DC-only ones first, then the non-DC-only ones. [23:27:07] <Dark_Shikari> The whole approach is pretty generic. [23:34:11] <astrange> any reduction in branches in h264 is good [23:36:24] <Sean_McG> do the branch prediction hint macros help with that? [23:36:34] <BBB> yeah h264 is pretty branchy and has some incredible spaghetti code in places :-p [23:36:56] <BBB> but then again I don't think it'd speed it up much to get rid of that, better just get ffmpeg-mt in place

1 0

IRC log for 2011-02-04
by irc＠mansr.com 05 Feb '11

05 Feb '11

[00:13:54] <pross-au> Err [00:14:02] <pross-au> ftp> cd /MPlayer/incoming [00:14:02] <pross-au> 550 Failed to change directory. [00:14:13] <mru> try cd /incoming [00:14:30] <pross-au> thanks! [00:14:45] <pross-au> Is this a permanent change? (bugreports.html needs updating) [00:15:04] <mru> diego moved it up a level, it does make sense [00:15:17] <mru> I guess he forgot to update all references to it [00:21:32] <michaelni> hi mans, ben said i have to reconcile with you for any compromis [00:21:41] <michaelni> iam not so much interrested to join you guys than iam concerned about the community spliting up and leaving both sides [00:21:49] <michaelni> ping mru [00:22:04] <mru> explain "compromise" [00:23:37] <mru> so far the only hints you've let slip have been totally unacceptable [00:24:07] <mru> and "ben said ..." doesn't exactly convince me you understand what this is about [00:24:56] <michaelni> compromise = "roots replaced by neutral people, stef,me,carl,reimar,baptiste joining commiters, clarification of leadership of new team, clarification of file maintainers vs commiters, some vission doc that lists goals of ffmpeg) [00:25:11] <mru> unacceptable [00:25:12] <michaelni> that is the idea for discussion [00:25:23] <michaelni> what part? [00:25:26] <mru> all of it [00:25:52] <michaelni> you dont want to clarify how the new maintainers are lead? [00:26:00] <mru> first of all, what has "root" got to do with it? [00:26:09] <michaelni> 1 person, democraty, consensus? [00:26:32] <michaelni> root abused their power to allow this without public discussion and vote [00:26:41] <mru> oh but there was [00:26:49] <mru> in october there was a vote [00:27:01] <mru> the outcome was that you got to stay under certain conditions [00:27:07] <mru> you failed to live up to those conditions [00:27:11] <mru> these are now the consequences [00:27:12] <iive> mru: you can't count? [00:27:16] <mru> deal with it [00:27:36] <michaelni> i did not fail the conditions [00:27:43] <mru> iive: I can count to 5 and then kickban you [00:28:00] <mru> michaelni: I can see this is pointless to discuss further [00:28:03] <michaelni> besides there was a majority that unconditionally wanted to keep me [00:28:10] <mru> I will not reply again [00:28:19] <michaelni> as you wish [00:28:49] <iive> mru: what would you wish michael to do, in order to accept reconciliation? [00:34:32] <Jumpyshoes> BBB: did holger ever reply to that thread? about LGPL ok? [00:43:05] <Dark_Shikari> michaelni: how about you get approval from other people? [00:43:07] <Dark_Shikari> this is a democracy. [00:43:17] <Dark_Shikari> it doesn't matter what mru thinks if nobody agrees with him. [00:43:21] <Dark_Shikari> I certainly don't agree with him. [01:39:30] <BBB> Jumpyshoes: he said he would, but the email didn't go through yet [01:39:36] <BBB> Jumpyshoes: keep asking him to reply to that thread saying ok [01:40:48] <BBB> oh and uhm, asking all roots to resign is rather silly [01:42:02] <BBB> lu_zero: did you comment on "[PATCH] swscale: fix build with --enable-runtime-cpudetect --disable-mmx/mmx2/amd3dnow"? or should we start merging your branch now? [01:44:46] <Jumpyshoes> BBB: okay [01:46:17] <{V}> BBB, re: roots to resign, agreed and "<michaelni> that is the idea for discussion" [01:46:43] <{V}> in other words a proposal. [01:46:53] <BBB> it might help the discussion to enter into it with slightly more realistic goals [01:47:47] <lu_zero> BBB: I wanted to check since my tree isn't ready at all right now [01:47:58] <BBB> {V}: if a woman and a man enter into a bar with the woman saying "I'm ugly, fat and I want a rich, handsome beautiful wall-street banker who makes $10M/yr" and the man says "I'm a loser and unemployed and I want a victoria secret's photomodel with blond long hair", then I don't think much will come out of the discussion [01:48:01] <lu_zero> (and possibly broken by the last commit in a case) [01:48:41] * Sean_McG snickers [01:49:01] <{V}> BBB, a mediator is needed. [01:49:21] <lu_zero> or to be less sexist, a compromise could be done only if both parties have a middle ground and are up to agree with some of the other party requests [01:49:29] <lu_zero> {V}: sadly not [01:49:38] <BBB> lu_zero: well but then the statement doesn't sound as funny [01:49:56] <lu_zero> I stated already that I thank you for your effort [01:49:57] <BBB> but anyway I apologize for the sexism, none was intended [01:50:01] <{V}> aiming is not a bad thing, as long as you're willing to settle for less [01:50:14] <{V}> s/aiming/aiming high/ [01:50:29] <lu_zero> {V}: I had been into mediation a bit [01:51:53] <lu_zero> you don't enter a compromise offending the other party AND requesting the other party annihilation [01:52:43] <lu_zero> or even worst, shifting from two different moods [01:56:16] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * rf61dee2fe4 ffmpeg/libavformat/wtv.c: [01:56:17] <CIA-38> ffmpeg: wtv: filesystem implementation [01:56:17] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [01:57:55] <bryno> which repo is the *official* repo? [01:58:15] <lu_zero> bryno: git.ffmpeg.org [01:58:45] <bryno> what's the difference between that one and the one at git.mansr.com ? [01:58:57] <BBB> git.mansr.com is mans' personal tree [01:59:03] <BBB> just like we all have our own personal trees [01:59:06] <lu_zero> git.mansr.com contains mans' experiments [01:59:10] <BBB> (github.com/rbultje !) [01:59:13] <lu_zero> like mine at github [01:59:18] <lu_zero> or ronald's ^^ [01:59:50] <CIA-38> ffmpeg: Nicolas George <nicolas.george(a)normalesup.org> master * r51b317d2e9 ffmpeg/libavformat/tcp.c: [01:59:50] <CIA-38> ffmpeg: TCP: factor the poll() call [01:59:50] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george(a)normalesup.org> [01:59:50] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [01:59:51] <lu_zero> once they are ready they'll be revised and sent as patchset in the ml [02:00:29] <bryno> the mansr one looks like it reflects the one at ffmpeg.org. the one at videolan.org has commits that aren't even made anywhere else [02:00:45] <lu_zero> bryno: and vice versa possibly [02:00:54] <lu_zero> btw check the branches [02:01:03] <lu_zero> since the master is usually in line for everybody [02:01:27] <bryno> it's becoming confusing. branches/forks everywhere [02:01:35] <lu_zero> bryno: why? [02:01:53] <Sean_McG> welcome to open source, enjoy the ride. [02:02:06] <BBB> bryno: that's the whole point of git [02:02:09] <lu_zero> you want something supposedly stable -> pick what a distribution you trust chose [02:02:33] <lu_zero> want something more dynamic, pick the git.ffmpeg.org tree [02:02:40] <bryno> not necessarily stable, but official [02:02:56] <lu_zero> want to help on a specific field? [02:03:24] <lu_zero> clone one of the branches in the public personal repos ^^ [02:03:31] <lu_zero> isn't that complex [02:03:55] <bryno> i'm coming from the perspective of someone who uses the libraries, like how the libav mailing list is designated [02:04:04] <lu_zero> git.ffmpeg.org repo aims to collect the changes and the bugfix [02:04:43] <lu_zero> so if you track it you possibly have less surprises [02:04:57] <bryno> there's 5 repos listed on the site whereas before it was only 1. just adds to some confusion [02:05:19] <lu_zero> bryno: there had been always that many (and some more) [02:06:05] <lu_zero> siretart poured a LOT of effort to convince us that releases should be done [02:06:06] <bryno> i can imagine, but the site only referred to the main branch that most people grabbed [02:06:16] <lu_zero> so you might consider that as well [02:11:04] <BBB> mru: is there a reason you did not push "[PATCH] Make avfilter_graph_free() free the graph"? [02:12:32] <mru> I was waiting for clarification on the api/abi change policy there [02:12:35] <mru> I guess it's good to go [02:12:39] <mru> agree? [02:13:42] <mru> hmm, look at fate [02:17:54] <mru> you really should have build tested that [02:40:20] <BBB> uh, I did [02:40:35] <mru> no, you did not [02:40:36] <BBB> oh damnit I didn't wait for the build to finish [02:40:46] <BBB> wtv.c finished so I thought it was good to go [02:40:48] <BBB> darnit [02:40:51] <BBB> learned something new [02:40:57] <BBB> ok, will find the parts I forgot to apply [02:41:01] * Dark_Shikari pokes BBB again [02:41:02] <mru> and you didn't see it spew warnings in all direction? [02:41:17] <mru> I just replied to the relevant patch [02:46:28] <BBB> moving functions into internal.h ok? [02:46:30] <BBB> Dark_Shikari: one second [02:46:35] <mru> I guess [02:46:40] <BBB> Dark_Shikari: let me fix yet another git messup of mine [02:46:47] <Dark_Shikari> sure [02:46:50] <Dark_Shikari> no rush [02:47:57] <BBB> so how do I amend the patch without changing its authorship? [02:48:36] <BBB> or should I change ownership now, and say "based on patch by ..."? [02:48:40] <mru> edit files; git add files; git commit --amend [02:51:24] <BBB> fixed [02:51:38] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * re6fb5a4f78 ffmpeg/libavformat/ (internal.h utils.c wtv.c): [02:51:38] <CIA-38> ffmpeg: add ff_index_search_timestamp and ff_add_index_entry [02:51:38] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:53:55] <BBB> ok, Dark_Shikari, sorry [02:54:14] <BBB> how should I help? [02:55:45] <Dark_Shikari> Just save the patch and maybe bench it [02:55:51] <Dark_Shikari> throw it in your folder or something. [02:56:02] <Dark_Shikari> I don't like having patches I wrote that weren't useful (but could be useful) sit on my disk. [02:56:25] <BBB> oh shit I missed it [02:56:28] <BBB> ok, will check [02:56:38] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r4359288c56 ffmpeg/ (4 files in 2 dirs): [02:56:39] <CIA-38> ffmpeg: Make avfilter_graph_free() free the graph. [02:56:39] <CIA-38> ffmpeg: Make avfilter_graph_free() free not only the internal structures, but [02:56:39] <CIA-38> ffmpeg: also the allocated graph, and set the graph pointer to NULL for [02:56:39] <CIA-38> ffmpeg: increased safety. [02:56:39] <CIA-38> ffmpeg: Simplify usage. [02:56:40] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [02:56:49] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * re8e5dde779 ffmpeg/libavfilter/graphparser.c: (log message trimmed) [02:56:49] <CIA-38> ffmpeg: Make avfilter_graph_parse() not free the input graph [02:56:49] <CIA-38> ffmpeg: Make avfilter_graph_parse() only release the internal structures [02:56:49] <CIA-38> ffmpeg: allocated during the parsing, and leave to free the graph itself to [02:56:49] <CIA-38> ffmpeg: the calling code. [02:56:49] <CIA-38> ffmpeg: This approach looks cleaner, as the graph is not allocated by the [02:56:50] <CIA-38> ffmpeg: function. [03:01:08] <BBB> wbs: https://roundup.ffmpeg.org/issue2583 for you [03:16:03] <Dark_Shikari> ok BBB I finally did something that helped performance (omg) [03:16:16] <BBB> Dark_Shikari: you imlpemented ffmpeg-mt for vp8? [03:16:35] <Dark_Shikari> lol [03:17:25] <BBB> you added support for real slices? [03:17:46] <BBB> as in, ndependent of each other, no refs to each other [03:17:48] <Dark_Shikari> check my email [03:17:48] <BBB> like in h264 [03:17:49] <BBB> :-p [03:18:19] <BBB> dont see ot yet [03:18:30] <BBB> there it is [03:19:16] <Dark_Shikari> it's like 8 cycles faster or something [03:20:04] <BBB> I'm confused, 8 cycles is noteworthy but 30 cycles like your last patch is not? [03:20:09] <BBB> or was that sarcastic? :-p [03:20:11] <Dark_Shikari> Relative [03:20:14] <Dark_Shikari> this is 8 cycles out of a 30 cycle function [03:26:20] <BBB> mru: http://patches.ffmpeg.org/patch/688/ shoud be committed [03:26:27] <BBB> Dark_Shikari: oh that's not bad [03:28:15] <BBB> Dark_Shikari: that passes make fate-vp8? [03:28:50] <BBB> I thought we had to cache the mvmode somehow for the next blocks [03:29:05] <BBB> (I mean near vs. nearest) [03:33:30] <BBB> mru: also "[FFmpeg-cvslog] Implement av_samples_alloc() and av_samples_fill_arrays()" should maybe be applied? [03:37:39] <Dark_Shikari> yes it passes [03:37:44] <Dark_Shikari> mvmode is not needed for future mbs [03:37:47] <Dark_Shikari> also [03:37:49] <Dark_Shikari> #define POW2CLIP(x,max) (((x) & ~max) ? (-(x))>>31 & max : (x)); [03:37:52] <Dark_Shikari> Do we have a macro that does this? [03:39:53] <Dark_Shikari> this makes the filter_level clip faster. [03:40:26] <BBB> static inline, I can see gcc calculating x 4x [03:40:48] <Dark_Shikari> this is from x264_clip_pixel [03:40:50] <BBB> av_clip_(u)ont16/32/64 are implemented as per above [03:40:54] <BBB> but there's no generic version of it [03:40:57] <Dark_Shikari> yes, but we need this to clip to 63 [03:41:03] <Dark_Shikari> I don't want to bikeshed this :> [03:41:05] <BBB> hehe :) [03:41:08] <Dark_Shikari> also filter_level is already calculated [03:41:11] <BBB> just make it a local macro [03:41:12] <Dark_Shikari> #define POW2CLIP(x,max) (((x) & ~max) ? (-(x))>>31 & max : (x)); filter_level = POW2CLIP(filter_level, 63); [03:41:23] <BBB> it's fine with me [03:41:28] <BBB> is it faster? [03:41:38] <BBB> btw is gaikai going to use vp8? you work a lot on vp8 lately [03:42:06] <Dark_Shikari> no [03:42:24] <Dark_Shikari> yes its faster, ~1-2 clocks [03:50:56] <BBB> ok, reviewed those two [03:51:04] <BBB> wifey wants to sleep, so I'll bench your last patch tomorrow [03:51:16] <Dark_Shikari> you really don't have to bench it, I already did [03:51:18] <Dark_Shikari> oh [03:51:21] <Dark_Shikari> you mean the sse4 one? [03:51:34] <Jumpyshoes> i was going to ask what wifey was <_< >_> [03:51:42] <BBB> Dark_Shikari: yes that one [03:51:53] <Dark_Shikari> Jumpyshoes: <insert photo of dakimakura here> [03:51:57] <BBB> Jumpyshoes: you're too young for that kind of stuff :-p [03:52:00] <Dark_Shikari> BBB: ok, no problem, it's not important [03:52:10] <Jumpyshoes> Dark_Shikari: nothing wrong with those :P [03:52:12] <BBB> Dark_Shikari: vp8 performance is fun :) [03:52:41] <Jumpyshoes> btw, is there a public xvp8 tree anywhere? [03:52:46] <Dark_Shikari> yes [03:52:52] <BBB> it's not uptodate [03:52:57] <Jumpyshoes> oh [03:52:59] * BBB lazy [04:24:41] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * rdd18c9a050 ffmpeg/libavcodec/ (vp8.c vp8data.h): VP8: simplify lf_delta mb mode logic [04:24:51] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * ra1b227bb53 ffmpeg/libavcodec/vp8.c: VP8: faster filter_level clip [05:42:02] <Dark_Shikari> mru: why is the troll still not banned? [05:46:24] <ubitux> in libavutil/tree.h, there is a "if(*next) av_freep(next)", according to the context, do you think it is a "typo" for "if(next) av_freep(next)", or we should just remove it with av_freep(next)? [05:46:45] <ubitux> (it's in a comment, not a functionnal code this is why i ask) [05:47:28] <ubitux> i would have removed the if if it was code [05:48:24] * elenril yawns [05:48:33] <elenril> awesome, more drama [05:49:28] <peloverde_> Is gabu's last post enough to get him banned? [05:50:19] <peloverde_> Any list admins around here? [05:53:25] <Dark_Shikari> I've repeatedly asked mru why the troll isn't banned [05:53:56] <wooster> what'd he post? [05:55:08] <elenril> Dark_Shikari: can mru even do that? [05:55:21] <elenril> i think doesn't admin the ML [05:55:29] <ubitux> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-February/105633.html [05:55:32] <ubitux> here is the post. [05:55:52] <Dark_Shikari> he's been constantly trolling the ml [05:55:54] <Dark_Shikari> for like a week [05:59:18] <peloverde_> who are list admins? [05:59:39] <Dark_Shikari> no idea [05:59:41] <Dark_Shikari> bcoudurier: you know? [06:03:35] <uau> KotH has maintained some of the mail stuff at least [06:39:47] <Dark_Shikari> mru: I'd like to troll you for a moment [06:39:50] <Dark_Shikari> so I just realized, in vp8 [06:39:54] <Dark_Shikari> mbedge_lim = bedge_lim + 4 [06:39:58] <Dark_Shikari> we should not be passing this as a parameter [06:40:06] <Dark_Shikari> because it's derived trivially from one of the other parameters. [06:40:34] <Dark_Shikari> ... oh wait. there's no single loopfilter DSP function that takes both. I think [06:40:40] <Dark_Shikari> phew. [06:40:43] <Dark_Shikari> don't have to break your asm. [07:00:22] <elenril> o_0 what's up with all the vp8 patches [07:02:26] <Dark_Shikari> me being bored [07:02:58] <lu_zero> yawn [07:03:04] <lu_zero> good morning [07:03:09] * lu_zero heads to the airport [07:04:35] <elenril> Dark_Shikari: help merging -mt =p [07:08:01] <elenril> btw it'd be really nice if somebody deprecated all the stuff that's to be removed from AVCodecContext [07:36:27] <elenril> :/ srsly, what does this troll have to do to get banned [07:42:12] <cartman> moin [07:58:51] <spaam> God morgon [07:58:59] <pross-au_> Evening [07:59:15] <pJok> ohayou gozaimasu [08:02:33] <siretart> Dark_Shikari: AFAIUI, benoit- is the list moderator, not mru [08:02:38] <Dark_Shikari> ah [08:02:40] <Dark_Shikari> benoit-: ^ [08:03:23] <siretart> btw, who cares about vc1 these days? https://roundup.ffmpeg.org/issue2584 [08:04:02] <Dark_Shikari> ask jumpyshoes, he fixes these things [08:04:22] <siretart> ok, thanks [08:04:32] <Dark_Shikari> I'll try to see if I can replicate btw [08:04:45] <cartman> man, get a fscking real SSL certificate for god's sake [08:05:06] <siretart> at least a cacert one would do for me [08:05:27] <Dark_Shikari> siretart: doesn't replicate here. [08:05:42] <Dark_Shikari> "Bits overconsumption" ---> looks like it might be an overread problem [08:05:48] <siretart> okay, that indicates that some commit in master fixed it then? [08:05:51] <Dark_Shikari> No [08:05:59] <Dark_Shikari> It could just indicate that ffmpeg.c has enough padding to avoid it. [08:06:32] <Dark_Shikari> (if that's the issue. it might not be.) [08:06:38] <Dark_Shikari> someone should valgrind it [08:06:41] <siretart> well, it was observed in vlc, this would rule out a change in ffmpeg.c [08:07:02] <spaam> cartman: will you fix OpenGL support for ffplay when roundup have a good cert? ;) [08:07:16] <cartman> spaam: I am on my way fixing myself [08:07:18] <Dark_Shikari> siretart: that isn't what I said [08:07:27] <Dark_Shikari> I don't think anything was changed at all. [08:07:44] <spaam> cartman: ohh [08:07:51] <cartman> spaam: for any specific problem though, reimar wrote MPlayer's OpenGL vout drivers [08:07:59] <siretart> Dark_Shikari: ah, so you're basically saying it needs more investigation? - ok [08:08:01] <cartman> maybe assign to him :) [08:08:04] <Dark_Shikari> yes [08:08:32] <spaam> cartman: i know. but you code some opengl stuff now. so it will be easy for you ;) [08:08:46] <cartman> spaam: baaaah [08:09:19] <spaam> cartman: pJok can help you. :) [08:09:26] <cartman> spaam: oh :D [08:10:14] <pJok> wa? [08:11:02] <cartman> pJok: spaam says you are an OpenGL wizard [08:11:16] <pJok> i am sure his tabcomplete is borked ;) [08:11:28] * pJok is about as wizardry as Clippy [08:11:40] <cartman> good :P [08:12:02] <pJok> i think he meant peloverde rather than me [08:12:12] <pJok> im a techie, not a coder ;) [08:13:17] <cartman> No worries I am not writing OpenGL either :P [08:13:32] <peloverde> I don't think he means me, I haven't done any OpenGL since first year at university [08:13:48] <av500> cartman: its not me either [08:13:57] <cartman> av500: I guessed that much :) [08:14:17] <cartman> http://dilbert.com/fast/2011-02-04 [08:14:17] <cartman> lol [08:24:56] <wbs> BBB: I'll have a look [08:29:39] <kshishkov> siretart: I can at least name you one person who doesn't care about VC-1 [08:31:02] <spaam> kshishkov: will we see interlaced support for vc-1 this year? ;D [08:31:22] <cartman> spaam: interlaced bink-b first [08:31:49] <spaam> cartman: Nice [08:32:08] <kshishkov> spaam: he's right (especially since such bink files don't exist) [08:32:24] <spaam> kshishkov: maybe we can create one? [08:33:13] <kshishkov> hmm, good idea, make Dark_Shikari work on bink-b encoder [08:33:57] <KotH> salut [08:34:35] <kshishkov> god morgon [08:36:50] <cartman> moin KotH [08:42:50] <Tjoppen> hm. sample_aspect_ratio as a name results in an ambiguous acronym [08:43:22] <kshishkov> ? [08:43:33] <Tjoppen> SAR can often mean "stored aspect ratio" [08:43:42] <Tjoppen> hence DAR = SAR * PAR [08:43:56] <Tjoppen> stead of SAR * SAR :o [08:43:59] <Tjoppen> *instead [08:44:33] <kshishkov> just kill the ones who proposed "stored" thingy [08:45:13] <superdump> indeed [08:45:23] <superdump> i haven't heard of SAR being stored aspect ratio [08:45:27] <superdump> always sample aspect ratio [08:45:55] <Tjoppen> what a good name for the essence's aspect then? EAR I suppose [08:46:34] <kshishkov> and I'm pretty sure you can tons of meanings for every TLA, look at Stefano's signature as example [08:46:43] <kshishkov> Tjoppen: IORE [08:47:25] <superdump> isn't the essence aspect ratio then easily calculable from the stored width/height? [08:47:45] <peloverde> deep down I know kshishkov secretly wants to finish AAC [08:48:51] <kshishkov> peloverde: actually I'd like my coworker to do it instead [08:51:34] <peloverde> and I would like Abraham Lincoln to do it but sometimes we have to stick to what's reasonable [08:52:33] <kshishkov> peloverde: not working at all? That always was reasonable to me [09:07:10] <mru> Tjoppen: if not stored, then what? [09:07:13] <mru> forgotten? [09:07:50] <mru> peloverde: you know who he works with, right? [09:07:58] <av500> "suggested" aspect ratio [09:08:07] <mru> supposed [09:08:42] <wbs> mru: who does he work with, menno bakker or someone similar? [09:08:47] <av500> ivan [09:09:01] <mru> wbs: ivan dimkovic [09:09:15] <wbs> oh, even better :-) [09:09:19] <kshishkov> indeed [09:09:53] <av500> and since we probably share some ancestry way back, it makes me total cool too [09:09:54] * cartman wonders if kshishkov works for the guys who burned Rome [09:10:17] <av500> cartman: close [09:10:48] <peloverde> I'm aware [09:12:38] <kshishkov> av500: 26 tram stops from here so it's not close :P [09:13:37] <kshishkov> cartman: I don't I'd be able to work there [09:13:53] <cartman> can't parse that [09:13:55] <av500> kshishkov: 26 tram stops to Rome? [09:14:14] <mru> all trams stop in rome, no? [09:15:04] <kshishkov> mru: not the ones in small village on west coast (aka GÃ¶teborg) [09:19:15] <KotH> Dark_Shikari, uau: yes, mru and me are root, but we do not manage the ffmpeg mailinglists. hence it would be inaproriate for us to ban someone. especially if the ml admins wont do that [09:20:08] <Dark_Shikari> so who does? [09:20:14] <spaam> Compn ? [09:20:19] <KotH> ffmpeg-devel-owner@mphq :) [09:23:12] <cartman> re [09:23:24] <cartman> Nero AAC encoder is from 2009 it seems , pff [09:24:03] <mru> their avc decoder is nice [09:25:12] * cartman pets his nvidia card for that [09:25:54] <kshishkov> mru: that makes me wonder - you know the man who wrote it so is it that hard to write fast and nice H.264 decoder given enough time? [09:26:26] * cartman just had a DejaVu [09:26:28] <mru> well, he's a philosopher... [09:26:43] <cartman> psychic powers? [09:27:33] <kshishkov> mru: exactly, so can't proper engineer write it too? [09:27:39] <mru> he smokes cigars, claims the code is revealed to him in the smoke [09:27:44] <cartman> LOL [09:27:56] <cartman> I worked with a guy like that [09:27:58] <mru> only last bit is made up [09:28:15] <cartman> http://cdn1.cnnturk.com/Handlers/file_.ashx?FileID=428734 looks similar btw. [09:29:49] <j-b> 'morning [09:29:54] <cartman> moin j-b [09:30:05] <peloverde> It would be cool if our AVC decoder were fast [09:30:18] <peloverde> Dark_Shikari: didn't you have some ideas on how to restructure it? [09:30:20] <j-b> +10 [09:30:29] <cartman> peloverde: then lots of commercial companies would go bankrupt [09:30:30] <av500> and what about the H264 decoder? [09:31:21] <kshishkov> av500: maybe writing fast h264 decoder is not that hard [09:31:33] <cartman> just need correct cigars [09:31:46] <av500> kshishkov: I want a fast mpeg4-part10 decoder too [09:31:49] <Dark_Shikari> peloverde: well I've already done some optimizations [09:31:52] <Dark_Shikari> ffmpeg-mt is more important though [09:32:13] <Dark_Shikari> One thing I want to do: port what I did in vp8, zero the dct blocks in idct [09:32:18] <Dark_Shikari> problem: requires changes in ALL h264 asm [09:32:20] <Dark_Shikari> ppc, x86, and arm [09:32:25] <Dark_Shikari> and whatever else [09:32:45] <mru> those are the only ones iirc [09:32:49] <mru> let's do it if it helps [09:32:51] <kshishkov> av500: make your Indians do it! [09:33:02] <cartman> av500 works with Chinese [09:33:11] <av500> cartman: wrong [09:33:13] <mru> cartman: but do they work with you? [09:33:22] <cartman> you mean "wong!" [09:33:28] <cartman> thats how you do it [09:33:42] <cartman> mru: if you pay enough they pretend to do so [09:33:44] <av500> wlong again! [09:34:01] <Dark_Shikari> mru: you know what I'm talking about, right? [09:34:04] <Dark_Shikari> i.e. to avoid clear_blocks [09:34:06] <Dark_Shikari> as in vp8 [09:34:12] <cartman> av500: so indians it is? [09:34:19] <av500> cartman: for codecs, yes [09:34:23] <cartman> av500: interesting [09:34:42] <Dark_Shikari> speaking of indians [09:34:44] <cartman> av500: edge cases that ffmpeg doesn't handle? [09:34:47] <Dark_Shikari> I just had one randomly PM me about a gstreamer question [09:34:50] <Dark_Shikari> unrelated to x264 [09:34:57] <Dark_Shikari> I think it's one of those guys who PMs everyone on the /who list until he gets a response [09:35:00] <Dark_Shikari> instead of asking it in channel [09:35:00] <av500> Dark_Shikari: just send him teh codez [09:35:29] <cartman> he just needs a complete "sample" :p [09:36:36] <cartman> wbs: my Android 2.1 crash bug is 7 days old and going :P [09:36:48] <j-b> pfff, you guys are still fighting over admin/roots? In those days of cloud? pfff [09:36:56] <wbs> j-b: lol [09:37:01] <wbs> cartman: awwww, poor you ;P [09:37:04] <kshishkov> j-b: not us [09:37:05] <cartman> We all have a "Got root?" tshirt [09:37:08] <cartman> we need it. [09:37:08] <wbs> cartman: you haven't even debugged it and sent a patch yet! ;P [09:37:20] <cartman> wbs: uh oh its inside the libstdc++ :( [09:38:12] <cartman> wbs: its Google's fault anyway. Obviously their famous QA doesn't test < 2.2 [09:38:16] <j-b> wbs: well, seriously. Finding git hosting is fucking easy (github, gitorious, or even git.v.o). Hosting the website is a joke (it is 20 static pages). Hosting mailing list is of almost no maintainance and outsourceable quite easily. [09:38:27] <j-b> wbs: so, what's the rest? fate? ok. [09:38:59] <cartman> j-b: you don't get it. [09:39:07] <cartman> its about the name "FFmpeg" in the end [09:39:42] <j-b> cartman: so? administrating a domain doesn't require a server. [09:39:43] <mru> j-b: and the 50GB of samples? [09:39:59] <j-b> mru: that's all? [09:40:03] <mru> also, I don't trust github [09:40:08] <j-b> mru: jones.v.o has a 1TB disk [09:40:21] <cartman> a disk could be donated [09:40:26] <j-b> sure [09:40:32] <mru> github often has downtime and they lost data at least once [09:40:43] * twnqx eyes a stack of decommisioned 1TB drives to his right [09:40:54] <j-b> mru: use gitorious. use us. use $whatever [09:40:57] <mru> it's nice as as a distribution channel, no more [09:41:28] <av500> mru: I can host your 50gb of samples on one A70H [09:41:30] <j-b> I just mean that roots/admin discussion is a non-issue. [09:41:42] <mru> that I agree with [09:41:51] <j-b> it isn't 2001 anymore [09:41:57] <mru> true [09:42:23] <twnqx> just use more than 1 server and sync daily or something [09:42:25] <kshishkov> mru: sourceforget.net! [09:42:28] <cartman> still ownership of the domain will be important [09:42:29] <twnqx> to reduce the dependency [09:42:31] <mru> when we set this thing up, the only vaguely viable public hosting was sourceforgery [09:43:00] <j-b> cartman: sure, and this is NOT a roots/admin issue§. [09:43:04] <mru> and their service was so poor we had to abandon it [09:43:06] <cartman> j-b: right [09:43:32] <vipw> try savannah, it's even worse [09:43:58] <j-b> if you don't expect the QoS that michaelni expected in the last mail a few months ago, it is quite easy [09:43:58] <mru> that's why I said vaguely viable [09:44:42] <mru> we've had much better availability stats than most of the public offerings over the last 5 years [09:45:06] <peloverde> we also block half the internet [09:45:15] <av500> and hungary [09:45:19] <mru> mostly china [09:45:29] <j-b> I can say the same [09:45:35] <mru> but _they_ block half the internet too [09:45:37] <j-b> "we've had much better availability stats than most of the public offerings" [09:45:42] <peloverde> When i started my current job I had to ask KotH to unblock me [09:45:45] <mru> j-b: I'm sure you have [09:46:11] <DonDiego> note that i'm working on getting said half of the internet unblocked [09:46:15] <j-b> mru: especially since we splitted development hosting|www hosting|other_stupid_websites [09:46:18] <peloverde> Samples and the website should have different rules [09:46:39] <DonDiego> peloverde: what rules do you mean? [09:47:03] <mru> rules of engagement [09:47:04] <peloverde> it should be ok to block half of china from samples, but not from the website [09:47:10] <j-b> peloverde: why are people blocking anything? [09:47:26] <mru> peloverde: DonDiego is working on exactly that [09:47:42] <peloverde> j-b: some people try to mirror all of samples eating a tremendous amount of bandwidth [09:47:48] <mru> j-b: because chinese leeches suck up all our bandwidth otherwise [09:48:08] <j-b> peloverde: you don't have unlimited bandwidth? [09:48:23] <mru> there's no hard limit [09:48:29] <cartman> there is no unlimited bandwidth in reality [09:48:31] <DonDiego> peloverde: half-way done, the website already resides on another IP, i still need to find a solution for rsync and ftp [09:48:41] <peloverde> DonDiego: awesome [09:48:56] <peloverde> will the website be ipv6 ready? [09:49:03] <DonDiego> hehe [09:49:08] <DonDiego> i never tried, good question [09:49:18] <mru> we don't have a public ipv6 address [09:49:29] <av500> DonDiego: make it v8 while you are at it... [09:49:41] <mru> with golden packets [09:49:58] <j-b> traffic on ipv6 on www.v.o was around 0.5% last month [09:49:58] <av500> alternate route packets [09:50:11] <wbs> j-b: that's surprisingly much :-) [09:50:21] <j-b> wbs: indeed [09:50:47] <peloverde> j-b: give it a year or two [09:50:54] <j-b> wbs: but since India is counting for 8% of the traffic (1,5% last year) it might be the reason [09:51:09] <spaam> j-b: www.v.o do not have aaaa records ;S [09:51:18] <j-b> spaam: because I deactivated it [09:51:21] <spaam> why? [09:51:33] <j-b> because I want a better allocation [09:51:43] <j-b> spaam: so I have new IPv6 now [09:51:51] <spaam> ok :) [09:51:51] <j-b> spaam: so I have new IPv6 adresses now [09:52:23] <j-b> spaam: seeing the traffic was more than I expected, I asked our provider for more. He said: "I hope this is for a BSD server". [09:53:19] <DonDiego> how is this related to bsd? [09:53:57] <mru> perhaps bsd handles high ipv6 traffic better [09:54:06] <j-b> DonDiego: just basic trolling from the sysadmin that is a BSD fan [09:54:11] <mru> linux certainly has rough edges [09:54:18] <spaam> : ) [09:54:24] <av500> please no bsd trolling now [09:54:33] <twnqx> mru: in what ways? [09:54:38] <av500> kshishkov: trains, pleaseeeee! [09:54:43] <mru> we caught linux doing tons of unaligned accesses in ipv6 code recently [09:54:55] <twnqx> i mean... i'm using ipv6 for a few years on my linux boxes, and never used up >500mbit with it, but... [09:55:13] <mru> it works for sure [09:55:18] <av500> twnqx: your fringe uses cases do not reflect ffmpeg.org reality :) [09:55:27] <mru> but I can very well imagine that it's not as well optimised as the ipv4 paths [09:55:40] <twnqx> sure, single high-bandwidth download is different from webserver reality [09:55:57] <av500> ff.org must handle all the known internet pulling git at once [09:55:59] <twnqx> mru: so i assume you're not talking x86/x86_64? [09:56:12] <mru> this was on arm [09:56:36] <kshishkov> are there ARM SOCs with gigabit ethernet? [09:56:45] <twnqx> av500: i am hosting a private gentoo portag emirror... i switched to using the disk as write-mostly with a ramdisk as raid 1 >_> [09:56:50] <mru> using a kernel patched to warn about alignment traps instead of silently fixing them [09:56:58] <mru> kshishkov: yes, the sheeva for example [09:57:17] <kshishkov> mru: ah, the one that needs fan as well [09:57:26] <spaam> twnqx: gentoo fan? ;D [09:57:35] <mru> kshishkov: that's not the only one [09:58:00] <twnqx> spaam: user. i have enough machines with it to run an own mirror for those [09:58:04] <kshishkov> mru: what else? [09:58:12] <cartman> setting up an IPv6 tunnel was easy [09:58:18] <mru> don't remember the details [09:58:19] * kshishkov has not seen ARM server CPUs yet [09:58:24] <spaam> twnqx: ok :) [09:58:30] <mru> gbit is not just for servers [09:58:35] <av500> kshishkov: ask canonical [09:58:49] <av500> they have a bunch of PXA270 based build servers :) [09:59:11] <kshishkov> mru: I also mean ARM-based chips with need of fan cooling [10:00:37] <pross-au> kshishkov: there are really cheap 1Us avail [10:01:13] <kshishkov> pross-au: I don't use big iron [10:01:25] <kshishkov> except at work [10:06:54] <ubitux> I'm looking for a (simple) audio-only demuxer+decoder I could use as base for writting one, do you have one in mind? [10:07:38] <kshishkov> any game format [10:07:46] <mru> great, combine it with my video-only player and we'll have completeness [10:07:47] <pross-au> sunau [10:08:50] <kshishkov> mru: why haven't you added audio out for omapfbplay? is it too messy with OSS/ALSA/NAS/whatever? [10:09:07] <ubitux> kshishkov: one random in mind? [10:09:22] <mru> alsa and libavcodec don't fit together well [10:10:06] <kshishkov> mru: only alsa and pulseaudio fit together [10:10:16] <kshishkov> ubitux: westwoodaudio.c [10:10:24] <ubitux> thanks [10:10:52] <kshishkov> ubitux: or try vocdec.c [10:10:55] <mru> alsa is stupid and won't let me just mmap the damn buffer [10:11:10] <mru> it insists on some silly function being called before and after each buffer fill [10:11:19] <kshishkov> mru: first three words were enough [10:11:56] <ubitux> kshishkov: right, perfect, thanks :) [10:11:57] <CIA-38> ffmpeg: ClÃ©ment BÅsch <ubitux(a)gmail.com> master * r523d9407d5 ffmpeg/ (3 files in 3 dirs): [10:11:57] <CIA-38> ffmpeg: Remove a few if (p) av_freep(&p) forms [10:11:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [10:12:08] <CIA-38> ffmpeg: ClÃ©ment BÅsch <ubitux(a)gmail.com> master * r290849e2a4 ffmpeg/ (libavfilter/defaults.c libavformat/avidec.c): [10:12:08] <CIA-38> ffmpeg: Remove forgotten if (p) av_free(p) forms [10:12:08] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [10:12:19] <kshishkov> mru: and I presume you've never looked at standard Window audio output API (before DShow), they had that approach for ages [10:12:33] <mru> of course not [10:12:53] <kshishkov> well, I felt in heaven after trying OSS output later [10:13:12] <mru> I don't like functions with dozens of arguments and an entire essay for a name [10:13:16] <mru> +Ex [10:13:50] <av500> mru: so, use OSS emulation on ALSA :) [10:13:51] <cartman> mru: no sound then? :) [10:13:53] <kshishkov> even if it's extrememly complicated to invoke several ioctl()s and then use write() I'd prefer OSS [10:14:01] <av500> kshishkov: +1 [10:14:10] <kshishkov> cartman: haven't you guessed it? [10:14:11] <mru> cartman: some way or other I suppose I'll do it regardless [10:14:20] <mru> but it probably means using an intermediate buffer [10:14:21] <mru> yuck [10:14:27] <cartman> good good :p [10:15:21] <av500> mru: cmon, one buffer for audio [10:15:52] <av500> mru: you are after 16 sample latency now? [10:21:07] * kshishkov suspects mru would need to allocate many buffers to allow realtime playback of Monkey Audio on BeagleBoard [10:22:37] <av500> one for each simian? [10:25:12] <Kovensky> 07:13.51 av500: mru: so, use OSS emulation on ALSA :) <-- did alsa ever fix their OSS emulation or do they keep using its brokeness to claim that OSS is a POS [10:25:21] <twnqx> kshishkov: which reminds me... .ape is supported by ffmpeg, right? [10:25:27] <mru> Kovensky: don't know [10:25:29] <mru> twnqx: yes [10:25:52] <av500> Kovensky: no idea [10:26:04] <av500> Kovensky: I doubt they fixed it [10:27:15] <kshishkov> av500: it's Monkey's Audio not because it employs monkeys in decoder but merely because it used monkeys in design and development [10:34:05] <kshishkov> BTW, anyone wants decoder writter specially for git.ffmpeg.org? [10:34:43] <Kovensky> most people with sound issues on linux are either ALSA trolls, people that believe the ALSA trolls, or freetards [10:35:20] <mru> alsa can actually be coerced into doing the right thing [10:35:29] <kshishkov> with pulseaudio? [10:35:31] <mru> if you replace the default configuration [10:35:49] <mru> set the default device to hw:0 or similar [10:36:10] <mru> that shuts off all it's nasty resampling, mixing, ipc backdoors, etc [10:36:15] <mru> -' [10:39:50] <Kovensky> mru: you still need dmix to be able to play more than one sound simultaneously though [10:40:18] <mru> no you don't [10:40:25] <cartman> Kovensky: or you get a Creative soundcard [10:40:29] <cartman> and it'll do hw mixing [10:40:35] <kshishkov> indeed [10:40:36] <mru> or any card with hw mixing [10:40:43] <mru> if you really care about it that much [10:40:50] <mru> otherwise you make do with one sound at a time [10:40:51] <Kovensky> won't help with my realtek hda :( [10:40:53] <cartman> yeah those are cheap nowadays [10:40:56] <Kovensky> and anyway [10:41:02] <Kovensky> OSS4 can do mixing in software [10:41:07] <av500> yes [10:41:14] <av500> and it does mixing where it belong [10:41:15] <cartman> HDA series are crap soundcards [10:41:17] <cartman> buggy shit [10:41:22] <mru> and dmix is the worst possible way of doing it [10:41:40] <kshishkov> cartman: they design good network cards though [10:41:45] <cartman> kshishkov: true [10:41:49] <mru> who? [10:41:53] <Kovensky> HDA is an intel spec [10:41:59] <cartman> ACPI too [10:42:00] <cartman> :P [10:42:03] <Kovensky> (aka Azalia) [10:42:08] <mru> the intel NICs are DEC designs originally [10:42:11] <kshishkov> mru: Realtek 8139 IIRC - the most famous NIC ever [10:42:20] <mru> infamous [10:42:26] <cartman> modprobe 8139too [10:42:27] <cartman> :p [10:42:39] <Kovensky> there's an 8139too.ko? [10:42:45] <mru> my motherboard has an onboard rtl8111 [10:42:50] <merbzt> I have a 8169 in my fitpc [10:42:54] <cartman> Kovensky: yes [10:42:55] * kshishkov remembers his surprise when LG NIC worked with DEC driver [10:42:55] <mru> 3/4 boots it doesn't even show up on the pci bus [10:42:56] <pross-au> kshishkov: pftt, everyone knows it was ne2k [10:43:12] <cartman> pross-au: ne2k was pretty stable for me [10:43:20] <Kovensky> quick, lspci equivalent for osx =p [10:43:21] <cartman> my first custom ethernet card [10:43:21] <merbzt> let's say it doesn't really work well [10:43:33] <cartman> Kovensky: System information :P [10:43:45] <Kovensky> cartman: can I run it from command line? :D [10:43:46] <kshishkov> at least Realteks had hardware bandwidth limiter connected to CPU load [11:32:49] <DonDiego> saste: have you thought about creating a libavfilter topic branch? [11:33:42] <saste> DonDiego: yes maybe I'll do [11:33:56] <mru> I think that would be a good idea [11:34:10] <saste> DonDiego: but some patches should be committed right now [11:34:26] <saste> the aspect ratio fix and the movie source [11:34:32] <saste> lots of users asking for that [11:35:15] <mru> nothing should be committed without proper review, no matter how many are asking for it [11:35:24] <mru> and the aspect ratio patch had review comments [11:35:55] <saste> mru: of course I mean *after* review [11:45:32] <Tjoppen> I've got some avc-intra samples to upload. should I put them in the usual spot, namely the ftp? [11:49:21] <kshishkov> yes [11:49:38] <kshishkov> preferably with decoder patch sent to ML :) [11:50:19] <Tjoppen> hehe :) [11:53:13] <Tjoppen> for avc-intra 50 it looks like an intra prediction issue, while avc-intra 100 just looks completely wrong. partly because it's 4:2:2 [11:54:02] <Dark_Shikari> avc-intra 50 is 10-bit [11:54:05] <Dark_Shikari> ffmpeg can't decode that properly [11:55:36] <Tjoppen> ah, that too [11:55:44] <Tjoppen> 50 ought to work though [11:55:51] <Dark_Shikari> why? [11:55:53] <Dark_Shikari> 50 is 10-bit [11:57:20] <Tjoppen> ah, I completely missed that [11:58:35] <Tjoppen> so the artifacts I see are probably things like the lowest two bits being truncated accumulating to visible errors? [11:58:59] <Tjoppen> also, it's interesting that the decoder outputs something semi-sane [11:59:16] <Dark_Shikari> not surprising at all [11:59:19] <Dark_Shikari> its not truncation [11:59:22] <Dark_Shikari> it's the opposite [11:59:24] <Dark_Shikari> overflow/saturation [11:59:30] <Dark_Shikari> 10 bits of range instead of 8 [12:01:52] <kshishkov> are you going to fix that? [12:02:17] <Dark_Shikari> irock is working on it, and uploaded his tree to github the other day [12:02:24] <Dark_Shikari> help is welcome. [12:04:22] <Tjoppen> would you have a url to said repo? [12:04:58] <Compn> spaam : nope, i asked a few ffmpeg-devel admins but none said they needed my help... [12:05:09] <Compn> michaelni and bcoudurier are admins iirc [12:07:13] <Dark_Shikari> https://github.com/irock/FFmpeg [12:08:51] <Tjoppen> cool. thanks [12:09:22] <Tjoppen> uhm, /MPlayer/incoming no longer exists - should samples go in /incoming instead? [12:09:32] <kshishkov> of course [12:09:40] <kshishkov> it was just moved up [12:10:03] <Tjoppen> ok. the site should be updated [12:10:36] <kshishkov> flame Diego [12:11:17] <Tjoppen> or I'll just put a patch on the ml for it [12:11:50] <Tjoppen> haha, awesome. avid outputs 10-bit 4:2:2 as normal 8-bit uyvy with the low-order bits stored separately [12:12:50] <Compn> i asked DonDiego to make symlinks [12:12:54] <Compn> but that didnt happen i guess ;\ [12:12:57] <DonDiego> Tjoppen: which url did i forget to update? [12:13:18] <DonDiego> i grepped everything for MPlayer/incoming i think [12:13:45] <Tjoppen> http://ffmpeg.org/bugreports.html [12:13:57] <Tjoppen> "cd -> /MPlayer/incoming" [12:15:47] <DonDiego> bcoudurier: why are you still asleep at the wheel and gabu is still not banned or moderated? [12:15:58] <DonDiego> sorry to bring this up in public, but this cannot continue [12:16:14] <Dark_Shikari> I already complained [12:16:17] <Dark_Shikari> I complained repeatedly [12:16:19] <Dark_Shikari> nothing has happened [12:16:24] <Dark_Shikari> our ML admins are incompetent [12:18:06] <Tjoppen> samples uploaded to /incoming/avcintra [12:19:22] <DonDiego> Tjoppen: oops, i committed locally but forgot to push, fixed - thanks for noticing [12:19:43] <Compn> DonDiego : what about symlinks from MPlayer/incoming to /incoming ? [12:20:00] <Compn> yes / no ? [12:20:17] <DonDiego> i see little point now that the docs are updated [12:20:40] <Compn> did you update every issue on roundup and bugzilla ? [12:20:46] <Compn> containing the old url [12:20:50] <DonDiego> no, why should i? [12:21:02] <DonDiego> incoming is not something you can link to [12:21:37] <Compn> ftp://upload.ffmpeg.org/MPlayer/incoming ? [12:21:39] <Compn> what ? [12:22:00] <DonDiego> you cannot link to files in there [12:22:21] <Compn> but you can link users to upload files there, and thats what carl has been doing for ages in the tracker [12:22:44] <DonDiego> well, now you send them to the new url... [12:23:02] <Compn> is there something technically wrong with doing a symlink ? [12:23:11] <DonDiego> no [12:23:20] <DonDiego> but i want to actively deprecate the old location [12:23:34] <Compn> it is actively depreciated [12:23:38] <Compn> since you removed the urls [12:23:54] <Compn> but to keep our old users afloat, who maybe wont check the new url, it might be nice to keep an old symlink alive [12:26:27] <DonDiego> i don't see any users being misled [12:26:52] <Compn> are you looking at ftp logs for MPlayer/incoming ? [12:27:14] <DonDiego> those old bugtracker urls were relevant when they got posted, but i don't think people follow them anymore [12:27:20] <DonDiego> i can do that later [12:28:12] <Compn> its just a good idea to have a symlink for a dir that we've used for incoming for 5+ years. cant say i didnt try... [12:28:39] <DonDiego> i'll look at the logs later [12:28:45] <DonDiego> ping me next week please [12:28:54] <DonDiego> i need to pack bags for fosdem now and run out [12:32:35] <Compn> bcoudurier : are you still accepting paypal for donations? i thought you stopped but now i cant remember. at least BBB seems to think you still are. [12:38:44] * elenril does an EvilLaugh [12:38:53] * elenril now officially knows quantum field theory [12:39:06] <cartman> it'll all be obsolote later on :P [12:40:01] <_av500_> its all meta knowledge... [12:40:09] <elenril> time to destroy the world [12:41:43] <cartman> michaelni: if this flames don't end I'll use your mails to train GMail spam filter [12:41:46] <cartman> seriously [12:42:00] <Dark_Shikari> good idea [12:44:25] <kshishkov> hmm? simple procmail rule on "leader.*" would suffice [12:52:45] <Dark_Shikari> how do I send just one patch for git send-email? [12:52:49] <Dark_Shikari> HEAD~2 sends the last two commits [12:52:54] <Dark_Shikari> I want to send the commit "HEAD~2" [12:52:54] <elenril> git send-email -1 [12:52:59] <Dark_Shikari> not HEAD~1 [12:53:13] <mru> git send-email -1 $refspec [12:53:27] <mru> e.g. git send-email -1 HEAD~2 [12:54:17] <elenril> won't that send HEAD~3? [12:54:30] <mru> not iirc [12:54:42] <Dark_Shikari> BBB: I confirmed that gcc doesn't do that [12:55:27] <elenril> mru: tested, it sends HEAD~3 [12:55:43] <mru> that's absurd [12:55:44] <BBB> Dark_Shikari: oh shit, that's bad, ok well ok more reason to apply then I guess [12:55:51] <elenril> mru: why, it's what i'd expect [12:56:02] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r79dec1541b ffmpeg/libavcodec/vp8.c: [12:56:02] <CIA-38> ffmpeg: VP8: faster deblock strength calculation [12:56:02] <CIA-38> ffmpeg: Convert hev_thresh logic to a LUT, simplify mbedge_lim calculation. [12:56:03] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r8a2c99b486 ffmpeg/libavcodec/vp8.c: VP8: slightly faster loopfilter sharpness logic [12:56:04] <elenril> err..wait, i'm wrong [12:56:06] <BBB> Dark_Shikari: does it change bla*2 to bla+bla? [12:56:06] <elenril> nvm [12:56:06] <mru> elenril: why would you expect that? [12:56:14] * elenril fails at basic math :) [12:56:27] <elenril> (though i have a good excuse) [12:56:32] <Dark_Shikari> BBB: yes, of course [12:56:45] <Dark_Shikari> gcc is just dumb [12:56:53] <mru> <insert sarcasm about quantum fields> [12:56:57] <Kovensky> elenril: "well, it's correct, for low enough values of 3"? [12:57:26] <elenril> mru: i'm allowed to say stupid things for the rest of the day after a hard exam ;) [13:00:58] * pJok turns on his quantum mechanics generation unit [13:26:07] <_av500_> geez this train is full of fosdem [13:28:08] <vipw> don't worry, it washes off [13:28:36] <jannau> _av500_: it was the obvious connection for the beer event [13:30:58] <thresh> :( [13:34:55] <pJok> _av500_, you wouldn't happen to know which init file mounts the sd card under android? [13:35:36] <_av500_> pJok: vold [13:36:00] <_av500_> the volume deaemon [13:37:10] <pJok> ahh [13:37:35] <pJok> im pondering on if i can get it to initialize earlier so i can actually use it for internal storage [13:43:05] <jannau> av500: where are you in ice 14? Can I bring anything (coffee + cake) from the station? [13:43:30] <pJok> _av500_, seems like you need to recompile the kernel for it... damnit [13:47:53] <_av500_> jannau: car 36 [13:48:12] <mru> long train... [13:48:37] <jannau> mru: they start at 20 [13:48:44] <_av500_> jannau: black tea please [13:49:31] <jannau> ok [13:49:40] * cartman notes that _av500_ is more Turkish than anything else [13:51:27] <jannau> I'm already in car 36 [13:53:15] <_av500_> jannau: i hope they dont decide to merge the cars physically [13:53:37] <_av500_> cartman: not sugar with a drop of tea in it [13:53:53] <cartman> thats me [13:53:54] <cartman> :p [13:55:13] <jannau> _av500_: unlikely, different platforms [13:55:42] <_av500_> jannau: watch DB :) [13:57:41] <jannau> yes, the rheinbrÃŒcke just before the station is infamous for derailing trains [14:08:37] <BBB> wbs: if that patch to issue 2583 works, submit it to ML please ;-) [14:15:16] <Dark_Shikari> BBB: fun... [14:15:23] <Dark_Shikari> latest ffmpeg and libvpx, gcc 4.3, win32 [14:15:26] <Dark_Shikari> libvpx: 34fps [14:15:27] <Dark_Shikari> ffvp8: 48fps [14:15:44] <Dark_Shikari> (ïŸâïŸ)ïœ±ïŸïŸå«å«ïŸãœïŸãœïŸãœïŸ ïŒŒ / ïŒŒ/ ïŒŒ [14:16:05] <kierank> lol [14:16:14] <Dark_Shikari> one wonders how libvpx could be so bad [14:17:00] <mru> nih driven development [14:17:13] <cartman> nice [14:18:11] <kshishkov> I thought they copy ideas from us as well [14:18:18] <Dark_Shikari> Total work put into vp8.c, not counting adding features that libvpx doesn't have (e.g. emu edge) in the past 6 months: a day or two [14:18:28] <Dark_Shikari> total work put into libvpx decoding: who knows how many man months [14:18:31] <Dark_Shikari> progress: libvpx still sucks [14:18:39] <cartman> thats how the economy works :p [14:22:40] <cartman> Dark_Shikari: what you are discarding that, FFmpeg already has basic & intermediate infrastructure for codec optimization [14:23:01] <Dark_Shikari> not really relevant, vp8 doesn't use any of it [14:23:02] <cartman> they possibly didn't want whole ffmpeg dependency for some reason [14:23:14] <Dark_Shikari> except basic stuff like intreadwrite [14:23:32] <cartman> no dsp function used? [14:23:35] <cartman> none at all? [14:23:36] <Dark_Shikari> sure -- vp8 ones [14:23:50] <cartman> and those in turn are standalone? :) [14:23:53] <Dark_Shikari> yes [14:24:02] <cartman> oh well nicely done then ;-) [14:24:03] <Dark_Shikari> the only dsp functions it borrows are intra pred [14:24:05] <Dark_Shikari> which are dead trivial [14:24:32] <Dark_Shikari> but still, the point is -- they have 6-10 years of an entire dev team on it [14:24:49] <Dark_Shikari> we have 3 people, none of which were anywhere close to full-time for anywhere more than a week or three. [14:24:50] <cartman> team of indians maybe [14:25:02] <kshishkov> Chinese [14:26:19] <pJok> Dark_Shikari, outsource to india! [14:26:43] <kierank> pJok: they already learnt that lesson for mbaff [14:26:54] <cartman> Google is a complex infrastructure [14:27:05] <cartman> its not easy to find a reason for this libvpx thing for example [14:27:38] <Kovensky> libvpx is not google's fault, at least not directly [14:27:47] <Kovensky> it spent a lot more time in duc--on2's hands [14:27:51] <pJok> cartman, at least android was set in motion for them to have another platform to make money off and put google search on [14:28:08] <cartman> pJok: Android has its own share of problems too [14:28:09] <Dark_Shikari> cartman: no, it's simple [14:28:13] <Dark_Shikari> 1) incompetent coders [14:28:27] <pJok> cartman, of course... java is one of them ;) [14:28:29] <Dark_Shikari> 2) open source model (read: collaborative development) is orders of magnitude more efficient than closed [14:28:40] <cartman> 1 cannot be easily solved [14:28:47] <cartman> their recruitement process sucks [14:29:06] <KotH> 1 can be easily solved: hire only competent staff [14:29:18] <cartman> KotH: where competent is defined by* [14:29:19] <cartman> ? [14:29:22] <KotH> ok, for this the whole HR crew needs to be replaced by competent people [14:29:22] <cartman> DNA? [14:29:23] <cartman> :P [14:30:04] <KotH> cartman: did you know what every hire at google has to be interviewed by an engineer working in the field where the hiree is been interviewed for? [14:30:20] <cartman> KotH: of course, I did an interview with them [14:30:22] <KotH> cartman: ie, at least the engineer gets an idea whether the guy is competent or not [14:30:49] <_av500_> i would says their hiring works as they now have BBB [14:30:52] <KotH> but: HR is so incompetent that most engineers refuse to waste their time with people totaly unfit for the job [14:32:19] <cartman> well I can't care less as long as they maintain GMail [14:34:34] <_av500_> maybe BBB can make it not mangle git patches [14:35:56] * cartman watches dancing kame [15:11:10] <jannau> this train is indeed full of fosdem, even the 1st class [15:11:18] * jannau waves to _av500_ [15:11:34] <kierank> is there wifi on that train? [15:11:36] <kierank> or 3g? [15:13:09] <jannau> 3g but I guess we could easily reach full covered with mobile hotspots [15:13:16] <jannau> coverage [15:13:20] <kshishkov> av500 usually brings his own [15:13:30] <cartman> leech his 3G [15:14:50] * jannau sits next to another haiku dev [15:17:37] <kshishkov> jannau: what? there are two of them? [15:17:49] * _av500_ waves to jannau [15:17:52] <jannau> apparently [15:17:58] <cartman> _av500_ is lagging [15:18:22] <_av500_> cartma is slacking [15:18:25] <_av500_> +n [15:18:26] <cartman> see [15:18:33] <cartman> _av500_: I am compiling man [15:18:39] <cartman> make -j32 while I chat [15:18:47] <jannau> hmm, just a single wlan on board, wpa2 encrypted, essid "lgf" [15:18:56] <Flameeyes> cartman: have you not applied the 200loc patch? [15:19:02] <_av500_> cartman: you dont need to rebuild android in order to install one app [15:19:07] <cartman> Flameeyes: kernel one? :) [15:19:11] <Flameeyes> yeah [15:19:15] <cartman> _av500_: just in case! [15:19:29] <cartman> Flameeyes: ah sure, thats how I can talk && make -j32 :D [15:19:49] <cartman> _av500_: you never compiled Qt, it shows ;> [15:19:54] <_av500_> Flameeyes: there is much more elegant solution in 2 lines of bash, no? [15:20:00] <Flameeyes> _av500_: no... [15:20:10] <_av500_> cartman: qte2.x all the time :) [15:20:15] <Flameeyes> there is a "wannabe elegant" solution that shown that whoever came up with the cgroup idea was on crack [15:20:23] <jannau> _av500_: we could troll lennart tomorrow [15:20:25] <cartman> _av500_: I've a minion over @ FOSDEM, ;P [15:20:38] <Flameeyes> because the main "original" user of cgroups (lxc) is incompatible with what Lennart, Kay and Greg decided would be the official way in the kernel [15:21:03] <Flameeyes> to the point that the whole shebang has a huge FAIL sticker over it from my pov [15:21:37] <cartman> >>I get this error: âglibc detectedâ [15:21:38] <cartman> wow [15:21:48] <cartman> fatal error [15:21:58] <_av500_> cartman: run! [15:22:00] * cartman loves StackOverflow [15:22:39] <kierank> cartman: you ask them to send you the codez? [15:22:49] <cartman> nah the guy is right [15:22:51] <cartman> *** glibc detected *** ./a.out: free(): invalid next size (fast): 0x09f931f0 *** [15:22:58] <cartman> how fucked up is that output [15:23:02] <Flameeyes> very fucked up [15:23:10] <cartman> glibc detected what [15:23:15] <cartman> stupid Drepper [15:23:15] <Flameeyes> but not as fucked up as the "repo" tool [15:23:30] <cartman> Flameeyes: git fuckage ;> [15:23:39] <Flameeyes> cartman: nono it's repo the fuckage [15:23:47] <cartman> heheh [15:24:14] <Flameeyes> "repo branches" -> first entry is "automake111"; "repo checkout automake111" -> "no project has branch automake111" [15:24:15] <Flameeyes> wtf [15:24:34] <cartman> thats a nice version of automake :D [15:24:53] <Flameeyes> [that's 1.11, not 1.1.1 :P] [15:25:51] <cartman> v111 was better :> [15:26:48] <Kovensky> <@Flameeyes> to the point that the whole shebang has a huge FAIL sticker over it from my pov <-- yes it was, and the whole idea was copied from a BFS feature but shoehorned in whatever infrastructure the kernel already had that seemed appropriate enough IIRC [15:27:19] <cartman> Kovensky, Flameeyes whats the shebang story? [15:27:27] <Flameeyes> Kovensky: the huge FAIL sticker is not over the 200loc patch but over cgroups [15:27:46] <Flameeyes> cartman: http://blog.flameeyes.eu/2011/01/10/cgroups-woes have fun :D [15:27:58] <cartman> ah always full of information :D [15:28:56] * _av500_ thinks Flameeyes is a team of blog writers [15:29:30] <Flameeyes> _av500_: no I just lack a life at over 100mt from a keyboard :P [15:29:44] <_av500_> 100 sounds to ,uch [15:29:48] <_av500_> much [15:29:56] <_av500_> that would allow you to go to a pub or so [15:29:58] <Kovensky> Flameeyes: talking about your blag, when I was reading some older entries on your blag from google reader I kept getting error messages with this logo: http://puu.sh/Frs [15:30:28] <Flameeyes> Kovensky: it should be fixed now, that's basically a webapp total failure [15:30:47] <cartman> Flameeyes: ah so cgroups is the new sysfs [15:30:49] <Kovensky> I enjoyed the irony from the logo :) [15:31:11] <Flameeyes> yeah "just works" and rails don't go hand in hand [15:31:45] <Flameeyes> fwiw http://blog.flameeyes.eu/2011/02/04/a-deji-vu-is-usually-a-glitch-in-the-ra… also gave me a few more itches about Rails in general [15:32:08] <Flameeyes> sooner or later I'll look into converting my blog to something else...likely going to try the JSP stuff again, at the time I tried it it was quite high-performance [15:32:30] <Kovensky> lol JSP [15:32:43] <Flameeyes> what's the alternative? :) Wordpress? [15:32:44] <Kovensky> ever looked at Mojolicious? [15:32:52] <cartman> Flameeyes: plain texy [15:32:55] <cartman> text* [15:33:11] <Flameeyes> Kovensky: oh god.. perl? :P I can't read that stuff!! >_< [15:33:40] <Flameeyes> seriously my choice would end up in a language I can sort-of understand and write.. and I can read Java better than Python [15:33:42] <Kovensky> and you go and decide to use... Java? >_< [15:34:00] <cartman> Python is Read/Write unlike Perl [15:34:15] <Flameeyes> cartman: my python sucks, and lu_zero can testify that [15:34:56] <cartman> Flameeyes: use whatever works approach :-) [15:35:19] <Flameeyes> yeah that's about it.. typo worked for me for a few years now... [15:36:03] <Kovensky> < cartman> Python is Read/Write unlike Perl <-- blasphemy! [15:36:28] <Flameeyes> guuuh Roller is now Apache? [15:36:56] <cartman> after Sun went the way of well... Oracle [15:38:23] <Kovensky> talking about sun / oracle, I remember someone saying that zfs wasn't GPL-licensed because the engineers refused the GPL [15:38:37] <Kovensky> but why do people think that GPL is the only free software license? o_O [15:38:38] <cartman> Engineers can't refuse shit [15:38:40] <cartman> management does [15:52:00] <kshishkov> Daemon404: sorry, no work on multichannel WavPack for you [15:52:09] <Daemon404> lol, not here about that [15:52:17] * Daemon404 sae the commit though. [15:52:20] <Daemon404> s/sae/saw/ [15:53:18] <Daemon404> actually here to poke mru about some arm-related docs. [15:53:54] <thresh> he's probably getting drunk already [15:54:16] <kshishkov> maybe it's too early for him [15:54:24] <kshishkov> thresh: BTW, where are you? [15:54:31] <thresh> kshishkov: at home :( flu. [15:55:31] <kshishkov> thresh: yes, mru was right saying two Konstantins for FOSDEM is too much [15:56:02] <thresh> kshishkov: ha ha, there would be another Kostya [15:56:14] <thresh> a friend of mine, mozilla-russia guy [15:56:43] <thresh> suppose the universe decided three Kostyas is too much :) [15:57:21] <kshishkov> thresh: then my University wouldn't exist - there were three Kostyas in my group there (including me) [16:02:27] <cartman> have a nice weekend! [16:08:49] <BBB> Dark_Shikari: ouch that's quite bad (for them :-p) [16:10:11] <BBB> Dark_Shikari: I wonder if can beat them further after -mt [16:10:18] <BBB> astrange: ping ping ping please rebase your patch to master [16:10:34] <Kovensky> lol [16:21:45] <Compn> Error occurred while sending the message: [16:21:45] <Compn> 421 Connection rate too high, try again later [R0203001] [16:22:12] <Compn> my isp's email server has been down 5+ hours [16:28:43] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r1338dc0823 ffmpeg/libavformat/ (movenchint.c rtpenc_chain.c rtsp.c sapenc.c): (log message trimmed) [16:28:43] <CIA-38> ffmpeg: libavformat: Use avcodec_copy_context for chained muxers [16:28:43] <CIA-38> ffmpeg: This avoids having the chained AVStream->codec point to the same [16:28:43] <CIA-38> ffmpeg: AVCodecContext owned by the outer AVStream. The downside is that [16:28:44] <CIA-38> ffmpeg: changes to the AVCodecContext made after calling av_write_header [16:28:44] <CIA-38> ffmpeg: cannot be detected automatically within the chained muxer. [16:28:45] <CIA-38> ffmpeg: This avoids having to manually unlink the chained AVStream->codec [16:30:57] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * rf124b087ee ffmpeg/libavformat/ (avformat.h utils.c version.h): [16:30:57] <CIA-38> ffmpeg: libavformat: Add a function for freeing an AVFormatContext [16:30:57] <CIA-38> ffmpeg: This function is useful for freeing data structures allocated by [16:30:57] <CIA-38> ffmpeg: muxers, which currently have to be freed manually by the caller. [16:30:57] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:37:46] <spaam> Compn: ok :) [16:39:17] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * rff19748977 ffmpeg/doc/APIchanges: [16:39:17] <CIA-38> ffmpeg: Add an APIchanges entry for avformat_free_context [16:39:17] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:40:31] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * rb22dbb291d ffmpeg/ (5 files in 2 dirs): [16:40:31] <CIA-38> ffmpeg: Use avformat_free_context for cleaning up muxers [16:40:31] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:41:39] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r397ffde115 ffmpeg/libavformat/rtpenc_chain.c: [16:41:39] <CIA-38> ffmpeg: rtpenc_chain: Don't copy the time_base back to the caller [16:41:39] <CIA-38> ffmpeg: If required, the caller can do this itself. ff_write_chained rescales [16:41:39] <CIA-38> ffmpeg: timestamps as necessary, and all current callers of rtpenc_chain [16:41:39] <CIA-38> ffmpeg: use ff_write_chained, making this timebase copy unnecessary. [16:41:40] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:43:16] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r5306bf41a6 ffmpeg/libavformat/ (Makefile movenchint.c): [16:43:16] <CIA-38> ffmpeg: movenchint: Use rtpenc_chain for setting up the chained RTP muxer [16:43:16] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:46:58] <Daemon404> Compn, your first mistake was using your ISP's servers in the first place. [17:10:49] <Compn> yes, i know [17:10:51] <Compn> blame the victim [17:11:57] <ohsix> yea, especially when one of the things your isp purports to do for your money is get you some mail [17:23:21] <peloverde> quiet morning [17:23:38] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r185a155e57 ffmpeg/libavformat/applehttp.c: [17:23:38] <CIA-38> ffmpeg: applehttp: Handle absolute paths relative to the current server [17:23:38] <CIA-38> ffmpeg: This fixes roundup issue 2583. [17:23:38] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [17:26:52] * elenril should've gone too [17:28:40] <BBB> wbs: hi peloverde [17:28:42] <BBB> ops [17:28:51] <elenril> lol [17:28:53] <BBB> that was a weird combination of two sentences in different timeframes [17:29:00] <BBB> let's go back [17:29:17] <BBB> wbs: can you merge the two checks in url_make_absolute() or somehow share code between the codepaths in there? [17:29:22] <BBB> wbs: it looks like spaghetti now [17:29:31] * elenril likes spaghetti [17:29:32] <BBB> peloverde: fosdem, probably [17:30:12] <peloverde> most likely [17:34:51] <BBB> Dark_Shikari: which testsample for your patch from yesterday? [17:37:44] <BBB> Dark_Shikari: quick test on sintel shows that it's significantly slower (!!) [17:37:53] <BBB> 44 vs. 51 cycles [18:00:54] <uau> Flameeyes: what's the problem with cgroups? that blog post doesn't seem to say much beyond some previously written software not working nicely with current API [18:02:02] <Flameeyes> uau: beside that the "previously written" is the one for which cgroups were implemented to begin with [18:02:38] <uau> well that still doesn't by itself identify any significant problem IMO [18:03:19] <elenril> Flameeyes: written any book yet? ;) [18:03:32] <Flameeyes> and that the "current API" was decided single-handedly without checking whether the rest of the software worked at all, while the preivous interface would have done nicely for both the old and the new software alike [18:03:55] <Flameeyes> elenril: no, I'm not a native english speaker, publishers don't want me [18:04:38] <elenril> how evil of them [18:05:28] <uau> Flameeyes: so the changes caused problems for some software, still doesn't tell anything about possible problems with the current version [18:05:35] * kierank wonder why readline does a double free [18:05:37] <Flameeyes> ... [18:06:14] <elenril> kierank: more free â more better [18:26:11] * elenril wonders if it's possible to make RA addresses lower priority than DHCPv6 addresses [18:26:35] <kierank> typical...readline doesn't double free under valgrind [18:30:00] * _av500_ waves from fosdem [18:31:17] * Tjoppen waves from umeÃ¥ [18:32:29] * siretart waves to fosdem [18:48:08] <wbs> BBB: the if checks can't really easily be merged, they do similarlooking stuff, but not really similar enough to be factorized. if you're comfortable with c string handling, it's not all that bad :-) [18:48:18] <wbs> BBB: thanks for applying anyway :-) [18:52:49] <wbs> and _finally_ we got the muxer cleanup function... so that libav users don't suddenly start leaking memory just because libavformat started doing something it didn't do before [18:57:44] <BBB> that's indeed good [18:57:45] <BBB> much-needed [18:58:28] <wbs> the memory leaks that I found the earlier days would have been fixed by that. and they've been running in production at $dayjob for a few months ;P [18:59:04] <wbs> I usually valgrind it all when I upgrade ffmpeg there, but apparently I didn't valgrind the configuration that uses those muxers [19:01:44] <kshishkov> well, is anybody going to review Xan4 decoder patch? [19:02:40] <BBB> kshishkov: I guess I can... [19:02:46] <BBB> what was the thradname again? [19:03:08] <kshishkov> [PATCH 0/2] Origin Wing Commander IV decoder or something like that [19:20:49] <kierank> is there any way of getting lavf to timeout if it can't open an udp stream [19:22:15] <wbs> kierank: hmm, that might be useful. if we'd get easily settable protocol specific avoptions, that might be a good candidate for that. (we've got protocol specific avoptions already, they're just not easily settable from the command line) [19:25:35] <j-b> michaelni: are you coming to FOSDEM? [19:39:35] * elenril kicks debian's isc-dhcp-client maintainer [19:40:16] <elenril> what an awesome idea to release with dhcpv6 client completely broken :? [19:41:29] <michaelni> j-b, with the whole current mess and accusations and lies against me, i really prefer to stay far away from FOSS [19:41:30] <ohsix> isn't stateless autoconfiguration the beans [19:41:54] <michaelni> I thought many of the people to be my friends ... [19:42:36] <Compn> oh someone mentioned michaelni had a wikipedia page! [19:42:40] * Compn goes to look at that [19:43:37] * michaelni is not in the mood to read more libel so ill not look at wikipedia today [19:43:43] <Compn> ooh [19:43:45] <Compn> yeah better not [19:43:50] * Compn looks at ffmpeg page [19:43:53] <Compn> yeesh [19:43:55] <ohsix> is it libel if you never see it [19:44:03] <Compn> shcrodingers libel [19:45:56] <michaelni> ohsix, its is if i "see" it indirectly too, like someone else sees it and tells me or changes his behavior depending on it [19:46:12] <michaelni> ;) [19:46:27] <ohsix> unknowable things aren't worth fretting over [19:46:37] <Compn> argh, isp news server still down [19:46:40] <Compn> time to use gmane. [19:46:45] <Compn> er isp mail server [19:47:28] <ohsix> gmane is awesome; i read stuff there, getting main is for jerks [19:49:20] * michaelni fails to find a wikipedia page about himself [19:50:23] <Compn> yes, maybe it was a joke ? [19:50:25] <Compn> hmm [19:52:47] <michaelni> Anyway, if anyone catches someone spreading lies or libel about me, please tell me. I no doubt am inpolite and occasioanlly an asshole but some of the recent things IMHO go too far, i was not behind everything that did not work out like everyone wanted [19:54:39] <ohsix> how is anyone supposed to know if it's a lie [19:54:59] <michaelni> ask for evidence & facts [19:55:13] <michaelni> mailing list postings irc logs whatever [19:55:24] <ohsix> how do they know theres even a basis for asking evidence to be presented [19:55:54] <iive> vmrsss ?? [19:56:44] <ohsix> reputations and names are like trademarks; got to defend them yourself if you register ;] [19:56:47] <j-b> michaelni: well, I just thought it to be a cool place to find a solution [19:57:36] <michaelni> j-b, how far is fosdem from vienna? [19:57:51] <michaelni> in terms of time/money [19:58:02] <michaelni> and from when to when is fosdem? [19:58:18] <j-b> tomorrow and sunday [19:59:07] <michaelni> thats a little narrow for me in terms of planing and packing and finding a cheap way to get there [19:59:35] <j-b> 99euro to get there [19:59:39] <Compn> maybe could get some kind of foundation to pay for that... [19:59:47] <kshishkov> j-b: from where? [19:59:54] <j-b> vinna [19:59:55] <j-b> vienna [20:00:06] <j-b> kshishkov: tomorrow, 9:40 [20:00:15] <michaelni> 99 with what? train airplane? [20:00:23] <j-b> airplane, ofc [20:00:24] <michaelni> 9:40 iam sleepimg [20:00:31] <kierank_> lol [20:00:37] <kshishkov> j-b: 9:40 is ETA for me [20:00:46] <j-b> 21:10 20EUR [20:00:57] <thresh> 99 euro for a plane flight, that's ridiculously low [20:00:58] <j-b> kshishkov: 9:40am [20:01:04] <BBB> wbs: https://roundup.ffmpeg.org/issue2586 [20:01:22] <j-b> kshishkov: 21:10, 20EUR from Vinna [20:01:45] <j-b> +e [20:01:57] <kshishkov> j-b: Ryan Airways? 120 EUR if you want to get by actual plane and such? [20:02:17] <j-b> kshishkov: http://quicktrip.brusselsairlines.com, of course [20:02:29] <j-b> and 125EUR to come back from BRU to VIE [20:03:01] <michaelni> j-b, they ll kill me i dont need a flight back, just cheap life insurance [20:03:11] <j-b> michaelni: they won't. [20:03:41] <kierank> kshishkov: nothing wrong with ryanair [20:03:54] <j-b> they are clever enough not to do so [20:04:16] <michaelni> j-b, yeah it will look like an accident [20:04:30] <j-b> michaelni: come on.... [20:04:36] <kierank> michaelni: nobody is going to kill you [20:04:39] <j-b> michaelni: FFmpeg needs you [20:04:41] <michaelni> iam joking [20:04:49] * thresh loves ryanair [20:04:51] <j-b> for the exact same reason than FFmpeg needs mru [20:04:54] <michaelni> i know that but iam trying to find an excuse [20:05:00] <j-b> and FFmpeg needs Dark_Shikari [20:05:21] <j-b> michaelni: seriously, come. even just on the sunday. [20:05:32] <j-b> We'll find a way to discuss. [20:05:43] <j-b> FFmpeg is too important for this mess not to end; [20:06:03] <Sean_McG> FWIW, I agree. [20:09:42] <ruggles> can ffmpeg still add streams after read_header() if a packet for a new stream is encountered? [20:10:15] <wbs> ruggles: iirc yes, there's a demuxer flag that says whether it usually does that, too [20:10:50] <Compn> what happened last time michaelni went to a convention? it saved ffmpeg for a few years ? [20:10:53] <Compn> ehe [20:11:01] * Compn forgets what convention it was [20:11:15] <ruggles> wbs: interesting. how does ffmpeg (the app) handle that? [20:11:41] <michaelni> Compn, i was at a convention? [20:12:00] <wbs> ruggles: I guess it keeps track of which ones have a decoder opened yet or not, if you get a packet for a stream that you haven't opened the decoder for yet, just open it (and decide what to do with it) [20:13:18] <wbs> BBB: I've got code in progress for handling that case [20:14:16] <skal> +1 [20:14:18] <elenril> michaelni: yes, but we erased your memory of it [20:14:55] <michaelni> elenril, do you have proof? ;) [20:15:49] <j-b> proofs can be erased :D [20:15:59] <j-b> photo can be photoshopped [20:16:32] <michaelni> j-b, you first need a photo from me ;) [20:17:19] <j-b> pff... [20:17:29] <j-b> Anyway, you should come. [20:17:38] <j-b> and I can guarantee your safety and a normal debate [20:17:50] <michaelni> j-b, if it was in walking distance i would [20:18:00] <j-b> it is a plane distance [20:20:12] <iive> how much time would it take with train? [20:20:58] <BBB> michaelni: I'm pretty sure foundation can cover your flight expenses if you ask [20:21:27] <michaelni> BBB 100 euro is no problem for me [20:21:45] <michaelni> but iam not a traveller [20:21:54] <BBB> expenses so you guys can sit in a nice restaurant and talk shit out [20:22:01] <BBB> under j-b's guidance, I'm sure [20:22:42] <j-b> I can make people talk [20:22:44] <j-b> :) [20:22:53] <BBB> j-b: wine does a lot of good stuff to people [20:22:54] <ubitux> btw, no one has news from Jacob? [20:22:56] <BBB> so does wodka [20:23:05] <j-b> BBB: good idea, vodka [20:23:05] <iive> it is much harder to avoid answer when talking face to face. at least without looking really bad. [20:23:15] <michaelni> BBB wine causes headache at best [20:23:21] <j-b> iive: and it avoids the misunderstandings of the ml [20:23:32] <BBB> j-b: please show michaelni the difference between good wine and baf wine [20:23:35] <j-b> michaelni: you haven't tested some good wine then; [20:23:41] <BBB> :) [20:23:48] <j-b> BBB: I have a very nice bottle here [20:24:01] <j-b> but if I sneak it out, my g/f is going to kill me [20:24:08] <BBB> from the ffineyard? [20:24:40] <j-b> Chateau Margaux [20:25:23] <j-b> michaelni: please, come; [20:28:16] <thresh> hmm, 300 euro for a bottle [20:28:36] <thresh> and that seems to be the cheapest one of the whole line [20:28:54] <j-b> more or less, yes [20:29:11] <thresh> you french are *weird* [20:29:30] <j-b> I know [20:29:52] <j-b> but, I'll live with it [20:30:41] <kshishkov> j-b: but some Russians even commit suicide with your wine [20:31:04] <Flameeyes> j-b: you french still have the curse of the peritÃ©l over your heads! >_< [20:31:17] <j-b> Flameeyes: :) [20:31:26] <j-b> Flameeyes: where are you now, btw? [20:31:36] <Flameeyes> j-b: in my office as usual :| [20:31:45] <j-b> .it ? veneto? [20:31:53] <Flameeyes> playing with ruby-elf and finding bugs in elflickers [20:32:01] <Flameeyes> yup, Venice inland (Mestre) [20:33:14] <thresh> kshishkov: d [20:33:21] <thresh> err [20:33:34] <j-b> Flameeyes: lucky you [20:33:41] <Flameeyes> j-b: not sure of that :) [20:33:48] <thresh> kshishkov: you mean fill the whole pool with a wine like that and then drown there? [20:34:48] <kshishkov> thresh: nope, IIRC last year some guy bought a bottle of some young French wine for $50000 and drank it. It was effectively poison [20:38:29] <siretart> michaelni: I'm flying from nuernberg, and it's about 200EUR from here. 120EUR from vienna seems increadibly cheap to me. If you can, I'd love to meet you in bruessels [20:39:00] <j-b> michaelni: what can I say/do to make you come? [20:39:09] <j-b> michaelni: what can I say/do to make you write a MVC decoder? :D [20:39:16] <j-b> should I kill 2 kittens? [20:39:33] <kshishkov> 3 goats [20:39:44] <Flameeyes> siretart: hey since you're around.. how's going with OpenVZ? :) /me longing for IPv6 [20:39:46] <j-b> I can do that [20:40:06] <Sean_McG> I heard the last IPv4 block was handed out a few days ago. [20:40:24] <Sean_McG> it's the beginning of the end [20:40:41] <wbs> good thing we've got quite good IPv6 support in ffmpeg nowadays [20:40:46] <iive> j-b: try to bribe him with 2000â¬ [20:40:59] <j-b> iive: to come? or for MVC? [20:41:03] <Flameeyes> Sean_McG: my ISP still rather provide me with 6 IPv4 than giving me an IPv6 subnet... it's not yet the beginning of the end [20:41:03] <iive> mvc [20:41:12] <Anaerin> Sean_McG, A friend of mine has 3 /16's for sale, if you need IPs. [20:41:16] <Sean_McG> Flameeyes: the providers are the problem. [20:41:24] <j-b> iive: then, it is fucking cheap [20:41:36] <j-b> iive: even I, can pay it [20:42:27] <Sean_McG> anyways, I'mma shut down my VMs, back 'em up and then take a nap [20:42:29] <Tjoppen> new regular ordinary swedish meal time \o/ [20:42:35] <Sean_McG> you folks take it easy, enjoy FOSDEM [20:42:58] <iive> j-b: well, it's michael's final word. [20:43:08] <j-b> iive: sure... [20:43:21] <j-b> but I believe than even I can pay 3 time that price [20:43:24] <iive> btw, what is mvc? [20:43:34] <siretart> Flameeyes: good news and bad news: good news is that we do now have ipv6, but openvz's ipv6 support sucks. hard, so I fear we won't be able to offer this soon :-( [20:44:06] <Flameeyes> uhm, ouch on that openvz support.. but what is it that you won't offer? openvz or ipv6 entirely? [20:44:29] <thresh> ipv6 works nicely in openvz [20:45:17] <siretart> thresh: unfortunately not with venet interfaces [20:45:54] <siretart> and configuring individual bridges for each customer is out of question [20:46:43] <siretart> Flameeyes: we are still trying to figure out what we can technically do. ipv6 with kvm for example is no problem and something that you can have right now [20:46:55] <siretart> but we really should take this to /query, I guess [20:47:54] <Flameeyes> sorry was just curious about the situation with that given the amount of hubhub over ipv6 lately, nothing really important now :) [20:48:05] <iive> j-b: stereoscopic 3D ? [20:48:07] <thresh> siretart: they should work [20:48:08] <kierank> lu_zero: is cancelling the thread lavf is running in the way to stop udp stream opening from blocking? [20:48:14] <thresh> once i'm at work, will test [20:48:15] <j-b> iive: yes [20:48:33] <j-b> iive: not to mention a correct 2D-3D filter in GPL [20:49:36] <siretart> thresh: I did experiment with that. it totally messes up the host routing and in my tests was rather unreliable. veth interfaces OTOH work just nice [20:49:53] <j-b> wbs: how do I know if FFplay will be able to seek in a file? [20:50:26] <thresh> siretart: I see [20:50:35] <wbs> j-b: hmmm.. there's like 2-3 different methods for seeking in ffplay [20:50:41] <kshishkov> j-b: avc intra please [20:50:54] <kshishkov> j-b: and please help Peter with Bink-b [20:50:59] <j-b> kshishkov: lol [20:51:11] <j-b> wbs: nice. [20:51:27] <kierank> j-b: well someone's already working on avc-intra 50 (I think that's the one with 10-bit precision) [20:51:52] <kierank> i mean kshishkov [20:52:02] <j-b> wbs: av_seek_frame [20:52:28] <kshishkov> kierank: iKnow [20:53:01] <j-b> I really should setup a bounties page for codecs on videolan.org [20:53:12] <wbs> j-b: ffplay seems to use avformat_seek_file actually [20:53:21] <kierank> j-b: i suggested something like kickstarter.com for ffmpeg [20:54:05] <kshishkov> j-b: what, you're playing for each .dll ? [20:54:39] <j-b> kshishkov: ? [20:55:17] <kshishkov> well, codec bounty == bounty for codec == bounty for codec even in DShow .dll?\ [20:55:35] <j-b> no [20:55:46] <kshishkov> only VfW dll? [20:55:58] <j-b> feature bounty = bounty for codec = codec inside lavc for GPL [20:57:06] <Sean_McG> wow...Amazon is amazing... I ordered Dr. Who seasons 3 & 4 on Wednesday afternoon, they already arrived today. [20:57:43] <elenril> beware, they're watching you [20:58:00] * kierank watches elenril [20:58:02] <elenril> they knew you'd order it so they sent it sooner [20:58:11] <Sean_McG> eheheh [20:58:17] <kshishkov> maybe they were just very happy to get rid of it [20:58:54] <pJok> kshishkov, http://pucko.se/Images/ProductImages_200/17287.jpg [21:00:16] <Sean_McG> what is that, chocolate milk? [21:00:55] <pJok> swedish chocolate milk [21:01:06] <pJok> which isn't really true, since its made in denmark [21:45:51] <wbs> Flameeyes: the lscube bugzilla db seems to be down, in case you didn't know [21:46:13] <Flameeyes> wbs: thanks... not sure if I have a clue on what my access on that box should be but will check [21:46:18] <Flameeyes> since I guess lu is in bruxelles right now [21:46:29] <kshishkov> BBB: thanks for review [22:10:22] <ruggles> pross-au: any insight on issue 2556? [22:13:22] <pross-au> mmm [22:14:14] <pross-au> for some samples, the stream_guid info is wrong, therefore the preference given to stream2_guid chunks [22:14:43] <ruggles> that seems ok. but some streams seem to not have stream_guid info at all. [22:14:55] <pross-au> oh wow [22:15:14] <pross-au> downloading.. [22:16:29] <ruggles> if you change line 801 in wtv.c to accept negative stream index you'll see lots more streams. but most are empty (no data ever sent with that sid). [22:17:08] <pross-au> Yes [22:17:10] <ruggles> but in this case the ac3 stream is not empty. and in one of the other samples there is a non-empty stream but it's just silence. [22:17:46] <pross-au> ah [22:17:50] <pross-au> interesting [22:20:05] <BBB> kshishkov: byand-large it looks good to me, all I could see is some potential security issues, but nothing big [22:20:17] <BBB> kshishkov: so on next review I'll probably ok, wait for 1-2 days and commit [22:20:23] <BBB> unless someone else wants changes [22:20:39] <ruggles> pross-au: maybe the stream_guid streams are supposed to be primary, but something about the way that file was recorded marked the mp2 stream as primary instead? [22:21:28] <Sean_McG> even though it's described as commentary for the visually impaired? [22:22:00] <ruggles> dunno... maybe whoever recorded it set some setting in the capture software to choose that stream? [22:22:37] <pross-au> ill test it with the windows7 SBE [22:24:11] <BBB> fok.nl [22:24:14] <BBB> oops [22:24:17] <BBB> wrong window :-p [22:25:58] <BBB> I should build something into this chat client so command-T switches to chrome and then adds a new tab [22:47:41] <kshishkov> BBB: updated. And just in case - I can't commit it anywhere except my local git repo [23:03:14] <astrange> BBB: will attempt to. which part failed? [23:03:34] <BBB> I think particular parts of #1 and a later patch had already been applied [23:03:41] <BBB> kshishkov: I'll commit for you [23:07:01] <kshishkov> BBB: thanks [23:13:42] <pross-au> Q: say my format has 4 audio streams, how do i mark one (say the 3rd one) as 'primary' [23:14:28] <Sean_McG> isn't that container dependant, with some containers not supporting it? [23:15:09] <ohsix> he probably knows that; just wants to know how to flag it [23:15:14] <kshishkov> pross-au: add it first I think [23:15:31] <pross-au> kshishkov: fuck, i had hoped not.. [23:16:08] <kierank> how do i use av_close_input_file as part of a thread cleanup? [23:16:08] <kshishkov> just don't care about it [23:16:54] <kshishkov> pross-au: I'm not sure if we have primary stream definition at all and user may not care as well [23:17:04] <pross-au> Ahah. We have AVStream->disposition [23:17:58] <pross-au> the problem is, there is a wtv file with a 'silence' audio stream first, and the the actual audio stream [23:19:55] <pross-au> i had re'd an 'ignore this stream' flag in the format, but turns out not to be reliable [23:20:11] <kierank> pross-au: is there no language code? [23:20:41] <pross-au> both streams say 'Eng' [23:20:45] <kierank> hmm [23:20:48] <pross-au> indeed! [23:21:02] <kshishkov> what? not reliable binary format from M$? Impossible! [23:21:28] <kierank> there's two ways of flagging audio description in mpegts. i guess your file uses the second way. flag in the iso-639 descriptor [23:21:28] <ohsix> there's always NE [23:21:29] <pross-au> we must demand better kshishkov [23:22:24] <pross-au> kierank: in wtv, the language code is embedded in an MPEG TS Descriptor (escapsulated in a chunk) [23:22:55] <pross-au> this wtv stuff is holding up important IDCT stuff [23:22:58] <kierank> in the 639 descriptor there's a flag [23:23:03] <pross-au> oh [23:23:04] <kierank> that's separate to the language [23:23:26] <kierank> http://dl.dropbox.com/u/2701213/Specs/ISO_IEC_13818-1_2007_PDF_version_%28e… [23:23:28] <kierank> audio_type [23:23:50] <kierank> some countries they use it. in britain we use the language code "NAR" [23:23:53] <kierank> in* [23:24:19] <pross-au> thanks for that [23:25:26] <The_Tick> hey Yuvi [23:27:26] <The_Tick> hi I'm the project manager for perian [23:27:34] <The_Tick> we use ffmpeg and have for years [23:27:49] <The_Tick> I'm seeing this "compromise" email on the mailing list [23:28:17] <The_Tick> I'm wondering if we could help by finding hosting to help alleviate some tension possibly? :) [23:28:56] <The_Tick> I have good contacts at a few hosting sites from having managed adium and growl [23:29:11] <kshishkov> I fear it's not about that [23:29:30] <The_Tick> oh no [23:29:34] <The_Tick> what's it about? [23:29:49] <The_Tick> maybe a almost impartial third party could help [23:32:20] <kierank> not an easy situation to fix [23:32:32] <kshishkov> well, judging from current emails one party demands are completely not acceptable for other party [23:33:21] <The_Tick> oh that sort of thing [23:34:12] <The_Tick> well what are the valid points on both sides? [23:34:29] * The_Tick continues to read the emails, but there seems to be a lot of backstory [23:35:27] <kshishkov> the story is simple - some developers grew tired of the way FFmpeg was developed and decided to restart it under new set of rules [23:35:43] <The_Tick> not a fork but a reboot? [23:36:06] <kshishkov> depends on whom you're listening to [23:36:55] <kshishkov> "leader" believes it was illegitimate takeover and wants full control on infrastructure [23:37:38] <_av500_> kshishkov: where are yozu? [23:37:45] <kshishkov> mostly because git.videolan.org repository is not listed as main one on ffmpeg.org [23:38:05] <kshishkov> _av500_: still at home. My train is in 3 hours [23:38:09] <The_Tick> it's the git clone used by videolan for their custom patches right? [23:38:18] <kshishkov> nope [23:38:31] <kshishkov> it's git repo set up specially for FFmpeg transition to Git [23:38:31] <_av500_> kshishkov: ah [23:38:38] <The_Tick> ahh [23:39:23] <kshishkov> and "leader" has admin rights here. And commits from there are posted to FFmpeg-cvslog still [23:40:00] <The_Tick> what's the problem with not listing the repository used for testing? [23:40:09] <kierank> there's also the issue that the "leader" is head of the foundation [23:40:29] <kshishkov> kierank: not head [23:40:36] <kierank> really? [23:40:38] <kierank> what is he? [23:41:14] <kshishkov> The_Tick: it's listed http://ffmpeg.org/download.html but not as the primary one [23:41:40] <kshishkov> kierank: one of directors. Ben is the president IIRC [23:41:57] <The_Tick> it's git, there is no main repo :) [23:42:15] <kierank> kshishkov: i see [23:43:17] <The_Tick> so that's it, it's not listed as the main repo, that's the argument? [23:43:47] <kshishkov> partially [23:43:56] <The_Tick> that seems easily resolved [23:44:02] <The_Tick> what's the other problems? [23:44:29] <_av500_> The_Tick: lots [23:44:49] <kshishkov> something that looks to me like Michael wanting full control back again. Or almost full for starters [23:44:56] <The_Tick> what I've found on the projects I've managed [23:45:00] <The_Tick> is when we were all arguing [23:45:18] <The_Tick> it was good to bring in someone who had no real benefit to either side, air it all, and brainstorm solutions that worked for everyone [23:46:16] <The_Tick> ok so there's a control problem [23:46:25] <The_Tick> any other problems? [23:46:36] <kshishkov> well, to me it all sounded like "Return to me, I'll forgive everything but three people - I find that unacceptable - Me too - +1" [23:47:11] <michaelni> kshishkov, you are misunderstanding something [23:47:27] * michaelni didnt read the backlog ... [23:47:32] <ohsix> third party gooood, people can ignore ill will but it'll still be there; and their perceptions are colored [23:47:52] <kshishkov> michaelni: could be, that's why I point it's my view or opinion [23:47:57] <kierank> The_Tick: I tried to be the third party for an evening [23:48:06] <The_Tick> michaelni: essentially I'm trying to get to the bottom of the problems in a method that's worked well for me in the past so that I can feel comfortable with us continuing to use ffmpeg for perian [23:48:59] <kierank> The_Tick: I don't think it'll be possible to solve these problems on irc [23:49:08] <kierank> phone possibly but face-to-face much more likely [23:49:17] <kshishkov> face-to-faces [23:49:25] <The_Tick> kierank: I've solved harder problems on irc :) [23:49:33] <ohsix> faec to faeces [23:49:42] <The_Tick> whatever you guys have tried so far [23:49:45] <The_Tick> has it worked? [23:50:01] <kierank> The_Tick: social problems? [23:50:02] <kshishkov> ohsix: yep, it's been that way so far [23:50:05] <kierank> or technical problems? [23:50:06] <The_Tick> kierank: yes [23:50:08] <The_Tick> to both [23:50:45] <The_Tick> michaelni: you said kshishkov misunderstood something [23:50:48] <The_Tick> can you clarify what that is? [23:51:23] <michaelni> "Return to me, I'll forgive everything but three people" [23:51:26] <michaelni> thats nonsense [23:51:51] <michaelni> I want noone to return to me [23:52:10] <kshishkov> and nothing? [23:52:42] <michaelni> I want to be able to work in a friendly environment without being draged down in some peoples philosophical views [23:52:53] <pross-au> kierank: is the meaning of lang=NAR defined somewhere [23:53:02] <The_Tick> michaelni: such as? [23:53:15] <ohsix> mismatching philosophy, you want your own to supersede? [23:53:40] <kshishkov> The_Tick: would you believe that people in other repo can say the same? [23:53:47] <ohsix> i've seen a lot of words about troll driven development, it sounds like you don't like that; heh (but it's also all it runs on) [23:53:52] <kierank> pross-au: it's audio description for the visually impaired (aka audio narrative). It's defined in the UK D-Book which costs about Â£10k to get [23:53:55] <michaelni> philosophical views like "ohh no libmpcodecs, ohh you forget a whitespace ohh this must be capitalized ohh we want to remove the he264 encdoer [23:54:12] <kierank> pross-au: other countries might have standardised it, i dunno [23:54:22] <The_Tick> michaelni: I don't know that those are philisophical differences so much as how people like to view their code [23:54:31] <iive> kshishkov: i think michael "demans" the current root team to don't be root anymore. I haven't seen anything about kicking them out of the project. [23:54:34] <The_Tick> philisophical differences being things like [23:54:40] <The_Tick> "we want to go bsd and not gpl anymore" [23:54:44] <kshishkov> kierank: standards often cost as much in all countries [23:54:58] <iive> The_Tick: how about "voting doesn't work" "meritrocracy is the way to go"? [23:55:03] <michaelni> The_Tick, thats not a problem they cant even if they wanted [23:55:18] <kierank> kshishkov: well some of the D-books like norway and italy are available for free [23:55:21] <The_Tick> ok, hold on [23:55:33] <ohsix> if you pick merit you have to follow through and rely on people not having motives [23:55:33] <The_Tick> michaelni: let's flesh out the rest of your point here [23:55:37] <kshishkov> iive: well, at least we have original source here to clarify [23:55:40] <michaelni> The_Tick, whitespace nitpicking at the level that we had was philosophy not just normal [23:55:41] <The_Tick> everyone else let him do that [23:56:01] <The_Tick> michaelni: so you want people to be less pedantic? [23:56:01] <Sean_McG> stupid polarizing crap like that [23:56:02] <michaelni> also rejecting 3 times as many filters is not a technical decission [23:56:04] <pross-au> kierank: thanks, thats plenty [23:56:33] <michaelni> The_Tick, i want them to do the work if THEY want the formating to be so pedantic [23:56:48] <The_Tick> michaelni: do you guys have a coding standards document? [23:57:13] <michaelni> somewhere but reallity was much stricter in the end [23:57:31] <The_Tick> so maybe to resolve that point, you guys could update and agree upon the changes [23:57:35] <The_Tick> and stick to them [23:57:41] <ohsix> cant' the typo/spelling/formatting crap be easily dismissed with a commit hook? [23:57:48] <kshishkov> it is [23:57:57] <kshishkov> except for typos [23:58:26] <kshishkov> especially since certain guy can't even give an answer [23:58:36] <kshishkov> only awnsers [23:58:41] <ohsix> on lists i've read where people actually get things done theres usually 2-3 passes and they do include white space and other comments from people; theres no discussion over it, they roll another patch [23:59:16] <kierank> kshishkov: the whole innofficial and unofficial thing was ridiculous

1 0

IRC log for 2011-02-03
by irc＠mansr.com 04 Feb '11

04 Feb '11

[00:19:17] <Jumpyshoes> what does RFC stand for? [00:19:26] <mru> request for comments [00:19:35] <Jumpyshoes> oh, i see [00:21:48] * lu_zero wonder if the replacement of libjpeg really works [00:21:51] <lu_zero> wonders [00:21:59] <mru> replacement? [00:22:25] <lu_zero> media-libs/libjpeg-turbo [00:22:53] <mru> oh that [00:23:01] <mru> that's just a hacked-up libjpeg [00:23:06] <lu_zero> yup [00:23:25] <lu_zero> still might work better [00:24:08] <lu_zero> wbs patches pushed now [00:25:05] <CIA-38> ffmpeg: Martin Storsjö <martin(a)martin.st> master * rd9c0510e22 ffmpeg/libavformat/ (rtsp.c rtspenc.c): (log message trimmed) [00:25:05] <CIA-38> ffmpeg: rtsp: Don't store RTSPStream in AVStream->priv_data [00:25:05] <CIA-38> ffmpeg: For mpegts in RTP, there isn't a direct mapping between RTSPStreams [00:25:05] <CIA-38> ffmpeg: and AVStreams, and the RTSPStream isn't ever stored in [00:25:05] <CIA-38> ffmpeg: AVStream->priv_data, which was earlier leaked. The fix for this [00:25:06] <CIA-38> ffmpeg: leak, in ea7f080749d68a431226ce196014da38761a0d82, lead to [00:25:07] <CIA-38> ffmpeg: double frees for other, normal RTP streams. [00:25:12] <CIA-38> ffmpeg: Martin Storsjö <martin(a)martin.st> master * rce41c51b0c ffmpeg/libavformat/ (movenchint.c rtpenc_chain.c rtsp.c): [00:25:12] <CIA-38> ffmpeg: Free AVStream->info in chained muxers [00:25:12] <CIA-38> ffmpeg: This fixes memory leaks in the RTSP muxer and RTP hinting in the [00:25:12] <CIA-38> ffmpeg: mov muxer present since SVN rev 25418. [00:25:13] <CIA-38> ffmpeg: Signed-off-by: Luca Barbato <lu_zero(a)gentoo.org> [00:27:28] <CIA-38> ffmpeg: Nicolas George <nicolas.george(a)normalesup.org> master * r62ecd3635a ffmpeg/libavcodec/utils.c: [00:27:28] <CIA-38> ffmpeg: Set pkt_pts in avcodec_default_reget_buffer() [00:27:28] <CIA-38> ffmpeg: This was missed when pkt_pts was first added. [00:27:28] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george(a)normalesup.org> [00:27:28] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:50:51] <CIA-38> ffmpeg: Clément Bœsch <ubitux(a)gmail.com> master * rdc75d6dbf2 ffmpeg/libavutil/mem.c: [01:50:51] <CIA-38> ffmpeg: Avoid pointless check before calling free [01:50:51] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:51:01] <CIA-38> ffmpeg: Clément Bœsch <ubitux(a)gmail.com> master * r437fb1c87d ffmpeg/ (9 files in 2 dirs): [01:51:01] <CIA-38> ffmpeg: Remove a few if (p) av_free(p) forms [01:51:01] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:51:45] <ubitux> the was *really* quick, thanks mru [01:52:15] <Sean_McG> they're low to no impact changes [01:52:16] <mru> that's a pet peeve of mine, glad to see them all gone [01:52:34] <mru> and yes, easily verified [01:52:41] <Sean_McG> and I like that av_free() already DTRTs [01:54:14] <ubitux> well, bbl, thanks for the reactivity :) [01:57:51] <mru> Sean_McG: btw, any idea about the remaining gcc 4.6 failure? [01:58:57] <Sean_McG> I was actually gonna look into that tonight, unless somebody else is [01:59:20] <mru> not that I know of [01:59:27] <Sean_McG> OK, I'll see what I can dig up [01:59:45] <mru> that would be most appreciated [02:04:18] <Sean_McG> is there a way to quickly run just that 1 test? (pixfmt) [02:04:26] <mru> make fate-$test [02:04:30] <Sean_McG> OK [02:04:53] <mru> where $test is whatever fateweb shows [02:05:23] <mru> make fate-list prints a list of all tests [02:31:56] <Sean_McG> how do I know which code a test is working when all I see is "TEST lavf-pixfmt"? [02:34:07] <mru> add V=1 [02:34:14] <mru> that'll print the exact commands [02:34:16] <Sean_McG> ah [02:34:18] <Sean_McG> sweet [03:12:17] <Sean_McG> I'm still kinda lost, but I'm guessing this is some inline asm issue, not unlike the imdct stuff [03:12:54] <Sean_McG> maybe getting gcc to keep the temps, and then comparing 4.5.2 against 4.6? [05:03:03] <Sean_McG> meh, I've been mucking around with this and still no closer to an answer [05:20:59] <peloverde> Sean_McG: did you see if valgrind has any insights? [05:21:28] <Sean_McG> I'm on Solaris, no valgrind [05:22:03] <peloverde> for some reason I thought you were on linux [06:39:24] <Dark_Shikari> So, I should add AVX detection to ffmpeg. [06:39:25] <Dark_Shikari> deblock_luma[1]_c: 7123 [06:39:25] <Dark_Shikari> deblock_luma[1]_mmx: 2159 [06:39:25] <Dark_Shikari> deblock_luma[1]_sse2: 936 [06:39:26] <Dark_Shikari> deblock_luma[1]_avx: 860 [06:54:41] <Dark_Shikari> fuck, does anyone know about inline asm? [06:54:58] <_av500_> m r u [06:55:01] <Dark_Shikari> #define xgetbv(index,eax,ebx,ecx,edx)\ [06:55:02] <Dark_Shikari> __asm__ volatile\ [06:55:02] <Dark_Shikari> ("xgetbv\n\t"\ [06:55:02] <Dark_Shikari> : "=a" (eax), (edx)\ [06:55:02] <Dark_Shikari> : "0" (index)); [06:55:31] <Dark_Shikari> according to libavutil/x86/cpu.c, this would seem to put "index" in eax [06:55:39] <Dark_Shikari> ... why? [06:55:41] <Dark_Shikari> how do I put it in ecx instead? [06:56:00] <astrange> "0" means the same as constraint 0 (the =a) [06:56:02] <astrange> use "c" [06:56:15] <Dark_Shikari> ok [07:18:32] <Dark_Shikari> it's the video version of PLZ SEND ME TEH CODEZ! [07:18:35] <Dark_Shikari> Dear experts, [07:18:35] <Dark_Shikari> An urgent help needed now. [07:18:35] <Dark_Shikari> I am testing the H.264/MVC decoder part using JM17.1 version source code, would you like provide me any encoded bitstream with "MVC_EXTENSION_ENABLE". It will be great if you also provide me the original stereo clips. either QCIF or CIF format is better. [07:24:04] <siretart> good morning [07:25:09] * Dark_Shikari loves jvt-experts. [07:26:11] <KotH> bon giorno [07:30:58] <pJok> ohayou gozaimasu [07:33:30] <elenril> лунный язык оверрейтед [07:37:16] * pJok should fix his screen+irssi setup to actually show utf-8 and not just recode it to iso8859-1 [07:37:37] <elenril> doesn't it JustWork? [07:38:29] <wooster> depends on your temrinal client [07:38:32] <pJok> it would if i didn't explicitly made it do that [07:38:48] * pJok uses a few terminal clients that aren't happy about utf-8 [07:40:05] <cartman> moin [07:46:36] <av500> Dark_Shikari: yeah, I feel subscribing jvt was worth it :) [07:57:10] <cartman> http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video… is this for real? Patent pool for VP8? [07:58:24] <Dark_Shikari> Look at the date [07:58:26] <Dark_Shikari> May [07:58:27] <Dark_Shikari> 2010 [07:58:53] <cartman> yes and it takes time I guess :P [07:59:51] <spaam> cartman: fail [08:00:07] <spaam> cartman: why do you read old news?? [08:00:14] <cartman> spaam: reddit :) [08:00:51] <spaam> i thought they have new stuff there. [08:01:14] <cartman> it was posted as "Reminder" [08:10:35] <Zor> people use reddit? [08:10:55] <KotH> people read? [08:11:30] <superdump> people? [08:11:40] <cartman> think about the children! [08:14:48] <wbs> Dark_Shikari: another favorite of mine is all the "how do I use ffmpeg on android?" - http://groups.google.com/group/android-ndk/browse_thread/thread/f05edc8949c… [08:15:28] <cartman> wbs: that was a good one [08:17:41] <Dark_Shikari> wbs: How do I patch KDE2 on FreeBSD? [08:18:16] <wbs> Dark_Shikari: yeah :-) [08:18:17] <cartman> Dark_Shikari: emerge World [08:22:34] <elenril> sup kshishkov [08:22:43] <elenril> there's something wrong with your address [08:22:50] <kshishkov> of course [08:23:13] <kshishkov> looks like Ukrainian reality striked again [08:23:24] <kshishkov> so I'll use this machine for a while [08:25:35] <pJok> kshishkov, so its the ukranian reality strike that has affected our busses here in denmark? [08:26:10] <kshishkov> pJok: nope, Denmark can manage by itself [08:27:57] <pJok> well, you never know about things like that [08:29:32] * kshishkov reminds pross-au his favourite word (and it's not "sheep") [08:29:54] <pross-au> Boobies? [08:30:07] <pJok> trocadero? [08:30:16] <kshishkov> pJok: not mine, his [08:30:27] <kshishkov> pross-au: you've guesses the first letter correctly [08:30:43] <pJok> ah [08:31:33] <elenril> why don't you write it yourself if you want it so much [08:32:05] * kshishkov has to work on one codec used in EA game instead [08:32:16] <pross-au> Whoa [08:32:19] <pross-au> Which one kshishkov ? [08:32:20] <pJok> hehe [08:32:40] <spaam> wait what? kshishkov going to do something? :D [08:32:56] <elenril> spaam: sounds like a cake [08:33:13] <spaam> elenril: yeah [08:34:47] <kshishkov> pross-au: look at publisher name in http://en.wikipedia.org/wiki/Wing_Commander_IV [08:34:58] <pross-au> K [09:36:29] <spaam> kshishkov: haha [09:38:10] <Dark_Shikari> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-February/105460.html oh wow [09:38:41] <spaam> kshishkov++ [09:38:46] * elenril kicks roundup [09:38:58] <elenril> why does searching show closed bugs [09:38:59] <peloverde> nice work kshishkov [09:39:15] <kshishkov> I told them I was working on something! [09:39:26] <peloverde> I suppose you might be looking for a new task now... might I interest you in the aac encoder? [09:39:45] <elenril> haha [09:39:47] <Dark_Shikari> come help us on x264! We have AVX code to write. [09:39:49] * kshishkov is trying to interest his colleague to write opensource one [09:39:54] <Tjoppen> kshishkov: wc4 decoder \o/ [09:40:06] <kshishkov> Dark_Shikari: it's too sandy path to AVX [09:40:59] <spaam> Dark_Shikari: x264? FFmpeg need it [09:41:06] <Dark_Shikari> ffmpeg too! [09:41:11] <Dark_Shikari> I posted a patch to add AVX support [09:41:31] <av500> meh, h264 coding happens on gfx cards these days... [09:41:45] <kshishkov> Dark_Shikari: the one with hidden hope mru will fix it? [09:42:50] * Dark_Shikari punts av500 [09:44:39] <kshishkov> av500: ftp://download.nvidia.com/XFree86/Linux-x86_64/195.36.15/README/vdpausuppor… look for "VDPAU features note 1" [09:45:49] <cartman> buy a Quadro GPU then [09:45:49] <cartman> :P [09:46:26] * kshishkov waits for KotH to give OGP cards along with Swiss chocolate [09:46:40] <cartman> OGP still alive?! [09:47:23] <KotH> ofc [09:47:26] <KotH> but no ogp cards [09:47:35] <cartman> meh :) [09:47:35] <KotH> these beasts are expensive! [09:47:45] <KotH> buy one yourself! :) [09:47:50] <cartman> OGP was supposed to produce something :P [09:48:19] <kshishkov> KotH: have you translated ffmpeg sources to verilog already? [09:48:36] * KotH refuses to speak verilog, it's the language of the devil [09:49:38] <kshishkov> what have you used for design instead? [09:49:43] <siretart> http://www3.informatik.uni-erlangen.de/Persons/potyra/potyra.html is working on a C->VHDL compiler [09:49:54] <siretart> I know him, he is a nice guy :-) [09:50:31] <av500> kshishkov: so? some minor resolutions not supported [09:50:54] <KotH> Subject: [FFmpeg-devel] [PATCH 0/2] Origin Wing Commander IV video decoder [09:50:56] <KotH> rotfl [09:51:05] <kshishkov> av500: and those guys made Tegra platform as well so I won't trust their GPU encoding either [09:51:36] <kshishkov> KotH: well, Reimar mentioned nobody's going to review obscure game codec so here's a test [09:52:27] <KotH> kshishkov: if i'd have the time and the knowledge, i'd review it, just for the fun of it :) [10:07:34] * av500 wonders how many obscure decoders kshishkov has stashed away to use in emergencies... [10:08:05] <mru> av500: remember all those games mike was playing? [10:09:29] <pross-au> mru: like the Barbie series... [10:09:36] <cartman> ... [10:09:37] <mru> and taco bell [10:10:06] <pross-au> Guiness Book of Records needs an obscure hobby section [10:11:57] * elenril was just going to say that psx str don't work [10:12:09] <elenril> but wow, they actually do work [10:12:45] <astrange> psxstr plays at the wrong framerate [10:13:02] <astrange> i discovered that in... hmm... 2005? [10:13:02] <kshishkov> av500: there's also LucasArts format and Discworld II [10:13:25] <kshishkov> av500: and everything else that comes across [10:13:28] <astrange> and then i read the str spec and couldn't figure out how it worked [10:13:45] <astrange> iirc the framerate is detected based on how many audio frames there are between video frames [10:14:19] <elenril> at least the xenogears movies i'm playing right now work fine [10:14:49] <elenril> .....except for the double free or whatever this is [10:15:25] <elenril> yay, and it's apparrently random [10:15:28] * elenril blames -mt [10:16:01] * kshishkov blames it for not being merged [10:16:11] <elenril> yes, goes away with threads=1 [10:16:17] <elenril> astrange: you broke it! [10:16:19] <peloverde> If -mt isn't merged before my birthday, it will be a very sad birthday [10:17:04] <astrange> the patches i sent are done but lost in confusing email threads. i'll repost them tomorrow and then the rest of the tree as RFC [10:17:22] <siretart> do we want -mt for the 0.7 release, or rather, how likely is -mt going to cause regressions? [10:17:30] <kshishkov> peloverde: make a present for yourself - improve AAC encoder [10:17:56] <astrange> likely. when do you want to release? [10:18:15] <siretart> astrange: I'm actually only waiting for the libavfilter API to become fixed [10:18:45] <kshishkov> siretart: i.e. never [10:18:49] <siretart> saste told me he wants to change things for audio filter, but other than that, I consider current master to be ready to branch [10:18:54] <peloverde> kshishkov: how about I implement some weird AOT in the decoder instead? [10:19:27] <elenril> how about working on libvorbis ;) [10:19:27] <siretart> kshishkov: read stable as 'future API/ABI breaks require major bump', which is currently not the case [10:19:31] <elenril> err i mean vorbisenc [10:20:20] <astrange> aotuv is good enough [10:20:37] <siretart> lunchtime.now [10:20:51] <kshishkov> peloverde: who needs it? and encoder is rather needed [10:20:57] <astrange> get ahead of the curve by writing xiph ghost enc [10:21:22] <astrange> http://pastebin.com/rXv2Jbbq it might help something if someone sends me review notes for this [10:21:29] <astrange> as well as "i completely don't understand this" [10:22:39] <peloverde> kshishkov: I wouldn't want to steal that fun from you [10:22:42] <Dark_Shikari> are we ever going to bump lavc btw? we have like five million things queued up for bump [10:23:09] <astrange> not enough things [10:23:10] <kshishkov> peloverde: you can't so go work on aacenc [10:23:21] <kshishkov> peloverde: I'm not good with encoders anyway [10:23:27] <astrange> i don't think anyone has proposed removing nearly enough of AVCodecContext [10:23:43] <mru> go for it, chop chop [10:24:02] <astrange> e.g. x264-only fields should be removed on bump and replaced by codec options, has_b_frames could be renamed delay, i think some other fields might be single-codec specific [10:24:04] <peloverde> the only bug free code is removed code [10:24:31] <kshishkov> astrange: probably some Michael would be against it, that's why it wasn't proposed [10:24:32] <elenril> won't people hate us even more for removing them so suddenly [10:25:16] <kshishkov> it's always sudden [10:25:20] <astrange> there's a field named slice_count and a field named slices [10:25:40] <elenril> kshishkov: it's slightly less sudden when it's marked as deprecated for a few months [10:26:14] <Dark_Shikari> in x264 we randomly remove an option every year or so [10:26:17] <Dark_Shikari> it's fun [10:26:19] <Dark_Shikari> keeps people on their toes [10:26:22] <kshishkov> elenril: you mean years? [10:26:45] <kshishkov> elenril: I don't see anything deprecated removed from FFmpeg after just months [10:27:05] * mru thinks it's time for The Big Bump [10:27:06] <elenril> because we didn't do a major bump in years [10:27:43] <elenril> it's not like we can't do another one a year later or so [10:27:44] * kshishkov had an evil plan to bump minor version till overflow [10:27:54] <elenril> kshishkov: IKnewIt! [10:28:04] <av500> kshishkov: rev 2.50.NAN [10:28:05] * elenril is all for bumping lavf [10:28:21] <astrange> enum Motion_Est_ID should have half the entries removed (no code implements them) [10:28:27] <KotH> somehow, all this talk about bumping reminds me of 4chan :) [10:28:34] <kshishkov> av500: rev 52.-127.0 for lavc [10:28:35] <astrange> i'll write an email if i don't sleep though the whole day [10:28:41] * elenril sages KotH [10:28:42] <astrange> which is possible, as i'm up past 5am [10:29:04] <KotH> astrange: living in the japanese timezone? [10:29:49] <kshishkov> KotH: why are you asking? [10:30:12] <astrange> living in est but talking to some people in jst did mess me up [10:30:48] <DonDiego> i also like the big bump idea [10:31:02] <mru> siretart: ping [10:31:28] <av500> FFmpeg 0.7 "the big bump" [10:31:34] <noname^^> http://git.ffmpeg.org/?p=ffmpeg.git;a=blob;f=libavcodec/resample.c;h=272831… <- has someone disabled this for a reason (&& 0) or is it a bug? [10:31:54] <DonDiego> av500: we need a more revolutionary slogan i guess [10:32:01] <DonDiego> what about "the tidal wave"? :) [10:32:34] <KotH> wennschondenschon "The Tidal Wave!" [10:32:37] <elenril> av500: big bump BBB? [10:32:50] <av500> "BBB's Big Bump" [10:32:56] <av500> or B5 [10:33:09] <peloverde> DS9 [10:33:30] <mru> noname^^: one beer says michael put that there [10:33:36] <mru> so there's no way we'll ever know why [10:33:41] <noname^^> haha [10:34:22] <elenril> well you could ask him [10:34:45] <mru> lol [10:34:45] <astrange> it looks like it doesn't check s->sample_size [10:34:52] <astrange> so it'd be wrong if it was enabled [10:34:58] <lu_zero> good morning [10:35:05] <kshishkov> mru: maybe it was there just to prevent it running on copy case but then he realised it eats precious cycles and moved condition elsewhere? [10:35:17] <pJok> i thought BBB was already Big Buck Bunny ;) [10:35:39] <benoit-> hi [10:35:49] <mru> hi benoit- [10:36:15] <kshishkov> bonjour [10:36:17] <benoit-> whoever is "administrating" the -devel mailing list please list themselves as an admin [10:36:28] <noname^^> astrange, I see [10:36:29] <pJok> mru, can't remember how long my "first" boot took... but i cleared the cache yesterday, pulled the battery out after 10 min and it booted fine right after [10:37:12] <mru> benoit-: I've been clearing out the spam from the moderation queue from time to time, since none of the listed admins bothered [10:37:22] <pJok> mru, rather odd feature about android aparantly [10:37:47] <elenril> siretart: you want to branch the release before or after the big bump? [10:37:51] <mru> pJok: I think the thing was just mighty confused for a while [10:37:55] <benoit-> mru: that's fine, I just want you to be listed if you're doing it [10:38:34] <pJok> mru, possibly... android is not quite there yet in terms of a really good phone os [10:38:34] <mru> ok, I'll add myself [10:38:56] <benoit-> thank you [10:39:17] <noname^^> http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=b9d2085ba14aa733503ff02d… [10:39:23] <noname^^> "various resampling fixes" [10:39:33] * mru wins [10:39:35] <noname^^> :D [10:39:39] * noname^^ gives mru a beer [10:39:48] <DonDiego> benoit-: didn't you use to help with ml administration? [10:40:19] <benoit-> DonDiego: I'm back at it [10:40:35] <benoit-> I've been pretty busy for the last months [10:41:00] <benoit-> DonDiego: I'm not doing it anymore for the -users ML though [10:41:01] <mru> yeah, I noticed the moderation backlog... [10:41:15] <benoit-> and it seems I was the only one who cared about it [10:41:30] <benoit-> I don't think that michael or baptiste are doing it [10:41:40] * mru cares [10:42:08] <benoit-> so there were a lot of emails in the moderation list when I (sort of) came back to it [10:42:11] <kshishkov> mru: that's because you're not admin. Become one and you'll stop. [10:43:43] <benoit-> mru: cool [10:44:34] <DonDiego> benoit-: would you be willing to work as ml moderator/admin (again)? it would be very helpful and appreciated... [10:45:01] <lu_zero> av500: poing [10:48:13] <siretart> mru: pong [10:48:52] <mru> siretart: did you read the discussion about bumping major versions? [10:48:57] <siretart> elenril: TBH, I'd prefer to include the bump, because not doing so will make backporting patches to the release branch harder. AFAIUI the bump won't destabilise the tree by itself [10:49:16] <siretart> mru: just reading the backlog [10:49:20] <mru> good, we agree [10:51:52] <cartman> int uvdxy; /* no, it might not be used uninitialized */ [10:51:55] <cartman> heh [10:52:52] <siretart> btw, I like the release code name "The Big Bump" :-) [10:53:19] <mru> +1 [10:53:40] <kshishkov> mru: you don't like codenames anyway [10:54:33] <mru> I don't like it when undocumented codenames are the primary identification used by people [10:55:02] <Dark_Shikari> undocumented? [10:55:14] <mru> Dark_Shikari: exactly what is "debian kenny"? [10:55:23] <av500> sw that dies often [10:55:28] <mru> and why does it not allow a bug to be fixed? [10:55:29] <cartman> mru: possibly my friend [10:55:59] <Dark_Shikari> Kenny? [10:55:59] <Dark_Shikari> WTF? [10:56:03] <cartman> Lenny [10:56:04] <cartman> :P [10:56:05] <siretart> you killed kenny, you bastards! [10:56:10] <Dark_Shikari> Lenny is a release name [10:56:13] <Dark_Shikari> Like Hardy Heron [10:56:15] <Dark_Shikari> or Maverick [10:56:20] <cartman> or Masturbating Monkey [10:56:21] <cartman> etc. [10:56:25] <Dark_Shikari> That's not undocumented. [10:56:26] <mru> at least the ubuntu ones are in alphabetical order [10:56:34] <kshishkov> mru: it's well-known fact that Debian has sponsored Toy Sotry 3 to get a source for new codenames [10:56:42] <Dark_Shikari> You complain about all codenames, even documented ones [10:56:45] <av500> Dark_Shikari: so, can I put Kenny on Sandy? [10:56:47] <Dark_Shikari> you don't like penryn, conroe, nehalem, sandy bridge, etc [10:56:53] <mru> no, I don't [10:57:01] <cartman> there is i3 i5 i7 :P [10:57:06] <mru> it's impossible to tell which is more recent without memorising the full list [10:57:07] <av500> or does Sandy need HArdy? [10:57:19] <mru> Sandy Salamander [10:57:25] <siretart> av500: sandy requires natty [10:57:28] <cartman> everybody needs a sane versioning system [10:57:31] <kshishkov> cartman: but 80186 precedes i386 which precedes i7 :P [10:57:33] <av500> how naughty [10:58:08] <mru> and then there's the debian stable/unstable thing [10:58:28] <kshishkov> well, version of something = MD5 of all its sources would be good [10:58:30] <av500> mru: no "next"? [10:58:35] <mru> it's fine for debian people to talk like that with each other, but it bothers me when they do it to outsiders [10:58:40] <av500> kshishkov: thats the git revision [10:58:46] <mru> av500: nope, debian lives in the past [10:59:57] <kshishkov> av500: it can be applied to hardware as well since it has blueprints in electronic form [11:00:17] * siretart is mildly annoyed that Debian 6.0 (AKA 'squeeze') will be shipped with FFmpeg 0.5 :-/ [11:00:42] <cartman> siretart: they ship a version that can decode PNG and animated gifs [11:00:46] <Dark_Shikari> siretart: it's debian [11:00:51] <kshishkov> siretart: well, Debian competes with FFmpeg in release delay terms [11:01:00] <elenril> siretart: can you imagine debian stable not having a lolold ffmpeg? [11:01:07] <Dark_Shikari> If debian shipped packages new enough to be useful to someone, they would have to change their name. [11:01:12] <Dark_Shikari> to something like "ubuntu" or "arch". [11:01:53] <mru> debian needs more qualifiers for their versions: testing, unstable, stable, decomposed, petrified... [11:02:05] <siretart> at least debian delivers a suitable environment to develop on ffmpeg [11:02:18] <Dark_Shikari> so does a 3 year old version of cygwin [11:02:25] <Dark_Shikari> that's not a very good resume item [11:02:37] <cartman> just use your bare (or bear) hands [11:02:41] <kshishkov> mru: what's wrong with their default "stale" and "unusable" statuses? [11:02:45] <lu_zero> why are we picking on debian today? [11:02:47] <DonDiego> siretart: why 0.5? [11:02:58] <elenril> wtf, ffmpeg uses FF_API? [11:03:03] <kshishkov> lu_zero: wanna picks on Gentoo? [11:03:23] <elenril> lu_zero: because flaming about the revolution got old [11:03:39] <siretart> DonDiego: too much breakage in depending packages, and "it would have delayed the freeze" [11:03:56] <lu_zero> elenril: I'd use change instead of revolution [11:04:08] <lu_zero> and it would be great if that's the reason [11:04:23] <mru> reminds of the time jörg schilling demanded that a fix in the linux scsi drivers be reverted because cdrecord was in release freeze and depended on the bug [11:04:31] <lu_zero> kshishkov: I had my share of debian vs gentoo already [11:04:39] <siretart> yeah, that sounds like joerg [11:05:11] <kshishkov> lu_zero: is it true that lamps belonging to Gentoo users emit faster light? [11:05:11] <mru> of course he got nothing but ridicule [11:05:45] <mru> lu_zero: where did this idea about gentoo being only about OMG FAST come from? [11:05:46] <lu_zero> kshishkov: only if painted in red and if the users have a green skin [11:05:52] <kshishkov> mru: he should have demanded that fro M$ instead and probably he would get it [11:06:05] <lu_zero> mru: kids trying that and spreading the voice [11:07:14] <kshishkov> lu_zero: is supercomputer speed now measured in "emerge world" per second? [11:07:29] <lu_zero> kshishkov: nope [11:07:30] <Dark_Shikari> you mean per day [11:07:35] <lu_zero> emerge system [11:07:48] <lu_zero> Dark_Shikari: emerge world could take seconds [11:08:06] <lu_zero> @world is a set that could be quite small [11:08:46] <Kovensky> 08:05.45 mru: lu_zero: where did this idea about gentoo being only about OMG FAST come from? <-- CFLAGS="-O9001 -vomit-frame-pointer -fomg-fast" [11:09:16] <kshishkov> lu_zero: do you think Dark_Shikari will ever install Gentoo? [11:09:26] <lu_zero> kshishkov: probably [11:09:31] <thresh> funroll-loops.info is awesome indeed [11:09:32] <Dark_Shikari> mru: http://funroll-loops.info/ [11:09:44] <mru> yes, I've seen it [11:09:44] <Dark_Shikari> read every single thing on that page, now [11:10:19] <mru> look, I use gentoo mostly because it lets me not have a fucking gnome dependency on _everything_ [11:10:31] <mru> and because the init system is sane [11:10:46] <kshishkov> and because it's still not complete BSD [11:11:07] <mru> bsd is stuck in 1995 [11:11:14] <kshishkov> that new? [11:11:38] * elenril kicks freenode [11:11:59] <Kovensky> 08:11.07 mru: bsd is stuck in 1995 <-- can we blame schilling for that too? can we? can we? [11:12:04] <Kovensky> (he's a freebsd maintainer) [11:12:20] <mru> isn't schilling in love with solaris? [11:12:27] <pJok> Kovensky, probably a lot of people you can blame for that [11:12:40] <Kovensky> I wonder how will bsd deal with C1x [11:12:45] <Kovensky> bsd can barely deal with c99 [11:12:46] <mru> I like DonDiego's observation about bsd [11:12:53] <pJok> when is the release date for ffOS? [11:12:57] <KotH> mru: schillings relation to solaris is better described by the old EAV song "fata morgana" :) [11:14:05] <av500> KotH: eav, lol [11:14:39] <Kovensky> mru: which were...? [11:15:47] <av500> # of BSDs approaches # of BSD users over time [11:16:38] * av500 is reminded that the BSD guy that sat next to him at GSOC summit was a guy with a beard [11:16:59] <elenril> wow, lavf almost builds after a bump [11:17:02] <cartman> av500: and? [11:18:28] <wbs> j-b: nice question on vlc/amr ;P who told him to forward his question to us? [11:18:40] <j-b> clearly not me [11:18:43] <elenril> haha [11:18:46] <wbs> j-b: I guess it is fixable, if someone says which parts of the amr support in lavf needs improving [11:19:18] <elenril> his usage of gpg is inconsistent with his level of cluelessness [11:19:18] <j-b> wbs: although I believe raw amr is demuxed by lavf, if it is inside a 3gp, I am quite sure the fault is ours. [11:20:00] <wbs> j-b: I guess he means raw amr [11:20:08] <j-b> wbs: you guess too much :) [11:20:17] <wbs> j-b: yeah, I know :-) [11:20:22] <j-b> wbs: the guy doesn't even mention his VLC version [11:20:38] <j-b> 1.1.7 has AMR-NB and WB support, while 1.0.5 has almost nothing... [11:20:41] <kshishkov> wbs: for raw AMR you have constant bitrate, don't you? So no problem at all [11:20:57] <wbs> kshishkov: not necessarily, nothing stops you from having different modes in each block (iirc) [11:21:04] <av500> kshishkov: no you need epic amr parser thread on -devel [11:21:05] * kshishkov resists to mention multichannel WavPack support [11:27:51] <j-b> wbs: anyway, someone can tell him: "we can do that: $1000" [11:28:41] <wbs> j-b: :-) [11:30:06] <j-b> wbs: what? not expensive enough? [11:30:16] <kshishkov> j-b: hire mru for that then [11:30:32] <kshishkov> it should be the sweet spot [11:32:25] <DonDiego> kshishkov: there, first xxan review... [11:33:00] <wbs> j-b: you clearly have more guts in demanding consulting fees than I do :-) [11:33:19] <DonDiego> Dark_Shikari: nit: the _deps hunk in your configure change for avx is not in alphabetical order [11:34:03] <DonDiego> av500: hey, copyright of that bsd joke is mine! [11:34:34] <av500> DonDiego: yes, I just reproduced it [11:34:41] <av500> [12:12:46] <mru> I like DonDiego's observation about bsd [11:34:54] <{V}> av500, did you check the license? :p [11:35:17] <mru> yay, more recruitment spam [11:35:28] <av500> {V}: no, I am stronger [11:35:46] <j-b> wbs: well, one day of your time is at least 700EUR/day [11:35:52] <mru> for "a major broadcasting company in West London" looking for "strong C++ knowledge (Boost libraries, Memory management etc) as well as having a working knowledge of Flash" [11:36:00] <wbs> j-b: true [11:36:06] <wbs> mru: sounds exactly like you then ;P [11:36:39] <av500> mru: demand london city payment [11:36:55] <av500> and boni [11:37:10] <j-b> wbs: small addition to a format in lavc/lavf, is worth at least 500EUR. Important feature is at least 5000EUR. RE of a codec is 10000EUR minimum. Except for bink [11:37:44] <wbs> j-b: true [11:37:47] <kshishkov> DonDiego: it's funny but most your nits are related to the function I reused from xan_wc3 [11:38:02] <av500> kshishkov: so, you blindly copy pasted [11:38:11] <cartman> ClipboardInheritance [11:38:24] <kshishkov> av500: nope, look at libavcodec/xan.c for original one [11:38:53] <Dark_Shikari> DonDiego: someone else will need to muck with configure anyways [11:38:57] <Dark_Shikari> I don't know crap about bash/configure/etc [11:39:07] <mru> this is not bash :) [11:39:08] <DonDiego> kshishkov: :) - the const stuff as well? [11:39:13] <j-b> DonDiego: well, .amr is directly lavf, :D [11:39:51] <Dark_Shikari> mru: same shit [11:41:32] <kshishkov> DonDiego: almost - look at libavcodec/xan.c [11:43:05] <CIA-38> ffmpeg: Benjamin Larsson <benjamin(a)southpole.se> master * raa42cce57d ffmpeg/libavformat/isom.c: [11:43:05] <CIA-38> ffmpeg: Add AVC-Intra identifiers used by Flip4Mac for mov files [11:43:05] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:43:06] <DonDiego> well, time to clean up that stuff as well then :) [11:43:10] <CIA-38> ffmpeg: Tomas Härdin <tomas.hardin(a)codemill.se> master * rf5b82f45dc ffmpeg/libavcodec/avcodec.h: [11:43:10] <CIA-38> ffmpeg: Add CODEC_ID_PRORES and bump lavc minor version [11:43:10] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:43:12] <CIA-38> ffmpeg: Tomas Härdin <tomas.hardin(a)codemill.se> master * r75fd0668df ffmpeg/doc/APIchanges: [11:43:12] <CIA-38> ffmpeg: Add APIchanges entry for lavc 52.109.0 [11:43:12] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:43:13] <CIA-38> ffmpeg: Tomas Härdin <tomas.hardin(a)codemill.se> master * re65b1934bf ffmpeg/libavformat/isom.c: [11:43:13] <CIA-38> ffmpeg: Add ProRes FOURCCs to isom.c [11:43:13] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:43:30] <DonDiego> merbanan: so is prores progressing? [11:43:35] <kshishkov> DonDiego: go for it! [11:44:26] <j-b> wbs: I'll mail the guy privately, so we'll know where the fix should be. [11:44:36] <kshishkov> DonDiego: also second patch is independent, feel free to queue [11:46:17] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r9ad4c65f6f ffmpeg/libavformat/rtmpproto.c: [11:46:17] <CIA-38> ffmpeg: rtmpproto: rename URLContext* argument in rtmp_write() [11:46:17] <CIA-38> ffmpeg: Now the first argument is URLContext *h. However, the function logs to [11:46:17] <CIA-38> ffmpeg: LOG_CONTEXT, which is #defined as 's' for new lavf major versions. [11:46:17] <CIA-38> ffmpeg: Therefore, rename h -> s. [11:46:18] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:46:35] <DonDiego> kshishkov: i don't have a working ffmpeg git setup here at work, but please feel free to ping somebody else [11:46:40] <Dark_Shikari> mru: write my configure stuff, I'll fix the rest [11:47:15] <mru> Dark_Shikari: answer my question about ssse3 [11:47:29] <Dark_Shikari> done on ml [12:00:34] <elenril> 19 files changed, 5 insertions(+), 585 deletions(-) [12:00:35] <elenril> nice [12:00:50] <mru> ? [12:00:55] <elenril> lavf major bump [12:01:18] <DonDiego> elenril: can you post numbers for the other version bumps as well? [12:01:33] <elenril> i'm not sure i should do lavc, i have zero experience with it [12:02:15] <DonDiego> in theory you should just have to remove #ifdefs and bump the number [12:02:25] <DonDiego> see if it compiles if you bump the number [12:04:59] <elenril> in theory [12:05:33] <elenril> won't -mt introduce new incompatible changes? [12:08:12] <elenril> bleh, tons of incompatibilities because of moves lavc->lavcore [12:08:17] * elenril glares at saste [12:08:52] <kshishkov> elenril: if you by any chance think lavcore was not a good idea I agree with you [12:09:06] <DonDiego> well, let's just reunify libavutil and libavcore again [12:09:20] <DonDiego> i think nobody except michael liked that split anyway... [12:09:38] <elenril> not many people will like us breaking api again [12:09:45] <cartman> indeed [12:09:59] <mru> libavcore was never in a release [12:10:07] <cartman> good point [12:10:08] <cartman> :p [12:10:22] <elenril> we don't gain anything significant by merging it with lavu [12:10:29] <elenril> except new incompatibilities [12:11:03] <kshishkov> better tab completion [12:11:05] <mru> we reduce library proliferation [12:11:09] <DonDiego> we spare users an api change [12:11:10] <kshishkov> less libraries [12:11:18] <lu_zero> or we could but we could discuss in the ml [12:11:28] <lu_zero> and hopefully get input from the users [12:11:34] <mru> of course we could [12:11:36] <elenril> DonDiego: those api changes were needed anyway [12:11:38] <lu_zero> (so poll also libav-users) [12:11:39] <elenril> they add av_ prefix [12:11:57] <DonDiego> that i don't disagree with [12:12:13] <DonDiego> merge libs, add prefixes, bump major... [12:13:33] <elenril> i know -- let's vote! [12:13:35] * elenril is shot [12:13:45] <kshishkov> elenril: yep, that was a good vote [12:26:58] <DonDiego> vote with your shotgun? :) [12:27:13] <DonDiego> i thought we had already voted with our feet recently.. [12:27:44] <kshishkov> well, I'm Ukrainian, I hate voting [12:28:14] <merbzt> DonDiego: from the info I have yes [12:28:23] <mru> kshishkov: then use shovel [12:29:58] <kshishkov> mru: why not? [12:30:30] <kshishkov> especially since shovel is less suspicious than shotgun, doesn't run of ammo and doesn't need silencer [12:30:36] <kshishkov> *out of ammo [12:31:12] <av500> its a bit more limited in range [12:31:48] <kshishkov> you can throw it too [12:32:02] * av500 watches how vlc and ff devs blame each other instead of helping poor users [12:33:03] <Kovensky> I thought you ex-soviets preferred hammers and sickles [12:33:13] <mru> av500: it's the first step towards forming a proper government [12:33:27] <av500> Kovensky: both have been collected and used to forge new shovels [12:33:39] <Compn> http://abstrusegoose.com/strips/ars_longa_vita_brevis.PNG [12:33:50] <JEEB> that reminds me of a certain Soviet-related joke [12:34:07] <Kovensky> hammers are better for throwing [12:34:13] <Kovensky> but I suppose nothing beat a norse axe [12:34:35] <mru> thor's weapon of choice was a hammer... [12:34:45] <av500> Kovensky: shovel is much more versatile [12:35:01] <Compn> are you going to see the new thor movie mru ? [12:35:26] <kshishkov> Compn: so you need only 3627 additional days compared to book and ~11000 days to fix that? [12:35:41] <mru> Compn: based on the comic book? [12:35:55] <Compn> mru : yes [12:36:02] * mru never read the comics [12:36:05] <Compn> kshishkov : i have no idea [12:37:04] <kshishkov> mru: why? you're American, you're supposed to read comics (if not them who else?) [12:37:22] <mru> do I _look_ american? [12:37:29] <mru> so I sound american? [12:37:31] <mru> do [12:38:07] <cartman> whoa [12:38:29] <Compn> mru has a circle above an a in his name, americans dont go for that [12:38:39] <Compn> no extra circles and such in our letters [12:38:44] <mru> two As in fact [12:39:10] <mru> it is true that I have a US passport, but that's just to get across the border with less hassle [12:39:20] <cartman> that surely helps [12:48:21] * Kovensky is reminded of that email exchange that decides that å is not cool, it's hot [12:50:27] <DonDiego> mru has always reminded me of a viking - just give him a hammer instead of an axe and he will look like thor.... [12:53:38] <kshishkov> mru: well, I'm from the part of the world where your documents define who you are [12:55:29] * mru waves a swedish passport in front of kshishkov [12:55:39] <mru> that one helps getting across other borders [12:55:53] <elenril> can you make one for me too? [12:56:00] <JEEB> herp, American borders [12:56:04] <JEEB> Got to hate them [12:56:09] <wbs> mru: how do you get a us passport? [12:56:19] <mru> sssh [12:56:23] <JEEB> serving in the US military? [12:56:26] <cartman> ssh? [12:56:32] <wbs> cartman: lol [12:56:33] <av500> hmm, sure looks like A with circle on top to me: http://imagebin.org/135956 [12:56:48] <JEEB> yah, it's a "Swedish O" [12:57:06] <JEEB> lol [12:57:07] <kshishkov> JEEB: reused in many countries [12:57:26] <JEEB> We have it in our alphabet purely to write the Swedish surnames :3 [12:57:30] <mru> av500: what did you search for to find that? [12:57:41] <av500> mru: gimp [12:57:53] <kshishkov> av500: was that the first hit? [12:58:15] <av500> kshishkov: like bing, I do not comment on my search results [12:58:33] <av500> excet that they are 100% geniune [12:58:38] <av500> +spelling [12:58:57] <cartman> Did you mean _except_? [12:59:29] <av500> _yes_ [13:00:56] <kshishkov> av500: have you ask your kid to do search? [13:00:59] <cartman> bureaucracy takes so looooong time [13:01:13] <kshishkov> cartman: nope, it takes _all_ time [13:01:28] <kshishkov> cartman: read about Parkinson's law [13:01:41] <cartman> kshishkov: Hopefully will finish before I die [13:02:08] <cartman> Work expands so as to fill the time available for its completion. [13:02:11] <cartman> LOL [13:02:35] <av500> kshishkov: as said, I types gimp into command line [13:02:38] <av500> typed [13:03:47] <Kovensky> cartman: the bureaucracy expands to fulfill the needs of the expanding bureaucracy [13:04:06] <mru> whose law is that? [13:04:17] <cartman> mru: Parkinson's Law as kshishkov pointed out [13:04:25] <Kovensky> it's some quote that appears on civilization 4 once you research code of laws (I think) :) [13:04:41] <mru> hehe [13:05:09] <kshishkov> mru: his book is definitely one of the best British books ever written [13:05:43] * av500 nominates kshishkov as assistant chairman of the subcommitte for the redesign of the ffmpeg-devel minor patch submit form [13:06:39] <kshishkov> av500: as another British author put it, committes are just a form of isolating people from activity [13:06:58] <elenril> bleh, lavc is full of breakage on bumping major [13:07:17] <elenril> anyone with more experience than me wants to look at it? [13:07:46] <kshishkov> mru: and I really recommend you reading his book [13:09:10] <mru> does it say something I don't already know? [13:09:19] <kshishkov> could be [13:09:45] <Kovensky> isn't Parkinson the one that wrote down the bikeshed example [13:10:06] <kshishkov> yes, it's him [13:12:13] * mru is reminded of the time it took nds to put up a second bikeshed... [13:13:07] <DonDiego> elenril: maybe you can pastebin the result of 'make -k' [13:13:18] <KotH> mru: did they paint it? [13:13:45] <kshishkov> KotH: not yet [13:13:46] <mru> no, the walls are polycarbonate or something [13:15:11] <kshishkov> mru: please read http://en.wikipedia.org/wiki/The_Dilbert_Principle [13:15:29] <kshishkov> the last sentence in first abstract at least [13:15:44] * KotH wants a paint bucket with red-viollet with yellow-green dots colour in it [13:17:46] <elenril> ok, it doesn't seem so bad after all [13:18:11] <elenril> the only thing i'm not sure what to do about is AVCodecContext.request_channels [13:18:31] <mru> what about it? [13:18:36] <elenril> it's deprecated [13:18:42] <mru> undeprecate it [13:18:57] <mru> ah, it's replaced by the _layout version [13:19:06] <mru> which carries more information [13:19:07] <elenril> is _layout the same thing? [13:19:22] <mru> first one is number of channels, second also includes order [13:19:43] <elenril> but are they compatible [13:19:50] <mru> not really [13:20:11] <mru> request_channels is a number, _layout a bit mask [13:20:39] <mru> there are many ways you can end up with, say, 3 channels [13:21:01] <elenril> ah, ok [13:21:07] <mru> 2f1r, 3f, and 2f+lfe all being used [13:21:13] <elenril> btw don't apply the patch i just sent [13:21:15] <kshishkov> that reminds me of combinatorics for some reason [13:21:29] <elenril> the one with CH_* renaming [13:21:33] <mru> ok [13:21:40] <elenril> it's missing some headers which break on major bump [13:26:05] <CIA-38> ffmpeg: Martin Storsjö <martin(a)martin.st> master * r1f56f5ed6d ffmpeg/libavformat/sapenc.c: [13:26:05] <CIA-38> ffmpeg: sapenc: Free AVStream->info on cleanup [13:26:05] <CIA-38> ffmpeg: This fixes yet another memory leak, present since SVN rev 25418. [13:26:05] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:34:58] * elenril spams the ML some more [13:35:07] <elenril> ok, now only the request_channels problem remains [13:36:12] <elenril> anybody feels like fixing it? [13:36:23] <kshishkov> merbzt should [13:36:29] <mru> fixing it fully is non-trivial [13:39:27] <elenril> or we can postpone it to next major bump if everybody's too lazy [13:39:40] <kierank> elenril: can you fix metadata with weird characters in ts files [13:40:04] <elenril> "weird characters"? [13:40:06] <elenril> samples? [13:40:48] <kierank> i'll see if i can find one i can shre [13:41:06] <kierank> or maybe it was a problem with my shell [13:41:39] <elenril> and i didn't ever touch the ts stuff, so i don't know how metadata works in it [13:42:48] <kierank> I think ts uses a different character map [13:43:19] <av500> yes, there are some wierd char maps [13:43:41] * kierank blames all the weird languages [13:43:49] <mru> dvb uses some obscure maps sometimes [13:44:06] * kierank also blames people with funny characters in their name [13:44:08] <av500> latin-5 [13:44:26] <mru> ever had to deal with hebrew text in dvb? [13:44:33] <av500> mru: nope [13:44:38] <av500> only on tags [13:44:40] <av500> in [13:44:46] <kierank> mru: must have been commonplace at nds i guess [13:45:06] <mru> they have/had customers in israel [13:45:43] <kshishkov> kierank: ever heard about Cyrillic? [13:46:01] <kierank> kshishkov: yes but as a true brit I ignore all foreign langauges [13:46:32] <mru> kierank: so do I, but my definition of foreign is a little different [13:46:45] <elenril> saste: did you finish adding av_ prefixes to audio stuff in lavf? [13:47:21] <kshishkov> mru: inte Älvdalska? [13:47:32] <mru> kshishkov: I don't speak that [13:47:34] <jannau> DVB defaults to iso 6937 [13:48:21] <saste> elenril: no, I just did that as I was moving stuff from lavc -> lavcore [13:48:35] <kshishkov> mru: Orsamål? [13:48:36] <saste> elenril: but major work need to be done with the audio API anyway [13:48:49] <saste> elenril: so prefixing could go with that... [13:48:49] <mru> kshishkov: that I understand, not speak [13:48:55] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r151595fe2e ffmpeg/libavcodec/amrwbdec.c: [13:48:55] <CIA-38> ffmpeg: Rename remaining occurrences of SAMPLE_FMT_* to AV_SAMPLE_FMT_* [13:48:55] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:49:05] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rb2ed95ec48 ffmpeg/ (5 files in 2 dirs): [13:49:06] <CIA-38> ffmpeg: Replace remaining occurrences of CODEC_TYPE_* with AVMEDIA_TYPE* [13:49:06] <CIA-38> ffmpeg: Tested to compile with lavc major bump. [13:49:06] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:49:07] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * ra9d921cbad ffmpeg/libavformat/tty.c: [13:49:07] <CIA-38> ffmpeg: tty.c: rename PKT_FLAG_KEY to AV_PKT_FLAG_KEY. [13:49:07] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:49:30] <elenril> saste: well i'm wondering if it should be removed now or postponed until next major bump [13:49:51] <saste> elenril: what do you want to remove? [13:50:31] <elenril> all the deprecated stuff under FF_API_AUDIO_OLD [13:50:54] <kierank> lol someone made subs for the troll film using google translate [13:51:02] <kshishkov> mru: be glad you don't live in Hungary. Their equivalent to word "skål" would make one sober [13:51:21] <mru> kshishkov: btw, I do speak Moramål [13:51:34] <kshishkov> kierank: that's traditional way of subbing movies and games [13:51:34] <saste> elenril: major bump or you break applications linked to the old libavcodec [13:51:59] <kshishkov> mru: well, I just misplaced your location then [13:52:19] <mru> in that region, every street has its own dialect [13:52:20] <elenril> saste: well yes, that's why i'm doing it [13:52:28] <elenril> we think it's time for a big bump [13:52:44] <kshishkov> mru: that's no problem for me [13:52:49] <saste> of all the libs? [13:53:02] <mru> that's why it's big [13:54:23] <saste> there is a problem in error.h.. AVERROR(EINVAL) and AVERROR_INVALIDDATA share the same code [13:54:39] <saste> I proposed a "big bump" sometimes ago for resolving that problem [13:54:47] <saste> note that michael was against [13:55:02] <saste> but if we want to go for that then that problem should be fixed [13:55:39] <kshishkov> patchiswelcome [13:55:43] <saste> indeed changing the error code in libavutil is going to change the behavior of all the depending libs [13:56:33] <mru> lavc was last bumped in 2008 [13:57:38] <siretart> saste: what's the status of lavfi-audio? - I'd like to see your changes to the API included before the big bump. [13:58:01] <saste> siretart: what's your schedule [13:58:14] <kshishkov> mru: and what was release gap between 0.4.9 and 0.5.0? [13:58:21] <siretart> saste: I'm trying to make one :-) [13:58:26] <saste> siretart: I'm quite busy and those changes need some thought [13:59:24] <siretart> saste: ok. I think march or april would be okay, however it seems that people here seem to be pretty keen on merging -mt, which i'd prefer to happen after branching off 0.7 [13:59:49] <mru> lavf last bump was in 2007 [13:59:57] <saste> siretart: it may take some weeks or some months.. [14:00:16] <saste> siretart: but maybe for march / april may be ready [14:00:26] <DonDiego> siretart: what about declaring libavfilter API unstable? [14:00:38] <saste> DonDiego: already is [14:00:59] <DonDiego> we can leave it out of the release also [14:01:01] <siretart> DonDiego: is it really such a big deal to promise bumping major of avfi for api/abi breaks?! [14:01:29] <DonDiego> or say it's unstable and merely include it with a promise that code written against it will soon break [14:02:30] <saste> I don't see the problem with the second approach.. it is what we did for 0.6 [14:03:35] <siretart> AFAIR, avfi did not break interfaces from 0.5->0.6. however, it didn't hardly matter. now with 0.7, I expect avfi to do matter [14:04:04] <siretart> err, I think you get what I meant to write [14:06:09] <tetsuo55> mt merge is going to kill me :P [14:06:15] <tetsuo55> but im happy for it [14:06:32] <lu_zero> tetsuo55: why? [14:06:50] <tetsuo55> lu_zero: it will most probably become incompatible with the DXVA1 patches we apply [14:07:07] <tetsuo55> i believe we don't already use the -mt because of that [14:07:12] <kierank> tetsuo55: that's not true [14:07:28] <kierank> there are two version of ffmpeg in mpc-hc [14:07:43] <kierank> one which is torn apart in order to do the h.264 handling [14:07:48] <kierank> and a near-vanilla one [14:07:50] <tetsuo55> sure, but the mt version is only used as an optional backup for failing dxva [14:09:19] <tetsuo55> too bad casimir isnt around to help port over DXVA1 support to the already existing DXVA2 code [14:10:35] <siretart> I guess that as soon as -mt is merged, this problem will be resolved within a reasonable timeframe [14:11:41] <tetsuo55> maybe it will make the changes more urgent [14:12:14] <tetsuo55> we're tired of having so many patches over ffmpeg for our directshow fork, its time to clean house and and use an as vanilla as possible ffmpeg [14:12:24] <elenril> ok, all the cruft removed [14:12:30] * elenril wonders how many things did he break [14:14:04] <tetsuo55> kierank: we've voted on removing any remainng code to make lavc compile with msvc, so once everyone replies and agrees it will be easier to use vanilla [14:14:22] <kierank> finally [14:15:11] <tetsuo55> nobody ever does it anyway, just test the file in ffplay and its clear which part of the code is at fault [14:16:14] <tetsuo55> even if ffmpeg new management did want to be able to compile with msvc officially, we've only patched a tiny amount of the total codebase [14:17:10] <lu_zero> tetsuo55: the stance had always being that we try to not break msvc, but the ffmpeg target is a c99 compiler (and system headers) [14:17:39] <tetsuo55> lu_zero: yes and i assume it will remain that way [14:17:51] <lu_zero> so if your changes aren't invasive or not break other systems [14:17:57] <kierank> merbzt: find anybody to do h264 422 yet? [14:17:57] <Kovensky> MSVC has got stdint now [14:17:59] <Kovensky> but no inttypes yet [14:18:39] <lu_zero> they won't be rejected just because they are msvc-related [14:19:00] <lu_zero> but might be rejected because they break other supported platforms [14:19:26] <lu_zero> anyway if you have a public repo for your changes we could add it to the website [14:19:39] <Kovensky> idk, I've seen mingw compatibility changes being rejected before just because [14:20:10] <mru> nothing was ever rejected just because [14:20:17] <lu_zero> Kovensky: which ones? [14:20:19] <tetsuo55> would full support of C++0x in msvc solve any incompatibilities it currently has with c99 specific code? [14:20:35] <lu_zero> tetsuo55: might add more =| [14:20:37] <mru> but dirty, invasive hacks to support a non-standard platform are rarely accepted [14:20:50] <tetsuo55> it says on wikipedia they target backwards compatibility with c98 not c99 [14:21:29] <lu_zero> tetsuo55: if they provide system headers probably there would be less problems [14:21:41] <Kovensky> well yes, but such a platform (which despite the non-standardness is the only one available to run the software on a major OS (cygwin and virtualization don't count)) might require those dirty hacks to work at all [14:22:09] <lu_zero> Kovensky: hopefully not [14:22:13] <kshishkov> tetsuo55: of course, who've ever heard about win99? [14:22:21] <Kovensky> well, the biggest culprit is usually pthread-w32 [14:22:32] <Kovensky> not really mingw [14:22:46] <lu_zero> (said the guy who replaced the bada headers to build ffmpeg) [14:23:04] <Kovensky> but in order to, for example, support unicode filenames on windows, you need special casing for all filesystem calls [14:23:22] <Kovensky> I remember someone (ramiro? TheFluff?) was working on something like that but it was dropped on bikeshedding [14:23:26] <mru> that gets really ugly really quickly [14:23:42] <lu_zero> Kovensky: macro-renaming doesn't work? [14:23:43] <mru> some things are just not worth supporting [14:23:53] <Kovensky> lu_zero: no, you also need to do charset conversion [14:24:23] <tetsuo55> this is our patched fork http://code.google.com/p/mpc-hc/source/browse/#svn%2Ftrunk%2Fsrc%2Ffilters%… [14:24:30] <tetsuo55> unfortunately google code search is broken [14:24:38] <tetsuo55> so i cannot single out our patches [14:24:53] <mru> I'd like to point out that we _do_ work around broken systems when this is possible in a clean way [14:24:54] <tetsuo55> we dont host them seperately :( [14:25:08] <mru> cf libavutil/libm.h [14:25:28] <lu_zero> Kovensky: uhm? [14:25:34] <lu_zero> tell me more [14:26:15] <lu_zero> tetsuo55: would be great if you could host those changes in a git repo ^^; [14:26:43] <Kovensky> lu_zero: mingw / msvcrt don't support unicode on the standard calls (fopen, printf, etc) [14:26:58] <Kovensky> you need to use the 'w' variants and feed them UTF-16 strings for it to work [14:27:18] <tetsuo55> lu_zero: it would wouldnt it :P [14:27:33] <lu_zero> ^^; [14:27:39] <Kovensky> and there's still the issue of the console; by default it will convert anything to the computer's default charset [14:28:01] <Kovensky> you could just set the codepage to 65001 (secret, unmaintained UTF-8 codepage), but then the console has a few rendering errors [14:28:20] <tetsuo55> most patches are marked with a comment like this "Start patch MPC" "End patch MPC" but the wording is not consistent, and there are also patches marked with ffdshow, and a few are unmarked. Many of them are DXVA related in h264 and VC1 [14:28:44] <tetsuo55> in our case we basically use a wrapper to translate directshow stuff to lavc stuff [14:29:06] <tetsuo55> all the patches in the code itself only solve compiling errors and add dxva (in theory) [14:29:25] <tetsuo55> the whole talking to windows part is handled by windows specific wrapper [14:30:40] <tetsuo55> and the compiling with msvc is probably only interesting for us with regards to debugging those dxva patches [14:31:04] <tetsuo55> ofcourse others might be interested in doing other stuff [14:32:23] <lu_zero> uhmm [14:32:37] <lu_zero> sounds quite hard to split them up =| [14:32:44] <tetsuo55> im sorry the changes in our code are not ready to use patches, but the people who made them are all MIA, so its up to the remaining non-experts in this area to mark them and keep them when we update from ffmpeg git [14:33:02] <kierank> blame clsid [14:33:05] <tetsuo55> thats also one of the mainreasons we're voting for deleting them [14:33:16] <tetsuo55> kierank: yes hes a big cause, he refuses to mark them [14:35:33] <tetsuo55> the project he works on ffdshow, is also responsible for creating most of the patches in the source i showed you, and since they use a slightly larger portion of lavc there are many more (unmarked) ones in their fodk [14:35:34] <tetsuo55> fork [14:36:02] <tetsuo55> all of them are to make lavc play nice with msvc and the directshow wrappers [14:38:10] <tetsuo55> i dont have a link to the source due to sourceforge's stupidness [14:41:09] <tetsuo55> lu_zero: maybe its better to start over, make a clean wrapper and then an as vanilla as possible ffmpeg inside that, and then work together on solving compiling errors [14:41:41] <tetsuo55> the wrapper should not be comitted, but the compiler errors in ffmpeg code could be cleanly solvable [14:41:44] <mru> tetsuo55: reformatting the code to your style rules doesn't help diffing... [14:42:05] <tetsuo55> mru: our project doenst do that [14:42:15] <tetsuo55> mru: must be ffdshow then :( [14:42:58] <mru> look at e.g. r1783 in your svn [14:43:09] <tetsuo55> that was reverted [14:43:18] <tetsuo55> was a mistake [14:43:26] <mru> ah, so I see [14:44:22] <tetsuo55> we now have strict rules on thirdparty stuff, all changes must have a patch comment decleration (but ffdshow does not have this rule) [14:44:44] <tetsuo55> and something like astyle may never be applied [14:44:56] <tetsuo55> that formatting actually broke compilation becaue it messed with inline assembly [14:44:57] <tetsuo55> :P [14:46:02] <lu_zero> ^^; [14:46:09] <DonDiego> tetsuo55: try uncrustify instead, works infinitely better than astyle [14:46:57] <tetsuo55> thanks ill check that out [14:51:29] <kierank> bye [14:53:41] <elenril> 33 files changed, 44 insertions(+), 768 deletions(-) [14:53:44] <elenril> ^lavc major bump [14:56:06] <lu_zero> wow [14:57:16] <kshishkov> heh, any mru can affect more files by simply adding FATE tests [15:10:53] * elenril glares at kshishkov [15:10:57] <elenril> my patch is waiting [15:14:58] <spaam> kierank: going to leave us? :( [15:15:23] <kierank> spaam: no [15:15:27] <kierank> was saying bye to michaelni [15:15:29] <kierank> belatedly [15:15:51] <spaam> he like to leave this channel [15:33:27] <michaelni> uhm, where did my op status go? [15:33:39] * michaelni kicks ChanServ [15:34:00] <spaam> michaelni: you forgot to auth? :) [15:34:16] <michaelni> fuck no [15:34:22] <michaelni> i identified [15:34:36] * michaelni kicks ChanServ harder [15:34:43] <spaam> michaelni: try /msg chanserv op #ffmpeg-devel [15:34:47] <kierank> yeah [15:35:09] <michaelni> tried [15:35:13] <iive> spaam: he got auto-op-ed in mplayer. [15:35:19] <spaam> iive: i saw that [15:37:05] * elenril does TheBigSpam [15:37:39] <elenril> michaelni: what do you think about bumping major [15:38:11] <michaelni> elenril, no objection but id like to look over what that changes and IMHO this should be discused on ML [15:38:25] <elenril> sure, i just sent the mail/patches [15:38:49] <elenril> it doesn't really change anything except LIBAV{CODEC,FORMAT}_VERSION_MAJOR++ [15:38:57] <elenril> and removing everything deprecated [15:39:16] <iive> isn't major bumped after release? [15:39:37] <elenril> our relese managers want to bump first, release after [15:39:46] <spaam> elenril: can i haz some cheese with that? [15:40:09] * michaelni guesses the new maintainers have decided to silently deop him [15:40:27] <elenril> michaelni: IT'S THE CONSPIRACY!!!!!111one [15:40:29] <iive> try with voice [15:40:38] <michaelni> iive, ? [15:40:42] <kshishkov> have you tried leaving and coming again? [15:41:03] <DonDiego> michaelni is not in the access list, just checked [15:41:22] <michaelni> DonDiego, is that intended? or mistake? [15:41:32] <iive> well, that's deigo's channel. [15:41:53] <DonDiego> i did not remove you, but i plain don't remember if you were ever added [15:42:03] <DonDiego> you were never on irc, so... [15:42:06] <benoit-> DonDiego: IIRC yes [15:42:17] <michaelni> Dark_Shikari, gave me op i dont know if he added me to any lists [15:42:17] <benoit-> he was in the access list [15:43:01] <DonDiego> michaelni: if you are not in the access list, then op only lasts until you leave [15:43:15] <DonDiego> michaelni: try leaving and entering again [15:44:16] <michaelni> :)))))))))))))))))))))))))))))))))))))))))))))))) [15:44:29] <spaam> woho [15:44:38] * michaelni loves ChanServ and ?DonDiego??? [15:44:40] <spaam> michaelni: going to celebrate? ;D [15:45:02] * kshishkov writes that down to blackmail michaelni at appropriate occasion [15:45:10] <michaelni> DonDiego, was that you who added me bak? [15:47:02] <DonDiego> sure, who else? [15:47:14] * michaelni thanks DonDiego [15:47:50] <DonDiego> np [15:51:36] <michaelni> DonDiego, you have new mail :) [15:54:44] * elenril waits for somebody using the gmail web client to bash him for spamming [16:02:36] <j-b> Adding a field to AVCodecContext needs a minor API bump, right? [16:02:53] <kshishkov> of course [16:03:03] <j-b> Does it require a Changelog entry ? [16:03:16] <elenril> yes [16:03:16] <kshishkov> APIChanges [16:03:21] <j-b> kshishkov: no Micro, then? [16:03:22] <elenril> err yes [16:03:44] <elenril> it'd be better if you removed some fields though ;) [16:03:54] <kshishkov> j-b: nope, micro is for binary-compatible but slightly different things [16:03:59] <michaelni> j-b, dont forget updating that AVOption list [16:04:18] <michaelni> ... when you add a field or change things [16:04:40] <j-b> elenril: sure :D [16:04:46] <j-b> michaelni: got you [16:05:46] <j-b> elenril: if it was my code, yes. But it isn't [16:06:11] <j-b> kshishkov: APIChanges? [16:06:49] <michaelni> doc/APIchanges [16:07:14] * michaelni forgets one of these things normally when adding fields :) [16:08:33] <j-b> got you. Info fwd-ed [16:08:50] <j-b> thx guys [16:10:57] * michaelni wonders if we could maybe drop doc/APIchanges and rather mark commit messages with a keyword and use git to generate it [16:11:26] <michaelni> that also would work alot better with branches and multiple repos that have different hashes/versions [16:11:32] <elenril> or we could use git tags [16:11:38] <michaelni> yes [16:12:02] * elenril wonders where did all the people who wanted to edit commit message disappear to [16:12:28] <mru> shhh, don't wake them [16:12:45] <michaelni> They probably think expelling me solved the problem [16:13:08] <elenril> no more typos! [16:13:30] <j-b> you could have a hook checking for common typos [16:14:50] <lu_zero> michaelni: thanks for repeating what I was long ago [16:15:15] <elenril> oh well, time for some quantum fields :/ [16:15:19] * elenril detaches [16:15:23] <lu_zero> not thanks for twisting it to look like it is your idea and we are against it [16:15:30] <kierank> elenril: you're attached and detached at the same time [16:15:50] <michaelni> lu_zero, what!? [16:15:54] <lu_zero> and demoting you solves more than a problem [16:18:17] <michaelni> lu_zero, i dont remember tags/commit message keywords being discussed previously [16:18:30] <michaelni> for a replacement of doc/APIchanges [16:18:39] <michaelni> or did i misunderstand you? [16:19:44] <lu_zero> I wrote an email with a proposal for tags mapping that apparently everybody agreed with at least in the idea [16:20:05] <michaelni> lu_zero, do you remember the subject? [16:20:12] <michaelni> so i can search ? [16:21:05] <michaelni> i cant remember and id be surprised if i was against reducing work (i really hate) namely updating APIchanges [16:21:41] <iive> are these tags something xml/doc specific, or git specific? [16:21:51] <lu_zero> the whole APIchanges can be autogenerated indeed [16:22:32] <michaelni> and instead of fighting whos idea it was (surely iam not the first who suggested it on this planet) we should rather discuss how t implemet it IMHO [16:22:47] <spaam> git down on git.f.o? [16:22:58] <spaam> nvm [16:23:06] <spaam> i wrote fffmpeg ;S [16:23:18] <lu_zero> too many f [16:23:21] <lu_zero> michaelni: sure [16:24:57] <lu_zero> anyway [16:26:58] <kierank> spaam: that's what happens when you don't spell spam correctly [16:27:12] <spaam> :( [16:28:31] <DonDiego> go figure, i'm getting a videolan account now... [16:28:41] <spaam> wow [16:29:07] <michaelni> :) [16:30:21] <iive> michaelni: i guess your wild whitespace days are over... [16:37:56] <DonDiego> gtg, bye [16:44:06] <lu_zero> I need a better way to show up tag messages [16:44:21] <lu_zero> since I usually pick them with -n [17:40:08] <BBB> astrange: ping again, can you please rebase your patch to master os I can compare to my tree and see why for you make fate fails and for me it doesn't? [18:08:16] <mru> BBB: so on -mt, aside from this little bug, how much work to get vp8 multithreaded? [18:16:52] <j-b> wait a bit to give [18:17:15] <j-b> users of the libs [...] a chance to comment... [18:17:18] <j-b> that would mean us? [18:19:28] <mru> was that a comment? [18:30:24] <mru> damn... I went digging for euros and found a fat wad, only most of it was dollar notes [18:36:18] <spaam> j-b: who else? :D [18:53:48] <BBB> mru: not much [18:53:57] <BBB> mru: I've got a volunteer to do it already maybe [18:54:00] <BBB> mru: so don't work on it [18:54:02] <BBB> mru: it'll be done [18:54:17] <mru> I'm not doing anything, but ARM are keen to see it done [18:54:19] <BBB> mru: get astrange to rebase patch so I can test further [18:59:39] <j-b> mru: because someone is an "*SS" and thinks it is a clever design [19:00:32] <j-b> spaam: like I care :) [19:05:53] <lu_zero> j-b: uh? [19:20:47] <j-b> ? [19:25:36] * lu_zero re-reads the backlog [19:26:09] <j-b> lu_zero: what part did "uh?" ? [19:30:44] <lu_zero> 19:59 < j-b> mru: because someone is an "*SS" and thinks it is a clever design [19:31:05] <j-b> lu_zero: oh, that's an explanation for mru than I cannot say on #videolan :) [19:31:29] <lu_zero> I was trying to understand what's the design in question ^^; [19:31:31] <lu_zero> brb [19:31:49] <j-b> lu_zero: a stupid vlc design using thread cancellation [19:44:41] <spaam> haahah [19:44:45] <spaam> ops [19:52:43] <lu_zero> I see.. [20:00:56] <j-b> lu_zero: it is a weird, but I cannot fight it, because I can't fix it/replace it. So I shut up [20:03:30] <j-b> is Nicolas George on IRC? [20:08:20] <lu_zero> j-b: uh [20:08:40] <mru> guy who sends patches on ml [20:10:04] <lu_zero> the uh was about the part that is't unreplaceable [20:10:49] <mru> it's not unreplacable as such [20:10:56] <mru> but I guess j-b can't do it himself [20:11:43] <j-b> lu_zero: it is a political decision, indeed. I cannot fight people on important parts of VLC, if I cannot do their work. [20:14:13] <lu_zero> I see =| [20:15:36] <j-b> lu_zero: but I believe mru is right here. A weird decision it is. [20:27:06] <TheFluff> 15:23:22 < Kovensky> I remember someone (ramiro? TheFluff?) was working on something like that but it was dropped on bikeshedding <--- ramiro made a good patch that made it Just Work both on the commandline and in the API and had the switch enabling it as a configure flag [20:27:17] <TheFluff> but mru didn't like it on vague grounds and so it never got committed [20:27:33] <TheFluff> hence everyone on windows works around it by hijacking the file protocol handler [20:27:37] <mru> it was a dreadful patch [20:27:54] <mru> it used an environment variable to move information from one place to another [20:28:10] <TheFluff> oh right it used an env variable that enabled or disabled it [20:28:15] <mru> worse [20:28:15] <TheFluff> the configure flag was mine [20:28:20] <TheFluff> it did? [20:28:33] <mru> the command line flag set an env var, and the file protocol read it [20:28:51] <TheFluff> I don't remember that but if you say so [20:29:00] <TheFluff> that would be pretty ugly yes [20:29:00] <mru> it morphed into that [20:29:59] <TheFluff> extern URLProtocol *first_protocol; [20:30:09] <TheFluff> I'm pretty sure this isn't part of the lavf api [20:30:13] <mru> it's not [20:30:14] <TheFluff> +public [20:30:20] <TheFluff> I figured [20:30:28] <elenril> i think it still is [20:30:30] <elenril> but deprecated [20:30:32] <mru> no [20:30:39] <TheFluff> it's what windows apps uses to work around the issue [20:30:41] <mru> didn't Flameeyes hide it even? [20:30:47] <TheFluff> it still works [20:30:57] <elenril> ah, it was first_{i,o}format [20:31:03] <elenril> nvm then [20:31:50] <TheFluff> just grab the list of protocol handlers, loop over it until you find the file one and replace it with your own that converts utf8 in char* to utf16 in wchar_t and calls the windows functions [20:32:06] <TheFluff> if there's a sanctioned way of doing this I'd be glad to know about it [20:32:53] <wbs> TheFluff: iirc there's a public av_ prefixed function that gives you the first protocol [20:33:02] <mru> windows is just hopeless [20:33:24] <TheFluff> wbs: oh? [20:33:42] <mru> filenames from open dialogs have one format, command has another, and the syscall expect any of a zillion others [20:33:55] <mru> *command line [20:34:05] <TheFluff> what do you mean "format" [20:34:16] <mru> encoding [20:34:36] <TheFluff> everything uses utf16 in wchar_t afaik... [20:34:39] <wbs> TheFluff: av_protocol_next(NULL) will give you the first protocol [20:35:02] <TheFluff> wbs: is that in libavutil? [20:35:09] <wbs> TheFluff: libavformat [20:35:37] <TheFluff> it's not in my avformat.h... [20:35:41] <mru> TheFluff: if everything used utf16 the patch wouldn't be so ugly [20:35:43] <TheFluff> was it added in like, the last week? [20:35:53] <wbs> TheFluff: it's in avio.h, just below first_protocol [20:36:02] <TheFluff> oh ok [20:36:47] <TheFluff> mru: I don't think I understand [20:37:00] <mru> I never quite understood it fully either [20:37:26] <TheFluff> wmain() (the unicode version of main) uses utf16 in wchar_t [20:37:35] <TheFluff> so does _wopen and its friends [20:37:47] <TheFluff> so does everything else really [20:37:55] <TheFluff> so I think I'm missing something here [20:38:06] <TheFluff> wbs: thanks by the way [20:38:08] <mru> playlist files? [20:38:23] <TheFluff> what about playlist files [20:38:32] <mru> they could contain any encoding [20:38:48] <mru> so you'd have to a) know which one, and b) convert it to utf16 [20:39:04] <mru> unix is so much nicer [20:39:52] <TheFluff> you have the exact same issue on unix, it's just that everyone expects everything to be in utf8 [20:40:15] <mru> no [20:40:26] <mru> a filename is just a string of bytes other than nul or / [20:40:30] <TheFluff> in this case you'd convert the playlist file to utf8 because we haven't changed any lavf api calls, they just expect utf8 instead of iso8859-1 [20:40:44] <mru> so you can simply assume that the playlist uses the same encoding as the filename [20:40:50] <mru> and just pass it through [20:40:52] <lu_zero> btw there isn't any way to force utf8 ? [20:40:59] <TheFluff> force utf8 where [20:41:32] <astrange> POSIX apis for hfs+ require utf8 [20:41:46] <astrange> as i recall this made linus very mad at some point and i wasn't convinced he had a point [20:42:23] <TheFluff> mru: I still don't see why you're so opposed to supporting unicode on windows anyway [20:42:28] <TheFluff> it certainly doesn't make things any worse [20:42:36] <mru> I'm not opposed to supporting anything [20:42:39] <TheFluff> playlist files won't work correctly on windows right now anyway [20:42:44] <mru> I'm opposed to dirty, unmaintainable hacks [20:42:49] <TheFluff> 15:23:42 <@mru> some things are just not worth supporting [20:42:52] <TheFluff> excuse me [20:42:59] <TheFluff> but this is hard to interpret as anything else [20:43:12] <mru> given the amount of effort and ugliness [20:43:13] <wbs> astrange: the issue with hfs is that they use utf8 NFD - if you write a file with an utf8 filename in composed form, it will actually store it in another format, messing up things like git [20:45:44] <lu_zero> TheFluff: forcing everything reaching ffmpeg to utf8 [20:46:19] <mru> the latest I can find on that patch says this: [20:46:24] <mru> > Won't this break the command line tools? [20:46:24] <mru> It will for all filenames that aren't effectively 7-bit ASCII, at least until a [20:46:27] <mru> patch to add Unicode support for the command line tools is accepted. (My first [20:46:30] <mru> attempt at a reworking of Ramiro's old patch does add input support that works [20:46:33] <mru> just fine, but when ffmpeg attempts to print the input filename it just prints [20:46:36] <mru> garbage because the vanilla printf doesn't expect UTF8. Maybe a patch that adds [20:46:39] <mru> Unicode support should fix that too.) [20:59:52] <TheFluff> printing unicode to cmd.exe in a way that makes it actually show up properly on all systems is probably impossible [21:00:07] <TheFluff> even using _wprintf and whatnot usually doesn't work [21:00:28] <TheFluff> maybe it's better in powershell but I haven't tried [21:02:25] <TheFluff> (it prints the right thing, as it works if you redirect stderr/stdout to a file, but cmd.exe can't show it properly) [21:02:53] <lu_zero> uhmm [21:03:00] <mru> you mean the terminal app, not cmd.exe [21:03:02] <lu_zero> but is that important? [21:03:32] <TheFluff> mru: cmd.exe is the terminal app on windows, to which this patch applies [21:03:36] <TheFluff> lu_zero: not to me it isn't [21:03:45] <TheFluff> but mru would probably disagree [21:04:12] <mru> cmd.exe is the windows shell interpreter [21:04:21] <mru> the window itself is rendered by something else [21:04:35] <mru> cmd.exe will run inside xterm, if a bit oddly [21:05:16] <TheFluff> I'm not sure where you're trying to get with this splitting of hairs but sure if you insist [21:05:46] <Plorkyeran> http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx [21:06:29] <Plorkyeran> (tldr is _setmode(_fileno(stdout), _O_U16TEXT); makes it work) [21:06:44] <TheFluff> interesting [21:07:02] <TheFluff> then I'd just need to find and replace all the relevant printf's with one that converts to utf16 [21:07:09] <lu_zero> TheFluff: probably there are some workarounds related to the shell and the terminal [21:07:46] <Plorkyeran> you do still have font issues though [21:09:25] <TheFluff> right [21:09:55] <Kovensky> 18:00.08 TheFluff: even using _wprintf and whatnot usually doesn't work <-- I remember seeing something that would make it work in one of the microsoft blogs [21:09:58] <Kovensky> the problem is finding it again D: [21:10:01] <TheFluff> yes plork just linked it [21:10:04] <Kovensky> a workaround is to use ConsoleWriteW, but what if your output is not a console? [21:10:22] <Kovensky> oh [21:51:02] <Dark_Shikari> BBB: question [21:51:16] <Dark_Shikari> in vp8, what happens to t_nnz[8] and l_nnz[8] for a non-skipped block that's i4x4 or splitmv? [21:51:21] <Dark_Shikari> they seem to be left uninitialized?? [21:51:37] <mru> maybe that's the spec [21:51:45] <Dark_Shikari> >implying it has a spec [21:55:22] <Yuvi> t_nnz[8] / l_nnz[8] predictions are only updated for i4x4 / splitmv, regardless of whether it's skip or not [21:55:22] <Yuvi> so they point to the last i4x4/splitmv macroblock or are 0 if there haven't been any [21:56:11] <Dark_Shikari> er... but I thought t_nnz is supposed to be the top macroblock [21:56:14] <Dark_Shikari> and l_nnz is supposed to be the left [21:56:16] <Dark_Shikari> what _are_ they then? [21:56:26] <Yuvi> for [0..7], yes [21:56:51] <Yuvi> [8] can be arbitrarily far back [21:57:00] <Yuvi> but it's still to the left or top [21:57:10] <Dark_Shikari> so it could be 10000 mbs ago [21:57:33] <Yuvi> yes [21:57:39] <Dark_Shikari> that's pretty pants-on-head retarded. [22:36:37] <pross-au> it [22:52:31] <spaam> pross-au: check [22:55:58] <Jumpyshoes> BBB: okay so my finals are finally over. i thought about it and i'm more interested in vp8 encoding. i also might have a job over the summer (still unsure about that) if it matters [22:56:33] <Dark_Shikari> BBB should be done with xvp8 by the summer [22:56:35] <Dark_Shikari> if he's not he's slow [22:56:50] <Dark_Shikari> Jumpyshoes: you have all this other cool stuff to do though~ [22:57:03] <Jumpyshoes> Dark_Shikari: give me access to your sandy bridge and i'll finish my patch :P [22:57:13] <Dark_Shikari> Use boiled_sugar's machine. [22:57:18] <Dark_Shikari> Why do you need another one? [22:57:22] <Jumpyshoes> linux for profiling [22:57:26] <Dark_Shikari> why do you have to profile? [22:57:38] <Jumpyshoes> also, 64-bit [22:57:45] <Jumpyshoes> since cross compiling fails on boiled_sugar's machine [22:58:03] <boiled_sugar> ah I found the way [22:58:07] <Jumpyshoes> but i'd like to know if the functions actually sped up or not [22:58:15] <Jumpyshoes> boiled_sugar: oh, how? [22:58:31] <boiled_sugar> ./configure --host=x86_64-w64-mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-win32thread [22:58:49] <Jumpyshoes> ah, thanks [22:58:52] <Dark_Shikari> Jumpyshoes: but I already saw a checkasm [22:59:08] <Dark_Shikari> so clearly you have something [22:59:12] <Jumpyshoes> yea, i do [22:59:19] <Jumpyshoes> also, i guess i have 64-bit now [22:59:54] <Jumpyshoes> hrm, i'd like to time overall speedups [23:00:49] <Dark_Shikari> That's not really important [23:00:50] <Dark_Shikari> you can do that later [23:01:00] <Dark_Shikari> and we can hire 2chers to time for us `-` [23:01:06] <Jumpyshoes> lol, okay [23:26:16] <BBB> hi yuvi btw :) [23:26:47] <BBB> Jumpyshoes: hm, encoding... darn, means I have to start working on that also, I ws hoping you'd do decoding :-p [23:26:56] <BBB> ok, let me think where we can get you started [23:34:04] <Dark_Shikari> Jumpyshoes: how about 10-bit? [23:34:06] <Dark_Shikari> Given you wrote all that asm =p [23:40:29] <Dark_Shikari> you can help irock [23:40:31] <Dark_Shikari> make your asm useful [23:40:46] <Dark_Shikari> oh btw BBB [23:40:59] <Dark_Shikari> http://pastebin.com/6Qi4XnJ9 [23:41:08] <Dark_Shikari> I can't make this faster. Or maybe my benches are inaccurate, since my stddev is ridiculous [23:41:17] <Dark_Shikari> feel free to test it. it definitely won't be faster on a non-nehalem though [23:41:35] <Dark_Shikari> ideas to make it less bad welcome [23:42:20] <Jumpyshoes> BBB: okay [23:42:23] <Jumpyshoes> Dark_Shikari: 10-bit decoding? [23:42:37] <Dark_Shikari> Jumpyshoes: yes [23:42:42] <Dark_Shikari> irock has a large part already done [23:42:47] <Dark_Shikari> you could work with his tree to help finish [23:42:51] <Dark_Shikari> and also a bit later to help write some asm [23:43:00] <Dark_Shikari> I'll help with asm too [23:43:14] <Jumpyshoes> Dark_Shikari: hrm, i see... i don't know too much about actual h264 decoding though [23:43:23] <Dark_Shikari> You don't need to know that much [23:43:27] <Dark_Shikari> And learning helps [23:43:51] <Dark_Shikari> Learning is good. You'll need to do it anyways to work on an encoder. [23:44:09] <Jumpyshoes> true [23:44:30] <Jumpyshoes> hrm, okay, i'll consider [23:44:34] <Jumpyshoes> where can i find the tree? [23:45:00] <Dark_Shikari> Ask him [23:45:07] <Dark_Shikari> It's probably not public, but he can certainly put it on github [23:45:24] <Jumpyshoes> okay [23:45:33] <Jumpyshoes> irock: where can i find your 10-bit decoding tree?

1 0

IRC log for 2011-02-02
by irc＠mansr.com 03 Feb '11

03 Feb '11

[00:01:02] <mru> ah, I see what's going on [00:01:19] * kierank forgets its 2011 [00:02:33] <mru> he's upscaling chroma by doing a 16x16 idct with zeros outside the top-left quadrant [00:02:44] <mru> so it's dreadfully slow _and_ shit quality [00:04:00] <lu_zero> Dark_Shikari: pong [00:04:22] <Dark_Shikari> oh, I gave your name to a Marvell guy looking for rtp people [00:04:36] <lu_zero> ah [00:07:24] <lu_zero> do they need something specific? [00:10:09] <Dark_Shikari> I don't really know [00:10:13] <Dark_Shikari> it just involved something related to RTP and VLC [00:10:15] <Dark_Shikari> and they were going after me [00:10:21] <Dark_Shikari> and I was like "fuck, I don't know about that stuff" [00:10:26] <lu_zero> =) [00:10:34] <lu_zero> we'll see then ^^ [00:16:53] <Kovensky> "The Total Perspective Vortex is allegedly the most horrible torture device to which a sentient being can be subjected." <-- I thought it was Vogon poetry? [00:17:06] * Kovensky should resume reading [01:09:47] <mru> Dark_Shikari: got any good still images where chroma blocking would be unusually noticable? [01:38:27] <astrange> BBB: you don't see the mpeg4 issues? does make fate run test as well? [01:38:39] <astrange> BBB: h264 patch ok though, i'll apply iy [01:38:47] <mru> make fate runs every test we have [02:23:42] <Dark_Shikari> mru: you mean yv12 chroma blocking? [02:23:46] <Dark_Shikari> or compression chroma blocking? [02:23:52] <Dark_Shikari> (be more specific in what you're looking for) [02:25:39] <mru> dct blocking [02:26:49] <Dark_Shikari> explain what you're using this for [02:27:15] <mru> to demonstrate that libjpeg is shit [02:27:25] <Dark_Shikari> as compared to what? [02:27:32] <Dark_Shikari> why chroma in particular, etc [02:27:37] <Dark_Shikari> tell the whole story and I'll find you the most obnoxious thing possible [02:27:38] <mru> older versions of libjpeg [02:27:46] <Dark_Shikari> what in particular about chroma [02:28:04] <mru> since v7 the idiot uses his "clever" dct scaling to upscale chroma [02:28:35] <mru> I'm expecting that to introduce blocking compared to a bilinear upsampling or whatever [02:28:37] <Dark_Shikari> on decode you mean? [02:28:40] <mru> yes [02:29:03] <Dark_Shikari> hmm. [02:29:28] <Dark_Shikari> gmaxwell might know more about the worst possible case for this, he knows more about interpolation vs dct theoretics than I do. [02:30:13] <mru> he's taking the 8x8 coeffs and padding to 16x16, then doing a horrendously slow 16x16 idct [02:30:29] <Dark_Shikari> loool [02:30:53] <mru> 40-50% slower than w/o that "feature" [02:30:57] <mru> total [02:31:07] <mru> a comment in the code says it's faster [02:31:14] <Dark_Shikari> looool [02:32:53] <Dark_Shikari> mru: here's a simple thing to start with, create an image with a rapid chroma gradient [02:32:56] <Dark_Shikari> and see how well that works [02:33:16] <Dark_Shikari> hmm... the ideal would be the case where the gradient between blocks is different from that within blocks. [02:33:20] <mru> that occurred to me as well [02:33:37] <Dark_Shikari> so you could generate an image where the slope across block boundaries is higher than the slope within blocks. [02:33:53] <mru> but I'd like a something real as well if possible [02:33:56] <Dark_Shikari> Of course [02:34:45] <Dark_Shikari> Next thing you know, he'll be combining Y, U, and V coefficients [02:34:47] <Dark_Shikari> and doing RGB idcts [02:34:55] <mru> obviously most images have more information in the luma plane [02:35:21] <Dark_Shikari> mru: actually, I have a set of test images I used for a blind test to convince my boss that 4:2:0 subsampling sucked for an image editing application [02:35:33] <mru> that might do it [02:36:21] <Dark_Shikari> not necessarily useful to use, but you could use it to see what kind of things are most sensitive to chroma changes. [02:38:48] <Dark_Shikari> uploading now [02:39:06] <Dark_Shikari> it includes 4 images: 4 photoshop screenshots and 1 SAI screenshot [02:39:21] <Dark_Shikari> each one has three types (randomized, blind): original RGB, YV24, and YV12 [02:39:26] <Dark_Shikari> (all were converted back to RGB and stored as png) [02:40:41] <astrange> Y guided edge interpolation would be a good way to do chroma upscaling, if you could notice it [02:40:44] <astrange> which i doubt [02:41:15] <mru> plain bilinear has to be better than 8x8 block based [02:41:16] <astrange> i wrote a program against jpeg6 that broke with 8, but it sounds like the solution is not to upgrade past 6... [02:41:34] <mru> there's a compile-time switch to turn of the crap [02:41:43] <mru> and then it's actually a little faster than v6 [02:42:33] <BBB> astrange: thanks for pushing [02:42:41] <BBB> astrange: make fate completes succesfully, including all vsynth tests [02:43:04] <BBB> astrange: can you post a new patch, so I can test it in a separate branch and make sure it's not a local hack somewhere that makes things work? [02:45:16] <Dark_Shikari> mru: http://x264.nl/developers/Dark_Shikari/Photoshop%20Test.tar [02:45:26] <Dark_Shikari> mapping of the blind test files (SPOILERS): http://pastebin.com/CLiXa3N9 [02:46:02] <astrange> hold on, i forgot to eat dinner [02:46:19] <astrange> running build+test [02:48:39] <Dark_Shikari> also if you can't tell the difference between rgb and yv12 on some of those you're blind [02:56:41] <mru> heh, pretty obvious which one is yv12 [02:56:47] <mru> the other two are harder to tell [02:57:37] <Dark_Shikari> Impossible to tell IMO [02:57:42] <Dark_Shikari> in some cases there's no difference pixel-wise [02:58:48] <mru> yeah, I couldn't say [02:59:44] <Dark_Shikari> You can see though what kinds of images tend to die more with chroma futzing. [03:00:04] <mru> ones with sharp chroma edges of course [03:03:13] <BBB> astrange: who needs dinner when you can merge ffmpeg-mt?? [03:03:53] <BBB> mru: did you ever figure out that ppc vp8 bug? [03:03:59] <mru> me? no [03:04:00] <BBB> mru: the -2 that should be -1 overread [03:04:03] <BBB> hm... [03:04:09] <BBB> who here can write/read ppc asm? [03:04:23] <mru> that's not asm, that's intrinsics [03:04:32] * mru can only read/write asm [03:04:35] <BBB> that much I figured, but it's the same to me :-p [03:04:43] <BBB> it's stuff-that-is-not-regular-C [03:04:51] <mru> well, I can mostly read them [03:04:56] <mru> I wouldn't write them [03:05:30] <BBB> can you fix 'em? [03:05:41] <mru> possibly [03:12:19] <CIA-38> ffmpeg: Alex Converse <alex.converse(a)gmail.com> master * r770c410fbb ffmpeg/libavcodec/x86/fft_sse.c: [03:12:19] <CIA-38> ffmpeg: Fix ff_imdct_calc_sse() on gcc-4.6 [03:12:19] <CIA-38> ffmpeg: Gcc 4.6 only preserves the first value when using an array with an "m" [03:12:19] <CIA-38> ffmpeg: constraint. [03:12:19] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [03:12:21] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rc73d99e672 ffmpeg/libavcodec/ (32 files in 4 dirs): [03:12:21] <CIA-38> ffmpeg: Separate format conversion DSP functions from DSPContext. [03:12:21] <CIA-38> ffmpeg: This will be beneficial for use with the audio conversion API without [03:12:21] <CIA-38> ffmpeg: requiring it to depend on all of dsputil. [03:12:22] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [03:32:02] <Compn> Dark_Shikari : so whens your computer demos over cloud computing company go public so i can invest in it ? :P [03:32:08] * Compn forgot the name again [03:32:46] <Compn> gaikai [03:33:37] <Dark_Shikari> we're more likely to be bought [03:34:04] <Dark_Shikari> possible buyers include telecomms (comcast, etc), software makers (adobe, etc), publishers (electronic arts, etc), retailers (gamestop, etc). [03:34:28] <Compn> so theres no way i can invest money and get a return huh? :\ [03:34:30] <Compn> ehe [03:34:39] <Dark_Shikari> =p [03:34:40] <Dark_Shikari> nope [03:34:43] <Compn> shucks [03:35:05] <Compn> well keep me on your investor list for future projects [03:35:18] * Compn not fond of mutual funds and stock markets [03:40:22] <astrange> git doesn't compile for me [03:40:22] <astrange> cd doc && texi2html -monolithic --init-file /Users/astrange/Projects/video/ffmpeg/doc/t2h.init developer.texi [03:40:26] <astrange> Unknown option: init-file [03:40:41] <astrange> /sw/bin/texi2html 1.64 [03:41:06] <mru> too old [04:37:10] <ravipriya419> Hi, I want to build vlc. for that I needed libavcodec. so i installed ffmpeg. But vlc configure still asks for libavcodec. [04:37:57] <ravipriya419> my friend suggested me to install ffmpeg-devel. But i cuoldn't find ffmpeg-devel. can anyone please help me in my problem [04:41:27] <Jumpyshoes> ravipriya419: http://www.ffmpeg.org/download.html he probably means the current ffmpeg repository (i.e. not the stable release). also, this should be in #ffmpeg [04:44:36] <astrange> BBB: http://pastebin.com/rXv2Jbbq [04:44:47] <astrange> haven't had any time to rebase on top of git so i don't know if that applies... [06:28:19] <Dark_Shikari> mru: http://gcc.gnu.org/wiki/reload [06:44:59] <saintdev> mru: something like "Chapter 6: Chroma Upsampling Error Tests" on http://www.tomshardware.com/reviews/hqv-2-radeon-geforce,2844-6.html may be what you're looking for [06:46:51] <elenril> morning [06:55:52] <elenril> still no -mt? ;) [07:32:50] <astrange> BBB: http://www.speedyshare.com/files/26634359/ffms2-chroma-chaos.mkv decodes wrong with one thread, some chroma problem [07:32:59] <astrange> that's really surprising, it shouldn't have changed at all [07:48:16] <KotH> salve [07:48:54] <cartman> moin [07:49:16] <KotH> günaydin cartman [07:49:44] <cartman> ehlo KotH [08:46:22] <av500> ahoi [08:46:27] <kshishkov> hejsan [08:47:58] <KotH> fujisan [08:48:15] <kshishkov> ? [08:49:05] <KotH> http://www.fujisan.com [08:49:39] <kshishkov> I know about that mountain but why have you mentioned it here and now? [08:50:25] <Dark_Shikari> houraisan [08:51:14] * kshishkov suspects is has something to do with that game series by permanently drunk Japanese [09:06:22] <Sean_McG> I'm fixing vf_scale to not use sws_getContext now that it's deprecated -- do I have to populate the SwsContext structure *before* or *after* I call sws_init_context() ? [09:07:17] <kierank> http://www.imdb.com/title/tt1740707/ [09:07:17] <kshishkov> isn't it supposed to be filled by init func? [09:07:40] <Sean_McG> with defaults, presumably [09:08:32] <kshishkov> ah, comment to sws_alloc_context() says it must be filled before init [09:08:50] <Sean_McG> that's what I read, yeah [09:50:32] <pJok> kshishkov, is there any reason that ffmpeg allows you to have multiple instances of the same command running on the same outputfile? [09:50:54] <kshishkov> because there's no reason to prevent you [09:51:08] <kshishkov> especially if that file is /dev/stdout [09:52:00] <pJok> well, its smart with stdout, but not so practical when you write to the same file, from my experience ;) [09:52:29] <kshishkov> just don't do that [09:53:15] <kshishkov> also I don't know a tool that has that approach [09:53:36] <kshishkov> except for databases [09:54:12] <pJok> well, its just an implementation bug in the distributed encoder system i poke around in [09:54:22] <pJok> that happens to take the same job on two machines simultaneously [09:58:03] <kshishkov> well, I'd install AM system there [10:38:33] <lu_zero> j-b: do you have libvlc documentation/examples at hand? [10:38:47] <av500> the source? [10:39:52] <j-b> http://git.videolan.org/?p=libvlc-demos.git;a=summary [10:40:14] <j-b> http://git.videolan.org/?p=vlc.git;a=tree;f=doc/libvlc;hb=HEAD [10:40:22] <j-b> this would seem the right places :D [10:44:10] * lu_zero is suggesting somebody to use libvlc instead of straight ffmpeg since they want playlist support [10:45:50] <j-b> playlists are a mess [10:46:12] <av500> +1 [10:46:27] * av500 thinks that overloadeing .m3u with 3 totally different things was a bad idea [10:48:12] <j-b> not to mention, asx, wsx, zpl, wpl, wpl that are all variants of M$ mess [10:48:46] <av500> yeah [10:52:39] <av500> j-b: is there a ffmpeg wrapper for libvlc :) [10:53:06] <j-b> I hope not [10:53:16] <j-b> but, i've seen some dshow wrappers and puked [10:53:40] <av500> I mean, can I use libvlc from ffmpeg api :) [10:53:49] <j-b> I hope not [10:59:14] <lu_zero> their problem is the mms related nested redirection through playlist [10:59:26] <lu_zero> so vlc had been the obvious idea =P [11:00:19] <av500> lu_zero: hey, we support that :) [11:05:12] <j-b> vlc has been more tested for porn [11:05:27] <j-b> while ffmpeg is 'serious business'©® [11:05:31] <kshishkov> and MPlayer - for anime which disqualifies them both [11:07:55] <cartman> use ffplay for pr0n [11:08:34] <kshishkov> cartman: or look into its source - it's pornography too [11:08:49] <cartman> sure :P [11:11:16] <lu_zero> av500: we-> who? [11:12:50] <av500> lu_zero: $dayjob [11:13:21] <lu_zero> av500: ^^; [11:15:05] <j-b> saste: I still don't see why you don't adopt a sub-systems maintainers policy [11:36:58] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rb9a639ddd6 ffmpeg/libavcodec/arm/asm.S: [11:36:58] <CIA-38> ffmpeg: ARM: add helper macro for declaring constant data [11:36:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:37:20] <elenril> lu_zero: api bump! [11:37:50] <lu_zero> elenril: where is the commit in ml? [11:38:00] * lu_zero should run in a bit [11:45:17] <Tjoppen> lunsj [11:46:46] * av500 got a bugfixed mpeg2 decoder, size increased by 100% [11:47:26] <av500> or maybe they forgot to strip it [11:47:34] <cartman> likely [11:48:00] <kshishkov> it's from India so can be just all those checks for exactly one buggy case [11:48:31] <cartman> I re'd some C# code from Chinese it had something like this [11:48:39] <cartman> int wifiSignalLevel = random() % 5 [11:48:51] <pJok> cartman, awesome coding [11:48:58] <cartman> that explains the wireless stability [11:49:16] <cartman> it even managed to connect offline wireless modems! [11:49:27] <kshishkov> maybe it was just simulator [11:49:36] <av500> wirulator [11:56:12] <saste> j-b: how does it work? [11:56:44] <saste> j-b: do you mean having every developer having commit rights on a limited part of the tree? [11:56:51] <j-b> no [11:58:19] <j-b> Some developer or group of developer have the reference tree for a limited part of it (lavfi, lavf) [11:58:36] <j-b> they merge the relevant patches in their tree [11:59:02] <j-b> and a developer or a group of developers merges the different important trees to the main ones [11:59:20] <saste> j-b: that can work as well [11:59:32] <j-b> that is mostly as the linux kernel works [11:59:46] <j-b> linus merges trees from the submaintainers [12:00:02] <j-b> submaintainers merges trees from other developers or direct patches [12:00:14] <j-b> if a submaintainer tree is unclean, linus doesn't pull it [12:00:22] <saste> j-b: but it requires some coordination for preventing API/ABI diversion [12:00:30] <elenril> so how does this --8<-- thing work? [12:00:38] <elenril> i didn't find any docs anywhere [12:00:40] <cartman> scissor [12:00:46] <saste> j-b: for example no version bumps in "submaintainers" tree [12:01:09] <j-b> saste: well, a bit of coordination, but not much [12:01:16] <saste> j-b: they are applied to the main branch when submaintainers tree are merged [12:01:32] <j-b> saste: like the reference lavf tree can update its lavf version without the other to care [12:02:28] <saste> j-b: a problem which i see with this approach is that changes are not tested until they're merged [12:02:39] <saste> j-b: indeed fate works only for the "main" branch [12:02:52] <av500> fate could work on any branch [12:03:08] <j-b> I don't see why fate couldn't run on other branches [12:03:11] <pJok> damnit [12:03:24] <pJok> autobuilds of win-ffmpeg all over :/ [12:03:51] * av500 sends pJok to have lunch [12:04:49] <pJok> av500, already had lunch [12:06:09] <saste> av500: do you mean a fate for each topic branch? [12:06:15] <j-b> yes [12:06:20] <saste> av500: if that can be done I'm for it [12:07:11] <j-b> saste: I mean, it is just a suggestion [12:07:31] <j-b> saste: but that can let the right people manage the right parts [12:08:09] <j-b> like having D S work on lavc/x86, and wbs on lavf/network... [12:08:40] <j-b> but, I am a crazyFroggy, so ignore me :D [12:09:25] <saste> j-b: how do you do with vlc? [12:09:31] <av500> the ugly part [12:09:46] <av500> /undo [12:09:59] <av500> worng channel [12:10:14] <saste> j-b: do you follow this submodules maintainership model? [12:10:36] <j-b> saste: we don't do anything, because we are not enough (the core is 3-5people at most) and because we are less important and we don't consider every commit as a release [12:10:43] <j-b> saste: however, i would love to, yes [12:10:57] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r75ea596de1 ffmpeg/ffplay.c: [12:10:57] <CIA-38> ffmpeg: ffplay: factorize code from video_thread() into configure_video_filters() [12:10:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:11:02] <j-b> saste: and seriously, noone cares about VLC [12:11:10] <av500> lol [12:11:12] <j-b> it isn't important [12:11:16] <j-b> it isn't like FFmpeg [12:11:16] <kshishkov> neither is FFmpeg [12:11:28] * kshishkov looks at download numbers for FFmpeg [12:11:49] <av500> kshishkov: you have to add the vlc download numbers [12:11:51] * j-b counts 600M downloads of FFmpeg in the last year [12:12:30] <kshishkov> av500: why, those people definitely choosed to download wrapper [12:12:46] <av500> kshishkov: using lavc without is hard [12:13:16] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r5fce60c3a9 ffmpeg/libavfilter/avfilter.c: [12:13:16] <CIA-38> ffmpeg: Log debug information in filter_samples(). [12:13:16] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:46:57] <DonDiego> saste: how would you feel about a public branch for your libavfilter work? [13:06:38] <mru> it's on my todo list to somehow allow developer repos on ffmpeg.org [13:06:50] <mru> meanwhile, I'm sure j-b would host it [13:07:48] <av500> yeah, lets have v-o host dev repos for ff.org and ff.org host dev repos for v-o :) [13:27:23] <lyakh> mru: hi, so, regarding your review: shall I submit the next version or wait for your ff_mpa_synth_filter() rework? [13:28:38] <mru> feel free to help me with it [13:28:55] <lyakh> mru: in what way? [13:29:36] <mru> ff_mpa_synth_filter() needs some love [13:30:04] <mru> it needs to be able to call apply_window_mp3() through a function pointer like the float version does [13:31:29] <lyakh> that's what my patch does, or would you like that part as a separate patch? [13:31:40] <mru> your patch doesn't do it cleanly [13:31:54] <lyakh> so, you want that context added everywhere? [13:32:04] <mru> I want _some_ context [13:32:11] <mru> it obviously can't be the full mpegaudio one [13:33:17] <lyakh> ok, I'm afraid, explaining this to me will take you longer, than doing it yourself, since I'd now have to ask "what some context" and "why obviously" etc etc [13:33:20] <mru> perhaps put all the state variables and the function pointer into a struct [13:33:38] <mru> I don't mind doing it, but I don't have time today [13:33:43] <lyakh> ok, so, several context pointers in a new struct [13:33:54] <lyakh> it can wait until tomorrow, no problem;) [13:34:04] <mru> I might not have time then either [13:34:23] <mru> but next week is likely [13:39:14] <av500> lu_zero: ping [13:40:20] <lyakh> mru: I would be tempted then to embed that struct in both contexts, but that's kinda silly - to embed a pointer to a struct in itself... Without embedding we'd have to take care about its lifecycle, add alloc / free, etc [13:53:36] <kshishkov> bink^W mate! [13:59:16] <kshishkov> hmm, time to try IRC command /bink [14:01:02] <jannau> elenril: I think you misunderstood me. I would prefer having the actual commit which changed the api in API changes and not the commit which increases the version [14:01:22] <av500> kshishkov: try /nick binkishkov [14:01:45] <elenril> jannau: why [14:01:53] <mru> elenril: because it makes sense [14:01:54] <elenril> people usually test against the version [14:02:06] <mru> but the version is already written there [14:02:25] <mru> the rev is handy if someone wants to look up exactly what changed [14:02:28] <jannau> elenril: it's easier to see the change [14:02:54] <elenril> ok [14:03:09] <jannau> and it's already useable with that commit [14:03:12] <elenril> except for lavf i'm doing one bump per several changes [14:03:23] <elenril> you think i should do three bumps? [14:03:27] <mru> no [14:03:41] <mru> but the file should list the rev that introduced the change [14:04:19] <jannau> list one rev for each change [14:05:30] * mru notes in passing that the latest update to icc 12 still fails on gif [14:06:23] <mru> and what happened to snow on freebsd/clang? [14:07:37] <cartman> mru: http://llvm.org/bugs/show_bug.cgi?id=9123 [14:08:10] <mru> that's the build failure [14:08:23] <cartman> right, I thought you mean a build failure [14:08:27] <mru> on freebsd it crashes during testing [14:09:42] <mru> anyone in the mood for reviewing 2k lines of neon vp8 code? [14:09:56] <av500> lgtm [14:10:03] <cartman> queued [14:10:04] <cartman> :p [14:10:34] <av500> mru: 2k lines? you can do loops, you know? [14:11:08] <BBB> mru: go for it [14:11:18] <BBB> mru: just submit it, benjamin and I will look [14:11:22] <BBB> I can probably half-read it [14:11:26] <BBB> benjamin should be able to totally read it [14:11:37] <BBB> mru: is it faster than libvpx? [14:11:51] <mru> BBB: considerably [14:11:58] <BBB> \o/ [14:12:00] <BBB> awesome [14:12:03] <BBB> let's remove libvpxdec [14:12:05] <mru> >40% in some cases [14:12:13] <kshishkov> even without edge_emu? [14:12:16] <merbzt> anyone wanna do 422 support in the h264 decoder ? [14:12:26] <mru> with whatever ffmpeg command line does [14:12:30] * kshishkov looks for Dark_Shikari [14:12:32] <BBB> non-edge_emu [14:12:38] <mru> and libavfilter off [14:12:49] <av500> merbzt: ? [14:12:50] <mru> lavfi slows it down by 5% due to the stupid memcpy [14:12:52] <BBB> merbzt: how difficult is that? :-p [14:12:54] <kshishkov> mru: in omapfbplay? [14:13:04] <merbzt> no idea [14:13:29] <av500> merbzt: what for? [14:13:45] <merbzt> decode support for that format [14:13:50] <merbzt> avc-intra mainly [14:28:05] <elenril> jannau: in that case, why the .. [14:41:09] <kierank> you need to watch that troll film at fosdem [14:41:21] <av500> which one? [14:41:25] <kierank> http://www.imdb.com/title/tt1740707/ [14:41:55] <av500> upload to samples [14:42:18] <kierank> I would but Compn wouldn't be happy [14:42:46] <kshishkov> do we have space for it there anyway? [14:43:11] <kierank> kshishkov: some bink samples will be deleted for that [14:43:18] <kierank> or maybe vp8 [14:43:36] <av500> delete both fringe format samples [14:44:35] <mru> av500: hmm, that film was put on pirate bay today [14:44:47] <av500> but thats illegal [14:45:00] <mru> it's not illegal to search the site [14:46:22] <kierank> hmmm the blu-ray might even be x264 encoded [14:46:30] <kshishkov> mru: it's illegal to know about it because *AA says so [14:46:47] <cartman> MafiAA [14:47:19] <kierank> hmm no english subtitles for it [14:47:57] <jannau> elenril: when we don't forget to do version bump and APICHANGES in the same commit [14:49:14] <mru> kierank: you don't speak norwegian? [14:49:24] <kierank> nope [14:49:33] <mru> nor do I, but I understand it [14:49:46] <Compn> what troll film ? [14:49:53] <mru> yes [14:49:54] <Compn> the rare exports ? [14:50:10] <kierank> someone needs to fansub it or whatever they do [14:50:27] <kshishkov> mru: at least you've had practice on live Norvegian people [14:50:52] <Compn> kierank : the version in english i saw was good [14:50:52] <av500> we need libavsub [14:50:53] <Compn> :P [14:51:11] <av500> kierank: bastard [14:51:12] <kierank> http://www.youtube.com/watch?v=TLEo7H9tqSM [14:51:13] <Compn> also did you know it was a shortfilm first? i queued up the shortfilms [14:52:40] <mru> kshishkov: when I lived in oslo I was actually able to do a convincing imitation of a norwegian [14:53:03] <mru> took the locals several minutes to suspect anything [14:53:15] <kshishkov> mru: well, either you or Andreas come from place near Norwegian border too [14:53:33] <kierank> av500: I could download it but it'll take all day to upload [14:53:43] <av500> kierank: :) [14:53:47] <av500> its ok [14:54:18] <kierank> download it at fosdem [14:54:33] <av500> ub there? [14:54:43] <kierank> no [14:54:49] <Compn> kierank : did you download the rare exports short films ? [14:54:49] <cartman> scp -r kierank.local:~/Movies . [14:55:01] <kierank> Compn: what films? [14:55:40] <Compn> one sec [14:56:14] <Compn> Rare Exports, Inc. (2003) [14:56:15] <Compn> http://www.imdb.com/title/tt0435312 [14:56:20] <Compn> The Official Rare Exports Inc. Safety Instructions 2005 [14:56:21] <Compn> http://www.imdb.com/title/tt0769542 [14:56:38] <Compn> cinemageddon.net/details.php?id=87299 [15:06:31] <ubitux> "A new general optimization level, -Ofast has been introduced. It combines the existing optimization level -O3 with options that can affect standards compliance but result in better optimized code. For example -Ofast enables -ffast-math." [15:06:35] <ubitux> mpf. [15:06:48] <mru> yeah, don't use [15:07:00] <cartman> ubitux: Gentoo user's are rejoicing everywhere [15:07:07] <cartman> s/'// [15:07:07] <mru> those things can be useful on carefully audited code [15:07:43] <mru> -ffast-math really does make things faster, but if assumes there will never be any inf or nan values [15:07:55] <mru> or denormals in general [15:08:57] <mru> -Ofast might also make assumptions about integer arithmetic never overflowing or similar [15:10:21] <cartman> http://gcc.gnu.org/gcc-4.6/changes.html huge [15:11:37] <ubitux> The -Wsuggest-attribute=[const|pure|noreturn] flag is available that informs users when adding attributes to headers might improve code generation. [15:11:41] <ubitux> this is fun too [15:11:52] <mru> that could actually be useful [15:12:17] <mru> does it also warn about incorrect application of those attributes? [15:12:32] <ohsix> it knows, so why not [15:12:39] <mru> it's also gcc [15:12:56] <ohsix> functions marked noreturn and pure will at least raise warnings if they return [15:13:11] <ohsix> er, pure is something else; but i've seen a warning about it before [15:15:43] <mru> const means the return value depends only on the parameter values with no side-effects [15:15:54] <mru> pure means the same thing but allows global data to be read [15:16:22] <mru> and also data pointed to by parameters [15:16:47] <mru> so strlen() is pure but not const [15:20:24] <av500> GCC now supports the Loongson 3A processor. Its canonical -march= and -mtune= name is loongson3a [15:20:29] <av500> we are saved [15:20:58] <mru> ah, the bogomips [15:21:32] <cartman> Chinese? [15:21:42] <av500> ...Basic support was added for Cortex-A15 and is available through -mcpu=cortex-a15. [15:21:47] <av500> yay for the eagleboard [15:21:52] <kshishkov> mru: bogoMIPS [15:22:02] <kshishkov> mru: also with x86 emulation [15:22:11] <av500> for doublebogo? [15:22:15] <mru> a15 is still a v7-a, "basic" support doesn't mean much [15:22:32] <mru> and with out of order execution, scheduling isn't very important either [15:22:35] <kshishkov> mru: basic support means now you have its name as an option [15:22:43] <mru> probably, yes [15:23:02] <kshishkov> like FFmpeg configure introducing basic support for QNX x86 [15:23:03] <cartman> kshishkov: indeed [15:23:17] <mru> qnx is on fate now [15:23:25] <cartman> QNX will be valuable when RIM releases its Playbook [15:23:38] <mru> I should set up a beagle with qnx/arm [15:23:46] <kshishkov> you did :) [15:23:52] <mru> not for fate [15:23:53] <kshishkov> but without fate [15:24:13] <kierank> why does RIM need to release a device with QNX on it? [15:24:25] <mru> kierank: because they bought qnx [15:24:25] <kshishkov> mru: at least you had spare Beagle for that [15:24:29] <cartman> kierank: because they bought it? [15:24:35] <kierank> mru: well why do they need qnx i mean? [15:24:43] <kshishkov> kierank: because QNX sucks royally with multimedia? [15:24:46] <av500> kierank: because RIMos is dead [15:24:53] <mru> kshishkov: not quite true [15:24:55] <kierank> why couldn't they use linux [15:24:58] <kierank> nih? [15:25:01] <av500> no [15:25:03] <av500> ttm [15:25:10] <mru> qnx isn't a bad os [15:25:26] <kshishkov> yep, but it's for different tasks [15:25:40] <mru> says who? [15:25:41] <av500> kierank: linux from scratch: 2ys, buying an os with 100engineers that workd on it: 6mo [15:25:55] <kierank> k [15:26:27] <kshishkov> mru: well, I know people in Ukraine working on nuclear station controlling software, they praised it [15:26:57] <av500> that station did output more power than asked for, indeed [15:27:12] <kshishkov> mru: and you know guy working on getting playback on QNX-driven HW and he complains about it [15:27:27] <mru> qnx is not to blame for that [15:27:47] <mru> on the beagle it was faster than linux [15:28:09] <mru> using a stock qnx 6.5 bsp [15:29:13] <av500> faster doin what? [15:29:35] <mru> playing movies [15:30:08] <mru> with you-know-which app [15:31:06] <kshishkov> have you also tried omapfbplay there? [15:31:16] <mru> no [15:33:48] <av500> ahm the $serious app? [15:34:07] <mru> the $$$serious app [15:35:05] <kierank> why (is the app) so $$$serious? [15:35:22] <mru> the $$$ refers to my bank account [15:38:11] <kshishkov> kierank: if the company hired mru to optimise it then it's really serious [15:39:40] <av500> mru: so all you did to make it faster was to run it on qnx and not linux..... [15:39:51] <av500> did you consult RIM as well? [15:40:38] <av500> kierank: now you know why they picked qnx [15:42:15] <cartman> heheh [15:42:34] <kierank> knowing RIM it's probably a useless app [15:42:44] <kierank> that they think is the next best thing since sliced bread [15:43:01] <cartman> Blackberry worked out well [15:43:12] <kshishkov> compared to what? [15:43:28] <kshishkov> Diego claims it's one of the least usable phones [15:43:29] <cartman> kierank: other phones? until iPhone came in. [15:43:39] <cartman> kshishkov: ^^ [15:44:03] <kierank> well it had push email that worked [15:44:05] <kierank> that was about it [15:44:13] <mru> kierank: I was not hired by RIM, if that's what you thought [15:44:30] * mru curses android [15:44:31] <cartman> kierank: it saves Egyptians' ass [15:44:33] <mru> phone locked up [15:44:39] <mru> all I did was try to make a call [15:44:42] <cartman> saved* [15:45:08] <cartman> mru: adb logcat :p [15:45:10] <kshishkov> mru: but that's not a proper task for modern smartphone [15:45:17] <mru> cartman: it rebooted now [15:45:22] <mru> I guess watchdog woke up [15:45:33] <cartman> nice [15:47:05] <av500> mru: N1 is the worst phone I ever owned [15:47:13] <av500> wrt making phone calls [15:47:18] <av500> or receiving them [15:47:24] <cartman> WFM [15:47:27] <cartman> now go away [15:47:36] <kierank> windows mobile is worse [15:47:44] <av500> might be [15:47:47] <mru> bah, the thing is _still_ booting [15:47:47] <cartman> he he :D [15:48:03] <cartman> mru: you sure didn't install a system update? [15:48:13] <mru> a few days ago [15:48:13] <cartman> mru: time to plug adb logca to see wtf its doing [15:48:22] <av500> in android, system update installs you [15:48:33] * cartman rmmod av500 [15:48:48] <av500> cartman: try [15:48:56] <pJok> mru, its probably rebuilding the dalvik cache [15:49:00] <cartman> I'll use -f in order :P [15:49:02] <pJok> that can take forever [15:49:14] <mru> it's shoing a silly animation [15:49:21] <pJok> yeah [15:49:25] <pJok> its probably rebuilding [15:49:39] <pJok> i was afraid i had bricked mine when i upgraded it with a custom rom [15:49:43] <av500> ...compiling.... [15:49:48] <mru> 303 [15:49:51] <cartman> av500: optimizing [15:50:03] <pJok> just turned out to take exeptionally long to boot the first time [15:50:05] <cartman> pJok: there is always fastboot [15:50:13] <av500> cartman: nope [15:50:25] <av500> not if you kill the bootloader [15:50:31] <cartman> av500: well... [15:50:35] <av500> ask jannau [15:50:39] <cartman> or install wrong radio fw [15:51:06] <cartman> Thats kind of expected [15:51:10] <pJok> cartman, i dont have it enabled... im thinking of rolling my own 2.3 for it with SD being initialized way earlier in the procress so i can actually dump stuff like the dalvik cache and internal programs onto my sd card... its not like i use the mount sd card as drive feature anyways [15:51:37] <cartman> pJok: got a Nexus S? [15:51:51] <pJok> cartman, if i did, i wouldn't have that problem ;) [15:52:02] <pJok> cartman, i have a htc desire [15:52:20] <mru> that's ~= n1, right? [15:52:21] <cartman> pJok: ah custom roms out of AOSP :P [15:52:50] <pJok> cartman, its a "stock n1 rom" with sense ui on top [15:52:54] <pJok> mru, yeah [15:53:39] <pJok> cartman, upgraded to 2.2 before it was official for the desire [15:53:50] <cartman> pJok: I wouldn't dare to :p [15:54:26] <pJok> cartman, i dont care... the bootloader is already patched, so what ever i throw at it, it should gobble it up [15:56:04] <pJok> cartman, i just need to figure out how to roll my own 2.3 and fix that sd card stuff [15:56:31] <cartman> pJok: shared libs. in sdcard is supported wit 2.3 now but no idea about dalvik cache [15:56:43] <pJok> well [15:56:46] <pJok> its just unionfs [15:57:00] <pJok> there are a lot of app2sd solutions for it [15:57:37] <pJok> ah well [15:57:38] <pJok> time to run [16:20:43] <mru> the damn phone is _still_ animating [16:21:00] <BBB> astrange: so what happened? :-p [16:34:24] <kierank> av500: I have asked to get english subtitles for the troll film [16:39:07] <av500> trolls got him [17:01:00] <cyclist> high. i just wanted to say that it shouldn't be possible for one to be part of the ffmpeg steering comittee if they dont understand, for example, the MPEG standard. In order to be part of that people should prove AV coding skill by having written an encoder. get your shit together people. wtf with the whitespace gurus running the proj? [17:01:17] <ohsix> will ffplay use the proper pixel size if you set the DAR during encoding (source is 1.28:1 or something) [17:02:19] <ohsix> not sure if either of the things i'm usign to preview the output respect DAR [17:02:26] <Kovensky> cyndis: because our whitespace is better than yours [17:02:30] * Kovensky runs [17:03:06] <av500> whotf was that? [17:03:14] <BBB> a troll [17:03:18] <Kovensky> wrong hilight [17:03:21] <Kovensky> but yeah, lol [17:03:36] <j-b> lol [17:03:51] <av500> even I wrote an encoder one [17:03:55] <j-b> mpeg1 ? [17:04:07] <av500> it took the midle pixel of each line and stored that [17:04:14] <av500> decoder made the whole line that color [17:04:17] <Flameeyes> yeah because whoever wrote the reference encoders for h264 were very good at coding, don't you think so Dark_Shikari? :P [17:04:22] <Kovensky> I never wrote an encoder, but I don't think it'd be very hard to take YV12 data, rot13 it and write it encoded ;) [17:04:49] <Kovensky> then to decode you'd have to irot13 the input data and present it as YV12 [17:04:51] <j-b> Kovensky: you need to asm the rot13 though :D [17:05:25] <av500> and then rot13 the asm [17:05:28] <BBB> mru: your neon code is really nicely organized [17:05:35] <BBB> mru: with some imagination I can pretty much read it [17:06:00] <BBB> mru: so for sixtap filters, you're basically using a complete 8xword register and not use the last two words right? [17:06:03] <Kovensky> nah, that's the job for those crazy CPU people, not encoding people [17:06:19] <av500> I dont like the label names [17:06:38] <Kovensky> actually, as bonus points for the rot13-based codec, it can support any colorspace! [17:06:48] <Kovensky> now, someone just need to make a matroska mapping for it... [17:06:51] <Kovensky> +s [17:13:51] <mru> BBB: yes, that's right [17:14:01] <mru> I don't know of a better way [17:15:02] <mru> btw, robclark did the ground work for epel and loopfilter [17:15:09] <mru> I just made it twice as fast [17:17:29] <av500> mru: what res can you now decode on omap3? [17:17:39] <mru> av500: which omap3? [17:17:52] <mru> a 1GHz one should manage 720p fine [17:18:02] <av500> oh [17:18:19] <av500> nice [17:18:39] <av500> but some mhz needed for audio and $the_rest [17:18:50] <mru> the 600MHz can almost do it [17:18:56] <av500> k [17:19:05] <av500> I will add it here and test [17:20:38] <BBB> mru: let me check, I thought we did that different for x86 [17:20:53] <mru> BBB: h or v? [17:21:04] <BBB> both, I think [17:23:12] <BBB> I think we run four rows rows/cols at once, then multiply all of them with the first two coeffs, then the second 2 coeffs and the third 2 coeffs, and then sum it [17:23:20] <mru> hold on, you're confusing me [17:23:35] <mru> the only place the full width isn't used is some of the width-4 ones [17:23:58] <BBB> width=4 [17:24:46] <mru> for width 8 it uses 6 registers with 8 values in each [17:25:26] <mru> the width 4 ones don't quite fill the registers since doing that would cost more than it saves [17:28:14] <mru> does x86 have multiply-accumulate? [17:29:20] <BBB> no :( [17:29:25] <BBB> it has pmaddubsw [17:29:29] <av500> it has complicate [17:29:38] <BBB> and then sum of two neighbouring ones [17:29:45] <BBB> but not sum of all values into a single one [17:30:12] <BBB> anyway, sounds like neon has an insutrction that saves much more than this, so then it's ok [17:30:17] <BBB> just an x86'ism ;) [17:30:31] <mru> I don't see the neon code calculating anything that isn't used [17:30:45] <mru> except some of the width=4 parts [17:31:42] <mru> the horizontal ones there can't easily be packed [17:36:56] <mru> BBB: the mc functions do overread horizontally to a multiple of 8 [17:37:06] <mru> iirc you said that was ok [17:37:44] <BBB> overread at end is always ok [17:37:47] <BBB> overread before start is not [17:38:05] <BBB> also, when you say "3% faster", you mean overall, not in that function, riht? [17:38:08] <mru> nor would it be beneficial [17:38:12] <mru> overall, yes [17:39:23] <mru> the decode_block_coeffs asm is ~ twice as fast as the C code [17:39:29] <mru> gcc really made a mess of that functino [17:39:46] <BBB> I'm planning to do that after ffmpeg-mt is merged [17:39:48] <BBB> one thing at a time ;) [17:39:59] <mru> no pressure [17:47:21] <av500> is -mt merged already? [17:47:31] <mru> no [17:47:40] <BBB> astrange: ping :-p [17:50:33] <mru> pJok: is it normal for android boot to take >2h? [17:50:46] <av500> mru: no [17:51:05] * mru ponders pulling the battery [17:55:53] <av500> mru: do it [17:56:12] <mru> I did [17:57:01] <mru> ah, now it booted normally [18:00:25] <wbs> mru: how long did it take, an hour? [18:00:55] <mru> wbs: it didn't finish [18:00:59] <mru> I pulled the battery [18:01:01] <mru> after 2h [18:01:14] <mru> then it booted in the usual 30s [18:01:15] <wbs> ah, I should read up properly first ;P [18:24:01] <lu_zero> av500: pong [18:25:29] <wbs> lu_zero: would you mind pushing the rtsp patches you ok'd earlier today? [18:26:15] <av500> lu_zero: about free.fr, but I need to go home now [18:27:31] <BBB> wbs: I'll commit them later today [18:27:35] <BBB> if he doesn't beat me to it [18:28:06] <lu_zero> wbs: had a day walking from a meeting to another [18:28:22] <lu_zero> and I'll be back in 3 hours (leaving almost now) [18:28:49] <lu_zero> av500: send me an email or write me once you are at home ^^ [18:48:23] <astrange> BBB: what happened with what? i went to sleep [18:54:26] <BBB> astrange: I was hoping you'd post ffmpeg-mt again [18:54:31] <BBB> did my patch fix your make fate? [18:54:43] <astrange> 23:44 <@astrange> BBB: http://pastebin.com/rXv2Jbbq [18:55:16] <BBB> did make fate pass? [18:55:21] <j-b> who understands the reasoning in libavcore/libavutil? [18:55:54] <astrange> i still see the encoding problems (using the -mt tree, not anything based on ffmpeg git), but h264 was fixed [18:57:18] <BBB> j-b: what reasoning? for the split? [18:57:51] <BBB> astrange: ok, I'm going to compare your patch in a new branch to my current patch, and then see how it went away here [18:58:01] <BBB> maybe I made a local chance that fixed it while sleeping or so [18:58:07] <BBB> I tend to do that, and then forget about it [18:59:39] <j-b> BBB: yes [18:59:42] <BBB> and your patch does not apply :-p [18:59:53] <ruggles> j-b: i think it was to keep libavutil as generic utilities not specifically related to multimedia and libavcore for general multimedia things to share between libs. [19:00:11] <michaelni> ruggles, yes :) [19:01:04] <michaelni> ive used things from libavutil in several of my projects that where not MM related [19:01:26] <BBB> astrange: can you rebase against master? [19:04:12] <astrange> have to look for that filter-branch script [19:05:34] <Dark_Shikari> mru: That's a really nice asm function btw [19:05:36] <Dark_Shikari> it's surprisingly clean [19:05:51] <Dark_Shikari> mru: can't you give your labels names? [19:06:03] <astrange> look = type filter-branch into gmail search, done [19:10:39] <j-b> ruggles: ok [19:12:55] <mru> Dark_Shikari: which function? [19:14:25] <BBB> the ones that have 1: and 2:, presumably? [19:15:17] <kshishkov> but that's very convenient labels [19:25:44] <_av500_> and easy to predict [19:44:02] <Dark_Shikari> mru: your vp8 decode coeffs [19:44:19] <Zor> didn't ffmpeg have some macro for 'nicer' 4ccs? [19:44:42] <mru> lu_zero: ping [19:46:21] <BBB> Zor: MKTAG('f','c','c','x') or AV_RL32("fccx") [19:48:10] <Compn> Zor : see riff.c ? [20:02:44] <elenril> awesome, yet another TL;DR thread! [20:02:52] <elenril> because we don't have enough of those [20:07:25] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rc3beafa0f1 ffmpeg/ (3 files in 3 dirs): [20:07:25] <CIA-38> ffmpeg: ac3enc: Change EXP_DIFF_THRESHOLD to 500. [20:07:25] <CIA-38> ffmpeg: This patch changes the exponent difference threshold in the exponent [20:07:25] <CIA-38> ffmpeg: strategy decision function of the AC-3 encoder. I tested lowering in [20:07:25] <CIA-38> ffmpeg: increments of 100. From 1000 down to 500 generally increased in quality [20:07:25] <CIA-38> ffmpeg: with each step, but 400 was generally much worse. [20:07:26] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:10:51] <Dark_Shikari> mru: response to my comment about label names? [20:11:18] <kshishkov> Dark_Shikari: 1-9 are ideal for label names [20:11:32] <mru> Dark_Shikari: I'm don't know what to call them [20:11:50] <mru> you don't label lines in C code, do you? [20:12:07] <kshishkov> maybe he rewrites x264 in Basic [20:13:29] <_av500_> mru: h_loop, v_loop [20:13:34] <_av500_> no? [20:13:59] <mru> Dark_Shikari: are you talking about the coeff decode or all the functions? [20:17:36] <DonDiego> and the best troll ever award goes to... [20:17:40] <DonDiego> *drumroll* [20:17:55] <DonDiego> Microsoft for publishing a H.264 playback Chrome extension: [20:17:58] <DonDiego> http://blogs.msdn.com/b/interoperability/archive/2011/02/01/greater-interop… [20:18:06] <mru> yeah, read about that [20:18:19] <Zor> that was sort of hilarious [20:18:33] <DonDiego> indeed :) [20:18:41] <mru> it's nice to see them accepting defeat on vc1 [20:19:03] <mru> h264 won, and they're not trying to deny it [20:19:40] <Dark_Shikari> lool [20:19:48] <_av500_> and they acknoledge that browser and codec are orthogonal [20:19:49] <Dark_Shikari> mru: coeff decode [20:21:45] <kshishkov> mru: well, I've looked through your patches - they look good and I believe they work correctly too. It's just a bit strange to me to see d0[1] instead of s1 but that's not even a nitpick [20:22:14] <mru> vld1 doesn't work on s regs [20:22:27] <kshishkov> ah [20:23:08] <mru> btw, speed tip: loading all elements {d0[]} is faster than loading only one {d0[0]} [20:23:26] <mru> so if you don't care about clobbering the whole reg, use the former form [20:24:16] <mru> that's because the single-element load has to do a read-modify-write on the register [20:24:35] <Zor> >H.264 isn't an open standard and isn't supported by Firefox or Opera, so in what way is this in support of interoperability? Commercial interests absolutely, but interoperability certainly not. You should be ashamed of yourselves. [20:24:37] <Zor> herp derp [20:24:53] <Zor> (comment in the above blog post) [20:25:20] <elenril> why h.264? [20:25:24] <kshishkov> Zor: they have H.264 plugin for Firefox as well [20:25:29] <elenril> why not a general dshow plugin [20:25:37] <elenril> (or whatever they're calling it these days) [20:25:54] <J_Darnley> elenril: That wouldn't be in the HTML5 spirit [20:26:28] <elenril> because it would be actually useful and not completely braindead? [20:26:42] <elenril> makes sense i guess [20:26:43] <J_Darnley> Sounds like what I said [20:27:23] <elenril> which reminds me that i wanted to drop the second _ from map_meta_data [20:27:31] <J_Darnley> PLEASE! [20:27:43] <mru> elenril: send a patch [20:27:52] <elenril> J_Darnley: why didn't you write a patch? [20:28:11] <Zor> the HTML standardization process has always been pretty dumb [20:28:12] <J_Darnley> Because I made the suggestion before I wrote any code [20:28:32] <J_Darnley> And then I saw the inertia any change like that would have [20:36:46] <Dark_Shikari> hahahahahhahahahahahahaha. [20:36:48] <Dark_Shikari> Hacker news thread [20:36:54] <Dark_Shikari> Headline: reddit has 1 billion monthly page views [20:36:59] <Dark_Shikari> Comment A: what does that translate to in ad revenues? [20:37:02] <Dark_Shikari> Comment B: About $3.50. [20:38:46] <kshishkov> well, $3.50 income sounds like doubling its value [20:41:43] <ruggles> weird. issue 2581 did not show up in the roundup mailing list when first submitted by the user. possibly because it didn't have a message, just an attached text file. [20:47:48] <ruggles> mru: regarding loading all elements vs. one element, that's possibly why iirfilter is slower when saving coefficients to xmm registers before the loop. movss clears upper bits when moving from memory but leaves them unmodified when moving xmm-to-xmm. [20:49:14] <elenril> J_Darnley: see - wasn't that hard [20:52:01] <kierank_> j-b [20:52:03] <kierank_> http://news.ycombinator.com/item?id=2171212 [20:53:25] <mru> j-b: your website is down [20:55:11] <kierank_> mru: works4me [20:55:20] <mru> yeah, now it loads [20:55:27] <mru> must've been a glitch [20:55:43] <elenril> ffdshow uses x264? [20:56:08] * elenril thought it was decoders only [20:57:58] <kierank_> elenril: maybe as a directshow encoder [20:57:58] <kierank_> dunno [21:14:17] <{V}> elenril, apparently "x264 encoder re-added and updated." http://ffdshow-tryout.sourceforge.net/wiki/old_changelogs#beta_2 [21:18:07] <_av500_> j-b: btw, what happened to these laptops? [21:29:26] <KSHawkEye> Hey, I'm trying to cross compile FFmpeg for windows 32 and 64 bit with mingw-w64. I'm configuring it with "../source/configure --prefix=/home/kyle/software/ffmpeg/ffmpeg --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-runtime-cpudetect --enable-memalign-hack --arch=i686 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-" and I get this make error: http://pastebin.com/Ta20mB4d Anyone have any ideas? [21:30:05] <jannau> KSHawkEye: #ffmpeg [22:05:07] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r4868bebe5b ffmpeg/ (doc/APIchanges libavformat/version.h libavutil/avutil.h): [22:05:07] <CIA-38> ffmpeg: Add forgotten minor API bumps and APIChanges entries [22:05:07] <CIA-38> ffmpeg: The bumps are for adding version.h and avio_{get/put}_str functions in [22:05:07] <CIA-38> ffmpeg: lavf and making av_dlog public in lavu. [22:05:07] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [22:05:17] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r87e4d9b252 ffmpeg/ (doc/ffmpeg.texi ffmpeg.c): [22:05:17] <CIA-38> ffmpeg: ffmpeg.c: rename map_meta_data option to map_metadata [22:05:17] <CIA-38> ffmpeg: It's consistent with the -metadata option and easier to write. [22:05:17] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [22:08:34] <DonDiego> saste: i just reviewed three of your docs patches (crc/framecrc/image2), do you have more pending? [22:10:26] <jannau> DonDiego: image2 is already committed [22:10:46] <DonDiego> so? :) [22:11:27] <mru> a little extra review can't hurt it [22:12:27] <DonDiego> i'm trying to teach some (technical) writing in the process, so i sure hope it's useful [22:13:40] <jannau> it was just a reaction to the "pending", more review is of course good [22:13:55] * _av500_ thinks in 2011 ff api docs should be utube videos [22:14:05] <_av500_> more audience [22:14:48] <superdump> audience? [22:15:35] <_av500_> well, most tech blogs have stopped writing, its all utub vids [22:15:56] <_av500_> superdump: /me thinks in 2011 ff api docs should be utube videos [22:16:03] <_av500_> in case you missed that [22:16:17] <mru> _av500_: http://www.youtube.com/watch?v=iIalNEW-LQ8 [22:16:20] <mru> they are :) [22:16:35] <_av500_> thats the blonde? [22:16:40] <mru> ack [22:16:43] <mru> what else? [22:17:18] <kierank> _av500_: i approve [22:17:20] <_av500_> so, we enact api example at fosdem? [22:17:41] <mru> do you bring girls? [22:17:53] <_av500_> we will only encode girls? [22:18:15] <mru> any good video needs at least one girl [22:18:44] <_av500_> btw, DonDiego what about yv? [22:56:52] <lu_zero> mru: pong [22:56:58] * lu_zero is just back [22:57:21] <mru> lu_zero: care to comment on anssi's swscale patch? [22:57:32] <mru> http://patches.ffmpeg.org/patch/764/ [22:58:24] <lu_zero> I read it [22:58:55] <lu_zero> I was about to when I got caught and translated outside ^^; [22:59:32] <lu_zero> it might break my changes a little [22:59:45] <lu_zero> but nothing that big I think [23:18:26] <DonDiego> gnite [23:27:33] <j-b> av500: these? [23:28:42] <_av500_> these? [23:29:07] <_av500_> ah, the hp ones with exploding speakers [23:29:45] <j-b> av500: nah

1 0

IRC log for 2011-02-01
by irc＠mansr.com 02 Feb '11

02 Feb '11

[00:10:58] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * ra0f9c8ce37 ffmpeg/Makefile: [00:10:58] <CIA-38> ffmpeg: Auto-generate dependencies for documentation [00:10:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:51:25] <Dark_Shikari> BBB: bench my patch please [01:02:18] <BBB> Dark_Shikari: ok [01:07:26] <Dark_Shikari> So, interesting [01:07:33] <Dark_Shikari> nVidia wants to get nvcuenc into ffmpeg [01:07:35] <Dark_Shikari> their cuda encoder [01:07:51] <mru> info ffmpeg? [01:07:52] <mru> makes no sense [01:07:59] <Dark_Shikari> So ffmpeg can call it [01:08:06] <Dark_Shikari> currently there is no open solution for using their encoder on linux [01:08:16] <Dark_Shikari> This would be the first case of committed code in ffmpeg calling a PROPRIETARY dll. [01:08:17] <mru> call as external lib, sure [01:08:20] <Dark_Shikari> Yes, that's the idea. [01:08:27] <mru> that I don't mind [01:08:35] <mru> and what about vdpau? [01:08:42] <mru> isn't that proprietary? [01:08:42] <kierank> dxva as well [01:08:48] <mru> and that [01:08:53] <Dark_Shikari> they're system libs, so the (l)gpl treats them differently [01:08:56] <Dark_Shikari> you can call them from gpl code too [01:09:09] <mru> spare me this discussion [01:09:13] <Dark_Shikari> here's the question [01:09:20] <Dark_Shikari> is it possible to compile ffmpeg with libx264 and nvcuenc? [01:09:30] <Dark_Shikari> x264 is GPL, GPL prohibits linking to proprietary code. [01:09:38] <Dark_Shikari> LGPL would seem fine. [01:09:44] <mru> x264 is not linked to proprietary in that case [01:09:50] <Dark_Shikari> Of course this would be terribly annoying if it _was_ a problem. [01:09:54] <mru> ffmpeg links to A and B [01:10:02] <mru> does not imply A links to B or vice versa [01:10:21] <Dark_Shikari> ffmpeg linking to x264 means ffmpeg has to be GPL. [01:10:24] <Dark_Shikari> i.e. --enable-gpl [01:10:31] <Dark_Shikari> that means a GPL ffmpeg is linking to B (nvcuenc) [01:10:54] <mru> if ffmpeg chooses to link to something proprietary it bloody well just gave itself permission to do that [01:11:12] <Dark_Shikari> I'm confused. [01:11:15] <mru> and what defines a "system lib"? [01:11:42] * Dark_Shikari goes to check with people who know more. [01:11:59] * mru hates such legal wrangling [01:12:07] <mru> it's not better than the mpaa [01:12:12] * Dark_Shikari does too, so I'd like to know if there's an issue before we start. [01:15:17] <mru> I can assure that some freetard will kick up a fuss [01:21:04] <BBB> Dark_Shikari: done, let me finish feeding baby and i will pastebin it [01:21:09] <Dark_Shikari> k [01:21:28] <BBB> its 3 cycles faster or so [01:21:39] <Dark_Shikari> 3?!?! [01:21:42] <Dark_Shikari> It was about 30 here [01:21:55] <BBB> 30 dezicycles [01:21:59] <BBB> 3 cycles [01:22:03] <BBB> ? [01:22:14] <mru> isn't it time we fixed that misspelling btw? [01:22:20] <BBB> :-p [01:22:31] <BBB> nah, its fun [01:23:03] <Dark_Shikari> lol [01:23:37] <Jumpyshoes> dezicycles confused me for a while [01:23:42] <j0sh> wbs: nice, you have an attribution in downey's Little Book of Semaphores [01:24:05] <mru> what book is that? [01:24:32] <j0sh> it's a ebook on synchronization [01:24:54] <mru> I figured it wasn't railroad signals [01:24:54] <j0sh> http://greenteapress.com/semaphores/downey08semaphores.pdf [01:28:52] <kierank> j0sh: it's no knuth cheque ;) [01:29:02] <j0sh> heh yeah [01:29:30] <kierank> I knew someone with one of thoise [01:30:06] <kierank> naturally he worked in such a messy office he didn't actually know where it was [01:30:28] <mru> how do you know he was telling the truth? [01:30:55] <BBB> Dark_Shikari: http://pastebin.com/3vT10uJh after and before, 4 cycles difference [01:31:13] <Dark_Shikari> BBB: heh, not worth the mess [01:31:29] <BBB> you saw 300 dezicycles difference btw? [01:31:34] <Dark_Shikari> Might have been wrong. [01:31:36] <kierank> mru: he'd shown it to people before [01:31:36] <BBB> or really just 30? [01:31:43] <BBB> must've been 30, or a shitty compiler :-p [01:35:38] <BBB> oh, emu_edge is OK'ed [01:35:40] <BBB> let me commit that [01:35:46] <BBB> that's a massively big patch off my list :-p [01:43:01] <Dark_Shikari> BBB: that seems weird. just 400 cycles for an entire MB's MC? [01:43:08] <Dark_Shikari> what test sample are you using? [01:43:15] <BBB> elephant's dream [01:43:23] <Dark_Shikari> oh, something covered in 0,0 mvs [01:43:25] <BBB> there's a lot of skips also [01:43:26] <Dark_Shikari> try something with a bit more action [01:43:32] <BBB> sintel? [01:43:42] <Dark_Shikari> Just a short clip like parkjoy [01:45:47] <Dark_Shikari> something with motion all th etime [01:46:19] <Dark_Shikari> http://x264.nl/developers/Dark_Shikari/website/compare/vp8.mkv [01:46:50] <BBB> great, dl'ing [01:47:11] * BBB runs make fate once more [01:50:55] <BBB> why is it that people post complete iphone applications to libav-user, expecting us to find their bug and make them rich? [01:51:21] <mru> iphone is the new php [01:51:40] <BBB> every idiot thinks he can do it? [01:51:58] <mru> every idiot comes asking how to use ffmpeg with it [01:52:21] <mru> a few years ago, they were all asking how to convert $video to flv from php [01:55:36] <Kovensky> mru: once in a while people appear if ffmpeg requires php because everything they find about it is how to use it from php [01:57:48] <BBB> git push origin emu_edge:master pushes my branch back to ffmpeg.git, right? [01:58:00] <BBB> I don't want to screw up more [01:58:07] <mru> if you're unsure, don't do it [01:58:22] <BBB> what do I do else? [01:58:34] <mru> git rebase master emu_edge [01:58:36] <mru> git checkout master [01:58:42] <mru> git merge --ff-only emu_edge [01:58:44] <mru> git push [01:59:05] <mru> how much is on that branch? [01:59:36] <BBB> just this one patch [01:59:50] <BBB> I have one branch per "project", and generally a "project" is just a single patch [02:01:11] <lu_zero> good morning [02:01:15] * lu_zero just woke up [02:02:07] <BBB> done [02:02:08] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r81f2a3f4ff ffmpeg/libavcodec/x86/ (dsputil_mmx.c dsputil_yasm.asm): [02:02:08] <CIA-38> ffmpeg: Implement a SIMD version of emulated_edge_mc() for x86. [02:02:08] <CIA-38> ffmpeg: From ~550 cycles (C version) to 170 (SSE/x86-64), 206 (MMX/x86-32) [02:02:08] <CIA-38> ffmpeg: and 196 (SSE2/x86-32) cycles. [02:02:21] <Dark_Shikari> \o/ [02:02:24] <mru> looks like it worked [02:02:39] <Dark_Shikari> BBB: bench on vp8.mkv? [02:02:44] <BBB> yep [02:02:45] * mru meanwhile tries to coerce qnx into running fate [02:02:47] <BBB> coming [02:04:48] <Kovensky> 22:58.42 mru: git merge --ff-only emu_edge <-- can't have merge commits either? [02:09:24] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/K28fVzG8 28 cycles faster [02:10:03] <BBB> Kovensky: I'm affraid to mess up [02:10:05] <BBB> trying to learn slowly [02:10:11] <Dark_Shikari> BBB: toldyaso [02:10:16] <BBB> nice [02:10:19] <Dark_Shikari> Now, I still don't know if it's worth it [02:10:23] <Dark_Shikari> It's uuugly [02:10:32] <BBB> do something about it [02:11:17] <BBB> 28 cycles per run for something that runs a lot, regardless of which file [02:11:49] <BBB> basically inter_predict() becomes 1.5-2.0% faster [02:11:54] <BBB> as a whole [02:11:57] <BBB> that's not bad [02:12:50] <Dark_Shikari> It's not really ugly, moreso duplicated code. [02:14:44] * BBB goes review fmtconvert code [02:15:05] <BBB> Dark_Shikari: I'm fine with the patch basically, I don't care duplicated code all too much as long as it's right next to each other [02:15:15] <BBB> not the best approach, but if it's faster... [02:16:46] <Dark_Shikari> any chance you could get an overall bench while reviewing? [02:16:52] <Dark_Shikari> (after removing timers ofc) [02:16:58] <Dark_Shikari> Not sure if it affects overall enough to measure on your system or not [02:17:01] <Dark_Shikari> as I don't know what your stddev is like [02:17:35] <Kovensky> 23:10.04 BBB: Kovensky: I'm affraid to mess up <-- nah, it's a git thing [02:17:35] <Kovensky> if you use --ff-only, then git doesn't make a commit saying "merge branch <branchname>" afterwards [02:17:38] <Kovensky> OTOH, if you use --no-ff, then git will always make that commit, even the branch you're merging branched from the current HEAD [02:19:56] <mru> if you say --ff-only git will refuse to make a merge commit [02:20:06] <mru> the default is to make a merge commit if the merge is non-ff [02:20:13] <BBB> Dark_Shikari: ok will try [02:25:52] <Kovensky> mru: what I said, but more concise and with better jargon ._. [02:28:39] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/PCXYdznc 0.55% faster [02:28:43] <BBB> Dark_Shikari: that's pretty significant [02:31:08] <Dark_Shikari> Not bad. [02:31:23] * BBB slaps Dark_Shikari [02:31:46] <Dark_Shikari> ? [02:32:15] <BBB> not bad is what dutch farmers say when they don't want to say something is pretty darn good, but they do want to say something [02:32:17] <BBB> you're not a farmer [02:32:42] <BBB> n/m, it's a bad joke [02:33:56] <Dark_Shikari> I farm optimizations [02:34:12] <BBB> go harvest [02:34:57] <BBB> time for ffmpeg-mt again [02:45:17] <Dark_Shikari> I'll send a patch in a bit [03:03:22] <lu_zero> that would be a nice catchphrase on a t-shirt [03:08:56] <Dark_Shikari> Message-ID to be used as In-Reply-To for the first email? [03:09:00] <Dark_Shikari> wtf does that mean in git send-email? [03:09:37] <mru> if you put a message ID there the patch will be sent as a reply to that one [03:09:46] <Dark_Shikari> and if there is none, I just hit enter? [03:09:51] <lu_zero> yup [04:47:32] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r64233e702a ffmpeg/libavcodec/vp8.c: [04:47:32] <CIA-38> ffmpeg: VP8: merge chroma MC calls [04:47:32] <CIA-38> ffmpeg: Adds some duplicated code, but avoids duplicate edge checks and similar. [04:47:32] <CIA-38> ffmpeg: ~0.5% faster overall on Parkjoy test sample. [07:28:23] <KotH> salut [07:28:29] <kshishkov> shalom [07:30:06] <pJok> konbanwa [07:30:12] <pJok> or [07:30:22] <pJok> ohayou gozaimasu rather [07:30:27] <wooster> prevet [07:31:40] <pross-au> hmmm [07:32:10] <kshishkov> nudge-nudge, Bink-Bink, mate! [07:33:14] * kierank sees what kshishkov did there [07:33:50] <pross-au> where did u learn to be so subtle [07:34:26] * kshishkov is subtle as 'roo kick [07:41:23] * elenril kicks kshishkov [07:41:44] <elenril> you've finished not working on wavpack multichannel, now you have no excuse! [07:41:53] <_av500_> unless elenril is built like a roo, kshishkov shrugs [07:41:59] <thresh> _av500_: awesome [07:43:32] <kshishkov> elenril: Xan4 [07:44:37] * elenril never heard about it [07:49:01] <kshishkov> your problem, but it's the codec Mike couldn't RE [07:49:51] <elenril> resident evil? [07:51:04] <kshishkov> Wing Commander IV [07:55:04] <wbs> j0sh: yeah - had to "send a patch" ;P it's kinda annoying when there's bugs in a book like that, when you start pulling your hair off when you don't understand how a tricky problem is supposed to work, and then realize it's a bug in the text ;P [07:59:33] <wbs> and re the discussion on people posting iphone apps - the android-ndk list is full of people asking how to compile ffmpeg [08:00:35] <wbs> and attribute the problem to ffmpeg when they're actually screwing up in something else, keeping eternally long threads all with ffmpeg in the subject line [08:01:37] <cartman> moin [08:09:54] <j0sh> wbs: yeah, textbooks can have a lot of errata. i found a couple in my dragon book (compilers) but they were already reported by then :) [08:10:25] <wbs> j0sh: ah.. too bad with normal books that you can't get the errata applied automatically before you read :-) [08:10:42] <j0sh> would be nice to git-pull the latex :) [08:10:47] <wbs> yeah :-) [08:32:41] <Flameeyes> somebody (elenril?) has the pkg-config version of when the new metadata interface was introduced in libavformat, by chance? [08:35:53] * elenril has nfi what pkg-config version is [08:37:34] <cartman> elenril: version in the *.pc files [08:37:36] <benoit-> moin [08:38:27] <Flameeyes> elenril: usually I'd _expect_ the library version reported by the .pc files to be bumped when a new interface gets added so I can test for it :) [08:38:30] <benoit-> does anyone know where I can get the right version of libcrystalhd? I wanted to give a shot to Philip Langdale patch (compile it, at least). [08:38:42] <cartman> benoit-: ask merbanan [08:38:47] <elenril> isn't that just so version? [08:39:00] <Flameeyes> elenril: depends what so version you're referring to :P [08:39:04] <kshishkov> bonjour, benoit- [08:39:19] <benoit-> kshishkov: dobroe utro (or something like that :)) [08:39:26] <Flameeyes> elenril: http://blog.flameeyes.eu/2009/10/27/a-shared-library-by-any-other-name :P [08:39:30] <elenril> Flameeyes: this is all arcane black magic for me ;) [08:40:12] <benoit-> cartman: I'll see with merbanan when he's here then... Or I'll email Philip to ask. [08:40:26] <elenril> anyway, isn't the very first entry in doc/APIChanges what you're looking for? [08:41:48] <Flameeyes> uhm let me check.. I looked last night and was mostly asleep... [08:41:50] <kshishkov> Flameeyes: BTW, isn't that what we all like Gnome for - loads and loads of unneeded libraries [08:42:04] <cartman> fact of life [08:42:32] <Flameeyes> kshishkov: uhm I'd rather have that than kde's monolithic packaging that is able to get out of sync with itself [08:42:36] <Flameeyes> [kdepim, anyone?] [08:42:43] <cartman> kdepimp [08:42:52] <Flameeyes> cartman: kdefuckup, let's be honest [08:43:06] <cartman> yeah well they need better release management [08:43:51] <kshishkov> Flameeyes: well, since KDE starts crapload of daemons/services/whatever even for single app, I'm not considering it sane [08:43:52] <Flameeyes> cartman: they should have listened to us back in the kde3 days [08:44:11] <cartman> Flameeyes: yeah same thing happening over and over but, what did you guys suggested back then? [08:44:14] <Flameeyes> kshishkov: find me something sane that is actually living in the 21st century and not in the '70s... [08:44:27] <Flameeyes> elenril++ yes that was what I was looking for.. but the first from the _bottom_ :P [08:44:49] <elenril> well yeah, i meant the very first chronologically :) [08:45:21] <Flameeyes> I was looking at the top, and that was other metadata APIs :P [08:45:49] <kshishkov> Flameeyes: that may mean that 70s were sane unlike 2000s - just think when UNIX was created and when Haiku [08:46:22] <Flameeyes> kshishkov: I have definitions of "sane" that goes above and beyond being minimal, tbh [08:46:43] <Tjoppen> Flameeyes: don't use dark grey text on a light gray background [08:47:26] <Tjoppen> (just inserting my pet peeve regarding blogs) [08:48:01] <Flameeyes> Tjoppen: sorry â I'm not really a designer, that's a theme I found and that I liked the structure of :P I always tell myself to actually hire somebody to do a design for me, but never have the time or the money to do that [08:50:15] <Tjoppen> it's just a minor eyestrain issue. a little more contrast would be better [08:50:27] <j0sh> benoit-: possibly https://groups.google.com/group/crystalhd-development?pli=1 [08:50:33] <Dark_Shikari> http://www.exploringbinary.com/java-hangs-when-converting-2-225073858507201… [08:50:36] <Dark_Shikari> ohgod not again [08:52:24] <Flameeyes> Tjoppen: uhm actually it isn't that bad indeed... will probably make an update later since I wanted to fix another issue with the theme [08:54:37] <Tjoppen> nice [08:54:48] <Tjoppen> making the text darker should suffice [08:55:36] <Tjoppen> also: interesting post on the ld stuff [08:55:56] <Tjoppen> it's sort of the mental model I had inferred already [08:56:23] <Flameeyes> thanks! â it's the kind of black magic that libtool hides "too well" :| [09:24:29] <benoit-> j0sh: well, found it eventually. If anyone's interested, seems to be git://git.wilsonet.com/crystalhd.git/ [09:41:53] <lyakh> yeah... ok, spent a couple of days, put a large part of apply_window_mp3_c, including the loop, in a separate .S file - gained a whole extra 5%....... [09:43:11] <spaam> http://blog.whiletrue.com/2011/01/what-if-visual-studio-had-achievements/ [09:45:35] <cartman> lol [09:46:00] <cartman> The Portal â Created a circular project dependency [10:54:08] <lu_zero> wbs: ever used rtpplay and such? [10:55:48] <wbs> lu_zero: yes, a few times [11:09:49] <lu_zero> wbs: mind teaching me how to use it? [11:10:05] <lu_zero> since apparently I'm missing a thing or two [11:13:54] <merbzt> where can I find an avc intra sample file ? [11:14:08] <Dark_Shikari> make one with x264? [11:14:22] <av500> where can I find an avc intra command line for x264 [11:15:01] <Dark_Shikari> though I don't think x264 is quite compliant with every single absurd restriction [11:15:21] <{V}> av500, man x264 ? [11:15:26] <Dark_Shikari> commit b20059aa has an example commandline [11:26:58] <gfto> I see more than 20 warnings about functions which parameters are declared const but are called without const var - http://ffmpeg.pastebin.com/7K42HgEq any idea what to do with them, I have some spare time and would like to clean the warnings [11:27:24] <Dark_Shikari> patches welcome [11:27:26] <Dark_Shikari> --> #ffmpeg-devel [11:28:00] * av500 thought this was #ffmpeg-devel [11:29:36] <gfto> Dark_Shikari: suer :) I was asking on what to do, remove const declaration in function prototypes or add casts (which sounds incorrect) [11:30:42] <kshishkov> add qualifiers [11:30:46] <Dark_Shikari> oh wait [11:30:47] <cartman> gfto: casting sounds wrong [11:30:49] <Dark_Shikari> this is #ffmpeg-devel. [11:30:51] <Dark_Shikari> Damnit. [11:31:15] <kshishkov> Dark_Shikari: no problems unless you were going to discuss your crazy games [11:31:35] <Dark_Shikari> I thought it was #ffmpeg. [11:31:37] <Dark_Shikari> 'cause I'm blind. [11:36:40] <jannau> gfto: at least some of them can't be avoided [11:36:46] <gfto> umm, casts definately don't work in this case. http://ffmpeg.pastebin.com/wdkN4LEJ [11:37:11] <gfto> jannau: can we make gcc shut up about them, most of them are just rubish [11:38:01] <jannau> I think not without silencing useful warnings [11:39:06] <gfto> it seems that there is -Wcast-qual but not -Wno-cast-qual [11:40:54] <jannau> merbzt: "Bitstreams for Professional Profiles" from http://www.itu.int/net/ITU-T/sigdb/spevideo/VideoForm-s.aspx?val=102002641 [11:42:03] <Dark_Shikari> AVC Intra != High 10 Intra [11:42:08] <Dark_Shikari> AVC Intra is not an ITU spec [11:46:28] * jannau should read more carefully [11:46:51] <jannau> but it's just a plot to get Dark_Shikari to review the h264 profiles patch [11:47:10] <jannau> justjust pinged [11:55:01] <wbs> lu_zero: in my case, I've most often exported data from wireshark, by choosing "save as" in some of the RTP dialogs... I usually run e.g. rtpplay -f <file.rtpdump> 224.0.0.42/1234, and try to play it back with e.g. ffplay rtp://224.0.0.42:1234 [11:55:21] <wbs> lu_zero: some files need -T added to rtpplay to get it played back in a sensible speed [12:05:47] <lu_zero> so it works only for multicast [12:06:10] <lu_zero> I was trying to get it just send to localhost:port [12:06:10] <wbs> no, you can send to 127.0.0.1/1234 as well [12:06:18] <wbs> should work just as well [12:06:23] <lu_zero> it complained a lot [12:06:58] <wbs> ah, yeah, it complains if noone is listening on that port at the time [12:07:15] <wbs> that's one of the advantages of sending over multicast [12:08:19] <lu_zero> and obviously I'm messing up wrongly with the sdp I'm feeding ffmpeg with, possibly [12:08:58] <wbs> probably [12:09:42] <wbs> if you're testing mpeg2ts stuff, using the rtp:// url directly probably is easier [12:10:55] <lu_zero> ok ^^; [12:14:29] <mru> wtf @ const discussion [12:14:43] <mru> passing non-const pointer to const-qualified function argument is perfectly fine [12:14:52] <mru> it just means the function promises not to modify [12:15:03] <mru> the other way around is wrong [12:15:13] <Dark_Shikari> then why does gcc warn? [12:15:17] <Dark_Shikari> is this a case of the C standard being really dumb? [12:15:27] <mru> I've never seen such a warning [12:15:43] <Dark_Shikari> I'd guess it's new to gcc 4.6 [12:15:44] <Dark_Shikari> or similar [12:15:49] <mru> it's stupid [12:15:54] <mru> it's nothing to warn about [12:16:07] <mru> he _could_ be talking about multi-level pointers [12:16:18] <mru> there the C spec is a bit stupid [12:16:38] <wbs> the warnings he put on pastebin were multi-level pointers, yes [12:17:06] <mru> some of those can be fixed by adding more const [12:17:14] * superdump wonders what you're talking about [12:19:27] <DonDiego> gfto: the correct way to fix such warnings is usually to *add* const in the right places [12:19:47] <mru> removing const is never a correct fix [12:20:38] <gfto> I have removed const from declarations in couple of places in imgutils and the resulting object code is exactly the same [12:20:47] <Dark_Shikari> const is a tool for the programmer [12:20:47] <mru> that's not the point [12:20:49] <Dark_Shikari> not a tool for the compiler [12:20:55] <mru> Dark_Shikari: both actually [12:20:59] <Dark_Shikari> well yes, but moreso the former. [12:21:10] <DonDiego> gfto: removing const means removing safeguards against mistakes... [12:21:24] <mru> const-qualified data can be safely cached across function calls, for instance [12:21:31] <gfto> I understand the maning, this is not changed in this function but the compiler seems to be too anal [12:22:02] <Dark_Shikari> anal? sounds like gcc [12:22:22] <DonDiego> whatever, your fix is wrong, removing const qualifiers does not improve the code [12:22:24] <mru> no, gcc is actually correct in this case [12:22:31] <mru> the C spec is stupid [12:22:56] <mru> the C spec doesn't allow implicitly adding const to one level of a multi-level pointer without adding it to all [12:23:22] <gfto> that seems the problem with many of these places in the code [12:23:28] <mru> in some cases the fix for the warning is as simple as changing "const int *foo" to "const int *const foo" [12:23:40] <Dark_Shikari> if const doesn't solve the problem, you're not using enough [12:24:28] <gfto> heh "const int *const foo", lets try that for uint8_t **blah :) [12:24:29] <mru> btw, we now have qnx on fate too, should anyone care [12:24:45] <mru> s/int/whatever/ [12:24:58] <wbs> \o/ [12:25:06] <superdump> const uint8_t *const *const blah? [12:25:29] <mru> yes [12:25:39] <mru> the last const isn't usually needed [12:25:48] <mru> that's just for the pointer value itself [12:26:00] * mru forgot a * in his example [12:39:43] <lu_zero> wbs: complains the same way =| [12:40:57] <wbs> lu_zero: hmm, that's weird [12:41:16] <wbs> lu_zero: sure you listen on 127.0.0.1 and not localhost (which probably resolves to ::1)? [12:47:52] <lu_zero> ffplay rtp://127.0.0.1:1234 [12:48:09] <lu_zero> rtpplay -v -f /tmp/dump.rtp 127.0.0.1/1234 [12:50:09] <wbs> ah, yes, rtp://127.0.0.1:1234?localport=1234 [12:50:47] <lu_zero> ^^; [12:50:50] <lu_zero> thank you =) [12:51:19] <lu_zero> uhm [12:51:21] <lu_zero> ffplay rtp://127.0.0.1:1234?localport=1234 [12:51:31] <lu_zero> rtpplay -v -f /tmp/dump.rtp --help 224.0.0.42/1234 [12:51:34] <lu_zero> ... [12:51:54] <lu_zero> wrong buffer [12:51:56] <lu_zero> rtpplay -v -f /tmp/dump.rtp 127.0.0.1/1234 [12:52:11] <lu_zero> still complains the same way [12:52:31] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rf3619680a7 ffmpeg/Makefile: [12:52:31] <CIA-38> ffmpeg: Makefile: remove unused variable ALLHTMLPAGES [12:52:31] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:52:36] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r7f939f55bb ffmpeg/Makefile: [12:52:36] <CIA-38> ffmpeg: Makefile: build docs only for enabled tools; fix docs dependencies [12:52:36] <CIA-38> ffmpeg: This makes "make documentation" build the man/html pages only for [12:52:36] <CIA-38> ffmpeg: the tools enabled in the build. It also fixes the dependency [12:52:37] <CIA-38> ffmpeg: tracking for the built man pages. [12:52:37] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:52:38] <CIA-38> ffmpeg: Gianluigi Tiesi <mplayer(a)netfarm.it> master * re86e858111 ffmpeg/libavcodec/dca.c: [12:52:38] <CIA-38> ffmpeg: dca: avoid C99 declaration in for() expression [12:52:39] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:52:56] <wbs> lu_zero: ok, that's weird then, that works flawlessly for me [12:56:11] <Kovensky> 09:52.38 CIA-38: ffmpeg: dca: avoid C99 declaration in for() expression <-- why is this? isn't ffmpeg C99 to begin with? [12:56:35] <elenril> no [12:56:45] <elenril> only some selected features [12:57:06] <Dark_Shikari> it's stupid, IMO [12:57:11] <Dark_Shikari> c99 for loop declarations avoid tons of bugs [12:57:12] <Dark_Shikari> and are cleaner [12:57:20] <Dark_Shikari> even if you don't like declaration after statement, they're still cleaner [12:57:20] <mru> I agree with that [12:57:28] <mru> but some silly compilers still don't support them [12:57:35] <Dark_Shikari> Can't we stop caring about them? [12:57:37] <Dark_Shikari> We don't support MSVC [12:57:42] <Dark_Shikari> why support some other shitty C89 compiler? [12:58:11] <mru> what if that's the only one that exists for a certain target? [12:58:17] <Dark_Shikari> which one is this? [12:58:27] <kshishkov> some shitty Atmel chip for example [12:58:32] <mru> I've run into the same problem with TI DSP compilers [12:59:16] <Dark_Shikari> You could write a preprocessing script to turn C99 int-- *shot* [12:59:48] <lu_zero> wbs: willing to give a try? [13:00:12] <wbs> lu_zero: on the mpegts stuff, or on getting rtpplay to work for you? :-) [13:00:32] <lu_zero> wbs: that or give me an rtp-mpegts to try [13:00:44] <lu_zero> I'm spending too much time on this =P [13:01:07] <wbs> there's the http://albin.abo.fi/~mstorsjo/RTP_mpegts_sample.{cap,rtpdump} that I think I sent you last week [13:01:20] <lu_zero> those are known to work? [13:01:36] <wbs> they work quite ok - some dropped packets, but generally quite ok [13:01:48] <av500> lu_zero: did you get the captures from us? [13:01:55] <Kovensky> 09:50.12 Kaze: An IPv4 address space walks into a bar: "A strong CIDR please. I'm exhausted." [13:02:30] <mru> ha ha ha [13:02:40] <wbs> I had a look at the samples that av500 gave, and the issue there seemed to be that the mpegts demuxers sets the streams into probe mode, taking an eternity to sort out... if using a normal mpegts demuxer, the demuxer read_header function would sort it all out, but that one never is called in the rtp/mpegts setup [13:04:43] <lu_zero> av500: those are making rtpplay upset ^^; [13:05:08] <lu_zero> wbs: what I'm doing is to call the normal mpegts demuxer [13:05:23] <lu_zero> just that I need to remap the streams doing so =| [13:05:34] <lu_zero> (and double check it) [13:09:45] <lu_zero> your sample does have the same problem =| [13:10:17] <wbs> well, that's weird then. check with wireshark what ip address the packets are sent to, and check with netstat which ports ffplay listens to [13:10:23] <wbs> did you test sending over multicast? [13:13:31] <lu_zero> rtpplay -v -f /tmp/RTP_mpegts_sample.rtpdump 224.0.0.42/1234 [13:13:31] <lu_zero> fread body: Bad address [13:13:31] <lu_zero> rtpplay: multimer.c:98: timer_check: Assertion `np->time.tv_usec < 1000000' failed. [13:13:34] <lu_zero> Aborted [13:17:27] <lu_zero> stranger and stranger [13:17:30] <wbs> uhm, sounds like your rtpplay is miscompiled in some way.. I think I ran into some such issue early on, but don't really remember what I did to fix it [13:18:25] <lu_zero> it does have -g -O2 as cflags so I'm not expecting such issues [13:18:52] <wbs> in my case, it might have been some issue with osx [13:23:26] <lu_zero> mpegts_read_header needs 5k [13:23:34] <lu_zero> apparently [13:31:31] <j-b> "unstable executables up to gcc 4.5" I call BS [13:32:22] <mru> j-b: stable or not, c99 has nothing to do with it [13:32:51] <j-b> the only stable way to have a computer is to turn it off [13:33:16] <j-b> not to mention that gcc 4.2 compiles c99 fine [13:33:35] <mru> of course it does [13:37:15] * kshishkov want the best compiler eternal - GCC 96.96.96 [13:38:23] <lu_zero> isn't it the 6.6.6_p9999 ? [13:39:49] <kshishkov> nope [13:40:18] <kshishkov> just compare any GCC with 6 in any version and with 96 in any version [13:40:37] <Dark_Shikari> 3.4 is still the best [13:40:48] <Dark_Shikari> `-` [13:50:20] <cartman> Dark_Shikari: share what you are smoking [13:52:04] <Dark_Shikari> it's the only version of gcc that's never miscompiled any of my code [13:52:08] <Dark_Shikari> of all those I've ever used [13:52:09] <Dark_Shikari> (well, 3.4.5) [13:52:22] <kshishkov> 3.4.5 patchlevel 6.7.8 ? [13:52:53] <av500> runing in windows 1.2.3? [13:53:29] <kierank> av500: is that what it would have been called if ibm bought microsoft? [13:53:30] <kshishkov> av500: in windows -3.-2.-1 [13:53:53] <kshishkov> kierank: it would be windows 3/2^7 [13:55:48] <pJok> OS/2 Warp 9? [13:56:07] <kshishkov> pJok: that's only for selected ships [13:56:30] * pJok does not understand the people who are still running OS/2 [13:57:06] <kshishkov> pJok: they are also playing StarCraft in it [13:57:17] <pJok> kshishkov, damn koreans... [13:57:17] <kierank> pJok: they are not people, they are ATMs [13:57:29] <pJok> kierank, if only... ;) [13:57:47] <pJok> kierank, most of the ATMs around here run some terminal edition of windows now [13:57:52] <pJok> and have been for quite some time [13:59:23] <av500> terminal edition means its the last one? [14:00:47] <kshishkov> could be [14:01:00] <kshishkov> or could be just second word missing [14:01:55] <pJok> hehe [14:08:53] <lu_zero> pff [14:08:55] <lu_zero> ok [14:23:24] <cartman> thresh: http://www.androidcentral.com/archos-5-tablet-half-amazon-today-only [14:23:29] <cartman> better than av500's discount :P [14:23:52] <av500> yes, but old tech [14:24:03] <av500> cartman: but please go buy one [14:24:14] <cartman> av500: I have 4-5 tablets already [14:24:16] <cartman> :P [14:24:24] * cartman got a new one from Marvell [14:24:48] <thresh> cartman: I'm off using held devices with hard drives :) [14:24:55] <thresh> been there done that with an ipod [14:24:57] <cartman> thresh: heheh :) [14:25:07] <cartman> <3 ipod classic [14:25:14] <thresh> i was using exactly that model [14:25:28] <thresh> and guess what? it died three days after warranty void [14:25:34] <cartman> I'm waiting for Motorola Xoom hotness [14:25:41] <cartman> thresh: mine still works 6 years and going [14:26:03] <kshishkov> thresh: that's success for manufacturer! [14:26:06] <thresh> cartman: you obviously don't bike with it :) [14:26:09] <thresh> kshishkov: indeed :) [14:26:13] <cartman> thresh: lol [14:26:30] <thresh> actually, I've fallen a numerous times on my n900 already, still alive [14:26:55] <thresh> if only it wouldnt be such a disaster OS/software wise ... [14:27:00] <cartman> http://searchengineland.com/google-bing-is-cheating-copying-our-search-resu… [14:27:04] <cartman> scroll down to examples [14:27:08] <cartman> hahah MS is busted [15:16:53] <siretart> michaelni: with the two commits regarding aspect handling in avfilter from yesterday evening, can the libavfilter API/ABI considered stable, or do you have more changes in the pipe? [15:22:58] <ubitux> is for (int i ... ) still problematic with recent mingw64 versions? [15:24:02] <saste> siretart: more changes due to audio filtering [15:24:45] <siretart> saste: ah, I see. thanks [16:06:32] <BBB> michaelni: will you review " [PATCH] Factorize code from video_thread() and put it in configure_video_filters()"? [16:07:03] <BBB> mru: did you push "[PATCH] In get_video_frame(), use frame->pkt_pts rather than the deprecated reordered_opaque API, which is deprecated for this specific use" already? [16:07:19] <BBB> I think you did, right? [16:07:22] <BBB> I see it in git log [16:07:45] <mru> if so, I did [16:18:03] <michaelni> siretart, no ABI/API changes from my side planed but as saste said from his about audio [16:18:16] <j-b> hello peopl [16:19:47] <kshishkov> where do you see them? [16:23:47] <michaelni> BBB, if it makes you happy, ill review it. But dont forget iam trying to do civil disobedience [16:53:46] <BBB> mru: can you commit "[PATCH] Log debug information in filter_samples()"? [16:54:23] <BBB> michaelni: if you don't want ot review, then don't, I'l review and apply myself [17:02:36] <michaelni> BBB, well ive already reviewed it now [17:03:13] <BBB> thank you [17:06:17] <BBB> mru: do you want to backport "Document that av_write_header sets stream time_base to a value of it chosing" from videolan git? [17:10:59] <ruggles> does x86 have a vector float log instruction? [17:12:20] * av500 guesses its called vctrfltlg [17:12:40] <thresh> av500: at office? :) [17:12:44] <mru> that doesn't look like an sse instruction [17:12:55] <av500> thresh: er, yes [17:17:53] <pengvado> ruggles: no [17:18:39] <mru> BBB: that patch wasn't approved afaics, but you had a comment that was never answered [17:20:18] <pengvado> ruggles: how much precision do you need? [17:21:54] <ruggles> 1/256 i think [17:22:05] <lyakh> hm, are patches now preferred inline? [17:22:47] <av500> not in .S files any more? :) [17:23:09] <lyakh> av500: what? patches in .S files?;) [17:23:22] <mru> lyakh: patches are preferred in any unmangled form [17:23:23] <ruggles> pengvado: i need to calculate lrintf(128.0*(25.0-log2f(x))) [17:23:31] <mru> pasting into gmail does _not_ work [17:23:34] <lyakh> mru: good, thanks [17:23:51] <lyakh> mru: it won't be the first patch I'm sending to a list, don't worry;) [17:24:48] <av500> mru: fun fact: coworker wrote an IIR filter in asm, if you shouted loud enough into the MIC, the filter would go mute forever [17:25:09] <lyakh> av500: lol [17:25:09] <pengvado> ruggles: you need 8 bits exactly, or just some limit on average error? [17:28:52] <ruggles> any estimate better than an integer will be useful. the more accuracy the better, up to 8 bits. [17:29:58] <pengvado> simd taylor series [17:30:30] <lyakh> ...hope nearly 200 lines assembly (excluding empty lines) make an enjoyable reading, even with TABs... [17:30:37] <pengvado> quadratic is enough to get average error below 1/256 [17:30:43] <mru> lyakh: tabs are forbidden [17:31:05] <lyakh> mru: I know, I commented in the patch, if it is accepted, I'll convert [17:31:15] <mru> and I have nearly 2000 lines of asm here about to go [17:31:16] <ruggles> pengvado: great. i'll look into it. [17:31:19] <kierank> why not use spaces in the first place? [17:31:51] <lu_zero> lyakh: which editor do you use? [17:32:02] <lyakh> kierank: different people have different preferences... [17:32:05] <av500> notepad.exe? [17:32:05] <lyakh> lu_zero: emacs [17:32:15] <lu_zero> sed -i -e "s:\t: :g" to remove tabs [17:32:17] <lu_zero> uhmm [17:32:31] <mru> M-x untabify [17:32:32] <lu_zero> emacs... mru could you give him the mode you use? [17:32:41] <lyakh> av500: no, mac:"Text Editor" [17:33:00] * av500 prefers joe anyway [17:33:11] * mru has seen people write code in msworks [17:33:39] <lyakh> sure, I think we all have seen such code... [17:33:47] <pengvado> ruggles: and for a C implementation, LUT works. x264 has one. [17:34:15] <pengvado> I'm not actually sure whether simd float taylor series will be faster than scalar LUT [17:34:43] * lyakh likes to look at ohloh.net when he wants to find out about developer experience of someone new in a certain community;) [17:35:23] <kierank> [17:33] mru has seen people write code in msworks --> oh god [17:35:49] * av500 has seen people "program" in excel [17:36:05] <av500> it was a brake system even [17:36:17] <kierank> hundreds of billions of dollars are managed in excel [17:36:21] <ruggles> pengvado: that does sound faster. so is the LUT based on the mantissa only? [17:36:43] <av500> kierank: ok for the $$, but pls not my car brakes :) [17:37:11] <pengvado> both taylor and lut work by separating exponent from mantissa, adding exponent to the output directly, and the approximating log2 on the limited domain of the mantissa [17:50:03] <BBB> mru: correct, I asked to use @note but nobody answered [17:50:11] <BBB> Jumpyshoes: are you interested in vp7? [17:50:25] <BBB> Jumpyshoes: and if you had to choose encoding/decoding, as a way to start learning, which would you prefer? [17:52:55] <Jumpyshoes> BBB: no objections with vp7 and i guess i would like to start with encoding [17:53:24] <mru> I would've thought decoding is easier to start with [17:54:12] <Jumpyshoes> mru: probably, but i'm more interested in encoding [17:54:33] <mru> how will you know the bitstream format without REing the decoder first? [17:55:00] <Jumpyshoes> mru: has that not been done with vp7? [17:55:10] <mru> not that I know [17:55:26] <Jumpyshoes> oh [17:55:37] <mru> nobody really cares about vp7 since it was never used in the wild [17:55:49] <Jumpyshoes> who actually uses it then? [17:55:58] <mru> on2 marketing [17:56:07] <BBB> not many people, it was more an exercise to get you to learn everything about video :-p [17:56:14] <BBB> best way to learn is to just do it yuorself [17:56:22] <mru> it might be used in some closed system somewhere [17:56:29] <BBB> are you interested in vp8 encoding? :-p (google is asking) [17:56:49] <lu_zero> BBB: =) [17:57:02] <Jumpyshoes> BBB: vp7 decoding or vp8 encoding are fine with me [17:57:20] <BBB> which do you feel is more interesting? [17:57:24] <Jumpyshoes> speaking of google i should submit my resume [17:57:28] <j-b> vp7 [17:57:34] <BBB> j-b: hey there [17:57:40] <j-b> hello BBB [17:57:47] <BBB> Jumpyshoes: j-b will give you double gci points next year if you do vp7 decoding, I guess :-p [17:57:57] <Jumpyshoes> can't do GCI next year [17:58:01] <j-b> BBB: I don't want Jumpyshoes in GCI anymore [17:58:06] <j-b> BBB: he is too good [17:58:09] <BBB> oh [17:58:12] <j-b> he destroys the concept [17:58:22] <BBB> good point [17:58:22] <j-b> he needs a GSoC [17:58:25] <Jumpyshoes> to be fair i started with 0 knowledge in the things i did [17:58:31] <j-b> and an exceptions [17:58:36] <Jumpyshoes> i also can't do gsoc <_< [17:58:43] <j-b> Jumpyshoes: take it in the best way you can [17:58:43] <av500> skype used vp7 [17:58:54] <Jumpyshoes> j-b: haha okay [17:58:56] <j-b> Jumpyshoes: well, age limitation ? [17:59:04] <Jumpyshoes> j-b: yea, i'm too young (17) [17:59:06] <j-b> Jumpyshoes: ok, so I need to do a SoV ? [17:59:19] <Jumpyshoes> j-b: SoV? [17:59:24] <j-b> Summer of VideoLAN [17:59:30] <mru> summer of violence [17:59:35] <Jumpyshoes> j-b: lol, possibly [17:59:44] <j-b> Jumpyshoes: don't lol on that [18:00:06] <j-b> I am stupid enough to do it [18:00:16] <kierank> j-b: french government paying? [18:00:23] <j-b> VideoLAN©® [18:00:32] <av500> http://forum.skype.com/index.php?showtopic=67904 [18:00:38] <av500> wrt vp7 [18:00:38] <Jumpyshoes> BBB: hrm, can i think about that for a bit? vp7 is interesting because no one has done it so i'll get to work on RE + decodng, but vp8 encoding is also interesting <_< [18:00:51] <BBB> Jumpyshoes: of course [18:00:55] <kierank> Jumpyshoes: work on a codec people actually use ;) [18:01:08] <mru> what kierank said [18:01:20] <Jumpyshoes> kierank: lol [18:01:26] <BBB> wvp2? [18:01:29] <mru> nobody really uses vp8 either, to be honest [18:01:43] <kierank> mru: yep, that's why i said that to him [18:01:50] <lu_zero> mru: I'll use it for my evil plans soon [18:01:55] <lu_zero> vp8 [18:01:59] <lu_zero> I mean ^^ [18:02:00] <kierank> Jumpyshoes: you can work on my broadcast encoder [18:02:02] <Jumpyshoes> j-b: well, if it's possible, that would be interesting [18:02:22] <jannau> mru: I guess google uses it to encode videos nobody watches [18:02:26] <mru> if Jumpyshoes is masochistic, he can add interlaced support to our vc1 decoder :) [18:02:40] <Jumpyshoes> kierank: i thought those were massive compliance stuff [18:02:40] <BBB> rv40 bidirectional prediction [18:02:41] <kierank> or write 422 h264 decoding [18:03:05] <av500> if we re vp7, we can use vp6,7 and 8 to extrapolate vp9 with quadratic curve fitting! [18:03:18] <lu_zero> av500: aaaaargh [18:03:23] <j-b> vc1 interlaced and MVC would be cool [18:03:33] <av500> Jumpyshoes: and I can host you on vp7.de!!! [18:03:50] <mru> av500: no, we need vp4 as well for quadratic [18:03:53] <Jumpyshoes> quadratic curve fitting? [18:04:10] * mru reconsiders [18:04:11] <jannau> av500: you have hopes that quadratic curve gives better results than a linear vp6,vp8 fit? [18:04:15] <av500> mru: 2 points give linear, 3 gives x^2, no? [18:04:27] <mru> av500: you're right [18:04:30] * mru can't count to 5 [18:04:41] <Jumpyshoes> av500: vp7.de? >_> [18:04:48] <av500> Jumpyshoes: yeah [18:05:11] <av500> its also my initials and 7 was the 1st free one when I registered it [18:05:26] <av500> also the only free one iirc [18:05:55] <Jumpyshoes> av500: oh, i see [18:16:40] <Kovensky> jannau: I got fate to work here btw, just not submitting [18:16:45] <Kovensky> I need to figure out how to get it to work on cron (I wrote the crontab, but my ssh private key has a passphrase) so I give my pubkey to whoever is responsible ._. [18:17:19] <mru> Kovensky: you'll need to create a key pair without password just for fate [18:18:22] <jannau> or a properly configured ssh-agent [18:18:31] <jannau> and enviroment [18:18:38] <mru> I still recommend using a dedicated key [18:18:40] <BBB> Kovensky: what os? [18:18:54] <Kovensky> osx [18:20:28] <BBB> yay [18:20:29] <jannau> yes, I thought more of a dedicated key with a passphrase [18:20:34] <BBB> mru: " [WIP] movie video source" should be committed? [18:20:53] <mru> the WIP tag suggests otherwise, unless it has been completed [18:20:57] <mru> I haven't reviewed it [18:21:34] <BBB> I think it's completed [18:21:53] <BBB> we can wait until it's applied to videolan repo [18:23:18] <mru> that makes no sense [18:23:29] <mru> if it's finished and reviewed, we should commit it [18:26:09] <Kovensky> who do I send the pubkey to [18:26:18] <av500> mru [18:26:27] <av500> aka the fatekeeper [18:26:27] <Kovensky> is IRC query okay [18:35:27] <lu_zero> BBB: could you have a look at ff_rtsp_close_streams ? [18:39:32] <lu_zero> http://ffmpeg.pastebin.com/bTyV9t0z [18:43:33] <saste> mru: the movie source is complete, I'm just waiting for the reply from michaelni after the last review [19:02:53] <kierank> With git, if I have modifications to ffmpeg vanilla and ffmpeg-mt is there any way of keeping them automatically in sync (with manual fixes if necessary)? [19:03:52] <BBB> lu_zero: patch looks correct, nice catch [19:05:48] <lu_zero> kierank: rebase the modification [19:09:42] <lu_zero> sent to the ml [19:24:28] <maxime1986> hello [19:24:38] <maxime1986> ffmpeg -i dvd.vob -itsoffset 10 -i dvd.vob -map 0.0 -map 1.1 ... [19:24:44] <maxime1986> doesn't work [19:24:50] <maxime1986> ffmpeg -i dvd.vob -itsoffset -10 -i dvd.vob -map 1.0 -map 0.1 ... [19:24:55] <maxime1986> work [19:24:58] <kierank> maxime1986 --> #ffmpeg [19:26:16] <maxime1986> kierank: I just want to know if it's a bug ... so I think a user can't be aware of this... [19:41:05] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r71e0bee9ea ffmpeg/libavcodec/h264.c: [19:41:05] <CIA-38> ffmpeg: h264: add profile names for the existing defines [19:41:05] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [19:41:16] <CIA-38> ffmpeg: Luca Barbato <lu_zero(a)gentoo.org> master * rea7f080749 ffmpeg/libavformat/rtsp.c: [19:41:17] <CIA-38> ffmpeg: Free the RTSPStreams in ff_rtsp_close_streams [19:41:17] <CIA-38> ffmpeg: This plugs a small memory leak [19:41:17] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [19:41:26] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * rfe9a3fbe42 ffmpeg/libavcodec/ (avcodec.h h264.c h264.h h264_parser.c h264_ps.c): h264: Add Intra and Constrained Baseline profiles to avctx.profile [19:42:22] <uau> Kovensky: btw did you see what i said about PKG_CONFIG_LIBDIR earlier? did you use (older) pkg-config without that or was there a reason why it didn't work for crosscompiling? [19:43:05] * Kovensky didn't know about PKG_CONFIG_LIBDIR [19:58:33] <BBB> this is retarded [19:58:41] <BBB> I used to have ffmpeg-mt failing in two parts [19:58:49] <BBB> I changed some random parts, didn't fix it [19:58:51] <BBB> try it again [19:58:55] <BBB> and now only one part fails [19:58:56] <BBB> wtf? [19:59:07] <BBB> I guess I shouldn't care, but this is pretty retarded [20:00:27] <mru> I hate vanishing bugs [20:00:36] <mru> I want to know _why_ they went away [20:08:42] <lu_zero> BBB: bisect it [20:30:23] <Kovensky> 17:00.36 mru: I want to know _why_ they went away <-- it's because you scared them away with your shotgun! [20:34:15] <spaam> Kovensky++ [20:48:54] <jannau> are defines prefixed with FF_ considered internal [21:02:14] <lu_zero> that was my understanding [21:07:53] <Kovensky> http://www.yorktownhistory.org/homepages/1900_predictions.htm [21:08:10] <saste> jannau: in that case I believe minor doesn't need to be updated [21:08:27] <kierank> Kovensky: reminds me of that at&t advert where you can send a fax on the beach [21:08:30] <saste> jannau: for being extra-safe though it's a good norm to update micro [21:08:59] <saste> jannau: so that e.g. pkg-config can track the new dependency if the symbol is used in another library (although internally) [21:11:02] <saste> jannau: also we have many FF_ symbols which are considered public at all effects [21:11:48] <jannau> saste: I've already sent patches [21:11:54] <lu_zero> yet another thing that should be addressed [21:13:32] <jannau> it doesn't make much sense to have internal symbols to describe a field in avformatcontext [21:24:26] <jannau> Dark_Shikari: I don't understand your mail [21:25:48] <BBB> neither do i [21:28:03] <kierank> _av500_: make them answer my mail on jvt-experts kthx [21:35:35] <BBB> astrange: blegh, I fixed your h264 bug [21:35:45] <BBB> astrange: ready to merge? make fate passes locally [21:38:23] <jannau> BBB: woohoo! [21:39:06] <kierank> BBB: merge mt? [21:39:15] <BBB> kierank: flying pigs [21:39:18] <BBB> see 'em? right up there [21:39:28] <kierank> awww it was worth a try [21:39:39] <kierank> also Dark_Shikari is saying High444 != High 444 Predictive [21:39:57] <kierank> there's an old lossless mode and a new one [21:41:25] <jannau> BBB: the encoding bug is the heisenbug? was it maybe a different ffmpeg base? [21:41:35] <BBB> I rebased [21:41:42] <BBB> and made local changes also [21:41:45] <BBB> not sure what fixed it [21:41:47] <elenril> lu_zero: did you do the api bump we talked about yesterday? [21:41:48] <BBB> but I can't reproduce it anymore [21:41:57] <lu_zero> elenril: waiting for you =P [21:42:03] <BBB> jannau: I'll compare trees with alex to make sure we've got everything right [21:42:15] <elenril> lu_zero: what? i thought you were going to do it =p [21:42:24] <lu_zero> same ^^; [21:42:27] <elenril> haha [21:42:42] <elenril> you have commit powers unlike me =p [21:43:07] <jannau> kierank: how do those two differ? only High 444 Predictive made it into the latest itu draft with profile_idc = 244 [21:43:36] <lu_zero> elenril: not that this changes [21:43:51] <lu_zero> if you write I'll review and commit ^^ [21:44:02] <lu_zero> if I write you'll review and I'll commit =P [21:44:15] <elenril> ok, i'll write it [21:45:04] <lu_zero> thank you =) [21:45:05] <kierank> jannau: can't actually remember the difference wrt profile_idc off the top of my head [21:45:45] <jannau> lu_zero: I smell a conspiracy to game the system :D [21:46:54] <elenril> wait, your change is lavu [21:47:01] <elenril> mine is lavf [21:47:38] <lu_zero> jannau: uh? [21:47:43] <lu_zero> yup [21:48:09] <lu_zero> that reminds me that we should discuss an item... [21:49:54] * elenril wonders what to put use instead of svn revision in doc/APIChanges [21:50:12] <mru> craft a git hash such that it matches the commit [21:50:27] <elenril> my crypto magic isn't strong enough ;) [21:50:27] <jannau> elenril: git short hash [21:50:43] <elenril> jannau: of the commit i'm about to commit? [21:50:47] <mru> there should exist a long hash with that property [21:50:52] <mru> not necessarily a short one though [21:52:17] <jannau> elenril: guess until you find one [21:52:42] <elenril> i guess this will take a while [21:53:07] <elenril> hmm, bump for lavf 52.94 isn't documented either [21:54:09] <jannau> elenril: that's the reason why I suggested to start with short ones [21:59:56] <elenril> any constructive ideas? [22:00:43] <elenril> maybe we should write parent there [22:00:46] <elenril> or tag api bumps [22:01:15] <lu_zero> elenril: only major [22:01:32] <elenril> you don't like having a gazillion tags? [22:01:51] <_av500_> kierank: your jvt question is neither in latin nor does it mention h264, so booooring [22:01:54] <jannau> elenril: $PARENT.. [22:02:15] <kierank> _av500_: yeah but it's a genuine question and they are ignoring it [22:02:25] <kierank> they seem to think everyone understands the magic hrd(tm) [22:02:42] <Jumpyshoes> hrd? [22:02:53] * elenril wonders where are all the people who wanted to merge -mt a few minutes ago [22:03:19] <kierank> Jumpyshoes: hypothetical reference decoder [22:03:30] <kierank> magic thing in h.264 [22:03:41] <elenril> should i use first person pejorative in APIChanges? [22:03:56] <_av500_> Jumpyshoes: jvt experts all wear pointy hats and fight balrogs [22:06:24] <elenril> haha, git shortlog says i have 99 commits [22:06:42] <Jumpyshoes> _av500_: oh ._. [22:08:15] <lu_zero> _av500_: claim to have fought balrogs in their young times [22:08:39] <Jumpyshoes> does anyone have a sandy bridge that they're willing to give me access to? [22:08:56] <lu_zero> why a sandy bridge? [22:09:08] <jannau> AVX [22:09:09] <lu_zero> btw the broken bridge? [22:09:23] <Jumpyshoes> lu_zero: working on avx for x264 [22:09:28] <mru> I didn't know trolls were so particular about the bridges they lived under [22:10:49] <wbs> lu_zero: in what scenario did you find the leak in rtsp? I didn't stumble upon it in normal rtsp use... with rtp/mpegts however, I get lots of leaks [22:11:06] <elenril> lu_zero: http://pastebin.com/awatEEuD [22:12:00] <mru> http://www.ll.mit.edu/mission/communications/ist/publications/041031_Leek.p… [22:12:46] <mru> ^^ that paper finds that splint is no better than randomly tagging 43% of all lines as buggy [22:13:04] <wbs> lol [22:13:28] <wbs> sure, it forces you to manually reread and verify all of it ;P [22:13:43] <mru> but what's the point in using lint then? [22:13:48] <mru> if you're going to reread all of it [22:13:59] <lu_zero> wbs: just ran valgrind on ffmpeg -i rtsp://source -vcodec copy -acodec copy out.nut [22:14:56] <lu_zero> elenril: looks ok [22:15:37] <elenril> lu_zero: maybe i should mention that the commit has refers to parent [22:15:46] <elenril> or maybe anybody has a better idea [22:15:47] <BBB> mru: do you want to merge "Add sample_aspect_ratio to AVFilterLink" into git? [22:16:18] <wbs> lu_zero: uhm, with that patch in place, I get a valgrind warning about a double free now, no such warning before (and no leak there) [22:16:52] <BBB> wbs: where was it originally free'ed? maybe it needs a freep(&..) [22:19:53] <ubitux> jannau: thanks for setting up patchwork for mplayer too [22:21:03] <lu_zero> wbs: if it's freed it isn't in rtsp.c [22:23:42] <wbs> lu_zero: it's freed in utils.c:2549, as st->priv_data [22:25:41] <lu_zero> give me a backtrace [22:26:19] <BBB> oh that's right, utils.c free()s priv_data already [22:26:27] <wbs> http://pastebin.com/n6isx1pV [22:27:16] <lu_zero> I wonder why it doesn't with mpegts-in-rtp... [22:28:03] <lu_zero> ok so my free has to be a freep [22:28:10] <wbs> because for mpegts-in-rtp, the AVStreams aren't created when parsing the SDP, they're created later when the chained mpegts demuxer adds new streams [22:28:28] <wbs> that might be ok [22:28:28] <lu_zero> they should be in the same context... [22:28:47] <BBB> lu_zero: freep() would be ok [22:28:58] <wbs> yes, but the AVStreams priv_data aren't set up if created that way [22:30:51] <wbs> hmm, freep() isn't that easy in that case, you must make sure the AVStream->priv_data for the right stream is zeroed [22:31:14] <lu_zero> uhm? [22:31:24] <lu_zero> no [22:31:28] <lu_zero> grrr... [22:31:38] <lu_zero> freep isn't enough [22:32:28] <lu_zero> we'd get that pointer dangling nonetheless [22:32:30] <wbs> for mpegts in rtp, nb_rtsp_streams is 1, while many AVStreams are created (none which have priv_data set to the rtsp_st field), while they're mapped directly and linked via priv_data for "normal" rtp [22:32:51] <wbs> can we do without setting that pointer to st->priv_data, by always cleaning it up within rtsp? [22:33:22] <lu_zero> I guess we are keeping around a pointer too much [22:34:01] <wbs> sdp_parse_line relies on being able to pick it out from st->priv_data though [22:34:39] <lu_zero> the quickest path is to special case it [22:34:59] <wbs> yeah, the mpegts stuff is special cased in a few other places, too [22:35:39] * lu_zero originally wanted to make it uniform but it didn't work that well [22:36:04] <wbs> it's kinda hard to force the both cases to uniformity yes, when they're almost orthogonally different [22:36:06] <lu_zero> or I can just make that rtsp_st the st->priv_data [22:36:34] <wbs> perhaps, but that would leak if no AVStream ever is created [22:38:37] <Dark_Shikari> jannau: the execution of code differs based on profile_idc [22:38:49] <Dark_Shikari> if the profile is HIGH 444 PREDICTIVE, we run special intra pred functions [22:38:52] <Dark_Shikari> if the profile is HIGH 444, we don't [22:38:57] <lu_zero> st = s->streams[s->nb_streams - 1]; [22:38:57] <lu_zero> rtsp_st = st->priv_data; [22:38:57] <lu_zero> rtsp_st->sdp_ip = sdp_ip; [22:38:57] <lu_zero> rtsp_st->sdp_ttl = ttl; [22:38:57] <Dark_Shikari> therefore, we CANNOT have them use the same id [22:39:52] <wbs> lu_zero: that one perhaps could use rt->rtsp_streams[rt->nb_rtsp_streams - 1] instead? [22:40:54] <lu_zero> I guess I'll figure out tomorrow [22:40:58] * lu_zero now is too tired [22:41:06] <Dark_Shikari> mru: ugh, they have a sheevaplug sequel, and it still has a shitty old armv5 I think :> [22:41:13] * Dark_Shikari prepares for more newbies asking to encode video on them [22:42:31] <mru> this time it has a fan [22:42:39] <mru> the sheevaplug had a habit of melting... [22:42:44] <Sean_McG> ouch [22:42:45] <Dark_Shikari> lol [22:43:03] <mru> or more accurately, the caps in the psu blew up [22:47:23] <_av500_> lu_zero: definitely progress [22:47:39] <_av500_> does not work 100% but when it does it does [22:47:50] <mru> is anything holding up ruggles' fmtconvert patch? [22:48:23] <Sean_McG> also if there aren't any regressions with older compilers, can someone commit 704? [22:48:36] <lu_zero> _av500_: yet another bug [22:48:43] <lu_zero> possibly more ugly [22:48:51] <lu_zero> anyway let me fix what I broke [22:49:02] <kierank> elenril: found a metadata bug [22:49:42] <_av500_> lu_zero: the mem leak? [22:50:09] <wbs> _av500_: which was fixed into a double free for other codepaths.. [22:50:23] <_av500_> yeah, i saw [22:50:42] <lu_zero> wbs: http://ffmpeg.pastebin.com/C8PHG7YM [22:50:48] <lu_zero> try that as quick fix [22:51:16] <_av500_> urg [22:51:26] <lu_zero> ugly? [22:51:31] <lu_zero> it is =P [22:51:33] <_av500_> could have been from me :) [22:51:51] <Dark_Shikari> http://www.youtube.com/watch?v=oJagxe-Gvpw [22:52:08] <wbs> lu_zero: works yes [22:52:09] <ruggles> mru: peloverde gave his ok, and you didn't change much, so i think it's ok to commit [22:54:37] <lu_zero> patch sent [22:57:34] <lu_zero> good night [23:03:10] <jannau> Dark_Shikari: not in ffmpeg. FF_PROFILE_H264_HIGH_444 was not used [23:04:21] <Dark_Shikari> jannau: The inverse was. [23:04:23] <Dark_Shikari> != was used [23:04:34] <Dark_Shikari> h->sps.profile_idc==244 [23:04:36] <Dark_Shikari> in h264.c [23:04:48] <Dark_Shikari> Unless this is something different? [23:06:08] <mru> ruggles: you forgot to remove the yasm code from the old place [23:07:07] <ruggles> didn't you do that in your patch though? [23:07:21] <mru> I only noticed arm [23:08:37] <jannau> Dark_Shikari: that's kind of unrelated to the defines. we should replace the number with the symbol though [23:08:54] <Dark_Shikari> jannau: the problem I mentioned was you were defining HIGH 444 == HIGH 444 Predictive [23:08:58] <Dark_Shikari> iirc [23:09:03] <Dark_Shikari> that == check is intended to tell the two apart [23:09:32] <jannau> latest itu draft say profile_idc==244 HIGH 444 Predictive [23:09:55] <jannau> and it was the previous value for HIGH 444 [23:10:00] <ruggles> mru: oh, it looks like i did miss the x86 yasm code removal [23:10:09] <mru> ruggles: I've fixed it here [23:10:36] <Dark_Shikari> jannau: no it wasn't, that was 144 iirc [23:10:51] <Dark_Shikari> let me check [23:11:06] <jannau> no: -#define FF_PROFILE_H264_HIGH_444 244 [23:11:16] <ruggles> mru: great, i don't have time tonight to update/resend. [23:11:34] <Dark_Shikari> Yup, 144 [23:11:38] <Dark_Shikari> jannau: then that was wrong [23:11:42] <Dark_Shikari> The spec says 144 [23:12:16] <jannau> ok, I'll change that and remove the VERSION_MAJOR check [23:12:37] <jannau> and add a string to the profiles [23:13:29] <jannau> that profile was removed? I haven't seen it in the latest draft [23:13:36] <Dark_Shikari> Yes [23:13:38] <Dark_Shikari> It was removed in 2007 [23:13:42] <jannau> ok [23:13:48] <jannau> thanks [23:14:02] <mru> ruggles: new patch sent [23:41:44] <mru> lol, libjpeg v8 is 40% slower than v6 [23:41:54] <Dark_Shikari> lol libjpeg [23:41:58] <Dark_Shikari> I heard you like the ijg [23:43:01] <kierank> isn't the ijg just a crazy guy now? [23:43:14] <mmu> what are they doing new from last year ? 128bit rendering ? [23:43:33] <mru> v7 is just as slow [23:45:21] <Dark_Shikari> who is it here who knows stuff about RTP? Marvell apparently is looking for someone who does. [23:45:26] <Dark_Shikari> and I'd like to give them a name or something [23:45:39] <mru> hmm, it's spending that extra time in "jpeg_idct_16x16" [23:45:59] <iive> Dark_Shikari: lu_zero [23:46:12] <Dark_Shikari> lu_zero: ping [23:50:41] <mru> ah, disabling that retarded scaling makes it faster [23:51:01] <mru> how the fuck did he manage to slow down normal jpeg decoding by 40% when adding that? [23:52:16] <Kovensky> hm, Marvell... [23:52:28] * Kovensky remembers fighting with an old Marvell wireless card to get it to work under linux [23:52:38] * Kovensky ended up having to use ndiswrapper and it would only work on 32bit kernels [23:52:50] <superdump> mru: scaling stuff? [23:52:50] <Kovensky> it also would refuse working on nt6+ [23:53:08] <mru> superdump: http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/

1 0

IRC log for 2011-01-31
by irc＠mansr.com 01 Feb '11

01 Feb '11

[00:01:54] <Anaerin> ...And still sitting there even longer... [00:01:59] <Anaerin> I don't think it's going to return. [00:04:15] <Anaerin> Nope. Ctrl-C, here we come. [00:18:36] <lu_zero> Anaerin: I'll try to get a proper fix during the next week [02:23:42] <DonDiego> mru: is mem.h the only place where attribute_used appears? [02:23:48] <mru> yes [02:24:01] <mru> at least git grep says so [02:24:04] <mru> and gcc agrees [02:24:50] <DonDiego> i guess.. - it was just surprising.. [02:25:54] <mru> same here [03:07:32] <Sean_McG> can I run an individual fate test in gdb to see where it's segfaulting? [03:08:41] <peloverde_> do "make testname V=1" to get a command line [03:13:17] <mru> Sean_McG: play with the TARGET_EXEC variable [03:13:31] <mru> or perhaps that doesn't play well with gdb [03:13:53] <mru> I'd simply enable core dumps [03:14:47] <Sean_McG> OK so I have to add -g to CFLAGS [03:15:00] <ohsix> . [03:15:07] <mru> should be there already [03:15:25] <Sean_McG> oh...crap yes it is [03:15:31] <Sean_McG> my bad [03:32:28] <Sean_McG> blah, no dump created [03:33:19] <ohsix> need to set a ulimit if the core size is set to nothing [03:33:52] <Sean_McG> sean@tsukimi:/var/opt/BUILD/ffmpeg-fate.amd64/build$ ulimit -a | grep core [03:33:53] <Sean_McG> core file size (blocks, -c) unlimited [03:34:14] <ohsix> theres also a core file pattern thing that can send it to a pipe [03:39:27] <mru> Sean_McG: what are you debugging? [03:51:17] <Sean_McG> atrac3-1 [03:52:02] <mru> Sean_McG: do you have this patch applied? http://patches.ffmpeg.org/patch/697/ [03:52:26] * mru recalls something about gcc 4.6 being looked at [03:52:44] <Sean_McG> ah... looking at the logs here... it's not segfaulting which is why I'm not getting a dump... it segfaults on Linux though [03:53:00] <mru> try that patch [03:53:04] <Sean_McG> yeah I'm building with 4.6 [03:53:22] <Sean_McG> OK... I'mmma go shower and then try again with the patch [03:53:30] <mru> all those audio codec crashes are probably related [03:53:44] <mru> no idea about the pixfmt one [03:53:46] <peloverde_> all the audio crashes were in imdct [03:54:05] <peloverde_> the reason it was only those codecs was because it was only full imdct [03:54:13] <mru> ah [03:54:25] <mru> do you think I should push the patch? [03:54:32] <mru> or wait for BBB or Dark_Shikari? [03:54:42] <peloverde_> wait for an x86 guy [03:54:45] <Dark_Shikari> which one [03:54:56] <mru> Dark_Shikari: http://patches.ffmpeg.org/patch/697/ [03:55:04] <Sean_McG> OK so if you folks are all looking at these I might as well stop [03:55:19] <mru> it's more of an inline asm constraint thing than an x86 thing though [03:55:30] <mru> Sean_McG: every set of eyes helps [03:55:36] <Dark_Shikari> no idea [03:55:42] <Dark_Shikari> die inline asm die [03:55:52] <Sean_McG> lol [03:57:50] <mru> it was never intended for such usage [03:58:03] <peloverde_> what usage? [03:58:11] <mru> writing entire functions [03:59:08] <mru> inline asm is intended, and works well, for small fragments of a few instructions where call overhead would be too high [03:59:46] <mru> and even there, intrinsics that actually work would be better [04:00:00] <mru> some compilers can do it... [04:06:55] <peloverde_> ugh I sent the wrong one [04:16:16] <DonDiego> gnite [04:28:58] <Sean_McG> OK, trying with that patch [04:47:01] <BBB> peloverde: which patch? [04:47:07] <BBB> peloverde: I can review, sorry, was wacthing a movie [04:47:24] <peloverde> BBB: http://patches.ffmpeg.org/patch/704/ [04:47:58] <peloverde> that whole files needs some love but this puts out the immediate fires [04:49:00] <saintdev> but does it put out the ffflames? [04:49:26] <BBB> peloverde: yes patch is fine [04:49:39] <Sean_McG> what's the difference between MANGLE and LOCAL_MANGLE? [04:49:45] <mru> _ [04:49:53] <mru> sometimes [04:50:01] <mru> no difference on linux [04:50:16] <Sean_McG> SunOS shinobu 5.10 Generic_142901-08 i86pc i386 i86pc [04:50:24] <mru> not there either [04:50:27] <Sean_McG> OK [04:50:32] <BBB> local_mangle() is for symbols within the function, mangle() is for things declared outside the scope of the function? [04:50:35] <mru> only on silly systems that put prefixes on global symbols [04:50:39] <BBB> I remember always using mangle in similar situations [04:50:45] <BBB> osx is a silly system :) [04:51:26] <mru> of course it is [05:01:41] <Sean_McG> OK this seems to fix all the atrac3 tests [05:02:05] <Sean_McG> only thing still failing is pixfmt [05:03:10] <peloverde> If i need to use ecx/cl from yasm how do I do that wrt yasm's renaming? [05:03:37] <Dark_Shikari> It's hard. [05:03:45] <Dark_Shikari> Look at cabac-a.asm in x264 for an example. [05:03:59] <Dark_Shikari> well not hard, just an annoyance. [05:04:18] <peloverde> maybe we should just add a 1 << nbits field to the FFTContext? [05:04:21] <Dark_Shikari> you bypass the main macro system [05:04:29] <Dark_Shikari> and you use DECLARE_REG_TMP [05:04:40] <Dark_Shikari> which lets you declare a different register order for the function for each of win32, x86_64, x86_32 [05:04:43] <Dark_Shikari> er, win64 [05:05:13] <Dark_Shikari> example from a very complex function: [05:05:15] <Dark_Shikari> %ifdef WIN64 DECLARE_REG_TMP 3,1,2,0,4,5,6,10,2 [05:05:15] <Dark_Shikari> %elifdef ARCH_X86_64 DECLARE_REG_TMP 0,1,2,3,4,5,6,10,6 [05:05:15] <Dark_Shikari> %else DECLARE_REG_TMP 0,4,2,1,3,5,6,2,2 [05:05:16] <Dark_Shikari> %endif [05:05:29] <Dark_Shikari> in this function, "t3b" is our shift register. [05:09:20] <Dark_Shikari> You could also do the shift in simd if it's convenient. [05:42:27] <peloverde> dumb question: why don't i see a call to memcpy in the disasm of ff_fft_permute_sse? [05:44:02] <Dark_Shikari> peloverde: gcc inlined it? [05:44:21] <peloverde> that would make sense [05:46:49] <peloverde> memcpy()ing the buffers seems silly but i suppose it is frozen api now [05:49:37] <peloverde> It seems like the caller should just pass in two buffers and do its own memcpy if absolutely necessary [05:49:50] <peloverde> thoughts? [05:50:33] <Dark_Shikari> this is the problem with exposing internal apis [05:51:03] <peloverde> well we can change it for the next major bump? [05:57:00] <peloverde> we could even do an fft_permute2 [05:57:07] <peloverde> and phase the old one out [06:00:30] <peloverde> actually av_fft_premute wraps ff_fft_permute so we wouln't be breaking public api [06:00:38] <peloverde> we can just do the memcpy in the wrapper [06:01:28] <peloverde> It looks like only x86 and ARM have optimized versions, mru would you be willing to help with ARM? [06:22:11] <peloverde> (I)MDCT merges the copy with the pre-twiddle though so the changes are largely unimportant [06:28:03] <peloverde> I suppose someone might want to do the permute inplace [06:28:48] <peloverde> though an inplace permute is usually branchy and gross [06:29:14] <Dark_Shikari> random question [06:29:27] <Dark_Shikari> Suppose you have a function that takes a size N input array, and a size N permute mask (i.e. how to permute it). [06:29:46] <Dark_Shikari> Is it possible to perform any arbitrary permute with no more than O(1) temporary data? [06:30:14] <Dark_Shikari> Also, you can't write to the permute mask, it's constant. [06:30:39] <Dark_Shikari> Oh, and can it be done in O(N) time [06:30:56] <peloverde> for arbitrary permute IDK [06:31:25] <peloverde> the comments in fft.c imply that in place permute is reasonable [06:31:42] <peloverde> "TODO: handle split-radix permute in a more optimal way, probably in-place" [06:34:03] <pengvado> Dark_Shikari: yes [06:34:12] <peloverde> if you have a permute that is just based on swaps, only swap at the lower index [06:34:15] <pengvado> any permute can be decomposed into a disjoint set of cycles [06:34:44] <pengvado> each of which can be handled with 1 value copied out of place [06:36:33] <Dark_Shikari> Can that be done with O(1) space? [06:36:38] <Dark_Shikari> A set of cycles requires space. [06:37:02] <Dark_Shikari> I guess in practice you could change your permute mask to be represented as a set of cycles [06:37:03] <pengvado> it's O(N) constant space [06:37:05] <Dark_Shikari> instead of a set of indices [06:37:15] <pengvado> just like the array of indices already is [06:37:52] <Dark_Shikari> It is? [06:38:00] <pengvado> revtab[] [06:38:04] <Dark_Shikari> Oh, in ffmpeg. [06:41:20] <peloverde> pengvado: do you think giving the permute function two buffers and always doing it out of place is smarter? [06:41:30] <pengvado> yes [06:46:04] <peloverde> right now the (i)mdct, does handle the copy in its pretwiddle though so I question how important this is. very few codecs use raw fft [06:56:55] <cartman> moin [07:02:48] <_av500_> +1 [07:16:52] * elenril yawns [07:32:54] * elenril updates on the fflames [07:33:07] <thresh> moroning [07:34:58] <andoma> morning [07:35:53] * cartman brrrrrs its damn cold [07:37:41] * pross-au is sweating like a pig [07:38:56] <pross-au> 70% humidity atm [07:41:23] <cartman> pross-au: I'd prefer that instead [07:50:52] <superdump> morning [07:52:34] <elenril> "Free software's awfully like sausages - wonderfully tasty, but sometimes you suddenly discover that you've been eating sheep nostrils for the past 15 years of your life." [07:56:49] <KotH> salut [08:51:51] * Dark_Shikari pokes BBB to bench that patch [08:52:27] * elenril thinks KotH is scary [08:53:13] <superdump> elenril: why? [08:53:38] <elenril> superdump: did you see his speech just now [08:54:40] <superdump> not scary, just history [08:54:41] <elenril> kinda feels like http://tvtropes.org/pmwiki/pmwiki.php/Main/YouShallNotPass [08:58:29] <KotH> elenril: lol [09:09:29] <elenril> though i'm really suprised by the godwin's law failing [09:11:06] <kshishkov> ? [09:11:28] <elenril> kshishkov: still no mention of nazis in those threads [09:11:32] <elenril> or did i miss something? [09:12:56] <kshishkov> elenril: well, direct translation of "leader" into German is "Führer" though it's not used much these days because of different Austrian [09:13:05] <kshishkov> elenril: so it's no need to mention it [09:17:02] <kshishkov> but speaking of it... [09:17:26] <kshishkov> av500: can we have Das FFmpeg Wechsel Lied for anthem? [09:18:03] <av500> kshishkov: send a patch [09:18:14] <Tjoppen> oh, the flames [09:18:23] * elenril prefers союз нерушимый [09:19:06] <kshishkov> elenril: current Ukrainian anthem is more optimistic [09:19:28] <elenril> ще невмерла? [09:19:33] <elenril> or something like that [09:19:39] <kshishkov> exactly [09:19:47] <elenril> wow, i even remember it a little [09:19:51] <Dark_Shikari> I'm surprised nobody's godwinned it [09:19:59] <Dark_Shikari> considering michael's nationality [09:20:21] <kshishkov> elenril: in winter time it's changed into "ще не змерзла" [09:22:18] <elenril> michaelni: i hereby apply godwin's law to you ;) [09:23:14] <cartman> michaelni is a bot :P [09:23:35] <Dark_Shikari> is michael from austraia or germany? [09:23:54] <cartman> former I believe [09:23:58] <siretart> Dark_Shikari: austria [09:23:59] <av500> austraia is the mythical continents that split into austria and australia? [09:24:05] <Dark_Shikari> So he's even CLOSER to hitler!! [09:24:30] <Dark_Shikari> av500: http://ohforfuckssake.com/files/australiak.jpg [09:24:31] * siretart sighs [09:25:07] <Dark_Shikari> It's the worst country in Europe! [09:25:14] <kshishkov> av500: Austria is a land of mountains and streams and Australia is girt by sea, how can one not distinguish them? [09:25:16] <av500> Dark_Shikari: is there a matching piv for austria? [09:25:23] <Dark_Shikari> av500: don't think so [09:25:23] <av500> pic [09:25:24] <kshishkov> Dark_Shikari: you hurt my Ukrainian pride [09:25:46] <Dark_Shikari> this meme came from that news story about the austrian guy who kept a girl his basement for 18 years [09:25:51] <Dark_Shikari> people kept calling him australian [09:25:56] <Dark_Shikari> and that spawned this meme [09:26:52] <av500> makes no sense, im australia he would have kept her free roaming [09:27:01] <siretart> please, no fritzl jokes. it's already tasteless enough like it is now. [09:27:44] <pross-au> That map is incorrect. Sydney is not the capital!! [09:28:07] <Dark_Shikari> siretart: "tasteless" is the fuel that runs 4chan [09:28:15] <Dark_Shikari> for that matter, the internet. [09:28:40] <av500> Dark_Shikari: so egypt ran out of tasteless? [09:28:47] * elenril would hope we're higher level than 4chan [09:29:01] <Dark_Shikari> 4chan is already max level [09:29:04] <kshishkov> pross-au: ask any guy from Sydney [09:29:11] <av500> elenril: we go up to 11 [09:29:19] <Dark_Shikari> 4chan is level 85 [09:29:23] <elenril> av500: http://kecy.roumen.cz/tweet_z_egypta.jpg [09:29:49] <Dark_Shikari> http://i.imgur.com/RgDGZ.jpg [09:29:53] <av500> elenril: so, the govmt has to airdrop harddrives with p [10:01:37] * elenril discovers git add --intent-to-add [10:01:58] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/TheDevTeamThinksOfEverything [10:05:06] <Tjoppen> and of course, http://tvtropes.org/pmwiki/pmwiki.php/TheDevTeamThinksOfEverything/NetHack [10:15:33] <elenril> how do i change the author name for several commits at once? [10:15:52] <Zor> I don't think you can [10:15:56] <wbs> elenril: you can try filter-branch [10:16:14] <elenril> wbs: any more specific hints? [10:16:20] <elenril> filter-branch is still black magic for me :) [10:16:34] <elenril> Zor: you can do anything with git! [10:16:36] <elenril> it's magic! [10:16:44] <Zor> very true... [10:17:03] <wbs> elenril: git filter-branch --env-filter "if [ "$GIT_AUTHOR_NAME" = "foo" ]; then export GIT_AUTHOR_NAME="bar"; fi" old-commit..HEAD [10:17:18] <wbs> elenril: the docs for filter-branch has some quite useful examples [10:17:59] <wbs> elenril: that way, you could e.g. choose to change the author name just for commits where it is something specific before [10:18:18] <elenril> nice [10:18:32] <Zor> ...git really can do anything [10:18:39] <wbs> old-commit might usually be `git merge-base master cur-branch` [10:21:42] <elenril> wow, it worked [10:21:46] <elenril> wbs: thanks [10:23:11] <av500> merbzt: ping [10:23:46] <merbzt> pong [10:24:28] <wbs> elenril: np, git filter-branch is like the most awesome tool ever :-) [10:28:30] <j-b> or not [10:30:50] <wbs> sure, it's not the most easy to use tool [10:40:28] <j-b> wbs: and it lacks some features [10:40:50] <j-b> like changing author and message at the same time [10:41:08] <wbs> hmm, can't you do that with an env-filter? [10:41:21] <wbs> or that perhaps was a separate filter [10:42:45] <cartman> http://static.whalesalad.com/north_korea/ [10:43:27] <jannau> j-b: you can use multiple --*-filter commands. see http://git.jannau.net/git/FFmpeg.git.convert/tree/merge_FFmpeg_libswscale_g… ff for an ugly example [10:45:18] <kshishkov> cartman: well, caption "North Koreans are always amazed when they see a white man." is incomplete, he's written over the picture "look, negro in pink clothes!" [10:45:31] <cartman> heheh [11:17:15] <Kovensky> "It seems that the goal of the NK architects was to make stations more impressive that Moscow's metro." <-- reminds me to finish Metro 2033 [11:18:10] * kshishkov prefers Tunnelbanan [11:18:15] <elenril> metro 2033 is overrated [11:18:42] <elenril> it has an interesting premise [11:18:55] <elenril> but it gets pretentious and starts AuthorTracting [11:19:08] <Dark_Shikari> Eh? It was fine. [11:19:09] <elenril> and the ending is incredibly meh [11:19:17] <Dark_Shikari> It wasn't as good as Stalker, but it was fun. [11:19:44] * elenril wonders why does everybody keeps calling пикник на обочине by the weird name [11:20:01] <kshishkov> elenril: because they've not read it [11:20:52] <kshishkov> elenril: but don't worry, co-author of that sanctioned fanfics after Обитаемый остров [11:22:47] <elenril> kshishkov: their books got close to unreadable after волны гасят ветер anyway [11:23:54] * Kovensky wonders why the sovietspeak [11:24:17] <elenril> those are the original names of the books [11:24:22] <elenril> and you should go read them RightNow [11:24:56] * thresh doesnt like стругацких [11:25:12] * elenril stops liking thresh =p [11:25:21] <Kovensky> "bonhbl tacrt betep"? [11:25:32] <Kovensky> "ctpyrauknx"? [11:25:33] * Kovensky runs [11:25:57] <thresh> elenril: well, some of their stuff is OK, I just dont like science fiction that much [11:26:33] * elenril stabs Kovensky [11:33:25] <elenril> Dark_Shikari: i agree that it's interesting, but it has too much Fauxlosophy, especially in the second half [11:33:41] <Dark_Shikari> stop using tvtropes words [11:33:54] <elenril> they're convenient [11:34:04] <elenril> and exactly express what i think [11:34:22] <Compn> kshishkov : you didnt add kgv1 decoder into mplayer? :P [11:37:16] <Kovensky> Dark_Shikari: TvTropesWillRuinYourVocabulary [11:39:39] <kshishkov> Compn: only because it was Daniel (aka drv) who finished and comitted it [11:39:56] <kshishkov> Compn: and adding codecs from third parties is your job [11:41:54] <Compn> doh [11:42:12] * Compn thought someone added it [11:47:27] <spaam> mmmm julmust. vad gott [11:58:41] <Compn> someone remind me to make roundup report about blox mpeg2 codec http://samples.mplayerhq.hu/V-codecs/blox.avi [11:58:50] <Compn> feature request [11:59:28] <lu_zero> ok [12:02:01] <Compn> or someone do it for me :) [12:04:08] <elenril> why do both ffmpeg.git and ffmpeg repos exist? [12:04:15] <elenril> it's pretty confusing [12:04:22] <kshishkov> where? [12:04:50] <superdump> elenril: follow http://ffmpeg.org/download.html [12:05:04] <superdump> the ffmpeg repo, is iirc, a git-svn read only repo [12:05:12] <elenril> superdump: i know, but it's still confusing [12:05:35] <elenril> when i'm constructing an address out of my head i'm likely to get that wrong [12:05:37] <superdump> shouldn't be difficult to either take it down or move it [12:06:00] <superdump> also, i think one can generally drop the .git and cloning will still work [12:06:21] <jannau> yes, it's the old repo git-svn repo [12:06:31] <elenril> superdump: that's exactly the point [12:06:35] <elenril> it should work that way [12:06:41] <elenril> but now it'll clone the wrong repo [12:06:44] <superdump> right [12:06:51] <superdump> it should be moved or removed [12:57:31] <kshishkov> why do we have libpostproc in FFmpeg? [12:58:14] <siretart> kshishkov: I think for hysterical raisins. and because other applications like xine still use it. [12:58:33] <kshishkov> siretart: who cares if FFmpeg does not use it? [12:58:33] <elenril> what does it even do? [12:58:40] <kshishkov> postprocesses [12:59:02] <elenril> really? [12:59:17] <siretart> kshishkov: xine devs, distro packagers and possibly other users would be quite annoyed, I imagine [12:59:41] <thresh> indeed [12:59:41] <kshishkov> is Xine still alive? [12:59:44] <siretart> is that really worth dropping it? [12:59:49] <thresh> VLC uses it as well [13:00:05] <thresh> I never found a use case though nor seen the difference with postproc enabled video [13:00:18] <av500> thresh: well, thats a strong point [13:00:37] <BBB> isn't postproc supposed to be a avfilter at some point? [13:00:53] <kshishkov> it has two dozens of filters inside IIRC [13:01:21] <siretart> michaelni: see above, and could you perhaps clarify the relationship between postproc and avfilter? [13:04:23] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rfa34a3626c ffmpeg/ffmpeg.c: [13:04:23] <CIA-38> ffmpeg: Make ffmpeg warns the user when the selected sample format is ignored. [13:04:23] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:20:53] <mru> about the fft... [13:21:15] <mru> why don't we simply leave the permutation as is without copying back? [13:44:08] <michaelni> BBB, siretart , one avfilter should use libpostproc [13:44:44] <michaelni> thresh, low bitrate flv or anything else that shows blocks you will see a huge difference [13:45:50] <siretart> ah, the postproc avfilter is yet to be written. I see. [13:46:09] <mru> there are other apps that use postproc [13:46:19] <kshishkov> mru: but not FFmpeg [13:46:22] <mru> true [13:46:36] <wbs> isn't such deblocking part of the decoder in h264, and mandated by the spec? [13:46:38] <siretart> so? do we want to annoy these external users for no benefit? [13:46:43] <mru> wbs: h264 yes [13:46:53] <mru> siretart: annoy? [13:47:01] <kshishkov> wbs: in-loop vs. out-of-loop deblocking [13:47:02] <siretart> mru: by removing libpostproc [13:47:18] <wbs> ok [13:47:21] <kshishkov> siretart: s/removing/making it standalone [13:48:13] <thresh> michaelni: ah, thanks. I suppose I dont watch videos like that =) [13:48:14] <siretart> kshishkov: that's something different. do you (or know someone) that would volunteer to maintain a standalone version of it? [13:48:39] <kshishkov> siretart: is it maintained at all? [13:48:42] <mru> no [13:49:32] <kshishkov> and it looks like written in sws-style i.e. in need of major cleanup/restructuring [13:49:40] <mru> yes [13:49:47] <mru> both api and internal structure [13:50:42] <kshishkov> siretart: http://codecs.multimedia.cx/?p=315 [13:51:01] <kshishkov> siretart: not about libpp but the notion is the same [13:59:08] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r4543009943 ffmpeg/libavformat/asf.c: [13:59:08] <CIA-38> ffmpeg: asf/wtv: use service_provider and service_name metadata tags [13:59:08] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [14:02:51] <BBB> ? [14:02:54] <BBB> wth [14:03:13] <mru> ? [14:03:20] <BBB> the from: should be peter ross [14:03:27] <BBB> I used git am to import the patch [14:03:31] <mru> you obviously didn't apply it correctly [14:03:36] <BBB> gitk showed it as from: peter ross [14:03:42] <BBB> then I amended it to add the sign-off line [14:03:48] <BBB> and then push [14:03:51] <BBB> and now the from: is wrong [14:04:00] <mru> you should have told it to keep the original author when amending [14:04:20] <mru> to add a sign-off, use "git am -s" [14:04:43] <mru> or to add one to the last commit "git commit --amend -s -C HEAD" [14:04:43] <BBB> git gui has no such checkout... I'll use git am -s next time [14:05:03] <BBB> checkout=checkbox [14:05:05] <BBB> weird anyway [14:05:09] <mru> at least it's only two entries in a table [14:05:27] <mru> not like you're claiming credit for something big [14:05:37] <BBB> right, I chose a small patch to practice git am [14:12:17] <wbs> hmmm, git commit --amend always keeps the original author name/date for me, did that change in some version, or is it controllable with some option? [14:13:45] <mru> wbs: git gui replaces author [14:13:57] <jannau> maybe in ancient version. the author can be changed with --amend --author="..." [14:14:12] <wbs> mru: hmm, that's a weird inconsistency [14:14:42] <wbs> jannau: yeah, I recently had to look up --reset-author in order to do that [14:17:48] <michaelni> siretart, i volunteer to maintain libpostproc somewhere outside ffmpeg if you guys want it out [14:20:42] <BBB> it'd be easier to move it to lavfilter also at some point [14:20:56] <BBB> by itself it doesn't belong there but is part of api, so let's keep it for now [14:21:18] <mru> BBB: I don't see why it doesn't belong [14:21:32] <mru> there are lots of things ffmpeg.c doesn't use [14:21:44] <mru> doesn't make them any less useful [14:21:58] <mru> what libpostproc does need is a major overhaul of both api and code [14:22:42] <michaelni> mru libpostproc is fine [14:22:53] <mru> not the api and not the internal structure [14:22:53] <michaelni> both api and code [14:23:06] <mru> but I'm not going to argue that with you [14:23:20] <michaelni> ok [14:23:30] <BBB> how do I amend just the log msg but not the author using git tools? [14:23:38] <BBB> I want to delete some lines from the commit msg [14:23:42] <mru> BBB: git commit --amend -c HEAD [14:23:50] <mru> that opens an editor with the old message [14:23:54] <mru> edit and save [14:24:54] <michaelni> BBB, libpostproc is usefull for projects without full libavfilter, like resampling is too [14:24:57] <wbs> doesn't need any -c HEAD either, just "git commit --amend" works too [14:25:17] <mru> I could have sworn it didn't use to [14:25:41] * mru needs to read git release notes more carefully [14:26:42] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * r22e9277aa5 ffmpeg/libavformat/vc1testenc.c: [14:26:42] <CIA-38> ffmpeg: VC1testenc: convert pts values to correct time-base. [14:26:42] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [14:29:11] <BBB> hah, that looks better now [14:29:55] * thresh bangs his head against the table http://dumpz.org/30383/ [14:30:30] * cartman helps thresh [14:31:12] <cartman> thresh: SloWaris? [14:31:19] <thresh> cartman: worse, hpux [14:31:23] <cartman> w00t [14:31:31] <cartman> then mru will fix it :P [14:31:51] <thresh> I think hpux is unfixable [14:32:14] <Kovensky> 11:23.43 mru: BBB: git commit --amend -c HEAD <-- `git commit --amend` by itself will always edit the HEAD commit (will also merge anything you `git add`ed with it) [14:32:33] <superdump> that's handy [14:32:44] <cartman> j-b: http://news.ycombinator.com/item?id=2161449 [14:32:57] <superdump> for those "oops i forgot this" or bugs noticed after a commit [14:33:11] <thresh> yeah but don't use that if you pushed already :) [14:33:15] <cartman> yep [14:33:34] <superdump> :) [14:34:23] <kierank> cartman: lol [14:34:38] <benoit-> thresh: the non fast forward pushes can be forbidden on the server side. [14:34:40] <cartman> kierank: GPL code is not for the lulz [14:34:46] <thresh> benoit-: yeah and they are [14:34:50] <cartman> benoit-: its already forbidden atm. [14:34:52] <kierank> cartman: GPL: serious business [14:35:09] <cartman> RMS approved™ [14:35:33] <kierank> also they're actually using correct x264 presets [14:35:35] <benoit-> thresh, cartman: then cool, amend as much as you want, even after pushing :) [14:35:43] <cartman> benoit-: heheh :D [14:36:12] <uau> so you need to delete the current branch and start using a new one instead :) [14:38:07] <mru> uau: the server forbids pushing new branches too [14:42:40] <Kovensky> why forbid branches? [14:43:04] <elenril> because we generally fail at git [14:43:45] <cartman> You don't git it, do you? [14:43:56] <wbs> people can keep branches in personal repos, unless it's an officially sanctioned branch [15:13:22] <siretart> michaelni: if you maintain libpostproc seperately, I volunteer to package and maintain it in debian [15:13:48] <siretart> for ffmpeg, I really don't mind much, both would work for me [15:14:03] <lu_zero> it will be managed by me for gentoo for sure [15:16:03] <mru> let's see if we can clean it up first, if that's too much work, we can consider dropping it [15:17:17] <kshishkov> mru: it's built in the same way as swscaler [15:17:28] <siretart> do we care enough for that? [15:17:55] <lu_zero> uff [15:18:07] <lu_zero> I barely touched swscale.c [15:18:22] <kshishkov> FFmpeg code quality is important, libpostproc - who knows? [15:18:27] <kshishkov> lu_zero: and? [15:18:31] <lu_zero> now the init is first call C then call the arch specific [15:18:48] <lu_zero> but I couldn't untangle the scale function variants so far [15:19:21] <mru> libpostproc is rather small [15:19:33] <mru> fixing it shouldn't be too hard [15:19:33] * lu_zero needs to fetch enough guarana` to try w/out breaking the x86 asm [15:33:50] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * re771d2e3fe ffmpeg/doc/muxers.texi: [15:33:50] <CIA-38> ffmpeg: Add documentation for the image2 muxer. [15:33:50] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [15:36:08] <BBB> wbs: would you be interested in modifying ffmpeg.c, ffplaty.c and all functions that are necessary to be able to use AVOptions with (autodetected) demuxers? [15:36:33] <BBB> so we can use --rtsp-protocol=tcp or so instead of ?tcp to force tcp [15:36:45] <BBB> wbs: you seem the best candidate to do that (if you have time) [15:36:58] <mru> wbs: consider yourself volunteered [15:38:08] <spaam> woho! [15:38:13] <spaam> wbs: grattis! [15:41:18] <lu_zero> ^^; [15:47:04] <CIA-38> ffmpeg: Georgi Chorbadzhiyski <gf(a)unixsol.org> master * r445996aa51 ffmpeg/ (doc/muxers.texi libavformat/mpegtsenc.c): (log message trimmed) [15:47:04] <CIA-38> ffmpeg: Replace defines in libavformat/mpegtsenc.c with AVOptions [15:47:04] <CIA-38> ffmpeg: Around 01/28/11 18:56, Ronald S. Bultje scribbled: [15:47:04] <CIA-38> ffmpeg: > That patch is now merged, can you submit the update to muxers.texi? [15:47:04] <CIA-38> ffmpeg: > Then we'll apply the whole thing. [15:47:05] <CIA-38> ffmpeg: See attached. I hope the documentation is enough. [15:47:06] <CIA-38> ffmpeg: -- [15:48:15] <Tjoppen> even cooler might be to have something like ffmpeg --options-for foo://example.com/bar [15:48:16] * elenril glares at BBB [15:48:27] <elenril> who's playing with git again [15:48:33] <BBB> ? [15:48:43] <mru> you messed up a commit [15:48:47] <BBB> huh? [15:48:50] <BBB> what happened [15:48:54] <mru> you put the entire quoted thread in the commit message [15:48:58] <BBB> oh no it imported the thread [15:48:59] <BBB> argh [15:49:13] <BBB> now what do I do? [15:49:15] <mru> nothing [15:49:23] <mru> but don't do it again [15:49:32] <BBB> git has no undo function? [15:49:34] <mru> no [15:49:39] <mru> not a remote undo [15:49:43] <BBB> uhm... [15:50:05] <BBB> so if you fuck up, you're stuck with it? [15:50:09] <mru> yes [15:50:12] <mru> so don't fuck up [15:50:16] <bilboed-pi> for *EVER* [15:50:19] <BBB> that's easier said then done [15:50:22] <mru> run "git log origin..master" before pushing [15:50:38] <bilboed-pi> git commit -v helps also (you can review your commit that way) [15:50:38] <mru> make sure everything looks ok [15:50:45] <Kovensky> git does have a remote undo [15:50:55] <mru> push -f, yes [15:50:55] <Kovensky> but it will fuck up everyone's trees if they pulled from the tree before you undid it [15:51:18] <mru> shall I fix it on the server quickly before it propagates? [15:52:27] <jannau> mru: it's already to late with auto pushing [15:52:36] <mru> where do we auto-push? [15:52:47] <mru> only patchwork afaik [15:53:02] <jannau> patchwork repo and github [15:53:25] <jannau> not sure how fast the mirror for gitorious is [15:53:30] <mru> BBB: so please double-check next time [15:54:00] <thresh> also, git push -n [15:54:12] <jannau> that doesn't help [15:54:26] <thresh> well I usually check git log with sha ids :) [15:54:52] <jannau> mru: we both made already the same mistake [15:55:07] <BBB> mru: ok [15:55:16] <mru> yes, I've done it myself as well [15:55:32] <mru> and started checking more carefully afterwards [15:55:40] <BBB> I'll be more careful [15:55:45] <BBB> "oops" [15:58:08] <BBB> shall I try to import vasyil's patch? [15:58:13] <BBB> maybe I can try better now [15:58:29] <mru> which patch? [15:58:50] <mru> I applied one from him [15:59:36] <BBB> I guess this must be an old one then [15:59:56] <mru> what's the title? [16:00:32] <BBB> you already applied it [16:00:35] <BBB> I just checked git log [16:00:37] <BBB> so n/m [16:00:59] <mru> there are some patches with wrong status in patchwork [16:01:48] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r365e3c7878 ffmpeg/libavutil/ (attributes.h internal.h mem.h): [16:01:48] <CIA-38> ffmpeg: Rename attribute_used to av_used and move it to attributes.h [16:01:48] <CIA-38> ffmpeg: This is consistent with most of the other attribute macros. [16:01:48] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:03:49] <mru> ruggles: ping [16:04:05] <ruggles> mru: hi [16:04:18] <mru> did you see the updated patches I sent for the dsputil stuff? [16:05:09] <ruggles> yes. looks good. [16:05:26] <mru> can someone else please have a look as well? [16:05:40] <mru> BBB: perhaps you could cast an eye on the x86 parts [16:08:53] <ruggles> mru: i see you changed the vfp part to always build, but the original was wrapped in HAVE_ARMV6 [16:09:05] <mru> that's handled in the makefile now [16:09:09] <ruggles> ah, ok [16:09:13] <mru> ifdefs around entire files are silly [16:09:27] <mru> other than headers of course [16:10:06] <BBB> mru: ok, will look, what's the threadname? [16:10:44] <BBB> remove unneeded bias from ...? [16:10:52] <mru> yes [16:11:00] <mru> and the fmtconvert one [16:11:18] <ruggles> Separate format conversion DSP functions from DSPContext [16:13:26] <BBB> mru: first oen reviewed [16:15:16] <BBB> hm, the fmtconv one mixes moving inline asm to yasm and moving it from one struct to the other [16:15:19] <BBB> that kind of sucks [16:15:23] <BBB> anyway, I'm looking at it [16:32:18] <BBB> mru: [PATCH] Add muxers.texi as dependency to ffmpeg.pod OK with you? or you want ot make it a varlist? [16:32:29] <mru> I want a list [16:34:14] <ruggles> BBB: i don't see where the fmtconvert patch moves inline asm to yasm... [16:37:04] * mru yells at BBB [16:42:16] <BBB> mru: ? [16:42:18] <BBB> I did nothing! [16:42:25] <mru> you applied a patch that broke ts test [16:42:32] <BBB> huh? [16:42:38] <mru> fate is crying [16:43:01] * elenril pats fate [16:44:03] <BBB> hum [16:44:06] <BBB> what changed? [16:44:07] <BBB> I'm confused [16:44:22] <jannau> probably changed PIDs [16:44:37] <mru> but I don't see how [16:44:43] <BBB> - service->pmt.pid = DEFAULT_PMT_START_PID + ts->nb_services - 1; [16:44:43] <BBB> + service->pmt.pid = ts->pmt_start_pid + ts->nb_services; [16:44:47] <BBB> the -1 went missing [16:44:57] <mru> ah, there it is [16:45:08] <BBB> can you fix it? [16:45:14] <BBB> I have student proposals to read [16:45:18] <gfto> BBB: no it is not :) [16:46:00] <mru> what is not what? [16:46:01] <gfto> DEFAULT_PMT_START_PID was constant when replaced with variable, -1 gives the wrong pid [16:46:15] <mru> patch or gtfo :) [16:46:18] <gfto> thats why I removed it :) [16:46:34] <mru> the patch changes the default output [16:46:34] <BBB> the -1 is because nb_streams starts at one [16:46:47] <BBB> and start_pid should be the number itself [16:46:54] <BBB> so you crrect for nb_streams being 1 by subtracting one [16:46:57] <BBB> it should be there [16:47:07] <BBB> mru: can you run lavf-ts with -1 re-added to confirm it fixes it? [16:47:09] <mru> putting the -1 back makes the test pass [16:47:14] <BBB> please commit [16:47:28] <jannau> no. change the default instead [16:47:40] <mru> that makes no sense [16:47:41] <BBB> jannau: then it's lexicographically wrong [16:47:52] <BBB> the -1 is correct from a user perspective [16:47:55] <mru> yes [16:48:05] <BBB> the number should be set to start_pid for the first program [16:48:10] <BBB> right now it's set to start_pid+1 [16:48:10] <mru> pid == base+index [16:48:15] <BBB> -1 sets it back to start_pid [16:48:15] <mru> index == count - 1 [16:48:22] <BBB> exactly [16:48:25] <jannau> ah, yes. I was confused [16:51:05] <gfto> BBB: may be it is better to set default in AVOpiton to be 0x1001 to preserve the old numbering when the ption is not used [16:51:30] <gfto> my logix was that setting -pmt-start pid you want this pid to be the pmt pid, not something else [16:51:53] <mru> that's exactly what you get with my patch [16:52:01] <mru> you were setting it to one more [16:53:56] <BBB> gfto: read mru's explanation up there, it's not start_pid that's wrong, it's stream_idx that is wrong; you're not reading stream_idx, you're readng stream_cnt, which is stream_idx+1, so you're etitng start_pid one too high [16:54:00] <BBB> er, stream_pid [16:56:03] <BBB> mru: "[PATCH] In video_thread(), disable logging of rescaled timestamps if DEBUG is not enabled" - why did you say it's ok to _not_ fold the calculation innto the av_dlog()? [16:56:26] <mru> because the calculation is always needed [16:56:41] <mru> the dlot() prints both the old and new values [16:57:08] <mru> dlog [16:57:45] <BBB> ok, feel free to commit then [16:58:08] <mru> I already did [16:58:45] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r740ad0d14d ffmpeg/libavformat/mpegtsenc.c: [16:58:45] <CIA-38> ffmpeg: mpegtsenc: fix PMT PID calculation [16:58:45] <CIA-38> ffmpeg: 445996aa51f4f1d9a26456a8511988291a720ba0 caused the PMT PID to be [16:58:45] <CIA-38> ffmpeg: off by one. This corrects it. [16:58:45] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:59:43] <BBB> can you say "queued" - so I don't look at the threads then? :-p [16:59:55] <gfto> hmm, I was mistaken in thinking that pmt start_pid should be the first pid :) tricky. It is pmt_start_pid-1, may be the docs should be fixed as wall [17:00:11] <mru> no, that's not it [17:01:13] <BBB> gfto: service->pmt.pid = DEFAULT_PMT_START_PID + ts->nb_services - 1; [17:01:18] <BBB> gfto: see how that's calculated? [17:01:29] <gfto> BBB: yes, and DEFAULT_PMT_START_PID was 0x1000 [17:01:32] <BBB> gfto: START_PID (or your AVOption setting) is the first pid right? [17:01:36] <BBB> what is nb_services? [17:01:51] <mru> sounds like number of services to me [17:02:00] <BBB> mru: sshhhh, I want him to see it ;) [17:02:15] <gfto> when I replaced with options, I saw that setting the option give me one less so I presumed I was doing something stupid and removed the -1 (that was obviously stupid :) [17:02:21] <mru> BBB: have you considered a career in teaching? [17:02:35] <av500> ho chose teching [17:02:38] <av500> he [17:02:40] <BBB> mru: I'm actually teaching a class right now [17:02:46] <av500> while on irc? [17:02:51] <BBB> no [17:02:57] <BBB> while at university in general [17:03:11] <BBB> gfto: explain to me in your own words what the variable nb_services represents in the above line of code [17:03:14] * mru has dabbled a little in teaching [17:03:20] <mru> quite frustrating at times [17:03:38] <gfto> BBB: number of services (rfrom the top of my mind) [17:04:03] <BBB> gfto: right [17:04:09] <BBB> gfto: so let's assume a simple case [17:04:22] <BBB> gfto: where we have a simple file with just one single audio service, that's all, nothing else [17:04:28] <BBB> gfto: what is the value of that variable? [17:05:00] <gfto> zero if it is used as index 1 if it is used as count [17:05:11] <BBB> is it an index or a count? [17:05:43] <gfto> "for(i = 0; i < ts->nb_services; i++) " I would say count [17:06:04] <BBB> right [17:06:07] <BBB> so what is the value then? [17:07:00] <gfto> one [17:07:05] <BBB> ok [17:07:09] <BBB> let's go back to the line of code now [17:07:10] <BBB> service->pmt.pid = DEFAULT_PMT_START_PID + ts->nb_services - 1; [17:07:32] <BBB> what is the value that will be written in service->pmt.pid, if DEFAULT_... is 0x1000, ts->nb_services is 1? [17:07:49] <av500> 42? [17:08:08] <gfto> 0x1000 :) [17:08:29] <BBB> gfto: and is that what you would expect to happen? [17:08:38] <bunniefoofoo> is there a trick to ffmpeg encoder when setting thread_count in AVCodecContext? I have set it to "2" and only see a slight boost in mpeg2 encoding [17:08:52] <BBB> as a user, using --start_pid=0x1000, do you think it should write 0x1000 for the first service? [17:08:56] <{V}> BBB in teacher mode is a little scary :) [17:09:20] <bunniefoofoo> do I have to use a bigger encoding buffer perhaps? [17:09:30] <BBB> bunniefoofoo: #ffmpeg please [17:09:36] <bunniefoofoo> ok [17:10:30] <BBB> gfto: and now also look at your code: service->pmt.pid = ts->pmt_start_pid + ts->nb_services; <- if pmt_start_pid is 0x1000 and ts->nb_services is 1, what is the value that it writes now? and is that value still correct if a user specified --start_pid=0x1000? [17:14:06] <gfto> BBB: now I'm testing with "-mpegts_pmt_start_pid 0x1000" and the output file have PMT pid set 0x0fff (that is with mru's fix to add back -1) [17:14:39] <gfto> the input file have 1 program with audio and video [17:15:41] <BBB> uh [17:15:45] <BBB> then the original test is wrong [17:15:47] <BBB> hm [17:16:04] <BBB> mru: look below [17:16:08] <BBB> service->pmt.pid = ts->pmt_start_pid + ts->nb_services; [17:16:09] <BBB> service->sid = sid; [17:16:09] <BBB> service->provider_name = av_strdup(provider_name); [17:16:09] <BBB> service->name = av_strdup(name); [17:16:09] <BBB> service->pcr_pid = 0x1fff; [17:16:10] <BBB> dynarray_add(&ts->services, &ts->nb_services, service); [17:16:15] <BBB> I think fate is wrong [17:16:18] <mru> I was just looking at that [17:16:31] <BBB> who on earth wrote that fate test? [17:16:47] <mru> that's not the question [17:16:56] <mru> who wrote the muxer is [17:17:19] <gfto> it always generated 0xfff for pmt even if the define says 0x1000 [17:17:46] <gfto> "always" as in when there is one program [17:18:06] <gfto> so fate was right to be become red (thats my fault) [17:18:15] <BBB> gfto: apologies, I'm wrong and fate is wrong [17:18:28] <BBB> anyway, let's fix fate [17:18:36] <gfto> BBB: no probs, it is the end of day and can't really think straight [17:18:39] <mru> the code is fucked up [17:19:17] <mru> besides, generating dvb tables is ridiculous [17:19:27] <mru> nobody would ever use ffmpeg to feed a broadcaster [17:19:43] <gfto> I'm to blame here because silently fixed that bug forgeting about fate tests that will expect old default values, cest la vie :) [17:19:55] <mru> we're all at fault here [17:20:53] <gfto> well I'm using for some kind of broadcast application althou I don't care about SDT being there or pmt pids, etc :) [17:21:29] <mru> the real sdt has to be generated by the broadcaster [17:21:34] <mru> nobody else knows what to put in it [17:21:43] <Tjoppen> mru: a user was appearently able to use it to feed a QAM modulator using a hackish patch of mine to fix the current pcr issue [17:22:04] <mru> a qam modulator can be fed with any stream of bits [17:22:07] <mru> it's just a modulator [17:22:30] <Tjoppen> true. appearently it didn't accept the stream before though [17:22:37] <Tjoppen> he probably meant something else [17:22:57] <Tjoppen> and of course, the real test is whether an stb will take it :o [17:23:22] <mru> on the modulators I've used you'd just set the modulation parameters and start feeding bits [17:34:12] <av500> BBB: might be too late now for your NY flat: http://www.ikeahackers.net/2011/01/when-imac-goes-to-work.html [18:06:02] <jannau> mru: fabrice did the dvb tables for his hacked graphic card^W^W^W custom built DVB-T modulator [18:07:04] <jannau> http://bellard.org/dvbt/ [18:07:15] <mru> oh yes, that thing [18:35:36] <ruggles> do i have to reply directly to the previous patch in order for patchwork to not duplicate it? [18:35:58] <mru> patchwork still duplicates [18:36:54] <ruggles> oh, ok. i've been manually mark my previous patch as superceded. is that the right thing to do? [18:37:17] <mru> I haven't found a better way [18:37:21] <mru> jannau might know [18:40:42] <jannau> wait for me doing it [18:41:53] <jannau> I need a little time make patchwork useful [19:13:17] <wbs> BBB: I can give it another look, I started looking at it some weeks ago, but it was less trivial than I had hoped for [19:51:22] <Jumpyshoes> BBB: make fate if failing for me on HEAD on h264-lossless [19:52:29] <wbs> nitpick point of the day: HEAD isn't equal to trunk in SVN-land - HEAD is whatever you have checked out currently (which may be an old version or whatever), master is the name of the main branch [19:52:39] <Jumpyshoes> BBB: oh wait, i might need to update my fate samples [20:18:30] <mru> wbs: nitpick2: there's no requirement to have a 'master' branch [20:19:29] <wbs> mru: true [20:20:04] <wbs> but that's probably what people mean in most of those cases. if really nitpicky, one should of course say which repo's master one refers to, too [20:20:16] <Jumpyshoes> BBB: http://ffmpeg.pastebin.com/qaWi8ga8 patch to remove the GPL stuff [20:20:25] <mru> wbs: or just say the sha1 [20:21:02] <mru> Jumpyshoes: someone gave permission to relicense? [20:21:20] <wbs> mru: yeah, that's of course the best if you want to refer to something that specific [20:21:51] <Jumpyshoes> mru: holger, yes [20:22:00] <BBB> mru: they all did [20:22:03] <elenril> the commit message should say that then [20:22:08] <BBB> mru: I chased holger until he said yes/no [20:22:19] <BBB> Jumpyshoes: yeah, make sure that's clear from the commit msg, and then send to the ML, I'll apply for you [20:22:25] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * r8cb3c557a9 ffmpeg/libavformat/oggparsevorbis.c: [20:22:25] <CIA-38> ffmpeg: Ogg: discard non-essential metadata from Vorbis header when creating extradata [20:22:25] <CIA-38> ffmpeg: The first part of the metadata, the "vendor" string, is required by [20:22:25] <CIA-38> ffmpeg: libvorbis, it will refuse to play when it is not available. [20:22:25] <CIA-38> ffmpeg: Also we do not currently parse that part into metadata so it would also [20:22:26] <CIA-38> ffmpeg: be lost if we removed it as well. [20:22:27] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:22:33] <Jumpyshoes> BBB: ok, just making sure fate works [20:22:35] <BBB> permission was given by Jason/Loren earlier, and by Holger just a few days ago [20:22:40] <mru> the commit message should if possible reference a public notice about the relicensing [20:23:50] <Jumpyshoes> BBB: was there a public notice? [20:26:35] <mru> ruggles: what's new in your latest bias removal patch? [20:27:29] <BBB> Jumpyshoes: no [20:27:34] <BBB> Jumpyshoes: but I have chatlogs [20:27:48] <BBB> Jumpyshoes: I'll ask holger to ack it on the ML once you've sent the patch [20:28:19] <Jumpyshoes> BBB: okay, what's his last name again? [20:28:42] <BBB> lubitz [20:28:48] <Jumpyshoes> oh, thx [20:37:01] <Jumpyshoes> BBB: so about the other project, i had some of the registers loaded inside the code for the predicts. making another function will = slower code, is that okay? [20:37:17] <Jumpyshoes> BBB: probably will cut code size by a lot though [20:38:21] <elenril> Jumpyshoes: are you going for gsoc? [20:38:53] <Jumpyshoes> elenril: too young [20:38:58] <Jumpyshoes> elenril: otherwise i would [20:39:18] <ruggles> mru: i just changed HAVE_6REGS per comment from BBB [20:39:31] <Jumpyshoes> elenril: developing for open source projects = resume++, and i like working on asm [20:39:37] <Jumpyshoes> elenril: so just doing this for fun [20:39:52] <elenril> gsoc is so restrictive? [20:39:53] <elenril> o_0 [20:40:09] <Jumpyshoes> elenril: i'm 17, you need to be 18 [20:40:48] <wbs> don't you have to be enrolled at a university/college or similar, too? [20:41:39] <Jumpyshoes> i will be by the time gsoc starts, but i'm still too young [20:42:10] <wbs> ah, ok [20:42:37] <wbs> too bad [20:42:48] * elenril feels old [20:42:48] <Jumpyshoes> well, there's always next year [20:44:47] <BBB> Jumpyshoes: you don't have to unload registers when calling [20:44:55] <BBB> Jumpyshoes: if you call a function, the registers are still intact [20:45:11] <BBB> Jumpyshoes: so you can load, call, work on the loaded regs, ret and then continue specific stuff [20:45:29] <mru> custom calling conventions ftw [20:45:33] <Jumpyshoes> BBB: unless you want me to have four different load functions, i don't know if that will work [20:46:20] <BBB> Jumpyshoes: are values loaded in different registers for each function? [20:46:25] <BBB> that would kind of suck [20:46:29] <BBB> can you "generalize" that? [20:46:39] <BBB> mru: indeed, custom calling convention ftw [20:46:41] <BBB> \o/ [20:46:57] <mru> and multiple entry points [20:47:04] <Jumpyshoes> BBB: yes, but not without a speed decrease [20:47:18] <BBB> Jumpyshoes: these functions aren't used terribly much, so a 1 cycle loss is ok [20:47:23] <BBB> if size decreases with a few kb [20:47:24] <Jumpyshoes> BBB: okay [20:47:41] <BBB> Jumpyshoes: but don't go out of your league, this is not terribly important, if it takes more than afew minutes, do something else that is more fun [20:47:42] <BBB> :) [20:47:55] <Jumpyshoes> oh, this will take more than a few minutes <_< [20:48:14] <BBB> then don't do it :-p [20:48:19] <Jumpyshoes> heh, okay [20:49:20] <BBB> what would you like to learn? [20:49:24] <BBB> that's much more important [20:49:33] <BBB> what do you want to do if you were to, say, do ffmpeg for another year [20:50:00] <elenril> we could use a new leader [20:50:04] * elenril hides [20:50:06] <Jumpyshoes> LOL [20:50:30] <Jumpyshoes> BBB: hrm, that's a good question... i don't have anything in mind atm except asm [20:50:58] <Jumpyshoes> BBB: i think that since i plan to work on this for a while, i'd also like to learn more about ffmpeg in general, since it's important to broading your scope when learning [20:51:13] <Jumpyshoes> BBB: so i guess i'm pretty open to anything really [20:51:32] <_av500_> pts guessing? [20:54:40] <BBB> Jumpyshoes: asm is really just "the cpu-intensive tasks that can be vectorized" - you could do more on generic video coding structure [20:54:58] <BBB> Jumpyshoes: have you ever considered - just for a change - to implement a video decoder for a simple format yourself? [20:55:06] <BBB> Jumpyshoes: at some point we can teach you how to RE a video codec [20:55:11] <BBB> kshishkov is really good at that [20:55:42] <Jumpyshoes> BBB: hrm... that sounds interesting [20:56:19] <Jumpyshoes> BBB: no clue how complex/hard that would be, but it would allow me to learn more about video decoding in general [20:56:27] <BBB> that was my idea [20:57:11] <Jumpyshoes> BBB: haha yea, that sounds like something i could like. also, what is RE a video codec? [20:57:41] <BBB> reverse engineer [20:58:00] <BBB> so rather than working from a defined video coding structure, work from a binary that decodes a video file and try to recreate it in c [20:58:05] <Jumpyshoes> oh, i'm also interested in reverse engineering in general too, that works out real nice [20:58:21] <BBB> it's a little more obsessive, very complex in a way, so I'd go with a simple video codec first before going to more complex reverse engineering [20:58:33] <BBB> you have asm knowledge, so reverse engineering is not completely impossible [20:58:38] <BBB> in fact you'd be quite good at it [20:58:41] <mru> it helps being familiar with common coding methods [20:58:42] <BBB> since you can read/write asm [20:58:47] <saintdev> bink-b ^_^ [20:58:49] <mru> so you recognise a dct when you see one [20:58:54] <BBB> yeah [20:59:09] <BBB> and then you don't have to RE it only to throw it away later because ffmpeg already has a better one [20:59:13] <_av500_> mru: if you are lucky that the codec has one :) [20:59:20] <Jumpyshoes> i see [20:59:21] <Jumpyshoes> that makes sense [21:00:05] <_av500_> thresh: the eagle has landed [21:01:33] <BBB> Jumpyshoes: let's take it slowly and have you work on a defined video codec first, you already know h264 so a simpler one should be super-easy [21:01:49] <BBB> if you're interested [21:01:58] * BBB goes look for unimplemented video codecs or features [21:02:18] <mru> vp7 [21:02:28] <Jumpyshoes> i don't actually know h264 that well, since i've only been working on asm [21:02:33] <BBB> a pretty interesting thing would be wmv2 j-frames (or was that done already?) or rv40 bidir prediction (but that involves RE'ing) [21:02:45] <mru> http://wiki.multimedia.cx/index.php?title=Category:Undiscovered_Video_Codecs [21:02:48] <mru> ^^ take a pick [21:02:49] <BBB> Jumpyshoes: well it goes two ways, you'll get to know h264 better by working on other video codecs [21:03:12] <Jumpyshoes> BBB: yea, true [21:03:21] <mru> working on vp8 is so full of wtf moments [21:03:22] <BBB> coding techniques are often similar [21:03:27] <BBB> mru: whehe :) [21:03:44] <mru> why can't they just use normal rounding everwhere? [21:04:10] <saintdev> i thought we had a REDcode decoder? [21:04:42] <mru> we have a demuxer [21:04:48] <Dark_Shikari> But Jumpyshoes said he was going to do useful stuff, like k-mean or non-local RD =p [21:04:54] <Dark_Shikari> don't steal him ;) [21:05:27] <Jumpyshoes> i'm working on avx actually [21:05:39] <Jumpyshoes> but it's kinda annoying backtracking to find out where the slowdowns occured [21:06:00] <mru> you have avx hw? [21:06:23] <Jumpyshoes> oh, no [21:06:32] <Dark_Shikari> You don't need it to convert 2 operand to 3 operand code [21:06:42] <Dark_Shikari> But I'm getting some benching hardware soon [21:06:42] <Jumpyshoes> ^ yea [21:06:49] * mru sends Jumpyshoes an old vax machine [21:06:55] <Dark_Shikari> and one of the .jp guys who hangs around #x264 just installed a sandy bridge [21:06:58] <Dark_Shikari> so he can bench [21:07:02] <Dark_Shikari> Jumpyshoes: harass boiled_sugar to bench for you~ [21:07:17] <boiled_sugar> ? [21:07:22] <Jumpyshoes> Dark_Shikari: oh, i mean in non-avx mode [21:07:35] <Dark_Shikari> Oh, it'd be useful to bench your avx changes too though. [21:07:38] <Jumpyshoes> http://x264.pastebin.com/euy21LYE so like all these are slower w/ the 3 operand abstraction layer [21:07:46] <Jumpyshoes> oh, i plan on doing that too [21:07:55] <Jumpyshoes> as soon as i actually initialize the function <_< [21:17:22] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r80ba1ddb58 ffmpeg/libavcodec/ (21 files in 4 dirs): [21:17:22] <CIA-38> ffmpeg: Remove unneeded add bias from 3 functions. [21:17:22] <CIA-38> ffmpeg: DSPContext.vector_fmul_window() [21:17:22] <CIA-38> ffmpeg: DCADSPContext.lfe_fir() [21:17:22] <CIA-38> ffmpeg: SynthFilterContext.synth_filter_float() [21:17:23] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:17:24] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rd19b744a36 ffmpeg/libavcodec/x86/dsputil_mmx.c: [21:17:24] <CIA-38> ffmpeg: cosmetics: indentation [21:17:25] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:31:30] <BBB> ruggles: nice work! [21:32:16] * Dark_Shikari pokes BBB to bench his patch. [21:32:25] <BBB> oops, forgot [21:32:25] <ruggles> BBB: thanks [21:32:36] <BBB> I still have it here, I'll bench tonight, promise [21:32:40] <BBB> at work now, can't bench [21:32:46] <BBB> Dark_Shikari: please review my emu_ege patch in return [21:35:00] <Jumpyshoes> BBB: what do you think the chances are of me getting a summer internship at google <_< the microsoft thing didn't work since i'm too young [21:35:29] <merbanan> ruggles: \o/ [21:35:30] <Dark_Shikari> BBB: why do you have special x86_64 code to use rax instead of an mmx register? [21:35:34] <Dark_Shikari> it's not any faster [21:35:45] <Dark_Shikari> why are you using movdqu ? [21:39:13] <Dark_Shikari> for left/right: try pshufb [21:48:10] <BBB> Dark_Shikari: shorter opcode [21:48:25] <BBB> Dark_Shikari: the x86-64 code is really tight, one of them is exactly 128 bytes [21:48:36] <BBB> any change for the worse and I need to move to 256-byte blocks [21:48:39] <BBB> which would suck [21:48:55] <Dark_Shikari> ah [21:49:27] <Dark_Shikari> on FASTSHUFFLE CPUs, pshufb can go from a -> aaaaaaaaaaaaaaaaa in one cycle [21:49:38] <BBB> using pxor as third reg? [21:49:41] <BBB> that's nice [21:49:46] <BBB> hm, should look into that [21:49:50] <Dark_Shikari> on Atom, it's 6 cycles, unpipelined [21:49:56] <Dark_Shikari> on Conroe, it's 2, unpipelined [21:50:12] <Dark_Shikari> I suggest you rip cpu detection code from x264 to detect this, and possibly add the fastshuffle flag to ffmpeg. [21:52:59] <Flameeyes> mru: ping [21:53:41] <BBB> even on atom that may be faster than what I currently do (mov ah, al; movd mm, eax; pshufw mm, mm, 0, movqx2 [21:54:33] <Dark_Shikari> punpcklbw is slower than that? [21:54:35] <Dark_Shikari> punpcklbw + pshufw [21:54:36] <mru> Flameeyes: pong [21:54:56] <Flameeyes> mru: am I missing something or for whatever reason the symbol and string tables of ELF libraries are loaded into memory? [21:56:39] <BBB> Dark_Shikari: I need the ax for shorter movs anyway (e.g. 18 bytes = movq+movq+mov-word) [21:56:52] <mru> Flameeyes: perhaps for use when resolving symbols in shared objects loaded later [21:56:55] <BBB> so I always fill byte->word using mov ah, al [21:57:08] <BBB> by lack of pextrw in mmx basic instruction set [21:57:21] <Dark_Shikari> Also, BBB, what about the fact that in filling 'right', you're allowed to write more bytes than necessary [21:57:25] <Dark_Shikari> but you can't do so when filling 'left'? [21:57:25] <Flameeyes> mru: yeah I know many of the possible "whatever reason".. just wanted to confirm I wasn't on drug when I saw them loaded [21:57:35] <Dark_Shikari> Well, I guess you can do that on left, just not on the first row. [21:58:00] <BBB> Dark_Shikari: "write more bytes"? I don't think you can do that, I copy body first [21:58:05] <BBB> you don't want to overwrite that [21:58:16] <Dark_Shikari> er... [21:58:23] <Dark_Shikari> [left] [body] [right] [21:58:30] <Dark_Shikari> [left] [body] [rightXXXXXXXXXXXXX] [21:58:32] <Dark_Shikari> where X are extra bytes [21:58:35] <Dark_Shikari> what did I overwrite? nothing. [21:58:43] <BBB> no, but wrt left [21:58:52] <Dark_Shikari> [XXXXXXleft] doesn't overwrite anything either [21:59:20] <BBB> on emu_edge, XXX is the last pixels of the previous line, which for line=0 is the previous block [22:00:36] <Dark_Shikari> The previous line is of size stride. [22:00:37] <Dark_Shikari> It's big. [22:00:46] <Dark_Shikari> Though I guess in theory it might not be big enough? [22:00:50] <Dark_Shikari> for tiny tiny images? [22:00:57] <Dark_Shikari> ... we should have a fate test for that. [22:03:47] <Kovensky> talking about fate, I see that the docs all refer to svn [22:11:00] <BBB> Dark_Shikari: it could be packed, I don't trust it... besides, this is shit-ass fast already :-p [22:11:21] <BBB> Dark_Shikari: don't optimize too much for 16-byte left/right edges, for both h264 and vp8, most edges are 1 or 2 pixels [22:11:27] <BBB> most being like 90% [22:11:45] <BBB> brb [22:12:12] <Dark_Shikari> k [22:12:53] <Dark_Shikari> BBB: lgtm'd [22:12:54] <Dark_Shikari> afk [23:02:10] <Sean_McG> mru: any more motion on patch 704? [23:03:39] <mru> poke peloverde [23:33:20] <saintdev> ruggles: what's the reasoning behind using an iir filter for attack detection?

1 0