[FFmpeg-devel-irc] IRC log for 2010-07-30

[irc at mansr.com]

[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-emulator/
[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/standards/pdf/s367m.pdf
[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