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

[irc at mansr.com]

[00:00:15] <mru> the file decodes in 16.2s
[00:01:12] <mru> 13.2s with coreavc
[00:01:20] <Dark_Shikari> well what matters is the peak per-frame time
[00:01:23] <Dark_Shikari> it has to finish before the next frame comes
[00:01:28] <mru> I can't easily measure that
[00:01:31] <mru> just buffer more
[00:01:41] <Dark_Shikari> we can't buffer at all
[00:01:44] <mru> ouch
[00:01:47] <Dark_Shikari> and so many slices ---> because one slice per packet
[00:01:49] <Dark_Shikari> udp
[00:01:58] <mru> the gaming thing?
[00:02:00] <Dark_Shikari> yes
[00:02:04] <Dark_Shikari> they want to do it on ipad.
[00:02:10] <Dark_Shikari> they're getting 60ms per frame in high motion for full-res ipad
[00:02:11] <saintdev> cool
[00:02:26] <Dark_Shikari> Which means they either have to drop fps to 15fps or drop resolution to 640x480
[00:02:30] <Dark_Shikari> Either sucks
[00:03:02] <Dark_Shikari> Note they could, if they wanted, disable cabac or deblocking
[00:03:25] <Dark_Shikari> oh, mru, you think you could write an ARM version of deblock strength calculation?
[00:03:28] <Dark_Shikari> currently it's only for mmx
[00:03:31] <Dark_Shikari> They could probably pay.
[00:04:16] <mru> how much would that gain?
[00:04:59] <Dark_Shikari> A lot
[00:05:09] <Dark_Shikari> more than any other single asm function by a full order of magnitude (of those left to write)
[00:05:16] <Dark_Shikari> its the cornerstone of filter_mb_fast
[00:05:19] <Dark_Shikari> I would guess >10%
[00:05:38] <Dark_Shikari> you can easily check just by profiling and measuring the time spent in the C portion of deblocking code
[00:05:39] <mru> what is the c function called?
[00:05:44] <Dark_Shikari> There is none
[00:06:04] <mru> the top function on that clip is ff_h264_decode_mb_cabac
[00:06:07] <mru> 8%
[00:06:29] <Dark_Shikari> h->h264dsp.h264_loop_filter_strength
[00:06:40] <mru> and what's the C version of that called?
[00:06:46] <Dark_Shikari> ff_h264_filter_mb vs ff_h264_filter_mb_fast
[00:06:47] <mru> I'm staring at the oprofile output
[00:06:51] <mru> but I don't see anything
[00:06:54] <Dark_Shikari> the latter is a thin wrapper around loop_filter_strength
[00:06:58] <Dark_Shikari> the former is very complex and messy.
[00:07:04] <mru> ff_h264_filter_mb is 5.6%
[00:07:10] <mru> so you won't gain more than that
[00:07:18] <Dark_Shikari> oh wow, lower than I thought
[00:07:24] <Dark_Shikari> michael must have improved it a lot
[00:07:30] <Dark_Shikari> oh, it's because he does deblocking per-row now
[00:07:33] <Dark_Shikari> thus getting rid of the icache misses
[00:07:41] <Dark_Shikari> Either way, I would guess there would be a gain of about 4% then.
[00:07:45] <Dark_Shikari> Which is pretty nice regardless.
[00:07:48] <mru> sure
[00:07:48] <Dark_Shikari> for a single function
[00:07:56] <mru> I wasn't aware of this one
[00:07:56] <Dark_Shikari> ok, so I'll up a cavlc one for you to bench
[00:08:15] <Dark_Shikari> http://mirror05.x264.nl/Dark/test2.h264
[00:08:56] <Dark_Shikari> also, keep in mind we can also modify the spec (and the encoder/decoder) to make it faster if necessary.
[00:09:18] <mru> that decodes in 14.4s
[00:09:27] <Dark_Shikari> and coreavc?
[00:09:41] <mru> 10.8
[00:10:27] <mru> ff_h264_filter_mb is 7.8% now
[00:12:50] <Dark_Shikari> finally http://mirror05.x264.nl/Dark/test3.h264
[00:12:53] <Dark_Shikari> no cabac, no deblock
[00:13:02] <Dark_Shikari> also, notable properties of these streams amenable to optimization:
[00:13:07] <Dark_Shikari> 1) no sub16x16 inter partitions
[00:13:09] <Dark_Shikari> 2) no b-frames
[00:13:12] <Dark_Shikari> 3) Lots of skips
[00:14:49] <mru> 14.3s
[00:15:05] <mru> err, wrong file
[00:15:23] <mru> 10.5
[00:15:45] <mru> 8.3 with coreavc
[00:18:42] <mru> does anyone know what arm core the ipad uses?
[00:19:16] <astrange> a8 + magic power saving circuitry
[00:19:45] <mru> plain old A8?
[00:19:52] <mru> same as the TI OMAP?
[00:20:45] <astrange> yes i think so
[00:20:50] <astrange> http://www.slashgear.com/samsung-1ghz-hummingbird-mobile-cpu-takes-on-snapdragon-2750348/ it's pretty much the same as this
[00:21:17] <mru> snapdragon is a v7 but not an a8
[00:21:31] <mru> oh, yet another one
[00:21:35] <Dark_Shikari> do we know how it compares to the a8?
[00:22:03] <mru> that says the samsung one is "based on the a8"
[00:22:18] <mru> if that means it's an a8 with stuff around it or that it's a modified a8 is hard to tell
[00:23:07] <mru> I don't think samsung is an architecture licencee though
[00:23:14] <mru> which would mean it's a stock a8 from arm
[00:23:39] <astrange> "cycle-accurate and Boolean equivalent to" sounds like it's the same
[00:38:35] <Dark_Shikari> mru: do you think ffmpeg could benefit from arm cabac asm?
[00:39:11] <mru> any asm is good
[00:39:13] <Dark_Shikari> (keep in mind I can get money for all this stuff)
[00:39:19] <Dark_Shikari> just wondering how much you think it would help
[00:39:20] <astrange> yes
[00:39:25] <Dark_Shikari> the arm equivalents of the current x86 cabac asm
[00:39:29] <Dark_Shikari> i.e. sigmap decode and cabac get
[00:39:41] <astrange> the c cabac code can be improved to generate better arm code though
[00:39:59] <astrange> it should be split up for arches with and without conditional execution
[00:40:10] <astrange> that's if you can get any compiler to reliably do it, anyway...
[00:46:26] <pengvado> that's the crux, isn't it? there's nothing in the x86 cabac asm that couldn't in principle be generated by a compiler, but gcc doesn't like cmov.
[00:46:35] <mru> and the sheevaplug psu dies again...
[00:47:07] <mru> gcc often uses arm conditional execution
[00:49:36] <astrange> i think gcc 4.3+ can generate something close, it knows the sbb trick
[00:50:00] <astrange> the worst problem is that *state and cabac->bytestream are char* and alias the cabac struct
[00:57:35] <Dark_Shikari> mru: so suppose you did a contract for "write arm asm for loop filter strength, cabac, and cabac sigmap"
[00:57:40] <Dark_Shikari> how much would you quote that at?
[01:01:04] <mru> there, sheeva back in action
[01:01:06] <mru> with atx pcu
[01:01:07] <mru> psu
[01:02:14] <mru> Dark_Shikari: I'd have to have a look at the C code first
[01:04:03] <mru> what does h264dsp.h264_loop_filter_strength do?
[01:04:14] <mru> don't tell me to read the mmx code
[01:05:01] <Dark_Shikari> it calculates loop filter strength values based on mvd, nnz, and ref values
[01:05:08] <Dark_Shikari> you know the algorithm
[01:05:14] <mru> no, I don't
[01:05:23] <Dark_Shikari> if there's nnz on either side of a 4x4 block boundary, set strength for each side to 2
[01:05:40] <Dark_Shikari> else, if there's an mv difference >= 1 pixel or different ref frame, set to 1
[01:05:43] <Dark_Shikari> else, set to 0
[01:05:52] <Dark_Shikari> (and inside an intra block, set to 3, edges of an intra block, set to 4)
[01:05:56] <Dark_Shikari> but those are handled outside of the asm
[01:06:13] <Dark_Shikari> so e.g.
[01:06:13] <mru> is there any c code that does this?
[01:06:20] <Dark_Shikari> 0 | 0 | 0 | NZ | 0
[01:06:32] <Dark_Shikari> would become
[01:06:39] <Dark_Shikari>  0  0  2  2
[01:06:44] <Dark_Shikari> yes
[01:06:49] <mru> where?
[01:06:53] <Dark_Shikari> filter_mb_dir does this
[01:07:51] <Dark_Shikari> You're better off parsing the mmx at the same time you read the C
[01:07:56] <Dark_Shikari> because what the MMX does is very restrictive
[01:08:02] <Dark_Shikari> i.e. it explicitly doesn't handle many corner cases
[01:08:03] <mru> that's a hell of a lot of c code
[01:08:03] <Dark_Shikari> like, say, MBAFF
[01:08:08] <Dark_Shikari> MMX is much simpler
[01:08:15] <mru> full of loops and conditions
[01:08:26] <mru> mmx is never simple
[01:08:35] <Dark_Shikari> sure it is
[01:08:45] <Dark_Shikari> it has about a dozen different instructions in this function
[01:09:04] <Dark_Shikari> it's a mix of mmx and c so it should be rather obvious what it's doing
[01:09:36] <mru> I can't read that
[01:09:49] <Dark_Shikari> stop being retarded
[01:09:55] <mru> I don't know wtf the instructions do
[01:09:57] <Dark_Shikari> it even has comments to reference appropriate C code
[01:10:05] <mru> comments are always wrong
[01:10:08] <Dark_Shikari> No, they're right
[01:10:09] <Dark_Shikari> and stop being stupid
[01:10:15] <Dark_Shikari> seriously, you're being intentionally thick here
[01:10:16] <Dark_Shikari> stop it
[01:10:30] <mru> will not
[01:10:37] <Dark_Shikari> ....
[01:10:58] <mru> look, it's bloody mmx code I don't know the first thing about
[01:11:01] <Dark_Shikari> do you want me to walk you through it?
[01:11:06] <mru> it's gcc inline asm ugly as sin
[01:11:07] <Dark_Shikari> force-feed you the code?
[01:11:11] <Dark_Shikari> you don't need to read the asm
[01:11:19] <Dark_Shikari> you can figure out what it does without reading a line of asm
[01:11:48] <mru> if it's that easy, why don't you write a pure c function doing the same thing?
[01:11:56] <Dark_Shikari> because that would be slower than the existing c code
[01:12:11] <mru> as illustration only
[01:12:13] <Dark_Shikari> the optimal simd way is not the optimal C way
[01:12:29] <Dark_Shikari> I'll guide you through it.  I'm not the one who would be paid for this anyways
[01:12:38] <mru> and the optimal mmx way is usually very different from the optimal neon way
[01:12:46] <Dark_Shikari> no, they're pretty much the same
[01:12:53] <Dark_Shikari> each bit of asm code does a _trivial_ operation
[01:13:00] <Dark_Shikari> the only reason it's large is because there is more than one trivial operation
[01:13:02] <mru> says the man who's never written any neon
[01:13:11] <ramiro> stop biting each other
[01:13:19] <mru> mmx does a lot of things very differently
[01:13:25] <Dark_Shikari> mru: you'd do each code segment differently sure
[01:13:28] <Dark_Shikari> but you still have to _do_ the same things
[01:13:39] <Dark_Shikari> you still have to compare ref values
[01:13:41] <Dark_Shikari> you still have to compare mvs
[01:13:47] <mru> whenever you'd use pshuf in mmx you'd do something else in neon
[01:13:50] <Dark_Shikari> of course
[01:13:54] <Dark_Shikari> I told you not to read the asm
[01:13:58] <Dark_Shikari> did you listen? nooooooo
[01:14:15] <mru> HOW THE FUCK AM I SUPPOSED TO KNOW WHAT THE CODE DOES THEN?
[01:14:16] <mru> GUESS?
[01:14:21] <Dark_Shikari> I offered to guide you through it
[01:14:22] <Dark_Shikari> and you refused
[01:14:28] <mru> I don't have time for that crap
[01:14:30] <saintd3v> children, don't make me pull thich channel over!
[01:14:35] <saintd3v> *this
[01:14:36] <Dark_Shikari> You have time to yell at me for 10 minutes
[01:14:42] <Dark_Shikari> And you don't have time to listen to a 2 minute walkthrough?
[01:14:48] <Dark_Shikari> OK, I'll ignore you and do it anyways
[01:14:49] <Dark_Shikari> shut up.
[01:15:07] <Dark_Shikari> 1) Iterate over the two directions (horizontal and vertical)
[01:15:13] <mru> it's the middle of the fucking night, I'm tired, and I'm trying to finish up something else
[01:15:15] <Dark_Shikari> obviously, for one of them, we have to do some transposes to get what we want.
[01:15:47] <Dark_Shikari> 2) apply the MV mask, based on partition type, so we only have to check the MVs that could be different.
[01:15:51] <Dark_Shikari> This is optional, and simply a time-saving step.
[01:16:16] <Dark_Shikari> 3) Check the reference frames
[01:16:25] <Dark_Shikari> 4) Check the MV deltas across the edges
[01:16:35] <Dark_Shikari> 5) Do 2-4 for both list0 and list1
[01:16:38] <Dark_Shikari> 6) do nnz
[01:16:56] <Dark_Shikari> the big block of asm in the middle of the loop is 3-4
[01:17:11] <Dark_Shikari> the way it works is as follows:
[01:17:31] <Dark_Shikari> we have 4 edges in our macroblock we need to filter, each 16 pixels (4 4x4 blocks) long
[01:17:45] <Dark_Shikari> The edge mask tells us that we only have to filter some of these.  Say, only 2, for example.
[01:17:52] <Dark_Shikari> For each one we have to filter, we compare the MVs and refs on either side of it.
[01:17:56] <Dark_Shikari> this is done in SIMD.
[01:18:10] <Dark_Shikari> Doing the refs in simd isn't very useful, it's primarily doing the MVs that helps here.
[01:18:44] <Dark_Shikari> So at some given edge, for example, in a generic asm language:
[01:19:05] <Dark_Shikari> r0 = int16_t top_of_edge_mvs[4][2]
[01:19:11] <Dark_Shikari> r1 = int16_t bottom_of_edge_mvs[4][2]
[01:19:51] <Dark_Shikari> for each element of r0/r1, if( abs(r0[i] - r1[i]) > 4 ) r2[i]=1 else r2[i]=0
[01:20:01] <Dark_Shikari> That's the MV algorithm.
[01:20:27] <Dark_Shikari> It works similarly for NZ, where it's if( r0[i] | r1[i] ) r2[i]=2 else r2[i] = 0
[01:20:53] <Dark_Shikari> and for ref, if( r0[i] != r1[i] ) r2[i] = 1 else r2[i] = 0
[01:21:07] <Dark_Shikari> Then the greatest of all three values is selected from the outputs of each of the three processes.
[01:21:10] <Dark_Shikari> Done.
[01:21:32] <Dark_Shikari> See, it's not that bad.
[01:21:42] <Dark_Shikari> It's easily 10x less work than, say, hpel.
[01:24:12] <Dark_Shikari> if you don't like the ffmpeg c code, mru, here's the x264 C code
[01:24:13] <Dark_Shikari> http://pastebin.org/200078
[01:24:21] <Dark_Shikari> Not as optimized, but same thing (and simpler, no mbaff corner cases)
[01:24:42] <Dark_Shikari> 1) check nz on each side of boundary, 2) check ref on each side of boundary, 3) check mv on each side of boundary
[03:32:29] <KotH> salut
[06:20:28] <elenril> 'We are moving the rendering of the window decorations into the app itself, so that you don’t have the window manager and application drawing those pieces separately.'
[06:20:36] * elenril wonders wtf are the ubuntu people smoking
[06:21:24] <KotH> sauce?
[06:21:30] <elenril> http://www.markshuttleworth.com/archives/333
[06:21:31] <KotH> moin btw
[06:21:38] <elenril> o/ BofH-san
[06:22:06] <superdump> morning
[06:23:18] <KotH> elenril: well.. as i said various times in the past: the gnome, freedesktop and other people in that area have never understood and never bothered to understand what X11 is and how it works
[06:24:30] <ohsix> like they cant dare put an icon in a window property and have the window manager use it, gasp! (thats what the wm already does for the app icon, olol)
[06:24:47] <bilboed> KotH, erm, please, could you stop insulting the gnome/fdo people by confusing them with the canonical/spaceman community, thx.
[06:25:02] <ohsix> yes, they're the people doing real work
[06:27:57] <ohsix> i'm waiting for the time they rip off osx's pages for app modal dialogues :D
[06:29:03] <KotH> bilboed: sorry that i put those people into the same pot
[06:29:26] <KotH> bilboed: but i've talked with enough gnome and freedesktop people and came to the conclusion that they understand x11 much less than i do...
[06:29:34] <KotH> bilboed: and i know hardly anything about it
[06:29:56] <ohsix> then what do you draw upon to judge that they have no understanding of concepts you aren't familiar with yourself
[06:30:10] <bilboed> eh :)
[06:30:29] <KotH> ohsix: oh.. quite simple.. if they dont even understand what i know, then it's bad, very bad ;)
[06:30:57] <ohsix> heh, i cant think of a limited scope where that'd hold
[06:32:08] <bilboed> anyway, don't make it a generality. Don't forget X is part of fdo, so pretty sure the people who would know the most *are* part of fdo (but seriously doubt they're part of canonical/ubuntu)
[06:33:44] <KotH> from my experience, xorg seems to be a seperate entity within fdo, with not much contact to other groups
[06:33:55] <KotH> but that might be my limited view of that field
[06:34:41] <ohsix> canonical/ubuntu pretty much stay out of the picture aside from their own design/integration projects for new releases
[06:35:18] <bilboed> KotH, somewhat true, which is a shame
[06:36:03] <KotH> does anyone have a good idea how i can get rid of "warning: cast increases required alignment of target type" if the variable (an uint8 array) is casted to an uint32 pointer and already alligned to 8 bytes?
[06:36:18] <KotH> bilboed: juup
[06:36:33] <Dark_Shikari> hmm, since when does gcc warn about that?
[06:36:34] <bilboed> ohsix, nono, they just stay out of the picture, except for the one month before freeze when they sound the alarm at the Canonical bunker going "fuck fuck fuck, we need to get in touch with upstream to figure out wtf's been going on"
[06:36:50] <KotH> bilboed: i have a very high regard for xorg people... i cant imagine how much time they must invest in building and maintaining that huge infrastructure that xorg is
[06:37:09] <ohsix> bilboed: o ic, i haven't seen any of that, which projects have they done that to? did they offer money for their trouble?
[06:37:09] <Dark_Shikari> KotH: well it is rather amazing
[06:37:20] <Dark_Shikari> xorg is a steamping pile of shit, and yet they are so good that they've made the steaming pile of shit work incredibly well
[06:37:34] <ohsix> KotH: they do a pretty good job at rewriting huge pieces of it every few years, and removing stuff
[06:37:47] <bilboed> ohsix, that is at least for all the projects that aren't hosted on "THE LAUNCHPAD" (insert dramatic 1940's black and white sound effect)
[06:37:48] <ohsix> its a lot of little steaming piles now; almost all optional
[06:40:30] <ohsix> bilboed: oic; then i guess i'll never see until someone shows me something :D
[06:42:25] <bilboed> launchpad just duplicates the amount of bug triaging/maintaining/... for any project. Imagine for one second having to handle ffmpeg bug reports/requests/code-hosting on lp in addition to what you already have... it's just the fastpath to failure
[06:42:46] <ohsix> oh, right
[06:42:58] <KotH> Dark_Shikari: i dont know how the internals look like. i only know how the mga driver looks like, but that is one very old and hardly maintained driver anyways
[06:43:02] <ohsix> so you're talking about the stampede from launchpad at the moment that they go from not care to do care
[06:43:08] <bilboed> ohsix, yah
[06:43:28] <bilboed> ohsix, and then them requesting releases with all the bugs they want fixed for a given deadline
[06:43:36] <ohsix> k yea i've seen half of that; launchpad is pretty dry, nobody does triage its more like first level phone support asking you to make sure your printer is plugged in
[06:43:43] <bilboed> ohsix, to which your response is "I'm sorry, got other stuff to do, you're not our priority"
[06:44:03] <ohsix> even distro metabugs are kind of meh
[06:44:44] <bilboed> some distros actually do the triaging downstream, instead of ubuntu expecting upstream to come and triage stuff in lp
[06:45:18] <bilboed> debian (and not ubuntu) is pretty good at that for ex. Same for gentoo. Fedora to a certain extent. Launchpad/ubuntu ? meh
[06:45:36] <ohsix> yea
[06:45:46] <bilboed> I'd say they're overwhelmed by their success
[06:46:15] <ohsix> the very least they need less gladhanding and more aggressive bug closing if they aren't going to have people to triage and file upstream, or push people out to the right place to file upstream
[06:46:31] <KotH> hmm..? what is launchpad exactly? it looks like a generic bugtracker site?
[06:46:50] <ohsix> they don't really give extra priority to apport collected bugs or anything either; the real reason launchpad should exist
[06:47:18] <ohsix> apport rules; but if user reports are ignored then its less than useless
[06:50:50] <_av500_> bonjour mes enfants
[06:55:08] <KotH> salut papa
[07:41:17] <siretart> god morgon
[07:41:21] <kshishkov> :)
[07:41:23] <kshishkov> hej hej
[07:41:47] <siretart> KotH: launchpad is technically a heap of zope applications that more or less collaborate with each other
[07:42:13] <siretart> KotH: the bug tracker component is called 'malone', the archive and package build component 'soyuz' and so on
[07:42:34] <kshishkov> what does "malone" mean?
[07:42:43] <merbzt> boker tov
[07:42:47] <ohsix> the same thing steve does
[07:42:57] <KotH> siretart: and what's the goal of launchpad?
[07:43:26] <siretart> kshishkov: no idea. but that name isn't promimently exposed. you see it in bugreports and the bzr repo is named like that
[07:43:52] <kshishkov> at least "Soyuz" fits nicely on launchpad
[07:43:54] <siretart> KotH: "to improve collaboration between projects" would be the buzzword-style answer
[07:43:57] <kshishkov> or V2
[07:44:18] <siretart> KotH: launchpad tries to be not ubuntu-specific, although ubuntu is clearly the most important user of it
[07:45:08] <siretart> KotH: these days, there are a number of non ubuntu, non distro upstream projects hosted on launchpad, that use bug managment, user support, translations managment and code hosting
[07:45:13] <KotH> siretart: improve collaboration by providing a common bug tracker, mail archive,... etc pp?
[07:46:24] <siretart> KotH: malone has the concept that every bug can have more than one 'bug task'. a 'task' is targeted at either a distro or at some upstream project. this way you can say 'this bug is confirmed in ubuntu, and fix released in upstream'
[07:47:07] <siretart> this becomes interesting when an upstream bug task is linked to some upstream bugtracker. in that case, launchpad will poll the status of the bug from the remote bugtracker
[07:48:04] <siretart> e.g. https://edge.launchpad.net/mplayer/+bugs are the bugs launchpad knows that affect 'mplayer' as upstream project. they may or may not also have a bugtask in the ubuntu distro
[07:48:40] <siretart> same for https://edge.launchpad.net/ffmpeg/+bugs
[07:55:37] <KotH> intersting concept
[07:55:59] <KotH> and what are people complaining about launchpad?
[07:56:26] <ohsix> its insulated from upstream except for the volition of people who do triage (which there aren't many, if any that i've seen)
[07:56:49] <ohsix> so those people have to spend time doing triage out of launchpad which is hard cuz the bug quality is low and so is their classification
[07:58:32] <KotH> but that's not a prob directly related to launchpad, but a genereal problem of bug trackers, or not?
[08:00:24] <ohsix> any given bug tracker will have more narrow focus, like the redhat bugzilla has people and bug reporting directly linked to respective projects and people
[08:02:16] <KotH> you mean the broad "focus" of launchpad is the cause of these low qual reports?
[08:03:22] <ohsix> no, thats secondary
[08:03:39] <KotH> what's primary then?
[08:04:16] <ohsix> lack of people doing triage
[08:04:39] <ohsix> you essentially have people doing form letters for bugs; to make sure the information is there, but the people that would use that information arent there
[08:06:14] <ohsix> and thats the best case scenario; people sending form letters don't know much about what they're looking at
[08:13:56] <ohsix> the way they do updates sidesteps a lot of bugs too, consequently there are is a lot of old, dead information on their wiki and in the bugs
[08:14:46] <ohsix> anything targeting a milestone isn't really visible in the bug minutae; so you might have a bug thats already going to be solved or is solved at some release; but nobody has tended the bug or even classified it
[08:16:47] <_av500_> siretart: i see you spend a lot of time in this launchpad
[08:20:24] <siretart> KotH: I'd rather say that launchpad makes it too easy to report low-quality bugs. ubuntu developers do not manage to cope with this flood, so you almost always have to filter out the 'yet unseen' (read: untriaged) bugs
[08:22:12] <ohsix> apports usefulness is marginized when there aren't people doing triage
[08:38:43] <KotH> siretart: how can you make it more difficult to submit low quality reports while not making it more difficult to enter high quality reports?
[08:39:54] <ohsix> you cant without people forcing bugs out
[08:43:34] <KotH> so it boils down to have enough people weeding out bugreports?
[08:43:36] <ohsix> what people do with retraces isn't very visible; they dont aggregate the automatic reports or anything, or link stuff with upstream, anyone can do that though; i've done it for some of my bugs, but they need staff that does just that
[08:44:04] <ohsix> its all thrown in the same bin
[08:59:27] <benoit-> moin
[08:59:39] <kshishkov> guten morgen
[09:01:13] <scaphilo> hallo
[09:03:19] <KotH> echo
[09:12:09] <siretart> KotH: one approach is to encourage users to not use the webinterface, but dedicated bug reporting tools. ubuntu e.g. offers the tool 'ubuntu-bug' that includes additional information about the system and the installed package. additionally, it calls hooks included in the respective package for additional, package specific information
[09:12:33] <siretart> KotH: for the alsa package that is for instance the amount and settings of the mixers, etc.
[09:14:03] <siretart> KotH: another bug reporting tool is 'apport', which attaches coredumps to bugs. these core dumps are then retraced in a special environment with debug symbols installed. the resulting backtrace is then hopefully understandable to developers
[09:28:28] <_av500_> siretart: ffmpeg --bug-report?
[09:29:54] <siretart> _av500_: sorry? what is that supposed to produce?
[09:30:15] <_av500_> a good bug report of course :)
[09:30:46] <_av500_> or at least a templete to paste into an emial
[09:30:49] <siretart> _av500_: if there is anything that I can call or do in some apport package hook, tell me, I can include it in the package
[09:31:04] <_av500_> it could give a templte for bug reports
[09:31:17] <_av500_> like <enter bug descriptoin here>
[09:31:28] <_av500_> liek <paste backtrack here >
[09:32:19] <siretart> there is something like package specific instruction for bug reports, which serves a similar purpose like templates. but malone itself doesn't support real bug templates
[09:32:56] <siretart> again, if there is information on the system that is potentially relevant for the bug and I can programatically extract it at the time the bug is filed, tell me, I'll include it
[09:33:28] <siretart> requiring the user to read a template, think, do stuff and then proceed is not an option
[09:33:35] <_av500_> :)
[09:33:39] <siretart> well, it is an option in general, but not in launchpad
[09:34:42] <_av500_> is there a way to detect we crashed (sig handler?) and at least spit out some lines that point users to what to do next?
[09:35:49] <siretart> I think that should be possible. I remember that pitti added an API so that apport hook can interact with the user
[09:36:32] <siretart> I haven't used it yet, it most often is used to ask the user if there is potentially something confidential in the report, but I think that can be extended to other purposes
[09:37:48] <siretart> the ubuntu kernel has been modified to always call apport on every segfault. apport will then check if the segfault was in a binary that was shipped by an ubuntu package and if yes, call these apport hooks
[09:38:41] <siretart> and I think that we can have some user interaction at this point. Given that the user has an graphical session open at all, that is.
[10:20:50] <Honoome> lu_zero: may I prod bilboed-pi here or should I lure him somewhere more cozy? :P
[10:22:44] <scaphilo> is there a way to simply ignore b frames in the input video, skip-bframes or something?
[11:08:19] <scaphilo> well i found a way to simply remove them but its a hack... once again. But an other question:
[11:08:33] <scaphilo> mb_type_l0 and mb_type_16x16
[11:08:53] <scaphilo> does that make sens when both of them are set for one macroblock?
[11:09:16] <scaphilo> mb_type16x16 would be enough not?
[11:10:13] <kshishkov> l0 means it has motion vector
[11:10:24] <kshishkov> for backward reference frame IIRC
[11:11:01] <kshishkov> 16x16 means something completely different
[11:11:08] <scaphilo> ah i see
[11:11:14] <scaphilo> i thought its line0
[11:11:17] <scaphilo> and line1 for
[11:11:24] <scaphilo> mb_type_l1
[11:11:50] <scaphilo> thx for help
[11:12:16] <scaphilo> ah your right line0 and line1 makes no sense
[11:40:02] <ramiro> superdump: don't bother helping phil rhodes, he's just trolling
[11:40:27] <superdump> what makes you say that?
[11:40:38] <kshishkov> maybe he saw you helping him
[11:40:53] <ramiro> superdump: he's a notorious troll on ffmpeg-user
[11:40:58] <superdump> oh
[11:41:27] <ramiro> he's the guy who wrote the dark shikari complaining mail
[11:41:41] <ramiro> he's too dumb to google and wants every spoon-fed.
[11:41:46] <superdump> ah, yes, i remember him
[11:42:24] <ramiro> it's actually quite fun to troll back and see what he will reply =)
[11:44:37] <kshishkov> "don't argue with a fool, you'll eventually get to his level and he'll beat you having more experience"
[11:45:07] * mru points at Nietzsche
[11:45:19] <mru> monsters, trolls, it's all the same
[11:45:30] <_av500_> Nietzsche is on -user?
[11:54:46] <KotH> why didnt anyone tell me of that Dark_Shikari complaint threat before?
[11:59:09] <DonDiego> what's up with CIA-7 ?
[12:01:42] * janneg kicks CIA-7 
[12:01:44] <CIA-7> ow
[12:05:56] <ramiro> KotH: having fun reading it?
[12:06:10] <KotH> ramiro: juup
[12:15:10] * Honoome today is hitting crazy stuff =_=
[12:16:38] <KotH> Honoome: at least it isnt shit hitting the fan ;-)
[12:17:32] <Honoome> KotH: but it's gstreamer hitting feng from one side :P
[12:18:07] * Honoome wanted to update synergy-plus in Gentoo… they moved to CMake… they now lack a dist target… they tarballed the .svn directories =_=
[12:18:31] <DonDiego> given how broken the dist target implementation in automake is..
[12:18:47] <DonDiego> you have to manually remove .svn directories there, too..
[12:18:53] <mru> dist targets are useless
[12:19:11] <mru> if exporting the files under version control isn't enough, something's broken
[12:19:12] <Honoome> DonDiego: untrue… you just have to list each file one-by-one :P
[12:19:39] <Honoome> mru: *shrug* I'm fine with that as well… not so fine with downloading the whole shebang twice 'cause they don't know the --exclude '.svn' option
[12:19:51] <mru> or svn export
[12:20:00] <mru> which is in fact better
[12:20:09] <mru> otherwise you can be sure to get a few *~ files along too
[12:20:12] <Honoome> does svn export tar the stuff as well?
[12:20:20] <mru> no
[12:20:39] <Honoome> too bad, that would have been useful to suggest people ;)
[12:20:59] <janneg> git archive does
[12:21:18] <mru> if something seems useful, svn probably doesn't do it
[12:22:01] <Honoome> mru: ah true
[12:30:38] <mru> ugh, 43 different gcc builds installed again...
[12:31:20] <kshishkov> wanna recompile gentoo with each of them?
[12:31:37] <mru> mostly cross-compilers of course
[12:37:41] <spaam> mru: why so many?
[12:38:19] <_av500_> many cross platforms
[12:41:47] <mru> and many gcc versions
[12:42:35] <_av500_> how does gcc 2.9.5 run for A8 :)
[12:43:04] <mru> probably not at all
[12:43:21] <mru> nothing before 4.2 is worth looking at for arm
[12:43:58] <_av500_> iirc we used 2.9.5 for the omap1
[12:44:44] <mru> and my ex-employer still uses armcc 1.2
[12:45:45] <Kovensky> <@mru> if something seems useful, svn probably doesn't do it <-- lol
[12:51:03] <hyc> it always pissed me off that we couldn't build a single gcc frontend with multiple backends
[12:51:27] <_av500_> patches welcome
[12:51:35] <hyc> been there, done that, they were rejected
[12:51:36] <mru> or vice versa
[12:53:05] <hyc> (that was ... 15+ years ago)
[12:53:50] <hyc> more like 19 years, that's when I wrote my Usenix paper on using big multiprocessor "supercomputers" as compile servers
[12:54:29] <hyc> I used an Alliant FX/8 with a bunch of gcc installs, to compile code for Sparc, VAX, and a couple other systems we had
[12:54:52] * mru looks at distcc
[12:55:04] <mru> someone ought to fix that
[12:56:59] <hyc> distcc is almost the opposite problem, instead of one machine with many compiler backemds, you want many machines with only one compiler
[12:57:21] <mru> depends
[12:57:35] <mru> I have one really fast machine and many slow ones
[12:57:41] <hyc> but it all still ties together with parallel make, so there's a connection I guess
[12:57:59] <mru> you want each machine to run as many compilers as it can manage
[12:58:27] <hyc> true
[12:58:46] <hyc> but you generally only care about one architecture at a time
[12:58:55] <mru> says who?
[12:59:30] <hyc> well, most project makefiles only build a package once.
[12:59:43] <hyc> you can of course wrap anotehr build script around it to build multiple instances in parallel
[12:59:57] <mru> I might be building stuff independently on many machines
[13:00:45] <hyc> ok. so really you just want to be able to distribute as many cc's as possible regardless of arch or project
[13:00:47] <mru> and then there are things like fate
[13:01:00] <mru> I run 17 different compilers on each rev
[13:01:40] <hyc> fate ... you have 17 different execution environments?
[13:02:01] <hyc> or a lot of different compilers for the same platform?
[13:02:05] <mru> 6 different targets, most of them with multiple compilers
[13:03:44] <hyc> I need to get our cross-compile environment in shape here. currently we build for different platforms on their native hardware
[13:04:00] <hyc> but our AIX machines are ancient RS6000s
[13:04:02] <_av500_> we=?
[13:04:16] <hyc> amy company, Symas Corp., and our products
[13:04:21] <hyc> s/amy/my/
[13:04:37] <_av500_> i get get you another bunch of ancient rs6000s if you want :)
[13:04:41] * mru glares at debian
[13:04:47] <hyc> heck, our Sparc/solaris machines are ancient now too :P
[13:05:14] <mru> who cares, Sun has turned brown dwarf
[13:05:20] <hyc> _av500_: no thanks. when our company started, we picked up 4 RS6000s that Caltech was throwing away
[13:05:20] <mru> didn't even go nova
[13:05:39] <_av500_> hyc: mine would be uni machines too
[13:05:41] <hyc> happily we have also discarded them by now.
[13:06:10] * mru got alphas from uni
[13:06:23] * _av500_ remembers smitty
[13:06:24] <hyc> the new boxes are at least built within this decade :P  but still way slower than cheap x86 machines
[13:06:58] <_av500_> so why build for them?
[13:07:03] <hyc> yeah, I guess sparc/solaris will become less relevant over time
[13:07:11] <hyc> we still have customers on those platforms tho
[13:07:24] <hyc> so we still need to provide updates/new releases for them
[13:08:02] <hyc> compile would go much faster if we just cross-compiled on our x86 machines, but we still need to run the test suites on the actual boxes
[13:10:29] <hyc> smitty was pretty cool. Kinda wish linux had something as good.
[13:17:56] <_av500_> hyc: it has yast
[13:17:59] * _av500_ hides
[13:18:18] <hyc> :P
[13:19:00] <hyc> I had a lifetime subscription to SuSE due to my work on Gnu stuff in the 1980s and 1990s
[13:19:12] <hyc> but I finally stopped using it and switched to Ubuntu
[13:19:47] <DonDiego> heh
[13:19:54] <_av500_> i wonder when i will do that
[13:20:02] <DonDiego> i often feel like the grandpa around here..
[13:20:09] <DonDiego> hyc: i wonder what it must be like for you..
[13:20:10] <DonDiego> :)
[13:20:22] <_av500_> but coworkers wife is Mrs KDE, so i am biased
[13:20:38] <hyc> don't go there. my birthday was last week, I don't need the reminder right now. ;)
[13:21:02] <DonDiego> :)
[13:21:16] <_av500_> DonDiego: compared to me you are a kid
[13:21:29] <_av500_> im in semester 40
[13:21:40] * DonDiego is catching up..
[13:22:00] <_av500_> where are you now?
[13:22:05] <DonDiego> home
[13:22:06] <DonDiego> :)
[13:22:21] <_av500_> in 2 years i will be 42 and ee engineer :)
[13:22:33] <DonDiego> you intend to finish?
[13:23:09] <_av500_> i am finished, was refering to badesalz (but that might be for hessian locals only)
[13:23:36] <hyc> well, I'm 43 now :P  42 isn't bad really, especially if you liked Douglas Adams
[13:23:37] <DonDiego> it did not ring a bell with me..
[13:23:40] <_av500_> of course the phd is permanently under construction
[13:23:56] * DonDiego is 35
[13:23:58] <mru> you're doing a phd on geocities?
[13:24:13] <hyc> lol
[13:25:26] <kshishkov> mru: that's because a thesis in draconology is not welcome anymore
[13:26:17] * BBB thinks kshishkov should do a PhD in sweden
[13:27:16] <kshishkov> BBB: nej, tack
[13:27:26] <BBB> "tack"?
[13:27:36] <janneg> thanks
[13:27:44] <kshishkov> "thanks" or "please" depending on context
[13:28:40] <mru> or bitte/danke for you germans
[13:29:20] <_av500_> thx mru
[13:29:41] * mru doesn't know serbian
[13:29:43] <thresh> 'благодаря' in bulgarian, also
[13:30:21] <kshishkov> звучит как деепричастие
[13:30:40] <hyc> you guys are messing up my tty
[13:30:55] <DonDiego> you're not on utf-8 yet?
[13:31:02] <DonDiego> you really are an oldtimer ;)
[13:31:08] <hyc> I am, but apparently missing some fonts :P
[13:31:22] <Tjoppen> \u2603
[13:31:37] <Tjoppen> if only my tty also supported UTF-8
[13:31:40] <spaam> time to write ÅÄÖåäö ? ;)
[13:31:53] <Tjoppen> räksmörgås?
[13:31:58] <kshishkov> 日本語をできますか
[13:32:02] <thresh> kshishkov: i actually like Bulgarian, seems it is an 'older' version of Russian
[13:32:04] <spaam> Tjoppen: ÅÄÖ does fuck it up more then åäö
[13:32:26] <kshishkov> thresh: Church Slavic is Old Bulgarian, that's why
[13:32:29] <spaam> TiAMO did have that problem before ;)
[13:32:30] * elenril throws ☃ at kshishkov 
[13:32:44] <kshishkov> elenril: too warm for snowmen
[13:33:14] <elenril> true :(
[13:33:33] <kshishkov> thresh: and new Bulgarian does not have cases. Весело было в школе склонять числительные небось?
[13:33:40] * elenril should buy some ice cream on his way from school
[13:33:43] <thresh> =)
[13:34:18] <kshishkov> thresh: and we did it in two languages
[13:34:45] <thresh> kshishkov: here goes an obvious joke of not living in a proper country
[13:35:38] <hyc> (ah, I had forgotten to enable UTF-8 in my screen session)
[13:35:56] <kshishkov> thresh: I cannot argue, that's the reason I've moved
[13:36:17] * thresh still notes ukrtel though
[13:36:47] <kshishkov> thresh: ukrevilempiretel actually
[13:37:44] <mru> english has two cases, upper and lower
[13:38:46] <kshishkov> I actually meant stuff like Nominativ, Genitiv, Akkusativ und Dativ
[13:40:09] <_av500_> kshishkov: most ppl here only know 3 of those anyway
[13:40:20] <_av500_> rettet dem Dativ
[13:40:20] * elenril remembers hearing those words a loooong time ago ;)
[13:41:08] <kshishkov> _av500_: and I *don't know German at all*
[13:43:26] <mru> kshishkov: it's much simpler than russian
[13:43:44] <mru> russian has six cases: upper, lower, left, right, front, and back
[13:44:04] <kshishkov> no, none of them is straight
[13:44:20] <kshishkov> and German sometimes resembles Russian too much
[13:44:51] <janneg> _av500_: should be only two then since "Der Dativ ist dem Genitiv sein Tod"
[13:45:12] <mru> russian is like a cube, german is only a tetrahedron
[13:45:45] <kshishkov> mru: Russian is like a corkscrew - the same straightness and associated with alcohol
[13:46:09] * elenril wonders how to apply doppler shift to rgb data
[13:46:23] <kshishkov> G--,B--,R++
[13:47:04] <kshishkov> or you can rebuild model of RGB correspondence to wavelength and convert it back and from
[13:47:28] <kshishkov> IIRC it looked like a triangle in a loop
[13:48:47] <elenril> except you miss the  uv/ir parts
[13:49:20] <kshishkov> and not only them
[13:49:27] <elenril> i was thinking about fitting it to blackbody radiation, but it doesn't make a lot of sense for only 3 points
[13:49:35] <kshishkov> for example, sky blue cannot be represented with non-negative R
[13:51:42] * elenril should learn a few things about color representation
[13:52:29] <kshishkov> I've read mine in the textbook for TV repairman
[13:52:48] <elenril> and if i did it like you said, how would i add the resulting 3 colors together?
[13:53:29] <kshishkov> to get what?
[13:53:42] <elenril> the final shifted color
[13:54:05] <kshishkov> depends on output format obviously
[13:54:37] <kshishkov> I think it's better to operate in nanometers from the beginning
[13:54:46] <elenril> you convert each of the input RGB components to a wavelength -> shift each one -> convert them back to RGB -> you're left with 3 rgb colors
[13:54:56] <kshishkov> nope
[13:55:10] <kshishkov> whole RGB triplet represents one single wavelength
[13:55:16] <elenril> no?
[13:55:24] <elenril> 'white' is not a wavelength
[13:55:36] <kshishkov> it's not a colour neither
[13:55:48] <elenril> (256,256,256) is white
[13:55:49] <kshishkov> (for our US firends it's not a color as well)
[13:56:04] <kshishkov> elenril: just mention that to Isaac Newton
[13:57:22] <elenril> ?
[13:57:40] <elenril> not sure what you're talking about
[13:58:32] <kshishkov> you know, the guy with an apple and a prism
[13:58:54] <_av500_> the prism fell on his head?
[13:58:56] <elenril> how is that relevant to this?
[13:59:03] * elenril throws http://bouman.chem.georgetown.edu/S02/lect23/Solar_Spectrum.png at kshishkov 
[13:59:22] <elenril> here's your white
[14:02:29] <elenril> anyways, /me goes to school
[14:02:34] <kshishkov> I remember that in 8th grade they told us "you'll learn Optics in 10th grade" and in 10th grade they said "you should've learned Optics in 8th grade already"
[14:03:04] <elenril> heh
[14:03:11] <elenril> optics was unexpectedly fun
[14:03:20] <mru> there's this messy thing called human visual perception involved here too
[14:03:50] <mru> simply shifting each of the rgb components won't do the right thing
[14:04:12] <elenril> yeah, i realize that
[14:04:42] <elenril> i'd need full spectrum to be physically correct
[14:04:51] <mru> the eye has three kinds of colour receptors, each with a peak sensitivity at a different wavelength
[14:05:25] <_av500_> beer color, meat color and flesh tones
[14:05:28] * elenril away
[14:05:36] <mru> any combination of inputs generating the same response from all three will be perceived as the same colour
[14:05:41] <kshishkov> mru: engineers think their calculations are an approximation to reality, physicians think that reality is an approximation of their calculations and mathematicians don't see a connection between them both
[14:06:04] <mru> physicists...
[14:06:14] <mru> a physician is a medical doctor
[14:06:57] <kshishkov> noted, thanks
[14:07:04] <_av500_> j-b: ping
[14:07:07] * kshishkov does not believe in them anyway though
[14:07:30] * mru neither
[14:07:42] <mru> but nurses can be nice...
[14:08:22] * kshishkov remembers Monty Python skets involving two Gumbies calling nurse
[14:09:03] <kshishkov> *sketch
[17:11:05] <_av500_> j-b: pinger
[17:11:23] <j-b> av500: pong
[17:13:20] <j-b> shit
[17:15:03] <j-b> _av500_: ping
[17:17:46] <_av500_> for tonight?
[17:17:54] <_av500_> propose place
[17:18:08] <_av500_> needs food and beer
[17:18:24] <CIA-7> ffmpeg: cehoyos * r23017 /trunk/libavformat/avidec.c:
[17:18:24] <CIA-7> ffmpeg: Do not use pkt->size when it is potentially uninitialized.
[17:18:24] <CIA-7> ffmpeg: Patch by Thierry Foucu, tfoucu gmail
[17:18:38] <_av500_> im in massy
[17:18:59] <_av500_> willing to travel somewhat
[17:19:40] <j-b> where do you sleep? In massy too ?
[17:19:47] <_av500_> yes
[17:56:30] * Kovensky wonders how bad is sun's compiler
[18:00:34] <astrange> someone gave me a copy but i seem to have lost it
[18:00:52] <astrange> i had pathscale too. wonder where they went
[18:00:59] <astrange> maybe i should find open64 too
[18:02:02] <KotH> astrange: open64 seems mostly defunct these days
[18:02:46] <KotH> astrange: if you want pathscale for testing, ask codestr0m, i'm quite sure he'll get you one
[18:03:46] <KotH> Kovensky: on sparc, sun cc outperforms gcc by far (which isnt a surprise). but the quality of error messages is so bad, hardly anyone uses it during development
[18:04:39] <astrange> the commercial highly-optimizing compilers (pgi, pathscale, icc) tend to be much slower than even gcc and not much better on ffmpeg
[18:05:00] <astrange> they seem to advertise automatic parallelization and stuff which is useless for c, so i assume they're really meant for fortran or something
[18:05:29] <Kovensky> KotH: lol
[18:06:00] <Kovensky> I'll just try it anyway, and if it sucks I can make sunstudio use something else (I think)
[18:06:24] <Kovensky> just learning though, don't intend to use it for long unless I end up liking, but I also guess that if people liked it they'd use and advertise it
[18:06:27] <Kovensky> lol
[18:06:56] <astrange> http://pastebin.org/201510 run this through it if you've got access, i'll give you a random guess at how good it is
[18:08:59] <KotH> astrange: at least pathscale uses ffmpeg as test case :)
[18:10:14] <mru> I've had people from arm ask how to run fate
[18:10:34] <DonDiego> we need a fate replacement..
[18:11:05] <mru> doesn't sound so difficult
[18:11:42] <Kovensky> astrange: through my suncc?
[18:11:49] <DonDiego> it doesn't indeed; i've been toying with the idea ever since mike refused to share his code with me
[18:11:53] <astrange> yeah
[18:11:57] <Kovensky> astrange: how should I bench it
[18:12:12] <astrange> i just want to read the asm output
[18:12:13] <mru> I'd structure a replacement a bit differently
[18:12:16] <Kovensky> oic
[18:12:21] <Kovensky> it'll take a while to install
[18:12:23] <DonDiego> mru: elaborate
[18:12:28] <KotH> DonDiego: what's the prob with fate?
[18:12:32] <mru> there's too much central control
[18:12:33] <astrange> those are compiler testcases, i deleted the useful code from them to make it smaller
[18:12:36] <Kovensky> 78MB out of 350MB
[18:12:59] <Kovensky> at I-have-no-idea-how-fast-it-is-going-but-I'm-sure-it's-not-being-fast-at-all
[18:13:47] <DonDiego> KotH: it is proprietary
[18:13:56] <DonDiego> and the start page sucks
[18:13:58] <KotH> DonDiego: ah..
[18:14:13] <KotH> DonDiego: nothing that cannot be written in a couple of days in haskel, perl or bash
[18:14:30] <mru> make that one day in posix sh
[18:14:37] <mru> and a bit of perl
[18:14:49] <DonDiego> haskell could be fun :)
[18:14:58] <Kovensky> ocaml?
[18:15:11] <KotH> anyone a good idea how i can get rid of "warning: cast increases required alignment of target type" ?
[18:15:14] <Kovensky> or at least I heard that ocaml is a less-lazy haskell =p
[18:15:20] <mru> novelty languages are fun and all, but do real work with a real language, please
[18:15:26] <KotH> (yes, the target is already alligned right, it's just gcc not getting that)
[18:15:29] * Kovensky votes for perl
[18:15:36] <mru> KotH: get rid of -Wcast-align
[18:15:50] <Kovensky> how do you disable a warning, -w or -Q?
[18:15:50] <KotH> mru: that i dont want to
[18:16:01] <mru> then you have to live with the warning
[18:16:05] <mru> KotH: -Wno-foo
[18:16:15] <mru> Kovensky: ^^
[18:16:17] <DonDiego> Kovensky: -Wno-cast-align
[18:16:37] <KotH> mru: ok.. then so be it
[18:16:57] <Kovensky> oic
[18:17:03] <Kovensky> clang uses -Q, at least for its own warnings
[18:17:17] <mru> yeah, there's no standard
[18:17:20] <KotH> ok.. code compiles, only three warnings (all bougus), testing (resp frying hardware) can wait for tomorrow
[18:17:31] <KotH> time to go home \o/
[18:17:37] <KotH> have a nice evening boys!
[18:18:02] <Kovensky> I suppose it supports -Wno- for gcc compatibility though
[18:18:12] <Kovensky> talking about gcc compatibility, it can't compile firefox :(
[18:18:15] <Kovensky> durr friend templates
[18:18:39] <Kovensky> it also fails on "typodef struct Name {} Name;" if you try using "struct Name;"
[18:19:03] <KotH> Kovensky: nice typo ;)
[18:19:24] <peloverde> firefox? that's that theora browser?
[18:20:53] <DonDiego> it had better fail on 'typodef'
[18:23:30] <Dark_Shikari> http://pastie.org/945486
[18:23:34] <Dark_Shikari> this patch fixes the win64 ABI issue
[18:23:41] <Dark_Shikari> (courtesy of bugmaster)
[18:24:05] <Kovensky> KotH: ;)
[18:24:08] <Kovensky> DonDiego: indeed :>
[18:24:28] <mru> Dark_Shikari: why the ifdefs?
[18:24:39] <mru> that reg is always clobbered
[18:24:44] <Dark_Shikari> mru: so that it can compile on x86_32 without -msse2
[18:24:47] <mru> it was a mistake not to mark it originally
[18:24:59] <mru> at least the _WIN32 ifdef should go
[18:25:03] * Kovensky never understood gcc asm syntax
[18:25:03] <Dark_Shikari> ok, agreed
[18:25:09] <Dark_Shikari> But that's obviously a trivial find/replace to remove that
[18:25:11] <mru> and tidy it up with a macro somewhere
[18:25:13] <Dark_Shikari> so it's hardly something to debate about.
[18:25:24] <DonDiego> Dark_Shikari: btw, if you can help with optimizing that YUV to RGB lgpl code, that would be very appreciated
[18:25:28] <DonDiego> pengvado: same for you
[18:25:29] <DonDiego> :)
[18:26:43] <peloverde> DonDiego, what's the status on 0.6?
[18:27:06] <DonDiego> looking good :)
[18:27:21] <DonDiego> didn't siretart cut the branch already?
[18:27:26] <peloverde> did he?
[18:27:35] <peloverde> branches aren't visible anywhere
[18:27:43] <peloverde> I have SBR fixes I'd like to backport
[18:28:12] <DonDiego> there is no branch yet i think
[18:28:15] <DonDiego> so just commit the fixes
[18:28:27] <DonDiego> let us know when you're done
[18:28:34] <peloverde> they are comitted
[18:28:48] <DonDiego> then they will be in 0.6
[18:29:49] <peloverde> ok
[18:32:12] <Kovensky> meh, why do people top-post so much in the gsoc list too :(
[18:36:26] <ramiro> Dark_Shikari: is that everything that needs to be patched? I expected a much longer patch.
[18:42:04] <mru> anyone heard of these guys? http://cinemo.com/
[18:42:19] <mru> just got an email from their ceo
[18:47:11] <_av500_> mru: ~corbett
[18:47:39] <CIA-7> libswscale: diego * r31135 /trunk/libswscale/ (x86/yuv2rgb_mmx.c Makefile yuv2rgb.c x86/yuv2rgb_template2.c):
[18:47:39] <CIA-7> libswscale: alternative LGPL-licensed, MMX-optimized YUV to RGB conversion routines
[18:47:39] <CIA-7> libswscale: written by Kostya Shishkov
[18:47:57] <mru> _av500_: ?
[18:48:00] <mru> you know him?
[18:48:23] <_av500_> ask kshishkov :-)
[18:48:41] <_av500_> its his outfit...
[18:48:55] <mru> oh
[18:49:13] <_av500_> thre nero guy
[18:49:26] <mru> yeah, I got the nero connexion
[18:49:40] <DonDiego> mru: kostya works for them
[18:49:43] <DonDiego> what did they want?
[18:50:22] <mru> talk business
[18:51:04] <spaam> mru: they want you to work for them ? :)
[18:52:29] <kierank> as chief troll
[18:52:55] <spaam> :)
[18:52:56] <mru> giving CTO a whole new meaning
[18:58:06] <Dark_Shikari> ramiro: most functions don't even use more than 6 xmm regs
[18:58:42] <ramiro> Dark_Shikari: isn't it about using some specific regs?
[18:58:50] <Dark_Shikari> yes.  xmm6 and above.
[18:58:57] <Dark_Shikari> Which you only use if you've used xmm0-5 already.
[18:59:02] <ramiro> ah, ok...
[19:16:43] <BastyCDGS> hey wonderful evening @ all!
[19:16:56] <mru> morning BastyCDGS
[19:17:05] <BastyCDGS> how are u?
[19:17:06] <mru> btw, what is cdgs?
[19:17:17] <BastyCDGS> CDGS = Coders Develop Glorious Stuff
[19:21:04] <BastyCDGS> mru, what do you think about the palette index be/le issue?
[19:22:10] <mru> don't ask me
[19:22:19] <mru> michael has strong opinions on those things
[19:23:03] <BastyCDGS> btw, are my heavy opt patches now getting in?
[19:23:18] <BastyCDGS> including the iff-decoder-fix patch
[19:23:42] <BastyCDGS> which fixes all these wrong decoded iffs that don't have masking enabled
[19:39:53] <BastyCDGS> mru, I'm thinking of a way to get rid from the switch cases in the HAM decoding stuff
[19:40:01] <BastyCDGS> and put that into a table
[19:40:13] <Kovensky> <@mru> giving CTO a whole new meaning <-- lol
[19:40:55] <BastyCDGS> it seems it has to be dynamically created because of the palette data and hbits / mbits
[19:42:39] <peloverde> Their product list seems very intel-centric
[19:45:18] <kierank> maybe getting money from intel
[20:05:15] <Kovensky> DonDiego: lend me your grammar powers
[20:05:26] <Kovensky> DonDiego: how is "I found song" correct
[20:06:12] <_av500_> a song?
[20:06:27] <_av500_> the song?
[20:06:38] <_av500_> one song?
[20:07:08] <Kovensky> 17:00.40 <&Emess> I'm not following you at all
[20:07:08] <Kovensky> 17:00.59 <~zfs> "found a song", "found the song", "found many songs", "found one song", but not "found song"
[20:07:11] <Kovensky> 17:01.24 <&Emess> song as a collective object
[20:08:12] <kierank> replace "song" with "music" and it might be clearer
[20:08:25] <Kovensky> kierank: yes, but he keeps arguing that "song" isn't wrong
[20:11:26] <mru> yes, song can be used like that
[20:11:42] * Kovensky sees no documentation about that in the internet
[20:11:48] <mru> http://www.merriam-webster.com/dictionary/song
[20:11:51] <mru> first entry
[20:12:26] <mru> although "I found song ..." does sound a bit odd
[20:12:35] <mru> "singing" is probably better there
[20:13:01] <mru> depends on context of course
[20:13:23] <Kovensky> his rant-explanation is "<&Emess> she had nothing to live for, then she discovered the power of song and is now a happy musicfag~"
[20:13:30] <Kovensky> s/~//
[20:13:39] <Kovensky> (which still doesn't make much sense for me)
[20:13:43] <mru> that is a correct sentence
[20:13:52] <Kovensky> I find that 'music' would be a much less confusion-inducing noun
[20:13:56] <mru> maybe missing a comma
[20:15:36] * _av500_ likes the tower of song
[20:15:42] <BastyCDGS> mru, I just updated my patches to represent the latest unsigned->signed changes
[20:15:57] <BastyCDGS> so they apply to current git/svn again
[20:16:06] <Kovensky> he keeps saying it's an expression that only natives would understand and also that it's "a fairly fucking common expression" :v
[20:16:52] <mru> I wouldn't say it's that common
[20:17:04] <mru> but it's not hard to understand
[20:17:04] <Kovensky> me neither
[20:17:10] <twnqx> let's just wait for D_S
[20:17:25] <Kovensky> otherwise it would appear on a google search, or define: search, or on UD, or on TFD
[20:17:55] <Kovensky> I don't find it hard to understand at all, I just think the grammar is wrong because 'song' is countable
[20:19:52] <janneg> BBB: ping
[20:19:57] <kierank> you can "burst into song" though Kovensky
[20:21:26] <twnqx> the fucl
[20:21:35] <twnqx> never heard that phrase either
[20:21:46] * Kovensky neither
[20:25:29] <dgux> "The file you are trying to access is temporarily unavailable."
[20:26:18] <BBB> janneg: pong
[20:26:31] <BBB> (sorry, I'm semi-not-here, but ask anyway and I'll respond in a few minutes)
[20:27:02] <BastyCDGS> hey BBB :)
[20:27:05] <dgux> Hi all, I'll probably be told that I should ask in #ffmpeg,  but no activity there.  I'm just wondering about a problem that I see encoding mp4's for wowza RTMP vs. FMS RTMP.   (same files are fine on FMS, but not smooth on wowza).  Does this ring a bell for anyone?
[20:33:36] <BBB> BastyCDGS: I'll get bck to patch review at the end of this week, I'm almost done with busy work-stuff
[20:34:25] <BastyCDGS> oh so it's the same as here ;)
[20:35:59] <kierank> dgux: ask hyc
[20:36:34] <dgux> Thanks kiernak
[20:37:18] <Dark_Shikari> mru: http://pastie.org/945767
[20:37:23] <Dark_Shikari> Not as pretty as I'd hoped, but better than before
[20:41:14] <lu_zero> fms?
[20:41:28] <wbs> lu_zero: flash media server
[20:41:30] <dgux> yea, Adobe flash media server
[20:41:50] * lu_zero should learn more about rtmp =P
[20:42:00] <lu_zero> wbs: hi
[20:42:19] <wbs> lu_zero: hi :-)
[20:42:58] <lu_zero> any news?
[20:44:01] <lu_zero> today we eventually put a workaround in feng so upset udp network won't makes rippling drifts on live streaming in feng =P
[20:44:16] <wbs> oh, nice :-)
[20:44:21] <wbs> nothing new here, I think
[20:45:36] <pengvado> BugMaster, Dark_Shikari: of the functions that are split into multiple asm blocks, do any depend on data staying in xmm6+ between blocks? if so, clobber doesn't describe that dependency, and will probably break.
[20:46:03] <Dark_Shikari> ooh, good point.
[20:46:06] <pengvado> also, does gcc only spill to memory, or can it spill xmm6 into xmm0 if you tell it that xmm6 is clobbered and xmm0 isn't?
[20:46:16] <Dark_Shikari> Also good point.
[20:46:32] <Dark_Shikari> hmm, I think we might need to do things The Right Way then (declare all clobbers)
[20:46:49] <Dark_Shikari> 1) rewrite all asm functions to use incrementing numbers of xmms (i.e. to not use xmm0, xmm1, and xmm6)
[20:46:58] <BugMaster> there is such blocks (but dissasm show that it is mostly ok). it seems to splitt only to memory
[20:47:00] <Dark_Shikari> 2) declare macros for XMM0 ... XMM15 clobbers
[20:47:15] <Dark_Shikari> ugh.  I don't like relying on "the current version of gcc happens to do X"
[20:48:20] <BugMaster> eh. probably the problem can occure only if changed xmm register used in section between to asm blocks
[20:48:21] <mru> yeah, that's a Very Bad Idea
[20:48:40] <mru> gcc makes no promises about what it does between two asm blocks
[20:48:42] <pengvado> The Right Way is to declare any data passed from one block to another via "x" constraint. but that fails to compile without -msse, just like the clobbers do.
[20:49:45] <mru> the right way is not have such dependencies at all
[20:50:38] * Kovensky throws an yasm in the channel and runs away
[20:51:44] <mru> yes, that's the best
[20:51:50] <mru> for non-inlined functions
[20:52:23] <lu_zero> hopefully next I'll merge the statistics stuff and add auth and tls (eventually)
[20:52:59] <wbs> lu_zero: oh, what other implementations do rtsp over tls?
[20:53:15] <wbs> lu_zero: and do you run that on a separate port, or is it negotiated on the fly within a normal session?
[20:53:33] <lu_zero> I'd like to negotiate it on fly
[20:53:49] <BugMaster> anyway if the problem of such dependence exist than it exist in current code also not only with this patch
[20:54:05] <mru> yes, and it should be fixed
[20:54:07] <mru> not ignored
[20:54:46] <lu_zero> I'm not sure how many would do, surely I'll make sure ffmpeg will be able to interact with it =P
[20:55:08] <lu_zero> btw did you read my request for comments/clues about sctp?
[20:55:50] <BugMaster> I don't tell that it must be ignored. But it must be fixed separate from this patch (which must be earlier is the question but I don't want to fix this also).
[20:56:29] <mru> this patch could make it worse
[20:57:03] <mru> I wouldn't be at all surprised if gcc decided to reload the clobbered registers between two asm blocks
[20:57:22] <mru> but leave them alone if it's unaware of anything going on with them
[20:57:37] <wbs> lu_zero: didn't read it much, I know next to nothing on sctp
[20:58:08] <wbs> lu_zero: on rtsp/tls, this may be a quite relevant discussion: http://www.ietf.org/mail-archive/web/mmusic/current/msg05580.html
[20:58:43] <siretart> DonDiego: I'm on it right now.
[20:59:06] <CIA-7> ffmpeg: siretart * r23018 /branches/0.6: Create 0.6 release branch.
[21:00:24] <lu_zero> ok, Magnus suggests separate port -> less work for us =)
[21:00:57] <DonDiego> the branch arrived :)
[21:01:05] <DonDiego> siretart: 0.5.2 ?
[21:01:28] <mru> oh, get 0.6 out there already and drop 0.5
[21:01:36] <mru> can we have it out by linuxtag?
[21:01:58] <wbs> when is that?
[21:02:09] <CIA-7> ffmpeg: siretart * r23019 /branches/ (31 files in 8 dirs): replace svn:externals on libswscale by a real copy
[21:02:11] <mru> june
[21:02:15] <mru> 9-12 iirc
[21:02:27] <mru> siretart: scary...
[21:03:00] <siretart> mru: 0.5 will be around in distros and other distros for quite some time, what do you exactly mean with 'drop 0.5'?
[21:03:17] <mru> I mean stop maintaining it
[21:03:29] <mru> not eradicate it from history
[21:03:41] <Kovensky> we'd need a flux capacitor for that
[21:04:05] <lu_zero> uhm
[21:04:11] <elenril> Kovensky: here http://xkcd.org/730/
[21:04:15] <Kovensky> unless mru has one in his basement, along with his shotgun
[21:04:20] <Kovensky> elenril: :P
[21:04:41] <siretart> well, if some distro contributes clean patches, or even better, manages to nominate patches that backport cleanly and fix security issues, I don't see why they shouldn't be included in 0.5
[21:04:49] <BastyCDGS> elenril: lol
[21:05:04] <siretart> but as for "active maintenance", i think we agree
[21:05:14] <twnqx> mru: i'd have done that years ago
[21:05:25] <twnqx> it's just old, obsolete and deprectaed
[21:05:34] <BastyCDGS> for the flux though, you should just add imaginary components ;)
[21:05:43] <twnqx> oh, and ridicously crappy, codecsupportwise
[21:09:24] <peloverde> the current ubuntu LTS uses 0.5-branch, no?
[21:09:57] <peloverde> do any of the mainstream rpm distros ship ffmpeg?
[21:10:46] <Kovensky> maybe fedora, but if they do it's probably a highly crippled version
[21:10:54] <janneg> peloverde: I don't think so
[21:10:57] <peloverde> no ffmpeg is banned from fedora
[21:11:06] <Kovensky> lol
[21:11:08] <peloverde> they won't even ship the stripped down chromium version
[21:11:16] <Kovensky> then it isn't in RHEL either
[21:11:25] <lu_zero> what?
[21:11:31] <lu_zero> and why?
[21:11:41] <Kovensky> well, this is just wild guessing
[21:11:43] <Kovensky> it might be, dunno
[21:11:50] <Kovensky> suse? mandriva?
[21:12:00] <Kovensky> they're the only other ones I can think of
[21:12:39] <janneg> only hit for ffmpeg in fedora13 packages is gallery2-ffmpeg
[21:12:40] <peloverde> for fedora see this issue: http://code.google.com/p/chromium/issues/detail?id=28289
[21:13:09] <DonDiego> siretart: this reminds me of the wiki page for distro status..
[21:13:51] <Kovensky> blastwave (some solaris thing) ships 0.4.9 (lolol) and 0.5
[21:14:25] <siretart> DonDiego: yeah, my fault. I still didn't get to that. I'm currently writing a mail about ffmpeg 0.6 for ffmpeg-devel
[21:14:33] <DonDiego> no trouble
[21:14:47] <DonDiego> it would be nice if you got to it eventually
[21:14:57] <lu_zero> "Fedora won't use ffmpeg, for legal reasons"
[21:15:01] <lu_zero> sad
[21:15:35] <BastyCDGS> they all are worried about getting sued for patent issues
[21:15:55] <BastyCDGS> time to stop this software patent bullshit
[21:16:02] <peloverde> but the chromium version of ffmpeg only has ogg, vorbis, and theora decoders
[21:16:32] <BastyCDGS> I was concerning fedora...
[21:16:41] <peloverde> so was I
[21:16:51] <BastyCDGS> but why then they write legal reasons?
[21:16:52] <peloverde> fedora won't ship the stripped down chromium version of ffmpeg
[21:17:30] <peloverde> cargo cult IP policy
[21:17:44] <BBB> why do you guys care about freetards with a 0.1% market share?
[21:17:59] <BastyCDGS> well I don't really care about fedora ;)
[21:18:07] <BBB> videolan has more installations on windows95 than fedora has installations in total
[21:18:09] <DonDiego> their linux market share is larger than that
[21:18:16] <BBB> and believe me, not many people run windows95
[21:18:20] <Kovensky> plus, almost everyone sane uses whatever-livna-is-called-now
[21:18:33] <BBB> DonDiego: all desktops, not linux
[21:18:37] <kierank> wow vlc still works on w95
[21:18:42] * BastyCDGS runs win9x for doing IT music
[21:19:10] * Kovensky hasn't run win9x in 8 years
[21:19:15] <DonDiego> BBB: i hardly see windows desktops these days
[21:19:15] <peloverde> I care about fedora because every ubuntu upgrade things break
[21:19:16] <BastyCDGS> it's the only config where IT still w/o problems runs on my relatively modern machine
[21:19:19] * kierank knows someone who uses windows 3.1
[21:19:27] <peloverde> I'd like a reasonable exit strategy
[21:19:45] <kierank> [22:19] <@peloverde> I care about fedora because every ubuntu upgrade things break --> yes, and delete your partition sometimes
[21:19:51] <BastyCDGS> pelo, are you using alien debs?
[21:19:54] <BBB> DonDiego: what do people around you use then?
[21:19:56] <BastyCDGS> and/or repos?
[21:19:58] <peloverde> no
[21:19:59] * BBB gone again btw
[21:20:14] <peloverde> I use a handful of PPAs they are unrealted to what breaks
[21:20:45] <BastyCDGS> well, after 2 years I prefer a fresh install anyway
[21:20:55] <peloverde> I do do clean installs
[21:20:55] <BastyCDGS> I'm also this LTS to LTS guy
[21:21:04] <DonDiego> BBB: macs, linux, the latter equally debian and ubuntu
[21:21:25] <DonDiego> i think i've only ever seen a fedora once in the wild
[21:21:27] <BastyCDGS> btw, I installed kubuntu 10.04 on my laptop running it in a virtualbox machine in 64-bit mode with win7 as host
[21:21:31] <peloverde> in this release, zuff is missing/fails post build tests, gvim spams shit to the console, gtkwebkit crashes constantly
[21:21:50] <BastyCDGS> what I realized was that many picture decoders don't show an Image anymore
[21:22:07] <BastyCDGS> or if they do only on very very small images (32x32 or alike)
[21:23:03] <BastyCDGS> installed kubuntu was the final one (i.e. no RC/beta/etc.)
[21:23:07] <peloverde> plus I wind up having to undo the obnoxious Ubuntu customizations like putting the close button next to the file menu
[21:23:21] <BastyCDGS> I also tried to fix the issue in ffplay without luck :(
[21:23:45] <BastyCDGS> I found out nice stuff how to avoid it to clear the background on window resize
[21:23:55] <BastyCDGS> but on switching to fullscreen it still happened
[21:25:13] <BastyCDGS> the other thing I found out is, on x86_64 the IFF demuxer/decoder segfaults if you enable libavfilter
[21:25:16] <BastyCDGS> and swscale
[21:25:20] <BastyCDGS> with configure
[21:26:11] <BastyCDGS> but latter bug has still to be retested on x86_32 for really be sure that's a 64-bit issue
[21:27:47] <BastyCDGS> I expect it though more be a kwin4 issue than be one of endianess
[21:28:36] * Kovensky wonders how are kwin4 or endianess related to word width
[21:32:12] <Kovensky> isn't win64 not working a regression in relation to 0.5?
[21:33:23] <BastyCDGS> kovensky, I meant I'm not sure yet if it's an 64-bit issue or a window manager, I just figured that ffplay is practically unusable with 10.04 / kwin4 within virtualbox with a win7 host
[21:33:38] <BastyCDGS> (for standalone pics)
[22:12:33] <Kovensky> siretart: isn't ffmpeg not compiling on win64 a regression
[22:12:55] <mru> it never did
[22:13:04] <Dark_Shikari> it's compiled on win64 just fine.  _WORKING_ is another story
[22:13:13] <mru> well, yeah
[22:14:00] <Kovensky> I remember people saying it worked until some commit broke win64 ._.
[22:14:04] <Kovensky> but I don't remember which commit
[22:14:13] <Dark_Shikari> no
[22:14:14] <Dark_Shikari> it never worked
[22:14:17] <mru> most of that asm is ancient
[22:14:24] <Kovensky> lol
[22:14:33] * Kovensky thinks working win64 should be in 0.6
[22:16:31] <ramiro> Kovensky: that's something different. it fails to compile swscale
[22:16:47] <ramiro> but even when that is fixed, it won't work properly
[22:17:08] <Dark_Shikari> Yeah.
[22:23:43] <ramiro> mru: building for win64 spams the console with "cc1: warning: -fPIC ignored for target (all code is position independent)" for every file. is there any way to avoid it?
[22:28:06] <mru> fix gcc
[22:28:20] <mru> -fPIC asks for PIC, gcc gives you PIC, what's it whinging about?
[22:32:19] <Kovensky> clang is worse on the unused parameter whinery :(
[22:32:28] <Kovensky> IIRC you need to give -Qunused-arguments
[22:34:00] <ramiro> mru: IIRC there's no off switch for that warning. I don't mind, but it worries some users... (the same that thing they found a bug because at the end of config.err it says alignment is not a power of 2)
[22:34:32] <ramiro> it's amazing how many people think that fixing that alignment "bug" is the solution to all their problems.
[22:34:59] <mru> ramiro: that's why I said "fix gcc"
[22:35:06] <mru> it's whining about something that isn't a problem
[22:35:16] <mru> it's doing exactly as it was asked
[23:13:39] <pengvado> kshishkov: random idea to save about 45 instructions in yuv2rgb24: http://pastie.org/946021 (untested)
[23:14:50] <pengvado> it should also be obvious how to apply pshufb to this
[23:16:18] <pengvado> on x86_64, the shift/store part could also use gprs, which allows the 2 byte stores to be actually 2 bytes
[23:20:41] <pengvado> why the nearest-neighbor chroma interpolation?
[23:28:25] <BBB> does anyone know what 'b' means in nm output?
[23:28:30] <BBB> from the top of their head
[23:30:27] <astrange> probably bss
[23:42:41] <DonDiego> gnite
[23:56:55] <BBB> mru: (ignorantly naive etc.), but what about e.g. alloca and calloc?
[23:57:00] <BBB> no good?
[23:57:21] <BBB> (I'm not strictly against malloc, I'm just affraid it'll affect performance in some unpredictable way on some systems)