[FFmpeg-devel-irc] IRC log for 2010-04-14

[irc at mansr.com]

[01:04:54] <astrange> how do you test a lavfi filter? i see client code in ffplay but not ffmpeg
[03:21:47] <ShadowJK> Anyone know what vp8 is? Presumably on2...
[03:21:51] <ShadowJK> I'd assume NIH h264
[03:23:06] <peloverde> I think there are bigger mysteries afoot: http://archosfans.com/wp-content/uploads/2010/04/gen_8_china4.jpg
[03:28:56] <Vitor1001> ShadowJK: vp8 is very likely just an improved vp3
[03:29:26] <Vitor1001> It would be hard otherwise to avoid some random patent bitting on2
[03:30:52] <peloverde> there is this totally unsubstantiated notion that VP8 doesn't step on any non-on2 patents
[03:30:52] <Vitor1001> why would they be stupid?
[03:31:00] <peloverde> it may not have been intentional
[03:31:10] <Vitor1001> do you think they have that many patents to defend themselves?
[03:31:18] <peloverde> look at VC-1 which was supposed to be patent free
[03:31:30] <peloverde> or microsoft patents only
[03:31:34] <Vitor1001> VC-1 wasn't designed to be patent-free
[03:32:16] <Vitor1001> probably whoever designed it could pretty well expect it was covered by some unknown-to-them patents
[03:32:37] <Vitor1001> but why care? MS has a big patent portfolio to fight back whoever tries to sue them.
[03:32:56] <peloverde> not necessarily, not all of the litagents make products
[03:33:10] <peloverde> some of them only collect IP and license it
[03:33:14] <Vitor1001> Are there video coding patent trolls?
[03:34:42] <peloverde> There are university held patents, sometimes those get sold
[03:35:09] <Vitor1001> :p
[03:35:10] <peloverde> isn't that how eolas got their plugin patent
[03:35:16] <Vitor1001> Great use of public money
[03:36:10] <peloverde> Presumably if the public funded the universities more they wouldn't have to sell off their patent portfolios
[03:36:59] <peloverde> On2 has been pimping vp8 since way before the google takeovers tuff started
[03:37:18] <peloverde> there must be some reason why they haven't actually released anything
[03:37:24] <Vitor1001> I know. But never releasing.
[03:37:39] <Vitor1001> BTW, there is a rumor google will opensource vp8 mid-may
[03:38:31] <Vitor1001> http://arstechnica.com/open-source/news/2010/04/google-planning-to-open-the-vp8-video-codec.ars
[03:39:14] <peloverde> there have been rumors that google will opensource vp8 for months
[03:39:59] <Vitor1001> Actual rumors or "if I were google ..."
[03:40:01] <Vitor1001> ?
[03:40:22] <peloverde> I heard "actual rumors" at FOSDEM
[03:41:17] <Vitor1001> Well, the arstechnica one was a rumor with a fixed date ;)
[03:45:50] <peloverde> Anyway I'm going back to my policy of ignoring VP8 until something, anything, is actually released, a spec, a binary decoder, some source, anything
[03:47:20] <Vitor1001> OF course. It is just that speculating is fun...
[03:49:20] <peloverde> We are missing a significant number of non vaporware formats, let's not get all worked up over a codec that hasn't managed to leave google/on2 doors
[03:49:51] <hyc> but who uses those other formats? or requests them...
[03:50:24] <Vitor1001> Which ones are not very rarely found on the wild?
[03:50:34] <Vitor1001> MS Screen codec? VP7?
[03:50:45] <Vitor1001> DolbyE?
[03:51:27] <peloverde> HE-AACv2?
[03:51:32] <peloverde> AMR-WB
[03:51:43] <peloverde> AAC encoding, SBR encoding
[03:51:55] <peloverde> really any lossy audio encoding
[03:52:06] <hyc> amr-wb used to be supported
[03:52:15] <hyc> then they switched to opencores
[03:52:18] <hyc> oh well
[03:52:22] <Vitor1001> yeah, encoding is progressing slowly
[03:52:39] <Vitor1001> btw, how is HE-AACv2 going?
[03:52:47] <peloverde> almost done
[03:52:50] <Vitor1001> cool
[03:52:54] <Vitor1001> any public branch?
[03:53:11] <peloverde> not at the moment
[03:53:29] <Vitor1001> is amr-wb used in the wild?
[03:53:38] <peloverde> the code works pretty well but is still super ugly
[03:53:59] <Vitor1001> code is born like that ;)
[03:54:56] <peloverde> more missing format i've seen in the wild: 3GPP metadata, mp3pro, GoToMeeting
[03:55:45] <peloverde> BSAC
[03:55:55] <peloverde> LATM
[03:56:49] <peloverde> icod
[03:56:54] <Vitor1001> Ugh, I forgot the GoToMeeting one
[03:56:55] <Vitor1001> :p
[03:58:00] <Vitor1001> BBL
[03:58:02] <Vitor1001> good night
[03:58:08] <peloverde> good night
[03:59:47] <hyc> AVERROR_PATCHWELCOME should be AVERROR_PATCHWILLBEMOSTLYIGNORED
[04:00:57] <astrange> i thought there was a gotomeeting codec for quicktime but i can't find it
[04:09:39] <peloverde> maybe it's time to make hyc a committer
[04:12:39] <astrange> i just installed a bunch of commercial lossless qt codecs then realized they were probably in the mplayer package already
[04:57:50] <hyc> peloverde: I guess that would help some, but not if every patch still needs to be reviewed before it's allowed to be committed
[04:59:08] <peloverde> yeah but generally after two or three pings on a patch you can push it anyway under the doctrine of nobody else seems to care
[04:59:53] <hyc> ahhh
[05:00:21] <hyc> yeah that would help ;)
[05:00:48] <kshishkov> peloverde: if you have commit rights
[05:01:01] <peloverde> yes if you have commit rights
[05:04:28] <av500> peloverde: what is the mystery afoot?
[05:08:22] <peloverde> with multitouch are you moving to capacitive touch-screens?
[05:11:01] <av500> I'd guess so
[05:11:39] <peloverde> I mostly brought ti up for the sake of speculating about something that doesn't begin in V and end in 8
[05:12:00] <av500> ah :)
[05:12:49] <kshishkov> peloverde: you can prematurely name that Theora2 anyway ;)
[05:14:09] * peloverde declines to comment further on the vaporcodec
[05:14:43] * kshishkov hasn't got a clue what peloverde is talking about anyway
[05:15:28] <kshishkov> have we got netbooks on OMAP4 yet?
[05:15:34] <av500> kshishkov: nope
[05:15:45] <av500> but they will come
[05:16:09] <kshishkov> d'you mean iPad?
[05:16:13] <hyc> not this year I'd suspect
[05:16:21] <hyc> all the initial allocation is to smartphones
[05:17:03] <av500> hyc: hmm, not sure about that
[05:17:10] <av500> kshishkov: but they wont be "netbooks"
[05:20:11] <hyc> av500: what are you thinking of?
[05:21:28] <av500> a netbook is by (current) market definition a small laptop running windows (7)
[05:21:35] <av500> and that is unlikey to change
[05:21:57] <av500> now, remove the keyboard and you suddently have a "tablet" which are all the rage
[05:22:26] <peloverde> I'm more excited about LTE devices 3G is old hat
[05:22:50] <hyc> ah. hohum. I wouldn't mind having a TouchBook based on OMAP4
[05:23:16] <peloverde> In The Feb 2010 Issue of the comsoc magazine there is a great article about LTE
[05:23:33] <av500> hyc: sure, neither would I
[05:23:56] <av500> but both of us are not "the customers"
[05:24:05] <hyc> right
[05:24:24] <hyc> and companies like that are far from the front of the line
[05:24:37] <av500> customer see screen and keyboard, thinks word/excel
[05:25:48] <hyc> well, the TB can be bought without the keyboard, just as a tablet
[05:25:59] <hyc> personally I could never use it like that
[05:26:33] <av500> so you are back at a linux running netbook...
[05:27:11] <hyc> yep
[05:28:47] * kshishkov wants ARM-based portable system that he can compile FFmpeg on
[05:29:03] <hyc> you can compile ffmpeg on the touchbook
[05:29:07] <hyc> if you have a lot of patience
[05:29:36] <hyc> I rebuilt gcc and the 2.6.29 kernel on mine
[05:29:37] <kshishkov> I started with PII-266
[05:29:46] <hyc> not the most thrilling useo f time
[05:30:36] <hyc> not sure what real purpose tablets serve, don't like handwriting as an input method
[05:30:36] <kshishkov> you can do something else on other hw
[05:31:06] <hyc> and I'm not enough of an artist to take advantage of it for freehand drawing/sketching
[05:32:59] <hyc> I'd like a portable machine with eyeglass display. I don't even think a foldable/rollable flexi screen would satisfy
[05:35:47] <hyc> I didn't realize displays were such a touchy subject for kshishkov :P
[06:03:33] <pJok> god morgon kshishkov :)
[06:03:41] <kshishkov> goda morgnar
[06:13:40] <ramiro> mru, j-b: there is no way to shut that warning up (at least last time I looked at gcc's code)
[06:19:37] <ramiro> someone please tell BBB (when he's back) please commit.
[06:20:19] <ramiro> and someone please tell him again what irssi is and why it's much better to leave a client always on =)
[06:26:41] <jai> maybe he's using a laptop?
[06:26:55] <av500> a Mac laptop even
[06:27:06] <av500> and as they do not multitask....
[06:32:33] <superdump> iphone os 4 brings multi-tasking!
[06:32:46] <av500> but it is not released yet
[06:33:06] <av500> and apple did not mention irc as a supported background task
[06:33:27] <av500> :)
[06:33:35] <kierank> mac users: irc, is that a form of twitter?
[06:34:03] <av500> @kierank: lol
[06:34:27] <kierank> RT: @av500 @kierank:lol
[06:34:47] <jai> #fail
[06:36:49] <pJok> vp8 open source #rumors
[06:38:02] * kshishkov thinks it may be the time to kick anybody who mentions Theora2 here
[06:38:14] <merbzt> you just did
[06:38:20] <pJok> KICK HIM!
[06:38:22] <pJok> ;)
[06:39:36] <av500> "...One of the most exciting innovations in VP8 is the constructed reference frame. A constructed reference frame is a frame of image data (a reference buffer) that's encoded into the bitstream but never displayed. It serves solely to improve the encoding of subsequent frames by providing an additional and hopefully better predictor than any previously transmitted "normal frames."...
[06:40:17] <ramiro> kshishkov: we once talked about chanson. is this something related to your chanson, but in german? http://www.youtube.com/watch?v=U_j6q6GB0ZI
[06:40:40] <merbzt> av500: well that was sort of interesting
[06:41:00] <thresh> ramiro: if they sing about prisons, then yes
[06:41:19] <kshishkov> ramiro: I cherish my ignorance of German language
[06:41:26] <av500> merbzt: http://www.dspdesignline.com/howto/214303691
[06:41:50] <ramiro> thresh, kshishkov: I don't undertand german enough to understand the words, but the music sounds just as corny =)
[06:42:19] <kshishkov> ramiro: music does not matter for Russian chanson anyway
[06:43:17] <kshishkov> it may range from prison blues to j(ail)-pop
[06:46:02] <ramiro> Kovensky: this sounds more like our brega...
[06:46:38] <av500> well, element of crime is not about jail :)
[06:46:57] <ramiro> av500: hmm, you're german, right?
[06:47:02] <kshishkov> av500: "A New Take on Loop Filtering" is laughable - even RV4 uses loop filter that fits that description
[06:47:20] <jai> kshishkov: that's marketing for you :)
[06:47:25] <av500> ramiro: somewhat
[06:48:50] <kshishkov> well, Russian chanson includes everything from songs about everyday life of Assi to the ballads about criminals like in Australia
[06:49:39] <ramiro> av500: but you know the band?
[06:49:47] <av500> yes
[06:51:42] <kshishkov> av500: do you know what "Assi" in German means?
[06:51:55] <av500> I can imagine
[06:52:21] * ramiro is curious...
[06:56:03] <kshishkov> av500: well, I just heard it's German equivalent of most of Ukrainian population (including Ukrainian president in youth)
[06:56:23] <kshishkov> I just don't know how to translate it properly into English
[06:56:29] <kshishkov> hoon?
[06:56:49] <av500> well, the german assi is from "asozial" which is anti-social
[06:57:36] <kshishkov> are those the people who seemingly do nothing but will be glad to lighten your burden of money and valuables in the dark?
[07:05:00] <hyc> irssi? I just run finch in a screen session on my web server
[07:05:05] <hyc> and ssh in
[07:07:00] * kshishkov runs irssi in a screen session on his web server/rounter/the only x86 box and uses ssh too
[07:15:34] <__gb__> pong superdump, sorry, I am not always at the office since bus drivers are on strike around here
[07:15:45] <superdump> no problem :)
[07:15:57] <kshishkov> PCI-Express bus or AGP bus drivers?
[07:16:03] <kierank> lol country stereotypes ;)
[07:16:07] <av500> french bus
[07:16:18] <superdump> i was just wondering if that i965 h.264 branch affected the gma x4500mhd
[07:16:26] <superdump> of libva
[07:16:28] <kshishkov> ah, frech transport drivers seem to be always on strike
[07:16:42] <kierank> kshishkov: french * seem to be always on strike
[07:16:54] <ramiro> __gb__: les francais aiment la greve...
[07:17:53] <kshishkov> kierank: english transport is not much better though
[07:18:00] <__gb__> superdump, there probably are regressions for older G45, but I am not aware of any
[07:18:12] <kierank> kshishkov: well of course
[07:18:15] <__gb__> if you say so, then probably :)
[07:18:40] <superdump> __gb__: well, i want to know is if that branch adds support for h.264 decoding using the gma x4500mhd
[07:18:46] <superdump> or if it's already in master...
[07:18:48] <superdump> :)
[07:18:57] <superdump> or if neither
[07:19:05] <kshishkov> __gb__: you should have an array of video cards (donated by vendors) to test it
[07:19:17] <__gb__> kshishkov, our parisian transportation service also has a good technique: they can be on strike again to force management to pay their days they were on strike...
[07:19:39] <kshishkov> ah, Paris
[07:19:43] <kshishkov> that explains all
[07:19:58] <__gb__> superdump, not yet, only for Arrandale/Carkdale platforms (Ironlake) at this time
[07:20:12] <superdump> i wish they wouldn't use codenames all the time
[07:20:14] <__gb__> they will support older G45 when the current code stabilises
[07:20:17] <superdump> list the damn gpus :)
[07:20:40] <__gb__> ok, I think this is Intel HD Graphics, the integrated GPU to Core iX :)
[07:21:03] <superdump> after mine then
[07:21:05] <superdump> hrm
[07:21:11] <kshishkov> superdump: codenames are not bad when they applied correctly - like to furniture
[07:23:38] <superdump> well, my issue is, it's a level of indirection
[07:24:09] <superdump> when people look at their laptop to figure out if their gpu has hardware decoding support, they'll look at the gpu name, not try to figure out what codename was used for their whole chipset
[07:25:06] <kshishkov> superdump: they look on the pasted label saying "Designed for Windows 98" or something
[07:25:14] <astrange> they won't be able to figure out anyway because they have to know the level of the video being played
[07:26:49] <__gb__> superdump, they will try to target support for older G45 by Q3
[07:27:12] <kshishkov> "by Q3"? in half a year?
[07:28:08] <__gb__> interestingly, their implementation (at least on Arrandale), can cope with 1 HD + 1 SD stream simultaneously
[07:28:24] <__gb__> kshishkov, yes, could be [ July - September ] :-/
[07:29:36] <kshishkov> __gb__: fine with me
[07:29:58] * kshishkov does not own anything supported by vaapi anyway
[07:31:04] <kshishkov> or anything that could be supported by it
[07:31:57] <superdump> __gb__: the claims i saw about the gma hd was that it had ~50% better performance than the x4500hd though
[07:32:07] <superdump> still, 1 HD would be nice
[07:32:10] <superdump> :)
[07:32:45] <av500> DTS/DCA has fixed block sizes?
[07:32:49] <__gb__> :)
[07:32:56] <kshishkov> nope
[07:33:06] <kshishkov> its block size is stored in header IIRC
[07:33:13] <av500> ok
[07:33:34] <superdump> __gb__: thanks for the response though :) good to know roughly when it's due
[07:38:08] <kshishkov> http://www.ubersoft.net/files/comics/hd/hd20100413.png?1271158276
[08:24:22] <Kano> hi, is there a time estimation when
[08:24:27] <Kano> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086859.html
[08:24:32] <Kano> will be merged?
[08:24:52] <kshishkov> of course not
[08:25:03] <Kano> i tested it with vlc and mplayer it works
[08:25:07] <kshishkov> could be quite soon though
[08:25:38] <Kano> would be fine, then i dont have to patch it everytime
[08:26:42] <superdump> Kano: well, i guess as long as __gb__ is responsive to michael's reviews, it shouldn't take too long
[08:26:47] <superdump> it's a small piece of code
[08:27:22] <av500> he might be on strike
[09:06:40] <mru> q
[09:06:57] <peloverde> r
[09:07:13] <pJok> s
[09:08:34] <av500> t
[09:10:26] <superdump> u
[09:13:29] <saintdev> v
[09:13:49] <__gb__> w
[09:13:51] <elenril> c-c-combo breaker
[09:16:43] <kshishkov> you could continue that till ö
[09:17:00] <bilboed-pi> you have the whole of unicode if you insist
[09:17:28] <kshishkov> no, our alphabet is from a to ö
[09:17:38] <kshishkov> not from \u0000 to \uFFFF
[09:17:47] <j-b> __gb__: tu pourrais au moins avoir un avatar :)
[09:19:08] * __gb__ pige rien à ces interfaces et s'en fout :)
[09:21:00] <j-b> :)
[09:22:12] <kshishkov> varför talar ni på franska i svensk kanal?
[09:22:16] * KotH is reminded of fried french... er.. french fries
[09:22:20] * KotH is getting hungry
[09:22:28] <av500> schoggi?
[09:22:32] <kshishkov> * KotH is not getting Hungary
[09:22:41] <KotH> av500: schoggi is energy, not nutrition
[09:23:01] <kshishkov> av500: do you feast on shoggots now?
[09:23:08] <KotH> kshishkov: been there, got it, didnt like it, left it
[09:23:36] <av500> kshishkov:  \\\ooo///
[09:24:14] <kshishkov> KotH: there is a saying that man should try everything in his life except folk dancing and visiting Ukraine
[09:24:26] <kshishkov> av500: (,,;,,;,,)
[09:24:44] <av500> kshishkov: nice
[09:55:07] <Dark_Shikari> wooohooooo bikeshed arguments on ffmpeg-devel ML!
[09:55:30] <kshishkov> again?
[09:58:22] <mru> again implies they ended
[09:59:00] <peloverde> bikeshedding, me still being up at 6 am, ... what else is new
[09:59:53] * pJok hands Dark_Shikari a bucket of black paint
[09:59:59] <peloverde> I have this gut feeling that one of these days this little coalition of ours is going to fall apart and we are going to split in 2-4 directions (forks)
[10:00:02] <peloverde> but who knows its lasted this long
[10:00:23] <kshishkov> pJok: the only proper paint for bikesheds is Faluröda
[10:00:23] <mru> where would we go?
[10:00:34] <pJok> hehe
[10:00:45] <kshishkov> peloverde: we have ffmbc already
[10:00:53] <mru> seriously, there's nowhere else to go
[10:01:03] <mru> and our differences aren't that bad
[10:01:20] <pJok> i've seen wrose
[10:01:24] <pJok> worse*
[10:01:41] <pJok> you agree on most things and you mostly agree to disagree on things you dont agree about
[10:02:10] * kierank goes to register openffmpeg, netffmpeg and freeffmpeg
[10:02:23] <peloverde> If there were a serious fork using git an interleaved swscale i'd jump
[10:02:46] <mru> I could set up such a "fork" right there on ffmpeg.org :-)
[10:03:05] <pJok> fffmpeg? ;)
[10:03:07] <mru> you can help by preaching to diego and michael
[10:03:58] <peloverde> I tried at delirium :)
[10:04:04] <kshishkov> Kierank: you versions will lack H.263 decoder
[10:04:19] <mru> peloverde: use more beer
[10:04:41] <kierank> kshishkov: why h.263?
[10:04:46] <kshishkov> peloverde: hint - Michael is more important
[10:05:12] <kshishkov> kierank: dunno, but those BSD variant always seem to lack something substantial
[10:05:27] <mru> yes, c99 support
[10:05:38] <mru> but hey, they've got theo de rant
[10:05:41] <mru> gotta be good
[10:06:05] <pJok> mru, they will just reimplement ffmpeg if they think its the wrong license
[10:06:38] <peloverde> I wasted a good day on PS tracking down a handful of bugs resulting from doing complex arithmetic manually
[10:06:42] <pJok> and make their version almost, but not quite, compatible in arguments
[10:06:46] * peloverde shakes fist at non-c99 systems
[10:06:56] <kshishkov> pJok: well, someone should make swscaler LGPL
[10:07:15] * mru wouldn't trust a compiler to do complex maths efficiently anyway
[10:07:27] <pJok> kshishkov, first someone should do the "svn commit" and run ;)
[10:07:50] <peloverde> I feel like it really shouldn't be that hard (which doesn't mean gcc does it right)
[10:08:03] <pJok> mru, do you even trust gcc to do simple math efficiently?
[10:08:30] <mru> no
[10:08:41] <KotH> it might not been hard, but it's more complex than a simple "if this basic_block, then write this_code"
[10:08:59] <Kovensky> lol de rant
[10:09:19] <mru> pJok: how did you think I sped up the dca decoder by >4x?
[10:09:24] <KotH> kshishkov: theo de rant?
[10:09:34] <pJok> mru, prybar?
[10:09:37] <peloverde> you reduce it to scalar arithmetic, then you remove all dead-state, that's how it gets done by hand
[10:09:52] <Kovensky> * @peloverde shakes fist at non-c99 systems <-- the fun: there was actually a patch that implemented all log\d\d?f? functions for freebsd's libc... in 2006
[10:09:57] <Kovensky> it never got anywhere afaik
[10:09:59] <mru> peloverde: and then you simd as much as possible
[10:10:19] <peloverde> mru, yes, that's the second phase
[10:11:03] <peloverde> I'm thinking about writing all new code with complex.h then converting to scalar once it's all been verified
[10:11:47] <mru> especially when doing complex arithmetic, you'll often end up several independent operations
[10:11:56] <mru> by careful register allocation you can simd those
[10:12:20] <peloverde> that is true, but it's not like we use the autovectorizer anyway
[10:12:29] <kshishkov> KotH: that's more correct version of Theo de Raadt name IIRC. Kinda Dalias for BSD
[10:12:37] * peloverde remembers he has that half finished simd rdft patch
[10:13:01] <peloverde> I really need to clone myself or something, too few hours
[10:13:32] * pJok gets the cloning equipment from the basement
[10:14:01] <kshishkov> peloverde: and I have half-finished VC-1 8x8 transform patch
[10:14:26] * kshishkov does not think this world can hold more than one instance of him
[10:14:53] * mru places a clone of kshishkov on mars
[10:15:00] <mru> sorry about the ping time
[10:16:32] <jai> DTN ftw :)
[10:17:10] <peloverde> I wonder if there is a way we can find some new competent contributors
[10:17:37] <mru> peloverde: huh?  they're arriving all the time
[10:18:05] <peloverde> not fast enough
[10:19:11] <jai> post on reddit, that seemed to help vlc
[10:20:02] <peloverde> At fosdem noticed an estimated 4:1 interest ratio from vlc to ffmpeg
[10:20:12] <Dark_Shikari> that's because people like the frontends, not the backends
[10:20:14] <peloverde> and it's probably lower once you factor out OGP :)
[10:21:09] <kshishkov> time for FFplay G2
[10:21:23] <mru> we need a bigger video wall
[10:21:28] <peloverde> clearly
[10:21:34] <mru> more beagles and monitors, anyone?
[10:22:07] <kshishkov> nah, we need holographic output this time
[10:22:14] <peloverde> I know I was a recession recruit to FFmpeg and there have to be others who found themselves out of work and looking to keep busy
[10:22:20] <Dark_Shikari> those are a little expensive
[10:22:24] <jai> also free beer at ffmpeg's stall
[10:22:37] <Dark_Shikari> btw, I may be able to get some funding for ffmpeg
[10:22:46] <peloverde> I was actually thinking about doing stickers or something
[10:22:48] <Dark_Shikari> I'm working with a guy who is currently getting money THROWN at him by creative to try to use their incredibly awful hardware
[10:22:58] <Dark_Shikari> and "using their hardware" involves "making the decoder support what the hardware does"
[10:23:02] <Dark_Shikari> and the decoder is ffmpeg
[10:23:17] <mru> what does the hardware do?
[10:23:37] <peloverde> gather dust?
[10:23:47] <Dark_Shikari> I'm sorta under NDA, but I think it's just some box
[10:23:47] <mru> ah, it's a roomba
[10:23:58] <Dark_Shikari> and it has stuff like an (insanely awful) encoder
[10:24:03] <peloverde> FFroomba
[10:24:04] <Dark_Shikari> which can only do slices if FMO is on
[10:24:06] <Dark_Shikari> etc
[10:25:03] <Dark_Shikari> I also wonder how much michael would charge for SVC
[10:25:06] <Dark_Shikari> he quoted $10k for FMO
[10:25:27] <peloverde> ahh FMO that brings back good memories of my early codec hacking
[10:25:44] <Dark_Shikari> FMO might be useful if it wasn't baseline-only :/
[10:26:11] <peloverde> yes, the non main features of baseline that no one uses
[10:26:13] <peloverde> once upon a time I started out with H.264 and ASP decoders
[10:26:29] <mru> you're young
[10:26:31] <peloverde> maybe sometime I'll get back to video
[10:26:38] <peloverde> 2005 is half a decade ago
[10:26:56] <mru> that's recent
[10:27:09] <peloverde> It seems like a long time ago to me
[10:28:37] <KotH> does anyone know a good explanation of unified diff format? i couldnt find one that's easy to understand and not a foot note in a huge document
[10:28:55] <mru> the format is rather obvious to me
[10:28:56] <KotH> need it as reference for in-house documentation
[10:29:36] <KotH> the format is obvious if you come from unix, if you come from electronics or, heaven forbid, from windows, it's far from being obvious
[10:29:53] <mru> wrong
[10:30:00] <mru> the format has nothing unixy about it
[10:30:14] <mru> if you know what it's supposed to represent, it should be obvious
[10:30:26] <mru> if not, you've no business using a computer
[10:30:29] <peloverde> it's very simplistic, more simplistic than non-unified diff
[10:30:48] <KotH> mru: it is not unixy, but people with a unixy-mindset have less probs to grasp it
[10:31:15] <KotH> bbl... lunch time
[10:31:18] <mru> seriously, how any anyone not understand it?
[10:31:25] <mru> -line to delete
[10:31:27] <mru> +line to add
[10:31:38] <mru>  untouched context line
[10:33:20] <kierank> [11:31] <@mru> seriously, how any anyone not understand it? --> needs some xml
[10:33:22] <mru> @@ -old_line_num,old_num_lines +new_line_num,new_num_lines @@ comment
[10:33:31] <mru> --- old filename
[10:33:34] <mru> +++ new filename
[10:33:37] <mru> that's it
[10:34:09] <mru> http://gist.github.com/363107
[10:34:26] <mru> ^^ parser generator in xslt
[10:34:56] <jai> ugh
[10:35:30] <j-b> my eyes!
[10:36:10] <kshishkov> hmm, kinda obvious
[11:08:37] <KotH> mru: never underestimate the stupidity of average people
[11:10:45] <twnqx> kierank: register ffmpeg-ng, too
[11:11:25] <kshishkov> ffmpeg-next and ultimate-ffmpeg
[11:11:40] <KotH> and ffmpeg-for-ever
[11:11:47] <Tjoppen> mru: looks like it generates code for xml data binding, or?
[11:13:15] <Tjoppen> we butted heads with xmlbeansxx for quite some time here, before we eventually grew fed up with its idiotic dependencies (JDK, Ant and Maven för a C++ library!?)
[11:17:23] <mru> wow
[11:18:18] <kierank> twnqx, which program uses -ng?
[11:18:29] <twnqx> none (yet)
[11:20:03] <kshishkov> yaffmpeg?
[11:20:45] <pJok> ffmpeg-2010
[11:23:54] <KotH> pJok: ffmpeg-2013 "after the end of the world edition"
[11:24:14] <pJok> that too
[11:24:29] <pJok> and ffmpeg-classic
[11:26:36] <kshishkov> don't forget ffmpeg-enterprise for mru/av500
[11:27:25] <mru> EEmpeg
[11:27:30] <mru> enterprise edition
[11:27:41] <_av500_> huh
[11:27:48] <kshishkov> sounds like --FFmpeg
[11:30:21] <KotH> FFmpeg/400 ?
[11:30:42] <pJok> FFmpeg mainframe edition?
[11:30:43] <kshishkov> exclusively for AIX?
[11:31:04] <pJok> yes
[11:31:16] <kshishkov> FFmpeg Transuranium
[11:31:36] <kshishkov> (why settle for lighter metals?)
[11:31:57] <pJok> hehe
[12:08:13] <Kovensky> < kierank> twnqx, which program uses -ng? <-- lincity? :>
[12:47:43] <mru> ping gsoc people
[12:48:00] <Dark_Shikari> "gsoc people"; students?
[12:48:12] <mru> no, admins/mentors
[12:48:22] <Dark_Shikari> btw, mru, what do you know about explicit prefetch on modern cpus?
[12:48:24] <kshishkov> wait till evening and BBB then
[12:48:37] <mru> Dark_Shikari: that's a vague question
[12:48:40] <Dark_Shikari> How many prefetches can said CPUs that you know about take at once, and what if you exceed the limit?
[12:48:45] <Dark_Shikari> Do they queue them up, or ignore them?
[12:48:47] <mru> we had a gsoc slot too many, right?
[12:49:20] <kshishkov> wanna participate as a student?
[12:49:23] <Dark_Shikari> lol
[12:49:30] <Dark_Shikari> mru isn't in bloody school >_>
[12:50:22] <kshishkov> there are public schools in Britain ;)
[12:55:59] <mru> Dark_Shikari: there are as many answers to that question as there are cpus
[12:56:05] <mru> and the values are rarely documented
[12:56:19] <mru> publicly
[12:56:21] <Dark_Shikari> For those you know about =p
[12:56:40] <Dark_Shikari> for those you know answers to said questions for
[12:56:43] <mru> I'd have to check the docs
[12:58:21] <Dark_Shikari> I'd like to know for cortex and modern x86 chips
[12:58:31] <mru> which cortex?
[12:58:36] <mru> there's about a dozen of them
[12:58:38] <Dark_Shikari> lol
[12:58:43] <av500> M1
[12:58:45] <Dark_Shikari> The ones we care about, i.e. A8+
[12:59:32] <mru> there's a5, a8, a9, m0, m1, m3, m4, and r4
[12:59:42] <mru> and each of those has multiple revisions
[13:00:01] <mru> and many of them are configurable by the silicon builder
[13:00:35] <mru> cortex-a8 has 3 major revisions, each with rather different cache/memory interfaces
[13:00:46] <Dark_Shikari> and?  pick one
[13:08:00] <Dark_Shikari> hmm.  also, how long has __builtin_prefetch been around?
[13:08:14] <mru> 3.x I think
[13:08:29] <mru> varies depending on cpu
[13:08:48] <Dark_Shikari> not talking about per cpu
[13:08:52] <Dark_Shikari> I'm fine with it just ignoring it on old versions
[13:08:55] <Dark_Shikari> I want to know when I can start using it
[13:09:01] <Dark_Shikari> and know it won't fail to compile =p
[13:09:18] <Dark_Shikari> hmm.  seems to be 3.1 or 3.2 depending on which source
[13:09:43] * Dark_Shikari goes with 3.2
[13:10:32] <Dark_Shikari> also, in the general case, are cache misses on stores "free" if we don't load from there for a while?
[13:10:39] <Dark_Shikari> I would assume the cpu can pipeline them away
[13:10:43] <Dark_Shikari> since there's no data dependency
[13:18:55] <mru> miss on store depends on many things
[13:19:14] <mru> often it's a per-page setting
[13:19:22] <Dark_Shikari> explain?
[13:19:29] <Dark_Shikari> how is whether or not it stalls the pipeline a per-page setting?
[13:19:51] <mru> allocate-on-write is a per-page setting
[13:20:11] <Dark_Shikari> allocate-on-write?  I mean pages that are already allocated obviously
[13:20:15] <Dark_Shikari> I mean "cache miss" not "page fault"
[13:20:20] <mru> I mean cache line allocate
[13:20:21] <Dark_Shikari> if I meant page fault, I would have said page fault
[13:20:23] <Dark_Shikari> ah
[13:20:25] <mru> it's common terminology
[13:20:37] <Dark_Shikari> But why would that affect anything?
[13:20:43] <Dark_Shikari> Even if it has to allocate a cacheline, there's no data dependency
[13:20:46] <Dark_Shikari> it should happen in the background
[13:20:50] <mru> sometimes it's better to let a miss on write simply write through
[13:21:08] <mru> so suppose you do allocate on write
[13:21:19] <mru> there are different ways of dealing with that
[13:21:52] <mru> one way is to put the write in a store queue, issue the line fetch, and commit the store to cache once the line has been filled
[13:22:04] <mru> the pipeline can then proceed without delay
[13:22:10] <mru> some cpus do this
[13:22:32] <mru> others simply block while waiting for the data to arrive
[13:22:39] <mru> that's much simpler to implement
[13:22:58] <Dark_Shikari> what do modern x86 chips do?
[13:23:05] <mru> some non-blocking implementations have nasty bugs in unusual corner cases too
[13:23:06] <Dark_Shikari> I would assume the former, since they like to do complicated things
[13:23:36] <mru> it's good for performance too, so yes they probably do it
[13:23:48] <Dark_Shikari> k, then I only have to prefetch for loads, not stores
[13:24:11] <mru> some cpus do have special prefetch-for-write instructions
[13:25:12] <Dark_Shikari> the next issue I have is the following corner case
[13:25:14] <mru> and some have prefetch and mark as low priority
[13:25:22] <mru> which is good when iterating over large blocks
[13:25:32] <Dark_Shikari> suppose we're doing something simple like fetching the mvs for top left, top, and top right MBs
[13:25:49] <Dark_Shikari> If we run the prefetch on "top left", we get all the MVs, unless it crosses a cacheline
[13:25:55] <Dark_Shikari> then we don't
[13:26:01] <mru> also don't forget predictive, speculative prefetching in some cpus
[13:26:07] <Dark_Shikari> the question is whether it's worth running two prefetches (mv top left, and top right)
[13:26:11] <Dark_Shikari> to catch that corner case
[13:26:14] <Dark_Shikari> or whether it's a waste of time
[13:26:32] <mru> how often do you reckon it happens?
[13:26:35] <Dark_Shikari> my thought is that since we _wrote_ the cached data only one row ago, it's guaranteed to be in L2 (we're doing this to fetch to L1), so a miss couldn't be too expensive
[13:26:45] <Dark_Shikari> But obviously it's expensive enough that prefetches are helpful
[13:27:03] <Dark_Shikari> well, each row of an MB is 2 * 2 * 4 = 16 bytes of data
[13:27:06] <Dark_Shikari> so it happens once every 4 MBs
[13:27:26] <Dark_Shikari> for reference frames, every 32 MBs (2 bytes of data per MB)
[13:27:34] <Dark_Shikari> so maybe worth it for MVs, maybe not for refs
[13:27:40] <Dark_Shikari> it depends on how many prefetches the CPU will let us run at once
[13:27:47] <mru> try both and compare
[13:27:59] <Dark_Shikari> I need 3+3+6*2+2*2 prefetches at once, roughly
[13:28:09] <Dark_Shikari> where "at once" means "in relatively close proximity"
[13:28:25] <Dark_Shikari> i.e. within a space of 100 clocks
[13:29:51] <Dark_Shikari> I wonder if this would be a reason to store MVs on a per-MB basis
[13:29:56] <Dark_Shikari> instead of in an 2D array
[13:30:08] <Dark_Shikari> i.e. [MB index][0 to 15]
[13:30:16] <Dark_Shikari> This would be more friendly cache-wise: one cacheline per MB
[13:30:33] <Dark_Shikari> currently it's up to 6 cachelines per MB for loading data, this would bring it down to 4
[13:40:54] <mru> BBB: ping
[13:47:06] <Dark_Shikari> oh god cdecl
[13:47:49] <Dark_Shikari> mv: int16_t (*mv[2])[16][2];
[13:47:50] <Dark_Shikari> int16_t (*l1mv[2])[16][2] = { h->fref1[0]->mv[0][h->mb.i_xy], h->fref1[0]->mv[1][h->mb.i_xy] };
[13:47:57] <Dark_Shikari> the latter warns about initialization from incompatible pointer type
[13:50:03] <Dark_Shikari> mru: any idea?
[13:50:27] <Dark_Shikari> ah, it seems I have to remove the "16"
[14:08:08] <mru> lol, did you know there exists a Japan Highway Public Corporation Tokyo First Operation Bureau Facilities Maintenance Division
[14:09:41] <kshishkov> sounds reasonable
[14:10:06] <mru> now translate it to german
[14:10:12] <kshishkov> one word?
[14:12:27] <kshishkov> Russian establishment usually bear the names like "Federal X division of Federal organization Y of Russian Federation"
[14:13:17] <mru> some soviet outfit used to hold the guiness record for longest organisational name
[14:13:49] <kshishkov> could be, Russia is improving German model since XIXth century at least
[14:14:24] <kshishkov> sometimes mere abbreviation takes about ten letters
[14:15:30] <kshishkov> for example, my internal passport issues by "Nth RVKhMUUMVS of Ukraine in Kharkiv region"
[14:16:04] <kshishkov> (and I had to write it by hand for so many times :(
[14:16:55] <av500> mru: that does not translate cleanly to german
[14:18:21] <kshishkov> av500: japanischepublikautobahntokioersteoperationenbueronagåntingmaintenanz?
[14:19:24] <av500> no
[14:19:31] <av500> japanische would be a separate word
[14:19:48] <mru> damn
[14:19:49] <twnqx> and å isn't even a german letter :P
[14:20:03] <av500> public as well
[14:20:07] <kshishkov> well, it's a typo anyway
[14:20:13] <av500> i assumed that much
[14:20:48] <kshishkov> it should be "någonting"
[14:21:04] <mru> that's etwas
[14:21:14] <mru> or irgendwas
[14:21:16] <mru> depends
[14:21:26] * kshishkov does not know German but thinks of Swedish as more acceptable substitute
[14:23:25] <pJok> kshishkov, eller nånting om man är lat ;)
[14:23:42] <mru> eller nåt om man e latare
[14:23:49] <pJok> japp
[14:24:21] * kshishkov is not that lazy
[14:24:22] <mru> danish has gone quite far in reducing all words to single-syllable gurgles
[14:24:39] <pJok> of course
[14:24:42] <andoma> ø
[14:24:47] <pJok> just take my name
[14:24:47] <kshishkov> 0
[14:24:53] <pJok> noone pronounces it fully
[14:24:59] <pJok> noone says Jørgen
[14:25:01] <mru> andoma: hey, didn't know you speak danish
[14:25:04] <pJok> its Jørn mostly
[14:25:21] <kshishkov> same here
[14:25:29] <andoma> mru: :)
[14:25:29] <mru> kshishkov: no, that's different
[14:25:43] <mru> russians etc all have two quite distinct names
[14:25:49] <mru> one official, one that people call them
[14:26:05] <mru> and some have one that people refer to them as in third person
[14:26:12] <mru> or something like that
[14:26:15] * kshishkov has Ukrainian name as well
[14:27:09] <kshishkov> given name, some form of it for close friends, patronymic name (used for calling middle-aged men too) and last name
[14:27:33] <pJok> kosi?
[14:27:35] <pJok> ;)
[14:27:43] <kshishkov> kostya
[14:28:06] <kshishkov> as a bonus it's short version of both Russian and Ukrainian name
[14:28:16] <mru> that's a fairly standard contraction of konstantin
[14:28:43] <mru> but in a formal setting you'd probably be called by the full name
[14:28:49] <mru> not so in danish
[14:32:26] <j-b> ramiro: /tmp/ccUKMx1c.s:13310: Error: operand type mismatch for `cmp' when compiling swscale?
[14:33:16] <av500> kshishkov: I call you whatever tab completion calls you :)
[14:36:56] <pJok> av500, like Kovensky ?
[14:36:57] <pJok> ;)
[14:37:49] <j-b> ramiro: cmp on Win64 isn't correct?
[14:38:00] <av500> for reasons (unknown to me), this tab places kshishkov before Kovensky
[14:39:07] <thresh> because irssi has adaptive completion
[14:39:12] <pJok> it just wants to mess with you
[14:39:15] <thresh> like, who's been last active.
[14:40:01] <av500> I think that it rates "k" < "K"
[14:40:12] <pJok> it doesn't
[15:24:54] <BBB> mru: pong
[15:26:17] <mru> BBB: did we have one gsoc slot too many?
[15:26:44] <BBB> nope
[15:27:06] <mru> didn't or don't?
[15:27:13] <BBB> we did, but we don't
[15:27:20] <BBB> but we still probably have 2-3 that we won't use
[15:27:30] <BBB> I don't see all of these students qualifying in the next 7 days
[15:27:36] <BBB> but that might just be me being negative or so
[15:27:42] <BBB> what would you like to do with 'em?
[15:28:01] <mru> I'm asking because an xbmc guy applied to the beagle soc and it looks like he might not get it
[15:28:05] <mru> beagle only got 4 slots
[15:28:29] <merbzt> BBB: we can give slots to orgs we like to give to
[15:28:45] <BBB> so would you like me to ask carol to assign it to them?
[15:28:45] <merbzt> or at least suggest
[15:28:49] <kshishkov> yay, bribes!
[15:28:56] <mru> xbmc is good for ffmpeg, so I though if we have extra slots, we could give one to him
[15:29:08] <BBB> ok, I'll ask carol to give it to them
[15:29:28] <mru> wait until we've hammered out the beagle situation properly
[15:29:32] <BBB> ok
[15:29:36] <kshishkov> mru: really? What except APE decoder and RTMP stuff we got from them?
[15:29:48] <mru> they use ffmpeg, got to be good
[15:29:51] <BBB> keep me updated and I'll do as you say
[15:29:57] <merbzt> that's rockbox
[15:29:59] <BBB> gstreamer uses ffmpeg, does that make them good?
[15:30:03] <mru> no
[15:30:05] * BBB hides
[15:30:12] <kshishkov> mru: a lot of projects do, some of them are in hall of shame
[15:30:18] <mru> oh, come on
[15:30:24] <mru> you know the xbmc people
[15:30:27] <mru> they're good
[15:30:30] <BBB> we're kidding dude
[15:30:32] <BBB> I know they're good
[15:30:36] <BBB> I communicated with a few of them
[15:30:37] <BBB> they're nice
[15:31:09] <andoma> I drank beer with one of them. Can't remember anything...
[15:31:20] <mru> we met a few at linuxtag
[15:31:25] <kshishkov> so what, bilboed-pi is not that bad as gstreamer either
[15:31:41] <mru> that's on a more personal level
[15:31:50] <mru> gst as a project despises us
[15:31:55] <mru> and we them
[15:31:58] <bilboed-pi> eh what ?
[15:32:00] <bilboed-pi> no
[15:32:27] <ohsix> sounds like projection
[15:32:29] <bilboed-pi> any open-source multimedia project that needs codecs... would be utterly stupid to despire ffmpeg
[15:32:32] <bilboed-pi> *despise
[15:32:34] <mru> gst is always there, picking crumbs from the corporate table
[15:32:49] <mru> then they ignore they are totally dependent on ffmpeg
[15:32:58] <mru> and put the ffmpeg support in gst-plugins-ugly
[15:32:59] <bilboed-pi> mru, right, because you're living off charity maybe ?
[15:33:03] <mru> or was it dirty?
[15:33:12] <Dark_Shikari> mru: er, it's in ugly because they are lazy and don't want to decouple the gpl parts
[15:33:19] <ohsix> ffmpeg elements are in all sorts of the split packages
[15:33:21] * bilboed-pi laughs :)
[15:33:25] <Dark_Shikari> Now, what _is_ obnoxious about gstreamer
[15:33:29] <Dark_Shikari> though probably less so gstreamer's fault
[15:33:34] <bilboed-pi> it's actually in a standalone module : gst-ffmpeg
[15:33:36] <mru> of course taking money from companies is fine
[15:33:36] <Dark_Shikari> is promotion of proprietary codecs
[15:33:49] <Dark_Shikari> gstreamer is a very popular platform for promoting proprietary garbage
[15:33:50] <mru> it's the way they do it I don't like
[15:33:53] <bilboed-pi> Dark_Shikari, show me where we promote proprietary codecs on gstreamer website
[15:33:56] <ohsix> allowing them is promoting them?
[15:33:56] <mru> look at the fluendo stuff
[15:33:59] <Dark_Shikari> particularly promoting propietary garbage _as a replacement for ffmpeg_
[15:34:02] <Dark_Shikari> fluendo in particular
[15:34:10] <Dark_Shikari> I didn't say gstreamer devs in particular were the primary ones at fault
[15:34:11] <bilboed-pi> fluendo hasn't been a gstreamer contributor in ... 4 years ?
[15:34:26] <ohsix> its been a long time :]
[15:34:28] <mru> what can I say, a bad reputation sticks
[15:34:29] <bilboed-pi> despite them still stating they hire "core contributors"
[15:34:30] <Dark_Shikari> bilboed-pi: and yet people still promote fluendo gstreamer elements as a replacement for open source ones
[15:34:43] <bilboed-pi> Dark_Shikari, I know, and I want to slap them really hard every time they do that
[15:34:56] <Dark_Shikari> This is like the people who say to use mplayer binary codecs instead of libavcodec.
[15:35:55] <Dark_Shikari> But yes, mru bitches too much about gstreamer
[15:36:02] <Dark_Shikari> gstreamer is hardly evil, just incompetent.
[15:36:03] * Dark_Shikari runs
[15:36:13] * bilboed-pi brings out the railgun
[15:36:18] <bilboed-pi> run little jason, run
[15:36:26] <mru> Dark_Shikari: there's little difference in practice
[15:36:32] <Dark_Shikari> mru: evil is more effective
[15:36:46] <kshishkov> mru: evil is a cure for incompetence ;)
[15:37:00] <ohsix> don't ascribe malice to wit can be explained adequately by stupidity
[15:37:02] <BBB> bilboed-pi: even I agree with them though, you guys do an absolutely horrible job at giving credit where due
[15:37:12] <bilboed-pi> BBB, where ? what ?
[15:37:16] <BBB> bilboed-pi: ffmpeg gets very little credit and a LOT of criticisim from your little corner
[15:37:26] <BBB> just talk with christian for 10 minutes
[15:37:34] <BBB> he's sitting there right next to you
[15:37:48] <bilboed-pi> BBB, hmm... no, he works in Cambridge, I work in Barcelona
[15:37:59] <merbzt> http://www.youtube.com/watch?v=1T5gQHa2pq4&feature=player_embedded
[15:37:59] <ohsix> running out of unused frames and aborting is kind of a drag
[15:38:16] <BBB> bilboed-pi: you're ignoring the bigger issue
[15:38:22] <BBB> bilboed-pi: christian is a pain in giving us proper credit
[15:38:39] <BBB> it'd be great if you could at least acknowledge that
[15:39:00] <BBB> I know other gst devs are quite happy with what we do, but they are unfortunately not as outspoken or well-spoken or bloggy or whatever you want to call it
[15:39:16] <BBB> your vocal minority is a problem
[15:39:22] <mru> as always
[15:39:30] <ohsix> people can see that its being used; what kind of credit do you mean? like giving information that a nontechnical user wouldn't know what to do with anyways?
[15:39:32] <Dark_Shikari> BBB: the technical term we use in the US is
[15:39:34] <Dark_Shikari> "overzealous staffer"
[15:39:40] <bilboed-pi> BBB, define "your" in "your vocal minority"
[15:39:43] <Dark_Shikari> whenever something bad happens, it's the fault of an "overzealous staffer"
[15:39:46] <Dark_Shikari> or "overzealous intern"
[15:39:54] <Dark_Shikari> it's never the fault of an organization or a higherup
[15:39:58] <mru> BBB: it's a bigger issue than that
[15:40:26] <mru> the way gst is running around the hw companies, they drop an ugly gst plugin and call it "supporting open source"
[15:40:54] <mru> if they didn't have that option, they might, just might, be more likely to provide something we could actually work with
[15:41:20] <mru> best case, open specs
[15:41:20] * bilboed-pi wished mru knew what he was talking about :)
[15:41:42] <mru> not quite as good, a close-to-hardware library not tied to gst
[15:42:02] <Dark_Shikari> mru: platform lockin is fine when we do it!
[15:42:06] <mru> for the record, I always know what I'm talking about
[15:42:34] <BBB> ohsix: I think we care a lot more about the acknowledgement clause of the lgpl than you think
[15:42:37] <mru> Dark_Shikari: please note that I didn't suggest they contribute lavc support
[15:42:46] <BBB> ohsix: just see how painful we are to license violators
[15:42:50] <Dark_Shikari> mru: I was referring to gstreamer
[15:43:35] <mru> so I see gst as being actually harmful to open source
[15:43:43] <mru> quite aside from being arrogant bastards
[15:44:03] <ohsix> i'm harming open source right now
[15:45:12] <kshishkov> ohsix, wanna be harmed in return?
[15:45:27] <BBB> bilboed-pi: anyway, one thing you could bring up in your corporate office next tie you visit cambridge is that we'd be more than happy to accept donations from your company that assist our always-ongoing RE efforts... also, kshishkov is looking for a job in a developed country
[15:45:28] <mru> I don't mind people doing closed source
[15:45:33] * KotH passes some bottles of beer around
[15:45:37] <KotH> boy, please relax!
[15:45:40] <mru> but doing it under the guise of being open bugs me
[15:45:41] <ohsix> is that a threat? heh, whats the point of that
[15:45:56] <kshishkov> KotH: we are relaxed and lazy trolling :P
[15:46:17] <mru> and trying to hack u-boot in another window
[15:46:18] <kshishkov> BBB: but both UK and Spain don't qualify as developed countries
[15:46:36] <BBB> :-p
[15:46:36] <bilboed-pi> kshishkov, you should try USA, I here they're trying to get civilized
[15:46:48] <kshishkov> ohsix: no, just a hint on moral code and such stuff
[15:47:02] <ohsix> a threat is a lesson on morality eh
[15:47:05] <KotH> kshishkov: yeah.. and hitting the poor boy lying on the ground
[15:47:09] <BBB> living in "USA" is like living in "Europe", it means nothing
[15:47:12] <jai> bilboed-pi: lol
[15:47:14] <KotH> anyways.. gtg... have a nice evening
[15:47:14] <BBB> it depends on *where* you live
[15:47:50] <kshishkov> ohsix: no, it was just a phrase intended to remind you of "don't do unto others what you don't want to be done on you"
[15:48:49] <kshishkov> BBB: that's why I determined part of Europe where I want to live
[15:48:53] <ohsix> its a difference of opinion, not bore out by anything empyrical; you cant reason about it, so what can you definitively say is being done in reality?
[15:49:23] <BBB> enough flaming I guess...
[15:49:40] * BBB goes work
[15:49:47] <kshishkov> boooring
[15:50:13] <ohsix> minutae often is
[15:51:35] <superdump> mru: i'm not really sure why you're attacking gstreamer
[15:51:47] <superdump> i have more loyalty to ffmpeg than gstreamer
[15:51:48] <mru> because they deserve it
[15:51:53] <superdump> i don't really know gstreamer too well
[15:51:58] <mru> they're annoying as hell
[15:52:01] <superdump> but i don't understand what you're talking about
[15:52:19] <mru> just take my word for it then
[15:52:24] <bilboed-pi> lol
[15:52:34] <superdump> but you haven't given any evidence
[15:52:47] <superdump> you've just said gstreamer is bad, evil, annoying, arrogant, blah blah
[15:52:58] <av500> and it uses glib on top of that
[15:52:59] <mru> you're obviously not listening
[15:53:06] <superdump> i just read the entire backlog
[15:53:13] <mru> and you seem to be in the defend-the-bad-guy-against-mru mood today
[15:53:29] <superdump> not really
[15:53:30] <mru> I hate it when you do that
[15:53:37] <Dark_Shikari> mru: I think it's moreso that annoying people tend to be associated with gstreamer
[15:53:45] <merbzt> poor mru
[15:53:46] <Dark_Shikari> rather than outright gstreamer's fault.
[15:53:54] <mru> is there a difference?
[15:53:56] * merbzt sends a hug to england
[15:53:57] <Dark_Shikari> most definitely
[15:53:59] <Dark_Shikari> =p
[15:54:00] <superdump> i defend ffmpeg when people in gst say 'don't use the ffmpeg plugin, it's bad'
[15:54:14] <Dark_Shikari> superdump: mru is arguing that said people are why gst is bad
[15:54:19] <av500> err, what do you use instead?
[15:54:25] <av500> superdump: ^^^
[15:54:33] <mru> gst ships a badly written ffmpeg plugin, it fails, they and the users blame ffmpeg
[15:54:33] <Dark_Shikari> av500: proprietary codecs
[15:54:36] <mru> ffmpeg gets a bad name
[15:54:49] <superdump> so then we should help make the gst plugin better if we can
[15:54:55] <ohsix> ^^
[15:54:59] <superdump> and they should contact us about things that aren't good
[15:54:59] <mru> they're not interested in that
[15:55:01] <Dark_Shikari> mru: then patch ffmpeg to runtime-fail
[15:55:02] <ohsix> right now its an ugly situation
[15:55:03] <Dark_Shikari> like we did with x264
[15:55:07] <Dark_Shikari> and ffmpeg
[15:55:15] <Dark_Shikari> Then they'll be forced to fix it eventually
[15:55:20] <bilboed-pi> mru, correction : distribution don't pick the revision of ffmpeg we recommend for gst-ffmpeg, and then the blame goes to gstreamer or ffmpeg
[15:55:25] <superdump> unless distributions just patch that out again
[15:55:27] <Dark_Shikari> actually that's a rather good point
[15:55:29] <Dark_Shikari> handbrake has the same issue
[15:55:34] <ohsix> they're basically checkpointing their own versions since the releases aren't fit for purpose
[15:55:37] <Dark_Shikari> a ton of distros try to hijack their build system and replace the versions
[15:55:41] <dgt84> I've personally met and spent a few days with a lot of the GStreamer guys and they are a pretty cool group. I have a feeling there are some miscommunication issues here and people get into flamefests too easily...
[15:55:41] <Dark_Shikari> and shit breaks
[15:55:57] <Dark_Shikari> ohsix: well, moreso that gstreamer wants more releases
[15:55:58] <mru> I know what I see
[15:56:12] <ohsix> you think therefore you are?
[15:56:17] <mru> and I see ffmpeg getting blamed for gst failing
[15:56:42] <ohsix> this doesn't have anything to do with those aborts does it
[15:56:48] <superdump> to use your mantra - patches welcome
[15:56:51] <superdump> :)
[15:57:03] <jai> well, more like ffmpeg's mantra :)
[15:57:07] <superdump> right
[15:57:41] <kshishkov> superdump: speaking of which, how many useful ones we've got from gst?
[15:57:47] <superdump> i dunno
[15:58:05] <superdump> but both sides saying "you're not being helpful to us, you suck, we're not helping you" isn't progressive
[15:58:12] <jai> of course not
[15:58:21] <jai> more participation on the ML would be nice
[15:58:55] <kshishkov> superdump: and why that doesn't happen with MPlayer/VLC/Xine/XBMC?
[15:59:14] <BBB> superdump: I just gave patch suggestions to bilboed-pi
[15:59:17] <BBB> superdump: scroll up a bit
[15:59:19] <bilboed-pi> to be fair... libavcodec has been pretty much flawless for the past year
[15:59:22] <BBB> in fact, I gave 3
[15:59:29] <av500> kshishkov: coz they are "g" less :)
[15:59:36] <merbzt> jai: is this album for real http://www.bombay-connection.com/en_GB/site/page/1/releases ?
[15:59:51] <av500> merbzt: you asked that like 2 weeks ago
[15:59:53] <av500> :)
[16:00:06] <merbzt> jai: you being the only indian music player I know
[16:00:08] <av500> to the same jai
[16:00:17] <merbzt> av500: no that was to nfl
[16:00:24] <av500> hm
[16:00:25] <av500> ok
[16:00:28] <jai> merbzt: yeah :)
[16:01:24] <jai> merbzt: though i can recommend better artists
[16:02:11] <kshishkov> jai: i.e. any artist?
[16:03:07] <jai> merbzt: like http://www.youtube.com/watch?v=x4SFOm9CL5A
[16:03:19] <jai> merbzt: much better sampling and post-production
[16:03:39] <av500> jai: video is stuck on 1st frame here...
[16:03:52] <merbzt> jai: well sure but this is from 19 frickin 82
[16:04:46] <jai> av500: err, maybe flashplugin's fault?
[16:05:13] <merbzt> like 10 years before its time
[16:05:38] <av500> jai: ah, it is a slideshow :)
[16:05:41] <kshishkov> jai: http://www.youtube.com/watch?v=ZA1NoOOoaNw - can you also hear what's said in subtitles or you knowledge of that language prevents that?
[16:06:04] <jai> merbzt: yeah, i kinda forgot that part :)
[16:07:11] <jai> kshishkov: err, yeah its pretty much what the subs say :)
[16:07:16] <jai> that's tamil btw
[16:07:31] <kshishkov> ah, that must be the reason
[16:08:05] <kshishkov> Russian and Swedish examples don't work with me
[16:08:11] <kshishkov> this one does
[16:09:42] * mru once heard a kurdish(?) song that sounded just like "kill all the russians"
[16:09:53] <jai> lol
[16:10:00] <mru> didn't even need subs
[16:13:24] <kshishkov> too many Gentoo devs here
[16:14:01] <av500> kshishkov: you wanted to fflame gentoo now after gst?
[16:14:53] <kshishkov> no, just slightly worried about any sudden increase of any other group of devs here
[16:15:17] <BBB> too many ffmpeg devs here
[16:15:17] <Dark_Shikari> -fomit-all-instructions
[16:15:24] <mru> who's a gentoo dev other than lu_zero ?
[16:15:42] <mru> -fabandon-all-hope
[16:15:50] <elenril> fflameeyes?
[16:15:54] <mru> oh, right
[16:15:56] <ohsix> Honoome/flameeyes
[16:16:21] <Honoome> mru: yeah?
[16:16:44] <mru> Honoome: sorry, forgot about you
[16:16:47] <nirbheek> Honoome, our increased presence here is making kshishkov uncomfortable :p
[16:16:49] <mru> you're kinda new around here
[16:16:58] <Honoome> nirbheek: ah there's you as well :)
[16:17:08] <mru> nirbheek: well, what _are_ you doing here?
[16:17:10] <Honoome> mru: it's mostly that I don't usually am not even around :P
[16:17:23] <nirbheek> mru, I'm here because jai told me to join ;p
[16:17:34] <mru> now why would he do that...
[16:17:50] <elenril> it's a conspiracy to take over ffmpeg
[16:18:06] * YuviPanda is here becaus of jai as well
[16:18:10] <jai> gst related talk is interesting to nirbheek
[16:18:14] <jai> YuviPanda: uh huh
[16:18:53] <kshishkov> jai: but we stopped flaming already
[16:19:02] <jai> kshishkov: indeed, so its pointless now :)
[16:19:10] <nirbheek> kshishkov, jai said that it keeps coming back
[16:19:24] <nirbheek> something about 'predicable flamewars'
[16:19:40] <mru> did you mean predictable?
[16:19:45] <mru> predicable is something else entirely...
[16:19:45] <nirbheek> Yes, I did
[16:20:19] <mru> this is getting scary
[16:20:21] * av500 pretends to download gentoo to blend in
[16:20:24] <jai> lol
[16:20:43] <Ford_Prefect> av500, you need to -O3 to _really_ blend in
[16:21:07] <av500> only -O3?...
[16:21:14] <ohsix> Ford_Prefect is gentoo too zomg
[16:21:14] <jai> -fzomg-ricers?
[16:21:18] * jai hides
[16:21:20] <mru> why do people think gentoo is only about -O9?
[16:21:26] <nirbheek> -fmake-everything-faster
[16:21:27] <Dark_Shikari> mru: NO ITS TOTALLY ABOUT THE USE FLAGS
[16:21:40] <mru> it's about control
[16:21:46] <ohsix> its build a bunch of packages with deps into a directory
[16:21:46] <av500> kshishkov: there is your gentoo fflame :)
[16:21:52] <mru> and about the rc system being f*cking ace
[16:21:53] <DonDiego> Yuvi: you around?
[16:21:56] <Ford_Prefect> it's about keeping your room warm in the winter
[16:21:57] <nirbheek> mru, so it's like BDSM?
[16:21:58] <DonDiego> YuviPanda: are you Yuvi ?
[16:22:07] <YuviPanda> DonDiego: no, I'm not
[16:22:08] <kshishkov> av500: thanks but I need neither them nor gentoo
[16:22:23] <ohsix> Ford_Prefect: keeping the cat content :]
[16:22:27] <Dark_Shikari> >control   can I "control" gentoo to stop using 5-page-long config lines for vlc?
[16:22:43] <av500> use smaller font?
[16:24:50] <kshishkov> Dark_Shikari: yes, do everything manually
[16:25:02] <Dark_Shikari> kshishkov: that's probably still easier than portage
[16:25:28] <mru> you can always replace the ebuild
[16:26:00] <mru> in debian/redhat/suse you can't do a friggin thing
[16:26:04] <Dark_Shikari> sure you can
[16:26:06] <Dark_Shikari> build it yourself
[16:26:08] <Dark_Shikari> same as I do in gentoo
[16:26:14] <Ford_Prefect> That's probably there because we don't let the build autodetect anything. (disclaimer: I don't maintain the ffmpeg ebuild and haven't even looked at it)
[16:26:19] <ohsix> debian is pretty slick with source packages
[16:26:21] <nirbheek> Dark_Shikari, you use gentoo?
[16:26:30] <Dark_Shikari> yes
[16:26:37] <av500> kshishkov: look what you have started!
[16:26:45] <mru> he's like one of those gay homophobes
[16:26:47] <ohsix> not as simple as a single text file though (and patches/arch independent files or whatever)
[16:27:22] <mru> if I need a simple patch for something, I just drop it in /etc/portage/patches
[16:33:20] <av500> mru: btw, aac sbr wants neon love it seems
[16:34:21] <mru> oh yes, I know
[16:34:31] * mru waits for the highest bidder
[16:34:38] <av500> I clock 5.1 at 40% of 500mhz atm
[16:35:03] <kshishkov> mru: $5 from me, unless anybody else bids I'm the highest bidder
[16:35:24] <av500> $5.50
[16:36:04] <mru> if you add a k to that we're in business
[16:36:14] <mru> av500: do you have a good test file?
[16:36:31] <kshishkov> you'd better ask peloverde
[16:36:43] <av500> al_sbr_cm_48_5.1.mp4
[16:36:53] <av500> mru: ^^
[16:37:00] <av500> from the compliance files
[16:37:21] <mru> looks like I'm missing that set
[16:38:07] <av500> wow, I get 60% of 500mhz even on a movie tralier
[16:39:22] <mru> aren't you using that other aac decoder?
[16:39:36] <av500> yes, but it only 2ch atm
[16:39:55] <av500> for 2ch, its 6% vs 12%
[16:40:09] <mru> sbr?
[16:40:12] <av500> yes
[16:40:26] <av500> I think for non sbr, lavc is even faster than what I have
[16:40:47] <av500> but I have to go now, back at work on monday
[16:41:03] <mru> I did optimise it to death
[16:41:22] <av500> good
[16:41:23] <mru> it spends about 40% of the time in neon asm
[16:52:59] <av500> lol: http://spot.livejournal.com/308370.html
[16:53:48] <mru> that's not bad
[16:54:46] <ohsix> theres a language project called Io that'd hit every one of those demerits
[16:56:10] <Ford_Prefect> 40 points for the Linux kernel in the first 2 sections
[16:56:21] <Ford_Prefect> Well, 35
[16:57:43] <pengvado> why is "you've written your own source control" more fail than not having any?
[16:57:55] <Ford_Prefect> 135 points for the Linux kernel
[16:58:00] <Ford_Prefect> I always knew it was made of fail
[16:58:36] <kshishkov> pengvado: because relying on any tool you wrote for it gives you 100 points
[16:58:42] <elenril> yeah, it's obvivous it'll die soon
[16:58:59] <mru> exception if the tool is so good everybody else starts using it too
[16:59:03] <kshishkov> not before its year on desktop ;)
[16:59:46] * elenril doubts it
[16:59:57] <elenril> 2011 is the year of hurd on desktop
[17:00:13] <Ford_Prefect> Oooh, ooh, is a 0.1 release planned? :P
[17:03:47] <elenril> Your code tries to install into /opt or /usr/local << what's wrong with that?
[17:06:39] <kshishkov> well, try to sum points for GCC
[17:06:48] <mru> maybe he means it _only_ installs there
[17:06:57] <mru> kshishkov: integer overflow
[17:07:33] <kshishkov> ok, any other GNU tool
[17:17:21] <Kovensky> <+elenril> Your code tries to install into /opt or /usr/local << what's wrong with that? <-- /usr/local is standard location
[17:24:26] <elenril> Kovensky: http://tvtropes.org/pmwiki/pmwiki.php/Main/CaptainObvious =p
[17:30:57] * Kovensky to the rescue
[17:32:46] <Kovensky> * Your source builds using something that isn't GNU Make [ +10 points of FAIL ] <-- what's wrong with building with BSD Make
[17:33:19] <kshishkov> again, either GNU sales pitch or scons/cmake
[17:34:12] <Kovensky> * Your project does not do releases [ +50 points of FAIL ] <-- lolol
[17:34:34] <Kovensky> * Your releases are only in OSX .zip format [ +10 points of FAIL ] <-- OSX has their own zip format? o_O
[17:34:36] <kshishkov> yep, now we replaced that with tablegen
[17:34:53] <kshishkov> OSX special files in ZIP
[17:35:06] <kshishkov> like attributes and other crap
[17:35:19] <Kovensky> * Your code is a fork of another project [ +10 points of FAIL ] <-- he clearly hates DVCSes
[17:35:30] <kierank> and the zip file has all sorts of mac crap in it or thumbs.db from windows
[17:35:46] <Kovensky> if there was +10 points of fail for every person that has a clone of git://git.videolan.org/x264.git ...
[17:35:54] <kshishkov> thumbs.db deserves +13 points of FAIL
[17:36:07] <kierank> the mac equivalent is worse
[17:36:25] <Kovensky> * Your code does not have per-file licensing [ +10 points of FAIL ]
[17:36:25] <Kovensky> * Your code contains inherent license incompatibilities [ +20 points of FAIL ]
[17:36:28] <Kovensky> * Your code does not have any notice of licensing intent [ +30 points of FAIL ]
[17:36:32] <Kovensky> * Your code doesn't include a copy of the license text [ +50 points of FAIL ]
[17:36:35] <Kovensky> lol
[17:36:37] <Kovensky> I guess all my perl scripts fall in those categories? :S
[17:36:57] <Kovensky> well, not on the licensing intent I guess, at least I say it's ISC on Build.PL / README
[17:37:14] <Kovensky> * Your code doesn't have a changelog [+10 points of FAIL] <-- `git log`
[17:37:36] <kshishkov> not very useful
[17:37:38] <kierank> these days I think sourceforge is a fail
[17:37:51] <kshishkov> *sourceforget
[17:38:08] <Kovensky> now reading the comments
[17:38:11] <Kovensky> "MakeMaker for Perl" <-- uh, MakeMaker makes a standard makefile
[17:38:39] <Kovensky> - for building static libraries with -fPIC objects. <-- can't this be blamed on binutils on x86_64 being retarded and refusing to link shared libs to non-PIC static libs
[17:41:24] * kshishkov prefers PIC on processors where number of register actually allows using it
[17:41:37] <Kovensky> "You need a score for "Your code has a licence you made up"." <-- what about the code from the guy that made the WTFPL license, or all the code mrs wrote
[17:41:37] <kshishkov> i.e. PPC/MIPS
[17:42:27] <kshishkov> GNU projects have +infinity score
[17:42:48] <Kovensky> valid point
[17:43:29] <kierank> xiph too
[17:44:00] <mru> Kovensky: it's _impossible_ to have non-pic code in shared libs on x86-64
[17:45:03] <pengvado> sure, but the impossibility can be blamed on ld.so, not on the hardware.
[17:45:16] <mru> it's not that simple
[17:45:20] <Kovensky> "# Your build system depends on csh. (+50)" <-- what, I never saw *anything* that uses csh
[17:45:26] <Kovensky> <@mru> Kovensky: it's _impossible_ to have non-pic code in shared libs on x86-64 <-- what about -Bsymbolic
[17:45:55] <mru> you'd have to require .text+.data+.bss <4G for non-pic shlib to work
[17:46:06] <mru> -Bsymbolic is different
[17:46:58] <Kovensky> well, it is, but it makes ld not abort :P
[17:47:10] <Kovensky> and it makes a working .so that links to a static library somehow
[17:47:18] <mru> -Bsymbolic tells the linker to resolve any internal dependencies immediately and not defer it to ld.so
[17:47:24] <mru> you'll still have relocations
[17:47:36] <Kovensky> never looked into details, but it was the only way I got a shared ffms2 to link with static libav*
[17:47:44] <mru> Kovensky: your statement is pointless
[17:47:50] <mru> meaningless
[17:48:06] <Kovensky> ?
[17:48:26] <mru> you can't have a .so that "links to" a .a
[17:48:33] <mru> you can link a .a into a .so
[17:48:42] <mru> but then it becomes _part of_ the .so
[17:48:43] <Kovensky> well, true, the code is stuffed inside the .so
[17:49:23] <pasteeater> who is the contact for donations (if any)?
[17:49:25] <mru> and any inter-section references will still have to go through the GOT
[17:49:57] <mru> with -Bsymbolic you allow the linker to bind intra-section references directly
[17:49:58] <kshishkov> pasteeater: BBB should be
[17:49:58] <Kovensky> "king_inuyasha" <-- lol @ nick
[17:50:12] <mru> so function calls within the .so don't get the plt indirection
[17:50:17] <Kovensky> mru: I see
[17:50:27] <Kovensky> well, I should read about ELF and ld.so more
[17:51:03] <mru> the problem with x86-64 shared libs is that without pic you can end up requiring a 64-bit offset where there's only a 32-bit field
[17:51:13] <pasteeater> kshishkov: thanks
[17:51:27] <BBB> kshishkov: ?
[17:51:29] <Kovensky> but the only difference I noticed, as a non-informed person, between -Wl,-Bsymbolic and no -Wl,-Bsymbolic is that the latter made ld abort with "invalid relocation", the former made the .so :P
[17:51:42] <mru> yes, that's quite likely
[17:51:50] <kshishkov> BBB: are you donations man?
[17:51:50] <mru> -Bsymbolic will remove some relocations
[17:51:56] <BBB> oh right
[17:51:56] <BBB> yes
[17:52:23] <mru> function calls within the same .so can be done as relative call directly to the target
[17:52:35] <mru> because the .text section is always loaded as one piece
[17:52:53] <pasteeater> BBB: is IRC your preferred method of contact?  i was going to reply to a message in ffmpeg-user.
[17:53:09] <BBB> whichever is convenient for you
[17:53:12] * Kovensky doesn't see why would anyone prefer a ML to IRC
[17:53:18] <BBB> Kovensky: log
[17:53:22] <BBB> search, also
[17:53:26] * mru logs irc
[17:53:28] <kshishkov> attachments
[17:53:28] <Kovensky> the logs are public now
[17:53:44] <BBB> I'm not on that list
[17:53:46] <Kovensky> and I have logs from here since late 2008
[17:53:47] <mru> kshishkov: never heard of irc attachments?
[17:53:50] <BBB> anyway
[17:54:09] <pasteeater> BBB: i'll just tell them to come here and look for you.
[17:54:21] <mru> kshishkov: like this @attach:virus.jpg.exe:base64:2l3kdj908834rjlk34j238
[17:54:24] <BBB> pasteeater: ok
[17:54:25] <kshishkov> mru: sometimes fftrollbot goes out for a smoke or lunch
[17:54:42] <mru> kshishkov: even trolls have some rights
[17:54:58] * BBB goes for lunch
[17:57:26] <DonDiego> the failmeter is great..
[17:59:03] <kshishkov> you can lower it by returning viewvc or similar
[17:59:28] <mru> I've been unable to find a viable replacement
[17:59:31] * DonDiego looks at KotH
[17:59:32] <mru> they _all_ suck cpu
[17:59:53] * DonDiego thought there was cpu to spare, oh well..
[18:00:10] <mru> not when running viewvc
[18:00:17] <mru> it KILLED the machine, remember?
[18:01:34] <elenril> that git viewer doesn't eat so much cpu?
[18:03:26] <mru> not by far
[18:03:57] <elenril> then we should switch to git immediately ;)
[18:04:16] <_av500_> +1
[18:08:18] <mru> I installed the latest viewvc on my computer
[18:08:28] <mru> fetching the log for ffmpeg's configure takes almost 10 seconds
[18:08:39] <mru> with hot caches
[18:09:35] <mru> on a much faster machine than natsuki
[18:10:25] * Kovensky pats ナツキ
[18:10:42] <Kovensky> about "that git viewer", do you mean gitweb elenril
[18:11:05] <mru> the only other svn viewers I found were either unmaintained or php
[18:11:05] <elenril> i mean this >> http://git.ffmpeg.org/
[18:11:06] <mru> or worse
[18:11:07] <Kovensky> I like gitweb, but I miss the syntax hilighting (that github gives) :(
[18:11:22] <Honoome> hmm
[18:11:25] * Honoome prefers cgit over git
[18:11:28] <Honoome> *gitweb
[18:11:37] <Kovensky> any cgit example?
[18:11:42] <Honoome> unless they finally do caching… for a while I worked on my own frontend
[18:11:44] <Kovensky> elenril: needs to get mplayer too
[18:11:46] <Honoome> cgit.lscube.org iirc ;)
[18:11:48] <mru> cgit.openembedded.net
[18:15:09] <elenril> Kovensky: http://repo.or.cz/w/mplayer.git =p
[18:15:57] <Kovensky> elenril: well, I mean for the reimar fork
[18:16:13] <elenril> why? people still use it?
[18:16:20] * elenril hides
[18:16:23] <Kovensky> Honoome: hmm, no syntax hilighting on cgit either :(
[18:16:58] <Honoome> I didn't implement it in gitarella either… I could have though…
[18:18:41] * Kovensky still doesn't get why replace ... with the unicode …
[18:18:54] <Kovensky> though if you do that to annoy people that don't set up UTF-8 correctly it is a perfectly valid reason :>
[18:19:21] <kshishkov> or really poor man who can't afford enough dots
[18:19:44] <elenril> Kovensky: for the lulz ofc
[18:19:53] <elenril> <insert ED link>
[18:20:04] <mru> it's a 3-byte utf8 sequence too, so it doesn't save any bandwidth
[18:20:26] <Kovensky> true
[18:20:32] <Kovensky> but lol @ saving 1 byte per "..."
[18:21:27] <kshishkov> Kovensky: maybe it's a sign "I can use IRC from M$ Word"
[18:21:41] <Kovensky> winword does that replacement? o_o
[18:21:45] <Kovensky> s/o$/O/
[18:21:57] <elenril> â‹® hmm, there's a vertical version too
[18:22:08] <Kovensky> I think that one's for math
[18:22:40] <kshishkov> or Japanese
[18:22:43] <Kovensky> lol, … actually saves typing from one POV... compose+.+. instead of ... =p
[18:23:08] <Kovensky> kshishkov: I don't think they use that outside informal writing
[18:23:11] <twnqx> altgr+.
[18:23:14] <twnqx> …
[18:23:22] <Kovensky> my compose is altgr =p
[18:23:27] <Kovensky> but it requires two . instead of one ._.
[18:23:35] <twnqx> mine is right ctrl :P
[18:23:39] <twnqx> Ë™
[18:23:41] <Kovensky> because compose+.+- is ·
[18:23:59] <twnqx> ˙·.
[18:24:13] <Kovensky> don't know how to make the upper dot
[18:24:13] <Kovensky> lol
[18:24:53] <twnqx> upper dot for me is compose+.+.
[18:24:54] <twnqx> :P
[18:25:26] <Kovensky> what do you use for composing
[18:25:28] <Kovensky> gtk or xim
[18:25:39] <twnqx> huh?
[18:25:43] <Kovensky> (or autohotkey with that xcompose -> ahk hack)
[18:25:46] <twnqx> i rely solely on X
[18:25:59] <Kovensky> gtk has their own hardcoded compose table, they ignore X's
[18:26:03] <Kovensky> xim would be X's
[18:26:13] <twnqx> this is a gtk app i'm typing in
[18:26:21] <twnqx> you're right
[18:26:36] <twnqx> in shell compose+.+. gives … :P
[18:26:54] <Kovensky> I heard gtk would use xim's if you forced it to use xim as the input method, but I didn't get much success with that :v
[18:27:07] <elenril> xim worksforme
[18:27:20] <elenril> pretty much anywhere
[18:27:30] <Kovensky> switching to xim makes ibus not find xchat :(
[18:27:41] <Kovensky> same for urxvt (and that's why I'm not using it instead of konsole)
[18:27:48] <Kovensky> stupid konsole and its dumb font restrictions
[18:27:56] <Kovensky> I like MS Gothic ok :V
[18:28:13] <elenril> => don't use xchat =p
[18:28:23] <elenril> ibus works just fine with urxvt
[18:28:30] <twnqx> you know way too much about stuff i don't care about \o/
[18:28:30] <Kovensky> howto
[18:28:48] <elenril> URxvt.inputMethod: ibus
[18:28:56] <elenril> in resources
[18:29:11] <Kovensky> hmm, I have "URxvt*inputMethod: xim"
[18:29:37] <elenril> s/works just fine/almost fine/
[18:29:53] <elenril> it randomly freezes on client exit if you use urxvtd
[18:30:01] <Kovensky> yay, it werks
[18:30:05] * elenril should file a bugreport
[18:30:35] <Kovensky> URxvt*perl-ext-common: default,readline,matcher,selection-popup
[18:30:35] <Kovensky> URxvt*matcher.pattern.1: http:\/\/img\\d+\\.pixiv\\.net\/img\/.*\/(\\d+)(?:_.*?)\\..*?
[18:30:38] <Kovensky> URxvt*matcher.launcher.1 /usr/bin/xdg-open http://www.pixiv.net/member_illust.php?mode=medium&illust_id=$1
[18:30:41] <Kovensky> ^ doesn't work though :C
[18:31:27] * elenril isn't really into pokemon
[18:31:30] <Kovensky> hmm, I forgot to put a \b to terminate the regexp, but that's not the point
[19:01:32] <astrange> ah, gcc4.5 came out
[19:02:37] <peloverde> too little too late, clang is my compiler now
[19:04:23] <Kovensky> peloverde: clang builds ffmpeg correctly now?
[19:04:33] <Kovensky> well, llvm
[19:04:39] <Kovensky> since the miscompilation was on asm
[19:04:47] <Kovensky> also, last time I tested, clang++ didn't build ffms :(
[19:05:05] <Kovensky> it generated valid llvm that llvmc didn't like lol
[19:05:45] <peloverde> clang++ is a different beast, and it seems to handle our asm these days
[19:05:56] <peloverde> plus it gives human readable error messages
[19:07:46] <astrange> it's the same backend, still miscompiles x86-32
[19:08:12] <peloverde> (ok clang++ is part of clang but clang is my CC my CXX remains g++)
[19:08:59] * elenril wonders wtf is with oom killer randomly killing his processes
[19:10:02] <Kovensky> it ran out of mana
[19:10:36] <elenril> got over 200MB left
[19:25:41] * elenril rage
[19:26:20] <mru> if gcc4.5 is out, why doesn't gcc.gnu.org say so?
[19:27:09] <mru> and the list of serious regressions is still a mile long
[19:28:09] <mru> oh well, I guess I know what my 1GHz cortex-a8 will be doing
[19:28:57] <BBB> cross-compiling for cygwin?
[19:43:24] <pJok> mru, did you expect them to actually fix faults before releasing a new version?
[19:43:30] <mru> no
[19:43:34] <mru> just saying
[19:44:31] <pJok> gcc's way of fixing a serious regression is to degrade its priority if its not fixed within two weeks anyways
[19:44:34] <BastyCDGS> hey greetz to all of thee!
[19:44:43] <pJok> regression fault*
[19:45:30] <Dark_Shikari> lol
[19:45:37] <mru> it's not a joke
[19:45:49] <Dark_Shikari> even non-jokes can be funny
[19:46:07] <BastyCDGS> seems saste isn't yet here...awaiting him because of discussion of my gsoc proposal
[19:48:49] <BastyCDGS> what's that regression? maybe i can be a bit of help
[19:49:10] <mru> I just looked at the list on their bugzilla
[19:49:13] <mru> it's long
[19:49:52] <astrange> most existed since 4.3/4.4
[19:50:04] <BBB> BastyCDGS: his name is "saste", he's usually on irc 10-12 in GMT+1, so he should be on in a little bit
[19:50:30] <BBB> oh wait you already knew his nick
[19:50:33] <mru> they seemed to lower the quality considerably with 4.3
[19:50:35] <BBB> well nevermind, he'll be on in a bit ;)
[19:50:47] <BastyCDGS> yeah he wrote a mail today to me I should be on on IRC
[19:52:50] <BastyCDGS> until he is going online maybe it's a good idea to introduce a bit of myself...you surely want to know what I want to do in ffmpeg? ;)
[19:53:16] <BastyCDGS> if you haven't read my application yet...
[19:53:25] <mru> nah, you'll fail just like the rest :-)
[19:54:07] <BastyCDGS> i want to do the resampling stuff...
[19:54:59] <BastyCDGS> but he asked me to do a qualification task first
[19:55:12] <BastyCDGS> so I took a look and decided to do IFF-ANIM
[19:55:28] <BastyCDGS> since I'm coming from the amiga and have huge experience there with m68k asm
[19:56:00] <BastyCDGS> reading the description of this task showed me that reverse engineering is required where i'm experienced with
[19:56:30] <mru> well, go ahead, show us what you can do
[19:56:47] <Dark_Shikari> which task are you doing again?
[19:57:10] <BastyCDGS> qualification: IFF-ANIM, main-task: write a multi-channel mixing engine
[19:57:24] <BastyCDGS> with resampling capabilities
[19:58:19] <BastyCDGS> I already did a mixing engine and a module playback engine on amiga times
[19:58:56] <BastyCDGS> it can handle 1-65535 channels, 8-bit vol/pan, 1-32 bit samples (even odd bit depths like 17 bit and 23, 5, etc.)
[19:59:18] <BastyCDGS> output is always 32-bit signed right now
[19:59:57] <BastyCDGS> source code for amiga is available here:
[20:00:01] <BastyCDGS> http://forum.cdgs-crew.com/viewforum.php?f=11
[20:00:18] <BastyCDGS> including a brief description of my sound tracker
[20:00:50] <BBB> you know we already have a resampler right?
[20:01:01] <BBB> Michael emailed to ffmpeg-soc that he was interested in the mod decoding
[20:01:24] <BBB> the resampler is in libavcodec/resample.c and libavcodec/audioconvert.c
[20:01:29] <BastyCDGS> yeah but I read also that it needs improvement
[20:01:38] <BBB> right, but then you wouldn't rewrite it
[20:01:38] <kierank> stupid question but what's the difference between using a 1-channel resampler multiple times and a "multichannel resampler"?
[20:01:42] <BBB> you would improve it :)
[20:01:49] <mru> the resampler should be mostly ok
[20:01:56] <Dark_Shikari> kierank: changing number of samples
[20:01:57] <BBB> the converter needs improvement, yeah
[20:01:58] <mru> the format conversion needs some love
[20:02:01] <Dark_Shikari> mru: it's an awesome resampler!
[20:02:07] <Dark_Shikari> it has AUDIOPHILE_KIDDY_MODE ;)
[20:02:11] <mru> yeah
[20:02:14] <BBB> lol :)
[20:02:23] <Dark_Shikari> CONFIG_AUDIOPHILE_KIDDY_MODE
[20:02:25] <Dark_Shikari> best #define ever
[20:02:25] <BastyCDGS> :D
[20:02:35] <BastyCDGS> i agree to that
[20:03:37] <BastyCDGS> so i'll add an CONFIG_AUDIOPHILE_ADOLESCENT_MODE :D
[20:04:12] <BastyCDGS> I'll also would be glad to see libavcodec able to playback TuComposer modules
[20:04:18] <BBB> ok, now, seriously, BastyCDGS, so the resampler is quite fine I think, if you have specifics you'd like to improve we'd love to hear it, but the initial task was optimization of the audio conversion, which is also jai's project...
[20:04:31] <BBB> BastyCDGS: so what is your exact plan w.r.t. the audio conversion optimizations?
[20:04:37] <BBB> (or that task as a whole)
[20:04:56] <BBB> BastyCDGS: and would you be interested in doing the mod decoder for ffmpeg instead? you seem to have the expertise for that
[20:05:15] <BastyCDGS> i wanted to do both anyway
[20:05:21] <BBB> that's even better :)
[20:05:34] <BBB> so, have a look at libavcodec/audioconvert.c, so you get an idea of what it does
[20:05:37] <BBB> and why it sucks
[20:05:42] <BastyCDGS> so if jai has the resampler stuff it's probably a great idea to let him do that and me concencrating on mod stuff
[20:05:51] <BBB> ok
[20:06:05] <BBB> so ideally the mod playback would not just be linking an external library into ffmpeg
[20:06:12] <BBB> but it would actually be a new, C implementation in ffmpeg
[20:06:25] <BastyCDGS> tucomposer's mod engine is already C
[20:06:35] <BastyCDGS> back-ported from my original m68k code
[20:06:49] <BastyCDGS> because i noticed that m68k assembly isn't portable very much ;)
[20:07:21] <BastyCDGS> hey neo
[20:07:27] <NeoSchamane> hi basty
[20:08:44] <BastyCDGS> btw, tucomposer's mod engine plays all my modules (which is over 1k) perfectly and even deals with undocumented features
[20:09:06] <BastyCDGS> it loads and playbacks currently MOD/S3M/XM/IT and futurecomposer modules
[20:09:50] <Dark_Shikari> the real fun is dealing with different channel mappings
[20:09:52] <BastyCDGS> for those don't know, futurecomposer is a very old amiga module format which mainly was used in demo scene intros
[20:11:25] <BastyCDGS> the thing is, while I have C code ready for the playback engine itself and mixing engine, the loaders aren't ported from m68k asm yet
[20:11:36] <BastyCDGS> (except the TuComposer Module loader/saver)
[20:12:08] <BastyCDGS> but porting this is more trivial although the C code may look at first a bit weird
[20:12:57] <BastyCDGS> @dark_shikari what channel mappings do you mean? stereo => 5:1 and that stuff?
[20:13:11] <Dark_Shikari> no no
[20:13:15] <Dark_Shikari> I mean the five dozen different ways to code 5.1
[20:13:17] <Dark_Shikari> or 7.1
[20:15:10] <BastyCDGS> ahh understand, the mapping to the real speakers and ensuring that output is going there where it should?
[20:15:52] <BastyCDGS> or internal sample format of 5.1 and 7.1?
[20:16:10] <CIA-81> ffmpeg: andoma * r22881 /trunk/ (3 files in 2 dirs): Add PIX_FMT_Y400A, 8bit gray, 8bit alpha
[20:16:47] <CIA-81> ffmpeg: andoma * r22882 /trunk/libavcodec/pngdec.c: pngdec: Add support for PIX_FMT_Y400A
[20:17:07] <BastyCDGS> doing a svn checkout right now...
[20:20:38] <BBB> BastyCDGS: so we'd love to have that as part of ffmpeg, if you're interested in that as a soc project
[20:20:45] <BastyCDGS> so now I'm looking at audioconvert.c
[20:20:56] <BastyCDGS> already see some stuff which has potential for optimizations
[20:20:56] <BBB> (although that wouldn't be an avfilter, that'd be a decoder in libavcodec/)
[20:21:21] <BBB> uh, yeah, that whole file can be optimized millionfold :) that was the soc task ;)
[20:21:40] <BastyCDGS> the first I noticed was the forward from zero to anything for loops
[20:21:48] <BastyCDGS> such things should be done backward to zero
[20:21:52] <mru> BS
[20:21:55] <mru> it makes no difference
[20:22:02] <BastyCDGS> the reason is that the inner loop gets faster
[20:22:12] <mru> why?
[20:22:13] <BastyCDGS> because a cmp edx,eax
[20:22:15] <BBB> they should be done in asm with sse* ?
[20:22:15] <BastyCDGS> jnz loop
[20:22:20] <BastyCDGS> can be optimized to:
[20:22:22] <BastyCDGS> dec edx
[20:22:23] <BastyCDGS> jnz loop
[20:22:29] <astrange> compilers know how to reorder loops better than you
[20:22:34] <mru> compilers usually do that
[20:22:47] <NeoSchamane> ;)
[20:23:08] <BBB> BastyCDGS: the idea for optimizations would be to use sse* on systems supporting it, see libswscale/ for an example of what that would look like
[20:23:18] <BastyCDGS> normally they should yes, but even gcc 4.4 doesn't do this
[20:23:26] <BastyCDGS> i often take a look on asm output
[20:23:35] <mru> BBB: do _not_ suggest doing like swscale
[20:23:47] <BBB> mru: ok, anything else is fine also, as long as it does sse :)
[20:23:54] <BBB> or neon, if you so please
[20:24:00] <mru> look at dsputil
[20:24:01] <mru> or fft
[20:24:38] <BastyCDGS> the backward loop also saves a sparse register
[20:24:47] <mru> btw, I know of one cpu where loops are best counted from -x to 0
[20:24:49] <BastyCDGS> which is pretty good on a low-register CPU like x86
[20:25:11] <pJok> mru, the P4?
[20:25:17] <BastyCDGS> yes that is pretty the same just that dec is replaced by inc
[20:25:28] <mru> pJok: can't say, nda
[20:25:29] <BBB> BastyCDGS: it wouldn't make much of a difference, really, one register isn't very much gain, whereas sse could probably make it 5-10-fold faster
[20:25:52] <BastyCDGS> yeah of course, but i don't see a problem with mixing both optimisations
[20:26:34] <pJok> mru, sounds evil
[20:26:49] <BBB> fair enough, just be careful what you choose to optimize, you don't want to spend hours on 0.1% while you could spend less time on 50% optims
[20:26:49] <mru> it's a weird thing
[20:26:51] <BastyCDGS> btw, I found a nice page on x86 assembly optimisations quite a time ago:
[20:26:53] <BastyCDGS> http://mark.masmcode.com/
[20:26:57] <astrange> it's not an optimization unless gcc 3.4/4.2/llvm already don't do it
[20:27:06] <mru> pJok: all instructions are 8 bits
[20:27:17] <mru> so there had to be some sacrifices
[20:27:24] <pJok> sounds even more evil
[20:27:26] <mru> it has inc but not dec
[20:27:31] <pJok> like AVR/PIC
[20:27:32] <BastyCDGS> it also deals with SSE
[20:27:36] <mru> inc wrapping to zero sets a flag
[20:28:52] <BastyCDGS> as does dec
[20:29:11] <pJok> hmm
[20:29:28] <pJok> i wonder if anyone will play around with spc
[20:30:07] <BastyCDGS> gcc does this optimisation if the loop ends at zero
[20:30:43] <BastyCDGS> but it isn't smart enough yet to reverse order the loop direction if start of loop is 0
[20:32:46] <BastyCDGS> @pJok up to now i was playing only with m68k/x86
[20:32:53] <BastyCDGS> but who knows what future will be
[20:33:34] <pJok> BastyCDGS, would be fun if ffmpeg actually got support for spc as well
[20:34:18] <BastyCDGS> if i would have a spc cpu i would do this
[20:34:59] <BastyCDGS> does ffmpeg run at all on spc right now?
[20:35:14] <BastyCDGS> i.e. is there a generic C fallback code for non-supported CPUs for all parts?
[20:40:07] <BastyCDGS> what I just noticed, what is about SAMPLE_FMT_S24?
[20:40:10] <BastyCDGS> seems to be missing
[20:40:35] <BastyCDGS> or is that converted to S32 before handling it to the converter?
[20:44:38] <BBB> there's CODEC_ID_S24LE/BE
[20:44:43] <BBB> which might b what you're looking for
[20:45:09] <BastyCDGS> ah ok thx was just wondering since 24 bit samples are quite common
[20:45:09] <BBB> there's not really any reason to support 24-bit samples while processing / filtering because you can't represent it as an actual datatype anyway
[20:45:21] <BastyCDGS> yes would slow down things
[20:47:45] <BBB> yeah, so CODEC_ID_* is what you find in files
[20:48:00] <BBB> SAMPLE_FMT_* is what these are represented as in ffmpeg after decoding
[20:48:56] <BastyCDGS> but still then, wouldn't it better to have signed samples after decoding all the times
[20:49:13] <BastyCDGS> looking at the code seems there is still some unsigned stuff after decoding
[20:49:32] <BastyCDGS> e.g. SAMPLE_FMT_U8
[20:49:48] <BBB> I don't think that one is used, really
[20:50:13] <BBB> so you can convert to it, but ffmpeg will never explicitely decode to it
[20:50:32] <BBB> I'm not really sure why it's there, I agree it's odd
[20:50:41] <BastyCDGS> then we shall remove it?
[20:50:50] <BastyCDGS> or try to remove and look if that causes harm?
[20:51:05] <BBB> it doesn't really hurt to keep it, it's only a few lines of code
[20:51:24] <BBB> but you don't want to optimize for it
[20:52:35] <BastyCDGS> well the FIXME above the CONV's states unnecessary stuff shall be removed to save some cases
[20:52:48] <BastyCDGS> or at least to put them within ifdefs
[20:53:33] <BastyCDGS> cases? sorry meant else ifs
[20:55:15] <BastyCDGS> suggestion
[20:55:35] <BastyCDGS> add sth. like: #define CONFIG_SUPPORT_U8
[20:56:03] <BastyCDGS> and embrace the unsigned stuff around the appreciate ifdef
[20:56:12] <BastyCDGS> just an idea
[20:57:39] <BastyCDGS> also the FIXME states add rounding and clipping
[21:00:08] <BastyCDGS> what about replacing these if-else if stuff with a jump table?
[21:01:20] <BastyCDGS> that's also the approach I use in the TuComposer mixing engine
[21:01:44] <mru> you're thinking too low-level
[21:01:57] <BBB> the founding/clipping is already fixed, my patch did that
[21:01:57] <mru> look at fft
[21:02:00] <BBB> I didn't apply it yet
[21:02:04] <BBB> will do soon
[21:02:15] <BBB> actually my patch doesn't fix rounding, just clipping
[21:02:16] <BBB> anyway
[21:02:22] <BastyCDGS> why? this can be done on regular C also, no need for asm with a jump-table
[21:02:24] <BBB> but yeah, look at the fft code to see what we're hoping to get
[21:02:34] <BBB> BastyCDGS: because asm can optimize stuff more than a jumptable
[21:02:49] <BastyCDGS> ah ok understand
[21:03:11] <mru> the conversions should be split into lots of functions
[21:03:14] <BBB> asm can do multiple conversions at once, or speed up float<->int conversions, etc.
[21:03:20] <mru> one for each supported pair
[21:03:38] <mru> the init function should set a function pointer to the correct one
[21:03:52] <mru> how it does that is irrelevant for speed
[21:04:03] <BastyCDGS> yes this is exactly what I do in TuComposer's mix routine
[21:04:08] <BastyCDGS> set a function pointer and just call this
[21:04:23] <BBB> right, and so the function pointer would be decided based on cpu flags, etc.
[21:04:39] <BBB> so for you and me, it'd call convert_float_to_int16_sse3()
[21:04:44] <mru> the init function should also call cpu-specific init functions which can provide optimised work functions if they want
[21:04:45] <BastyCDGS> sorry my term jump table was a little bit misleading on this I just noticed
[21:04:49] <BBB> instead of crappy_c_function_which_nobody_likes()
[21:05:02] <BastyCDGS> :D
[21:05:15] <BBB> and mru is awesome so he'd write a neon version
[21:05:35] <mru> BastyCDGS: we don't expect you to write all the asm versions
[21:05:47] <mru> it important thing is to get the framework in place
[21:06:14] <mru> then anyone with a minute to spare can write an asm function
[21:06:38] <BastyCDGS> well since I have a hour to spare I can write 60 asm functions then? :D
[21:07:02] <BastyCDGS> hehe
[21:07:59] <SmkMnstr> if ffmpeg NEON can encode an audio/video stream and decode an audio stream at sametime im gonna be set
[21:08:35] <SmkMnstr> ill use the c64+ for my own stuff
[21:11:38] <BastyCDGS> I see regarding to fft.c
[21:12:04] <BastyCDGS> there's a base fft.c in libavcodec and one in each cpu supported dir
[21:12:31] <BastyCDGS> I also seen that the x86/fft.c also sets func ptrs according if 3DNow! etc. is available
[21:13:23] <BastyCDGS> so I guess there shall be a similar approach for audioconvert.c
[21:13:31] <mru> yes
[21:14:42] <BastyCDGS> can I do this as base of a qualification task?
[21:14:55] <BastyCDGS> preparing all this stuff and do some asm versions?
[21:16:24] <BastyCDGS> as the main gsoc task I would do the mod stuff itself then
[21:18:25] <BastyCDGS> btw, just noticed that there's no sub dir for m68k/coldfire
[21:18:44] <BastyCDGS> so maybe I could add some m68k optimized asm code?
[21:18:54] <BastyCDGS> or isn't m68k a target platform at all?
[21:20:36] <astrange> if you write asm for it it'll become a target platform
[21:20:54] <mru> m68k is difficult
[21:21:15] <mru> gcc rarely compiles ffmpeg for it to begin with
[21:21:24] <mru> and hardware capable of running ffmpeg is rare
[21:21:59] <mru> the most common m68k hardware is probably old macs and amigas
[21:22:13] <mru> we don't support old macos or amigaos
[21:22:52] <BastyCDGS> you're right, it's probably not worth the mess anymore...
[21:23:03] <peloverde> Doesn't 68k linux still exist?
[21:23:17] <BastyCDGS> yes but as far as I know it's tagged as deprecated
[21:23:20] <BastyCDGS> even by the kernel
[21:23:20] <BBB> BastyCDGS: if you prepare that and write one optimized function, that's enough as qualification for sure... don't forget deadline is 4/21
[21:23:21] <mru> and running linux on those machines is fraught with peril
[21:24:25] <BBB> BastyCDGS: make sure you have my patch or you'll be optimizing some old version
[21:24:57] <BastyCDGS> then I will do this, or have I to wait for saste agreeing on this?
[21:25:15] <BBB> email him to make sure
[21:25:20] <BBB> I don't think he'd mentor the mod decoder
[21:25:23] <BBB> I'm not sure who would
[21:25:25] <BBB> but we'd find someone
[21:25:31] <BastyCDGS> btw, what's the best way of submitting patches?
[21:25:32] <BastyCDGS> ml?
[21:25:34] <BBB> email ffmpeg-soc@ and ask who would like to mentor it
[21:25:46] <BBB> ml, yes, ffmpeg-devel@ or (if you prefer) ffmpeg-soc@, where review will be a bit kinder
[21:25:56] <BBB> don't be angry if review is harsh, it just is ;)
[21:25:56] <BastyCDGS> or shall I straight forward do a svn ci?
[21:26:04] <BBB> you don't have permission :-p
[21:26:20] <BBB> (try, it'll say "permission denied" or ask for a password)
[21:26:37] <BastyCDGS> then I'll try 1234 as in the spaceballs movie as pw :D
[21:26:50] * BBB quickly changes his password
[21:26:55] <BastyCDGS> lol
[21:28:16] <BastyCDGS> so I'll send this log as mail to saste let him read it and decide
[21:29:07] <BastyCDGS> is there anything special I should take care off when submitting patches (e.g. special command line params for patch)?
[21:29:33] <BBB> patcheck
[21:29:35] <BBB> in ... tests/?
[21:29:41] <BastyCDGS> ok thx
[21:29:45] <BBB> tests for common formatting mistakes in patches
[21:31:02] <BBB> but email ffmpeg-soc@ so we can find a mentor for you
[21:31:19] <BBB> I can't think of an obvious one fro the top of my head, but shouldn't be a big issue
[21:32:14] <BastyCDGS> found that file but it was in tools not in tests
[21:32:40] <BBB> oh right, well that one
[21:33:43] <BastyCDGS> 7 days until deadline is more than enough, since i have vacation until that date
[21:34:34] <BastyCDGS> I think I'll require 1-2 days for getting into it and another 1-2 days for writing and testing
[21:35:00] <BastyCDGS> what is the best way with testing the actual routines (ffmpeg cmd line switches or alike that)
[21:35:08] <BastyCDGS> to be sure that my functions are actually called?
[21:35:14] <BBB> add a printf()?
[21:35:16] <BBB> or a break in gdb
[21:35:51] <BastyCDGS> yes of course, then I'll see when they are called but I want to know how to get them called initially
[21:36:06] <BastyCDGS> can i simply launch a conversion of a WAV lets say from 32 to 16 bit?
[21:36:11] <mru> yes
[21:36:22] <mru> if not, make that part of the task too
[21:36:38] <BastyCDGS> hehe
[21:37:56] <BastyCDGS> i haven't any 32 bit wavs out of place but I can easily create one using TuComposer
[21:38:28] <mru> or with ffmpeg
[21:39:40] <BastyCDGS> ok just to summarize up:
[21:40:02] <BastyCDGS> 1. prepare the framework
[21:40:10] <BastyCDGS> 2. create 1-3 asm functions
[21:40:20] <BastyCDGS> will probably do most common ones, 8, 16 and 32 bit)
[21:40:35] <BBB> forget about the 8-bit one
[21:40:41] <BBB> just 16<->32 would be awesome
[21:40:49] <mru> float to 16-bit is by far the most important
[21:40:49] <BBB> and then we'll fight about int16<->floa
[21:40:58] <BBB> mru: yes but we were fighting over that one ;)
[21:41:08] <mru> I'm not fighting, I'm right
[21:41:13] <BBB> yes you are
[21:41:23] <mru> then you misunderstood me
[21:41:35] <BBB> huh? no, I say "yes you are right"
[21:41:49] <BBB> I just hope I'm not the one that has to implement that idea ;)
[21:41:52] <mru> I thought you said "yes .. fighting"
[21:42:16] <mru> you mean the idea that the old codecs already use?
[21:42:22] <BastyCDGS> fighting like the black knight in monty python? :D
[21:42:36] <BBB> mru: yes that one, also don't forget the conversion function should clip
[21:42:44] <BBB> mru: new codecs don't do that anymore
[21:42:57] <mru> and that's where they need to change a little
[21:43:04] <mru> they need to accept a scale parameter
[21:43:12] <BBB> yes
[21:43:22] <BastyCDGS> clipping from float to int16 shouldn't be that hard just clip +/- 1.0 to -32768 and 32767
[21:43:23] <mru> when it's easy to do
[21:43:39] <BBB> mru: right... but the caller / converter should clip
[21:43:48] <BBB> dsputil.int16_to_float doesn't do that
[21:43:56] <mru> yes it does
[21:43:57] <BBB> er, the other way around
[21:44:01] <BBB> float_to_int16 doesn't
[21:44:03] <BBB> oh it does?
[21:44:06] <BBB> I didn't know that
[21:44:07] <mru> that's the one that does
[21:44:15] <BBB> maybe wmadec does i doubly then
[21:44:17] <BBB> need to check again
[21:44:21] <BastyCDGS> btw, tell me when you have updated audioconvert.c
[21:44:25] <BastyCDGS> so I again can checkout
[21:44:27] <mru> wmapro outputs float
[21:44:33] <mru> which goes through the crappy converter
[21:44:37] <mru> which doesn't clip
[21:44:55] <BBB> BastyCDGS: see patch in "[PATCH] audio conversion clipping/overflows" thread
[21:45:22] <mru> wow, I whacked gcc devs with c99 spec and it stuck
[21:47:18] <Dark_Shikari> ?
[21:47:26] <mru> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721
[21:48:40] <Dark_Shikari> woot
[21:48:47] <mru> fun fact: ppc doesn't trap on div by 0
[21:49:16] <BastyCDGS> i agree to you, expecting a behaviour on div0 violates C std.
[21:49:28] <BastyCDGS> AFAIK this is true for all C standards not just C99
[21:51:19] <BastyCDGS> and even for C++
[21:52:24] <Dark_Shikari> nasal demons?
[21:54:05] <BastyCDGS> just remembering
[21:54:10] <BastyCDGS> this is for integer div0
[21:54:18] <BastyCDGS> fp div0 is well-defined in IEEE
[21:54:55] <BBB> there's no % operator in float really
[21:54:57] <BastyCDGS> if I'm remembering correctly either result shall be +/- inf or NaN (not exactly sure)
[21:55:05] <mru> BBB: only in javascript
[21:55:21] <mru> 0/0 = nan
[21:56:00] <mru> +/0 = +inf
[21:56:04] <mru> -/0 = -inf
[21:56:17] <mru> don't remember what 1/-0 is defined as
[21:58:02] <BastyCDGS> intuitively I would say -inf
[21:58:09] <BastyCDGS> -1/-0 = +inf
[21:58:23] <mru> negative zeros are evil anyway
[21:58:32] <Dark_Shikari> it makes if( x == 0 ) hard
[21:58:38] <Dark_Shikari> or at least annoying
[21:58:48] <mru> bitmask
[21:58:49] <BastyCDGS> yes I haven't ever heard of somebody really using this
[21:58:53] <Dark_Shikari> Yeah, bitmask works
[21:58:56] <Dark_Shikari> just more immediate bits
[21:59:03] <BastyCDGS> or fabs(x) == 0.0
[21:59:07] <mru> ugh
[21:59:10] <BastyCDGS> :D
[21:59:21] <mru> shift left one and test for zero
[21:59:21] <BastyCDGS> but looks really lame i know
[21:59:25] <Dark_Shikari> fabs *is* faster than abs ;)
[21:59:36] <Dark_Shikari> clearly we should use one's complement for all data
[21:59:39] <mru> if shift also sets flags
[22:00:51] <BastyCDGS> luckily I doesn't happen that often that you have to divide some value by george w. bush's IQ :D
[22:01:19] <mru> well, suppose you need to calculate wars/iq
[22:01:49] <Dark_Shikari> how about pretzels/iq
[22:02:01] <mru> wars/pretzel
[22:02:46] <BastyCDGS> oh yeah you're right, for dividing by bush's IQ we have to introduce complex numbers
[22:02:57] <BastyCDGS> oops dragging sqrt
[22:05:59] <BastyCDGS> what about if ( x == 0.0 || x == -0.0 )?
[22:06:21] <mru> never compare floats for equality
[22:06:51] <SmkMnstr> if (!x<=0 && !x>=0)
[22:06:57] <BastyCDGS> depends on use case, i know that you normally should use epsilon comparision
[22:07:27] <mru> no, you should write your code so don't need to compare in the first place
[22:07:55] <BastyCDGS> luckily I barely use float at all, i prefer fixed-point integers
[22:08:02] <SmkMnstr> u have to do screwy stuff like that for nan and infin/-infin
[22:08:09] <SmkMnstr> dont quite recall details
[22:08:10] <mru> float is often faster than fixed-point
[22:08:25] <BastyCDGS> when you need log and sqrt and that stuff yes
[22:08:29] <BastyCDGS> if you do only add/muls not
[22:08:37] <mru> depends on the hardware
[22:08:50] <SmkMnstr> i do relatively few logs, so i can do the rest as muls
[22:08:52] <BastyCDGS> is there really hw out there where one fpu cycle is faster than an int?
[22:08:52] <BBB> most audio filters and codecs will use sqrt/log/etc
[22:09:07] <SmkMnstr> or adds
[22:09:16] <mru> a fixed-point mul requires a normalising shift
[22:09:50] <BastyCDGS> a 32x32 (64 bit fixed with 32 bit prec) doesn't require a shift
[22:09:50] <mru> and float ops use a different execution unit
[22:10:02] <BastyCDGS> if its a 32-bit CPU and has a 32x32=64 mul instruction
[22:10:02] <mru> so you can do some integer stuff for free in the meantime
[22:10:15] <mru> pointers, loop control etc
[22:10:16] <BastyCDGS> you then can simply use the reg which stores the upper 32-bits
[22:10:30] <mru> if the shift were exactly 32, yes
[22:10:46] <mru> but such multiplications are as slow as float
[22:12:14] <BastyCDGS> after all it heavily depends on target CPU
[22:12:40] <mru> I'm assuming one with decent hardware fpu
[22:12:51] <BastyCDGS> then the point goes to you...
[22:13:17] <mru> fixed-point is obviously faster if you don't have an fpu
[22:13:59] <BBB> most fixed-ints don't use 32-bit shifts exactly anyway, e.g. MS uses 31/30 in their fixed codecs
[22:14:13] <BBB> and I'd guess their market share is big enough to be significant
[22:14:20] <BBB> poor suckets having bought into windows mobile :)
[22:14:29] <BastyCDGS> hehe
[22:14:59] <BastyCDGS> now I know why their stuff is such slow :D
[22:15:22] <BastyCDGS> wonder they don't use BCD during the whole OS sometimes haha
[22:17:17] <BastyCDGS> btw, since I'm still running hardy (8.04) are there some dependencies I've to take care when compiling ffmpeg SVN?
[22:18:55] <mru> gnu make 3.81, decent gcc
[22:19:42] <BastyCDGS> make is exactly 3.81
[22:19:48] <mru> that's the latest
[22:19:58] <BastyCDGS> gcc is 4.2.4
[22:20:03] <mru> should be fine
[22:20:35] <BastyCDGS> I'll do a test build now
[22:21:37] <peloverde> make sure you have yasm
[22:22:20] <peloverde> Also I think hardy's yasm is too old
[22:22:33] <BastyCDGS> thank you for mentioning this I hadn't yasm installed
[22:23:31] <BastyCDGS> seems you're right
[22:23:32] <BastyCDGS> http://ubuntuforums.org/showpost.php?p=6963607&postcount=360
[22:25:22] <peloverde> yasm 1.0 is out? sweet!
[22:25:34] <BastyCDGS> just building it right now ;)
[22:28:21] <BastyCDGS> works yeah
[22:28:40] <BastyCDGS> yasm 1.0.0.2319
[22:29:19] <peloverde> most of the best x86 assembly requires yasm
[22:31:53] <BBB> fft is yasm?
[22:32:05] <BastyCDGS> yasm was unknown to me, I was using nasm instead
[22:34:11] <BastyCDGS> still building ffmpeg...
[22:34:23] <BastyCDGS> configure detected compiled yasm should be fine
[22:37:24] <astrange> yasm is syntax compatible with nasm but more up to date
[22:39:54] <BastyCDGS> just wondering is the yasm stuff done at the end? because console output just says CC        xyz.c
[22:39:56] <BastyCDGS> upto now
[22:40:16] <BastyCDGS> ok question answered
[22:40:18] <mru> alphabetical order I think
[22:40:28] <mru> x86/* comes near the end
[22:41:26] <BastyCDGS> ahh ok
[22:41:37] <BastyCDGS> have just seen a yasm line
[22:42:22] <BastyCDGS> taadaaa, finished, seems good:
[22:42:26] <BastyCDGS> basty at cdgs-basty:~/src/ffmpeg/build$ ./ffmpeg --help
[22:42:26] <BastyCDGS> FFmpeg version SVN-r22882, Copyright (c) 2000-2010 the FFmpeg developers
[22:42:26] <BastyCDGS>   built on Apr 15 2010 00:40:39 with gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
[22:42:26] <BastyCDGS>   configuration:
[22:44:04] <BastyCDGS> so building works now, then I'll apply the clipping patch
[22:46:13] <bcoudurier> hi guys
[22:46:26] <BastyCDGS> hi
[22:49:04] <Dark_Shikari> hi bcoudurier's onjoin script
[22:54:28] <BastyCDGS> so have found your patch in march archive
[22:54:45] <BastyCDGS> but wondering that there's no patch file, just see the text and the patch as a quoted message
[22:54:49] <BastyCDGS> did I miss sth.?
[22:56:54] <BastyCDGS> I only see the PGP signature (189 bytes as downloadable attachment)
[22:57:59] <BastyCDGS> ahh is it that?
[22:58:03] <BastyCDGS> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100315/8513ea8e/attachment.bin
[23:00:03] <BastyCDGS> hmm says failed in one file:
[23:00:21] <BastyCDGS> basty at cdgs-basty:~/src$ patch -p0 < ffmpeg-svn/patches/attachment.bin
[23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavcodec/audioconvert.c
[23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavutil/common.h
[23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavcodec/amrnbdec.c
[23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavcodec/qcelpdata.h
[23:00:22] <BastyCDGS> patching file ffmpeg-svn/libavcodec/ra288.c
[23:00:22] <BastyCDGS> patching file ffmpeg-svn/libavcodec/sipr.c
[23:00:23] <BastyCDGS> patching file ffmpeg-svn/libavcodec/twinvq.c
[23:00:23] <BastyCDGS> patching file ffmpeg-svn/libavcodec/wmaprodec.c
[23:00:24] <BastyCDGS> Hunk #1 FAILED at 1351.
[23:00:24] <BastyCDGS> 1 out of 1 hunk FAILED -- saving rejects to file ffmpeg-svn/libavcodec/wmaprodec.c.rej
[23:00:25] <BastyCDGS> patching file ffmpeg-svn/libavcodec/atrac1.c
[23:00:25] <BastyCDGS> patching file ffmpeg-svn/libavcodec/qcelpdec.c
[23:00:26] <BastyCDGS> patching file ffmpeg-svn/libavcodec/wmavoice.c
[23:00:42] <mru> never paste that much into the channel
[23:00:48] <BastyCDGS> oh ok sorry
[23:01:58] <BastyCDGS> should I care about the failed hunk?
[23:02:09] <mru> of course you should
[23:02:19] <mru> probably someone edited the file after the patch was made
[23:02:27] <mru> you'll have to look and see
[23:02:38] <mru> you can probably figure out how to make the change manually
[23:04:30] <BastyCDGS> just doing this and it looks that the guy who edited it has changed the for to a while
[23:04:42] <BastyCDGS> but your patch (call to clipping func) is included
[23:05:32] <BastyCDGS> av_clipf
[23:05:53] <BastyCDGS> so I guess it's okay to ignore that failure
[23:06:48] <BastyCDGS> will do a rebuild now
[23:08:50] <BastyCDGS> if that's successful again then I think I can begin coding
[23:08:58] <Dark_Shikari> hmm.  why the fuck is prefetch like the only instruction on x86 that doesn't take complex addressing
[23:09:04] <Dark_Shikari> Either that or gcc can't use it
[23:09:18] <Dark_Shikari> it only seems to be using [REG + CONST]
[23:09:53] <BastyCDGS> not sure about this, but maybe the adressing mode is dependant of the target CPU?
[23:10:03] <Dark_Shikari> not since 386
[23:10:37] <Dark_Shikari> oh god, mru, you'll lol at this
[23:10:41] <Dark_Shikari> actual code generated by gcc
[23:10:46] <Dark_Shikari> mov    edi,0x80808080
[23:10:46] <Dark_Shikari> mov    [ecx+0x4804],eax
[23:10:46] <Dark_Shikari> mov    eax,0x80808080
[23:10:46] <Dark_Shikari> mov    [ecx+0x4af0],edx
[23:10:46] <Dark_Shikari> mov    edx,0x80808080
[23:10:48] <Dark_Shikari> mov    [ecx+0x482c],edi
[23:11:08] <Dark_Shikari> (ad infinitum)
[23:11:33] <BastyCDGS> lol
[23:11:44] <Dark_Shikari> Let's keep storing the same constant value repeatedly in different registers!
[23:11:45] <BastyCDGS> i see
[23:12:01] <Dark_Shikari> It really seems to like this for some reason
[23:12:05] <Dark_Shikari> it won't optimize out repeated constants
[23:12:25] <astrange> prefetchtX stores the X in part of the address byte
[23:12:37] <BastyCDGS> maybe gcc decided that it's faster to leave the constant in the src param and have one more reg available?
[23:12:49] <Dark_Shikari> BastyCDGS: but it wastes tons of registers!
[23:12:57] <Dark_Shikari> this is for the purpose of storing the same value to mem repeatedly
[23:13:07] <mru> and it wastes tons of instruction space
[23:13:10] <Dark_Shikari> That too
[23:13:19] <Dark_Shikari> astrange: ah so it only does -128 -> 127 offsets?
[23:13:38] <BastyCDGS> gcc version is?
[23:13:55] <BastyCDGS> 4.2.4 does some weird stuff for me too...4.4 is much better regarding this
[23:14:06] <mru> 4.4 is a very mixed bag
[23:14:15] <mru> sometimes it produces 25% slower code
[23:14:28] <Dark_Shikari> 3.4 here
[23:14:31] <Dark_Shikari> so yeah, partially my fault =p
[23:14:48] <BastyCDGS> from where the asm code originates?
[23:14:55] <Dark_Shikari> gcc 3.4
[23:14:57] <BastyCDGS> (want to try gcc 4.2.4 on this src)
[23:15:03] <Dark_Shikari> oh, local changes to x264
[23:15:07] <Dark_Shikari> to add prefetching to cache handling
[23:15:20] <Dark_Shikari> to cut down on those obnoxious L2 -> L1 misses
[23:16:14] <Dark_Shikari> oh nice, gcc 4 does something _equally_ dumb, but totally different
[23:16:58] <Dark_Shikari> c7 40 04 80 80 80 80            mov    dword[eax+0x4],0x80808080
[23:16:58] <Dark_Shikari> 8b 94 24 b0 00 00 00            mov    edx,[esp+0xb0]
[23:16:58] <Dark_Shikari> c7 82 18 48 00 00 80 80 80 80   mov    dword[edx+0x4818],0x80808080
[23:16:58] <Dark_Shikari> c7 40 18 80 80 80 80            mov    dword[eax+0x18],0x80808080
[23:17:06] <Dark_Shikari> yes, that's right, that's a 10-byte opcode!
[23:17:18] <BastyCDGS> crazy
[23:17:27] <Dark_Shikari> Everyone knows that storing a value to memory over and over should be done using immediates!
[23:17:36] <Dark_Shikari> 4.3.4
[23:18:02] <BastyCDGS> 10 byte op-codes should be avoided at all
[23:18:08] <astrange> the x86 backend tries to duplicate constants because it can't deal with register pressure well
[23:18:25] <Dark_Shikari> :/
[23:18:37] <astrange> and it doesn't have the real fix for this (rematerialization pass)
[23:18:43] <Dark_Shikari> what's that?
[23:19:03] <BastyCDGS> maybe you can manually fix it by sth line:
[23:19:14] <BastyCDGS> const uint32_t myval = 0x80808080;
[23:19:14] <astrange> http://en.wikipedia.org/wiki/Rematerialization
[23:19:17] <BastyCDGS> for (...) {
[23:19:19] <BastyCDGS> ...
[23:19:22] <astrange> basically that but only when necessary
[23:19:27] <Dark_Shikari> BastyCDGS: you'd probably need to do uint32_t myval = ...
[23:19:32] <Dark_Shikari> to make it impossible to optimize
[23:19:48] <BastyCDGS> i mean move the const out of the loop by hand
[23:20:18] <Dark_Shikari> it isn't a loop
[23:20:23] <BastyCDGS> oh ok
[23:20:24] <Dark_Shikari> and gcc may still optimize it away
[23:20:55] <Dark_Shikari> so, I'm getting the feeling that there's at least 5%+ performance to be had in x264 just by killing L1 misses
[23:21:26] <pengvado> prefetch takes the same kinds of addresses as anything else, gcc is just being stupid
[23:21:28] <BastyCDGS> could you post the C code which causes that crazy code?
[23:22:13] <BastyCDGS> btw, ffmpeg just compiled fine with the applied clipping patch
[23:22:14] <Dark_Shikari> pengvado: *headdesk*
[23:22:26] <Dark_Shikari> BastyCDGS: store any constant repeatedly to multiple memory addresses
[23:22:35] <Dark_Shikari> pengvado: so you're saying if I used inline asm, it'd go away?
[23:23:11] <BastyCDGS> it surely would, but I would call this a somewhat ugly hack
[23:23:36] <Dark_Shikari> inline asm is an ugly hack?
[23:23:38] <Dark_Shikari> better not work on ffmpeg then
[23:23:48] <astrange> http://i.imgur.com/nmFca.png it's not the same addresses
[23:23:50] <BastyCDGS> not in general of coz
[23:23:56] <BastyCDGS> but for such a thing
[23:24:00] <astrange> http://pastebin.org/151566 and the gcc constant thing
[23:24:08] <Dark_Shikari> asm volatile("prefetch %0":"m"(p));
[23:24:12] <astrange> it will unduplicate constants that need movabsq
[23:24:15] <Dark_Shikari> how do I make gcc like this?
[23:24:19] <Dark_Shikari> it thinks p is an output value
[23:24:21] <Dark_Shikari> prefetch has no output
[23:24:25] <Dark_Shikari> I've never made an asm block with no output before
[23:24:34] <astrange> ::"m"(*p)
[23:25:56] <Dark_Shikari> astrange: wait
[23:26:01] <Dark_Shikari> what's the difference between prefetch and prefetcht etc
[23:26:12] <Dark_Shikari>  2aee:       0f 0d 44 c1 0c          prefetch byte[ecx+eax*8+0xc] works
[23:26:22] <pengvado> astrange: then gas is broken for not warning when I give complex addresses to prefetch
[23:28:36] <astrange> 0f 0d? http://ref.x86asm.net/geek32.html#x0F0D gives that as nop
[23:29:00] <pengvado> the difference is that prefetch and prefetchw are 3dnow, while prefetch{t0,t1,t2,nta} are mmx2
[23:29:16] <BastyCDGS> 0d 0f
[23:29:21] <BastyCDGS> little endian
[23:29:52] <astrange> 0d is orb
[23:29:58] <astrange> against ax
[23:30:06] <Dark_Shikari> pengvado: ahhhhh
[23:30:08] <astrange> ah, 3dnow. this is an intel manual
[23:30:12] <Dark_Shikari> so "prefetch" is better address-coding-wise
[23:30:47] <Dark_Shikari> But only available on AMD?
[23:31:09] <Dark_Shikari> someone explain this.  I just ran x264 with "prefetch" being used
[23:31:11] <Dark_Shikari> .... on my core i7
[23:31:29] <Dark_Shikari> How does that work?
[23:31:32] <Dark_Shikari> No SIGILL.
[23:31:46] <Dark_Shikari> and what's with gcc doing stuff like this
[23:31:47] <Dark_Shikari>     2b04:       01 f8                   add    eax,edi
[23:31:47] <Dark_Shikari>     2b06:       0f 0d 00                prefetch byte[eax]
[23:31:51] <pengvado> as astrange says, the intel manual calls it a nop, and prefetch doesn't actually do anything from a program correctness pov, so it should work.
[23:32:18] <Dark_Shikari> But obviously being a nop on intel, it's rather bad.
[23:32:35] <Dark_Shikari> So, what's the verdict on prefetcht0 with non-m8 addresses?
[23:33:55] <BastyCDGS> searching on the link above for prefetch doesn't find any matches, is prefetch[t?] AMD only
[23:34:10] <Dark_Shikari> 3dnow, as we said above
[23:34:17] <pengvado> umm, m8 refers to the size of the operand, not the address
[23:34:33] <pengvado> i.e. it means char* as opposed to int*
[23:34:35] <Dark_Shikari> ah
[23:35:13] <Dark_Shikari> Wait, so does http://i.imgur.com/nmFca.png allow full addresses or not?
[23:35:39] <BastyCDGS> here's an example of prefetch (10 prefetching data):
[23:35:42] <BastyCDGS> http://mark.masmcode.com/
[23:36:17] <BastyCDGS> the site says prefetch is available starting from p3 hmm
[23:36:21] <Dark_Shikari> yes, mmx2
[23:39:08] <BastyCDGS> so there are two different prefetches one for 3dnow and one for mmx2
[23:39:15] <Dark_Shikari> More than 2!
[23:39:16] <Dark_Shikari> more like 6!
[23:39:16] <BastyCDGS> maybe you have to tell gcc to use the mmx2 version
[23:39:22] <Dark_Shikari> no, it uses the mmx by default
[23:39:42] <BastyCDGS> I'm not sure about this maybe it uses host CPU as default
[23:39:59] <BastyCDGS> if you have an 3dnow cpu so it might use 3dnow version?
[23:40:14] <Dark_Shikari> no, it uses what you set -march for
[23:40:15] <Dark_Shikari> Also
[23:40:19] <Dark_Shikari> pengvado: this is interesting
[23:40:27] <Dark_Shikari> with gcc 4.3.4, it uses the complex addressing mode...
[23:40:29] <Dark_Shikari> ... just incredibly badly
[23:40:41] <Dark_Shikari> it'll do "eax+esi" and on the next line do "sub eax, 1"  "prefetch eax"
[23:40:48] <Dark_Shikari> It does things Right if you use inline asm.
[23:41:53] <BastyCDGS> yes but i didn't know what you set -march to or even used it at all sorry
[23:41:59] <Dark_Shikari> -march=i686
[23:42:54] <BastyCDGS> this is equal to march=pentiumpro
[23:43:11] <mru> +mmx
[23:43:28] <mru> or not
[23:43:31] <mru> intel is confusing
[23:43:49] <BastyCDGS> could you try march=pentium4 and compare that?
[23:43:58] <mru> lol
[23:44:31] <Kovensky> chrome is built with march=pentium4
[23:44:37] <mru> rotfl
[23:45:15] <BastyCDGS> I mean just to be sure if it's not that
[23:45:57] <BastyCDGS> pentiumpro is mmx but we need mmx2, right?
[23:46:01] <BastyCDGS> that's why I had this idea
[23:46:07] <BastyCDGS> pentium4 will ensure even sse
[23:46:39] <Dark_Shikari> we use -msse
[23:46:46] <pengvado> I think the "use of any ModR/M value other than the specified ones" is referring to the fact that there are only 4 prefetch modes (nta,t0,t1,t2) encoded using 3 bits. thus the other 4 syntactically possible values are undefined.
[23:46:55] <Dark_Shikari> pengvado: ahhhh k
[23:49:07] <BastyCDGS> or give this a try:
[23:49:10] <BastyCDGS> -march=i686 -mtune=pentium3
[23:51:43] <BastyCDGS> was doing some research, according to wikipedia p3 has x86, mmx and sse instruction set
[23:51:48] <BastyCDGS> while pentium pro just hast x86
[23:51:58] <mru> sounds about right
[23:52:04] <mru> p2 was ppro+mmx iirc
[23:52:22] <BastyCDGS> if you use march=i686 it just uses x86 maybe even if you force gcc to sse?
[23:52:48] <BastyCDGS> so give at least a march=pentium3 a try
[23:53:19] <mru> -msse and friends override -march
[23:56:21] <BastyCDGS> maybe it confuses gcc if you use msse with a march which doesn't support it?
[23:57:17] <BastyCDGS> http://gcc.gnu.org/ml/gcc-help/2007-09/msg00188.html
[23:57:51] <BastyCDGS> gcc mailing lists warns about such things, too.