[FFmpeg-devel-irc] IRC log for 2011-01-24

[irc at mansr.com]

[00:03:19] <ruggles> this is driving me insane... why would function parameters get loaded in the wrong registers?
[00:04:48] <pengvado> missing prototype?
[00:05:49] <ruggles> ah, maybe so.
[00:05:58] <ruggles> thanks
[01:04:49] <ruggles> still no luck on the param swapping. i'm setting up the function exactly like every other yasm function in ffmpeg...
[01:06:07] <ruggles> but at the start of the function, the values for r2 and r3 are reversed...
[01:08:05] <ruggles> x86inc.asm has r0,r1,r2,r3 as rdi, rsi, rdx, rcx for x86_64
[01:08:20] <ruggles> but my 4th param is getting loaded into rdx not rcx
[01:12:24] <roxfan> alignment?
[01:12:40] <roxfan> oh wait
[01:12:53] <roxfan> what about third param?
[01:15:04] <ruggles> 3rd param is a float...
[01:15:16] <ruggles> maybe it's going in a fp register instead?
[01:15:28] <roxfan> yep
[01:15:54] <ruggles> so i have to cast it to an int?
[01:16:11] <roxfan> i guess, if you need in integer reg
[01:27:49] <ruggles> ok, so the 3rd param gets passed in xmm0. but can i count on that?
[01:28:29] <saintdev> won't that depend on the calling convention?
[01:28:36] <Dark_Shikari> x86inc doesn't handle float params.
[01:28:41] <Dark_Shikari> because x264 never needed them
[01:29:33] <ruggles> inline asm it is... :(
[01:29:39] <mru> eeew
[01:29:52] <mru> it can't be that hard to fix the params in yasm
[01:36:44] <ruggles> maybe change PROLOGUE to  # args, # int regs, # float regs, # xmm regs, params... and list float params after int params
[01:38:13] <ruggles> but i don't know enough about x86 asm to know what to define them as on various arches
[01:39:38] <peloverde> can you just pass the float by pointer?
[01:41:11] <mru> that would be silly
[01:41:43] <mru> I doubt this is the last time this problem will surface
[01:41:52] <mru> we might as well solve it properly now
[01:42:40] <Dark_Shikari> peloverde: I did that for the one function in x264 that needed it.
[01:42:59] <mru> but here we're dealing with mostly-float code
[01:43:05] <Dark_Shikari> true
[01:43:08] <Dark_Shikari> in ffmpeg, it needs to be doe right
[01:43:10] <mru> shoving everything through pointers will kill performance
[01:48:32] <mru> btw, take a look at fate
[01:48:36] <mru> tell me what you think
[01:50:28] <saintdev> mru: perhaps warnings should be a link to compile log?
[01:50:37] <mru> good idea
[01:56:31] <mru> done
[01:59:36] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r5f3b8314a4 ffmpeg/configure:
[01:59:37] <CIA-43> ffmpeg: Add CFLAGS needed by PathScale compiler
[01:59:37] <CIA-43> ffmpeg: The PathScale compiler miscompiles wrapping arithmetic without
[01:59:37] <CIA-43> ffmpeg: these flags.
[01:59:37] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:01:23] <ruggles> so on x86_32 all params are on the stack, but x86_64 are in xmm (4 for windows, 8 for all other)?
[02:01:34] <ruggles> float params that is
[02:03:52] <Jumpyshoes> hrm, is reimar still active?
[02:04:28] <mru> Jumpyshoes: he's never on irc
[02:04:54] <mru> he was posting on the ml a few days ago at least
[02:04:58] <Jumpyshoes> oh, okay
[02:05:14] <Jumpyshoes> i have a patch that needs review, but probably got overwhelmed in the patchspam
[02:05:37] <mru> ping it and see what happens
[02:05:40] <Jumpyshoes> k
[02:14:02] <BBB> Dark_Shikari: is there a instruction that swaps the lower and higher word in a dword register?
[02:14:38] <mru> rotate 16
[02:15:33] <Dark_Shikari> rotate, yes
[02:19:03] <BBB> like ror edx, edx, 16?
[02:19:20] <BBB> cool
[02:19:22] <mru> sounds about right
[02:21:20] <ruggles> i can't see how a PROLOGUE macro with float args can be done for both x86_32 and x86_64 unless float args are always last (or always first).
[02:22:20] <Dark_Shikari> It can be done if the PROLOGUE macro is aware of the types of the args.
[02:22:23] <Dark_Shikari> this is hard.
[02:24:25] <BBB> ror is cool
[02:24:31] <BBB> wish I had known earlier :)
[02:25:42] <peloverde> I don't see anything wrong with requiring float parameters to be last
[02:26:04] <mru> me neither
[02:26:11] <mru> simplifies all kinds of things
[02:26:23] <mru> I have two calling conventions to deal with on arm too
[02:26:28] <uau> why do people insist on handling stuff like calling conventions in raw asm?
[02:26:40] <mru> uau: how else would you do it?
[02:26:43] <uau> is there any real advantage in not using inline asm for that?
[02:27:01] <uau> if you want more complex macros you could add a proprocessing stage before that
[02:27:13] <mru> yasm has a rather good preprocessor
[02:28:47] <uau> is it just that nobody has implemented that, or is there a real reason why it'd be good to avoid using gcc for things like calling conventions, access methods to globals, and correct elf sections?
[02:29:06] <mru> if gcc can fuck up, it does fuck up
[02:29:14] <mru> if you let it touch code, it can fuck up
[02:29:35] <mru> also, yasm is much nicer for writing code
[02:29:48] <mru> and you can't very well mix that with gcc inline
[02:29:57] <uau> nicer in a way that couldn't be done with a preprocessing step before gcc?
[02:30:15] <mru> what would that preproc do?
[02:31:07] <uau> try to emulate as much of that "nice yasm functionality" as possible
[02:33:14] <uau> you certainly could implement things like register renaming etc with that
[02:33:14] <mru> half the point is to avoid gcc
[02:33:14] <mru> it has the habit of spewing tons of crap around inline asm
[02:33:14] <saintdev> uau: the yasm preprocessor can do things like loops
[02:33:14] <mru> I'm surprised you don't know that already
[02:33:14] <BBB> omg that discussion again
[02:33:14] <BBB> uau: how much of the ffmpeg asm did you write?
[02:33:28] <BBB> try writing a couple dozen functions, you'll see why we use yasm :)
[02:33:44] <mru> BBB: git says none
[02:33:50] <uau> BBB: none i think
[02:34:02] <BBB> mru: it's scary how quickly you figured that out
[02:34:24] <mru> git log --author=Uoti libavcodec/x86
[02:36:42] <uau> BBB: and there are also reasons to avoid doing everything in completely raw asm - so what i was wondering about was not so much why you'd want to use yasm over "plain" inline asm, but how much of that functionality available in yasm would not be compatible with using gcc for some of the higher-level stuff
[02:37:38] <BBB> uau: raw asm is faster
[02:37:47] <BBB> don't you want your phone to play HD video from youtube?
[02:38:37] <uau> BBB: OTOH you add at least call overhead to everything you implement in yasm, so it can't be too tiny
[02:38:41] <BBB> or you mean using cc instead of yasm for preprocessor tricks?
[02:39:01] <uau> no, kind of the opposite
[02:39:25] <uau> using something "yasm-like" for the "preprocessor tricks"
[02:39:35] <uau> but using gcc as the backend to compile the result
[02:39:54] <uau> as it has support for a lot of stuff that is cumbersome to do manually, like all calling conventions etc
[02:40:17] <mru> but then gcc would be able to inject its poison
[02:41:21] <uau> mru: well gcc already does the calling side, and you're willing to take at least call overhead for everything you write in yasm anyway
[02:41:34] <BBB> call overhead is small
[02:41:38] <mru> it's a tradeoff
[02:41:46] <uau> i doubt the "poison" could be so much extra overhead that it'd matter for a lot of functions
[02:41:50] <mru> writing everything in asm would surely double the speed
[02:41:54] <uau> if it's still something run at most once per call
[02:42:05] <mru> but doing so isn't exactly feasible
[02:42:35] <BBB> I think for loop_filter_strength calculation, the gcc overhead around the inline asm made it take twice the cycles
[02:42:48] <BBB> gcc is like a civil servant
[02:42:50] <BBB> it does its job
[02:42:53] <BBB> it's busy
[02:42:56] <BBB> it does a lot of stuff
[02:43:03] <BBB> but the end result makes you wonder what it's doing all day
[02:48:03] <uau> so, are you seriously claiming that asking gcc to place function parameters into suitable registers would create so much overhead that it'd be an issue for a lot of functions?
[02:48:59] <mru> yes
[02:52:33] <uau> i have a hard time believing that
[02:58:18] <Jumpyshoes> changing a constant from a double to float could speed up a function by 5x
[02:58:20] <Jumpyshoes> in gcc
[02:58:49] <mru> not surprising
[02:59:03] <mru> double arithmetic is generally slower than floag
[02:59:05] <mru> float
[02:59:30] <Jumpyshoes> it's one constant. five times.
[03:06:35] <Dark_Shikari> Jumpyshoes: I've seen that before
[03:06:38] <Dark_Shikari> possibly even more extreme than that
[03:12:03] <uau> mru: can you construct a case where gcc would really screw up just "function arguments -> asm parameters" on amd64?
[03:12:37] <mru> Dark_Shikari would be a better person to ask for that
[03:13:51] <Dark_Shikari> be more specific?
[03:15:37] <uau> Dark_Shikari: mru claimed above that using gcc to compile asm would necessarily add so much overhead that it'd be an issue for a lot of functions
[03:16:10] <Dark_Shikari> I recall gcc doing too many stupid things in general for me to trust it.
[03:16:49] <uau> i find that hard to believe; so is there some example that would demonstrate gcc adding a lot of overhead for using it just for the calling convention, to move function parameters into suitable registers?
[03:16:53] <mru> one thing I've often seen gcc do is dump a bunch of callee-saved regs to stack and use those even though scratch registers are available
[03:17:25] <Dark_Shikari> uau: If you let gcc do register allocation, it will often be dumb.
[03:17:32] <Dark_Shikari> If you do it yourself, it will only be optimal on one architecture.
[03:17:38] <Dark_Shikari> Because you have to use explicit register names.
[03:17:40] <uau> mru: i could imagine gcc doing that - but i wouldn't expect that overhead to matter much for many functions
[03:17:42] <Dark_Shikari> Which will result in things getting moved around.
[03:18:04] <Jumpyshoes> there was that retarded compile bug that i fixed a while back
[03:18:12] <mru> uau: you are speculating, I and the others are speaking from experience
[03:19:03] <Jumpyshoes> i think it was transpose4x4
[03:19:55] <uau> mru: what was speculation about that? i don't think it's too speculative to say that one unnecessary load/store of some registers would not add that much overhead
[03:20:14] <Dark_Shikari> In a function that takes 30 clocks, 5 clocks spent load/storing kinda sucks.
[03:20:19] <mru> you've been speculating all along
[03:21:35] <uau> mru: of course it's somewhat speculative - nobody has written that kind of "gcc as a backend after preprocessing" system for ASM as far as i know
[03:22:55] <uau> but OTOH the fact that some people have worked on asm and not implemented that shouldn't automatically be taken as a proof that it would be a bad idea
[03:23:28] <mru> if you want us to believe you, you need to make such a system
[03:24:30] <uau> people certainly have worked with bad tools before, even people who managed to create something working well, so people having experience with and managing to implement things with current tools does not automatically prove that the tools are good
[03:25:04] <mru> I'm talking only about results here
[03:25:30] <mru> you're talking about doing brain surgery with a chainsaw
[03:33:56] <uau> i don't think there's anything which would make it that unreasonable
[03:34:45] <uau> gcc would have to try pretty hard to be able to waste more than a couple dozen cycles, and even that would still be useful for many classes of functions that do a significant amount of work at once
[03:36:08] <uau> and worrying about the absolute possible worst case how gcc _could_ screw up doesn't seem appropriate if you're still calling the function from code generated by gcc - in worst case gcc could really screw up that side just as well
[03:36:18] <saintdev> Zzzzz
[03:38:19] <BBB> Dark_Shikari: you're genious btw
[03:38:54] <BBB> Dark_Shikari: I wrote the yasm version of emu_edge which calls width-specific copy/extend "sub"functions, and it's a friggin close-to-100 cycles faster
[03:39:03] <BBB> it's ~170 cycles now for this particular test movie
[03:39:08] <BBB> when I started it was ~1000
[03:39:10] <BBB> \o/
[03:39:49] <Dark_Shikari> Nice.
[03:39:53] <Jumpyshoes> isn't that what offset(add|sub) does?
[03:40:00] <Dark_Shikari> Well, it's an approach I learned from Loren's cacheline code
[03:40:06] <Dark_Shikari> It's basically a switch statement.
[03:40:13] <BBB> right
[03:40:16] <BBB> except a very funkyone
[03:40:27] <Dark_Shikari> Are you using a jump table or a computed jump?
[03:40:33] <BBB> computed jump
[03:40:36] <Dark_Shikari> If it's the latter, you MUST CONFIRM that your functions are the right size on all arches
[03:40:41] <Dark_Shikari> There is no way to guarantee this in yasm
[03:40:51] <BBB> I did, I manually went over all of them in x86-64 and 32
[03:41:03] <Dark_Shikari> win64
[03:41:15] <BBB> commit, see if it breaks?
[03:41:17] <BBB> :-p
[03:41:17] <Dark_Shikari> lol
[03:41:23] <BBB> ramiro took down my account
[03:41:28] <BBB> I think he's pissed
[03:41:36] <Dark_Shikari> Also, you should make sure that you shrink things as much as possible
[03:41:38] <Dark_Shikari> how large is each function?
[03:41:40] <Dark_Shikari> in bytes
[03:41:47] <BBB> 64
[03:41:52] <BBB> (I know, that's a lot)
[03:42:05] <BBB> I haven't tried shrinking to 48 or so
[03:42:10] <BBB> it's probably possible to shirnk it
[03:42:57] <BBB> I couldn't shrink to 32, didn't fit
[03:43:16] <Dark_Shikari> How many are too large?
[03:43:34] <Dark_Shikari> You could also do it to something non-mod16
[03:43:35] <Dark_Shikari> like mod8
[03:43:51] <Dark_Shikari> If it would save a ton of space, you could use a jump table instead
[03:43:58] <Dark_Shikari> since here, each loop is being run many times
[03:44:02] <Dark_Shikari> so the cost of the initial jump isn't huge
[03:44:10] <Dark_Shikari> so if it saves space, it might be better to use a table
[03:44:43] <BBB> I can try
[03:44:51] <BBB> it'll probably save space
[03:44:58] <Dark_Shikari> That means btw that you should STOP aligning them
[03:45:02] <Dark_Shikari> so no nops between sections
[03:45:05] <BBB> I've got 24x4xsizeof(function) bytes here
[03:45:10] <Dark_Shikari> Then again...
[03:45:10] <BBB> I know :)
[03:45:15] <Dark_Shikari> Here's another thing to consider
[03:45:31] <Dark_Shikari> Each time you call emulated_edge, you will be using three loops
[03:45:31] <BBB> but 24x4=96x0x40=0x1800 bytes
[03:45:34] <Dark_Shikari> er, four loops
[03:45:38] <Dark_Shikari> one to fill top/bottom
[03:45:40] <Dark_Shikari> one to fill mid
[03:45:43] <Dark_Shikari> one to fill left
[03:45:45] <Dark_Shikari> one to fill right
[03:45:46] <Dark_Shikari> right?
[03:45:48] <BBB> yes
[03:45:56] <Dark_Shikari> The odds of any of these overlapping in the same cacheline is low.
[03:46:03] <BBB> yes
[03:46:06] <Dark_Shikari> Therefore, odds are that your initial jump, no matter what, will be an L1 instruction cache miss.
[03:46:20] <Dark_Shikari> So it doesn't actually matter how much space they take up as long as each one fits in a cacheline.
[03:46:24] <Dark_Shikari> Probably.
[03:46:48] <mru> in that case, make sure they're aligned on cache lines
[03:48:49] <Dark_Shikari> Yeah, sounds like a good idea
[03:48:57] <Dark_Shikari> and fuck x86 cpus with 32-byte cachelines
[03:49:30] <mru> still better two than three
[03:51:00] <Dark_Shikari> Of course
[03:51:27] <pengvado> Dark_Shikari: you can ask yasm for padding up to a certain size, and I think you can also assert based on the numerical value of the difference between 2 labels.
[03:52:12] <pengvado> so you have to manually figure out what the size should be, but you can ensure that it won't silently miscompile if you get it wrong
[03:54:23] <Dark_Shikari> Ah, nice.
[04:48:58] <relaxed> http://pastebin.com/raw.php?i=YyjLCNUT
[05:49:58] <drv> relaxed: can you do 'display /i $pc' in gdb too?
[05:50:03] <drv> should show which instruction it is
[05:50:30] <drv> (if your source lines match up to mine, that is a femms under if (flags & SWS_CPU_CAPS_3DNOW)
[06:05:15] <relaxed> drv: 1: x/i $pc  0x90850e <swScale_3DNow+10814>:     femms
[06:14:40] <drv> hmm, do you have a 3dnow-capable CPU?
[06:21:55] <relaxed> drv: I don't believe so, it's a Intel(R) Core(TM)2 CPU T7600
[06:23:55] <cartman> moin
[06:25:03] <thresh> moroning
[06:25:24] <_av500_> guten morgen
[06:26:25] <thresh> it's monday morning, no way it could be good
[06:27:06] <cartman> thresh: agreed
[06:27:13] <cartman> got a boring meeting in 5 minutes
[06:28:10] <kshishkov> thresh: you can discover it's not true if you move outsize 100.500th Moscow Ring road (aka Russian state border)
[06:29:43] <thresh> kshishkov: that would make me get to bed earlier on Sundays?
[06:31:58] <kshishkov> thresh: probably, some European countries have limitations on what can be opened on Sunday
[06:33:18] <thresh> kshishkov: I only had 'Sprite' and lemon slices, are those prohibited in The Promised Lands?
[06:34:24] <cartman> Sprite is OK
[06:43:10] <_av500_> sprite and lemon slices
[06:43:20] <_av500_> russia is not what it used to be
[06:43:35] <_av500_> since when do they have lemon slices
[06:48:02] <lu_zero> good morning
[06:48:17] <cartman> moin lu_zero
[06:48:21] <lu_zero> _av500_: nag me about the mpegts chain demuxer later in the week
[06:48:26] <lu_zero> possibly once a day
[06:49:27] <thresh> _av500_: the joys of globalization
[06:49:28] <lu_zero> uau: having gcc provide that kind of result would be nice, nobody tries and succeeded to my knowledge
[06:49:58] <thresh> it's actually cheaper to import turkish potatoes than to grow them even in the most fertile grounds
[06:50:50] * cartman notes that
[06:52:34] <_av500_> thresh: so all the russians at the mediteranean are just moving closer to the potatoes?
[06:55:42] <thresh> _av500_: could be true as potatoes are our favourite food
[06:55:50] <thresh> except for vodka of course
[07:02:38] <lu_zero> thresh: how so?
[07:03:06] <lu_zero> I mean there are potatoes and topinanbour that resist cold quite well
[07:10:00] <thresh> lu_zero: I have no idea, but that's what I see on the shelves of supermarkets
[07:10:05] * lu_zero sometimes wonders why people are so fixed on potatoes and forgets topinambour
[07:10:08] <thresh> no russian potatoes here
[07:11:02] <lu_zero> thresh: topinambour are pretty much more interesting than potatoes and they grow more or less everywhere you leave them IIRC
[07:12:03] <thresh> lu_zero: topinambours are exotic in Russia
[07:12:38] <thresh> no idea why actually, probably potato growers lobby =)
[07:12:48] <lu_zero> thresh: start growing them! Might be interesting
[07:32:14] * lu_zero wonders
[07:32:16] <lu_zero> ff_h264_get_slice_type+0x138
[07:32:43] * lu_zero is too lazy to disasm by hand
[07:33:04] <lu_zero> is there a simpler way to spot the line referred?
[07:34:37] <lu_zero> give it's just a switch
[07:35:01] <lu_zero> I think it should be the h->slice_type
[07:35:08] <lu_zero> but isn't that a bit too far?
[07:38:34] <drv> it could be in a static function that is after that symbol
[07:39:41] <cartman> _av500_: http://www.youtube.com/watch?v=FKG34jlZdqo
[07:40:27] <thresh> "The story takes place in 1632 in Istanbul, where he will attempt the first flight of the human being." hmmm I thought that was the Icarus
[07:40:58] <kierank> cartman: rip off of aladdin
[07:40:59] <kierank> ;)
[07:41:07] <cartman> kierank: heheh no :)
[07:41:30] <lu_zero> drv: ^^;
[07:41:53] <cartman> the story as I have been told is someone steals Leonardo DaVinci's drawings of human-wings and somehow Hezarfen gets hold of them
[07:41:57] <cartman> and starts implementing one
[07:55:55] <spaam> God morgon
[08:05:07] <superdump> god morgon spaam
[08:05:20] <av500> cartman: thx for wasting 3:42 of my life...
[08:05:37] <cartman> av500: thats why I am here for
[08:06:02] <spaam> superdump: allt bra? :)
[08:06:03] <saintdev> av500: demand a refund
[08:06:15] * cartman refunds av500 3:43
[08:06:27] <spaam> Nice. one extra
[08:06:58] <saintdev> cartman has excellent customer service o.O
[08:07:03] <cartman> :D
[08:07:14] <superdump> spaam: mostly
[08:07:16] <saintdev> didn't even need an RMA
[08:07:27] <superdump> cat sprained its knee by slipping on the bath yesterday
[08:07:39] <superdump> and he's protesting against resting right now :)
[08:08:16] <spaam> hehe :)
[08:21:53] <cartman> http://dilbert.com/fast/2011-01-24/ heheh
[08:26:44] <spaam> haha
[08:28:44] <kshishkov> cartman: http://comics.com/pearls_before_swine/2011-01-23/
[08:29:49] <cartman> kshishkov: heheh
[08:30:22] <spaam> kshishkov: is that how you do it? :)
[08:30:46] <kshishkov> spaam: nope, I shun social networks completely
[08:31:08] <spaam> aww
[08:31:55] * cartman hates Facebook
[08:32:28] <kshishkov> cartman: I think only Dark_Shikari here has a right to hate it
[08:32:45] <spaam> cartman: KotH hates me on facebook.. he never accept my friend reqeust :(
[08:32:51] <cartman> kshishkov: why?
[08:32:56] <cartman> spaam: that bastard
[08:32:57] <cartman> :D
[08:33:00] <elenril> KotH has a facebook account?
[08:33:06] <spaam> yes
[08:33:30] <cartman> spaam: he didn't even tell me he had one :D
[08:33:31] <kshishkov> cartman: read http://x264.nl/developers/Dark_Shikari/consulting.html
[08:34:20] <spaam> cartman: KotH can be a bit shy sometimes.
[08:34:27] <cartman> kshishkov: nice rates
[08:34:42] <cartman> spaam: He secretly hates me :P
[08:34:58] <cartman> kshishkov: I think Facebook is nice engineering-wise
[08:35:24] <spaam> cartman: i know the feeling.. he used to kick and ban me.. :)
[08:35:33] <kshishkov> cartman: well, he can ask them and there companies willing to pay them, he's not you (i.e. not in Turkey)
[08:36:02] <cartman> kshishkov: yeah I get nicely paid here, never mind me rumbling all the time :D
[08:37:33] <spaam> cartman: is that why you have more then one wife?
[08:37:53] <cartman> spaam: no thats because we are not a secular state anymore
[08:37:56] <cartman> up to 4 allowed
[08:38:28] <kshishkov> cartman: you should have ended that sentence with "Allah akbar"
[08:38:40] <spaam> haha
[08:38:44] <cartman> kshishkov: Ma$allah brother
[08:50:26] <wbs> lu_zero: would you like to rebase the switch->poll patchset on top of the latest version and apply it sometime? it's annoying to know that such a change is coming, without actually having it in the main tree :-)
[08:55:05] <lu_zero> wbs: uh...
[08:55:14] <lu_zero> that's something I was about to forget...
[08:55:18] <lu_zero> thanks for reminding
[09:01:59] <lu_zero> rebased now
[09:02:05] <lu_zero> testing ^^;
[09:21:09] <j0sh> should ff_yuv2rgb_coeffs be public?
[09:21:34] <j0sh> there is no real way to call sws_setColorspaceDetails without it
[09:22:36] <j0sh> other than writing the coeffs yourself into the parameters
[09:24:16] <cartman> http://www.mesa3d.org/MESA_ycbcr_texture.spec looks interesting
[09:25:28] * kierank hates reading ascii specs
[09:25:48] <cartman> kierank: you like PDF ones better? :p
[09:25:56] <kierank> yeah
[09:26:32] <j0sh> kierank: you must *really* hate RFCs then
[09:26:48] <kierank> yes, yes i do
[09:30:14] <kierank> I actually considered writing a script to convert them to a readable font
[09:31:21] <j0sh> you could make a bookmarklet that swaps out the css for something custom
[09:31:45] <j0sh> oh, they're plain text, no css, lol
[09:32:00] * j0sh needs sleep
[09:34:28] <pross-au> kierank: so you need diagrams? ascii can do that
[09:35:06] <kierank> i don't have a problem with ascii diagrams
[09:35:25] <kierank> it's just when there's a wall of text (that isn't code) I'd rather it be in something readable
[09:36:03] <kierank> also my other gripe with specs is when they have loads of syntax element tables then explanations after so you have to scroll up and down to read the syntax element and the explanation
[09:36:07] <pross-au> that markdown format is pretty need
[09:36:11] <pross-au> *neet
[09:36:24] <j0sh> i think well styled ascii is a lot more readable than, say, the h264 spec
[09:36:36] * cartman hands pross-au a "neat"
[09:36:58] <j0sh> MS word formatted times new roman just makes me want to gouge my eyes out
[09:37:37] * kierank has that opinion for ascii specs
[09:37:37] <pross-au> agree with you on the jumping around bit
[09:38:00] <pross-au> MPEG-4 Part 2 is like a choose your own adventure
[09:38:31] <kierank> 13818-1 has it right
[09:38:39] <kierank> you don't need to scroll like hell
[09:41:33] <j0sh> specs need to be LaTeX'd, especially ones that are equation heavy
[09:41:44] <j0sh> and syntax elements properly monospaced
[09:41:45] <kshishkov> +2.71
[09:41:57] <j0sh> i think those are my two biggest gripes with most pdf specs
[09:42:44] <lu_zero> s/LaTeX'd/formatted in a decent way no matter how/
[09:43:12] <lu_zero> LaTeX originated pdf might gouge your eyes as well
[09:43:34] <lu_zero> e.g. sporting a screen-unfriendly font
[09:43:35] <j0sh> i suppose but at least latex will usually do a good job of making the presentation nice
[09:45:07] <j0sh> i just realized something
[09:45:14] <j0sh> the h264 spec is justified
[09:45:44] <kierank> yep
[09:45:46] <j0sh> the spacing is all whacky, thats prob part of the reason i don't like it
[09:51:52] <kshishkov> j0sh: say hello to your friend M$ Word and its flexible interword spacing then
[09:52:07] <kshishkov> that's where most of those documents were made
[09:52:29] <kierank> s/most/all
[09:53:31] <kshishkov> SWF spec was made in FrameMaker
[09:54:08] * kierank doesn't consider fruit or flash related specs relevant
[09:57:40] <kshishkov> VP8 spec was converted from HTML
[09:58:04] <kierank> VP8 spec was converted from C
[09:58:29] <j0sh> the swf spec is actually really nice
[09:58:50] <j0sh> the rtmp spec, on the other hand...
[09:59:21] <kshishkov> j0sh: well, if company that mades its buck from publishing and design publishes spec in eye-watering style it's a sure sign of megafail
[09:59:54] <kshishkov> RTMP spec looked like quick convert from RFC
[10:00:17] <kshishkov> which showed how much they cared for it
[10:00:21] <kierank> kshishkov: what about rv40 spec
[10:01:30] <kshishkov> kierank: Word
[10:02:02] <j0sh> eugen andrei (c++ rtmp server creator) had a really good description of the rtmp spec
[10:02:10] <j0sh> "That doc is the work of a sunday-drunk Adobe employe in a rainy monday morning with a 6 foot tall boss shouting at him"
[10:02:57] <kshishkov> j0sh: "c++ rtmp server creator" means nothing since there are dozens of RTMP server in any language including VB
[10:03:51] <j0sh> https://groups.google.com/group/c-rtmp-server/msg/3c3d13842a30e3f6
[10:04:06] <j0sh> yeah but he wrote *the* c++ rtmp server, like that is the name of the project :)
[10:04:44] <j0sh> it's actually a nice implementation, minus the mountains of C++ template hackery
[10:04:56] <j0sh> follows the behavior of flash/fms closer than anything else i've seen
[10:05:47] * kshishkov is disgusted by RTMP
[10:06:12] <j0sh> join me and lu_zero in brooding
[10:06:21] * lu_zero is disgusted by rtmp and C++
[10:06:53] <kshishkov> lu_zero: and you know that I have my reasons to hate RTMP
[10:07:20] <kshishkov> C++ not that much because I've not tried reading new specs for it
[10:07:35] * lu_zero did
[10:07:44] <lu_zero> I was foolish enough to
[10:08:07] * kshishkov is extremely disgusted by Boost, strongly disgusted by STL and just disgusted by the rest of C++
[10:25:32] <peloverde> with the exception of std::vector<bool> STL isn't so bad
[10:27:39] <kshishkov> it's horrible
[10:28:50] <kshishkov> when I moved from C++ different compilers had different support for STL and no one used its string class
[10:32:39] <merbzt> no being able to read code without an IDE makes it hard to understand at times
[10:35:41] <kshishkov> reminds me of that small symbol mru found once - that took ~36k in demangled form
[10:37:20] <ubitux> is there anyone working on the vf_drawtext filter (soc)?
[10:37:49] <kshishkov> peloverde: BTW, do you think anybody else is going to review my wavpack patch?
[10:38:18] <superdump> do we have anyone who knows wavpack or has the spec?
[10:38:20] <superdump> other than you
[10:38:30] <superdump> (is there a spec)
[10:39:00] <kshishkov> there is
[10:39:21] <peloverde> kshishkov: my guess is no
[10:39:28] <kshishkov> superdump: http://www.wavpack.com/file_format.txt
[10:40:01] <kshishkov> superdump: and http://matroska.org/technical/specs/codecid/wavpack.html
[10:40:46] <superdump> perhaps spam those links to the ML in case anyone else wants to check it
[10:40:55] <superdump> i'm afraid i don't have time right now
[10:41:45] <peloverde> add a multichannel sample to fate so no one breaks it
[10:42:26] * kshishkov is not into encoding
[10:42:41] <kshishkov> peloverde: you can ask me to create AAC samples though
[10:43:09] <peloverde> surely you must have had a sample to test this patch on?
[10:43:46] <kshishkov> yep, ~350MB of samples for 1.0, 2.0, 4.0, 5.1, 6.1 and 7.1
[10:44:16] <peloverde> just add a small clip of 5.1 or 7.1
[10:44:17] <kshishkov> the guy asking for support was nice to encode them for testing
[10:51:00] <kshishkov> in any case I'd be able to create fate test only on Wednesday or later
[10:54:37] <lu_zero> 11:35 <@kshishkov> reminds me of that small symbol mru found once - that took  ~36k in demangled form
[10:54:59] <lu_zero> that was from boost:spirit
[10:55:37] <lu_zero> so probably it was a full parse graph encoded in a symbol
[10:56:42] <superdump> mru: random suggestion if possible - on fate, perhaps clicking on the coloured bar at the top could filter out those items of that colour
[10:56:55] <superdump> with some intuitive way to go 'back' to unfiltered
[11:00:22] <superdump> actually i guess with sorting it's not so necessary
[11:00:24] <superdump> nevermind
[11:42:58] <cartman> when converting YUV420P to RGB, should I convert it to YUV444 packed first?
[11:43:09] <av500> ??
[11:43:16] <kshishkov> of course not
[11:43:43] <spaam> first to YUV444 then back to YUV444p then RGP..
[11:44:15] <cartman> I should have known not to trust Microsoft (ref. http://msdn.microsoft.com/en-us/library/ms893078 )
[11:44:18] <av500> and some HSV000 inbetween?
[11:44:27] <cartman> To convert 4:2:0 or 4:2:2 YUV to RGB, convert the YUV data to 4:4:4 YUV, and then convert from 4:4:4 YUV to RGB.
[11:44:38] <spaam> av500: yes.
[11:47:37] <j-b> anyone around FFmpeg that is from NetFlix©® ?
[11:48:08] <cartman> Consider I have a YUV420P sample.yuv file I can create Y,U,V arrays by directly reading from the file
[11:48:19] <cartman> then I'd have to match (U,V) tuples for each Y value
[11:48:46] <cartman> or I could read the whole file into an array and setup Y,U,V arrays
[11:49:15] <cartman> but then U and V values would be duplicated
[11:49:47] <cartman> is that OK? Was my question clear? :)
[11:50:23] <wbs> cartman: just iterate through two Y-rows, one U-row and one V-row at the same time, then you get Y,U,V-tuples
[11:50:31] <wbs> cartman: then convert each YUV-tuple into RGB and store into the output
[11:51:05] <wbs> cartman: so if you want to see it that way, it is converted to yuv444 inbetween, but that version isn't stored anywhere
[11:51:27] <cartman> wbs: that was what I am asking, thanks :)
[11:51:44] <cartman> so its actually converted :)
[11:53:35] <lu_zero> cartman: reading swscale won't help?
[11:53:48] <cartman> lu_zero: too complex for learning basics :)
[11:54:02] <wbs> lu_zero: I don't think swscale is the best/most pedagogic introduction into the subject :-)
[12:00:58] <lu_zero> wbs: the loop code in C should be simple
[12:01:14] <wbs> lu_zero: probably, but finding it if you're totally new to the subject isn't easy
[12:01:27] <wbs> and you'll be scared off long before you've found that loop :-)
[12:01:29] <lu_zero> ^^;
[12:01:54] <kshishkov> I wasn't
[12:03:04] <lu_zero> libswscale/yuv2rgb.c is yours isn't it?
[12:09:24] <kshishkov> lu_zero: no, it's FFmpeg's
[12:09:47] <av500> no it's lu_zero's now
[12:23:08] <lu_zero> av500: luckily not =P
[12:23:16] <lu_zero> kshishkov: I mean you wrote it last time
[12:23:28] <kshishkov> lu_zero: so what?
[12:23:40] <lu_zero> so you can tell cartman where to look inside it ^^;
[12:23:41] <kshishkov> lu_zero: I've looked at the previous version too
[12:27:21] <lu_zero> I see
[12:58:06] <mru> merbanan: seen fate recently?
[13:00:28] <kshishkov> mru: is "±" sign is that you may get warnings more or less?
[13:00:39] <mru> click and see
[13:01:11] <kshishkov> first five configs are empty
[13:01:42] <mru> it gives you a diff from the previous compile log
[13:01:56] <kshishkov> sucks with tmpnames though :(
[13:02:49] <kshishkov> still, it's a nice feature
[13:04:31] <av500> the +/- gives empty pages here :(
[13:04:46] <mru> there was no change there
[13:05:17] <av500> is should say :"this webpage intentionally left blank"
[13:06:25] <av500> hmm, most diffs seems to be -j N related
[13:06:36] <mru> yes, I'm afraid so
[13:07:29] <av500> ca we blame drepper?
[13:07:31] <av500> can
[13:07:40] <mru> I don't think so
[13:07:50] <mru> make -jN isn't deterministic
[13:07:57] <mru> especially not on a busy system
[13:08:09] <av500> i know :)
[13:09:12] <av500> what is the new policy on warnings?
[13:09:28] <kshishkov> avoid them unless it's gcc farts?
[13:09:50] <mru> fix the cause, not the warning
[13:11:07] <av500> kshishkov: http://fate.ffmpeg.org/?dsort=nwarn
[13:11:10] <av500> not just gcc :)
[13:12:46] <mru> it's not so strange that the more obscure systems and compilers show more warnings
[13:12:50] <kshishkov> but it definitely leads the way
[13:13:13] <av500> there are 2 entries without warnings shown
[13:13:17] <av500> but they have some
[13:13:48] <mru> they haven't reported since the warning count was added
[13:13:53] <av500> ah
[13:14:16] <av500> cartman: ^^^ get your fate up to speed
[13:15:07] <cartman> av500: wut
[13:15:14] <cartman> I already FATEd in the morning
[13:15:25] <av500> fainted maybe?
[13:15:30] <cartman> http://fate.ffmpeg.org/x86_64-apple-darwin10-clang
[13:16:42] <av500> this not yours: http://fate.ffmpeg.org/opensuse-factory-clang ?
[13:16:54] * cartman hides
[13:17:20] <cartman> binutils 2.21 has a new ld bug, goes out of memory while linking llvm
[13:17:24] <cartman> thats why
[13:23:07] <lu_zero> ?
[13:23:13] <lu_zero> binutil or llvm?
[13:23:20] <cartman> lu_zero: binutils
[13:23:26] <lu_zero> gold or plain?
[13:23:29] <cartman> plain
[13:24:32] <j-b> mru: I don't want to say bad things of my friends from India, but I believe this is crap
[13:24:45] <lu_zero> which?
[13:27:42] <kshishkov> j-b: your friends from India working on VLC or on Symbian?
[13:27:53] <av500> both
[13:28:05] <av500> getting vlc into the OVI store
[13:28:17] <kierank> I was surprised how big OVI store is
[13:28:25] <lu_zero> Compn: "original" doesn't sound correct to me.
[13:28:25] <av500> how big?
[13:28:47] <j-b> quite big, in Asia
[13:28:53] <kierank> http://thenextweb.com/asia/2011/01/20/nokia-ovi-store-is-the-top-application-store-in-china/
[13:29:10] <j-b> mru: anyway, the only actual Symbian Expert I know is a FFmpeg developer: wbs
[13:29:53] <kierank> what about courmisch?
[13:31:24] <j-b> courmisch doesn't do any Symbian work
[13:31:29] <j-b> he says: it's crap
[13:31:35] <kierank> i see
[13:31:42] <av500> he is right :)
[13:31:49] <j-b> the cool thing about working on Symbian is that: if we fail, noone will care :)
[13:31:55] <mru> I have a theory for how this has happened
[13:31:58] <wbs> j-b: lol
[13:32:17] <j-b> but if it works, that will be cool
[13:32:38] <j-b> however, VLC on Symbian will have almost no codec/no demuxer except ffmpeg
[13:33:09] <av500> j-b: er, what other do you need?
[13:33:32] <j-b> av500: tremor, probably
[13:33:55] <av500> and you fail to compile that for symbian?
[13:34:13] <kshishkov> j-b: sponsor intger-only decoding for lavc audio ;)
[13:34:36] * av500 is reminded that he still drag thats integer cook patch around
[13:34:39] <av500> +s
[13:34:51] <wbs> av500: who uses cook?
[13:34:57] <j-b> kshishkov: well, we could make VLC on OVI a paid app and then sponssor it, not stupid idea
[13:34:58] <av500> wbs: RA?
[13:35:12] <wbs> av500: eww
[13:35:17] <av500> wbs: cook is real audio
[13:35:23] <wbs> av500: IC
[13:35:52] <av500> i guess I could use the float cook on the omap3, I just have the integer patch for historic reasons :)
[13:36:03] <av500> and I like keeping it alive
[13:38:34] <j-b> mru: anyway, only wbs can tell us what the true solution is
[13:39:10] <Compn> lu_zero : suggestions welcome
[13:39:29] <Compn> lu_zero : note i didnt ask michael what he wanted so its just what came out of my head :p
[13:40:59] <mru> I suspect the loader doesn't allow resolving a non-call address against the plt
[13:44:03] <wbs> I'll try to dig into the area a bit
[13:46:17] * kshishkov gives wbs traditional Russian weapon
[13:46:29] <cartman> http://fate.ffmpeg.org/opensuse-factory-clang updated
[13:46:30] <pJok> vodka bottle?
[13:46:34] <av500> shovel
[13:46:45] <kshishkov> see, even av500 knows that
[13:46:55] <av500> cartman: 208 warnings, rejected!
[13:47:06] <cartman> av500: better than gcc.com
[13:47:10] <av500> kshishkov: been here too long...
[13:47:34] <kshishkov> av500: not long enough - you still don't speak Turkish
[13:47:59] <kshishkov> or for other value of "here" - you still don't speak Swedish
[13:48:18] <lu_zero> nor Japanese
[13:48:53] * pJok speaks swedish, is working on the japanese part
[13:48:55] * lu_zero should keep studying swedish
[13:49:13] * kshishkov should too but he's distracted by German
[13:50:10] <mru> now where's that page listing dangerous swedish homophones?
[13:50:31] <mru> kshishkov: german and swedish are almost the same thing :)
[13:50:38] <cartman> homophone?
[13:50:41] <cartman> a new smartphone?
[13:51:04] <kshishkov> mru: http://sv.wikipedia.org/wiki/Lista_%C3%B6ver_falska_v%C3%A4nner_mellan_svenska_och_engelska
[13:51:30] <thresh> kshishkov: http://www.putingoodbye.ru/
[13:51:37] <kshishkov> mru: Swedish sounds much nicer than German, has simpler grammar and shorter words
[13:51:57] <kshishkov> thresh: за вами уже выехали
[13:52:43] <kshishkov> cartman: the things that sounds similar, like "meet" and "meat"
[13:53:29] <mru> kshishkov: Donaudampfschiffahrtselektrizitätenhauptbetriebswerkbauunterbeamtengesellschaft
[13:53:32] <lu_zero> then the best will be using runes to write in japanese the ffmpeg documentation
[13:53:53] <lu_zero> mru: what's that?
[13:53:58] <av500> a word
[13:54:01] <lu_zero> I quitted parsing it halfway
[13:54:19] <kshishkov> mru: http://en.wikipedia.org/wiki/Rinderkennzeichnungs-_und_Rindfleischetikettierungs%C3%BCberwachungsaufgaben%C3%BCbertragungsgesetz
[13:54:27] <cartman> wbs: now I am able to produce my colors-are-drunk image again :D
[13:54:36] <cartman> I guess the U/V formula is fucked up
[13:54:37] <mru> translation: Association for subordinate officials of the head office management of the Danube steamboat electrical services
[13:55:04] <av500> kshishkov: this one is nice
[13:55:11] <kshishkov> yes, it's popular root to produce even shorter words
[13:55:18] <kshishkov> av500: and it's legal!
[13:55:20] <mru> kshishkov: Nordöstersjökustartilleriflygspaningssimulatoranläggningsmaterielunderhållsuppföljningssystemdiskussionsinläggsförberedelsearbeten
[13:55:58] <lu_zero> mru: made up?
[13:56:05] <kshishkov> mru: google refuses to acknowledge its existence
[13:56:23] <mru> lu_zero: yes
[13:56:41] <lu_zero> google thinks its Norwegian
[13:56:53] <lu_zero> but couldn't get the meaning
[13:56:56] <kshishkov> maybe it's Fenno-Swedish
[13:56:57] <JEEB> järjestelmällisentelentelemättömyydellänsäkään ← without putting together multiple words (not yhdyssana)
[13:57:32] <JEEB> (yes, that's the Finnish word 'järjestelmällisyys' with a lot of informative endings)
[13:58:45] <JEEB> with putting together a compound word you can make a real word in Finnish that's as long if not even longer than what mru's saying :3
[13:58:51] <pross-au> Please use hyphenation :P
[13:59:09] <merbzt> mru: that symbian patch, I see no way to work around the linker issue cleanly
[13:59:12] <mru> pross-au: like this? összetettszóhosszúságvilágrekorddöntéskényszerneurózistünetegyüttes-megnyilvánulásfejleszthetőségvizsgálatszervezésellenőrzésiügyosztály-létszámleépítésellenesakciócsoporttagságiigazolványmegújításikérelem-elutasítóhatározatgyűjteményértékesítőnagyvállalatátalakításutó-finanszírozáspályázatelbírálóalapítványkuratóriumelnökhelyettesellenes-merényletkivizsgálóbizottságiülé
[13:59:31] <pross-au> does that gunzip to something?
[13:59:34] <JEEB> lol
[13:59:35] <mru> merbzt: fix the linker?
[13:59:38] <kshishkov> mru: elenril would call it The True Black Speech (aka Hungarian)
[13:59:46] <pross-au> Night
[14:00:16] <merbzt> mru: yeah, hard to do on a symbian phone, buy the next one in the series I guess
[14:00:40] <av500> merbzt: just send it the SMS-o-death
[14:01:20] <kierank> av500: same goes for the base station
[14:07:14] <cartman> there are many YUV->RGB matrices and most are not compatible
[14:07:18] <cartman> why tf? :)
[14:07:33] <mru> that's the good thing about standards, so many to choose from
[14:07:35] <cartman> compatible as in give completely unrelated values for the same YUV input
[14:08:34] <cartman> http://cekirdek.pardus.org.tr/~ismail/4.png but my colors are f*cked up now
[14:09:14] <mru> and saturated
[14:09:43] * cartman wonders if he is writing the RGB24 file wrong
[14:10:16] <kshishkov> cartman: at least it should convince mru there are worse things than swscaler
[14:10:30] <cartman> kshishkov: heheh
[14:10:54] <mru> anyway, we have a patch queue to review
[14:11:08] <av500> kshishkov: we should commits cartman's code as-in and clean later!
[14:11:24] <av500> libavlsd maybe?
[14:11:33] * kshishkov nominates av500 into next Michael
[14:11:51] <kshishkov> bonus points for creating new library
[14:11:57] <cartman> stop mocking I am trying to learn here ;)
[14:11:58] <av500> I did
[14:12:06] <av500> cartman: you learn, we mock
[14:12:08] <av500> that is the deal
[14:12:21] <cartman> av500: speculate on colors first
[14:12:22] <cartman> :P
[14:12:25] <cartman> then you can mock
[14:12:29] <kshishkov> cartman: that's called learning with negative stimulus
[14:13:02] <av500> cartman: sorry, but why dont you take a few known yuv values and check your rgb output for them?
[14:13:14] <mru> like 0,0,0
[14:13:19] <mru> should give green
[14:13:25] <av500> instead of your randon coefficient approach
[14:13:26] <cartman> av500: that would make sense if there is a common YUV<->RGB mapping
[14:13:32] <kshishkov> cartman: is that too hard to take input YUV, multiply it by any set of coefficients given in Wikipedia and output RGB triplets in PPM file?
[14:13:36] <av500> cartman: they should be similar
[14:13:42] <mru> av500: he does programming by the monte carlo method
[14:13:46] <cartman> kshishkov: thats what I did :)
[14:13:50] <Kovensky> av500: no, no, name it libsd instead
[14:14:03] <av500> Kovensky: right!
[14:14:08] <kshishkov> cartman: show teh codez
[14:14:20] * av500 assumes rand() is involved
[14:14:34] <kshishkov> cartman: if that's what you get with plain C you're really screwed
[14:14:45] <cartman> http://cekirdek.pardus.org.tr/~ismail/yuv2rgb.c
[14:15:16] <mru> float?!?!!!!!
[14:15:33] <cartman> calm down mru :P
[14:16:51] <kshishkov> cartman: I hope you remember UV is signed
[14:16:52] <av500> cartman: wtf with all the fseeks?
[14:17:06] <kshishkov> av500: that's putpixel() calls :)
[14:17:08] <Kovensky> mmap man, mmap!
[14:17:25] <cartman> av500: those are unrelated to the problem
[14:17:41] <av500> ah, this isn't perl code...
[14:17:43] <cartman> kshishkov: I use uint8_t for them
[14:18:08] <kshishkov> cartman: try subtracting 128 from U/V during conversion
[14:18:18] <cartman> signed
[14:18:19] <cartman> uhm
[14:18:23] <cartman> f..k
[14:18:26] <mru> can we tag the ancient patches vitor sent so they don't clutter up the patchwork view so badly?
[14:18:34] <kshishkov> av500: be proud he's agreed working for you!
[14:18:35] <cartman> mru: reject them
[14:18:49] <mru> there's this 'archive' option
[14:18:52] <mru> what does that do?
[14:18:59] <av500> kshishkov: not yet :)
[14:19:00] <kshishkov> cartman: it's stored as unsigned but with 128 bias
[14:19:42] <cartman> kshishkov: U,V -= 128 before processing?
[14:19:50] <mru> yes
[14:19:51] <kshishkov> yep
[14:20:03] <kshishkov> and don't store them back to uint8_t
[14:20:05] <cartman> different bad colors but not saturated it seems
[14:20:29] <mru> ok, I'm setting these old patches to state "RFC"
[14:20:34] <cartman> kshishkov: what should I store them into?
[14:20:42] <kshishkov> cartman: int
[14:21:05] <cartman> http://cekirdek.pardus.org.tr/~ismail/5.png with the -= 128
[14:22:02] <av500> cartman: please, do the math by hand for a few values
[14:22:19] <wbs> cartman: you can't do -= 128 on an uint8_t and expect it to turn out right ;P
[14:22:31] <wbs> (unless you really want the wraparound)
[14:22:44] <cartman> kshishkov: thanks
[14:23:07] <kshishkov> mru: at least you haven't complained about him using for (int i = 0; ...) in C
[14:23:16] <cartman> kshishkov: thats valid in C99
[14:23:17] <mru> that is c99
[14:23:36] <cartman> kshishkov: http://cekirdek.pardus.org.tr/~ismail/6.png
[14:23:37] <mru> and the one case of declaration not at start of block I actually like
[14:23:40] <cartman> so there it is :P
[14:23:56] <mru> now you're getting somewhere
[14:24:03] <cartman> is the same as original :D
[14:24:11] <av500> it still does not look like anything...
[14:24:19] <cartman> av500: a frame from a movie
[14:24:25] <wbs> av500: that's the most legal kind of porn in turkey
[14:24:46] <cartman> ~70 lines of code, endless mocking
[14:24:50] <av500> ah, frak, the boss just walked in
[14:24:51] <cartman> worth the outcome :p
[14:25:08] <lu_zero> cartman: enjoy!
[14:25:09] <av500> "is that turkish porn on your screen!"
[14:25:17] <cartman> lu_zero: thanks :)
[14:25:23] <lu_zero> now you can help with swscale
[14:25:34] <lu_zero> =)
[14:25:35] <cartman> lu_zero: I am getting mocked enough
[14:25:36] <cartman> :P
[14:25:49] <av500> cartman: now please rewrite it without the seeks
[14:26:00] <cartman> av500: I don't know how, yet.
[14:26:21] <av500> cartman: buffer one line
[14:26:39] <cartman> kshishkov: Y has 16 bias too?
[14:26:42] <av500> er, wait, no buffer
[14:26:53] <kshishkov> cartman: depends on colourspace details
[14:27:09] <cartman> kshishkov: ah is it easy to detect if thats needed?
[14:27:24] <kshishkov> probably
[14:27:38] <av500> well
[14:27:41] <kshishkov> JPEG doesn't have it, MPEG has, something like that
[14:27:46] <mru> you can make a guess
[14:27:47] <av500> if Y is 0-255
[14:27:55] <av500> you can assume its the full range
[14:28:13] <mru> if you see values outside 16-240, you can assume it's full range
[14:28:19] <mru> or a sloppy decoder
[14:28:36] <mru> if you don't see any such values, you can't know for sure
[14:28:46] <cartman> and if its full range?
[14:28:59] <mru> if it's full range you use different coeffs
[14:29:12] <mru> if reduced, you subtract 16 from y and use another set of coeffs
[14:29:34] <cartman> and these coeffs are different everywhere? :)
[14:29:49] <mru> those are the matrixes you mentioned before
[14:30:10] <cartman> yeah everyone seems to have a different set of one as to simplify the operations
[14:31:49] <cartman> Wikipedia seems to explain this in YUV444 section instead.
[14:33:08] <cartman> mru: since floats made you scream, should I use fixed-point coefficients instead?
[14:33:15] <mru> subsampling and packing has nothing to do with it
[14:33:19] <cartman> av500: and whats the fseek replacement here? :)
[14:33:24] <av500> ?
[14:33:29] <av500> write one line at a time
[14:33:30] <mru> and of course use fixed-point
[14:33:50] <cartman> av500: but I am traversing two rows at a time
[14:33:55] <mru> multiply the coeffs by something suitably large and shift at the end
[14:34:08] <av500> cartman: so?
[14:34:17] <cartman> mru: makes sense
[14:34:47] <cartman> av500: so buffer them all and write at once?
[14:34:49] <av500> cartman: convert 2 lines in memory and then write them out
[14:35:04] <av500> the write out part is for your test case only anyway...
[14:35:24] <av500> cartman: or even better, write a full mem2mem converter
[14:35:29] <kshishkov> or traverse one row at a time, just update UV pointers
[14:35:30] <av500> coz that is what you are after, no?
[14:35:32] <cartman> av500: yeah still learning efficent ways is good
[14:36:01] <av500> cartman: or write the even and odds row to different files and call it RGB interlaced...
[14:36:07] <cartman> av500: true, writing to a file is not interesting for my problem
[14:36:52] <cartman> ok thank you
[14:37:15] <kshishkov> av500: thank you for introducing yet another pointless interlaced format!
[14:37:39] <cartman> lets efficient disk usage :P
[14:37:48] <lu_zero> kshishkov: he could propose vertical interlacing
[14:38:06] <kshishkov> lu_zero: diagonal
[14:38:20] <lu_zero> kshishkov: diagonal is tricky
[14:38:36] <lu_zero> 3x the aliasing I guess
[14:39:06] <kshishkov> lu_zero: not at all - just swap every 2x2 block from (a, b; c, d) to (a, c; d, b)
[14:39:18] <av500> kshishkov: tiled interlacing
[14:39:36] <kshishkov> av500: indeed
[14:39:55] <Tjoppen> wasn't there some tv engineer in the 50s that invented triple interlacing?
[14:39:56] <kshishkov> I'd call it Russian interlacing - senseless and ruthless
[14:40:19] <Tjoppen> I recall reading somewhere that it made 600 lines possible
[14:43:21] <mru> 200 lines per field?
[14:43:40] * cartman notes that NTSC coefficients work as expected too
[14:43:40] <kshishkov> per component
[14:44:54] <av500> http://en.wikipedia.org/wiki/Nipkow_disk
[14:45:26] <av500> this russian?
[14:46:55] <av500> oh, not a russian at all
[14:47:36] <Tjoppen> ah, electromechanical TV. how wonderful
[14:47:52] <Tjoppen> didn't bbc broadcast for those early on? vertical lines as well
[14:52:01] <mru> anyone with some neon knowledge care to look at http://patches.ffmpeg.org/patch/484/ ?
[14:52:25] <av500> mru: ^^^
[14:53:26] <kshishkov> mru: why change registers along with instructions?
[14:53:52] <kshishkov> mru: ah, I see
[14:54:22] <kshishkov> mru: looks rather trivial and OK for me
[14:54:41] <mru> kshishkov: I know it works
[14:54:49] <mru> but I need an OK on the ml
[14:55:03] <kshishkov> isn't OK on IRC enough?
[14:55:34] <mru> we're trying to keep some kind of record
[14:56:13] <kshishkov> ok
[14:58:22] <lu_zero> I thought I ok'd it before...
[14:58:45] * lu_zero spent some time to doublecheck the instructions just in case
[14:58:52] * lu_zero needs to recover =_=
[14:59:07] <mru> lu_zero: gmane has no record of you replying to that patch
[15:00:27] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r78f318be59 ffmpeg/libavcodec/arm/h264pred_neon.S:
[15:00:27] <CIA-43> ffmpeg: ARM: NEON: fix overflow in h264 16x16 planar pred
[15:00:27] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:07:17] <cartman> ugh bombing in Russia
[15:07:32] <kshishkov> *yawn*
[15:09:15] <cartman> hello h
[15:09:19] <cartman> hello hijacker forkers
[15:09:24] <cartman> sounds like terrorists
[15:10:24] <spaam> cartman: why did you bomb it ?
[15:10:31] <cartman> spaam: it was kshishkov
[15:10:37] <cartman> kshishkov: Allah Akbar!
[15:11:07] <kshishkov> cartman: here it's inappropriate
[15:11:10] <mru> some kurds who used to live next-door to me would play a song where the lyrics sounded just like "kill all the russians"
[15:11:12] <cartman> kshishkov: :(
[15:11:22] <mru> it was probably kurdish and meant something rather more harmless
[15:11:25] <cartman> mru: and not Turks?
[15:11:39] <av500> mru: "kill all turks" I guess
[15:11:42] <kshishkov> spaam: well, maybe you'll get less tourists from Moscow and Russia for some time (which is always good)
[15:12:04] <cartman> Most of the Kurdish people living in *.se and *.be is likely to be in Turkey's terrorist watchlist
[15:12:07] <cartman> weheee
[15:21:01] <cartman> MN is outperforming himself
[15:21:24] <cartman> "i dont like you mans but i agree this is crazy"
[15:26:52] <mru> apparently it offended him that I reviewed a few patches/commits of his
[15:27:04] <mru> with the same level of scrutiny applied to others
[15:27:10] <DonDiego> where did you do that?
[15:27:23] <mru> last summer on the ml
[15:30:18] <lu_zero> wonderful...
[15:31:44] <spaam> ? :)
[15:41:23] <lu_zero> spaam: re-routed...
[15:49:11] <arpi_mphq> hi
[15:49:30] <mru> hi, long time no see
[15:49:55] <cartman> offerred money to work with the other side?
[15:50:05] <mru> I am not aware of any such offer
[15:50:18] <mru> and if one were made, I would be
[15:50:19] <cartman> must be a Nigerian developer
[15:51:05] * cartman resists answering the mail
[15:51:18] <elenril> wow
[15:51:26] <mru> please all stay calm
[15:51:40] <DonDiego> arpi_mphq: doh, long time no see.. - hi
[15:51:45] <cartman> arpi_mphq: lose the _mphq already :)
[15:51:48] <lu_zero> hi!
[15:52:02] <DonDiego> arpi_mphq: still sporting a moustache? :)
[15:53:24] <lu_zero> oh
[15:53:54] <lu_zero> av500: do you have the latest vote count numbers at hand btw?
[15:54:16] <av500> lu_zero: that pastebin is still "out there"
[15:54:28] <lu_zero> which one?
[15:54:40] <lu_zero> I'd like to append that to my pastebin
[15:54:52] <cartman> your pastebin should call my pastebin
[15:54:57] <lu_zero> I'm sick of reading hijack, coup and such
[15:55:15] <cartman> tell MN he should be a politician in Turkey
[15:55:18] <cartman> will work out great
[15:55:18] <av500> lu_zero: it wasa coup :)
[15:55:45] <av500> cartman: updated c file?
[15:56:02] <kshishkov> lu_zero: "latest vote count" sounds like "latest Debian stable"
[15:56:17] <lu_zero> kshishkov: please =P
[15:56:27] <cartman> av500: wut file
[15:56:31] <lu_zero> av500: not that much
[15:56:40] <lu_zero> it's the normal outcome of the election
[15:56:59] <lu_zero> C: change or get demoted
[15:57:02] <arpi_mphq> why?  16:55 < cartman> tell MN he should be a politician in Turkey
[15:57:03] <superdump> mru: i'm calm, but this is rather strange and not really credible to me - do you have any idea what's going on?
[15:57:12] <mru> no
[15:57:12] <superdump> hello arpi_mphq
[15:57:17] <merbzt> DonDiego: did you create a fltter account for FFmpeg ?
[15:57:20] <cartman> arpi_mphq: if you tell lies like this + coups etc you fit Turkey
[15:57:25] <mru> superdump: and I'm a director in the foundation
[15:57:25] <cartman> it happens everyday here
[15:57:31] <mru> I should know about anything like that
[15:57:43] <arpi_mphq> cartman: what lies?
[15:57:59] <kshishkov> arpi_mphq: BTW, what led your feet to this channel?
[15:58:10] <cartman> arpi_mphq: MN's last post is a blatant lie unless backed up by evidence
[15:58:26] <arpi_mphq> kshishkov: i was curoius what the neu team does now after losing the best developers
[15:58:37] <DonDiego> cartman: no fanning of flames please
[15:58:46] <arpi_mphq> cartman: which post? too much to read all
[15:58:46] <cartman> neu team doesn't develop on the beach anymore :P
[15:58:48] <lu_zero> arpi_mphq: having fun fixing and introducing new bugs
[15:58:50] <kshishkov> arpi_mphq: who are they? Name three or four
[15:58:52] <mru> the foundation is sponsoring ruggles to work ac3enc
[15:59:00] <cartman> arpi_mphq: someone tried to bribe someone to join neu team
[15:59:08] <mru> but that's hardly what that email says
[15:59:14] <kshishkov> allegedly
[15:59:30] <DonDiego> merbzt: not yet, but i finally added the mplayer flattr button to the mplayer homepage
[15:59:33] <kierank> kshishkov: ian hislop quote
[16:00:13] <spaam> mru: going to tell MN about that? :)
[16:00:14] <superdump> i assume michael isn't talking about himself indirectly and that none of the 'new team' have offered michael money
[16:00:18] <arpi_mphq> cartman: it was not originated from MN
[16:00:22] <kshishkov> kierank: ?
[16:00:23] <mru> spaam: tell him what?
[16:00:40] <cartman> arpi_mphq: its useless without evidence
[16:00:40] <mru> spaam: michael is a director of the foundation, he knows everything it does
[16:00:48] <cartman> Nigerian scammers offer 300.000$ everyday
[16:00:50] <spaam> mru: about the foundation sponsring ruggles..
[16:00:59] <spaam> mru: ah ok
[16:01:05] <DonDiego> merbzt: should i just create the flattr button through my flattr account or do we setup something through the foundation? i'm not sure if such a foundation account is possible, however...
[16:01:06] <kierank> kshishkov: he's editor of a newspaper here who's been sued for libel so many times. On TV he always says something happened...allegedly
[16:01:17] <mru> spaam: and that was decided a long time ago
[16:01:47] <spaam> mru: ah that explains some stuff :)
[16:01:53] <lu_zero> DonDiego: not sure what works best
[16:02:00] <kshishkov> mru: wasn't it more about recruiting new devs with foundation money behind his back?
[16:02:14] <mru> kshishkov: that hasn't happened
[16:02:15] <av500> kshishkov: I never got anything offered :(
[16:02:26] <cartman> av500: we were all bribed
[16:02:47] <av500> cartman: you was bribed to start work on libswscale2
[16:02:49] <DonDiego> lu_zero: me neither, i can try to investigate if it's possible...
[16:02:54] <av500> one can clearly see that
[16:02:57] <cartman> av500: sure sure
[16:03:01] <DonDiego> why wasn't i bribed?
[16:03:20] <av500> DonDiego: your status as poor student could not be endangered
[16:03:21] <cartman> we were all bribed with the promise of friendliness ;P
[16:03:22] <lu_zero> DonDiego: you were the one bribing
[16:03:30] * elenril should have asked KotH for some chocolate in exchange for joining
[16:03:34] <DonDiego> i'm piss-poor, at least i wouldn't waste the money on a new yacht ...
[16:03:43] <av500> elenril: he did *not* offer you some?
[16:03:53] * Compn replies to michael
[16:03:58] <elenril> av500: see how evil he is!
[16:04:02] * av500 munches on chocolate
[16:04:06] <DonDiego> ok, enough fun, i have some work to do here..
[16:04:11] <spaam> av500: KotH want all his chocolate for himself..
[16:04:17] <elenril> av500: go review my patches
[16:04:30] <DonDiego> @everybody: shut up and drop the subject, you have already been trolled into replying and wasting time
[16:04:50] <av500> thats what I came here for!
[16:05:07] * cartman goes back to slacking
[16:05:33] <arpi_mphq> good luck assholes
[16:05:37] <spaam> haha
[16:05:39] <cartman> LOL
[16:05:41] <ubitux> :s
[16:05:41] <lu_zero> uhm
[16:05:42] <av500> lol
[16:05:46] <kshishkov> thanks for his kind words
[16:05:46] <mru> same old arpi
[16:05:54] <lu_zero> I wonder what he really wanted
[16:06:03] <av500> lu_zero: to say assholes
[16:06:06] * elenril hoped for a better troll
[16:06:08] <lu_zero> ah
[16:06:24] <cartman> he was here for the teh neu codez
[16:07:03] <lu_zero> all in the git =P
[16:07:14] <cartman> except my super duper yuv2rgb.c :P
[16:07:14] <kshishkov> spaam, kierank: why does his nick reminds me of Basty?
[16:07:44] <kierank> who's nick?
[16:07:46] <kierank> whose*
[16:07:50] <kshishkov> cartman: my humble yuv2rgb.c was eventually accepted into SwS, so you still have a lot to achieve
[16:07:59] <kshishkov> kierank: arpi_mphq
[16:08:07] <spaam> kshishkov: i dont know.
[16:08:29] <kierank> MPHQ is an amiga group
[16:08:31] <cartman> kshishkov: nah all I need is to hookup it with omapfbplay and I'll be done
[16:08:33] <kierank> haven't you haearD?
[16:09:50] <kshishkov> kierank: well, I remember seeing one gross enourmous pile of hacks there and it was not libavseq
[16:10:38] <lu_zero> I didn't grasp exactly the extents of what was the proposed libavseq
[16:10:53] <kshishkov> lu_zero: an engine for tracker and MIDI files
[16:10:59] <av500> lu_zero: is there a need to grasp it now?
[16:11:10] <lu_zero> av500: I'd let it alone
[16:12:09] <merbzt> DonDiego: create it with your own account
[16:12:19] <spaam> lu_zero: with avseq ffmpeg will grow twice the size in code.. and kierank can play his amiga stuff ;D
[16:13:15] <merbzt> amiga !!!!
[16:14:50] <BBB> wbs: how did you do the undo_setup()? (I didnt' check the patch yet)
[16:14:54] <BBB> wbs: was TEARDOWN enough?
[16:15:14] <kshishkov> merbzt: have you convinced someone to finish REing those video files from Cryo?
[16:15:38] <merbzt> I thought I convinced you ...
[16:16:10] <kshishkov> well, now convince my free time, I'd gladly work on it (eventually)
[16:16:25] <Tjoppen> ah, DVCPRO HD is specified in S370m. I almost feel like fixing lavc's encoder (it messes up the AC encoding)
[16:17:05] <Tjoppen> it's a little annoying that it can encode everything else :o
[16:17:09] <merbzt> Tjoppen: afaik the encoder was never committed
[16:17:28] <merbzt> dvcpro hd 100 or something
[16:18:16] <Tjoppen> ah. because it looks like it "almost" working. meaning it outputs something that looks sort of right except the AC is inverted or something
[16:19:12] <spaam> Tjoppen: fixa det . kshishkov bjuder på trocadero om du gör det
[16:19:53] <Tjoppen> :)
[16:19:57] <Tjoppen> are the patches around somewhere?
[16:20:07] <merbzt> Tjoppen: look back in the mail history, I think the guy behind mars digital coded it up and I think Roman tried to get it included but never finished it
[16:20:22] <merbzt> rsv at sun me thinks
[16:20:34] <merbzt> rebase and send it again IIRC
[16:20:44] <merbzt> then patchwork will find it
[16:22:43] <Tjoppen> I see the thread for the decoder. I'll have to google around a bit more for the encoder
[16:23:53] <mru> hmm, a TI dsp compiler has an int40_t type
[16:24:13] <Flameeyes> 40? o_O
[16:24:24] <mru> apparently it supports 40-bit ints
[16:24:27] <superdump> awesome
[16:24:43] <av500> 8 bit ecc info
[16:24:50] <mru> :)
[16:25:07] <av500> mru: or its used to fix that gcc float bug
[16:25:45] <mru> and they claim to have finally fixed designated initializers for unions
[16:25:50] <mru> compiler used to crash on those
[16:26:11] <av500> wrt symbian, sin() as a macro?
[16:26:21] <mru> sin() might be a macro, sin is not
[16:26:39] <mru> it wouldn't compile if it were
[16:27:00] <mru> spec says "The following shall be declared as functions and may also be defined as macros"
[16:27:05] <mru> then lists all the math.h functions
[16:27:34] <av500> #define sin(x) x // works for me for small x
[16:27:37] <kshishkov> mru: and we have 80-bit lagarith_state_t on x87
[16:27:53] <mru> kshishkov: that's floating point
[16:28:09] <mru> some TI dsps have 40-bit integers
[16:29:17] <kshishkov> yes, but I don't see principal difference between them - both are weird nonportable types
[16:34:55] <Compn> isnt there some ffmpeg rule about not having OS hacks ?
[16:35:09] <Compn> e.g. for symbian or mingw or bsd or anything
[16:35:20] <mru> they should be kep to a minimum and isolated from real code
[16:35:31] <av500> fflibm
[16:35:34] <av500> er, libavm
[16:35:44] <Compn> wasnt there a liboshacks or something
[16:35:47] <Compn> where did that go
[16:35:55] <av500> it was discussed
[16:37:48] <Flameeyes> mru: about the unversioned symbols I noted...
[16:37:57] <mru> go on
[16:40:11] <Flameeyes> what's the plan?
[16:40:20] <mru> find the bug and fix it
[16:40:36] <mru> which .so has the bad symbols?
[16:42:55] <Flameeyes> avformat and avcodec — want me to send a patch to simply version them in the future (accepting the issue is still present in git, need to check that)
[16:43:33] <mru> do you know why they are missing a version?
[16:44:33] <Flameeyes> haven't looked into that, was wondering if you had an idea already — will look into it now, I guess it's as good a time as any other to convert the stuff I had in the old ffmpeg git clone to the official git
[16:44:54] <siretart> Flameeyes: sorry for not getting earlier at it, I've got caught up at work here
[16:45:01] <Flameeyes> siretart: don't worry :)
[16:45:22] <mru> Flameeyes: the libavcodec version script is quite simple
[16:45:28] <mru> I don't see how it could miss a few symbols
[16:45:36] * Flameeyes has some free time, waiting for IBM people to answer him
[16:45:41] <Tjoppen> found the dvcpro hd patches
[16:45:42] <mru> it has a single global: * directive
[16:45:58] <siretart> btw, my plan to have daily builds of ffmpeg worked out: https://code.launchpad.net/~motumedia/+recipe/ffmpeg-daily \o/ :-)
[16:46:58] <mru> nice
[16:47:23] <mru> but please, must you call it 0.7?
[16:47:26] <av500> mru: another SW soon only be had from ubuntu PPA ;)
[16:47:28] <mru> there is no 0.7
[16:48:06] <wbs> BBB: no, it just clears the data structures. TEARDOWN makes the server close the control channel on DSS and ms-rtsp servers
[16:48:19] <spaam> mru: maybe you should give him a better name for it ?
[16:48:38] <wbs> BBB: (but teardown helps a bit on real-rtsp, although I havent got that working fully yet)
[16:49:24] <Flameeyes> mru: uhm I think I know why it happens: they seem all to be common symbols (.bss)
[16:49:42] <siretart> mru: what else shall I call it?
[16:49:50] <mru> siretart: good question
[16:50:19] <spaam> siretart: mru_allstars
[16:50:22] <siretart> it is called 0.7~~ to indicate that it is a pre-pre version of what will end in 0.7
[16:50:40] <mru> what kind of naming convention is that?
[16:51:15] <siretart> a weird one. in the dpkg version comparision algorithm, the '~' directive roughly means "earlier"
[16:51:26] <lu_zero> Flameeyes: cough
[16:51:49] <thresh> mru: why do you care? You're not using debian AFAIR, and debian users know what that means :)
[16:52:17] <av500> but it might never be 0.7 if we fork again :)
[16:52:35] <siretart> it will be superseeded by any 'real' 0.7 distro package
[16:52:40] <thresh> I'm pretty sure it's possible to override the version then :)
[16:53:19] <Flameeyes> lu_zero: uhm?
[16:53:23] <siretart> when we branch 0.7, I will go with 0.7~ for the distro packages until release, 0.7 for the release packages, and move 0.8~~ for the dailies.
[16:53:41] <mru> what does ~~ mean compared to ~?
[16:54:17] <siretart> it is the "earlier" directive applied twice
[16:54:33] <siretart> 0.7~rc1 will win over 0.7~~something
[16:54:35] <mru> whatever you say...
[16:54:44] <mru> do whatever you think is right
[16:54:49] <lu_zero> siretart: proposing _preN would be considered heresy?
[16:55:06] <lu_zero> =)
[16:55:07] <siretart> lu_zero: '_' is not an allowed character in version strings
[16:55:19] <lu_zero> ah
[16:55:27] <siretart> '+' would be. or '-'
[16:55:28] <elenril> how about we converge to sqrt(2)/2
[16:55:41] <BBB> wbs: oh, I see, you didn't fix the issue for real - can you still do that?
[16:55:43] <siretart> that would be tex/latex like
[16:57:41] <elenril> awesome, spammers finally noticed by mailserver
[16:57:54] <elenril> took them quite long
[16:57:55] <Flameeyes> lu_zero: if you were asking what I said means is simple: by default GCC emits common symbols, so each uninitialised variable is declared to be merged at the final link stage for all the objects using it...
[16:59:06] <mru> Flameeyes: all of those symbols should eventually be hidden
[16:59:14] <Flameeyes> mru: quite definitely
[16:59:22] <Flameeyes> in the case of one (qmf_window) I wonder why it is not static actually
[16:59:24] <mru> once the api cleanup is complete
[16:59:53] <mru> patches welcome
[17:00:01] <Flameeyes> I know, I'll send some in the next days
[17:00:30] <Flameeyes> ff_* symbols are reserved/internal right?
[17:02:45] <siretart> Flameeyes: yes, only other ffmpeg libraries are allowed to use them
[17:03:06] <siretart> that's why we cannot hide them in the symbol files
[17:03:56] <siretart> ideally, we make the symbol versioning scripts hide anything not matching av_* or ff_*. this doesn't work out for libavformat and libavcodec, though.
[17:04:13] <Flameeyes> siretart: and if we were to use ff_avc_* for those that need to stay local?
[17:04:15] <mru> the ff_ ones should be internal to each lib
[17:04:37] <siretart> Flameeyes: what's the problem with ff_*?
[17:04:37] <superdump> what is mp3on4?
[17:04:52] <mru> some ugly hack on mp3
[17:04:53] <Flameeyes> siretart: if ff_* can be used avf→avc
[17:05:11] <mru> Flameeyes, siretart: ff_* should be lib-private
[17:05:30] <Flameeyes> mru: so those could be hidden already?
[17:05:41] <Flameeyes> [given no software used them that is]
[17:06:23] <siretart> mru: 'lib-private' means "only in the very same lib", then it should be hidden and not exported at all
[17:06:33] <mru> libavcodec and libavformat currently export everything because the patterns required to match the correct things are too convoluted
[17:06:33] <superdump> not mp3pro related or something to do with mp3 in mpeg-4 aac or something?
[17:06:43] <av500> yes
[17:06:45] <mru> due to all sorts of public symbols not having correct prefixes
[17:07:00] <siretart> yes
[17:07:35] <Flameeyes> mru: but then again you could "export everything BUT ff_*"
[17:08:00] <mru> it's not that easy
[17:08:14] <mru> some ff_ symbols need to be changed to av_ and made public
[17:08:39] <siretart> this has happened for some symbols in the past already
[17:08:50] <mru> yes, but the transition is incomplete
[17:08:55] <Flameeyes> okay thus my proposal of renaming those that really _really_ shouldn't be exported to ff_avc_* so that they can be hidden right now...
[17:08:57] <siretart> indeed
[17:09:05] <Flameeyes> [or something similar]
[17:09:11] <kierank> anybody know anything about gpio?
[17:09:23] <av500> kierank: lol
[17:09:24] <Flameeyes> then you could link ff_* to interlib-private, and av_* to public
[17:09:42] <kierank> av500: what?
[17:09:42] <mru> Flameeyes: is this lack of version a huge problem?
[17:09:54] <siretart> Flameeyes: I think we should first fix/enforce public symbols to start with av_*, and then reconsider what to hide
[17:10:04] <mru> +1
[17:10:13] <av500> +1
[17:10:20] <Flameeyes> mru: the version was added to avoid collisions, wasn't it? the lack of version of those will make the whole version idea moot
[17:10:33] <Flameeyes> siretart: you know I read that so many times by now that I lost count?
[17:10:47] <av500> Flameeyes: add one :)
[17:11:01] <Flameeyes> av500: I don't see it as something to be happy or proud with
[17:11:05] <mru> Flameeyes: only if something external uses them, which it shouldn't
[17:11:17] <siretart> Flameeyes: then let's start working on it :-) - but TBH, this smells like post 0.7 stuff to me
[17:11:19] <mru> internal references are already bound to the local lib
[17:11:33] <mru> siretart: why not do it _before_ 0.7?
[17:11:41] <Flameeyes> what mru said...
[17:11:44] <uau> are there many ff_ symbols that would need to be made public
[17:11:50] <siretart> mru: I fear it would delay 0.7 for a long time
[17:11:53] <Flameeyes> mru: I'm not sure if common symbols are bound to -bsymbolic
[17:11:57] <uau> i checked that mplayer2 uses none
[17:12:08] <mru> Flameeyes: that's easy enough to check
[17:12:08] <siretart> for instance, I still haven't heard a comment on what to do with libavfilter
[17:12:21] <siretart> is the API/ABI already frozen? or still in flux?
[17:12:47] <mru> some internal interfaces need to change for sure
[17:12:53] * Kovensky melts APIs and doesn't afraid of anything
[17:12:58] <mru> I don't know if that will propagate to the public api
[17:13:05] <Flameeyes> also, while gentoo might not have everything on the planet, the list I sent to the ml should cover most of the issues out there, no?
[17:13:11] <Kovensky> and hi Flameeyes
[17:13:19] <siretart> well, we can bump major for public api changes, right?
[17:13:37] <siretart> anyway, sorry, I need to run home to my wife now. cu later!
[17:13:43] <uau> Flameeyes: making any symbols "interlib-private" is problematic as long as the libraries have independent major versions
[17:13:57] <av500> and do we need them to have that?
[17:14:02] <Flameeyes> uau: that was more a declaration than something enforceable of course
[17:14:04] <Flameeyes> hi Kovensky
[17:14:28] <uau> Flameeyes: i mean that you can't count on the ffmpeg libraries having matching versions
[17:14:35] <Flameeyes> and?
[17:14:51] <uau> so any benefits from them being "private" would be limited
[17:15:03] <uau> you'd still need to track compatibility in them
[17:15:09] <mru> that technical detail aside, I don't like the idea of libs accessing each other's internals in spaghetti fashion
[17:15:27] <av500> liavinterlibdeps
[17:15:28] <Flameeyes> [fwiw the only ff_ symbol of which I found use outsize of interlibs is ff_codec_get_tag
[17:15:30] <av500> lib
[17:15:33] <Flameeyes> used by bombono
[17:15:45] <mru> wtf is that?
[17:15:46] <Kovensky> libavlasagna (or libasagna)
[17:15:59] <Flameeyes> mru: http://www.bombono.org/cgi-bin/wiki/
[17:16:27] <av500> mru: pardon my ignorance, but why must av libs be able to have different version numbers?
[17:16:38] <Dark_Shikari> .... LOOOL.
[17:16:41] <mru> av500: that's not the point
[17:16:44] <Dark_Shikari> Someone asked me what compression I would use to stream audio + 480x272 video
[17:16:49] <Dark_Shikari> if I had a 64bps connection
[17:16:50] <av500> gzip?
[17:16:52] <mru> that's just a consequence of having a sane api
[17:17:02] <Dark_Shikari> I answered zlibbed MIDI and procedurally generated video.
[17:17:12] <av500> he forgot a "k"?
[17:17:37] <mru> Dark_Shikari: mpeg4-2 wireframe ftw
[17:17:49] <Flameeyes> http://paste.pocoo.org/show/326089/ while this is the list of interlib symbols
[17:19:47] <mru> Flameeyes: that list looks managable
[17:20:30] <mru> the header parsing functions could be folded into parsers
[17:20:35] <mru> with a generic api
[17:21:26] <elenril> BBB: afraid to push the patch yourself? ;)
[17:21:38] <BBB> no, busy with other stuff
[17:21:40] <mru> elenril: he has gmail issues
[17:21:50] <av500> he has gmail
[17:22:24] <elenril> oh.....accept my sincere lolgmail
[17:23:24] * av500 slaps everybody that mentions "leader" on -devel with a wet trout
[17:25:08] <Compn> lol
[17:26:03] <av500> please use "voted leader" or "revoluted leader"
[17:26:36] <iive> av500: michael was co-leader with fabrice, long  before ffmpeg moved to mphq
[17:26:49] <elenril> av500: supreme leader?
[17:26:53] <elenril> or eternal leader
[17:27:00] <av500> iive: sure, I know the history
[17:27:13] <av500> iive: its just that this work has lost meaning to me wrt -devel
[17:27:24] <iive> av500: but you try to rewrite it.
[17:28:20] <superdump> i suspect av500 was joking
[17:29:00] <iive> he is not funny.
[17:31:13] <CIA-43> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r07b48f8c7a ffmpeg/ffmpeg.c:
[17:31:13] <CIA-43> ffmpeg: Do not set audio_resample to 0 if audio_sync_method is > 1.
[17:31:13] <CIA-43> ffmpeg: If audio_sync_method is >1 the resampler is used for audio drift
[17:31:13] <CIA-43> ffmpeg: compensation, and do_audio_out() was causing an assert failure because
[17:31:13] <CIA-43> ffmpeg: audio_resample was not set.
[17:31:13] <CIA-43> ffmpeg: Fix issue 2516, which was introduced by SVN r25939.
[17:31:14] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[17:32:21] <elenril> rounddown is up?
[17:37:43] <superdump> i'm curious - who is on 'michael's side'?
[17:39:04] <BBB> define "on ... side"
[17:39:46] <BBB> wants him to be leader? I've seen little support for that, "disagrees with the way we un-bdfl'ed him"? quite a few, "wants to commit to git.videolan"? I think stefano atm, but he wants to keep the two trees synced
[17:41:07] <mru> most likely he made it up
[17:41:18] <mru> just like the part about foundation paying people to "switch sides"
[17:41:41] <mru> we know for a fact that didn't happen
[17:45:33] <av500> Compn: avi with >100 streams, you really need that?
[17:46:42] <superdump> i'm inclined to believe it was either someone else using michael to stir up the situation or michael misinterpreting or misunderstanding something
[17:54:20] <superdump> have fun
[18:07:22] <elenril> o_0 reimar committing to the videolan tree
[18:09:41] * BBB agrees with superdump, probably a misunderstanding
[18:10:03] <mru> question is _what_ was being misunderstood
[18:10:33] <mru> the foundation hasn't offered anyone money since ruggles' ac3enc work was approved
[18:24:54] <Tjoppen> I took a stab at rebasing that dvcpro hd patch, but it was a bit harder than I thought since it was written prior to the dv encoder becoming multithreaded
[18:38:03] <lu_zero> uff
[18:38:14] <mmu_man> huff
[18:38:19] <mru> puff
[18:38:38] <lu_zero> apparently somebody was playing BGP w/out knowing the rules...
[18:39:09] <mru> gateway thing?
[18:40:47] <lu_zero> mru: IX thing...
[18:41:13] <mru> border gateway protocol?
[18:41:14] <lu_zero> the fun of sitting right on the border...
[18:41:50] <lu_zero> lscube.org is hosted on the second Italian internet exchange
[18:42:20] <lu_zero> so from time to time we get strange issues ^^;
[18:42:44] <spaam> like what? :)
[18:44:50] <lu_zero> spaam: missing few routes to the outside
[18:45:15] <lu_zero> not that often luckily
[18:45:37] <lu_zero> this border is mostly safe
[18:46:22] <av500> no smugglers?
[18:49:05] <lu_zero> those usually prefer the MIX for obvious reasons
[18:54:40] <Compn> av500 : like i said, not me, but maybe someone wants it :P
[18:55:01] <lu_zero> Compn: smuggling packets?
[19:26:38] <{V}> did git.videolan switch to some other mailinglist than ffmpeg-cvslog ?
[19:27:52] <av500> no
[19:27:56] <av500> its still this ml
[19:28:39] <av500> but they are pulling a lot of patches from the other git
[19:29:27] <{V}> odd. My mailbox (and http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/ ) seems to be missing the latest commits to the ffmpeg repo on videolan
[19:30:59] <{V}> those by Reimar for example
[19:31:45] <{V}> hmmm just the last 2 by Reimar it seems
[19:32:10] <mru> +1
[19:34:03] <jannau> I can't see them in the archive either
[19:34:39] <mru> nor moderation queue
[19:35:31] <jannau> j-b, thresh: ping, notify mails from git.videolan.org:ffmpeg.git seems to be broken
[19:35:50] <j-b> jannau: the ones from reimar, yes
[19:36:08] <j-b> because of the "ö"
[19:36:40] <elenril> he fails at utf-8?
[19:36:42] <elenril> or you do?
[19:37:24] <j-b> one of us...
[19:37:27] <j-b> thresh will know
[19:38:05] <elenril> thresh belongs to the videolan sect?
[19:38:15] <jannau> we have a proposal for a new logo, http://www.heise.de/open/artikel/Die-Woche-Meuterei-auf-der-FFmpeg-1174538.html
[19:38:19] <spaam> maybe git.videolan.org live in the past with iso8859-1 :/
[19:38:21] <jannau> ignore the article
[19:38:43] <spaam> what does the article say?
[19:39:05] <j-b> elenril: it isn't a sect (yet)
[19:39:13] <spaam> i dont see the logo jannau ;S
[19:47:50] <jannau> spaam: argh, it's not in the article. http://www.heise.de/open/imgs/10/6/2/0/1/6/2/ffmpeg-pirat-95x90-278105162ee1e1f5.png
[19:48:51] <mru> :)
[19:49:34] <CIA-43> ffmpeg: Kostya <kostya.shishkov at gmail.com> master * r3bdc886c22 ffmpeg/ (libavcodec/wavpack.c libavformat/wv.c):
[19:49:34] <CIA-43> ffmpeg: Extend WavPack demuxer and decoder to support >2 channel audio
[19:49:34] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[19:49:46] <CIA-43> ffmpeg: Kostya <kostya.shishkov at gmail.com> master * rdacbcd170a ffmpeg/ (libavcodec/wavpack.c libavformat/wv.c):
[19:49:46] <CIA-43> ffmpeg: reindent after last commit
[19:49:46] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[19:50:29] <mru> j-b: regarding the 'ö', I edited the notification script on ffmpeg.org to properly mime-escape such things
[19:52:24] <Compn> is there no way to resend those mails from git or are they lost forever btw ?
[19:53:27] <Compn> spaam : google translate :P
[20:04:35] <jannau> bah, and patchwork chokes on reimar's patches too
[20:05:40] <Compn> should i send a mail to ffmpeg-devel about lost commit messages ?
[20:05:49] <Compn> j-b , jannau , mru ?
[20:05:59] <jannau> Compn: already done
[20:06:03] <Compn> oh ok :)
[20:06:59] <lu_zero> ...
[20:08:39] <Compn> wb there lu_zero and lu_zero's doppleganger
[20:08:56] <lu_zero> where ?
[20:09:05] <lu_zero_> there
[20:09:08] <lu_zero_> ok
[20:09:10] <elenril> fork( lu_zero_ )
[20:09:19] <lu_zero_> still BGP weirdness
[20:09:45] <Compn> lu_zero : have you gotten your country to learn ipv6 yet ? :P
[20:10:17] <lu_zero_> Compn: not sure who is messing with bgp
[20:10:23] <lu_zero_> tomorrow I'll know
[20:10:41] <lu_zero_> hi saste
[20:10:45] <j-b> mru: ok, should I fix something on my side?
[20:11:04] <mru> j-b: you need to mime-escape the From header
[20:11:20] <mru> I don't know how you're setting it currently
[20:11:35] <saste> lu_zero: ciao luca
[20:11:37] <j-b> I don't know either :)
[20:11:45] <mru> replacing $author with encode("MIME-Q", $author) in some place should do the trick
[20:12:06] <mru> does for us anyway
[20:13:10] <wbs> BBB: I didn't get resetup working (easily) with real at least... if I don't do teardown, I get an error saying that the method isn't supported at that point.. if I do teardown, everything seems to succeed, but I never actually get any packets over TCP... so I'm not sure if I'd have to close the whole connection and start over from scratch with a new connection instead
[20:13:52] <wbs> BBB: on the other hand, if one just closes the connection and does that, but don't go through the full options/describe phase, it might not be all that hacky
[20:15:05] <siretart> wow. I'm impressed
[20:15:34] <siretart> it seems that all of vlc, mplayer and gst-ffmpeg compiled against 0.6 still work with 0.7
[20:15:55] <j-b> stop using drugs! :D
[20:16:14] <saste> siretart: we've been obsessed by the idea of not breaking apps in the last year
[20:16:24] <saste> siretart: we did it pretty well
[20:16:35] <jannau> siretart: stop using fake releases ;)
[20:17:25] <siretart> saste: indeed, I have to congratulate to everyone working on that!
[20:17:30] <BBB> wbs: can you try? would be nice if it works with real also
[20:17:43] <wbs> BBB: I can give it a try. it might be cleaner for the other cases, too
[20:17:45] <mru> siretart: I don't mind if you call your ubuntu packages 0.7~~#*@~, but don't refer current master as simply "0.7"
[20:18:03] <BBB> wbs: not necessary for the other cases, this is networking, it'll introduce significant latency if we reconnect completely, I'm affraid
[20:18:20] <wbs> BBB: but I'm not sure how the real cookie/challenge stuff works if we just keep the same data from the previous connection
[20:18:24] <siretart> mru: ok, I'll be more careful in the future.
[20:18:52] <wbs> BBB: or if we really need to do the full setup from the start in order to get a new challenge etc
[20:20:21] <lu_zero> wbs: ?
[20:20:24] <CIA-43> ffmpeg: Martin Storsjö <martin at martin.st> master * r2b0decf60b ffmpeg/libavformat/applehttp.c:
[20:20:24] <CIA-43> ffmpeg: applehttp: Fix the key check in handle_variant_args
[20:20:24] <CIA-43> ffmpeg: The key string is supposed to contain the equals character,
[20:20:24] <CIA-43> ffmpeg: too. Since the checked string was wrong, and the return value
[20:20:24] <CIA-43> ffmpeg: check was wrong too, it incorrectly seemed to work right before.
[20:20:25] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:20:26] * lu_zero missed the start
[20:20:55] <mru> jannau: http://pastebin.com/SEFvmLMr
[20:21:07] <BBB> wbs: test it :)
[20:21:16] <wbs> BBB: yeah, that's the only way of finding out :-)
[20:21:27] <BBB> wbs: also, no pakcets over TCP
[20:21:33] <BBB> wbs: did you send a aubscribe afterwards?
[20:21:50] <BBB> I'd love to see a wireshark trace of that
[20:21:51] <wbs> BBB: hmmm, perhaps that's missing
[20:22:34] <BBB> no subscribe means it won't send anything
[20:22:36] <BBB> it's normal
[20:22:46] <BBB> "normal" :-p
[20:22:52] <wbs> real-rtsp sure is weird ;P
[20:23:11] <lu_zero> could someone give me a backlog?
[20:24:24] <BBB> wbs: indeed
[20:25:33] <CIA-43> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r032f406864 ffmpeg/libavutil/lzo.c:
[20:25:33] <CIA-43> ffmpeg: Handle input or output len of 0 properly in lzo decoder.
[20:25:33] <CIA-43> ffmpeg: (cherry picked from commit 7d5082600ee63d879c2a325974ea09c8ace05019)
[20:25:37] <jannau> mru: I know
[20:25:37] <CIA-43> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r4be170c937 ffmpeg/libavcodec/nuv.c:
[20:25:37] <CIA-43> ffmpeg: Use av_fast_malloc instead of av_realloc.
[20:25:37] <CIA-43> ffmpeg: This should be faster, is less code and fixes issue 2524
[20:25:37] <CIA-43> ffmpeg: (allocation error would lead to crash).
[20:25:38] <CIA-43> ffmpeg: (cherry picked from commit e7b95918fca1c3d057d35f77ba58ee2d00d03151)
[20:26:27] <mru> jannau: did you miss my comment about "cherry-picked from"?
[20:26:54] <jannau> mru: no, see my reply
[20:26:59] <jannau> http://patchwork.libav.org/user/bundle/1/?state=*
[20:27:23] <jannau> for Vitor's patches
[20:28:01] <mru> I don't see a reply
[20:28:28] <jannau> now sent, sorry
[20:28:55] <mru> having a hash is useless without knowing where to find it
[20:29:49] <mru> does google index them in gitweb?
[20:30:43] <jannau> doesn't look like it does, only hit for e7b95918fca... is my mail
[20:31:51] <jannau> git show $SHA1 will just work if both repos are configured as remotes
[20:32:01] <mru> yes, I know
[20:33:04] <relaxed> Just to be sure, on my Freebsd 8 box './configure --enable-gpl' enables #define HAVE_AMD3DNOW 1 and #define HAVE_AMD3DNOWEXT 1 in config.h even though I have an Intel T7600. After compiling it crashes when using 'vf scale=$W:$H' which I backtraced to swsscale trying to use 3dnow. I should file a bug report, correct?
[20:33:35] <mru> sounds like the runtime detection went wrong
[20:33:47] <mru> so yes, that's a bug
[20:33:50] <jannau> I'm undecided, a agree that the default cherry-pick -x message is not ideal
[20:34:14] <jannau> mru: there is no runtime detection in swscale
[20:34:20] <mru> if it included the url of the remote it would be more useful
[20:34:26] <mru> jannau: so that's wrong then
[20:34:40] <mru> relaxed: does it work if you add --disable-amd3dnow?
[20:34:47] <relaxed> yes
[20:34:49] <mru> or whatever the flag is called
[20:35:45] <relaxed> This looks similar. https://roundup.ffmpeg.org/issue893
[20:35:57] <jannau> someone thinks that HAVE_AMD3DNOW means the CPU has it vs the assembler being able to assemble it
[20:37:09] <mru> and there gcc/binutils are horribly inconsistent
[20:37:10] <jannau> argh: libswscale/x86/yuv2rgb_mmx.c:#undef HAVE_AMD3DNOW
[20:37:31] <mru> on arm and mips, they reject instructions not supported by the selected cpu
[20:37:37] <mru> on intel and ppc they always accept anything
[20:37:57] <mru> at least on intel you can do runtime detection reliably
[20:38:12] <mru> ppc doesn't have a portable way to do that
[20:38:43] <uau> jannau: there is some runtime cpudetection support in swscale
[20:38:44] <lu_zero> sadly =_=
[20:39:06] <mru> linux traps and emulates the relevant instructions since quite a while
[20:39:17] <mru> but obviously macos doesn't
[20:39:22] <mru> no idea what aix does
[20:39:49] <jannau> uau: only if explicitly enabled
[20:40:08] <mru> hopefully that's something we can fix once lu_zero is done cleaning it up
[20:40:18] <mru> lu_zero: we're counting on you
[20:40:53] <uau> jannau: and why that "argh"? you realize that's just setting different variations when compiling a template?
[20:41:32] <mru> uau: argh accurately sums up most of libswscale
[20:41:43] <jannau> I could refresh my patches from october but I fear it would make lu_zero job harder
[20:42:30] <mru> perhaps I should try once more raising the idea that --cpu=foo should disable things cpu foo doesn't support
[20:42:35] <jannau> uau: I know but redefining a config.h is just wrong and broken
[20:42:46] <mru> +100
[20:42:54] <jannau> +define
[20:43:54] <relaxed> mru: For the record, I wasn't using --cpu=foo
[20:44:38] <mru> I would also suggest disabling 3dnow by default
[20:45:05] <mru> if no --cpu is specified, I'd expect the result to run on most current machines
[20:45:08] <mru> whether intel or amd
[20:45:54] <lu_zero> mru: I went a bit further yesterday
[20:49:12] <wbs> BBB: sending a new subscribe seems to work fine, thanks :-)
[20:49:36] <wbs> BBB: I'll brush it up and resubmit patches for those parts that need changing
[20:51:43] <siretart> is svn://svn.ffmpeg.org/soc/libavfilter still being in use?
[20:51:51] <mru> do all fate runners update samples every 24h?
[20:52:21] <siretart> seems that it's checkout.sh fails due to the remove libswscale external
[20:52:46] <siretart> now I wonder if it's worth to fix or if we should better import it into some git branch
[20:52:54] <wbs> I guess the rest of the libavfilter soc repo should be imported as a git branch somewhere
[20:53:11] <wbs> which makes it _much_ easier to deal with than the current soc svn repo
[20:55:06] <lu_zero> hopefully ^^;
[20:57:24] <siretart> wbs: how to keep the 'new' soc repo synced with master?
[20:59:13] <wbs> siretart: it can be done as a branch that is rebased on top of master.. or merging in master if you prefer that
[21:02:27] <mru> hmm, the gcc 4.6 snapshots have non-deterministic warnings
[21:02:51] <lu_zero> why are you using 4.6?
[21:02:57] <mru> I'm not
[21:03:02] <mru> someone is running fate with it
[21:03:41] <mru> warning count fluctuates
[21:03:49] <siretart> wbs: I've not worked with the soc branch at all so far, so I'm totally indifferent
[21:03:51] * lu_zero wonders what would be running ffmpeg on parrot
[21:03:54] <mru> even with commits not touching any code it sees
[21:04:20] <andoma> weird.. a friend posted this on facebook for me:
[21:04:25] <andoma> echo `grep "make mbaff " libavcodec/h264_mvpred.h | awk '{ print $4; }' | cut -c1-5` `grep '2007;$' ffprobe.c | cut -d_ -f2` `grep getti libavutil/des.c | cut -c14-16` `git log | grep -A1 f06d6c751f708 | grep \>$ | awk '{ print $2,$3; }'`
[21:05:41] <lu_zero> O_o?
[21:06:48] <wbs> andoma: haha, nice
[21:07:09] <spaam> what does it do?
[21:07:16] <andoma> it prints a message
[21:07:17] <mru> try and see
[21:08:35] <spaam> awesome
[21:09:21] <lu_zero> funny
[21:09:39] <andoma> same guy also implemented an mp3 decoder in haskell
[21:11:19] <mru> ouch
[21:11:39] <mru> that's just not sane
[21:13:32] <andoma> no, it isn't :)
[21:15:45] <lu_zero> haskell...
[21:23:49] <mru> haskell may have uses, though I've yet to see one, but codecs ain't one
[21:24:27] <Dark_Shikari> mru: I could imagine haskell being useful for high-level stuff.
[21:24:38] <Dark_Shikari> That is, consider writing high-level design in haskell, and DSP functions in asm and C.
[21:24:56] <Dark_Shikari> Not necessarily the best idea, but it would be a less stupid model.
[21:25:05] <mru> that's not what andoma said
[21:27:31] <andoma> anyway, the guy wrote a blog post about it...
[21:27:34] <andoma> http://blog.bjrn.se/2008/10/lets-build-mp3-decoder.html
[21:28:14] <andoma> rather good, especially if you want to know a bit about mp3 itself
[21:28:25] <Kovensky>  <@andoma> same guy also implemented an mp3 decoder in haskell <-- link
[21:28:31] <Kovensky> so I can break a haskellfag's mind
[21:28:38] * Kovensky scrolls down and sees it
[21:28:46] <andoma> ^ that's the link
[21:29:53] <BBB> wbs: not surprised. Thanks for testing, great b/c now it'll work with real also :)
[21:31:42] <j0sh> ghc (haskell compiler) is supposed to be pretty good
[21:32:12] <ruggles> what is a nice generic name for format conversion dsputils when i split them out from DSPContext? i was thinking fmtconvert.c/h/asm/S/etc... and FmtConvDSPContext or put in libavcore and call it AVFmtConvDSPContext?
[21:32:32] <BBB> wbs: why do you need to initialize real_challenge[] to ""?
[21:32:55] <lu_zero> j0sh: at least twice as painful to bootstrap than gcc
[21:33:04] <wbs> BBB: because we unconditionally copy it into rt->real_challenge, and if uninitialized, we'd might read out of bounds or read uninitialized data there
[21:33:20] <BBB> the original one only uses it if server == REAL
[21:33:26] <BBB> maybe that's what you should do here also?
[21:33:34] <mru> compiler ... pretty good .. lol
[21:33:54] <wbs> yeah, it's only used if server == REAL, but it feels less cluttered that way to copy it in every case
[21:34:22] <mru> ruggles: talking about float/int conversion etc?
[21:34:23] <BBB> it's NULL vs. "\0", not exactly identical
[21:34:32] <BBB> well I don't care
[21:34:50] <wbs> BBB: no, if it's an array, it's not NULL, it just contains uninitialized data
[21:34:52] <BBB> it's just that in one place it's server==REAL?real_challenge:NULL now, and in the other it's real_challenge and for that you initialize it to ""
[21:35:17] <BBB> it's a little inconsistent is all I wanted to say :-p
[21:35:20] <wbs> ah ;P
[21:35:21] <BBB> I know "\0" != NULL
[21:35:30] <BBB> anyway, if you prefer it this way it's fine
[21:35:34] <BBB> it works, which is more important
[21:35:35] <mru> ruggles: I'd say drop the "DSP" from the name
[21:35:50] <mru> and maybe abbreviate a bit less
[21:35:59] <mru> formatconv or fmtconvert perhaps
[21:37:22] <BBB> FmtConvert is short enough
[21:37:41] <ruggles> i like that one better. more similar to AV_SAMPLE_FMT_*
[21:38:00] <mru> then it's settled
[21:38:15] <ruggles> should it go in libavcore? or wait until all of audioconvert is there?
[21:38:16] <mru> oh no, I'll never fit a bike in this tiny shed
[21:38:22] <ruggles> :)
[21:38:46] <mru> ruggles: keep in in lavc for now
[21:38:59] <mru> let's see what it ends up looking like, then we can decide where to put it
[21:39:09] <ruggles> sounds good.
[21:46:35] <Kovensky> <@BBB> I know "\0" != NULL <-- ofc not, "\0" is just 2 bytes, NULL is 4 or 8 bytes depending on the word size :)
[21:46:56] <Kovensky> or are there any platforms people still care about that have a non-0 NULL?
[21:54:08] <j0sh> where did the ffmpeg foundation money come from? (just wondering)
[21:54:25] <merbanan> gsoc
[21:54:32] <merbanan> and settlements
[21:54:43] <merbanan> some are donations
[21:55:04] <j0sh> settlements? lol
[21:55:20] <j0sh> so threatening legal action actually does work?
[21:55:26] <merbanan> yes
[21:55:30] <j0sh> cool
[21:55:33] <merbanan> we have a lawyer
[21:55:54] <Compn> a team of lawyers
[21:55:55] <CIA-43> ffmpeg: Martin Storsjö <martin at martin.st> master * r2762a7a28b ffmpeg/libavformat/ (rtsp.c rtsp.h rtspdec.c):
[21:55:55] <CIA-43> ffmpeg: rtspdec: Retry with TCP if UDP failed
[21:55:55] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:56:01] <Compn> ;p
[21:56:17] <CIA-43> ffmpeg: Martin Storsjo <martin at martin.st> master * rfef5649a82 ffmpeg/libavformat/ (rtsp.c rtsp.h):
[21:56:17] <CIA-43> ffmpeg: rtsp: Make make_setup_request a nonstatic function
[21:56:17] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:56:25] <merbanan> sflc
[21:56:28] <CIA-43> ffmpeg: Martin Storsjo <martin at martin.st> master * re836b1b085 ffmpeg/libavformat/rtspdec.c:
[21:56:28] <CIA-43> ffmpeg: rtspdec: Move rtsp_read_pause up, next to rtsp_read_play
[21:56:28] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:56:30] <Compn> yep
[21:56:39] <CIA-43> ffmpeg: Martin Storsjo <martin at martin.st> master * r93e7490ee0 ffmpeg/libavformat/ (rtsp.c rtsp.h):
[21:56:39] <CIA-43> ffmpeg: rtsp: Split out a function undoing the setup made by ff_rtsp_make_setup_request
[21:56:39] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:56:41] <CIA-43> ffmpeg: Martin Storsjo <martin at martin.st> master * raeb2de1c82 ffmpeg/libavformat/rtsp.c:
[21:56:41] <CIA-43> ffmpeg: rtsp: Use ff_rtsp_undo_setup in the cleanup code in ff_rtsp_make_request
[21:56:41] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[21:57:03] <thresh> what about the mails?
[21:57:55] <Compn> reimar's non utf-8 name got stuck at the scripts
[21:58:04] <Compn> i guess
[21:58:10] <Compn> if you arent utf8, you arent a person
[21:58:21] <Compn> its 1984 all over!
[21:58:55] <thresh> haha
[21:59:03] <wbs> jannau: hey, where did my 'ö's go on some of the commits? ;P
[21:59:27] <mru> wbs: you sent them that way
[22:00:31] <thresh> i've added $author_name = encode("MIME-Q", $author_name); in git-notify
[22:00:38] <thresh> should probably work
[22:00:42] <wbs> mru: no, they sure look proper to me, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/104199.html
[22:01:54] <merbanan> wbs: embrace you new name
[22:02:34] <wbs> merbanan: I've got no problem with it being either way, as long as it would be consistent... since it was written with an 'ö' in the rewritten svn commits, I've changed to use that in my git commits in this repo, too
[22:03:12] <mru> wbs: resistance is futile
[22:03:58] <lu_zero> ^^;
[22:04:16] <wbs> consistence, too, apparently
[22:04:22] <thresh> elenril: and yeah I'm a videolan folk as you might have noticed by /whois thresh :P
[22:04:30] <jannau> wbs: sorry, patchwork or the patchwork client seem to have stripped them
[22:05:02] <lu_zero> wbs: I could commit using all my names and then remove one or the other
[22:06:05] <wbs> lu_zero: yeah, you've got a bit more combinatorics ;P
[22:07:35] <lu_zero> =)
[22:07:40] <jannau> I'll commit from my mailer from now on, 5/5 with proper ö was committed from there since patchwork missed the the updated patch
[22:09:30] <thresh> btw, were there just two git commits by reimar?
[22:09:48] <thresh> I'll just resend the mails
[22:10:15] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * refa6ce9982 ffmpeg/ffserver.c: ffserver: put gcc attribute under proper ifdef
[22:11:42] <jannau> thresh: yes, only two after the from was changed
[22:12:21] <mru> you'd be surprised how many spam mails are stopped by strict header checks
[22:15:43] <thresh> thanks, seems fixed
[22:21:17] <thresh> mru: well I wonder why spammers are so stupid they don't use proper MTA
[22:21:36] <thresh> no idea if postfix is capable of shooting out thousands of mails at a time, though
[22:22:11] <mru> postfix maybe doesn't run so well on botnets
[22:22:45] <thresh> but still, I would expect them to analyze logs to minimize costs
[22:22:55] <thresh> well maybe not, as infecting another machine is cheaper
[22:26:53] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * re63dd5fb04 ffmpeg/tests/ (fate/h264.mak ref/fate/h264-extreme-plane-pred):
[22:26:53] <CIA-43> ffmpeg: fate: add h264 test for extreme cases in planar prediction
[22:26:53] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:27:37] <Dark_Shikari> \i/
[22:27:39] <Dark_Shikari> er, \o/
[22:28:05] <mru> I don't want to know what that first thing represents
[22:28:55] <Dark_Shikari> a typo.
[22:30:11] <merbanan> freudian misshap
[22:30:59] <JEEB> FreudWasRight
[22:34:25] <CIA-43> ffmpeg: Jason Garrett-Glaser <darkshikari at gmail.com> release/0.6 * r4ac56bf7dc ffmpeg/libavcodec/vorbis_dec.c:
[22:34:25] <CIA-43> ffmpeg: Fix crashes in vorbis decoding found by zzuf
[22:34:25] <CIA-43> ffmpeg: Fixes issue 2322.
[22:34:25] <CIA-43> ffmpeg: Originally committed as revision 25591 to svn://svn.ffmpeg.org/ffmpeg/trunk
[22:34:25] <CIA-43> ffmpeg: (cherry picked from commit 3dde66752d59dfdd0f3727efd66e7202b3c75078)
[22:34:25] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[22:34:33] <CIA-43> ffmpeg: Frank Barchard <fbarchard at google.com> release/0.6 * r5e3d023702 ffmpeg/libavcodec/vorbis_dec.c:
[22:34:33] <CIA-43> ffmpeg: Check rangebits to avoid a possible crash.
[22:34:33] <CIA-43> ffmpeg: Fixes issue 2548 (and Chrome issue 68115 and unknown CERT issues).
[22:34:33] <CIA-43> ffmpeg: Patch by Frank Barchard, fbarchard at google
[22:34:34] <CIA-43> ffmpeg: Originally committed as revision 26365 to svn://svn.ffmpeg.org/ffmpeg/trunk
[22:34:34] <CIA-43> ffmpeg: (cherry picked from commit 13184036a6b1b1d4b61c91118c0896e9ad4634c3)
[22:34:35] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[22:34:43] <_av500_> since the coup, cia spams a lot here :)
[22:34:51] * _av500_ kicks CIA-43 
[22:34:52] <CIA-43> ow
[22:35:11] <Kovensky> what, svn commits:?? o_O
[22:35:39] <wbs> cherrypicked to release/0.6
[22:37:09] <_av500_> the donation thread took a strange turn
[22:38:53] <Kovensky> oh lol
[22:39:09] <Kovensky> the lack of colors on CIA here makes it a bit less obvious ._.
[22:39:41] <siretart> jannau: thanks for pushing, though some OK would have been okay, I can push myself. I just solicited for opinions :-)
[22:39:45] <spaam> Kovensky: you like colors? ;)
[22:43:01] <jannau> siretart: I know, I wanted sligthly different commit messages and figured it would be easier if I just push them
[22:43:38] <mmu_man> mIRC colors crash PalmOS clients running on 4800bauds GSM
[22:43:49] <mmu_man> but I didn't see anyone using it for some time :)
[22:44:07] <spaam> mmu_man: lets start using it? :)
[22:44:50] <siretart> jannau: ah, I see, thanks!
[22:45:05] <siretart> good night
[22:45:10] <lu_zero> nite
[22:48:17] <ruggles> mru: what are the parameter constraints for ff_float_to_int16_neon?
[22:48:37] <mru> 16-byte aligned, multiple of 8 elements iirc
[22:49:07] <ruggles> good. same as x86.
[22:52:20] <lu_zero> NASCA DRM FILE - VER1.00 <- rings any bell?
[22:53:16] <_av500_> taco bell?
[22:54:37] <Flameeyes> hrm, why would ff_acelp_interpolate be unused? o_O
[22:56:12] <_av500_> i see 3 codecs use it
[22:56:24] <Flameeyes> _av500_: don't they use the final 'f' version
[22:56:24] <Flameeyes> ?
[22:56:53] <_av500_> i am blind
[22:57:25] <lu_zero> Flameeyes: integer and float variants might be incomplete across audio codecs
[22:57:59] <Flameeyes> lu_zero: there is no use of the integer version; I was more looking into an answer like "because it was migrated to float" or "because nobody migrated them from float" or "future use"
[22:58:23] <mru> BBB: ping
[22:59:12] <Flameeyes> sigh trying to make sense of my missingstatic output is difficult
[22:59:41] <Flameeyes> because it's not easy to tell what is "unused, for future extension", "no longer used" or "will go away at next ABI bump"
[23:01:31] <lu_zero> Flameeyes: nobody had the integer/float implementation done yet
[23:03:28] <lu_zero> BBB: rdt adds streams while parsing the sdp as well am I wrong?
[23:04:11] <mru> BBB: I know you're there
[23:04:15] <mru> I need your help
[23:04:24] <BBB> mru: pong
[23:04:27] <BBB> lu_zero: it does
[23:04:31] <mru> 8x8 planar prediction is busted on x86
[23:04:38] * mru fucked up testing yesterday
[23:04:42] <BBB> shit
[23:04:45] <BBB> I'll fix tonight
[23:04:48] <mru> but I only added the test...
[23:05:11] <mru> it's the pred8x8_plane_* functions
[23:05:41] <mru> but I can't make heads or tails of it
[23:05:56] <mru> it's several times bigger than my neon code...
[23:06:06] <BBB> it's unlooped which was a little faster
[23:06:09] <BBB> I'll fix it, don't worry
[23:06:57] <mru> it's full of ifdefs too
[23:07:20] <BBB> x86-64/32 misery
[23:07:43] <mru> the only loop in mine is a 3-insn loop of 8 iterations at the end
[23:07:48] <mru> and it's memory bound anyway
[23:07:58] <BBB> I have that loop also
[23:08:01] <BBB> I don't know why mine is bigger
[23:08:03] <BBB> it's just messy
[23:08:09] <BBB> but it's really fast :) it's faster than x264's
[23:08:18] <mru> it has the 32/64 conditionals
[23:08:24] <mru> and some svq3 mess
[23:08:36] <BBB> oh right, rounding differences
[23:08:39] <BBB> fun
[23:08:41] <mru> and mmx/sse/ssssseeee
[23:08:47] <BBB> yes
[23:09:00] <BBB> I'll fix it, don't worry, I'm quite sure I know where the bug is :-p
[23:09:12] <mru> good
[23:09:53] <BBB> you can try backporting my 16x16 fix to 8x8, if you're adventurous
[23:10:05] <BBB> I currently have my tree messy for the emu_edge patch
[23:10:11] <BBB> I should learn to create branches per big patch
[23:10:15] <BBB> can I do that now?
[23:10:42] <mru> I was trying to figure out what the hell that changed
[23:11:00] <jannau> BBB: you could just stash your current changes
[23:11:06] <jannau> git help stash
[23:11:58] <BBB> mru: the sum of H coefficients (8*tl+7*t0...-8*t15) * 17 (I think)
[23:12:01] <BBB> overflows in a word
[23:12:07] <BBB> I did that as a vector operation in words
[23:12:15] <jannau> git checkout -b work/emu_edge && git add -p && git commit -m "wip" would work too
[23:12:18] <BBB> it moves it below where it's in a regular register, so dword at least
[23:12:32] <BBB> and then it does not overflow
[23:12:33] <mru> oh, it's being moved to scalar?
[23:12:39] <jannau> that would create your branch
[23:12:39] <BBB> yes
[23:12:48] <BBB> so I moved the code to a place where we already moved it to scalar anyway
[23:12:52] <BBB> then it doesn't get slower
[23:13:38] <mru> no 32-bit in vectors?
[23:15:26] * Flameeyes mutters something about exuberant-ctags failing badly without pre-processing headers
[23:15:26] <BBB> I could, but scalar is faster
[23:15:39] <lu_zero> how's possible?
[23:16:00] <BBB> lu_zero: it's a single operation, so I don't load multiple values in multiple registers
[23:16:05] <BBB> it's just a single mul+shift
[23:16:10] <BBB> then scalar is not slower than vector
[23:16:14] <BBB> in fact it can be faster
[23:16:31] * mru tries to find the corresponding place in the 8x8 code
[23:16:33] <mru> without much luck
[23:16:47] <lu_zero> the same operation shouldn't be applied over a vector?
[23:17:01] <mru> ah, I think I found it
[23:17:09] * lu_zero was distracted while looking at rdt and asf
[23:17:10] <BBB>     pmullw       m0, [pw_17]
[23:17:11] <BBB>     paddw        m0, [pw_16]
[23:17:11] <BBB>     psraw        m0, 5 is the stuff to remove
[23:17:28] <mru> that much I figured out already
[23:17:28] <BBB>     movd        r1d, m0
[23:17:29] <BBB>     movsx       r1d, r1w
[23:17:36] <mru> and I just spotted that
[23:17:36] <BBB> under that movsx, do the mul, add and shift
[23:17:40] <BBB> :)
[23:17:44] <BBB> you're too quick ;)
[23:20:47] <mru> hmm, lea doesn't work here
[23:21:02] <BBB> use imul
[23:21:09] <BBB> we use pmullw also, it shouldn't be slower
[23:22:06] <mru> \o/ it works
[23:22:17] <mru> wait, maybe it doesn't
[23:22:27] <mru> but it assembles
[23:22:43] <BBB> make fate h264-extreme-plane-test
[23:22:50] * Flameeyes feels like crying
[23:22:57] <mru> hey, it _does_ work
[23:23:02] <BBB> Flameeyes: ?
[23:23:13] <Flameeyes> exuberant-ctags goes tfu because it doesn't pre-process correctly files
[23:23:16] <BBB> mru: OMG YOURE OUR NEW X86 ASM HERO!!! CAN I TAKE A PICTURE WITH YOU?!?
[23:23:33] <Flameeyes> so I can't use it to produce a list of symbols to be considered the public API
[23:23:55] <Flameeyes> and without that, trying to make heads or tails of what I see missing av or ff prefixes is near impossible
[23:25:45] <Flameeyes> beside the fact that ffserver takes up symbols that are not in the public api anyway
[23:25:57] <mru> BBB, Dark_Shikari: patch waiting for your review
[23:26:00] <BBB> reviewed
[23:26:37] <lu_zero> Flameeyes: headers missing?
[23:26:47] <Flameeyes> lu_zero: and prefixes.. "rtp_get_local_rtp_port"
[23:27:41] <CIA-43> ffmpeg: Mans Rullgard <mans at mansr.com> master * r80944df720 ffmpeg/libavcodec/x86/h264_intrapred.asm:
[23:27:41] <CIA-43> ffmpeg: x86: fix overflow in h264 8x8 planar prediction
[23:27:41] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:27:45] <BBB> ty mru
[23:27:50] * BBB continues working on emu_edge
[23:28:00] <BBB> brb
[23:28:11] * mru washes hands
[23:28:14] * lu_zero doesn't like it...
[23:28:23] <lu_zero> mru: too much dust?
[23:28:32] <mru> too much x86
[23:28:40] * lu_zero is considering how to get the chained demuxer for mpegts
[23:29:02] <mru> chained how?
[23:29:46] <lu_zero> rtp -> depack -> feed a pb -> mpegts
[23:39:48] <Flameeyes> okay I sent a bunch of patches, see which ones make sense please, and at least it should slightly reduce the mess
[23:39:57] <mru> on it
[23:41:24] <Flameeyes> I guess the next step would be to get a list of symbols exported that need to be renamed at ABI bump... rename them and bump ABI
[23:42:07] <Flameeyes> and does anybody have contact with http://www.bombono.org/cgi-bin/wiki/ ?
[23:44:06] <lu_zero> Flameeyes: who packaged it in gentoo?
[23:44:36] <Flameeyes> lu_zero: dilfridge
[23:46:35] <j-b> Flameeyes: glad to see you around... You still are a legend here...
[23:47:04] <Flameeyes> j-b: I'm not sure how to read it ^^;; I tend to be very real-world myself :P
[23:47:11] <mru> j-b: he's "the other diego"
[23:47:22] <j-b> Flameeyes: read it the good way
[23:47:50] <j-b> mru: well, he has a few fans...
[23:47:59] <Flameeyes> j-b: I will :D thanks, I try to still be around, time allowing to do stuff... hiding ffmpeg's symbols is a veeeery old pet peeve of mine :P
[23:48:06] <mru> j-b: ah, that's why he's so noisy
[23:48:16] <j-b> Flameeyes: ;)
[23:48:21] <mru> j-b: do you think he could be fitted with water cooling instead?
[23:48:29] <j-b> no idea :)
[23:49:10] <Flameeyes> uhm I wouldn't mind a watercooler in the office actually
[23:49:41] <Flameeyes> but I guess a gbit switch would be more useful
[23:49:44] <Flameeyes> or a coffee, right now
[23:50:03] * mru recently bought a 16-port gbit switch
[23:50:17] <Flameeyes> mru: uhm, which brand, where and how much did you pay for it? :P
[23:50:54] <Flameeyes> I have a 2x5p here and I don't think they are very happy of working this way :/
[23:51:37] <mru> Flameeyes: this one: http://www.scan.co.uk/products/netgear-gs716teu-pro-safe-16-port-gigabit-smart-switch
[23:52:19] <mru> I got tired of cheap switches locking up, dropping packets or otherwise being a nuisance
[23:52:40] <mru> the old one had taken to intermittently hating the mac g4
[23:52:53] <mru> dropping 90% of packets to and/or from it
[23:56:00] <Flameeyes> ouch. not exactly cheap but not bad either.. is that a sane site?
[23:56:27] <mru> it's usually sane
[23:56:55] <mru> I've found the £50 switches to be less than reliable
[23:57:03] <mru> time to try something better
[23:57:06] <Flameeyes> yeah they tend to be
[23:57:37] <Flameeyes> I wonder if they sell outside of UK, within EU VAT discount area
[23:57:46] <mru> no idea
[23:58:02] <mru> but surely someone in .it sells that or something similar
[23:59:04] <Flameeyes> mru: at twice the price usually
[23:59:18] <mru> hmm
[23:59:45] <DonDiego> so...
[23:59:50] <DonDiego> WTF?
[23:59:57] <roxfan> http://www.amazon.fr/NETGEAR-ProSafe-GS716T-Commutateur-Ports/dp/B0007TFG8U/