Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2010

1 participants
22 discussions

IRC log for 2010-07-30
by irc＠mansr.com 31 Jul '10

31 Jul '10

[00:06:05] <CIA-92> ffmpeg: stefano * r24585 /trunk/configure: (log message trimmed) [00:06:05] <CIA-92> ffmpeg: Make pkgconfig_generate() explicitly return 0 in instead of returning [00:06:05] <CIA-92> ffmpeg: without value when the target library is disabled. [00:06:05] <CIA-92> ffmpeg: If it does not explicitly return 0, when the last library is disabled [00:06:05] <CIA-92> ffmpeg: (swscale), the final "configure" exit value is 1, even if the [00:06:06] <CIA-92> ffmpeg: configure script is successfully executed. So it breaks scripts that [00:06:07] <CIA-92> ffmpeg: invoke configure and rely on 0 for success and 1 for failure. [00:30:40] <CIA-92> ffmpeg: stefano * r24586 /trunk/libavfilter/ (avfilter.h defaults.c): [00:30:41] <CIA-92> ffmpeg: Make avfilter_default_get_video_buffer() use functions in [00:30:41] <CIA-92> ffmpeg: libavcore/imgutils.c rather than ff_fill_linesize() and [00:30:41] <CIA-92> ffmpeg: ff_fill_pointer(). [00:30:41] <CIA-92> ffmpeg: Also remove a dependency on libavcodec. [01:50:45] <Dark_Shikari> BBB: Try http://software.intel.com/en-us/articles/intel-software-development-emulato… [01:50:53] <Dark_Shikari> This should let you develop ssse3 code on your core 1. [01:51:00] <Dark_Shikari> It's fast enough to run x264's checkasm. [01:51:02] <Dark_Shikari> in a few seconds [01:52:10] <BBB> huh? [01:52:17] <BBB> I already ordered my new macbook [01:52:23] <BBB> it's arriving saturday [01:52:38] <BBB> much easier, and then it'll start to scratch an itch [01:54:03] <BBB> your blog reply guy (last one) is right though, I'm waiting for the IRS to respond [01:54:20] <BBB> (tax-exempt and free-as-in-beer paypal donate now button) [01:55:37] <BBB> (if you're asking why I'm still online: I broke something, so I have to fix it so I can keep injecting mice next week, otherwise my graduation will have to be delayed, which I don't want) [01:58:56] <j0sh> BBB, i dont know how you do it [01:59:01] <j0sh> PhD + ffmpeg + real life [01:59:56] <Dark_Shikari> _PHD_? [01:59:57] <Dark_Shikari> WHAT? [02:00:04] <Dark_Shikari> lol [02:04:26] <BBB> you didn't know? [02:04:46] <BBB> I'm almost done with my PhD :) I've got a Nature and a Neuron (Cell press, 2nd level) paper [02:04:58] <BBB> my committee wasn't happy and wanted a manuscript for a third paper [02:05:02] <BBB> I want to kill them [02:05:04] <BBB> oops [02:05:11] <BBB> ^d^d this channel is logged [02:05:21] <j0sh> lol [02:05:27] <j0sh> http://www.nature.com/nature/journal/v458/n7237/full/nature07722.html [02:05:28] <j0sh> ? [02:05:37] <BBB> yes [02:05:59] <BBB> http://ronald.bitfreak.net/publications.php [02:07:02] <BBB> (for any automatic bot reading this, the comment 10 lines above was a joke, I love my committee) [02:07:19] <j0sh> haha [02:07:23] <BBB> ... [02:07:44] <BBB> btw, PhD + FFmpeg + life is only half of it [02:07:53] <BBB> I'm married and my wife is pregnant :-p [02:08:46] <j0sh> haha, crazy [02:09:15] <BBB> I guess [02:09:20] <BBB> 20 more minutes and I can go home [02:09:25] <BBB> I think I fixed all breakage [02:10:07] <Dark_Shikari> you are batshit insane [02:10:18] <BBB> btw the real story is like this: molecular biology is a process of waiting waiting and a little more waiting. then you take a break, pipet a little of this into that, then you wait some more [02:10:25] <Dark_Shikari> lol [02:10:29] <Dark_Shikari> Also [02:10:33] <Dark_Shikari> I LOVE YOU INTEL THANK YOU SO MUCH [02:10:33] <BBB> during the waiting, most students IM, read email and some actually read papers [02:10:35] <BBB> I code [02:10:40] <Dark_Shikari> vpsraw xmm3, xmm0, 5 [02:10:40] <Dark_Shikari> vpsraw xmm4, xmm1, 5 [02:10:40] <Dark_Shikari> vpaddsw xmm5, xmm0, xmm2 [02:10:40] <Dark_Shikari> vpaddsw xmm6, xmm1, xmm2 [02:10:46] <Dark_Shikari> THREE OPERAND ON X86 [02:10:47] <Dark_Shikari> FINALLY [02:10:54] <Dark_Shikari> x264: All tests passed Yeah :) [02:11:12] <BBB> huh? [02:11:18] <Dark_Shikari> AVX adds three-op to sse [02:11:24] <Dark_Shikari> Just insert a v before every instruction [02:11:34] <Dark_Shikari> Now I'll have to make yasm macros for this [02:11:41] <Dark_Shikari> i.e. if(sse) {do a mov instead} else {do avx method} [02:11:58] <Dark_Shikari> Hmm. I wonder if there's an easy way to bulk-redefine a hundred instructions? [02:12:38] <Dark_Shikari> i.e. [02:12:42] <Dark_Shikari> INIT_AVX [02:12:48] <Dark_Shikari> paddsw xmm0, xmm1, xmm2 [02:12:49] <Dark_Shikari> generates: [02:12:54] <Dark_Shikari> vpaddsw xmm0, xmm1, xmm2 [02:13:00] <Dark_Shikari> INIT_XMM before the same code generates: [02:13:10] <Dark_Shikari> movdqa xmm0, xmm1 [02:13:13] <Dark_Shikari> paddsw xmm0, xmm2 [02:13:21] <Dark_Shikari> pengvado: thoughts? [02:15:01] <BBB> paddsw xmm1, xmm2 also? [02:15:17] <Dark_Shikari> That would just outupt paddsw xmm1, xmm2 [02:15:30] <Dark_Shikari> I have confirmed that mixing AVX and SSE syntax works fine. [02:16:00] <BBB> vpaddsw m0, m1, m2 = movdqa m0, m1; paddsw m1, m2; paddsw m0, m2? [02:16:06] <Dark_Shikari> no [02:16:08] <Dark_Shikari> m0 = m1 + m2 [02:16:18] <Dark_Shikari> movdqa m0, m1 [02:16:21] <Dark_Shikari> paddsw m0, m2 [02:16:31] <BBB> ooooooooooooooooooooooo [02:16:38] <BBB> target != source1 or source2 [02:16:42] <Dark_Shikari> yes! [02:16:44] <Dark_Shikari> that's called 3-operand [02:16:47] <Dark_Shikari> welcome to 25 years ago on ARM [02:16:57] <BBB> smart! [02:17:11] <BBB> I hate always having to mov stuff for backup :-p [02:17:32] <BBB> avx is available on what cpus? [02:17:37] <BBB> is it on core i7? [02:17:48] <Dark_Shikari> no [02:17:54] <BBB> godddammit [02:17:55] <Dark_Shikari> Sandy Bridge. [02:18:00] <Dark_Shikari> Q4 2010 [02:18:05] <BBB> I just bought a core i7 [02:18:08] <BBB> you should've told me [02:18:11] <Dark_Shikari> There's an emulator! [02:18:18] <BBB> emulators don't scratch my itch [02:18:30] <BBB> although the core i7 is probably so fast that I don't want to write simd anymore anyway [02:19:13] <Dark_Shikari> hahhahaha [02:19:38] <BBB> actually that's silly indeed, my core1 is 2GHz and the i7 is only 2.7GHz [02:19:40] <BBB> :( [02:19:46] <Dark_Shikari> Is there a good, copy-pastable list of all x86 SIMD instructions that act on xmm registers? [02:19:51] <BBB> moore's law is dead? [02:20:01] <Dark_Shikari> no, moore's law was about transistor counts. [02:20:05] <Dark_Shikari> I want to loop over them and redefine them. [02:20:08] <Dark_Shikari> er, the instructions. [02:20:23] <BBB> I'm not really aware of such a list, sorry :( [02:20:38] <drv> you could probably extract one from an assembler's source (YASM probably has a table somewhere?) [02:21:12] <Dark_Shikari> wikipedia has a list, woot [02:22:30] <BBB> I typed psraw paddw xmm into google [02:22:37] <BBB> the first page has two hits from the ffmpeg source :-p [02:22:43] <BBB> and one from doom9 about x264 [02:22:52] <Dark_Shikari> lol [02:25:12] <Dark_Shikari> ok, I need a way to take every ", " in a file and convert it to a newline [02:25:57] <Dark_Shikari> oh nvm, notepad++ has an extended search/replace mode that takes \n as an arg. [02:26:00] <Dark_Shikari> nice. [02:31:41] <Dark_Shikari> Is there a way to macro a macro in yasm? [02:31:53] <Dark_Shikari> e.g. %macro rename_my_thing [02:31:56] <Dark_Shikari> and put a %macro inside that [02:46:56] <BBB> isn't that exactly how you do that? [02:47:05] <BBB> and you want to define, not macro [02:47:23] <Dark_Shikari> no I need a macro [02:47:26] <BBB> oh [02:47:27] <Dark_Shikari> I need as following: [02:47:33] <Dark_Shikari> %macro instructionname 2-3 [02:47:41] <Dark_Shikari> %if %0==3 && AVX [02:47:50] <Dark_Shikari> vinstructionname %1, %2, %3 [02:47:56] <Dark_Shikari> %else if %0==3 && !AVX [02:48:04] <Dark_Shikari> mova %1, %2 [02:48:11] <Dark_Shikari> instructionname %1, %3 [02:48:19] <Dark_Shikari> oh, well I should probably compare %1, and %2 too [02:48:22] <Dark_Shikari> so movaifnidn [02:48:25] <Dark_Shikari> and then so forth. [02:48:37] <BBB> I thought you wanted if XMM macro vXYZ 3 movdqa %1, %2; XYZ %1, %3 [02:49:07] <BBB> anyway, up to you, it's all the same anyway [02:49:46] * BBB goes home [02:49:47] <BBB> bye [02:50:19] <Dark_Shikari> http://pastebin.com/jyEjmJsL [02:50:20] <Dark_Shikari> there [02:50:29] <Dark_Shikari> pengvado: ping me when you're on, I want to discuss this [02:52:23] <Dark_Shikari> hmmm. nested macros might actually work. [02:54:21] <Dark_Shikari> mru: intel is taking the piss. [02:54:27] <Dark_Shikari> PCLMULHQLQDQ (westmere, sse) [02:54:39] <Dark_Shikari> carry-less multiplication for AES Galois mode [02:55:16] <astrange> how popular is aes that intel needs to implement it in hardware? [02:55:24] <Dark_Shikari> dunno [02:55:31] <Dark_Shikari> Also, they FINALLY HAVE SPLAT INSTRUCTIONS [02:55:31] <Dark_Shikari> holy shit [02:55:37] <Dark_Shikari> .... for float only. [02:55:42] <Dark_Shikari> fucking bastards. [02:56:40] <Dark_Shikari> how do I remove any line in a file containing a given phrase? [03:00:29] <Compn> grep -v blahblah [03:00:43] * Compn uses -iv because he hates case [03:02:57] <Dark_Shikari> thx [03:21:28] <saintdev> debugging attack detection is the fun. Zzzz [03:23:46] <Dark_Shikari> hmm, I have this problem in yasm [03:23:52] <Dark_Shikari> %macro NAME 1 [03:23:59] <Dark_Shikari> %macro X 2-* [03:24:02] <Dark_Shikari> <do stuff with X> [03:24:03] <Dark_Shikari> %endmacro [03:24:04] <Dark_Shikari> %endmacro [03:24:13] <Dark_Shikari> I want X to be %1 in the outer macro [03:24:20] <Dark_Shikari> i.e. NAME apple [03:24:28] <Dark_Shikari> will declare %macro apple 2-* [03:24:36] <Dark_Shikari> how can I get the scope to work right? [03:32:03] <Dark_Shikari> I want to do this: http://pastebin.org/430668 [05:05:10] <pengvado> Dark_Shikari: the only way I can see to pass data from the outer macro to the inner is as a default argument. which gets in the way of making the inner macro itself vararg. [05:05:13] <pengvado> http://pastebin.com/mS9Mzuhh [05:06:35] <pengvado> the other way is to give up on a single line instantiator and use 3 lines to paste the outer macro each time [05:07:26] <Dark_Shikari> pengvado: huh? [05:07:33] <Dark_Shikari> I don't get the firs tthing you said [05:07:38] <Dark_Shikari> or how the pastebin is relevant [05:09:33] <pengvado> %macro foo a-b bar [05:10:01] <pengvado> creates a macro named foo, which takes a madatory args and b-a optional args, the first of which defaults to bar if it isn't specified [05:10:14] <Dark_Shikari> how is the pastebin relevant? [05:10:18] <Dark_Shikari> or %ecx, (,%ebx,4) [05:10:20] <pengvado> the inner macro's scope hasn't started yet, so you can use outer macro args in that line [05:10:22] <Dark_Shikari> that looks like gcc syntax [05:10:35] <pengvado> oops [05:10:36] <pengvado> http://pastebin.com/WqRxPeQH [05:11:15] <Dark_Shikari> so I'd have to have a version for every possible level of vararg? ew [05:11:20] <Dark_Shikari> Which of the two methods do you prefer? [05:11:26] <Dark_Shikari> the 3-line-per-instantiation? [05:11:29] <Dark_Shikari> or the break-vararg? [05:12:21] <pengvado> 3-line-per-instantiation generated at compiletime by a perl/shell script [05:12:30] <Dark_Shikari> EW. [05:12:43] <Dark_Shikari> I like the idea of a self-constained x86inc that we can pass around easily [05:13:04] <Dark_Shikari> is there a way to put it all one line? [05:13:08] <Dark_Shikari> or are line breaks syntactical in yasm? [05:13:09] <Dark_Shikari> and unavoidable? [05:14:39] <Dark_Shikari> http://pastebin.org/431108 <--is this right? [05:18:42] <Dark_Shikari> would it be possible to use a single-line macro with %define? [05:23:11] <pengvado> %define FOO(x) BAR x, [05:23:57] <Dark_Shikari> %define addpd AVX_INSTR addpd, [05:24:01] <pengvado> works insofar as FOO(x) can thereafter be used as a macro which prepends x to BAR's args [05:24:02] <Dark_Shikari> would that work? [05:24:41] <pengvado> problem is we want the final instruction name to be a macro, not a define, or else it can't introspect on its args without parens [05:25:05] <Dark_Shikari> why would that not work? [05:25:11] <Dark_Shikari> addpd ----> AVX_INSTR addpd, [05:25:15] <Dark_Shikari> which creates a macro invocation [05:25:34] <Dark_Shikari> so paddw x, y, z [05:25:35] <Dark_Shikari> becomes [05:25:44] <Dark_Shikari> AVX_INSTR paddw x, y, z [05:25:51] <Dark_Shikari> er [05:25:53] <Dark_Shikari> AVX_INSTR paddw, x, y, z [05:25:56] <Dark_Shikari> which would work. [05:26:16] <Dark_Shikari> Is there a reason that breaks? [05:30:08] <pengvado> it breaks, but I don't understand why [05:30:40] <Dark_Shikari> Because the macro is expanded before the define? [05:30:40] <pengvado> http://pastebin.com/ENN344A4 [05:31:39] <Dark_Shikari> %xdefine FOO(xor) seems weird [05:32:04] <pengvado> why? [05:32:19] <Dark_Shikari> a define of A that includes A [05:32:57] <Dark_Shikari> and what is the "fail"? [05:33:09] <pengvado> bar.asm:16: warning: (BAR:1) macro `BAR' exists, but not taking 3 parameters [05:33:12] <pengvado> bar.asm:16: error: unexpected `,' after instruction [05:33:54] <pengvado> a) yasm detects loops in macro expansion. this is explicitly allowed. a macro whose expansion contains itself is expanded exactly once. [05:34:19] <pengvado> b) xdefine expands the rhs at macro definition time, and never again [05:35:09] <Dark_Shikari> using [05:35:09] <Dark_Shikari> %define hsubps AVX_INSTR hsubps , [05:35:11] <Dark_Shikari> results in [05:35:17] <Dark_Shikari> "unexpected ',' after instruction" [05:35:30] <Dark_Shikari> should I use xdefine? [05:35:38] <pengvado> no,, same error I pasted [05:35:46] <Dark_Shikari> ugh. [05:36:03] <Dark_Shikari> do we know what it's preprocessing into? [05:36:09] <Dark_Shikari> oh. we do. -e. [05:36:14] <Dark_Shikari> check what it's doing. [05:37:12] <Dark_Shikari> it preprocesses to [05:37:13] <Dark_Shikari> AVX_INSTR paddw , mm3, mm2 [05:37:21] <Dark_Shikari> er.... the macro isn't getting expanded! [05:37:29] <Dark_Shikari> That's interesting. [05:38:35] <Dark_Shikari> it's the same whether or not I use xdefine. [05:41:52] <pengvado> my add case doesn't get expanded according to -e, but it works?! [05:42:17] <pengvado> and my xor works if I give it a different name, but not if I try to call it xor [05:42:31] <Dark_Shikari> %macro paddw 2+ AVX_INSTR paddw, %2 [05:42:31] <Dark_Shikari> %endmacro [05:42:32] <Dark_Shikari> is wrong [05:42:39] <Dark_Shikari> it says that AVX_INSTR doesn't take two parameters [05:42:45] <Dark_Shikari> how do I make it work? [05:42:59] <Dark_Shikari> e.g. it's not parsing the arguments of paddw correctly [05:43:43] <Dark_Shikari> ok this is just weird [05:43:49] <Dark_Shikari> line 191 of dct-a becomes: [05:43:51] <Dark_Shikari> %line 191+0 common/x86/dct-a.asm AVX_INSTR paddw, xmm1 psubw xmm1, xmm0 [05:45:27] <Dark_Shikari> oh, duh, it should be %1 not %2 [05:45:37] <Dark_Shikari> ok, the macro method works. [05:45:47] <Dark_Shikari> %macro paddw 1+ AVX_INSTR paddw, %1 [05:45:48] <Dark_Shikari> %endmacro [05:45:52] <Dark_Shikari> that generates valid code [05:47:11] <Dark_Shikari> oof. now we have breakage in other categories -- specific types of instructions that require special cases [05:47:15] <Dark_Shikari> e.g. pshuflw [05:48:11] <pengvado> pshuflw is already 3arg. why wrap it at all? [05:48:27] <Dark_Shikari> oh, good point [05:48:54] <Dark_Shikari> palignr [05:49:02] <Dark_Shikari> right? [05:49:54] <pengvado> AVX_INSTR 3-4+ [05:50:25] <pengvado> there, it should work just well for converting 3arg to 4arg [05:50:45] <pengvado> though then we need a different way to detect... [05:50:45] <Dark_Shikari> no, didn't work [05:50:52] <Dark_Shikari> Yeah [05:51:02] <Dark_Shikari> it's fine to have two macros imo [05:51:12] <Dark_Shikari> now it breaks in deblock though [05:51:28] <Dark_Shikari> ah, I need to kill shufps [05:53:00] <KotH> salut [05:56:37] <Dark_Shikari> AND IT WORKS. [05:56:40] <Dark_Shikari> Hell yeah. [05:57:21] <Dark_Shikari> we now have 3-operand simd in yasm. [05:58:55] <Dark_Shikari> pengvado: http://pastebin.org/431305 [05:58:59] <Dark_Shikari> see if I missed any instructions to eliminate [05:59:06] <Dark_Shikari> included is an example of 3-operand code for testing [05:59:14] <Dark_Shikari> I haven't implemented actual AVX. [05:59:37] <Dark_Shikari> How do you think we should make INIT_AVX work?' [05:59:42] <Dark_Shikari> i.e. what should it set to tell the macros how to work? [06:01:49] <Dark_Shikari> We should also probably make it smart enough to distinguish the correct "mov" to use based on mmx vs xmm. [06:01:56] <Dark_Shikari> And we should make it use the correct mov based on whether it's a float or int op. [06:05:15] <Dark_Shikari> Oh, and we'll also have to add some sort of OS detection for AVX [06:05:24] <Dark_Shikari> It requires Windows 7 or some new linux kernel version. [06:05:35] <Dark_Shikari> Oh, though we're not using the ymm registers. [06:05:37] <Dark_Shikari> So actually no. [06:07:30] <saintdev> kshishkov: is there a limit to the number of window groups in a short sequence? [06:08:49] <Dark_Shikari> pengvado: how do I determine if an argument is an mmx or xmm register? [06:12:18] <pengvado> %define sizeofmm0 8 [06:12:21] <pengvado> %define sizeofxmm0 16 [06:12:21] <pengvado> etc [06:16:38] <Dark_Shikari> pengvado: huh? [06:17:09] <Dark_Shikari> you mean define sizeof for all 32 registers [06:17:14] <Dark_Shikari> and then lookup sizeof%2 ? [06:17:18] <pengvado> yes [06:17:27] <Dark_Shikari> ok [06:17:57] <Dark_Shikari> make that 24 times [06:24:21] <pengvado> I have several times considered rearranging INIT_MMX/XMM to keep track of a cpulevel in some global variable, so that it doesn't have to be passed to each function-declaring-macro [06:28:50] <kshishkov> saintdev: yes, 8 :) [06:29:32] <saintdev> kshishkov: i can't have > 1 group per block not fair! [06:29:37] <saintdev> :P [06:29:59] <kshishkov> that's limit for long windows :P [06:30:27] <superdump> ? [06:30:54] <saintdev> kshishkov: how about the opposite, can i have all 8 short blocks in one window? [06:31:09] <saintdev> s/window/group/ [06:31:15] <kshishkov> yes [06:31:30] <superdump> sounds like aac [06:31:52] <kshishkov> bitstream just informs you how they are grouped, no artificial limitations IIRC [06:32:14] <kshishkov> superdump: yes, that's AAC. And an attempt to make it LAME [06:32:27] <superdump> certain transitions are not meaningful and should be avoided though [06:32:40] <saintdev> well ofc, just wondering on any limitations [06:36:51] <superdump> seems like the amr-wb decoder for SoC is going well by the way [06:37:20] <superdump> the student (marcelo) mailed me on tuesday saying that he'd got coherent sound coming out of it [06:37:39] <superdump> but needed to do some fun high band synthesis stuff [06:37:48] <superdump> looks like he committed that or most of it earlier [06:38:15] <superdump> he said he had some audible issues (metallic-sounding) before the high band stuff [06:39:12] <wbs> superdump: wow, that's great news [06:39:24] <superdump> yeah [06:40:03] <superdump> i was very pleased [06:40:05] <superdump> :) [06:41:28] <mru> morning [06:41:36] <superdump> morning mru [06:41:38] <kshishkov> morgon [06:41:52] <Dark_Shikari> mru: I just retrofitted yasm to do 3-operand [06:41:55] <Dark_Shikari> did I mention 3-operand is awesome? [06:41:57] <mru> yeah [06:42:14] <mru> and lol PCLMULHQLQDQ [06:42:17] <Dark_Shikari> and with AVX, we'll be able to actually have it. [06:42:39] <Dark_Shikari> it just adds an extra move for anything pre-avx. [06:42:53] <Dark_Shikari> unfortunately it forced me to paste this about 150 times: [06:42:54] <Dark_Shikari> %macro addpd 1+ [06:42:54] <Dark_Shikari> AVX_INSTR addpd, 1, 0, %1 [06:42:54] <Dark_Shikari> %endmacro [06:42:59] <Dark_Shikari> for each simd instruction. [06:43:16] <Dark_Shikari> instr, ISFLOAT, HASIMMEDIATE, args [06:44:05] <Dark_Shikari> but besides that, it works! [06:44:12] <Dark_Shikari> pmullw xmm3, xmm1, [pw_76543210] [06:44:24] <Dark_Shikari> the best of x86 and ARM -- 3-operand, with memory operands ;) [06:45:30] <mru> btw neon has polynomial multiplication [06:46:09] <saintdev> itunes uses some pretty creative grouping o.O [06:51:50] <Dark_Shikari> woohoo, AVX cpu detection works [06:51:53] <Dark_Shikari> I love intel's emulator [06:51:57] <Dark_Shikari> It's actually not that slow [06:52:01] <Dark_Shikari> I'm shocked [06:52:34] <Dark_Shikari> CPU: 26.39fps, emulator: 2.68fps [06:52:48] <superdump> :) [06:52:53] <Dark_Shikari> That's so fast I'd think there'd have to be binary translation involved [06:52:59] <superdump> that's pretty nifty [06:53:25] <Dark_Shikari> oh whoa. their emulator gets faster. [06:53:28] <Dark_Shikari> if you run it longer [06:53:34] <Dark_Shikari> Must be JIT, has to be [06:53:47] <Dark_Shikari> it starts off slow, then jumps up to over 10fps [06:53:57] <Dark_Shikari> end result is about half native speed [06:54:18] <Dark_Shikari> I'm shocked they're this competent [06:55:48] <superdump> i guess intel are pretty good at compilers [06:57:13] <Dark_Shikari> I'm just surprised they bothered for an emulator. [06:59:27] <Dark_Shikari> x264: AVX - intra pred : [OK] [06:59:27] <Dark_Shikari> x264: All tests passed Yeah :) [06:59:31] <Dark_Shikari> WOOHOO [06:59:35] <Dark_Shikari> moar avx [07:02:31] * kshishkov tries to remember when MMX was introduced [07:03:04] <kshishkov> it took them 15-20 years to do SIMD properly? [07:05:06] <mru> it's intel, what do you expect? [07:05:18] <kshishkov> high precision, of course! [07:05:54] * kshishkov wonders why you can do all of SIMD stuff with any of SIMD regs, that sounds too non-Intel [07:08:03] <Dark_Shikari> pengvado: is there any faster abs() method if mov is free? [07:13:31] <Dark_Shikari> mru: help my pathetic non-3-operand brain [07:13:52] <Dark_Shikari> is there a way to calculate (a-b) and (a+b) in two ops, with a generic 3-operand instruction set, with 2 registers? [07:14:03] <Dark_Shikari> or do you still need a temp? [07:14:17] <mru> I would use a temp [07:14:23] <mru> don't know any other way [07:14:40] <Dark_Shikari> ok [07:14:59] <mru> what good is 3-op going to do you if you only have 2 regs? [07:15:11] <Dark_Shikari> I was just trying to replace a macro with a 3-operand one [07:15:18] <kshishkov> there's math approach [07:15:26] <Dark_Shikari> to do a SUBSUM, it did": [07:15:27] <Dark_Shikari> paddw %1, %2 [07:15:27] <Dark_Shikari> paddw %2, %2 [07:15:27] <Dark_Shikari> psubw %2, %1 [07:15:39] <Dark_Shikari> which in 2-operand is just as good as mov/add/sub [07:15:47] <mru> ah, ok [07:15:52] <mru> but it's 3 ops [07:16:04] <Dark_Shikari> yes, in 3-operand you would only use two ops for a subsum [07:16:14] <Dark_Shikari> hence why I'm rewriting the macro ;) [07:16:43] <mru> what I would do is c=a+b; a=a-b or similar [07:16:46] <mru> and then b is free [07:16:58] <mru> no need to keep stuff in the same regs [07:17:19] <Dark_Shikari> yes, it requires a SWAP [07:17:20] <Yuvi> even easier with yasm with SWAP [07:17:27] <Dark_Shikari> the problem is I can't get it to work here [07:17:31] <Dark_Shikari> I'm not sure if I have a substitution problem [07:17:39] <mru> it doesn't _require_ a swap [07:17:40] <Dark_Shikari> this macro takes m0, not 0 [07:17:46] <Dark_Shikari> mru: can you do it in two ops without a swap? [07:17:48] <mru> it just requires you to remember where you put stuff [07:17:52] <Dark_Shikari> er... that's what a swap is [07:18:01] <Dark_Shikari> "swapping the locations of values in registers" == "a swap" [07:18:02] <mru> you don't have to write it down [07:18:07] <Dark_Shikari> yes, but it's still a swap [07:18:14] <mru> call it what you want [07:18:15] <Dark_Shikari> The whole point of the macros is that they do that for you [07:18:21] <Dark_Shikari> You don't have to remember where you put stuff. [07:18:22] <Dark_Shikari> SWAP 1,3 [07:18:28] <mru> yes, yes I know [07:18:28] <Dark_Shikari> now all future uses of registers 1 and 3 are swapped [07:18:38] <mru> I find it confusing [07:18:44] <mru> I want r1 to mean r1 [07:19:13] <Dark_Shikari> It does mean r1. Just don't look at the disasm. [07:19:27] <Dark_Shikari> Think of "SWAP" as an xchg operation. [07:19:30] <Dark_Shikari> xchg r1, r5 [07:19:32] <mru> I know what it does [07:19:41] <Dark_Shikari> but if you think of it as xchg, r1 does mean r1. [07:20:02] <mru> not when I put the return value in r0 and it has been swapped for something else [07:20:09] <kshishkov> Dark_Shikari: ever seen http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs ? [07:20:15] <Dark_Shikari> mru: then you explicitly use the return register [07:20:18] <Dark_Shikari> on x86, eax is return [07:20:21] <Dark_Shikari> thus, we always use "eax" [07:20:26] <Dark_Shikari> "r0" may map to something else [07:20:30] <Dark_Shikari> but "eax" is always "return register" [07:20:33] <mru> even more confusing [07:20:36] <mru> one reg, one name [07:20:36] <Dark_Shikari> thus, mov eax, blah [07:20:41] <Dark_Shikari> == put something in return register [07:20:44] <Dark_Shikari> it's not very complicated [07:20:53] <Dark_Shikari> But it is one reg, one name. [07:21:00] <Dark_Shikari> "return register" is a different concept from "r0" [07:21:06] <mru> no, eax and r0 might be the same [07:21:09] <mru> or they might be different [07:21:12] <Dark_Shikari> They might be. But they're two different concepts. [07:21:23] <mru> they still share a physical register [07:21:27] <Dark_Shikari> Different concepts should have different names. [07:21:35] <mru> no [07:21:41] <Dark_Shikari> same reason you don't use the same variable for 15 different things in C code. [07:21:51] <mru> there's a reason it's C code [07:21:59] <Dark_Shikari> there's no reason that asm can't be just as readable as C [07:21:59] <mru> naming in C is an abstraction [07:22:05] <Dark_Shikari> Same in asm. [07:22:07] <mru> no [07:22:13] <mru> registers are registers [07:22:22] <Dark_Shikari> OK, if you don't want your abstractions, feel free to not have your abstractions [07:22:29] <Dark_Shikari> you can take 5 hours to write an inverse transform [07:22:31] <Dark_Shikari> I'll take 2 minutes [07:22:35] <mru> values in C are moved in and out of regs as necessary [07:22:48] <Dark_Shikari> or less [07:23:05] <mru> which transform [07:23:17] <mru> 2048-point IFFT? [07:23:19] <Dark_Shikari> VP8's WHT [07:23:28] <mru> oh but that one is trivial [07:23:29] <Dark_Shikari> I wrote it in less than 2 minutes by pasting together yasm macros [07:23:36] <Dark_Shikari> it is trivial, but I didn't even have to write asm [07:23:42] <Dark_Shikari> besides "load" and "store" [07:23:53] <mru> and you don't care about scheduling [07:24:05] <Dark_Shikari> true. on neon it does actually matter [07:24:08] <Dark_Shikari> lol no ooe [07:24:12] <Dark_Shikari> not even on A9. [07:24:32] <mru> can you say BATTERY POWERED? [07:24:43] <mru> pocket size [07:24:47] <Dark_Shikari> A9 has OOE on the main chip [07:24:52] <Dark_Shikari> just not on neon [07:24:55] <mru> I know what A9 has and hasn't [07:25:09] <Dark_Shikari> There is no reason why a battery powered device can't have OOE. [07:25:12] <mru> the neon unit is already bigger than the main integer core [07:25:20] <Dark_Shikari> Then why is it slow as shit? [07:25:26] <mru> oh fuck off [07:25:42] <Dark_Shikari> <insert Gumboot bragging about how VideoCore's SIMD is 10 times faster than NEON and uses half the power here> [07:25:49] <mru> go build a chip if you think it's so damn easy [07:26:02] <mru> videocore is a highly specialised chip [07:26:20] <Dark_Shikari> and it does 512-bit simd with fully transposed register access [07:26:23] <Dark_Shikari> and a 2D regfile [07:26:27] <mru> exactly [07:26:29] <Dark_Shikari> and extremely powerful and flexible SIMD instructions [07:26:33] <mru> 2d register file is very powerful [07:26:33] <Dark_Shikari> far more powerful or flexible than NEON [07:26:38] <Dark_Shikari> far more than SSE [07:26:42] <Dark_Shikari> for less power [07:26:50] <kshishkov> what's the catch then? [07:26:56] <Dark_Shikari> It's proprietary. [07:27:11] <Dark_Shikari> for example, they have: [07:27:37] <Dark_Shikari> ((int16_t * int16_t) + int16_t) >> {0-31} [07:27:52] <Dark_Shikari> A rather useful instruction ;) [07:29:01] <kshishkov> still, what's the catch? I find it hard to believe in product that is significantly outstands all competitors [07:30:29] <Dark_Shikari> the catch is that Gumboot apparently constantly bitches at work about how shitty it is [07:30:32] <kshishkov> would you believe in H.264 encoder that produces better visual quality streams that x264 with lower bitrate and 50% faster? [07:30:35] <Dark_Shikari> while simultaneously bragging on irc about how awesome it is [07:30:57] <superdump> who is Gumboot? [07:31:05] <kshishkov> Broadcom dev [07:31:10] <superdump> and why do they bitch about it at work if it's so awesome? [07:31:23] <kshishkov> he was porting RealVideo to their chip [07:31:28] <superdump> hehe [07:31:38] <av500> bitch meets bitch then [07:32:12] <Dark_Shikari> So this is what powers that chip that they were bragging to us about [07:32:15] <Dark_Shikari> 3ms 1080p [07:32:18] <Dark_Shikari> encoding [07:32:19] <Dark_Shikari> h264 [07:33:28] <superdump> :) [07:34:01] <superdump> power usage for said performance? [07:34:37] <av500> i guess it will be ok for a HD camera [07:34:41] <Dark_Shikari> superdump: low [07:34:46] <Dark_Shikari> Of course, it looked like shit. [07:34:51] <superdump> hehehe [07:35:27] <Dark_Shikari> and that was intra only [07:35:28] <Dark_Shikari> at 30mbit [07:35:36] <superdump> and it looked like shit? [07:35:44] <superdump> oh intra only [07:36:33] <superdump> hmm, what's the proportion bits-wise of I-frames to P-frames and to B-frames? [07:36:39] <superdump> roughly [07:37:42] <Dark_Shikari> depends completely on the video [07:37:50] * superdump is out of the loop [07:37:52] <superdump> what is libavcore? [07:38:17] <Yuvi> the new tab-completion nightmare to keep libavutil "pure" [07:38:27] <Dark_Shikari> lol [07:38:43] <superdump> :) [07:38:43] <Dark_Shikari> and to break compilation with windows apps [07:38:47] <jenk> lol hows that [07:38:56] * cartman tests eatg_x264hd-sample.mkv [07:39:38] <Dark_Shikari> jenk: stuff intended to work without pkg-config [07:40:27] <jenk> does that mean just one -l ? [07:41:26] * av500 is all for adding libove and libolcats [07:41:57] <Dark_Shikari> jenk: yeah, but it still breaks it [07:42:15] <jenk> how so [07:43:05] <Dark_Shikari> We have to add it to configure. [07:43:10] <Dark_Shikari> Which means that it breaks it until we fix it. [07:43:30] <mru> add what to configure? [07:44:01] <Dark_Shikari> -lavcore [07:44:09] <jenk> how much work does that take [07:44:24] <mru> oh your configure? [07:44:24] <Dark_Shikari> that isn't the problem [07:44:28] <Dark_Shikari> it breaks all older versions [07:44:35] <Dark_Shikari> so everyone is forced to update to make it compile again [07:44:54] <jenk> you mean if you try to use old apps with avcore instead of the other stuff? [07:44:58] <jenk> what's the difference? [07:45:20] <mru> Dark_Shikari: when did you ever support running old versions? [07:45:35] <Dark_Shikari> mru: I don't, the point is that arbitrarily breaking compilation with every other app until people fix it is _annoying_ [07:45:47] <mru> you do only when it gives you a chance to bitch [07:46:07] <Dark_Shikari> ? [07:46:24] <Dark_Shikari> the point is -- a change that breaks backwards compatibility should be done with at least some reason [07:46:25] <mru> you always chant the use latest mantra, except now [07:46:35] <Dark_Shikari> er.... it's not quite the same [07:46:37] <mru> now you have a chance to bitch at ffmpeg for breaking old verseions [07:46:41] <Dark_Shikari> um, no. [07:46:46] <Dark_Shikari> suppose 20 apps use ffmpeg. [07:46:47] <jenk> call it something else? [07:46:50] <Dark_Shikari> ffmpeg makes change that breaks backwards compatibility. [07:47:01] <Dark_Shikari> EVERY SINGLE ONE must update to even _compile_. [07:47:10] <Dark_Shikari> It's fine to do that if there's a good reason. [07:47:14] <Dark_Shikari> But there's no good reason. [07:47:56] <mru> I agree it's silly [07:48:06] <mru> but you are in no position to be bitching about it [07:48:10] <thresh> look at x264, they update sonames five times a day [07:48:15] <thresh> oh wait, you're the x264 author [07:48:17] <Dark_Shikari> yes, but we don't break backwards compatibility [07:48:20] <Dark_Shikari> that's not quite the same [07:48:24] <jenk> i'm curious why avcore breaks ffmpeg compat tho [07:48:30] <jenk> is stuff named differently? [07:48:32] <Dark_Shikari> we break backwards compatibility once or twice a year [07:48:35] <Dark_Shikari> jenk: you have to add an extra ldflag [07:48:36] <mru> jenk: it needs a -lavcore to link [07:48:38] <Dark_Shikari> I mean, it's trivial to fix [07:48:42] <Dark_Shikari> it's just everyone has to do it to fix their apps. [07:48:48] <jenk> well thats not unreasonble [07:48:50] <Dark_Shikari> It would have been nicer, IMO, to announce this earlier [07:48:54] <jenk> easily fixed [07:48:54] <Dark_Shikari> to give peole time to fix shit [07:48:58] <jenk> can you do both for a while? [07:48:59] <Dark_Shikari> we do that when we break backwards compatibility [07:49:07] <jenk> make all libs + avcore? [07:49:11] <mru> if you use shared libs nothing breaks [07:49:22] <thresh> static libs are bad, mkay [07:49:35] <Dark_Shikari> mru: requires PIC on x86_64 [07:49:48] <mru> and already built stuff keeps working [07:50:04] <av500> what happened to every project having a cloned copy of ffmpeg, did that go out of fashion? [07:50:05] <mru> if you're compiling some app against bleeding edge ffmpeg, you're obviously a developer of said app [07:50:11] <mru> so you can trivially fix it [07:50:16] <Dark_Shikari> mru: er... no [07:50:22] <jenk> anyone who statically links against ffmpeg deserves what they get [07:50:23] <Dark_Shikari> I'm a developer of x264, and I don't compile against bleeding edge ffmpeg [07:50:31] <Dark_Shikari> I got the report from a user [07:50:38] <Dark_Shikari> who was trying to compile a build to distribute [07:50:49] <thresh> so he was a developer as well [07:50:54] <Dark_Shikari> er... no [07:50:57] <Dark_Shikari> he has never contributed a patch [07:51:00] <mru> Dark_Shikari: you linking against ffmpeg is just a huge bitch in itself [07:51:00] <Dark_Shikari> therefore, he is not a developer [07:51:10] <Dark_Shikari> mru: you want us to reimplement swscale? [07:51:17] <jenk> lol [07:51:20] <mru> I wouldn't mind [07:51:22] <Dark_Shikari> LOL [07:51:24] <Dark_Shikari> good point =p [07:51:24] <mru> swscale stinks [07:52:26] <jenk> hey so [07:52:30] <jenk> i made my own rtsp server [07:52:35] <jenk> basically i just relay rtp packets [07:52:36] <jenk> but [07:52:47] <jenk> if i stream something to it with -f rtsp from ffmpeg [07:52:53] <jenk> and then try to play it in vlc [07:53:04] <jenk> it tells me my PTS values are totally off [07:53:13] <jenk> and i can make out video and audio but its all chopped up [07:53:26] <wbs> haven't tested that much with vlc, but with e.g. quicktime player it works just fine [07:53:31] <jenk> im just pasasing through the rtp packets, do i need to munge them in some way [07:53:42] <wbs> and only tested bouncing via DSS [07:54:02] * kshishkov thinks we need to introduce several libraries - from libavaux, libavbits to libavxtend to libavzlib [07:54:31] <saintdev> libavcake [07:54:49] <mru> libavwrapper [07:54:53] <wbs> jenk: ffmpeg -f rtsp via DSS to VLC seems to work just fine, too. using mpeg4/aac that is [07:55:01] <kshishkov> saintdev: move it into libavportal [07:55:39] <saintdev> there is no libavcake? [07:55:42] <jenk> hrm [07:55:46] <mru> saintdev: no, it's a lie [07:55:51] <mru> the lib is a lie [07:55:52] <jenk> i was using h264 and mp3lame [07:56:04] <jenk> but what more could i be doing besides relaying RTP packets? [07:56:08] * mru goes and writes libie [07:56:10] <jenk> why wouldn't that just work [07:56:36] <wbs> dunno, try mpeg4/aac first, something could be screwy with mp3 in rtp [07:57:01] <wbs> not many commercial apps do mp3 in rtp either [07:57:02] <jenk> well the video was jacked too [07:57:06] <jenk> it was out of order [07:57:10] <jenk> and it gave me lots of PTS errors [07:57:14] <jenk> the values looked pretty big [07:57:18] <wbs> did you run ffmpeg with -re? [07:57:20] <kshishkov> mru: replace it with libO, libFF or libChrome [07:57:23] <jenk> what's that do [07:57:34] <wbs> it plays the video in realtime [07:57:42] <pJok> ffbrowser? [07:57:42] <wbs> otherwise it plays through the source file as fast as it can [07:57:54] <wbs> and you obviously have weird timestamps and dropped packets and whatnot [07:58:18] <kshishkov> pJok: yes, no need to tell gcc to -lie, it does so for free [07:58:19] <jenk> http://github.com/revmischa/rtsp-server/tree/master/lib/RTSP/ [07:58:27] <jenk> oh, that could help [07:59:01] <pJok> kshishkov, i thought gcc was very honest about its random code generator, otherwise known as the compiler... [08:00:26] <kshishkov> pJok: no, they don't even disclose version to random seed transform [08:01:39] <spaam> debian had a good random seed generator... [08:02:12] <kshishkov> gcc-based? [08:02:25] <spaam> no :) that one in openssl :) [08:02:48] <kshishkov> it's been fixed already :( [08:03:03] <thresh> you can still have a more stale debian version if you want [08:03:28] <mru> oh, stable was just a typo? [08:04:24] <kshishkov> mru: for Debian there's no difference [08:04:32] <mru> deian [08:04:53] <kshishkov> I meant stale/stable - like the case with French bread [08:06:54] <thresh> don't you know the naming scheme? stale, teasing, unusable... [08:07:15] <jenk> okay, i'm trying -re [08:07:17] <jenk> sorta works [08:07:21] <jenk> looks fucked up [08:07:25] <jenk> but it looks in the right order at least [08:07:51] <mru> I hate the way debian puts new meanings to perfectly normal words like 'main' [08:08:02] <wbs> ok, now test mpeg4 and aac too, if there's something weird with the other codec packetizations [08:08:12] <mru> and then the debianites use them in their special sense when talking to outsiders [08:08:43] <pJok> mru, debian is a whole universe [08:08:58] <mru> I also find it hilarious that they have this convoluted form of "democracy" which turns out to be all fake [08:09:10] <DonDiego> hey [08:09:16] <mru> the "ftpmasters" are the real dictators [08:09:24] <DonDiego> who is in favor of holding a vote over libavutil vs. libavcore [08:09:36] <DonDiego> for once, that seemed like a vote-worthy subject [08:09:37] * kshishkov kicks DonDiego [08:09:44] <jenk> same thing, mpeg4 looks fucked up bit in sync [08:09:55] <mru> DonDiego: maybe it would put an end to michael calling vote all the time [08:10:02] <DonDiego> but it was decided by the evil overlord nonetheless [08:10:13] <av500> I vote to remove libav from the folder names [08:10:24] <jenk> i can show you [08:10:24] <mru> av500: there are technical complications to that [08:10:27] <pJok> mru, democracy is bikeshedding and bickering till someone commits regardles... oh wait, isn't that ffmpeg? ;) [08:10:37] <mru> av500: it would break the #include directives [08:10:37] <av500> mru: ? [08:10:44] <kshishkov> av500: don't forget - "One Man, One Vote" and you're not that man [08:10:44] <av500> mru: ahm [08:11:03] <mru> it's very convenient to have the same path in the repo as when installed [08:11:15] <av500> for the inlcude files, hmm [08:11:37] <mru> I don't really mind the names [08:11:39] <av500> I guess I could just create local symlinks as well :) [08:11:50] <mru> I keep most files open in emacs all the time anyway [08:12:00] <mru> so it's just a buffer switch away [08:13:17] <DonDiego> seriously, who else wants a vote? [08:13:43] <mru> I am against votes in all forms [08:13:55] <mru> it's not going to change anything, and you know it [08:14:07] <DonDiego> it *is* something that competent people can disagree about [08:14:46] <kshishkov> so "vote" is a new word for flamewar? [08:15:56] <DonDiego> did it ever mean something else? :) [08:24:56] <DonDiego> and while we're at it - did anybody ever decode the result of the last vote? [08:25:16] <DonDiego> since i have thousands of mails to catch up to i just filed it away - tl;dr [08:25:33] <mru> which vote? [08:25:42] <mru> the documentation one? [08:25:44] <DonDiego> there were several? [08:25:50] * DonDiego is backlogged [08:25:58] <mru> that hardly qualified as a vote [08:26:14] <DonDiego> yes, that one [08:26:24] <DonDiego> well, some sort of result was presented in the end [08:26:32] <mru> most people seemed to vote for no vote [08:26:37] <mru> which michael ignored [08:26:45] <DonDiego> but i had neither the time nor the motivation to decode the result [08:26:57] <mru> of the remaining 3 votes, the winner was keep as is [08:27:13] <mru> i.e. people write to the best of their abilities [08:27:27] <mru> and those who know better can fix later [08:27:37] <mru> of course he'll slam any _actual_ fixes [08:27:40] <mru> but that's another matter [08:28:53] <mru> in other news, the new fate is ready to go live [08:29:02] <DonDiego> \o/ [08:29:14] <DonDiego> fate.ffmpeg.org [08:29:18] <mru> I've been running it all week, and it seems smooth [08:29:27] <mru> it's on fate.mansr.com at the moment [08:29:28] <DonDiego> make it the official one right away IMO [08:29:42] <DonDiego> register it in the dns on mphq [08:29:52] <mru> I can point fate.ffmpeg.org at my machine [08:29:54] <DonDiego> it can remain on mansr.com (for the time being) [08:30:08] <DonDiego> that's what i meant, point it to your machine [08:30:41] <mru> I hope mike won't be too pissed [08:30:44] <mru> but he had it coming [08:31:31] <DonDiego> i asked for the source code twice [08:32:15] <DonDiego> this is the fate of proprietary software that was in slow development for years and had feature requests ignored constantly... [08:33:47] * kshishkov looks at GNU software for comparison [08:36:34] <mru> I'm still working on improving the backend storage, but that doesn't stop it from being used [08:42:12] <cartman> anyone with a DirectShow knowledge around? [08:42:22] * mru knows it sucks [08:42:35] * cartman just used it for first in his life yesterday [08:42:48] <mru> poor cartman [08:43:00] <cartman> yay for me mru :D [08:43:04] <CIA-92> ffmpeg: stefano * r24587 /trunk/libavcodec/imgconvert.c: [08:43:05] <CIA-92> ffmpeg: Make avpicture_fill() directly call av_fill_image_linesizes() and [08:43:05] <CIA-92> ffmpeg: av_fill_image_pointers() rather than their wrappers ff_fill_linesize() [08:43:05] <CIA-92> ffmpeg: and ff_fill_pointer(). [08:43:05] <CIA-92> ffmpeg: Improve performance. [08:43:05] <CIA-92> ffmpeg: stefano * r24588 /trunk/libavcore/imgutils.c: [08:43:05] <CIA-92> ffmpeg: Rename av_fill_image_linesizes() internal variables max_plane_step and [08:43:05] <mru> here's to a speedy recovery [08:43:06] <CIA-92> ffmpeg: max_plane_step_comp by removing the "plane_" word, and add a comment [08:43:06] <CIA-92> ffmpeg: for explaining what they represent. [08:43:07] <CIA-92> ffmpeg: Increase readability. [08:43:07] <cartman> I got video decoding working :p [08:43:08] <CIA-92> ffmpeg: stefano * r24589 /trunk/libavcore/imgutils.c: [08:43:08] <CIA-92> ffmpeg: Make av_fill_image_linesizes() return a meaningful error core rather [08:43:09] <CIA-92> ffmpeg: than -1. [08:43:09] <CIA-92> ffmpeg: stefano * r24590 /trunk/libavcore/imgutils.c: [08:43:10] <CIA-92> ffmpeg: Reimplement av_fill_image_pointers() using the information stored in [08:43:10] <CIA-92> ffmpeg: the pixdescs. [08:43:17] <cartman> just the MKV files have some problems [08:43:27] <mru> what demux are you using? [08:43:36] <mru> haali? [08:43:43] <cartman> mru: yup [08:43:51] <cartman> MatroskaSplitter thing [08:43:58] <cartman> but decoded video is kind of garbage [08:44:22] <kshishkov> so? [08:44:38] <cartman> like 2 in 3 frames are bad [08:44:40] <cartman> 1 frame half good [08:44:44] <cartman> windows media player works finbe [08:44:56] <cartman> I am just using RenderFile function [08:44:58] <cartman> nothing else [08:45:05] <cartman> wonder what might be wrong [08:45:54] <kshishkov> output [08:46:22] <cartman> yeah output is wrong kshishkov :) [08:46:34] <cartman> but it works for AVC in MOV [08:46:40] <cartman> just the MKV is wrong [08:47:00] * kshishkov has forgotten about Direct* since years [08:47:51] <cartman> well there is just one Render function so I am not sure what might be wrong [08:49:43] <kshishkov> ask somewhere else, there should be a channel with people using DShow [08:50:00] <kshishkov> I suspect here people are rather proud of never using it [08:50:07] <cartman> why? [08:50:16] <cartman> being able to decode a video made me happy :P [08:54:35] <kshishkov> cartman: look at channel name, we don't need side tools to decode video [08:56:48] <cartman> right [08:56:50] <KotH> mru: could your fate be adjusted to use mplayer instead? [08:56:52] * cartman goes away [08:57:01] <mru> KotH: use mplayer? [08:57:07] <KotH> mru: instead of ffmpeg [08:57:12] <mru> for what? [08:57:15] <KotH> testing [08:57:16] <spaam> fate [08:57:22] <mru> eh, it's for testing ffmpeg [08:57:24] <kshishkov> KotH: no, by definition. You'd have to change first letter at least [08:57:31] <mru> it could be adapted to test mplayer of course [08:57:40] <KotH> kshishkov: mate? :) [08:58:15] <mru> first mplayer would need some actual test cases... [08:58:39] <KotH> that can be done [09:00:04] * KotH will have a look at the source.. somewhen.. maybe after retirement [09:00:56] <mru> the backend aggregator doesn't care how the results came about [09:01:02] <mru> nothing ffmpeg-specific there [09:01:07] <DonDiego> compilation tests would be a start [09:01:24] <DonDiego> other tests can follow later [09:01:31] <mru> all that's required is a report file in the correct, undocumented format [09:01:57] <DonDiego> let's get it live for ffmpeg, then we shall see [09:02:06] <kshishkov> mru: XML? [09:02:07] <mru> fate.ffmpeg.org is live [09:02:17] <mru> kshishkov: you know the answer [09:02:25] <spaam> \o/ [09:02:32] <av500> mru: its not live, its a fairly static page [09:02:50] <mru> commit something and watch it spring to life [09:02:58] <spaam> mru: only linux :S [09:03:01] <DonDiego> announce it on -devel then [09:03:05] <mru> spaam: I only have linux systems [09:03:09] <mru> DonDiego: I will [09:03:46] <kshishkov> mru: looks like it will be Gentoo linux systems only. Not that I mind [09:04:07] <mru> that's only because it's what I'm running [09:04:14] <mru> anyone is free to contribute [09:04:17] <DonDiego> kshishkov: regarding the RVXX docs, i think you can convert the pdfs to text and then grep them [09:04:39] <kshishkov> DonDiego: of course. What for? [09:04:49] <DonDiego> mru: i'll look into adapting it for work when i'm back from holidays [09:05:08] <DonDiego> kshishkov: the famous typo or other things you haven't understood yet [09:05:17] <DonDiego> kshishkov: did you give them a glance? [09:05:34] <kshishkov> not yet [09:05:50] <DonDiego> it cannot hurt.. [09:05:52] <kshishkov> anyway, DS asked some guy - it was a decision, not a type [09:05:55] <kshishkov> *typo [09:06:22] <kshishkov> and the only thing left is weighted prediction - feel free to implement it\ [09:06:59] <CIA-92> ffmpeg: stefano * r24593 /trunk/doc/APIchanges: Add an entry for the AVFilterBuffer change of r24592. [09:07:41] <cartman> http://img823.imageshack.us/img823/4043/mukavva.png looks like a codec problem right? [09:07:49] <cartman> not a filter problem I think [09:08:02] <kshishkov> or bitstream [09:08:06] <mru> cartman: garbled input to decoder [09:08:22] <av500> cartman: looks like your deblocking filter was not applied [09:08:28] <cartman> without a splitter I wouldn't get even garbage right? [09:08:42] <cartman> av500: I didn't add any deblocking filter to graph [09:08:47] <cartman> maybe that, thanks :) [09:08:59] <mru> lol, no that's not the problem [09:09:01] <av500> you need one, way to blocky for my taste :) [09:09:07] <cartman> bah :) [09:09:10] <cartman> stop mocking me ;) [09:09:18] <av500> its friday.... [09:09:27] <mru> av500: you didn't have dialup porn in your youth? [09:09:29] <DonDiego> kshishkov: is the missing feature documented somewhere? [09:09:36] <cartman> av500: http://www.youtube.com/watch?v=qST5eVLudrQ , have fun [09:10:24] <kshishkov> DonDiego: yes, it definitely should be in the spec [09:10:51] <DonDiego> i mean, did you document the missing feature in our decoder.. [09:11:25] <kshishkov> in the list of small tasks [09:11:39] <kshishkov> for now we have simple average instead of weighted sum [09:23:18] <DonDiego> kshishkov: you lazy lout, you! [09:23:19] <DonDiego> :) [09:27:07] <kshishkov> DonDiego: yes I am [09:29:31] <av500> kshishkov: dont forget, kshishkov has day job while you study around.. [09:35:17] <kshishkov> av500: also, if Diego had studied at Ukrainian university instead, he'd be either graduated or kicked out by this time [09:35:41] <av500> so, if you hide long enough from being kicked, you get graduated? [09:37:16] <DonDiego> av500: that's a lie, i'm travelling around right now :) [09:37:26] <DonDiego> so neither studying nor working ;-p [09:37:39] <kshishkov> like me last year :) [09:37:41] <DonDiego> and hey, i just passed my final exam with flying colors.. [09:37:51] <av500> DonDiego: ic [09:38:03] <av500> congrats then [09:38:31] <kshishkov> av500: well, the common rule for .ua is that number of graduates should be equal to the number of enrolled people. [09:38:41] <av500> DonDiego: so now you are done, or still missing a "schein" from 2nd semester? [09:39:02] <kshishkov> av500: so unless you do something extreme (like not showing at uni for a year) you'll pass at least for bachelor degree [09:39:20] <av500> what if you die suddenly, they graduate somebody twice? [09:40:11] <DonDiego> av500: i'm "scheinfrei" since ages, but i'm missing the thesis, plus the final exam for my minor (philosophy) [09:40:25] <av500> ah, so you are not done at all [09:40:39] <kshishkov> av500: no, some losses are tolerated [09:41:37] <av500> ic [09:42:11] <av500> as long as dying suddenly is not the only accepted way to not graduate... [09:42:39] <kshishkov> nowadays you can also stop paying :) [09:42:43] <mru> http://thedailywtf.com/Articles/The-Suicide-Door.aspx [09:45:45] <kshishkov> yes, good story about not thinking of every possible input handling [09:48:58] <KotH> mru: you should see the new gym they build for the ETH.. it was a star architect... who didnt even talk to the group who is running the gyms [09:49:16] <av500> and, can it be used as a swimming pool as well? [09:49:58] <KotH> mru: and yes... after a recent heavy rain (havier than usual, but still not unusally bad), the _whole_ gym (which is a >1000m^2 building) was flooded [09:50:12] <KotH> av500: now they can [09:50:22] <av500> multi role [09:50:29] <KotH> it has been closed for repearse the last 3 weeks and will be closed for another 1-2 months [09:50:41] <KotH> repear* [09:51:57] <av500> repair [09:52:26] * KotH knew that something was straing [09:52:29] <KotH> er.. strange [09:52:31] <KotH> fuck... [09:52:45] * KotH goes to hide in a hole until he can type correct english again [09:53:01] <mru> they don't teach english typing in holes afaik [09:53:13] * av500 hopes the hole does not get flooded as well [09:54:15] <kshishkov> av500: maybe that hole was digged by proper Swiss architect? [09:55:04] <kshishkov> *dug [09:55:12] <cartman> configure: check_cflags -Werror=implicit-function-declaration [09:55:13] <cartman> nice [09:55:16] <cartman> breaks mingw shit [09:56:01] <mru> yes, mingw is shit [09:56:05] <mru> and they refuse to fix it [09:56:32] <cartman> I bet :) [09:58:09] <cartman> FFmpeg-devel - compile issues under mingw-cross-env [09:58:10] <cartman> heheh [10:06:58] <cartman> well it runs \o/ [10:13:13] * mru drops the fate-bomb [10:13:26] * KotH watches the fireworks [10:15:04] <astrange> i was going to say add -no-integrated-as to the clang build if you want it to work, but it looks like you found a new problem with it [10:15:29] <mru> it's the register allocator failing [10:15:32] <mru> on some inline asm [10:16:06] <j-b> where can I get the old fate ? </troll> [10:17:14] <KotH> there is no fate but what we make ourselves [10:17:44] <Dark_Shikari> there is no fate. it is only yourself that fails. [10:18:19] <cartman> religion is a disease [10:19:13] * j-b doesn't see the mingw bots [10:19:41] <mru> they haven't been assimilated yet [10:20:00] <KotH> religion ist das opium des volkes! </marx> [10:24:08] <Dark_Shikari> mru: I would like to say that your fate is totally sweet [10:26:42] <mru> web design is not one of my stronger skills, but I try my best [10:26:58] <thresh> be sure to add tag cloud [10:27:02] <thresh> and voting [10:27:26] <mru> up/down votes like on reddit/hn etc [10:27:35] <mru> and a facebook like button of course [10:29:07] <mru> I should make the raw data available too [10:29:11] <mru> in case someone wants to tinker [10:29:59] <av500> failing entries should be linked to "revert in SVN" buttons [10:30:06] <mru> :-) [10:30:27] <spaam> av500: :DD [10:30:46] <thresh> also, fate needs xmpp-based ajax chat. [10:31:01] <av500> "discuss fate" [10:31:39] <mru> hey, it has some javascript on there [10:31:44] <mru> that should be good enough [10:32:05] <mru> and syntax highlighting in the error diffs [10:33:51] <av500> for compile failures could it show the end of the log by default? [10:35:10] <mru> I guess [10:35:27] <Dark_Shikari> hmm. I wrote a nice little app that automatically greps files for some tables in x264 [10:35:33] <Dark_Shikari> and automatically checks for different datatypes of those tables [10:35:52] <Dark_Shikari> it can probably be generalized to pick up any arbitrary datatable input and look around for it. [10:36:56] <Dark_Shikari> example: [10:37:03] <Dark_Shikari> MATCH to coeff_abs_level_transition of size 1 at 2dfcf0 in file QTSystem/QuickTimeH264.qtx! [10:37:07] <Dark_Shikari> MATCH to x264_lambda_tab of size 4 at 2dc328 in file QTSystem/QuickTimeH264.qtx! [10:37:11] <Dark_Shikari> http://pastebin.org/432364 code [10:39:57] <av500> sell it to mpegla? [10:40:23] <Dark_Shikari> lol, you can find x264 itself easily enough using "strings" [10:40:30] <Dark_Shikari> this is moreso to find people copying tables from x264 [10:40:44] <av500> Dark_Shikari: some cleaver people might remove strings [10:40:44] <Dark_Shikari> and moreso sflc than mpegla ;) [10:40:51] <av500> -a [10:41:05] <Dark_Shikari> some strings are necessary for functionality [10:41:10] <mru> chop them off with a cleaver? [10:41:14] <av500> yeah [10:43:00] <astrange> encrypt the tables with xor against the license text [10:43:20] <Dark_Shikari> lol [10:43:37] <Dark_Shikari> the viginere cipher is so passe [11:32:14] * cartman wonders how did he manage to produce all-black PPM files with ffmpeg [11:32:21] <cartman> outdated howtos probably [11:34:04] <av500> all black input? [11:34:24] <CIA-92> ffmpeg: stefano * r24594 /trunk/libavfilter/vf_crop.c: [11:34:24] <CIA-92> ffmpeg: Compute the max pixel step for each plane, and use it in place of [11:34:24] <CIA-92> ffmpeg: hardcoding that value in a switch. [11:34:24] <CIA-92> ffmpeg: More compact and correct. [11:35:16] <DonDiego> gtg, cu [11:35:50] <cartman> av500: bad joke [11:35:57] <cartman> at least I managed to get garbage now :P [11:38:18] <cartman> yihaaa it works! [11:38:19] <cartman> := [11:38:23] * cartman dances [11:39:07] <KotH> cartman: no zurna/davul? [11:39:17] <cartman> KotH: dual zurna davul even :D [11:39:24] <KotH> hehe [11:39:50] <cartman> ;> [11:39:57] * cartman hugs KotH [11:41:06] * KotH feels hugged [11:41:25] <cartman> I really need deblocking now [11:41:26] <cartman> hi hi [11:41:49] * KotH wonders what kind "food" cartman eats [11:42:16] <cartman> usual Turkish food, you should visit Istanbul and eat a dinner with me & wife [11:42:47] <KotH> cartman: well.. last time i was in istanbul, you went into hiding ;) [11:43:45] <cartman> KotH: I had an appointment with dentist, which I revisited 2 months ago and need to visit again soon :-P [11:44:07] <cartman> I promise I will not have toothache this time :P [11:45:59] <thresh> uhm, Turkey [11:46:36] <cartman> works with AVC1 in MKV too [11:46:43] <cartman> ffmpeg > DirectShow :P [11:46:53] <cartman> now to find a way to embed this into Qt [11:56:48] <CIA-92> ffmpeg: stefano * r24595 /trunk/libavfilter/vf_crop.c: Make config_input() return AVERROR(EINVAL) in place of -1. [12:05:18] <CIA-92> ffmpeg: mstorsjo * r24596 /trunk/libavformat/ (19 files): Remove mostly unnecessary rtpdec_*.h files, store the declarations in one file [12:22:25] <Tjoppen> it seems the day I need to figure out how to choose between PUT and POST in lavf/http.c has arrived [12:22:53] <Tjoppen> ah, BBB isn't around. maybe I should post an RFC on the list [12:23:05] <av500> we could vote? [12:23:08] <mru> put it in the post, royal mail will do the rest [12:23:13] <mru> or not [12:24:13] <Tjoppen> does rtsp really need post, or would put suffice? my guess is "no" [12:25:47] <wbs> Tjoppen: yes, it needs post [12:26:07] <wbs> I don't think all those rtsp servers implementing the apple http/rtsp tunneling spec supports anything else than post [12:26:08] <Tjoppen> isn't it an indempotent operation though? seems like an oversight [12:26:21] <Tjoppen> *idempotent [12:26:40] <mru> http post sends a bunch of parameters and expects a response [12:26:58] <mru> put is a different operation [12:27:35] <mru> there's also DELETE [12:28:47] <Tjoppen> it's not really uploading form data though. in those cases they shouldn't differ much, apart from semantics [12:29:11] <wbs> apart from all specs about it saying that the methods involved are "POST" and "GET" and nothing else [12:29:41] <Tjoppen> fair enough. I would like to be able to use PUT with the HTTP handle though (no tRTSP related) [12:29:48] <Tjoppen> *handler [12:30:12] <wbs> since some time, you're actually able to set options on the http URLContext before making the connection [12:30:17] <cartman> I managed to write the lamest video player \o/ [12:30:27] <wbs> is that acceptable for you, if you're using url_open() etc directly? [12:30:37] <Tjoppen> seems fair enough. looked at it a bit [12:30:59] <Tjoppen> well, looked at ff_http*, but I'm guessing those aren't public [12:31:08] <wbs> no, they aren't unfortunately [12:31:16] <Tjoppen> something like av_http_set_method() [12:31:17] <wbs> but you can set options in an even more nifty way [12:31:51] <wbs> you can do av_set_string3(urlcontext->priv_data, "optionname", "value", 0, NULL); [12:32:48] <wbs> if you compare to the rtsp/http stuff, instead of doing ff_http_set_chunked_transfer_encoding(rt->rtsp_hd_out, 0);, we could as well do av_set_string3(rt->rtsp_hd_out->priv_data, "chunksize", "-1", 0, NULL); [12:34:55] <Tjoppen> hm [12:36:04] <Tjoppen> isn't priv_data a HTTPContext though? does it just stick those strings after the struct? [12:36:24] <wbs> are you familiar with AVOptions in general? [12:37:44] <Tjoppen> nope. I see it uses AVClass and other stuff [12:37:47] <wbs> yes [12:37:50] <wbs> basically, it works like this [12:38:01] <wbs> it can set options on any struct without you knowing the layout of the struct [12:38:28] <wbs> AVFormatContext and AVCodecContext have an AVClass* as their first member [12:38:53] <wbs> the AVClass points to a list of AVOptions, that map a set of options into struct offsets [12:39:12] <wbs> so without knowing the exact layout of the struct, you can tell av_set_string() to set some options on the struct [12:39:29] <Tjoppen> ah, cool. yeah, that makes sense [12:39:44] <wbs> if it finds a matching option, it writes the value at the correct offset in the struct in the correct format (string, int, float etc) [12:40:00] <wbs> normally, if you're using AVFormatContext, you chould still just set it manually [12:40:18] <wbs> but for the urlcontexts, where the URLContext->priv_data struct declaration differs between all protocols, you can't do that [12:40:25] <Tjoppen> meaning the above example should use av_set_int() [12:40:50] <wbs> perhaps there's such a method, too, av_set_string works, too, it parses out the number from the string I gave it [12:41:08] <wbs> av_set_string is what cmdutils/ffmpeg.c uses at least [12:41:44] <wbs> as long as know that the urlprotocol you're using has set an AVClass as the first member of its priv_data, you're free to set options in that way. currently only http does it [12:42:01] <Tjoppen> why use priv_data? just set the options on the URLContext. it seems to have an AVClass var [12:42:21] <wbs> but that is the AVClass for the generic URLContext [12:42:31] <wbs> which only can set values with an offset from the start of the URLContext struct [12:42:45] <wbs> it can't dereference the priv_data pointer, since what we want to set is http specific [12:42:45] <Tjoppen> aha. hm [12:45:17] <KotH> mru: apropos fate: didnt you get path64 workign? [12:45:27] <mru> more or less [12:45:31] <mru> I'll add it later [12:46:48] <Tjoppen> was just about to suggest a flag or something for signaling the use of AVClass in priv_data, but then I saw priv_data_class [12:47:20] <Tjoppen> so to be save one should be able to check that it's non-NULL [12:47:49] <wbs> yes, that could be one way of determining if you can do that [12:47:57] <Tjoppen> url_alloc_for_protocol() does that [12:48:04] <mru> still no fate flames... [12:48:50] <wbs> Tjoppen: yes.. for cases where you know that it's a http context, you could skip it, assuming that we'll never remove the AVClass from its context, but if you want to be on the safe side, sure [12:49:26] <Tjoppen> av_set_string3(priv_data, "method", "PUT", ...); in other words. would also allow using DELETE if the user wished that [12:50:35] <wbs> yeah, something like that would probably work [12:51:11] <Tjoppen> btw, doesn't URLProtocol belong in lavu instead of lavf? [12:51:24] <Tjoppen> always seemed rather wierd to me [12:51:51] <wbs> or libavcore? ;P [12:52:21] <peloverde> How dare you pollute libavcore with network stuff ;-p [12:52:33] <mru> we need libavnet [12:52:48] <cartman> libavwtf [12:52:59] <kierank> there's going to be a lot of libav libs soon [12:53:09] <kierank> with libavsequencer appearing on the horizon... [12:53:14] <mru> lol [12:53:20] <mru> that will never hit svn [12:53:21] <kshishkov> mru: we need libav[a-z] [12:53:33] <Tjoppen> I wonder how much more the protocols would need before being able to replace libcurl [12:53:43] <mru> libavcurl [12:53:46] <wbs> Tjoppen: quite a bit [12:53:55] <av500> kierank: libavsequencer will know the correct sequence of all the other libav libs? [12:53:58] <Tjoppen> libavnotusingcallbacksforbasicio [12:54:02] <wbs> I've been reading the libcurl code, it has insane amounts of corner cases for god knows what [12:54:02] <kierank> [13:53] <@mru> that will never hit svn --> i think we all know that [12:54:20] <cartman> wbs: specs means corner cases [12:55:10] <wbs> yeah, true, but in curl's case it's more that it can be used in so very diverse environments with different expectations on what should be done [12:55:30] <wbs> for the simple case of pulling data over http, optionally removing chunked encoding, as our http handler does, things are very much simpler [12:56:01] <Tjoppen> true. too bad it uses callbacks though [12:56:08] <mru> callbacks are evil [12:56:43] <mru> at least if used for anything beyond trivial notifications [12:56:47] <Tjoppen> I had a lot of "fun" trying to get data between libmicrohttpd's callbacks and libcurl's callbacks [12:57:01] <mru> sounds like fun indeed [12:57:05] <wbs> Tjoppen: is the code using the put/delete ever landing in ffmpeg btw? if not, it can be quite hard to maintain the http custom method code, if ffmpeg itself has no way of actually testing those code paths [12:57:50] <Tjoppen> I'd be happed just being able to replace POST with PUT. maybe we could just have it as an int option: "use_put" 0/1 [12:59:57] <Tjoppen> btw, can the user be informed of these option in some way? like documenting them in some header? [13:00:19] <Tjoppen> http.h wouldn't do, since that isn't exporte [13:00:25] <Tjoppen> d [13:01:03] <wbs> I guess it could be acceptable somewhere - it makes the things a bit more official though, so we can't remove them without breaking compatibility [13:01:27] <wbs> but I think that framework is quite good in the shape it is now, so I don't think that's a problem [13:02:01] <cartman> Is WMV HD == VC1 ? [13:02:29] <merbzt> cartman: close but no cigar [13:02:45] <cartman> merbzt: wonder if ffmpeg will decode it [13:03:13] <spaam> try [13:03:21] <cartman> will do, in a sec ;) [13:03:50] <spaam> im waiting ;D [13:04:46] <kierank> you do it spaam [13:05:32] <cartman> yeah it does decode it [13:06:07] * cartman decodes Taxi3 1080p sample [13:06:39] <spaam> kierank: i did :D [13:07:58] <kshishkov> maybe it will decode VC-1 interlaced one day... [13:08:39] <kshishkov> too bad the first frame I tried decoding had both I and P fields [13:09:18] <av500> the P refs the I from the same frame? [13:11:36] <kshishkov> yes, that's the first frame [13:13:16] <kshishkov> at the that picture book (SMPTE 421m) says so [13:19:02] <kierank> hmm internet archive has a suprising number of smpte standards in it [13:19:05] <lu_zero> yaaawn [13:19:17] * lu_zero is falling asleep already [13:19:26] <kierank> like http://web.archive.org/web/20031206215137/http://www.smpte.org/smpte_store/… [13:23:38] <lu_zero> mru: the troll brewer limit for a custom beer is around 1k bottles [13:24:02] <lu_zero> they won't have problems to directly sell mix of beers from the normal batches [13:24:36] <av500> mix? [13:24:59] <kshishkov> av500: have you ever cooked omelette? [13:25:07] <av500> from mixed beer? [13:25:32] <av500> no [13:25:35] <lu_zero> av500: any within their normal batches [13:26:00] <lu_zero> let me rephrase [13:26:21] <lu_zero> if we want a custom beer we need to take 1k bottles of it and he couldn't do that now [13:26:40] <mru> and for a custom label? [13:26:44] <lu_zero> if we want to buy any of his currently brewed beers he has no problem in directly selling [13:26:52] <lu_zero> mru: I hadn't ask yet [13:27:05] <lu_zero> tell me the questions and I'll act as translator [13:27:17] <benoit-> could be good, indeed [13:27:54] <lu_zero> I should get the foundation website done for such stuff, our ffmpeg.org website isn't good for getting non tech sponsors [13:28:31] <benoit-> lu_zero: I'd give money to help having a custom FFmpeg beer :) [13:28:48] <benoit-> hmm, actually: s/I'd/I'll/ [13:28:50] <KotH> FFbeer? [13:29:01] <av500> why not buy a beer and print custom labels [13:29:02] <KotH> i hope there will be also some FFnonalcoholibeverage [13:29:15] <kshishkov> unless recipe is bikeshedded it's not a proper FFbeer [13:29:17] <benoit-> KotH: we could buy oranges [13:29:24] <benoit-> kshishkov: true [13:29:26] <av500> FForanges [13:29:33] <thresh> one can steal oranges in Turkey really ease [13:29:33] <kshishkov> FFruits [13:29:35] <av500> FFfrout [13:29:35] <thresh> easy [13:29:37] <KotH> though, i'd rather like some FFchocolate [13:29:37] <av500> damn [13:29:58] <kshishkov> KotH: you're the man, make some [13:29:59] <benoit-> KotH: well... they would have to be french chocolates, so you would'nt agree anyway [13:30:00] <mru> KotH: you live in the land of chocolate... [13:30:27] <KotH> mru: you mean i shall ask whether sprüngli would custom lable some chocolate for us for next LT? [13:30:32] * benoit- kindly reminds that french chocolates don't find their way to Ukraine [13:30:36] <KotH> how much budget do i have? [13:30:48] <mru> KotH: ask whichever chocolatier you prefer [13:30:55] <mru> might be easier with a smaller one [13:30:56] <KotH> benoit-: why french? [13:31:03] <mru> ffrench? [13:31:04] <benoit-> KotH: ask for an invoice (?) and we'll see :) [13:31:12] <kshishkov> benoit-: actually some of it did (bought in Sweden, of course) [13:31:28] <benoit-> kshishkov: the ones I sent over to you never made it, though [13:31:29] <KotH> benoit-: i dont think you want to go that way... you dont know what kind of chocolate i prefere...and in which quantities [13:31:44] <av500> huge quantities? [13:31:53] <mru> daily dose, 1kg [13:31:57] <benoit-> KotH: well, you are to act for the rest of us; try to be... fair? [13:31:58] <KotH> av500: as a point of reference: what you got was a very small package [13:32:06] <av500> :) [13:32:06] <benoit-> mru: 7 days, you're ill [13:32:17] <mru> benoit-: only with french chocolate [13:32:20] <av500> KotH: I still have some of it [13:32:22] <mru> benoit-: swiss is safe [13:32:27] <KotH> av500: o_0 [13:32:34] <KotH> av500: they dont get any better ^^' [13:32:38] <benoit-> mru: wan I use this last sentence as a topic ? :D [13:32:38] <av500> KotH: and my wife is not allowed chocolate atm :) [13:32:49] <KotH> benoit-: well.. being fair and using myself as a reference doesn't work [13:32:56] <KotH> av500: doh! [13:33:00] <benoit-> KotH: I was about to say it :) [13:33:08] <kshishkov> av500: eat her share, you can do that! [13:33:15] <av500> kshishkov: of course [13:33:24] <mru> morning BBB [13:33:29] <BBB> howdy [13:33:32] <BBB> what did I break? [13:33:34] <benoit-> KotH: OK... I'll need your snail address bak, so that I can send you some good french chocolate [13:33:38] <benoit-> hey BBB [13:33:41] <mru> we should ask the blender guys for a custom render of BBB [13:34:03] <BBB> Vitor1001: just apply, I haven't had a chance to test it yet but I'm sure fate will complain if it breaks [13:34:10] <kshishkov> mru: too bad nobody has taken photo of BBB and lu_zero working at RT*P [13:34:20] <mru> benoit-: whois has some address for him [13:34:23] <mru> on idea if it works [13:34:25] <mru> *no [13:34:28] <KotH> benoit-: so that you get an idea: i'm known to eat >1kg/d over weeks... and >0.5kg/d over months [13:35:02] <lu_zero> KotH: thehehe [13:35:03] <kshishkov> KotH: heh, I can easily do >1kg/ms [13:35:23] <KotH> kshishkov: eat? that i'd like to see [13:35:33] <KotH> kshishkov: even thought it is a waste of good chocolate [13:35:36] <benoit-> KotH: well, then I'll send you something to last about few hours [13:35:39] <benoit-> maybe minutes [13:36:04] <lu_zero> so [13:36:11] <lu_zero> FFbeer and FFchocolate [13:36:13] <KotH> benoit-: well.. i'm not eating that much anymore... maybe around 1kg/week or something like that [13:36:20] <BBB> lu_zero: have you looked at that weird x-pn-wmt format as sent by real servers for asf? [13:36:25] <kshishkov> KotH: ok, wrong scale. [13:36:29] <BBB> lu_zero: maybe j0sh should implement it ;) [13:36:29] <lu_zero> BBB: where? [13:36:30] <lu_zero> what? [13:36:43] <BBB> https://roundup.ffmpeg.org/issue1607 [13:36:57] <kshishkov> KotH: for me it's rather 0.1 kg per week [13:37:08] <BBB> I hacked rtpdec_asf.c to work with it, it's a cruel hack and breaks original asf support, but now that we know how it works, someone can finish it ;) [13:38:22] <benoit-> lu_zero: and yes, if you manage to have a beer brewed for FFmpeg, that'd be great [13:38:32] <KotH> kshishkov: well.. you grew up w/o any good chocolate [13:40:45] <lu_zero> benoit-: 1k bottles [13:41:07] <benoit-> lu_zero: what's the price of one bottle ? [13:41:17] <kshishkov> KotH: I still managed to grow well [13:41:32] <Tjoppen> speaking of beer, my red ale is about halfway through fermenting :) [13:41:53] <lu_zero> benoit-: I'll ask [13:42:23] <benoit-> lu_zero: cool [13:42:34] <benoit-> we'll make a pole :) [13:42:57] <lu_zero> common retail price is around 8-9e with 10 for something I'm afraid to try... [13:43:04] <lu_zero> (yes, _afraid_) [13:44:30] <benoit-> lu_zero: well, indeed, less than a euro for a beer looks scary to me too [13:44:42] <benoit-> do we have FFdevs in Belgium ? [13:44:56] <lu_zero> to check for other beerplaces? [13:45:55] <benoit-> yup [13:48:05] <kshishkov> try elenril instead [13:49:52] <lu_zero> btw how many? [13:49:52] <KotH> kshishkov: plants and animals often grow large when there is less food/nutrition ;) [13:50:04] <benoit-> mru: can you (briefly) explains how the new fate works? is it just a matter of running make fate on a machine, and then send the results somewhere? [13:50:40] <benoit-> (or not briefly ;)) [13:50:44] <mru> benoit-: I'll write up a description tonight [13:50:55] <benoit-> mru: OK, fair enough. [13:51:01] <lu_zero> mru: how many bottles is one of the requests [13:51:27] <lu_zero> and which kind [13:51:29] <benoit-> lu_zero: actually, it directly depends on how much we're willing to pay. [13:51:37] <mru> benoit-: it's quite simple, but I'd rather not explain it over and over [13:52:03] <benoit-> mru: no problem, I can understand that... I have coworkers :) [13:52:08] <mru> we should get a crate of that Bink beer... [13:52:51] <lu_zero> Bink? [13:52:54] <lu_zero> why? [13:53:24] <mru> it exists [13:54:54] <benoit-> lu_zero: are you afraid of it too ? [13:55:11] <lu_zero> I wonder how it is [13:55:45] <kshishkov> and something stronger called "Smacker" then [13:56:35] <kshishkov> and juice in cardboard packs with a straw under "VP8" label [13:56:57] <lu_zero> http://www.brewdog.com/ is yet another possibility [13:58:17] * kshishkov thinks that FFmpeg devs should've started with cola [14:00:21] <benoit-> kshishkov: cola is available at work [14:02:21] <kshishkov> benoit-: not the special brand for fixing bugs [14:03:45] <lu_zero> kshishkov: find a cola producer [14:03:46] <lu_zero> hmm [14:03:54] <lu_zero> I could ask as well... [14:06:20] <lu_zero> kshishkov: vp8 isn't that dull [14:06:39] <janneg> the club mate brevery has mate cola [14:07:47] <Tjoppen> ooh, brewdog and mikkeller are collaborating to create an imperial IPA [14:21:49] <BBB> Tjoppen: oh, AVOption works? [14:21:53] <BBB> who implemented that? :-p [14:22:13] <lu_zero> janneg: do you have way to ask for a price for a custom cola? [14:23:00] <BBB> oh right, wbs did [14:23:08] <BBB> Tjoppen: that's a cool patch! [14:27:49] <BBB> lu_zero: what was the conclusion on latm rtsp support? [14:27:53] <BBB> lu_zero: I might do that next [14:29:20] <Tjoppen> BBB: I assume it works, because chunksize is there :) [14:29:30] <BBB> Tjoppen: you tested that it works right? [14:29:38] <Tjoppen> I'm actually on vacation, doing my thesis in the office. overtiming this [14:29:44] <BBB> oh... [14:29:46] <BBB> hmm... [14:29:49] <Tjoppen> well, no. that's why I said it's mostly for discussion [14:29:52] <BBB> some testing of this would be useful ;) [14:30:05] <Tjoppen> indeed. but have to go now. maybe later today or tomorrow :) [14:30:15] <lu_zero> BBB: remind me the url [14:30:20] <BBB> rtsp://qt-ar.as34763.net/ar32.sdp [14:30:41] <lu_zero> uhm [14:30:52] <peloverde> Aren't we still waiting for janneg's LATM patch? [14:30:53] <lu_zero> on the mplayer ml somebody is talking about the broadcom decoder [14:31:07] <lu_zero> BBB: is it supposed to crash [14:33:15] <BBB> not sure [14:33:18] <BBB> I hope not [14:33:54] <mru> lu_zero: what bcm decoder? [14:35:07] <lu_zero> BCM70010/BCM70012 [14:35:45] <cartman> does http://gist.github.com/500615 make sense? [14:35:51] <cartman> atom should have fast cmov too [14:37:04] <peloverde> does it? A lot of things are squirrelly about the early atoms [14:38:22] * cartman checks if there is a way to check that [14:39:01] <cartman> Dark_Shikari: any idea if cmov is fast in Atom chips? [14:39:44] <lu_zero> BBB: it basically hangs [14:40:12] <lu_zero> want me to trace how it misbehaves? [14:40:15] <mru> "is cmov fast in atom chips", "it basically hangs" ... hmm [14:40:52] <cartman> mru: ;) [14:43:28] <Honoome> they replaced the silicon for cmov with the one used for hlt [14:43:39] <mru> HCF? [14:43:52] <av500> +1 [14:46:39] <BBB> lu_zero: it hangs because we don't have a depayloader for it [14:46:46] <BBB> lu_zero: the fix is to implement the depayloader [14:46:49] <BBB> it shouldn't crash though [14:47:44] <lu_zero> BBB: it should error out [14:49:10] <BBB> it doesn't :-p [14:49:22] <BBB> av_find_stream_info() can loop for an hour [14:49:32] <BBB> especially on low-bitrate network (live) streams [14:49:56] <av500> it has to pull the whole stream :) [14:55:18] <lu_zero> BBB: we should fix that sooner or later [14:55:30] <lu_zero> it makes using ffmpeg for certain task next to impossible =P [14:55:54] <BBB> go for it [15:59:45] <j0sh> lu_zero, is there any way to the rtp sequence number in the depacketizer? [15:59:59] <j0sh> i can compare timestamps but that won't tell if we're missing a frame [16:00:05] <j0sh> s/frame/packet [16:02:39] <BBB> really, imo rtpdec.c should do that for all [16:02:51] <BBB> individual depacketizers shouldn't have to deal with that [16:02:55] <j0sh> ok [16:03:01] <BBB> so that's fine for now, don't worry [16:03:03] <j0sh> i'll just look at timestamps then [16:03:06] <BBB> but that's a great feature for later [16:03:20] <BBB> timestamps are also for rtpdec.c, you shouldn't have to deal with it [16:03:22] <j0sh> this vp8 phantom packet thing is driving me crazy [16:03:34] <BBB> the phantom packet is likely caused by somthing else [16:03:39] <BBB> don't add random hacks to get rid of it [16:03:44] <BBB> figure out what causes it [16:03:47] <BBB> and get rid of that :) [16:04:15] <j0sh> the packetizer looks fine though [16:04:16] <j0sh> hmm [16:04:53] <BBB> use wireshark to look at the data on the wire [16:04:58] <BBB> see if anything looks wrong [16:05:18] <BBB> then you know if it's depacketizer or packetizer [16:05:28] <BBB> alternatively, hook your packetizer up with gst's depcketizer [16:05:31] <BBB> or the other way around [16:06:26] <j0sh> yeah i should try gst [16:06:43] <BBB> btw great work on getting vp8 in, that was rather early [16:07:45] <j0sh> it was pretty easy, but it's always the last 10% thats the hardest, like now :) [16:07:46] <Honoome> lu_zero: should we add support for feng to stream vp8? :P [16:08:00] <j-b> yes [16:09:49] <BBB> j0sh: you'll get it working, just know the policy: no hacks,we want good code :) [16:09:53] * BBB brb [16:10:06] <j0sh> heh [16:12:19] <Honoome> mru: hrm, I'll have a look at your fate web view at some point, might be able to use it for the gentoo tinderbox :P [16:15:49] <peloverde> mru: Do you think you can get me a MIPS backtrace for AAC for al07_96? [16:16:07] <mru> peloverde: of course I _can_ [16:16:15] <mru> I just have to take the time to do it [16:16:52] <peloverde> well when you have time then [16:17:07] <Honoome> mru: if you can make it so you can attach additional logs together with the report (backtrace in this case, config.log for the tinderbox :P) it would definitely be perfect for my case :P [16:17:45] <mru> that's a trivial change actually [16:46:52] <lu_zero> 18:07 < Honoome> lu_zero: should we add support for feng to stream vp8? :P [16:46:53] <lu_zero> yes [16:47:51] <kshishkov> does it stream Tarkin? [16:47:59] <lu_zero> note [16:48:08] <lu_zero> gst uses another approach for vp8 [16:48:49] <lu_zero> kshishkov: it's slated after the nkfvf [16:49:23] <lu_zero> d [16:50:36] <Honoome> lu_zero: don tell me they stream vp8-in-mkv over rtp [16:54:39] <lu_zero> nah [16:54:50] <lu_zero> slightly different but not that brain damaged [16:55:20] <lu_zero> probably josh should post a followup pointing to the patches [16:56:40] <j0sh> lu_zero, gst rtp for vp8 doesnt look that different [16:56:49] <j0sh> they dont set the marker bit [16:56:51] <lu_zero> it was slightly different iirc [16:56:53] <j0sh> but we don't use that anyway [16:57:20] <lu_zero> we could use just the marker bit then ^^; [16:58:00] <lu_zero> still we need to make the parser aware of packet loss [16:58:08] <j0sh> i added that [16:58:16] <lu_zero> good =) [16:58:46] <j0sh> do you know how to force tcp when just streaming rtp? (not rtsp) [16:58:52] <j0sh> ?tcp doesn't seem to do anything [16:59:47] <lu_zero> you shouldn't be able to [17:00:06] <lu_zero> tcp is interleaving rtp in the rtsp tcp stream [17:01:00] <j0sh> trying to debug thatphantom packet issue and my captures are a bit confused. not sure if it's because the packetizer really is broken, or udp is just out of order [17:02:10] <lu_zero> uhmm [17:02:20] <lu_zero> having feng would help? [17:03:50] <j0sh> i'm doing ok with dss [17:04:01] <j0sh> it just mirrors whatever i send it [17:04:11] <lu_zero> ok [17:14:43] <Honoome> j0sh: I'll rephrase lu_zero.. "if you were to use feng and found a helluva bugs, feel free to tell us so we can actually get it to behave" :P [17:44:31] <mru> lol http://news.ycombinator.com/item?id=1561306 [18:31:07] <CIA-92> ffmpeg: jbr * r24597 /trunk/libavcodec/flacenc.c: cosmetics: pretty-print flacenc.c [18:35:28] <CIA-92> ffmpeg: jbr * r24598 /trunk/libavcodec/flacenc.c: Add 2 failed memory allocation checks [18:37:25] <j0sh> Honoome, does feng mirror streams? [18:37:35] <Honoome> define "mirror" [18:38:01] <j0sh> accepts an incoming stream, then reflects it back to whoever else may connect [18:38:22] <Honoome> j0sh: yes and no [18:38:28] <Honoome> feng alone won't, feng+flux will [18:39:16] <lu_zero> feng alone will =_= [18:39:31] <lu_zero> first let's fix the eventloop issue =P [18:39:38] <Honoome> lu_zero: how? [18:39:57] <Honoome> ah you mean will (in a long distant future)? [18:40:01] <lu_zero> dinner now =) [18:40:03] <j0sh> [rtsp @ 0x9ef27d0] method ANNOUNCE failed, 501 [18:40:08] <lu_zero> uhm [18:40:11] <lu_zero> Honoome: btw [18:40:12] <j0sh> thats what i get from feng [18:40:19] <lu_zero> monday with the other diego ? [18:40:22] <jenk> hey [18:40:25] <jenk> i made one of those! [18:40:35] <j0sh> jenk, yes, whats your github page again [18:40:38] <lu_zero> feng doesn't support ANNOUNCE (yet) =\ [18:40:41] <jenk> http://github.com/revmischa/rtsp-server/ [18:40:45] <jenk> supports ANNOUNCE and RECORD [18:40:47] <lu_zero> brb [18:40:48] <j0sh> thanks [18:40:51] <lu_zero> jenk: nifty [18:41:02] <jenk> you can mount streams on different urls [18:41:02] <lu_zero> ok one excuse less to support it as well [18:41:09] <jenk> its not totally finished [18:41:12] <jenk> its a work in progress [18:41:15] <jenk> but it "mostly" works [18:41:17] <j0sh> sweet [18:41:52] <Honoome> lu_zero: nope from me, messed up badly [18:46:05] <j0sh> how many dependencies does moose have? :) [18:47:32] <kshishkov> 2 - food and water [18:47:43] <Honoome> kshishkov: 1 - a rifle [18:47:56] <jenk> i dunno [18:47:59] <jenk> use cpanminus [18:48:28] <Honoome> kshishkov: actually I guess it means if you need the -dev version or not [18:48:44] <Honoome> *it changes [18:50:19] <kshishkov> Honoome: it's mooses who develop new mooses, people have nothing to do with that [18:50:50] <j0sh> jenk, is there any way to install to a custom directory? [18:51:12] <jenk> local::lib [18:51:17] <Honoome> kshishkov: for the binary version you're okay with just a rifle, but if you need the development tools, you need food and water as you said [18:51:53] <mru> and a minimum of two mooses [18:52:13] <Honoome> or you could use the split packages if you only need moose-head [18:52:24] * kshishkov remembers ELK format for some reason [18:52:52] <Honoome> mru: you know we're going down a dangerous road if we start to talk about client and server [18:53:41] <mru> and sockets [18:54:24] <Honoome> RPMC? (Remote Procedure Mating Call) [18:55:26] <j0sh> lol [18:58:26] <Honoome> k I'm off now, you can resume the productive stuff :P [19:00:19] <CIA-92> ffmpeg: jbr * r24599 /trunk/libavcodec/flacenc.c: Move debug logging of compression options to a single function. [19:03:49] <CIA-92> ffmpeg: jbr * r24600 /trunk/libavcodec/flacenc.c: [19:03:49] <CIA-92> ffmpeg: Do not need to set coded_frame->key_frame = 1 because it is already set in [19:03:49] <CIA-92> ffmpeg: avcodec_alloc_frame(). [19:15:55] * lu_zero is back [19:16:14] <lu_zero> Honoome: the productive stuff? [19:19:38] <CIA-92> ffmpeg: jbr * r24601 /trunk/libavcodec/flacenc.c: Set coded_frame->pts in the FLAC encoder [19:41:13] <CIA-92> ffmpeg: jbr * r24602 /trunk/libavcodec/flacenc.c: [19:41:13] <CIA-92> ffmpeg: cosmetics: change FlacEncodeContext variable name from ctx to s in several [19:41:13] <CIA-92> ffmpeg: places for consistency. [20:10:06] <CIA-92> ffmpeg: jbr * r24603 /trunk/libavcodec/flacenc.c: Pass FlacSubframe to output_subframe_* instead of channel number. [20:25:08] <CIA-92> ffmpeg: jbr * r24604 /trunk/libavcodec/flacenc.c: Combine and simplify output_subframe_constant() and output_subframe_verbatim(). [20:29:36] <CIA-92> ffmpeg: jbr * r24605 /trunk/libavcodec/flacenc.c: Combine and simplify output_subframe_fixed() and output_subframe_lpc(). [20:29:36] <CIA-92> ffmpeg: jbr * r24606 /trunk/libavcodec/flacenc.c: cosmetics: reindent [20:53:51] <CIA-92> ffmpeg: jbr * r24607 /trunk/libavcodec/flacenc.c: Combine and simplify output_residual() and output_subframe_lpc(). [21:07:27] <CIA-92> ffmpeg: jbr * r24608 /trunk/libavcodec/flacenc.c: Combine output_subframe_verbatim() and output_subframe_lpc(). [21:08:12] <CIA-92> ffmpeg: jbr * r24609 /trunk/libavcodec/flacenc.c: cosmetics: indentation [21:27:53] <CIA-92> ffmpeg: jbr * r24610 /trunk/libavcodec/flacenc.c: Remove unneeded variable. [21:33:08] <CIA-92> ffmpeg: jbr * r24611 /trunk/libavcodec/flacenc.c: Combine output_subframe() and output_subframes(). [21:34:40] <CIA-92> ffmpeg: jbr * r24612 /trunk/libavcodec/flacenc.c: cosmetics: indentation [23:08:31] <peloverde> This e-mail strikes me as bizarre: http://www.mail-archive.com/mp3encoder@geek.rcc.se/msg00091.html [23:09:21] <kierank> because he was threatened by them [23:10:10] <kierank> and iirc there was a lot of weirdness with the licensing when aac first came out [23:10:16] <mru> "working on mp3 is more interesting" [23:10:25] <peloverde> That seems odd, Dolby doesn't seem to hassle free software AAC implementations, meanwhile if you are doing MP3 above board you need to negotiate with like 3 different licensing organizations [23:10:28] <mru> drinking water is more interesting than beer cause it's free [23:10:47] <kierank> peloverde: in 1999 they were threatening people [23:11:04] <kierank> things have moved on a lot since then... [23:11:40] <peloverde> I guess a lot has changed, these days AAC licensing seems far more simple and straight forward [23:12:42] <kierank> iirc there was some sort of drm scheme that dolby was pushing for at the time [23:12:47] <kierank> which I think is what he's refering to [23:12:54] <peloverde> Also as far as copy protected bitstreams go, I don't recall any of the major early encoders using it [23:13:14] <kierank> possibly it was a condition to get the official licence [23:15:29] <Dark_Shikari> that makes sense -- they might have been trying to do it like blu-ray [23:15:34] <peloverde> Speaking of this, I'm still looking for historical licensing papers for AAAC [23:15:37] <Dark_Shikari> where to get a license, you need to implement the copy protection scheme [23:20:38] <peloverde> but it's not like lame has a license for MP3 [23:22:01] <Dark_Shikari> Yes, but people using LAME do. [23:22:09] <Dark_Shikari> and anyways, this was 1999. [23:22:11] <peloverde> Also if anyone has the agreement from the Via "MPEG-2 AAC" license program, i'd be interested to see it [23:22:20] <Dark_Shikari> did anyone ever use mpeg-2 aac? [23:22:30] <kierank> japanese tv [23:22:31] <peloverde> Most people use MPEG-2 AAC [23:22:37] <peloverde> Nobody uses PNS [23:22:43] <Dark_Shikari> I mean, before MPEG-4 came out [23:22:45] <Dark_Shikari> did anyone use aac? [23:23:01] <kierank> japanese tv still [23:23:01] <peloverde> no [23:23:27] <peloverde> but the AAC people use now is MPEG-2 AAC in an MPEG-4 container [23:23:34] <peloverde> no one uses any mpeg-4 only features [23:24:12] <peloverde> that said I don't think SBR/PS are in the MPEG-2 AAC licensing program as they were added later [23:25:17] <peloverde> And I recall a few people in the WinAMP forums back ~2000 being very pro-AAC, so they must have used it [23:26:27] <peloverde> But via bundles the current AAC licensing program with a whole bunch of shit nobody needs [23:26:58] <kierank> extra stuff like what? [23:28:37] <peloverde> Like LTP, Error Resilience [23:28:55] <peloverde> scalable [23:29:04] <kierank> oh extra stuff in the sense that you get the whole of mpeg-4 aac with the licence [23:29:12] <peloverde> yes [23:29:24] <peloverde> you get all the MPEG-4 features that no one uses [23:32:09] <kierank> xm radio apparently used mpeg-2 aac [23:32:35] <Dark_Shikari> hmm. so, BBB, wanna get trolling? [23:33:47] <kierank> who do you want to troll? [23:34:27] <Dark_Shikari> he proposed adding --vp8 to x264 [23:34:45] <kierank> next years gsoc [23:34:54] <Dark_Shikari> nah, two-week hackathon [23:35:08] <kierank> they'll be a circle of google [23:35:15] <kierank> google paying for their own codec to be implemented [23:42:03] <CIA-92> ffmpeg: aurel * r24613 /trunk/libavformat/avidec.c: 100l: av_freep() needs the address of the pointer [23:43:04] <bcoudurier> hi guys [23:54:14] <BBB> Dark_Shikari: let's start that tomorrow [23:54:58] <Dark_Shikari> BBB: ok, so the first thing I'd like you to do is add a vp8 option and just have it disable everything that we don't feel like implementing first [23:55:01] <Dark_Shikari> e.g. [23:55:03] <Dark_Shikari> ref=1 (no golden, no altref) [23:55:20] <Dark_Shikari> then next you'll need to implement the arithcoder [23:55:27] <Dark_Shikari> since writing headers requires it, iirc

1 0

IRC log for 2010-07-29
by irc＠mansr.com 30 Jul '10

30 Jul '10

[00:00:53] <CIA-92> libswscale: stefano * r31847 /trunk/libswscale/swscale.h: [00:00:53] <CIA-92> libswscale: Revert commit: [00:00:53] <CIA-92> libswscale: r31772 | stefano | 2010-07-23 01:01:31 +0200 (Fri, 23 Jul 2010) | 2 lines [00:00:53] <CIA-92> libswscale: Prefer impersonal form over third person, for consistency with the [00:00:53] <CIA-92> libswscale: rest of FFmpeg. [00:00:54] <CIA-92> libswscale: The change was not approved by the maintainer. [01:26:04] <efriedma> roughly 1% faster h264 decoding on my mobile core i5: http://paste.pocoo.org/show/242904/ [01:48:44] <Compn> vitor isnt in here is he ? [01:48:53] <Compn> oh , just not now , nm [01:49:07] * Compn replies on list [02:27:43] <Dark_Shikari> efriedma: you can do that with pmaddubsw [02:27:43] <Dark_Shikari> iirc [02:27:45] <Dark_Shikari> see x264 [02:28:05] <efriedma> Dark_Shikari: yeah, just wrote an implementation using that [02:28:56] <efriedma> i'll do some more benchmarking in a bit [02:33:36] <Dark_Shikari> x264 has an implementation of these, so compare yours to it [02:36:02] <Compn> hmm [02:36:04] <Compn> http://www.bealecorner.com/trv900/DVD/Maxell-DVDR-spots.html [02:36:13] <Compn> neat dvdr information there [02:36:28] <Compn> freezing = no good, baking = smart? hmm [02:47:08] <efriedma> Dark_Shikari: it looks nearly identical [02:47:57] <Dark_Shikari> you don't need two paddsw [02:48:14] <Dark_Shikari> oh wait nvm you do. [02:48:29] <Dark_Shikari> you should see if you can use another free register to pipeline it a bit better [02:48:36] <Dark_Shikari> i.e. do two rows at once or similar [02:48:39] <Dark_Shikari> you aren't using m2 [02:48:56] <Dark_Shikari> Then you can do packuswb m0, m2 [02:48:58] <Dark_Shikari> and movh/movhps [02:59:56] <efriedma> Dark_Shikari: is log2_denom a constant? [03:00:16] <efriedma> (in this context) [03:15:53] <Dark_Shikari> efriedma: no. [03:16:32] <efriedma> then could you explain how the x264 versions get away with "psraw m0, 6" [03:16:34] <efriedma> ? [03:17:43] <Dark_Shikari> x264 only uses implicit weighted bipred [03:17:51] <Dark_Shikari> it doesn't have to worry about supporting explicit mode [03:18:02] <efriedma> oh [03:18:12] <Dark_Shikari> explicit is rare atm, so you could make asm versions only for the regular mode. [03:18:16] <Dark_Shikari> If it helped a lot. [03:23:10] <efriedma> the only reason it might help is that it frees up a register [03:23:34] <Dark_Shikari> and variable shifts are slower than constant shifts on some x86 chips [03:23:41] <Dark_Shikari> like core 2 iirc [03:23:50] <Dark_Shikari> You could branch. [03:26:30] <Dark_Shikari> You could do a jump table and have one for each shift value. [03:26:39] <Dark_Shikari> Under the assumption that nobody changes much within a frame (sane) [03:29:15] <efriedma> not worth it to save 1 clock cycle per 8 pixels [03:31:03] <Dark_Shikari> that's all the unroll saves? [03:31:47] <efriedma> my instruction tables say on core i7, constant shift is 1 cycle, variable shift is 2 [03:31:56] <Dark_Shikari> I meant the unrolling due to extra reg [03:32:05] <Dark_Shikari> Or maybe you could make the instruction ordering better on x86_64 [03:32:08] <Dark_Shikari> and worse on x86_32 [03:32:16] <Dark_Shikari> to make up for the missing extra reg [03:32:21] <efriedma> oh... actually, i can unroll it with 1 reg [03:34:27] <efriedma> current version: http://paste.pocoo.org/show/242923/ [03:36:13] <Dark_Shikari> the 8x8 one should do two rows [03:36:24] <Dark_Shikari> via unroll [03:36:32] <Dark_Shikari> but yeah looks good [03:36:36] <Dark_Shikari> now write 8x8 and ssse3 [03:54:37] <efriedma> current: http://paste.pocoo.org/show/242927/ [03:56:54] <efriedma> umm, any ideas to speed up the bit before the loop? my profile shows it taking a non-trivial amount of time [04:00:14] <Compn> Dark_Shikari : btw is there any vp8 / h264 mmx routines that could be asm'd by vitor that would be useful for x264 ? [04:00:24] * Compn guesses not [04:03:03] <Dark_Shikari> why vitor [04:04:19] <Dark_Shikari> and what do you mean, mmx routines [04:04:25] <Dark_Shikari> if it's already an asm routine why does it need mmxing [04:10:13] <Compn> er good point [04:10:20] <Compn> vitor was asking what needed to be mmx > asm'd [04:10:24] <Compn> i think? [04:10:39] <Compn> not important, nm [04:11:27] <efriedma> Dark_Shikari: any comments on my patch? [04:13:44] <Dark_Shikari> looks fine to me. [04:16:12] <Dark_Shikari> oh, the new patch [04:16:13] <Dark_Shikari> didn't look [04:16:31] <Dark_Shikari> OPERATION is too long, pick a shorter word [04:16:32] <Dark_Shikari> STEP [04:16:33] <Dark_Shikari> OP [04:16:54] <Compn> bzzzt [04:17:00] <Dark_Shikari> 182 looks unnecessary, why not do that in scalar [04:18:23] <efriedma> Dark_Shikari: i don' [04:18:44] <efriedma> i don't know how to use cl with the cglobal macro [04:19:01] <Dark_Shikari> why do you need cl? [04:19:12] <Dark_Shikari> remove add r3, 1 [04:19:13] <efriedma> shift? [04:19:18] <Dark_Shikari> and then remove psrld m5, 1 [04:19:51] <efriedma> and then use padd? [04:19:57] <efriedma> i suppose that works [04:21:24] <Dark_Shikari> er, why padd? [04:21:30] <Dark_Shikari> I'm confused here [04:21:31] <Dark_Shikari> you are doing [04:21:35] <Dark_Shikari> (x << a) >> 1 [04:21:36] <Dark_Shikari> why not do [04:21:39] <Dark_Shikari> (x << (a+1)) >> 1 ? [04:21:44] <Dark_Shikari> er, I mean [04:21:48] <Dark_Shikari> (x << (a-1)) [04:22:19] <efriedma> i need r3+1 in an xmm register for the loop [04:23:24] <Dark_Shikari> ahhhh [04:23:27] <Dark_Shikari> I see. [04:24:19] <efriedma> so what do you suggest? [04:24:24] <Dark_Shikari> current is fine imo [04:24:46] <Dark_Shikari> for 16x16 the setup isn't very costly. [04:24:55] <Dark_Shikari> don't worry too much about it. [04:25:06] <efriedma> k [04:43:46] <efriedma> patch sent to ffmpeg-devel [04:49:23] <Dark_Shikari> passes regressions? [04:56:49] <Dark_Shikari> er, regression tests [05:04:27] <efriedma> Dark_Shikari: umm, how do i run h264 regression tests? [05:05:45] <Dark_Shikari> the fate tests? make fate or whatever [05:05:47] <Dark_Shikari> you have to have them downloaded [05:06:10] <Dark_Shikari> or [05:06:11] <Dark_Shikari> http://www.mediafire.com/download.php?mi2zjoynymi [05:06:15] <Dark_Shikari> decode every file here, compare md5 to old ffmpeg [05:09:31] <Compn> fate samples are on samples.mplayerhq.hu [05:09:35] <Compn> no need to mediafire ? [05:09:43] <Dark_Shikari> mediafire is faster, only one file to download [05:10:09] <Compn> faster than mphq? ehe [05:10:49] <Dark_Shikari> I mean yo udon't have to download 90 things... [05:11:16] <Compn> right [05:11:47] * Compn wonders what kind of bad browser doesnt have support for multiple downloading of files [05:11:59] <Compn> firefox needs downthemall, opera has links [05:12:06] <Compn> chrome ... well, chrome sucks [05:12:14] * Compn sleeps before he starts browser war [05:19:20] <efriedma> Dark_Shikari: k, thanks; passes regression tests [05:19:25] <Dark_Shikari> good. [06:11:08] <thresh> moroning [06:37:07] <mru> moins [06:37:19] <kshishkov> your name does not sound like that [06:37:45] <mru> in skÃ¥ne it does [06:37:50] <mru> ask pJok [06:38:06] <kshishkov> crazy near-Danish people [06:39:09] <cartman> moin [07:14:26] <KotH> günaydin arkadaslar [07:16:38] <kshishkov> same to you [07:18:39] <cartman> ehlo KotH [07:18:45] <cartman> I see you miss Turkish ;) [07:19:03] * kshishkov tries to watch how cartman is going to fetch mail from KotH [07:19:14] <cartman> fetch mail? :) [07:19:44] <xxthink> Hi, I use ffmpeg -i x.264 x.yuv to decode the yuv file [07:20:06] <xxthink> but this x.yuv file is different from the recon yuv file [07:20:26] <xxthink> Are there some postprocessing method used by ffmpeg [07:20:33] <xxthink> or it's a ffmpeg bug? [07:20:35] <kshishkov> cartman: if you greet somebody with "EHLO" it looks like POP [07:20:45] <Honoome> I just love when the tinderbox gets stuck for SEVEN HOURS on the same package because the test suite freezes X_X [07:20:47] <cartman> kshishkov: yeah indeed :P [07:21:31] <kshishkov> cartman: also you may be pleased to know that "bikeshed" in Russian is "saray" [07:21:37] <cartman> kshishkov: lol :D [07:21:38] <cartman> nice [07:21:49] <kshishkov> xxthink: it may be different YUV format after all [07:22:10] <xxthink> kshishkov: why [07:22:28] <xxthink> can I output the raw decoded yuv file by ffmpeg? [07:22:37] <kshishkov> because you can pack YUV into many different ways [07:22:47] <cartman> KotH: btw I wonder if there are any job opportunities in .ch for a C++/Qt/Python programmer with Linux/Win/WinCE background ;) [07:23:02] <KotH> cartman: i'm quite sure there are [07:23:13] <xxthink> kshishkov: I use jm to verify that the x.264 file is correct [07:23:18] <KotH> cartman: good people are always sought [07:23:27] <xxthink> but when I use ffmpeg to dump it, it doesn't match [07:23:30] <cartman> KotH: anything you can refer for your good old friend me? :D [07:23:44] <KotH> cartman: actually, i would like someone who knows how to code linux and windows at our comp :) [07:23:45] <kshishkov> KotH: he said C++/Qt/Python, nothing about being good :P [07:23:58] <KotH> kshishkov: öh.. i know cartman for some time already :) [07:24:01] <cartman> kshishkov: I am good, trust me :) [07:24:06] <cartman> not as good as you guys but [07:24:08] <xxthink> kshishkov: my yuv is 4:2:0, Y, U, V [07:24:08] <cartman> good ;) [07:24:14] <xxthink> why it doesn't work [07:24:26] <cartman> KotH: I can send you a CV so you could maybe check it out? :) [07:24:42] <KotH> kshishkov: and i know turkish people well enough not to trust anything they say unless i've verified myself ;) [07:24:48] <cartman> LOL [07:24:52] <cartman> good thinking KotH [07:25:06] * KotH always thinks good [07:25:07] <kshishkov> xxthink: I really cannot say anything without knowing how your reference YUV file was created [07:25:24] <KotH> cartman: you can send me your cv, but i'm quite sure that we currently will not hire you :-( [07:25:24] <kshishkov> KotH: I'll try to verify your words [07:25:33] <xxthink> my reference yuv file is the yuv file dumped by x264 when I encode it [07:25:38] <cartman> KotH: oh well, why not! :) [07:25:43] <KotH> cartman: there might be an opening in 2-3 months though [07:26:00] <kshishkov> xxthink: ask Dark_Shikari then [07:26:06] <xxthink> :) [07:26:12] <cartman> KotH: it would be OK if you could forward the CV to somewhere which might have an opening [07:26:22] <KotH> cartman: sure [07:26:40] <cartman> I just want to work somewhere in EU ;) [07:26:41] <xxthink> Dark_Shikari: do you know my problem? [07:26:46] <KotH> err.. [07:26:51] <KotH> cartman: .ch is _not_ EU [07:26:52] <xxthink> I use ffmpeg -i x.264 x.yuv to dump a x.yuv file [07:26:58] <KotH> cartman: which is not a bad thing, though ;) [07:26:59] <cartman> KotH: not as in union [07:27:05] <cartman> I mean as in Europe :) [07:27:10] <xxthink> but this yuv file is different from the recon file dumped by x264 [07:27:21] <kshishkov> cartman: I know one guy with the same dream [07:27:22] <KotH> cartman: .ch is not in europe either... if you believe some local parties [07:27:23] <xxthink> Dark_Shikari: do you know why? [07:27:50] <KotH> kshishkov: did you ever stand in front of the masses and started a speach with "i have a dream..."? [07:27:51] <av500> gm [07:27:51] <cartman> KotH: switzerland is not in Europe?! [07:28:06] <cartman> kshishkov: what dream? I am gonna make this a reality soon ;) [07:28:13] <kshishkov> KotH: I'm not black enough to do that [07:28:15] <KotH> m' av500 [07:28:17] <cartman> my dream would be lying down in Bahamas [07:28:18] <Honoome> cartman: by any definition minus the physical one [07:28:18] <cartman> not EU [07:28:29] <kshishkov> cartman: to work in Europe [07:28:37] <xxthink> Dark_Shikari: my x.264 is verifyed by jm [07:28:43] <cartman> kshishkov: bad dream ;) [07:28:56] <xxthink> the decoded yuv of jm is the same as the recon yuv dumped by x264 [07:29:05] <mru> cartman: there are bad dreams, and there are nightmares [07:29:09] <kshishkov> cartman: as a means of escaping from certain country by Black Sea [07:29:17] <cartman> kshishkov: ah lol [07:29:19] <cartman> true that [07:29:27] <mru> cartman: .ua would be the latter if kshishkov is to be believed [07:29:40] <cartman> .ua is a touch place [07:29:54] <cartman> though many people go there from Turkey to work [07:29:56] <cartman> tough* [07:30:09] <mru> kshishkov: ehlo is smtp, not pop [07:30:17] * kshishkov points out that Turkey also has Black Sea coast [07:30:20] <mru> or maybe both, I don't know pop [07:30:30] <kshishkov> mru: I don't know both [07:30:34] <cartman> I used ehlo for smtp [07:30:39] <cartman> remember using- [07:30:49] <kshishkov> or for KotH [07:31:24] <cartman> ;= [07:31:35] <cartman> kshishkov: you are in the .ua btw? [07:32:26] <kshishkov> cartman: no, I'm next to mru [07:32:48] <cartman> nice place [07:34:26] <KotH> kshishkov: next to mru? when did you move to .uk? [07:34:47] <kshishkov> KotH: it's mru moved, not me [07:34:57] <KotH> huh? [07:35:04] <cartman> lol [07:35:06] <KotH> mru: when did you move to .de? [07:35:06] <cartman> :> [07:35:17] <cartman> so kshishkov is in .de [07:35:18] <cartman> aha :P [07:36:19] * av500 saw both mru and kshishkov yesterday [07:36:21] <mru> KotH: I didn't move [07:36:29] <mru> .de came to me [07:37:03] * cartman waits for .se to come to him [07:38:19] * kshishkov would gladly swap .de for .se too [07:38:58] * cartman connects to his Windows CE 6 tablet for another boring day [07:39:24] <kshishkov> double lie - it's not "CE" and it's not 6 [07:41:35] <cartman> kshishkov: I got Windows CE 5 and Android tablets too [07:41:37] <cartman> happy now? [07:43:05] * pJok swaps kshishkov with .se [07:43:08] <kshishkov> cartman: it's called "Windows Mobile" and it's really 5.1 or 5.2 [07:43:29] <cartman> Mobile != CE [07:43:31] <cartman> kernel is different [07:44:58] * cartman even got ffmpeg encoding working at some point [07:45:08] <cartman> I should try again [07:45:08] <cartman> ! [08:12:17] <saintdev> peloverde: well i got lame windowing to almost match itunes :) [08:12:53] <av500> the itune leading the lame? [08:14:01] <saintdev> except for a couple of false positives on our side, but we also eliminate cases where itunes incorrectly stays short for long periods [08:24:51] <peloverde> thats good [08:26:34] <saintdev> *on castanets [08:26:40] <saintdev> peloverde: latest dump http://pastebin.org/427402 [08:26:45] <saintdev> and i'm off to bed. [08:49:24] <lu_zero> yawn [08:49:35] * av500 gives lu_zero coffee [08:49:44] <av500> or was it diet coke? [08:50:14] <cartman> I thought I was the only one drinking coke in the morning [08:50:49] <av500> better than doing coke in the morning [08:51:23] <cartman> nice [08:51:32] <cartman> I see some thedailywtf-worthy code in our codebase [08:51:35] <cartman> refreshing [08:51:40] <lu_zero> I prefer tea, iced [08:51:56] * lu_zero should do something simple thus boring [08:52:43] <kshishkov> try to do it in the most convoluted way then [08:53:09] * kshishkov sighs as he remember "The Incredible Machine" game series [08:55:24] <KotH> cartman: share it with us :) [08:55:41] <cartman> if( this->backendRootPath.size() == 0 || this->backendRootPath.size() == 0 || [08:55:41] <cartman> this->backendRootPath.size() == 0 || this->backendRootPath.size() == 0 || [08:55:41] <cartman> this->userId.size() == 0) [08:55:46] <cartman> 4 times the charm it seems [08:57:29] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/DepartmentOfRedundancyDepartment [08:57:36] <kshishkov> (ExtractBits(1) == 1) ? true : false [08:59:04] <mru> for (n = 0; n < 0; n++) ... [08:59:33] <cartman> I bet this was ClipboardInheritance [08:59:37] <cartman> CTRL-V multiple times [09:00:09] <av500> it's a fourfold redunancy, making sure it is really 0 [09:00:17] <mru> shortly before: M = foo; N = bar; 0 = baz; ... [09:00:35] <kshishkov> the same source! [09:00:44] <mru> we're not making this up [09:01:00] <kshishkov> but certain company did [09:03:46] <cartman> it would be nice if the code said, workaround a compiler bug [09:03:47] <cartman> :p [10:54:21] <siretart> god morgon [11:06:25] * kshishkov looks at siretart and still does not believe it [11:11:38] <mru> siretart: btw, the new fate can test branches [11:11:55] <mru> although only ones created after the test system overhaul [11:16:29] <siretart> kshishkov: it's 7am here [11:16:49] <siretart> mru: yay! who deserves the beer and kudos? [11:18:09] <mru> http://fate.mansr.com/ [11:20:19] <mru> it's still not quite complete [11:22:36] <siretart> wow, that looks really neat :-) [11:44:14] <kierank> lol rv9 had an interlace mode [11:44:23] <lu_zero> http://fate.mansr.com/report.cgi?slot=x86_64-linux-clang&time=20100728235201 [11:44:27] <lu_zero> x86? [11:44:41] <mru> it says so [11:45:09] <lu_zero> x86_64-linux-clang [11:45:23] <mru> yes [11:45:24] <lu_zero> doesn't compute well [11:45:33] <mru> what is not clear? [11:45:35] <lu_zero> x86_64-linux-clang building for x68? [11:45:37] <mru> no [11:45:50] <mru> which part of 64 is unclear? [11:46:28] <lu_zero> what got passed to configure made me uncertain [11:46:59] <kshishkov> kierank: and dquant, but I'm yet to see files with it [11:49:31] <lu_zero> mru: cf --arch=mips64 [11:49:32] <av500> omg, it leeked: http://multimedia.cx/eggs/official-realvideo-specifications/ [11:49:38] <mru> lu_zero: good point, that flag is unnecessary [11:49:41] <mru> removed now [11:51:15] <mru> lu_zero: --arch=x86 covers all x86 [11:51:23] <mru> configure figures out what it really is [11:51:52] <kshishkov> av500: personally I don't care [11:52:03] <av500> so you said [11:56:12] <kshishkov> av500: you know, full format docs would be more useful [13:11:00] <thresh> lol @ http://seclists.org/oss-sec/2010/q3/106 [13:13:01] <spaam> haha nice [13:13:06] <thresh> and it works. [13:13:23] <mru> annoying but harmless [13:13:55] <thresh> and funny [13:15:32] <mru> for one of the involved parties, yes [13:18:06] <kshishkov> isn't it fixed by general rule of staying away from KDE? [13:18:32] <thresh> Qt, you mean [13:19:11] <cartman> bleh [13:19:18] <cartman> its an implementation bug :) [13:48:48] <lu_zero> pfff [13:49:00] <mru> fffp [13:49:30] <BBB> lu_zero: do we have a LATM depacketizer? [13:49:38] <BBB> I have a LATM rtsp stream here that doesn't work [13:49:47] <lu_zero> latm [13:49:50] <lu_zero> yawn... [13:50:19] <BBB> maybe I should ask "the other luca" :-p [13:50:29] <lu_zero> http://www.rfc-editor.org/rfc/rfc3016.txt [13:50:47] <lu_zero> iff we don't have one is quite easy to get [13:51:08] <lu_zero> the generic mpeg4es doesn't support it already? [13:51:15] * lu_zero is sleepy [13:51:42] <BBB> it didn't work here [13:52:18] <funman> iirc i used the packetizer of vlc because there is none in ffmpeg [13:52:49] <kierank> janneg is writing a latm demuxer [13:53:11] <mru> or so he says [13:54:36] <merbzt> http://lolpics.se/pics/682.jpg [13:57:42] <lu_zero> what's inside latm btw? [13:57:53] <mru> aac usually [13:58:08] <lu_zero> the sdp says that? [13:58:20] <mru> no idea [13:59:05] <funman> can you put something else at all? [13:59:22] <funman> latm is described in mpeg4 part 3, isn't it? [14:06:02] <lu_zero> funman: apparently you can [14:06:31] <lu_zero> rfc3016 is a sort of catchall [14:06:33] <kierank> xiph would probably put ogg in it [14:06:42] <lu_zero> so it states much about it [14:06:54] <lu_zero> kierank: do not remind me ogg please ;_; [14:06:57] <funman> vorbis in ogg in latm in ts ? [14:07:04] <lu_zero> in rtp [14:07:07] <lu_zero> in http [14:07:10] <lu_zero> in atm [14:07:22] <lu_zero> in udp [14:07:25] <lu_zero> in tls [14:07:31] <kierank> over umts [14:07:36] <funman> take that, 'low overhead' ! [14:07:37] <lu_zero> I think that's the longest valid totem pole [14:08:25] <lu_zero> switch udp and tls [14:08:48] <mru> you can put ip in mpegts [14:08:51] <mru> over rtsp [14:09:07] <mru> over ip [14:09:09] <lu_zero> funman: you might serialize network traffic in xml [14:09:31] <lu_zero> mru: so you can do that recursively [14:09:38] <funman> real world use: vorbis in ogg in avi [14:09:42] <lu_zero> and have the end product as xml [14:09:58] <lu_zero> funman: excusable somehow [14:10:14] <lu_zero> by that time you had avi and ogg [14:10:32] <lu_zero> it's the quickest way pick one and fit the other inside [14:10:41] <lu_zero> the other way round would be worse [14:15:01] <BBB> lu_zero: you want the link to play around with? [14:15:14] <BBB> rtsp://qt-ar.as34763.net/ar32.sdp [14:24:59] * kierank wonders how utorrent is suddenly using ipv6 [14:28:39] <lu_zero> BBB: uhm [14:31:32] <BBB> lu_zero: ? [14:33:51] <BBB> wbs: you can put that one function declaration of rtpdec_asf.h in it also imo [14:38:34] <lu_zero> ffmpeg cannot reach it from here? [14:38:41] * lu_zero is puzzled [14:38:43] <lu_zero> btw [14:38:58] <lu_zero> those header were used in just one point, isn't it? [14:39:09] <lu_zero> why not merge those defs directly into the file? [14:57:34] <_skal_paris_> BBB: here? [15:02:21] <wbs> BBB: mmkay [15:03:25] <wbs> lu_zero: that's one option, too, but declaring a long list of "extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;" etc looks a bit ugly there [15:06:52] <_skal_paris_> BBB: http://pastebin.org/428089 [15:07:05] <_skal_paris_> BBB: and before you ask, yes it passes FATE :) [15:07:50] <spaam> o/ [15:13:37] <lu_zero> we could copy allcodecs [15:32:13] <BBB> _skal_paris_: uh, that's a rather long read, give me a bit to go through it ;) [15:32:25] <BBB> what's the summary? you replace uint8_t[] by a bitmask? [15:32:34] <BBB> there appear some unrelated changes in it also... [15:38:18] <_skal_paris_> BBB: yeah, it replaces storing the number of non-zero by just a bit [15:38:29] <kierank> roozhou: what do you know about the new chinese audio codec for blu-ray? [15:38:32] <_skal_paris_> on both top_nnz/left_nnz and non_zero_count_cache [15:38:50] <_skal_paris_> and that simplifies the loop somehow [15:39:59] <roozhou> kierank: nothing [15:40:40] <kierank> roozhou: ok [15:40:44] <roozhou> kierank: you mean CBHD? [15:41:37] <kierank> roozhou: no, there's been a new audio codec approved for blu-ray called DRA [15:42:17] <kierank> though I think cbhd also uses dra as well [15:42:28] <BBB> dra sounds like drm [15:42:31] <BBB> that's a pr failure [15:42:54] <mru> DRAt [15:43:14] <funman> Digital Restriction (is) Awesome!! [15:43:30] <kierank> [16:42] <@mru> DRAt --> dick dastardly's drm [15:44:29] <kshishkov> anybody thought about "Disguised Real Audio"? [15:44:45] <av500> lol [15:44:54] <av500> Dynamic Real Audio [15:45:11] <roozhou> dra looks like aac [15:45:26] <roozhou> frame size = 1024? [15:45:37] <av500> dra = dra resembles aac [15:46:12] <kshishkov> do we have specs for it? [15:46:29] <av500> kshishkov: since when do you need specs? [15:46:56] <kshishkov> av500: it's hard to implement codec without specs. Even binary ones [15:47:18] <mru> dra = dts ridiculous audio [15:47:24] <av500> kshishkov: screenshots must do... [15:48:10] <kshishkov> av500: yes, for audio [15:48:15] <funman> digital rifle association? [15:48:53] * kshishkov had REd one codec with specially crafted input for encoder [15:57:11] <BBB> _skal_paris_: I'll have a good look at it [16:03:03] <BBB> _skal_paris_: looks mostly ok to me, please fix alignment (style, not memory) [16:03:17] <BBB> in various places it'd be more readable with a few more spaces to align lines vertically [16:03:29] <BBB> the patch itself is straightforward [16:03:42] <BBB> why are the current left_nnz and non_zero_count_cache mem-aligned? [16:04:01] <BBB> is that just optimization for gcc memory access on certain archs? or is it used in asm? [16:06:58] <_skal_paris_> not sure [16:07:23] <BBB> should be ok then, as long as testsuite is ok [16:07:26] <BBB> did you fix and re-commit that? [16:07:32] <BBB> because at least the first of those two patches was fine [16:07:38] <BBB> the second broke the testsuite, not the first [16:07:47] <_skal_paris_> yeah, the quant one was totally wrong [16:07:58] <_skal_paris_> half of it [16:08:11] <_skal_paris_> BBB: i can recommit a fixed version of both, yeah [16:08:41] <_skal_paris_> BBB: i will send a revised version (that works!) [16:09:02] <_skal_paris_> BBB: let me fix the alignment [16:12:00] <roozhou> kierank: i just downloaded DRA spec [16:13:11] <roozhou> kierank: it's a scanned PDF and chinese only [16:13:26] <kierank> hahahaha i had a feeling it was going to be in chinese [16:16:08] <roozhou> it contains watermark in every page so it is not easy to use OCR [16:16:56] <kierank> transcribing all the codebook tables will be fun [16:17:04] <funman> is the watermark scanned or inside the pdf? [16:17:20] <kierank> does dra have conformance vectors? [16:17:32] <kierank> or a reference decoder [16:17:54] <funman> some watermarks can be removed by pdf -> ps -> edit -> pdf [16:18:16] <kierank> presumably it's a scanned watermark [16:18:51] <roozhou> scanned [16:19:47] <roozhou> the good news is a large part of the spec is written in C [16:20:20] <mru> better than chinese I guess [16:20:25] <mru> if you don't read chinese [16:21:01] <funman> ask the guys who sent the cavs patch [16:21:29] <kierank> that was one of the most bizzare mailing list threads i've ever seen [16:21:34] <roozhou> I speak Chinese [16:22:08] <mru> then you can traslate it for us [16:22:10] <mru> +n [16:22:17] <funman> kierank: why? [16:22:42] <kierank> that guys random soliliquy about why he loves open source, the whole amanda thing, etc [16:23:17] <roozhou> who sent the cavs patch? [16:23:30] <kierank> soliloquy* [16:23:47] <kierank> roozhou: they modified x264 to write avs files [16:24:04] <roozhou> xavs? [16:24:24] <kierank> yes [16:24:37] <roozhou> one of xavs developers was my classmate [16:24:48] <roozhou> in college [16:25:09] <kierank> jianwen chen was the guy [16:25:32] <roozhou> i don't know this guy [16:38:33] <_skal_paris_> BBB: shall i send to the ML? [16:38:52] <_skal_paris_> BBB: for some second look.. [16:39:59] <Dark_Shikari> BBB: left_nnz is aligned for AV_WN64A [16:40:04] <Dark_Shikari> same with nonzero cache [16:40:10] <Dark_Shikari> er, for AV_ZERO I mean [16:41:31] <Honoome> for LU_ZERO? [16:45:09] <_skal_paris_> BBB:http://pastebin.org/428179 [16:49:13] <Dark_Shikari> _skal_paris_: are you sure it's worthwhile to pack bits like that [16:49:14] <Dark_Shikari> ? [16:49:18] <Dark_Shikari> I don't think it is [16:49:25] <Dark_Shikari> too much extra calculation to save a tiny bit of memory [16:49:56] <Dark_Shikari> it looks ugly too [16:50:55] <lu_zero> .... [16:51:09] <_skal_paris_> Dark: i don't like the [9] [16:51:43] <Dark_Shikari> What's wrong with (9)? That's the strongest array. [16:51:50] <Dark_Shikari> But more seriously, I don't see how yours is going to make things any faster [16:51:53] <Dark_Shikari> it has more logic [16:52:03] <Dark_Shikari> and [9] makes perfect sense [16:52:04] <_skal_paris_> Not really [16:52:06] <Dark_Shikari> 4 luma AC [16:52:10] <Dark_Shikari> 4 chroma AC [16:52:11] <Dark_Shikari> 1 luma DC [16:52:17] <Dark_Shikari> er... it has way more logic [16:52:20] <Dark_Shikari> extracting bits from a mask is many ops [16:52:24] <Dark_Shikari> you have needless conditionals too [16:52:33] <Dark_Shikari> # [16:52:34] <Dark_Shikari> if (nnz) [16:52:34] <Dark_Shikari> # [16:52:34] <Dark_Shikari> + s->has_non_zero_ac |= block_bit; [16:52:36] <_skal_paris_> it's always tests to zero [16:52:43] <Dark_Shikari> It's far better to do s->has_non_zero_ac |= nnz [16:53:02] <lu_zero> what's DRA? [16:53:07] <Dark_Shikari> "it's always tests to zero"? [16:53:18] <_skal_paris_> extrating the bits [16:53:23] <_skal_paris_> tract [16:53:50] <Dark_Shikari> your extracting takes like 6+ ops [16:53:54] <Dark_Shikari> current takes 1 op [16:53:55] <Dark_Shikari> my question is [16:53:56] <Dark_Shikari> what does this save? [16:54:04] <Dark_Shikari> what are you saving that justifies a hundred extra ops per mb? [16:54:44] <kierank> 17:53] <@lu_zero> what's DRA? --> a new chinese audio codec that was included in the blu-ray spec recently [16:54:49] <_skal_paris_> i could time [16:54:57] <_skal_paris_> but in doubt, i prefer compactness [16:55:13] <Dark_Shikari> yours is less compact! [16:55:14] <Dark_Shikari> it's more code [16:55:26] <Dark_Shikari> and yes, time optimizations please [16:58:21] <lu_zero> kierank: anything interesting there? [16:58:46] <Honoome> lu_zero: beside "it's chinese" and "it was included in a spec"? [17:04:12] <BBB> _skal_paris_: could you add a few START/STOP_TIMERS to make sure it doesn't get slower? [17:04:16] <BBB> I don't thnk it will be [17:04:18] <BBB> but always good to prove [17:04:57] <_skal_paris_> BBB: on it [17:05:06] <Dark_Shikari> I personally reject the patch even if it's neutral. [17:05:07] <BBB> j0sh: how do you manually enable http-rtsp tunneling? is there a ?keyword? [17:05:17] <Dark_Shikari> i.e. if all else is equal, pick the simpler code. [17:05:29] <BBB> Dark_Shikari: I think it's ok, memory saving (even a few bytes) is useful for phones etc. [17:05:30] <Dark_Shikari> Only if it's faster will I consider it. [17:05:35] <BBB> which we will eventually target [17:05:43] <Dark_Shikari> BBB: um... [17:05:55] <BBB> (I agree it's minimal) [17:05:57] <Dark_Shikari> 2.5 kilobytes? [17:05:59] <Dark_Shikari> for CIF? [17:06:03] <Dark_Shikari> >_> [17:06:05] <_skal_paris_> Dark: i think the has_non_zero* logic is clearer [17:06:10] <Dark_Shikari> that's not even worth bothering with [17:06:16] <Dark_Shikari> _skal_paris_: maybe, but the bitmask bullshit is unreadable [17:06:17] <BBB> I agree, it's small [17:06:26] <BBB> but 2 cycles gain is small also [17:06:32] <Dark_Shikari> but it won't be 2 cycles gained [17:06:34] <Dark_Shikari> it'll be 200 cycles lost [17:06:35] <BBB> if we do it all over the place it may eventually add up to something noticeable [17:06:51] <BBB> that's why he has to test performance ;) [17:06:52] <Dark_Shikari> there is simply far more logic here. [17:07:10] <Dark_Shikari> even if it's faster I still reject it. he would need to make it not ugly as sin [17:07:23] <BBB> I actually did the same "trick" in wmavoice :-p [17:12:06] <_skal_paris_> old: [17:12:07] <_skal_paris_> 908550 dezicycles in block, 1 runs, 0 skips [17:12:07] <_skal_paris_> 480380 dezicycles in block, 2 runs, 0 skips [17:12:07] <_skal_paris_> 251070 dezicycles in block, 4 runs, 0 skips [17:12:07] <_skal_paris_> 132810 dezicycles in block, 8 runs, 0 skips [17:12:07] <_skal_paris_> 85013 dezicycles in block, 16 runs, 0 skips [17:12:07] <_skal_paris_> 48212 dezicycles in block, 32 runs, 0 skips [17:12:08] <_skal_paris_> 28723 dezicycles in block, 64 runs, 0 skips [17:12:08] <_skal_paris_> 18145 dezicycles in block, 127 runs, 1 skips [17:12:09] <_skal_paris_> 12540 dezicycles in block, 255 runs, 1 skips [17:12:09] <_skal_paris_> new: [17:12:14] <Dark_Shikari> um, not enough runs [17:12:16] <_skal_paris_> 738570 dezicycles in block, 1 runs, 0 skips [17:12:16] <_skal_paris_> 436205 dezicycles in block, 2 runs, 0 skips [17:12:16] <_skal_paris_> 224652 dezicycles in block, 4 runs, 0 skips [17:12:16] <_skal_paris_> 116723 dezicycles in block, 8 runs, 0 skips [17:12:16] <_skal_paris_> 61858 dezicycles in block, 16 runs, 0 skips [17:12:16] <_skal_paris_> 33809 dezicycles in block, 32 runs, 0 skips [17:12:16] <_skal_paris_> 20217 dezicycles in block, 64 runs, 0 skips [17:12:17] <_skal_paris_> 13782 dezicycles in block, 128 runs, 0 skips [17:12:17] <_skal_paris_> 9817 dezicycles in block, 256 runs, 0 skips [17:12:21] <Dark_Shikari> that's far too few runs [17:12:26] <Dark_Shikari> we need at least 100k+ runs [17:12:36] <Dark_Shikari> your time is dominated entirely by the initial run [17:12:43] <Dark_Shikari> which is completely random [17:12:53] <Dark_Shikari> I also need stdev [17:13:04] <Dark_Shikari> furthermore, you haven't even made it clear what you are timing [17:13:19] <_skal_paris_> old: 32488 dezicycles in block, 261916 runs, 228 skips [17:13:24] <_skal_paris_> new: 31840 dezicycles in block, 261924 runs, 220 skips [17:13:28] <Dark_Shikari> what are you timing? [17:13:37] <Dark_Shikari> and what is the stdev? [17:14:00] <_skal_paris_> timing the whole mb-reconstruction loop [17:14:21] <Dark_Shikari> er... you're not decoding the entorpy decoding? [17:14:24] <Dark_Shikari> you know, the part that'll get slower?> [17:15:10] <BBB> hi efriedma [17:15:14] <_skal_paris_> ? [17:15:18] <BBB> Dark_Shikari: calm down, he needs some coffee [17:15:22] <_skal_paris_> Dark: decode_mb_mode() [17:15:36] <efriedma> BBB: hi [17:15:44] <_skal_paris_> decode_mb_coeffs() [17:16:01] <_skal_paris_> int{ra,er}_predict() [17:16:05] <_skal_paris_> seems the full monthy to me [17:16:26] <Dark_Shikari> decoding an entire mb is only 3k clocks? [17:16:38] <Dark_Shikari> do you have a magical future computer from space? [17:16:40] <BBB> brb [17:18:01] <_skal_paris_> Dark: i'm timing 1547->1588 [17:18:23] <Dark_Shikari> for what? [17:19:08] <_skal_paris_> ? [17:19:52] <Dark_Shikari> something is going from 1547->1588 clocks [17:19:53] <Dark_Shikari> what is it? [17:20:12] <_skal_paris_> that's the line numbers in vp8.c where i put START/STOP TIMER :) [17:20:39] <Dark_Shikari> oh. [17:20:46] <Dark_Shikari> ok, I'll do testing in a moment. [17:21:00] <_skal_paris_> k [17:54:52] <BBB> bug report on webm bug tracker: "libvpx is slow" (issue156) [17:55:38] <mru> there are a lot of such complaints [17:55:57] <Honoome> RESO WONTFIX â use ffvp8 [17:56:04] <mru> it's the encoder [17:56:52] <Honoome> RESO UPSTREAM â write ffvp8enc :P [17:57:05] <Dark_Shikari> BBB: link? [17:57:32] <peloverde> http://code.google.com/p/webm/issues/detail?id=156 [17:58:07] <Dark_Shikari> lol [18:00:34] <BBB> it's a little funny ;) [18:00:49] <BBB> is there interest in adapting x264 to output webm compatible streams? [18:00:57] <BBB> that'd be a fun project [18:01:08] <Dark_Shikari> You mean vp8 ? [18:01:12] <BBB> yes [18:01:20] <BBB> toomanybuzzwords [18:01:25] <Dark_Shikari> "webm compatible" is a stupid phrase [18:01:29] <Dark_Shikari> that doesn't even make sense [18:01:29] <BBB> I agree [18:01:37] <BBB> I meant vp8 streams [18:02:09] <Dark_Shikari> and yes, I think that would be interesting =p [18:02:11] <BBB> wbs: do you remember how to maually enable http tunneling in rtspdemuxer? [18:02:16] <Dark_Shikari> it would troll the shit out of the freetards [18:02:24] <Dark_Shikari> and further the x264/vp8 conspiracy [18:02:26] <BBB> that's exactly why it's interesting [18:02:36] <Dark_Shikari> even better... let's do it on runtime, not compile time [18:02:39] <mru> that would be rather hilarious [18:02:40] <BBB> I think people in general don't appreciate how similar all these fuzzy video codecs are [18:02:42] <Dark_Shikari> so you can't distribute it without distributing an x264 encoder [18:02:47] <BBB> of course runtime [18:02:51] <BBB> -o h264 is default [18:02:55] <BBB> -o vp8 makes it "free" [18:03:03] <BBB> we'll call it "free" mp3^d^d^dh264 [18:03:36] <mru> how much work would it be? [18:03:43] <Dark_Shikari> If we start by implementing the minimum necessary [18:03:44] <funman> sell x264 to FSF [18:03:50] <Dark_Shikari> i.e. not the whole spec but just the parts that are easiest conversions [18:03:53] <Dark_Shikari> it wouldn't be too hard [18:03:56] <Dark_Shikari> a week or two of hacking [18:04:09] <mru> obviously no altref and shit [18:04:28] <mru> how does libvpx use altref? [18:04:42] <funman> what i wonder is, how does libvpx use shit? [18:04:48] <Dark_Shikari> I suspect that without using any vp8-unique features, we could beat the crap out of libvpx [18:05:01] <mru> btw, I found a few h264 files where ffmpeg differs from jm [18:05:07] <Dark_Shikari> yes, we know they exist [18:05:12] <Dark_Shikari> patches welcome [18:08:43] <_skal_paris_> intra-only should be easy [18:10:12] <mru> here's a troll plan: first make a simple encoder, clearly inferior to libvpx (although faster) [18:10:27] <mru> this will fuel the conspiracy theories [18:10:38] <Dark_Shikari> no, let's just make it better. [18:10:38] <mru> the, a week or two later, make it _better_ than libvpx [18:10:48] <mru> which shouldn't be too hard [18:10:50] <BBB> like the decoder [18:10:52] <BBB> that's great [18:10:55] <Dark_Shikari> _skal_paris_: http://pastebin.org/428232 [18:10:56] <Dark_Shikari> coefficient loop [18:10:57] <BBB> because it's two slashdot stories [18:10:58] <BBB> not one [18:10:59] <Dark_Shikari> new/old/new/old/etc [18:11:03] <mru> it's also the natural way of doing development [18:11:09] <mru> start with I-frames, etc [18:11:20] <Dark_Shikari> 6-8% slower [18:11:32] <mru> put it on /. when it encodes I and P frames [18:11:35] <BBB> Dark_Shikari: hm, that's unacceptable :( [18:11:52] <Dark_Shikari> that's decode_mb_coefficients [18:11:58] * funman can't find lego testers [18:12:12] <Dark_Shikari> the new code is also 400 bytes larger [18:12:22] <mru> funman: no kindergarten nearby? [18:12:47] <funman> i'd expect today kids to facebook, not play lego! [18:14:03] <Dark_Shikari> BBB: btw, if you want to do it [18:14:07] <Dark_Shikari> I would say do two things: [18:14:19] <Dark_Shikari> 1) add vp8 option, have it auto-disable everything that isn't in vp8 _or_ we haven't converted yet [18:14:34] <Dark_Shikari> e.g. bframes, trellis, etc [18:14:40] <Dark_Shikari> 2) convert cabac and header writing [18:14:46] <Dark_Shikari> however, everything would stay as h264-like as possible [18:14:53] <Dark_Shikari> so we still use h264 syntax element names, etc [18:14:55] <mru> that's the entire point [18:14:57] <BBB> of course, that was always my plan [18:14:58] <Dark_Shikari> to minimize the amount of code necessary to be changed [18:15:01] <mru> maximum troll effect [18:15:07] <Dark_Shikari> because pengvado will not like it if we fuck with x264 needlessly [18:15:10] <Dark_Shikari> to appease the gods of vp8 [18:15:11] <BBB> it should be minimal and "upstreamable" [18:15:21] <Dark_Shikari> so in short: [18:15:24] <Dark_Shikari> 1) add vp8 option (3 minutes) [18:15:28] <Dark_Shikari> 2) disable nearly everything (5 minutes) [18:15:33] <Dark_Shikari> 3) new header writing (a few hours) [18:15:37] <Dark_Shikari> 4) new cabac (a few hours) [18:15:49] <Dark_Shikari> bam, one day of hacking and you have a working encoder that produces a valid output stream [18:15:52] <funman> 5) ??? [18:15:57] <BBB> 0) get familiar with where stuff is in x264 (a few days) [18:15:59] <mru> 6) TROLL [18:15:59] <Dark_Shikari> then, you fix intra [18:16:08] <Dark_Shikari> then you fix inter (new get_ref and mc_luma functions) [18:16:23] <Dark_Shikari> and predict mv [18:16:32] <Dark_Shikari> the best part is most of the work is already done for you ;) [18:16:46] <Dark_Shikari> ref off the frame == -2 [18:16:50] <Dark_Shikari> intra ref (CURRENT) == -1 [18:16:56] <Dark_Shikari> prev frame (LAST) == 0 [18:16:58] <Dark_Shikari> golden == 1 [18:17:00] <Dark_Shikari> etc [18:17:33] <peloverde> I think Vorbis and AAC have shown making something that spits out a valid output stream is much harder than making it not suck [18:17:49] <Dark_Shikari> peloverde: most of the code that makes it "good" is already there. [18:17:59] <BBB> right, that's why you'd use x264 [18:18:02] <Dark_Shikari> x264 is already good. [18:18:02] <funman> peloverde: missing psycho accoustics? [18:18:05] <BBB> rather than developing ffvp8enc [18:18:15] <Dark_Shikari> ok, so I endorse this trolling scheme. [18:18:19] <BBB> peloverde: and that's why ffaacenc is so exciting, I wish I could give you money for it [18:18:42] <BBB> peloverde: because stuff is shareable [18:18:47] <mru> BBB: sue some more gpl violators and you'll be able to [18:18:53] <BBB> true [18:18:56] <BBB> working on it [18:19:23] <funman> 1/ --disable code written by people suing [18:19:32] <funman> 2/ ship a new gpl violating ffmpeg [18:19:52] <Dark_Shikari> michael gave permission for sflc to sue on behalf of him [18:19:53] <Dark_Shikari> iirc [18:19:57] <Dark_Shikari> which means "lol you're screwed" [18:20:10] <funman> ah it's nice [18:20:12] <peloverde> The SFLC has agrements from contributors deemed essential (i.e. michael) [18:20:12] <BBB> no he didn't [18:20:22] <BBB> but we have enough to sue anyone [18:20:24] <peloverde> it's like a patent pool ;-p [18:20:33] <peloverde> he didn't? [18:20:37] <BBB> not that I know [18:20:48] <BBB> Michael, please reply to the irc log list if you read this, did you? :-p [18:21:09] <funman> i don't believe there's something that michael doesn't know [18:21:18] <Dark_Shikari> he doesn't know how to make a good video encoder [18:21:20] * Dark_Shikari runs [18:21:29] <funman> :) [18:21:40] <_av500_> /undo!!!! [18:21:46] <funman> what did he wrote: ffv1 and mpeg4 asp ? [18:21:52] <Dark_Shikari> mpegvideo and ffv1 [18:22:00] <Dark_Shikari> mpegvideo ---> all lossy encoders in ffmpeg [18:22:15] <funman> also snow [18:22:20] <BBB> I thought mpegvideo was decent? [18:22:27] <Dark_Shikari> ok, it's decent. [18:22:39] <mru> what's the fabrice/michael ratio in mpegvideo? [18:22:41] <BBB> look, mpeg isn't gonna beat h264 (e.g. x264) [18:22:45] <Dark_Shikari> I'm just trolling him. [18:22:47] <BBB> so don't compare it to that [18:22:51] <Dark_Shikari> BBB: that isn't what I mean [18:22:55] <BBB> I'm not comparing vp8 and h264 either, it'd be unfair ;) [18:23:00] <Dark_Shikari> the encoders have no sensible defaults, require months of code investigation to come up with them [18:23:01] * BBB runs [18:23:04] <funman> mru: in number of codecs? [18:23:06] <Dark_Shikari> and have crap psy opts [18:23:11] <Dark_Shikari> mru: good question [18:27:04] <iive> mru: i doubt there is any code left from fabrice [18:27:13] <mru> there's quite a bit [18:27:37] <funman> mpegaudio? [18:27:42] <Compn> iive doesnt trust svn blame? [18:27:47] <mru> and even if few lines are directly attributable to him, he did much of the underlying work [18:27:58] <Compn> someone did a count of lines in ffmpeg [18:28:09] <funman> svn blame doesn't see moved lines, does it? [18:28:15] <Compn> michael was either #1 or #2 and fabrice was top 10 at least [18:28:16] <peloverde> git does [18:28:47] <iive> ^_^ [18:29:06] <peloverde> http://archives.free.net.ph/message/20100216.113913.8a0b7e89.it.html [18:30:08] <Dark_Shikari> whoa. kshishkov . [18:30:45] * funman goes run that on rockbox [18:32:55] <_av500_> funman: count the negative lines removing all my code :) [18:33:22] <funman> _av500_: what was your committer name? [18:33:36] * funman can't find git-blame-stats equivalent anyway [18:34:07] <_av500_> funman: no, the original jb6000 + jbr os :) [18:35:11] <peloverde> tmmm is also mike? [18:35:40] <funman> _av500_: hm? [18:36:08] <mru> peloverde: yes [18:40:29] <pengvado> Dark_Shikari: that is sufficiently hilarious that it almost overrides me not wanting to encourage vp8 encoding. [18:40:58] <funman> _av500_: http://www.jbros.co.kr/ ? [18:41:12] <funman> is that a birthday cake or a vlc logo imitation? [18:45:16] <_skal_paris_> Dark: ah yeah, the bit-munching thing is slower here too [18:49:32] <Dark_Shikari> pengvado: lol [18:50:15] <Dark_Shikari> _skal_paris_: fyi, I really do like hacks that involve bitmasks/etc [18:50:21] <Dark_Shikari> especially for dealing with dct coeffs [18:50:26] <Dark_Shikari> but here it doesn't really _get_ you anything [18:50:36] <Dark_Shikari> i.e. it doesn't let you do larger-scale compare magic or something that you couldn't do before. [18:50:52] <mru> make a mode where it encodes as both h264 and vp8, then mocks the user at the end [18:50:56] <Dark_Shikari> (example of bit masking magic in x264: coeff_level_run, where we convert the dct block to a bitmask and iterate over it with count-trailing-zeroes to do run-level coding) [18:51:28] <Dark_Shikari> pengvado: the best part is where patent FUD conflicts with making good vp8 encodes [18:51:42] <Dark_Shikari> i.e. where our encodes look much better than libvpx [18:51:51] <_skal_paris_> Dark: i managed to get rid of the update_nz_bit() and get_nz_bit() [18:51:52] <Dark_Shikari> but "omg x264" [18:52:07] <Dark_Shikari> _skal_paris_: I don't think getting rid of those will fix the problem [18:52:11] <_skal_paris_> Dark: and get similar speed, but the code get .. well.. [18:52:16] <Dark_Shikari> lol [18:52:19] <_skal_paris_> even less showable, let's say [18:52:51] <Dark_Shikari> btw [18:52:55] <Dark_Shikari> one thing I think might be worthwhile [18:53:11] <Dark_Shikari> do decode_mb_coeffs, then idct, repeatedly, for each block at a time [18:53:17] <Dark_Shikari> one and then then other [18:53:21] <Dark_Shikari> instead of all decode, then all idct [18:53:24] <_skal_paris_> Dark: i think the small overall speed-up was because i was testing block[y][x][0] for the DC [18:53:28] <Dark_Shikari> but of course that naively appears to break the idct_dcy4 [18:53:30] <_skal_paris_> instead of just nnz [18:53:38] <_skal_paris_> (*if* there was a speed-up) [18:53:53] <Dark_Shikari> _skal_paris_: oh, you mean that some dct blocks were marked as dc, but had nothing? [18:53:59] <_skal_paris_> yeah [18:54:10] <_skal_paris_> or, the WHT generated zeros on some sub-4x4 [18:54:18] <Dark_Shikari> that's what I mean [18:54:24] <wbs> BBB: yes, add ?http to enable it [18:54:29] <Dark_Shikari> you should go do some testing and see how common that is [18:54:45] <_skal_paris_> yeah, but that's independant of this nnz thing [18:54:58] <_skal_paris_> could be done anyway, separately [18:54:58] <Dark_Shikari> I know [18:55:11] <_skal_paris_> ok, time to head home [18:55:33] <Dark_Shikari> home from paris? [18:55:34] <_skal_paris_> i'll fiddle more with the bit thing later (just because i like it) [18:55:56] <_skal_paris_> yup, small pit-stop for summer [18:56:00] <_skal_paris_> then back to sun [18:56:40] <_skal_paris_> later! [18:57:13] <Honoome> Dark_Shikari: you find misnomers annoying? [18:58:07] <Dark_Shikari> ? [18:58:16] <Honoome> the "webm compatible" vs vp8 before :P [19:00:07] <Dark_Shikari> yes [19:00:19] <Honoome> because if you find those annoying, I know somebody in here that talks about "html5 pseudostreaming" Â¬_Â¬ [19:02:18] <Dark_Shikari> pseudostreaming at least has an accepted definition [19:02:25] <Honoome> but html5? [19:02:30] <Dark_Shikari> even if it's just buzzwordspeak for progressive download [19:02:35] <Dark_Shikari> progressive download is what html5 video does [19:02:50] <Honoome> it has nothing to do with html5 [19:03:03] <Honoome> it's http at best, not html5 [19:03:14] <mru> it's what current browsers support [19:03:28] <wbs> there's nothing saying you could add an rtsp:// or mms:// or whatever url in the html5 video tag [19:03:49] <mru> couldn't? [19:03:58] <wbs> couldn't, yes [19:04:24] <Honoome> just like there's nothing saying you can't add a gopher:// sftp:// git:// itms:// link in an x?html4? <a> tag :P [19:04:34] <wbs> yeah [19:05:01] <Honoome> I'm fine with http pseudosteam, but html5.. that's the worst marketing speak I heard in a while [19:05:36] <wbs> I've seen people request html5 streaming video for mobile phones where the actual browser doesn't support html5 [19:05:47] <Dark_Shikari> Honoome: how else do you want to express <video> [19:05:49] <Dark_Shikari> it didn't exist before html5. [19:05:52] <wbs> people just take html5 == non-flash [19:06:10] <Honoome> Dark_Shikari: progressive download existed before html5 [19:06:18] <Dark_Shikari> er... [19:06:19] <mru> flash does it [19:06:25] <Dark_Shikari> but they explicitly mean html5 pseudostreaming [19:06:29] <Dark_Shikari> i.e. with <video> [19:06:32] <Dark_Shikari> which did not exist before html5 [19:06:33] <Dark_Shikari> durhrhrhrh [19:06:57] <Honoome> the fact that you use it with <video> has nothing to do with the technique used behind, it's protocol-level, not format level [19:07:00] <Dark_Shikari> um... [19:07:01] <mru> so it means "progressive download invoked with <video> tag" [19:07:03] <Dark_Shikari> but they're not talking about the technique used [19:07:10] <Dark_Shikari> they're just saying "I am using technique X with tag Y" [19:07:14] <Dark_Shikari> X == progressive download [19:07:16] <Dark_Shikari> Y == <video> [19:07:27] <Honoome> Dark_Shikari: when describing a streaming server behaviour? [19:07:29] <Dark_Shikari> is it wrong to say "I have a red honda"? [19:07:35] <Dark_Shikari> I'm saying it's both red, AND it's a honda! [19:08:02] <funman> i'm ok with red, but having a honda is clearly wrong [19:08:27] <Honoome> funman: you'd prefer a uawei? [okay this was far-fetched and unfunny] [19:10:37] <Honoome> Dark_Shikari: what about a "red honda engine"? [19:11:04] <mru> obviously a honda engine in a red car :-) [19:11:44] <Honoome> so you go to an engine shop and ask for a "red honda engine" and they give you... what? :P [19:11:55] <Honoome> an engine stripped from a stolen red honda? [19:21:01] <Dark_Shikari> "red honda engine"? [19:21:03] <Dark_Shikari> well that's important [19:21:08] <Dark_Shikari> everyone knows that if it's red, it's three times faster. [19:22:13] <elenril> <insert relevant trope here> [19:22:38] <Honoome> Dark_Shikari: that's about how html5 feels :P [19:22:47] <Honoome> elenril: you're growing lazy! [19:23:08] <funman> ferrari effect [19:23:35] <Dark_Shikari> Honoome: but it IS three times faster [19:24:29] <Dark_Shikari> http://tvtropes.org/pmwiki/pmwiki.php/Main/LawOfChromaticSuperiority [19:36:47] <pengvado> http://www.overcomingbias.com/2009/09/seeing-red.html <-- yep, red is faster [19:39:09] <funman> â is not always faster [19:40:27] <funman> is rgb655 faster than rgb565 ? [19:41:24] <Dark_Shikari> Yuvi: any status on finishing up edge emulation? [19:42:20] <pengvado> funman: depends whether you use the extra red bit to increase the range or only the precision [19:42:37] <Dark_Shikari> why not just apply a gamma to the red channel [19:50:11] <funman> pengvado: the extra bit could be used as 'fast': > 0x1f = fast red [19:50:51] <Dark_Shikari> but all red is fast. [19:51:09] <funman> brighter red is faster [19:51:11] <Dark_Shikari> now, what I want is RGBV [19:51:16] <Dark_Shikari> 32-bit [19:51:22] <Dark_Shikari> red, green, blue, violet [19:51:22] <funman> V = ? [19:51:37] <funman> RVB is french RGB [19:51:40] <Dark_Shikari> or we could go further and do RYGBV [19:59:19] <mru> CMYUV [19:59:36] <Dark_Shikari> that doesn't even make sense [19:59:56] <funman> RAINBOW [20:08:37] <Dark_Shikari> ugh. so much stupid [20:08:45] <Dark_Shikari> the 3d craze has led to people asking on doom9 how to "convert their movies to 3D" [20:09:07] <BBB> awe s o m e [20:09:38] <mru> we obviosly need an output feeding http://makerbot.com/ [20:09:41] <BBB> is doom9 really that fantastic? [20:09:56] <BBB> I always wonder, because webforums inherently fall into chaos given enough time [20:10:19] <Dark_Shikari> doom9 is fine [20:10:26] <mru> doom10 is better [20:10:28] <mru> it's one more [20:10:32] <Dark_Shikari> it has its quota of stupid, but it's not particularly liked [20:34:00] <Yuvi> Dark_Shikari: fixed some bugs, works most of the time but still some bugs remaining :/ [20:34:27] <BBB> oh boy I'll be offline for a while [20:34:32] <BBB> just got my sc2 box :-p [20:34:40] <Dark_Shikari> lol [20:34:44] <BBB> thank god vp8 wasn't released 4 weeks later [20:34:48] <Dark_Shikari> Snape kills Kerrigan with Dumbledore. [20:34:52] <Dark_Shikari> now you don't have to play [20:35:06] <Dark_Shikari> Raynor is her father [20:35:28] <Dark_Shikari> Arcturus Mengsk isn't real [20:35:34] <Dark_Shikari> Zeratul is Keyser Soze [20:35:49] <Dark_Shikari> Hyperion was his sled [20:35:52] <mru> are you guys _all_ insane? [20:36:00] * funman hits mru with a pylon [20:36:08] <Dark_Shikari> mru: http://addisonrd.com/WordPress/wp-content/uploads/2007/05/spoilers.gif [20:36:44] <funman> verbal kint :) [20:36:50] <BBB> /me pokes mru [20:36:54] <BBB> wanna play on bnet? [20:36:57] * BBB hides [20:37:07] <Yuvi> jekyll and hyde were the same person [20:37:22] <funman> no [20:38:23] <funman> physical person perhaps? [20:38:36] <Dark_Shikari> oh god this isn't umineko [20:38:39] <Dark_Shikari> no more DID! [20:38:44] <Dark_Shikari> personas are not people! [20:39:13] <funman> Dark_Shikari: so which race are you playing in sc2? [20:39:20] <Dark_Shikari> I've mostly been playing protoss [20:39:23] <Dark_Shikari> though I haven't played for over a month [20:39:27] <Dark_Shikari> other than singleplayer [20:39:36] <funman> in sc1, terran: marines+tanks > protoss: dragoons [20:39:45] <Dark_Shikari> marines are useless against dragoons [20:39:48] <Dark_Shikari> once the dragoons have range at least [20:39:53] <Dark_Shikari> also, reavers [20:40:01] <Dark_Shikari> the only purpose of marines in TvP is for cheese rushes [20:40:05] <funman> tanks blow them before marines can reach them [20:40:10] <Dark_Shikari> which, honestly, works pretty well if the protoss is just blindly 14-nexusing or something [20:40:11] <peloverde> dragoons are useless in teh presence of stairs [20:40:20] <funman> reavers suck big times [20:40:28] <Dark_Shikari> yes, they suck if you're terran [20:40:29] <funman> i can't fight them, and i can't use them :) [20:40:34] <mru> guys, this isn't #ffmpeg-kindergarten [20:40:44] <mru> go play your games elsewhere [20:40:54] <Dark_Shikari> mru: coding on ffmpeg is a game just like any other [20:41:01] * funman sends a starcraft CD to mru [20:41:09] <Dark_Shikari> life is just a game. have fun. [20:41:16] * mru has no optical drive in his laptop [20:41:18] <peloverde> it's no game, it is the number 1 esport worldwide, a multimillion dollar industry [20:41:27] <Dark_Shikari> peloverde: esports are still games [20:41:31] <Dark_Shikari> no more or less games than, say, football [20:41:37] <mru> football is a game [20:41:48] <mru> ever heard of the olympic games? [20:41:50] <funman> mru: you've got loop devices? [20:42:09] <peloverde> They use theora in their cutsecenes and the quality was sub par, is that back on topic? [20:42:22] <Dark_Shikari> it's better than bink =p [20:42:35] * Dark_Shikari remembers starcraft 1 cutscenes [20:42:36] <Dark_Shikari> oh wait [20:42:37] <Dark_Shikari> those were not bink [20:42:39] <Dark_Shikari> those were SMACKER. [20:42:41] <peloverde> smacker [20:42:42] <Dark_Shikari> Now _that_ goes back. [20:42:58] <Yuvi> I thought sc1 was mpeg4 [20:42:58] <funman> 'starcraft' goes back already [20:43:03] <Yuvi> it's been too long [20:43:04] <funman> 1998? [20:43:05] <Dark_Shikari> mpeg-4 didn't exist [20:43:09] <Dark_Shikari> when they developed it [20:43:13] <Yuvi> makes sense [20:43:17] <Yuvi> must be thinking of some other game [20:43:28] <Dark_Shikari> march 1998, yes [20:43:44] <Dark_Shikari> fuck that was ages ago. [20:43:59] <peloverde> 12 years [20:44:12] * funman still did serious playing last year [20:44:18] <Dark_Shikari> damn, they're even slower than Valve [20:44:20] <mru> so Dark_Shikari has wasted half is life on it [20:44:29] <mru> *his [20:44:31] <Dark_Shikari> mru: actually I've only really watched starcraft for the past year or so [20:44:43] <mru> you _watch_ it??? [20:44:47] <Dark_Shikari> and I probably only played a few dozen games of the original [20:44:47] <mru> not play? [20:44:51] <funman> ah [20:44:55] <Dark_Shikari> well, not counting the use map settings games back in the day [20:44:56] <Dark_Shikari> when I was like... 12 [20:44:59] <Dark_Shikari> matrix defense, bunker wars, etc [20:45:04] <Dark_Shikari> but that was ages ago [20:45:15] <peloverde> bunker command was the best [20:45:17] <funman> Dark_Shikari: i defy you to sc1 [20:45:17] <Dark_Shikari> I spent my younger half of childhood mostly playing starcraft, Age of Empires 2 [20:45:21] <Dark_Shikari> etc [20:45:22] <Dark_Shikari> homeworld [20:45:27] <Dark_Shikari> civ2 [20:45:36] <Dark_Shikari> colonization [20:45:44] <Dark_Shikari> ~1995-2000 strategy era [20:45:52] * funman just needs a bnet key [20:45:53] <mru> booooring [20:45:55] <Dark_Shikari> funman: I haven't played in ages :> [20:46:01] <Dark_Shikari> mru: it's boring because it involves your brain ? [20:46:12] <Dark_Shikari> as opposed to shoving your massive throbbing gun down the mouths of your enemies [20:46:20] <mru> it's boring because a games drags on for fucking ever [20:46:23] <Dark_Shikari> of what? [20:46:34] <Dark_Shikari> a game of what [20:46:35] <mru> any strategy game [20:46:38] <Dark_Shikari> er... [20:46:43] <Dark_Shikari> starcraft games rarely last more than 15 minutes [20:46:46] <Dark_Shikari> homeworld, probably no more than 30-45 [20:46:49] <peloverde> Most pro starcraft games are pretty short [20:46:51] <Dark_Shikari> civ2, ok, that lasts 5-10 hours, but that's civ [20:46:57] <peloverde> except stork v ggplay [20:46:58] <Dark_Shikari> and that's not intended to be a one-sitting game [20:47:01] <Dark_Shikari> peloverde: oh god [20:47:03] <funman> my games lasted more like 60 mins [20:47:07] <Dark_Shikari> AoE2 was usually 10-20 minutes [20:47:18] <BBB> sc1 cutscenes? [20:47:19] <Dark_Shikari> 30 minutes if you insisted on getting to imperial age and making 20 trebuchets before losing [20:47:20] <BBB> those were divx [20:47:23] <BBB> the first big use of divx iirc [20:47:25] <Dark_Shikari> BBB: divx didn't exist when sc1 came out [20:47:28] <mru> you must have played in a different way from anything I ever saw [20:47:29] <Dark_Shikari> they were smacker [20:47:42] <mru> divx didn't exist until ~2002 [20:48:01] <Dark_Shikari> Note how they are 256-color. [20:48:06] <Dark_Shikari> DivX didn't have a 256-color mode. [20:48:18] <mru> depends [20:48:33] <mru> you can code mpeg4 as luma only [20:48:43] <mru> and shove it on a palette display [20:48:57] <peloverde> I thought AOE2 was bink? [20:49:10] <Dark_Shikari> AoE2? No idea [20:49:19] <Dark_Shikari> It had a pretty damn good opening movie for its time though [20:49:30] <Dark_Shikari> It was also the last really good game by ensemble, I think [20:50:03] <peloverde> Where is mike when we need him, he knows every codec that any game ever used [21:09:42] <funman> peloverde: who won in stork v ggplay: zerg or protoss ? [21:10:49] <funman> (replay ETA: 45mins) [21:11:13] <Dark_Shikari> why spoil it? [21:11:19] <Dark_Shikari> wait, was stork vs ggplay the one that ended up with crazy dark archon stuff? [21:11:26] <Dark_Shikari> and a heavily fortified base at the top? [21:11:34] <Dark_Shikari> I can remember a couple games that went insanely long [21:11:53] <Compn> youtube stork v ggplay 85 mins ? [21:11:54] <funman> i don't understand the start [21:12:00] <funman> Compn: that's the one i'm watching [21:12:03] <Compn> ah [21:13:36] <Dark_Shikari> http://gurupreet.com/stork-vs-ggplay-aka-english-commentary-the-movie/ [21:13:41] <Dark_Shikari> there's one with english commentary [21:13:53] <Dark_Shikari> no idea how good it is [21:14:08] <funman> commentary = shit [21:14:27] <Dark_Shikari> it's useful if you're not already a pro [21:14:32] <Dark_Shikari> i.e. 99% of viewers [21:14:52] <funman> why does mplayer mute all other audio players :'( [21:14:58] <Dark_Shikari> I mean, I can watch most any game and get a lot out of it without commentary, but that's only because I've watched a couple hundred games _with_ commentary to learn enough to do that [21:15:29] <funman> did you make battle.net tournaments or so? [21:15:35] <Dark_Shikari> and even then, I'd rather have commentary. [21:15:38] <Dark_Shikari> Though really only if it's from someone good. [21:15:42] <Dark_Shikari> Like, say, Tasteless or Day9. [21:17:03] <Compn> day9 is good :) [21:17:20] <Dark_Shikari> tasteless was pretty awesome. I want to see more gomtv tournaments [21:17:30] <Dark_Shikari> the tournaments are always better because the players are more likely to try batshit crazy stuff [21:17:38] <Dark_Shikari> that they're not willing to go for during normal league games [21:17:44] <Compn> i want to play sc2 once or twice [21:18:23] <funman> there's no single player beta on torrents? [21:18:31] <Compn> probably [21:18:36] <Compn> i'm just reminding myself [21:18:42] <Dark_Shikari> there was no singleplayer beta [21:18:47] <Compn> or that [21:19:18] <funman> i'm pretty sure seeing single player games some months ago [21:19:34] <Dark_Shikari> oh, you mean against the computer? [21:19:36] <Dark_Shikari> yes those were available [21:19:41] <Dark_Shikari> just not the campaign [21:20:05] <funman> yeah, although AI was shit it seems [21:20:19] <Dark_Shikari> less than shit, it did basicalyl nothing [21:20:21] <Dark_Shikari> it was just for testing [21:21:12] <funman> i only remember terran farms [21:21:22] <funman> which could be buried to let units go through [21:21:59] <Dark_Shikari> >farms [21:22:03] <Dark_Shikari> go back to warcraft 3! [21:22:19] <funman> didn't play much [21:22:31] <funman> i played warcraft 2 recently [21:22:44] <funman> still can't understand how one could enjoy it. [21:23:02] <funman> 1/ no right click [21:23:09] <funman> was it designed for macos ? :/ [21:23:21] <Dark_Shikari> welcome to 1995 [21:26:37] <spaam> thank you :D [21:51:27] <Yuvi> gah, I kept forgetting about topright [21:51:51] <Yuvi> now to make it less complicated [21:52:26] <Dark_Shikari> now once we've done that, would anything get faster if we turned off edge emulation? [21:52:37] <Dark_Shikari> i.e. if edge emulation isn't necessary [21:53:21] <Yuvi> probably not, since it means that we have to copy the top/left edges for each of the top/left macroblocks, then copy the intra prediction back into the frame [21:53:34] <Dark_Shikari> why would we have to copy them? [21:53:40] <Dark_Shikari> just memset to 129 [21:53:51] <Dark_Shikari> i.e. what we're currently do [21:53:52] <Dark_Shikari> *doing [21:54:07] <Yuvi> you have to copy the left edge for each macroblock on the top except 0,0 [21:54:59] <Dark_Shikari> why [21:55:51] <Yuvi> because you can't intra predict directly into the frame (since it might read 1 row above), so you need a temp buffer where -1 is valid [21:56:01] <Dark_Shikari> why? [21:56:06] <Dark_Shikari> isn't that what the xchg border is for? [21:56:38] <Dark_Shikari> -1 is valid in the frame, too [21:56:47] <Yuvi> dst[-linesize] is not valid to write or read from without an edge [21:57:00] <Yuvi> same with dst[-1] on the left [21:57:12] <Dark_Shikari> um [21:57:14] <Dark_Shikari> that's why I said [21:57:16] <Dark_Shikari> when edge emulation is off [21:57:18] <Dark_Shikari> ............... [21:57:31] <Dark_Shikari> dst[-1] on the left is perfectly valid if edge emulation is off [21:57:35] <Yuvi> oh, no, all of this code is conditional on edge emulation being on [21:57:50] <Dark_Shikari> I was asking if there's other stuff we can do in the case that it's off. [21:57:52] <Yuvi> I'm not changing the current behaviour [21:57:55] <Dark_Shikari> Such as, say, padding the edges for MC. [21:58:20] <Yuvi> yeah, that'd buy you a bit less time in emulated_edge_mc [21:58:39] <Dark_Shikari> no, it'd eliminate time in emulated_edge_mc. [21:58:47] <Dark_Shikari> you wouldn't even have to check [21:58:52] <Dark_Shikari> because vp8 includes its own built-in mv clamping [21:58:57] <Yuvi> we only have an edge of 16 pixels for luma and 8 for chroma [21:59:03] <Yuvi> that's not enough with a 6 tap filter [21:59:08] <Dark_Shikari> So, make it larger. [21:59:19] <Dark_Shikari> Do what x264 does. [21:59:22] <Dark_Shikari> Make it 32 for luma, 16 for chroma. [21:59:25] <Yuvi> it's a #define in dsputil.h [21:59:28] <Dark_Shikari> Only pad the pixels necessary of course. [21:59:31] <Dark_Shikari> .... that is retarded [21:59:37] <Dark_Shikari> Why the fuck can't each codec pick how much padding it needs? [21:59:49] <Dark_Shikari> In fact, what's stopping us from requesting frames of the size we want? [22:00:03] <Dark_Shikari> when we allocate pictures? [22:00:05] <Yuvi> the get_buffer API wasn't designed that way [22:00:15] <Dark_Shikari> huh? [22:00:19] <Yuvi> it rounds the width/height up to 16 [22:00:21] <Dark_Shikari> SOMEONE has to tell lavc what size frame it wants [22:00:25] <Dark_Shikari> Well duh [22:00:28] <Dark_Shikari> so we increase width and height by 32. [22:00:30] <Dark_Shikari> Done. [22:00:37] <Yuvi> you can't decrease it later [22:00:43] <Dark_Shikari> And? [22:00:55] <Dark_Shikari> Why do we care if the buffer is a bit too large? [22:01:25] <Yuvi> because it's the same width/height that's used to determine how large a frame is displayed [22:01:32] <Dark_Shikari> No it isn't [22:01:42] <Yuvi> avctx->width, avctx->height [22:01:43] <Dark_Shikari> copy_picture is run before returning a frame [22:01:49] <Dark_Shikari> You can modify the height in the returned picture. [22:01:57] <Dark_Shikari> iirc. [22:02:06] <Dark_Shikari> i.e. to put a frame in the reference list, it's copied. [22:02:36] <Dark_Shikari> width/height are properties of an AVPicture, not of the buffer itself [22:02:44] <Dark_Shikari> so you can make a new AVPicture that aliases the old one [22:02:47] <Dark_Shikari> and modify the internals. [22:02:50] <Yuvi> we don't use copy_picture [22:03:26] <Yuvi> and width/height aren't AVFrame properties, they're AVCodecContext properties [22:03:42] <Dark_Shikari> ok, so we can increase them before calling get buffer [22:03:45] <Dark_Shikari> and then decrease them. [22:06:19] <Dark_Shikari> yes, this is getting really evil. [22:09:43] <Yuvi> who was koorogi so I can yell at him for not giving avcodec_get_edge_width any parameters... [22:11:16] <CIA-92> ffmpeg: aurel * r24578 /trunk/libavformat/assdec.c: add seeking support in ASS demuxer [22:13:35] <Yuvi> j-b: does vlc ever not use CODEC_FLAG_EMU_EDGE when using a custom get_buffer? [22:14:15] <j-b> Yuvi: ENO_NOIDEA [22:14:50] <j-b> if( p_sys->b_direct_rendering ) [22:14:54] <j-b> { [22:14:58] <j-b> msg_Dbg( p_dec, "trying to use direct rendering" ); [22:15:02] <j-b> p_sys->p_context->flags |= CODEC_FLAG_EMU_EDGE; [22:15:07] <j-b> oops [22:15:49] <j-b> Yuvi: http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/video.c;h… is the relevant code [22:16:18] <Yuvi> and ffmpeg_GetFrameBuf uses avcodec_default_get_buffer if b_direct_rendering is false [22:17:09] <Yuvi> so possibly nothing uses direct rendering + edge except maybe ffplay+libavfilter? [22:17:37] <Dark_Shikari> you mean direct rendering + no edge emulation? [22:17:47] <Yuvi> yeah [22:18:20] <CIA-92> ffmpeg: aurel * r24579 /trunk/libavformat/avidec.c: avidec: demux ASS and SRT tracks out of GAB2 chunks [22:18:29] <Yuvi> well, more no edge emu + custom get_buffer that doesn't use avcodec_default_get_buffer to allocate stuff [22:19:30] <Yuvi> I think making avcodec_get_edge_width2 would be better [22:19:36] <Yuvi> than changing width/height [22:20:47] <CIA-92> ffmpeg: vitor * r24580 /trunk/libavcodec/x86/idct_mmx.c: Translate libmpeg2 MMX IDCT to plain asm [22:21:00] <Yuvi> the whole buffer allocation API is a mess anyway [22:36:39] * Vitor1001 breaks building in x86_64 :p [22:38:14] <Vitor1001> Does anyone have a 64-bit x86 box to test my fix? [22:38:14] <Vitor1001> http://ffmpeg.pastebin.com/rKqq5FRQ [22:39:17] <CIA-92> ffmpeg: stefano * r24581 /trunk/cmdutils.c: Extend show_protocol() to make it print more information. [22:40:32] <funman> Vitor1001: i can test [22:40:39] <Vitor1001> funman: Great, thanks [22:40:53] <j-b> Vitor1001: never ever trust funman :D [22:41:04] <Vitor1001> Just see if it unbreak my compilation after my commit [22:41:08] <Vitor1001> j-b: ;) [22:41:31] <funman> commit, if it doesn't work on the build bots, just git push --force [22:42:22] * Vitor1001 know nothing about git :( [22:44:18] <funman> Vitor1001: it builds [22:44:26] <Vitor1001> funman: nice! [22:45:30] <Vitor1001> Let's see if fate goes green... [22:46:15] <CIA-92> ffmpeg: vitor * r24582 /trunk/libavcodec/x86/idct_mmx.c: Fix compilation in x86_64. I broke it with r24580. [23:45:47] <CIA-92> ffmpeg: stefano * r24583 /trunk/ (6 files in 2 dirs): [23:45:47] <CIA-92> ffmpeg: Move fill_image_linesize() and fill_image_data_ptr() from [23:45:47] <CIA-92> ffmpeg: libavcodec/imgconvert.c and make them public in libavcore/imgutils.h, [23:45:47] <CIA-92> ffmpeg: with the names av_fill_image_linesizes() and av_fill_image_pointers(). [23:58:55] <CIA-92> ffmpeg: stefano * r24584 /trunk/doc/APIchanges: Add APIchanges entry for the libavcore/imgutils.h addition.

1 0

IRC log for 2010-07-28
by irc＠mansr.com 29 Jul '10

29 Jul '10

[00:23:22] <saintdev> peloverde: http://imgur.com/aNijz.png [00:23:23] <saintdev> top is ffaac lame windowing stuffed into 3gpp, middle is 3gpp, bottom is itunes [00:24:29] <peloverde> Is iTunes using TNS on that? [00:24:49] <saintdev> don't think so, let me check [00:26:05] <saintdev> it is [00:26:25] <saintdev> however, on that hit lame seems to perform very poorly [00:32:59] <saintdev> it seems to do a little better when there is more background noise [00:35:25] <peloverde> how does actual lame do? [00:43:49] <saintdev> peloverde: http://imgur.com/2w5Ci.png bottom is lame [01:00:02] <peloverde> So looking at that there is probably an inconguity in the port to AAC [01:01:25] <saintdev> peloverde: but that is just one isolated hit [01:02:17] <saintdev> anyway, got to run, bbl [01:02:37] <peloverde> yeah, but it is a lot of pre-echo, and having looked at the 3GPP one before that particular case is rather clear (Should be an easy decsion) [01:03:00] <peloverde> otoh perhaps the lame+aac code has fewer false positives [01:09:52] <saintdev> could also be the thresholds need retuned [01:10:35] <saintdev> i know that our decisions are much closer to itunes and nero [01:10:59] <saintdev> 3gpp seems to switch even earlier than we do, and we're usually one frame ahead of itunes [01:11:10] <saintdev> which is usually one frame ahead of nero [01:16:27] <j0sh> why don't we use pkg-config to detect x264? [01:17:36] <saintdev> peloverde: wrt false-positives, i know there's a couple spots a few frames into castanets where it switches to short blocks, and none of the other encoders do [05:03:00] <thresh> moroning [05:05:16] <kshishkov> good morning [05:05:52] <peloverde> still night time here but good morning [05:20:44] <CIA-92> ffmpeg: mstorsjo * r24560 /trunk/libavcodec/nellymoserenc.c: nellymoserenc: Declare the supported sample format [05:34:55] <elenril> bcoudurier: ping [05:37:24] <CIA-92> ffmpeg: alexc * r24561 /trunk/libavcodec/ (vp56.h vp5.c vp6.c vp56.c): ff_prefix non static vp56 functions. [05:39:19] <CIA-92> ffmpeg: alexc * r24562 /trunk/libavcodec/ (vp56.h vp6.c): Reindent after last commit. [05:41:30] <CIA-92> ffmpeg: alexc * r24563 /trunk/libavcodec/vp56.c: 10l: missed one reindent. [05:41:33] <peloverde> I need to start using git again [05:42:19] <saintdev> peloverde: well i got it much closer to 3gpp, still nowhere near itunes [05:42:34] <saintdev> just needed to lookahead further [05:43:23] <peloverde> What's it look like now? Does it miss the attack? is the grouping correct? [05:45:56] <saintdev> peloverde: http://imgur.com/Y3zRn.png [05:46:15] <saintdev> top to bottom itunes, ffaac-lame, ffaac-3gpp, reference [05:47:05] <saintdev> same hit as before :) [05:47:14] <peloverde> good [05:47:23] <peloverde> what's the length of the preecho? [05:49:10] <saintdev> .00136054s [05:49:12] <saintdev> lol [05:49:27] <peloverde> how many samples? [05:49:43] <CIA-92> ffmpeg: reimar * r24564 /trunk/libavformat/mxfenc.c: [05:49:43] <CIA-92> ffmpeg: Add extern to mxf_d10_muxer forward declaration to avoid a redundant [05:49:43] <CIA-92> ffmpeg: redeclaration warning. [05:49:52] <peloverde> 60? [05:50:57] <peloverde> That is smaller than block switching will get us [05:51:13] <saintdev> so how does itunes get it so right :/ [05:51:19] <peloverde> TNS [05:52:25] <saintdev> TNS can help that much with pre-echo o.O [05:53:56] <peloverde> yes [05:54:38] <peloverde> I have some TNS code floating around, but it's based on 3GPP which is apparently very subpar [05:56:10] <av500> mroning [06:07:01] <peloverde> How is it on false positives? At very low bitrates, false positives bleed quality [06:07:17] <saintdev> that's what i'm looking into now [06:08:00] <saintdev> at first glance, not very good, but i think just adjusting the threshold may solve that [06:36:24] <mru> moronings [06:36:36] <av500> +1 [06:37:09] <mru> moroningses? [06:38:04] <av500> morona [06:38:57] <mru> that's plural of moronum [06:39:06] <thresh> huh, some russian court say ISP should ban access to youtube, because it contains extremist materials [06:39:30] <thresh> like Mein Kampf, which is forbidden in Russia [06:39:34] <mru> those lolcats are *extreme* [06:39:52] <av500> thresh: they also ban russian state TV? [06:40:03] <thresh> av500: I wish.. [06:41:05] <thresh> the Great Russian Firewall rises up [06:42:26] <av500> you can make a common firewall zone with china [06:42:32] <av500> and afew other states nearby [06:42:52] <KotH> moin [06:43:00] <av500> grÃŒezi [06:43:02] <elenril> at least tor is getting faster lately [06:43:16] <mru> tor is a joke [06:43:33] <elenril> orly [06:43:44] <mru> not to _them_ of course [06:44:51] <CIA-92> ffmpeg: mstorsjo * r24565 /trunk/libavformat/rtpdec_xiph.c: [06:44:52] <CIA-92> ffmpeg: rtpdec_xiph: Handle the sampling SDP parameter [06:44:52] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [06:45:15] <thresh> haha, they actually should also block web.archive.org :-) [06:46:03] <thresh> I wonder if they will ban the whole subnets; what will happen if they discover there is porno sites on the internets? ban the whole 0.0.0.0/0 ? :) [06:47:17] <saintdev> porn! on the interwebs! no wais!!! [06:49:03] * KotH notes, that number of fftards is rising [06:49:26] <av500> you have a tardmeter? [06:49:49] <KotH> juup, right next to my matsumotometer [06:50:07] <mru> av500: I'll need to upgrade mine for OVC [06:50:22] <mru> get one that goes to 11 [06:53:56] <KotH> ovc? oberpfälzer veteranen club? [06:55:18] <av500> yeah [06:56:03] <av500> http://www.openvideoconference.org/ [07:20:36] <saintdev> wow, 3gpp falls apart on fatboy.wav [07:21:35] <saintdev> and once again itunes kicks ass [07:23:28] <mru> kick the fat boy's ass? [07:24:20] <saintdev> itunes does, yes [07:26:17] <saintdev> i wonder what the TRUMPET, FSOL and SNAPS test samples the LAME comments mention are [07:38:14] <KotH> av500: is anyone of the fftards being invited? [07:38:34] <KotH> av500: or from vlc, xine or mplayer for that matter [07:38:38] <av500> j-b [07:38:41] <av500> speaks [07:39:04] <KotH> right [07:39:07] <av500> BBB and peloverde want to go iirc [07:40:00] * KotH finds it interesting, that from the speakers only one is involved in video coding and only another two can be said to have an involvment into the field [07:40:13] <av500> but one is a rock star! [07:41:09] <peloverde> presumably most of the CELT people will be there because they are going to FOMS [07:41:53] <Dark_Shikari> KotH: well duhhhh [07:41:54] <Dark_Shikari> it's xiphcon [07:41:54] <kshishkov> most of the CELT people == J-M Vallin, isn't it? [07:43:00] <KotH> .o0(ffcon) [07:43:35] <peloverde> my choice for conventions within a days drive of where I live are Ohio Linux Fest or OVC [07:43:57] <peloverde> And monty is keynoting OLF [07:44:25] <av500> OLF? [07:44:34] <av500> ah, ohio [07:44:52] <kshishkov> so no real choice, eh? [07:45:29] <av500> no freedom of choise! [07:46:36] <peloverde> I'll see how it goes [07:47:08] <kshishkov> av500: till this year I had freedom to choose any of zero conferences [07:47:27] <mru> no ukraine LUG? [07:47:40] <kshishkov> in theory there is [07:47:50] <mru> but it moved to germany? [07:48:21] <av500> kshishkov: i thought they all write java apps? [07:48:50] <kshishkov> mru: it's site www.linux.kiev.ua - isn't that a bit suspicious? [07:49:49] <kshishkov> av500: no, Ukrainian coders mostly do PHP and .NET, Java developers are quite rare and can get insane amounts of money (insanely small by European standards) [07:50:03] <av500> ah, mixed that up then [07:50:30] <pJok> kshishkov, i thought ukrainian developers were paid in beatings... [07:50:39] <mru> and I was feeling dirty after doing all that web work on fate [07:50:59] <mru> it uses css3, is that cool enough? [07:51:13] <av500> html5? [07:51:16] <kshishkov> yes, enough to feel dirty [07:51:20] <mru> no html5 [07:51:24] <av500> lame [07:51:39] * pJok makes mru remake the site in flash [07:51:40] <kshishkov> pJok: it's not India even if it seems so quite often [07:51:54] <av500> kshishkov: you missed this one: http://conference.osdn.org.ua/ [07:51:56] <kshishkov> in Silverlight! [07:52:03] <pJok> kshishkov, the pics i saw did somewhat resemble Delhi... [07:52:13] <j0sh> peloverde, you should get yourself added to the open source section here http://www.openvideoconference.org/speakers/ [07:52:20] <peloverde> You should put all failures in <video> tags then file bugs against the major browsers to try to trick them into fixing the bugs [07:52:37] <kshishkov> av500: no, but it has the last announcement for 2009. Dead? [07:52:49] <mru> ah, so _that_ is why they only support webm doctype [07:52:55] <peloverde> I was under the impression that that was for the 2009 conference [07:53:09] <j0sh> ohh it is, my bad [07:53:46] <av500> not sure, it feauteres j-b and he was not there 2009, was he? [07:54:36] <funman> 2010 Announced Speakers (so far) [07:54:39] <kshishkov> av500: so what? LinuxTag 2010 also featured j-b 9at least his badge) and he was not there [07:55:21] <funman> it's a fake: it says this j-b develops "VLC Player" [07:57:42] <kshishkov> funman: and you develop "Rockbox player software", I presume (nothing to do with firmware, not at all) [07:59:06] <av500> kshishkov: at least the ukranians are building UAV killdrones with gstreamer: http://ftp.linux.kiev.ua/pub/conference/2009/reports/Lavruschenko-GStreamer… [07:59:07] <funman> i firmly develop software [08:01:04] <j-b> av500: I will go there... [08:01:09] <av500> yes [08:01:20] <av500> you can meet a rockstar [08:01:23] <j-b> and I was there last year... [08:01:26] <j-b> a rockstart? [08:01:27] <av500> ok [08:01:34] <av500> in a rockbox [08:02:02] <j-b> :) [08:03:13] <funman> j-b: what will you speak about? [08:03:32] <CIA-92> ffmpeg: cehoyos * r24566 /trunk/libavcodec/libvpxenc.c: [08:03:32] <CIA-92> ffmpeg: Map rc_buffer_size to and c_initial_buffer_occupancy to their libvpx [08:03:32] <CIA-92> ffmpeg: counterparts. [08:03:32] <CIA-92> ffmpeg: Patch by James Zern, jzern at google [08:03:33] <j-b> no fucking idea [08:03:47] <funman> "how webm penetrates the porn industry" [08:04:13] <peloverde> good use of the word penetrate [08:04:26] <j-b> I would love that this conference doesn't stay the Mozilla/html5 showcase, like last year [08:05:03] <KotH> j-b: you mean, more of us should speak there? [08:05:20] <peloverde> Well I'll be there and I hate mozilla with a fiery passion [08:05:30] * mru fans the flames [08:06:10] <funman> get "i run safari" t-shirts [08:06:29] <j-b> KotH: well, I don't know, but yes for them, the future of video is only through the browser [08:06:50] <kshishkov> "Firefox - still a long way to implement garbage collector" [08:06:55] <j-b> in the cloud [08:07:14] <funman> in the cloud with rainbows and unicorns [08:07:45] <mru> if firefox had a working garbage collector, it would self-collect first thing at startup [08:07:51] <CIA-92> ffmpeg: cehoyos * r24567 /trunk/libavformat/id3v2.c: [08:07:51] <CIA-92> ffmpeg: Skip short padding in id3v2. [08:07:51] <CIA-92> ffmpeg: Patch by Alexander Kojevnikov, alexander kojevnikov com [08:08:08] <kshishkov> mru: only in case of smart garbage collector [08:08:12] <mru> funman: check where fftrollbot is signed on from [08:08:35] <funman> :o [08:09:08] <j-b> funman: so, I don't know, speak about patents, DRM, how to be a small team, how vlc depends on so many other projects, how it is hard to do crossplatform for different stuffs, like UI or video output [08:09:29] <mru> and how ffmpeg rocks [08:09:47] <j-b> well, ffmpeg rocks, but there is a troll, named mru... :D [08:09:48] <j-b> :D [08:10:01] <kshishkov> trolls have relations to rocks [08:10:35] <kshishkov> but I must admit that even our trolls are of very high quality [08:12:35] <KotH> j-b: well.. the web is the future.. or rather the present... it's time we replace it with something new [08:12:44] <lu_zero> good morning [08:12:53] <KotH> bon giorno [08:13:04] <lu_zero> hi KotH [08:13:29] <lu_zero> your doomsday devices got ok btw? [08:14:07] <lu_zero> j-b: our troll beer is top quality =P [08:14:25] <mru> we need a sponsorship deal with them [08:14:47] <kshishkov> mru: I wonder why trolleybuses went out of fashion? [08:14:54] <lu_zero> mru: I'm thinking about really ask for an estimate about a custom brew for us [08:15:26] <lu_zero> and setup a shop within the foundation website with the t-shirt and the beer [08:15:27] <mru> we could put a "powered by Troll" logo on stuff... [08:15:41] <kshishkov> "trolled by power" [08:15:56] <KotH> lu_zero: doomsday devices? which one do you mean? [08:15:57] <lu_zero> kshishkov: thehehe [08:16:02] <lu_zero> KotH: good question [08:16:39] <lu_zero> we left you with those earthquake monitoring stuff being completed [08:17:17] <lu_zero> btw I'm thinking about having the ffcon with the cloudcamp by topix [08:17:53] <lu_zero> they are already taking a good place for few days [08:18:02] <CIA-92> ffmpeg: bcoudurier * r24568 /trunk/libavformat/wav.c: In wav muxer, always flush in write_trailer, fix pipe output [08:19:02] <bcoudurier> yes elenril [08:20:45] <elenril> bcoudurier: what happened to the patch for writing ogg-vorbis and ogg-theora metadata? [08:20:58] <bcoudurier> good question [08:21:02] <bcoudurier> it's very welcome [08:21:03] <elenril> you forgot about it? [08:21:15] <elenril> J_Darnley sent it a few months ago [08:21:21] <bcoudurier> did I miss it ? [08:21:24] <elenril> as far as i can see it wasn't reviewed [08:21:29] <bcoudurier> ping the thread then [08:21:42] <elenril> ok [08:23:07] <bcoudurier> thanks [08:23:29] <bcoudurier> fuck I got pownd in 3 2v2 in a row [08:23:33] <bcoudurier> hate that [08:23:53] <peloverde> hmm... I need to find a new FFmpeg related project to work on [08:24:55] <Dark_Shikari> make the aac encoder suck less [08:24:56] * elenril wishes he had time for sc2 [08:25:08] <Dark_Shikari> bcoudurier: have you played the singleplayer yet? [08:26:47] <merbzt1> peloverde: well the dca encoder needs some love [08:26:49] <Dark_Shikari> also, snape kills kerrigan with dumbledore [08:27:09] <peloverde> I'm sick of AAC, I don't have good ears, relying on others has very high latency, it's tolerable at high bitrates, and I get so apprehensive about the encoder that I make up excuse to not work on it like playing sc2 all day [08:27:41] <peloverde> Whatever codec they use for the prerendered video blows [08:27:46] <bcoudurier> Dark_Shikari, first mission [08:28:00] <bcoudurier> then I did 1v1 to check in which league I would end up [08:28:04] <bcoudurier> I'm in plat currently [08:28:10] <saintdev> peloverde: as long as you're willing to answer my questions ;) [08:28:39] <kshishkov> peloverde: please provide a sample [08:29:13] * kshishkov suspects that Blizzard still uses RAD Game Tools codecs for cutscenes [08:29:32] <bcoudurier> I've seen some ogg files [08:29:38] <peloverde> I don't have appropriate tools to bust open the MPQs on linux, I'll have to wait until i reboot [08:29:47] <mru> chris blizzard? [08:29:48] <elenril> sc2 works in wine? [08:29:53] <Dark_Shikari> elenril: should [08:29:55] <lu_zero> wine 1.2 [08:29:59] <Dark_Shikari> I've been playing it in wine for months [08:30:09] <bcoudurier> well I can only play low on my macbookpro :/ [08:30:13] <Dark_Shikari> though I think their last beta patch broke things [08:30:22] <Dark_Shikari> Oh yeah, there was a kernel bug. [08:30:22] <bcoudurier> but that's fine, TLO plays low as well ;) [08:30:23] <elenril> Dark_Shikari: weren't you the evil windoze guy? [08:30:26] <Dark_Shikari> elenril: yes [08:30:27] <kshishkov> mru: should be a piece of good news - "Monty admits using Xvid and MP3 for his encodings" [08:30:32] <Dark_Shikari> I've just tested it some on wine [08:30:33] <lu_zero> apparently also the wine developers are playing sc [08:30:47] <Dark_Shikari> it turns out there was a kernel bug stopping SC2 from working [08:30:49] <bcoudurier> I installed win7 just for it :/ [08:30:50] <lu_zero> kshishkov: but not ffmpeg [08:30:58] <Dark_Shikari> they added an anti-debug thing that used "icebp" [08:31:06] <Dark_Shikari> but a kernel bug broke the trapping for that instruction [08:31:08] <kshishkov> lu_zero: games is #1 reason why people still use Windows [08:31:21] <kshishkov> lu_zero: #0 is legacy crap [08:31:25] <mru> kshishkov: I thought it was stupidity [08:31:29] <Dark_Shikari> or wait, maybe that was wow [08:31:33] <Dark_Shikari> it was one of the blizzard games that broke. or both. [08:31:55] <peloverde> What's the mpq program that doesnt suck? [08:31:55] <Dark_Shikari> anyways I just beat the campaign [08:31:57] * kshishkov thought Blizzard had developed more than two games [08:32:01] <mru> hmm, firefox is a blizzard game... [08:32:12] <lu_zero> mru: o_O? [08:32:29] <mru> lu_zero: chris blizzard [08:32:38] <mru> the ubertard [08:32:49] <kshishkov> "grab as much RAM as you can" is not a good game [08:32:58] <kshishkov> mru: what about Drepper then? [08:33:12] <mru> he's just an arrogant bastard [08:33:19] <bcoudurier> how's the campaign ? [08:33:31] <mru> drepper is smart, misguided, and arrogant [08:33:38] <mru> a very dangerous combination [08:33:53] <Dark_Shikari> http://vimeo.com/13457383 [08:33:56] <Dark_Shikari> this is really fucking cool. [08:34:11] <peloverde> I see a bunch of .ogv files [08:34:23] <Dark_Shikari> peloverde: theora is better than bink [08:34:31] <Dark_Shikari> also, they probably didn't use enough bitrate [08:34:35] <Dark_Shikari> given just how much cinematics the game has [08:35:01] <kshishkov> Dark_Shikari: Bink is better - it's not that easy to encode into it so it's still niche format [08:35:37] <mru> Dark_Shikari: see, that's why games on bluray is a good idea [08:35:41] <mru> 50GB of space [08:35:50] <Dark_Shikari> mru: no, bad idea [08:35:52] <Dark_Shikari> then we get final fantasy 14 [08:35:58] <Dark_Shikari> or 13 or whatever [08:36:01] <Dark_Shikari> where the game is 90% cutscenes [08:36:07] <lu_zero> Dark_Shikari: nah [08:36:07] <mru> I didn't say it was impossible to fuck it up [08:36:14] <Dark_Shikari> and every 2 hours [08:36:16] <lu_zero> the tutorial is 90% story [08:36:16] <Dark_Shikari> they let you play the game [08:36:18] <kshishkov> Dark_Shikari: ever heard of Phantasmagoria ? [08:36:21] <bcoudurier> hehe [08:36:24] <Dark_Shikari> kshishkov: yes, but that was done right [08:36:29] <Dark_Shikari> it's fine if the game is ALL cutscenes. [08:36:31] <peloverde> Couldn't they have but better cutscenes in the 0day patch? [08:36:33] <bcoudurier> ff13 scenario sucked [08:36:39] <bcoudurier> but I still finished 100% [08:36:41] <Dark_Shikari> it's not fine if it's 90% cutscenes and 10% stupid grinding [08:37:04] <lu_zero> Dark_Shikari: you get to finish it? [08:37:08] <bcoudurier> well the producer said that now they have the engine [08:37:16] <Dark_Shikari> lu_zero: I haven't seriously played an FF game since 10 [08:37:18] <bcoudurier> they would like to reuse it for the next game [08:37:36] <lu_zero> I wonder if the story would end flat [08:37:38] <Dark_Shikari> If I want to play an interactive movie, I'll play an interactive movie with less grinding. [08:37:42] <bcoudurier> X was very nice [08:37:45] <Dark_Shikari> Japan makes lots of them [08:37:47] <Dark_Shikari> they're called visual novels [08:37:55] <kshishkov> Dark_Sikari: no, cutscenes there actually were <50%, but still 7 CDs for the first game and 5CDs for the second [08:38:14] <lu_zero> X was bearable [08:38:22] <bcoudurier> come on [08:38:25] <lu_zero> but completing it is daunting [08:38:30] <bcoudurier> don't say your favorite is the 6 [08:38:33] <kshishkov> aren't visual novels mostly static images? [08:38:34] <bcoudurier> us 6 [08:38:35] <lu_zero> X-II was more or less the same [08:38:47] <lu_zero> bcoudurier: mine had been 7 [08:38:56] <bcoudurier> ok we agree on this [08:39:01] <lu_zero> 12 felt like wow [08:39:03] <kshishkov> lu_zero: X-II = VIII, learn your arithmetics already [08:39:18] <bcoudurier> I didn't play 12 [08:39:19] <Dark_Shikari> kshishkov: well, some are more animated than others. [08:39:23] <lu_zero> 5 and 6 are fun [08:39:25] <bcoudurier> heard game play sucked [08:39:30] <lu_zero> bcoudurier: nah [08:39:37] <lu_zero> the gameplay is fine [08:39:39] <elenril> 12 is a jrpg trying to be a western rpg [08:39:42] <bcoudurier> 7 had an awesome scenario [08:39:45] <elenril> and failing at that [08:39:49] <lu_zero> and the game isn't that bad [08:40:01] <lu_zero> just feel like wow [08:40:21] <Yuvi> I liked 9 for some reason, I think I'm pretty alone there [08:40:24] <bcoudurier> anyway I'm going to bed guys [08:40:37] <bcoudurier> humm 9 was decent [08:40:37] <lu_zero> 9 was better than 8 [08:40:43] <lu_zero> bcoudurier: nite [08:40:53] <bcoudurier> well in the 8, we had the first damage > 9999 with orbital [08:41:02] <bcoudurier> that was cool ;) [08:41:06] <lu_zero> pff [08:41:16] <lu_zero> that reminds me 10 [08:41:21] <Yuvi> 8 had the great idea of scaling all encounters by level [08:41:27] <Dark_Shikari> like oblivion [08:41:28] <KotH> lu_zero: ah.. these are not earthquake monitoring devices, but earth movement monitoring devices [08:41:43] <lu_zero> KotH: yes, that one =) [08:41:46] <elenril> 8 had the great idea of not having to grind [08:41:56] <KotH> lu_zero: to measure the movements of the ground in high mountains using gps... with a resolution of 5mm ^^' [08:41:56] <lu_zero> elenril: uh? [08:41:59] <Dark_Shikari> imagine if final fantasy had no random encounters. [08:42:00] <lu_zero> _not_ having [08:42:00] <Dark_Shikari> =p [08:42:03] <bcoudurier> 8 was too easy [08:42:08] <bcoudurier> you'd put 99 dark matter on your weapon [08:42:21] <KotH> lu_zero: hw is mostly designed, being in production now... software is SEP :) [08:42:23] <lu_zero> Dark_Shikari: Chrono serie [08:42:23] <elenril> that's good [08:42:32] <lu_zero> KotH: nice =) [08:42:35] <Dark_Shikari> lu_zero: yes, remember when jrpgs were actually good? [08:42:36] <elenril> combat in jrpgs is boring and pointless [08:42:38] <Dark_Shikari> chrono trigger? [08:42:44] <lu_zero> cross [08:42:51] <Yuvi> cross was ugh [08:42:51] <bcoudurier> but the card game was fun [08:42:54] <Dark_Shikari> elenril: Except for the rare good boss battle. [08:43:02] <lu_zero> Yuvi: compared to trigger yes [08:43:19] <astrange> tales of * have a good battle system [08:43:20] <bcoudurier> anyway I'm off this time [08:43:22] <bcoudurier> good night [08:43:33] <KotH> lu_zero: now i'm back to coding an usb device stack ^^' [08:43:35] <astrange> actually most games would be improved if all their systems were replaced with tales of vesperia [08:43:38] <lu_zero> ouch [08:43:41] <Dark_Shikari> lol [08:43:42] <lu_zero> usb-3 [08:43:45] <lu_zero> ? [08:43:47] <Dark_Shikari> haven't played tales; what's it do right [08:43:47] <Dark_Shikari> ? [08:43:56] <lu_zero> astrange: I'll try them [08:43:58] * elenril thinks all jrpgs would be improved if they were remade as VNs [08:44:03] <Dark_Shikari> elenril: wrong [08:44:09] <Dark_Shikari> a lot of JRPGs have shit story [08:44:14] <Yuvi> hm, I haven't played a tales since phantasia [08:44:15] <lu_zero> right now in my list I want to try Persona * [08:44:16] <Dark_Shikari> VNs rely entirely on storytelling, because they're books [08:44:20] <elenril> Dark_Shikari: so do Vns [08:44:22] <Dark_Shikari> so if the story is crap, there's nothing left [08:44:28] <elenril> most Vns are crap [08:44:33] <Dark_Shikari> that's not what I mean [08:44:36] <KotH> lu_zero: btw: diego seems to be online... at least he's commiting lots of stuff [08:44:52] <Dark_Shikari> Most games suck, but every single game has some focus on gameplay [08:44:55] <astrange> it's 3d/realtime with attack combos and the characters have varied combat styles [08:44:57] <lu_zero> he might end up in Torino next week [08:45:00] <elenril> Dark_Shikari: well if the story is crap, then combat won't save it [08:45:01] <Dark_Shikari> that is, if the game sucks, the gameplay sucks [08:45:04] <kshishkov> elenril: how many VNs have you tried? [08:45:05] <Dark_Shikari> same with a book [08:45:09] <Dark_Shikari> in a book, if the story sucks, the book sucks [08:45:15] <Dark_Shikari> but there are good games with bad story [08:45:19] <elenril> gamplay in jrpgs sucks by design [08:45:24] <Dark_Shikari> i.e. gameplay makes the game, story makes the bookk [08:45:27] <lu_zero> two games that I found quite interesting were vagrant story and parasite eve [08:45:30] <Dark_Shikari> so... conversion doens't always work out. [08:45:31] <elenril> kshishkov: ~5 i think [08:45:31] <lu_zero> (2) [08:45:31] <Yuvi> do you actually get to controll all the characters or does it give you a crap AI like star oceans? [08:45:45] <Dark_Shikari> astrange: 3d/realtime with attack combos... [08:45:47] <Dark_Shikari> sounds like wow [08:45:47] <KotH> lu_zero: nope, just a full speed, usb2.0 stack. there are no usb3 capable embedded devices yet... actualy there are still very few high speed capable ones [08:45:58] <kshishkov> elenril: what're their names? [08:46:00] <lu_zero> I see [08:46:27] <astrange> you can switch between party characters to control, the rest get ai (or you can get someone else to control them) [08:46:39] <Dark_Shikari> dragon age? [08:46:46] <astrange> and attacks are mapped to buttons rather than constant pauses to find a radial menu like dragon age [08:46:50] <elenril> kshishkov: ever17, remember11, fate/stay night, tsukihime, umineko, planetarian [08:47:13] <astrange> plus the damage is tuned better so non-boss fights are interesting for a while [08:47:13] <Dark_Shikari> that reminds me, I should go and read remember11 for real sometime [08:47:15] <kshishkov> elenril: ok, when I'll finally try VNs, I'll avoid those [08:47:15] <Dark_Shikari> then again, it kept crashing [08:47:18] <Dark_Shikari> kshishkov: lol [08:47:23] * elenril shoots kshishkov [08:47:29] <Dark_Shikari> many of those on the list are like... hte best ones ever >_> [08:47:35] * kshishkov resists the damae [08:47:35] <astrange> and the final boss is a white guy whose secret form is a black guy [08:47:42] <Dark_Shikari> LOL [08:50:22] <Dark_Shikari> damn, a lot of VNs I should play [08:50:26] <Dark_Shikari> a ton of translated stuff came out recently [08:50:40] <Dark_Shikari> and more stuff about to come out [08:50:54] <Dark_Shikari> s/play/read [08:51:37] <Dark_Shikari> elenril: so, how far are you in sc2 [08:51:43] <peloverde> Assets/Textures/cinematic_thedream.ogv shows a bunch of artifacting [08:52:02] <kshishkov> Dark_Shikari: so, what's your backlog of Touhou VNs? [08:52:42] <Dark_Shikari> kshishkov: there are no translated touhou VNs [08:52:56] <peloverde> I'm about 8 missions in [08:53:05] <Dark_Shikari> peloverde: snape kills kerrigan with dumbledore [08:53:16] <kshishkov> Dark_Shikari: so? that means nothing was lost in translation. [08:53:23] <peloverde> I accidentally watched the wrong cutscene a minute ago :( [08:54:05] <Dark_Shikari> warning: villains carry pockets full of idiot balls all the way through. [08:54:15] <Dark_Shikari> and almost every mission name is a pop culture reference [08:56:18] <peloverde> So far I'm regretting having chosen normal, but maybe the difficulty will ramp up toward the end of the campaign like sc1/war3 [08:56:28] <Dark_Shikari> I chose hard. it wasn't too hard [08:56:35] <Dark_Shikari> there were only a couple missions where I ever had to reload [08:56:48] <peloverde> I chose easy because I spent most of the beta in copper/bronze [08:57:04] <peloverde> err normal, not easy [08:57:35] <Dark_Shikari> the last mission is a bitch if you don't pay attention to the advice given to you on the loading screen (kill the bloody nydus worms) [08:57:46] <CIA-92> ffmpeg: stefano * r24569 /trunk/ (libavfilter/Makefile configure): [08:57:46] <CIA-92> ffmpeg: Remove reference to the unexisting movie filter and the corresponding [08:57:46] <CIA-92> ffmpeg: useless --enable-avfilter-lavf option. [08:57:46] <CIA-92> ffmpeg: stefano * r24570 /trunk/libavfilter/Makefile: [08:57:46] <CIA-92> ffmpeg: Require libswscale only if the scale filter is used. [08:57:47] <CIA-92> ffmpeg: Although with several limitations, lavfi can be compiled and used [08:57:48] <CIA-92> ffmpeg: without the scale filter. [08:57:49] <Dark_Shikari> since in the campaign, unlike in multiplayer, they are infinite unit-spawners [08:57:52] <Dark_Shikari> it's really annoying [08:57:55] <Dark_Shikari> because I hate infinite unit-spawning [08:58:23] <kshishkov> good for zergs [08:59:22] <elenril> Dark_Shikari: i'm not playing it [08:59:33] <elenril> no time+my laptop wouldn't handle it [09:00:14] * kshishkov donates Gdium to elenril [09:00:15] <Dark_Shikari> yes you do have time [09:00:16] <Dark_Shikari> make time [09:00:24] <elenril> soon [09:00:30] <elenril> when i finish my bc paper [09:01:18] <funman> sc1 > * [09:01:58] <mru> that looks like a css selector [09:02:53] <kshishkov> it may work in some shell too [09:03:28] <mru> bash: *: ambiguous redirect [09:03:31] <Dark_Shikari> kshishkov: prefetcht0 [rv40 memories] [09:03:38] <Gumboot> Urgh... 17th window... this won't do. [09:04:03] <Gumboot> Dark_Shikari: what does the t0 suffix do? [09:04:13] <Dark_Shikari> prefetch to lowest level cache [09:04:14] <funman> [ $starcraft -gt $1 ] || kernel_panic [09:04:39] <kshishkov> Dark_Shikari: I'm not into x86 SIMD much [09:04:52] <mru> kernel_panic: command not found [09:05:00] <Dark_Shikari> kshishkov: prefetch isn't simd. [09:05:01] <mru> kshishkov: that's not simd [09:05:02] <av500> poke 1,0 [09:05:19] <kshishkov> mru: but usually make sense with it [09:05:30] <mru> prefetch always makes sense [09:05:53] <funman> there's no postfetch ? [09:05:54] <mru> although hw speculative prefetchers are getting pretty good [09:06:11] <mru> funman: that would be blocking caches [09:06:16] <mru> ~curse blocking caches [09:06:17] <kshishkov> Dark_Shikari: okay, I flushed that cache anyway [09:06:32] <funman> it would be good for benchmarking [09:06:34] <Gumboot> kshishkov: I got stuffed back in the RV40 cage and while I was in there I found my old list of bug workarounds, and I wanted to see if they were on your list. Keep in mind, though, that I'm NDA-ed and I'll have to go and re-read the Ts and the Cs to see if I can share. [09:06:54] <Gumboot> s/workarounds/emulations/ [09:07:28] <kshishkov> wonderful! [09:07:54] <Gumboot> Shall I repeat the term "NDA", here? It's not that wonderful. [09:08:12] <kshishkov> I wonder if there were special clause to prevent devs disclosing that codec sucks? [09:08:25] <Gumboot> Ooh... I hope not. I might be in trouble already. [09:08:30] <funman> NSDA [09:09:00] <av500> godwi [09:09:02] <kshishkov> Gumboot: I suspect I know most about it already [09:09:53] <Gumboot> There's some preprocessor stuff that reveals intentions that might change your perceptions a little. [09:10:24] <Gumboot> Anyway, do you have a list of bug emulations? [09:10:42] <av500> yes, but only under NDA [09:10:47] <kshishkov> yes, it's the whole decoder :) [09:10:53] <av500> pssst [09:11:29] <mru> people take NDAs far too seriously [09:11:37] * kshishkov can show where his specs are stored. In nice .so format [09:11:50] <merbzt1> ohh, binary specs [09:11:53] <merbzt1> best there is [09:12:15] * funman wish he had specs in elf format [09:12:26] <merbzt1> funman: for what ? [09:12:43] <funman> rockbox drivers [09:13:47] <KotH> http://lwn.net/Articles/397422/ <- refreshing article on academics vs real world [09:14:12] <mru> 408 Subscription required [09:14:26] <lu_zero> how refreshing? [09:14:38] <janneg> http://lwn.net/SubscriberLink/397422/d283e1959b4592db/ [09:14:38] <kshishkov> Gumboot, your name reminds me of people who wrote RV3/4 (e.g. Chief Developer Gumby) [09:15:36] <Gumboot> Nope, not me at all. [09:15:53] <kshishkov> of course not you, you're too intelligent [09:16:29] <kshishkov> but you should have heard of Gumbies [09:16:30] <Gumboot> I just did a porting job on the reference code, but I had to do a lot of bug emulation on the way through because I need more substantial optimisations than just replacing the leaf nodes with assembly. [09:16:47] <kshishkov> proting to what? [09:16:53] <Gumboot> BCM2727 originally. [09:17:23] <kshishkov> ah, go on [09:17:57] <Gumboot> With 16-way SIMD you don't want to be doing leaf-node optimisations on 4-pixel edge functions all the time, so you have to rewrite the calling functions. [09:18:15] <kshishkov> indeed [09:19:29] <Gumboot> Then you find that it doesn't work anymore, and so you have to and do more advanced work to emulate what appear to be copy-and-paste errors. [09:19:54] <mru> like the qpel duplicated position [09:20:22] <Gumboot> That one's in the spec. [09:20:31] <mru> there's a spec? [09:20:59] <Gumboot> The spec is actually on a public https location, but I don't know if I'm allowed to share that address. [09:21:13] <kshishkov> Gumboot: if it's public - then yes [09:21:41] <Gumboot> Not worth my job. [09:21:53] <mru> geeez, some people are paranoid [09:21:59] <Gumboot> (not that it's a fantastic job, mind, but general professionalism and all that) [09:22:00] <kshishkov> share it in private [09:22:10] <Gumboot> Well now if there's a leak I get the blame anyway! [09:22:24] <kshishkov> anyway, my decoder is bitexact on I and P-frames [09:22:43] <mru> Gumboot: do you really think anyone will 1) notice or 2) care? [09:22:51] <kshishkov> for B-frames it lacks weighted prediction and maybe loop filter is incorrect [09:22:52] <Yuvi> wonder if this spec is googleable if you knew the right keywords [09:23:09] <Gumboot> I tried, and it turned out to not be. Unless I didn't know the right words. [09:24:52] <kshishkov> okay, what can you say anyway? [09:25:51] <Gumboot> I guess I can say that the QP doesn't vary in any encoder, now or future, and that leads to a lot of optimisation. [09:26:47] <kshishkov> heh, so when I used DQUANT appearance as error condition was right :) [09:27:09] <CIA-92> ffmpeg: mstorsjo * r24571 /trunk/libavformat/rtsp.c: rtsp: Move the definition of SDP_MAX_SIZE up, use it in the RTSP muxer, too [09:27:24] <Gumboot> But really I was just wondering if there's a list of observed deviations-from-the-obvious that I can compare mine to. [09:27:42] <Gumboot> Aside from the well-known bottom-right qpel filter. [09:27:52] <kshishkov> it's hard to say so - we don't have spec and it was written with deviations in mind [09:28:14] <kshishkov> different rounding constant in MC is also in spec, I presume [09:28:21] <kshishkov> *constants [09:28:48] <Gumboot> I didn't actually bother to check. It was in the comments in the reference. [09:29:11] <kshishkov> my reference had no comments [09:29:23] <mru> I'm sure you had ample comments about it [09:29:36] <kshishkov> no, I self-censor myself [09:29:56] * mru hopes kshishkov doesn't self-censor others [09:30:12] <kshishkov> of course not, by definition [09:30:32] <Gumboot> No, not ample. They weren't so big and flashy that I noticed them within half an hour of trying to figure out where I'd gone wrong. [09:30:36] <mru> so 'myself' was redundant [09:31:22] <kshishkov> mru: maybe. Me is no good at English language [09:31:46] <kshishkov> Gumboot: I hope you had fun with loop filter [09:32:09] <Gumboot> At least half of my development effort went into it. [09:32:20] <Gumboot> Maybe 2/3. [09:32:42] <merbzt1> who are buying rv40 decoders ? [09:32:47] <Gumboot> NFI. [09:32:49] <kshishkov> Chinese? [09:32:52] <mru> merbzt1: china [09:33:24] <kshishkov> just look at any good tracker - they still release stuff in .rmvb [09:33:29] <Gumboot> When I'm rich I might start a company called NFI. Maybe I'll get business by default. [09:33:55] <av500> merbzt1: all chinese p2p content is still rv [09:34:03] <av500> s/all/most/ [09:34:19] <merbzt1> ok that makes it more understandable [09:34:29] <merbzt1> but why do they encode in that format [09:34:35] <merbzt1> the tools must be horrible [09:34:36] <av500> nobody knows [09:34:42] <av500> even real does not know [09:34:44] <kshishkov> misterious Eastern souls [09:34:47] <av500> we asked them [09:34:54] <kshishkov> (from German "Das Mist") [09:34:55] <merbzt1> :) [09:35:16] <av500> real guesses that at some point in time, rv producer was an ok sw and that stuck [09:35:31] <av500> cargo cult from then on [09:36:08] <mru> more likely sw was crap, someone released a few popular titles with it anyway, and there was cargo cult [09:36:17] <av500> mru: could well be [09:36:38] <Yuvi> one explanation I heard was that at the bitrates the chinese use (think 50-100 MB per 20 min show) rv40 looked the best [09:36:38] <Yuvi> this was in the window between real releasing it and x264 becoming good [09:37:26] <Gumboot> I think the encoding tools are public, aren't they? [09:37:32] <Gumboot> Real Producer, or something like that. [09:37:55] <Gumboot> With its confusing ..umm.. 'recipe-based' command line, or whatever it is. [09:37:56] <kshishkov> Yuvi: maybe it was good for anime - 4x4 blocks and such [09:37:58] <Gumboot> I think it's recipes. [09:38:25] <Gumboot> I don't think China has much anime, does it? They seem to be all about soaps and Hollywood movies. [09:38:40] <Yuvi> kshishkov: was real ever widely used for english anime after the dialup days? [09:38:55] <av500> the samples I have show a strong interest in hally pottel as well [09:39:54] <kshishkov> Yuvi: a good question to ask for guy who had nothing to do with neither English or anime in dialup days [09:39:55] <Yuvi> dunno, I doubt anime drove codec choice in china unlike america [09:40:14] <kshishkov> but IIRC cartoons were encoded into .rm in Russia as well [09:40:29] <Yuvi> france was a pocket for real too for a while [09:40:37] <mru> imo cartoons are still cartoons, even if in japanese [09:40:39] <kshishkov> French are perverts anyway [09:41:22] <kshishkov> mru: you're likely haven't seen Soviet cartoons [09:41:40] <av500> in soviet russia, cartoon see you [09:42:12] <KotH> kshishkov: can you get us some examples? [09:42:48] <kshishkov> KotH: it's all on YouTube [09:44:30] <KotH> kshishkov: youtube lacks quality and archival features [09:44:36] <Gumboot> I think that China uses Real because China likes adware. [09:44:49] <Gumboot> All the popular Chinese software seems to be adware. [09:45:44] <Gumboot> If you want a sharp increase in your userbase, turn it into adware. You lose everyone in the rest of the world, but pick up the whole of China. [09:47:36] <mru> hmm, ffads [09:48:21] <kshishkov> KotH: original quality is not good either. For example, I don't remember any Soviet cartoon with bright colours [09:48:57] <av500> they would have been unrealistic... [09:53:23] <KotH> kshishkov: hmm... [09:53:56] <KotH> kshishkov: do you have any recomendations? [09:54:55] <KotH> kshishkov: i loved the czech children series back when i was small. they were refreshingly different (ie cared more about a consistent story plot than fancy effects) [09:55:16] <kshishkov> KotH: I remember only one of those - with little mole [09:55:24] <KotH> hmm.. or were they polnish?... dont remember [09:55:55] <KotH> kshishkov: http://en.wikipedia.org/wiki/Mole_%28Zden%C4%9Bk_Miler_character%29 ? [09:56:09] <kshishkov> KotH: yes, exactly [09:56:44] <KotH> eh.. [09:56:59] <KotH> that one was and is still quite famous in the german speaking area [09:57:04] <KotH> (probably even wider) [09:58:18] <kshishkov> still, you'd better ask thresh [09:58:41] <av500> KotH: I have the DVD :) [09:59:33] <thresh> kshishkov: about? [09:59:41] <thresh> (not following, just came back from lunch) [09:59:44] <kshishkov> Soviet cartoons [09:59:54] <thresh> they suck mostly [10:00:11] <kshishkov> Ð° "ÐÐ¶ÐžÐº Ð² ÑÑÐŒÐ°ÐœÐµ"? [10:00:24] <thresh> that's an exception that proves the rule [10:00:33] <thresh> that, and 'winnie-the-pooh' [10:00:49] * Rathann|work remember watching the one about the woolf and a rabbit when he was little [10:00:58] <merbzt1> the rabbit and the wolf then ? [10:00:59] <Rathann|work> *remembers [10:01:03] <kshishkov> thresh: Ð° ÐµÑÐ»Ðž Ñ ÐœÐµ Ð»ÑÐ±Ð»Ñ ÐœÐ°ÑÐºÐŸÐŒÐ°ÐœÑÐºÐžÐµ ÐŒÑÐ»ÑÑÐžÐºÐž? Ð¢ÐŸÐ³ÐŽÐ° ÑÐŸÐ»ÑÐºÐŸ ÐÐžÐœÐœÐž-Ð¿ÑÑ [10:01:22] <Rathann|work> meh, I can't spell today [10:01:22] <merbzt1> what rathann said [10:01:34] <thresh> kshishkov: you would enjoy 'Ð©Ð°Ñ ÑÐ¿ÐŸÑ' then [10:01:38] <kshishkov> merbzt1: Tom and Jerry clone for Soviet Union in essence [10:02:15] <Rathann|work> the czech(oslovakian?) "neigbours" were hilarious [10:02:20] <thresh> Rathann|work: it's called 'Nu pogodi' [10:02:35] <Rathann|work> ah yes, sounds familiar [10:04:04] <kshishkov> Rathann|work: yes, Soviet stuff was very popular in Warsaw pact countries. Especially Soviet army [10:30:35] <CIA-92> ffmpeg: stefano * r24572 /trunk/MAINTAINERS: Add my GPG fingerprint and add myself as ffprobe.c maintainer. [10:36:42] <Gumboot> Is that Tom and Jerry with political overtones one might infer from the character names? Or just a cat and a mouse doing cat and mouse stuff? [10:37:18] <Gumboot> (yes, you would have to be one of those student types who tries too hard to find extra layers of meaning in everything, but there are plenty of those) [10:48:07] <kshishkov> everything targeting children made in Soviet Union was either with obvious ideological component, idiotic or made on drugs [10:48:43] <Gumboot> What about all three? I'd watch it if it had all three. [10:48:43] * kshishkov preferred books from foreign authors in his childhood, especially Astrid Lindgren [10:49:31] <thresh> I wouldnt say 'nu pogodi' was of any ideology or idiocy [10:49:44] <thresh> rather ironic on 'stagnation' period [11:03:33] <Gumboot> kshishkov: Did you find test content for RPR, by the way? [11:04:25] <kshishkov> Gumboot - lots of it [11:05:00] <kshishkov> Chinese often encode group logo in one resolution and the rest of file in another one [11:05:41] <Gumboot> Was there actually any resizing you had to do? There was a bunch of documentation and code for it, but when I actually ran RPR streams, it never seemed to get called. [11:06:27] <kshishkov> yes, of course [11:06:38] <Gumboot> Hm. [11:06:45] <Gumboot> Maybe I need to see better test streams. [11:06:50] <Gumboot> Got any links? [11:07:17] <kshishkov> just a moment, something should be on MPHQ [11:07:54] <Gumboot> Most of what I did was just knocking down the worst part of th profile, but the rescaling never showed up. I tried to set a breakpoint, but it never hot hit. [11:08:16] <Gumboot> There's a _lot_ of never-executed code in the reference, though, so I just accepted it. [11:09:07] <Gumboot> (that's why it's always a relief to find somebody saying that most of these features aren't actually supported -- because I could never see how the code was going to work with them) [11:12:00] <kshishkov> what about samples in http://samples.mplayerhq.hu/real/anamorphic/ ? [11:12:17] <kshishkov> or http://samples.mplayerhq.hu/real/size_change/ [11:13:12] <Compn> since we dont have rv specs, the only code created was based on samples... [11:15:45] <Gumboot> I tested using the files in the rarvcode-tck subproject at helixcommunity.org. [11:16:17] <Gumboot> The resolution changed, but all that resizing business seemed irrelevant. Using their reference decoder things just blanked out during the resize. [11:20:50] <kshishkov> well, I don't have access to the reference decoder either [11:22:28] <merbzt> http://blogs.gnome.org/uraeus/2010/07/26/collabora-multimedia-at-guadec/ [11:22:41] <Gumboot> What about Real Alternative? [11:22:46] <Gumboot> Can that dump YUV? [11:23:35] <kshishkov> dunno [11:23:40] <kshishkov> I used MPlayer [11:23:51] <Gumboot> Can that use the Real libraries? [11:23:58] <kshishkov> (since FFmpeg still lacks binary codec loader) [11:24:02] <kshishkov> of course [11:24:26] <kshishkov> bbl [11:24:54] <Gumboot> I should test that. I don't know what the odds are on Real's on player library being compatible with their reference decoder. [11:30:50] <Compn> what are you doing anyways Gumboot ? [11:31:03] * Compn reads log [11:31:45] <Vitor1001> Weird, my first try of writing YASM code assemble but does not link. [11:32:06] <Vitor1001> Errors: http://ffmpeg.pastebin.com/rBGksr9R [11:33:18] <Gumboot> Compn: Not a lot, now. I'm done with my Real Video redux; but it made me think that maybe I should check my bug emulation against ffmpeg's bug emulation to see that I haven't missed anything. [11:33:26] <Compn> ah [11:33:59] <Gumboot> Actually, I'll be running in circles doing conformance testing on a bunch of other codecs and things like that. Just as soon as I get off my arse and go to work. [11:34:26] <Compn> some kind of hardware/mobile player ? [11:37:18] * Compn googles for some rv40 spec page [11:38:57] <Gumboot> Good luck! [11:38:59] <Vitor1001> ping Dark_Shikari [11:39:27] <Compn> RV9DecoderExternalSpecificationv15 [11:39:30] <Compn> hmmm [11:39:38] <Gumboot> Holy crap. You found one? [11:39:46] <Compn> well, lets not count them chickens yet [11:39:49] * Compn waits for webpage to load [11:40:48] <Gumboot> Current version is 18. [11:40:54] <Gumboot> Or 1.8, or whatever. [11:41:40] <Gumboot> So what you found is in China, then, eh? [11:41:46] <Compn> http://www.docin.com/p-57120909.html [11:41:53] <Compn> probably [11:41:58] <Compn> flash based viewer [11:42:09] <Compn> i'll try to find 1.8 now that i know that bit of information [11:42:28] <Gumboot> I already searched. There's nothing there. [11:42:36] <Gumboot> Well, I say that. It shows my complete faith in Google, doesn't it. [11:43:30] <Gumboot> Anyway, my project is just a port to a chip. The chip normally goes in mobile phones, but people have been known to make other devices withi t. [11:43:40] <Gumboot> But if I knew what anybody was making with it, I wouldn't be able to tell you. [11:43:51] <Gumboot> It normally shows up in the teardowns. [11:44:04] <Vitor1001> If anyone is looking at my problem, I've just fixed it, was missing a SECTION_RODATA. [11:46:17] <Compn> Gumboot : ah, well i'm just asking dumb questions anyways, you probably shouldnt tell me anything :) [11:46:39] * _av500_ is on train to ffcon(steam train work group) [11:47:24] <funman> are you going to optimize steam? [11:47:34] <jai> funman: is that even possible? [11:48:09] <funman> perhaps by applying transforms to the water molecules, who knows [11:48:17] <jai> hmm, i have never written any asm for lavc till now [11:48:19] <jai> shame on me [11:48:44] <funman> write some c, build with gcc -S, pretend you have written it :o) [11:49:02] <jai> and get flamed to a crisp ;) [11:52:35] <cartman> "When disassembling, you can detect C++ code by the tons of do-nothing wrappers" [11:52:37] <cartman> nice one ha [12:09:18] <CIA-92> ffmpeg: michael * r24573 /trunk/libavutil/log.c: Make sure "Last message repeated" is printed. [12:29:39] <Compn> soo [12:29:47] <Compn> whats next on the agenda today [12:30:09] <kshishkov> VP7 for av500 [12:30:17] <kshishkov> BINKb for pross-au [12:30:22] <kshishkov> and pony for Diego [12:30:23] <mru> vp7.de [12:30:55] <_av500_> kshishkov: pony for my daughter too [12:31:34] <kshishkov> _av500_: steal it from Diego [12:32:22] <_av500_> easy, all diegos are small [12:32:53] <cartman> this is Don-Diego [12:34:13] <kshishkov> cartman: have you ever seen that Diego? he's small [12:34:25] <cartman> nah :) [12:34:29] <cartman> didn't see him [12:34:48] <_av500_> see, so small :) [12:38:00] <KotH> cartman: have you ever seen av500? he is a fucking giant! [12:38:18] <cartman> I guessed from the 500 part [12:38:18] <cartman> :P [12:38:57] <kshishkov> KotH: are you crazy? he got rather normal dimensions [12:46:05] <KotH> kshishkov: i've heard that you are also one of those human phalic symbols [12:47:50] * kshishkov sends av500 to deal with KotH [12:48:18] * KotH takes out some swiss chocolate to deal with av500 [12:50:41] * kshishkov points out that KotH is poor and cannot afford enough chocolate to deal with av500 [12:50:58] <Compn> btw i went to ikea store the other day [12:51:08] <Compn> and bought 3 bags of those gummy kars [12:51:21] <Compn> addicting candy [12:51:45] <Compn> did KotH send me a bag of those years ago? hmm [12:52:05] <Compn> or was that my swedish friend [12:54:29] <KotH> that must have been a swedish friend [12:54:35] <KotH> i would have send you chocolate cars [12:54:58] <KotH> kshishkov: that chocolate goes on company expenses :) [12:55:03] <mru> Compn: "ahlgrens bilar" ? [12:55:16] <spaam> Ahlgrens bilar <3 [12:55:46] <kshishkov> KotH: and disclose my address to you? no way! [12:56:32] * kshishkov has missed the chance to taste Swedish sweets (except lingonsylt) [12:56:47] <mru> you didn't miss much [12:56:53] <KotH> kshishkov: i already know where you work. figuring out the rest is easy [12:59:21] <Compn> mru : yes, ahlgrens bilar [12:59:24] * Compn had to find the bag [12:59:49] <Compn> it was hiding from me [13:00:05] <mru> wonder why... [13:06:00] <KotH> Ahlgrens [...] founded [..] as a store for paint and wallpaper [...] [13:06:08] <KotH> interesting [13:06:11] <KotH> sounds like nokia [13:14:05] <pJok> kshishkov, i could just mail you some? [13:16:23] <kshishkov> in theory - yes [13:16:46] * kshishkov would prefer Swedish cheese though [13:17:15] <spaam> kshishkov: which one ? :D [13:19:04] <kshishkov> spaam: Vasterbotten and Greve [13:34:46] <Compn> kshishkov : btw, merbzt = ben, i was looking for merbanan haha ;\ [13:35:20] <kshishkov> what's the difference? [13:37:22] <Compn> i dont think there is one, i just forgot the alt nick [13:42:18] <jai> worst case, people will think i'm stu [13:42:29] <jai> err, wrong window [13:43:28] <BBB> j0sh: how do you feel about adding a MJPEG RTP depacketizer/packetizer somewhere later? [13:54:48] <KotH> jai: dont worry, we already know that you're stupid ;-> [13:59:22] <jai> KotH: that was about using java to teach an operating systems course :) [14:01:16] <kshishkov> jai: first five words are enough [14:27:04] <KotH> kshishkov: you mean the fith word was enough [15:03:58] <CIA-92> ffmpeg: michael * r24574 /trunk/tools/patcheck: Warn about "/** text" comments. [15:08:06] <_av500_> mru: I have some nice hd demos on omap3 :) [15:08:21] <_av500_> (in the room next door) [15:12:43] * cartman sniffs and kicks his ARM11 device [15:59:40] <Dark_Shikari> Vitor1001: what [16:00:03] <Vitor1001> Dark_Shikari: Nevermind, was fighting with yasm for the first time [16:00:24] <Vitor1001> Dark_Shikari: I should not forget SECTION_RODATA, or else it will not link :p [16:00:48] <Vitor1001> Dark_Shikari: But now patch is ready and posted to -devel :D [16:01:27] <Honoome> Vitor1001: was that the last use of x86/mmx.h? [16:01:31] <Vitor1001> Dark_Shikari: Thanks anyway [16:01:34] <lu_zero> hm [16:01:44] <lu_zero> why api-example.c is lgpl and not mit? [16:01:53] <lu_zero> it covers quite a basic usage [16:01:55] <Dark_Shikari> good point. it should really be MIT [16:02:05] <Vitor1001> Honoome: libavcodec/x86/idct_mmx.c [16:02:12] <lu_zero> who has copyright on it? [16:02:14] <Honoome> Vitor1001: shit then :P [16:02:28] <Vitor1001> mostly, nobody uses it [16:04:58] <kshishkov> Vitor1001: no good news yet [16:05:37] <Vitor1001> Well, we could copy-and-paste mmx.h to the top of idct_mmx.c [16:06:04] <Vitor1001> BTW, idct_mmx.c is GPL-only [16:28:09] <CIA-92> ffmpeg: reimar * r24575 /trunk/libavformat/udp.c: [16:28:09] <CIA-92> ffmpeg: Check for udp_set_remote_url error. [16:28:09] <CIA-92> ffmpeg: Fixes issue 1784 (hang with nonsense URL/no network available). [16:50:40] <wbs> lu_zero: FWIW, the things I've made in api-example can be relicensed any way you want [16:51:28] <spaam> beerware [16:51:29] <spaam> <3 [16:51:53] <kierank> wtfbbq licence [16:52:17] <spaam> does not exists :O [16:52:24] <spaam> dont lie kierank :O [16:52:29] <kierank> it does [16:52:32] <kierank> i remember seeing it somewhere [16:52:37] <kierank> and it wasn't gpl compatible [16:54:19] <Dark_Shikari> you mean WTFPL [16:56:14] <kierank> that's the one [16:56:27] <Honoome> that's Hocevar's license [16:56:44] <Honoome> and iirc it was gpl-compatible [16:57:17] <Honoome> libcaca is relesed under that and xine uses it... and I think I did check all the license related to that, but siretart would know better since he maintained that for Debian (and they are much more anal about licenses that Gentoo would ever be, given we don't redistribute binaries) [16:58:56] <elenril> put it under "good not evil" licence [17:00:02] <Honoome> nah that _is_ gpl-incompatible :P [17:00:36] * Honoome remembers a license for a package in some Debian external repository "Free to friends of America" [17:00:47] <elenril> lol [17:00:52] <Honoome> I had to forget installing the package [17:01:00] <elenril> good not evil is teh ultimate trolling licence [17:01:06] * KotH is a friend of america, but not of the us [17:01:36] <Honoome> KotH: hah that would have been a witty response indeed... I guess I have no problem with Canada [17:01:37] <Honoome> or Mexico [17:02:13] <kierank> iirc you can offer copyright to the queen [17:02:44] <elenril> brazil is evil though [17:04:18] <Dark_Shikari> wtf [17:04:24] <Dark_Shikari> ffmpeg is dropping the first frame when decoding my h264 files [17:04:29] <Dark_Shikari> just... the default files out of x264 [17:04:37] <KotH> elenril: no, brazil is cool... they are about to outlaw all DRM that does restrict the freedom of fair use [17:04:40] <lu_zero> wbs: given I'm just providing a thin wrapper around _encode and _decode I'll do something even simpler =) [17:06:07] <elenril> KotH: inconceivable! [17:06:27] <kierank> http://thedailywtf.com/Articles/Strong-Web-Design.aspx [17:41:06] <siretart> greetings from debconf10! [18:00:13] <lu_zero> siretart: hi =) [18:20:15] <Dark_Shikari> lol, reimar [18:20:17] <Dark_Shikari> At least it is now documented what this string means. However, if [18:20:18] <Dark_Shikari> next time someone suggests removing an entry and just adjust the [18:20:18] <Dark_Shikari> documented API instead of bumping major I will seriously consider [18:20:18] <Dark_Shikari> eating them alive - you have been warned. [18:28:39] <peloverde> I hate hate hate CSS [18:29:32] <BBB> omg one moment he does AAC and then he complains about css [18:29:42] <BBB> something is seriously wrong there [18:29:48] <BBB> peloverde: will you go to ovc? [18:29:49] <peloverde> I'm trying to do a blog post and their are diagrams [18:29:53] <j0sh> css == cascading style sheets? [18:29:55] <peloverde> Yes I'm going to OVC [18:29:57] <BBB> you have a blog? [18:30:00] <peloverde> yes j0sh [18:30:09] <peloverde> Yes I have a newish blog [18:30:47] <j0sh> i don't think anyone likes css. its not intuitive at all [18:30:53] <BBB> omg yuvi was a x264 soc student [18:30:59] <BBB> this is so funny [18:31:03] <BBB> peloverde: where's your blog? [18:31:07] <Dark_Shikari> BBB: welcome to last year [18:31:18] <BBB> I never pay attention :-p [18:31:24] <peloverde> http://spectralhole.blogspot.com [18:32:24] <BBB> http://blog.case.edu/ajc30/free_software/index.html is no longer used? [18:32:25] <peloverde> Yuvi being x264 soc is part of the Reddit x264-vp8 conspiracy [18:32:31] <Dark_Shikari> obviously [18:32:57] <peloverde> yeah, that blog was from when I was is school quite a few years back now [18:59:32] <elenril> peloverde: mid/side is still broken? [19:01:24] <peloverde> yes [19:02:23] <elenril> :( [19:09:45] <Dark_Shikari> http://www.youtube.com/watch?v=XduXCp91_IA [19:32:13] <astrange> 13:04 <@Dark_Shikari> ffmpeg is dropping the first frame when decoding my h264 files <- does -vsync 0 fix it? [19:33:07] <Dark_Shikari> didn't try it. [19:33:10] <Dark_Shikari> probably does. [19:33:17] <Dark_Shikari> oh btw, what happens if you combine may_alias and restrict? [19:34:42] <Dark_Shikari> I have an annoying problem in the x264 bitstream writer where the M32( output pointer ) = bswap( current data ); can potentially have output pointer alias anything [19:34:45] <Dark_Shikari> even the bitstream struct itself [19:34:51] <Dark_Shikari> and thus the compiler is forced to reload everything [19:35:14] <astrange> never tried it [19:35:22] <Dark_Shikari> i.e. which wins, restrict or may_alias [19:38:41] <Dark_Shikari> also, what happens in C if [19:38:43] <Dark_Shikari> I do [19:38:46] <Dark_Shikari> int diff = a - b; [19:38:49] <Dark_Shikari> where a is a uint8_t* [19:38:51] <Dark_Shikari> and b is a uint32_t*? [19:38:56] <Dark_Shikari> is diff measured in uint32_t or uint8_t? [19:39:34] <merbanan> an [19:40:02] <Dark_Shikari> ? [19:41:12] <Dark_Shikari> ah. compile error. [19:41:45] <Vitor1001> Dark_Shikari: This is just plain unreadable, no mater what the compiler do. [19:42:01] <Vitor1001> Dark_Shikari: One should not write code for people who have memorized the full C spec [19:42:06] <Dark_Shikari> Vitor1001: er... I didn't mean that [19:42:14] <Dark_Shikari> I just wondered what would happen if you subtracted two pointers of different sizes [19:42:26] <Vitor1001> Ah, ok [19:43:33] <Dark_Shikari> By C aliasing rules, can uint32_t *a alias int b; ? [19:45:47] <Dark_Shikari> e.g. do unsigned ints alias signed ints [19:47:54] <mt> stddev: 4251.63 PSNR: 23.76 bytes: 17973248/ 17977344 --- That's very far from being bit-exact isn't it ? [19:51:02] <merbanan> mt: yes [19:51:36] <merbanan> mt: you should get above 70 in psnr [19:52:09] <Vitor1001> mt: If it is float based, look for stddev < 1.0 [19:52:09] <mt> hmm .. guess I shouldn't have relied on plots only :( [19:52:59] <mt> it's fixed vs float [19:53:00] <Vitor1001> mt: Be careful that some codecs insert random silence in the begining of the output [19:53:32] <Vitor1001> mt: I plotted it is close, you should definitely get stddev < 1000 [19:53:59] <Vitor1001> a difference of 4000 will be visible no mater how you measure it [19:54:58] <mt> Vitor1001: Yeah there were visible differences .. I just thought that it's alright since it all lied in the order of 1e-3 [19:55:19] <Dark_Shikari> not even the same number of bytes [19:55:20] <Vitor1001> mt: Still not compatible with stddev 4251 [19:55:42] <Vitor1001> mt: For ex: [19:55:51] <Vitor1001> tests/tiny_psnr ffplay ffmpeg [19:55:57] <Vitor1001> stddev:22611.53 PSNR: 17.24 MAXDIFF:65530 bytes: 6570632/ 6542152 [19:56:22] <Vitor1001> Ok, 22 > 4, but gives an ide [19:56:26] <Vitor1001> s/ide/idea/ [19:59:40] <merbanan> fate is broken on some platforms [20:00:58] <Vitor1001> merbanan: fate is broken in all platforms that ran in less than 3 hours ago [20:01:02] <Vitor1001> merbanan: no idea why [20:05:50] <BBB> merbanan: some of those are gcc bugs [20:05:57] <BBB> (according to mru, I asked him yesterday) [20:15:30] <CIA-92> ffmpeg: siretart * r24576 /branches/ (19 files in 2 dirs): [20:15:30] <CIA-92> ffmpeg: Backport AAC-HE v2 from trunk [20:15:30] <CIA-92> ffmpeg: This patch has seen testing for a couple of weeks in ubuntu maverick and debian/experimental w/o negative feedback so far. [20:19:31] <siretart> btw, debconf video team is going to provide footage in both theora and webm/vp8 [20:19:49] <kierank> :/ [20:19:54] <Dark_Shikari> WHAT ARE YOU DOING GCC. [20:19:58] <Dark_Shikari> WHAAAAAAT. [20:19:59] <Dark_Shikari> 483725: 8b 8c 24 80 00 00 00 mov ecx,[esp+0x80] [20:19:59] <Dark_Shikari> 48372c: 8b 81 c8 04 00 00 mov eax,[ecx+0x4c8] [20:19:59] <Dark_Shikari> 483732: 89 d9 mov ecx,ebx [20:20:00] <Dark_Shikari> 483734: 8b 9c 24 80 00 00 00 mov ebx,[esp+0x80] [20:20:33] <roxfan> lol [20:21:14] <roxfan> is is 'optimized'? [20:21:17] <roxfan> *this [20:21:26] <siretart> kierank: ? [20:21:33] <kierank> theora and webm [20:21:36] <kierank> why both? [20:21:45] <thresh> yeah, screw both [20:24:21] <Honoome> rather... can we declare Ogg dead? [20:25:45] <Dark_Shikari> no, there's a vp8 mapping for ogg too [20:25:55] <Dark_Shikari> and when we get working on that next-gen obmc codec [20:26:01] <Dark_Shikari> xiph will insist on putting it in ogg [20:26:22] <kierank> oh god [20:26:31] <Honoome> Dark_Shikari: what's the _point_ of ogg? [20:26:41] <kierank> xiph nih of course [20:26:46] <Honoome> kierank: beside that [20:27:07] <siretart> Honoome: it will take some time to get vp8/webm distributed and deployed. but I guess in one or two years, we might be able to ditch theora and provide vp8 only [20:27:30] <kierank> because theora is so well deployed? [20:27:43] <Honoome> siretart: I'm quite sure that it'll be quite more easily deployed in a few months than theora has ever been [20:27:44] <Dark_Shikari> lol [20:27:58] <siretart> I mean in stable linux distros [20:28:04] <Honoome> siretart: that as well [20:28:04] <Dark_Shikari> and guess what [20:28:08] <Dark_Shikari> it still won't play on your ipad =p [20:28:31] <siretart> true [20:28:36] <Honoome> especially given that it's going to be _actually used_ by video services, given they have at least a basic userbase available [20:28:38] <kierank> stable is basically a synonym for ancient in the linux packaging world [20:28:46] <Honoome> kierank: talk for debian [20:28:50] <kierank> </troll> [20:29:29] <Dark_Shikari> kierank: not quite [20:29:32] <Dark_Shikari> depends on the distro [20:29:42] <Dark_Shikari> for gentoo, it means "we didn't fuck with it today" [20:31:15] <Honoome> hey with rare exceptions (*cough* python *cough*) our stable system is decent [20:37:57] <BBB> roundup is dead [20:37:59] <BBB> lu_zero: help! [20:38:20] <Dark_Shikari> fate is red too [20:41:56] <Honoome> BBB: do you want me to track Luca down? [20:49:52] <BBB> Honoome: yes [20:50:46] <Honoome> gha he's probably sleeping ... his schedules are a bit off [20:50:54] <Honoome> so he'll probably be around in the next three hours [20:54:36] <BBB> Dark_Shikari: "Unknown option "--enable-avfilter-lavf". [20:54:37] <BBB> See /home/fate/source/configure --help for available options." [20:54:37] <BBB> well... [20:54:57] <Dark_Shikari> lol [20:55:35] <Honoome> I saw a bug related to that in gentoo bugzilla as well [21:22:42] <_skal_paris_> yo le baptiste [21:38:31] <bcoudurier> hey _skal_paris_ [21:38:41] <bcoudurier> il fait beau au pays ? [21:56:20] <BBB> bcoudurier: will you come to ovc? [22:01:24] <bcoudurier> yes I think [22:08:22] <BBB> cool! [22:12:41] <Compn> libmpdemux/demux_real.c:571:12: internal compiler error: Segmentation fault [22:12:47] <Compn> ehe, poor guy on mplayer-cygwin [22:14:13] <kierank> it's a compiler defence mechanism from real [23:08:33] <kierank> lol michael [23:09:08] <iive> ? [23:09:25] <kierank> what is farrow interpolation? [23:09:26] <kierank> this text in that link is pretty much crap. I can explain what fir is in 2 [23:09:26] <kierank> lines they drag it out over pages and diagrams that only make sense to someone [23:09:26] <kierank> who knows already what the things are besides that the informations is [23:09:26] <kierank> obviously incomplete. [23:10:19] <iive> hehe. [23:18:49] <CIA-92> ffmpeg: stefano * r24577 /trunk/ (doc/ffprobe-doc.texi ffprobe.c Changelog): Implement ffprobe -show_packets. [23:51:36] <BBB> wbs: ping

1 0

IRC log for 2010-07-27
by irc＠mansr.com 28 Jul '10

28 Jul '10

[07:10:39] * Terminating due to: TERM [07:10:52] * /join #ffmpeg-devel ... [07:10:55] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged. [07:10:55] *** TOPICINFO: peloverde!~alex(a)cpe-173-88-148-20.neo.res.rr.com, 1276886498 [07:19:28] <CIA-92> ffmpeg: stefang * r24533 /trunk/ (9 files in 4 dirs): add Chinese AVS encoding via external library libxavs [07:28:37] <kshishkov> hmm, somebody should convince DS to augment x264 with AVS, VP8 and RV3/4 and whatever H.264 ripoff we encounter in the future [07:29:53] <av500> binkHD? [07:30:01] <Dark_Shikari> I'd add VP8 support for, hmm [07:30:05] <Dark_Shikari> $200k? [07:30:22] <mru> that's cheap [07:30:34] <mru> google paid $100M for a much worse encoder [07:30:49] <kshishkov> av500: write to Jeff from RAD, he may also entertain that idea [07:30:51] <Dark_Shikari> I'd take $1m too [07:30:56] <saintdev> mru: lol [07:31:10] <mru> saintdev: well, they did! [07:31:26] <kshishkov> mru: they got some other codecs as a bonus [07:31:33] <saintdev> that's why it's funny [07:31:57] <saintdev> although they did get a few patents along with that. [07:33:58] <kshishkov> mru: so it's $99999999.99 for a codec [07:44:04] <merbzt1> anyone in patch apply mode ? [07:45:18] <kshishkov> unlikely [07:46:45] <CIA-92> ffmpeg: benoit * r24534 /trunk/tests: Add base64 to the svn:ignore list. [07:47:23] <mru> benoit-: thanks [07:48:05] <CIA-92> ffmpeg: benoit * r24535 /trunk/libavcore: [07:48:05] <CIA-92> ffmpeg: Fill svn:ignore list for libavcore. [07:48:05] <CIA-92> ffmpeg: Add *.d, *.ho and libavcore* to the ignore list. [07:50:25] <merbzt1> I forgot to apply the dca patches yesterday [08:04:00] <CIA-92> ffmpeg: mru * r24536 /trunk/libavformat/Makefile: libavformat needs libavcore [08:06:24] <Yuvi> libavcore is really annoying me with it adding two keys to my tab-completion of libavcodec :( [08:06:33] <mru> +1 [08:06:42] <mru> libavfilter did the same [08:07:17] <av500> +2 [08:07:50] <av500> i find the libav prefix annoying anyway [08:07:54] <av500> inside the source tree [08:08:03] <mru> what I _really_ hate in names is when a name requires several completion steps [08:08:15] <av500> typing cor+tab is ok [08:08:22] <av500> or cod+tab [08:08:26] <av500> or for+tab [08:08:32] <mru> so set up some bash completion rules [08:08:34] <mru> can't be that hard [08:08:39] <mru> and emacs of course [08:08:48] <av500> gee, how do I do that in notepad.exe? [08:09:02] <funman> no plans on ffsh? [08:09:02] <mru> notepad with tab completion? [08:09:11] <mru> funman: nope, posix shell is just fine [08:09:32] <av500> mru: it says: C:\, what do I do now? [08:09:40] <elenril> posix shell has programmable completion? [08:09:51] <mru> elenril: of course not [08:10:04] <mru> posix shell is useless interactively [08:11:48] <elenril> then ffsh is obviously needed [08:16:55] <CIA-92> ffmpeg: mstorsjo * r24537 /trunk/libavformat/rtpdec_xiph.c: [08:16:55] <CIA-92> ffmpeg: rtpdec_xiph: Drop RTP packets that come in without a prior fragment start marker. [08:16:55] <CIA-92> ffmpeg: This can avoid segfaults in some cases. [08:16:55] <CIA-92> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [08:22:16] <CIA-92> ffmpeg: mru * r24538 /trunk/libavformat/raw.c: [08:22:16] <CIA-92> ffmpeg: Remove duplicate initialiser for cavsvideo_muxer.extensions [08:22:16] <CIA-92> ffmpeg: The extensions field was initialised first to "cavs", then to "avs". [08:22:16] <CIA-92> ffmpeg: The name "cavs" is kept since this is used for the format elsewhere [08:22:16] <CIA-92> ffmpeg: and "avs" is already used for avisynth files. [09:05:34] <lu_zero> j0sh: the extradata depends on the file being packetized [09:27:36] <saintdev> peloverde: oh wow, this seems to be a LOT more sensitive than itunes or nero [09:42:23] <saintdev> huh, you would think with 2-pass nero would be able to improve the window decision :/ [09:42:46] <kshishkov> why should it? [09:43:16] <saintdev> because it could store information about the attacks for use on the second pass [09:43:42] <kshishkov> second pass is mostly for refining quantizers/codebooks in any codec [09:44:16] <merbzt1> window decision just need a 2-4 frames lookahead [09:45:33] <saintdev> less :P [09:46:11] <merbzt1> depends on the frame size o) [09:46:13] <kshishkov> my codec manages it with one frame of lookahead. Never mind its quality though [09:46:36] <saintdev> kshishkov: LAME only uses one frame lookahead [09:47:05] <saintdev> so it's in good company ;) [09:47:42] <kshishkov> lookahead is only needed for using transitional windows on frame before the one with short windows [10:07:00] <saintdev> hmm, it almost seems like nero isn't using any lookahead [10:07:50] <saintdev> it reacts to most things 1 frame behind itunes/ffaac-lame [10:09:23] <CIA-92> ffmpeg: cehoyos * r24539 /trunk/ (libavcodec/mpegaudiodec.c libavformat/mp3.c): [10:09:23] <CIA-92> ffmpeg: Show correct bitrate for VBR MP3 files. [10:09:23] <CIA-92> ffmpeg: Patch by Alexander Kojevnikov, alexander kojevnikov com [10:11:56] <CIA-92> ffmpeg: cehoyos * r24540 /trunk/libavformat/mp3.c: [10:11:56] <CIA-92> ffmpeg: Make frames unsigned. [10:11:56] <CIA-92> ffmpeg: Patch by Alexander Kojevnikov, alexander kojevnikov com [11:32:43] <merbzt1> hmm, how about we add a few sec holes in the ffmpeg code crome uses and then we fix them [11:33:14] <merbzt1> for $3133.7 per bugfix [11:33:40] <cartman> merbzt1: not a bad idea [11:34:16] <mru> I'm sure we can find some already there [11:36:32] <merbzt1> http://blog.chromium.org/2010/07/celebrating-six-months-of-chromium.html [11:37:53] <merbzt1> not sure lavc stuff is included [11:38:17] <merbzt1> but if it is, it might actually be worth it looking for some bugs [11:38:31] <av500> btw, following the current trend, shouldnt we run ffmpeg in a sandbox as well? [11:38:43] <merbzt1> up to the user [11:38:53] <mru> I thought ffmpeg was just a big sandbox [11:38:57] <mru> full of bickering kids [11:39:18] <av500> true, but we can advertise said sandbox now as being more secure :) [11:39:19] <merbzt1> but imo never feed ffmpeg unknown data [11:40:09] <merbzt1> to many code paths that havn't been tested enough [11:43:52] <mru> I bet there are code paths in ffmpeg that have never been executed [11:44:31] <kshishkov> well, we are known for supporting obscure formats [11:45:00] <mru> I'd like to think every major feature has been invoked at least once [11:45:28] <mru> but rare error conditions might not ever have been triggered [11:45:30] <merbzt1> we need fate tests for everything [11:45:52] <mru> we should really test with a random-malloc-fail wrapper [11:46:39] <mru> and record the prng seed for each run so it can be reproduced [11:47:03] <kshishkov> for example, "range" field in DCA should not be read for XCh. lavc decoder does but so far nobody complained about bitstream decoding errors [11:47:32] <av500> what? DCA is wrong? I want my money back!!! [11:47:40] <merbzt1> kshishkov: ? [11:47:52] * kshishkov hands av500 a scan of 5rp coin [11:47:54] <mru> av500: you didn't pay for XCh, you paid for a neon qmf filter [11:48:34] <mru> speaking of testing, has everybody seen the new fate? [11:48:40] <mru> http://fate.mansr.com/ [11:49:16] <kshishkov> merbzt1: in subframe header parsing function s->dynrange_coef should not be read when base_channel!=0 but no such situation occured so far [11:50:08] <kshishkov> hmm, what about old x86 ? It's still in active undead state [11:50:34] <mru> you want tests for x86_32? [11:50:38] <mru> that can be arranged [11:50:42] <Vitor1001> mru: I'm thinking about increasing FUZZ to 2 for ra288 and vorbis-18 [11:50:52] <mru> vorbis-18 was approved [11:50:54] <av500> mru: it misses a longsoon entry [11:51:06] <mru> Vitor1001: feel free to do it [11:51:10] <kshishkov> mru: I'd like x86_<=32 dead [11:51:26] <wbs> can that be arranged, too? [11:51:34] <mru> with a shovel, I bet [11:51:47] <Compn> the new fate without ... mingw :P [11:51:49] * kshishkov can donate "Gdium" brand of shovel [11:52:03] <mru> I'll add more machines [11:52:11] <merbzt1> mru: can you add a warning count ? [11:52:20] <mru> merbzt1: compiler warnings? [11:52:28] <merbzt1> from the compile log [11:52:30] <merbzt1> yes [11:52:41] <mru> as from grep -ci warning? [11:52:51] <merbzt1> guess that would work yes [11:53:04] <mru> I can add almost anything [11:53:19] <mru> I wanted to get something up and running quickly [11:53:56] <merbzt1> it looks nice [11:54:01] <Vitor1001> mru: Now you can also shout "patch welcome" for new features ;) [11:54:04] <CIA-92> ffmpeg: vitor * r24541 /trunk/tests/fate2.mak: [11:54:04] <CIA-92> ffmpeg: Increase error tolerance for RA288 and one vorbis test. Should fix some [11:54:04] <CIA-92> ffmpeg: failures in PPC and ARM. [11:54:30] <mru> Vitor1001: true, but I don't want too many patches just yet [11:54:37] <mru> I have some ideas I'd like to implement first [11:54:52] <Vitor1001> sure [11:55:11] <Vitor1001> Anyway, I'm very happy already of being able to easily add new tests [11:55:19] <mru> Vitor1001: it's curious that ra288/pps only fails with some gcc versions [11:55:38] <mru> anybody want to try running some tests? [11:55:53] <Vitor1001> mru: Yes, that should be something about the order operations are done. [11:55:57] <mru> I should probably document how it's done [11:56:09] <Vitor1001> What kind of tests? [11:56:26] <mru> I meant fate2 runs [11:56:36] <mru> all you need is in the ffmpeg repo [11:57:38] <Vitor1001> Well, obviously everything passes here... [11:58:01] <mru> do you have any interesting hw/os? [11:58:08] <Vitor1001> AMD [11:58:36] <Vitor1001> AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ [11:58:39] <CIA-92> ffmpeg: mru * r24542 /trunk/tests/fate.sh: fate: clean up also after failed runs [11:58:41] <Vitor1001> Besides my core2 [11:58:42] <av500> mru: I have that even crappier longsoon if you need it :) [11:59:04] <mru> Vitor1001: I think my i7 covers intel/linux [11:59:24] <kshishkov> av500: it's unlikely to be crappier but motherboard may [11:59:38] <Vitor1001> Yes, there is no code specific to AMD boxes that supports SSE [11:59:40] <mru> av500: the one with the incompatible chipset? [12:00:05] <merbzt1> mru: can you do 32bit builds on the core i7 also ? [12:00:09] <mru> merbzt1: sure [12:00:42] <Vitor1001> mru: BTW, I also tried valgrind and it works fine, besides a leak in atrac3 I had to fix. [12:01:02] <merbzt1> Vitor1001: tnx for that [12:01:05] <mru> who runs the valgrind fate currently? [12:01:16] <av500> mru: the old elonex one [12:01:29] <Vitor1001> Michael Kostylev [12:02:10] <av500> mru: http://www.theregister.co.uk/2008/05/23/china_cheap_eee_clone/ [12:02:11] <Vitor1001> merbzt1: No problem, it was pretty easy to fix :) [12:03:19] <KotH> av500: rotfl.. 128mb ram... 1gb flash... my pc i bought 11y ago had more [12:07:16] <Compn> 128mb ? that ought to be enough for anybody! ;p [12:07:18] <Vitor1001> kshishkov: Can you have a look at issue2089? It blocks me from fate-testing musepack... [12:07:33] <Compn> thats what adobe needs, a dedicated dsp for flash [12:08:41] <twnqx> KotH: my first pc had 100MB hdd, 4MB ram and 1MB vga! [12:08:54] <twnqx> and 40mhz, no fpu! [12:09:19] <mru> fpu? flash processing unit? [12:09:47] <mru> my first pc has 12MHz 286, 640k ram, 40M disk [12:09:58] <mru> vga [12:10:08] <Vitor1001> mru: fate2 pass in my AMD compiling with "--disable-sse" to force it to use 3dnow [12:10:27] <mru> it could run wolfenstein 3d much to the annoyance of a classmate who had a 386 with ega graphics [12:12:43] <kshishkov> Vitor1001: ok, I'll try [12:12:59] <Vitor1001> kshishkov: thx [12:14:30] <twnqx> lol mru :) [12:14:34] <twnqx> my first was a 386/40 [12:14:50] <twnqx> and no 387! [12:15:09] <twnqx> (also, no weitek 3167 or whatever it was) [12:15:16] <kshishkov> my family could afford computer only when i586 appeared [12:15:18] <mru> oh, and borland c 2.0 [12:15:36] <kshishkov> mru: I think it was called Turbo C 2.0 then [12:15:46] <mru> maybe [12:15:57] <mru> it said borland all over it too [12:19:46] <KotH> boys, you're getting old [12:20:44] <kshishkov> KotH: sometimes I feel extremely old [12:21:24] <microchip_> kshishkov: use your anti-aging hypo spray :P [12:24:59] <kshishkov> microchip_: never heard of it [12:25:11] <kshishkov> leave it for Stallman anyway [12:25:12] <microchip_> kshishkov: that's why you're old :P [12:25:50] <KotH> microchip_: do you mean rohypnol? [12:27:40] <microchip_> KotH: no, that's a date-rape drug, used by spaam ;) [12:28:06] <spaam> no [12:28:11] <spaam> microchip_: dont lie [12:28:37] <microchip_> spaam: we know your secrets :p [12:29:01] <spaam> no [12:43:40] <kshishkov> Vitor1001: for now it looks like bitstream reading overrun, I'll try to figure it out at home if I have free time [12:45:37] <Vitor1001> Ok. If you also find a sample for both codecs that don't overrun (ie, properly cropped) and small (less than 1mb of decoded raw pcm), it would also do the trick [12:48:18] <kshishkov> MPC8 can be cut easily since it has internal structure - frames and such, MPC7 don't even align frames to byte boundary [12:51:31] <Vitor1001> kshishkov: -acodec copy would work? [12:52:40] <Vitor1001> kshishkov: nevermind, we don't have a mpc muxer. [12:53:36] <kshishkov> actually my demuxer has to pad frames to make it work [12:54:36] <kshishkov> whoever designed MPC SV1-7 was too concerned with saving bits [12:55:04] * KotH would rather try to save kittens [12:55:09] <Honoome> kshishkov: do you know the flac header, yeah? [12:56:19] <Vitor1001> kshishkov: Wait, it doesn't overread just the last frame but every single one. Maybe the padding isn't big enough? [12:57:54] <kshishkov> Honoome: MPC7 also has all frames as P-frames [12:58:15] <Honoome> kshishkov: a 21-bit field on a flamin' lossless format! [12:58:16] <kshishkov> Vitor1001: could be, I'll check [13:11:54] <CIA-92> ffmpeg: stefano * r24543 /trunk/ (6 files in 2 dirs): Add the indevs.texi and outdevs.texi files. [14:11:15] <peloverde> saintdev: 1 frame of look ahead should be sufficient [14:14:20] <CIA-92> ffmpeg: alexc * r24544 /trunk/libavformat/avformat.h: Document existing rules for AVInputFormat.name. [14:21:28] <peloverde> :) [14:33:56] <lu_zero> hi jrmuizel [14:33:56] <jrmuizel> lu_zero: hey [14:34:43] <lu_zero> I was wondering if would be acceptable a patch for firefox to use libavcodec to cover webm [14:34:55] <lu_zero> (and libavformat) [14:35:36] <mru> lu_zero: acceptable to whom? [14:35:48] <CIA-92> ffmpeg: stefano * r24545 /trunk/libavformat/allformats.c: [14:35:49] <CIA-92> ffmpeg: Place the concat protocol entry at the begin of the registered [14:35:49] <CIA-92> ffmpeg: protocol list, restore alphabetical order. [14:36:26] <jrmuizel> lu_zero: unfortunately lgpl isn't compatible with our licensing terms [14:37:03] <lu_zero> ah [14:37:41] <lu_zero> how you managed to use gtk+ then? [14:37:54] <lu_zero> exception clause from them? [14:38:00] <jrmuizel> we don't distribute gtk [14:39:56] <jrmuizel> there's been noises about changing our policies to allow shipping things that aren't compatible with the tri-license but nothing concrete thus far [14:39:57] <lu_zero> so the problem is just with distribution [14:40:08] <jrmuizel> yep [14:40:27] <jrmuizel> afaik anyways, I'm not a lawyer [14:40:33] <lu_zero> so as compile time option it would survive [14:40:45] <lu_zero> but you won't enable it on the official builds [14:41:05] <BBB> jrmuizel: mozilla? [14:41:11] <jrmuizel> BBB: yes [14:41:42] <lu_zero> mru: do we have benchmarks regarding png and jpeg on arm? [14:42:17] <jrmuizel> lu_zero: well I don't think it could really be put into our source tree, but certainly it would be possible to link against a system libavcodec [14:42:29] <av500> lu_zero: >10mpixel/s here [14:42:45] <av500> but its on the dsp :) [14:42:47] <mru> is that the new unit of decoder speed? [14:42:59] <av500> its the one we use for jpef [14:43:00] <av500> its the one we use for jpeg [14:43:46] <BBB> jrmuizel: I'm not entirely sure that's true, let me confirm that with some people [14:44:07] <jrmuizel> lu_zero: at the same time there would be resistance to the maintenance burden of supporting something that we didn't actually distritbute [14:44:25] <jrmuizel> BBB: confirm what? [14:44:27] <lu_zero> so it's an uphill route at best [14:44:34] <jrmuizel> lu_zero: indeed [14:45:17] <BBB> jrmuizel: that lgpl is incompatible with mpl if distributed together [14:45:41] <BBB> I think that's only true if they're part of the same entity (not binary), e.g. in the same dll or in the same object file or source file [14:45:51] <jrmuizel> it's sort of an unfortunate position that we're in and sort of ironic that Opera could more easily link against libavcodec then we could [14:46:15] <BBB> as long as they are separated on some level, afaik it is ok, so I'm asking sflc for advice ;) [14:46:39] <lu_zero> mru: if ffjpeg and ffpng are faster I'll consider replacing the stand-alone libraries with those [14:46:59] <mru> jpeg is probably faster [14:46:59] <jrmuizel> BBB: the issue isn't with license incompatibly it is with the policy that everything that we ship be tri-licensed [14:47:01] <Honoome> lu_zero: will you make API-compatible interfaces for those? :P [14:47:02] <mru> no idea about png [14:47:17] <lu_zero> Honoome: only if somebody pays me for that separately [14:47:34] <BBB> jrmuizel: that is a rather limiting policy that you might want to reconsider - especially if you want to make use of the true spirit of free software: sharing [14:47:48] <lu_zero> then would be quite interesting having an use ffmpeg in jpeg and libpng in gentoo [14:47:49] <BBB> nothing is tri-licensed, so essentially you're excluding everything from being shared (if it originated somewhere else) [14:47:57] <mru> BBB: that idea was lost a long time ago [14:48:19] <Honoome> lu_zero: we recently got a virtual/jpeg [14:48:25] <jrmuizel> BBB: cairo is tri-licensed :) [14:48:47] <mru> ffmpeg is too: lgpl2, gpl2, gpl3 [14:48:54] <jrmuizel> and we can share code with less restrictively licensed projects [14:49:08] <BBB> nih syndrome :( [14:49:17] <BBB> ohwell [14:49:20] <BBB> nevermind then [14:49:44] <BBB> I guess this kind of attitude is what keeps gnu/hurd alive :) [14:49:46] <jrmuizel> BBB: I agree that it sucks, but there's not really an easy way out that satisfies everyone [14:51:22] <lu_zero> anyway if we can get to avoid that restriction would be quite fun having a way to get a hopefully faster firefox ^^ [14:51:50] <jrmuizel> lu_zero: indeed [14:52:17] <BBB> I suppose mozilla could always link against a system ffmpeg; some distributions would have that [14:52:38] * lu_zero meanwhile tries to build firefox using gcc 4.5.0 [14:52:53] <jrmuizel> BBB: yeah, but I'm not sure that's worth the maintenance burden [14:52:56] <spaam> dont firefox use libavcodec for theora and ogg vorbis ? those are lgpl ? [14:53:11] <BBB> jrmuizel: I guess I have to agree there ;) ifdef spaghetti isn't quite worth it [14:53:41] <BBB> wbs: nice patch, I'll do a deep review later today or tomorrow but I like the looks of it [14:53:42] <jrmuizel> spaam: no we use the xiph implementations of theora and vorbis [14:53:49] <BBB> wbs: especially if 'a' and 'v' work in ffplay [14:53:50] <KotH> spaam: nope. ff devels wont toucn ffmpeg with a 10m pole [14:54:06] <spaam> jrmuizel: ok [14:54:53] <KotH> spaam: at fosdem one said, that they are not going to consider using any project that has been tainted by h.264 [14:55:03] <av500> lol [14:55:07] <av500> so, no vp8... [14:55:33] <jrmuizel> KotH: that doesn't make much sense [14:55:38] <spaam> KotH: ok = [14:55:42] <KotH> jrmuizel: no, it does not... [14:55:46] <jrmuizel> what does "tainted by h.264" even mean? [14:56:24] <KotH> jrmuizel: dunno.. dropped out after that comment... didn't want to join in a rl flamewar if it wasn with jörg schilling [14:57:06] <av500> so, if we gat Dark_Shikari to commit an improvement to libvpx, it will be unusable? [14:57:07] <BBB> KotH: that doesn't sound quite right, probably not a dev, esp. not given what I've heard about mozilla's desires for a h264-quality-like codec [14:57:19] <jrmuizel> afaik the only reason for not using ffmpeg is because of the licensing problems discussed above [14:57:48] <jrmuizel> KotH: do you know who it was that said that? [14:58:49] <KotH> jrmuizel: no idea... i joined a discussion between mru, dondiego and someone from ff... and after i heard above comment, i didnt think it was good use of my time to stay there [14:59:52] <KotH> jrmuizel: and i dont consider it the official position of ff... it would be too much RMS like [15:00:15] <mru> or chris blizzard... [15:00:19] <mru> he could say such a thing [15:00:27] <KotH> jrmuizel: it's just an example of how weird and uninforment opinions are circulating in the area of video coding [15:00:36] <mru> he drank the koolaid, then ate the bottle it seems [15:01:06] <jrmuizel> KotH: indeed [15:01:08] <lu_zero> mru: you mean the crate [15:01:38] <KotH> .o0(damn, i need a typo fixer... or someone who proof reads my english in irc) [15:02:41] <elenril> you need an encoding fixer =p [15:03:28] <KotH> näi, bruchts nöd [15:04:36] <elenril> â! [15:20:54] <CIA-92> ffmpeg: michael * r24546 /trunk/libavformat/avformat.h: Make doxygen formatting more consistent. [15:22:17] <CIA-92> ffmpeg: michael * r24547 /trunk/libavformat/avformat.h: Fix 2 doxy comments that referred to the wrong variable. [15:26:44] <wbs> BBB: thanks :-) yeah, the 'a' and 'v' keys in ffplay do work [15:28:59] <CIA-92> ffmpeg: mstorsjo * r24548 /trunk/doc/general.texi: Fix the lavf docs, we have a RTP muxer, not a demuxer [15:55:19] <CIA-92> ffmpeg: michael * r24549 /trunk/ (6 files in 2 dirs): Fix doxy that refers to the wrong variable. [17:00:34] <CIA-92> ffmpeg: mru * r24550 /trunk/configure: [17:00:34] <CIA-92> ffmpeg: configure: fix sh_quote function [17:00:34] <CIA-92> ffmpeg: Non-matching lists start with ! instead of the usual ^ in shell [17:00:34] <CIA-92> ffmpeg: patterns. [17:11:36] <stefang_> hi [17:12:03] <CIA-92> ffmpeg: reimar * r24551 /trunk/libavcodec/gsmdec.c: Document how the ref_buf is used. [17:12:12] <kshishkov> gruess dich [17:35:12] <saintdev> peloverde: so if we are going to use lame's window decision instead of 3gpp. how should initialization be handled [17:38:25] <peloverde> It seems to use a similar mechanic to 3gpp windowing, There was initialization for that one assert, which probably could be better avoided by using ">=", what else needs to be initialized? [17:39:42] <saintdev> attack threshold, but that can probably be made static (iirc lame varies it depending on the requested quality) [17:40:29] <peloverde> If it's not a complicated calculation it can be chosen each frame, 3GPP does it based on bitrate [17:40:59] <saintdev> peloverde: it's selected from a table [17:41:16] <peloverde> Then looking it up every frame should be fine [17:41:29] <funman> 'window decision' is only about window length, right? [17:42:31] <funman> i've seen there are some different windowing functions but Hann seems to be overwhelmingly used [17:48:03] <saintdev> peloverde: double checked, it is selected depending on the requested quality, however for the default psymodel it is always 4.2 for L,R,M and 25 for S [17:48:13] <saintdev> not sure about the ABR psymodel, let me look [17:48:41] <peloverde> For now just worry about L,R,M [17:48:58] <saintdev> ABR varies depending on requested bitrate [17:52:21] <saintdev> huh, bitrate thresholds are much higher than quality thresholds [18:03:59] <peloverde> ratios probably also depend on the weight and size of the moving average [18:08:47] <peloverde> I know window decision is something LAME paid a lot of attention to [18:08:58] <peloverde> I would trust their judgement [18:09:43] <peloverde> At least for medium and high/bitrates qualities [18:13:19] <_av500_> gee, mru is unstable today.. [18:13:48] <peloverde> saintdev: I'll be back in a few, time for more sc2 [18:14:10] <saintdev> they got you also! [18:15:30] <funman> the zergs got everyone :o [18:56:12] <CIA-92> ffmpeg: mru * r24552 /trunk/configure: Detect PathScale compiler [19:12:17] * elenril wonders why he read that as DeathScale [19:34:11] <BBB> jrmuizel: I just asked my lawyer, and he tells me there is no problem linking lgpl to mpl, so the only problem that might exist is that you would ship non-mpl code, which is really only policy, not a licensing violation per se [19:35:03] <_av500_> ffireffox fftw! [19:36:43] <mru> mozilla and xiph love inventing stupid policies for the sole puprose of having something to stick to [19:46:21] <kierank> vlc should make a browser [19:50:16] <BBB> fedora would refuse to ship it [19:50:17] <BBB> o [19:50:21] <BBB> or worse, cripple it [19:50:36] <mru> make it only display gifs [19:50:47] <BBB> right, because jpegs use blocks, and so do mpegs [19:50:49] <BBB> and they sound alike [19:50:54] <BBB> only one letter difference [19:50:59] <kierank> lol [19:51:00] <BBB> must be patented!!! :-o [19:51:40] <mru> but gifses are also patented [19:51:42] <BBB> besides, did you know ffmpeg uses the same api for their mpeg and jpeg decoder? so even if they're not patented, then surely ffmpeg violates patents [19:52:21] <mru> that's not far from the fsf "derived work" logic... [19:52:34] <kierank> ffmpeg has the words h264 in it's vp8 decoder so it's patented!!!!111ONE [19:54:08] <BBB> hehe, that's actually true [19:54:37] <BBB> Dark_Shikari: seriously, intra_pred isn't very h264 specific, should we rename it to something more generic (similar to motion_est.c; intra_pred.c)? [19:54:47] <BBB> Dark_Shikari: plus structures in it etc. [19:55:05] <mru> it is h264 [19:55:21] <mru> it's the prediction scheme defined by h264 [19:55:27] <mru> others have borrowed it [19:55:44] <saintdev> h264_omg_patents_intra.c [19:55:57] <_av500_> look at bink, it reuses the h264 idea of frames.... [19:56:19] <_av500_> its tainted [19:56:19] <mru> now you're talking like apple [19:56:21] <saintdev> wait a second, vp8 uses frames also!! [19:56:24] <_av500_> see [19:56:31] <mru> in appleworld, if they do it, they invented it [19:56:34] <saintdev> omg vp8 is tainted! [19:56:40] <mru> painted? [19:56:43] <mru> the shed? [19:56:45] <mru> cannot be [19:56:52] <_av500_> i think it is shikared darkly [19:59:19] <j-b> software patents... what a joke... [20:02:56] * elenril wonders when did so many trolls come here [20:03:29] * spaam looks at mru [20:04:10] <_skal_paris_> all patainted [20:05:18] <jrmuizel> BBB: indeed [20:06:52] <jrmuizel> The idea is that someone should be able to take firefox and use it under the conditions of the MPL without having to follow the conditions of the LGPL [20:08:23] <_skal_paris_> BBB: http://pastebin.org/423037 [20:08:45] <_skal_paris_> BBB: move some fields out of proba[2], that don't need to be copied [20:09:01] <BBB> jrmuizel: I understand that, but seriously, this is easily prevented by haing an ext/ directory with "stuff that we didn't write" [20:09:22] <BBB> or a separate dependencies repo that is only included in the binary builds, but not officially part of the source tarball [20:09:37] <BBB> jrmuizel: anyway, that's all policy, I won't interfere, I'm just making the point that it's a little odd ;) [20:10:09] <jrmuizel> BBB: right but what if I'm IBM and I want to link firefox into a proprietary product and don't want to abide by the conditions of the LGPL [20:10:46] <jrmuizel> if firefox now depends on something that is LGPL I'm out of luck [20:11:18] <BBB> jrmuizel: don't use the deps [20:11:33] <BBB> jrmuizel: and make sure the product is functional (although crippled) without it [20:11:49] <BBB> jrmuizel: just like gstreamer or vlc is functional (although crippled) without ffmpeg [20:12:17] <jrmuizel> right but the goal is to have something for others to use that's not crippled [20:12:35] <BBB> _skal_paris_: looks good to me, ask david (yuvi) also before you commit please [20:13:02] <BBB> _skal_paris_: and the other ons is probably ok also, but also there, ask yuvi before applying (or wait three days and apply if he doesn't object) [20:13:19] <Yuvi> the quant one is okay [20:13:23] <Yuvi> what was the other one? [20:13:44] <BBB> jrmuizel: it does that anyway - gtk is lgpl (and the system lib exception is part of gpl, not lgpl, so lgpl would still apply to gtk) [20:13:55] <_skal_paris_> yuvi : http://pastebin.org/423037 [20:16:13] <Yuvi> okay, don't mind too much where those are [20:16:53] <_skal_paris_> yuvi: yeah, that's minor [20:17:48] <jrmuizel> BBB: right, but we don't distribute gtk, and gtk certainly isn't the only the platform we support [20:17:49] <BBB> if it saves a cycle.. [20:18:54] <jrmuizel> BBB: I'm not saying the policy is great, just trying to give some rationale [20:19:52] <jrmuizel> policies are hard to change in community projects [20:20:33] <jrmuizel> people love to bikeshed and complain [20:20:37] <BBB> jrmuizel: linkage still makes you lgpl in this case, because you distribute a program that links to ... (see section 6b) [20:20:46] <BBB> or well, not you [20:20:56] <BBB> but it means the full program, although not lgpl itself, should not violate the lgpl [20:21:18] <BBB> http://www.gnu.org/licenses/lgpl-2.1.txt section 6b [20:21:21] <BBB> that's how I read it at least [20:22:48] <jrmuizel> sure and I don't think the policy wouldn't prevent against linking against a system libavcodec either [20:27:16] * Terminating due to: TERM [20:27:35] * /join #ffmpeg-devel ... [20:27:36] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged. [20:27:36] *** TOPICINFO: peloverde!~alex(a)cpe-173-88-148-20.neo.res.rr.com, 1276886498 [20:31:14] <BBB> jrmuizel: but I don't understand (tell me if I bikeshed too long and I'll stop); if you link against a system lgpl gtk, then regardless of what you ship in your mpl mozilla, _it may not violate the lgpl_, that's what section 6b says. so regardless of how you look at it, ibm cannot use mozilla only under the mpl, it must still abide by the lgpl for those parts that firefox links to, system or not... knowing that, what is the difference (other tha [20:31:15] <BBB> did it") between linking to system libraries and linking to self-distributed lgpl binaries? [20:31:18] <BBB> I probably bikeshed too long about this ;) let's get back to work [20:31:54] <jrmuizel> BBB: that sounds correct to me [20:33:02] <jrmuizel> but like I said there are widget backends other than gtk [20:33:58] <jrmuizel> personally I'd rather the policy were different, but it's not easy for me to change it :) [21:04:43] <_av500_> c++ is really the root of all evil: http://www.numerama.com/magazine/16319-pour-arreter-le-terrorisme-interdiso… [21:13:11] <CIA-92> ffmpeg: aurel * r24553 /trunk/libavcodec/dvdsubdec.c: remove useless cast [21:13:38] <_skal_paris_> back [21:13:54] <_skal_paris_> yuvi: ok, so good to go for both patches [21:13:55] <_skal_paris_> ? [21:14:22] <Yuvi> yeah [21:15:04] <_skal_paris_> deal [21:17:10] <peloverde> The prerendered cutscenes in sc2 do not reflect well on whatever codec they use [21:20:25] <Dark_Shikari> keyframe flashing [21:45:01] <CIA-92> ffmpeg: banan * r24554 /trunk/libavcodec/dca.c: [21:45:01] <CIA-92> ffmpeg: Setup correct channel value when downmixing is required. [21:45:01] <CIA-92> ffmpeg: Patch by Nick Brereton [21:46:34] <CIA-92> ffmpeg: banan * r24555 /trunk/libavcodec/dca.c: [21:46:35] <CIA-92> ffmpeg: DCA: fix multichannel -> 2 channel downmix. [21:46:35] <CIA-92> ffmpeg: Patch by Nick Brereton [21:50:13] <mru> peloverde: http://fate.mansr.com/report.cgi?slot=mips64el-linux-gcc-4.5&time=201007272… [21:50:24] <mru> anything special about those tests? [21:52:20] <peloverde> They all seem to report maxdiff 1 [21:52:24] <peloverde> why are they failing [21:52:30] <mru> they crash halfway [21:52:35] <mru> look at the sizes [21:53:10] <peloverde> Does the readout say it crashed, I'm not used to your new and improved fate yet [21:53:33] <mru> it stopped outputting samples for some reason [21:54:02] <peloverde> yes, mikes fate used to say SIGSEGV or SIGABRT [21:54:10] <mru> the 'test' log says "error 255" [21:54:26] <peloverde> ahh [21:54:52] <mru> I need to try to capture more information about crashes and such [21:55:04] <peloverde> The tools used by those particular files are listed in http://wiki.multimedia.cx/index.php?title=AAC_Conformance_Vectors [21:55:12] <peloverde> lets see what they have in common [21:56:23] <peloverde> hmm al07 and am00 have zero overlap on common optional tools [21:57:27] <peloverde> Debug it further I'll probably need a backtrace or a valgrind report [21:57:42] <mru> no valgrind on that machine [21:59:28] <peloverde> gdb backtrace? [22:00:16] <mru> I suppose I could get one [22:00:20] <peloverde> The three mips64 configs are identical hardware? [22:00:28] <mru> same hw [22:00:53] <mru> the 4.3 one uses -march=mips3, the later ones -march=loongson2f [22:01:04] <peloverde> ahh [22:01:39] <CIA-92> ffmpeg: lu_zero * r24556 /trunk/MAINTAINERS: Add my gpg fingerprint [22:03:44] <peloverde> I don't see any warnings in aacdec.o [22:04:06] <mru> bugs don't always come with warnings [22:04:25] <mru> armcc sometimes forgets to initialise something and then warns about it [22:04:29] <mru> kinda funny [22:04:37] <saintdev> peloverde: what does it mean when the reference decoder lists two window sequence changes for a block? [22:04:58] <peloverde> That seems funny, can you pastebin the output? [22:05:48] <saintdev> i'm guessing one for each channel when L and R use different block types [22:06:09] <saintdev> peloverde: http://pastebin.org/423301 [22:06:20] <peloverde> When the program is crashing and I don't have valgrind and I don't have a backtrace, my next best option is compiler warnings [22:06:35] <saintdev> block 21,22,23 are the first ones [22:06:59] <peloverde> Is the file stereo? [22:07:09] <saintdev> yes [22:07:23] <peloverde> If so it was using a common window up until block 20 [22:07:30] <peloverde> look at the common_window flag [22:07:38] <saintdev> ok, kind of what i guessed, just hadn't seen it before [22:10:04] <saintdev> the weird one is the same file with 3gpp windowing [22:10:18] <saintdev> http://pastebin.org/423315 [22:11:09] <peloverde> I've done zero work on stereo [22:11:22] <saintdev> anyway... [22:12:09] <saintdev> well itunes and nero use entirely common window for that sample [22:12:50] <Vitor1001> Can anyone test a patch for me? [22:12:54] <Vitor1001> http://ffmpeg.pastebin.com/t0amXsjT [22:13:09] <Vitor1001> With the sample http://samples.mplayerhq.hu/fate-suite/gsm/ciao.wav [22:13:26] * Vitor1001 is trying to debug issue2133 [22:16:16] <saintdev> pre-echo, how about post-echo, LOL [22:16:22] <peloverde> mru: Another option would be adding more of the test vectors to see if we can further narrow what id failing [22:18:14] <saintdev> peloverde: http://rapidshare.com/files/409476197/castanets.aac [22:18:16] <saintdev> :/ [22:18:34] <peloverde> is mono ok? [22:18:35] <spaam> Vitor1001: what rev was that patch made for ? [22:18:58] <spaam> oh [22:19:14] <Vitor1001> spaam: r24541 [22:19:18] <kierank> stop the presses; spaam is doing something useful ;) [22:19:31] <spaam> kierank: hahaha :P [22:19:40] <Vitor1001> spaam: I will make one against latest svn [22:20:21] <Vitor1001> spaam: http://ffmpeg.pastebin.com/LW7pZFBW [22:20:29] <saintdev> should too many bits per frame _really_ be an error [22:21:13] <saintdev> yeah mono seems ok, no post-echo :P [22:22:05] <saintdev> every other encoder has problems with pre-echo, not ff-aac!! It just has problems with post-echo. [22:22:39] <CIA-92> ffmpeg: skal * r24557 /trunk/libavcodec/vp8.c: save some copies by moving some fields out of proba[2] [22:24:40] <CIA-92> ffmpeg: skal * r24558 /trunk/libavcodec/vp8.c: perform the clipping on luma_dc_qmul[1] and chroma_qmul[0] earlier [22:28:11] <saintdev> although surprisingly 3gpp windowing is more well bahaved than lame [22:29:34] <spaam> Vitor1001: http://pastie.org/private/6tcmx7zbz2gdgrstyknmg output from ffplay.. [22:30:14] <Vitor1001> spaam: ow, actually I need output from ffmpeg, something lilke "ffmpeg -i ciao.wav -f md5 -" [22:31:10] <spaam> http://pastie.org/1062955 [22:31:11] <Vitor1001> spaam: Funny, for you the bug shows up also in ffplay. I could only reproduce it in ffmpeg. [22:31:21] <Vitor1001> You are on 64 or 32 bits? [22:31:27] <spaam> 64bity [22:31:29] <spaam> -y [22:32:00] <Vitor1001> Thanks... So the bug does exist. [22:32:08] <spaam> np :) [22:32:13] <Vitor1001> wait [22:32:22] <Vitor1001> I just saw I sent you a bad patch :p [22:32:48] <spaam> haha [22:33:07] <Vitor1001> spaam: Ok, nevermind, my bad. Thanks anyway. :) [22:33:20] <kierank> good job spaam [22:33:42] <spaam> Vitor1001: i can test the real one if you like ;D [22:33:46] <spaam> kierank: thank you :D [22:34:04] <Vitor1001> spaam: No, ok, it looks like it was me that was confused :p [22:34:42] <spaam> oK :) [22:38:59] <mru> hmm, someone broke vp8 [22:39:48] * merbanan points at skal [22:39:49] <Dark_Shikari> probably _skal_ [22:39:50] <Dark_Shikari> blame _skal_ [22:40:56] <kierank> the new brutalist fate should send henchmen to punish people for breaking things [22:41:44] <_skal_paris_> yeah [22:42:06] <_skal_paris_> ok, what did i break? [22:43:03] <merbanan> http://fate.mansr.com/report.cgi?slot=x86_64-linux-gcc-4.3&time=20100727223… [22:44:31] <_skal_paris_> fixing [22:46:40] <_skal_paris_> merbanan: when fate says it's r 24558, it's exactly r24558? or anything before? [22:46:52] <mru> that's the version it tested [22:47:01] <_skal_paris_> k [22:47:17] <mru> click the time to get a history of all tested revs [22:49:02] <mru> it's showing a bunch of spurious errors right now because I accidentally filled up a disk [22:49:34] <spaam> haha [22:50:05] <_skal_paris_> can one get the exact command that was run? [22:52:13] <BBB> _skal_paris_: it seems several testsuite files failed [22:52:22] <BBB> google for vp8-test-vectors-r1 [22:52:37] <mru> or just grab the fate samples [22:52:37] <BBB> ./ffmpeg -i $file -vcodec rawvideo -f md5 -an - [22:52:44] <BBB> that would work too [22:52:45] <Dark_Shikari> _skal_: please regression test before you do another commit [22:52:49] <Dark_Shikari> revert it for now. [22:52:49] <BBB> and compare before and after your patch [22:53:01] <mru> and make fate-vp8-foo [22:53:23] <merbanan> mru: but it would be nice to see the actual command in the log [22:53:31] <mru> yes, it would [22:54:14] <_skal_paris_> Dark: yep [22:55:41] <mru> kierank: I changed the styling a bit [22:58:51] <Vitor1001> mru: What do you think of a "make fate-vp8" target to run all vp8 tests? [22:59:00] <mru> I already thought of that [22:59:12] <Vitor1001> mru: ok, cool [22:59:48] <_skal_paris_> where can i find the test-vector-* ? [23:00:18] <Vitor1001> _skal_paris_: http://samples.mplayerhq.hu/fate-suite/vp8-test-vectors-r1/ [23:00:32] <_skal_paris_> thanks! [23:00:35] <mru> and don't believe the mime type.. [23:01:10] <BBB> Vitor1001: what you had reminds me of an issue I had a week or two ago [23:01:14] <BBB> make clean; make fixed it [23:01:20] <BBB> Vitor1001: suggests a dependency problem somewhere... [23:01:27] <BBB> (rather than an actual bug) [23:01:30] <BBB> but I don't know where :( [23:02:00] <BBB> mru: if compile fails, can we get gcc output? [23:02:15] <mru> already there [23:02:20] <Vitor1001> BBB: Hmm, might be possible. But I suppose mru box runs "make clean" between fate runs... [23:02:37] <mru> it saves the console output [23:02:54] <mru> click the link in the red box [23:03:03] <_skal_paris_> can't get the same printout [23:03:15] <_skal_paris_> ./ffmpeg -i vp80-00-comprehensive-007.ivf -vcodec rawvideo -f md5 -an - [23:03:21] <_skal_paris_> gives onl one MD5 [23:03:30] <mru> -f framemd5 [23:03:39] <_skal_paris_> oh [23:03:42] <_skal_paris_> k [23:03:58] <BBB> oh it's there, got it [23:04:01] <BBB> mru: thanks [23:04:15] * BBB goes home [23:04:18] <BBB> _skal_paris_: good luck :-p [23:04:54] <_skal_paris_> BBB: i'm gonna revert & sleep [23:05:08] <_skal_paris_> (there's a svn command for that, right? :) [23:05:17] <_skal_paris_> but i would have like to understand the fate thing [23:05:20] <_skal_paris_> and repro [23:06:31] <Vitor1001> _skal_paris_: to run fate you have to download the samples [23:06:46] <Vitor1001> rsync -aL rsync://rsync.mplayerhq.hu:/samples/fate-suite/ fate/fate-suite [23:07:09] <_skal_paris_> vitor: that's why i grabbed the vp8 ones [23:07:10] <Vitor1001> Then simply run "make fate SAMPLES=/the/path/to/the/dir/fate-suite" [23:07:40] <_skal_paris_> ok, md5s are back to normal [23:07:41] <Vitor1001> This command will run all the tests (and thus need all the samples) [23:07:44] <mru> or configure --samples=/the/path [23:07:47] <_skal_paris_> rolling back [23:09:20] <_skal_paris_> done [23:09:22] <_skal_paris_> sorry about that [23:09:30] <mru> thanks for the speedy fix [23:09:50] <mru> fate should verify within a few minutes [23:09:55] <_skal_paris_> now i've got some md5 to look at and figure out my borkinationage [23:10:07] <CIA-92> ffmpeg: skal * r24559 /trunk/libavcodec/vp8.c: b0rk3d FATE + black helicopters hissing -> rolling back to r24556 and sleeping [23:10:37] <_skal_paris_> well, yeah, maybe tomorrow hey [23:12:43] * _skal_paris_ waiting a bit for FATE to recall the black helipcopters though [23:12:54] <mru> first green result in [23:13:28] <mru> the x86 tests are taking about 3 minutes per compiler [23:14:24] <spaam> buy a faster cpu mru ;) [23:14:39] <mru> it's only using half of it [23:20:44] <_skal_paris_> oh, fate-suite = 387megs [23:20:46] <_skal_paris_> could be worse [23:22:15] <kierank> too big for google [23:28:01] <_skal_paris_> mru: if i leave only the vp8-* files in fate/fate-suite, will it still work? [23:28:16] <mru> it will fail all other tests [23:30:46] <_skal_paris_> ok, waiting then [23:31:54] <Vitor1001> _skal_paris_: If you have only these files, better to run "make `seq -f "fate-vp8-test-vector-%03g" 1 17` SAMPLES=/files/fate-suite" [23:31:57] <_skal_paris_> ah! that was r24558 [23:43:45] <_skal_paris_> that was a silly patch [23:46:04] <_skal_zZzz_> zZzz

1 0

IRC log for 2010-07-21
by irc＠mansr.com 22 Jul '10

22 Jul '10

[00:01:17] <BBB> feel free to help also btw [00:01:32] <BBB> since I have to ssh into someone else's computer, I'll probably be slower at this [00:02:07] <Dark_Shikari> ok [00:08:25] <Honoome> BBB: learn the pleasure of emacs for writing code remotely :D [00:08:25] <Dark_Shikari> BBB: you should be specific [00:08:27] <Dark_Shikari> "x86_64" is not a cpu [00:08:39] <BBB> oh [00:08:58] <BBB> model name : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz [00:09:33] <BBB> it's a quadcore [00:09:36] <Dark_Shikari> does it have sse4? [00:09:39] <BBB> we should abuse that and do threading [00:09:50] <BBB> yes [00:09:51] <BBB> fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm [00:10:05] <Dark_Shikari> that's a Core i7 [00:10:39] <Dark_Shikari> BBB: is this all committed now? [00:10:40] <Dark_Shikari> if not, commit it [00:10:46] <BBB> it's all committed [00:10:51] <BBB> my patchqueue is empty regarding vp8 [00:11:01] <BBB> I have a lot of uncommitted stuff, but nothing for vp8 ;) [00:11:07] <Dark_Shikari> ok, great [00:11:15] <Dark_Shikari> now you need to get Yuvi to commit his deblocking changes [00:11:19] <Dark_Shikari> and emulated edge [00:12:44] <Honoome> BBB: I could set up a container for an 8-core if you wanted to abuse threading :P [00:12:46] <BBB> I want to test how well his decode_block_coeffs changes speed it up, is that noticeable at all? [00:13:07] <BBB> Honoome: I don't know shit about video decoding and threading yet, so give me some time to get used to it :) [00:13:25] <Honoome> okay, with a bit of luck it might turn into a 12-core by that time :P [00:14:48] <BBB> first going home for dinner :) [00:16:06] <Dark_Shikari> merge ffmpeg-mt [00:16:10] <Dark_Shikari> then we will beat the crap out of vpx [01:48:49] <saintdev> peloverde: is a long_start followed by a only_long valid? [02:37:53] <saintdev> otherwise, seems to work \o/ [02:38:41] <saintdev> onto band info [02:44:24] <saintdev> peloverde: what information does band_info() need to fill out? [02:45:11] <funman> hi [03:15:50] <saintdev> peloverde: all we get for a commit message on the addition of the 350 is "optimizations on mask_add and L3psycho_anal_ns" [03:20:26] <saintdev> anybody here familiar with mp3? [03:23:31] <UKCoder> quick question... does anyone know where I can get a copy of the aac/mp4 spec without having to pay ISO? [03:34:47] <astrange> search for the standard numbers [03:34:50] <astrange> http://neuron2.net/library/mpeg2/iso13818-7.pdf [03:35:09] <astrange> that's not the most up to date one of course [03:39:16] <Compn> UKCoder : http://wiki.multimedia.cx has links to it [03:47:33] <UKCoder> thanks [03:54:04] <peloverde> long_start followed by only_log is not legal [03:54:04] <peloverde> If you look at the window shapes it's pretty clear [04:54:30] <funman> kshishkov: ping [05:02:06] <kshishkov> whut? [05:03:10] <funman> i have the rso/adpcm decoder working but there's one step i don't understand, can you shed some light? [05:03:36] * kshishkov readies flashlight [05:05:22] <funman> http://pastie.org/1053198 <- why is the shift needed? [05:06:42] <kshishkov> you know, in reality output is in U8 format, so you can indicate that and output without any shifts or subtractions [05:06:56] <funman> http://pastie.org/1053201 <- the pascal decoder calculates a 16 bits sample and outputs only 8 bits [05:07:25] <funman> hm ok [05:09:15] <kshishkov> but since existing ADPCM decoders in FFmpeg output S16 it's fine to convert output to s16 [05:09:25] <kshishkov> (I think) [05:09:39] <funman> i can ask the guru [05:10:03] <funman> also since the format is a bit different i added a new codec [05:10:12] <josh> speaking of the guru [05:10:17] <kshishkov> that's right [05:10:22] <josh> mn has a new blog post up :) [05:10:42] <kshishkov> funman: just submit and the guru will say how to improve/change it [05:10:43] <josh> i love reading those, always learn a lot [05:13:13] <kshishkov> indeed [05:23:18] <CIA-99> ffmpeg: rbultje * r24378 /trunk/libavcodec/x86/ (vc1dsp_mmx.c vp8dsp.asm dsputil_mmx.c vp8dsp-init.c): [05:23:18] <CIA-99> ffmpeg: VP8 MBedge loopfilter MMX/MMX2/SSE2 functions for both luma (width=16) [05:23:18] <CIA-99> ffmpeg: and chroma (width=8). [06:11:50] <thresh> moroning [06:11:52] <UKCoder> any aac whizzes around tonight? [06:14:01] <kshishkov> it's not evening here [06:14:08] <kshishkov> thresh: morning [06:16:01] <av500> morgen [06:16:15] <kshishkov> god morgon [06:17:08] <funman> mâtin [06:19:00] <saintdev> UKCoder: you probably want peloverde, he left a little earlier [06:20:53] <UKCoder> thanks saintdev [06:21:23] <kshishkov> what's the question anyway? [06:22:55] <UKCoder> I'm looking at programmatically concatenating two aac file (of the same bitrate, same number of channels) and I'm getting hung up on what needs to be altered in the headers [06:23:03] <UKCoder> file=files [06:23:29] <saintdev> oh yeah, kshishkov may be able to answer also, he wrote the encoder :P [06:23:39] <UKCoder> :) [06:24:19] <av500> UKCoder: aac files as in? [06:24:41] <av500> what file format? [06:25:15] <UKCoder> av500: a couple of WAV files encoded with neroAacEnc [06:25:17] <av500> and isnt this a #ffmpeg type of question? [06:25:27] <pJok> god morgon :) [06:25:43] <av500> UKCoder: encoded into what? raw AAC, ADTS? ADIF? MP4? [06:25:50] <UKCoder> av500: I'm not trying to achieve it with ffmpeg, just trying to understand how it's done [06:26:04] <av500> UKCoder: encoded into what? raw AAC, ADTS? ADIF? MP4? [06:26:45] <saintdev> LATM [06:26:51] <UKCoder> av500: I'm guessing raw AAC (it's whatever output format comes out of neroAacEnc, not entirely sure) [06:27:03] <saintdev> nero outputs mp4 [06:27:39] <UKCoder> thanks saintdev, I did notice a bunch of mp4 strings when I opened it up with mc [06:27:52] <av500> UKCoder: well, then you cannot tweak the headers [06:27:59] <av500> you need to demux and remux [06:28:17] <av500> i bet ffmpeg can do that [06:29:41] <UKCoder> av500: hmm... I really have to go through all that? I'm trying to put together a simple program that dumps the contents of a few files concatenated together, to put a seemless stream. [06:30:03] <av500> you? no, use ffmpeg [06:30:20] <av500> and complain to apple for inventing mov/mp4 [06:30:39] <mru> mornings [06:31:05] <UKCoder> av500: I wish I could use ffmpeg, but I'm writing this in java. I figured ffmpeg devs would have done this already so I came here to see if I could pick some brains :) [06:31:19] <mru> use xuggle then [06:31:38] <av500> UKCoder: yes, ffmpeg devs did that, the results are inside ffmpeg [06:32:24] <av500> UKCoder: can you tell me how to join 2 word documents in a simple java program? [06:32:32] <UKCoder> av500 [06:32:55] <UKCoder> : actually yes :) I've done that and painfully many other office formats before now for my day time job [06:33:22] <UKCoder> audio tinkering is my spare time hobby (kinda) [06:33:26] <av500> cool, so join in, we can make ffoffice :) [06:33:41] <mru> Dark_Shikari: BBB: you broke icc [06:33:45] <UKCoder> lol... I'd rather have hot pokers rammed inside me [06:33:57] * mru rams a poker inside UKCoder [06:33:57] <av500> we can arange that too [06:34:09] <UKCoder> you guys first :) [06:34:18] <av500> you asked for pain, not us [06:34:37] <Dark_Shikari> mru: I didn't do anything [06:35:27] <kshishkov> Dark_Shikari: then stop being lazy and do something [06:35:32] <mru> Dark_Shikari: you approved the patch [06:35:46] <funman> av500: oFFice ? :) [06:35:59] <mru> libavcodec/x86/vc1dsp_mmx.o:(.rodata+0x10): multiple definition of `ff_pw_18' [06:36:10] <mru> libavcodec/x86/dsputil_mmx.o:(.rodata+0x160): first defined here [06:36:10] <mru> ld: Warning: size of symbol `ff_pw_18' changed from 16 in libavcodec/x86/dsputil_mmx.o to 8 in libavcodec/x86/vc1dsp_mmx.o [06:36:34] <Dark_Shikari> that wasn't me [06:36:36] <Dark_Shikari> that was vc-1 [06:36:44] <Dark_Shikari> I think that was Yuvi's patch [06:36:54] <kshishkov> anyway, feel free to fix it [06:36:58] <mru> there were vc1 commits last night? [06:37:10] <UKCoder> mru: have you used xuggle? [06:37:13] <kshishkov> yes, loop filter for VP8 touched that file [06:37:28] <mru> UKCoder: no, I wouldn't touch java with a pointed stick [06:37:39] <votz> Anybody know what the variable name 'pb' (member of AVFormatContext of type ByteIOContext) stands for? [06:37:45] <Dark_Shikari> I investigated that problem earlier [06:37:47] <kshishkov> put bytes [06:37:50] <votz> ah [06:37:52] <Dark_Shikari> I have no idea what it is, because ff_pw_18 doesn't _exist_ in dsputil_mmx.c [06:38:06] <mru> then it must be in some file it includes [06:38:35] <mru> libavcodec/x86/dsputil_mmx.c:DECLARE_ALIGNED(16, const xmm_reg, ff_pw_18 ) = {0x0012001200120012ULL, 0x0012001200120012ULL}; [06:38:42] <Dark_Shikari> oh. yuvi screwed up [06:38:49] <Dark_Shikari> he dedclared it twice [06:38:51] <Dark_Shikari> or wait, did BBB add it? [06:39:05] <av500> are you all just going to shuffle the blame all morning? [06:39:06] <mru> libavcodec/x86/vc1dsp_mmx.c:DECLARE_ASM_CONST(16, uint64_t, ff_pw_18) = 0x0012001200120012ULL; [06:39:28] <votz> kshishkov: ah, thanks [06:39:29] <mru> so which one should be deleted? [06:39:32] <funman> are fate builds triggered by svn post-commit hook ? [06:39:46] <mru> funman: most of them are just polling [06:39:47] <Dark_Shikari> mru: delete the vc1 one, expand the original to an xmmreg [06:39:53] <kshishkov> av500: why not? it was very popular in bureaucratic countries (like USSR) [06:39:57] <Dark_Shikari> and add it to dsputil_mmx.h if it isn't already there [06:40:10] <mru> Dark_Shikari: the dsputil one is xmm_reg [06:40:10] <saintdev> peloverde: think i can use the mdct coeffs in place of a fft for analysis? [06:40:11] <funman> on #rockbox the CIA bot announces warnings/errors after each commit [06:40:49] <peloverde> saintdev: That's what kostya's 3GPP-derived model does [06:41:01] <peloverde> OTOH, one extra FFT isn't going to kill us [06:41:14] <peloverde> IIRC psytel discussed this [06:42:01] <peloverde> http://www.mp3-tech.org/programmer/docs/di042001.pdf [06:42:17] <Dark_Shikari> mru: then delete the vc1 one [06:42:31] <av500> ah, all the good research comes from belgrade! [06:43:12] <peloverde> "Our improved coder is using MDCT for the psychoacoustic analysis, too. This way we are performing accurate estimate of the energy and also we are reducing complexity because MDCT output could also be used for the codec thus avoiding one transform. However, we also need complex values (imaginary part) of the transform in order to estimate tonality." [06:43:42] <UKCoder> av500: I'm a lil confused about comment you made about having to mux and demux to join the two aac files together. Not questioning the validity of the statement, just wondering how say a streaming server that's trying to concatentate content to a live stream would do that. It seems like the first file would be transmitted and so couldn't be de/remuxed to the latter [06:43:49] <peloverde> Anything from Ivan Dimkovic/PsyTEL should be treated as expert advice [06:44:13] <mru> I can ask ivan dimkovic in person if you want... [06:44:23] <saintdev> huh, i wonder how it compares then. there's a comment in the lame source that mentions using a shorter fft to match the mp3 window size may be better [06:44:27] <av500> UKCoder: it cant [06:44:30] <peloverde> I think his paper is very clear here [06:44:53] <av500> UKCoder: this is the "beaty" of mp4 [06:44:56] <saintdev> peloverde: again, like he states in that quote they use the imaginary part for calculation [06:45:00] <peloverde> "One of the possible solutions is using of CMDCT filterbank (Complex Modified Discrete Cosine Transform) that outputs MDCT as real part and MDST as imaginary part. CMDCT is also very good choice for LSI/DSP solutions because of reduced complexity when compared to ISO Model II approach (MDCT + FFT in parallel)." [06:45:34] <UKCoder> av500: huh? I've seen dynamic source clients feed streaming servers where the files are added dynamically... [06:45:58] <UKCoder> av500: things like edcast [06:46:07] <av500> yes, but the resulting file sent to the client is not MP4 [06:47:11] <peloverde> saintdev: For now I would add a slow MDST and we can work on an optimized MDCT/MDST pair later [06:47:41] <saintdev> peloverde: so i guess i'll just do fft for now, and maybe look into that later when i'm a little more knowledgeable ;) [06:47:45] <UKCoder> av500: does that hold true for aac+ aldo? [06:47:47] <UKCoder> also [06:48:11] <av500> it does not depend on aac at all [06:49:09] <peloverde> saintdev: OK, use FFT for now... one of the many DSP gurus can provide you with an MDST later [06:50:59] <UKCoder> av500: k, now you've really confused me. [06:51:19] <av500> UKCoder: the MP4 file format is not easily concatenable [06:51:19] <mru> can one of the x86 guys please fix the ff_pw_18 error? [06:51:36] <av500> UKCoder: regardless of which codecs are used [06:51:54] <funman> use ogg [06:52:12] <av500> yes, but make sure the stream ids are really random! [06:52:17] <UKCoder> funman: I currently do, but it's lack of support on mobile devices is forcing me to look elsewhere [06:52:43] <av500> use rtsp [06:53:48] <funman> sandisk audio players support ogg vorbis but i don't know about video players [06:54:06] <av500> sandisk audio players support streaming? [06:54:28] <UKCoder> av500: so I could wrap the aac content in RTP (rather than RTSP) and use RTP as the glue? [06:54:37] <mru> av500: yes, streaming off sd card [06:54:40] <av500> yes, rtp/rtsp [06:54:54] <UKCoder> av500: hmmm... that sounds promising [06:54:56] <av500> mru: ah, Streaming Data card [06:54:58] <funman> av500: not really [06:55:32] <funman> though you could stream audio over usb [06:55:43] <av500> funman: iKnow :) [06:56:23] <av500> funman: I made the JB6000 stream music from a hard disk :) [06:56:49] <funman> the sansa connect has wifi but i don't know how the firmware looks [06:57:23] <UKCoder> av500: rfc3016 to the rescue then :) [06:57:45] <funman> av500: nice, how/where did you send the stream? [06:59:37] <av500> to the MAS of course :) [06:59:42] <funman> bleh [07:00:06] <av500> you dont like the MAS? [07:00:11] <funman> no i don't [07:00:39] <funman> (i was speaking about USB audio card btw) [07:00:50] <av500> funman: ? [07:01:42] <funman> av500: the archos jukebox is the single reason to keep a lot of old unmaintained code in rockbox source so i don't like anything related to this player :) [07:01:57] <av500> but its the one that started it all! [07:02:42] <funman> true [07:02:48] <av500> I made a deliberately bad UI so that you could come along and fix it! [07:03:41] <funman> noooooo [07:04:10] * kshishkov asks jbr20 to write twenty FLAC encoders [07:05:01] <jbr20> kshishkov: I'm not into flacellation [07:05:43] * kshishkov now realizes that Vladimir's nick would make a nice library name [07:06:02] <av500> av500? the 500th ffmpeg library? [07:06:11] <mru> libav500, hmm... [07:06:19] <funman> not the 501st? [07:06:29] <kshishkov> should be good for tables [07:06:29] <av500> like Heinz 57 sauce.... [07:07:46] <av500> funman: but i dont get why rb does not make one last jb/jbr release and then drops it.... [07:09:21] <funman> it has been mentioned already, so 'why?', because there was no consensus already [07:09:38] <funman> rb has no leader who can make votes/decisions [07:10:11] <av500> funman: you need more votes! [07:10:46] <funman> unfortunately i don't know of a vote-counting fixed-point app! [07:12:05] <kshishkov> try fixed-voting counting app then [07:12:27] <av500> kshishkov: you have experience? [07:12:38] <kshishkov> av500: I lived in Ukraine [07:13:24] <av500> right [07:13:34] <av500> do they now adjust the fixed vote count since you left? [07:13:56] <kshishkov> I suspect it will be so for decades [07:46:55] <CIA-99> ffmpeg: mstorsjo * r24379 /trunk/ (libavformat/gxfenc.c tests/ref/lavf/gxf): [07:46:55] <CIA-99> ffmpeg: gxfenc: Fix ES name in the UMF media description, by using strlen instead of sizeof [07:46:55] <CIA-99> ffmpeg: Patch by Thierry Foucu, tfoucu at gmail [09:00:00] <av500> webm attracts very strange people: http://groups.google.com/a/webmproject.org/group/apps-devel/browse_thread/t… [09:00:16] <mru> I thought that was a property of the internet in general [09:00:53] <cartman> av500: how is your Google today? [09:00:55] <cartman> :p [09:00:57] * mru fails to find connection between phone and guitar [09:01:08] <av500> there is a fender labeled g1 or so [09:01:21] <mru> the things people will pay for... [09:01:56] <cartman> people would pay for ffmpeg on Android ;) [09:02:08] <av500> it exists already [09:02:17] <g0th> rock playerr [09:02:25] <mru> and others I'm sure [09:02:26] <av500> yup [09:02:29] <g0th> btw they now released some sources [09:02:34] <mru> yes, I know [09:02:36] <g0th> but only of ffmpeg (standard sources) [09:02:46] <g0th> and it is not clear how it fits into rockplayer etc [09:02:56] <av500> lgpl [09:03:01] <cartman> violation :) [09:03:04] <mru> I suppose swapping out the .so is enough [09:03:26] <g0th> I am happy that they deal with the problem at all [09:03:27] <mru> they should of course provide source for any changes they made [09:03:33] <mru> and the configuration they used [09:03:33] <g0th> I am unhappy how they do it though [09:03:48] <mru> but they seem to be trying to do the right thing at leasat [09:03:50] <mru> -a [09:03:54] <g0th> yes :) [09:04:09] <av500> mru: dont assume they made changes [09:04:30] <g0th> but afaics they simply took the standard sources and license files and put them somewhere on their webpage ^^ [09:04:39] <mru> statistically, the change they did is overwhelming [09:04:57] <mru> and they still need say how they built it [09:05:05] <cartman> wohoooo [09:05:09] <cartman> /usr/bin/ld: fatal error: out of file descriptors and couldn't close any [09:05:19] <mru> too much ulimit? [09:05:22] <av500> no OOFD killer? [09:05:27] <cartman> too crap linker? [09:05:29] <cartman> all of above [09:05:35] <mru> try an incremental link [09:05:46] <cartman> this is the so called "gold" linker [09:05:47] <mru> ld -r groups of 100 objects or so [09:05:49] <cartman> normal ld works fine [09:05:52] <mru> oh [09:05:53] <mru> gold.. [09:05:55] <mru> lol [09:05:57] <cartman> ;) [09:06:29] <av500> linking what? [09:06:33] <av500> silverlight? [09:07:04] <cartman> WebKitty [09:07:08] <cartman> ;) [09:08:39] <mru> did you try linking hno3.o and hcl.o? [09:08:50] <cartman> dunnow those [09:09:04] <mru> HNO3 + HCl = aqua regia [09:09:11] <mru> dissolves gold [09:11:47] <cartman> lol [09:12:05] <kshishkov> it's called "Tsar's vodka" in Russian for some reason [09:12:20] <av500> it dissolves the tsar as well [09:36:10] <benoit-> mru: too bad this one's locked, you would have loved it: http://www.diffthink.com/forum/viewtopic.php?f=2&t=34 [09:38:21] <mru> I don't post on web forums anyway [09:38:23] <mru> to much hassle [09:40:02] <kshishkov> you posted on NVidia forum or so I heard [09:40:21] <mru> there were good trolling opportunities there [09:49:30] <Yuvi> wasn't there a discussion about getting rid of DECLARE_ASM_CONST? [09:49:43] <mru> I tried [09:50:09] <mru> why bundle used-by-asm with const? [09:50:23] <mru> and with aligned [09:50:35] <mru> don't we have av_used already? [09:50:50] <mru> so DECLARE_ALIGNED(16, const av_used foo) [09:51:27] <Yuvi> do you even need av_used on non-static global vars? [09:51:40] <mru> never on non-static [09:51:42] <mru> obviously [09:51:55] <Yuvi> oh DECLARE_ASM_CONST is static [09:52:13] <mru> yeah, so add static to my line above [09:53:34] <Yuvi> so isn't icc's compilation failure their bug? [09:53:34] <Yuvi> not that all the asm constants shouldn't be gathered in one place [09:54:16] <Yuvi> or I guess it'd be weird either way [09:54:27] <mru> it's a duplicate symbol [09:54:34] <mru> how gcc doesn't fail is a mystery [09:54:51] <Yuvi> ff_pw_18 isn't declared in any headers actually [09:55:07] <Yuvi> so from vc1dsp_mmx.c's perspective, its static ff_pw_18 is the only one [09:55:31] <mru> oh, I see what's going on [09:55:39] <mru> for icc DECLARE_ASM_CONST _isn't_ static [09:56:01] <mru> doesn't icc support attribute(used)? [09:56:13] <Yuvi> no clue, never used it [10:02:57] <CIA-99> ffmpeg: conrad * r24380 /trunk/libavcodec/x86/ (vc1dsp_mmx.c dsputil_mmx.c): [10:02:57] <CIA-99> ffmpeg: Move ff_pw_* from vc1dsp_mmx.c to dsputil_mmx.c [10:02:57] <CIA-99> ffmpeg: Should fix compilation with icc and should help prevent any future duplicates [10:02:57] <CIA-99> ffmpeg: conrad * r24381 /trunk/libavcodec/x86/dsputil_mmx.h: Add header declarations for mmx/sse constants missing them [10:03:28] <mru> thanks [10:07:12] <CIA-99> ffmpeg: mru * r24382 /trunk/Makefile: Enable lavfi test in "make test" [10:12:42] <Yuvi> hm, using multiple threads for libvpx decode appears to add 60% to user time while not affecting wall clock time at all [10:13:23] <mru> heh [10:13:28] <mru> that's called scalability [10:13:31] <kshishkov> can you use enough threads to make user time > real time? [10:13:41] <mru> you see, they do 60% more work in the same time [10:13:44] <mru> so it's quite good [10:14:07] <mru> kshishkov: with thread user time usually is > real time [10:14:15] <mru> user time being sum of time by all threads [10:14:49] <Yuvi> oh whoops, I was comparing the timing of two completely different videos [10:15:47] <spaam> good job [10:16:03] <Yuvi> with 2 threads, 40% more user time for 16% faster real time [10:16:39] <mru> not impressive [10:17:36] <Yuvi> yeah, they don't do frame multithreading and slice multithreading is limited to decoding coeffs *iff* the video is encoded with multiple partitions [10:17:43] <kshishkov> mru: I know, but it's be hilarious to see that most time spent on decoding is actually thread switching overhead [11:30:46] <av500> finally RMS found a welcoming place: http://www.computerworlduk.com/community/blogs/index.cfm?entryid=3083 [11:31:17] <mru> "year of the GNU/Linux smartphone" [11:31:23] <mru> there's nothing gnu in android [11:31:25] <mru> only linux [11:31:29] <mru> and android [11:31:35] <mru> so it's android/linux [11:32:36] <av500> since he uses a chinese laptop already, i thought he would maybe defect [11:32:50] <mru> one can always hope [11:34:17] <av500> maybe if the chinese firewall starts filtering closed source java script.... [11:34:41] <mru> that story about his laptop is just too funny [11:34:52] <mru> why doesn't he just put seabios on a normal pc [11:35:12] <av500> closed src gfx drivers? [11:35:19] <mru> intel [11:35:27] <mru> as open as they come [11:35:30] <thresh> so, non-working gfx drivers [11:35:38] <mru> works for me [11:35:38] <av500> mru: poulsbo? [11:35:40] <thresh> although I though he doesn't use X [11:35:44] <thresh> thought [11:35:46] <mru> av500: so don't get that one then [11:35:50] <mru> arrandale works fine [11:35:58] <av500> mru: same here :) [11:36:12] <mru> haven't bothered with the nvidia chip [11:36:18] <av500> idont have one [11:36:30] <mru> I switched it off in bios [11:36:33] <mru> saves power [11:36:42] <av500> mine has only intel [11:36:52] <mru> what machine? [11:36:56] <av500> x210 [11:36:58] <av500> x201 [11:37:05] <mru> who makes? [11:37:09] <thresh> mru: have you tried switching on-the-fly? [11:37:11] <av500> lenovo [11:37:58] <mru> thresh: no [12:38:35] <CIA-99> ffmpeg: flameeyes * r24383 /trunk/ (5 files in 2 dirs): (log message trimmed) [12:38:35] <CIA-99> ffmpeg: Make ff_inverse stay with libavutil, and optional copy it to libavcodec. [12:38:35] <CIA-99> ffmpeg: The ff_inverse table is used by FASTDIV macro, defined in libavutil, but up [12:38:35] <CIA-99> ffmpeg: to now the table was defined only in libavcodec. [12:38:35] <CIA-99> ffmpeg: After this change, the main copy of ff_inverse is part of libavutil (just [12:38:35] <CIA-99> ffmpeg: like FASTDIV), but if CONFIG_SMALL is unset, then a different copy is made [12:38:36] <CIA-99> ffmpeg: available to libavcodec, to avoid the performance penalty of using an [12:51:18] <benoit-> mru: do you have any plan to making config target use the 'quiet' output mode too ? [12:52:01] <mru> now I do [12:52:08] <mru> how would you like it? [12:52:58] <benoit-> I don't really know [12:53:16] <benoit-> mru: that's even "I really don't know" :) [12:54:11] <benoit-> CONFIG would do I guess, maybe also having the configure options would be cool [13:07:34] <Honoome> mru: is it wanted that the tablegen stuff is not in svn:ignore? [13:09:17] <mru> Honoome: I don't maintain svn:ignore [13:09:33] <mru> but anything generated during a build should be there I guess [13:09:35] <Honoome> I think Diego is coming this way and probably unreachable :P [13:11:02] <mru> aren't you also a diego?

1 0

IRC log for 2010-07-20
by irc＠mansr.com 21 Jul '10

21 Jul '10

[00:00:06] <kierank> virtualbox can run x86_64 [00:01:36] <BBB> Yuvi: the ppc vp8 tests also fail, could this be a bug in your ppc code? [00:01:54] <Dark_Shikari> Could it be a bug in your deblock chroma change? [00:02:01] <BBB> Dark_Shikari: ok, patch is reverted, I'll see what I can do tonight [00:02:19] <BBB> no [00:02:25] <BBB> the ppc has been broken for quite a while [00:02:32] <BBB> as long as the history goes, at least [00:02:37] <j0sh> BBB:email sent [00:02:41] <BBB> and it's specific for gcc-4.0.4 also, the rest works fine (??) [00:02:49] <CIA-99> ffmpeg: rbultje * r24341 /trunk/libavcodec/x86/ (vp8dsp.asm vp8dsp-init.c): [00:02:49] <CIA-99> ffmpeg: Revert r24339 (it causes fate failures on x86-64) - I'll figure out what's [00:02:49] <CIA-99> ffmpeg: wrong with it tomorrow or so, then re-submit. [00:02:55] <BBB> http://fate.multimedia.cx/index.php?history=build&config_id=9 [00:03:30] <BBB> j0sh: can you install yasm? [00:03:41] <BBB> that's all I should need [00:03:54] <j0sh> sure [00:04:03] <BBB> thanks [00:04:07] <bcoudurier> hi guys [00:04:18] <j0sh> done [00:11:25] <BBB> j0sh: did you install gcc, etc? [00:11:30] <BBB> maybe libc-dev [00:11:35] <BBB> something basic is missing [00:11:41] <j0sh> doh, yes [00:11:44] <j0sh> build-essentials [00:12:06] <j0sh> installing now [00:12:07] <Honoome> aaah these binary distributions [00:12:13] <j0sh> btw [00:12:23] <Honoome> I challenge you to forget the compiler on gentoo ;P [00:12:25] <j0sh> i have no idea what the hardware specs on this are [00:12:40] <j0sh> i dont know if sse3, etc will work if you need that [00:13:11] <BBB> no, sse2 is enough [00:13:43] <BBB> can you download http://code.google.com/p/webm/downloads/detail?name=vp8-test-vectors-r1.zip… and put it in my home dir? [00:13:49] <BBB> maybe wget is installed [00:14:08] <j0sh> it should be [00:14:37] <BBB> ok, got it [00:15:05] <j0sh> also installed git/subversion if you need to work directly from trunk [00:15:10] <BBB> thanks [00:16:37] <BBB> at least fate is greener again [00:23:33] <j0sh> 4 core xeons [00:23:39] <j0sh> /proc/cpuinfo ftw [00:24:31] <j0sh> apparently has sse4 if anybody wants to play wit that... [01:10:51] <lu_zero> aEHM [01:11:05] <lu_zero> I did test it. [01:41:01] <Honoome> okay I'll qualify my earlier statement: give lu_zero a step-by-step guide while asking him to test something ;) this includes running "make fate" [05:24:18] <CIA-99> ffmpeg: mstorsjo * r24342 /trunk/libavformat/movenc.c: [05:24:19] <CIA-99> ffmpeg: movenc: Free the buffer returned by url_close_dyn_buffer, regardless of the size [05:24:19] <CIA-99> ffmpeg: This fixes a leak introduced in rev 23942, since we write padding to the [05:24:19] <CIA-99> ffmpeg: buffer unconditionally. [05:27:10] <av500> gm CIA-99 [05:27:52] * kshishkov thinks something is wrong with av500 [05:28:37] <thresh> moroning [05:28:43] * thresh yaawns [05:29:17] <kshishkov> thresh, mornings are usually better is you move far from exUSSR [05:31:02] <av500> kshishkov: a quick steam train ride brefore going to the office today? :) [05:31:06] <thresh> kshishkov: got any tips? [05:31:28] <thresh> to 'намаслить лыжи' [05:31:45] <kshishkov> thresh: Turks recommend Switzerland [05:32:05] <kshishkov> av500: I've not earned enough to buy one, sorry [05:32:31] <funman> you'd better be rich to enter or even approach Switzerland [05:32:47] <kshishkov> thresh: also depends on man - some feel good at USA, some prefer Germany, some like Sweden [05:33:07] <kshishkov> funman: hah, even I've been there [05:33:24] <funman> you lived there? [05:34:41] <funman> life (and especially housing) is very expensive [05:35:02] <thresh> kshishkov: How did you find your employer? [05:35:02] <funman> ok with Swiss salary though [05:35:28] <av500> funman: of course you live in germany and work in .CH :) [05:35:31] <thresh> housing becomes really expensive in Moscow now as well:-( [05:36:03] <funman> av500: yeah i know this but from the other side of switzerland (my bro lives in france close to geneva) [05:36:20] <kshishkov> funman: I just went there for a day [05:36:27] <funman> av500: i bet housing near switzerland is expensive as well? [05:36:36] <av500> no idea [05:36:56] <kshishkov> thresh: I'm lazy, it's always employers finding me. When I tried to look for job I was always unsuccessful [05:37:14] <thresh> kshishkov: suppose I need to learn something useful first ;-) [05:37:22] <kshishkov> German houses are cheap - as in Ukraine [05:37:45] <av500> kshishkov: damn, they must be hiding here somewhere [05:38:07] <kshishkov> thresh: depends on your definition of "useful" - maybe it's enough to let certain people know you can do something [05:38:33] <funman> hmm freenode has #jobs for jobs opportunities. so bad there's only me and chanserv [05:38:55] <thresh> maybe Chanserv is hiring. [05:39:04] <funman> thresh: perhaps start by putting your CV online [05:39:11] <av500> and make a blog [05:39:16] <kshishkov> av500: nope, you just don't know prices for real estate in .ua [05:39:43] * funman read that as .lua [05:41:01] <thresh> I probably need to translate my CV into more used language, right [05:50:23] <kshishkov> thresh: from Russian to Moscowian? [05:52:51] <thresh> kshishkov: I don't have enough practice to speak Moscowian. That, and no Cayennes, Prada or Tissots... [05:53:27] <funman> there's a reason you use 'free' software, no ? [05:54:25] <kshishkov> nope [05:54:27] <Dark_Shikari> cheapskate! [05:54:41] <kshishkov> all software had the same price in Russia [05:55:00] <thresh> 2 EUR per CD now, or something like that [06:11:46] <josh> wbs: how do i disable auth requirements for DSS? [06:12:29] <josh> i keep getting 401's, no matter how many times i try to re-set the username/pw or disable authentication [06:17:09] <josh> (for broadcasting) [06:18:39] <wbs> josh: don't know if you can disable it altogether, but if the server is on localhost, you shouldn't need any password [06:19:02] <josh> just username then? [06:19:18] <wbs> no username either [06:19:48] <wbs> but it sounds weird if you aren't able to use the broadcast password properly [06:19:50] <josh> still getting 401s [06:20:21] <josh> yeah [06:20:30] <wbs> streaming to rtsp://localhost/foobar.sdp using ffmpeg? [06:20:38] <wbs> or rtsp://username:password@server/foobar.sdp? [06:20:43] <benoit-> good morning [06:21:24] <josh> former [06:21:27] <josh> well, neither work [06:21:51] <josh> i'm gonna tool around in the darwin config file for a bit [06:22:29] <wbs> and you set the broadcast password via the admin ui, at http://server:1220, unser general, movie broadcast password? [06:22:40] <josh> yeah [06:22:44] <josh> every time i do that [06:22:49] <josh> and go back [06:23:03] <josh> it seems to be reset [06:23:15] <josh> to the admin username [06:23:28] <wbs> hmmm, sounds like there's some issue with updating some of the files? [06:25:27] <josh> probably [06:40:43] <mru> morning [06:41:12] * Dark_Shikari reminds mru to do a little bit of hunting today [06:41:27] * mru loads shotgun [06:43:36] <mru> someone was looking for me earlier [06:43:47] <mru> Honoome: ^^ [08:15:15] * pJok unleashes his snapdragon power on mru [08:16:39] * kshishkov still waits for ARM-based server [08:17:04] <pJok> aren't there ARM based servers out there...? [08:17:24] <mru> toy "nas" boxes don't count [08:17:27] <kshishkov> proper ARM-based servers, with 2GHz multicore CPUs [08:17:44] <KotH> filling whole rooms with hardware? [08:18:36] <pJok> kshishkov, doesn't that really require A9 to be out first? [08:18:44] <kshishkov> nope [08:18:47] <mru> a9 _is_ out [08:18:57] <pJok> mru, i know... but i recall having seen a server board out there somewhere with ARM [08:19:12] <pJok> and out as in widely used... [08:19:27] <mru> many boards have arm cores in the chipsets [08:20:18] <lu_zero> as ppcs and mipses [08:21:14] <pJok> it just lurks inside my brain [08:21:24] <superdump> how long has the A9 been out? how come there are still so many new products being released that still use A8? [08:21:25] <pJok> if i suddenly remember where i saw it, i will spam you with it, mru [08:21:26] <pJok> ;) [08:21:47] <superdump> just product development time? [08:21:51] <pJok> superdump, its the apple factor! [08:21:52] <kshishkov> superdump: different goals [08:21:58] <mru> superdump: A8 is plenty enough for many applications [08:22:06] <mru> and probably a lot cheaper [08:22:15] <mru> there are still arm7 devices being made [08:22:38] <mru> and development time is a factor too [08:23:00] <Dark_Shikari> there are still arm5 devices being made [08:23:07] <mru> Dark_Shikari: no [08:23:16] <mru> armv5, not arm5 [08:23:40] <mru> arm7 is the oldest anyone still uses [08:23:52] <mru> some of them are armv4 actually [08:24:29] <Dark_Shikari> does armv7 mostly map to arm7? [08:24:31] * kshishkov dislikes that numbering scheme [08:24:35] <mru> Dark_Shikari: oh no [08:24:42] <pJok> arm numbering scheme is cryptic at best [08:24:43] <mru> the vX are architecture versions [08:24:54] <mru> v4-v7 are currently available [08:25:04] <pJok> no worse than intels though... [08:25:12] <Dark_Shikari> er [08:25:12] <Dark_Shikari> I meant [08:25:13] <Dark_Shikari> armv4 [08:25:14] <Dark_Shikari> map to arm7 [08:25:18] <Dark_Shikari> sorry, typo [08:25:29] <mru> arm7 can be v4 or v5 [08:25:34] <mru> there are a few of both [08:25:41] <mru> same for arm9 [08:25:48] * pJok remembers his nokia 8210 having ARM7TDMI [08:25:48] <wbs> Dark_Shikari: http://en.wikipedia.org/wiki/ARM_architecture gives quite a good overview (I think) [08:25:49] <mru> arm11 is always v6 [08:25:57] <Dark_Shikari> is v7 arm13? [08:26:02] <mru> there is no arm13 [08:26:06] <Dark_Shikari> then what's v7? [08:26:06] <mru> or 12 [08:26:11] <mru> v7 is cortex [08:26:15] <Dark_Shikari> they stopped the numbers? [08:26:15] <mru> and snapdragon [08:26:22] <Dark_Shikari> Why are there no even numbers? [08:26:25] <Dark_Shikari> arm11, arm9, arm7... [08:26:29] <mru> there's 10 [08:26:35] <mru> they're rare though [08:27:00] <mru> maybe they stopped the numbers because they were confusing [08:27:28] <iive> names are even more confusing... [08:27:35] <av500> nothing is as confusing as intel naming [08:27:49] <mru> that's a given [08:27:49] <av500> this I7 is has 2 cores? 4 cores? 6 cores? [08:28:06] <Dark_Shikari> the intel naming makes sense, it's what they do with them that ends up being stupid [08:28:10] <Dark_Shikari> i3, i5, i7: makes sense, low to high end. [08:28:15] <Dark_Shikari> Then they start releasing 2 core i7s. [08:28:16] <Dark_Shikari> What? [08:28:18] <av500> i just need a 6core, to have all 3.... :) [08:28:25] <av500> Dark_Shikari: you, in my laptop [08:28:27] <av500> yup [08:28:30] <mru> Dark_Shikari: the official names are fine [08:28:40] <mru> it's the boggleston and whatnot I can't get a grip on [08:28:43] <pJok> remember, its iX YYY for the intel naming scheme [08:28:52] <Dark_Shikari> mru: oh, you mean codenames [08:28:54] <Dark_Shikari> those aren't official names [08:29:01] <Dark_Shikari> I _prefer_ the codenames [08:29:02] <mru> but everybody uses them [08:29:04] <Dark_Shikari> because they're more accurate [08:29:08] <Dark_Shikari> "i3 i5 i7" says nothing [08:29:12] <Dark_Shikari> "nehalem" is the name of the architecture [08:29:15] <pJok> about as informing as nVidias and ATi's naming schemes for their XXXXGT, GTS, GTX model name schemes... [08:29:17] <Dark_Shikari> it covers _everything_ in that category. [08:29:18] <mru> i7 940 says something [08:29:25] <Dark_Shikari> "nehalem" is like "arm11" [08:29:31] <mru> Dark_Shikari: I know that [08:29:33] <av500> i7 used to saw "awesome quadcore" [08:29:41] <av500> not it can be lame laptop core [08:29:41] <mru> there's just no way to compare them [08:29:43] <av500> now [08:29:53] <mru> arm11 is obviously better than arm9 [08:30:01] <mru> and arm1136 is similar to arm1176 [08:30:03] <mru> etc [08:30:11] <mru> all cortex-a are similar [08:30:15] <av500> mru: is apple A4 better than A8? :) [08:30:22] <Dark_Shikari> mru: with intel it's basically the same concept [08:30:28] <Dark_Shikari> take, for example, since the p4 days [08:30:33] <Dark_Shikari> original p4: williamette (shiiiiiit) [08:30:40] <Dark_Shikari> upgraded p4: northwood (less shit) [08:30:46] <mru> but they're not in alphabetical order or anything [08:30:57] <Dark_Shikari> crazy-long-stupid-pipeline-p4-that-used-200-watts: Prescott [08:30:59] <mru> just looking at the names it's impossible to tell what's what [08:31:14] <Dark_Shikari> Pentium M that sat around beating the crap out of the p4 while Intel hid in shame: dothan [08:31:16] <mru> prescott is a UK politician so it makes sense that it's shit [08:31:33] <Dark_Shikari> original Core 2: conroe [08:31:36] <Dark_Shikari> 45nm core 2 shrink: penryn [08:31:40] * av500 waits for the Intel Torchwood cpu [08:31:46] <Dark_Shikari> the latest awesome: nehalem. [08:31:52] <mru> av500: is that better than a Gotham? [08:31:57] <pJok> av500, Apple A4 is an A8 ;) [08:32:03] <av500> pJok: orly? [08:32:06] <Dark_Shikari> so that's basically 7 arches in the past decade [08:32:09] <kshishkov> mru: UK has politicians? [08:32:14] <Dark_Shikari> I ignored core 1, but core 1 was really just a rebranding of the dothan. [08:32:17] <pJok> av500, but its apple... so half should do just fine... [08:32:24] <mru> pJok: a4 is soc [08:32:39] <pJok> mru, i know [08:32:49] <kshishkov> av500: "torchwood" sounds more like AMD CPU [08:32:59] <Dark_Shikari> torchwood sounds more like a diablo 2 clone [08:33:05] <av500> kshishkov: right, I had a few athlons torch themselves [08:33:09] <Dark_Shikari> Or a primetime TV show [08:33:16] <av500> Dark_Shikari: :) [08:33:20] <pJok> Dr. Who spin-off [08:33:25] <mru> av500: that's the Hogroast chip [08:34:02] <av500> that was the "dont touch the cpu with a heatsink, silicon edges will splinter off" aera... [08:35:00] * pJok should fry up his breakfast on a cpu [08:35:06] <Dark_Shikari> hmm, mru, intel could pull an ubuntu [08:35:09] <Dark_Shikari> make the names in alphabetical order [08:35:14] <Dark_Shikari> that'd run out after 26 arches [08:35:17] <Dark_Shikari> but it'd work for a while [08:35:27] <Dark_Shikari> They could name them after fruits. [08:35:28] <Dark_Shikari> Appleton [08:35:28] <pJok> should be plenty of presscott processors laying around for that [08:35:31] <Dark_Shikari> Bananable [08:35:42] <Dark_Shikari> Cherryroast [08:36:10] <mru> Dark_Shikari: do you see what I mean? [08:36:19] <mru> there's no relation _at all_ between the names [08:36:33] <pJok> Donut, Eclair, Froyo, Gingerbread? [08:36:35] <mru> short of memorising all of them there's no way to even guess [08:36:41] <Dark_Shikari> mru: like git hashes [08:36:47] <Dark_Shikari> well, except you can at least memorize intel's names. [08:36:48] <mru> Dark_Shikari: :-) [08:37:05] <av500> i486, i586, i686, i786, i886, i986..... where are we now? [08:37:10] <Dark_Shikari> lol [08:37:15] <astrange> you just start over when you reach Z [08:37:26] <Dark_Shikari> Well, honestly, I think it's easier to memorize 150 pokemon by name than by number. [08:37:30] <kshishkov> av500: wrapped around and went to i3, i5, i7 [08:37:38] <Dark_Shikari> Which brings me to my next point... CPUs are like pokemon. [08:37:54] <mru> x86 is a monster, yes [08:37:55] <Dark_Shikari> Williamette evolved into Northwood! [08:38:31] <Dark_Shikari> Pentium 4 is trying to learn "SSE3". But Pentium 4 can only learn 4 abillities. Which ability would you like to replace to learn "SSE3"? [08:38:39] <Dark_Shikari> >Sane-length pipeline [08:38:44] <Dark_Shikari> Pentium 4 has learned "SSE3!" [08:38:51] <Dark_Shikari> And Pentium 4 has forgotten "sane-length pipeline"! [08:39:16] * mru has no clue about pokemon [08:39:28] * mru wishes to keep it that way [08:39:53] <kshishkov> mru: that's misterious thing mentioned in XKCD along with Ubuntu [08:39:56] <ubitux> Dark_Shikari: there are more than 493 pokémons atm [08:39:58] <ubitux> :( [08:40:01] * av500 wishes elenril would drown Dark_Shikari in tropes [08:40:03] <Dark_Shikari> ubitux: the ones after the first 150 don't exist. [08:40:11] <ubitux> :D [08:40:22] <mru> Dark_Shikari: grow up [08:40:26] <kshishkov> Dark_Shikari: too much information [08:40:28] <Dark_Shikari> mru: That would be horribly lame. [08:40:40] <Dark_Shikari> "growing up" is an excuse made by boring people for not having fun. [08:41:05] <mru> well, that's true too [08:43:07] <lu_zero> Dark_Shikari: evolve! [08:44:11] <kshishkov> lu_zero: he's not Zerg, you know [08:44:19] <lu_zero> kshishkov: you sure? [08:44:29] <Dark_Shikari> EVOLUTION COMPLETE [08:44:35] <lu_zero> oh... [08:44:45] <kshishkov> lu_zero: not very much. Do Zergs play Touhou games? [08:44:58] <Dark_Shikari> kshishkov: well, the fairies seem to be like the zerg [08:44:59] <lu_zero> kshishkov: I'm afraid they do in sc2 [08:45:01] <Dark_Shikari> they're tons of them [08:45:06] <Dark_Shikari> oh yeah, lu_zero, you have a point [08:45:10] <Dark_Shikari> there's that touhou clone for sc2 [08:45:50] * lu_zero is wondering who has the rainbow attack... [08:45:56] <lu_zero> protos. [08:51:41] <astrange> Dark_Shikari: you don't like bidoof? [08:52:33] <Dark_Shikari> which one is that? [08:52:38] <Dark_Shikari> I don't play your newfangled series reboots. [08:52:47] <Dark_Shikari> the only one I know of is mudkips. [08:52:50] <Dark_Shikari> and for the obvious reason. [08:53:07] <astrange> http://tygerstyle.net/wordpress/wp-content/uploads/2007/05/art_011.jpg [08:53:47] <Dark_Shikari> Oh. That guy. [08:54:19] <Dark_Shikari> He looks like a Chia pet. [08:58:41] <iive> is that pokemon too? [09:00:56] <av500> lol: http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread… [09:02:49] * kshishkov invents A-frames that make video better than one with B-frames by definition [09:03:45] <mru> mpeg1 D-frames were worse for sure [09:04:04] <Dark_Shikari> Q-frames [09:04:46] <kshishkov> Z-frames encoded with IJG 9 [09:05:22] <av500> kshishkov: A-frames can be nice for vacation [09:07:33] <kshishkov> av500: the only vacation I had in my life was June 9th-11th 2010 [09:07:57] <av500> and janneg does not live in an a-frame.... [09:10:35] * elenril shoots av500 [09:10:47] <elenril> i don't even read tvtropes all that much =p [09:10:58] * av500 tropes elenril [09:11:26] <mru> elenril: not anymore, not since you memorised them all [09:11:32] <av500> http://tvtropes.org/pmwiki/pmwiki.php/Main/TheTropeToEndAllTropes [09:11:56] * kshishkov wants to kill at least half of av500 [09:12:14] <av500> i'll just grow back [09:12:31] * elenril kills av500 http://tvtropes.org/pmwiki/pmwiki.php/Main/DeaderThanDead [09:12:57] <elenril> mru: irrelevant details [09:13:08] <iive> elenril: i don't know if you read them, but you quote them all the time :P [09:13:48] <av500> you have been troped [09:14:00] <av500> you've got trope [09:14:49] <pJok> never start cleaning up in a mess you enherited when its 32+ degrees where the mess is... [09:15:29] <kshishkov> yes, let it produce vile stench first [09:15:44] <kshishkov> and attract flies [09:16:20] <pJok> its only bitrot [09:16:27] <mru> bitflies [09:16:44] <pJok> old outdated equipment that should have been thrown away way before i started in this company [09:16:56] <av500> and you are the janitor? [09:16:58] <pJok> (like most of the rest of the equipment we use) [09:17:04] <mru> bitjanitor [09:17:06] <pJok> av500, im the IT janitor, yes... [09:17:14] <pJok> i have all the keys [09:17:15] <av500> oh [09:17:31] <pJok> im the IT drone of this company [09:17:38] <pJok> which just means im in charge of anything with a charge [09:17:49] <pJok> except video equipment [09:17:58] <mru> bitpredator? [09:18:02] <pJok> i wish [09:18:07] <twnqx> hm, blurays/dvds don't have language info in the stream, do they? [09:18:21] <mru> twnqx: dvds have it in the ifo files [09:18:28] <kshishkov> mru: careful, you may mention some versioning system by mistake [09:18:35] <twnqx> i meant the m2ts/vob alone [09:18:52] <mru> twnqx: not in the vob [09:18:55] <mru> don't know about bluray [09:19:50] <av500> twnqx: for DVD, not in the vob [09:20:03] <twnqx> mh [09:20:18] <mru> av500: no professional guess about bluray? [09:20:34] <mru> can a bluray have 54 audio streams? [09:20:52] <twnqx> i'm just looking at one with 8 audio and 5 sub streams [09:21:08] <pJok> mru, if you make an image, i will gladly test if a bluray will play with 54 audio streams ;) [09:22:11] <pJok> actually i dont think we have proper bluray player software... [09:22:26] <twnqx> not for menus etc [09:22:30] <twnqx> the .m2ts plays fine [09:22:32] <pJok> last time i had to do something with a bluray, i used vlc anyways [09:23:22] <twnqx> huh, ffmpeg supports everything that can be in a stream [09:38:30] <pJok> twnqx, untrue.... avi in mov isn't supported ;) [09:38:44] <twnqx> s/stream/bluray stream/ [09:39:12] <pJok> i actually wonder when demuxer chaining will happen [09:39:20] <pJok> would be fun to wrap an ogg in an avi in a mov [09:45:12] <CIA-99> ffmpeg: cehoyos * r24343 /trunk/ (3 files in 3 dirs): [09:45:12] <CIA-99> ffmpeg: Make MP43 the default fourcc for msmpeg4v3: [09:45:12] <CIA-99> ffmpeg: DIV3 is not supported on default XP and Vista installations (MP43 is). [09:59:24] <CIA-99> ffmpeg: mstorsjo * r24344 /trunk/libavformat/aviobuf.c: Remove an assert that was no longer correct nor relevant [10:10:52] <CIA-99> ffmpeg: mru * r24345 /trunk/tests/ (229 files in 2 dirs): regtest: rename seektest ref files using alphanumeric chars only [10:18:33] * elenril kicks git-cvsimport [10:18:41] <elenril> why does it have to be so slow [10:18:50] <KotH> because it's *effort* [10:18:55] <mru> cvs is slow [10:20:15] <CIA-99> ffmpeg: mru * r24346 /trunk/configure: Collect list of seek tests in configure [10:20:16] <CIA-99> ffmpeg: mru * r24347 /trunk/ (Makefile tests/fate-run.sh): fate: allow running regtests through fate frontend [10:20:16] <CIA-99> ffmpeg: mru * r24348 /trunk/Makefile: Remove old regtest make rules redirecting to fate-based ones [10:20:17] <CIA-99> ffmpeg: mru * r24349 /trunk/tests/seek-regression.sh: Remove unused seek-regression.sh script [10:25:06] <elenril> anybody knows about a git mirror for pgf? [10:25:27] <elenril> i feel like this could take a few hours [10:27:52] <lu_zero> pgf? [10:28:17] <lu_zero> elenril: what are you mirroring? [10:28:50] <elenril> http://en.wikipedia.org/wiki/PGF/TikZ [10:29:06] <elenril> a tex package for drawing [10:29:14] <elenril> it still uses cvs :/ [10:30:45] <KotH> most of tex uses cvs [10:31:27] <elenril> are they into bdsm or what [10:32:02] <av500> wasnt tex like buf free? they could use .tgz ... [10:32:07] <av500> bug free [10:33:36] <elenril> packages aren't [10:34:38] <av500> ah [10:35:24] <KotH> and which tex implementation? [10:35:33] <lu_zero> and tex is already a perversion in many senses [10:35:43] <KotH> tetex has been replaced by pdflatex which is going to be replaced by luatex [10:35:59] <mru> that doesn't sound right [10:36:03] <elenril> KotH: you mean xetex [10:36:18] <mru> tetex is/was a tex distribution containing all the different frontends and backends [10:36:33] <mru> pdflatex is a latex frontend and a pdf backend [10:36:43] <KotH> lu_zero: then you've never hat a look at metapost/metaobject ;:) [10:37:10] <mru> gentoo is now installing something called texlive [10:37:21] <mru> which also contains all the usual frontends and backends [10:37:32] <mru> I have no idea what luatex is but it sounds scary [10:37:33] <elenril> yeah, texlive replaced tetex [10:37:49] <KotH> mru: most distros switched to texlive as tetex wasnt maintained for years [10:37:57] <mru> yes, makes sense [10:38:08] <mru> but both contain pdflatex [10:38:26] <mru> it neither replaced anything nor was replaced [10:38:50] <elenril> pdflatex and luatex and xetex and godknowswhatelsetex [10:38:57] <av500> textex? [10:39:07] <av500> semtex ftw! [10:39:33] <mru> av500: can I run that on my beagle C4? [10:39:39] <KotH> semtex for the *BOOM*! [10:39:52] <av500> mru: dont mix C4 and semtex [10:40:07] <mru> what happens? [10:40:22] <av500> i guess nothing, still few people try [10:42:58] <spaam> mru: do you run gentoo on your beagle? :D [10:43:05] <mru> of course [10:43:11] <mru> by beagleS [10:43:24] <lu_zero> KotH: whats that? [10:43:34] <lu_zero> lots of beagles [10:43:38] <mru> lu_zero: the boom? [10:44:16] <lu_zero> you managed to made them explode? [10:44:25] <mru> no [10:44:43] <lu_zero> btw there are interesting plans about having at least pkgcore support remote building [10:45:14] <mru> what's pkgcore? [10:47:14] <lu_zero> an alternative implementation of portage [10:47:26] <lu_zero> still python+C [10:56:44] <spaam> lu_zero: what is the diff between pkgcore and paludis ? :) [10:56:59] <mru> all except the p [10:57:33] <spaam> ;P [10:58:05] <ods15> does anyone know if cellphones today use software decoding for video or hardware? [10:58:31] <mru> combination [10:59:16] <ods15> what sort.. does the software handle the frames individually? (demuxing) [10:59:50] <mru> they use DSPs and low-level accelerators [11:00:51] <lu_zero> spaam: one works the other is a bad excuse to show up your knowledge of latin [11:00:51] <ods15> so just fancy cpu functions, not proper decoding [11:01:15] <spaam> lu_zero: ok :) [11:01:28] * lu_zero is a bit critical regarding paludis [11:01:32] <mru> ods15: there are hw blocks doing things like transform and deblocking [11:01:39] <mru> sw tells them what to operate on [11:01:49] <ods15> ok [11:02:11] <ods15> i thought hardware decoding was more commonplace, i'm a bit surprised that it doesn't do it all [11:02:27] <mru> ods15: 80% of the work is done by dedicated hw [11:02:34] <mru> the sw is mostly glue [11:02:52] <ods15> yeah that's pretty convinient actually, supports a lot of codecs this way [11:03:11] <kshishkov> only if they are very similar [11:03:21] <kshishkov> for example, good luck with VPx [11:04:20] <ods15> depends on how generic the hardware functions are... i don't know any video encoding internals, i mostly expected them to be similar building blocks... [11:05:18] <kshishkov> yes, but it may be stone, brick or adobe [11:05:29] <ods15> :) [11:05:30] <mru> flash? [11:05:36] <av500> kshishkov: wood too [11:05:44] <ods15> different q :) how common are b frames on youtube flv's and the like? [11:05:56] <av500> depends [11:05:59] <ods15> (is youtube mp4 now? i'm never sure) [11:06:29] <kshishkov> ods15: youtube now uses your encoder [11:06:36] <kshishkov> with webm [11:06:49] <kshishkov> (or maybe they've stopped doing that already) [11:07:21] <ods15> kshishkov, my encoder is the vorbis encoder in ffmpeg :P i doubt they use that.. do you mean ffmpeg or mencoder? [11:07:28] <av500> vorbis [11:07:42] <av500> in ffmpeg [11:07:50] <ods15> oh, wait, what [11:07:53] <ods15> haha [11:08:27] <ods15> heh i've never heard of webm, looking at it now.. does anyone use it? i've actually never seen any html5 videos [11:08:34] <mru> lol [11:08:38] <ods15> err, any html5 webpages at all i mean [11:08:40] <mru> what rock have you been under? [11:08:50] <kshishkov> Negev desert rock, I think [11:08:55] <ods15> stone, concrete :P [11:09:16] <av500> mru: you think he missed much with html5 and wemb? [11:09:22] <ods15> i FIRST heard of html5 when i was hunting around for a new cellphone a few months ago! [11:09:24] <lu_zero> ods15: !! [11:09:30] <mru> av500: jsut surprised he hadn't heard of it [11:09:33] <lu_zero> you are alive! [11:09:45] <mru> lu_zero: it could be a zombie [11:09:47] <ods15> lu_zero, yes, shhh, they haven't gotten to me yet :P [11:09:48] <mru> in early stages [11:10:23] <lu_zero> mru: considering ods I'd consider him a changeling [11:10:52] <ods15> a what? [11:12:24] <lu_zero> http://whitewolf.wikia.com/wiki/Changeling:_The_Lost [11:12:32] <lu_zero> hi wbs [11:13:21] <ods15> kshishkov, i wonder if i can find out if they are really using my vorbis encoder.. that would be pretty cool.. do you know any webm videos on youtube? [11:13:30] <wbs> hi lu [11:14:27] <av500> ods15: http://googlesystem.blogspot.com/2010/05/how-to-play-webm-video-on-youtube.… [11:15:04] <ods15> sigh, webm is theora.. has theora gotten better? [11:15:13] <mru> is not [11:15:18] <mru> and has not [11:15:23] <ods15> (i am wildly out of date, "gotten better" i mean since several years ago) [11:15:27] <mru> wemb is vp8 [11:15:30] <mru> in matroska [11:15:52] <kshishkov> and vp8 is theora 2 [11:16:05] <lu_zero> kshishkov: nah [11:16:19] <kshishkov> lu_zero: just wait for Xiph move [11:16:28] <mru> vp8 magically made theora worse [11:16:37] <mru> theora use to be "as good as h264" [11:16:38] <lu_zero> kshishkov: then will be ffvp9 [11:16:51] <mru> not vp8 is "competitive with h264" [11:16:55] <mru> and also better than theora [11:17:09] <mru> rock, scissors, paper... [11:17:10] <av500> mru: theora was "good enough", vp8 is "gooder enougher" [11:17:35] <lu_zero> hammer? [11:17:45] <av500> RPG [11:18:18] <MrNaz_YMAtv> av500 is vp8 really comparable in quality to h264? that seems like quite a claim... [11:18:46] <lu_zero> MrNaz_YMAtv: depends on the encoder/settings etc [11:18:55] <lu_zero> it isn't that bad anyway [11:19:04] <av500> MrNaz_YMAtv: too H264 BP [11:19:07] <av500> MrNaz_YMAtv: to H264 BP [11:19:26] <MrNaz_YMAtv> av500 H264 BP ? [11:19:31] <av500> base profile [11:19:36] <MrNaz_YMAtv> is that the simple profile? [11:19:38] <MrNaz_YMAtv> aahyea [11:19:40] <av500> the one without the fun [11:20:01] <MrNaz_YMAtv> yep cool [11:20:02] <MrNaz_YMAtv> thanks [11:20:12] <MrNaz_YMAtv> any chance flash will get vp8 support ever ? [11:20:22] <av500> adobe said it would [11:20:26] <MrNaz_YMAtv> ooer nice [11:20:46] <MrNaz_YMAtv> final q... will vp8 support live streaming ? [11:21:12] <MrNaz_YMAtv> err... dumb q [11:21:14] <wbs> uh, that hasn't anything to do with the codec, it's just up to the live streaming protocols [11:21:21] <wbs> but mkv is streamable [11:21:51] <MrNaz_YMAtv> well.. id prefer to pack it into .flv for live streaming directly from studio to the web site [11:22:04] <ods15> hrm, this video isn't webm... /me tries to find another one [11:22:57] <MrNaz_YMAtv> i'm currently doing camcorder -> firewire port -> dvgrab -> ffmpeg -> flv -> ffserver running in datacenter -> flowplayer and that gives me a real time broadcast to web site [11:23:02] <av500> ods15: http://devfiles.myopera.com/articles/1891/custom-controls-webm-720p.html [11:23:11] <av500> from http://dev.opera.com/articles/view/opera-supports-webm-video/ [11:25:07] <ods15> is this a youtube video? [11:25:15] <av500> no [11:25:17] <ods15> i want to find a webm video from youtube [11:26:38] <ods15> hmm, need to download different firefox or opera for this [11:40:06] <KotH> hey ods15! [11:45:52] <ods15> hi KotH ! [11:46:32] <KotH> how come you ended up here? [11:47:13] <av500> KotH: apparently somebody lifted a rock [11:48:25] <ods15> i actually needed some info about cellphone video decoding... but now i'm obsessed on finding out if youtube uses my vorbis encoder :P [11:49:08] <mru> ods15: they did for a short while [11:49:09] <cartman> lo ods15 , your vorbis encoder still sucks man :-} [11:49:12] <cartman> hi! ;) [11:49:16] <mru> until someone told them how shit it was [11:49:45] <ods15> cartman, yes, i know it does suck [11:49:58] <ods15> mru, oh! can i find that conversation? it sounds awesom :) [11:50:00] <KotH> ods15: time to fix it then! [11:50:18] <mru> ods15: sorry, I don't know where any discussions took place [11:51:13] <CIA-99> ffmpeg: mstorsjo * r24350 /trunk/libavformat/ (asf.c asf.h): asf: Add asf_jfif_media guid [11:51:51] <ods15> oh, there's aomsething - http://xiphmont.livejournal.com/51160.html [11:51:53] <CIA-99> ffmpeg: mstorsjo * r24351 /trunk/libavformat/asfdec.c: asfdec: Handle asf_jfif_media [11:52:02] <ods15> anyway, thats cool enough for me :P [11:52:27] <KotH> ods15: how are your studies going? [11:52:35] <KotH> ods15: or did you switch again? ;) [11:53:19] <CIA-99> ffmpeg: mstorsjo * r24352 /trunk/libavformat/asfdec.c: asfdec: Don't read the video stream header if there isn't enough data [11:53:40] <ods15> still at physics/math [11:54:32] <mru> get onto dsp already! [11:55:14] <ods15> lol, i think this webm video i download IS my vorbis encoder :) it's vorbis, and it doesn't have the Xiph tag [11:55:20] <kshishkov> somebody from FFmpeg devs should know that stuff [11:59:08] <cartman> that explains the crap quality of webm videos? [11:59:09] <cartman> :p [12:00:19] <ods15> i actually feel kind of bad about this - http://xiphmont.livejournal.com/51160.html [12:00:23] <av500> the crap sound rubs on to the video? [12:00:36] <av500> ods15: dont [12:00:42] <ods15> ffmpeg using my sucky encoder on youtube does not bode well for vorbis [12:00:53] <kshishkov> ods15: relax, that guy designs containers worse than you write audio encoders [12:01:00] <ods15> lol [12:01:19] <ods15> av500, i actually somewhat blame ffmpeg, i was against using my encoder by default if libvorbis is compiled in [12:01:52] <kshishkov> now it won't [12:01:58] * mru blames those who allowed it to be committed in the first place [12:01:58] <av500> ods15: ah, ffmpeg and it's NIH syndrome.... [12:02:30] <ods15> kshishkov, yeah, i JUST read that it has been disabled by default, good move... [12:02:55] <av500> ods15: I still blame google for doing no QC on what they encode.... [12:03:16] <kshishkov> av500: does it makes any difference with input users provide? [12:03:31] <av500> no [12:03:35] <ods15> av500, yeah, i miswrote, it's bad PR for vorbis in general that ffmpeg does this, not specific to youtube [12:03:47] <av500> from the POV, they could have stayed with H263 for 99% of their content [12:03:54] <cartman> ods15: lol [12:04:01] <av500> the->that [12:08:41] <ods15> does flv1 have b frames? [12:09:26] <av500> the h263 variant? no IIRC [12:29:38] <ods15> is the h263 variant the one commonly used on youtube? [12:30:20] <ods15> any easy way i can see I/P/B statistics on a file? count or size, prefferably size [12:30:42] <ods15> i need on H264 files and FLV1 [12:31:15] <kshishkov> ffmpeg -loglevel 9 -i infile -f null [12:31:25] <lu_zero> ods15: use youtube-dl --all-formats [12:31:29] <lu_zero> and you'll fetch all [12:31:57] <lu_zero> youtube-dl --all-formats http://www.youtube.com/watch?v=d1_JBMrrYw8 [12:32:08] <lu_zero> with the latest youtube-dl [12:32:31] <ods15> hmm, i've already fetched all :) [12:32:40] <ods15> kshishkov, i'll try that :) [12:34:44] <ods15> ./ffmpeg: unrecognized option '-loglevel' ? wow i'mwildly out of date [12:34:51] <ods15> FFmpeg version SVN-r16061, Copyright (c) 2000-2008 [12:35:57] <ods15> kshishkov, it's not showing any ipb statistics that i can see... [12:52:21] <kshishkov> ods15: it's 2010 [12:52:40] <kshishkov> but in your case -v 99 may work [12:52:52] <mru> -v still works [12:53:22] <ods15> yeah i just ran svn update [12:53:37] <ods15> you'll notice i was about 8000 revisions out of date [12:55:37] <CIA-99> ffmpeg: mru * r24353 /trunk/tests/fate-run.sh: [12:55:37] <CIA-99> ffmpeg: fate: run diff even if command fails [12:55:37] <CIA-99> ffmpeg: The diff may provide useful information even if the command was [12:55:37] <CIA-99> ffmpeg: unsuccessful. The test is still treated as failed in this case. [13:04:28] <ods15> kshishkov, it's still not showing me any statistics.. i used '-loglevel 9', i'll try -v 99 [13:05:37] <ods15> heh, well, -v 9 shows more noise than -loglevel 9, but still nothing about p/b frames :( [13:08:26] <kshishkov> hmm, I remember that debug log level showed picture information [13:09:04] <CIA-99> ffmpeg: mstorsjo * r24354 /trunk/libavformat/asfdec.c: [13:09:05] <CIA-99> ffmpeg: asfdec: 10l, fix the minimum asf video stream header size [13:09:05] <CIA-99> ffmpeg: This fixes the regression test breakage. [13:09:25] <mru> wbs: thanks [13:15:29] <wbs> mru: thanks to you for pointing it out so quickly, too. saved potentially many minutes of embarrasment until I would have found out myself :-) [13:15:56] * mru keeps an eye on fate [13:17:11] <wbs> on that topic btw, I've got a fate in a screen somewhere, but it's only good for checking if the build has failed or not - it's testing the win ce build [13:17:52] <wbs> and I'm not really that into ce so that I would have set up some remote testing on such an emulator or something similar [13:23:49] <Honoome> wbs: the feng patch looks good, but still probably not 100% fixed [13:24:41] <wbs> Honoome: ok, what issue do you expect? [13:24:51] <Honoome> wbs: machine with _no_ public IPs ;) [13:25:11] <wbs> Honoome: umm.. how would you expect it to work then? :-) [13:25:19] <Honoome> NAT [13:25:37] <wbs> ah, well, it should work just as well as it did before at least [13:26:03] <Honoome> yeah no doubt about that :) it just came to me that it wouldn't work in that case [13:26:08] <Honoome> I'll turn yamato on and apply the patch [13:26:18] <Honoome> mru: any idea about having obj-$(CONFIG_NO_SMALL) or something? :P [13:26:32] <mru> $(!CONFIG_SMALL) [13:26:48] <wbs> well, the packets would be sent from the same IP as the client has connected to, whatever that is, so the nat can map that back in whatever way it wants [13:26:54] <Honoome> mru: it works? [13:26:58] <mru> of course [13:27:02] <mru> look in config.mak [13:27:16] <mru> ! is a valid character in make variables [13:27:24] <Honoome> I wasn't expecting it to, okay thanks :) [13:27:40] <mru> the configure system has many nice, undocumented functions [13:27:42] <Honoome> wbs: you'd have to mangle the RTSP stream for that to work, a configuration would help [13:53:33] <BBB> spyfeng: I'll apply your patches today, something went wrong yesterday so didn't get to it [13:57:10] <mchinen> how do I run a particular seek regression test? [13:57:25] <mru> mchinen: make fate-seek-foo [13:57:33] <mru> works since today [13:57:56] <mru> test dependencies are still a bit weird though [13:58:00] <mchinen> cool. [13:58:09] <mru> so it will insist on running the codec tests first [13:58:42] <Honoome> mru: confirmed that static linking works, will check the osx build in a moment [13:59:12] <mru> if you've already run those, you can skip them by using make -o fate-codec -o fate-lavf [13:59:20] <mru> Honoome: static linking of course works [13:59:34] <mru> or actually not of course [13:59:38] <mru> by luck [13:59:49] <mchinen> ok [13:59:57] <Honoome> by design more than luck :) and by symbolic dynamic linking works as well [14:00:04] <mru> Honoome: depends [14:00:15] <mru> is the table alone in an object file in both libs? [14:00:21] <Honoome> yep [14:00:27] <mru> then it of course works [14:00:45] <mru> if it's sharing file with something else it will only work if that file is linked first [14:00:52] <mchinen> I get messages like +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 8256 size: 614 [14:01:01] <mchinen> I guess these are reference errors? [14:01:03] <av500> wbs: ping [14:01:08] <mru> mchinen: what command did you run [14:01:22] <Honoome> mru: thus design ;) of course I was going to make it stand alone in the object file at that point [14:01:40] <wbs> av500: pong [14:01:40] <mchinen> mru: this is just 'make test' and its probably caused by my flac parser. [14:01:44] <mru> Honoome: I didn't know you'd moved the one in lavc to its own file [14:02:08] <Honoome> I told you on ML I think [14:02:09] <av500> wbs: you did that opencore amr stuff? [14:02:13] <wbs> av500: yeah [14:02:25] <av500> which is the lib as given by opencore from android no? [14:02:31] <mru> Honoome: maybe I didn't read carefully enough [14:02:48] <wbs> av500: not really [14:03:00] <av500> so what is it? [14:03:01] <wbs> av500: it's just the amr files ripped out from opencore, with enough wrapping to compile standalone [14:03:10] <av500> ok [14:03:15] <av500> thats what I meant [14:03:24] <av500> and what is the licence? [14:03:27] <wbs> apache 2.0 [14:03:39] <mru> mchinen: the seek test pass with svn head [14:03:46] <mru> mchinen: so it must be something you did [14:03:53] <mchinen> yes, but I don't know how to read the error. [14:04:01] <av500> wbs: a coworker tries to add it and comes up with gpl3? [14:04:05] <mru> it's a diff between the output and the reference [14:04:19] <wbs> av500: apache 2.0 is incompatible with (l)gplv2 if you read the fine print [14:04:31] <wbs> av500: but compatible with (l)gplv3, so you need to --enable-version3 for ffmpeg to be compatible with it [14:04:49] <av500> yes, thats what we get [14:05:03] <mru> btw, I want to rename that flag [14:05:07] <mru> version3 of what? [14:05:09] <mru> ffmpeg? [14:05:25] <wbs> good point [14:05:34] <siretart> FFmpeg 3.0 sounds kinda cool :-) [14:05:46] <pJok> ffgpl? [14:05:56] <wbs> do a slackware, jump a few major numbers just to be as cool as everybody else ;P [14:06:03] <mru> wbs: 7? [14:06:13] <kierank> ffmpeg karmic [14:06:16] <wbs> mru: yeah [14:06:17] <av500> wbs: so, i need to enable that flag, but what does that mean for the licence of the final ffmpeg? [14:06:30] <av500> assuming i dont include any gpl3 code [14:06:48] <mru> nobody knows [14:06:51] <wbs> av500: ask a good lawyer, or diego [14:06:59] <mru> a good diego [14:07:00] <av500> :) [14:07:04] <mru> so Honoome won't do [14:07:08] <wbs> :-) [14:07:16] <Honoome> mru: tsk :P [14:07:20] <av500> maradonna? [14:07:30] <av500> no, he lost.... [14:07:30] <Honoome> https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument what about this? [14:07:46] <av500> Honoome: "This Connection is Untrusted" [14:07:52] <Honoome> don't tell me [14:08:14] <wbs> theoretically, I guess you consider all the lgplv2+ code as lgplv3+ only, for that build, and have to abide to that version, even if the code itself initially was lgpl2 [14:08:19] * Honoome still can't understand EFF's insistence of moving the world toward exclusive ssl connections [14:08:30] <mru> wbs: somehow that doesn't make sense to me [14:08:50] <mru> Honoome: everybody has an agenda, that happens to be theirs [14:08:59] <wbs> av500: but if you want real progress - IIRC superdump said that he had heard from someone at packetvideo that said that they're ready to dual-license it to lgpl if it would make us happier [14:09:04] <mchinen> are parsers supposed to return the file header if encountered? [14:09:15] <superdump> yup [14:09:24] <av500> return inside a packet? [14:09:28] <superdump> i told them to send a message to the -devel mailing list iirc [14:09:33] <mru> mchinen: what kind of header? [14:09:38] <mru> flac header? [14:09:38] <mchinen> ok that must be it. [14:09:42] <mchinen> mru: yes [14:10:04] <mru> I don't think you're supposed to send the header to the parser [14:10:08] <av500> wbs: thing is, we already use the same code on the android side... [14:10:15] <av500> inside the same product [14:10:31] <mru> av500: legalese is fun, isn't it? [14:10:37] <wbs> yeah [14:10:40] <av500> sure [14:11:08] <mru> it's like one of these elaborate stories where someone ends up being his own uncle in the end [14:11:19] <wbs> also, since all the system libs are apache 2.0, is gplv2 userland code forbidden totally? or is that ok with gpl since they're system libs? [14:11:26] <wbs> and what if you consider opencore-amr a system lib? ;P [14:11:42] <mru> on that system I guess you could consider it that... [14:14:17] <CIA-99> ffmpeg: cehoyos * r24355 /trunk/ (10 files in 4 dirs): [14:14:17] <CIA-99> ffmpeg: Lego Mindstorms RSO muxer and demuxer. [14:14:17] <CIA-99> ffmpeg: Patch by Rafa?l Carr?, rafael d carre a gmail [14:14:54] <av500> CIA-99: utf-8 please [14:15:17] <Honoome> hah, cia and utf8 [14:15:39] <av500> Honoome: your fsf doc is tl;dr [14:15:44] <mru> av500: that's cia [14:15:48] <Honoome> not mine [14:15:59] <mru> right, you were shouting at cia [14:16:12] <av500> yes [14:16:14] <mru> thought you'd know by now that doesn't work [14:16:16] <CIA-99> ffmpeg: cehoyos * r24356 /trunk/doc/general.texi: FFmpeg never supported msmpeg4v1 encoding. [14:16:21] * mru kicks CIA-99 [14:16:21] <CIA-99> ow [14:18:47] <av500> D_IF_init() D_IF_decode() D_IF_exit(), what that DOS 8.3 function names? [14:19:24] <wbs> av500: well, that are the names of the original amr float sample code [14:21:06] <wbs> av500: if it is of any help to you, I can relicense the wrapper files to whatever license you want, including public domain. then you should be able to link that file into your binary, and just link against the libraries in the system, given that the function names the wrapper wants exist [14:21:54] <wbs> superdump: I'd appreciate if you'd remind him [14:22:13] <av500> wbs: im looking at libopencore-amr.c [14:22:20] <wbs> av500: ah [14:22:26] <av500> is that the wrapper? or is there another one? [14:22:51] <wbs> libopencore-amr itself contains a small wrapper that emulates that interface, using the functions that actually exist in opencore [14:23:18] <av500> wbs: I will have a look [14:23:49] <wbs> av500: http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/openc… [14:24:12] <j-b> funman? [14:24:22] <av500> j-back from vacation? [14:24:38] <wbs> av500: hmm, I'm not sure if I'm legally able to relicense the one for amrwb, though, if you want that one, http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/openc… [14:25:06] <av500> wbs, apche is fine for me [14:25:20] <j-b> av500: yes [14:26:02] <superdump> av500, wbs : his main focus was getting the code merged into ffmpeg [14:26:20] <superdump> i had told him that merging library code into ffmpeg was not common practice [14:26:28] <superdump> but perhaps it might be interesting [14:26:37] <superdump> if the license were ok and so on [14:26:38] <mru> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44958 [14:26:38] <wbs> yeah, that's a pity. but using it in general would be less problematic with lgpl anyway [14:26:38] <av500> GSMInitDecode(&ptr, (int8*)"Decoder"); ..... [14:26:46] <superdump> but he should discuss it with a wider audience [14:26:59] <av500> they have to relicence to lgpl anyway [14:27:01] <superdump> and so he said that they could relicense it as lgpl if that would help move things along [14:27:04] <superdump> right [14:27:09] <av500> before it could be merged [14:27:15] <Honoome> what the heck? I can't send email through gmail today? [14:35:18] <mchinen> how are the ref files generated for flac if there was no parser? [14:35:52] <av500> magic [14:36:13] <mru> /dev/random [14:36:57] <mru> mchinen: note that the ref fails on all seeks [14:37:15] <mru> so it probably should change [14:38:05] <mchinen> mru: the ref should change? [14:38:15] <mru> if you made seeking work, yes [14:39:55] <mchinen> ok, then i should probably verify that the ts is actually sample accurate through a different test before putting a ref in. [14:45:12] <BBB> mru: do you have x86-64 somewhere? [14:45:26] <mru> I have a few [14:45:45] <BBB> one with gdb, gcc, shell accounts for hungry developers? [14:45:53] <BBB> I'm using josh's right now, but it doesn't have gdb [14:45:53] <BBB> :-p [14:46:28] <mru> I suppose I could give you an account on one of mine [14:46:36] <mru> do you have one on the ppc already? [14:46:38] <BBB> no [15:00:14] <CIA-99> ffmpeg: rbultje * r24357 /trunk/libavformat/mmst.c: [15:00:15] <CIA-99> ffmpeg: Send a time test to the server, as the spec recommends. [15:00:15] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [15:01:59] <CIA-99> ffmpeg: rbultje * r24358 /trunk/libavformat/mmst.c: [15:01:59] <CIA-99> ffmpeg: Check the status code of each server responses, and fail if it indicates [15:01:59] <CIA-99> ffmpeg: a problem. [15:01:59] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [15:06:37] <CIA-99> ffmpeg: rbultje * r24359 /trunk/libavformat/mmst.c: [15:06:37] <CIA-99> ffmpeg: Fix a compile warning when compiling with DEBUG=1. [15:06:37] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [15:08:27] <CIA-99> ffmpeg: rbultje * r24360 /trunk/libavformat/mmst.c: [15:08:27] <CIA-99> ffmpeg: Align outgoing messages to 8 bytes, this is required to interact with [15:08:28] <CIA-99> ffmpeg: most servers. Also remove a case where we manually aligned to 8 bytes, [15:08:28] <CIA-99> ffmpeg: since this is now no longer needed. [15:08:28] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [15:09:43] <CIA-99> ffmpeg: vitor * r24361 /trunk/libavcodec/atrac3.c: Fix memory leak in ATRAC3 decoder [15:12:37] <CIA-99> ffmpeg: rbultje * r24362 /trunk/libavformat/mmst.c: [15:12:37] <CIA-99> ffmpeg: Explicitely set the size of the "ff_asf_head1_guid" header chunk, this is [15:12:37] <CIA-99> ffmpeg: part of the spec and causes problems otherwise. [15:12:37] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [15:15:06] <CIA-99> ffmpeg: rbultje * r24363 /trunk/libavformat/mmst.c: [15:15:06] <CIA-99> ffmpeg: Allow the ASF header to be transferred split over multiple packets, as some [15:15:06] <CIA-99> ffmpeg: servers happen to do. For this, we also move several header-size-related [15:15:06] <CIA-99> ffmpeg: variables to the MMSTContext. [15:15:06] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [15:57:24] <synapsepg> hello ... this might sound odd ... but has anyone managed to build the ffmpeg-0.6 for WinCE >= 6.1 [15:59:57] <synapsepg> cause I'm struggling with two ARM build chains, and they both fail, at linking stage of libavcodec [16:00:05] <lu_zero> BBB: if you still need I could give an access as well [16:00:28] * av500 winces [16:24:11] <CIA-99> ffmpeg: stefano * r24364 /trunk/libavfilter/vsrc_buffer.c: Add @file doxy. [16:24:11] <CIA-99> ffmpeg: stefano * r24365 /trunk/libavfilter/vsrc_buffer.c: Apply misc cosmetical style fixes. [16:26:08] <DonDiego> mru: the build system should run 'make config' if allcodecs.c/allformats.c/etc. have been modified [16:26:29] <DonDiego> it's annoying to see the build fail because of a definition missing from config.h [16:27:08] <DonDiego> i'm thinking what would be the best way to achieve it [16:27:08] <av500> mru: now a good diego is there? [16:27:14] <DonDiego> ? [16:27:27] <mru> I've thought of the same thing [16:27:33] <mru> just not been too bothered by it [16:27:47] <DonDiego> automake does it :) [16:27:53] <mru> which is annoying as hell [16:27:59] <mru> becuase it generally breaks something [16:28:00] <DonDiego> we should be at least equally good.. [16:28:02] <av500> DonDiego: http://ffmpeg.pastebin.com/7zmFPMM6 [16:29:05] <DonDiego> please [16:29:14] <DonDiego> at least spell the man's name correctly: maradona [16:29:22] <mru> DonDiego: anyway, I'll fix it [16:29:36] <DonDiego> av500: what were you doing? [16:29:51] <av500> trying to use libopencore_amr with lgpl ffmpeg [16:30:04] <av500> which needs enable-v3 [16:30:05] <DonDiego> the end result is lgpl v3+ [16:30:09] <av500> yes [16:30:18] <DonDiego> what was your question then? [16:34:37] * /join #ffmpeg-devel ... [16:34:39] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged. [16:34:39] *** TOPICINFO: peloverde!~alex(a)cpe-173-88-148-20.neo.res.rr.com, 1276886498 [18:16:13] * /join #ffmpeg-devel ... [18:16:15] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged. [18:16:15] *** TOPICINFO: peloverde!~alex(a)cpe-173-88-148-20.neo.res.rr.com, 1276886498 [18:21:15] <mru> DonDiego: btw, you have your automatic reconfigure now [18:21:57] <Dark_Shikari> awesome! [18:34:20] * DonDiego looks [18:35:31] <DonDiego> great! [18:36:04] <DonDiego> .config needs to be added to svn:ignore though [18:36:20] <DonDiego> will add it in a moment [18:36:37] <DonDiego> and i will shamelessly copy it for mplayer :) [18:38:05] <mru> you may copy it, but only if you feel a little shame [18:38:31] * mru introduces the Shame Licence [18:38:43] <mru> do whatever you want, provided you feel shameful doing it [18:39:14] <kshishkov> aka Conscient Ripoff License [18:42:53] <DonDiego> nah, i'm a shameless person generally.. [18:43:17] * kshishkov adds that to his stereotypes about Argentinians [18:43:23] <mru> guess I'll have to add a diego exception clause [18:43:32] <kierank> but then it won't be gpl compatible [18:43:52] <kshishkov> add Stallman exception clause too and it will [18:43:58] <mru> the diego exceptino makes no difference in that regard [18:44:44] <DonDiego> it would become compatible if i died [18:44:50] <mru> no [18:44:51] <DonDiego> since then the exception would be void [18:44:55] <mru> it's not compatible to begin with [18:45:03] * DonDiego starts getting paranoid [18:45:09] <mru> the shame requirement is incompatible [18:45:21] <CIA-99> ffmpeg: diego * r24371 /trunk: Ignore .config file. [18:58:02] <peloverde> How do people feel about fixed point? [18:59:29] <peloverde> Somebody with some money approached me about fixedpoint aacdec [19:00:09] <_av500_> take it? [19:00:16] <mru> I don't think anyone is fundamentally opposed to it [19:00:52] <kierank> only audiophiles are opposed to it [19:00:53] <peloverde> Do people like the approach used for MP3? [19:01:08] <mru> it's a hack [19:01:11] <peloverde> (which I realize was fixed point first) [19:02:05] <peloverde> I've done pure fixed point before but I've never done a single codebase supporting both [19:02:46] <BBB> peloverde: it's supposedly easier to maintain [19:02:54] <mru> huh? [19:03:20] <BBB> enter: the era of disagreement [19:03:24] <mru> shared code quickly turns into macro hell [19:03:33] <Dark_Shikari> It's not unreasonable to do both [19:03:37] <Dark_Shikari> it's a bit of macroing yeah [19:03:40] <Dark_Shikari> but it's not insane [19:03:50] <twnqx> template it [19:03:51] <mru> the mp3 decoder is done in a very ugly way [19:03:52] <twnqx> oh, wait... [19:03:59] <mru> twnqx: same thing [19:04:05] <Dark_Shikari> of course this could be resolved with C++ [19:04:09] <Dark_Shikari> and operator overloading [19:04:15] <mru> operator overlording [19:04:53] <kierank> that's presumably some kind of air and sea assault on europe in c++? [19:05:17] <Dark_Shikari> spawn more overlords [19:05:21] <mru> that's what c++ feels like [19:05:27] <mru> an assault [19:05:33] <mru> one you're on the wrong side of [19:06:34] <CIA-99> ffmpeg: mru * r24372 /trunk/configure: configure: create .config file in configure to avoid needless reruns [19:07:02] <peloverde> I was thinking about trying to macroize the AAC code but using the tremor IMDCT [19:07:23] <peloverde> but it looks like av_fft was written with some sort of fixedpoint conversion in mind [19:07:33] <mru> a fixed-point version of our mdct would be awesome [19:07:52] <mru> peloverde: I think that left the mind just after the typedef was written [19:09:09] <mru> that sort of typedeffing is useless imo [19:09:16] <mru> we'll want both float and fixed-point anyway [19:09:22] <mru> they're not mutually exclusive [19:09:48] <peloverde> I'm not opposed to a fixed point version of our MDCT but I don't want to do it [19:10:06] <mru> it would probably be much faster than tremor's [19:11:12] <peloverde> What about the RockBox IMDCT [19:11:14] <peloverde> it is LGPL [19:11:20] <mru> how fast is it? [19:11:27] <Yuvi> rockbox's is derived from ours [19:11:38] <Yuvi> iirc they're trying to port it to tremor [19:11:46] <mru> that's what we're looking for then [19:12:10] <mru> if by derived you mean using the same split-radix algorithm [19:12:19] <Yuvi> yeah, they started from our C code [19:12:47] <peloverde> "Copyright (c) 2002 The FFmpeg Project" [19:13:01] <peloverde> that seems too old? [19:13:07] <peloverde> did we do split-radix in 2002? [19:13:10] <mru> no [19:13:15] <Yuvi> I know they also did the older one to fixed point [19:13:34] <mru> just make sure it's the split-radix one [19:13:40] <mru> anyway, wishlist time [19:13:49] <mru> I'm doing things to the test system [19:14:40] <peloverde> mt: ping? [19:15:08] <mru> aim is to make something more managable than mike's fate [19:16:09] <mru> so far I can run all the tests and produce a report file with all the results [19:20:13] <spaam> good :) [19:20:19] <DonDiego> sounds good [19:20:37] <DonDiego> bbl [19:25:29] <peloverde> The FFT that runs under the MDCT says "Copyright (c) 2008 Loren Merritt" :) [19:25:37] <peloverde> What about a new fate server? [19:26:34] <mru> that's part of the plan [19:26:44] <mru> infrastructure is not the issue here [19:27:01] <mru> but now would be a good time for bright ideas on what to include [19:27:49] <peloverde> I was thinking rather than using SQLite as the wire format maybe we should use some sort of structured text? [19:29:42] <Kovensky> YAML? [19:30:14] <peloverde> I was thinking YAML or JSON [19:31:13] <mru> for the report I'm using a simple text format [19:31:17] <mru> one line per test [19:31:22] <mru> values separated by : [19:31:37] <Honoome> mru: the reason why I wanted to use it cross-directory was to make it buildable once only [19:31:41] <mru> field with arbitrary content base64-encoded [19:31:50] <peloverde> ok, that seems to make sense [19:31:52] <mru> Honoome: I understand that [19:32:03] <mru> Honoome: but I don't like it [19:32:03] <Honoome> and also, using symlinks wouldn't work [19:32:07] <mru> I know [19:32:09] <Honoome> mru: any suggestion? [19:32:16] <mru> #include it in lavc [19:32:27] <saintdev> peloverde: http://uazu.net/fiview/ [19:32:42] <Honoome> it still has to be on its own object [19:32:46] <mru> yes [19:32:47] <peloverde> saintdev: very nice [19:32:59] <mru> Honoome: so a one-line file #including the other one [19:33:10] <mru> no, it's not terribly pretty [19:33:11] <Honoome> hrm not elegant but would work [19:33:28] <mru> but pulling in objects across libs is dodgy [19:34:40] <mru> "compile" time is negligible anyway [19:35:17] <peloverde> mru: I'd like the concept of a configuration to be a little more clear, in the past we had failures that we though were OS specific but turned out to be hardware specific [19:36:25] <mru> arch, cpu, os, compiler [19:36:28] <mru> anything else? [19:36:50] <peloverde> assuming cpu is specific enough that should be sufficient [19:37:02] <mru> whatever is passed to --cpu [19:37:32] <peloverde> I want to know what the machine's mm_flags are [19:37:55] <peloverde> That shows what codepaths get taken [19:43:00] <Honoome> add uname -a output if uname exists [19:43:24] <CIA-99> ffmpeg: mru * r24373 /trunk/configure: configure: create .config file where I intended [19:43:53] <mru> Honoome: that's $arch [19:44:03] <Honoome> -a not -m? [19:44:18] <mru> sorry [19:44:21] <mru> right [19:44:22] <mru> good point [19:44:39] <Honoome> -a should tell you the cpu trade name [19:44:43] <Honoome> even though it's not perfect [19:44:56] <mru> not quite [19:45:03] <Honoome> fgrep flags /proc/cpuinfo | head -n1 ? [19:45:06] <mru> -a is equivalent to -mnrsv [19:45:22] <mru> anyway, this won't do any good at all for the cross-builds [19:46:44] <mru> hmm, gnu uname prints more stuff [19:47:08] <Honoome> Linux saladin.local 2.6.34.1 #10 SMP PREEMPT Mon Jul 5 22:31:17 CEST 2010 x86_64 Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz GenuineIntel GNU/Linux [19:47:24] <mru> I know what it looks like [19:47:29] <peloverde> My uname -a says "Linux <hostname> 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux" [19:48:30] <peloverde> "uname (GNU coreutils) 7.4" 7.4-2ubuntu2 [19:49:05] <Honoome> 8.5 here [19:50:01] <peloverde> wow, I'm kind of surprised ubuntu is still on 7.4 [19:50:14] <mru> 8.5 here too [19:58:59] <peloverde> janneg: LATM ping? [20:00:09] <Honoome> mru: sent with the #include hack [20:07:40] <wbs> BBB: btw, do you have time to check the rtsp-ms patch I sent yesterday? [20:16:41] <mt> peloverde: pong [20:17:13] <peloverde> mt: Looks like I managed to answer my own question in the interim, sorry [20:17:26] <mt> no problem :) [20:17:44] <peloverde> but it does look like I will be porting the rockbox fixed point IMDCT/FFT to FFmpeg :) [20:18:32] <mt> Nice ! :) [20:18:48] <pJok> ffrockbox? [20:19:02] <peloverde> more like fffixedpointaudio [20:22:23] <BBB> wbs: not yet, it looked weird when I briefly looked at it [20:22:25] <BBB> so needs more time [20:23:24] <wbs> BBB: ok, it should be quite straightforward I think, so take your time :-) [20:26:59] <_av500_> http://www.fsf.org/tasks/noscript [20:28:02] <Honoome> ... [20:28:29] <Honoome> there's nothing more important than that to waste their time with on the web? [20:48:34] <CIA-99> ffmpeg: vitor * r24374 /trunk/tests/fate2.mak: WMAVoice regtests [20:49:57] <mru> Vitor10011: I see you understood how to use the new test functinos [20:51:59] <Vitor10011> mru: Sure! [20:52:29] <Vitor10011> mru: I also tested to see if really 2.4 and 2.6 are really interpreted as different numbers ;) [20:52:38] <mru> of course they are [21:01:47] <mru> btw, have you guys seen the comments on my latest blog post? [21:02:27] <Honoome> which one is it? [21:02:37] <mru> the inline asm [21:03:25] <_av500_> mru: nobody called an idiot yet... [21:03:54] <mru> the gcc guy is getting angrier... [21:05:41] <_av500_> you know my take on this, arm does not seem to be interested in having a good and free compiler [21:05:58] <mru> s/arm/gnu/ [21:06:04] <_av500_> no, arm [21:06:11] <_av500_> arm wants to sell stuff [21:06:22] <Honoome> mru: you know, they are always volunteer, even when they are paid by RedHat, Canonical, ... [21:06:36] <mru> Honoome: yes, that's what pisses me off [21:06:42] <Honoome> too bad I can't volunteer to be paid by them :P [21:06:52] <_av500_> have you tried? [21:07:57] <Honoome> _av500_: the only thing that ever made someone interested in hiring me (pulseaudio) got me an interview with canonical, but then it drifted apart 'cause of my health [21:08:51] <_av500_> ic [21:09:05] <mru> are you blaming them for your health troubles? [21:09:06] <mru> :-) [21:10:22] <Honoome> mru: no I could blame gentoo for part of it though [21:11:01] <Vitor10011> mru: What was again your reason why it was not possible to have a clean (documented in the C spec) syntax for inline asm? [21:11:34] <mru> I don't recall giving such a reason [21:11:48] <Vitor10011> mru: I think I asked you in IRC once... [21:12:04] <mru> although the way the C language is defined it would be rather hard [21:12:10] <Vitor10011> Why? [21:12:38] <mru> not everething is a von neumann machine [21:14:00] <Vitor10011> In what sense? (ie, where would it break?) [21:14:45] <mru> the best you could do is set aside a keyword, e.g. asm, and leave the contents unspecified [21:15:10] <Honoome> I guess you might not even emit asm at all in some cases [21:15:25] <mru> what if you're targeting a turing tape? [21:15:50] <mru> or anything else without a standard register/alu model [21:16:31] <Vitor10011> mru: Well, in that case you need a special machine-specific syntax to say what is cloberred, but that's it. [21:16:48] <mru> everything is machine-specific [21:17:40] <_av500_> i guess that is why you write asm per cpu arch [21:17:52] <mru> exactly [21:18:25] <Vitor10011> The fact of having some syntax for ASM should be required for a future C spec and for all existing archs the machine-specific stuff should be defined. [21:18:51] <_av500_> no [21:18:53] <hyc> what's wrong with the way gcc inline asm works? specify input registers, clobbers ... [21:18:56] <_av500_> eroops [21:18:59] <_av500_> ooops [21:19:05] <_av500_> the no was not for here :) [21:19:28] <mru> gcc syntax works fine for gcc [21:20:16] <mru> with a differently designed compiler it might not be possible to use that model [21:25:07] <hyc> well, if your compiler doesn't let you write in terms of input registers and output registers then you probably can't embed ASM code in it anyway [21:26:02] <_av500_> the compiler passes asm to the assembler [21:28:46] <mru> some compilers do [21:28:49] <mru> not all [21:29:18] <mru> some generate machine code directly from the optimised parse tree [21:29:50] <mru> I've come across bizarre compiler bugs that only showed up when producing an object file [21:30:00] <mru> requesting asm output made it go away [21:33:37] <_av500_> gee [21:39:34] <BBB> Dark_Shikari: I found it [21:39:39] <BBB> Dark_Shikari: you'd never believe where it was [21:39:49] <BBB> Dark_Shikari: it was a 32bit'ism in WRITE_4x4D :'( [21:40:31] <Dark_Shikari> :( [21:40:34] <Dark_Shikari> gj [21:40:51] <mru> what was it? [21:41:09] <_av500_> mru: *it* [21:45:47] <BBB> mru: mov [mem], reg [21:45:52] <BBB> instead of mov [mem], regd [21:46:07] <BBB> once you see it, you go like "oh, of course" [21:47:03] <mru> I prefer machines where access size is part of the instruction name [21:47:11] <mru> more obvious that way [21:48:28] <Honoome> auuuugh [21:51:33] <hyc> you could just write your assembler that way regardless [21:51:52] <hyc> isn't that standard in MIT syntax? [21:51:53] <twice11> Could "mov.l [mem], reg" have prevented the semantic change? [21:52:04] <twice11> Oh, without the dot, sorry. [21:52:45] <twice11> Might break compilation on 64 bit, but that would have helped here. [21:52:51] <BBB> maybe [21:52:57] <BBB> but I didn't [21:54:55] <twice11> mru: There once was a bug in Borland's 16-bit C++ compiler that made it generate an invalid instrution internally. [21:55:23] <twice11> In default mode, it directly writes an object file and used "DI" at a place where it didn't make sense. [21:55:27] <mru> gcc can do that too [21:55:38] <mru> make the assembler choke [21:55:41] <CIA-99> ffmpeg: skal * r24375 /trunk/libavcodec/libvorbis.c: remove an unneeded av_realloc() [21:55:47] <twice11> In the generate-asm mode, the operand was missing and the assembler complained. [21:56:34] <mru> if avr32-gcc is compiled with x86-gcc-4.3 it spits out invalid asm syntax [21:56:40] <mru> when compiling libgcc [21:57:33] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/FTc7Mzhe [21:58:04] <BBB> Dark_Shikari: tested on core1 with mmx-only, mmx2-only, sse2(forced) x86-32 and on x86-64 (sse2 only), bitexact on all [21:58:07] <BBB> Dark_Shikari: ok to apply? [21:58:12] <Dark_Shikari> don't see why not [21:58:25] <BBB> yesterday, you told me "no more commits" ;) [22:02:28] <Dark_Shikari> you tested it didn't you? [22:02:35] <Dark_Shikari> I said no commits until you test on x86_64 [22:02:39] <Dark_Shikari> you did [22:02:40] <Dark_Shikari> so commit it [22:03:09] <CIA-99> ffmpeg: mru * r24376 /trunk/configure: configure: make sh_quote() more robust [22:05:15] <CIA-99> ffmpeg: rbultje * r24377 /trunk/libavcodec/x86/ (vp8dsp.asm vp8dsp-init.c): Chroma (width=8) inner loopfilter MMX/MMX2/SSE2 for VP8 decoder. [22:19:33] <Honoome> mru: does the latest patch look good for you? [22:23:31] <mru> why do you include intmath.h? [22:35:15] <peloverde> I have the worst electric company ever [22:49:00] <Honoome> mru: to make sure to have its declaration and that it does not get mistaken [22:49:46] <mru> ah ok [22:50:11] <mru> then I'm ok with the patch [22:50:33] <Honoome> okay, I'll still wait till tomorrow just to be on the safe side [22:52:29] <Honoome> mru: out of curiosity, is there any dvb-s/mhp provider in the uk that beams encrypted bbc? [22:52:48] <mru> sky? [22:53:07] <kierank> all fta [22:53:08] <mru> they're not mhp though [22:53:18] <mru> is sky fta for bbc? [22:53:22] <kierank> yes [22:53:32] <mru> didn't they use to encrypt everything just because? [22:53:48] <Honoome> hrm on which sat are they? they don't seem to be on fta where sky ita also is [22:53:52] <kierank> because of "rights". however now they use astra 2d which is focused on britain [22:53:55] <Honoome> only bbc news is here [22:54:04] <Honoome> ah there is the trick, astra :/ [22:55:34] <BBB> Dark_Shikari: register saving done so pw_63 is now always in a reg, mmx-m8-15 references removed, tested on x86-64, anything else I should do before I can commit this? [22:55:42] <kierank> might be a few regions on one of the european footprint birds, i forget though. [22:56:04] <BBB> once this is committed, I'll work on getting performance charts on x86-64 also, maybe optimize the few cases where ssse3/sse4 helps [22:56:15] <Dark_Shikari> ok [22:56:17] <Dark_Shikari> commit that [22:56:24] <Dark_Shikari> the x86_64 box has ssse3 right? [22:56:25] <BBB> (pextrw, more register saving by splitting out sse2 functions from mmx-looped ones, etc.) [22:56:34] <Dark_Shikari> so you can do pshufb with the SPLAT, and you can do the pmaddubsw trick I mentioned [22:56:36] <BBB> it has everything, it seems [22:56:38] <BBB> yes [22:57:16] <Honoome> kierank: if they make use of the satellite reach, unlikely that anything arrives here, too "southern"... I was hoping to get some decent programmes here >_< sigh [22:57:48] <mru> proxy through the uk and use iplayer [22:58:15] <kierank> there are unofficial streams out there [22:58:21] <kierank> some of which are pretty decent quality [22:58:52] <Honoome> unfortunately I'd rather avoid streaming as my line is already slow by itself :| [22:59:09] <kierank> if you buy a 2+m dish you might be lucky [22:59:28] <Honoome> from italy? I'd doubt that :| [22:59:49] <mru> mount it on a ship in the channel [22:59:59] <kierank> people do it in southern spain so it might be possibly in italy [23:00:16] <Honoome> and at that point I might as well just get a sky subscription, even just the "fox" channels (tv series) would be worth it from one point of view [23:01:03] <kierank> there are maps out there that show what dish sizes you need for 2d [23:01:30] <Honoome> [watching anything dubbed in Italian when the original is english gives me the creeps nowadays] [23:01:33] <kierank> the official footprint maps aren't necessarily correct [23:03:52] <kierank> Honoome: http://www.astra2d.com/italy.html [23:05:44] <Honoome> hmm if it reaches bologna it might well reach here (bit norther), thanks! :) I'll keep this around, might not be too soonish (A/C comes first) but I'll take a look ;) [23:20:01] <BBB> how do I see the tree that a git repo came from? [23:20:17] <mru> uh? [23:20:24] <BBB> i.e. if I want to pull from a tree on another computer but I'm too lazy (or cannot find) where the tree was on the first computer [23:20:35] <BBB> svn info displays this [23:20:40] <mru> git config -l [23:21:10] <mru> note that a git repo can have any number of remotes defined [23:21:31] <mru> which is very useful at times [23:22:39] <Honoome> git remote -v [23:22:50] <BBB> thanks, git config -l had it [23:23:19] <mru> config displays everything [23:23:28] <mru> remote only some informat [23:23:35] <mru> ion [23:33:55] <BBB> let's see how x86-64 performs [23:34:36] <Dark_Shikari> you should go through and do the easy-mode ssse3 stuff first [23:34:41] <Dark_Shikari> well, before other optimizations that is [23:35:59] <BBB> I will, I just want to see how it compares, roughyl [23:36:17] <BBB> on Core1 we're clearly faster now, by about 10-15% [23:36:29] <Dark_Shikari> that might just be because livpx is dumb [23:36:33] <Dark_Shikari> and uses sse2 asm [23:36:58] <BBB> right, so I want to test our current state on a real cpu [23:37:57] <Dark_Shikari> k [23:41:01] <BBB> C: 1min47sec, SIMD: 52sec, libvpx: 50sec [23:41:09] <BBB> not bad, but we can do better [23:42:05] <spaam> so libvpx is faster [23:42:06] <Dark_Shikari> so the reason we beat them on core1 is smarter asm function picking. [23:42:12] <Dark_Shikari> spaam: it likely depends on the test clip and cpu [23:43:12] <BBB> they have a lot of sse2/ssse3/sse4 asm [23:43:31] <BBB> I think our mmx* asm is better, maybe our sse2 is on-par, but we don't have enough ssse3/sse4 asm, as you said [23:43:39] <BBB> and it can be made a lot more optimal in some cases [23:43:50] <BBB> (because mmx loops, sse* doesn't) [23:44:27] <BBB> so I'll work on using pmaddusbw, pextrw, better use of registers in no-loop functions, etc. [23:47:47] <Dark_Shikari> pshufb [23:47:49] <Dark_Shikari> pshufb [23:47:50] <Dark_Shikari> pshufb [23:58:37] <BBB> oh yes pshufb for the splatbreg [23:58:38] <BBB> :-p [23:58:54] <BBB> I have a list of this somewhere, I won't forget, I think [23:59:27] <Dark_Shikari> and everything else [23:59:30] <Dark_Shikari> pshufb is just plain pure awesome

1 0

IRC log for 2010-07-19
by irc＠mansr.com 20 Jul '10

20 Jul '10

[00:39:56] <peloverde> Is this grammar shit really still being discussed?! [00:57:49] <saintdev> peloverde: how are input samples laid out? interleaved for each channel? [00:58:03] <peloverde> yes [00:59:06] <saintdev> well it seems stereo is at best broken, and anything more is fubar :P [00:59:40] <peloverde> yes, stereo has issues [00:59:43] <saintdev> la = samples2 + (448+64) * avctx->channels + start_ch; [00:59:51] <saintdev> peloverde: what is the 448+64 for? [01:00:18] <peloverde> read the commit message in the blame log for that line [01:01:18] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=08bffe794ed67c24b49ae3c805c0… [01:01:37] <saintdev> also, start_ch gets added twice [01:01:47] <saintdev> samples2 already is offset by start_ch [01:02:10] <peloverde> good catch [01:02:22] <saintdev> peloverde: so what is the 64 about then? [01:03:03] <peloverde> First short window begins at 448 [01:03:20] <peloverde> short window length is 256 [01:03:26] <peloverde> quarter window is 64 [01:03:52] <saintdev> yeah, didn't the entire message because of gitweb making it the title [01:03:58] <saintdev> didn't notice [01:06:37] <saintdev> peloverde: also, inside psy_3gpp_window where the iir is calculated, la is indexed as: [01:06:40] <saintdev> la[(i*128+j)*ctx->avctx->channels] [01:06:56] <saintdev> which doesn't take into account the current channel [01:07:25] <peloverde> The current channel is already taken into account in the la base pointer (twice even as we just discussed) [01:07:37] <saintdev> no, start_ch is, but the current channel is not [01:08:04] <saintdev> so for stereo start_ch is always 0 [01:08:31] <saintdev> but then we loop over the individual channels calling suggest_window for each one [01:08:52] <saintdev> but la is not adjusted for the current channel in aacenc, or aacpsy [01:09:11] <peloverde> The call to to ff_psy_suggest_window() is buggy then [01:09:40] <peloverde> That whole section is still mostly wrong for multichannel as previously discussed [01:10:20] <saintdev> so would it be better to offset la in aacenc, or inside suggest_window? [01:10:28] <peloverde> in aacenc [01:25:03] <saintdev> argh, samples2 isn't offset by the current channel either :/ [01:25:11] <saintdev> not that it's used in the current code :P [01:45:49] * Honoome starts to have a huge headache and a tremendous feeling for destruction [01:50:18] <saintdev> peloverde: check ML [01:56:11] <peloverde> Doesn't that break apply_window_and_mdct()? [02:01:03] <saintdev> ugh, yes. [02:01:31] <peloverde> IMHO apply_window_and_mdct() shouldn't take an offset [02:02:03] <saintdev> which means it can be simplified [02:02:07] <peloverde> yes [02:13:13] <saintdev> peloverde: this look correct: http://pastebin.org/403836 [02:23:10] <peloverde> yes [02:24:26] <peloverde> but the patches should be applied seperately so one of the apply_window_and_mdct() lines is wrong (either the before or the after depending on which patch is applied first) [02:25:29] <saintdev> eek, almost hit send, LOL [02:32:34] <peloverde> Whatever the outcome, the apply_window_and_mdct() patch should be a pure refactor with identical output [02:44:50] <saintdev> peloverde: do you mean make it so the change of the function definition is in the other patch? [02:45:24] <peloverde> I mean before and after the MDCT patch the outputs hould be identical [02:45:33] <peloverde> *output should [03:17:31] <saintdev> did i break something then? [03:17:42] <saintdev> i get different results before and after, but that is because it decides on different window types. [03:18:06] <saintdev> everywhere it uses the same window types the coefficients are identical [03:31:33] <peloverde> There are two patches, but only one should change output [03:34:27] <peloverde> the MDCT refactor patch should be a pure recfactor patch that changes nothing [03:54:34] <saintdev> peloverde: http://pastebin.org/404016 [03:57:18] <jenk> o hi [03:57:40] <peloverde> saintdev: That's moving in the wrong direction [03:58:32] <peloverde> now you have a patch that plays with both at the same time [03:59:05] <peloverde> Take the MDCT patch you had, which was almost perfect and just make it a pure refactor [04:03:24] <peloverde> All you have to do is change the function call to make it clean [04:10:16] <saintdev> i will have to modify both at some point to not change output [04:15:32] <saintdev> if i add the current channel to samples2 i will have to change apply() to not add the offset itself [04:16:14] <saintdev> if i don't add the current channel, then the next patch when i do i'll have to modify apply() [04:18:23] <peloverde> just add the offset to the bae pointer [04:19:41] <peloverde> *base pointer [04:19:52] <saintdev> erm, wtf was i thinking, LOL [04:28:48] <saintdev> peloverde: http://pastebin.org/404082 [04:29:14] <saintdev> think i need to smack my head on my desk a few times for that one :P [06:15:26] <thresh> moroning [06:19:15] <av500> +1 [06:19:33] * kshishkov thinks it's rather nice and lovely morning [06:19:43] <mru> mornings [06:19:52] <kshishkov> goda morgnar [06:50:13] <av500> mru: http://wanderingcoder.net/2010/06/02/intro-neon/ [06:54:45] <mru> I disagree with his conclusion [06:54:59] <mru> neon is much easier to use than sse or altivec [06:55:25] <mru> lack of a SAD instruction isn't the end of the world [06:56:29] <funman> lack of SAD should make people HAPPY [07:02:54] <kshishkov> unless you're encoder guy, you don't care about it much [07:03:50] <mru> video encoder [07:04:01] <kshishkov> or audio encoder with MC [07:04:13] <mru> it has VABA though [07:04:19] <mru> absolute difference and accumulate [07:04:48] <mru> a few adds at the end give you the SAD [07:12:21] <av500> woot the vote! [07:18:27] * kshishkov now truly hates C++ [07:50:26] <KotH> moin [07:50:43] <mru> morning KotH [07:53:05] <CIA-99> ffmpeg: diego * r24320 /trunk/doc/faq.texi: [07:53:05] <CIA-99> ffmpeg: Remove duplicate RTP depacketization entry. [07:53:05] <CIA-99> ffmpeg: Two questions below there is the same Q+A, slightly rephrased. [08:11:20] <lu_zero> good morning [08:11:25] <mru> morning [08:13:26] * kshishkov feels that ffmpeg-devel returned to its hello-channel status [08:17:00] <mru> it's monday morning, what do you expect? [08:22:05] <j0sh> lu_zero: ping [08:23:24] <benoit-> moin [08:23:34] <av500> gm [08:23:37] <benoit-> anyone interested to sell FFmpeg? [08:23:40] <benoit-> "Please give necessary details about licence,price of ffmpeg tool." [08:23:47] <av500> 4) profit [08:24:00] <jenk> i'll sell it [08:24:19] <jenk> tell them to hti me up [08:25:19] <saintdev> jenk: does that mean you get to tell them it'll do things it really can't just to get the sale? [08:25:51] <av500> "It's user friendly..." [08:26:07] * kshishkov sues av500 for slander [08:26:29] <av500> "It's *super* user friendly..." [08:26:53] * kshishkov just multiplies compensation by ten [08:26:54] <av500> wait, didn't we vote against users? [08:27:24] <kshishkov> no need to do that [08:27:53] <jenk> i'll be willing to provide them with a license enabling them full source code access [08:27:57] <jenk> for a reasonable fee [08:28:26] <kshishkov> may Stallman be with you then [08:28:35] <jenk> oh he is [08:28:48] <jenk> he is tiled on my desktop bg [08:28:57] <saintdev> o.O how can we afford you to just give the source away [08:28:59] <jenk> no hoarders [08:29:07] <jenk> who said anything about giving it away??? [08:35:31] <CIA-99> ffmpeg: diego * r24321 /trunk/doc/faq.texi: Mark file references as such with texinfo markup. [08:42:35] <CIA-99> ffmpeg: diego * r24322 /trunk/doc/faq.texi: Clarify bug reporting policy with regard to releases. [08:57:46] <CIA-99> ffmpeg: diego * r24323 /trunk/doc/faq.texi: Mark URL as such with texinfo markup. [09:01:11] <Dark_Shikari> _troll_: ping [09:01:16] <_troll_> pong [09:01:29] <Dark_Shikari> On a Cortex, what's the current speed status of ffh264 vs CoreAVC? [09:01:46] <_troll_> I'd have to run a test [09:01:49] <_troll_> suggest a sample [09:01:57] <Dark_Shikari> ok, I'll get you a few samples [09:02:08] <_troll_> something realistic please [09:02:13] <av500> meh [09:02:16] <Dark_Shikari> I'll get something relatively worst-case [09:02:19] <_troll_> nothing 1080 or so [09:02:26] <Dark_Shikari> since what matters is it being able to keep up in hard situations [09:02:30] <Dark_Shikari> not how fast it goes in zero motio [09:05:36] <Dark_Shikari> so this will be the first test we've done on a purely-hard test clip. [09:07:22] <Dark_Shikari> ok, uploading. it's 4 clips, each of which is 250 frames long. they're .h264, so you can easily cat them to make them longer [09:07:26] <Dark_Shikari> test1.h264: normal high profile [09:07:31] <Dark_Shikari> test2.h264: minus cabac [09:07:35] <Dark_Shikari> test3.h264: minux cabac and loopfilter [09:07:51] <Dark_Shikari> test4.h264: minus cabac, loopfilter, subpel, all modes except i16x16 and p16x16 [09:07:58] <Dark_Shikari> i.e. "like h261" [09:08:52] <_troll_> how does that compress compared to mpeg2? [09:09:21] <Dark_Shikari> dunno. [09:09:33] <Dark_Shikari> probably worse, I'm just curious [09:09:39] <Dark_Shikari> wrt decoding speed [09:10:04] <kshishkov> Dark_Shikari: and what's the outcome of your codec testing (the one with parkrun sample, SVQ1 and Bink)? [09:10:11] <Dark_Shikari> kshishkov: parkjoy [09:10:14] <Dark_Shikari> and meh, never finished it [09:10:16] <Dark_Shikari> :effort: [09:10:18] <Dark_Shikari> to make it totally fair [09:10:26] <Dark_Shikari> it did satisfy my curiosity though [09:10:33] <Dark_Shikari> _troll_: http://x264.nl/developers/Dark_Shikari/bench_clips.tar [09:10:52] <av500> 404 [09:14:29] <Dark_Shikari> fixed. [09:14:47] <CIA-99> ffmpeg: diego * r24324 /trunk/doc/faq.texi: Remove outdated entries about bt8x8 capture on Linux 2.4 kernels. [09:26:08] <Dark_Shikari> btw, our problem on the ipad was _always_ the worst case [09:26:10] <_troll_> Dark_Shikari: decode times with ffh264: 16.5 13.6 10.3 8.1 [09:26:12] <_troll_> at 600MHz [09:26:18] <Dark_Shikari> we could easily get 5-8ms on low motion [09:26:22] <Dark_Shikari> on high motion it could spike to 30-40ms [09:26:37] <Dark_Shikari> oh wow, no subpel really is a lot faster. [09:26:54] <Dark_Shikari> interesting, deblocking takes more time than cabac. barely. sounds like you need to write that deblock strength function ;) [09:27:06] <_troll_> yeah, should do that [09:27:25] <Dark_Shikari> you can write it for x264 first if you want, since it has a clear C version and checkasm [09:27:33] <Dark_Shikari> once that's done it's probably a trivial port. [09:27:35] <Dark_Shikari> so... now coreavc. [09:28:04] <_troll_> what resolution are those clips? [09:28:04] <Dark_Shikari> Also, I just got an email from Fluendo about licensing x264. [09:28:09] <_troll_> :-) [09:28:10] * Dark_Shikari wonders what to do. [09:28:17] <Dark_Shikari> they're evil, but... hey [09:28:18] <_troll_> make 'em pay [09:28:19] <Dark_Shikari> lol [09:28:56] <_troll_> coreavc: 12.1 9.8 7.1 5.7 [09:29:13] <twice11> Just curious: why is Fluendo evil? [09:29:18] <_troll_> lol [09:29:30] <_troll_> why is satan evil? [09:29:41] <Dark_Shikari> Because their entire business model consists of attempting to convince people to purchase proprietary alternatives to open source software? [09:29:49] <Dark_Shikari> I mean, it's not like microsoft [09:29:56] <Dark_Shikari> Microsoft doesn't say "we're a linux alternative, buy us" [09:30:04] <_troll_> selling proprietary sw on its own merits is fine by me [09:30:09] <Dark_Shikari> agreed [09:30:27] <Dark_Shikari> _troll_: a8 or a9? [09:30:31] <_troll_> beagle [09:30:34] <Dark_Shikari> ok, so a8 [09:30:38] <_troll_> I don't have an a9 with neon [09:30:58] * KotH would use a4, a8 is way too small [09:31:02] <KotH> ;-) [09:31:09] <_troll_> actually, I do have access to one [09:31:29] * Dark_Shikari sends numbers to boss [09:31:35] <av500> _troll_: could you be mru again? [09:31:42] <mru> better? [09:31:44] <av500> yes [09:31:59] <kshishkov> but it was appropriate for those benchmarks [09:32:06] <Dark_Shikari> lol [09:34:17] <Dark_Shikari> mru: that's pretty bloody impressive. [09:34:40] <twice11> Doesn't Microsoft's "get the facts" campaign claim that "Windows can do everything Linux can do, but more reliable and with a lower TCO"? [09:35:02] <twice11> err, "Windows server can do everything Linux servers can do" to be more exact. [09:35:08] <Dark_Shikari> ok, true, they do that for servers. [09:35:13] <Dark_Shikari> so yeah, they're pretty evil there. [09:35:19] <Dark_Shikari> though even then, their methods aren't the same [09:35:31] <Dark_Shikari> Fluendo says "use us because OMG OPEN SOURCE IS ILLEGAL" [09:35:35] <Dark_Shikari> Microsoft gave up on that a few years ago [09:35:55] <twice11> And now we have VFAT long name patent lawsuits... [09:36:32] <mru> yet we don't see debian dropping vfat support [09:37:13] <twice11> The kernel already crippled VFAT long/short name dualism as response to the patent claims, AFAIK. [09:38:11] <twice11> And Debian's policy is mostly to not care about patents anyway. [09:38:18] <mru> except for ffmpeg [09:38:51] <KotH> mru: s/ffmpeg/mplayer/$ [09:38:57] <mru> same thing [09:39:08] <Dark_Shikari> ubuntu actually honestly doesn't care about patents [09:39:09] <KotH> mru: ffmpeg has been in debian for ages until they allowed mplayer in [09:39:14] <Dark_Shikari> debian doesn't care about patents except when it suits them politically to do so [09:39:31] <mru> KotH: didn't they --disable-everything? [09:39:32] <Dark_Shikari> Then they care a lot. [09:39:33] <KotH> mru: interstingly, they always critizied lavcodecs as the main source of probable lawsuits [09:39:37] <av500> Dark_Shikari: how many frames is that test clip? [09:39:41] <KotH> mru: no, that was suse [09:39:41] <Dark_Shikari> av500: 250 [09:39:44] <av500> right [09:41:14] <av500> so, I get: 5, 6, 3.5 and 2.75 [09:41:24] <mru> ittiam? [09:41:34] <av500> yes [09:41:35] <mru> and what hw? [09:41:43] <av500> 3440 [09:41:43] <mru> MHz? [09:42:00] <av500> 600 [09:42:04] <mru> impressive [09:42:05] <Dark_Shikari> what's a 3440 [09:42:11] <mru> Dark_Shikari: same as 3530 [09:42:11] <av500> but this is the split one, arm and dsp [09:42:15] <mru> of course [09:42:23] <Dark_Shikari> explain? is this a dsp decoder? [09:42:32] <Dark_Shikari> wait. 5, 6??? [09:42:33] <mru> it splits the work between arm and dsp [09:42:35] <Dark_Shikari> CABAC IS FASTER THAN CAVLC? [09:42:42] <Dark_Shikari> This thing has a dedicated cabac unit, right? [09:42:45] <kshishkov> Dark_Shikari: TI OMAP 3xxx I think [09:43:02] <mru> Dark_Shikari: the ittiam decoder does the first stages on arm and transfers to dsp [09:43:06] <av500> at 800mhz, the last clip is 9ms/frame [09:43:11] <mru> so cabac/cavlc will be don on arm [09:43:13] <mru> done [09:43:17] <Dark_Shikari> Why would CABAC be faster than CAVLC? [09:43:24] <av500> Dark_Shikari: dunno, but its like that [09:43:26] <Dark_Shikari> that makes no sense if there's no dedicated CABAC unit [09:43:32] <mru> Dark_Shikari: it's probably not the bottleneck anyway [09:44:14] <Dark_Shikari> interesting that deblocking takes up so much time [09:45:03] <mru> maybe it can be done faster [09:46:02] <Dark_Shikari> av500: thanks for the info, forwarded [09:46:06] <av500> hmm, I think my measurements are off [09:46:08] <av500> Dark_Shikari: hold that [09:46:15] <Dark_Shikari> oh. already sent. I can send a new one of course [09:46:19] <Dark_Shikari> er, correction email [09:46:22] <av500> ok [09:46:25] <Dark_Shikari> since nobody I'm sending the email to is awake anyways [09:46:28] <av500> but might take some time [09:46:37] <Dark_Shikari> btw, you can run the test multiple times [09:46:38] <Dark_Shikari> e.g. using cat [09:46:41] <Dark_Shikari> to get more accurate results [09:46:46] <Dark_Shikari> cat it 10 times, divide by 10 [09:46:51] <av500> rly? :) [09:47:01] <av500> all my setup is only for ms/frame [09:47:11] <av500> I never care for total runtime [09:47:15] <mru> 54 [09:47:32] <av500> mru: its a 26/26 split between arm and dsp [09:47:49] <Dark_Shikari> av500: well yes, ms per frame matters [09:47:54] <Dark_Shikari> but we need to be comparable with mru's results [09:48:08] <Dark_Shikari> and of course, average time per frame * numframes... [09:48:24] <mru> another decoder: 12.7 10.5 6.7 5.3 [09:49:56] <kshishkov> that's better [09:56:39] <av500> mru: Dark_Shikari: ah, I see why, I do not render faster than 60fps [09:56:58] <Dark_Shikari> ah [09:56:59] <av500> coz the LCD is 60fps or s [09:57:08] <Dark_Shikari> can you remove that lock? [09:57:11] <av500> I need to write mode that only decodes without renderinf [11:25:49] <pross-au> Evenin' [11:44:24] <CIA-99> ffmpeg: mstorsjo * r24325 /trunk/libavformat/rtpdec_asf.c: rtpdec_asf: Include lavu headers using quotes instead of angle brackets [11:50:59] <CIA-99> ffmpeg: pross * r24326 /trunk/ (5 files in 2 dirs): Add doxygen @file comment block [12:17:21] <Dark_Shikari> fuck. I hate the fact that pixfmts are enums, not defines [12:17:28] <Dark_Shikari> this means we can't do logic based on whether a pixfmt exists or not [12:17:42] <Dark_Shikari> (in an swscale-using app) [12:17:56] <mru> all of them always exist [12:18:04] <Dark_Shikari> I mean wrt old versoins. [12:18:08] <mru> check the version [12:18:12] <mru> you can #if on that [12:18:19] <Dark_Shikari> then you have to track the version for every single pixfmt [12:18:21] <Dark_Shikari> which is really stupid [12:18:22] <mru> or just use latest [12:18:36] <Dark_Shikari> x264 has a function which converts swscale pixfmts to the closest internally supported one [12:18:38] <mru> or do a configure-type test [12:18:39] <Dark_Shikari> for its filter chain [12:18:45] <Dark_Shikari> e.g. RGB565 -> RGB24 [12:18:56] <Dark_Shikari> it has a switch statement off pix fmts [12:19:00] <mru> x264 does pixfmt conversion now? [12:19:12] <Dark_Shikari> when you can do decoding, you have to be able to do pixfmt conversion [12:19:24] <mru> true [12:19:49] <mru> but why not use libswscale names directly [12:19:56] <Dark_Shikari> because we don't want to require swscale [12:19:59] <Dark_Shikari> for two reasons [12:20:11] <Dark_Shikari> 1) x264 should be able to build without swscale, to begin with [12:20:27] <Dark_Shikari> 2) avisynth can do colorspace conversions and resizes, so not having swscale is not doom for the filtering system [12:20:52] <Dark_Shikari> the only way to fix 1) is to keep our own copy of pixdesc.h [12:20:53] <Dark_Shikari> which is stupid [12:21:14] <mru> ok, point taken [12:21:50] <Dark_Shikari> oh, and we don't want to support every colorspace in the world in the filter system [12:21:54] <Dark_Shikari> that's very stupid [12:21:54] <Dark_Shikari> and too much work [12:22:59] * kshishkov thought pixfmt are not in sws anymore [12:23:56] <Dark_Shikari> they're in avutil. [12:23:58] <Dark_Shikari> same problem. [12:27:13] <av500> they should go to libavcore [12:28:17] <Dark_Shikari> we still shouldn't require it. [12:28:34] <Dark_Shikari> placing a required dependency between x264 and ffmpeg is a gigantic dick move. [12:28:41] <Dark_Shikari> and should only be done if absolutely necessary. [12:28:45] <Dark_Shikari> Which it isn't. [12:29:04] <mru> but do you need the pixel format defs when not using ffmpeg? [12:29:05] <KotH> how about merging x264 into ffmpeg? ;-) [12:29:25] <elenril> KotH: right after -mt i think [12:29:39] <KotH> is that before or after hurd 1.0? [12:29:49] <av500> at the same time as DNF [12:29:56] <elenril> before, after hurd 1.0 we won't need mt [12:29:56] <kshishkov> Dark_Shikari: or introduce a function to swscaler to get needed colourspace ID from required parameters [12:30:22] <Dark_Shikari> mru: we would, if we didn't do what we did now [13:05:20] <Honoome> elenril: after hurd 1.0 we won't need computers [13:05:49] <Honoome> actually, hurd 1.0 codename is going to be "Matrix"... so we would want to stay _away_ from computers then :P [13:06:28] * elenril thought is was skynet [13:08:35] * kshishkov though "Hurd" was just a codename for Emacs 256.0 or so [13:23:55] <pross-au> Ah, the Duke Nukem Forever of operating systems... [13:24:46] <av500> no, DNF, the hurd1.0 of video games [13:25:23] <pross-au> But most people have heard of DNF [13:25:49] <KotH> DNF is taking away the glory from hurd 1.0! [13:27:27] <elenril> evil proprietary software! [13:27:55] <KotH> elenril: is that a trope? [13:28:41] <pross-au> goes back to GNU/FFmpeg [13:30:23] <elenril> KotH: there's a trope for everything [13:30:31] <elenril> it's like rule 34 [13:31:20] * mru applies rule 34 to tropes [13:31:57] * elenril throws http://tvtropes.org/pmwiki/pmwiki.php/Main/Trope-tan at mru [13:34:01] * KotH wonders how rule 34 on ffmpeg would look like [13:34:07] <BBB> \o/ [13:34:13] <BBB> my mbedge loopfilter worked at once [13:34:37] <KotH> then you have not seen the obvious bug ;-) [13:34:41] <BBB> and then I used the mru approach to break it intentionally to make sure it's actually used, and it broke indeed \o/ [13:34:41] <kshishkov> KotH: whenever you feed one ffmpeg output to another [13:34:45] * BBB cheers [13:37:42] <elenril> KotH: http://tvtropes.org/pmwiki/pmwiki.php/Main/BeCarefulWhatYouWishFor [14:11:41] <KotH> elenril: i've seen rule 34 invoced on shopping carts... so nothing is going to shock me anymore [14:12:37] <kshishkov> KotH: isn't it demonstrated in every supermarket? [14:14:50] <Honoome> kshishkov: only in .ua I guess :P [14:15:09] <av500> you are not supposed to demostrate in supermarket! [14:18:29] * Honoome has been trained by xkcd to reply with "that's what SHE said" but will avoid doing so this time [14:21:17] <kshishkov> Honoome: may I remind you that Italia does not differ from Ukraine much [14:21:50] <Honoome> kshishkov: our supermarkets are still not applying rule34 daily [14:23:26] <KotH> Honoome: do you have nightmares about being sourunded by thousands of mouse sized dromaeosaurids? [14:23:28] <kshishkov> Honoome: we still don't have enough supermarkets so I cannot say what happens in them [14:23:29] <mru> KotH: would you be shocked by rule 34 applied to high-voltage power lines? [14:23:51] <KotH> mru: hmm... [14:24:01] <mru> or rule 34 applied to various fractions of spork [14:24:06] <kshishkov> mru: everybody will be shocked when applied to high-voltage lines [14:24:10] <KotH> mru: only if they are under power and have more than 1GV applied ;) [14:24:26] <Honoome> KotH: not yet no, but I have strange hobbies lately [14:25:08] <kshishkov> mru: replacing conditions with loops and switches [14:25:18] <Honoome> well, never stranger than elenril's linking of tvtropes at any chance ;) [14:25:32] <mru> Honoome: tried #331? [14:26:01] <Honoome> not yet, I have too many friends who work in the graphics area :/ [14:26:31] <mru> Honoome: #559? [14:27:09] <Honoome> that one yes [14:29:19] <mru> #79 is fun [14:30:12] <Honoome> saste just did #139 [14:30:15] <Honoome> err #138 [14:35:47] <kshishkov> #253 [14:59:29] <CIA-99> ffmpeg: aurel * r24327 /trunk/libavformat/avformat.h: [14:59:30] <CIA-99> ffmpeg: fix av_seek_frame_binary() documentation [14:59:30] <CIA-99> ffmpeg: read_timestamp() is part of AVInputFormat, not AVCodec [15:23:48] <Honoome> I _definitely_ got to try #590... I know _so_ many of them [15:24:49] <mru> it is a dreadful font [15:25:14] <Honoome> where is it found? [15:25:41] <mru> papyrus.ttf says fc-match [15:26:02] <mru> which is in a bag of fonts I snagged from a windows system years ago [15:26:13] <kshishkov> standard MacOSX Comic Sans replacement? eww [15:26:14] <Honoome> windows, gotcha! :) [15:27:11] <mru> nice fonts, but expensive: http://typography.com/ [15:27:38] <kshishkov> mru: still, Comic Sans is #0 in dreadfulness [15:32:11] <jhuntwork> Hi! [15:32:29] <mru> lo [15:33:18] <jhuntwork> I was wondering if there had been any updates on getting speex encoding to work with ffmpeg [15:33:40] <jhuntwork> saw there had been a few patches floating around, but none of them seem to have been accepted from what I can tell [15:34:11] <mru> 1. find them [15:34:13] <mru> 2. fix them [15:34:17] <mru> 3. submit them [15:34:21] <mru> 4. ??? [15:34:23] <mru> 5. profit [15:34:37] <jhuntwork> heh, ok [15:34:58] <mru> sorry, I didn't follow those patches [15:36:48] <jhuntwork> the last one I saw was here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-October/077595.html [15:43:30] * Kovensky would like to know why is the SNR -1.5dB on his modem's statistics page [15:45:07] <kshishkov> read the manual [15:45:28] * kshishkov had lots of different SNRs on his modem statistics [15:45:51] <mru> what's the snr of the snr reading? [15:48:51] <Kovensky> it's -2.0 now =p [15:48:55] <Kovensky> kshishkov: no manual [15:49:06] <Kovensky> the help just says "View status and statistical information for the Digital Subscriber Line (DSL)when the physical WAN-side connection to the service provider is achievedthrough a DSL line. Statistical information is accumulated over periodicintervals and may be displayed for up to a 24 hour period" [15:50:09] <mru> well, as long as it's not -inf you have some signal... [16:09:16] <Honoome> Kovensky: SNR of -1.5dB? and you're still connected? MiracleModem? [16:11:12] <Kovensky> is there even negative SNR anyway [16:11:48] <mru> of course [16:11:56] <mru> when the signal is weaker than the noise [16:12:07] <mru> signal/noise < 1 [16:12:28] <av500> take #beagle for example [16:12:41] <mru> nah, it has snr of 54db [16:12:58] <av500> right 26^2 [16:12:58] <mru> signal and noise are both 26 [16:13:35] <Kovensky> <@mru> when the signal is weaker than the noise <-- how can you even find the signal when it's below the noise [16:13:48] <mru> Kovensky: you look harder [16:14:11] * mru points at shannon [16:14:51] <av500> Kovensky: you might know something about the signal [16:15:35] <mru> av500: you always know something about the signal: it's not noise [16:16:16] <av500> yes [16:30:54] <kshishkov> Kovensky: look at matched filtering, for example [16:31:23] * Kovensky is only now starting at DSP ._. [16:31:35] <av500> look at how GPS works [16:31:37] <Kovensky> actually, I paused the DSP reading stuff to read on calculus and other math stuff [16:31:54] * Kovensky needs to learn math properly [16:31:56] <kshishkov> Kovensky: unlike you DSP has never met with me [16:32:01] <mru> calculus exists so we can do dsp [16:32:24] <mru> gauss and his friends had amazing foresight [17:18:31] <CIA-99> ffmpeg: mru * r24328 /trunk/Makefile: fate: echo fate-run command with V=1 [17:18:32] <CIA-99> ffmpeg: mru * r24329 /trunk/ (Makefile configure): Generate list of lavfi tests in configure [17:18:41] <CIA-99> ffmpeg: mru * r24330 /trunk/ (4 files in 3 dirs): (log message trimmed) [17:18:41] <CIA-99> ffmpeg: Fix lavfi pixdesc test [17:18:41] <CIA-99> ffmpeg: This test verifies the pixdesc code by comparing the output with and [17:18:41] <CIA-99> ffmpeg: without a filter which should have no effect on the image. Since the [17:18:42] <CIA-99> ffmpeg: available pixel formats depend on the byte order of the machine, a [17:18:42] <CIA-99> ffmpeg: simple reference checksum is not possible. [17:18:43] <CIA-99> ffmpeg: The test originally tried to solve this by generating a reference file [17:21:29] <pJok> what to do with the power of perl on my android phonne? [17:22:23] <saintdev> Try and take over the world! [17:22:38] <mru> ffperl? [17:41:01] <_av500_> pJok: use it to run ffmpeg [18:13:09] <pJok> _av500_, that would require root ;( [18:13:11] <pJok> ;)* [18:13:28] <mru> make it suid root then [18:14:33] <pJok> mru, rooting it requires some bashing on the bootloader [18:14:45] <pJok> and i can't be bothered doing that till android 2.2 officially is out from htc [18:14:47] <mru> doesn't it have bash installed? [18:14:55] <pJok> nop [18:14:59] <mru> ah.. [18:15:00] <pJok> i think it has busybox [18:15:10] <mru> try boxing the bootloader then [18:15:22] <pJok> again, can't be bothered doing it till 2.2 is out [18:15:27] <mru> then you can make an unboxing vid after [18:15:38] <pJok> since i will have to do it all over again anyways [18:17:38] <pJok> annoyingly you have to create a rom and flash it if you want to change the OS [18:18:02] <pJok> otherwise i'd have fixed 2.2 when i got it [18:20:45] <CIA-99> ffmpeg: alexc * r24331 /trunk/libavcodec/aacenc.c: [18:20:45] <CIA-99> ffmpeg: aacenc: Refactor apply_window_and_mdct() so it no longer takes an offset channel. [18:20:45] <CIA-99> ffmpeg: Patch by Nathan Caldwell <saintdev(a)gmail.com> [18:23:34] <CIA-99> ffmpeg: alexc * r24332 /trunk/libavcodec/aacenc.c: [18:23:34] <CIA-99> ffmpeg: aacenc: Adjust array offsets for the current channel before calling ff_psy_suggest_window(). [18:23:34] <CIA-99> ffmpeg: Patch by Nathan Caldwell <saintdev(a)gmail.com> [18:38:37] <CIA-99> ffmpeg: alexc * r24333 /trunk/libavcodec/aaccoder.c: Cosmetics: Whitespace [18:44:11] <CIA-99> ffmpeg: mstorsjo * r24334 /trunk/libavformat/rtpdec_xiph.c: [18:44:12] <CIA-99> ffmpeg: rtpdec_xiph: Avoid extra memcpy in Xiph RTP depacketizer [18:44:12] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [18:45:56] <saintdev> peloverde: does the initial window type have to be anything specific? [18:46:13] <peloverde> no [19:07:05] <saintdev> peloverde: is there any sort of frame analysis software that you know of? [19:07:31] <peloverde> nothing useful [19:08:21] <BBB> how do I force a video decoder with ffmpeg? [19:08:22] <peloverde> Some video software claims to handle AAC but it's never more than pulling a few flags out of an ADTS header [19:08:32] <Dark_Shikari> BBB: -vcodec blah -i input [19:08:34] <peloverde> -vcodec before -i [19:08:39] <BBB> ah ok, thanks [19:35:49] <peloverde> saintdev: I did start writing my own analysis tools in python but they still are pretty rough [19:52:21] <CIA-99> ffmpeg: siretart * r24335 /branches/ (0.6 0.6/libavformat/aviobuf.c): [19:52:22] <CIA-99> ffmpeg: aviobuf: Do short seeks forward by reading and skipping data instead of a proper seek [19:52:22] <CIA-99> ffmpeg: This improves performance on e.g. seekable http. [19:52:22] <CIA-99> ffmpeg: backport r24280 by mstorsjo [19:55:54] <BBB> Dark_Shikari: peloverde: does ffplay have a -vcodec option of some sort also? [19:56:22] <Dark_Shikari> yes afaik [19:56:51] <BBB> Unrecognized option 'vcodec' [19:56:57] <BBB> what is the name of the option? :-p [19:57:21] <_av500_> dont they all use the same option parser? [19:57:55] <BBB> apparently not [19:59:14] <_av500_> right ffplay.c has its own set of options [19:59:54] <_av500_> the only codec you can force is "none" [19:59:59] <_av500_> aka .vn [20:00:03] <_av500_> -vn [20:05:40] <mru> I'm hooking the normal regtests into the fate test runner... [20:07:27] <peloverde> BBB You could always pipe FFmpeg output to FFplay [20:07:34] <BBB> not needed [20:07:36] <BBB> pretty awesome [20:07:41] <BBB> we surpasses libvpx already [20:07:58] <BBB> \o/ [20:08:38] <spaam> with how much? [20:08:48] <mru> shhh [20:09:36] <BBB> 1:50 for decoding a movie our version, C takes almost 4 minutes, libvpx takes 2:05 [20:09:45] <BBB> 110 vs 125 seconds [20:09:47] <Dark_Shikari> BBB: on your cpu. if you can commit [20:09:49] <Dark_Shikari> I'll test on a core 2 later [20:09:51] <Dark_Shikari> er, core i7 [20:09:56] <BBB> so 12% [20:10:49] <Dark_Shikari> BBB: I think libvpx has h and v swapped for deblock function names [20:11:16] <BBB> you mean we have v and h swapped [20:11:40] <BBB> same thing I guess [20:11:44] <BBB> I still think 14.3% is too much [20:11:53] <BBB> I need to at least be able to explain that [20:11:54] <Dark_Shikari> Your CPU sucks [20:12:06] <Dark_Shikari> I'll comment more later when I get to work [20:12:08] <BBB> even if it doesn't suck, it'd still be the topmost function [20:12:08] <Dark_Shikari> and you commit your stuff [20:12:15] <BBB> can I commit it all? [20:12:54] <BBB> and yeah we need some profiling data from other cpus also [20:12:56] <Dark_Shikari> the sseslow change... you really should call it something else imo [20:13:05] <Dark_Shikari> we have if(SSE2 && 3DNOW to detect some amd slow stuff [20:13:05] <BBB> I'm open for suggestions [20:13:10] <Dark_Shikari> there are effectively 4 categories of SSE [20:13:14] <Dark_Shikari> VERYSLOW (worthless, conroe) [20:13:19] <Dark_Shikari> SLOW (sometimes worthless, amd64) [20:13:22] <Dark_Shikari> er, athlon 64 [20:13:23] <Dark_Shikari> NORMAL [20:13:28] <Dark_Shikari> and FAST (Core 2, Phenom, i7)( [20:13:44] <Dark_Shikari> with the extra category FAST_AND_DOES_FAST_SHUFFLES (penryn, phenom, i7) [20:14:09] <BBB> I don't mind a good bikeshed about this [20:14:20] <Dark_Shikari> this isn't critical to the rest of your patch [20:14:24] <Dark_Shikari> commit the inner loopfilter if it isn't committed already [20:14:27] <Dark_Shikari> er, chroma bits and all that [20:14:28] <saintdev> let's take a vote! [20:14:31] <Dark_Shikari> and I'll review mbedge when I get to wokr. [20:14:31] <Dark_Shikari> brb. [20:14:35] <BBB> ok, thanks [20:16:12] <Yuvi> for us, v == filtering in the vertical direction (no transpose) [20:16:12] <Yuvi> for libvpx: v == filtering a vertical edge (in the horizontal direction) [20:18:24] <BBB> Yuvi: any recommendations on how to further speed up our vp8 decoder, or what to waste time on instead? [20:18:47] <BBB> if nothing else matters, I'll probably move on and start learning neon or so [20:19:00] <_av500_> mru: watch out [20:19:05] <BBB> heh :) [20:19:06] <_av500_> BBB: you have a BB? [20:19:10] <BBB> no [20:19:22] <mru> a B? [20:19:23] <BBB> I have an iphone [20:22:09] <Yuvi> BBB: http://pastie.org/1050972 is probably the biggest possible speedup left, I needed to check wheter gcc combined the branches or if not, how much a macro that did would benefit [20:22:26] <Yuvi> and something I forgot [20:22:55] <Yuvi> I'm busy for the next couple of days unfortunately [20:24:38] <BBB> I'm not in a hurry ;) [20:24:51] <Yuvi> http://pastie.org/1050981 is a WIP for edge emulation, it doesn't work [20:28:12] <peloverde> Do people have thoughts on attack detection and window decision? [20:29:04] <_av500_> DHS might care about attack detection [20:30:59] <BBB> peloverde: what is attack detection? [20:31:11] <saintdev> peloverde: i've got lame's almost ported over ;) [20:31:53] <BBB> Yuvi: that first one looks pretty complicated, I don't fully get it... if it works, why don't you commit it? if it's faster... [20:32:43] <peloverde> BBB: Attack detection is looking for a changes in signal properties to decide when to use a short window sequence [20:32:45] <BBB> Yuvi: the second one I can look at also, I was already considering doing some work on both lack of emu_edge for intra, as well as implementing non-edge-emu inter MV handling and maybe (if possible ??) implement optimized edge emulation routines [20:32:59] <saintdev> although it decides on pretty much entirely short blocks for castinets [20:33:19] <saintdev> so i'm not 100% sure everything is correct [20:33:23] <peloverde> Too many false positives burns bitrate [20:33:33] <saintdev> also i'm not sure how to do group decision [20:34:03] <peloverde> There is a table in 26.403 that covers group decision [20:34:36] <peloverde> http://www.3gpp.org/ftp/Specs/archive/26_series/26.403/26403-900.zip [20:34:52] <_av500_> we tried to have a group decision on where to eat at fosdem, it was hard [20:35:12] <mru> in the end we had chinese [20:35:26] <mru> can we encode audio in chinese? [20:35:50] <_av500_> and chinese is always short packets err waiters... [20:36:11] <mru> short change... [20:36:44] <pJok> nearly time to run ffmpeg on android it seems [20:37:05] <_av500_> pJok: use one of the 15+ chinese players :) [20:37:46] <pJok> i just hope i got my contacts back [20:37:54] <BBB> Yuvi: also, since you're maintainer, ist he change of prototype for vp8's filter8 inner/mbedge functions ok with you, and do you want me to change the names to something else (filtery/filter16y, filteruv/filter8uv) in the process? or is filter16/8 ok? [20:37:57] <pJok> otherwise i have to "sync" them manually again [20:37:59] <_av500_> did you root it? [20:38:05] <pJok> not only that [20:38:15] <_av500_> riot it? [20:38:17] <pJok> i found myself a nice 2.2 android rom [20:38:32] <pJok> it works [20:38:56] <pJok> but i just recovered my settings to see if it actually is going to keep my contacts or not [20:38:58] <_av500_> then u dont need ffmpeg any more, you have flash(tm) now [20:39:37] <saintdev> peloverde: but have those been investigated, or are they just blind suggestions? [20:39:54] <Dark_Shikari> BBB: ok, let me look over it [20:40:06] <Dark_Shikari> you never changed movpx.... [20:40:09] <Dark_Shikari> It looks like "mov vpx" [20:40:11] <pJok> i had that before [20:40:12] <Dark_Shikari> which seems a bit blegh [20:40:16] <BBB> I knew you'd bring that up ;) [20:40:19] <BBB> I'm doing that right now [20:40:22] <pJok> 10.1 was out for 2.1 for some reason [20:40:28] <peloverde> saintdev: They are just blind suggestions but intuitively they look like a good starting point [20:40:29] <BBB> I forgot yesterday, was finishing mbedge filter first [20:40:38] <Dark_Shikari> ok [20:41:18] <Dark_Shikari> why are there ifdef m12 blocks inside ifidn mmx? [20:41:19] <Dark_Shikari> (line 432) [20:41:26] <Dark_Shikari> don't have ifs that never trigger [20:41:40] <BBB> really? [20:41:46] <BBB> aiee [20:42:05] <Dark_Shikari> try putting pw_63 in a register, please [20:42:12] <Dark_Shikari> (even if only on x86_64) [20:42:15] <saintdev> peloverde: ok [20:42:19] <Dark_Shikari> remember: you can _overwrite_ constants you no longer need [20:42:21] <Dark_Shikari> and in sse, there's no loop [20:42:25] <Dark_Shikari> so you really do no longer need them. [20:42:28] <BBB> ugh, you're right [20:42:38] <Dark_Shikari> Also, in general, I think you might be able to use that fact to get away with fewer total regs required [20:42:48] <BBB> probably, yes [20:43:01] <BBB> I haven't gone to the extreme yet, in particular for the sse one [20:43:04] <Dark_Shikari> ok [20:43:18] <BBB> I might eventually rip out sse into its own function and further optimize it [20:43:29] <BBB> because the loop-noloop makes a huge difference [20:43:56] <Dark_Shikari> yeah, might be a good idea [20:44:08] <pJok> deadshot [20:44:14] <pJok> good thing i took a backup [20:45:19] <Dark_Shikari> BBB: can you try macroing out the movd crap? [20:45:22] <Dark_Shikari> at the end [20:45:26] <BBB> yes [20:45:40] <BBB> I said in my email I'd do it if someone would ask me to, so I will now ;) [20:46:37] <BBB> and pextrw directly to mem is useful there, but needs testing (I don't have sse4) [20:46:45] <Dark_Shikari> and that ssse3 multiply trick [20:47:03] <BBB> for the +63>>7? [20:47:06] <Dark_Shikari> yes [20:47:07] <Dark_Shikari> the pmaddubsw [20:47:10] <BBB> yeah [20:53:53] <saintdev> peloverde: http://pastebin.org/406253 [20:54:52] <CIA-99> ffmpeg: alexc * r24336 /trunk/libavcodec/aaccoder.c: aacenc: Convert if () abort() to assert(). [20:55:17] <BBB> Dark_Shikari: what was the conclusion on filter8/16 naming? [20:55:28] <BBB> some people complained but nobody gave a preference for a better name [20:55:40] <BBB> filter16y/filter8uv ok? [20:56:51] <Dark_Shikari> ok [20:57:18] <peloverde> anyone know if pylab has an fdatool clone? [21:06:52] <peloverde> That so called highpass filter looks like a bandpass to me [21:07:34] <Dark_Shikari> well your so-called aac encoder looks like a spectral hole creator [21:08:04] <saintdev> peloverde: in lame it only operates on 576 samples if that matters. [21:08:10] <saintdev> Dark_Shikari: lol [21:11:11] <peloverde> Dark_Shikari: shut up we are actually trying to be constructive here [21:11:21] <Dark_Shikari> lol [21:12:07] <saintdev> peloverde: also the center coefficient i'm guessing is 0.5 [21:12:30] <peloverde> ahh, I missed the center coef [21:12:52] <saintdev> it's not in the table, but sum1 is set equal to the center sample [21:12:59] <peloverde> yes, I see that now [21:13:01] <saintdev> so i assume that is 0.5 * 2 [21:13:51] <saintdev> although that doesn't make sense if it's the center it shouldn't be doubled [21:15:51] <saintdev> although about all i know about fir is the coefficient table the wfir prints out in scilab [21:18:58] <CIA-99> ffmpeg: rbultje * r24337 /trunk/libavcodec/ (vp8dsp.c x86/vp8dsp.asm vp8dsp.h x86/vp8dsp-init.c vp8.c): [21:18:59] <CIA-99> ffmpeg: Change function prototypes for width=8 inner and mbedge loopfilter functions [21:18:59] <CIA-99> ffmpeg: so that it does both U and V planes at the same time. This will have speed [21:18:59] <CIA-99> ffmpeg: advantages when using SSE2 (or higher) optimizations, since we can do both [21:18:59] <CIA-99> ffmpeg: the U and V rows together in a single xmm register. [21:18:59] <CIA-99> ffmpeg: This also renames filter16 to filter16y and filter8 to filter8uv so that it's [21:19:00] <CIA-99> ffmpeg: more obvious what each function is used for. [21:20:01] <peloverde> saintdev: http://imgur.com/MCZy9l&hY2zn [21:20:31] <peloverde> First image is 3GPP second image is GPSYCHO [21:27:00] <peloverde> saintdev: presumably la should be advanced ten samples, no? [21:28:25] <saintdev> i don't think so [21:29:46] <peloverde> don't we want the center value to slide through the whole window rather than center sliding through win+10 to next_win+9? [21:31:20] <saintdev> well lame does a weird offset to it's equivalent before the code you see there. [21:31:51] <saintdev> it uses firbuf = input[576 - 350 - FIRLEN + 192] [21:32:12] <saintdev> the 576 and 192 i can guess where they came from, but what is with the 350 [21:39:24] <peloverde> I don't know MP3 windowing well enough to know where it came from [21:39:36] <peloverde> Do you know an overview of MP3 window sequences [21:45:57] <saintdev> neither do i :P [21:46:25] <saintdev> but from reading the lame source they're almost identical, except long/short are 576/3x192 [21:46:30] <CIA-99> ffmpeg: rbultje * r24338 /trunk/libavcodec/x86/vp8dsp.asm: [21:46:30] <CIA-99> ffmpeg: Be more efficient with registers or stack memory. Saves 8/16 bytes stack [21:46:30] <CIA-99> ffmpeg: for x86-32, or 2 MM registers on x86-64. [21:47:00] <saintdev> or at least from window type/length [21:53:17] <peloverde> Does MP3 have start/stop windows? [21:53:45] <saintdev> yes [21:54:21] <CIA-99> ffmpeg: rbultje * r24339 /trunk/libavcodec/x86/ (vp8dsp.asm vp8dsp-init.c): Implement chroma (width=8) inner loopfilter MMX/MMX2/SSE2 functions. [21:54:29] <Dark_Shikari> \o/ [21:54:47] <Dark_Shikari> mru, peloverde, other people who know slightly more than zero about the lgpl, ping [21:55:03] <mru> pong [21:55:07] <peloverde> pong, also BBB [21:55:25] <Dark_Shikari> ok, so my company obviously wants to abide by the LGPL. [21:55:34] <Dark_Shikari> However, they have some practical issues which mean they can't do it exactly the same way that most companies do [21:55:39] <Dark_Shikari> normally, you have a software download link on your site [21:55:43] <Dark_Shikari> and you either include source + LGPL [21:55:51] <Dark_Shikari> or you put a link next to it for source, and say "we use ffmpeg blah blah blah" [21:55:58] <Dark_Shikari> (also, ffmpeg is not the only LGPL lib here, fyi) [21:56:03] <Dark_Shikari> However, our downloadable is... an applet [21:56:06] <Dark_Shikari> There's no link. There's no install. [21:56:09] <Dark_Shikari> It starts automatically. [21:56:21] <Dark_Shikari> Putting lgpl or source in the .jar is stupid -- nobody will ever see it or even know that it's there. [21:56:34] <Dark_Shikari> What should be done to be LGPL compliant in this case? [21:56:36] <mru> java!!?!? [21:56:55] <Dark_Shikari> Java is just used for the network stack and as a payload. [21:56:58] <BBB> provide a link to the source in an about dialog or so [21:57:07] <Dark_Shikari> e.g. it's a way to get lavc onto a user's machine without an install [21:57:15] <BBB> I'm working on committing the other stuff btw, but splitting takes a little [21:57:16] <Dark_Shikari> All the stuff that matters is native code. [21:57:49] <mru> put a note on the page containing the "installer" that it uses lgpl and link to a page with source [21:57:53] <Dark_Shikari> er..... [21:57:55] <Dark_Shikari> there is no such page [21:58:01] <Dark_Shikari> there is no installer [21:58:11] <mru> but surely people get it _somewhere_ [21:58:15] <peloverde> the page where the applet is embedded then [21:58:20] <Dark_Shikari> Our plugin is inserted on the pages of of websites using one line of javascript [21:58:25] <mru> it's not a worm that installs itself on computers without asking, is it? [21:58:26] <Dark_Shikari> We are not going to require our customers to modify their websites [21:58:30] <Dark_Shikari> in order to insert our client [21:58:36] <Dark_Shikari> (beyond that one line) [21:58:39] <peloverde> can you put it in the applet gui then? [21:58:40] <Dark_Shikari> i.e. no forcing them to include extra content [21:58:45] <Dark_Shikari> We don't want to clutter the GUI pointlessly [21:58:49] <Dark_Shikari> right now it has a grand total of two things [21:58:53] <Dark_Shikari> 1) The game window. [21:58:58] <Dark_Shikari> 2) A tiny bar at the top, with our logo. [21:59:05] <peloverde> do you have a screenshot? [21:59:10] <Dark_Shikari> sure [21:59:19] <Dark_Shikari> my suggestion was "click the logo, get the about box" [21:59:21] <mru> is there some kind of <object> or <embed> tag? [21:59:50] <saintdev> Dark_Shikari: that was my immediate thought also :P [22:00:12] <mru> that one line that goes into the page, what does it end up doing? [22:00:19] <mru> insert some html? [22:00:25] <mru> with an object tag? [22:00:43] <Dark_Shikari> I guess. one moment [22:00:48] <mru> can't it also insert a line of text with link to lgpl info page [22:00:54] <Dark_Shikari> we don't want to add random text to the interface [22:00:57] <Dark_Shikari> imo an about box makes more sense [22:01:04] <mru> like google ads insert "ads by google" [22:02:00] <Dark_Shikari> http://i25.tinypic.com/6r6cep.jpg [22:02:29] <votz> Dark_Shikari: what does the applet do? install necessary bins and libs in the host OS for the gaikai client? [22:02:30] <mru> I see plenty of space in that title bar [22:02:34] <Dark_Shikari> votz: no installation [22:02:48] <Dark_Shikari> mru: "click on gaikai, get about box?" [22:02:51] <Dark_Shikari> or "add about link"? [22:02:54] <peloverde> turn the logo into a menu or having it launch a dialog seems reasonable [22:03:02] <mru> Dark_Shikari: either would be fine with me [22:03:33] <Dark_Shikari> now, would it be reasonable to only provide source for the latest applet? [22:03:41] <Dark_Shikari> since the applet is provided directly from our website [22:03:44] <Dark_Shikari> and not intended to be "installed" [22:03:50] <mru> I guess [22:03:53] <merbanan> Dark_Shikari: as long as you "offer" the source you should be ok [22:04:04] <Dark_Shikari> merbanan: yeah, but we shouldn't be required to give source for 2 year old applets [22:04:09] <Dark_Shikari> since we don't even distribute anything but the latest [22:04:37] <Dark_Shikari> in some sense "if you want the source for the current version, get it when you get the current version" [22:05:00] <votz> ah, an 'invisible' installation? ffmpeg/libs etc have to get installed somehow right? [22:05:17] <Dark_Shikari> No [22:05:20] <Dark_Shikari> They're just linked into the app. [22:05:23] <Dark_Shikari> Inside the .jar. [22:05:40] <Dark_Shikari> It's just an applet. It ends up in a tempdir and gets cleared with your browser cache. [22:06:07] <votz> Dark_Shikari: perhaps add a down arrow to the right of the 'Gaikai' logo to let users know there's a menu available if they click on the logo [22:06:37] <votz> quick example that comes to mind are chrome's default dropdown boxes next to the page and wrench icons [22:06:52] <merbanan> Dark_Shikari: I think that is a lawyer question, so maybe both yes and no is the correct answer [22:07:04] <Dark_Shikari> k. [22:07:30] <mru> personally I'm not too fussed over that 3-year thing [22:07:50] <merbanan> but very unlikely that someone ever will go to court over that [22:08:28] <merbanan> I would go with only supplying the latest version [22:08:39] <Dark_Shikari> k [22:08:41] <Dark_Shikari> makes sense. [22:09:57] <peloverde> saintdev: Also, new code should be in the style of "if (x)" not "if( x )" [22:11:07] <saintdev> ok [22:24:33] <Dark_Shikari> ok, talked with them about it [22:24:40] <Dark_Shikari> the menu is hard because we don't do compositing on the client currently [22:24:50] <Dark_Shikari> and we would rather avoid that if we don't have to [22:24:59] <Dark_Shikari> ( mru, peloverde, BBB ) [22:25:10] <Dark_Shikari> the decision they made is to take advantage of the fact that our client is in a frame [22:25:23] <Dark_Shikari> and make the "powered by gaikai" link at the bottom go to a special page on our site [22:25:29] <Dark_Shikari> which has information about the client, version info, and source downloads. [22:25:54] <Dark_Shikari> seems to work. [22:26:08] <peloverde> saintdev: Anyway until we can figure out where that 350 comes from, I think la-sizeof(aac_psy_fir_coeffs) makes sense as where to start [22:26:18] <peloverde> saintdev: Did you look at the commit log for clues? [22:28:59] <michaedw> Dark_Shikari: IANAL and IDNSFME, but I would be less concerned about the mechanics of delivering the source code and more concerned about meeting the conditions for allowing the recipient to use his own build of the LGPL library [22:29:42] <Dark_Shikari> They could extract the JAR and insert their own lavc [22:29:44] <Dark_Shikari> no problem with that [22:29:51] <peloverde> saintdev: This could be done with "for (j = -((FIRLEN - 1) / 2); j < 0; j += 2)" [22:30:57] <michaedw> ok, so as long as you provide adequate instructions for how to do that, I'd think you'd be fine [22:32:03] <Kovensky> IDNSFME? [22:33:00] <michaedw> including instructions for how to fetch the LGPL source from a "designated place" side-by-side with your distribution of your jar [22:33:17] <michaedw> I Do Not Speak For My Employer [22:34:29] <BBB> Dark_Shikari: I think a link to source should be fine [22:34:56] <michaedw> you don't have to distribute code from every location that you distribute the binary; that's what the "written offer" clause is for [22:35:15] <BBB> true, but that can be a lot of work if someone slashdots you [22:36:39] <michaedw> BBB: I doubt anyone could get a judge to issue an injunction on the basis that you got Slashdotted and didn't have the bandwidth to serve everyone who wanted just your source without having actually received the binary first [22:36:57] <BBB> that's what the gpl says though [22:37:08] <BBB> you want to take that to court and throw a dice? [22:37:14] <Dark_Shikari> we have a lot of bandwidth. [22:37:27] <michaedw> "equivalent access" doesn't have to mean "unlimited access" if you are making a good faith effort to serve the source on terms equivalent to the binary [22:37:51] <Honoome> michaedw: fsf won't stop at "good faith effort" [22:38:27] <michaedw> judges, historically, do; see Progress vs. MySQL [22:38:29] <Dark_Shikari> we aren't the fsf [22:39:20] <CIA-99> ffmpeg: rbultje * r24340 /trunk/libavcodec/ (avcodec.h x86/cpuid.c x86/vp8dsp-init.c x86/dsputilenc_mmx.c): (log message trimmed) [22:39:20] <CIA-99> ffmpeg: Remove FF_MM_SSE2/3 flags for CPUs where this is generally not faster than [22:39:20] <CIA-99> ffmpeg: regular MMX code. Examples of this are the Core1 CPU. Instead, set a new flag, [22:39:20] <CIA-99> ffmpeg: FF_MM_SSE2/3SLOW, which can be checked for particular SSE2/3 functions that [22:39:21] <CIA-99> ffmpeg: have been checked specifically on such CPUs and are actually faster than [22:39:21] <CIA-99> ffmpeg: their MMX counterparts. [22:39:22] <CIA-99> ffmpeg: In addition, use this flag to enable particular VP8 and LPC SSE2 functions [22:39:31] <michaedw> fsf and other guardians of the faith also have a history of pursuing good faith compliance as long as they don't feel they've compromised their "future enforcement ability" in the process [22:39:36] <Honoome> Dark_Shikari: don't worry, they'll try to put something under your wheels anyway [22:40:06] <michaedw> you're thinking of gpl-violations.org [22:40:44] <peloverde> I would argue the iPhone people were making a good faith effort [22:41:03] <michaedw> not familiar with the situation. what were people unhappy about? [22:42:02] <Honoome> michaedw: no different bunch those [22:42:15] <Honoome> peloverde: argue for or against they were making it? [22:42:45] <michaedw> Honoome: yes and no; the FSF and the netfilter folks are coming from different places [22:42:58] <Honoome> michaedw: gpl-violations is far from being just netfilter [22:44:39] <michaedw> true; I'm just mentioning a couple of significant participants in gpl-violations, who come from different places :-) [22:44:45] <peloverde> http://arstechnica.com/apple/news/2010/05/fsf-apples-itunes-store-terms-of-… [22:45:03] <Dark_Shikari> "good thing we don't use the gplv3" [22:47:14] <peloverde> Dark_Shikari: "The primary problem is that Apple imposes numerous legal restrictions on use and distribution of GNU Go through the iTunes Store Terms of Service, which is forbidden by section 6 of GPL*v2*." [22:47:22] <peloverde> (emphasis mine) [22:47:39] <Dark_Shikari> of course, they think that the gpl means whatever they want it to mean [22:47:46] <michaedw> the FSF sometimes confuses itself with a government. [22:48:23] <BBB> Dark_Shikari: ok, I'm at the patch now ;) [22:48:28] <BBB> what did I have to change again? [22:48:49] <BBB> pw_63 in a reg, something about using %ifdef m12 in mmx code [22:48:52] <BBB> was there more? [22:49:33] <Honoome> mru: ping [22:49:52] <Honoome> michaedw: no, a religion [22:50:11] <michaedw> Honoome: there's a difference? :-) [22:50:47] <Honoome> michaedw: yes, a government is unlikely to take itself very seriously [22:51:15] <Dark_Shikari> BBB: using fewer regs for constants by reusing them after the constant is done being used [22:51:20] <michaedw> I know some religions that take themselves less seriously than (at least some departments in) most governments [22:51:32] <Honoome> not fsf's case [22:51:37] <saintdev> peloverde: i'll give that a try. and no i haven't checked the commit logs [22:52:05] <peloverde> saintdev: I'm not sure how good lame commit messages are, but commit logs are usually a goof place to find context [22:52:23] <BBB> Dark_Shikari: ah yes [22:52:24] <BBB> ok [22:52:25] <michaedw> I have my own opinions about the FSF, some of which are unprintable; but none of them seem to be relevant to Dark_Shikari's ask, which is pretty straightforward AFAICT [22:52:29] <saintdev> peloverde: just glancing at them, not that great [22:52:37] <BBB> fixed the other two [22:53:31] <peloverde> Also I'm going to go ahead and switch to pluggable psymodels right away [22:55:10] <saintdev> want me to resend that patch? [22:55:26] <Dark_Shikari> BBB: so basically, you split up the big part of constant loading at the top [22:55:30] <Dark_Shikari> and just put some parts in other places in the code [22:55:42] <Dark_Shikari> e.g. "now we're done with register X, so we can load a new constant in it and %define a new name for it" [22:56:56] <BBB> Dark_Shikari: but only for >=sse2 right? [22:57:05] <michaedw> for what it's worth, good judges are familiar with prevailing practices in the industries they deal with, and try not to invalidate those practices without good reason [22:57:16] <Dark_Shikari> BBB: well your current code is only ifdeffed under that too [22:57:18] <Dark_Shikari> and yeah, of course [22:57:23] <Dark_Shikari> well, only where it makes sense [22:57:27] <BBB> yeah [22:57:32] <Dark_Shikari> you won't be able to do it except on x86_64 anyways [22:57:34] <Dark_Shikari> probably [22:58:04] <michaedw> and providing notice in the About box, and a source download link, is very much the prevailing practice for web-delivered programs with LGPL bits inside [22:58:56] <BBB> ugh [22:58:59] <BBB> I broke x86_64 again [22:59:10] <Dark_Shikari> lol gj [22:59:17] <Dark_Shikari> why are you not testing first?? [22:59:27] <Dark_Shikari> you have a gajillion people who can give you ssh access to x86_64 boxes [22:59:58] <BBB> I test most of my changes ;) [23:00:02] <Honoome> sigh one time I needed mru around he's not here?! [23:01:36] <spaam> mru is always here [23:02:27] <Honoome> I also need him sober [23:22:26] <BBB> ugh, can't figure out what's wrong :( [23:45:34] <BBB> dammit [23:45:42] <BBB> should I revert, or can I leave this for tonight? [23:45:45] <BBB> I need to go home ;) [23:46:05] <Dark_Shikari> spend a bit more time if you need to [23:46:23] <Dark_Shikari> try disabling all your x64-specific stuff [23:46:29] <Dark_Shikari> and just running the x64 with x86-style stuff [23:46:31] <Dark_Shikari> i.e. no using extra regs [23:46:34] <Dark_Shikari> then add it on bit by bit until it breaks [23:46:47] <BBB> I probably need a ssh account first for that [23:46:54] <BBB> can anyone get me one? [23:46:55] <iive> BBB: you committed bad code? [23:46:57] <BBB> preferrably on 24/7 [23:47:06] <BBB> iive: yes I should be shot [23:47:23] <Dark_Shikari> er wait [23:47:25] <Dark_Shikari> you said you were testing it [23:47:26] <Dark_Shikari> ..... [23:47:35] <Dark_Shikari> how the hell were you testing it if you didn't have an x86_64 machine? [23:47:36] <iive> does it break compilation or just gives funny pictures? [23:47:37] <Dark_Shikari> ... [23:47:45] <BBB> you tested it earlier [23:47:49] <BBB> I never modified it since then [23:47:57] <BBB> lu_zero tested this particular patch [23:48:12] <Honoome> oh god, BBB is relying on lu_zero's tests? :P [23:48:13] <BBB> it worked for him (yesterday?) [23:48:15] <Dark_Shikari> er, I didn't test it [23:48:26] <Dark_Shikari> not on x86_64 at least [23:48:36] <BBB> no, lu_zero tested this one [23:48:42] <Dark_Shikari> "I tested it" means "I tested it" [23:48:46] <Dark_Shikari> it doesn't mean "some other guy tested it" [23:49:00] <Dark_Shikari> no more commits from you, for anything, until you can test on x86_64. [23:49:05] <Dark_Shikari> there are a billion people who can give you ssh [23:49:07] <Dark_Shikari> stop being lazy [23:49:28] <Honoome> and stop leaving lu_zero to test something ¬_¬ lovely guy, just not the one to test :P [23:49:30] <BBB> mru: ping [23:49:31] <iive> Dark_Shikari: he feels bad enough already. [23:49:57] <BBB> anyone with x86-64 server with ssh access: ping [23:50:03] <Dark_Shikari> BBB: ask checkers [23:50:11] <Dark_Shikari> if you can't get one otherwise [23:50:25] <BBB> there must be someone in here with x86-64... [23:50:31] <iive> BBB: if you want to go home, revert and finish it tomorrow. [23:50:34] <BBB> checkers is in #x264dev? [23:50:48] <BBB> iive: it doesn't break compilation, just gives (probably) funny pictures [23:51:34] <Dark_Shikari> tes [23:51:36] <Dark_Shikari> *yes [23:51:39] <Dark_Shikari> checkers provides my shell [23:51:53] <iive> so no runtime segfault either... How did you found the problem? [23:52:02] <BBB> fate [23:52:15] <Dark_Shikari> oh nevermind [23:52:16] <Dark_Shikari> it's x86_32 [23:52:17] <Dark_Shikari> :/ [23:52:36] <BBB> let's wait for mru to wake up [23:52:37] <Dark_Shikari> don't ping checkers. [23:52:43] <Dark_Shikari> revert the patch for the meantime. [23:54:10] <iive> some of the fate test run in qemu, don't they? [23:55:27] <j0sh> BBB: i'm getting a x86_64 image running on my linode right now, you can have an account on there [23:55:55] <BBB> that'd be great [23:56:06] <BBB> can you send me login credentials to my email when it's up? [23:56:13] <BBB> and is it on 24/7? [23:57:59] <j0sh> yeah [23:58:02] <j0sh> it will be [23:58:50] <BBB> ok [23:58:59] <BBB> I'll logon once you've got it going then, I guess ;) [23:59:06] <BBB> let me know, I'll check email tonight [23:59:14] <j0sh> geting thigns set up now, will be a few mins [23:59:21] <j0sh> ill send you an email once its up [23:59:24] <BBB> thanks

1 0

IRC log for 2010-07-18
by irc＠mansr.com 19 Jul '10

19 Jul '10

[00:50:42] <saintdev> peloverde: ping [05:53:40] <_av500_> http://www.dspdimension.com/admin/dft-a-pied/ [07:43:12] <CIA-99> ffmpeg: pross * r24295 /trunk/libavcodec/ (cga_data.c cga_data.h): Add ff_vga16_font [07:45:29] <CIA-99> ffmpeg: pross * r24296 /trunk/libavcodec/ (cga_data.c cga_data.h): Add ff_draw_pc_font() [07:47:18] <CIA-99> ffmpeg: pross * r24297 /trunk/libavcodec/tmv.c: 8088flex TMV video decoder now uses ff_draw_pc_font() [07:53:35] <CIA-99> ffmpeg: pross * r24298 /trunk/libavcodec/ (cga_data.c cga_data.h): Add @file documentation tag [07:56:21] <mru> morning [07:56:35] <av500> morning [07:58:09] * elenril wonders why did xelatex decide to go batshit insane overnight [07:58:59] <pross-au> morning (okay) [08:04:25] <CIA-99> ffmpeg: pross * r24299 /trunk/libavcodec/ (allcodecs.c avcodec.h ansi.c Makefile): ASCII/ANSI art decoder [08:05:53] <CIA-99> ffmpeg: pross * r24300 /trunk/libavformat/ (sauce.c sauce.h): Add ff_sauce_read() [08:06:12] <mru> wtf is sauce? [08:06:16] <mru> is it secret? [08:06:57] <pross-au> Indeed [08:07:08] <pross-au> It was the precursor to ID3 [08:07:21] <pross-au> Goes with the ansi patch [08:07:45] <CIA-99> ffmpeg: pross * r24301 /trunk/ (6 files in 3 dirs): Tele-typewriter demuxer [08:11:13] <pross-au> Hmm, perhaps i better check that doxygen syntax... [08:14:01] <CIA-99> ffmpeg: pross * r24302 /trunk/libavformat/sauce.h: Use correct doxygen syntax [08:16:33] <CIA-99> ffmpeg: pross * r24303 /trunk/libavformat/sauce.h: Remove trailing linefeed [08:18:16] <mru> pross-au: where/when was this lot reviewed? [08:23:12] <pross-au> ml [08:23:17] <mru> when? [08:23:20] <mru> I see no review [08:23:21] <pross-au> March ~ June [08:23:24] <mru> oh [08:24:45] <pross-au> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/090886.html [08:29:32] <av500> pross-au: read between the lines, you are supposed to also write the "ass&utf8 subtitle renderer" :) [08:31:20] <pross-au> There's something fundamentally wrong about ASS... [08:31:42] <av500> :) [08:31:54] <av500> it's advanced SSA, so why not ASSA? [08:32:14] <pross-au> TLAs [08:32:16] <mru> primitive minds can only hold 3 letters at a time [08:32:32] <av500> wha? [08:32:50] * elenril points at mru's nick [08:32:53] <mru> hmm, they can handle 3 letters and 1 punctuation it seems [08:33:06] <av500> hello tro [08:33:18] <thresh> _tro, you meant [08:33:27] <pross-au> goes back to using git and svn [08:33:31] <av500> I'm primitive in my own way [08:38:36] <av500> mru: bored? [08:38:53] <mru> I've been looking for that text [08:39:15] <mru> but it seems like someone went through great pains to excise it from the internets [08:39:24] <av500> http://lists.xiph.org/pipermail/vorbis/2000-June/012621.html [08:39:32] <av500> he has lost it... [08:39:58] <mru> wow, so he's argumenting by appeal to a text _that nobody can read_?!!! [08:41:06] <av500> well, its a well used pratice these days, ask the TSA on what legal basis they operate the no-fly list :) [08:41:22] <mru> classified [08:42:16] <pross-au> how did we get from ASS to OGG to TSA [08:42:25] <pross-au> The link is tenuous at best [08:44:47] <mru> pross-au: you're not on #vp8 I take it [08:45:04] <pross-au> Nah, i'm good thanks [08:45:31] <av500> pross-au: it's TLA day [08:46:31] <av500> mru: can you please try to have a boring codec discussion, I'm trying to work over here :) [08:52:59] <pross-au> mru: why not use sth like hash://<filename>?algorithm={md5,sha1,etc.} [08:53:15] <mru> pross-au: too fucking complicated [08:53:39] <pross-au> well the algo can default to md5 [08:53:44] <pross-au> so it becomes hash://filename [11:36:25] <mchinen> I keep getting crc = 0 after running av_crc on buffers that shouldn't pass the check. [11:36:35] <mchinen> crc = av_crc(av_crc_get_table(AV_CRC_16_ANSI), 0, buf, buf_len_including_crc_at_end); [11:38:05] <mchinen> is there something strange about this? (typo - I expect crc != 0 but get crc ==0) [12:08:26] <astrange> http://pastebin.com/GqVBm8re what are you supposed to be sorting cachegrind by? [12:08:35] <astrange> (giving up and using a sampling profiler is an ok answer) [12:27:26] <av500> lu_zero: dont feed him [12:33:56] <lu_zero> av500: but I have plenty of troll food! [12:34:05] <lu_zero> btw [12:34:23] <av500> he is not a troll, he is just plain annoying [12:35:16] <lu_zero> astrange: you might be happier using a visualizator [12:36:30] <ohsix> something going on on the ml again? [12:36:56] <av500> no [12:45:35] <mru> cruncher? [12:45:41] <av500> yeah [12:45:54] <mru> he's a bit annoying [12:46:10] <av500> yes [12:46:13] <mru> not much of a troll though [12:46:20] <av500> [14:34] <av500> he is not a troll, he is just plain annoying [12:46:35] <mru> that's why I guessed [12:47:46] <av500> he has almost 3k posts at doom9.... [12:47:59] <mru> now count mine [12:50:24] <av500> 10 billion [12:50:50] <mru> I don't remember ever posting there [12:50:55] <av500> :) [12:51:07] <av500> I did not count his 3k *for* hime [12:51:10] <av500> -e [12:51:23] <av500> ppl that post to forums have too much free time [12:51:52] <mru> I can't stand those forums [12:52:08] <mru> especially not the posters with 3-page animated signatures [12:52:24] <av500> on the archos uses ML, every 6 month one of them made a forum, most of them never to be heard of again [12:52:27] <av500> users [12:52:45] <av500> every time I asked the guys to make the forum email-capable [12:52:45] * pJok points at mru for the art of trolling [12:53:04] <av500> which seems to be physically impossible [12:53:36] <mru> for those who run them, yes [12:53:46] <av500> the most you get from all these phpBB clowns is an email notificiation [12:54:12] <av500> why is it hard to email the text of the post and accept and email reply to the same topic? [12:54:32] <mru> then it would just be a mailing list [12:54:40] <av500> :) [12:54:43] <av500> it would be both [12:55:07] <ohsix> forsooth; thats like putting content in an rss feed! [12:55:25] <av500> -EIWANTITINMYMAILER [12:55:39] <mru> rss is nothing but a poor reinvention of nntp [12:56:25] <mru> with bigger ego [12:56:46] <av500> rss sucks unless you have one centralized place that keeps your feeds [12:56:55] <mru> exactly [12:56:57] <av500> like an imap server for email [12:57:00] <mru> at which point it becomes nntp [12:57:32] <av500> mru: I mean, when I read one entry from SW-A I dont want it flagged as new in SW-B [12:57:41] <pJok> av500, google reader [12:57:46] <mru> google reader is nice [12:57:49] <av500> pJok: and guess what I use [12:57:59] <av500> and on the phone, I have the rss reader sync to gr [12:58:02] <pJok> its the best invention since sliced bread [12:58:12] <mru> google reader works fine on the phone too [12:58:18] <pJok> i would be scared to sync up my phone with gr [12:58:19] <av500> at which point it stops to be an rss client and is just a gr interface... [12:58:31] <pJok> i use the google mobile reader site [12:58:33] <pJok> works a treat [12:58:43] <av500> iKnow [12:58:44] <mru> pJok: I wish more countries than sweden had discovered sliced _cheese_ [12:58:55] <av500> mru: popular here too [12:59:00] <mru> do they have cheese slicers in denmark? [12:59:02] <lu_zero> mru: what's the discovery? [12:59:05] <pJok> mru, it was norway who made the cheese slicer... but its a scandinavian thing [12:59:17] <av500> mru: home sliced? [12:59:27] * pJok had two instances of the cheese slicer [12:59:35] <mru> http://upload.wikimedia.org/wikipedia/commons/6/6d/Osthyvel_20050723_001.jpg [12:59:42] <av500> pJok: you freed one and the other segfaulted? [12:59:43] <pJok> the norwegian one and the one with a pianowire [12:59:51] <pJok> av500, something like that [12:59:59] * pJok doesn't actually buy cheese that often anymore [13:00:06] <av500> mru: kitchen stores have that, make great wedding gifts... [13:00:16] <av500> "it's a uh oh cheese thingy, well thanks...." [13:00:18] <pJok> i dont eat much at home so what ever stuff i keep in the fridge ends up getting too [13:00:21] <pJok> old [13:00:28] <lu_zero> mru: I have something similar as well [13:00:33] <lu_zero> not just for cheese [13:00:58] <mru> they can be found outside of scandinavia, but you have to look hard [13:01:02] <mru> and most people don't have one [13:01:20] <lu_zero> and I have also a tool specific for a certain type of cheese [13:01:29] <lu_zero> that's more a sharder [13:01:38] <mru> for parmesan? [13:01:42] <lu_zero> yup [13:01:43] <av500> chese fragmenter [13:01:49] <mru> grater [13:01:52] <lu_zero> no [13:02:11] <mru> oh, to make little flakes? [13:02:24] <av500> http://www.shop-016.de/shop_cfg/KingFood/14906.jpg [13:03:42] <pJok> http://en.wikipedia.org/wiki/Cheese_slicer [13:03:45] <lu_zero> http://i70.twenga.com/casa/coltello-da-parmigiano/coltello-per-formaggio-gr… [13:04:14] <lu_zero> av500: your image search skill is better than mine [13:04:18] <av500> :) [13:04:24] <lu_zero> anyway that is [13:04:49] <av500> is it popular in italian crime shows? [13:05:07] <pJok> mru, http://www.midtjyskudlejning.dk/billeder/s-ostehoevl.jpg my prefered one [13:05:08] <lu_zero> how so [13:05:15] <av500> "...he died from the parmesan knife in the forehead..." [13:05:26] <lu_zero> nah [13:05:43] <av500> "..so it was the drowning in concrete then..." [13:06:03] <lu_zero> the crime object of the summer is the crowbar [13:06:12] <lu_zero> and you are mixing stuff up [13:06:20] <lu_zero> parmesan -> north [13:06:31] <av500> yes, I mix concrete before I use it... [13:06:37] <mru> with cheese? [13:06:40] <lu_zero> people part of buildings and streets -> south [13:07:00] <lu_zero> people using knives to sort out issues -> center [13:07:11] <av500> they dont meet ever? [13:07:12] <mru> I was always told to avoid getting any organic matter in the concrete mix [13:07:36] <mru> av500: yes, in the middle, where they kill people by drowning them in cheese [13:08:05] <av500> wasnt that in .CH? [13:08:10] <lu_zero> av500: apparently the method do not mix even if they do business with [13:08:15] <lu_zero> av500: in .ch is chocolate! [13:08:28] <lu_zero> or they forget you in a safe [13:08:40] <av500> they keep you safe... [13:08:57] <lu_zero> or just use military grade weapons [13:09:07] <pJok> military grade chocolate? [13:09:07] <lu_zero> (with or w/out bullets) [13:09:22] <lu_zero> pJok: interesting question [13:09:33] <lu_zero> I had stories about military grade fondue [13:09:47] <pJok> that required military grade cheese and chocolate? [13:09:52] <pJok> sounds military delicious [13:10:13] <lu_zero> fondue -> cheese and milk or cheese and wine (white) [13:10:42] <lu_zero> I'm not so far from the border so it's a local recipe as well [14:02:27] <CIA-99> ffmpeg: diego * r24304 /trunk/doc/faq.texi: Fix URL for ffv1, msmpeg4, asv1, 4xm docs. [16:04:26] <kierank> hehe found another schrodingbug [16:05:33] <av500> so its gone [16:06:19] <kierank> my code should have crashed badly [16:06:26] <kierank> by some miracle was working [16:09:14] <mru> quick, call the vatican [16:16:18] * BBB lacks context [16:16:34] * av500 gives BBB 0x345DEF67 [16:16:46] <av500> careful, its a void* [16:16:58] <BBB> is it stack of malloced? [16:17:23] <av500> my stack here [16:17:24] <mru> it's unaligned [16:17:37] <BBB> it is [16:17:44] <BBB> DEF70 would be aligned though [16:17:51] <BBB> but might be out of range already if it's on the stack [16:19:59] <jai> lol [16:20:47] <jai> av500: maybe you caught him in a bad mood [16:20:58] <av500> the stack? [16:21:10] <BBB> Dark_Shikari: can you review my chroma inner loopfilter patch? [16:21:17] <jai> michael that is [16:21:18] <BBB> Dark_Shikari: I'm halfway the mbedge one already and don't want to hold this up too long [16:21:28] <BBB> oh, regarding michael [16:21:35] <BBB> that link that benjamin sent [16:21:38] <BBB> suggests that he's on irc [16:21:44] <BBB> I thought he wasn't? [16:21:56] <mru> michael sometimes reads the logs [16:22:20] * av500 waves to michael [16:22:52] <BBB> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/17029/match=wolfgang… [16:23:04] <BBB> ohwell [16:23:09] <av500> ...that FFmpeg-based DOS multimedia viewer... [16:24:12] <mru> hmm, reverse deja vu [16:24:23] <jai> what do they use for video output? [16:24:36] <mru> vga framebuffer I guess [16:24:40] <mru> it's dos.. [16:25:03] <BBB> that's a pretty bad license violation [16:25:12] <BBB> it mixes closed-source code with gpl code [16:25:18] <av500> its a DOS attack, no? [16:25:25] <BBB> return of the DOS [16:25:38] <av500> denial of saticfaction [16:27:19] <av500> he ask for money for that thing? [16:27:24] <av500> asks [16:29:21] <BBB> it's shareware [16:29:22] <BBB> yeah [17:08:08] <twnqx> else if ((size == 64) && (value & 0xFE) && !(value & 0x01)) /* 11111110 */ <-- sometimes i wonder [17:10:46] <av500> 6 [17:12:17] <kierank> BBB: ok to PM? [17:14:40] <BBB> yes [18:21:32] <CIA-99> ffmpeg: jai_menon * r24305 /trunk/ffmpeg.c: [18:21:32] <CIA-99> ffmpeg: FFmpeg : Replace some av_exit calls in av_transcode with branches to the [18:21:32] <CIA-99> ffmpeg: cleanup code. [18:21:32] <CIA-99> ffmpeg: This plugs a bunch of memleaks. [18:33:49] <funman> kshishkov: do you want a .rso sample? [18:34:23] <kshishkov> why not? [18:36:44] <kierank> funman: is your .rso format the same as the wii's .rso format? [18:36:56] <funman> kierank: no idea [18:37:02] <kshishkov> maybe not [18:37:18] * kshishkov remembers Intel IVF vs On2 IVF [18:37:40] <funman> kierank: you have a sample / info on these files? [18:38:05] <funman> kshishkov: http://pastie.org/1049533 [18:38:45] <kierank> funman: the wii rso is their equivalent of .so files [18:38:56] <kierank> so no the same one then [18:39:09] <kierank> not* [18:39:15] <CIA-99> ffmpeg: mru * r24306 /trunk/libavformat/avio.c: [18:39:15] <CIA-99> ffmpeg: Allow all valid (and only valid) characters in URL scheme for url_open() [18:39:15] <CIA-99> ffmpeg: The URL specification allows letters, numbers, plus, hyphen, and period [18:39:15] <CIA-99> ffmpeg: in the scheme part. The isalpha() test would allow additional characters [18:39:15] <CIA-99> ffmpeg: depending on locale settings while rejecting numbers and punctuation. [18:39:30] <_av500_> we still need the .elf demuxer [18:39:46] <kshishkov> _av500_: send a patch [18:40:06] <funman> _av500_: but first the x86 decoder? [18:40:14] <mru> it would be apt for a troll to submit the elf demuxer... [18:40:38] <_av500_> what is stopping said troll? [18:41:05] <kshishkov> mru: trolling output for FFmpeg is good too [18:44:13] <twnqx> _av500_: render it as a matrix screensaver? [18:50:42] <_av500_> i think the apropriate x86 decoder in lavc would be qemu [18:52:47] <funman> what would it decode to? [18:54:20] <_av500_> printf [18:54:34] <mru> _av500_: that's with the ascii-art backend [18:54:38] <mru> it has sdl output too [18:54:42] <mru> with full graphics [18:54:50] <_av500_> yes [18:55:01] <_av500_> and seek would be cool, like reverse debugging [18:55:21] <kshishkov> funman: it decodes fine but looks like output is not full 16-bit audio but rather 8-bit [18:55:21] <mru> forward seek? [18:55:32] <mru> can you seek past the place where it crashes? [18:55:41] <_av500_> hmm [18:56:00] <funman> kshishkov: the converter i use might downsample it before encoding (especially since the other codec in rso is pcm u8 [18:56:31] <kshishkov> funman: this hack will convert rso from stdin to raw s16le at stdout - http://pastie.org/1049550 [18:56:50] <kshishkov> function for nibble decompressing is borrowed from FFmpeg [18:56:58] <kshishkov> tables as well [18:57:32] <funman> thx [18:58:12] <funman> i'll look at it when the rso patch is deemed acceptable (one thing at a time) [18:58:37] <mru> acceptable isn't good enough, it must be perfect [18:58:42] <mru> lego is important stuff [18:59:04] <funman> well i disagree [18:59:11] <kshishkov> mru: danish blocks are important? [18:59:21] <funman> what's nice with lego is build, break, repeat [18:59:29] <funman> if it's perfect it'll just sit there and you won't have fun [19:00:06] * mru preferred meccano though [19:00:09] <mru> much sturdier [19:00:32] <funman> did it have motors and such? [19:00:52] <mru> we never had the official ones [19:01:04] <mru> but we added some DC motors we obtained from somewhere [19:04:20] <BBB> is there a mmx instr to expand a register of signed bytes to words? [19:04:42] <Dark_Shikari> BBB: gj [19:04:44] <Dark_Shikari> let me check it out [19:05:01] <BBB> oh there he is :-p [19:05:02] <BBB> hello [19:05:10] <BBB> do you have a highlight on the word mmx or so? ;) [19:06:42] <BBB> I guess pxor res, res; pcmpeqb res, x; and then SBUTTERFLY x, res, tmp? [19:07:04] <BBB> or rather pcmpgtb, I guess [19:07:05] <Dark_Shikari> BBB: movpx seems like a stupid acronym [19:07:50] <BBB> movfullrow? [19:07:58] <BBB> movrow maybe [19:07:59] <Dark_Shikari> It looks pretty straightforward to me otherwise [19:08:01] <Dark_Shikari> movrow, ok [19:08:04] <Dark_Shikari> everything else ok [19:08:33] <BBB> mbedge filter is mostly in-place already, will try to have it finished in 1-2 days [19:08:36] <mru> what, no signed unpack? [19:08:50] <BBB> I don't think mmx has signed byte->word [19:09:41] <Dark_Shikari> Why do you need a sign-extending unpack? [19:10:08] <mru> there are times when it's useful [19:10:18] <Dark_Shikari> Yeah, but I imagine most cases it's avoidable [19:14:41] <mru> why would you want to avoid it? [19:14:53] <mru> if you have the instruction, surely using it is better [19:16:29] <Dark_Shikari> mru: well duh [19:16:34] <Dark_Shikari> I mean in most cases, lack of it on x86 isn't killer [19:16:43] <Dark_Shikari> (unlike some other missing instructions, like vtrn) [19:16:55] <mru> vtrn is fantastic [19:17:03] <mru> and vzip/vuzp too [19:17:27] <Dark_Shikari> so after this, 4 more functions [19:17:34] <Dark_Shikari> mbedge V, mbedge H, mbedge chroma V, mbedge chroma H [19:17:45] <Dark_Shikari> then we finish the edge emulation stuff yuvi started, unless he already committed [19:17:53] <Dark_Shikari> then we merge my like-x264-deblocking patch [19:18:05] <Dark_Shikari> then we turn deblock strength calculation into a LUT [19:18:12] <Dark_Shikari> then we optimize the bloody cabac [19:18:57] <Honoome> mru: no jokes about valgrind warnings and debian patches? [19:19:16] <mru> heh [19:19:34] <funman> mru: http://pastie.org/1049575 < is that worth doing it? [19:19:54] <mru> no, __builtin_clz() already does the right thing [19:20:22] <mru> I would've done something like that long ago if it didn't [19:21:00] <funman> ah i hadn't spotted the definition in intmath.h [19:26:02] <BBB> Dark_Shikari: mbedge_filter for vp8 is signed, and requires a mul*27/18/9 >> 7 [19:26:12] <BBB> with a +63 for rounding in there somewhere [19:26:25] <Dark_Shikari> let me check that. [19:26:26] <mru> no rounding shift? [19:26:39] <BBB> ((w*27)+63)>>7 [19:26:52] <mru> is there no rounding shift instruction? [19:26:57] <BBB> not that I know [19:27:00] <Dark_Shikari> not on x86 [19:27:01] <BBB> but I don't know very much [19:27:03] <mru> primitive [19:27:03] <Dark_Shikari> It would be nice to have. [19:27:10] <mru> neon has both kinds [19:27:11] <Dark_Shikari> There are a few instructions that do have rounding [19:27:20] <BBB> not to mention that vp8 is round-screwed [19:27:21] <Dark_Shikari> pmulhrsw is actually potentially interesting here [19:27:27] <BBB> it does +4>>3 in one case and +3>>3 in another [19:27:29] <Dark_Shikari> pmulhrsw does the following [19:27:34] <mru> vqrshrun is one of the best neon instructions [19:27:37] <Dark_Shikari> each input value is treated as a signed 16-bit instruction [19:27:44] <Dark_Shikari> er, signed 16-bit number [19:27:54] <Dark_Shikari> er, bah, let me restate that [19:28:00] <Dark_Shikari> the input values are 16-bit sigend FIX8 [19:28:03] <Dark_Shikari> *signed [19:28:03] <BBB> I have the book here, I can look it up ;) [19:28:07] <mru> shift signed value right with rounding and saturate unsigned to half width [19:28:08] <Dark_Shikari> and the output is 16-bit signed FIX8 [19:28:17] <Dark_Shikari> and it does a multiplication with correct rounding [19:28:32] <Dark_Shikari> wikipedia is better, probably loren wrote it: [19:28:34] <Dark_Shikari> treat the sixteen-bit words in registers A and B as signed 15-bit fixed-point numbers between -1 and 1 (eg 0x4000 is treated as 0.5 and 0xa000 as -0.75), and multiply them together with correct rounding. [19:28:57] <Dark_Shikari> Might be slightly wrong rounding for this case because of the bloody +63 [19:29:50] <Dark_Shikari> btw, you're planning to do the unpack-to-word after w = clip_int8(w + 3*(q0-p0)); right, BBB? [19:29:58] <BBB> Dark_Shikari: right [19:30:02] <BBB> that's what I need it for [19:30:04] <Dark_Shikari> ok, in SSSE3, you can do this: [19:30:07] <Dark_Shikari> fyi [19:30:11] * BBB looks [19:30:16] <Dark_Shikari> let xmm0 = w [19:30:17] * BBB wants a ssse3 cpu :-p [19:30:24] <Dark_Shikari> punpcklbw xmm0, [pb_1] [19:30:32] <Dark_Shikari> pmaddubsw xmm0, {27, 63} [19:30:43] <Dark_Shikari> psraw xmm0, 7 [19:30:52] <Dark_Shikari> this is one less op than the pmullw method. [19:31:15] <Dark_Shikari> For the signed saturation, it might be faster to unpack the pixels, add to them, and repack. [19:32:34] <BBB> ok, I'll check it out... let me first get a basic mmx one rolling ;) [19:32:58] <Dark_Shikari> for mmx, I would do [19:33:03] <Dark_Shikari> punpcklbw mm0, 0 [19:33:07] <Dark_Shikari> pmullw mm0, 27 [19:33:13] <Dark_Shikari> paddw mm0, 63 [19:33:16] <Dark_Shikari> psraw mm0, 7 [19:33:38] <BBB> well, it's signed, so it's a little more complicated [19:33:45] <Dark_Shikari> pmullw isn't signed? [19:33:53] <BBB> punpcklbw isn't signed [19:33:54] <Dark_Shikari> Oh, you need to fix the punpcklbw [19:33:58] <Dark_Shikari> ahhhhhhhhh I see your problem [19:34:05] <Dark_Shikari> ok, in that case the ssse3 one is not one instruction better [19:34:06] <BBB> probably mova mm1, mm0; pcmpgtb mm1, 0 [19:34:08] <Dark_Shikari> it's WAY better. [19:34:13] <BBB> punpcklbw mm0, mm1 [19:34:35] <Dark_Shikari> nevermind, was confused for a second [19:34:40] <BBB> or something like that [19:34:46] <BBB> I'm probably mixing up somewhere ;) [19:34:53] <Dark_Shikari> no, you're right [19:35:21] <BBB> and then all the stuff you just said [19:35:38] <Dark_Shikari> do everything as normal for mmx, except use that trick for the unpack [19:35:42] <Dark_Shikari> is probably the best way. [19:35:52] <Dark_Shikari> ssse3 is where it gets really interesting because of the addition of byte multiplies. [19:36:24] <BBB> ok, will have it done in a few days [19:36:28] <BBB> now gotta go to a party ;) [19:54:23] <CIA-99> ffmpeg: cehoyos * r24307 /trunk/libavcodec/mpegaudiodec_float.c: [19:54:24] <CIA-99> ffmpeg: Fix memleak when using mp*float decoder. [19:54:24] <CIA-99> ffmpeg: Patch by flybird2k at gmail [20:07:39] <CIA-99> ffmpeg: lorenm * r24308 /trunk/libavcodec/ (x86/fft_mmx.asm ppc/fft_altivec_s.S arm/fft_neon.S): more credits to D. J. Bernstein for fft [20:18:43] <mchinen> ffplay stops calling av_read_frame as soon as url_feof(pb) returns true. Is this incorrect? [20:19:20] <mchinen> i have a flac parser that has a queue of frames that requires the user to keep calling read_frame after reaching the end of the file to get them [20:19:34] <mru> it seems a bit wrong to me [20:20:06] <CIA-99> ffmpeg: mru * r24309 /trunk/libavformat/ (md5proto.c Makefile allformats.c): [20:20:07] <CIA-99> ffmpeg: Add MD5 protocol [20:20:07] <CIA-99> ffmpeg: This is a write-only protocol which computes the md5sum of data written, [20:20:07] <CIA-99> ffmpeg: and on close writes this to the designated output or stdout if none [20:20:07] <CIA-99> ffmpeg: is specified. It can be used to test muxers without writing an actual [20:20:07] <CIA-99> ffmpeg: file. [20:20:08] <CIA-99> ffmpeg: mru * r24310 /trunk/tests/fate-update.sh: fate: do not delete ref files when updating tests from db [20:20:11] <CIA-99> ffmpeg: mru * r24311 /trunk/tests/fate-run.sh: fate-run: rename some variables consistently with other files [20:20:11] <CIA-99> ffmpeg: mru * r24312 /trunk/tests/ (fate.mak fate-update.sh fate-run.sh): fate: use our variable names in test rules imported from Mike's db [20:20:11] <CIA-99> ffmpeg: mru * r24313 /trunk/tests/fate-run.sh: fate: apply TARGET_EXEC only to commands starting with absolute path [20:20:11] <CIA-99> ffmpeg: mru * r24314 /trunk/tests/fate-run.sh: fate: add some helper functions to simplify test rules [20:20:30] <mchinen> ok i'll submit that as a seperate patch [20:20:53] <elenril> so...is a tar muxer next? [20:22:32] <Dark_Shikari> RFC: libavcodec has no per-sequence TFF option [20:22:34] <Dark_Shikari> only a per-frame TFF option [20:22:41] <Dark_Shikari> x264 needs to know TFF at the start of encoding, before the first frame. [20:30:56] <mru> Dark_Shikari: tff is a per-frame attribute [20:30:59] <mru> it varies [20:31:04] <mru> telecine [20:31:11] <Dark_Shikari> No, that's not how telecine works [20:31:16] <Dark_Shikari> for telecine, you have a per-frame pulldown flag [20:31:23] <CIA-99> ffmpeg: mstorsjo * r24315 /trunk/libavformat/rtspenc.c: Include lavu headers using quotes instead of angle brackets [20:31:23] <Dark_Shikari> i.e. an RFF flag [20:31:26] <mru> hard telecine [20:31:39] <mru> some idiots do that [20:31:45] <Dark_Shikari> why would hard telecine have varying field order? [20:32:03] <mru> err, I'm stupid, it's soft that varies [20:32:11] <Dark_Shikari> soft is the one where it's resolved via RFFs though [20:32:11] <mru> after you've repeated a field, the field order changes [20:32:16] <Dark_Shikari> no it doesn't [20:32:23] <Dark_Shikari> an RFF flag simply says "repeat this field on playback" [20:32:28] <Dark_Shikari> it doesn't affect the bitstream [20:32:38] <Dark_Shikari> in h264, the top vs bottom field is used in compression [20:32:45] <Dark_Shikari> to determine how to scale motion vectors and such [20:32:51] <_av500_> Dark_Shikari: congrat, you made c't magazine here in .de [20:32:51] <Dark_Shikari> for weighted bipred, etc [20:32:54] <_av500_> +s [20:33:11] <kierank> what's c't magazine? [20:33:12] <Dark_Shikari> so it is inherently wrong to use the wrong *FF flag [20:33:14] <_av500_> vp8 article mentions your analys [20:33:32] <_av500_> kierank: the only german computer magazine [20:33:46] <Dark_Shikari> >vp8 article [20:33:48] <Dark_Shikari> they're late. [20:33:50] <Dark_Shikari> oh, they're a magazine. [20:33:55] <Dark_Shikari> the Old Media [20:34:01] <Dark_Shikari> mru: so what's the proper solution? [20:34:03] <Dark_Shikari> do we modify the x264 API? [20:34:20] <Dark_Shikari> x264 currently has two flags you can set: [20:34:28] <Dark_Shikari> 1) pic struct flags (per frame, the h264 analog of RFF flags) [20:34:34] <Dark_Shikari> 2) TFF/BFF (sequence-wide flag) [20:35:26] <_av500_> kierank: h-online is also from them: http://www.h-online.com/open/news/item/FFmpeg-0-6-adds-WebM-VP8-support-102… [20:36:22] <mru> Dark_Shikari: suppose frame 1 has tff and rff [20:36:35] <mru> then the second top field to be displayed is still from frame 1 [20:36:42] <Dark_Shikari> x264 doesn't care about what is displayed. [20:36:47] <mru> the field after that, a bottom field, will be from frame 2 [20:36:50] <mru> hence frame 2 has bff [20:36:51] <Dark_Shikari> er... no. [20:36:53] <Dark_Shikari> wrong. [20:37:08] <Dark_Shikari> "frame 1" is the first coded field, and the second coded field. [20:37:11] <Dark_Shikari> x264 doesn't care what you display. [20:37:14] <Dark_Shikari> it cares what you code. [20:37:27] <Dark_Shikari> for example, frame 1 may have a TBT pic struct flag [20:37:39] <Dark_Shikari> er, actually let me check the flag names [20:37:57] <Dark_Shikari> ah ok, so a simple example [20:38:01] <Dark_Shikari> PIC_STRUCT_TOP_BOTTOM_TOP [20:38:05] <Dark_Shikari> display top, display bottom, display top [20:38:13] <Dark_Shikari> that means you have 2 coded fields, 3 display fields. [20:38:32] <Dark_Shikari> so frame 1 contains coded fields A and B [20:38:32] <mru> yes [20:38:36] <Dark_Shikari> which map to display fields A,B,C [20:38:42] <Dark_Shikari> frame 2 contains coded fields C and D [20:38:48] <Dark_Shikari> which map to display fields E and F (for example) [20:38:56] <Honoome> why did I accept to work on rails, why? [20:39:04] <mru> Honoome: warned you... [20:40:53] <mru> for actually interlaced content, the field order is of course constant [20:40:58] <Honoome> mru: I'm so close to just declaring myself bankrupt and go sell crap at mediamarkt =_= [20:41:25] <mru> if you're coding progressive frames with pulldown flags, the field order is an invention for display purposes only [20:41:38] <Dark_Shikari> mru: oh, I see where I went wrong [20:41:40] <mru> Honoome: is it that bad? [20:41:43] <Dark_Shikari> if you have pic struct, and you're using it for pulldown [20:41:46] <Dark_Shikari> your content is PROGRESSIVE [20:41:50] <Dark_Shikari> and there is no field order in the stream [20:41:53] <Dark_Shikari> thus tff/bff don't even apply [20:42:17] <mru> to the codec, no [20:42:31] <Dark_Shikari> So the point is, you don't need tff/bff set per frame. [20:42:36] <Honoome> mru: middleware over rails.. the doc is outdated, it no longer supports one of the two formats... yet they kept around the monkeypatching of the 3rd party library that did the processing [20:42:47] <mru> Dark_Shikari: mpeg2 signals it per frame for display purposes [20:43:12] <mru> I still don't see where the problem is [20:43:44] <mru> why do you need to know the field order earlier than together with the first frame? [20:44:23] <Dark_Shikari> Because the codec is initted before the first frame. [20:44:34] <Dark_Shikari> Want to restructure ffmpeg to not require the header before the first frame? [20:44:38] <mru> can't you defer that? [20:44:57] <Dark_Shikari> for global header formats, it requests the header before the first frame, afaik [20:45:07] <Dark_Shikari> Yup [20:45:08] <Dark_Shikari> It does. [20:47:38] <CIA-99> ffmpeg: mru * r24316 /trunk/tests/ (fate.mak fate-update.sh fate2.mak): fate: use helper functions in test rules [20:47:39] <CIA-99> ffmpeg: mru * r24317 /trunk/tests/fate-run.sh: [20:47:39] <CIA-99> ffmpeg: fate: simplify test runner slightly [20:47:39] <CIA-99> ffmpeg: All tests use the provided helper functions so prepending $target_exec [20:47:39] <CIA-99> ffmpeg: and using eval is no longer required. [20:50:54] <CIA-99> ffmpeg: mru * r24318 /trunk/tests/fate-update.sh: fate: ensure all imported rules are handled by helpers [21:14:45] <Dark_Shikari> patch review please [21:14:47] <Dark_Shikari> http://pastebin.org/403140 [21:14:52] <Dark_Shikari> this is bugmaster's patch to make swscale not-broke on win64 [21:15:54] <mru> I predict michael will demand benchmarks with all compilers on all cpus [21:16:01] <mru> and then reject it anyway [21:16:19] <Dark_Shikari> how about I just commit it? [21:16:22] <Dark_Shikari> and hope nobody notices [21:16:36] <Dark_Shikari> It doesn't affect asm output on any arch that isn't broken [21:16:41] <Dark_Shikari> and it fixes it on those where it is [21:16:42] <mru> I think it should all be rewritten in yasm [21:16:47] <Dark_Shikari> oh I agree [21:18:06] <Dark_Shikari> ok, I'm going to give people a while to complain in irc before I commit. [21:19:07] <mru> we also need to fix those damned xmm clobbers [21:19:13] <Dark_Shikari> yes, but that doesn't affect swscale [21:19:17] <Dark_Shikari> it doesn't use sse [21:19:27] <mru> ought it not? [21:19:32] <Dark_Shikari> it should yes [21:19:37] <Dark_Shikari> but michael hasn't worke don it in years [21:19:53] <mru> the code is so horrible to look at it makes my eyes bleed [21:33:34] <Dark_Shikari> mru: fuck. I can't commit it because I don't have mplayer repo commit access. [21:34:01] <Dark_Shikari> mru: can you commit it with this commit message? http://pastebin.org/403233 [21:34:10] <mru> I can give you access [21:34:18] <mru> I think that's fair [21:34:34] <Dark_Shikari> ok [21:34:35] <mru> michael was cross because mplayer devs didn't have automatic rights to ffmpeg [21:34:41] <mru> and libsws is ffmpeg anyway [21:34:49] <Dark_Shikari> ok [21:35:25] <Honoome> mru: any comment about the dprintf vs posix thing? :P [21:36:25] <mru> ff_dprintf [21:37:58] <Dark_Shikari> mru: ping me when I have access [21:38:20] <mru> hmm, you should have access already [21:38:28] <Dark_Shikari> it's asking me for my password [21:38:35] <Dark_Shikari> which I don't even remember because they insisted on making it like 25 characters [21:38:44] <Dark_Shikari> making it less secure [21:38:50] <mru> it's the same as ffmpeg [21:38:54] <Dark_Shikari> I know. [21:38:56] <mru> copy the svn credentials file [21:39:07] <Dark_Shikari> where's that? [21:39:17] <mru> ~/.subversion [21:39:27] <Dark_Shikari> ah there it is [21:39:36] <Dark_Shikari> lol, 22-character alphanumericsymbolic [21:40:10] <Dark_Shikari> does it go to ffmpeg-cvslog? [21:40:14] <mru> yes [21:40:14] <Dark_Shikari> or will they bikeshed me on a different location [21:40:15] <Dark_Shikari> ok [21:43:07] <Dark_Shikari> well, it's in. [21:44:50] <Dark_Shikari> now let's see if fate dies. [21:44:57] <Dark_Shikari> does fate auto update for new swscale revs? [21:44:59] <Dark_Shikari> or only ffmpeg revs? [21:45:52] <mru> only ffmpeg I think [21:46:00] <mru> commit something to trigger it [21:46:00] <Dark_Shikari> so we need one more commit ;) [21:46:03] <Dark_Shikari> lol [21:46:07] * Kovensky sees nothing from CIA anywhere [21:46:27] <Dark_Shikari> cia only tracks ffmpeg, not swscale [21:46:47] <Kovensky> not in #mplayerdev either [21:47:44] <mru> Dark_Shikari: cia tracks both [21:47:49] <mru> but swscale is often delayed a lot [21:47:54] <mru> no idea why [22:01:42] <CIA-99> libswscale: darkshikari * r31751 /trunk/libswscale/swscale_template.c: (log message trimmed) [22:01:42] <CIA-99> libswscale: Another try at fixing swscale on win64, as per r31153. [22:01:42] <CIA-99> libswscale: Don't change paramater passing, but instead use casts. [22:01:42] <CIA-99> libswscale: Shouldn't affect asm output on anything other than win64. [22:01:42] <CIA-99> libswscale: libswscale should work on win64 now. [22:01:43] <CIA-99> libswscale: The rest of ffmpeg still isn't win64 compatible due to the issue of xmm [22:01:44] <CIA-99> libswscale: clobbers, but swscale doesn't use any SSE. [22:21:04] <Tjoppen> finally back in umeå again. have to poke at that pix_fmt_descriptor export stuff tomorrow [22:38:42] <CIA-99> ffmpeg: stefano * r24319 /trunk/libavfilter/ (avfilter.c avfilter.h internal.h): [22:38:42] <CIA-99> ffmpeg: Make avfilter.c dprintf* functions internal and declare them in an [22:38:42] <CIA-99> ffmpeg: internal.h header, so they can be easily used from other files. [22:39:27] <mru> saste: ping [22:40:41] <saste> mru: pong [22:40:58] <mru> I'm looking at lavfi-regression.sh and I'm a bit confused [22:41:15] <mru> the lavfi_pixdesc section [22:41:22] <mru> ref_file=tests/ref/lavfi/lavfi_pixdesc [22:41:28] <mru> rm -f $ref_file [22:41:31] <mru> what's that all about? [22:41:46] <saste> that's a clever trick ;-) [22:41:52] <mru> no it's not [22:41:59] <mru> you must never, ever write in the ref dir [22:42:30] <saste> the idea is to create the reference using the reference of the unfiltered stuff [22:42:47] <mru> the ref dir is for static reference files [22:42:54] <mru> _never_ write to it [22:42:56] <saste> which needs to be the same as the output issued by the files filtered with pixdesctest [22:43:09] <saste> I considered the issue... [22:43:15] <mru> not enough [22:43:25] <mru> it's also failing to run at all [22:43:26] <saste> the alternative I suppose is to provide the reference [22:43:33] <saste> ?? [22:43:46] <mru> tests/ref/lavfi/lavfi_pixdesc: No such file or directory [22:44:45] <saste> I suppose that will happen if you don't have permission to write there... [22:46:01] <mru> but you're not allowed to write there [22:46:03] <mru> I told you that [22:46:08] <saste> anyway fate never complained about that, and the pixdesc test is enabled since the first commit of pixdesctest [22:46:18] <mru> those tests aren't run by fate [22:46:24] <mru> because they don't work [22:46:29] <mru> I'm trying to fix that [22:46:55] <saste> can you confirm that's a permission problem? [22:47:04] <mru> it's a directory not existing problem [22:47:13] <mru> try building outside the source dir [22:47:30] <mru> but that's beside the point [22:47:36] <mru> DO NOT WRITE TO THE REF IR [22:47:38] <mru> DIR [22:48:04] <saste> yes... I already get that... just trying to understand what's failing [22:48:20] <mru> tests/ref doesn't exist in the build dir [22:49:23] <saste> let me think about that... I'll try to come with a solution tomorrow [22:49:56] <mru> just check in the ref file [22:50:29] <saste> the reason for which I started to write in the ref dir is that I needed to write a reference *depending on the supported pixel formats* [22:50:40] <saste> which depend on the machine endiannes [22:50:50] <mru> hmm [22:50:55] <saste> that's why I couldn't have a static reference file [22:51:11] <mru> you're still not allowed to write to the ref dir [22:51:41] <saste> ok but in that case I need to find an alternative solution [22:52:07] <saste> the brute force solution would be to implement support for all pixfmt in both LE/BE [22:52:52] <mru> or choose the ref depending on endianness [22:53:14] <mru> make two tests [22:53:18] <saste> seems feasible [22:53:21] <mru> lavfi_pixdesc_le and _be [22:53:36] <mru> make one depend on bigendian and the other on !bigendian [22:54:28] <mru> also, why is that test prefixed lavfi_ ? [22:54:33] <mru> none of the others are [22:54:43] <saste> BTW the reason for which I didn't committed the other 1-1 lavfi test is that it is failing on LE (i.e. your PPC machine) [22:55:16] <saste> well that was a namespace problem... [22:55:39] <mru> I don't see anything else called pixdesc [22:56:03] <saste> let me recall... I was addressing a specific problem... that or I tried to be future-proof [22:58:26] <saste> there is a test pixfmt in the lavf tests [22:58:55] <saste> then I added the pix_fmts test... since I wanted to avoid potential confusion I decided to add the prefix lavfi [22:59:18] <saste> that was to distinguish regtest-pixfmt from regtest-lavfi_pix_fmts [22:59:19] <mru> I see [23:02:44] <saste> anyway... leave me some days to fix the pixdesctest test issue... then feel free to blame me on ML or ping me here [23:30:30] * Kovensky wonders what would be a good read on DSP (mainly audio stuff for gsoc)

1 0

IRC log for 2010-07-17
by irc＠mansr.com 18 Jul '10

18 Jul '10

[00:31:45] <Dark_Shikari> peloverde: ping [02:40:40] <Compn> oooh [02:40:41] <Compn> idea time [02:41:06] <Compn> mru : what about a cron job that sends a mail to ffmpeg-issues with a filename of every new file uploaded to incoming ? [02:41:16] <Compn> KotH [02:41:48] <Compn> this will finally solve a ton of incoming problems, having an automated bug creation [02:43:18] * Compn sleeps before any more good ideas leak out of his brain [02:45:18] <beandog> dont you want them to leak out? [02:45:32] <beandog> aren't there ftpds with fam? [02:46:09] <Compn> fam ? [02:46:19] <beandog> file alteration monitor [02:47:06] <beandog> anyway [02:47:13] <beandog> im sure theres an ftpd that supports hooks [02:47:40] <beandog> alright, Im gonna go bump stuff now. [02:47:49] <beandog> packages, that is. [02:55:24] <Compn> the order in which to report bugs would change, first > upload file, second > reply to roundup issue. a more advanced script could even move such files into issueXXXX dirs automatically. [05:08:58] <CIA-99> ffmpeg: jai_menon * r24279 /trunk/libavformat/avidec.c: avidec : Free codec context before initializing the chained DV demuxer. [05:27:20] <CIA-99> ffmpeg: mstorsjo * r24280 /trunk/libavformat/aviobuf.c: [05:27:20] <CIA-99> ffmpeg: aviobuf: Do short seeks forward by reading and skipping data instead of a proper seek [05:27:20] <CIA-99> ffmpeg: This improves performance on e.g. seekable http. [05:41:07] <CIA-99> ffmpeg: jai_menon * r24281 /trunk/libavformat/avidec.c: avidec : Free packet if dv_produce_packet fails. [08:01:51] <mru> morning [08:03:18] <mru> thinking about how to build a new fate [08:03:57] <_av500_> KotH: http://www.flickr.com/photos/av500/4801350504/ [08:04:19] <mru> :-) [08:04:58] <thresh> good morning [08:05:29] <mru> it would obviously be nice to keep all the client-side scripts in the ffmpeg repo [08:05:50] <mru> and drive it all from make [08:06:09] <mru> but if the makefiles broke, it wouldn't be able to report that... [08:09:17] <mru> so I guess a separate script is required [08:09:30] <mru> or at least a fully standalone script [08:46:54] <kurosu> Yuvi: (regarding a discussion here some 27H ago) GL_UNPACK_ROW_LENGTH isn't available with OpenGL ES (you have to do the copy line by line yourself), which is what most smartphones and tablets get [08:47:54] <mru> things with GL ES have shared memory anyway [08:49:40] <kurosu> I don't get the point, but whatever, this is the obvious reason for the stride concern Jason reported earlier [09:11:01] <DonDiego> Yuvi: vp8.c:892: warning: suggest explicit braces to avoid ambiguous 'else' [09:20:29] <CIA-99> libswscale: mstorsjo * r31746 /trunk/libswscale/swscale.c: [09:20:29] <CIA-99> libswscale: In planarCopyWrapper, Only copy length, not stride of the last line in the plane [09:20:29] <CIA-99> libswscale: If the destination planes are offset within the destination buffer, [09:20:29] <CIA-99> libswscale: writing the extra bytes at the end may write outside of the destination [09:20:29] <CIA-99> libswscale: buffer. [09:20:52] <ohsix> thats one semicolon away from disaster [09:23:40] <mru> DonDiego: while I agree with the sentiment, that warning is badly phrased [09:23:57] <mru> there is nothing ambiguous about it [09:24:03] <mru> confusing perhaps [09:29:11] <DonDiego> and btw, weren't we going to do away with the parentheses warning? [09:30:14] <mru> is this a different warning? [09:30:28] <DonDiego> yes [10:15:43] <CIA-99> ffmpeg: stefano * r24282 /trunk/ (5 files in 2 dirs): Add color source. [10:44:33] <CIA-99> ffmpeg: diego * r24283 /trunk/libavcodec/ (8 files): [10:44:33] <CIA-99> ffmpeg: Fix Doxygen @param command attribute syntax. [10:44:33] <CIA-99> ffmpeg: The [in] and [out] attributes have to be appended to the @param command. [10:45:08] <CIA-99> ffmpeg: stefano * r24284 /trunk/libavfilter/ (avfilter.h defaults.c): [10:45:08] <CIA-99> ffmpeg: Rename AVFilterPic to AVFilterBuffer. [10:45:08] <CIA-99> ffmpeg: The struct is going to be used for audio data as well, so the new name [10:45:08] <CIA-99> ffmpeg: is less misleading. [10:45:08] <CIA-99> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeenaks AT ucsd DOT edu. [10:48:15] <CIA-99> ffmpeg: stefano * r24285 /trunk/doc/APIchanges: Add APIchanges entry for AVFilterPic -> AVFilterBuffer rename. [10:51:15] <CIA-99> ffmpeg: vitor * r24286 /trunk/tests/ (ref/fate/msmpeg4v1 fate2.mak): [10:51:16] <CIA-99> ffmpeg: Undo my revert at r24260. [10:51:16] <CIA-99> ffmpeg: This is the only way by now to test this codec. [10:51:47] <elenril> saste: +@var{color}:@var{frame_size}:@var{frame_width} << shouldn't the second one be frame_rate? [10:52:22] <saste> yes indeed I missed that... [10:52:36] <saste> going to fix it in few minutes [10:57:54] <CIA-99> ffmpeg: stefano * r24287 /trunk/doc/filters.texi: [10:57:54] <CIA-99> ffmpeg: Fix documentation syntax for the color source, the third parameter is [10:57:54] <CIA-99> ffmpeg: frame_rate, not frame_width. Thanks elenril for spotting it. [11:02:42] <DonDiego> janneg: any progress with latm? :) [11:12:33] <pjay_> hi ! anyone familiar with mmst.c ? i have problems with it and i'm trying to debug it. [12:10:05] <lu_zero> good morning [12:10:14] <mru> morning [12:17:38] <mru> http://www.bbc.co.uk/news/world-europe-10660867 [14:13:58] <markuman> !randnick [15:03:31] <CIA-99> ffmpeg: mru * r24288 /trunk/tests/fate-run.sh: fate: whitespace cosmetics [15:03:31] <CIA-99> ffmpeg: mru * r24289 /trunk/tests/fate-run.sh: [15:03:31] <CIA-99> ffmpeg: fate: add stddev comparator [15:03:31] <CIA-99> ffmpeg: This allows CMP=stddev in test rules. The test passes if the reported [15:03:31] <CIA-99> ffmpeg: stddev is <= the FUZZ value (default 1). [16:35:52] <CIA-99> ffmpeg: cehoyos * r24290 /trunk/libavutil/internal.h: Use attribute force_align_arg_pointer only on x86_32. [17:15:14] <mru> lol basty thinks someone will write a new tracker... [17:16:55] <kierank> what's a tracker? [17:17:17] <kshishkov> module music player [17:17:50] * kierank reads the wikipedia article [17:17:52] <kshishkov> you know, in pattern/note format [17:19:05] <kierank> the only thing i know relating to that is midi [17:19:44] <Dark_Shikari> MIDI is one tracker format [17:19:46] <kshishkov> well, in zeroth approximation it's the same thing [17:20:14] <mru> Dark_Shikari: no, tracker data can be represented as midi [17:20:22] <mru> midi is also a hell of a lot more [17:20:32] <kshishkov> now just imagine MIDI with notes grouped with defined note group order and instruments [17:20:49] <kshishkov> yes, MIDI is also a joystick port :) [17:20:51] <mru> we had a fun flame war about that some time ago [17:21:21] <mru> eventually it emerged that basty had never heard of a moog synth [17:21:30] <Dark_Shikari> LOL [17:21:34] <Dark_Shikari> _what_ [17:21:43] <jai> synths ftw [17:21:43] <Dark_Shikari> I wasn't even alive when those are around and I've heard of them [17:21:49] <mru> which is rather embarrassing for someone allegedly dabbling in electronic music [17:22:00] <mru> they're legendary [17:22:01] * kshishkov still thinks the best synth is called church organ [17:22:22] * mru thought that was maxim [17:23:09] <kshishkov> at least another GSoCer has heard of Therminvox [17:23:30] <spaam> :) [17:23:41] <Dark_Shikari> mru: MIDI is a tracker format in the same way that .doc is a styled text format [17:23:45] <Dark_Shikari> sure, .doc can have images too [17:23:50] <Dark_Shikari> but that doesn't make it less of a text format. [17:24:11] <Dark_Shikari> (images, and macros, and viruses) [17:24:32] <mru> no, it goes much further [17:24:41] <mru> file formats are only a tiny part of midi [17:24:47] <Dark_Shikari> ok, true [17:24:55] <mru> it contains electrical specs for connecting stuff [17:25:03] <mru> and wire protocols [17:25:09] <mru> sync mechanisms [17:25:11] <mru> etc etc [17:25:25] <mru> it's mainly about _playing music_ [17:25:48] <kshishkov> on instruments with digital interfaces [17:25:52] <Dark_Shikari> mru: well it's like MPEG-4 [17:25:56] <Dark_Shikari> there's MPEG-4 part 2 and 10 (video) [17:25:59] <Dark_Shikari> then there's audio [17:26:00] <Dark_Shikari> then there's a container [17:26:01] <Dark_Shikari> etc etc [17:26:05] <Dark_Shikari> all kinds of shit in one spec [17:26:05] <mru> and bifs [17:26:22] <kshishkov> and structured whatever [17:26:27] <mru> seriously though, ask an actual musician about midi [17:26:34] <mru> I bet file formats is not the first thing he'll mention [17:27:06] <kshishkov> mru: don't people remember that sound cards had MIDI ports, for instance? [17:27:21] <mru> evidently not [17:28:11] <kshishkov> well, I cannot say that I was introduced to computers early but even I know that stuff [17:30:35] * kshishkov reflects on it and feels extremely old [17:31:05] * mru reflects in the mirror... nah, still not very old [17:32:11] * kshishkov is not eligible for ungdom biljett anymore - should be very old indeed [17:32:30] <mru> no, that means you're not a kid anymore [17:32:50] <spaam> :) [17:33:01] <spaam> and it will be more expensive.. [17:33:15] <kshishkov> javisst [17:33:21] <Dark_Shikari> I remember midi ports. I used one with a keyboard I had [17:33:42] <Dark_Shikari> fuck, I remember when I could actually play piano. [17:33:54] <mru> spaam: relatively, it's much cheaper for those of us with decent jobs [17:34:03] <mru> spaam: but I guess you wouldn't know much about that [17:34:12] <spaam> mru: not yet.. [17:34:28] <mru> I never played the piano, only with it [17:35:58] <kshishkov> spaam: move to Ukraine, railroad tickets are much cheaper there (service quality is proportional too) [17:37:16] <spaam> kshishkov: no thanks :) next time im going to move will be malmÃ¶ or someplace near :) [17:37:18] <kierank> railrunner is best ticket ever on dutch trains [17:37:48] <kshishkov> spaam: I'd like to move to the north of Gotaland [17:38:06] <spaam> kshishkov: why there? :) [17:38:22] <kshishkov> spaam: too warm for me elsewhere [17:38:25] <mru> stockholm is the only place in sweden worth living [17:38:37] <mru> kshishkov: if you want cold, go to kiruna or something [17:38:47] <spaam> mru: nothing wrong with norrland :) [17:39:04] <mru> spaam: only that it's too cold, too dark, and too far away [17:39:05] <kshishkov> mru: I dreamed of doing that [17:39:08] <mru> and too boring [17:39:32] <kshishkov> mru: if it has Internet access it's not that boring [17:39:36] <spaam> mru: boing ? haha only if you make it [17:39:46] <spaam> boring [17:40:08] <mru> so what would you do? go for a ride on the snowmobile? [17:40:19] <mru> not my idea of fun [17:40:24] <mru> not in the long term at least [17:40:38] <kshishkov> vodka works in long term for Russians [17:40:53] <mru> vodka only masks the boredom [17:41:00] <mru> drunkenness can mask almost anything [17:41:02] <spaam> hembrÃ€nt ;D [17:41:34] <spaam> moonshine in english ;D [17:45:17] <kshishkov> well, Sundsvall seems to be a nice place too [17:45:43] <spaam> umeÃ¥ is much better :) [17:45:55] <spaam> i like that city more :) [17:46:09] * kshishkov tries to guess where spaam was born [17:46:49] <spaam> in a city between umeÃ¥ and sundsvall :) [17:47:20] <kshishkov> I'd rather choose LuleÃ¥ then [17:47:36] <mru> luleÃ¥ at least has a respectable university [17:48:04] * kshishkov knows a guy with email address there [17:48:22] <merbanan> spaam: övik ? [17:48:25] <spaam> merbanan: yes [17:48:34] <spaam> kshishkov: benjamin? ;D [17:48:45] <spaam> i think he has a email from ltu.se. [17:48:58] <merbanan> yeah I think I have that [17:49:07] <spaam> ah its you :) [17:49:15] <merbanan> yes I'm me [17:49:52] <mru> merbanan: if you were not, then who would you be? [17:50:29] <merbanan> someone else of course [17:50:44] <mru> but then who'd he be? [17:50:46] <merbanan> a pure logic deduction [17:51:19] <merbanan> he would be someone else also [17:51:45] <mru> but eventually it would have to come back to someone else being you [17:51:51] <mru> to maintain equilibrium [17:52:13] <kshishkov> mru: and I'm crazy guy [17:52:21] <kshishkov> graduated from KTH [17:52:54] <kshishkov> (with totally different 'K' than in your KTH of course) [18:14:07] <CIA-99> ffmpeg: stefano * r24291 /trunk/libavfilter/ (avfilter.h defaults.c): [18:14:07] <CIA-99> ffmpeg: Remove AVFilterBuffer w and h fields. [18:14:07] <CIA-99> ffmpeg: These fields are never used, and they do not seem to belong to [18:14:07] <CIA-99> ffmpeg: AVFilterBuffer anymore, now that it is now a media-independent [18:14:07] <CIA-99> ffmpeg: structure and these fields are video-related. [18:14:08] <CIA-99> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeenaks ! ucsd ! edu. [18:17:50] <CIA-99> ffmpeg: stefano * r24292 /trunk/doc/APIchanges: Add APIchanges entry after AVFilterBuffer w and h fields removal. [18:28:02] <CIA-99> ffmpeg: stefano * r24293 /trunk/libavfilter/avfilter.h: [18:28:03] <CIA-99> ffmpeg: Clarify AVFilterBuffer documentation, make it clear that it is not [18:28:03] <CIA-99> ffmpeg: necessarily video-related. [18:56:48] <CIA-99> ffmpeg: stefano * r24294 /trunk/libavfilter/avfilter.h: [18:56:48] <CIA-99> ffmpeg: Move the AV_PERM_* flags definition outside the AVFilterPicRef [18:56:48] <CIA-99> ffmpeg: definition. [18:56:48] <CIA-99> ffmpeg: This way it is easier to reference them in other structures, for [18:56:48] <CIA-99> ffmpeg: example in the pending AVFilterSamplesRef struct. [18:56:49] <CIA-99> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeenaks AT ucsd DOT edu. [19:07:02] <mchinen> for parsers is it better to assume the frame length is at it says in the header, or is it better to look over all frame data for a new header? [19:07:38] <mru> go with the header value first [19:07:51] <mru> if you don't find the next frame where it should be, start searching [19:07:54] <mchinen> i would think the first is better, but I see some code that does the second, i guess, to look for interrupted frames. But this is subject to getting unluck [19:08:05] <mchinen> ok [19:08:14] <mru> the mpegvideo parsers must scan the entire frame [19:08:15] <mchinen> thats what i'd prefer too [19:08:18] <mru> there is no size field [19:08:30] <mchinen> i'm rebuilding a flac parser that jason ruggles submitted [19:08:41] <mru> flac parsing is nasty [19:08:50] <mru> there is no size header [19:09:04] <mchinen> hm [19:10:29] <mru> there's only a 16-bit sync word [19:10:42] <mru> which frequently occurs in the payload too [19:11:23] <mru> you have to do something like scan for the syncword, then parse and validate the header following it [19:11:40] <mru> if the header seems weird, keep searching [19:11:55] <mru> there's an 8-bit crc covering the header [19:12:10] <mru> of course there's a 1 in 256 chance it will match randomly [19:12:20] <mchinen> haha [19:12:37] <mru> so when you find a sane header with correct crc, you scan for the next sync word [19:12:49] <mru> at the end of each frame is a 16-bit crc for that frame [19:12:53] <mru> so check that [19:13:01] <jai> is this for seeking in flac? [19:13:09] <mru> jai: yes [19:13:14] <jai> k [19:13:21] <mchinen> yes [19:13:35] <mru> if the header checks out and the frame crc matches, there is still a 1 in 16 million chance it's fake [19:13:38] <mchinen> okay that's pretty much what's in there already [19:14:19] <mru> if the following frame also validates, you're probably good [19:15:11] <mru> if you think 1 in 16M sounds low, consider I have ~130GB of flac files, and my collection is small [19:15:49] <mru> and because it's compressed data, any bit string is as likely as any other [19:15:53] <mru> well, in theory [19:16:22] <mchinen> yeah, the bitrate is much higher so it's more likely. People on the list didn't like the idea of just validating two frames for this reason [19:16:31] <mchinen> (from a thread in mar 09) [19:16:46] <mru> yes, even two frames might not be enough at all times [19:17:15] <mru> if only they'd put some sync emulation prevention in there... [19:17:35] <mru> this is what happens when amateurs design file formats [19:17:38] <mru> or codecs [19:17:43] <mchinen> yeah really. [19:17:46] <mru> compresses well but is a bitch to use [19:19:41] <mchinen> maybe i'll just make the number of subsequent validated frames arbitrary and this will be enough [19:31:24] <spaam> mru: so you can make a better format? ; [19:32:07] <mru> spaam: there are some mistakes I wouldn't make [19:32:17] <jai> better framing maybe [19:32:31] <mru> that would be one thing [19:32:50] <mru> or require external framing [19:32:58] <mru> but that's annoying too

1 0

IRC log for 2010-07-16
by irc＠mansr.com 17 Jul '10

17 Jul '10

[00:00:01] <Dark_Shikari> oh [00:00:03] <Dark_Shikari> you forgot top left [00:00:06] <Dark_Shikari> that's why it breaks. [00:00:08] <Yuvi> ah! [00:00:19] <Dark_Shikari> fyi, if you commit that, I have a patch that requires that. [00:00:27] <Dark_Shikari> so we can get double the fun. [00:03:34] <Yuvi> how does h264.c save tl? [00:06:14] <Dark_Shikari> the way x264 does it is that it does the backup per-row [00:06:32] <Dark_Shikari> i.e. one big memcpy (well, three) at the end of encoding a row [00:20:51] <Dark_Shikari> Yuvi: got it to work? [00:25:38] <Yuvi> Dark_Shikari: not quite, think I'm not handling the 129 on the left right [00:52:27] <pengvado> Dark_Shikari: nv12 patch changed that, it now does backup per mb. [01:49:06] <Compn> Google Spent $100 Million Defending YouTube Against Viacom [01:49:07] <Compn> wow [01:54:33] <saintdev> peloverde: could the bark averaging because of the overlap? [02:25:37] <Dark_Shikari> pengvado: ah, ok [02:45:53] <saintdev> actually that doesn't make sense :/ [02:52:33] <Dark_Shikari> Yuvi: http://pastebin.org/398567 [02:52:35] <Dark_Shikari> here's my patch [02:58:25] <Yuvi> looks good to me once I figure out why border saving isn't working for the simple lf... [02:58:48] <Dark_Shikari> btw, where's the part where it adapts strength based on whether the block is coded or not? [02:58:52] <Dark_Shikari> I can't find it [02:58:57] <Dark_Shikari> also, how often do those ifs trigger in the filter strength function? [02:59:00] <Dark_Shikari> i.e. which parts are common? [02:59:06] <Dark_Shikari> also, how much of that can we precalculate? [02:59:25] <Yuvi> it doesn't adapt based on coded or not, being coded only influences whether the lf is run at all [02:59:56] <Yuvi> don't have any stats on the if()s other than sharpness is rare [03:00:20] <Yuvi> and level is generally 10-25 or so [03:01:21] <Dark_Shikari> but where is the coded thing run? [03:01:24] <Dark_Shikari> I don't see that check [03:01:35] <Yuvi> if (!mb->skip ... [03:01:49] <Yuvi> mb borders are always filtered [03:02:12] <Dark_Shikari> so we still have to calculate the limit even if it's skipped. [03:02:13] <Dark_Shikari> ok [03:02:19] <Dark_Shikari> s->lf_delta.enabled [03:02:22] <Dark_Shikari> is that usually on? [03:02:31] <Dark_Shikari> because if it isn't, filter_level is constant frame-wide [03:02:53] <Yuvi> iirc yes [03:02:55] <Dark_Shikari> ok [03:03:03] <Dark_Shikari> if (mb->ref_frame == VP56_FRAME_CURRENT) { [03:03:05] <Dark_Shikari> seems unnecessary [03:03:09] <Dark_Shikari> in filter_level_for_mb [03:03:18] <Dark_Shikari> the ref_frame check period seems unnecessary [03:03:49] <Dark_Shikari> it seems like we could convert this to [03:03:54] <Yuvi> hm [03:03:59] <Dark_Shikari> filter_level = array[segment][ref][mode] [03:04:11] <Dark_Shikari> ane eliminate all the logic above "interior_limit = filter_level" [03:04:23] <Dark_Shikari> similarly, hev_thresh can be made into a lut [03:04:30] <Dark_Shikari> a quantized lut of some sort [03:07:08] <Yuvi> a [4][2][9] array sounds reasonable [03:11:03] <Yuvi> I know libvpx has at least a 63*16 table for filter level, can't remember exactly what they do [03:19:07] <saintdev> peloverde: ping [03:30:28] * Yuvi stabs the 127/129 non-pixels in vp8 [04:14:54] <Yuvi> Dark_Shikari: http://pastie.org/1046739 [04:14:55] <Yuvi> I kept the 3 memcpy since removing them meant more code per-mb [04:19:46] <Yuvi> I think I'll try to implement edge emu now, maybe really get rid of them [06:10:31] <astrange> if you're going to use int simple... try av_always_inline instead of inline [06:38:15] <av500> m0rn1ng [06:40:34] <mru> moroning [06:45:55] <Dark_Shikari> Yuvi: if it works, feel free to commit really [07:17:55] <KotH> moin [07:18:25] <kshishkov> gruess dich [07:20:53] <Yuvi> added av_always_inline, got rid of those 3 memset, and committed [07:21:22] <CIA-99> ffmpeg: conrad * r24251 /trunk/libavcodec/vp8.c: vp8: Check for malloc failure [07:21:23] <CIA-99> ffmpeg: conrad * r24252 /trunk/libavcodec/vp8.c: [07:21:23] <CIA-99> ffmpeg: vp8: Save mb border needed for intra prediction so that loop filter can run [07:21:23] <CIA-99> ffmpeg: immediately after a mb row is decoded [07:21:43] <Dark_Shikari> Yuvi: want to merge my changes as well? [07:22:21] <Yuvi> sure [07:22:31] <Yuvi> paste it again? lost my scrollback [07:26:09] <Dark_Shikari> 10:52 <@Dark_Shikari> Yuvi: http://pastebin.org/398567 [07:26:09] <Dark_Shikari> 10:52 <@Dark_Shikari> here's my patch [07:26:14] <Dark_Shikari> 11:03 <@Dark_Shikari> if (mb->ref_frame == VP56_FRAME_CURRENT) { [07:26:14] <Dark_Shikari> 11:03 <@Dark_Shikari> seems unnecessary [07:26:22] <Dark_Shikari> 11:03 <@Dark_Shikari> it seems like we could convert this to [07:26:22] <Dark_Shikari> 11:03 <@Yuvi> hm [07:26:22] <Dark_Shikari> 11:03 <@Dark_Shikari> filter_level = array[segment][ref][mode] [07:26:22] <Dark_Shikari> 11:04 <@Dark_Shikari> ane eliminate all the logic above "interior_limit = filter_level" [07:26:28] <Dark_Shikari> there's the relevant info [07:42:23] <Dark_Shikari> Yuvi: btw, does this mean we can dump the !emulated_edge requirement? [07:42:34] <Yuvi> not yet, working on that too [07:43:13] <Dark_Shikari> imo should feel free to commit whatever you want to vp8.c that doesn't break it, at this point we're the only maintainers so we don't really need ML discussion for most stuff [07:44:06] <mru> Dark_Shikari: but isn't !emu faster? [07:44:14] <Dark_Shikari> mru: it breaks direct rendering [07:44:21] <mru> only with stupid apps [07:44:32] <Dark_Shikari> opengl textures don't allow arbitrary stride [07:44:40] <mru> so don't use arbitrary stride [07:44:51] <Dark_Shikari> You can't pad the edges if the stride isn't arbitrary. [07:44:51] <Yuvi> Dark_Shikari: um, they do [07:44:52] <mru> pad it up to whatever [07:45:01] <Dark_Shikari> Yuvi: our opengl guy kept telling us that you can't. [07:45:13] <mru> surely opengl allows padded lines [07:45:16] <Dark_Shikari> that calls like ReadPixels only wrote to a buffer, not an arbitrary stride buffer [07:45:25] <Dark_Shikari> is the opposite of that (write pixels, I guess?) more flexible? [07:45:27] <Yuvi> I distinctly remember experimenting with weird strides with opengl [07:45:34] <mru> if it requires more alignment than lavc, that's fine [07:45:38] <mru> just give it that [07:45:44] <Dark_Shikari> iirc, it didn't use any alignment at all [07:45:46] <Dark_Shikari> just the width [07:45:54] <mru> I can't believe it's that stupid [07:45:55] <Dark_Shikari> whatever, I'm probablyw rong. [07:45:55] <Dark_Shikari> Anyways [07:46:02] <Dark_Shikari> There are two right ways to do it [07:46:06] <Dark_Shikari> 1) emulate edges, don't pad [07:46:09] <Dark_Shikari> 2) pad, don't emulate edges [07:46:13] <Dark_Shikari> currently, we emulate edges AND pad. [07:46:15] <Dark_Shikari> This is retarded. [07:46:17] <mru> yeah [07:49:36] <kshishkov> why emulate edges at all? There's usually not enough of them for MC anyway [07:50:35] <Yuvi> ah, glTexImage2D does indeed not take a stride, but it's trivial to map the texture to discard excess stride [07:51:21] <Yuvi> or setting GL_UNPACK_ROW_LENGTH works too [07:51:47] <Yuvi> Dark_Shikari: so tell your opengl guy to look into GL_UNPACK_ROW_LENGTH [07:53:23] <Dark_Shikari> does it work for the reverse? [07:53:31] <Dark_Shikari> _writing_ pixel data to a strided buffer? [07:53:44] <astrange> http://developer.apple.com/mac/library/samplecode/TextureUpload/Introductio… read that if you haven't [07:53:57] <Dark_Shikari> this is moreso texture download than upload [07:54:02] <Yuvi> should [07:54:08] <av500> does it explain the iphone 4 antenna issue? [07:54:27] <Yuvi> astrange: unfortunately noone but apple implements those extensions [07:55:22] <wbs> Yuvi: texture_rectangle_ext/arb is quite widely available [07:55:43] <Yuvi> wbs: I meant texture range and client store [07:56:00] <wbs> ah, yes, those are a different matter [07:59:35] <kshishkov> av500: there is an explanation - "you're not cool enough to use it" [08:00:09] <av500> no, you are holding it wrong! [08:02:42] <Yuvi> hm, should I be lazy and reuse put_pixels or copy it and use a smaller stride [08:03:30] <_troll_> no temp buffers with full stride please [08:03:33] <_troll_> if it can be avoided [08:04:12] <Dark_Shikari> what do you need put pixels for? [08:04:40] <Yuvi> Dark_Shikari: for edge emu + intra pred, I'm predicting into a temp buffer then copying to the actual frame [08:04:58] <Yuvi> for the top/left row only ofc [08:05:28] <Dark_Shikari> what does h264 do? [08:05:42] <Yuvi> not predict from pixels outside the frame afaik [08:06:19] <Yuvi> so it complains about an invalid bitstream and uses some other mode [08:08:21] <Dark_Shikari> ah yeah, you're right [08:08:35] <Dark_Shikari> it's ironic that vp8's "simplification" makes it harder and more complicated [08:09:44] <_troll_> they simplified the spec, not the implementation [08:09:54] <Yuvi> it's simpler for them [08:10:04] <Yuvi> they always intra pred to a temp buffer [08:10:06] <_troll_> which is odd, considering those are one and the same [08:11:02] <Dark_Shikari> I do agree that eliminating the need to check intra pred modes is a good thing [08:11:34] <Yuvi> except you still have to check DC on the edge [08:11:48] <Yuvi> ...but not for 4x4 [08:12:24] <Dark_Shikari> that's retarded [08:12:36] <Dark_Shikari> well, actually, it makes sense really compression-wise [08:12:38] <Dark_Shikari> but it kinda goes against the point. [08:13:22] <Yuvi> I kinda want to know why 127/129 and not just 128 [08:13:45] <Dark_Shikari> to be different from h264 [08:14:37] <Yuvi> h264 only uses that for the first block though, which vp8 winds up doing too if it uses DC (which the encoder does) [08:16:03] <Yuvi> copy_pixels sounds like a good name for a put_pixels with 2 strides? [08:17:07] <Dark_Shikari> sounds good [08:20:59] <_troll_> a lot of things in dsputil should have had 2 strides [08:21:29] <Dark_Shikari> _troll_: agreed [08:21:54] <Dark_Shikari> the real problem with ffmpeg dsp functions is that so many things share them [08:21:58] <Dark_Shikari> I mean, obviously there's no solution [08:22:07] <Dark_Shikari> but e.g. in x264, if a function would be better with another arg [08:22:10] <Dark_Shikari> we can just add it and bam [08:22:35] <_troll_> we can theoretically do that in ffmpeg too [08:22:41] <_troll_> but it's a huge undertaking [08:22:51] <_troll_> and will never leave the bikeshed [08:24:09] <Dark_Shikari> Exactly [08:24:16] <Dark_Shikari> that's pengvado's main reason for why x264 isn't part of ffmpeg [08:24:26] <Dark_Shikari> if you share code among 10 different en/decoders, it's harder to change anything [08:24:36] <Dark_Shikari> changing x264 to use nv12 was hard enough, imagine changing ffmpeg to use nv12. [08:25:30] <astrange> well changing a decoder would be harder anyway [08:25:55] <Dark_Shikari> why's that? [08:25:57] <Dark_Shikari> encoders are more complicated [08:26:39] <astrange> you're outputting the yv12/nv12 and don't want to convert it or break clients that don't know about the new one [08:26:50] <kshishkov> Dark_Shikari: please train on ZMBV codec to use NV12 [08:27:17] <Dark_Shikari> astrange: deinterleave it for legacy clients [08:28:11] <Dark_Shikari> but yeah, trickier [08:35:53] <pJok> god morgon kshishkov :) [08:36:39] <av500> kshishkov: your train overview is lacking [08:38:14] <_troll_> speaking which, the berlin s-bahn runs pretty far from the city [08:38:23] <_troll_> all the way to spandau as av500 can tell you [08:38:34] <_troll_> and potsdam [08:38:35] <av500> well, not at the times when I needed it... [08:38:56] <av500> but that's what S-Bahns do in general [08:39:13] <av500> running pretty far [08:40:07] <_troll_> the stockholm "tunnelbana" also runs rather far, and above ground too [08:41:53] <pJok> as does the copenhafen metro for quite a long way outside the city center [08:41:59] <av500> http://www.forgotten-ny.com/SUBWAYS/9thavel/9Ave.html [08:42:02] <pJok> copenagen* [08:42:31] <pJok> and the s-train lines all run above ground exceppt for one station [08:44:07] <_troll_> the stockholm equivalent of s-bahn runs further though [08:44:21] <_troll_> and now they're building a tunnel for it under the city [08:44:33] <pJok> yeah, T-banan covvers quite a big area [08:45:09] <_troll_> and it has the best trains of any underground system I've tried [08:45:28] <pJok> didn't get to try them when i was actually in stockholm [08:45:35] <pJok> i do like the metro trains in copenhagen [08:45:42] <pJok> since they are driverless [08:45:56] <_troll_> the trains were all replaced starting in the mid 90s [08:46:26] <_troll_> the best bit is they run almost silently [08:46:32] <_troll_> you can actually talk inside them [08:46:39] <_troll_> not shout [08:46:39] <pJok> the only older trains in the copenhagen area are the regional trains rolling stock from the 60s [08:47:10] <pJok> X2000 is crap [08:47:27] <_troll_> I'd say it's pretty good [08:47:36] <Yuvi> hm, vp8's mc functions take 2 strides [08:47:37] <pJok> inside tthey look like SJ's old waggons [08:47:55] <_troll_> I don't mind them [08:48:03] <Yuvi> there are too many functions that do put_pixels with different arguments already :/ [08:48:07] <_troll_> it's not as fast as tgv perhaps [08:48:23] <_troll_> though I've never been on the tgv [08:48:25] <_troll_> only the korean clone [08:48:27] <pJok> nothing in sweden is as fast as tgv/agv [08:48:35] <av500> I havte TGV seats [08:48:37] <av500> hate [08:48:38] <pJok> its just a s boring as denmark [08:48:44] <av500> ICE are much better [08:48:55] <pJok> at least sweden has decided to use 250km+ trains [08:48:57] <av500> (in 1st class) [08:49:04] <pJok> denmark says that 180 is more than enough for anyone [08:49:10] <_troll_> av500: the swedish trains don't melt in hot weather [08:49:24] <av500> yep [08:49:29] <pJok> mru, and they don't die from snow... well, a bit [08:49:38] <_troll_> x2000 usually runs [08:49:51] <pJok> they ran out of X2000 trains this winteer [08:49:57] <pJok> that was not fun [08:49:58] <av500> pJok: http://ahoipolloi.blogger.de/stories/1663338/ [08:50:10] <pJok> since they also ran out of öresundståg [08:50:48] <pJok> av500, noone likes DB ;) [08:51:22] <av500> they will be DubaiBahn soon.... good riddacne [08:51:37] <pJok> i still don't understand why i can buy a tickeet to berlin that costs the same as a ticket home from work [08:51:51] <_troll_> av500: their website is mostly ok [08:51:55] <av500> yes [08:51:58] <av500> well [08:52:03] <_troll_> it's much better for looking up swedish trains than the swedish website [08:52:04] <pJok> plane vs train that is [08:52:28] <av500> _troll_: they revambed it a bit [08:52:30] <av500> p [08:52:31] <pJok> mru, SJ's site sucks... DB's site is also better for looking up danish trains [08:52:34] <_troll_> pJok: because the ICE is the train equivalent of the concorde [08:52:38] <pJok> or at least, it used to be [08:52:39] <av500> and the android app is cool [08:52:52] * kshishkov thinks his post was rather good as an unitented troll [08:52:58] <av500> we all know what becaome of the concorde... [08:53:12] <av500> it also had heat issues [08:53:12] <pJok> #ffmpeg-trains [08:53:14] <pJok> ;) [08:53:16] * _troll_ saw one standing at heathrow in june [08:53:29] <kshishkov> pJok: actually, it was easier to me to use SJ site for buying tickets than DB [08:53:36] <_troll_> av500: yes, the passengers were full of hot air [08:53:42] <av500> http://mentalfloss.cachefly.net/wp-content/uploads/2009/03/ACCIDENT.jpg [08:53:53] <pJok> kshishkov, funny... i [08:53:56] <av500> AC overload I guess [08:54:18] <pJok> i'd expect them both to be equally annoying because of all the ways you can select a ticket [08:55:20] <kshishkov> Db site is just more confusing [08:55:28] <pJok> kshishkov, i hope never to have to buy my SJ ticket on tradera though... [08:57:03] <kshishkov> pJok: at least it was rather mildly amusing buying ticket Copenhagen->Stockholm at DB in Munich [08:57:19] <pJok> were they confused? [08:57:24] <kshishkov> not at all [08:58:42] <pJok> at least, if you are two people, its cheaper and faster to take the car from copenhagen to hamburg than the train and still cheaper than the plane [08:59:08] * kshishkov is rather not fit for cars [08:59:31] <pJok> even when having to buy a green "umwelt zone" thingie for my car [09:00:24] * kshishkov still prefers trains unless in Ukraine [09:00:31] <twnqx> pJok: depends on the gar and your driving habits :P [09:00:35] <twnqx> car* [09:00:49] <pJok> i do find it mildly amusing that i could have said pretty much anything to the person i bought that thing from... they didn't even look at the car or the registration papers, only wanted the license plate so they could print a strip to put on it [09:01:12] <pJok> twnqx, my car does 10l/100km... and 193km/h on the top [09:01:42] <twnqx> see... my average is 16, and more like 25 @250 [09:01:54] <_troll_> germans... [09:02:13] <pJok> the 10l/100km is @~150 [09:02:48] <pJok> but it still cheaper than taking the train if you are two people [09:03:32] <av500> only because you already pay for the car anyway [09:04:00] <pJok> my car did cost 295eur ;) [09:04:14] * kshishkov would like Sweden to have Europabanan [09:04:15] <thresh> .65 EUR for litre of gas here, so it almost always cheaper to travel by car in Russia [09:04:17] <pJok> insurance on it is more expensive [09:04:50] <thresh> and 0.5 EUR for litre of diesel fuel... [09:04:52] * pJok would like all of scandinavia to have europabahn [09:04:57] <kshishkov> thresh: lack of proper public transport helps [09:05:42] <thresh> i was quite amazed on the queue lines on RU-EST border. they all went to Russia just to full their tanks.. [09:06:16] <kshishkov> pJok: that sounds German. But proper (i.e. without electricity standard change in some quirky place) railroad from Sweden to the rest of Europe would be good. [09:06:49] <pJok> kshishkov, it would... but denmark is too stubborn and german can't be arsed [09:06:56] <pJok> sweden on the other hand... [09:07:20] <_troll_> the trains seem switch power systems quite ok when going to denmark [09:07:30] <pJok> mru, it works [09:07:36] * pJok uses it every day [09:07:39] <pJok> as does the freight trains [09:08:34] <kshishkov> especially diesel ones [09:08:51] <pJok> denmark is still buying diesel trains because they haven't electrified the main lines [09:09:04] <_troll_> swedish trains are nuclear-powered, right? [09:09:06] <pJok> and because they are still buying diesel trains, they wont electrify the rest of the main lines [09:09:13] <pJok> they are [09:09:37] <kshishkov> catch-22 in action [09:09:41] <pJok> yeah [09:09:47] <pJok> it was the same problem 20 years ago [09:09:54] <av500> not 22ys? [09:10:00] <pJok> probably [09:10:29] <_troll_> swedish railways are almost entirely electrified [09:10:35] <pJok> of course [09:10:40] <pJok> sweden has nucelar power [09:10:47] <CIA-99> ffmpeg: vitor * r24253 /trunk/tests/fate2.mak: Add AC3 regtests [09:10:57] <_troll_> there are few obscure lines without electricity [09:11:02] <pJok> and their trains have that "bra miljöval" bird logo on them [09:11:03] <_troll_> inlandsbanan for example [09:11:44] <pJok> well [09:11:45] <kshishkov> pJok: Ukraine has world-famous nuclear power, so what? [09:12:08] <kshishkov> pJok: and locos from Czech and USSR older than you [09:12:10] <_troll_> kshishkov: you're doing your best to make the trains famous too [09:12:11] <pJok> kshishkov, but they aren't giving it away... and the russians cut off their gas every time they start to argue over the price [09:12:39] <kshishkov> _troll_: if you ever see Rc6 model, please buy one for me [09:13:06] <_troll_> RC6 is a good one [09:14:00] <pJok> kshishkov, should be available in any swedish model train shop [09:14:11] <kshishkov> pJok: an address, please [09:14:17] <_troll_> stockholm [09:14:28] <kshishkov> more details, please [09:14:35] <pJok> hehe [09:14:54] <_troll_> stockholm is a small city [09:14:58] <_troll_> no need for more detail [09:14:58] * kshishkov has looked only in GÃ€vle for some reason [09:15:39] <pJok> Gefle? the only thing happening there is a goat gets burned every year [09:16:10] <kshishkov> _troll_: well, should I start with SkÃ€rholmen and Rinkeby and leave Norrmalm and Gamla Stan till the end? [09:16:35] <_troll_> africa and the middle east are not in stockholm [09:16:36] <kshishkov> pJok: http://sv.wikipedia.org/wiki/Sveriges_j%C3%A4rnv%C3%A4gsmuseum [09:20:09] <pJok> kshishkov, funny enough, i've passed by the one in ängelholm quite a few times, but i've never been there [09:20:50] <kshishkov> pJok: I'm shocked. Probably you've never visited Danish one as well? [09:21:01] <pJok> the one in Odense? [09:21:08] <pJok> negative [09:21:11] <kshishkov> don't remember where [09:21:23] <kshishkov> ans isn't Odense known for some pervert? [09:21:25] <pJok> i have, however visited sporvejsmuseet outside roskilde [09:21:40] <pJok> yeah, that H.C. Andersen guy with the little mermaid [09:22:09] * kshishkov is proud to omit seeing it in Copenhagen [09:24:58] <CIA-99> ffmpeg: vitor * r24254 /trunk/tests/fate2.mak: Add EAC3 regtests [09:25:07] <pJok> how big is the one in Gävle? [09:25:15] <pJok> the one in Ängelholm doesn't look very big [09:25:21] <_troll_> we really need to get mike to run those new tests [09:25:33] <_troll_> or more realistically, set up a new fate system [09:25:48] <pJok> mru, go go go [09:25:56] * pJok goes to find the bikeshed paint [09:26:10] <_troll_> no need for that [09:26:23] <_troll_> I do whatever I want with the tests [09:26:58] <_troll_> at some point, I just started doing stuff without asking, and nobody complained... [09:27:16] <pJok> people are afraid of you ;) [09:27:19] <kshishkov> pJok: one standard steam train depot with exposition, another one for repairs and stuff, station house and small park [09:27:41] <kshishkov> pJok: nonsense - I'm not afraid of him, even now [09:28:15] <_troll_> that's only because the shotgun isn't allowed in the office [09:28:24] <kshishkov> or on planes [09:28:28] <pJok> hehe [09:28:42] <_troll_> you have no idea what it's possible to bring on a plane [09:28:44] <pJok> how far do you actually sit from each other? same office? [09:29:15] <kshishkov> _troll_: neither does airport security, so they forbid everything [09:29:31] <kshishkov> pJok: yes, almost in a hand reach [09:29:44] <_troll_> kshishkov: so don't bring it through security [09:30:01] <pJok> kshishkov, friend of mine had a bottle of water with him when we went to gran canaria... i don't think they had the machine turned on that day since noone complained about it [09:30:37] <_troll_> I've had toothpaste etc packed normally many times without anyone saying anything [09:30:46] <pJok> its stupid [09:30:51] <_troll_> they found a bottle of water I'd forgotten about once [09:31:02] * kshishkov remembers the smallest airport he's ever been to - you have to do a lot of security stuff by yourself there [09:31:03] <pJok> security circus of the policians [09:31:38] <kshishkov> pJok: it's called "CYA" [09:31:42] <_troll_> I reckon it's quite easy to sneak something in with some goods delivery [09:33:39] <kshishkov> guess why Ukrainian airports have such service as packing your baggage into plastic wrapping? [09:34:13] <pJok> do they pack your lunch as well? ;) [09:34:52] <_troll_> in soviet russia, the lunch packs you [09:35:45] <kshishkov> it's done to prevent tampering with your baggage - when I flew to homeland a year ago, my bag went rummaged through [09:36:00] <av500> _troll_: in soviet russia lunch hunts in packs [09:36:20] <CIA-99> ffmpeg: vitor * r24255 /trunk/tests/fate2.mak: Add ATRAC1 regtest [09:36:25] <pJok> at least it means that if your luggage is lost, its lost with a lot of other peoples luggage [09:37:23] <kshishkov> pJok: yes, had that wonderful experience too. With Danish branch of SAS [09:38:19] <pJok> fun [09:38:25] * pJok is waiting for SAS to finally die [09:38:40] <Honoome> serial attached scsi? [09:38:54] <pJok> scandinavian airline service [09:38:56] <kshishkov> Scandinavian Air (dis)Service [09:39:04] <pJok> or lack there of... [09:39:10] <av500> I thought SAS makes u die.... [09:39:16] <pJok> thats SARS [09:39:28] <_troll_> svenskt allt sammen, no? [09:39:32] <av500> http://en.wikipedia.org/wiki/Special_Air_Service [09:39:58] <_troll_> yes, that airline is, er..., "special" [09:40:29] <kshishkov> _troll_: and again, their HQ is in Denmark which is rather suspicious [09:42:40] <CIA-99> ffmpeg: vitor * r24256 /trunk/tests/fate2.mak: ATRAC3 regtests [09:59:09] <CIA-99> ffmpeg: vitor * r24257 /trunk/tests/ (ref/fate/gsm fate2.mak): Add MS-GSM regtest [10:07:29] <CIA-99> ffmpeg: vitor * r24258 /trunk/tests/ (ref/fate/msmpeg4v1 fate2.mak): Add msmpeg4v1 regtest [10:09:17] <_troll_> Vitor1001: we already test msmpeg4 [10:09:17] <CIA-99> ffmpeg: vitor * r24259 /trunk/configure: Nit: fix alphabetical order [10:09:31] <Vitor1001> - [10:09:39] <Vitor1001> _troll_: :p [10:09:48] <Vitor1001> Where? We encode for it? [10:09:50] <_troll_> yes [10:10:31] <Vitor1001> msmpeg4 == msmpeg4v1? [10:10:36] <_troll_> yes [10:11:12] <Vitor1001> why do we have redundant identifiers? [10:11:39] <_troll_> we don't [10:12:04] <Dark_Shikari> we have always been at war with eurasia [10:12:08] <Dark_Shikari> also, webm/matroska [10:12:32] <av500> mkv,webm ftw [10:12:50] <Dark_Shikari> COMMAS OMG PANIC [10:13:11] <_troll_> sorry, I thought it would break more than it did [10:13:28] <_troll_> and had baptiste stayed out of the fray it would have been fine [10:13:39] <av500> thou art forgiven [10:13:41] <_troll_> but he never passes up a chance to go up against me [10:14:48] <Vitor1001> _troll_: According to libavcodec/msmpeg4.c, msmpeg4 == msmpeg4v3... [10:14:58] <kshishkov> _troll_: he once played a game of kicking with Dark_Shikari, so he treats you rather nice [10:15:06] <_troll_> yes, but the msmpeg4 _test_ tests v1 [10:16:01] <Vitor1001> _troll_: Ok, I'll trust you in this one... [10:16:25] <_troll_> hold on [10:19:33] <_troll_> there's an inconsistency [10:19:45] <_troll_> the msmpeg4 test does indeed test v3 [10:19:48] <_troll_> the deps are wrong [10:19:51] <_troll_> probably my fault [10:20:11] <CIA-99> ffmpeg: vitor * r24260 /trunk/tests/ (ref/fate/msmpeg4v1 fate2.mak): (log message trimmed) [10:20:11] <CIA-99> ffmpeg: Revert r24258: [10:20:11] <CIA-99> ffmpeg: Log: [10:20:11] <CIA-99> ffmpeg: Add msmpeg4v1 regtest [10:20:11] <CIA-99> ffmpeg: Added: [10:20:12] <CIA-99> ffmpeg: trunk/tests/ref/fate/msmpeg4v1 [10:20:12] <CIA-99> ffmpeg: Modified: [10:20:23] <_troll_> but it's still better to add an encode/decode test [10:27:43] <_troll_> hmm, this is ungood [10:31:00] <_troll_> the encoder seems broken [10:37:17] <av500> _troll_: wrt msmpeg4, I found it annoying that its CODEC_ID_MSMPEG4V3, but the codec is msmpeg4 only [10:37:29] <_troll_> yes, I found that too just now [10:40:27] <CIA-99> ffmpeg: mru * r24261 /trunk/configure: Fix dependencies for msmpeg4v3 regression test [10:45:15] <av500> http://ffmpeg.pastebin.com/pgCU1UUq [10:47:28] <kshishkov> av500: s/wmv1/msmpeg4v4/, s/wmv2/msmpeg4v5/ too [10:47:54] <_troll_> av500: now _that_ could break apps relying on the name... [10:49:47] <av500> yes [10:50:15] <av500> but its totally annoying that you have to configure using "msmpeg4v3" to get -codecs spit out "msmpeg4" [10:50:43] <av500> kshishkov: and H265 is H261V42 [10:51:20] <_troll_> av500: agreed [10:51:32] <av500> cant configure at least accept msmpeg4? [10:51:56] <_troll_> configure pulls the list from allcodecs.c [10:52:18] <kshishkov> av500: it's "H.261v3/H.26L/AVC/H.264/MPEG4p10/..." - as a single codec ID [10:54:23] <Dark_Shikari> >h261v3 [10:54:24] <Dark_Shikari> lol [10:57:36] <Vitor1001> _troll_: Can you revert my revert? [11:00:15] <_troll_> ideally we should fix the encoder [11:00:53] <kshishkov> Vitor1001: and then MN will his revert of your revert and leave you both without commit rights for abusing SVN [11:01:03] <Vitor1001> lol [11:01:19] <_troll_> I can't look at the encoder now [11:01:24] <Vitor1001> Well, if I revert myself again it is not a revert-war, no? [11:01:34] <_troll_> Vitor1001: leave it for now [11:01:39] <_troll_> I'll have a look at the encoder tonight [11:01:42] <Vitor1001> ok [11:01:49] <_troll_> hopefully it's something simple to fix [11:01:55] <kshishkov> Vitor1001: no, it's called "schizophrenia" [11:02:11] <Vitor1001> kshishkov: Does we have a policy against that? [11:02:12] <Vitor1001> ;) [11:02:24] <_troll_> some of our personalities do [11:12:39] <J_Darnley> make [11:12:42] <J_Darnley> oops [12:14:42] <spaam> J_Darnley: fail :P [12:33:02] <CIA-99> ffmpeg: vitor * r24262 /trunk/tests/fate2.mak: Vorbis regtests [12:38:01] <CIA-99> ffmpeg: mru * r24263 /trunk/tests/ref/fate/vc1: fate: update vc1 reference [13:03:38] <CIA-99> ffmpeg: pross * r24264 /trunk/libavcodec/pcm.c: Use designated initialisers for pcm codec struct [13:10:24] <kshishkov> congratulations to you and your ... structure, pross-au [13:12:03] <pross-au> Cheers [13:12:13] <pross-au> Now where's my, sorry, our GIFT. [13:12:16] <av500> may it have many offspring [13:12:33] <pross-au> pcm is ugly [13:12:44] <kshishkov> like ea_layer3_decoder struct [13:12:59] <pross-au> ahhh [13:13:34] <pross-au> Must revisit that someday. Maybe 2012 [13:16:18] <kshishkov> I'll produce BINKb decoder by then [13:16:47] <pross-au> Careful now. Dont write cheques you can't honour [13:17:17] * kshishkov somehow grew in land without cheques [13:18:02] <kierank> what did you have instead? [13:18:15] <pross-au> Ciao kostya [13:18:18] <av500> queues [13:18:31] * mru has never written a cheque [13:18:43] <mru> cash and credit cards work fine [13:19:09] <av500> cheques were cool [13:19:26] <mru> sure, they were a neat invention back in the day [13:19:43] <av500> and for c2c transactions, you could not use credit cards [13:19:43] <mru> but they were surpassed by 24h cash machines and plastic cards [13:19:44] <kierank> paying in cheques is very annoying [13:19:57] <kshishkov> kierank: hard cash, we called it "wooden" for some reason [13:20:20] <kierank> you've got to fill out the paying in form. then fill out the form on the envelope and give it in to the teller or god forbid try and get one of those cash depost machines to work [13:20:37] <av500> one form here only [13:21:08] <kierank> unsuprisingly your country is known for its efficiency [13:21:22] <av500> well, no form now, as no more cheques [13:21:46] <av500> and they try hard to get rid of all income to people, so all the spending questions will be solved.... [13:22:41] <kshishkov> kierank: and it's very religious - people pray before trying to withdraw money from ATM [13:23:51] <mru> in soviet russia, atm withdraws you [13:25:04] <mru> that happens elsewhere too: http://www.theregister.co.uk/2007/03/16/carnivore_atm/ [13:25:09] <kshishkov> even I had my money ate by ATM ones [13:25:15] <kshishkov> s/ate/eaten/ [13:25:29] <mru> you're not supposed to put money in the machine [13:26:03] <kshishkov> no, it was supposed to give them to me, but it printed receipt, withdrew them from my account and that's all [13:26:12] <kshishkov> no monetary output [13:26:15] <av500> mru: so, soon it will say on US ATMs: "there will not be more money if you stick your hand in deeper"" [13:26:29] <av500> kshishkov: highly efficinet [13:26:31] <av500> ent [13:27:06] <mru> like on the vending machines: rocking machine will not result in free product [13:27:17] <av500> no, only on you crushed by machine [13:28:03] <kshishkov> but not you [13:28:22] <av500> what machine?... [13:30:54] <Honoome> mru: I can put money in my bank's ATM :P [13:31:11] <mru> sure, but can you get it back out? [13:31:13] <Honoome> [the fact that the money laundry regulations don't allow me to do that anymore is a different problem] [13:31:32] <Honoome> mru: yah it's listed in realtime on my account's balance ;) [13:31:36] <mru> I've solved that problem [13:31:42] <kshishkov> av500: I'm pretty sure you can withstand a falling vending machine [13:31:51] <mru> I put money in the pockets when I take my clothes to the laundry [13:32:17] <mru> <insert OADS joke here> [13:32:19] <kshishkov> to stelthly launder your money? [13:44:16] <av500> sometimes I hate my job... pDst = ( OMX_U8 * ) ( &( ( ( H264SplitLcmlQInputParam * ) pUAlgInBufParam )->sIttAlgContext ) ); [13:46:47] <mru> eeew [13:47:35] <av500> yeah, I ran outside and asked a coworker to incenerate the hard drice [13:47:40] <av500> drive [13:47:56] <av500> my vision is almost back [14:07:37] <wbs> BBB: SPACE_CHARS are defined in rtpdec.h now (josh suggested to move them back there since nobody else were using them from internal.h) - do you prefer the version I posted then, or should I move SPACE_CHARS back to internal.h? [14:08:07] <BBB> hm... [14:08:10] <av500> #define SPACE " "? [14:08:15] <BBB> I suppose you could move it to internal.h [14:08:23] <BBB> av500: \n\r\t [14:08:25] <mru> av500: no, (" ") [14:08:30] <mru> or better ( " " ) [14:08:31] <av500> ' ' [14:08:38] <wbs> BBB: ok, will do [14:09:26] <av500> (,,;,,;,,) [14:09:57] <mru> for? [14:10:10] <av500> wasnt that chtulu? [14:13:42] <CIA-99> ffmpeg: mstorsjo * r24265 /trunk/libavformat/ (rtpdec.h rtpdec_mpeg4.c internal.h): [14:13:43] <CIA-99> ffmpeg: Move SPACE_CHARS back to libavformat/internal.h [14:13:43] <CIA-99> ffmpeg: It will be used by other parts of lavf now. This reverts svn rev 23846. [14:14:15] <mru> should it not include vertical tab and form feed too? [14:14:34] <mru> and what about bell? is that considered whitespace? [14:14:49] <BBB> blah [14:15:02] <BBB> if we don't move it to internal.h everyone will complai about duplication [14:15:46] <BBB> I think a static inline void skip_spaces(char **ptr) { *ptr += strspn(*ptr, SPACE_CHARS); } would be nice [14:15:54] <BBB> but that's just me [14:16:03] <av500> ^G [14:16:22] <wbs> BBB: yes, that would be very useful for all the protocol code [14:16:29] <CIA-99> ffmpeg: mstorsjo * r24266 /trunk/libavformat/http.c: http: Log a warning when receiving an error code [14:16:48] <BBB> I should've brought that up with the original patches, but it's ok for now I guess [14:16:55] <BBB> maybe later [14:17:20] * BBB is a little confused with doing all kind of random stuff [14:33:38] <av500> geee: http://www.matroska.org/technical/specs/tagging/index.html#targettypes [14:34:04] <BBB> Vitor1001: I'm quickly reading that thread, what does truncf do? [14:34:29] <Vitor1001> truncation to integer. [14:34:32] <Vitor1001> I think. [14:34:33] <mru> BBB: http://www.opengroup.org/onlinepubs/009695399/functions/truncf.html [14:34:57] <BBB> so it's like round? [14:35:00] <mru> no [14:35:05] <mru> it rounds towards zero [14:35:10] <BBB> I said like [14:35:14] <BBB> so that's useless [14:35:26] <mru> round goes to nearest [14:36:21] <mru> av500: I think the polite word is "over-engineered" [14:36:59] <av500> yes [14:37:36] <Vitor1001> BBB: rounding (to any side) will never work to hide floating-point differences. [14:37:56] <mru> of course not [14:37:56] <Vitor1001> The only way I see is to convert a couple of vectors to fixed-point. [14:37:59] <BBB> the amrnb thread said this removed the problem ;) [14:38:16] <BBB> I was very confused by that [14:38:17] <BBB> I still am [14:38:27] <elenril> mru: no, the polite word would be "still better than ogg" [14:38:32] <Vitor1001> BBB: Well, removed, not much. It still differs considerably from the reference. [14:38:38] <av500> mru: https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [14:38:48] <av500> lhomme will be back! [14:39:23] <Vitor1001> BBB: Compare your 2.5 stddev with the enormous value he was getting. In that sense, it "removed" the problem... [14:40:13] <mru> hi DonDiego [14:42:00] <BBB> Vitor1001: right [14:42:05] <BBB> Vitor1001: I guess 2.5 isn't bad at all [14:42:17] <BBB> I mean, it's bad of course, but since it's gradual buildup of random noise variation, it's ok [14:42:23] <jai> well lavf does support tags, just that the demuxer prefixes targettypes to the metadata value [14:42:50] <elenril> lavf doesn't support muxing [14:43:22] <jai> ah, yes [14:43:35] <elenril> (yet) [14:43:41] * elenril should finish the patch for that [14:43:59] <jai> "I can not get meta-data for webm video file." <= i thought he meant demuxing [14:44:22] <jai> elenril: with target types ? [14:45:44] <elenril> no [14:48:00] <elenril> i fail to see the point of those, they mess up conversion etc [14:48:30] <av500> well, we just add title_10, title_20, title_30..... [14:54:20] <Vitor1001> BBB: 2.5 isn't bad, it is just unpractical for regression testing... [14:54:42] <BBB> also maxdiff>90 [14:54:48] <BBB> suggests something weird is going on [14:54:54] <BBB> can you both send me the pcm output? [14:54:59] <BBB> so I can see what's so different? [14:55:01] <Vitor1001> Sure [14:55:11] <Vitor1001> You don't have an account? [14:55:18] <BBB> where? [14:55:21] <BBB> (probably not) [14:55:33] <Vitor1001> In mru's PPC box [14:55:36] <BBB> no [14:56:04] <Vitor1001> You can just ask him [14:56:08] <jai> elenril: you could just allow remuxing of targettype 50 and drop the rest [14:57:32] <jai> tbh though i dont see the point either [14:58:10] <Vitor1001> BBB: sent [14:58:35] <elenril> jai: ? [14:58:46] <elenril> you mean not export any other metadata? [14:59:14] <jai> elenril: yeah, when the output is anything other than mkv [14:59:46] <jai> is there any other issue you see with conversion? [15:00:15] <elenril> what? the demuxer doesn't know anything about output [15:02:26] <jai> umm, yeah. i was referring to targettype handling in the muxer [15:02:32] <BBB> Vitor1001: ty [15:03:33] <elenril> nah, i'd rather not write it at all [15:03:38] <jai> av500: seeking in mod files would be tough [15:03:42] <elenril> it's not mandatory and nobody uses it anyway [15:03:53] <jai> true [15:04:59] <jai> and pointless to because of the latency [15:05:01] <jai> *too [15:09:55] <jai> of course we could always implement bass/modplug style inaccurate seeking [15:11:11] <av500> jai: why cant you seek? a sequencer usually has quite a good idea about time, no? [15:11:29] <Vitor1001> jai: Do you have any idea why SIPR in vlc sounds worse than in ffplay? [15:11:58] <mru> because everything is better with ff [15:12:07] <jai> av500: the instruments used tend to change based on the pattern, so skipping a bunch without having interpreted the earlier ones screws up the state [15:12:13] <KotH> mru: ffsalt? [15:12:21] <mru> ffchocolate [15:12:29] <KotH> hmm... [15:12:31] <KotH> good idea [15:12:39] <jai> av500: well, you could seek, its just very unreliable and tends to suck [15:12:46] <KotH> i'll ask whether sprüngli will sponsor some ffchocolate for next LT [15:13:04] <jai> Vitor1001: didnt know that, could you point me to a sample? [15:13:17] <Vitor1001> just a min [15:16:10] <Vitor1001> jai: Weird, I cannot reproduce it anymore. [15:16:14] <Vitor1001> jai: But test http://samples.mplayerhq.hu//real/AC-sipr/intro.rm [15:17:14] * Vitor1001 can only run VLC on wine... [15:18:14] <mru> not beer? [15:18:29] <jai> Vitor1001: sounds same as ffplay's audio output here [15:18:43] <jai> Vitor1001: are you using pulseaudio or something by any chance [15:18:58] <Vitor1001> jai: Ok, fine, should be my setup... [15:19:16] <Vitor1001> Never got to compile VLC using my non-installed ffmpeg tree... [15:20:33] <twice11> would it be possible to create one AVPacket per tick (IIRC typically 6 ticks/row)? [15:21:39] <Vitor1001> twice11: Don't some sample formats has commands to go to the n-th row or something? [15:24:44] <av500> mru: you need to runtime detect neon [15:24:44] <twice11> Mod even has some loop command. [15:24:55] <mru> av500: how? [15:25:07] <twice11> That would be decoded in the mod->BSS part, as I see it. [15:25:12] <av500> no idea, but otherwise ubuntu will drop ffmpeg neon [15:25:20] <jai> Vitor1001: yeah [15:25:20] <mru> their problem, not mine [15:25:26] <mru> but do you have a reference? [15:25:41] <av500> ask koen [15:26:09] <mru> is this loic's doing? [15:26:23] <av500> loic? [15:26:26] <av500> our CFO? [15:26:28] <Vitor1001> twice11: That kind of things that make it kind of pointless to break a file in several packets. [15:26:30] <mru> ubuntu arm guy [15:26:47] <mru> loic minier [15:26:53] <av500> dunoo [15:27:36] <twice11> Vitor1001: You decode the file into ticks (and expand the loops). The per-tick-info is then stateless and perfectly seekable, even with absolute time. [15:28:28] <jai> whoa, isnt that waaay too much overhead? [15:28:44] <Vitor1001> twice11: To expand the loop one has to practically decode, no? Besides, it would make a lot of information loss in transcoding... [15:29:03] <jai> once the new seeking api is in place, you could just do what dumb does [15:29:58] <DonDiego> what do you guys think of the -Wcast-qual warning? [15:30:34] <mru> DonDiego: it would be good, if it weren't for a few situations where no amount of const will avoid the warnings [15:30:40] <mru> double pointers come to mind [15:31:00] <mru> and implementations of strstr() and friends [15:31:44] <DonDiego> i [15:31:56] <DonDiego> 'm tasked with removing some warnings from HIPL [15:32:03] <DonDiego> and they are all caused by that option [15:32:11] <mru> so you're going to drop the flag? [15:32:17] <mru> sounds wrong without a thorough investigation [15:32:26] <mru> usually the fix is to add const where it belongs [15:32:31] <DonDiego> i remembered that there was some discussion about dropping the flag on -devel [15:32:31] <av500> http://hipl.org/ [15:32:44] <jai> mru: not a fan of tracked music eh :) [15:32:49] <DonDiego> http://infrahip.net/ [15:33:30] <DonDiego> can i trust the fix to be ok if adding a const kills the warning? [15:34:17] <mru> make sure it doesn't pop up elsewhere instead [15:34:26] <mru> const warnings can be very hard to kill [15:39:09] <twice11> If adding a const does not provoke new warnings or errors, the fix is OK (except in C++ maybe where different overloads might be chosen depending on constness). [15:39:43] <mru> overlords... [15:39:56] <twice11> Adding casts to silence warnings might be dangerous and hide problems. [15:39:59] <mru> <swedish>konstigt</swedish> [15:40:17] <mru> twice11: I _never_ suggested adding casts [15:40:41] <twice11> OTOH, there are too many libraries with missing consts in their interfaces where adding casts is needed :( [15:40:51] <mru> if I start doing that, I count on you lot to take me to the doctor [15:40:54] <twice11> mru: I did not mean to suggest you did. [15:41:14] <av500> mru: not just shoot you? [15:42:03] <mru> that may be the only cure... [15:42:07] <KotH> mru: we should take you to the doctor anyways ;) [15:42:15] <kshishkov> mru, have no worry. Almost everything is curable withh shovel [15:42:23] <mru> KotH: there aren't any left who will see me [15:42:47] <KotH> mru: you mean i should study medicin? [15:43:13] <DonDiego> what was the result of the discussion on -devel? [15:43:22] <DonDiego> will the warning stay or be removed? [15:43:33] <mru> DonDiego: probably that there are many colours of bikesheds [15:44:10] <kshishkov> mru: only Faluroda for true bikesheds [15:44:13] <KotH> mru: superposition of bikeshed colours? [15:44:34] <kshishkov> KotH: you know what you get when you mix all colours [15:44:47] <av500> ugly [15:45:02] <KotH> kshishkov: yes: an ugly brownish colour [15:45:13] <kshishkov> KotH: or greenish [15:45:45] <kshishkov> that's why I stick to traditional colour of sheds in the country of heavy bike users [15:46:28] * KotH doesnt know what colour the sheds in china are [15:46:44] <kshishkov> who cares about China? [15:46:56] <KotH> they are heavy bike users [15:47:08] <mru> they use heavy bikes? [15:47:15] <kshishkov> I mean Nordic countries [15:47:17] <av500> they have no bikesheds [15:48:52] <kshishkov> cyckelbod [15:50:10] <mru> cykel [15:50:20] <mru> or sykkel in .no [15:50:36] <kshishkov> I thought that word means simply "bicycle" [15:50:38] <kierank> [16:46] <@kshishkov> who cares about China? --> red of course [15:51:43] <kshishkov> kierank: one of popular mottos in West Ukraine is "communist should be hanged on tree branch" [16:51:46] <CIA-99> ffmpeg: vitor * r24267 /trunk/libavcodec/imc.c: Make Intel Music Coder output SAMPLE_FMT_FLT [16:52:14] <mru> Vitor1001: does this break the fate test? [16:52:49] <Vitor1001> mru: Of course not. It _fixes_ the fate test when using float_to_int16_c. [16:53:18] <mru> I mean on the machines where it was already working [16:53:29] <mru> maybe working is the wrong word [16:53:32] <mru> does the output change? [16:53:47] <Vitor1001> I know. No, that was how I tested to see if I didn't screwed up my patch ;) [16:54:56] <Vitor1001> mru: BTW, I've written Mike about enabling fate2 in the fate machines and was simply ignored :p [16:55:03] <mru> I know [16:55:34] <Vitor1001> do you? I mean again, in pvt. [16:56:06] <mru> your mail to the list a week ago got no response [16:56:12] <Vitor1001> yes [16:56:13] <mru> didn't know you'd mailed him again [16:56:42] <Vitor1001> Maybe we should just convince fate machine admins to run "make -k test fate2" instead of just "make -k test"... [16:57:02] <mru> or make test include fate2... [16:57:05] <mru> no convincing required [16:57:23] <Vitor1001> It will fail for most people who don't pass the samples path to configure... [16:57:54] <Vitor1001> And "make test" should include both fate1 and fate2... [16:58:05] <Vitor1001> (if it were to include anything) [16:58:13] <mru> yeah [16:59:05] <Vitor1001> Does "make fate2" pass in all your jungle of exotic hardware? [16:59:29] <mru> haven't tested them all [17:00:19] <Vitor1001> I ran each test in my notebook and your ppc box, but only that... [17:01:35] <Vitor1001> But I'm happy it has already spotted a bug [17:01:38] <mru> testing on the beagle now [17:01:43] <Vitor1001> Nice! [17:02:24] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/FEG1Z3qZ good idea or bad idea? it makes the integration of the size==8 one (a little code is available for that on top, so you can see what I have in mind) easier [17:02:51] <BBB> and saves a regular reg on x86-64 8-) [17:03:46] <mru> vorbis-18 fails with maxdiff=2 [17:03:57] <Vitor1001> :p [17:04:18] <mru> the neon float to int rounds negative values slightly differently [17:04:22] <mru> that's probably the reason [17:04:39] <Vitor1001> mru: I see... Maybe we could just add fuzz=2 to this test... [17:04:47] <Vitor1001> And the rest pass? [17:04:52] <mru> rest pass [17:04:54] <Vitor1001> cool [17:04:58] <mru> ask the vorbis maintainer [17:05:10] <mru> who's that anyway? yuvi? [17:06:39] <mru> peloverde might have an opinion [17:06:49] <peloverde> about? [17:06:51] <Vitor1001> Ok. I'll post an open question to the list. [17:06:53] <mru> peloverde: fate-vorbis-18 has maxdiff 2 on arm [17:07:10] <peloverde> 2 seems reasonable [17:07:53] <mru> so you think setting fuzz=2 is ok? [17:08:36] <Vitor1001> mru: MAINTAINERS list mike for vorbis... [17:08:54] <Vitor1001> ... who is not really active these days. [17:09:03] <peloverde> I think Yuvi is the defacto maintainer [17:09:15] <mru> mike? not here [17:09:26] <peloverde> anyway pretty much all of AAC seems to require fuzz=2 [17:09:37] <mru> my file says denes balatoni and yuvi [17:09:49] <peloverde> and they are fairly similar formats [17:09:51] <Vitor1001> mru: nevermind, saw it wrong [17:09:57] <mru> yeah, next line has mike [17:10:29] <peloverde> Are any of these tests going to make it into real fate anytime soon? [17:10:43] <mru> don't hold your breath [17:10:47] <DonDiego> experience with mike says no [17:11:00] <mru> so let's build a new fate [17:11:12] <DonDiego> as i've been saying, we need to build the community fate to replace mike's proprietary one [17:11:24] <DonDiego> the 'make fate' target is a good start [17:11:33] <DonDiego> everybody can basically run fate locally now [17:11:51] * kshishkov prefers providing reasons for new cases to fate instead [17:11:55] <Vitor1001> peloverde: we can put in a few boxes by asking their admin to replace "make test" by "make test fate2" [17:12:16] <mru> there's a problem with that [17:12:32] <mru> mike's script only logs the last few lines of output [17:12:45] <mru> so it might not be possible to see what failed [17:12:59] <mru> and lumping them all together isn't nice either [17:13:09] <mru> therefore, let's make something new and better [17:13:13] <Vitor1001> Of course. [17:13:43] <kierank> mru: i thought you don't do web ;) [17:13:55] <mru> I don't [17:14:01] <mru> I'm leaving that part to you [17:14:34] <Vitor1001> Be sure to use google, MSN and yahoo scripts for providing flamewar amusement in -devel. [17:14:39] <kshishkov> it's totally different app anyway [17:15:06] <lu_zero> yawn? [17:15:09] <Honoome> hi lu [17:15:10] <kshishkov> and <script language="Lisp"> tags [17:15:13] <lu_zero> hi [17:15:19] <lu_zero> please... [17:15:44] <lu_zero> not use something that crazy... [17:15:53] <Honoome> kshishkov: don't give crazy ideas to luca [17:15:55] <mru> arm asm? [17:15:59] <Honoome> he's known to getting them throguh [17:16:07] <lu_zero> mru: that's good [17:16:17] <mru> not for web scripts [17:16:17] <kshishkov> Honoome: good luck dealing with HTML5 comittee [17:16:22] <lu_zero> btw why arm asm uses % instead of @ [17:16:33] <mru> instead of? [17:16:37] <mru> in what context? [17:16:39] <lu_zero> my current idea for html5 is adding rtsp for video [17:16:39] <kshishkov> for comments [17:16:44] <lu_zero> mru: progbits [17:16:44] <peloverde> fate-imc is failing on my system [17:16:53] <lu_zero> I had icu fail on arm because of that [17:16:53] <mru> lu_zero: because @ is comment [17:17:04] <peloverde> nevermind, i see it is being discussed [17:17:08] <Vitor1001> peloverde: Did you update it? [17:17:38] <Vitor1001> peloverde: It should work fine after r24267 [17:18:06] <mchinen> are there any gotchas for the file end conditions when writing parsers? [17:18:33] <kshishkov> no [17:19:14] <mchinen> trying to do a flac one but i get some memory bashing bugs in ff_combine_frame that I'm trying to sort out with valgrind [17:20:49] <mru> kshishkov: you said anything can be cured with a shovel... [17:21:14] <kshishkov> mru: rather anybody's illness [17:22:21] <kshishkov> and Soviet army shovel sounds cooler than Swiss army knife [17:22:27] <peloverde> Vitor1001: you are correct [17:22:33] <mchinen> hope it doesn't drive me to that point. [17:23:04] <lu_zero> kshishkov: you had a shovel with multiple tools embedded inside? [17:23:15] * lu_zero still wonders at the american spork [17:23:41] <mru> http://xkcd.com/419/ [17:23:49] <kshishkov> lu_zero: no, but there are too many uses for ordinary shovel anyway [17:25:33] <lu_zero> yes [17:25:49] <lu_zero> like hacking woods [17:27:02] <lu_zero> interesting fact [17:27:16] <kshishkov> well, current Ukrainian infantry equipment includes _two_ shovels [17:27:52] <lu_zero> youtube h264 high res takes more to decode than vp8 [17:29:09] <Honoome> with ffvp8? [17:29:25] <lu_zero> yes [17:29:29] <lu_zero> on the imx [17:29:50] <lu_zero> so there is something strange [17:30:02] <Honoome> like the whole system? [17:30:12] <Honoome> -mfpu=no? :P [17:30:24] <lu_zero> -mfpu=neon you mean? [17:30:36] <Honoome> ah you did rebuild all of it then? [17:30:39] <kshishkov> FPU is useful with H.264 indeed [17:30:56] <mru> fpu is a bit of a misnomer here [17:33:12] <lu_zero> Honoome: not exactly [17:33:30] <lu_zero> apparently the image and the "sdk" were desynced... [17:33:35] <Honoome> lu_zero: you know that if you didn't rebuild, say, glibc, you're going to use integer-only libm? :P [17:33:56] <lu_zero> Honoome: I do know =P [17:34:04] <Honoome> did you rebuild glibc? [17:34:36] <lu_zero> cat /var/db/pkg/sys-libs/glibc-2.11.2/CFLAGS [17:34:36] <lu_zero> -march=armv7-a -mtune=cortex-a8 -mfpu=neon -pipe -O2 -fno-strict-aliasing [17:34:41] <lu_zero> no I checked the flags [17:36:12] <BBB> Vitor1001: how feasible is it to check the stdev < X instead of maxdif < X for amr && wmavoice? [17:36:27] <BBB> (I haven't checked the files yet, but it's an alternative solution that will catch obvious bugs) [17:38:38] <mru> lu_zero: you forgot -mfloat-abi=softfp [17:38:45] <mru> or =hard as your case may be [17:41:52] <lu_zero> mru: I didn't, the guy that made the image did [17:42:04] <lu_zero> mru: what's the difference between them btw? [17:42:07] <mru> in that case you forgot to make your own [17:42:19] <mru> softfp uses softfloat calling convention [17:42:20] <lu_zero> mru: I'm supposed just to evaluate it [17:42:26] <mru> hard passes float parameters in vfp registers [17:42:30] <mru> which is much more efficient [17:43:25] <lu_zero> noticed [17:43:26] <lu_zero> uhmm [17:46:59] <DonDiego> ah, the ugliness.. [17:47:12] <DonDiego> two casts in a row like: (foo *) (void *) [17:47:14] <mru> ? [17:47:16] <mru> oh [17:47:20] <DonDiego> the joys of working on hipl.. [17:47:36] <mru> why do you do it? [17:47:43] <DonDiego> s/you/they/ [17:47:57] <DonDiego> probably didn't know better, noticed that it worked.. [17:48:01] <mru> you work on it [17:48:02] <mru> why? [17:48:22] <DonDiego> i get paid to do it, the people are nice, i may get to do a thesis.. [17:48:42] <DonDiego> i assume it's safe to remove the void* cast? [17:48:57] <mru> I get paid (probably much more) to write fun assembler code... [17:49:23] <DonDiego> :) [17:49:31] <DonDiego> s/probably// [17:49:35] <lu_zero> DonDiego: check [17:49:45] <lu_zero> if gcc screams about aliasing you know why it was there [17:52:56] <DonDiego> are aliasing warnings part of -Wall and -Wextra? [17:53:08] <mru> should be -Wall [17:53:14] <mru> they are in whatever ffmpeg uses [17:53:40] <mru> they are more elaborate (and more numerous) with more recent gcc versions [17:53:53] <peloverde> DonDiego: Is the mplayer build system broken? [17:55:25] <Honoome> -Wstrict-aliasing should be in -Wall [17:55:32] <Honoome> -Wstrict-aliasing=2 _may_ be in -Wextra [17:58:48] <DonDiego> peloverde: not that i know of [17:58:59] <DonDiego> i have fixed all the bugs i was told about [18:00:43] <peloverde> DonDiego: Whenever I try to configure I get "Error: MPlayer will not compile without libavutil in the source tree." at the bottom and "sed: can't read libavcodec/allcodecs.c: No such file or directory" at the top [18:01:02] <peloverde> SVN checkout from ~5 minutes ago [18:04:02] <DonDiego> what options do you pass to configure? [18:04:08] <DonDiego> and what system are you on? [18:04:18] <peloverde> http://pastebin.ca/1901914 [18:04:20] <peloverde> amd64 [18:04:33] <DonDiego> also, this is offtopic here - i'll gladly help you, but move it to #mplayerdev or privmsg, whatever you prefer [18:04:54] <peloverde> I tried on #mplayer and no one was useful [18:05:16] <DonDiego> oh, i see - you are trying to build out-of-tree, this is not supported [18:05:30] <peloverde> So it is broken [18:05:36] <DonDiego> it's on the wishlist, but not particularly high up on my todo list [18:06:08] <DonDiego> if you consider that a requirement for nonbrokenness, then yes, by your definition of broken, it is broken [18:07:18] <mru> how can anyone _not_ do out of tree builds? [18:07:53] * DonDiego never felt so constrained without it.. [18:08:02] <DonDiego> it's a matter of habit i guess [18:08:28] <peloverde> It never even occurred to me to try an intree build [18:08:42] <peloverde> That how outmoded the concept is [18:08:55] <mru> building the same source in a dozen different configurations is often handy [18:09:08] <mru> and make distclean turns into rm -r * [18:09:13] <peloverde> agreed [18:09:15] <mru> much more reliable [18:09:38] <peloverde> I don't even cross compile and I keep 5 or 6 ffmpeg build directories [18:09:52] <Honoome> ++ on out-of-tree [18:09:58] <DonDiego> for a long time it never occurred to me to build out-of-tree [18:10:06] <peloverde> clag, gcc, no asm, x86_32 (I guess that is technically cross) [18:10:13] <DonDiego> and judging from the people i know it's an alien concept to most devs [18:10:17] <mru> DonDiego is the old in-tree, svn etc mindset [18:10:23] <DonDiego> lol :) [18:10:44] <peloverde> I guess I am also kind of hating on MPlayer because of the WebM thing [18:11:19] <mru> mplayer devs always expect special treatment [18:12:03] <DonDiego> geez, calm down already [18:12:19] <DonDiego> mplayer has always been the first ffmpeg user [18:12:38] <mru> that doesn't give it the right to abuse non-api functions [18:12:57] <DonDiego> and it's a very recent development that no longer 80% of ffmpeg devs are not also mplayer devs [18:13:18] <DonDiego> it shows how ffmpeg can be abused and that should be considered [18:13:25] <DonDiego> if mplayer does it, others will follow [18:13:34] <peloverde> You say it's very recent but it has been the case for the 2 years I have been around [18:13:45] <peloverde> aka 20% of FFmpeg's history [18:14:56] <mru> it's a long time since any other mplayer devs than DonDiego and reimar were active in ffmpeg [18:15:26] <mru> and I've been around longer than DonDiego [18:15:34] <DonDiego> you are among the 20% [18:15:45] <DonDiego> peloverde: you are a newcomer.. [18:15:55] <kshishkov> so am I [18:16:02] <peloverde> 20% ago is not recent history [18:16:28] <DonDiego> oh, come on.. [18:16:40] <microchip_> mru: Carl is active, no? [18:17:33] <mru> he doesn't do any coding [18:20:01] <kshishkov> mru: exclude Diego then [18:22:39] <peloverde> Also the past 2 years makes up 40% of ffmpeg commits [18:30:11] <CIA-99> ffmpeg: rbultje * r24268 /trunk/libavcodec/x86/vp8dsp.asm: [18:30:11] <CIA-99> ffmpeg: Change return statement, the REP_RET is a mistake since the else case (x86-64, [18:30:12] <CIA-99> ffmpeg: sse2) doesn't actually loop, so REP_RET isn't necessary. [18:33:25] <mru> mplayer is like ntsc and interlacing [18:33:35] <mru> an ugly hack once necessary [18:33:48] <mru> now lingering around due only to inertia [18:36:47] <Compn> so what replaced mplayer mru ? [18:36:59] <mru> a lot of people seem to use vlc [18:37:08] <Compn> what do you use ? [18:37:09] <kshishkov> Compn: and what replaced NTSC? [18:37:14] <mru> kshishkov: hdtv [18:37:23] <Compn> interlaced ntsc hdtv kshishkov [18:37:29] <kshishkov> is it ubiquous? [18:37:43] <Compn> under the atsc standard :P [18:37:44] <DonDiego> vlc on the command line sucks [18:37:48] <mru> I guess nothing is sufficiently better to kill it off completely [18:37:50] <Compn> vlc ... sucks :P [18:37:57] <mru> both mplayer and ntsc [18:38:15] <mru> Compn: I don't use vlc [18:38:16] <kshishkov> add VLC to that list just in case [18:38:47] * kshishkov somehow is better with German project than with French [18:39:14] * Compn kidding of course, vlc has more features than mplayer [18:40:22] <Compn> huh [18:40:25] <Compn> gives me an idea [18:40:28] <peloverde> In a lot of ways VLC seems to be moving in the right direction [18:40:40] <Compn> how much code to make mplayer output a stream using ffmpeg's network code [18:41:28] <Compn> vlc also has more output messages than mplayer [18:41:41] <peloverde> the LGPL libvlc relicense, etc, compare how much traffic VLC got at FOSDEM compared to the combined FFmpeg/MPlayer stand [18:42:18] <Compn> how much more did they get ? [18:42:30] <kshishkov> peloverde: you'd see how much traffic got LinuxTag MPlayer stand [18:42:38] <mru> lol [18:42:41] <mru> mplayer [18:42:55] <kshishkov> mru: unlike OGP it was manned too [18:43:02] <mru> true [18:43:18] <mru> but they had only a single, small poster [18:43:26] <mru> ffmpeg had The Beast [18:43:36] <peloverde> Compn: It seemed like at least a factor of 4 or 5, and a good chunk of our traffic was OGP [18:43:49] <peloverde> Also, we have been added: http://www.webmproject.org/about/supporters/ [18:44:37] <Compn> ugh [18:44:40] <Compn> right next to flash logo [18:44:50] <kierank> and near java [18:44:51] <Compn> ah its alphabetical [18:46:11] <BBB> peloverde: you forget that vlc is an end user tool [18:46:16] <BBB> peloverde: ffmpeg is a developer's tool [18:46:23] <BBB> they attract different audiences [18:46:24] <peloverde> BBB: Mplayer is an enduser tool [18:46:31] <BBB> no [18:46:35] <BBB> mplayer is a hack, as mru just said [18:46:46] <peloverde> A hack that claims to be an end user tool [18:46:55] <BBB> vlc _is_ an end user tool :-p [18:47:13] <BBB> it's like freetards _claim_ to be relevant, whereas google _is_ relevant [18:47:22] <BBB> that's why theora sucked ass and vp8 might actually have a slight chance [18:47:26] <peloverde> VLC is what MPlayer should be [18:47:31] <BBB> probably, yes [18:47:57] <peloverde> Also, I still think we could do some work to raise our profile hence my mini PR blitz (WebM, firefogg, etc) [18:48:21] <BBB> yes, indeed [18:48:24] <BBB> I totally agree [18:49:04] <jai> why does vls "suck" on the command line? [18:49:07] <jai> *vlc [18:49:38] <mru> because it's got a vacuum [18:49:43] <mru> as opposed to being full of hot air [18:49:56] <jai> ic [18:49:58] <jai> :) [18:50:09] <kierank> seeking is still broken [18:50:24] <kierank> with h.264 and ts/mkv I think [18:50:31] <Compn> jai : have you tried it on the command line ? [18:50:49] <jai> Compn: i use it exlusively with the cli [18:51:27] <jai> then again, personal taste [18:51:52] <jai> kierank: are you aware of any ticket for that? [18:52:18] <Compn> jai : so you are saying that mru should report bugs instead of complaining about vlc's cli suckage ? [18:52:23] <Compn> :) [18:52:35] <mru> when did I complain about vlc? [18:52:38] <jai> 00:07:51 @DonDiego | vlc on the command line sucks [18:52:51] <jai> mru: not you :) [18:52:54] <Vitor1001> <BBB> Vitor1001: how feasible is it to check the stdev < X instead of maxdif < X for amr && wmavoice? [18:52:55] <Compn> oops [18:52:57] <Vitor1001> Pretty easy [18:52:58] <Compn> my bad [18:53:10] <jai> Compn: if its a simple UX issue, i'm sure we could fix it [18:53:28] <BBB> Vitor1001: maybe we should do that, at least for now, with a requirement that stdev<=3 or so [18:53:54] <jai> sucks being a broad term, i'm sure j-b and others would appreciate any feedback [18:54:28] <jai> hm, michael never ok'd the memleak stuff [18:55:02] <Vitor1001> BBB: ok, I will have a look at it [18:55:14] <BBB> cool [18:59:39] <DonDiego> bye [18:59:57] <j-b> vlc suck :D [19:00:18] <Compn> nooo, its good. dont listen to us chickens [19:00:39] <j-b> no, it sucks. But so far, most other stuff suck even more :D [19:01:00] <j-b> and the cool thing about sucking hard, is that there is fucking lots of place for improvement :) [19:01:02] <Compn> the truth of the universe [19:01:14] <Compn> it sucks, but everything else sucks more [19:01:23] <j-b> not everything :) [19:01:38] <j-b> I switched from mplayer to vlc just a few months ago [19:05:51] <Honoome> if we're doing the player-that-sucks-a-lot competition, xine wins by default [19:06:26] <j-b> Honoome: what about ogle? [19:06:35] <Honoome> was that ever generic? [19:06:39] <cartman> ogle rocks [19:06:41] <cartman> ;) [19:06:42] <j-b> no idea :D [19:06:53] <mru> ogle was a dvd player [19:07:03] <mru> it actually did menus correctly [19:07:09] <cartman> yup [19:07:17] <cartman> it was ahead of its time for DVDs :) [19:07:20] <j-b> mru: btw, vlc's avcodec module works really great on iPad [19:07:56] <j-b> mru: thanks a lot ;) [19:08:15] <cartman> now enable gpu decoding for MacOSX [19:08:17] <cartman> ;= [19:08:21] <cartman> s/=/p [19:08:35] <j-b> well, the patch is there, but well [19:08:53] <cartman> now Mac maintainer still ? [19:08:57] <cartman> s/now/no [19:09:10] <j-b> cartman: people will work on it, soonish [19:09:17] <cartman> neato :) [19:09:29] <cartman> first thing to install on a Mac is vlc [19:09:35] <cartman> and then compile ffmpeg ;) [19:09:37] <j-b> I can't tell more... I need to fight FSF about the iPad [19:09:46] <mru> ? [19:09:51] <cartman> fight Apple first [19:09:55] <cartman> for the AppStore :P [19:09:59] <j-b> and then, I'll see about the Mac thing [19:10:11] <j-b> cartman: we'll do soonish [19:10:12] <mru> what does the fsf have to do with anything? [19:10:21] <Honoome> mru: if vlc has any fsf-owned code on the ipad it'll have to abide to gpl-2 when distributed [19:10:27] <mru> but does it? [19:10:28] <Honoome> and the app store does not allow you to fully abide to gpl-2 [19:10:40] <j-b> vlc is gplv2+ [19:10:43] <mru> so? [19:10:50] <mru> does the fsf own copyright? [19:10:57] <j-b> fsf interpretation of the GPL is that this isn't ok [19:11:10] <j-b> mru: no, but some devs trust them [19:11:15] <Honoome> most other people settle for the "the way that's more practical" of allowing the sources to be available [19:11:17] <mru> shoot those devs [19:11:23] <mru> and replace their code [19:11:25] <kierank> there's a copy of vlc (pay) on the app store iirc [19:11:39] <Honoome> without having to actually deny themselves availability on the appstore [19:11:39] <j-b> well, libvlc is being relicensed anyway [19:11:58] <Honoome> mru: that's why we call them freetards, no? [19:12:19] * Honoome still think that some software is better than no software [19:13:33] <Dark_Shikari> btw [19:13:44] <Dark_Shikari> Bugmaster is finding a lot of swscale bugs relating to register sizes and such [19:13:51] <Dark_Shikari> now that x264 uses swscale on win64 [19:14:02] <Dark_Shikari> lots of users are reporting crashes [19:14:10] <Dark_Shikari> so.... lots of bugfixes may be coming in that way. [19:15:54] <Vitor1001> BBB: http://ffmpeg.pastebin.com/wvLSxNty [19:16:29] <mru> Vitor1001: let me clean that up [19:20:00] <Vitor1001> mru: I was expecting it ;) [19:24:33] <spaam> Dark_Shikari: bugmaster? [19:25:58] <Dark_Shikari> russian x264 dev [19:28:49] <BBB> Vitor1001: awesome [19:29:09] <peloverde> mru: tcvp.sourceforge.net and trac.inprovinde.com/tcvp are down, is it ok to change the link to http://git.mansr.com/?p=tcvp [19:29:16] <mru> sure [19:29:27] <mru> and thanks [19:29:37] <BBB> Dark_Shikari: ping re my patch [19:29:44] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/FEG1Z3qZ [19:30:00] <BBB> Dark_Shikari: is that ok? makes implementing chroma inner loopfilter ultra-simple [19:30:50] <Dark_Shikari> sure [19:34:44] <BBB> it also saves one reg on x86-64 8-) [19:34:47] <BBB> (had to say that) [19:39:00] <CIA-99> ffmpeg: rbultje * r24269 /trunk/libavcodec/x86/vp8dsp.asm: [19:39:00] <CIA-99> ffmpeg: Give x86 r%d registers names, this will simplify implementation of the chroma [19:39:00] <CIA-99> ffmpeg: inner loopfilter, and it also allows us to save one register on x86-64/sse2. [19:43:22] <CIA-99> ffmpeg: rbultje * r24270 /trunk/libavcodec/x86/vp8dsp.asm: Remove duplicate define. [19:44:50] <BBB> Dark_Shikari: can I do %if bla == x && blo == y in a macro? [19:45:41] <Dark_Shikari> yes [19:46:57] <BBB> shit I hate my text editor [19:55:13] <CIA-99> ffmpeg: rbultje * r24271 /trunk/libavcodec/x86/vp8dsp.asm: Revert 24270, it contained some stuff that shouldn't have been in there. [19:55:13] <CIA-99> ffmpeg: rbultje * r24272 /trunk/libavcodec/x86/vp8dsp.asm: Remove duplicate define. [19:56:59] <Honoome> mru: I guess the only solution to the deprecated warnings is getting rid of the code iirc the problem was in the declaration themselves, that gcc counts as usage, and are _always_ emitted once including the header [19:58:58] <mru> there's not many of those [19:59:16] <mru> there are some for AVPaletteControl stuff [20:03:35] <CIA-99> ffmpeg: alexc * r24273 /trunk/libavcodec/aaccoder.c: aacenc: Template quantize_and_encode_band_cost(). [20:15:58] <BBB> Dark_Shikari: this was too easy ;) it already works [20:16:14] <BBB> wanna see the patch (mmx/mmx2 only for now, sse2 requires actual code :-p) [20:16:40] <Dark_Shikari> sure [20:17:30] <peloverde> stupid C question, I feel like I'm missing a const here but I don't know where it goes: http://pastebin.ca/1901993 [20:17:32] <BBB> http://ffmpeg.pastebin.com/D8ihT70h [20:18:06] <peloverde> Specfically the pointers in quantize_and_encode_band_cost_arr should never be over written [20:18:11] <BBB> peloverde: static const float ...? [20:18:27] <peloverde> nope, that changes the return type of the functions [20:19:02] <pengvado> static float (*const quantize_and_encode_band_cost_arr[])( [20:19:48] <peloverde> thanks [20:22:45] <Dark_Shikari> BBB: you should give it a better name [20:22:47] <Dark_Shikari> it's no longer filter8 imo [20:22:49] <Dark_Shikari> maybe filteruv? [20:22:53] <Dark_Shikari> and filter16 should be filtery [20:23:01] <Dark_Shikari> anyways, awesome [20:27:47] <BBB> filter16y/filter8uv? [20:28:29] <BBB> it acts on cols/rows of 16/8wide/high [20:28:45] <BBB> uv just happens to take 2 :) [20:29:47] <CIA-99> ffmpeg: alexc * r24274 /trunk/libavcodec/aaccoder.c: 10l: Add a missing const. [20:30:27] <Dark_Shikari> BBB: dunno, whatever you want I guess [20:30:35] <Dark_Shikari> mru: ok, I have some rage for you. [20:30:39] <Dark_Shikari> some massive, massive rage. [20:30:47] <mru> I don't need that [20:30:51] <mru> but go on [20:31:08] <Dark_Shikari> Matroska says that AR should be coded as pixel units (i.e. display resolution), not an AR. This is kinda stupid, but it's not so awful. [20:31:17] <Dark_Shikari> Haali did it wrong in his muxer in x264, as did some other software. [20:31:24] <mru> of course it's stupid [20:31:28] <Dark_Shikari> now that a Corecodec guy is making a validator [20:31:31] <Dark_Shikari> they're going around and fixing stuff. [20:31:34] <Dark_Shikari> So, now for the rage-inducing part. [20:31:35] <mru> what does it even mean? [20:31:55] <Dark_Shikari> He says there's an easy solution for the AR problem [20:32:03] <Dark_Shikari> Just add another unit type in the spec and tell the muxer to use that instead! [20:32:07] <Dark_Shikari> Bam, problem solved! [20:32:11] <Dark_Shikari> (a unit type == normal AR units) [20:32:11] <mru> aspect ratio should be specified either as pixel aspect ratio or display aspect ratio _in physical size_ [20:32:20] <Dark_Shikari> yes that's what I mean [20:32:22] <Dark_Shikari> e.g. [20:32:24] <mru> what happens if you have non-square pixels [20:32:24] <Dark_Shikari> "1920:1080" is the AR [20:32:25] <bcoudurier> hey guys [20:32:30] <Dark_Shikari> thats what I mean by pixel units [20:32:36] <mru> specifying DAR in pixels makes no sense [20:32:37] <Dark_Shikari> "1920:1080" means "display the video as 1920x1080" [20:32:40] <Dark_Shikari> anyways [20:32:44] <Dark_Shikari> the rage-inducing part [20:32:45] <bcoudurier> is int array[5] = {} non standard ? [20:32:50] <Dark_Shikari> "let's just change the spec!" [20:33:01] <Dark_Shikari> bcoudurier: why {}? [20:33:05] <bcoudurier> init to 0 [20:33:07] <mru> bcoudurier: I read the spec carefully, and it seems it's actually not [20:33:10] <Dark_Shikari> use {0} [20:33:28] <Dark_Shikari> mru: so in short, the corecodec solution to any mkv issue [20:33:30] <Dark_Shikari> is to change the spec [20:33:36] <bcoudurier> another mkv issue ? [20:33:39] <bcoudurier> :) [20:33:40] <mru> typically corporate [20:33:58] <Dark_Shikari> and their excuse is "oh it's just a draft" [20:34:04] <Dark_Shikari> so even in 2010, they're still changing the fucking spec [20:34:08] <Dark_Shikari> even though the format is already in wide use [20:34:12] <Dark_Shikari> it's like the microsoft word of video formats [20:34:42] <mru> I can write a rant about it if you like... [20:34:56] <Dark_Shikari> then there was the [20:34:59] <Dark_Shikari> Block -> SimpleBlock thing [20:35:03] <bcoudurier> what does C99 say ? That the initializer list cannot be empty ? [20:35:09] <mru> the old way was bloody annoying [20:35:11] <mru> bcoudurier: yes [20:35:17] <bcoudurier> ok [20:35:39] <mru> it's quite clear from the grammar spec in annex A [20:35:43] <bcoudurier> told mkv wasn't a good idea [20:35:46] <bcoudurier> told you [20:36:14] <mru> at least mkv tried to solve an actual problem [20:36:28] <mru> unfortunately they tried to solve too many problems [20:36:33] <mru> without fully understanding them first [20:36:52] <bcoudurier> the real problem was subtitles [20:36:56] <bcoudurier> they indeed fixed it [20:37:02] <mru> the real problem was AVI [20:37:06] <mru> and they fixed that too [20:37:15] <mru> but they had no fucking clue about container design [20:37:26] <mru> like how to make it codec-agnostic [20:37:35] <bcoudurier> well avi is still widely used [20:37:41] <Yuvi> Dark_Shikari: it'd work if they redefined the meaning without the new element as "aspect ratio" since that's what all players treat it as anyway [20:37:47] <bcoudurier> narutoverse do h264 in avi for example [20:37:50] <mru> all the codecs supported in the first versions use completely different header syntax [20:37:54] <mru> that must be parsed [20:38:19] * elenril thinks people releasing avi now should be shot [20:38:31] <bcoudurier> avi has the most widespread support [20:38:33] <mru> Yuvi: all players being broken is no excuse for making a broken format [20:38:43] <bcoudurier> and avi has technically the most used code path [20:38:57] <peloverde> Just register an official vorbis mapping for mp4 and be done with it :) [20:38:58] <bcoudurier> since it's there since way more time than mkv [20:38:58] <Yuvi> mru: no, but giving up and codifying what players do anyway doesn't seem so bad to me [20:39:54] <elenril> => we should use old crappy formats because our fathers and grandfathers used them? [20:40:19] <mru> these condoms were good enough for my father, they are good enough for me!!! [20:41:29] <peloverde> people also need to stop releasing in xvid, just because it's SD content doesn't mean you have to use a Part2 codec [20:41:55] <mru> people should stop being idiots [20:43:10] <BBB> Yuvi: http://ffmpeg.pastebin.com/D8ihT70h ok for the vp8dsp.c/vp8.c part? [20:43:29] <Yuvi> maybe_inline? [20:43:40] <BBB> it's a macro argument [20:44:17] <BBB> also, Dark_Shikari suggested I rename filter8/16 to filter16y or filtery and filter8uv or filteruv, what's your take on it? [20:46:16] <peloverde> Should Audacity be added to projects? FFmpeg is an option plugin [20:46:22] <peloverde> *optional plugin [20:46:56] <Yuvi> does inlining help for C chroma? [20:48:01] <Yuvi> OK otherwise [20:50:15] <Yuvi> and imo filter_luma / filter_chroma [20:50:52] <mru> BBB: have you noticed vp8 fate tests are failing on anything using the yasm code? [20:55:29] <lu_zero> uhm? [20:56:00] <mru> http://fate.multimedia.cx/index.php?build_record=263514 [21:23:49] <BBB> I use the yasm code? [21:24:17] <BBB> weird [21:24:34] <BBB> which commit broke it? [21:25:01] <mru> don't know [21:25:04] <mru> something today [21:25:54] <BBB> 24270 broke, 24267 is ok [21:26:10] <BBB> hm... [21:26:12] <BBB> wth [21:27:25] <BBB> I suppose 64-bit only then? [21:27:37] <BBB> x86_32 / linux uses yasm, right? [21:27:39] <BBB> that one works fine [21:27:48] <BBB> apparently I broke x86-64 with one of my patches [21:28:07] <g0th> hi [21:29:16] <mru> fix it [21:29:20] <BBB> working on it... [21:29:26] <g0th> I am the owner of a motorola milestone running android (2.1). There is now an application available by the name "Rock player" which seems to be using ffmpeg code. They charge money to get the advertisement free version. At first glance I dont see any source code on their website. I am not sure: Is this legal? [21:30:15] <g0th> If it is not I hope someone will write them an email... [21:31:36] <lu_zero> g0th please fill all the details on roundup [21:32:35] <g0th> can someone please tell me what roundup is? [21:32:50] <g0th> I suppose bugtracker [21:33:03] <g0th> hmm it counts as a bug? [21:33:08] <mru> roundup.ffmpeg.org [21:33:13] <g0th> I am not even sure if it is illegal. [21:33:14] <g0th> ok thanks [21:33:20] <mru> we know of rock player already [21:33:30] <mru> and yes, they use ffmpeg [21:33:37] <mru> illegally [21:33:44] <g0th> did you write them? [21:33:54] <mru> not me personally [21:33:59] <mru> I don't know if someone else did [21:34:45] <g0th> ok this is kind of my request: Can someone from this project write them please and pursue legal actions if they dont change anything? [21:35:16] <mru> they're in china, nothing we can do [21:35:29] <mru> we can try to get the app pulled from the market [21:35:31] <g0th> reject their inclusion in appstore [21:35:41] <g0th> yes [21:35:50] <g0th> this would force them to change it [21:36:22] <CIA-99> ffmpeg: rbultje * r24275 /trunk/libavcodec/x86/vp8dsp.asm: Attempt to fix x86-64 testsuite on fate. [21:36:25] <g0th> If I were them I would just release the source code and still charge for the software [21:36:33] <Dark_Shikari> oh, you broke x86_64? [21:36:36] <Dark_Shikari> gj BBB ;) [21:36:51] <BBB> wonderful right? [21:36:56] <BBB> should be fixed now [21:38:00] <Honoome> BBB: http://tvtropes.org/pmwiki/pmwiki.php/Main/NiceJobBreakingItHero :P [21:45:28] * BBB awaits fate's verdict [21:46:46] <mru> passes here [21:46:49] <mru> thanks [21:48:24] <twice11> Vitor1001: You were worried about the "loop expansion" I suggested for MOD data. [21:48:43] <Dark_Shikari> BBB: so, we have chroma now. mbedge next? [21:48:52] <BBB> no I'm doing sse2 chroma first [21:48:54] <twice11> If you want to have manageable complexity of the BSS, you can't represent every format pecularity in the BSS. [21:48:55] <Dark_Shikari> oh ok [21:48:56] <BBB> otherwise the whole thing is pointless [21:48:59] <Dark_Shikari> didn't know you did sse2 already [21:49:02] <Dark_Shikari> er, didn't do [21:49:08] <BBB> it requires actual code ;) [21:49:20] <BBB> (for the vertical filter) [21:49:29] <Dark_Shikari> btw, for vertical [21:49:32] <Dark_Shikari> movq / movhps [21:49:34] <Dark_Shikari> are your gods [21:49:43] <BBB> I was going to look for those :-p [21:49:48] <BBB> thanks ;) [21:49:54] <BBB> that's indeed the only code I need [21:50:20] <twice11> So as far as I can imagine, you either have the BSS being tailored to one tracker format or you loose information on the round-trip tracker->BSS->tracker. [21:50:29] <Dark_Shikari> or more exactly [21:50:30] <Dark_Shikari> movh/movhps [21:50:52] <BBB> movh sounds about right, yeah [21:53:07] <Vitor1001> twice11: At least, I don't want to degrade information in the conversion tracker->BSS->player [21:53:56] <twice11> This wouldn't prevent expanding loops on tracker->BSS, as far as I can see. [21:54:37] <twice11> And I consider loop expansion to be part of the format specific processing (e.g. MOD provides an quite unknown "repeat reverse" instruction) [21:57:24] <Vitor1001> Something to think about [21:57:32] <Vitor1001> Well, I'm going to sleep now [21:57:35] <Vitor1001> bye [21:57:58] <twice11> Vitor1001: good night [22:15:26] <BBB> fate is fixed? [22:15:29] <BBB> at least for stuff I broke [22:15:39] <_av500_> fate is inevitable [22:15:41] <mru> now please fix the rest [22:16:11] <BBB> I fixed it! [22:16:16] <BBB> what else is there to fix? [22:16:26] <mru> the other fate errors :-) [22:16:39] <BBB> not my fault :-p [22:16:52] <BBB> they shouldn't create so many weird cpu-related devices [22:16:59] <mru> that's not a prerequisite for fixing it [22:17:16] <mru> cpu-related devices? [22:17:58] <Dark_Shikari> I really like michael's approach to the mod question [22:18:13] <Dark_Shikari> mod is a compressed PCM sound format [22:18:20] <Dark_Shikari> using a matching-pursuits coding method. [22:18:59] <BBB> mru: "thingy that looks like a cpu" [22:19:07] <BBB> like sparc, or x86-64 [22:19:09] <mru> like x86? [22:19:18] <BBB> I own a x86, so it's a cpu [22:19:19] <kierank> "dont forget that we would like to be able to store mod in avi/mp4/nut" --> that doesn't sound good [22:19:34] <mru> but can we store it in a bikeshed? [22:19:47] <BBB> let's rename nut to bikeshed [22:19:52] <twice11> we need a mod->bike converter. [22:21:01] <_av500_> we need a shedalizer [22:21:20] <twice11> I don't think you really want to store "MOD" in avi/mp4/nut, but some kind of sequenced music might make a lot of sense. [22:22:47] <twice11> The inevitable question is how to store the quite big "decompression context" data in the containers. For sequenced music, the whole sample data of the different "instruments" are static context. [22:23:12] <_av500_> extradta [22:23:26] <twice11> I mean in the file, not in memory. [22:24:14] <twice11> For wav I know that there is some kind of codec specific additional data, but I don't know whether programs are prepared to handle megabytes in there. [22:24:45] <_av500_> we can always store it in an id3tag like mp3 lossless... [22:24:49] <mru> if they want to play that kind of audio, they'd better [22:25:15] <mru> mp3 lossless? wav in id3 tag or what? [22:25:23] <_av500_> yes [22:25:31] <mru> people do that? [22:25:32] <_av500_> wav-mp3 in id3tag [22:25:40] <_av500_> thomson proposed it [22:26:05] <_av500_> my mp3 parser handles it [22:26:09] * BBB kicks his sse2 H chroma inner filter b/c it doesn't work [22:26:13] <_av500_> it ignores it successfully [22:26:21] <kierank> isn't mp3pro in id3 tags? [22:26:42] <_av500_> no [22:26:51] <_av500_> pro is in private data [22:27:03] <_av500_> user data [22:27:10] <mru> ancillary data? [22:27:17] <_av500_> yes [22:27:21] <mru> bit bucket! [22:27:31] <_av500_> frame lenght - bits used [22:28:15] <_av500_> but since length is limited, they could not store the lossless residual there [23:20:58] <CIA-99> ffmpeg: bcoudurier * r24276 /trunk/libavformat/oggenc.c: In ogg muxer, free dyn allocated buffer, fix memleak [23:20:59] <CIA-99> ffmpeg: mstorsjo * r24277 /trunk/libavformat/ (aviobuf.c avio.h): url_fskip: Return an error code if the url_fseek failed [23:31:28] <pjay_> hi all ! [23:31:50] <pjay_> anyone knows about mmst.c ? i'm having problems with it, trying to debug it. [23:32:23] <CIA-99> ffmpeg: mstorsjo * r24278 /trunk/ (doc/APIchanges libavformat/avformat.h): Bump minor and add APIchanges entry for url_fskip return value change. [23:32:48] <kierank> pjay_, ask BBB when he returns [23:33:31] <pjay_> kierank thanks for the tip.

1 0