[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... [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@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@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-librar... [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-5f43a93c2f0f571c44f4dae1... [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@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_spe... 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#l22... ← 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@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@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@mansr.com> [22:59:38] <CIA-36> ffmpeg: Mans Rullgard <mans@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