[FFmpeg-devel-irc] IRC log for 2011-03-11

[irc at mansr.com]

[00:00:08] <kierank> wow
[00:00:21] <kierank> didn't know there was a new one
[00:01:04] <ruggles> mru: since half the bands are only 1 coeff, do you think it would speed up the function to unroll and hardcode the start/end of the inner loop?
[00:01:14] <kierank> Sean_McG: is there a diff anywhere
[00:01:27] <Sean_McG> file diff? probably not
[00:01:58] <kierank> well something showing the new bits
[00:02:30] <Sean_McG> "A/52:2010 clarified several areas of ambiguity in A/52B identified by CEA working group R4.3 WG12. Additional
[00:02:33] <Sean_McG> items were identified by TSG/S6 members and subsequently addressed."
[00:02:49] <kierank> yeah
[00:02:51] <kierank> just saw that
[00:02:54] <ruggles> really? I didn't know that. the ETSI version is newer, but i think it's still 2008.
[00:03:11] <Sean_McG> this was November 2010
[00:04:16] <kierank> still doesn't specify e-ac3 t-std...
[00:04:31] <ruggles> t-std?
[00:04:39] <kierank> transport stream system target decoder
[00:04:53] <kierank> buffering model for transport streams
[00:05:34] <ruggles> ah
[00:06:50] <mru> ruggles: I did unroll it
[00:07:43] <ruggles> mru: oh, ok. i'm curious to see it.
[00:10:44] <mru> what do you think is the best way to integrate it?
[00:20:12] <ruggles> mru: if the band number is <= 27 we should be able to calculate the number of bands to loop with 1 coeff rather than re-checking band_start_tab[] for every band
[00:21:41] <ruggles> same for the rest, calculate number of bands with the same size and where to stop before doing the inner loop
[00:23:00] <ruggles> it's 1x18, 3x7, 6x6, 12x4, 24x5. depending on where you start and end of course.
[00:35:15] <ruggles> and if the non-zero start coeff makes it too expensive, we can special-case the coupling channel (or enhanced coupling channel)
[00:42:13] <j0sh> kshishkov: ping
[00:48:23] <mru> http://www.cs.purdue.edu/homes/dec/essay.criticize.html
[00:50:53] <Sean_McG> hahaha! "Wasn't all this done years ago at Xerox PARC?"
[00:59:37] <j0sh> for NEON long operations, if i do something like vaddl.u8 Qd, Dn, Dm, will the result in Qd be 16-bit?
[00:59:56] <mru> yes
[01:00:01] <mru> that's the point
[01:00:24] <j0sh> alright cool
[01:01:44] <roxfan> long = result is twice as long
[01:01:50] <roxfan> narrow = result is twice as short
[01:02:32] <mru> now explain wide
[01:03:06] <j0sh> result and first operand are twice the width of the 2nd
[01:03:31] <roxfan> wide is 2x = 2x * 1x
[01:03:31] <j0sh> vaddw Qd, Qn, Dm
[01:04:30] <mru> you were supposed to give an answer of the form "wide = result is twice as ..."
[01:04:41] <roxfan> sorry :(
[01:05:00] <mru> I know what it does...
[01:05:46] <j0sh> also, if i barrel shift on a long instruction, will it overflow or is the result placed in the result
[01:05:54] <mru> huh?
[01:06:28] <j0sh> say i do vaddl.u8 q0, d3, d4, lsl 3
[01:06:30] <roxfan> neon insns can't use barrel shifter
[01:06:37] <mru> eh what?
[01:06:39] <j0sh> ohh ok
[01:06:44] <mru> of course it's a barrel shifter
[01:06:53] <mru> do you guys know what that means?
[01:07:05] <roxfan> but afaik you can't use it the same way as with gprs
[01:07:36] <mru> neon instructions don't have an inline shifter for one operand, no
[01:07:38] <j0sh> mru: the shift is applied before the operation takes place
[01:07:47] <mru> that's not what barrel shift means
[01:08:11] <mru> a barrel shifter is a unit that can shift by any number of bits in one clock cycle
[01:08:20] <mru> as opposed to iterating one bit at a time
[01:08:45] <mru> the term says nothing about how it's wired into a system
[01:09:05] <j0sh> but that's the behavior of the shifter on arm, no?
[01:09:30] <mru> all modern cpus have barrel shifters
[01:09:47] <roxfan> j0sh: there are two-op shift instructions in neon however
[01:10:04] <roxfan> hmm there's even Vector Shift Right and Accumulate
[01:10:05] <j0sh> alright i just assumed that to mean the shift could be done as part of the instruction
[01:11:01] <mru> so you learned something today
[01:11:25] <j0sh> i try to every day :)
[01:11:31] <Sean_McG> ^^;
[01:12:01] <roxfan> cuter pictures http://blogs.arm.com/software-enablement/277-coding-for-neon-part-4-shifting-left-and-right/
[01:12:04] <roxfan> *cute
[01:13:14] <j0sh> sweet
[01:13:29] * mru prefers reading the ref manual
[01:13:53] <Kovensky> up up down down left right left right a b
[01:14:18] <roxfan> at times ref manual is too detailed and you don't see the big picture
[01:14:36] <mru> then you read it again
[01:14:38] <j0sh> yeah and with the manual i'm not sure where to start sometimes
[01:14:45] <j0sh> it's good for what it is, a reference
[01:15:13] <j0sh> but noobs like me appreciate the pictures starting out :)
[01:15:27] <mru> the ref manual has pictures too
[01:17:51] <j0sh> hm most of the diagrams i see are instruction encodings
[01:18:10] <mru> vzip has some pictures iirc
[01:18:12] <mru> and vrev
[01:18:46] <j0sh> ah, indeed
[01:19:39] <mru> the instruction listings aren't all there is to the manual either
[01:22:01] <mru> ruggles: anyway, how do you think it's best to plug in asm for bit_alloc_calc_bap?
[01:22:48] <Sean_McG> holy shit it's after 8PM already
[01:22:51] * Sean_McG should eat!
[01:24:14] <ruggles> mru: probably add to ac3dsp for after the -960 case and pass AC3DSPContext to the shared function.
[01:24:37] <mru> why do the 960 case in C?
[01:24:40] <mru> it's trivial
[01:24:47] <ruggles> what, just call memset?
[01:25:00] <mru> what did you expect the compiler to do?
[01:25:50] <mru> now that you mention it though, it can probably be done more efficiently
[01:26:01] <ruggles> well, yeah i guess so. i haven't done much asm except some simple x86 simd.
[01:26:42] <mru> is the bap pointer aligned or anything?
[01:27:21] <ruggles> in the encoder it is. i'll have to double-check the decoder though.
[01:27:54] <ruggles> not aligned in the decoder. but easily can be.
[01:33:14] <CIA-36> ffmpeg: Benjamin Larsson <benjamin at southpole.se> master * r35d7d6f748 ffmpeg/libavformat/isom.c:
[01:33:14] <CIA-36> ffmpeg: Add one more avc intra fourcc and extend the description
[01:33:14] <CIA-36> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[01:44:06] <mru> is there some reason for all aligned arrays being at the end of AC3DecodeContext?
[01:59:31] <mru> hmm, dsputil already has a memset(0, 128) function
[02:01:28] <mru> how often does the -960 case occur anyway?
[03:01:03] <Compn> merbanan : haha! were those emails a requisite of selling live.com to microsoft? :P
[03:01:41] <Compn> or is that bbb's ?
[03:20:39] <BBB> astrange: are you interested in mentoring a -mt project for soc this year, or rather not?
[03:21:21] <BBB> not ffmpeg-mt-based per se, just threading-related, e.g. partition-threading in vp8, or more frame-based threading in various codecs where possible, maybe encoding-mt, ...
[03:21:28] <mru> 18% speedup of ac3enc on arm so far
[03:22:04] <Sean_McG> for when I do the same for altivec, how do I get performance numbers?
[03:22:26] <mru> people still care about altivec?
[03:22:32] <BBB> time ./ffmpeg -i file file.ac3
[03:22:40] <mru> or ffmpeg -benchmark ...
[03:22:45] * Sean_McG shrugs, I do
[03:35:58] <astrange> BBB: i don't think a project touching mpegvideoenc will succeed. i'd be ok with a project touching codecs
[03:36:07] <astrange> let me check the time commitment requirement for mentors
[03:37:49] <BBB> astrange: ok
[03:46:21] <Compn> 1500 lines added to dsputil?
[03:46:42] <Compn> THE BEAST GROWS!
[03:51:59] <Compn> oh nm i read that incorrectly
[03:52:03] <Compn> just moving code around
[03:52:04] <Compn> whew
[05:02:02] <Dark_Shikari> http://www.jwz.org/doc/cadt.html
[05:11:00] <pasteeater> are regressions considered "important" in roundup or is priority more subjective?
[05:12:08] <Dark_Shikari> crashes are important
[05:22:50] <pengvado> anyone know a good library for runtime generation of x86 code?
[05:23:20] <Dark_Shikari> what sort of runtime generation?
[05:23:21] <Dark_Shikari> compilation?
[05:23:25] <pengvado> jit
[05:23:26] <Dark_Shikari> if so, llvm I'd assume
[05:23:37] <Dark_Shikari> what are you jitting this time around?
[05:23:44] <pengvado> desmume
[05:23:50] <Dark_Shikari> .... desmume is entirely interpreted?
[05:23:54] <pengvado> yes
[05:23:58] <Dark_Shikari> jesus fucking christ
[05:24:02] <Dark_Shikari> no wonder it's so damn slow
[05:24:19] <Dark_Shikari> Hasn't ARM->x86 emulation been done well somewhere before?
[05:24:50] <Dark_Shikari> My guess would be LLVM would probably be the best approach, but it might be rather heavy a dependency.
[05:24:57] <pengvado> including timings? and dma?
[05:25:10] <Dark_Shikari> a lot of games seem to work without emulating timings
[05:25:15] <Dark_Shikari> I disabled that first
[05:25:23] <Dark_Shikari> DMA can be interpreted
[05:25:26] <Dark_Shikari> http://stackoverflow.com/questions/1413734/most-portable-jit-compiler-library
[05:25:34] <pengvado> without *accurate* timings, sure
[05:25:35] <Dark_Shikari> libjit, llvm
[05:25:48] <pengvado> even with everything disabled it still keeps track of a static cost per opcode
[05:26:14] <Dark_Shikari> then I would do the following:
[05:26:25] <Dark_Shikari> 1) Track every possible entry point and exit point to the code
[05:26:38] <Dark_Shikari> 2) Calculate the runtime of all chunks of code in there, cache it
[05:26:57] <Dark_Shikari> 3) If there's a register jump, jump to a set of code that handles that and sees if that exact indirect jump has been taken before
[05:27:04] <Dark_Shikari> 4) sum up these chunks as you cross the code
[05:27:17] <drv> there's libcpu, but it's not anywhere near finished afaik
[05:27:18] <Dark_Shikari> ... or you could just add an "add" for every single instruction you use.
[05:27:30] <Dark_Shikari> doubling the total instruction count
[05:27:50] <Dark_Shikari> ... you planning to get this committed?
[05:28:03] <pengvado> dunno
[05:28:33] <Dark_Shikari> libjit seems to be pretty nice
[05:28:37] <Dark_Shikari> dunno if llvm is better
[05:29:48] <pengvado> tried libjit. it incurs some overhead by exposing a risc isa. also can't omit frame pointers.
[05:30:21] <Dark_Shikari> "exposing a risc isa"?
[05:30:25] <pengvado> in principle it would run an optimization pass, but it doesn't
[05:30:33] <Dark_Shikari> .... oh blagh.
[05:30:35] <pengvado> just translates each risc instruction independently to x86
[05:30:39] <Dark_Shikari> ok, then llvm is much better
[05:31:07] <Dark_Shikari> I've used llvm assembly for a class assignment, it was pretty simple
[05:35:06] <Dark_Shikari> iirc it's not too different from jvm assembly
[05:35:08] <Dark_Shikari> it's stack-based
[05:35:18] <Dark_Shikari> or wait, no
[05:35:19] <Dark_Shikari> it's register based
[05:35:23] <Dark_Shikari> SSA
[05:35:39] <Dark_Shikari> Now I remember having to write the SSA stuff.
[05:35:54] <Dark_Shikari> useful trick for writing SSA assembly easily: simply make a new variable with every single line.
[06:04:51] <astrange> code-copying is an easy way to write a jit
[06:05:09] <astrange> it's basically what n64 emus do, they don't do register allocation or anything
[06:05:25] <astrange> and i'm afraid llvm might be too slow for complex unclean inputs
[06:12:03] <Dark_Shikari> astrange: ?
[06:12:14] <astrange> ? about what?
[06:12:19] <Dark_Shikari> unclean input?
[06:12:47] <astrange> translating a DS instruction trace into llvm's SSA IR produces a large number of IR entries
[06:13:00] <Dark_Shikari> Is a DS game that large, instruction-wise?
[06:13:16] <Dark_Shikari> ... though a ROM is like, 512MB.
[06:13:19] <Dark_Shikari> er, 256MB
[06:13:24] <astrange> not even that, you recompile a straight-line block as you jump to it
[06:13:25] <pengvado> 150000 instructions
[06:13:44] <astrange> static recompilation of the whole game at once usually isn't done
[06:13:50] <Dark_Shikari> I don't see something wrong with a preprocessing pass to recompile the game once
[06:14:24] <astrange> they might use self modifying code
[06:14:28] <pengvado> while most of the code is in rom, a little bit is executed from writable memory
[06:14:39] <Dark_Shikari> the game itself does code generation?
[06:14:55] <Dark_Shikari> self-modifying code sounds much scarier than generated code
[06:15:32] <pengvado> not *very* self-modifying
[06:15:49] <pengvado> I've seen at most 2 different contents of any given executed address
[06:16:42] <pengvado> but yes, I can't just preprocess
[07:34:43] <j0sh> how do you set the value of a neon register in gdb?
[07:39:18] <j0sh> nvm i rtfm'd
[08:03:11] <thresh> where is your japan now
[08:03:17] <thresh> http://pit.dirty.ru/lepro/2/2011/03/11/45754-103441-5f43a93c2f0f571c44f4dae1ce4cf97f.jpg
[08:03:26] <Dark_Shikari> welcome to 2 hours ago
[08:03:54] <thresh> our bytes are usually delayed
[08:04:08] <kshishkov> thresh: неужто кто-то бросил валенок в пульт?
[08:04:30] <thresh> kshishkov: ага, "чуть-чуть изменили магнитное поле Земли"
[08:04:51] <thresh> незачем было Курилы требовать обратно и флаги жечь!
[08:07:36] <j0sh> kshishkov: are the y/u/v offsets in swscale (that are used for mmx) safe to reuse for neon, provided i follow the same algorithm?
[08:08:16] <j0sh> from a preliminary inspection they seem OK
[08:08:29] <kshishkov> not sure
[08:09:01] <kshishkov> at least for other struct offsets were different depending on whether you used Apple toolchain or sane toolchain
[08:10:13] <j0sh> the values are loading no problem, at least under gcc/linux
[08:10:24] <j0sh> havent tested on iOS yet
[08:10:28] <kshishkov> exactly
[08:10:46] <j0sh> i guess i'm not sure about the numbers themselves
[08:11:08] <j0sh> like, the bfin algorithm is similar but uses a shift of 2 (x4) and the offsets are different accordingly
[08:11:42] <kshishkov> just add av_log(NULL,0,"offset is %d\n",(char*)&context->urCoef - (char*)context)
[08:11:49] <j0sh> although i'm not sure where the coeff/offset numbers come from, and why they work. they seem to be pulled out of thin air
[08:13:36] <kshishkov> Ramiro was documenting them
[08:13:43] <cartman> moin
[08:13:50] <kshishkov> grüß dich
[08:13:55] <j0sh> hmmm the tsunami warning alarms just went off here
[08:14:21] <kshishkov> cartman: you should've switched greeting, ask local people if you don't believe me
[08:14:38] <cartman> kshishkov: ok :)
[08:14:43] <cartman> j0sh: japan?
[08:15:05] <j0sh> cartman: hawaii
[08:15:13] <thresh> same stuff for Russian lands on Pacific coast
[08:15:22] <KotH> i've read japan?
[08:15:28] <kshishkov> j0sh: offset is the difference between address of field in structure and structure address itself
[08:15:34] <thresh> KotH: there is no japan now
[08:15:40] <KotH> though!
[08:15:41] <cartman> KotH: Earthquake in Japan
[08:15:43] <cartman> big one
[08:15:46] <KotH> huh?
[08:15:51] <j0sh> kshishkov: ohh, so that's what it is for
[08:16:08] <kshishkov> j0sh: yep
[08:20:33] <Tjoppen> ooh, 9-10 bit H.264 decoding posted
[08:20:53] <Tjoppen> irock: is that pullable from your github repo as well?
[08:20:59] <Dark_Shikari> Yuuuup, 10-bit decoding \o/
[08:21:27] <Tjoppen> because when I tried it a few days ago it crashed on samples coming from media composer
[08:21:59] <av500> does 10bit make my scen rips faster?
[08:22:02] <av500> scene
[08:22:14] <Tjoppen> the ones I already uploaded to mplayerhq I believe
[08:22:18] <kshishkov> Dark_Shikari: when those patches are applied I'll have more evidence that FFmpeg is a Swedish project
[08:22:26] <Tjoppen> SWEDISH STYLE
[08:22:27] <Dark_Shikari> \o/
[08:23:16] <kshishkov> Tjoppen: thanks for reminding
[08:24:25] <peloverde> greetings hobos and ninjas!
[08:24:32] <thresh> what's the technical advantage of 10bit?
[08:24:58] <kshishkov> peloverde: and AACenc writers!
[08:24:59] <spaam> 2bits more then 8
[08:27:20] <Tjoppen> wasn't there also something about 10-bit encoding surprisingly being more efficient for 8-bit data? I recall some discussion about that a while back
[08:27:46] <Tjoppen> like the improved accuracy making x264 happier
[08:28:01] <Dark_Shikari> 10-15% better compression
[08:28:04] <Dark_Shikari> helps more at lower bitrates
[08:30:00] <irock> Tjoppen: I've refactored the code heavily over the last few days. maybe I pushed code that was incomplete. else I'd appreciate a proper bug report :)
[08:30:27] <Tjoppen> I can try again later today
[08:30:40] <irock> ok, thx
[08:52:54] <j0sh> i'm being evacuated
[08:52:57] <j0sh> wish me luck
[08:53:29] <thresh> hm, hawaii is far far away from japs
[08:57:42] <thresh> kshishkov: http://comicsia.ru/i/41/d9-16857.jpeg
[08:58:38] <Tjoppen> lol
[08:58:56] <kshishkov> thresh: да, торсионщики сильны
[08:59:29] <thresh> Tjoppen: can you read russian?
[08:59:41] <thresh> kshishkov: промазали немного, правда
[08:59:47] <Tjoppen> no, but the absence of NA is quite obvious
[08:59:59] <Tjoppen> well, I understand да :)
[08:59:59] <thresh> yeah, but most fun is written
[09:00:08] <Tjoppen> I see
[09:01:36] <thresh> "the scheme of alleged geological changes as a result of the gravitational corrections by 'A-241' device
[09:02:01] <Tjoppen> doomsday device?
[09:05:17] <Tjoppen> irock: ffplay crashes, decoding is a bit off (at least when transcoding to a bunch of jpegs)
[09:08:57] <irock> Tjoppen: I know ffplay doesn't like the patch. I guess I'll have to fix that..
[09:10:06] <Tjoppen> ok. there also seems to be something off when converting the pixel format as well (see the sample I PM:ed)
[09:22:17] <spaam> irock: how do you test it ? using mplayer ?
[09:24:25] <irock> I've tested it with x264. bitexact to dump-yuv for everything I've tried
[09:54:45] <siretart> BBB: there, first sandy fate runs: http://fate.ffmpeg.org/x86_64-avx-linux-gcc-4.5/
[11:22:29] <Mathias2> I just wanted to submit a bug...
[11:22:34] <Mathias2> so I registered on the bugtracker
[11:22:41] <Mathias2> clicked the activation link in my email
[11:22:46] <Mathias2> I got an error there...
[11:23:12] <Mathias2> but I still logged in and the first thing I was presented with is the complete user list with email adresses and phone numbers
[11:27:10] <Mathias2> Nobody interested in this kind of critical security flaw?
[11:28:46] <Dark_Shikari> people are probably alseep
[11:28:50] <Dark_Shikari> wait until later
[11:29:58] <Mathias2> I will try it later...
[11:30:00] <siretart> lu_zero: ^^
[11:31:11] <kshishkov> siretart: do you care to push new decoder?
[11:32:01] <siretart> kshishkov: sorry, I'm about to leave for skiing weekend with work collegues
[11:32:27] <siretart> just returned from a business trip last night
[11:33:51] <kshishkov> that sucks
[11:34:32] <lu_zero> Mathias2: which error?
[11:35:25] <Mathias2> The "I can see everyones email and phone number on the bug tracker" security issue
[11:35:37] <Mathias2> and probably change it too
[11:36:08] <Mathias2> (no, there is no save button, so I probably can't change them)
[11:36:38] <Compn> people put their phone numbers into the bug tracker ? ;P
[11:36:58] <Mathias2> just like every 20th
[11:37:35] <Mathias2> But I'm not supposed to see everyones email right?
[11:37:53] <Compn> all our emails are public anyways
[11:38:03] <Compn> how else are people supposed to report bugs
[11:38:10] <Mathias2> I can also see the SHA hashes of passwords that were changed
[11:38:25] <Mathias2> aren't they supposed to use the bugtracker?
[11:38:26] <Compn> https://roundup.ffmpeg.org/user
[11:38:30] <Compn> thats what you are talking about ?
[11:38:33] <Compn> the userlist ?
[11:38:55] <Mathias2> thats it
[11:39:03] <Mathias2> is that supposed to be visible to everyone?
[11:39:11] <Mathias2> with mail, changed password hashes and so on?
[11:39:34] <Compn> i dont see changed password hashes
[11:39:39] <Mathias2> https://roundup.ffmpeg.org/user10
[11:39:42] <Compn> sounds like a bug
[11:40:33] <Compn> you can report it on the bugtracker maybe :)
[11:40:45] <Compn> as you can see, my password is now set to *encrypted* :)
[11:40:52] <Mathias2> :)
[11:41:07] * Compn finds another roundup to look at
[11:41:59] <Compn> ah forgot have to login
[11:42:15] <Compn> Mathias2 : anyways, mru or lu_zero would be the ones to ask about it
[11:49:13] <lu_zero> Mathias2: what's the problem exactly?
[11:53:11] <Compn> Mathias2 can see emails and password hashes! :P
[11:53:39] <Mathias2> you know when I register somewhere, I'm kinda used to that my email is not published to everyone else
[11:54:08] <Mathias2> the hashes are salted so probably useless, so the security implications are probably not that severe
[11:54:24] <Mathias2> but still, its not what I would expect to happen
[11:54:54] <kshishkov> lu_zero: also can you please push JV decoder?
[12:10:53] <Mathias2> great... now I tried to file the bug report, wrote the text and got an error after submitting
[12:11:09] <Mathias2> and when I get back, the text field is empty...
[12:12:42] <Flameeyes> lu_zero: uhm okay tell me again why we use roundup? :P
[12:13:42] <lu_zero> Flameeyes: because somebody asked vehemently not to use bugzilla
[12:13:52] <Flameeyes> lu_zero: who?
[12:14:05] <lu_zero> michael
[12:14:52] <mru> let's change then
[12:15:00] <mru> recent bugzilla versions are actually quite nice
[12:15:11] <mru> a few years ago they were rather clunkier
[12:15:12] <kshishkov> are they secure enough?
[12:15:17] <mru> who cares?
[12:15:21] <lu_zero> kshishkov: they work fine
[12:15:27] <mru> ooooh, someone can see my bugs!!#!@11!
[12:15:28] <Flameeyes> kshishkov: both me and lu_zero already manage one each
[12:15:32] <lu_zero> and are a breeze to setup
[12:15:39] <Flameeyes> mine's on valid ssl as well
[12:16:14] <kshishkov> mru: have you ever heard of PHP?
[12:16:20] <lu_zero> for that we should ask for a proper certificate
[12:16:37] <mru> php isn't inherently insecure
[12:16:49] <Flameeyes> kshishkov: bugzilla is in Perl
[12:16:59] <mru> it comes (or used to at least) with some rather ridiculous defaults though
[12:17:08] <mru> and there's a lot of really poor code written for it
[12:17:32] <kshishkov> and I heard that mod_php in Apache was secure as a shoelace for padlock
[12:17:46] <mru> maybe
[12:17:49] <mru> but does it matter?
[12:18:01] <thresh> you've never seen mod_perl then
[12:18:13] <mru> well, I don't run apache at all
[12:18:19] <kshishkov> thresh: I cherish my ignorance
[12:18:23] <mru> to much black magic for my liking there
[12:18:28] <Flameeyes> kshishkov: they added support for fcgi in php recently
[12:18:37] <thresh> yeah like years ago
[12:18:48] <thresh> they added support for fpm some time ago
[12:18:50] <kshishkov> Flameeyes: I don't care about PHP
[12:18:51] <mru> php has had fcgi for much more than a year
[12:19:02] <thresh> which is better than spawn-fcgi, for sure
[12:19:21] <iive> wasn't there some security researcher who left php development because others didn't accept his improvements of the security?
[12:19:22] <Flameeyes> to me anything in the past two years is "recently" for what concerns php
[12:19:27] <Flameeyes> I haven't used it directly in over six...
[12:19:33] <thresh> iive: suhosin guy
[12:19:44] <kshishkov> Flameeyes: never used it at all
[12:19:45] <thresh> adding security to a sieve
[12:19:58] <Flameeyes> thresh: heh... and I had to fix suhosin myself at some point...
[12:20:03] <thresh> needless to say, with suhosin patch enabled, almost no webapps do work
[12:20:34] <kshishkov> thresh: в советских реалиях - усилить охрану на проходной, а забор по прежнему не чинить
[12:20:37] <iive> this for me is the definition of  inherently insecure
[12:20:40] <Flameeyes> thresh: like setting up mod_security with the default settings?
[12:21:01] <thresh> Flameeyes: no, just enabling suhosin results in non-working code :)
[12:21:19] <Flameeyes> thresh: no doubt, the bloody thing didn't link in properly to libcrypt to begin with
[12:21:24] <thresh> hehe
[12:21:26] <Flameeyes> and only worked if php was bringing libcrypt in itself...
[12:21:36] * kshishkov wonders why WMAL is not 1st-tier project for gsoc
[12:22:18] <Flameeyes> okay this box is doing a bloody update, not nice to work on... gotta fetch the laptop
[12:22:31] <thresh> kshishkov: because BINK is?
[12:22:43] <kshishkov> thresh: neither is Bink encoder :(
[12:27:52] <thresh> oh, VLC doesnt play bink files
[12:28:05] <mru> fix it!
[12:28:12] <thresh> yes sir
[12:28:41] <kshishkov> mru: can any of you push JV decoder?
[12:29:01] <kshishkov> should be another format that VLC doesn't support
[12:45:33] <thresh> kshishkov: hey, I dont want to recompile full VLC once again just because of you!
[12:46:14] <kshishkov> thresh: it's mostly because of Peter
[12:47:39] <thresh> you sneaky ukrainians
[12:48:33] <kshishkov> thresh: could be worse
[12:48:46] <kshishkov> thresh: sneaky Indians or Chinese
[12:48:53] <thresh> kshishkov: true
[12:49:55] <kierank> thresh: troll ukranian politics
[12:50:46] <kshishkov> kierank: they know only one way to troll - accuse Ukraine of stealing gas
[13:17:26] <thresh> are there any bink samples to test? the ones I randomly picked on samples, do not
[13:18:02] <thresh> hmm, I may need to recompile ffmpeg
[13:18:11] <av500> again?
[13:18:28] <thresh> not VLC this time!
[13:19:15] <pross-au> thresh: there are bink samples in the fate suite
[13:19:34] <kshishkov> thresh: http://samples.mplayerhq.hu/game-formats/bink/
[13:20:41] <pross-au> no bink 'd' samples yet..
[13:21:08] <spaam> pross-au: you know what you have to do.
[13:22:35] <pross-au> Yep. Night!
[13:22:43] <Compn> KotH : oh man this is gonna set anime releases back  ;\
[13:22:57] * Compn wonders if japan is ok
[13:23:16] <kshishkov> pross-au: no worries, I don't have even decoder for it
[13:24:14] <KotH> Compn: dunno.. didnt had time to call my friends overthere
[13:27:03] <spaam> they lost some trafic .. http://www.jpnap.net/english/jpnap-tokyo-i/traffic.html
[13:34:10] <Compn> we had some .jp devels in here didnt we ?
[13:34:13] <Compn> wonder how they are doing
[13:34:25] <JEEB> most of those that are online are alright
[13:34:34] <Compn> Chikuzen : are you in japan ?
[13:34:38] <JEEB> yah, he is
[13:34:53] <Compn> [04:08] <j0sh> i'm being evacuated
[13:34:53] <Compn> [04:08] <j0sh> wish me luck
[13:34:53] <Compn> [04:08] * j0sh (~josh at cpe-24-161-146-104.hawaii.res.rr.com) Quit (Quit: Lost terminal)
[13:34:59] <Compn> ooh hawaii too
[13:35:07] <JEEB> yah, not surprising
[13:35:17] <JEEB> the tsunami's probably going there, too
[13:35:28] * Compn never saw 'japan sinks' movie
[13:36:15] <JEEB> watching TBS live, but afterquakes have been coming in every 20-30min or so
[13:36:50] <kierank> Compn: that's incredibly chilling
[13:39:04] <lu_zero> OUCH
[13:39:45] <thresh> do I need to provide something special to libav to be able to demux&play bink ? now it's like Unknown block type 11 etc spam
[13:40:29] <spaam> bad joke:
[13:40:30] <spaam> "chin up Japan. If you watch Godzilla backwards, it's about a giant lizard who helps rebuild a half destroyed city and then moonwalks back into the ocean"
[13:40:57] <kshishkov> thresh: extradata? codec_tag?
[13:53:58] <thresh> kshishkov: ffplay doesnt set those :P
[13:54:27] <kshishkov> thresh: and yet FFplay works and VLC doesn't
[13:54:36] <kshishkov> thresh: so which is superior?
[13:54:48] <thresh> not really works
[13:55:05] <thresh> ffplay doesnt know anything about xinerama for instance :)
[13:59:41] <thresh> hmm, CGOOD3.bik is ok
[14:01:48] <kshishkov> it's bink-b :)
[14:02:35] <thresh> original.bik is the one causing troubles
[14:07:19] <pengvado> Dark_Shikari: llvm assembly, or C code that generates the internal representation of llvm assembly? the latter is like an order of magnitude more verbose.
[14:41:57] <DonDiego> yo
[14:42:23] <kshishkov> y?
[14:53:10] <lu_zero> ya(wn) ?
[14:54:40] <kshishkov> lu_zero: Yet Another Wasted Night?
[14:57:54] <mru> ruggles: ping
[14:58:10] <ruggles> mru: pong
[14:58:45] <mru> do you know what the distribution of values is typically like in compute_mantissa_size?
[14:58:53] <mru> and can nb_coefs be zero?
[14:59:51] <ruggles> nb_coefs cannot be zero
[15:00:05] <kshishkov> it has hardcoded floor value IIRC
[15:00:15] <ruggles> and do you mean for all mantissas?
[15:00:39] <kshishkov> CPL/LFE/FWB ones :)
[15:01:58] <ruggles> for nb_coefs: minimum 73 max 253 for full-bandwidth channels. 7 for lfe. 36 minimum for coupling i think.
[15:02:31] <ruggles> oh wait, no coupling can be 12
[15:04:04] <ruggles> mru: compute_mantissa_size will depend greatly on the bandwidth. the majority of bits are for mantissas.
[15:04:36] <ruggles> s/bandwidth/bitrate
[15:04:46] <ruggles> well, and bandwidth too i guess
[15:11:15] <mru> that tiny function is using a lot of cpu time
[15:11:22] <ruggles> mru: the exponents and other misc bits have a very narrow range not depending on bitrate. the rest of the bits are mantissas.
[15:17:01] <mru> hah, I'm faster than gcc
[15:17:45] <kshishkov> of course you are
[15:18:03] <kshishkov> not on compiling stage though
[15:22:11] <ruggles> can i compile ffmpeg with manscc?
[15:22:21] <kshishkov> too expensive
[15:22:28] <ruggles> :)
[15:23:09] <mru> probably, yes
[15:25:08] <mru> but I bet it would fly
[16:17:00] <Compn> mms://nhk-world.gekimedia.net/nhkw-highm
[16:17:05] <Compn> watch nhk live in english
[16:17:09] <Compn> evacuation notices
[16:29:17] <lu_zero> kshishkov: poing
[16:40:25] <mru> another 7.5% faster
[16:40:44] <mru> by writing compute_mantissa_size in asm
[16:40:54] <av500> what codec?
[16:40:57] <mru> ac3enc
[16:45:41] * kierank wonders who is funding ac3enc opts
[16:45:50] <mru> ARM
[16:45:53] <kierank> LOL
[16:46:01] <kierank> it seems they don't care about their relationship with dolby then
[16:46:24] <mru> they've suddenly decided that open source matters
[16:46:25] <av500> what does arm want it for?
[16:46:36] <Compn> av500 : dumb ac3 recievers no doubt
[16:46:37] <Compn> :P
[16:47:52] <av500> Compn: can I stop listening to these tsunami warnings now? my coworker are rebelling
[16:48:08] <Compn> av500 : haha, i was looking for a better stream but gave up
[16:48:45] <mru> av500: are they starting a tsunami of their own?
[16:48:58] <mru> av500: btw, don't you have a door to your office?
[16:49:10] <av500> I also have very good speakers
[16:49:34] <mru> s/good/loud/
[16:50:04] <av500> they even make fancy disco lights when loud
[16:51:39] <twnqx> Oo
[16:54:15] <av500> twnqx: overvoltage protection with glow lamps
[17:17:19] <kshishkov> lu_zero: piong
[17:17:54] <mru> ruggles: can the bap pointer passed to compute_mantissa_size be guaranteed one extra element?
[17:18:12] <mru> over-reading by one makes it faster
[17:18:17] <ruggles> mru: yes
[17:18:26] <ruggles> 3 extra elements in fact
[17:18:36] <mru> cool, so I'm safe then
[17:18:40] <ruggles> max nb_coefs is 253
[17:18:54] <mru> and 256 are allocated, I take it
[17:19:01] <ruggles> yes
[17:19:28] <ruggles> 256*6*channels
[17:19:43] <mru> yeah, I noticed they're allocated as one block
[17:20:21] <ruggles> yes, allows processing all at once or separately. and swapping the base pointer around.
[17:20:30] <mru> btw, http://git.mansr.com/?p=ffmpeg;a=shortlog;h=refs/heads/ac3
[17:22:48] <ruggles> awesome
[17:24:00] <lu_zero> kshishkov: do you recall enough of flv?
[17:24:27] <kierank> lu_zero: what do you want to know
[17:24:27] <kshishkov> lu_zero: depends on "enough"
[17:25:00] <lu_zero> trying to get a data stream in flv
[17:25:11] <lu_zero> the spec states something about scriptdata
[17:25:14] <lu_zero> but not much
[17:25:31] <lu_zero> and seems that there isn't a real way to signal it in the headers
[17:26:06] <kshishkov> FLV headers are next to nonexistant
[17:26:19] <kierank> the flv header is three characters
[17:26:37] <kshishkov> wrong
[17:26:49] <kshishkov> they also have one byte to denote streams present
[17:26:52] <lu_zero> there is one for stating if there is video or audio or both
[17:26:55] <kshishkov> and some other junk
[17:27:09] <lu_zero> but I couldn't see a bit for metadata
[17:28:02] <kshishkov> http://www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf_file_format_spec_v10.pdf mentions HasMetadata flag
[17:28:33] <ruggles> mru: nice build system patch. that should be committed.
[17:28:47] <mru> I'll reshuffle those commits later
[17:29:54] <lu_zero> I read the flv pdf looks like it was lacking
[17:32:03] <lu_zero> uhm
[17:32:19] <mru> ruggles: what's the status of your latest batch?
[17:32:41] <lu_zero> I need something useful to encode a generic stream that's not video or audio
[17:33:06] <lu_zero> s/encode/mux-and-signal/
[17:33:20] <ruggles> mru: well, thought i would finish today but my main dev computer is acting weird. i'm working on my laptop, but i'm not as efficient...
[17:33:46] <mru> ok, so you're still working on it
[17:33:55] <mru> just making sure it wasn't sitting in the corner all forgotten
[17:34:09] <ruggles> yes. cleaning it up.
[17:35:37] <kshishkov> lu_zero: IIRC FLV can have generic metadata blob with AS[13]-encoded data
[17:53:28] <lu_zero> kshishkov: that part is more or less clear to me
[17:54:00] <lu_zero> the doubt is how to make ffmpeg show the data stream
[17:54:27] <kshishkov> tere's no way currently
[17:54:42] <kshishkov> script data will be treated as metadata and parsed so
[17:55:25] <kshishkov> the only way is to add there AMF blob handling and to pretend they are data packets
[18:07:24] <lu_zero> so there isn't a sane way
[18:08:24] <lu_zero> either I put a start blob and have ffmpeg look for it on start
[18:08:55] <lu_zero> or hack ffmpeg to always declare the data stream and if it's there or not I'll discover later
[18:15:09] <kshishkov> exactly
[18:16:09] <kshishkov> though IIRC flv demuxer does some parsing at the beginning to find out if streams are really there, so the first dummy blob can help (just with string "ffmpeg_data_stream_present=true" ;)
[18:17:13] <lu_zero> that's the idea
[18:17:24] <lu_zero> but I wasn't that _happy_ of that
[18:18:02] * kshishkov is not happy of FLV overall
[18:23:36] <lu_zero> kshishkov: sadly
[18:29:08] <ruggles> does git have an easy way to "git reset --soft HEAD^" and "git commit -a" with the original commit message so i don't have to copy/paste the commit message?
[18:34:05] <BBB> git --amend -c HEAD?
[18:34:27] <kshishkov> BBB: please push Peter's JV decoder
[18:34:39] <BBB> kshishkov: please fix our vc1 decoder
[18:35:00] <BBB> I'll push stuff this weekend if I get any second off from my wife ;)
[18:35:07] <BBB> for now, I need the vc1 decoder to not suck
[18:35:22] <kshishkov> BBB: IIRC loop filtering order was changed to be bitexact - ironic, isn't it?
[18:35:35] <kshishkov> why?
[18:35:48] <BBB> why not
[18:35:53] <BBB> DonDiego: please fix issue455
[18:36:25] <mru> BBB: -c HEAD is default
[18:36:58] <ruggles> BBB: thanks. i haven't tried using amend
[18:49:45] <iive> kshishkov: 4 down, 4 to go.
[19:10:35] <Dark_Shikari> pengvado: llvm assembly
[19:10:51] <Dark_Shikari> we wrote a program that compiled a basic C-like language into llvm asm
[19:11:03] <Dark_Shikari> llvm asm is like an SSA version of JVM asm
[19:11:15] <Dark_Shikari> As in, our program did the parsing, lexing, and turned it into llvm statements
[19:11:20] <Dark_Shikari> and llvm did the optimizing and assembling
[19:11:32] <Dark_Shikari> we gave LLVM the ssa asm.
[19:11:46] <mru> so you wrote a compiler frontend
[19:12:01] <Dark_Shikari> yes.
[19:23:42] <DonDiego> BBB: no idea what to do about kandalu - they stopped using ffmpeg apparently, but they obviously violated our license in the past
[19:24:10] <DonDiego> at least they claim not to use ffmpeg anymore
[19:24:52] <DonDiego> i haven't checked their programs manually (again) - that's likely quite a bit of work and might require an iphone or a mac
[19:25:38] <Zor> Dark_Shikari: what was your experience with llvm? did it have reasonable APIs, did it optimize well, etc
[19:26:01] <mru> llvm is a compiler like any other
[19:27:36] <mru> with one difference: it is designed to be usable as a library as well
[19:41:04] <Kovensky> 16:11.04 Dark_Shikari: llvm asm is like an SSA version of JVM asm <-- SSA?
[19:42:56] <gnafu> Kovensky: Perhaps one of these:
[19:42:57] <gnafu> http://en.wikipedia.org/wiki/SSA#Computing_and_data_analysis
[19:42:57] <gnafu> ?
[19:43:15] <gnafu> I'm guessing this one:
[19:43:16] <gnafu> http://en.wikipedia.org/wiki/Static_single_assignment_form
[19:44:07] <gnafu> And the "Compilers using SSA form" section mentions LLVM, so I'm going to increase my confidence to 95-99%.
[19:47:02] <lu_zero> kshishkov: which is the thread I should look for?
[19:53:01] <Dark_Shikari> Zor: we didn't handle that part of it, the professor wrote the interface
[19:53:03] <Dark_Shikari> or actually
[19:53:05] <Dark_Shikari> we outputted raw asm
[19:53:08] <Dark_Shikari> and just ran llvm on that asm
[19:53:13] <Dark_Shikari> so not even our professor did.
[19:53:22] <Dark_Shikari> So we didn't actually call the lib, but it's probably not very different
[19:54:51] <Zor> I'm contemplating using it in a language-neutral VM
[20:09:00] <mru> ruggles: ping
[20:09:30] <ruggles> mru: pong
[20:09:56] <mru> extract_exponents is my new victim
[20:10:39] <ruggles> ok. notice the patch set i'm working on modifies that.
[20:11:00] <ruggles> gets rid of exp_shift
[20:11:04] <mru> cool
[20:11:14] <mru> right, I remember that
[20:11:42] <ruggles> also, some of these functions will need to take start/end instead of nb_coefs for channel coupling
[20:12:09] <ruggles> now start is 0, but coupling channel does not start at 0
[20:12:13] <mru> count is just a subtraction away
[20:13:36] <ruggles> indeed. but the start pointer won't be aligned.
[20:13:46] <mru> so be it
[20:14:20] <ruggles> just letting you know in case that affects how you're implementing it
[20:14:48] <mru> unaligned load/store is slower of course
[20:14:58] <mru> but if that's how it has to be...
[20:17:00] <mru> the patch you already posted just gets rid of exp_shift
[20:17:12] <mru> which simply means there's one thing less to do
[20:18:13] <mru> how far away is the final version of that patch?
[20:20:34] <ruggles> mru: i think my computer might fixed now *crossing my fingers* so i can send a new patch within an hour or so
[20:20:46] <mru> great
[20:21:35] <DonDiego> BBB: your opinion on kandalu?
[20:45:53] <ubitux> do you guys plan to make a sws_scale2() someday in order to change the crazyness of the const in the prototype?
[20:46:47] <ubitux> the src parameter is quite annoying
[20:48:51] <mru> it's _all_ annoying
[20:49:49] <kshishkov> at least it's well optimised for NEON
[21:25:03] <vcs> I know this is not the vlc channel, but why would the -ss parameter work on ffplay (i support seeking and give all streams a duration), but not when i build into vlc? the bar just stays at once place and when it seeks, it just stops playing like it hit the end of the file
[21:28:05] <vcs> i based my demultiplexer on avidec.c, and seeking/duration with avi files work fine
[21:38:44] <ubitux> http://git.ffmpeg.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;hb=HEAD#l2221 ← can anyone tell me why is there this exception here?
[21:39:18] <kshishkov> SBR?
[21:40:09] <ubitux> is it the only codec in this case?
[21:41:04] <ubitux> (http://en.wikipedia.org/wiki/Spectral_band_replication ?)
[21:41:12] <mru> because lavf is _all_ exceptions
[21:41:35] <ubitux> i was just surprised to find this exception here
[21:41:50] <kierank> if you try and create libraries to handle all types of formats/codecs you're bound to have exceptions
[21:50:44] <ubitux> (is it normal to have access to the whole user list in the roundup?)
[21:52:42] <ubitux> it seems i have more permissions than i should have
[21:53:10] <ruggles> mru: sending ac3 patch set soon. just need to run Atom benchmarks.
[21:53:10] <ubitux> like removing messages or access to the whole user list
[21:53:20] <Mathias2> I asked the same question about the permissions earlier this day :)
[21:53:48] <mru> ubitux: if you don't want people to know somthing about you, don't write it on the bloody internet
[21:54:23] <Mathias2> but how am I supposed to send in bugreports, when the bugtracker needs registration and a valid email address?
[21:54:24] <ubitux> what about the remove option?
[21:54:41] <mru> talk to lu_zero about those things
[21:54:45] <ubitux> ok
[21:54:45] <Mathias2> plus, how should I know that when I register on the bugtracker, my email is visible to everyone?
[21:55:00] <mru> you should assume _everything_ on the internet is
[21:55:29] <Mathias2> youre right there...
[21:55:45] <Mathias2> still, IMO it should be changed
[21:55:59] <mru> you can always register with a throwaway gmail address or something
[21:56:29] <Mathias2> I do that for services I don't know
[21:56:39] <Mathias2> but I thought ffmpeg are not the bad guys, so what the hell
[21:59:38] <Dark_Shikari> email addresses are for people to contact you
[21:59:47] <Dark_Shikari> >_>
[22:04:25] <mru> we're not the bad guys
[22:04:30] <mru> did we ever send you spam?
[22:13:05] <Mathias2> you didn't send me spam, but everyone that registers can send me spam
[22:14:44] <Dark_Shikari> Um, it's an email address.  It's on the internet.  People can spam you.
[22:14:51] <Dark_Shikari> And they will nicely go into your spam filter.
[22:14:54] <Dark_Shikari> And you will never see them again.
[22:16:29] <Mathias2> well since a few months ago spammers started to know my real name I don't have much to loose anyways
[22:17:01] <Mathias2> was because a show where I bought somehow lost their database...
[22:17:14] <mru> I get thousands of spam mails _every day_
[22:17:42] <mru> one or two of those sneak through the filters far enough that I see them
[22:17:47] <mru> but still in the spam box
[22:17:57] <Mathias2> congratulations, I hope you can spare me the joy
[22:18:30] <mru> I've never tried to hide my email addresses
[22:18:44] <mru> and every address I've used since 1999 still works
[22:19:00] <mru> and I don't have a spam problem
[22:28:50] <ruggles> mru: after the patches i sent, extract_exponents() can operate on the whole buffer instead of one block at a time.
[22:29:03] <mru> even better
[22:59:20] <CIA-36> ffmpeg: Mans Rullgard <mans at mansr.com> master * r3f8040db3e ffmpeg/configure: (log message trimmed)
[22:59:20] <CIA-36> ffmpeg: configure: improve pkg-config support
[22:59:20] <CIA-36> ffmpeg: This adds helper functions for checking packages with pkg-config
[22:59:20] <CIA-36> ffmpeg: and managing the associated flags.
[22:59:20] <CIA-36> ffmpeg: Note that pkg-config use is still discouraged due to widespread
[22:59:21] <CIA-36> ffmpeg: poor practices resulting in broken flags in many situations. A
[22:59:22] <CIA-36> ffmpeg: few badly designed packages require flags only obtainable using
[22:59:33] <CIA-36> ffmpeg: Mans Rullgard <mans at mansr.com> master * r4fa18c5666 ffmpeg/configure:
[22:59:33] <CIA-36> ffmpeg: configure: use pkg-config helpers
[22:59:33] <CIA-36> ffmpeg: This makes existing pkg-config uses as well as the libsdl checks
[22:59:33] <CIA-36> ffmpeg: use the new pkg-config helper functions, which should be more
[22:59:34] <CIA-36> ffmpeg: robust against broken systems.
[22:59:34] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:59:38] <CIA-36> ffmpeg: Mans Rullgard <mans at mansr.com> master * redaf1ae276 ffmpeg/configure: (log message trimmed)
[22:59:38] <CIA-36> ffmpeg: configure: allow checking multiple functions in check_func_headers()
[22:59:38] <CIA-36> ffmpeg: This makes it possible to pass a space-separated list of functions
[22:59:38] <CIA-36> ffmpeg: to check_func_headers and check_lib2. If any function is missing,
[22:59:39] <CIA-36> ffmpeg: none are enabled as available, so this should only be used for
[22:59:39] <CIA-36> ffmpeg: all-or-nothing sets, i.e. groups in which none will be used if any
[22:59:40] <CIA-36> ffmpeg: one is missing.
[23:03:22] <asdf1234> in justin's last patch, if this is for performance, shouldn't the first jz in ac3_%1shift_int%2_%4 be moved out? saves a call
[23:05:53] <mru> ruggles: ^^
[23:08:14] <peloverde> I'm freeeeeeeeeeeeeeeeeeeeeeeeeeeeee
[23:08:21] <mru> congrats
[23:09:32] <iive> ?
[23:09:50] <Dark_Shikari> BBB: ping
[23:12:50] <asdf1234> ruggles: also, why align 8 vs something else?
[23:13:12] <mru> you'd rather have 7 or 9?
[23:14:24] <asdf1234> how about 16 or 4? why 8?
[23:19:33] <ruggles> asdf1234: that's what is fastest in all the tests i did
[23:22:33] <ruggles> asdf1234: i'll try moving the check out. i think it was slower when i first wrote the int16 version a while ago. but it's worth re-testing.
[23:22:39] <DonDiego> peloverde: ?
[23:24:06] <peloverde> today was my last day at zoran
[23:26:16] <peloverde> I have the whole weekend to work on whatever I want without any employment agreements hampering me
[23:27:32] <DonDiego> :)
[23:27:47] <gnafu> peloverde: Their website looks cheesy.
[23:27:53] <DonDiego> there's plenty of stuff awaiting review...
[23:28:12] <mru> peloverde: when do you start your new job?
[23:28:18] <kierank> peloverde: where are you going?
[23:28:19] <DonDiego> i'll try to take some time off when i'm back from travelling...
[23:28:57] <gnafu> Like, there's a green laser blowing up (communicating with?) a satellite, and a bunch of smiling faces.
[23:29:08] <peloverde> I start Monday with these people: http://www.youtube.com/watch?v=Tlmho7SY-ic
[23:29:29] <peloverde> I was supposed to have most of this week to myself but I let zoran pull me back for it
[23:31:04] <gnafu> peloverde: Oh, that's right.  Are you going to help with integrating xvp8 into YouTube's workflow?  ;-)
[23:32:44] <kierank> good to see youtube recognising ffmpeg
[23:33:03] <mru> I don't see that they are
[23:33:11] <kierank> they do privately anyway
[23:38:59] <asdf1234> ruggles: ok, just wondering. i haven't run tests either
[23:44:07] <asdf1234> ruggles: i don't think you need that arg if you move out the check for that matter
[23:45:03] <asdf1234> oh nvm
[23:55:13] <mru> can we just decide on something soon?
[23:55:20] <mru> this is blocking my work
[23:56:54] <Dark_Shikari> Anyone want to bench my vp8 decoder patch?
[23:56:58] <Dark_Shikari> My computer has too high stddev to do it