[FFmpeg-devel-irc] IRC log for 2010-02-18

[irc at mansr.com]

[00:02:58] <Vitor1001> Hmm, there is something seriously miscompiled here :(
[00:03:10] <BBB> ?
[00:03:11] <Vitor1001> I'm getting a segfault for every wmavoice file
[00:03:28] * BBB checks patch
[00:04:10] * Vitor1001 try make distclean and rebuild
[00:04:23] <Vitor1001> ccache is great
[00:04:26] <BBB> did it play without the patch I just gave you?
[00:05:04] <Vitor1001> yes.
[00:05:36] <BBB> it might be the lamely named tables powtab, sintab, etc.
[00:05:43] <BBB> I think lavc has other tables with the same name
[00:05:50] <Vitor1001> I'll try gdb
[00:06:05] <mru> it shouldn't link if there are name clashes
[00:06:25] <Vitor1001> BBB: I think you are using FFT with unaligned buffers
[00:06:39] <BBB> oh, my debug code?
[00:06:54] <Vitor1001> probably
[00:07:03] <BBB> comment it all out, it doesn't do anything
[00:07:06] <BBB> in com_wmsapf.c
[00:07:23] <BBB> search for rdft_calc
[00:07:27] <BBB> and surrounding lines
[00:07:35] * Vitor1001 tries
[00:07:47] <Vitor1001> cool, working now
[00:08:30] <BBB> you in jersey now?
[00:09:03] <BBB> hm, .fr
[00:09:07] <BBB> you're working odd hours
[00:09:10] <Vitor1001> yeah
[00:09:21] <Vitor1001> sleeplessness today :p
[00:10:44] <Vitor1001> do you know the size of arr1?
[00:11:13] <BBB> in which function?
[00:11:23] <Vitor1001> DoSmoothFilter
[00:12:40] <BBB> 0x80
[00:12:44] <BBB> or actually ox82
[00:19:50] * BBB decides to giv up and head home
[00:20:02] <BBB> jez9999, I'm still waiting for a new patch on issue 1740
[00:20:12] <jez9999> BBB: hum
[00:20:22] <jez9999> i cant RDC into my work machine, i'll update it tomorrow
[00:20:26] <BBB> okies
[00:20:30] <jez9999> but i have to say it seems pointless
[00:20:37] <jez9999> the way i've done it is 100% fine
[00:20:38] <jez9999> ;-)
[00:20:41] <CIA-90> ffmpeg: michael * r21874 /trunk/ffplay.c: fix issue 1747
[00:22:04] <BBB> just for the sake of preventing mental insanity, let's just do as michael requested, I in fact agree with him
[00:22:09] <jez9999> why?
[00:22:22] <jez9999> even in the sense of multithreaded apps, wouldn't they all be using different filenames?
[00:22:29] <jez9999> i can't see why they'd share that memory
[00:23:05] <BBB> why would they use different filenames?
[00:23:26] <jez9999> because they're triggered by different incarnations of av_open_* ?
[00:23:29] <BBB> you could one 10 threads for h264 decoding in that file, plus one for aac and one main thread plus one for video playback and another for network buffering
[00:23:55] <BBB> they might all want to access that pointer
[00:24:08] <jez9999> but until the file was opened, none of them would try to access it
[00:24:37] <BBB> how do you know?
[00:24:48] <jez9999> because the alternative is opening the file multiple times
[00:24:55] <jez9999> if that happens, i'd consider that behaviour to be the bug
[00:25:51] * BBB omg's
[00:27:12] * BBB decides again to go home
[00:27:21] <jez9999> ...
[00:27:22] <BBB> Vitor1001, thanks for helping, let's talk more tomorrow
[00:27:34] <jez9999> so ffmpeg does open the file multiple times? :-)
[00:27:53] <BBB> jez9999, I'm telling you a patch to get your patch applied... why are you being obstructive?
[00:28:23] <jez9999> so copy filename to internal allocated memory, and pass that to open()?
[00:28:29] <jez9999> filename must never change
[00:28:42] <BBB> if open of filename with ? fails
[00:28:43] <BBB> {
[00:28:55] <BBB> char filename[..]; strcpy(filename, s->filename);
[00:29:05] <BBB> '?' -> '/0';
[00:29:10] <BBB> open that;
[00:29:11] <BBB> }
[00:29:19] <jez9999> i was simply trying to explain why it almost seems counter-intuative to me to do that
[00:29:24] <jez9999> unless i made a blunder somewhere
[00:29:36] <jez9999> not trying to be argumentative for its own sake :-)
[00:30:02] <jez9999> semantically, you're saying "multiple threads might want to open the file at the same time"
[00:31:27] <BBB> not open
[00:31:30] <BBB> access the pointer
[00:31:34] <Vitor1001> BBB: I think I got one
[00:31:37] <BBB> the pointer could be shared
[00:31:43] <BBB> Vitor1001, that was quick
[00:32:05] <Vitor1001> WMAVoiceRealForwFFT_INT()
[00:32:09] <jez9999> BBB: the pointer to the filename or the fd?
[00:32:15] <BBB> jez9999, the pointer to filename
[00:32:24] <jez9999> ok
[00:32:46] <Vitor1001> BBB: check your email
[00:32:50] <BBB> Vitor1001, ok
[00:34:08] <BBB> is this mathematica output?
[00:34:32] <Vitor1001> yes, do you have the software?
[00:34:35] <BBB> no
[00:34:58] <BBB> so what does this mean? </silly>
[00:35:11] <BBB> it means the function does fft(array)/sqrt(8)/
[00:35:12] <BBB> ?
[00:35:21] <Vitor1001> it is just a real FFT with output
[00:35:44] <Vitor1001> {Re[q0], Im[q0], Re[q1], Im[q1], ... }
[00:35:57] <BBB> ah, re/im interleaved
[00:36:11] <Vitor1001> yes, exactly
[00:36:50] <Vitor1001> note that for rdft the way of outputting the real/imaginary part is a bit special
[00:36:58] <Vitor1001> to make it fit in a single vector
[00:37:18] <Vitor1001> see fft-example.c, it uses trivial complex fft to test rdft
[00:37:39] <BBB> I can just change the argument to that function into struct { int re; int im; } x[0x41];
[00:38:05] <Vitor1001> not really
[00:38:09] <Vitor1001> input is real
[00:38:14] <BBB> hmm...
[00:38:17] <BBB> right
[00:38:20] <Vitor1001> output is struct {int re; int im;}
[00:38:36] <Vitor1001> Well, really have to sleep now
[00:38:41] <BBB> ok, thanks
[00:38:41] <Vitor1001> 1h40 am
[00:38:47] <Vitor1001> good luck!
[00:38:51] <BBB> thanks
[00:38:51] <BBB> bue
[00:38:52] <BBB> bye
[00:38:56] * BBB leaves also
[00:38:56] <Vitor1001> bye
[00:41:39] <Dark_Shikari> question about __attribute__((flatten)
[00:41:45] <Dark_Shikari> if A calls B, and B calls C
[00:41:47] <Dark_Shikari> and we flatten A
[00:41:51] <Dark_Shikari> will C be inlined all the way into A?
[00:43:19] <mru> hopefully not
[00:43:21] <mru> try and see
[00:44:23] <Dark_Shikari> basically I have the following
[00:44:28] <Dark_Shikari> A calls X a lot, I want X inlined into A
[00:44:33] <Dark_Shikari> A also calls B, and A is the only thing that calls B
[00:44:38] <Dark_Shikari> B calls X a lot, but I don't want X inlined into B
[00:44:48] <Dark_Shikari> because the calls to X from B are less important.
[00:48:17] <Dark_Shikari> meh, didn't help, gcc didn't fully flatten it even one level.
[00:48:18] <Dark_Shikari> blegh.
[00:48:26] * Dark_Shikari ports ffmpeg-style partition tracking to x264
[00:50:54] <Dark_Shikari> mru: is there a way to have a function that is inlined if its arguments are constant, and a function call if they are not?
[00:51:16] <Dark_Shikari> I have some variable-size fill_rectangles in my x264 code
[00:51:18] <mru> that would be way too useful ;-)
[00:51:21] <Kovensky> partition?
[00:51:29] <Dark_Shikari> lol
[00:51:49] <Dark_Shikari> the final hard part now: port the partition checks to deblocking
[00:51:58] <mru> you can probably hack something up with flatten, always_inline, and builtin_constant_p
[00:52:12] <mru> it won't be pretty...
[00:52:13] <Dark_Shikari> lol
[00:52:15] <Dark_Shikari> oh dears
[00:53:42] <iive> i may sound very naive, but isn't pure simple `inline` supposed to that automagically?
[00:54:33] <mru> plain inline is only a hint
[00:54:45] <mru> it has no defined semantics
[01:32:19] <Dark_Shikari> more cdecl nastiness
[01:32:27] <Dark_Shikari> what do you call a pointer to a static const uint8_t[2][4][4]?
[01:32:45] <Dark_Shikari> *(x)[2][4]?
[01:33:25] <mru> static const (*x)[2][4][4]
[01:33:35] <Dark_Shikari> er, but don't you not include the [2]?
[01:33:53] <mru> in that case your question is wrong
[01:34:09] <Dark_Shikari> ok, then I'll make it clearer
[01:34:12] <Dark_Shikari> static const uint8_t mv_check[2][2][4][4]
[01:34:16] <Dark_Shikari> const uint8_t *(mv_check)[2][4][4] = mv_check[sub8x8];
[01:34:38] <mru> the * goes inside the ()
[01:34:42] <Dark_Shikari> oh yeah
[01:38:18] <Dark_Shikari> also, 4-D arrays are a great way to confuse people
[01:39:33] <Kovensky> nothing like 5-D arrays though
[01:46:41] <peloverde> bah that's kid's stuff, aliasing ParametricStereo on top of the SBR right channel and turning it back into the right channel when you are done through a union pun is a good way to confuse people
[01:52:16] <Kovensky> what
[01:52:34] <Kovensky> oshi- I just proved your point
[01:58:12] <peloverde> something vaguely like "union { struct { SBRData data[2]; } stereo; struct { SBRData data; ParametricStereo ps; } mono; } channel_data;"
[06:53:51] * elenril pokes KotH 
[07:00:19] <pJok> mornings
[07:01:58] <kshishkov> goda morgnar
[07:02:39] <thresh> moroning
[07:05:24] <benoit-> hej
[07:05:30] <kshishkov> hejsan
[07:20:51] * KotH stabs elenril 
[07:20:59] <KotH> good morning, everyone else!
[07:21:25] <kshishkov> god morgon
[07:21:38] <elenril> sup BofH
[07:21:46] <elenril> can i have access to incoming?
[07:22:15] <KotH> what do you pay?
[07:22:41] <elenril> a virtual cake?
[07:22:49] <KotH> the cake is a lie
[07:22:57] <KotH> anything else to offer?
[07:23:18] <elenril> curse, my evil plan is foiled
[07:23:46] <kshishkov> an eternal soul? preferably from somebody else
[07:24:01] <KotH> i'd also take your first born
[07:24:09] <thresh> i love to see our sport officials shit themself because of no results in Olympics
[07:24:10] * elenril offers Kovensky's soul
[07:24:44] <kshishkov> thresh: what about that Georgian guy?
[07:24:47] <KotH> elenril: bah.. who'd take that soiled thing?!?
[07:25:03] <thresh> kshishkov: mm?
[07:25:45] <kshishkov> thresh: you should have heard - an accident on Olympics opening
[07:26:44] <thresh> yes, i did
[07:27:37] <kshishkov> anyway, there's always football
[07:27:48] <thresh> what i really mean is the whole system is FUBAR, not only the sports one, and they try to put a brave face on a sorry business
[07:28:05] <thresh> yeah, with no Guus our football is fubared as well :-)
[07:28:22] <kshishkov> go suport Ukrainian football
[07:28:26] <kshishkov> *support
[07:31:50] <pJok> isn't handball big in ukraine?
[07:32:09] <kshishkov> jo
[07:32:29] * kshishkov does not know any sport Ukraine does not suck at
[07:32:41] <pJok> hehe
[07:33:14] <pJok> considering handball aparantly was invented (at least the current form of it) in denmark, im surprised that its not bigger in denmark
[07:33:29] * elenril wonders if he's the only one who finds the concept of a nation failing at sport weird
[07:35:06] <kshishkov> yes, in the beginning of XXth century there were many Englishmen living here, so our local football team was really great beck in 1920s
[07:35:27] <kshishkov> *back
[07:36:01] <kshishkov> the same reason why one of districts here is called "Neue Bayern" if translated from Ukrainian
[07:36:10] <pJok> the only thing denmark seems to be good at at the moment is tennis
[07:36:39] <pJok> considering Caroline Wozniacki is climbing up the world rank quite fast
[07:37:12] <kshishkov> heh, but the most famous tennis player lived in Russia
[07:37:59] <pJok> Kurnikova?
[07:38:03] <kshishkov> Yeltsin
[07:38:19] <pJok> shows what i know
[07:38:20] <pJok> :)
[07:38:57] <kshishkov> he was also famous Russian national sport player too
[07:40:29] <thresh> vodking
[08:12:17] <siretart> Dark_Shikari: FYI: https://launchpad.net/ubuntu/+source/x264/2:0.85.1442+gitfcf70c-1
[08:13:06] * siretart not really around, I'm at workshop, will return tonight very late
[08:13:09] <Dark_Shikari> what's epoch?
[08:14:21] <Dark_Shikari> oh btw, I've added a gpac version check locally to get rid of those nasty problems people have been having
[08:14:46] <astrange> epoch numbers override versions so you can break the version numbering
[08:14:47] <kshishkov> Dark_Shikari: it means their x264 is now in XXIst century
[08:15:12] <Dark_Shikari> astrange: heh
[08:18:38] <siretart> Dark_Shikari: epoch is the number before the ':'
[08:18:46] <Dark_Shikari> ah.
[08:20:25] <Dark_Shikari> siretart: did you get lavf input working properly btw?
[08:20:35] <Dark_Shikari> or will that not be ready for lucid
[08:55:18] <Dark_Shikari> kshishkov: did you bench the mode_list thing?
[08:55:19] <Dark_Shikari> was it faster?
[08:56:36] <Dark_Shikari> also, what's bink_scan[]?
[08:58:04] <kshishkov> no difference in speed
[08:58:13] <kshishkov> bink scantable, of course
[08:58:38] * kshishkov was too unsure and lazy to permute quant matrices
[08:59:12] <Dark_Shikari> wait, if no difference, why did you do it? >_>
[08:59:53] <Dark_Shikari> and yeah, permute your quant tables.  faster that way
[09:00:12] <Dark_Shikari> also, why is it bink_scan and not scan?
[09:00:16] <Dark_Shikari> do the quant order tables have a different scan order?
[09:00:23] <Dark_Shikari> block[scan[idx]] = (block[scan[idx]] * quant[bink_scan[idx]]) >> 11;
[09:01:32] <Dark_Shikari> btw, when measuring speed I assume you used START/STOP timer?
[09:01:36] <Dark_Shikari> it's hard to get "no difference" with timer
[09:02:25] <kshishkov> well, bink_scan[] is DCT scan order
[09:03:04] <kshishkov> scan[] is permuted bink_scan[] so somebody may use optimized Bink IDCT with trasposed scan order ;)
[09:03:24] <Dark_Shikari> either way, try to get everything permuted to minimize scan[] derefs
[09:03:32] <Dark_Shikari> especially differing scan derefs
[09:03:36] <Dark_Shikari> and add comments as to why they differ
[09:03:53] <kshishkov> it's obvious
[09:03:54] <Dark_Shikari> 1419-1432
[09:04:00] <Dark_Shikari> wasn't obvious to me
[09:04:10] <Dark_Shikari> so, in those lines, the if( i+run check and the i+= run can be merged
[09:04:17] <Dark_Shikari> i.e. move the i += run up to the top, after int run
[09:04:37] <Dark_Shikari> furthermore, it looks like that if is duplicating the while() check too
[09:04:50] <Dark_Shikari> not sure if that's factorable out or not
[09:04:56] <Dark_Shikari> but either way you can at least factor out the i + run.
[09:04:59] <kshishkov> ok
[09:05:15] <Dark_Shikari> unclamped or nonclamped?  I think unclamped is more correct english
[09:05:56] <kshishkov> different meanings to me
[09:06:05] <Dark_Shikari> unclamped == not clamped
[09:06:10] <Dark_Shikari> nonclamped == not a word
[09:06:22] <kshishkov> it sounds more like "it was clamped, now it's not"
[09:06:28] <Dark_Shikari> lol
[09:06:50] <Dark_Shikari> btw, that change I mentioned above should be done in both places
[09:06:56] <kshishkov> done
[09:07:07] <Dark_Shikari> also, I get the feeling in general that you might be able to template some of this code.... I mean the code duplication just eats
[09:07:10] <Dark_Shikari> *just eats at me
[09:07:11] <Dark_Shikari> it's annoying
[09:07:16] <Dark_Shikari> but if there's really no better way, there's no better way
[09:07:33] <Dark_Shikari> ... why do we do coordmap[*scan[]]?
[09:07:36] <Dark_Shikari> that's a double-deref
[09:08:31] <Dark_Shikari> double-derefs for every single iteration of a loop like that are inefficient
[09:08:40] <Dark_Shikari> got to be a better way to do that
[09:09:09] <kshishkov> [*scan & 7 + (*scan >> 3) * stride], scan++
[09:09:32] <Dark_Shikari> why not eliminate scan and just make the tables cover the scans
[09:09:45] <Dark_Shikari> i.e. have coordmap include the scans
[09:09:50] <Dark_Shikari> you have plenty of L1 cache
[09:10:06] <kshishkov> scan order may be different for each block in that case
[09:10:10] <Dark_Shikari> also,  1743-1745 has brackets but 1741-1742 doesn't
[09:10:20] <Dark_Shikari> kshishkov: ?
[09:10:41] <Dark_Shikari> so if there are X scantables
[09:10:43] <Dark_Shikari> you have X coordmaps
[09:11:25] <Dark_Shikari> ugh...
[09:11:28] <kshishkov> 4*16*64 = 2K
[09:11:28] <Dark_Shikari> I guess you should probably bench
[09:11:32] <Dark_Shikari> i.e. see how common each block type is
[09:11:43] <Dark_Shikari> to decide which ones you have to care about
[09:12:32] <kshishkov> from my observations, both DCT and pattern blocks are quite common
[09:12:49] <Dark_Shikari> and motion?
[09:13:13] <Dark_Shikari> and residue?
[09:13:21] <kshishkov> those too
[09:13:45] <kshishkov> residue blocks are not that common though
[09:14:16] <Dark_Shikari> btw, if you wanted to be silly and find some nice way to optimize pattern blocks
[09:14:21] <Dark_Shikari> you could experiment with something like this
[09:14:30] <Dark_Shikari> lets say the pattern is AABABBAA
[09:14:47] <kshishkov> I know - two masks, multiply and combine
[09:14:50] <Dark_Shikari> yeah
[09:14:57] <Dark_Shikari> two 0x010101 ... masks
[09:15:01] <Dark_Shikari> it'd basically be 64-bit only
[09:15:21] <Dark_Shikari> to warn you, 64-bit multiplies on 32-bit tend to be pessimized by gcc
[09:15:25] <Dark_Shikari> i.e. it won't split it into fast 32-bit code
[09:15:30] <kshishkov> what isn't?
[09:15:42] <Dark_Shikari> lol
[09:15:58] <Dark_Shikari> a profile would be useful btw
[09:16:04] <Dark_Shikari> like an oprofile or something
[09:17:24] <Dark_Shikari> line 798-799: these can be merged with the declarations
[09:17:25] <Dark_Shikari> i.e.
[09:17:27] <Dark_Shikari> int bw = ...
[09:18:13] <Dark_Shikari> +    if (!b->cur_dec  <--wtf is this for?
[09:18:17] <Dark_Shikari> +        b->cur_dec = NULL; \ etc
[09:18:51] <kshishkov> for empty bundles
[09:19:28] <Dark_Shikari> um, but if cur_dec is 0, we already returned
[09:19:36] <Dark_Shikari> so how can it be NULL at the start?
[09:20:38] <kshishkov> why? that's called several times per each plane
[09:21:24] <Dark_Shikari> oh so you're saying there can be no motion values
[09:21:25] <Dark_Shikari> no dcs
[09:21:25] <Dark_Shikari> etc
[09:21:35] <kshishkov> yes
[09:21:37] <Dark_Shikari> k
[09:21:54] <Dark_Shikari> ah, so there's one bundle per row of the frame?
[09:22:26] <kshishkov> each bundle can have data for several rows
[09:22:47] <kshishkov> but it's for multiple of rows, yes
[09:22:50] <Dark_Shikari> wait then why is it run once per row?
[09:23:11] <kshishkov> to fill it again if data depleted
[09:23:50] <Dark_Shikari> that's a bit odd.
[09:23:56] <Dark_Shikari> I guess it's like theora except less stupid
[09:24:31] <kshishkov> it's closer to TM2
[09:24:56] <kshishkov> (which is Ducker TrueMotion 2, not Duck TrueMotion VP3)
[09:24:59] <kshishkov> *Duck
[09:28:35] <Dark_Shikari> either way--awesome decoder.
[09:28:36] * Dark_Shikari sleeps
[09:29:20] * kshishkov thinks it's appropriate to say "in your dreams"
[10:17:07] <nfl> Hi. Is there any way to know if the current frame is even/odd numbered other than from avctx->frame_number?
[10:28:28] <siretart> Dark_Shikari: no. I didn't look into that. didn't you say it just doesn't work with ffmpeg 0.5?
[12:14:13] <CIA-90> ffmpeg: michael * r21875 /trunk/libavcodec/h264_cabac.c: Speedup decode_cabac_field_decoding_flag() by 9 cpu cycles.
[12:16:25] <twnqx> i think michael should not just say how many cycles less he needs
[12:16:39] <merbzt> ?
[12:16:45] <twnqx> 9 out of 100 would be kinda impressive, 9 out of 10000... not so much
[12:18:10] <merbzt> true, but you need to understand the context anyway
[12:19:11] <twnqx> well, yes, but the cabac decoder takes a big amount of the resources in h264 decoding
[12:19:16] <merbzt> cabac is used very much so even if it is only 9 out of 10000 it would matter
[12:19:58] <twnqx> 0.09%?
[12:20:27] <merbzt> what I'd like to get is a benchmark from before christmas and now
[12:20:37] <twnqx> i certainly agree on that
[12:22:14] <merbzt> 0.1% is faster, and I think is has come to a point where the these micro opts are the lowest hanging fruit
[12:23:13] <pross-au> 9 cycles is still 9 cycles
[12:38:32] <CIA-90> ffmpeg: michael * r21876 /trunk/libavcodec/h264.c: Simplify deblock_left/top condition for deblocking_filter=2
[13:09:01] * elenril facepalms
[13:09:24] <elenril> broken id3 in asf
[13:12:19] <kshishkov> what is it doing here in the first place?
[13:12:37] <elenril> mypointexactly
[13:14:02] <elenril> also the way it's stored is very funny
[13:14:13] <elenril> the keys are utf-16
[13:14:43] <elenril> tags themselves are two utf-8 strings
[13:15:11] <elenril> srsly, what mushrooms were they smoking
[13:16:26] <kshishkov> MS Mushrooms Me
[13:17:39] * elenril thinks the most correct solution would be to skip these tags
[13:18:25] <kshishkov> yes
[13:18:26] <Rathann|work> the simplest, maybe :)
[13:21:05] <elenril> simple == good
[13:23:12] <KotH> hey Rathann|work!
[13:41:11] <CIA-90> ffmpeg: mru * r21877 /trunk/libavutil/intreadwrite.h: Add alias-safe union typedefs
[13:41:11] <CIA-90> ffmpeg: mru * r21878 /trunk/libavutil/intreadwrite.h: Use alias-safe types in AV_[RW] macros
[13:41:12] <CIA-90> ffmpeg: mru * r21879 /trunk/libavutil/intreadwrite.h: Use alias-safe types in AV_COPY/SWAP/ZERO macros
[13:45:26] <CIA-90> ffmpeg: mru * r21880 /trunk/libavutil/intreadwrite.h: Add alias-safe aligned AV_[RW]N macros
[14:40:04] <jez9999> BBB: morning
[14:42:49] <jez9999> I see you've commented on patch5 for issue 1740
[15:03:50] <Compn> DonDiego: you should write up a rant on chilling effects. you could educate the masses.
[15:04:27] <DonDiego> i've been thinking about getting that blog that mike offered me ages ago..
[15:05:15] <mru> blogs are actually more fun than I expected
[15:15:03] <superdump> and it seems if you write intelligently, people read it
[15:15:58] <kshishkov> no, you need either pr0n or cats pictures to attract some attention
[15:16:44] <DonDiego> define "attention"
[15:17:20] * Compn has to run afk, bbl
[15:18:06] <kshishkov> a mental state which leads to an action comprising not closing the window with blog post, reading aforementioned article of text and comprehending it
[15:19:35] <DonDiego> so you only read pr0n and cat pics? :)
[15:19:55] <kshishkov> no, but I hint that majority of Internet users do
[15:20:15] <DonDiego> as i said, define "attention"..
[15:20:45] <DonDiego> rob and you do not appear to have the same kind of attention in mind
[15:21:11] <mru> there are many kinds of attention
[15:21:28] <mru> the two most important ones are from people with money and from girls
[15:21:34] <mru> not necessarily in that order
[15:21:48] <mru> so far my blog has only got me the former kind
[15:22:08] <mru> you reckon cat pics would help with that?
[15:22:44] <kshishkov> no, you need SEO for that
[15:25:42] <BBB> dondiego: get a blog, it's fun
[15:25:50] <DonDiego> do you have one?
[15:25:53] <BBB> of course
[15:26:03] <DonDiego> and yeah, i guess i will once i have a bit more time
[15:26:03] <BBB> half of all ffmpeg devs have one
[15:26:04] <kshishkov> a share of gnome blog actually
[15:26:05] <BBB> if not more
[15:26:10] <BBB> indeed
[15:26:20] <BBB> alhough not really gnome-related anymore
[15:26:25] <kshishkov> DonDiego: "once i have a bit more time" - won't happen ever
[15:26:28] <BBB> but hey, it's free
[15:26:37] <DonDiego> kshishkov: it will, after my exam
[15:26:44] * BBB likes kostya's wild west blog
[15:26:48] <kshishkov> BBB: mine is even more misleading
[15:26:59] <kshishkov> named by Mike
[15:32:16] <jez9999> BBB: why do you say to use 0 instead of '\0'?
[15:32:27] <jez9999> i was always taught to use '\0' or NUL when setting the null terminator character
[15:32:32] <mru> one char instead of 4
[15:32:44] <mru> they are exactly equivalent in C
[15:32:46] <mru> but not in C++
[15:32:57] <mru> character constants have type int in C
[15:34:03] <BBB> jez9999, as mru says, source code size is smaller
[15:34:07] <BBB> that's a virtue in ffmpeg
[15:34:23] <kshishkov> heh
[15:34:30] <mru> code readability is important
[15:34:42] <jez9999> also, that you support GCC 2.95 is beyond belief
[15:34:54] <jez9999> it was released in July 1999
[15:34:56] <BBB> jez9999, if I don't complain, someone else with - get used to it :)
[15:35:01] <jez9999> please tell me you were just being extra anal
[15:35:03] <BBB> this is just how ffmpeg review works
[15:35:05] <kshishkov> ask mmu_man why we support GCC 2.95
[15:35:09] <mru> jez9999: I suggest you stop bitching before we have to kick you
[15:35:11] <BBB> jez9999, no, everyone would say that
[15:35:16] <jez9999> :-\
[15:35:21] <BBB> don't kick him :)
[15:35:22] <BBB> he's fine
[15:35:29] <mru> if he stops bitching
[15:35:34] <BBB> jez9999, our review is just a bit more anal, generally, than other projects
[15:35:42] <BBB> but it leads to better code
[15:35:44] <BBB> so it's ok
[15:35:57] <jez9999> well support for an ancient compiler is debatably 'better'
[15:35:58] <mru> it's not us being anal, it's them being lax
[15:36:25] <BBB> mru: if you believe in relativity, then that's the same thing :)
[15:36:27] <kshishkov> jez9999: unfortunately, there are OSes where it's standard compiler
[15:36:33] <jez9999> such as?
[15:36:37] <BBB> beos?
[15:36:38] <kshishkov> BeOS
[15:36:47] <BBB> :)
[15:36:47] <jez9999> isn't that a dead OS?
[15:36:51] <mru> DeadOS
[15:40:43] <jez9999> BBB: anyway, the issues are addressed in patch6
[15:45:45] <DonDiego> does anybody know a quick way to grep for non-ascii characters?
[15:46:16] <kshishkov> it should take octal
[15:46:30] <kshishkov> or [^A-Za-z]
[15:47:36] <mru> [^ -~]
[15:47:46] <mru> that gives you 0x20 to 0x7e
[15:47:47] * thresh survived boring corpo-meeting
[15:47:51] <mru> I don't know what 7f is
[15:48:22] <mru> it doesn't print here
[15:55:11] <jez9999> what counts as an ascii character?
[15:55:17] <jez9999> anything below 128?
[15:55:50] <mru> and >= 32
[15:55:56] <mru> <32 are control characters
[15:56:19] <kshishkov> why grep cannot use bitmasks?
[15:57:59] * kshishkov found that grepping with awk sometimes is more convenient and significantly faster
[16:02:06] <jez9999> grep with Perl
[16:02:06] <jez9999> :-)
[16:05:20] <DonDiego> mru: does not work :-/
[16:05:33] <mru> what are you trying to do?
[16:05:33] <KotH> DonDiego: [[:ascii:]] ?
[16:11:39] <Compn> oh DonDiego, i didnt know you were in the middle of exams, i wouldnt have bugged you if i knew ...
[16:12:12] <Compn> s/knew/remembered
[16:12:48] <DonDiego> Compn: np
[16:17:40] <kshishkov> what a ridiculous MPlayer message "Cannot seek backward in linear streams!"
[16:18:03] <mru> socket, pipe?
[16:18:11] <kshishkov> yes
[16:18:24] <mru> of course you can't seek backwards there
[16:18:29] <mru> it's like seeking backwards in time
[16:18:37] <kshishkov> are other streams curvy or non-euclidean?
[16:19:55] <mru> rectangular
[16:20:02] * KotH has seen hyperbolic streams
[16:20:03] <mru> haven't you ever looked inside a file?
[16:20:54] <kshishkov> yes, but that was wraparound
[16:25:30] <CIA-90> ffmpeg: mru * r21881 /trunk/libavcodec/ (h264_loopfilter.c h264.c h264_mvpred.h h264.h h264_direct.c):
[16:25:30] <CIA-90> ffmpeg: H264: use alias-safe macros
[16:25:30] <CIA-90> ffmpeg: This eliminates all aliasing violation warnings in h264 code.
[16:25:30] <CIA-90> ffmpeg: No measurable speed difference with gcc-4.4.3 on i7.
[16:27:27] <mru> Dark_Shikari: ^^
[16:28:06] <CIA-90> ffmpeg: kostya * r21882 /trunk/libavformat/rtmpproto.c: Make RTMP client send bytes read report
[16:28:07] <kshishkov> mru: does that mean we'll have all green on ARMv5?
[16:28:23] <mru> we'll have all green on arm when arm release the next update
[16:28:32] <mru> or if I install the test build they gave me
[16:31:28] <lu_zero> hm
[16:31:49] <lu_zero> irssi seems to be less than perfect for my usage...
[16:32:50] <kshishkov> solution: use something else
[16:32:58] <mru> no, fix it
[16:33:11] <mru> irssi is quite customisable too
[16:33:16] <kshishkov> mru: same can be said about Windows Me
[16:33:27] <mru> in some cases fix == replace
[16:33:40] <mru> in the winme case fix == annihilate
[16:34:54] <kshishkov> well, svn commit -m "fix something" should be ideal description then
[16:37:17] <BBB> Vitor1001, haven't looked at the fft yet, will do hopefully this weekend
[16:37:31] <Vitor1001> BBB: ok, no hurry
[16:37:44] <Vitor1001> do you have an idea of what the other func do?
[16:39:02] <BBB> the bottom one?
[16:39:06] <BBB> it's the inverse of the top one
[16:39:19] <BBB> so most likely it's ifft re/im interleaved back to int[]
[16:39:33] <BBB> I'll test that soon
[16:40:00] <BBB> the functions in com_wmsapf.c don't do much complicated
[16:40:39] <mru> kshishkov: http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-2.6.27/musb-mru-otgfix.diff
[16:42:00] <kshishkov> mru: yes, it was pretty obvious
[16:44:37] <Vitor1001> BBB: I mean the wmsCcsFft_INT()
[16:45:26] * Dark_Shikari sees aliasing patches applied
[16:45:27] <Dark_Shikari> mru: awesome.
[16:45:50] <Dark_Shikari> now we have to do it in other decoders/encoders
[16:47:20] <kshishkov> for example?
[16:47:27] <mru> ls *.c
[16:48:03] <kshishkov> costablegen.c
[16:48:17] <mru> top of the list
[16:49:15] <Dark_Shikari> mru: lol
[17:02:32] <elenril> o/ people
[17:02:46] <elenril> anyone wants to apply nut metadata conv table for me?
[17:06:58] <kshishkov> superdump: can you serve as a patch monkey?
[17:07:09] <superdump> hmm?
[17:07:29] <kshishkov> here's elenril and his nutty patch
[17:07:38] * elenril is nuts
[17:08:00] <elenril> kshishkov: what prevents you from applying it btw? =p
[17:08:21] <kshishkov> elenril: laziness mostly
[17:08:43] <kshishkov> especially effort needed to find your patch and obfuscate your email
[17:09:30] <elenril> more effort than reverse engineering obscure codecs? ;)
[17:09:41] <mru> less fun
[17:09:47] <kshishkov> exactly
[17:17:42] <elenril> so we should switch to git
[17:17:53] <elenril> applying patches will be less effort
[17:18:14] <Kovensky> git am elenril
[17:22:17] <mru> git re codec
[17:23:14] <kshishkov> okay, I retire then
[18:01:57] <mattg> mru: i've added a new directory to FTP at /MPlayer/incoming/mattg_neon_green2/ which you may be interested in. i've supplied raw YUV outputs from the app running on mac, iphone with asm, iphone without asm. (320x242, YUV420P).
[18:02:21] <mattg> green in both iphone cases, not green in the mac case. something strange is going on.
[18:02:38] <mru> mattg: you might want to try latest svn
[18:02:50] <mru> I've fixed some potential alignment problems
[18:03:10] <Dark_Shikari> and aliasing >_>
[18:03:24] <mattg> ah, yes, just spotted you have commited recently. i'll certainly go and check out the new version. thanks! i'll give you feedback (probably tomorrow)
[18:03:35] <mru> Dark_Shikari: aliasing wouldn't be fixed by disabling asm
[18:05:12] <Dark_Shikari> true.
[18:05:16] <Dark_Shikari> In most cases.
[18:06:03] <kshishkov> it should be fixed by disabling compiler optimizations ;)
[18:06:27] <mattg> mru: note that i've actually found that it can't be the asm (apologies for saying that before) as YUV output is exactly the same with and without --disable-asm on iphone
[18:07:02] <mru> hmpf
[18:07:56] <mattg> i'm totally confused by it, but am getting somewhere and tomorrow am going to try new svn trunk and then if it's still broken for me, i'll step through the decoding on both mac & iphone and see where the green is coming from.
[18:24:37] <CIA-90> ffmpeg: stefang * r21883 /trunk/libavcodec/cavs.h:
[18:24:37] <CIA-90> ffmpeg: fix intra prediction modes with inter-MB neighbors,
[18:24:37] <CIA-90> ffmpeg: the old sample clips are in violation of the 2006 spec
[19:03:36] <BBB> [aac @ 0x1044600]channel element 0.0 is not allocated <- is that SBR again?
[19:03:55] <superdump> not necessarily
[19:04:03] <superdump> it's channel configuration stuff
[19:04:05] <superdump> sample?
[19:06:21] <BBB> http://archives.free.net.ph/message/20100203.025553.2fbf395b.en.html
[19:06:29] <BBB> has a link to samples already in incoming/
[19:10:06] <superdump> oh that one
[19:10:44] <superdump> BBB: https://roundup.ffmpeg.org/roundup/ffmpeg/issue1733
[19:15:37] <CIA-90> ffmpeg: mru * r21884 /trunk/configure: Suppress icc warnings about unknown attributes
[19:40:43] <Dark_Shikari> siretart: ping, quick question
[19:44:49] <siretart> Dark_Shikari: you're lucky, it seems umts is working right now
[19:44:59] <Dark_Shikari> quick question about ubuntu releasing and all that
[19:45:04] <siretart> 42
[19:45:45] <Dark_Shikari> lets say that we find some big bug in x264, and lucid's already out
[19:45:49] <Dark_Shikari> can we get that bugfix pushed out?
[19:46:37] <siretart> there is a process for that, so short answer: yes
[19:47:25] <Dark_Shikari> k
[19:47:33] <siretart> btw, my last x264 upload FTBFS on arm, just as you promised :-)
[19:47:40] <Dark_Shikari> ?
[19:47:45] <Dark_Shikari> FTBFS?
[19:47:52] <siretart> fails to build from source
[19:48:02] <Dark_Shikari> doesn't r1442 work?
[19:48:05] <Dark_Shikari> it was supposed to
[19:49:10] <siretart> https://edge.launchpad.net/ubuntu/+source/x264/2:0.85.1442+gitfcf70c-1/+build/1515320
[19:50:15] <Dark_Shikari> common/arm/asm.S:21:20: error: config.h: No such file or directory
[19:50:35] <Dark_Shikari> looks like something in your build environment is borked
[19:50:42] <Dark_Shikari> Yuvi: ?
[19:51:06] <siretart> I can retry the build
[19:51:16] <Dark_Shikari> ./version.sh: line 2: git: command not found
[19:51:22] <Dark_Shikari> er, git isn't installed on the build machine?
[19:51:39] <thresh> why would you need it anyway
[19:51:45] <Dark_Shikari> true, if you're customizing the version
[19:52:03] <Dark_Shikari> siretart: something must be broken, because every DEFINE command in configure writes to config.h
[19:52:11] <Dark_Shikari> so it would be very difficult for configure to succeed and config.h to not exist.
[19:52:29] <thresh> let me see about arm on my test build
[19:52:32] <siretart> a) why does this happen that late in the build process, and b) why only on arm?
[19:52:52] <siretart> either the chroot is f'cked, or x264 :-)
[19:53:38] <siretart> or hardware problems, of course
[19:53:53] <Dark_Shikari> doubtful the last
[19:54:22] <thresh> build seems ok here on latest git
[19:55:52] <thresh> siretart: looks like it's some older version of git checkout
[19:56:12] <thresh> i've had the same problem before last Dark_Shikari's (or whoever did it) push
[19:58:45] <Dark_Shikari> forgot to make distclean?
[20:01:17] <Yuvi> If it's an older x264, asflags didn't look in the right place for config.h
[20:02:17] <Yuvi> Can't download the buildlog on my iPod though so I'm just guessing
[20:04:15] <Yuvi> Btw, ubuntu will have a neon build in addition to the base armv5?
[20:04:32] <Dark_Shikari> yeah, that's a major issue
[20:04:35] <Dark_Shikari> a "base" build is 100% useless
[20:04:38] <Dark_Shikari> far too slow to do anything
[20:04:49] <Dark_Shikari> might as well not include x264 at all if it only has a base build
[20:21:35] * elenril kicks mp4 specs
[20:21:49] <elenril> anyone knows when will bcoudrier return?
[20:48:11] <CIA-90> ffmpeg: stefano * r21885 /trunk/cmdutils.c: (log message trimmed)
[20:48:11] <CIA-90> ffmpeg: FFmpeg is a collective effort so allowing a single name in a banner is
[20:48:11] <CIA-90> ffmpeg: not nice/fair towards the community of developers.
[20:48:11] <CIA-90> ffmpeg: Also this looks like the best way for resolving the debate about which
[20:48:11] <CIA-90> ffmpeg: is the one person name to be put in the banner.
[20:48:12] <CIA-90> ffmpeg: See the thread:
[20:48:13] <CIA-90> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Replace "Fabrice Bellard" with "the FFmpeg developers" in the banner
[21:20:38] * _av500_ tries to keep down the idle offtopic chatter...
[21:20:43] <Dark_Shikari> lol
[21:21:06] * _av500_ fails
[21:21:32] <mru> this channel is like fosdem but without the beer
[21:21:40] <Dark_Shikari> and without the freetards
[21:22:51] <peloverde> The channel needs a video wall
[21:23:11] <_av500_> libaa ftw
[21:24:10] <mru> +---+---+---+
[21:24:10] <mru> |   |   |   |
[21:24:10] <mru> +---+---+---+
[21:24:10] <mru> |   |   |   |
[21:24:10] <mru> +---+---+---+
[21:24:35] <_av500_> -fps 25
[21:25:10] <mru> we used to do that with the chat system they had at uni
[21:26:48] * _av500_ arranges 6 xterms with irrsi in the proper pattern  
[21:38:58] * mru looks at fate
[21:39:10] <mru> looks like the anti-aliasing macros fixed a bunch of failures
[21:39:17] <Dark_Shikari> nicwe
[21:39:22] <Dark_Shikari> >antialiasing
[21:39:24] <Dark_Shikari> hahahaha
[21:39:33] <Dark_Shikari> so, what method do you prefer
[21:39:37] <Dark_Shikari> supersampling?  multisampling?
[21:39:47] <astrange> what was the difference?
[21:40:06] <Dark_Shikari> en.wikipedia.org
[21:49:48] <CIA-90> libswscale: stefano * r30641 /trunk/libswscale/utils.c:
[21:49:48] <CIA-90> libswscale: Merge two if conditions, allow to decrese the level of indentation of
[21:49:48] <CIA-90> libswscale: the block.
[21:49:48] <CIA-90> libswscale: stefano * r30642 /trunk/libswscale/utils.c: Vertically align a list of comparisons in sws_getCachedContext().
[21:49:50] <CIA-90> libswscale: stefano * r30643 /trunk/libswscale/utils.c: Reindent and fix brace placement.
[21:54:13] <siretart> Dark_Shikari: I'm looking again at the buildlog for arm. AFAIUI, the failing gcc command line lacks a '-I.' flag. but that gcc call looks funky anyway
[21:55:52] * janneg has started rendering BBB in 3640x2048
[21:56:08] <Dark_Shikari> lol
[21:56:10] <Dark_Shikari> this might take a while
[21:56:31] <peloverde> the person or the blender movie?
[21:56:43] <_av500_> lol
[21:57:07] <Dark_Shikari> how about elephant's dream
[21:57:14] <_av500_> janneg: u got 50k render hours where?
[21:58:29] <mru> janneg: you've got until june...
[21:58:52] <_av500_> june this year
[22:00:06] <_av500_> janneg: just the wireframe does not count....
[22:00:28] <janneg> just wanted to test how long a frame takes
[22:01:31] <janneg> and ten days on a quadcore are already 1000 cpu hours
[22:02:06] <mru> so how long does a frame take?
[22:02:35] <_av500_> how can he know, he only started it yesterday
[22:03:22] <janneg> no frame rendered yet. only a couple of minutes until blender gets killed
[22:04:03] <mru> why does it get killed?
[22:04:26] <_av500_> out of pixels
[22:05:16] <janneg> out of memory
[22:05:33] <_av500_> -EAREYOUNUTS
[22:06:36] <Kovensky> -EFFFFFFFU
[22:06:42] <mru> where are the source files?
[22:06:44] <janneg> [114976.339948] Killed process 8126 (blender) vsz:3449520kB, anon-rss:2437324kB, file-rss:212kB
[22:07:04] <Dark_Shikari> how much memory does a 4k render need
[22:07:22] <janneg> apparently more than 3.5G
[22:07:24] <_av500_> janneg: so how many kills in 10days on the quadcore?
[22:07:35] <Dark_Shikari> hmm, I have a 6 gig I can try on
[22:07:37] <mru> well, I have 12G
[22:07:58] <janneg> mru: torrent, I'll seed with 10mbit
[22:08:56] * _av500_ writes letter to boss, explaining the need for 24G 
[22:09:50] <mru> and where is the torrent file?
[22:10:04] <janneg> http://download.blender.org/peach/bigbuckbunny_production.torrent
[22:10:04] <mru> the one on bbb.org/download tries to use piratebay tracker
[22:10:27] <mru> that's the one I'm trying
[22:10:29] <Dark_Shikari> where's the torrent file for elephant's dream?
[22:10:46] <mru> now it's trying dht
[22:15:15] <janneg> http://93.220.64.28
[22:15:19] <janneg> mru: ^^^
[22:15:35] <mru> it's downloading now
[22:28:45] <peloverde> I wonder If I will land SBR before next Thursday when Google will release VP8 and make FFmpeg completely irrelevant (or so says the prevailing opinion on the Internet)
[22:29:02] <Dark_Shikari> lol vp8
[22:29:30] <Dark_Shikari> there was an on2 shareholder on doom9 complaining about how the corporate leadership cheated them out of their money
[22:29:37] <Dark_Shikari> and used procedural BS to get votes for the merger
[22:29:45] <Dark_Shikari> I'm laughing at the shareholders who thought on2 was worth more than 100m
[22:29:59] <_av500_> mA, mV?
[22:33:19] <BBB> peloverde, vp8 makes ffmpeg irrelevant?
[22:33:19] <janneg> wtf: blender needs even for 640x512 3G
[22:33:26] <BBB> peloverde, are you sure you didn't confuse ffmpeg and theora there?
[22:33:37] <BBB> peloverde, otherwise I'm terribly confused
[22:33:54] <peloverde> BBB: that's what people all over the internet are saying
[22:34:25] <peloverde> remember fedora wont even ship an xiph only libffmpegsumo for chromium
[22:34:26] <BBB> peloverde, people around me - scientists - all think we're going to decode all genomic diseases and grant us eternal life
[22:34:53] <BBB> peloverde, fedora is irrelevant
[22:35:04] <BBB> it has a desktop market share that is a hundredfold, if not thousandfold, below that of apple
[22:35:22] <BBB> and apple is less than two handfingers in percentunits
[22:35:25] <peloverde> FFmpeg seems to be just as hated as the MPEG codecs
[22:35:53] <BBB> you listen too much to fanboys, zealots and other useless slashdot commenters
[22:35:55] <janneg> of course, it has mpeg in its name
[22:36:08] <BBB> you need to retract yourself from reading slashdot and such
[22:36:32] <BBB> and convert to interacting with real people, e.g. bankers/traders, business owners, consultants, contracters, etc.
[22:36:46] <BBB> they provide money and business
[22:36:50] <BBB> not slashdot crowd
[22:36:52] <microchip_> so they can steal all your money :p
[22:37:07] <BBB> if I get ~1% of their money, I'll be terribly happy
[22:37:26] <BBB> 1% of the money of the average slashdot loser is not very much, on the other hand
[22:37:32] <peloverde> If you just follow the money Xiph managed to pull in $100K from Mozilla, On2 managed to pull in way too much from Google
[22:38:16] <BBB> and you think ffmpeg won't be funded by google?
[22:38:36] <Dark_Shikari> google's official policy is to refuse to admit they even use ffmpeg
[22:38:48] <BBB> you seem a little down... do you live near new york? I'll offer you some free beer and better liquors
[22:38:58] <Dark_Shikari> but yeah, peloverde, stop worrying so much
[22:39:01] <peloverde> Dark_Shikari, lies
[22:39:03] <BBB> Dark_Shikari, they admit using it in chrome
[22:39:07] <BBB> or chromium
[22:39:09] <Dark_Shikari> BBB: not for their backend though
[22:39:14] <Dark_Shikari> for chrome obviously, they distribute it
[22:39:16] <BBB> youtube?
[22:39:24] <peloverde> for chrome they admit it as you said
[22:39:41] <Dark_Shikari> yes e.g. youtube
[22:39:45] <Dark_Shikari> btw
[22:39:50] <Dark_Shikari> vimeo, hulu, facebook, and yotuube all use x264 now
[22:39:53] <Dark_Shikari> let's see if we can get the entire top 10
[22:39:55] <BBB> we have no contact in their youtube team
[22:40:03] <Dark_Shikari> yes we do.  Pascal
[22:40:05] <BBB> get a contact
[22:40:06] <BBB> ..
[22:40:07] <BBB> profit
[22:43:06] <BBB> ask him if he uses ffmpeg :)
[22:44:59] <Dark_Shikari> they do
[22:45:01] <Dark_Shikari> but they can't say it publicly
[22:45:04] <Dark_Shikari> for some weird reason
[22:45:45] <BBB> blah
[22:45:54] <BBB> I barely care
[22:46:07] <BBB> peloverde, don't forget that vlc is downloaded enough times to make fedora irrelevant
[22:46:21] <BBB> peloverde, point being; don't listen to the slashdot crowd
[22:46:51] <peloverde> The VLC thing is kind of funny when VLC is so loved yet we are so hated
[22:47:18] <Dark_Shikari> VLC is more popular than all linux distros combined
[22:47:54] <astrange> if they admitted youtube could process proprietary game codecs i guess they think it'd lead to problems?
[22:48:13] <Dark_Shikari> well so can facebook
[22:48:14] <Dark_Shikari> and they admit it
[22:48:16] <Dark_Shikari> and so can vimeo
[22:48:18] <Dark_Shikari> and so can hulu
[22:48:24] <BBB> peloverde, why do you think we're hated?
[22:48:28] <BBB> peloverde, I don't quite understand
[22:49:04] <Dark_Shikari> BBB: because he listens to a very very small vocal minority
[22:49:06] <peloverde> All the comments on a recent Ars story
[22:49:08] <Dark_Shikari> which is a minority of a minority of a minority
[22:49:37] <Dark_Shikari> freetards are a minority of people who care about free software
[22:49:46] <Dark_Shikari> people who care about free software are a minority of linux/osx/etc users
[22:49:52] <Dark_Shikari> linux/osx users are a minority of computer users
[22:50:17] <peloverde> A huge portion of the windows firefox users are drinking the coolaid now
[22:50:34] <Dark_Shikari> "huge portion"?
[22:50:44] <BBB> coolaid?
[22:50:46] <Dark_Shikari> a "huge portion" of windows firefox users are grandmas who don't know what html is
[22:50:59] * BBB smiles
[22:51:15] <BBB> peloverde, if you're ever in new york, I'll get you free beers
[22:51:25] <peloverde> BBB, thanks
[22:57:36] <peloverde> I guess I'm just sick of hearing nutty shit like a high profile mozilla engineer claiming that even suggesting people use ffmpeg2theora is contributory infringement
[22:58:12] <Dark_Shikari> lol
[23:07:44] <CIA-90> ffmpeg: alexc * r21886 /trunk/libavcodec/aac.c: Add some AAC buffer overread checks.
[23:15:31] <BBB> peloverde, I'm sorry you take it so badly, but from the number of people saying thanks every time we RE a new codec, I think we're doing allright
[23:17:57] <peloverde> that's good to hear
[23:22:06] <iive> i'm read /. daily, i haven't noticed tendency in hating ffmpeg there. But then again, i don't read comments with score -1 troll.
[23:25:22] <iive> janneg: do you have idea why blender needs so much memory?
[23:28:33] <mru> so... how do render it?
[23:29:58] <iive> pixel by pixel :)
[23:30:24] <janneg> blender scenes/01_intro/01.blend
[23:30:41] <janneg> and F12 to render the current frame
[23:34:09] <janneg> or blender -b scenes/01_intro/01.blend -f x to render frame x from command line
[23:38:41] <CIA-90> ffmpeg: michael * r21887 /trunk/libavcodec/h264_cabac.c:
[23:38:41] <CIA-90> ffmpeg: Move abs() from decode_cabac_mb_mvd() to the code that writes mvd_cache.
[23:38:41] <CIA-90> ffmpeg: 4-8 cycles faster
[23:40:45] <Dark_Shikari> ... fucking good idea michael
[23:40:55] * Dark_Shikari thought of that one just the other day...
[23:42:34] <mru> 3GB
[23:42:40] <mru> 3.8
[23:43:19] <mru> seems to have leveled out
[23:43:29] <mru> err
[23:43:32] <mru> 4.1
[23:43:43] <mru> 4.5
[23:43:49] <mru> damn, this thing is hungry
[23:43:55] <mru> 4
[23:43:55] <mru> 5
[23:44:46] <mru> and it's using 750% cpu
[23:48:23] <mru> done
[23:48:29] <mru> peaked at 5.2GB
[23:48:48] <Dark_Shikari> but you have 12GB, so you laugh
[23:53:49] <Dark_Shikari> ok, quick question, what's the best way to do a SWAR absolute value?
[23:53:57] <Dark_Shikari> I know that you can do one easily for the case of (x<<16) + y
[23:54:07] <Dark_Shikari> but that's a bit different than the case of two 16-bit values packed into a 32-bit
[23:54:12] <Dark_Shikari> due to sign
[23:54:29] <Dark_Shikari> and I need the latter, because I want to do an SWAR absolute value during a packed store
[23:55:31] <janneg> commandline rendering seems to be more stable
[23:57:59] <mru> Dark_Shikari: trivial on arm...
[23:58:06] <mru> 3 insns
[23:58:16] <Dark_Shikari> in C
[23:58:22] <Dark_Shikari> i.e. using machine-independent ops
[23:58:40] <mru> if you're going to be doing this a lot you should probably have asm for it
[23:58:47] <Dark_Shikari> no, just in one place
[23:59:43] <Dark_Shikari> I need to turn pack16to32(x,y) into pack16to32(abs(x),abs(y))
[23:59:49] <Dark_Shikari> preferably faster than the latter.