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

[irc at mansr.com]

[00:00:09] <barque> aww
[00:00:24] <barque> well I wrote a patch for targaenc, just wondering if he got it
[00:00:45] <barque> I also signed up on the devel mailing list, just haven't received a confirmation email yet :(
[00:16:15] <Compn> strange
[00:16:19] <Compn> should get one immediately
[00:16:36] <Compn> maybe mru can check it for you barque , if you tell him your mail addy
[02:15:53] <Yuvie> :/ the bilinear filter requires truncation to 8 bits between horizontal and vertical interpolation
[02:16:25] <Dark_Shikari> WHAT?
[02:18:04] <BBB> Yuvie: I've had a problem today where output of all test vectors is completely random
[02:18:11] <BBB> they worked for me a few days ago
[02:18:17] <BBB> I didn't change anything in the code
[02:18:22] <BBB> do they work for you?
[02:18:30] <BBB> I think I broke something
[02:18:51] <Yuvie> BBB: yeah, everything except 3,4,7
[02:18:58] <BBB> 2,3,7?
[02:18:59] <Yuvie> though I just pushed some fixes for stuff
[02:19:02] <BBB> 2 and 3 were broken here
[02:19:07] <BBB> I was working on 2 :)
[02:19:14] <Yuvie> ah, I fixed 2 today
[02:19:24] <BBB> ah great
[02:19:34] <Yuvie> everything should be bitexact now except for stuff that uses the bilinear filter
[02:19:35] <BBB> was it in mb coeff coding?
[02:20:05] <BBB> oh, whoa, you're fast
[02:20:25] <Yuvie> nope, it was the reference stuff
[02:20:46] <Yuvie> the rules for update golden/altref/last were abit weird
[02:20:56] <BBB> sorry, that was my code :(
[02:21:14] <Yuvie> eh, it took me 3 tries :)
[02:22:02] <Yuvie> e.g. if altref and golden are supposed to be swapped
[02:22:09] <Yuvie> libvpx actuall just sets them both to the golden ref
[02:22:18] <BBB> ah, yes, I didn't test that :)
[02:22:34] <BBB> hmm...
[02:23:16] <Yuvie> and libvpx has some weird contortions if update_last is set
[02:23:28] <Yuvie> since they swap pointers for the last ref, but do a frame copy for golden/altref
[02:23:58] <Dark_Shikari> 10:22 <@Yuvie> e.g. if altref and golden are supposed to be swapped
[02:23:58] <Dark_Shikari> 10:22 <@Yuvie> libvpx actuall just sets them both to the golden ref
[02:24:01] <Dark_Shikari> is that a bug in libvpx?
[02:24:05] <BBB> no
[02:24:06] <Dark_Shikari> or is that intended?
[02:24:14] <BBB> whatever libvpx does is spec and intended
[02:24:17] <Dark_Shikari> lol
[02:24:27] <BBB> the spec says so
[02:24:37] <Dark_Shikari> wait, does the spec actually say that's supposed to happen?
[02:24:48] <BBB> Yuvie: oh right, I never thought of that, but I guess golden should indeed be copied
[02:24:53] <Yuvie> the spec is rather vague on how referenes are updated
[02:25:01] <Yuvie> BBB: no reason to
[02:25:19] <BBB> oh right we update cur, not last
[02:25:19] <BBB> ok
[02:25:35] <BBB> I see you rewrote my weird reference "handling" code
[02:25:41] <BBB> looks a lot simpler now
[02:26:04] <Yuvie> cause the weird logic moved to 2 other places ;)
[02:26:34] <BBB> ah
[02:26:38] <BBB> ref_to_update()
[02:26:39] <BBB> a new function
[02:26:41] <BBB> smart
[02:26:49] <BBB> much better
[02:27:14] <BBB> ok, I'm gonna look at this tonight
[02:28:02] * BBB feels newbie
[02:28:40] <BBB> do you want to make it bitexact or is the current h264-style filter ok?
[02:28:53] <BBB> (or I can try making it biteaxct, but then it'll take twice as long)
[02:28:56] <Yuvie> oh, I already replaced that with the normal 6tap filter
[02:29:44] <BBB> omg you are fast indeed
[02:29:46] <BBB> I just saw it
[02:30:01] <BBB> so when is the bilinear filter used then?
[02:30:10] <Yuvie> sub_version 1,2,3
[02:30:15] <BBB> ok
[02:30:58] <Yuvie> http://pastie.org/1003296 <- that should work for it if it weren't for the stupid truncation
[02:31:32] <Yuvie> for bilinear
[02:35:11] <BBB> nice work
[02:37:32] <BBB> your subversion checks that it's != 0 in that patch
[02:37:41] <BBB> but you said it's only bilineair for 1, 2 and 3
[02:37:44] <BBB> do the others not exist?
[02:37:53] <Yuvie> yep, 4+ aren't defined
[02:38:08] <Yuvie> didn't feel like leaving them out of the bilinear fun though
[02:39:41] <BBB> impressive work
[02:39:46] <BBB> sorry I didn't get more done :(
[02:39:49] <Yuvie> (what it should do is copy one or the other to VP8Context at frame init instead of the branch, but eh)
[02:40:12] <BBB> optimization can always be done afterwards
[02:40:21] <BBB> I like the glib approach, which people here might not like
[02:40:33] <BBB> 1) get it to work, commit
[02:40:35] <BBB> 2) optimize
[02:40:40] <BBB> (and keep it working)
[02:41:52] <BBB> so is the truncation that you're talking about the truncation for subversion==3? because vp8_mc() already handles that
[02:42:08] <astrange> is glib especially optimized?
[02:42:38] <Yuvie> no, truncation in the bilinear filter
[02:42:38] <Yuvie> e.g. what that does is (A*p0 + B*p1 + C*p2 + D*p3 + 32) >> 6
[02:42:39] <BBB> some parts a little
[02:43:18] <BBB> isn't that the same as what the sixtap filter does?
[02:43:30] <Yuvie> what libvpx does is (E*(A*p0 + B*p1 + 128) >> 7) + F*((C*p2 + D*p3 +128)>>7) + 128) >> 7
[02:43:50] <BBB> why 128
[02:44:08] <Yuvie> 128: to match the 6 tap
[02:44:17] <BBB> 6tap does 64
[02:44:28] <BBB> >>7 rounding should use 64
[02:44:34] <Yuvie> oh right
[02:44:38] <Yuvie> 64 then
[02:44:46] <Yuvie> they #define 128 but always use it /2
[02:46:01] <BBB> I wonder what E and F are in this scheme
[02:46:28] <Yuvie> actually ABCD probably aren't quite the same either
[02:46:59] <Yuvie> but basically, libvpx does horizontal bilinear filter, truncates it to 8 bit and saves it, then vertical bilinear filter
[02:47:39] <Yuvie> the truncation is the killer, because bilinear is simple enough to do vertical and horizontal at the same time
[02:47:45] <Yuvie> which is what h264_chroma_mc does
[02:48:08] <Yuvie> so you need more operations to match libvpx
[02:50:39] <BBB> I guess now is a great time for me to learn asm
[02:50:50] <BBB> maybe I can write a few DSP functions for vp8_*()
[02:51:31] <BBB> anyway, wife is calling, bedtime
[02:51:47] <BBB> thanks for fixing the ref streams that I guess my code broke ;)
[04:25:59] <kshishkov> barque: no, got nothing from you
[04:27:16] <barque> oh hi kshishkov!
[04:27:27] <kshishkov> hi
[04:28:15] <barque> take a look: http://pastebin.com/t9C1HyNQ
[04:28:20] <barque> kaktila? :]
[04:28:26] <barque> kharasho? :D
[04:28:44] <barque> the patch adds 32 bit BGRA support for targa
[04:28:46] <kshishkov> yes :P
[04:29:02] <barque> ^^ that's as much Russian I know :D
[04:29:24] <barque> Pagoda Kharasho! =D
[04:30:03] <kshishkov> just remember that in Russian it's usually written not in the same way as read
[04:30:13] <barque> I'm absolutely sure XD
[04:30:20] <barque> I have no idea how the alphabet works
[04:30:21] <barque> :D
[04:30:59] <kshishkov> it's not only alphabet - some letters are not read at all, some are read as different ones
[04:31:29] <barque> wow
[04:31:37] <barque> anyway, I'm drunk as all hell
[04:31:45] <barque> tomorrow's my convocation
[04:31:55] <kshishkov> okay, you _know_ Russian well :)
[04:32:01] <barque> I'm getting my Bachelor's of Engineering in Computer Engineering
[04:32:04] <barque> :D
[04:32:09] <barque> so I'm gonna pass out
[04:32:43] <barque> Dobre Noch kshishkov! =D
[04:33:05] <kshishkov> just for the record - patch is not OK and may not work on BE but I'll cook something based on it
[04:33:10] <kshishkov> g'night
[04:33:14] <barque> oh ok
[04:33:17] <barque> good night :D
[04:37:30] <pross-au> cool barque
[04:55:48] <pJok> god morgon, kshishkov :)
[04:58:34] <kshishkov> god morgon
[05:26:17] <peloverde> How does adding "restrict" make my code slower?
[05:27:27] <Dark_Shikari> it rerolls the gcc random code generator
[05:27:52] <peloverde> I hate gcc
[05:40:08] <pross-au> peloverde: alternative?
[05:41:35] <peloverde> It was on the PS filtering functions, I was hoping for an easy small gain
[05:41:50] <peloverde> They probably need SIMD
[05:45:09] <astrange> better optimization = more register pressure = maybe bad on x86
[05:45:23] <astrange> do asm diffs to check what it does
[05:46:58] <Dark_Shikari> usually it's just bad luck for something like that
[05:47:05] <Dark_Shikari> e.g. a suboptimality, by sheer luck, generated better code than normal gcc
[05:57:22] <Dark_Shikari> kshishkov: did you get my message about the "funny position"?
[05:58:13] <peloverde> Honestly at this juncture I don't think it's worth wasting that much time on, important architectures will probably get custom ASM
[06:00:48] <Dark_Shikari> agreed
[06:46:15] <Tjoppen> morning
[07:06:49] <CIA-92> ffmpeg: ramiro * r23597 /trunk/libavformat/output-example.c: output-example: Set sample_fmt to SAMPLE_FMT_S16.
[07:12:15] <av500> hi guys
[07:49:34] <KotH> ohayou!
[07:49:37] <KotH> kshishkov: in what sense
[08:13:30] <CIA-92> ffmpeg: mstorsjo * r23598 /trunk/libavformat/rtsp.c:
[08:13:30] <CIA-92> ffmpeg: Reindent
[08:13:30] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:21:36] <KotH> salut
[08:24:49] <CIA-92> ffmpeg: mstorsjo * r23599 /trunk/libavformat/rtsp.c:
[08:24:49] <CIA-92> ffmpeg: RTSP: Shrink SDP fmtp parsing buffer size
[08:24:49] <CIA-92> ffmpeg: Since the parsing of Vorbis/Theora fmtp headers is handled by the
[08:24:49] <CIA-92> ffmpeg: parse_sdp_a_line function pointer now, the buffer in sdp_parse_fmtp
[08:24:49] <CIA-92> ffmpeg: doesn't need to be this large any longer.
[08:24:50] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:36:28] <kshishkov> Dark_Shikari: I did, and what excuse they invented for different rounding in horizontal and vertical cases?
[08:36:55] <Dark_Shikari> dunno, if you write it specifically, I can ask him
[08:37:57] <kshishkov> Dark_Shikari: lavc/rv40dsp.c table rv40_bias lists rounding values for MC funcs, look at it
[08:42:20] <Dark_Shikari> sent
[08:42:30] <Dark_Shikari> My guess: it's to allow qpel to be used as a method to pick between rounding biases
[08:42:33] <Dark_Shikari> we _know_ this is useful
[08:43:18] <Dark_Shikari> (i.e. in areas where the subpel position doesn't really matter)
[08:48:33] <kshishkov> well, subpel doesn't really matter in RV, it's still crap
[08:51:44] <Dark_Shikari> even crap things can have good ideas
[08:52:40] <CIA-92> ffmpeg: mstorsjo * r23600 /trunk/libavutil/log.c: Fix compilation on windows CE
[08:55:14] * kshishkov waits for x264 to adapt ideas from VP8
[08:55:28] <Dark_Shikari> their run-based quant bias thing is cool
[08:56:00] <av500> yay, taint x264 with vp8 patents :)
[08:56:27] <Dark_Shikari> on2 has basically no patents
[08:56:46] * av500 understands the generous patent grant now :)
[08:57:04] * av500 grants ALL his video coding patents to everybody
[08:57:07] <Dark_Shikari> they have a few, but not enough to cover every last little detail
[08:57:32] <lu_zero> good morning
[08:57:40] * kshishkov mutually grants all his video coding patents to av500, including the same patented technologies
[08:58:01] <av500> lu_zero: err, didnt we forget some head hitting to be performed at linuxtag?
[09:00:23] <kshishkov> av500: you should've done that by yourself
[09:00:38] <lu_zero> av500: sadly, indeed =)
[09:00:40] <av500> yes, as said, I forgot
[09:02:14] <kshishkov> BTW, since you own The Beast you should have your nick changed to av666
[09:04:45] <KotH> apropos the beast... are there any pics? vids?
[09:04:55] <kshishkov> there are
[09:05:03] <av500> http://www.youtube.com/watch?v=xsqkVowgHuI
[09:05:35] <superdump> does anyone in the UK want to buy a core i7 920, noctua tower cooler, 3x2G DDR3, motherboard, Antec P183 case, Corsair 650W PSU, dvd-rw and an old nvidia 7800GT?
[09:06:21] <superdump> oh and a hauppauge nova-t dual tuner pci card
[09:06:49] <pross-au> Impressive
[09:07:36] <pross-au> Also as much as the 'Converting Videos Howto - FFMPEG' video
[09:07:49] <av500> :)
[09:10:53] <CIA-92> ffmpeg: mstorsjo * r23601 /trunk/libavformat/ (rtsp.c udp.c rtsp.h): Cosmetics: Change connexion to connection in code comments
[09:13:10] <pross-au> av500: did you use some magic sauce to sync the videos?
[09:13:54] <av500> yes
[09:13:56] <av500> mru did
[09:14:41] <kshishkov> USB actually :)
[09:14:51] <av500> http://git.mansr.com/?p=omapfbplay;a=blob;f=netsync.c;
[09:16:01] <pross-au> Nice
[09:16:20] <barque> gooood mornin'
[09:16:40] <kshishkov> as you say
[09:16:52] <barque> dobre den shishkov! =D
[09:16:54] <KotH> kshishkov: isnt it nice and sunny where you are?
[09:17:01] <kshishkov> KotH: it is
[09:17:10] <barque> shishkov, I forgot to ask you, what was the problem with the code btw? :D
[09:17:15] <KotH> kshishkov: isn't it than a wonderfull morning?
[09:17:27] <barque> it worked on this side
[09:17:36] <kshishkov> KotH: it is. Still not Swiss morning though :P
[09:17:38] <barque> I tried to keep it as non-evasive as possible
[09:17:45] <barque> just basically 3 lines
[09:17:51] <kshishkov> KotH: http://en.wikipedia.org/wiki/Basel_Badischer_Bahnhof
[09:18:16] <barque> did you mean BeOS by BE ?
[09:18:28] <kshishkov> barque: two things - changing first comment was wrong since it's non-alpha and is used so for otehr formats
[09:18:47] <barque> oh of course
[09:18:49] <barque> right
[09:18:54] <barque> it's attribute after all :]
[09:18:58] <KotH> kshishkov: you're in basel?
[09:18:59] <kshishkov> barque: and second - I'm not sure it will be the same RGB on big-endian (BE) systems
[09:19:06] <barque> oh it's always BGRA
[09:19:15] <barque> that's a guarantee
[09:19:17] <barque> spec wise
[09:19:29] <barque> the arch must be very careful in loading
[09:19:30] <kshishkov> KotH: no, that's just to demonstrate there are some good places not belonging to .ch
[09:19:46] <KotH> kshishkov: hmm..
[09:20:05] <KotH> kshishkov: i think, you just want to tell me, that no matter where you move, you'd still like to be in .ch?
[09:20:18] <barque> oh I noticed you guys also talking about the restrict keyword crapping up on x86
[09:20:22] <barque> in the logs
[09:20:32] <barque> that's interesting because x86-32 has very small register count
[09:20:54] <barque> and that should be a wise deduction
[09:21:02] <barque> however x86-64 has a large register file
[09:21:08] <barque> thus restrict must do good there
[09:21:22] <kshishkov> barque: no, I think you should use PIX_FMT_RGB32 since on other-endian systems order for R,G,B and A may be swapped otherwise. I need to test that too
[09:21:41] <kshishkov> KotH: yes with s/.ch/.se/
[09:21:49] <enkidu> how can i look into ffserver to see, what is it doing and why it is so loaded?
[09:21:55] <barque> well just saying kshishkov, I have yet to see RGBA(32) on any Targa format
[09:22:17] <barque> specifically speaking the spec says (oddly enough) the order ends up B,G,R, then A
[09:22:56] <barque> cause usually it's RGBA on Graphics hardware (and this thing was devised in ancient times where dragons existed) so they somehow decided to do BGRA :D
[09:23:10] <kshishkov> still, replacing PIX_FMT_BGRA with PIX_FMT_RGB32 should make no change for you and produce the same file on big-endian systems too
[09:23:29] <KotH> kshishkov: .se is too cold for me.... but you might be used to sibirian winters, so that should be quite ok for you ;)
[09:23:54] <barque> sure, but make very very sure (as you probably will) that content on the hardware coming from AVFrame is at least accessed as BGRA
[09:24:13] <barque> and ... thanks for all the hard work :D
[09:24:20] <barque> I used FFmpeg in my bachelor's thesis
[09:24:26] <enkidu> okay
[09:24:33] <barque> client side a/v decoder... it was hella awesome
[09:24:46] <KotH> barque: then you are obliged to give us your first born
[09:24:48] <barque> the result was being streamed rt to embedded clients
[09:24:50] <barque> :D
[09:24:58] <kshishkov> KotH: never been that far in Russia and don't want to. But .ua climate is continental
[09:25:02] <barque> I credited you guys so much :D
[09:25:09] <enkidu> here, in Poland, there is early summer and temperatures lower than in RSA in winter=
[09:25:17] <KotH> barque: otherwise we'll take your imortal soul and sell it on a flee market
[09:25:22] <barque> hehehe
[09:27:29] <KotH> wtf... a list handling with O(n^2+2n) and people ask themselves why that shit is so slow when the list grows over 100k entries?
[09:27:39] <barque> lol
[09:27:47] <barque> who's running an algo like that?
[09:28:02] <KotH> (not to mention that each step costs a few us!)
[09:28:05] <barque> if I ever do anything O(n^2) I'd be damned if I didn't prune it to O(nlogn)
[09:29:10] <KotH> barque: oh, i'm quite sure the guy who wrote it didnt realize it was o(n^2), as the first function is O(n) (loop over all elements) which calls another function that is O(n) too
[09:30:00] <Dark_Shikari> for( int i = 0; i < strlen...
[09:30:02] <KotH> and i wouldnt be surprised, if something like this happened elsewhere too, with more intermediate steps... leading to O(n^3) or even O(n^4)
[09:31:11] <KotH> but best i've seen sofar is: each element in the data structure is 1kB, because the name can be at most 1000 characters long... i guess i dont have to mention that most of the names are <100 characters
[09:31:55] <KotH> which results in the whole system barfing when going over 500k elements
[09:32:24] <barque> actually
[09:32:27] <barque> I just thought of something
[09:32:47] <barque> using restrict on x86-32 is nothing but plain wrong
[09:33:17] <barque> 1. low register count 2. few load-store units 3. tomasulo
[09:33:40] <Dark_Shikari> not quite.
[09:33:47] <Dark_Shikari> there are still places where aliasing beats the shit out of you
[09:33:56] <Dark_Shikari> I develop exclusively on x86_32 and I've found tons of places aliasing hurts
[09:34:07] <Dark_Shikari> Of course, restrict hardly solves any of them.
[09:34:11] <barque> lol what's the point when you have only 2 loads and 2 stores on the functional unit?
[09:34:15] <av500> KotH: wrt tomasulo, I got that book...
[09:34:17] <Dark_Shikari> huh?
[09:34:25] <Dark_Shikari> how does restrict relate to load/store units?
[09:34:29] <Dark_Shikari> other than perhaps reducing the load on them?
[09:34:42] <barque> I mean the gains seems to be ordering so that you make the most use
[09:34:45] <Dark_Shikari> um... no
[09:34:58] <barque> because store in series independent locations
[09:35:00] <Dark_Shikari> here's a simple example
[09:35:10] <Dark_Shikari> a->b[x] = c;
[09:35:17] <Dark_Shikari> a->b[x+1] = d;
[09:35:28] <Dark_Shikari> How many loads from memory are performed in those two ops?
[09:35:34] <av500> 42?
[09:35:34] <barque> two ?
[09:35:36] <Dark_Shikari> Assuming a, c, and d are in registers
[09:35:39] <barque> or rather more
[09:35:39] <Dark_Shikari> and x
[09:35:41] <KotH> av500: that book?
[09:35:43] <barque> 4
[09:35:53] <Dark_Shikari> Maximum possible: 4
[09:35:58] <barque> well depends on register count
[09:35:58] <Dark_Shikari> What it should be: 2
[09:36:10] <Dark_Shikari> What the compiler will do, even if you have 1000 registers: 4
[09:36:18] <barque> sure
[09:36:20] <Dark_Shikari> Because it doesn't know that a->b[x] doesn't alias a->b
[09:36:34] <Dark_Shikari> solution:
[09:36:40] <Dark_Shikari> someptr *e = a->b
[09:36:42] <Dark_Shikari> e[x] = c;
[09:36:44] <barque> right
[09:36:45] <Dark_Shikari> e[x+1] = d;
[09:36:50] <barque> restrict
[09:36:54] <Dark_Shikari> This helps no matter how many registers you have.
[09:37:01] <barque> suuure but that's so small :D
[09:37:03] <barque> I'm saying
[09:37:12] <barque> make that [x] to [x+400]
[09:37:13] <barque>  :D
[09:37:31] <barque> store , store ,.... stall...... okay,store ,store .... stall ....
[09:37:47] <barque> ad infinitum
[09:37:56] <Dark_Shikari> sure ,it's small in a small example
[09:38:04] <Dark_Shikari> in a big function, like x264_macroblock_cache_load, it's 100 redundant instructions
[09:38:27] <barque> well now that should be looked at carefully
[09:38:46] <barque> but still, it doesn't compare up to what you could do with a 100 load store units
[09:38:54] <Dark_Shikari> 100 load store units would be basically useless
[09:38:59] <Dark_Shikari> and no real chip has that many.
[09:39:04] <Dark_Shikari> and in that space, you could put 20 more cores.
[09:39:12] <barque> and a very fastly pipelined arch with not much hardware to bother you
[09:39:14] <Dark_Shikari> also, according to intel, increasing the load bandwidth from L1 would increase the latency
[09:39:42] <barque> yeah I guess
[09:39:48] <Dark_Shikari> and intel likes their 3 cycle L1 latency
[09:40:09] <barque> what we need is faster cycles :D
[09:40:12] <barque> I just kid you
[09:40:21] <barque> but come to think of it
[09:40:23] <barque> that's not a bad idea
[09:40:55] <barque> but seriously though... let's say not 100 load stores... just one, pipelined in a RISC arch
[09:41:03] <barque> beats the hell out of using this on x86-32
[09:41:24] <Dark_Shikari> why?
[09:41:37] <barque> because they can all just go in the pipeline one by one
[09:41:45] <Dark_Shikari> in a perfect world
[09:41:48] <barque> and the arch should probably be simple enough to not stall anything
[09:42:02] * kshishkov looks at MIPS
[09:42:02] <Dark_Shikari> in the real world we have tons of load-bound functions
[09:42:08] <Dark_Shikari> Using up 30% of encoding time.
[09:42:11] <barque> so in 'theory' you probably get ~1 CPI
[09:42:15] <KotH> barque: have you read hennessy&paterson?
[09:42:21] <barque> KotH, I have it
[09:42:24] <barque> 3rd and 4th ed
[09:42:28] <KotH> barque: if not, it's now the time before you make a fool out of yourself
[09:42:45] <barque> we had to study it this semester
[09:43:01] <barque> KotH, what is it you object to/
[09:43:03] <barque> ?*
[09:43:18] <KotH> i'm not asking whether you've studied it, but whether you've _read_ it.. _completely_
[09:43:29] <Dark_Shikari> barque: one clock per instruction -- amazing, welcome to 1985
[09:43:29] <barque> well what is it you exactly object to?
[09:43:40] <Dark_Shikari> I like to have 0.5 cpi or less ;)
[09:43:55] <KotH> barque: inconsistencies and false assumptions about modern architectures and their problems
[09:44:01] <barque> well with today's fastened functional units sure
[09:44:09] <Dark_Shikari> and what KotH said
[09:44:09] <barque> KotH, I'm not making any assumptions
[09:44:23] <barque> of course things have changed a great deal
[09:44:26] <av500> KotH: yes, that book :)
[09:44:27] <KotH> s/false/wrong/
[09:44:28] <barque> I'm not saying things have stayed the same
[09:44:31] <Dark_Shikari> better yet
[09:44:34] <Dark_Shikari> read agner's guides
[09:44:38] <Dark_Shikari> and then go try to make one of x264's asm functions faster.
[09:44:43] <KotH> av500: could you please spell out what "that" is?
[09:44:48] <Dark_Shikari> one of them.  any one.
[09:44:55] <Dark_Shikari> you have 500 to choose from
[09:45:08] <KotH> Dark_Shikari: agners guides?
[09:45:15] <Dark_Shikari> http://agner.org/optimize
[09:45:17] <av500> KotH: hennessy&paterson
[09:45:21] <Dark_Shikari> software optimization guides
[09:45:22] <KotH> Dark_Shikari: ah..
[09:45:24] <Dark_Shikari> asm optimization guides
[09:45:26] <Dark_Shikari> microarchitecture guides
[09:45:27] <Dark_Shikari> instruction tables
[09:45:46] <Dark_Shikari> his instruction tables are godlike.
[09:45:48] <av500> KotH: you mentioned it and my company bought it 5min later...
[09:45:54] <KotH> av500: lol
[09:46:04] <Dark_Shikari> I use them so often I've practically memorized the entire simd instruction tables for core 2, core i7, and a few others
[09:46:10] <barque> all I was really saying is that a single simple pipeline (like the ones you find in DSPs) could really make independent batch stores and loads look useful
[09:46:23] <av500> KotH: ~30$ used from the US... not too bad and looks like new..
[09:46:27] <KotH> av500: if you want more literature, i can give you more hints and tips on what to buy :)
[09:46:31] <barque> like the ones you want to see with using restrict
[09:46:45] <av500> KotH: I give you my amazon login details :)
[09:46:52] <KotH> av500: imho that book is worth every CHF you pay for it.. no matter whether used or new
[09:46:55] <Dark_Shikari> barque: now wouldn't it be nice if restrict actually did that
[09:47:01] <Dark_Shikari> it didn't even do anything prior to gcc 4.5
[09:47:04] <Dark_Shikari> and even in gcc 4.5, it still sucks
[09:47:12] <Dark_Shikari> Here's a really fun one for you
[09:47:31] <av500> KotH: I did not like the fact it wanted me to read the 200page appendix A before I proceed :)
[09:47:31] <Dark_Shikari> dspfuncs->sad( a->arg1, a->arg2, a->arg3, a->arg4 );
[09:47:38] <Dark_Shikari> Not only will it reload arg1 through arg4...
[09:47:39] <barque> so what's all this mud slinging then? assuming that I'm ignorant of today's archs or what-have-you :<
[09:47:42] <Dark_Shikari> it'll reload dspfuncs->sad!
[09:47:59] <Dark_Shikari> the function pointer that it just called might have changed as a result of the call
[09:48:01] <barque> well sure I have yet to break into intel HQ
[09:48:03] <Dark_Shikari> and to make things even more fun
[09:48:10] <Dark_Shikari> attribute__((pure)) doesn't work for function pointers
[09:48:12] <Dark_Shikari> making it totally useless.
[09:48:27] <barque> hmm
[09:48:28] <Dark_Shikari> it is completely impossible to fix that with restrict or anything similar: the only option is to make the function pointer a local variable.
[09:48:29] <KotH> av500: lol
[09:48:30] <barque> well that's nice
[09:48:39] <Dark_Shikari> and that makes code insanely ugly
[09:48:41] <KotH> av500: yes, the org of the book is strange
[09:48:50] <KotH> av500: but still very good reading
[09:49:02] <av500> KotH: if I had the time :(
[09:49:04] * KotH read half of within a week
[09:49:25] <barque> so yeah, what I was trying to say Shikari... is that in actual practice, especially on the x86-32, you don't get much of that 'store batch' goodness
[09:49:34] <barque> like what you probably want to expect
[09:49:35] <Dark_Shikari> it doesn't matter beacuse of OOE
[09:49:40] <barque> of course
[09:49:44] <barque> exactly, Tomasulo
[09:49:56] <barque> the hardware will tell you, who will go where
[09:50:02] <Dark_Shikari> of course, the OOE is incredibly dumb
[09:50:05] <Dark_Shikari> and will constantly do the wrong thing
[09:50:08] <barque> hehehe
[09:50:11] <barque> I bet
[09:50:17] <barque> nothing makes a perfect hardware
[09:50:25] <Dark_Shikari> like if instruction N can use p0, p1, or p5
[09:50:26] <barque> where it magically finds the excellent dependency chains
[09:50:28] <Dark_Shikari> and N+1 can use p1 only
[09:50:33] <Dark_Shikari> and p0 and p1 are free
[09:50:37] <Dark_Shikari> it may put instruction N into p1
[09:50:41] <Dark_Shikari> forcing N+1 to stall
[09:50:45] <barque> howabout register renaming, that sucks too?
[09:50:50] <Dark_Shikari> register renaming seems to work fine
[09:50:58] <Dark_Shikari> OOE generally works well, it's just that you have to play with it a bit.
[09:51:05] <barque> shouldn't that do something in your given case?
[09:51:22] <barque> ahh nevermind
[09:51:23] <Dark_Shikari> I'm not sure how register renaming helps you use underutilized alus
[09:51:31] <barque> sorry I didn't see any registers
[09:51:41] <Dark_Shikari> p0/p1/p5 == intel alus
[09:51:44] <barque> I thought you mentioned registers
[09:51:45] <barque> yeah
[09:51:52] <barque> the new SSE4 or whatever they have
[09:51:58] <barque> how many do they have anyway?
[09:52:21] <barque> I saw 3 in the Nehalem diagram the other day
[09:52:35] <Dark_Shikari> 3
[09:52:39] <barque> yeah
[09:52:45] <Dark_Shikari> they've had 3 for half a decade
[09:52:46] <barque> with like parts of 2 for FP
[09:52:47] <enkidu> sse+fpu in parallel gives something?
[09:52:47] <Dark_Shikari> or more
[09:52:54] <Dark_Shikari> enkidu: no
[09:52:56] <barque> lol
[09:53:05] <barque> they've had only 2 pipelines for more than god's age
[09:53:10] <barque> hyperthread
[09:53:11] <barque> lol
[09:53:16] <Dark_Shikari> HT is new
[09:53:18] <Dark_Shikari> at least, HT done properly
[09:53:35] <Dark_Shikari> they have 6 units iirc
[09:53:37] <barque> but yeah
[09:53:44] <Dark_Shikari> 3 ALU, 1 load, 1 store, 1 address
[09:53:48] <barque> yeah
[09:53:56] <barque> and a memory order buffer for the load/store
[09:54:07] <Dark_Shikari> and because of fun things like "p1 almost never gets used unless you're doing float or multiplies"
[09:54:12] <Dark_Shikari> you can get huge performance boosts by using the wrong instructions.
[09:54:17] <barque> lol
[09:54:36] <barque> so I hope I'm not being an ass to anyone
[09:54:43] <barque> KotH, we're still friends right?
[09:54:54] <KotH> hmm?
[09:55:02] <KotH> we were friends? didnt know that
[09:55:12] * Dark_Shikari makes note about using multiplies to perform subtractions
[09:55:19] <barque> lol, I wasn't bashing x86-32... I was just saying RISC with a bare pipeline and minimum extra hardware would do a better use of restrict (batch load/stores)
[09:55:34] <barque> that's all
[09:55:42] <barque> then I was told I'm a fool and what have you
[09:55:53] <barque> just wondering if we're still friends?
[09:56:04] <KotH> barque: anything can do better than an architecture that has been patched and extended for 30 years
[09:56:06] <av500> barque: don't take it to seriously
[09:56:24] <KotH> barque: lol
[09:56:29] <KotH> barque: we're on the internet
[09:56:32] <barque> right
[09:56:44] <KotH> barque: people flame here freely... especialy around ffmpeg and mplayer
[09:56:52] <barque> actually my prof was working for the soviets
[09:56:54] <barque> I'm not kidding
[09:57:01] <barque> he worked alongside creator of Tetris
[09:57:02] <KotH> kshishkov: your call!
[09:57:16] <av500> where is thresh when you need him?
[09:57:28] <barque> http://www.ee.ryerson.ca/~lkirisch/   <= this guy
[09:57:44] <barque> read his bio, interesting stuff
[09:58:24] <KotH> what is interesting there?
[09:58:27] <av500> "...as well as a pilot version of the control system M-64 (1985), for the new generation of Soviet nuclear power stations..."
[09:58:31] <av500> hmm
[09:58:35] <Dark_Shikari> barque: nothing wrong with that, x86_32 sucks
[09:58:40] <Dark_Shikari> it's just that RISC has nothing to do with that
[09:58:53] <barque> well at heart it's got a lot of RISCy stuff
[09:58:59] <barque> Hardwardy RISCy
[09:59:10] <barque> I mean "load/store" is RISC hallmark no? :D
[09:59:12] <Dark_Shikari> the problem is that the instruction set is too _simple_, not too complex.
[09:59:20] <barque> and uInstructions
[09:59:23] <Dark_Shikari> two-operand, etc
[10:00:14] <barque> I was surprised when I (first) realized that it's modified hardward... (before that I always saw only one address space, so I made the wrong assumption)
[10:00:30] <barque> and then I saw simple decoders
[10:00:32] <barque> and load/store
[10:00:38] <barque> etc.
[10:00:43] <barque> then my world was shattered :D
[10:00:55] <barque> my beloved CISC was a super-scalar RISC
[10:01:25] <Dark_Shikari> CISC and RISC have become useless terms anyways
[10:01:31] <Dark_Shikari> good instruction sets have ended up being incredibly complex
[10:01:42] <Dark_Shikari> sometimes people just use RISC to mean "load/store" but then they might as well just say "load/store"
[10:01:44] <KotH> barque: well...i'm not impressed
[10:01:56] <barque> lol his friend created Tetris
[10:02:00] <barque> how about that? :D
[10:02:15] <barque> he told us, it was basically an exercise in dynamic scheduling
[10:02:20] <barque> which makes sense if you think about it
[10:02:26] <barque> holes == processing elements
[10:02:33] <barque> every clock == instruction moves down the pipeline
[10:02:38] <barque> up to you to schedule :]
[10:02:47] <Dark_Shikari> don't tell me what your friend did, tell me what you did.  or if you didn't do anything, come do something.
[10:02:51] <Dark_Shikari> like optimize some asm =p
[10:02:56] <barque> :D
[10:02:56] <KotH> barque: i've worked on mplayer, ffmpeg, LTO tape drive controller chips, 40GBit/s 128 port fully optical switch controllers, there is code from me in the linux kernel,.... etc pp
[10:03:00] <barque> I'm already doing work on this side
[10:03:25] <barque> nice KotH, I wasn't contesting your contributions
[10:03:33] <barque> I'm saying that he's an old schooler from KGB
[10:03:36] <barque> that's all :D
[10:03:40] <barque> I kid I kid
[10:03:54] <KotH> barque: "i have worked on" does not say anything.. maybe you were just the guy who had a look at the highest level design white paper and were allowed to comment on it
[10:04:05] <kshishkov> tell that to CIA guys later
[10:04:05] <Dark_Shikari> KotH: or like the guys who started cuil who "worked at google"
[10:04:09] <Dark_Shikari> for all we know they were janitors
[10:04:21] <KotH> hehe... exactly
[10:04:27] <barque> lol I'm out of this loop
[10:04:31] <barque> I didn't say I worked on anything
[10:04:37] <barque> I said his FRIEND created tetris
[10:04:44] <barque> while he was in Moscow Institute of whatever
[10:04:55] <Dark_Shikari> barque: again -- doesn't matter if you didn't do anything
[10:04:56] <KotH> barque: we are just saying that you should be very carfull what people say
[10:04:56] <av500> the famous MIW?
[10:04:58] <Dark_Shikari> just come do something now ;)
[10:05:14] <barque> Dark_Shikari, sure sure, you're killing me :D
[10:05:16] <barque> I'm all yours
[10:05:21] <KotH> barque: most of my contributions to what i mention above were infinitesimal
[10:05:21] * av500 knows a lot of ppl from MIW
[10:05:37] <KotH> barque: heck, my linux kernel patch is a one liner that adds a PCMCIA id
[10:05:41] <barque> lol
[10:05:45] <barque> I gotta get ready guys
[10:05:48] <barque> for convocation
[10:05:51] <barque> it's today :)
[10:05:59] <barque> nice talking to you all
[10:06:09] <wbs> KotH: ooh, the ones I got accepted in 2001(?) actually were a few lines of real code ;P
[10:06:18] <kshishkov> KotH: and I have a special term for my contributions to MPlayer - "Compn-level developer"
[10:06:26] <KotH> wbs: hmm? i dont remember those ^^'
[10:06:38] <wbs> KotH: hah. :-)
[10:06:41] <KotH> wbs: ah.. those! :)
[10:06:52] <KotH> kshishkov: lol
[10:07:13] <KotH> kshishkov: but you know, compn contributed quite a bit in various places
[10:07:15] <Dark_Shikari> is that like a "windless-day level tornado"?
[10:07:25] <wbs> KotH: I added command line/module parameter handling of parameters to a weird scsi driver that nobody sane uses at all, that got lost in the translation from 2.2 to 2.4 :-)
[10:07:27] <KotH> kshishkov: so it isnt nothing if you call yourself "Compn-level developer"
[10:07:41] <KotH> wbs: :-)
[10:08:06] <kshishkov> KotH: well, all I did to MPlayer was some entries to codecs.conf, most of them for my own FFmpeg decoders
[10:08:16] <KotH> wbs: the one real code patch i wrote for the kernel got lost too... there was a very weird bug that happend only if you used vcd's with scsi cdroms...
[10:08:32] <KotH> wbs: and only if you switched to some special mode using mplayer
[10:09:13] <KotH> kshishkov: "sub-Compn-level developer" ;->
[10:10:27] <kshishkov> KotH: I'm fine with that too
[10:12:47] <wbs> KotH: hah :-)
[10:52:53] <Compn> i'm useful? :P
[11:24:38] <KotH> lol
[11:29:32] <siretart> hm. YV12 to NV12 conversion? doesn't libswscale support YV12 at all, or is it known under some other name?
[11:31:38] <kshishkov> YV12 is 3 planes, NV12 is only two IIRC
[11:32:07] <KotH> kshishkov: UV packet in one plane?
[11:32:17] <KotH> .o0(sound awfully familiar)
[11:33:00] <av500> semi planar
[11:36:14] <pengvado> siretart: libav* (including swscale) calls it PIX_FMT_YUV420P
[11:50:42] <siretart> interesting. thanks pengvado
[11:53:04] <siretart> pengvado: would you mind to make a note in pixfmts.h? ;-)
[11:58:45] <pengvado> you mean, for people who know they want "YV12" but don't know what YV12 is, so they can't compare it to the definitions currently in pixfmts.h?
[12:01:21] <KotH> lol
[12:01:56] <KotH> siretart: people working with different colour formats are required to know about the existance of fourcc.org
[12:02:10] <mru> nonsense
[12:02:20] <mru> only if they have a windows mindset to begin with
[12:02:53] <ln-> *existence
[12:03:02] <KotH> ln-: thanks
[12:03:05] <ln-> np
[12:03:11] <KotH> mru: uhmm. why?
[12:03:57] <mru> the entire concept of 4cc is windowsy
[12:04:12] <mru> those codes simply have no meaning outside of that garden
[12:04:34] <KotH> uhmm..
[12:04:53] <KotH> mplayer and afaik ffmpeg use the same concept to identify formats
[12:05:01] <mru> no
[12:05:09] <mru> not ffmpeg
[12:05:12] <mru> mplayer is an avi player
[12:05:16] <mru> and suffers the consequences
[12:05:37] <mru> ffmpeg uses enum PixelFormat or whatever it's called
[12:06:38] <KotH> ok.. than i remembered wrong
[12:06:51] <mru> of course many of the actual formats are the same
[12:07:01] <KotH> what does mkv, mov & co use?
[12:07:08] <mru> mov uses different 32-bit codes
[12:07:23] <mru> mpeg uses entirely different codes
[12:07:28] <mru> most of them not even 32-bit
[12:08:09] <mru> and for the planar formats, fourcc.org goes into details about specific memory layouts of the planes relative to each other
[12:08:38] <av500> taken straight out ot windows GDI I guess :)
[12:08:41] <mru> yep
[12:08:46] <mru> or something similar
[12:09:06] <mru> in reality you have for each plane a pointer to the start and a line stride
[12:09:55] <mru> which is why ffmpeg only has one code for planar 420
[12:10:02] <mru> not 16 or whatever fourcc.org has
[12:10:09] <mru> one for each packing they could think of
[12:35:47] <CIA-92> ffmpeg: mstorsjo * r23602 /trunk/libavcodec/nellymoserdec.c: nellymoserdec: Allow using unusual input block sizes
[12:36:21] <CIA-92> ffmpeg: mstorsjo * r23603 /trunk/libavcodec/nellymoserdec.c: Reindent
[12:36:53] <merbzt> \o/
[12:49:19] <lu_zero> wbs: ping
[12:53:43] <wbs> lu_zero: pong
[12:55:23] <lu_zero> wbs: dss allows PAUSE during live?
[12:55:40] <lu_zero> or it disables them for on-demand?
[12:55:55] <wbs> hmmm, don't know actually
[12:56:18] <wbs> what client could I test that with?
[12:59:37] <lu_zero> wbs: ffplay issues pause
[13:02:27] <lu_zero> I'll shut down roundup for a while
[13:02:51] <lu_zero> KotH: we'll have to decide where to put it and update the dns
[13:03:58] <lu_zero> I'd like to have the thing moved within this week
[13:04:21] <KotH> hmm..
[13:04:35] <KotH> lu_zero: you dont have a login on natsuki, do you?
[13:06:06] <lu_zero> I don't
[13:06:30] <lu_zero> I can move it to the top-ix anyway
[13:06:49] <KotH> i wouldnt mind if we centralize it on natsuki
[13:07:00] <lu_zero> since it uses lots of space AND cpu make sure we have enough
[13:07:18] * mru feels uneasy about running piles of python code and databases
[13:07:29] <KotH> but i dont have much time this week, that's why i'd like you to do all the ground work, check what's needed so that i have only to do the tasks that need root
[13:07:53] <KotH> lu_zero: cpu, ram and diskspace are not a problem
[13:08:20] <lu_zero> ok
[13:09:12] <lu_zero> basically you "just need" mysql and python
[13:09:42] <lu_zero> so if you have python 2.6 (mod_wsgi) and virtualenv installed I can prepare the rest
[13:09:55] <KotH> we dont run apache :)
[13:10:31] <lu_zero> ...
[13:10:34] <lu_zero> what then?
[13:10:34] <KotH> if you need apache, we can install it on batanen  (though the apache tehre isnt set up at all)
[13:10:37] <KotH> lighttpd
[13:10:43] <lu_zero> uhmm
[13:11:04] <lu_zero> right now I want just to close that server
[13:11:05] <lu_zero> so
[13:11:34] <lu_zero> probably it's quicker for me setting up roundup on lscube.org AND then we can consider a further migration
[13:11:51] <KotH> maybe
[13:12:51] <KotH> we can do whatever you like
[13:19:39] <wbs> lu_zero: it does seem to support pause during live transmissions, and then it simply drops any packets during the pause
[13:20:20] <lu_zero> ok
[13:21:09] <lu_zero> KotH: hopefully this night I'll prepare a setup and during the night we could update the dns and copy the db
[13:21:49] <KotH> ok
[13:24:17] <merbzt> wbs: commit at will no need to send patches
[13:25:08] <wbs> merbzt: ok, thanks :-)
[13:26:08] <KotH> but be carefull... there is a niedermayer waiting at the entrance to svn-land...
[13:26:36] <wbs> KotH: well, it was actually he who suggested this change ;P
[13:27:43] <KotH> wbs: it might be. but does he also aprove of your quest? or does he want the princess for himself? ;)
[13:28:59] <siretart> KotH: I did of course check fourcc.org, but I wasn't able to conclude that YV12 is an alias for YUV420P
[13:29:17] <KotH> siretart: so ka
[13:29:21] <wbs> KotH: haha
[13:29:25] <KotH> siretart: well.. i can understand that
[13:29:40] <mru> if you knew the details of yuv420 you'd notice that fourcc.org has about a dozen different codes for various layouts of this format
[13:29:42] <kshishkov> and next people won't be able to guess that IF9 stands for YUV410p
[13:29:43] <KotH> siretart: feel free to write a chapter on colour formats for BoW :-)
[13:31:25] <siretart> KotH: heh
[13:33:30] <KotH> oh... a 600 loc function... very mplayeresque
[13:42:59] <kshishkov> where?
[13:43:33] <KotH> internal code
[13:43:46] <KotH> written 5y ago by a then novice programmer
[13:44:04] <KotH> and with no understanding about unix, datastructures or algorithms ^^'
[13:44:28] * KotH guestimates that the whole code could be shrank by a factor of 4 or so, just by proper design
[13:44:41] <av500> or pkzip...
[13:45:08] <KotH> that would lead a reduction by a factor of 100 :)
[13:45:12] * kshishkov was always lazy so his programs tended to be rather short
[13:46:21] <KotH> kshishkov: lazynes, impatience and hybris
[13:56:50] <KotH> hmm... if this thing would have line numbers, i'd say it's basic ^^'
[14:07:34] <CIA-92> ffmpeg: mstorsjo * r23604 /trunk/libavcodec/nellymoserdec.c: nellymoserdec: Simplify calculation of numbers of blocks
[14:08:14] <CIA-92> ffmpeg: mstorsjo * r23605 /trunk/libavcodec/nellymoserdec.c: Reindent
[14:09:44] <thresh> av500: here
[14:09:51] <CIA-92> ffmpeg: mstorsjo * r23606 /trunk/libavcodec/nellymoserdec.c: nellymoserdec: Increase the log level of messages when failing to decode data
[14:10:48] <thresh> well now not here
[14:12:44] <av500> thresh: we needed your expertise on tetris earlier
[14:13:15] <lu_zero> tetris?
[14:13:50] <lu_zero> av500: are you trying to write a tetris in which you move the table by accelerometer feedback instead of moving the falling piece?
[14:19:06] <av500> [11:57] <barque> actually my prof was working for the soviets
[14:19:22] <av500> [11:57] <barque> he worked alongside creator of Tetris
[14:31:49] <lu_zero> hi BBB
[14:35:27] <BBB> hi
[14:35:51] * kshishkov wonders if somebody took a picture of lu_zero near BBB
[14:39:51] <kierank> are there any pictures from linuxtag
[14:41:44] <av500> not yet
[14:41:44] <BBB> uhm...
[14:41:59] <mru> there's the youtube video showing BBB
[14:42:02] <av500> kierank: http://www.youtube.com/watch?v=xsqkVowgHuI
[14:42:12] <av500> I have to upload some pics
[14:43:15] <BBB> linkedin is so silly
[14:43:24] <BBB> I'm adding a person
[14:43:28] <BBB> then he knows a person I know
[14:43:32] <BBB> I click "add to my network"
[14:44:02] <BBB> AND NOW IT WANTS ME TO RE-ENTER THE EMAILADDRESS OF THAT VERY PERSON, WHAT THE HELL IS WRONG WITH YOU, YOU SHOULD KNOW THAT, STUPID DATABASE WRAPPER
[14:44:15] <kierank> that is a verification step
[14:44:25] <kierank> afaik
[14:44:26] <BBB> it's a user-unfriendly verification step
[14:44:48] <BBB> imagine that every time you want to take money out of the atm, you have to show your passport to the cleric
[14:44:50] * KotH gives BBB some valium
[14:44:58] <KotH> BBB: take it.. it might help you
[14:45:20] <KotH> BBB: uhmm.. in .ch you have to show your passport (or any other official id)
[14:45:49] <av500> KotH: to the ATM?
[14:46:59] <KotH> we've japanese style ATM's where a man sits behind it and waits for you to need help or show your passport
[14:48:13] <kshishkov> what cantons are those?
[14:48:47] <KotH> the japanese speaking ones :)
[14:49:17] * kshishkov searches for Japanese-speaking Swiss canton on map of Turkey
[14:50:44] <KotH> kshishkov: interlaken, luzern, ... ;)
[14:52:29] <kshishkov> central German-speaking part of .ch?
[14:53:02] <KotH> no, the places where there are more japanese tourists than swiss citizens
[14:53:15] <av500> KotH: ah, like this: http://imagebin.ca/view/Ovs2Bh.html
[14:53:35] <KotH> av500: lol
[14:53:48] <KotH> av500: no, actually that bit is true
[14:54:05] <KotH> av500: ATMs, ticket machines and stuff like that have a room behind it with someone sitting there
[14:54:30] <KotH> av500: if you have problems, you press a button and someone will come and open a small window and ask you where he can help
[14:55:11] <av500> u sure he isn't just living there, small apartments and what have you...
[14:55:12] <mru> hope they don't have freestanding ATMs
[14:56:13] <kshishkov> or freewalking
[14:57:54] <av500> KotH: sometimes he lives in front of atm? http://www.weirdasianews.com/wp-content/uploads/2009/04/atm01.jpg
[15:17:20] <twnqx> does vlc have a wmv3/vmw9 implemantation of its own?
[15:17:33] <kshishkov> unlikely
[15:17:47] <kshishkov> it may have binary loader though
[15:18:05] <kierank> probably a stupid question but why does vc-1 interlaced have to be REd if there is already a smpte spec?
[15:18:19] <av500> and no real world usage...
[15:18:31] <kierank> av500: some blu-rays
[15:18:37] <av500> orly?
[15:18:40] <av500> gee
[15:18:49] <av500> interlaced as in TV shows?
[15:19:02] <kierank> virtually all warner bbc blu-rays that have been converted from 25p to 30i :/
[15:19:35] <av500> and they are VC1 only?
[15:19:54] <kierank> they used to be only vc-1. however there are usually non-warner eu versions which are h.264
[15:19:56] <enkidu> nice. 21st century and interlaced media
[15:20:09] <kierank> warner is always 15mbit vc-1 or the likes
[15:20:10] <twnqx> kshishkov: wondering because this stream seems blocky in mplayer/linux every now and then, and $friend says with vlc/windows there's no blocking
[15:20:27] <twnqx> i guess the real reason is windowed vs. fullscreen though
[15:21:54] <mru> or $friend being less good at spotting artifacts
[15:22:40] <enkidu> or $friend got nvidia purevideo or something else enabled ;]
[15:24:27] <KotH> av500: lol
[15:25:55] <KotH> mru: "$friend not seeing artifacts at all" would describe it better
[15:27:02] * KotH has seen $friends watching videos with half a second a/v desync, or totally distorted video... and finding everything just fine
[15:28:01] <twnqx> Oo
[15:29:03] <lu_zero> twnqx: people sometime doesn't care
[15:29:11] <elenril> KotH: o_0 and those atms work 24/7?
[15:31:23] <KotH> elenril: ofc
[15:31:38] <KotH> elenril: though, dont expect someone responding after midnight :)
[15:34:08] * kshishkov suspects that in China all electronic actually operates with people
[15:35:02] * elenril thinks that in soviet russia, electronics operates you
[15:36:06] * KotH suspects that elenril has been on 4chan for too long
[15:37:12] * kshishkov reminds KotH what site elenril likes the most
[15:37:59] <elenril> actualy i didn't open 4chan for a few weeks now =p
[15:38:00] * KotH didnt say that a b-tard cannot evolve to something else
[15:38:43] <elenril> b-tard????
[15:38:51] * elenril isn't talking to KotH anymore
[15:38:52] <kshishkov> what is "b-tard" and how different is that thing from MPlayer dev?
[15:39:45] <KotH> kshishkov: look at spaam and microchip_, these are true b-tards, but not mplayer devs
[15:39:46] <elenril> kshishkov: http://www.urbandictionary.com/define.php?term=%2Fb%2Ftard
[15:41:58] <KotH> #5 is great! :)
[15:42:43] * kshishkov compares #3 with elenril, finds little difference
[15:44:28] <KotH> "We are one. Anonymous does not forgive. Anonymous does not forget. We are legion. We are Anonymous." <- i wonder how many people will in 5 years still remember where that moto is comming from
[15:44:48] <KotH> but it will be repeated in a 9000 years, still!
[15:44:54] <kshishkov> from somewhere else with s/X/Anonymous/
[15:44:55] * elenril isn't talking to kshishkov either
[15:45:10] <elenril> the talking is over. starting now there'll be a lot less...err wait
[15:45:12] <kshishkov> elenril: just don't post links
[15:46:10] * elenril doesn't where's that motto from even now
[15:47:04] <KotH> elenril: you fail at being even a b-tard!
[15:47:38] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/CriticalResearchFailure was someone talking about links?
[15:54:33] <av500> giten tag
[15:54:36] <DonDiego> moin
[15:55:05] <av500> wie git es dir?
[15:55:18] <DonDiego> got
[15:55:26] <DonDiego> or rather
[15:55:28] <DonDiego> svn
[15:56:00] * elenril invokes godwin's law on svn
[16:02:00] <microchip_> KotH: stop spreading lies. I'm not a b-tard, haven't visited that place for a long time
[16:05:14] <lu_zero> pfff
[16:19:07] <enkidu> microchip_: rule #1 and #2?
[16:19:20] * enkidu requesting rule 34 on microchip_ ;p
[16:19:59] <microchip_> lol
[17:36:39] <CIA-92> ffmpeg: michael * r23607 /trunk/ffmpeg.c:
[17:36:39] <CIA-92> ffmpeg: Deprecate -crop* arguments, they currently are buggy (issue1957) and probably
[17:36:39] <CIA-92> ffmpeg: will be fixed by removing them.
[18:34:43] <Dark_Shikari> kshishkov:
[18:34:44] <Dark_Shikari> This is for chroma only. There was a problem where for low bitrates,
[18:34:44] <Dark_Shikari> long scenes with no scene changes, if we always rounded down, chroma
[18:34:44] <Dark_Shikari> would slowly drift towards pink. It was resolved by rounding up for some
[18:34:45] <Dark_Shikari> of the positions.
[18:42:49] <janneg> Dark_Shikari: http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http://www.golem.de/1006/75750.html&sl=de&tl=en
[18:43:46] <janneg> I guess it's not impossible to find material and settings at which x264 has a lower PSNR than vp8 at the same bitrate
[18:44:11] <mru> sure, just don't say --tune=psnr to x264
[18:44:16] <pJok> i wonder if ffmpeg compiles with android ndk
[18:44:23] <mru> then it optimises for actual quality instead
[18:44:34] <mru> pJok: the compiler should be ok
[18:44:39] <janneg> unfortunately his linuxtag slides are not available
[18:44:51] <mru> pJok: but don't let the ndk mess with the cflags
[18:44:55] <mru> it will break
[18:45:05] <pJok> mru, of course...
[18:45:11] <pJok> wouldn't expect otherwise
[18:45:30] <mru> using a proper compiler is probably better though
[18:45:34] <kshishkov> Dark_Shikari: would you consider it logical
[18:45:42] <mru> iirc they use some horribly outdated version in the ndk
[18:45:43] <Dark_Shikari> janneg: I would say it is impossible.
[18:45:51] <Dark_Shikari> vp8 is basically a subset of h264
[18:45:54] <janneg> mru: iirc PSNR was still better in Dark_Shikari comparisson
[18:45:57] <wbs> mru: the latest one has gcc 4.4
[18:45:59] <pJok> mru, im just thinking of an alternative solution to pulseaudio
[18:46:03] <Dark_Shikari> janneg: I used tune psnr too
[18:46:11] <mru> wbs: that's horrible compiler
[18:46:22] <janneg> Dark_Shikari: even for the visual comparisson?
[18:46:28] <pJok> mru, that would work on  more platforms than just linux (even though they say it works on multiple platforms)
[18:46:31] <Dark_Shikari> janneg: obviously not
[18:46:49] <mru> pJok: that == ?
[18:47:37] <mru> hmm pulseaudio I guess
[18:47:42] <mru> my alternative: nothing
[18:47:45] <pJok> mru, broadcast audio to one single machine that has speakers hooked up
[18:47:53] <pJok> well
[18:48:32] <twnqx> nas
[18:48:36] <pJok> i just hate when people chose something because it works on their platform and say its good because its free and opensource... when noone has bothered compiling a version for windows never than 2007
[18:48:45] <barque> well hello again folks!
[18:48:58] <barque> now that all that ceremonial wackadoodle is over with :D
[18:48:58] <mru> let the trolling commence
[18:49:08] <barque> lol trolling?
[18:49:14] <barque> hello mru, I'm barque
[18:49:16] <barque> :]
[18:49:24] <barque> Dark_Shikari, you there?
[18:49:27] <Dark_Shikari> yes
[18:49:30] <pJok> twnqx, the idea here is that people them selves are responsible for their music so the community as such here (hackerspace) isn't a playground for piracy ;)
[18:49:32] <barque> ahh hello again
[18:49:34] <elenril> 'FFmpeg - Troll-driven development (tm)'
[18:49:55] <elenril> fftech should really trademark that
[18:49:57] <barque> I actually thought about what you said regarding 'restrict'. You're right, I missed a big point there. It helps retain operands in registers.
[18:50:17] <barque> that's a big gain... come to think of it
[18:50:27] <barque> especially in long functions with long additions etc.
[18:50:33] <barque> or alu ops
[18:50:57] <janneg> linuxtag had almost 12k visitors
[18:51:33] <barque> but it sure helps a lot more with longer register files
[18:51:46] <barque> you know, you can retain a lot more in registers yada yada
[18:51:59] <janneg> and the wrong speeling seems to be contagious http://www.golem.de/1006/75767.html
[18:52:09] <janneg> spelling
[18:52:43] <barque> Dark_Shikari, just wondering, if you pass -pix_fmt bgra to ffmpeg, it decodes BGRA into memory right (AVFrame)?
[18:52:56] <barque> regardless of video's original packing format
[18:52:58] <twnqx> pJok: missed the windows part - i meant network audio system
[18:53:27] <pJok> ah
[18:55:07] <barque> .. does it?
[18:55:14] <janneg> next years linuxtag will be a month earlier. May 11th - 14th 2011
[18:56:16] <barque> anyone watching E3 btw?
[18:56:24] <barque> there's a youtube feed :P
[18:56:37] <mru> janneg: that site seems to lack long-term memory
[18:56:45] <mru> google were there two years ago
[18:56:51] <mru> and year before that
[18:56:52] <mru> and year before that
[18:56:56] <mru> etc, etc
[18:57:43] <elenril> barque: anything interesting happened?
[18:58:14] <elenril> except incredibly lame new name for project natal?
[18:59:05] <barque> they're advertising kinect to death
[18:59:10] <barque> Microsoft's hands-free controller
[18:59:17] <barque> god is it boring
[18:59:29] <barque> at one point you're like, "we GET IT, IT'S HANDS FREE"
[18:59:42] <Dark_Shikari> NATAL
[18:59:46] <Dark_Shikari> NAAAAAAAAAAAATAL
[18:59:50] <Dark_Shikari> barque: I'm going to be there
[19:00:01] <barque> in E3?
[19:00:05] <barque> well it's happening right now
[19:00:08] <barque> so you'd better hurry
[19:00:13] <barque> so umm just wondering
[19:00:27] <barque> pix_fmt bgra means ffmpeg decodes just like that
[19:00:30] <barque> no questions asked
[19:00:32] <Dark_Shikari> barque: no, it starts tuesday
[19:00:51] <Dark_Shikari> or, well, our company does
[19:00:54] <Dark_Shikari> we're setting up on monday
[19:01:03] <barque> what are you advertising?
[19:01:04] <mru> today is monday
[19:01:20] <barque> yeah it's Monday
[19:01:30] <Dark_Shikari> I know
[19:01:35] <Dark_Shikari> the setting up doesn't involv eme
[19:01:46] <barque> so, what are you guys doing?
[19:01:52] <barque> don't tell me you work for Ubisoft
[19:01:54] <Dark_Shikari> we have a private room in the back where we're inking deals ;)
[19:01:56] <Dark_Shikari> ubisoft?  lol
[19:02:12] <barque> you're killing me already
[19:02:15] <barque> where do you work?
[19:02:33] <av500> Dark_Shikari is porting VP8 to xbox...
[19:02:34] <barque> gah
[19:02:37] <elenril> lol
[19:02:50] <mru> VP360
[19:02:56] <Dark_Shikari> http://x264dev.multimedia.cx/?p=458
[19:02:58] <barque> lol
[19:03:00] <Dark_Shikari> for janneg
[19:03:25] <barque> alright
[19:03:27] <barque> so finally
[19:03:29] <barque> imma ask again
[19:03:40] <barque> pix_fmt bgra means BGRA in AVFRame right?
[19:03:57] <barque> AVFrame->data
[19:03:59] <barque> rather
[19:04:15] <janneg> mru: it's called Qualitaetsjournalismus in german. i.e. don't even try to research your facts
[19:04:46] <barque> come on
[19:04:58] <barque> any of you guys can answer that
[19:05:10] <mru> that question belongs in #ffmpeg
[19:05:17] <barque> ok
[19:46:32] <twnqx> Dark_Shikari: Stream #0.0(eng): Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 24 tbr, 20k tbn, 180k tbc <- why does x264 write 180kfps? :X
[19:47:09] <Dark_Shikari> er, that's a timebase of 180000
[19:47:10] <Dark_Shikari> that's not an fps
[19:47:23] <twnqx> hm
[19:50:55] <twnqx> because... when muxing the x264 encoded mkv, which says "Seems stream 0 codec frame rate differs from container frame rate: 180000.00 (180000/1) -> 24.00 (24/1)" with mkvmerge i get a 25fps mkv...
[19:51:19] <twnqx> guess i expected x264 to take the source fps from the .m2ts
[19:53:59] <Dark_Shikari> um, no, it takes the source timebase
[19:54:12] <Dark_Shikari> that's what VFR means :)
[20:31:13] <twnqx> mh vfr...
[20:31:18] <twnqx> is that legal on BDs?
[20:31:43] <twnqx> i mean... maybe my source isn't 24fps after all
[20:34:48] <peloverde> I don't know if http://x264dev.multimedia.cx/?p=458#comment-5458 (comment 4) makes me want to laugh or jam a fork in my eye
[20:35:48] * kierank clicks on "notes on testing theora" and takes a deep breath
[20:36:20] <Dark_Shikari> peloverde: he's mostly right
[20:36:35] <Dark_Shikari> we need a "notes on testing ANYTHING" page
[20:36:38] <Dark_Shikari> which says stuff like
[20:36:41] <Dark_Shikari> "DONT FUCK UP YOUR COLORSPACES"
[20:36:59] <Dark_Shikari> or "it has worse contrast" is rarely an observation about an encoder that's correct
[20:37:57] <peloverde> There are plenty of legitimate uses of very low bitrate video, there are much fewer for bitrates above transparency for non-archival purposes
[20:38:08] <Dark_Shikari> no, there aren't, and here's the reason
[20:38:16] <Dark_Shikari> past a certain point, you'd be better off downscaling
[20:38:23] <Dark_Shikari> making the bitrate no longer "very low" for that reason
[20:38:32] <Dark_Shikari> most non-wavelet codecs are _not_ infinitely scalable
[20:38:41] <Dark_Shikari> so you can't just lower the bitrate infinitely and expect them to scale well
[20:38:48] <peloverde> That's true, I never said downscaling was not allowed
[20:38:50] <Dark_Shikari> past a certain point, you are better off using a lower resolution
[20:38:58] <Dark_Shikari> well, if you're able to use a lower resolutionj
[20:39:02] <Dark_Shikari> there is no such thing as "very low bitrate"
[20:39:12] <peloverde> So then use a lower resolution
[20:39:22] <peloverde> what's the big deal?
[20:39:26] <Dark_Shikari> people who don't.
[20:39:36] <peloverde> Huge resolution at tiny bitrate is problematic
[20:39:38] <Dark_Shikari> for example, if I did my 1080p parkjoy comparison at 3mbps instead of 14mbps.
[20:39:41] <peloverde> he never siad huge resolution
[20:39:43] <Dark_Shikari> That
[20:39:46] <Dark_Shikari> that's what he implied.
[20:39:52] <Dark_Shikari> "very low bitrate" means "very low bitrate for the given resolution"
[20:39:53] <Dark_Shikari> obviously
[20:40:02] <peloverde> I would argue he didn't
[20:40:08] <Dark_Shikari> He's not stupid.  That's what everyone means.
[20:40:14] <Dark_Shikari> it's an implicit assumption
[20:40:31] <mru> low bitrate == few bits per pixel
[20:40:41] <Dark_Shikari> what mru said.
[20:40:49] <peloverde> low bitrate = few bits per second
[20:40:56] <Dark_Shikari> no
[20:41:04] <Dark_Shikari> "1mbps" is low bitrate for 2160p
[20:41:07] <Dark_Shikari> it's not low bitrate for CIF
[20:41:38] <Dark_Shikari> I define "unreasonably low bitrate" in x264 to mean that your average P-frame quant is > ~35-40.
[20:41:39] <mru> you must specify framerate too
[20:41:43] <Dark_Shikari> that too yes
[20:41:54] <peloverde> I'm looking at this from you have a certain channel bandwidth and part of encoding is choosing an appropriate resolution and frame rate perspective
[20:41:56] <mru> 1Mbps at 1fpb might be ok for 2160p
[20:41:59] <mru> fps
[20:42:29] <Dark_Shikari> peloverde: stop trying unreasonably hard to find flaws in every statement made by people you don't like
[20:42:34] <Dark_Shikari> it makes you look like a jackass.
[20:43:08] <mru> 0.1 bits per pixel is usually a resonable target
[20:43:12] <peloverde> I came to that with a different set of assumptions and came to a different set of conclusions
[20:43:29] <Dark_Shikari> mru: I would say while bits per pixel is a decent measure compared to, say, bitrate
[20:43:40] <Dark_Shikari> a better one would be a matter of bits per entropy
[20:43:50] <Dark_Shikari> since there's highly compressible and highly incompressible stuff.
[20:44:07] <mru> sure
[20:44:27] <mru> it's still a good starting point
[20:44:32] <Dark_Shikari> e.g. I have content that looks acceptable at 0.001-0.002 bits per pixel.
[20:44:47] <mru> that must be rather extreme stuff
[20:44:52] <Dark_Shikari> anime.
[20:45:02] <Dark_Shikari> though 0.1 is generally overly high
[20:45:11] <Dark_Shikari> 14mbps on parkjoy, which is a REALLY tough clip to compress
[20:45:21] <Dark_Shikari> and which looked Good Enough with x264 (imo)
[20:45:30] <Dark_Shikari> oh wait, google was giving me bytes per pixel
[20:45:40] <Dark_Shikari> so that would be 0.14bpp
[20:45:54] <Dark_Shikari> and 0.01-0.015 on the anime.
[20:46:00] <mru> sounds more reasonable
[20:46:03] * Dark_Shikari hits google for not giving me the units I wanted.
[20:53:38] <lu_zero> uh?
[20:54:17] <mru> google calculator?
[20:54:22] <Dark_Shikari> yes
[21:05:08] <Dark_Shikari> hahahahaha
[21:05:09] <Dark_Shikari> > I doubt Michael will suddenly use the shift key due to that, for example.
[21:05:12] <Dark_Shikari> I have just one reliably working shift key left here, iam just trying to
[21:05:15] <Dark_Shikari> extend its lifetime :)
[21:09:29] <reynaldo> I laughed at that one too ;)
[21:31:06] <spaam> KotH: haha
[21:33:15] <Tjoppen> hehe
[21:45:57] <enkidu> oh crap...
[21:47:09] <enkidu> is "if () blah; ret; if () bleh; ret; if () bloh; ret;" less eficient than nested case?
[21:47:37] <Dark_Shikari> doubt anyone cares
[21:47:45] <Dark_Shikari> on an unrelated note, I need a regex that does { X, Y } -> { (X<<4) + (Y-1) }
[21:48:23] <Dark_Shikari> where X and Y are strings with no spaces (tokens)
[21:48:53] * enkidu has regex knowledge in <0;10> scale: -15
[21:49:00] <Dark_Shikari> so I can convert these 10 pages of tables
[21:49:31] <enkidu> i will have to rewrite half of ffserver to use switch-case approach
[21:52:21] <Dark_Shikari> hmm, it might actually be posisble to do this with just find/replace
[21:54:01] <iive> Dark_Shikari: can't you use macro?
[21:56:14] <kierank> enkidu: have you profiled ffserver?
[22:01:50] <enkidu> kierank: no, how can I achieve it?
[22:02:50] <kierank> oprofile
[22:03:08] <spaam> kshishkov: KotH har konstiga ider ibland :)
[22:04:12] <enkidu> kierank: you are talking to oprofile newbie
[22:07:28] <bcoudurier> don't rewrite half of ffserver
[22:08:04] <enkidu> bcoudurier: anyways, I had to do something with zombie connections.
[22:08:38] <bcoudurier> zombie ?
[22:08:43] <bcoudurier> like Z processes ?
[22:09:24] <bcoudurier> back in days I used to spawn 10000 wgets on ffserver and there was no leak
[22:09:48] <enkidu> maybe - if you mean "established state, zero rate for more than one minute"
[22:10:17] <bcoudurier> ffserver is not threaded
[22:10:31] <bcoudurier> following the connection states
[22:10:36] <bcoudurier> and addressing the leak should be easy
[22:10:57] <bcoudurier> and straightforward
[22:11:19] <enkidu> bcoudurier: I have had done it with one if in http_send_data
[22:11:23] <bcoudurier> also the process is so leightweight that you can run it in valgrind with 500 connections
[22:12:01] <enkidu> if (compute_datarate(...) == 0 && c->state == HTTP_SEND_DATA) return -1
[22:12:06] <enkidu> or something like that
[22:12:40] <bcoudurier> why is that needed ?
[22:12:45] <bcoudurier> the client may still be connected
[22:12:51] <bcoudurier> tcp timeout is pretty long
[22:13:42] <enkidu> bcoudurier: it is, but clients are not closing connections
[22:14:06] <enkidu> I have seen connections kept up by ffserver even, when remote was turned off fo more than hour
[22:19:43] <bcoudurier> humm, no write error nor select error ?
[22:20:09] <enkidu> no
[22:20:16] <bcoudurier> weirdo
[22:20:20] <enkidu> ffserver seems to be waiting for ACK
[22:22:06] <bcoudurier> maybe POLLERR is not correctly checked
[22:22:19] <enkidu> maybe, dunno
[22:25:18] <bcoudurier> you might want to look at the poll call, and what happens next
[22:27:24] <enkidu> you are talking to guy, who havent had his coffee for a long time
[22:36:44] <enkidu> kierank - could u help me with oprofile?
[22:37:28] <kierank> read the website; i haven't used it for ages
[23:12:11] <enkidu> only thing, i found out, that most interrupts / cycles / etc were caused in http_server
[23:14:36] <enkidu> why it is not strange
[23:26:58] <hyc> even if you use TCP_KEEPALIVe it will take upwards of two hours to detect a connection that died because the client was powered off
[23:27:14] <hyc> pretty sure the default timeout is 7200 seconds
[23:28:13] <enkidu> ow
[23:28:28] <enkidu> can it be tweaked somehow?
[23:30:17] <bcoudurier> yes
[23:30:28] <bcoudurier> tcp_keepalive_interval
[23:31:19] <enkidu> time
[23:31:22] <enkidu> not interval
[23:32:16] <bcoudurier> probably
[23:33:46] <enkidu> okay, so I have now to fight workload
[23:37:17] <enkidu> nearly half of it is vdso