[FFmpeg-devel-irc] IRC log for 2011-02-17

[irc at mansr.com]

[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 at 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/62dc5f79a968780a414f4a010bbdfb9c0f10a7cd
[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 at 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 at jannau.net>
[14:42:29] <CIA-15> ffmpeg: Anton Khirnov <anton at 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 at 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-Support-Stories.aspx awesome
[15:24:13] <thresh> http://www.asymco.com/2011/02/11/in-memoriam-microsofts-previous-strategic-mobile-partners/
[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-Support-Stories.aspx awesome <-- better version of cartman's link: http://thedailywtf.com/Articles/Genital-Syncing,-Accentricity,-and-More-Support-Stories.aspx
[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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at x264.com> master * r7634771e70 ffmpeg/libavcodec/vp8.c: VP8: faster MV clipping
[23:28:23] <CIA-15> ffmpeg: Jason Garrett-Glaser <jason at 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 at 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