Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2011

1 participants
28 discussions

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

18 Feb '11

[00:05:47] <dalias> wow i found the cause of ice [00:05:49] <dalias> gcc is idiotic [00:06:10] <mru> enlighten us [00:06:39] <dalias> the comparison function they pass to qsort asserts get_decl_name(e1)!=get_decl_name(e2) with a comment that 2 elements cannot be equal [00:06:44] <dalias> however [00:07:02] <dalias> C allows qsort to call the comparison function with both pointers pointing to the _same_ element [00:07:13] <dalias> in which case of course they'll be equal [00:07:25] <Sean_McG> lol [00:07:27] <dalias> now of course I should optimize my qsort not to do that :) [00:07:34] <dalias> but it's still a bug in gcc [00:07:46] <Sean_McG> please bugzilla if you have time [00:07:47] <dalias> they should make the assert this: [00:07:53] <iive> dalias: gcc or glibc? [00:08:15] <dalias> e1!=e2 && get_decl_name(e1)!=get_decl_name(e2) [00:08:22] <dalias> gcc [00:08:27] <Jumpyshoes> i thought if you submit a bug report to gcc nothing happens. ever. [00:08:35] <Sean_McG> no [00:08:48] <Sean_McG> I've helped fix 2 bugs in the past few months [00:08:51] <mru> Jumpyshoes: that's a good approximation but not entirely accurate [00:08:57] * Sean_McG sighs [00:09:20] <Jumpyshoes> mru: i see [00:09:36] <Sean_McG> meh, nevermind... I'mma go watch some True Blood [00:09:39] <mru> it might also get swept under the carpet to make the release notes prettier [00:10:05] <Jumpyshoes> lol [00:10:11] <mru> it's no joke [00:10:28] <Jumpyshoes> ... do they at least close tickets? [00:11:57] <mru> dalias: what does your qsort() do if called on the array { rock, paper, scissors }? [00:13:38] <Dark_Shikari> Does gcc inline the quicksort comparator function? [00:13:42] <dalias> mru, i dunno :) [00:13:45] <Dark_Shikari> (when possible) [00:13:50] <dalias> its undefined behavior so it doesnt really matter [00:13:59] <mru> Dark_Shikari: how could it ever be possible? [00:14:03] <mru> dalias: I know [00:14:15] <mru> dalias: but not infinilooping would be nice nonetheless [00:14:23] <Dark_Shikari> mru: if it's static? [00:14:28] <Dark_Shikari> And never called by anything else? [00:14:30] <Dark_Shikari> And constant? [00:14:40] <mru> Dark_Shikari: qsort() isn't likely static [00:14:44] <Dark_Shikari> I mean, if the comparator is [00:14:51] <Dark_Shikari> and qsort() is an intrinsic. [00:14:56] <Dark_Shikari> That is, if qsort was treated as one. [00:14:58] <Dark_Shikari> Like memcpy. [00:14:59] <mru> hmm [00:15:01] <mru> evil [00:15:01] <dalias> mru, infinite looping might actually be nicer :) [00:15:06] <dalias> at least you'd know there's a bug [00:15:07] <Dark_Shikari> That wouldn't be evil, that would be really cool [00:15:12] <Dark_Shikari> it would make qsort() less horribly slow. [00:15:17] <Dark_Shikari> it would be just as fast as C++ sorting [00:15:18] <dalias> rather than silently returning bogus results [00:15:19] <Dark_Shikari> i.e. template-based. [00:15:24] <Sean_McG> fast and C++ [00:15:25] * Sean_McG sighs [00:15:28] <dalias> but my guess is it returns [00:15:34] <dalias> since heapsort is always the same number of steps [00:15:49] <dalias> regardless of input [00:28:51] <j-b> av500: 'lo? [03:43:19] <peloverde> BBB: I assume you meant pengvado but the parts I understand seem ok [04:36:05] <BBB> peloverde: oops, tab completion problem, sorry [04:36:45] <BBB> Jumpyshoes: yes I can look at it (tomorrow) [04:36:58] <BBB> oh D_S already did [04:37:53] <Jumpyshoes> BBB: the avx patch? [04:38:09] <BBB> no I meant the inline asm for get_cpuinfo [04:38:13] <Jumpyshoes> oh [04:38:18] <BBB> but I read the rest, so not necessary [04:38:23] <Jumpyshoes> apparently there were issues with the avx patch [04:44:22] <Dark_Shikari> Interesting. [04:44:28] <Dark_Shikari> memsetting 12 bytes per struct in a long array of structs [04:44:48] <Dark_Shikari> ... is slower than memsetting all 72 bytes of every struct. [04:46:28] <Jumpyshoes> <3 gcc [04:48:37] <Jumpyshoes> BBB: http://ffmpeg.pastebin.com/sn5EJaG2 comments please, updated Dark_Shikari's patch, but apparently there's an issue with xgetbv [04:49:46] <Dark_Shikari> not gcc afaik [04:49:50] <Dark_Shikari> xgetbv? what [04:49:52] <Dark_Shikari> what about it [04:50:09] <Jumpyshoes> dunno, mans had an issue on the mailing list [04:50:35] <Jumpyshoes> >What you wrote will not compile, or at any rate should not, and I see no reason to copy an ugly style. [04:50:48] <Jumpyshoes> http://patches.ffmpeg.org/patch/779/ [04:50:53] <Dark_Shikari> fix it, I don't know about inline asm [04:51:09] <Jumpyshoes> i don't know anything about inline asm either [04:51:49] <Jumpyshoes> HAVE_AVX should also probably be under HAVE_SSE [04:52:39] <Jumpyshoes> sadly my computer enjoys hanging while compile ffmpegso i'll have to wait before i see if this actually compiles or not [04:58:28] <Jumpyshoes> BBB: http://ffmpeg.pastebin.com/6VwjvM5C well apparently the other patch doesn't even apply to updated [05:05:53] <Jumpyshoes> how does GPL work? if i modify the GPL'd code in ffmpeg who does it belong to (e.g. avx)? in other words, can i LGPL holger's code without the original LGPL'd? [05:06:12] <Jumpyshoes> er, LGPL the modified code* [05:06:37] <kierank> no [05:06:44] <kierank> your work is derived from his [05:06:53] <Jumpyshoes> hrm, okay [05:08:57] <Jumpyshoes> hrm, what happens if i hypothetically want to keep the code GPL'd? since i modified it, but the original would be LGPL'd? [05:10:00] <Dark_Shikari> you can make your modifications GPL [05:10:11] <Jumpyshoes> i see [05:14:42] <Jumpyshoes> a quick test with that patches seems to indicate it works [05:32:53] <Jumpyshoes> btw, ssh to a linux sandy bridge machine would be greatly appreciated [05:33:01] <astrange> it would be annoying to maintain HAVE_GPL changes scattered in something else [05:33:30] <Jumpyshoes> holger hasn't LGPL'd his code yet [05:34:44] <Jumpyshoes> could someone modify LGPL'd code and GPL the modifications? [05:34:58] <kierank> yes [05:35:03] <Jumpyshoes> this is complicated [05:36:51] <Dark_Shikari> You can make LGPL code into GPL like that [05:36:53] <Dark_Shikari> you can't make GPL code into LGPL [05:36:56] <Dark_Shikari> simple as that. [05:37:26] <Jumpyshoes> oh [05:38:02] <kierank> someone should take over fsf and make gplv4 into a public domain licence [05:40:03] <pengvado> and you can do it because LGPL specifically says that anyone can reliscence any LGPL code to GPL at will, whether or not they contributed to it [05:41:32] <Jumpyshoes> interesting [05:42:22] <Jumpyshoes> i should probably read the LGPL and GPL at some point [05:42:47] <Sean_McG> teh evil viral licensing [05:43:33] <Sean_McG> s/viral/invasive/ [05:45:43] <Jumpyshoes> well i do write code under it [05:45:48] <Jumpyshoes> without actually knowing what it does [05:46:05] <Sean_McG> it will eat your soul [05:49:54] <YHLEE> Should I talk to #ffmpeg about source code under libavcodec? I did but there is no response. [05:52:28] <Jumpyshoes> if it's development probably here [05:52:37] <_av500_> j-b: ? [05:52:39] <Jumpyshoes> if you sent something to the mailing list, pinging it is a good idea [05:53:14] <YHLEE> ok, thanks. [05:53:44] <Jumpyshoes> also pinging the appropriate people on IRC [06:30:19] <elenril> morning [06:30:35] <elenril> any patch monk^w^wcommitters around? [07:31:26] <cartman> moin [07:32:37] <Tjoppen> morrn [07:48:23] <spaam> God morgon [08:14:56] <peloverde> Is anyone else waiting on stuff from me? I think my personal queue is pretty low [08:20:23] <spaam> good fast ffaacenc ? [08:22:21] <peloverde> you guys wanted that? I've been sitting on it for months [08:24:41] <spaam> Nice.. maybe you can share it ? :D [08:25:00] <pJok> ohayou gozaimasu [08:45:37] <KotH> hoi zäähmmmme.. [08:46:33] <JEEB> pretty ANSI [08:49:59] <kshishkov> KotH: today I had no chocolate to eat except LÃ€derach :( [08:50:23] <KotH> lol [08:51:24] <kshishkov> KotH: what's the name of decent choco from .ch? [08:56:44] <KotH> lindt? sprüngli? callier? maestrani? [08:59:07] <siretart> I often see lindt chocolate in german shops; I'm not aware of the others, though [09:03:46] <kshishkov> KotH: once I had Lindt&SprÃŒngli chocolate [09:05:25] * KotH is baffled [09:05:28] <KotH> how come? [09:05:42] <kshishkov> what? [09:06:33] <cartman> wut? [09:08:29] * kshishkov wonders what KotH can say about Migros [09:08:39] <cartman> kshishkov: it lets you buy online [09:08:42] <cartman> I <3 that [09:12:11] <KotH> kshishkov: cheap but edible [09:14:47] <cartman> works online!!11!! [09:14:56] <cartman> KotH: do you have Migros over there? [09:15:08] <KotH> lol [09:15:25] <kshishkov> cartman: why do you think KotH moved close to its HQ? [09:15:31] <KotH> cartman: http://en.wikipedia.org/wiki/Migros [09:15:35] <KotH> cartman: read and learn! [09:16:13] <cartman> whoa [09:16:15] <cartman> bastards [09:17:21] <kshishkov> KotH: did you mean http://en.wikipedia.org/wiki/Migros_T%C3%BCrk ? [09:17:42] <cartman> ahha [09:18:26] * cartman in other news /me finally resigned this Monday [09:18:34] <KotH> \o/ [09:19:10] <cartman> I'll be "Gururumuzsun Åaban" [09:19:11] <cartman> :p [09:27:51] <cartman> wbs: you do compile ffmpeg for WinCE?! [09:28:11] <wbs> cartman: I've got a build-only fate running in a screen to catch build regressions [09:28:20] <cartman> wbs: nice :) [09:28:31] <cartman> wbs: are you using wcecompat? [09:28:55] <wbs> cartman: umm... not that I know :-) I only use mingw32ce and a bunch of hacks to the headers [09:29:03] <cartman> ah mingw32ce [09:29:06] <cartman> cool cool :) [09:29:32] <wbs> I haven't actually run it on neither devie nor emulator for literally ages, but it's good to make sure it still builds at least [09:29:52] <wbs> who knows if WP7 eventually will allow native code, making it relevant again [09:29:53] <cartman> wbs: I did run ffmpeg successfully back in the day [09:29:57] <cartman> ffplay is harder [09:30:24] <wbs> yeah, ffmpeg worked fine for me, too, and I wasn't building a player, so ffplay was irrelevant for me, as long as libavcodec worked :-) [09:30:35] <cartman> :> [09:31:01] <cartman> WP7 is Dead On Arrival :> [09:31:16] <wbs> yeah, and I hope it would just die silently [09:31:23] <wbs> but you never know when the undead returns [09:31:26] <cartman> just like Kin :D [09:31:30] <cartman> The Walking Dead! [09:31:54] <kshishkov> well, since they explicitly prohibit GPLv3 and similar stuff, no VLC there for sure [09:40:16] <Dark_Shikari> https://people.xiph.org/~greg/opus0.html what an awesome troll [09:41:53] <kshishkov> but it's easy! [09:42:12] <cartman> fp3s=(((3-(config&3))*13&119)+9>>2)*((config>13)*(3-((config&3)==3))+1)*25 [09:42:15] <cartman> easy? [09:42:22] <kshishkov> the easiest [09:42:49] <Tjoppen> fun! [09:42:56] <cartman> spaghetti [09:43:19] <Tjoppen> does it make full use of the bits though? [09:43:47] <JEEB> lol'd [09:44:01] <pross-au> opus is the new name for celt? [09:44:06] <Dark_Shikari> opus = celt + silk [09:44:21] <Dark_Shikari> thank skype [09:44:26] <kshishkov> i.e. three codecs we don't support [09:44:31] <pross-au> Yet! [09:45:12] <pross-au> To be frank, speex en/decoder would be more useful [09:45:31] <kshishkov> uhm, write one [09:45:34] <Dark_Shikari> CELT would be useful! And don't call me Frank. [09:45:48] <kshishkov> pross-au: once I volunteered and got RTMP instead [09:45:54] * cartman wonders what codec Google Talk uses [09:45:55] <pross-au> LOLZ [09:46:02] <Dark_Shikari> gtalk uses vidyo [09:46:07] <Dark_Shikari> for video [09:46:09] <Dark_Shikari> i.e. svc [09:46:17] <kshishkov> heh [09:46:28] <kshishkov> do they use x264 for encoding? [09:46:32] <Dark_Shikari> no, they use vidyo [09:47:15] <astrange> did speex get adopted anywhere that can't just move to opus? [09:47:33] <cartman> some h.264 variant? [09:47:34] <kshishkov> astrange: they bothered to write a spec [09:48:21] <cartman> vidyo.com it is [11:13:45] <Kovensky> 08:12.34 LLStarks: it really shocks me how microsoft has to make everything they touch so bulky [11:13:48] <Kovensky> 08:12.55 LLStarks: why can't they do lightweight, no-nonsense compilers like gcc/g++? [11:17:52] <roxfan> haha [11:20:17] <Kovensky> not defending microsoft here but the line directed at g++ is hilarious indeed :D [11:36:54] <lu_zero> Kovensky: you'd point clang as no-nonsense C++ compiler? [11:37:25] <thresh> kshishkov: so you Swedes wanted to break the duumvirate of our Shmele and Krabbe [11:38:27] <cartman> lu_zero: clang is a pretty sensible compiler [11:40:43] <kshishkov> thresh: ? [11:41:10] <kshishkov> thresh: who cares about your chekist and his nanopuppet? [11:41:47] <thresh> kshishkov: apparently Swedes do :) [11:41:58] <thresh> http://lenta.ru/news/2011/02/17/wedge/ [11:44:20] <kshishkov> thresh: just name a country that loves Russia [11:45:13] <thresh> kshishkov: *ahem*ukraine*ahem* [11:45:55] <kshishkov> thresh: *ahem*Western part?*ahem* [12:07:34] <CIA-15> ffmpeg: Young Han Lee <cpumaker(a)gmail.com> master * r979395bbbb ffmpeg/libavcodec/mdct.c: [12:07:34] <CIA-15> ffmpeg: mdct: remove unnecessary multiplication [12:07:34] <CIA-15> ffmpeg: 3*n4 was already calculated in n3. [12:08:15] <elenril> mru: can you commit the last lavf rename+api bump? [12:11:15] <siretart> is that a ping for "the big bump"? ;-) [12:11:52] <kshishkov> seems so [12:13:01] <elenril> not yet [12:13:19] <kshishkov> :( [12:13:21] <elenril> but Soon(tm) [12:13:32] <elenril> kshishkov: why don't you go help [12:17:39] <elenril> somebody should write a checklist of what's missing for the bump [12:18:02] <mru> elenril: consider yourself volunteered [12:18:16] * elenril has an exam in a few hours [12:18:23] <mru> so do it after [12:18:29] <mru> or during [12:19:46] <thresh> or instead [12:20:26] <mru> elenril needs to get his priorities straightened out [12:20:35] <kshishkov> on a rack? [12:21:38] <Kovensky> 08:36.55 lu_zero: Kovensky: you'd point clang as no-nonsense C++ compiler? <-- I don't know it enough to do so, but that'd be the closest one I guess [12:22:09] <mru> non-nonsense and c++ are mutually exclusive [12:22:48] <Kovensky> mru: I said "closest" =p [12:23:13] <mru> if closeness is measured in parsecs... [12:23:23] <Kovensky> why not? :) [12:24:05] <lu_zero> mru: or in nanometers [12:24:18] <lu_zero> still too far no matter the unit [12:24:24] <lu_zero> (and the fraction) [12:33:15] <jannau> please don't push to git.ffmpeg.org, I'm working on the patchwork update hook [12:34:05] * elenril goes to push to videolan instead [12:35:15] <mru> jannau: you could disable the auto-push to patchwork in the meantime [12:35:28] <Kovensky> 09:31.40 TheFluff: the usual libavformat behavior when asked to seek to point x is to seek to point y (which is nowhere near x) and then tell you that you are at point z (which isn't near anywhere point x either) [12:36:10] <mru> jannau: please don't push the avutil.h inclusion patch from stefano [12:36:33] <mru> it isn't needed [12:36:42] <jannau> mru: I'm working on eliminating that [12:36:50] <mru> eliminating what? [12:37:00] <mru> the patch does nothing useful [12:37:03] <jannau> mru: ok, it was going to be my test push [12:37:18] <mru> find another one [12:37:25] <elenril> push my patches [12:37:27] <jannau> eliminating the explicit push to patchwork [12:37:37] <jannau> elenril: are they reviewed? [12:37:46] <elenril> one of them is [12:37:51] <elenril> the other one is just a bump [12:38:57] * elenril is talking about 4/5 and 5/5 in 'lavf api cleanup' thread [12:41:31] <wbs> gah for users reusing one single bug entry for everything they want to talk about [12:42:03] <wbs> as in "when doing <foo>, the program crashes" "-fixed, doesn't crash any longer" "no, not fixed! doing <foo> doesn't work yet!" [12:42:35] <cartman> wbs: join the club [12:42:39] <cartman> Resolved->WorksForMe [12:44:42] <BBB> lu_zero: did you push the rtsp change yet? I don't see it in -commits [12:45:17] <BBB> elenril: I'll queue the avio prefix to get/put today, just want to review it carefully, it's a big change :) [12:47:10] <mru> BBB: trust the sed [12:48:13] <lu_zero> BBB: I try to queue up patches and push them by 12h later [12:50:16] <spaam> kshishkov: we got 60 33cl cans of trocadero at work today :D [12:50:42] <kshishkov> spaam: good for you [12:50:47] <spaam> yes : ) [12:51:17] <cartman> http://en.wikipedia.org/wiki/Trocadero_(drink) this is it? [12:51:30] <spaam> yes [12:51:44] <cartman> looks boring :D [12:52:02] <andoma> cartman: looks awesome [12:52:07] <andoma> we got it here as well [12:52:14] <cartman> interesting [12:52:15] <spaam> andoma: \o/ [12:52:26] <kshishkov> andoma: unfortunately not here :( [12:54:36] * mru does not get it [12:54:45] <mru> it's just another stupid soft-drink [12:54:52] <kierank> kshishkov: have you tried irn-bru [12:55:11] <kshishkov> mru: just remember I don't drink beer [12:55:20] <mru> you could start [12:55:30] * cartman doesn't like beer [12:55:40] <mru> cartman: that's a very broad statement [12:55:47] <cartman> any $beer [12:55:49] <mru> you might as well say you don't like food [12:55:57] <kshishkov> kierank: of course not [12:56:25] <kierank> kshishkov: irn-bru is close to being a religion in scotland [12:56:41] <kshishkov> mru: I like food but I don't drink beer, so what? [12:56:57] <mru> it's your choice [12:56:58] <kshishkov> kierank: well, the same can be said about Trocadero and Northern Sweden [12:57:35] <kierank> you're missing out [12:57:56] <kshishkov> mru: indeed, maybe that's the reason I prefer countries with stricter alcohol selling regulations [12:58:24] <mru> my point is that the difference between cheap beer and good beer is as large as that between a kebab of the dodgiest kind and a fine meal in a 3-star restaurant [12:58:45] <kshishkov> I can believe that [12:59:04] <cartman> mru: then the definition of a good beer is needed [12:59:06] <kshishkov> but good luck actually finding that beer in some countries [12:59:27] <mru> kshishkov: try one with less strict alcohol regulations [12:59:43] <mru> hi Jumpyshoes [12:59:49] <Jumpyshoes> hi mru [12:59:59] <kshishkov> mru: I'm living in one of those, but trying to move you-know-where-to [12:59:59] <mru> we were just discussing beer, but I guess you're not allowed to have opinion :) [13:00:12] <Jumpyshoes> no, unfortunately [13:00:21] <Jumpyshoes> not legally at least [13:00:28] <mru> that's what I meant [13:00:53] <cartman> You can own a gun at 18, can't drink beer until 24 [13:01:04] <mru> cartman: 24, where? [13:01:05] <Jumpyshoes> 21 in the unted states [13:01:16] <cartman> in Turkey of course [13:01:18] <mru> Jumpyshoes: is that federal law or per state? [13:01:33] <Jumpyshoes> i believe it is federal... let me check [13:01:41] <mru> not important [13:01:45] <kshishkov> probably not for Southerners [13:01:51] <mru> and they're _very_ strict about it too [13:02:08] <mru> I'm 30 and I have to show ID more often than not in the states [13:02:16] <cartman> :> [13:02:20] <mru> in europe that never happens [13:02:22] <kshishkov> that's the whole idea about USA [13:02:27] <twnqx> lol [13:02:29] <mru> the land of the free [13:02:31] <Jumpyshoes> The National Minimum Drinking Age Act of 1984 states that revenue will be withheld from states that allow the purchase of alcohol by anyone under the age of 21. <-- figures, it's a mandate [13:02:41] <kshishkov> mru: as long as they can track you [13:02:50] <twnqx> lol, 21 [13:03:13] <lu_zero> Jumpyshoes: then you should spend some time in europe to try some [13:03:15] <twnqx> yeah, drinking alcohol takes SO MUCH more responsibility than driving a car or owning a gun. [13:03:23] <mru> in sweden it's 18, but you have to be 20 to buy it yourself in the shop [13:03:30] <Jumpyshoes> lu_zero: buy me a plane ticket :P [13:03:32] <lu_zero> possibly one of the Troll beers [13:03:42] <Jumpyshoes> has anyone had the issue in cygwin where yasm in the path but ffmpeg's configure cannot find it? version is ok [13:03:44] <mru> troll beer is good [13:04:02] <kshishkov> mru: but you liked Bink beer most [13:04:08] <mru> that's for you [13:04:17] <mru> I don't think I actually tried it [13:04:21] <lu_zero> mru: when you'll get there I'll make sure you sample all of them [13:04:40] * mru should schedule a tour of italy some time [13:04:56] <lu_zero> (easier than make Koth sample all the chocolate made here) [13:05:32] <mru> when does the weather get nice in italy? [13:05:53] <lu_zero> now it's a mix up of autumn and winter [13:06:07] <mru> I'd prefer a spring/summer mix [13:06:12] <lu_zero> and depends on your nice and which part of Italy [13:06:26] <lu_zero> spring should be fine [13:06:45] <lu_zero> summer can get too hot... [13:07:19] <mru> I prefer if it doesn't go too much above 30 [13:07:21] * kshishkov would like to spend summers around LuleÃ¥ [13:07:37] <mru> kshishkov: that region sometimes has the warmest temperatures of all sweden [13:07:42] <mru> in summer [13:07:52] <kshishkov> Kiruna then [13:08:14] <lu_zero> Sweden in summer seems interesting [13:08:34] <DonDiego> mru: try spring or autumn then, summer will likely be too warm for you - and make sure to pass by sardinia and visit stefano, it's a beautiful island [13:08:48] <Jumpyshoes> http://ffmpeg.pastebin.com/kSEEvzrK error in config.log [13:08:55] <kshishkov> DonDiego: how's the fish there? [13:09:19] <DonDiego> good [13:09:20] <mru> DonDiego: I'll survive warmer weather, but I prefer it slightly cooler [13:09:29] <DonDiego> spring then [13:09:42] <mru> depends on amount of physical activity involved too of course [13:09:52] <cartman> KotH: http://alkislarlayasiyorum.com/icerik/1685/kendimle-oynuyorum [13:10:13] <cartman> LOL [13:10:17] <lu_zero> april could be fine even if rainy here and there [13:10:34] <lu_zero> and you might enjoy the civil war if you come by before the 6th [13:10:35] <kshishkov> are your trains puctual? [13:12:06] <Flameeyes> kshishkov: not really [13:13:33] <BBB> lu_zero: ok, no rush, just wanted to make sure ;) [13:13:44] <kshishkov> I heard that in Serbia people actually complained when train came on time (usually it was ~2hrs late) [13:14:42] <lu_zero> Flameeyes: depends on the region mostly and on the line ^^ [13:15:20] <Flameeyes> popquiz: H.264 and AAC are defined as a standard, aren't they? what should I reference when stating so? :P [13:15:42] <Flameeyes> lu_zero: the Frecciarossa with 15% lateness is emblematic [13:17:04] <lu_zero> Fecciarossa you mean? [13:17:12] <kshishkov> Flameeyes: MPEG-4 [13:17:35] <cartman> while you are there explain what is MPEG-2 too [13:17:37] <Flameeyes> kshishkov: yeah up there I reached :) part 10 for H.264 ain't it? â my problem is actually finding which document to reference :) [13:18:34] <kshishkov> Flameeyes: ISO/IEC 14496 - Coding of audio-visual objects [13:18:40] <Flameeyes> kshishkov: thanks [13:18:48] <Flameeyes> both of them there? [13:19:08] <kshishkov> yes, part 3 AAC, part 10 - H.264 [13:19:24] <Flameeyes> kshishkov: :* you saved me from hours of digging around [13:19:35] * kshishkov looked at http://en.wikipedia.org/wiki/MPEG-4 [13:19:36] <mru> Flameeyes: "ITU-T Rec H.264 | ISO/IEC 14496-10" [13:20:08] <mru> aac is ISO/IEC 14496-3 [13:20:28] <mru> and parts of it ISO/IEC 13818-7 [13:20:28] <kshishkov> both are extremely heavy paper bricks [13:20:54] <cartman> ISO/IEC 13818 [13:20:58] <cartman> part 7 is AAC too [13:21:00] <cartman> it seems [13:21:07] <cartman> ah mru already mentioned it ;) [13:21:40] <kshishkov> it's just a core AAC encoder without all those enhancements [13:22:12] <mru> it corresponds mostly to one of the subparts of 14496-3, forgot which one [13:22:30] <mru> and the headers are subtly different [13:22:36] <mru> all very annoying [13:23:00] <kshishkov> subpart 4 [13:34:21] <jannau> nice graph: https://github.com/FFmpeg/ffmpeg/branches showing how outdated the release branches are [13:38:57] <lu_zero> where is the aacenc from google? [13:39:12] <kshishkov> in android sources [13:39:25] <kshishkov> but it's from 3GPP and VisualOn2 [13:40:03] <lu_zero> kshishkov: android sources is too wide ^^; [13:40:31] <kshishkov> libstagefright/codecs/aacenc [13:40:40] <kshishkov> in base/media [13:41:12] <lu_zero> which git? [13:41:22] <wbs> frameworks/base [13:41:39] <lu_zero> found =) [13:41:41] <lu_zero> thank you [13:52:45] <cartman> http://nokiaplany.com/ lol [14:08:25] <lu_zero> uh [14:08:38] <lu_zero> the voaacenc doesn't seem working... [14:09:21] <wbs> lu_zero: it worked for me, I tried wrapping it up to a standalone library in december [14:09:32] <kshishkov> any symptoms? [14:09:41] <wbs> lu_zero: but it needed a bit of tweaking, which I've submitted to the android review system [14:10:37] <lu_zero> adjustPeMinMax [14:10:48] <lu_zero> it gives me a nice division by 0 [14:10:56] <lu_zero> wbs: it took me just [14:11:11] <lu_zero> gcc -g -O2 -DLINUX -Icommon/include -Iaacenc/inc/ -Iaacenc/basic_op/ common/cmnMemory.c aacenc/basic_op/*.c aacenc/src/*.c aacenc/SampleCode/AAC_E_SAMPLES.c -o voaacenc [14:11:31] <kshishkov> and were you trying to encode? [14:12:23] <wbs> lu_zero: hmm, ok.. are you on 64 bit? [14:14:48] <Flameeyes> interesting, at least a small set of Microsoft's extensions to RTSP would make sense to implement on feng/ffmpeg as well.. [14:19:00] <wbs> Flameeyes: which parts? [14:19:21] <Flameeyes> wbs: for once, the SDP extensions making it clear whether a resource can be seeked on or not [14:23:10] <lu_zero> wbs: yup [14:23:20] <wbs> lu_zero: you could try https://github.com/mstorsjo/vo-aacenc and the vo-aacenc branch from https://github.com/mstorsjo/ffmpeg [14:23:37] <wbs> lu_zero: the code is really broken on 64 bit originally [14:23:41] <lu_zero> ah [14:24:04] <wbs> like this one: https://github.com/mstorsjo/vo-aacenc/commit/62dc5f79a968780a414f4a010bbdfb… [14:26:47] <Flameeyes> lu_zero: theora's rtp draft on ietf? [14:28:17] <lu_zero> http://tools.ietf.org/html/draft-barbato-avt-rtp-theora-01 [14:28:22] <Flameeyes> thanks [14:32:43] <lu_zero> wbs: did you try using ffmpeg memory functions ? [14:33:20] <wbs> lu_zero: yeah, it probably is doable, but they don't fit the required signature right away, so they'd need some local wrapper functions for that case [14:36:40] <lu_zero> meh [14:42:18] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rab0287fcbd ffmpeg/ (10 files in 3 dirs): [14:42:18] <CIA-15> ffmpeg: Move find_info_tag to lavu and add av_ prefix to it [14:42:18] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [14:42:29] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r09d171b988 ffmpeg/ (doc/APIchanges libavformat/version.h libavutil/avutil.h): [14:42:29] <CIA-15> ffmpeg: lavf, lavu: bump minor versions and add an APIChanges entry for av_ prefixes [14:42:29] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [14:46:17] <Flameeyes> jannau: remind me later tonight to re-execute my scripts to see what remains to be fixed :) [14:58:15] <{V}> wbs, is Dave the verifier/reviewer for aacenc in platform/frameworks/base ? 'cause if not, maybe the process will be faster if you contacted a different one (judging by his pattern of recently closed code reviews) [14:58:46] <wbs> {V}: I'm not sure actually, I think he reviews stagefright stuff in general at least [14:58:59] <wbs> {V}: where would I find who's better suited for reviewing it? [15:00:46] <cartman> find-googler.sh [15:01:34] <cartman> The other day my boss found someone from Google, [15:01:37] <cartman> a Sr. Engineer [15:01:51] <cartman> asked him to find someone to fix the bug I reported against NDKr5 [15:01:58] <cartman> the guy came back with this answer [15:02:20] <cartman> "I can't find anyone inside Google responsible for this. I think this is an open source project?" [15:02:20] <{V}> wbs, not sure, but Jean-Baptiste Queru and Brad Fitzpatrick were recurring names as verifier and reviewer for the code reviews that were listed as closed in Dave's list of recently closed. [15:03:42] <wbs> {V}: hmm, ok [15:14:42] <BBB> astrange: does this mean you call ff_thread_finish_setup() twice? is that bad? [15:17:35] <cartman> http://thedailywtf.com/Articles/Genital-Syncing,-Accentricity,--More-Suppor… awesome [15:24:13] <thresh> http://www.asymco.com/2011/02/11/in-memoriam-microsofts-previous-strategic-… [15:32:24] <lu_zero> bilboed-tp: I have to go now, when I'm back I'd like to try setting up a bit a test environment for compatibility and such [15:33:08] <bilboed-tp> neat [15:34:04] <lu_zero> brb [15:39:37] <superdump> test environment for what? [15:39:56] <bilboed-tp> rtp [15:45:54] <Flameeyes> and rtsp I guess as well :) [15:55:57] <BBB> it'd be nice to test that in fate, yes [15:56:30] <Flameeyes> BBB: if you find me a reliable way to test rtsp/rtp I'm going to build you a statue! [15:56:46] <BBB> not quite on the top of my list, but a statue sounds nice [15:56:52] <BBB> can you put that on paper and sign it? [15:58:23] <Flameeyes> how do I use gpg with paper? [15:58:41] <mru> scan, process, print? [15:59:48] <elenril> Flameeyes: read the daily wtf link above [15:59:50] <Compn> Flameeyes : you dont like the reliableness of the rtsp urls in the wiki page ? [15:59:55] <Compn> ehe [16:00:07] <Flameeyes> Compn: I have a server to test with such a method :P [16:00:49] <Compn> Flameeyes : didnt someone suggest to just wireshark record the connections [16:00:52] <Compn> and then play those back ? [16:01:09] <Compn> maybe that wouldnt work so well either :P [16:01:12] <Flameeyes> Compn: not sure if somebody suggested that [16:01:18] <Flameeyes> but I'm quite sure it won't work too well [16:03:07] <Kovensky> 12:17.36 cartman: http://thedailywtf.com/Articles/Genital-Syncing,-Accentricity,--More-Suppor… awesome <-- better version of cartman's link: http://thedailywtf.com/Articles/Genital-Syncing,-Accentricity,-and-More-Sup… [16:06:11] <spaam> Kovensky: same link? [16:06:17] <Kovensky> spaam: nope [16:06:26] <spaam> aah [16:06:30] <Kovensky> his is "--More", mine is "-and-More" [16:06:31] <spaam> --and- [16:06:34] <spaam> yeah. [16:37:53] <kierank> spaam: shall I delete basty's amiga stuff in /incoming [16:38:01] <av500> +1000000000000 [16:38:42] <kierank> av500: your friend avcoder is reporting bugs [16:38:55] <spaam> kierank: how big is it ? :D [16:39:14] <kierank> 6MB [16:39:44] <spaam> thats nothing.. we should save it [16:40:15] * elenril summons some committers [16:40:29] <elenril> fix the commit hash in APIChanges [16:41:16] <av500> kierank: er, what? [16:41:38] <kierank> av500: don't you remember, avcoder is your buddy [17:12:56] <mru> hmm, av_bswap32(AV_RL32("TTA1")) [17:16:52] <lyakh> mru: hi, you haven't found time for that mpegaudio patch, that we talked about, yet? [17:17:05] <mru> lyakh: not yet, sorry [17:17:30] <mru> but once I finish what I'm working on now, it's next on my list of paid jobs [17:18:03] <lyakh> mru: ok, can you kick me, when you post it? I can easily miss in on the list, and using "CC" is not a popular behaviour on ffmpeg... [17:18:18] <mru> I'll keep you informed [17:18:28] <lyakh> mru: cool, thanks! [17:19:46] <BBB> Dark_Shikari: so I'm all for making this stuff faster, but it's a lot of work, I can commit in small steps right? e.g. right now I have this patch that transposes dc/ac coeffs while parsing them, that can safely be committed independently while I work on the bigger stuff? [17:20:10] <BBB> Dark_Shikari: because it's gonna involve a little more, and I'll likely split out the dsp stuff into a vc1dspcontext to make it easier to work with [18:06:48] <elenril> BBB! [18:07:09] <mru> ~curse gcc [18:07:27] <mru> now it's insisting that string literals aren't lvalues [18:07:48] <mru> the spec clearly says they are: "A string literal is a primary expression. It is an lvalue with type as detailed in 6.4.5." [18:10:07] <BBB> elenril: put/get avio prefix? :-p [18:10:15] <elenril> =p [18:10:15] <BBB> elenril: or something else? [18:10:18] <elenril> yes [18:10:31] <BBB> sorry, got distracted by vc1 [18:10:35] <elenril> and somebody fix the commit hash in apichanges [18:10:37] <BBB> it's a bad habit to work on game codecs [18:10:45] <BBB> they are irrelevant yet so much work to do to optimize the [18:10:47] * lu_zero is back [18:10:47] <BBB> +m [18:10:49] <elenril> vc1 is a game codec? [18:10:56] <BBB> fringe codec is a better description [18:11:19] <mru> isn't windows a game? [18:11:29] <lu_zero> windows has lots of games indeed [18:14:32] * j-b would suggest another patch to reimar [18:16:20] * mru would patch reimar [18:16:32] <j-b> git rm MAINTAINERS [18:16:37] <mru> +1 [18:17:59] <j-b> As Mr. Colbert said it at the closing conference of FOSDEM: "maintainership doesn't mean ownership [...] of a file" [18:18:29] <j-b> "if you want ownership, [...] do not contribute to open source" [18:23:55] <spaam> j-b: do you guys have a MAINTAINERS file in vlc? [18:24:26] <j-b> spaam: I am quite sure we removed it 3 y ago [18:24:57] <spaam> ok :) [18:25:13] <lu_zero> j-b: who should I nag about vlc mpegts? [18:25:28] <j-b> lu_zero: in or out ? [18:25:40] <lu_zero> both [18:25:50] <j-b> Meuuh [18:26:14] <lu_zero> I helped setting up a strange contraption in which vlc is the key redistributor [18:26:27] <lu_zero> gets mpegts in, serves mpegts around [18:27:07] <lu_zero> problem -> now I'm adding a data stream in mpegts [18:27:41] <mru> am I stupid or are gcc commit messages totally incomprehensible? [18:27:46] <lu_zero> and that isn't something ffmpeg manages that well (almost fixed) [18:28:01] <lu_zero> mru: you aren't stupid, usually, which are those messages? [18:28:10] <mru> most of them [18:28:13] <lu_zero> then will be the turn of vlc... [18:28:20] <j-b> lu_zero: can you mail me about that ? [18:28:27] <mru> * file.c (blurb): gibberish [18:28:39] <lu_zero> sure [18:28:47] * j-b needs to go [18:28:50] <lu_zero> possibly vlc already does the right thing ^^ [18:30:00] <kierank> lu_zero: what kind of data stream are you adding [18:36:29] <dalias> mru, find anyone for my arm port? :) [18:47:44] <lu_zero> kierank: random text data [18:48:06] <lu_zero> the application will send some kind of control stamps [18:48:42] <lu_zero> I'm thinking about suggesting that to embed gps coordinates [19:30:54] <elenril> BBB: don't commit avio yet [19:31:08] <elenril> found some functions i've missed [19:31:13] <elenril> will send new patch in a sec [19:35:07] <BBB> ok [19:35:10] <elenril> done [19:35:15] <elenril> commit at will [19:35:21] <elenril> (sooner is better ;) ) [19:37:02] <elenril> spring cleaning came early this year [19:38:25] <BBB> uh, I'm splitting dspcontext further [19:38:29] <BBB> cleaning isn't 1% done yet [19:39:04] <elenril> urlcontext should be considered public too? [19:40:26] <elenril> mpd and mplayer use it => i guess yes [19:41:02] <elenril> hmm....AVURLContext doesn't look very pretty [19:45:50] <BBB> it doesn't have to be pretty [19:45:54] <BBB> just has to work [19:46:04] * elenril prefers pretty things [19:46:05] <lu_zero> question [19:46:22] <BBB> hm, I guess that's a mis-statement [19:46:22] <lu_zero> why avcodec should do something complex with timestamps? [19:46:23] <elenril> i was surprise how pretty AVIOContext looks [19:46:29] <elenril> *surprised [19:46:33] <mru> lu_zero: you know the answer [19:46:37] <BBB> elenril: fine with me also [19:46:43] <mru> lu_zero: discussion is pointless [19:46:43] <BBB> lu_zero: I'm gonna ignore the trollthread [19:46:44] <BBB> enough [19:46:58] <elenril> why should avcodec do _anything_ with timestamps [19:47:03] <BBB> it's all the same, I'm ignorant, I don't know what I'm talking about, I should be ashamed about myself [19:47:21] <BBB> by somebody's joke I could certainly be advised to hang myself [19:47:25] <BBB> and have a foundation pay for my funeral [19:47:28] <mru> elenril: it should of course provide reordering from input to output picture [19:47:28] <BBB> bla bla bla [19:47:34] <mru> but that doesn't need to be tied to timestamps [19:47:59] <lu_zero> BBB: ignore the trolls and let's try to think about the problem at hand [19:48:08] <mru> lu_zero: nicolas _is_ a troll [19:48:10] <BBB> lu_zero: I'll leave it for a week and get back to the problem [19:48:17] <BBB> lu_zero: I don't want to think about it right now [19:48:19] <lu_zero> mru: he is French and stubborn [19:48:26] <lu_zero> ok =) [19:48:26] <mru> let's get the release out, then we'll deal with the timestamps [19:50:15] <elenril> much work is left before the release [19:50:31] <mru> yes, that's why we should focus on that [19:54:03] <BBB> how do I git send-email some but not all of my patches? [19:54:18] <BBB> e.g. I have 4 patches in my tree, 1 was approved already, I want to send 2-3 for review and not 4 [19:54:32] <elenril> git send-email HEAD^ -2 [19:54:52] <BBB> awesome [19:54:52] <BBB> thanks [19:54:57] <BBB> I tried -3 HEAD^ [19:55:05] <BBB> but that didn't do what I thought it would (I thought it'd be a range) [19:55:08] <lu_zero> elenril: .. isn't needed anymore? [19:55:18] <elenril> this is not a range...i think [19:55:23] <elenril> it's a different kind of magic [19:57:33] <mru> -<number> <ref> sends email for $number commits ending at $ref [19:57:37] <mru> iiuc [19:57:56] <BBB> -3 HEAD^ only sent out one email [19:57:58] <lu_zero> block[k][i + j*8] is 0-255 ? [19:58:15] <BBB> no, they're DCTElem, so int16_t [19:58:44] <BBB> kshishkov: please review more patches [19:59:01] <elenril> what's URLPollEntry? i don't see it used outside avio.h [19:59:37] <BBB> is it used in any C file? [20:00:18] <elenril> i don't see it used outside avio.h [20:00:20] <BBB> probably old stuff that's deprecated now [20:00:30] <elenril> git blames Fabrice [20:00:31] <BBB> seems like a workaround for systems missing poll() [20:00:33] <elenril> committed in 2001 [20:00:37] <BBB> feel free to deprecate it [20:02:23] <lu_zero> uhmm [20:02:30] <lu_zero> might be useful [20:03:33] <lu_zero> (if implemented so we can poll for a group of url and the process if there is something for one of them) [20:03:42] <elenril> it's been untouched since 2001 [20:04:09] <lu_zero> elenril: feel free to remove it [20:04:10] <elenril> and we have too many 'might be useful someday in some fringe case if somebody implements it' things [20:04:17] <lu_zero> we could re-introduce it later [20:04:21] <elenril> right [20:04:41] * lu_zero was more or less making a mental note ^^; [20:09:16] <elenril> eew and wtf is URLInterruptCB [20:09:28] <elenril> this one seems to be used :/ [20:09:30] <ohsix> a callback for interruptions [20:09:56] <mru> funny thing btw, _my_ avi demuxer does nothing special at all with timestamps, yet I always get perfect sync [20:10:03] * elenril gives ohsix a CaptainObvious award [20:10:05] <mru> unless the file is bad of course [20:16:53] <BBB> elenril: that's disgusting, but leave it for now [20:17:12] <BBB> elenril: don't ask why or how, it's used and it's a necessary hack to prevent worser evils [20:17:50] <BBB> vc1dsp has funny idcts [20:18:02] <BBB> 7 out of 8 have a uint8_t *dst, int linesize argument [20:18:06] <BBB> oddly, the last one does not [20:18:40] <BBB> they're called idct_inv_trans_[48]x[48]{,_dc} [20:18:46] <BBB> very weird [20:19:08] <mru> the non-square transforms are weird [20:19:27] <BBB> haven't looked at them yet [20:19:43] <BBB> idct8x8 takes >15% of processing time, so I care most about that one [20:20:15] <mru> it's just a weird idea in general [20:20:40] <mru> never seen it anywhere else [20:25:07] <elenril> i recall some flames about init_put_byte name, but can't find them now [20:25:20] <BBB> jannau: you left some xxxxxx in APIChanges [20:25:45] * elenril already pointed that out two times =p [20:26:46] <jannau> yes, I forgot to git commit --amend before pushing and haven't felt like sending a patch for that [20:28:25] <BBB> jannau: honestly for APIChanges xxx->real you don't need to git send-email [20:35:47] <elenril> av_alloc_put_byte is confusing, any objections to renaming it to avio_alloc_context? [20:36:01] <elenril> (same will be done for init_put_byte) [20:40:50] <BBB> init_put_byte() does nothing put_*() specific right? [20:41:00] <BBB> i.e. a context for get_byte() would use init_put_byte() also? [20:41:25] <elenril> yes, i think so [20:41:29] <BBB> please don't forget to not clash with ByteIOContext anywhere [20:41:42] <BBB> avio_*() should be strictly for URL* stuff, to be renamed to AVIO maybe [20:41:46] <BBB> ByteIO != AVIO [20:41:49] <BBB> and that may be confusing [20:41:50] <mru> all the avio names are highly confusing [20:42:43] <BBB> kshishkov: ping [20:42:50] <elenril> ByteIO != AVIO << ?? [20:44:02] <elenril> maybe we should split off all the url_* into url.h [20:44:49] <BBB> you said you wanted to rename URLContext to AVIOContext [20:44:53] <elenril> no [20:44:55] <BBB> if you do that, ByteIOContext can't be AVIOContext [20:45:01] <BBB> which would be more logical [20:45:07] <elenril> i said i already renamed ByteIOContext into AVIOCOntext [20:45:08] <BBB> but anyway, maybe I misunderstood [20:45:11] <BBB> oh, ok [20:45:14] <BBB> that makes more sense [20:45:15] <elenril> it makes more sense to me [20:45:20] <BBB> what about URLContext/URLProtocol? [20:45:30] <elenril> i just added AV to them for now [20:45:37] <elenril> it doesn't look very nice though [20:45:38] <elenril> ideas? [20:46:02] <elenril> in any case, avio.h is getting cluttered imo [20:52:05] <BBB> avio.h has both ByteIOContext and URLContext stuff right? [20:52:08] <BBB> that can of course be split [20:52:19] <BBB> just like in .c files it's split in aviobuf.c and avio.c [20:58:47] <CIA-15> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * rc3dbfa1afd ffmpeg/doc/APIchanges: [20:58:47] <CIA-15> ffmpeg: Add SHA1s to APIChanges for av_dump_format, av_parse_time and av_find_info_tag [20:58:47] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:02:27] <BBB> jannau: thanks [21:05:16] * elenril wonders how well will git handle the split [21:05:32] <kshishkov> BBB: reviewed [21:08:06] <BBB> kshishkov: ty [21:08:08] <lu_zero> elenril: if the commit with that is a single one quite well [21:08:08] * BBB commits [21:10:13] <BBB> brb [21:19:56] <elenril> nah, it fails horribly [21:41:06] <astrange> 10:14 <@BBB> astrange: does this mean you call ff_thread_finish_setup() twice? is that bad? <- it's only called once, the if logic for that has gotten complex [21:41:32] <astrange> it would actually be harmless, but would do useless pthread_cond_broadcasts [21:42:10] <astrange> i found an unrelated hang on a vp3 file testing that... [22:14:44] <BBB> hang? that's bad :( [22:14:51] <BBB> astrange: is threading automatically enabled? [22:15:13] <BBB> astrange: e.g. let's say I use ./ffplay theorafile.ogg, does it automatically enable threading? [22:15:14] <BBB> ideally it would [22:16:01] <astrange> nope, we don't autodetect #cpus. it's a future todo [22:16:32] <astrange> also hold on that patch for a sec [22:17:39] <BBB> I'm not doing anything with the patch yet :-p [22:18:37] <BBB> hm [22:18:41] <BBB> make -j4 fate is kinda of cool [22:19:05] <BBB> of course if ffmpeg autodetects #cores, make -j4 fate becomes kinda useless [22:19:07] <BBB> dilemma [22:19:11] <CIA-15> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * rc2ca851b23 ffmpeg/ffserver.c: [22:19:11] <CIA-15> ffmpeg: ffserver: Try matching the RTSP url without a trailing slash [22:19:11] <CIA-15> ffmpeg: If the client sends PLAY/PAUSE requests with the same url as [22:19:11] <CIA-15> ffmpeg: specified in Content-Base, these requests may have urls with [22:19:11] <CIA-15> ffmpeg: trailing slashes. [22:23:06] <BBB> diff: tests/data/regression/lavfi/pixfmts_hflip_le: No such file or directory [22:23:06] <BBB> ? [22:25:44] <BBB> this is "make fate-lavfi-pixfmts_hflip_le" btw [22:28:49] <BBB> hm, make clean fixed it [22:28:50] <BBB> weird [22:30:57] <J_Darnley> <@BBB> of course if ffmpeg autodetects #cores, make -j4 fate becomes kinda useless <-- What? [22:31:03] <ruggles> well today has been fun... determining the formula for samples-per-frame for all the adpcm varieties. [22:35:18] <BBB> J_Darnley: fate basically runs a whole lot of ffmpeg commands. doing make -j4 fate runs several simultaenously, to make use of all your cores. if ffmpeg detects cores and does multithreading, guess what, make -j4 fate won't have as much effect as it used to have :-p [22:35:24] <BBB> hah, fate passed [22:36:14] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r1da6ea3954 ffmpeg/libavcodec/ (ppc/vc1dsp_altivec.c vc1.h vc1dec.c vc1dsp.c): VC1: transpose IDCT 8x8 coeffs while reading. [22:36:17] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r0b16cdc3fa ffmpeg/libavcodec/vc1dec.c: VC1: simplify a calculation in a loop. [22:36:18] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r12802ec060 ffmpeg/libavcodec/ (13 files in 3 dirs): dsputil: move VC1-specific stuff into VC1DSPContext. [22:36:52] <ruggles> BBB: how would that affect the seek tests? is there explicit dependency somewhere in the make file that would ensure acodec and lavf are run before the corresponding seek test? [22:37:10] <BBB> ruggles: I honestly have no idea [22:37:18] <BBB> I suppose so [22:40:14] <J_Darnley> BBB: Oh, for fate, right. I missed that bit [22:40:31] <J_Darnley> sorry [22:40:57] <BBB> oh, right, I can see how that sounds confusing without that bit [23:13:28] <Jumpyshoes> BBB: http://ffmpeg.pastebin.com/EH0L8ezd modified version of Dark_Shikari's avx patch that was never pushed, comments? [23:14:07] <mru> you didn't try compiling that [23:14:27] <Jumpyshoes> it compiled [23:14:40] <mru> then HAVE_AVX wasn't set [23:14:55] <mru> you're calling a macro with wrong number of arguments [23:15:00] <mru> that doesn't compile [23:15:08] <mru> let me see if I can fix it [23:15:43] <Jumpyshoes> hrm, /me checks if HAVE_AVX is set [23:17:15] <Jumpyshoes> oh [23:17:20] <Jumpyshoes> apparently HAVE_AVX isn't even defined [23:17:23] <Jumpyshoes> libavutil/x86/cpu.c:104:5: warning: "HAVE_AVX" is not defined [23:17:48] <mru> gimme a moment [23:17:55] <Jumpyshoes> okay [23:28:20] <CIA-15> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * reb3755a5aa ffmpeg/libavutil/ (arm/intmath.h common.h): [23:28:20] <CIA-15> ffmpeg: Force inlining of avutil common routines [23:28:20] <CIA-15> ffmpeg: On some versions of gcc, these weren't always getting inlined due to hitting [23:28:20] <CIA-15> ffmpeg: the inline cap limit in some files. This is generally bad, as most of these [23:28:20] <CIA-15> ffmpeg: functions are smaller inlined than not. [23:28:22] <CIA-15> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r7634771e70 ffmpeg/libavcodec/vp8.c: VP8: faster MV clipping [23:28:23] <CIA-15> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * rbcf4568f18 ffmpeg/libavcodec/ (vp8.c vp8.h vp8data.h): VP8: split out declarations to new header [23:28:24] <CIA-15> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r891b1f15a7 ffmpeg/libavcodec/vp8.c: [23:28:24] <CIA-15> ffmpeg: VP8: init one less near_mv [23:28:24] <CIA-15> ffmpeg: This one didn't actually need to be initialized. [23:31:31] <mru> who broke the build on ppc now? [23:33:53] <dalias> :) [23:34:37] <ruggles> mru: looks like it was BBB. shame shame. doesn't he have a login on saracen? [23:34:43] <mru> he does [23:35:21] <BBB> I will fix [23:36:08] <Jumpyshoes> does anyone have ssh to a linux sandy bridge? [23:36:18] <mru> not me [23:36:30] <mru> I'm hanging on to my i7 for a little longer [23:36:34] <BBB> Jumpyshoes: I thought you had that [23:36:40] <Jumpyshoes> i have access to a cygwin, but it can't detect yasm for some reason [23:36:45] * BBB tries to figure out what he broke [23:36:53] <mru> you broke *it* [23:36:59] <Jumpyshoes> i will need to fix that at some point, but linux would be handier for timings [23:38:17] <ruggles> BBB: /misc/fate/work/saracen/src/libavcodec/ppc/h264_altivec.c:976: error: 'DSPContext' has no member named 'put_no_rnd_vc1_chroma_pixels_tab' [23:39:44] <mru> fix looks trivial [23:39:54] <mru> but wtf is that doing in h264_foo.c? [23:40:24] <Dark_Shikari> vc1/h264 share chroma [23:42:32] <BBB> h264_altivec.c is really still dspcontext stuff [23:42:38] <BBB> I moved it out of dspcontext [23:42:46] <mru> I know [23:42:50] <BBB> sorry, I must've missed that one, I thought I grepped to make sure there was nothing left [23:42:52] <mru> you just forgot to update the ppc init code [23:43:11] <mru> no worries, but please fix it [23:43:16] <BBB> working on it [23:43:25] <BBB> it's at libavcodec/mpegaudiodec.c [23:43:33] <BBB> your ppc is a little slow [23:43:44] <mru> hey, it was free [23:44:04] <mru> like much of my hardware [23:45:06] <Jumpyshoes> what, how do you get free hardware [23:45:24] <mru> Jumpyshoes: someone gave me an old mac g4 [23:45:39] <mru> and TI give me dev boards [23:45:52] <Jumpyshoes> i see [23:45:57] <mru> I have some other free dev boards too [23:46:10] <mru> you can usually get them if you ask the right people nicely [23:46:17] <Jumpyshoes> i think the chances of intel giving me a sandy bridge are slim to none [23:46:27] <mru> that's a bit different [23:46:45] <mru> a beagleboard costs $130 retail [23:46:53] <mru> giving me a few costs them next to nothing [23:47:20] <mru> and in return they get software [23:47:43] <Jumpyshoes> i guess [23:48:19] <mru> especially if I get them at a stage where I have to write the software myself if I want to do anything at all [23:48:51] <mru> a giveaway high-end intel system could simply turn into a gaming rig [23:48:57] <mru> and that's not what they want [23:49:21] <Jumpyshoes> true, true [23:49:38] <BBB> ugh this is messy... will take me a few minutes to fix, I'll likely have to split h264_template_altivec.c into several subfiles [23:49:49] <mru> why? [23:49:57] <BBB> unless I create a second init function in it, vc1_stuff_init(), that I call from vc1dsp_altivec.c [23:50:00] <BBB> but that's hacky [23:50:03] <BBB> which do you prefer? [23:50:54] <mru> Jumpyshoes: anyway, http://git.mansr.com/?p=ffmpeg;a=commitdiff;h=53f60a4 [23:51:17] <mru> BBB: I see [23:51:40] <mru> the vc1-only functions obviously don't belong in h264_*.c [23:51:49] <mru> so moving them is the right thing to do [23:52:01] <BBB> ok I'll split it [23:52:14] * BBB has a crying baby on lap, so programming is a little slower right now [23:52:37] <Jumpyshoes> mru: thanks [23:52:37] <mru> crying baby has higher priority than crying fate [23:52:57] <Jumpyshoes> i'll test once i get config to detect yasm [23:53:06] <BBB> crying baby is much louder than red fate [23:53:10] <BBB> :-p [23:53:19] <mru> Jumpyshoes: do you have any logs of the failure? [23:53:34] <Jumpyshoes> mru: yes, lemme paste [23:54:02] <Jumpyshoes> mru: http://ffmpeg.pastebin.com/eiGPAGfi [23:54:29] <{V}> mru, I think that was a feature request from BBB; make red fate result louder than a crying baby :p [23:54:45] <BBB> aiyoh [23:54:47] * BBB runs [23:55:20] <mru> Jumpyshoes: running configure under cygwin with non-cygwin yasm? [23:55:51] <Jumpyshoes> mru: hrm, that might be it. i didn't install yasm myself. it works with x264 though [23:56:41] <mru> Jumpyshoes: it's being called with unix-style filenames [23:56:47] <mru> and then it complains that file doesn't exist [23:57:04] <mru> that's consistent with a non-cygwin yasm [23:57:11] <Jumpyshoes> interesting [23:57:22] <mru> and that's a configuration that's not easy to support [23:57:43] <Jumpyshoes> why does it work in x264 though? [23:58:00] <mru> x264 probably uses only relative file paths [23:58:32] <Jumpyshoes> i see [23:59:33] <Sean_McG> happy $timezone folks [23:59:48] <mru> morning Sean_McG

1 0

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

17 Feb '11

[00:00:07] <j-b> iive: ok [00:00:07] <kierank> it's also consistent with x264 which is good [00:00:53] <michaelni> LGTM [00:01:10] <michaelni> .... but iam sure you can biekshed it more .... [00:01:13] <j-b> http://pastebin.com/ySqdSiNu [00:01:22] <j-b> for the libavutil part [00:01:26] <iive> j-b: you could assume that the buffer is filled with constant speed (TS stream, dvd/cd), but frames are of different size. [00:01:28] <j-b> not sure about the MICRO part though [00:01:45] <kierank> iive: in vbv the buffer is filled at a constant rate [00:01:59] <kierank> i.e maxrate [00:02:12] <Dark_Shikari> only in cbr [00:03:02] <michaelni> j-b, LGTM but its bikeshedable like retunrned error code and what ver to bump [00:03:42] <mru> it adds something to external api -> minor bump [00:03:55] <j-b> ok [00:04:04] <michaelni> blue ! :) [00:04:08] <j-b> but error code? [00:04:20] <mru> inval seems ok [00:04:27] <michaelni> something permission and access denied maybe :) [00:04:38] <mru> it's not really a permission thing [00:04:45] <mru> it's an invalid thing to attempt [00:04:57] <j-b> not EIO, nor ENOENT, nor EILSEQ or ENOMEM nor ENOSYS [00:05:05] <iive> j-b: actually I think that vbv should be decided entirely by the encoder. it is the one who knows frame complexity and how big frames would be. this means that the delayed setting of it is the best course of action. [00:05:09] <mru> ENOPAINT [00:05:10] <j-b> EDOM is a bit different [00:05:14] <dalias> lu_zero, lifted? [00:05:26] <mru> EDOM would be correct for out of range values [00:05:29] <lu_zero> dalias: like from boehm [00:05:30] <Sean_McG> EEPIC_FAIL? [00:05:34] <j-b> iive: I think I understand it [00:05:36] <dalias> ah [00:05:49] <dalias> i'm sure there's some source you could look at to find how to do them on arm [00:05:51] <j-b> iive: the tip of the iceberg. thx [00:05:57] <michaelni> premission is not so wrong, read only here means you as outsider cant write toi it the codec after all can [00:05:58] <dalias> i just know x86 asm so i wrote the originals myself [00:06:07] <iive> j-b: i'm glad i've been of some use. [00:06:24] <mru> there are perfectly good manuals from arm and linux kernel [00:06:28] <lu_zero> I wrote some fixes for ppc64 loong ago to libatomic_ops [00:06:40] <lu_zero> so that code looked quite similar [00:06:45] <mru> atomic ops on arm are similar to ppc [00:07:29] <iive> kierank: it can't be filled at max rate, because then it should be emptied at max rate. it should be filled at average rate. aka the normal rate. [00:07:49] <mru> iive: constant rate is constant [00:07:49] <kierank> iive: read annex c [00:07:57] <Dark_Shikari> iive: "max rate" is the rate of inflow to the buffer [00:08:00] <Dark_Shikari> there is NO maximum on outflow rate. [00:08:19] <mru> Dark_Shikari: each coded picture has to fit in the buffer [00:08:21] <j-b> michaelni: EPERM ? [00:08:24] <mru> that does impose a limit [00:08:28] <mru> j-b: no, perm is wrong [00:08:39] <mru> that implies that someone else could do it [00:08:47] <michaelni> mru, encoder ... [00:08:56] <j-b> EINVAL seems the best, so far [00:09:06] <michaelni> j-b, perfectly fine with me :) [00:09:23] <mru> j-b: care to send a git patch? [00:09:23] <j-b> ok, then I should create 2 patches and send them? [00:09:27] <j-b> mru: sure [00:09:30] <mru> j-b: please do [00:09:33] <dalias> are you guys choosing which posix error codes make sense for codecs to return? :) [00:09:43] <michaelni> :) [00:09:43] <mru> something like that [00:09:45] <j-b> mru: that'll make me learn to read the doc [00:10:00] <dalias> nice not to be reinventing the wheel :) [00:10:17] <mru> dalias: exactly [00:10:48] <michaelni> POSIX should have a EPATCHWELCOME ... [00:10:57] <michaelni> and EBIKESHED [00:11:02] <Sean_McG> hahah [00:11:25] <mru> 00:05 <@mru> ENOPAINT [00:11:32] <michaelni> yes [00:12:01] <j-b> mru: should I send 2 patches for the 2 different trees? [00:12:19] <michaelni> j-b, commit to videolan :) [00:12:41] <j-b> michaelni: well, to send to the mls [00:13:09] <michaelni> doesnt one apply to both trees? [00:14:08] <j-b> well, libavutil.MICRO is 37 vs 38 [00:14:16] <michaelni> hmpf [00:14:29] <mru> j-b: send whatever, I'll fix that [00:14:33] <michaelni> id say send one, cherry picking and fixing up is trivial [00:25:49] <Sean_McG> mru: I'm still not sure why your and kostylev's ppc builds don't both have the vp8 SEGVs [00:26:17] <mru> probably a memory alignment thing [00:26:32] <Sean_McG> the only real difference is that he builds with -O3 [00:26:45] <Sean_McG> oh wait and gcc 4.5.2 [00:26:58] <mru> everybody builds with -O3 [00:27:04] <mru> it's the default [00:27:09] <mru> in configure [00:27:22] <mru> my guess is some read is slightly out of bounds and some machines happen to have an unreadable page there [00:27:50] <mru> valgrind complains [00:27:50] <Sean_McG> but looking at the patch that broke them, I think I know why... there's a 24-element char array that's being fed to altivec that probably isn't 16-byte aligned [00:28:18] <Sean_McG> which would actually match the valgrind complaint [00:28:23] <mru> gcc 4.0 is plain broken [00:28:26] <mru> it never passed [00:28:29] <j-b> mru: michaelni: sent to ml, and http://people.videolan.org/~jb/f-ffmpeg-patches/ http://people.videolan.org/~jb/v-ffmpeg-patches/ [00:28:39] <j-b> I hope I didn't mess up too much... [00:28:46] <j-b> hopefully, I am French :) [00:29:02] <mru> are you hopefully french? [00:29:08] <mru> what would be the worse option? [00:30:07] <j-b> I am French, so I can't be worse than that. So anything I do that is stupid is expected :D [00:30:49] <mru> hmm, that will still print the option in the -help listing [00:30:58] <mru> unless I'm missing something subtle [00:31:38] <michaelni> needs a change to show_help_options() [00:31:47] <michaelni> to not proint read only fields [00:32:08] <mru> wrong function [00:32:42] <mru> opt_list() in opt.c seems like the right place [00:34:28] <j-b> hmm, exact [00:34:41] <michaelni> no [00:34:53] <michaelni> why dont you want to list read only options? [00:35:07] <mru> show_help_options() doesn't even touch that list [00:35:14] <michaelni> for "internal" ABI options yes [00:35:24] <michaelni> opt_list() would be correct [00:35:28] <j-b> show_help_options doesn't seem to use AVOption, I was confused [00:35:36] <mru> j-b: it doesn't [00:35:48] <michaelni> j-b, yes it would have been insufficient [00:35:48] <j-b> <= confused [00:36:19] <michaelni> if you guys insist on readonly flag then its updating the show_whatever stuff in ffmpeg/ffplay.c [00:36:36] <michaelni> or add a abi flag like i suggested and do the chek in opt_list() [00:36:39] <mru> add the flag to the skip mask in show_help() [00:36:42] <michaelni> but iam happy to hear better ideas [00:37:22] <michaelni> mru, yes thats what iove meant with updating ffmpeg/ffplay.c [00:37:33] <mru> I didn't imply otherwise [00:37:41] <michaelni> its a much bigger change though [00:37:52] <michaelni> than what a abi flag would need [00:38:20] <michaelni> and it break AVOption ABI/API a little [00:38:35] <j-b> then, this is out of my capabilities [00:38:37] <michaelni> by apps needing such change ... [00:38:51] <j-b> Did my best though [00:39:09] <michaelni> j-b, thanks anyway [00:39:17] <j-b> sure [00:41:53] <Sean_McG> hmmm patches.ffmpeg ain't responding [00:43:36] <j-b> gn people [01:02:36] <Sean_McG> I think it's almost beer o-clock [01:14:57] <lu_zero> dalias: half of the code you need is available in libatomic_ops (MIT) [01:15:39] <dalias> the atomics are like a 5-min job :) [01:16:06] <lu_zero> less since is copy&paste =P [01:16:21] <dalias> its clone, set_thread_area, setjmp/longjmp, unmapself that take a little work [01:16:30] <dalias> unmapself is my fav asm in musl [01:16:51] <dalias> it written in asm because the function unmaps its own stack :) [01:17:06] <mru> scary [01:17:22] <dalias> used so that detached threads can cleanly exit without leaking memory [01:17:26] <lu_zero> x_x [01:17:44] <dalias> glibc's approach is to keep a linked list of orphaned thread stacks and reuse them [01:18:11] <dalias> but that can waste lots of memory and has potential for lock contention updating the list [01:18:19] <lu_zero> the math ops aren't already provided by gcc btw? [01:18:32] <dalias> on gcc 4, yes [01:19:45] <dalias> i'm thinking about updating the code to use them if the compiler provides them and only fallback to asm when it doesn't [01:20:16] <dalias> but i'd like to support tcc, pcc, etc. without having to wait for them to mimic gcc __builtin_* [01:20:43] <mru> the atomics in gcc suck badly on arm [01:20:49] <mru> those that exist at all [01:21:38] <dalias> then its prolly best not to use them [01:22:10] <dalias> btw i hear some old arms lack proper atomic ops [01:22:40] <mru> maybe some really ancient ones [01:22:50] <dalias> is it worth trying to support that crap? [01:23:30] <dalias> my thought is to target the modern stuff and if really necessary, maybe add an "arm-ancient" arch with workarounds for broken stuff [01:23:48] <mru> do you need byte, halfword, or double-word atomics? [01:24:12] <dalias> just 32-bit and pointer-sized [01:24:16] <dalias> mostly 32-bit [01:24:23] <mru> and pointers are 32-bit on arm [01:24:37] <mru> then you can support armv6 and later with the modern implementation [01:24:49] <mru> armv5 uses a different strategy for atomic ops [01:24:57] <dalias> how does v5 work? [01:25:07] <mru> locks the bus [01:25:13] <mru> which doesn't scale well [01:25:18] <mru> and is hard to implement [01:25:49] <mru> armv6 added ldrex/strex instructions [01:26:11] <mru> same style as on ppc, alpha, etc [01:26:27] <dalias> http://lwn.net/Articles/314561/ [01:26:27] <mru> v6k added non-word size versions of those [01:28:01] <mru> that's not atomic [01:28:16] <BBB> hm, I wrote the idct and it didn't crash [01:28:19] <BBB> it doesn't work either [01:28:20] <BBB> but hey [01:28:23] <BBB> that's better than nothing [01:28:24] <BBB> :-p [01:28:39] <dalias> mru, the kernel makes it atomic [01:29:06] <dalias> by resetting the instruction pointer if it got interrupted in the middle [01:29:12] <mru> ah, kernel helps [01:29:18] <mru> sneaky [01:29:25] <mru> but it's not smp-safe, as he points out [01:29:39] <mru> and almost all arm systems do have another processor [01:29:39] <dalias> and it stores that code at a special address so it can know if it's in the middle of an atomic op [01:29:42] <dalias> right [01:29:46] <dalias> even v5? [01:29:50] <mru> of course [01:29:53] <dalias> ah [01:29:55] <dalias> that's useless then [01:29:56] <mru> they're usually teamed up with a dsp [01:30:04] <dalias> oh [01:30:13] <dalias> not smp, specialized stuff [01:30:26] <dalias> thats a whole 'nother game of hackery :) [01:30:38] <mru> from this point of view, not really [01:30:41] <mru> it's another bus master [01:30:57] <mru> anything with access to the system bus can write to memory [01:31:21] <dalias> yes but using the dsp to write to implementation-internal locking structures has UB anyway [01:31:24] <mru> a truly atomic operation must somehow snoop or block such traffic [01:31:46] <dalias> i agree for atomic ops on data shared with the dsp it matters [01:31:53] <mru> you often need atomic ops to synchronise the arm and the dsp... [01:32:12] <mru> for purely arm-side things it doesn't matter of course [01:32:19] <dalias> but i doubt you use pthread_mutex_t for it :) [01:32:27] <mru> you might actually [01:32:39] <mru> if you're _really_ careful [01:32:49] <dalias> only if you have a pthread implementation that's for both arm and the dsp.. [01:32:57] <mru> exactly [01:33:07] <dalias> :) [01:33:15] <mru> would make sense [01:33:18] <dalias> that's cool but way outside the current problem domain [01:33:51] <dalias> if armv5 is not going to be used in smp, for musl's purposes i probably don't have to care if there might be dsps [01:34:28] <mru> there are actually some really obscure armv5 smp systems [01:34:36] <mru> but I wouldn't worry about those [01:34:46] <dalias> perhaps armv5 is just worth considering as a separate arch anyway [01:34:53] <dalias> uclibc's approach is the worst [01:35:05] <mru> supporting v6 and later is a good start [01:35:16] <dalias> "getting interrupted between those 2 instructions will probably only happen once in 10 years and the device is more likely to fail for other reasons anyway" [01:35:46] <dalias> :) :) [01:35:48] <mru> be careful with such reasoning [01:35:56] <dalias> i said it's the worst :) [01:36:04] <dalias> i was mocking it [01:36:05] <mru> sometimes it's applicable [01:36:26] <mru> if the failure mode is catastrophic it's probably ok [01:36:35] <mru> if it silently gives wrong answers, it's not [01:36:45] <dalias> if that's really the case, i'd probably throw in a random spin of ~1000 cycles or so before the lock attempt [01:36:51] <dalias> to make it even more unlikely [01:44:15] <dalias> btw just a note [01:44:35] <dalias> musl's use of atomics requires them actually be the same as the underlying types [01:44:51] <dalias> no hacks of making an atomic_int type that has a separate lock incorporated in it [01:47:18] <BBB> anyone wants to develop a codec for $1000? [01:47:27] <mru> are you joking? [01:47:32] <BBB> that's what I thought [01:47:33] <BBB> :-p [01:47:39] <BBB> https://roundup.ffmpeg.org/issue421 [01:47:54] <BBB> maybe there's a 0 missing, plus a *2-5 multiplier [01:48:08] <mru> 50k would be worth considering [01:48:16] <bcoudurier> 50k ? [01:48:19] <BBB> some people would do it for 25k [01:48:23] <Jumpyshoes> BBB: how hard is it :P [01:48:23] <BBB> I'd probably do it for 25k [01:48:29] <BBB> Jumpyshoes: requires RE'ing [01:48:31] <BBB> Jumpyshoes: it'd be fun [01:48:35] <BBB> Jumpyshoes: want to try? [01:48:43] <Jumpyshoes> hrm... sure [01:48:46] <BBB> Jumpyshoes: warning, $1000 is not a lot :) [01:48:47] <bcoudurier> nobody's gonna pay 25k [01:49:02] <Jumpyshoes> BBB: when your income is 0, it is [01:49:04] <BBB> bcoudurier: probably not in public, no :( [01:49:26] <mru> let's just say I've done business with codecs... [01:49:42] <mru> 25k to RE and implement an entire codec is low [01:49:53] <bcoudurier> I've done business as well [01:49:59] <bcoudurier> 25k is high [01:50:03] <bcoudurier> for a single entity [01:50:03] <mru> then you're underpaid [01:50:37] <bcoudurier> you're paid what people want to pay for [01:50:37] <mru> ok, for a lossless audio codec perhaps 25k is enough [01:51:13] <dalias> :) [01:51:19] <mru> chances are it's another variant of rice+lpc [01:51:36] <bcoudurier> besides the foundation was offering $4000 for prores, if that is low I'd say we need to reconsider [01:51:44] <kierank> mru: good to hear I have the right kind of ballpack figures as you ;) [01:51:47] <BBB> bcoudurier: foundation doesn't pay market rate [01:52:01] <bcoudurier> BBB and why not ? [01:52:08] <BBB> bcoudurier: good question [01:52:15] <BBB> bcoudurier: maybe it should, you're right [01:52:26] <mru> maybe if had the funds, it could [01:52:34] <BBB> although for prores I doubt we can achieve market rate [01:52:37] <BBB> prores would cost a lot [01:52:41] <BBB> as you no doubt know :) [01:52:50] <bcoudurier> yes, that's why you get paid what people want to pay for it [01:53:00] <Jumpyshoes> i think [01:53:05] <Jumpyshoes> this file has debug info in it [01:53:30] <BBB> Jumpyshoes: I have a wmavoice binary with debug in it [01:53:31] <BBB> er [01:53:33] <BBB> wmalossless [01:53:35] <BBB> same thing btw [01:53:35] <dalias> mru, looks like the kernel approach is considered the right way to do atomics on arm [01:53:40] <BBB> it's the same binary [01:53:46] <Jumpyshoes> lol [01:53:47] <BBB> debugging it is relative easy [01:53:48] <mru> dalias: armv6 doesn't need kernel help [01:53:53] <dalias> it will use the real atomic opcodes on armv6 [01:53:56] <BBB> Jumpyshoes: it's the "wma" binary :) [01:54:19] <mru> dalias: a function call for a 4-instruction sequence is silly [01:54:32] <mru> call overhead is more than that [01:54:44] <Jumpyshoes> haha [01:55:06] <dalias> are you sure? i've found calls are pretty damn cheap these days but i dunno about arm [01:55:21] <BBB> Jumpyshoes: if you're in, I can probably help you, I did the wmavoice part of the binary and it was quite fun, you could continue working from there on, but warning, it's audio, not video [01:55:27] <mru> dalias: the call itself yes [01:55:35] <dalias> if benchmarking showed an improvement for inlining the 4 ops tho, i'd have separata targets for arm6 and oldarm [01:55:35] <mru> but you have to set up the arguments etc [01:55:41] <BBB> (in the department of "well, that was kind of obvious" warnings) [01:55:47] <Jumpyshoes> BBB: ah, true [01:55:49] <dalias> mru, it's pass-by-register [01:55:53] <mru> I know [01:56:08] <mru> but what if your values aren't in the argument registers? [01:56:24] <dalias> still just a couple cycles [01:56:27] <mru> and if you're in an otherwise leaf function, you need to save your return address [01:56:31] <mru> dalias: not so simple [01:56:51] <mru> you need to shuffle whatever is in the arg regs elsewhere [01:57:04] <mru> dalias: I write arm asm for a living, I should know... [01:57:09] <dalias> :) [01:57:30] <dalias> anyway benchmark is probably best [01:57:45] <Jumpyshoes> BBB: they're nice enough to give decrypted strings :p [01:57:50] <dalias> if there's measuable performance to be gained by inlining and making an arm6-specific build, go for it :) [01:58:30] <BBB> Jumpyshoes: imagine that you know all function names [01:58:39] <BBB> Jumpyshoes: and the binary looks like it's been compiled with -O0 [01:58:45] <BBB> Jumpyshoes: believe me, much nicer :) [01:58:57] <Jumpyshoes> do you know the function names for this binary? [01:59:57] <BBB> they're in the binary [02:00:10] <BBB> we'll make you a master reverse engineer [02:00:20] <BBB> you'll be able to figure it all out yourself [02:00:35] <bcoudurier> I remember when hexrays wasn't available ... [02:00:52] <BBB> I did it without hexrays :-p [02:00:58] * BBB used just plain ida [02:01:01] <bcoudurier> yes [02:01:02] <Jumpyshoes> hexrays would... probably work really well on this binary [02:01:17] <bcoudurier> wma3 started without hexrays [02:01:48] <BBB> bcoudurier: want to help out teaching Jumpyshoes for wmalossless? [02:02:00] <BBB> I can help him with the day-to-day stuff, if you help him setting up hexrays [02:02:09] <BBB> which I've tried but apparently not enough [02:02:11] <bcoudurier> do we have the linux .so ? [02:02:22] <BBB> yes [02:02:31] <BBB> but the wince binary has better debug symbols [02:02:38] <bcoudurier> well cool [02:02:40] <Jumpyshoes> >please bump back if not adequate. <-- maybe i should do this :p [02:02:41] <BBB> (they're from the same source, just slightly different struct offsets) [02:02:45] <bcoudurier> but after some point it's nice to hook up the lib [02:02:51] <BBB> oh [02:02:55] <BBB> you can do that with the wince one also [02:02:58] <BBB> objconv [02:03:13] <BBB> it gives individual object files [02:03:14] <BBB> very easy [02:03:41] <bcoudurier> you can execute them ? [02:03:48] <BBB> yes [02:03:53] <bcoudurier> that's nice [02:04:01] <BBB> I did the whole thing for wmavoice [02:04:13] <BBB> since it's the same binary, doing the same for wmalossless with the binary should be easy [02:04:33] <BBB> (each codec has its own api in that lib, but once you know the functions and its parameters, it's easy) [03:48:26] <funyun> hi. can anyone help me with crop? i've read the documentation but still don't understand it. i simply need to crop 2 pixels from the top [04:13:18] <Compn> funyun : did you try #ffmpeg ? [05:47:03] <astrange> BBB: https://roundup.ffmpeg.org/issue2609 wrote a diagnosis but i might not be able to get to it (or anything else) until monday [07:13:48] <wbs> BBB: re the rtsp udp/tcp resetup bug, I do think it's valid, I just have to figure out how to reproduce it :-) [07:49:53] <elenril> .....wow [07:50:02] <elenril> git can deal with renamed files when mergind/rebasing [07:51:13] <Tjoppen_> git is awesome :) [07:51:29] <andoma> git is divine [07:54:26] <KotH> einen wunderherrlichen guten morgen! [07:54:36] <cartman> moin [07:55:07] <KotH> selam cartman [07:55:22] <cartman> ve aleykÃŒm selam KotH :D [07:57:53] <elenril> KotH: http://tvtropes.org/pmwiki/pmwiki.php/Main/BlackSpeech [07:59:43] <KotH> elenril: es isch aber ka dütsch! [08:04:01] <pJok> ohayou gozaimasu [08:19:03] <uau> elenril: other VCSes can deal better with renamed files [08:19:25] <elenril> how "better" [08:20:48] <kshishkov> ClearCase? [08:21:12] <uau> git's whole rename support is kind of hacky [08:22:24] <uau> it has no proper rename tracking (as everything is based on heuristics), and as a result the things that try to do something with renames aren't very consistent or reliable about it [08:22:45] <uau> for example git has no concept of directory renaming at all [08:23:19] <uau> which can lead to various breakage when the unreliable per-file heuristics return different results [08:24:33] <uau> for example i've seen one directory rename case where git thought that one file in the renamed directory was deleted, and a copy of another was created... [08:26:32] <lu_zero> uau: it's the problem of having per line tracking [08:35:49] <divVerent> uau: yes, personally, I prefer to "help" git to know about renames [08:35:58] <divVerent> by doing a rename-only commit, and fixing up the references in a second commit [08:52:59] <CIA-15> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * rec25f83bd9 ffmpeg/libavformat/spdifenc.c: [08:52:59] <CIA-15> ffmpeg: spdifenc: update 482d98f69b2eb7a7b0b5054101a43db384e9432b to the latest patch [08:52:59] <CIA-15> ffmpeg: "spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI" [09:15:33] <DonDiego> btw, is anybody aware that our ogg demuxer fails when tracks change in streams? [09:16:01] <DonDiego> ubitux mentioned that he could reproduce this issue [09:16:14] <DonDiego> ubitux could you report a bug for this issue? [09:16:28] <ubitux> on bugzilla? [09:17:24] <ubitux> it's simple, start http streaming with icecast/mpd or just a recent mpd, run mplayer on the stream, switch song, shit bricks [09:19:00] <DonDiego> no, on roundup please [09:19:16] <DonDiego> also, can you reproduce with ffplay? [09:19:42] <av500> can ffplay handle song changes at all? [09:19:47] <iive> DonDiego: ogg puts each new track into new stream [09:20:11] <kshishkov> av500: FFplay is overly British in spirit - it ignores any changes [09:20:32] <ubitux> DonDiego: on sorry, i though i was on #mplayerdev. [09:20:43] <j-b> good moroning [09:21:40] <av500> +1 [09:21:50] <cartman> <<1 [09:22:08] <kshishkov> j-b: come visit Russia [09:22:20] <j-b> kshishkov: great idea [09:22:24] <thresh> not really [09:22:29] <thresh> it's -23Â°C here now [09:22:52] <thresh> well was in the moroning [09:23:05] * cartman is freezing with 4Â°C atm. [09:23:13] <kshishkov> thresh: Zoich? [09:23:34] <kshishkov> thresh: or other warmer place? [09:24:13] <kshishkov> thresh: and our Ben has visited Murmansk, big deal [09:24:18] <pJok> kshishkov, so FFplay also only speaks one language? [09:24:23] <thresh> kshishkov: zoich is a cool mascot, what do you mean by place? [09:25:23] <ubitux> DonDiego: are you sure there isn't any issue already filled?; i asked several times and everyone seems aware of the issue [09:26:21] <ubitux> (i can't test right now with ffplay) [09:26:22] <kshishkov> thresh: a place where Zoich-2018 is held? Ð¢Ð°ÐŒ Ð³ÐŽÐµ Ð¿ÑÐžÐºÑÐ¿ Ð·ÐœÐ°ÑÑ [09:28:00] <thresh> kshishkov: 2014 [09:28:49] <thresh> it's actually a cool idea to held a winter olympics at a place with no snow in winter [09:29:03] <cartman> "I donated you the same amount I give to beggars in the city; hope it helps you in finding a job. Best wishes!" [09:29:05] <kshishkov> thresh: Ð²ÐžÐŽÐžÐŒÐŸ Ñ ÑÑÑÐ±ÐŸÐ»ÐŸÐŒ Ð¿ÐŸÐ¿ÑÑÐ°Ð», ÐŒÐ°Ð³Ñ Ð»Ðž Ð¹Ð° ÑÐºÐ°ÑÐ°ÑÑ Ð°Ñ ÑÐžÑÑÐ°Ð²Ð° ÑÐµÑÑÐ° Ð¿Ð°ÑÑÑÐºÐž? [09:29:08] <cartman> stylish donation [09:30:12] <DonDiego> ubitux: no, i'm not sure, but i'm not aware of such a bug either and i did look for all ogg-related bugs at some point [09:30:22] <thresh> for those of you who are still puzzled by what zoich is: http://rt.com/files/sport/other/sochi-2014-mascot-zoich/sochi-2014-mascot-z… [09:30:35] <thresh> it won an internet voting for a mascot for winter olympics [09:30:41] <cartman> lol [09:30:53] <av500> thresh: can it patch kde2 on bsd? [09:31:12] <thresh> somehow officials didnt allow it to a second phase of voting ;( and only left the stupid ones :( [09:31:18] <thresh> av500: most probably so [09:31:51] <kshishkov> thresh: it's Russia and Zoich was not a member of ER [09:33:56] <CIA-15> ffmpeg: Reimar DÃ¶ffinger <Reimar.Doeffinger(a)gmx.de> master * r5d820db2f9 ffmpeg/libavformat/avformat.h: [09:33:56] <CIA-15> ffmpeg: Document that av_write_header sets stream time_base to a value of it chosing. [09:33:56] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [09:34:04] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r938b62538a ffmpeg/libavcodec/avcodec.h: [09:34:04] <CIA-15> ffmpeg: Document audio_resample_close(). [09:34:04] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [09:34:06] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r5495528365 ffmpeg/libavcodec/avcodec.h: [09:34:06] <CIA-15> ffmpeg: Apply minor cosmetics fixes to the av_audio_resample_init() doxy. [09:34:06] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni(a)gmx.at> [09:34:06] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [09:34:19] <iive> thresh: it is mighty quite, no wonder it won. ;) [09:35:33] <thresh> indeed: http://zhgun.ru/pics/zoich/glory.gif [09:36:37] <DonDiego> what is this beast? a hairy frog on lsd? [09:37:00] <kshishkov> DonDiego: so you've never seen Futurama, eh? [09:38:35] <iive> kshishkov: hipnotoad is much more cute. [09:39:26] <kshishkov> iive: well, of course, but here it's not about world domination either [09:40:26] <thresh> but Zoich actually shows the Russian majesty and spirituality [09:40:35] <thresh> it has a crown [09:42:21] <iive> thresh: and the crown looks like hand showing a finger... [09:43:02] <thresh> iive: for this words I will invade .bg in May [09:43:55] <iive> thresh: too late, it was invaded 66 years ago, in september. [09:48:12] <thresh> yeah we beat the crap out of nazis [09:50:57] <kshishkov> yes, Russia remembers all great victories it had, there are too few of them anyway [09:53:34] <thresh> yeah not much to be proud of now :( [10:23:03] <j-b> anyone near Hannover? [10:24:01] <DonDiego> define near :) [10:24:07] <DonDiego> i'm in the same country... [10:25:39] <kshishkov> I'm in different BunderlÃ€ndle [10:25:53] <kshishkov> so Janne may be the closest [10:26:31] <jannau> j-b: looking for a place to sleep during cebit? [10:26:52] <av500> j-b: sleep in gÃ¶ttingen and take the ICE in the morning [10:27:07] <av500> is faster than car/pubic transport in hannover [10:27:23] <DonDiego> you are welcome to sleep here in aachen, the thalys from paris passes through here... [10:27:24] <jannau> and probably less expensive [10:27:29] <av500> yep [10:27:43] <kshishkov> av500: more punctual too? [10:27:43] <KotH> av500: pubic transport? [10:29:24] <j-b> near, as in can go attend the opening ceremony, so I can give him free tickets [10:30:55] <jannau> j-b: the free tickets are still physical tickets and not coupons for electronic tickets? [10:31:33] <j-b> jannau: for the opneing ceremony, it is quite special, I think [10:31:51] <av500> special as in mrs merkel will be there [10:32:11] <kshishkov> av500: do you care about her? [10:33:05] <kierank> hmmm I want to see angela merkel [10:33:18] * kierank considers going again [10:33:41] <av500> kshishkov: nope, thats why i think that cebit opening is useless [10:33:52] <jannau> but who wants to go to the opening ceremony? /me has trouble to imagine less interesting events [10:33:58] * av500 files kierank under "wierd brit" [10:34:57] <kierank> av500: along with mru [10:35:04] <kierank> ? [10:35:16] <j-b> av500: yes, which is why they break our b*lls with security and registration [10:36:00] <kierank> they are not particularly paranoid about security for the prime minister or the royal family here [10:36:13] <av500> j-b: as her how to patch KDE2 under BSD [10:36:34] <j-b> av500: I really doubt I will go [10:36:58] <elenril> what's up with obscure russian memes [10:37:02] <kshishkov> kierank: have you ever thought that Brit with name MÃ¥ns may be not weird but rather not Brit? [10:37:11] <kierank> av500: ? [10:38:14] <kierank> kshishkov: no [10:38:27] * kierank doesn't see why mru shouldn't be classed as british [10:38:48] <spaam> why should he? [10:39:04] <spaam> swedish > british [10:39:04] <kshishkov> kierank: double-classed [10:39:24] <kshishkov> spaam: it's Britain, they have a long history of importing their great men [10:39:35] <kierank> kshishkov: importing our royalty too [10:40:03] <spaam> kshishkov: haha [10:40:20] <kshishkov> kierank: almost everybody got their royalty from Germany (except Danes and Scandinavia) [10:40:55] <spaam> kshishkov: you know.. our king grand grand... father is not swedish.. [10:41:10] <kshishkov> spaam: jag vet det [10:41:18] <spaam> kshishkov: vad bra :) [10:41:37] <kshishkov> spaam: men Bernadotte Ã€r riktig svensk namn nu [10:41:59] <spaam> kshishkov: ja. [11:18:42] <mru> kierank: so why should I be classed as british? [11:19:08] <kshishkov> mru: as the guy who lives in Southampton probably [11:19:31] <av500> and goes to pub lunches every day [11:20:09] <kierank> mru: why one is classed as british is unwritten. It's like the british unwritten constitution [11:20:13] <kierank> you just *are* british [11:20:50] <mru> how do you know, you haven't even met me? [11:21:02] <kierank> true [11:21:20] <mru> the occasional monty python quote doesn't make a man truly british [11:21:38] <kierank> i've heard your accent though [11:22:25] <av500> mru: viciously denying it make you all the more suspect :) [11:22:41] <Flameeyes> mru: you sure look a heck of a brit :) [11:23:09] <av500> [VOTE] is Mans a brit? [11:23:20] <av500> i vote YES [11:23:21] <kshishkov> just ask him if he has a spare morakniv [11:23:24] * Flameeyes votes YES [11:23:26] <spaam> i vote NO [11:23:44] <kshishkov> spaam: you should vote NEJ then [11:23:50] <spaam> kshishkov: ok [11:23:54] * kshishkov does not vote (as usual) [11:23:56] <spaam> jag rÃ¶star NEJ [11:24:40] <spaam> since im from .se my vote counts more :) [12:07:32] <lu_zero> NEJ [12:07:49] <lu_zero> is that a pop-quiz? [12:09:42] <kshishkov> lu_zero: lÃ€ra svenska, Ã€r du snÃ€ll? [12:13:19] <lu_zero> FÃ¶rsÃ¶ker [12:13:56] <CIA-15> ffmpeg: Balint Marton <cus(a)passwd.hu> master * r22ec6b738f ffmpeg/libavformat/utils.c: [12:13:56] <CIA-15> ffmpeg: Fix av_find_best_stream when using a program [12:13:56] <CIA-15> ffmpeg: The current implementation has a bug, it is returning the stream index [12:13:56] <CIA-15> ffmpeg: in the found program, and not the stream index in the list of all [12:13:56] <CIA-15> ffmpeg: streams. The attached patch fixes this issue. [12:13:56] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:26:16] <j-b> michaelni: mru: don't fight for my stupid patch... There is no reason to. I did a patch on ffmpeg that actually compiles. /me happy [12:27:38] <kshishkov> j-b: I've produced such patch once too [12:28:16] <j-b> a VC-1 interlaced patch? [12:28:18] * j-b runs [12:28:50] <mru> no interlaced patches on our ml, please [12:29:41] <kshishkov> j-b: there was a guy asking me about it at FOSDEM. Be thankful he got home alive [12:29:41] * kierank waits for the ffmpeg-interlaced fork [12:29:56] <j-b> kshishkov: :) [12:30:10] <j-b> kshishkov: do not worry, my next hobby is MVC :) [12:30:42] <j-b> and except jason, michaelni or lorenm, I don't know who is actually able to do it [12:30:46] <kshishkov> j-b: you need to go to USA then [12:30:48] <twnqx> j-b: i'd have some weird container/PCM audio stuff id you'd like :P [12:31:16] <j-b> kshishkov: why? [12:31:32] <twnqx> though it's an mpeg-ps variant, and that avformat is utterly horrid, and contains several read-beyond-end-of-buffer parts in my oppinion [12:31:53] <kshishkov> j-b: x264 guys are in USA. And MN is too paranoid to let you see him [12:32:03] <kshishkov> j-b: and judging from what I see any above-average developer can write fast H.264 decoder [12:32:21] <j-b> kshishkov: your average is screwed [12:32:40] <kshishkov> j-b: ask mru [12:32:45] <JEEB> even that chinese dude can do it >_> [12:32:53] <JEEB> (who jointed with neuron2) [12:32:58] <kshishkov> j-b: he knows two guys who created commercial H.264 decoders [12:33:02] <j-b> kshishkov: mru isn't average [12:33:19] <j-b> kshishkov: average developer knows VB.Net and C#. Or maybe Java [12:33:37] <Dark_Shikari> j-b: MVC seems to just be header and ref frame stuff [12:33:40] <Dark_Shikari> which is the stuff I'm worst at [12:33:48] <CIA-15> ffmpeg: Maksym Veremeyenko <verem(a)m1stereo.tv> master * r41cdc1ff1e ffmpeg/libavformat/nsvdec.c: [12:33:48] <CIA-15> ffmpeg: fix nsvdec.c compilation if DEBUG macro defined [12:33:48] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [12:33:52] <j-b> Dark_Shikari: ok [12:34:10] <j-b> kshishkov: anyway, I submitted the idea of putting ads on v.o to get money for such bounties [12:34:32] <kshishkov> j-b: what about putting some money to get rid of autotools for VLC build? [12:34:42] <j-b> rofl [12:34:54] <j-b> noone would do that, even for 10000000$ [12:35:00] <j-b> autotools is hell [12:35:12] <kshishkov> so why do you keep it? [12:35:15] <kierank> j-b: you should make the bounties more prominent on v.o [12:35:30] <JEEB> at least VLC didn't go the mkvtoolnix way and added some ruby for the building process >_> [12:35:59] <kshishkov> mplayer2 uses Python scripts [12:36:05] <j-b> kshishkov: because anything else was worse [12:36:13] <kshishkov> j-b: look at FFmpeg [12:36:15] <j-b> kshishkov: the tryout of cmake was horrible [12:36:21] <JEEB> python at least is pre-installed on mostly used distros and it's somewhat more used overall [12:36:23] <kshishkov> j-b: and hire mru to do the same [12:36:31] <mru> shell scripts rock [12:36:34] <JEEB> cmake is relatively horrible for cross-compilation, yeah [12:36:34] <j-b> kshishkov: yes, but FFmpeg doesn't depend on 60+ libraries :D [12:36:41] <j-b> JEEB: exactly [12:36:44] <Dark_Shikari> Have you looked at configure lately? [12:36:45] <mru> j-b: how is that relevant? [12:36:45] <Dark_Shikari> I think it does~ [12:36:56] <j-b> scons was tried and stopped within the same day [12:37:12] <JEEB> lol scons [12:37:17] <j-b> kshishkov: but yes, something like ffmpeg could be done. [12:37:20] <mru> what became of jam? [12:37:23] <j-b> and would actually be clever [12:37:36] <kshishkov> Dark_Shikari: well, some mru forgot to refresh his zlib replacement for new FFmpeg [12:37:51] <kshishkov> mru: they ran out of tea [12:38:02] <JEEB> perl/python/bash is still understandable for building processes I guess :3 Python being on the line. [12:38:05] <kshishkov> mru: which is the worst British horror [12:38:12] <j-b> JEEB: -perl [12:38:27] <uau> kshishkov: bare mplayer2 doesn't actually use python for building [12:38:30] <mru> kshishkov: the usual english tea is indeed dreadful [12:38:42] <JEEB> yeah, the python is used to automate the building of all of the parts [12:38:59] <uau> if you use the build repo wrapper to build ffmpeg at the same time then the scripts it that do use python [12:39:01] <kshishkov> mru: why do people consume it large quantities then? [12:39:03] <mru> JEEB: I prefer using only posix tools and make [12:39:10] <mru> kshishkov: you'll have to ask them [12:39:19] <kshishkov> uau: yes but you have mplayer-build for it [12:39:26] <j-b> kshishkov: python is clean, I like it [12:39:49] <JEEB> mru, if possible that's a good one [12:39:51] <mru> python is a huge dependency [12:39:56] <JEEB> the less is used the better [12:39:59] <JEEB> :3 [12:40:18] <j-b> pyton is too gue a dep for us [12:40:29] <j-b> python is too huge a dep for us [12:40:45] <mru> the nice thing about shell tools is they don't change [12:40:48] <mru> python does [12:40:56] <j-b> kshishkov: I would love if changing the configure wouldn't trigger an almost full rebuild :) [12:40:56] <JEEB> true [12:40:58] <mru> what works in one version might suddenly break [12:41:05] <mru> and you have to scramble to fix your code [12:41:25] <mru> j-b: in ffmpeg? [12:41:31] <mru> j-b: that can be fixed [12:41:39] <j-b> mru: in VLC, of course [12:41:56] <j-b> mru: I really like ffmpeg build-system [12:42:32] <j-b> but contrary to kshishkov I don't consider it a priority [12:43:07] <kshishkov> what are your priorities then? [12:43:25] <av500> MVC [12:43:41] <kshishkov> av500: and multichannel WavPack till recently [12:43:51] <av500> meh [12:44:02] <kshishkov> and VC-1 interlaced [12:44:15] <j-b> kshishkov: fixing important broken parts of VLC's core (including "clock for audio", "vout rework", especially for subtitle) [12:44:40] <mru> you need to get rid of that ghastly resampler [12:44:47] <mru> for file playback [12:45:01] <j-b> kshishkov: and for users, (mac interface improvement, win interface simplification, and media library) [12:45:06] <av500> kshishkov: vc1 interlaced is only dead HD-DVD, no? [12:45:20] <j-b> and some early BD, I thing [12:45:38] <av500> j-b: media library? you want to do it like winamp, kill the product by making it like itunes? [12:45:41] <kshishkov> av500: dead Blu-Rays, IIRD HD-DVD was progressive [12:45:43] <j-b> kshishkov: then, about codec support, nothing is very important, but I am sure people are going to break our balls with MVC quite soonish [12:46:08] <kshishkov> j-b: just invite us to watch the process [12:46:12] <mru> 3D film is a passing fad [12:46:20] <mru> at least this time [12:46:25] <j-b> kshishkov: doesn't wtv accept vc-1i ? [12:46:25] <av500> it was in the 50's [12:46:39] <mru> the tech is still too crude [12:46:41] <kshishkov> j-b: if yes then bug pross-au for patch [12:46:46] <j-b> av500: optionnal to use. but it is mandatory for audio playback [12:47:09] <mru> now if they were to invent the holodeck... [12:47:24] <j-b> kshishkov: I haven't read anything about wtv yet (except some people harassing for supporting this "major format" (lol)) [12:47:33] <kshishkov> mru: for committing suicides? [12:47:41] <mru> huh? [12:47:49] <j-b> mru: indeed, that is what I meant by "audio clock" [12:47:53] <kshishkov> j-b: it's minor filesystem, not major format [12:48:00] <j-b> kshishkov: exact [12:48:13] <kshishkov> mru: has Star Trek taught you anything about holodeck usage? [12:48:25] <kierank> kshishkov: some current BD's too [12:48:27] <j-b> kshishkov: and then, final thing would be to work on mobile ports (Android), but that is easier, because it is fun, so people want to work on it [12:48:38] <mru> kshishkov: don't disable the safety protocols [12:48:41] <j-b> kshishkov: (end of answer) [12:48:57] <mru> and don't ask it to create a character smarter than you [12:49:36] <kshishkov> and don't run control system under Windows ST without firewall and plugged into Internet [12:50:18] <{V}> mru, re: jam. Last I heard, nothing changed on the official version. I know Haiku uses jam (and I think they customized it a little or maybe that was just for their port to beos and haiku) [12:50:23] <kshishkov> j-b: all things I don't care about but I don't use VLC then [12:50:51] <mru> {V}: I don't see anyone using it anymore [12:50:52] <j-b> kshishkov: as much as mru is not the average developer, you aren't an average user [12:51:21] <kshishkov> j-b: I'm under-average user then [12:53:18] <{V}> mru, that's probably self-sustaining; nobody choses jam, (because they don't know about it,) because nobody else uses it. [12:53:33] <thresh> and it should stay the same [12:53:33] <mru> it was all the rage a few years ago [12:53:46] <mru> then they all switched to cmake [12:54:17] <mru> or cmake became the make replacement du jour [12:54:45] <mru> scons reared an ugly head there too for a while [12:55:00] <mru> and let's not even think about what the java crowd uses [12:55:16] <j-b> and both are crap, and not better than autohell [12:55:38] <mru> tell that the to the trolls that use it [12:56:32] <j-b> I don't see the idea in moving from autotools to go to something that isn't better [12:56:44] <kshishkov> mru: coremake! [12:56:52] * mru is not a fan [12:57:01] * kshishkov neither [12:57:10] <mru> it sucks less than cmake though [12:57:26] <mru> you're stuck on an ancient version too [12:57:35] <mru> there have been improvements [12:57:51] <mru> such as proper dependency tracking and parallel build support [12:58:11] * kshishkov does not care [12:58:24] <kshishkov> I don't care even for the newest GNU Make release [12:58:43] <mru> some of the changes in 3.82 are actually for the better [12:58:53] <mru> it's more consistent in behaviour [12:59:06] <mru> unfortunately it breaks some existing makefiles [12:59:34] <kshishkov> exactly [12:59:46] <kshishkov> so waiting for 3.84 [13:03:54] * {V} doesn't like debugging makefiles [13:04:17] <mru> then get them correct to begin with [13:04:32] <mru> most likely, you're using the wrong approach [13:04:50] <mru> makefiles are, like all computer programs, pure logic [13:06:16] <{V}> probably. Mostly it's just my lack of experience with them. [13:06:54] <mru> people who instinctively reach for the single-step button will have trouble with makefiles [13:08:02] <kshishkov> make CC=echo [13:08:11] <mru> make -n [13:11:27] <{V}> remake :p [13:12:42] <mru> usual debugging techniques for procedural languages don't work with the declarative make [13:14:20] <lu_zero> btw [13:14:41] <lu_zero> waf hadn't been mentioned yet [13:14:42] <mru> and on that note, much of the ffmpeg configure script is declarative in nature [13:16:03] <lu_zero> the ffmpeg configure should be split in modules to be easily reusable by other projects [13:16:25] <mru> +1 [13:16:32] <mru> send more time, and I'll do it [13:16:53] <wbs> making ffmpeg configure/make reusable would be a humanitarian effort to save the world from the other evil build systems [13:17:01] <andoma> yeah [13:17:01] <wbs> as in +1000 from me ;P [13:17:24] <andoma> i've borrowed some smaller functions from it to my project [13:18:25] <andoma> but i'm thinking of reworking my configure script so it generates one .h file per option .. to get rid of full rebuilds when reconfiguring [13:18:55] <mru> how does linux kernel build do that? [13:19:14] <andoma> no idea .. [13:19:18] <mru> #including dozens of config_foo.h in every file isn't practical either [13:19:25] <andoma> indeed [13:19:49] <mru> I've thought about splitting them up in categories at least [13:29:41] <wbs> the worst part mostly is rebuilding everything when lavc minor/micro is bumped [13:30:09] <DonDiego> we could move that stuff into a version.h header [13:30:20] <Kovensky> 09:50.51 mru: {V}: I don't see anyone using it anymore <-- boost does [13:30:29] <mru> lol boost [13:30:33] <Kovensky> 09:54.17 mru: or cmake became the make replacement du jour <-- cmake writes makefiles, it doesn't replace make [13:30:44] <mru> Kovensky: minor detail [13:31:06] <jannau> DonDiego: doesn't help since avcodec.h would include version.h [13:31:17] <mru> jannau: it wouldn't need to [13:31:27] <DonDiego> that was my point... [13:31:50] <mru> which reminds me, there are a number of cross-includes I'd like to drop [13:31:58] <kshishkov> send a patch [13:32:22] <Kovensky> boost is pretty much the only thing I've seen using jam so far [13:33:39] <jannau> as long as we have #if LIBAVCODEC_VERSION_* in avcodec.h we need version.h [13:33:52] <lu_zero> http://ffmpeg.pastebin.com/m8C3kXGc <- what I'm doing wrong? [13:34:11] <mru> we could also split avcodec.h [13:34:21] <mru> possibly [13:34:29] <mru> if there are unrelated parts in it [13:36:45] <kshishkov> look into it first [13:37:54] <kshishkov> lu_zero: line 46 - copypaste error [13:43:03] <DonDiego> mru: what do you mean by "cross-includes"? [13:43:25] <kshishkov> a includes b and b includes a [13:44:18] <mru> that especially [13:44:33] <mru> but may of our headers include others needlessly [13:44:40] <{V}> Kovensky, "boost is pretty much the only thing I've seen using jam so far" look at haiku, then you'll have seen two :D [13:44:41] <lu_zero> kshishkov: uh [13:44:59] <kshishkov> lu_zero: anything else? [13:45:03] <Kovensky> {V}: :P [13:45:28] <lu_zero> kshishkov: try the code =) [13:45:37] <lu_zero> what you'd expect to see? [13:46:01] <kshishkov> let's see [13:47:19] <kshishkov> I see moving gray gradients in top half [13:48:40] <lu_zero> and what's in the bottom? [13:48:49] <kshishkov> nothing [13:48:53] <lu_zero> exactly [13:49:01] <lu_zero> (nothing -> yuv green) [13:49:27] <lu_zero> so you take a frame twice as big, you feed swscale to it to scale it down [13:49:33] <lu_zero> and you got that [13:49:53] <lu_zero> I'm not sure where I'm messing up [14:00:54] <uau> mplayer2 uses the libavformat avi demuxer by default [14:01:15] <uau> that has uncovered an annoying property in it, namely that for some files it seeks audio to a significantly later position than video [14:01:25] <Rathann> what's mplayer2? [14:01:36] <kshishkov> mplayer-uau [14:01:38] <uau> so that when starting playback after seeking audio is missing for a while [14:01:38] <Rathann> ah [14:02:03] <uau> i think the new avformat seek api is supposed to solve issues like that [14:02:14] <uau> but that's still marked "under construction" [14:03:01] <uau> any ideas how to solve that? [14:04:09] <uau> anyone willing to make the default behavior of the current API saner for avi? (i'd rather concentrate on mplayer2 code myself) [14:04:31] <uau> or the new seek api becoming the standard or at least stable in the next bump, assuming that's reasonably soon? [14:06:22] <kshishkov> lu_zero: in sws_scale you forgot to pass c->height*2 for source image height! [14:08:41] <kshishkov> lu_zero: and if you think passing source image height after initialising context is redundant - blame me not [14:14:49] <Kovensky> 11:02.03 uau: i think the new avformat seek api is supposed to solve issues like that <-- does it also solve the seeking-in-ts issue? specially when there are repeated timestamps? [14:16:01] <mru> Kovensky: that's a hard problem to solve [14:16:17] <lu_zero> kshishkov: eh eh [14:16:43] <kshishkov> lu_zero: see why it's useful to read docs sometimes? [14:16:49] <uau> Kovensky: which issue do you mean? the unreliability of mpeg timestamps is orthogonal at least [14:17:09] <lu_zero> kshishkov: not overlook you mean ^^; [14:17:33] * lu_zero assumed that param being the other way round [15:34:56] <BBB> lu_zero: you have mingw32, can you fix AVERROR -> FFNETERROR in https://roundup.ffmpeg.org/issue2611 ? [15:37:29] <cartman> BBB: had time to debug clang VP8 problems? [15:37:38] <Flameeyes> BBB: you have knowledge of mms/mmst, don't you? [15:37:38] <BBB> no [15:37:41] <BBB> Flameeyes: yes [15:37:46] <cartman> BBB: :( [15:37:54] <cartman> my fate is not green anymore :( [15:37:56] <Flameeyes> BBB: is the protocol _officially_ documented? [15:37:57] <BBB> cartman: I'm almost certain it's a compiler issue, I don't have time to look into it right now [15:38:08] <BBB> Flameeyes: yes, look for ms-http on msdn [15:38:18] <cartman> BBB: give me a pointer (void* is good) to debug a function then [15:38:20] <BBB> Flameeyes: mmst (afaik) is not publicly documented [15:38:25] <Flameeyes> BBB: thanks! [15:39:02] <cartman> sigh [15:39:07] <BBB> cartman: I don't really know, the path isn't big, I've said before, try making random modifications in that patch (or the code touched by it), e.g. making stuff not inline, not using AV_ZERO32 but =0 instead, etc. [15:39:32] <cartman> ok if it turns out to be an FFmpeg bug you owe me a fix :P [15:39:35] <BBB> cartman: in other words, apply that patch line-by-line (I'm assuming you understand the code here) and run make fate-vp8 after every line of change [15:39:55] <BBB> cartman: I think it's quite likely that the AV_ZERO32() or inlining causes the issue [15:40:01] <BBB> that's still a compiler bug imo [15:40:02] <BBB> but whatever [15:41:42] <mru> it breaks even with --disable-asm fwiw [15:41:47] <mru> but works at -O2 [15:42:22] <BBB> mru: the patch basically does some processing only when necessary, but with identical code, and uses AV_ZERO32() for some stuff that should be aligned but might not be depending on the compiler [15:42:36] <BBB> mru: I think that second part might break on exotic compilers that don't get much real-world testing [15:42:41] <BBB> oh, hi there clang :) [15:42:45] <cartman> uh oh [15:43:00] <cartman> next time I won't report clang bugs ;) [15:43:14] <BBB> cartman: did you fix it already? [15:43:25] <cartman> BBB: debugging atm. [15:43:29] <BBB> cartman: awesome [15:43:39] <BBB> if you can't figure stuff out, ask me, I can help you apply the patch "change-by-change" [15:44:03] <cartman> thanks, I will break decode_mvs into 2-3 parts and see what part is borking [15:44:07] <cartman> that worked before [15:44:29] <lu_zero> BBB: let me have a look [15:44:34] <BBB> lu_zero: ty [15:45:32] <lu_zero> ugh [15:45:37] <lu_zero> remind me this night... [15:49:37] <DonDiego> does anybody know of a tool to detect write-only variables and similar? [15:50:48] <mru> compiler? [15:51:09] <mru> gcc 4.6 does a much better job than older versions of finding them [15:52:00] <kshishkov> or any of those code analyzers like clang [15:52:07] <DonDiego> i can trivially trick gcc 4.2 here on this mac at work... [15:52:39] <DonDiego> int unused = 0; unused = 42; [15:52:47] <mru> 6 > 2 [15:53:03] <DonDiego> never use that value and gcc never complains [15:53:12] <DonDiego> ok, might be worth compiling a new gcc then... [15:56:58] <Dark_Shikari> Clang is pretty good at that. [15:57:17] <Dark_Shikari> ... to the point where it's too good, it complains about the last i++ in a loop [15:57:39] <mru> isn't that referenced by the loop condition? [15:58:15] <mru> in a while(i++ < foo) I guess it isn't [16:15:37] <BBB> mru: also, mkv doesn't have a dts field, so where does the dts come from in these files anyway? [16:16:30] <BBB> mru: I'm gonna do a rough guess here: lavf utils.c made them up in av_read_frame() or so [16:16:41] <mru> it's made up [16:16:43] <BBB> and then we """""fix""""" them later on :):):):):):):):):):) [16:16:55] <Dark_Shikari> =_= [16:17:42] <BBB> . o O (... ... ... is there anything else left to say? ...) [16:18:32] <elenril> yes [16:18:39] <elenril> you need to merge the rest of -mt =p [16:18:52] <BBB> has anyone gotten a hold on astrange lately? [16:19:21] <elenril> he's usually around at ~6-7 in the morning (CET) [16:19:25] <Dark_Shikari> Hmm, BBB, I have an evil hack idea for making MV clamping faster. [16:19:28] <Dark_Shikari> in vp8 [16:19:37] <Dark_Shikari> 1) copy the trick in me.c in x264 [16:19:37] <Dark_Shikari> uint32_t mv_min = pack16to32_mask2( -mv_x_min, -mv_y_min ); [16:19:38] <Dark_Shikari> uint32_t mv_max = pack16to32_mask2( mv_x_max, mv_y_max )|0x8000; [16:19:45] <Dark_Shikari> 2) increment mv_max and mv_min per-MB [16:20:03] <{V}> BBB, about 11 hours ago: <astrange> BBB: https://roundup.ffmpeg.org/issue2609 wrote a diagnosis but i might not be able to get to it (or anything else) until monday [16:20:24] <Dark_Shikari> The only trick I see is that the "min" values can be negative, so incrementing them might be tricky. [16:20:46] <Dark_Shikari> Also, if there's a lot of mv0 or things that don't require clamping, it might not be worth it [16:21:51] <BBB> {V}: thanks, I missed that [16:22:01] <BBB> my backlog isn't long enough, it seems [16:22:11] <{V}> you're welcome :) [16:22:16] <mru> solution: sleep less [16:26:16] <ubitux> mru: you're a bit hard with Nicolas :) [16:26:21] <mru> not at all [16:26:24] <mru> I'm too soft [16:26:36] <mru> but the others won't let me toast him properly [16:27:25] <ubitux> the questions are interested for a new comer like me; i guess this thread will help me to understand that stuff better [16:27:27] <av500> you are medium raw [16:27:35] <ubitux> interesting* [16:27:50] <BBB> mru is a little hostile to him, but inviting him to spill his mind so we can find what he's talking about [16:27:57] <BBB> he finally mentioned the case he's fixing [16:28:01] <BBB> we told him the fix is wrong and why [16:28:05] <BBB> now he can fix it correctly [16:37:41] <lu_zero> now we'll see [16:38:23] <lu_zero> I hope he gets at least that there isn't a "Leader", Czar, Alpha or whatever [16:40:28] <mru> you are all my mindless minions, muahahaha [16:41:35] * BBB happy to be a "mindless minion" if this is what it means [16:41:52] <BBB> I'm a mindless minion, muhahahahhahahahha [16:49:47] <Kovensky> 11:16.49 uau: Kovensky: which issue do you mean? the unreliability of mpeg timestamps is orthogonal at least <-- ffmpeg can't seek in ts, at all, IIRC (I haven't tried it myself, it's what I hear from ffms people) [16:50:37] <Kovensky> the last time I mentioned that people mentioned something to do with the seeking API using absolute timestamps and .ts by design having repeated timestamps (overflow), so it doesn't know where exactly to seek to [16:50:42] <uau> quite a posting spree on ffmpeg-dev [16:51:10] <Kovensky> this could be workarounded by having a relative seek API (which would be useful not just for .ts too) [16:52:27] * av500 sees in TS and PS using the file pos only [16:52:29] <av500> seeks [16:52:42] <Kovensky> also, is there no way to have frame-accurate seeking other than by doing it user-side? for example when seeking somewhere with precision mode on it could return the needed reference frames without a pts and then only start returning pts when you reach the specific frame requested [17:03:19] <Dark_Shikari> am I stupid, or is clip(x, y, z) equal to median(x, y, z)? [17:03:32] <Dark_Shikari> if x is less than y, the middle is y (correct value) [17:03:40] <Dark_Shikari> if x is greater than z, the middle is z (correct value) [17:03:43] <Dark_Shikari> so median is the same as clip? [17:04:54] <Dark_Shikari> or, I guess, clip is a special case of mid_pred [17:04:57] <Dark_Shikari> where y > x. [17:05:00] <Dark_Shikari> er, z>y [17:13:34] <ubitux> about "RTMP: trailing slash in content-base", can't path be ""? [17:14:03] <Dark_Shikari> BBB: Any objection to moving all the vp8 struct declarations into a vp8.h? [17:14:06] <Dark_Shikari> or what should we do with that [17:14:31] <BBB> Dark_Shikari: which struct? [17:14:48] <BBB> you want to share stuff with x86/vp8_stuff.c? [17:14:58] <BBB> in that case, yes, you can export the struct [17:15:12] <BBB> \o/ make fate-vc1 passes again [17:15:44] <BBB> let's see if it's faster [17:15:51] <j-b> hello *<tab> [17:16:00] <BBB> (btw I only did mmx so far, will do sse2 and ssse3 in a little, that's probably much more fun) [17:16:39] <ubitux> is Ronald or Martin on IRC? [17:16:48] <Dark_Shikari> BBB is ronald. [17:17:08] <ubitux> oh, ok, then BBB, can you confirm path can't be "" in the rtmp patch? [17:18:00] <j-b> and wbs is martin [17:20:33] <BBB> ubitux: we can do a len > 0 if you think that's helpful [17:20:53] <BBB> I am not familiar enough with the ffserver.c code to tell for sure... [17:22:26] <ubitux> i'm not either at all, it just looks suspicious from a quick view [17:22:39] <BBB> funny artifact: [17:22:40] <BBB> [null @ 0x101021800] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8705697 >= 8705697 [17:22:49] <BBB> and I wasn't even looking for it :( [17:25:23] <wbs> ubitux: hmm, perhaps it potentially can be "" [17:25:39] * lu_zero did something evil... [17:26:42] <BBB> what on earth is that [17:27:24] <lu_zero> -dcodec copy ^^; [17:29:08] <elenril> lu_zero: what muxers support that? [17:29:45] <lu_zero> nut, mpegts [17:29:50] <lu_zero> so far I tried that [17:31:34] <elenril> wow, even avi [17:32:09] <lu_zero> elenril: well feel free to play with the concept ^^; [17:33:54] <siretart> can someone please comment on the severity of this: https://roundup.ffmpeg.org/issue2584 [17:34:41] <siretart> the last two comments indicate that it is [17:35:14] <wbs> ubitux: and that issue actually is RTSP, not RTMP, it's Nicolas typo in the first mail ;P [17:35:45] <ubitux> wbs: ok :) [17:35:55] <peloverde> speaking of minor overreads does someone want to do that padding thing before the bump? [17:36:28] <mru> padding? [17:37:15] <peloverde> allowing codecs to specify how much input buffer padding they need [17:37:39] <mru> oh, that old one [17:38:20] <mru> there's one thing about it that bothers me [17:38:41] <mru> it means feeding information backwards from the decoder to the demuxer [17:38:48] <mru> which can be all but trivial [17:39:39] <BBB> hm [17:39:40] <BBB> yummy [17:39:46] <BBB> kurosu: 15% faster overall, one single function [17:39:51] <BBB> kurosu: that's optimizations :) [17:40:13] <BBB> wbs: no patch attached [17:40:24] <mru> BBB: I more than doubled the speed of a client's vc1 decoder with neon [17:40:38] <BBB> mru: I've only just started, give me a little time :) [17:40:48] <Dark_Shikari> BBB: what are you doing now? [17:40:55] <wbs> BBB: ah crap, new mail sent [17:40:55] <mru> and why? [17:41:20] <BBB> Dark_Shikari: evading xvp8 until end of march, I guess [17:42:53] <Dark_Shikari> really though [17:44:15] <Dark_Shikari> vp8data.h is missing include guards btw [17:44:17] <thresh> kshishkov: another nice Winter Olympics mascot, http://yaicom.ru/o/2010/11/stakasha-geroj-sochinskoj-olimpiady-foto_47472_s… [17:45:34] <BBB> Dark_Shikari: not really anything specific. I've noticed our decoding of vc1 is particularly slow and think it's not hard to fix a little [17:45:39] <BBB> Dark_Shikari: so I'm doing that a little [17:45:41] <Dark_Shikari> oh. [17:45:46] <Dark_Shikari> "a little slow" is an understatement [17:45:50] <BBB> I apologize [17:45:51] <Dark_Shikari> I wrote some opts for that a while back [17:45:53] <Dark_Shikari> I think I was the last one to. [17:45:57] <BBB> "it's a disgrace to humanity" [17:45:59] <BBB> that better? [17:45:59] <Dark_Shikari> by a while back I mean 2 years ago [17:46:01] <Dark_Shikari> lol [17:46:30] <BBB> I mean my cpu is busy with HD resolution HD content [17:46:33] <BBB> that's kind of sad [17:46:34] <Dark_Shikari> What is VP8_MAX_QUANT used for? [17:46:36] <Dark_Shikari> It isn't referenced anywhere. [17:46:38] <Dark_Shikari> watafuck [17:46:40] <elenril> who uses vc1 :/ [17:47:01] <mru> nobody [17:47:07] <BBB> is anyone going to review my patches? [17:47:08] <BBB> :-p [17:47:11] <mru> Dark_Shikari: delete it then [17:47:15] <Dark_Shikari> Oh, wait, I see where it is [17:47:18] * BBB goes work on sse2/ssse3 idct [17:47:19] <Dark_Shikari> It's in the one file I didn't look [17:47:23] <Dark_Shikari> >_> [17:47:37] <mru> vp8.c? [17:47:40] <Dark_Shikari> vp8data.h [17:47:42] <elenril> Dark_Shikari: git grep? [17:48:30] <mru> BBB: aughgggh, it's PERMUTED, not permutated [17:48:40] <Dark_Shikari> mru: repetetetive [17:49:23] <mru> pretumed [17:50:10] <lu_zero> tumated [17:50:41] <mru> tomatoed [17:57:47] <DonDiego> cu [18:03:13] <thresh> ahahhah, de icaza is sooo stupid [18:03:26] <thresh> http://tirania.org/blog/archive/2011/Feb-14.html , love the first comment [18:04:41] <mru> old joke [18:04:45] <mru> originally about java [18:05:18] <thresh> yeah I know, but suits the post really good [18:05:27] <mru> indeed [18:08:13] <j-b> de icaza, still an ass [18:08:35] <j-b> http://news.ycombinator.com/item?id=2226260 <= no gpl on WP7 [18:11:22] <Dark_Shikari> mru: so what should we do about av_always_inline and avutil? [18:11:29] <Dark_Shikari> and things like av_clip not being inlined. [18:11:48] <mru> Dark_Shikari: make it av_always_inline, do some quick sanity tests, send patch [18:12:09] <Dark_Shikari> I'd have to it to every single arch and everything [18:12:15] <Dark_Shikari> it'd be a change all over avutil [18:12:28] <mru> "all over" for on function? [18:12:34] <mru> one [18:12:41] <Dark_Shikari> I meant to always_inline everything in common.h [18:12:49] <Dark_Shikari> seems inconsistent to always_inline one clip [18:12:50] <Dark_Shikari> and not 50 others [18:14:17] <BBB> mru: I'm not native, I'm allowed to screw up :-p [18:14:22] * BBB fixes locally [18:14:25] <mru> do the change, check code size difference, speed test something likely to show a difference [18:15:05] <mru> I said quick sanity test [18:15:18] <mru> just make sure something common didn't get slower [18:15:26] <mru> like h264 on x86 [18:15:29] <mru> it's gcc after all [18:16:35] <av500> irc is more quiet than the ml today... [18:16:54] <mru> we should set up a balancing gateway [18:17:05] <av500> yes, ml overspill to irc [18:17:08] <BBB> thresh: heh :) [18:17:30] <BBB> mru: also, subject fixed too [18:17:36] <j-b> av500: hello French-lover, how are you? [18:18:29] <av500> j-b: soso [18:22:25] <uau> Dark_Shikari: gcc actually leaves the clip functions as function calls with non-forced "inline"? [18:22:57] <mru> in some cases at least [18:23:37] <Dark_Shikari> due to hitting the inline cap [18:23:50] <Dark_Shikari> some versions of gcc have a max inlined % per file [18:23:55] <Dark_Shikari> in files like vp8.c, everything is inlined [18:24:01] <Dark_Shikari> so the smallest functions don't get inlined instead [18:26:06] <BBB> I don't think we're inlining too much [18:26:36] <mru> vp8.c is a difficult case [18:26:51] <Dark_Shikari> we aren't inlining too much [18:26:52] <Dark_Shikari> GCC is dumb [18:26:59] <Dark_Shikari> because if you have a function used ONCE, and it gets inlined [18:27:04] <Dark_Shikari> it counts that against its inlined % [18:27:07] <Dark_Shikari> even though that makes NO SENSE AT ALL. [18:27:14] <Dark_Shikari> Because inlining a function used once can never hurt. [18:27:20] <mru> inlining call-once functions isn't necessarily good [18:27:26] <Dark_Shikari> Why? [18:27:31] <mru> it can pollute i-cache [18:27:39] <Dark_Shikari> But it can pollute i-cache either way. [18:27:44] <Dark_Shikari> It's the compiler's job to arrange its code. [18:27:44] <mru> only when actually called [18:28:20] <mru> if it's called rarely, keeping separate might be better [18:28:47] <mru> stays out of cache when not needed, and since it's called rarely, the call overhead is probably irrelevant [18:29:00] <mru> the compiler can't generally know the probabilities [18:29:01] <Dark_Shikari> the compiler can arrange the code like that even if it's inlined. [18:29:19] <mru> a call or a branch is pretty much the same thing [18:29:23] <mru> unless you're gcc of course [18:29:37] <mru> gcc is too stupid to use custom calling conventions for static functions [18:29:47] <mru> even though the manual says it might [18:30:02] <mru> there's some -f flag for that [18:30:07] <mru> on by default at some -O level [18:35:39] <BBB> mru: can you test a patch for me on ppc? [18:36:19] <mru> I can give you a login so you can test yourself [18:37:21] <kshishkov> BBB: you're lucky we don't have NEON optimisations for VC-1 [18:37:29] <BBB> mru: ok [18:37:33] <BBB> kshishkov: true [18:37:40] <BBB> or I can just break it [18:37:45] <mru> BBB: what's your favourite username? [18:37:46] <BBB> hm... who did that before? [18:37:49] <BBB> mru: rbultje [18:39:31] <mru> BBB: try ssh saracen.mansr.com [18:39:57] <BBB> permission denied [18:40:00] <BBB> (public key) [18:40:05] <BBB> oh wait wrong username [18:40:06] <BBB> sorry [18:40:15] <BBB> works [18:40:33] <BBB> can I just git pull? [18:40:39] <mru> sure [18:40:59] <mru> usual dev tools installed [18:41:04] <mru> lots of gcc versions [18:41:45] <BBB> ty [18:41:57] <mru> various samples in /misc/samples [18:41:59] <BBB> kshishkov: how to fix transpose()? [18:42:01] <mru> you'll figure it out [18:42:37] <mru> it's a dual-proc machine so make -j2 can save you some time [18:42:43] <mru> unless fate is running [18:43:05] <BBB> mru: --samples=? [18:43:13] <BBB> (for fate [18:43:15] <BBB> ) [18:43:27] <mru> /misc/samples/mphq/fate-suite [18:43:35] <mru> double-check that [18:44:22] <BBB> yeah that's correct [18:44:23] <BBB> thanks [18:45:51] <kshishkov> BBB: just write it without macro (maybe with comment) [18:52:50] <BBB> kshishkov: ok [18:55:03] * BBB notes ppc is slow [18:55:48] <kshishkov> it's 800 MHz [18:55:50] <kshishkov> IIRC [18:56:41] <kierank> nothing is as slow as emulating ppc through qemu [18:56:58] <BBB> it's only at mpeg4videodec.c [18:57:04] <BBB> it's been running for a couple of minutes already [18:57:12] * BBB remembers compiling ffmpeg on his P-II 400MHz [18:57:14] <BBB> that sucked [18:57:46] <Dark_Shikari> BBB: any thoughts on the mv patch? it might be slower if zero mv is very common or intra is common [18:58:07] <kshishkov> kierank: have you tried emulating x86 on non-x86? [18:58:47] <kierank> no [18:59:37] <kshishkov> well, it's hard to imagine CPU worse than x86 [18:59:59] <Dark_Shikari> mips [19:00:18] * kshishkov mourns Dark_Shikari [19:02:25] <BBB> Dark_Shikari: I thought I OK'ed that already? [19:02:32] <BBB> or a different mv patch? [19:02:39] <BBB> if it's the one from several days ago, it needs benchmarking [19:02:55] <Dark_Shikari> no, the one from today [19:03:00] <Dark_Shikari> the several days ago was already committed [19:05:19] <BBB> how do I turn off vim autoformatting? [19:06:07] <mru> use emacs [19:06:13] <Dark_Shikari> :set noai [19:06:34] <mru> vim autoformatting is a bit too stupid [19:06:40] <Dark_Shikari> My patch is kinda hard to bench, I think [19:06:44] <Dark_Shikari> because you'd have to bench the entire decode loop [19:06:48] <Dark_Shikari> and try to sneak out a few cycles [19:06:56] <Dark_Shikari> I don't have low enough stdev, not even close [19:07:03] <Dark_Shikari> My worry is too many mv0 blocks. [19:07:08] <Dark_Shikari> It would help more with mmx inline asm though. [19:10:46] <BBB> let's take the embedded x86 as a benchmark though [19:10:53] <BBB> it's gonna have performance issues at high-motion [19:10:57] <BBB> rather than mv0 [19:11:05] <BBB> therefore, we should focus on making high-motion quicker [19:11:05] <Dark_Shikari> ? [19:11:09] <Dark_Shikari> ah [19:11:13] <Dark_Shikari> true. [19:11:15] <BBB> and your patch does that [19:11:36] <BBB> right, if high-moion takes 120% cpu and mv0 takes 55% cpu, then I don't care if mv0 goe to 60 to get high-motion to 110% [19:11:42] <Dark_Shikari> yup [19:11:43] <BBB> even if mv0 is more common [19:11:48] <BBB> because you want to get both under 100% [19:11:53] <BBB> so it plays back on the stupid device [19:12:08] <BBB> kshishkov: fate vc1 passes [19:12:24] <kshishkov> BBB: resend a patch for approval then ;) [19:12:26] <j-b> vc1 interlaced? /me is out [19:12:34] <kshishkov> j-b: of course not [19:12:44] <kshishkov> j-b: even Bonald is not going to implement it [19:12:52] <kierank> Bonald B Bultje [19:12:55] <j-b> kshishkov: ok, I'll change joke (I need to find a new one) [19:13:46] <kierank> j-b: svc [19:13:52] <kshishkov> j-b: talk about WVP2, it's going to be not implemented by Dark_Shikari [19:14:44] <j-b> kierank: svc, noone will believe I am serious :D [19:14:46] <Dark_Shikari> `-` [19:15:15] * elenril stabs kshishkov [19:15:21] <elenril> go deprecate stuff in avcodeccontext [19:15:37] <kierank> j-b: how many people have requested it? [19:15:50] <kshishkov> elenril: tell it about life in Ukraine till it will selfdeprecate? [19:16:11] <kshishkov> kierank: big number of small ignore them all [19:16:40] <j-b> kshishkov: none. [19:16:44] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r1f004fc512 ffmpeg/libavcodec/x86/ac3dsp.asm: [19:16:44] <CIA-15> ffmpeg: ac3dsp: Change punpckhqdq to movhlps in ac3_max_msb_abs_int16(). [19:16:44] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [19:16:45] <j-b> kierank: none. [19:17:01] <kierank> wow, people have common sense [19:17:17] <BBB> kshishkov: I like transpose(), can I keep it pretty-please? [19:17:20] <mru> kierank: where? [19:17:21] <BBB> kshishkov: maybe under a new name [19:17:30] <BBB> kshishkov: I'm too lazy to write out that macro in full 4x [19:17:42] <kierank> mru: by not being stupid enough to request svc decoding in vlc [19:17:43] <mru> BBB: just copy&paste [19:17:52] <BBB> mru: takes effort :( [19:17:53] <mru> BBB: oh right, apple users don't believe in copy&paste [19:17:57] <kshishkov> BBB: if it doesn't clash just don't undefine it [19:18:06] <BBB> if I remove the #undef is it ok? [19:18:08] <mru> kierank: svc lol [19:18:14] <BBB> it doesn't clasg [19:18:18] <mru> clang [19:18:34] <BBB> clash [19:18:37] <kierank> now if we could get rid of the people who ask for svc in x264 every few months [19:20:20] <wbs> am I right that SVC works like each layer being it's own h264 stream - if you drop a packet in one such stream, you'll have artefacts for the rest of the GOP unless you drop that layer completely? [19:20:48] <kshishkov> probably you'll have artefacts in any case [19:20:48] <Dark_Shikari> and all layers above too [19:20:57] <wbs> Dark_Shikari: yeah [19:21:43] <mru> when they ask for svc, say x264 already supports temporal scalability (aka non-reference frames) [19:22:47] <mru> spatial scalability is more annoying [19:22:59] <BBB> kshishkov: sent [19:23:12] <mru> and I don't remember quite how it's supposed to work [19:23:12] * BBB goes work on sse2 version [19:23:15] <BBB> probably much easier [19:23:32] <mru> does the enhancement layer encode the difference against an upscaled version of the base layer? [19:23:47] <kshishkov> BBB: you have D_S for second patch to check [19:23:56] <BBB> D_S: please review patch#2 [19:24:58] <Dark_Shikari> I'll leave a fullr eview to loren, he's better at that [19:26:28] <Dark_Shikari> pmullw by 12: store the 12 to avoid loading it twice [19:26:28] <BBB> peloverde: care to review my vc1#2 patch on the mailinglist? [19:26:38] <Dark_Shikari> same with pw_6 [19:28:49] <Dark_Shikari> ... is there some reason that vc1_idct doesn't output directly to pixels? [19:28:57] <Dark_Shikari> i.e. outputs to 16-bit words instead of 8-bit? [19:29:25] <Dark_Shikari> there should be an idct_add and idct_put etc [19:29:36] <Dark_Shikari> also if you're optimizing vc1 you should fish up my old ML patch for the asm overlap filter [19:29:46] <BBB> uh, one thing at a time [19:30:12] <BBB> it does use the unrounded/clipped values for something [19:30:17] <Dark_Shikari> Go check it. [19:30:19] <BBB> but I haven't looked very carefully [19:30:30] <Dark_Shikari> If you're going to optimize, you should look carefully [19:30:32] <BBB> (i.e. I don't know what that something is, kshishkov would know) [19:30:34] <Dark_Shikari> bad to write asm and then find out you need to change it again [19:30:36] <Dark_Shikari> Read the code [19:30:55] <BBB> kshishkov: ping :-p [19:30:57] <BBB> kshishkov: ^^ [19:31:15] <kshishkov> why it operates? Because 16-bit is DCTELEM [19:31:35] <kshishkov> and look at creation date - it was written by a student more than four years ago [19:32:08] <BBB> kshishkov: does it use the unclipped values for anything? [19:32:14] <BBB> or can I clip them inside and it's ok? [19:32:43] <kshishkov> it may output to two ranges [19:33:06] <kshishkov> because of overlap even I-frames may need an additional +128 [19:34:48] <BBB> can we do that in the idct function? [19:34:59] <Dark_Shikari> just grep for idct in the c [19:35:03] <Dark_Shikari> srsly [19:35:09] <kshishkov> +0.5 [19:35:14] <BBB> hm... [19:35:16] * BBB goes look [19:38:25] <BBB> you've got to be fscking kidding me, it does a conditional <<= 1 or += 128 just for the heck of it? dude [19:38:43] <kshishkov> nope, that's special overlap mode they invented [19:38:50] <kshishkov> and intensity compensation [19:38:56] <BBB> += 128 is easy though, just packsswb instead of packuswb and then ^= 128 or so [19:39:14] <kurosu> for the vc1 idct, i'm wondering if the *12 and *6 could be somehow factored [19:39:29] <kshishkov> no gain [19:39:57] <kurosu> for the c code [19:40:20] <BBB> omg @ vc1_put_block [19:40:25] <BBB> that's a 3-level loop [19:41:06] <mru> that decoder probably needs some high-level restructuring [19:41:56] <_av500_> vc-1 is dead [19:42:31] <kshishkov> well, it's used as a base for some other decoders - like WMV9 and WMVP at least [19:43:13] <BBB> kshishkov: and they are not-dead? [19:43:41] <kshishkov> they are undead [19:44:03] <kshishkov> and Dark_Shikari wanted to write WVP2 decoder (which is also based on WMV9) [19:44:07] * Dark_Shikari punts kshishkov [19:44:52] <kshishkov> Dark_Shikari: you're the only one who showed any interest in it [19:45:00] <elenril> do we have a flvdec maintainer? [19:45:01] <kshishkov> Dark_Shikari: and you're capable of doing it [19:45:11] <BBB> kshishkov: block[k][i + j*8] = ((block[k][i + j*8] - 128) << 1) + 128; isn't that the same as block[k][i + j*8] = ((block[k][i + j*8] - 64) << 1); ? [19:45:24] <elenril> kshishkov: lies, Dark_Shikari wanted to go deprecate stuff in avcodeccontext [19:45:39] <BBB> elenril: flv=baptiste [19:45:50] <Dark_Shikari> kshishkov: no, I have no RE experience [19:45:51] <elenril> BBB: seems not [19:46:01] <elenril> MAINTAINERS says michaelni [19:46:08] <kshishkov> Dark_Shikari: time to get some! [19:46:38] <kshishkov> BBB: could be, I derived that from the spec [19:48:26] <BBB> "could be" :) [19:52:01] <mru> elenril: MAINTAINERS says a lot of things [19:53:45] <elenril> anyway, there's a patch for reading index in flv that needs some love [19:54:17] <elenril> also can i has avio renames? [19:54:33] <kshishkov> all from MN? [20:03:33] <BBB> Dark_Shikari: so you want me to include all post-idct "changes" to the coeffs into the idct function, and then include the put/add also? [20:06:15] <Dark_Shikari> I mean that idct should output to 8-bit data. [20:06:56] <mru> same as for every other decoder [20:07:28] <BBB> elenril: I'll apply the avio put/get prefixes [20:07:43] <BBB> not today though, remind me tomorrow [20:07:50] <BBB> I have a date with my wife tonight [20:09:09] <elenril> BBB: you fail at being an unsocial nerd ;) [20:09:28] <BBB> elenril: sorry, can't fix that [20:09:31] <BBB> it's in my genes [20:09:35] <BBB> or is it? [20:09:50] <BBB> "the evil plan to turn every person in the world into an unsocial nerd" [20:09:59] <BBB> next james bond title [20:10:55] <dalias> :) [20:16:51] <lu_zero> enjoy your date =) [20:19:18] <microchip_> elenril: it's asocial :p [20:21:25] <mru> or antisocial [20:21:37] <microchip_> antisocial are the psychos [20:21:46] <mru> yes, that's a step worse [20:22:05] <mru> asocial just doesn't socialise, antisocial ruins it for others too [20:22:12] <microchip_> yeah [20:22:27] * dalias wonders if antignostic is a word [20:22:41] <dalias> or better yet, anti-GNUstic :) [20:22:47] <_av500_> antipasta is one, lu_zero eh? [20:25:50] <lu_zero> uhmm [20:26:14] <lu_zero> in that case is from ante [20:26:19] <lu_zero> as in before [20:26:31] <lu_zero> so before pasta (or pasto -> meal) [20:27:29] <dalias> lol [20:28:12] <_av500_> lu_zero: no, pasta and antipasta cancel each other out, thats why you eat so much and stay slim [20:29:03] <dalias> hmm, lame compiles fine with musl :) [20:31:29] <microchip_> lol musl [20:34:01] <dalias> lol? :) [20:34:10] <microchip_> silly name :p [20:34:21] <kshishkov> yep, not very healthy [20:34:51] <lu_zero> dalias: btw why musl? [20:35:29] <kierank> If I had a ts file and I wanted to use lavf to output the stream as udp, how do I go about doing that [20:35:42] <dalias> short, unique, nice interpretations as acronym, nice homophones [20:36:09] <microchip_> dalias: you forgot the 'im' at the end :P [20:36:19] <lu_zero> microchip_: =P [20:36:34] <lu_zero> dalias: still looks quite promising [20:36:37] <lu_zero> btw [20:36:42] <dalias> microchip_, that's for when you compile pidgin against it :) [20:36:53] <lu_zero> what about using ffconf? [20:37:06] <lu_zero> (give that probably it will get more options) [20:37:09] <dalias> configure system? [20:37:12] <lu_zero> yup [20:37:47] <dalias> the options for musl are pretty much limited to target arch, compiler optimization options, and compiler warning flags [20:38:05] <dalias> i don't want to follow the uclibc path of having 20+ compiletime options to enable/disable features [20:38:14] <lu_zero> indeed [20:38:18] <dalias> that's a big part of the reason they haven't had a single release since adding nptl [20:38:29] <dalias> 20 options = 2^20 combinations = impossible to test [20:38:39] <dalias> especially when they all interact [20:39:45] <dalias> i'm thinking of having a configure script to detect (or manually set) the target, install prefix, etc. and choose nice warning options for your compiler version [20:41:26] <lu_zero> ffconf should help [20:43:04] <kshishkov> ffmru [20:43:16] <dalias> i'm thinking i could get by with something a lot smaller than ffconf [20:44:22] <lu_zero> dalias: picking just the useful bits helps [20:44:54] <dalias> i'll look at it :) [20:45:12] <dalias> *sigh* there's one nasty ICE compiling ffmpeg [20:45:22] <dalias> and the funniest part is that it goes away if i just type "make" again after it stops [20:45:46] <dalias> hard to know if it's my bug or a gcc bug, or a hardware problem [20:45:58] <mru> dalias: ICE is always gcc or hw [20:46:39] <dalias> mru, if gcc is compiled with a known-good libc, yes [20:46:49] <mru> right [20:47:02] <mru> ltrace it [20:47:14] <dalias> but since gcc is linked to musl, it's *possible* (altho unlikely) that it's a libc bug [20:47:26] <dalias> i should just get gcc 4.x working.. [20:47:49] <dalias> still using 3.4 because in early development getting 4.x to build against musl was looking too hard [20:47:53] <lu_zero> which gcc would work with musl? [20:48:17] <dalias> any gcc 3.2 and later should be able to compile musl and link programs against it (maybe 3.0 too) [20:48:45] <dalias> i know 3.2 and 3.4 build well against musl [20:49:39] <lu_zero> what's wrong with gcc-4x? [20:49:42] <dalias> mru, ltrace requires shared libs. i can just use gdb, but the problem is it's not reproducible - the crash goes away when i rerun make [20:49:58] <dalias> i'm betting it's OOM [20:50:05] <dalias> gcc probably ICE's on malloc failure [20:50:16] <lu_zero> dalias: make clean && make? [20:50:27] <dalias> and more memory is available when i rerun make after it crashes once [20:50:55] <dalias> as for gcc 4.. [20:51:49] <dalias> it has a lot more deps (all the mpc/float crap), decimal float, and wants to integrate more closely with OS threads for TLS support stuff [20:52:07] <dalias> i can disable some of that (but it's undocumented) [20:52:45] <mru> dalias: have malloc log a message if it fails [20:52:55] <dalias> and it's just a lot more to deal with "is everything this functionality needs working in musl yet?" "am i seeing a musl bug or a gcc glibc assumption?" etc. [20:52:58] <kierank> BBB: you know the URLProtocol stuff right? How hard would it be to have direct passthrough so you could stream arbitrary data over udp? [20:57:25] <BBB> kierank: well, udp is internally packetized, so that's one issue [20:58:38] <mru> I once wrote a simple app to stream out a ts file over udp [20:58:44] <mru> was about a page in size [20:58:58] <kierank> well yeah but lavf already does the igmp join stuff i need for mulitcast [20:59:10] <mru> that's 10 lines or so [20:59:47] * kierank still considers igmp magic [20:59:53] <bcoudu> wtf is that pts discussion again [21:00:06] <mru> bcoudu: ridiculous [21:00:10] <bcoudu> when people talking have the smallest clue about what's happening in the wild [21:00:42] <bcoudu> and please mru, commit your code and see how many users will complain, besides mkv stream copy issue is completely unrelated [21:00:54] <bcoudu> -> no clue [21:00:58] <mru> commit what? [21:01:10] <BBB> he probably means the pts += 1/framerate [21:01:11] <mru> mkv stream copy comes from lavf guessing incorrect dts [21:01:23] <bcoudu> be my guest and compute them [21:01:33] <mru> and it guesses wrong because it assumes an mpeg2 b-frame model [21:01:38] <mru> which isn't valid for h264 [21:02:01] <bcoudu> it doesn't [21:02:04] <bcoudu> this code is disabled [21:02:10] <mru> oh? [21:02:14] <mru> what's doing it then? [21:02:26] <bcoudu> read the code [21:02:29] <BBB> bcoudu: stop it [21:02:33] <mru> I give up [21:02:34] <bcoudu> 1/framerate doesn't work for wmv [21:02:37] <BBB> enouhg personal insults [21:02:38] <bcoudu> BBB stop it as well [21:02:44] <bcoudu> you have no clue [21:02:50] <BBB> uh, right [21:02:52] <mru> bcoudu: and you do? [21:02:56] <BBB> of course he does [21:02:58] <bcoudu> yes I do [21:03:02] <BBB> I'm an airplane [21:03:18] <mru> I actually wrote a ts muxer producing valid output [21:03:24] <mru> or valid enough for my needs [21:03:32] <mru> which were a kasenna server and amino decoders [21:03:32] <bcoudu> and every day I get hundreds of files [21:03:47] <mru> the kasenna server is exceedingly picky [21:03:51] <bcoudu> producing ts is completely different than reading files correctly [21:04:05] <BBB> enough, stop ot [21:04:08] <BBB> it* [21:04:08] <mru> it's the inverse, yes [21:05:14] <bcoudu> besides, when playing it's not a big deal if you have one or two wrong values [21:05:20] <bcoudu> when stream copying it's broken [21:13:47] <lu_zero> btw [21:14:01] <lu_zero> I guess I should add to my random data patchset [21:14:10] <lu_zero> the example code to produce it [21:14:34] <lu_zero> and then we could use it to weight how strange is libavformat. [21:14:36] <lu_zero> hint [21:14:47] <lu_zero> gdb --args ./ffmpeg_g -dump -y -i libavformat/test.nut -vcodec mpeg2video -acodec copy -dcodec copy /tmp/test.nut [21:18:31] <lu_zero> gets [21:18:34] <lu_zero> "fun" [21:21:52] * lu_zero finds yet another bug in his code meanwhile [22:04:56] <CIA-15> ffmpeg: Carl Eugen Hoyos <cehoyos(a)ag.or.at> master * r2e3c56a29f ffmpeg/libavcodec/mjpegdec.c: [22:04:57] <CIA-15> ffmpeg: Set maximum lowres value for the MJPEG decoder to 3. [22:04:57] <CIA-15> ffmpeg: While 4 works for some samples, 3 is the correct value since 8x8 [22:04:57] <CIA-15> ffmpeg: DCT is used by (m)jpeg. [22:04:57] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [22:05:07] <CIA-15> ffmpeg: Michael Niedermayer <michaelni(a)gmx.at> master * r50a82c2c75 ffmpeg/libavcodec/options.c: [22:05:07] <CIA-15> ffmpeg: vbv_delay AVOption for ABI compatibility [22:05:07] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni(a)gmx.at> [22:05:07] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [22:19:44] <Jumpyshoes> BBB: for avx support for ffmpeg, i need a function similar to x264_cpu_xgetbv, but it's written in yasm in x264... i could probably do it in inlined asm, but could you do it if you have time? [22:19:54] * Jumpyshoes is not comfortable with futzing around with inlined assembly [22:20:40] <mru> didn't Dark_Shikari already post a patch for that? [22:21:17] <mru> http://patches.ffmpeg.org/patch/779/ [22:21:57] <Jumpyshoes> oh, it seems like he did. has it been pushed? [22:22:02] <mru> no [22:22:51] <Jumpyshoes> also seems there has been no activity for 10 days or so, can i bump it? [22:23:46] <mru> it needed some fixes [22:23:59] <mru> feel free to fix it and resubmit [22:24:39] <Jumpyshoes> hrm, okay [22:25:08] <dalias> i hate gcc [22:25:20] <dalias> how the hell do you pass CPPFLAGS to configure to build gcc? [22:25:22] <mru> dalias: feeling's probably mutual [22:30:17] * lu_zero notices there is something more wrong... [22:31:20] <lu_zero> but seems working to a point now =P [22:32:04] * lu_zero now needs to make sure mpegts keeps the data [22:32:15] <mru> floating point or fixed point? [22:33:19] <lu_zero> fixed for nut [22:33:29] <lu_zero> floating around on mpegts =P [22:33:54] <lu_zero> it claims to do stuff but you don't get anything in the file in the end =-= [22:35:42] * lu_zero opens the ts file with an editor... [22:35:47] <lu_zero> the packets seems here [22:37:43] <dalias> haha i eventually just went with CC="gcc -D_GNU_SOURCE" [22:38:15] <mru> why would you want that? [22:47:37] <astrange> BBB: the existence of files with input packet count != output packet count makes it difficult to implement timestamps entirely in libavformat [22:48:37] <astrange> BBB: for instance, if you take an h264 file with mixed PAFF/not PAFF, and assign the same timestamp increment to each packet, some of your frames will display twice as long. it could work if we had completely implemented AVParser [22:52:53] <mru> timestamp increment should be per frame, not per packet or field [22:52:55] <mru> of course [23:07:05] <iive> of course. If there is a way to distinguish them. [23:08:06] <mru> parse the frame headers, duh [23:09:02] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r009026efb1 ffmpeg/tools/graph2dot.c: [23:09:02] <CIA-15> ffmpeg: In graph2dot, print more specific audio information for audio links. [23:09:02] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [23:09:11] <CIA-15> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r6c60fcf89a ffmpeg/libavformat/spdifenc.c: [23:09:11] <CIA-15> ffmpeg: spdifenc: set flag AVFMT_NOTIMESTAMPS [23:09:11] <CIA-15> ffmpeg: There are no timestamps in IEC 61937. [23:09:11] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [23:09:13] <CIA-15> ffmpeg: James Zern <jzern(a)google.com> master * r0fa904c9d8 ffmpeg/doc/ (encoders.texi ffmpeg.texi): [23:09:13] <CIA-15> ffmpeg: documentation: add encoders chapter [23:09:13] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [23:11:58] <Sean_McG> evening folks [23:12:27] <mru> good $localtime [23:12:33] <Sean_McG> mru :) [23:12:51] <jannau> mru: can you push http://patches.ffmpeg.org/patch/981/ FATE_SAMPLES env variable? [23:13:06] <mru> jannau: will do later [23:14:37] <Sean_McG> is mplayer svn supposed to be able to be built against ffmpeg HEAD? [23:14:46] <mru> no idea [23:15:03] <mru> DonDiego would know, but he's not here [23:15:15] <Sean_McG> I just tried here (I used to build it against astrange's ffmpeg-mt branch) and I'm getting swscale missing symbols [23:15:30] <mru> that's odd [23:16:17] <Sean_McG> I'll ask the mplayer folks [23:17:20] <lu_zero> Sean_McG: which missing symbol? [23:17:29] <Sean_McG> quite a few [23:20:42] <lu_zero> mind providing me a list? [23:21:11] <Sean_McG> oh wait shit no... this is a local build issue, ignore me [23:21:29] <Sean_McG> those libs are distinctly missing from the link line [23:21:43] * Sean_McG pokes it with a stick [23:22:06] <Sean_McG> probably because I've been mucking around with paths [23:22:19] <lu_zero> ^^; [23:22:38] <uau> Sean_McG: generally mplayer svn may fail to compile against any new ffmpeg revision, as it uses internal symbols which are not part of the API (even if that's not the problem you hit) [23:23:01] <Sean_McG> uau: but ffmpeg-mt wouldn't have had the same problem? [23:23:16] <uau> i cleaned that up for mplayer2, that should compile reliably against all ffmpeg versions [23:23:24] <uau> i'm not sure what you're asking [23:23:46] <mru> uau: btw, why mplayer2 and not something from scratch? [23:23:56] <Sean_McG> anyways yeah don't worry about it too much, I'm pretty sure this is my fault [23:24:30] <uau> mru: you mean why didn't i write a player from scratch? there's still useful code in mplayer even if much of it sucks [23:24:58] <uau> less work to modify it than start writing a player from scratch [23:25:01] <mru> separating suck from non-suck is often harder than writing new code [23:25:46] <uau> well not for me really [23:25:46] <Sean_McG> if this is pkg-config crap I'mma scream [23:26:00] <uau> i've done architecture improvement changes before in other programs [23:26:31] <uau> and i find it easier to work with some existing code [23:27:41] <uau> also i couldn't personally test all the stuff like video/audio drivers [23:28:27] <uau> that kind of stuff couldn't be rewritten by one person alone [23:28:52] <uau> and if you started writing something from scratch it probably wouldn't interest others until after it was already reasonably complete [23:29:31] <mru> depends on how superior the working parts are [23:31:23] <uau> well i find it easier to also write new parts when there's already existing infrastructure - even if flawed - that can be used as scaffolding to use/test the new stuff [23:31:36] <lu_zero> Sean_McG: how? [23:31:54] <Sean_McG> I'm still looking to see WTF is going on [23:32:18] <mru> uau: ok, if that's how you like to work [23:32:23] <mru> uau: I was just curious [23:36:54] <Sean_McG> oh snap, it's looking for avcore.h! [23:37:02] <Sean_McG> which um, just disappeared yesterday [23:39:14] <CIA-15> ffmpeg: Nicolas George <nicolas.george(a)normalesup.org> master * r6741f7c9be ffmpeg/ffserver.c: (log message trimmed) [23:39:14] <CIA-15> ffmpeg: ffserver: set the sample aspect ratio [23:39:14] <CIA-15> ffmpeg: Hi. [23:39:14] <CIA-15> ffmpeg: It seems that ffserver sets sample_aspect_ratio to an invalid value and lavf [23:39:14] <CIA-15> ffmpeg: rejects it. [23:39:15] <CIA-15> ffmpeg: I am not sure what I am doing here, but the attached patch actually solves [23:39:16] <CIA-15> ffmpeg: something: using the following config: [23:39:24] <CIA-15> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r2c35a6bde9 ffmpeg/libavformat/rtsp.c: [23:39:24] <CIA-15> ffmpeg: rtsp: udp_read_packet returning 0 doesn't mean success [23:39:24] <CIA-15> ffmpeg: If udp_read_packet returns 0, rtsp_st isn't set and we shouldn't [23:39:24] <CIA-15> ffmpeg: treat it as a successfully received packet (which is counted and [23:39:25] <CIA-15> ffmpeg: possibly triggers a RTCP receiver report). [23:39:25] <CIA-15> ffmpeg: This fixes issue 2612. [23:40:11] <uau> bad commit message? [23:40:22] <lu_zero> uhm [23:40:39] <lu_zero> grr [23:40:46] <mru> lu_zero: looks like you piped the entire message to git, not just the attachment [23:40:51] <lu_zero> git am had been overzealous [23:40:54] <lu_zero> =_= [23:41:02] <mru> I always double-check these things before I push [23:41:22] <uau> do the ffmpeg-commits mails not show committed anywhere? [23:41:28] <uau> committer [23:41:31] <mru> since the time I made that mistake [23:41:37] <lu_zero> I should do as well [23:42:01] * lu_zero doublechecked the diff but not the log =| [23:42:29] <uau> looks like mplayer2 will also have one issue with the libavcore re-merge, though not that configure one [23:42:41] <uau> there's '#include "libavcore/imgutils.h"' in one file [23:43:17] <uau> though apparently that's an mga video out file which is not compiled by default [23:43:30] <lu_zero> uau: that's from mplayer? [23:44:59] <uau> well that include line is from mplayer2 specifically if that's what you were asking (only explicit mention of avcore) [23:45:53] <uau> mplayer 1 also contains that, plus several other mentions due to the ugly embedded ffmpeg build hacks [23:48:36] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r610219a598 ffmpeg/ (8 files in 2 dirs): [23:48:36] <CIA-15> ffmpeg: lavf: add av_ prefix to dump_format() [23:48:36] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:48:39] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rf6c7375a17 ffmpeg/ (8 files in 3 dirs): [23:48:39] <CIA-15> ffmpeg: Deprecate parse_date() in favor of av_parse_time(). [23:48:39] <CIA-15> ffmpeg: The new av_parse_time() is created in libavutil/parseutils.h, all the [23:48:39] <CIA-15> ffmpeg: internal functions used by parse_date are moved to [23:48:40] <CIA-15> ffmpeg: libavutil/parseutils.c and made static. [23:48:40] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:48:43] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r5b54d4b376 ffmpeg/ (3 files in 3 dirs): [23:48:43] <CIA-15> ffmpeg: ac3enc: fix bug in stereo rematrixing decision. [23:48:43] <CIA-15> ffmpeg: The rematrixing strategy reuse flags are not reset between frames, so they [23:48:43] <CIA-15> ffmpeg: need to be initialized for all blocks, not just block 0. [23:48:43] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:48:54] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r9fcae9735e ffmpeg/ (ffserver.c libavformat/rtsp.c): [23:48:54] <CIA-15> ffmpeg: Replace remaining uses of parse_date with av_parse_time. [23:48:54] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:52:27] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r610219a598 ffmpeg/ (8 files in 2 dirs): [23:52:27] <CIA-15> ffmpeg: lavf: add av_ prefix to dump_format() [23:52:27] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:52:31] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rf6c7375a17 ffmpeg/ (8 files in 3 dirs): [23:52:31] <CIA-15> ffmpeg: Deprecate parse_date() in favor of av_parse_time(). [23:52:31] <CIA-15> ffmpeg: The new av_parse_time() is created in libavutil/parseutils.h, all the [23:52:31] <CIA-15> ffmpeg: internal functions used by parse_date are moved to [23:52:32] <CIA-15> ffmpeg: libavutil/parseutils.c and made static. [23:52:32] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:52:35] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r5b54d4b376 ffmpeg/ (3 files in 3 dirs): [23:52:35] <CIA-15> ffmpeg: ac3enc: fix bug in stereo rematrixing decision. [23:52:35] <CIA-15> ffmpeg: The rematrixing strategy reuse flags are not reset between frames, so they [23:52:35] <CIA-15> ffmpeg: need to be initialized for all blocks, not just block 0. [23:52:35] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:52:36] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r9fcae9735e ffmpeg/ (ffserver.c libavformat/rtsp.c): [23:52:37] <CIA-15> ffmpeg: Replace remaining uses of parse_date with av_parse_time. [23:52:37] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:52:41] <mru> oops [23:52:50] * mru playing with the notificatino script

1 0

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

16 Feb '11

[00:02:42] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r77c330a046 ffmpeg/doc/APIchanges: [00:02:42] <CIA-38> ffmpeg: APIchanges: update for 12c14cd [00:02:42] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:03:05] <mru> Sean_McG: ever used Alpha systems? [00:03:29] <Sean_McG> only when I worked at a hospital... and it ran OpenVMS *shudder* [00:03:59] <Sean_McG> replaced an aging VAX [00:16:17] <Sean_McG> I'll always love POWER/PPC, but after Apple abandoned it obviously my exposure has been basically zero since I don't own an RS/6000 or System/p [00:16:42] <mru> any machine with an eieio instruction has to be good [00:16:57] <Sean_McG> heheheh [00:22:17] <roxfan> pfft eieio [00:22:28] <Sean_McG> roxfan: HCF? [00:22:28] <mru> best instruction ever [00:22:46] <Sean_McG> Halt & Catch Fire, for the uninitiated [00:22:47] <roxfan> what about sleep, doze, nap _and_ rvwinkle? [02:53:26] <kierank> Compn: do you know if we have any samples with e-ac3 in ts [02:53:42] <Jumpyshoes> BBB: want me to write avx asm for ffmpeg? i'd need to port the abstraction layer [02:54:00] <Dark_Shikari> and by port you mean "cp" [02:54:17] <Jumpyshoes> :D [02:54:51] <bcoudurier> kierank, we do from the french tv channels :) [02:58:15] <Compn> kierank : uhhhhhhh [02:58:19] <Compn> whats e-ac3 usually in ? [02:58:27] <Compn> m2ts ? [02:58:28] <kierank> .ts or .m2ts [02:58:46] <kierank> but i'm looking for hdtv samples [02:58:47] <bcoudurier> kierank, aren't the ones in allsamples good ? [02:58:59] <bcoudurier> or ask j-b he probably has some [02:59:08] <bcoudurier> justin for sure I think [02:59:20] <Compn> kierank : no clue, the ones in allsamples are the only ones i know of [02:59:22] <Compn> :( [02:59:42] <Compn> theres also a bunch of .ts in incoming probably [02:59:42] <kierank> maybe i should go on a day trip and capture some eac3 ;) [02:59:45] <Compn> no one cleans it out [03:00:23] <Jumpyshoes> BBB: if you ping me later, it might be better to do it in #x264dev since i actually read the backlog for that channel [03:01:20] <bcoudurier> kierank, search in vlc forum [03:01:35] <kierank> that's a good point [03:01:41] <bcoudurier> french tvs were using eac3 spectral [03:01:51] <bcoudurier> and that caused some bug reports [03:07:34] <kierank> yay found one [03:17:27] <Sean_McG> OK, looking at this VP8 AltiVec thing my first gripe is with the use of macros in vp8dsp_altivec.c [03:17:54] <Sean_McG> wondering why it couldn't have been written as an inline function [03:37:57] <kierank> ruggles: why do you use bsid of 8 in the ac3 encoder? [03:39:02] <kierank> afaik nobody uses 8 any more [03:39:05] <kierank> everybody uses 6 [05:44:30] <CIA-38> ffmpeg: Young Han Lee <cpumaker(a)gmail.com> master * read15f1dc1 ffmpeg/libavcodec/ (aac.h aacdec.c aacdectab.h mpeg4audio.h): [05:44:31] <CIA-38> ffmpeg: aacdec: Implement LTP support. [05:44:31] <CIA-38> ffmpeg: Ported from gsoc svn. [05:45:47] <saintdev> \o/ [05:47:35] * pJok prods saintdev to fix ffaacenc [05:47:56] <saintdev> eek, now elenril has got you at it as well [05:48:00] * Sean_McG cheers too [05:48:20] <pJok> it needs fixing [05:48:25] <pJok> and people keep saying you can fix it :P [05:49:00] <Sean_McG> I think I'd like to take a crack at fixing these VP8 AltiVec problems, unless someone else is already looking at it? [05:50:08] <pJok> saintdev, and fix mpeg1 layer 2 audio while you're at it [05:50:17] <saintdev> yeah right [05:50:27] <saintdev> i have absolutely no use for that [05:52:40] <pJok> saintdev, was worth a try :P [07:44:04] <cartman> moin [07:46:02] <Flameeyes> hi cartman [08:00:23] <siretart> morning [08:00:33] <thresh> moroning [08:00:36] <siretart> what do you think about: http://mpeg.chiariglione.org/meetings/daegu11/daegu_press.htm? [08:03:06] <cartman> lo Flameeyes [08:03:54] <Flameeyes> siretart: uhm given the guy's address is in Turin I'd ask lu_zero when he wakes up :) [08:04:30] * av500 lols at the fact that MPEG does not own mpeg.org [08:04:57] <peloverde> MVC in TS, just what I always wanted [08:04:59] <siretart> yeah, that's indeed hilarious [08:06:00] <saintdev> av500: they're video guys, not internets guys. =P [08:06:35] <av500> what happens if chiariglione steps down as mpeg BDFL? [08:09:31] <astrange> they all move to IETF? [08:10:25] <peloverde> they put me in charge [08:11:06] <siretart> I espc. like this part: "...MPEG will issue a call for proposals on video compression technology at the end of its upcoming meeting in March 2011 that is expected to lead to a standard falling under ISO/IEC âType-1 licensingâ, i.e. intended to be âroyalty freeâ." [08:11:46] <siretart> seems like a great opportunity for the free software community [08:12:39] <Flameeyes> I wonder if we can go lobby in Geneve, or Turin :P [08:12:48] <av500> siretart: you mean the free codec community [08:13:04] <av500> or is ffmpeg not free sw? [08:13:43] <siretart> av500: I consider ffmpeg as part of the free software community, but of course, you're right, ffmpeg of course included [08:13:59] <Flameeyes> av500: depends who you ask; gnu probably finds ffmpeg evil! [08:14:15] <Flameeyes> we dare provide users with support for codecs that are used out there! [08:14:29] <siretart> do we care about their opinion on us? [08:14:34] <av500> siretart: it was my lame attempt to troll you into making some patent remark :) [08:14:50] <siretart> av500: ok. your attempt has failed then ;-) [08:15:26] <Flameeyes> siretart: I don't :D [08:16:15] <Flameeyes> I'm an happy GNU (emacs) user but that doesn't mean I have to subscribe to everything that passes for a good idea in their minds ;) [08:16:50] <siretart> Flameeyes: ah, btw, it might very well be possible that we could arrange ipv6 to midas soon. seems that things look much better with squeeze, so it might work after we've upgraded the host. [08:17:31] <Flameeyes> siretart: good to hear! let me know even if you need a guinea pig to get it tested [08:18:13] <siretart> Flameeyes: sure. but first I'd prefer to experiment with (other) internal hosts first before doing that to customer hosts [08:19:24] <Flameeyes> of course :) â btw if you're looking at general fixes and improvements, would you mind taking a look at entropy as well? it seems like the vservers end up with very feeble entropy (and no way to inject more even with stuff like timer_entropyd), can be bad for https afaict [08:20:18] <siretart> oh, interesting. I should add that to the collectd monitoring then. thanks for the hint [08:21:19] <Flameeyes> np â for my boxes here I ended up getting the entropykey that I read wonders of on planet debian ;) [08:22:36] * kshishkov is a bit proud of http://satwcomic.com/art/nuclear-power.jpg [08:23:46] <Flameeyes> lol [08:24:25] <vipw> why is the french guy wearing a swedish shirt? [08:24:46] <kshishkov> what France has to do with that? [08:25:03] <av500> they have the most non working nucular power plants [08:25:24] <kshishkov> and Ukraine hold the record for peak nuclear plant productivity indeed [08:25:41] <thresh> who needs plants when one can have weaponry [08:25:53] <vipw> most nuclear power in the world is either france(per capita or as pct of total) or usa (watt capacity) [08:26:20] <superdump> perhaps they meant in scandinavia [08:26:36] <kshishkov> thresh: most of Soviet nuclear weapons ended as nuclear fuel for US plants [08:27:08] <vipw> i have the most nuclear power in the whole scandinavia!! kneel before zod! [08:27:09] <kshishkov> superdump: would you like it labeled for furniture instead? [08:27:40] * pJok makes kshishkov fix mpeg1 layer 2 audio instead [08:28:00] <Flameeyes> if somebody didn't guess that already, trying to draw UML diagrams with a mouse having a faulty left button is no fun. at all. [08:28:31] <av500> Flameeyes: you can make window swap the buttons [08:28:33] <av500> +s [08:28:49] <vipw> wbs: i found a fairly complete (but very ugly) implementation of http-live-streaming in boxee [08:28:51] <kshishkov> pJok: do you want me to adapt ffaacenc for producing layer2? [08:28:52] <Flameeyes> av500: osx and it's bothersome to swap them as well :P [08:29:35] <vipw> but it includes encryption support as well as adaptive bandwidth switching [08:29:42] <pJok> kshishkov, dunno, i just wish people would stop wanting layer 2 audio for broadcasting... [08:30:06] <pJok> kshishkov, they always demand peak perfect audio, which ffmpeg isn't able to produce [08:30:10] <wbs> vipw: mmkay [08:31:13] <kshishkov> pJok: I may look at it eventually [08:32:16] <pJok> kshishkov, last time i fixed it by sending them what they'd encode to anyways for broadcast... but now there are someone else wanting it again... what is it with broadcasters and 50mbit mpeg2 iframe only and compressed audio? [08:32:33] * pJok would rather deliver everything in IMX30 [08:33:28] <vipw> does anything in libavformat support adaptive bandwidth? [08:34:05] <kshishkov> ffaacenc classic? It had not so reliable bitrate control [08:34:33] <wbs> vipw: not automatically adaptive, but both realrtsp and our applehttp stuff can choose which bandwidth variant to use by setting the discard flags on the different avstreams [08:34:42] <vipw> with http it's trivial to measure how long it takes to download an X-second segment, and adapt from that [08:35:08] <wbs> vipw: except that it requires the download not to be waiting outside of library anywhere [08:35:47] <vipw> i don't think i follow you [08:36:19] <wbs> since the user calls av_read_frame(), which internally calls url_read() on the urlprotocol, which does the http reading [08:36:29] <Flameeyes> vipw: it's hard to account for the latency between libavformat and the connection itself, if I read wbs right [08:36:35] <av500> can we have this channel without voice and play ffmpeg-devel-karaoke? [08:36:50] <wbs> if the user calls av_read_frame() immediately again and doesn't do anything else inbetween, you'd get a fairly ok estimate of the bandwidth [08:37:21] <wbs> but if you decode frames or think you've already buffered enough data and don't read more data yet, you won't measure what the connection actually is capable of [08:37:52] <wbs> e.g. ffplay only buffers up to a certain amount, then it waits until the playing consumes some data before fetching more [08:38:06] <vipw> oh, i thought that individual segments were downloaded full-throttle [08:38:13] <av500> that buffer could be used with high/low water mark to select streams [08:38:43] <av500> hmm [08:39:00] <wbs> vipw: that wouldn't be feasible in a non-threaded setup I think [08:39:11] <wbs> or perhaps it would be [08:40:33] <Flameeyes> don't think it would be.. [08:40:33] <j-b> kierank? [09:04:34] <siretart> DonDiego: Flameeyes: FYI: the transition from ffmpeg 0.5 -> 0.6 in debian has started. progress is tracked here: http://release.debian.org/transitions/ffmpeg.html [09:06:16] <cartman> no way [09:06:47] <av500> lu_zero: wbs: http://www.mail-archive.com/live-devel%40lists.live555.com/msg02258.html [09:06:54] <spaam> so next year debian going to have -mt ;D [09:06:54] <av500> ever heard of that issue? [09:07:52] <wbs> av500: yes, I've seen youtube rtsp servers not supporting tcp [09:08:10] <av500> wbs: and the "udp hole punch"? [09:08:28] <av500> to make it work behind a firewall [09:08:31] <wbs> av500: we do that since last year, patch by yours truly [09:09:27] * av500 <3 wbs [09:11:05] <cartman> http://nokiaplanc.com/ heheh [09:11:37] <av500> nice [09:15:10] <cartman> my fate is not green [09:15:12] <cartman> damn you all [09:15:46] <saintdev> cartman: lol [09:16:27] <Flameeyes> cartman: build failure? :D [09:16:39] <cartman> Flameeyes: nah VP8 tests failing with clang 2.9 trunk :( [09:16:44] <cartman> optimizationfail [09:16:57] <Flameeyes> isn't that an old one? [09:17:04] <cartman> yeah 4 days old [09:17:05] <cartman> :P [09:17:19] <Dark_Shikari> lol clang [09:17:27] <cartman> Dark_Shikari: you bastard [09:17:36] <Dark_Shikari> not my fault clang sucks `-` [09:17:56] * cartman needs a green fate so in case of a compile failure he can bisect clang [09:19:26] <kshishkov> make! [09:19:54] <cartman> s/k/t/ [09:20:01] <pJok> make.believe? [09:20:14] <kshishkov> cartman: for Peter - yes, for you - make it [09:20:28] <cartman> kshishkov: dual birds with one stone [09:21:59] <Flameeyes> cartman: are the birds parallel at least? [09:22:09] <cartman> maybe :P [09:23:23] <kshishkov> Flameeyes: and fast as unladen African swallows [09:24:02] <spaam> wbs: yo. do you have any rtp streams? :) [09:24:04] <pross-au> Chaps [09:24:14] <wbs> spaam: a few [09:24:25] <cartman> spaam: wbs streams kitten pr0n 24/7 [09:24:29] * Flameeyes got UML models of RTP streams >_< [09:24:31] <cartman> its all meowwww all night long [09:24:32] <spaam> cartman: Nice [09:24:36] <wbs> Flameeyes: :-) [09:24:48] <spaam> wbs: can you share some of them? :) [09:24:52] <Flameeyes> wbs: I'm basically rewriting lscube.. in UML =_= [09:24:56] <spaam> wbs: if they are over utp :) [09:25:16] <Flameeyes> spaam: what if they are in fiber? [09:25:24] <wbs> spaam: rtsp://albin.abo.fi:7070/sample_100kbit.mp4 [09:25:46] <wbs> spaam: is both udp or tcp depending on what the client requests [09:26:03] <kshishkov> pross-au: I read an article about constant M$ failure with storage technologies. It mentioned their attempts on structured file system (OLE crap for example), you are working on another one (aka WTF^HV) [09:26:13] <spaam> wbs: ok :) how do i get it as udp with ffmpeg? :) ?protocol=udp ? [09:26:23] <cartman> [aac @ 0x101014a00] RTP: PT=61: bad cseq d30e expected=f1df [09:26:23] <cartman> [mpeg4 @ 0x101010000] RTP: PT=60: bad cseq 02c7 expected=39bd [09:26:24] <cartman> nice [09:26:24] <spaam> Flameeyes: too bad for me. [09:26:25] <cartman> :D [09:27:09] <wbs> spaam: ffplay <url> should try both udp, and if you don't get any packets, it should fall back to tcp after a while [09:27:12] <Flameeyes> spaam: ya know, twisted pair doesn't work well on long distance ;) [09:28:16] <spaam> Flameeyes: damn it! ;S then you need to get the stream to malmÃ¶ [09:28:30] <spaam> wbs: cool :) [09:30:37] <kshishkov> spaam: no problem, Mediterranean -> Atlantic Ocean -> Northern Sea [09:33:34] <spaam> wbs: got rtsp from it ;S [09:35:22] <spaam> oh [09:37:06] <spaam> didnt work.. [09:37:12] <wbs> spaam: rtsp, which sets up two rtp/udp sessions, yes [09:38:58] <spaam> mm.. [09:39:36] <spaam> i got something that should not be rtp and so i need to fix it : ) [09:42:53] * pJok drags a fiber to spaam [09:44:35] <av500> http://webm.googlecode.com/files/Realtime_VP8_2-9-2011.pdf [09:45:35] <KotH> grüezi [09:46:52] <kshishkov> shalom [09:48:02] <spaam> pJok: yay ;D then we have another isp at the office ,D now we have comhem and telia :D [09:49:23] <kshishkov> spaam: so each computer has its own ISP? [09:50:00] <spaam> kshishkov: no.. two computers have one isp.. all the others have the other one :) [09:50:49] <spaam> the first two we use for srs bizniz. like play games, watch weird .cn p2p video.. [09:53:21] <kshishkov> "weird .ch" is like "crazy Norrlander", totally redundant [09:54:16] <kshishkov> err, "weird .cn" too [10:13:44] <pross-au> kshishkov: i wonder what comes after wtv.. [10:14:15] <av500> wbs: any idea why tcp.c would suddenly report: Failed to resolve hostname www....: Name or service not known [10:15:18] <wbs> av500: hmmm, no idea... sometimes on some OSes, a failure is cached instead of retried (in many different applications) [10:16:27] <av500> its strange, same address works with curl [10:16:32] <av500> but not from tcp.c [10:16:50] <av500> and tools like ping or traceroute are able to resolve it as well [10:18:40] <saintdev> pross-au: wtw ? [10:19:27] <pross-au> wtv: television disk-streaming format found in Windows Vista/7 [10:19:47] <saintdev> so "wtw" would be next [10:19:56] <saintdev> then wtx [10:19:58] <saintdev> =P [10:20:01] <pross-au> Ah [10:20:28] <kshishkov> or wpv for Windows Phone [10:20:46] <saintdev> 'p' doesn't come after 't' [10:20:58] <saintdev> well it does, but not directly after it [10:21:07] <kshishkov> is M$ known for logic? [10:21:22] <saintdev> erm.. [10:21:25] * saintdev is tired [10:21:28] <wbs> av500: hmm, weird [10:21:50] <kshishkov> saintdev: why, you haven't produced anything for ffaacenc, have you? [10:21:53] <pross-au> C'mon, its 2011, we're no longer restricted to three character filenames. [10:22:09] <kshishkov> it's tradition, mate [10:22:19] <pross-au> then it should be in uppercase TOO [10:22:43] <kshishkov> internally they probably are - it's case-insensitive anyway [10:22:49] <saintdev> filename.ext NO EXCEPTIONS [10:22:59] <kshishkov> prn [10:23:05] <pross-au> PRN$ [10:23:14] <pross-au> or was the dollar in front, i forget [10:23:32] <saintdev> longfi~1.ext [10:24:52] <kshishkov> or extension.notsoshortfilename for libavseq devs [10:25:22] <saintdev> they hate DOS [10:25:50] <kshishkov> nope [10:26:03] <kshishkov> only M$ DOS, PC DOS and DR DOS [10:26:12] <kshishkov> AmigaDOS was fine for them [10:26:39] <saintdev> yeah, but who uses that. 99% of the world used MS [10:27:12] * kshishkov points to USA aka Unique Shoppers at Apple [10:42:09] <superdump> av500: any idea who authored that pdf? it wasn't BBB was it? [10:42:17] <superdump> ah no [10:42:19] <superdump> january 2010 [11:38:39] <av500> wbs: found it, getaddrinfo() has issues in a chroot [11:46:01] <wbs> av500: oh, that's interesting, any references to that issue? [11:48:47] <av500> yes [11:49:22] <wbs> ah, found some info [11:50:48] <av500> yes, needed 2 more libs copied [11:59:25] <av500> wbs: btw, playing m.youtube stuff give me a lot of video errors. vlc has way less [11:59:48] <wbs> av500: hmm, any sample url? [11:59:54] <av500> sure [12:00:02] <av500> "rtsp://v3.cache3.c.youtube.com/CjYLENy73wIaLQmVlK-fWDADMRMYESARFEIJbXYtZ29v…" [12:00:18] <j-b> wbs: did you manage to extort money? [12:00:35] <av500> wbs: but sound is OK [12:01:00] <wbs> j-b: working on it, got a mail today that they should be ok with it [12:01:22] <j-b> nice [12:01:38] <av500> j-b: where can I extort money too? [12:01:56] <cartman> your bank account [12:02:09] <wbs> av500: try adding -max_delay 100000 to the ffplay command line, then it's almost warning free for me [12:03:07] <j-b> av500: vlc-devel@ [12:03:46] <lu_zero> av500: iirc that is udp only [12:03:53] <av500> lu_zero: yes [12:04:04] <lu_zero> and we do still are decode loop driven [12:04:13] <lu_zero> so we will miss frames [12:04:18] <av500> meaning? [12:04:30] <lu_zero> you can be network loop driven [12:04:58] <lu_zero> so your loop ticks every time you have something from the network [12:05:04] <lu_zero> or you can be decode loop driven [12:05:22] <lu_zero> so you move forward once you need more to decode [12:05:37] <av500> lu_zero: actually I am busrting [12:05:40] <av500> bursting [12:05:45] <av500> I have a big buffer for packetsd [12:05:49] <lu_zero> uh? [12:06:13] <av500> lu_zero: the system still assumes the data might come from a hdd [12:06:21] <av500> which needs to sleep most of the time [12:06:50] <lu_zero> looks like I'm missing something [12:06:58] <lu_zero> which is the system? [12:07:03] <av500> my system [12:07:06] <av500> I use lavf for rtsp [12:07:08] <lu_zero> ok... [12:07:09] <av500> I try to [12:07:13] <av500> ffplay is just for testing [12:07:27] <lu_zero> and your problem is that the udp proto is unsuitable [12:07:38] <lu_zero> tcp I bet works fine =P [12:07:38] <av500> so, what is -max_delay xx in the lavf api? [12:07:46] <av500> lu_zero: nope, there is no tcp here [12:07:49] <av500> its udp only [12:08:02] <lu_zero> =\ [12:08:07] <wbs> av500: AVFormatContext->max_delay [12:08:52] <av500> yup [12:08:54] <av500> thx :) [12:09:04] <av500> lets try to set that [12:10:17] <wbs> hmm, weirdly enough, the packets do seem to arrive in order, so that shouldn't help much, but it apparently seems to make the buffering behaviour work better for ffplay at least ;P [12:13:54] <wbs> no, there sure is some jitter. not much, but a little, and setting max_delay reorders packets for those cases, working exactly as intended \o/ [12:14:35] <wbs> av500: nice video btw ;P [12:14:55] <av500> wbs: it was a random click on that m.utub size [12:14:57] <av500> site [12:15:18] <av500> wbs: did you build one by now? [12:15:37] <wbs> av500: build a what? [12:18:53] <lu_zero> youtube? [12:19:20] <cartman> http://i.imgur.com/M52mw.png LOL [12:21:34] <av500> wbs: well, that love ring [12:21:51] <wbs> av500: aah, not yet [12:22:50] <kshishkov> cartman: well, seems the book found its reader [12:23:26] <cartman> kshishkov: absolutely [12:25:40] <lu_zero> uh [12:25:48] <av500> wbs: setting that does nothing in my app :( [12:26:26] <wbs> av500: hmm, how old lavf do you use? I think that was added in october/november sometime [12:26:27] * lu_zero wonders what will happen now, Berlusconi got http://www.bbc.co.uk/news/world-europe-12083491 [12:27:24] <av500> wbs: I see it in rtsp.c [12:27:34] <Flameeyes> lu_zero: they'll just make another Lodo Al Nano [12:28:37] <wbs> av500: hmm, can you add debugging in rtsp to see that it actually is nonzero, to make sure it was set and initialized at the right place and not overwritten? [12:28:43] <av500> sure [12:28:48] <thresh> Nano stuff is reserved by mr Medvedev nowadays [12:29:36] <kshishkov> Flameeyes: but it's interesting how many open crimes he can commit [12:29:47] <cartman> and still be president [12:29:53] <kshishkov> thresh: Ð§ÑÐ±Ð°Ð¹ÑÐ° Ð·Ð°Ð±ÑÐ»! [12:30:01] <kshishkov> cartman: of course [12:30:15] <cartman> http://nokiaplanx.com/ btw. [12:30:41] <av500> Flameeyes: lu_zero: but after all the crimes, only after the 17y sex thing your people go to the streets? [12:30:52] <av500> the rest was ok, or what? [12:31:04] <Flameeyes> av500: actually it's not the first time people reach the street [12:31:09] <kshishkov> cartman: http://www.msqt.org [12:31:22] <Flameeyes> the problem is... we have no opposition, so ... [12:31:48] <cartman> kshishkov: yeah saw that one, cute [12:32:01] <Flameeyes> cartman: no, qute! :P [12:32:09] <cartman> hehhe :P [12:32:26] <thresh> cartman: lol [12:32:31] <thresh> they're fast [12:32:40] <cartman> heheh [12:32:43] <thresh> I was thinking 'I wonder when there would be nokiapland site' [12:32:51] <cartman> :D [12:33:32] <Flameeyes> nokiaplane was the best though :P [12:34:12] <jannau> nokia plan f fails on mouse over [12:34:15] <cartman> heheh [12:34:33] <jannau> nsfw [12:34:46] <cartman> jannau: too late [12:34:48] <cartman> fsck [12:35:56] <av500> wbs: its 100000 all the time [12:36:02] <av500> lets put more [12:37:40] <lu_zero> av500: many times people got in the streets [12:37:57] <lu_zero> but before the media tried to ignore the protest [12:38:18] <Flameeyes> lu_zero: speaking about people and going places, did our coworkers reach the office? :P [12:38:22] <lu_zero> even if you get 1/10 of the people of a city in a square protesting [12:38:38] <lu_zero> Flameeyes: good question, today we are supposed to be at topix [12:39:11] * lu_zero is home due a strange chain of events started by his sister... [12:39:37] <lu_zero> j0sh: poing [12:40:05] <Flameeyes> lu_zero: why strange chains of events _always_ involve your sister? [12:41:04] <lu_zero> Flameeyes: because she's my sister? [12:41:15] <Flameeyes> yeah that's enough of a reason I guess [12:41:29] <Compn> was she protesting lu_zero ? [12:41:41] <Compn> i heard on the radio people were protesting in italy [12:41:46] <lu_zero> Compn: she's studying in the countryside [12:41:51] <DonDiego> Flameeyes: does xine use pkgconfig? [12:41:55] <Flameeyes> DonDiego: it does [12:41:55] <Compn> are you finally going to get rid of berluscioni ? [12:41:58] <DonDiego> for ffmpeg i mean [12:42:11] <lu_zero> Compn: actively trying since 15years ago [12:42:17] <lu_zero> now apparently more people got aware [12:42:26] <Compn> yeah but is this the one that will sink him? its hard to tell from here [12:43:14] <lu_zero> Compn: the main issue with berlusconi is his grasp on the media [12:43:36] <kshishkov> i.e. he either owns or sues the media [12:43:40] <Flameeyes> and the media having a grasp on the average Mario Rossi [12:43:46] <wbs> av500: if you have that enabled, you should at least get warnings about missed packets and/or too old packets received [12:43:48] <Compn> yep, thats a problem when he owns all of the state-tv channels [12:44:11] <av500> wbs: hmm, nope [12:44:13] <wbs> av500: but if you do read in bursts, you might well get dropped packets.. for udp, the code should ideally be waiting in poll()/read() all the time [12:44:19] <kshishkov> Flameeyes: maybe you should just call hil il Duce and forget about it [12:44:23] <kshishkov> *him [12:44:33] <Flameeyes> kshishkov: I wish... [12:44:55] <lu_zero> we'll see anyway [12:45:13] <kshishkov> wanna get Ukrainian guy instead? [12:45:20] <wbs> av500: you could add debugging code in rtpdec.c, around lines 705-710, that prints what seq and diff are, there you should easily see what's going on [12:45:30] <cartman> I'll have a spare Turkish one for you lu_zero & Flameeyes [12:45:35] <Compn> kshishkov : what happened to the guy that was poisioned and his face went all blaoted ? [12:45:36] <cartman> Berlusconi replacement, 1:1 :P [12:45:39] <Compn> bloated* [12:45:55] <kshishkov> cartman: your country seems to have run out of Ataturks [12:46:01] <cartman> kshishkov: long ago [12:46:32] <kshishkov> Compn: he's not a president since 2008 IIRC [12:46:36] <Compn> cartman : going to be protests in turkey like tunisa/egypt? :P [12:46:53] <Compn> my friend was trying to guess the next country... [12:46:56] <cartman> Compn: nope, I think not. [12:46:59] <av500> Compn: there is a queue, they are late :) [12:47:08] <Compn> haha [12:47:15] <cartman> only students protest here [12:47:50] <Flameeyes> cartman: they solved that in italy [12:47:59] <Flameeyes> there is no reason for people to _be_ student, with the kind of universities we have [12:48:08] <cartman> Flameeyes: lol [12:48:18] <cartman> they beat the hell out of them here [12:48:26] <cartman> one uni. student lost her baby [12:49:16] <av500> what kind of uni is that? [12:49:29] <cartman> The Life Universityâ¢ [12:49:43] <kshishkov> Flameeyes: there's absolutely no reason to be student in .ua Especially since they'll get more money not working by speciality and nobody believes diplomas much either [12:50:05] * Flameeyes decided not to go to uni after two weeks, been working since then [12:50:13] <cartman> Flameeyes: better than me [12:50:20] <cartman> I stopped after 2 years :P [12:50:31] <kshishkov> I stopped after 8 years [12:50:40] <cartman> kshishkov: with a diploma my friend ;) [12:50:44] <Flameeyes> got lucky, my ex-professor from high school proposed me a job immediately [12:50:58] <cartman> finding a job is never hard [12:51:07] <cartman> finding smart people to work with, is hard :p [12:51:17] * kshishkov waits for av500 to say something about dÃ¶ner stalls [12:51:26] <Flameeyes> cartman: yeah it was with my teacher so it wasn't bad [12:51:28] <av500> cartman: you are on 0800-FIXMYSUSE soon, right? [12:51:41] <Flameeyes> translated Ian Sommerville's "Software Engineering" book [12:51:43] <cartman> av500: they say software engineer too, right :) [12:52:08] <cartman> av500: 0800-FIXMYSUSE is in India [12:52:32] <av500> so you are outsourced already? [12:52:55] <cartman> heheh [12:53:01] <cartman> stop dreaming ;) [12:53:33] <kshishkov> av500: wanna get code from India written by Turks? [13:23:00] * kshishkov finds http://en.wikipedia.org/wiki/Sweden_Solar_System funny [13:24:30] <spaam> :) [13:28:06] <Kovensky> kshishkov: I don't know why but http://en.wikipedia.org/wiki/Sweden_Solar_System is blocked in my college [13:28:10] <Kovensky> lol [13:28:53] <kshishkov> Kovensky: obviously stupid college [13:29:09] <Kovensky> found out [13:29:14] <Kovensky> they did block the "Sweden" word [13:29:21] <Kovensky> and not even a substring of it [13:29:30] <av500> sweden = porn [13:30:23] <Dark_Shikari> we have a new meme! [13:30:29] <Dark_Shikari> http://www.nokiaplanb.com/ started it... [13:30:34] <Dark_Shikari> then we got http://www.nokiaplanc.com/ [13:30:36] <Dark_Shikari> then we got http://www.nokiapland.com/ [13:30:37] <Dark_Shikari> then we got http://www.nokiaplane.com/ [13:30:45] <av500> you are late [13:30:46] <JEEB> lawl [13:30:50] <Dark_Shikari> They keep adding more! [13:30:53] <spaam> Dark_Shikari: look at planx! [13:30:56] <thresh> and you are late [13:30:56] <Dark_Shikari> "nokiaplane.com" is literal [13:31:06] <Dark_Shikari> Yup, planx is the best~ [13:31:10] <av500> Dark_Shikari: pls tell new stuffz [13:31:11] <spaam> http://nokiaplanx.com/ ;D [13:31:14] <spaam> :D [13:31:28] <spaam> http://nokiaplana.com/ [13:31:38] <Dark_Shikari> .... lol? [13:31:45] <kshishkov> nokiaplanms? [13:31:47] <Dark_Shikari> oh god I lol'd [13:31:51] <Dark_Shikari> that is brilliant. [13:31:57] <cartman> heheh [13:34:18] <spaam> http://www.nokiaplan9.com/ [13:35:12] <thresh> plana is nice indeed [13:35:22] <thresh> too bad nokiaplant is squatted [13:35:35] <av500> we need a nokia plan webring NOW! [13:35:44] <thresh> av500: http://nokiaplans.com/ [13:35:50] <cartman> LOL [13:35:52] <spaam> :DDDD [13:36:02] <av500> thats not a ring [13:36:15] <spaam> av500: FiX iT [13:36:20] <cartman> Plan G is boring [13:37:14] <av500> looooool: ...Attend Ubuntu meetings, talk to Shuttleworth.... [13:38:02] <Kovensky> plan g is an actual good plan instead of a joke =p [13:38:18] <Kovensky> plan h has the wrong page title :D [13:38:20] <av500> Kovensky: plan g is the actual plan that got nokia into that mess [13:38:38] <Kovensky> av500: then they executed it wrong? o_O [13:38:45] <Kovensky> though I don't actually know what the mess is :> [13:38:46] <av500> no [13:38:59] * Kovensky never cared about cellphones [13:39:01] <av500> they executed it and now they have to hire elop [13:39:02] <cartman> Nokia 3310 the unbreakable phone [13:42:19] <av500> http://nokiaplank.com/ [13:42:53] <mru> this plank is made for walking... [13:43:00] <cartman> hit elop with that [13:43:06] <spaam> http://nokiaplanz.com/ [13:44:08] <av500> mru: go get plan54 for us [13:44:28] <mru> got content? [13:44:49] <av500> not really [13:45:00] <mru> alias it to 26-26-54? [13:45:05] <av500> who cares, lets buy adwords [13:45:08] <cartman> mru: I used to only buy Sony VAIO laptops, they are pretty good [13:45:20] <mru> cartman: good but expensive [13:45:22] <av500> cartman: that is not called "ridiculing" [13:45:24] <mru> and quirky bios [13:45:24] <cartman> true [13:45:34] <cartman> you can patch the acpi table [13:45:50] <mru> good thing ivan dimkovic has the same model [13:45:55] <cartman> hahah [13:46:07] <spaam> mru: Here at work we only have Thinkpad and macbook :) [13:46:10] <kshishkov> and he patched the bios IIRC [13:46:14] <mru> exactly [13:46:39] * cartman patches his ooooold VAIO to enable VT [13:46:47] <spaam> who is this ivan dimkovic ? [13:46:57] <cartman> spaam: the man that brought you AAC encoding [13:47:38] <spaam> cartman: why dont we have it in FFmpeg? [13:48:04] <cartman> spaam: eh because he doesn't do open source :P [13:48:10] <mru> spaam: I've asked kshishkov to kidnap ivan and make him work on ffaacenc, but he refuses [13:48:18] <cartman> he was working for Nero last time I checked [13:48:22] <av500> he is [13:48:24] <mru> sort of [13:48:32] <av500> he tried to sell nero to me [13:48:33] <spaam> kshishkov: come on. .do it.. i can buy you some trocadero and julmust! [13:48:41] <cartman> av500: crap suite? [13:48:45] <cartman> 1GB cd burner [13:48:54] <av500> kshishkov: you dont need to kidnap him, just corner him [13:48:56] <mru> spaam: kidnapping your boss (-ish) probably isn't good for your career [13:49:05] <twnqx> av500: i just opened a dbox2 and looked at the chips... is that hte source of your nick? [13:49:05] <mru> av500: same thing with kshishkov [13:49:23] <av500> twnqx: er, nope [13:49:31] <twnqx> no avia500 asic? :P [13:49:42] <cartman> twnqx: there is Archos AV500 [13:49:50] <twnqx> ah... [13:50:12] <av500> twnqx: http://reviews.cnet.co.uk/i/c/rv/e/dvdplayers/archos/av500/200x150_1.jpg [13:50:28] <spaam> mru: maybe kshishkov can get the source and just share it to us? ;D [13:51:02] <kshishkov> it's C++ I think [13:51:25] <cartman> thats a start [13:51:34] <cartman> leak 1 line of code everyday [13:51:39] <cartman> ++i; here is one [13:51:43] <av500> and apply C-- to it [13:51:55] <mru> av500: that would be --C [13:52:03] <mru> got to balance the operators [13:52:11] <kshishkov> --(C++) [13:52:18] <av500> cartman: here: " encode_aac(ctx, foo);" [13:52:18] <mru> not an lvalue [13:52:34] <cartman> av500: foo, no way [13:52:34] <mru> spaam: the source is not pretty at all [13:52:35] <kshishkov> mru: see, it's not possible! [13:52:54] <spaam> mru: but we can make it [13:53:03] <mru> a++-++b is valid c [13:53:10] <av500> mru: but you did leave a beagleboard plugged to the corporate network when you left there, right? [13:53:40] <kshishkov> av500: it's got reused [13:53:57] <kshishkov> av500: but he left me there [13:54:34] <av500> kshishkov: no, the *other* one under the raised floor.... [13:55:03] <mru> kshishkov: remember that eth adaptor that went missing? [13:55:27] <kshishkov> av500: nope, we don't even have case with shotgun for extreme situations [13:55:33] <kshishkov> mru: not at all [13:55:33] <cartman> are they still using CVS though? *ducks* [13:55:42] <mru> elif was searching all over for it [13:55:50] <cartman> sounds Turkish [13:55:57] <mru> what? [13:56:07] <mru> cvs? [13:56:15] <kshishkov> can't people name their child for C preprocessor directive? [13:56:17] <cartman> the modern vcs [13:59:48] <cartman> kshishkov: Elif is a Turkish girl name [14:00:02] <mru> this one is french, or so she says [14:00:09] <cartman> lying [14:00:11] <cartman> :p [14:00:17] <mru> she looks more french than turkish [14:00:21] <cartman> actually [14:00:26] <cartman> its roots are Arabic [14:00:37] <cartman> Elif is the "A" of Arab alphabet [14:00:42] <kshishkov> cartman: is Endif also a Turkish name? [14:00:49] <cartman> kshishkov: sadly no [14:01:00] <mru> ifdef? [14:01:07] <cartman> only Elif :P [14:01:15] <av500> gosub? [14:01:27] <mru> elsie is a swedish name [14:01:32] <mru> off by one... [14:01:34] <cartman> so close [14:01:34] <cartman> :D [14:01:54] <av500> elsie always picks the *other* guy [14:03:11] <kshishkov> av500: be thankful for what you got [14:03:40] <cartman> Will you guys attend LinuxTag? [14:03:44] <mru> kshishkov: have you met his wife? I have... [14:03:51] <mru> cartman: I hope so [14:04:03] <cartman> nice then we can meet finally \o/ [14:04:05] <kshishkov> mru: she's somewhere on pictures in his Flikr [14:04:39] <cartman> I didn't met av500's wife but his kids are lovely [14:04:48] <kshishkov> cartman: the most important is for you to meet av500 [14:04:50] <mru> I've only met two of them [14:05:02] <mru> and both of av500 of course [14:05:09] <cartman> kshishkov: he might kill me unlike I bring kÃ¶fte [14:05:09] <av500> mru: early in the morning too :) [14:05:21] <av500> cartman: I kill you just like that [14:05:21] <mru> av500: indeed [14:05:27] <cartman> av500: wow [14:05:32] <cartman> don't sit on me [14:05:34] <cartman> please [14:05:34] <cartman> :P [14:05:48] <mru> cartman: sit? you mean breathe [14:05:52] * av500 sings "the P K K too my cartman away" [14:05:59] <cartman> LOL [14:06:11] <cartman> soon I'll be immune to the P-word [14:06:29] <av500> cartman: I will find words monitored by BND [14:06:39] <cartman> BND? [14:06:42] <kshishkov> av500: you look a bit young here - http://www.flickr.com/photos/av500/4999167638/ [14:06:45] <av500> they have a concern about the P people too [14:07:06] <cartman> av500: what BND :) [14:07:25] <av500> cartman: the germany CIA wannabee [14:07:40] <cartman> it was a good idea to buy VPN from USA then [14:08:05] <av500> from the CIA? [14:08:25] <cartman> they possibly don't care about the Pee [14:08:58] <av500> dont pee in their teepee [14:09:21] <cartman> do they wiretap IRC in *.de? [14:09:46] <av500> no need, I send them logs [14:09:51] <cartman> av500: good idea [14:10:09] <cartman> I'll sure mention you as my secret supporter [14:10:37] <av500> cartman: the BND gets most of its intelligence from wikileaks [14:10:45] <cartman> lol [14:12:11] <cartman> at least I'll be able to listen last.fm there [14:12:22] <cartman> only Spotify is missing and thats because of andoma somehow :p [14:16:35] <CIA-38> ffmpeg: Maksym Veremeyenko <verem(a)m1stereo.tv> master * rd06497f316 ffmpeg/libavformat/nsvdec.c: [14:16:35] <CIA-38> ffmpeg: fix nsvdec.c compilation if DEBUG defined [14:16:35] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [14:23:18] <mru> wtf @ Compn on ML [14:24:19] <spaam> where? :) [14:24:30] * cartman sighs [14:24:37] <mru> "2 weeks review time is standard operating procedure" [14:24:49] <mru> except for certain induhviduals, apparently [14:25:00] <cartman> back in the Lord Vader days [14:25:03] <av500> but only after a "request for review" has been filed [14:25:14] <mru> in triplicate [14:25:27] <av500> and the review review committee has approved it [14:26:34] <mru> j-b: ping [14:26:53] <kshishkov> mru: s/except//, the rest reviews in a few days [14:27:34] <mru> kshishkov: I meant that one person seems to be exempt from review entirely [14:27:59] <elenril> people are still reading those? [14:28:19] <j-b> mru: pong [14:28:20] <kshishkov> mru: I thought you meant time it takes for dev to review incoming patch, but you're right [14:28:33] <mru> j-b: what's your interest in the vbv patch? [14:29:41] <j-b> mru: cmassiot is an oldie of VLC, and he has a new ts muxer for VLC, that can 'allegedly', create CBR ts, which is useful in many broadcast situations. Hence, interesting for my $day_job [14:29:53] <mru> I see [14:30:01] <mru> so you approve the patch? [14:30:08] <j-b> I don't care [14:30:15] <j-b> I just want a solution [14:30:21] <mru> you do care, but not at that level of detail [14:30:22] <j-b> the best [14:30:49] <j-b> I'd like that, in the next 3 months, there is a solution. [14:31:06] <mru> I can push it in 3 seconds... [14:31:07] <kshishkov> j-b: next you'll ask for interlaced VC-1 [14:32:00] <j-b> mru: well, I certainly don't want something bad in FFmpeg. [14:32:17] <mru> I think the patch is fine [14:32:24] <j-b> see https://github.com/cmassiot/vlc-broadcast/commits/master [14:32:49] <mru> and I assume it's good enough for christophe [14:33:11] <j-b> mru: but to be honest, I am also interested in getting cmassiot back in the vlc dev community, as a political side [14:33:25] <j-b> yes, I am evil©® [14:33:32] <mru> !french [14:33:54] <mru> <Hector4212> French are evil! Â© [14:33:59] <j-b> but I'll ask Chris to add a libavcodec/options.c something [14:34:04] <mru> nevermind [14:34:07] <mru> that's not needed [14:34:17] <mru> it's a read-only field for the application [14:34:27] <mru> adding to options.c would expose it on the command line [14:34:36] <mru> and that would be weird to say the least [14:35:43] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r9806fbd535 ffmpeg/libavcodec/binkaudio.c: [14:35:43] <CIA-38> ffmpeg: binkaudio: fix channel count check [14:35:43] <CIA-38> ffmpeg: Perform validity check on AVFormatContext.channels instead of [14:35:43] <CIA-38> ffmpeg: uninitialised field. [14:35:43] <CIA-38> ffmpeg: This fixes issue 2001. [14:35:44] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:35:50] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r71f88b1f38 ffmpeg/libavcodec/binkaudio.c: [14:35:50] <CIA-38> ffmpeg: binkaudio: remove unused copy of AVCodecContext* [14:35:50] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:35:55] <CIA-38> ffmpeg: Christophe Massiot <massiot(a)via.ecp.fr> master * r55bad0c602 ffmpeg/libavcodec/ (avcodec.h mpegvideo_enc.c): [14:35:55] <CIA-38> ffmpeg: Pass VBV delay to the calling application via ctx [14:35:55] <CIA-38> ffmpeg: VBV delay is useful for T-STD compliance in some TS muxers. It is [14:35:55] <CIA-38> ffmpeg: certainly possible to retrieve it by parsing the output of FFmpeg, but [14:35:55] <CIA-38> ffmpeg: getting it from the context makes it simpler and less error-prone. [14:35:56] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:35:57] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r8ed4cc65a1 ffmpeg/doc/APIchanges: [14:35:57] <CIA-38> ffmpeg: APIchanges: update for 55bad0c: vbv_delay [14:35:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:36:15] <kshishkov> j-b: there you are [14:36:40] <elenril> so what's up with lavcore [14:36:52] <kshishkov> merge it back! [14:37:13] <siretart> ++ [14:37:26] <elenril> i mean...what are you waiting for? [14:38:41] * Compn charges his fflames-laser [14:39:11] <j-b> I thought it was ffdrama [14:42:53] <lu_zero> j-b: both flavours available [14:43:03] <lu_zero> one is bitter the other is spicy [14:45:57] <av500> wbs: lu_zero: i find it strange that the behaviour of rtsp depends on the timing of the client [14:46:24] <wbs> av500: that's the problem with UDP and the top-down architecture of lavf [14:46:29] <av500> and even setting max_delay=1 for ffplay makes a huge difference [14:46:46] <mru> architecture? [14:46:49] <wbs> av500: the issue with max_delay on/off is that it enables a different codepath [14:46:52] <mru> you mean house of cards [14:46:55] <av500> ah [14:47:10] <av500> so why does it not work from my client :( [14:47:30] <wbs> av500: I'd love to have it set to a non-zero value by default, but since it's a general AVFormatContext field used for other things, too.. [14:48:27] <Dark_Shikari> http://nokiaplanp.com/ [14:48:38] <Dark_Shikari> http://nokiaplant.com/ [14:48:44] <Dark_Shikari> http://nokiaplanz.com/ [14:48:47] <lu_zero> wbs: uhmm [14:48:49] <Dark_Shikari> http://nokiaplan5.com/ [14:48:51] <Dark_Shikari> I love these [14:49:23] <bilboed-tp> you could have just linked nokiaplans.com [14:49:27] <bilboed-tp> which links them all :) [14:49:33] <j-b> and the 'x' one, that autogenerates [14:52:14] * Compn vomits at all of the fixed width websites [15:05:01] <lu_zero> Compn: are you in bad faith or you missed the other thread completely? [15:05:25] * elenril guesses Compn just feels like trolling [15:07:50] <mru> that's not helpful [15:15:01] <av500> wbs: \\\ooo/// [15:15:22] <av500> wbs: turns out, getting max_delay into AVFormatContext is not so easy [15:15:37] <wbs> av500: told you so ;P [15:17:30] <av500> wbs: preallocing the context is not enough, one also has to provide params that says so [15:17:35] <av500> gee [15:32:56] <CIA-38> ffmpeg: Reinhard Tartler <siretart(a)tauware.de> master * r737eb5976f ffmpeg/ (120 files in 9 dirs): (log message trimmed) [15:32:56] <CIA-38> ffmpeg: Merge libavcore into libavutil [15:32:56] <CIA-38> ffmpeg: It is pretty hopeless that other considerable projects will adopt [15:32:56] <CIA-38> ffmpeg: libavutil alone in other projects. Projects that need small footprint [15:32:56] <CIA-38> ffmpeg: are better off with more specialized libraries such as gnulib or rather [15:32:57] <CIA-38> ffmpeg: just copy the necessary parts that they need. With this in mind, nobody [15:32:58] <CIA-38> ffmpeg: is helped by having libavutil and libavcore split. In order to ease [15:33:37] <BBB> \o/ [15:33:54] <kshishkov> I, for one, welcome our less scattered FFmpeg [15:33:57] <jannau> siretart: thanks [15:34:56] <mru> \\\\\\\oooooo/////// [15:34:57] <av500> deleadered and delibraried [15:35:02] <mru> // [15:37:08] <JEEB> heh, I kind of wondered what libavcore was going to do in the end >_> [15:37:22] <siretart> in case someone asks, this is the 'packaging maintenance' overhead for libavcore: http://bazaar.launchpad.net/~siretart/ffmpeg/packaging-trunk/revision/15 [15:37:29] <siretart> (just reverse the changes) [15:40:19] <cartman> http://www.nunomonteiro.org/how-the-british-view-other-countries [15:43:18] <mru> "Koreans are not Chinese." <-- and _certainly_ not japanese [15:43:38] <kshishkov> mru: and Koreans invented everything long before Chinese! [15:43:52] <JEEB> oh boy, mru -- don't step into that minefield of KOR-JPN >_> [15:44:02] <cartman> mru: ah you are a brit! [15:44:03] <JEEB> I don't even want to understand that beehive [15:44:19] <mru> JEEB: it's not that complicated really [15:44:32] <mru> china and japan have fought many wars -- in korea [15:44:42] <mru> thus the koreans rather dislike both of them [15:44:53] <mru> and of course they have a national pride [15:45:05] <kshishkov> mru: Korea was Japanese colony till 1946 [15:45:13] <kshishkov> that's enough [15:45:29] <mru> that too [16:00:32] <Compn> lu_zero : which thread? the original review thread ? [16:02:03] <lu_zero> exactly. [16:03:45] <DonDiego> \o/ [16:03:55] <DonDiego> libavutil may now reign supreme :-) [16:04:22] <KotH> ? [16:04:30] <Compn> lu_zero : my point was that 'over my dead body' was used instead of 'here is whats wrong with the patch, copied from the earlier thread' [16:04:56] <Compn> or even 'look at earlier thread xxxx' [16:05:06] <mru> Compn: I've repeated the reasons why that is wrong on average once a month for the last 5 years [16:05:25] <lu_zero> Compn: given is the same guy that discussed the issue before [16:06:58] <Compn> why not say that on the list then ? [16:06:58] <Compn> heh [16:07:34] <Compn> sorry, i didnt see previous threads [16:07:39] <Compn> my bad [16:08:53] <lu_zero> I'd like to have the hypocrisy claim retracted please. [16:09:39] <mru> Compn: 'over my dead body' was a stupid thing to say [16:10:09] <KotH> mru: next time, use "over your dead body" instead ;-) [16:10:49] <lu_zero> KotH: don't joke =P [16:10:53] <spaam> ;P [16:11:03] <spaam> funny KotH is not funny.. [16:11:04] <spaam> ;P [16:11:20] <mru> joking about the death of others is rarely a good idea [16:11:29] <mru> unless you know them very well [16:11:37] <kshishkov> depends on society [16:11:46] <mru> safer never to do it [16:11:53] <kshishkov> indeed [16:11:57] <mru> especially in an open forum [16:12:36] <Compn> it may be illegal in some countries :p [16:13:00] <kshishkov> Compn: in USA but not anywhere else [16:19:03] <av500> kshishkov: nope, in usa you are not allow to say: "over your naked body" [16:19:09] <av500> dead is fine [16:19:51] <kshishkov> av500: that can be considered as a death threat and will induce a lawsuit [16:23:21] <mru> expressing a wish to see someone naked can be almost as offensive as wishing to see them dead [16:40:10] <KotH> well, if she's cute...? [16:47:10] <mru> KotH: of course there are a number of people I'd _like_ to see naked... [16:48:42] <KotH> mru: ask those girls whether they'd join a trip to sweden, then go to a sauna with them :) [16:48:55] <mru> :) [16:49:01] <mru> and yes, they are all girls [16:49:10] <BBB> KotH: if you ask sandra bullock, she might say "no", which is kind of devastating [16:49:48] <KotH> BBB: i dont mind... bullock is not really my type :) [16:49:59] <KotH> mru: i'd be surprised if it would be otherwise ;-) [16:50:55] <mru> KotH: I guess you'd know by now if it were [16:51:26] <KotH> mru: yeah.. i know too many things about too many people... [17:02:20] <av500> BBB: bullock is of german origin, depending where from she might sauna [17:03:42] <av500> mru: nothing beats the look on the faces of the brits that shared a sauna with my coworker and his wife when they were in the UK [17:03:58] <av500> they considered it "mixed" [17:04:22] <av500> it was a new concept to the natives [17:14:48] <siretart> av500: IIRC bullock has franconian heritage, but I may be wrong [17:15:04] <mru> who cares about her anyway? [17:19:19] <av500> siretart: nope [17:19:52] <av500> "...She sang in the operas children's choir at the Staatstheater NÃŒrnberg.[9]..." [17:20:40] <siretart> which is the most important city in franconia :-) [17:21:01] <av500> pah [17:21:11] * av500 must need more coffee [17:21:15] <av500> lots of [17:21:18] <siretart> http://en.wikipedia.org/wiki/Franconia [17:21:20] <siretart> :-) [17:21:31] <av500> Franggen [17:24:29] <pJok> http://www.blogcdn.com/www.engadget.com/media/2011/02/amd-apu-2011-02-15-60… [17:24:36] <pJok> AMD has humor [17:29:47] * lu_zero never tried a swedish sauna [17:30:05] <lu_zero> how is that different from a japanese one? [17:38:53] <CIA-38> ffmpeg: Max Shakhmetov <shakhmetov.max(a)gmail.com> master * r9ac2085dbf ffmpeg/libavformat/os_support.c: [17:38:53] <CIA-38> ffmpeg: os_support: fix poll() implementation [17:38:53] <CIA-38> ffmpeg: Our poll implementation does not iterate over the pollfd array properly [17:38:53] <CIA-38> ffmpeg: while setting the revents. [17:38:53] <CIA-38> ffmpeg: Signed-off-by: Luca Barbato <lu_zero(a)gentoo.org> [20:47:05] <mru> I filed one gcc bug and one armcc bug this week, any bets on which one gets fixed first? [20:48:32] <_av500__> clang? [20:48:59] <mru> none by me, don't know if someone else reported the vp8 problem [20:51:57] <mru> speaking of bugs, http://blog.regehr.org/archives/383 [20:52:03] <mru> that guy actually seems sensible [21:02:52] <Flameeyes> mru: likely armcc [21:05:10] <mru> the last few bugs similar to this one took them ~50 days [21:05:40] <Flameeyes> mru: I think I still have gcc bugs open after years [21:05:53] <Flameeyes> and I _definitely_ still have sunstudio bugs open after years [21:08:02] <Tjoppen_> speaking of bugs, how old are the oldest open ffbugs on roundup? [21:08:17] <mru> nobody knows [21:08:33] <mru> the system time has wrapped around since then [21:08:51] <jannau> lol: from lkml http://keithcu.com/wordpress/?p=1691 [21:10:42] <spaam> hÃ¶hÃ¶hÃ¶ [21:10:54] <jannau> totally incomprehensible, if I had to guess he wants the kernel reimplemted in python so that all userspace code can be converted to python [21:11:08] <mru> who is he? [21:11:25] <jannau> some insane person [21:12:13] <elenril> tl;dr [21:12:49] <jannau> ignoring that scipy uses Fortran and C libs for most of it math functions [21:14:33] <jannau> Employment: "1993 â 2005 Software Design Engineer, Microsoft Corporation. Shipped code in Tools, Consumer, Office, Windows, Window CE, Mobile, Research, and MSN." [21:15:03] <mru> so _that_ is the explanation for windows ME [21:19:39] <{V}> elenril, "too long; did read" ? :) [21:21:56] <Tjoppen_> oh, he means garbage collection [21:22:21] <mru> probably, it self-collected before I could finish it [21:30:17] <BBB> wbs: can you look at https://roundup.ffmpeg.org/issue2612 ? looks like a user problem to me, but I'm not sure [21:32:21] <Flameeyes> mru: well it is in target for the garbage [21:42:45] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r50d7140441 ffmpeg/ (3 files in 3 dirs): [21:42:46] <CIA-15> ffmpeg: ac3enc: change default floor code to 7. [21:42:46] <CIA-15> ffmpeg: This is to match the value in every (E-)AC-3 file from commercial sources. [21:42:46] <CIA-15> ffmpeg: It has a negligible effect on audio quality. [21:42:46] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [22:01:17] <mru> does anyone else think an option to make ffmpeg not print _any_ general chatter would be nice? [22:02:48] <Jumpyshoes> BBB: can i have a patch that sets HAVE_AVX if yasm can assemble it? [22:03:03] <mru> it's a two-liner [22:03:21] <mru> Jumpyshoes: give an example of an avx instruction [22:03:57] <Jumpyshoes> vpaddw xmm0, xmm0, xmm0 [22:05:46] <mru> http://pastie.org/1568244 [22:05:48] <mru> untested [22:06:12] <Jumpyshoes> okay, thanks [22:07:58] <BBB> Jumpyshoes: mru is our local configure overlord [22:08:34] <Jumpyshoes> BBB: i see, i'll post a patch shortly with an avx function for testing [22:09:03] <BBB> Jumpyshoes: I'm writing vc1 stuff, see lots of potential for avx functions here :) [22:09:34] <Jumpyshoes> anything with a mova :) [22:09:51] <mru> BBB: need 32-bit much? [22:10:48] <Jumpyshoes> oh, i also need to set the AV_CPU_FLAG [22:11:03] <kurosu> were vc1 f/iDCT ever committed ? [22:11:41] <BBB> mru: haven't tested yet, you told me I didn't need it [22:11:56] <mru> I wrote a neon one w/o and it seems to work [22:12:00] <BBB> kurosu: no, the functions sucked, I'm rewriting that now [22:12:06] <kurosu> :p [22:12:13] <mru> the specs suggested 16 bits would be enough [22:12:21] <BBB> mru: also I'm gonna break your optimizations [22:12:26] <mru> huh? [22:12:32] <mru> which ones? [22:12:34] <BBB> mru: I'm transposing the idct coefficients [22:12:39] <mru> vp8? [22:12:40] <BBB> mru: so the asm will need modifications [22:12:42] <BBB> mru: no, vc1 [22:12:53] <mru> there is no neon vc1 in ffmpeg [22:12:59] <mru> this was for a client [22:13:02] <BBB> right [22:13:11] <BBB> I'm just saying you need to fix them if you want to re-sell it [22:13:12] <BBB> :-p [22:14:17] <kurosu> the subpel interpolation functions for vc1 are indeed written for old cpus; as usual ssse3 will also improve that [22:14:54] <mru> that interpolation is dreadful [22:15:19] <kurosu> the way it is implemented ? [22:16:33] <mru> the spec [22:16:36] <mru> it's annoying to implement [22:16:46] <mru> not quite as annoying as mpeg4-2 qpel of course [22:19:23] <kurosu> i remember part of the non-spec compliance in ffmpeg was that the order (vertical followed by horizontal and vice versa) mattered, so, yes [22:19:46] <kurosu> (talking only about my own limited view of the spec) [22:20:10] <kurosu> s/mattered/was wrong [22:20:11] <mru> vc1 is less wtf than vp8 though [22:20:53] <kurosu> i've seen strange stuff indeed in various commits in ffmpeg [22:21:13] <kurosu> this 129 or 127 padding iirc... [22:21:30] <mru> (x + 63) >> 7 and such [22:21:35] <mru> any sane person does +64 [22:21:48] <mru> cpus have an instruction that [22:21:53] <mru> +for [22:22:06] <mru> and they're not consistent [22:22:29] <mru> even in the same function, they use different rounding modes [22:22:33] <kurosu> people developping codecs in such fields hardly have any idea of what a cpu can do efficiently or not [22:22:41] <mru> that's the problem [22:22:51] <mru> h264 is actually nice to optimise [22:23:14] <kurosu> maybe more with neon, which i don't know [22:23:21] <mru> it never overflows into 17 bits and such silly things [22:23:36] <mru> almost everything fits in 16 bits [22:23:49] <kurosu> but for instance the strength computation for the loop filter is rather troublesome [22:23:51] <mru> I don't remember if it ever needs more [22:25:15] <kurosu> BBB: so what are you doing with vc1 dsp functions? rewriting them to yasm? adding sseX versions with X>1 ? [22:25:31] <dalias> hi [22:25:36] <BBB> kurosu: writing idct from scratch, really [22:25:47] <BBB> kurosu: I'm profiling and going top-down [22:25:51] <mru> hi dalias, long time no see [22:25:55] <dalias> yes [22:26:07] <dalias> been working on my own project, finally released :) [22:26:15] <mru> what project is that? [22:26:31] <dalias> libc, now called musl [22:26:48] <mru> got a web page? [22:26:54] <mru> how complete is it? [22:26:57] <DonDiego> you seem to be happy about musl's release :) [22:26:58] <kurosu> BBB: there may be potential also with subpel as it's mmx, but indeed the idct is much needed [22:27:26] <dalias> mru, yeah, http://www.etalabs.net/musl/ [22:27:28] * mru did vc1 subpel in neon with no intermediate storage [22:27:52] <dalias> the faq and comparison pages there answer how complete it is fairly well [22:28:02] <BBB> kurosu: almost done with the 8x8 [22:28:20] <mru> why the name musl? [22:28:24] <j-b> Can someone explain "The logical unit" from AVOption2 ? can it be anything? [22:29:00] <mru> j-b: heh, that's a bit weird [22:29:07] <dalias> mru, also in the faq :) [22:29:10] <mru> it's for supporting symbolic names as arguments to some flags [22:29:51] * j-b scratches his head [22:30:15] <j-b> so far I have, "{"vbv-delay", NULL, 0, FF_OPT_TYPE_INT64, 0, 0, INT64_MAX, V|E, "27MHz_timestamp"}, [22:30:28] <mru> that's wrong [22:30:45] <mru> the last field should be null [22:31:07] <j-b> then NULL it is [22:31:10] <mru> and before we add this, we should add a flag to mark things as "read-only" [22:31:20] <mru> so they don't become command line params [22:31:28] <mru> setting this from the command line makes no sense [22:31:43] <j-b> it has exactly no sense, indeed [22:31:57] <j-b> but I said: "I will make a patch tonight", so I make a patch tonight. [22:32:03] <mru> setting such fields with av_set_foo() should also be impossible [22:32:11] <j-b> clearly [22:32:21] <mru> I'd just add an AV_OPT_FLAG_READONLY [22:33:14] <lu_zero> dalias: uhm [22:33:20] <lu_zero> which allocator do you use? [22:33:41] <mru> lu_zero: there's a faq for that [22:35:06] <j-b> michaelni: here should be the patch http://pastebin.com/RihwBQs3 [22:35:39] <mru> j-b: a brief comment in the second field might be nice [22:35:53] <bcoudurier> why do you need an avoption for this ? [22:36:07] <mru> you don't [22:36:15] <mru> or else I'd have insisted on it [22:36:32] <dalias> lu_zero, my own [22:36:51] <bcoudurier> so why does j-b want to add it ? [22:36:51] <j-b> bcoudurier: I believe we don't either. But learning I am [22:37:04] <j-b> bcoudurier: I don't want to. I said I would do a patch for it [22:37:08] <mru> bcoudurier: michael wants it [22:37:11] <j-b> so, a patch I do. [22:37:28] <bcoudurier> this is useless for fields not settable externally [22:37:38] <bcoudurier> we'd better not add them [22:37:48] <j-b> adding AV_OPT_FLAG_READONLY is easy, what to do with it, is different ;) [22:37:52] <bcoudurier> and remove the wrongly added ones [22:37:54] <bcoudurier> IMHO [22:38:15] <mru> bcoudurier: I agree [22:39:30] <lu_zero> dalias: dl variant... I see, did you have a look at nedmalloc? [22:40:50] <lu_zero> or tlsf [22:41:00] <mru> lu_zero: nih :) [22:41:21] <dalias> lu_zero, the claims on the page were ridiculous enough that i didn't bother :) [22:41:22] <mru> dalias: what pthread interfaces are missing? [22:41:28] <lu_zero> mru: trying new allocators is always useful [22:41:43] <mru> lu_zero: I've done my share of malloc testing [22:41:55] <lu_zero> dalias: well beating windows is easy [22:41:55] <mru> even convinced management to switch [22:42:08] <lu_zero> tlsf seems interesting [22:42:15] <lu_zero> mru: switch from what to what? [22:42:23] <mru> homebrew to dl [22:42:38] <lu_zero> dalias: I'm getting you some audience now [22:43:04] <dalias> mru, most attributes for condition vars and rwlocks, robust and process-shared mutexes, priority scheduling [22:43:54] <lu_zero> dalias: http://rtportal.upv.es/rtmalloc/ if you are still up to play with the concept [22:44:02] <mru> dalias: nothing terribly important then [22:44:19] <mru> dalias: did you once say threads were unnecessary? [22:44:31] <dalias> mru, imo most of the missing stuff is only needed for people who want premature microoptimization :) [22:44:33] <mru> or is my memory playing tricks on me? [22:44:36] <dalias> yes i did [22:44:48] <mru> what made you change your mind? [22:44:59] <dalias> 2 things i guess [22:45:15] <dalias> one, i decided since thye're a mandatory part of modern posix i should implement them whether i like them or not [22:45:17] <mru> I'll be the first to agree threading is abused far too much [22:45:27] <dalias> and two, i discovered that i could make them insanely efficient [22:46:02] <dalias> my thread creating and joining, without any cacheing hacks like glibc does, is roughly the same speed, and as cheap as a couple io syscalls [22:46:25] <mru> nice [22:46:40] <dalias> and using threads doesn't even pull in malloc if you don't otherwise use it [22:46:44] <mru> of course, if thread creation is a performance issue, the app is horribly misdesigned [22:47:09] <dalias> i would say the same about if malloc is a performance issue :) [22:47:14] <mru> +1 [22:47:19] <dalias> but plenty of ppl think it is..... :/ [22:47:25] <mru> and memcpy [22:48:03] <dalias> actually my fav thing about my malloc is that it can return memory to the os from anywhere in the heap, not just the top [22:48:14] <mru> depends on the os I guess [22:48:38] <dalias> at present it does not reduce the commit charge, just the dirty count [22:48:58] <dalias> but i could make it reduce the commit charge too with a little more complexity and time cost [22:49:05] <lu_zero> dalias: is your allocator usable as is? [22:49:09] <dalias> yeah [22:49:18] * lu_zero as a certain exa implementation that could try new tricks... [22:49:22] <mru> btw, do you know what all that code in glibc actually does? [22:49:22] <lu_zero> has [22:49:29] <dalias> but it would take some _minor_ work to rip it out and use it independently [22:49:36] <mru> the posix spec isn't _that_ big... [22:49:39] <dalias> mru, :) [22:49:43] <mru> and most of it is syscall wrappers [22:50:06] <dalias> the biggest bloat components in glibc are stdio and locale [22:50:17] <dalias> stdio is implemented as C++ iostream, written in C [22:50:33] <dalias> they actually make it have compatible struct layout in C with the C++ class [22:50:59] <lu_zero> why that? [22:51:00] <dalias> and thus it's way more complex than it needs to be [22:51:14] <dalias> because they like C++ i guess.... ;-) [22:51:34] <lu_zero> the only reason I could think is to make C++ slightly faster [22:51:44] <dalias> it probably does do that [22:51:48] <mru> c++ needs to die [22:51:53] <mru> the sooner, the better [22:52:34] <lu_zero> mru: well we might have lost Qt as side effect of nokia->ms [22:52:56] <mru> heh [22:53:13] <lu_zero> what else is making C++ more useful than annoying? [22:53:24] <j-b> lu_zero: the internal infos I have are not saying that [22:53:37] <lu_zero> j-b: which plan now? [22:53:42] <lu_zero> B or Z ? [22:53:46] <j-b> lu_zero: except UI and strings management? nothing. C++ is annoying [22:54:02] <j-b> C++ has things that let you bazooka your foot [22:54:15] <j-b> and C++ lets you write unmaintainable code [22:54:23] <dalias> the lack of good gui tools in C is what makes C++ attractive to ppl, imo [22:54:28] <mru> c++ makes writing bad code _really_ easy [22:54:31] <lu_zero> any language beside python does [22:54:31] <dalias> :) [22:54:38] <lu_zero> dalias: check evas/elementary [22:54:45] <mru> bad code can be written in any language [22:54:56] <j-b> dalias: and string management [22:55:03] <lu_zero> the comment before was referred to j-b's one [22:55:13] <dalias> string management in C is a lot easier than ppl give credit for [22:55:21] <mru> +1 [22:55:27] <dalias> it's just that ppl wantto apply broken, inefficient string processing idioms from script languages to C [22:55:38] <dalias> concatenation is *NOT* a sane string processing idiom [22:55:47] <lu_zero> dalias: was about to ask that [22:55:53] <j-b> lu_zero: yes, and at work I force python and a subset of C++ using Qt [22:56:03] <mru> concatenation is very rarely what you really want to do [22:56:06] <lu_zero> j-b: ^^; [22:56:07] <dalias> it leads to O(n^2) time, even *without* the null-terminated/C-string issue [22:56:12] <lu_zero> pyside or the other monster? [22:56:13] <dalias> due to reallocation [22:56:31] <lu_zero> dalias: what would you do? [22:56:36] <dalias> snprintf [22:56:42] <lu_zero> ... [22:56:43] <dalias> and build the string all in one step [22:56:44] <j-b> a UI has a lot of string manipulations, asprintf and concatnateion [22:56:58] <dalias> asprintf is fine too [22:57:18] <lu_zero> asprintf doesn't look that light [22:57:19] <michaelni> bcoudurier, j-b, we want the AVOption because if fork1 appends field guessed_pts to AVCodecContext and fork2 doesnt but then appends fieldX then both are ABI incompatible unless you access through av_set/get* that is AVOptions [22:57:51] <j-b> lu_zero: it isn't light [22:57:57] <dalias> it sure can be [22:58:07] <dalias> asprintf+all deps is <10k in musl [22:58:15] <lu_zero> michaelni: and obviously you want guessed_pts even if what code should live better in avutils... [22:58:23] <lu_zero> s/what/that/ [22:58:43] <j-b> dalias: for simple programming and when people don't need perfs for strings, concatenation is nice. str* are a mess for those cases [22:58:46] <michaelni> lu_zero, maybe, maybe not, my point is we wont always agree i fear even if we agree now [22:58:46] <mru> if you don't need the formatting facilities, a few strlen, strcpy, and some pointer maths will do the trick [22:59:48] <lu_zero> mru: wrapping them in nicer abstraction is usually what happens then [22:59:53] <michaelni> and it costs very little to add a line per field to the AVOption table... [23:00:00] <dalias> mru, yeah and instead of a 1-time cost of snprintf&deps, you have 5 or 6 function calls to strlen, memcpy, etc. every time you build a string :) [23:00:18] <dalias> sure you could make your own wrapper and abstraction [23:00:19] <michaelni> j-b, about the patch, the flags would cause it to be outputted in the help output i think [23:00:33] <j-b> michaelni: ok, so what should I do? [23:02:23] <michaelni> #define new flag in libavutil/opt.h, use that and omit such flaged fields from show_help_options() output [23:02:40] <michaelni> should be 4 lines of code or so [23:02:50] <mru> and have av_set_*() reject it too [23:03:12] <michaelni> mru, i dont understand ? [23:03:15] <j-b> 4 lines of code in FFmpeg is way more difficult :) [23:03:31] <mru> michaelni: it makes no sense to set that field through av_set_string and friends [23:03:37] <michaelni> yes [23:03:49] <michaelni> but other (future) fields for them it can make sense [23:03:54] * lu_zero notices that the whole thing growing [23:04:20] <mru> I was suggesting a "readonly" flag [23:04:28] <mru> meaning the library user should only read the field [23:04:35] <mru> that fits the semantics of this one [23:04:37] <michaelni> mru thats a good idea as well [23:04:57] <michaelni> what i was thinking of was more a "internal_for_abi" flag [23:05:18] <mru> the vbv delay field should be read by the user, just not written [23:05:31] <mru> internal things don't belong in public structs at all [23:06:04] <michaelni> ok, bad name then ... [23:07:16] <michaelni> maybe "non_user_field/option" but it doesnt sound terrible great either [23:07:42] <mru> for now readonly fits the need and makes general sense [23:08:22] <mru> that would apply to all existing "set by lavc" fields too [23:09:35] <michaelni> yes, but many are "set by user" on the other side (encoder vs decoder) [23:10:02] <michaelni> its maybe just encoder status output stuff ... [23:11:29] <DonDiego> gnite [23:14:22] <dalias> lu_zero, i almost wonder if nedmalloc is just SEO spam [23:14:42] <dalias> it doesn't seem to do anything revolutionary [23:16:39] <Dark_Shikari> http://nokiaplan0.com/ [23:19:17] <lu_zero> dalias: I hadn't tried it yet [23:19:32] <saintdev> lol they added "Profit!" to the Plans page [23:19:33] <lu_zero> tlsf seems sound [23:22:09] <dalias> :) [23:23:13] <kierank> ruggles: why do you use a bs_id of 8 when everyone else uses 6? [23:23:22] <kierank> (sorry if you ended up answering this after i left) [23:23:47] <ruggles> hi kierank. i saw the question but didn't answer because you were gone. [23:24:34] <ruggles> 6 is for alternative bitstream syntax, which we don't support yet. [23:24:39] <ruggles> it would still work, but not needed. [23:25:09] <kierank> it's only that little metadata section right, replacing timecode with other options? [23:25:48] <ruggles> yes. and using bsid 6 is part of my AVOptions patch, which i still have to revise before resubmitting. [23:25:53] <kierank> ah [23:26:07] <ruggles> since that patch will allow writing that little extra metadata [23:29:31] <dalias> lu_zero, you know anyone who might could do an arm port of musl? [23:29:53] <mru> are you paying? :) [23:30:13] <dalias> its basically just implementing 4 or 5 asm functions and getting all the bits and syscall header stuff right [23:30:19] <dalias> haha [23:30:39] <mru> how much work do you estimate it is? [23:31:38] <dalias> a few hours unless you get stuck debugging something that doesn't want to work :) [23:31:58] <mru> hmm, I might look into it if nobody beats me to it [23:34:53] <j-b> something like that http://pastebin.com/8jjPKtDa then? [23:40:56] <mru> j-b: av_set_string3() needs the same check [23:41:40] <lu_zero> dalias: is there something that could be used as template? [23:41:41] <j-b> mru: of course, all of them [23:41:50] <j-b> mru: but is it something like that that is needed? [23:41:56] <dalias> the i386 or x86_64 versions of the asm :) [23:41:59] <mru> j-b: yes [23:42:14] <mru> j-b: I think set_number2 and set_string3 cover all paths [23:42:21] <lu_zero> where are them? [23:42:27] <mru> dalias: no gitweb? [23:42:35] <dalias> find -name i386 [23:42:50] <dalias> mru, not yet, will do soon. [23:43:00] <dalias> i just started learning git a few days ago [23:43:09] <michaelni> j-b, (ignoring set_string*), this implements what mans suggested though this is solving a slightly different problem [23:43:23] <j-b> michaelni: oh? [23:43:32] <michaelni> i mean we have a fork/ABI issue and not a someone writes in read only fields issue [23:43:45] <mru> this solves both problems [23:44:01] <michaelni> it only solves the ABI issue for read only fields [23:44:12] <mru> the field we're talking about _is_ readonly [23:44:21] <mru> and there's currently no way of saying so [23:44:22] <michaelni> yes, by coincidence [23:44:38] <lu_zero> michaelni: better a good solution than no solution I think ^^ [23:44:43] <j-b> michaelni: I have 2 patches, one on libavcodec/options.c adding the vbv_ thingie. One on libavutil/opt.* about readonly thingiie [23:44:56] <mru> this adds a way of describing the semantics of the field, _and_ provides an abi-safe way to access the field [23:44:59] <lu_zero> dalias: the atomic ops couldn't be lifted? [23:45:46] <michaelni> lu_zero, mru will will still need a flag for read/write fields ... [23:45:52] <mru> read/write avoption access to non-commandline fields can be addresssed when we require it [23:46:23] <j-b> http://pastebin.com/qtfMT25H and http://pastebin.com/6EtUGwHv [23:46:29] <michaelni> ohh well, why easy when one can solve it complexly and obfusacted [23:46:39] <mru> you call this obfuscated??? [23:46:59] <lu_zero> calm mru [23:47:00] <mru> I've rarely seen a simpler patch, and it perfectly describes the field semantics [23:47:01] <Compn> lu_zero : you know the vote is just to give everyone commit access right ? [23:47:03] <michaelni> j-b, V|E looks bad [23:47:12] * Compn reads log [23:47:40] <j-b> michaelni: then back to the docs I am :) [23:47:41] <michaelni> mru, it solves only half the ABI issue, namely only for readonly fields [23:47:49] <michaelni> j-b, you need the new flag in there [23:48:05] <michaelni> that readonly flag [23:48:33] <mru> maybe should have A as well, on the off-chance some audio encoder would want to use it [23:49:24] <j-b> A|V|AV_OPT_FLAG_READONLY then? [23:49:36] <j-b> michaelni: indeed, makes sense [23:49:39] <michaelni> and E IIRC [23:49:47] <michaelni> encooder that is [23:49:53] <mru> of course E [23:50:14] <j-b> http://pastebin.com/BVXFG9Cs [23:50:31] <michaelni> LGTM [23:50:44] <mru> perhaps the comment could be less verbose [23:51:26] <michaelni> ahh bikeshedimg ... [23:51:39] <j-b> if I actually knew what vbv-delay was, I could help :) [23:51:50] <mru> reading the spec now... [23:52:19] <kierank> it's the amount of time that should be spent buffering before the decoding of the first frame [23:52:21] <j-b> For constant bitrate operation, the vbv_delay 14is used to set the initial occupancy of the decoder's buffer at the start of play so that the decoder's buffer does not overflow or underflow. The vbv_delay measures the time needed to fill the VBV buffer from an initially empty state at the bitrate, R, to the correct level immediately before the current picture is removed from the buffer. [23:53:18] <michaelni> j-b, thats better then whats in the patch ;) [23:53:35] <Sean_McG> wow... epic commits lately [23:53:49] <kierank> michaelni: I have done that sports karaoke thing before [23:53:59] <j-b> michaelni: a bit long, ain't it? [23:54:06] <michaelni> j-b, :))) [23:54:43] <j-b> and I still have 0 understanding of what that means, but well. I'll read the doc another day [23:55:04] <iive> j-b: i think i may have an idea. [23:55:45] * michaelni thinks its the time to wait when you start before playback starts aka buffer fill time [23:55:47] <iive> j-b: wanna hear it now? [23:55:53] <j-b> iive: sure [23:56:01] <mru> what michaelni said [23:56:29] <mru> for realvideo the value is infinity [23:56:40] <j-b> "get the 'buffer fill time' in periods of 27Mhz clock" for the help then? [23:56:54] <mru> I'd drop the "get the" [23:56:54] <kierank> j-b: that implies the whole buffer is being filled which is not necessarily true [23:56:55] <iive> j-b: ok. first case. you want to start playing something. you must take it from the buffer, but the buffer is completely empty. [23:57:00] <Dark_Shikari> listing the buffer fill time is impossible for VFR video [23:57:03] <Dark_Shikari> because you don't know future timestamps [23:57:12] <Dark_Shikari> you can list the number of BITS you need to fill, iirc. [23:57:23] <Dark_Shikari> (referring to _decoding_ and reading HRD data, here) [23:57:34] <j-b> iive: yes [23:57:34] <Dark_Shikari> ... though that could be converted to time. [23:57:36] <iive> j-b: so you have to pre-buffer some data, before you want to start playback. [23:58:20] <j-b> kierank: indeed. Better idea for wording? [23:58:31] <iive> j-b: then, you remove packets from it, as you play them. [23:58:57] <iive> if you remove them too fast, it would underflow... [23:58:58] <kierank> j-b: initial buffer fill time [23:59:19] <mru> sounds good [23:59:26] <michaelni> yes [23:59:54] <j-b> http://pastebin.com/Y2J9DBge then

1 0

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

15 Feb '11

[00:03:32] <mru> hmm, adding restrict to a pointer makes the armcc bug in dv go away [00:03:37] <mru> that's a first [00:04:02] <peloverde> that seems weird [00:04:08] <mru> not really [00:04:36] <mru> adding restrict allows the compiler to optimise out the bit it miscompiled otherwise [00:04:45] <peloverde> restrict should never be necessary, it should only open the door to better optimization [00:04:56] <mru> it's a compiler bug [00:05:10] <mru> _anything_ can affect those [00:05:10] <peloverde> if restrict is required to get proper output you are papering over a bug in the source or compiler [00:05:17] <mru> I know that [00:05:20] <mru> I'm just tinkering [00:05:27] <mru> to narrow down the bug [00:05:53] <mru> now I'm pretty certain it has to do with a specific pointer dereference [00:05:56] <mru> time to read asm [00:31:51] <mru> found it [00:38:24] <Sean_McG> wow at the cygwin results... 8/499 [00:38:49] <mru> something unrelated failed [00:38:53] <Sean_McG> ah [00:40:12] <mru> they are all new failures [00:40:37] <Sean_McG> it doesn't capture stderr either? is that a cygwin issue? [00:40:55] <mru> probably there was none [00:41:05] <mru> I suspect it failed to execute ffmpeg at all [00:42:34] <mru> if you expand the list of failed tests on the front page, new failures are listed in red [00:42:54] <Sean_McG> oh cool [00:43:41] <mru> the full report page also tells which revision the test last passed, if any [00:44:01] <Sean_McG> ah so it does keep history then [00:44:07] <mru> sure [00:44:21] <mru> click the timestamp at the left for a recent history [00:44:36] <mru> it only shows the 50 latest reports for now [00:45:39] * Sean_McG LOLs @ gentoo with the pre9999 [00:45:53] <mru> yeah, I know [00:46:10] <Sean_McG> we've still got over 20 P1 & P2 bugs before we can release 4.6.0 [00:46:36] <mru> I predict 4.6.0 will be rather bad [00:46:39] <Sean_McG> a number of which are specific to platforms I don't use (HPPA) [00:46:46] <mru> it's a .0 of an even parity series [00:47:29] <mru> have you heard my theory about gcc release quality? [00:48:04] <peloverde> it sucks because they reprioritze P1s so they can release? [00:48:11] <Sean_McG> not yet, but it's usually heartbreaking to hear people go on about it [00:48:29] <mru> peloverde: that too [00:48:53] <mru> I was referring to the parity rule [00:49:12] <mru> if major and minor numbers have odd parity, it's a good one [00:49:24] <mru> or will be once micro becomes > minor [00:49:40] <mru> I haven't quite worked out that last one [00:50:53] <Sean_McG> anyhow... getting a ride home now and I think I will catch up on some anime when I get there so if you folks aren't around when I return then take care [00:51:12] <mru> enjoy the cartoons [01:17:59] <Compn> i wonder if youtube does have a porn detection filter... [01:18:16] <Compn> it must [01:19:51] <ohsix> theres also the human filter [01:20:17] <Compn> yes but i think its pretty difficult to review that many videos [01:20:18] <Compn> and costly [01:20:43] <ohsix> people watching them flag them, doesn't have to be at youtub [01:21:06] <mru> but omg, think of the children@!!!@!@!@# [01:21:17] <Compn> quick statistic i pulled out, '20 hours of video uploaded to youtube every second' [01:21:39] <ohsix> they probably do audio detection for porno noises and skin tones, and give it a number like spamassassin; then just put it behind a login warning [01:21:58] <Compn> i guess humans could review in 2x speed... [01:22:05] <Compn> doesnt have to be realtime [01:22:12] <Compn> maybe even 4x :) [01:22:16] <ohsix> new footage isn't watched footage either [01:22:32] <Compn> huh? [01:22:42] <ohsix> chances are the first guy that actually sees it besides the uploader will probably flag it; or show it to their friends, one of which will [01:22:54] <ohsix> it's not porn until someone sees it :D [01:22:59] <Compn> shcrodinger porn [01:23:18] <Compn> btw even behind login wall, its rare to see nude people on youtube [01:23:38] <ohsix> yea, most stuff flagged behind the login is tame stuff too [01:23:56] <ohsix> i've seen lots of boobies in trailers for old movies though; and that's all down to who's viewing them [01:24:00] <mru> there are other sources of porn, you know... [01:24:27] <Compn> i'm just making a point that whatever youtube is doing, it works [01:24:55] <ohsix> soylent green is people [01:25:05] <Compn> http://www.youtube.com/watch?v=IVnba8ipJ9I [01:26:01] <ohsix> there's also that [01:26:15] <Compn> private videos [01:26:17] <Compn> right [01:26:22] <ohsix> unlisted videos only get viewed by the uploader and people that almost definitely don't give a shit [01:26:24] <saintdev> i've come across some old r3d samples, and have gotten permission to put them up on samples.mphq.hu. Are we interested in them? [01:26:53] <Compn> they all decode properly ? [01:27:08] <saintdev> we don't have a decoder... [01:27:33] <saintdev> we have a demuxer [01:27:58] * Compn forgot what codec is in r3d [01:28:04] <saintdev> r3d [01:28:11] <saintdev> or REDCODE [01:28:11] <Compn> ah [01:28:14] <Compn> samples welcome then [01:28:55] <saintdev> Compn: we have one up there already, afaikt it' appears to be from a newer firmware than these are. [01:30:12] <Compn> well firmware probably not really matter, but spec/api/version might :) [01:30:24] <ohsix> no spec [01:30:33] <saintdev> Compn: well the firmware determines the version ;) [01:30:38] * Compn wonders why he didnt find binary red codec for mplayer [01:30:38] <ohsix> it rolls with their firmware versions and their software [01:30:59] <Compn> sounds like a pain in the ass [01:31:06] <ohsix> that's why they rule [01:31:40] <ohsix> inexpensive modular digital and the tie in [01:31:53] <saintdev> and according to the guy i got the samples from they significantly changed the file format in a later firmware [01:32:36] <Compn> ugg [01:32:45] <Compn> well sounds perfect for ffmpeg devs :) [01:32:45] <saintdev> i don't know how much truth that holds, or how it compares to our existing sample [01:32:54] <Compn> they love incompatable version file formats [01:33:08] <saintdev> i just thought it would be nice to have more samples than the one we have. [01:33:23] <Compn> yep, be good [01:33:50] <saintdev> ok, how do i go about putting them in the right place? [01:35:34] <Compn> upload directly to the dir using developer login [01:35:55] * saintdev doesn't have one. [01:36:45] <Compn> check pm [01:39:21] <ohsix> they only do it that way cuz of the sensors, and that it's a raw format [01:40:28] <saintdev> ohsix: it's not raw. [01:40:45] <ohsix> ehhhhhhh [01:40:57] <saintdev> it's called "REDCODE RAW" [01:41:23] <ohsix> the contents are multispectral bayer shits [01:41:28] <mru> is it boiled, fried, grilled, baked, or something else? [01:41:33] <saintdev> but it's lossily wavelet compressed (i've read it's similar to jpeg2k) [01:41:50] <mru> ah, poached [01:43:51] <ohsix> but anyways, processing the footage is tied to the sensor it was shot on [01:44:47] <saintdev> do i have to worry about md5sum, etc? or are those scripted? [01:45:19] <Dark_Shikari> the "raw" name is to mislead you into thinking their footage is actually 4K [01:45:22] <Dark_Shikari> when it's really more like 720p [01:47:05] <ohsix> that'd be quite a scam [01:50:01] <Compn> 720p should be enough for everyone :P [01:50:30] <Dark_Shikari> 20mbit wavelet "4K" is a scam. [01:50:32] <ohsix> flic 4 lyf [01:50:40] <Sean_McG> just a way to sell equipment [01:52:10] <ohsix> they're haxors [01:52:17] <Sean_McG> 31337? [01:55:14] <ohsix> Dark_Shikari: maximum bitrate is 244mbit/s, up to 366 on newer devices [01:55:27] <Dark_Shikari> Their marketing material at least originally claimed really stupid low bitrates. [01:55:36] <Dark_Shikari> 244 mbit sounds quite feasible for 4K though. [01:55:48] <ohsix> shrug @ marketing material [01:56:06] <ohsix> the sensor can do windowing and lower resolutions, dunno what use a minimum or average bitrate number would be [01:57:42] <saintdev> Dark_Shikari: it was 28 MBps [01:57:57] <Dark_Shikari> MBps? [01:57:58] <saintdev> which is 224 Mbps [01:58:06] <saintdev> megabytes per second [01:58:10] <Dark_Shikari> oh, that's much more feasible. [01:58:31] <saintdev> the choices are 28MBps 36MBps and 42MBps [02:02:09] <ohsix> Werner Herzog shot his film My Son, My Son, What Have Ye Done? with the Red One. He was disappointed with the camera's long reboot times, saying "It drove me insane, because sometimes something is happening and you can't just push the button and record it". He described the camera as "an immature camera created by computer people who do not have a sensibility or understanding for the value of high-precision mechanics" [02:02:18] <ohsix> HUHUHU, i've got tha tmovie in my "to see" bin [02:02:56] <ohsix> hm the social network was done on a red one too [02:03:25] <saintdev> ...and that's why Cameron bought 30 Red Epics... [02:04:40] <ohsix> apparently they can take the suck out of digital cinematography if they can play with the bayer data [02:26:19] <kierank2> red are licensing x264 [02:26:32] <kierank2> so their tech can't be *that* good [02:27:08] <Sean_McG> isn't that much more likely to be part of their postproduction stuff than part of the camera? [02:27:22] <kierank2> probabl [02:27:23] <Dark_Shikari> of course. [02:27:50] <kierank2> don't let facts get in the way of some good marketing [02:28:20] <Sean_McG> lol [02:28:30] <Sean_McG> anyways, I'mma go watch some Highschool of the Dead [05:09:16] <kierank2> http://code.google.com/p/ffmpeg-p3dtv/ [05:22:01] <Compn> p3dtv ? [05:22:06] * Compn lazy to cllick [07:01:04] <Dark_Shikari> http://search.cpan.org/~dconway/Lingua-Romana-Perligata-0.50/lib/Lingua/Rom… [07:01:12] <Dark_Shikari> Now we can say for sure that Perl really is a dead language! [07:03:31] <pJok> Dark_Shikari, funny enough, that does seem to make perl less obscure for some reason.... [07:40:54] <KotH> salut [07:41:32] <KotH> elenril: nope, i dont mind good samples, as long as it will be sorted in properly ;) [07:44:06] <cartman> moin [07:47:01] <KotH> moin cartman [07:48:11] <cartman> KotH: its official, I am moving to Germany :) [07:50:52] <KotH> /o\ [07:51:35] <cartman> You mean \o( [07:51:40] <cartman> You mean \o/ rather [07:52:14] <cartman> KotH: Would you be happier if I went to France instead? [07:53:18] <spaam> cartman: why germany? ;S [07:53:42] <cartman> spaam: there is an awesome Linux company there ;) [07:54:44] <KotH> cartman: are you going to köln? to ms? [07:54:52] <spaam> cartman: so they will give you $$$ to fix gl output for ffplay? nice [07:54:58] <cartman> KotH: NÃŒrnberg, SUSE :) [07:55:16] <KotH> /o\ [07:55:17] <cartman> I'll make sure that I bug _av500_ enough though [07:55:43] <cartman> KotH: you are supposed to be proud of me instead ;) [07:55:47] <spaam> cartman: when are you going to move? :D [07:55:56] <cartman> spaam: Early March [07:56:03] <spaam> cartman: oh nice .. glhf then :) [07:56:08] <cartman> glhf? :D [07:56:18] <cartman> Good luck have fun? :D [07:56:20] <spaam> cartman: good luck and have fun ;D [07:56:22] <spaam> yes [07:56:25] <cartman> nice compression :D [07:56:48] <cartman> KotH: you are not happy because you don't like German chaklit right? [08:00:53] <KotH> cartman: no. because you're leaving your homeland instead of defending it against vultures sitting on dear-skin chairs [08:01:30] <cartman> KotH: oh well... [08:02:29] <KotH> italian deer-skin nonetheless! [08:02:49] <cartman> nice one! [08:03:04] <KotH> hey, it's true! [08:03:10] <cartman> I know :> [08:06:53] <cartman> KotH: when are you coming back to .tr then? :P [08:09:40] <KotH> as soon as i've gathered an army [08:10:48] <cartman> LOL [08:10:51] <cartman> count me in [08:10:52] * elenril knew it [08:11:47] <cartman> KotH: Everybody has a plan until they get hit. [08:12:15] <superdump> peloverde: ping? [08:12:23] <peloverde> pong [08:12:33] <superdump> why was that scaling code dead? [08:14:08] <peloverde> because of this http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=9d06d7bce3babb82ed650c13… [08:14:08] * cartman hears another police raid [08:14:37] <KotH> cartman: the secret about a successfull revolution is _not_ getting hit ;) [08:14:54] <cartman> KotH: heheh true [08:15:34] <peloverde> I double check that make fate still works both with and without asm [08:19:48] <superdump> looks right [08:21:07] <superdump> peloverde: also, with young's submission, i don't suppose you verified that ret can be reduced to 1024 elements from 2048 did you? [08:22:41] <peloverde> hmm, when did that part get there? [08:24:29] <peloverde> seems like it first showed up revision 9 [08:24:36] <peloverde> and also seems like ti will break SBR [08:27:22] <peloverde> hmmm, fate still passes but i think it's because the second half of ret is aliasing ltp_state [08:27:26] <peloverde> care to comment on this? [08:27:55] <peloverde> Looks like it happened revision 9 [08:31:21] <superdump> peloverde: hmmmmm :) [08:31:28] <superdump> i don't like such hacks personally [08:31:40] <peloverde> i agree [08:31:44] <superdump> i'd be fine with a lump of ram that is used for multiple mutually exclusive things [08:32:00] <peloverde> the correct hack is to alias ltp_state and predictor state with a union [08:32:14] <peloverde> those two really are mutually exclusive [08:32:15] <kshishkov> superdump: every moder computer RAM is such [08:32:50] <superdump> peloverde: as for reducing ltp_state, i think it's something to look at later unless you have time right now [08:33:14] <peloverde> I think it's fine for later as well [08:33:38] <peloverde> I'd rather get something committed sooner, positive feedback, etc. [08:35:58] <superdump> yup [08:59:35] <wbs> about the guy sending patches for mpeg2ts muxer for bluray - what's the point in having two separate muxers, one "mpegts" and one "mpeg2ts"? [09:00:41] <Dark_Shikari> blu-ray "mpeg ts" is slightly different [09:00:44] <kshishkov> bluray m2ts is not compatible [09:00:45] <Dark_Shikari> it has an extra 4 bytes among other things. [09:00:49] <Dark_Shikari> per packet [09:00:53] <wbs> ah, ok [09:03:59] <peloverde> I hope the FFmpeg developers 50 years from now curse the crazy formats I come up with [09:04:32] <kshishkov> Vorbis+SBR? [09:04:37] <kshishkov> or FLAC+SBR? [09:05:29] <peloverde> adpcm_ms+SBR [09:05:45] <wbs> lol [09:07:23] <kshishkov> but it's reasonable [09:11:59] <hyc> hey, is anyone working on atrac3plus these days? [09:19:47] <kshishkov> hyc: probably [09:19:50] <Kovensky> 06:17.28 rfw: i am going to use the json license in my software [09:19:50] <Kovensky> 06:17.44 rfw: i find it hilarious that the clause "The Software shall be used for Good, not Evil." makes it incompatible with the GPL [09:20:26] <Dark_Shikari> Of course. the GPL isn't discrimanatory against evil people. [09:20:34] <kshishkov> GNU is beyond good and evil [09:20:46] <wbs> the "no additional requirements" part of GPL adds all sorts of complications :-( [09:20:47] <Dark_Shikari> Beyond Good and Evil is a good game. [09:22:56] <astrange> it's incompatible with a lot of things [09:23:07] <kshishkov> Dark_Shikari: you play something not related to Houhou? [09:23:23] <astrange> anyone who's going to run things through a lawyer will object to someone else being able to define if they're evil or not [09:23:53] <kshishkov> for me having a lawer is a clear sign of evilness [09:25:02] * cartman has a lawyer friend [09:28:00] <hyc> lol... kshishkov: agreed. heck, even Shakespeare said "the first thing we do is kill all the lawyers" [09:28:01] <kshishkov> cartman: and you're going to work for SuSe, that counts even more [09:28:28] <astrange> just use WTFPL [09:28:36] <kshishkov> hyc: I'm not in USA and the rest of world doesn't have lawyer mafia [09:28:53] <kshishkov> astrange: WTFPL v2 actually [09:29:54] <uau> that "hilarious" comment shows a lack of understanding / judgment [09:30:05] <uau> it's obviously a very problematic clause [09:30:10] <peloverde> "I hereby give IBM and its customers permission to use this software for evil" [09:31:01] <elenril> s/customers/minions/ [09:32:14] <kshishkov> peloverde: laugh till your code ends in Windows Media [09:34:49] <__av500__> cartman: work for Suse, cool, I can bug you with bugs all day long [09:35:16] <cartman> __av500__: I will be L3 support [09:35:19] <cartman> you can't bug me :P [09:35:31] <__av500__> cartman: of course I can [09:35:40] <cartman> You paid for it? :) [09:36:09] <av500> cartman: priceless hours of my life lost [09:36:14] <cartman> LOL [09:36:15] <av500> so yes, I paid dearly [09:36:36] <cartman> shouldn't be _that_ bad, its pretty solid :) [09:37:22] <mru> suse? you mean novell^W attachmate? [09:37:29] <cartman> mru: SUSE/* [09:37:31] <cartman> yes [09:38:02] <mru> I thought they'd be firing, not hiring [09:38:04] <thresh> you evil MS liker [09:38:13] <av500> cartman: I hope suse does not follow the trend to swicht to some windows 7 variant [09:38:29] <cartman> av500: nah I don't think so :) [09:38:40] <cartman> mru: They don't fire R&D, neither does Nokia [09:38:46] <av500> they could switch to redhat7 [09:38:53] <av500> that was pretty soldi [09:38:54] <av500> solid [09:39:01] <cartman> av500: I do know Linux you know :P [09:39:09] <av500> cartman: neither does Nokia, lol [09:39:27] <thresh> well nokia will actually fire a lot of folks [09:39:41] <cartman> what I heard is Nokia won't fire Qt R&D guys [09:39:41] <thresh> most will go away by themselves though [09:39:56] <av500> they set thier burning platform on fire last friday [09:39:57] <thresh> my peeps @ meego team say they're not motivated now [09:39:58] <cartman> they were still hiring [09:40:12] <wbs> thresh: wonder why.. [09:40:12] <cartman> thresh: true they'll move to somewhere else probably [09:40:21] <pJok> thresh, probably moving to android then? [09:40:26] <av500> back to making tires.... [09:40:37] <cartman> I had a MeeGo related job opportunity in Finland [09:40:41] <cartman> good idea to refuse it :P [09:41:09] <DonDiego> nah, just make sure you work on infrastructure that is of general usefulness... [09:41:16] <thresh> pJok: well there is a lot of interesting linux related work, not only the embedded stuff [09:41:22] <j-b> oy [09:41:40] <DonDiego> saste: moin - do you have any patches pending for me to review? [09:42:19] <pJok> thresh, of course [09:42:26] <cartman> Google is hiring at least :p [09:44:12] <pJok> isn't google always hiring? [09:44:26] <cartman> hiring thousands these days [09:46:44] <peloverde> word is on the street they are planning on building a death star [09:56:59] <CIA-38> ffmpeg: Alex Converse <alex.converse(a)gmail.com> master * r916dee9f45 ffmpeg/libavcodec/aacsbr.c: [09:56:59] <CIA-38> ffmpeg: aac: remove dead SBR input scaling [09:56:59] <CIA-38> ffmpeg: It has been unused since 9d06d7bce3babb82ed650c13ed13a57f6f626a71 [09:56:59] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:07:42] <kshishkov> mate! [11:08:31] <spaam> kshishkov: Time to fix that audio issue? :D [11:08:47] <kshishkov> spaam: why are you asking me? [11:09:11] <spaam> kshishkov: beacuse you are bink guy nr1 [11:09:17] <pross-au> There is no audio issue in my tree :) [11:09:22] <pJok> kshishkov actually codes? ;) [11:09:34] <kshishkov> pross-au: where's the patch? [11:09:35] <spaam> pJok: sometimes. [11:09:47] <pross-au> Forthcoming [11:09:49] <kshishkov> pJok: why should I? [11:10:19] <kshishkov> pross-au: good, then we can forget about Bink completely and do something nonproductive instead [11:10:32] <pross-au> Bink is awesome [11:10:52] <kshishkov> wow http://losslessaudio.org/ [11:11:19] <kshishkov> undead lossless audio codecs! run for your life! [11:12:21] <av500> kshishkov: 1st undead mplayer devs, not undead codecs, what is next? [11:12:27] <av500> not->now [11:12:45] <cartman> The Walking Dead [11:12:54] <pross-au> Codecs that suck your BLOOD [11:13:01] <kshishkov> av500: undead standards? or undead hardware? dunno [11:13:05] <kshishkov> pross-au: brains! [11:13:24] <kshishkov> please try REing RALF [11:14:06] <pross-au> RALF? [11:14:35] <kshishkov> Retarded Audio Lossless Format [11:14:36] <av500> real audio lossless [11:15:50] <av500> KotH: so you can keep your gun at home! [11:16:31] <kshishkov> pross-au: it uses ~30kb for Huffman tables description [11:16:58] <kshishkov> pross-au: so please look at it, decide that Z video is better and RE it ;) [11:17:26] <pross-au> the Z one is fidely because well, its DOS. [11:18:05] <kshishkov> iKnow [11:18:36] <spaam> iKostya [11:18:48] <kshishkov> but I still like to have Discworld Noir video decoder and it's hard to even pinpoint in executable - it's all coroutines [11:19:29] <pross-au> Well, you can resort to studying the bitstream [11:19:54] <pross-au> Thats how the American laser games one was reverse engineered [11:20:45] <mru> that's the proper way [11:21:01] <kshishkov> pross-au: that was how I REd my first codec and some others [11:24:13] <kshishkov> pross-au: here's its first generation (from Discworld II) - https://github.com/scummvm/scummvm/blob/master/engines/tinsel/bmv.cpp [11:32:18] <pross-au> Never got into those games ksh. FFmpeg doesnt support any Discworld formats? [11:35:00] <kshishkov> nope [11:35:30] <kshishkov> there was experimental decoder based on that ScummVM code but I'm not sure if I've ever submitted it [11:38:16] <kshishkov> and for Discworld Noir I've REd file structure (it was almost the same) and found audio decoder IIRC [11:51:35] <BBB> peloverde: re "[PATCH] Don't write an illegal stsz when sample size is larger than sample count", will you add a comment? I'll commit after that [11:55:23] <mru> peloverde, saintdev: linaro are talking about aac encoders [11:55:36] <av500> ffaacenc? [11:55:51] <j-b> faac relicensing? [11:56:05] <mru> they think there's a need for a good open-source one [11:56:08] <mru> I tend to agree [11:56:36] <j-b> yes [11:57:12] <av500> mru: I just pinged goog on relicencing the android one.... [11:57:18] <av500> +spelling [11:57:19] <Dark_Shikari> >faac [11:57:20] <Dark_Shikari> >good [11:57:26] <mru> better than ffaac [11:57:38] <cartman> av500: I thought they only had a decoder [11:57:56] <av500> cartman: you thought wrong then [11:58:30] <cartman> av500: and I thought it was Apache licensed [12:00:20] <mru> that part you thought correctly [12:00:40] <cartman> good luck with relicensing it then [12:00:42] <av500> cartman: hence us asking to get it gpl/lgpl [12:01:43] <lu_zero> lgpl would be better probably [12:02:12] <lu_zero> btw ffaac is "just" missing a complete psy-model or something else? [12:13:05] <BBB> hm I keep missing astrange [12:13:17] <kshishkov> aim better [12:13:30] <wbs> BBB: which parts of -mt were committed, and which parts are left? [12:13:48] <wbs> BBB: h264 still missing, right? any other codecs? [12:14:02] <spaam> bink-mt [12:14:11] <spaam> kshishkov going to fix that this year [12:14:35] <kshishkov> spaam: well, at least WavPack multichannel decoding can be made threaded [12:16:04] <spaam> :) [12:16:36] <kshishkov> and parts of Xan WC4 frame can be decoded in parallel [12:17:36] <superdump> lu_zero: it needs someone smart to work on it and make it good [12:18:22] <av500> hmm, could one use -mt also for audio? [12:18:51] <superdump> i think the work focused on video and mpegenccontext and such [12:18:57] <superdump> but perhaps i'm wrong [12:19:01] <superdump> astrange: ^ [12:19:37] <av500> e.g. if I have 5 audio tracks to encode [12:20:05] <av500> but thats not the same [12:20:13] <av500> thats more like adding -mt to ffmpeg.c [12:20:35] <av500> i guess there is not much audio where one can encode/decode frames on their own [12:20:52] <kshishkov> just run LAME in parallel and mux result [12:21:13] <av500> for mp3 :) [12:21:26] <kshishkov> and you won't gain much on ffaacenc :P [12:22:03] <cartman> encoding silence, multithreaded! [12:22:31] <av500> [PATCH] make codec PCM use several cores [12:22:31] <BBB> wbs: theora was committed (well, vp3) [12:22:45] <BBB> wbs: h264/h263/mpeg/huffyuv was not committed [12:22:47] <divVerent> av500: yay :P [12:22:51] <cartman> BBB: had time to look at VP8 failures with clang -O2? [12:22:55] <BBB> I don't know if huffyuv was actually multithreaded [12:22:57] <divVerent> multithreaded endianness conversion NOW ;) [12:23:08] <wbs> BBB: ok, how much work do you think there's remaining on those ones? [12:23:13] <BBB> cartman: looked at clang 2.8, cannot reproduce [12:23:14] <mru> divVerent: one byte per core? [12:23:18] <BBB> wbs: not much [12:23:20] <divVerent> mru: yeah :P [12:23:27] <divVerent> mru: one core reads even bytes, writes to odd [12:23:28] <BBB> cartman: I'll try on kostylev's machine at some point [12:23:30] <cartman> BBB: you need clang 2.9 trunk, 2.8 doesn't optimise well [12:23:31] <divVerent> opther reads odd, writes to even [12:23:33] <divVerent> PROBLEM? ;) [12:23:34] <cartman> BBB: ok [12:23:37] <BBB> cartman: until then, compiler error is likely [12:23:52] <divVerent> CPU cache will go bankrupt [12:23:56] <mru> divVerent: that is probably the slowest possible way of doing it [12:23:57] <BBB> cartman: feel free to try various combinations of that patch, change random stuff, no-inline, etc. until it works [12:24:03] <divVerent> mru: right :P [12:24:11] <mru> anyone for a game of ping-pong? [12:24:16] <divVerent> sane would probably be dividing the work into two halves, and avoiding overlapping writes :P [12:24:44] <mru> actually, what would probably happen is one core would get ahead by a cacheline and stay there [12:24:59] <mru> still bad, but not quite the worst case [12:25:23] <divVerent> don't worry, just do a barrier every 16 bytes to make sure it'll suck :P [12:25:43] <Dark_Shikari> "optimize well" == "miscompile code"? [12:25:45] <KotH> mru: the only way to win is not to play :) [12:25:47] <kshishkov> mru: multithreaded bureacracy! [12:25:56] <divVerent> kshishkov: best way to describe it ;) [12:26:10] <av500> isnt there an internet service like NTP that one sends data to and it returns it endian-reversed? [12:26:40] <mru> I know of the standard echo service [12:26:45] <kshishkov> av500: bswap instruction on CPU is usually enough [12:26:51] <divVerent> another thing I always wondered... how many reimplementations of htonl/htons exist? [12:26:52] <av500> kshishkov: not cloudy enough [12:27:05] <divVerent> also, why do we have both htonl and ntohl? [12:27:11] <divVerent> they do THE EXACT SAME THING, ALWAYS [12:27:19] <mru> for clarity [12:27:28] <mru> makes it obvious which side is which [12:27:31] <divVerent> then the header should be allowed to use a macro for these [12:28:00] <divVerent> oh, it IS a macro [12:28:01] <mru> "On some implementations, these functions are defined as macros." [12:28:18] <divVerent> or not [12:28:36] <divVerent> here, they are macros if __OPTIMIZE__ is defined [12:28:59] <kshishkov> ...an option totally unacceptable in glibc [12:29:10] <divVerent> how so? [12:29:21] <divVerent> what is this macro anyway, set by gcc -O? [12:29:37] <mru> yes [13:11:00] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rb7ec5cc401 ffmpeg/ffplay.c: (log message trimmed) [13:11:00] <CIA-38> ffmpeg: Remove disabled legacy code in ffplay. [13:11:00] <CIA-38> ffmpeg: The code was setting aspect ratio from the DTG active format, and was [13:11:00] <CIA-38> ffmpeg: present and disabled since the creation of ffplay. [13:11:00] <CIA-38> ffmpeg: See thread: [13:11:01] <CIA-38> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Cosmetics: adopt compact notation in [13:11:02] <CIA-38> ffmpeg: disabled code. [13:13:49] <DonDiego> superdump, peloverde, could you please teach young han lee to snip quotes or at least remove the mailing list footers yourself? thx [13:14:17] <lu_zero> ^^; [13:15:28] <superdump> i have been iirc [13:15:44] <superdump> but yes, we should point it out [13:16:18] <DonDiego> note that many people here are guilty of excessive quoting... [13:17:04] <av500> > note that many people here are guilty of excessive quoting... [13:17:05] <av500> who? [13:18:41] <DonDiego> i don't remember offhand, i can point some fingers as i notice offenders if you want :) [13:18:55] <av500> > i don't remember offhand, i can point some fingers as i notice offenders if you want :) [13:18:59] <av500> no, i trust you [13:19:47] <CIA-38> ffmpeg: Michael Niedermayer <michaelni(a)gmx.at> master * r910b5b82e8 ffmpeg/libavfilter/ (avfilter.c avfilter.h vf_aspect.c vf_transpose.c): [13:19:47] <CIA-38> ffmpeg: Add sample_aspect_ratio to AVFilterLink [13:19:47] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:19:57] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r08a459f096 ffmpeg/doc/APIchanges: [13:19:58] <CIA-38> ffmpeg: Update APIchanges for 910b5b8 [13:19:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:20:55] <divVerent> You are doing it wrong. On IRC, you quote Outlook style. av500 wrote: > > i don't remember offhand, i can point sume fingers as i > notice > > offenders if you want :) [13:22:12] <divVerent> argh, failed to properly do a FULL quote ;) [13:22:18] <av500> divVerent: yes, but how do I top post on irc? divVerent wrote: You are doing it wrong. On IRC, you quote Outlook style. av500 wrote: > > i don't remember offhand, i can point sume fingers as i > notice > > offenders if you want :) [13:23:03] <divVerent> av500: wrote: divVerent: yes, but how do I top post on irc? divVerent wrote: You are doing it wrong. On IRC, you quote Outlook style. av500 wrote: > > i don't remember offhand, i can point sume fingers as i > notice > > offenders if you want :) actually, on IRC top posting seems to work out better than bottom posting. [13:29:31] <mru> av500: top-posting on irc is trivial once you master precognition [13:30:13] <av500> s/wat/what/ [13:30:14] <av500> wat? [13:30:18] <divVerent> there sure is some IRC client that adds new lines at then top [13:30:35] <mru> you could run irc in hyperterm for a partial effect [13:31:56] <divVerent> "blog-style interface to IRC" now [13:32:30] <mru> f1rst! [13:32:47] * elenril double-stabs av500 and divVerent [13:32:54] <av500> we should move away from irc andway and use a *forum* [13:33:02] <av500> andway->anyway [13:33:05] <av500> [edit] [13:33:11] <divVerent> you accidentally the usenet [13:33:33] <pJok> av500, forum is too newfangled [13:33:41] <av500> alt.bizarre.ffmpeg-devel [13:34:05] <pJok> alt.bikeshed.ffmpeg-devel [13:34:07] <pJok> or [13:34:10] <pJok> alt.flame [13:34:22] <av500> alt.ffmpeg.flame.flame.flame [13:34:29] <thresh> any flame topics I should read for last 4 days? [13:34:40] <divVerent> ANNOUNCEMENT: if you have a video sample to demonstrate a bug, always crosspost to alt.binaries.movies.pr0n.pr0n.pr0n [13:34:43] <av500> in fact, we are standing on a burning bikeshed [13:34:59] <divVerent> this is all fine... [13:35:01] <divVerent> but... [13:35:03] <divVerent> WHICH COLOR HAS IT? [13:35:13] <mru> by now, black [13:35:28] <divVerent> good, we'll go with that then [13:35:40] <av500> mru: full or reduced range? [13:35:49] <divVerent> the only thing why IRC is still not a complete mess yet... [13:35:56] <divVerent> is that IRC lacks features for crossposting [13:36:16] <divVerent> and also, lacks "Followup-to: #debian" [13:36:40] <av500> /autojoin divVerent #debian [13:36:50] <divVerent> that is still quite harmless :P [13:37:01] <divVerent> but redirecting replies would be quite evil [13:37:10] <divVerent> like one can do on Usenet (and some clients don't even notify about it) [13:37:41] <mru> and some clients rudely ignore it [13:37:46] <kshishkov> is it still September on Usenet? [13:38:04] <mru> yes [13:38:06] <av500> kshishkov: nope, all the aol ppl are on facebook now [13:38:22] <mru> remember remember, eternal september [13:38:24] <divVerent> also this is always fun on IRC: #notachannel.iknewyouwilljoinit [13:39:54] <divVerent> BTW, I just noticed that a channel #!/bin/sh exists. On another network, I once made that channel... accidentally. I posted a script, and some moron complained that nobody is in that channel. [13:41:11] <mru> it exists on freenode too [13:41:22] <av500> I like the topic [13:41:24] <mru> but the most disturbing channel is still #netbsd-furries [13:42:02] <kshishkov> what's so disturbing about NetBSD? [13:42:19] <mru> it's the combination [13:42:46] <kshishkov> well, every BSD user can have its own channel [13:42:50] <mru> and the only person to be banned from #alpha hangs out there [13:44:06] <divVerent> I suppose, "openbsd-furries" would be worse [13:44:18] <divVerent> just imagine a furry version of that fish thing [13:44:28] <mru> brain melt [13:44:30] <kshishkov> haven't he splitted already? [13:44:50] <divVerent> should I try posting the openbsd logo on 4chan, and ask for rule 34... better not [13:46:03] <Flameeyes> divVerent: for obsd nuts obsd is porn in itself [13:47:08] <divVerent> even if it got planed there by the FBI/NSA/CIA/Scientology/whoever? [13:47:11] <divVerent> *planted [13:48:06] <mru> which is worse, rule 34 on cia or scientology? [13:48:42] <Flameeyes> the latter [13:50:39] <siretart> baaah, images in my head. make them go away! [13:50:49] <divVerent> does the latter involve scientology's enemies too? [13:50:50] <lu_zero> siretart: uh? [13:50:58] <siretart> lu_zero: rule 34 on scientology [13:51:00] <divVerent> like, weirdos with guy fawkes masks who claim to "not forgive"? [13:51:08] <lu_zero> siretart: missing reference ^^ [13:51:15] <Flameeyes> divVerent: but they will forget! :P [13:51:54] <Flameeyes> lu_zero: https://xkcd.com/305/ [13:52:17] <Flameeyes> [don't ask me why I got the secure url..] [13:53:10] <lu_zero> Flameeyes: to be safe =) [13:53:28] <Flameeyes> lu_zero: more the fact that I have kb ssl installed on chromium :P [13:55:52] <Flameeyes> damn isn't there a useless use of cat lolcat? :| [13:56:30] <divVerent> IM IN UR COMMANDLINE DOIN NUTTIN USEFUL [13:57:51] <divVerent> USELESS CAT IS WATCHING YOU AWK|GREP|SED [13:58:20] <kshishkov> that's useless indeed, awk is enough [13:58:52] <divVerent> sure, this is why :P [13:58:55] <divVerent> but awk is so awkward [13:59:15] <divVerent> I prefer the pathologically eclectic rubbish lister [14:09:20] <mru> awk is nice at times [14:10:23] <spaam> How to you use it on times? [15:01:35] <BBB> michaelni: not to restart a trollwar again, but do you understand how infuriating it is to other developers who develop a "fix" for a problem (regardless of how good or bad this "fix" is), if you merely just tell them that the fix is "rejected" and then you just commit your own fix, without public discussion, without submitting a patch, anything? it's like we're worth nothing to you [15:04:59] <mru> BBB: you didn't know that sooner? [15:07:25] <divVerent> this is how FOSS development works. [15:07:27] <divVerent> Discuss. [15:16:50] <spaam> elenril: do you think he will do it? :P [15:20:39] <Compn> BBB : not to troll, but what is the 'correct' way to reject a patch and fix it yourself in a better way ? [15:21:30] <mru> Compn: start by explaining why it is wrong [15:21:38] <mru> and why the alternative is better [15:22:02] <mru> "fixing" the "better" solution moments later doesn't exactly inspire confidence either [15:22:21] <kshishkov> mru: it's mine ergo it's better [15:23:34] <BBB> Compn: send a patch [15:24:42] <BBB> Compn: mru is required to send patches before he can apply them. that way I can review them and poke his head whenever he does something stupid. there is no reason whatsoever why specifically and only Mr. Michael Niedermayer would be exempt from this rule as the only person in the whole FFmpeg developer community. he should send patches just like Mans and everybody else [15:25:35] <kshishkov> BBB: should we vote for that? [15:25:46] <av500> BBB: yes, but only for git.ffmpeg.org, no? [15:25:47] <BBB> let's bikeshed over it first [15:25:56] <BBB> and stop bikeshedding only if people don't reply by email for 7 days [15:26:24] <BBB> av500: well it doesn't inspire any confidence for us in having michael being part of the git.ffmpeg.org team, does it? [15:26:34] <av500> no comment :) [15:27:18] <kshishkov> BBB: all people to any email [15:27:53] <{V}> saying why it is rejected is/should be part of the procedure of either of the main repos, isn't/shouldn't it? [15:28:21] <DonDiego> BBB: you forget insulting people about how broken their code/tree/commits are and how yours is infinitely better, this step is mandatory! [15:56:30] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r275189a2bd ffmpeg/libavformat/mmst.c: [15:56:30] <CIA-38> ffmpeg: mmst: fix reading uninitialized data for ping packets. [15:56:30] <CIA-38> ffmpeg: Fixes errors after a few minutes (first ping) when playing back [15:56:30] <CIA-38> ffmpeg: mmst://wm.bbc.co.uk/wms/bbc7coyopa/bbc7_-_friday_0430.wma [16:08:32] <Flameeyes> TCP is fourth level in the stack isn't ti? [16:08:48] <mru> depends on where you start counting [16:09:06] <Flameeyes> mru: bottom, osi-style? [16:09:07] <kshishkov> mru: with usual 7-level model it doesn't matter [16:09:15] <mru> 7-lol [16:11:32] <mru> Flameeyes: some old book of mine puts tcp at layer 4 [16:12:15] <Flameeyes> thanks that should do [16:12:26] <kshishkov> passing an exam on networks? [16:12:36] <Flameeyes> kshishkov: writing documentation [16:12:38] * Flameeyes eyes lu_zero [16:13:13] <mru> I rarely memorise such irrelevant details [16:13:28] <mru> I know enough about how it works to get stuff done [16:13:40] <mru> arbitrary names don't help me there [16:13:43] <kshishkov> can you whistle at 4800? [16:13:57] <lu_zero> uhm [16:14:01] <mru> same with language and silly classifications of grammatical constructs [16:14:09] <lu_zero> Compn: BBB patch for mmst seems a good example [16:15:02] <kshishkov> mru: we had more formal grammar in school than German people in their life, so consider yourself lucky [16:26:04] <divVerent> kshishkov: I beg to differ :P [16:26:08] <divVerent> I had Latin at school [16:26:25] <kshishkov> I had Russian [16:26:28] <divVerent> sure [16:26:46] <divVerent> just saying... in Latin, we do nothing BUT learn about all sorts of formalities in grammar, and rhetorical forms [16:27:06] <divVerent> but I do know that Russian grammar is best described as "Like Latin. But worse." [16:27:29] <kshishkov> exactly [16:28:19] <mru> it bugs me when they try to classify other languages according to latin patterns [16:28:31] <divVerent> however, if you learn Latin at school, you PROBABLY put way more emphasis on the grammar constructs than in ANY "native" language class [16:28:49] <kierank> hehe latin [16:29:02] <divVerent> of course... now, if you had Russian AND Latin at school... then you must have the ultimate grammar experience :P [16:29:09] <mru> what with latin being a rather fossilised language and all... [16:29:23] * mru took an introductory class in russian [16:29:48] <divVerent> I mean... in German class, we never put much emphasis on grammar formalities [16:30:00] <divVerent> we learn what imperfect, perfect, conjunctive, etc. are... but that's it [16:30:08] <divVerent> to learn German grammar properly, you must learn Latin :P [16:30:57] <mru> occasionally someone will start talking about words belonging to some declension or other [16:30:58] <divVerent> I would go so far, and say that a German who chose French, not Latin, as second foreign language, will know less about grammar formalities than a 10 years old Russian [16:31:00] <mru> that's just silly to me [16:31:33] <mru> I have no trouble learning the correct inflections without categorising them [16:31:39] <divVerent> mru: especially funny are the Latin words that are in a declension but male [16:31:41] <divVerent> e.g. pirata, idiota [16:31:44] <mru> or at least without formally naming the categories [16:32:04] <mru> I never took latin [16:32:05] <divVerent> I wonder what picture the Romans had of women [16:32:17] <divVerent> if they use grammatically-female-looking words for pirate and idiot [16:32:28] <mru> pirate chicks, arrr [16:32:45] <divVerent> (note: "the biggest idiot" would be idiota maximus, not idiota maxima) [16:33:12] <divVerent> but nowadays, we call them just "user" ;) [16:33:16] <mru> hehe [16:33:22] <mru> or biggus dickus [16:33:27] <divVerent> or "manager" [16:33:58] <divVerent> what was so funny about his name? he was a fwiend of mine [16:34:40] <divVerent> anyway, just wanted to say... don't generalize [16:34:56] <mru> I try not to [16:35:00] <divVerent> some germans had Latin at school, and put a LOT of emphasis on grammatical details... they may be on the level of a typical Russian with that [16:35:20] <Kovensky> portuguese still has a lot of words with feminine-looking endings but that are masculine [16:35:20] <divVerent> many didn't, of course [16:35:26] <divVerent> Kovensky: like "Maria"? ;) [16:35:28] <Kovensky> pirata and idiota are some of those examples :P [16:35:33] <Kovensky> no, maria is female [16:35:36] <mru> and then there's swedish... [16:35:46] <divVerent> hm... in some languages, Maria is a male first name [16:35:49] <divVerent> some Spanish-like [16:35:50] <mru> with two genders, neither of them male nor female [16:35:52] <divVerent> but I forgot which ones [16:35:52] <Kovensky> spanish probably is the same [16:36:11] <Kovensky> maria here always is female [16:36:13] <divVerent> cool, what ARE the genders in swedish then? [16:36:20] <mru> just different [16:36:28] <divVerent> ah, nice [16:36:44] <divVerent> and what is really ill-designed in Latin, is the few declensions and conjugations that only apply to VERY FEW words [16:36:52] <divVerent> so few, that there is no point in actually learning them [16:37:06] <mru> swedish has four 3rd person singular pronouns [16:37:12] <divVerent> especially, as these ones even contain so many ambiguous forms that you need to guess anyway [16:37:35] <mru> that's why I don't bother memorising the declensions in the first place [16:37:56] <divVerent> e.g. look at the forms of "domus" (u declension), or "ferre, fero, tuli, latum" (HOW THE **** IS tuli THE PERFECT FORM, AND latum THE PARTICIP OF ferre?) [16:38:30] <divVerent> which is also etymologically funny, as from "transferre" we got both "transfer" and "translate" in English [16:39:09] <mru> nice [16:39:49] <divVerent> and of course... the one verb that is irregular in about every language: "to be" [16:39:57] <divVerent> in very few languages it is actually regular [16:40:01] <mru> yeah [16:40:26] <mru> where are you from btw? [16:40:30] <vipw> swedish has 3 genders, as i recall [16:40:31] <divVerent> Germany [16:40:37] <mru> vipw: no, two [16:40:38] <divVerent> "sein" in German, but why "ich bin" then? How can that come from the same word? Or worse: "gewesen", the perfect participle [16:40:39] <vipw> just feminine is almost ever used [16:40:42] <mru> wrong [16:41:07] <kierank> [16:32] mru: pirate chicks, arrr --> keira knightley [16:41:14] <lu_zero> 17:35 < divVerent> hm... in some languages, Maria is a male first name [16:41:19] <lu_zero> not first [16:41:21] <lu_zero> second [16:41:25] <lu_zero> same for Italian... [16:41:26] <mru> given name [16:41:28] <divVerent> it can only be second? [16:41:32] <divVerent> still, weird :P [16:41:35] <lu_zero> second or third [16:41:44] <lu_zero> divVerent: lookup my full name and have fun [16:41:44] <mru> there are spanish blokes called jesus maria [16:41:53] <divVerent> mru: yes, that is evil :P [16:43:00] <vipw> Though traces of the three-gender system still exist in archaic expressions and certain dialects, masculine and feminine nouns have today merged into the common gender [16:43:07] <mru> reminds me of a funny coincidence... the recent calls list on my phone happened to have at the top: jesus, mr monk, 666 666 [16:43:07] <vipw> thus spake wikipedia [16:43:17] <mru> the last one being the local taxi company [16:43:24] <vipw> but that's what i remember from swedish classes [16:43:38] <mru> vipw: that's about right [16:44:03] <mru> and the old neutral gender still remains [16:44:40] <mru> but you have four 3rd-person pronounds: han, hon, den, det [16:45:13] <vipw> not strange for english speakers (he she it_ [16:45:31] <mru> but there are two kinds of "it" [16:46:07] <mru> the maskuline and feminine ones are only used about people or, occasionally, animals [16:46:11] <mru> if the gender is important [16:46:23] <vipw> it's a nice simple language [16:46:34] <mru> it has its share of traps [16:46:57] <mru> like an insane number of vowel sounds [16:46:59] <vipw> now i'm learning polish, every possible thing you can do wrong when making a language has been done in polish [16:47:05] <mru> and a penchant for long strings of consonants [16:47:30] <mru> as in e.g. vÃ€rldssprÃ¥k [16:48:05] <vipw> do foreigners have trouble pronouncing that? [16:48:09] <mru> oh yes [16:48:49] <vipw> it doesn't seem difficult, but i'm not normal [16:51:18] <mru> thresh: http://www.theregister.co.uk/2011/02/14/russia_poll/ [16:52:27] <vipw> it's just more logical: http://dd.dynamicdiagrams.com/wp-content/uploads/2011/01/orrery_2006.swf [16:52:58] <BBB> hm, vc1 decoding spends 10% of its time in memcpy() (probably lavfilter), another 15% in av_md5_update() (should've used null as output, not md5), but another 10% in vc1_inv_trans_8x8_c() - guess what I'm going to optimize some time later [16:53:13] <BBB> new hobby: optimize unused decoders :-p [16:53:57] <divVerent> mru: Weltsprache? [16:54:00] <divVerent> not that problematic :P [16:58:08] <lu_zero> bilboed: you'll be at the EuroPython? [16:58:15] <bilboed> nope :( [16:58:19] <lu_zero> ouch =| [16:59:06] <bilboed> why ? :) [16:59:45] <lu_zero> I'll be there [16:59:52] <divVerent> mru: I somewhat doubt that study [17:00:07] <divVerent> 29% claimed something about a man vs dinosaur war... ROTFL [17:00:12] <lu_zero> and I was planning to gather more beer-interested friend and bring them to a local brewery [17:00:19] <bilboed> lu_zero, :D [17:00:23] <divVerent> either that was a suggestion on the multiple choice test... then many just didn't care and put the cross SOMEWHERE [17:00:29] <divVerent> or, some movie has pictured that recently [17:00:34] <divVerent> I am not aware of such a movie, though [17:01:05] <divVerent> Jurassic Park was a) too long ago, b) didn't really pose that scenario either [17:01:22] <Kovensky> people have that image even without the movies [17:01:32] <divVerent> no, really? [17:01:36] <divVerent> first time I heared of that story [17:01:39] <Kovensky> it's just that they don't grasp that we only started existing a long time after dinosaurs stopped [17:01:55] <Kovensky> children often have that image, if they grow uncorrected... [17:03:09] <lu_zero> brb [17:03:15] * lu_zero heads to home hopefull [17:03:55] <divVerent> Kovensky: actually, I am not THAT sure about any PROOF how that really happened... there is one funny aspect... [17:04:10] <divVerent> people imagined and have drawn dragons that look remarkably like today's picture of dinosaurs [17:04:19] <divVerent> way before we knew anything about dinosaurs [17:04:31] <divVerent> however, this isn't exactly proof of any story, and there are no OTHER indications to this [17:04:33] <divVerent> just funny [17:04:39] * Kovensky spews fire on divVerent [17:04:56] <Kovensky> in brazil "dragÃ£o" is apparently also slang for ugly women [17:05:04] <divVerent> of course... it maybe just shows that our image of dinosaurs may be rather created as "let's make dragon skin around this skeleton we found" [17:06:08] <divVerent> I mean... I'm pretty sure dinosaurs "as we know them" and humans can't have existed at the same time, no matter what [17:06:14] <divVerent> but what are the dragons based on then? [17:06:35] <divVerent> maybe simply a somewhat harmless animal that has died out independently, and looked a bit similar to the stereotypical dragon [17:06:40] <divVerent> that never spewed fire though :P [17:07:12] <Kovensky> probably some alchemist got drunk enough and wrote down about it and people liked [17:07:27] <mru> dragons are really just an amalgamation of various scary creatures [17:07:32] <divVerent> hehe, I just can't imagine how a stupid idea from a single person could spread like that [17:07:35] <divVerent> I mean... [17:07:39] <mru> and then fire added for extra emphasis [17:07:40] <divVerent> we didn't have the internet back then :P [17:08:03] <mru> there was also no peer review back then [17:08:33] <divVerent> but the other half is... we must see quite critical the "dinosaur findings", as there are many things we don't know [17:08:41] <divVerent> especially, all those pictures of "dinosaurs with skin" [17:08:44] <divVerent> (not just skeleton) [17:08:56] <divVerent> at that time, no humans were there, and especially none with a photographic camera :P [17:09:40] <divVerent> use magnet to acquire time machine (or simply use the flashlight-magnet based time machine), travel to the past, shoot photo of real T-Rex, travel back, sell photo on ebay [17:09:44] <mru> drawings of dinosaurs with skin are of course just guesses [17:10:21] <divVerent> of course... but I am a bit wary that people consider these drawings real [17:10:36] <Kovensky> also, in japan, OurDragonsAreDifferent: http://danbooru.donmai.us/post/show/836176 [17:10:43] <mru> it's reasonable to assume the dinosaurs had the same basic physiology as modern animals [17:13:06] <divVerent> mru: on this assumption, which is reasonable, the combining of the bones is based [17:13:11] <divVerent> don't doubt THAT part much [17:13:16] <divVerent> but how the skin looks... no idea :P [17:13:38] <mru> colour and texture are of course pure guesses [17:13:39] <divVerent> Kovensky: now base a "dinosaur photo" on that ;) [17:20:57] <CIA-38> ffmpeg: Tilman Brock <tilman.brock(a)tu-clausthal.de> master * rb08f59dca4 ffmpeg/doc/faq.texi: [17:20:58] <CIA-38> ffmpeg: Fix spelling error. [17:20:58] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [17:31:58] <thresh> mru: yeah, I know that people around me are stupid [18:13:26] <av500> goog says nope to GPL for aacenc [18:14:30] <mru> who did you ask? [18:14:36] <mru> and how final was the answer? [18:14:37] <pJok> computer says no [18:15:47] <av500> mru: biff [18:17:25] <elenril> solution: kicks saintdev until he fixes ffaacenc [18:21:55] <kierank> solution: use quicktime aac enc [18:22:52] <bilboed> steal Watson and make it code it in less time it takes to answer a jeopardy question [18:48:18] <spaam> kierank: can you use it on linux? [18:51:57] <kierank> spaam: through wine yes [20:00:58] <microchip_> kierank: neroaacenc ;) [20:01:04] <microchip_> ftw! [20:01:16] <mru> works, but code ain't pretty [20:01:28] <microchip_> who cares? [20:01:36] <mru> whoever has to edit the code [20:01:44] <microchip_> their problem [20:04:35] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r70c275f8c3 ffmpeg/libavfilter/avfilter.c: Make avfilter_config_links() propagate audio information of the source link if it is not explicitely set by the filter. [20:15:40] <lu_zero> neroaacenc source is available? [20:16:24] <mru> in their offices, and those of their subsidiaries/spinoffs [20:17:21] * av500 saw mru hide a floppy disk up his sleeve there... [20:43:38] <BBB> Dark_Shikari: ping [20:44:00] <BBB> Dark_Shikari: please look at http://pastebin.com/seYQ7ih6, I'm trying to transpose the idct while reading it, and it breaks make fate-vc1, any idea what I forgot? [20:55:38] <ubitux> why is there a special -x parameter added to strip on darwin? (configure) [20:55:57] <mru> because steve said so [20:56:09] <ubitux> it seems to be the same option here on linux [20:56:12] <av500> was it added for macOS "X"? [20:56:18] <ubitux> isn't steve dead? [20:56:24] <ubitux> haha [20:56:39] <av500> the liver lives on [21:02:25] <Kovensky> -x Remove all local symbols (saving only global symbols). [21:02:46] <Kovensky> and from osx's ld manpage: [21:03:07] <Kovensky> -x Do not put non-global symbols in the output file's symbol table. Non-global symbols are useful when debugging and getting symbol names in back traces, but are not used at runtime. If -x is used with -r non-global symbol names are not removed, but instead replaced with a unique, duumy [21:03:12] <Kovensky> name that will be automatically removed when linked into a final linked image. This allows dead code stripping, which uses symbols to break up code and data, to work properly and provides the security of having source symbol names removed. [21:03:43] <Kovensky> (strip's manpage says -x means the same as ld's -x) [21:07:31] <ubitux> well, maybe i miss something but... what is the difference since -r is not used? [21:39:18] <Kovensky> elenril: sure are spoilers in that op (you ran from rizon so I have to poke you here :P) [21:41:08] <Kovensky> in b4 he didn't run away and it's actually freenode's timeout being REALLY long as usual :S [21:46:45] <Dark_Shikari> BBB: 404 [21:47:54] <BBB> Dark_Shikari: http://pastebin.com/FLSdP0Zc [21:49:10] <BBB> ac reading is all screwed up, not sure what I did wrong, still looking at it [21:49:25] <Dark_Shikari> watch out that iirc the vc-1 transforms require 32-bit intermediates at some point [21:49:28] <Dark_Shikari> because micorsoft is dumb [21:49:41] <BBB> I'll watch out once I write it [21:49:46] <BBB> I'm just trying to do something simple [21:50:00] <Dark_Shikari> why v->zz_8x8? [21:50:04] <Dark_Shikari> do you need another indirection [21:50:05] <Dark_Shikari> ? [21:50:17] <mru> Dark_Shikari: nope [21:50:25] <mru> vc1 transform fits in 16 bits [21:50:27] <mru> just [21:50:35] <BBB> Dark_Shikari: simply transpose of the original scantables [21:50:35] <Dark_Shikari> I thought there was an extremal case where it failed to? [21:50:45] <BBB> Dark_Shikari: I may hardcode it later, but am too lazy now [21:50:46] <Dark_Shikari> BBB: why not transpose the scantables themselves? [21:50:47] <Dark_Shikari> ok [21:50:57] <BBB> Dark_Shikari: first make it work, then make it pretty :) [21:51:13] <Dark_Shikari> patch looks correct, I would guess you're missing some other hunk [21:51:18] <Dark_Shikari> since I'm not reading vc1dec.c [21:51:40] <BBB> hm, I'll bt on the abort to see where it fails [22:17:40] * twnqx wonders if ffmpeg can convert animated gifs to movies [22:18:40] <twnqx> no, only 1 frame. lame. [22:19:08] <spaam> twnqx: fix it [22:30:44] * BBB found bug - one of those "oh shit duh" momentss [22:31:25] <spaam> haha [22:46:44] <mru> av500: wtf? [22:48:08] <_av500_> its sony related [22:48:15] <_av500_> not ridiculing you but them [22:48:28] <mru> ah, that key [22:49:24] <spaam> mru: lÃ¥ngsÃ¶kt? :P [23:24:08] <mru> hmm, all the bus errors mysteriously vanished [23:25:37] <Sean_McG> when in doubt, reboot? ;) [23:25:58] <mru> didn't [23:26:11] <mru> new code rev probably shuffled alignment enough [23:26:26] <mru> I'm pretty sure it'll come back [23:26:49] <mru> the dv errors I have narrowed down [23:26:54] <mru> loop unrolling gone wrong [23:27:22] <mru> you know, if you unroll a loop twice, you need up increment your pointers by twice as much too... [23:27:29] <mru> s/up/to/ [23:27:31] <Sean_McG> heheh [23:27:52] <mru> not write the odd iterations on top of the even ones [23:28:08] <mru> not the first time that compiler messes up in that way [23:28:17] <mru> it's funny with compilers [23:28:30] <mru> each one has its own typical miscompilations [23:39:04] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r24a83bd10a ffmpeg/libavformat/ (avformat.h utils.c version.h): [23:39:05] <CIA-38> ffmpeg: lavf: add AV_DISPOSITION_CLEAN_EFFECTS flag [23:39:05] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:39:17] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r935ee1b9bb ffmpeg/doc/APIchanges: [23:39:17] <CIA-38> ffmpeg: apichanges: update for 24a83bd: add AV_DISPOSITION_CLEAN_EFFECTS flag [23:39:17] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:39:18] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r3f2d3a1904 ffmpeg/libavformat/mpegtsenc.c: [23:39:18] <CIA-38> ffmpeg: mpegtsenc: set audio_type according to st->disposition [23:39:18] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:39:21] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r60e7306643 ffmpeg/libavformat/mpegts.c: [23:39:21] <CIA-38> ffmpeg: mpegts: set st->disposition according to ISO 639 language descriptor [23:39:21] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:39:25] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r2dd1ee4bfe ffmpeg/libavformat/mpegtsenc.c: [23:39:25] <CIA-38> ffmpeg: mpegtsenc: whitespace cosmetics [23:39:25] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:43:54] <Sean_McG> wow...even the ppc vp8 stuff is succeeding [23:44:18] <Sean_McG> and that's been broken for almost a month now [23:45:41] <mru> nope, still broken [23:45:51] <Sean_McG> wierd, it's working on Rosetta here [23:47:02] <mru> it depends on compiler [23:47:06] <mru> and never trust an emulator [23:49:45] <Sean_McG> *sigh* looks like the DVD drive in my MacBook Pro is starting to go... very picky about what discs it'll read now [23:51:30] <mru> get a real computer [23:51:38] <mru> my laptop doesn't even have a dvd drive [23:51:58] <Sean_McG> I'm not into that whole cloud computer thing [23:52:05] <mru> me neither [23:52:22] <mru> but the twice a year I need to read a dvd in the laptop, I can connect an external one [23:53:14] <Sean_McG> I'll probably just pick up an external one soon, hoping this machine will last another year (or at least until Apple gets Sandy Bridge) [23:54:37] <lu_zero> Sandy Broken Bridge? [23:54:43] <lu_zero> o Sandy Burning Bridge? [23:54:49] <Sean_McG> the CPUs are fine! :P~ [23:55:02] <Sean_McG> just because the damn SATA300 eats data for lunch, heh

1 0

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

14 Feb '11

[00:06:29] <lu_zero> uh [00:06:31] <lu_zero> interesting [00:06:43] <lu_zero> I got a sample file for mpegts [00:06:48] <lu_zero> vlc plays it right [00:06:53] <lu_zero> ffplay/ffmpeg puke on it [00:07:47] <mru> you know what to do [00:08:07] <kierank> lu_zero: is it h264? [00:11:35] <lu_zero> kierank: mpeg4 [00:11:37] <lu_zero> and yes [00:11:40] <lu_zero> I know what to do [00:11:49] <lu_zero> comment out something in libavformat/utils.c [00:11:59] <kierank> might be one of those ones where the pps is in the next frame [00:15:42] <lu_zero> eh eh... [00:15:45] <lu_zero> obviously... [00:37:30] <spaam> mru: hard to commit a !git-formated-patch ? [00:37:39] <mru> lazy [00:37:55] <mru> properly formatted takes one keystroke [00:39:10] <twnqx> are there known issues with framerate detection for MJPG in avi? [00:39:33] <twnqx> i kinda have the feeling it plays too fast [00:40:08] <twnqx> on the other hand... Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 30 tbr, 30 tbn, 30 tbc [00:43:22] <twnqx> hm, fps = "auto" [00:43:26] <twnqx> (in the cam) [01:26:38] <CIA-38> ffmpeg: Takashi Mochizuki <mochi(a)da2.so-net.ne.jp> master * r44b1120724 ffmpeg/libavformat/movenc.c: [01:26:38] <CIA-38> ffmpeg: movenc: Force first sample as SYNC [01:26:38] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:37:59] <mru> BBB: ping [01:38:07] <BBB> pong [01:38:13] <mru> that swscale patch [01:38:20] <BBB> I just said ok [01:38:23] <mru> I know [01:38:29] <BBB> what's wrong with it? [01:38:32] <BBB> it looked ok to me [01:38:33] <mru> I don't know [01:38:38] <BBB> ? [01:38:49] <BBB> fate broke? [01:38:55] <mru> I expected someone to object against using another register or whatever [01:39:04] <BBB> it only uses 4 or 5 [01:39:10] <BBB> x86 always has 6 [01:39:27] <mru> I didn't say I expected the objection to be rational [01:39:29] <BBB> we don't care about pow(broken,3) systems that sometimes have 5 or 4 for particular compilers [01:39:29] <BBB> :) [01:39:38] <BBB> mru: I think the trolls are gone for now [01:39:53] <mru> I also don't trust myself with x86 asm [01:41:28] <mru> I don't suppose the extra instruction needed to load the address into a register is anything to worry about [01:43:40] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rf344903ca5 ffmpeg/libswscale/swscale_template.c: [01:43:40] <CIA-38> ffmpeg: Fix MMX rgb24 to yuv conversion with gcc 4.6 [01:43:40] <CIA-38> ffmpeg: When built with gcc 4.6, the MMX rgb24 to yuv conversion gives [01:43:40] <CIA-38> ffmpeg: wrong output. The compiler produces this warning: [01:43:40] <CIA-38> ffmpeg: libswscale/swscale_template.c:1885:5: warning: use of memory input without lvalue in asm operand 4 is deprecated [01:43:41] <CIA-38> ffmpeg: Changing the memory operand to a register makes it work. [01:43:42] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:43:59] <mru> now we wait [01:47:47] <spaam> mru: you say that libavformat is a messs. why dont you fix it then? [01:48:01] <spaam> or are you to lazy for that also? :P [01:49:39] <BBB> mru: well, it's the same thing actually [01:50:01] <BBB> mru: as in, both take a register [01:50:26] <BBB> you change a mov %4 with "m"(*memory) to a mov(%4) with "r"(memory) [01:50:48] <BBB> mru: in the end, the memory is loaded as a memory argument, which it loads from a register, and thus it takes a register anyway [01:50:53] <bcoudu> BBB and mru, can we please stop this nonsensical discussion [01:50:54] <BBB> mru: so the code is actually identical [01:50:58] <bcoudu> about timestamps [01:51:04] <BBB> bcoudu: ok [01:51:06] <bcoudu> BBB you have no clue as to why dts are needed [01:51:11] <mru> wouldn't the "m" turn into an immediate address? [01:51:27] <bcoudu> and why TS has them since 20 years [01:51:42] <ohsix> i know i have no clue, where can i familiarize myself [01:51:44] <mru> dts are needed in buffer-constrained synchronous systems [01:51:45] <bcoudu> more than this actually [01:51:46] <BBB> mru: (%4) with "r" is an immediate address as much as %4 is with "m" [01:51:47] <mru> not on a pc [01:51:49] <BBB> mru: both are [01:51:58] <mru> no [01:52:07] <mru> (reg) is a register indirect address [01:52:29] <mru> immediate means the absolute address is part of the opcode [01:52:37] <BBB> oh like that [01:52:55] <BBB> I don't think gcc would compile it as such [01:53:09] <mru> I admit I didn't check [01:53:11] <BBB> it's not something like ff_pw, which is actually a memory location [01:53:19] <mru> it is a memory location [01:53:23] <BBB> it's more like &ff_pw[x==1?5:7] [01:53:31] <mru> the index is constant [01:53:45] <BBB> the few times when I looked at this, gcc would put it in a register [01:53:49] <BBB> which is kinda stupid, admittedly [01:53:49] <mru> ok [01:54:00] <BBB> might be apple's gcc version being dumb [01:54:33] <BBB> "m"(ff_bgr24toUV[srcFormat == PIX_FMT_RGB24][0]) <- that's the one you change, right? [01:54:39] <mru> yes [01:54:41] <BBB> there is a conditional in it [01:54:47] <BBB> so I'm quite sure gcc would put it in a register [01:54:48] <mru> srcFormat is constant [01:54:54] <BBB> ah, I didn't know [01:55:07] <mru> it's inlined into two places with a different constant [01:55:15] <BBB> got it [01:55:49] <BBB> I guess if you want to make sure gcc does the right thing, you should MANGLE(absolute_address) it [01:56:01] <BBB> but as you remember from a few months ago, that'd fail on gcc 3.x [01:56:10] <BBB> (with the loopstrengthfilter inline asm code) [01:56:26] <mru> and that doesn't work with the conditional, even though compile-time constant [01:56:36] <BBB> exactly [01:58:08] <BBB> but as I said, I think even gcc4.x puts it in a register anyway [01:58:15] <BBB> not because it's necessary, but just because that's what gcc does [01:58:25] <mru> got it [01:58:28] <BBB> if you want to be absolutely sure it doesn't do that, you unfortunately have to rewrite it in asm [01:58:40] <BBB> (external asm, i.e. yasm) [01:59:48] <BBB> bcoudu: I'll cut the discussion... I would like to have a more constructive discussion at some point on all the timestamp hacks in lav[fc]/{cmdutils,ffmpeg,ffplay}.c, because it's a mess, and if michael got hit by a bus, we'd be in a deep pile of shit because nobody understands any of that code [02:00:31] <ohsix> time os for jerks [02:00:43] <ohsix> is. not os; that would be dirty [02:02:48] <BBB> mru: "[PATCH] faster SSE FFT" is ok also, can you push? [02:03:10] <BBB> didn't dondiego have push rights also? [02:03:17] <BBB> he hasn't committed anything yet [02:13:58] <ohsix> mru: how do you feel about enums with switches & all labels [02:14:22] <ohsix> and default [02:14:28] <mru> ridiculous [02:14:31] <bcoudu> it's hard to have a constructive discussion about this [02:14:54] <lu_zero> ^^? [02:14:57] <mru> it's just noise [02:15:00] <mru> best case [02:15:00] <lu_zero> bcoudu: what do you mean? [02:15:10] <mru> worst case it turns into actual dead code [02:15:13] <ohsix> i like em, if you add something to the enum you can get the compiler to complain where it's likely used [02:19:47] <bcoudu> I can't see how a constructive discussion can happen given the current situation [02:22:01] <lu_zero> why? [02:23:18] <ohsix> people litigating over stuff they partially understand? [02:23:53] <BBB> bcoudu: I'll shut up if that helps - but eventually at some point a constructive discussion would be needed [02:24:25] <ohsix> from not knowing anything about pts/dts/whatever, mans has a good point about messing with information you might need to filter to make useful [02:24:46] <BBB> mru: I was thinking, perhaps one way of making this work is by using four memory arguments, %4 being table[0/1][0], %5 being table[0/1][4], and so on for %6/%7 [02:25:05] <BBB> mru: I'd have to look at the disassembly to see whether gcc-4.x and 3.x actually do the right thing, but they might [02:30:42] <BBB> [0/1][0/1/2/3], actually, I didn't realize they're uint64_t already [02:32:11] <uau> ff_bgr24toUV[srcFormat == PIX_FMT_RGB24][0] looks like it should be an lvalue [02:38:33] <mru> it does [02:39:05] <mru> BBB: I wouldn't bother with that function [02:43:38] <BBB> I'll just give it a quick try [02:46:15] <BBB> hm, it actually works [02:46:19] <BBB> mru: see new patch on IRC [02:46:25] <BBB> "MASSIVE PERFORMANCE IMPROVEMENT" [02:46:32] <BBB> (or so... ... ...) [02:46:47] <peloverde> Even on a mov to mov stream copy where we have frame_size set correctly, we still wind up with a broken stsz box because frame_size > pkt->size [02:55:33] <peloverde> bcoudu: I'm sorry I called you names, can you please elaborate on how this is supposed to work? [02:56:56] <ohsix> you called him names?! [02:58:09] <Compn> BBB : btw , rejecting a patch because you want the rest of ffmpeg fixed first sounds like a dumb argument [02:58:41] <Compn> maybe i'm misunderstanding the situation of course ;) [02:58:42] <mru> from what I can tell, the patch doesn't improve anything [02:58:51] <Compn> does it fix some sample s? [02:59:00] <mru> none that anyone cared to mention [02:59:12] * Compn will ask on list for samples it fixes then [02:59:21] <mru> what it does is embed the hacks in the external api [02:59:23] <mru> and that is a bad [03:05:12] <peloverde> encoding adpcm_ms to mov is also broken? [03:05:23] <peloverde> what was that patch tested with? [03:09:59] <Compn> hmm, whos the master at reverse engineering game codecs? [04:15:03] <peloverde> ugh, I've wasted the entire day and ms adpcm in mov is still broken [04:15:17] <mru> does anyone even use that? [04:16:46] <peloverde> i don't know, but it is a crasher [04:17:22] <ohsix> add an error message that tells them to stuff it [04:18:12] <peloverde> that's dumb, let's just fix the bug(s) [04:18:21] <mru> compress it with stuffit instead? [04:28:27] <peloverde> interesting, i have it working with one block per packet [05:28:50] <Sean_McG> heh, does anyone actually use stuffit anymore? [05:31:18] * saintdev expands Sean_McG [05:32:50] <Sean_McG> I mean, hell, I have a Mac and even I don't [05:42:24] <astrange> the built in zip replaced stuffit on OS X a few years ago [05:42:35] <Sean_McG> basically [05:42:46] <Sean_McG> I used to use stuffit when I had my G4 [07:33:53] <cryptw> what's the abuild command [07:34:01] <cryptw> to just do the final step in actually [07:34:07] <cryptw> creating/signing the package? [09:33:19] <elenril> KotH: do you mind a 700mb sample in incoming? [10:55:37] <lu_zero> what happened to the yadif filter? [12:09:37] <lu_zero> yawn [12:15:37] <kierank> i wonder why nobody trolled the webm list about patents [12:30:15] <mru> morning [12:33:30] <jannau> kierank: nobody cares enough about webm [12:33:34] <jannau> morning [13:25:16] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * rcb62510cab ffmpeg/libavcodec/bink.c: [13:25:16] <CIA-38> ffmpeg: bink: simplify how quantization matrices are passed to read_dct_coeffs() [13:25:16] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:29:48] <spaam> omg a normal mail from arpi :D [13:29:58] <mru> and it's not insulting [13:30:03] <mru> that's the real surprise [13:30:24] <mru> he's wrong of course, but that's a different matter [13:33:06] <mru> _av500_: http://www.engadget.com/2011/02/12/eighth-circuit-declares-razr-a-computer-… [13:48:29] <divVerent> as this is a big topic on the mailing list (again, I suppose)... is there any documentation HOW an application calling ffmpeg should fill out dts? [13:48:55] <divVerent> currently, I simply choose to not fill it out and have libavformat calculate dts from pts, pts coming from coded_frame->pts from libavcodec [13:49:48] <divVerent> from Dark_Shikari I at another time I got the info (I probably misunderstood it) to just use "pts minus encoding delay", but this makes no sense [13:49:58] <divVerent> as if ordered by dts, pts are not monotonous, and vice versa [13:50:22] <mru> for software decoding on a pc-like system dts is irrelevant [13:50:31] <divVerent> sure [13:50:38] <divVerent> but what is "proper" use of libavcodec/libavformat? [13:50:49] <mru> depends on what you're doing [13:50:55] <divVerent> "I want to encode video" [13:51:21] <divVerent> seriously... assume this: [13:51:32] <divVerent> my input is "I want to show this video frame at this time" [13:51:40] <divVerent> I even know display duration, I think, not 100% sure about it [13:51:50] <mru> when _encoding_ you should give the encoder pts of each input frame and the encoder should then assign correct dts to encoded output frames [13:51:55] <divVerent> I want to use the encoder "transparently" [13:51:56] <mru> in an ideal world [13:52:00] <mru> that's how x264 works [13:52:17] <divVerent> so I don't want to know implementation details like how many b-frames the encoder happens to be using right now [13:52:38] <divVerent> my current code just sets pts, and ignores dts [13:52:50] <divVerent> which triggers libavutil's dts-from-pts-by-sorting-and-some-magic code [13:53:16] <divVerent> which fails for the first frames of a video if the time base is <1ms (VFR) [13:53:20] <twnqx> i think mplayer gets wrong data from my vfr .avi [13:53:25] <divVerent> so as workaround, my application sets a duration of 1 for the very first frame [13:53:32] <divVerent> to make the libavformat code not fail [13:53:34] <twnqx> via libavcodec/libavformat [13:53:46] <divVerent> but - this can't be the right way to use the API [13:54:06] <mru> twnqx: avi doesn't support vfr [13:54:24] <twnqx> but the player for this cam gets the speed right [13:54:29] <mru> divVerent: I'm afraid there is no sane way to use lavf with timestamps [13:54:44] <divVerent> mru: I mean... what is the -correct- way? [13:54:48] <divVerent> let's ignore "sane" for now :P [13:55:08] <divVerent> one possibly correct way would be easy if I had the dts for the video strea [13:55:15] <divVerent> but libavcodec does not provide it, so that possibility is out [13:55:28] <mru> divVerent: same answer [13:55:36] <divVerent> Dark_Shikari's suggestion "pts minus encoding delay" actually may be ambigous [13:55:42] <mru> libavcodec is broken [13:55:50] <divVerent> is it "pts of coded_frame minus enoding delay" [13:56:01] <divVerent> or "pts of frame I passed to avcodec_encode_video minus encoding delay" [13:56:03] <mru> it's not that simple [13:56:07] <divVerent> subtly different, but the latter may even be correct [13:56:15] <divVerent> the former is obviously wrong [13:56:21] <divVerent> the latter is "maybe correct, but insane if it is" [13:57:03] <mru> dts increases with one frame period per coded frame [13:57:04] <divVerent> mru: are there any plans on fixing libavcodec for VFR? [13:57:17] <divVerent> yes, but I am encoding VFR :P [13:57:24] <BBB> I like mru's last suggestion to remove all pts/dts adjustment code and fix it back from scratch [13:57:27] <divVerent> I suppose, libavformat's reordering logic is even MOSTLY correct [13:57:37] <divVerent> BBB: and how would that go? [13:57:50] <mru> that's not a correct assumption [13:58:00] <BBB> you select the code in a editor, then you hit "delete" [13:58:02] <mru> the timestamp logic in lavf is 10 years of hacks [13:58:08] <divVerent> BBB: I mean, from application view [13:58:12] <divVerent> how would the final API look [13:58:19] <BBB> divVerent: api looks same as now [13:58:19] <mru> more or less the same [13:58:27] <mru> but it would do the right thing [13:58:28] <BBB> except that it works and needs no hacks app-side [13:58:29] <divVerent> personally, I'd prefer "coded_frame provided by libavcodec contains dts, application copies it to AVPacket" [13:58:36] <mru> instead of randomly guessing [13:58:37] <divVerent> BBB: cannot be the same :P [13:58:45] <divVerent> BBB: because currently libavcodec provides no dts [13:58:50] <mru> that should be fixed [13:58:53] <divVerent> and I suppose, providing the dts from there is the only sane solution [13:59:00] <divVerent> libx264 provides it, IIRC [13:59:02] <mru> yes [13:59:07] <mru> x264 works very well [13:59:35] <divVerent> another issue is the duration :P [13:59:58] <divVerent> AVPacket contains "packet duration", whatever that is [14:00:28] <divVerent> but FF_COMMON_FRAME does not [14:00:35] <divVerent> so, if I treat libavcodec as blackbox, which I have to [14:00:45] <divVerent> then I do not know which input frame coded_frame actually contains [14:00:50] <divVerent> so how am I supposed to know its duration? [14:01:19] <divVerent> of course, I could have my own array of pts<->duration assignment, and search for coded_frame's pts in that array, and get the duration from there [14:01:22] <divVerent> but that would be insanity [14:02:19] <mru> I'd just use x264 for encoding [14:02:23] <mru> much simpler [14:02:30] <divVerent> I want to support other codecs too [14:02:34] <divVerent> not be fixated on a single one [14:02:41] <divVerent> especially given that there may be multiple upcoming codecs [14:02:48] <divVerent> this is what an abstraction layer like libavcodec is for, anyway [14:02:49] <mru> add support for them to x264 :) [14:02:52] <divVerent> haha [14:03:14] <divVerent> to actually "nicely" solve this from the app: assume I use the "opaque" field in AVFrame passed to avcodec_encode_video [14:03:24] <divVerent> will the coded_frame later contain that field too? [14:03:29] <mru> probably not [14:03:31] <divVerent> i.e. is coded_frame a copy of the one I passed, with the data encoded [14:03:37] <divVerent> or is it a "new" one made by the encoder? [14:03:41] <mru> the encoding api sucks [14:04:31] <divVerent> then it needs fixing :P [14:04:46] <divVerent> IMHO it needs two things urgently: [14:04:53] <divVerent> - dts passing from codec to format [14:05:04] <divVerent> - "arbitrary option string" processing for codec libraries [14:05:23] <divVerent> so e.g. libx264 could provide ALL x264 options as an option namespace, e.g. libx264_ref [14:05:33] <divVerent> (so if x264 adds its own new option, lavc won't need any change for it) [14:06:00] <mru> nobody is disagreeing [14:06:06] <divVerent> would also allow a codec to e.g. support stuff like --preset in x264 [14:06:21] <divVerent> if these two are solved, I'd actually consider it sane [14:06:34] <divVerent> as these seem to be the only design flaws there [14:07:57] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r2315392174 ffmpeg/libavcodec/bink.c: [14:07:57] <CIA-38> ffmpeg: bink: permute Bink version 'b' quant matrices by inverse scan order [14:07:57] <CIA-38> ffmpeg: This fixes visual glitches in Bink version 'b' files, as the quantization [14:07:57] <CIA-38> ffmpeg: tables were not being permuted. [14:07:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:26:58] <BBB> peloverde: ping [14:27:05] <BBB> peloverde: is the LTP patch fine to apply now? [14:29:48] <kshishkov> BBB: not until he says so on ML [14:29:58] <BBB> I think he did already [14:57:02] <BBB> astrange: should I start pushing h264 etc. patches? [14:58:05] <jannau> wtf apple! Apple Mail (2.1082) doesn't set references and in-reply-to headers [14:58:22] <BBB> mru: did you test that my alternative swscale patch fixes gcc-4.6 compile? [14:58:31] <BBB> mru: the patch is better and should probabyl be used instead [14:58:57] <mru> why is it better? [14:59:10] <BBB> saves 1 instruction with some gcc versions [14:59:49] <mru> how does it behave with PIC and such nasties? [14:59:56] <BBB> works [14:59:59] <BBB> I tested that yesterday [15:00:06] <mru> I wouldn't be surprised if some gcc version allocated 4 registers [15:00:12] <BBB> I was hoping you could test with gcc-4.6 and 3.x and make sure it works [15:00:36] <BBB> if it works with 3.x, I trust it (just see if it compiles) [15:23:15] <Sean_McG> do you folks have requirements for the earliest version of gcc it should be compiled with? are they enforced? [15:23:48] <mru> depends a bit on the target [15:25:16] <spaam> kshishkov: you can write that bink encoder ;) [15:29:00] <kshishkov> spaam: why? [15:29:23] <Kovensky> Sean_McG: propbably x.y.1+, with the biggest possible x and then the biggest possible y :) [15:29:59] <Sean_McG> Kovensky: would be nice [15:30:00] <mru> x and y should have odd parity [15:30:27] <spaam> kshishkov: bink is great. [15:30:31] <spaam> ;) [15:30:34] <Sean_McG> I think D_S told me he uses 3.4.5 ;) [15:30:55] <mru> 3.4 does a decent job on x86 [15:31:06] <kshishkov> spaam: so push it for next generation patent-free codec. It has patents on encoder though IIRC [15:31:10] <mru> on other targets anything older than 4.3 is likely useless [15:33:33] <Sean_McG> anyways, I'mma go fix myself up and head out for late breakfast [15:34:11] <Kovensky> < Sean_McG> I think D_S told me he uses 3.4.5 ;) <-- which is cygwin's default [15:34:33] <kshishkov> Kovensky: and D_S is using Windows. Coincidence? [15:34:42] * mru submits a gcc bug report [15:34:56] <Kovensky> <@mru> on other targets anything older than 4.3 is likely useless <-- gcc propably did well on m68k before 4.3 too :) [15:35:22] <kshishkov> Kovensky: ask hyc when he's around, he claimed to work on that backend long ago [15:35:34] <Sean_McG> I dunno about that... I think vendor compilers were so compelling when compared to gcc that no one cared if it wasn't x86 [15:35:55] <Kovensky> IIRC gcc was written for m68k, then ported to everything else [15:36:14] <Sean_McG> really? what was the first target... Sun boxen? [15:36:24] <mru> it was started in the 80s [15:36:29] <mru> PCs barely existed [15:36:45] <mru> when did the 386 come out? [15:36:50] <kshishkov> later [15:36:56] <Sean_McG> early 90's methinks [15:37:15] <kshishkov> 1985 [15:37:17] <Kovensky> the GNU OS targeted m68k [15:37:23] <Sean_McG> oh, wow [15:37:28] <Kovensky> but it didn't get the opportunity because GNU Turd is still not ready [15:37:31] <kshishkov> Kovensky: Hurd? [15:37:42] <kshishkov> Kovensky: it's Hurd NG now! [15:37:48] <Sean_McG> hahahah Turd [15:37:54] <mru> I remember 486 was commonplace in 93 [15:38:08] * Kovensky had one from 1994 to 1997 [15:38:28] <Sean_McG> yeah I was in highschool back then and we'd just got a whole fleet of new 486's in 95 [15:38:49] <mru> and everybody was excited about the glorious pentium about to be launched [15:38:58] * Kovensky started elementary in 1996 [15:39:09] <Sean_McG> yeah, I'm old :( [15:39:25] <Kovensky> actually, at the time, elementary started in 1997 [15:39:25] <mru> in 96 most of the school machines were 486, with a few pentiums around [15:39:45] <Compn> all our schools were mac , the whole way [15:39:52] <Sean_McG> we had both [15:39:55] <Sean_McG> Macs and PCs [15:39:55] <kshishkov> Compn: you're US guy [15:40:06] <Kovensky> but ~3 years ago the government decided to retroactively make the last year of kindergarten the first of elem [15:40:09] <Compn> kindergarden = apple 2 [15:40:16] <kshishkov> my school still had 386+486s till 99 I think [15:40:18] <Kovensky> garden* [15:40:31] <Kovensky> my high school still used win98 when I studied there [15:40:33] <Sean_McG> and I always gravitated towards the Mac labs, but the programming courses were all Visual BASIC (although we did do a smattering of Delphi *gasp*) [15:40:59] * Kovensky used anything mac for the first time last november when he decided to do a hackintosh [15:41:18] * mru was never formally taught a programming language [15:41:35] * Kovensky was formally taught a programming language now in uni [15:41:36] <mru> apart from perhaps java in uni [15:41:38] <kshishkov> mru: so you're untainted [15:41:46] <Kovensky> they were all terribly taught though and I already knew anything useful before anyway [15:42:22] <Sean_McG> think at home I still had a C=64 back then [15:42:49] * mru never owned a C64 [15:42:51] <mru> nor amiga [15:42:59] <kshishkov> mruCDGS: too bad [15:42:59] <Sean_McG> and I kept bugging my dad to get us an Amiga [15:42:59] <mru> some friends had them [15:43:06] <mru> I never "got it" [15:43:07] <Kovensky> Sean_McG: my trauma: a version of pascal with syntax in portuguese and with several builtin functions moved to global namespace and also translated to portuguese, and a "C++" class that actually used the borland C++-Delphi chimera and claimed that everything in there was C++ itself, not C++ with Delphi's API [15:43:31] <Sean_McG> Kovensky: I just remember how incredibly picky about syntax it was [15:43:36] <kshishkov> people in .su started with ZX Spectrums, my first computer was AMD-166 [15:43:56] <Kovensky> the first time I even saw an AMD was a 750MHz Duron [15:44:21] <mru> iirc a classmate had a k5 at some point [15:45:30] <mru> kshishkov: reading your notes about countries... [15:45:37] <mru> kshishkov: did you visit vigelandparken in oslo? [15:45:52] <kshishkov> mru: nope, does it has statues? [15:45:57] <mru> you could say that [15:46:05] <mru> overdone doesn't even begin to describe it [15:46:22] * kshishkov is not surprised [15:46:50] <kshishkov> well, compare Rådhus in Oslo vs. Stadthus in Stockholm [15:47:16] <mru> http://www.google.co.uk/images?q=vigeland [15:47:28] <mru> that's all the work of one man [15:49:14] <kshishkov> just compare common look of http://sv.wikipedia.org/wiki/Stockholms_stadshus and http://no.wikipedia.org/wiki/Oslo_r%C3%A5dhus [16:08:44] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r482d98f69b ffmpeg/ (Changelog libavformat/spdifenc.c libavformat/version.h): [16:08:44] <CIA-38> ffmpeg: spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI [16:08:44] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [16:08:55] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r57f2c9aed9 ffmpeg/libavformat/spdifenc.c: (log message trimmed) [16:08:55] <CIA-38> ffmpeg: spdifenc: fix byte order on big-endian systems [16:08:55] <CIA-38> ffmpeg: There is a check for HAVE_BIGENDIAN when outputting the IEC 61937 [16:08:55] <CIA-38> ffmpeg: stream. On big-endian systems the payload data is not byteswapped, [16:08:56] <CIA-38> ffmpeg: causing in effect the outputted payload data to be in a different byte [16:08:56] <CIA-38> ffmpeg: order on big-endian than on little-endian systems. [16:08:57] <CIA-38> ffmpeg: However, the IEC 61937 preamble (and the final odd byte if present) is [16:08:57] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r3c33c0e263 ffmpeg/libavformat/utils.c: [16:08:58] <CIA-38> ffmpeg: lavf: print stream disposition in dump_stream_format [16:08:58] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [16:08:59] <CIA-38> ffmpeg: Loren Merritt <lorenm(a)u.washington.edu> master * re6b1ed693a ffmpeg/libavcodec/ (6 files in 3 dirs): [16:09:25] <CIA-38> ffmpeg: FFT: factor a shuffle out of the inner loop and merge it into fft_permute. [16:09:25] <CIA-38> ffmpeg: 6% faster SSE FFT on Conroe, 2.5% on Penryn. [16:09:25] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [16:23:07] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rbb7a22b584 ffmpeg/configure: [16:23:07] <CIA-38> ffmpeg: configure: add cleanws() function [16:23:07] <CIA-38> ffmpeg: This function removes leading and trailing spaces and collapses [16:23:07] <CIA-38> ffmpeg: multiple spaces into one. [16:23:07] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:23:09] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r5d57846bba ffmpeg/configure: [16:23:09] <CIA-38> ffmpeg: configure: report full gcc version string [16:23:09] <CIA-38> ffmpeg: This makes the cc_ident value, which is used in FATE reports, include [16:23:09] <CIA-38> ffmpeg: all interesting parts of the gcc version string. [16:23:10] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:35:16] <Kovensky> < CIA-38> ffmpeg: configure: add cleanws() function <-- I remember I + several other people in another channel did several implementations of that each in a different language [16:35:21] <Kovensky> lol [16:35:41] * Kovensky did one in C and one in Perl [16:36:21] <mru> I could do it in pure shell script, but that wouldn't be very efficient [16:39:14] <divVerent> how does cleanws() differ from "xargs echo"? [16:39:16] <divVerent> ;) [16:39:39] <mru> embedded whitespace [16:40:18] <mru> foo=' foo < bar ( $baz ' [16:40:19] <divVerent> looks like the ffmpeg git repo I use doesn't have this commit yet... [16:40:30] <divVerent> I would say you want 'foo < bar ( $baz' then? [16:40:34] <mru> yes [16:40:43] <Kovensky> http://www.cracktwo.com/2011/02/what-if-worlds-most-influential-tyrant.html [16:40:52] <divVerent> [rpolzer@grawp ~]$ echo ' foo < bar ( $baz ' | xargs echo [16:40:54] <divVerent> foo < bar ( $baz [16:41:13] <divVerent> my main objection against xargs echo is nasty platforms where echo is weird [16:41:25] <mru> precisely [16:41:32] <mru> echo is often very weird [16:41:35] <divVerent> but, simulating xargs echo is simple anyway [16:41:53] <divVerent> out=""; for x in $string; do out="$out $x"; done; out=${out# } [16:42:22] <divVerent> or, if you are allowed to mess up the positional parameters: [16:42:31] <divVerent> set -- $string; out=$* [16:42:47] <divVerent> (e.g. safe to do in a function specially made for it) [16:43:30] <divVerent> wouldn't be 100% sure about THAT latter one though, as THAT might fail on nasty platforms [16:43:38] <divVerent> (but if it works on Solaris, it works everywhere) [16:44:27] <divVerent> one shell where this sure fails, is zsh, BTW, which generally assumes that you don't want to word-split variables [16:44:44] <divVerent> in a script I made, I thus have a hack: [16:44:47] <mru> xargs echo fails if string contains quotes [16:44:53] <divVerent> if [ -n "$ZSH_VERSION" ]; then setopt SH_WORD_SPLIT; fi [16:45:29] <divVerent> http://paste.pocoo.org/show/337761/ - I currently have this portability hack... which is annoying [16:45:49] <divVerent> this echo test fails on MSYS [16:46:07] <divVerent> no idea what they did to their shell [16:47:01] <divVerent> but well, this cleanws() isn't that bad even [16:47:02] <mru> 16:40 < divVerent> looks like the ffmpeg git repo I use doesn't have this commit yet... <-- what repo do you use? [16:47:09] <divVerent> except if the first arg happens to be, e.g., -E [16:47:28] <mru> I suppose it could use printf instead [16:47:41] <divVerent> git://repo.or.cz/FFMpeg-mirror/mplayer-patches.git - managed by uau [16:47:47] <divVerent> no idea how its merging policy is, though [16:48:02] <divVerent> but I am basically forced to use this one as mplayer2's build system uses it as a submodule [16:48:22] <divVerent> as for that cleanws() function... [16:48:29] <divVerent> I suppose, with a small change it should be portable [16:48:43] <divVerent> change echo "$@" to either echo "" "$*" or printf "%s\n" "$*" [16:48:59] <divVerent> both should reliably prevent echo option parsing mess [16:49:01] <mru> yes, I know [16:49:06] <divVerent> but the backslash issue... printf should fix that [16:49:55] <uau> divVerent: the submodule part shouldn't really force that [16:49:58] <divVerent> set -- "$*"; printf "%s" "$*" is "neater" though [16:50:09] <uau> however there's no newer ffmpeg-mt version (so you'll lose mt if you use something else) [16:50:17] <mru> I'm tempted to override echo with something like that actually [16:50:19] <mru> just to be safe [16:50:37] <divVerent> printf "%s\n" "$*" should be a pretty good echo override [16:50:54] <uau> and i think nobody has yet fixed the .pc errors in main ffmpeg repo(s), so static linking against those might fail [16:50:56] <divVerent> maybe also detect the -n option of echo if you need it :P [16:50:58] <mru> yes, that should be equivalent to the posix echo [16:51:05] <mru> -n is not part of the standard [16:51:12] <divVerent> but needed very often [16:51:16] <divVerent> but sure [16:51:22] <mru> printf w/o \n does same [16:51:28] <divVerent> sure [16:51:35] <mru> I always use printf if I need anything special [16:51:36] <divVerent> personally, I'd probably name one of them echo() and the other echo_n() [16:51:42] <divVerent> always printf is ugly :P [16:51:48] <divVerent> lots of "%s" for unformatted raw strings [16:51:56] <divVerent> as printf "Hello World" is considered evil ;) [16:52:11] <divVerent> ("what happens if someone later changes the string and adds a percent sign") [16:52:36] <divVerent> but this is what shell functions are for [17:15:06] <lu_zero> uhmm [17:15:18] <lu_zero> cross compiling on mingw32 seems to not link anymore? [17:35:39] <lu_zero> uhm [17:35:47] <lu_zero> --enable-shared was needed... [17:36:05] <lu_zero> btw why aren't we using dlltool from mingw32 instead of lib.exe? [17:38:22] <spaam> ramiro maybe know? [17:40:52] <kshishkov> yes, FFmpeg needs devil's advocate^W^W Windows porting guy [18:01:03] <lu_zero> spaam: apparently we got the .lib equivalent as side effect of linking [18:01:11] * lu_zero dug a bit of mingw32 documentation [18:01:31] <lu_zero> so I'm not really understanding why those are with different extension and how they should work [18:01:50] <kshishkov> lu_zero: swscaler is more important [18:02:07] <lu_zero> kshishkov: let me bisect to see where I did wrong so far =P [18:02:07] <kshishkov> and if it's clean we may get NEON opts for it [18:02:42] <kshishkov> lu_zero: take all time you need, just don't be distracted on less important things ;) [18:03:03] <mru> neon libswscale is something I could probably find a sponsor for [18:03:11] <mru> but only once the task is palatable [18:03:22] <mru> or rather, I won't offer to do it until then [18:03:34] <mru> libjpeg is bad enough [18:03:37] <kshishkov> iKnow [18:04:07] <kshishkov> mru: at least you seemed to like those libjpeg7 ideas like scalable coding [18:26:24] <CIA-38> ffmpeg: Anatoly Nenashev <anatoly.nenashev(a)ovsoft.ru> master * r7a4abe5912 ffmpeg/libavcodec/mpeg4videodec.c: [18:26:24] <CIA-38> ffmpeg: mpeg4video: ignore broken GOP headers [18:26:24] <CIA-38> ffmpeg: Some MPEG4 cameras produce files with empty GOP headers. [18:26:24] <CIA-38> ffmpeg: This patch makes the decoder ignore such broken headers and proceed [18:26:24] <CIA-38> ffmpeg: with the following I-frame. Without this change, the following [18:26:25] <CIA-38> ffmpeg: start code is missed resulting in the entire I-frame being skipped. [18:26:26] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:28:34] <_av500_> kshishkov: nice one about the sculpting! [18:28:58] <kshishkov> _av500_: have you been to Oslo too? [18:29:17] <_av500_> nope [18:29:17] <mru> seriously, oslo isn't _that_ bad [18:29:25] <mru> a bit expensive, but not a bad place [18:29:36] <_av500_> mru: oh, so somebody is wrong on the internet? [18:29:38] <kshishkov> but it tasteless as Belgian sausages [18:29:55] <mru> and I don't find brussels all too awful either [18:30:22] <kshishkov> you live in Britain for too long [18:30:36] * kshishkov uses Stockholm for reference point [18:31:38] <kshishkov> mru: and my main point against Brussels is that it reminds me Ukraine too much [18:32:04] <kshishkov> mru: and I don't know if it's me being lucky but hotel where I stayed at was idiotic [18:32:20] <mru> which hotel were you in? [18:32:28] <kshishkov> Mercur [18:32:55] <mru> mercur are usual alright [18:33:13] <mru> at least the ones in paris and tokyo were [18:33:20] <kshishkov> well, I like to have free Internet [18:33:28] <mru> pick a cheaper hotel then [18:33:45] <kshishkov> and paying separately for breakfast was something new for me too [18:34:07] <Flameeyes> kshishkov: hey last year lu_zero had to pay for the towels :P [18:34:31] <kshishkov> Flameeyes: well, this year they provided paper towels [18:35:31] <mru> the more expensive the hotel, the more things they charge separately [18:35:38] <mru> like internet and breakfast [18:35:51] <kierank> hehe, hotel internet [18:36:21] <kshishkov> mru: does it have something to do with stars or just country? [18:36:31] <Flameeyes> yeah last year I spent less by allowing 3 to charge me for the roaming traffic than I would have to get it from the hotel [18:36:39] <mru> some even charge for shampoo [18:37:00] <kshishkov> where? [18:37:09] <mru> I saw that in some 5-star in seoul [18:37:14] <Flameeyes> (London was more friendly on that note... 3-on-3 → no roaming charges, free internet :D) [18:37:47] <kshishkov> mru: the only four-star hotel I've ever stayed at was in Sundsvall, every other were three-star [18:38:13] <kshishkov> mru: and separately paid Internet was in .no, .fi and .be [18:39:02] <pJok> the hotels i've been to in riga didn't charge extra for wifi [18:39:29] <mru> up to 3-star it's usually free [18:39:47] <mru> the more expensive ones figure if you can afford to stay there at all, you can afford to pay for _everything_ [18:39:58] <kshishkov> i.e. RyanAir model [18:40:07] <mru> not quite [18:40:08] * pJok isn't going to stay at something higher than 3 stars anyways [18:40:18] <mru> ryanair at least starts out with a low base price [18:40:21] <pJok> if you are only going to sleep there, why pay for more than you have to anyways [18:40:31] <mru> pJok: someone else might be paying [18:41:07] <pJok> mru, that might change the game.... if you can get them to pay everything including a rental car at least [18:41:21] <kshishkov> pJok: well, you may find that 4-star hotels abroad may be cheaper than 3-star in København [18:41:39] <mru> aforementioned korean 5-star wasn't very expensive [18:41:51] <mru> about £75 per night iirc [18:41:59] <mru> hotels are cheap in korea [18:42:12] <pJok> kshishkov, nothing is cheap in copenhagen... though, i've never stayed at a hotel in copenhagen [18:42:28] <kshishkov> mru: about the same for that hotel in .be [18:42:37] <pJok> mru, sounds reasonable for a 5 star hotel room [18:42:52] <pJok> considering that you probably pay that for a 3 star in copenhagen [18:42:54] <kshishkov> and I payed ~100€ for one night at 3-star hotel in Copenhagen [18:42:57] <mru> pJok: exactly [18:43:03] <mru> very central location too [18:43:28] <pJok> kshishkov, i have at least three places i can sleep in copenhagen if needed [18:43:46] <mru> the metro station, the park bench, and the police cell? [18:43:55] <pJok> something like that :D [18:44:12] <kshishkov> mru: not metro [18:44:21] <pJok> work has some nice couches, the hackerspace has some couches and friends [18:44:31] <kshishkov> they have toy metro without benches at stations [18:44:31] <pJok> in the metro you just get kicked out [18:44:46] <mru> that's when you move to the park bench [18:45:51] <kshishkov> and there's Christiania [20:16:04] <BBB> mru: it seems patchwork doesn't update a patch if I reply a counterpatch in a thread, but also doesn't create a new patch ID [20:16:17] <mru> it's a bit weird sometimes [20:17:02] <BBB> can someone review the patch in mmst 2/2 that I wrote? [20:17:08] <BBB> would be nice to apply that [20:17:13] <BBB> also the patch in swscale needs review [20:17:27] <BBB> and my patch to fix compile id 3dnow is not supported by clang [20:17:30] <BBB> s/id/if/ [20:17:44] <mru> you never updated that after I fixed the deps in configure [20:17:52] <Sean_McG> how new a version of clang do you need for 3dnow support? [20:18:05] <mru> 2.9 seems to do the trick [20:18:29] <Sean_McG> I don't have any AMDs so the question is really just out of curiosity [20:19:07] <ohsix> they have a simulator [20:22:44] <mru> there, another compiler bug tracked down [20:23:13] <mru> av_open_input_stream() of all places [20:24:53] <Sean_McG> oooh qnx... is this new mru? [20:25:01] <mru> been there a week or so [20:25:08] <Sean_McG> must've missed it [20:26:51] <BBB> mru: I tohught I did... at least locally [20:26:54] <BBB> I'll resend [20:29:39] <Sean_McG> it's nice having my gcc version detail on fate [20:29:42] <Sean_McG> s/my/more/ [20:41:57] <Kovensky> oh, you are running patchwork? [20:42:38] <Sean_McG> me no, I was just talking about patches.ffmpeg [20:44:12] <Sean_McG> mru: would I be welcome to join fate.ffmpeg for sunos-gcc-4.6 on i386/x86_64 ? I'd offer sparc too but I tend to shut it down for days at a time (usually only power it on when there's an x264 build to be done) [20:44:42] <mru> Sean_McG: every contribution is welcome [20:45:01] <Kovensky> < Sean_McG> me no <-- you_(plural) [20:45:10] <Sean_McG> OK... who should I talk to for a key? [20:45:19] <Kovensky> reminds me, I forgot to send my key to mru [20:45:20] <Kovensky> orz [20:45:23] <Kovensky> should do that when I'm at home [20:45:57] <Kovensky> my patchwork question was about <@BBB> mru: it seems patchwork doesn't update a patch if I reply a counterpatch in a thread, but also doesn't create a new patch ID [20:46:14] <mru> Sean_McG: talk to me [20:46:19] <Kovensky> are you running patchwork on production, in some closed test or just exploring docs? [20:46:28] <BBB> I'm not running patchwork [20:46:31] <mru> Kovensky: patches.ffmpeg.org [20:47:00] <Kovensky> BBB: damn english language for not having a plural you [20:47:09] <Kovensky> or for having but being identical to the singular [20:47:11] <BBB> hh :) [20:47:15] * Kovensky proclaims the invention of the "yous" word [20:47:59] <_av500_> ffyou [20:48:56] <drv> y'all ;) [20:49:41] <{V}> Kovensky, I think some new york gangsters beat you to that [20:50:17] <kshishkov> drv: where's our FSV2 decoder? [20:50:43] <drv> in some git tree on my old disk, rotting away [20:50:51] <drv> still haven't gotten a real sample yet [20:51:49] <kshishkov> IIRC it's used for shared screen feature [20:52:05] <kshishkov> and probably meant for direct streaming from one computer to another [20:54:01] <drv> yes, i think the ffmpeg encoder patch was based on network dumps of some kind [20:54:53] <Sean_McG> I was mildly surprised to see the other day that Adobe makes Flash plugin for Solaris... and current builds as well [21:03:37] <mru> Kovensky: the singular is thou [21:04:21] * elenril wonders why is his hovercraft full of eels [21:16:24] <Sean_McG> hmmm I was gonna learn some more Cocoa this afternoon but I think I should try to build ccache first [21:16:59] <mru> my computer builds glibc in <5min, I don't need ccache [21:17:06] * _av500_ thinks all cocoa should be shipped to switzerland [21:17:18] <Sean_McG> ffmpeg build takes over 5 minutes and all the while my fan runs at full crank :P~ [21:17:35] <_av500_> i had a pc like that once too [21:18:25] <mru> the noisiest parts here are the hard drives and some caps that make noises on usb and/or eth traffic [21:38:11] <Sean_McG> LOL... "I've had mono so many times it turned into stereo"... Glee is a riot [21:41:31] <jannau> _av500_: the belgian chocolate wasn't good? [21:41:50] <mru> ah.. new armcc, new bugs [21:41:57] <mru> but the old ones are gone [21:42:01] <Sean_McG> mru: party time! :D [21:42:14] <mru> now amr and dv are failing [21:42:25] <mru> used to be vp[56] and roq [21:42:37] <spaam> Nice [21:42:47] <spaam> fix some stuff.. get new ones [21:42:54] <mru> the dv bug isn't actually new [21:43:57] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r3ad464bfc7 ffmpeg/configure: [21:43:57] <CIA-38> ffmpeg: configure: fix non-standard regex used with expr [21:43:57] <CIA-38> ffmpeg: The colon operator of expr always anchors the pattern at the start [21:43:57] <CIA-38> ffmpeg: of the string. An explicit ^ in the pattern has unspecified [21:43:57] <CIA-38> ffmpeg: behaviour, so remove it. [21:43:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:45:04] <spaam> segv in mpeg4als [21:45:09] <mru> yeah, that too [21:50:21] <CIA-38> ffmpeg: Francesco Cosoleto <cosoleto(a)gmail.com> master * r70630e35a4 ffmpeg/libavformat/mmst.c: [21:50:21] <CIA-38> ffmpeg: mmst: print packet type with error status code message [21:50:21] <CIA-38> ffmpeg: Signed-off-by: Francesco Cosoleto <cosoleto(a)gmail.com> [21:50:21] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:50:27] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r8bf6db1b29 ffmpeg/libavformat/asfdec.c: [21:50:27] <CIA-38> ffmpeg: asfdec: split reading stream properties out of asf_read_header() [21:50:27] <CIA-38> ffmpeg: This contains a rename from gsize->size [21:50:27] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:50:29] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r5cbd3b5d91 ffmpeg/libavformat/asfdec.c: [21:50:29] <CIA-38> ffmpeg: asfdec: don't export empty metadata [21:50:29] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:50:31] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r1a973feb45 ffmpeg/libavformat/wtv.c: [21:50:31] <CIA-38> ffmpeg: wtv: ignore empty data_guid chunks [21:50:31] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:50:35] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rfbb6b49dab ffmpeg/libavcodec/ (5 files in 2 dirs): [21:50:35] <CIA-38> ffmpeg: ac3enc: Add x86-optimized function to speed up log2_tab(). [21:50:35] <CIA-38> ffmpeg: AC3DSPContext.ac3_max_msb_abs_int16() finds the maximum MSB of the absolute [21:50:35] <CIA-38> ffmpeg: value of each element in an array of int16_t. [21:50:36] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [22:03:40] <astrange> lu_zero: what threading abstraction? [22:04:26] * mru shouts at elenril [22:25:49] <lu_zero> astrange: w32thread and friends [22:28:51] <astrange> i'd like w32thraed to go away and be replaced by an implementation of pthread in osdep [22:29:11] <astrange> but yeah, avcodec_thread_execute doesn't make much sense being in AVCodecContext or lavc [22:29:19] <mru> I tried to get rid of it a while back but the windows users fought back [22:29:45] <Sean_McG> fun fun [22:32:22] <lu_zero> mru: move, not remove =P [22:33:29] <mru> lu_zero: I know [22:33:39] <mru> but w32threads should still go [22:33:46] <mru> there are nice pthreads implementations for windows [22:34:58] <Sean_McG> having to ship that extra DLL can be a contention point for some [22:35:20] <mru> they should've thought about that before making a windows app [22:35:25] <Sean_McG> agreed [22:35:37] <mru> it comes with the territory [22:36:09] <astrange> nothing requires them to use a dll, a version with working statics libs is available [22:36:13] <astrange> -s [22:36:47] <CIA-38> ffmpeg: Frank Barchard <fbarchard(a)google.com> release/0.5 * r329e816ed7 ffmpeg/libavcodec/vorbis_dec.c: (log message trimmed) [22:36:47] <CIA-38> ffmpeg: Check rangebits to avoid a possible crash. [22:36:47] <CIA-38> ffmpeg: Fixes issue 2548 (and Chrome issue 68115 and unknown CERT issues). [22:36:47] <CIA-38> ffmpeg: Originally committed as revision 26365 to svn://svn.ffmpeg.org/ffmpeg/trunk [22:36:47] <CIA-38> ffmpeg: (cherry picked from commit 13184036a6b1b1d4b61c91118c0896e9ad4634c3) [22:36:48] <CIA-38> ffmpeg: Addresses: CVE-2011-0480 [22:36:49] <CIA-38> ffmpeg: Conflicts: [22:36:50] <CIA-38> ffmpeg: Reinhard Tartler <siretart(a)tauware.de> release/0.5 * r04847a06c2 ffmpeg/Changelog: Update Changelog for 0.5.4 release. [22:36:55] <CIA-38> ffmpeg: Jason Garrett-Glaser <darkshikari(a)gmail.com> release/0.5 * rd6860fb653 ffmpeg/libavcodec/vorbis_dec.c: [22:36:55] <CIA-38> ffmpeg: Fix crashes in vorbis decoding found by zzuf [22:36:55] <CIA-38> ffmpeg: Fixes issue 2322. [22:36:55] <CIA-38> ffmpeg: Originally committed as revision 25591 to svn://svn.ffmpeg.org/ffmpeg/trunk [22:36:55] <CIA-38> ffmpeg: (cherry picked from commit 3dde66752d59dfdd0f3727efd66e7202b3c75078) [22:36:55] <CIA-38> ffmpeg: Addresses: CVE-2010-4704 [22:37:52] <mru> can someone please ack or nak my asfdec fix? [22:38:44] <siretart> DonDiego: I'd like to do a 0.5.4 release next week. Please let me know if you have anything to add and I missed [22:40:21] <Dark_Shikari> When will 0.5 die? [22:40:39] <mru> Dark_Shikari: when siretart no longer wants to maintain it [22:40:41] <Sean_McG> ask the magic 8ball? ;) [22:40:57] <Dark_Shikari> Is this like the Windows API? [22:41:00] <Dark_Shikari> It'll never, ever, die? [22:41:43] <ohsix> at least they version t heir structures [22:42:01] <mru> ohsix: you call appending "ex" versioning? [22:42:12] <Sean_McG> I was gonna say... [22:43:48] <Dark_Shikari> ohsix: it doesn't actually work that well though. [22:43:52] <Dark_Shikari> see for example http://git.videolan.org/?p=x264.git;a=commitdiff;h=49e2d55b5834318a4e370dde… [22:44:06] <ohsix> mru: they added a size field too! [22:44:30] <Dark_Shikari> In that example, on win64, the wrong struct definition gets used. [22:44:34] <mru> since when does size matter? [22:44:45] <ohsix> since windows [22:45:12] <ohsix> they have fixed packing for the interfaces so size changes are added members [22:45:23] <ohsix> they add a bunch of padding in real troublesome ones too [22:45:45] <ohsix> and some of that padding is gr8stuff, used as hidden handles, if you touch them bad things happen [22:47:26] <DonDiego> siretart: i have nothing queued [22:47:30] <siretart> Dark_Shikari: it might very well be possible that 0.5.4 will be the last one. mainly depends on how downstreams react and contribute to it [22:47:38] <DonDiego> gnite [22:47:44] <siretart> DonDiego: sleep well! [22:47:49] <Sean_McG> aye, sleep well [22:48:20] <ohsix> on balance, sleep awful, or don't sleep :D [22:49:11] <siretart> unbelievable. ffmpeg 0.6.1 did built on the hurd successfully: https://buildd.debian.org/fetch.cgi?pkg=ffmpeg&arch=hurd-i386&ver=4:0.6.1-5… [22:49:48] <ohsix> one less hurdle for its world domination [22:50:03] <mru> aren't hurd and success mutually exclusive? [22:50:23] <pJok> siretart, that just means it entered bikeshed country [22:50:36] <Flameeyes> mru: no that's hurd and usefulness [22:50:42] <Sean_McG> what does that term mean, "bikeshed"? [22:50:52] <pJok> you really don't wanna be in bikeshed country once the shed hits the fan [22:50:54] <mru> Sean_McG: bikeshed.org [22:50:54] <ohsix> obvious troll is obvious [22:50:57] <lu_zero> hurd can be a successful playground for concepts [22:51:18] <lu_zero> so hurd has at least an use [22:51:33] <ohsix> so does rtems and freertos [22:52:04] <mru> or L4 or minix or any other such system [22:52:20] <Sean_McG> or plan9? ;) [22:52:24] <mru> lol [22:52:27] <ohsix> l4 is closest [22:52:43] <ohsix> replacing parts for an experiment is ez [22:53:12] <mru> that's a nice aspect of microkernels [22:53:25] <mru> at least if they're done right [22:53:44] <mru> hmm, what were Kovensky and ruggles doing over there? [22:54:16] <ruggles> hm? [22:54:34] <mru> ruggles: you both dropped out and rejoined at the same time [22:54:40] <mru> probably using the same server [22:54:54] <ruggles> got a notice to reconnect due to server maintenance [22:54:55] <Kovensky> 19:51.58 [freenode] -Martinp23(martinp23(a)freenode/staff/wikimedia.martinp23)- [Server Notice] Hi everyone! The server you are on (card) will be going down for maintenance in the next few days. This is early warning that you might want to switch to another server in the chat.freenode.net rotation by simply reconnecting to chat.freenode.net. Thanks for using freenode, and if you've any questions join #freenode. [22:54:59] <ruggles> yeah, that one [22:55:01] * Kovensky just did /reconnect [22:55:10] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * raabc2682fc ffmpeg/libavformat/asfdec.c: [22:55:10] <CIA-38> ffmpeg: asfdec: fix build for big endian targets [22:55:10] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [22:56:00] <mru> ruggles: I'm losing track of your patch versions [22:56:21] <mru> could you mark the old ones as superseded on patchwork? [22:56:56] <Kovensky> is patchwork doing the monkeying or is it just for keeping track of things? [22:57:00] <ruggles> mru: yes. and one still needs to be resent in order to apply cleanly now. [22:57:31] <mru> Kovensky: just tracking [22:57:40] <siretart> good night [22:57:55] <Kovensky> do you intend to use it for monkeying later on? [22:59:24] <Sean_McG> night [23:02:53] <Sean_McG> ooo, looks like vc1 started failing on icc [23:03:18] <mru> always has [23:03:22] <Sean_McG> or has this been ... ah OK [23:03:36] <ruggles> mru: patchwork updated. the only one left has to be updated since the other ac3dsp patch was committed. [23:03:40] <mru> lines in red have more failures than the previous report [23:03:52] <mru> ruggles: thanks [23:17:08] <mru> (gdb) quit [23:17:09] <mru> Cannot access memory at address 0x7f8 [23:17:11] * mru curses [23:20:27] * Kovensky ncurses

1 0

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

13 Feb '11

[03:14:57] <kierank_> http://www.youtube.com/watch?v=ZRM6-PrOfZE [03:14:59] <kierank_> j-b: ..... [04:59:30] <saintdev> gsachin: pong [07:38:10] <zuxy> hi, do git.ffmpeg.org and git.videolan.org pull from each other? [07:38:30] <Sean_McG> ummm, no [07:42:58] <zuxy> Sean_McG: so all the git.ffmpeg.org commits seen from http://git.videolan.org/?p=ffmpeg.git;a=summary were hand picked by Michael? [07:44:53] <peloverde> by whoever is in the committer field [07:52:18] <saintdev> boiled_sugar: http://danbooru.donmai.us/post/show/851086 [07:52:37] <boiled_sugar> I think wrong channel [07:52:42] <saintdev> lol [07:56:36] <Sean_McG> hahahah [07:56:56] <Sean_McG> very cute though ^^; [09:20:02] <ubitux> http://www.osnews.com/story/24401/_lt_strike_gt_Patent_Troll_lt_strike_gt_M… [09:40:29] <_av500_> its actually helping vp8 [09:40:37] <peloverde> not really surprising and not really that trolly considering that parts of vp8 look like they were based on h.264 [09:41:08] <_av500_> peloverde: explain that to the freetards :) [09:45:52] <peloverde> And I've said this before too, perhaps a better use of that $106 million would have been lobbying to change the us patent system [10:14:12] <Dark_Shikari> 21:13 <@Dark_Shikari> how did you install yasm? [10:14:12] <Dark_Shikari> 21:13 < MakePath> yes ! [10:14:56] <peloverde> I'm pretty sure that just loop prints !\n [10:15:04] <Sean_McG> lol [10:15:39] <Dark_Shikari> yup. [10:15:47] <elenril> lol [10:16:02] <Sean_McG> are there any instructions for where I should start looking when a fate test is failing? as in, for example, where to set my 1st breakpoint in gdb? [10:17:28] <peloverde> it depends on the test and the type of failure [10:17:46] <Sean_McG> hrm... this isn't a crash, it's a checksum difference on the test result [10:18:18] <peloverde> does it work with --disable-asm? [10:18:28] <Sean_McG> lemme try that [10:19:19] <peloverde> if it does, from there you can start trying to narrow down which chunk of asm makes it fail [10:30:43] <Sean_McG> hmmm yeah, succeeds with disable-asm [10:31:46] <Sean_McG> anyways I should get some rest, I'll look at this again after some shuteye [11:30:40] <VFR_maniac> libavformat cannot handle aac in mp4+mov-chimera :( [12:20:30] <Kovensky> bcoudurier: ^ [12:29:10] <merbanan> VFR_maniac: file a bugreport on the roundup tracker [12:29:34] <VFR_maniac> i figured out the bug [12:31:05] <VFR_maniac> http://vfrmaniac.fushizen.eu/OtherStuff/0001-Fix-parsing-mp4-with-sound-des… [13:08:44] <j-b> 'moroning [13:18:19] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rcd6a5a57b8 ffmpeg/Makefile: [13:18:19] <CIA-38> ffmpeg: Add lavfi-showfiltfmts and graph2dot to $(TOOLS) [13:18:19] <CIA-38> ffmpeg: Allow make clean to remove the corresponding binaries. [13:18:19] <CIA-38> ffmpeg: Fix issue 2162. [13:18:19] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:18:28] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r40321376d8 ffmpeg/Makefile: [13:18:28] <CIA-38> ffmpeg: Allow "make clean" to clean files in tools [13:18:28] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:18:31] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * re063f5886b ffmpeg/doc/faq.texi: (log message trimmed) [13:18:31] <CIA-38> ffmpeg: Fix script command in a FAQ entry [13:18:31] <CIA-38> ffmpeg: In the FAQ section "How do I encode single pictures into movies?", use [13:18:31] <CIA-38> ffmpeg: -s for generating symbolic links with the ln command. [13:18:31] <CIA-38> ffmpeg: The script was generating hard links, which is not likely what it was [13:18:32] <CIA-38> ffmpeg: supposed to do. [13:18:32] <CIA-38> ffmpeg: Fix issue 2488. [14:08:42] <Dark_Shikari> pengvado: nice FFT patch. [15:10:24] * mru curses libavformat [15:10:40] <kshishkov> memcopy it! [15:11:17] <pJok> ncurses? [15:11:27] <mru> any curses will do [15:11:29] <mru> I'm not particular [15:12:52] <kshishkov> byt memcpy() if your favourite curse [15:12:55] <kshishkov> *but [15:48:53] <CIA-38> ffmpeg: Vitor Sessak <vitor1001(a)gmail.com> master * r47d62c965b ffmpeg/libavcodec/bink.c: [15:48:54] <CIA-38> ffmpeg: Make tables generation insensitive to floating-point implementation [15:48:54] <CIA-38> ffmpeg: Using doubles make the double -> int cast well defined for all the values [15:48:54] <CIA-38> ffmpeg: used, with the exception of when s[i]==1.0, which is special-cased. [15:48:54] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:24:44] <mru> ok, this is scary [16:25:06] <mru> I made -strict 1 -vsync 0 default and ran fate [16:25:39] <kshishkov> and got hello from VBV? [16:25:48] <mru> no [16:25:57] <mru> just no duplicating or dropping of frames [16:26:10] <mru> some of the refs have tons of duplicated frames [16:27:07] <mru> rv30 and rv40 drop about half of the rames [16:27:10] <mru> +f [16:27:32] <mru> one mpeg test and one wmv test duplicate a bunch of frames at the start [16:27:37] <kshishkov> yes, rv30 and rv40 should be dropped completely instead [16:28:17] <kshishkov> along with their creator [16:28:24] <mru> you? [16:28:31] <kshishkov> Buffering Inc [16:28:37] <mru> many game formats duplicate _every_ frame [16:28:39] <mru> or more [16:29:03] <mru> -strict 1 only affect h264 actually [16:29:30] <mru> but setting that and leaving -vsync at default makes ffmpeg.c drop the 15 first frames on many h264 tests [16:29:39] * kshishkov believes that RV3/4 and RALF design principle was "every coding is effective if you have lots of Huffman tables for every context" [16:30:03] <mru> when in doubt, huff [16:31:14] <kierank> kshishkov: implies there was a design principle [16:31:42] <kshishkov> mru: context-dependant Huff [16:32:03] <kshishkov> kierank: of course, how else they could come with "Buffering" message [16:32:35] <kshishkov> there are hundreds of tables for RALF and even tables for RV3/4 would make RAM cry [16:33:05] <kierank> kshishkov: what about dts [16:33:29] <kshishkov> no comment [17:05:22] <divVerent> ubitux: "MPEG (so not the MPEG-LA) has announced its intent to develop a new video compression standard for the web which will be royalty-free. "The new standard is intended to achieve substantially better compression performance than that offered by MPEG-2 and possibly comparable to that offered by the AVC Baseline Profile." [17:05:25] <divVerent> sounds VERY promising [17:05:43] <divVerent> so they say "it sure exceeds MPEG-2, and will be somewhat below AVC Baseline" [17:05:54] <ubitux> it would be great :) [17:05:57] <divVerent> when Dark_Shikari is done with it... it'll be somewhere between AVC Baseline and Main [17:06:01] <divVerent> so, great :P [17:06:58] <divVerent> as I suppose their estimates are referring to somewhat "ok-ish" reference encoders, and not excessively tuned ones [17:07:03] <kierank> divVerent: it's like vc-1 all over again [17:07:21] <divVerent> my point is just... such a thing will likely kill VP8 [17:07:27] <Kovensky> Vitor1001: did you meet another brazilian named Will Almeida in france [17:07:29] <kierank> vc-1 was meant to be royalty free [17:07:31] <divVerent> as VP8 simply lacks a good spec [17:08:00] <mru> they could be planning on making a subset of h264 royalty-free [17:08:12] <divVerent> doesn't sound like it [17:08:15] <divVerent> but would be better [17:08:25] <mru> that would be substantially better than mpeg2 and not quite as good as h264 [17:08:26] <divVerent> h264 baseline + "trivialities" would be a really great codec, for example [17:08:28] <kierank> iirc baseline was meant to be royalty free at some point [17:09:20] <kierank> anyway it'll be funny if xiph get involved in mpeg [17:10:14] <divVerent> I mean... baseline removes 8x8dct (triviality), bframes (triviality), cabac (nontrivial), --cqm flat (just a bunch of numbers, so, triviality), and --weightp 0 (weighted prediction of P-frames again sounds like your typical patent claim) [17:10:29] <divVerent> basically, H.264 baseline + b-frames would be VERY promising :P [17:11:22] <divVerent> patenting a set of matrices sounds like abuse of the patent system, so I suppose that must be free [17:11:48] <divVerent> and size isn't an algorithmic ingenuity, if anyhting, the DCT itself is (but that is too old) [17:11:53] <kierank> it removes delta_qp [17:12:03] <kierank> oh baseline [17:12:07] <kierank> i thought you mean patents [17:12:15] <divVerent> this was just daydreaming [17:12:30] <divVerent> about "what can we safely add to H.264, assuming H.264 baseline were royalty free" [17:12:57] <divVerent> or rather, "if baseline were free, which differences to high can we immediately add back" [17:13:13] <divVerent> bframes e.g. are very likely not patentable [17:13:45] <divVerent> 8x8dct POSSIBLY can be, as it also involves an adaptive DCT size decision [17:14:04] <mru> b-frames were in mpeg1 [17:14:11] <divVerent> mru: exactly [17:14:16] <divVerent> not used much [17:14:22] <divVerent> but b-frames aren't exactly a new idea [17:14:30] <mru> at least as old as mpeg1... [17:14:36] <mru> which is >20 years [17:14:46] <divVerent> at least, b-frames are a non trivial idea [17:15:01] <divVerent> as e.g. "decode order isn't playback order" WAS something new at the time [17:15:50] <divVerent> basically, B-frames can be summarized as "Assume we remove the requirement that decode order is playback order... what can we gain?" [17:16:17] <mru> and then h264 goes crazy with lots of ref frames [17:16:27] <divVerent> yes, but doesn't baseline already do that? [17:16:39] <mru> don't remember [17:16:44] <mru> there's probably some restriction [17:16:49] <divVerent> weighted prediction for p-frames is off, though, in baseline [17:17:03] <divVerent> but shouldn't this still allow --refs? [17:17:42] <divVerent> IIRC (not sure), you still can select a different reference frame per macroblock, and maybe even take the arithmetic mean of two or three, without "weighting" [17:18:29] <kierank> isn't motion vector prediction patented [17:18:53] <divVerent> doesn't mpeg-1 do that? [17:20:28] <mru> yes it does [17:20:42] <divVerent> but basically, I think there is one codec alternative that MAY have a future too [17:20:47] <divVerent> I call it "VP8x" [17:21:01] <divVerent> VP8, incompatibly extended by some other interesting features, and properly specified and bugfixed [17:21:19] <kshishkov> i.e. VP9 [17:21:26] <divVerent> or that [17:21:32] <divVerent> wouldn't it only be VP9 if On2 makes it, though? [17:22:00] <kshishkov> VPy then [17:22:03] <divVerent> hehe [17:56:21] <Vitor1001> Kovensky: Will Almeida? No. Funny, not a very brazilian name... [17:56:39] <Kovensky> Vitor1001: lol [17:57:14] <Kovensky> Vitor1001: he's one of my professors, he came back recentlish from a doctorate in france, don't remember if in 2009 or early 2010 [17:59:29] <Vitor1001> Funny, doctorate in what? [17:59:53] <Vitor1001> It would surprise me that I don't know a brazilian phd student in physics living in france... [18:06:38] <Kovensky> Vitor1001: hm, it was something on data processing, not physics [18:34:08] <Sean_McG> mru: lavf-pixfmt on gcc 4.6 seems to be problematic asm somewhere -- it succeeds when built with disable-asm [18:34:27] <mru> Sean_McG: next step is to narrow it down [18:34:38] <Sean_McG> I'm not sure where to start, I'm so new to this [18:37:39] <Sean_McG> is there a good place to put my 1st breakpoint in gdb, so I can skip all the irrelevant stuff? [18:37:54] <mru> I wouldn't start chasing this with breakpoints [18:38:06] <Sean_McG> what I almost need is a unit tester [18:38:15] <kshishkov> brains [18:39:47] <kshishkov> 1) look at the diff, determine which files differ [18:39:50] <mru> Sean_McG: I'd start by looking at the rgb24ToY and rgb24ToUV functions in swscale [18:40:25] <Sean_McG> wow, I was like, totally looking only in avformat [18:40:38] <mru> no asm there [18:40:58] <Sean_McG> except for get_bits.h -- which is another thing that has only started whining since 4.6 [18:42:21] * mru builds gcc 4.6 [18:42:35] <mru> Sean_McG: how about a race? [18:42:44] <spaam> do it! [18:42:49] <Sean_McG> I'd lose :) [18:42:52] <kierank> the troll vs the Sean_McG [18:43:05] <Sean_McG> I'm not known for being fast [18:43:08] <kshishkov> meetpoint is in the middle of Atlantic ocean [18:43:24] <ohsix> you're known for being slow? [18:43:35] <Sean_McG> pretty much [18:43:41] <mru> are you accurate? [18:43:48] <mru> that's what matters here [18:43:51] <Sean_McG> depends what context [18:44:35] <mru> the trick is to quickly narrow down the code of interest to a few functions or a file [18:44:46] <mru> then look for commonly miscompiled patterns there [18:45:19] <spaam> Sean_McG: you know.. mru built his system with --omg-optimized -O1337 [18:45:29] * Sean_McG snickers [18:45:51] <mru> CFLAGS="-O3 -march=core2 -fno-tree-vectorize -fomit-frame-pointer -pipe" [18:45:54] <mru> if you must know [18:45:55] <kshishkov> spaam: nope, just gcc -mru is enough [18:46:00] <Sean_McG> vomit frame pointer! [18:46:38] <spaam> kshishkov: true. [18:47:00] <Sean_McG> so have any of you bought a Sandy Bridge yet, or waiting for Bulldozer? [18:47:22] <spaam> buldozer? is that the amd thing? [18:47:25] <Sean_McG> aye [18:47:31] <kierank> i'm more of a combine harvester man myself [18:47:34] <mru> still on a good ol' i7 here [18:47:48] <Sean_McG> better than mine... C2D 2.4 (MacBook Pro) [18:48:11] <kierank> http://www.youtube.com/watch?v=tb63PdPweDc [18:49:06] <Sean_McG> hahahahah [18:49:09] * kshishkov wants proper 64-bit ARMv11 SoC with 8G RAM and 128G flash [18:50:13] <spaam> kshishkov: buy one [18:51:12] <kshishkov> spaam: when it's released as OMAP8 on HamsterBoard I'll buy it [18:51:43] <Sean_McG> hahahah..."have to go ooh-waah ooh-waah after the first line!" [18:57:42] <Sean_McG> what does MANGLE() do? [18:57:54] <mru> it mangles [18:58:08] <kshishkov> symbol names [18:58:11] <mru> it prefixes its argument with _ if needed [18:58:15] <Sean_McG> ah [19:08:25] <mru> http://pastie.org/1556851 [19:08:58] <Sean_McG> ahhh...wow you are fast [19:09:32] <mru> it's easy when you know what you're looking for [19:12:32] <spaam> Sean_McG: you knw.. mru like x86 asm.. so it goes fast to find the problem :) [19:13:04] <ohsix> theres lots to say about x86, i'd probably be insulted [19:13:47] <Sean_McG> truthfully I'm not very good at asm, we only touched on it very briefly in college. mostly we were doing C,C++ & Java [19:14:15] <kshishkov> i.e. not C [19:14:18] <Sean_McG> and if I was to pick an architecture I liked the most I'd have to say POWER/PPC [19:14:55] <j-b> BBB: ping [19:15:57] <BBB> j-b: pong [19:57:36] <_av500_> BBB: got *it*? [19:57:57] <BBB> working on "it" :-p actually [19:58:28] <BBB> but I don't think the code is right, I've been playing with it for a while and I can't get and working results from it :( [19:58:29] <kshishkov> BBB: BTW, I think we should rewrite RM demuxer from scratch [19:58:40] <BBB> kshishkov: bcoudurier did that also [19:58:42] <BBB> check his ffmbc code [19:58:47] <kshishkov> BBB: iKnow [19:58:51] <mru> kshishkov: you're volunteered [19:58:52] <Compn> 'we should' [19:58:53] <Compn> hehe [19:59:04] <kshishkov> I think I even tried to port some bits from it [19:59:26] <kshishkov> mru: I'd like to but I don't want my name name associated with Real formats [20:00:19] <kshishkov> Compn: in that case "we" is equal to Bonald B. Bultje [20:01:04] <BBB> never heard of that [20:01:06] <elenril> BBB must merge the rest of -mt first [20:01:22] <kshishkov> I agree [20:01:38] <kshishkov> BBB: doesn't BBB stand for your initials? [20:01:43] <BBB> no [20:01:52] <BBB> astrange: ping for rest of ffmpeg-mt :-p [20:08:34] <Compn> kshishkov : werent the rm specs part of those specs online ? or just rv8/9 specs? :\ [20:09:25] <kshishkov> Compn: I got them in other way [20:13:21] <Compn> were they as braindead as you always knew ? :) [20:14:03] <_av500_> i think the accident specs were only rv8 and 9 [20:14:26] <Sean_McG> mru: why were a set of brackets all that was needed to fix that issue? something AT&T syntax? [20:14:29] <kshishkov> for the rest you need to sacrifice newborns [20:14:32] <Compn> a format that had 10+ years of hacks added onto it [20:14:36] <mru> Sean_McG: read more carefully [20:15:40] <Sean_McG> and a memory constraint became a register constraint? [20:17:05] <mru> the final code changes from something like "movq 24+ff_bgrfoo, %mm6" to "movq 24(%eax), %mm6", give or take [20:17:54] <mru> replacing an immediate address with an indexed register [20:19:00] <Sean_McG> so what change in 4.6 forced that... something in IRA? [20:19:26] <mru> no clue [20:19:35] <mru> I was just guessing and got lucky [20:19:44] <Sean_McG> k [20:20:03] <mru> although there's a warning related to that: [20:20:11] <mru> libswscale/swscale_template.c:1885:5: warning: use of memory input without lvalue in asm operand 4 is deprecated [enabled by default] [20:21:59] <Sean_McG> ...and so there is. [20:31:03] <mru> BBB: arithmetic fail :) [20:31:16] <BBB> fuck :-p [20:31:30] <BBB> ohwell [20:31:36] <BBB> at least I'm proud to be a fool :-p [20:32:29] <BBB> the function is kind of odd [20:32:36] <kshishkov> BBB: tell that to your child in twelve years [20:32:49] <mru> shifting elements in an array? what's odd about that? [20:33:00] <Sean_McG> kshishkov: kid won't figure it out themself? [20:33:04] <BBB> why does it do [srcq+offsetq+...*0/1/2/3] if it could just do [srcq+....*0/1/2/3]? [20:33:33] <BBB> maybe because he doesn't have to increment srcq in the loop now? [20:33:38] <BBB> I wonder if that's faster though [20:33:48] <BBB> srcq+offsetq+.. is bigger binary code than srcq+.., right? [20:33:58] <mru> no idea [20:34:16] <mru> mmsize is a constant of course [20:34:17] <BBB> ruggles: ^^ ? [20:34:28] <BBB> yeah, mmsize is the constant offset [20:40:47] <ruggles> BBB: i don't quite understand the question. what alternative are you suggesting? [20:41:32] <mru> ruggles: update srcq with each iteration and drop offsetq from the [] [20:41:53] <mru> so it would say "mova m1, [srcq+mmsize*n]" [20:42:16] <mru> that would cost one extra instruction in the loop [20:42:24] <mru> but the mova opcodes might get smaller [20:42:38] <ruggles> yes. it just has extra adds. but it's worth a try. [20:42:46] * mru hugs post-increment addressing [20:43:05] <kshishkov> r3! [20:43:12] <mru> the address generation itself should be the same speed [20:43:25] <mru> but smaller opcodes might be beneficial [20:43:33] <BBB> ruggles: also, I'm not quite sure why you sub 4*mmsize from offsetq before the loop [20:43:44] <mru> BBB: he's working backwards [20:43:50] <ruggles> yes [20:43:51] <BBB> ruggles: you can just change your absolute offset to be -[4321]*mmsize [20:43:58] <BBB> instead of [0123]*mmsize [20:44:25] <BBB> (and of course if you increment offsetq in the loop, you don't have to go backwards anymore) [20:44:56] <ruggles> sure, i'll test it [20:45:04] <BBB> ruggles: if you try a few approaches you'll see which is fastest, and whichever is fastest is fine and can be committed (just maybe change cmp x, 0 to test x, x) [20:46:06] <ruggles> i did try that and it was slower [20:46:16] <mru> wtf [20:46:41] <ruggles> yep. i saw gcc likes to do that so i tried it. [20:46:54] <mru> oh, if gcc does it you probably shouldn't [20:46:59] <ruggles> :) [20:47:14] <mru> that's why we write asm, no? [20:47:26] <BBB> it was slower? [20:47:27] <BBB> wtf :) [20:47:34] <BBB> probably alignment-based [20:47:37] <BBB> ok, nevermind then [20:47:57] <BBB> asembly is like black magic [20:47:59] <ohsix> how come the whole thing isn't in assembly [20:48:00] <BBB> don't try to get it [20:48:02] <BBB> it'll eat you alive [20:48:18] <mru> arm asm isn't nearly as dark [20:48:30] <ohsix> (i know the answer, but gcc still gets a lot of shit for doing most of the job sort of well) [20:48:58] <mru> ohsix: gcc does a reasonably good job often enough that it's not worthwhile writing most functions in asm [20:49:07] <mru> only the most cpu-intensive ones [20:49:11] <BBB> arm doesn't have 1000 reincarnations of different-but-similar instruction sets that are not 100% compatible, plus 1000000s of revisions of cpus, each of which behaves slightly different with each instruction set [20:49:12] <ruggles> yeah, i'm inclined to settle for 85% faster than C instead of getting really frustrated trying to get 90% faster than C. [20:49:15] <ohsix> i know [20:49:47] <mru> ruggles: you're too modest [20:49:56] <mru> I don't settle for less than 4x speed of C [20:50:02] <mru> for simd [20:50:29] <mru> for non-simd the gain can be anywhere from 30% and up [20:50:34] <mru> often 100-200% [20:50:52] <mru> when registers run low [20:51:17] <BBB> gotta love x86-64 [20:51:20] <BBB> never too few registers [20:51:21] <BBB> \o/ [20:51:26] <mru> only 16 [20:51:34] <BBB> and if you do, you can use mm and xmm ones as backups [20:51:35] <ohsix> 649k is enough for everyone [20:51:41] <BBB> as alternative to stack [20:51:43] <Sean_McG> heh, and most other architectures had insane register files [20:51:56] <mru> 16 is quite common [20:52:02] <mru> some have 32 [20:52:06] <ruggles> 4x speed is same as 75% faster, no? [20:52:07] <mru> a few have 64 [20:52:11] <ohsix> Sean_McG: they also had weird rules due to the instruction size/format [20:52:21] <mru> 4x speed is 300% faster [20:52:39] <mru> did you mean 10% time? [20:52:40] <ruggles> you can't have 100% faster. that's instantaneous. [20:52:47] <mru> wrong [20:52:47] <BBB> mru: don't forget with pextrq, you can use 16 xmm registers for 32 quadwords, saving you up to 256 bytes of stack [20:52:58] <BBB> ruggles: depends how you count [20:52:58] <mru> ruggles: 10% time == 900% faster [20:53:14] <mru> I count in whichever way give the highest numbers [20:53:15] <Sean_McG> I'd like to learn asm, but I can't find any courses at my local educational institutions [20:53:16] <ruggles> well if you compare backwards i guess [20:53:23] <mru> ruggles: do you compare speed or time? [20:53:36] <mru> 10% less time != 10% faster [20:53:48] <ohsix> Sean_McG: get anything with an arm in it [20:53:54] <mru> Sean_McG: there are no good asm courses [20:54:02] <mru> learn by doing [20:54:07] <ohsix> things can be had for 20$, make it blink lights [20:54:14] <Sean_McG> ohsix: I've kinda waffled with doing that, something like a cheap SheevaPlug or what not [20:54:25] <mru> beagle is a better choice [20:54:30] <Sean_McG> or a beag...yeah [20:54:32] <mru> ~$130 [20:54:39] <ohsix> cheap stuff that fits in a breadboard or has useful outputs is better [20:54:50] <mru> ohsix: depends on what you're after [20:55:02] <ohsix> blinking lights [20:55:13] <mru> I can do that with a handful of transistors [20:55:34] <ruggles> mru: guess my mind is stuck on compression comparisons... too much lossless :) [20:55:36] <ohsix> who can't, you can actually do it with one [20:55:43] <Sean_McG> is ARM a good platform to learn asm on? [20:55:46] <mru> for more elaborate effects, move up to counters, shift registers, and logic gates [20:55:50] <mru> Sean_McG: sure [20:55:53] <mru> it's a nice instruction set [20:55:59] <ohsix> Sean_McG: it wont kill you [20:56:14] <mru> I wonder if I've used all instructions yet [20:57:03] <Sean_McG> hmmm, beagleboard xM is $149 [20:57:28] <mru> it's the big brother of the beagle classic [20:58:06] <ohsix> i already have all the junk, so if i was buying it for something it'd def be the breadboard variety [20:58:08] <mru> and then there's their cousin the panda at 179 [20:58:42] <mru> 1GHz dual-core goodness [20:58:45] <ohsix> bringing linux or anything up and poking at it would be dreadfully boring [20:59:07] <mru> board bringup has its charm [21:05:01] <peloverde> when i first heard of the panda i assumed it was some chinese version of the beagle [21:06:23] <mru> there is an indian version of the beagle [21:06:26] <mru> the devkit800000000000000000 [21:06:34] <Sean_McG> lol [21:06:38] <mru> perhaps slightly fewer zeros [21:16:42] <mru> omg libjpeg is convoluted [21:17:02] <ohsix> it's also largely from the 80s isn't it? [21:17:13] <mru> all the more reason to keep it small [21:17:28] <mru> the ffmpeg jpeg decoder is like 5 lines [21:17:29] <ohsix> and has stuff in it from when you couldn't even fit stuff into memory [21:17:45] <mru> I'm not talking about the memory management [21:18:33] <lu_zero> mru: what are you doing with libjpeg? [21:18:45] <mru> making money [21:19:39] <pJok> mru, selling libjpeg to the chinese as classified secrets? [21:19:58] <ohsix> i'm not really talking about memory management either; it jus permeates the whole thing & how its structured [21:20:00] <lu_zero> mru: if it involves making libjpeg flying on arm I'll use it as well [21:20:03] <mru> no, taking android's copy of it, making it faster, and selling it back [21:20:11] <lu_zero> (and plant on gentoo as soon as possible) [21:20:29] <mru> the qualcomm mods are disgusting [21:20:37] <lu_zero> why? [21:20:45] <ohsix> more like qualcomm is [21:21:04] <mru> lu_zero: do you expect $bigcorp to do anything nicely? [21:21:21] <ohsix> expedient and disposable is their motto [21:21:33] <Flameeyes> mru: I don't think lu_zero is so naïve [21:21:40] <mru> nor do I [21:22:06] <Flameeyes> and you just reminded me of opencryptoki... thanks for killing my possible sleep for the next couple of days [21:22:45] <lu_zero> ^^; [21:31:44] <BBB> oh wow I just found a radio station that uses wmavoice - my codec is actually practically useful \o/ [21:32:40] <Flameeyes> BBB: radio station with voice? [21:32:55] <lu_zero> wmapro with voice? [21:33:51] <BBB> no wmavoice [21:36:41] <lu_zero> uhm [21:36:56] <lu_zero> mru: http://ffmpeg.pastebin.com/dgYAxSFQ <- would be useful? [21:37:51] <mru> no [21:38:08] <mru> the files are always there [21:38:27] <mru> -include means don't error if file doesn't exist [21:38:29] <lu_zero> except when you have the same code mapped in different places [21:38:32] <lu_zero> I know [21:38:33] <mru> huh? [21:38:45] <lu_zero> current situation [21:38:46] <mru> if the files aren't there, something is horribly wrong [21:39:00] <mru> what problem are you trying to solve? [21:39:01] <lu_zero> ffmpeg tree exported to msys in a box [21:39:12] <lu_zero> msys is dog slow [21:39:32] <lu_zero> problem at hand : issue make clean w/out waiting for ages [21:39:44] <mru> I don't see why that makes a difference [21:39:49] <mru> did you delete the files? [21:39:50] <lu_zero> solution: run make clean in the host, not the guest [21:40:19] <lu_zero> the files are there but the paths are wrong for the host and right for the guest [21:40:24] <JEEB> make distclean is slow for me sometimes, but also fast sometimes :/ I do know that it's lolslow at configure tho @ msys [21:40:26] <lu_zero> and. now I'm puzzled [21:41:33] <lu_zero> http://ffmpeg.pastebin.com/cKgvQxiC [21:41:46] <lu_zero> what as expects to get those ? [21:42:19] <mru> binutils 2.16 or other ancient version? [21:43:12] <lu_zero> codesourcery 2.19.something [21:43:22] <mru> that should be recent enough [21:43:28] <lu_zero> indeed [21:43:47] * lu_zero is really spending too much time on getting bada working =P [21:44:31] <mru> windows-only compiler? [21:45:44] <lu_zero> mru: I have built it on linux from sources but seems there are discrepancies [21:45:49] <roxfan> maybe that compiler doesn't support UAL for vfp code [21:46:04] <roxfan> or just doesn't support ual [21:46:08] <lu_zero> it's the assembler puking [21:46:11] <mru> the error message suggests it does support ual [21:46:20] <mru> it would say invalid instruction name or something otherwise [21:46:27] <roxfan> vpop is pretty basis [21:46:28] <lu_zero> just the asflags are wrong [21:46:29] <roxfan> basic [21:46:49] <mru> lu_zero: it needs -mfpu=foo to work of course [21:46:58] <mru> unless the defaults are sane [21:47:01] <mru> (unlikely) [21:47:18] <lu_zero> (exactly) [21:47:26] <lu_zero> on linux the defaults seem ok [21:47:36] <lu_zero> on the sdk provided the are... [21:47:41] <lu_zero> utterly wrong =_= [21:47:57] <Sean_McG> mru: hrm... same error as the swscale is also @ libavcodec/x86/fft_3dn2.c:157 [21:48:05] <Sean_McG> s/error/warning/ [21:48:48] <mru> that one is at least feasible to convert to yasm [21:49:52] <BBB> PS was my 3dnow-thingy disabling patch ok? [21:49:58] <BBB> allows compiling ffmpeg with clang 2.8 [21:50:42] <ruggles> BBB: i was considering trying the shuffle/por thing. i just thought it would be slower. but i should never guess when it comes to asm. :) thanks for the code. [21:50:56] <BBB> ruggles: was it actually faster? [21:51:03] <ruggles> haven't tried yet. [21:51:05] <BBB> oh [21:51:07] <BBB> :-p [21:51:21] <ruggles> still working on various versions of abs vs min/max [21:51:39] <BBB> these things aren't too much effort to try, my take is if you're gonna try to write the fastest code, you should try a few things and make sure your choice is the best [21:51:47] <ruggles> indeed [21:51:51] <BBB> but I like your code a lot, ac3enc looks pretty good right now [21:52:06] <BBB> now if only we could convince peloverde to do something about aacenc [21:52:21] <BBB> ruggles: any interest in aac? :-p [21:52:29] <ruggles> thanks. the lastest stuff is to speed up the fixed-point encoder. then i have a quality improvement ready for it. [21:52:43] * saintd3v eeks [21:53:26] <ruggles> BBB: i haven't looked into it much. i'm slightly afraid of getting lost in the woods... ;) [21:53:45] <BBB> saintd3v: :D [21:54:24] <saintd3v> ruggles: join me, then i'll have company out here. [21:54:37] <ruggles> so many extensions and mp4 crap. mp4als is bad enough with that stuff. aac takes it to the extreme. [21:55:02] <saintd3v> ruggles: wouldn't need most of the extensions [21:55:08] <saintd3v> lc is simple enough [21:55:23] <BBB> elenril: so about the guid renaming, why the long ff_asf_guid_... prefix? [21:55:27] <ruggles> it would be nice to learn a little bit about it. we need a better psy model. [21:55:27] <mru> the good thing about writing an encoder is you get to choose the features you support [21:55:33] <BBB> elenril: isn't it quite obvious that it's a guid? [21:55:39] <BBB> I mean, after all it _is_ a guid [21:55:48] <BBB> like int ff_asf_int_i; [21:55:56] <saintd3v> ruggles: well it's incomplete [21:56:03] <BBB> ff_asf_ is debatable because they're non-static, but the int part is a little much [21:57:44] <ruggles> saintd3v: that much is clear. :) at first i thought i could reuse it as a secondary psy model for ac3, then i realized it's probably worse than the one already built-in to ac3. [21:58:10] <saintd3v> i know mostly what needs done to complete the 3gpp psymodel, but i'm wary of just doing another 3gpp clone [21:58:48] <mru> saintd3v: what would it take to convince you to make it decent? [21:59:07] <mru> is the issue time or money? [22:01:14] <BBB> elenril: also, regarding your don't-set-empty-metadata-values, should that be generalized, and should there also be "space-only" detection, e.g. for metadata consisting only of whitespace (\n\r\t )? [22:01:43] <mru> don't forget form feed and vertical tab [22:02:02] <kierank> isspace [22:02:23] <mru> and what do you do with the bell character? make it an audio stream? [22:02:52] <saintd3v> mru: more knowledge. i'm not confident i know enough about psychoacoustics to be able to implement my own psymodel. [22:03:12] <kierank> saintd3v: you should get some people from hydrogenaudio [22:03:14] <mru> so steal one [22:03:24] <saintd3v> the reason i know what our 3gpp psymodel is missing is because i've gone over the 3gpp source, and the 3gpp spec. [22:04:40] <BBB> I thought the lame one was pretty good? [22:04:42] <saintd3v> mru: lame's does a convolution at the end, but i have no idea where the table they use came from, which makes it kind of hard to extend for aac's extra scalefactors. [22:04:59] <mru> ask them [22:05:32] <saintd3v> i emailed gabriel. haven't got a reply, guess i should ping him on that. [22:06:17] <saintd3v> not sure how to get ahold of tak [22:06:21] <saintd3v> *takehiro [22:07:40] <ruggles> are orps and por really any different? [22:07:41] <saintd3v> anyway...i guess i should finish 3gpp [22:08:49] <_av500_> elenril: got that? a bell char in metadata has to be exported as an audio stream! [22:09:10] <ruggles> LOL [22:10:37] <lu_zero> O_o [22:11:01] <lu_zero> _av500_: uhm mpegts =P [22:11:49] <saintd3v> ruggles: come get lost with me! [22:14:16] <ruggles> saintd3v: maybe after i finish ac3 and eac3. my todo list is so long... [22:15:45] <ruggles> i really want to finish AVFrame in audio codecs, and work on planar audio, generic mixing, and simd sample format conversion. [22:16:49] <BBB> speaking of the devil [22:16:50] <BBB> :-p [22:19:10] <lu_zero> AVFrame audio? [22:19:19] <lu_zero> or another devil? [22:19:33] <mru> I guess he means peloverde [22:23:14] <BBB> lu_zero: can you review anssi's mpegts patches? [22:23:17] <BBB> I know nothing about mpegts [22:44:54] <lu_zero> not that I know much more [22:45:07] <lu_zero> still they look pretty straightforward [22:45:32] <lu_zero> I wanted to have bcoudu opinion though [22:52:06] <peloverde> mru: bcoudu: Did either of you guys test that ms adpcm patch? [22:52:22] <peloverde> Because I'm getting divide-by-zeros because of it [22:52:41] <mru> which patch? [22:53:01] <mru> the adpcm in mov one? [22:53:07] <peloverde> yes [22:53:28] <bcoudu> yes works in every case here, stream copy as well [22:53:41] <peloverde> movenc.c:84 with scatter.wav from samples [22:55:38] <bcoudu> stream copy ? [22:56:26] <peloverde> yes [22:59:20] <bcoudu> that's because frame_size is not set [23:01:06] <peloverde> that's correct [23:01:15] <peloverde> it worked fine with my patch [23:01:17] <bcoudu> - if(!st->codec->frame_size && !av_get_bits_per_sample(st->codec->codec_id)) { [23:01:17] <bcoudu> + if(!st->codec->frame_size && !mov_get_lpcm_flags(st->codec->codec_id)) { [23:01:30] <bcoudu> your patch was broken if you accepted frame_size unset [23:01:33] <bcoudu> and indeed it was [23:02:08] <ruggles> BBB: your shuffle/por suggestion is about 12 cycles faster for sse2 [23:02:16] <peloverde> so that makes it error out, how about making it actually copy [23:02:23] <bcoudu> you can't [23:02:28] <bcoudu> no frame size no luck [23:02:35] <bcoudu> you don't know how many samples are in the frame [23:02:48] <peloverde> the wav plays fine [23:02:57] <bcoudu> yes because frame size is in extradata [23:03:04] <bcoudu> read the specs ... [23:03:32] <peloverde> quicktime can copy it [23:03:47] <peloverde> I suppose quicktime is wrong too [23:04:03] <bcoudu> quicktime is right [23:04:19] <peloverde> <bcoudu> you can't [23:04:57] <bcoudu> if you don't know the frame size you are going to put wrong values in samples to chunk [23:08:01] <peloverde> if you want to be constructive and not just be a snotty dick perhaps you should just say that you think the wav demuxer is broken, which is what I think you are trying to say [23:09:56] <peloverde> furthermore shy should frame_size be used there and not pkt->size? [23:10:38] <bcoudu> I'm wasting my time with your hacks [23:10:49] <bcoudu> and you keep being stubborn [23:11:02] <mru> calm down, both of you [23:11:20] <mru> calling each other names won't fix the bug [23:11:42] <bcoudu> and the was demuxer is not broken, you don't need frame size to decode [23:11:46] <bcoudu> you only need block align [23:12:31] <peloverde> so whose job is it to set frame_size? [23:17:45] <peloverde> mru: "you can't" is a misleading non-answer [23:21:04] <DonDiego> gnite [23:30:12] <bcoudu> are you stupid or what ? [23:32:01] <ohsix> i infer that the value may be unknown [23:32:19] <ohsix> and making one up is wrong [23:32:50] <peloverde> <peloverde> quicktime can copy it <bcoudu> quicktime is right [23:32:55] <bcoudu> talk about a waste of time [23:33:00] <bcoudu> you don't know what you are doing [23:33:28] <peloverde> how does quicktime get the right answer? [23:33:57] <bcoudu> because quicktime retrieve the frame size from the wav [23:36:02] <peloverde> So whose responsibility is it to get this from the wav and put it in frame_size? [23:43:53] <ohsix> git grep to the rescue [23:44:37] <ohsix> elementary streams dont have the info

1 0

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

12 Feb '11

[00:07:12] <j-b> Jumpyshoes: no, irssi [00:07:34] <mru> the one client to rule them all [00:09:25] <mru> #define ONE((INT32) 1) [00:11:26] <Jumpyshoes> j-b: oh, i see [00:19:03] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * rf3d09d44b7 ffmpeg/libavcodec/vp8.c: [00:19:03] <CIA-38> ffmpeg: VP8: optimized mv prediction and decoding [00:19:03] <CIA-38> ffmpeg: Merge find_near_mvs and mv bitstream decoding: don't do prediction steps [00:19:03] <CIA-38> ffmpeg: until absolutely necessary. [00:22:30] <Kovensky> 20:49.51 mru: oh, and everything you hear on irc is true <-- how do you hear written text? :) [00:22:34] <Kovensky> 20:58.48 mru: rebase -i <-- that's not a merge =p [00:23:10] <mru> rebase -i is the answer he was looking for [00:23:26] <mru> and re hearing on irc, that's the point [00:23:53] <Kovensky> heh [00:24:14] <Kovensky> there is a way to workaround that though [00:24:17] * Kovensky points to festival [00:24:57] <mru> so text2speech makes things come true? [00:25:24] <Kovensky> well, it makes hearing irc come true :) [00:26:28] <kierank> or we could have an #ffmpeg-devel skype like we did in #x264 [00:27:33] <Kovensky> voice chat doesn't work very well with more than 5 people involved [00:27:47] <kierank> it was alright when we did it [00:28:08] <Kovensky> it was terrible when I tried that :> [00:28:17] <kierank> though it managed to be exactly like #x264 somehow. discussion of touhou interspersed with discussion of x264 [00:28:22] <Kovensky> heh [00:28:36] <Kovensky> live imitates irc! [00:28:38] <Kovensky> life* [00:30:45] <Kovensky> the only time I've used voice chat effectively with more than 10 people was in an eve fleet, since there's a clear hierarchy and rules to follow [00:30:52] <Kovensky> not much unlike military radio [00:31:15] <kierank> I always though multiplayer fps voice chat would be like military radio [00:31:18] <kierank> how wrong was I [00:31:38] <Kovensky> lol [00:31:56] <Kovensky> no, it's just people cursing each other and competing for the biggest cluster f bomb [00:32:06] <kierank> it's only good if it's people you know [00:34:02] <merbanan> my name is Benjamin-san [00:35:52] <ubitux> is there a way in the probe function to ask for more data? [00:37:30] <ubitux> also, how to handle if the header is at the end of the file? [00:37:59] <kierank> merbanan: ? [00:38:38] <merbanan> from devel [00:40:45] <BBB> merbanan: I saw that, that was funny [00:46:18] <Kovensky> merbanan: Benãã [00:46:20] * Kovensky runs [00:46:58] * kierank has no idea what that means [00:47:21] <Kovensky> "bensan" [00:47:52] <kierank> well i still have no idea what the context is [00:48:09] <mru> kierank: someone called merbanan benjamin-san on the ml [00:48:29] <beastd> not it should read: ãã³ãã [00:48:33] <kierank> ah i see it [00:48:50] <kierank> last question: what does the suffix -san mean? [00:48:58] <mru> something japanese [00:49:07] <mru> that's usually all you need to know [00:49:08] <beastd> mr (or ms in depending on the gender) [00:49:12] <Kovensky> japanese has a bunch of suffixes you put after names called "honorifics" [00:49:15] <Kovensky> "-san" is the "default" one [00:49:23] <kierank> I see [00:50:14] <Kovensky> there's, -kun, -sama and a bunch of other ones and they imply a certain relationship between you and the mentioned person, -san is almost always the "neutral" one [00:51:12] <roxfan> suddenly, japanese lessons in my #ffmpeg-devel [00:52:09] <Kovensky> video codec development is anime-driven [00:52:16] <roxfan> true [00:54:16] <BBB> mru: hah, I figured it out, it's squash! [00:54:22] <BBB> mru: can I commit the rest? [00:55:43] <Dark_Shikari> kierank: [00:55:44] <Kovensky> kierank: to make it weirder to westerners, not using any honorifics at all (specially if you're using the person's given name instead of family name) is the most intimate way to refer to someone [00:55:46] <Dark_Shikari> -san (neutral, respect) [00:55:52] <Dark_Shikari> -kun (friend) [00:55:57] <Dark_Shikari> -chan (don't use this unless you're an anime character) [00:56:00] <Dark_Shikari> or you're mocking someone [00:56:11] <kierank> -sama? [00:56:12] <Kovensky> -kun can also be used for subordinates [00:56:16] <Dark_Shikari> -sama (great respect, e.g. to a teacher, leader, etc) [00:56:34] <mru> and the negatives? [00:56:41] <mru> how do you address someone you dislike [00:56:43] <mru> ? [00:56:55] <merbanan> don't answer him [00:57:05] <mru> is there a way? [00:57:10] <mru> I'm just curious [00:57:17] <merbanan> or we will hear him saying it all the day [00:57:19] <Dark_Shikari> I don't think they know what "not being respectful" means. [00:57:19] <Kovensky> AFAIK there's no specific one for that [00:57:24] <Dark_Shikari> they're Japanese [00:57:24] * BBB gives mru the look [00:57:26] <merbanan> lol [00:57:30] <mru> merbanan: come on, I'm not 12 anymore [00:57:41] <mru> Dark_Shikari: I'm not surprised [00:57:45] <BBB> he will say it very specifically to one person [00:58:08] <Kovensky> most of the time when someone is trying to be disrespectful it's either through sarcasm or through disrespectful pronouns [00:58:09] <beastd> well, if you use the wrong suffix or none. or if you use kisama instead of anata (you) ;) [00:58:38] <merbanan> someone go commit the LTP stuff [00:58:49] <Kovensky> beastd watches too much shounen [00:58:50] * Kovensky runs [00:59:14] <BBB> merbanan: ok, will do tonight [00:59:18] <BBB> looking at the bink patch now [00:59:19] <BBB> +dinner [01:02:42] * beastd runs opposite direction [01:18:23] <mru> 52 insertions(+), 111 deletions(-), 30% faster [01:18:50] <mru> qualcomm not so good at optimising... [01:20:37] <kierank> optimising what? [01:20:44] <mru> libjpeg [01:33:05] <bcoudurier> are you optimizing libjpeg ? [01:33:25] <mru> there are those who pay for that [01:33:34] <bcoudurier> rofl [01:33:35] <mru> and it's laughably easy [01:33:45] <bcoudurier> can you optimize zlib ? [01:33:48] <bcoudurier> encoding [01:33:57] <bcoudurier> png is so slow ... [01:34:16] <bcoudurier> although I guess multi frame threading should be implemented [01:34:24] <kierank> optimize iff [01:34:31] <kierank> most important codec [01:37:38] <BBB> wasn't basty doing that? [01:38:01] <bcoudurier> well png is one rgb codec supported by quicktime [01:38:13] <bcoudurier> handy when doing some funky stuff with logo, text etc.. [01:38:23] <kierank> BBB: yes [01:44:07] <BBB> merbanan: there's rob's comment which was not really addressed [01:44:12] <BBB> merbanan: what do I do with it? [01:44:25] <mru> ignore it :) [01:44:30] <BBB> mru: use libjpeg-mmx, part of mjpeg.sourceforge.net/, about 2x as fast as libjpeg with same api [01:44:50] <mru> not on arm [01:44:54] <BBB> (unfortunately only x86) [01:44:55] <BBB> oh [01:44:59] <BBB> I should've known :-p [01:45:17] <mru> there are about 142 different libjpeg forks [01:45:21] <mru> and forks of forks [01:45:23] <BBB> I guess [01:45:25] <BBB> so [01:45:27] <mru> and spoons [01:45:29] <BBB> ignore superdump's comment? [01:45:36] <mru> of course not [01:46:07] <BBB> so not apply? [01:46:56] <mru> I don't even know which patch you're talking about [01:47:03] <mru> ignore me [01:48:38] <kierank> [01:46] mru: there are about 142 different libjpeg forks --> what about wrappers? [01:48:44] <kierank> i know you'd love a nice wrapper mru [01:50:46] <saintd3v> LibJpegKit ? [02:18:21] <BBB> mru: are the vorbis_dec.c cosmetics ok? [02:18:25] <BBB> mru: I merged 1/5+2/5 [02:34:54] <CIA-38> ffmpeg: Alexander Strasser <eclipse7(a)gmx.net> master * r07f06540f6 ffmpeg/libavcodec/vorbis_dec.c: [02:34:54] <CIA-38> ffmpeg: vorbis dec: Delete useless scopes, and reindent after scope deletion [02:34:54] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni(a)gmx.at> [02:34:54] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:35:07] <CIA-38> ffmpeg: Alexander Strasser <eclipse7(a)gmx.net> master * r97f5f97108 ffmpeg/libavcodec/vorbis_dec.c: [02:35:07] <CIA-38> ffmpeg: vorbis dec: cosmetics: Indent CPP cond properly [02:35:07] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni(a)gmx.at> [02:35:07] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:35:09] <CIA-38> ffmpeg: Alexander Strasser <eclipse7(a)gmx.net> master * r4f03c5d793 ffmpeg/libavcodec/vorbis_dec.c: [02:35:09] <CIA-38> ffmpeg: vorbis dec: cosmetics: Indent consistently [02:35:09] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni(a)gmx.at> [02:35:09] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:35:11] <CIA-38> ffmpeg: Alexander Strasser <eclipse7(a)gmx.net> master * r0605cb4332 ffmpeg/libavcodec/vorbis_dec.c: [02:35:11] <CIA-38> ffmpeg: vorbis dec: Remove obsolete comment [02:35:11] <CIA-38> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni(a)gmx.at> [02:35:11] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:35:15] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rb0294c80d3 ffmpeg/libavformat/ (avformat.h version.h): [02:35:15] <CIA-38> ffmpeg: lavf: deprecate AVFormatContext.index_built [02:35:15] <CIA-38> ffmpeg: it's not touched anywhere in ffmpeg, the code setting it was removed [02:35:15] <CIA-38> ffmpeg: over two years ago (e9b78eeba22b050810a507e69df1b652e56ab62b). [02:35:16] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:53:19] <barspi> hi kids, it's me again! this time trying to report an apparent bug in the configure script for the case when you are compiling for darwin/arm and you need the gas-preprocessor.pl [02:53:39] <barspi> anyone around who is responsible for the configure script? [02:57:41] <barspi> I think mru could be the guy :-) [03:00:25] <mru> describe the problem [03:01:05] <barspi> I'm trying to compile for iphone with the gas-preprocessor (this works in the 0.6.1 version, but the configure script in HEAD has changed) [03:01:10] <barspi> in particular this line: [03:01:24] <barspi> if enabled asm; the [03:01:25] <barspi> as=${gas:=$as} [03:01:36] <barspi> I had to turn around the default [03:01:44] <barspi> as=${as:=$gas} [03:02:09] <barspi> because otherwise it ignores the âas parameter I give [03:02:23] <barspi> it just tries to use the hardcoded $gas instead of my --as [03:02:59] <barspi> if I modify this line, it works perfectly [03:03:35] <mru> what are you setting with --as? [03:03:54] <mru> your change will break when the defaults (without --as) are ok [03:03:55] <barspi> ./gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1 [03:04:05] <barspi> I'm sorry ../gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1 [03:04:38] <mru> why? [03:04:56] <barspi> but the thing isâŠ If I explicitly pass a âas "bla bla bla" parameter, shouldn't use mine instead of the internal, hardcoded gas variable? [03:05:11] <mru> does the default not work? [03:05:29] <barspi> nopeâŠ. [03:05:30] <barspi> GNU assembler not found, install gas-preprocessor [03:05:30] <barspi> If you think configure made a mistake, make sure you are using the latest [03:05:34] <barspi> etc etc [03:05:57] <mru> your suggested change is wrong either way [03:06:03] <barspi> the hardcoded one tries to use $cc instead of arm-apple-darwin.xxxxx [03:06:13] <mru> and what is $cc? [03:06:24] <mru> it should work [03:06:41] <barspi> I don;t claim to undersand all the subtleties of what's going onâŠ but the default just doesn't work and if I use my old and trusty âas configuretion it does work [03:06:49] <barspi> let's see [03:07:28] <barspi> this is my âcc='/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv6' [03:07:52] <mru> that should work [03:08:15] <barspi> then, the new configure does [03:08:17] <barspi> darwin) [03:08:17] <barspi> enable malloc_aligned [03:08:17] <barspi> gas="gas-preprocessor.pl $cc" [03:08:22] <mru> I know that [03:08:25] <mru> that's intentional [03:08:31] <barspi> it hardcodes it.. and completely ignores whatever âas I pass on the command line [03:08:55] <barspi> I'm not against having a "hardcoded default" (either one that works or not), but it should let me use my --as [03:09:06] <mru> why do you need to use --as? [03:10:01] <barspi> wellâŠ it's the one that works :-) it's the way to do it that appears all over the internet for the last couple of years as the "way to build ffmpeg for ios devices" [03:10:19] <mru> those instructions are old and wrong [03:10:21] <barspi> you must use the gas-preprocessor, and bla bla bla and use configure with all those parameters [03:10:49] <barspi> they may be old but they work and the default doesn't :-( [03:11:02] <barspi> at least for certain (mine?) cases [03:11:55] <barspi> this is a clean git clone, with a gas-preprocessor.pl installed, on an up-to-date mac, with the latest Xcode installed in the standard apple-santified way [03:12:21] <barspi> i think I don't have any special configuration... [03:12:35] <barspi> and it's been compiling like that (ffmpeg 0.6.x) for several months [03:12:45] <barspi> but the new configure script fails :-( [03:12:46] <mru> 1) find someone who can touch a mac without puking (i.e. not me), 2) explain the problem _in detail_, 3) hope for a solution [03:13:33] <barspi> ohâŠ I just thought you were the one who added that line because of http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2010-July/030747.html [03:14:41] <mru> that doesn't mean I'll go anywhere near a mac [03:15:10] <barspi> I won't question that :-) [03:16:00] <barspi> my question is about the reason of not letting me define my own âas (if I don't, it's ok to use a working/non-working/sometimes-working default) [03:16:21] <barspi> but if I *do* explicitly use âas, I should be able to use mine and not the hardcoded one [03:16:40] <barspi> like the rest of the cofnigure script (I can provide my own cc, or my own prefix directories, etc) [03:16:48] <mru> if you're a mac user you should be used to doing as you're told [03:17:05] <barspi> haha [03:17:22] <barspi> I'm not completely a mac user, but i'm developing mac/ios apps :-) [03:17:46] <mru> that's unfortunate for you [03:18:45] <astrange> BBB: could you look for the reason in encoding why MPV_frame_end gets called but ff_draw_horiz_band doesn't? or rather, the draw_edges bits of them don't [03:20:35] <barspi> there's an interesting idiosyncrasy in the ffmpeg community of avoiding/evading a problem with answers of the kind "you are doing it wrong" (very Steve Jobsy I must say) [03:20:53] <Yuvi> barspi: put gas-preprocessor in /usr/local/bin or similar? [03:21:05] <barspi> hmm I'll try that Yuvi [03:21:23] <barspi> so far I had it in the project root, and the one above it (from where I call the build script) [03:21:50] <astrange> does llvm-mc do ARM yet? [03:22:05] <mru> mc? [03:22:10] <Yuvi> there's work on it [03:22:12] <Yuvi> haven't tried it [03:22:34] <astrange> the llvm gas replacement [03:22:38] <astrange> guess it stands for machine code [03:24:52] <barspi> Yuvi: I put the gas-preprocessor on the path and it seems to be working [03:25:40] <mru> you're right that an explicit --as should take precedence, but I can't think of a sane way to do that [03:25:59] <mru> and when building for ios, using $cc is the only thing that will work anyhow [03:26:16] <barspi> stilâŠ if I'd like to *explicitly* use âas 'stupid-preprocessor /stupid/path/to/non/working/asm/just/for/fun' I should be able to do it [03:26:53] <mru> I agree in principle [03:26:55] <barspi> doesn't it work as all the other defaults? (if it's given in the command line, use that one, if not, use default?) [03:27:00] <mru> but in practice you'll never need to do that [03:29:06] <barspi> I may want to use a different version of gcc/asm for a different SDK or architecture or whatever [03:29:17] <mru> that would be ill-advised [03:29:34] <mru> mixing versions is not a good idea [03:32:04] <barspi> okâŠ want to see more fun stuff? ;-) [03:32:28] <barspi> using the default configure file, putting gas-preprocessor.pl under /opt/local/bin (which is in the path) [03:32:33] <barspi> -rw-r--r-- 1 barspi staff 625456 Feb 11 01:31 libavcodec.a [03:32:39] <barspi> I'm sorry [03:32:47] <barspi> -rw-r--r-- 1 barspi staff 944208 Feb 11 01:26 libavcodec.a [03:32:57] <barspi> so, 944K for the libavcodec.a [03:33:09] <mru> so? [03:33:24] <barspi> using my modified configure (which calls '../gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1') [03:33:32] <barspi> the libavcodec.a measures 625K [03:33:41] <barspi> (the line i copied first) [03:33:50] <mru> means nothing [03:33:52] <barspi> so arm-apple-darwin.xxxx must be doing some better optimizations [03:33:56] <barspi> than jsut using gcc [03:34:05] <barspi> means the file is 2/3 the size [03:34:21] <mru> no [03:34:28] <barspi> no? [03:34:48] <mru> the only difference is what assembles the .S files [03:34:57] <mru> those are not touched by the optimiser [03:35:18] <mru> I suspect you have different amount of debugging symbols or similar [03:36:10] <barspi> the point is: by specifying my own âas line (and having the configure script respect that), the file is 2/3 the size of what I get when using the default hardcoded configure [03:36:20] <barspi> everything else is the same [03:36:32] <Compn> how did you come to the conclusion that smaller = more optimized ? lol [03:36:43] <barspi> I'm not sure how all the internal stuff is working [03:36:54] <Compn> you should benchmark it to see which is faster [03:36:58] <barspi> in my particular case smaller == better [03:36:59] <Compn> instead of guessing [03:37:08] <Compn> and coming in here and guessing at that... [03:37:29] <mru> there are two possible explanations: [03:37:33] <barspi> it's like talking to a stone wall or some character form alice in wonderland [03:37:37] <mru> 1) the smaller one is missing debugging symbols [03:38:03] <mru> 2) the smaller one is missing large numbers of asm functions [03:38:19] <mru> if 1, there's no problem [03:38:23] <mru> if 2, you have a problem [03:38:24] <barspi> I'm using exactly the same configure line in both cases (exactly the same enabled/disabled options) [03:38:43] <mru> compare the final stripped binaries instead [03:38:51] <Compn> well the configure line means nothing, you have to compare the configure.log [03:38:58] <Sean_McG> does the apple linker do deadstripping? [03:39:25] <barspi> the *only* difference is that by using the obligatory hardcoded âas I get one file, and by using my own specified âas I get a different result (a better one for my case, but that's besides the point) [03:39:50] <barspi> the point being, if the user provides âas, let him have it [03:40:02] * mru suspects the "better" one is failing and thus disabling all asm [03:40:02] <barspi> if the user doesn't provide âas, do whatever you want in the script :-) [03:40:45] <barspi> I'll test that suspiction later [03:40:54] <Yuvi> Sean_McG: only with .subsections_via_symbols which the .S files don't set [03:41:03] <barspi> in my particular case, i want small size, I don't care much about performance [03:41:23] <Sean_McG> Yuvi: ah... yeah and I was thinking it's probably hard to deadstrip a library [03:49:42] <Yuvi> astrange: looks like llvm-mc for arm doesn't really work at all [03:50:59] <barspi> ok, for all the naysayersâŠ I've hardcoded most stuff so the *aboslutely only difference is what I'm passing to gas-preprocessor.pl' [03:51:05] <barspi> original configure script from git clone will do [03:51:06] <barspi> gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv6 [03:51:06] <barspi> libavcodec.a size 944K [03:51:18] <barspi> hardcoding the variable gas to what I wanted: [03:51:19] <barspi> gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1 [03:51:19] <barspi> libavcodec.a size 625K [03:51:34] <barspi> . . . *everything else* is equal. the only difference is the parameter to gas-preprocessor.pl [03:51:35] <barspi> Will both versions *perform* with equal speed/cpu consumption? I'll tell you in a while :-) [05:35:12] <barspi> http://xkcd.com/386/ [05:51:55] <bcoudu> yo guys [05:52:17] <bcoudu> who is motivated to write some code to compute the poc in the h264 raw demuxer ? :) [05:53:37] <_av500_> poc? [05:54:17] <Dark_Shikari> bcoudu: what do you need poc for? [05:54:27] <bcoudu> compute the pts [05:54:42] <Dark_Shikari> why do you need to compute it? [05:54:45] <Dark_Shikari> just call the header parser [05:54:47] <bcoudu> stream copy [05:54:53] <Dark_Shikari> call the header parser [05:55:01] <Dark_Shikari> doesn't it already do that? [05:55:08] <bcoudu> nope [05:55:15] <_av500_> i guess he wants the reordering [05:55:28] <bcoudu> I guess the parser could do it [06:07:13] <thresh> moroning [06:16:55] <_av500_> (good morning [06:28:23] <kshishkov> mate! [06:28:52] <pross-au> G'day [06:29:58] <kshishkov> where's an updated patch, I'm eager to have official BIK-b support [06:30:31] <_av500_> kshishkov: but what are we going to talk here about then? [06:30:56] <kshishkov> DNF is not released yet [06:31:06] <_av500_> but soon, no? [06:31:29] <kshishkov> and there are some other game video codecs - from Z for example [06:31:58] <drv> bink B has different audio too IIRC [06:51:25] <thresh> _av500_: what max bitrate would you suggest for 720p h264 on 101? [06:51:52] <thresh> bloody thing is slow with raw h264 mp4 from my camera :) [06:54:50] <_av500_> thresh: is your cam 60fps? [06:54:52] <_av500_> some are [06:54:56] <_av500_> thats too much [06:55:11] <thresh> _av500_: well it can shoot in 60fps, but i'm using 720p@30 [06:55:19] <_av500_> thresh: its not only bitrate, also the tools [06:55:24] <_av500_> and num ref frames and such [06:55:50] <thresh> I see, I'll doublecheck the params [06:59:27] <elenril> lol@today's xkcd [06:59:30] <elenril> also morning [07:11:48] <thresh> _av500_: yeah a tiny bit slow with 8000kbit/s Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 8029 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc [07:12:00] <thresh> I wonder if VLC would be better [07:12:06] <thresh> oh wait there is no VLC :( [07:22:23] <superdump> ? [07:26:32] <thresh> superdump: there is not VLC for google evil OS [07:26:49] <thresh> -t [07:28:26] <superdump> ah [07:28:57] <superdump> well i assume that it is possible to build an apk for personal use [07:31:28] <av500> thresh: less mbit please [07:31:46] <av500> thresh: j-b is working on vlc for evilOS [07:31:57] <av500> but it wont use the dsp and stuff [07:32:37] <thresh> iKnow [07:34:18] <thresh> well they said there is an API to use OpenMAX, but barely documented [07:45:40] <ubitux> i'm working on a XM demuxer/decoder, do you know if anyone is on it? and if no, if it's worth the effort? [07:46:24] <ubitux> (fasttracker II, some kind of common mid) [07:56:42] <siretart> ubitux: wow, that reminds me of old times... [07:57:01] <siretart> ubitux: IIRC, there was a GSoC project for midi/tracker files [07:57:12] <ubitux> oh? [07:57:18] <ubitux> and what comes out? [07:57:25] <av500CDGS> nuthin [07:57:27] <siretart> sorry, I didn't follow it [07:57:47] <av500CDGS> the amiga asm code converted to C never made it into any repo [07:58:57] <ubitux> i'm worried about a few things, especially that kind of things: The above formulas DO work as long as you don't replace "*2^" by "shl" (the result of 2^(...) is a floating point number). [07:59:13] <av500CDGS> run [07:59:15] <ubitux> (formula is: Frequency = 8363*2^((6*12*16*4 - Period) / (12*16*4))) [07:59:29] <ubitux> but well, i want to do it :p [07:59:42] <av500CDGS> ubitux: you need to have libavseq 1st [07:59:53] <av500CDGS> ubitux: its all on the mailing list from last summer [08:00:37] <av500CDGS> ubitux: http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2010-July/009403.html [08:01:29] <ubitux> mmmh ok [08:02:13] <ubitux> i just wanted to support XM but i guess it won't be accepted with a proper libavsequencer integration in parallel? [08:04:27] <siretart> ubitux: I guess that depends. and surely nobody would mind if you would develop it in a developer branch/repository [08:06:17] <av500> ubitux: well, the gsoc guy had like million lines of code that he wanted to dump into ffmpeg, so having it all restructured and put into a proper lib was the only way [08:06:34] <spaam> av500 ubitux : with avseq. ffmpeg source code will be twice the size.. [08:06:50] <av500> spaam: if you add all the different formats, yes [08:07:06] <spaam> av500: ofc. [08:07:17] <spaam> we cant leave some formats alone. ;) [08:07:25] <spaam> :) [08:10:01] <spaam> ubitux: and basty did have a amiga group called CDGS.. he was the only member. [08:11:10] <ubitux> wellâŠ is it worth the effort trying to get libavseq upstream so i can add just a xm format? [08:11:26] <ubitux> i don't think there is much point in trying to add more than midi and xm [08:11:35] <av500> what about MOD? [08:12:02] <ubitux> i don't know [08:12:28] <spaam> ubitux: https://github.com/BastyCDGS/ffmpeg-soc/tree/master/libavsequencer [08:12:36] <spaam> his code [08:12:47] <ubitux> yes i saw that [08:13:15] <ubitux> av500: well yeah maybe, there are 1538 XM and 375 MOD in the keygenmusic pack [08:13:39] * av500 has no idea about procedurally generated music [08:18:24] <kshishkov> av500: it's called MPEG-4 SAOL [08:18:52] <kshishkov> IIRC reference implementation reads input and generates C program for generating output [08:19:32] <av500> damn, so we need ffcc before we can implement it [08:24:15] <kshishkov> not necessarily - we can just use some bytecode [08:28:45] <thresh> epic fail for nokia today [08:30:08] <kshishkov> after epic success yesterday? [08:30:20] <thresh> not really [08:30:30] <thresh> they dumped meego and going for windows phone [08:30:47] <kshishkov> first part is epic success, the second is epic fail [08:31:07] <thresh> well almost anything is better than windows phone [08:31:08] <av500> what is epic success? [08:31:17] <kshishkov> ditching meego [08:31:30] <av500> ture [08:31:32] <av500> true even [08:32:23] <cartman> moin [08:32:31] <kshishkov> grÃŒÃ dich [08:32:50] <kshishkov> cartman: and when you greet KotH use word "moinli" [08:34:12] * kshishkov lols at todays Dilbert [08:34:30] <cartman> KotH: gÃŒnaydÄ±n! [08:34:47] <cartman> lol indeed [08:34:58] <kshishkov> cartman: he's in .ch, use "gÃŒnaydÄ±nli" [08:35:03] <cartman> :D [08:40:52] <spaam> kshishkov: how does it go with rewrite of rm*.c? :) [08:42:44] <kshishkov> spaam: only rm rm*.c works for a moment [08:46:19] <spaam> maybe you should add "buffering..." stuff in the code. then everything should work? :) [08:47:26] <j-b> waouw -mt is getting merged? FFX 4 is going out soon, with DNF mode, too? [08:49:10] <thresh> j-b: some say ffmpeg devs heard about Duke Nukem Forever coming out, and they wanted to be faster in merging -mt [08:49:38] <j-b> thresh: there are no other rationale explanation [08:50:13] <kshishkov> since DNF release was a major deadline term we should see a lot of activity soon [08:50:24] <KotH> günaydin arkadaslar! [08:50:35] <spaam> kshishkov: working rm stuff ? ;D [08:51:01] <KotH> can someone help a blind man find the documentation of the gas .code directive? [08:52:02] <kshishkov> spaam: not even thinking about it [08:52:57] <spaam> KotH: ask our wonderful friend MÃ¥ns [08:53:12] <spaam> kshishkov: come on. you can get a trocadero for it ;) [08:54:06] <KotH> spaam: the blind man found it himself after stumbling in the dark for hours [08:54:26] <kshishkov> spaam: unlikely. Though I'd like to come and buy some at any HemkÃ¶p/ICA/Coop/Prism/whatever [09:02:38] <cartman> KotH: do you know Adnan Hodjca? [09:02:43] <cartman> s/c// [09:02:55] <KotH> nope [09:03:04] <cartman> KotH: Harun Yahya?! [09:03:08] <KotH> though i think i've heard the name somewhen [09:03:17] <cartman> the man who denies the Darwin and evolution [09:03:30] <KotH> ah.. now that rings a bell! [09:03:41] <cartman> KotH: http://alkislarlayasiyorum.com/icerik/43884/ [09:03:46] <av500> cartman: the email client? it exists!!! [09:03:59] <cartman> av500: he is now an email client too? :D [09:04:12] * KotH will watch taht at home [09:04:26] <cartman> its an mp3 ;) [09:04:52] <spaam> astrange: gj with -mt btw :) [09:16:45] <spaam> BBB astrange : whats left to get h264-mt stuff commited? :) [09:21:22] <cartman> nice [09:21:26] <cartman> all VP8 tests broken [09:22:20] <Dark_Shikari> just on clang? [09:22:42] <cartman> seems so [09:24:01] <cartman> now to debug that ahem [09:36:35] <cartman> Dark_Shikari: [09:36:38] <cartman> its your commit [09:36:47] <cartman> VP8: optimized mv prediction and decoding [09:37:08] <saintdev> STRING HIM UP [09:37:09] <saintdev> =P [09:37:10] <Dark_Shikari> I know. [09:37:19] <cartman> bisect rocks :P [09:37:20] <Dark_Shikari> It's not my fault that a shitty compiler fails on my nice patch. [09:37:24] <Dark_Shikari> Er, you didn't need bisect [09:37:28] <Dark_Shikari> I figured that out in 7 seconds [09:38:05] <spaam> cartman: 2slow [09:38:07] <cartman> Dark_Shikari: nice now fix it [09:38:12] <cartman> clang is not your mom's compiler [09:38:14] <Dark_Shikari> I could care less about clang [09:38:23] <Dark_Shikari> get clang devs to fix the bugs in their compiler [09:38:25] <cartman> nice attitude [09:38:36] <Dark_Shikari> nobody actually compiles ffmpeg with clang [09:38:38] <Dark_Shikari> so it's not a user-facing issue [09:38:40] <cartman> huh? [09:38:40] <cartman> wtf [09:38:44] <cartman> even mru does [09:38:48] <Dark_Shikari> Sure, for FATE [09:38:50] <Dark_Shikari> Not for real usage [09:38:51] <bilboed-tp> or file a bug report with clang/llvm [09:38:59] <Dark_Shikari> I'll leave it to a clang-related person to fix. [09:39:06] <Dark_Shikari> I don't even have it installed. [09:39:07] <cartman> sigh [09:39:13] <Dark_Shikari> And installing clang on win32 is probably hard [09:39:17] <Dark_Shikari> I don't think I could get it to work last time I tried [09:39:21] <cartman> ok [09:39:36] <Yuvi> near_mv isn't guaranteed to be 32-bit aligned [09:39:57] <Dark_Shikari> yes it is [09:40:00] <Dark_Shikari> typedef struct { int16_t x; int16_t y; [09:40:01] <Dark_Shikari> } DECLARE_ALIGNED(4, , VP56mv); [09:40:10] <Yuvi> ah [09:49:33] <Dark_Shikari> does AV_RN/etc use alias intrinsics on clang? [09:49:52] <superdump> mru: re: those rockbox patches - i think one can run configure through the Android.mk [09:51:11] <Yuvi> I don't think llvm has aliasing optimizations that would break even *(uint32_t*) [09:53:08] <av500> superdump: i guess you could touch a .configured or so [09:57:42] <pross-au> CD pross-au [09:57:48] <pross-au> oops [09:59:07] <kshishkov> bink? [10:01:40] <pross-au> Ah, yes, i gotta run another test [10:01:49] <pross-au> i have incorporated your changes ksh [10:02:27] <pross-au> whats this about bink-b audio? [10:02:47] <kshishkov> dunno [10:03:52] <kshishkov> I don't remember having any problems with audio there [10:04:59] <pross-au> How does it feel, to be the King Bink [10:06:09] <kshishkov> good - we beat RAD tools by the number of supported Bink versions :) [10:06:56] <pross-au> to be fair [10:07:02] <pross-au> there are dct coefficient overflows [10:07:03] <kshishkov> and it supports our reputation as ultimate game video convertor [10:07:09] <pross-au> (which im working on) [10:07:14] <kshishkov> yay! [10:07:56] <Tjoppen> what other interesting game formats are left? [10:08:03] <kshishkov> tons [10:08:05] <pross-au> Yeah finnishing off the Z video decoder is important to me [10:08:23] <av500> kshishkov: what about the Pong game format? [10:08:52] <kshishkov> pross-au: aha, incoming/bink/NWCLOGO.BIK has totally scrambled sound [10:08:53] <av500> can ffmpeg play that pong sound when you feed it the wikipedia article about it? [10:09:13] <kshishkov> av500: why should it? [10:09:30] <pross-au> kshishkov: okay [10:09:32] * kshishkov remembers we don't have 16-bit VQA support either [10:09:55] <Tjoppen> the pixel format choosing logic for auto-inserted filters needs improving [10:10:15] <pross-au> SMUSH [10:10:29] <pross-au> ^ that's a popular format [10:10:33] <Tjoppen> I just discovered that cropping uyvy422 causes ffmpeg to auto-convert the video to yuv420p rather than yuv422p [10:10:34] <kshishkov> iKnow [10:11:01] <kshishkov> pross-au: patch is on the list, hopefully I'll rewrite it with current coding standards in mind [10:11:17] <kshishkov> and I want Discworld Noir cutscenes support [10:11:19] <merbzt> Tjoppen: colorspace negotiation might be a NP complete problem :) [10:11:22] <Tjoppen> similarly for mjpeg (and probably other codecs) where it prefers choosing yuvj420p rather than yuvj422p because the former is first in the pixel format list [10:11:40] <pross-au> Cool [10:11:51] <kshishkov> merbzt: it doesn't matter much [10:11:57] <Tjoppen> merbzt: actually, no :) [10:12:25] <Tjoppen> just pick whichever has the same or higher subsampling [10:12:34] <Tjoppen> higher as in, prefer 4:4:4 to 4:2:0 [10:12:49] <Tjoppen> if 4:2:2 is unavailable [10:13:23] <Tjoppen> there are corner cases I guess, like 4:2:0 vs 4:1:1 [10:15:01] <kshishkov> 420 is better [10:18:11] <Tjoppen> depends on what your target codec is. but in that case maybe it'd pick the appropriate pixel format [10:21:31] <kshishkov> yes, that's the case - format negotiations should be started from the last filter [10:30:56] <Tjoppen> my use case is simple: crop vbi lines from uyvy422 rawvideo [10:35:51] <Tjoppen> I suspect vf_crop.c shouldn't have much trouble handling that colorspace though, since it already handles rgba [10:50:23] <Tjoppen> woo [10:50:37] <Tjoppen> adding PIX_FMT_UYVY422 to vf_crop.c was enough :) [10:51:47] <Tjoppen> I discovered a possible bug though - going via yuv422p caused the output to differ. shouldn't going uyvy422 -> yuv422p and back just rearrange the bytes? [10:52:22] <Tjoppen> a few pixels in each frame ended up with +-1 luma [10:52:57] <merbzt> it probably took a detour through libswscale [10:53:37] <Tjoppen> yes, I know that [10:54:18] <merbzt> rm libswscale * [10:54:18] <Tjoppen> question is, why did swscale mess up? [10:54:39] * Tjoppen looks at swscale_template.c and cries a little [10:55:22] <merbzt> I assume it actually performed a resample step [10:56:37] <merbzt> and then rounding causing the diff [10:58:12] <Tjoppen> makes sense [10:58:22] <kshishkov> unlike swscale sources [10:58:24] <Tjoppen> I presumme sws doesn't have regressions [10:58:39] <kshishkov> it has [10:58:48] <kshishkov> there is swscale-test.c [10:59:10] <kshishkov> it calculates difference on different rescaling and/or converting operations [10:59:33] <kshishkov> but it's "too long; didn't run" situation [11:00:15] <kshishkov> and there's that lavf-pixfmt test probably [11:00:30] <Tjoppen> I'd image it being very useful to make sure things like 8bit -> 16bit -> 8bit results in the same output. the same for repacking conversions like uyvy <-> 422p and uyyvyy <-> 411p [11:01:07] <Tjoppen> but then again, I fear swscale isn't built to be able to easily plug in alternate algorithms for certain cases [11:02:18] <kshishkov> s/to easily plug in alternate algorithms for certain cases// [11:03:01] <Tjoppen> heh [11:04:04] <kshishkov> I've dabbled a bit in its sources [11:04:04] <Tjoppen> I was a little bit inspired to come up with a runtime optimization thing based on a paper me and a friend implemented for optimizing boolean operations on compressed binary indexes in databases. the ideas are similar [11:04:44] <Tjoppen> it's a little hard to explain though.. but basically revolves around selecting appropriate formats in each step so cetains algorithms can be chosed [11:04:47] <Tjoppen> *chosen [11:05:02] <Tjoppen> then you choose between optimizing for speed or quality [11:05:03] <kshishkov> patchiswelcome [11:05:28] <Tjoppen> yeah, it's not happening any time soon :) [11:05:41] <pross-au> AVPATCHISWELCOME [11:05:46] <kshishkov> polish your Cinepak encoder then [11:05:58] <kshishkov> pross-au: that's applicable to you as well [11:06:35] <Tjoppen> well, a side project I have now is to write an encoder for my atari video decoder. it outputs 128 colors at the amazing resolution of 8x6 pixels [11:07:32] <Tjoppen> with self modifying code I might be able to cram it up to 10x8 or so [11:07:57] <kshishkov> use RNG [11:24:08] <Tjoppen> feeding the decoder with its own machine code produces intersting results [11:29:03] <j-b> av500: http://magsoft.dinauz.org/videolan/vlc-android/vlc-android-archos101.3gp [11:33:49] <av500> j-b: nice!!!! [11:34:10] <av500> please make sure you use only this product for all publicity vids you make :) [11:34:24] <av500> j-b: and please use the intent to hide the buttons [11:34:38] <j-b> av500: well, this is very likely the reference board for us, so yes. [11:34:49] <av500> :) [11:34:56] <j-b> av500: and I couldn't understand your last sentence [11:34:59] <j-b> intent? [11:35:11] <av500> I gave you once what you need to do to hide our buttonbar [11:35:15] <kshishkov> av500: do you have your players with non-glare screens? [11:35:25] <av500> kshishkov: you can always sandblast them [11:35:29] <j-b> av500: and I forgot :) [11:35:32] * j-b is b ad [11:35:40] <superdump> j-bad? [11:35:51] <j-b> :) [11:36:21] <superdump> it was good to finally meet you at fosdem j-b, though it was only brief and i don't think you really got my name as it was a big group [11:36:32] <superdump> so perhaps s/meet/see/ [11:37:01] <j-b> I know your name and see who you are :) [11:37:19] <superdump> then meet it is :) [11:37:23] <av500> j-b: did you see Diego or you missed him again? [11:37:44] <j-b> av500: I did! [11:37:47] <j-b> incredible? [11:37:54] <merbzt> I missed j-b :/ [11:38:04] <kshishkov> did he agree to proofread French in VLC sources? [11:38:07] <merbzt> and f revol [11:38:15] <j-b> kshishkov: :) [11:38:22] <kshishkov> merbzt: Revol was at Haiku stand so no wonder [11:38:42] <av500> he was waiting for ffmpeg to compile all the time [11:38:59] <av500> j-b: see you pm and print and frame it [11:39:03] <av500> your [11:39:07] <kshishkov> j-b: I'm pretty sure we also talked at FOSDEM but were not properly introduced to each other [11:39:31] <j-b> kshishkov: I'm French, i don't need "proper introduction" :D [11:39:37] <j-b> av500: forwarded to the right guys [11:40:06] <kshishkov> j-b: well, I consider any VLC guy to be French by default [11:40:42] <bilboed-tp> don't they have some swiss, belgian and quebec people also ? :) [11:40:53] <superdump> j-b: one time i was on-site with a french client and they did this thing where anyone visiting went around the whole room, said hello to and shook hands with everyone [11:41:24] <av500> superdump: yes, they do that [11:41:25] <j-b> kshishkov: lol. This isn't true. We have .de, .fi, .nl and .uk in the core team. [11:41:26] <superdump> it was quite strange considering every single one of them were not seen again throughout the day [11:41:47] <kshishkov> j-b: .de? As Jean-Paul .de? [11:41:53] <av500> superdump: same when I visit our paris HQ, everybody comes in shakes hand in the morning [11:42:09] <superdump> some people were abstaining because of swine flu :B [11:42:16] <j-b> kshishkov: Felix [11:42:22] <av500> while I just sit there any try to wake up [11:42:36] <bilboed-tp> superdump, is that when they kiss instead of shaking hands ? [11:42:48] <superdump> bilboed-tp: french kiss! [11:43:03] <bilboed-tp> no, not that one [11:43:07] <bilboed-tp> the cheek kiss [11:43:09] <bilboed-tp> la bise quoi [11:43:37] <j-b> av500: they will add it to the next build [11:43:51] <superdump> j-b: is there some semi-offical vlc ppa for ubuntu? [11:44:15] <j-b> superdump: https://launchpad.net/~videolan/+archive/master-daily ? [11:44:15] <kshishkov> superdump: ask next about autotools [11:44:50] <superdump> ha [11:45:26] <superdump> j-b: i mostly wanted 'most recent release as ubuntu's package is out of date' [11:45:33] <superdump> but hey, dailies will do [11:46:03] <j-b> superdump: sudo add-apt-repository ppa:n-muench/vlc will get the stable version [11:46:18] <superdump> ta [11:48:17] <uau> superdump: are you doing some kind of player comparison? [11:49:05] <superdump> i just find that it is useful to have multiple players around when testing stuff [11:49:08] <superdump> not using it right now [11:53:41] <uau> btw does any player other than mplayer2 use ffmpeg frame discarding functionality for exact seeks? [11:53:55] <uau> adding the exact seek support uncovered a bug in ffmpeg-mt at least [11:54:53] <bilboed-tp> what do you mean by "frame discarding functionality" ? [11:55:53] <av500> seek to non-iframe I guess [11:56:04] <uau> bilboed-tp: the skip_frame field, to speed up decoding from keyframe to the target frame [11:56:07] <av500> seek to previous iframe and drop all frames up to ... [11:56:20] <j-b> uau: vlc --ffmpeg-skip-frame [11:56:26] <bilboed-tp> uau, yah, we use it in gst-ffmpeg, works fine [11:57:37] <bilboed-tp> oh wait, no [11:59:43] <uau> j-b: that's constantly-on framedrop? [12:00:33] <uau> with probably really ugly result as frames are dropped at an uneven rate? [13:05:00] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * re00f41d574 ffmpeg/ (5 files in 3 dirs): [13:05:00] <CIA-38> ffmpeg: Bink version 'b' video decoder [13:05:00] <CIA-38> ffmpeg: Based on original patch by Kostya Shishkov [13:05:00] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [13:05:10] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * radb1ad0d80 ffmpeg/libavcodec/bink.c: [13:05:10] <CIA-38> ffmpeg: bink: reindent after last commit [13:05:10] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [13:05:20] <jannau> kshishkov: bink-b pushed \o/ [13:05:28] <kshishkov> jannau: oink! thank you [13:09:03] * Flameeyes laughs at all those people deluding themselves in thinking Nokia was interested in free software for freedom, or those who call for Nokia to bankrupt for "selling" to MS. [13:09:20] * av500 joins in [13:10:26] <Flameeyes> although I have to say it's bitter laughs [13:10:42] <Flameeyes> mostly because these people think they can shape the world â without factoring in business sense and requirements [13:23:55] <j-b> Flameeyes: well, the upside for MS is amazing, with almost NO risk. While for Nokia, the upside is more than limited... [13:24:11] <Flameeyes> j-b: depends what you count as baseline [13:24:30] <Flameeyes> baseline "what nokia promised", yes there is little upside, same goes for "how nokia appears to kde guys" [13:24:51] <Flameeyes> but baseline "what nokia really is" and "how common people feel about nokia", upside is far from limited [13:25:30] <j-b> Flameeyes: oh, I don't care about FOSS here. At ALL. [13:25:38] <Flameeyes> seriously, they obsoleted an â¬650 phone in three months? [13:25:52] <mru> cartman: vp8 tests pass with clang -O1, fail with -O2 [13:26:04] <j-b> Flameeyes: Nokia wins almost nothing from a WP7, which is a very very small platform. M$ Wins huge on that [13:26:43] <Flameeyes> j-b: people like Nokia phones but hate the software... this will at least give them a chance [13:26:50] <Flameeyes> but yes, I see that the next move might actually be a merger [13:27:13] <cartman> mru: optimifail [13:27:17] <kshishkov> and there was VLC for WinCE so j-b cannot care less [13:27:39] <j-b> Flameeyes: well, they didn't even managed to force M$ to allow native code and the ovi store... [13:27:47] <j-b> kshishkov: there still is. Just no interface. [13:27:53] <mru> cartman: could still be an ffbug [13:28:06] <cartman> mru: sure :) [13:28:52] <Flameeyes> j-b: not sure how bad would be for the ovi store to be missing, ya know [13:30:14] <j-b> Flameeyes: well, they just killed the whole ecosystem, while they could have asked for some counterparts [13:30:44] <av500> Flameeyes: obsoleted what 650â¬ phone? [13:30:46] <Flameeyes> j-b: I think for Nokia was either that or filing for bankrupcy [13:30:47] <av500> the n900? [13:30:49] <Flameeyes> av500: E75 [13:31:00] <mru> the n900 was obsoleted in 3 weeks [13:31:11] <thresh> +1 [13:31:12] <av500> Flameeyes: why is it obsolete? [13:31:28] <jannau> symbian is dead [13:31:30] <j-b> Flameeyes: bankrupcy? I hope you are kidding. Numbers are falling down, but are still high [13:31:40] <j-b> jannau: and Meego too now [13:31:50] <j-b> not that I particularly care [13:31:54] <Flameeyes> av500: [beside the fact that it's bloody fragile] about three months after the italian release date, they released Ovi Maps... but it didn't cover E75 at all.. [13:31:54] <av500> Flameeyes: why is it obsolete? [13:31:58] <mru> nokia will on making "feature phones" for teenagers [13:32:02] <mru> +keep [13:32:08] <Flameeyes> on the other hand they covered the much cheaper E72 [13:32:13] <av500> ic [13:32:26] <Flameeyes> and the E75 was a failure under many povs [13:32:29] <av500> but that sounds like typical $random phone maker decision [13:32:41] <Flameeyes> that's the typical Nokia decision [13:32:50] <jannau> s/phone maker/big company/ [13:33:00] <j-b> +1 [13:33:15] <j-b> av500: doesn't change much for us... Android is the clear winner [13:33:29] <thresh> but it sucks [13:33:37] <av500> j-b: I did you fear for VLC at all :) [13:33:40] <mru> android sucks less with each update [13:33:51] <av500> so its like windows :) [13:33:56] <mru> and apple are clearly afraid of it [13:34:05] <mru> apple are safe of course [13:34:08] <j-b> av500: I don't fear for VLC. Why should I? [13:34:10] <mru> they have their loyal fans [13:34:26] <av500> j-b: [14:33:15] <j-b> av500: doesn't change much for us [13:34:42] <thresh> I only have 2.2 on this device [13:34:48] <thresh> youknowho, gimme 3.0 :P [13:35:07] <j-b> av500: yes, not much changes so, I can't fear. [13:35:19] <j-b> av500: and this isn't even my $day_job [13:35:27] <j-b> even though i would love to [13:37:58] <av500> thresh: again, ask your russian hacker friends to get us the source code [13:40:06] <thresh> :) [13:47:45] <Kovensky> kshishkov: that "nice formatting" thing on the rockplayer patch looks like code my C professor writes [13:48:20] <kshishkov> Kovensky: probably I won't trust him either [13:48:24] <mru> Kovensky: you should've seen the code mine wrote [13:48:42] <av500> mine looked all like pascal, wait, it was pascal [13:48:45] <Kovensky> well, that's when he didn't accidentally write pascal instead :> [13:48:45] * elenril summons some reviews [13:48:47] <mru> he placed all braces and semicolons to the far right [13:48:56] <Kovensky> av500: lol [13:49:04] <elenril> which one is right......oh wait, what? [13:49:18] <mru> if (foo) { [13:49:24] <mru> bar(); ; [13:49:30] <mru> } [13:49:31] <mru> etc [13:49:43] <mru> actually, he'd fold the ;} onto one line [13:49:45] <Kovensky> av500: mine wrote for loops with the index starting at i and ending at <= length (yes he wrote past the end of the array and left the first entry unused, and yes he didn't believe me when I told him that was invalid and would crash on a non-debug build if he was unlucky enough) [13:50:06] <Kovensky> actually, a crash would've been lucky :) [13:50:06] <mru> smells like fortran [13:50:18] <elenril> also are we merging lavco or what? [13:50:30] <elenril> it's conflicting with my lavf api cleanups [13:50:36] <av500> yes, we are merging libavcodec with windows phone 7 [13:50:41] <Kovensky> int i, a[8]; for (i = 1; i <= 8; i++) { a[i] = 0 } // <-- enjoy your infinite loop \o/ [13:50:46] * elenril merges av500 with /dev/null [13:50:49] <Kovensky> wait, forgot a semicolon [13:50:56] <av500> elenril: no space left on device [13:51:12] <elenril> av500: chapter muxing for asf where [13:51:18] <av500> here? [13:51:23] <elenril> send patches! [13:51:24] <mru> Kovensky: on a boring day I made an emacs function to reformat code in that weird style [13:51:27] <mru> and back [13:51:53] <Kovensky> 10:49.44 Kovensky: av500: mine wrote for loops with the index starting at i <-- er, starting at 1 [13:52:16] <av500> Kovensky: for(i=i; .... is much more fun [13:52:24] <Kovensky> mru: are you sure that wasn't Dev-C++'s doing [13:52:34] <mru> I'm quite sure [13:52:35] <Kovensky> mru: Dev-C++ can and does make weird formatting like that [13:52:42] <Kovensky> it pretty much filters its indentation through rand() [13:52:42] <mru> we talked about it [13:52:48] <mru> he was even proud of it [13:52:56] <mru> he was a bit quirky like that [13:52:59] <mru> but a nice guy [13:53:04] <Kovensky> lol [13:53:17] <Kovensky> that C professor was also my class's Java professor [13:53:32] <mru> http://hardwarebug.org/files/henrik.el [13:53:35] <av500> mru: have that macro, I need to send a patch to -devel [13:53:37] <Kovensky> last time I checked last year, my classmates still didn't properly know how to instantiate objects [13:53:37] <mru> no idea if it still works [13:53:47] <kshishkov> Kovensky: same with me but he knew both quite well [13:53:48] <Kovensky> (the Java class was in 2009) [13:54:14] <elenril> how do you improperly instantiate an object? [13:54:29] <Kovensky> elenril: by not instantiating it for instance [13:54:39] <av500> delete( new <object> ); [13:54:39] <kshishkov> mru: I think I can guess your professor's name [13:54:48] <Kovensky> in C++ you get a class on stack with the default constructor, in Java you get a null reference [13:55:08] <Kovensky> talking about C++, I really cringed when he showed that Borland abomination and said that was C++ [13:55:19] <Kovensky> sure, it might have been C++'s syntax, but it was just Delphi with a different syntax [13:55:43] <kshishkov> well, it was decent C++ before Builder [13:55:52] <Kovensky> the thing is, he didn't say that syntax was C++, he said the thing itself was C++, and that the major advantage of C++ over C is that you can write GUI programs in it and not in C [13:55:56] <kshishkov> (as much as C++ can be decent of course) [13:56:33] <Kovensky> my classmates also insist that netbeans and dev-c++ are compilers and still didn't understand what an IDE is after years of me trying to correct them [13:56:55] * mru still does not understand what an IDE _does_ [13:57:10] <mru> an IDE _is_ annoying, that I know [13:57:12] <Kovensky> look cute [13:57:14] <j-b> autocomplete [13:57:24] <Kovensky> and have a button to compile [13:57:25] <elenril> poor man's regexps [13:57:33] <thresh> mru: that's how everyone else call that OS you're using to do everything [13:57:35] <Kovensky> without having to deal with scary makefiles and compiler commands [13:57:49] <bilboed-tp> the whole point of an IDE is to hide all the warnings that a compiler will give you [13:57:49] <Kovensky> Eight Megabytes And Constantly Swapping <-- lol [13:58:08] <mru> escape meta alt control shift [13:58:13] <cartman> lets you do clipboardinheritance [13:58:18] <mru> emacs makes any computer slow [13:58:31] <Kovensky> I lost my .emacs.d :( [13:58:35] <Kovensky> too lazy to remake it [13:58:39] <mru> want mine? [13:58:45] <Kovensky> sure [13:58:50] <mru> I'm not [13:58:50] <Kovensky> does it have a nice cperl-mode setup btw? [13:58:53] <kshishkov> make EMACS regenerate it [13:58:54] <cartman> mru: github it [13:59:02] <mru> it has weird stuff in it [13:59:09] <cartman> mru: its emacs [13:59:10] <cartman> doh [13:59:12] <Kovensky> mine also had lots of cruft =p [13:59:27] <lu_zero> btw [13:59:30] * Kovensky is using vim for now [13:59:38] <lu_zero> you should really provide the configuration for emacs [13:59:50] <lu_zero> and I should put somewhere the bare conf for vim [13:59:53] <Kovensky> vim's vimrcexample is almost perfect, you just need to add the tab setup lines [14:00:06] <Kovensky> well, I also set nobackup [14:00:07] <kshishkov> Kovensky: did your .emacs.d contain ELisp reimplementation of vim? [14:00:08] <lu_zero> Kovensky: and the space cleaning function [14:00:33] <mru> space cleaning hack: enter and exit picture-mode [14:02:26] <Flameeyes> isn't there already a .dir-settings.el? [14:02:33] <Orphis> Alright, cygwin is just made of fail [14:02:45] <lu_zero> Orphis: sadly ^^; [14:03:06] <Kovensky> I still prefer cygwin to anything else on windows just because of properly supporting unicode filenames :( [14:03:23] <Orphis> When something is mysteriously not working occasionnaly, there's no one to help or anything [14:03:46] <Orphis> I get a "vfork: resource not available" occasionnaly [14:04:20] <Kovensky> try closing everything cygwin-related, opening \cygwin\bin\ash.exe and running rebaseall in it [14:04:45] <cartman> and peflagsall [14:04:50] <Kovensky> I usually have to do that on new installs, specially if I install / use python because for some reason it ships python pre-broken and you need to rebase the dlls to fix it [14:09:46] <Zor> elenril: can I pull a specific commit from another repo into my own in git? (JEEB says to harass you) [14:10:20] <Orphis> I've did that a few times already [14:10:31] <Orphis> But it doesn't fix it [14:10:36] <Kovensky> Zor: yes [14:10:44] <Kovensky> Zor: git cherry-pick <commit hash> [14:10:58] <Kovensky> if you have that repo as one of your remotes and it is fetched, git will find the commit in it [14:11:10] * elenril promotes Kovensky to his spokesperson [14:11:32] <Kovensky> `git remote add -f remote_name git://address` <-- to add and automatically `git fetch` a new remote [14:11:38] <Zor> Kovensky: excellent [14:11:40] <Zor> thanks [14:13:39] <j-b> kierank: "Each project gets 500 visitor tickets for free" [14:14:18] <av500> lol [14:14:26] <av500> sell them and you can have a $big booth [14:15:15] <j-b> you are more evil than a Frenchman [14:15:42] <kshishkov> j-b: was that a compliment? [14:19:52] <lu_zero> kshishkov: obviously [14:24:48] <j-b> av500: 34EUR /ticket? seriously? [14:28:30] <av500> its a serious, professional trade show [14:29:43] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * raa8ac53b51 ffmpeg/doc/filters.texi: [14:29:43] <CIA-38> ffmpeg: Update overlay documentation after movie syntax update. [14:29:43] <CIA-38> ffmpeg: Overlay documentation is still using the old unsupported syntax. [14:29:43] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:30:31] <kshishkov> av500: 206bit? [14:30:42] <mru> 26-bit [14:31:03] <j-b> ok, "vbv-delay" patch status? [14:31:23] <jannau> bikeshedding [14:31:47] <mru> the correct solution is to make encoders output AVPacket and set it there [14:31:51] <mru> but that's a lot of work [14:32:00] <kshishkov> mru: that makes no sense. Even PDPs operated on 36-bit IIRC [14:32:55] <j-b> jannau: pfff [14:34:11] <kshishkov> j-b: unfortunately since the split time we don't have so great bikesheds :( [14:37:18] <lu_zero> I'm not complaining a lot [14:41:04] <Orphis> Kovensky: I still get the same error with cygwin [14:41:18] <Kovensky> :S [14:42:39] <Orphis> I think I'll be moving the build to a real linux box and transfer the binaries only to run the tests on Windows [14:43:54] <kshishkov> http://www.mpegla.com/main/pid/vp8/default.aspx <- av500 rejoice! [14:44:20] <lu_zero> kshishkov: what? [14:44:26] <cartman> niceeee [14:44:47] <mru> seriously, they're doing the right thing [14:44:59] <cartman> it was about time [14:44:59] <mru> if someone does have patents, they'll surface sooner or later [14:45:07] <mru> better to encourage them to come forth now [14:45:14] <av500> yes [14:45:27] <lu_zero> and hammer them like wack-a-mole? [14:45:32] * kshishkov remembers the reason why Archos players support VP8 [14:46:17] <cartman> kshishkov: why? [14:46:34] <av500> because we pay H264 royalties :) [14:46:38] <cartman> no patent thing? [14:46:41] <cartman> av500: ah [14:47:13] <cartman> must be royal pain in the ass [14:47:15] <cartman> *giggle* [14:47:21] * kshishkov wonders what would Firefox do when enough VP8 are gathered [14:47:35] <cartman> back to MNG [14:47:39] <mru> this should be fun [14:48:04] <cartman> this is a such a fucked up day [14:48:12] <cartman> even GTK+ 3 is released [14:48:16] * mru trolls #vp8 with the link [14:48:26] <cartman> mru: do what you are good at :D [14:48:59] <mru> so we'll have nokia phones running gtk3 on winphone playing vp8? [14:48:59] <j-b> kshishkov: oh, lol... [14:49:10] <cartman> mru: who knows [14:50:45] <Tjoppen> the w3c html5 workshop appearently considered h.261 [14:51:06] <Tjoppen> re: MNG [14:51:07] <cartman> they considered VP3/Theora too [14:52:07] <av500> I guess they considered ascii art too [14:54:50] * kshishkov goes to asciimation.co.nz, blames av500 [14:56:23] <kierank> w3c could have considered bink [14:56:49] <j-b> nut/ffv1 [14:57:16] <kshishkov> Snow+Sonic+NUT [14:57:41] <av500> flash! [14:57:51] <av500> they should have standardized flash [14:58:21] * av500 smells API wars coming up [14:58:38] <lu_zero> where? [14:58:40] <lu_zero> and why? [14:59:06] <spaam> on ml.. [14:59:08] <elenril> that would make a nice movie title [14:59:23] <elenril> FFmpeg III: The API Wars. [14:59:24] <lu_zero> spaam: which thread? [15:00:11] <kshishkov> av500: well, it's all in SWF spec, open standard for what it worth. So Firefox may support FLV for <video> [15:00:14] <spaam> lu_zero: "ABI and forkS" and/related to "Pass VBV delay to the calling application via ctx" [15:01:19] <kierank> kshishkov: what about the patents [15:01:28] <Kovensky> some_struct *iter = &{ NULL, option_list }; // <-- is this even valid C? [15:01:29] <lu_zero> yawn [15:01:42] <kshishkov> kierank: Steve Jobs was right [15:01:55] * kierank joins #vp8 to see the flames [15:02:07] <kshishkov> Kovensky: looks like valid C++2010 at least [15:02:12] * Kovensky joins kierank in joining [15:02:21] <Kovensky> kshishkov: would gcc eat that from a .c file? =p [15:02:26] <Kovensky> would clang? [15:03:40] * Kovensky is trying to iterate through a linked list and thought that syntax as a way to make the "head" of the iterator on the stack [15:03:52] <Kovensky> it looks valid to me, but you never know ._. [15:04:08] <Kovensky> well, it doens't look valid, it looks like it should / could be valid =p [15:04:29] <kshishkov> just try it [15:05:30] <mru> that doesn't look like valid C [15:05:50] <mru> some_struct *iter = (some_struct *){ stuff }; is valid [15:07:01] <kierank> doesn't matter anyway. vp8 is still a niche product whatever. [15:07:11] <Kovensky> mru: wouldn't that convert the struct itself to a pointer, instead of making a pointer to the struct? [15:07:13] <mru> wrong, it's sub-niche [15:07:27] <mru> Kovensky: what do you want to do? [15:07:50] <Kovensky> some_struct is a linked list struct [15:08:06] <Kovensky> I want to iterate through it but without special casing the first element [15:08:35] <mru> I don't understand [15:08:51] <Kovensky> hm, I'll just finish writing the loop then pastebin [15:09:01] <Kovensky> then I can actually explain it [15:09:14] <mru> maybe then you won't need to explain it [15:09:30] <cartman> have a nice weekend! [15:09:51] <Kovensky> or that [15:09:51] <Kovensky> :> [15:10:36] <kshishkov> mru: I'd call that unsweeped corner, not sub-niche [15:10:56] * mru gets out the hoover [15:11:04] * lu_zero calls it possible new and untapped market [15:13:43] <kshishkov> lu_zero: where sane people don't dare to thread? [15:34:24] <kierank> j-b: why did you call mpeg-la patent trolls? [15:34:53] <j-b> kierank: because they are :D [15:35:12] <j-b> for a broad definition of "patent trolls", but yes [15:35:19] <kshishkov> j-b: they are patent troll middlemen [15:36:17] <j-b> same business [15:36:38] <mru> I don't see them doing any harm [15:36:42] <kshishkov> j-b: nope, it's even better [15:36:46] <mru> the patents are already there [15:37:10] <kshishkov> mostly in H.264 pool [15:41:19] <mru> BBB: please comment on my pending vp8 patches [15:41:29] <mru> http://patches.ffmpeg.org/patch/755/ [15:41:34] <mru> http://patches.ffmpeg.org/patch/756/ [15:43:41] <BBB> don [15:43:42] <BBB> done [15:46:59] <mru> kshishkov: care to take a look at the first of those? [15:47:06] <mru> you already acked the second one [15:47:34] <kshishkov> asm seems to be the same as in third patch [15:47:51] <mru> pretty much, yes [15:48:00] <kshishkov> so ok with me [15:52:20] <BBB> i think the whole nokia+wimo is funny [15:52:41] <mru> kshishkov: here's a nice one: PLD [R0, R3] [15:52:42] <BBB> so what's left of meego now? wasn't that the gnome desktop based on qt, or so? [15:52:44] <mru> r0 and r3 are pointers [15:53:27] <kierank> BBB: vp8 is even funnier [15:53:58] <kshishkov> mru: it's funny if if makes any differences on certain CPU models [15:54:02] <kshishkov> *if it [15:54:11] <superdump> BBB: it rather seems that symbian will be scrapped, meego will continue to be developed for 'future platforms' [15:54:31] <superdump> in short it seems that windows phone is a stopgap because they need to release some products and meego isn't ready [15:54:43] <superdump> and i guess if meego doesn't prove itself, it too will be binned from the nokia side [15:55:52] <BBB> superdump: that's exactly the problem [15:56:07] <BBB> superdump: meego or maemo have been around for what, 8 years now? [15:56:15] <BBB> they'll be dead-on-arrival [15:56:20] <BBB> or won't arrive at all [15:56:30] <superdump> yeah, but maemo/meego themselves weren't the problem from what i can tell [15:56:46] <BBB> I'm not crazy, I'm an airplane! [15:57:12] <superdump> the processes forced upon the developers due to being funded by nokia was the real problem [15:57:42] <bilboed-tp> BBB, they haven't. maemo was started 6 years ago and it was restarted at least 3 times from scratch due to incompetent finish bureaucracy [15:57:52] <bilboed-tp> BBB, hadn't they done that... we would have the dream platform by now [15:57:55] <bilboed-tp> (sucks) [15:57:57] <superdump> basically growing very large, trying to cope with it by developing features and shovelling them into lots of different but very similar products [15:58:01] <av500> it was restarted again 6mo ago when they decided that native apps were bad [15:58:23] <av500> and had to retool for QML+javascript [15:58:28] <BBB> bilboed-tp: I started gradschool 6 years ago, and by then some certain company was already doing contract work on some platform for some finnish company [15:58:41] <BBB> but doesn't matter [15:58:44] * kierank doesn't care for mobile phones [15:58:49] <kierank> best option [15:59:03] <av500> http://qt.nokia.com/products/qt-quick/ [15:59:07] <BBB> what android and ios teach us is that stuff isn't built by dreaming things up. it's done by f&cking hard work :) [15:59:19] <BBB> wimo is wonderful but _already_ too late [15:59:25] <BBB> and then there's webos/meego :-p [15:59:26] <superdump> + a metric fuckton of bureaucracy [15:59:36] <bilboed-tp> it's bureaucracy that killed it [15:59:40] <BBB> meego is just Yet Another Me-Too [15:59:53] <kshishkov> BBB: postgrad students in .ua are supposed to produce thesis in 3 years after enrollment (and they study at the same time too) [16:00:05] <BBB> kshishkov: doesn't that depend on the field? [16:00:27] <kshishkov> BBB: 5 years for medical stuff IIRC [16:00:28] <av500> BBB: post grad in agriculture have even less time [16:00:34] <BBB> kshishkov: here math/economy is 3 years, biology is ~6 on average (I was 5 1/2 and the first in my program, and third or fourth in the whole year) [16:00:37] <av500> so much for field work [16:00:46] <kshishkov> av500: you mean "got your shovel"? [16:00:53] <av500> yep [16:02:10] <BBB> The Wall Street Journal is always right-on: "But the biggest loser is MeeGo, the ugly, unloved step child of operating systems." [16:02:18] <BBB> gotta love those damn americans [16:02:37] <BBB> "So MeeGo to No Go." [16:04:06] <kshishkov> BBB: was wrong, 3 or 4 years at most for everybody [16:04:29] <kshishkov> BBB: 4 years if you work somewhere else officially [16:04:49] <BBB> PS, if Nokia is so big on "open video codecs" (weren't they or their contracters pimping theora 6 years ago?), and vp8 is the new open video future, then what does that mean for vp8 support in WiMo on Nokia phones? [16:04:52] <BBB> bilboed-tp: ^^ [16:04:59] <BBB> I foresee a problem [16:05:14] <bilboed-tp> what are you talking about ? [16:05:36] <bilboed-tp> could you stop using double-entendre and express yourself clearly ? [16:05:57] <bilboed-tp> N has never pushed open video codecs. [16:05:59] <kshishkov> BBB: h.264 plugin of course [16:09:40] <merbzt> bilboed-tp: not really true, they "pushed" for MVC [16:10:18] <kierank> i wonder why mpeg-la is calling for an mvc patent pool when the codecs are shipping already [16:10:32] <bilboed-tp> merbzt, you mean the 'heavily-patented extension to H264' ? Wouldn't call that 'open' [16:10:39] <mru> no, not that one [16:11:00] <bilboed-tp> in real news, mubarak finally stepped down [16:12:42] <mru> I thought he'd hang on for another week [16:13:13] <bilboed-tp> must have been the nokia/microsoft announcement that pushed him to leave [16:13:44] <kierank> nah he saw the vp8 patent pool call [16:13:55] <bilboed-tp> :) [16:14:00] <BBB> mru: should I bother looking into clang 2.8 or just assume it's a compiler bug? [16:14:08] <BBB> suse clang 2.9 works fine, it seems [16:14:22] <BBB> I can't find any eays way to install clang 2.9 locally [16:14:26] <mru> BBB: no, it hasn't built that rev yet [16:14:27] <BBB> don't want to do too much effort [16:14:34] <BBB> oh, I see [16:14:43] * BBB goes try clang 2.8 then [16:14:46] <BBB> let's see if it fails [16:15:12] <BBB> wbs: ping :-p [16:16:45] <BBB> co clang 2.8 doesn't support "pavgusb" in inline asm? [16:18:39] <merbzt> bilboed-tp: not the extension, Nokia submitted their own codec as proposal for the H264 standardization process [16:18:49] <bilboed-tp> ah [16:18:56] <merbzt> thus open in that meaning [16:19:13] <bilboed-tp> I thought you meant something theora like [16:19:29] <mru> wasn't there a rumour that nokia had patents on theora? [16:19:40] <av500> [17:17:10] <dwd> Robot101, On the plus side, Collabora should be able to take over Nokia in a couple of hours at this rate. [16:19:48] <bilboed-tp> lol [16:20:43] <bilboed-tp> nokia has so many patents... I'd be amazed they didn't have some on everything tech-related out there [16:55:30] <mru> kshishkov: could you please ok the vp56 arm patch on the ml? [16:58:59] <spaam> mru: i can do it ;) [16:59:49] <kierank> spaam: stick to your traffic shaping [17:00:45] <spaam> kierank: pfff i dont do that kind of things.. our cutomers can do it if they want.. :P [17:01:27] <kierank> ah so you're just shifting the responsibility [17:01:27] <mru> is this another "guns don't kill people" speech? [17:01:49] <spaam> kierank: i just help them to identify the traffic ;) [17:02:02] <spaam> mru: nope.. kierank blame me for stuff. [17:02:23] <mru> I don't pull the trigger, the firing squad does that... I only name the dissidents [17:03:15] <spaam> im the good guy :) [17:04:53] <spaam> time to go home :) [17:08:04] <kierank> spaam: continue to kid yourself [17:09:11] <av500> what traffic doth spaam shape? [17:09:30] <BBB> oh hell this is painful [17:09:36] <BBB> clang 2.8 doesn't support 3dnow inline asm [17:09:40] <BBB> and I have to ifdef everything out [17:09:47] <BBB> can't believe nobody ever noticed [17:09:47] <mru> BBB: --disable-asm [17:09:53] <mru> still triggers bug on 2.9 [17:11:40] <BBB> almost done [17:11:44] <BBB> only swscale left now [17:12:07] <mru> BBB: hunting that vp8 bug? [17:12:50] <BBB> yeah [17:13:07] <mru> build with --disable-asm [17:14:03] <BBB> damnit [17:14:08] <BBB> 2.8 doesn't trigger it either :-p [17:14:20] * BBB goes consider if he wants to install 2.9 [17:19:36] <kshishkov> mru: okayed [17:20:45] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r7da48fd011 ffmpeg/libavcodec/ (arm/vp56_arith.h vp56.h): [17:20:45] <CIA-38> ffmpeg: ARM optimised vp56_rac_get_prob() [17:20:45] <CIA-38> ffmpeg: Approximately 3% faster on Cortex-A8. [17:20:45] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:20:57] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * ra7878c9f73 ffmpeg/ (6 files in 3 dirs): [17:20:57] <CIA-38> ffmpeg: VP8: ARM optimised decode_block_coeffs_internal [17:20:57] <CIA-38> ffmpeg: Approximately 5% faster on Cortex-A8. [17:20:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:22:15] <pJok> kshishkov, uh nice... bink b \o/ [17:22:57] <kshishkov> pJok: yes, it was the whole point [17:28:12] * mru stabs over-commented code [17:29:08] <pJok> mru, code can never me too commented... [17:31:05] <mru> https://github.com/CyanogenMod/android_external_jpeg/blob/gingerbread/asm/a… [17:31:08] <mru> that code [17:33:09] <mru> many of the comments are of course wrong [17:36:28] <kierank> av500: what nationality wrote that code [17:36:38] <kierank> you are the arbiter of these things [17:36:54] <mru> the jpeg code? [17:37:38] <kierank> yes [17:37:47] <mru> no idea who wrote it [17:37:51] <mru> it comes from qualcomm [17:37:56] <mru> and it sucks [17:38:24] <kierank> av500 can use magic to tell whether it was indian, chinese, american [17:38:38] <mru> this looks american to me actually [17:38:55] <mru> judging by the comment style [17:43:55] <pJok> mru, you are right... too much commenty stuff [17:49:34] * mru stabs ijg some more [17:49:50] <mru> the trolls didn't include configure.{in,ac} [18:10:38] <mru> BBB: figured it out [18:12:28] <BBB> \o/ [18:15:12] * jannau too [18:40:31] <BBB> mru: thanks, now it works as expected [18:41:04] <spaam> av500: ppl use our products to do stuff with their internet traffic ;) [18:47:01] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r4b884207eb ffmpeg/configure: [18:47:01] <CIA-38> ffmpeg: configure: remove early check_deps $ARCH_EXT_LIST [18:47:01] <CIA-38> ffmpeg: The early disabling of irrelevant arch extensions is no longer [18:47:01] <CIA-38> ffmpeg: required, and removing it makes dependencies involving these [18:47:01] <CIA-38> ffmpeg: work as expected. [18:47:02] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [19:10:05] <KotH> .o0(where is cartman when you need him?) [19:12:31] <pJok> KotH, out with kenny and the other guys? [19:15:23] <KotH> how can he? [19:15:26] <KotH> i need him! [19:15:29] <KotH> now! [19:15:30] <KotH> ^^' [19:26:12] <lu_zero_> how [19:28:35] <j-b> wbs: no idea what OS he is on [19:30:07] <kierank> is there an interchange format for dvb subtitles [19:32:37] <Tjoppen> mpegps? [19:32:45] <mru> hardly [19:32:55] <Tjoppen> ts it is then :p [19:37:12] <kierank> well closed captions have scc files but dvb has nothing [19:38:44] <Tjoppen> I tried googling around (no ffmpeg on this machine), but ts seems to be pretty much the only place where they're used? maybe I missed something? [19:39:43] <mru> dvb == ts [19:40:20] <kierank> rhozet seems to have made a .dvb file format for subtitle interchange [19:40:56] <kierank> mru: there's also dvb in mp4 [19:40:58] <kierank> but nobody uses that [19:41:04] <mru> kierank: that's still ts [19:41:05] <Tjoppen> mru: yes, but surely there are other containers that can mux bitmap subtitles? [19:41:10] <mru> ts wrapped in mp4 [19:41:17] <_av500_> mru: wow, that is well commented [19:41:27] <mru> Tjoppen: dvb subs are not bitmap [19:41:43] <mru> they are ridiculously complicated [19:42:03] <Tjoppen> uhm.. aren't they the ones that are RLE:ed 2/4/8-bit bitmaps? [19:42:11] <mru> that'd dvd [19:42:16] <Tjoppen> aha [19:42:50] <mru> dvb is an entire rendering system with embedded fonts and whatnot [19:43:37] <mru> of course nobody ever uses more than about 1% of the capabilities [20:00:39] <mru> why must everybody so totally misunderstand mpeg-la? [20:01:02] <Dark_Shikari> hacker news seems to have gotten it right [20:01:40] <mru> "MPEG LA â the patent pool organization that controls the H.264 video codec â is collecting patents for what can only be described as an attack on the competing VP8 codec" [20:01:44] <mru> how wrong can it get? [20:01:54] <mru> 1) they don't control anything [20:02:05] <mru> 2) vp8 is not "competing" with them [20:02:10] <kshishkov> mru: 1) wait till Stallman and Xiph awake [20:02:17] <kshishkov> mru: 2) get tons of lulz [20:02:30] <Dark_Shikari> mru: the top HN comments are not saying that [20:02:37] <Dark_Shikari> only stupid people are saying that [20:02:50] <mru> I know, but stupid people are in abundance [20:02:58] <Dark_Shikari> They always are. You can't get rid of them [20:04:38] <_av500_> mru: you can spend ages just to explain what mpegla does [20:04:41] <iive> isn't vp8 compete with h264? [20:04:48] <mru> iive: possibly [20:04:56] <mru> iive: but that doesn't mean it competes with _mpegla_ [20:05:14] <mru> mpeg-la will set up pools for any patented standard [20:05:29] <mru> they don't care [20:05:36] <pJok> mru, considering they pooled together for 1394, you're right about that [20:06:28] <_av500_> we should get patents on bikeshedding and pool them in mpegla [20:06:34] <mru> patent pools make life easier for both patent holders and licensees [20:06:36] <iive> mru: the quote doesn't explicitly say they compete with mpegla. it allows correct interpretation. [20:06:42] <_av500_> but we would never agree [20:06:51] <mru> mpeg-la is just a middle-man who takes a cut of the transaction [20:07:15] <_av500_> and its frakin 25cents.... [20:07:34] <BBB> wbs: if you could fix that, that'd be fantastic [20:07:46] <BBB> wbs: otherwise I might revert your priv_data removal patch :-p [20:07:48] <mru> given the patent system, the service they provide is well worth the cost [20:08:14] <mru> imagine chasing down each of those hundreds of patents separately, then negotiating licensing terms with each [20:08:17] <mru> nightmare [20:08:23] <_av500_> yup [20:08:39] <_av500_> and if you get sued, you cannot even reveal how much the others charge you [20:08:44] <_av500_> with the pool you can [20:08:51] <wbs> BBB: which will make lavf crash on all _normal_ rtsp streams, too, due to trying to free the RTSPStreams for mepgts [20:08:52] <mru> the pool is open [20:09:12] <mru> of course I'd much rather see the uspto shut down [20:09:13] <BBB> wbs: only on mpegts streams, no? :-p [20:09:18] <mru> but that's not going to happen anytime soon [20:09:18] <_av500_> if a non pool patent owner sues you, the court can look at the pool and award damages [20:09:28] <BBB> wbs: oh right, now on all - ohwell, double free doesn't crash [20:09:31] * BBB runs [20:09:34] <_av500_> if there is no pool, they can ask for anything [20:10:31] <wbs> BBB: but yes, it should be quite solveable via AVStream->id, but do you have samples that I can try it on? [20:10:47] <wbs> oh, now I see the mail too, thanks :-) [20:14:24] <BBB> :) [20:14:56] <Dark_Shikari> someone is trying to post a patch to ffmpeg-devel but they need the moderator to approve their subscription [20:15:00] <Dark_Shikari> can someone do that? [20:15:12] <mru> doen [20:15:15] <mru> done even [20:16:40] <bcoudurier> morning [20:17:08] <Compn> how about readding michaelni to list admins? or you guys talk about that stuff in private ? [20:18:40] <mru> we don't want trolls on the list [20:18:53] <Compn> michaelni has said a few times he wouldnt unban gabu [20:19:00] <mru> I don't believe that [20:19:34] <Compn> well it sounds like you have issues then [20:19:43] <mru> what other reason would he have for poking around the admin pages 5 minutes after gabu was put on moderation? [20:19:45] <Compn> if you cant trust michael, who can you trust [20:19:54] <iive> if he unbans gabu, you would have valid reason to keep him away from admin. [20:20:00] <Compn> well he thought it was arpi [20:20:01] <mru> prior to that, he hadn't touched for something like 6 months [20:20:03] <mru> minimum [20:20:03] <Compn> remember his confusion ? [20:20:10] <Compn> because of the poorly written mail [20:20:11] <iive> mru: to found out if arpi is banned. of course. [20:20:23] <mru> yeah, right [20:20:33] <mru> I'm not discussing this further [20:20:38] <Compn> fair enough [20:21:08] <Compn> cant say i didnt try... [20:22:27] <BBB> elenril: can you ping patches directly? I don't know which ones are uncommitted, sorry [20:22:39] <BBB> elenril: it's a little chaotic if you don't pay continuous attention :) [20:23:02] <_av500_> BBB: the new system, it fails! [20:23:09] <mru> elenril: please go over your patches in patchwork and make sure all actually committed ones are marked as such [20:23:13] <mru> same for superseded [20:23:24] <BBB> _av500_: yeah, we're all gonna die!! [20:23:29] <_av500_> omg [20:23:32] * _av500_ runs [20:23:37] <Compn> is there a link to the patchwork somewhere on ffmpeg.org ? [20:23:38] <BBB> there is no place to hide! [20:23:44] <BBB> Compn: don't think so [20:23:48] * Compn hasnt looked at it yet [20:23:56] <Compn> where would you put something like that ? [20:24:05] <BBB> dunno [20:24:08] <BBB> maybe the developer section? [20:24:14] <Compn> is roundup linked there ? [20:24:16] <BBB> same place as a multimedia wiki link [20:24:21] <BBB> yeah [20:24:29] <Compn> patches welcome BBB [20:24:31] <Compn> :P [20:27:19] <BBB> Compn: /me lazy [20:27:35] * Compn lazy too [20:27:38] * elenril busy hating on solid state physics :/ [20:27:55] <BBB> lu_zero_: as for the "why this hack" - I don't actually remember :) [20:28:02] <BBB> I'll try to dig in my memory [20:31:55] <elenril> wow, an actually readable -map documentation [20:32:12] <elenril> somebody commit that asap! [20:32:32] <mru> I never bothered figuring out what -map does, so I can't review it [20:33:21] <elenril> it does :magic: [20:33:45] <mru> I know the general idea of what it does [20:33:59] <mru> picking streams from inputs and assigning to outputs [20:34:03] * Compn avoids -map , for fear of breaking something [20:34:05] <mru> but the way it does it seems mostly random [20:34:30] <mru> it's been years since I tried to use it [20:34:36] <Compn> did ffmpeg get multiple input files yet ? [20:34:40] <Compn> whered that patch go? [20:34:44] <mru> it always had [20:34:45] <Compn> or is that playlist related [20:35:00] <Compn> oh really, what am i thinking then [20:35:05] <mru> it used to have multiple outputs too, but someone broke that [20:35:23] <Compn> ah nm, i'm dumb then [20:38:06] <michaelni> <mru> what other reason would he have for poking around the admin pages 5 minutes after gabu was put on moderation? [20:38:17] <michaelni> i did not poke around [20:38:57] <michaelni> IIRC i got a mail from arpi that i interpreted that arpi was baned and i looked at the page and saw that iam not admin anymore [20:40:01] <michaelni> anyway ive been disconnected from irc thanks to shitty lan cable for a moment, i hope ive not missed any important trolling [20:40:07] <Dark_Shikari> don't think so. [20:40:20] <Dark_Shikari> there's an interesting thread on the topic of signalling fps in vfr mode for x264. [20:40:21] <michaelni> ill be back in 30min or so need to leave [20:40:25] <Dark_Shikari> x264 uses fps to calculate level [20:40:39] <Dark_Shikari> but in vfr mode, the fps gets set to 1 / timebase which is totally borked whne timebase is microseconds or whatever [20:41:44] <Dark_Shikari> (it's probably lavc-api-related) [20:42:32] <Compn> mru : oh, i meant concatenating files [20:42:45] <bcoudurier> Dark_Shikari, what do you want as timebase ? [20:42:56] <bcoudurier> and what's borked about it ? [20:42:57] <Dark_Shikari> timebase should be the real timebase [20:42:59] <Dark_Shikari> timebase is fine [20:43:05] <Dark_Shikari> the problem is that ffmpeg sets fps to 1 / timebase [20:43:08] <Dark_Shikari> thus, for a vfr stream [20:43:10] <Compn> which mencoder has had for a while... [20:43:11] <Dark_Shikari> fps is, say, 1 million [20:43:29] <mru> what do you need to know? average frame rate? [20:43:40] <bcoudurier> how do you specify the timestamps timebase using libx264 [20:43:57] <Dark_Shikari> You set timebase_num and timebase_den [20:43:58] <Dark_Shikari> mru: we don't [20:44:06] <Dark_Shikari> the problem is that: [20:44:12] <Dark_Shikari> 1) an encoder must calculate the correct level before encoding starts. [20:44:15] <Dark_Shikari> it can't go back and change it later [20:44:24] <Dark_Shikari> 2) you've told the encoder the fps is 1 million [20:44:33] <Dark_Shikari> 3) it uses this and says "no level can possibly match your stream" and defaults to 5.1. [20:44:40] <Dark_Shikari> TECHNICALLY, peak fps would be most accurate. [20:44:50] <elenril> Compn: send patches [20:44:52] <Dark_Shikari> Practically, it'd be better to just do "25fps" than to say 1 million fps. [20:45:05] <mru> naturally [20:45:08] <bcoudurier> well actually I'd like the encoder to fail [20:45:16] <Compn> elenril : there were concat patches [20:45:29] <mru> chained ogg ftw [20:45:34] <Compn> elenril : i'm trying to find out if they were rejected/reviewed whatnot [20:45:37] <elenril> you mean the playlist ones? [20:45:40] <BBB> ruggles: do you think you should also update the documentation for SSE2/SSE2SLOW in lavu/cpu.h? [20:45:49] <elenril> they weren't very nice afaik [20:45:50] <Compn> might be related to playlists , yeah [20:46:02] * Compn wants playlist support too :) [20:46:11] <bcoudurier> IMHO fps should not be set in that case [20:46:16] <bcoudurier> but timebase should always be set [20:46:16] * Compn not care about chained ogg tho [20:46:23] <elenril> and from what i saw they weren't generic enough to be useful for stuff like matroska ordered chapters etc [20:46:26] <bcoudurier> setting fps for VFR makes no sense to me [20:46:34] <bcoudurier> or set it to the average [20:46:48] <Dark_Shikari> bcoudurier: how is the encoder supposed to figure out the level to use? [20:47:05] <Dark_Shikari> In 2-pass mode it could look at the stats, I guess. [20:47:19] <bcoudurier> well if there are constraints it should require the level [20:47:22] <Compn> Dark_Shikari : somewhat unrelated, should there be a limit to hte max fps ? e.g. no more 1million fps ? [20:47:24] <bcoudurier> and if it cannot guess [20:47:35] <bcoudurier> otherwise you could create invalid bitstreams [20:48:04] <bcoudurier> do the h264 spec mention how to handle vfr ? [20:48:12] <Dark_Shikari> Barely. [20:48:15] <Dark_Shikari> At best, obfuscated. [20:48:23] <Dark_Shikari> The level section talks constantly about framerate. [20:54:46] <bcoudurier> :( [20:58:46] <michaelni> Dark_Shikari, our API lacks a peak fps. But even if the av-encoder API had one i dont know how ffmpeg.c could set it without scanning the whole input file [20:59:04] <Dark_Shikari> I know, I'm not asking for that [20:59:13] <Dark_Shikari> I'm asking "if our input is VFR, and our timebase is crazy, what fps do we give the encoder" [20:59:25] <Dark_Shikari> and what are the boundaries of "crazy"? [20:59:32] <Dark_Shikari> is 100fps crazy? 200? 1000? [20:59:50] <michaelni> AVStream.r_frame_rate [20:59:59] <Dark_Shikari> what is that? [21:00:01] <Dark_Shikari> i.e. what does it represent [21:00:20] <michaelni> best guess of the least crazy timebase that can represent all frames exactly [21:00:34] <michaelni> its a guess aka it can be wrong [21:00:57] <Dark_Shikari> how is it calculated ? [21:01:09] <michaelni> see av_find_stream_info [21:01:11] <Dark_Shikari> what is it typically? [21:01:36] <michaelni> typically like 25 or 30 or 24000/1001 or so [21:01:44] <michaelni> but as said it can be nonsense too [21:01:47] <Dark_Shikari> hmmph [21:01:50] <michaelni> like 1000000 [21:02:00] <Dark_Shikari> But wait. the encoder doesn't know the avstream. [21:02:12] <michaelni> and for vfr that has a minute of 25fps and then 30 it will be 25 [21:02:25] <michaelni> its just based on the first few frames [21:02:34] <Dark_Shikari> can lavc access the avstream? [21:02:55] <michaelni> no [21:03:15] <Dark_Shikari> well that doesn't work very well then? [21:05:51] <michaelni> ffmpeg.c should maybe set time_base to 1/r_frame_rate, dunno if it doesnt or if r_frame_rate if silly too to begin with [21:06:03] <Dark_Shikari> timebase shouldn't be changed [21:06:10] <Dark_Shikari> if it's milliseconds it should stay ms [21:06:27] <michaelni> you cant do that for some cases [21:06:29] <michaelni> like avi [21:07:34] <Dark_Shikari> yes, of course [21:07:37] <Dark_Shikari> but where possible, it shouldn't be changed [21:09:33] <michaelni> of course [21:10:02] <michaelni> i think we might have some bug there in ffmpeg.c in relation to this [21:10:34] <michaelni> but fixing this isnt all that easy [21:10:55] <michaelni> some codecs (older ones) only support some fps / timebase values [21:11:08] <kierank> bcoudurier: is there a spec that describes how drop frame works for different framerates (i.e 24/1.001 , 30/1.001, 60,1.001)? [21:11:48] <bcoudurier> if you mean timecode drop frame is only allowed with 30000/1001 [21:12:13] <kierank> there's a 60/1.001 drop frame apparently [21:12:21] <kierank> but maybe it's just unofficial [21:12:28] <bcoudurier> it's not official [21:12:50] <Dark_Shikari> divVerent: http://pastebin.com/3tPkjeet [21:12:52] <bcoudurier> did you read that in some document ? [21:13:00] <bcoudurier> SMPTE 12M is the reference [21:13:02] <kierank> bcoudurier: can't remember where I read it [21:15:21] <bcoudurier> ok it seems s12m-2008 added 60000/1001 [21:15:26] <bcoudurier> same mechanism [21:15:30] <ruggles> BBB: i was considering that. maybe separate the flags above 16-bits as special-case flags and document them better. [21:16:08] <bcoudurier> progressive 60000/1001 only though [21:16:10] <kierank> [21:15] bcoudurier: ok it seems s12m-2008 added 60000/1001 --> do you know which part? [21:16:57] <bcoudurier> section 5.2 [21:16:58] <divVerent> one thing to reply... yes, there are two open questions [21:16:59] <BBB> ruggles: we don't even need an organization for that (16bit or whatever), but the documentation could be better now [21:17:02] <divVerent> 1. what fps to set for VFR [21:17:05] <divVerent> 2. how to detect VFR [21:17:08] <BBB> ruggles: I'll apply the patch regardless, but for some future patch :) [21:18:08] <kierank> divVerent: everything is vfr unless proven otherwise [21:18:14] <kierank> by codec or container [21:18:17] <divVerent> as for 1.: I suppose anything from 23.98 to 60 will be "good enough" for this [21:18:34] <divVerent> as for 2.: for x264's purposes, treating anything as VFR indeed won't hurt much [21:18:50] <divVerent> but a "somewhat good" frame rate estimate would be very useful for x264 initialization [21:19:02] <ruggles> BBB: thanks. i have 2 patches pending where sse2 is slower on athlon64 [21:19:12] <divVerent> its main purpose seems to be decision of the H.264 level, and calculation of the default minimum keyframe interval [21:19:19] <divVerent> the latter being skipped by ffmpeg having a hardcoded default [21:19:28] <saintd3v> peloverde_: when you store he-aac in adts is AOT minus 1 still AOT_LC-1 ? [21:19:31] <BBB> ruggles: great, (or, well, no, I wish it were faster, but thanks for testing and making us select the fastest anyway) [21:20:10] <divVerent> kierank: however, how would you "prove it otherwise"? Even a low-fps time base could be VFR [21:20:16] <divVerent> e.g. if mplayer's "decimate" filter was used [21:20:29] <kierank> divVerent: proven otherwise by a flag in the container or codec [21:20:51] <kierank> saintd3v: everyone seems to just flag their he-aac audio as aac-lc at the adts level [21:21:05] <divVerent> kierank: that would consider my encodes CFR :P [21:21:14] <divVerent> as the MP4 codec does not have the VFR flag set in libavformat [21:21:18] <divVerent> *MP4 container [21:21:21] <bcoudurier> would it be unreasonable to not set the fps and assume level based on everything else ? [21:21:43] <divVerent> bcoudurier: this is what x264 does in level calculation if fps are not set [21:22:00] <divVerent> not sure if not setting fps at all has any negative impact otherwise, though [21:22:18] <bcoudurier> vfr flag ? [21:22:36] <bcoudurier> oh yes [21:22:40] <saintd3v> kierank: thanks. what i figured, as storing the extension audio type would be kind of silly. but you never know. [21:23:02] <divVerent> bcoudurier: mp4 (movenc.c) does not have AVFMT_VARIABLE_FPS set [21:23:12] <bcoudurier> yes [21:23:14] <divVerent> yet e.g. my Blackberry Bold 9000 plays VFR MP4 files written by libavformat just fine [21:23:27] <divVerent> I have read somewhere that the only reason why the flag isn't set is lack of support of negative pts [21:23:52] <bcoudurier> negative dts [21:24:20] <kierank> divVerent: ask vfr_maniac, he knows a lot more about mp4 and vfr [21:24:29] <divVerent> so basically, I wouldn't like anything making it entirely impossible to make VFR MP4 files [21:24:32] <VFR_maniac> ! [21:25:41] <divVerent> currently, to write working VFR MP4 files with libavcodec/libavformat, all one has to do is to do a nasty hack to set display duration of the first frame to "some nonzero value", so dts initialization doesn't create a row of equal pts which libavformat will later choke on [21:26:00] <divVerent> which incidentally is the other code that uses "time base <= 1ms" as a heuristics to detect VFR :P [21:26:02] <Dark_Shikari> Oh hey, it's VFR_maniac. [21:26:06] <Dark_Shikari> How relevant. [21:26:24] <bcoudurier> divVerent, just use -vsync 0 [21:26:46] <divVerent> I am not using ffmpeg.c, though [21:26:59] <bcoudurier> then it doesnt matter [21:27:09] <bcoudurier> the muxer will work just fine [21:27:20] <divVerent> it does not unless you specify the per-frame duration for the first frame [21:27:36] <bcoudurier> humm no [21:27:47] <bcoudurier> duration is only used for the last frame [21:27:48] <divVerent> but this is an unrelated issue [21:28:02] <bcoudurier> otherwise it uses curdts - lastdts [21:28:07] <bcoudurier> which is the correct way [21:28:10] <divVerent> nope [21:28:19] <bcoudurier> nope what ? [21:28:20] <divVerent> libavformat/utils.c [21:28:51] <bcoudurier> that's not the muxer [21:28:55] <divVerent> compute_pkt_fields() [21:29:00] <divVerent> is part of the muxer [21:29:03] <bcoudurier> and why don't you set the timestamps ? [21:29:06] <bcoudurier> not it's not [21:29:08] <divVerent> I set the pts [21:29:10] <divVerent> I cannot set dts [21:29:12] <bcoudurier> x264 gives you the pts [21:29:15] <bcoudurier> you can set dts [21:29:17] <bcoudurier> you know the delay [21:29:18] <divVerent> as I don't get them from libavcodec [21:29:21] <bcoudurier> and you have the pts [21:29:27] <divVerent> I don't use x264 directly, I use libavcodec [21:29:30] <bcoudurier> yes [21:29:36] <bcoudurier> you have the pts _and_ the delay [21:29:46] <bcoudurier> first dts == -delay [21:29:57] <divVerent> but this isn't allowed for mp4? [21:30:05] <bcoudurier> mp4 doesn't use dts [21:30:14] <bcoudurier> it uses frmae duration [21:30:21] <bcoudurier> frame duration is curdts - lastdts [21:30:26] <bcoudurier> according to specs [21:30:57] <divVerent> "Number of frames the decoded output will be delayed relative to the encoded input." [21:30:59] <bcoudurier> well more nextdts - curdts [21:31:00] <divVerent> but I am doing VFR :( [21:31:12] <divVerent> description of AVCodecContext::delay [21:32:05] * lu_zero_ wakes up [21:32:17] <bcoudurier> all right then, add AVFrame.dts field and set it :) [21:32:37] <divVerent> my problem is, I just don't know the proper dts [21:32:40] <bcoudurier> althought I'm curious what x264 uses as first dts [21:32:50] <bcoudurier> x264 is supposed to return it [21:32:57] <bcoudurier> I guess you can simulate the behaviour [21:33:06] <bcoudurier> althought using it directly would be better [21:33:10] <divVerent> oh, you mean adding the dts so it ends up in coded_frame [21:33:17] <divVerent> that would probably be somewhat sane :P [21:33:29] <bcoudurier> yes [21:33:50] <divVerent> my current code basically "helps" the hack in libavformat/utils.c so its "regeneration" of dts from pts actually works [21:33:59] <divVerent> is a workaround I want to eventually kill [21:34:09] <mccoffein> hi [21:34:10] <divVerent> it "helps" it by setting the duration of the first frame [21:34:43] <bcoudurier> yes [21:35:09] <bcoudurier> well although it's better to always set the duration of the frame like I said [21:35:12] <bcoudurier> it's needed for the last frame [21:35:26] <divVerent> sure, if I knew it :P [21:35:28] <bcoudurier> even if it's allowed to be 0 [21:35:36] <bcoudurier> well you know it from the input [21:35:44] <bcoudurier> don't you ? [21:35:48] <divVerent> I am working on a video output driver for mplayer to feed ffmpeg [21:35:59] <divVerent> I do not have duration info there, as far as I know [21:36:21] <divVerent> and what makes it more evil: I need duration of the *packet*, not of the *frame* [21:36:26] <bcoudurier> humm well it's next pts - curpts [21:36:33] <divVerent> I already noticed that the packet doesn't necessarily contain the frame I just encoded [21:36:43] <bcoudurier> right [21:37:06] <bcoudurier> well I believe adding AVFrame.dts is sane [21:37:18] <bcoudurier> and would spare you problems :> [21:37:50] <divVerent> but anyway, this is the smallest of my problems :P [21:37:56] <divVerent> but would eventually be the right thing to do in ffmpeg [21:38:52] <divVerent> http://paste.pocoo.org/show/336755/ - this is my code BTW, which I eventually want to get rid of (e.g. by getting proper dts from ffmpeg) [21:39:10] <divVerent> the chain of if conditions is exactly the failure condition of libavformat [21:40:03] <divVerent> (as I want to avoid doing such a hack unless I absolutely have to) [21:40:59] <divVerent> BTW... slightly off topic, but what IS a good VFR time base? [21:41:16] <bcoudurier> a timebase that can accurately represent all your timestamps [21:41:36] <divVerent> 24000fps seems somewhat good, as it can handle NTSC 24/1.001, PAL 25, and a lot of typical "computer frame rates" without ANY loss [21:41:42] <bcoudurier> and this applies to cfr as well [21:41:43] <divVerent> however, it can't handle NTSC 30/1.001 [21:41:46] <BBB> wbs: did you test that pressing 'a' switches correctly to the next audio stream with that patch? [21:41:58] <divVerent> but... I also know that the time base shouldn't have a denominator larger than 32767 :P [21:41:58] <bcoudurier> ie 1/1000 is crap [21:42:01] <BBB> wbs: and does -ast work correctly, i.e. start at the correct audiostream [21:42:06] <bcoudurier> 1/1000000 [21:42:14] <divVerent> fails for some containers I tried :P [21:42:14] <bcoudurier> should be safe [21:42:17] <BBB> wbs: and subscribe etc. is done correctly so ffplay only downloads that stresm we actually listen to at that time? [21:42:23] <bcoudurier> what fails ? [21:42:28] <divVerent> IIRC mp4 [21:42:43] <bcoudurier> it shouldn't [21:42:47] <wbs> BBB: yes [21:42:49] <BBB> wbs: particularly that last one [21:43:08] <BBB> wbs: you're not looping for building up the subscribe, so I'm affraid something like ffmpeg, which tries to download all streams and not just one, will still fail [21:43:23] <BBB> wbs: for ffmpeg, the subscribe string should basically enable all of them if we transcode all of them [21:43:41] <wbs> BBB: uh, I do exactly the same as before, except using ->id instead of ->priv_data to identify them? [21:43:58] <wbs> BBB: the subscribe commands are identical to before all of the priv_data restructuring [21:44:12] <BBB> hm, oh, you didn't remove the second loop anymore [21:44:14] <BBB> then it's fine [21:44:16] <BBB> sorry, missed it [21:44:29] <BBB> so can I drop the other two patches then? [21:44:37] <wbs> yes, they can be dropped [21:44:43] <divVerent> mpegvideo_enc.c e.g. allows at most a denominator of 65535 [21:44:49] <divVerent> because it is stored in 16 bit, I suppose [21:45:00] <divVerent> but I _think_ I saw this error with 32767 somewhere too [21:45:13] <bcoudurier> oh you meant mpeg-4 video [21:45:46] <divVerent> but anyway, the extra range from 32768 to 65535 doesn't contain any good "generic" time base numbers anyway [21:46:14] <BBB> hm the stream won't play here now [21:46:15] <BBB> odd [21:46:26] <wbs> yeah, the first stream doesn't seem to give any packets [21:46:30] <wbs> but with -ast 1 it works [21:47:04] <wbs> and you can switch streams with 'a' once, but once you switch to stream 0, you never get any more packets, and switching streams doesn't work (since the read function doesn't return and resubscribe) [21:52:43] <BBB> hm, indeed [21:52:44] <BBB> weird [21:52:48] <BBB> well, switching 2-3 works, so that's ok [21:53:13] <wbs> yeah, they're probably just not pushing any content into the lowest bandwidth version.. annoying ;P [21:53:26] <wbs> it's very low bandwidth at least ;P [21:54:39] <BBB> that is true [21:55:03] <BBB> I can just see how the brits would defend this as "cutting public spending by having extra-low bandwidth streams" [21:55:11] * BBB gives mru the look [21:55:54] <mru> the bbc actually cares a little about quality [21:56:15] <mru> they have _much_ better picture than the commercial channels [21:56:34] <kierank> mru: have you seen the 1080i@3mbit they push now [21:56:42] <kierank> mru: but yes on SD they're ok [21:56:47] <BBB> but does it look as good as that blonde dumb bimbo that is really pretty on fox news? [21:57:08] <mru> kierank: haven't seen those streams [21:57:32] <kierank> mru: on dvb-t2 they've dropped to main profile [21:58:14] <mru> I don't think we have that here yet [21:58:24] <BBB> wbs: thanks for fixing btw [21:58:36] <mru> the order they introduce new things across the uk is weird [21:58:42] <mru> first they do greater london [21:58:54] <mru> then they do some welsh backwater regions [21:59:04] <mru> then english backwaters and scotland [21:59:16] <mru> then places apart from london where people actually live [21:59:17] <BBB> ruggles, wbs: pushed [21:59:18] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r74b1f96859 ffmpeg/libavutil/x86/cpu.c: [21:59:18] <CIA-38> ffmpeg: Add check for Athlon64 and similar AMD processors with slow SSE2. [21:59:18] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [21:59:27] <kshishkov> mru: Leeds? [21:59:28] <CIA-38> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * rb2dd842d21 ffmpeg/libavformat/ (rdt.c rtsp.c rtspdec.c): (log message trimmed) [21:59:28] <CIA-38> ffmpeg: rtsp/rdt: Assign the RTSPStream index to AVStream->id [21:59:28] <CIA-38> ffmpeg: This is used for mapping AVStreams back to their corresponding [21:59:28] <CIA-38> ffmpeg: RTSPStream. Since d9c0510, the RTSPStream pointer isn't stored in [21:59:29] <CIA-38> ffmpeg: AVStream->priv_data any longer, breaking this mapping from AVStreams [21:59:29] <CIA-38> ffmpeg: to RTSPStreams. [21:59:30] <CIA-38> ffmpeg: Also, we don't need to clear the priv_data in rdt cleanup any longer, [21:59:30] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r2a03e87330 ffmpeg/libavcodec/avcodec.h: Add missing terminating backslash [21:59:37] <kierank> kshishkov: nobody lives there [22:00:15] * mru has been to bradford once [22:00:18] <mru> omg what a depressing place [22:00:36] <kierank> dover is worse [22:00:44] <kshishkov> mru: you know one guy from Newcastle [22:01:07] <mru> never been there [22:03:52] <kshishkov> mru: he's not eager to return there either. He settled in Germany for now [22:04:27] <mru> who are you referring to? [22:04:43] <kshishkov> Ivan from work [22:04:48] <mru> isn't he from london? [22:04:59] <kshishkov> not at all - Newcastle [22:05:12] <mru> he doesn't have a newcastle accent [22:05:41] <ruggles> apparently my last name comes from Rugeley in Staffordshire. [22:06:09] <mru> I've changed trains in stafford once [22:06:53] <kshishkov> and there's a guy from Derby [22:07:27] <_av500_> and newcastle brown ale [22:07:48] <mru> _av500_: straight from the pond [22:08:17] <_av500_> it was the beer in the junior commons room [22:08:48] <kshishkov> _av500_: remember where you live, it's not beer by your local standards [22:08:59] <_av500_> yup [23:07:38] <bcoudurier> is there a way to update the regression ref easily ? [23:07:54] <mru> yes [23:08:03] <mru> copy the +++ file from the diff to the --- one [23:08:18] <bcoudurier> ok, but I have 10*2 files to update [23:08:24] <bcoudurier> vsynth1 and vsynth2 [23:08:28] <mru> cp * [23:08:34] <mru> names are same [23:08:37] <bcoudurier> the suite fails at the first filaing [23:08:42] <mru> make -k [23:09:05] <bcoudurier> ahhhh [23:09:07] <bcoudurier> my saviour [23:09:08] <bcoudurier> thank [23:11:23] <bcoudurier> humm qtrle test is borked, it doesn't actually test qtrle, it tests mpeg4 :) [23:15:10] <mru> hmm [23:21:07] <bcoudurier> patch sent [23:32:33] <ruggles> bcoudurier: thanks. i noticed that a while ago and replied to the original commit in ffmpeg-cvslog but never got a response. [23:33:41] <spaam> nice m2ts patch.... ;D [23:34:38] <kierank> spaam: should rewrite the muxer first before doing that [23:34:57] <kierank> blu-ray players are picky as hell [23:35:31] <bcoudurier> I guess the guy tested his code [23:35:35] <mru> I don't understand how they manage to write the players like that [23:35:36] <bcoudurier> if he needed it [23:35:44] <mru> you've got to try _really_ hard to be that picky [23:36:23] <bcoudurier> mru the original file is yuv [23:36:23] <bcoudurier> to compare back you need yuv [23:36:26] <ruggles> the patch seems like a backwards diff... [23:36:39] <mru> he noticed [23:36:41] <spaam> but his patch is a bit wrong.. he remove stuff.. :) [23:37:05] <spaam> oh [23:37:37] <mru> bcoudurier: right [23:37:39] <bcoudurier> mru, I guess the good way of doing it would be to convert the test file in rgb [23:37:46] <mru> I see the other rgb codecs do the same [23:37:46] <bcoudurier> encode, decode, verify the lossless [23:37:50] <bcoudurier> (qtrle is lossless) [23:37:56] <spaam> is there a big diff between m2ts and ts? [23:38:03] <mru> spaam: 4 bytes [23:38:04] <spaam> container wise.. [23:38:06] <kierank> there's loads of silly things like new descriptors [23:38:07] <spaam> ok [23:38:11] <kierank> and a different timing model [23:38:29] <mru> kierank: somehow I doubt that patch contains all that [23:38:40] <kierank> of course [23:38:47] <mru> particularly since the existing muxer has no timing model at all [23:39:13] <bcoudurier> ask him how he tested it [23:39:24] <bcoudurier> I guess it works for him [23:39:38] <kierank> iirc you also have to pad to a mod 16 number of packets [23:39:39] <mru> you'd be surprised what people submit [23:40:05] <mru> presumably ffmpeg reads whatever it spits out [23:41:07] <mru> bcoudurier: verifying it really is lossless would be nice, but we'll do that another time [23:41:14] <mru> along with other similar cases [23:41:52] <kierank> "The first two bits are reserved for a copyright and should set to 11" --> that's wrong [23:44:34] <kierank> aahhhh thought he looked familiar: http://doom10.org/index.php?topic=1277.msg6342#new [23:47:33] <CIA-38> ffmpeg: Baptiste Coudurier <baptiste.coudurier(a)gmail.com> master * r646739a0a8 ffmpeg/tests/ (codec-regression.sh ref/vsynth1/qtrle ref/vsynth2/qtrle): [23:47:33] <CIA-38> ffmpeg: Fix qtrle regression test, actually test qtrle. [23:47:33] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com>

1 0

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

11 Feb '11

[03:22:24] <CIA-38> ffmpeg: David Fries <David(a)Fries.net> master * r00952be424 ffmpeg/libavformat/udp.c: [03:22:24] <CIA-38> ffmpeg: udp: Enable address reuse by default for multicast [03:22:24] <CIA-38> ffmpeg: Keep the original corner case behaviour, where reuse is enabled [03:22:24] <CIA-38> ffmpeg: for the case where no argument is given to the reuse url option. [03:22:24] <CIA-38> ffmpeg: Signed-off-by: Martin StorsjÃ¶ <martin(a)martin.st> [03:22:24] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [05:04:42] <Dark_Shikari> 5eb85d: f3 ab rep stos dwordes:[edi],eax [05:04:51] <Dark_Shikari> FFFFFFFFFFFFFFF gcc why are you using rep stos to store 16 BYTES. [05:19:47] <saintdev> Dark_Shikari just got trolled by gcc [05:28:21] * Sean_McG sighs [05:28:32] <Sean_McG> I wish I could defend gcc, but I can't [05:36:59] <saintdev> gcc says "Dark_Shikari: trollface.jpg" [06:17:37] <elenril> morning [06:18:08] <thresh> moroning [06:19:35] <Sean_McG> Thu Feb 10 01:19:35 EST 2011 [06:19:42] <Sean_McG> wee smalls [06:20:00] <thresh> EST == Estonian time? [06:20:21] <elenril> Sean_McG: your time is broken [06:22:27] <_av500_> thresh: didnt you switch to PCT? putin central time? [06:25:01] <thresh> _av500_: it's medvedev northern time, MNT [06:25:45] <elenril> wait, doesn't MNT mean.... [06:38:54] <thresh> ....what? [06:39:50] <elenril> the evil overlord timezone [06:40:12] <thresh> oh lol [06:42:03] <spaam> god morgon :D [06:57:36] <elenril> o_0 long subject is long [06:58:54] <Dark_Shikari> elenril: Accidentally put it on one line [06:59:08] <Dark_Shikari> git doesn't like it unless you put an extra line break between subject and commit message [06:59:49] <elenril> i thought it also rejects overlong subjects [06:59:52] <elenril> apparrently not [07:51:28] <lu_zero> good morning [08:08:45] <cartman> moin [08:26:06] <elenril> what's the purpose of index_built in AVFormatContext? [08:26:26] <elenril> git grep says it's not touched by any code in ffmpeg [08:27:37] <elenril> ....and the code setting it was removed 2 years ago [08:27:48] <elenril> so i guess i'll go ahead and deprecate it [08:27:50] * bilboed-tp hands elenril the broom [08:30:49] <av500> elenril: about the seek in asf [08:31:03] <av500> you now added the url_is_streamed() check [08:31:29] <DonDiego> elenril: nice to see you on a roll :) [08:31:54] <av500> elenril: ok, forget it :) [08:31:55] <elenril> DonDiego: exams! [08:32:17] <av500> elenril: but you now still delay asf startup time on a slow http link [08:41:13] * elenril kicks his isp [08:41:18] <elenril> what did i miss? [08:41:30] <spaam> elenril: nothing! [08:41:34] <lu_zero> hi superdump [08:41:46] <superdump> morning [08:43:09] <elenril> av500: so what did you want to know? [08:43:55] <av500> see ml [08:44:26] <elenril> :/ [08:44:50] <av500> [09:32:17] <av500> elenril: but you now still delay asf startup time on a slow http link [08:46:37] <elenril> well with current code you get the same delay on first seek [08:46:44] <elenril> which is worse imo [08:46:57] <wbs> except if you never seek [08:47:20] <wbs> OTOH, if you want fast startup, you can set the IGNIDX flag [08:47:59] <elenril> i admit that i don't do streaming much [08:48:06] <elenril> so i'll leave it up to your judgment [08:49:20] <av500> elenril: over here, I read avi and asf index in a separate thread :) [08:49:40] <av500> wbs: but with IGNIDX you have no index at all, no? [08:49:57] <wbs> no idea, but with that flag, the code elenril added isn't invoked at least [08:50:04] <av500> true [08:58:39] <elenril> and what's the purpose of AVFormatContext.packet_size? [08:59:07] <elenril> it seems it's only used by a few de/muxers [08:59:51] <elenril> is it useful to the users? [09:07:06] <elenril> ....actually only mpegenc uses the user-supplied value [09:07:28] <elenril> maybe it should be turned into a muxer-specific AVOption [09:07:57] <bilboed-tp> for mpeg-ts maybe ? [09:08:08] <astrange> it should be useful for anything used in the same situations as mpeg-ts [09:08:10] <av500> ps, no? [09:08:19] <astrange> but i guess people just use ts for everything? [09:08:39] <av500> yes, apple uses it to stream mov :) [09:10:39] <av500> mpegenc is the ps muxer, not the ts one [09:11:31] <av500> ffmpeg.c does not set that value either [09:13:34] <lu_zero> hi Flameeyes [09:14:16] <Flameeyes> hi lu_zero [09:14:22] * Flameeyes hopes quassel won't suicide again [09:14:22] <DonDiego> bilboed-tp: hey, what version of ffmpeg does gstreamer use? [09:14:31] <av500> Flameeyes: http://www.twoflavours.com/blogimages/dymowaxseal/DSC_0021.jpg [09:14:31] <Flameeyes> care to tell me why you haven't answered skype? [09:14:51] <bilboed-tp> DonDiego, in git we bumped to the last svn revision (still using the svn repo) [09:14:58] <bilboed-tp> DonDiego, let me check what the last release uses [09:15:01] <lu_zero> I guess skype ate you message... [09:15:15] <Flameeyes> av500: heh old-style dymo :) I remember seeing those a long time ago â they also were bloody expensive :D [09:15:17] <lu_zero> since I don't even see you up... [09:15:36] <Flameeyes> terrific [09:15:48] <Flameeyes> lu_zero: [OT] have you looked at the feng man pages? [09:15:58] <bilboed-tp> DonDiego, 23623 for the last release [09:15:59] <bilboed-tp> DonDiego, from the 0.6 branch [09:16:09] <DonDiego> ok, thx [09:21:47] <kshishkov> DonDiego: http://stallman.org/articles/xemacs.origin [09:22:46] <DonDiego> kshishkov: any particular reason to point that out to me now? i know about the emacs split in general... [09:24:25] <kshishkov> DonDiego: it's just funny and reminds me of other split [09:25:06] * Flameeyes tries to guess whether lu_zero is still awake or fell asleep [09:27:31] <superdump> narcolepsy [09:27:52] <Flameeyes> superdump: nah it's more that Luca lives on his own timezone most of the time [09:28:02] <Flameeyes> well I do much the same as well.. [09:40:30] <kshishkov> mate! [09:42:03] <pross-au> gday [09:43:05] <kshishkov> BTW, I should remind you that there are no people with game codec experience so your patch won't be reviewed [09:44:15] <pross-au> Aye [09:49:14] <elenril> also when the review is finished, there will be cake [10:00:11] <Flameeyes> mru: list of software using libav* in Gentoo: http://paste.pocoo.org/show/335605/ [10:01:11] <Flameeyes> the only one looking fishy is wxsvg but it uses _all_ the libs anyway [10:01:11] <av500> wow, ffplay [10:01:28] <cartman> av500: a recent ruling in Munich court says Turks can stay in Germany for 3 months without a visa [10:01:37] <cartman> you'll be happy to hear that :P [10:01:37] <av500> cartman: and? [10:01:54] <cartman> more dÃ¶ner with horse meat! [10:04:04] <astrange> Flameeyes: doesn't detect mplayer [10:05:57] <jannau> astrange: mplayer uses probably a private copy [10:08:09] <cartman> absolutely it does [10:08:10] <jannau> Flameeyes: can you create seperate lists for libavutil and libavcodec? and libavcore for the lulz? [10:08:11] <astrange> yes, but if the list is used to check private API use then mplayer still counts as a client [10:08:44] <kshishkov> as an abuser [10:09:06] <Flameeyes> astrange: not used for that, more for identify who links to libavcore :P [10:09:25] <Flameeyes> jannau: I can give you the raw data that include the needed entries [10:09:54] <peloverde> the list is missing audacity (dlopens ffmpeg) [10:09:58] <jannau> astrange: I think mru asked for something that uses libavutil bit not any other lib [10:10:01] <Flameeyes> jannau: http://paste.pocoo.org/show/335612/ [10:10:14] <Flameeyes> peloverde: this is a list of NEEDED entries, no dynamic link involved obviously [10:10:39] <peloverde> ok [10:11:01] <Flameeyes> and tbh, bundled copies and dynamic links are not exactly high on my priority list of things to keep from breaking [10:11:16] <Flameeyes> sorry let me qualify [10:11:46] <Flameeyes> _unavoidable_ bundled copies and dynamic links [10:13:16] <jannau> mediatomb uses libavformat without libavcodec [10:13:20] <siretart> peloverde: IIRC there is someone in Debian's pkg-multimedia team working on a patch to make audacity link dynamically against libavcodec [10:13:34] <siretart> jannau: impossible, as libavformat links against libavcodec [10:13:36] <Flameeyes> siretart: you mean statically I guess [10:13:46] <siretart> Flameeyes: I mean without dlopen [10:13:54] <Flameeyes> siretart: then you mean static link to dynamic library :) [10:14:03] <pross-au> libavgrabbag? [10:14:08] <siretart> now you confuse me [10:14:50] * elenril thinks Flameeyes likes confusing people with his advanced elf-fu [10:15:23] <jannau> siretart: iKnow. from Flameeyes raw data: libmysqlclient_r.so.16,libz.so.1,libpthread.so.0,libtag.so.1,libmozjs.so,libmagic.so.1,libexif.so.12,libavformat.so.52,libavutil.so.50,libexpat.so.1,libmp4v2.so.1,libcurl.so.4,libstdc++.so.6,libgcc_s.so.1,libc.so.6 /usr/bin/mediatomb [10:15:45] <Flameeyes> siretart: -Bstatic -lfoo â static link to static library (libfoo.a); -Bdynamic -lfoo â static link to dynamic library (libfoo.so); dlopen("libfoo.so") â dynamic link to dynamic library [10:16:17] <siretart> Flameeyes: yeah, I see. [10:16:45] <{V}> how is linking to libavcodec at buildtime an improvement over using dlopen [10:16:50] <jannau> ok, there's no standalone user of libavutil in Flameeyes set [10:17:26] <Flameeyes> {V}: it's resolved at startup rather than further down the road, PLT is updated at once, and whether it forks before or after dlopen() it doesn't have to CoW it [10:18:03] <Flameeyes> and in both Debian's and Gentoo's cases is easier to make sure that it is linked to the latest version of ffmpeg [10:18:16] <pross-au> {V}: the program can choose to function, even if the library is missing [10:19:00] <{V}> pross-au, err.. that's when using dlopen. Not when linking at buildtime. [10:19:12] <Flameeyes> pross-au: that's quite relative, it works fine for universal binary cases, but in Gentoo it's just an extra cost for no good reason [10:20:04] <pross-au> ah okay [10:41:42] <kierank> spaam: committed any libavseq changes yet [10:43:07] <kierank> I'm suddenly reminded of bastycdgs insistence of calling every email to the ml a "commit" [10:44:14] <wbs> kierank: argh, that was annoying :-) [10:47:47] <av500> kierank: patch commited to mailing list [10:49:21] <kierank> damn should have asked bcoudurier about -708 while he was awake [10:51:09] <spaam> kierank: no =/ [10:51:10] <kierank> av500: that phrase is very confusing [10:51:36] <av500> kierank: tell basty [10:52:31] <spaam> wbs: klart du vill ha avseq ;D [10:52:49] <spaam> wbs: you will be the number one commiter ;) [10:53:20] <wbs> spaam: ugh ;P [10:54:37] <spaam> wbs: and you are welcome to join our crew CDGS with basty, me and kierank ;) [10:54:56] <kierank> spaam: only as an associate member [10:55:02] <spaam> ofc [10:55:21] <kierank> needs further amiga training before becoming a provisional member [10:55:34] <kierank> then a course in "optimisations" to become a full member [10:56:51] <kierank> the full title is "optimising useless codecs" [10:57:28] <spaam> wbs: you like that title? ;) [10:57:49] <wbs> spaam: I'm delighted [10:57:53] <kshishkov> i.e. rewriting C code into slightly optimised 68k ASM [10:58:33] <kierank> why write in C when you can write in ASM [10:59:26] <kshishkov> because C code exists [11:00:21] <kierank> kshishkov: pssh you're never going to become a full CDGS member with that attitude [11:00:31] <kshishkov> not that I case [11:00:34] <kshishkov> *care [11:01:48] <cartman> CDGS? [11:02:44] <j-b> 'moroning [11:02:45] <kierank> Coders Design Glorious Software or something like that [11:03:38] <kshishkov> j-b: still in Berlin? [11:04:00] <kshishkov> j-b: which is twinned with Bruxelle if you don't know [11:04:58] <kierank> kshishkov: I have met a second ukranian who has left because of dislike of his homeland [11:06:14] <j-b> kshishkov: I am back [11:06:38] <kshishkov> kierank: where? (and who was the first one?) [11:06:43] <kshishkov> j-b: congrats! [11:07:00] <kierank> kshishkov: well first then since i haven't technically met you [11:07:10] <kshishkov> j-b: though I suspect Paris is similar to them both [11:07:14] <kierank> kshishkov: a friend of a friend [11:08:50] <kierank> j-b: will computermodules send me an sdi card if I ask for one? [11:09:37] <kshishkov> kierank: if your credit card asks then maybe [11:10:05] <j-b> kierank: I doubt it. but ask [11:10:18] <j-b> kierank: less cold [11:10:24] <kierank> my current sdi card only works on linux :/ [11:10:26] <kierank> i mean windows [11:10:53] <j-b> kshishkov: less cold [11:10:57] <j-b> kshishkov: decklink? [11:11:14] <kierank> j-b: osprey [11:15:49] <lu_zero> j-b: decklink works ok on linux [11:16:02] <lu_zero> btw remind me to stab the player patch for vlc as well [11:16:17] <j-b> stab? [11:16:18] * lu_zero currently made some quite bare player [11:16:35] <lu_zero> j-b: shape it up if it hadn't been already fixed [11:16:54] <kierank> lu_zero: that's the one with the c++ driver? [11:17:02] <j-b> kierank: yes [11:17:13] <j-b> lu_zero: no idea if it has been improved, indeed [11:27:54] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rd42b09723e ffmpeg/libavformat/asfdec.c: [11:27:54] <CIA-38> ffmpeg: asfdec: move DAR list to ASFContext [11:27:54] <CIA-38> ffmpeg: This will be useful for splitting asf_read_header() [11:27:54] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [11:28:06] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r7c7253802b ffmpeg/libavformat/asfdec.c: [11:28:06] <CIA-38> ffmpeg: asfdec: use an ASFContext array for storing stream bitrates [11:28:06] <CIA-38> ffmpeg: This will be useful for splitting asf_read_header() [11:28:06] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [11:30:59] <kierank> erm a bit delayed [11:32:29] <Dark_Shikari> BBB: patch review please [11:32:45] <BBB> Dark_Shikari: the bottom part is unrelated [11:32:54] <BBB> (I was already looking at it) [11:34:47] <BBB> Dark_Shikari: it's a little difficult to see what you did because you moved the function, what's the difference? [11:34:48] <Dark_Shikari> That was an accident, it'll be removed from the real patch. [11:34:51] <Dark_Shikari> It was some hacky code in it [11:34:57] <Dark_Shikari> because read_time wasn't being inlined [11:34:59] <Dark_Shikari> just testing [11:35:28] <BBB> it inlines the get_prob() things in the decode_mv() (what used to be find_near_mv()) function so that some steps are only done when they are necessary [11:35:29] <BBB> ? [11:35:34] <Dark_Shikari> on a related note, we need to inline av_clip_c [11:35:37] <Dark_Shikari> er, always_inline [11:35:40] <Dark_Shikari> yes [11:35:50] <Dark_Shikari> basically previously we did: [11:35:50] <av500> peloverde_: and we have that API/ABI breaking reputation to live up to, no? [11:35:51] <Dark_Shikari> 1) all mv pred [11:35:53] <Dark_Shikari> 2) all decoding [11:35:55] <Dark_Shikari> now we do [11:36:03] <Dark_Shikari> 1) the bare minimum mv pred required to decode the CNT_ZERO bit [11:36:06] <Dark_Shikari> 2) CNT_ZERO bit [11:36:12] <Dark_Shikari> 3) the bare minimum required to decode CNT_NEAREST [11:36:15] <Dark_Shikari> 4) CNT_NEAREST [11:36:16] <Dark_Shikari> etc [11:36:25] <Dark_Shikari> So we postpone everything as late as possible. [11:36:28] <BBB> Dark_Shikari: yeah, you mentioned that yesterday, please send a patch :-p I Can't believe it's not inlined, typical gcc... [11:36:43] <Dark_Shikari> It's not inlined because the file has so many inline functions [11:36:48] <Dark_Shikari> that it triggers the maximum inlining threshold [11:36:52] <Dark_Shikari> ... this might be fixed on recent gcc. [11:36:55] <Dark_Shikari> I'm using 4.3.4 [11:37:11] <Dark_Shikari> Anyways, I fixed that random shit that got in the patch [11:38:15] <Dark_Shikari> there might be some optimization that can be done of MV_EDGE_CHECK. [11:38:17] <BBB> I'm just teasing about that part :-p [11:38:36] <Dark_Shikari> I still don't like having to manually zero all the stuff at the start. [11:38:49] <Dark_Shikari> Oh yeah, and gcc used "rep stos" to zero near_mv originally. [11:38:53] <Dark_Shikari> aka "ARE YOU CRAZY" [11:39:02] <Dark_Shikari> (It's a function with a huge startup time) [11:39:02] <BBB> I noticed the AV_ZERO32(), nice catch [11:39:08] <Dark_Shikari> Note: it doesn't zero [3] [11:39:20] <Dark_Shikari> If you look carefully you'll notice it doesn't need to be zeroed. [11:39:27] <kierank> Dark_Shikari: what should gcc be using instead of rep stos? [11:39:31] <BBB> true [11:39:38] <BBB> kierank: stosd? [11:39:41] <BBB> stosq? [11:40:01] <Dark_Shikari> .... mov [11:40:05] <BBB> Dark_Shikari: use AV_ZERO64()+AVZERO32() instead of 3x AV_ZERO32() [11:40:05] <Dark_Shikari> it's zeroing 16 bytes. [11:40:10] <Dark_Shikari> BBB: it's not aligned enough [11:40:13] <BBB> oh [11:40:18] <BBB> fuck it [11:40:20] <BBB> :) [11:40:25] <Dark_Shikari> additionally, I don't know if that will cause load/store forwarding penalties [11:40:31] <Dark_Shikari> because they're accessed as 32-bit values. [11:40:37] <Dark_Shikari> storing as 64-bit RIGHT BEFORE they are used might be bad. [11:40:45] <Dark_Shikari> Oh also, another thing improved by my changes [11:40:52] <Dark_Shikari> previously, near_mv[] and the mv array in find_near_mvs were different [11:40:55] <Dark_Shikari> so, at the end, we had to do [11:41:03] <Dark_Shikari> near_mv[0] = near[CNT_NEAREST] [11:41:06] <Dark_Shikari> near_mv[1] = near[CNT_NEAR] [11:41:08] <Dark_Shikari> two pointless copies. [11:41:19] <BBB> yes, I wrote that, that part was ugly [11:41:19] <Dark_Shikari> I originally fixed this by passing in a pointer to near_mv and making that [4] instead [11:41:27] <Dark_Shikari> But then I just said fuck it and merged the functions. [11:41:30] <BBB> I think this is the first function I wrote, so I was like "oh well who cares" [11:41:52] <BBB> (I've noticed it comes up in profiling, kind of embarassng) [11:41:58] <Dark_Shikari> I can't really time it very well here [11:42:01] <Dark_Shikari> I think I saved at least 30-40 clocks [11:42:05] <Dark_Shikari> I suggest you time it if you're curious [11:42:18] <BBB> I'll time it, it'd help if you did that too ;) [11:42:36] <Dark_Shikari> I did, but my computer isn't stable enough [11:42:39] <Dark_Shikari> the timings are all over. [11:42:43] <BBB> it looks interesting, I might suggest that you don't move the function so it's easier to see what changed in the patch [11:42:46] <Dark_Shikari> I can tell it's DEFINITELY faster but I don't know much. [11:42:48] <Dark_Shikari> I have to move it. [11:42:55] <Dark_Shikari> Otherwise I'd need a forward declaration of decode_split_mvs [11:42:57] <BBB> because of clamp_mv()? [11:43:01] <BBB> oh that one [11:43:03] <BBB> hm, ok [11:43:07] <BBB> nm then, I'll tiem it [11:43:19] <BBB> get a shell on a computer with a stable timer :-p [11:47:51] <siretart> for friends of cross compiling that hate libtool: http://thread.gmane.org/gmane.linux.linaro.devel/2239 [11:49:46] <Flameeyes> siretart: you don't read my blog, do you? ;) [11:49:55] <mru> or my rants [11:50:31] <Flameeyes> which reminds me I need to get again to look at venus [11:50:38] <Flameeyes> last time I checked it was crap, I wanted to create planet.multimedia.cx [11:50:44] <andoma> when it come to build systems and makefiles mru is my god [11:50:51] <Flameeyes> [already asked Mike if the domain sounded good] [11:52:58] <spaam> andoma: mru our hero [11:53:02] <andoma> ! [11:53:09] <spaam> all hail mru ! [11:53:14] <pross-au> venus? [11:53:16] <kshishkov> spaam: and of proper nationality too! [11:53:30] <spaam> kshishkov: the best part :) [11:55:09] <kshishkov> spaam: now only to make that guy to put more spots on FFmpeg code [11:56:41] <Flameeyes> pross-au: blog aggregator software [11:58:00] <spaam> Flameeyes: is it written in ruby? [11:58:07] <kshishkov> Flameeyes: the problem is that there's almost nothing to aggregate [11:58:18] <Flameeyes> spaam: worse, python [11:58:48] <cartman> Flameeyes: stop bashing python :P [11:58:50] <Flameeyes> kshishkov: there's your blog, mike's, mru's and mine.. and the gst guys tend to blog a lot [11:59:21] <kshishkov> Flameeyes: look at sidebar on spectralhole.blogspot.com [11:59:36] <kshishkov> and I'd feel uneasy being aggregated with gst [11:59:36] <Flameeyes> cartman: sigh, I can't deal with that language, it's the bloody lack of an "end" keyword for me [12:00:01] <cartman> bah :) [12:00:08] <mru> significant whitespace, yuck [12:00:18] <cartman> lgtm [12:00:19] <cartman> ;P [12:00:26] <pross-au> blog post quantity is inversely proportional to productivity right? [12:00:39] <Flameeyes> pross-au: depends how you define productivity [12:00:49] * Flameeyes is vastly a doc person so writing _is_ productivity [12:01:16] <Flameeyes> kshishkov: okay so that's at least a starting point, ain't it? :) [12:02:17] <Dark_Shikari> BBB: poke for benchies [12:02:22] <BBB> in a bit [12:02:25] <Dark_Shikari> k [12:04:20] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rd7a5106eb2 ffmpeg/libavformat/asfdec.c: [12:04:20] <CIA-38> ffmpeg: asfdec: skip the stream bitrate list [12:04:20] <CIA-38> ffmpeg: Its contents aren't used for anything. [12:04:20] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [12:05:26] <KotH> grüezi [12:05:31] <spaam> hey KotH [12:05:55] <BBB> Dark_Shikari: baby needs food, me needs food, then me needs to go to work and set something up early, then I do benchies for you [12:06:00] <BBB> then ??? then $$profit$$ [12:06:09] <BBB> :-p [12:06:20] <Dark_Shikari> no problem =p [12:08:04] <wbs> it's good as long as you have $$profit$$ somewhere on your roadmap, even if there are a few unknown steps leading up to that ;P [12:11:24] <BBB> yeah, highly volatile $$profit$$, maybe EUREURprofitEUREUR is better [12:11:47] * BBB can't find the EUR on his keyboard [12:11:54] <av500> here: â¬ [12:11:54] <kshishkov> â¬â¬â¬ [12:12:07] <kshishkov> BBB: I use compose-=-e [12:12:47] <BBB> my kb is american english, it probably doesn't have that [12:13:00] <kshishkov> mine is too [12:13:02] <BBB> compose-= gives me â [12:13:28] <kshishkov> compose=e [12:13:29] * mru uses Â£ [12:13:49] <kshishkov> and are you on MacOSX by any chance? [12:14:54] <kshishkov> if so try option-shift-2 [12:15:43] <Flameeyes> kshishkov: it's C= [12:16:32] <Tjoppen> â¬â¬profitâ¬â¬ [12:17:14] <kshishkov> Flameeyes: looks like there are many ways to get it Ã³Ã² [12:17:37] <Tjoppen> Â€_Â€ [12:18:15] <Flameeyes> kshishkov: well it is a C with a = sign impressed over it :P [12:18:38] <av500> the c64 logo? [12:19:07] <Tjoppen> the quake 2 logo turned sideways? [12:19:52] <kshishkov> Flameeyes: and slanted! don't froget proper slant degree and alignment! [12:20:02] <kshishkov> *forget [12:21:16] <Flameeyes> kshishkov: don't remind me of the stupid artistics concerns and the winner of the "commemorative" â¬1 coin [12:22:05] <kshishkov> Flameeyes: I like 5SEK coin [12:22:26] <Flameeyes> kshishkov: have you ever seen the commemorative coin? [12:23:22] <Flameeyes> kshishkov: sorry that was â¬2... http://en.wikipedia.org/wiki/File:%E2%82%AC2_commemorative_coin_UEM_2009_Ge… [12:23:47] <Flameeyes> and no, it's not like many thought, that it was a kid's drawing.. that's an "artist" [12:24:28] <av500> nice, Emulated Money Unit [12:24:31] <Tjoppen> derp [12:25:23] <kshishkov> Flameeyes: that's really greedy hand he has... [12:25:30] <mru> Flameeyes: yeah, one of the most renowned artists of the neolithic era [13:11:07] <CIA-38> ffmpeg: Kostya Shishkov <kostya.shishkov(a)gmail.com> release/0.5 * r44511b17cb ffmpeg/libavcodec/rv34.c: [13:11:07] <CIA-38> ffmpeg: Update dimensions in AVCodecContext when RV3/4 frame dimensions change [13:11:07] <CIA-38> ffmpeg: Originally committed as revision 20572 to svn://svn.ffmpeg.org/ffmpeg/trunk [13:11:07] <CIA-38> ffmpeg: (cherry picked from commit ec10d2d53999f6edf7d7b5ac88df263eccfb1fb0) [13:11:07] <CIA-38> ffmpeg: Fixes heap corruption crashes [13:11:07] <CIA-38> ffmpeg: Addresses: CVE-2011-0722 [13:11:08] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart(a)tauware.de> [13:11:20] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> release/0.5 * r9109a58867 ffmpeg/ (38 files in 38 dirs): [13:11:20] <CIA-38> ffmpeg: convert svn:ignore properties to .gitignore files [13:11:20] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [13:11:20] <CIA-38> ffmpeg: (cherry picked from commit 348b8218f7a59374355c966dbe3b851a7275f952) [13:11:20] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart(a)tauware.de> [13:11:21] <CIA-38> ffmpeg: Reinhard Tartler <siretart(a)tauware.de> release/0.5 * re332c41670 ffmpeg/.gitignore: also ignore *.so for vhook plugins [13:11:23] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> release/0.5 * r11f6eebdd3 ffmpeg/ (38 files in 38 dirs): [13:11:24] <CIA-38> ffmpeg: consolidate .gitignore patters into a single file [13:11:24] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [13:11:24] <CIA-38> ffmpeg: (cherry picked from commit 2c3589bfda036c7827ded0bf38b16dfe7630bae1) [13:11:24] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart(a)tauware.de> [13:11:28] <CIA-38> ffmpeg: Michael Niedermayer <michaelni(a)gmx.at> release/0.5 * r48b086b0ef ffmpeg/libavcodec/utils.c: [13:11:28] <CIA-38> ffmpeg: Update safety check as the maximum pixel size is no longer 4. [13:11:28] <CIA-38> ffmpeg: New max size is 16bit * 4 samples (RGBA). [13:11:28] <CIA-38> ffmpeg: Originally committed as revision 18655 to svn://svn.ffmpeg.org/ffmpeg/trunk [13:11:29] <CIA-38> ffmpeg: (cherry picked from commit 445f0a8b666a34e6402f6ae96c6804c8bc024baa) [13:11:29] <CIA-38> ffmpeg: Addresses: CVE-2010-3908 [13:11:30] <CIA-38> ffmpeg: Signed-off-by: Reinhard Tartler <siretart(a)tauware.de> [13:12:13] <elenril> huh? [13:12:40] <kshishkov> somebody is rolling new 0.5 release? [13:13:07] <thresh> sometart [13:13:46] <Orphis> For those interested, the first useful report of the win64 build has been done [13:14:14] <kshishkov> ÐœÑÐœ! [13:14:43] <kshishkov> not on fate.ffmpeg.org yet [13:15:10] <Orphis> And I'm thinking of moving to a linux build and transfer the build onto the windows box and run the test directly there [13:15:28] <Orphis> http://fate.ffmpeg.org/x86_64-mingw-w64-gcc-4.5/20110210122230 [13:16:08] <kshishkov> OS: mingw32 <- that's a bit confusing [13:16:36] <siretart> kshishkov: yes, I am [13:16:36] <Orphis> Is kostylev here ? I might be interested in getting his rpc.wrapper to remotely run the test on the windows box [13:16:58] <Orphis> Yes, but that's how the platform is called in the configure :p [13:32:23] <Flameeyes> mru: can I ask your opinion on a possible feature of my ruby-elf tools? :) [13:35:04] <mru> Flameeyes: ask away [13:35:49] <Flameeyes> mru: have you seen the output of rbelf-size I posted for libavcodec? do you think it might be worth adding a --differential switch so that the first argument is used as baseline, and the other are expressed as +x or -y in the columns? [13:36:21] <mru> I suppose that could be handy [13:36:49] <cartman> Orphis: awesome! [13:37:16] * Flameeyes starts to think how to easily implement that [13:37:28] <Flameeyes> thankfully implementing a different thing altogether made it much easier to deal with that :) [13:38:48] <cartman> why does chinese guys set reported display dpi to 25 is beyond me [13:39:28] <Flameeyes> cartman: 'cause chinese fonts are impossible to read at small point sizes? [13:39:48] <cartman> Flameeyes: at 25dpi I get the smallest fonts ever [13:39:55] <cartman> should 160 or more [13:39:57] <cartman> to be sane [13:40:01] <mru> Orphis: looks like you're missing zlib [13:40:17] <Flameeyes> cartman: hrm... dpi always escape me =_= [13:40:21] * mru stabs fonts scaling with dpi [13:40:24] <cartman> Flameeyes: ;> [13:40:46] <mru> I know how many _pixels_ I want, dammit [13:40:48] <Flameeyes> dpi â \Flameeyes [13:40:59] <av500> "....Writing configure scripts by hand is error prone and no fun at all..." [13:41:01] <cartman> hahah [13:41:22] <mru> av500: depends on how you write them [13:41:24] <cartman> av500: mru in the parallel universe said that [13:41:37] <av500> mru: from one of the ELCE talks [13:41:44] <mru> cartman: orthogonal universe more likely [13:41:53] <Flameeyes> av500: mru: depends also on _who_ writes them [13:41:54] <cartman> mru: ah true ;P [13:42:21] <Flameeyes> i.e. if the author is a kde dev, a manual configure would be probably very much messed up, seeing the kde3 build system >_< [13:42:26] <cartman> mru: had a chance to read your "discussion" with pbrook [13:42:35] <cartman> about codesourcery toolchain [13:42:37] <kshishkov> Flameeyes: autotools! [13:42:45] <Flameeyes> kshishkov: no, kde3 wasn't autotools [13:42:47] <Flameeyes> was autohell [13:43:04] <cartman> Flameeyes: make -f admin/Makefile.cvs [13:43:05] <cartman> or something [13:43:07] <cartman> heheh [13:43:45] <Flameeyes> cartman: and only with the right _micro_ version of the proper tools patched by SuSE... [13:43:55] <cartman> ;> [13:44:08] <Flameeyes> damn C++ libraries, why do they have to export so many bloody symbols? :( [13:44:32] <andoma> because c++ sucks [13:44:35] <av500> because c++ is overloaded with symbols [13:44:45] <Flameeyes> it was a rethoric question guys :) [13:44:51] <cartman> because you let them do that [13:44:55] <andoma> it still sucks :) [13:45:10] <lu_zero> we should chat more with kde people [13:45:24] <lu_zero> regarding on having all kde using ffconf [13:47:13] <mru> let's abduct lydia next time then [13:47:17] <mru> won't be hard... [13:48:13] <Flameeyes> I somehow doubt she's going to be able to put some sense into the buildsystem guys [13:48:23] <lu_zero> lydia will kill us sooner or later [13:48:43] <Flameeyes> o_O what the heck happened at fosdem? [13:49:20] * mru did nothing [13:49:31] <mru> well, I did sort of suggest we might troll her talk [13:49:35] <mru> then we didn't [13:50:10] <av500> whatshe talk about? [13:50:18] <av500> kdvp8? [13:50:25] <mru> don't know [13:50:33] <mru> as I said, we didn't troll it [13:52:27] <jannau> "Let me teach you how to fish!" [13:52:45] <av500> hand grenade? [13:53:10] <kshishkov> Holy Hand Grenade of Antioch [13:53:31] <mru> jannau: she's so... girly [13:53:57] <siretart> HHGoA? [13:56:23] <mru> kshishkov: that's for rabbits, not fish [13:57:27] <kshishkov> mru: it's for all kinds of enemies [13:57:41] <kshishkov> just read Book of Arms [13:57:43] <DonDiego> so lydia has got herself an fffanbase? :) [13:58:09] <mru> DonDiego: that happened years ago [13:58:22] <mru> I guess since that time we shared booth at linuxtag [13:59:16] <DonDiego> when did we share booth with kde? [13:59:24] <DonDiego> the year i did not attend? [13:59:43] <mru> 2007 iirc [13:59:55] <mru> not with kde, with amarok [13:59:56] <kshishkov> DonDiego: yes, otherwise you'd have spotted a girl next to you [14:00:20] * mru should've taken a photo of her next to kshishkov... [14:00:27] <mru> that looked kinda funny [14:00:47] <cartman> mru: post it! [14:00:54] <Flameeyes> cartman: he didn't take it :P [14:00:58] <kshishkov> mru: you have reference av500 instead [14:01:06] <DonDiego> haha, yes, kostya has 3-4 times the volume :) [14:01:07] <cartman> Flameeyes: damn [14:02:18] <kshishkov> DonDiego: and I have not found out who has the biggest ego - Argentinians, Swiss or people from Moscow [14:02:38] <DonDiego> haha, where did that come from now? :) [14:02:47] <cartman> possibly Swiss [14:02:49] <thresh> yeah, why arent we the only ones? [14:03:07] <Flameeyes> kshishkov: where did you put Italy? [14:03:18] <mru> kshishkov: none of those, it's schilling [14:03:28] <DonDiego> bcoudurier: Maksym Veremeyenko is desperately trying to ping you for patch review... [14:03:29] <cartman> hahah [14:03:59] <kshishkov> mru: how much is that in IJGs? [14:04:08] <Flameeyes> mru: followed by drepper? [14:04:32] <mru> Flameeyes: drepper at least works on something that everybody uses [14:04:33] <kshishkov> mru: also it's the name for pre-Euro Austrian currency, isn't it? [14:04:38] <Flameeyes> mru: good point [14:06:15] <Flameeyes> gha! haskell libraries are even worse than C++ [14:06:36] <mru> s/gha/ghc/ ? [14:07:00] <Flameeyes> more or less yes [14:07:21] <Flameeyes> btw "how surprising" that a bunch of stuff beaks with glibc-2.13 [14:07:38] <Flameeyes> didn't memcpy() tell you not to use it on overlapping areas since ... ever? [14:07:55] <mru> that one never gets old... [14:08:11] <cartman> Flameeyes: Flash developers didn't get the memo [14:08:16] <mru> btw, gcc emits invalid memcpy() calls all by itself [14:08:20] <Flameeyes> cartman: qt-webkit as well [14:08:31] <cartman> Flameeyes: lulz at that one [14:08:37] <mru> struct foo *a, *b; ...; a = b; ...; *a = *b; [14:09:00] <Flameeyes> mru: uhm terrific [14:09:13] <mru> gcc sometimes turns that into memcpy(a, b) [14:18:25] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r628b16f45f ffmpeg/libavformat/mov.c: [14:18:25] <CIA-38> ffmpeg: mov: remove stray semicolon [14:18:25] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:18:34] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rdbb09ec23f ffmpeg/libavcodec/ivi_dsp.c: [14:18:34] <CIA-38> ffmpeg: ivi_dsp: remove semicolons after function definitions [14:18:34] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:18:38] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rb4668274b9 ffmpeg/libavcodec/utils.c: [14:18:38] <CIA-38> ffmpeg: Remove incorrect return statement from avcodec_thread_free() [14:18:38] <CIA-38> ffmpeg: The function return type is void, so a return statement with an [14:18:38] <CIA-38> ffmpeg: expression is forbidden (and pointless). [14:18:38] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:33:21] * Dark_Shikari pokes BBB again [15:09:57] <cartman> av500: rockplayer guys seems to have some AAC decoder changes mostly. [15:10:10] <av500> and some dca stuff [15:10:20] <av500> cartman: did you find out the exact svn rev? [15:10:42] <cartman> av500: nah, just took the Jun 14 first commit as the base [15:11:07] <av500> 16th [15:11:25] <cartman> or that, sucks they didn't document it [15:11:48] <av500> its before 22830 according the Changelog [15:12:29] <cartman> might as well just ask tjem [15:12:31] <cartman> them* [15:13:41] <Compn> Dark_Shikari : still got contacts at facebook ? i wonder if they have any new bugs/fourcc/samples to share with ffmpeg ? [15:15:22] <av500> cartman: aac? [15:16:09] <cartman> av500: yes? [15:28:50] <BBB> Dark_Shikari: yes, working on my work thing, after I'm done and that's moving, I'll work on this, I promise it'll be today [15:29:57] <Dark_Shikari> No problem. [15:29:59] <Dark_Shikari> Compn: nope [15:30:01] <elenril> in dangerous testing environments the enrichment center promises to always provide useful advice [15:38:53] <mru> BBB: could you take a look at my 2 remaining vp8 patches? [15:40:01] <BBB> kshishkov already OK'ed them, no? [15:40:03] <BBB> at least 3/3 [15:40:37] <mru> are you ok with the vp8.c parts? [15:42:18] <BBB> rename vp8_dct_ to ff_vp8_dct_... and include arm/vp8.h? yes, that's ok [15:42:54] <mru> and the rac patch? [15:43:04] <BBB> I can't find that one, annoyingly [15:43:11] <BBB> what's the thread name? [15:43:15] <mru> same thread [15:43:21] <mru> patchwork should have links to gmane [15:45:31] <BBB> that's just vp56.h, but that's ok, yes. makes me wonder if we should do that for x86 also [15:45:40] <Dark_Shikari> ? [15:46:11] <BBB> Dark_Shikari: vp56_rac_get_prob_branchy() asm [15:46:22] <BBB> instead of the non-branchy one, which you wrote asm for [15:47:29] <Dark_Shikari> But isn't the whole point of _branchy that it needs to be inlined? [15:47:34] <Dark_Shikari> so that gcc can put the if/else on the right sides [15:48:19] <BBB> inline asm, of course [15:48:25] <Dark_Shikari> But what are you going to inline asm? [15:48:27] <Dark_Shikari> It doesn't need a cmov. [15:48:41] <BBB> I don't know, maybe gcc generates quite good code here [15:48:49] <mru> it didn't on arm [15:49:04] <Dark_Shikari> well duh it's gcc [15:49:12] <mru> partially because it doesn't know the limited ranges of various values [15:49:16] <Flameeyes> BBB: stop smoking pot ;) [15:49:21] <Dark_Shikari> using inline asm for things like that on arm bugs me though, because arm requires smarter scheduling than x86 [15:49:29] <Dark_Shikari> But if it helps, it helps. [15:49:34] <Dark_Shikari> I guess having more registers makes inline asm less bad. [15:50:20] <mru> scheduling matters more, yes, but gcc sucks at that too [15:50:26] <mru> so it doesn't really get any worse [15:50:30] <Dark_Shikari> heh [15:50:43] <Dark_Shikari> how's armcc do on it all? [15:51:05] <mru> on average maybe 5% faster than gcc [15:51:10] <Dark_Shikari> I mean, on the asm. [15:51:17] <Dark_Shikari> would you want to use the inline asm with armcc too? [15:51:21] <mru> it doesn't support gcc inline asm [15:51:53] <Dark_Shikari> ah. [15:52:06] <Dark_Shikari> so gcc + inline asm in the right places is still worse than armcc? [15:52:13] <Dark_Shikari> also, what do you do about stuff like AV_WN etc on armcc? [15:53:58] <mru> armcc does the right thing there [15:54:23] <Dark_Shikari> I mean, how do you tell the compiler that the writes are unaligned? [15:54:33] <Dark_Shikari> Without writing byte-by-byte. [15:54:40] <Dark_Shikari> Since ARM has separate unaligned instructions. [15:54:40] <mru> attributes [15:54:46] <mru> no it doesn't [15:54:50] <Dark_Shikari> Oh, it doesn't? [15:55:00] <mru> halfword and word load/store support unaligned [15:55:08] <Dark_Shikari> on all ARM? [15:55:08] <mru> load/store multiple do not [15:55:12] <Dark_Shikari> Ah [15:55:13] <mru> armv6 and later [15:55:17] <mru> and armcc knows that [15:55:19] <mru> gcc doesn't [15:55:26] <Dark_Shikari> ah. [15:55:36] <mru> gcc uses byte-by-byte on all arm versions [15:55:42] <mru> that's why the asm is there [15:57:42] <Dark_Shikari> ah. [16:20:37] <av500> kshishkov: rockplayer has the RM timestamp correction :) [16:20:43] <av500> I will post the patches [16:23:20] <spaam> good boy [16:27:38] <BBB> av500: thanks [16:33:37] <av500> patch commited to mailing list :) [16:36:40] <kierank> mru: what's the best way of keeping pcr precision? [16:39:19] <spaam> av500: you forgot something.. git-formated-patch.. mru going to tell you about it [16:39:59] <av500> spaam: I take as excuse that its against the svn rev they used [16:40:42] <av500> my git foo is weak [16:42:43] <mru> kierank: elaborate [16:42:58] <mru> kierank: that is both a request and an answer :) [16:43:34] <av500> https://groups.google.com/group/nextplayer/browse_thread/thread/9d89747f5db… [16:43:56] <spaam> mru: you should teach your comrade av500 how to use git. [16:44:12] <kierank> mru: in a software muxer, when you write each packet you increment PCR by (188*8)/bitrate. What's the best way of making sure you don't get errors in the PCR owing to lack of precision. [16:44:50] <mru> kierank: count total packets [16:44:53] <mru> I suppose [16:45:06] <mru> and deal with overflows somehow [16:45:13] <kierank> I used doubles to begin with (which is obviously wrong) and I changed to infinite precision with GMP which is a bit overkill [17:02:50] <Tjoppen> kierank: don't use a counter [17:03:10] <Tjoppen> do what I did in mpegtsenc.c - just calculate it correctly each time you need to write it [17:05:14] <Tjoppen> get_pcr() = av_rescale(url_ftell(pb) + 11, 8 * PCR_TIME_BASE, ts->mux_rate) + ts->first_pcr [17:05:18] <kierank> yeah i see [17:05:23] <kierank> but that won't work for vbr [17:05:49] <Tjoppen> ah, I see. well, at least use rationals [17:06:11] <mru> live streaming is so much easier [17:06:16] <mru> pcr = gettime(); [17:06:47] <spaam> kierank: going to fix ffmpegtsenc? [17:07:07] <kierank> spaam: i'll mentor someone in gsoc [17:07:22] <kierank> but I wrote my own muxer for the time being because i need full on the fly reconfig [17:07:39] <spaam> ok :) [17:07:54] <mru> I wrote a ts muxer once, I'd rather not do it again [17:08:00] <mru> and no, it doesn't really work [17:08:08] <Tjoppen> try to get < 10 fps muxing working as well. or VFR in general [17:08:16] <mru> it was good enough for the particular needs I had at the time [17:18:37] <kierank> also mru, maybe you'll know why no stb manufacturer seems to know what h.264 settings their boxes will decode [17:18:47] <kierank> the answer always seems to be "try it and see if it works2 [17:19:09] <mru> incompetent vendors [17:19:32] <mru> stb manufacturers just take a chip and drivers from broadcom or st and hope for the best [17:19:47] <mru> bcm and st are hopeless at writing drivers [17:19:52] <kierank> even providers which spend huge amounts of money on stbs can't get an answer [17:20:37] <mru> the decoders are usually dsps with firmware blobs [17:20:55] <mru> whoever writes the firmware might know the answer [17:21:02] <mru> but you'll never find them [17:21:14] <kierank> yeah by the time you've found them you could just try it yourself [17:21:19] <av500> yep [17:21:43] <av500> kierank: soon you will have fun to ask them what maximum bitrate for vp8 they support :) [17:22:07] <kierank> av500: "the one that most people use" [17:22:33] <av500> 54 [17:23:38] <kierank> vp8 will be the new vc-1 [17:23:51] <mru> of course [17:24:04] <mru> annoying, proprietary, and doomed to die [17:24:20] <kierank> well vc-1 was microsoft's attempt to tame mpeg [17:24:45] <mru> they even got it into the bluray spec [17:24:53] <mru> and still they gave up in the end [17:24:55] <Flameeyes> j-b: around? [17:31:09] <mmu_man> mru: "highly optimized" they say ? lol [17:31:30] <mru> who about what? [17:34:22] <mmu_man> -#if HAVE_NEON && HAVE_INLINE_ASM [17:34:23] <mmu_man> +#if HAVE_NEON && HAVE_INLINE_ASM && HAVE_ARMVFP && 0 [17:34:24] <mmu_man> :)) [17:34:57] <mmu_man> probably they tried to work around a buggy gcc [17:38:09] * elenril summons some reviews from depths of heck [18:09:33] <j-b> Flameeyes: yes [18:30:24] * elenril pokes kshishkov [18:44:30] <thresh> av500: just got the 101, yipeee [18:49:41] <_av500_> thresh: great [18:49:56] <_av500_> tonight i will start drinking away the rubles [18:53:43] <thresh> I decided to change my habits and try the interface in ru_RU [18:53:45] <thresh> bad idea :/ [19:01:48] <Flameeyes> j-b: what's the "g" at the end of the symbol names in vlc plugins? :| [19:02:40] <elenril> g is the new cool letter [19:02:59] <kierank> elenril: like x? [19:03:10] <Tjoppen> gPlayer? [19:03:53] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/ThereIsNoSuchThingAsNotability [19:04:08] <elenrilg> copyright infringement! [19:04:11] * kierank awaits the stab [19:04:33] <elenril> bwahaha [19:04:50] <j-b> Flameeyes: the version ? [19:05:29] <Flameeyes> j-b: gha... base 36 encoded? [19:05:46] <mru> base54 ftw [19:05:54] <mru> then we can do rot26 on it [19:07:05] <j-b> Flameeyes: vlc_entry__1_2_0g or something? [19:07:54] <Flameeyes> 1__1__0g yes [19:08:23] <Flameeyes> I guess now that g == 7 (wasn't entirely obvious before) [19:09:21] <j-b> yes [19:09:35] <j-b> those are ABI bumps, I believe [19:09:37] <Flameeyes> any reason why it's not 1__1__7? :P [19:09:49] <j-b> Flameeyes: no fucking idea [19:09:59] <Flameeyes> heh [19:10:23] <j-b> probably predates the 1.x days... When we had 0.x.y.z... [19:10:43] <j-b> and so people don't think it is 1.1.7 ABI [19:10:51] <j-b> but the 7th bump in the 1.1. branch [19:10:58] <j-b> but your guess is as good as mine [19:12:00] <Flameeyes> heh okay, guess I'll just add a [a-z] at the end of the regexp and match it that way ;) [19:13:37] <Flameeyes> nah I can't believe it... gnome-vfs bundles libneon?! [19:15:01] <spaam> zomg [19:15:50] <elenril> wtf is with everyone doing vfs [19:16:11] <elenril> can't they just write fuse modules or something [19:17:07] <Flameeyes> elenril: they moved toward that now [19:17:21] <elenril> sanity? in my gnome? [19:17:25] <elenril> inconceivable! [19:18:00] <j-b> Flameeyes: just remember that vlc is done by crazy French men that are as skilled as you and are stupid enough to go into the B2C business... [19:19:33] <Flameeyes> j-b: right, and that would be the same class as the inventors of SECAM and PeritÃ©l? :P [19:19:51] <j-b> nah... not _that_ crazy [19:20:30] <kierank> the british are becoming the new french [19:20:35] <kierank> we keep loads of random crap alive [19:20:38] <kierank> like mheg [19:20:42] <kierank> 1080i in europe [19:20:53] <kierank> tv-anytime or whatever it's called [19:22:12] <j-b> oh, yeah, I saw that crap @ W3C Web&TV workshop [19:22:42] <kierank> did you see mpeg-7 [19:22:44] <Flameeyes> okay, my newest script can generate the collision detection database for Yamato's host system in less than 10 minutes [19:22:46] <Flameeyes> THIS is an improvement :) [19:23:02] <Flameeyes> [the original script on Enterprise took over 13 hours to finish a scan] [19:23:58] <j-b> kierank: I had 2 people complaining that "VLC sucks, because it doesn't read .mp7" [19:24:19] <mru> Flameeyes: enterprise stuff is meant to be slow :) [19:24:22] <kierank> did you tell them to come back when mpeg-7 actually does something [19:24:48] <kierank> or if mpeg-7 can be explained without 50 buzzwords [19:25:02] <j-b> kierank: more or less... And they told me to implement mpeg21 [19:25:11] <j-b> I didn't even answer [19:25:34] <kierank> lol [19:27:31] <j-b> kierank: I tried to read the spec... I didn't even know where to start from [19:29:22] <_av500_> j-b: its a meta spec, you need elenril to read it for you [19:29:34] <kierank> j-b: do you still have a stand at cebit [19:29:46] * kierank might go [19:30:01] * elenril proves his awesome meta skillz by not stabbing _av500_ [19:30:24] <j-b> kierank: yes, a very small one, but yes [19:30:42] <_av500_> j-b: you can stand on both legs in it? [19:30:45] <j-b> _av500_: haha... Meta! But is is generic and abstracted? [19:32:19] <_av500_> j-b: yes, 21 describes how to write a spec that describes how to write a spec that describes ... [19:32:38] <_av500_> ... turtles [19:33:02] <j-b> and unicorns? [19:33:20] <thresh> bah, that bastard had already registered the device on his name :D [19:33:35] <_av500_> ` [19:33:37] <_av500_> ? [19:33:46] <_av500_> i gave it in sealed box [19:34:02] <thresh> nah, I'm not blaming you :) [19:34:11] <_av500_> but his name is the same [19:34:13] <thresh> it's Kostya whos nuts are going to be kicked :) [19:34:48] <kierank> j-b: what's the best day to go to cebit? [19:35:10] <j-b> kierank: no idea. I am closing the FOSDEM things before looking at FOSDEM [19:35:19] <_av500_> kierank: any day 2000 or 2001 [19:35:32] <Tjoppen> _av500_: specs all the way down? [19:35:41] <j-b> kierank: but the more it will come near to the week-end, the more it will be crowded with clueless people [19:35:46] <Tjoppen> the only thing I got out of wikipedia was "DRM" [19:36:17] <kierank> j-b: how many tickets did they give you [19:37:25] <j-b> I've not even looked at it... But too many is my guess [19:42:00] <jannau> j-b: expect also clueless people on weekdays, i.e. people who have no idea what open source is or people who have $IDEA for mobile app and looking for devs [19:42:21] <j-b> ofc [19:53:37] * mru curses typedeffed pointers [19:54:09] <elenril> those are the root of all that is evil [19:55:11] <Flameeyes> elenril: no that's /opt [19:55:45] <thresh> _av500_: now as a paying customer I demand you to fix all bugs [19:55:48] <elenril> who uses opt [19:55:50] <kierank> elenril: those are vla [19:55:53] <kierank> VLAs [19:55:54] <Flameeyes> elenril: prebuilt evil! [19:56:15] <kierank> elenril: all proprietary software [19:56:27] <elenril> yeah, but who uses proprietary software =p [19:56:44] <mru> sensible people do when it's the best solution available [19:56:59] <Flameeyes> mru++ [19:57:51] * elenril prefers watching some anime instead [19:58:28] <Flameeyes> I'm lacking time to follow anime nowadays :( I'm keeping with stuff I can listen with half brain [19:59:02] <mru> that's why he's here listening to elenril [19:59:08] <BBB> does someone have time to create a git-formatted patch for the fix proposed in https://roundup.ffmpeg.org/issue2594 ? [19:59:47] <thresh> lol, people use archos application "market" to do two things [19:59:50] <Flameeyes> mru: waiting for libreoffice to complete build to run my collision detection script again :) [19:59:51] <thresh> 1/ install angry birds [19:59:56] <thresh> 2/ install google market [20:00:34] <elenril> Flameeyes: the amount of good anime these days doesn't require much time ;) [20:02:20] <j-b> Flameeyes: what is your collision detection script? [20:03:33] <Flameeyes> j-b: it's one of the ruby-elf tools: it reads all the dynamic ELF objects in a system, skip over plugin interfaces, collapse libraries' variants, adds all that to a db, then mines the data from that db to produce a list of possible collisions between libraries in that system [20:03:55] <j-b> Flameeyes: nice [20:04:05] <Flameeyes> I started working on it at the time I debugged a crash in xine because of collisions, has turned out a number of issues with bundled libraries in Gentoo [20:04:21] <Flameeyes> unfortunately most upstreams don't even care about those collisions in the first place :( [20:04:45] <j-b> "how to be a good upstream"... Is there a guide for it? [20:05:10] <thresh> Flameeyes: some time your package manager would be sane enough to have a require / provide for a set of symbols in a library [20:05:19] <thresh> then, no sonames would be necessary [20:05:33] <Flameeyes> j-b: a gentoo dev had that as a talk last year at fosdem... otherwise I don't think there are [20:06:15] <thresh> in fact, our guys at ALT Linux had done just that in our fork of RPM [20:09:24] <Flameeyes> thresh: not really.. sonames and package managers should solve different issues [20:10:42] <j-b> Flameeyes: betelgeuse(a)g.o seems to [20:11:50] <thresh> Flameeyes: yes, sure [20:16:41] <_av500_> thresh: i dont know you any more :) [20:17:21] <Flameeyes> j-b: yeah, me, lu_zero, mru and siretart were there en masse :D [20:17:48] <thresh> _av500_: I knew there was a catch :) [20:18:02] <_av500_> thresh: it was cheap :) [20:18:28] <thresh> hehe [20:18:40] <_av500_> cheap french stuff [20:18:55] <j-b> Flameeyes: no presentation online [20:19:08] <Flameeyes> j-b: uhm that's strange, the Debian team had it online [20:19:14] <Flameeyes> I know I have it around, will upload [20:19:51] <Flameeyes> will take a bit, since it's 519M and I have 32kib upstream though :P [20:22:50] <j-b> 519M for a presentation? [20:22:57] <kierank> video [20:23:00] <thresh> it's in bink video, what do you expect [20:23:07] <_av500_> xml video [20:23:19] <_av500_> </pixel> [20:23:31] <j-b> pfff, I don't want a 1h video that should be summarized in 10min [20:23:35] <Flameeyes> j-b: OGV :P [20:23:45] <thresh> j-b: then why did you watch Avatar?:) [20:23:58] <Flameeyes> guess at a minimum I should recode it ;) [20:23:59] <mru> avatar needs 10min? [20:24:09] <thresh> mru: point taken, 3 minutes max [20:24:14] <_av500_> blue pocahontas [20:24:18] <_av500_> done [20:24:41] <mru> that is a fair description [20:25:02] <astrange> huh, i am an ffmpeg developer in atlanta, ga [20:25:18] <_av500_> i feel for you [20:25:36] <astrange> but i'm already employed [20:25:45] <mru> see which is better [20:26:11] <j-b> http://www.youtube.com/watch?v=XBKwPeKLa4Q then [20:26:53] <mru> ugh @ sound quality [20:28:35] <_av500_> ffaacenc? [20:29:05] <thresh> last time I checked it only produced soundtrack for a swamp [20:29:18] <thresh> aka croaking [20:29:31] <thresh> it might fit that video though [20:30:30] * _av500_ watches "how to fork your own upstream" [20:31:04] <mru> by mark shuttleworth [20:31:15] <thresh> yeah, ffmpeg devs need that [20:31:19] <thresh> </troll> [20:33:36] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rdda3f0ef48 ffmpeg/libavcodec/ (8 files in 2 dirs): [20:33:36] <CIA-38> ffmpeg: Add x86-optimized versions of exponent_min(). [20:33:36] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:33:54] <ruggles> \o/ [20:33:58] <BBB> ruggles: thanks, sorry I took so long to apply it [20:34:09] <BBB> so how much more work until after is "done"? [20:34:43] <ruggles> not much code writing left. mostly just getting patches through review. [20:35:25] <Flameeyes> note to self: libreoffice might be slimmer, but it _still_ doesn't fit into tmpfs [20:35:27] <ruggles> only big piece of code left to write is channel coupling. i got the syntax working yesterday, but now i have to actually generate the coupling channel and coordinates. [20:35:42] <mru> Flameeyes: get more ram :) [20:35:50] <Flameeyes> mru: yeah I should... but it's pricey [20:36:16] <BBB> ruggles: oh that's pretty good, and how does ac3enc compare to "commercial" ac3 encoders then? [20:36:48] <ruggles> i don't really know. i don't have any commercial ac3 encoders. [20:36:53] <Flameeyes> mru: around â¬560 for another 16G :( [20:36:56] <CIA-38> ffmpeg: Reimar DÃ¶ffinger <Reimar.Doeffinger(a)gmx.de> master * r4a72765a1c ffmpeg/libavcodec/dvbsubdec.c: [20:36:57] <CIA-38> ffmpeg: Do not fail DVB sub decoding because of a few padding bytes [20:36:57] <CIA-38> ffmpeg: Instead of returning an error when bytes are left over, just return [20:36:57] <CIA-38> ffmpeg: the number of actually used bytes as other decoders do. [20:36:57] <CIA-38> ffmpeg: Instead add a special case so an error will be returned when none [20:36:57] <CIA-38> ffmpeg: of the data looks valid to avoid making debugging a pain. [20:36:58] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:37:05] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * r493aa30adf ffmpeg/libavcodec/dvbsubdec.c: [20:37:05] <CIA-38> ffmpeg: dvbsubdec: check against buffer overreads [20:37:05] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:37:06] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * r5c19f64c60 ffmpeg/doc/build_system.txt: document passing the fate samples location via make variable [20:37:38] <ruggles> BBB: but as far as features affecting quality are concerned, once coupling is done it should be fairly close. [20:39:21] <elenril> how good is ac3 compared to other formats? [20:39:24] <elenril> like vorbis or aac [20:39:53] <ruggles> elenril: not as good in the quality/bandwidth sense [20:40:19] <Flameeyes> does this mean alsa-plugin's ac3 encoder could soon allow to have multichannel output over spdif? :P [20:40:41] <ruggles> Flameeyes: why doesn't it now? [20:40:54] <Flameeyes> ruggles: mostly because it explodes [20:41:14] <Flameeyes> with various degrees of reasons [20:41:32] <Flameeyes> with xine it's a race condiiton due to the different init calls between xine and alsa [20:42:07] <ruggles> shouldn't have anything to do with what i'm doing in ffmpeg though... [20:43:35] <Flameeyes> just hoping somebody is looking at the ac3 encoding ;) [20:45:22] <ruggles> i only briefly looked at the alsa ac3 plugin several years ago. i thought it supported 5.1 ok. [20:45:38] <ruggles> it seemed to work with mplayer anyway [20:46:05] <Flameeyes> I think that's the only use case where it works :) [20:47:19] <ruggles> does it work with just ffmpeg now that we have an spdif muxer and alsa output? [20:48:09] <ruggles> i guess that would skip the plugin though... [20:48:11] <Flameeyes> I'd have to re-connect a soundcard to tell :) [20:50:23] <jannau> BBB: can you look at http://patches.ffmpeg.org/patch/167/ aac profiles [20:58:11] <BBB> jannau: isn't that applied already? [20:58:30] <BBB> hm, I guess not [20:59:06] <BBB> jannau: it needs an extra one-liner that always sets avctx->profile to FF_PROFILE_AAC_LOW in aacenc_init() [20:59:19] <BBB> jannau: otherwise the value will be undefined if avctx->profile wasn't explicitely set [20:59:48] <BBB> jannau: and that's the only profile supported anyway [21:04:11] <elenril> can i have an op in #ffmpeg? [21:04:29] <mru> elenril: trolls? [21:04:37] <elenril> also can we clone BBB so he'll review the rest of asf stuff? [21:04:38] <elenril> mru: yes [21:04:48] <elenril> or more like spam [21:04:54] <j-b> Flameeyes: ok, after watching it, we are not bad upstream [21:05:26] <Flameeyes> j-b: it wasn't as easy when I started mantaining vlc tho :P [21:06:29] <j-b> Flameeyes: indeed, but it has changed quite a bit since I cleaned configure and packaging with courmisch [21:06:43] <elenril> mru: thanks [21:06:45] <Flameeyes> yep yep it was definitely a welcome cleanup :) [21:07:32] <j-b> Flameeyes: btw, is there any correct way to warn all downstream developers in one time? [21:07:49] <Flameeyes> j-b: make an -announce list :D [21:07:57] <Flameeyes> that's what OpenSSL does fwiw [21:09:02] <jannau> BBB: thanks, it wasn't entirely clear. I'll send an updated patch [21:20:42] <barspi> hiâŠ anyone in charge of the git repository configuration? [21:21:02] <thresh> which one exactly? [21:21:10] <jannau> barspi: sure [21:21:18] <barspi> or who could tell me why "git archive âremote=git://git.ffmpeg.org/ffmpeg.git will not work? [21:21:34] <barspi> # git archive --format=tar --remote=http://git.ffmpeg.org/ffmpeg.git a1c1d3c003b0ec16fdb6574913781313fb2c7ab6 > tt.tar [21:21:34] <barspi> fatal: Operation not supported by protocol. [21:22:02] <barspi> I want an archive of *that specific* revision (and no, I don't want to clone the whole git repo :-) ) [21:22:29] <barspi> but I'm a git newbie so maybe I'm doing something wrong [21:22:41] <jannau> barspi: that repository was the old git svn clone and is discontinued [21:22:56] <jannau> use git://git.ffmpeg.org/ffmpeg instead [21:23:13] <barspi> hmm without the .git at the end? [21:23:20] <jannau> hmm wait [21:23:54] <barspi> I'm sorry I copied the wrong command form my screen (with http) [21:24:04] <barspi> I really tried it with git:// hehe [21:24:29] <barspi> # git archive --format=tar --remote="git://git.ffmpeg.org/ffmpeg.git/" a1c1d3c003b0ec16fdb6574913781313fb2c7ab6 > tt.tar [21:24:30] <barspi> fatal: The remote end hung up unexpectedly [21:24:35] <barspi> same error [21:24:47] <barspi> or rather, same result: an error :-) [21:25:05] <barspi> so maybe the git server is not configured to support remote archiving? [21:28:51] <jannau> barspi: yes, we don't allow remote archive generation [21:29:21] <barspi> ohh [21:29:28] <barspi> that sucksâŠ can it be fixed? :-) [21:30:29] <mru> btw ffmpeg.git and ffmpeg are the same now [21:30:37] <mru> the old one is ffmpeg.svn [21:30:53] <barspi> but ffmpeg.svn is not up-to-last-minute, right? [21:31:13] <mru> it's synced with the svn repo [21:31:20] <mru> which is read-only [21:31:55] * Daemon404 wonders why gcc does not yet have vmrs/vmsr instructions [21:32:09] <mru> that's binutils, and use the pre-ual names [21:32:28] <Daemon404> i ended up doing that [21:32:32] <jannau> barspi: upload-archive is by default disabled in git daemon [21:32:44] <Daemon404> any reason why it doesnt tho? [21:32:45] <jannau> I'm unsure if we want to enable it [21:32:50] <mru> Daemon404: the real question is why you are using those in the first place [21:33:01] <Daemon404> i was just pokign around teh cpuid shit [21:33:24] <mru> cpuid is privileged on arm [21:33:27] <mru> don't ask me why [21:33:28] <barspi> I'm not sure if that option is what I want. As I told you, I'm a git newbie :-) [21:34:03] <jannau> barspi: do you have a reason why you don't want to clone the repo? [21:34:16] <Daemon404> mru, that would explain what im seeing then [21:34:19] <barspi> but I think it could be useful to allow an export of a certain revision (one which has not been specifically tagged or branched) [21:34:35] <mru> Daemon404: SIGILL? [21:34:43] <Daemon404> mru, yes [21:34:57] <jannau> barspi: you'll have all revision in your repo clone [21:35:12] <barspi> the reason is that I have a build script that depends on a certain revision, and I want to distribute that script to my team and they don't need the whoooooooole git tree [21:35:24] <barspi> they just need to download that one and do a build [21:35:55] <barspi> (also, I could distribute the whole export that I have locally archived myself, but that's evading the question/problem) [21:36:09] <barspi> there's always 1000 ways to do something, but some ways are better than others :-) [21:36:31] <barspi> something so simple which in SVN could be done with a svn export @rev [21:36:33] <Daemon404> mru, i was just using it out of boredom btw (and to poke around a bit using gas-preprocessor.pl) [21:37:08] <mru> Daemon404: are you on iphone? [21:37:24] <Daemon404> nope. i have a few arm boards + android phone [21:37:33] <mru> then why the preprocessor? [21:38:00] <Daemon404> liek i said boredom, wanted to see wtf it did. [21:38:23] <mru> it works around apple's rotten build tools [21:38:29] <Daemon404> ah [21:39:00] <Daemon404> and im lookign in to obtaining armcc atmto toy with at some point (can prolly through company) [21:39:25] * Daemon404 is part way into his arm arch book [21:45:59] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r44adbebe17 ffmpeg/ (6 files in 2 dirs): [21:45:59] <CIA-38> ffmpeg: Remove final semicolon from some macros [21:45:59] <CIA-38> ffmpeg: This avoids double semicolons after macro expansion. [21:45:59] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:46:09] <CIA-38> ffmpeg: Ronen Mizrahi <ronen(a)tversity.com> master * rdf211c3ab7 ffmpeg/libavcodec/dvbsub.c: [21:46:09] <CIA-38> ffmpeg: dvbsubenc: Fix placement of the object version [21:46:09] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:55:19] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r12c14cd4a8 ffmpeg/libavformat/ (avformat.h version.h): [21:55:19] <CIA-38> ffmpeg: add AV_DISPOSITION_HEARING_IMPAIRED and AV_DISPOSITION_VISUAL_IMPAIRED [21:55:19] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:55:28] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r5209149157 ffmpeg/libavformat/utils.c: [21:55:28] <CIA-38> ffmpeg: make av_find_best_stream() ignore streams marked with AV_DISPOSITION_*_IMPAIRED [21:55:28] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:55:31] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r68137ba386 ffmpeg/libavformat/wtv.c: [21:55:31] <CIA-38> ffmpeg: wtv: mark streams intended for hearing or visual impaired persons [21:55:31] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:57:27] <barspi> soâŠ jannau, do you think the archive option will be enabled or is it a no-no ? [22:05:10] <jannau> mru: do you have an opinion on enabling upload-archive? [22:05:26] <ruggles> would that be the same as a snapshot from gitweb? [22:05:38] <mru> probably [22:05:54] <mru> it's a matter of system load and bandwidth [22:06:05] <mru> I doubt many will use it [22:07:57] <jannau> maybe we could create nightly snapshots for git [22:10:32] <_av500_> wont help ppl that need a specific rev [22:18:34] <barspi> nightly snapshots could be cool :-) [22:18:42] <barspi> but they will take space on your servers [22:19:12] <barspi> I need this feature because I need certain ASF features which have only recently been added [22:19:36] <barspi> and I know that the revision I used a few days ago works, but I can't guarantee that HEAD will always work [22:19:42] <siretart> barspi: you mean something like this: https://launchpad.net/~motumedia/+archive/ffmpeg-daily/+packages? [22:19:51] <barspi> so I want *that* revision specifically and it hasn't been tagged yet [22:20:29] <barspi> (side noteâŠ the ffmpeg-devel channel seems a lot more friendly than the harsh mailing list hehehe) [22:20:48] <elenril> ....so whay can't you just clone the whole repository [22:22:01] <barspi> there's no point in doing that (which is like twice the size of a clean tree) when my clients just one a specific build of a specific revision [22:22:35] <mru> do a shallow clone [22:22:37] <barspi> I could clone the whole internet on my machine because I want a couple of photos, but that's besides the point and avoiding the question/problem [22:23:26] <barspi> I read up on shallow clone, but it seems it works with a certain-depth-number which I understand as "depth as of now" (where now is moving in time because time runs forward) [22:23:45] <barspi> so 2 levels as of today probably won't give me the same revision as 2 levels 6 months from now [22:24:02] <jannau> mru: doesn't help since you can't specify which version you want [22:24:13] <barspi> (plus I have no idea how many levels back from "now" to get to a1c1d3c003b0ec16fdb6574913781313fb2c7ab6) [22:24:37] <mru> arithmetic in sha1 space can be a bit tricky, sure [22:25:44] <barspi> I don't want to sound like a pesty geek, but I just so it would be something simple todo and that's why I'm so tough headed about it hahaha [22:26:26] <elenril> looks to me like you're just creating artificial problems [22:26:40] * jannau curses elenril [22:27:28] <jannau> I've tried to clean patchwork but still more than 1 page [22:27:34] <elenril> haha [22:27:39] <barspi> haha I don't think soâŠ someone who is not interested in developing a project shouldn't have to clone a whole project's history/prehistory/and whatnot [22:27:39] <elenril> jannau: go review my patches then [22:27:51] <barspi> somebody just wants a certain revisionâŠ [22:28:07] <elenril> barspi: well most people don't care [22:28:13] <elenril> since the repository is tiny anyway [22:28:23] <elenril> we're not living in the age of 1gb disks anymore [22:29:12] <astrange> a git checkout with full history is the same size as an svn checkout [22:29:24] <astrange> because svn never implemented a compressed text-base [22:29:52] <_av500_> is it on the todo list? [22:33:19] <Dark_Shikari> BBB: poke [22:33:28] <BBB> oh, right, testing right this moment [22:33:38] <BBB> (yes I forgot, I apologize) [22:34:25] <elenril> jannau: you can remove Replace remaining occurrences of deprecated CH_* with AV_CH_*, it's been applied [22:34:31] <Dark_Shikari> BBB: no problem [22:34:44] <Dark_Shikari> also I found a way to save 2 clocks on rac_get [22:34:47] <Dark_Shikari> er, two instructions [22:34:52] <Dark_Shikari> but not sure what the cleanest way to do it is [22:34:55] <Dark_Shikari> if( av_builtin_constant_p(prob) && prob == 128 ) [22:34:55] <Dark_Shikari> low = (high + 1) >> 1; [22:34:55] <Dark_Shikari> else [22:34:56] <Dark_Shikari> low = 1 + (((high - 1) * prob) >> 8); [22:34:56] <BBB> 2 instructions is fabulous [22:35:02] <Dark_Shikari> Not rac_get_prob. [22:35:03] <Dark_Shikari> rac_get. [22:35:08] <BBB> oh [22:35:16] <Dark_Shikari> It's used in one place in speed-critical code (dct sign) [22:35:47] <mru> the code I wrote in all asm? [22:36:27] * BBB fears some version of gcc will not properly inline the prob==128 if prob=128, and actually compare 128 to 128 [22:36:41] <kierank> did google sponsor ffvp8's arm opts? [22:36:48] <mru> kierank: arm did [22:36:50] <barspi> the difference is not with svn checkout, but with svn export (which does not download the whole .svn stuff) [22:36:55] <kierank> mru: ah [22:37:04] * kierank doesn't see mru working on dead codecs without good reason [22:37:32] <mru> a 4-figure sterling amount is a good reason to me :) [22:37:57] <astrange> no sponsorship for decode_cabac_residual()? [22:38:08] <barspi> and as for 1gb hard disksâŠ the main problem is internet speed (the build script having to download a whole git repo clone takes much longer to execute) [22:39:36] <barspi> anywayâŠ I guess I'll script the 2-step and long process of doing a full clone and then a local archive... [22:42:39] <BBB> astrange: sponsorship? [22:51:17] <ruggles> mru: i already did send a new patch with a correct comment [22:51:36] <kierank> we could do some blind ffmpeg vs ffac3enc tests [22:52:19] <lu_zero> ? [22:52:30] <kierank> i mean dolby [22:52:32] <kierank> gah [22:52:49] <mru> ruggles: yeah, see it [22:52:53] <mru> ruggles: makes more sense now [22:53:51] <ruggles> kierank: good idea. what i need right now is a nice sample encoded by dolby encoder at all bitrates it supports for stereo and 5.1. [22:54:51] <ruggles> i have plenty of ac3 samples, but no source + sample. [22:54:52] <BBB> Dark_Shikari: see ML [22:55:29] <kierank> ruggles: http://www.neyrinck.com/en/downloads/dolby-digital [22:55:36] <Dark_Shikari> BBB: Nice [22:55:43] <Dark_Shikari> will get around to that in a bit. [22:56:29] <ruggles> kierank: oh nice. 30 sec limit... but better than nothing. [22:56:46] <kierank> ruggles: sometimes the drm doesn't work and lets you encode as much as you like [22:56:59] <kierank> at least that's what it was like on the dolby e one [22:57:13] <bcoudurier> wiat [22:58:24] <bcoudurier> if you want samples, ask me [22:58:28] <BBB> bcoudurier: oh, since you're here, should I go look for that old patch to set the raw video tag correctly? also, shouldn't that tag ever be set in the decoding case, since it basically just creates applications that work around bugs, so its only use case would be for ffmpeg -vtag abcd? [23:00:52] <BBB> astrange: should I help preparing patches to submit h264-mt/h263-mt/etc-mt? [23:01:14] <BBB> astrange: and yes I will keep bugging you until it's completely merged, this stuff is way too awesome to not merge right away [23:04:38] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rc1fea23070 ffmpeg/libavformat/asfdec.c: [23:04:39] <CIA-38> ffmpeg: asfdec: split asf_read_header() [23:04:39] <CIA-38> ffmpeg: Only trivial splits are done here -- i.e. copy/paste + reindent + [23:04:39] <CIA-38> ffmpeg: missing variable declarations. [23:04:39] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [23:05:19] <bcoudurier> BBB, I don't understand what you mean here [23:05:32] <bcoudurier> the tag is used to workaround bugs sometimes [23:05:42] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r0b1d291a71 ffmpeg/libavformat/asfdec.c: [23:05:42] <CIA-38> ffmpeg: asfdec: deobfuscate reading video properties size [23:05:42] <CIA-38> ffmpeg: This code will be later split out into a function which takes a 'size' [23:05:42] <CIA-38> ffmpeg: argument, so I'm keeping the name 'sizeX' here. [23:05:42] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [23:08:17] <BBB> bcoudurier: right, I can see it being useful in certain scenarios, like wanting to force a fourcc on a quicktime/avi file, or some more stuff, but in the mov<->avi transcoding case, you can see that it introduces problems. so I don't think demuxers should set AVCodecContext->video_tag, or alternatively I think the "fourcc of video format in the demuxed file" vs. "force fourcc to be this one in the muxed file" should not automatically be the sam [23:08:17] <BBB> in AVCodecContext... one solution is for demuxers to simply not set AVCodecContext->video_tag, do you have better solutions? [23:09:06] <bcoudurier> do what you want and break everything including stream copy [23:09:47] <atod> does anyone know where ffmpeg can be hacked to figure out h.264 references > 9. or would that be in libx264 also? [23:09:54] <bcoudurier> I guess you have to learn the mistakes by doing them like previous people knowledgeable went though [23:10:02] <bcoudurier> through [23:10:30] <mru> and what do you do with formats like matroska where the codec identifier is a string? [23:10:44] <mru> the 32-bit tag stuff reeks of avi-think [23:11:33] <bcoudurier> mov uses 32 bit tag and ts as well [23:11:40] <BBB> bcoudurier: well that one was obvious and coming. fine, be all arrogant about it, you say you sent a patch, I show interest, apparently I shouldn't? [23:12:08] <mru> bcoudurier: mov uses _different_ tags than avi [23:12:14] <mru> and ts doesn't require them [23:12:25] <mru> and when present, they're from yet another set [23:12:38] <mru> blindly copying them is beyond stupid [23:12:39] <bcoudurier> ts requires them for some mappins [23:12:48] <kierank> yeah for dirac [23:12:50] <bcoudurier> like ATSC requires AC-3 [23:13:02] <bcoudurier> and dirac too that's correct [23:13:20] <mru> ac3 uses a different identifier in atsc and dvb [23:16:51] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rd4582889ee ffmpeg/libavcodec/ac3enc_fixed.c: [23:16:51] <CIA-38> ffmpeg: ac3enc: remove right shifting from lshift_tab() and make lshift unsigned. [23:16:51] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:17:03] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r626264b11b ffmpeg/libavcodec/ac3enc_fixed.c: [23:17:03] <CIA-38> ffmpeg: ac3enc: Remove unneeded clipping of shift amount. [23:17:03] <CIA-38> ffmpeg: s->windowed_samples will always have a range of [-32767,32767] due to the [23:17:03] <CIA-38> ffmpeg: window function, so the return value from log2_tab() will always be in the [23:17:04] <CIA-38> ffmpeg: range [0,14]. [23:17:04] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:18:16] <bcoudurier> anyway, mru, 32 bit is not adequate for matroska, and mxf uses 16 bytes integer [23:18:24] <bcoudurier> I agree [23:18:24] <mru> that's my point [23:18:28] <mru> what do you do with them? [23:18:55] <mru> I know preserving the exact avi tag sometimes has advantages [23:18:56] <bcoudurier> well I think the best strategy is to override what's in codec_tag by default [23:19:01] <bcoudurier> when muxing [23:19:11] <bcoudurier> if user forces a new one, use it [23:19:18] <mru> but the current way it's done is wrong [23:19:31] <bcoudurier> mp4 muxer do not let the user specify it [23:19:36] <BBB> bcoudurier: tat's the problem [23:19:47] <BBB> bcoudurier: you don't know when it's forced and when it's set by a (which?) demuxer [23:19:53] <bcoudurier> mov muxer will choose the default unless strict is specified [23:20:28] <bcoudurier> that's about the stream copy case [23:20:52] <BBB> so I say: split it into two - one is "forced by used", which is always used, and one is "set by demuxer", which is only used if the muxer doesn't know how to map codec_id to a tag by itself [23:21:16] <BBB> (split into 2 = split AVCodecContext.video_tag into AVCodecContext.demux_video_tag and .force_video_tag) [23:22:51] <BBB> we could even consider making .force_video_tag a codec private option, since it really only applies to a few muxers that use fourccs as codec identifiers, but that's a flamewar that I'll skip since I'm ignorant [23:22:55] <bcoudurier> I'm not sure it's a lib problem, more an application problem [23:23:18] <bcoudurier> some decoders need the tag to workaround bugs, application has to set it anyway [23:24:14] <bcoudurier> when muxing, application can set it, and muxer will honor it or not (depending on strict) [23:25:42] <BBB> I don't think applications should set it so easily, as per what mru just said => a movfourcc != an avifourcc [23:26:05] <bcoudurier> why would application set it anyway [23:26:26] <bcoudurier> unless for specific use case that are way to particular [23:27:31] <bcoudurier> problem is ffmpeg here IMHO, always setting it even trans-formats [23:27:46] <BBB> I agree [23:27:53] <bcoudurier> moving that logic in libavformat was a bad choice and it broke the mov case [23:27:58] <bcoudurier> and I'm pissed off [23:28:17] <mru> given an AVCodecContext, there's now way to know what the codec_tag means [23:28:25] <mru> for that you need to know what set it [23:28:43] <bcoudurier> that's true [23:28:58] <bcoudurier> you can move codec_tag to AVStream [23:29:17] <bcoudurier> although decoders need it to decode some XVID or some other mpeg4 variants [23:29:18] <mru> but that breaks the decoder workarounds triggered by specific tag values [23:29:59] <BBB> "move into libavformat" == validate_codec_tag()? [23:30:05] <BBB> that function looks fishy [23:31:56] <bcoudurier> mru, that's why you would need both [23:32:03] <bcoudurier> on in AVCodecContext and one in AVStream [23:40:47] <BBB> alternatively you can simply create more codec_ids [23:41:03] <mru> ? [23:41:30] <BBB> CODEC_ID_XVID, CODEC_ID_DIVX for the divx/xvid-specific workarounds, same for VP30 and so on (quick grep showed some more) [23:41:38] <BBB> maybe that's a bad idea, can quickly get out-of-hand [23:42:01] <mru> that is ridiculous [23:42:05] <mru> one codec, one id [23:43:53] <BBB> is there a proper way to "port" commits from videolan.git to ffmpeg.git? [23:44:02] <BBB> or just "resend the same patch+commitmsg"? [23:44:07] <j-b> git remote add ... [23:44:16] <j-b> git remote update [23:44:19] <j-b> git cherry-pick [23:45:20] <BBB> do you have a highlight set whenever someone says videolan, j-b? :-p [23:46:20] <j-b> no [23:46:31] <j-b> I have a script that tells me what is the channel most active [23:48:40] <Jumpyshoes> that's pretty cool. xchat? [23:49:04] * mru has 12 monitors on the wall, each showing a different channel [23:49:34] <mmu> ah so that's what those beagleboards are doing the other 363 days of the year ? [23:49:49] <kierank> mru: nice [23:49:50] <mru> oh, and everything you hear on irc is true [23:50:04] <mmu> of course it is [23:50:33] <BBB> I don't believe that without pics [23:50:39] <mru> nor should you [23:50:50] * lu_zero won't believe w/out being there [23:51:37] <BBB> hm, git cherry-pick is kinda nice [23:51:40] <mru> if you ever come to visit, I'll make sure to hook up every monitor I have [23:51:41] <BBB> sorry for the spam on -devel now [23:52:32] <BBB> testing my git fu [23:54:58] <BBB> ugh I didn't understand that 'y' is not the same as 'a', I forgot to send the rest :-p [23:55:33] <mru> fu not so good [23:55:41] <lu_zero> nite [23:56:11] <BBB> bye lu_zero [23:56:21] <BBB> mru: it's getting there... [23:56:26] <BBB> I know what cherry-pick does now [23:56:27] <BBB> I know -s [23:58:29] <BBB> hm... merge [23:58:31] <BBB> how do I merge [23:58:47] <mru> rebase -i [23:58:48] <BBB> extra handicap: I've got a baby on my lap

1 0

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

10 Feb '11

[00:00:44] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * rf7f8120fb9 ffmpeg/libavcodec/libx264.c: [00:00:44] <CIA-38> ffmpeg: Fix broken vbv_buffer_init handling in libx264.c [00:00:44] <CIA-38> ffmpeg: Due to being pants-on-head retarded, libavcodec defaults this to zero, which [00:00:44] <CIA-38> ffmpeg: results in broken output. This didn't affect ffmpeg.c, which sets it itself, [00:00:44] <CIA-38> ffmpeg: but caused problems for other calling apps using VBV. [00:00:54] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r62457f9052 ffmpeg/libavcodec/vp8.c: [00:00:54] <CIA-38> ffmpeg: VP8: idct_mb optimizations [00:00:54] <CIA-38> ffmpeg: Currently uses AV_RL32 instead of AV_RL32A, as the latter doesn't exist yet. [00:00:57] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * rc7ac200d15 ffmpeg/ (27 files in 2 dirs): [00:00:57] <CIA-38> ffmpeg: Update qmin/qmax values for libx264 presets [00:00:57] <CIA-38> ffmpeg: Also allow qmin/qmax to go up to 69 (the current max value for libx264). This [00:00:57] <CIA-38> ffmpeg: will have to increase when we add 9/10-bit support. [00:17:04] <drv> BBB: yes, i'm working on a windows fate box on and off, possibly this weekend will have time to get it fully up and running [00:23:28] <Flameeyes> nice nice nice.. ffmpeg is totally LFS-safe [00:30:28] <Orphis> Any idea on how I could override the TARGET_PATH variable at the configure level ? It doesn't seem to be used anywhere but in fate [00:31:00] <mru> --target-path [00:31:56] <Orphis> Fair enough [00:32:35] <Orphis> Why did I only grep target_path ?! Humpf ^^ [00:33:11] <Orphis> Why will be running great with that I guess [00:54:28] <Orphis> Yeah, I've got the right configure now that's able to run Fate well ! [01:11:07] <mmu> didn't have to change it for Haiku :p [01:19:30] <Orphis> Haiku doesn't have mixed path like cygwin / windows :P [01:19:46] <mmu> no it's a sane OS :p [01:41:01] <BBB> drv: ok, the bug is fixed [01:42:45] <drv> cool, will test soon [01:46:12] <Orphis> cat workdir/compile.log : install: missing file or operand [01:46:32] <Orphis> Why why why is cygwin making everything so difficult ?! [01:57:59] <BBB> drv, Orphis: PS thanks for trying to set up windows fate boxes, very much appreciated [01:58:45] <Orphis> drv: Oh, you're trying to set up a windows fate box too ? [02:01:44] <drv> if you are putting one together, that is even better (less work for me ;) [02:01:58] <drv> i have a win64 VM, but it is not fully set up yet [02:02:30] <Orphis> Did you manage to configure and run fate tests manually yet ? [02:02:57] <drv> not yet, i have been cross-compiling with a linux machine, and cygwin ssh on the test machine is not cooperating [02:03:12] <Orphis> What's the problem , [02:03:41] <Orphis> cygwin ssh was easy enough to configure [02:03:56] <Orphis> Run ssh-host-config [02:04:22] <drv> it works fine with password, but key-based auth seems to have permission problems [02:04:27] <Orphis> Then: net user username password /add /yes [02:04:35] <drv> (i can't access network shares) [02:04:54] <Orphis> And mkpasswd -l -u username >> /etc/passwd [02:05:03] <Orphis> Wouldn't scp work ? [02:05:44] <Orphis> And key based auth works fine for me and BBB [02:07:43] <Orphis> And I've scp-ed the public keys too, so you should try that [02:55:50] <Orphis> Yay, I think the fate.sh script is now running fine ! [03:40:40] <Orphis> I'll setup the crontab tomorrow for my fate [06:08:28] <elenril> what a delightfully dull night [06:08:37] <elenril> no drama, no reviews, no -mt [06:13:36] <astrange> i feel ill. should go away tomorrow [06:14:15] <siretart> astrange: get well soon! [06:46:50] <elenril> _av500_: ping [06:49:22] <benoit-> moin [06:53:11] <_av500_> elenril: pong [06:53:53] <thresh> moroning [06:54:46] <elenril> _av500_: you said you'd add chapter muxing for asf [06:54:59] <_av500_> elenril: yes, its on hold :( [06:55:07] <elenril> and iirc then you ran into some problems with negative timestamps [06:55:11] <_av500_> yes [06:55:14] <elenril> i wonder what problems [06:55:29] <_av500_> ill tell you later, need to feed kids [06:55:30] <elenril> aren't all timestamps in asf unsigned? [06:55:36] <elenril> ok [07:49:20] <cartman> moin [07:49:55] <spaam> God morgon [07:59:03] <elenril> wow, there's a rfc draft for asf [08:03:55] <KotH> salut [08:04:44] <elenril> ãã¯ãã [08:05:29] <spaam> elenril: going to read it tonight? [08:05:59] <elenril> spaam: nah, it's the same as the m$ specs [08:06:11] <spaam> elenril: super duper good? [08:06:12] <elenril> just older version [08:06:28] <elenril> kinda funny actually [08:08:56] <elenril> and makes their "no open source implementations" licence even less valid if that's even possible [08:10:04] <spaam> hehe [08:17:05] <siretart> hmm. seems that I slowly start to win over git send-email... [08:17:40] <kshishkov> good [08:19:40] <spaam> kshishkov: how does it go with bink-b? :) [08:20:02] <kshishkov> spaam: nagging Peter about it time from time [08:23:42] <pross-au> its working [08:24:04] <spaam> \o/ [08:24:12] <pross-au> will spend some time on the idct tonight [08:24:16] <spaam> pross-au: did you get it bitexact? [08:24:48] <pross-au> yes its bit exact, but only on x86, and only using __asm() [08:26:46] <pross-au> , and float. [08:31:12] <kshishkov> I don't think that is extremely important [09:07:33] <mmu> http://fate.ffmpeg.org/x86_32-haiku-gcc-4.4.4 \o/ [09:11:46] <av500> mmu: :) [09:11:56] <mmu> ;) [09:12:01] <saintdev> and it's even green o.O [09:12:07] <spaam> wooow [09:12:43] <spaam> mmu: is there a 64bit version of haiku? [09:16:26] <lu_zero> mmu: great! [09:18:27] <mmu> spaam: no, the port is just started [09:20:05] <elenril> do we have a function that can do 'find 137th video stream'? [09:27:10] <av500> not in avi :) [09:27:54] <pross-au> thats a lot of v.streams [09:41:01] <j-b> so, vbv-delay, in ms, 90kHz, 27Mhz or in double? [09:44:21] <Tjoppen> why not simply in the codec's time base? [09:44:33] <Tjoppen> whatever it might be [09:53:18] <lu_zero> AVRational? [09:53:30] <lu_zero> AVRational_long? [09:54:14] <Tjoppen> AVRational64 might be useful [09:54:50] <lu_zero> let's discuss it [09:54:59] <pross-au> lu_zero: make it a template AVRational(t) [09:55:05] <Tjoppen> isn't there already a fractional struct though? [09:55:12] <lu_zero> pross-au: I was thinking about that [09:55:15] <Tjoppen> that is, a + b/c [09:55:23] <Tjoppen> for pts stuff [09:55:31] <pross-au> (i was joking) [09:55:42] <lu_zero> pross-au: you can do templating in C [09:56:00] <pross-au> i know that :) [09:56:10] <lu_zero> even if sometimes things gets a bit extreme and convoluted (swscale HI!) [09:56:20] * elenril kicks ffmpeg.c [09:56:25] <elenril> why are mappings so obscure [09:56:46] <lu_zero> elenril: please document them better if you could [09:57:04] * Flameeyes stares at lu_zero [09:57:08] <elenril> i would if i actually understood how it works ;) [09:57:26] <lu_zero> Flameeyes: oui? [09:57:35] <Flameeyes> lu_zero: see skype [09:57:48] <lu_zero> uhm [09:59:02] <iive> Tjoppen: I think it was removed few years ago. [10:03:27] <elenril> can wmp select between video tracks? [10:10:58] <av500> doubt it [10:11:05] <av500> do you have a sample? [10:11:20] <elenril> there's one on samples [10:12:02] <elenril> wmp in xp can read it, but i don't see any option to switch streams [10:12:11] <av500> i dont think there is one [10:12:56] <elenril> what an awesome piece of software [10:13:19] <elenril> it also rejects multivideo ASFs created by asfenc [10:13:19] <av500> it was made for awesome users [10:13:33] <elenril> but maybe i'm just failing ffmpeg commandline syntax [10:13:34] <av500> elenril: wmp rejects a lot of stuff muxed by asfenc [10:13:42] <av500> even std 1v 1a tracks [10:14:05] <elenril> samples! bugreports! [10:14:07] <av500> and the asf verifier tool barfs on every asf muxed by asfenc [10:14:13] <av500> elenril: yes, will do [10:14:57] <elenril> oh crap [10:15:08] * elenril just accidentally whole file [10:15:14] * elenril <3 reflog [10:16:26] <elenril> and the asf verifier tool barfs on every asf muxed by asfenc << i thought i fixed that [10:16:42] <elenril> and it wasn't on every file, just wmv videos [10:16:54] <elenril> unless you mean some other asf verifier [10:18:06] <elenril> ok, my asf branch is getting kinda long [10:18:28] <elenril> i'd appreciate it if somebody commented on more patches than just the first one ;) [10:26:45] * av500 goes to find some whitespace nit [10:30:00] <j-b> kshishkov: waow, I didn't realize you had so much code! [10:30:45] <av500> j-b: tables [10:30:53] <av500> kshishkov: waow, I didn't realize you had so much tables [10:31:19] <av500> j-b: still trolling the swamp? [10:31:51] <j-b> yes, the fights again MPEG-Dash people was fun [10:31:54] <j-b> yesterday night [10:32:17] <av500> dash? [10:32:32] <j-b> dash [10:33:00] <av500> ah, dash [10:33:48] <j-b> adaptive streaming [10:34:04] <av500> yes [10:34:07] * Kovensky never realized people cared about asf [10:34:32] <iive> Kovensky: microsoft still uses .wmv [10:34:38] <Kovensky> most of the time when I see video in asf is because the uploader is going "look ma! no codecs!" [10:34:43] <KotH> kshishkov: i've still quite a few asf files [10:35:21] <av500> lot of porn in asf [10:35:36] <av500> KotH: didnt mean you :) [10:35:46] <Kovensky> iive: well, adobe still supports sorenson spark (and you can still find videos encoded in it) but do people care about it? :) [10:35:55] <KotH> av500: nah.. people know that i have lots of anime in asf :) [10:35:57] <elenril> Kovensky: hey, asf is still bettern than ogg [10:36:02] <av500> for sure [10:36:07] <av500> asf is in fact quite nice [10:36:10] <elenril> NO [10:36:14] <Kovensky> the real challenge is finding what *isn't* better than ogg [10:36:27] <av500> elenril: compared to mov, you can stream it :) [10:36:38] <elenril> av500: ok, compared to mov asf seems rather nice [10:36:46] <iive> Kovensky: support != use [10:36:49] <elenril> at least its specs are of manageable size [10:36:56] <av500> and adding a codec can be done somewhat generically [10:36:56] <j-b> and compared to nut? [10:37:11] <av500> unlike mov and mkv where each codec is "mapped" somehow [10:37:39] * elenril wonders why does reading index break when it's called from read_header() [10:38:10] <av500> because the index is at the end? [10:38:56] <elenril> so? [10:39:06] <elenril> there's no diffrence, you seek anyway [10:39:31] <av500> Machete don't seek [10:39:33] <elenril> now the index is read when you seek for the first time [10:39:57] <Kovensky> 07:37.12 av500: unlike mov and mkv where each codec is "mapped" somehow <-- making maps for matroska seems trivial though [10:40:13] <av500> Kovensky: unless it is RealAudio [10:40:26] <Kovensky> matroska has some overcomplicated mappings for some codecs [10:40:39] <av500> Kovensky: or unless it is WMV compat mode where PTS becomes DTS [10:40:48] <Kovensky> lol [10:40:56] <Kovensky> there's also V_MS/VFW/FOURCC! [10:41:07] <av500> yes, thats what I meant [10:41:19] * Kovensky has seen H.264 muxed in VFW mode ;_; [10:41:30] <av500> maybe it came from an asf file :) [10:41:40] <av500> maybe one can mux asf into mkv [10:42:09] <Kovensky> not really, mkvmerge *still* muxes ASP as VFW unless you use --engage secret_undocumented_flag_here [10:42:13] <av500> elenril: what about http streaming, do you really want to delay playing the stream be reading the index from read_header? [10:42:39] <Kovensky> think of the poor dialup users! [10:42:47] * Kovensky looks at dalias over at #mplayerdev [10:42:47] <av500> and their children [10:43:08] <av500> in fact, they should have many children, all that idle time... [10:43:17] <Kovensky> lol [10:43:36] <elenril> av500: it's only done when !url_is_streamed [10:43:37] * Kovensky remembers when he used dialup back on 2000~2004 [10:43:40] <av500> see countries with no dialup at all... [10:43:42] <Kovensky> had to wait until sundays! [10:43:45] <av500> elenril: ok then [10:47:53] <av500> j-b: so, what came out of this? [10:51:03] <j-b> av500: dash-webm! [10:52:21] <av500> daweb [11:06:50] <pross-au> Even though i call fesetround(FE_TONEAREST) before hand, gcc prefixes all my float operations with fstcw 0x1200 (trucate to zero rounding method) [11:07:48] <kshishkov> BTW how much quality degrades with non-bitexact IDCT? [11:08:04] <pross-au> not much [11:08:22] <pross-au> i need to calculate it [11:09:36] <pross-au> is there a way to invoke ffmpeg to calculate, say, the maximum luma difference of two frames ? [11:09:56] <kshishkov> not directly IIRC [11:10:11] <pross-au> idct isn't used that frequently, in my samples [11:10:19] <pross-au> so drift isnt a huge issue [11:11:44] <merbzt> ok, where is that code one can set so the container pts/dts can be trusted ? [11:12:49] <merbzt> right now when ffmpeg knows the stream codec is h264 the pts/dts disappear, if it doesn't they are correct [11:13:50] <pross-au> merbzt: libavformat/utils.c tb_unreliable() ? [11:17:03] * cartman abuses jni [11:18:01] <av500> cartman: best is to use jni to call c code that then calls java code [11:18:32] <av500> it's called garbage correction [11:18:37] <cartman> lol :) [11:22:00] <elenril> av500: you promised me a review! =p [11:22:01] <Dark_Shikari> garbage collection is very simple [11:22:03] <Dark_Shikari> rm *.java [11:22:07] <Dark_Shikari> garbage collected [11:25:09] <kshishkov> Dark_Shikari: proper Java garbage collection should remove JVM as well [11:33:05] <av500> elenril: there, I did :) [11:33:10] <av500> the rest is LGTM :)= [11:36:56] <elenril> haha [11:37:01] <elenril> somebody go apply it then =p [11:48:42] <Kovensky> 08:22.08 Dark_Shikari: garbage collected <-- find / $ -iname '*.java' -o -iname '*.class' -o -iname '*.jar' $ -delete [11:52:51] <kshishkov> Kovensky: find / -name Oracle -exec nuke {} \; [12:01:05] <spaam> kshishkov: maybe you should commit avseq.. then you can be the number one on git blame! :D [12:03:28] <pross-au> waits patiently for the .exe demuxer/decoder [12:05:16] <cartman> kshishkov: finally bink-b [12:05:20] <cartman> pross-au++ [12:05:24] <spaam> cant be true [12:05:31] <cartman> we are saved [12:05:34] <spaam> omg there it is! [12:05:42] <spaam> pross-au: gj :D [12:05:47] <cartman> LGTM [12:05:48] <kshishkov> pross-au: I'll review it [12:06:47] <pross-au> kshishkov: note that it uses your idct, there are some artifacts due to DCTELEM clipping [12:07:23] * mru thinks we should replace DCTELEM with int16_t [12:07:30] <mru> all the asm depends on it being that anyway [12:08:31] <spaam> mru: patch welcome ;) [12:09:01] <pross-au> for the bink variants we need more precision (well thats the hypothosis) [12:09:21] <mru> the it can't use the same type [12:09:39] <Dark_Shikari> mru: irock's 10-bit h264 decoding will require 32-bit dctelem [12:10:06] <mru> and that will require all new asm [12:10:09] <Dark_Shikari> Yes. [12:10:16] <Dark_Shikari> asm is already written. [12:10:17] <mru> and the old asm will still be used for 8-bit [12:10:20] <Dark_Shikari> Yes, of course. [12:10:28] <mru> so the point stands [12:10:38] <mru> we can never change DCTELEM as it is used now [12:10:44] <mru> so the indirection is pointless [12:11:03] <Dark_Shikari> Eh? [12:11:19] <mru> there's a typedef int16_t DCTELEM; somewhere [12:11:24] <Dark_Shikari> Sure, in the asm, it'll obviously be int16_t or similar. [12:11:25] <mru> change that and everything breaks [12:11:44] <Dark_Shikari> x264 has dctcoef and pixel types instead of int16_t and uint8_t [12:11:55] <Dark_Shikari> of course that's because we actually intended it to work that way [12:12:09] <Dark_Shikari> I don't know why DCTELEM has to be all caps though. [12:12:13] <Dark_Shikari> bugs me, for some reason. [12:12:13] <mru> for templating C versions it works of course [12:12:30] <av500> typedef short DCTELEM; [12:12:35] * Dark_Shikari punts av [12:12:36] <mru> even worse [12:12:50] <mru> all-caps typedefs remind me of windows [12:12:53] <mru> ULONG [12:12:57] <pross-au> AVDCTELEM(16) [12:13:18] <cartman> kierank: x262?! [12:13:22] <av500> Dark_Shikari: I just stated facts [12:13:48] <kierank> cartman: ? [12:14:02] <cartman> kierank: seen on github under your nick [12:14:08] <kierank> ya [12:14:19] <spaam> cartman: do you stalk kierank ?! [12:14:25] <cartman> spaam: of course [12:14:28] <kierank> spaam: another one [12:14:42] <cartman> kierank: just wondering wtf it is :) [12:14:46] <spaam> kierank: how many stalkers do you have? only cartman ? :) [12:15:36] <kierank> spaam: you [12:15:45] <spaam> kierank: me? pfff [12:15:48] <cartman> lol [12:16:13] <spaam> stupid bittorrent encrypted things ;SSS [12:16:30] <cartman> stupid slow VPN [12:16:37] <spaam> why cant they all use the same stuff so it will be easier for me ? :P [12:21:34] <DonDiego> pross-au: why all the casting in binkb_read_bundle()? [12:21:55] <spaam> DonDiego: 2slow [12:22:00] <kshishkov> DonDiego: buffer is uint8_t but it can be interpreted as int8_t and int16_t too [12:22:15] <DonDiego> couldn't you avoid it if you declared *dst as uint8_t? [12:23:05] <kshishkov> ? [12:23:32] <wbs> kshishkov: woulnd't that kind of pointer casting break on big-endian? [12:23:59] <kshishkov> wbs: it shouldn't - it's written natively [12:24:16] <wbs> kshishkov: ah, sneaky bastards [12:26:22] <kshishkov> well, the proper solution would be to rewrite it in C++ creating template Bundle class with instances operating on uint8_t, int8_t and int16_t [12:26:27] <kshishkov> or maybe not [12:31:55] <merbzt> av500: what is more likely, you rigging the raffle or me winning the panda by pure luck ? [12:33:02] <av500> merbzt: I did not rig it [12:33:06] <kshishkov> av500: you being lucky. Otherwise I'd get it (even if I didn't put an application there). [12:33:15] <kshishkov> err, to Ben [12:33:28] <av500> all i did was to tell omar to pick a business card because on day 2 it was all business cards [12:33:51] <mru> and you knew merbzt had left a business card [12:33:55] <mru> so you rigged it [12:34:03] <merbzt> av500: I'm just asking a hypothetical question [12:34:16] <kshishkov> BTW, have they fixed the memory slowness problem there? [12:34:17] <merbzt> I did not ask if you rigged it or not [12:34:19] <av500> i "rigged" the fact that there was one winner for each day [12:34:36] <merbzt> ;) [12:34:44] <mru> kshishkov: next silicon rev should help to some extent [12:34:55] <mru> kshishkov: and the omap4440 should be even better [12:35:13] <av500> mru: by the amount of work they put into a speed bin, yes :) [12:35:41] <mru> it has a newer A9 core [12:35:52] <spaam> Anyone know about what bitrates youtube uses for 360p, 480p, 720p + [12:35:53] <spaam> ? [12:35:58] <mru> and reworked interconntects between the a9 and sdrc [12:36:09] <kshishkov> mru: and OMAP5 should be even better but ElefantBoard is to be designed yet :( [12:36:46] <cartman> uhm OMAP4 widespread yet? [12:37:02] <av500> cartman: all over my office, so yes [12:37:14] <cartman> av500: nice point of view, send over one [12:37:33] <cartman> in exchange I'll send kÃ¶fte [12:37:40] <av500> not sure I am allowed to export to you [12:37:42] <kshishkov> cartman: only after you get Archos tablet with discount from him [12:37:50] <cartman> kshishkov: bah [12:37:59] <cartman> av500: You could if I am in *.de? [12:38:17] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * re4e234fad7 ffmpeg/libavformat/ (asf.h asfdec.c): [12:38:17] <CIA-38> ffmpeg: asf: make ff_guidcmp inline and move it to asf.h [12:38:17] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:38:26] <kshishkov> cartman: I'm the first in queue [12:38:27] <av500> cartman: go order a pandaboard like everybody else [12:38:37] <cartman> av500: too expensive [12:38:41] <cartman> kshishkov: heheh :) [12:39:02] <kshishkov> av500: I was going to steal it at FOSDEM like everybody else [12:39:19] <av500> kshishkov: you succeeded not [12:39:29] <kshishkov> av500: iKnow [12:39:46] <cartman> av500: did you load Android on them? [12:42:44] <av500> cartman: no time to port it yet [12:43:02] <av500> i put them on flickr like the rest [12:43:45] <cartman> av500: oh Android doesn't work on OMAP4 yet? Or some drivers lacking? [12:43:57] <av500> cartman: it was a joke [12:44:09] <cartman> bah [12:46:13] <cartman> Don't joke when I'm working :P [12:46:32] <av500> so I can joke always [12:46:54] <cartman> mostly [13:13:55] <Orphis_> Great, cron on cygwin is finally working, I guess I can now add some lines in my crontab to make the reports for win64 [13:14:42] <mru> Orphis_: send me your ssh public key when you're ready to start submitting [13:17:35] <Orphis_> I'll send it by mail in a few minutes [13:43:34] <DonDiego> btw, trivia of note: gabu is also the only person to ever have been banned from xine-devel... [13:46:04] <kshishkov> so he had interest beside MPlayer... [13:46:21] <DonDiego> the funny thing was that these were the words gÃŒnter bartsch (xine project founder) used to greet gabu at linuxtag back in the days (2004?) [13:46:39] <DonDiego> he had interest in flaming, not necessarily restricted to mplayer [13:48:01] <DonDiego> funny was also the reaction - goofy (gÃŒnter) is about 200m tall while gabu's eye level barely reached his navel :-) [13:48:30] <KotH> DonDiego: lt 2003 [13:48:31] <spaam> s/200m/200cm/ ? [13:49:25] <KotH> spaam: no, really 200m [13:49:34] <KotH> günther is a giant! [13:49:42] <spaam> KotH: Nice! [13:50:24] <DonDiego> he is really tall, dunno how much, but surely 2,xx meters [13:50:40] * KotH would have said 1.9 or so... [13:50:56] <DonDiego> well, gabu was standing next to him ;) [13:51:02] <KotH> gabu was rather small :) [13:51:28] <DonDiego> anyway, his nickname is fitting, he is tall and thin and âŠ goofy - not meant in a negative way... [13:52:28] <kshishkov> and a dog? [14:02:18] <pJok> kshishkov, i see a bink-b patch [14:02:32] <kshishkov> pJok: yes, so? [14:03:28] <pJok> kshishkov, finally? [14:03:29] <pJok> :) [14:03:46] <DonDiego> offtopic: does anybody have some experience with git-svn and local commits that disappear after you push some but not all of them to the svn server? [14:03:55] <av500> DonDiego: as i read it, he is also baned from wiki.hu for life: http://hu.wikipedia.org/wiki/WikipÃ©dia:SzerkesztÅk_szankcionÃ¡lÃ¡sa/Gabuc… [14:03:59] <DonDiego> *highly* annoying... [14:04:44] <kshishkov> av500: you can read it? [14:04:53] <av500> google can [14:06:10] <kshishkov> DonDiego: can you hint him to troll VLC so he can earn another ban for his collection? [14:07:26] <DonDiego> lol [14:07:30] <pJok> kshishkov, aren't they french? [14:07:34] <bilboed-tp> DonDiego, keep a separate branch that git-svn won't touch [14:07:42] <kshishkov> pJok: oui, messeur [14:07:47] <bilboed-tp> DonDiego, and do all your work there [14:08:00] <pJok> kshishkov, that should give him a ban much faster than anywhere else then [14:24:14] <av500> http://www.slideshare.net/ranjithsiji/ffmpeg-tools [14:24:54] <cartman> 502 Bad Gateway [14:24:56] <cartman> nice slides [14:25:10] <kshishkov> av500: the name brings fear into my soul [14:25:20] <DonDiego> av500: where did you find out about that ban? [14:25:45] <av500> DonDiego: I must not reveal my methods, but they involve a tiny startup in mountain view [14:26:01] <av500> they develop self driving cars [14:26:19] <kshishkov> and sponsor BB development too [14:26:33] <kierank> av500: that pic is not michaelni [14:26:38] <cartman> Everything is tiny compared to av500 [14:26:55] <av500> kierank: i did not make the slides, but yes [14:27:11] <av500> its a dr michaelni from berlin [14:27:39] <av500> the copy paste indian did not google hard enough [14:27:52] <kshishkov> av500: do you have real MN photo? [14:30:35] <av500> the fabrice pic is also wrong btw [14:30:58] <av500> but i guess to indian we all look the same [14:31:02] <av500> jai: no offence [14:33:10] <kshishkov> av500: you and me - definitely [14:33:24] * cartman has no picture of kshishkov either [14:33:32] <av500> cartman: in my flickr [14:33:38] <cartman> aha [14:33:44] <av500> cartman: the one you "friended" [14:33:51] <av500> but I will not post on your wall [14:33:51] <cartman> lol [14:33:58] <cartman> like me, poke me [14:34:57] <av500> /unfriend [14:34:59] <av500> oops [14:35:22] <cartman> :P [14:35:33] <kshishkov> av500: http://www.flickr.com/photos/av500/5304197100/ <- probably the nicest piece of hardware you've ever photographed [14:35:42] <cartman> soon we might be neighbours [14:35:48] <cartman> who knows :P [14:35:53] * av500 digs deeper [14:36:00] <av500> kshishkov: you want it? [14:36:08] <av500> its going on ebay soon [14:36:19] <av500> and it has the upgrade, so its a palm V in fact [14:36:37] * kshishkov is very tempted but must resist it [14:36:42] <kierank> I had a palm vx [14:36:49] <kierank> but it got smashed on a plane [14:36:53] <av500> kshishkov: I have a V too and a tungsten [14:37:07] <av500> kierank: how did the plane smash the palm? [14:37:09] <cartman> av500: somewhere here, http://www.flickr.com/photos/av500/4767125825/ ? [14:37:58] <av500> nope [14:38:02] <kierank> av500: dunno, put it in a bag in the overhead locker i guess and the flight attendant forced the locker shut [14:38:09] <av500> ah [14:38:58] <cartman> av500: what size is he? [14:39:09] <av500> 3xl [14:39:33] <kshishkov> av500: and you? [14:39:46] <kierank> who is the guy second from the right [14:39:53] <av500> mchinen [14:40:01] <av500> ah no [14:40:04] <av500> wrong pic [14:40:17] <kshishkov> kierank: sitting/standing? [14:40:18] <av500> standing on the right is stefan [14:40:27] <kierank> standing [14:40:31] <kshishkov> aka Chinese Stefan [14:40:32] <kierank> who's below [14:40:35] <av500> janne, mru, diego, stefan, $random_xbmc [14:41:20] <cartman> av500: you should learn to tag [14:41:32] <av500> cartman: :effort: [14:41:33] <spaam> use facebook for it! [14:41:48] <av500> i barely mange to upload unless its one click from the phone [14:41:49] <kshishkov> av500: but tagging is a popular children' game [14:42:06] <cartman> teach your kids to do it [14:42:13] <av500> and google should know who these faces belong to anyway.... [14:42:15] <thresh> yeah, flickr always wants my yahoo account, and I remember no such thing [14:42:22] <DonDiego> doh, it seems that gabucino has also become an jew hater and holocaust denier ... [14:42:24] <DonDiego> http://www.subsim.com/radioroom/showthread.php?t=159374&page=2 [14:42:28] <cartman> thresh: they now work with Google accounts [14:42:55] <DonDiego> to even think that there were people complaining about his ban... [14:43:01] * DonDiego shakes his head [14:43:50] <thresh> is denying holocaust bad? [14:43:56] <cartman> "There is no need for you to get personal, don't do that." [14:43:57] <cartman> :D [14:44:12] <kshishkov> DonDiego: rule #something - there are always few people on Internet thinking the same as you [14:44:31] <kshishkov> thresh: well, it's a crime in some places [14:44:44] <cartman> in .de most notably [14:44:47] <twnqx> and there's most often the vast majority of "don't care" [14:45:05] <cartman> now I know how what to blame av500 on [14:45:30] <DonDiego> thresh: trying to troll or what? [14:45:51] <thresh> DonDiego: no. [14:46:09] <av500> godwin now! [14:46:17] <av500> kshishkov: trains please [14:47:04] <DonDiego> yes, it is bad and a clear sign that the person that utters such shit is not one i want to have to deal with in any way [14:47:37] * thresh reads wiki on that [14:49:02] <kshishkov> av500: Belgium is a kingdom and Belgian trains suck royally [14:49:18] <cartman> Good thing is you can deny God's existence [14:50:26] <bilboed-tp> kshishkov, whereas in Monaco they only suck in principle ? [14:50:32] <kshishkov> av500: they should replace benches in regional trains into wooden ones and then they'll be even worse than Ukrainian [14:50:53] <DonDiego> thresh: you dunno what the holocaust is? [14:50:59] <cartman> kshishkov's never ending rambling :) [14:51:02] <thresh> DonDiego: Of course I do know what that is [14:51:14] <thresh> DonDiego: I don't know why people would want to deny it though [14:51:18] <kshishkov> bilboed-tp: I'm not sure they have them at all [14:51:26] <thresh> and that's what I'm following up on now [14:51:40] <cartman> why would you care to deny it [14:52:48] <kshishkov> cartman: as always - to make somebody look better than he really is [14:56:23] <kshishkov> like some people telling lies about trains coming on time [14:56:34] <cartman> lol [14:57:52] <cartman> kshishkov: I suggest the Turkish way: http://4.bp.blogspot.com/_zUw28h3Phqk/TGMBTvBcJEI/AAAAAAAAAIY/ziPbdmGVFcg/s… [14:58:10] <av500> cartman: u could have gotten out and helped [14:58:18] <cartman> av500: no way [14:58:23] <kshishkov> cartman: what's special about it? [14:58:43] <av500> kshishkov: nobody with a whip driving the people [14:58:53] <av500> so it will be late [14:59:11] <cartman> we could push trains too [14:59:15] <cartman> human > horse power [15:03:40] * cartman does a late FATE [15:04:03] * kshishkov is proud of that contribution to FFmpeg [15:04:51] * cartman is abusing ffmpeg as compiler regression tool and it works fine [15:05:16] <kshishkov> cartman: you can't - FFmpeg is compiler regression tool [15:05:33] <cartman> I never abuse it as an encoder then [15:06:08] <kshishkov> of course [15:06:27] <kshishkov> except that you can accidentally abuse it as AAC encoder [15:06:33] <cartman> heheh [15:06:49] <cartman> av500: wondering, do you guys have "lahmacun" over in *.de? [15:06:58] <av500> sure [15:07:05] <av500> at least they call it that [15:07:10] <cartman> good :> [15:08:05] <cartman> nice, my compiler warnings are halved now [15:08:44] <av500> used a smaller font? [15:09:03] <cartman> did a > /dev/null [15:09:03] <spaam> hÃ¶hhÃ¶ [15:18:02] * Compn wonders where all the flames went [15:18:42] <ubitux> someone made a clear cease-fire recently [15:19:19] <ubitux> so he may have calm down things a bit, which is quiet pleasant :) [15:19:42] <cartman> http://notalwaysright.com/byte-off-more-than-you-can-chew/2372 [15:20:42] <elenril> Compn: you miss the flames? [15:21:19] <cartman> elenril: its cold in here [15:36:36] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rc2bd7578af ffmpeg/doc/APIchanges: Add missing git revision hask. [15:36:38] <CIA-38> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * r37b00b47cb ffmpeg/ (11 files in 5 dirs): [15:36:38] <CIA-38> ffmpeg: Frame-based multithreading framework using pthreads [15:36:38] <CIA-38> ffmpeg: See doc/multithreading.txt for details on use in codecs. [15:36:38] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [15:36:44] <BBB> astrange: \o/ [15:36:46] <kshishkov> hask? [15:36:47] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rf2146944fc ffmpeg/doc/APIchanges: Add missing git rev hash. [15:36:48] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r8e8cc52be3 ffmpeg/doc/APIchanges: Add missing git rev hash. [15:36:51] <CIA-38> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * rc0b102ca03 ffmpeg/ (8 files in 3 dirs): (log message trimmed) [15:36:51] <CIA-38> ffmpeg: Deprecate avcodec_thread_init() [15:36:51] <CIA-38> ffmpeg: As a side effect of the last commit, avcodec_open() now calls it automatically, [15:36:51] <CIA-38> ffmpeg: so there is no longer any need for clients to call it. [15:36:51] <CIA-38> ffmpeg: Instead they should set AVCodecContext.thread_count. [15:36:51] <CIA-38> ffmpeg: avcodec_thread_free() is deprecated, and will be removed from avcodec.h at the [15:36:52] <CIA-38> ffmpeg: next MAJOR libavcodec bump. [15:36:53] <CIA-38> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * rd23845f311 ffmpeg/libavcodec/vp3.c: (log message trimmed) [15:36:53] <CIA-38> ffmpeg: vp3: Frame-based multithreading support [15:36:53] <CIA-38> ffmpeg: Decode times for big_buck_bunny_720p_stereo: [15:36:54] <CIA-38> ffmpeg: 1 thread: [15:36:54] <CIA-38> ffmpeg: real 1m14.227s [15:36:55] <CIA-38> ffmpeg: user 1m13.104s [15:36:55] <CIA-38> ffmpeg: sys 0m1.108s [15:37:39] <Kovensky> 37b00b47cb <-- \o/ [15:38:42] <elenril> \\o// [15:38:54] <av500> \\\ooo/// [15:38:57] <Kovensky> \\\\\o///// [15:39:05] * Kovensky should resume ika musume [15:39:06] <BBB> omg an octopus [15:39:17] <kshishkov> \\\\\\\\\\\(;,;)/////////// [15:39:36] <elenril> BBB: wtf is with all the Add missing git revision hash [15:39:41] <Kovensky> BBB: well, the reference is to a squid, actually ;) [15:40:05] <av500> finally I can watch all my theora content 40% faster [15:40:09] <cartman> ha [15:40:11] <cartman> yay [15:40:30] <DonDiego> omg [15:40:36] <DonDiego> i cannot believe it... [15:40:40] <cartman> now add threading support to h264 [15:40:49] <elenril> DonDiego: h264 is not in yet [15:40:59] <av500> who needs h264 [15:41:11] <av500> when we have free codecs [15:41:12] <cartman> I need H265 please [15:41:20] <av500> cartman: here: "+1" [15:41:44] <kierank> av500: http://www.youtube.com/watch?v=PZF5wpntXsk [15:41:50] * kshishkov gives cartman VP9 instead [15:42:05] <Kovensky> http://4.bp.blogspot.com/_7ktzqvLUg1U/TN1jith-XNI/AAAAAAAABvc/RKVFL6MW9zk/s… <-- this [15:42:32] <av500> Kovensky: where is the octopus? [15:42:49] <Kovensky> that is japan's version of a squid [15:43:09] <siretart> yay @-mt! :-) [15:43:17] <JEEB> woah [15:43:20] <JEEB> -mt is in? [15:43:25] <av500> oui [15:43:26] <JEEB> WRRYYYYYYY [15:43:29] <bilboed-tp> w00t [15:43:33] * JEEB goes rebuild some stuff [15:43:35] <siretart> JEEB: check backlog 10 minutes ago [15:43:39] <JEEB> yeah [15:43:54] <JEEB> I see it :) Just was waiting for "Oh, it's not the full thing" etc. [15:43:56] * cartman FATEs [15:43:57] <kshishkov> Kovensky: "ika" is rather a cuttlefish [15:45:07] <JEEB> oh well, I guess I'll wait some more for H.264 [15:45:20] * Kovensky wonders what's a cuttlefish [15:45:47] <Kovensky> though I guess I shouldn't look too deep into japanese fish names since that's one thing they certainly were thorough with kanji [15:46:41] <elenril> lol [15:47:13] <JEEB> ika as the overall word covers both cuttlefish and lots of squids [15:47:21] <JEEB> it isn't really set in stone [15:47:22] <JEEB> http://ja.wikipedia.org/wiki/%E3%82%A4%E3%82%AB [15:48:07] <JEEB> see the "åé¡" part [15:49:51] <elenril> BBB: what's missing for h264 parts? [15:50:02] <elenril> only review from more people? [15:50:17] <cartman> FATE looks green, nice [15:54:36] <BBB> elenril: he didn't submit it yet [15:54:52] <BBB> cartman: I did a lot of fate checking with these patches ;) [15:55:00] <BBB> I don't think fate will break all that much [15:55:03] <cartman> BBB: good to know! :) [15:55:47] <DonDiego> mru: qnx compilation just died... [15:55:58] <DonDiego> CC libavcodec/snow.o [15:55:58] <DonDiego> /misc/fate/work/quadra/src/libavcodec/snow.c: In function 'encode_frame': [15:55:58] <DonDiego> /misc/fate/work/quadra/src/libavcodec/snow.c:3974: internal compiler error: in add_insn_before, at emit-rtl.c:3698 [15:55:58] <DonDiego> Please submit a full bug report, [15:55:58] <DonDiego> with preprocessed source if appropriate. [15:55:59] <DonDiego> See <http://www.qnx.com> for instructions. [15:55:59] <DonDiego> make: *** [libavcodec/snow.o] Error 1 [15:56:09] <mru> DonDiego: I can read [15:56:28] <mru> probably just a fluke crash [15:56:38] <DonDiego> one more ICE that ffmpeg triggered... [15:56:44] <mru> or bad ram [15:56:48] <mru> it's an ancient machine [15:57:13] <kshishkov> DonDiego: ICE? Not Thalys? [15:57:23] <mru> the ram is from 2005 or older [15:59:10] <av500> stupid question, how do I edit one git commit? commit something else and merge them togoether? [15:59:27] <av500> aka a typo [15:59:30] <av500> e.g. [15:59:35] <kierank> git reset --soft HEAD~1 [15:59:45] <av500> what does that do? [15:59:57] <kierank> undoes the commit [16:00:03] <av500> but keeps my changes? [16:00:04] <kshishkov> git rebase -i [16:00:06] <ubitux> there is simpler [16:00:27] <ubitux> git rebase -i HEAD~2, and you transform your typo fix into a fixup commit [16:01:00] <Kovensky> av500: git commit --amend [16:01:21] <cartman> amend will only work for the last commit [16:01:24] <Kovensky> av500: --amend will merge anything you `git add`ed with the HEAD commit and open $VISUAL to edit the commit message [16:01:37] <Kovensky> cartman: that's what he asked how to do =p [16:01:46] <ubitux> btw, if someone has a way to simplify this: git commit -a -m fixup; git rebase -i HEAD~2 (+transformation into a fixup commit) [16:01:49] <ubitux> i'm interested [16:01:51] <av500> Kovensky: no, also a non last commit [16:02:06] <Kovensky> for non-last? then only a rebase can do [16:02:32] <av500> well, what do you do if your post a series of commits and get remarks? [16:02:46] <ubitux> git rebase -i :p [16:02:49] <Kovensky> you don't have to commit then merge btw, if you set the commit on the interactive rebase to 'e', you can edit however you want, git add, git commit, then git rebase --continue [16:03:05] <Kovensky> at least IIRC that's how rebase works =p [16:04:15] <ubitux> av500: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-January/067416.html â i explained quickly how to hack with the rebase here [16:04:25] <Kovensky> av500: personally I'd do each patch on a topic branch, edit whatever you want, then at submit time merge to master, rebase squashing every commit [16:04:48] <Kovensky> idk if that's the best method though [16:05:06] * kshishkov fixups instead of squashing quite often [16:05:30] <av500> Kovensky: and if patched depends on each other? [16:05:33] <av500> patches [16:05:36] <Kovensky> I think the *right* way is for the release manager to pull the topic branch from your personal repo and merge to master [16:06:21] <av500> Kovensky: yes, but atm, ppl post to -devel [16:06:35] <Kovensky> av500: depending on how you develop, then you either use tags or two topic branches [16:06:50] <Kovensky> the second topic branch branching from the HEAD of the dependent topic branch instead of branching from master [16:06:59] <av500> ah [16:07:01] <av500> gee [16:07:39] <Kovensky> those are (probably) the "right" ways though, you can do sth else if you feel better =p [16:08:08] <av500> I will do it like svn, use 2 trees and beyondcompare :) [16:09:03] <cartman> av500: pffff use diff -urN [16:26:11] * av500 sent his 1st git patch [16:26:24] <cartman> av500: congrats. [16:26:26] <cartman> LGTM [16:26:55] <av500> :) [16:27:24] * av500 runs ffmpeg thru indent and sends that as 2nd patch [16:27:53] <cartman> mru will kill you :P [16:29:54] <spaam> av500: nice patch. [16:40:25] <merbzt> can you get interlacing info from parsing the h264 headers ? [16:41:23] <Kovensky> wouldn't that be interlacism [16:41:25] <av500> merbzt: fun, I need that for mpeg2 right now :) [16:41:28] <mru> not enough to be reliable [16:41:34] <mru> h264 interlacing is 10x worse than mpeg2 [16:41:54] <av500> as it can be per macro block? [16:42:08] <Kovensky> yes [16:42:08] <mru> that's only part of it [16:42:09] <Kovensky> MBAFF [16:42:29] <horlicks> lies mbaff is lovely [16:42:36] <horlicks> :p [16:42:54] <merbzt> I just need to know if it is MBAFF or not [16:43:44] <av500> given an mpeg2 "frame", how do I tell if its frame or a field? [16:44:13] <mru> mpeg2 is easy [16:44:28] <mru> there are about 3 or 4 flags that matter [16:44:49] <mru> if sequence header has progressive_sequnce set, no frames are interlaced [16:45:18] <elenril> wow, a patch from av500 [16:45:26] <mru> if not, each frame can be coded as progressive, interlaced frame picture, or two field pictures [16:45:28] <elenril> and -mt is merged [16:45:32] <mru> picture header will tell which [16:45:34] * elenril checks temperature in hell [16:45:35] <merbzt> elenril: bring out the champagne !!! [16:46:29] <merbzt> mru: would be nice if avcodec context had and interlacing mode flag [16:46:33] <av500> elenril: I have sent patches before :) [16:46:40] <elenril> i know [16:48:04] <merbzt> mru: that is my next thing I will nag about until someone implements it :) [17:00:09] <kierank> merbzt: how do you plan to flag fake-interlaced encoded video? [17:00:17] <kierank> at the header level you don't know what it's going to be [17:00:41] <mru> there are two kinds of fake [17:00:56] <mru> actually interlaced images coded as progressive [17:01:07] <mru> and progressive images coded interlaced [17:01:14] <mru> the latter has two forms [17:01:32] <mru> really coded interlaced and progressive with repeat_first_field set [17:01:35] <kierank> yeah i was referring to x264's "fake-interlaced" mode, which is frame mode PAFF [17:01:49] <merbzt> I just need to know if it is MBAFF or not [17:02:00] <mru> don't forget the SEI repeat messages either [17:02:09] <av500> mru: found the flag, it was already in my code... [17:02:46] <kierank> merbzt: there's a mbaff flag [17:03:03] <merbzt> k, that sounds easy enough to use [17:05:03] <Orphis> Yay, my first report : http://fate.ffmpeg.org/x86_64-mingw-w64-gcc-4.5/20110209165835 [17:05:16] <av500> No tests were run [17:05:36] <kierank> x86_64-w64-mingw32-gcc: vfork: Resource temporarily unavailable [17:05:38] <Orphis> Yes, someone broke compilation, it was working a few revisions before [17:05:46] <av500> -mt? [17:05:52] <Orphis> I guess so [17:05:53] <mru> yes [17:06:00] <mru> it broke systems w/o pthreads [17:06:03] <Orphis> And that resource temporarily available is strange [17:06:15] <Orphis> Why can't it be reliable ?! [17:06:27] <mru> reliably unavailable? [17:07:00] <lu_zero> vfork? [17:07:30] <Orphis> cygwin is failing sometimes for no obvious reason (other than it's a ugly hack) [17:07:52] <lu_zero> I always had problems with msys [17:08:07] <lu_zero> cygwin more or less works nicely [17:08:29] <lu_zero> (for the small purposes I had) [17:08:55] <lu_zero> I never checked how it worked ^^; [17:17:05] <Orphis> mru: Would it cause a problem if I run fate.sh again and submit the results if there has been no change to the git since the last submission ? [17:17:20] <mru> no [17:17:32] <mru> don't run it more than once per second though [17:17:58] <mru> that's not supported [17:18:04] <Orphis> Don't worry, cygwin makes it too slow to do that :p [17:18:21] <Orphis> I'd like to rerun it so the real compilation error is shown [17:18:37] <mru> the 32-bit build shows the real error [17:18:58] <Orphis> I've had a different one, which is related but well [17:19:35] <Orphis> I can wait for the next commit anyway [18:02:31] <Orphis> There seems to be a conflict between some driver and cygwin... Great, let's remove the driver and check if it's now working [18:18:56] <BBB> Orphis: awesome! I guess it's not reliable yet, but that'll come [18:23:57] <CIA-38> ffmpeg: Vladimir Pantelic <vladoman(a)gmail.com> master * rf4c79d1e0b ffmpeg/libavformat/mpegts.c: [18:23:57] <CIA-38> ffmpeg: mpegts: remove unused macro MAX_SCAN_PACKETS [18:23:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:24:25] <av500> \o/ [18:25:07] <Orphis> BBB: There's a known problem with a webcam service that injects a DLL in every process, so I've stoped that service [18:25:17] <av500> wtf? [18:25:22] <thresh> wow, a patch by av500 [18:25:34] <BBB> it removes code, that doesn't count :-p [18:25:38] <av500> :( [18:25:41] <thresh> I have useless patches too, to enable HPUX compilation [18:25:49] <mru> thresh: send 'em in [18:25:55] <av500> thresh: it was more a git test [18:26:07] <elenril> BBB: removing code is the best kind of patches [18:26:11] * elenril loves removing code [18:26:14] <thresh> mru: ok [18:28:21] <av500> elenril: /me too [18:28:27] <av500> less code = less bugs [18:34:02] <av500> hmm, mpeg2 stream with each field separate, why is the 2nd field of each I frame marked as P? [18:36:45] <mru> does it contain predicted blocks? [18:37:03] <mru> iirc the second field is allowed to predict from the first [18:38:25] <av500> ah right [18:38:42] <av500> didnt thiunk of that [18:38:47] <av500> so its "legal" [18:40:28] <Orphis> Finally, compilation went as far as it could ! I hope no more problem will arise... [18:41:42] <BBB> Orphis: my impression is that it just randomly fails b/c cygwin isn't very stable :-p [18:41:53] <BBB> oh I should get colloguy-iphone [18:42:10] <av500> BBB: ? [18:43:10] <Orphis> I've read scary things about cygwin... like it could run out of available PID [18:43:54] <Orphis> But most of the time, it's due to some service or antivirus or bloatware doing stuff in the backgroudn and hijacking the processes [18:45:17] <Orphis> By the way BBB, do you want me to install nasm too or yasm will be enough ? [18:47:44] <wbs> BBB, lu_zero: Care to review the "udp: Enable address reuse by default for multicast" patch I sent the other day? [18:55:55] <BBB> Orphis: either one [18:56:14] <BBB> wbs: I was hoping lu_zero would review; I'll review it in a bit :) [18:56:54] <BBB> oh yeah I looked at it, a little ugly but I guess it's ok [18:57:00] <BBB> wbs: can it be done in a less ugly way? [18:57:20] <wbs> BBB: no, it's necessary to keep corner case behaviour [18:57:28] <BBB> ok then it's fine [18:58:14] <BBB> (I looked at it earlier and that's what I figured, but I wasn't sure, so was hoping lu_zero would know better) [18:58:19] <BBB> I'll queue it later today [18:58:44] <wbs> great, thanks :-) [19:12:27] * elenril tries some patch review [19:16:54] <kshishkov> av500: http://codecs.multimedia.cx/?p=323 [19:17:57] <elenril> that's what av500 looks like? [19:18:20] <kierank> elenril: the stuff of nightmares [19:18:23] <kshishkov> T-shirt may give a hint [19:18:30] <mru> elenril: yes, and note the laptop for scale [19:18:35] <mru> iirc that's a 15" [19:19:29] <elenril> lol [19:25:43] <kshishkov> okay, fixed [19:28:44] <Dark_Shikari> mru: Gaikai is interested in someone who knows their shit regarding ARM, mobile devices, and set top boxes. i.e. someone who could, say, write a native media player app that isn't crap, knows network code, etc. Also note: probably doesn't include iShit. [19:28:50] <Dark_Shikari> Do you know anyone who might be interested? [19:28:53] <Dark_Shikari> (NB: probably fulltime) [19:47:20] <mru> Dark_Shikari: permanent position? [19:47:33] <Dark_Shikari> Indefinite, at least. i.e. a real job. [19:47:41] <Dark_Shikari> I figure you would know more people in this space than anyone else I know. [19:48:42] <mru> btw, developing 3rd-party apps always sucks, regardless of the device [19:48:51] <mru> some suck more of course [19:49:00] <kshishkov> develop wrapper instead! [19:49:18] <mru> but it's always the same story [19:49:39] <kierank> maybe that arm guy who wrote mlp might be interested [19:50:01] <mru> can't access $proper_way because the platform owner deliberatly (apple) or through incompetence locks you out [19:51:12] <Dark_Shikari> I know [19:51:15] <Dark_Shikari> part of the intention is: [19:51:18] <Dark_Shikari> 1) Develop 3rd party app [19:51:23] <Dark_Shikari> 2) Show to platform owner [19:51:32] <Dark_Shikari> 3) Platform owner is OMG THIS IS FUCKING SWEET how can we get this working for real [19:51:37] <Dark_Shikari> 4) Give us API access! [19:51:48] <Dark_Shikari> So far we've been very, very successful in doing this in most cases. [19:52:09] <Dark_Shikari> It's just that "knows networking", "knows video", and "knows performance" is a rare combination. [19:52:59] <wbs> Dark_Shikari: successful as in dealing non-SDK apis with apple? [19:53:14] <wbs> ah, you explicitly said it wasn't iShit [19:53:52] <Dark_Shikari> we already have someone who does ishit [19:57:34] <BBB> iShit is fun :-p [19:57:55] <kierank> mru: or doesn't understand how to access $proper_way themselves [19:58:17] <mru> kierank: that's the incompetent ones [19:58:39] <BBB> astrange: ping [19:59:01] <kshishkov> kierank: proper engineer can always make something plausible up (c) mru [20:13:11] <mru> BBB: ping [20:20:56] * elenril wonders where did all the people promising review and cake go [20:21:16] <mru> the cake is under review [20:21:34] <elenril> is that what we're callint it now? [20:23:04] <mru> elenril: what do you want reviewed? [20:23:43] <elenril> everything! [20:23:47] <elenril> the rest of asf stuff [20:23:51] <elenril> avio renames [20:24:14] <elenril> avformat moves (though those probably should wait until the merge) [20:24:22] <kshishkov> but no game codecs - nobody obviously has an experience to review them [20:28:06] <BBB> mru: pong [20:28:31] <BBB> elenril: will review asf, I will [20:28:42] <mru> BBB: mt build fixes on ml [20:28:50] <BBB> oh, for !pthread? [20:28:53] <mru> BBB: I was going to ask you something about that but figured it out [20:30:33] <astrange> mru's patch is ok [20:31:27] <astrange> there's a definition of ff_thread_init with !HAVE_THREADS higher up, so it could define an empty ff_thread_free there, but it'd be somewhat pointless [20:31:56] <mru> I thought of that too, but it seemed unnecessary [20:34:49] <BBB> elenril: "[PATCH 07/10] asfdec: deobfuscate reading video properties size" actually changes behaviour, is that intended? [20:36:21] <BBB> elenril: and the rest appears to have to be resent largely, so I'll wait for you to resend them [20:38:02] <elenril> BBB: what do you mean? [20:38:13] <BBB> you're reading two values, called size and sizeX [20:38:17] <BBB> later size is used [20:38:25] <BBB> then you remove reading size and replace it by a skip [20:38:28] <BBB> and just read sizeX [20:38:32] <BBB> and now you use sizeX later on [20:38:35] <BBB> but that's not the same [20:38:41] <BBB> because size != sizeX [20:39:35] <elenril> - size= sizeX; [20:39:47] <BBB> oh, that _is_ obfuscated [20:39:51] <BBB> wtf :) [20:40:11] <mru> that should prove the usefulness of the patch [20:41:00] <BBB> mru: did you push "[PATCH] lavf: make ff_guidcmp inline and move it to asf.h"? [20:41:10] <elenril> so i'll just dump the whole branch again [20:41:20] <elenril> BBB: yes, he did [20:41:37] <mru> yes [20:41:38] <elenril> ...or maybe not all of it [20:41:44] <elenril> TheWorldIsNotReady [20:42:47] <BBB> I've got 2/10 queued, I think [20:42:54] <BBB> I'll push it, makes your life easier [20:43:35] <BBB> pushed [20:43:37] <BBB> anything else? [20:43:40] <elenril> great [20:43:43] <BBB> will await your next patchset [20:43:45] <CIA-38> ffmpeg: Reimar DÃ¶ffinger <Reimar.Doeffinger(a)gmx.de> master * r2cfa2d9258 ffmpeg/libavcodec/utils.c: [20:43:45] <CIA-38> ffmpeg: check sample_fmt in avcodec_open [20:43:45] <CIA-38> ffmpeg: check AVCodecContext->sample_fmt against AVCodec->sample_fmts[] to ensure [20:43:45] <CIA-38> ffmpeg: that the encoder supports the specified sample format. Error out if it doesn't. [20:43:45] <CIA-38> ffmpeg: Previously, it would continue and output garbage. Fixes issue 2587. [20:43:47] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r4bc328a2bd ffmpeg/libavformat/ (asf.h asfdec.c asfenc.c): [20:43:47] <CIA-38> ffmpeg: asf: split ASFContext into muxer and demuxer parts. [20:43:47] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:43:53] * elenril resolves conflicts [20:44:03] <BBB> oh I had another one queued [20:46:07] <elenril> and yeah, i wanted to rename them too, but that's yet another huge and boring patch [20:46:31] <BBB> I'm sure cleaning up asfdec is much more exciting [20:46:55] <elenril> it's quite fun [20:48:32] * BBB awaits next mailbomb [20:51:31] <BBB> elenril: what was the verdict on the put_/get_*() rename? [20:51:39] <BBB> elenril: I thought I OK'ed it, did it get committed? [20:51:54] <BBB> (sorry if I didn't, I wanted to push -mt first) [20:53:07] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r9a77a92c2b ffmpeg/libavcodec/utils.c: [20:53:07] <CIA-38> ffmpeg: Fix build with threading disabled [20:53:07] <CIA-38> ffmpeg: The avcodec_thread_free() compatibility wrapper calls ff_thread_free(), [20:53:07] <CIA-38> ffmpeg: which is not defined when threading is disabled. Make this call [20:53:08] <CIA-38> ffmpeg: conditional. [20:53:08] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:53:17] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * raef669cdfd ffmpeg/libavcodec/w32thread.c: [20:53:17] <CIA-38> ffmpeg: w32thread: add missing #include thread.h [20:53:17] <CIA-38> ffmpeg: This should fix building with win32 threads. [20:53:17] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:53:23] <BBB> I wonder why he signs off on his own patches [20:53:33] <BBB> mru: should I do that too? ^^ [20:53:56] <kshishkov> BBB: should be good for bookkeeping [20:54:22] <mru> that's what they do in kernelspace [20:54:29] <elenril> BBB: Flameeyes suggested making the deprecated functions inline [20:55:02] <elenril> or was it the new ones [20:55:12] * elenril doesn't understand this magic very well [20:55:28] <BBB> that's a bad idea [20:55:39] <BBB> old apps are already compiled [20:55:46] <BBB> they expect a _symbol_ there, not just the api [20:55:53] <BBB> if the symbol isn't there, they will still not load [20:56:10] <BBB> besides, since when do we care about the performance of apps that haven't recompiled against a new ffmpeg? [20:56:21] * elenril sends some spam [20:56:21] <BBB> I don't expect a ffmpeg of 2006 to perform as well as ffmpeg of 2011 [20:56:22] <BBB> right? [20:56:31] <BBB> please bump that thread [20:56:32] <BBB> :-p [20:56:36] <wbs> BBB: did you mean to push the udp multicast reuse patch? you can add a "Signed-off-by: Martin StorsjÃ¶ <martin(a)martin.st>" too, to that one [20:56:43] <elenril> BBB: he suggested having both [20:57:31] <elenril> i was hoping somebody who really understands how this binary stuff works would comment [20:59:04] <_av500_> kshishkov: nice [21:01:12] <kshishkov> _av500_: iKnow [21:44:10] * elenril sleep(8h); [21:44:33] <mru> EINTR [21:45:58] <elenril> i expect to see all the patches reviewed by tomorrow morning ;) [21:58:18] <Dark_Shikari> mru: av_clip_c isn't being inlined in vp8.c [21:58:24] <Dark_Shikari> can we just force-inline everything in avutil common.h? [22:08:08] <mru> probably [22:14:12] <mru> I'd do a quick sanity check though [22:23:09] <Dark_Shikari> av_always_inline doesn't seem to be defined in avutil [22:23:09] <Dark_Shikari> wtf? [22:23:25] <mru> attributes.h [22:25:38] <Dark_Shikari> oh, it isn't included in some places... [22:27:17] <therealgalen> i heard somebody was working on 10-bit h.264 playback... is this anything vaguely usable? is there a link to the patch? [22:27:18] <therealgalen> [22:28:27] <kierank> therealgalen: https://github.com/irock/FFmpeg [22:29:35] <mru> Dark_Shikari: common.h includes it [22:32:33] <therealgalen> kierank: any idea if it is vaguely usable? [22:33:02] <kierank> no idea [22:34:29] <Jumpyshoes> define usable [22:39:10] <Dark_Shikari> Jumpyshoes: you need to help him on it! [22:40:05] <Jumpyshoes> i'm not sure what else he needs to do... seeing as he fixed the issue he mentioned before [22:45:14] <j-b> http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-cho… <= notice that ffplay got one vote :D [22:52:20] <Tjoppen> vote ffplay up! :) [23:07:24] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r569ff02168 ffmpeg/libavformat/asfdec.c: [23:07:24] <CIA-38> ffmpeg: asfdec: remove some write-only values from the context [23:07:24] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com>

1 0

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

09 Feb '11

[00:10:13] * lu_zero is eventually back [00:10:35] <mru> wb [00:10:46] <lu_zero> did I miss anything? [00:10:56] <mru> only gabu [00:11:08] <Sean_McG> killed the channel dead :| [00:11:33] <mru> he is a bit toxic [00:11:48] <jannau> at least he admits it [00:12:09] <lu_zero> interesting [00:12:29] <lu_zero> btw good news, I still have 3 months of applecare! [00:12:45] * lu_zero tomorrow will have his laptop sent to repair... [00:12:58] <Sean_McG> lu_zero: what happened? [00:13:08] <mru> it turned into cider [00:13:16] <Sean_McG> oh, lovely [00:13:19] <lu_zero> Sean_McG: no clue at all [00:13:31] <mru> indeed, a miracle [00:13:37] <ohsix> just didn't power on one day? [00:14:04] <lu_zero> basically we went having dinner and once in the room it couldn't boot anymore... [00:14:13] <Sean_McG> my MBP seems OK... wish it was one of the Nehalem ones though [00:14:40] <Sean_McG> I might get one of the Nehalem iMacs when this kicks the bucket [00:14:44] <Sean_McG> spendy though [00:14:48] <ohsix> Sean_McG: the cpu is socketed :D [00:15:10] <Sean_McG> this is a 2008 15" C2D 2.4 [00:15:20] <Sean_McG> wow, alphabet soup [00:15:50] <iive> lu_zero: it doesn't show any post or just can't boot from disk? [00:16:44] <ohsix> dead, usually [00:17:29] <ohsix> they service it as a "logic board" problem, but the efi update process they use can brick it in some cases [00:18:28] <ohsix> (to update the bios w/system updates they put it in the efi system partition then bless it; interrupting it in any phase after that is big trouble) [01:19:54] <BBB> astrange: split is fine [01:20:03] <BBB> astrange: but the non-vp3 parts werent' posted yet ;) [01:20:08] <BBB> astrange: also, I don't care about whitespace [01:20:15] <BBB> astrange: 80% performance improvement!!! :-p [01:20:18] <BBB> astrange: anyway [01:20:30] <BBB> astrange: point was, are you OK with me committing the threading framework, patch 2/6? [01:20:33] <Dark_Shikari> oh yeah, is someone with bigendian support ever going to bench my patch? [01:20:35] <Dark_Shikari> or should I just commit? [01:20:37] <BBB> astrange: or do you want ot do more work? [01:20:44] <BBB> Dark_Shikari: just commit if nobody did it [01:20:52] <BBB> Dark_Shikari: I tried, that's all I could do :-p if it sucks, their own fault [01:21:22] <Dark_Shikari> could you bench it? [01:21:35] <Dark_Shikari> BBB: ETA for Sandy Bridge is march btw [01:22:34] <BBB> do I get one for free in my new, free laptop? [01:22:44] <Compn> someone giving away laptops? :P [01:23:17] <Compn> i'm actually kinda surprised no hardware guys have tried to bribe ffmpeg project with free swag [01:23:27] <Compn> i guess maybe some companies have given away stuff at conferences [01:23:34] * Compn wonders what went on at the webm-summit [01:24:21] <kierank> Compn: don't understand why they can't live stream it [01:27:34] <astrange> BBB: updated 2/6, and 3-6/6, are fine by me [01:28:21] <BBB> I already applied 3-4/6 [01:28:25] <BBB> I believe [01:28:38] <BBB> the vp3 table init -> new func and simplification something ones [01:28:43] <BBB> they were rather simple [01:28:46] <astrange> looks like it [01:29:10] <astrange> outstanding ones are mt, deprecate avcodec_thread_init, vp3 [01:31:18] <astrange> er, don't apply the second one [01:32:07] <astrange> it removes avcodec_thread_free() entirely, because i found no callers of it outside lavc (using google code search) [01:32:17] <astrange> but this might be one http://google.com/codesearch/p?hl=en#uIdZ2LsHk6E/trunk/libraries/FFMpeg/src… [01:32:59] <astrange> i'll send an updated version. it's not important for anything anyway [01:33:57] <ohsix> astrange: ooh good idea with google code search [01:34:10] <ohsix> need to remember that :] [01:41:12] <BBB> astrange: send new set and I'll apply all, has been out for review long enough; how long until you'll send the h264/h263 ones? [01:54:14] <astrange> RFC rsn, appliable after i finish debugging it [01:55:52] * Orphis hates debugging bash and make files [01:56:13] <Orphis> It's blocking on fate-vsynth1-error [01:56:53] <Orphis> Is there a way to run only this test through the makefile ? [01:57:02] <BBB> make fate-vsynth1-error [01:57:13] <astrange> with V=1 to show the command you want [02:03:18] <Orphis> That's way better to debug :p [02:04:14] <Orphis> I see the problem, alright [02:09:33] <mru> "No trolls were harmed in the making of this movie." [02:10:24] <Orphis> I see the problem in the command line, now I have to find where it is called... [02:10:48] <mru> what's the problem? [02:11:47] <Orphis> "/cygdrive/d/Programming/ffmpeg"/tests/fate-run.sh fate-vsynth1-error "/home/fate/samples" "" "/cygdrive/d/Programming/ffmpeg" 'codectest vsynth1' '' '' '' [02:11:47] <Orphis> /cygdrive/d/Programming/ffmpeg/ffmpeg -v 0 -y -flags +bitexact -dct fastint -idct simple -sws_flags +accurate_rnd+bitexact -qscale 7 -flags +mv4+part+aic -mbd rd -ps 250 -error 10 -f image2 -vcodec pgmyuv -i /cygdrive/d/Programming/ffmpeg/tests/vsynth1/%02d.pgm -an -vcodec mpeg4 /cygdrive/d/Programming/ffmpeg/./tests/data/vsynth1/error-mpeg4-adv.avi [02:12:06] <mru> and what is the problem? [02:12:19] <Orphis> It's calling ffmpeg (that doesn't understand cygwin paths) with a cygwin path [02:12:42] <Orphis> /cygdrive/d/Programming/ffmpeg [02:12:54] <mru> bad mix of cygwin and non-cygwin parts [02:13:05] <Orphis> I know [02:13:42] <Orphis> I could make some tests to run with : make fate TARGET_PATH=`cygpath -am .` [02:15:37] <Orphis> Oh no, I forgot to run the test with the TARGET_PATH [02:15:57] <Orphis> Then it runs the following line that looks correct : D:/Programming/ffmpeg/ffmpeg -v 0 -y -flags +bitexact -dct fastint -idct simple -sws_flags +accurate_rnd+bitexact -qscale 7 -flags +mv4+part+aic -mbd rd -ps 250 -error 10 -f image2 -vcodec pgmyuv -i D:/Programming/ffmpeg/tests/vsynth1/%02d.pgm -an -vcodec mpeg4 D:/Programming/ffmpeg/./tests/data/vsynth1/error-mpeg4-adv.avi [02:16:02] <astrange> resent [02:20:07] <BBB> ty [02:38:03] <bcoudurier> astrange, what's the reason to extend AVCodec instead of putting the functions in AVCodecContext ? [02:41:02] <astrange> they're codec specific [02:41:16] <astrange> but not more specific than that [02:46:41] <Orphis> The problem seems to come from the glob [06:46:58] <elenril> morning [06:52:18] <_av500_> +1 [06:53:51] <Sean_McG> +/- inf [06:55:20] <saintdev> -0 [07:06:22] <ggergely> hello [07:24:54] <KotH> salut [07:25:10] <spaam> good morning :) [07:26:56] <benoit-> good morning [07:27:05] <elenril> :/ exactly what i expected [07:27:16] * benoit- too [07:28:01] <elenril> how about people stop feeding them? [07:30:52] <benoit-> elenril: it seems people cannot do that, I was told yesterday [07:37:11] <peloverde> I don't see what the harm in banning them is. It's not like they intend to contribute. [07:39:02] <ggergely> welcome to the world of FREE software. ban everyone. for FREEDOM :) [07:39:26] * elenril troll detected [07:39:35] <ggergely> yeah. [07:40:03] <peloverde> anyone is welcome to use the software for any purpose [07:40:33] <ggergely> homoz detected. but put my natural disgust for them aside, i want to see what will come out of the whole coup soap-opera. and i have heard that this new fron t has also been opened [07:41:09] <elenril> :( [07:41:23] <elenril> i always wanted to ban somebody [07:41:29] <peloverde> homophobic language is not cool, this isn't xbox live [07:41:42] <ggergely> yeah. you have to love everyone [07:43:22] * bilboed-tp found it sad not all parties were at fosdem despite being invited/sponsored :( [07:44:06] <ggergely> criticizsmpfobic language, calling everyone trolls is also not welcome. in the name of freedom :) actually on irc i can understand, but on a mailing list. it is extremely funny. to censor a mailing list. as we could just learn on the Egyptian example: censoring will not work [07:44:51] <ggergely> mostly in case if the one being censored has right point, apart from the style [07:44:59] <ggergely> *points [07:45:24] * elenril yawns [07:45:44] <elenril> i've seen better trolls [07:45:49] <elenril> go do something useful [07:45:52] <ggergely> sure. [07:45:55] <ggergely> i'm doing [07:46:04] <ggergely> you are only for my entertainment meanwhile [07:47:01] <cartman> moin [07:47:17] <Sho_> pretty broad ban mask there, remember to remove that at some point [07:47:29] <KotH> hoi cartman [07:47:47] <KotH> Sho_: we're generally annoyed by the behavoir of hungarian people [07:48:13] <cartman> and the Hungarian coding style too [07:48:25] <KotH> Sho_: considering how many of them have anything constructive to say, it's a wonder that .hu isn't already banned completely [07:49:07] <Sho_> KotH: per-ISP bans just rub me the wrong way considering I couldn't access the ffmpeg SVN repo for months from Arcor/Vodafone due to something similar ;) [07:49:24] <KotH> Sho_: i'm sorry for that, but it was necessary [07:49:43] <Sho_> it's alright, there ware useful git mirrors around .. [07:49:54] <KotH> Sho_: the alternative would have been shuting down mphq completely because we would have been kicked out from our current hoster [07:52:17] <peloverde> If someone wants to unban him or do a narrower ban go for it, i'm not really an IRC expert, just sick of him [07:54:24] * elenril kicks his isp [08:05:12] <Dark_Shikari> Oh wow, this is brilliant. [08:05:14] <Dark_Shikari> http://www.ykombinator.com/ [08:05:19] <Dark_Shikari> Random startup generator. [08:05:37] <Dark_Shikari> The funniest part is that it could _completely_ fool many of the web 2.0 people. [08:07:15] <peloverde> I feel like some of the web 2.0 startups these days are the pets.com of this bubble [08:07:48] <Dark_Shikari> I don't think any are quite the same. [08:07:53] <Dark_Shikari> We seem to have two categories this time: [08:08:04] <Tjoppen> the scroll-down spoiller ruins it a bit though [08:08:07] <Dark_Shikari> 1) Large-scale things that *make mone*, but people put way too much stock into. [08:08:11] <Dark_Shikari> *money [08:08:15] <Dark_Shikari> for example, Groupon [08:08:26] <Dark_Shikari> 2) Smaller-scale things that are just pants-on-head retarded. [08:08:39] <elenril> like playing video games over the network [08:08:58] <Dark_Shikari> Yeah, what a dumb idea that one is. [08:09:36] <Dark_Shikari> I think this is better than the 2005-ish bubble though, because that one was all about startups with no business model at all. [08:09:45] <Dark_Shikari> At least this time they're trying. Somewhat. [08:09:52] <peloverde> I don't quite get quora [08:10:01] <Dark_Shikari> isn't quora just a stackoverflow knockoff thing? [08:11:07] <peloverde> quora seems to be trying to carve out of the same space as stack*, expersexchange, and yahoo answers [08:11:44] <Dark_Shikari> Also, the top comment on HN about this site: [08:11:46] <Dark_Shikari> " [08:11:47] <Dark_Shikari> I propose the ycombinator turing test. Can you generate an application which will get accepted by ycombinator? This may require generating additional content to establish team credibility including twitter posts, blog posts, etc. [08:11:52] <Dark_Shikari> " [08:12:14] <Dark_Shikari> i.e. can someone get a randomly-generated startup accepted by VCs. [08:17:35] <peloverde> I constantly read about the tech pundits talking about quora but I don't know anyone who actually uses quora [08:17:58] <Dark_Shikari> Replace Quora with anything in that sentence. [08:18:03] <Dark_Shikari> Bubble 3.0 described in one sentence. [08:18:55] <peloverde> I think twitter and groupon are overhyped but i know people that use the services [08:18:58] <votz> Dark_Shikari: reminds me of http://itsthisforthat.com/, which I think we lol'd at before when it came out last year [08:19:38] <peloverde> It seems like everyone is jumping on the quora bandwagon because the guy behind it was CTO of facebook and they are scared of missing the next-big-thing [08:21:06] <Tjoppen> votz: awesome [08:21:59] <votz> Tjoppen: haha ya, some of the generated ideas are just brilliant [08:22:25] <Tjoppen> I got "CPA ad network for Erlang enthusiasts", but then I reaslized that anything aimed solely at them would be hilarious [08:22:35] <votz> lol [08:22:44] <peloverde> "Flickr for adult dancers" actually sounds like a good idea [08:23:08] <votz> That's the genius of it [08:59:11] <av500> Dark_Shikari: "i.e. can someone get a randomly-generated startup accepted by VCs." [08:59:20] <av500> Dark_Shikari: if you manage that, you have generated a startup [09:00:10] <Dark_Shikari> av500: of course, a randomly-generated startup is still a startup. [09:01:24] <peloverde> http://www.xkcd.com/810/ [09:03:47] <DonDiego> peloverde: inspired by hungarian trolls? :) [09:04:18] <peloverde> That was when I originally thought of it [09:04:41] <peloverde> but I think it also applies to the random startup generator or the random IEEE paper generator [09:05:33] <av500> random generator, then peer review, then feed that back into the generator :) [09:05:39] <av500> iterate [09:05:47] <j-b> 'moroning [09:06:08] <av500> j-b: how was the döner? [09:06:32] <cartman> köfte! [09:06:57] * kshishkov would like start up PDP-10 but he doesn't have any [09:10:05] * cartman finally FATEs again [09:13:13] <spaam> cartman: yoyoy [09:13:23] <spaam> cartman: they fixed the bug ;D [09:13:54] <cartman> yes, with my cool bisect & reduce skillz [09:13:59] <cartman> I sent them teh codez [09:14:30] <merbzt> when remuxing h264 in mov the payload is changed slightly for some reason what could be the problem ? [09:14:46] <spaam> cartman: zomg .. _awesome_ [09:14:51] <Dark_Shikari> Remuxing in mov -> You mean 「mov -> mov」? [09:16:37] <merbzt> mov->mov [09:16:47] <cartman> mov eax,eax [09:17:06] <Dark_Shikari> Have you tried doing 「mov -> mov -> h264」and comparing to 「mov -> h264」? [09:17:36] <Dark_Shikari> You might also want to try demuxing with something else and comparing. [09:17:40] <Dark_Shikari> Such as gpac. [09:17:41] <merbzt> hmm, think I found the issue [09:18:44] <av500> cartman: here: http://www.flickr.com/photos/av500/5427778410/ [09:19:00] <cartman> av500: \o/ [09:19:12] <cartman> absolutely Turkish [09:19:13] <cartman> awesome [09:20:20] <spaam> av500: what is that? [09:20:33] <cartman> spaam: "Urfa" as we call it [09:20:34] <cartman> yummy [09:23:16] <kshishkov> spaam: looks like a thing people invent när de har ingen riktiga köttbullar med potatismos [09:23:42] <spaam> kshishkov: verkar som så :) [09:37:51] * pross-au is in floating point hell [09:38:29] <cartman> I bet its hard [09:38:53] <merbzt> pross-au: is it x87 floating point ? [09:40:20] <pross-au> Yaaa [09:41:07] <kshishkov> as in "here is some Bink IDCT asm with x87 instructions" hell? [09:41:09] <pross-au> i want to retain bit-exactness on x86 [09:41:20] <pross-au> kshishkov: Yes [09:41:53] <Dark_Shikari> Bink itself doesn't have an SSE one that's auto-loaded based on CPU capabilities? [09:42:18] <Dark_Shikari> I don't think bit-exactness for idcts is that critical when the difference is going to be in the 10th decimal of rounding error. [09:42:54] <Dark_Shikari> For MPEG-2 it's a significant issue because the error is in the ~16th decimal point (measured in binary) [09:43:05] <Dark_Shikari> But with "double", the error will be something like the 40th or 50th. [09:43:21] <kshishkov> so it drifts [09:43:32] <Dark_Shikari> The drift should be basically minimal unless Bink doesn't have keyframes. [09:43:36] <kshishkov> and is that bitexact IDCT standardised yet? [09:43:48] <pross-au> Dark_Shikari: bink doesnt have keyframes [09:44:00] <Dark_Shikari> What do we do for Bink IDCT currently? [09:44:07] <kshishkov> new Bink uses integer IDCT anyway [09:44:21] <kshishkov> but version b had floating-point IDCT [09:44:51] <Dark_Shikari> Suggestion: write x87 softfloat lib for libavutil. Use this for Lagarith (replace current code). [09:45:08] <Dark_Shikari> On actual x86, write an asm version of the idct that's bit-exact. Use this when available. [09:45:13] <pross-au> man that sounds fun [09:45:15] <Dark_Shikari> On non-x86, call the x87 softfloat lib if +bitexact is enabled. [09:45:33] <Dark_Shikari> Or maybe if it's not, because of the drift issue. [09:45:37] <kshishkov> Dark_Shikari: okay, libavemu is on you [09:45:42] <Dark_Shikari> I don't think it's very difficult if you only do arithmetic. [09:45:51] <Dark_Shikari> It would be much more difficult if you did transcendental functions. [09:46:01] <Dark_Shikari> But I don't think an iDCT uses sqrt, sin, pow, exp, cos, etc. [09:46:12] <Dark_Shikari> Lagarith already has at least one op implemented for you to start with. [09:49:58] * elenril wonders how much is microsoft's asf specs licence valid in eu [09:56:45] <peloverde> USAC is getting a new (M)PS? decorator, just what I needed [09:56:56] <peloverde> I really hope USAC does not take off [10:00:40] <kshishkov> what does that mean? That future audio working draft now has some parametric stereo shit? [10:08:32] <peloverde> it means that it has a new implementation of the same parametric stereo shit [10:08:42] <peloverde> easier to implement but harder to reuse [10:10:50] * kshishkov dislikes word "parametric" when applied to audio [10:11:42] <peloverde> I prefer the name "placebo stereo" [10:12:10] <kshishkov> SOAL [10:12:14] <Dark_Shikari> peloverde: An interesting note is that, IIRC, listening tests showed that PS didn't help perceptual quality. [10:12:23] <Dark_Shikari> And sometimes even hurt. [10:12:29] <kshishkov> *SAOL [10:12:34] <Dark_Shikari> (Unlike SBR, which helped greatly.) [10:12:50] <kshishkov> Dark_Shikari: who cares, it's patents we're talking about [10:13:04] <peloverde> do you mean listening tests of real encoders or of the reference encoder? [10:13:09] <Dark_Shikari> Real encoders. [10:13:22] <superdump> and at what bitrates? [10:13:33] <Dark_Shikari> The bitrates that HE-AACv2 was supposed to do well at (e.g. 16-32kbps). [10:13:40] <peloverde> see that's the problem, the listening test that mpeg uses are based on the reference encoder which had super shitty LC but reasonable SBR and PS [10:13:52] <Dark_Shikari> We were discussing this in #celt a while back -- they encountered the same problem when working on CELT. [10:13:59] <Dark_Shikari> That is, really *terrible* emulated stereo is worse than mono. [10:14:16] <Dark_Shikari> If you don't have a sufficient amount of stereo information, it's actually counterproductive. [10:15:53] <Dark_Shikari> (Note: this might not be true in the general case. It is of course possible that someone simply hasn't discovered a very good way of doing it.) [10:16:30] <Dark_Shikari> It could be exacerbated by the fact that mid/side coding is not a very good way of representing stereo differences due to issues such as time delays. [10:17:34] <peloverde> Do you have any reasonably sized, non-ABX perceptual tests you can link? [10:18:29] <Dark_Shikari> I'll ask the CELT guys for the link, I don't think I have it anymore. [10:19:41] <Dark_Shikari> http://www.mp3-tech.org/tests/aac_48/results.html I think this is it? [10:20:15] <Dark_Shikari> http://www.mp3-tech.org/tests/aac_48/plot_overall_zoomed.png [10:20:25] <peloverde> That's ABX [10:20:34] <Dark_Shikari> What's the problem with AVX? [10:20:35] <Dark_Shikari> er, ABX? [10:20:40] <Dark_Shikari> Aren't basically all tests done as ABX? [10:20:51] <peloverde> that's also at the top of the PS range [10:20:54] <Dark_Shikari> True. [10:21:12] <peloverde> there is a certain point where quality is so distorted that no one is going to confuse it with the original [10:21:30] <Dark_Shikari> I don't think the purpose of the test is to see whether people can tell it apart from the original. [10:21:45] <Dark_Shikari> I can see your point if you're worried about "If you don't have the context of the original, the results might change." [10:22:33] <peloverde> "The ABX mode is meant to allow the listener to identify subtle differences between any two samples. Typically, one of the samples will be the original file. One of the samples is assigned to be 'A' and the other is assigned to be 'B'. Either sample A or Sample B is randomly assigned to be 'X'. The listener must determine whether X is the same as A or B. By performing this test multiple times, the listener can show with a speci [10:22:34] <peloverde> fied level of confidence that his results are not by chance alone." [10:22:53] <Dark_Shikari> That's not what that test is. [10:23:01] <Dark_Shikari> The listeners were told to rate them from 1 to 5. [10:25:28] <peloverde> ok [10:25:38] <Dark_Shikari> I agree that 48kbps is a bit high for v2. [10:26:15] <merbzt> ok, there is a regression or bug in the mov stream remux for h264 [10:26:19] <peloverde> indeed: http://ctaacplus.com/products/aacPlus.htm [10:26:23] <bgmarete> Hello. A fix for https://roundup.ffmpeg.org/issue481 would also fix a bug in which one cannot use .sdp file to to access a stream that another app on the local machine is also accessing -- One cannot pass reuse=1 to an SDP url. Can anyone help? [10:26:51] <peloverde> 48 is where CT claims V1 reaches parity with V2, V2 is "supposed to" win below [10:26:56] <wbs> bgmarete: I posted a polished up patch for that yesterday evening [10:26:57] <merbzt> bgmarete: talk to luca and wbs about that [10:27:03] <Dark_Shikari> The test suggests that v2 still loses to v1 at 48kbps. [10:27:27] <bgmarete> wbs: Thanks a lot. Will check the mailing list. merbzt: Much obliged. [10:27:56] <peloverde> which really isn't surprising if you allocate 10% to marketing hype [10:27:58] <merbzt> bgmarete: luca -> lu_zero [10:28:08] <Dark_Shikari> peloverde: True indeed~ [10:28:26] <bgmarete> merbzt: Thanks. [10:29:00] <peloverde> Now 24 kpbs is where the two curves really separate according to CT so that would be a slightly more interesting test to see if PS is at all useful [10:30:38] <peloverde> Still in general i don't think PS is worth the hassle, at 24k both signals were substantially degraded [10:30:59] <Dark_Shikari> I think someone needs to come up with a stereo coding method better than mid/side. [10:31:04] <Dark_Shikari> For example, something that codes delays for each band. [10:31:44] <peloverde> Dark_Shikari: that's actually more-or-less what PS is based on [10:31:56] <Dark_Shikari> Ah, interesting. [10:32:06] <Dark_Shikari> But what about using it for _normal_ stereo coding? [10:32:11] <Dark_Shikari> i.e. with the intent of being near-transparent? [10:32:18] <Dark_Shikari> instead of just using it to emulate stereo with few bits. [10:32:19] <peloverde> of course PS has a fixed band-delay curve, and allocates very few bits to describing anything [10:32:21] <peloverde> indeed [10:32:39] <peloverde> It might be interesting, but I imagine CT probably already tried that [10:32:41] <Dark_Shikari> CELT can't do this because its frame sizes are too small for the overhead to be worth it, iirc. [10:32:47] <Dark_Shikari> So they haven't investigated it. [10:33:09] <peloverde> seeing as they pretty much had a solution looking for a problem [10:36:23] <peloverde> I think something that attempts to integrate with the core-coder's TF model may have more luck [10:43:44] <Flameeyes> mru: okay I've got the tinderbox working again, will rebuild all ffmpeg deps in a bit [11:14:20] <Dark_Shikari> peloverde: interesting comment. [11:14:21] <Dark_Shikari> 22:13 < jmspeex> What I suspect is that v2 may not sound *that* bad with speakers instead of headphones [11:15:04] <kshishkov> especially with shitty speakers and Gduim audio output device [11:17:43] <merbzt> k, I found the code that messes up mov->mov remux [11:18:10] <av500> <drumroll> [11:18:12] <merbzt> if (enc->codec_id == CODEC_ID_H264) size = ff_avc_parse_nal_units(pb, pkt->data, pkt->size); [11:18:50] <cartman> and? [11:18:50] <merbzt> how do I detect when the stream is already from a proper container ? [11:19:32] <av500> so h264 can be both raw and in NALs? [11:19:54] <Dark_Shikari> It's always in NALs. [11:20:12] <lu_zero> av500: that reminds me [11:20:19] <av500> lu_zero: yeah [11:20:53] * lu_zero will have to bring his laptop to the store at 1.40pm [11:21:09] <kshishkov> lu_zero: use your sister's ;) [11:21:29] <lu_zero> kshishkov: she doesn't have a laptop yet [11:21:41] <lu_zero> and right now I'm using the efikasb [11:21:42] <cartman> buy one [11:21:55] <kshishkov> lu_zero: that's what you showed to me. [11:22:06] <kshishkov> lu_zero: it has display, keyboard and portable [11:22:18] <lu_zero> works almost fine even if I should update the software to the latest [11:23:13] <kshishkov> to the latest Gentoo? [11:24:12] <merbzt> http://git.ffmpeg.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=0949d29… [11:25:13] <merbzt> that parsing messes up the stream when I remux mov->mov [11:25:35] <lu_zero> kshishkov: latest sources for x11 [11:26:46] <av500> lu_zero: I fail to install the efika here [11:26:52] <lu_zero> merbzt: that code shouldn't be there... [11:26:56] <lu_zero> how so? [11:26:57] <av500> the ubuntu image starts but then looses display [11:27:20] <lu_zero> which kernel does it sport? [11:27:58] <lu_zero> it is a to2 device so it has a number of glitches [11:28:21] * lu_zero thought you were just collecting it [11:28:30] <av500> :) [11:28:38] <av500> lu_zero: no idea [11:28:52] <av500> i followed the instructions, upgrade uboot and then maverick [11:29:11] <av500> ubu boots and as soon as it asks me for language, the display is off ... [11:29:17] <lu_zero> =| [11:29:21] <kshishkov> lu_zero: how do you distinguish them? [11:29:32] <lu_zero> kshishkov: different labelling [11:30:10] <kshishkov> lu_zero: without disassembly. I got two and one had only half disk space. Also it required upgrading OS. [11:30:23] <lu_zero> check the back [11:30:28] * av500 glares at lu_zero [11:30:41] <lu_zero> av500: ^^? [11:30:54] <av500> for givin me broken stuffz [11:31:14] <lu_zero> av500: it was among the rarest item [11:31:26] <lu_zero> s/broken/quirky/ [11:31:36] <av500> lu_zero: well, got more [11:31:39] <av500> get more [11:31:41] <av500> get working ones [11:31:49] <lu_zero> =P [11:31:52] <kshishkov> lu_zero: mine has serial 09BPEX213828 [11:32:06] <lu_zero> this summer will do ^^ [11:32:22] <av500> lu_zero: what is your connection to efika? [11:32:47] <lu_zero> I hack on it and I know the people from Genesi since ages [11:32:55] <av500> ic [11:33:30] <av500> why does it come up in 1280x800 and not 1280x720? [11:35:05] <lu_zero> interesting question, which monitor are you using? [11:35:11] <lu_zero> hdmi or dvi? [11:36:27] <av500> er [11:36:30] <av500> both [11:36:35] <av500> let me try the other one [11:36:44] <Flameeyes> lu_zero: was it in warranty then? [11:37:44] <av500> lu_zero: ah, its 720 on the hdmi input [11:38:24] <lu_zero> Flameeyes: yup [11:38:31] <Flameeyes> lu_zero: poor support centre [11:38:49] <lu_zero> Flameeyes: why? [11:39:00] <Flameeyes> you abuse them! :P [11:39:27] <lu_zero> Flameeyes: apparently there were already a recall regarding the nvidia chip that I somehow missed [11:39:27] <av500> lu_zero: same thing, as soon as i click on the lang selection, it goes boom [11:39:49] <Flameeyes> lu_zero: ... you got the faulty nvidia laptop and _never got it replaced_? [11:40:15] <lu_zero> av500: makes no sense, it should have issue only with neon [11:40:23] <kshishkov> Flameeyes: "faulty", "nvidia" <- I smell redundancy here [11:40:49] <lu_zero> Flameeyes: it should had been the other times and/or I did not have the issue [11:40:50] <Flameeyes> I'm surprised it lasted this long, two friends of mine had the same issue and it was dead on its step after no longer than an year and a half [11:42:02] <Flameeyes> uhm I think I need to make sure my VMs are updated.. I had Ubuntu 9.10 still =_= [11:42:47] <spaam> what software do you use for VM stuff? kvm? virtualbox? [11:42:53] <spaam> other? [11:42:56] <Flameeyes> libvirt&&kvm [11:43:19] <Flameeyes> but only for unices.. Windows it's on Parallels [11:44:02] <spaam> ok :) [11:44:43] <av500> lu_zero: ah, its only the display that goes away, unplug and replug of hdmi "fixes" it.... [11:44:44] <Flameeyes> and of course it's always a question of whether kvm decides to boot up a given non-Linux target or not [11:45:01] <Flameeyes> so latest version works fine with Solaris... but fails with FreeBSD [11:45:04] <lu_zero> av500: ahh... [11:45:10] <spaam> Flameeyes: =/ [11:45:13] <lu_zero> which display is it? [11:45:22] <av500> some samsung 1080p monitor [11:45:27] <av500> it might be picky.... [11:45:33] <av500> will connect something else [11:45:51] <lu_zero> av500: I have one as well [11:45:54] <Flameeyes> spaam: the solution would probably be asking the qemu/kvm maintainers to ensure we have the latest version/patchset... [11:45:57] * Flameeyes looks at lu_zero [11:46:09] <lu_zero> the latest kernel should fix it [11:46:47] <Flameeyes> lu_zero: define "latest" [11:46:47] <lu_zero> Flameeyes: let me first fix evas, get the desktop working, sort out what to do with timeshift and get my laptop repaired [11:47:12] <lu_zero> Flameeyes: latest -> latest kernel fixes the av500 issue with samsung monitors... [11:47:14] <Flameeyes> lu_zero: I'd change the priority of desktop and evas [11:47:25] <Flameeyes> ah okay for a moment I thought you were telling me to update for kvm :P [11:47:36] <lu_zero> Flameeyes: evas is part of getting the desktop working... [11:47:41] <Flameeyes> [which was possible given I got "not implemented" dmesg when starting Solaris] [11:48:17] * thresh had a lot of fun with kvm-based "enterprise cloud solutions" [11:48:37] <thresh> xen, otoh, is even worse [11:48:47] <thresh> worse as in enteprisy [11:49:15] <Flameeyes> thresh: don't get me started, I have had to work with ec2 [11:49:51] <av500> lu_zero: I connected a LG 720p tv, no signal at all :( [11:49:57] <thresh> Flameeyes: ehehe me too [11:50:30] <thresh> the worst thing ever is Ubuntu Cloud, though [11:50:38] <kshishkov> av500: worked fine with DVI for me [11:50:43] <thresh> 'bringing the enterprise solutions to cooks' [11:50:51] <kshishkov> thresh: nope, Russian NanoCloud [11:50:54] <av500> kshishkov: what res? [11:51:11] <kshishkov> av500: 1280xsomething [11:51:19] <av500> kshishkov: ok, lets try that [11:52:05] <kshishkov> av500: I think it was 1280x720 [11:52:25] <thresh> kshishkov: ну, учитывая что НацОС будет делаться из ALT Linux, не всё так плохо -- могло быть и хуже [11:53:02] <kshishkov> thresh: например, ОС вооруженных сил [11:53:46] <lu_zero> av500: I'd say outdated kernel... [11:55:46] <av500> lu_zero: /me too [11:55:49] <wbs> jannau: care to queue/push the libavfilter movie video source filter? from the "[PATCH] movie video source" thread, ok'd by michael on february 1st [11:55:58] <av500> now i got it running 1280x958.... [11:57:30] <kshishkov> av500: maybe you should try different display [11:57:34] <lu_zero> how O_o? [11:57:35] <av500> kshishkov: i did [11:57:52] <av500> and now i get 1280x958 [11:57:56] <jannau> wbs: which patch? stefano's comment in the ping mail is confusing [11:58:05] <av500> on a 1680x1050 monitor [11:58:17] <kshishkov> av500: I got 1280x720 on my 1920x1200 monitor [11:58:17] <av500> lu_zero: is there a newer ubu kernel? [11:58:45] <av500> kshishkov: yes, I get that too, it just loses picture every 10s [11:59:36] <pross-au> 'x = a + b; y = x + c' != 'y = (a + b) + c' [11:59:57] <wbs> jannau: probably one of the patches from 30th january, and the confusing comment probably concerns updating minor numbers and such, depending on what base repo it is applied on... [12:00:37] <kshishkov> pross-au: but it is in math and ~= in FPU calculations [12:01:08] <pross-au> im liking the idea of libavfpu [12:01:16] <av500> lu_zero: this stock ubu image, does it have 3d accel enabled? [12:01:22] <pross-au> av_pushf(1.2f); [12:01:23] <av500> coz the desktop is rather slow [12:01:34] <kshishkov> of course not [12:01:42] <kshishkov> you need stuff from BSP [12:02:10] <av500> kshishkov: hey, it feels like working with TI :) [12:02:24] <kshishkov> av500: ah, that homely feeling :) [12:03:47] <av500> yes [12:05:12] <kshishkov> that's why I'm going to finally install Gentoo on mine and enjoy the latest stuff Luca can provide [12:06:01] <jannau> wbs: queued [12:06:54] <av500> kshishkov: i will follow in your footsteps [12:07:29] <av500> lu_zero: and the 720p hw decoding is done how? [12:07:32] <wbs> jannau: \o/ [12:18:29] <lu_zero> av500: vpu/ipu [12:18:34] * lu_zero runs [12:18:57] <lu_zero> brb [12:24:43] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rf4acb837eb ffmpeg/doc/muxers.texi: [12:24:44] <CIA-38> ffmpeg: Document null muxer. [12:24:44] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [12:24:55] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r77d4ed7a12 ffmpeg/doc/muxers.texi: [12:24:55] <CIA-38> ffmpeg: Add documentation for the framecrc muxer. [12:24:55] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [12:24:58] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * ra4effe432f ffmpeg/doc/muxers.texi: [12:24:58] <CIA-38> ffmpeg: Add documentation for the crc muxer. [12:24:58] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [12:25:03] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r0cad24ce9b ffmpeg/doc/muxers.texi: [12:25:03] <CIA-38> ffmpeg: Apply misc fixes to the image2 muxer documentation. [12:25:03] <CIA-38> ffmpeg: The fixes were pointed out by Diego. [12:25:03] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [12:25:07] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r9409c3811c ffmpeg/ (6 files in 3 dirs): [12:25:07] <CIA-38> ffmpeg: libavfilter: add video movie source [12:25:07] <CIA-38> ffmpeg: See thread: [12:25:07] <CIA-38> ffmpeg: Subject: [PATCH] movie video source [12:25:08] <CIA-38> ffmpeg: Date: 2010-12-31 15:35:30 GMT [12:25:08] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [12:50:22] <wbs> jannau: thanks for merging that, that was a quite much requested feature (for overlaying watermarks and such) [12:50:40] <wbs> I worked on that in may 2009 sometime, it's nice to have it all merged into the normal repo now :-) [12:50:53] <mru> now we only need to add a logo removal filter and we'll be complete [12:51:54] * elenril wonders what mushrooms was the person who wrote asfdec smoking [12:52:08] <mru> microsoft ones? [12:52:36] <cartman> elenril: magical ones [12:53:07] <Flameeyes> okay the good thing is that at least Ubuntu detected the virtio disk this time [12:54:37] <Dark_Shikari> jannau: what do you mean by an "include/source command"? [12:57:21] <jannau> Dark_Shikari: source libx264-common-options.ffpreset instead of duplicating all common options in each preset [12:57:36] <Dark_Shikari> You can do that? [12:58:16] <jannau> not now and I'm not sure if implementing is worth it [12:58:37] <Dark_Shikari> k [12:58:54] <av500> elenril: why? [12:59:04] <Dark_Shikari> jannau: I think it turned out that patch was unnecessary btw [12:59:17] <spaam> av500: maybe he want some of it :) [12:59:21] <Dark_Shikari> int qp_max = h->param.rc.i_qp_max == QP_MAX_SPEC ? QP_MAX : h->param.rc.i_qp_max; [12:59:43] <Dark_Shikari> Or... hmm. that might not actually be doing what I thought it was doing. [12:59:48] * Dark_Shikari makes a TODO to investigate this. [12:59:58] <elenril> av500: just look at it [13:01:15] <av500> elenril: it goes back to mr bellard [13:01:35] <elenril> so i'm destroying a piece of history [13:02:02] <spaam> noooo :( [13:02:23] <kshishkov> well, Fabrice is not Michael Kalvachev [13:02:35] <spaam> who is that? [13:02:39] <cartman> lol [13:02:55] <elenril> lol [13:03:04] <kshishkov> spaam: certain Michael mutating into certain Kalvachev [13:03:17] <kshishkov> 1) useful contributions in the past - check [13:03:19] <elenril> kshishkov: your obscure references to obscure trolls are lost here [13:03:50] <spaam> kshishkov: ok [13:04:04] <kshishkov> 2) agressive reaction when someone touches their code (even for formatting) - check [13:04:26] <cartman> now look at that, http://web.archiveorange.com/archive/v/yR2T41Zix9x6zC4jCdX5 [13:04:59] <kshishkov> 3) defending each other - check [13:05:26] <av500> keeping kshishkov entertained on a slow day, priceless [13:05:57] <cartman> its not a slow day I finished all my Android work [13:06:00] <cartman> time to slack [13:06:01] <cartman> :p [13:07:04] <kshishkov> cartman: how do you manage to do work in that short break between slack allowed by Turkish law [13:07:19] <cartman> kshishkov: my magic fingers does it [13:07:40] <cartman> I got it all working on molasses slow ARMv5 [13:07:43] * kshishkov still has to publish a photo with ArchosNote and av500 magic fingers [13:08:59] <av500> kshishkov: please submit to censor 1st [13:09:05] <cartman> lol [13:10:31] <kshishkov> av500: don't worry, I'll censor it myself [13:15:15] * cartman notes that av500 has lots of circuit pr0n [13:32:02] <pJok> mru, what about an ffmpeg-drama mailing list? [13:38:57] <cartman> pJok: ffmpeg-kindergarden [13:43:25] <bgmarete> Hello. I am receiving an H.264 RTP stream with the data encoded in Annex B Byte Stream, but I am stumbling on: http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/117195 every time. What is the recommended work-around? Is the attached patch okay? I noticed that there were some objections to it when it was proposed. Thanks! [13:44:27] <pJok> cartman, or that [13:45:07] <kshishkov> pJok: there's only one proper name for such channel [13:45:55] <cartman> bgmarete: looks like you'll have to fix the muxer instead [13:47:00] <kierank> cartman: you mean the demuxer [13:47:07] <cartman> kierank: yes [13:47:12] <bgmarete> cartman: Isn't that what that patch does? [13:47:24] <cartman> bgmarete: no idea, I am just replaying bcoudurier :P [13:47:43] <bgmarete> Ah, I see. Any hints? I am happy to do that since I have got to get this working :) [13:48:04] <cartman> bgmarete: he is the TS maintainer afaik, you could send an email to that thread or start a new one [13:48:16] <cartman> kierank will help you too [13:48:25] <wbs> btw, nice with the gmane page above, it only specifies month and date, but not which year... [13:48:29] <kierank> cartman: I will? [13:48:39] <cartman> kierank: you should :P [13:48:51] * kierank knows nothing about rtp [13:49:05] <av500> kierank: time to learn! [13:49:25] <bgmarete> cartman: Thanks. So bcoudurier then? [13:49:26] <kierank> av500: I would but the rtp spec uses a font i don't like [13:49:41] <wbs> that one doesn't have anything to do with rtp. if streamcopying h264 where 3-byte startcodes are used into the mpegts muxer, it doesn work, since it expects 4-byte startcodes [13:49:42] <av500> kierank: nice one, noted :) [13:49:55] <cartman> bgmarete: no try ffmpeg-devel, say this fixes a bug etc. Look for comments, fix the patch & submit :) [13:50:07] <wbs> the patch looks sane to me, but I'm not familiar with h264 in detail [13:50:20] <cartman> see wbs will help [13:50:59] <bgmarete> wbs, cartman: Thanks. I will test patch and reply to that thread if it works. Many thanks. [13:51:38] <bgmarete> wbs: BTW, the patch re: SO_REUSEADDR works fine here. Will also note that on mailing list on relevant thread. Thanks! [13:51:50] <wbs> bgmarete: good :-) [13:59:25] <Tjoppen> is there a way for a demuxer to signal lavfi to do cropping? [14:02:26] <Tjoppen> I remember it being discussed for mov.c, but I don't see anything in the code about it [14:05:40] <ruggles> Tjoppen: i don't think so. maybe something could be implement using AVPanScan or even just metadata? other filter / transformation hints would be useful too though. [14:07:02] <Tjoppen> the archives have baptiste taking a shot at it using metadata [14:07:39] <ruggles> maybe bcoudurier implemented it in ffmbc? [14:10:12] <Tjoppen> using AVPanScan sounds like a decent solution, however there doesn't seem to be any way to pass such information from demuxer to decoder atm [14:11:12] <Tjoppen> for now I think I'll just hack a bit since the only thing I need to do is crop VBI lines from raw video [14:11:20] * av500 wonders if we will one day transport video in metadata [14:11:34] <cartman> in elenril's dreams [14:13:15] * elenril stabs cartman [14:13:19] * elenril also stabs microsoft [14:13:37] * cartman is unstabbable [14:13:41] <elenril> wtf is this mirror-endian notation [14:14:01] <av500> where? [14:14:11] <av500> asf [14:14:15] <elenril> 30 26 b2 75 8e 66 cf 11 a6 d9 00 aa 00 62 ce 6c [14:14:19] <elenril> this is hexdump [14:14:39] <elenril> 75B22630-668E-11CF-A6D9-00AA0062CE6C [14:14:44] <av500> ah [14:14:45] <elenril> this is microsoft specs [14:14:48] <av500> GUID [14:14:51] <av500> yes, its crazy [14:15:07] <av500> I copy pasted all my GUIDs from hexdump [14:15:33] <wbs> oh, lovely [14:15:36] <kierank> cartman: wearing a stab proof vest? [14:15:42] <cartman> kierank: always [14:15:45] <av500> couldnt be bothered to learn how the mirroring works [14:15:51] <wbs> wtf does one have to interpret guids as a bunch of separate values when it just could be a byte array? ;P [14:15:51] <cartman> you never know when an ambush is coming up [14:16:23] <cartman> wbs: errr you'll need those to look up registry and such [14:16:28] <cartman> you need the representation [14:16:43] <wbs> cartman: yes, but why did they have to be designed that way in the first place? [14:16:54] <cartman> wbs: that you ask to Raymond Chen [14:17:09] <av500> the new old thing [14:17:12] <cartman> right [14:17:23] <wbs> 128 bit, interpreted as 32 bit little endian, 16 bit LE, 16 bit LE, 64 bit as 8 consecutive bytes [14:17:29] <wbs> instead of just 16 consecutive bytes [14:17:43] <j-b> wbs: because they have a patent on it? [14:17:49] <wbs> j-b: obviously [14:17:50] <cartman> remember DOS compatibility and such :P [14:18:03] <av500> dos could support 16 consecutive bytes? [14:18:16] <cartman> apparently not :P [14:18:41] * cartman notes that Windows has 2 notepad.exe for compatibility [14:18:45] <cartman> since they lack symlinks [14:19:09] * lu_zero notes that windows has symlinks but the aren't used [14:19:16] <cartman> only NTFS [14:19:25] <lu_zero> cartman: yup [14:19:39] <cartman> most of the world is still FAT16/32 [14:25:45] <kierank> gah aac specs have to use a different profile/level identifier and mp4 and ts for no reason [14:34:29] <mru> lu_zero: windows has symlinks? [14:34:37] <elenril> yes [14:34:41] <mru> ntfs has hardlinks but not easy way to create them [14:34:42] <elenril> since ntfs iirc [14:34:55] <mru> I never saw a true symlink on windows [14:35:04] <mru> only the ones cygwin emulates [14:35:04] <Flameeyes> junctions [14:35:18] <Flameeyes> junctions cross filesystem boundaries [14:35:26] <Flameeyes> so they are in all effects symlinks [14:35:30] <DonDiego> i remember installing a windows nt resource kit to have a tool for creating such links [14:35:40] <Flameeyes> only works since nt5 though [14:35:40] <kierank> iirc the x264 buildscript make cygwin create a file called "NUL" that's a nightmare to remove [14:35:50] <mru> windows makes everything so convoluted [14:36:17] <mru> kierank: heh, those magic names are fun [14:38:20] <kierank> also means you can't delete the directory [14:39:07] <kurosu> funny as the '-rf' file, too (in a college humor kind) [14:40:24] <TheFluff> 15:34:55 <@mru> I never saw a true symlink on windows <--- I don't know the definition of a "true" symlink but they do exist on vista+ and are created with the mklink commandline tool [14:40:41] * mru hasn't used vista or win7 [14:40:42] <Compn> winnt has them too [14:40:45] <Compn> win2k/xp [14:40:51] <merbzt> I used it on xp [14:40:54] <TheFluff> which annoyingly a) takes its arguments in reverse order compared to ln(1) and b) requires admin privileges by default [14:40:55] <j-b> TheFluff: aren't those hardlinks? [14:40:56] <merbzt> flaky at best [14:40:59] <KotH> TheFluff: links on windows are of the kind of short scripts [14:41:18] <KotH> TheFluff: horribly complex and prone to fail if anything unexpected happens [14:41:21] <mru> cygwin uses .lnk "shortcuts" for symlink emulation [14:41:24] <TheFluff> j-b: no [14:41:31] <TheFluff> you can create hard links with mklink too [14:41:39] <TheFluff> but by default it creates soft ones [14:41:42] <KotH> TheFluff: while symlinks on unix are just a special file type that contains a path as data [14:41:52] <j-b> TheFluff: winsxs are hardlinks though, right? [14:42:00] <Compn> there is 'junction' tool too [14:42:04] <Compn> but what it does i have no idea :) [14:42:12] <TheFluff> I dunno about that, I try to avoid winsxs [14:42:44] <TheFluff> Compn: NTFS junctions support only absolute paths on local paths [14:43:08] <TheFluff> s/local paths/local disks/ [14:43:26] <Compn> hokay [14:43:42] <TheFluff> other than that I don't know the technical difference either :V [14:44:42] <TheFluff> oh and apparently junctions can only link to directories too [14:45:27] <mru> so it's more like a linux bind mount [14:45:29] <TheFluff> most tools seem to treat junction points as hardlinks too [14:45:34] <TheFluff> yeah [14:45:45] <TheFluff> actually that's a better analogy than a hard link [14:46:57] <TheFluff> junctions seem to have a lot of potential for Surprise and Confusion [14:47:31] <TheFluff> for example if you put a junction point in the recycle bin with explorer, the folder it points to will look normal, but when you empty the recycle bin it's deleted [14:49:41] <JEEB> yah [14:50:00] <mru> now that sounds like fun [14:50:26] <JEEB> Yah, it's the reason why I use msys' /etc/fstab to switch around mingw packages instead of "just using junction" [14:58:56] <pJok> ntfs supports symlinks... shame there is no tools for it though [14:59:22] <pJok> but many tools that dedupe on ntfs just hardlink files [14:59:46] <mru> filesystem support isn't everything [15:00:00] <pJok> the os supports them too [15:00:05] <mru> how do standard tools and syscalls deal with them? [15:00:10] <pJok> but as i said, lack of tools for actually creating them... [15:00:32] <mru> many 'open file' dialogs fail miserably on certain perfectly valid constructs [15:00:49] <mru> like creating a non-alphabetic "drive" [15:00:57] <pJok> well [15:01:04] <pJok> drive letters under windows is really just a relic [15:01:12] <pJok> behind the scenes, its block devices like everything else [15:01:12] <mru> yet they are there [15:01:26] <pJok> for historic and compatibility reasons, i guess [15:01:48] <mru> and pretty much any printable ascii character except \ and : are valid drive designators [15:02:01] * mru has fooled around with subst too much [15:02:39] <mru> I've seen other instances too where apps try to be clever and validate filenames [15:02:46] <mru> with much too strict rules [15:02:57] <TheFluff> 16:00:05 <@mru> how do standard tools and syscalls deal with them? <--- if you use the syscalls, msdn claims they should treat it just like a normal file [15:17:44] <wbs> always wonderful with bounties on resolving completely bogus bug reports [15:18:10] <mru> mark it closed/invalid and collect :) [15:18:14] <wbs> lol [15:18:43] <av500> so ffmpeg is a flash player now [15:20:08] <kshishkov> av500: didn't you know that? [15:20:37] <kshishkov> av500: otherwise why I've tried to add RTMP support as well? [15:47:18] <uau> libavcodec/audioconvert.c uses AV_SAMPLE_FMT_NB which is defined libavcore [15:47:42] <uau> that's very likely to break if library majors are changed [15:50:44] <siretart> uau: I'm working on a patch to merge libavutil and libavcore [15:50:59] <siretart> that should solve this issue [15:51:29] <uau> solve? how so? i don't see how that'd be of any help if libavutil and libavcodec are still separate [15:51:55] <av500> merge != separate [15:52:00] <av500> no? [15:52:17] <siretart> I guess I misunderstood the issue uau's pointing out [15:52:36] <uau> av500: merge *libavutil and libavcore*, *libavutil and libcodec* separate [15:52:56] <av500> uau: my bad :) [15:53:00] <mru> merging libavutil and libavcore has no impact on libavcodec [15:53:17] <mru> both are separate from lavc both before and after [15:53:22] <lu_zero> and that should happen on the major bump [15:53:37] <av500> libavcore/samplefmt.h:34: AV_SAMPLE_FMT_NB ///< Number of sample formats. DO NOT USE if dynamically linking to libavcore [15:53:45] <av500> libavcodec/audioconvert.c:99: ctx->fmt_pair = out_fmt + AV_SAMPLE_FMT_NB*in_fmt; [15:53:56] <mru> yes, that's a problem [15:54:05] <av500> so one cannot dynlink codec to util/core [15:54:19] <lu_zero> btw with siretart we discussed a bit about keep an uniform version [15:54:21] <mru> it's a problem now, and it will remain after the merge [15:54:35] <mru> it has nothing to do with the merge [15:54:44] <av500> mru: yes, I understand that :) [15:55:24] <av500> lu_zero: and the outcome? [15:56:46] <uau> btw the reason i noticed that was that i want to support versions without AV_ versions of SAMPLE_FMT_foo in mplayer2 (those AV_ versions were only added 3 months ago) [15:57:34] <uau> however there doesn't seem to be a particularly nice way to do that - the version that added them only bumped avcore version, so if that gets removed any tests against avcore version would fail (unless there will be a compatibility define for those?) [15:57:52] <uau> testing some other lib version could work in practice but be kind of ugly [15:58:09] <uau> i guess the best practical choice is to just use the deprecated SAMPLE_FMT_FOO [15:59:18] <lu_zero> av500: we went over thinking about grouping changes so the version number won't go up that much [16:00:05] <lu_zero> (e.g. minor bump at earliest every week grouping all the changes happened during that week) [16:00:23] <uau> lu_zero: what benefit would that have? [16:00:29] <av500> lu_zero: so version is lib.year.week :) [16:00:52] <av500> make it lib.year.month.day :) [16:00:56] <lu_zero> uau: just reduce the bumps [16:01:01] <lu_zero> drop lib [16:01:14] <lu_zero> since the version would be the same for all the libs [16:01:15] <uau> well what benefit would reducing the bumps of minor version have? [16:01:20] <av500> lu_zero: thats what I meant [16:02:04] <lu_zero> uau: for us just having to prepare the abichanges once per week instead of twice per day [16:02:06] <av500> lu_zero: benefit is that you can use the revlog as calender, weekends are easy to spot :) [16:02:24] <uau> "prepare the abichanges"? [16:02:32] <uau> what do you mean by that? [16:02:40] <lu_zero> uau: the api changes document [16:02:47] <lu_zero> (and the abi changes as well) [16:03:15] <lu_zero> it started with the idea of keeping only a single version number across the ffmpeg libraries [16:03:29] <uau> i don't really see the benefit here... [16:03:29] <lu_zero> (iirc you were one of the ones proposing it) [16:04:06] <uau> so you mean that as a way to have a single version? [16:04:33] <uau> i don't see how delaying the update of the abi changes document would help [16:04:45] <av500> lu_zero: if we have many changes, it means the project is doing well, why not expose that :) [16:05:19] <lu_zero> uau: the question that came up is that we already have a quick increase of the version numbers [16:05:45] <av500> lu_zero: call it "build" :) [16:05:45] <lu_zero> so just grouping the changes would make the numbers grow slowly [16:06:03] <uau> lu_zero: yes, but what's the problem with them growing quickly? [16:06:08] <av500> +1 [16:06:11] <av500> let em grow [16:07:30] <lu_zero> just slightly more work [16:12:54] <jannau> most annoying are conflicts in patches both increasing minor [16:14:58] <av500> increasing minor should be automatic from the commit msg: ".... MINOR_BUMP..." :) [16:15:06] <lu_zero> jannau: that's why I'd rather have the commits marked with tags and autogenerate it [16:15:07] <av500> post commit hook does it then :) [16:15:15] <lu_zero> av500: better using tags [16:15:19] <lu_zero> but you got the idea [16:15:23] <av500> :) [16:16:23] <Loco89> Hey [16:16:31] <kshishkov> hey what? [16:16:38] <kierank> hey jude [16:16:39] <mru> hey ho [16:16:52] <Loco89> Any Girls from Germany here..? [16:17:27] <mru> wtf [16:17:56] <spaam> Loretta: asl? [16:17:56] <kshishkov> probably he realised how stupid his question was [16:18:05] <spaam> :( [16:18:36] <av500> kshishkov: no, it was from iphone and had no multitasking [16:19:16] <kierankette> :/ [16:19:41] <kshishkov> spaam: should be kieranketteCDGS [16:20:49] <kierank> spaam: the correct name is kiera [16:21:00] <kierank> i mean keira [16:21:11] <spaam> keiraCDGS [16:21:17] <kshishkov> kierank: nobodyCares^TM [16:21:27] <spaam> kshishkov: we need avseq.. [16:33:43] <av500> hmm, this mp3 bitstream parser is wierd [16:34:42] <av500> in a valid mp3 file, it manages to output 3265 bytes of non mp3 frames [16:43:51] <Orphis> Yay, lots of fate tests are now running on Win 64 :) [16:44:58] <Orphis> And some aren't still running because of one common problem I guess [16:52:53] <lu_zero> great [16:53:24] <av500> Orphis: thanks!!! [17:41:08] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * r440b61691d ffmpeg/libavcodec/ (avcodec.h h264.c): [17:41:08] <CIA-38> ffmpeg: h264: define FF_PROFILE_H264_HIGH_444 to the correct value [17:41:08] <CIA-38> ffmpeg: It was removed in fe9a3fb since it had the wrong value. Add profile name [17:41:08] <CIA-38> ffmpeg: for it. [17:41:20] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * r7ab8758baf ffmpeg/doc/APIchanges: add APIChanges entry for fe9a3fb [17:50:18] <CIA-38> ffmpeg: Stefan Kost <ensonic(a)users.sf.net> master * rae2104791f ffmpeg/libavcodec/ (mpeg4videodec.c vc1.c): [17:50:18] <CIA-38> ffmpeg: logging: downgrade recoverable errors to warnings [17:50:18] <CIA-38> ffmpeg: In all 3 cases, the decoding continues and thus a warning would be sufficient. [17:50:18] <CIA-38> ffmpeg: Helps application that catch them with own log handers to handle them [17:50:18] <CIA-38> ffmpeg: accordingly. [17:50:18] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:56:42] <lu_zero> mmu: I watched some haiku in action at the fosdem, looks really great =) [17:56:53] <mmu> cool [17:56:58] <lu_zero> (and we found other ffmpeg-haiku users!) [17:57:09] <mmu> really ? :p [17:57:10] <mru> s/users/user/ [17:57:16] <mmu> LOL [17:57:29] * mmu throws a Haiku CD over mru [17:57:48] * mru uses it as a beer coaster [17:57:53] <mmu> ok do I have enough disk space for FATE... [17:58:05] <mmu> 1.1G [17:58:25] <lu_zero> =) [17:58:42] <mru> you need some working space too [17:59:05] <mru> I'd set aside 1GB to be on the safe side [17:59:08] <mmu> yeah, plus it's the disk with all the sources on ... [17:59:14] <mru> not sure exactly how much is needed [18:01:44] <Orphis> For those who care : http://orphis.free.fr/fate.out [18:02:13] <Orphis> It's the output of make fate V=1 on Win64 [18:02:29] * kierank considers the building of networking on mingw magic [18:02:53] <Orphis> It's not perfect yet, some tests can't be run, but some other run and show interesting results [18:02:55] <mru> Orphis: that would be easier to read w/o V=1 [18:04:01] <Orphis> Use some grep voodoo then ;) [18:04:12] <mru> Orphis: for every failed test there is a foo.err file saved somewhere under tests/ [18:04:13] <mmu> need to do some more cleanup I suppose [18:04:24] <mmu> hmm did I ever touch these elinks sources anyway [18:04:45] <Orphis> Except the err file doesn't have the command line in it [18:05:25] <Orphis> I found it easier for me to find the common points between the failing command lines this way [18:05:53] <mru> just saying in case you hadn't noticed them [18:06:06] <mru> they occasionally contain useful diagnostics [18:06:16] <Orphis> I've seen a few yes [18:07:18] <Orphis> BBB have access to the computer, so he'll be able to make a cleaner output if you want [18:08:50] <Orphis> I'm going out now, I'll continue to debug this later [18:49:34] <elenril> anyone can comment on lavf renaming patches please? [18:58:50] <Compn> hmm, any tips for getting a usable license plate out of this security footage? http://dl.dropbox.com/u/17424360/camera1-20110203173710%5B1%5D.avi [18:58:57] <Compn> h264 even :P [18:59:13] <Compn> from 00:25 to 00:40 the car reverses [18:59:23] <Compn> jams the plate right up to the screen [18:59:48] <elenril> enhance() [19:00:47] <Compn> of course, why didnt i think of it [19:01:18] <Compn> more talking h264 deblocking filter, uspp, etc [19:02:00] <mru> http://www.youtube.com/watch?v=KUFkb0d1kbU [19:07:01] <Compn> so gigo then [19:08:03] <Compn> lol [19:08:26] <iive> Compn: to me it looks like the plate is in arabic. [19:09:35] * elenril wonders if the person writing asf specs ever heard of this thing called 'consistency' [19:10:40] <Compn> iive : well thanks for looking at it :) [19:11:21] <elenril> how nice of them to first store size in 64 bits, then store the same size - small constant in 32 bits [19:11:40] <iive> Compn: is that original footage? there seems too much aliasing and flickering, like it have been deinterlaced with tfields. [19:12:21] <iive> dropping one field. [19:12:25] <Compn> its from a dvr, the source was unclear how he grabbed it from there [19:20:05] <iive> Compn: what kind of combinations are there, aka how many symbols, letter, numbers, at what possition. [19:22:05] <Compn> one sec i'll find ref [19:22:31] <Compn> http://www.aaroads.com/license_plates/images/wa-337-kyj.jpg [19:23:25] <Compn> hopefully like that iive [19:24:33] <iive> my second guess was something like ?CD 26?, but that looks backwards... [19:26:29] <Compn> my guess was omd 287 [19:26:32] <Compn> ehe [19:26:48] <Compn> i'll ask the guy if he has a better quality video [19:26:56] <iive> ??2 -???" [19:33:43] * Compn goes afk [19:34:10] <BBB> drv: hah you are on IRC (you're daniel right?) - so will you try to set up a fate box? [19:50:35] <mmu_man> hmm didn't we have a FATE tutorial ? [19:50:45] <mmu_man> I recall seeing the insn somewhere [19:50:54] <mmu_man> on the ml ? [19:52:40] <mmu_man> ah doc/build_system.txt :)) [19:56:20] <mmu_man> ah that's the one I was seeking http://wiki.multimedia.cx/index.php?title=Running_FATE [20:07:38] <Kovensky> mmu_man: it needs to be updated for git =p [20:07:46] <Kovensky> also, several of the variables should be commented out or filled with the defaults [20:07:55] <Kovensky> if you forget to fill in anything, the build WILL fail [20:08:29] <mru> already updated for git [20:09:09] <Kovensky> I see, it wasn't a few days ago :> [20:12:08] <elenril> does anybody mind if i download all the asf samples at high speed? [20:12:10] <mmu> mru do I have to set up this config file the wiki talks about ? [20:12:14] <elenril> KotH: ^ [20:12:21] <mmu> hmm rsync could be more verbose about how much it does [20:12:34] <mru> rsync --progress is [20:13:52] <mmu> yeah but I don't care how much it does of each file [20:14:00] <mmu> just want to know the ETA [20:14:07] <mmu> oh well [20:14:09] <mmu> let it run [20:14:36] <mru> ETA: later [20:14:45] <mmu> :) [20:15:07] <kierank> same as the eta for BeOS to become a real os ;) [20:16:59] <mru> elenril: I think you can go ahead and grab the asf samples if you need them [20:17:10] <mmu> !kick kierank [20:17:32] <kierank> ENOTIMPLEMENTED [20:17:51] <mmu> BeOS was a real OS way before Linux even could play a video [20:22:04] <thresh> yeah so why bother now [20:22:18] <mmu> because Haiku is out there [20:22:37] * thresh sends H1N1 to Haiku [20:24:50] <mmu> are you sponsored by M$ like FOSDEM thresh ? [20:26:15] <mmu> ok 403MB for fate data [20:26:46] <mru> sounds about right [20:27:43] <mmu> just need to finish the build on this box [20:28:15] <thresh> mmu: I wish I was! [20:28:22] <mmu> bleh [20:28:43] * mmu installs Windows Vista on all thresh's computers [20:29:12] * Kovensky gives mmu a windows me disc [20:29:28] <mmu> aw, won't even touch it [20:29:32] <Kovensky> now, where was that microsoft bob disc... [20:29:43] <_av500_> thresh: u better now? [20:31:17] <thresh> _av500_: feeling tired and sleepy for a couple of days, looks like almost ok now [20:31:55] <thresh> no stupid swine flu could kill vodka drinkers [20:32:58] <_av500_> right [20:33:38] <mru> thresh: the swine flu doesn't kill the swine, so you're safe [20:35:12] <wbs> re dropping libavcore - strictly speaking, it's breaking ABI comparing to earlier svn/git versions, but combined with a major bump would probably be ABI-safe [20:35:40] <wbs> and that of course depends if ABI compatibility with svn/git versions is desired or ignored [20:36:28] <vipw> wbs: ever heard of oipf HTTP Adaptive streaming? [20:36:32] <elenril> well we _are_ claiming that git master is stable [20:36:35] <mru> we're breaking compatibility with lots of things anyway [20:36:51] <mru> elenril: git master is stable most of the time [20:37:13] <elenril> but if it's to be merged, than the bump must be immediately before or after [20:37:37] <mru> it'll be in close proximity [20:38:04] <wbs> vipw: hmmm, don't remember all the names, is that microsoft's or adobe's abomination? [20:38:21] <vipw> it looks a lot like apple's HLS, but with multiple bitrates [20:38:32] <wbs> apple's HLS supports multiple bitrates, too [20:38:46] <vipw> i honestly can't tell who is behind it, i see samsung pushing it for on their tvs [20:38:58] <vipw> http://www.oipf.tv/specifications.html [20:39:00] <wbs> both microsoft and adobe built similar-looking variants, but based on xml instead of m3u playlists, and on mp4 fragment files instead of mpeg2ts [20:40:14] <vipw> this is xml playlist and has either mp4 or mpeg2ts [20:40:30] <wbs> uh, weird, is it yet another variant of the same thing? sigh [20:40:49] <wbs> looks like some 3gpp spec (some of the xml namespaces point in that direction at least) [20:44:51] <mmu> Run the fate test suite, note you must have installed it [20:45:02] <mmu> ^^ note it doesn't say a word about how to install it [20:46:17] <mmu> ld: cannot find -lm [20:46:23] <mmu> bleh [20:47:06] <mmu> HOSTLIBS=-lm [20:47:18] <mmu> ^^ where does this crap come from ? there is libm in Haiku [20:47:23] <mru> configure [20:47:52] <mru> fix whatever you need in the haiku section of configure [20:47:55] <mru> send a patch [20:47:58] <mru> we'll apply [20:48:29] <mmu_man> hmm it only has -lm by default but what if it gets another stuff, will need to filter it out [20:48:41] <mmu_man> actually all platforms using it should add it for themselves [20:48:52] <mru> the majority needs it [20:48:59] <mru> easier to clear it for those that don't [20:49:02] <mmu_man> the majority is not always right [20:49:06] <mmu_man> ask Windows users [20:49:27] <mru> just add host_libs= to the haiku section and stop complaining [20:50:14] <mmu_man> why couldn't I do both adding it and still complaining ? :D [20:51:37] <mmu_man> why does ff* not use host_libs for linking ?? [20:52:22] <mmu_man> or rather, why does configure test for it but it's still hardcoded elsewhere [20:52:36] <mru> host != target [20:52:59] <mmu_man> well the test would only work when host == target anyway [20:53:08] <mru> the test is for the target [20:53:13] <mru> and uses the target cc [20:53:17] <mmu_man> hmm right [20:53:23] <mru> trust me, it works [20:53:32] <mmu_man> best would be to test for the host one too, but I'm too lazy [20:53:37] <Dark_Shikari> mru: while you're banning people on the ML, how about we ban the anti-GPL troll from ffmpeg-users? [20:53:38] <mru> the host settings could use some more detection though [20:53:53] <mru> Dark_Shikari: I'm not on -users [20:54:04] <mru> I can still ban trolls of course [20:54:17] <mru> but I won't notice them [20:54:43] <Dark_Shikari> This one is a guy who's been around for months posting to every single thread that's remotely legalities-related about how evil the GPL is [20:54:47] <Dark_Shikari> and how we're out to screw everyone [20:54:48] <elenril> hah, phil rhodes again? [20:54:50] <Dark_Shikari> yes [20:55:06] <Kovensky> hfuy? [20:55:15] <elenril> yeah [20:55:21] <Dark_Shikari> phil rhodes yes [20:55:30] * Kovensky doesn't like the GPL either but doesn't hate on people using it [20:55:41] <Dark_Shikari> Oh he's anti-LGPL too. [20:55:48] <Dark_Shikari> In fact I'm pretty sure if ffmpeg went BSD, he'd be anti-BSD. [20:56:13] <Kovensky> I just hate on people that are fanatic about it like libsamplerate's author which forbid anyone from making a foobar2000 plugin because it'd be a "pluging for an evil non-GPL program and since you're using GPL code foobar2000 would have to be GPLed too" [20:56:30] <mru> for some people being anti is more important than what they are against [20:56:40] <Kovensky> in fact a plugin was made but he forced it to be discontinued [20:57:05] <elenril> Kovensky: well...foobar _is_ an evil non-gpl closed proprietary evil program =p [20:57:19] <mru> perhaps, but that's irrelevant [20:58:13] <Dark_Shikari> Let's not flame over this and get the troll banned instead. [20:58:28] * Kovensky usually licenses his stuff under ISC [20:59:27] <Kovensky> btw, the code I wrote for x264 has to be in that GPL-proprietary dual-license, right? since it includes x264cli.h which is under that license [20:59:47] <Dark_Shikari> If you want to get it committed, it does. [21:00:00] <Dark_Shikari> However, x264 is available under two licenses, so for now it's just GPL. [21:00:08] <elenril> Kovensky actually writes patches? wow [21:00:10] * elenril ducks [21:00:15] <Dark_Shikari> No, he just pretends to. [21:01:16] <Kovensky> well, it's written, kinda, just needs polish and finishing ._. [21:01:32] <Kovensky> I need to get someone to review it so I know what to do next and then sit and actually do it [21:01:38] <Dark_Shikari> "It needs finishing" doesn't sound very promising. [21:02:03] <Kovensky> "finishing" because I'm also counting the DSP filters as part of it, if you don't count then yes it just needs final touches [21:02:40] <Dark_Shikari> On an unrelated note, http://whartoniteseekscodemonkey.tumblr.com/ [21:02:55] <KotH> elenril: tell me your ip and use rsync [21:03:04] <BBB> Dark_Shikari: please review my win64 emu_edge patch [21:03:07] <elenril> KotH: too late :) [21:03:55] <bcoudurier> closed = evil [21:04:17] <bcoudurier> foobar2k = closed, foobar2k = evil [21:04:24] <elenril> \o/ [21:04:32] <mmu_man> bleh, of course there is no man in Haiku so git fails to display the help [21:04:33] <mmu_man> stupid [21:04:59] <Kovensky> no man? lol [21:04:59] <saintdev> -h will just print usage [21:05:22] * Kovensky never remembers the -h and uses --usage [21:05:32] <Kovensky> while not actually a flag to display usage, it works because it's not a valid flag in any command [21:05:38] * saintdev just uses --help because his OS has man [21:05:49] * Kovensky doesn't always want to see the full manpage [21:05:56] <mmu_man> hmm it fails anyway, seems it misses some non portable perl module [21:06:13] <Kovensky> you mean a perl module that isn't in haiku's default install [21:06:15] <Kovensky> lrn2cpan [21:06:54] * mru runs fate on qnx with no git [21:07:13] <mmu_man> won't work anyway for sending... [21:07:22] * mmu_man slaps mru [21:07:29] <mmu_man> you "only" need to port git :D [21:08:01] <BBB> Daty [21:08:01] <mru> I run a separate cron job on a linux machine updating the git tree which the qnx machine then accesses over nfs [21:08:02] <BBB> oops [21:08:05] <BBB> tab completion sucks [21:08:07] <BBB> Dark_Shikari: ty [21:08:24] <CIA-38> ffmpeg: Reinhard Tartler <siretart(a)tauware.de> master * r87800dc2bf ffmpeg/doc/ (TODO developer.texi optimization.txt soc.txt): [21:08:24] <CIA-38> ffmpeg: Documentation updates for the git migration [21:08:24] <CIA-38> ffmpeg: This cleanup patch updates the developer documentation with respect to [21:08:24] <CIA-38> ffmpeg: the migration to the git scm. [21:08:48] <BBB> did astrange say I could push -mt patch 2/6? [21:08:51] <BBB> he did right? [21:09:16] <siretart> BBB: do you consider the -mt patch ready for 0.7? [21:10:01] <mmu_man> sent [21:11:21] <mmu_man> do I need to use tests/fate.sh or make fate ?? [21:11:58] <mru> fate.sh is for fully automated checkout/test/report [21:12:09] <mru> make fate just runs the tests [21:12:12] <mmu_man> looked like [21:12:18] <BBB> siretart: yes [21:12:23] <BBB> siretart: it passes make fate [21:12:29] <BBB> siretart: I don't know what else it should do [21:12:32] <BBB> look pretty? [21:12:38] <BBB> speedy code always looks pretty [21:14:08] <siretart> BBB: I'm only concerned about regressions in the various codecs. but I have no reason to not trust your confidence in it! [21:14:21] <BBB> it should work [21:14:23] <BBB> I think it's fine [21:14:42] <mru> I want it to work, therefor it must work [21:14:44] <Dark_Shikari> make sure fate is modified to test threading [21:14:45] <mru> </religion> [21:15:09] <mru> Dark_Shikari: sure [21:16:23] <CIA-38> ffmpeg: François Revol <revol(a)free.fr> master * rf59c4bd625 ffmpeg/configure: [21:16:23] <CIA-38> ffmpeg: Fix HOSTLIBS on Haiku [21:16:23] <CIA-38> ffmpeg: Haiku does not have a separate libm, so do not try to link to it. [21:16:23] <CIA-38> ffmpeg: Signed-off-by: François Revol <revol(a)free.fr> [21:16:23] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:17:43] <mru> mmu_man: see how easy it is to simply send a patch and have it applied [21:19:18] <mmu_man> mru: when the committers don't make it a <religion /> to reject things for no reason :D [21:19:39] <mru> I've always given a reason for rejecting things [21:19:50] <mmu_man> s/no /no valid / [21:20:22] <mmu> TEST vsynth2-mpeg1b [21:20:23] <mmu> ... [21:20:43] <mmu> (how many years does it run ? :p) [21:20:59] <elenril> mru: naively rewriting ff_guidcmp as a macro breaks thigs like [21:21:00] <elenril> !ff_guidcmp(g, /* DSATTRIB_CAPTURE_STREAMTIME */ (const ff_asf_guid){0x14,0x56,0x1A,0x0C,0xCD,0x30,0x40,0x4F,0xBC,0xBF,0xD0,0x3E,0x52,0x30,0x62,0x07}) [21:21:13] <elenril> in wtv.x [21:21:16] <elenril> s/x/c [21:21:21] <mru> elenril: how so? [21:21:23] <wbs> Anssi: btw, you did the patches for showing h264 profile info in the normal startup info, right? I love it :-) [21:21:33] <elenril> clang says libavformat/wtv.c:886:87: error: too many arguments provided to function-like macro invocation [21:22:54] <mru> mmu: make fate takes about 20s here [21:23:47] <mmu_man> hmm ? [21:24:00] <mru> make -j8 fate on i7 cpu [21:24:02] <mmu_man> I know it's just an AthlonXP but... [21:24:27] <mru> expect at least 10m there [21:25:19] * mmu_man multithreads mru and knits a nice pullover with him [21:26:07] <mmu> anyway, need to eat now, let it run [21:27:06] <mmu_man> don't we have a fate config template in git ? [21:27:23] <uau> mru: surrounding braces don't prevent breaking things into separate arguments in a macro like parentheses do [21:27:54] <mru> uau: I realised that as I hit enter [21:28:40] <mru> anyhow, the callers could have more () added, or it could be made an inline function [21:29:24] <elenril> or somebody could eliminate those inline abominations from wtv.c [21:29:45] <mru> or that [21:29:47] <elenril> ...later [21:41:20] <DonDiego> gnite [21:41:30] <_av500_> elenril: nice asf work [21:41:40] <_av500_> you even moved my 20 lines :) [21:41:44] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * r6bd69e6ada ffmpeg/libavformat/oggdec.c: (log message trimmed) [21:41:44] <CIA-38> ffmpeg: oggdec: Fix incorrect assumption about header/data interleaving [21:41:44] <CIA-38> ffmpeg: Currently (since the data_offset fix) the ogg demuxer assumes that [21:41:44] <CIA-38> ffmpeg: after the first non-header packets in any stream no more header packets [21:41:44] <CIA-38> ffmpeg: will follow. [21:41:45] <CIA-38> ffmpeg: This is not guaranteed, so change the code back again to wait until it [21:41:46] <CIA-38> ffmpeg: has finished the headers for all streams before returning from ogg_get_headers. [21:42:13] <elenril> _av500_: i'm whoring git blame points ;) [21:42:49] <elenril> now your 20 lines are MINE. bwahahaha [21:43:20] <jannau> even with --find-copies-harder? [21:44:22] * elenril casts Greater Silence on jannau [21:48:02] <mmu> cross_prefix= ?? how can it test for crossbuilds ?? or does it just test the buidl itself ? [21:48:16] <mmu> (hmm I suppose one could actually use qemu-user-* though :) [21:48:30] <mru> ssh [21:48:53] <mmu> ah, like you cheating with QNX ? :p [21:49:04] <mru> the qnx is a native build actually [21:49:22] <mru> but all the arm, mips etc are cross-builds [21:50:25] <mmu> ok [21:50:32] <mmu> didn't try with qemu ? :D [21:50:39] <mmu> ok make fate ran ok [21:50:43] <mmu> let's try the script [21:50:50] <mru> qemu is useless for validation purposes [21:50:56] <mru> much too buggy [21:52:30] <roxfan> arm has a new thing called ds-5, which has a simulator [21:52:38] <elenril> mru: http://pastebin.com/bMA7cmeZ like this? [21:52:48] <Flameeyes> mru: running the gentoo tinderbox through ffmpeg dependencies, finally [21:55:08] <mmu_man> mru: you can send patches [21:58:38] <mru> roxfan: your point? [21:59:10] <michaelni> BBB, mru, i just wanted to make it clear that you guys cant kick me out of every position and then ask me to reconcile. I was trying to find a compromise with you and reconcile but you just without the slightest reason kicked me out of the ML admin position [21:59:15] <roxfan> well, you could try it instead of qemu i guess [21:59:28] <petrvlasic> Hello. Probably, I found a bug in ffserver. But I'm not sure if it relates directly ffmpeg or if have to annoy someone else on live555 forum/irc. [21:59:38] <mru> roxfan: real hardware is still faster and more correct [21:59:51] <BBB> michaelni: i have no idea what you're talking about, seriously [21:59:52] <mru> and even if buggy, it's still the real thing [22:00:07] <michaelni> BBB, iam no longer ffmpeg-devel ML admin i was before [22:00:19] <BBB> i didn't change anything [22:00:22] <BBB> i don't even know how to [22:00:30] <michaelni> BBB ok, so who did it? [22:00:39] <michaelni> and why? [22:00:56] * BBB doesn't know [22:03:19] <mmu> mru you've got my ssh pubkey already ? [22:03:23] <michaelni> mru? your name is on the ML admin list now and i dont think it was before so who and why did remove me? [22:04:08] <mru> my name is there because benoit- thought it should be since I was anyone doing most of the moderating [22:04:12] <mru> anyway [22:04:34] <michaelni> ok, so why have i been removed? [22:05:04] <mru> one good reason would be to stop you unblocking gabu [22:05:29] <michaelni> mru, you might not belive me but i would not have unblocked gabu [22:05:37] <Dark_Shikari> btw, mru, if you're doing ip range blocks, have you considered whitelisting people who should have access but are in those ranges? [22:05:41] <Dark_Shikari> e.g. arpi [22:05:44] <michaelni> i would have unblocked arpi but he wasnt baned [22:06:01] <Dark_Shikari> This would probably be useful in general, I think we had range blocks beforehand too? [22:06:01] <bcoudurier> well taking over ml admin is one thing, but not mailing the password to the others is another [22:06:04] <mru> Dark_Shikari: arpi should not have access [22:06:10] <Dark_Shikari> he isn't trolling, iirc? [22:06:12] <mru> he helps gabu bypass the blocks [22:06:14] <bcoudurier> mru, why didn't you send the new password to the others ? [22:06:16] <Dark_Shikari> ah. [22:06:22] <mmu> aw, politics [22:06:25] * mmu hides away [22:06:26] <Dark_Shikari> then unfortunately he's shot himself in the foot. [22:06:29] <Dark_Shikari> sucks, he's a good guy. [22:06:36] <mru> bcoudurier: I thought mailman did that automatically [22:06:57] <mru> I've certainly seen it do so in the past [22:06:59] <mru> maybe it changed [22:07:38] <mmu> install: missing file operand [22:07:38] <mmu> Try `install --help' for more information. [22:07:47] <bcoudurier> I didn't receive anything [22:08:23] <bcoudurier> mailman sending clear text password in mails like this ? [22:08:27] <bcoudurier> this is fucked up anyway [22:08:40] <mru> it is [22:08:51] <j-b> mailman is broken beyond fixable [22:08:57] <michaelni> so could someone add me back as ML admin? i promise not to unblock gabu which i wouldnt have done anyway [22:09:04] <mru> j-b: got better alternative? [22:09:18] <kierank> ffmailman [22:09:20] <j-b> mru: tried ecartis... It was actually worse, with no web interface... [22:09:36] <j-b> mru: Google groups is not compatible with my idea of free software [22:11:43] <mru> google groups is plain annoying regardless [22:15:43] <Kovensky> yahoo groups then! [22:15:44] * Kovensky runs [22:22:05] <mru> siretart: ping [22:26:46] <mmu> mru ssh key ? [22:27:16] <mru> mmu: I don't think I have yours [22:27:36] <mru> and for fate you should probably not be using your regular ssh key [22:28:08] <mmu> well the one I sent for svn (eh) was already generated for it with mmu_man@ffmpeg as comment [22:28:51] <mru> for svn? [22:29:44] <siretart> mru: yes? (but I'm almost away for today) [22:29:46] <mmu> before the <politics><strike unwanted options>schisma|split|coup</strike></politics> [22:30:06] <mmu> for commit access [22:30:14] <jannau> mmu: you mean for git at videolan [22:30:30] <mru> siretart: in your libavcore merge patch, why do you mess with libavutil/internal.h? [22:30:36] <mru> there should be no need for that [22:32:33] <siretart> mru: I'll check that tomorrow. I think it was necessary for ff_set_systematic_pal2, which I moved to imgutil.h on your request [22:32:47] <mmu> jannau yeah that one [22:32:55] <mru> mmu: I don't have access to that [22:33:09] <mru> siretart: so #include <libavutil/imgutil.h> where needed [22:33:12] <mmu_man> dcc ? [22:33:19] <mru> email please [22:33:22] <mmu_man> ok [22:34:06] <mmu_man> actually http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/122142/focus=123805 [22:34:12] <siretart> mru: ok. I'll check that [22:34:42] <mmu_man> it's attached there mru [22:35:30] <mru> mmu_man: added [22:38:27] <siretart> mru: you're right, the change to libavutil/internal.h is not necessary and can be dropped without further changes [22:39:22] <mru> siretart: also, you should never #include internal.h from another lib [22:42:59] <siretart> ok, I'll check/fix that tomorrow [22:44:26] <mmu_man> I suppose I have to use fate_recv="ssh mmu_man@..." [22:44:36] <mru> no [22:45:02] <mru> "ssh -i /the/private/key fate(a)fate.ffmpeg.org" should do it [22:45:09] <mru> run it from a shell first [22:45:29] <mru> you'll probably need to accept the host key once [22:47:09] <mmu_man> yep [22:51:06] <Dark_Shikari> https://www.bids.tswg.gov/TSWG/bids.nsf/0/9FEB7174D58D16B085257817004BA951/… [22:51:09] <Dark_Shikari> check the top of page 42. [22:52:08] <mru> Dark_Shikari: :) [22:54:14] <_av500_> mil grade ftw [22:56:32] <Flameeyes> okay do I have a 32-bit vm to try verify-lfs over ffmpeg? hm? :| [23:10:29] <uau> does having libavcore merged in libavutil somehow make it harder to use for other projects? [23:11:24] <uau> people seem to implicitly assume that it having it in one lib would prevent use outside ffmpeg, and only argue about whether such use could occur at all in any library configuration [23:12:20] <uau> but would having the extra stuff in the same lib actually cause any significant problems? [23:12:47] <_av500_> not for me [23:13:00] <_av500_> gn [23:13:04] <kierank> bye [23:25:45] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * raad216fd7e ffmpeg/libavformat/ (internal.h utils.c): [23:25:45] <CIA-38> ffmpeg: lavf: simplify pb parameter of ff_probe_input_buffer [23:25:45] <CIA-38> ffmpeg: There is no need to pass the ByteIOContext via a pointer to a pointer [23:25:45] <CIA-38> ffmpeg: anymore. [23:25:45] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [23:25:56] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r4d016dd4e5 ffmpeg/libavformat/internal.h: [23:25:56] <CIA-38> ffmpeg: lavf: update ff_probe_input_buffer documentation [23:25:56] <CIA-38> ffmpeg: It never reopens the bytestream anymore. [23:25:56] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [23:25:58] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r3940caad02 ffmpeg/ (5 files in 2 dirs): [23:25:58] <CIA-38> ffmpeg: lavf: rename ff_probe_input_buffer to make it public [23:25:58] <CIA-38> ffmpeg: It is useful for applications that hand input data directly to lavf via [23:25:58] <CIA-38> ffmpeg: a ByteIOContext. [23:25:59] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [23:26:02] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r17cf7c68ed ffmpeg/libavcodec/x86/dsputil_yasm.asm: [23:26:02] <CIA-38> ffmpeg: Fix ff_emu_edge_core_sse() on Win64. [23:26:02] <CIA-38> ffmpeg: Fix emu_edge_v_extend_15 to be <128 bytes on Win64, by being more strict [23:26:41] <CIA-38> ffmpeg: on the size of registers and which registers are being used for operations [23:26:41] <CIA-38> ffmpeg: where multiple are available. This fixes segfaults in emulated_edge() [23:26:41] <CIA-38> ffmpeg: function calls on Win64. [23:38:20] <Flameeyes> does somebody have an x86 FFmpeg build directory at hand? [23:40:08] <jannau> x86_64 [23:40:21] <Flameeyes> nope, that I have as well :) [23:40:28] * Flameeyes needs to try his verify-lfs script with improvements [23:40:32] <Flameeyes> I guess I should start up a 32-bit vm

1 0