Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2011

1 participants
13 discussions

IRC log for 2011-01-30
by irc＠mansr.com 31 Jan '11

31 Jan '11

[00:00:21] <spaam> mru: some ppl say it like that :) [00:04:39] <{V}> is FÃ¥n also a real word in .se or just an almost homophone (no pun intended) ? [00:05:07] <mru> it's a word [00:05:18] <mru> sort of, at least [00:09:14] <{V}> is google translate correct when it says it means idiot? [00:09:29] <mru> that's one meaning [00:10:05] <{V}> punny [00:19:33] <lu_zero> mru: where that? [00:19:57] <lu_zero> we have a sockaddr_storage in os_support iric [00:20:46] <mru> lu_zero: yes, and it's being triggered in error [00:20:50] <mru> on qnx [00:21:00] <lu_zero> qnx does have the struct... [00:21:08] <mru> apparently, yes [00:21:13] <lu_zero> but [00:21:23] <mmu> who cares about QNX ? :p [00:21:24] <lu_zero> in the obviously wrong header... [00:21:33] <lu_zero> RIM does [00:21:37] <lu_zero> oh well [00:22:13] * lu_zero doesn't have a qnx available... [00:22:17] * mru does [00:22:23] <lu_zero> and the sources disappeared... [00:22:38] <lu_zero> mind using either gcc -E or grep to figure where it got defined? [00:24:01] <mru> it's in sys/socket.h but under _XOPEN_SOURCE >= 500 [00:24:13] <mru> and #if 1 for good measure [00:25:20] <lu_zero> O_o [00:26:53] <mru> what's worse is memalign() is broken [00:27:07] <mru> it fails to align properly on certain magic sizes [00:27:33] <lu_zero> ... [00:27:39] <lu_zero> which qnx is that one? [00:27:50] <mru> 6.5.something [00:27:57] <mru> whatever was the latest a few months ago [00:28:19] <mru> 32674, 94070, 143237, 532396, 573392 all fail to 16-byte align [00:28:27] <mru> most likely others too [00:28:49] <Anaerin> lu_zero, Want a QNX? here! ftp://213.191.222.2/Inet/QNX/ [00:29:11] <mru> qnx is free for non-commercial use [00:29:14] <mru> but not open source [00:29:36] <Anaerin> mru, I know. That's a link to the old "1.44mb floppy" QNX demo disk(s). [00:29:42] <mru> ah [00:33:17] <lu_zero> qnx apache sources are opensource... [00:33:27] <lu_zero> pity nobody cared that much [00:33:47] <mru> you still get some source [00:33:57] <mru> most of the kernel for instance [00:37:55] <lu_zero> anyway seems broken beyond normal checks... [00:38:48] <mru> -D_QNX_SOURCE seems to take care of the headers [00:40:34] <lu_zero> uh [00:40:36] <lu_zero> right [00:40:55] <lu_zero> that was something I had to do when playing with momentics [00:41:04] <mru> buggy memalign is another matter [00:45:41] <lu_zero> that should be reported [00:45:57] <lu_zero> posix_memalign works better? [00:46:01] <mru> same [00:46:12] <mru> I suppose one is just a wrapper around the other [00:49:40] <bcoudu> humm valgrind still broken on osx with xcode 4 :( [00:51:12] <mru> one more qnx quirk: SA_RESTART isn't defined [00:51:28] <mru> commented out in signal.h [00:53:00] <DonDiego> gnite [02:10:53] <Dark_Shikari> BBB: what's the x86_64 stuff in the top of your patch [02:21:43] <TheFluff> does anyone know why almost every single packet and table field in the mpeg ts spec seems to have the mnemonic "bslbf" [02:21:49] <TheFluff> (what does it even stand for) [02:28:17] <bcoudu> see 2.2.6 Mnemonics :> [02:28:29] <jannau> is american baidu down? [02:28:34] <bcoudu> bitstring left bit first [02:29:41] <TheFluff> oh ok [02:29:51] <TheFluff> I skipped that part :V [02:34:03] <jannau> lu_zero: I would settle for a QNX based tablet [02:38:22] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rd33ed7b367 ffmpeg/configure: Enable native build on QNX/x86 [02:38:53] <Dark_Shikari> wtf is QNX [02:39:00] <mru> an OS [02:41:03] <jannau> used by a canadian cell phone manufacturer [02:43:03] <Dark_Shikari> an x86 cellphone? [02:44:50] <{V}> probably not, QNX probably has a few platforms it runs on. It also didn't start life as a cellphone OS [02:45:09] <mru> qnx runs on many platforms [02:45:15] <mru> arm for instance [02:46:51] <jannau> automotive is probably even after rim bought it the biggest market [02:48:34] <lu_zero> ok I'm too tired to keep working on swscale... [03:03:50] <peloverde> Has anyone looked into imdct-test failing on gcc-4.6? [03:04:08] <mru> the failure pattern is interesting [03:04:25] <peloverde> indeed [03:14:03] <peloverde> FWIW, the acodec-wma crashes are also inside fft_sse.c [03:30:03] <Dark_Shikari> BBB: ping [03:35:05] <peloverde> ugh, putting printfs above the imdct unfolding makes it go away [03:35:23] <mru> heisenbug [03:36:25] <peloverde> actually no i was in the wrong build dir, it still is failing the same way :) [03:36:55] <mru> clever bug, hiding in a different dir [03:48:14] <peloverde> Dark_Shikari: pengvado: BBB: Is there a reason we don't mangle m1m1m1m1 in ff_imdct_calc_sse()? [03:48:44] <peloverde> any other x86 experts are also welcome to chime in [03:49:38] <Dark_Shikari> I don't know what MANGLE() is [03:49:46] * Dark_Shikari does yasm only [03:50:07] <mru> Dark_Shikari: it adds _ to a name if the platform needs that [03:53:23] <peloverde> This patch makes everything play nice http://ffmpeg.pastebin.com/biJ2pytn [03:54:12] <peloverde> the av_log is there to keep the optimizer from removing m1m1m1m1 too quickly [03:56:46] <peloverde> who was defending inline asm this week? [03:57:00] <mru> someone without much clue, obviously [03:57:43] * peloverde ponders yasmizing the function [03:58:08] <mru> what is the actual error in the generated code? [03:58:23] <Yuvi> mru: it also forces global references to not use registers (which gcc often uses needlessly) [03:58:48] <mru> Yuvi: no, MANGLE as such only adds the _ [04:00:36] <Yuvi> mru: that's what the macro does, but the reason to use it over "m"() is as I said [04:00:53] <mru> that wasn't the question I answered [04:01:25] <Yuvi> also doesn't it switch between PIC and non-PIC on x86-64? [04:01:38] <mru> no [04:02:38] <Yuvi> oh, LOCAL_MANGLE does that, which MANGLE uses... [04:02:48] <mru> or it's the other way around [04:02:51] <mru> I can't remember [04:03:34] <peloverde> http://ffmpeg.pastebin.com/mZrVSq9Y [04:06:08] <mru> where's the difference? [04:10:31] <mru> I don't see any difference? [04:10:50] <mru> is the relocation entry for that reference different? [04:11:52] <mru> or is this built with the fix? [04:13:34] <peloverde> this is built without the fix [04:14:05] <mru> so tell me what's different between the two [04:14:09] <mru> I don't see anything [04:14:56] <peloverde> Ahh! [04:15:10] <peloverde> gcc-4.6 onyl puts the first entry of m1m1m1m1 in rodata [04:15:20] <mru> and I know why [04:15:44] <mru> that "m" operand only references the first element [04:15:59] <mru> *array means the first element of array [04:16:22] <mru> does it work w/o the *? [04:17:05] <peloverde> without the '*' I get "error: memory input 4 is not directly addressable" [04:17:32] <Yuvi> so gcc-4.6 is being more strict about inline asm memory operands? [04:17:44] <mru> try *(int (*)[4])m1m1m1m1 [04:19:23] <peloverde> still the same error [04:21:21] <mru> yasm is obviously the best solution [04:34:30] <peloverde> There should be a way to write that constraint properly but I have a feeling it blows up some version of gcc from 1952 which will make people upset [04:39:02] <TheFluff> does anyone have the specification for m2ts [04:39:15] <TheFluff> or actually all I want to know is where in the packet those four extra bytes go [04:41:27] <pengvado> peloverde: no reason [04:45:19] <Yuvi> mru: *(int (*)[4]) compiles on clang but causes it to copy 64 bits of the constant to the stack and use that (wtf?) [04:47:48] <mru> add const [04:49:21] <Yuvi> same thing [04:50:21] <Yuvi> peloverde: only way I can think of is to use __int128_t [04:53:54] <Yuvi> or if you're just fighting the optimizer to not eliminate m1m1m1m1, av_used or "X"(m1m1m1m1) should work [05:08:25] <BBB> peloverde: if there's enough registers [05:08:27] <BBB> Dark_Shikari: pong [05:09:25] <Dark_Shikari> BBB: answer to my question from earlier? [05:09:32] <BBB> let me backlog [05:09:56] <BBB> what's the x86-64 stuff on top of my patch? [05:09:56] <BBB> uh [05:10:57] <BBB> which part? in dsputil_mmx.c or _yasm.asm? [05:11:48] <Dark_Shikari> all the stuff at the top [05:11:51] <Dark_Shikari> what's with mmx/sse depending on x86_64? [05:12:21] <ifb> TheFluff: kierank's muxer has the extra 4 bytes at the beginning (before the sync byte) [05:12:30] <BBB> Dark_Shikari: oh that [05:13:01] <BBB> Dark_Shikari: since the function is so big, and the speed gain between sse/mmx is relatively small, I thought it'd be good to not have more than a single function of this type per arch [05:13:12] <TheFluff> ifb: thanks [05:13:15] <BBB> so for x86-32, the common denominator is mmx, for x86-64 hat's sse [05:13:25] <BBB> Dark_Shikari: if you think that's bad, I can change it, but that was the logic [05:13:33] <Dark_Shikari> this is dumb [05:13:36] <Dark_Shikari> oh [05:13:38] <Dark_Shikari> how large is it? [05:13:47] <Dark_Shikari> thing is, we don't use that logic anywhere else in ffmpeg [05:13:54] <BBB> 128 bytes x 22 plus 22x64 bytes [05:13:57] <BBB> that's true [05:14:15] <BBB> 4kb [05:14:19] <Dark_Shikari> we template much larger things than that [05:14:20] <BBB> a little over [05:14:25] <BBB> 4.5kb basically [05:14:45] <BBB> I can write two versions, one sse2 and one mmx for x86-32 [05:14:51] <BBB> it's pretty simple [05:14:56] <BBB> I just figured it might be overkill [05:14:59] <BBB> because it's barely faster [05:15:06] <BBB> but if you think it's a good idea, I can do it [05:15:24] <Dark_Shikari> I don't like introducing logical dependencies that don't make sense. [05:21:41] <BBB> ok, will change thne [05:21:44] * BBB goes to bed now [05:21:45] <BBB> more tomorrow [05:27:21] <Sean_McG> mru: first problem with running fate on Solaris -- assumes /bin/sh is bash :P [06:48:20] <Dark_Shikari> so I'm about to try sendemail now [06:48:23] <Dark_Shikari> what do I need other than from or to? [06:48:27] <Dark_Shikari> do I need to run an smtp server? [06:48:59] <drv> you can use gmail's, if you use that [06:49:04] <saintdev> you need _an_ smtp server [06:49:08] <saintdev> but what drv said [06:49:09] <Dark_Shikari> what's gmail's? [06:49:16] <Dark_Shikari> don't I need a username/password for it? [06:49:24] <astrange> smtp.gmail.com, ssl, gmail account user and pass [06:49:27] <drv> http://morefedora.blogspot.com/2009/02/configuring-git-send-email-to-use-gm… [06:49:56] <astrange> i find send-email slightly annoying, because when i reply to the thread with an updated patch [06:50:12] <astrange> my mail client sends it differently than send-email does (attachment instead of inline) [06:51:36] <Dark_Shikari> what's thread=true? [06:51:38] <saintdev> astrange: that's why i use git imap-send. Then i can just have it added as a draft [07:12:38] <Dark_Shikari> ?? [07:12:41] <Dark_Shikari> when I use git-send email HEAD [07:12:45] <Dark_Shikari> it says no patch files specified [07:12:48] <Dark_Shikari> ... but I specified it. [07:12:48] <elenril> it doesn't do anything [07:12:49] <Dark_Shikari> "HEAD". [07:12:55] <elenril> HEAD to what? [07:12:59] <Dark_Shikari> Er, my current tree? [07:13:01] <saintdev> Dark_Shikari: you have to feed it format-patch [07:13:02] <Dark_Shikari> "master" doesn't work either. [07:13:05] <Dark_Shikari> ... that's retarded [07:13:10] <elenril> you have to specify a range of commits [07:13:17] <elenril> e.g. HEAD..<some commit> [07:13:21] <Dark_Shikari> how about just HEAD? [07:13:22] <elenril> or just <some commit> [07:13:26] <saintdev> erm, actually i guess that's just imap-send [07:13:26] <Dark_Shikari> .... but I did [07:13:30] <Dark_Shikari> git send-email HEAD [07:13:35] <Dark_Shikari> HEAD is a commit [07:13:36] <elenril> you mean HEAD^ [07:13:48] <elenril> yes and it means 'send all commits between HEAD and HEAD' [07:13:49] <saintdev> Dark_Shikari: if you just give it one commit it's a "since this commit" [07:13:52] <elenril> which is a noop [07:14:09] <elenril> try git send-email -1 [07:14:19] <Dark_Shikari> HEAD^ works [07:14:29] <elenril> send-email -<number> send latest <number> of commits [07:14:41] <Dark_Shikari> Can't locate Net/SMTP/SSL.pm [07:14:43] <Dark_Shikari> wtf [07:15:34] <astrange> sudo perl -MCPAN -e 'install Net::SMTP::SSL' [07:15:54] <elenril> aptitude install libnet-smtp-ssl-perl =p [07:16:19] <Dark_Shikari> I'm not on Debian [07:16:21] <saintdev> he's on cygwin [07:16:45] <elenril> doesn't cygwin track dependencies? [07:16:54] <Dark_Shikari> cygwin doesn't have that in its package manager [07:17:08] <Dark_Shikari> Going to write /home/Jason/.cpan/Metadata [07:17:08] <Dark_Shikari> Warning: Cannot install NET::SMTP::SSL, don't know what it is. [07:17:46] <Dark_Shikari> It's Net::SMTP:SSL [07:17:48] <Dark_Shikari> Capitalization matters. [07:20:21] <Dark_Shikari> elenril: how do I force an install? [07:20:27] <Dark_Shikari> it failed like 2 tests [07:20:30] <Dark_Shikari> and won't install [07:20:32] <Dark_Shikari> unless I "force" [07:20:36] <Dark_Shikari> but I don't know how to force. [07:20:40] <Dark_Shikari> er, astrange [07:21:13] <astrange> i forget. if you do -e shell (or just 'sudo cpan') you get a console [07:21:17] <astrange> which might tell you [07:23:13] <Dark_Shikari> perl -MCPAN -e 'CPAN::Shell->force(qw(install IO::Socket::SSL));' [07:24:50] <Dark_Shikari> bah I keep needing to install all these perl deps [07:24:54] <Dark_Shikari> why doesn't git come with them :> [07:26:34] <elenril> because it's not ffmpeg? [07:27:15] <Dark_Shikari> I mean, not even the package has them as deps. [07:27:16] <Dark_Shikari> The hell. [07:27:32] <astrange> i think the packagers don't use gmail [07:27:44] <Dark_Shikari> ... My first git-send-email! [07:28:01] <elenril> yeah, just install postfix ;) [07:28:12] <saintdev> jason(a)x264.com [07:31:02] <Dark_Shikari> I'm cool, I have an official x264 email. [07:31:05] <Dark_Shikari> Only two people do! [07:31:38] <saintdev> yeah, who names their kid "Licensing" ? [07:31:47] * Dark_Shikari smacks saintdev [07:32:38] <elenril> why's the name not set? [07:33:15] <saintdev> Dark_Shikari: did you specify a TO: address? [07:33:48] <saintdev> erm i mean from address [07:33:52] <saintdev> gah [07:34:25] <Dark_Shikari> elenril: how do I do that? [07:35:06] <Dark_Shikari> BBB: ping, see ml [07:35:08] <saintdev> Dark_Shikari: if you don't specify a from address, it should just use your name that's already set [07:35:58] <Dark_Shikari> I did set a from address [07:36:03] <elenril> don't do that [07:36:11] <Dark_Shikari> ok [07:36:18] <elenril> just let it use the commit name [07:36:45] <pross-au> The Joy of Git(tm) [07:51:10] * pross-au prefers git-mutt-patch: http://ffmpeg.pastebin.com/ynsEDpck (alternative to git-send-email) [08:26:10] <Dark_Shikari> BBB: another thought, the edge emulation check in vp8 is being duplicated for chroma channels [08:26:18] <Dark_Shikari> I HIGHLY doubt that's optimized out by gcc [08:53:21] <peloverde> Is av_used a thing? grep isn't finding it [08:57:36] <siretart> peloverde: there is av_unused, if there is a gcc attribute for it, I think libavutil/common.h would be the right place to implement it [08:58:08] <Dark_Shikari> peloverde: av_used(x) does x = x [08:58:09] <Dark_Shikari> iirc [08:58:48] <peloverde> Dark_Shikari: I thought that was av_uninit() [09:01:48] <Dark_Shikari> oh [09:01:53] <Dark_Shikari> you're right [09:02:22] <peloverde> What are the consequences of mangle? can it fuck shit up for PIC? [09:03:40] <Dark_Shikari> I think MANGLE is for pic. [09:05:00] <peloverde> what about "r"(m1m1m1m1) is that considered bad? [09:06:21] <Yuvi> MANGLE forces non-PIC references on 32-bit [09:07:25] <peloverde> what about "r"(m1m1m1m1)? [09:08:11] <Yuvi> attribute_used is what I was thinking of for av_used [09:08:52] <peloverde> cool, but the whole used/unused thing only comes into play with mangle, the optimizer is aware of variables that occur in constraints [09:09:03] <Yuvi> yeah [09:09:31] <Yuvi> thus the "X"(m1m1m1m1), which does MANGLE but not LOCAL_MANGLE [09:09:35] <Dark_Shikari> m1m1m1m1m1m1m1m1? [09:09:37] <Dark_Shikari> http://www.youtube.com/watch?v=kV4vHpqrj6E&t=0m10s [09:10:02] <Yuvi> "r"(m1m1m1m1) will work obviously, it just needs to load the address into a register instead of using a memory operand [09:10:10] <siretart> hm. it seems that MANGLE rather special cases x86_64 rather than 32 bit [09:10:38] <siretart> however other arches puke at PIC in shared libraries as well, I wonder why this hasn't hit us so far [09:11:01] <Yuvi> MANGLE's only used for x86 asm [09:11:06] <Dark_Shikari> also http://www.youtube.com/watch?v=gUeeIjyI7QQ#t=0m13s [09:11:09] <peloverde> "x"(m1m1m1m1) did not work for me [09:11:40] <siretart> Yuvi: oh, interesting. perhaps this piece of information should then be added to libavutil/internal.h, I guess? [09:12:52] <peloverde> I've always found gcc asm constraints to be poorly documented [09:15:14] <Yuvi> hm, "X" gives an extra $ on x86 apparently, I guess I was thinking of something else [09:15:48] <Yuvi> siretart: theoretically I guess any other inline asm could use it, it's just not done currently [09:15:59] <Yuvi> since x86 is about it for large inline asm [09:17:25] <siretart> yeah, I see that [09:17:51] <peloverde> I really wish I remembered who was defending inline asm so I could make him fix this [09:17:58] <Dark_Shikari> michael? [09:27:50] <peloverde> mru: When are you going to ban hammer gabu? [09:48:38] * thresh finds that amusing: http://twitter.com/#!/martinbogo/status/31253355032485888 [09:56:51] <Yuvi> peloverde: if you really want to use inline asm constraints, http://pastebin.com/q8zFrKJg should work but feels dirty [09:58:39] <astrange> is something wrong with declaring m1m1m1m1 as __m128i? [09:58:43] <astrange> that would fix it [09:59:09] <Yuvi> __m128i isn't allowed to be initialized to anything [10:00:16] <lu_zero> peloverde: where? [10:01:28] <astrange> http://pastebin.com/94tDRGmf [10:10:22] <Yuvi> looks like that works too [10:11:39] <astrange> that typedef should be how gcc/icc define m128i, i didn't check though [10:13:03] <Yuvi> btw, it seems that "%a0" / "X"(symbol) is the probably the correct inline asm syntax for this [10:13:18] <Yuvi> which takes care of PIC and everything [10:35:45] <thresh> bloody hpux aCC doesnt fail on unknown options :S [10:36:32] <spaam> thresh: hpux? why are you using it? [10:37:14] <thresh> spaam: because I can [10:37:31] <spaam> ok :) [11:08:42] <thresh> ROTFL, compiler segfaults on libavcodec/vorbis_enc.c :) [12:42:44] <Compn> btw if mplayer docsgenerate is failing, i'm assuming ffmpeg's docsgenerate is also failing mru [12:42:53] * Compn hasnt verified tho [12:43:12] <Compn> anyone check if ffmpeg docs are being generated ? [12:43:19] <Compn> updated that is [13:08:10] <{V}> Compn, there was a small change to the use of texi2html which included bumping the required version to 1.78. Could that be the problem? [13:15:06] <mru> could well be [13:17:54] <mru> Sean_McG: none of our scripts require bash [13:18:01] <mru> Sean_McG: they do require a posix shell [13:18:05] <mru> which solaris /bin/sh is not [13:18:15] <mru> you need to use /usr/xpg6/bin/sh there [14:32:57] <BBB> Dark_Shikari: yeah, I think h264 and all mpeg decoders do chroma and luma all together as most-inner-loops, whereas I do them separately as most outer loops or so [14:33:36] <BBB> Dark_Shikari: I think I tried to merge it the other way around but something didn't work quite right so I didn't do it, the code got more complex in another way, I forgot how exactly [14:36:03] <Compn> {V} : mplayer script is unrelated problems anyways, just i think the scripts got reset [14:36:11] <Compn> since i thought this bug was fixed long ago [14:36:32] <{V}> kay [14:36:57] <mru> reload and rejoice [14:37:41] <Compn> e.g. mplayer script needs --yasm='' [14:37:47] <Compn> ./configure --yasm='' [14:37:55] <Compn> to skip the yasm check [14:46:41] <kierank> Anaerin: can you post that mediaroom sample somewhere else [15:40:35] <twnqx> ... interesting, just installing foobar2000 in wine crashed audacious [15:46:52] <saste> lu_zero: please bump minor and add an APIchanges entry for av_dlog() [15:47:17] <elenril> which reminds me, i probable have to do the same for all the avio_* stuff [15:48:27] <lu_zero> elenril: mind merge all those changes in one? [15:51:27] <elenril> sure, no point in five successive bumps ;) [15:51:51] <kshishkov> bump once but += 5 instead [15:52:56] * elenril bumps kshishkov on head [15:54:47] * kshishkov reminds elenril that head is not mandatory to be FFmpeg developer [15:56:46] * pJok julmusts kshishkov [15:56:56] * kshishkov accepts [15:57:31] <kshishkov> please add a piece of julskinka on tunnbrÃ¶d [16:38:27] <uau> Kovensky: you talked before about needing a separate pkg-config binary for crosscompiling because of the default search directory - does PKG_CONFIG_LIBDIR not work for that? [16:41:15] <mru> it still falls back on the compiled-in default iirc [16:41:25] <mru> that, or totally ignore the env var [16:41:57] <uau> the documentation for that says "Replaces the default pkg-config search directory, usually /usr/lib/pkgconfig" [16:42:38] <mru> don't tell me you trust documentation [16:42:38] <uau> PKG_CONFIG_LIBDIR=/tmp/ pkg-config --libs zlib [16:42:38] <uau> Package zlib was not found in the pkg-config search path. [16:43:08] <uau> doesn't fall back to the default [16:43:24] <mru> then I guess they fixed it [16:43:38] <mru> I know I've struggled with it picking up system libs no matter what I did [16:44:20] <CIA-38> ffmpeg: Vasyl' Vavrychuk <vvavrychuk(a)gmail.com> master * r665132e620 ffmpeg/libavformat/ (mpeg.h mpegts.c): [16:44:20] <CIA-38> ffmpeg: mpegts: remove get_pts duplicate of ff_parse_pes_pts. [16:44:20] <CIA-38> ffmpeg: Signed-off-by: Vasyl' Vavrychuk <vvavrychuk(a)gmail.com> [16:44:20] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:52:19] <uau> Sean_McG: btw if you're familiar with gcc development, do you know whether handling of the "restrict" keyword has been improved from the "totally useless crap" level? [16:53:16] <uau> in gcc 4.5 it's still that - even blatant cases like "*a = 0; *b = 1; return *a;" are not optimized unless *both* a AND b are declared with "restrict" [16:54:35] <BBB> uau: isn't that correct? although last time I checked even if you did add restrict it still wouldn't optimize [16:58:04] <mru> damn, you're making go read the c99 spec on restrict _again_ [16:59:42] <uau> BBB: correct that it's only done if *both* have the restrict qualifier? not as far as i can see - the spec talks about "modifications" to an object accessed through a restrict pointer, and i don't see anything limiting that to "modifications done through another restrict pointer" [17:01:11] <uau> if i read the spec correctly, then *either* a or b having the restrict qualifier should be enough to know that "return *a;" is equal to "return 0;" [17:01:27] <BBB> uau: sounds like nitpicking to me. if restrict is of interest to you, you add it to _all_ objects that don't overlap with one another, not just one. if you don't care about restrict, then you don't (and don't get the optimization). if you're not sure if one object has no overlap but you're sure others do, you add it only to those some, and then gcc's behaviour is correct [17:01:42] <BBB> what if you have *a, *b and *c, but only a and b are restrict? [17:01:57] <BBB> to me that means "I'm sure a and b don't overlap with one another, but I have no idea what c points to" [17:01:57] <mru> whatever it means exactly, it's still not quite what you want in many cases [17:02:09] <BBB> because if you did know for sure, you'd have declared c as restrict also [17:02:18] <BBB> and 2/3 being restrict still allows for optimizations [17:02:32] <mru> I'd like a way to say that two pointers either point to entirely disjoint _or_ exactly overlapping objects [17:03:12] <BBB> that'd be nice for things like interleave(dst, src1, src2); to make dst and src be the same pointer [17:03:12] <uau> BBB: you're missing the point [17:03:31] <uau> adding restrict to "all objects that don't overlap another" wouldn't work [17:03:39] <BBB> uau: because? [17:03:42] <uau> because there are still objects that do overlap something [17:03:43] <Sean_McG> mru: Solaris /bin/sh doesn't like version.sh [17:03:49] <mru> BBB: exactly, but interleave doesn't work that way [17:03:59] <mru> you can't do an inplace interleave of arbitrary size [17:04:01] <BBB> uh, well [17:04:03] <uau> and now you couldn't tell that those don't overlap the object you're interested in [17:04:05] <mru> unless you want log(n) runtime [17:04:05] <BBB> sum(dst, src1, src2) [17:04:13] <BBB> interleave was a bad example [17:04:14] <mru> Sean_McG: solaris /bin/sh is not posix [17:04:21] <mru> version.sh is posix [17:04:22] <Sean_McG> aye, s'what I figured [17:04:23] <BBB> anything where dst and src increment by the same stride per loop iteration [17:04:36] <mru> yes [17:04:47] <Sean_McG> can we patch it the same way configure is patched, to detect if it's broken? [17:05:51] <mru> or have configure set SHELL in config.mak and use that to run version.sh [17:07:07] <uau> BBB: so to clarify a bit more, telling the compiler that "these couple of objects don't alias *each other*" would be fairly useless, because that still leaves all the other objects in the program - if they're accessed at any point you couldn't be sure about the special objects any more [17:07:13] <Sean_McG> hmm that might be a better idea [17:07:30] <uau> you really to say that "these couple of objects don't alias *anything*" [17:07:37] <BBB> uau: you're talking about thread-safety and that's a whole different issue anyway [17:07:37] <uau> want to say [17:07:55] <uau> BBB: where did you get that idea from? what i said had nothing to do with thread safety [17:07:58] <mru> restrict has nothing to do with threads [17:09:46] <BBB> "if they're accessed at any point you couldn't be sure about the special objects any more" [17:09:52] <BBB> how else do I read that? [17:10:34] <mru> my understanding after rereading the spec is that restrict promises that _no_ other pointer will alias the object while the restrict-qualified one is in scope [17:10:43] <BBB> mru: I know that, but I can't read uau's response in any other way... anyway, restrict doesn't work, I generally just read values from pointers out in a temp var if I believe they are restrict [17:10:47] <BBB> at least that always works as intended [17:10:56] <uau> BBB: that if the program makes access through any other pointer it couldn't be sure about the state of the restrict-qualified object any more if restrict was only guaranteed to work between *two* qualified pointers [17:12:42] <uau> and note that has a pretty big effect with for example function calls - if you have a restrict pointer in a block, and don't pass that pointer to functions, then you can know for sure that the functions don't change anything you access through the pointer [17:32:09] <Sean_McG> I don't understand what M= from common.mak is supposed to do? [17:32:49] <mru> that's for the pretty "CC file.c" output [17:32:54] <Sean_McG> ahhhhh [17:33:05] <Sean_McG> OK, cool [17:33:11] <mru> I admit it's a bit non-obvious how it works [17:40:25] <Anaerin> kierank, there are samples downloadable from http://dl.dropbox.com/u/16213885/Mythtv-NewMax/channel4_ctv_vlc_rawdump [17:40:46] <kierank> thanks [17:44:04] <Anaerin> kierank, I've updated the roundup issue, too, as the original message has been lost by it. [17:58:57] <kierank> Anaerin: ah it's one of those ts files with some weird headers [17:59:28] <mru> ts files don't have headers [17:59:46] <kshishkov> do they have anything except CBR? [18:00:06] <mru> PCR [18:00:37] <mru> and strictly speaking, files don't have a bitrate [18:00:44] <mru> they exist in their entirety all the time [18:00:55] <kshishkov> streams [18:01:37] <elenril> ts files are the beginning and the end! [18:02:11] <kierank> in the beginning god created a ts file [18:02:18] <kshishkov> and s/bitrate/requirements for data size for coding given amount of time/ [18:02:40] <kshishkov> kierank: and devil created perfect muxer for it as a reference implementation [18:02:58] <kierank> what reference implementation [18:03:18] <kierank> the reference implementation is useless [18:03:19] <kshishkov> Hypothethical reference muxer [18:04:27] <kierank> well anyway these days nobody follows the specs apparently [18:04:48] <kshishkov> is it possible? [18:04:57] <kierank> kshishkov: no idea [18:05:04] <mru> to follow the spec? [18:05:05] <kshishkov> to follow spect to the last letter and typo [18:05:16] <kierank> ts muxing and hrd are not specs. They are analyzer compliance tasks [18:05:35] <kierank> s/are not/do not involve following [18:06:04] <mru> ts muxing is only hard when you don't have all the stream parameters [18:06:08] <mru> and I mean all of them [18:06:48] <kshishkov> i.e. only in practice [18:06:48] <mru> if you have all the vbv buffer sizes, delays etc, it's not that complicated [18:06:58] <mru> the hard part is estimating the unknown parameters [18:07:00] <kierank> mru: yep, that's why in my muxer i cheated and made the user set all the params [18:07:38] <mru> if you underestimated the buffer size for instance, you might suddenly find yourself with an underflow [18:08:05] <kshishkov> mru: reminds me of popular FFmpeg message [18:27:38] <spaam> which one? [18:28:08] <kshishkov> about buffer underflow [18:42:24] <chandoo> hi :) [18:43:06] <kshishkov> ni hao [18:59:28] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r13156f40e1 ffmpeg/ffplay.c: [18:59:28] <CIA-38> ffmpeg: ffplay: in video_thread(), use av_dlog() for timestamp logging. [18:59:28] <CIA-38> ffmpeg: Disable logging of rescaled timestamps if DEBUG is not enabled. [18:59:28] <CIA-38> ffmpeg: Avoid debug log spamming with -loglevel debug. [18:59:28] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [19:02:14] <Tjoppen> kshishkov: http://www.youtube.com/watch?v=C8Wu3Bps9ic [19:08:23] <kshishkov> Tjoppen: tack, when I'll be ready to cook kÃ¶ttbullar I'll do them that way [19:08:32] <kshishkov> but with lingonsylt [19:09:04] <wbs> Tjoppen: lol [19:09:15] <pJok> kshishkov, if you prefer hardcore swedish cooking, lookup ordinary swedish mealtime on youtube... [19:09:53] <Tjoppen> pJok: that's exactly what I posted [19:10:09] <pJok> ah [19:10:15] <pJok> i didn't see your link actually :) [19:10:53] <pJok> sidepork pandemonium is rather amusing [19:11:09] * kshishkov ate kÃ¶ttbullar in Uppsala and different places in Stockholm including Skansen [19:12:28] * _av500_ eats em at ikea [19:12:41] <Tjoppen> I didn't eat sidflÃ€sk until recently. oh, how I have missed out [19:12:52] <Tjoppen> must try it with brown beans next time [19:14:59] <pJok> Tjoppen, you certainly have... you can try a danish dish... sidflÃ€sk med persiljesaus och potatis [19:15:49] * kshishkov has vildsvinkorv [19:16:41] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r2855080447 ffmpeg/ffplay.c: [19:16:41] <CIA-38> ffmpeg: In ffplay:get_video_frame(), use frame->pkt_pts rather than reordered_opaque. [19:16:41] <CIA-38> ffmpeg: AVCodecContext.reordered_opaque is deprecated for this specific use. [19:16:41] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [19:36:37] <Tjoppen> wait a minute.. regular ordinary swedish meal time is shot in umeÃ¥ [19:37:01] <Tjoppen> that ica is just 50 from where I live. how come I haven't heard of this earlier? [19:37:05] <Tjoppen> *50m [19:37:33] * kshishkov notes to try visiting UmeÃ¥ this summer [19:50:25] <spaam> Tjoppen: fail pÃ¥ dig [19:52:31] <pJok> Tjoppen, probably because its fairly new? [19:53:11] <Tjoppen> aha [19:53:34] <pJok> go eat with them? :P [20:16:25] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r73be29b0c4 ffmpeg/libavcodec/vp8.c: [20:16:25] <CIA-38> ffmpeg: Slightly simplify VP8 inter_predict [20:16:25] <CIA-38> ffmpeg: Merge an if and a switch. [20:19:09] <Tjoppen> hm, no gmaxwell here. just spotted a typo in the celt rfc [20:19:38] <Tjoppen> one of the formulas in the pvq part has + instead of -, which led me to confusion [20:19:58] <mru> Tjoppen: try in #vp8 [20:21:27] <Tjoppen> ok [20:22:02] <mru> but he's not there either [20:22:13] <Tjoppen> so I see [20:22:36] <Tjoppen> monty's there though [20:43:42] <_av500_> sorry in german: http://ahoipolloi.blogger.de/stories/1767834/ [20:45:22] <mru> hehe [21:02:13] <Sean_McG> mru: to fix my /bin/sh issues, OK to write a patch that teaches configure to store $SHELL in config.mak? [21:10:34] <mru> Sean_McG: do the tests in configure identify a working shell? [21:11:42] <Sean_McG> yes, Sol10 has /bin/bash, but /bin/sh is not bash [21:12:11] <mru> what I mean is, are the checks sufficient to reject /bin/sh? [21:12:33] <Sean_McG> yes, it looks for a "broken shell", and then tries to run bash [21:13:07] <mru> btw, doesn't solaris have a variable to request proper posix behaviour from /bin/sh? [21:13:12] <mru> like irix and tru64 do [21:13:17] <Sean_McG> don't know [21:13:30] <mru> on irix setting _XPG=1 makes it behave [21:13:43] <mru> on tru64 it's BIN_SH=xpg4 [21:13:44] * Sean_McG checks the manpage, but I'm betting the answer is no [21:13:53] <mru> how rude of them [21:14:30] <Sean_McG> ah... there's /usr/xpg4/bin/sh, but that's not guaranteed to be in the path, and it's also not /bin/sh ;) [21:15:15] <mru> btw, you'll have to put /usr/xpg4/bin before /bin in your path [21:15:25] <mru> otherwise some grep and sed commands we use will fail [21:15:42] <Sean_McG> yeah and it is in my case, but scripts still ask for /bin/sh by name [21:15:53] <mru> yes, different problem [21:16:12] <mru> but the aforementioned unixes have ways of making /bin/sh a true posix shell [21:16:49] <Sean_McG> yeah, looks like Sun failed at that one [21:17:11] <mru> kind of weird [21:17:25] <mru> they always led the way on ELF-related things [21:17:47] <Sean_McG> so I think since configure identifies a working shell, I should just jam that into config.mak and then tell it to run version.sh to run with $SHELL [21:17:47] <mru> and system-level stuff in general [21:25:35] <mru> Sean_McG: does this work? http://pastebin.com/M8Ynu63m [21:26:28] <Sean_McG> it's looks very similar to what I was just trying to write... but I think I like yours better. [21:26:32] * Sean_McG tests [21:27:23] <mru> SHELL in the normal environment usually means the user's interactive shell [21:27:31] <mru> so I don't want to mess with that in the configure script [21:27:51] <Sean_McG> aye, but what about just picking up what configure identifies? [21:28:03] <mru> that's what my patch does [21:28:07] <Sean_McG> OK [21:29:37] <Sean_McG> hunh... Makefile hunk 1 failed... copy paste poop maybe? [21:30:07] <mru> pastebin probably fucked with the text again [21:30:40] <mru> http://pastie.org/1512922 [21:32:14] <mru> yeah, pastebin turns line breaks in to windows-style [21:32:17] <mru> fuck pastebin [21:35:03] <Sean_McG> sean@tsukimi:/var/opt/BUILD/ffmpeg-fate.amd64/src$ gpatch < /tmp/pastie-1512922.diff [21:35:06] <Sean_McG> patching file Makefile [21:35:08] <Sean_McG> Hunk #1 FAILED at 104. [21:35:11] <Sean_McG> garrrrr [21:35:57] <Sean_McG> this wouldn't happen to be a ffmpeg vs. ffmpeg.git thing would it? [21:36:17] * Sean_McG fixes manually [21:36:21] <mru> sorry, it's my fault [21:36:33] <mru> copy&paste tabs from xterm doesn't always work [21:37:57] <mru> fixed the pastie [21:38:00] <Sean_McG> OK [21:38:05] <mru> now md5 matches diff output [21:42:19] <Sean_McG> mru: cheers dude, that works [21:47:05] <Sean_McG> hrm, or maybe not [21:47:29] <Sean_McG> sean@tsukimi:/var/opt/SOURCES/ffmpeg$ bash ./tests/fate.sh ~/Documents/ffmpeg-fate.cfg [21:47:30] <spaam> haha [21:47:32] <Sean_McG> Already up-to-date. [21:47:34] <Sean_McG> /var/opt/BUILD/ffmpeg-fate.amd64/src/version.sh: syntax error at line 4: `revision=$' unexpected [21:48:21] <mru> that's the fate.sh script running version.sh directly [21:48:33] <Sean_McG> ah. [21:48:51] <mru> I wonder how the solaris machines currently running fate do it [21:54:52] <Sean_McG> they run OpenSolaris which is different (/bin/sh *is* bash) [21:56:34] <mru> I see [21:59:11] <mru> the fate system has lots of scripts [21:59:33] <mru> I'm not sure I want to add the mess required to pass around a shell variable [21:59:53] <mru> you could easily make your /bin/sh a proper shell [22:00:09] <Sean_McG> I could, and risk breaking legacy scripts [22:00:17] <mru> put a little wrapper around it checking for an env var and exec either the real thing or bash depending [22:00:27] <Sean_McG> oh hrm. [22:01:25] <mru> that way it would still be the same old shell for most things [22:01:35] <peloverde> Is there a document that describes MANGLE? I feel like I'm still missing something [22:01:47] <mru> peloverde: the header file that defines it [22:01:51] <mru> it's quite simple really [22:02:38] <mru> you probably want to use LOCAL_MANGLE here though [22:02:46] <mru> since the variable in question is static to the file [22:02:48] <peloverde> It's defined to two more macros, one of which doesn't seem to be defined anywhere [22:02:50] <mru> hence no prefix [22:03:35] <peloverde> I can't use local mangle because of DCE [22:03:50] <mru> dce? [22:04:25] <peloverde> dead code, unused static variables [22:05:24] <uau> peloverde: i think the "right" answer to your problem would be what astrange said earlier, use a 128-bit type for the constant [22:05:53] <mru> or convert it all to yasm [22:05:56] <uau> and for the MANGLE hack av_unused should work [22:06:13] <mru> no [22:06:17] <mru> av_unused does something else [22:06:25] <mru> av_used is what you want, if it exists [22:06:28] <mru> if not, it should be added [22:08:06] <uau> attribute_used is the right one i think [22:08:15] <mru> yes, I noticed [22:08:18] <mru> but that's ridiculous [22:08:20] <mru> let's rename it [22:08:20] <peloverde> according to the docs attribute used only applies to functions [22:08:40] <mru> then docs are wrong [22:09:00] <mru> my docs say it works on both [22:09:11] <mru> `used' This attribute, attached to a variable, means that the variable must be emitted even if it appears that the variable is not referenced. [22:09:48] <peloverde> sorry i was in the wrong file [22:10:22] <uau> you were looking at the "attributes of functions" file and it only talked about functions? [22:13:52] <Sean_McG> OK so it looks like fate is chugging along now, albeit with these local mods [22:15:14] <Yuvi> mru: the systems that prefix "_" to symbols do it for static variables too [22:15:24] <Dark_Shikari> mru: heh, you should see some of AMD's XOP instructions. [22:15:27] <Dark_Shikari> I'm looking over them now [22:15:47] <Dark_Shikari> one of them lets you perform a SIMD byte rotate, with a different arg per byte [22:15:53] <Sean_McG> Yuvi: OS X is one of those, yes? [22:16:02] <Dark_Shikari> and of course the insane shuffle that can perform a different operation per byte [22:16:10] <Dark_Shikari> and they're finally adding multiply-accumulate after only 15 years [22:16:38] <Yuvi> Sean_McG: yeah [22:18:10] <Dark_Shikari> oh, I can't find the permute. they only have floating point ones. blah [22:19:14] <Dark_Shikari> god avx is a mess. [22:19:21] <peloverde> attribute_used + DECALARE_ALIGNED + const appears to be DECLARE_ASM_CONST() [22:19:37] <peloverde> but it is only static on some platforms [22:19:51] <mru> peloverde: I want to tidy up that mess [22:20:17] <mru> I tried once but certain people prevented it [22:20:54] <mru> Dark_Shikari: what's XOP? [22:21:23] <peloverde> what do you mean by tidy? [22:21:30] <mru> make less messy [22:21:49] <Dark_Shikari> AMD's new instruction mess [22:21:55] <Dark_Shikari> extension to AVX [22:21:55] <peloverde> how so? [22:22:02] <mru> Dark_Shikari: they're still playing the not-quite-intel game? [22:22:04] <Dark_Shikari> Yes [22:22:08] <Dark_Shikari> Well, here's what happened [22:22:13] <Dark_Shikari> AMD was going to do SSE5, Intel was doing AVX [22:22:19] <Dark_Shikari> Then AMD realized their SSE5 opcode design was shit [22:22:23] <Dark_Shikari> and they adopted AVX's instead [22:22:29] <Dark_Shikari> and tacked on their own instructions to it. [22:23:05] <mru> Yuvi: are you sure? [22:23:59] <hyc> Dark_Shikari: sure, but then Intel pulled a fast one and decided to drop FMA4 and only do FMA3 [22:24:05] <Dark_Shikari> hyc: that was another story [22:24:07] <Dark_Shikari> which was hilarious [22:24:08] <Yuvi> mru: on OS X, yes, and MANGLE is used on static const variables in other files, so... [22:24:09] <mru> fma? [22:24:14] <mru> Yuvi: ok [22:24:14] <Dark_Shikari> mru: fused multiply-add [22:24:18] <Dark_Shikari> FMA4 == 4-operand version [22:24:30] <Dark_Shikari> FMA3 == 3-operand version, but with different variations on the instruction to allow for all the possibilities of FMA4 [22:24:39] <Dark_Shikari> i.e. pushing the complexity into the opcode instead of adding a 4th input reg [22:24:41] <mru> scary stuff that [22:24:45] <Dark_Shikari> So what happened was [22:24:51] <Dark_Shikari> Intel said FMA4, AMD said FMA3 [22:24:57] <Dark_Shikari> then Intel figured "eh, FMA4 isn't very important, let's do FMA3." [22:25:01] <mru> do you mean ieee754 fused multiply-add? [22:25:04] <Dark_Shikari> AMD said "eh, FMA3 isn't very important, we'll be compatible and do FMA4." [22:25:10] <Dark_Shikari> And they swapped. [22:25:17] <Dark_Shikari> Now they're both still as incompatible. [22:25:25] <Dark_Shikari> Just doing the opposite of what they previously did. [22:25:27] <Sean_McG> lollerblade [22:25:30] <Dark_Shikari> Yeah, IEEE iirc [22:25:33] <mru> with no intermediate rounding [22:25:40] <hyc> total flustercuck. [22:25:56] <Dark_Shikari> the problem is that x86 doesn't have a central standards committee [22:26:04] <Dark_Shikari> so even when AMD and Intel *want* to work together, they STILL FAIL. [22:26:10] <mru> such instructions are annoying since if the compiler decides to use them, you suddenly get different results [22:26:18] <Dark_Shikari> nobody is ever supposed to rely on float rounding [22:26:38] <mru> no, but it's still annoying when things differ for no apparent reason [22:26:50] <mru> makes checking things for correctness that much harder [22:27:00] <uau> isn't that one of the instructions that C99 specifies in a way that you're supposed to be able to rely on [22:27:21] <mru> autofail of the day: checking uint32_t is 32 bits... configure: error: could not compile program using uint32_t [22:27:33] <Sean_McG> hahah [22:27:45] <mru> it's fucking _defined_ to be 32 bits [22:27:49] <hyc> lol [22:27:56] <mru> if you have the type, it's _guaranteed_ to be exactly 32 bits [22:28:28] <uau> Dark_Shikari: btw there is stuff that depends on exact float rounding - and that's why it is specified by standards [22:28:44] <hyc> mru: you on a TOPS10 box? ;) [22:29:01] <mru> cross-compiling [22:32:14] <Dark_Shikari> mru: LOL [22:32:20] <peloverde> Here is a goofy question, should there be some sort of mangle that is LOCAL_MANGLE when DECALRE_ASM_CONST is static and MANGLE when it isn't? [22:32:34] <DonDiego> peloverde: seen the aac ltp patch already? [22:33:11] <mru> peloverde: no, MANGLE should always be used [22:33:23] <peloverde> mru: why? [22:33:27] <mru> LOCAL_MANGLE is for local names only [22:33:27] <peloverde> DonDiego: yes [22:33:32] <mru> don't know when you'd use it [22:33:55] <peloverde> THEN WHY WERE PEOPLE TELLING ME I WANTED LOCAL_MANGLE INSTEAD!!!!? [22:34:03] <mru> because I misremembered [22:34:04] <mru> sorry [22:34:10] <peloverde> it's ok [22:34:21] <peloverde> this is just a little frustrating [22:34:41] <mru> I know, it's inline asm [23:09:01] <Anaerin> kierank, It's a RTP stream, with an MPEG-TS container inside. FFMpeg used to identify it as H.264 and two AAC streams (and one unknown stream, probably closed captions). Now it gives a weird codec ID (1024) and a stream type of [0][0][0][0] [23:09:27] <kierank> rtp :/ [23:13:26] <lu_zero> Anaerin: mind trying a small patch? [23:13:34] <Anaerin> Not at all. [23:13:40] <lu_zero> and/or giving me the url? [23:13:57] <Anaerin> The URL is multicast, and ISP limited, unfortunately. [23:14:35] <lu_zero> free.fr? [23:14:40] <Anaerin> I've got some wireshark captures. [23:14:47] <Anaerin> No, Sasktel Max. [23:15:06] <lu_zero> good, another field to test it =) [23:15:21] <j-b> BBB: does lavc support AMR-WB+ ? [23:15:44] <BBB> doesn't sound familiar [23:15:47] <lu_zero> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/52488 [23:15:47] <BBB> only AMR-WB afaik [23:15:51] <BBB> what is amrwb+? [23:15:57] <Dark_Shikari> One better. [23:16:20] <j-b> BBB: bigger, faster, more stupid :D [23:16:32] <BBB> Dark_Shikari: that is amrwb++ [23:16:38] <BBB> amrwb+ sounds like a parsing error [23:16:41] <j-b> half-one better :) [23:17:00] <Sean_McG> hmmmm, same fails as Linux when I run fate on Sol10 with gcc 4.6 [23:17:01] <lu_zero> I planned to push this on the tree once tested ^^; [23:17:57] <lu_zero> (while I'm hacking the slightly more uniform solution) [23:19:25] <Dark_Shikari> BBB: http://pastebin.com/UBrDYB1e bench please, I can't get my stddev low enough today [23:21:09] <Anaerin> Patch applied, making now. [23:23:33] <kierank> j-b: ^ there's the guy you want to ask about amr-wb+ [23:23:48] <superdump> who? [23:24:08] <kierank> you [23:24:11] <j-b> well, lavf/isom.c doesn't know sawp, so I guess there is a reason [23:26:53] <BBB> Dark_Shikari: that shouldn't matter, the function is inlined so luma/chroma is always expanded in the generated asm already (I checked that) [23:27:15] <Dark_Shikari> Merged [23:27:26] <Dark_Shikari> in current code, the emu edge checks get repeated [23:27:29] <Dark_Shikari> along with the mv0 check [23:27:39] <Dark_Shikari> it would be better to merge luma/chroma too but that would be uglier [23:27:55] <Dark_Shikari> my benches suggest it's a bit faster, but I can't be sure [23:28:38] <j-b> kierank: the code tells me it isn't supported [23:29:27] <superdump> there isn't a wb+ decoder in ffmpeg to my knowledge :) unless someone sneaked one in while i was away [23:29:44] <Anaerin> lu_zero, Patch (applied to latest trunk with fuzzing) broke the build: libavformat/mpegts.c: In function âff_mpegts_parse_openâ: | libavformat/mpegts.c:1802: error: implicit declaration of function âmpegts_set_serviceâ [23:29:52] <lu_zero> uhm? [23:29:54] <lu_zero> wait [23:30:10] <lu_zero> let me update it [23:30:17] <Anaerin> Thanks. :) [23:30:32] * mru read that as "illicit declaration" at first [23:30:50] * mru makes note to include such an error message if he ever writes a compiler [23:31:10] <Anaerin> Along with "Unlawful instruction"s? [23:33:25] <BBB> Dark_Shikari: it's probably slightly faster, it'd be nice if we could prevent the code duplication but I guess that's hard... in principle I'm ok with it, I'll benchmark it in a little (working on finishing your comments on my emu_edge patch right now) [23:33:36] <Dark_Shikari> ok [23:34:00] <lu_zero> mpegts_set_service doesn't exist... [23:35:36] <Anaerin> That could be a problem. [23:35:46] <lu_zero> drop that line and tell me if it works [23:36:22] <Anaerin> So, essentially, set auto_guess to 0 [23:36:48] <Anaerin> okay, passed that point. still Make'ing [23:39:40] <lu_zero> Anaerin: you'll be around tomorrow? [23:40:03] <Anaerin> No, actually. I'm headed out of town 'til Tuesday night. [23:40:13] <lu_zero> and/or you'd be able to give me a vpn to try myself some stuff? [23:40:17] <lu_zero> I see [23:41:13] <Anaerin> I don't have the upstream to provide a VPN, unfortunately. But you can use those stream captures, combined with rtpdump, to play it back locally to create a "virtual stream" [23:52:40] <lu_zero> Anaerin: I'll look into it [23:56:15] <Anaerin> lu_zero, Thanks. Here's the output from an older ffprobe run on these streams, if that helps: http://pastebin.com/WZVLX2Hq [23:57:29] <lu_zero> the changed bettered the situation somehow? [23:57:50] <lu_zero> uhmm [23:57:52] <Anaerin> Right now, ffprobe is just sitting there, with no "probing stream" information at all. [23:57:59] <lu_zero> I see... [23:58:20] <Anaerin> (Using loglevel debug) [23:59:33] <Anaerin> ...And still sitting there... [23:59:44] <lu_zero> I see

1 0

IRC log for 2011-01-29
by irc＠mansr.com 30 Jan '11

30 Jan '11

[00:00:51] <mmu_man_> upgrade ? :p [00:01:22] <jannau> that would also break the layout [00:01:28] <mmu_man_> does this old one handle -number-footnotes & -number-sections ? [00:01:44] <mmu_man_> --number-footnotes! 1 output footnote numbers. [00:01:44] <mmu_man_> --number-sections! 1 output chapter and sectioning numbers. [00:12:10] <jannau> doesn't look like it would: http://manpagez.com/man/1/texi2html/osx-10.3.php [00:21:41] <mmu_man_> sux [00:21:46] <mmu_man_> upgrade then :p [00:21:57] <mmu_man_> maybe we could fallback [00:22:10] <mmu_man_> texi2html ... -number || texi2html ... [03:15:25] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * re5262ec44a ffmpeg/libavcodec/dsputil.c: [03:15:26] <CIA-38> ffmpeg: Optimize C version of ff_emulated_edge_mc(). [03:15:26] <CIA-38> ffmpeg: From ~780 cycles to 551 cycles, mostly just by using libc memcpy() [03:15:26] <CIA-38> ffmpeg: instead of manually shuffling individual bytes around. [03:15:26] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r2e27959879 ffmpeg/libavcodec/ (15 files): Move ff_emulated_edge_mc() into DSPContext. [03:17:18] * Sean_McG cheers [07:36:43] <peloverde> How can SBR output scaling be correct after the latest changes to aacsbr? [07:38:05] <peloverde> (and yes the output appears correct) [07:43:03] <peloverde> Output scaling was completely removed [07:46:41] <peloverde> I guess nevermind, I think I misunderstood what we were doing with the C version [08:07:23] <peloverde> "Please note that many of the final equations presented by the paper are obviously incorrect but if you follow their work you should be able to arrive at the correct equations." [08:07:30] <peloverde> I leave the most useless notes for myself [08:09:00] <peloverde> I also completely failed to explain the mapping between the DCT-IV and the half IMDCT [08:19:08] <peloverde> at some point I should finish optimizing the SBR filterbank [08:20:58] <saintdev> thought you had given up? [08:22:53] <peloverde> i've been remotivated lately [08:24:21] <peloverde> There is a dropped minus sign on equation (76) [08:26:26] <peloverde> It is one of the only useful papers on doing SBR decoding quickly and the math is so sloppy :( [09:34:54] <lu_zero> good morning [09:35:10] <peloverde> greetings [09:58:50] <twnqx> we had the discussion about XXX+cue recently - is there actually a unix player that can handle those? at least wav+cue and flac+cue [10:00:53] <twnqx> *sigh* and preferably bin+cue [10:01:17] <Dark_Shikari> foobar2000 in wine? [10:01:30] <peloverde> how do we handle pre-roll and gapless type stuff in general? [10:01:31] <twnqx> ... i was kinda afraid i'd get this answer [10:01:49] <spaam> twnqx: xmms2 ? [10:02:28] <_av500_> urgh [10:02:40] <twnqx> peloverde: we lack, genrally speaking, metafile support - kinda like playlist, with both multiple tracks in one file, and multiple files as one track (e.g. .mkv with ordered chapters) [10:03:01] <twnqx> i always considered that a player thing though [10:03:12] <twnqx> spaam: will have a look. [10:03:36] <twnqx> foobar would have the advantage of playing ape+cue and tak+cue as well... [10:05:11] <_av500_> and cue+cue? [10:06:07] <Dark_Shikari> tta + cue is all that matters [10:08:56] <lu_zero> twnqx: it isn't a player thing anymore [10:09:00] <lu_zero> (sadly) [10:09:18] <lu_zero> most of the segmented types are now "network pseudostreams" [10:10:40] <wbs> lu_zero: except they're normally slightly different - the segmented streams still are the same data stream, just chopped up, while playlists easily can have data in different formats (needing close+reopen of codecs) [10:13:48] <_av500_> lu_zero: maybe its a libavplay thing? [10:14:49] <kshishkov> _av500_: if you mean common code from ffmpeg, ffplay and avcode then it's not there yet [10:14:56] <_av500_> http://www.flickr.com/photos/av500/5397821774/ [10:15:12] <_av500_> kshishkov: i know that [10:15:29] <_av500_> but i proposed it in the past [10:15:58] <elenril> twnqx: i think mpd can [10:16:30] <kshishkov> _av500_: WTF is that? [10:16:48] <_av500_> kshishkov: in the past news was printed... [10:17:07] <elenril> wtf [10:17:19] <elenril> looks shopped [10:17:24] <spaam> _av500_: why do you read past news? [10:17:33] <_av500_> it came today [10:17:35] <kshishkov> _av500_: yes, it looks like a photo of part of page from eine Zeitung but WTF with the content? [10:17:42] <_av500_> kshishkov: ?? [10:18:02] <elenril> lu_zero: did you see the playlists branch yesterday? [10:19:15] <kshishkov> _av500_: it doesn't look like what really happened [10:19:39] <_av500_> kshishkov: well [10:20:01] <_av500_> news is never about what REALLY happened [10:20:33] <elenril> but srsly, who writes dead-tree news about open source politics [10:20:40] <_av500_> and i dont think this is written too badly [10:21:17] <kshishkov> elenril: people with too little news to fill the page? [10:21:36] <_av500_> c't has one page dedicated to os news [10:21:58] <lu_zero> elenril: I fell asleep before... [10:22:48] <lu_zero> wbs: the segmented stuff might change in between [10:23:00] <lu_zero> (e.g. bandwidth adaptation) [10:23:09] <wbs> lu_zero: ah, yes [10:23:36] <elenril> in any case, our playlist api should be able to handle both [10:24:02] <lu_zero> and it's lovely how they mess up even the normal stuff [10:24:47] <wbs> elenril: otoh, segmented streaming playlists have a bit of other peculiarities (such as re-polling a sliding window playlist) [10:26:16] <wbs> and for some cases, regarding them as a pure playlist and playing each item in order doesn't yield the correct result - in some cases, the ts segment files are split in "bad" places, so that you get broken packets at the end of segments, but the correct result if you concatenate the segment files [10:26:49] <lu_zero> wbs: that is a segmenter bug IMHO [10:27:15] <lu_zero> and that reminds me that somebody asked me about that [10:28:30] <wbs> lu_zero: perhaps it can be considered a segmenter bug yes, but regardless, there are such streams out there, that our current code doesn't play back well, while (afaik) iOS plays them just fine [10:28:55] <wbs> my initial approach with an urlprotocol that feeds the data as one single long stream to the demuxer handles it fine though [10:29:29] <lu_zero> indeed [10:30:00] <lu_zero> and I think the mpegts demuxer can handle changes [10:31:17] <wbs> yes, but the issue is when one segment returns EOF, and the mpegts demuxer returns an incomplete (broken?) packet from the data available, then we switch the underlying ByteIOContext to the next segment and continue reading [10:31:40] <wbs> then we don't get the same output packets as if the segments had been one single stream and no EOF had been returned inbetween [10:32:06] <lu_zero> agreed, I was thinking about the other scenario [10:32:14] <bcoudu> playlist branch ? where can I see that ? [10:32:41] <lu_zero> so you glue as a single stream [10:32:53] <wbs> ah, yes [10:32:57] <wbs> yes, that might work just fine [10:33:03] <lu_zero> what isn't originally a single stream [10:33:05] <lu_zero> ^^; [10:33:07] <twnqx> _av500_: c't? [10:33:22] <wbs> the only issue with that is you can't receive two different bitrate variants at once, which the current approach allows [10:35:51] <twnqx> ah, you said it earlier [10:36:05] <bcoudu> ? [10:38:25] <peloverde> twnqx: so we don't have any infrastructure to support gapless audio? [10:39:32] <twnqx> at the very least we don't have .cue support - or i'm not aware of it. [10:39:57] <twnqx> also it would be a matter of seeking API if someone wants single tracks [10:40:22] <twnqx> with higher precison than "codec frame" [10:40:33] <peloverde> that is my big problem [10:40:47] <bcoudu> so guys, where can I see the playlist branch ? [10:40:48] <peloverde> I want to give AAC sample accurate cutting [10:46:14] <bcoudu> elenril ? [10:46:27] <lu_zero> bcoudu: on his github [10:46:31] <lu_zero> let me dig [10:47:07] <lu_zero> git://git.khirnov.net/git/ffmpeg [10:47:09] <lu_zero> pardon [10:47:26] <bcoudu> great, thanks [10:47:26] <elenril> yeah [10:47:40] <elenril> bcoudu: but it's just the latest soc patch rebased against current master [10:48:02] <bcoudu> ah [10:48:10] <lu_zero> elenril: could you send an email about that btw? [10:48:20] <bcoudu> I think wbs approach is a nice one [10:48:29] <bcoudu> (urlprotocol) [10:49:04] <bcoudu> do you have an idea about where the bitrate switching will occur ? [10:49:44] <lu_zero> bcoudu: we have different strategies [10:50:02] <lu_zero> in one the switch should be a client side decision [10:50:17] <lu_zero> in any case it happens on a segment boundary [10:51:25] <bcoudu> having both would be nice [10:51:29] <bcoudu> user + auto [10:57:07] <wbs> hmmm, interesting git weirdness. I've got one branch named "symbian" - if I do "git checkout -b symbian-gcce4" in order to create a new branch named that, git refuses, saying there's already a branch with that name [10:57:39] <wbs> this seems to be due to the way parsing of git describe style names work [10:58:01] <wbs> since it interprets it as <branch>-g<hash>, so it looks for the commit with the hash starting with "cce4" on the branch "symbian" [10:58:39] <wbs> if I explicitly create the branch with "git branch symbian-gcce4" it works fine though [11:10:54] <lu_zero> and then you can checkout properly? [11:12:02] <wbs> yes [11:16:42] <lu_zero> really strange [11:17:38] <wbs> checkout -b probably uses a different version for checking whether the given names matches anything in the repo already than what branch uses [11:20:50] <lu_zero> yes [11:55:26] <superdump> Dark_Shikari: ping? [12:01:56] <superdump> Dark_Shikari: never mind, i located the channel mixing patches from here: http://muzso.hu/2009/02/25/downsampling-multichannel-audio-5.1-into-stereo-… [12:03:32] <lu_zero> superdump: are you willing to repubblish them? [12:04:01] <superdump> i'm going to have a look at them to see what's what [12:04:18] <superdump> N channel resampling and M->N channel mixing really shouldn't be that difficult [12:05:12] * Kovensky is also interested in that [12:05:42] <jannau> I think the plan in regard to resampling and remixing was to wait for lavfi audio support [12:06:11] <Kovensky> lavfi still doesn't do audio? [12:06:25] <jannau> or at least move it out of libavcodec [12:06:47] <jannau> which current flavour is lavfi audio [12:06:54] <wbs> I at least see it as two different, orthogonal issues - having a function for doing that, in lavc or lavcore, that can be used easily whereever would be one step, then wrapping it up in filters for use in libavfilter filter chains is another issue [12:07:08] <Kovensky> I wrote an audio filtering system for x264 as part of gsoc, maybe it can be used if it is correct [12:07:14] <wbs> (I wouldn't want to have to use a full lavfi filter chain just to be able to downmix) [12:07:25] <saste> wbs: +1 [12:07:47] <saste> there was the idea of having a separate lib lavresample [12:07:59] <saste> in the meaningwhile the code can stay in lavc and be moved later [12:08:42] <bcoudu> lavfi audio must be used [12:08:49] <Kovensky> Receiving objects: 1% (2324/137093), 604.00 KiB | 3 KiB/s <-- this will take a while =p [12:08:49] <bcoudu> and the dumb interface dropped [12:09:17] <Kovensky> IMO any simple interface should be a wrapper around lavfi [12:09:20] <bcoudu> now a quick solution can definitely be added the dumb interface [12:09:48] <superdump> is libavfi audio functional? [12:09:57] <superdump> if not, what is needed for it to be so? [12:10:08] <bcoudu> interface is in already [12:10:11] <saste> the patches I posted work mostly [12:10:25] <saste> there is also a design problem to be fixed with av_samples_* [12:10:38] <saste> see the recent thread and the reply from Michael [12:10:47] * Kovensky had to rewrite his system thrice due to design problems [12:10:58] <saste> once I'll get ffplay lavfi audio support I'll add support to ffmpeg [12:11:04] <saste> togheter with a test system [12:11:23] <saste> hels is welcome of course [12:11:31] <saste> so feel free to pick my patches and work on them [12:12:04] <Kovensky> I don't have much time atm, and I don't know anything about ffmpeg's codebase :( [12:15:23] <bcoudu> also the patch in question, assumes a channel order [12:15:30] <bcoudu> which will be wrong either for aac or for ac3 [12:15:55] <superdump> it should use the waveformatex channel order, no? [12:16:01] <superdump> in combination with the layout [12:16:12] <bcoudu> it should use whatever is stored in the codec first, then the container [12:16:15] <superdump> saste: where are your patches? [12:16:29] <saste> superdump: on the ML [12:16:38] <saste> check for av_samples_ [12:16:42] <superdump> ok, thanks [12:16:46] <saste> aconvert [12:16:55] <saste> and lavfi ffplay audio support [12:20:57] <lu_zero> saste: your patches are about 8 channels [12:21:05] <lu_zero> iirc [12:21:18] <saste> lu_zero: yes [12:24:01] <lu_zero> so to handle more-than-8 you just do a staged downmix [12:41:09] <{V}> mmu, Janne has an alternative patch for the texi2html issue, it removes the 'number' option, but wasn't tested in texi2html 5. Perhaps you'd care to test it [12:42:12] <jannau> {V}: thanks [12:42:30] <jannau> saste: can you check with 1.82 [12:43:32] <bcoudu> mkv is really crap with timestamps [12:43:57] <bcoudu> it's great to claim to support nanosecond precision but if no implementation use it ... [12:44:15] <mmu_man> {V}: sorting 90mails atm [12:46:48] <spaam> bcoudu: do you really need nanosecond precision? [12:46:50] <ohsix> bcoudu: it's future proof! it's ready for that day when theres 1ns wakeups [12:47:46] <Tjoppen> spaam: ts does [12:48:33] <spaam> Tjoppen: ok [12:48:45] <superdump> i will have a look at the mixing stuff when i can [12:48:51] * Kovensky goes read more fflames in the ml [12:48:53] <superdump> have a good day [12:49:35] <Kovensky> 09:16.12 bcoudu: it should use whatever is stored in the codec first, then the container <-- isn't ffmpeg supposed to always convert channel order to waveformatex so code outside decoders doesn't need to special case everything? [12:50:59] <Kovensky> 09:43.57 bcoudu: it's great to claim to support nanosecond precision but if no implementation use it ... <-- it is mostly untested, but ffms2 with the haali demuxer for example support it [12:51:03] <Kovensky> or at least I saw some commits from Plorkyeran fixing things related to timebases different from 1/1000 [12:51:30] <{V}> Kovensky, re:fflames. You mean the Donations thread? it seems to be going in a non-flaming direction. :) [12:51:44] <bcoudu> spaam, no [12:51:49] <bcoudu> but you need accurate timestamsp [12:52:05] <bcoudu> and ms sucks [12:52:28] <bcoudu> containers should use 1/sample_rate for audio [12:52:39] <bcoudu> 1/frame_rate for video cfr [12:52:51] <bcoudu> and for vfr, well arbitrary big value [12:54:09] <bcoudu> pcr is 27mhz in ts [12:54:15] <bcoudu> but timestamps are 1/90000 [12:54:39] <Kovensky> {V}: there are other threads I haven't caught up with yet :) [12:55:19] <bcoudu> Kovensky, I'm not sure about the channel order all decoders output [12:55:26] <{V}> Kovensky, oh okay. Well if you get tired of flames and dev talk, check the latest mails in the Donations thread :p [12:55:26] <bcoudu> maybe you are right [12:56:05] <bcoudu> Kovensky, it's not about the mkv demuxer [12:56:09] <bcoudu> it's about the muxer [12:56:19] <bcoudu> if the muxer choose 1/1000, you are fucked up [12:56:30] <bcoudu> mov can fuck up like this as well [12:56:33] <Kovensky> mkvmerge uses 1/1000 by default but you can specify an arbitrary time base [12:56:37] <Kovensky> I don't know if this is well tested though [12:56:37] <bcoudu> like FCP who likes to use 1/2997 [12:56:53] <bcoudu> because 1/30000 does not allow as much duration [12:57:14] <bcoudu> on an uin32_t that is [12:57:24] <Kovensky> lol [12:57:41] <Kovensky> can matroska timebase numerators be arbitrary numbers btw? having a 1001/30000 timebase would be even more accurate =p [12:58:40] <kierank> I wonder why ffmpeg doesn't have a sup demuxer [13:00:26] <_av500_> sup? [13:00:58] <kierank> a subtitle file format [13:01:15] <Tjoppen> patch welcome? [13:01:16] <kierank> for dvds and blu-ray [13:01:18] <kierank> yeah [13:01:23] <Kovensky> isn't that one also used on BDs? [13:01:29] <Kovensky> efb [13:01:33] <kierank> yeah, it's just a generic bitmap container [13:01:40] <kierank> a little header with a pts at the front [13:01:46] <Tjoppen> speaking of subtitles, I should probably take another shot at fixing dvbsub remuxing [13:01:59] <bcoudu> dvbsub :) [13:02:15] * Kovensky wonders when will the aurelsubs issue be fixed [13:02:23] <Tjoppen> lavc is.. interesting in that regard. the decoder and encoder don't agree on the bitstream [13:02:37] <bcoudu> make it consistent, please [13:02:42] <Tjoppen> hence the demuxer/muxer don't as well, needlessly requiring a parser [13:02:52] <bcoudu> btw, I had another look at your patch the other day for pcr only packets [13:03:20] <kierank> i wonder why the vob demuxer doesn't pick up all the subtitle streams [13:03:20] <bcoudu> and I didn't remember exactly what was the concern about the overhead [13:03:33] <bcoudu> kierank, > 20 streams ? [13:03:37] <kierank> no [13:03:45] <Tjoppen> well, it does add a bit more overhead in rare cases. hm, let's see if I can remember [13:03:50] * Kovensky wonders why is there a hardcoded limit in the number of streams [13:04:15] <Tjoppen> but: I have an updated patch that I should send to the ml. still far from optimal and doesn't support < 10 fps but still [13:04:27] <bcoudu> Kovensky, legacy, it will be removed with the next major bump [13:04:30] <{V}> kierank, there was a patch+thread about blu-ray subtitle support on ffmpeg-devil in 2009 [13:04:38] <{V}> oops devel [13:04:47] <bcoudu> -devil :> [13:04:52] <kierank> we have blu-ray subtitle support, no? [13:04:53] <Tjoppen> without rewriting half the muxer it'll be hard to get proper output. at least a QAM takes it [13:05:07] <Tjoppen> or so someone in libav-user claimed [13:05:09] <bcoudu> yes, pgs [13:05:43] <kierank> Tjoppen: sounds about right [13:05:46] <bcoudu> oh yes the muxer would love a rewrite [13:06:11] <bcoudu> it has only be tweaked to just enough for some usage [13:06:49] <Tjoppen> yeah.. well, I'll see if I can get my laptop hooked up somewhere so that at least the pcr period problem can be resolved [13:07:04] <Tjoppen> since my code and mail is on there [13:07:40] <Tjoppen> atm I'm busy with more horrible things, such as trying to get opatom muxing and aaf files that avid will take :\ [13:08:17] <bcoudu> opatom for work ? [13:08:31] <bcoudu> standard opatom or avid crap ? [13:08:59] <Tjoppen> both. but the avid opatom isn't too bad - at least it's (mostly) s390m compliant [13:09:21] <Tjoppen> it's just the retardedness of having to use the same material package for all opatoms that i [13:09:24] <kierank> If I find a student to fix the ts muxer for gsoc '11, I'm going to make the qualification task involve writing an explanation of T-STD [13:09:26] <Tjoppen> is.. interesting [13:10:04] <Tjoppen> one things is quite interesting though: the avid people spotted and "fixed" a but on s390m [13:10:27] <Tjoppen> namely that VFR essence > 5 minutes or so can't be held in opatom [13:10:42] <Tjoppen> since the index can't be larger than 64k and each entry is 11 bytes [13:11:02] <bcoudu> kierank, lol [13:11:07] <bcoudu> that's actually a good idea [13:11:09] <Tjoppen> so they go "length = 0xFFFF" and have that mean "the index is the size of the rest of the klv packet" [13:11:46] <Tjoppen> s/but on/bug in/ [13:11:58] <bcoudu> index can be larger [13:12:02] <bcoudu> you just have to split it [13:12:05] <Tjoppen> not for a single essence container [13:12:08] <Tjoppen> and opatom only allows one [13:12:15] <Tjoppen> or? [13:12:21] <bcoudu> where is that written ? [13:12:36] <Tjoppen> s390m, page two or three [13:12:38] <bcoudu> xdcam op1a only uses sprinkled index tables [13:12:48] <bcoudu> oh ok [13:12:50] <Tjoppen> also, the index can't be sparse [13:13:06] <bcoudu> then yes they fucked up in s390m [13:13:09] <Tjoppen> so yeah.. a bug in the spec AFAICT [13:13:59] <Tjoppen> if only they'd used BER lengths in local sets or something.. [13:14:36] <bcoudu> indeed [13:15:12] <Tjoppen> btw, those opatom patches on the ml are insufficient for an opatom that has the index only in the footer [13:15:46] <Tjoppen> since it stops on the essence container [13:15:53] <Tjoppen> the header parsing that is [13:16:00] <bcoudu> yes [13:16:18] <bcoudu> I don't like this patch ... [13:16:27] <bcoudu> especially the one adding zillions of ULs [13:16:34] <Tjoppen> I haxed my local tree a bit, but the demuxer needs to be aware of partitions (among other things) [13:16:55] <Tjoppen> yeah, that's why I posted my simplified patch [13:17:09] <bcoudu> and if you seek [13:17:16] <bcoudu> it won't work and fuck the demuxer I think [13:17:44] <Tjoppen> well, the seeking it does is already quite dubious though :) [13:18:06] <bcoudu> it's inacurate for vbr [13:18:10] <bcoudu> but most mxf are cbr anyway [13:18:22] <Tjoppen> it doesn't account for the header [13:18:29] <bcoudu> ok ok :> [13:18:32] <Tjoppen> and the header can be quite large [13:18:47] <bcoudu> but it allows seeking in _all_ mxfs [13:18:49] <Tjoppen> say you have some dms-1 metadata and a huge index there :) [13:18:56] <bcoudu> op1a [13:19:05] <Tjoppen> unless they're clip wrapped [13:19:12] <bcoudu> op1a is frame wrapped [13:19:26] <Tjoppen> always? hm, must've missed that [13:19:29] <bcoudu> clip has to use op1b [13:20:33] <Tjoppen> anyway, I'll have to add seeking support for clip wrapped at work the next week or so. hopefully I can get it to use an index properly [13:21:21] <bcoudu> single essence container [13:21:41] <bcoudu> and only one type [13:21:46] <mmu_man> jannau: hmm can't copy-paste your patch, either my MUA or yours inserted line breaks [13:22:09] * Kovensky pats saste [13:22:24] <Kovensky> (for learning the meaning of "mud slinging" from fflames) [13:22:33] <mmu_man> jannau: ah worked now [13:22:40] <bcoudu> for clip wrap with 2 tracks you need at least 2 essence containers [13:22:41] <mmu_man> seems Mail.app has yet another bug [13:22:43] <bcoudu> IIRC [13:22:50] <Tjoppen> of course [13:22:59] * Kovensky uses Sparrow.app [13:23:00] <bcoudu> so that is not compatible with op1a [13:23:12] <bcoudu> you can have clip wrap op1a, but only one track [13:23:13] <Kovensky> the way it threads is annoying though; it feels like reading top posts ;_; [13:23:25] <Tjoppen> I was thinking a but of multi-track clip wrap demuxing. it'll have to seek like crazy [13:23:29] <Kovensky> I should complain at them since while it tries to be close to gmail it shows threads in the opposite sort order [13:23:44] <bcoudu> yes [13:23:45] <bcoudu> op1b [13:23:55] <bcoudu> this is crazy btw [13:24:27] <Tjoppen> of course - it's mxf [13:24:41] <saste> jannau: nice job, works fine here with texi2html 1.82 [13:25:13] <Tjoppen> although, to be fair, they have put some thought into handling tape stuff. like where indexes can go and how to seek fast to cetain portions of the file [13:25:50] <Tjoppen> but opatom still only requires an index in the footer, and closed header, so it can't be read from tape [13:26:10] <Tjoppen> nor written to tape, unless you know the length on advance [13:26:21] <bcoudu> ditch tapes [13:26:38] <Tjoppen> s/tape/pipe then. but yeah [13:27:30] <Tjoppen> I'm off [13:27:40] <bcoudu> you can write a closed header at first I think [13:27:47] <bcoudu> you just have to use the default values [13:27:56] <bcoudu> you'll update them in the footer [13:29:16] <bcoudu> anyway I'm off too, sleeping [13:29:29] <Tjoppen> can't have metadata in the footer in opatom [13:33:39] <Kovensky> 10:04.30 {V}: kierank, there was a patch+thread about blu-ray subtitle support on ffmpeg-devil in 2009 <-- freudian (kinda) slip? :) [13:34:09] * {V} refuses to self-diagnose :p [13:36:46] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r0745116c10 ffmpeg/libavcodec/arm/asm-offsets.h: ARM: update MpegEncContext offsets [13:39:33] <uau> Kovensky: all Matroska time arithmetic is basically in nanoseconds [13:40:12] <uau> it has the TimecodeScale element, which means that various other timestamps numbers will be multiplied by the given value [13:41:35] <Kovensky> I see, so you can only touch the denum [13:42:23] <lu_zero> saste: he use of reordered_opaque in the movie filter is on purpose? [13:43:43] <uau> it's typical for files to specify a TimecodeScale of 1000000, which means timestamps will be in units of 1 ms (1e6 ns) [13:48:52] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * rce20edb7bd ffmpeg/libavformat/oggparsevorbis.c: [13:48:52] <CIA-38> ffmpeg: Vorbis-in-Ogg: Do not set timebase to invalid values [13:48:52] <CIA-38> ffmpeg: Avoids an assert when the sample rate is invalid and the timebase [13:48:52] <CIA-38> ffmpeg: is thus set to e.g. 1/0. [13:48:52] <CIA-38> ffmpeg: Sample file is http://samples.mplayerhq.hu/ogg/fuzzed-srate-crash.ogg [13:48:53] <CIA-38> ffmpeg: This is a quick fix for a crash, not a final solution. [13:48:54] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:57:29] * mru curses flexlm [13:58:34] <kshishkov> what's that and how it's related to gcc? [13:58:36] <Kovensky> 10:42.24 lu_zero: saste: he use of reordered_opaque in the movie filter is on purpose? <-- wasn't it recently deprecated? [13:59:03] <Kovensky> 10:43.43 uau: it's typical for files to specify a TimecodeScale of 1000000, which means timestamps will be in units of 1 ms (1e6 ns) <-- because that happens to be mkvmerge's default [13:59:24] <mru> kshishkov: flexlm is a stupid licence manager used by a lot of commercial software [13:59:57] <kshishkov> mru: then cursing it does no good - it's like trying to curse demons [14:00:55] <jannau> kshishkov: I suppose they use it for their non-demo versions too [14:04:45] <jannau> kshishkov, lu_zero: I suppose it's for backwards compatibility. deprecating something doesn't magically make it unused in 3rd party code [14:04:48] <mru> the version of it armcc uses is buggy and once in a while insists that the system clock has been tampered with [14:07:49] <kshishkov> have you tried reporting that bug? [14:13:07] <mmu_man> jannau: seems to work fine [14:14:08] <jannau> mmu_man: the output looks like http://ffmpeg.org/ffmpeg.html ? [14:15:14] <mmu_man> at least it builds [14:16:01] <mmu_man> almost like [14:16:07] <mmu_man> with some navigational arrows [14:16:26] <jannau> argh [14:16:38] <mmu_man> http://revolf.free.fr/ffmpeg.html [14:16:50] <mmu_man> it does have the summary [14:17:15] * jannau downloads texi2html 5.0 [14:17:44] <jannau> we don't want the navigation [14:17:49] <jannau> mmu_man: thanks [14:18:04] <mru> wow, what a slab of nothing at the top [14:18:35] <mru> is that the (even more) minimalist version of the wordpress default theme? [14:19:50] <jannau> I think that is actually a bug fix, our texi files have @sp around the title which seems to be ignored with older versions [14:20:08] <mru> it's ugly whatever the cause [14:21:20] <jannau> wtf texi2html source tarball is 15M bz2-ipped [14:22:02] <jannau> 1.78 was 443k [14:22:08] <mru> hmm [14:24:20] <mmu_man> maybe there is a photo of the author in 5000x5000 ? :p [14:24:32] <mru> uncompressed tiff [14:25:11] <kshishkov> or a collection of selected Stallman speeches [14:25:16] <kshishkov> in ASCII [14:26:02] <mmu> lokl [14:26:08] <pengvado> ginormous regression tests [14:29:30] <jannau> pengvado is correct, it has extracted a 147M large test directory [14:32:17] <{V}> probably a trend that started around version 1.8. Its tar.gz is 7M [14:32:50] <mru> do you see the word enterprise mentioned anywhere? [14:33:49] <kshishkov> that sould be redundant [14:34:08] <jannau> no, but it looks like it will become gnu software [14:34:23] <jannau> so braindamage is to be expected [14:38:44] * kshishkov likes the first three lines in http://svn.xiph.org/trunk/planarity/Makefile [14:40:01] <mru> :) [14:40:26] <kshishkov> mru: see, even they can write partially good makefiles [14:40:47] <mru> recursive... [14:42:46] <mmu> fuck automake \o/ [14:42:57] <mmu> autofools burn in hell [14:47:16] <spaam> kshishkov mru mmu : http://fosdem.org/2011/schedule/event/autotools something for you guys ;D [14:47:52] <kshishkov> nothing for me [14:48:09] <spaam> maybe for DonDiego ? :) [14:50:12] <mmu_man> empty page here [14:50:46] <mmu_man> seems they screwed up at #fosdem [14:50:57] <{V}> here too. The main page works, but as soon as you try to access the schedule. blank. [14:51:14] <{V}> just search DonDiego for weapons before he's allowed in the room. Murder charge for FFmpeg dev would not be good publicity. :p [14:52:26] <lu_zero> autotools aren't as bad as their common usage make you think [14:52:53] <kshishkov> what? are they even worse? [14:53:01] <lu_zero> kshishkov: nope =P [14:53:28] <mmu_man> ah works now [14:53:36] <kshishkov> lu_zero: and checking for Fortran compiler is not mandatory? [14:54:39] * {V} is suddenly curious about which build system autotools use :) [14:55:26] <lu_zero> kshishkov: it is not mandatory... [14:55:53] <lu_zero> as checking for C++ [14:56:06] <lu_zero> or default C99 headers one by one [15:07:05] <Kovensky> 11:53.36 kshishkov: lu_zero: and checking for Fortran compiler is not mandatory? <-- that was an ancient automake bug that was fixed over a year ago [15:07:39] <kshishkov> that shows how much they cared about their product [15:09:13] <Kovensky> most of the time I spend when building a new toolchain is on workarounding custom build systems or libtool; only once in a while I need to mess with autoconf/make [15:09:52] <lu_zero> kshishkov: the main problem with autotools are their users [15:10:01] <lu_zero> and the anti-documentation [15:10:39] <lu_zero> you'd notice that the oh-so-praised cmake is getting the same usage faults [15:11:00] <lu_zero> (not to mention it's share of upstream-provided faults) [15:11:21] <Kovensky> the only thing I like about cmake is the `make` output format [15:11:38] <Kovensky> to this day I still have not figured out how to enable/disable features on a cmake-based build without resorting to the GUI [15:11:58] <Kovensky> and their CMakeLists syntax is terrible ;_; [15:12:15] <ohsix> theres an ncurses thing to poke at it [15:12:21] <ohsix> it's all terrible [15:13:03] <Kovensky> 12:12.15 ohsix: theres an ncurses thing to poke at it <-- which is a GUI, just no clicky [15:13:53] <ohsix> clicks work w/ncurses here ;D [15:25:19] <lu_zero> still the point remains... [15:28:02] <Kovensky> you also have to hope the script supports optional stuff [15:28:13] <Kovensky> it's not almost straightforward like on autoconf [15:28:54] <Kovensky> I have tried maintaining a cmake build system for ffmpegsource, ended giving up and switching to autotools ._. [15:28:55] <mru> build systems shouldn't need a gui [15:29:17] <mru> the kernel menuconfig is another matter [15:29:20] <Kovensky> autotools-based systems are AFAIK the only ones that are simple to cross compile [15:29:32] <mru> that's a gui for configuring the build, not for configuring the build system [15:29:45] <mru> Kovensky: you're forgetting the ffmpeg one [15:29:47] <Kovensky> just give a --host=<target triplet> and a script with decentish tests will work without any further tweaking [15:30:20] <Kovensky> mru: I don't count the ffmpeg one due to how you use pkgconfig [15:30:21] <mru> unless libtool decides to put -L/usr/lib in every link command [15:30:31] <mru> Kovensky: you mean not using it? [15:30:54] <Kovensky> no, I mean having "pkg-config" hardcoded in the script with no means to change other than manual patching [15:31:00] <Sean_McG> /usr/lib is typically a default search path for gcc, no? [15:31:07] <Kovensky> Sean_McG: not if you have a cross-compiler [15:31:10] <mru> Sean_McG: not when cross-compiling [15:31:14] <Sean_McG> ah [15:31:47] <Kovensky> it however is a default search path for pkg-config, and it will find packages on /usr/lib unless you either mess with the PKG_CONFIG_PATH envvar (NOT safe, for it will fallback to the default path if the package it looks for isn't on PKG_CONFIG_PATH), or to have a pkg-config build with a different builtin search path [15:32:34] <Kovensky> pkg-config however does not use autoconf properly and doesn't respect --sysroot, you need to use its own custom flag and need to give the target triplet prefix to the exe "manually" with another custom flag, but if you make such a pkg-config it works without issues as long as you prefix it with the triplet [15:33:18] <mru> sound to me like the problem is pkgconfig [15:33:20] <Kovensky> which is how you get -L/usr/lib in your cross compiles [15:33:27] <mru> especially since it doesn't actually solve any problem [15:33:33] <mru> Kovensky: that's one way to get -L/usr/lib [15:33:45] <mru> sometimes libtool decides to hardcode it into every link command [15:34:13] <mru> the only workaround is patching the libtool.sh included in the package [15:34:15] <ohsix> oh, that old saw [15:34:47] <Kovensky> 12:33.27 mru: especially since it doesn't actually solve any problem <-- yes it does; it makes it trivial for you to get CFLAGS, LDFLAGS and LIBS (even though it does it wrong and just returns LIBS, and autotools' pkgconfig wrapper calls LIBS "LDFLAGS" but you have to assign to LIBS) without needing custom code for each package you want to test / having each package have to roll their own $package-config script [15:35:17] <mru> properly written libs don't need any flags [15:35:20] <mru> other than -lname [15:35:29] <Kovensky> unless it isn't a shared library [15:35:37] <mru> there are better ways to fix that [15:35:52] <lu_zero> btw pkgconfig had been fixed properly with the current version... [15:35:58] <ohsix> you need to put all the dependent libs in there to aboid the overlinking stuff [15:36:04] <Kovensky> lu_zero: as in it respects --target and --sysroot? [15:36:14] <mru> with gnu ld one way is to make libfoo.a not an actual archive but a linker script pointing to all the required bits [15:36:27] <Kovensky> mru: keyword "gnu ld" [15:36:49] <mru> most pkgconfig scripts return gnu-only flags anyway [15:36:49] <Kovensky> non-GNU-based systems obviously won't have gnu ld, or if they have they won't for long since everyone else is betting on clang [15:36:51] <mru> so there's no difference [15:36:52] <kshishkov> why that reminds me of libtool? [15:37:14] <Kovensky> and as kshishkov says, it is awfully reminiscent of .la files if you do it like that [15:37:16] <mru> I'm just saying a solution already exists [15:37:26] <mru> it could be promoted as the preferred way [15:37:51] <mru> Kovensky: except it doesn't need a separate hell-script to parse them [15:38:17] <mru> a nicer solution would be put a special file in the .a listing the dependencies [15:38:21] <ohsix> distros have started running with gold [15:38:25] <mru> and encourage linkers to look at that [15:38:29] <Kovensky> I just think we should try and use the current widespread solution "properly", even if imperfect, and push for something better on appropriate discussion places other than code [15:38:32] <mru> similar to the DT_NEEDED entries in elf files [15:38:53] <twnqx> with higher precison than "codec frame" [15:38:59] <twnqx> argh, wrong window [15:39:12] * Kovensky resamples twnqx [15:39:31] * twnqx compresses Kovensky lossy [15:39:40] <Kovensky> what bitrate? [15:39:48] <twnqx> mh [15:39:55] <twnqx> 16kbit? [15:40:05] <Kovensky> hm, still enough for IRC [15:40:16] <Kovensky> your lossy codec does have PCM blocks doesn't it? [15:40:19] <CIA-38> ffmpeg: Vitor Sessak <vitor1001(a)gmail.com> master * r3af1fe829e ffmpeg/libavcodec/ppc/dsputil_altivec.c: [15:40:19] <CIA-38> ffmpeg: Fix overread in altivec DSP function sad16 [15:40:19] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:08:53] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * ra8f0814a74 ffmpeg/ (10 files in 2 dirs): (log message trimmed) [16:08:53] <CIA-38> ffmpeg: doc: modify style for texi2html 1.78+ [16:08:53] <CIA-38> ffmpeg: The generated HTML files are similar to the ones generated with [16:08:53] <CIA-38> ffmpeg: texi2html 1.56k used on the website. [16:08:53] <CIA-38> ffmpeg: Tested with texi2html 1.78 and 5.0. 1.78 is the minimal recommended [16:08:54] <CIA-38> ffmpeg: version. [16:08:55] <CIA-38> ffmpeg: The removed @sp from the titlepage section were ignored until [16:48:52] <uau> speaking of pkg-config, i needed to do some fixes to the generated .pc files for the mplayer-build repo [16:48:59] <uau> those should probably be applied to upstream ffmpeg [16:49:18] <mru> send a patch [16:49:51] <lu_zero> the mplayer-build repo would use something like an uninstalled variant isn't it? [16:50:14] <uau> http://repo.or.cz/w/FFMpeg-mirror/mplayer-patches.git/commitdiff/65e612b594… <- those are current differents, the configure ones are relevant to upstream [16:50:31] <uau> lu_zero: it does an install to an internal dir [16:50:59] <uau> the configure changes remaining in the current dir are changing optimization level from -O3 to -O2 [16:51:40] <mru> why do you make that change? [16:51:46] <mru> not that I'm necessarily against it [16:51:46] <uau> and the pkg-config fixes (basically adding missing dependencies - libm for a couple of cases, and a libavutil dependency for libpostproc) [16:52:01] <uau> -O2 was consistently faster than -O3 on new gcc versions in my tests [16:52:30] <uau> IIRC (though it's been a while) the main reason was that -O3 enabled various vectorization code [16:52:32] <mru> which gcc version? [16:52:47] <mru> we disable the vectorization separately [16:52:48] <uau> i think i tested with early 4.4 back then, not 100% sure [16:52:52] <mru> 4.4 is terrible [16:53:03] <mru> 4.5 should be much better [16:53:09] <mru> 4.3 too [16:55:12] <mru> uau: what's with the depflags changes? [16:56:20] <uau> hmm yes there was that one too, basically it's adding -MP to make rebuild failures less likely [16:56:32] <mru> isn't that already fixed? [16:57:21] <uau> is it? i haven't checked whether there have been changes - is there something in the upstream version which would prevent make failures due to missing dependencies now? [16:57:35] <mru> yes [16:58:51] <mru> http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=11d788cadef7454bdb1ff43d… [16:59:08] <mru> that has the advantage of working with all compilers [16:59:49] <uau> ok [17:09:00] <uau> mru: i tested compiling mplayer-build with -O3 instead of -O2 (gcc 4.4.5 from current debian unstable), it made the binary 1.3 MB bigger and 2% slower in a h264 test [17:09:26] <uau> build time is also slower [17:09:29] <mru> as I said, 4.4 sucks [17:09:46] <mru> if you have time, please try 4.5 as well [17:09:58] <mru> we might want to make that flag version-dependent [17:10:02] <Sean_McG> aye, do yourself a favour and build yourself a copy of 4.5.2 if there aren't any debs available for it [17:10:20] <lu_zero> uau gcc-4.5.2 is somehow nicer (and got a plethora of fixes from 4.5.0) [17:10:39] <Sean_McG> yeah, I helped fix up some of the Solaris bugs with 4.5.2 ^^; [17:10:49] <Sean_McG> errr 4.5.1 that made it in to .2 [17:11:07] <uau> i'll test with debian's gcc 4.5.2 [17:11:25] <mru> thanks [17:11:35] <Sean_McG> 4.6.0 will probably be even nicer, once we get rid of all these P1 & P2 bug reports [17:12:00] <mru> Sean_McG: any idea about the fate failures with 4.6? [17:12:16] <mru> the dct test is most curious [17:12:26] <mru> half the output values have the wrong sign [17:12:33] <Sean_McG> mru: I haven't tried it... but I'd be glad to help [17:13:02] <lu_zero> Sean_McG: btw they backed from the gcc-4.6-all-c++ idea? [17:13:16] <mru> some of the failures might be ffmpeg bugs of course [17:13:26] <mru> if gcc got more aggressive with aliasing or something [17:13:30] <Sean_McG> lu_zero: I think someone realized it was more work that it was worth [17:13:45] <Sean_McG> lu_zero: and there are a number of dup bugzilla reports saying "c++ sucks, fix it" [17:16:06] <mru> and here I was hoping they'd spend the next release cycle converting all code to c++, giving clang et al time to catch up [17:16:22] <lu_zero> they might spend 1/2 the time to rationalize better the ancient bits they would had touched w/out changing it [17:16:24] <uau> not much difference between the gcc versions at -O3 [17:16:36] <uau> same speed, 441 kB smaller binary for 4.5 [17:16:52] <mru> on arm 4.4 is 25% worse than 4.3 or 4.5 [17:16:55] <Sean_McG> binary size improvement is nice [17:18:37] <Sean_McG> mru: yeah I'm just thinking...you could be right about aliasing in 4.6, but do any of the fate.ffmpeg.org machines use 4.6? [17:18:56] <mru> the ones that say so [17:19:19] <mru> click the compiler heading to sort by compiler [17:19:23] <Sean_McG> ah, right [17:21:31] <uau> with -O2 gcc 4.5 is 139 kB smaller binary but 1% slower than 4.4 (i think "random" variation in compile results is at least 1% for that test though) [17:21:39] <uau> still faster than -O3 [17:22:25] <Sean_McG> OK well I'mma go have late breakfast [17:22:26] <mru> how much difference between -O2 and -O3? [17:22:40] <Sean_McG> best of luck folks... I'll poke at this stuff late [17:22:45] <Sean_McG> s/late/later/ [17:22:51] <uau> mru; about 1% [17:23:43] <uau> gcc 4.4 -O2 - - 1% -- gcc 4.5 -O2 - - 1% -- either -O3 [17:25:20] <lu_zero> uau: using -Os ? [17:25:39] <uau> guess i could test that too [17:28:02] <uau> with gcc 4.5 that dropped binary size from 10.5 to 9.7 MB, but it's clearly slower [17:28:13] <lu_zero> (sorry to making you do another run) [17:28:36] <ubitux> http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/07… [17:28:41] <mru> how are you measuring the speed btw? [17:28:48] <ubitux> not sure it's up-to-date though [17:29:51] <mru> ubitux: the problem is that all those optimisations are theoretically good, but in gcc they tend to have rather random interactions [17:30:03] <mru> often resulting in code size blowing up or similar [17:30:35] <ubitux> ok [17:33:21] <uau> mru: measured some times the overall time it took to run a particular command [17:35:04] <jannau> lu_zero: looks like you need a more elaborate sed command [17:35:12] <lu_zero> wasn't enough? [17:35:51] <jannau> renaming ff_dprintf_ref() to ff_av_dlog_ref() seems to be unintended [17:36:22] <mru> make sense to me [17:36:30] <mru> look inside those functions [17:37:19] <mru> but maybe losing the av_ on those would be appropriate [17:37:26] <lu_zero> the resulting name might drop the av_ [17:37:30] <jannau> yes, still a strange name [17:37:42] <jannau> ff_dbglog_ref might be better [17:38:02] <mru> what's a db-glog? [17:38:28] <jannau> bikesheds [17:38:35] <kshishkov> db-glögg? [17:40:06] <Sean_McG> are there instructions for setting up fate locally? [17:40:19] <mru> there are, somewhere [17:40:42] <jannau> http://wiki.multimedia.cx/index.php?title=Running_FATE [17:40:58] <mru> I suppose you mean how to run it automatically and send reports [17:41:02] <Sean_McG> aye [17:41:15] <Sean_McG> I've got Solaris x86 and SPARC, if it's useful [17:41:36] <Sean_McG> jannau: cheers for the link [17:42:01] <mru> if you have something not already on the list, your contribution would be appreciated [17:42:34] <Sean_McG> cool [17:43:18] <mmu> hmm how big is it btw ? [17:43:26] <mru> how big is what? [17:44:39] <mmu> requirements for FATE [17:46:39] <mru> test samples are 400M [17:47:37] <kshishkov> and some RAM of course [17:48:05] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rd461a47317 ffmpeg/libavcodec/ (arm/asm-offsets.h arm/mpegvideo_neon.S mpegvideo.h): [17:48:05] <CIA-38> ffmpeg: Rearrange MpegEncContext to simplify access from asm [17:48:05] <CIA-38> ffmpeg: This moves the fields needed by asm near the top, before any [17:48:05] <CIA-38> ffmpeg: structs or other members which complicate the offset calculation. [17:48:05] <CIA-38> ffmpeg: Modifying other structs will no longer require updating the offsets, [17:48:06] <CIA-38> ffmpeg: and the asm code is slightly simpler due to the smaller offsets. [17:48:07] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:48:09] <mru> kshishkov: blame gcc for that [17:48:23] <mru> running the tests needs only 64MB [17:49:00] <kshishkov> mru: still, that's whole 64MB RAM! [17:49:22] <ohsix> i ated the whole thing [17:49:54] <lu_zero> the WHOLE!!!! [17:49:58] <lu_zero> uhm [17:50:02] <lu_zero> which thing? [17:50:53] <kshishkov> probably RAM [17:51:21] <kshishkov> there are so many things that eat RAM [17:51:32] <kshishkov> including GCC compiling motion_est.c [17:52:35] <ohsix> thankfully it eventually regurgitates it [17:53:10] <kshishkov> that was my primary reason to get 128MB RAM in addition to 64MB I had then [17:53:21] <mru> no, but when it dies, the kernel cuts the ram from the dead carcass [17:59:10] <jannau> mru or kshishkov: please join #ffmpeg and kick art|st [17:59:54] <mru> now you can do it [18:00:00] <jannau> thanks [18:00:04] <elenril> too late [18:00:16] <jannau> he left just seconds after I got op [18:00:16] <mru> he can still do it next time [18:00:26] <mru> got scared? [18:00:47] <elenril> he looked too insane for that [18:00:57] * kshishkov does not care about #ffmpeg [18:02:00] <elenril> why are you op there then? [18:02:20] <lu_zero> too late =P [18:03:06] <jannau> he isn't, only in access list. probably from before we moved to #ffmpeg-devel [18:04:09] <kshishkov> indeed [18:10:57] <CIA-38> ffmpeg: Vitor Sessak <vitor1001(a)gmail.com> master * re0eb963aaa ffmpeg/libavcodec/alsdec.c: [18:10:57] <CIA-38> ffmpeg: Fix memory leak in ALS decoder in big endian systems [18:10:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:11:14] <mru> jannau: why didn't patchwork find the patch for that commit? [18:25:36] <Jumpyshoes> https://roundup.ffmpeg.org/issue2524 this was fixed in http://git.ffmpeg.org/?p=ffmpeg.git;a=commit;h=4be170c9371dfd3ae07a348b4490… , how should i close it? [18:40:33] <DonDiego> peloverde, peloverde_, aac ltp patch on -devel... [18:43:36] <jannau> mru: I don't know. straight applied from patchwork? [18:43:54] <mru> patch from ml but no changes [18:43:59] <mru> it usually works [18:44:05] <mru> two patches today failed, both from vitor [18:48:54] <jannau> I've also seen mismatches from patches sent as attachment. but the als memleak patch is so simple I can't image how that could mismatch [18:51:48] <Sean_McG> OK cool I'm done rsync'ing... need to wait for latest gcc to finish build & test [18:59:39] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r243f8241db ffmpeg/libavcodec/libfaac.c: [18:59:39] <CIA-38> ffmpeg: Flush final frames in libfaac encoder. [18:59:39] <CIA-38> ffmpeg: Gives decoded output identical in length to faac commandline encoder. [18:59:39] <CIA-38> ffmpeg: Fixes Issue 670. [18:59:39] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [19:01:29] <lu_zero> is Hervé on irc? [19:02:01] <kshishkov> yep, {V} [19:02:08] <{V}> I am [19:02:28] <lu_zero> I was wondering [19:03:52] <{V}> okay :) [19:06:37] <mmu> libavfilter/avfilter.c:208: warning: 'ff_get_ref_perms_string' defined but not used [19:06:40] <mmu> OMG a warning [19:06:51] <lu_zero> uh [19:07:06] <mru> the function is apparently never used [19:07:16] <mru> or perhaps only under #ifdef DEBUG [19:08:01] <mmu> just testing if it builds in Haiku [19:08:19] <mru> cool, let us know of any problems [19:08:26] <mru> preferably by sending patches [19:08:35] <mru> mmu: btw, are you coming to fosdem? [19:13:23] <mmu> ok so far, lotsa warnings [19:13:29] <mmu> mru yes, got my train tickets [19:13:35] <mmu> trolls ahead :) [19:14:01] <mmu> lots of "is deprecated" warnings [19:14:03] <mmu> ? [19:14:34] <jannau> ignore warnings for now [19:19:14] <mmu> I know, just kidding [19:19:19] <mmu> still building [19:26:00] <mmu> dear, that's almost as long as building the whole of Haiku itself [19:26:36] <spaam> maybe you build it in a loop? [19:26:43] <mmu> lol [19:28:10] <lu_zero> EFL 1.0 released! [19:28:11] <lu_zero> wow [19:29:46] <spaam> Nice [19:29:51] <spaam> about time. [19:33:03] <mmu_man> EFL ? [19:33:13] <mmu_man> the enlightenment stuff ? [19:33:32] <mmu_man> how many decades have they been worked on ? :p [19:33:47] <lu_zero> not sure [19:33:51] <kshishkov> who asks? [19:35:09] <kierank> really [19:36:32] * kshishkov points to Haiku 1.0 [19:36:56] <spaam> kshishkov++ [19:37:16] * kshishkov is also proud of FFmpeg 1.0 [19:37:20] <spaam> kshishkov: do you think that ffmpeg will became 1.0 before haiku? [19:38:07] <lu_zero> spaam: do not give him ideas [19:38:37] <lu_zero> spaam: there is a roadmap item for 0.8 already [19:38:55] <spaam> where? [19:39:14] <lu_zero> it was discussed with siretart and Flameeyes [19:39:22] <lu_zero> here [19:40:12] <spaam> ok :) [19:42:17] <mmu> kshishkov we're discussing beta1 :p [19:42:27] <mmu> plus it's a whole OS, not just a toolkit :p [19:42:37] <kshishkov> mmu: M$ or Google beta? [19:43:06] <kshishkov> mmu: and yes, you are developing extremely fast (compared to GNU Hurd) [19:43:24] <mmu> M$ releases are still beta quality, while Google releases "beta" stuff just to avoid doing support [19:43:30] <mmu> eh [19:43:31] <Sean_McG> Hurd is almost as vaporware as Duke Nukem Forever [19:43:40] <kshishkov> ahem [19:43:45] <mmu> I heard they were again redoing it all [19:43:54] <kshishkov> and they have GNU Hurd NG [19:43:57] <mmu> I Hurd this, I swear :p [19:44:05] <Sean_McG> bad pun [19:44:07] <Sean_McG> no cookie [19:44:22] <siretart> pffft, FFmpeg 1.0 [19:45:12] <Sean_McG> let's release it tomorrrow ;) [19:45:14] <spaam> when -mt will be in ffmpeg. will we change the name to ffmpeg-ng? :) [19:45:56] <spaam> mmu: what scm are you guys using at haiku? :) [19:46:36] <mmu> svn [19:47:03] <mmu> there has been talks about git but well :p [19:47:17] <spaam> ok :) [19:47:27] <mmu> LD ffmpeg_g [19:47:32] <mmu> .. wait .. [19:47:58] <spaam> *drums* [19:48:09] <mmu> .. wait .. [19:48:15] <Sean_McG> *trumpet fanfare* [19:48:16] <spaam> *more drums* [19:48:26] <mmu> "what happens now ?" [19:48:37] <mmu> "death, slavery, more slavery, more death..." [19:49:03] <mmu> (SG1) [19:49:15] <spaam> SG1? [19:49:19] <mmu> how many gigs do I need to link this ? [19:49:19] <Sean_McG> CAKE. [19:49:36] <mru> the cake is a lie [19:49:42] <Sean_McG> yes, yes it is. [19:49:47] <mmu> http://gateworld.net/movies/03.shtml [19:52:02] <kshishkov> mmu: can you benchmark it against "emerge world"? [19:52:39] <mmu> hmm CP takes forever as well :) [19:52:53] <mmu> bash: emerge: command not found [19:52:56] <kshishkov> damn, don't use floopies for source! [19:53:19] <mmu> reminsd me I still have to finish our floppy driver [19:53:31] <Sean_McG> people still use those things?!%^$#& [19:53:36] <mmu> strip... [19:53:46] <mmu> couldn't we tell strip to output to a different file ? [19:53:49] <mmu> that'd avoid cp [19:53:49] <spaam> Sean_McG: why not? [19:54:03] <mmu> -o :) [19:54:04] <Sean_McG> spaam: seriously... I think it's been 5 years since I've used one [19:54:05] <spaam> mmu: disable striP? :) [19:54:55] <mmu_man> $(CP) $< $@ [19:54:55] <mmu_man> $(STRIP) $@ [19:55:00] <mmu_man> WTF [19:55:01] <spaam> mmu: --disable-stripping [19:55:23] <mmu_man> ah it set STRIP=true [19:55:26] <mmu_man> bleh [20:01:06] <Sean_McG> wow, 3PM already [20:01:12] * Sean_McG heads out to anime club [20:03:54] <mmu_mmu> mmu mmu_man ;S [20:06:04] <Blackdown> hello [20:07:17] <mmu> who's that immitator ? [20:08:41] <Blackdown> ? [20:09:00] <mmu> [21:04] *** mmu_mmu (revol(a)0x86.net) has quit IRC (Client Quit) [20:18:44] <spaam> mmu: using the same nick and user like you.. can it be you? :o [20:19:52] <mmu> I wouldn't advertise for int<sub>e</sub>l [20:21:01] <mmu> FFmpeg version git-d461a47, Copyright (c) 2000-2011 the FFmpeg developers [20:21:03] <mmu> \o/ [20:21:10] <spaam> Nice [20:21:16] <spaam> run make fate ! [20:25:09] <Vitor1001> BBB: The PPC VP8 bug can be reproduced in Mans' box using valgrind [20:27:16] <BBB> Vitor1001: can you fix it? I think my patch that I sent to the ML fixes it, but apparently it doesn't do it completely [20:27:24] <BBB> if you can tell me at least where it fails [20:27:30] <BBB> the valgrind so far wasn't very good [20:29:21] <Vitor1001> BBB: Which patch? [20:29:36] <Vitor1001> I only find the old version, that breaks vp8 fate tests [20:29:50] <BBB> http://ffmpeg.pastebin.com/emHDyKJU [20:29:56] <Vitor1001> For me, valgrind points to line 59, for off==0 [20:31:11] <BBB> in which function? [20:31:25] <BBB> is it a hxv4 function? [20:31:37] <BBB> where x is either 4 or 6 [20:31:38] <Vitor1001> put_vp8_epel_h_altivec_core() [20:31:54] <BBB> caller of that function? [20:32:02] <BBB> core is called by hx, vx or hxvx functions [20:32:07] <Vitor1001> Wait, there is something wrong [20:32:14] <Vitor1001> put_vp8_epel4_h4_altivec() [20:32:15] <Vitor1001> called by [20:32:22] <Vitor1001> put_vp8_epel4_h4v4_altivec() [20:32:30] <BBB> yes, my patch should solve that [20:32:36] <Vitor1001> Ok, let me see [20:32:45] <Vitor1001> It takes a lot of time to recompile [20:32:55] <Vitor1001> I should not have make a git pull :-p [20:33:12] <Vitor1001> I'll tell you in ~20 mins [20:33:14] <BBB> ok [20:33:22] <BBB> actually, my patch is wrong I think [20:33:30] <BBB> let me fix it and give you a second one in case the first one doesn't fix it [20:33:30] <BBB> ok? [20:33:40] <Vitor1001> ok [20:33:53] <Vitor1001> Have to wait the compilation anyway [20:34:25] <BBB> http://ffmpeg.pastebin.com/Xe2wRZgV [20:38:19] <mru> Vitor1001: are you using my ppc? [20:38:27] <Vitor1001> mru: yep [20:38:40] <mru> if you're brave you can use distcc [20:38:45] <mru> specify the full compiler name [20:38:50] <mru> my i7 will help out [20:39:03] <Vitor1001> You mean cross-compiling? [20:39:08] <mru> yes [20:39:16] <mru> it usually works [20:39:27] <Vitor1001> And it can auto-detect that it would be a cross-compilation? [20:39:54] <lu_zero> mru: if you put the wrapper in the ppc host it should always work [20:39:57] <mru> if you tell it --cc=powerpc-...gcc it will work [20:41:53] <Blackdown> i'm back [20:42:46] <Blackdown> So I have a question, it is possible to display the percentage of a video during a conversion? [20:42:50] <Blackdown> with php [20:43:04] <mru> wrong channel [20:43:05] <DonDiego> Blackdown: #ffmpeg [20:43:21] <Blackdown> okay, sorry :h [20:45:51] <Vitor1001> BBB: invalid reads remains :-' [20:46:14] <BBB> Vitor1001: first or second patch? [20:46:20] <Vitor1001> Second [20:46:30] <BBB> does it fix the crash? [20:47:05] <Vitor1001> BBB: there is no crash in mans' box [20:47:10] <BBB> hm... [20:47:13] <Vitor1001> just valgrind invalid read errors [20:47:29] <Vitor1001> But, well, OS is free to coredump in those cases [20:47:43] <mru> it would crash if the memory mapping were a bit tighter [20:47:52] <mru> it just happens to not be near a page boundary here [20:48:38] <Vitor1001> mru: Indeed, but crashing would be a sane behavior [20:48:39] <BBB> Vitor1001: is the backtrace of the invalid reads identical? [20:49:04] <BBB> put_vp8_epel__h4/6v4_altivec() calling into v4? [20:49:09] <BBB> (calling into core, ...) [20:49:13] <mru> reading outside explicitly allocated memory may cause any behaviour [20:49:26] <Vitor1001> at least the first, yes [20:51:24] <mru> requiring any access outside allocated memory to trap would make everything as slow as valgrind [20:53:24] <Vitor1001> mru: I know. But I hate when people say a system is buggy because it segfaults for invalid reads [20:53:35] <mru> oh, that I agree with [20:55:16] <BBB> a = vec_ld((off)-2, src); ... [20:55:19] <BBB> that looks buggy to me [20:55:51] <mru> that's wrong for h4 [20:55:54] <mru> should be -1 [20:56:13] <mru> if the -2 is what I think it is [20:56:25] <BBB> exactly [20:57:14] <BBB> although the coefficients in the multiply table are probably set up so that it expects the data to be in such a position, i.e. I don't know how to fix this [20:57:21] <BBB> I just know this looks suspicious [20:59:07] <lu_zero> BBB: wait for me to have back a functional X ^^; [20:59:12] * lu_zero curses libmount [21:11:15] * Kovensky curses X [21:11:28] <mru> X is nice [21:11:47] <mru> although the fd.o people are doing their best to sabotage it [21:12:15] <spaam> fd.o? [21:12:21] <mru> freedesktop.org [21:12:41] <spaam> how do they sabotage it? [21:12:44] <mru> the whole "modular X" thing was the first disaster [21:13:06] <mru> they broke it into a million tiny pieces, each with their own autohell scripts [21:13:11] <spaam> why ? i thought you like that kind of things. [21:13:15] <mru> so build times exploded [21:13:28] <mru> and you still have to match the versions carefully [21:13:46] <mru> only now the working combinations don't even have the same version numbers [21:15:01] <lu_zero> mru: wait [21:15:08] <lu_zero> the build time got _reduced_ [21:15:14] <lu_zero> a LOT [21:15:35] <lu_zero> and keep in mind that autotools made a large step in the right direction [21:15:40] <mru> lu_zero: it spends 95% of the time in autoconf scripts now [21:15:42] <mru> it didn't before [21:16:01] <lu_zero> before 99% of the time was spent processing imakefile [21:16:10] <mru> lies [21:16:25] <lu_zero> mru: I started messing with X in gentoo [21:16:42] <mru> and you can't deny the compatibility hell between the modules now [21:16:43] <lu_zero> and even before gentoo I was building X myself [21:17:00] <lu_zero> there is _lot_ that could be improved [21:17:16] <mru> it's also much more unstable in general than it used to be [21:17:27] <mru> simple things like keyboard drivers don't work right anymore [21:17:29] <lu_zero> but between the current situation and the monolith I'd pick that one [21:18:03] <mru> they should make it impossible to build mismatched versions [21:18:04] <lu_zero> mru: only because you had the bad idea to enable hal or udev ^^ [21:18:09] <mru> I did not [21:18:17] <lu_zero> then is strange [21:18:27] <lu_zero> hal was a major shortcoming [21:18:29] <mru> I have hal and dbus in my package.mask [21:18:57] <mru> some time ago now, they broke hotplugging usb input devices [21:19:01] <lu_zero> and udev support is largely better but still I'm not comfortable with it [21:19:26] <mru> and every time I start X, I have to manually enable auto-repeat on some keys [21:19:36] <mru> which ones changes with each upgrade [21:19:47] <mru> it's usually one or more arrow keys [21:19:52] <mru> sometimes a random letter [21:20:06] <lu_zero> strange and stranger [21:20:06] <mru> and xmodmap doesn't work reliably [21:20:27] <mru> when run from my .xinitrc only parts of the settings take effect [21:20:35] <mru> and it spits an ugly error [21:20:41] <lu_zero> which error? [21:20:45] <mru> forgot [21:20:59] <mru> if I run the same command from xterm immediately after, it works [21:21:16] <lu_zero> might be worth debugging it [21:21:18] <mru> these things never happened before [21:21:31] <lu_zero> well some did differently [21:21:44] <lu_zero> they plugged a lots of old bugs [21:21:49] <mru> all the things I said now are regressions [21:21:55] <lu_zero> but they added a lot of brand new [21:21:55] <mru> blatant ones [21:22:04] <lu_zero> mru: report them [21:22:18] <mru> they used to tell me to enable hal [21:22:21] <mru> which I refuse [21:22:25] <lu_zero> for my usage right now I'm quite happy about X [21:22:37] <lu_zero> mru: who's the dick? [21:22:41] <mru> don't remember [21:23:16] <lu_zero> (since probably it might be the same who wrote the hal support breaking what was working relatively ok...) [21:23:26] <mru> I always got the impression they don't care about bugs that don't affect gnome/kde on ubuntu with default settings [21:23:35] <lu_zero> anyway the hal support now is gone... [21:23:39] <mru> so I've seen [21:23:55] <mru> my X setup is a bit unusual in some ways [21:24:02] <mru> like multihead without xinerama [21:24:40] <mru> I had to install a fake libxinerama to work around the real one telling apps the display is 3x bigger than it is [21:24:49] <mru> 3 heads [21:25:08] <lu_zero> xrandr shouldn't let you do that now? [21:26:34] <saintd3v> I started to setup up xinerama, when i added my second monitor. then the next day i realized Xrandr could do it automatically for me. [21:26:36] <mru> when I have a solution, I tend to forget about the problem after a while [21:28:08] <mru> another weird thing, don't know where to put the blame for this one though: [21:28:20] <mru> copy and paste from xpdf to xemacs doesn't work anymore [21:28:57] <mru> I can open a curses window in a terminal and paste it there [21:30:56] <lu_zero> do you have a clipboard utility in xemacs? [21:31:04] <mru> huh? [21:31:18] <mru> middle-click always pastes the current X selection [21:31:26] <mru> it works with all other apps [21:31:31] <mru> just not that pair [21:31:50] <lu_zero> so xpdf -> world^xemacs is ok? [21:31:56] <mru> yes [21:32:19] <mru> and anything but xpdf -> xemacs is fine [21:32:26] <lu_zero> world^xpdf -> xemacs works as well [21:33:28] <lu_zero> looks like xpdf expresses the buffer in some way (image first, text later?) and xemacs isn't understanding it [21:33:46] <mru> that's not it [21:34:06] <mru> xemacs pastes whatever the previous selection was [21:34:12] <mru> as if xpdf had never been there at all [21:34:33] <lu_zero> X has a number of paste buffers [21:34:36] <mru> I know [21:34:50] <lu_zero> I wonder why xpdf fills them differently now [21:35:06] <mru> xpdf apparently doesn't update the one xemacs looks at [21:35:34] <lu_zero> install a clipboard manager to figure who's stupid [21:35:47] <mru> clipboard managers are stupid [21:36:23] <lu_zero> clipboard manager at least should tell which buffer got touched by who [21:36:36] <mru> if it can be trusted [21:36:40] <lu_zero> otherwise evince or epdf might be an alternative [21:36:45] <mru> tried those [21:36:46] <mru> they suck [21:36:50] <lu_zero> uh? [21:37:03] <mru> as in don't work nearly as well as xpdf [21:37:21] <lu_zero> evince renders relatively better than xpdf (and it's the reason I moved to it) [21:37:53] <mru> but the UI is unusable [21:37:55] <lu_zero> epdfview should be smaller [21:38:03] <lu_zero> but I didn't try it [21:38:43] <mru> hmm, emerge evince wants to pull in some gnome stuff I've masked [21:38:53] <mru> I don't remember why I masked it, but I'm sure there was a reason [21:39:57] <lu_zero> check epdfview [21:40:43] <lu_zero> seems gnome-less [21:40:50] * lu_zero checks as well [21:42:29] * mru tries epdfview [21:42:44] <mru> first problem: it opens showing only 1/8 of the page [21:42:50] <mru> or maybe that's 1/4 [21:42:52] <mru> whatever [21:43:29] <mru> and no way to change that in preferences (which there aren't any) [21:44:57] <mru> minimum size w/o scroll bars has a huge border around the page [21:46:06] <mru> no selection possible at all [21:47:15] * mru uninstalls [21:47:20] <mru> worthless pile of crap [21:50:33] <lu_zero> too barebone I guess [21:51:33] <BBB> I thought xpdf was quite good, why is that out of the question? [21:52:12] <lu_zero> BBB: xpdf has problems [21:52:33] <lu_zero> evince has icky deps to be gentle [21:52:42] <lu_zero> (but works for me) [21:52:52] <lu_zero> epdfview is too barebone [21:53:47] <spaam> maybe its time for FFpdf! [21:54:11] <BBB> wasn't evince based on something that is x-only? [21:55:22] * _av500_ has both evince and okular and prefers adobe [21:56:27] <lu_zero> xpdf is X only [21:56:40] <lu_zero> _av500_: you are scaring me [21:56:45] <_av500_> y? [21:56:54] <_av500_> i have to read 5000page pdfs all the time [21:57:12] <_av500_> and those 2 os solutions suck [21:57:19] <lu_zero> either adobe improved their viewer [21:57:24] <_av500_> one of em insist to start search from the start alwaysa [21:57:39] <lu_zero> it was largely inferior to evince [21:57:51] <lu_zero> not sure about okular [21:57:54] <_av500_> lu_zero: my i7 handles abode just fine [21:57:59] <lu_zero> (never used it) [21:58:05] <_av500_> adobe even [21:58:31] <kierank> is there no foxit for linux? [21:59:01] <_av500_> sure is [21:59:14] <lu_zero> kierank: it's called evince, to the ones that are wondering about Preview, it's called Okular my kde-friends say [21:59:19] <mmu> _av500_ fix them :p [21:59:28] <mmu> you can send a patch :) [21:59:35] <lu_zero> mmu: how's the haiku one btw? [21:59:35] <_av500_> mmu: no time [21:59:49] <mmu> BePDF is based on some xpdf backend [21:59:55] <mmu> needs updates [22:00:08] <lu_zero> poppler is still there [22:00:11] <_av500_> its all poppler in the end :) [22:00:19] <mmu> I think someone built poppler [22:00:34] <lu_zero> gnupdf is quite initial and since it's gnu you never know [22:00:35] <_av500_> we shipped poppler based pdf viewer on 240mhz arm9 [22:00:35] <mmu> the lib at least [22:00:50] <lu_zero> mmu: that's all you need if you have already cairo bindings [22:01:02] <mmu> _av500_ ah, would go nicely alongside NetSurf :p [22:01:12] <mmu> lu_zero that's the problem :p [22:01:44] <lu_zero> mmu: hack the qt backend [22:01:47] <lu_zero> then [22:01:50] <lu_zero> or just use it [22:02:00] <mmu> I think we already have a port of Cairo for FF3 but don't know how much is done [22:02:03] <mmu> plus it sux [22:02:14] <lu_zero> the haiku-qt port should be more or less ok? [22:02:21] <mmu> something that requires adding .5 to the coords to look correct should be trashed [22:02:32] <mmu> maybe but this sux even more [22:02:33] <lu_zero> .5? [22:02:36] <mmu> we want native apps [22:03:22] <lu_zero> mmu: native as in written in the single language supported by the BeAPI? [22:03:28] <mmu> I recall seeing somewhere one had to add .5 to some coords with cairo to render some things less blurry [22:03:38] <mmu> native as in using native controls [22:03:47] <lu_zero> mmu: that means you have a rounding issue somewhere [22:03:57] <lu_zero> and it got fixed the ugly way... [22:04:03] <mmu> not things drawn by some QSkinWhateverItsCalled [22:04:15] <mru> adobe reader does have the best rendering [22:04:33] <lu_zero> so they improved it [22:04:54] <mru> if it weren't for the bloat, the bugs, and the annoying UI, I might use it [22:05:19] <lu_zero> if weren't for the bloat you'd try the current evince ^^; [22:05:35] <peloverde> what about evince-gtk? [22:06:07] <mru> I like the way adobe search gives you a list of all hits [22:06:10] <mru> very useful [22:06:59] <kierank> foxit is useful in that you can create your own bookmarks [22:08:53] <mmu> Preview.app also does [22:09:02] <mmu> show the matching pages [22:11:24] <mru> .app, so silly [22:12:24] <Dark_Shikari> how do I set up git send-email to work? [22:12:33] <Dark_Shikari> I've never used it for, but it looks convenient [22:13:15] <pross-au> Dark_Shikari: it is [22:14:03] <Dark_Shikari> *before [22:14:31] <pross-au> add [sendemail] block to .git/config [22:15:46] <pross-au> i have from=, to=, smtpserver=, smtpuser=, thread=true fields set [22:16:21] <mru> it's useful to set user.email and user.name in the global config [22:16:45] <pross-au> does it use those too? [22:17:10] <mru> absent any overrides in the repo config those go in the from header [22:17:48] <mru> but he probably already has those set [22:17:55] <mru> or his commits would have bogus author info [22:19:06] <siretart> is there an mirror of the git on github somewhere? [22:19:23] <mru> someone was talking about making one [22:19:33] <mru> don't know if it ever happened [22:34:34] <jannau> there is now https://github.com/ffmpeg/ffmpeg [22:34:42] <jannau> not yet auto synced [22:38:01] <lu_zero> nice =) [22:38:25] <lu_zero> should we use a sync hook? [22:39:22] <siretart> hmm. I hoped that https://github.com/blog/626-announcing-svn-support would work on the ffmpeg branch. seems it doesn't [22:44:39] <lu_zero> oh [22:44:49] <lu_zero> I'm eventually back to X ^^; [22:47:31] <lu_zero> {V}: I appreciate your try to make the mediatior, but [22:48:00] <lu_zero> as you can see there isn't much middle ground [22:49:24] <mmu> beware the mediator, this medecine killed people [22:49:56] <{V}> I think there's plenty of middle ground. Michael just doesn't seem to want to budge :) [22:50:09] <mru> that's the point [22:50:19] <{V}> yes, I'm starting to see that [22:52:44] <lu_zero> =\ [22:57:07] <CIA-38> ffmpeg: Luca Barbato <lu_zero(a)gentoo.org> master * rdfd2a005eb ffmpeg/ (47 files in 4 dirs): [22:57:07] <CIA-38> ffmpeg: Replace dprintf with av_dlog [22:57:07] <CIA-38> ffmpeg: dprintf clashes with POSIX.1-2008 [23:02:57] <michaelni> {V}, mru, you guys talk about your own wrong interpretation of my mail i think [23:03:27] <{V}> michaelni, that's possible. [23:03:38] <michaelni> did my reply clarify it ? [23:03:39] <lu_zero> michaelni: I have somebody that is always "misinterpreted" [23:03:47] <iive> michaelni: this is how perceptual bias works. [23:03:50] <{V}> michaelni, I'll check in a moment. [23:04:14] <lu_zero> he's called Silvio Berlusconi [23:04:36] <michaelni> :) [23:04:47] <lu_zero> you do not want that I consider you the same as him. [23:11:39] <kierank> hehe berlusconi [23:18:30] <j-b> 'morning [23:19:55] <spaam> j-b: where are you? [23:20:08] <j-b> Paris, as usual :) [23:20:20] <kierank> j-b: on x264 time? [23:20:27] <j-b> being evil, as French people are, what else? [23:20:32] <j-b> kierank: a bit, yeah :) [23:20:38] <spaam> j-b: haha. [23:21:40] <spaam> kierank: all the cool people follow x264 time? [23:22:00] <kierank> yeah, haven't you heard [23:23:10] <spaam> i didnt get that note :( [23:23:20] <mru> then you're not cool [23:24:46] <j-b> but you can become cool :D [23:25:17] <spaam> how? [23:25:40] <mru> sit in the freezer for a while [23:25:55] <spaam> i thougt i was cool.. in the cool group CDGS with basty, kierank and kshishkov [23:26:18] <j-b> dress like superman, commit on ffmpeg, and go on tv [23:26:34] <j-b> then, wake up at 1pm and go to bed at 7am: done. [23:26:43] <kierank> doing what on tv ;) [23:28:27] <spaam> then say something cool like " I will commit AVSEQ to FFmpeg! and Måns rulgård going to like me even more!" [23:28:44] <spaam> *rullgård [23:33:37] <kierank> what about your amiga port of ffmpeg spaam? [23:33:57] <j-b> or some bink-related code ? [23:34:22] <lu_zero> bink-j since bink-b is too easy [23:37:08] <spaam> thats way kshishkov wont do it [23:37:21] <kierank> spaam: i don't remember inviting kshishkov to CDGS [23:38:35] <BBB> hm, vitor left [23:38:47] <BBB> did we figure out the source of the vp8 ppc hxv4 bug? [23:39:32] <spaam> kierank: do you want some other guy in the group with us? [23:40:25] <spaam> BBB: there was some talk about -1. [23:42:22] <kierank> spaam: dunno [23:43:24] <spaam> maybe mru ? i know he wants avseq. [23:45:50] <kierank> mruCDGS [23:45:59] <kierank> or maybe BBBCDGS [23:46:04] <spaam> :DDD [23:46:20] <kierank> or maybe BBB could invert it to BBBcdgs [23:47:07] <spaam> or bbbCDGS [23:47:37] * BBB kicks spaam [23:47:41] <BBB> go sit in a corner, you [23:48:05] <spaam> BBB: ok :( [23:48:32] * spaam going to the corner. forever alone :'( [23:48:46] <mru> spaam: no, you're not alone [23:48:56] <BBB> bastyCDGS is sitting there also [23:48:57] <mru> spaam: sacarasc is there too [23:49:10] <spaam> woho! :D [23:49:33] <spaam> 2/3 ppl from the CDGS group. nice nice [23:53:25] <pross-au> u guys are too harsh, wasnt the scene guy a student after all? [23:53:55] <mru> he was a fossil [23:54:08] <mru> fossils do not study, they are studied [23:54:22] <pross-au> so he gamed the gsoc program.. [23:54:38] <mru> I guess he was registered at some university [23:54:59] <pross-au> lolz [23:55:40] <kierank> mru: as an exhibit? [23:56:38] <mru> lu_zero: In file included from /home/mru/src/ffmpeg.dev/libavformat/avio.c:30: [23:56:41] <mru> /home/mru/src/ffmpeg.dev/libavformat/network.h:69: error: redefinition of 'struct sockaddr_storage' [23:59:03] <bcoudu> god, let's pray the iphone 5 has both gsm/cdma [23:59:21] <mru> who cares about iphone? [23:59:34] <mru> spaam: is it called iFån in .se?

1 0

IRC log for 2011-01-28
by irc＠mansr.com 29 Jan '11

29 Jan '11

[00:05:20] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r37cb3eb534 ffmpeg/libavcodec/iirfilter.c: [00:05:20] <CIA-38> ffmpeg: Add special case for 2nd-order IIR filter. [00:05:20] <CIA-38> ffmpeg: 40% faster in ff_iir_filter_flt() when c->order == 2. [00:07:06] <CIA-38> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * r795ed278e6 ffmpeg/libavformat/movenc.c: [00:07:06] <CIA-38> ffmpeg: movenc: byteswap codec_tag in mov_write_ms_tag [00:07:06] <CIA-38> ffmpeg: based on Alex Converse's "Fix ADPCM MS in mov muxing" patch [00:07:17] <CIA-38> ffmpeg: John Stebbins <stebbins(a)jetheaddev.com> master * r97b04f5ed3 ffmpeg/libavformat/mov.c: [00:07:17] <CIA-38> ffmpeg: mov: add support for little-endian utf16 chapter names [00:07:17] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [00:07:18] <CIA-38> ffmpeg: Baptiste Coudurier <baptiste.coudurier(a)gmail.com> master * rf258964217 ffmpeg/libavformat/ (mov.c movenc.c): [00:07:18] <CIA-38> ffmpeg: In mov muxer, mux adpcm_ms and adpcm_ima_wav the way quicktime supports it [00:07:18] <CIA-38> ffmpeg: In mov demuxer, set adpcm_ms and adpcm_ima_wav frame size to stsd samples per packet. [00:07:18] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [00:22:18] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rb5ec638343 ffmpeg/libavcodec/ (aacdec.c ac3dec.c dca.c nellymoserdec.c wmadec.c): cosmetics: indentation and spacing [00:22:29] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r9d06d7bce3 ffmpeg/libavcodec/ (12 files): Remove the add bias hack for the C version of DSPContext.float_to_int16_*(). [00:22:55] <mru> hmm, cia got the order wrong [00:24:22] <ruggles> i've seen that on the ML too when the email timestamps are identical [00:24:35] <mru> timestamps are not the issue [00:24:45] <mru> emails sometimes simply get reordered along the way [00:25:17] <ruggles> ah [00:26:32] <mru> nothing in the mail transport looks at timestamps at least [00:27:49] <mru> every server has some kind of queue system, which doesn't need to be a strict fifo [00:29:08] <saste> good night people [00:29:16] <jannau> good night saste [00:32:27] <mru> argh, libvpx is still slightly faster on two clips on omap4 [00:33:20] <mru> ffvp8 is faster on all my clips on omap3 [00:33:23] <jannau> but using both cores instead of just one? [00:33:42] <mru> single-threaded [00:34:10] <mru> at least that's what I asked for [00:34:37] <mru> and numbers are consistent between omap3 and omap4 in that regard [00:35:17] <mru> but I'm running out of functions to optimise [00:35:34] <mru> I'll probably have to write some of the mb parsing in asm [00:35:43] <mru> make that some more [00:40:39] <Dark_Shikari> maybe the asm is better optimized for a9 as opposed to a8? [00:40:43] <Dark_Shikari> check top to make sure it's only using one core [00:41:08] <mru> it's roughtly twice as fast on 1GHz a9 as 600MHz a8 [00:41:23] <mru> same ratios for ffmpeg [00:41:37] <mru> I think the difference is in non-asm code [00:42:04] <mru> the a9 neon unit is in some ways slower than a8 [00:42:23] <Dark_Shikari> well, iirc the ffvp8 code is rather better structured at least [00:42:26] <Dark_Shikari> in terms of memory layout, etc [00:42:29] <Dark_Shikari> with stuff like the ringbuffer [00:43:18] <Dark_Shikari> btw, structural improvements are welcome as well [00:43:27] <Dark_Shikari> did you do neon versions of the idct_dc functions? [00:43:31] <Dark_Shikari> i.e. the uv4 and all that [00:43:35] <mru> yes [00:44:20] <mru> it's all in my git repo if you're curious [00:44:32] <Dark_Shikari> ok [00:45:34] <mru> I'm going to mess some more with the rac functions and see what happens [00:45:56] <Dark_Shikari> BBB: [00:45:58] <Dark_Shikari> if (copy) { [00:45:58] <Dark_Shikari> * (uint32_t *) (ptr+4*x) = * (uint32_t *) (copy_dst + 12); [00:46:01] <Dark_Shikari> * (uint32_t *) (ptr+4*x+s->linesize) = * (uint32_t *) (copy_dst + 20); [00:46:05] <Dark_Shikari> * (uint32_t *) (ptr+4*x+s->linesize*2) = * (uint32_t *) (copy_dst + 28); [00:46:08] <mru> perhaps write the entire decode_mb_coeffs in asm [00:46:08] <Dark_Shikari> * (uint32_t *) (ptr+4*x+s->linesize*3) = * (uint32_t *) (copy_dst + 36); [00:46:12] <Dark_Shikari> } [00:46:14] <Dark_Shikari> Stop with your aliasing ivolations please [00:46:17] <Dark_Shikari> and go fix that [00:46:26] <BBB> they are aligned! [00:46:28] <BBB> isn't it ok then? [00:46:31] <mru> no [00:46:40] <mru> that's not what aliasing means [00:46:40] <Dark_Shikari> No [00:46:44] <Dark_Shikari> it's not ok [00:46:45] <Dark_Shikari> ever [00:46:48] <Dark_Shikari> *(x*) is not ok [00:46:50] <mru> use the AV_RN*A macros [00:46:56] <mru> and WN [00:46:59] <Dark_Shikari> and please inline if(copy) into the EMULATED_EDGE section [00:47:03] <mru> or COPY [00:47:04] <Dark_Shikari> don't leave it hanging outside [00:47:18] <Dark_Shikari> I don't want it slowing down my non-stupid code [00:47:37] <Dark_Shikari> if ((y == 0 || x == 3) && mb_y == 0 && avctx->flags & CODEC_FLAG_EMU_EDGE) { topright = tr_top; [00:47:40] <Dark_Shikari> merge the EMU_EDGE ifs please [00:48:05] <Dark_Shikari> and while you're at it, add a comment or two to explain your mess [00:58:52] <Dark_Shikari> BBB: you going to do that or should I [01:28:30] <Dark_Shikari> BBB: ? [01:39:51] <BBB> Dark_Shikari: sorry, dinner [01:39:54] <BBB> Dark_Shikari: will fix [01:39:58] <BBB> Dark_Shikari: what shall I use instead? [01:40:06] <BBB> Dark_Shikari: I thought it was fine if I used alignment [01:40:09] <BBB> sorry if it wasn't [01:40:15] <BBB> is AV_[WR]N32A ok? [01:40:41] <mru> there are COPY macros too [01:40:45] <mru> they'll save you some typing [01:49:21] <CIA-38> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * re628864033 ffmpeg/libavformat/libavformat.v: [01:49:21] <CIA-38> ffmpeg: Hide demuxers', muxers' and protocols' objects via the ld version script. [01:49:21] <CIA-38> ffmpeg: This reduces the symbols exported by libavformat from 699 to 451. [01:49:21] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:49:30] <CIA-38> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rac28ce5fac ffmpeg/libavcodec/libavcodec.v: [01:49:30] <CIA-38> ffmpeg: Hide the now-prefixed decoders, encoders, parsers, bsf, hwaccel objects. [01:49:30] <CIA-38> ffmpeg: This significantly reduces the size of the symbol table in the generated ELF [01:49:30] <CIA-38> ffmpeg: shared object (as well as the other linked tables). [01:49:31] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:57:48] <BBB> mru: ok, will use those [02:18:42] <j0sh> is nb_rtsp_streams always 1 under tcp? (reviewing lu_zero's patch) [02:19:29] <Dark_Shikari> BBB: do what I said [02:19:31] <Dark_Shikari> get rid of all type puns [02:19:39] <Dark_Shikari> merge if(copy) into the emu edge section [02:19:44] <Dark_Shikari> get rid of the redundant emu_edge checks [02:21:37] <lu_zero> shouldn't [02:39:42] * Compn wonders what carl is so angry at [02:39:43] <Compn> lol [03:08:55] <BBB> Dark_Shikari: yes, I will - have a visitor right now but will send a patch tonight [03:22:35] <Dark_Shikari> ok [03:51:42] <j0sh> http://imgur.com/jacoj [04:33:34] <peloverde> to flame or not to flame: that is the question [04:35:35] <saintdev> fffire extinguisher [04:43:35] <pross-au> so thats what the other f stands for [04:43:48] <pross-au> LS [05:05:18] <in3xes> anyone has specification sheet for Tivo format? [05:06:56] <jai> read demux_ty.c from mplayer's source tree [05:08:07] <in3xes> No other way? I mean, anything official? [05:08:12] <jai> no [05:08:33] <Sean_McG> Tivo doesn't want to write themselves out of business. [05:09:55] <in3xes> reading this may be easier http://goo.gl/ulfLb [05:11:07] <jai> i don't see anything useful on that page [05:11:08] <in3xes> or not? [05:11:18] <in3xes> source [05:11:26] <jai> good luck with that then [05:11:36] <in3xes> I was just asking [05:31:21] <Compn> in3xes : btw there are devs to help reading mplayer code, if you need that [05:31:35] <Compn> but as for specs, its a private company like apple, no specs [05:31:59] <Compn> and even if there were specs (like on2) , the code is the spec in many cases [05:32:13] <Compn> bwahahahaha [05:32:26] <Compn> now you see what ffmpeg and mplayer had to put up with all of these years [05:32:37] <jai> reimar said he would help anyone who wanted to port it, i guess you'll have to ask on the ML [05:32:43] <Compn> in3xes : btw there might be something written up on http://wiki.multimedia.cx but i doubt it [05:32:56] <Compn> there were some tivo projects too, maybe one of them has better docs [05:33:19] <in3xes> I went to that page because of I was scared of mplayer codebase [05:33:43] <jai> 23:06:40 @jai | read demux_ty.c from mplayer's source tree [05:33:48] <jai> i stand by what i said :) [05:34:02] <Compn> people still have tivos ? [05:34:03] <Compn> :P [05:34:03] <jai> it's probably the easiest way to port it [05:34:04] <in3xes> I figured that long before [05:34:07] * Compn trooooolls [05:34:12] * Compn sleeps [05:34:14] <Compn> night [05:34:29] <Compn> now to find the comfy spot under the bridge... [05:35:56] <in3xes> Compn: Thanks for the info [06:02:42] <thresh> moroning [06:27:58] <siretart> good moroning! [06:28:10] <thresh> who's Gabu? [06:28:30] * thresh is young and doesnt know the flamers [06:28:42] <siretart> thresh: you really don't want to know [06:29:24] <thresh> siretart: haha :) [06:29:45] <thresh> it mustve been good I was ignoring mplayer [06:29:51] <peloverde> I kind of lost it at Arpi [06:30:03] <siretart> KotH: thank you very much for your very clear statement. I found it very enlighting! [06:30:03] * kshishkov thinks thresh might be somehow related to VLC [06:30:42] <thresh> kshishkov: yes, the rule of ignoring mplayer is one of the first ones in our Figh^WVideoLAN club [06:32:11] <kshishkov> thresh: lucky you. There were at least three ex-MPlayer guys nobody have heard about for a long time coming here. [06:32:31] <kshishkov> thresh: feels a bit like undead rising [06:32:34] <thresh> well I remember arpi [06:37:16] <kshishkov> as an active developer? [06:38:54] <thresh> hey I'm not in my 40s to remember *that* [06:41:29] <peloverde> Is there some sort of attribute that can be used to trick gcc about get_bits() range? [07:17:34] * elenril yawns [07:18:19] <_av500_> gm [07:20:49] <elenril> yay, more fflames [07:22:24] <saintdev> elenril: you should fffan the ffflames [07:24:04] <elenril> what's up with all the ghosts from the past [07:30:50] <Tjoppen> god morgon [07:46:22] * elenril reads about KotH hating us all and Dark_Shikari feeding the trolls :/ [07:46:43] * wbs doesn't dare start reading the mails from last night yet [07:48:11] <elenril> Sean_McG: chapters? [07:53:39] <spaam> wbs: awww [08:12:25] <peloverde> Can we make an mplayer-grumpy-old men list and reserve FFmpeg-devel for FFmpeg development? [08:13:24] <DonDiego> go ahead and suggest it [08:14:01] <DonDiego> btw, i woke up with a mailbox full of flames this morning, i don't intend to read it for now - anything important i need to respond to? [08:19:17] <superdump> perhaps if you haven't read KotH's mail you wish to read that [08:20:50] <peloverde> The MPlayer emeriti have got to go [08:24:45] <kshishkov> that all makes me want to switch to VLC finally. Or at least to mplayer2(uau) [08:25:04] <spaam> kshishkov: not mplayerG2 ? [08:25:45] <kshishkov> spaam: it's like GNU Hurd but even less developed [08:26:07] * elenril wonders where do those trolls keep coming from [08:26:25] <spaam> kshishkov: haha :) [08:26:37] <kshishkov> elenril: mostly Hungary. And MPlayer graveyard [08:27:36] <elenril> just ban them all to nine hells :/ [08:27:56] <elenril> peloverde: don't bother feeding them [08:28:41] <MultimediaMike> Sort of a troll reunion ; makes me sentimental [08:28:52] <elenril> wow, Mike is here [08:28:55] <elenril> hi MultimediaMike [08:28:58] <superdump> wow, we have mr melanson too? :) [08:29:00] <superdump> hey MultimediaMike [08:29:09] <kshishkov> MultimediaMike: and I've just started working on Xxan decoder again :( [08:29:49] <superdump> MultimediaMike: did you guys at adobe locate that memcpy instead of memmove yet? :) [08:30:26] <DonDiego> peloverde: if you feel that MPlayer issues have to stay out of this, say it [08:30:50] <Dark_Shikari> holy crap it's MultimediaMike [08:31:01] <Dark_Shikari> michaelni AND MultimediaMike [08:31:04] <DonDiego> MultimediaMike: mike? hey! what are you up to... [08:31:04] <Dark_Shikari> the mike pair [08:31:33] <DonDiego> Dark_Shikari: michael is not mike, although we always use the english instead of the german pronounciation, dunno why really... [08:31:38] <kshishkov> now all we need is Michel from France who's also not active these days [08:33:20] <peloverde> DonDiego: MPlayer is not FFmpeg. MPlayer developers who happen to develop FFmpeg are welcome. Former MPlayer developers who are not current FFmpeg contributors are not welcome to participate in organizational discussion. They are welcome to do code review or contribute new code. [08:33:58] <kshishkov> peloverde: only the latter - look at MPlayer code and tell how well it was reviewed [08:34:51] <DonDiego> peloverde: i absolutely agree, but you have to tell it to those people, not to me, please *do* express your feelings [08:36:19] <MultimediaMike> Me? I just decided to put an IRC client on my smartphone and keep upper with the drama [08:36:32] <Dark_Shikari> COME BACK AND DO ACTUAL WORK MIKE [08:36:35] <Dark_Shikari> and stop whoring all day at adobe [08:36:48] <Dark_Shikari> also you could apply for a job at gaikai, all the cool kids are doing that [08:37:01] <MultimediaMike> First time I have seen IRC in 2 years [08:37:04] <kshishkov> Dark_Shikari: he's not a kid anymore [08:37:09] <Dark_Shikari> Sure he is. [08:37:15] <peloverde> DonDiego: I said that to Berczi Gabor and I said that to Arpi, and I even had time to make two contributions in the process [08:37:18] <MultimediaMike> Sure I am [08:37:52] <kshishkov> MultimediaMike: where's the beef^Wcode? [08:38:29] <MultimediaMike> Xan will totally be ready any day now [08:38:47] <kshishkov> really? [08:38:50] <MultimediaMike> Right after I finish the 669 loader [08:39:05] <MultimediaMike> Which is an unrelated inside joke [08:40:19] <kshishkov> isn't that some module format? [08:40:23] <MultimediaMike> Maybe I should fix up ffvp8enc so that it beats x264 [08:40:25] <pross-au> what happened to the protracker guy? [08:40:49] <DonDiego> peloverde: ok, sorry, i haven't read all the mails yet... [08:40:54] <kshishkov> MultimediaMike: sorry, it's going to be xvp8 when BBB is finally ready to do it [08:41:01] <spaam> pross-au: avseq? [08:41:02] <MultimediaMike> Yeah 669 is a mod format [08:41:10] <kshishkov> pross-au: it all got sweeped out by libavsynth, I fear [08:41:32] <pross-au> who working on that kshishkov? [08:41:49] <kshishkov> pross-au: BastyCDGS of course! [08:42:17] <pross-au> still? [08:42:41] <kshishkov> we still have some time till the heat death of th Universe [08:43:44] <spaam> pross-au: do you wanna join his CDGS group with kirank and kshishkov ? [08:44:08] <kshishkov> spaam: and you [08:44:26] <spaam> i forgot that :) [08:44:37] <pross-au> im already in it [08:44:55] <spaam> good :D [08:45:34] <kshishkov> pross-au: Bink first! [08:47:01] <pJok> god morgon [08:47:42] <kshishkov> goda morgnar, pJok [08:48:01] <pJok> first mni on irc and then mike [08:48:35] <pJok> hell froze over, pigs are flying... has world peace also come? [08:48:50] <kshishkov> pJok: it's the other way round [08:49:02] <spaam> maybe Döffinger will join irc soon also ;D [08:49:04] <MultimediaMike> I was on Irc first; I just didn't stick around [08:49:41] <pJok> mike, what i mean is, you've not been here for two years and you came back... mni has (to my knowledge) not been in here before [08:50:18] * kshishkov remembers those times - single #ffmpeg channel, mostly everybody asking only how to recode his file into Fl*sh [08:50:36] <Dark_Shikari> it's stil flash [08:50:37] <Dark_Shikari> lol [08:50:58] <kshishkov> but there's $channelname to, not only user channel [08:51:02] <kshishkov> *too [08:51:06] <MultimediaMike> "Join IRC or be stripped of your leadership " is a powerful motivator [08:51:37] <kshishkov> MultimediaMike: sorry, you're not a leader anyway [08:51:48] <Dark_Shikari> yes, ever since he was eaten by adobe [08:51:59] <MultimediaMike> Not referring to me [08:52:18] <MultimediaMike> I lead nothing [08:52:36] <kshishkov> obviously, for you it should have something to do with game or QuickTime codecs [08:52:37] <spaam> kshishkov: you can be the leader and force everyone to speak swedish and drink trocadero :) [08:52:49] <pJok> mike, i thought you were leading a path to destruction (or at least Linux Flash support) [08:53:03] <kshishkov> spaam: what? that would leave less trocadero to me! So I refuse [08:53:18] <pJok> spaam, tried vira blåtira btw? [08:53:56] <pJok> servus __av500__ [08:54:02] <pJok> or not [08:54:21] <spaam> pJok: i dont like that one so much ;S [08:54:52] <kshishkov> spaam: Guldus? Cuba cola? 21? Haiwa? Siddni? [08:55:03] <pJok> spaam, i can't say i like it, but i don't dislike it either... its just odd that you can't seem to buy it anywhere in skåne... other than rosa pantern drugstore in ängelholm [08:55:22] <kshishkov> spaam: and yes, Fruktsoda from Vasa has similar colour [08:55:47] <pJok> i can usually only find Three Hearts soda from Halmstad everywhere [08:55:55] <spaam> kshishkov: never heard about those .. only cuba cola [08:56:14] <kshishkov> spaam: http://www.vasabryggeri.nu/ [08:56:20] <pJok> spaam, i think all those sodas are norrlans soda [08:56:55] <spaam> ah yeah [08:58:43] <KotH> salut MultimediaMike! [08:58:43] <MultimediaMike> Is this really Arpi? http://www.facebook.com/people/Arpad-Gereoffy/100001021857658 [08:58:51] <KotH> MultimediaMike: how is it going in the new world? [08:59:13] <KotH> MultimediaMike: yes [09:00:01] <MultimediaMike> Koth- Attila? [09:00:09] <KotH> juup, the one and only :) [09:00:15] <DonDiego> MultimediaMike: http://linsze.hu/pic/arpi1.jpg [09:00:24] <av500> MultimediaMike: hi Mike! [09:00:28] <MultimediaMike> I missed you too [09:00:48] <KotH> MultimediaMike: are you comming to LT this year? [09:00:54] <KotH> MultimediaMike: i promise to come as well :) [09:01:17] <MultimediaMike> Didn't plan too [09:01:26] <KotH> :-/ [09:01:26] <MultimediaMike> Europe is so far [09:01:44] <spaam> MultimediaMike: move ? :) [09:01:45] <KotH> but we're at the center of the world! :) [09:02:11] <MultimediaMike> Would love to come to fosdem [09:02:22] <MultimediaMike> I like Brussels [09:02:28] * KotH would like to as well... and beat the shit out of some people [09:02:49] <KotH> mru: you should show MultimediaMike the picture of brussels we took :) [09:02:56] <kshishkov> KotH: and do you know what country is at the centre of Europe? [09:03:10] <KotH> kshishkov: switzerland ;-) [09:03:17] <kshishkov> KotH: nope, Ukraine [09:03:20] <MultimediaMike> So weird - is all this drama really bothering you people? [09:03:42] <KotH> MultimediaMike: well... there has been a lot more going on than just on the mailinglist [09:03:44] <kshishkov> KotH: there's even special monument standing at the geographical centre of Europe - made by Austrians [09:03:46] <spaam> kshishkov: ukraine? i thought it was sweden.. ;/ [09:03:50] <KotH> MultimediaMike: and yes, it's bothering me [09:04:00] <KotH> kshishkov: lol [09:04:02] <kshishkov> spaam: that's centre of civilised world [09:04:38] <kshishkov> KotH: that's completely true. And as you know half of Ukraine was under Austro-Hungarian rule. [09:04:50] <kshishkov> it's mostly annoying [09:05:09] <kshishkov> why not do something productive instead of flaming? [09:05:34] <MultimediaMike> Being on one of the most reviled software teams on the planet, this drama looks ....small, I guess [09:06:10] <superdump> that reminds me [09:06:18] <Dark_Shikari> kshishkov: ffmpeg is all about people who do no real work [09:06:25] <Dark_Shikari> michael (flames and reviews, no actual code) [09:06:31] <bcoudu> ... [09:06:33] <Dark_Shikari> me (bitches about things sucking, not much actual code) [09:06:35] <av500> MultimediaMike: wrt reviled, when will flash be able to handle overlays? [09:06:36] <kshishkov> Dark_Shikari: wasn't that #ffmpeg-devel ? [09:06:37] <bcoudu> are we talking commit count ? [09:06:38] <Dark_Shikari> mike (done nothing for 5 years) [09:06:45] <Dark_Shikari> etc etc [09:06:46] <Dark_Shikari> ;) [09:06:51] * Dark_Shikari is semi-trolling [09:07:10] <kshishkov> bcoudu: nope, just code and its functions [09:07:11] <superdump> MultimediaMike: why don't you have feature and performance parity on Linux with Windows? and why hasn't the source code been released? [09:07:56] <DonDiego> superdump: you never heard what the code looks like? [09:08:01] <KotH> Dark_Shikari: and what would you say about me? lurking in the shadows and stabbing peoples backs? [09:08:26] <superdump> DonDiego: i have :) [09:08:47] <MultimediaMike> Overlays: glad you asked [09:08:51] <av500> DonDiego: I can confirm [09:08:52] <MultimediaMike> http://labs.adobe.com/technologies/flashplayer10/stagevideo.html [09:09:59] <av500> MultimediaMike: and for that mobile OS from that search company? [09:10:15] <MultimediaMike> When did I last do something on ffmpeg? Must have been those Theora optimizations a year ago [09:10:57] <MultimediaMike> Unless you count ffvp8enc, which I wouldn't [09:11:07] <kshishkov> MultimediaMike: http://wiki.multimedia.cx/index.php?title=Category:Undiscovered_Game_Formats [09:11:16] <bcoudu> kshishkov, that should be about the same [09:11:21] <Dark_Shikari> MultimediaMike: the theora code still sucks [09:11:22] <Dark_Shikari> :> [09:11:38] <kshishkov> Dark_Shikari: that's by codec design [09:11:41] <MultimediaMike> Av500: what about them? [09:11:54] <Dark_Shikari> kshishkov: no, the code sucks too [09:11:57] <kshishkov> bcoudu: not exactly [09:11:58] <Dark_Shikari> it does 4x 8x8 MC on 16x16 blocks [09:12:02] <Dark_Shikari> even though 8x8 blocks are extremely rare [09:12:32] <MultimediaMike> True, that was on my todo list [09:12:57] <MultimediaMike> I thought dconrad would handle that [09:12:58] <bcoudu> kshishkov, numbers ? [09:13:10] <Dark_Shikari> MultimediaMike: apple ate him [09:13:23] <MultimediaMike> He won't be handling anything related to ffmpeg [09:13:44] <kshishkov> bcoudu: just the fact cosmetics and documentation-only commits exist should be enough [09:14:34] <superdump> MultimediaMike: yeah but that's only for 32-bit so i'm using square [09:15:25] <bcoudu> documentation counts IMHO [09:16:15] <cartman> moin [09:16:56] <kshishkov> grüß dich [09:17:24] <cartman> nice discussion over ml [09:21:00] <spaam> kshishkov: http://talk.newagtalk.com/forums/thread-view.asp?tid=165984&mid=1190655#M11… "Locomotive Engine Failure - Blown Piston" [09:22:58] <kshishkov> spaam: well, it's rather ugly diesellok [09:23:11] <spaam> yes. :) [09:23:21] * kshishkov likes IORE [09:28:15] <DonDiego> bye [09:40:36] <j-b> ok, so you've reached DA point [09:40:42] <j-b> what about conciliation now? [09:41:16] <lu_zero> j-b: from the ffmpeg point of view everything is fine [09:41:57] <j-b> lu_zero: you mean th code? [09:41:58] <lu_zero> and trolls are just that [09:41:58] <lu_zero> and I'm sick of discussing [09:42:25] <bcoudu> .... [09:42:51] <j-b> well, maybe you, lu_zero, should help people find a compromise? [09:43:24] <MultimediaMike> J-b: is VLC Prepared to reconcile with Apple? [09:43:30] <lu_zero> j-b: trying to find compromises is something I did in the past months... [09:43:34] * kshishkov wonders: who knew that Niederösterreich had such an idiotic flag [09:43:35] <j-b> MultimediaMike: oh, yes [09:43:45] <j-b> MultimediaMike: I've mailed them again yesterday [09:43:52] <lu_zero> so now I'm a bit discouraged on that part [09:43:57] <j-b> MultimediaMike: I even mailed steve@ twice [09:44:44] <MultimediaMike> Now you'll have to try timcook@ now [09:45:01] <j-b> MultimediaMike: yeah, and that's a bit bad... [09:45:21] <av500> j-b: asking for appl to change the appstore for gpl? [09:45:35] <j-b> not for the gpl [09:45:42] <j-b> just clarify one term [09:45:47] <j-b> that they already apply in fact [09:45:58] <j-b> but they don't want to write it down [09:46:11] <jannau> it's of course not fine, we are losing developers but fear every mail no matter what's in it will accelerate the process [09:47:34] <jannau> attila sugested that we (including michael) meet at fosdem [09:47:49] <j-b> wow [09:47:57] <j-b> are you making sense now? [09:47:58] <j-b> no way [09:48:21] <lu_zero> j-b: I know it won't work. [09:48:28] <j-b> I disagree [09:48:35] <Kovensky> talking about vlc / osx, how do I get rid of the floating player control =p </userquestion> [09:48:47] <superdump> well, i'll be at fosdem [09:48:52] <{V}> only flamebait arpi seems to have seen my attempt at finding a compromise :-/ [09:48:55] <lu_zero> brb [09:48:56] <superdump> i guess michaelni won't be at fosdem [09:49:20] <j-b> Kovensky: no fucking idea... there is a reason why I am rewriting this interface. Did you try the view something like cmd+m ? [09:49:38] <superdump> bcoudu: will you be at fosdem? [09:49:40] <Kovensky> oh, you're rewriting the cocoa interface? cool [09:49:42] <kshishkov> superdump: what makes you think so? [09:49:54] <j-b> Kovensky: to be a bit more up to date, yes [09:50:25] <Kovensky> Cmd+m just minimizes ._. [09:50:32] * Kovensky never used that shortcut before, just doesn't minimize windows [09:50:38] <superdump> kshishkov: as far as i know, michaelni has not said he's going and perhaps it is a bit late to organise travel now, though perhaps not [09:51:03] <bcoudu> superdump, nope [09:51:14] <j-b> superdump: late? you are kidding... [09:51:23] <kshishkov> superdump: has he ever went to some public event? [09:51:40] <superdump> bcoudu: shame, it's been quite a while since we last met [09:51:46] <j-b> he has to. [09:55:32] <superdump> michaelni: is there any chance you could go to fosdem? [10:03:06] <Tjoppen> libvorbis depends on libogg? that's.. interesting [10:03:32] <j-b> I would have used another adjective [10:49:41] <elenril> Dark_Shikari: srsly, don't feed the iive ;) [10:52:26] <kshishkov> elenril: with all his faults he's at least FFmpeg dev [10:54:52] <elenril> the last time he was active was the deathmatch in 2009 =p [10:55:21] <elenril> who was it against btw? [10:55:26] * elenril can't remember anymore [10:55:27] <kshishkov> Diego [10:55:31] <elenril> right [10:55:48] <elenril> those were fun times [10:55:55] <elenril> we should do it again [10:57:50] <thresh> next week is ok for me to get enough pop-corn [10:58:15] <lu_zero> sure [10:58:23] <lu_zero> but probably it won't be that fun [11:00:34] <j-b> thresh: can you bring some for FOSDEM? </sarcasm> [11:01:04] <lu_zero> j-b: there is already plenty of beer [11:01:20] <j-b> I'll live with beers [11:02:26] * av500 prepares to shower j-b with french beer [11:02:36] <j-b> I'd welcome that [11:03:57] <cartman> cd .. [11:04:05] <cartman> someone cd please :O [11:04:32] <elenril> bash: ..: no such file or directory [11:05:13] <{V}> elenril, good one :) [11:05:37] <mru> morning [11:06:03] <cartman> char* strerror(int inErrno) [11:06:03] <cartman> { [11:06:03] <cartman> return "Unknown Error"; [11:06:04] <cartman> } [11:06:07] <cartman> lol [11:07:25] <lu_zero> cartman: O_o [11:08:21] <jannau> cartman: at least you can't claim it's wrong [11:08:33] <cartman> jannau: true [11:39:59] <CIA-38> ffmpeg: Alex Converse <alex.converse(a)gmail.com> master * r5ce5dbc5f3 ffmpeg/libavcodec/ (dsputil.c dsputil.h): [11:39:59] <CIA-38> ffmpeg: Make ff_float_to_int16*_c() static. [11:39:59] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:48:16] <wm4> what's the current state of the ffdrama? it seems everyone is fine with separated git repositories? [11:48:26] <kshishkov> but one person [11:49:00] <kshishkov> personally I'm going to keep ignoring it [11:49:01] <mru> and hungarian trolls keep pouring out from under the bridges [11:50:19] <mru> good choice [11:50:41] <j-b> wm4: one git repository will die eventually [11:50:57] <mru> right now one of them is clearly leading [11:51:13] <kshishkov> mru: and another one is illegally taking over [11:51:57] <j-b> define "legal" [11:52:15] <wm4> there was also the issue who owns the ffmpeg trademark and domain... [11:52:20] <mru> j-b: approved by MN [11:52:24] <kshishkov> j-b: by "Quod Dici" law [11:52:32] <mru> wm4: fabrice owns the ffmpeg name and domain [11:52:33] <j-b> wm4: Fabrice [11:52:38] <j-b> wm4: fortunately [11:52:45] <j-b> since this is the biggest asset [11:52:57] <wm4> yeah, I mean, did he put out a statement yet? [11:53:06] <mru> no [11:53:07] <j-b> he is too clever to put a statement now [11:53:15] <wm4> heh [11:53:30] <wm4> then I take it the whole situation is still in limbo [11:53:52] <j-b> wm4: however, I know a good popcorn reseller </sarcasm> [11:53:53] <mru> there are a bunch of trolls flaming away while the rest of us do useful work [11:56:55] <jannau> you mean cosmetics, bikesheds and reverts which are still good enough to be ported over [11:58:32] <mru> dammit, still slower than libvpx on one clip [11:59:04] <mru> not that it really matters [11:59:08] <mru> both are >130fps [11:59:20] <kshishkov> oprofile to the help? [11:59:32] <mru> oprofile isn't working too well on omap4 [11:59:34] <mru> yet [11:59:39] <mru> I need to shout at ti more [11:59:47] <lu_zero> perf is any better? [11:59:52] <mru> no [11:59:57] <kshishkov> mru: subcontract professional [12:00:06] <mru> lu_zero: the interrupt configuration is missing [12:00:22] <mru> so neither perf or oprofile can get any samples [12:00:34] <lu_zero> I see [12:00:55] <{V}> I don't think Fabrice is going to make any statement anytime soon. Has he even sent 1 email in the last year to any mailinglist (qemu, ffmpeg, tcc,..) [12:01:09] <mru> not ffmpeg [12:01:12] <mru> can't say for the others [12:03:40] * lu_zero plays a bit with ruby-elf [12:04:37] <jannau> gmane find mails on qemu lists from march 2010 [12:06:06] <cartman> rename it ffsmpeg [12:06:50] <kshishkov> FFmedia? [12:07:02] <kierank> FFohgod [12:07:04] <cartman> For F*ck's Sake MPEG [12:07:17] <mru> kierank: FFomg? [12:07:24] <mru> wtFF [12:07:25] <kierank> yes [12:07:40] <kshishkov> but av500 thinks that the most important codec there is Bink, not MPEG-[124] [12:08:20] <kierank> the most important codec is lego audio [12:08:45] <kshishkov> indeed [12:08:56] <kshishkov> and there's libavseq [12:14:59] <mru> jannau: what were the magic headers patchwork reacts to? [12:15:35] <kshishkov> mru: subject=open sesame [12:17:25] <{V}> jannau, thanks. Not quite as long ago as I thought. [12:21:28] <jannau> mru: X-Patchwork-State: Accepted [12:21:55] <jannau> or Rejected or Changes Requested [12:22:12] <jannau> the state is case sensitive [12:22:47] * mru cooks up some emacs bindings for that [12:24:09] <superdump> ffsmeg [12:24:25] <kierank> ffspam [12:24:42] <superdump> mru: you use emacs? interesting [12:24:49] <superdump> for some reason i would have thought you would have used vim [12:24:59] <mru> vim doesn't read email [12:25:35] * mru was counting brackets before he could count his toes [12:25:48] <thresh> I've heard it has that cool feature other software misses: editing [12:25:53] <jannau> {V}: that were just 2 single mails with a pause of 1 1/2 years to the next [12:28:19] <{V}> jannau, yes, I did the search on gmane myself after you mentioned march 2010. Even in one of the march 2010 messages he says he no longer follows qemu development [12:29:20] <jannau> superdump: I use vim for composing mails and emacs for sources [12:29:44] <superdump> i use vim solely for text editing [12:30:12] <jannau> {V}: ah, I just looked at the dates [12:30:23] <superdump> gvim actually (mostly because i couldn't get inter-process c+p working using vim in a terminal) [12:31:23] <elenril> workfineforme in terminal [12:32:02] <superdump> it used to [12:32:12] <superdump> it's a user error somewhere, i just can't find it [12:33:08] <elenril> you just need to use the X register [12:33:41] <elenril> e.g. "+p to paste from X clipboard [12:33:56] <mru> I like how emacs can open frames on multiple displays [12:34:24] <mru> so can I move freely between desktop and laptop and keep on editing the same files / reading the same mail [12:34:54] <thresh> what, they even reinvented screen(1)? [12:35:14] <mru> ever heard of X? [12:35:18] <mru> as in X11 [12:35:33] <thresh> who needs that to read mail or edit files? [12:35:38] <elenril> why do you need X for editing text =p [12:35:56] <thresh> counter-troll, aha [12:36:06] <mru> I like it and that's all you need to know [12:36:31] <mru> besides, a little bit of lisp is fun from time to time [12:36:43] <wm4> I'm using kate, I guess that makes me totally uncool [12:37:09] <KotH> wm4: you should date her instead ;) [12:37:17] <mru> indeed [12:37:22] <mru> women don't like being used [12:37:42] <wm4> sorry I don't like it if women are implemented in C++ [12:37:45] <kshishkov> mru: because it's their responsibility? [13:27:57] <Dark_Shikari> http://i.imgur.com/XqSzl.jpg [13:30:26] <kierank_> ffmpeg leader criteria [13:31:08] <kierank> lol what a surprise, it's military [13:33:55] <mru> jannau: the patchwork header doesn't seem to work [13:38:49] <Zor> Dark_Shikari: that is some amazing typesetting right there [13:39:14] <jannau> mru: I'll look into it [13:51:08] <Dark_Shikari> BBB: the intra predict section might be cleaner if you just create two copies of intra_predict [13:51:11] <Dark_Shikari> with and without emuedge [13:51:47] <Dark_Shikari> almost none of the code would be duplicated [13:51:48] <Dark_Shikari> like 10% [13:51:54] <Dark_Shikari> it'd be faster too [13:54:57] <iive> sounds good to me. [14:09:03] <Tjoppen> http://en.wikipedia.org/wiki/Inter_frame pretty fancy [14:32:34] <cartman> Where is Rich Felker guy, he must have smell the flames by now [14:33:35] <mru> :) [14:33:44] <lu_zero> probably he's wiser today [14:34:31] <elenril> he lives in #mplayerdev permanently, ignoring us here [14:35:42] <cartman> elenril: he is alive?! [14:35:43] <cartman> damn [14:35:51] <andoma> i remember him! [14:36:03] <cartman> andoma: you bet you do [14:36:05] <andoma> .. and endless mail threads [14:36:06] <cartman> wise-ass Felker [14:36:30] <cartman> even Bill Gates probably wrote more code compared to him [14:36:31] <mru> the 3rd, don't forget that [14:37:07] <cartman> fortunaly first 2 didn't make it :P [14:41:28] <elenril> how about somebody warns/bans the trolls [14:41:30] <elenril> from the ML [14:41:44] <ohsix> then theres the naming problem [14:41:49] <cartman> elenril: I believe in one thing [14:41:53] <cartman> ignore them and eventually they die [14:41:54] <cartman> :P [14:42:21] <elenril> apparrently some people can't resist the temptation to respond [14:42:32] <cartman> I cancelled twice in two days :P [14:47:38] <BBB> Dark_Shikari: you mean intra_predict()? probably [14:47:45] <BBB> Dark_Shikari: grew that way because I thought it'd share more [14:47:52] <BBB> Dark_Shikari: first let me fix the aliasing issues [14:47:57] <BBB> I have the branch back to master now [14:48:04] <BBB> was working on porting patches from svn into branches [14:51:08] <elenril> srsly, now it's just дурак - сам дурак level [14:52:06] <kshishkov> elenril: so the first who quits it wins [14:52:23] <BBB> Dark_Shikari: email sent [14:52:36] <BBB> Dark_Shikari: will look into having two versions of intra_predict() as you suggested in a separate patch [14:53:04] <iive> elenril: trolls live longer than humans ;) [14:54:11] <elenril> i'm starting to really like the idea of moving the trolls to a separate ML [14:56:02] <{V}> elenril, under the guise of "non-development discussions go here" ? [14:56:43] <elenril> under the guise of "trolling not welcome on the dev ML" =p [14:57:35] <cartman> iive: you should be ashamed of yourself for trolling :P [14:58:26] <elenril> cartman: this is what happens to Cthulhu when the Great Old Ones return [14:59:01] <cartman> Arpi & Gabu always trolled for their whole life [14:59:57] <elenril> Ph'nglui mglw'nafh michaelni R'lyeh wgah'nagl fhtagn [15:00:10] <CIA-38> ffmpeg: Luca Barbato <lu_zero(a)gentoo.org> master * ra8475bbdb6 ffmpeg/libavformat/ (8 files): [15:00:10] <CIA-38> ffmpeg: os: replace select with poll [15:00:10] <CIA-38> ffmpeg: Select has limitations on the fd values it could accept and silently [15:00:10] <CIA-38> ffmpeg: breaks when it is reached. [15:00:16] <CIA-38> ffmpeg: Luca Barbato <lu_zero(a)gentoo.org> master * rf81c7ac70a ffmpeg/libavformat/ (rtsp.c rtspdec.c): [15:00:16] <CIA-38> ffmpeg: rtsp: make ff_sdp_parse return value forwarded [15:00:16] <CIA-38> ffmpeg: the sdp demuxer did not forward it at all while the rtsp demuxer assumed [15:00:16] <CIA-38> ffmpeg: a single kind of error [15:06:19] <uau> kshishkov: btw there are better reasons to switch to mplayer2 than the morons who were associated with the older version [15:06:21] <uau> like proper pause handling (can do things while the player stays paused), better matroska support including ordered chapters, improved VDPAU support, no use of internal ffmpeg symbols, exact non-keyframe-limited seeks, etc [15:06:50] <kshishkov> uau: well, they created it [15:07:10] <uau> yes they created it, but they had zero clue how to maintain software of the size they created [15:07:49] <cartman> uau: there is mplayer2?! [15:08:16] <uau> cartman: the git tree [15:08:26] <cartman> damn I missed it [15:08:32] <cartman> uau: maintained by you? [15:08:34] <kshishkov> uau: you mean that glue between hacked libs? [15:08:55] <uau> cartman: there's no release as mplayer2 yet (though should be soon) [15:09:05] <cartman> uau: just give me the git :D [15:09:09] <siretart> google already reports about 659.000 results for "mplayer2" :-) [15:09:19] <cartman> I thought your branch was for i18n work only [15:09:35] <elenril> siretart: lol [15:09:47] <elenril> cartman: http://repo.or.cz/w/mplayer.git [15:09:56] <cartman> elenril: cheers :) [15:10:06] <uau> better use mplayer-build.git in most cases [15:10:18] <elenril> yeah, was just going to suggest that [15:10:19] <elenril> http://repo.or.cz/w/mplayer-build.git [15:10:47] <uau> cartman: btw i think i already mentioned the git when talking about the translations before [15:11:04] <cartman> uau: yeah I thought it was for i18n changes only [15:11:40] <siretart> uau: is there a windows port of mplayer2? [15:11:47] <cartman> this is what happens when you don't blog about these cool things :P [15:11:58] <siretart> I see a lot of reports in google complaining about issues in MPLAYER2.EXE [15:12:40] <cartman> siretart: yes thats the windows classic media player [15:12:54] <uau> siretart: kovensky has done some windows builds - his last public build is from almost a year ago, i know he's worked on things since then, but i'm not sure about the current state [15:13:10] <wm4> way too many <something>mplayer<something> out there... [15:13:22] <Kovensky> 12:11.58 siretart: I see a lot of reports in google complaining about issues in MPLAYER2.EXE <-- that's microsoft's ancient windows media player 6.something [15:13:28] <siretart> obviously my trolling against the name 'mplayer2' was too subtle... [15:13:49] <elenril> siretart: we're using to more obvious trolls these days [15:13:51] <uau> siretart: would you prefer just "Mplayer 2" then? [15:14:09] <superdump> no [15:14:15] <superdump> mplayer-uau is more unique :) [15:14:22] <superdump> mplayer2 is a bad idea though [15:14:27] <Kovensky> mprayer [15:14:30] <microchip_> or uplayer ;) [15:14:31] <superdump> too much noise in google results [15:14:31] <wm4> uau: will you use a different binary filename too? [15:14:39] <cartman> uplayer sounds nice [15:14:46] <wm4> nouplayer [15:14:49] <uau> superdump: i might not maintain it forever though... [15:15:06] * siretart also likes uplayer. or nuplayer [15:15:11] <superdump> uplayer already exists [15:15:16] <microchip_> grrr [15:15:19] <microchip_> fuck em [15:15:30] <iive> nuplayer is really nice. [15:15:35] <lu_zero> uplayer was a nice name [15:15:40] <iive> it sounds like new player [15:15:42] <lu_zero> eplayer maybe? [15:15:44] <superdump> iPlayer [15:15:46] <elenril> νplayer? [15:15:56] <wm4> "mplayerx"? [15:15:57] <uau> wm4: i don't intend to change filename immediately at least, to keep things compatible with GUIs [15:15:57] * elenril stabs superdump [15:16:12] <siretart> iive: that's what I had in mind :-) [15:16:25] <kierank2> New mplayer [15:16:25] <microchip_> µplayer :D [15:16:27] <kierank2> like New Labour [15:16:31] <lu_zero> I'd keep it mplayer till it's a drop-in replacement though [15:16:42] <iive> wm4: there is already mplayer-xp [15:16:45] <wm4> uau: could provide a compatibility symlink as well [15:16:47] <siretart> uau: which also means that "your" mplayer cannot be installed together with the existing mplayer package [15:17:24] <wm4> mplayer-uau lol [15:17:26] <uau> lu_zero: hmm? did you mean something else? that sentence doesn't make sense to me [15:17:26] <lu_zero> siretart: if it's a drop-in replacement eselect/alternate would take care of it? [15:17:35] <jai> iive: nick doesn't really maintain it iirc [15:17:47] <iive> jai: still, it exists. [15:17:51] <lu_zero> I'd keep the name mplayer for the executable [15:18:30] <lu_zero> at least until you change it's interface (command line/ command pipe protocol) [15:18:33] <siretart> hm, yes, playing with alternatives is an option. I just don't like alternatives in general, because it is a system wide setting and I'm kinda used to multi-user systems here [15:18:36] <uau> lu_zero: that "till" didn't make sense IMO - use a different name if it's NOT? [15:18:53] <uau> i guess you meant "while" then [15:18:56] <superdump> anyway, this is discussion for #mplayerdev i guess [15:18:59] <elenril> siretart: time to extend alternatives? [15:19:06] <lu_zero> uau: I guess so [15:19:07] <siretart> oh, indeed. let's move this discussion [15:19:07] <elenril> to be usable by normal users [15:19:11] <uau> superdump: there's already #mplayer2-dev [15:19:17] * lu_zero runs [15:19:19] <lu_zero> bbl [15:19:21] <superdump> as you please [15:20:21] <Kovensky> unrelated fact: "uau" means "wow" in portuguese (probably japanese too) [15:20:24] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r9d4bdcb714 ffmpeg/libavcodec/vp8.c: [15:20:24] <CIA-38> ffmpeg: Fix VP8 aliasing problems. [15:20:24] <CIA-38> ffmpeg: Replace * (uint32_t *) buf accesses with AV_WN32A/AV_COPY32. [15:25:12] <pJok> gotta love avisyth sometimes: Stream #0.1: Audio: pcm_f32le, 48000 Hz, 11873 channels, 1057058 kb/s [15:25:45] <pJok> and i didn't know that ffmpeg supported 11873 channels [15:26:18] <spaam> nice bitrate [15:26:49] <pJok> indeed [15:26:51] <microchip_> pJok: must have been designed for aliens with gazillion ears :p [15:27:14] <pJok> it is supposed to be a silent audiotrack [15:27:45] <mmu_man> then you'll get lots of silences :) [15:41:46] <kierank> anybody know anything about igmp [15:42:01] <kshishkov> google does [15:42:51] <kierank> of course [15:42:55] <cartman> it pings [15:43:40] <cartman> j-b: vlc on Galaxy Tab looks good [15:45:55] <cartman> uau: on OSX with mplayer-build.git: --cpu=host not supported with compiler gcc [15:46:27] <uau> cartman: ancient OS X gcc i assume [15:46:34] <cartman> uau: gcc 4.2.1 [15:46:37] <Compn> cartman : got latest xcode ? [15:46:49] <cartman> sure --cpu=core2 works fine [15:47:21] <cartman> I bet it doesn't extract host correctly [15:47:40] <uau> cartman: mplayer-build uses ffmpeg's build system [15:48:06] <jannau> cartman: I think -march=native was introduced in 4.3 [15:48:06] <uau> and ffmpeg does not have hacks to determine cpu with compilers that lack support [15:48:27] <Kovensky> cartman: I workaround it by commenting out the --cpu=host line on the ffmpeg-config script [15:48:28] <uau> i haven't added custom code to work around that [15:48:51] <uau> cartman: add --cpu=core2 or whatever in ffmpeg_options [15:48:54] <jannau> and that's that ffmpeg uses to extract the host cpu [15:49:18] <Compn> does fate have an osx box ?> [15:49:31] <Compn> or just mac-intel / ppc-linux [15:49:38] <cartman> okies :) [15:49:52] <uau> Compn: ffmpeg will compile if you leave out cpu-specific optimization completely [15:50:22] <uau> so fate would likely work [15:50:27] <Kovensky> I do have plenty of CPU time for running fate on this computer but I can't guarantee uptime or long-term stability =p [15:50:44] <Kovensky> (hackintosh) [15:51:05] <Kovensky> (CPU is a mostly unused i5 750, except when gaming (zomg)) [15:52:27] <Compn> uau : oh, these arent the default thing breaking ? [15:52:38] <Compn> anyways, a roundup issue might be worth it [15:52:54] <Kovensky> not really [15:53:06] <Kovensky> there are only three "sane" behaviors [15:53:11] <Kovensky> one is to upgrade your compiler [15:53:23] <Kovensky> the other is to whine if you give the flag that will break on the compiler until you remove [15:53:26] <uau> Compn: no - it's the ffmpeg "--cpu=host" switch erroring out if the compiler lacks support [15:53:30] <Kovensky> the other is to whine about the flag but compile it anyway [15:53:39] <Kovensky> the latter is clearly bordering on insane [15:53:50] * cartman has gcc 4.6 trunk too [15:53:57] <cartman> maybe I should just use clang ;) [15:54:02] <Kovensky> it could also just not whine and ignore the --cpu=host flag, but I don't think that's standard practice =p [15:54:18] * Kovensky wonders how reliable is clang++ nowadays [15:54:28] <Kovensky> it can compile ffms2 too, but I didn't do any extensive testing [15:54:32] <Compn> uau : so shouldnt there be a compiler test for that switch ? [15:54:40] <Kovensky> (1.7 couldn't, newer revisions can) [15:54:45] <Compn> checking to see if gcc is dumb .... yes [15:55:19] <Kovensky> Compn: if there isn't a compiler test for that switch, then it'll just put -march=native on the CFLAGS, fail every subsequent test, and if it does manage to finish configuring, make will instafail [15:55:52] <uau> Compn: you mean a separate test in the build repo scripts? it doesn't do such testing now, and doing two levels of tests could get ugly [15:56:16] <Kovensky> uau: nah, he was thinking it was a ffmpeg bug [15:56:27] <Compn> yes, in ffmpeg i mean [15:56:32] <Compn> not your script [15:56:52] <uau> Compn: i think it tests now and gives the error above if the compiler fails [15:56:55] <Compn> ah [15:56:58] <Compn> fair enough [15:57:52] <Kovensky> so, does anyone want me to run fate on this could-be-unreliable-since-I-need-to-reboot-once-in-a-while-to-ressuscitate-one-of-my-old-HDDs-so-I-can-rescue-data-from-it-but-I-try-to-keep-uptime hackintosh? or do you have enough osx boxes? [15:58:09] <cartman> configure.ac:33: error: possibly undefined macro: AC_DEFINE [15:58:12] <cartman> fsck [15:58:22] <Kovensky> cartman: msys? [15:58:29] <cartman> Kovensky: OSX :P [15:58:38] <Kovensky> lol [15:58:41] <Compn> Kovensky : a cross-compile mingw would be better, since ramiro has left [15:58:43] <Kovensky> I still didn't hit autotools issues here ._. [15:58:50] <uau> cartman: missing some autotools stuff required by libass probably [15:58:53] <Kovensky> Compn: eventually :) [15:58:58] <cartman> uau: seems so *sniff* [15:59:05] <Kovensky> Compn: http://github.com/Kovensky/AutoMinGW <-- gonna go back to working on it this weekend [15:59:12] <jannau> Kovensky: x86 darwin gcc is missing [15:59:13] <Kovensky> ramiro ragequit? [15:59:24] <Kovensky> jannau: I'm on x86-64, but that can be fixed with an -m32 [15:59:33] <Compn> Kovensky : read the autobuilds site [15:59:43] <jannau> Kovensky: I meant x86* [15:59:51] <uau> cartman: btw most of the compiling discussion would probably be more appropriate for #mplayer2 / #mplayer2-dev [16:00:11] <cartman> uau: I like keeping this channel off topic :D [16:00:21] <jannau> but x86_32 might be also a good idea [16:00:48] <cartman> uau: libass depends on pkg-config bleh [16:01:12] <uau> you'll need pkg-config anyway [16:01:50] <uau> at least to pass required flags from ffmpeg to static link the player (doing that sanely without pkg-config just wouldn't work...) [16:02:18] * cartman cp's pkg.m4 [16:02:23] <Kovensky> jannau: how large are the vectors [16:03:12] <jannau> ~400M currently [16:05:06] <Kovensky> jannau: are there any setup instructions? [16:08:07] <cartman> and it compiles :) [16:08:29] <jannau> Kovensky: http://wiki.multimedia.cx/index.php?title=FATE [16:14:42] * Kovensky leaves the rsync job running and goes to the last day of his internship [16:38:28] <mru> lu_zero: ping [16:50:08] <mru> the poll patch broke dos and os/2 builds [16:52:08] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r3e5bc7ff6a ffmpeg/libavfilter/vf_setpts.c: [16:52:08] <CIA-38> ffmpeg: In the start_frame() debug log, print the reference pos value rather than the evaluated value converted to int. [16:52:08] <CIA-38> ffmpeg: That's required because -1 is evaluated as NAN, which converted back [16:52:08] <CIA-38> ffmpeg: to int looks like a random number, this is especially annoying when [16:52:09] <CIA-38> ffmpeg: debugging sources with undefined pos (as the video4linux2 device). [16:52:09] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [16:52:10] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r3c802cabba ffmpeg/libavcodec/rawdec.c: [16:52:10] <CIA-38> ffmpeg: In the rawvideo decoder, set pkt_pts in the output frame. [16:52:11] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [16:52:11] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r85466e1e5f ffmpeg/doc/ (ffmpeg.texi ffplay.texi ffprobe.texi muxers.texi): [16:52:12] <mru> ah, looks like a missing update in os_support.h [16:52:12] <CIA-38> ffmpeg: Add muxers.texi file. [16:52:12] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [16:52:21] <CIA-38> ffmpeg: Georgi Chorbadzhiyski <gf(a)unixsol.org> master * ra7827a17c6 ffmpeg/libavformat/mpegtsenc.c: [16:52:21] <CIA-38> ffmpeg: In mpegts "reserved_future_use" field must be set to 1 in SDT table [16:52:21] <CIA-38> ffmpeg: According to EN 300 468 section 3.1 (Definitions): [16:52:21] <CIA-38> ffmpeg: Unless otherwise specified within the present document all [16:52:21] <CIA-38> ffmpeg: "reserved_future_use" bits is set to "1". [16:52:21] <CIA-38> ffmpeg: This was not the case for SDT generation so this patch fixes it. [16:52:22] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [17:01:25] <CIA-38> ffmpeg: Alex Converse <alex.converse(a)gmail.com> master * re5c82df80e ffmpeg/libavcodec/aacdec.c: [17:01:25] <CIA-38> ffmpeg: aacdec: Convert some loop copies into memcpy()s. [17:01:25] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:03:13] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r79dca23dc2 ffmpeg/tests/ref/lavf/ts: [17:03:13] <CIA-38> ffmpeg: Update mpegts test reference [17:03:13] <CIA-38> ffmpeg: The output was changed by a7827a17c6b3388322350456d445c94b3a82cd25. [17:03:13] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:04:26] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r4fc9ff0ad6 ffmpeg/libavformat/img2.c: [17:04:26] <CIA-38> ffmpeg: Make the image2 demuxer log more verbose [17:04:26] <CIA-38> ffmpeg: Add an error message in case the user requests to write more than one file [17:04:26] <CIA-38> ffmpeg: and the path does not contain a "%d" or "%0Nd" pattern. [17:04:26] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [17:21:34] <jannau> Dark_Shikari: ping [17:24:03] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r362d8f7d9e ffmpeg/libavformat/ (os_support.c os_support.h): (log message trimmed) [17:24:03] <CIA-38> ffmpeg: os_support: make poll() fallbacks conditional on CONFIG_NETWORK [17:24:03] <CIA-38> ffmpeg: poll() is only used by networking code, so the fallback should [17:24:03] <CIA-38> ffmpeg: only be built if networking is enabled. Also remove CONFIG_FFSERVER [17:24:03] <CIA-38> ffmpeg: condition from the declarations. [17:24:04] <CIA-38> ffmpeg: This should fix building on systems without poll(), broken [17:24:05] <CIA-38> ffmpeg: by a8475bbdb64e638bd8161df9647876fd23f8a29a. [17:25:23] <BBB> saste: ping [17:27:18] <saste> BBB: pong [17:27:32] <BBB> \o/ [17:53:13] <elenril> o_0 37 new mails in two hours? [17:53:27] * elenril guesses it's all hugs and puppies [17:53:49] <jannau> I think it's mostly review and patch mails [17:54:07] <elenril> on ffmpeg-devel? inconceivable! ;) [17:54:17] <elenril> michaelni: ping [17:54:26] <mru> our new strategy: drown the trolls in patches [17:54:43] <elenril> i like it [17:54:47] <jannau> and get on gmane.org's top ten list [17:55:06] <elenril> too bad i don't see any easy metadata work :) [17:55:18] <mru> then do some metawork [17:55:55] * elenril has to prepare for QFT exam anyway [17:56:28] <mru> quantum flux trolling? [17:56:50] * jannau doesn't trust the top ten list btw. http://dir.gmane.org/gmane.comp.hardware.beagleboard.general is on [17:57:27] <mru> there is some correlation to reality [17:57:30] <mru> but it's weak [17:57:38] <elenril> quantum field theory [17:57:43] <elenril> the evilest of all evils [17:58:03] <mru> iKnow [17:58:13] <elenril> (and a giant hack too) [17:58:17] <mru> that's it's evil, I don't know it [17:58:42] <mru> physics is nought but a hack [17:59:13] <mmu_man> yeah who's flooding my mailbox ? [18:39:46] <BBB> kshishkov: what was the review of the rm-multirate patch again? I've ported it to HEAD and it still works [18:40:00] <BBB> kshishkov: If you review I'll try to find someone to implement the missing features so we can apply it [18:53:21] <Compn> BBB : does seeking work with it ? [18:53:34] <Compn> is this mulitrate demuxer or multirate over rtsp ? [18:53:43] * Compn not paying attention [19:01:14] <skal> *yawn* [19:01:19] <skal> good mourning [19:01:36] <mru> hi skal [19:02:01] <skal> hey mru [19:03:41] <kierank> pffft centos has next to no packages :/ [19:04:00] <kshishkov> thresh: ^^^ see how civilised people feel about time before noon [19:04:05] <mru> kierank: isn't that point? [19:04:08] <kshishkov> BBB: I'll try to review it [19:04:11] <lu_zero> hi skal [19:04:22] <mru> it's a wannabe enterprise distro [19:04:26] <kierank> mru: dunno [19:04:32] <mru> and enterprise apps take over the entire machine anyway [19:04:41] <mru> no point installing anything separately [19:05:43] <lu_zero> is anybody on darwin/macosx? [19:05:50] <lu_zero> j0sh: ? [19:05:57] <kierank> I think we should have a daily ffmpeg drama newsletter [19:06:14] <kierank> executive summary of the goings on [19:07:47] <elenril> kierank: http://i.imgur.com/eSmOS.jpg [19:07:54] <elenril> here's your executive summary [19:07:59] <kshishkov> BBB: where is it? [19:11:29] <mmu_man> elenril eh, and it's trollday today :) [19:12:01] * {V} hoped it was friday [19:12:37] <thresh> kshishkov: you mean they already killed all the morons and now mourn them? [19:13:08] <kshishkov> thresh: could be (but not in Russia ever) [19:13:37] <mru> thresh: that's mouroning [19:15:10] <kshishkov> mru: you have shotgun, please fix this world [19:15:23] * mru curses gcc [19:15:34] <kshishkov> it's cursed already [19:15:48] <kshishkov> and probably not only because of Stallman's bite [19:17:00] <iive> try to ncurse it [19:17:37] <lu_zero> mru: what's wrong now? [19:18:08] <{V}> iive, adding dependencies to gcc does not seem like a good idea to me :p [19:18:29] <mru> lu_zero: I wrote some inline asm for the vp56_rac functions [19:18:36] <mru> now if I remove said asm again, it crashes [19:18:59] <mru> building same code with armcc is fine [19:19:30] <mru> and works on x86 [19:21:04] <lu_zero> O_o? [19:21:22] <lu_zero> strange [19:31:12] <BBB> kshishkov: I'll send it tonight [19:31:13] <BBB> brb [19:31:27] <kshishkov> ok [19:35:37] <kierank> wow mike on irc [19:35:54] <kierank> two michael's i've never seen on irc before [19:39:36] <MultimediaMike> So you weren't here last night [19:39:57] <Dark_Shikari> jannau: pong [19:40:09] <mru> found the problem [19:40:42] <MultimediaMike> You know, back in the day, most of the multimedia hackers were named Mike [19:41:20] <kshishkov> back in what day? [19:41:41] <MultimediaMike> First half of 2000s [19:41:58] <Dark_Shikari> BBB: were you going to clean up the rest of that stuff? [19:42:09] * kshishkov remember only Mike, Michael and Michel [19:42:39] <lu_zero> hi MultimediaMike =) [19:42:50] * mru wishes there were a michelle [19:43:14] <MultimediaMike> On xine, 75% of the project leaders were named Mike [19:43:28] <in3xes> If there are so many undisclosed formats how you guys managed to put them in ffmpeg? Reverse Engineering? [19:43:41] * mru looks at MultimediaMike [19:43:52] <MultimediaMike> Mike,Miguel, and Michael [19:43:59] <MultimediaMike> Different Michael [19:44:00] <{V}> lu_zero, vmrsss said the git.videolan version builds with --disable-filter=mp and as far as I know that almost the only difference between the two repos [19:44:01] <elenril> mru: http://tvtropes.org/pmwiki/pmwiki.php/Main/ThereAreNoGirlsOnTheInternet [19:44:10] <elenril> here, have a trope instead [19:44:38] <kshishkov> MultimediaMike: for me Xine is just DVD player project [19:44:47] <mru> elenril: I know a few girls on the internet [19:44:53] <mru> ones I've met in real life [19:44:59] <mru> so I know they're not something else [19:45:03] <MultimediaMike> Yep, reverse engineer as necessary [19:45:15] * mru prefers sideways engineering [19:45:58] <MultimediaMike> A colleague always used to remind me that forward engineering was superior [19:46:41] <kshishkov> but equally hard to find [19:47:18] <iive> MultimediaMike: he may suffer from nih syndrome. [19:48:08] <MultimediaMike> No, he just thought my RE exploits were silly [19:48:28] <elenril> re is fun [19:50:10] <MultimediaMike> And so educational [19:50:21] <mru> reverse education [19:51:15] <MultimediaMike> I contend that the fastest was to learn an ASM is to RE something [19:51:21] <kshishkov> mru: judging from education people usually get it's an improvement [19:51:51] <mru> MultimediaMike: is there any other way? [19:51:56] <MultimediaMike> Trying to learn ARM ASM that way [19:52:09] * mru learned z80 by reading hex dumps [19:52:26] <mru> then editing the code in place to do what I wanted [19:52:47] * kshishkov never had 8- or 16-bit machine [19:52:50] <MultimediaMike> @mru read books that don't make a lot of sense out of context [19:55:14] <MultimediaMike> I painstakingly learned x86 16-bit from books [19:55:22] <MultimediaMike> Then forgot [19:55:42] <mru> the only books on such things I've ever read are arch ref manuals [19:55:42] * kshishkov has not managed to learn x86 asm from any of his two books [19:55:49] <MultimediaMike> Then remembered quickly when starting. RE [19:56:03] <ruggles> i had to learn SPARC asm in college. all i remember is that i hate m4. [19:56:06] <kshishkov> mru: well, there are few geniuses (like you) out there [19:57:06] <MultimediaMike> @ruggles. You had to program in m4? [19:57:24] <ruggles> yeah. i guess the assembler had no preprocessor. [19:57:33] <ruggles> that or the prof liked m4 [19:57:46] <mru> sparc as such isn't all too bad [19:57:52] <mru> but they screwed up the 64-bit move a bit [19:57:53] * kshishkov fears that anything written in m4 would turn into autotools script [19:57:59] <MultimediaMike> I'M. relearning SH-4 [19:58:05] <mru> kshishkov: or a sendmail config file [19:58:24] <kshishkov> mru: and which is worse? [19:58:25] <mru> sh4 has a nice and small instruction set [19:58:49] <mru> kshishkov: unknown, nobody has read both and lived [19:58:50] <kshishkov> what SH-4 device can I buy for development? [19:58:50] <MultimediaMike> I will one day make ffmpeg and fate run on my Dreamcast [19:58:52] <lu_zero> kshishkov: autotools m4 isn't the worst m4 you would find around [19:59:12] <kshishkov> lu_zero: why would I ever search for such thing? [20:00:07] <lu_zero> kshishkov: not sure, sadism? [20:00:09] <mru> MultimediaMike: encountered the ftrv instruction yet? [20:00:11] <MultimediaMike> Kostya Dreamcast is cheap and easy to procure [20:00:32] <kshishkov> MultimediaMike: I hope it's not bulky [20:00:58] <MultimediaMike> But it's hard to program without the coder cable [20:01:28] <MultimediaMike> DC is a very small console [20:02:34] <kshishkov> hmm, a bit too slow for 720p H.264 [20:02:38] <mru> lu_zero: btw, os/2 is still failing [20:02:41] <MultimediaMike> @mru. Yeah I used the ftrv before [20:02:51] <lu_zero> ;_; [20:03:20] <mru> lu_zero: seems like rtspenc.c isn't including os_support.h [20:03:38] <MultimediaMike> DC SH-4 had some other custom instructions too [20:04:01] <kshishkov> reminds me of MIPS with each chip with its own SIMD [20:04:43] <MultimediaMike> Kostya indeed, the DC even struggled on basic MPEG 4 video [20:05:05] <MultimediaMike> Console came out in 1999 [20:09:06] <MultimediaMike> KOSTYA:You should probably ask that dev of ffmpeg-devel which sh4 board he is using [20:09:09] <mru> ruggles: I'll look at your fmtconvert patch in a while [20:09:37] <ruggles> ok, thanks. i know it's huge... mostly it's just moving code around though. [20:10:00] * j0sh is wiki'ing the dreamcast [20:10:29] <j0sh> apparently the OS came on disk with each game... that's pretty cool [20:10:57] <MultimediaMike> Omg you don't know the DC? :) [20:11:18] <mru> disks, bah! cartridges ftw [20:11:21] <j0sh> well i know it, just not the guts [20:11:29] <MultimediaMike> Minor footnote in gaming history by now, I guess [20:11:49] <j0sh> def looks like it'd be fun to hack on tho [20:12:26] <MultimediaMike> http://multimedia.cx/eggs/dreamcast-anniversary-programming/ [20:12:50] <MultimediaMike> A little post I did on that very topic [20:15:13] <j0sh> ...must resist the temptation to ebay [20:15:45] <j0sh> MultimediaMike: i got a crystalhd card because of the blogpost you made about one [20:15:56] <j0sh> i have yet to use it, lol [20:16:14] <MultimediaMike> What? Why would you do that? [20:16:18] <MultimediaMike> :) [20:16:23] * mru urges MultimediaMike to blog about something really expensive [20:16:31] <MultimediaMike> I couldn't make it work [20:17:09] <MultimediaMike> I don't know anyone who has made it work [20:17:24] <MultimediaMike> I guess that's not true [20:17:25] <j0sh> i have a pile of hardware in my "to hack with" pile that never goes down [20:17:41] <MultimediaMike> Yeah, same [20:18:17] <MultimediaMike> I still have a brand new vflash console, for 2 years [20:18:32] <mru> there are right now 9 arm boards on my desk [20:18:39] <MultimediaMike> Nice [20:18:56] <mru> that's the ones on my desk [20:19:26] <MultimediaMike> My only programmable ARM device is again. The SC [20:19:31] <MultimediaMike> DC [20:19:50] <mru> get a beagleboard or something [20:20:42] <MultimediaMike> I guess this nexus 1 I'm. Typing on right now might also count [20:20:42] * j0sh has a beagleboard too [20:21:03] <j0sh> i wanted to use it as a way to pick up neon [20:21:29] <mru> I have 2k lines of vp8 neon asm coming soon [20:21:34] <mru> you can review it :) [20:21:54] <j0sh> nice, is it based off that vp8 neon code dump that came a few months ago [20:22:56] <mru> yeah [20:23:06] <mru> not many lines are unchanged though [20:23:22] <j0sh> cool [20:23:59] <jannau> Dark_Shikari: reping, Have you seen my reply to the h264 profiles? High 4:4:4 Intra and Predictive use the same profile_idc [20:25:25] <Kovensky> heh, I wanna try my hand at neon too but no hardware [20:25:42] <Kovensky> hopefully I can get my hands on some during my EE course [20:26:06] <Dark_Shikari> jannau: and? [20:26:22] <Kovensky> does qemu count? :) [20:26:53] <_av500_> no [20:27:34] <Dark_Shikari> mru: askdjflaksjdfkasjdlfkajsdlfjasldkfjas;ldkfja;lskdj;flaksdjf;laksjdf;laksjd;flakjsdkfjasdkfjsdlfkj [20:27:43] <Dark_Shikari> intra predict in vp8 currently: ~2800 cycles [20:27:55] <Dark_Shikari> templated, based on emu_edge: ~3600 cycles (WTF?) [20:28:01] <Dark_Shikari> templated, but noinlined: ~2400 cycles [20:28:03] <Dark_Shikari> GCC [20:28:04] <Dark_Shikari> GCC [20:28:06] <Dark_Shikari> DIE [20:28:42] <_av500_> gcc rolls over and dies [20:29:54] <jannau> Dark_Shikari: they look identical to the profile code and the patch is imho ok [20:30:01] <Dark_Shikari> er... [20:30:08] <Dark_Shikari> profile is not only determined by profile_idc [20:30:14] <Dark_Shikari> profile_idc is a syntax element [20:30:18] <Dark_Shikari> It is one of the things used to calculate profile [20:30:31] <Dark_Shikari> It is the job of ffmpeg to Do The Right Thing and calculate the correct profile and export it. [20:30:54] <jannau> it's currently the only thing that sets profile in avcodeccontext [20:31:13] <Dark_Shikari> Then avccodeccontext should be fixed. [20:31:35] <Dark_Shikari> er, the code should be [20:31:39] <Dark_Shikari> if we're giong to export the profile we should do it correctly [20:32:28] <jannau> ok [20:33:00] <BBB> Dark_Shikari: you mean split intra_predict()? [20:33:07] <BBB> Dark_Shikari: eventually, yes, but working on something else first [20:33:41] <Dark_Shikari> ugh I can't bench anything [20:33:44] <Dark_Shikari> everything is giving crazy results [20:33:45] <BBB> but if you do it already :-p [20:34:41] <_av500_> Dark_Shikari: btw, the h264 encoding that merbzt was bugging you about [20:34:50] <_av500_> it was the decoder [20:35:01] <_av500_> and its fixed now [20:35:22] <Dark_Shikari> lol [20:35:59] <_av500_> Dark_Shikari: today they delivered a bugfis for their mp3 decoder... [20:36:09] <Dark_Shikari> lol [20:36:13] <_av500_> yep [20:36:15] <merbanan> _av500_: who ? [20:36:22] <_av500_> merbanan: them [20:36:30] <merbanan> ok [20:42:04] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r042950542d ffmpeg/libavformat/asfdec.c: [20:42:04] <CIA-38> ffmpeg: asfdec: ensure that the whole tag is read. [20:42:04] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:42:15] <CIA-38> ffmpeg: Dave Yeo <daveryeo(a)telus.net> master * ra0788cc627 ffmpeg/libavformat/rtspenc.c: [20:42:15] <CIA-38> ffmpeg: rtspenc: include os_support.h for system without HAVE_POLL_H [20:42:15] <CIA-38> ffmpeg: fix compile on OS/2 [20:42:15] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:56:40] <Kovensky> lol, rsync apparently refuses timeouting [20:56:52] <Kovensky> it still hadn't finished getting the vectors, I had to kill and restart it [20:57:02] <Kovensky> it's now apparently going normally [20:57:08] * Kovensky should have sshed sooner [21:04:48] <soroushi> Hi, what is the behavior of swscale if the input video is interlaced and I ask for half width: 720 -> 288, will it just discard one field and return the other? [21:05:11] <soroushi> err 576 -> 288 [21:05:55] <mru> did you mean height? [21:06:07] <soroushi> yes, height [21:06:43] <iive> soroushi: no [21:06:58] <iive> you can use tfields and crop to do that [21:07:54] <iive> ops, fil or il filters and crop [21:08:07] <Vitor1001> BBB: your PPC patch breaks "make fate-vp8" in a previously working build [21:08:10] <soroushi> I am using it in VLC and can set just mode parameter [21:08:41] <iive> soroushi: if scale is instructed it would separate both fields, scale fields separately and then produce the resulted frame. [21:09:24] <iive> this is the correct behaviour, because in real interlace frames it would cause color from one field bleeding into the other. [21:09:28] <BBB> Vitor1001: so I heard, disregard it (I haven't applied it, have I?) [21:09:40] <BBB> Vitor1001: I'd like to figure out what is broken right now though [21:09:45] <BBB> if anyone can debug it that'd help a lot [21:09:49] <Vitor1001> No, last time I saw it you were looking for someone to test [21:10:04] <Vitor1001> Ask mru for a ppc account in his box [21:10:08] <BBB> I sent an update patch that has brackets :) [21:10:14] <BBB> mru says it's not broken on his box [21:10:20] <BBB> so then I can't test that my patch fixes it... [21:10:30] <Vitor1001> At least you can test if it doesn't break anything [21:10:45] <soroushi> iive: I can't play with other than mode parameter with VLC, thanks anyway [21:13:39] <iive> soroushi: hum, sorry, wrong channel, swscale won't do that automatically. you have to do it. bilinear filter doesn't discart pixels, nearest neighbour may do it. [21:15:18] <Kovensky> so bilinear will effectively crappily deinterlace the source? [21:15:56] <mru> fields should be scaled separately [21:16:08] <mru> and care should be taken of chroma positions [21:16:31] <soroushi> indeed, I use separatefields().selecteven().AssumeFrameBased() in avisynth and it give clear image and tried 10 mode of swscale and nearest neighbour gave the best image [21:16:40] * Kovensky hopes h265 will finally kill interlacing [21:17:13] <mru> didn't someone on this channel invent "russian interlacing" a few days ago? [21:17:47] <Kovensky> thresh? [21:17:54] <mru> or kshishkov [21:17:54] <kierank3> it interlaces you somehow? [21:18:17] <iive> soroushi: skipping half the fields is not good way to scale down height. It would create visible staircase artifact on diagonal edges. [21:18:34] <iive> i mean, skipping half the lines. [21:20:01] <soroushi> iive: my video do not many of them and I can live with it [21:20:44] <soroushi> iive: I also have moving subtitle that discard field gives best quality [21:21:14] <soroushi> and in swscale the best was nearest neighbour for that subtitle [21:22:07] <iive> soroushi: dropping interlaced fields is OK. [21:22:26] <iive> well, not really... [21:22:37] <mru> better than dropping lines in general [21:22:50] <mru> it shouldn't make aliasing any worse [21:22:57] <jannau> Dark_Shikari: patches sent with proper annotation for high 4:4:4 predictive, constrained baseline and Intra profiles [21:23:44] <mru> can we please stop writing "foo= bar"? [21:23:50] <mru> and write "foo = bar" instead [21:23:52] <soroushi> I will force upscaling later when video display and discard field and its nearest equivalent method in swscale gives better quality, especially for that subtitle [21:24:08] <kierank3> mru: oh god yes finally [21:24:23] <soroushi> iive: nearest equivalent(nearest neighbour) * [21:25:09] <mru> kierank3: what happened to 1 and 2? [21:25:14] <jannau> mru: I would gladly, just adjusted to neighbouring code [21:25:31] <mru> jannau: there's sane code rigth beside it [21:25:34] <mru> just do it [21:25:49] <mru> if you like consistency, fix the ugly code in a separate commit [21:26:26] <kierank> kierank1: :D [21:26:50] <kierank1> hmmm i wonder why my other pc lost connection [21:26:57] <mru> someone forgot to register his nick... [21:27:18] <spaam> kierank is registered [21:27:26] <kierank> kierank also :) [21:29:10] <jannau> fixed locally. I won't change surrounding code now, michael will just complain over cosmetics [21:29:27] <mru> let him [21:29:38] <lu_zero> jannau: clean code is better code. [21:29:50] <mru> this code is mostly maintained by Dark_Shikari and pengvado [21:29:57] <mru> I'm sure they both prefer it clean [21:30:51] <mmu_man_> so which git should I clone now ? [21:30:58] <mmu_man_> </troll> [21:31:02] <soroushi> speaking of upscaling, in some containers like flv and mp4 there is meta data that can be set to set different dimensions than real dimensions of video, onMetaData() in flv and tkhd in mp4 but players based on libavformat and libavcodec(ffplay, mplayer, vlc) do not obey meta dimensions [21:31:12] <mru> mmu_man_: whichever works better for you [21:31:15] <kierank> elenril ^ [21:31:49] <soroushi> flash obey dimensions set in onMetaData in flv but not in tkhd in mp4 [21:32:03] <mmu_man_> mru: <troll>like, the one I can push BeOS patches to ?</troll> [21:32:08] <kierank> lol [21:32:09] <soroushi> and quick time seems to obey dimensions set in tkhd [21:32:13] <spaam> mru: i cant kill my comrade in CDGS.. the member count will drop... ;S [21:32:18] <mru> mmu_man_: send patches and I'll review [21:32:23] <mmu_man_> eh [21:32:30] <lu_zero> mmu_man_: send patches and provide an haiku fate [21:32:44] <mmu_man_> well I shall rewrite the a/v native input someday [21:33:05] <lu_zero> it would have to be in C++ ? [21:33:11] <mmu_man_> as for BeOS stuff I have a somehow working build, for that I can just set up one on github [21:33:22] <mmu_man_> lu_zero: yes, the MediaKit API is C++ [21:33:41] <mru> mmu_man_: http://www.flickr.com/photos/av500/4767125825/ [21:33:43] <lu_zero> no plain C bindings? [21:33:47] <mmu_man_> lu_zero: I don't believe the beosaudio.cpp ever caused any other platform trouble, did it? [21:34:05] <mmu_man_> lu_zero: no, Haiku is a forward looking OS :P [21:34:05] <lu_zero> mmu_man_: I have a patch for a C++ avdevice [21:34:24] <lu_zero> mmu_man_: so I could use python ctypes bindings ^^; [21:34:40] <mmu_man_> well we already use lavc and lavf in our MediaKit plugins btw [21:34:50] <lu_zero> mmu_man_: jokes aside [21:35:18] <mmu_man_> mru: Eternal curse on you all :P [21:35:29] <mmu_man_> OMG, you did that on a mac [21:35:33] <lu_zero> I the decklink patch added somehow the CXX bits I needed [21:35:59] <mmu_man_> ROTFL a Mac with an FSFE fellowship sticker [21:36:08] <lu_zero> and shouldn't be a problem [21:36:40] <mru> if anything needs libstc++ or libgcc_eh there will be problems [21:36:41] <mmu_man_> OMG, if all those phishing emails claiming my ISP ows me 89EUR were right I'd be rich [21:37:11] <mmu_man_> why so ? [21:37:26] <lu_zero> mru: if the base runtime is that one for everything, it shouldn't [21:37:37] <mmu_man_> well the BeAPI doesn't use templates, std::* or exceptions, so... [21:37:43] <lu_zero> mmu_man_: on linux linking to libstc++ is begging for troubles [21:37:45] <mru> lu_zero: if something needs those, you need to link with g++ [21:38:01] <lu_zero> mru: I know =| [21:38:37] <mru> and switching link command depending on some avdevice being on or off gets ugly quickly [21:38:46] <mru> especially if building shared libs [21:38:56] <mmu_man_> lu_zero: I suppose it's just because Linux freaks are afraid of it and thus do wrong things [21:39:06] <mmu_man_> you always fear what you don't know [21:39:32] <mru> yes, I don't know why, and it scares me [21:40:00] <lu_zero> mmu_man_: more because libstdc++ by itself is ... icky [21:40:16] <mmu_man_> I don't recall having much problem on BeOS with it [21:40:45] <lu_zero> mmu_man_: sorry... as fellow beos user I recall gcc2 vs gcc3 [21:40:54] <mmu_man_> more probably because it was a separate lib in the OS and not left with gcc at the time [21:41:03] <lu_zero> and haiku had it's share of fun with gcc3 vs gcc4 [21:41:09] <mmu_man_> lu_zero: that's != [21:41:13] <mmu_man_> it's about ABI changes [21:41:35] <mmu_man_> mostly name mangling [21:41:43] <lu_zero> mmu_man_: not just that [21:42:03] <mmu_man_> vtable fmt and such [21:42:12] <Compn> oh egypt pulled the bgp [21:42:20] <mmu_man_> yeah [21:42:27] <mru> Compn: border gateway plug? [21:42:34] <lu_zero> as gentoo developer I had my share of pain because gcc-3 had some subtle changes not even versioned... [21:42:35] <Compn> protocol [21:42:38] <Compn> :) [21:42:51] <mmu_man_> FDN (French Data Network) has set up free dialup access in France for them [21:43:01] <Compn> the phones still work? :P [21:43:04] <mmu_man_> http://www.fdn.fr/ [21:43:09] <Compn> and they called everyone ? :P [21:43:21] <mmu_man_> I heard they were cut as well but I'm not sure [21:43:31] <lu_zero> Compn: land phones so far should be fine [21:43:32] <mmu_man_> at least they werent earlier when they set this up [21:43:37] <lu_zero> cellphones got cut [21:43:54] * lu_zero wonders about mesh-networking [21:44:11] <Compn> does your isp have mesh networking lu_zero ? [21:44:16] <mmu_man_> http://reflets.info/egypte-chronique-dun-massacre-pas-ordinaire-jan25-live/ [21:44:22] <Compn> e.g. just local isp customers to each other local-net [21:44:26] <mmu_man_> some have set up a HAM radio link [21:45:23] <mru> then it won't be long before we have SPAM radio [21:45:33] <mmu_man_> :))) [21:46:25] * Compn eats one can of spam per year [21:46:28] <lu_zero> Compn: I have friends providing mesh solutions [21:46:30] <Compn> you guys eat the spam ? [21:46:38] <lu_zero> didn't [21:46:41] <lu_zero> you did? [21:47:16] <Compn> spiced pork and meat [21:48:54] * elenril discovers some mpc7 in his collection [21:49:05] <elenril> in wonder if we support metadata for it [21:49:38] <mmu_man_> incidentally, I've cited shame.html several times to members of the french HADOPI, asking them why they didn't protect my copyright as they are supposed to >:-) [21:50:34] <mmu_man_> they waste their time sending mails to kids doing P2P instead, that wouldn't have bought the disks anyway, and that aren't doing any harm to the moral rights of authors, actually helping them get advertisement... [21:50:44] <Compn> did you get reply ? [21:50:48] <mmu_man_> nope [21:50:50] <mmu_man_> wonder why :) [21:51:04] <Compn> also probably none of those in shame are in the hadopi jurisdiction :P [21:51:07] <elenril> but but but PIRACY [21:51:40] <elenril> won't anybody think of poor copyright lawyers [21:51:41] <mmu_man_> Piracy is an incorrect word [21:51:58] <elenril> arrr [21:52:00] <mmu_man_> it's a semantic shift made to induce the idea that sharing is wrong [21:52:03] <mmu_man_> anyway [21:52:21] <mmu_man_> Copying is an act of love. Love is not subject to law. http://copyheart.org/ [21:52:25] <mmu_man_> :p [21:52:35] <mmu_man_> ♡ [21:53:18] <mmu_man_> http://questioncopyright.org/minute_memes/copying_is_not_theft [21:54:23] <mmu_man_> Compn: well they don't do P2P, but Orange certainly is in the french jurisdiction, so they could be tried if they really wanted to [21:54:26] <elenril> i think you're preaching to the choir here ;) [21:54:26] <mmu_man_> btu they don't care [21:54:40] <mmu_man_> elenril: yeah it's just friday I guess :) [21:54:58] <mmu_man_> still, go watch Copying is not theft, it's funny :) [21:58:13] <elenril> michaelni: i case you feel like answering, i wanted to know about the playlist patch from last gsoc [21:58:40] <elenril> i'm wondering what what happened to it [21:59:30] <saste> elenril: it's still in soc [21:59:48] <saste> elenril: nobody dared to touch it after gsoc [22:00:05] <saste> elenril: i mean in the soc SVN repo [22:00:34] <elenril> iirc the student went through several review rounds [22:00:49] <elenril> then he sent one last version and no review came [22:01:07] <saste> elenril: yes I remember the code was not bad [22:01:18] <elenril> so i'm wondering if it's salvageable [22:01:20] <saste> elenril: but then how much time passed since the last patch? [22:02:29] <elenril> what difference does it make, we still don't have playlists ;) [22:04:26] <lu_zero> elenril: care to rebase and put it in a branch/send it out? [22:07:23] <mmu_man_> mru: btw, git: is a perfectly valid URI scheme, even though there is no RFC for it, and at least under Haiku it's fully supported by CheckItOut, so having <a href=""> would allow checking out in a click [22:07:28] <mmu_man_> http://ffmpeg.org/download.html [22:07:33] <mmu_man_> same for svn: [22:08:12] <mmu_man_> though I think we could probably come up with something like maven's scm: canonical scheme as an RFC since http: can be used as well for git [22:08:21] <mmu_man_> hmm for svn at least [22:08:57] <jannau> http: shouldn't be used for git [22:09:11] <mmu_man_> right, was thinking about svn [22:09:15] <mru> only in a pinch [22:09:22] <michaelni> elenril, IIRC i simply run out of time / motivation especially when it came to thinking about the architecture of it all, if someone else would do a round review on it i wouldnt be sad [22:09:25] <mmu_man_> still, there is svn+ssh: for ex as well [22:09:56] <mmu_man_> but svn can use http(s) too, which is usually wired back to the browser but well [22:10:34] <elenril> michaelni: so it wasn't unusable horrible? [22:10:38] <mmu_man_> oh, git: isn't listed on http://fr.wikipedia.org/wiki/Sch%C3%A9ma_d%27URI [22:11:18] <mru> oh those scheming frenchmen... [22:13:44] <microchip_> must be all those frogs [22:14:07] <michaelni> elenril, i dont remember exactly but i think i didnt like the original architecture but after i complained it ended with a worse mix of 2 architectures IIRC but its long ago so i might misremember [22:15:51] * mmu_man_ doesn't eat frogs [22:16:15] <mmu_man_> just like englishmen likely not always eat haggis [22:16:21] <mmu_man_> scothish I mean [22:16:45] <mru> scottish [22:17:18] <kierank2> mmu_man_: you eat snails I assume [22:17:38] <{V}> mmu_man, did you mention Orange specifically to those hadopi members you contacted? [22:17:57] <mru> kierank2: snips and snails and puppydog tails [22:18:48] <{V}> (not as just part of a list) [22:18:59] * lu_zero eats frogs and snails from time to time [22:20:45] <mmu_man_> kierank2: neither [22:20:54] <mmu_man_> {V}: at least once yes [22:20:57] <mmu_man_> but they just don't care [22:21:09] <mmu_man_> I shall send a formal letter someday [22:21:31] <mmu_man_> do we know which files they use ? need to make sure they use at least one I have © on [22:21:47] <mmu_man_> let's see if the git HEAD still builds on OSX [22:21:58] <mmu_man_> I have a pending change for the doc [22:22:15] <mru> mmu_man_: fate says it builds [22:22:19] <mmu_man_> mru: do we have FATE for OSX also ? [22:22:20] <mmu_man_> ah ok [22:22:27] <jannau> and even runs [22:22:28] <mmu_man_> well do we build doc by default ? [22:23:09] <jannau> I don't think so, at least not if the necessary tools are missing [22:23:12] <mmu_man_> mru: oh IIRC it was due to texi2html installed from MacPort being too recent and rejecting an option [22:23:26] <mmu_man_> -number specifically [22:23:44] <mru> we fixed that [22:24:55] <mmu_man_> there is still -number in the Makefile [22:25:09] <mmu_man_> let's see [22:26:44] <DonDiego> mmu_man_: i'm interested to hear if this is broken [22:27:00] <DonDiego> unfortunately texi2html sucks :-/ [22:27:22] <mmu_man_> I suppose it does :p [22:27:28] <mru> hmm, I thought we'd fixed that [22:28:26] <mmu_man_> I recall sending a patch or something and it didn't get in [22:28:33] <mmu_man_> or maybe here [22:29:02] <DonDiego> mmu_man_: so what about the build? [22:29:29] <jannau> there is no (High*) profile sample in fate-suite/h264-conformance? [22:29:43] <mru> don't know [22:29:50] <mru> grab one from ITU and add it [22:30:11] <mru> http://www.itu.int/net/ITU-T/sigdb/spevideo/VideoForm-s.aspx?val=102002641 [22:30:36] <mmu_man_> HTML doc/developer.html [22:30:36] <mmu_man_> Option number is ambiguous (number-footnotes, number-sections) [22:30:37] <mmu_man_> Try `texi2html --help' for more information [22:30:51] <mru> jannau: and make sure it's correctly decoded of course [22:30:57] <mmu_man_> texi2html --version [22:30:57] <mmu_man_> 5.0 [22:31:30] <DonDiego> i have 1.78 here on my debian stable box :) [22:31:36] <jannau> mru: we have to High and a High 4:4:4 Predictive sample in h264/ [22:31:48] <DonDiego> but the best ones are far older, on mphq we use 1.32 or so... [22:31:50] <mru> 1.78 is the latest in gentoo [22:31:56] <mru> must be a different version scale [22:32:02] <mru> perhaps one that goes to 11 [22:32:42] <mmu_man_> anyway [22:32:49] <mmu_man_> annoying [22:32:51] <jannau> http://download.savannah.gnu.org/releases/texi2html/ [22:33:24] <mmu_man_> july 2010 :p [22:33:40] <mru> oh, they did a version leap [22:33:52] <mru> because versions <2 are so 1990s [22:33:57] <mmu_man_> yeah [22:33:57] <jannau> NEWS: change the release number to 5.0, to match [22:33:58] <jannau> the next texinfo release. [22:34:17] <DonDiego> ok, that makes sense [22:34:18] <mmu_man_> then when they get to 9.99 they have to switch back :p [22:34:26] <jannau> and it's still in cvs [22:34:41] <DonDiego> not a project i would want to work on... [22:34:46] <mru> let's make it a rule that every ffmpeg release shall have a number greater than any other released software at the time [22:35:41] <mmu_man_> let's use +∞-N [22:36:01] <jannau> I guess the plan might be to integrate texi2html into texinfo [22:36:01] <CIA-38> ffmpeg: Peter Ross <pross(a)xvid.org> master * r4d54df8e07 ffmpeg/libavformat/ (mpegts.h mpegtsenc.c): (log message trimmed) [22:36:01] <CIA-38> ffmpeg: mpegtsenc: support CODEC_ID_AAC_LATM [22:36:01] <CIA-38> ffmpeg: $subject. Have used this for loopback testing with mpegts.c. [22:36:01] <CIA-38> ffmpeg: -- Peter [22:36:01] <CIA-38> ffmpeg: (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) [22:36:02] <CIA-38> ffmpeg: [2. text/x-diff; 0001-mpegtsenc-support-CODEC_ID_AAC_LATM.patch] [22:36:03] <CIA-38> ffmpeg: From 0f7f9db4b7da1793996af6dda84298507703759a Mon Sep 17 00:00:00 2001 [22:36:18] * mru curses [22:36:24] <elenril> lu_zero: see branch playlists git://git.khirnov.net/git/ffmpeg [22:36:29] <elenril> and it even compiles! [22:36:39] <{V}> mru, gcc again? [22:36:55] <jannau> no, people not using git send-email [22:36:58] <mru> no, I fucked up the commit message [22:37:15] <{V}> ohh [22:37:16] * elenril should install gitorious or something [22:37:24] <mru> I sent the whole message instead of just the attachment to git [22:37:34] <pross-au> eh? [22:37:42] <mru> I need to make some (local) commit hooks to catch such things [22:37:42] <merbanan> elenril: was the asf stuff I sent you of any use ? [22:38:08] <elenril> merbanan: well...i'm not really working on asf [22:38:19] <elenril> the asf patches were just collateral damage [22:38:20] <mru> pross-au: please use git send-email in future [22:38:24] <merbanan> but it is metadata [22:38:28] <merbanan> you love that stuff [22:38:31] <elenril> i was actually working on mp3 muxer at the time [22:38:32] <pross-au> k [22:38:33] <mmu_man_> git send-mail sux [22:38:53] <mmu_man_> it doesn't use the normal MUA, so mails aren't in sent/ folder.. [22:39:02] <mmu_man_> and git format-patch actually formats an email anyway [22:39:03] <mmu_man_> sux [22:39:09] <pross-au> mmu_man_: there's your calling then [22:39:26] <mru> mmu_man_: you can have it send a copy to yourself [22:39:34] <mmu_man_> bleh [22:40:20] <wbs> mru: re git send-email, what way do you prefer for answering review comments inline as a normal reply to the review mail while sending a new updated patch? just comment on the mail and send the updated patch as a separate mail with git send-email? [22:40:45] <mmu_man_> bleh, git send-mail doesn't even exist on OSX it seems [22:40:52] <mmu_man_> I suppose it depends on linux crap [22:41:18] <jannau> wbs: git send-email --annotate --in-reply-to=msg-id [22:41:26] <elenril> mmu_man_: your trolling is too obvious, you've been reading the ML too much [22:41:49] <wbs> jannau: yeah, but if I'd like to answer each of the comments in the previous mail inline as in normal mail discussions, too? [22:41:50] <mmu_man_> elenril: I've been saying this way before the ml talked about switching to git [22:42:00] <mru> wbs: if you attach a properly formatted patch to a review reply, that's rather obvious [22:42:13] <wbs> mru: ok, that's what I've done so far [22:42:14] <mmu_man_> there are several ugly incoherencies in git [22:42:19] <mru> pross-au's patch here looked almost like just a send-email patch [22:42:28] <mmu_man_> not talking about the option jungle :) [22:42:29] <mmu_man_> anyway [22:42:37] <jannau> wbs: and then copying your answer into the annotate editor and using ---8<--- [22:42:48] <mmu_man_> shall I send a patch for s/-number// ? [22:42:50] <wbs> jannau: ah :-) [22:42:56] <Yuvi> git send-email works on my mac... [22:42:58] <mmu_man_> ELAZY [22:43:15] <ohsix> -ELAZY [22:43:16] <elenril> iirc send-email is a perl script [22:43:26] <mmu_man_> ohsix: certainly not [22:43:32] * pross-au is working on git-mutt-patch.sh .. [22:43:34] <elenril> or something similarly horrible [22:43:35] <mmu_man_> negating error codes is ugly [22:43:40] <mmu_man_> and dangerous [22:43:47] <mmu_man_> some OSes have them <0 [22:44:06] <mmu_man_> ah, was searching send-mail [22:44:42] <mmu_man_> but I shouldn't have to set up a mail account in an SCM [22:50:53] <mmu_man_> couldn't they just have send-email use the native clients... [22:52:09] <jannau> it works out of the box with a proper sendmail compatible mta [22:52:27] <jannau> no need to configure amail account [22:52:46] <mmu_man_> except I don't think sendmail on OSX actually uses the Mail.app settings [22:53:13] <mmu_man_> I suppose I could write a sendmail wrapper for Haiku [22:53:18] <mmu_man_> that's ugly [22:53:21] <Yuvi> mmu_man: have git send-email use an smtp sever [22:53:30] <Yuvi> instead of sendmail [22:54:10] <DonDiego> Yuvi: hey, long time no see :) [22:54:42] <Yuvi> DonDiego: hi, I've been busy :) [22:58:01] <Kovensky> 19:43.34 elenril: or something similarly horrible <-- me and TheFluff (mru too?) would like to have a chat with you [22:58:04] * Kovensky runs [22:58:17] <Kovensky> ohi Yuvi [22:58:38] <TheFluff> >sendmail [22:58:39] <TheFluff> sage [22:59:34] <wbs> great, only 97 mails on the ML while being away for a few hours ;P [22:59:39] <mru> going out, back later [22:59:47] * elenril goes to sleep [23:12:28] <mmu_man_> git send-email seems hung up [23:12:53] <mmu_man_> Result: 250 2.0.0 Ok: queued as DC12F82261 [23:12:56] <mmu_man_> hmm [23:13:07] <mmu_man_> ah :) [23:13:36] <mmu_man_> hmm it forgot the Signed-off-by [23:13:43] <astrange> is there a way to copy aac from ts->mov or mkv that works? ffmpeg streamcopy and mkvtoolnix don't [23:13:43] <mmu_man_> man says it's on by default ?? [23:15:57] <mmu_man_> couldn't git clone set the sendemail.to on its own btw ? [23:19:08] <mmu_man_> at least it seemed to have worked [23:20:04] <Sean_McG> elenril: it's not authored as 1 file. [23:20:41] <mmu_man_> hmm did it go through the ml ? [23:21:22] <mmu_man_> ah yes [23:23:40] <bcoudurier> astrange, what's wrong ? [23:23:54] <bcoudurier> you have to absf the stream [23:27:48] <astrange> ah [23:27:57] <astrange> now it at least works in mplayer. only with faad though [23:27:57] <astrange> [aac @ 0x10185fa00] Audio object type 4 is not supported. [23:28:45] <astrange> the original ts doesn't show that error :/ [23:33:58] <superdump> 4 is LTP [23:34:21] <superdump> a guy is working on that as an early small task for qualification for SoC [23:34:38] <superdump> (rebasing and cleaning up LTP) [23:34:59] <superdump> but i guess if it worked in the ts... [23:39:55] <astrange> i really doubt tv tokyo is broadcasting LTP, it's a copy failure [23:41:16] <DonDiego> gnite [23:41:23] <Sean_McG> take care dude [23:42:40] <kierank> astrange: japanese tv does a lot of weird non-standard things with aac audio [23:49:44] <mmu_man_> mru: care to commit ? [23:59:45] <jannau> mmu_man_: that would probably break the docs on the website which still uses texi2html 1.56k

1 0

IRC log for 2011-01-27
by irc＠mansr.com 28 Jan '11

28 Jan '11

[00:45:45] <Dark_Shikari> michaelni: sorry, I think I flamed too hard [00:50:00] <michaelni> Dark_Shikari, throw as much at me as you like, ive a thick skin after this [00:50:20] <Dark_Shikari> lol [00:50:38] <Dark_Shikari> in short: I think it would be better if you offered to give something as well. [00:50:45] <michaelni> i really am a bit upset after i read the secret logs [00:50:48] <Dark_Shikari> For example, "I'll resign as BDFL officially, but only if <X> <Y> <Z>." [00:50:57] <Dark_Shikari> As opposed to "I want <X> <Y> <Z> now!" [00:51:01] <michaelni> i hoped to find libel from diego and mans but none of that [00:51:18] <Dark_Shikari> I think you overestimate how much people cared about mans... [00:51:25] <michaelni> i wrote this mail really quickly ... [00:51:27] <Dark_Shikari> I didn't even know until after I agreed to get involved that mans was coming back. [00:51:55] <Dark_Shikari> oh also, I sent you (and the others) an email asking how you'd like your x264 LLC shares paid out, since we just hit profitability. [00:52:13] * michaelni remembers no mail [00:52:24] <michaelni> when was that? [00:52:27] <Dark_Shikari> This minute. [00:52:35] <michaelni> ok then it makes sense :) [00:52:39] <Dark_Shikari> lol [00:52:42] <michaelni> ill look later [00:52:52] <Dark_Shikari> no problem, no rush. [00:53:03] <Jumpyshoes> :O x264 LLC is now profitable? [00:53:12] <Dark_Shikari> Total income so far: $37750 [00:53:16] <Dark_Shikari> Total costs so far: $25835 [00:53:20] <Jumpyshoes> :o [00:53:21] <Jumpyshoes> nice [00:53:33] * Dark_Shikari pats his trusty spreadsheet. [00:54:15] <Dark_Shikari> michaelni: btw, I think you should set yourself a goal of something you want to do. right now you seem to just be reviewing things and talking about things with no real aim. [00:54:24] <Dark_Shikari> Even something like "make motionest faster" is a goal, though I don't think a very useful one. [00:54:40] <Dark_Shikari> For example it could be "modernize ffmpeg's assembly code", since a whole lot of the asm is mmx-only (for mpegvideo, etc). [00:54:51] <michaelni> about resigning as BDFL, i just dont see how it could work, at the least i need to retain control over the accounts [00:55:03] <michaelni> alternative is chaos IMHO [00:55:12] <Dark_Shikari> what do you mean by retain control over accounts? [00:55:16] <Dark_Shikari> you mean root? [00:55:55] <michaelni> i mean when lets say ffmpeg is on soureforge someone is in charge to add/remove accountgs [00:56:24] <michaelni> for the project that is [00:56:29] <Dark_Shikari> that doesn't mean you need to be BDFL for that. [00:56:35] <michaelni> you cant have noone [00:56:36] <Dark_Shikari> For example, a man at a nuke silo has the ability to launch the nuke. [00:56:42] <Dark_Shikari> That doesn't mean he has the RIGHT to unless he's ordered to. [00:56:57] <Dark_Shikari> You can have the _ability_ to manage accounts, while still being required to obey the decisions of the majority. [00:57:20] <michaelni> that i can live with [00:57:21] <michaelni> but [00:57:34] <michaelni> sometimes its simply bad to do long votes ... [00:57:42] <lu_zero> michaelni: by votes [00:57:44] <Dark_Shikari> I agree that votes are generally bad. [00:57:45] <lu_zero> and by count [00:57:49] <lu_zero> you are in minority [00:57:51] <lu_zero> end. [00:58:08] <Dark_Shikari> On the other hand, I think that most things don't need votes. [00:58:11] <michaelni> lu_zero, what votes what count? [00:58:13] <Dark_Shikari> "Should $newuser get commit access?" [00:58:23] <lu_zero> even on your quite biased and ugly "love me hate me" call [00:58:26] <Dark_Shikari> usually such things don't require much debate. [00:58:28] <lu_zero> I'm sick of that [00:58:49] <michaelni> lu_zero, what? [00:58:52] <lu_zero> YOU [00:59:08] <bcoudurier> hey please calm down [00:59:36] <bcoudurier> I don't even understand why votes are so bad [00:59:45] <Dark_Shikari> bcoudurier: they invite politicking [00:59:48] <Dark_Shikari> I think [01:02:17] <bcoudurier> I can see why, but the same can happen without [01:02:29] <bcoudurier> anonymous votes allow people to express their opinion [01:02:37] <Dark_Shikari> Anonymous votes are good [01:02:40] <Dark_Shikari> most of the votes we've had -- haven't been. [01:02:46] <bcoudurier> I agree with this [01:02:54] <bcoudurier> and I raised that concern on -legal once [01:02:56] <Dark_Shikari> non-anonymous voting invites massive politicking. [01:03:00] <Dark_Shikari> I strongly oppose it. [01:03:07] <iive> Dark_Shikari: you cant vote anonymously over internet. [01:03:38] <Dark_Shikari> sure you can [01:03:59] <lu_zero> in gentoo we do every time we need [01:05:43] <iive> you need independent third parity whom you can trust to count the vote correctly and to keep the secret. [01:06:31] <uau> iive: i think there actually are cryptographic protocols that enable a secret vote without a third party [01:06:55] <iive> no, no protocols yet [01:07:11] <iive> i've read about some math that may allow it, but it is untested field. [01:07:59] <BBB> votes are bad, don't do votes [01:08:03] <BBB> blegh [01:08:52] <BBB> bcoudurier: we've abused votes in the past, as a system of making a decision when we can't get to one as a community [01:08:55] <uau> iive: a google search returns hits that look like they're talking about such a protocol [01:09:11] <BBB> bcoudurier: the result has generally been that half developers don't get their way, half do, the votes list two extremes and thus half of the devs are unhappy [01:09:26] <BBB> bcoudurier: whereas in many cases we could've come to a consensus that met all developers more or less in the middle [01:09:38] <BBB> bcoudurier: fun vote: foundation name. bad vote: michael stays leader or steps down [01:09:51] <BBB> first: there's a few literal choices and really, nobody cares that much anyway [01:09:53] <iive> BBB: votes are used when such consensus cannot be reached [01:10:07] <BBB> second: there's many ways in between that would satisfy the whole developer body more than those extremes [01:10:12] <BBB> so the vote was pointless :( [01:10:13] <iive> as a method to stop arguing. [01:10:34] <BBB> iive: keep believing that, but clearly as you've noticed in the past week, votes do not end the arguing [01:10:39] <BBB> they just leave half the developer body unhappy [01:10:41] <BBB> if not more [01:10:59] <iive> BBB: i don't see any voting in the past week. [01:11:15] <BBB> thank god no [01:11:19] <BBB> that would've made it worse [01:11:46] <BBB> here's a vote that makes no sense whatsoever: who shall be project leader: michael, and mans leaves ffmpeg for good, or mans, and michael leaves ffmpeg for good [01:11:51] <BBB> that makes _no sense whatsoever_ [01:11:57] <Dark_Shikari> It's also a false dichotomy. [01:11:58] <BBB> if you don't see why, then sorry, you're an idiot [01:12:08] <BBB> there's better choices than either of those two [01:12:10] <BBB> Dark_Shikari: yes :) [01:13:21] <iive> BBB: mans and michael have reached stage where they can't work in the same project. what other options do you have? [01:13:34] <Dark_Shikari> iive: in that case, I pick the third option. [01:13:36] <Dark_Shikari> Both leave. [01:13:39] <bcoudurier> sometimes difficult decisions have to be made and consensus cannot be reached [01:13:39] <Dark_Shikari> Notjoking.jpg [01:13:58] <bcoudurier> I've had votes against what I wanted in the past and I accepted the outcome [01:14:23] <BBB> bcoudurier: if nothing else, a vote can help - but we've abused them beyond what they are good for [01:14:26] <BBB> no more votes for now [01:14:35] <Dark_Shikari> "If we have to pick between Mans and Michael to leave, I choose that both leave." [01:14:37] <bcoudurier> if we want to avoid votes, we need reasonable people that agree to a compromise [01:14:38] <BBB> and michaelni's email just now is an example of how not to do this [01:14:50] <bcoudurier> many times I didn't see any compromise [01:15:09] <bcoudurier> and harsh tone [01:15:51] <michaelni> BBB, by email is poor but the truth should not be hidden [01:16:03] <Dark_Shikari> michaelni: but it's not the truth, it's just flames [01:16:11] <iive> Dark_Shikari: indeed, my mistake. there is forth option. [01:16:20] <Dark_Shikari> fourth? [01:16:23] <Dark_Shikari> which is that [01:16:29] <iive> 00,01,10,11 [01:16:31] <Dark_Shikari> michael leaves, mans leaves, both leaves, or... [01:16:37] <Dark_Shikari> Oh. I thought you implied 00 wasn't. [01:19:00] * Compn still not see what michael actually does as 'leader' [01:19:33] <Compn> i see him rejecting all patches as a maintainer [01:19:38] <michaelni> iam evil, eat small children, force people to commit seppuku so i can deduct the burial cost [01:19:40] <Compn> but not him overriding any other maintainers [01:19:56] <Compn> i havent read every mail... [01:20:03] <iive> lol [01:20:16] <Compn> you should eat the large children too, more meat [01:20:40] * michaelni eats Compn [01:21:10] <Compn> but i'm full of transfats! [01:21:19] * michaelni pukes [01:21:34] <merbanan> this isn't going to lead anywhere [01:21:34] <iive> Compn: now you are answering your own questions. [01:21:51] <BBB> I'm with merbanan [01:22:17] * Compn guessed if michael came on irc that all people talking shit about him would stop, and everyone would get quiet [01:22:29] <Dark_Shikari> Talking shit begets talking shit. [01:22:32] <Dark_Shikari> if nobody talks shit, nobody talks shit. [01:22:35] <Dark_Shikari> if someone talks shit, everyone talks shit. [01:22:53] <michaelni> solution to our problems: lets talk shit [01:23:00] <Dark_Shikari> yaaaaaay talking shit. [01:23:15] <Compn> michaelni : btw why were you upset about ronald asking carl if he wanted to get paid for fflegal ? because it looked like a bribe ? [01:23:31] <michaelni> yes, i misunderstood [01:23:33] <Compn> ah [01:23:40] <lu_zero> ... [01:23:46] <Compn> thats why i said not to jump :P [01:23:51] <Compn> no jumping allowed! [01:24:03] <lu_zero> something that was already half decided months ago... [01:24:16] <michaelni> BBB and merbanan leaving isnt solving this either :( [01:24:29] <Dark_Shikari> michaelni: time to talk shit! [01:24:34] <michaelni> they should have stayed in the channel [01:24:35] <Dark_Shikari> Your mother was a hamster and your father smelt of ELDERBERRIES! [01:24:38] <lu_zero> and still on the ml remains just what you wrote in vitriol [01:24:38] <Compn> lu_zero : what did michaelni do to make you hate him so much? if you dont mind airing your grievences now ? [01:24:43] <lu_zero> michaelni: I'm about to sleep [01:24:48] <bcoudurier> it looked like a bribe considering the situation [01:24:51] <Compn> oh too late :P [01:24:52] <iive> they need to sleep. [01:24:53] <Dark_Shikari> I empty my nose at you, you pathetic pig-sty cleaner! [01:24:54] <lu_zero> merbz is on the same time zone [01:25:02] <lu_zero> BBB has a newborn to care... [01:25:16] <bcoudurier> lu_zero, "decided" ? [01:25:16] <iive> there is russian saying that morning is smarter than evening. [01:25:18] <bcoudurier> how so ? [01:25:55] <Compn> michaelni : maybe you should apologize on the list for some of them rude mails... [01:26:07] <lu_zero> bcoudurier: the proposal had been made and there were only positive comments that I recall [01:26:09] <michaelni> yeah, which ? :) [01:26:10] <Compn> well thats what i'd do anyways [01:26:10] <bcoudurier> any foundation matter is decided is when 4 people from the directors vote for [01:26:22] <michaelni> i mean for which do you think it matters most? [01:26:40] <lu_zero> bcoudurier: that's why I said _half_ [01:26:50] <lu_zero> and not decided [01:27:02] <Compn> michaelni : hmm, good question. i am not sure which ones were most upsetting. [01:27:13] <iive> lu_zero: see, the problem here is that the proposition haven't been official. [01:27:19] <bcoudurier> besides ronald has no real right to do that [01:27:30] <michaelni> Anyway if people want we can keep the 2 repos i just dont think this is a good idea [01:27:30] <iive> so if carl haven't agreed, it may have never been official. [01:27:38] <Compn> ronald can make an inquiry before making a proposition to the board ? [01:27:42] <bcoudurier> and as the treasurer it could even more look like a bribe :> [01:27:42] <iive> been->become [01:27:52] <Compn> bcoudurier , iive : cant he ? [01:28:06] <bcoudurier> Im kidding here [01:28:10] <Compn> its hard to tell. [01:28:21] <bcoudurier> smiley :> [01:28:34] <relaxed> that's a bird [01:28:40] <Compn> is iive kidding ? [01:28:50] <bcoudurier> anyway the timing was not the best, but the idea is good [01:29:40] <ubitux> oh guys, you changed again the repository? [01:29:41] <iive> that's how bribe is done. I do not imply that is what ronald intent. [01:30:14] <michaelni> ubitux, just wait a minute until diego chnages it back flames me and closes my account [01:30:23] <ubitux> haha [01:30:34] <Compn> hopefully mru will come up with a better dload page for all ffmpeg trees [01:30:34] <ubitux> come onâŠ :p [01:30:58] <ubitux> you're seriously all insane :) [01:31:09] <michaelni> I really do NOT want to loose mru [01:31:12] <Compn> now for some serious questions [01:31:17] <Compn> michaelni : what are you drinking right now ? [01:31:21] <iive> I see that ronald then talks about third unrelated thing. Also the mail date is 18'th, and that's the day of the switch, not signing. [01:31:23] <michaelni> or anyone else [01:31:32] <michaelni> Compn, water was last [01:31:59] * Compn drinks sports drink, like gatorade [01:32:20] * Kovensky goes drink some water [01:32:25] <lu_zero> Compn: it was started by me and mru was filling the css and the entries since I was tired by that time already... [01:32:26] <michaelni> iive, the "bribe" really isnt helping us in resolving this [01:32:51] <Compn> lu_zero : no problem, just trying to help :( [01:33:07] <michaelni> iive, so lets accept that BBB was fucking stressed by his baby and wrote shit without thinking on the wrong day [01:33:27] <Compn> michaelni : so how do you propose everyone work together here ? [01:33:34] <Compn> if you have any ideas... [01:33:45] <michaelni> Depends on the people [01:33:57] <michaelni> if people want 2 repos this is possible [01:34:09] <michaelni> if they want to try 1 this is possible [01:34:12] <iive> as i just said, the mail is from 18 january. the signing was on 17 [01:34:18] <michaelni> we can also switch it every week [01:34:30] <Compn> iive : i think everyone is willing to drop it, is that ok with you ? [01:34:40] <Compn> lol switch it every week [01:34:50] <iive> yes, I've dropped it. [01:35:00] <iive> oops, it broke. [01:36:29] <Compn> michaelni : mru rejected the libmpcodecs stuff, should it stay on a branch or what should be done ? [01:36:49] <michaelni> Compn, i dont care the faintest about libmpcodecs [01:37:10] <michaelni> if we can resolve this by doing something with it please people, mru do it with libmpcodecs [01:37:13] <Compn> i guess no one does :)\ [01:37:41] <Compn> well i cant figure out where you guys differ in code ideas then [01:38:00] <michaelni> Compn, we dont strongly differ [01:38:11] <Compn> and by 'you guys' i mean everyone, not just you and mans [01:38:15] <michaelni> we differ in knowledge that is we have knowledge in different areas [01:38:26] <michaelni> ahh i meant me and mru [01:38:52] <michaelni> and that different areas knowledge leads to somewhat different oppinions i think [01:38:52] <Compn> ehe [01:39:20] <michaelni> and theres bikesheds .... [01:39:38] <lu_zero> Compn: some libmpcodecs will be ported in a sprint if I can convince saste or michaelni to support the effort sharing their knowledge [01:39:39] <michaelni> where things can be either way and down to earth it makes no difference at all [01:40:30] <michaelni> lu_zero, you can convince me if this is moving us toward a solution but if its not then no [01:40:33] <Compn> its quite hard to organize and agree and have a committee work on a project together ;\ [01:41:09] <michaelni> i mean i dont want to spend a month on libmp and then find we still are in the same crisis [01:41:30] <ubitux> btw, this may sound stupid, but why don't you host the main copy of the repository on ffmpeg.org? [01:41:33] <Compn> lu_zero : well i havent even seen any users use libavfilter yet :P [01:41:44] <bcoudurier> I crashed :( [01:41:44] <Dark_Shikari> michaelni: maybe then you should get approval before doing things unilaterally [01:41:53] <lu_zero> Compn: yadif had been used with satisfaction [01:41:55] <michaelni> ubitux, trust & paranoia [01:41:56] <Dark_Shikari> You constantly whine at others for such things, but then you go do them yourself. [01:42:08] * lu_zero suggested its use in some situations [01:42:15] <ubitux> michaelni: since you're using git there is not that much to care about [01:42:30] <ubitux> i mean you can push to somewhere else anytime [01:42:33] <Compn> ubitux : let the dust settle before drawing the lines :P [01:42:36] <lu_zero> and still [01:42:44] <Compn> ubitux : also i dont think michael has commit rights on git.ffmpeg ... [01:42:59] <michaelni> Dark_Shikari, i know i fucked up with that mail a bit [01:43:08] <lu_zero> libmpcodecs is something total orthogonal [01:43:21] <michaelni> I dont think the idea was bad but yes i should have asked and worded it more diplomatically [01:43:27] <lu_zero> Compn: nobody but those in charge of merging do [01:43:29] <Dark_Shikari> well, right there I was referring to libmpcodecs [01:43:37] <Dark_Shikari> I think people have the impression you forced libmpcodecs on ffmpeg [01:43:39] <ubitux> Compn: well i mean, admitting everything was fine (for example just before the putsch), why was it important to put the main repo elsewhere? [01:43:40] <Dark_Shikari> even when most disagreed [01:43:44] <Dark_Shikari> Yet -- you whine at others for doing the same. [01:44:02] <michaelni> Dark_Shikari, let me explain about libmp [01:44:11] <ubitux> i mean, at least for users it's disturbing :P [01:44:13] <Compn> ubitux : its a long story [01:44:23] <ubitux> Compn: do you have a thread reference? [01:44:32] <Compn> see git threads in ffmpeg-devel [01:44:40] <ubitux> 'k thanks. [01:44:41] <Compn> go back a few months [01:44:50] * Compn doesnt remember exact threads [01:44:57] <Compn> but its all on the list [01:45:00] <michaelni> attila gave me a hint of a possible fork a week or so earlier but no word on who,why or anything, and i thought if iam more active and work on something usefull like libmp i hcould avoid the fork [01:45:22] <michaelni> thats why i was a bit pushy [01:45:42] <Compn> Dark_Shikari : i think a few people asked during libavfilter development about porting libmpcodecs [01:45:48] <Compn> as a wrapper [01:46:00] <lu_zero> Compn: there was a discussion about it [01:46:00] <Compn> i think it was even in the soc project description ? [01:46:24] <lu_zero> started by Stefano I think [01:46:34] <michaelni> as said if doing something with libmp like droping it resolves things i definityl agree [01:46:44] <Dark_Shikari> it's not about dropping it, it's about having discussion [01:47:05] <Compn> michaelni : Dark_Shikari and others want you to ask what to work on before you do it, i guess [01:47:28] <Dark_Shikari> I think people should be aware of what's going on. [01:47:29] <Dark_Shikari> Code dumps are bad. [01:47:32] <Compn> heh [01:47:38] <michaelni> lords, how can i server thee best? [01:47:43] <iive> michaelni: i actually joked here that it would be better if you gave ultimatum to commit the wrapper if filters from mp are not ported for x weeks. [01:48:04] <lu_zero> sigh... [01:48:08] <Compn> thats what his mail said iive [01:48:16] <Compn> wrapper would be in until it was ported and faster ... [01:48:23] <Compn> or someone elses mail [01:48:41] <iive> maybe somebody quoted me... [01:48:48] <Compn> lu_zero : yes, stefano didnt want to do it, and michael wanted someone to do it [01:48:56] <Compn> lu_zero : michael ended up doing it [01:49:02] <lu_zero> the whole libmpcodecs stuff would be solved in around 3-4 days by collectively porting those 20 filter one by one [01:49:05] <Compn> i'm not understanding the problem really [01:49:13] <lu_zero> Compn: have a look at that code [01:49:15] <lu_zero> and [01:49:20] <michaelni> stefano tried but he lacked experience with integrating code dumps [01:49:28] <Compn> ah [01:49:36] <lu_zero> have fun trying to optimize swscale [01:50:00] <bcoudurier> well I think having libmpcodecs features is nice [01:50:07] <michaelni> BBB, hi [01:50:15] <lu_zero> the features, indeed, the code as is not. [01:50:19] <bcoudurier> a compromise would have been to not compile them by default [01:50:28] <bcoudurier> a _compromise_ [01:50:35] <Compn> lu_zero : ah, you are talking about having optimized libavfilter being next to optimizing libmpcodecs ? [01:50:40] <bcoudurier> saying I don't want this doesn't lead anywhere [01:50:53] <uau> bcoudurier: i don't think that would have been accepted as a compromise [01:50:54] <bcoudurier> and it will happen again in the future [01:50:55] <ubitux> oh, repository url switch again. [01:50:56] <Compn> lu_zero : i mean, the trouble having the same code so that both can be optimized ? [01:51:18] <ubitux> (hey, this is starting to be ridiculous) [01:51:27] <bcoudurier> uau, let the people talk, please [01:51:34] <lu_zero> Compn: could we drop libmpcodecs? [01:52:03] <michaelni> lu_zero, as i said if it helps solve the crisis definitly yes [01:52:18] <lu_zero> having the libmpcodecs interesting filters as avfilter is something 5-6 people would get done in a weekend. [01:52:26] <Compn> lu_zero : i have no problem with dropping whatever [01:52:33] <lu_zero> I mean dropping the discussion [01:52:35] <bcoudurier> lu_zero, let's try to do that then, who is in ? [01:52:48] <Compn> lu_zero : yes, i agree its not going anywhere [01:53:07] <Compn> sorry, i brought it up as an example but ... my question got answered quickly [01:53:11] <lu_zero> I'm in, Benjamin was (shoud re-ask) [01:53:18] <lu_zero> BBB: you were, you'd be? [01:53:31] <bcoudurier> that sounds good [01:53:36] <bcoudurier> I would be in also [01:53:56] <lu_zero> stefano was debating since the whole idea was told him on the phone that day [01:54:12] <Dark_Shikari> nice patch by mru. [01:54:14] <lu_zero> anyway, that is not the problem. [01:54:39] <bcoudurier> btw, I think cleaning up swscale is needed and that it must be done [01:55:36] <BBB> lu_zero: sorry, in for what? short summary? [01:56:22] <Kovensky> BBB: hack weekend to port the most important filters from libmpcodecs to libavfilter [01:57:53] <lu_zero> bcoudurier: I'm at patch 8, few more needed ^^; [01:58:04] <bcoudurier> please keep going :) [01:58:25] <BBB> Kovensky: I can be in, but I want this bs to end first please [01:58:36] <BBB> and yes, lu_zero, awesome :) [02:01:16] * michaelni sees links reverted to illegitimate repo and returns to civil disobedience [02:01:33] <Dark_Shikari> "illegitimate"? [02:02:02] <michaelni> no public discussion, many details kept secret, no public vote, ... [02:02:19] <Dark_Shikari> ... says michael, who committed libmpcodes with no public discussion, no public vote... [02:02:24] <michaelni> people signing actually not knowing it was a takeover and no fork [02:02:34] <Dark_Shikari> But it was a fork. There's two repos. [02:02:46] <Compn> Dark_Shikari : not according to download page ... [02:03:07] <lu_zero> Compn: the download page has a patch for it now =P [02:03:08] <michaelni> nor according to suggested new download page [02:03:22] <michaelni> its still advertising mans tree as more official which it is not [02:03:27] <Dark_Shikari> "Fork" does not mean "all forks are equal" [02:03:30] <Dark_Shikari> it means "there are multiple trees" [02:03:38] <bcoudurier> humm, michaelni please don't [02:03:57] <Compn> and now we get to bikeshed the tree names in dload page like i guessed we would [02:04:02] <michaelni> bcoudurier, ? [02:04:05] <Compn> hooray [02:04:27] <BBB> anyway, to get back to kovensky's question, yes I will help porting the most important mpfilters if that helps us along, _if_ we can at the same time also figure out a way out of this mess we're currently in [02:04:34] <BBB> Compn: no, let's vote [02:04:58] <BBB> I think my tree should be called "The Tree of Corporate Evil" [02:04:59] <bcoudurier> don't go crazy and into the "civil disobedience" mode [02:05:14] <michaelni> ahh ok understood [02:05:42] <Compn> BBB : you should name it after your kid :P [02:05:53] <uau> BBB: i don't think porting filters will help that much - at least i didn't get the impression that many people would have forked over the filters specifically [02:06:14] <BBB> uau: that is my impression also, but if it helps I'll do my share [02:06:26] <lu_zero> the filter are something small [02:06:36] <michaelni> uau, /BBB mine too [02:06:54] <BBB> I don't mind doing work to solve this mess, though [02:07:00] <lu_zero> eh [02:07:26] <michaelni> BBB i also volunteer but it must be real not waste time for no gain [02:07:34] <Compn> so both sides should get a list of demands ? [02:07:43] <uau> michaelni: btw as Dark_Shikari already said, i don't think many people would view it as 'mÃ¥ns's tree' [02:07:58] <lu_zero> michaelni: having libavfilter used was your wish as well [02:08:07] <lu_zero> still [02:08:38] <michaelni> uau, its one of 2 ffmpeg trees, the "mans" one is not more official [02:08:45] <BBB> Dark_Shikari: btw are you ok with me committing the emu_edge dsp'ification + C speed-up while I keep polishing the asm some more? [02:08:51] <Dark_Shikari> michaelni: there is one thing I typically disagree with you on that I think is important here [02:08:54] <Dark_Shikari> Users are the #1 priority [02:08:56] <Dark_Shikari> Not developers [02:08:57] <lu_zero> I'd like you wait and see if this way of managing patches for the master is that wrong or not [02:09:04] <Dark_Shikari> therefore, if putting forked repos up on the ffmpeg download page would confuse people [02:09:07] <Dark_Shikari> it is better not to do it [02:09:12] <Dark_Shikari> (i.e. putting up two, separate repos that appear equal) [02:09:16] <Dark_Shikari> (but aren't the same in content) [02:09:28] <uau> michaelni: my point was about the name "mans tree" - i don't think other developers view it that way (identifying it with him personally) [02:09:50] <Dark_Shikari> BBB: yes [02:09:51] <lu_zero> uau: mans' tree is http://git.mansr.com/?p=ffmpeg [02:09:52] <michaelni> uau yes i agree with you [02:09:52] * BBB agrees with uau [02:10:01] <iive> uau: it is the tree mans created after ffmpeg moved to videolan. [02:10:03] <Dark_Shikari> asm does not have to be pretty, it has to be fast. [02:10:09] <Dark_Shikari> "Ugly asm" is better than "no asm". [02:10:11] <michaelni> i just had to refer to it somehow [02:10:13] <Dark_Shikari> "pretty asm" is better than "ugly asm". [02:10:19] <Dark_Shikari> But if there's no pretty asm, ugly is better than nothing. [02:10:26] <BBB> Dark_Shikari: heh :) I hate to see my name be asosciated with this mess :-p [02:10:35] <BBB> it's darn fast though [02:10:52] <bcoudurier> I agree with Dark_Shikari with Users are #1 priority [02:10:53] <lu_zero> BBB: why it's ugly then? [02:11:08] <j-b> users are cheap and numerous... Developers aren't [02:11:10] <bcoudurier> that's the reason I had my own tree in the first place [02:11:17] <BBB> lu_zero: uh... just look at it, it's a little... convoluted [02:11:49] <lu_zero> BBB: if you'd have to change it in a week you'd be able? [02:12:00] <BBB> lu_zero: probably [02:12:10] <lu_zero> if I'd have to change it you'd be able to tell me, in a month? [02:12:10] <BBB> unless I have to port mpfilters :-p [02:12:24] <BBB> two weeks [02:12:27] <BBB> if not less [02:12:35] <BBB> probably a week also, depends on how much time you have [02:12:52] <lu_zero> if I'd have to change/fix it alone I would scream in pain? [02:12:54] <uau> lu_zero, iive: i don't think michaelni meant that (certainly i don't see how the download page would claim that to be "more official" - the patch says "Personal repository with works in progress" about that one) [02:13:01] <Compn> i think we can all agree... we need to make kshishkov work on vivo decoders :P [02:13:08] <BBB> lu_zero: yes [02:13:28] * lu_zero enumerates the levels of ugliness [02:13:58] <lu_zero> BBB: if you can make so it would let me or anybody else understand it, it's fine ^^; [02:14:00] <drv> what's so exciting about vivo? i've never seen one outside the mphq samples [02:14:24] <BBB> lu_zero: that's the goal :) [02:14:47] <Compn> drv : it used to be big. like quicktime - vivo - real [02:15:02] <Compn> - asf [02:15:48] <Compn> drv : its also just about the last big format i can think of with no support in ffmpeg [02:16:05] <Dark_Shikari> michaelni: you see, here's the problem again. [02:16:06] <Compn> btw someone asked about openexr on -users list :) [02:16:13] <Dark_Shikari> You say "videolan is official tree" [02:16:20] <Dark_Shikari> You aren't even asking for both to be listed equally [02:16:24] <Dark_Shikari> you're asking for that to be the only one listed [02:16:31] <Dark_Shikari> that's not a compromise, that's a dictator decree [02:16:34] <Compn> Dark_Shikari : you arent asking for both to be listed equally [02:16:41] <Compn> hurrrr [02:16:43] <Dark_Shikari> Compn: I'm not, I'm saying Michael isn't proposing that. [02:16:59] <iive> Dark_Shikari: because they are not equal. [02:17:06] <Compn> michaelni : try proposing that, please oh please [02:17:07] <Dark_Shikari> Yes, one has all the developers, one has two devs. [02:17:34] <lu_zero> the git.ffmpeg.org is what ubuntu and gentoo will use for the time coming.... [02:17:39] <Compn> again with the counting [02:18:04] <bcoudurier> lu_zero, well ffmpeg.org is not ours [02:18:29] <lu_zero> while ffmpeg-mt is what chromium and vlc are using for the time coming if -mt isn't merged somewhere else [02:18:40] <lu_zero> bcoudurier: define ours and define ffmpeg.org [02:18:48] <Compn> astrange was working on -mt merging [02:18:49] <j-b> lu_zero: not yet for VLC, but yes, we will [02:18:52] <Compn> post git switch [02:19:00] <michaelni> Dark_Shikari, one has 7 commiters from which 4 dont commit, the other has all ffmpeg devels as commiters [02:19:26] <bcoudurier> lu_zero, fabrice owns ffmpeg.org and the trademark [02:19:32] <michaelni> and most commits are old bikeshed cosmetics n that 7 devel tree [02:19:49] <Dark_Shikari> michaelni: er, no [02:19:53] <uau> lu_zero: there should pretty soon be an mplayer2 release with the default being ffmpeg-mt too (tarball with ffmpeg-mt included to compile the player against) [02:19:53] <Dark_Shikari> that one has far more than 7 committers [02:19:59] <Dark_Shikari> "can push" != "can commit" [02:20:02] <Dark_Shikari> anyone in the entire world can commit [02:20:32] <iive> Dark_Shikari: please... don't bring semantics [02:20:34] <bcoudurier> that's the same, pusher == svn commiters [02:20:35] <michaelni> Dark_Shikari, 7 pushers? sounds odd to be but ok [02:21:10] <Dark_Shikari> iive: michael brought up the semantics [02:21:15] <Dark_Shikari> he's complaining about "only a few people are committing" [02:21:20] <lu_zero> uau: ok, I guess I'll notice from Nikoli when you are ready =) [02:21:26] <Dark_Shikari> when really he means "dozens of people are having their patches pushed via a few people" [02:22:35] <bcoudurier> not yet dozens [02:22:38] <iive> Dark_Shikari: you are confusing x264 development model with ffmpeg one. [02:22:39] <bcoudurier> but I get the point [02:22:46] <Dark_Shikari> iive: ffmpeg is the same [02:22:50] <Dark_Shikari> in fact [02:22:52] <michaelni> Dark_Shikari, people dont post patches for one tree they can be applied to either [02:22:56] <Dark_Shikari> we just shifted ffmpeg to x264's model ;) [02:23:02] <michaelni> i just refuse to work currenzly [02:23:44] <iive> Dark_Shikari: you can't shift palm to sibir. [02:23:53] <Dark_Shikari> ? [02:23:57] <iive> Siberia? [02:24:11] <Compn> why are we arguing about committers and pushers [02:24:17] <Compn> we all know how this works and how many there are [02:24:21] <Compn> this is dumb [02:24:59] <Compn> if we are going to argue, lets argue about something dumber [02:25:08] <Dark_Shikari> ok, good idea [02:25:09] <lu_zero> michaelni: ... [02:25:12] <Dark_Shikari> x264 has Touhou, ffmpeg needs an equivalent. [02:25:16] <Dark_Shikari> Let's argue about what ffmpeg should have. [02:25:24] <lu_zero> harui [02:25:26] <Compn> you guys watch entirely too much anime [02:25:34] <Dark_Shikari> "Touhou isn't anime!!!!!1o1oo1no1neo1" [02:25:36] <Compn> is redline out yet ? [02:26:10] <lu_zero> haruhi is a book... [02:26:19] <Dark_Shikari> Haruhi has an anime or three. [02:26:32] <lu_zero> Dark_Shikari: it's a damn scrambled book [02:26:32] <iive> Dark_Shikari: you may have missed it, but reimer had some valid complains. He didn't said it, but 3 of his patches are just hanging. not rejected, not pushed, no further reviewed. [02:26:36] <lu_zero> then an anime [02:26:39] <bcoudurier> I don't know about this "pushers" thing anyway [02:26:39] <lu_zero> then a religion [02:26:50] <Dark_Shikari> iive: which ones? I can go comment on them [02:26:58] <bcoudurier> why should specific people be more trusted than some others ? [02:27:02] <iive> ogm 21 jan [02:27:09] <lu_zero> iive: we got patchwork for that... [02:27:28] <Compn> bcoudurier : some idea about those people know more about git and wont fuck git repo up by doing a wrong rebase or something [02:27:29] <iive> i think they were missing for some reason. [02:27:34] <lu_zero> bcoudurier: other way round [02:27:40] <Dark_Shikari> I don't think I'm qualified to comment on ogg demuxer stuff. [02:27:41] <Dark_Shikari> Who is>? [02:27:53] <lu_zero> mru wrote one [02:27:54] <Compn> Dark_Shikari : everyone hates ogg stuff [02:27:59] <bcoudurier> other way round ? [02:28:01] <lu_zero> I ported it to ffmpeg [02:28:01] <iive> mans [02:28:18] <bcoudurier> it seems to me that maintainers should have pushing rights [02:28:23] <lu_zero> bcoudurier: the people merging stuff are just doing it [02:28:31] <lu_zero> so is basically manual labor [02:28:36] <lu_zero> (and I know I'm slacking) [02:28:42] <bcoudurier> looks like a maintainer job [02:28:49] <bcoudurier> + some patch monkeys [02:29:06] <lu_zero> maintainer job -> reviewing [02:29:09] <Compn> like svn was ? [02:29:23] <Compn> just say you want svn rules :p [02:29:26] <j-b> Well, sorry, but it is ridiculous that the maintainer of FFmpeg is not paid to do that full time [02:29:27] <bcoudurier> so no maintainers can be pushers ? [02:29:37] <Dark_Shikari> j-b: I agree [02:29:55] <j-b> and I mean it [02:29:56] <lu_zero> bcoudurier: the idea is to have a second person push (and test) [02:30:01] <bcoudurier> this "pushers" list looks more and more like a way to "control" the project [02:30:12] <iive> well, now that there is dialog, I think I can get some sleep [02:30:12] <j-b> FFmpeg is one of the most important project, maybe after the kernel [02:30:16] <Compn> j-b : no offense, but putting the money thing into the middle of this isnt helping, i dont think [02:30:21] <j-b> and maybe before [02:30:27] <Compn> because i dont remember michael ever asking for money [02:30:36] <j-b> Compn: I don't mean money, I mean time [02:30:45] <Compn> what [02:31:03] <bcoudurier> j-b, I agree [02:31:20] <j-b> the one coordinating the merges and so one should be fulltime 50hours a week on that [02:31:23] <iive> n8 ppl [02:31:27] <Compn> oh i see [02:32:14] <lu_zero> j-b: the idea was to spend one day per week every pusher [02:32:17] <lu_zero> more or less [02:32:35] * Compn is exhausted from ffmpeg talks going nowheres [02:33:18] <uau> j-b: the problem with that is that there's no accepted "the maintainer", _especially_ when it comes to stuff like managing merges [02:34:00] <j-b> uau: sure, and sorry, but seeing the actual status, it cannot be michaelni, nor mru. It must be someone a bit more neutral [02:34:01] <michaelni> lu_zero, i can spend 7 per week :) you need more pushers [02:34:18] <Dark_Shikari> j-b: I agree [02:34:19] <michaelni> btw, i like to see diego push and review [02:34:30] <j-b> uau: and probably not the best coder, but the one beeing the best at understanding most parts [02:34:34] <lu_zero> michaelni: he did already [02:34:38] <Dark_Shikari> j-b: DEFINITELY not the best coder [02:34:41] <Dark_Shikari> the time of the best coders is too valuable. [02:35:09] <Compn> i dont think there is anyone like that of the group [02:35:16] <j-b> uau: maybe kernel like submaintainer trees and pulling trees [02:35:17] <lu_zero> Makefile and config bits got reviewed by him [02:35:21] <Compn> the coders like that either have jobs already due to ffmpeg work [02:35:37] <Compn> we should hire linus [02:35:44] <j-b> :) [02:36:01] <uau> i kind of wondered myself why diego was among the "pushers" as his technical skills don't seem up to par for that (if it's really supposed to be "knowledgeable people") [02:36:08] <uau> but i guess that's orthogonal to the main discussion [02:36:14] <j-b> and michaelni's knowledge is way too important to let michaelni go away for stupid bullshit political fight [02:36:18] <bcoudurier> uau, because this list is weird [02:36:28] <j-b> (that goes also for mru in the past) [02:36:40] <bcoudurier> and seems more like "friends" than anything else [02:36:41] <j-b> Compn: jobs can be changed :D [02:36:53] <Dark_Shikari> bcoudurier: I'm not sure why I'm on the list. [02:37:06] <Dark_Shikari> so far my assumption is "because I was put on the list" is the best answer. [02:37:08] <lu_zero> bcoudurier: people volunteering that had already experience on that kind of tasks [02:37:16] <lu_zero> diego does that as job now... [02:37:23] <uau> j-b: i think there isn't enough development in most sub-areas to be worth separate "submaintainer trees" [02:37:59] <j-b> Compn: I am sorry, but from an external point of view, maybe BBB or lu_zero seem more "calm downed" people [02:38:07] <j-b> uau: are you sure? [02:38:22] <bcoudurier> janne and diego seems like a good pair [02:39:01] <j-b> uau: lavf, lavfi, lavio, libavc/core, libavc-x86, libavc-neon, libavutils/core [02:39:45] <j-b> uau: I am not telling you guys what you should do, I am just giving ideas, please don't take it in any other way [02:39:51] <bcoudurier> j-b, yes that would be reasonable [02:40:46] <uau> j-b: i don't count myself as a real ffmpeg developer (re "you") [02:40:53] <bcoudurier> http://pastebin.com/ByUCwL5g [02:41:00] <bcoudurier> can someone fix the compilation quickly ? [02:41:08] <j-b> uau: nor me :D [02:41:20] <j-b> uau: it was a general "you" [02:41:45] <lu_zero> bcoudurier: did you re-run configure? [02:41:54] <bcoudurier> it's not from me [02:42:03] <bcoudurier> <pasteeater> looks like d36beb3 is causing some issues with ubuntu users. [02:42:03] <bcoudurier> <pasteeater> http://pastebin.com/ByUCwL5g [02:42:03] <bcoudurier> <pasteeater> resolved by --disable-vaapi [02:42:11] <bcoudurier> that's what you get for not being in #ffmpeg ;) [02:42:20] <lu_zero> not reading [02:44:20] <uau> Dark_Shikari: you being on the list at least seems mostly logical as you've done similar things with x264 [02:45:40] <lu_zero> uau: and since it's a pain he has enough with x264 alone ^^; [02:47:57] <Compn> Dark_Shikari : michaels request to have both repos equal on the page is here > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/103580.html [02:48:20] <Compn> Dark_Shikari : unless you meant something else ? [02:48:57] <bcoudurier> thanks lu_zero [02:50:40] <BBB> hey skal :-p [02:54:06] <skal> hey :) [02:54:17] <skal> heard some noise, saw some light, came in. :) [02:55:56] * j-b offers beer to skal [02:56:54] <skal> hey, ain't Friday yet [02:56:59] <skal> but accepted [02:57:35] <lu_zero> hi skal [02:57:58] <bcoudurier> I have crown royal on my desk [02:58:57] <skal> hey lu_zero [02:59:14] <skal> got a "Corsendonk" here (not opened ;)) [03:02:02] * lu_zero should have a 12 and an enkir somewhere [03:02:10] <Sean_McG> .... [03:02:18] * lu_zero right now likes more the water next to him [03:02:54] <Sean_McG> oh your good friend Al [03:02:55] <Sean_McG> Cohol [03:04:52] <saintdev> better than my friend Sal [03:04:57] <saintdev> Monella [03:05:20] <Sean_McG> he mafioso? [03:11:43] <lu_zero> bcoudurier, j-b, somebody with vaapi or dxva could test and report back ^^? [03:19:01] <skal> heading home, back later [03:20:50] <Dark_Shikari> uau: I don't do enough ffmpeg stuff though [03:27:23] <Dark_Shikari> some people here wrote 5 decoders, I didn't even write one [03:30:48] <Compn> Dark_Shikari : you see that earlier message ? [03:31:10] <Dark_Shikari> which one? [03:31:59] <Compn> > Dark_Shikari : michaels request to have both repos equal on the page is here > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/103580.html [03:32:15] <Dark_Shikari> oh that. [03:32:31] <Compn> well you asked , in an angry tone :P [03:32:52] <Compn> or maybe frustrated tone [03:32:53] <Compn> who knows [03:59:15] <BBB> Dark_Shikari: can you write us a h265 decoder? [04:01:31] <astrange> ffcelt? [04:01:43] <Dark_Shikari> ïœïœïœïœïœïœïœïœïœïœïœïœïœïœïœïœïœïœïœïœ [04:02:27] <saintdev> ffceltenc just as bad as ffaacenc, but lower latency! [04:02:52] <saintdev> although that would be kind of hard to do... [04:02:56] <Dark_Shikari> it's impossible to write a bad celt encoder [04:03:00] <Dark_Shikari> too much is hardcoded in the bitstream [04:03:02] <Dark_Shikari> same as with ac3 [04:03:08] <saintdev> i just thought that after i typed it, lol [04:03:15] <Dark_Shikari> I mean, it's impossible to write a bad one unless you actively sabotage it [04:03:26] <saintdev> "wait, you would have to REALLY screw things up to manage that" [04:03:40] <BBB> ffcelt is fun [04:03:42] <BBB> can you do that? [04:03:52] <BBB> maybe I should learn new audio tricks by doing that [04:04:02] <BBB> I guess celt should be in int? [04:04:08] <Dark_Shikari> it has a fixed and float mode [04:04:28] <BBB> decoder or bitstream mode? [04:04:32] <Dark_Shikari> both [04:04:34] <Dark_Shikari> afaik [04:04:40] <BBB> so bitstrea [04:04:42] <Dark_Shikari> I mean, it doesn't affect the format of the bitstream [04:04:50] <Dark_Shikari> but it's intended to be symmetrical [04:04:54] <Dark_Shikari> for minimum mismatch error [04:05:05] <BBB> weird [04:05:10] <Dark_Shikari> afaik [04:05:14] <Dark_Shikari> well, I mean it's only natural, right [04:05:17] <Dark_Shikari> no bitstreams actually use float [04:05:19] <Dark_Shikari> even, say, mp3 [04:05:35] <BBB> true [04:05:48] <peloverde> what about that xiph unpack float madness? [04:08:42] <peloverde> mru: I thought you used to object to removing add_bias? [04:08:48] <mru> never [04:09:00] <mru> I want to keep the scale [04:09:12] <mru> since it's free in most decoders [04:09:20] <mru> as part of transform or windowing [04:10:06] <peloverde> is the comment in dsputl.h correct? It seems to imply after this patch they will both use the same scale [04:10:54] <mru> that's a different thing [04:11:10] <mru> some people wanted to make all decoders output float in -1..1 range [04:11:26] <mru> and then convert it to s16 with some horrid c code after [04:11:49] <mru> I want to keep the option of outputting +-32k range even if in float [04:11:58] <mru> to make conversion to int easier [04:12:23] <mru> does that make sense? [04:13:17] <peloverde> yes [04:13:45] <mru> and I've already painstakingly written neon code for pre-scaled float to int [04:14:16] <Dark_Shikari> why is float->int faster if pre-scaled? [04:14:24] <mru> no need to multiply [04:14:41] <mru> out=in is faster than out=scale*in [04:16:55] <mru> 4-cycle latency doesn't make it easier [04:18:08] <Dark_Shikari> how fast is float -> int16_t (the actual conversion)? [04:18:38] <mru> almost all neon float operations have 4 cycles latency [04:19:05] <Dark_Shikari> is there a 4xfloat -> 4x int16_t? [04:19:12] <Dark_Shikari> or do you have to do -> 4x int32_t and then convert to 16? [04:19:22] <mru> look at the code [04:19:35] * Dark_Shikari is lazy [04:19:38] <mru> it can only issue 2x per cycle [04:20:07] <mru> I don't quite remember the details, but I did some trickery with 16.16 fixed-point [04:20:22] <mru> for some of them at least [04:20:31] <mru> made the interleaving easier [04:22:03] <mru> then I could use a 32-bit shift and insert instruction [04:57:17] <Dark_Shikari> what the crap, am I blind or is something weird going on [04:57:24] <Dark_Shikari> This code works: [04:57:25] <Dark_Shikari> shr edx, cl [04:57:25] <Dark_Shikari> add al, byte [table + rcx] [04:57:25] <Dark_Shikari> shr edx, 1 [04:57:26] <Dark_Shikari> jne .loop [04:57:32] <Dark_Shikari> This code fails the test: [04:57:33] <Dark_Shikari> shr edx, 1 [04:57:33] <Dark_Shikari> add al, byte [table + rcx] [04:57:33] <Dark_Shikari> shr edx, cl [04:57:34] <Dark_Shikari> jne .loop [04:57:46] <Dark_Shikari> ... how can that possibly.... wtf [04:58:52] <Sean_McG> what's in edx before the first shift? [04:59:08] <Dark_Shikari> shouldn't matter, should it? [04:59:15] <Dark_Shikari> It's a bitmask up to 16 bits long. [04:59:26] <Dark_Shikari> ecx is the result of a "bsf" call (trailing zeroes) [05:01:03] <pengvado> the effect of shr on flags depends on how much you shift [05:01:11] <Dark_Shikari> But ne/e only depends on the result. [05:03:00] <pengvado> >>0 doesn't set flags, not even ZF [05:03:10] <Dark_Shikari> ahhhhhh [05:03:22] <Dark_Shikari> that's tricky [06:12:43] * elenril yawns [06:12:48] <elenril> wow, :drama; [06:14:41] <kshishkov> yawn indeed [06:14:45] <ohsix> o rly [06:18:33] <thresh> moroning [06:20:02] <kshishkov> good morning (and a wonderful near-Moscow morning to you) [06:22:02] <thresh> I'm trying to fight that bad feeling of mornings [06:22:20] <thresh> Installed that Sleep Analyzer application, it's supposed to wake me up softly [06:22:28] <kshishkov> did you have that many bad mornings in Andorra? [06:22:54] <thresh> not really [06:23:08] <thresh> mountain view somehow fixes that [06:24:04] <Sean_McG> mornings suck [06:25:42] <kshishkov> thresh: and probably they didn't end with work :) [06:26:33] <thresh> kshishkov: very much so [06:30:41] <elenril> michaelni: you should try http://tvtropes.org/pmwiki/pmwiki.php/Main/EvilLaugh [06:38:06] <Tjoppen> morrn [06:38:19] <pJok> god morgon [06:48:54] * elenril recompiles the whole tree again [06:48:57] <_av500_> moin [06:48:58] * elenril glares at Flameeyes [06:49:15] <_av500_> Flameeyes: flameeye elenril! [06:49:48] * _av500_ offers elenril some cheese: http://www.flickr.com/photos/av500/5388262880/ [06:50:09] <thresh> _av500_: well elenril didnt elenril Flameeyes, so why would Flameeyes flameeye elenril? [06:50:32] * elenril retaliates with a http://tvtropes.org/pmwiki/pmwiki.php/Main/LargeHam [06:51:57] <_av500_> thresh: because he can? [06:57:19] <Sean_McG> how very meta [07:02:40] <siretart> /build/buildd/ffmpeg-0.7~daily~27417+201101262353~natty1/libavcodec/allcodecs.c:57: undefined reference to `ff_h263_vaapi_hwaccel' [07:02:51] <siretart> known, transient problem? didn't happen yesterday [07:05:16] <astrange> patch is in[FFmpeg-devel] [PATCH] Add ff_ to AVHWAccel decoders [07:05:27] <siretart> ah, thanks [08:02:36] <cartman> moin [08:11:17] <superdump> morning [08:11:38] <spaam> godmorgon [08:11:43] <elenril> o/ [08:13:30] <cartman> Android 3.0 Preview \o/ [08:19:34] <wbs> cartman: what, where? [08:19:42] <wbs> ugh, took quite a while to read the backlog from last night ;P [08:20:11] <wbs> and \o/ for android NDK r5b - my __asm__ patch is one of the "highlights" of the bugfix release :-) [08:20:45] <cartman> wbs: yup, thanks for that! :) [08:21:45] <KotH> moin [08:22:53] <cartman> elow KotH [08:28:40] <KotH> hoi michaelni [08:28:50] <KotH> michaelni: was hat dich denn hier her verschlagen? :) [08:29:24] <Dark_Shikari> sollen wir deutsch sprechen? [08:29:39] <KotH> nihongo mo ii yo [08:29:50] <Dark_Shikari> weil michaelni an irc ist, wir sollen immer deutsch sprechen. [08:29:56] <kshishkov> KotH: nej, man mÃ¥ste pratar pÃ¥ svenska hÃ€r [08:30:32] <pJok> KotH, wakarimasen [08:30:32] <Dark_Shikari> KotH: æ¥æ¬èª [08:30:34] <kshishkov> Dark_Shikari: ãã«ãã«ããããã [08:30:35] <Tjoppen> japp, svenska Ã€r det official ffsprÃ¥ket [08:30:46] <Tjoppen> *officiella [08:30:52] <Dark_Shikari> kshishkov: ________shii__ne__ (only know 30 kana) [08:30:56] <kshishkov> officiellt? [08:31:19] <kshishkov> Dark_Shikari: skÃ€ms, du kan lÃ€ra mer [08:34:22] <kshishkov> Dark_Shikari: och jag har inget tid att anvÃ€nda tyska [08:34:31] <Dark_Shikari> ich kann das Sprache nicht sprechen [08:34:38] <Dark_Shikari> oder, nicht lesen [08:35:11] <siretart> wbs: I guess he's referring to http://android-developers.blogspot.com/2011/01/android-30-platform-preview-… [08:35:12] <pJok> hehe [08:35:21] <pJok> Dark_Shikari, die Sprache [08:35:45] <wbs> siretart: ah, thanks [08:35:52] * pJok needs to kick himself some more and study more japanese [08:35:56] <siretart> scheiss auf grammar :-) [08:36:11] <Dark_Shikari> Ich werde die Articlen fast immer vergessen. [08:36:22] <kshishkov> siretart: und Deutsche WÃ¶rter sind zu kurze [08:36:43] <pJok> kshishkov, biste schwÃ€bish? [08:36:52] <kshishkov> pJok: absolut inte [08:37:03] <colde> haha [08:37:14] <pJok> morn colde [08:37:20] <colde> morning pJok :) [08:37:25] <kshishkov> pJok: jag vill gÃ€rna gÃ¥ till Norrland att leva [08:37:48] <colde> pJok: hows your swedish? :) [08:38:08] <superdump> att leka [08:38:53] <royger> does ffmpeg know the number of frames an input video has? [08:38:55] <kshishkov> superdump: du kan leka men jag vill leva i Norden [08:39:04] <andoma> kshishkov: "gÃ¥" in swedish is more like "walk" rather than "go" [08:39:04] <pJok> colde, det Ã€r faktiskt bra :) [08:39:06] <Tjoppen> kshishkov: gÃ¥ till norrland frÃ¥n tyskland? lite vÃ€l lÃ¥ngt :) [08:39:11] <colde> Norden er ogsÃ¥ et fint sted at vÃŠre :) [08:39:14] <andoma> walking to norrland is gonna take a while .. [08:39:16] <superdump> Ã¥ker [08:39:34] <av500> royger: depends [08:39:45] <superdump> andoma: Ã¥ker would be a better word, right? [08:39:51] <kshishkov> Tjoppen: jag kan gÃ¥ genom Danemark eller ta tÃ¥get [08:40:08] <superdump> Ã¥ka [08:40:11] <superdump> :) [08:40:12] <andoma> yes [08:40:34] <kshishkov> andoma: well, it took me two pendeltÃ¥g at most [08:40:39] <colde> kshishkov: you would need a boat/ship as well though :) [08:40:57] <kshishkov> colde: ever heard of Ãresundsbron? [08:40:59] <colde> well, actually not, since you could go through jutland [08:41:01] <colde> yeah [08:41:03] <royger> av500: the input video is mpeg2, could you please tell me where can I find it? [08:41:08] <colde> i just kinda remembered :) [08:41:29] <kshishkov> colde: do they teach anything at Danish schools? [08:41:38] <colde> Nope [08:41:51] <colde> This is why we come here afterwards. To learn stuff :) [08:42:32] <kshishkov> at least my Ukrainian school gave good training as a sweeper/street cleaner [08:42:35] <spaam> andoma: but far and fara are better then go :) [08:43:37] <colde> kshishkov: haha :D [08:44:29] <kshishkov> colde: I'm serious [08:45:17] <colde> Really? Thats slightly scary then [08:46:01] <av500> royger: in what container? [08:47:20] <pJok> kshishkov, at least you speak english and you're getting somewhere with swedish [08:48:05] <royger> av500: AVCodecContext or MpegEncContext would be great [08:48:28] <kshishkov> colde: we had to clean all school territory several times a year for example. [08:48:52] <kshishkov> pJok: they mostly teach to hate foreign languages but I failed :( [08:48:59] <av500> royger: no, your mpeg2, in what container is it? [08:49:15] <pJok> kshishkov, that just means you're a progessive one [08:49:32] <colde> kshishkov: crazy [08:49:37] <royger> av500: m2v or mpg usually [08:50:22] <av500> these must be parsed completely to get the number of video frames [08:50:44] <royger> av500: no luck then, thanks anyway [08:59:46] <thresh> siretart: which git do you use for 0.7~ debian packages? [09:00:53] <siretart> thresh: I use lp:ffmpeg, which is a bzr branch that imports from git.ffmpeg.org [09:02:07] <thresh> so you chose the jedi side? [09:02:09] <thresh> :) [09:02:57] <av500> wasnt it the dark side? [09:02:59] <superdump> andoma, kshishkov: would 'bo' be a better word for 'live' instead of 'leva' in : jag vill leva i Norden? [09:03:21] <CIA-38> ffmpeg: Luca Barbato <lu_zero(a)gentoo.org> master * rd1b6f33bf2 ffmpeg/libavcodec/ (7 files): [09:03:21] <CIA-38> ffmpeg: Add ff_ to AVHWAccel decoders [09:03:21] <CIA-38> ffmpeg: That unbreaks compilation of vaapi and dxva2 [09:03:21] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [09:04:22] <thresh> av500: dark side never had so many followers [09:04:51] <kshishkov> superdump: http://sv.wikipedia.org/wiki/Du_gamla,_du_fria#Texten [09:05:21] <peloverde> g.ff.o is probably more amenable to releases [09:05:40] <kshishkov> thresh: hmm, are you implying there's Darth Michaelius? [09:05:58] <kshishkov> peloverde: only because it has people caring about releasing [09:06:10] <superdump> kshishkov: ah, thanks :) [09:06:23] <peloverde> let's not try to be too hostile with this jedi/sith nonsense [09:06:41] <superdump> though i expect leva is used there for poetic purposes :) [09:06:48] * av500 wants the ewok friendly ffmpeg [09:06:56] <kshishkov> peloverde: it's just in my habit to ridicule everything [09:07:34] <thresh> kshishkov: haha [09:08:02] <superdump> it's very true, kshishkov does ridicule everything [09:08:04] <superdump> :) [09:08:05] <peloverde> many of these somehow get twisted into serious discussion on the ml [09:08:12] <kshishkov> superdump: leva is more like general "to live" and bo is "to live somewhere" but I don't think you have such division in English [09:08:31] <thresh> yeah sorry. [09:08:41] <superdump> kshishkov: no, it would have be expressed through the way one stresses the word in the sentence [09:09:02] <superdump> like: i want to _live_ in the north [09:10:59] <kshishkov> anyway it's completely true [09:11:20] <superdump> :) [09:11:31] <superdump> at least we both understand the nuance [09:12:44] * kshishkov also tried to understand nuances of Julmust tastes, found that julmust from Norrland is the best [09:14:14] <superdump> any particular brand? [09:14:38] <superdump> kshishkov: i highly recommend hjortron glÃ¶gg [09:15:34] <kshishkov> superdump: somehow I dislike glÃ¶gg part there [09:15:45] <kshishkov> Zeunerts and Vasa of course! [09:16:06] <superdump> you can get non-alcoholic glÃ¶gg [09:16:08] * kshishkov remebers he still has a jar of hjortronsylt [09:24:36] <wbs> elenril: the asfdec patch you posted, could you test it to make sure it doesn't break rtsp-ms/rtpdec_asf decoding? (not sure how much it touches that area, it might possibly) [09:25:00] <wbs> elenril: you can try one of the ms-rtsp sample urls at http://wiki.multimedia.cx/index.php?title=RTSP#Samples_in_the_wild [09:40:34] <elenril> wbs: i don't see how it could possibly break anything other than metadata [09:40:44] <elenril> but tested with two samples, they work fine [09:40:56] <wbs> ok, good [09:40:56] <elenril> s/fine/as well as without the patch/ [09:41:01] <wbs> :-) [09:41:47] <j-b> 'morning [09:42:02] <wbs> I didn't check what it affected, but it sounded like it possibly could... since asf data is fed a little at a time via a special byteiocontext from the rtpdec layer to the asf demuxer.. and changes in how much is read per packet could screw something up in those cases [09:50:41] <merbzt> elenril: I think I have an old asf metadata patch some where [09:59:20] <merbzt> elenril: patch sent [10:52:33] <j-b> av500: http://magsoft.dinauz.org/videolan/vlc-android/vlc-neon.apk [10:54:37] <cartman> j-b: supports 2.2? [10:54:46] <j-b> yes, sir [10:54:54] <cartman> j-b: you guys are awesome :D [10:55:23] <j-b> we are not [10:55:23] <cartman> http://img408.imageshack.us/img408/6885/screenshot20110127at125.png hehe [10:55:34] <thresh> j-b: does it work? [10:55:47] <cartman> j-b: link not working though :S [10:55:57] <j-b> works for me [10:55:57] <thresh> worksforme [10:56:05] * cartman blames .tr [10:56:06] <thresh> well at least downloads, I have no device to test [10:56:31] <av500> j-b: cool GUI!!! [10:56:37] * cartman tries from USA [10:56:39] <j-b> av500: pff :) [10:56:57] <cartman> av500: screenshot! [10:57:15] <av500> sec [10:57:41] <av500> cartman: http://blog.justpulse.com/wp-content/uploads/2009/04/cone-soppera10.png [10:57:44] <mru> j-b: do you think courmisch will allow vlc on android? [10:57:47] <av500> it more or less looks like that [10:57:57] <av500> mru: yes, androuis is "open" [10:57:59] <cartman> av500: looks awesome [10:58:02] <j-b> mru: well, well, yes [10:58:08] <j-b> mru: on the Market, I don't know yet [10:58:18] <thresh> Failure [INSTALL_FAILED_INVALID_APK] [10:58:21] <thresh> or htc hero [10:58:43] <cartman> thresh: truncated zip [10:58:58] <thresh> hum? [10:59:02] <thresh> unzip worked fine here [10:59:24] <thresh> ah [10:59:27] <thresh> lib/armeabi-v7a/libvlcjni.so [10:59:31] <cartman> v7 [10:59:32] <cartman> :P [10:59:33] <thresh> that probably explains as htc hero is v6 [10:59:39] <av500> j-b: it has to be a .mp4? [11:00:07] <roxfan> "neon" in the name was a hint of sorts [11:00:24] <thresh> :p [11:00:41] <j-b> av500: it is just a test for the vout, so yes, we only test with the Mr_MrsSmith sample [11:00:46] <j-b> av500: but yo can try anyhting [11:00:57] <av500> url to your sample? [11:01:05] <av500> i lost it [11:01:10] <j-b> http://streams.videolan.org/streams-videolan/mp4/Mr_MrsSmith-h264_aac.mp4 [11:02:15] <av500> plays [11:02:22] <kurosu> thresh: http://magsoft.dinauz.org/videolan/vlc-android/vlc.apk I guess [11:02:45] <av500> now some 720p... [11:02:49] <cartman> av500: :D [11:03:03] <j-b> 720p, I doubt [11:03:18] <kurosu> tested on my samsung phone, no sound output, no video scaling (broken gl on it though), crash when changing mode and trying to replay test.mp4 [11:03:31] <cartman> pffft phone [11:03:38] <cartman> will test on Samsung Tab :P [11:03:43] <j-b> kurosu: expected yes [11:03:55] <kurosu> j-b: guessed so [11:04:14] <av500> j-b: hardcoding /sdcard is wrong btw, you have to use Environment.something() [11:04:22] <av500> getExternalStorage() or something like that [11:04:26] <kurosu> samsung tab or s are beast regarding hardware [11:04:41] <cartman> kurosu: its scary fast [11:04:49] <cartman> 2.x UI sucks for tablet though [11:04:49] <av500> j-b: http://developer.android.com/reference/android/os/Environment.html#getExter… [11:04:53] <j-b> kurosu: sound is broken and the biggest part those days is to check that the video is actually outputed [11:04:56] <thresh> kurosu: that's a normal behaviour for desktop version, why would you expect vlc on android to work better? :) [11:05:41] <kurosu> j-b: all the more since android and many real devices have absurdly large delays [11:05:56] <av500> j-b: I like your .mp4 debug output :) [11:06:43] <av500> j-b: it crashes with 720p [11:06:50] <j-b> kurosu: I mean, it is work in progress :) [11:06:53] <j-b> av500: sample? [11:07:04] <av500> some random 720p anime [11:07:12] <cartman> j-b: did you guys found a fast way to do yuv->rgb conversion? [11:07:25] <mru> cartman: yes, using hw [11:07:27] <mru> :) [11:07:35] <j-b> cartman: I don't think we do that yet [11:07:37] <cartman> mru: bah :) [11:07:39] <cartman> j-b: ah ok [11:08:11] <cartman> mru: I think TI chips do have a hw function to do it? [11:08:13] <cartman> read somewhere [11:08:15] <av500> j-b: looks like oom error [11:08:28] <mru> cartman: _all_ chips have it [11:08:28] <kurosu> j-b: and I meant that even with a working implementation, audio/video synch might be a tough one [11:08:41] <cartman> mru: all what chips? :) [11:08:52] <j-b> cartman: well, before our vout was 2.3 only [11:08:55] <av500> j-b: http://ffmpeg.pastebin.com/vFDaxRvX [11:08:59] <mru> cartman: all chips capable of displaying an image [11:09:01] <j-b> cartman: so now, we are doing 2.2 too [11:09:03] <cartman> mru: oh [11:09:13] <cartman> j-b: yup I know, I think 2.3+ will be more fun :) [11:09:21] <mru> of course a 74LS74 doesn't have one [11:09:34] <av500> maybe the 74LS565? [11:09:35] <cartman> mru: but its not exposed for most chips? [11:09:48] <av500> or the 74LS420 [11:09:54] <mru> android doesn't expose it [11:10:00] <cartman> bandroid [11:10:02] <cartman> :P [11:10:08] <j-b> cartman: GLSL maybe can help [11:10:12] <mru> lol [11:10:19] <mru> xbmc guys tried that [11:10:23] <mru> managed a few fps [11:10:23] <cartman> j-b: there are some examples for that yes [11:10:33] <mru> it eats memory bandwidth like crazy [11:10:39] <j-b> cartman: well, at least, we are not regressing :) [11:10:42] <cartman> j-b: or we can force mru to donate his neonized magic for that [11:11:06] <j-b> I have a level+10 in god invocation, if you want [11:11:08] <mru> hw is still faster [11:11:14] <cartman> j-b: lol [11:11:23] * mru is an atheist, won't work [11:11:32] * cartman is agnostic, who cares [11:11:50] <kshishkov> mru: what about commandments like "thou shall not memcpy()"? [11:12:17] <cartman> j-b: anyhow I'll let you know when I test on Galaxy Tab [11:12:22] <cartman> Boss took it away again [11:12:32] <av500> clever boss [11:12:49] <cartman> how clever for not letting me work [11:12:53] <cartman> and still get paid [11:12:55] <cartman> looks stupid [11:13:01] <j-b> av500: I'll try the non-neon version on a 720p then [11:13:40] <mru> kshishkov: http://26-26-54.hardwarebug.org/0 [11:13:57] <cartman> nice [11:14:21] <superdump> can't some video output be written to use the android apis? (surface flinger iirc) [11:14:34] <mru> those are rgb only [11:14:35] <mru> iiuc [11:14:36] <cartman> superdump: that needs RGB data [11:14:44] <superdump> one would have to hook into the hardware for colorspace conversion [11:14:53] <cartman> Android geniuses forgot about YUV [11:15:00] <superdump> yeah [11:15:05] <mru> just mimicking apple [11:15:23] <av500> j-b: non neon does not crahs [11:15:26] <cartman> hmm iOS doesn't do it in hw either? [11:15:32] <superdump> but is there some other way to output YUV without converting? [11:15:40] <mru> cartman: probably does with their own sw [11:15:48] <mru> but it's not a public interface [11:15:50] <superdump> i guess it will be converted somewhere along the way anyway to be composited [11:15:55] <cartman> mru: ah, expected [11:16:00] <mru> there is a private ios api that does it [11:16:01] <superdump> assuming you aren't using fullscreen [11:16:06] <mru> someone figured out how to do it [11:16:23] <mru> superdump: hw alpha blending [11:16:40] <superdump> mru: can accept multiple colorspaces? [11:16:55] <superdump> why am i writing color and not colour? damnit [11:17:05] <mru> of course it can [11:17:11] <mru> the blending happens after conversion [11:17:23] <superdump> ah, ok [11:17:27] <lu_zero> mru: do you have more info on it? [11:17:38] <mru> pick you omap trm [11:17:40] <mru> your [11:17:58] <mru> lu_zero: or info on what? ios? [11:18:00] <superdump> solutions have to be worked out per chip though [11:18:07] <cartman> ask av500 , his media player is super fast :D [11:18:21] <lu_zero> yes [11:19:08] <superdump> as there's no android api to accept buffers in random colourspaces and do the hardware alpha blending [11:19:11] <superdump> afaik [11:19:32] <superdump> but then, converting and using the android surface flinger api would have to be done per chip too [11:19:35] <superdump> pain [11:19:42] <superdump> omap ftw [11:20:06] <mru> why would the api have to be per chip? [11:20:16] <superdump> no the api wouldn't [11:20:26] <cartman> the conversion is simple math [11:20:30] <mru> of course drivers are per-chip [11:20:36] <superdump> but whatever interacts with the chip's drivers to do one thing or another would have to be per chip [11:20:37] <superdump> right [11:20:45] <mru> the horror [11:20:49] <mru> have to do _work_ [11:21:17] <superdump> although at the european celf, it seems v4l work is being done to expose such hardware and capabilities in some kind of graph-able way [11:21:34] <superdump> and some of that work is going into linux 2.6.38 [11:22:19] <mru> v4l2 already exposes the necessary bits in a hw-independent way [11:22:31] <mru> (nevermind no two drivers actually behaving alike) [11:22:46] <kshishkov> and there was GATOS [11:23:02] <superdump> hmm [11:23:20] <superdump> when i say v4l, i mean v4l2 (who cares about v4l1 anymore?) [11:24:04] <superdump> anyway, something like that is the way forward i guess as long as it's done well and the drivers behave (...yeah, i'm crossing my fingers) [11:24:19] <superdump> or screw everything and use omap [11:24:20] * pross-au questions the need for so many different hardware drivers. guessing that the driver development profession is unionised. [11:24:52] <kshishkov> pross-au: because there are so many HW companies [11:25:08] <superdump> and each hardware does stuff its own way [11:25:14] <kshishkov> and driver development seems to be in-house [11:25:19] <superdump> yup [11:27:45] <mru> kshishkov: nokia wrote the display drivers for omap [11:28:05] <j-b> mru: http://www.google.com/mobile/android/market-tos.html seems way more open, seeing §3.8 [11:28:15] <superdump> they're still closed because of powervr though, right? [11:28:33] <mru> superdump: the display drivers are open as can be [11:28:40] <mru> sgx is mem to mem only [11:28:40] <superdump> oh [11:29:14] <superdump> why do i remember people bitching about sgx drivers then? [11:29:23] <mru> because those are closed [11:29:37] <mru> but you don't need to touch sgx to display video [11:29:46] <superdump> oh really? [11:29:49] <superdump> interesting [11:30:03] <mru> sgx renders into whatever buffer you tell it [11:30:12] <mru> you don't need to use it at all [11:30:20] <superdump> so you can do the same using a general purpose cpu [11:30:25] <mru> of course [11:30:26] <superdump> fun [11:30:31] <mru> it's faster for 3d of course [11:30:37] <superdump> i saw that the sony NGP has a quad core cortex-A9 [11:30:51] <mru> nice [11:30:55] <superdump> yeah [11:30:56] <superdump> :) [12:06:42] <mru> lyakh: ping [12:14:35] <cartman> wbs: I am not indian anymore, reported another useful Android bug :P [12:14:55] <wbs> cartman: good boy *tap on head* ;P [12:15:07] <cartman> I am probably older than you :P [12:15:16] <wbs> most certainly, yes :-) [12:15:38] <cartman> now the toolchain bug that mru's stuff exposes [12:15:42] <cartman> that'll be harder to report [12:15:44] <merbzt> I still think you appreciate a good tap [12:15:48] <cartman> merbzt: yeah [12:16:23] <mru> age is irrelevant on irc [12:17:09] <mru> cartman: what bug is that? [12:17:11] <cartman> http://code.google.com/p/android/issues/detail?id=14348 [12:17:24] <cartman> mru: static bug thing [12:17:41] <mru> the attribute(((((used)))))? [12:17:46] <cartman> mru: yup [12:18:03] <cartman> that looked like LISP btw. [12:19:00] <mru> no, that would be (attribute '(used . t)) [12:19:29] <kshishkov> cartman: they've been forcing parentheses uage for a reason since ages [12:19:45] <kshishkov> mru: you can use a macro [12:19:48] * cartman wonders the reason [12:20:13] <kshishkov> it was voices somewhere - some GCC dev is LISPer and tried to make it homey [12:20:39] <cartman> must be Tom Tromey, the emacs man [12:21:13] <kshishkov> BTW, when Stallman was young (but had those "freedom" ideas already) he was heavy into list [12:21:16] <kshishkov> *lisp [12:21:55] * kshishkov wonders if Stallman can also be called "the emacs man" [12:24:44] <lu_zero> mru: which time you'll arrive and depart from bruxelles? [12:25:31] <mru> arrive fri 16:55 [12:25:40] <mru> depart mon 13:30 [12:26:06] <thresh> anyone on thursday? [12:26:54] <kshishkov> mru: are you taking train? [12:27:00] <mru> plane [12:27:11] <mru> train from airport to city of course [12:27:35] <kshishkov> then why do you mention such precise times? [12:27:54] <kshishkov> planes overall are even less punctual than German trains [12:28:09] <mru> just quoting the flight booking [12:28:49] <kshishkov> do you believe it? [12:29:05] <mru> it's realistic [12:29:35] <mru> if there's no bad weather they should make it [12:29:49] <mru> SOU isn't very crowded [12:30:05] <kshishkov> what about Belgium? [12:30:24] <mru> not so bad either [12:30:48] <mru> nothing like LHR or FRA [12:30:53] <kshishkov> nobody is interested in capital of Europe? [12:31:09] * kshishkov still likes ARN most [12:31:17] <mru> AMS is nice [12:31:48] <mru> ARN is nice when departing, not arriving [12:31:57] <mru> it's much bigger than it needs to be [12:32:09] <mru> so security is quick [12:32:18] <mru> but it takes them forever to get the luggage in from the plane [12:32:40] <kshishkov> compared to FRA? [12:33:10] <mru> I don't think I've ever had checked luggage there [12:33:16] <mru> TXL is quick [12:33:45] * thresh is having fun reading booking.com traveller comments on st nicholas hotel [12:33:48] <colde> CPH is nice both when departing and arriving :) [12:34:19] <kshishkov> colde: Kastrup? I doubt it [12:34:30] <colde> Yeah, it is :) [12:34:34] <kshishkov> it's FRA wannabe [12:35:02] <kshishkov> and it's also the only place where they've managed to lost my luggage during transfer [12:35:09] <mru> FRA has the worst signage ever [12:35:44] <colde> well, i understand why you might not like them, although i doubt they lose more luggage than any other airport :) [12:35:48] <kshishkov> FRA also has baggage handling in different place than gates [12:36:07] <kshishkov> mru: I've heard that Italian airports compete with it [12:38:21] <superdump> NYO is pretty quick but they need more space for passport checking [12:38:26] <superdump> and staff [12:38:46] <kshishkov> and security! [12:39:03] <superdump> their security seems to be pretty quick in my experience [12:39:06] * thresh shudders [12:39:18] <superdump> but then i guess i go at times when not so many other people are going [12:39:22] <lyakh> mru: pong [12:39:34] <mru> lyakh: about your sh4 optims [12:40:01] <mru> have you considered writing at least the functions called through pointers in plain asm .S files? [12:40:05] <kshishkov> thresh: Ð° Ð²Ñ Ð»ÐµÑÐ°Ð¹ÑÐµ ÑÐ°ÐŒÐŸÐ»ÐµÑÐ°ÐŒÐž ÐÑÑÐŸÑÐ»ÐŸÑÐ° [12:40:33] <lyakh> mru: yeah... but only very lightly;) [12:40:46] <mru> consider it again, and more profoundly [12:40:56] <mru> it's much easier to work with than inline [12:40:57] <lyakh> I looked at sh ABI, the function calling convention is not very... transparent [12:41:04] <lyakh> at least from the first sight [12:41:06] <mru> can't be that bad [12:41:09] <thresh> kshishkov: :S [12:41:13] <lyakh> no, not _that_ bad [12:41:19] <mru> first few params in registers, rest on stack [12:41:35] <lyakh> but bad enough for me to leave it for the first instance;) [12:41:40] <merbzt> lyakh: why do you work on sh4 ? [12:42:15] <lyakh> merbzt: well, let's put it this way: it's not just-for-fun [12:42:17] <lyakh> ;) [12:42:48] <kshishkov> lyakh: if GCC can generate it why can't you? [12:42:50] <lyakh> mru: but what are reasons to prefer .S to inline? [12:43:06] <mru> avoid the clutter of inline asm [12:43:09] <mru> and avoid gcc [12:43:15] <mru> also works with non-gcc compilers [12:43:16] <lyakh> kshishkov: sure I can... just didn't see the point to begin with [12:43:30] <lyakh> mru: last argument I consider void [12:43:32] <mru> better register allocation [12:43:35] <lyakh> for sh [12:44:33] <lyakh> dunno, so far all optimizations were _inside_ functions [12:44:47] <mru> where else would they be? [12:45:09] <mru> all the functions with pointers in e.g. dsputil are easy to write in pure asm [12:45:12] <lyakh> so, I thought, that overhead that gcc might add at the top and bottom of inline fragments shouldn't be bad enough [12:47:33] <mru> you'd be surprised [12:48:28] <lyakh> mru: do you have a specific example, where you think, that converting a certain function X to pure asm would bring a measurable advantage? [12:48:45] <mru> I didn't read the patches carefully [12:49:04] <mru> inline asm is bloody hard to read too [12:53:30] <siretart> lu_zero: no reason to hide this in private. when will you arrive? [12:54:36] <lu_zero> 17:25 [12:54:37] <siretart> my plane arrives on saturday at 10:35 at Brussels National Airport. I'll then take the cab to fosdem [12:55:02] <lu_zero> I see [12:55:07] <siretart> ok. where do I find you all on fosdem then? [12:55:18] <siretart> I think i have diego's mobile number [12:55:30] <lu_zero> siretart: I'll be there on Friday [12:55:34] <kshishkov> siretart: BeagleBoard booth, I presume [12:55:41] <siretart> kshishkov: excellent. I'll find that [12:55:42] <lu_zero> so I think we'll meet there [12:56:11] <mru> my phone number can be found using standard internet services [12:56:12] <kshishkov> siretart: and I'll arrive there only an hour earlier than you [12:56:22] <mru> those who are unable to figure it out are not worthy of calling me [12:56:26] <siretart> kshishkov: but via train, I persume? [12:56:31] <lu_zero> siretart: you should have already one of mine [12:56:38] <kshishkov> siretart: of course [12:57:27] <kshishkov> mru: once you spilled your inofficial Swedish number as well here [12:57:27] <mru> lu_zero: I have two numbers for you, one ending in 6295, one in 2494 [12:57:43] <mru> that one is harder to find [12:57:47] <mru> it's not listed anywhere [12:57:52] <siretart> mru: is the one ending on ..032 up-to-date? [12:58:06] <mru> +447900001032 [12:58:25] <siretart> that' [12:58:29] <siretart> s what I've found :-) [12:58:54] <cartman> everybody call mru now :p [12:59:13] <mru> cartman: it's your phone bill [12:59:33] <kshishkov> mru: who knows how Turkish Telecom works, it may bill you instead [12:59:37] * cartman has 7$ on Skype [12:59:42] <cartman> kshishkov: LOL [12:59:50] <cartman> that could happen [13:09:18] <siretart> our download page contains obsolete pieces of information about svn snapshots. ok to remove? http://pbot.rmdir.de/86f1ce5124c19a4ebdf592343d1bad4a [13:09:51] <mru> fine with me [13:10:16] <mru> btw, http://svn.ffmpeg.org/ redirects to git.ff.o [13:11:14] <superdump> siretart: send a patch to the ML :) [13:11:26] <siretart> superdump: seriously? [13:12:04] <mru> it's just removing old cruft from a web page [13:12:05] <mru> commit it already [13:12:09] <superdump> well, i don't care personally, but we said that stuff should be reviewed [13:12:16] <siretart> aaaaand, it is gone [13:12:18] <mru> code, yes [13:12:43] <siretart> superdump: it just had been reviewed and ack'ed by mans :-) [13:12:58] <mru> removing obviously wrong statements from the web page is hardly anything to debate [13:13:51] <kshishkov> too bad sometimes it's differently obvious to different people [13:14:02] <superdump> website svn commits only go to -cvslog and not -commits [13:15:49] <kshishkov> that makes sense too [13:16:20] <andoma> re the float_to_int16 discussion the other day.. i think the codecs should just output samples in their native format [13:16:39] <kshishkov> which is? [13:17:09] <mru> andoma: float output does not preclude scaling it [13:17:27] <kshishkov> I'd use -1.0..1.0 range [13:17:43] <andoma> mru: yeah, scaling of float (where it is "for free") can be offered by the codec [13:18:03] <andoma> s/can/should/ [13:18:20] <kshishkov> my codec can scale by 0 for free! [13:19:10] <merbzt> my by 1 [13:19:44] <cartman> we get the idea :P [13:20:14] <kshishkov> and proper one should output numbers in range [2.718281...; 3.141592...] [14:45:00] <ruggles> andoma: that is the goal, but currently the generic conversion doesn't use the fast functions. once it does the codecs can output what fits best. and even better if we get good planar audio support. [14:49:23] <BBB> mru wanted planar audio also [14:49:33] <BBB> I'm all for it, most decoders output planar audio internally anyway [14:49:42] <mru> yes, planar output is fine [14:49:55] <mru> something, somewhere still has to interleave it of course [14:50:08] <mru> but there's no inherent advantage of doing it early [14:51:56] <BBB> some avaudiofilters (avseq, anyone?) could also work better on planar audio maybe [14:52:42] <kshishkov> whatever - we'll just need final audioconvert filter [14:53:37] <mru> filters in general are easier to do planar [14:54:01] <kshishkov> especially with SIMD [14:58:01] <cartman> KotH: http://www.kamikazecookery.com/blogs/210 [14:58:56] <kshishkov> cartman: smells like pferdmist [14:59:16] <cartman> kshishkov: pferwhat? [14:59:27] <kshishkov> cartman: horse manure [14:59:40] <saste> astrange: your repo is missing libswscale [14:59:46] <cartman> kshishkov: ... [15:00:03] <kshishkov> cartman: that's how they call it in Northern Sauteuerland [15:00:16] <KotH> cartman: 10 out of 9 people are complete utter idiots... does that mean i have to boycot the world? [15:00:48] <cartman> KotH: I do so [15:00:49] <cartman> :D [15:01:08] * KotH boycots cartman [15:01:30] <cartman> :( [15:02:15] <kshishkov> cartman: number of idiots in Sauteuerland is lower only because it has less people than Turkey [15:04:28] * cartman hopes to be part of the 1 out of 10 [15:05:55] <spaam> cartman: he said 10/9 ... not 9/10... [15:06:16] <kshishkov> spaam: he hopes to be that -1 out of 9 [15:06:17] <cartman> spaam: tricky bastard KotH [15:06:27] <spaam> cartman: i know. [15:07:05] <spaam> kshishkov: ah :) [15:54:43] <lu_zero> we do have audio mixing algos in ffmpeg already, isn't it? [15:54:58] * mru looks around, sees none [15:55:01] <superdump> i don't think so [15:55:55] <Tjoppen> nope. not even audioconvert.h is public [15:56:05] <kshishkov> mixing as in what? [15:56:17] <spaam> mixtapes [15:57:14] <av500> lu_zero: out = (L + R) / 2 [15:57:16] <av500> done [15:57:57] <kshishkov> some decoders have builtin downmixing and upmixing [15:58:00] <cartman> av500: 2.0 [15:58:02] <cartman> :P [15:58:12] <av500> kshishkov: yes, dca and ac3 [15:58:19] <av500> and wmapro [15:58:31] <av500> at least the ones I have :) [15:58:46] <kshishkov> upmixing 1->2 is also present in some decoders [16:06:34] <lu_zero> uhmm [16:06:48] <lu_zero> av500: L + R - L*R you mean =P [16:22:52] <kshishkov> mru: just in improbable case you've overlooked it - http://www.cc65.org/ [16:28:19] <mmu_man> 6502 \o/ [16:28:25] <mmu_man> You want to port ffmpeg to ORIC ? [16:29:47] <av500> mmu_man: not all the world knows your french computer [16:29:58] <av500> only you and ex .yu :) [16:34:30] <mmu_man> av500: ORIC was british [16:34:41] <mmu_man> only when the british screwed up was it bought by french :p [16:35:07] <av500> ah [16:35:23] <benoit-> mmu_man: isn't that also true for some colonies? :) [16:35:33] <Tjoppen> ooh, I'll have to look at cc65 [16:36:28] <Tjoppen> assuming it plays well with dasm it should be useful with my atari 2600 experiments [16:47:44] <mmu_man> Tjoppen: hmm I recall writing a sed script to convert the output of one 6502 disassembler to the one used by cc65 [16:48:07] <mmu_man> I probably put it on miniserve... [16:48:08] <mmu_man> cf. http://forum.defence-force.org/viewtopic.php?t=635 [16:48:08] <Tjoppen> I'd rather do the opposite [16:48:55] <mmu_man> http://miniserve.defence-force.org/svn/users/mmu_man/sedoric/ca2xa.sed [16:49:14] <mmu_man> might still be helpful I hope :) [16:50:00] <Tjoppen> cool [16:50:37] <Tjoppen> I wonder if it makes use of the undocumented opcodes. I've found some to be particularly useful, like SAR [16:51:41] <mmu_man> I used it to disassemble and reassemble SEDORIC automatically [16:51:50] <mmu_man> the idea was to add Jasmin2 support... [16:51:53] <mmu_man> never had time [16:52:06] <mmu_man> cf the makefile http://miniserve.defence-force.org/svn/users/mmu_man/sedoric/ [16:54:02] <lu_zero> firefox has a really strange build system [16:54:53] <mru> tell us something new [16:55:13] <av500> at least it has one [16:56:30] <lu_zero> mru: it seems to be broken right now [16:56:42] * lu_zero workarounds it... [16:57:04] <mru> "works around" [16:59:36] <lu_zero> note taken [17:02:45] <mru> not "takenoted" :) [17:03:03] <mmu_man> mans' tree :=D [17:03:04] <av500> notetaked! [17:03:22] <mmu_man> or shortened "naked" :) [17:04:36] <lu_zero> isn't for not acknowledged? [17:05:18] <av500> NACK'ed [17:06:03] <lu_zero> jrmuizel: you! [17:06:08] <mru> I thought it was "nekkid" [17:06:25] <lu_zero> I'm having some really strange issue building firefox [17:06:56] <lu_zero> apparently it fails because LIBXUL_LIBS doesn't have -lcairo [17:07:04] <lu_zero> rings any bell? [17:07:30] <mru> warning bells, loud ones [17:09:02] <j-b> s/dont/done [17:09:19] <mru> yeah, that one didn't quite parse the first time [17:17:20] <Compn> kshishkov : you seen 'rare exports' yet? horror movie about santa clause [17:17:28] <Compn> finnish i think [17:20:11] <peloverde> It looked awesome but I have not seen it yet [17:26:36] <mru> jannau: patchwork seems to hate mime-encoded subject lines [17:27:24] <av500> can somebody have a look at that flv index patch? [17:30:12] <jannau> mru: looks so [17:30:42] <elenril> jannau: please fix the commit message for the mov patch [17:30:46] <elenril> it's not a regression [17:31:44] <elenril> those -- 8< -- lines is some patchwork magic? [17:31:52] <mru> git magic [17:32:15] <jannau> elenril: John said it worked before your patch [17:33:57] <jrmuizel> lu_zero: ? [17:34:01] <jannau> err, misrembered. will fix the commit message [17:38:11] <lu_zero> jrmuizel: I'm trying to build firefox from a snapshot a little after beta9 and I got this strange behaviour [17:38:37] <lu_zero> the workaround I'm using is adding -lcairo to the flags [17:39:14] <jrmuizel> lu_zero: weird [17:39:22] <jrmuizel> file a bug? [17:39:37] <lu_zero> jrmuizel: I wanted to confirm it first [17:39:42] <jrmuizel> sure [17:39:50] * jrmuizel heads to lunch [17:41:38] * lu_zero is thinking about heading to bed... [17:47:57] <mru> BBB: what are the constraints on the 'h' argument to vp8 epel MC? [18:07:50] <TheFluff> does av_realloc() guarantee aligned memory? [18:08:07] <mru> what are you doing? [18:08:39] <TheFluff> using it in an application that links against ffmpeg [18:08:39] <mru> but the answer is no [18:08:50] <TheFluff> ok [18:09:22] <TheFluff> I'm reading frames from a file to a buffer, enlarging it when needed [18:09:32] <TheFluff> and then feeding that buffer to lavc [18:09:44] <TheFluff> so I guess I shouldn't do that and use av_malloc instead [18:09:50] <mru> why don't you allocate enough to begin with? [18:10:00] <mru> realloc is slow [18:10:01] <TheFluff> because I don't know the maximum frame size [18:10:26] <TheFluff> I guess I could scan the file first but that's probably even slower [18:10:46] <mru> start with a sensible guess, then every time you find a larger frame, allocate a bigger buffer and keep that size [18:10:59] <mru> you might add an exponential factor too [18:11:09] <TheFluff> that's what I'm doing, except I start at 0 instead of a sensible guess [18:11:17] <mru> if you do that, you shouldn't need to enlarge it more than a few times [18:11:40] <TheFluff> lazy coding uses realloc the first time too so I don't have to handle the unallocated case in a special way [18:11:48] <TheFluff> but I guess I should Do It Right [18:11:56] * mru bets TheFluff doesn't handle realloc failure properly [18:12:24] <TheFluff> I do, I raise an error saying "out of memory" [18:12:27] <TheFluff> ;V [18:12:38] <TheFluff> (hasn't been triggered yet to my knowledge) [18:12:41] <mru> and leak the old buffer [18:12:50] <TheFluff> no, and abort [18:14:53] <mmu_man> re [18:16:51] <ruggles> TheFluff: regarding starting at 0, many movies start with black & silence which could have small frame sizes for VBR, so it could still be way too low even after the first realloc. [18:17:36] <TheFluff> yes, the current implementation is highly inefficient [18:17:46] <TheFluff> I'm very aware of this [18:18:26] <av500> what is the issue to alloc 256k or so for the frame? [18:19:25] <TheFluff> none, I just inherited lazy coding that does it in the laziest way possible, which is if (framesize > bufsize) enlarge_buffer(framesize + some constant) where enlarge_buffer calls realloc [18:19:53] <TheFluff> init the bufsize to 0 and you don't have to do anything special at all [18:20:00] <TheFluff> no special cases etc [18:21:06] <av500> + constant -> *= 2 [18:21:49] <TheFluff> yeah but that still leaves me with unaligned memory so I really should take the time and write the five lines of code required to do it right [18:34:42] <Compn> peloverde : i just finished watching it. very strange movie. [18:44:40] <BBB> mru: h is either 4, 8 or 16, and it is the same as the width, or half or double of that (i.e. for width=8, you can have 8x4, 8x8 or 8x16) [18:45:01] <BBB> mru: also, if width == 16, then x and y (last two arugments) are always even [18:45:11] <BBB> mru: so you don't need to implement fourtap for width == 16 [18:48:21] <mru> and for width 4, h >= 4? [18:50:36] <BBB> h is either 4 or 8 [18:50:42] <BBB> for width == 16, h is 8 or 16 [18:50:50] <BBB> for width == 8, h is 4, 8 or 16 [19:33:47] <j-b> I am so sad I must be missing all the fun [19:35:26] <Jumpyshoes> fun? [19:35:54] <mru> Jumpyshoes: sarcasm detector broken? [19:36:15] <j-b> Jumpyshoes: sorry, missing the <irony> tags [19:37:08] <Jumpyshoes> lol, i'm bad at sarcasm [19:37:21] <mru> learn, quickly [19:38:32] <j-b> Jumpyshoes: it will be a useful tool for your career, srsly [19:38:54] <j-b> Jumpyshoes: just try to avoid the being-too-cynical-to-appreciate-life trap [19:39:47] <Jumpyshoes> i should learn [19:44:30] <thresh> it's not a trap really [19:44:37] <thresh> but the only possible way of survivng [19:46:17] <j-b> no, life is Awesome! [19:46:45] <j-b> you need to be a bit cynical and use irony&sarcasm, but you need to be positive about life [19:49:20] * thresh puts off his Marvin hat [19:55:21] <j-b> thresh: I must re-read those books [20:00:49] <_av500_> j-b: but in the original russian! [20:01:09] <thresh> j-b: I like the movie too [20:01:41] <j-b> av500: ? ?? ?????? ??-?????? [20:04:39] <thresh> yeah that's what I say in the mornings [20:05:52] <thresh> when i'm like that: http://www.youtube.com/watch?v=umxQfF4dobw [20:23:16] <mru> http://blog.regehr.org/archives/364 [20:31:32] <j-b> rofl [20:31:45] <j-b> yet another angry mail from top HP executive to me [20:32:02] <j-b> for "VLC is destroying speakers of our laptops" [20:32:26] <_av500_> lol [20:32:33] * elenril always knew vlc is evil [20:32:54] <roxfan> wow, how do you do that? [20:33:19] <j-b> roxfan: well, the UI allows you to go above 100% of the audio input [20:33:32] <roxfan> nice [20:33:33] <j-b> roxfan: so the sound will saturate (obviously) [20:34:01] <j-b> roxfan: but, saturating sound is still outputted through Win32 drivers to their hardware [20:34:21] <j-b> I am trying to tell them that we aren't modifying the output [20:34:40] <mru> does it cause physical damage? [20:34:47] <j-b> destroys the speaker [20:34:50] <j-b> according to them [20:34:51] <mru> if so, the laptops are rather poorly designed [20:34:59] <j-b> my opinion too [20:35:04] <j-b> we are using Win32 APIs [20:35:08] <j-b> not hooking the drivers [20:35:13] <mru> laptop speakers are like 0.5W [20:35:46] <mru> it's not like driving a few kW too much from a power amp into a too small speaker [20:35:48] <j-b> so, I've received the 20th mail on the thread, and they are getting angry [20:35:59] <j-b> and angrier [20:36:16] <iive> tell them it is driver problem. [20:36:22] <thresh> lol [20:36:34] <j-b> I mean, it is like if I was listening to some German Metal group [20:36:37] <thresh> j-b: what do they want from you? [20:36:39] <j-b> the sound saturared [20:36:44] <j-b> thresh: fix our code [20:37:00] <j-b> so they "can actively promote VLC" [20:37:04] <j-b> I lol'd on that one [20:37:23] <j-b> iive: well, to me too, it seems obvious [20:37:26] <elenril> haha [20:37:38] <elenril> wait until they threate to actively promote mplayer instead [20:37:41] <thresh> j-b: well tell them you did fix the code [20:37:47] <_av500_> j-b: make em pay [20:37:48] <thresh> and watch them burn another laptops [20:37:50] <thresh> :) [20:38:01] <wbs> j-b: ask what they'll do if you don't fix it, add a "please don't use VLC on this computer, it might break" sticker on all computers? :-) [20:38:09] <j-b> elenril: well, VLC, mplayer, this is the same [20:38:21] <wbs> that'd sell well [20:38:30] <j-b> wbs: lol [20:38:41] <j-b> but, I am a bit afraid that I am missing something [20:39:35] <j-b> but what? [20:40:15] <ruggles> this is float output? [20:41:02] <j-b> f32l or s16l [20:41:28] <ruggles> how can s16l go over 100%? [20:41:41] <mru> how can anyone be stupid enough to build a system capable of self-destructing? [20:41:41] <_av500_> s17l [20:41:49] <roxfan> 2.0 = 200% ? [20:41:52] <mru> just put a goddamn power limiter in the output stage [20:41:52] <j-b> ruggles: well, it doesn't, obviously [20:42:16] <j-b> ruggles: can it? [20:42:28] <mru> of course not [20:42:33] <mru> s16 uses the full range [20:43:31] <j-b> so, s16l is out of problem I guess [20:43:34] <j-b> so is spdig [20:43:44] <j-b> *spdif* [20:44:02] <mru> I doubt the hw accepts anything other than s16 [20:44:23] <j-b> mru: so, am I crazy? [20:44:29] <_av500_> no [20:44:44] <_av500_> their amp stage is crap [20:44:55] <_av500_> they must limit the sound [20:44:55] <j-b> seeing the code, we try fl32 before s16l [20:45:02] <mru> j-b: do you know which part is breaking? [20:45:07] <_av500_> even we do that [20:45:09] <mru> output stage or speakers? [20:45:15] <_av500_> speakers [20:45:18] <_av500_> i guess [20:45:21] <j-b> mru: they claim "speakers destroyed" [20:45:33] <mru> coming from an executive that could mean anything [20:45:42] <_av500_> no bandpass on the speaker stage [20:45:46] <mru> it's his way of saying "no sound" in a more techy-sounding way [20:45:49] <_av500_> even we do that [20:46:04] <j-b> "Open Source Program Office", (ITO CT & [20:46:49] <j-b> "Open Source Program Office", "ITO CT & CA and Open Source Lead", "Open Source and Linux Technology Architect", "central CTI" [20:46:58] <j-b> I mean, those guys are not kidding :) [20:47:27] <j-b> serious business [20:48:14] <_av500_> j-b: always ask for a sample product [20:48:16] <j-b> and of course, I know next to nothing in audio [20:48:26] <j-b> av500: free laptop! [20:48:32] <_av500_> yup [20:48:44] <j-b> I would prefer a new server [20:48:49] <j-b> so I can host a ffmpeg-fork [20:48:54] <j-b> </sarcasm> [20:49:03] <mru> j-b: ask him to test vlc on a server [20:49:05] <mru> hope it breaks [20:49:17] <j-b> well, www.v.o is a HP server [20:52:21] <j-b> still, to me the fault is theirs [20:54:22] <{V}> why is an executive even contacting you about it. Sounds like something one of their more technically inclined people should address (and probably not by contacting you) [20:57:32] <ruggles> which systems don't HAVE_6REGS? [20:58:10] <mru> x86_32 with pic and -fno-omit-frame-pointer or something [20:59:49] <ruggles> ok. vector_fmul_window sse & 3dn2 require 6regs, but with memcpy+5regs it's still faster than C on my system. [21:07:21] <lu_zero> nice =) [21:08:03] <mru> how can you replace a mul with memcpy? [21:20:01] <Compn> j-b : ohhh, wheres the thread about bad laptop speakers? :D [21:20:05] <Compn> or is it private mail hehe [21:20:07] <kierank> Yuvi: do bugs in qt aac encoder get fixed if we report then [21:20:08] <kierank> them* [21:20:28] <BBB> Yuvi is online? [21:20:29] <BBB> ooo [21:20:31] <BBB> hi yuvi [21:21:07] <ruggles> mru: just memcpy src0 to dst then load/save to dst [21:21:22] <mru> how can that be faster? [21:21:31] <ruggles> faster than the C version [21:22:08] <ruggles> sse2 6regs: 6671 - sse2 5regs: 8761 - C: 12721 [21:22:21] <mru> ah, now you're making sense [21:22:32] <mru> but who cares about not having 6 regs free? [21:22:43] <mru> besides, it can just be written in yasm instead [21:22:45] <mru> problem solved [21:23:40] <ruggles> true [21:23:41] <BBB> x86-32 always has 6 regs [21:23:42] <j-b> Compn: private mail [21:23:48] <BBB> just put it under #ifdef HAVE_7_REGS or so [21:23:53] <BBB> we don't care about broken systems [21:24:32] <ruggles> it's currently under HAVE_6REGS [21:24:56] <ruggles> and falls back to C otherwise [21:25:13] <ruggles> i was just wondering if it's worth it to optimize the 5 register case [21:25:22] <mru> it's not [21:25:39] <mru> that only happens in some bizarre combination of bad choices [21:25:58] <ruggles> good enough for me [21:30:24] <j-b> Compn: i can fwd you the mails [21:30:35] * BBB agrees with mru [21:32:22] <Compn> j-b : sure, patriotact(a)gmail.com [21:32:39] <j-b> what? [21:32:44] <Compn> my email [21:34:03] <Compn> to forward the mails to... [21:34:40] <spaam> eh what? dont you have a rr.com mail? [21:35:11] <kierank> ah yes compn's epic email [21:35:19] <Compn> i do, mostly used for the mailing list [21:35:20] <lu_zero> which one? [21:35:34] <Compn> but i use the gmail when i post it in public because it has better spam protection [21:35:48] <Compn> kierank : glad someone likes it :) [21:36:02] <spaam> Compn: since when is ffmpeg-devel not public? [21:36:06] <Compn> its a constant reminder that at any time, my government can read what books i take out of the library [21:36:26] <Compn> spaam : well that and i signed up for the list before i got gmail [21:36:59] <spaam> ok :) [21:37:36] <Compn> projects(a)mplayerhq.hu forwards to my gmail too [21:38:19] <Compn> i was getting ffmpeg project emails about every month until you guys hid the projects page on the about navigation [21:39:03] <Compn> er nm, i cant remember if that mail was ever up there [21:39:13] <spaam> :) [21:49:50] <BBB> wbs: ping [21:49:58] <wbs> BBB: pong [21:50:01] <BBB> \o/ [21:50:06] <BBB> wbs: do you feel like cleaning up https://github.com/rbultje/ffmpeg/commit/4900f0ec82720229c7293c242114555d38… ? [21:50:35] <BBB> there's quite some work left to do, it's a asf rtp payload parser when streamed by realmedia servers (I know, don't ask) [21:50:50] <BBB> it crashes on exit, there's a few hacks that may be preventable, etc. [21:51:03] <BBB> sample stream is provided in the commit message [21:51:47] <wbs> BBB: sure, I can give it a look in a while [21:52:20] <BBB> awesome [21:52:33] <BBB> I'm gonna clean up some other patches to push into that tree [21:59:40] <mru> ruggles: do you want a login on my ppc? [22:00:16] <ruggles> sure [22:00:30] <mru> send an ssh pubkey [22:00:38] <mru> and pick a username [22:02:53] <ruggles> sent [22:04:10] <mru> ruggles: ssh saracen.mansr.com should work [22:04:20] <mru> usual dev tools are available [22:04:26] <mru> samples in /misc/samples/ [22:04:35] <mru> mphq and some other random stuff [22:04:57] <mru> machine is dual g4 800-ish MHz [22:05:03] <ruggles> awesome. thanks. [22:07:03] <ruggles> how do i send my patch? [22:07:18] <mru> send it where? [22:07:36] <ruggles> to the ppc. so i can test it. [22:07:38] <mru> you have git, push and pull to your heart's content [22:13:05] <ruggles> i can setup a git clone on the ppc, but how do i make it accept push from local? [22:13:16] <mru> from local? [22:14:02] <mru> on your pc, do "git push saracen.mansr.com:path/to/clone master" [22:14:05] <mru> or something like that [22:14:28] <mru> wait, it'll bitch about pushing into a checked-out branch [22:14:43] <lu_zero> BBB: http://ffmpeg.pastebin.com/SRRxSQSx [22:14:48] <lu_zero> I hate it [22:14:53] <lu_zero> got better ideas? [22:15:54] <wbs> lu_zero: uh, can't we allocate it once we know rt->nb_rtsp_streams at startup? [22:16:02] <lu_zero> wbs: even more ugly [22:16:31] <BBB> exactly [22:16:38] <BBB> it's ok to do that, but not in fetch_packet [22:16:43] <BBB> malloc during init is fine [22:17:00] * j0sh would like a way to add/remove streams at runtime [22:17:34] <ruggles> mru: what if i just init an empty repo on the ppc, then push? [22:17:44] * elenril would like a pony [22:17:51] <mru> ruggles: it'll still be checked out [22:18:03] <mru> you can push to a temp branch and merge that into master [22:18:32] <ruggles> ok. i'll give it a shot. [22:28:41] <Yuvi> kierank: well, unreported bugs probably won't get fixed [22:28:41] <Yuvi> beyond that, "probably" [22:28:41] <Yuvi> BBB: hey [22:28:52] <ruggles> mru: worked fine. i checked out a temp branch then pushed to master. [22:29:04] <kierank> Yuvi: yes we reported it [22:29:05] <kierank> thanks [22:29:21] <mru> Yuvi: you mean they'll be snuck into a later update under "improve bulgarian translation" [22:29:44] <Yuvi> mru: usually it's "bug fixes" as the entire changelog ;) [22:30:07] <mru> bios updates are really bad like that [22:30:19] <mru> the official release notes always seem totally innocent [22:30:28] <mru> yet they mysteriously fix things [22:30:33] <bcoudurier> merbanan, are you around ? [22:30:39] <merbanan> yes [22:32:06] <lu_zero> j0sh: that isn't a problem where you add the change logic you can add the av_realloc ^^; [22:33:25] <lu_zero> http://ffmpeg.pastebin.com/tdvNNdPE <- better? [22:36:12] <wbs> lu_zero: yes, looks better to me. won't you need to allocate it somewhere else for the rtsp demuxer, though? that only allocates it for the sdp demuxer [22:36:59] <lu_zero> wbs: rtsp->sdp->rtp [22:37:40] <wbs> lu_zero: did you test it yet? ;P sdp_read_header isn't called anywhere in the rtsp demuxer [22:37:49] <lu_zero> uh? [22:37:51] <lu_zero> meh [22:39:51] <lu_zero> ff_sdp_parse fooled me =P [22:41:22] <lu_zero> ff_rtsp_setup_input_streams ... [22:41:46] <lu_zero> remind me why we have it in another file while it is called in the other one... [22:42:36] <wbs> since it's only used in the rtsp demuxer (while it's called by common rtsp code in rtsp.c), it was moved there as part of trying to split it up a bit more in october [22:43:44] <lu_zero> right [23:08:04] <mru> BBB: so which vp8 epel variants are not used? [23:08:34] <mru> I don't see width4 h4 or v4 in my profiles [23:11:24] <Yuvi> those are for if either the x or y component has no subpel at all iirc [23:11:44] <Yuvi> but the other is epel [23:12:53] <mru> the function pointer tables have entries for h6, v6, h4, v4, h6v6, h6v4, h4v6, h4v4 for widths 4, 8, and 16 [23:13:07] <mru> but some of them don't appear to be used (much) [23:13:47] <mru> BBB said width 16 4-tap isn't used [23:13:51] <Yuvi> yeah [23:13:55] <Yuvi> 4 tap is chroma-only [23:14:28] <Yuvi> and I'd imagine most chroma mvs have subpel for both components [23:14:45] <Yuvi> or none at all [23:15:11] <mru> what are the mixed 4/6-tap ones for? [23:15:43] <Yuvi> qpel position for (x,y), epel for the other [23:15:50] <Yuvi> x or y I mean [23:30:56] <jannau> is the git-svn ffmpeg repo still somewhere? [23:31:39] <mru> it's still there [23:31:44] <mru> but out of public view [23:32:18] <j-b> hello jannau [23:37:41] <Dark_Shikari> oh awesome, more ffflames [23:39:54] <jannau> hi j-b, I still haven't tested the crystalhd decoder in vlc [23:40:52] <j-b> still, point 8) is quite right [23:41:30] <Sean_McG> I hear those are awesome [23:42:15] <j-b> crystald? [23:42:31] <Sean_McG> aye [23:42:37] <jannau> that sounds like a wild exaggeration. I would say they work to some extent [23:43:14] <Sean_McG> well as in they let a dinky Atom play a 1080p stream [23:43:32] <j-b> Sean_McG: they are not too bad [23:43:34] <jannau> and the driver has much room for improvement [23:43:41] <j-b> Sean_McG: and the API is broken, but not too much [23:43:49] <j-b> but the drivers is not up to standards yet [23:46:52] <jannau> mru: and the non-public way to access it? [23:47:07] <mru> same git url as before [23:47:16] <mru> why? [23:49:18] <jannau> indeed, I assumed ffmpeg and ffmpeg.git are the same repos [23:49:30] <mru> sorry for the confusion [23:49:33] <lu_zero> got fooled as well ^^ [23:49:43] <Sean_McG> ditto [23:49:54] <mru> we'll make them the same eventually [23:50:15] <mru> but I didn't want to break things for anyone overnight [23:50:36] <Sean_McG> I thought that's what mainline development was all about? [23:50:40] * Sean_McG ducks and runs! [23:54:22] <Sean_McG> anyone know where I should ask about metadata tagging for a show like oldskool Doctor Who, where you had separate "stories" within a season? [23:55:43] <mru> ask elenril, he's our master of all things meta [23:56:33] <mru> not too familiar with old dr who, are those a plot line spanning several episodes? [23:56:47] <mru> but several such multi-episode stories per season [23:56:50] <Sean_McG> aye [23:57:27] <mru> I guess I'd just tag them "title: part X" or something [23:57:41] <mru> of if sw can handle it, part as a separate tag [23:58:04] <Sean_McG> I suppose I could do that... I tried with episode ID but iTunes still doesn't sort them properly

1 0

IRC log for 2011-01-26
by irc＠mansr.com 27 Jan '11

27 Jan '11

[00:05:54] <CIA-43> ffmpeg: Georgi Chorbadzhiyski <gf(a)unixsol.org> master * r535638b55f ffmpeg/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): [00:05:54] <CIA-43> ffmpeg: mpegtsenc: set reserved bits to 1 in PCR field [00:05:54] <CIA-43> ffmpeg: The reserved bits between PCR base and extension fields must be [00:05:54] <CIA-43> ffmpeg: set to 1. [00:05:54] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:39:50] <BBB> mru: can you send me a backtrace? [00:39:58] <BBB> mru: I don't have oenbsd@sparc so it's hard to debug [00:39:58] <BBB> :-p [00:40:08] <mru> me neither [00:40:15] <BBB> whose box is it? [00:40:27] <BBB> you need a maintainer contact info entry there [00:40:28] <mru> kostylev I think [00:41:29] <BBB> ok I'll email him [00:44:01] <BBB> astrange: anything else I can do to help you debug it? :-p otherwise I'll continue looking either at other samples that fail, or I'll look at this one if you're not looking into it [00:47:14] <astrange> i have to do some non-ffmpeg work tonight but i'll look at it half-paying attention [00:47:27] <astrange> you can see if other samples have different problems [00:50:24] <BBB> astrange: ok - I hope we can get this moving [00:51:41] <astrange> and then keep going after that if they do. or if they don't [00:55:27] <Anaerin> I'm getting an interesting output from the latest ffprobe for a stream: http://pastebin.com/Tir2JR7g [00:57:46] <BBB> it's rtp - don't you need a sdp or rtsp-with-a-sdp? [00:58:02] <Anaerin> Nope, not always. [01:00:03] <Anaerin> It's an IPTV stream from Microsoft's Mediaroom system. [01:00:45] <Anaerin> It should be h.264 Video, and several AAC audio streams, and possibly a closed caption stream as well. [01:02:04] <Anaerin> As it's multicast, it's difficult to get a sample, but I have a few grabbed with rtpdump (That can be played back over a network interface to simulate the live stream) if that would help. [01:02:53] <Anaerin> If this can be figured out and decoded, it'll help a lot with streaming U-Verse (among other IPTV systems) directly to computers without a set-top-box in the way. [01:12:52] <Anaerin> The pastebin (http://pastebin.com/h2HPjbKi) has been updated with the -loglevel debug output [01:14:48] <BBB> you probably want to put this on roundup [01:14:52] <BBB> I have no time to look today [01:14:54] <BBB> sorry [01:15:26] <Anaerin> No problem. [01:16:17] <BBB> astrange: I think all h264 bugs are this one [01:16:24] <BBB> astrange: have you looked at the vsynth fate problems? [01:16:29] <BBB> that's the only ones I see [01:17:10] <astrange> i wrote down that it had to do with draw_edges, but i forgot my reasoning [01:17:31] <astrange> i changed mpeg* decoding so it runs that in ff_draw_horiz_band, in mainline it does that in MPV_decode_end [01:22:25] <BBB> after we've got this fixed, I'd like to do at least one round of review, some of the code in h264.c looked wrong so I want to make sure I get it (review = you explain me what it does so I know what it does, not review = I tell you what's wrong, you change it and resubmit) [01:29:51] <BBB> I'm confused though, it seems the encoded file is different also [01:29:55] <BBB> did you change anything in the encoders? [02:08:07] <astrange> they share a lot of code and both call draw_edges() [02:08:45] <CIA-43> ffmpeg: Marco Gittler <marco(a)gitma.de> master * rb09f548285 ffmpeg/libavcodec/libx264.c: [02:08:45] <CIA-43> ffmpeg: Pass field order flag to libx264 [02:08:45] <CIA-43> ffmpeg: Signed-off-by: Jason Garrett-Glaser <jason(a)x264.com> [02:12:44] <BBB> astrange: ok, I'll look [02:45:53] <BBB> astrange: you only draw top/bottom, not left/right, edges, is that correct? why? [03:00:05] <BBB> astrange: also, if I encode a wmv2 file (for example, fate fails for that) using ffmpeg-old and compare output of mt and old, they're identical [03:00:13] <BBB> astrange: I think only encoding is broken, decoding seems fine [03:27:09] <BBB> astrange: encoding of interframes seems broken, specifically, at the edges :) my rough guess is that you not drawing edges at the correct places in the "last" buffer causes motion estimation to give different results around the edges [03:27:47] <BBB> astrange: decoding is fine afaics, I'll see if I can figure out the encoding paths, getting to know a whole new piece of codebase here that I was hoping not to have to look at... [04:25:14] <peloverde> BBB: consider it reviewed [05:20:20] <astrange> BBB: it certainly should end up with all of them drawn [05:21:02] <astrange> BBB: in decode it draws top/bottom if the top/bottom parts of the video were decoded, and left/right of the decoded parts [05:21:22] <astrange> and then draws everything at the end if the frame was damaged or draw_horiz_band was ever not called [05:21:25] <astrange> iirc [05:42:45] <peloverde> Is anyone planning on looking at anatoly's MxPEG patch? [07:52:18] <cartman> moin [07:53:12] <spaam> God morgon [07:53:39] <cartman> or moroning [07:58:20] <spaam> cartman: how is your $WIFE[2] today? :) [08:02:36] <cartman> spaam: non-existent :P [08:02:48] <superdump> morning [08:03:03] <cartman> moin superdump [08:03:31] <peloverde> greetings [08:08:49] <andoma> morning [08:14:38] <_av500_> gm [08:15:32] <Sean_McG> idkfa [08:17:35] <kshishkov> goda morgnar alla [08:19:38] <spaam> kshishkov: allt bra? [08:20:15] <kshishkov> spaam: javisst (utan Trocadero, jag har bara Trocadero bara i karamell) [08:32:01] <siretart> lu_zero: sorry, I hope you didn't book the room for me yet, I've now learned that I cannot possibly make it to fosdem this year :-( [08:40:13] <siretart> hm. I could take the night train. [08:42:24] <kshishkov> where are you going from? Frankonia? [08:42:30] <siretart> yes [08:43:39] <siretart> hm. there doesn't seem to be any suitable connection [08:44:03] <siretart> the problem is that I have a workshop here until ~5pm, where I must attend [08:44:04] <kshishkov> yes, any connection via Stuttgart is definitely unsuitable [08:45:27] <kshishkov> personally I'll go with train at 3:30 AM [08:45:47] <siretart> 3:30am on saturday morning? [08:45:53] <kshishkov> yes [08:46:11] <kshishkov> hope it makes you feel better [09:04:02] <pross-au> kshishkov: are you staying up late for that one, or getting up early?? [09:05:00] <spaam> pross-au: he wanted to be the first to see your patch for bink-b [09:06:24] <pross-au> tossing up whether to tackle that, or mess around with bayer8 [09:06:54] <ubitux> btw, about the ff_ unexport patches [09:07:06] <kshishkov> pross-au: it's 10AM here [09:07:10] <ubitux> maybe those should not get exported right now: http://pastie.org/1498657 [09:07:17] <ubitux> they seem to be in used in mplayer [09:07:38] <ubitux> (at least those, grabbed from a quick grep) [09:08:01] <kshishkov> that's MPlayer, it likes to reuse internals of any project it assimilates [09:10:21] <ubitux> :) [09:13:42] * kshishkov wonders if DonDiego can give a lecture on clean pluggable modular design of MPlayer [09:15:35] <DonDiego> what internals are you talking about? [09:16:15] <jannau> DonDiego: http://pastie.org/1498657 [09:31:27] <DonDiego> i think those symbols might actually come from the copied mjpeg encoder in mplayer [09:36:13] <Dark_Shikari> "clean pluggable modular design" [09:36:15] <Dark_Shikari> "mplayer" [09:37:01] <av500> </troll> [09:39:11] <kshishkov> Dark_Shikari: there are still people that think so [09:39:42] <kshishkov> Dark_Shikari: they alsoo see nothing wrong with mencoder.c [09:40:17] <ubitux> (mencoder.c is no more in mplayer2) [09:40:25] <ubitux> +present [09:40:30] <superdump> mplayer2? :o [09:40:37] <ubitux> (and no, it's not called mencoder2.c) [09:41:36] <ubitux> superdump: Uoti's MPlayer if you prefer, but it's actually called mplayer2 [09:41:37] <kshishkov> superdump: aka uau-mplayer [09:42:20] <merbzt> Dark_Shikari: awake ? [09:42:50] <superdump> out of curiosity, where does it live? [09:42:58] <superdump> (mplayer-uau) [09:43:24] <kshishkov> repo.or.cz, I think [09:44:30] <kshishkov> superdump: http://repo.or.cz/w/mplayer.git it seems [09:44:47] <ubitux> s/mplayer/mplayer-build/ [09:45:03] <Dark_Shikari> merbzt: yes [09:45:10] <ubitux> mplayer-build uses mplayer [09:57:01] <merbzt> Dark_Shikari: I have some hardware that decodes some fragments of the clip distorted [09:58:14] <merbzt> http://pastebin.com/48rQ4R6p [09:58:21] <merbzt> that is the encode log [09:58:26] <andoma> av500: package arrived on my desk [09:58:38] <andoma> IRC is faster than mail [09:59:23] <merbzt> Dark_Shikari: do you have any hint on what features that I can disable to pinpoint what causes decode corruption [09:59:39] <merbzt> I tried lowering the bitrate and set the refs to 3 [09:59:43] <kierank> merbzt: weightp [10:00:21] <spaam> those p frames.. [10:02:57] <cartman> lonely p frames [10:03:34] <av500> andoma: nice [10:12:00] <Dark_Shikari> merbzt: disable weightp [10:27:10] <Tjoppen> interesting.. I just figured out a major difference between avid's opatoms and the standard [10:27:45] <Tjoppen> they've worked around a retarded limitation in the standard, namely that of indexes not being allowed to be larger than 64k [10:28:12] <merbzt> no change :/ [10:28:15] <merbzt> http://pastebin.com/yd96kHie [10:28:21] <merbzt> any other suggestions ? [10:28:32] <merbzt> Dark_Shikari / kierank ? [10:31:04] <Dark_Shikari> what if bframes are off? [10:31:15] <saste> michaelni: hi michael :)! [10:31:24] <Dark_Shikari> he seems pretty quiet sadly [10:31:46] <merbzt> think he is meeting ramiro [10:32:50] <kshishkov> anybody knows why? [10:32:57] <saste> anyway nice to see him online [10:33:04] <kshishkov> I thought he's not into meeting people [10:33:20] <saste> I believe ramiro was preparing himself for carnival... [10:33:23] <kshishkov> saste: you're pathetic liar [10:33:41] <saste> kshishkov: ? [10:37:08] <lu_zero> good morning [10:37:20] <DonDiego> saste: ramiro is travelling around europe [10:37:39] <lu_zero> j-b: is there a way to make cvlc - close once the file is complete? [10:38:20] <j-b> lu_zero: you mean like cvlc pr0n.avi vlc://quit [10:38:42] <j-b> lu_zero: or you mean cvlc pr0n2.avi --play-and-exit ? [10:39:15] <av500> j-b: is there a way to get pr0n.avi? [10:39:31] <kshishkov> saste: "always nice to see him online" - I doubt you had much experience seeing him online. And since he doesn't talk it makes no difference. [10:39:43] <j-b> av500: http://streams.videolan.org/misc/untriaged/ probably :) [10:40:06] <av500> hmm, akiyo... [10:40:12] <lu_zero> j-b: nc6 --continous --exec='cvlc - stuff' [10:40:38] * kshishkov sees http://streams.videolan.org/misc/untriaged/lossless_touhou.snow-crash-vlc-1… and wonders who would produce such file [10:40:40] <merbzt> av500: search for it on the pirate bay [10:41:17] <av500> isnt that illegal? [10:42:28] <kshishkov> av500: stop whining and do it! [10:42:32] <iive> kshishkov: it may be possible for michael to talk while sleeping, but I doubt he can type :P [10:42:49] <saste> kshiskov: give him more time [10:43:38] <kshishkov> saste: of course, but so far you can also say "it's always nice to see fftrollbot online" [10:43:51] <j-b> Waouw, michaelni is on the chan? That _is_ cool. [10:44:59] <merbzt> well now the error in one place disappeared but another one appeared instead [10:47:19] <merbzt> http://pastebin.com/uqqpzDuG [10:47:46] <merbzt> Dark_Shikari / kierank: any more suggestions ? [10:48:14] <Dark_Shikari> try baseline profile? [10:57:30] <lu_zero> siretart: where do you live exactly? [10:58:11] <siretart> lu_zero: near nueremberg, that's the airport or trainstation I would use [10:59:18] <merbzt> http://pastebin.com/Jx7TZuZy [10:59:25] <merbzt> still distortions :/ [10:59:56] <lu_zero> so in the middle of Germany [11:01:10] <DonDiego> siretart: if you can get to frankfurt you can likely share commute with stefan gehrer [11:03:33] <kshishkov> DonDiego: if you can get to Bankstadt-am-Lufthafen you can get almost anywhere by train [11:03:40] <merbzt> Dark_Shikari: this line has some low values, how do I disable whatever those are ?-> mb P I16..4: 3.7% 0.0% 0.9% P16..4: 24.5% 3.8% 0.8% 0.0% 0.0% skip:66.3% [11:03:48] <thresh> kshishkov: you're coming as wel? [11:03:53] <Dark_Shikari> you don't [11:03:54] <kshishkov> thresh: yes [11:04:00] <thresh> kshishkov: ha nice [11:04:26] <av500> kostya overload [11:04:32] <thresh> :) [11:04:44] <kshishkov> thresh: saturday morning so probably I'll be as nice as Edinaya Rossiya symbol after premature hybernation end [11:05:16] <kshishkov> av500: when I was a student there were 3,5 Kostyas in our group and it still survived [11:05:38] <av500> 3+0.5 or 2+1.5? [11:05:53] <kshishkov> av500: what a silly question, you've seen me [11:06:01] <thresh> kshishkov: у нас тут был прикол -- в компании работают 3.5 Павловых [11:06:57] <cartman> what was the thing to send patches with git? git-send-patch something [11:07:17] <pross-au> git send-email [11:07:24] <av500> cartman: libswscale patches? [11:07:25] <cartman> thanks pross-au :) [11:07:25] <kshishkov> thresh: я как-то работал на кафедре где было два Ивановых (не родственники), а в дирекции Укртелекома вообще "работают" кланами [11:07:32] <cartman> av500: snowdsp_mmx :P [11:11:05] <kshishkov> cartman: Snow+lossy Sonic in NUT for the pure FFmpeg solution ;) [11:13:36] <cartman> kshishkov: NUT is vapurware, even more now that Duke Nukem Forever is coming. [11:13:44] <Cyril__> Hi [11:13:53] <Cyril__> I was wondering what is the timebase used for AVStream's index_entries[].timestamp [11:14:05] <Cyril__> From a logical point of view, I think it should be AVStream's timebase, but I've found such code in the mov.c file, so I'm having doubts [11:14:12] <Cyril__> AVIndexEntry *current_sample = &avst->index_entries[msc->current_sample]; [11:14:18] <Cyril__> int64_t dts = av_rescale(current_sample->timestamp, AV_TIME_BASE, msc->time_scale); [11:14:27] <Cyril__> So, is it AV_TIME_BASE or the streams's base ? [11:15:06] <Cyril__> I can propose a patch adding the @doxy for this field in the documentation [11:17:09] <DonDiego> please send that patch to the ml [11:17:37] <Cyril__> Yes, once I know what is the "expeced" time base for the field, I'll [11:18:45] <kshishkov> cartman: well, Nut is usable, it's just not very popular [11:18:58] <cartman> kshishkov: never heard anyone using it. [11:19:24] <cartman> Why does git format-patch doesn't extract my local commit as a patch :S [11:19:46] <kshishkov> cartman: lu_zero claimed something like that [11:20:06] <cartman> kshishkov: claimed what? :) [11:20:26] <kshishkov> cartman: using NUT of course! [11:20:29] <cartman> lol [11:20:59] <lu_zero> cartman: did you commit? [11:21:03] <cartman> lu_zero: yeah [11:21:07] <cartman> lu_zero: git log shows it [11:21:11] <lu_zero> your command line? [11:21:19] <cartman> git format-patch <commit hash> [11:21:29] <lu_zero> git format-patch <commit hash>^ [11:21:35] <cartman> hmm [11:21:58] <av500> hmm^ [11:21:58] <cartman> lu_zero: thanks! it silently ignored the first one then :) [11:22:59] <cartman> From: =?UTF-8?q?=C4=B0smail=20D=C3=B6nmez?= <ismail(a)namtrac.org> [11:23:03] <cartman> UTF-8 fsck [11:23:35] <siretart> DonDiego: yes, but I will likley make it to frankfurt by about 7 to 8pm. I doubt that Stefan is going to wait that long [11:25:59] <DonDiego> when will you arrive in brussels? [11:26:06] <DonDiego> will you stay until monday? [11:26:08] <Flameeyes> cartman: if you just want the latest, simply use "git format-patch -1" :) [11:26:11] <lu_zero> 4+ hours [11:26:29] <cartman> Flameeyes: is there a syntax to format all local patches? [11:26:37] <Flameeyes> cartman: git format-patch master.. [11:26:42] <cartman> Flameeyes: ah thanks [11:26:42] <cartman> :) [11:26:44] <Flameeyes> [including the two final dots] [11:26:51] <Flameeyes> works fine even if you do "merge master" a few times btw [11:26:59] <cartman> nice [11:29:22] <Flameeyes> uhm new nvidia driver, I wonder if it's going to work with suspension on my laptop [11:29:49] <Kovensky> 08:26.44 Flameeyes: [including the two final dots] <-- I thought they were implicit on format-patch? [11:30:08] <Kovensky> which is why when you do git format-patch <some commit> it makes a patch for all commits since <some commit> until HEAD [11:30:30] <Flameeyes> Kovensky: if they are they added it afterwards, used not to work [11:33:14] * cartman hugs CPAN [11:45:04] <spaam> cartman: perl user;SSSSS [11:45:44] <cartman> spaam: git still uses perl :) [11:46:04] <spaam> i know. i use it at work too. [11:46:16] <spaam> so i can read some pcaps better ;D [11:46:18] <cartman> spaam: intall Net::SMTP::SSL and done :D [11:46:27] <cartman> install* [11:47:39] <kierank2> i tried doing that once [11:47:45] <kierank2> didn't install and i gave up# [11:47:55] <cartman> kierank2: must have failed automated tests [11:51:42] <av500> köfte! [11:51:44] <siretart> DonDiego: If I manage to go, I'd most probably stay until monday [11:53:27] <DonDiego> cool, time to talk then [11:53:40] <DonDiego> i'm already looking forward to the beer event on friday :) [11:54:30] <lu_zero> so... [11:54:34] <lu_zero> what to book? [11:56:01] <cartman> av500: möhte [11:56:14] <lu_zero> (meanwhile we got more options regarding rooms =)) [11:59:26] <DonDiego> lu_zero: what did you find out? [11:59:39] <DonDiego> maybe post about it, easier to have everybody see the info in this way [12:14:16] <BBB> mru: I've traced the bsd/sparc bugs, fix should be pretty easy [12:15:25] <lu_zero> DonDiego: just got more rooms available [12:15:57] <lu_zero> apparently somebody rescinded the booking [12:17:21] <DonDiego> siretart: i'm confused now, coming or not? [12:18:57] <siretart> DonDiego: do you think stefan will wait until 8pm for me? [12:27:18] <pross-au> Q: How would i describe an 8-bit bayer pxlfmt using AVPixFmtDescriptor [12:28:49] <BBB> A: you might have to change AVPixFmtDescriptor a bit...? [12:29:08] <BBB> (is bayer really a pixfmt, or is it a codec? or "in between"?) [12:29:23] <pross-au> the later [12:30:48] <DonDiego> siretart: ask him, that would mean arriving in brussels around 00:00 i think... [12:37:43] <siretart> I too modest to set him on pressure with such a question. I've explained my situation in the mail, either he answers or he doesn't [12:40:13] <lu_zero> uhm [12:42:30] <Kovensky> http://i.remotehost.co/images/d5acdbbb6cea90e6f7513a26844ef8b1.jpg [13:10:02] <wbs> cartman: sure you're not indian? [13:12:12] <DonDiego> siretart: if you can catch the thalys somewhere you should be able to go to brussels quickly [13:12:48] <av500> thalys goes from cologne afaik [13:13:41] <siretart> what's thalys? [13:13:52] <cartman> wbs: why would you think that? [13:14:04] <cartman> wbs: did I ask for teh codez? :p [13:14:17] <wbs> cartman: on android-ndk, yes ;P [13:14:22] <cartman> wbs: ah lol [13:14:27] <cartman> wbs: thats well deserved [13:14:29] <kshishkov> siretart: French train going to Netherlands or Belgium and Germany [13:14:37] <cartman> wbs: stupid shit is not documented somewhere [13:14:49] <wbs> cartman: well, JNI is well documented in itself IMO [13:15:00] <kshishkov> siretart: French variant of ICE if you like ;) [13:15:10] <wbs> cartman: no need to have a specified "how do I use class X through JNI" document when you can read the JNI spec and use that to access whatever api you want ;P [13:15:23] <siretart> I thought they call it TGV. ok [13:15:27] <cartman> wbs: the only docs I found explains using C++ code inside Java [13:15:32] <cartman> wbs: not the other way [13:15:45] <cartman> wbs: please feel free to redirect to a RTFM for that :) [13:15:51] <wbs> cartman: the docs aren't NDK specific, just read the normal JNI docs [13:15:59] <cartman> wbs: ah [13:16:05] <wbs> cartman: http://download.oracle.com/javase/1.5.0/docs/guide/jni/spec/jniTOC.html [13:16:09] <wbs> cartman: there you go, RTFM [13:16:11] <cartman> ooops [13:16:22] * cartman will act like an Indian in ndk list from now on [13:16:28] <cartman> Hello, thank you, come back again. [13:16:32] <cartman> </simpsons> [13:16:45] <cartman> mv cartman apu [13:17:32] <lu_zero> ^^; [13:24:01] <kshishkov> siretart: yes, but they all have fancy names for international routes [13:33:01] <cartman> wbs: is there a way to get javah to create the header for you? [13:33:31] <wbs> cartman: yes, if you've got the normal eclipse setup where binaries are built under $proj/bin, do javah -classpath $proj/bin com.foo.MyClass [13:33:51] <cartman> wbs: right but the class is android.media.MediaPlayer :) [13:34:08] <wbs> cartman: why would you need a header for that? [13:34:14] <wbs> cartman: you're doing it wrong [13:34:33] <cartman> wbs: ok I could just write the method declerations by hand I guess [13:34:43] <wbs> cartman: what method declarations do you need? [13:35:00] <cartman> wbs: MediaPlayer.create [13:35:13] <cartman> and start() [13:35:37] <wbs> cartman: yes, and in order to call that from JNI, you don't use a JNI header, that's for calling native functions from java (javah creates such headers only for the methods declared with native) [13:35:59] <cartman> argh [13:36:00] <cartman> ok [13:36:18] <wbs> cartman: you use FindClass and GetMethodID and CallVoidMethod etc for calling java methods from native [13:36:30] <cartman> ok [13:36:40] * mru has disturbing memories of implementing that shit in a jvm [13:36:42] <wbs> ... all of that exactly as you do in every other JNI environment, none of that is android specific [13:43:32] <wbs> mru: btw, I'm getting "Error: bad instruction stm" (and the same for ldm) on some ancient gcc/binutils - is that some meta-instruction that newer binutils expands into longer instructions? [13:44:04] <mru> no [13:44:12] <mru> just update binutils [13:44:25] <mru> old ones might insist on stmia/ldmia [13:44:45] <mru> even without base reg writeback [14:14:54] <BBB> Dark_Shikari: please review the C patch also when you wake up [14:15:33] <j-b> good morning BBB [14:16:33] <BBB> hi j-b [14:38:57] <kierank> http://forum.doom9.org/showthread.php?p=1474381#post1474381 [14:39:51] <kshishkov> so? [14:40:39] <cartman> wbs: ok got Hello World working :P [14:40:48] <kierank> kshishkov: just saying [14:40:48] <wbs> cartman: congrats :-) [14:40:51] <cartman> wbs: in desktop jni :P [14:41:11] <av500> cartman: so now you can publish ffmpeg in google market? [14:41:25] <kierank> av500: maybe he's more chinese then [14:42:00] <cartman> wbs: but the normal (desktop) examples use JNI_CreateJavaVM but I think I should just use JNI_onLoad to get a VM pointer, right? [14:42:25] <j-b> av500: btw, vlc works on the Archos 32 on 2.2 [14:42:34] <cartman> j-b: how? :D [14:42:37] <cartman> where :D [14:42:37] <wbs> cartman: uh.. that depends on where you want your code to be called [14:42:43] <av500> j-b: nice [14:42:44] <j-b> cartman: how? with C++ code [14:42:51] <cartman> j-b: nice nice. [14:42:52] <j-b> cartman: where? on the Archos 32 [14:42:53] <wbs> cartman: normally, you mark a method native in java, then implement that in JNI [14:42:59] <cartman> j-b: send me the apk :P [14:43:23] <j-b> cartman: well, it is a bit too early for that :) [14:43:23] <wbs> cartman: but if you don't want to go via java at all, you'd better just look at the nativeactivity stuff from 2.3 [14:43:33] <cartman> wbs: hmm in this case I want to call arbitrary Java methods [14:43:41] <cartman> wbs: nope we only have 2.2 atm. [14:43:49] <j-b> cartman: we started as 2.3, and we are going back to 2.2 [14:43:52] <cartman> j-b: congrats! :) [14:44:00] <wbs> cartman: yes, but the native code that calls java methods, who calls that? [14:44:18] <cartman> wbs: a library loaded via JNI [14:44:36] <cartman> Java -> libmyapp.so -> calls Java method [14:44:46] <wbs> yes [14:44:55] <j-b> cartman: the vout was 2.3 (native only) and now is 2.2 too ( jni) [14:45:00] <wbs> but why do you need to get a VM pointer at all? isn't JNIEnv enough? [14:45:14] <cartman> j-b: very nice :) [14:45:38] <cartman> wbs: I only need JNIEnv yes, but where does Android pass that to me? :) [14:46:00] <wbs> cartman: it passes it as the first argument to every single JNI method that java calls in your .so [14:46:15] <wbs> cartman: you've never ever done this before, and still you talk so much on all the android-ndk lists? ;P [14:46:27] <j-b> cartman: the apk we have is not-NEON enabled yet [14:56:16] <lu_zero> BBB: what about soc11? [14:58:10] <Compn> DonDiego : you alive ? [14:58:35] <Compn> i plan to commit that ffmpeg.org download patch today unless you want to reword somethin [14:58:46] <Compn> i think lu_zero said something about it too ? [14:59:11] <Compn> lu_zero , DonDiego : any rewording ideas ? [14:59:29] <Compn> the second one, with the 'mean, dirty,' line michael came up with [15:00:01] <DonDiego> i will suggest marking it as private dev tree [15:00:06] <mru> Compn: do not commit that [15:00:20] <Compn> DonDiego : but its open to whomever [15:00:30] <Compn> mru : suggestions welcome [15:00:40] <lu_zero> Compn: [15:00:45] <mru> I'll do something today [15:00:52] <Compn> .... [15:01:06] <Compn> thought you werent going to do anything for michael :) [15:01:06] <merbzt> Compn: I agree abit with you here, but I want a neutral name for both repos [15:01:07] <Compn> ehe [15:01:08] <lu_zero> repo ${foo}, tree maintained by ${person} [15:01:36] <lu_zero> possibly [15:01:38] <Compn> merbzt : yeah, well get the tree listed, then you can bikeshed your names later [15:01:54] <lu_zero> repo ${foo}, tree maintained by ${person}, mirror(s) : ... [15:02:04] <mru> lu_zero: that's what I had in mind [15:02:16] <lu_zero> mru: =) [15:02:18] <mru> and throw in some more trees too [15:02:21] <Compn> lu_zero : sure sounds fine, whos the new tree maintained by $person ? [15:02:22] <mru> like mine [15:02:37] <lu_zero> I should push mine somewhere [15:02:53] <Compn> but the description should stay, at least its accurate [15:03:02] <merbzt> lu_zero: I like that idea [15:03:26] <DonDiego> Compn: open to whomever? [15:03:42] <DonDiego> i haven't sent in my ssh key yet, high time to try i guess... [15:03:50] <Compn> DonDiego : yes, michael has said a few times if anyone wants commit access... [15:04:10] * Compn chortles [15:04:16] <Compn> well, be interesting at least [15:04:26] <Compn> :) [15:05:22] <kshishkov> Compn: I'm too lazy to generate it. And I've forgotten passphrase for my GPG key minutes after I generated it [15:05:55] <spaam> kshishkov: fail [15:05:55] <Compn> kshishkov : you should have id_rsa or some kind of file, or if you sent it into ffmpeg repo, someone else may have it for you [15:06:03] <pJok> kshishkov, are you sure you just didn't one-way encrypt it? ;) [15:06:13] <Compn> we can pass around your key even if you cant generate it again [15:06:15] <mru> kshishkov: try bits of the swedish national anthem [15:06:46] <kshishkov> mru: in my case too obvious and not all keyboards have åäö [15:06:49] <Compn> so wait, isnt it the same passphrase as your ssh password ? [15:07:13] <Compn> how would you login... if you dont have the ... [15:07:15] <{V}> since file maintainers can get (and some have) commit access on the videolan repo, maybe "lead by" rather than "maintained by" ? [15:07:16] <Compn> anyway you can generate a new one :P [15:07:34] <Compn> {V} : still waiting to know who 'leads' the new tree... [15:07:35] <spaam> {V}++ [15:07:53] <spaam> Compn: "The new maintiners".. [15:07:56] <Compn> lol [15:07:56] <kshishkov> Compn: where to? [15:08:20] <lu_zero> uhm [15:08:30] <Compn> kshishkov : where to send key? you could reply to michaels last mail i guess? [15:09:50] <Compn> anyways, must go afk now [15:10:03] <Compn> mru has 24 hours :P [15:10:30] <Compn> or maybe 12hr who knows [15:10:50] <lu_zero> yawn [15:21:00] <superdump> BBB: have you started on xvp8 yet? :) [15:21:37] <BBB> a little, but only in private [15:22:12] <mru> when do you start at google? [15:22:35] <BBB> end of march [15:23:00] <kierank> is it true that you'll be working full time on xvp8 then? [15:23:01] <superdump> and when is xvp8 due? [15:23:14] <kshishkov> "when it's done" [15:23:19] <kierank> superdump: day after x262's done ;) [15:23:22] <BBB> "when it's done":) [15:23:33] <kshishkov> like DNF before it was completely spoiled [15:24:25] <av500> BBB: btw, the guy that hired you got kicked out [15:24:30] <av500> that schmitt guy [15:24:50] <kshishkov> av500: are you going to remind him every week? [15:24:55] <superdump> :) [15:25:01] <superdump> 'that schmidt guy' [15:26:03] <kshishkov> for av500 there's only one guy from M$ exists [15:26:41] <kierank> Ballmer writes all the code [15:26:44] <kierank> throws all the chairs [15:26:53] <av500> kshishkov: there is one guy I have worked with for years, he is now at m$, its the only guy I know *exists* :) [15:27:30] <kshishkov> av500: hmm, such guy would rather unexist for me [15:27:38] <av500> he is bored [15:27:50] <av500> so he will ununexists soon [15:27:57] <mru> reexist [15:28:13] <kierank> ctrl-alt-exist [15:31:09] <kierank> I saw a car registration plate the other day. "10l" [15:31:37] <andoma> hum hum .. a bit OT but starting with gcc 4.4.x it seems that it emits less warnings for uninitialized variables [15:32:07] <andoma> i can compile some code in 4.4.x with no warnings.. and then when trying with 4.3.x I get (correct) warning about uninitialized vars [15:32:45] <andoma> i was just wondering if anyone else have seen the same thing [15:34:29] <kshishkov> not FATE [15:35:27] <iive> kierank: really? [15:36:58] <mru> andoma: that's not unreasonable [15:37:14] <mru> presumably gcc got better at tracking data dependencies [15:37:39] <kierank> iive: yes and I lol'd and people were looking at me weird [15:37:56] <CIA-43> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r4c57cde942 ffmpeg/libavcodec/ (ac3.c ac3.h ac3dec.c ac3enc.c): [15:37:56] <CIA-43> ffmpeg: Add ff_ prefix to ac3_common_init(). [15:37:56] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:37:59] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r7767d8d361 ffmpeg/libavcodec/ (fft.c fft.h): [15:37:59] <CIA-43> ffmpeg: Mark C base versions of FFT functions static to fft.c [15:37:59] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:38:07] <mru> there's a car in my street with X268 on the licence place [15:38:12] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * reb7ccf8f33 ffmpeg/libavfilter/ (avfilter.c internal.h): [15:38:12] <CIA-43> ffmpeg: Make the avfilter debug functions and macros static to avfilter.c [15:38:12] <CIA-43> ffmpeg: This removes ff_get_ref_perms_string, ff_dprintf_ref and ff_dprintf_link [15:38:12] <CIA-43> ffmpeg: fro the interface of libavfilter. [15:38:12] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:38:14] <CIA-43> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r24e3ad3031 ffmpeg/libavcodec/ac3.c: [15:38:14] <CIA-43> ffmpeg: ac3: Remove ff_ac3_critical_band_size_tab. [15:38:14] <CIA-43> ffmpeg: It is only used to generate band_start_tab, which about the same size, at [15:38:14] <CIA-43> ffmpeg: runtime, so it's simpler just to always hardcode band_start_tab. [15:38:14] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:38:27] <kshishkov> mru: too early for that [15:40:19] <mru> siretart: ping [15:41:53] <siretart> mru: pong [15:42:07] <mru> siretart: please comment on http://patches.ffmpeg.org/patch/528/ [15:43:15] <siretart> on my way [15:43:56] <mru> thanks [15:44:30] <siretart> anyone feeling to share a room with me from *sat* -> *mon*? (I could take the plane on sat morning) [15:44:52] <mru> you'll miss friday beer [15:44:59] <siretart> indeed [15:45:20] <Compn> ok iz back, i miss anything [15:46:24] <uau> cartman: does clang do its own parsing for asm or use a custom assembler? it doesn't just pass inline asm to an underlying 'as' command? [15:47:00] <lu_zero> siretart: me and Diego could book 1 day for the twin and then switch for the triple [15:47:07] <cartman> uau: it has its own assembler [15:47:30] * lu_zero re-checks about availabilities [15:47:45] <kshishkov> mru: so I won't spoil your Friday evening with my sober face too [15:49:46] <DonDiego> siretart: we'll miss you for friday beer :-( [15:50:03] <av500> We will drink his share [15:50:22] <DonDiego> av500: you drink it, you're twice my size... [15:50:28] <superdump> i should check what time i arrive on friday [15:51:36] <lu_zero> may I book now? [15:52:56] * mru updates to clang head [16:01:43] <cartman> mru: good :p [16:02:02] <mru> is this a very recent thing in clang? [16:02:08] <cartman> ~1 month [16:02:09] <cartman> or so [16:02:19] <mru> I may have just missed it then [16:02:32] <BBB> anyone have a ppc? [16:03:09] <BBB> I want someone on a ppc+altivec to try a patch for me [16:03:10] <BBB> brb [16:03:43] <mru> BBB: /me has [16:03:49] <mru> and you may have an account on it [16:16:50] <mru> cartman: now on clang rev 124291 [16:17:52] <cartman> mru: still works? (MPlayer) [16:18:07] <mru> fate will test ffmpeg in a moment [16:18:31] <cartman> ffmpeg works here, only MPlayer [16:18:46] <mru> so find out what's different [16:18:51] <mru> compare cflags etc [16:18:59] <cartman> ok [16:31:59] * kierank curses libsndfile [16:32:15] <spaam> why? [16:32:40] <kierank> doesn't build and it just a silly wrapper [16:33:04] <spaam> wrap a wrapper round it [16:33:23] <mru> wrap it around itself [16:33:23] <spaam> mru know how to do that i have heard. [16:33:35] <kierank> might end up doing that in fact [16:33:50] <kierank> adding twolame to ffmpeg :/ [16:35:10] <cartman> toolame [16:35:38] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r2d162e3825 ffmpeg/ (libavcodec/iff.c libavcodec/iff.h libavformat/iff.c): [16:35:38] <CIA-43> ffmpeg: Make ff_cmap_read_palette static to libavcodec/iff.c. Delete iff.h. [16:35:38] <CIA-43> ffmpeg: The iff.h header only declared one function that is now static, the [16:35:38] <CIA-43> ffmpeg: libavformat/iff.c source file wasn't using it before. Drop the file [16:35:38] <CIA-43> ffmpeg: entirely. [16:35:38] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:35:42] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rd36beb3f69 ffmpeg/libavcodec/ (268 files): [16:35:42] <CIA-43> ffmpeg: Add ff_ prefix to data symbols of encoders, decoders, hwaccel, parsers, bsf. [16:35:42] <CIA-43> ffmpeg: None of these symbols should be accessed directly, so declare them as [16:35:42] <CIA-43> ffmpeg: hidden. [16:35:42] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:36:05] <spaam> kierank: why do you want twolame? [16:36:35] <kierank> mp2 encoding of course [16:36:48] <mru> how 1993 [16:37:14] <spaam> kierank: something wrong with mp3? acc? wv? .amr ? [16:38:21] <kierank> need to test it on this stb [16:38:35] * kierank agrees with mru about 1993ness [16:39:00] <kierank> oh finally autotools picked it up [16:48:12] <mru> hmm, new unused function warning: http://fate.ffmpeg.org/armv5te-linux-armcc-4.0/20110126164053/compile/20110… [17:01:10] <lu_zero> roundup nas back online... [17:02:29] <BBB> mru: can I send you a patch and you tell me if it fixes make fate-vp8 on it? [17:02:44] <mru> BBB: I can give you an ssh login on the ppc [17:02:48] <BBB> ok [17:02:59] <mru> but it's not broken there, so what's to fix? [17:03:00] <BBB> lu_zero: \o/ so comments work again? [17:03:13] <BBB> mru: it crashes on a few samples on one of the fate machines, and I think I know the bug [17:03:20] <mru> not mine [17:03:22] <BBB> (since a few days - not the other ppc that always has different output) [17:03:22] <siretart> lu_zero: okay, I think I found a connection to attent. not exactly inexpensive, but anyway [17:03:30] <BBB> can I test the patch anyway? [17:03:34] <BBB> if it doesn't break I'll commit it [17:03:37] <BBB> it's more correct [17:03:41] <mru> BBB: can't you test it yourself? [17:03:46] <siretart> lu_zero: in that case I'd stay 2 nights: saturday night and sunday night [17:03:49] <BBB> don't have a ppc with altivec [17:03:55] <mru> the crashing machine is a sparc belonging to kostylev [17:03:56] <siretart> lu_zero: did you already order the rooms? [17:04:05] <siretart> err, book, even [17:04:11] <lu_zero> still waiting ^^; [17:04:11] <BBB> mru: that one is fixed, but crash is in c code; I think the crash on ppc is in altivec code [17:04:35] <mru> BBB: oh, it's failing on ppc/darwin [17:04:40] <mru> that's not mine either [17:12:19] <siretart> lu_zero: okay, tell/mail me if you booked the room. I'll then order the flight tickets [17:14:02] <BBB> mru: yeah that one is the one I mean [17:14:14] <BBB> astrange: ping [17:15:18] <lu_zero> av500, wbs do you have an rtp-ts source around? [17:15:35] <av500> no [17:15:41] <av500> its the free.fr box [17:15:44] <av500> in france only [17:15:51] <av500> but I have a login [17:15:58] <av500> I can check patches tonight or so [17:20:37] <astrange> pong [17:30:11] <BBB> astrange: any ideas on the mpeg/wmv/etc encoding? the problem is encoding only, decoding is fine [17:30:20] <BBB> astrange: the problem is related to ME around the edges, I think [17:30:34] <BBB> astrange: is it posible that the encoder doesnt' draw edges around the prev frame (used for ME) at all? [17:30:53] <BBB> astrange: that is my rough guess looking at the changes observed [17:31:08] <BBB> (i.e. it used to, but somehow that code got disabled in ffmpeg-mt) [17:33:50] <astrange> it's possible [17:36:02] <BBB> that's about as far as I've gotten [17:36:08] <BBB> that's also the only two bugs I see [17:36:24] <BBB> all other test failures can be reduced to either the h264 bug you are hopefully working on, or this one [17:36:34] <BBB> which one would you like me to work on? [17:36:37] <BBB> and can you work on the other? [17:42:36] <astrange> you can take the make test one, try reverting ff_draw_horiz_band and MPV_frame_end in mpegvideo.c [17:45:20] <lu_zero> av500: since I have a _really_ ugly thing to try [17:45:50] <av500> lu_zero: and you think I would refuse that? [17:45:51] * lu_zero is thinking about optimizations [17:46:34] <lu_zero> av500: it's basically hack some code that fill a buffer and then runs the normal mpegts functions as they would over it [17:46:54] <lu_zero> all of it placed in the codepath currently present [17:47:04] <lu_zero> and I'm still dubious about it =P [17:47:14] <Sean_McG> I really need to swap in that faster processor module on my SPARC... it's still building gcc trunk (well, running the testsuite anyways) after 15 hours [17:47:48] <mru> Sean_McG: what cpu is that? [17:48:23] <Sean_McG> mru: I have a Sun Blade 1000 with a 750MHz US3... but I got a 900MHz module for it off of eBay but I'm missing the torque tool to put it in [17:54:05] <av500> [18:43:48] <coppolla> i heve a probleme with this command "sudo chown <your login> /usr/src/android" [17:54:10] <av500> [18:49:48] <akk> What problem? [17:54:16] <av500> [18:52:19] <coppolla> bash: your: No such file or directory [17:54:27] <mru> :) [17:54:42] <mru> there is one word for such people: *plonk* [17:58:01] <Sean_McG> hahahahah [18:01:46] <BBB> Dark_Shikari: ping please review vp8 patch :-p [18:02:14] <wbs> lu_zero: I've got one [18:02:34] <BBB> mru: can you say that timebase-unreliable in the 0/2 thread? there it's explained better and I think you and I basically agree on the same thing [18:02:40] <BBB> mru: at least I think what you say makes sense [18:03:05] <mru> yes, I'm pretty sure we agree [18:03:24] <mru> the problem is that 80% of numbers from lavf are pure fiction [18:04:46] <kshishkov> mru: you insult BBB. RM demuxer has higher rate of fictious numbers [18:04:46] <BBB> indeed [18:04:49] <lu_zero> wbs: where =) ? [18:09:16] <wbs> lu_zero: http://albin.abo.fi/~mstorsjo/RTP_mpegts_sample.{cap,rtpdump} - it's from some roundup case a few months back [18:11:00] <Sean_McG> ooo yay roundup works today [18:11:28] <mru> yeah, it's round-to-even, works on even days [18:11:38] <Sean_McG> heheheh [18:18:49] <lu_zero> Sean_McG: hopefully [18:19:20] <Sean_McG> ah so it's still a fingers-crossed kinda thing [18:20:31] <lu_zero> Sean_McG: I don't have control over the nas [18:20:34] <lu_zero> nor the hardware [18:20:49] <lu_zero> the software now seems properly working [18:25:03] <Sean_McG> ah [19:21:18] <mru> re commit rules, I never liked the 48h commit ultimatum method [19:21:27] <av500> 54h ftw [19:22:04] <mru> it's simple a matter of quality control [19:34:44] <DonDiego> gtg, cu [19:35:08] <mru> lu_zero: ping [19:36:45] <uau> Flameeyes: re your mail, that "if the upgrade happens at the same time" argument doesn't always work because of the library major version issue i mentioned yesterday [19:36:59] <Flameeyes> uau: which one? [19:37:37] <uau> which main? the latest on ffmpeg-devel, where the quote is from [19:37:44] <uau> /main/mail/ [19:37:53] <uau> or which argument? [19:38:00] <Flameeyes> which argument [19:38:32] <uau> you can't rely on ffmpeg libraries having matching versions if their major version numbers change independently [19:38:38] <Flameeyes> doesn't matter [19:38:59] <uau> why wouldn't it? [19:39:45] <Flameeyes> the original problem with ABI and Debian (and other binary distros), for which siretart pushed for versioned libraries relates to projects that link more than one FFmpeg library [19:40:26] <Flameeyes> in that situation, the fact that the ABI version of the libav* set differ, is the root cause, but it's relieved by the presence of ABI versions so that symbols don't clash with one deptree to the other [19:40:56] <Flameeyes> so you can have a process loading both a libavutil.so.50 and a libavutil.so.49, but only a libavcodec.so.52 [19:41:03] <uau> your symbol rename _would_ cause breakage with suitable major changes - do you not see that, or are you saying it doesn't matter? [19:41:37] <siretart> who uses that particular symbol? [19:41:38] <Flameeyes> how would it, assuming no ABI version change [19:41:44] <Flameeyes> siretart: only libavformat.so.52 [19:42:02] <uau> Flameeyes: here's an example where things would break [19:42:10] <siretart> so it is a purely internal symbol. great! [19:42:20] <uau> suppose a symbol is defined in libavcodec and used by libavformat [19:42:22] <Flameeyes> so if you replace _both_ libavformat.so.52 and libavutil.so.52 at the same time, you will _not_ feel any breakage [19:42:42] <Flameeyes> siretart: no, it's libavcodec→libavformat, it's an interlib symbol the one in the example [19:42:45] <mru> that symbol was only used by lavf for a short time [19:42:55] <siretart> Flameeyes: oh, I see [19:42:56] <Flameeyes> the one Ronald asked about is purely internal one so the original problem is moot [19:43:11] <Flameeyes> uau: sure like the one I used as an example [19:43:48] <uau> your example only mentioned a case where use doesn't install all new ffmpeg libraries [19:43:58] <uau> use/user [19:44:31] <Flameeyes> if you drop it with an ABI bump, you'll have libavcodec.so.50 with symbol, libavcodec.so.51 without it, old libavformat.so.52 uses it and links to the former; new libavformat.so.52 uses it and links to the newer → you have no issue at all [19:45:19] <uau> yes if you DO change major version at the rename then things work [19:45:41] <Flameeyes> if you drop it without ABI bump, you'll have old libavcodec.so.50 with symbol, new libavcodec.so.50 without it; old libavformat.so.52 using it, new libavformat.so.52 not using it it; software started before update uses the old (unlinked) version, software started afterwards will use the new versions [19:45:57] <Flameeyes> the only case you have where it will go wrong is if you mix new libavformat and old libavcodec [19:46:12] <Flameeyes> but that situation only happens if you _don't_ do a whole-package update of ffmpeg per each build [19:46:21] <Flameeyes> [which as far as I can tell is not the case for Debian] [19:46:25] <uau> Flameeyes: that "without ABI bump" case is not so simple [19:46:40] <Flameeyes> uau: note what I wrote in my mail: "if they are upgraded at the same time" [19:46:43] <Flameeyes> in that case yes, it is so simple [19:46:50] <uau> no it isn't :) [19:46:56] <Flameeyes> why it isn't? [19:47:10] <uau> if there's an unrelated ABI bump of _libavformat_ then things break [19:47:11] <Flameeyes> [which is what I asked you a 15 minutes ago] [19:47:27] <Flameeyes> uau: "wow" you just came up with a _different_ situation than what I described [19:48:27] <uau> different? not really IMO - the case your claimed to work actually doesn't without _additional_ assumptions about libavformat ABI not changing [19:49:16] <Flameeyes> yes it is different, because I explicitly work in my "not so simple" example, .so.52 [19:49:34] <Flameeyes> yes it _is_ different if you end up mixing and matching more between sonames [19:50:00] <Flameeyes> but whether that works or not, at all, is up for discussion IMHO [19:50:50] <Flameeyes> also note I'm not expecting upgrades to always happen synchronously, so I'm _not_ advocating changing the interlib dependencies without keeping compatibility symbols [19:50:53] <Sean_McG> yikes, library versioning [19:51:16] <uau> well let's say that it was the "you'll have ... old libavformat.so.52 using it, new libavformat.so.52 not using it it" that was inaccurate then (you need the _additional_ assumptions for that to be true "if you drop it without ABI bump") [19:51:56] <Flameeyes> uau: I wrote the bloody version numbers of both libraries out in full. THAT was your damn assumption "without ABI bump" [19:54:14] <uau> come on, your line was "if you drop it without ABI bump, you'll have..."; i think it's reasonable to interpret the rest as what you claim would happen in the "without ABI bump" case [19:55:05] <uau> so anyway, "drop it without ABI bump" is NOT safe if you just install new versions simultaneously [19:56:23] <uau> you'd at still at least need to ensure that the ABI bump _does_ happen some time before (or at the same time as) libavformat ABI is next bumped [19:56:42] <Flameeyes> *shrug* there isn't really any difference in "safety" between _removing_ and _adding_ interlib symbols [19:57:31] <Flameeyes> so one way or another, the solution is *not* to have them, bump all the bloody sonames, and possibly either bump all of them at once, or start a realistic procedure for bumping them on a watefall model [19:58:04] <av500> are there projects/distros that do not update all ff libs at the same time? [19:58:25] <uau> how so? removing has the problem above; i don't immediately see how adding them could cause similar problems [19:58:33] <Flameeyes> [i.e. you change the soname of the consumer libraries when the provider library changes soname] [19:59:32] <Dark_Shikari> BBB: it looks to be duplicating information in the macro args... [19:59:37] <Flameeyes> uau: your problem above happens only if one library renames a symbol, and the other one bumps ABI; the same applies in the case a new symbol is added to the former and used in the latter [20:00:12] <Flameeyes> but I really have better things to do than trying to come up with theoretical situation caused by async upgrades (which are, by large, a bad thing to do) [20:00:31] <uau> async? there was nothing "async" about the case i mentioned above [20:01:47] <Flameeyes> it only happens if one of the ABI-slotted libraries doesn't get upgraded [20:01:52] <Flameeyes> for me that's an async update [20:01:52] <uau> i don't see how your addition problem case would work (unless you assume async for that case) [20:03:07] <Flameeyes> av500: most binary distribution "slot" libraries by soname [20:03:31] <uau> the problem i described can happen if you install newest major versions of all the libraries [20:04:07] <uau> if you mean that leaving older sonames at their previous version would be "async" i don't agree with that - IMO that's something that _will_ happen in practice [20:04:25] <Flameeyes> since – this is the part uau definitely got right – ffmpeg doesn't use the same ABI version for all libraries, it is possible that it it would mix a libavutil.so.50 (without the symbol), a libavformat.so.52 (using the symbol) and a libavformat.so.53 (not using it) [20:04:56] <Flameeyes> but in that case to me that counts exactly as an async because libavformat.so.52 is not built against the latest libavutil.so.50 [20:05:48] <av500> Flameeyes: that answer confused me even more :) [20:05:52] <uau> Flameeyes: eh? you CAN'T possibly build it against the "latest" version [20:06:31] <Flameeyes> uau: sure you can — it is a mess, it is long, boring and generally speaking not worth the time spent on it, but you can [20:06:42] <uau> since the only the newest ffmpeg version produces that libavutil, and it doesn't produce libavformat 52 any more [20:07:09] <Flameeyes> do agree that it's much better to have the versions all together at the next bump [20:07:12] <uau> well if you mean hacking ffmpeg build system to do something completely different, maybe for those values of "can", but IMO that's pretty unrealistic [20:07:12] <Flameeyes> *I do [20:07:47] <BBB> Dark_Shikari: will look, sec [20:08:25] <Flameeyes> uau: I don't think you have to go much far about the FFmpeg build system to do that.. pretty sure it is designed to allow that being done easily [20:09:05] <uau> i do not believe it's designed to allow compiling libavformat against an older libavutil already found on the system [20:09:44] <Flameeyes> other way around, older libavformat against new libavutil is what I meant [20:10:01] <uau> and i haven't heard of distros doing anything like that in practice [20:10:44] <uau> i'm pretty sure most would not consider that to be something normally needed to get packages to work [20:10:46] <Flameeyes> ask that to siretart, but sincerely my solution is much easier (I don't deal with slots) [20:11:14] <Flameeyes> tell me another multi-library, async ABI package han FFmpeg [20:12:05] <BBB> Dark_Shikari: http://pastebin.com/PsR7W6Sc better? [20:12:44] <Dark_Shikari> FILTER_4TAP and FILTER_6TAP still seem redundant? [20:12:49] <Dark_Shikari> can those not be eliminated given gcc macro syntax? [20:13:21] <BBB> I can try inlining them under an if (HTAPS==6) or so [20:13:30] <BBB> that's what the ppc optimizations do [20:13:36] <BBB> should be same speed [20:13:38] <BBB> let me check [20:13:45] <Dark_Shikari> how about FILTER_##HTAPS##TAP? [20:14:28] <uau> Flameeyes: the expectation is for all multi-library packages (so they would not have async ABI if there are such issues; your implicit assumption about the scope of the expectation - that it only applies if it's already know to have async ABI - is too narrow) [20:14:46] <BBB> Dark_Shikari: does that work? [20:14:48] <BBB> Dark_Shikari: let me try [20:15:10] <Dark_Shikari> No idea [20:15:43] <Flameeyes> uau: really we're debating theoretical versus real-world.. and I'm sick tired of theoretical right now [20:15:54] <BBB> Dark_Shikari: trying... switching git branches takes forever [20:16:41] <uau> Flameeyes: IMO the "without ABI bump" case above is a completely real-world thing [20:18:04] <uau> if you remove "internal" symbols like that and then somewhat later bump ABI of the depending lib only, it's quite possible it _will_ break installations in practice [20:18:29] <Flameeyes> uau: which is why I'm NOT suggesting removing them! [20:18:46] <Flameeyes> I'm suggesting removing INTERNAL symbols and not INTERLIB symbols [20:18:58] <Flameeyes> INTERLIB symbols should be migrated and then both libraries' ABIs bumped [20:19:02] <Flameeyes> so that they can go away [20:27:36] <BBB> Dark_Shikari: yeah, works [20:27:41] <BBB> much easier [20:32:58] <BBB> Dark_Shikari: please re-review, let's see if this is better [20:33:00] <BBB> works for me [20:33:09] <BBB> (only compile-tested of course) [20:33:28] <Dark_Shikari> what? you just resent the same mail [20:33:36] <BBB> no it has a different attachment [20:33:43] <Dark_Shikari> attachment? [20:33:45] <Dark_Shikari> what attachment [20:33:53] <BBB> wait it didn't [20:33:54] <BBB> damnit [20:34:45] <Dark_Shikari> Still no patch. [20:35:01] <BBB> patch is inlined in the email [20:35:18] <BBB> is that better? [20:36:21] <BBB> ty [20:36:39] <lu_zero> michaelni: are you eventually out of mind or you consider wishing suicide/death a normal behaviour? [20:37:32] <michaelni> lu_zero, iam sorry this joke really misfired [20:37:42] <michaelni> i just tried to be funny [20:39:00] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r22893e10ae ffmpeg/libavcodec/vp8dsp.c: [20:39:00] <CIA-38> ffmpeg: VP8: don't overread edges on fourtap MC. [20:39:00] <CIA-38> ffmpeg: Fix C VP8 H+V MC functions which do two-dimensional 4/6-tap filters to [20:39:00] <CIA-38> ffmpeg: not overread beyond their edges if the second filter is 4-tap, since [20:39:00] <CIA-38> ffmpeg: the outer pixels aren't there anymore since [20:39:00] <CIA-38> ffmpeg: 44002d8323023c35f51d523a7d305e45103ba7a1. [20:39:28] <kierank> lu_zero: committing seppuku doesn't mean suicide literally. [20:39:55] <mru> BBB: what does that change mean for asm versions? [20:40:07] <mru> it's often _very_ useful to load a few pixels more than you need [20:40:20] <mru> like loading a full 8-byte register even if you only need 5 pixels [20:41:10] <michaelni> and besides trying to be funny, the recent events have been quite a bit stressfull [20:43:24] <lu_zero> michaelni: you are using quite strong words and some are really ticking me off [20:44:01] <michaelni> iam sorry [20:44:17] <michaelni> i felt it would be funny when i write it [20:44:33] <michaelni> but later realized it was a very bad idea especially now [20:44:55] * michaelni uses strong words in jokes in real life too [20:45:12] * michaelni is rarely misunderstood [20:45:41] <michaelni> people know iam joking when i wish them to .. well ... [20:46:10] <BBB> mru: it's padded at the end of the buffer [20:46:18] <BBB> mru: but these are reading before the buffer start [20:46:35] <BBB> mru: which used to work fine by accident for fourtapfilters using sixtap-padding, but now doesn't work anymore [20:46:50] <BBB> mru: so you can do the 5/8 by reading 3 extra pixels at the end, but not at the start [20:47:03] <kierank> michaelni: are you going to join #x264dev [20:48:27] <Compn> hey its michael1 [20:48:52] <Compn> oh i'm slow [20:49:00] <kierank> hey it's Compn [20:49:04] <Compn> hey its me [20:49:17] * kierank is reminded to upload some more samples [20:50:04] <Compn> upload them directly into samples [20:50:09] <Compn> you know how to do it kierank ? [20:50:10] <Compn> :P [20:50:29] * kierank doesn't have login [20:50:42] <Compn> the devel login ? [20:50:55] <Compn> to access incoming [20:51:04] <Compn> just cd samples instead [20:51:18] <Compn> or you dont have that either ? [20:51:35] <kierank> lemme see [20:51:51] <Compn> if not i can pm it to you [20:54:40] <michaelni> kierank, remind me 5 times a day and ill join in a month :) [20:55:02] <kierank> ok [20:55:13] <kierank> you seem to be of the same mindset of pengvado and patch reviews [21:18:29] <elenril> jannau: ping [21:18:59] <elenril> c34461b35b68ff1f3d04540e0279383c51be8cee/ 'mov: simplify mov_read_chapters() by using avio_get_str16be' is wrong version of the patch [21:22:06] <elenril> also michaelni, what happened to the playlists patch? [21:26:10] <spaam> kierank: haha. maybe pengvado have alot of things to do ;) [21:27:15] <kierank> spaam: you've seen patch review on #x264dev [21:27:25] <Sean_McG> still, I'm surprised the water from my fishtank doesn't help to keep the air humid [21:27:29] <Sean_McG> ewps, ww [21:28:07] <spaam> kierank: maybe. i dont follow that channel so much.. why? beacuse its in window 56 [21:28:35] <elenril> you people are a bad influence [21:28:56] <elenril> now my window count got to 17 [21:29:39] <wbs> I try to keep it below 20, too, to be able to access them with numbers/letters in irssi ;P [21:30:20] <Sean_McG> and here I am having trouble with 4. [21:30:20] <spaam> wbs: i changed so i can have it up 28.. [21:30:31] <wbs> spaam: oh, how's that done? [21:31:23] <spaam> wbs: /bind meta-a change_window 20 [21:31:30] <spaam> /help bind [21:31:34] <wbs> oh, nice :-) [21:31:48] <spaam> yeah :) [21:31:52] <mru> the default action of meta-a is nice though [21:32:01] <mru> could go on another key of course [21:32:30] * elenril tries meta-a [21:32:36] <elenril> wow [21:32:38] <elenril> nice [21:32:45] <mru> goes to the next window with activity [21:32:53] <elenril> yeah, already noticed [21:33:00] <Sean_McG> hmmm how do I change the colours git uses? [21:33:02] <mru> with priority to ones with a highlight [21:37:10] <bilboed> Sean_McG, search for "color" in man git-config [21:37:45] <Sean_McG> ah... yeah Google was my friend too [21:50:31] * elenril summons somebody with commit powers [21:51:05] <mru> elenril: which patch? [21:51:27] <elenril> please revert c34461b35b68ff1f3d04540e0279383c51be8cee and apply the correct version [21:52:01] <elenril> the correct one is Message-ID 20110123200301.GA18725(a)zohar.khirnov.net [21:52:02] <mru> and which is that? [21:52:22] <mru> got a patchwork link? [21:52:40] <elenril> sec [21:52:54] <BBB> Re: [FFmpeg-devel] [PATCH 4/4] mov: simplify mov_read_chapters() by using avio_get_str16be [21:53:38] <BBB> hm, it's off patchwork already [21:53:44] <BBB> maybe it was marked as applied? [21:54:21] <elenril> yeah, seems so [21:55:25] <BBB> I can't find it in patchwork, I can find the wrong one and another one in that thread, but not this one [21:55:39] <mru> so like this? http://git.mansr.com/?p=ffmpeg;a=shortlog;h=master;hp=origin/master [21:56:57] <mru> or do just the total diff as a new commit? [21:57:14] <mru> it's easier to see what's going on that way [21:57:24] <elenril> i prefer the revert+reapply [21:57:40] <elenril> but whatever you think is cleaner [21:59:23] <mru> so what's in my 'master' branch now is correct? [21:59:34] <elenril> yes [21:59:40] <elenril> you could mention the reason for revert [21:59:52] <mru> I thought I did [22:00:03] <mru> you might need to reload for that [22:01:01] <elenril> yeah, looks fine [22:07:28] <CIA-38> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rc4f8765ac5 ffmpeg/libavformat/mov.c: [22:07:28] <CIA-38> ffmpeg: Revert "mov: simplify mov_read_chapters() by using avio_get_str16be" [22:07:28] <CIA-38> ffmpeg: This reverts commit c34461b35b68ff1f3d04540e0279383c51be8cee. [22:07:28] <CIA-38> ffmpeg: The wrong version of the patch was committed. [22:07:36] <CIA-38> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r225b6d7fde ffmpeg/libavformat/mov.c: [22:07:36] <CIA-38> ffmpeg: mov: simplify mov_read_chapters() by using avio_get_str16be [22:07:36] <CIA-38> ffmpeg: It probably also fixes a memleak or two. [22:07:36] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [22:12:53] <CIA-38> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rc6610a216e ffmpeg/ (186 files in 2 dirs): [22:12:53] <CIA-38> ffmpeg: Prefix all _demuxer, _muxer, _protocol from libavformat and libavdevice. [22:12:53] <CIA-38> ffmpeg: This also lists the objects from those two libraries as internal (by adding [22:12:53] <CIA-38> ffmpeg: the ff_ prefix) so that they can then be hidden via linker scripts. [22:19:12] <elenril> haha, ff_ffmeta [22:19:16] <elenril> how meta [22:19:29] <mru> how ff [22:19:49] <saintd3v> ff_ffmeta_meta [22:19:53] <Sean_McG> !! [22:20:18] <Dark_Shikari> ff_ff_ffffmeta_ffmeta_meta [22:20:21] <elenril> we should nominate this for some postmodernism award [22:20:30] <elenril> Dark_Shikari: fffffffffffffffu [22:21:25] <Flameeyes> mru: if we do set out to fix the bloody ABI, could we get an ABI bump for all the libs (minus avdevice, maybe filter?) before 0.7 release? [22:21:40] <mru> Flameeyes: I'm all for it [22:21:48] <mru> we'd get rid of piles of cruft in the process [22:22:18] <spaam> Dark_Shikari: yo dawg. i heard you like ff [22:22:37] <Flameeyes> oh crap.. I just updated the laptop for the past ten days.. and now a new chromium? :| [22:23:09] <elenril> shouldn't we wait for -mt? [22:23:26] <Sean_McG> definitely noticed that a lot of the software I've used in the past couple of years has updates *very often* [22:23:30] <spaam> elenril: that can be in *drums* 0.8 [22:26:05] <lu_zero> Flameeyes: now parsing tex as well html-next? [22:27:19] <Flameeyes> lu_zero: no clue... [22:29:09] <lu_zero> _av500_: send me again your pcap dump please [22:29:13] * lu_zero lost it [22:31:33] <mru> BBB: ping [22:31:42] <BBB> mru: pong [22:32:11] <mru> why do the vp8 bilinear mc functions take an argument they don't use? [22:32:45] <BBB> so the func prototype is identical to 6/4tap and we can use them interchangeably in the same calling code? [22:32:55] <mru> that makes sense [22:33:05] <mru> just making sure I'm not crazy [22:33:10] <BBB> you're not :) [22:33:35] <mru> and is the source guaranteed to have some horizontal padding? [22:33:48] <mru> for the horizontal variants [22:35:38] <BBB> not necessarily; this could be emu_edge or so where the source is quite literally just that exact block [22:35:48] <mru> that's annoying [22:35:54] <mru> can we please allocate some padding? [22:36:04] <mru> up to a multiple of 8 [22:36:14] <BBB> for emu_edge I believe there's always 16 bytes padding [22:36:39] <BBB> if you remind me I can add a if() for emu_edge so that it also copies into the temp buffer if there's no 16 pixels left on the bttomright [22:36:44] <BBB> I wouldn't mind [22:36:49] <BBB> emu_edge isn't that important anyway [22:36:56] <mru> the padding doesn't need to be initialised [22:37:02] <mru> just not fault on read [22:37:04] <BBB> right [22:37:24] <Sean_McG> I'd love to see someone test this on an IA64 :> [22:37:32] <mru> Sean_McG: http://fate.ffmpeg.org/ [22:37:34] <BBB> fate has ia64 [22:37:37] <BBB> oh [22:37:40] <Sean_McG> doh! [22:37:47] * Sean_McG didn't know that [22:38:09] <mru> why ia64 specifically? [22:38:27] <Sean_McG> because they seem to be the ugliest when it comes to unaligned reads [22:38:45] <mru> are they any worse than alpha or mips? [22:39:08] <Sean_McG> good question... I've neither owned nor used either [22:39:30] <mru> of the machines on fate, only x86, ppc, and armv7 support unaligned accesses [22:39:38] <roxfan> ia64 is worse than about anything [22:39:50] <mru> either it supports unaligned or it doesn't [22:39:56] <mru> there are no levels [22:40:04] <Sean_McG> fair point [22:40:08] <BBB> av_default_get_buffer() always adds 16 bytes extra buffer [22:40:18] <BBB> custom get_buffer implementations may not do that [22:40:19] <BBB> not sure [22:40:29] <mru> we should require that of them [22:40:41] <BBB> feel free to add it [22:40:46] <mru> doing two loads when one is enough is annoying [22:40:48] <BBB> I think in practice we already do require it [22:41:03] <mru> oh, there's lots of code that overreads a little [22:41:05] <Sean_McG> is anybody able to contribute to fate? I have a SPARC running Solaris 10... it's not fast though [22:41:32] <BBB> mru: exactly [22:42:09] <mru> we need more obscure systems on fate [22:42:19] <mru> if my octane weren't so noisy I'd put it on there [22:48:20] <saintd3v> we need a Cray on there [22:48:30] <Sean_McG> that would be neat [22:48:38] * mru doesn't have one [22:50:02] <kierank> http://ccore.sourceforge.net/ [22:50:27] * kierank wonders if n64 runs linux [22:50:58] <roxfan> it's a mips, so should be possible [22:51:27] <saintd3v> kierank: http://www.linux-mips.org/wiki/Nintendo_64 [22:51:31] <roxfan> at least uclinux [22:51:41] <mru> ffmpeg works on uclinux [22:51:47] <mru> for certain values of work [22:52:02] <roxfan> hmm 4MB of ram [22:52:12] <mru> not enough [22:52:24] <Sean_McG> "oh shit I'm hitting swap" [22:52:43] <mru> you can't have swap w/o mmu [22:53:10] <roxfan> you can use overlays \o/ [22:53:19] <roxfan> good old dos had them [22:53:39] <mru> and have fun swapping overlays if your mv points too far out [22:53:46] <roxfan> hehe [22:54:08] <roxfan> http://www.uclinux.org/pub/uCsimm/archive/0011.html says 1MB should be enough, but this was in 2K [22:55:53] <mru> 4M isn't enough for ffmpeg [22:56:03] <mru> at least not all of it [22:56:10] <mru> heck, the binary is bigger than that [22:56:42] <mru> on the blackfin I've set aside 32M for ffmpeg bss+heap, and that's not enough for some tests [22:59:48] <mmu> mru therefore you need me :p [23:00:21] <mru> mmu: are you offering to run fate on haiku? [23:03:41] <mmu> could be arranged [23:03:48] <mmu> don't have time to install it yet [23:04:27] <mru> if vmware fucking esxi didn't require a windows app to configure it, I'd set up some virtual machines [23:04:45] <mmu> virtualbox ? [23:04:50] <mmu> Haiku runs fine in vbox [23:05:06] <Sean_McG> yeah I dunno what vmware is smoking not having a Linux binary for the vmware console [23:05:11] <mru> I don't like virtualbox [23:05:28] <mru> Sean_McG: there's no mac version either, I take it? [23:05:43] <mru> there is an old macbook here, but no windows [23:06:42] <Sean_McG> mru: aye, for Mac, there's Fusion but that's a desktop product [23:06:47] * Sean_McG uses and likes Fusion [23:07:27] <mru> I'm talking about the vsphere console or whatever it's called [23:07:35] <Sean_McG> aye... I know what you mean [23:07:42] <Sean_McG> I use vsphere at work [23:08:07] <mru> there is the cli that runs on linux, but that only lets you make minor changes to existing vms [23:08:31] <Flameeyes> mru: don't virt-manager allow at least partial control of those? [23:08:36] <Sean_McG> vmrun would be more useful if it didn't require a plaintext password [23:08:47] <Sean_McG> which makes it annoying to script [23:08:50] <mru> Flameeyes: there's apparently no way whatsoever to create a new vm without the windows console [23:08:56] <Flameeyes> terrific [23:08:57] <Sean_McG> yup [23:12:20] <mru> Flameeyes: any idea why vmware workstation/server/player ebuilds pull in half of gnome and other nasties? [23:19:28] <{V}> I thought for vmware player one could use qemu-img to create a vmdk file and a text editor to copy-edit an existing vmx file to point to your new vmdk file. Are things different for the cli on linux? Or have things changed from the last time I played with vmware? [23:19:40] <Flameeyes> mru: they used to depend on esd and other crap like that [23:19:59] <kierank> mru: what's wrong with virtualbox [23:20:13] <mru> kierank: last time I tried to use it, it locked up my computer [23:20:15] <kierank> it's gotten very good lately [23:20:27] <mru> and was generally annoying to use [23:20:49] <Flameeyes> I agree with mru's dislike for vbox honestly [23:21:31] <mru> I like the way vmware hosted emulators are structured [23:21:36] <mru> it's clear what's what [23:21:41] <mru> and there's no hidden state [23:22:32] <mru> close the app and it's all gone [23:39:49] <Compn> mru : hows download page coming ? [23:40:12] <mru> you said 24h [23:47:29] <Compn> yes but that wasnt my question [23:47:42] <Compn> still have whatever hours left :P

1 0

IRC log for 2011-01-25
by irc＠mansr.com 26 Jan '11

26 Jan '11

[00:00:20] <mru> that's roughly the price I paid [00:00:46] <Flameeyes> hm, I actually found it at _one_ place at €200 (inc. VAT) here in Italy, how that's interesting, somebody with honest prices, in Italy? [00:01:05] <Flameeyes> almost all of my hardware purchases come from Germany [00:05:53] <jannau> mru: have queued any of Flameeyes' patches? [00:06:04] <mru> some, about to push [00:06:19] <mru> there [00:06:24] <jannau> ok, I haven't [00:06:27] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r53493f9a81 ffmpeg/libavcodec/ (atrac.c atrac.h): [00:06:27] <CIA-43> ffmpeg: Mark qmf_window table static to atrac.c unit. [00:06:27] <CIA-43> ffmpeg: The table is not used anywhere else on libavcodec. [00:06:27] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:06:36] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r3568853f63 ffmpeg/ (cmdutils.c cmdutils.h): [00:06:36] <CIA-43> ffmpeg: Make this_year static to cmdutils.c [00:06:36] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:06:38] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r82e1f217f2 ffmpeg/libavcodec/ (atrac.c atrac.h atrac1.c atrac3.c): [00:06:38] <CIA-43> ffmpeg: Rename sf_table in atrac.c unit to ff_atrac_sf_table. [00:06:38] <CIA-43> ffmpeg: This ensures a locally-unique name as well as marks the symbol as [00:06:38] <CIA-43> ffmpeg: FFmpeg-private at least by declaration. [00:06:38] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:06:39] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rbb875b75ba ffmpeg/libavcodec/utils.c: [00:06:39] <CIA-43> ffmpeg: Make the ff_lockmgr_cb function pointer static to utils.c [00:06:40] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:06:41] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r1d4da6a460 ffmpeg/libavcodec/ (mpegvideo_common.h mpegvideo_enc.c): [00:06:43] <CIA-43> ffmpeg: Make denoise_dct_c and dct_quantize_trellis_c static. [00:06:43] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:06:43] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rf0a8676958 ffmpeg/libavformat/ (dv.h dvenc.c): [00:06:43] <CIA-43> ffmpeg: Make dvenc.c functions static to the unit. [00:06:43] <CIA-43> ffmpeg: Also drop some CONFIG_DV_MUXER #ifdefs probably vestigial from before the [00:11:36] <lu_zero> BBB: so if I understood correctly in asf [00:12:05] <lu_zero> you never have more than one or fragments of asf packets [00:12:13] <lu_zero> per rtp packets [00:18:14] * Flameeyes is also taking a moment to cleanup his historical patches [00:26:30] <mru> Flameeyes: I can push the good parts of the DEBUG patch if you want [00:26:34] <mru> avidec needs more work [00:27:12] <Flameeyes> uhm define "more work", but okay for me to at least merge part of it [00:27:19] <mru> see mail [00:27:33] <Flameeyes> hasn't arrived here, so I'll see when it does :) [00:27:44] <Flameeyes> the dprintf changes I had laying around since ... july? [00:27:46] <CIA-43> ffmpeg: Diego Elio 'Flameeyes' Pettenò <flameeyes(a)gmail.com> master * r73a0b19ba3 ffmpeg/ (libavcodec/gifdec.c libavformat/mxf.h): [00:27:46] <CIA-43> ffmpeg: Don't check for DEBUG before using dprintf. [00:27:46] <CIA-43> ffmpeg: The dprintf macro is no-op when DEBUG is unset, so there is no need to [00:27:46] <CIA-43> ffmpeg: put it conditional to DEBUG. [00:27:46] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:29:11] <Flameeyes> see the original as re-imported here: http://gitorious.org/~flameeyes/ffmpeg/flameeyes-ffmpeg-historical/commit/c… — it was second in a row to remove dprintf() for the POSIX.1-2008 collision [00:36:16] <mru> BBB, wbs: libavformat/rtsp.c:1039:9: warning: 'rtx' may be used uninitialized in this function [00:36:19] <mru> that's a new warning [00:47:43] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r5b5083b5fe ffmpeg/libavcodec/pcm.c: [00:47:44] <CIA-43> ffmpeg: Don't declare a pcm_dvd encoder. [00:47:44] <CIA-43> ffmpeg: The PCM_DVD encoder would be left unused, as allcodecs.c properly declared [00:47:44] <CIA-43> ffmpeg: it as being decoder-only, but it would still be built into the object file. [00:47:44] <CIA-43> ffmpeg: Since there is no block of code to properly encode this PCM format, it's [00:47:44] <CIA-43> ffmpeg: not a full codec. [00:47:45] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:52:03] <Flameeyes> mru: you know anything of syncpoint search stuff? [00:53:10] <mru> nope [00:53:42] <lu_zero> mru: that line is a comment here [00:54:41] <lu_zero> make_setup_request anyway... [01:17:42] <Flameeyes> mru: uhm, are floating-point versions of functions always preferred? [01:17:58] <mru> elaborate [01:18:47] <Flameeyes> acelp has interpolate and interpolatef (floating point) functions [01:18:50] <Flameeyes> but only the latter is used [01:19:10] <mru> ask the voice codec guys what they were planning [01:19:19] <Flameeyes> another acelp source file has decode_gain_code, which is never used, and sipr16k.c has a float version of that [01:19:57] <Flameeyes> sipr16k also has an lp_decodef, while lp_decode (integer) is still used [01:20:32] <Flameeyes> is there any voice guy here who can enlighten me before I spent too much time on acelp? :) [01:21:19] <DonDiego> Flameeyes: try pinging reynaldo or superdump [01:21:33] <Flameeyes> DonDiego: will do! [01:22:37] <Flameeyes> reynaldo: can you help me figuring out the duplication of integer and floating point functions between acelp and sipr16k? tia! [01:22:44] <DonDiego> ok, i'm off to bed, gnite [01:23:43] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * raa61e39eac ffmpeg/libavcodec/mpegvideo_enc.c: [01:23:43] <CIA-43> ffmpeg: Make denoise_dct_c() and dct_quantize_trellis_c() static in definitions [01:23:43] <CIA-43> ffmpeg: 1d4da6a460d5b78026e3b854fdd6f469957a054c added static to the [01:23:43] <CIA-43> ffmpeg: prototypes for these fuctions. Adding it to the definitions [01:23:43] <CIA-43> ffmpeg: as well. [01:23:44] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:38:35] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r69ad22c7a7 ffmpeg/libavformat/rtpdec.c: [01:38:36] <CIA-43> ffmpeg: Make ff_realmedia_mp3_dynamic_handler static. [01:38:36] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:42:16] <Dark_Shikari> mru: oh wow, there was an overflow in 8x8 [01:42:33] <mru> lu_zero: that warning about rtx uninitialised is compiler mistake [01:42:48] <mru> classic case of init in first loop iteration, use in subsequent [01:43:03] <mru> compiler too stupid to notice [01:43:07] <mru> Dark_Shikari: apparently so, yes [01:44:04] <Dark_Shikari> wait, did you apply it? [01:44:08] <Dark_Shikari> if not, why is fate green? [01:44:13] <mru> I fixed it [01:44:15] <Dark_Shikari> k [01:44:26] <mru> with help from BBB [01:44:27] <Dark_Shikari> We need more really fun test cases like that. [01:45:24] <BBB> agreed [01:45:58] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r119cc033fc ffmpeg/libavformat/ (rtpdec.c rtpdec.h): [01:45:58] <CIA-43> ffmpeg: Make RTPFirstDynamicPayloadHandler static to rtpdec.c [01:45:58] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [01:46:18] <mru> Dark_Shikari: now I don't claim to understand how that asm works [01:47:55] <Dark_Shikari> it works much the same as the neon, really [01:48:03] <Dark_Shikari> though the init part (i.e. above the main loop) is imo a total mess [01:48:07] <mru> it doesn't look anything the same [01:48:13] <mru> main loop? [01:48:13] <Dark_Shikari> The core loop's logic is the same [01:48:19] <Dark_Shikari> i.e. the part that calculates the output pixels [01:48:27] <Dark_Shikari> the part that calculates i00/a/b/c is messy [01:48:50] <BBB> its fast :) [01:49:26] <mru> it's the part with the scalar registers I don't get [01:51:37] <Dark_Shikari> Yes, that's the init part [01:51:43] <Dark_Shikari> i.e. calculations of parameters for the simd part [01:52:42] <mru> I see a lot of simd there too [01:54:11] <Dark_Shikari> Some of the init can be done in simd [01:54:28] <Dark_Shikari> e.g. the top pixels are multiplied by 8, 7, 6, 5, 4... [01:54:34] <Dark_Shikari> you load them in simd, do a multiply [01:54:36] <Dark_Shikari> then you horizontal sum [01:54:47] <Dark_Shikari> the left pixels can't, because you have to load them one at a time [01:55:30] <mru> you can load them one at a time and then simd them [01:56:02] <BBB> pextrb is sse4 [01:56:07] <BBB> I may in the future write that also [01:56:15] <BBB> may be slightly faster... [01:56:16] <Dark_Shikari> you mean pinsrb [01:56:19] <mru> what does that do? [01:56:20] <Dark_Shikari> mru: not any faster [01:56:22] <Dark_Shikari> imo [01:56:24] <mru> element load? [01:56:25] <BBB> right [01:56:39] <Dark_Shikari> mru: so there are two ways to do it: [01:56:41] <BBB> load a byte from memory anywhere into the mm reigster [01:56:48] <Dark_Shikari> 1) 16x load, 16x mul, 16x add (48 ops) [01:56:58] <Dark_Shikari> 2) 16x load, 16x shuffle into place, 1 mul, a few horizontal adds [01:57:09] <Dark_Shikari> 2) is probably not significantly faster than 1) [01:57:17] <mru> neon is 16x load, 1 mul [01:57:25] <Dark_Shikari> and the horizontal adds of course. [01:57:28] <BBB> mru: the scalar is simple, if you do 4X[n1]+3x[n2]+...+-4x[n9], then I can lose a mul by doing (n0-n8)x4 [01:59:23] <Dark_Shikari> hey, it's michael! [01:59:39] <michaelni> hi jason [01:59:52] <michaelni> iam just here becazse i promissed arpi ;) [01:59:58] <michaelni> to logon today [02:00:11] <michaelni> well i should have 6 hours ago i guess [02:00:14] <Dark_Shikari> this is unheard of, we should throw a party [02:00:50] <michaelni> actually iam tired and have to go to bed soon :( [02:01:00] <michaelni> and ill meet ramiro tomorrow, he is in vienna [02:01:07] <Dark_Shikari> leave your irc on, then you won't miss anything. [02:01:15] * Dark_Shikari pokes BBB and mru etc [02:01:16] <michaelni> willdo [02:01:41] <BBB> feeding baby :-p but reading, hi michael [02:01:49] <michaelni> BBB, btw, iam sorry for mentining your name with that email [02:02:40] <michaelni> hi BBB, out of order msg & greeting ;) [02:02:45] <BBB> it's ok, the email is fine otherwise so i guess it makes no difference [02:03:29] <Flameeyes> hi michaelni [02:03:32] <BBB> assuming it is the one i think it is [02:03:39] <michaelni> hi Flameeyes [02:04:01] <michaelni> BBB i dunno, it looked ambigouse [02:04:08] <michaelni> but iam not a native [02:04:31] <Flameeyes> I think I'm done with the patchball for tonight ^^;; the interface should be slightly easier to deal with this way [02:04:33] <michaelni> a few paragraphs of new world propaganda and the offer for payment intermixed [02:04:40] <Dark_Shikari> By the way, michaelni, not sure if you know, but "iam" is two words =p [02:04:56] <michaelni> icnatspell [02:05:07] <Dark_Shikari> is spacing spelling? [02:05:17] <michaelni> who knows [02:07:34] <Flameeyes> uhm the _decoder and _encoder objects should never be accessed directly, right? [02:07:41] <mru> no [02:07:49] <mru> they should have ff_ [02:08:17] <michaelni> hi mru [02:08:30] <Flameeyes> mru: so let's say we change the macros to use ff_ prefix... adding a local: ff_*_encoder; ff_*_decoder; in the version script would be okay in that case? [02:08:45] <mru> Flameeyes: I suppose so [02:08:52] <mru> I don't know exactly how version scripts work [02:08:56] <mru> what takes precedence? [02:09:03] <mru> hi michaelni [02:09:12] <Flameeyes> mru: should be first-match-rules [02:09:17] <Flameeyes> but I'll doublecheck that now [02:18:44] <Kovensky> a michaelni :O [02:19:36] <Flameeyes> grrr there are three symbols that clashes with my idea of restricted mask =_= [02:20:10] <mru> which ones? [02:20:19] <Flameeyes> actually af few more [02:20:32] <Flameeyes> T ff_init_range_decoder [02:20:32] <Flameeyes> T ff_vp56_init_range_decoder [02:20:32] <Flameeyes> T ff_init_cabac_decoder [02:20:32] <Flameeyes> T ff_init_range_encoder [02:20:36] <Flameeyes> these four here [02:21:13] <mru> those should all be private too [02:21:39] <michaelni> Kovensky, hi, ive a lookup failure in my brian with your nick who are you ? :) [02:21:57] <Kovensky> just an observer :) [02:22:12] <michaelni> mosad? [02:22:25] <michaelni> or kgb? [02:22:38] <Flameeyes> mru: then I should be able to go with this as an experimental approach [02:22:41] <Kovensky> nah, neither [02:22:48] <Kovensky> they don't allow anime in their workplaces do they [02:23:50] * Kovensky made some mplayer builds for windows but stalled for almost a year on them and should resume building sometime soon [02:24:10] <lu_zero> hi [02:25:34] <Flameeyes> flame@yamato yamato % nm -D --defined-only /usr/lib/libavcodec.so | wc -l → 1519 [02:25:34] <Flameeyes> flame@yamato yamato % nm -D --defined-only libavcodec/libavcodec.so | wc -l → 1214 [02:25:34] <Flameeyes> not bad I'd say [02:26:46] <lu_zero> nice indeed [02:34:46] <lu_zero> good night michael, say hi to ramiro from me as well [02:34:49] * lu_zero heads to bed [02:35:06] <Dark_Shikari> michaelni: you can lurk #x264dev now too~ [02:35:57] * michaelni goes to kitchen eating a bit and then bed no more lurking [02:36:20] <michaelni> good night everyone [02:36:26] <BBB> goodnight [02:36:45] <Flameeyes> bye BBB [02:36:45] <BBB> baby is gone now [02:36:50] <BBB> no that was to michael [02:36:51] <Dark_Shikari> night michael [02:36:54] <BBB> I'm not sleepy yet [02:36:57] <Flameeyes> mru: ff_find_hwaccel is also internal, right? [02:36:59] <Dark_Shikari> it's like 3 AM there [02:37:21] <BBB> Dark_Shikari: mru is right that loading using pinsrb and then using pmullw might work for sse4 [02:37:27] <BBB> Dark_Shikari: I'll try that sometime next week or so [02:37:32] <Dark_Shikari> BBB: pinsrb, ugh [02:37:33] <BBB> even if it's only 5% faster, that's not bad [02:37:40] <Dark_Shikari> iirc, pinsrb is as slow as movd+punpck [02:37:44] <Flameeyes> Dark_Shikari: yeah and it's 3.30 here :P [02:37:45] <mru> BBB: I used that approach for neon [02:37:48] <BBB> haha, you said the same thing when I used it in vp8dsp [02:38:03] <BBB> Dark_Shikari: it was _slightly_ faster for a few uses, in others it made no difference [02:38:04] <mru> Flameeyes: where is it used? [02:38:08] <BBB> if it's faster, why not use it? :) [02:38:25] <Flameeyes> mru: mpeg12 h264 h263dec vc1dec [02:38:30] <Flameeyes> declared in internal.h [02:38:39] <mru> sounds pretty internal to me [02:39:11] <Flameeyes> good, then we can go down to fewer than 1200 symbols in libavcoded with relatively small changes [02:44:23] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r6081f8c4e2 ffmpeg/libavformat/avidec.c: [02:44:23] <CIA-43> ffmpeg: avidec: make print_tag() a macro and remove related ifdefs [02:44:23] <CIA-43> ffmpeg: The dprintf macro is a no-op if DEBUG is not defined, so there [02:44:23] <CIA-43> ffmpeg: is no need to guard it here. [02:44:23] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [02:45:11] <Flameeyes> fwiw http://paste.pocoo.org/show/326396/ these are the symbols not prefixed with av exported by libavcodec [02:45:53] <Flameeyes> I *think* we could start by hiding symbols that are internal to a given codec, so hide for instance ff_eac3_* [02:46:15] <mru> which non-av* symbols are used outside lavc? [02:46:22] <mru> that wasn't so many iirc [02:46:26] <mru> so let's fix those instead [02:47:10] <Flameeyes> well, it's a matter of renaming url_* and *_format, first of all [02:47:17] <mru> those are in lavf [02:47:18] <Flameeyes> and *_license [02:47:25] <Flameeyes> ah you mean for codec itself, hmm [02:48:07] <Flameeyes> the only user of ff_* functions from libavcodec is... libavformat [02:49:50] <mru> you posted a list a while ago [02:49:53] <mru> it looked rather short [02:50:08] <mru> this one: http://paste.pocoo.org/show/326089/ [02:50:24] <Flameeyes> yep [02:50:57] <Flameeyes> http://paste.pocoo.org/show/326402/ → this limits itself to libavformat's uses of libavcodec's ff_* functions [02:51:35] <mru> does it use anything that's neither av* nor ff_*? [02:51:47] <Flameeyes> i.e. elfgrep -DV -e '_.*@LIBAVCODEC' libavformat/libavformat.so [02:51:49] <Flameeyes> sec [02:53:14] <Flameeyes> nope [02:53:27] <Flameeyes> at least libavformat that is [02:56:07] <mru> hmm, that ff_toupper4 is funny [02:57:07] <mru> it's obviously only intended for ascii [02:58:01] <Flameeyes> also, http://paste.pocoo.org/show/326407/ these are all the non-prefixed interlib deps [02:59:21] <mru> it can be simplified to (x & ~((x & 0x40404040) >> 1)) [03:00:43] <mru> all letters have bit 0x40 set, and uppercase have bit 0x20 clear [03:01:43] <mru> the part that someone should have objected over is #include "libavcodec/internal.h" in libavformat/utils.c [03:02:02] <mru> err, I can't read [03:02:17] <mru> too many files with same name [03:02:38] <mru> actually, I can read [03:02:41] <mru> it is there [03:16:54] <Flameeyes> heh the .dynstr table for libavcodec is about 32K.. I killed 6K just by hiding those symbols before [05:14:08] <saintdev> nice article on groklaw about the GPL [05:22:24] <Dark_Shikari> BBB: YOU ARE INSANE [05:22:27] <Dark_Shikari> YOUR CODE IS NUTS [05:22:41] <BBB> I know :-p [05:22:44] <BBB> I'm sorry [05:22:53] <saintdev> lol [05:22:54] <BBB> I wasn't intending to apply as-is [05:24:12] <BBB> shall I have loren review it? [05:25:06] <BBB> we should put that on the quotes page [05:25:13] <BBB> that was awesome [05:26:08] <Dark_Shikari> you haven't been paying enough attention to my quotes =p [05:26:43] <BBB> this one was definitely quoteworthy [05:27:32] <Dark_Shikari> So yeah, I heard you like computed jumps now~ [05:29:42] <BBB> hehehe :) [05:29:58] <BBB> dude, it's amazingly fast now [05:30:10] <BBB> I was hoping to get close to 200 cycles, it's around 180 now [05:30:14] <BBB> that's insanely fast [05:30:53] <Dark_Shikari> It'd be faster if it only had to extend the edges [05:30:57] <Dark_Shikari> and didn't have to copy the other parts [05:31:05] <Dark_Shikari> i.e. if it wrote back to the main frame [05:31:12] <Dark_Shikari> (wouldn't work with emulated edge mc though) [05:31:58] <BBB> yeah, that doesn't work [05:32:19] <Dark_Shikari> It does work, it would be faster for the non-emulated-edge case. [05:32:22] <BBB> that'd be nice to try though [05:32:37] <BBB> I know it would work, I mean right now that's not how it works [05:33:20] <BBB> I may look into that in the future [05:33:29] <BBB> but want to do vp8 multithreading and ffmpeg-mt integration also [05:33:39] <BBB> xvp8 something something will soon start as well [05:33:47] <BBB> dude, I'm gonna be a vp8 junkie [05:34:25] <Dark_Shikari> lol [05:34:47] <Dark_Shikari> *sings* "I'm gonna bet my liiiiife on a shiiiiiiity coooodecccc...." [05:34:56] * saintdev sees BBB on the street corner searching for his next vp8 fix [05:34:57] <BBB> hehehe :) [05:35:22] <BBB> Dark_Shikari: at least it pays for my kids college education, then it's ok [05:37:20] <pross-au> what! is somebody whoring themself for vp8? [05:42:23] <BBB> oops, I'm caught [05:42:25] <BBB> anyway [05:42:27] <BBB> gotta sleep now [05:42:34] <BBB> Dark_Shikari: please review my patch online [05:42:49] <BBB> Dark_Shikari: other points: alignment to non-power-of-two-values (e.g. 48), is that ok? [05:42:58] <BBB> I think 48 would work [05:43:07] <BBB> it's a multiple of 16, should work [05:43:11] <saintdev> BBB: just stay away from the minneapolis airport men's bathroom... [05:43:35] <BBB> I shall remember that [05:44:16] <Dark_Shikari> BBB: no, each one is not guaranteed to be in a single cacheline then [05:44:41] <Dark_Shikari> ... then again ... the linker usually can't align to any more than 16. [05:44:56] <Dark_Shikari> so it probably doesn't matter. [05:45:17] <Dark_Shikari> and instruction prefetch likely happens ahead regardless [05:51:49] * elenril wakes up and sees 100 new mails [05:52:10] <elenril> and wtf, michael here? [05:52:30] <Dark_Shikari> Yeah, the world turned upside down [06:04:23] <thresh> moroning [06:07:34] <astrange> if there's any more commit emails i'll have to set up list->folder filters [06:08:09] <Dark_Shikari> you don't already have filters ? [06:09:20] <astrange> my approach of starting at the top and hitting space 500 times really fast works very well [06:23:17] <_av500_> yawn [06:25:08] <siretart> buna diminaca [07:53:11] <KotH> salut [07:53:51] <spaam> god morgon [07:54:55] <elenril> morning, glorious BofH [07:55:10] <spaam> awww [07:55:19] <spaam> KotH: he likes you [07:56:06] <KotH> moin elenril [07:56:24] <KotH> spaam: at least, he is not as perverted as you are [07:56:46] <spaam> im not [08:23:44] <bcoudu> elenril, btw it's very inefficient to always write utf16le with id3 v2.3 [08:24:01] <bcoudu> you'd better fallback on ascii when you can [08:32:48] <elenril> i guess [08:39:34] <cartman> moin [08:40:51] <kshishkov> grüß dich [08:41:10] <pJok> god morgon [08:41:16] <andoma> hej [08:44:39] <superdump> morning [08:46:59] <kshishkov> ska vi göra någonting med WMAL? [08:47:18] <kshishkov> eller WVP2? [08:47:59] <kshishkov> eller RALF? [08:50:22] <pross-au> roundup.ffmpeg.org down [08:53:43] <kshishkov> it's called rounddown for a reason, mate [08:54:19] <kshishkov> but no worries, I can check Bink-b decoder status directly from you [08:57:01] <pross-au> status: active [08:57:10] <kshishkov> yay! [08:57:45] <kshishkov> have you seen http://codecs.multimedia.cx/?p=306#comments ? [08:57:56] <pross-au> nup [08:58:01] <pross-au> one sec mate [08:58:36] <pross-au> Ta [09:00:17] <pross-au> Strewth!! [09:10:55] <bcoudu> elenril, also IMHO muxer should write 2.3 by default which is supported by more devices/oses [09:15:10] <KotH> boys, if i'd be looking for a person/movement detection system using a camera based system, what words should i use to google for algorithms? [09:15:32] <kshishkov> goldfish [09:15:47] <kshishkov> and motion estimation [09:16:00] <spaam> pross-au: will we see that decoder end of this week? :) [09:16:25] <av500> KotH: encode and check size of P frames [09:16:30] <peloverde> http://scholar.google.com/scholar?q=goldfish+motion+estimation [09:18:38] <av500> KotH: http://www.codeproject.com/KB/audio-video/Motion_Detection.aspx [09:20:51] <cartman> nice [09:22:20] <KotH> peloverde, av500: domo arigatou! [09:23:04] <kshishkov> KotH: I hope you don't ask how to encode video next time - it's FFmpeg channel after all [09:25:28] <av500> ...._SVF.mxf: could not open codecs [09:25:36] <av500> who is doing mxf? [09:25:43] <kshishkov> Tjoppen [09:25:46] <cartman> av500: bcoudu [09:26:43] <av500> nice how you agree :) [09:26:55] <av500> cartman: whats the code doing¿ [09:27:35] <KotH> kshishkov: no, i wont ;) [09:27:47] <bcoudu> well it's more about who is friend with who ... [09:28:49] <Tjoppen> av500: what codec? the demuxer only seems to support a limited set atm [09:29:00] <cartman> av500: resting [09:29:03] <av500> Tjoppen: I have no idea [09:29:15] <cartman> av500: re-encode as avi [09:29:46] <Tjoppen> try to get the codec UL [09:29:57] <elenril> bcoudu: i disagree, i think we should push for the 2.4 standard [09:30:13] <elenril> and only write the obsolete one when it's really required [09:30:28] <av500> Tjoppen: the avi says: [scale @ 0x8c16d80] w:1998 h:1080 fmt:bgr24 -> w:1998 h:1080 fmt:yuv420p flags:0x4 [09:30:41] <bcoudu> why do you want to create files that cannot be read on windows ? [09:30:45] <elenril> YES! [09:30:47] <elenril> :) [09:30:53] <bcoudu> this is stupid [09:30:57] <elenril> well "windows" [09:31:02] <elenril> most audio players can read them [09:31:22] <bcoudu> windows does not read them, and the user reported the issue for a reason [09:31:35] <av500> Tjoppen: ffprobe says this on the mxf: Stream #0.0: Video: [0][0][0][0] / 0x0000, 1998x1080, 24 fps, 24 tbr, 24 tbn, 24 tbc [09:31:36] <Tjoppen> av500: weren't you just using mxf? [09:31:44] <elenril> from what i heard, windows media player can read 2.4 [09:31:49] <av500> Tjoppen: I vcodec copied to avi [09:31:49] <Tjoppen> you're trying to remux rawvideo from avi to mxf? [09:31:50] <elenril> only windows explorer can't [09:31:56] <Tjoppen> ah [09:31:59] <av500> Tjoppen: I have a mxf [09:32:02] <av500> that does not play [09:32:07] <av500> i can play the audio mxf [09:32:10] <av500> but not the video one [09:32:21] <Tjoppen> do you have any idea what codec it's supposed to be? [09:32:33] <bcoudu> wikipidia disagrees [09:32:44] <bcoudu> not that wikipedia is a reliable source [09:33:33] <bcoudu> av500, -vcodec copy -f rawvideo, that should extract the essence [09:33:52] <lu_zero> uhm [09:34:25] <elenril> bcoudu: therefore i don't think we should push an obsolete standard just because _one_ _file browser_ (not player) can't read them [09:34:55] <bcoudu> you didn't understand me [09:35:01] <bcoudu> windows media player does not support it [09:35:05] <saintdev> i didn't know that av500 had the same syntax as ffmpeg [09:35:13] <elenril> it doesn't? [09:35:23] <elenril> i did in my tests [09:35:27] <bcoudu> wikipedia says win7 doesn't [09:35:33] <bcoudu> nor win media player [09:35:35] <elenril> (which admittedly i didn't do myself, but....) [09:35:48] <elenril> i wouldn't trust wikipedia on that matter [09:36:12] <av500> elenril: url to your test file? [09:36:18] <bcoudu> I wouldn't either but there is a reference in the article [09:36:48] <elenril> ftp://ftp.khirnov.net/in.mp3 id3v2.4 [09:36:53] <elenril> ftp://ftp.khirnov.net/out.mp3 id3v2.3 [09:37:20] * av500 waits for worlds slowest win7 tablet to boot [09:37:25] <elenril> ok, i'll do some more testing and think about it when i have more free time [09:38:36] <kshishkov> av500: you've made that one too? [09:38:52] <av500> kshishkov: not really [09:39:00] <av500> I did nothing for it :) [09:39:04] <GillesM> hi [09:41:10] <GillesM> I have a strange problem on h264 with h->cabac.bytestream > h->cabac.bytestream_end + 2 ... when I read a dvb stream but it If I do a cat /dev/dvb/adapter0/dvr0 > file ... i don't have any problem readin file .. idea ? [09:41:27] <kshishkov> av500: yes, I doubt you'd willingly work on that [09:41:36] <bcoudu> even id3.org mention that v2.3 is the most popular format [09:41:43] <bcoudu> ... [09:42:31] <elenril> so? [09:42:35] <elenril> avi is popular too [09:42:39] <bcoudu> id3 is the reference, dude [09:43:02] <elenril> that doesn't mean we should make it the default [09:43:22] <bcoudu> default should be the most popular one [09:43:44] <cartman> elenril: being compatible > being hip [09:43:54] <bcoudu> this applies to codec settings as well [09:44:02] <elenril> if that were true, new formats would never spread [09:44:12] <merbzt> we should write the most common one as default if it can contain all the "info" the is supplied [09:44:15] <cartman> elenril: they still encode pr0n with XVID [09:44:15] <cartman> :P [09:44:45] <bcoudu> not only porn but tv shows and movies [09:44:54] <elenril> which is completely braindead [09:44:59] <kshishkov> bcoudu: not in CHina [09:45:04] <cartman> which is compatible :) [09:45:24] <elenril> anyways, i'm not entirely convinced one broken player is a reason enough to switch, but i'll consider it [09:45:43] <elenril> anyone else has an opinion on this? [09:46:12] <av500> elenril: the 2.4 one is broken for the chinese tag [09:46:22] <elenril> :/ [09:46:28] <elenril> file a bugreport to m$ =p [09:46:32] <bcoudu> kshishkov, what about china ? scene releases are worldwide [09:47:13] <bcoudu> Tjoppen, the clip wrapping patch is messy, don't you have an op1b patch that is cleaner ? [09:47:16] <av500> elenril: I am for using the format that most players can understand [09:47:50] <bcoudu> I agree with av500 [09:48:21] * elenril doesn't like the idea of having to write -id3v2_version 4 every time he converts something [09:48:22] <GillesM> no idea about my h264 problem ? [09:48:55] <bcoudu> you don't have to, everything supports v2.3 ;) [09:48:57] <elenril> oh well, the majority is against me [09:49:12] <j0sh> does the destination for swscale have to be aligned? [09:49:17] <elenril> bcoudu: it's deprecated, obsolete and evil ;) [09:49:30] <av500> nonsense [09:49:36] <bcoudu> I agree v2.4 is superior because of utf8 [09:49:38] <elenril> (also we don't properly handle TDAT/TYER tags yet) [09:49:43] <kshishkov> j0sh: yes [09:50:07] <j0sh> hmmm alright [09:50:27] <bcoudu> but you can mitigate by using ascii instead of utf16le [09:50:29] <elenril> 2.4 is superiour because of other things too -- like a tag for full date [09:50:41] <bcoudu> well only mov supports full date [09:50:51] <elenril> ? [09:50:51] <bcoudu> asf/mp3 only supports year [09:51:04] <bcoudu> v2.3 I mean [09:51:06] <roxfan> i _think_ wmp/win7 might not like utf-8 (i.e. it wants utf-16), rather than just v2.4 [09:51:16] <bcoudu> and itunes only show year anyway ;) [09:51:25] <elenril> no, 2.3 supports full date too [09:51:30] <elenril> but it splits in 3 tags [09:51:35] <elenril> *splits it [09:51:45] <elenril> TYER/TDAT/TIME [09:51:52] <bcoudu> itunes write only year in TDRC here [09:52:02] <elenril> your itunes is broken then ;) [09:52:20] <roxfan> i.e. if you write v2.4 with utf-16 it should be able to read it [09:52:31] <bcoudu> it's just a shortcut, because nobody care about the day and the month [09:53:10] <elenril> that should be for the user to decide, not the format [09:53:20] <bcoudu> lol [09:53:21] <av500> but then I cant make a playlist with all music release april 1st.... [09:53:26] <av500> +d [09:53:35] <bcoudu> users don't care they want stuff to work [09:54:00] <elenril> users sometime care about the weirdest things [09:54:16] <av500> elenril: we put these on hold... [09:54:28] <bcoudu> certainly not day and month, otherwise itunes would display it [09:55:00] <elenril> itunes automatically does what each user wants? ;) [09:55:19] <elenril> most of the users certainly don't care [09:55:40] <elenril> but that doesn't mean everybody [09:56:04] <bcoudu> the point is to make the default the most popular but allow others to be able to do what they want [09:56:41] <elenril> oh well, ok, but the date tags must be fixed first [09:57:26] <av500> elenril: http://www.flickr.com/photos/av500/5387240974/ [09:57:43] * elenril kicks microsoft [09:57:59] <av500> microsoft shrugs [09:58:09] <superdump> hello michaelni [09:58:17] <elenril> i knew i shouldn't have touched the utf-16 support =p [09:59:09] <Dark_Shikari> michael should be awake by now [09:59:17] <kshishkov> av500: ahem, do you know his tastes or just guessing? [09:59:42] <saintdev> he's probably not paying attention, like loren [09:59:42] <kshishkov> Dark_Shikari: I doubt you know his timetable [09:59:48] <superdump> if anyone knows ogg, it seems some of reimar's ogg patches have sat for a few days without any motion on them [09:59:48] <Dark_Shikari> he went to sleep like 7 hours ago [10:00:09] <superdump> was there a party last night? [10:00:34] <cartman> whoa michaelni is here ;) [10:00:36] <bcoudu> I'm out, good night or good day [10:01:47] <lu_zero> roundup back online [10:02:07] <lu_zero> yesterday mess with networking upsetted nfs as well... [10:02:43] <kshishkov> /me is not surprised [10:16:12] <Kovensky> 06:54.29 bcoudu: certainly not day and month, otherwise itunes would display it <-- ofc users want it [10:16:15] <Kovensky> I for one want it =p [10:16:26] <Kovensky> I have to use the "sort album" tag to disambiguate albums released in the same year <_< [10:16:43] <av500> sort by what? [10:16:54] <Kovensky> sort by album artist + year [10:17:05] <av500> and how else would you sort? [10:17:10] <Kovensky> well, album artist + date [10:17:30] <Kovensky> I dunno [10:17:41] <Kovensky> the problem is that itunes does it as album artist + date + album title [10:18:11] <Kovensky> for example, asian kung-fu generation has 3 albums released in 2008; it falls back to sorting by album title and gets the order wrong [10:18:31] <av500> omg [10:19:01] <Dark_Shikari> Things get more fun when you have doujin albums. [10:19:04] <Dark_Shikari> where album artist == circle [10:19:08] <Dark_Shikari> and artist == composer [10:19:11] <Kovensky> Dark_Shikari: no, itunes supports that properly [10:19:15] <Dark_Shikari> and worse... [10:19:18] <Dark_Shikari> when artist == vocalist [10:19:19] <Dark_Shikari> not composer [10:19:23] <Kovensky> unlike every other player other than foobar2000 I've used ever [10:19:30] <Dark_Shikari> foobar <3 [10:19:39] <av500> http://www.thedoghousediaries.com/?p=2502 [10:19:55] <Kovensky> Dark_Shikari: it gets fun with alstroemeria records tho [10:20:03] <Kovensky> Dark_Shikari: which often released 2, 3 albums per comiket [10:20:20] <Dark_Shikari> <insert comment about how quantity != quality here> [10:20:39] <av500> Dark_Shikari: I did already :) [10:21:20] <superdump> and in general, if someone has time, since the change, we need to check that patches aren't falling into the void [10:22:13] <Kovensky> 06:56.06 bcoudu: the point is to make the default the most popular but allow others to be able to do what they want <-- it's lacking the latter part then, since the year field only allows 4 digits (what about the year 10000?!?!) and there are no fields where you can put a more detailed date [10:22:28] <Kovensky> I also had some files with ISO 8601 dates that itunes completely failed to read and had to get the year retagged [10:24:45] <Kovensky> itunes does prefer to sort by "release date" instead of "date", but it doesn't allow you to add / modify release date and it fetches that information from the itunes store according to internet folklore; it's also apparently not stored in tags, only in the database [10:24:56] <Dark_Shikari> and it doesn't look at vgdb [10:24:59] <Dark_Shikari> er, vgmdb [10:29:56] <elenril> Kovensky: there are no fields where you can put a more detailed date << read the specs plz [10:30:15] <elenril> i already said id3v2.3 has the extra fields [10:30:38] <elenril> the question is whether anyone supports them [10:31:26] <elenril> and while we're at it, lolitunes, get a real player =p [10:31:43] <kshishkov> elenril: buffering? [10:32:03] <Kovensky> 07:31.47 elenril: Kovensky: there are no fields where you can put a more detailed date << read the specs plz <-- I said in the user interface [10:33:06] <elenril> Kovensky: one more reason to get a real player [10:33:11] <elenril> kshishkov: note the space [10:33:28] <av500> http://www.real.com/realplayer/android [10:33:29] <Kovensky> http://puu.sh/N0L [10:33:42] <Kovensky> there are a few more options under Options but they're flags only [10:34:26] <benoit-> The future of multimedia... iTunes + wikipedia... Yay! [10:34:28] <elenril> looks stolen from amarok [10:38:30] <elenril> Kovensky: what does it say about ftp://ftp.khirnov.net/test.mp3 [10:38:33] <Kovensky> anyway elenril, find me a real player then; one that works under osx, properly supports the album artist and artist separation and supports full dates [10:38:36] <kshishkov> elenril: are you implying that absolute value of iTunes is bigger than its real part? [10:42:45] <elenril> Kovensky: mpd obviously [10:43:25] <Kovensky> elenril: now get me a client that doesn't look terrible, doesn't need x11.app to run and doesn't require me to code it myself [10:44:02] <j-b> Kovensky: Amarok ? [10:44:17] <elenril> mine should run anywhere where qt4 runs [10:44:20] <Kovensky> j-b: fails the first requirement =p [10:44:27] <thresh> amarok++ [10:44:33] <j-b> Kovensky: arf, :D [10:44:39] <Kovensky> it also doesn't have album artist / artist separation [10:48:43] <Kovensky> 07:38.31 elenril: Kovensky: what does it say about ftp://ftp.khirnov.net/test.mp3 <-- it reads the year (2006) [10:53:41] <av500> hexdump reads 15:30 [11:27:26] <elenril> Kovensky: what does itunes do with TDRC tags in id3v2.4? [11:27:35] <Kovensky> TDRC? [11:27:41] <elenril> release date [11:28:25] <elenril> it's a replacement for TYER i 2.4 [11:29:05] <Kovensky> well, itunes does have a column named "release date" that has an ISO-8601 date (but that's probably because I edited my short date format to ISO-8601), but it doesn't seem you can edit that [11:29:43] <av500> needs sjobs approval to edit that [11:32:23] <elenril> does qt4 run on apple btw? [11:32:29] <Kovensky> yes [11:32:37] <Kovensky> I heard the cocoa port is terrible though, but idk about 4.7 [11:35:11] * elenril wonders if pyside got usable yet [11:35:21] <lu_zero> elenril: which one? [11:35:49] <elenril> EAMBIGUOUSQUESTION [11:43:49] * kshishkov reads http://techcrunch.com/2011/01/25/google-to-acquire-fflick-for-10-million/ and wonders why we don't have trademarked FF- prefix yet [11:46:01] <spaam> Kovensky: do you use fflick everyday? [11:46:06] <BBB> shit, my ffmpeg-log is gone [11:46:07] <spaam> kshishkov.. [11:46:17] <BBB> Dark_Shikari: any comments on patch? my backlog is gone [11:46:44] <kshishkov> spaam: nope, I've seen that name for the first time and it was a bit familiar [11:46:53] <kshishkov> spaam: only two first letters though [11:47:40] <spaam> maybe google going to buy FFmpeg also [11:48:23] <Dark_Shikari> BBB: ? which comments, besides ITS CRAZY [11:48:39] <BBB> I was hoping you'd have suggestions on how to make it less CRAZY [11:49:01] <BBB> also, did I mention it's fast? :-p [11:49:13] * elenril would never sell his precious metadata to http://tvtropes.org/pmwiki/pmwiki.php/Main/PeaceAndLoveIncorporated [11:49:40] <kshishkov> BBB: no, it was just a bit faster than you'd expected [11:50:06] <kshishkov> elenril: do you think they won't pay you much for it? [11:50:51] <cartman> elenril: let me know if you use pyside, I wonder if its usable too :P [12:05:03] <lu_zero> Dark_Shikari, BBB: what's crazy and fast? [12:06:19] <av500> lu_zero: h264 asm code [12:06:39] <elenril> to are we faster than coreavc yet? [12:06:57] <kshishkov> elenril: don't forget to stab yourself [12:07:22] <cartman> elenril: never gonna happen [12:07:27] <elenril> kshishkov: i'll do someting worse [12:08:35] <elenril> i'll spend the rest of the day calculating scattering cross sections [12:09:01] <kshishkov> yay! [12:09:11] <elenril> how evil [12:09:22] <spaam> elenril: compile ffmpeg with -O1338 and --omg-optimized.. then ffmpeg will be FAST [12:09:22] <elenril> this is going to leave a deep scar on me [12:09:35] <elenril> you ean -O9001 [12:09:38] <elenril> *mean [12:12:28] <cartman> New Amazon SPAM™ service http://aws.amazon.com/ses/ [12:13:17] <Dark_Shikari> lu_zero: BBB's emulated edge [12:17:46] <lu_zero> nice =) [12:17:59] <kshishkov> cartman: well, at least it should be easy to block [12:32:25] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * re153e9a53a ffmpeg/libavcodec/latm_parser.c: [12:32:25] <CIA-43> ffmpeg: latm: remove superflous #includes [12:32:25] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:32:42] <av500> mru: ping [12:32:56] <mru> pong [12:47:53] <CIA-43> ffmpeg: Daniel Verkamp <daniel(a)drv.nu> master * r3adbe49f2b ffmpeg/Makefile: [12:47:53] <CIA-43> ffmpeg: Fix ALLPROGS_G so that *_g binaries get cleaned properly [12:47:53] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:07:46] <DonDiego> 101 commits :) [13:08:02] <mru> since? [13:08:17] <DonDiego> new tree [13:09:11] <kierank> mru: how come you haven't put yourself back in http://ffmpeg.org/consulting.html [13:09:36] <mru> kierank: I'm not going to [13:09:45] <mru> kierank: too much "spam" requests [13:09:50] <mru> indians writing iphone apps etc [13:10:00] <kierank> lol [13:10:04] <mru> the clients I want find me anyway [13:10:32] <kierank> what happened to nds using ffmpeg? [13:11:10] <mru> I've been answering weird questions for them [13:11:16] <mru> time to send them a bill soon I think [13:11:31] <kierank> the sky boxes have OSS in them now [13:11:36] <kierank> seems to be a weird shift [13:11:53] <mru> I know too much about those new sky boxes [13:12:24] <mru> that software is one of the reasons I left [13:12:33] <lu_zero> too ugly? [13:12:33] <mru> it's just too horrible to work on [13:12:42] <mru> overengineered [13:12:48] <mru> enterprise-in-a-box [13:12:57] <spaam> mru: why didnt you fix it? [13:13:02] <kierank> i've been sent a motorola box [13:13:29] <kierank> it is also enterprise in a box [13:13:57] <spaam> enterprise-in-a-box? [13:14:06] <kierank> prolly as much as the NDA says I can say too [13:14:23] * mru never cared much about NDAs [13:14:27] <kshishkov> spaam: because they prevented him removing at least four of five homebrew wrapper layers there [13:15:00] <mru> kshishkov: that was actually a different system [13:15:14] <spaam> kierank: ... ;P [13:15:14] <kshishkov> mru: but from the same company? [13:15:18] <mru> yes [13:15:22] <mru> the old system [13:15:36] <mru> kierank is talking about the new linux-based one [13:15:38] <kshishkov> so why can't you expect similar programming gems in newer one? [13:15:50] <mru> oh, it'll get there [13:16:02] <mru> it just hasn't had time to grow all the wrappers yet [13:17:26] * cartman hears collegaues talking about "openjpeg" dependency in "freetype" [13:17:29] <cartman> life is good [13:19:53] <lu_zero> mru make clean works for you? [13:20:59] <mru> lu_zero: it deletes stuff, if that's what you mean [13:22:13] <lu_zero> it doesn't delete ffmpeg_g and the rest for some reason [13:22:20] <mru> that's fixed [13:26:11] <lu_zero> nice =) [13:26:14] <lu_zero> uh [13:26:16] <lu_zero> interesting [13:26:21] <lu_zero> a platform with hardfp [13:26:30] <mru> ? [13:27:13] <merbzt> would be nice if we could create a ffmpeg version that can be compiled with hardfp [13:27:25] <mru> ffmpeg works fine with hardfp [13:27:26] <merbzt> if it has any benefits though [13:27:40] <mru> if you're talking about ARM [13:27:45] <merbzt> yes [13:28:04] <mru> I build it for hardfp all the time [13:28:07] <cartman> Tegra2? [13:28:17] <mru> and omap3/4 [13:28:24] <mru> I don't use the tegra much [13:28:40] <cartman> yeah tegra doesn't have neon lights =p [13:29:00] <mru> and is generally painful to deal with [13:29:14] <lu_zero> uhm [13:29:26] <mru> no documentation etc [13:29:36] <merbzt> so we don't use things that could be affected by hardfp ? [13:29:42] <lu_zero> the toolchain I'm playing with seems to be bogus in some regards [13:29:46] <mru> merbzt: we do, but it's all taken care of [13:30:21] <merbzt> have you banchmarked hardfp vs soft ? [13:30:30] <mru> not much difference in ffmpeg [13:30:40] <mru> we don't tend to pass floats between functions much [13:30:49] <merbzt> yeah thought so [13:31:17] <mru> but it's still a saner calling convention [13:32:05] <merbzt> yeah [13:33:19] <mru> jannau: ping [13:36:31] <kshishkov> BTW, are we ready for GSoC 2011? [13:36:50] <av500> kshishkov: I am ready to apply [13:37:33] <kshishkov> av500: for what project? [13:37:52] <cartman> bink-b [13:37:53] <cartman> :p [13:38:32] <av500> kshishkov: hmm [13:38:43] <av500> kshishkov: ffmpeg-wrapper maybe? [13:38:50] <av500> or codec plugins [13:38:56] <cartman> av500: OMX codec support in FFmpeg [13:39:15] <mru> then do an omx wrapper around ffmpeg [13:39:15] <kshishkov> yes, and make mru a mentor for that! [13:39:53] <mru> I'll probably mentor for beagleboard if they're accepted again [13:40:27] <elenril> i think we urgently need a shitty mp3 encoder [13:40:41] <kshishkov> that's easy [13:40:49] <kshishkov> wanna me write it? [13:40:52] <elenril> maybe i could try writing one [13:41:01] <elenril> kshishkov: you shoul fix aacenc [13:41:05] <mru> elenril: why do we need that? [13:41:05] * kshishkov has a shitty encoder in his portfolio already [13:41:09] <mru> lame is good enough [13:41:12] <elenril> mru: because we don't have one [13:41:14] <mru> and mp3 is dead [13:41:22] <kierank> elenril: could have a decent mp2 encoder ;) [13:41:22] <kshishkov> mru: to provide source for his IDv3 tags of course! [13:41:35] <kshishkov> kierank: to accompany x262? [13:41:40] <av500> kshishkov: for a wrapper project, I will mentor myself [13:41:46] <kierank> kshishkov: yeah [13:41:50] <elenril> av500: what wrapper? [13:42:08] <av500> elenril: wrap ffmpeg in itself [13:42:47] <kshishkov> elenril: OMX input for FFmpeg using FFmpeg interface to OMX so lavc can indirectly call lavc indefinitely [13:42:51] <av500> maybe we can wrap v2.4 tags as a binary blob in v2.3 ones too? [13:42:59] <elenril> sure [13:43:36] <kshishkov> elenril: does you metadata muxer support muxing v2.3 and v2.4 streams into single metadata? [13:43:45] <kierank> what about mp3pro decoder [13:43:52] <av500> that is even more dead [13:43:56] <kierank> exactly [13:43:59] * elenril stabs kshishkov [13:44:08] <av500> what are we, dead codecs society? [13:44:16] <elenril> av500: you didn't notice? [13:44:24] <kshishkov> kierank: it uses hacked SBR, sometimes very hacked [13:44:35] <av500> hmm, the strange smell, yes... [13:44:52] <kshishkov> av500: yes, we care for dead codecs, game codecs, obsolete and long-forgotten codecs and Bink-b [13:45:14] <CIA-43> ffmpeg: Georgi Chorbadzhiyski <gf(a)unixsol.org> master * r6e78c8ee94 ffmpeg/libavformat/mpegtsenc.c: (log message trimmed) [13:45:14] <CIA-43> ffmpeg: mpegtsenc: remove unused variables [13:45:14] <CIA-43> ffmpeg: Remove two variables that were not used and caused the following [13:45:14] <CIA-43> ffmpeg: warnings: [13:45:14] <CIA-43> ffmpeg: CC libavformat/mpegtsenc.o [13:45:14] <elenril> btw what happened to audio filters soc? [13:45:15] <CIA-43> ffmpeg: libavformat/mpegtsenc.c: In function 'mpegts_write_section': [13:45:16] <CIA-43> ffmpeg: libavformat/mpegtsenc.c:72:18: warning: unused variable 'ts' [13:45:22] <CIA-43> ffmpeg: Daniel Verkamp <daniel(a)drv.nu> master * r54fe299b88 ffmpeg/configure: [13:45:22] <CIA-43> ffmpeg: configure: move network tests before results are needed [13:45:22] <CIA-43> ffmpeg: This moves network_extralibs setup before use so that the link tests [13:45:22] <CIA-43> ffmpeg: for network functions work correctly. [13:45:22] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:45:24] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r3d157bf31f ffmpeg/Makefile: [13:45:24] <CIA-43> ffmpeg: Makefile: fix cleaning of tools in tests directory [13:45:24] <CIA-43> ffmpeg: The variable TESTPROGS is reset by the library makefiles, [13:45:25] <CIA-43> ffmpeg: use another name. [13:45:25] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:45:26] * av500 secretly plants bink-c info on teh intertubes... [13:45:36] <elenril> saste: ^? [13:46:06] * av500 goes to learn git [13:46:12] <av500> git co [13:46:21] <mru> mmit [13:46:36] <elenril> fatal: Not a git repository (or any parent up to mount parent ) [13:46:36] <jannau> mru: pong [13:46:40] <av500> is there a single git command that converts my svn checkout to git? [13:46:42] <kshishkov> av500: there are no known bink-a, bink-c, bink-d and bink-e instances IIRC. And bink-b existence is not acknowledged by its creators either [13:46:56] <mru> jannau: why does patchwork not always pick up commits? [13:47:56] <kshishkov> mru: commit titles mismatch with patches? [13:48:14] <mru> it that all it takes? [13:48:17] <wbs> av500: do you want to convert your ntfs partition to ext3 in-place, too? ;P [13:48:25] <av500> wbs: yes [13:48:34] <jannau> hash mismatches, should be only patch content [13:49:07] <av500> wbs: now that ff is git, I can finally commit my ff git into company svn :) [13:49:07] <mru> jannau: so if patches are committed out of order it won't work? [13:49:09] <kshishkov> av500: git init [13:49:33] * av500 does not fall for that trap [13:49:53] <av500> kshishkov: and then git add .svn? [13:49:58] <kshishkov> git trap --target=av500 [13:50:07] <kshishkov> av500: of course [13:50:07] <mru> av500: git init; git remote add origin git://git.ffmpeg.org/ffmpeg.git; git fetch; echo .svn >>.git/info/exclude [13:50:52] <mru> + git branch -fb master origin/master [13:51:01] <jannau> I've read that it has something to deal with mismatching offsets but it's not 100% relieable [13:51:23] <av500> my svn checkout is borken anyway since swscale went awol [13:52:45] <kshishkov> so just ditch it [13:53:00] <av500> it has many valuable printfs :) [13:53:18] <kshishkov> another reason to ditch it [13:53:24] * cartman hands av500 a svn diff [13:53:34] <av500> :) [13:54:02] <mru> with some adjustments to the commands above you can turn the tree into a working git clone [13:54:24] <mru> just change the branch command to point at the commit corresponding to the svn rev your checkout is at [13:54:47] <mru> then you can git commit the changes and pull --rebase [13:56:10] <mru> kshishkov: the fax decoder fails on blackfin [13:56:12] <mru> fix it! [13:56:25] <andoma> :) [13:57:00] <mru> and lavf-dv crashes with a segv [13:57:11] <mru> that's the test that uses a 100MB fifo [13:57:14] <kshishkov> mru: okay, just donate me a blackfin [13:57:25] <mru> and there's not that much memory available [13:57:30] <av500> andoma: fedex picked it up [13:57:47] <andoma> cool [13:58:01] <mru> av500: you're sending *it* somewhere? [13:58:09] <av500> yes [13:58:14] <cartman> mru: make dsort=date default on fate pls [13:58:31] <mru> cartman: I like it how it is [13:58:36] <mru> change your bookmarks [13:58:51] <cartman> mru: I don't use bookmarks, I type with my bear hands [13:59:14] <mru> cartman: http://www.fugly.com/media/IMAGES/Random/with-my-bear-hands.jpg [13:59:15] <DonDiego> mru: so, are you interested in the sun for fate or not? [13:59:28] <mru> DonDiego: I have neither space nor time for it [13:59:29] <cartman> mru: exactly that one [14:00:02] <mru> DonDiego: and we have some sparc tests on there already [14:00:05] <Flameeyes> DonDiego: do you really think I changed all those lines by hand? [14:00:28] <av500> Flameeyes: bear hands? [14:02:08] <DonDiego> Flameeyes: of course not - i did not mean to imply you should do the extra change by hand ;-p [14:02:32] <Flameeyes> I really would avoid using gnu indent :P [14:03:08] <DonDiego> Flameeyes: try uncrustify, works like a charm after you set it up properly and when it does not, the author reacts quickly... [14:03:22] <mru> DonDiego: let's just get this prefixing done first [14:03:23] <kshishkov> mru: bfin stderr for test gives "Cannot allocate 48018632 bytes output buffer". Can't you solder more memory there without my help? [14:03:26] <mru> we can worry about style later [14:03:26] <Flameeyes> DonDiego: will do! [14:03:58] <mru> kshishkov: ah, that explains it [14:04:11] <mru> I've allocated 32M for .bss+heap [14:04:15] <DonDiego> the patch is fine as-is, i think i OKed it unconditionally on the ml, but by all means somebody commit it... [14:04:34] <mru> I'd like the version script change separated [14:04:37] <mru> as I said [14:04:44] <mru> it's impossible to find in the noise [14:04:45] <DonDiego> git add -p? [14:04:57] <mru> just omit that file [14:06:12] <cartman> 1,10MB of 484,OO KB [14:06:18] <cartman> IE does it again :p [14:07:26] <cartman> this fucking firewall is fucked up [14:07:28] <cartman> URL: hakim.se/experiments/html5/sketch/ [14:07:29] <cartman> Category: Personal Relationships [14:07:45] <kierank> turkish firewall [14:08:12] <cartman> kierank: new work firewall :( [14:08:15] <kshishkov> kierank: programmed by Turks for Turks [14:08:20] <av500> every doner shop here has one of these [14:08:25] <av500> döner [14:08:33] <cartman> av500: go to döner.de [14:09:59] * kierank feels hungry after thinking about doner kebab [14:10:11] <cartman> kierank: döner in EU has the worst meat ever. [14:10:15] <cartman> don't eat that crap [14:10:18] <kierank> of course [14:10:31] <kierank> it's no secret [14:10:36] <mru> cartman: worse meat than in .tr? [14:10:37] <kierank> but when you're drunk it's like manna [14:10:38] <av500> cartman: its made of turkish kids, that is known... [14:10:44] <cartman> mru: its lamb meat here. [14:11:07] <mru> I wasn't primarily thinking about the species [14:11:17] <cartman> mru: better meat here, sorry :p [14:11:17] <av500> cartman: because I never see kids around the döner shops... [14:11:17] <mru> not the primary species at least [14:12:16] <cartman> av500: Don't you have a ministry of health? [14:12:47] <mru> cartman: no, they have a ministry of disease [14:12:49] <av500> these people vanish around döner places too [14:13:03] <mru> av500: and the rats, don't forget the rats [14:13:13] <av500> mru: rat döner is hard to find [14:14:42] <cartman> av500: your favourite [14:15:18] <kshishkov> av500: in .ru/.ua you can buy middle asian version with the best meat from stray cats or dogs [14:15:54] <DonDiego> ruggles: Subject: [FFmpeg-devel] [PATCH 07/11] Remove unused ff_ac3_parse_header_full function [14:16:03] <thresh> yeah, the meat that was myawing just 30 minutes ago [14:16:13] <DonDiego> Dark_Shikari: this reminds me that i wanted to ping you about a libx264 patch [14:16:31] <kshishkov> thresh: купи 5 беляшей и собери собачку [14:17:19] <elenril> take your vulgar topics out of this noble company =p [14:19:00] <kshishkov> av500: that's why I prefer eating in a country where they have proper deer, reindeer and elk meat [14:19:53] <av500> kshishkov: thats how they label cats and dogs? [14:20:06] <cartman> elk -> rat? [14:20:30] <mru> size discrepancy... [14:20:34] <kshishkov> av500: nope, there are plenty of real animals there [14:20:35] <andoma> is there a sign-extension helper somewhere in ffmpeg? [14:20:41] <andoma> get_bits(gb, 6) -> signed int [14:20:43] <av500> womp rats ftw [14:20:45] <mru> andoma: sign_extend() in mathops.h [14:20:48] <andoma> oh! [14:20:52] <mru> and get_sbits() [14:20:55] <andoma> ah [14:22:09] <kshishkov> cartman: in other places elks are known as mooses, not rats [14:22:25] <mru> andoma: now I want a linux spotify client in return [14:22:47] <kshishkov> mru: despotify.se [14:22:52] <andoma> thanks [14:23:04] <cartman> mru: there is one with Qt4 GUI :P [14:23:13] <av500> mru: there is one, it runs on the linux kernel :) [14:23:44] <andoma> your account needs to be premium or unlimited though [14:23:56] <cartman> yeah a vpn is cheaper \o/ [14:24:20] <mru> cartman: how does a vpn help connect to spotify? [14:24:36] <cartman> mru: Prerequisite 0 was using OSX :P [14:25:08] <kshishkov> mru: if you connect to andoma's work server via VPN... [14:26:37] <BBB> Dark_Shikari: I'm waiiiiiitiiiiiiing :-p [14:27:14] <kshishkov> BBB: go to mad house, show your patch at entrance, be admitted [14:27:26] <BBB> yes, that is true [14:27:26] <av500> DonDiego: lu_zero : you are booked at the St Nicolas too? [14:27:33] <BBB> but how do I make it better? come on guys [14:27:36] <BBB> it's not eternally doomed [14:28:02] <elenril> BBB: go review my patches while D_S is procrastinating ;) [14:28:13] <BBB> when I get in the office I will [14:28:51] <kshishkov> office? [14:29:03] <av500> the federal review office [14:29:20] <kshishkov> they have only internal review office [14:29:25] <kshishkov> aka IRS [14:29:47] <DonDiego> av500: not sure, lu_zero is taking care of the rooms, i'm just trawling along, but the whole crew in the same hotel would be great - how much do you pay per night? [14:29:55] <mru> hmrc ftw [14:30:11] <BBB> elenril: btw didn't we review and apply all your patches already? [14:30:13] <av500> hmso ftw [14:30:42] <elenril> no [14:30:51] <elenril> still two to review and 4 to apply [14:31:16] <kshishkov> write some interesting patches then [14:31:30] <kshishkov> (i.e. not related to metadata) [14:31:32] <elenril> some crazy ones like BBB does? [14:31:40] <kshishkov> why not? [14:31:46] <av500> find a middle ground [14:31:46] <BBB> why does everyone think it's crazy? [14:31:53] <av500> hearsay [14:31:54] <BBB> the patch is Fast[TM] [14:31:55] <elenril> BBB: people say it is [14:32:06] <kshishkov> BBB: because D_S said so and we trust his judgement [14:32:07] <BBB> elenril: people say lots of things [14:32:20] <BBB> the patch mechanism was his idea [14:32:29] <BBB> so if it's nuts, it's because he told me to do so :-p [14:33:01] * elenril scatters some µons on BBB [14:33:19] <kshishkov> elenril: he won't notice them anyway [14:33:27] <kierank> [14:29] mru: hmrc ftw --> erm [14:33:32] <kshishkov> elenril: try pi-mesons [14:33:47] <mru> kierank: sarcasm detector offline? [14:34:09] <mru> damn, I still need to make up some numbers for them... [14:34:10] <av500> DonDiego: it was to answer siretart asking on the ML [14:34:16] <av500> 54! [14:34:46] <kierank> mru: yes offline [14:39:10] * siretart turns up [14:40:30] <av500> siretart: a bunch of us is in the st nicolas, i dont remember if that includes lu_zero and DonDiego [14:40:41] <siretart> k [14:41:17] <siretart> A collegue here told me the hotel where the opensuse folks are staying [14:41:26] <siretart> but I'm still not totally decided if I will go [14:41:34] <cartman> siretart: those are good folks [14:41:36] <cartman> *ahem* [14:42:15] <av500> siretart: irc logs indicate they are there as well [14:43:41] <siretart> av500: according to my information, they are in radison blu [14:43:55] <av500> siretart: oh [14:45:21] <kshishkov> cartman: the guys who gave us ALSA are good? [14:45:59] <cartman> kshishkov: yes [14:48:14] <elenril> kshishkov: better than the guys who gave us pulseaudio [14:51:04] <kshishkov> elenril: well, SuSE guys created some other abominations as well [14:53:58] <j-b> elenril: you can't wait for systemd, I guess, then :D [14:54:24] <elenril> heh [14:54:49] <elenril> upstart is rather nice though [14:54:58] * mru prays to $all_deities that gentoo will remain a sane haven [14:55:35] * cartman expects Gentoo to switch to systemd too [14:55:54] <kshishkov> mru: it's been touched by Hand of BSD, so it's tainted :( [14:56:17] <Kovensky> 11:54.58 mru prays to $all_deities that gentoo will remain a sane haven <-- wrong sigil, should've been @all_deities [14:56:29] * Kovensky runs [14:56:39] <mru> Kovensky: good catch [14:56:47] <Kovensky> heh [14:57:03] <kshishkov> an associative array of deities? [14:57:33] <Kovensky> no, that'd be % and you can't put % directly on strings [14:58:19] <cartman> brb [14:58:27] * av500 thought $deity was a singleton? [14:59:28] <Kovensky> av500: but there is a $deity singleton for each monotheistic religion, so it's easier to use @all_deities which contain refs to each religion's deities as a flattened list [14:59:57] <mru> av500: java.faith.Deity.getInstance()? [15:00:36] <av500> deties.xml [15:07:13] <j-b> wbs: why do you care about win2000 ? [15:07:40] <mru> win2k is irrelevant [15:07:52] <wbs> j-b: well, it was discussed sometimes last year, people had varying opinions [15:07:52] <mru> but does it work on windows me, that is the question? [15:07:59] <wbs> lol [15:08:08] <j-b> wbs: well, last year, win2000 was still supported [15:08:12] <j-b> wbs: it isn't anymore [15:08:31] <kshishkov> mru: win3.11 + win32s is the base [15:08:38] <wbs> j-b: the effort for supporting it wasn't too bad, so we went that route instead of explicitly dropping support for something ;P [15:08:55] <j-b> "Support for Windows 2000 ended on July 13, 2010!" [15:10:54] <wbs> oh crap, didn't get that memo [15:11:12] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r362bfe2997 ffmpeg/libavcodec/ (ac3.c ac3.h): [15:11:12] <CIA-43> ffmpeg: Remove unused ac3_parametric_bit_allocation function. [15:11:12] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:11:15] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r6ed3b504f9 ffmpeg/libavcodec/ (ac3.c ac3tab.c): [15:11:15] <CIA-43> ffmpeg: Move ff_ac3_critical_band_size_tab in ac3.c for non-hardcoded tables. [15:11:15] <CIA-43> ffmpeg: This symbol is only ever used to calculate the non-hardcoded tables, so [15:11:15] <CIA-43> ffmpeg: only enable it in that case, and static to the source unit that uses it. [15:11:16] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:16:27] * elenril loves 2.1-line integrals [15:17:14] <mru> elenril: my rule of thumb in school was that if an expression got longer than one line, I'd made a mistake [15:17:21] <mru> worked pretty well [15:17:27] <elenril> no, qft is really that bad [15:19:22] <mru> said rule obviously only works in school, not in the real world [15:22:31] <kshishkov> probably it's reverse in solid bodies modelling - if it's shorter than two lines you've forgotten something [15:22:56] * cartman notes that Cardigans is one of the good things coming out of *.se [15:23:12] <mru> aren't they a bit 80s? [15:24:57] * av500 wears t-shirts only [15:25:04] <thresh> even in winters? [15:25:11] <microchip_> lu_zero: ping [15:25:56] <microchip_> alright, seems he's afk... anyone knows if ffserver can stream mp4/h264 ? [15:26:01] <av500> thresh: in winter I wear jack wolfskin or north face, if only I could decide [15:26:17] <thresh> they make t-shirts? [15:26:31] <av500> i guess they do :) [15:26:50] * cartman takes note :P [15:28:57] <mru> av500: not south butt? [15:29:08] <cartman> or Gore TeX [15:29:40] <av500> AlGoreTex [15:29:42] <kshishkov> mru: Abba is nice too. Jag älskar inlägd sill. [15:29:54] <cartman> Cardigans is 90s [15:30:15] <mru> still old [15:30:57] <mru> not that old is necessarily bad [15:31:14] <mru> they made some great rock in the 60s [15:31:15] <av500> 1890? [15:31:47] <cartman> better than current crap , *sniff* [15:33:14] <thresh> you don't like Justin Bieber?! [15:33:14] <kshishkov> mru: any opinion on Hagström guitars? [15:33:34] * mru does not play the guitar [15:33:45] <kshishkov> mru: http://sv.wikipedia.org/wiki/Hagstr%C3%B6m [15:33:45] <cartman> http://www.youtube.com/watch?v=s2UWxiLSA48 kicks Justin's butt [15:36:51] <cartman> KotH: http://www.rthaber.com/-haber-5668---.html [15:39:53] <KotH> rotfl [15:40:05] <av500> what is 4 and 5? [15:40:42] <DonDiego> i'm going home, cu guys [15:41:46] <cartman> av500: a guy called Temel asks the prime minister about corruption in 3 questions [15:42:06] <cartman> av500: his friend Dursun asks (after a break), why the break was 30 minutes earlier and where tf is Temel now [15:42:26] <av500> cartman: thx [15:44:05] <mru> lol @ google translate [15:44:20] <mru> 1-in power despite being worn out how we increased event.php? [15:44:28] <cartman> lol [15:44:52] <jannau> mru: 6ed3b504f9 breaks many compilers [15:45:05] <cartman> translates Temel as "Basic" [15:45:06] <cartman> heheh [15:45:22] <mru> ruggles: !!!!!!!!!!!!! [15:45:30] <mru> and Flameeyes [15:46:51] <mru> do you people not test your patches? [15:47:03] <kshishkov> cartman: it's very old joke, probably was popular in DDR too (and USSR of course) [15:47:27] <av500> mru: fate does that [15:48:52] <kshishkov> av500: it hasn't evolved yet to the stage when it can send letter back to ML with complaints "you commit broke my builds" [15:48:59] <mru> fix sent [15:49:00] <cartman> kshishkov: it was a good one :> [15:49:12] <thresh> kshishkov: actually buildbot can do that [15:49:22] <thresh> that isnt that cool yet though [15:49:23] <cartman> time to slack off [15:49:25] <cartman> see ya [15:50:06] <mru> would someone please ack the patch? [15:51:11] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r21c900129c ffmpeg/libavcodec/ac3tab.h: [15:51:11] <CIA-43> ffmpeg: ac3: remove ff_ac3_critical_band_size_tab[] external declaration [15:51:11] <CIA-43> ffmpeg: This fixes compilation broken by 6ed3b504f984dc6cefde8d57a57726f9d30e5033 [15:51:11] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:54:44] <Tjoppen> the inbox overfloweth [15:55:40] <av500> Tjoppen: wrt mxf, it supports a fixed list of codecs or something like fourcc based? [15:56:45] <kierank> av500: fourcc in your dreams [15:56:47] <kierank> guid more like [15:56:53] <mru> fixed list of guid [15:56:57] <kshishkov> Tjoppen: does that mean FFmpeg is in active development state again? [15:56:59] <kierank> and even with all that guid space there are still colissions [15:57:33] <BBB> indeed [15:57:36] <BBB> indeed [15:58:22] <kshishkov> kierank: why not? Especially since some GUIDs are not that random [15:59:04] <BBB> hrm [15:59:09] <BBB> my chat client is misbehaving [15:59:11] <BBB> anyway [15:59:25] <BBB> mru, jannau you are queueing patches OK'ed by us right? [15:59:30] <BBB> or should I use patchwork also now? [15:59:32] <kshishkov> BBB: check for babies around [15:59:41] <BBB> mine is at home, so not here [16:00:00] <av500> you left the baby at home alone [16:00:09] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r1e48cdaac3 ffmpeg/libavformat/tty.c: [16:00:09] <CIA-43> ffmpeg: tty: remove superflous #include <strings.h> [16:00:09] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:00:21] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * re781c4e6ff ffmpeg/libavutil/intfloat_readwrite.c: [16:00:21] <CIA-43> ffmpeg: intfloat_readwrite: include "mathematics.h" for fallback macros [16:00:21] <CIA-43> ffmpeg: This allows this file to build on systems lacking NAN or INFINITY [16:00:21] <CIA-43> ffmpeg: in math.h. [16:00:22] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:00:35] <mru> jannau: it would be nice if patchwork could somehow detect approved patches [16:01:23] <merbzt> and if they are not approved, somehow fix them so they can be [16:01:43] <kshishkov> av500: are you suggesting he should get few more babies? [16:01:48] <mru> merbzt: is the warning counter to your liking btw? [16:01:54] <mru> you were always asking for that [16:02:31] <jannau> BBB: I'm away from a computer with git, I'll catch up tonight, everything mru hasn't picked up [16:02:43] <jannau> mru: it's on my todo list [16:03:03] <mru> no rush [16:03:17] <merbzt> mru: simple and awesome [16:03:23] <mru> we've managed without it all this time, so I'm sure we can cope a little longer [16:03:47] <BBB> does patchwork apply patches? [16:03:51] <BBB> or do you do that yourself still? [16:04:04] <mru> it does not [16:04:49] <BBB> ok [16:04:52] <BBB> n/m then [16:04:53] <mru> nor would I want that [16:04:58] <BBB> hackable :-p [16:06:09] <BBB> is anyone merging patches from ffmpeg-cvslog/videolan-tree? [16:06:15] <BBB> e.g. the mov demuxer patch by baptiste? [16:07:04] <mru> they should be posted to the ml for review [16:07:42] <BBB> so nobody is working on that? [16:07:45] <BBB> I'll tree to do that... [16:07:50] <BBB> did you queue "Set reserved bits to 1 when writing PCR in mpegts packets"? [16:08:16] <lyakh> how does it happen, that some codecs (audio or video) have a "hot-spot" where they spend, say, more than 25% of the time calculating, whereas others have load approximately evenly spread over several functions? [16:08:22] <kshishkov> BBB: should I post your RM multistream patch for review? [16:08:25] <mru> sent [16:08:44] <BBB> kshishkov: sure, but it's hideous, people will think that all my code is suddenly poor [16:09:00] <mru> lyakh: the former have not been optimised properly [16:09:01] <kshishkov> lyakh: yep [16:09:09] <BBB> mru: I was thinking of "In mov muxer, mux adpcm_ms and adpcm_ima_wav the way quicktime supports it" [16:09:25] <kshishkov> BBB: so they'll know the truth [16:09:28] <BBB> lyakh: if there's functions that we spend a lot of time in and the codec is popular, we'll optimize that function. if we don't care, we don't optimize it :-p [16:09:32] <lyakh> aha, so, it's not some fundamental property of two codec-types... [16:09:32] <mru> BBB: yes, I sent that and the one after [16:09:39] <BBB> lyakh: indeed [16:09:43] <BBB> mru: ah I see, ok thanks [16:09:49] <lyakh> hm, ok, thanks... [16:10:09] <BBB> mru: will you queue the mpegts one? it seems you ok'ed it but you didn't queue / commit it yet [16:10:13] <BBB> lyakh: which codec is this? [16:10:23] <BBB> lyakh: if you ask nicely and someone has time, we might optimize it [16:10:39] <kshishkov> even on SH4 :) [16:10:41] * mru optimises codecs for $$$ [16:10:45] <mru> or make that $$$$ [16:10:53] <lyakh> mp3 has 53% in one fn, als 30%, vorbis 25%... [16:10:54] <BBB> peloverde: can you review some audio-patches? :-p [16:11:19] <BBB> I thought mp3 was pretty well-optimized? could just be that gcc inlines everything so it looks like it's one function [16:11:22] <BBB> not sure though [16:11:24] <av500> even after optimization a codec might spend more time in some functions... [16:11:28] <lyakh> I optimized mp3 (as you know;)) and als now too, but with sh4-asm... [16:11:29] <mru> BBB: mp3 isn't that well optimised actually [16:11:31] <BBB> audio is not important anyway, most decoding time is spent in video [16:11:35] * BBB runs [16:11:46] <mru> BBB: that's a flawed argument [16:11:51] <BBB> I know :-p [16:11:54] <BBB> that's why I ran :) [16:12:02] <mru> apparently you ran in a circle [16:12:10] * kshishkov gives Monkey's Audio to BBB [16:12:40] <mru> lyakh: once I get that sh4 stuff off av500 I can help optimise stuff [16:13:03] <lyakh> mru: thanks, for sh4 or for all? [16:13:24] <mru> I'll probably do some arm opts there too [16:13:30] <kshishkov> on sh4? [16:13:35] <mru> no, on arm [16:13:36] <av500> kshishkov: yes! [16:13:46] <mru> but some restructuring is common [16:14:04] <BBB> D_S didn't review my emu_edge patch beyond his "OMG ITS EVIL" :( [16:14:09] <mru> I expect to double the speed of the windowing function [16:14:42] <mru> BBB: I don't see your patch in patchwork [16:14:43] <lyakh> so, my idea is - to prepare what I've profiled, and what I've managed to optimize so far, post it to the list even if in some crude form - just for info, and maybe discuss that at FOSDEM? [16:15:18] <BBB> mru: I probably didn't send it git-formatted [16:15:26] <BBB> mru: how do I edit a patch in git after committing it? [16:15:37] <BBB> or, how do I make a branch out of my current origin/master+local commits? [16:15:39] <mru> do the edits and commit --amend [16:15:46] <mru> or use the gui [16:16:03] <BBB> and the branching? [16:16:11] <mru> lyakh: speaking of fosdem, there was some talk on the ml about people driving there [16:16:12] <BBB> I don't mind having to recommit it after creating the branch [16:16:29] <mru> lyakh: in case you want share a car with some others [16:16:51] <lyakh> mru: yes, seen that. that might be useful, it is still not clear, whether I'll be able to use mine;) [16:16:53] <av500> but on friday :) [16:17:00] <mru> BBB: have you tried gitk? [16:17:01] <av500> so you have to drink beer [16:17:06] <BBB> I use git gui [16:17:07] <lyakh> I'll see:) [16:17:09] <BBB> and GitX also [16:17:11] <mru> gitk is great [16:17:25] <jannau> BBB: if you want to have all commits in a branch in a single commit: git merge --squash [16:17:51] <av500> fatal: bad default revision 'HEAD' [16:17:54] <av500> ??? [16:18:11] <jannau> context? [16:18:26] <av500> git log [16:18:30] <av500> after git init [16:18:35] <av500> and add remote and fetch [16:18:58] <av500> git init; git remote add origin git://git.ffmpeg.org/ffmpeg.git; git fetch [16:19:32] <lyakh> decode_spectrum_and_dequant() - bloody hell... [16:19:42] <mru> aac? [16:20:26] <lyakh> yes... [16:20:30] <BBB> jannau: how do I switch branch [16:20:30] <BBB> ? [16:20:52] <mru> lyakh: you should've seen it before I optimised it [16:20:53] <jannau> git checkout $branch [16:21:03] <lyakh> up to 10 levels of indentation... [16:21:58] <Tjoppen> av500: it supports whichever codecs have been registered with SMPTE for use in MXF [16:22:42] <Tjoppen> each one gets a 128-bit UL, which is pretty much the MXF way of saying FOURCC [16:22:55] <av500> Tjoppen: ic thx [16:22:58] <mru> SIXTEENCC [16:23:09] <av500> but there is no av_log that shows it, no? [16:23:19] <Tjoppen> even more fun is that some codecs have specific variants registered [16:23:45] <av500> Tjoppen: I guess I will just upload the sample :) [16:23:59] <Tjoppen> like, PAL intra-only mpeg2 + more arbitrary settings might be registered as a "sub-codec" [16:24:15] <BBB> jannau: ah thanks [16:24:25] <BBB> jannau: so now when I git pull, does it update all branches or just my current one? [16:24:55] <Tjoppen> so if you only match say the first 112 bits that may be enough to say "oh, it's mpeg2" [16:24:58] <jannau> av500: still in your svn checkout? [16:25:22] <av500> jannau: no, fresh git [16:25:33] <av500> why does git diff show strange ESC codes [16:25:41] <av500> or why does my term not like them? [16:25:56] <jannau> ansi color codes? [16:26:05] <av500> prolly [16:26:19] <mru> av500: export LESS=-R [16:26:26] <mru> or add -R to whatever is already in $LESS [16:26:42] <av500> thx [16:26:47] <jannau> BBB: git pull only updates the current branch [16:27:13] <Tjoppen> bah, my ubuntu-virtualbox keeps hanging [16:27:20] <mru> av500: you probably already had it set, or git would've supplied its own less flags [16:27:27] <av500> mru: yes [16:27:31] <av500> -M -I [16:27:58] * av500 blames suse [16:34:01] <av500> mru: gitk is awesome, I love how I can got back to the 1st commit in 2000 :) [16:34:23] <BBB> jannau: how do I make it do all branches? [16:34:35] <BBB> ports doesn't have gitk :( [16:34:44] <mru> ditch the mac [16:34:45] <j-b> use tig [16:34:49] <j-b> way better [16:34:59] <j-b> and gitks runs on my mac [16:35:31] <mru> j-b: I actually like the guis [16:35:32] <BBB> also how do I tell it what to update against? [16:35:39] <BBB> git pull --rebase doesn't work b/c I'm in a branch [16:35:46] <BBB> but git pull --rebase origin/master doesn't work either [16:35:52] <BBB> what do I do? [16:35:59] <mru> for the same reason I don't like browsing the web with lynx [16:36:13] <BBB> j-b: gitks? is that the portname? [16:36:40] <j-b> git package IIRC [16:36:50] <BBB> hm [16:37:01] <BBB> oh indeed I have it already [16:37:03] <BBB> cute [16:37:12] <wbs> BBB: git checkout master, git pull, git checkout $branch, git rebase master, is what I usually do [16:38:01] <BBB> oh cute [16:38:04] <BBB> that works [16:38:06] <BBB> git is nice [16:38:16] <wbs> and if all commits were on master already, I can go back to master and do git branch -d $branch [16:38:33] <j-b> 17:37 <@BBB> cute [16:38:36] <BBB> I saw that in git gui [16:38:38] <j-b> BBB: no, one says Qt [16:38:39] <BBB> gitk also [16:38:51] <wbs> which will work if the branch doesn't have anything not on the current branch, but fail if there's still unmerged stuff [16:39:05] <wbs> (branch -D force-deletes branches) [16:39:11] <peloverde> BBB: after work [16:39:26] <jannau> BBB: that's because your branch tracks your master branch. 'git branch --set-upstream origin/master' in your branch should fix it [16:40:06] <BBB> gnome is trying to raise donors since 2 weeks now, they only have 29 so far... that's a rather sad figure [16:40:28] <mru> wbs: I've made a special command for that sequence: git assimilate [16:40:32] <BBB> somehow I feel that the linux desktops (as opposed to applications) as developer attractions are slowly dying... [16:41:08] <wbs> mru: ah, that would probably be handy [16:41:56] <mru> wait, that's not quite what my assimilate does [16:42:05] <wbs> BBB: I guess once you're at this point, getting to feel that you know what happens (more or less), at least visualized by GitX or similar, you're never ever going back to branchless coding again :-) [16:42:06] <mru> you can probably guess what it does [16:43:00] <mru> BBB: and that I think is a good thing (re gnome etc) [16:43:11] <mru> apps are what matter [16:43:16] <mru> the rest is just fluff and NIH [16:44:38] <BBB> mru: probably... I'm just surprised it took so long... kde same thing btw, massive way over-weight organization/lib, and a lot of it isn't very useful [16:44:53] <BBB> big succesful projects always exist outside the kde/gnome spheres [16:45:05] <BBB> succesful in "adoption beyond a few hundred geeks" [16:45:24] <BBB> e.g. firefox, thingyoffice, one or two of those mono apps, vlc [16:45:54] <peloverde> ewww firefox [16:46:04] <mru> sure, but that's not the point [16:46:21] <mru> it's wildly popular and not tied to any "desktop environment" [16:46:42] <mru> btw, wtf happened to gnome's own browsers? [16:47:36] <av500> gnome with the wind? [16:47:46] <BBB> I forgot what it's called [16:47:50] <siretart> mru: epiphany is still being ported to webkit [16:47:51] <BBB> but it was such an integration disaster [16:48:05] <mru> oh, is that what it's called now [16:48:11] <BBB> you'd think that at the very least, since gnome has this massive NIH "media framework", it'd play video - guess what IT DOES NOT [16:48:16] <elenril> konqueror was rather nice [16:48:19] <mru> is used to be galeon, then nautilus, or was it the other way around? [16:48:25] <BBB> all of the above [16:48:26] <mru> elenril: konqueror is/was kde [16:48:27] <siretart> before it was galeon, but then ephiphany was forked from it [16:48:28] <elenril> and amarok is pretty popular [16:48:34] <elenril> mru: i know [16:48:49] <mru> I think amarok is popular _despite_ being kde [16:48:50] <peloverde> galeon wasn't officially part of gnome and was partial inspiration for firefox [16:48:51] <siretart> nautilus is the file manager, not related with any web browsing at all [16:48:59] <peloverde> kcachegrind is pretty nice [16:50:03] <peloverde> I wish gnome were less tightly coupled to evolution [16:55:25] <BBB> oh, evolution [16:55:30] <BBB> waiting, waiting, waiting, waiting [16:55:33] <BBB> *crash* [16:55:36] <BBB> \o/ [16:56:11] <peloverde> sadly gnome seems to be the least-bad oss desktop [16:56:27] <mru> how about _no_ "desktop"? [16:56:42] <mru> has served me well for many years [16:57:35] <wbs> merbzt, cartman, av500 and other interested in android: http://android.git.kernel.org/?p=platform/development.git;a=commit;h=dfb912… finally merged - from the next release (or whenever that's part of a release), you should be able to build ffmpeg without hacking the ndk headers ;P [16:57:40] <peloverde> I like some of the functionality it provides [16:57:59] <av500> wbs: nice [16:58:07] <kierank> the most useful feature in gnome/gtk is the "favourite directories" thing on the left of file selection dialogs [16:58:18] <av500> yes [16:58:21] <mru> kierank: you get that with plain gtk [16:58:28] <av500> thats about what I use... [16:58:39] <wbs> I'm not sure wtf has happened with my wireshark for osx btw, the gtk file open dialogs sort files according to filename _length_, which is kinda annoying ;P [16:58:57] <mru> lol [16:59:20] * mru wants the gtk1 open dialog back [16:59:48] <peloverde> the calendar widget on the panel is nice, I need some sort of widget to keep track of my windows, the menu is kind of useful [17:00:58] <peloverde> plus gtk# apps pull in 500 years of deprecated gnome dependencies (at least on debian/ubuntu) [17:01:29] * mru knows where his windows are [17:02:47] <BBB> I want the mac open file dialog in gtk [17:02:50] <BBB> much better [17:03:20] <mru> I want a command line with tab completion [17:05:17] <peloverde> What I really want is the windows 7 task bar [17:05:41] <mru> task bars are nothing but theft of screen space [17:05:56] <mru> I _know_ what apps I'm running dammit [17:06:20] <Flameeyes> mru: pretty sure I did test it, where did it break? [17:06:32] <mru> Flameeyes: it didn't build [17:06:34] <mru> see fate [17:06:47] <mru> just click the arrow on any red box [17:06:55] <Flameeyes> will check fate, I guess it might be setup-dependent, as here it definitely didn't fail [17:07:02] <mru> they all broke [17:07:32] <mru> did you perhaps test only with hardcoded tables? [17:09:29] <Flameeyes> uhm, that's a good question, I could have forgotten migrating the other config :/ [17:10:18] <Snaggle> Compile (linking) failure question goes here or on #ffmpeg? [17:10:20] <Flameeyes> d'oh! indeed I only had yamato, not yamato-nohardcoded in the makefile :/ [17:10:43] <mru> Flameeyes: oh well, it was easily fixed [17:11:20] <Flameeyes> mru: thanks! I'll also make sure to restore the local build for that [17:15:38] <BBB> Snaggle: try #ffmpeg first please [17:16:51] <Snaggle> BBB: k [17:35:28] <CIA-43> ffmpeg: Jai Menon <jai(a)retroficial.org> master * rc0ae5152d1 ffmpeg/libavformat/ffmetaenc.c: [17:35:28] <CIA-43> ffmpeg: ffmetaenc: Use correct format specifiers. [17:35:28] <CIA-43> ffmpeg: Use printf format macros from inttypes.h. [17:35:28] <CIA-43> ffmpeg: Additionally, this fixes a warning when building with clang. [18:08:35] <BBB> hah, I finally have a mt branch [18:08:40] <BBB> let's start fixing issues [18:19:19] <Compn> btw does anyone remember who or why the wrappers for other codec libs were removed ? [18:19:38] <mru> examples? [18:19:58] <Compn> its been a while and my memory is dead [18:20:03] <Compn> maybe faad/faac ? [18:20:07] <mru> faad and vorbisdec were removed since we have better decoders ourselves [18:20:15] <mru> faac is still there [18:21:14] <Compn> guess there was never a libmpeg2 [18:22:35] <Compn> thought there were more [18:22:44] <BBB> libamrnb/wb [18:22:50] <BBB> we have decoders ourselves now [18:22:56] <BBB> we use opencore for amrnb encoding [18:23:17] <mru> we only wrap things where we aren't as good (yet) [18:23:17] <BBB> mru: when will you commit your work on vp8 neon/arm? [18:23:35] <mru> when it's finished, polished, and reviewd [18:23:37] <mru> +e [18:23:42] <BBB> hm [18:34:40] <Tjoppen> bcoudurier: I just got an mxf sample where DataDefinition seems to have bogus values. having codec_type rely on which type of Descriptor is used fixes it. does this seem like a reasonable approach? [18:38:41] <cbsrobot> hi - anybody knows why http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/thread.html is not updated anymore ... ? [18:42:51] <spaam> are you sure? [18:43:33] <spaam> i see a lot of emails from today in it [18:43:55] <jannau> yes, I have checked other lists too, last refreshed today 00:3x [18:44:47] <cbsrobot> http://news.gmane.org/gmane.comp.video.ffmpeg.devel seems ok [18:44:58] <spaam> mru KotH ? [18:45:08] <Dark_Shikari> BBB: what [18:45:27] <cbsrobot> on mplayerhq I see "Last message date: Tue Jan 25 02:29:44 CET 2011" [18:45:39] <BBB> Dark_Shikari: nothing, can you review my small change to vp8.c and then start reviewing my hellish emu_edge disaster and tell me how to fix it? :-p [18:45:44] <BBB> Dark_Shikari: I'm working on -mt now [18:46:40] <BBB> Dark_Shikari: I openly admit the asm is ugly, I could commit that separately and then start working on the asm as-we-go [18:46:46] <BBB> Dark_Shikari: makes review easier perhaps [18:48:53] <Dark_Shikari> BBB: done [18:51:13] <CIA-43> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r44002d8323 ffmpeg/libavcodec/vp8.c: [18:51:13] <CIA-43> ffmpeg: Don't do edge emulation unless the edge pixels will be used in MC. [18:51:13] <CIA-43> ffmpeg: Do not emulate larger edges than we will actually use for this round of [18:51:13] <CIA-43> ffmpeg: MC. Decoding goes from avg+SE 29.972+/-0.023sec to 29.856+/-0.023, i.e. [18:51:13] <CIA-43> ffmpeg: 0.12sec or ~0.4% faster. [18:51:40] <BBB> "this is fucking ugly" rofl [18:54:49] <Dark_Shikari> btw if you want you can apply the same patch to h264 [18:54:59] <Dark_Shikari> it should be trivial [18:55:54] * Dark_Shikari notices michaelni is still here (amazing!) [18:56:59] <spaam> Nice :D [18:57:28] <kierank> Dark_Shikari: and not behind a proxy or tor or anything ;) [18:58:35] <kierank> michaelni: are you going to join #x264dev [18:58:55] <BBB> Dark_Shikari: I can look at it, that's for luma only right? [18:59:07] <BBB> (that staged mc filter thing for h264 mc is scary) [19:00:32] <Dark_Shikari> Luma only, chroma is always bilinear and thus trivial [19:01:00] <Dark_Shikari> the staged MC filter is trivial, just calculate the hpel pixels you need, then take the MAX() of the pixels required for each [19:13:11] <BBB> Dark_Shikari: ok, I'll have a look at that, may not be today but on my list [19:13:22] <BBB> (the vp8 one was on my list since like forever, I just never did it, no idea why) [19:57:25] <pontscho> what a hell [19:57:45] <kierank> hell is other people [19:57:55] <pontscho> :) [19:58:24] <pontscho> o/ [19:58:59] <Sean_McG> hi folks... any idea what's up with roundup today? [19:59:24] <elenril> evil italian smugglers are stealing our routes [19:59:28] <elenril> OrSoIHeard [19:59:33] <Sean_McG> oh, weak [20:15:41] <spaam> kshishkov: mmmm cold trocadero [20:17:46] <bcoudurier> Tjoppen, is that file old ? [20:20:28] <andoma> spaam: mmm! [20:32:07] <BBB> astrange: there's some major (funny) bugs in your mt code, I'll see what I can do, which ones are you working on? from the patch you posted a week ago, any changes in your local git? should I work on your tree instead of using your patch? [20:32:27] <BBB> astrange: oh, and bug isn't "haha your code sucks" but rather "it produces funny images that aren't quite right" [20:32:29] <Tjoppen> bcoudurier: the mxf file? nope, made today with avid [20:33:38] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rd0f0f6287c ffmpeg/configure: [20:33:38] <CIA-43> ffmpeg: armcc: filter out non-gcc options from ASFLAGS [20:33:38] <CIA-43> ffmpeg: This allows passing armcc-specific flags with --extra-cflags without [20:33:38] <CIA-43> ffmpeg: choking the assembler. [20:33:38] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:33:47] <Tjoppen> it uses something that isn't even an smpte ul for its datadefinitions. I would have thought they were UIDs or something, but they're identical in both video and audio files [20:33:49] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r9d201b2606 ffmpeg/configure: [20:33:49] <CIA-43> ffmpeg: configure: add filter_out() function [20:33:49] <CIA-43> ffmpeg: This adds a function to filter out words matching a pattern [20:33:49] <CIA-43> ffmpeg: from a list. [20:33:49] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:34:33] <astrange> BBB: take the changes from my mainline_patches branch and apply them to git [20:34:44] <astrange> or you can use master of my repository, which should be the same [20:34:53] <astrange> but is still based on the last SVN rev [20:35:21] <astrange> the branch is the same as the patches i sent, it's just hard to find all those lost in the email [20:39:30] <Tjoppen> since the video descriptors all inherit GenericPictureEssenceDescriptor and similarly for audio I think it makes sense to set codec_type based on that [20:44:26] <spaam> http://mashable.com/2011/01/25/adaptive-bit-rate-video-streaming/ [20:46:55] <astrange> BBB: is this vp8 or an existing codec? [20:47:06] <spaam> its about HLS HTTP Live Streaming [20:47:51] <Sean_McG> Hot Lesbian Sex? [20:47:55] * Sean_McG ducks and runs [20:48:05] <CIA-43> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r93b78d1210 ffmpeg/libavformat/ (asfdec.c avio.h aviobuf.c): [20:48:06] <CIA-43> ffmpeg: lavf: make a variant of ff_get_str16_nolen public [20:48:06] <CIA-43> ffmpeg: It will be useful in mp3 demuxer and hopeful some other places. [20:48:06] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:07] <CIA-43> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r2934cd9dbf ffmpeg/libavformat/asfdec.c: [20:48:07] <CIA-43> ffmpeg: asfdec: remove some commented-out cruft [20:48:07] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:08] <CIA-43> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rc34461b35b ffmpeg/libavformat/mov.c: [20:48:08] <CIA-43> ffmpeg: mov: simplify mov_read_chapters() by using avio_get_str16be [20:48:08] <CIA-43> ffmpeg: It probably also fixes a memleak or two. [20:48:09] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:10] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r101e1f6ff9 ffmpeg/libavformat/ (audiointerleave.h utils.c): [20:48:10] <CIA-43> ffmpeg: Make ff_interleave_compare_dts static to utils.c. [20:48:10] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:15] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r8529731961 ffmpeg/libavcodec/ (h264.c h264.h): [20:48:15] <CIA-43> ffmpeg: Make ff_h264_decode_rbsp_trailing static to h264.c [20:48:15] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:18] <mru> here comes the flood [20:48:27] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * ra3dffc0627 ffmpeg/libavformat/ (mxf.c mxf.h): [20:48:27] <CIA-43> ffmpeg: Make ff_mxf_pixel_layouts static to mxf.c. [20:48:27] <CIA-43> ffmpeg: Also make it an anonymous structure as never it is accessed by name. [20:48:27] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:30] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rd625a32d6b ffmpeg/libavcodec/rdft.c: [20:48:30] <CIA-43> ffmpeg: Make ff_sin_tabs constant to rdft.c [20:48:30] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:34] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rf2e246f576 ffmpeg/libavcodec/ (png.c png.h): [20:48:34] <CIA-43> ffmpeg: Make ff_png_pass_xmin and ff_png_pass_xshift static to png.c. [20:48:34] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:34] <Sean_McG> whoa commitstorm [20:48:38] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rebb06d96ed ffmpeg/libavcodec/ (dwt.c dwt.h): [20:48:38] <CIA-43> ffmpeg: Make ff_spatial_idwt_{init, slice} static to dwt.c [20:48:38] <CIA-43> ffmpeg: Both functions seem to be commanded by the ff_spatial_idwt function [20:48:38] <CIA-43> ffmpeg: instead. [20:48:38] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:48:39] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r676f1f533e ffmpeg/libavcodec/ (ac3_parser.c ac3_parser.h): [20:48:39] <CIA-43> ffmpeg: Remove unused ff_ac3_parse_header_full function. [20:48:39] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [20:50:45] <Sean_McG> hmmm what's the difference between CODEC_ID_H264 and CODEC_ID_MPEG4, especially given that so many of the ASP variants have CODEC_IDs of their own? [20:51:05] * Sean_McG is working on roundup #2386 [20:51:06] <mru> CODEC_ID_MPEG4 is MPEG4 part 2 [20:51:13] <mru> CODEC_ID_H264 is MPEG4 part 10 [20:51:18] <mru> totally different codecs [20:51:27] <jannau> and http://patches.ffmpeg.org/project/FFmpeg-devel/list/ is still long [20:51:34] <mru> divx, xvid etc are also CODEC_ID_MPEG4 [20:51:39] <Sean_McG> ah...hrm. [20:51:44] <mru> only the MS variants have their own IDs [20:51:51] <mru> since they are not compatible with the standard [20:55:30] <bcoudurier> Tjoppen, omg avid files... [20:56:58] <Flameeyes> jannau: thanks for taking care of those [20:57:40] <Tjoppen> indeed. I managed to get both audio and video files to play though [20:57:58] <lu_zero> siretart: ping [20:57:58] <Tjoppen> using a bit of that clip wrapping stuff on the ML [20:58:14] <bcoudurier> well yes [20:58:52] <astrange> HEVC 1.0 posted. wonder if 1.0 means anything [21:04:27] <spaam> astrange: link? [21:04:55] <astrange> http://www.h265.net/2011/01/hevc-test-model-hm-reference-software-1-0-relea… which doesn't seem to load [21:05:08] <astrange> https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/tags/HM-1.0/ [21:06:03] <_av500_> hevc is h265? [21:06:12] <kierank> yes [21:06:29] <_av500_> as in they decided on that? [21:06:36] <kierank> yes [21:06:53] <Dark_Shikari> It takes only 35 seconds per frame to encode SD on a core i7! [21:06:54] <_av500_> i was not asked [21:06:56] <Dark_Shikari> On fast mode. [21:06:58] <Dark_Shikari> Amazing! [21:07:10] <Sean_McG> o_O; [21:07:21] <spaam> kierank: will we get avseq before hevc? [21:07:52] <kierank> spaam: avseq needs its own itu working group [21:08:17] <_av500_> Dark_Shikari: at that speed generating random bitstream and checking the decoded result might be faster... [21:08:56] <spaam> kierank =/ [21:12:23] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * rcf1d794a49 ffmpeg/libavcodec/ (ass.c ass.h): [21:12:23] <CIA-43> ffmpeg: Make ff_ass_subtitle_header static to ass.c [21:12:23] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:12:26] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r13eb6b9097 ffmpeg/libavcodec/ (h264.c h264_parser.c h264_parser.h): [21:12:26] <CIA-43> ffmpeg: Make ff_h264_find_frame_end static to h264.c; delete h264_parser.h [21:12:26] <CIA-43> ffmpeg: The header is empty after making the function static, so delete it and [21:12:26] <CIA-43> ffmpeg: drop its usage. [21:12:27] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:12:28] <bcoudurier> avseq ? [21:12:30] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r1a88674862 ffmpeg/libavcodec/ (ra144.c ra144.h): [21:12:30] <CIA-43> ffmpeg: Make ff_add_wav static to ra144.c [21:12:30] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:12:40] <CIA-43> ffmpeg: Diego Elio Pettenò <flameeyes(a)gmail.com> master * r57c4d01ec9 ffmpeg/libavformat/ (rtsp.c rtsp.h): [21:12:40] <CIA-43> ffmpeg: Make ff_rtsp_send_cmd_with_content_async static to rtsp.c. [21:12:40] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:13:05] <spaam> bcoudurier: AVSequencer [21:13:27] <_av500_> famous gsoc project [21:14:05] <kierank> so famous i'm suprised google didn't sponsor its completion [21:14:23] <_av500_> kierank: im in talks with sergey about that [21:14:43] <kierank> good to know [21:14:49] <kierank> have ballmer as a backup just in case [21:15:15] <spaam> yeah. [21:15:30] <_av500_> i have a chair if needed [21:15:54] <Sean_McG> so codec_tag of H.264 content is only 'mp4v' if it's been authored by QuickTime? [21:15:56] <spaam> then we all can join cdgs with basty [21:16:10] <kierank> _av500_: lol'd [21:18:06] <siretart> lu_zero: sorry, still in a phone conference [21:18:20] <lu_zero> np [21:20:48] <relaxed> lu_zero: On roundup I'm seeing, "content file for /var/db/roundup/ffmpeg/db/files/msg13546 not found" on https://roundup.ffmpeg.org/issue2570. Is this a temporary issue? [21:21:23] <Sean_McG> me too [21:21:48] <in3xes> Can someone tell about AVStream? [21:22:14] <in3xes> like, what is that for, how it should be used... [21:23:58] <in3xes> Or, its such a easy thing that I should be able to figure out myself ? [21:24:48] <lu_zero> relaxed: let me have a look at it [21:26:11] * in3xes dives again into doxygen pages. [21:30:12] <Flameeyes> buaahhahahhaha the one switch I found last night that seemed to have had a decent price in italy... was the wrong one [21:30:29] <BBB> astrange: h264 test suite [21:30:43] <Flameeyes> it was the non-managed one that it's at £120 (at €200 in italy) [21:30:43] <BBB> astrange: I'm running make fate-h264 and fixing problems 1-by-1 [21:30:56] <BBB> (or, well, planning to; I haven't fixed anything yet) [21:31:05] <kierank> BBB <3 [21:31:14] <kierank> oh <3 was pre-emptive [21:32:57] <astrange> BBB: i agree that there are unexpected bugs in that [21:34:06] <astrange> i stopped early because i couldn't figure out how to get the actual ffmpeg command for a fate test [21:34:36] <mru> V=1 [21:34:49] <j-b> 'morning [21:35:01] <mru> evening' [21:35:28] <astrange> http://gitorious.org/~astrange/ffmpeg/ffmpeg-mt/blobs/cd71fb4386961bc860c3a… [21:45:25] <BBB> astrange: V=1 yeah [21:45:28] <BBB> I'm working on it too [21:48:05] <astrange> in the repo do 'git diff master mainline/master libavcodec/h264*' and you'll get a large diff that reverts all changes to it [21:48:22] <astrange> binary search (apply the whole thing, revert and apply the first half, etc.) should find regressions [21:49:31] <siretart> lu_zero: okay, what's up? [21:50:50] <Sean_McG> astrange: git bisect should help with that [21:52:13] <astrange> bisect only travels across history and there are both mainline and mt breakages across history, so i think it's a bit confusing [21:52:24] <astrange> but bisecting now vs. 2007 on one sample might work [21:55:47] <siretart> lu_zero: please e-mail [22:01:25] <lu_zero> siretart: I sent one few hours ago [22:02:21] <siretart> oh, about fosdem? [22:02:28] <lu_zero> yup [22:02:35] <lu_zero> we are going short on rooms ^^; [22:02:53] <siretart> aah, right. so did you already book the room? [22:03:01] <lu_zero> nope [22:03:12] <siretart> ok, now I understand the email [22:03:13] <mru> where are you staying? [22:03:17] <lu_zero> I wrote in the email that was about and wanted to heard from you. [22:03:30] <lu_zero> mru: your hotel IF we don't lose the last triple ^^; [22:05:35] <siretart> lu_zero: I still have to figure out how to get to fosdem. either I drive with stefan again, or I take the train [22:05:53] <_av500_> siretart: there is a fftrain via aachen [22:06:25] <siretart> _av500_: does it start in southern germany? [22:06:42] <_av500_> siretart: no idea [22:06:53] <_av500_> but one can switch trains :) [22:07:42] <thresh> speaking of which, you guys all chose that st nicolas hotel? [22:07:51] <siretart> lu_zero: so you basically need to know if I'm attending and I'm up to share a room, and this today, right? [22:08:08] <lu_zero> mostly [22:08:35] <siretart> hm. I'd really prefer to defer that for tomorrow, I have a student that considers joining, but is also undecided, and I have to check with stefan if he has room in his car [22:08:49] <lu_zero> or I can pick the triple and stuff a random third once is available [22:09:01] <_av500_> siretart: 6h from erlangen [22:09:12] <_av500_> and you switch into the fftrain too :) [22:09:21] <siretart> av500: what is fftrain? [22:09:34] <_av500_> the ice14 that leaves aachen at 16:20 [22:09:39] <_av500_> with jannau and me [22:09:45] <jannau> ice passing achen friday at 16:20 [22:10:21] <_av500_> siretart: from erlangen its 2x train change, so DB lottery... :( [22:10:41] <_av500_> hopefully the weather is not extremely mild [22:11:10] <siretart> there seems to be a connection 11:19 Er / 12:00 Nue -> 17:27 Bruessel [22:11:30] <siretart> with some luck, that could be the fftrain [22:11:45] <_av500_> thats the one [22:11:51] <_av500_> midi as 17:35 [22:11:53] <Dark_Shikari> ok guys, I need adjective suggestions [22:12:01] <_av500_> awesome [22:12:07] <siretart> hm. sounds like another reason to take the train [22:12:08] <Dark_Shikari> our rule is, every time we send out an x264 dev newsletter, we add two words (usually adjectives) to the following paragraph: [22:12:12] <Dark_Shikari> Work is planned to integrate x264 with the Sandy Bridge's encoding [22:12:14] <Dark_Shikari> ASIC for improved encoding performance. Current status is: waiting on [22:12:17] <Dark_Shikari> Intel (these guys move at the speed of a paraplegic three-toed sloth swimming [22:12:20] <Dark_Shikari> down a frozen river of bricks while chained to an osmium anchor). [22:12:21] <mru> gcc is hilarious [22:12:23] <Dark_Shikari> Need suggestions on ones to add. I've covered all the obvious bases so far. [22:12:37] <Sean_McG> mru: hm? [22:12:45] <mru> in a trivial function, it pushes a register to stack, puts a value in it, does nothing, and pops it back [22:12:54] <Sean_McG> oh, heheh [22:12:57] <_av500_> mru: it was cleaning it [22:12:58] <jannau> Dark_Shikari: add "at 0 degree kelvin" [22:13:02] <lu_zero> Dark_Shikari: the wind [22:13:13] <siretart> lu_zero: so you're booking the triple room and have no roommate yet? is that correct? [22:13:18] <lu_zero> add the wind direction [22:13:22] <Sean_McG> D_S: so commitstorm today? [22:13:25] <Dark_Shikari> Sean_McG: yes [22:13:28] <Sean_McG> k [22:13:30] <Dark_Shikari> "a river of bricks frozen in solid hydrogen"? [22:13:50] <mru> s/hydrogen/helium/ [22:13:56] <lu_zero> siretart: I was about to book the double (there are still some left) [22:13:58] <Dark_Shikari> ... helium doesn't freeze [22:14:03] <mru> that's the point [22:14:04] <_av500_> chromium? [22:14:08] <lu_zero> and there is a single triple [22:14:41] <Dark_Shikari> Current status is: waiting on [22:14:41] <Dark_Shikari> Intel (these guys move at the speed of a paraplegic three-toed sloth swimming [22:14:44] <spaam> Dark_Shikari: at 0 K it will.. [22:14:44] <Dark_Shikari> down a river of bricks covered in frozen helium while chained to an osmium anchor). [22:14:44] <siretart> lu_zero: I'm pretty sure that I'm coming, and I'd be happy to stay with you [22:14:47] <Dark_Shikari> spaam: nope [22:14:49] * mru goes to write that function in asm instead [22:14:52] <lu_zero> ok then it's set [22:14:54] <siretart> ah, damn it, I wil somehow make it to brussels [22:15:00] <saintdev> river of frozen helium ? [22:15:06] <lu_zero> monday or not monday? [22:15:19] <spaam> Dark_Shikari: are you sure? [22:15:21] <siretart> boah, next difficult question. [22:15:27] <saintdev> nah, that doesn't work [22:15:28] <Dark_Shikari> yes [22:15:44] <Dark_Shikari> Current status is: waiting on [22:15:44] <Dark_Shikari> Intel (these guys move at the speed of a paraplegic three-toed sloth swimming [22:15:47] <Dark_Shikari> better! [22:15:50] <Dark_Shikari> down a river of frozen helium while chained to an osmium anchor stuck inside a black hole). [22:15:51] <siretart> I'd rather prefer not monday [22:16:01] <saintdev> lol [22:17:39] <Sean_McG> hahahahah [22:17:44] <Dark_Shikari> spaam: [22:17:45] <Dark_Shikari> Unlike any other element, helium will remain liquid down to absolute zero at normal pressures. This is a direct effect of quantum mechanics: specifically, the zero point energy of the system is too high to allow freezing. Solid helium requires a temperature of 1–1.5 K (about −272 °C or −457 °F) and about 25 bar (2.5 MPa) of pressure. [22:18:34] <siretart> lu_zero: sorry, I need to leave now, please let's continue this tomorrow. [22:18:36] <siretart> cu! [22:18:40] <lu_zero> ok [22:24:24] <ruggles> argh! codecs' use of float_to_int16_interleave is such a mess! [22:25:10] <mru> let's ditch the bias hack first [22:25:16] <mru> should simplify matters significantly [22:25:21] <mru> then we only have scale to think of [22:25:34] <andoma> yes [22:25:54] <ruggles> will that slow down the C version? [22:25:59] <andoma> yes [22:26:05] <ruggles> enough to matter? [22:26:08] <mru> measurably? [22:26:14] <Sean_McG> any word on the roundup error yet? [22:26:18] <mru> on hardware with an fpu [22:26:25] <lu_zero> trying is the only way to check [22:26:27] <mru> softfloat is irrelevant [22:26:28] <lu_zero> Sean_McG: which error? [22:26:31] <_av500_> Sean_McG: routing afaik [22:27:47] <Sean_McG> "content file for /var/db/roundup/ffmpeg/db/files/msg12681 not found" <-- this is routing related? [22:28:19] <ruggles> my plan was to put mul/add bias in FmtConvertContext so they could be used directly instead of comparing function pointers. removing add bias would certainly make it somewhat simpler. [22:29:02] <mru> bias/scale should obviously be provided explicitly [22:29:09] <mru> but we might drop bias [22:29:45] <andoma> i'm just thinking.. if speed is critical, why are you using a C-only version anyway? [22:29:59] <ruggles> you don't have anything else? [22:30:27] <_av500_> ruggles: like on a pen and paper computer? [22:30:45] <andoma> yeah but then perhaps you should switch hardware [22:32:02] <lu_zero> Sean_McG: I'm afraid that somebody got "luckily and commited something while that poor server was advised to route his packets through halfway the italian inner network and back [22:33:21] <andoma> i just think it's just plain wrong for FFmpeg to jump thru loops to optimize for the C only case [22:33:39] <lu_zero> (in short, roundup is nas backed on an IX, yesterday something got the wrong bgp informations and rerouted to hell most of the packets [22:33:43] <lu_zero> ) [22:34:04] <lu_zero> andoma: I'd like to have the C as fast as possible w/out losing sanity [22:34:09] <mru> any fpu has a fast float to int conversion instruction [22:34:15] <Sean_McG> ahhh, so yeah if it's a network filesystem then that makes sense [22:34:22] <mru> probably faster than that hack [22:34:31] <BBB> astrange: I'll likely just run two instances in the debugger, one good and one bad, and compare variables [22:34:57] <lu_zero> Sean_McG: so the file either got lost between the server and the nas or also between the sender and the server... [22:35:06] <Sean_McG> fair point [22:35:10] <_av500_> lu_zero: maybe the file is still "out there" [22:35:14] * Sean_McG *assumed* it was a local fs [22:36:03] <mru> _av500_: next to the truth [22:36:25] <lu_zero> I put roundup on nas to make it grow as needed [22:36:31] <ruggles> i vaguely remember mru saying something about some systems taking a huge percentage of time in format conversion. [22:37:29] <mru> ruggles: that's why we write asm [22:38:09] <ruggles> so what systems was that? or was that before the arm optimized float_to_int16_*? [22:38:44] <Dark_Shikari> Here's the general rule: [22:38:54] <Dark_Shikari> if you have no hardware FPU [22:39:03] <Dark_Shikari> your decoder that generates the float code will be intolerably slow [22:39:26] <Dark_Shikari> er, float data [22:39:43] <Dark_Shikari> So... it's pointless to optimize float_to_int16_t for sytsems without an fpu. [22:42:58] <Flameeyes> I assume *_(de)?muxer in libavformat/libavdevice should follow the same rule as libavcodec's stuff, right? [22:44:13] <mru> yes [22:44:37] <mru> but how does the matching work? [22:44:45] <mru> is it first match or last match? [22:44:50] <mru> or something else entirely? [22:45:30] <Flameeyes> I think it's greedy stuff [22:45:52] <Flameeyes> I know the common form is to provide a specific list in global: and then set local: *; [22:48:05] <mru> ld info page sucks [22:48:56] <Flameeyes> mru: ld info man page about the subject tend to lie as well [22:49:12] <Flameeyes> _protocol as well? [22:49:23] <mru> damn manual only says what not to do [22:49:29] <mru> yes [22:50:01] <BBB> astrange: for one of the testsuite files, two frames disappear, but the other frames are identical... does your code do anything w.r.t. framedropping or framedupping or so? [22:50:36] <mru> BBB: always use -strict 1 -vsync 0 [22:50:51] <BBB> I do [22:50:56] <BBB> even so it drops the first two frames [22:53:09] <Flameeyes> mru: why I have a bad feeling about "s->informat == &ff_mpegts_demuxer"? [22:53:34] <mru> same reason I get a bad feeling about that [22:53:44] <astrange> no. hold on a sec and i'll tell you some things to printf() [22:54:05] <Flameeyes> mru: equality tests between iformat and oformat seem to be all over the place :( [22:54:30] <mru> lavf is a mess [22:56:05] <lu_zero> interesting fact -std=c99 seems to trigger __STRICT_ANSI__ in certain compilers... [22:56:15] <Flameeyes> lu_zero: surprised? [22:56:28] <mru> that's correct [22:56:31] <Sean_McG> aye [22:56:43] <mru> it's various headers that are buggy [22:56:56] <andoma> yup, it screws up with newlib pretty badly :( [22:57:13] <mru> that's because someone confused syntax with symbols [22:57:38] <mru> -std=foo is for choosing which language syntax to use [22:57:51] <mru> library feature selection is done with -D_FOO_SOURCE [22:58:00] <BBB> astrange: ? [22:58:12] <BBB> astrange: I'm waiting :-p [22:58:18] <astrange> had to move rooms [22:58:19] <Flameeyes> mru: doesn't c99 also specify certain library interfaces? [22:58:20] <Sean_McG> FOO being one of either POSIX, XOPEN, or what have you [22:58:31] <lu_zero> Flameeyes: somebody assumes __STRICT_ANSI__ means --ansi [22:58:34] <mru> Flameeyes: yes, so? [22:58:54] <Flameeyes> mru: well, those should be enabled by -std=c99 anyway :) and those tend to be symbols as well [22:58:58] <lu_zero> so you lose about all c99 in a batch [22:59:05] <lu_zero> and yes [22:59:34] <astrange> in avcodec_decode_video2 or its caller in the client, print AVFrame.coded_picture_number [22:59:42] <lu_zero> newlib is the culprit [23:00:33] <mru> Flameeyes: system headers should expose standard C by default, more of requested with -D_POSIX_C_SOURCE etc [23:00:44] <mru> the standard headers, that is [23:00:58] <astrange> and in h264 print H264Context.outputed_poc and (in mt only) H264Context.next_output_pic->coded_picture_number [23:00:59] <mru> if a non-standard header is included, all bets are already off [23:01:13] <Flameeyes> okay hiding symbols on libavformat at least seem to have a better effect on percentage [23:01:17] <astrange> / -> poc [23:01:20] <astrange> that should help [23:01:52] <astrange> the major change here is i moved a lot of code into a function decode_postinit(). i guess there could be a merge glitch there [23:02:00] <Flameeyes> since it reduces symbols from 699 to 451 [23:02:27] <BBB> astrange: working on it [23:07:16] <BBB> astrange: looks bad [23:07:23] <BBB> astrange: it outputs images in the wrong order, I think [23:07:47] <BBB> basically first few calls to decode_frame() in h264 are all outputed_poc=0 [23:08:07] <BBB> then after a while it skips up, avcodec_decode_video() returns data and then it's like this: [23:08:13] <BBB> 0,4,5,3,7,8 [23:08:33] <BBB> (that's the order of numbers after subsequent calls to avcodec_decode_video() [23:08:34] <BBB> ) [23:09:35] <BBB> astrange: 1 and 2 are missing and never occur in return calls from avcodec_decode_video() [23:09:38] <BBB> astrange: whatever that means [23:10:05] <astrange> poc is decode order, not display order. i think [23:10:15] <astrange> the two decoders just have to match [23:11:34] <BBB> I see, let me see [23:11:55] <Dark_Shikari> no [23:12:10] <mru> poc is monotonically increasing in display order [23:12:16] <mru> but it's allowed to skip [23:12:20] <Dark_Shikari> wrong [23:12:30] <mru> what then? [23:12:30] <Dark_Shikari> poc is required to increase 1 with each field [23:12:39] <mru> did they finally fix the spec? [23:12:39] <Dark_Shikari> 1, only 1, exactly 1 [23:12:43] <Dark_Shikari> so, 2 per frame [23:12:59] <mru> that used to be the topic of endless debate [23:13:06] <BBB> astrange: recompiling, give me a minute, don'trun anywhere [23:13:30] <Dark_Shikari> frame num can have gaps [23:13:31] <Dark_Shikari> poc can't [23:13:34] <Dark_Shikari> AFAIK [23:13:51] <mru> around 2004 everybody was doing it differently [23:14:31] <Dark_Shikari> :/ [23:14:52] <mru> back when I was hacking on x264 [23:15:22] <Dark_Shikari> You should come do that again. [23:15:25] <Dark_Shikari> We have tons of cool stuff to do. [23:16:04] <BBB> astrange: no, bad [23:16:14] <BBB> astrange: original, output is 1,2,0,4,5,3 [23:16:20] <BBB> astrange: mt output is 0,4,5,3 [23:16:22] <BBB> etc. [23:16:28] <BBB> do you want the input of outputed_poc also? [23:16:35] <Dark_Shikari> Why should mt output be different? [23:16:39] <Dark_Shikari> x264 doesn't output frames in a different order. [23:16:42] <Dark_Shikari> because of its mt [23:16:42] <astrange> bugs [23:16:46] <astrange> this is with mt turned off [23:17:12] <mru> Dark_Shikari: nah, I don't like your coding style [23:17:23] <mru> if ( foo ) eeeed [23:17:24] <mru> eek [23:17:33] <mru> sorry, i_foo [23:17:33] <BBB> mt: 19x0,2,4,6; original: -2147483648x16,-4, -2, 0, 2, 4, 6 [23:17:45] <BBB> astrange: i.e. it appears to not handle negative poc values very well? [23:17:49] <BBB> it truncates them to zero [23:17:59] <BBB> and I guess then discard the frame [23:18:11] <mru> is that INT_MIN? [23:18:14] <BBB> yes [23:18:56] <BBB> astrange: is this useful or do you need more debug info? [23:19:00] <Dark_Shikari> mru: we got rid of hungarian [23:19:05] <Dark_Shikari> or, at least, new code doesn't have it. [23:19:09] <astrange> that's getting close to it [23:19:09] <BBB> if( foo ) is indeed weird [23:19:13] <Dark_Shikari> if( foo ), not if ( foo ) [23:19:21] <Dark_Shikari> anyways, spacing style is not really a reason not to work on code [23:19:22] <astrange> i need to move again and get the laptop power adapter to look [23:19:27] <Dark_Shikari> ffmpeg, vlc, and x264 are all fine [23:19:28] <astrange> is -debug mmco the same in both? [23:19:30] <BBB> astrange: omg get a home :-p [23:19:31] <Dark_Shikari> derf's code: NOT FINE. [23:19:36] <Dark_Shikari> (i.e. celt) [23:19:52] <BBB> astrange: I'm going home, email me if you need more or leave me a message in this irc bouncer thing [23:19:56] <BBB> astrange: I'll read it later [23:20:00] <astrange> i can look [23:20:04] <astrange> just tell me the sample name, i forgot it [23:20:23] <Dark_Shikari> mru: you're giving shitty excuses btw =p [23:20:29] <BBB> ffmpeg -v 0 -vsync 0 -strict 1 -i /Users/ronaldbultje/Movies/fate-suite/h264-conformance/CAMA1_TOSHIBA_B.264 -f framemd5 - [23:20:44] <mru> Dark_Shikari: I know [23:20:44] <BBB> aka make fate-h264-conformance-cama1_toshiba_b [23:20:48] <mru> but seriously, I have no time [23:20:55] <Dark_Shikari> you have to time to bitch on irc all day =p [23:21:01] <Sean_McG> lol [23:21:06] <mru> I'm doing work at the same time [23:21:17] <mru> right now I'm being paid to work on ffmpeg [23:21:28] <Dark_Shikari> true, you're getting paid by the hour~ [23:22:14] <mru> I'm actually a rather generous fixed-price contract right now [23:23:24] <lu_zero> Dark_Shikari: how's celt now? [23:24:01] <Dark_Shikari> what about it [23:24:07] <Dark_Shikari> they seem to be panicking about getting it done in time for opus mainly [23:24:23] <Dark_Shikari> which is important because it hardcodes so much stuff in the bitstream format [23:26:38] <jannau> mru: http://lists.ozlabs.org/pipermail/patchwork/2011-January/000369.html [23:27:24] <lu_zero> ugh [23:27:31] <lu_zero> so celt2 might be sane [23:27:34] <lu_zero> not celt [23:27:41] <mru> jannau: would work for me [23:32:07] <Sean_McG> ahhh mail-archive.com has the emails for this issue, cool [23:36:10] <mru> BBB: does the vp8 idct overflow 16 bits? [23:37:57] <Dark_Shikari> no [23:38:18] <mru> other than those multiplications that use only the high half [23:40:47] <mru> BBB: btw, some vp8 emu-edge tests are failing on sparc64/bsd [23:44:02] <Sean_McG> someone forget about big-endianness? [23:44:35] <mru> works on ppc [23:44:53] <mru> except some gcc versions [23:45:33] <mru> and sparc64/linux works [23:46:07] <Flameeyes> sparc64/bsd -> fbsd? [23:46:12] <mru> open [23:46:22] <Flameeyes> k [23:46:41] <Flameeyes> was going to say that fbsd used to throw sigbus more often wrt unaligned load because gcc assumed the OS dealt with that [23:47:36] <mru> we take care not to do any unaligned loads needing fixup

1 0

IRC log for 2011-01-24
by irc＠mansr.com 25 Jan '11

25 Jan '11

[00:03:19] <ruggles> this is driving me insane... why would function parameters get loaded in the wrong registers? [00:04:48] <pengvado> missing prototype? [00:05:49] <ruggles> ah, maybe so. [00:05:58] <ruggles> thanks [01:04:49] <ruggles> still no luck on the param swapping. i'm setting up the function exactly like every other yasm function in ffmpeg... [01:06:07] <ruggles> but at the start of the function, the values for r2 and r3 are reversed... [01:08:05] <ruggles> x86inc.asm has r0,r1,r2,r3 as rdi, rsi, rdx, rcx for x86_64 [01:08:20] <ruggles> but my 4th param is getting loaded into rdx not rcx [01:12:24] <roxfan> alignment? [01:12:40] <roxfan> oh wait [01:12:53] <roxfan> what about third param? [01:15:04] <ruggles> 3rd param is a float... [01:15:16] <ruggles> maybe it's going in a fp register instead? [01:15:28] <roxfan> yep [01:15:54] <ruggles> so i have to cast it to an int? [01:16:11] <roxfan> i guess, if you need in integer reg [01:27:49] <ruggles> ok, so the 3rd param gets passed in xmm0. but can i count on that? [01:28:29] <saintdev> won't that depend on the calling convention? [01:28:36] <Dark_Shikari> x86inc doesn't handle float params. [01:28:41] <Dark_Shikari> because x264 never needed them [01:29:33] <ruggles> inline asm it is... :( [01:29:39] <mru> eeew [01:29:52] <mru> it can't be that hard to fix the params in yasm [01:36:44] <ruggles> maybe change PROLOGUE to # args, # int regs, # float regs, # xmm regs, params... and list float params after int params [01:38:13] <ruggles> but i don't know enough about x86 asm to know what to define them as on various arches [01:39:38] <peloverde> can you just pass the float by pointer? [01:41:11] <mru> that would be silly [01:41:43] <mru> I doubt this is the last time this problem will surface [01:41:52] <mru> we might as well solve it properly now [01:42:40] <Dark_Shikari> peloverde: I did that for the one function in x264 that needed it. [01:42:59] <mru> but here we're dealing with mostly-float code [01:43:05] <Dark_Shikari> true [01:43:08] <Dark_Shikari> in ffmpeg, it needs to be doe right [01:43:10] <mru> shoving everything through pointers will kill performance [01:48:32] <mru> btw, take a look at fate [01:48:36] <mru> tell me what you think [01:50:28] <saintdev> mru: perhaps warnings should be a link to compile log? [01:50:37] <mru> good idea [01:56:31] <mru> done [01:59:36] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r5f3b8314a4 ffmpeg/configure: [01:59:37] <CIA-43> ffmpeg: Add CFLAGS needed by PathScale compiler [01:59:37] <CIA-43> ffmpeg: The PathScale compiler miscompiles wrapping arithmetic without [01:59:37] <CIA-43> ffmpeg: these flags. [01:59:37] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [02:01:23] <ruggles> so on x86_32 all params are on the stack, but x86_64 are in xmm (4 for windows, 8 for all other)? [02:01:34] <ruggles> float params that is [02:03:52] <Jumpyshoes> hrm, is reimar still active? [02:04:28] <mru> Jumpyshoes: he's never on irc [02:04:54] <mru> he was posting on the ml a few days ago at least [02:04:58] <Jumpyshoes> oh, okay [02:05:14] <Jumpyshoes> i have a patch that needs review, but probably got overwhelmed in the patchspam [02:05:37] <mru> ping it and see what happens [02:05:40] <Jumpyshoes> k [02:14:02] <BBB> Dark_Shikari: is there a instruction that swaps the lower and higher word in a dword register? [02:14:38] <mru> rotate 16 [02:15:33] <Dark_Shikari> rotate, yes [02:19:03] <BBB> like ror edx, edx, 16? [02:19:20] <BBB> cool [02:19:22] <mru> sounds about right [02:21:20] <ruggles> i can't see how a PROLOGUE macro with float args can be done for both x86_32 and x86_64 unless float args are always last (or always first). [02:22:20] <Dark_Shikari> It can be done if the PROLOGUE macro is aware of the types of the args. [02:22:23] <Dark_Shikari> this is hard. [02:24:25] <BBB> ror is cool [02:24:31] <BBB> wish I had known earlier :) [02:25:42] <peloverde> I don't see anything wrong with requiring float parameters to be last [02:26:04] <mru> me neither [02:26:11] <mru> simplifies all kinds of things [02:26:23] <mru> I have two calling conventions to deal with on arm too [02:26:28] <uau> why do people insist on handling stuff like calling conventions in raw asm? [02:26:40] <mru> uau: how else would you do it? [02:26:43] <uau> is there any real advantage in not using inline asm for that? [02:27:01] <uau> if you want more complex macros you could add a proprocessing stage before that [02:27:13] <mru> yasm has a rather good preprocessor [02:28:47] <uau> is it just that nobody has implemented that, or is there a real reason why it'd be good to avoid using gcc for things like calling conventions, access methods to globals, and correct elf sections? [02:29:06] <mru> if gcc can fuck up, it does fuck up [02:29:14] <mru> if you let it touch code, it can fuck up [02:29:35] <mru> also, yasm is much nicer for writing code [02:29:48] <mru> and you can't very well mix that with gcc inline [02:29:57] <uau> nicer in a way that couldn't be done with a preprocessing step before gcc? [02:30:15] <mru> what would that preproc do? [02:31:07] <uau> try to emulate as much of that "nice yasm functionality" as possible [02:33:14] <uau> you certainly could implement things like register renaming etc with that [02:33:14] <mru> half the point is to avoid gcc [02:33:14] <mru> it has the habit of spewing tons of crap around inline asm [02:33:14] <saintdev> uau: the yasm preprocessor can do things like loops [02:33:14] <mru> I'm surprised you don't know that already [02:33:14] <BBB> omg that discussion again [02:33:14] <BBB> uau: how much of the ffmpeg asm did you write? [02:33:28] <BBB> try writing a couple dozen functions, you'll see why we use yasm :) [02:33:44] <mru> BBB: git says none [02:33:50] <uau> BBB: none i think [02:34:02] <BBB> mru: it's scary how quickly you figured that out [02:34:24] <mru> git log --author=Uoti libavcodec/x86 [02:36:42] <uau> BBB: and there are also reasons to avoid doing everything in completely raw asm - so what i was wondering about was not so much why you'd want to use yasm over "plain" inline asm, but how much of that functionality available in yasm would not be compatible with using gcc for some of the higher-level stuff [02:37:38] <BBB> uau: raw asm is faster [02:37:47] <BBB> don't you want your phone to play HD video from youtube? [02:38:37] <uau> BBB: OTOH you add at least call overhead to everything you implement in yasm, so it can't be too tiny [02:38:41] <BBB> or you mean using cc instead of yasm for preprocessor tricks? [02:39:01] <uau> no, kind of the opposite [02:39:25] <uau> using something "yasm-like" for the "preprocessor tricks" [02:39:35] <uau> but using gcc as the backend to compile the result [02:39:54] <uau> as it has support for a lot of stuff that is cumbersome to do manually, like all calling conventions etc [02:40:17] <mru> but then gcc would be able to inject its poison [02:41:21] <uau> mru: well gcc already does the calling side, and you're willing to take at least call overhead for everything you write in yasm anyway [02:41:34] <BBB> call overhead is small [02:41:38] <mru> it's a tradeoff [02:41:46] <uau> i doubt the "poison" could be so much extra overhead that it'd matter for a lot of functions [02:41:50] <mru> writing everything in asm would surely double the speed [02:41:54] <uau> if it's still something run at most once per call [02:42:05] <mru> but doing so isn't exactly feasible [02:42:35] <BBB> I think for loop_filter_strength calculation, the gcc overhead around the inline asm made it take twice the cycles [02:42:48] <BBB> gcc is like a civil servant [02:42:50] <BBB> it does its job [02:42:53] <BBB> it's busy [02:42:56] <BBB> it does a lot of stuff [02:43:03] <BBB> but the end result makes you wonder what it's doing all day [02:48:03] <uau> so, are you seriously claiming that asking gcc to place function parameters into suitable registers would create so much overhead that it'd be an issue for a lot of functions? [02:48:59] <mru> yes [02:52:33] <uau> i have a hard time believing that [02:58:18] <Jumpyshoes> changing a constant from a double to float could speed up a function by 5x [02:58:20] <Jumpyshoes> in gcc [02:58:49] <mru> not surprising [02:59:03] <mru> double arithmetic is generally slower than floag [02:59:05] <mru> float [02:59:30] <Jumpyshoes> it's one constant. five times. [03:06:35] <Dark_Shikari> Jumpyshoes: I've seen that before [03:06:38] <Dark_Shikari> possibly even more extreme than that [03:12:03] <uau> mru: can you construct a case where gcc would really screw up just "function arguments -> asm parameters" on amd64? [03:12:37] <mru> Dark_Shikari would be a better person to ask for that [03:13:51] <Dark_Shikari> be more specific? [03:15:37] <uau> Dark_Shikari: mru claimed above that using gcc to compile asm would necessarily add so much overhead that it'd be an issue for a lot of functions [03:16:10] <Dark_Shikari> I recall gcc doing too many stupid things in general for me to trust it. [03:16:49] <uau> i find that hard to believe; so is there some example that would demonstrate gcc adding a lot of overhead for using it just for the calling convention, to move function parameters into suitable registers? [03:16:53] <mru> one thing I've often seen gcc do is dump a bunch of callee-saved regs to stack and use those even though scratch registers are available [03:17:25] <Dark_Shikari> uau: If you let gcc do register allocation, it will often be dumb. [03:17:32] <Dark_Shikari> If you do it yourself, it will only be optimal on one architecture. [03:17:38] <Dark_Shikari> Because you have to use explicit register names. [03:17:40] <uau> mru: i could imagine gcc doing that - but i wouldn't expect that overhead to matter much for many functions [03:17:42] <Dark_Shikari> Which will result in things getting moved around. [03:18:04] <Jumpyshoes> there was that retarded compile bug that i fixed a while back [03:18:12] <mru> uau: you are speculating, I and the others are speaking from experience [03:19:03] <Jumpyshoes> i think it was transpose4x4 [03:19:55] <uau> mru: what was speculation about that? i don't think it's too speculative to say that one unnecessary load/store of some registers would not add that much overhead [03:20:14] <Dark_Shikari> In a function that takes 30 clocks, 5 clocks spent load/storing kinda sucks. [03:20:19] <mru> you've been speculating all along [03:21:35] <uau> mru: of course it's somewhat speculative - nobody has written that kind of "gcc as a backend after preprocessing" system for ASM as far as i know [03:22:55] <uau> but OTOH the fact that some people have worked on asm and not implemented that shouldn't automatically be taken as a proof that it would be a bad idea [03:23:28] <mru> if you want us to believe you, you need to make such a system [03:24:30] <uau> people certainly have worked with bad tools before, even people who managed to create something working well, so people having experience with and managing to implement things with current tools does not automatically prove that the tools are good [03:25:04] <mru> I'm talking only about results here [03:25:30] <mru> you're talking about doing brain surgery with a chainsaw [03:33:56] <uau> i don't think there's anything which would make it that unreasonable [03:34:45] <uau> gcc would have to try pretty hard to be able to waste more than a couple dozen cycles, and even that would still be useful for many classes of functions that do a significant amount of work at once [03:36:08] <uau> and worrying about the absolute possible worst case how gcc _could_ screw up doesn't seem appropriate if you're still calling the function from code generated by gcc - in worst case gcc could really screw up that side just as well [03:36:18] <saintdev> Zzzzz [03:38:19] <BBB> Dark_Shikari: you're genious btw [03:38:54] <BBB> Dark_Shikari: I wrote the yasm version of emu_edge which calls width-specific copy/extend "sub"functions, and it's a friggin close-to-100 cycles faster [03:39:03] <BBB> it's ~170 cycles now for this particular test movie [03:39:08] <BBB> when I started it was ~1000 [03:39:10] <BBB> \o/ [03:39:49] <Dark_Shikari> Nice. [03:39:53] <Jumpyshoes> isn't that what offset(add|sub) does? [03:40:00] <Dark_Shikari> Well, it's an approach I learned from Loren's cacheline code [03:40:06] <Dark_Shikari> It's basically a switch statement. [03:40:13] <BBB> right [03:40:16] <BBB> except a very funkyone [03:40:27] <Dark_Shikari> Are you using a jump table or a computed jump? [03:40:33] <BBB> computed jump [03:40:36] <Dark_Shikari> If it's the latter, you MUST CONFIRM that your functions are the right size on all arches [03:40:41] <Dark_Shikari> There is no way to guarantee this in yasm [03:40:51] <BBB> I did, I manually went over all of them in x86-64 and 32 [03:41:03] <Dark_Shikari> win64 [03:41:15] <BBB> commit, see if it breaks? [03:41:17] <BBB> :-p [03:41:17] <Dark_Shikari> lol [03:41:23] <BBB> ramiro took down my account [03:41:28] <BBB> I think he's pissed [03:41:36] <Dark_Shikari> Also, you should make sure that you shrink things as much as possible [03:41:38] <Dark_Shikari> how large is each function? [03:41:40] <Dark_Shikari> in bytes [03:41:47] <BBB> 64 [03:41:52] <BBB> (I know, that's a lot) [03:42:05] <BBB> I haven't tried shrinking to 48 or so [03:42:10] <BBB> it's probably possible to shirnk it [03:42:57] <BBB> I couldn't shrink to 32, didn't fit [03:43:16] <Dark_Shikari> How many are too large? [03:43:34] <Dark_Shikari> You could also do it to something non-mod16 [03:43:35] <Dark_Shikari> like mod8 [03:43:51] <Dark_Shikari> If it would save a ton of space, you could use a jump table instead [03:43:58] <Dark_Shikari> since here, each loop is being run many times [03:44:02] <Dark_Shikari> so the cost of the initial jump isn't huge [03:44:10] <Dark_Shikari> so if it saves space, it might be better to use a table [03:44:43] <BBB> I can try [03:44:51] <BBB> it'll probably save space [03:44:58] <Dark_Shikari> That means btw that you should STOP aligning them [03:45:02] <Dark_Shikari> so no nops between sections [03:45:05] <BBB> I've got 24x4xsizeof(function) bytes here [03:45:10] <Dark_Shikari> Then again... [03:45:10] <BBB> I know :) [03:45:15] <Dark_Shikari> Here's another thing to consider [03:45:31] <Dark_Shikari> Each time you call emulated_edge, you will be using three loops [03:45:31] <BBB> but 24x4=96x0x40=0x1800 bytes [03:45:34] <Dark_Shikari> er, four loops [03:45:38] <Dark_Shikari> one to fill top/bottom [03:45:40] <Dark_Shikari> one to fill mid [03:45:43] <Dark_Shikari> one to fill left [03:45:45] <Dark_Shikari> one to fill right [03:45:46] <Dark_Shikari> right? [03:45:48] <BBB> yes [03:45:56] <Dark_Shikari> The odds of any of these overlapping in the same cacheline is low. [03:46:03] <BBB> yes [03:46:06] <Dark_Shikari> Therefore, odds are that your initial jump, no matter what, will be an L1 instruction cache miss. [03:46:20] <Dark_Shikari> So it doesn't actually matter how much space they take up as long as each one fits in a cacheline. [03:46:24] <Dark_Shikari> Probably. [03:46:48] <mru> in that case, make sure they're aligned on cache lines [03:48:49] <Dark_Shikari> Yeah, sounds like a good idea [03:48:57] <Dark_Shikari> and fuck x86 cpus with 32-byte cachelines [03:49:30] <mru> still better two than three [03:51:00] <Dark_Shikari> Of course [03:51:27] <pengvado> Dark_Shikari: you can ask yasm for padding up to a certain size, and I think you can also assert based on the numerical value of the difference between 2 labels. [03:52:12] <pengvado> so you have to manually figure out what the size should be, but you can ensure that it won't silently miscompile if you get it wrong [03:54:23] <Dark_Shikari> Ah, nice. [04:48:58] <relaxed> http://pastebin.com/raw.php?i=YyjLCNUT [05:49:58] <drv> relaxed: can you do 'display /i $pc' in gdb too? [05:50:03] <drv> should show which instruction it is [05:50:30] <drv> (if your source lines match up to mine, that is a femms under if (flags & SWS_CPU_CAPS_3DNOW) [06:05:15] <relaxed> drv: 1: x/i $pc 0x90850e <swScale_3DNow+10814>: femms [06:14:40] <drv> hmm, do you have a 3dnow-capable CPU? [06:21:55] <relaxed> drv: I don't believe so, it's a Intel(R) Core(TM)2 CPU T7600 [06:23:55] <cartman> moin [06:25:03] <thresh> moroning [06:25:24] <_av500_> guten morgen [06:26:25] <thresh> it's monday morning, no way it could be good [06:27:06] <cartman> thresh: agreed [06:27:13] <cartman> got a boring meeting in 5 minutes [06:28:10] <kshishkov> thresh: you can discover it's not true if you move outsize 100.500th Moscow Ring road (aka Russian state border) [06:29:43] <thresh> kshishkov: that would make me get to bed earlier on Sundays? [06:31:58] <kshishkov> thresh: probably, some European countries have limitations on what can be opened on Sunday [06:33:18] <thresh> kshishkov: I only had 'Sprite' and lemon slices, are those prohibited in The Promised Lands? [06:34:24] <cartman> Sprite is OK [06:43:10] <_av500_> sprite and lemon slices [06:43:20] <_av500_> russia is not what it used to be [06:43:35] <_av500_> since when do they have lemon slices [06:48:02] <lu_zero> good morning [06:48:17] <cartman> moin lu_zero [06:48:21] <lu_zero> _av500_: nag me about the mpegts chain demuxer later in the week [06:48:26] <lu_zero> possibly once a day [06:49:27] <thresh> _av500_: the joys of globalization [06:49:28] <lu_zero> uau: having gcc provide that kind of result would be nice, nobody tries and succeeded to my knowledge [06:49:58] <thresh> it's actually cheaper to import turkish potatoes than to grow them even in the most fertile grounds [06:50:50] * cartman notes that [06:52:34] <_av500_> thresh: so all the russians at the mediteranean are just moving closer to the potatoes? [06:55:42] <thresh> _av500_: could be true as potatoes are our favourite food [06:55:50] <thresh> except for vodka of course [07:02:38] <lu_zero> thresh: how so? [07:03:06] <lu_zero> I mean there are potatoes and topinanbour that resist cold quite well [07:10:00] <thresh> lu_zero: I have no idea, but that's what I see on the shelves of supermarkets [07:10:05] * lu_zero sometimes wonders why people are so fixed on potatoes and forgets topinambour [07:10:08] <thresh> no russian potatoes here [07:11:02] <lu_zero> thresh: topinambour are pretty much more interesting than potatoes and they grow more or less everywhere you leave them IIRC [07:12:03] <thresh> lu_zero: topinambours are exotic in Russia [07:12:38] <thresh> no idea why actually, probably potato growers lobby =) [07:12:48] <lu_zero> thresh: start growing them! Might be interesting [07:32:14] * lu_zero wonders [07:32:16] <lu_zero> ff_h264_get_slice_type+0x138 [07:32:43] * lu_zero is too lazy to disasm by hand [07:33:04] <lu_zero> is there a simpler way to spot the line referred? [07:34:37] <lu_zero> give it's just a switch [07:35:01] <lu_zero> I think it should be the h->slice_type [07:35:08] <lu_zero> but isn't that a bit too far? [07:38:34] <drv> it could be in a static function that is after that symbol [07:39:41] <cartman> _av500_: http://www.youtube.com/watch?v=FKG34jlZdqo [07:40:27] <thresh> "The story takes place in 1632 in Istanbul, where he will attempt the first flight of the human being." hmmm I thought that was the Icarus [07:40:58] <kierank> cartman: rip off of aladdin [07:40:59] <kierank> ;) [07:41:07] <cartman> kierank: heheh no :) [07:41:30] <lu_zero> drv: ^^; [07:41:53] <cartman> the story as I have been told is someone steals Leonardo DaVinci's drawings of human-wings and somehow Hezarfen gets hold of them [07:41:57] <cartman> and starts implementing one [07:55:55] <spaam> God morgon [08:05:07] <superdump> god morgon spaam [08:05:20] <av500> cartman: thx for wasting 3:42 of my life... [08:05:37] <cartman> av500: thats why I am here for [08:06:02] <spaam> superdump: allt bra? :) [08:06:03] <saintdev> av500: demand a refund [08:06:15] * cartman refunds av500 3:43 [08:06:27] <spaam> Nice. one extra [08:06:58] <saintdev> cartman has excellent customer service o.O [08:07:03] <cartman> :D [08:07:14] <superdump> spaam: mostly [08:07:16] <saintdev> didn't even need an RMA [08:07:27] <superdump> cat sprained its knee by slipping on the bath yesterday [08:07:39] <superdump> and he's protesting against resting right now :) [08:08:16] <spaam> hehe :) [08:21:53] <cartman> http://dilbert.com/fast/2011-01-24/ heheh [08:26:44] <spaam> haha [08:28:44] <kshishkov> cartman: http://comics.com/pearls_before_swine/2011-01-23/ [08:29:49] <cartman> kshishkov: heheh [08:30:22] <spaam> kshishkov: is that how you do it? :) [08:30:46] <kshishkov> spaam: nope, I shun social networks completely [08:31:08] <spaam> aww [08:31:55] * cartman hates Facebook [08:32:28] <kshishkov> cartman: I think only Dark_Shikari here has a right to hate it [08:32:45] <spaam> cartman: KotH hates me on facebook.. he never accept my friend reqeust :( [08:32:51] <cartman> kshishkov: why? [08:32:56] <cartman> spaam: that bastard [08:32:57] <cartman> :D [08:33:00] <elenril> KotH has a facebook account? [08:33:06] <spaam> yes [08:33:30] <cartman> spaam: he didn't even tell me he had one :D [08:33:31] <kshishkov> cartman: read http://x264.nl/developers/Dark_Shikari/consulting.html [08:34:20] <spaam> cartman: KotH can be a bit shy sometimes. [08:34:27] <cartman> kshishkov: nice rates [08:34:42] <cartman> spaam: He secretly hates me :P [08:34:58] <cartman> kshishkov: I think Facebook is nice engineering-wise [08:35:24] <spaam> cartman: i know the feeling.. he used to kick and ban me.. :) [08:35:33] <kshishkov> cartman: well, he can ask them and there companies willing to pay them, he's not you (i.e. not in Turkey) [08:36:02] <cartman> kshishkov: yeah I get nicely paid here, never mind me rumbling all the time :D [08:37:33] <spaam> cartman: is that why you have more then one wife? [08:37:53] <cartman> spaam: no thats because we are not a secular state anymore [08:37:56] <cartman> up to 4 allowed [08:38:28] <kshishkov> cartman: you should have ended that sentence with "Allah akbar" [08:38:40] <spaam> haha [08:38:44] <cartman> kshishkov: Ma$allah brother [08:50:26] <wbs> lu_zero: would you like to rebase the switch->poll patchset on top of the latest version and apply it sometime? it's annoying to know that such a change is coming, without actually having it in the main tree :-) [08:55:05] <lu_zero> wbs: uh... [08:55:14] <lu_zero> that's something I was about to forget... [08:55:18] <lu_zero> thanks for reminding [09:01:59] <lu_zero> rebased now [09:02:05] <lu_zero> testing ^^; [09:21:09] <j0sh> should ff_yuv2rgb_coeffs be public? [09:21:34] <j0sh> there is no real way to call sws_setColorspaceDetails without it [09:22:36] <j0sh> other than writing the coeffs yourself into the parameters [09:24:16] <cartman> http://www.mesa3d.org/MESA_ycbcr_texture.spec looks interesting [09:25:28] * kierank hates reading ascii specs [09:25:48] <cartman> kierank: you like PDF ones better? :p [09:25:56] <kierank> yeah [09:26:32] <j0sh> kierank: you must *really* hate RFCs then [09:26:48] <kierank> yes, yes i do [09:30:14] <kierank> I actually considered writing a script to convert them to a readable font [09:31:21] <j0sh> you could make a bookmarklet that swaps out the css for something custom [09:31:45] <j0sh> oh, they're plain text, no css, lol [09:32:00] * j0sh needs sleep [09:34:28] <pross-au> kierank: so you need diagrams? ascii can do that [09:35:06] <kierank> i don't have a problem with ascii diagrams [09:35:25] <kierank> it's just when there's a wall of text (that isn't code) I'd rather it be in something readable [09:36:03] <kierank> also my other gripe with specs is when they have loads of syntax element tables then explanations after so you have to scroll up and down to read the syntax element and the explanation [09:36:07] <pross-au> that markdown format is pretty need [09:36:11] <pross-au> *neet [09:36:24] <j0sh> i think well styled ascii is a lot more readable than, say, the h264 spec [09:36:36] * cartman hands pross-au a "neat" [09:36:58] <j0sh> MS word formatted times new roman just makes me want to gouge my eyes out [09:37:37] * kierank has that opinion for ascii specs [09:37:37] <pross-au> agree with you on the jumping around bit [09:38:00] <pross-au> MPEG-4 Part 2 is like a choose your own adventure [09:38:31] <kierank> 13818-1 has it right [09:38:39] <kierank> you don't need to scroll like hell [09:41:33] <j0sh> specs need to be LaTeX'd, especially ones that are equation heavy [09:41:44] <j0sh> and syntax elements properly monospaced [09:41:45] <kshishkov> +2.71 [09:41:57] <j0sh> i think those are my two biggest gripes with most pdf specs [09:42:44] <lu_zero> s/LaTeX'd/formatted in a decent way no matter how/ [09:43:12] <lu_zero> LaTeX originated pdf might gouge your eyes as well [09:43:34] <lu_zero> e.g. sporting a screen-unfriendly font [09:43:35] <j0sh> i suppose but at least latex will usually do a good job of making the presentation nice [09:45:07] <j0sh> i just realized something [09:45:14] <j0sh> the h264 spec is justified [09:45:44] <kierank> yep [09:45:46] <j0sh> the spacing is all whacky, thats prob part of the reason i don't like it [09:51:52] <kshishkov> j0sh: say hello to your friend M$ Word and its flexible interword spacing then [09:52:07] <kshishkov> that's where most of those documents were made [09:52:29] <kierank> s/most/all [09:53:31] <kshishkov> SWF spec was made in FrameMaker [09:54:08] * kierank doesn't consider fruit or flash related specs relevant [09:57:40] <kshishkov> VP8 spec was converted from HTML [09:58:04] <kierank> VP8 spec was converted from C [09:58:29] <j0sh> the swf spec is actually really nice [09:58:50] <j0sh> the rtmp spec, on the other hand... [09:59:21] <kshishkov> j0sh: well, if company that mades its buck from publishing and design publishes spec in eye-watering style it's a sure sign of megafail [09:59:54] <kshishkov> RTMP spec looked like quick convert from RFC [10:00:17] <kshishkov> which showed how much they cared for it [10:00:21] <kierank> kshishkov: what about rv40 spec [10:01:30] <kshishkov> kierank: Word [10:02:02] <j0sh> eugen andrei (c++ rtmp server creator) had a really good description of the rtmp spec [10:02:10] <j0sh> "That doc is the work of a sunday-drunk Adobe employe in a rainy monday morning with a 6 foot tall boss shouting at him" [10:02:57] <kshishkov> j0sh: "c++ rtmp server creator" means nothing since there are dozens of RTMP server in any language including VB [10:03:51] <j0sh> https://groups.google.com/group/c-rtmp-server/msg/3c3d13842a30e3f6 [10:04:06] <j0sh> yeah but he wrote *the* c++ rtmp server, like that is the name of the project :) [10:04:44] <j0sh> it's actually a nice implementation, minus the mountains of C++ template hackery [10:04:56] <j0sh> follows the behavior of flash/fms closer than anything else i've seen [10:05:47] * kshishkov is disgusted by RTMP [10:06:12] <j0sh> join me and lu_zero in brooding [10:06:21] * lu_zero is disgusted by rtmp and C++ [10:06:53] <kshishkov> lu_zero: and you know that I have my reasons to hate RTMP [10:07:20] <kshishkov> C++ not that much because I've not tried reading new specs for it [10:07:35] * lu_zero did [10:07:44] <lu_zero> I was foolish enough to [10:08:07] * kshishkov is extremely disgusted by Boost, strongly disgusted by STL and just disgusted by the rest of C++ [10:25:32] <peloverde> with the exception of std::vector<bool> STL isn't so bad [10:27:39] <kshishkov> it's horrible [10:28:50] <kshishkov> when I moved from C++ different compilers had different support for STL and no one used its string class [10:32:39] <merbzt> no being able to read code without an IDE makes it hard to understand at times [10:35:41] <kshishkov> reminds me of that small symbol mru found once - that took ~36k in demangled form [10:37:20] <ubitux> is there anyone working on the vf_drawtext filter (soc)? [10:37:49] <kshishkov> peloverde: BTW, do you think anybody else is going to review my wavpack patch? [10:38:18] <superdump> do we have anyone who knows wavpack or has the spec? [10:38:20] <superdump> other than you [10:38:30] <superdump> (is there a spec) [10:39:00] <kshishkov> there is [10:39:21] <peloverde> kshishkov: my guess is no [10:39:28] <kshishkov> superdump: http://www.wavpack.com/file_format.txt [10:40:01] <kshishkov> superdump: and http://matroska.org/technical/specs/codecid/wavpack.html [10:40:46] <superdump> perhaps spam those links to the ML in case anyone else wants to check it [10:40:55] <superdump> i'm afraid i don't have time right now [10:41:45] <peloverde> add a multichannel sample to fate so no one breaks it [10:42:26] * kshishkov is not into encoding [10:42:41] <kshishkov> peloverde: you can ask me to create AAC samples though [10:43:09] <peloverde> surely you must have had a sample to test this patch on? [10:43:46] <kshishkov> yep, ~350MB of samples for 1.0, 2.0, 4.0, 5.1, 6.1 and 7.1 [10:44:16] <peloverde> just add a small clip of 5.1 or 7.1 [10:44:17] <kshishkov> the guy asking for support was nice to encode them for testing [10:51:00] <kshishkov> in any case I'd be able to create fate test only on Wednesday or later [10:54:37] <lu_zero> 11:35 <@kshishkov> reminds me of that small symbol mru found once - that took ~36k in demangled form [10:54:59] <lu_zero> that was from boost:spirit [10:55:37] <lu_zero> so probably it was a full parse graph encoded in a symbol [10:56:42] <superdump> mru: random suggestion if possible - on fate, perhaps clicking on the coloured bar at the top could filter out those items of that colour [10:56:55] <superdump> with some intuitive way to go 'back' to unfiltered [11:00:22] <superdump> actually i guess with sorting it's not so necessary [11:00:24] <superdump> nevermind [11:42:58] <cartman> when converting YUV420P to RGB, should I convert it to YUV444 packed first? [11:43:09] <av500> ?? [11:43:16] <kshishkov> of course not [11:43:43] <spaam> first to YUV444 then back to YUV444p then RGP.. [11:44:15] <cartman> I should have known not to trust Microsoft (ref. http://msdn.microsoft.com/en-us/library/ms893078 ) [11:44:18] <av500> and some HSV000 inbetween? [11:44:27] <cartman> To convert 4:2:0 or 4:2:2 YUV to RGB, convert the YUV data to 4:4:4 YUV, and then convert from 4:4:4 YUV to RGB. [11:44:38] <spaam> av500: yes. [11:47:37] <j-b> anyone around FFmpeg that is from NetFlix©® ? [11:48:08] <cartman> Consider I have a YUV420P sample.yuv file I can create Y,U,V arrays by directly reading from the file [11:48:19] <cartman> then I'd have to match (U,V) tuples for each Y value [11:48:46] <cartman> or I could read the whole file into an array and setup Y,U,V arrays [11:49:15] <cartman> but then U and V values would be duplicated [11:49:47] <cartman> is that OK? Was my question clear? :) [11:50:23] <wbs> cartman: just iterate through two Y-rows, one U-row and one V-row at the same time, then you get Y,U,V-tuples [11:50:31] <wbs> cartman: then convert each YUV-tuple into RGB and store into the output [11:51:05] <wbs> cartman: so if you want to see it that way, it is converted to yuv444 inbetween, but that version isn't stored anywhere [11:51:27] <cartman> wbs: that was what I am asking, thanks :) [11:51:44] <cartman> so its actually converted :) [11:53:35] <lu_zero> cartman: reading swscale won't help? [11:53:48] <cartman> lu_zero: too complex for learning basics :) [11:54:02] <wbs> lu_zero: I don't think swscale is the best/most pedagogic introduction into the subject :-) [12:00:58] <lu_zero> wbs: the loop code in C should be simple [12:01:14] <wbs> lu_zero: probably, but finding it if you're totally new to the subject isn't easy [12:01:27] <wbs> and you'll be scared off long before you've found that loop :-) [12:01:29] <lu_zero> ^^; [12:01:54] <kshishkov> I wasn't [12:03:04] <lu_zero> libswscale/yuv2rgb.c is yours isn't it? [12:09:24] <kshishkov> lu_zero: no, it's FFmpeg's [12:09:47] <av500> no it's lu_zero's now [12:23:08] <lu_zero> av500: luckily not =P [12:23:16] <lu_zero> kshishkov: I mean you wrote it last time [12:23:28] <kshishkov> lu_zero: so what? [12:23:40] <lu_zero> so you can tell cartman where to look inside it ^^; [12:23:41] <kshishkov> lu_zero: I've looked at the previous version too [12:27:21] <lu_zero> I see [12:58:06] <mru> merbanan: seen fate recently? [13:00:28] <kshishkov> mru: is "Â±" sign is that you may get warnings more or less? [13:00:39] <mru> click and see [13:01:11] <kshishkov> first five configs are empty [13:01:42] <mru> it gives you a diff from the previous compile log [13:01:56] <kshishkov> sucks with tmpnames though :( [13:02:49] <kshishkov> still, it's a nice feature [13:04:31] <av500> the +/- gives empty pages here :( [13:04:46] <mru> there was no change there [13:05:17] <av500> is should say :"this webpage intentionally left blank" [13:06:25] <av500> hmm, most diffs seems to be -j N related [13:06:36] <mru> yes, I'm afraid so [13:07:29] <av500> ca we blame drepper? [13:07:31] <av500> can [13:07:40] <mru> I don't think so [13:07:50] <mru> make -jN isn't deterministic [13:07:57] <mru> especially not on a busy system [13:08:09] <av500> i know :) [13:09:12] <av500> what is the new policy on warnings? [13:09:28] <kshishkov> avoid them unless it's gcc farts? [13:09:50] <mru> fix the cause, not the warning [13:11:07] <av500> kshishkov: http://fate.ffmpeg.org/?dsort=nwarn [13:11:10] <av500> not just gcc :) [13:12:46] <mru> it's not so strange that the more obscure systems and compilers show more warnings [13:12:50] <kshishkov> but it definitely leads the way [13:13:13] <av500> there are 2 entries without warnings shown [13:13:17] <av500> but they have some [13:13:48] <mru> they haven't reported since the warning count was added [13:13:53] <av500> ah [13:14:16] <av500> cartman: ^^^ get your fate up to speed [13:15:07] <cartman> av500: wut [13:15:14] <cartman> I already FATEd in the morning [13:15:25] <av500> fainted maybe? [13:15:30] <cartman> http://fate.ffmpeg.org/x86_64-apple-darwin10-clang [13:16:42] <av500> this not yours: http://fate.ffmpeg.org/opensuse-factory-clang ? [13:16:54] * cartman hides [13:17:20] <cartman> binutils 2.21 has a new ld bug, goes out of memory while linking llvm [13:17:24] <cartman> thats why [13:23:07] <lu_zero> ? [13:23:13] <lu_zero> binutil or llvm? [13:23:20] <cartman> lu_zero: binutils [13:23:26] <lu_zero> gold or plain? [13:23:29] <cartman> plain [13:24:32] <j-b> mru: I don't want to say bad things of my friends from India, but I believe this is crap [13:24:45] <lu_zero> which? [13:27:42] <kshishkov> j-b: your friends from India working on VLC or on Symbian? [13:27:53] <av500> both [13:28:05] <av500> getting vlc into the OVI store [13:28:17] <kierank> I was surprised how big OVI store is [13:28:25] <lu_zero> Compn: "original" doesn't sound correct to me. [13:28:25] <av500> how big? [13:28:47] <j-b> quite big, in Asia [13:28:53] <kierank> http://thenextweb.com/asia/2011/01/20/nokia-ovi-store-is-the-top-applicatio… [13:29:10] <j-b> mru: anyway, the only actual Symbian Expert I know is a FFmpeg developer: wbs [13:29:53] <kierank> what about courmisch? [13:31:24] <j-b> courmisch doesn't do any Symbian work [13:31:29] <j-b> he says: it's crap [13:31:35] <kierank> i see [13:31:42] <av500> he is right :) [13:31:49] <j-b> the cool thing about working on Symbian is that: if we fail, noone will care :) [13:31:55] <mru> I have a theory for how this has happened [13:31:58] <wbs> j-b: lol [13:32:17] <j-b> but if it works, that will be cool [13:32:38] <j-b> however, VLC on Symbian will have almost no codec/no demuxer except ffmpeg [13:33:09] <av500> j-b: er, what other do you need? [13:33:32] <j-b> av500: tremor, probably [13:33:55] <av500> and you fail to compile that for symbian? [13:34:13] <kshishkov> j-b: sponsor intger-only decoding for lavc audio ;) [13:34:36] * av500 is reminded that he still drag thats integer cook patch around [13:34:39] <av500> +s [13:34:51] <wbs> av500: who uses cook? [13:34:57] <j-b> kshishkov: well, we could make VLC on OVI a paid app and then sponssor it, not stupid idea [13:34:58] <av500> wbs: RA? [13:35:12] <wbs> av500: eww [13:35:17] <av500> wbs: cook is real audio [13:35:23] <wbs> av500: IC [13:35:52] <av500> i guess I could use the float cook on the omap3, I just have the integer patch for historic reasons :) [13:36:03] <av500> and I like keeping it alive [13:38:34] <j-b> mru: anyway, only wbs can tell us what the true solution is [13:39:10] <Compn> lu_zero : suggestions welcome [13:39:29] <Compn> lu_zero : note i didnt ask michael what he wanted so its just what came out of my head :p [13:40:59] <mru> I suspect the loader doesn't allow resolving a non-call address against the plt [13:44:03] <wbs> I'll try to dig into the area a bit [13:46:17] * kshishkov gives wbs traditional Russian weapon [13:46:29] <cartman> http://fate.ffmpeg.org/opensuse-factory-clang updated [13:46:30] <pJok> vodka bottle? [13:46:34] <av500> shovel [13:46:45] <kshishkov> see, even av500 knows that [13:46:55] <av500> cartman: 208 warnings, rejected! [13:47:06] <cartman> av500: better than gcc.com [13:47:10] <av500> kshishkov: been here too long... [13:47:34] <kshishkov> av500: not long enough - you still don't speak Turkish [13:47:59] <kshishkov> or for other value of "here" - you still don't speak Swedish [13:48:18] <lu_zero> nor Japanese [13:48:53] * pJok speaks swedish, is working on the japanese part [13:48:55] * lu_zero should keep studying swedish [13:49:13] * kshishkov should too but he's distracted by German [13:50:10] <mru> now where's that page listing dangerous swedish homophones? [13:50:31] <mru> kshishkov: german and swedish are almost the same thing :) [13:50:38] <cartman> homophone? [13:50:41] <cartman> a new smartphone? [13:51:04] <kshishkov> mru: http://sv.wikipedia.org/wiki/Lista_%C3%B6ver_falska_v%C3%A4nner_mellan_sven… [13:51:30] <thresh> kshishkov: http://www.putingoodbye.ru/ [13:51:37] <kshishkov> mru: Swedish sounds much nicer than German, has simpler grammar and shorter words [13:51:57] <kshishkov> thresh: Ð·Ð° Ð²Ð°ÐŒÐž ÑÐ¶Ðµ Ð²ÑÐµÑÐ°Ð»Ðž [13:52:43] <kshishkov> cartman: the things that sounds similar, like "meet" and "meat" [13:53:29] <mru> kshishkov: DonaudampfschiffahrtselektrizitÃ€tenhauptbetriebswerkbauunterbeamtengesellschaft [13:53:32] <lu_zero> then the best will be using runes to write in japanese the ffmpeg documentation [13:53:53] <lu_zero> mru: what's that? [13:53:58] <av500> a word [13:54:01] <lu_zero> I quitted parsing it halfway [13:54:19] <kshishkov> mru: http://en.wikipedia.org/wiki/Rinderkennzeichnungs-_und_Rindfleischetikettie… [13:54:27] <cartman> wbs: now I am able to produce my colors-are-drunk image again :D [13:54:36] <cartman> I guess the U/V formula is fucked up [13:54:37] <mru> translation: Association for subordinate officials of the head office management of the Danube steamboat electrical services [13:55:04] <av500> kshishkov: this one is nice [13:55:11] <kshishkov> yes, it's popular root to produce even shorter words [13:55:18] <kshishkov> av500: and it's legal! [13:55:20] <mru> kshishkov: NordÃ¶stersjÃ¶kustartilleriflygspaningssimulatoranlÃ€ggningsmaterielunderhÃ¥llsuppfÃ¶ljningssystemdiskussionsinlÃ€ggsfÃ¶rberedelsearbeten [13:55:58] <lu_zero> mru: made up? [13:56:05] <kshishkov> mru: google refuses to acknowledge its existence [13:56:23] <mru> lu_zero: yes [13:56:41] <lu_zero> google thinks its Norwegian [13:56:53] <lu_zero> but couldn't get the meaning [13:56:56] <kshishkov> maybe it's Fenno-Swedish [13:56:57] <JEEB> jÃ€rjestelmÃ€llisentelentelemÃ€ttÃ¶myydellÃ€nsÃ€kÃ€Ã€n â without putting together multiple words (not yhdyssana) [13:57:32] <JEEB> (yes, that's the Finnish word 'järjestelmällisyys' with a lot of informative endings) [13:58:45] <JEEB> with putting together a compound word you can make a real word in Finnish that's as long if not even longer than what mru's saying :3 [13:58:51] <pross-au> Please use hyphenation :P [13:59:09] <merbzt> mru: that symbian patch, I see no way to work around the linker issue cleanly [13:59:12] <mru> pross-au: like this? Ã¶sszetettszÃ³hosszÃºsÃ¡gvilÃ¡grekorddÃ¶ntÃ©skÃ©nyszerneurÃ³zistÃŒnetegyÃŒttes-megnyilvÃ¡nulÃ¡sfejleszthetÅsÃ©gvizsgÃ¡latszervezÃ©sellenÅrzÃ©siÃŒgyosztÃ¡ly-lÃ©tszÃ¡mleÃ©pÃtÃ©sellenesakciÃ³csoporttagsÃ¡giigazolvÃ¡nymegÃºjÃtÃ¡sikÃ©relem-elutasÃtÃ³hatÃ¡rozatgyÅ±jtemÃ©nyÃ©rtÃ©kesÃtÅnagyvÃ¡llalatÃ¡talakÃtÃ¡sutÃ³-finanszÃrozÃ¡spÃ¡lyÃ¡zatelbÃrÃ¡lÃ³alapÃtvÃ¡nykuratÃ³riumelnÃ¶khelyettesellenes-merÃ©nyletkivizsgÃ¡lÃ³bizottsÃ¡giÃŒlÃ© [13:59:31] <pross-au> does that gunzip to something? [13:59:34] <JEEB> lol [13:59:35] <mru> merbzt: fix the linker? [13:59:38] <kshishkov> mru: elenril would call it The True Black Speech (aka Hungarian) [13:59:46] <pross-au> Night [14:00:16] <merbzt> mru: yeah, hard to do on a symbian phone, buy the next one in the series I guess [14:00:40] <av500> merbzt: just send it the SMS-o-death [14:01:20] <kierank> av500: same goes for the base station [14:07:14] <cartman> there are many YUV->RGB matrices and most are not compatible [14:07:18] <cartman> why tf? :) [14:07:33] <mru> that's the good thing about standards, so many to choose from [14:07:35] <cartman> compatible as in give completely unrelated values for the same YUV input [14:08:34] <cartman> http://cekirdek.pardus.org.tr/~ismail/4.png but my colors are f*cked up now [14:09:14] <mru> and saturated [14:09:43] * cartman wonders if he is writing the RGB24 file wrong [14:10:16] <kshishkov> cartman: at least it should convince mru there are worse things than swscaler [14:10:30] <cartman> kshishkov: heheh [14:10:54] <mru> anyway, we have a patch queue to review [14:11:08] <av500> kshishkov: we should commits cartman's code as-in and clean later! [14:11:24] <av500> libavlsd maybe? [14:11:33] * kshishkov nominates av500 into next Michael [14:11:51] <kshishkov> bonus points for creating new library [14:11:57] <cartman> stop mocking I am trying to learn here ;) [14:11:58] <av500> I did [14:12:06] <av500> cartman: you learn, we mock [14:12:08] <av500> that is the deal [14:12:21] <cartman> av500: speculate on colors first [14:12:22] <cartman> :P [14:12:25] <cartman> then you can mock [14:12:29] <kshishkov> cartman: that's called learning with negative stimulus [14:13:02] <av500> cartman: sorry, but why dont you take a few known yuv values and check your rgb output for them? [14:13:14] <mru> like 0,0,0 [14:13:19] <mru> should give green [14:13:25] <av500> instead of your randon coefficient approach [14:13:26] <cartman> av500: that would make sense if there is a common YUV<->RGB mapping [14:13:32] <kshishkov> cartman: is that too hard to take input YUV, multiply it by any set of coefficients given in Wikipedia and output RGB triplets in PPM file? [14:13:36] <av500> cartman: they should be similar [14:13:42] <mru> av500: he does programming by the monte carlo method [14:13:46] <cartman> kshishkov: thats what I did :) [14:13:50] <Kovensky> av500: no, no, name it libsd instead [14:14:03] <av500> Kovensky: right! [14:14:08] <kshishkov> cartman: show teh codez [14:14:20] * av500 assumes rand() is involved [14:14:34] <kshishkov> cartman: if that's what you get with plain C you're really screwed [14:14:45] <cartman> http://cekirdek.pardus.org.tr/~ismail/yuv2rgb.c [14:15:16] <mru> float?!?!!!!! [14:15:33] <cartman> calm down mru :P [14:16:51] <kshishkov> cartman: I hope you remember UV is signed [14:16:52] <av500> cartman: wtf with all the fseeks? [14:17:06] <kshishkov> av500: that's putpixel() calls :) [14:17:08] <Kovensky> mmap man, mmap! [14:17:25] <cartman> av500: those are unrelated to the problem [14:17:41] <av500> ah, this isn't perl code... [14:17:43] <cartman> kshishkov: I use uint8_t for them [14:18:08] <kshishkov> cartman: try subtracting 128 from U/V during conversion [14:18:18] <cartman> signed [14:18:19] <cartman> uhm [14:18:23] <cartman> f..k [14:18:26] <mru> can we tag the ancient patches vitor sent so they don't clutter up the patchwork view so badly? [14:18:34] <kshishkov> av500: be proud he's agreed working for you! [14:18:35] <cartman> mru: reject them [14:18:49] <mru> there's this 'archive' option [14:18:52] <mru> what does that do? [14:18:59] <av500> kshishkov: not yet :) [14:19:00] <kshishkov> cartman: it's stored as unsigned but with 128 bias [14:19:42] <cartman> kshishkov: U,V -= 128 before processing? [14:19:50] <mru> yes [14:19:51] <kshishkov> yep [14:20:03] <kshishkov> and don't store them back to uint8_t [14:20:05] <cartman> different bad colors but not saturated it seems [14:20:29] <mru> ok, I'm setting these old patches to state "RFC" [14:20:34] <cartman> kshishkov: what should I store them into? [14:20:42] <kshishkov> cartman: int [14:21:05] <cartman> http://cekirdek.pardus.org.tr/~ismail/5.png with the -= 128 [14:22:02] <av500> cartman: please, do the math by hand for a few values [14:22:19] <wbs> cartman: you can't do -= 128 on an uint8_t and expect it to turn out right ;P [14:22:31] <wbs> (unless you really want the wraparound) [14:22:44] <cartman> kshishkov: thanks [14:23:07] <kshishkov> mru: at least you haven't complained about him using for (int i = 0; ...) in C [14:23:16] <cartman> kshishkov: thats valid in C99 [14:23:17] <mru> that is c99 [14:23:36] <cartman> kshishkov: http://cekirdek.pardus.org.tr/~ismail/6.png [14:23:37] <mru> and the one case of declaration not at start of block I actually like [14:23:40] <cartman> so there it is :P [14:23:56] <mru> now you're getting somewhere [14:24:03] <cartman> is the same as original :D [14:24:11] <av500> it still does not look like anything... [14:24:19] <cartman> av500: a frame from a movie [14:24:25] <wbs> av500: that's the most legal kind of porn in turkey [14:24:46] <cartman> ~70 lines of code, endless mocking [14:24:50] <av500> ah, frak, the boss just walked in [14:24:51] <cartman> worth the outcome :p [14:25:08] <lu_zero> cartman: enjoy! [14:25:09] <av500> "is that turkish porn on your screen!" [14:25:17] <cartman> lu_zero: thanks :) [14:25:23] <lu_zero> now you can help with swscale [14:25:34] <lu_zero> =) [14:25:35] <cartman> lu_zero: I am getting mocked enough [14:25:36] <cartman> :P [14:25:49] <av500> cartman: now please rewrite it without the seeks [14:26:00] <cartman> av500: I don't know how, yet. [14:26:21] <av500> cartman: buffer one line [14:26:39] <cartman> kshishkov: Y has 16 bias too? [14:26:42] <av500> er, wait, no buffer [14:26:53] <kshishkov> cartman: depends on colourspace details [14:27:09] <cartman> kshishkov: ah is it easy to detect if thats needed? [14:27:24] <kshishkov> probably [14:27:38] <av500> well [14:27:41] <kshishkov> JPEG doesn't have it, MPEG has, something like that [14:27:46] <mru> you can make a guess [14:27:47] <av500> if Y is 0-255 [14:27:55] <av500> you can assume its the full range [14:28:13] <mru> if you see values outside 16-240, you can assume it's full range [14:28:19] <mru> or a sloppy decoder [14:28:36] <mru> if you don't see any such values, you can't know for sure [14:28:46] <cartman> and if its full range? [14:28:59] <mru> if it's full range you use different coeffs [14:29:12] <mru> if reduced, you subtract 16 from y and use another set of coeffs [14:29:34] <cartman> and these coeffs are different everywhere? :) [14:29:49] <mru> those are the matrixes you mentioned before [14:30:10] <cartman> yeah everyone seems to have a different set of one as to simplify the operations [14:31:49] <cartman> Wikipedia seems to explain this in YUV444 section instead. [14:33:08] <cartman> mru: since floats made you scream, should I use fixed-point coefficients instead? [14:33:15] <mru> subsampling and packing has nothing to do with it [14:33:19] <cartman> av500: and whats the fseek replacement here? :) [14:33:24] <av500> ? [14:33:29] <av500> write one line at a time [14:33:30] <mru> and of course use fixed-point [14:33:50] <cartman> av500: but I am traversing two rows at a time [14:33:55] <mru> multiply the coeffs by something suitably large and shift at the end [14:34:08] <av500> cartman: so? [14:34:17] <cartman> mru: makes sense [14:34:47] <cartman> av500: so buffer them all and write at once? [14:34:49] <av500> cartman: convert 2 lines in memory and then write them out [14:35:04] <av500> the write out part is for your test case only anyway... [14:35:24] <av500> cartman: or even better, write a full mem2mem converter [14:35:29] <kshishkov> or traverse one row at a time, just update UV pointers [14:35:30] <av500> coz that is what you are after, no? [14:35:32] <cartman> av500: yeah still learning efficent ways is good [14:36:01] <av500> cartman: or write the even and odds row to different files and call it RGB interlaced... [14:36:07] <cartman> av500: true, writing to a file is not interesting for my problem [14:36:52] <cartman> ok thank you [14:37:15] <kshishkov> av500: thank you for introducing yet another pointless interlaced format! [14:37:39] <cartman> lets efficient disk usage :P [14:37:48] <lu_zero> kshishkov: he could propose vertical interlacing [14:38:06] <kshishkov> lu_zero: diagonal [14:38:20] <lu_zero> kshishkov: diagonal is tricky [14:38:36] <lu_zero> 3x the aliasing I guess [14:39:06] <kshishkov> lu_zero: not at all - just swap every 2x2 block from (a, b; c, d) to (a, c; d, b) [14:39:18] <av500> kshishkov: tiled interlacing [14:39:36] <kshishkov> av500: indeed [14:39:55] <Tjoppen> wasn't there some tv engineer in the 50s that invented triple interlacing? [14:39:56] <kshishkov> I'd call it Russian interlacing - senseless and ruthless [14:40:19] <Tjoppen> I recall reading somewhere that it made 600 lines possible [14:43:21] <mru> 200 lines per field? [14:43:40] * cartman notes that NTSC coefficients work as expected too [14:43:40] <kshishkov> per component [14:44:54] <av500> http://en.wikipedia.org/wiki/Nipkow_disk [14:45:26] <av500> this russian? [14:46:55] <av500> oh, not a russian at all [14:47:36] <Tjoppen> ah, electromechanical TV. how wonderful [14:47:52] <Tjoppen> didn't bbc broadcast for those early on? vertical lines as well [14:52:01] <mru> anyone with some neon knowledge care to look at http://patches.ffmpeg.org/patch/484/ ? [14:52:25] <av500> mru: ^^^ [14:53:26] <kshishkov> mru: why change registers along with instructions? [14:53:52] <kshishkov> mru: ah, I see [14:54:22] <kshishkov> mru: looks rather trivial and OK for me [14:54:41] <mru> kshishkov: I know it works [14:54:49] <mru> but I need an OK on the ml [14:55:03] <kshishkov> isn't OK on IRC enough? [14:55:34] <mru> we're trying to keep some kind of record [14:56:13] <kshishkov> ok [14:58:22] <lu_zero> I thought I ok'd it before... [14:58:45] * lu_zero spent some time to doublecheck the instructions just in case [14:58:52] * lu_zero needs to recover =_= [14:59:07] <mru> lu_zero: gmane has no record of you replying to that patch [15:00:27] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r78f318be59 ffmpeg/libavcodec/arm/h264pred_neon.S: [15:00:27] <CIA-43> ffmpeg: ARM: NEON: fix overflow in h264 16x16 planar pred [15:00:27] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:07:17] <cartman> ugh bombing in Russia [15:07:32] <kshishkov> *yawn* [15:09:15] <cartman> hello h [15:09:19] <cartman> hello hijacker forkers [15:09:24] <cartman> sounds like terrorists [15:10:24] <spaam> cartman: why did you bomb it ? [15:10:31] <cartman> spaam: it was kshishkov [15:10:37] <cartman> kshishkov: Allah Akbar! [15:11:07] <kshishkov> cartman: here it's inappropriate [15:11:10] <mru> some kurds who used to live next-door to me would play a song where the lyrics sounded just like "kill all the russians" [15:11:12] <cartman> kshishkov: :( [15:11:22] <mru> it was probably kurdish and meant something rather more harmless [15:11:25] <cartman> mru: and not Turks? [15:11:39] <av500> mru: "kill all turks" I guess [15:11:42] <kshishkov> spaam: well, maybe you'll get less tourists from Moscow and Russia for some time (which is always good) [15:12:04] <cartman> Most of the Kurdish people living in *.se and *.be is likely to be in Turkey's terrorist watchlist [15:12:07] <cartman> weheee [15:21:01] <cartman> MN is outperforming himself [15:21:24] <cartman> "i dont like you mans but i agree this is crazy" [15:26:52] <mru> apparently it offended him that I reviewed a few patches/commits of his [15:27:04] <mru> with the same level of scrutiny applied to others [15:27:10] <DonDiego> where did you do that? [15:27:23] <mru> last summer on the ml [15:30:18] <lu_zero> wonderful... [15:31:44] <spaam> ? :) [15:41:23] <lu_zero> spaam: re-routed... [15:49:11] <arpi_mphq> hi [15:49:30] <mru> hi, long time no see [15:49:55] <cartman> offerred money to work with the other side? [15:50:05] <mru> I am not aware of any such offer [15:50:18] <mru> and if one were made, I would be [15:50:19] <cartman> must be a Nigerian developer [15:51:05] * cartman resists answering the mail [15:51:18] <elenril> wow [15:51:26] <mru> please all stay calm [15:51:40] <DonDiego> arpi_mphq: doh, long time no see.. - hi [15:51:45] <cartman> arpi_mphq: lose the _mphq already :) [15:51:48] <lu_zero> hi! [15:52:02] <DonDiego> arpi_mphq: still sporting a moustache? :) [15:53:24] <lu_zero> oh [15:53:54] <lu_zero> av500: do you have the latest vote count numbers at hand btw? [15:54:16] <av500> lu_zero: that pastebin is still "out there" [15:54:28] <lu_zero> which one? [15:54:40] <lu_zero> I'd like to append that to my pastebin [15:54:52] <cartman> your pastebin should call my pastebin [15:54:57] <lu_zero> I'm sick of reading hijack, coup and such [15:55:15] <cartman> tell MN he should be a politician in Turkey [15:55:18] <cartman> will work out great [15:55:18] <av500> lu_zero: it wasa coup :) [15:55:45] <av500> cartman: updated c file? [15:56:02] <kshishkov> lu_zero: "latest vote count" sounds like "latest Debian stable" [15:56:17] <lu_zero> kshishkov: please =P [15:56:27] <cartman> av500: wut file [15:56:31] <lu_zero> av500: not that much [15:56:40] <lu_zero> it's the normal outcome of the election [15:56:59] <lu_zero> C: change or get demoted [15:57:02] <arpi_mphq> why? 16:55 < cartman> tell MN he should be a politician in Turkey [15:57:03] <superdump> mru: i'm calm, but this is rather strange and not really credible to me - do you have any idea what's going on? [15:57:12] <mru> no [15:57:12] <superdump> hello arpi_mphq [15:57:17] <merbzt> DonDiego: did you create a fltter account for FFmpeg ? [15:57:20] <cartman> arpi_mphq: if you tell lies like this + coups etc you fit Turkey [15:57:25] <mru> superdump: and I'm a director in the foundation [15:57:25] <cartman> it happens everyday here [15:57:31] <mru> I should know about anything like that [15:57:43] <arpi_mphq> cartman: what lies? [15:57:59] <kshishkov> arpi_mphq: BTW, what led your feet to this channel? [15:58:10] <cartman> arpi_mphq: MN's last post is a blatant lie unless backed up by evidence [15:58:26] <arpi_mphq> kshishkov: i was curoius what the neu team does now after losing the best developers [15:58:37] <DonDiego> cartman: no fanning of flames please [15:58:46] <arpi_mphq> cartman: which post? too much to read all [15:58:46] <cartman> neu team doesn't develop on the beach anymore :P [15:58:48] <lu_zero> arpi_mphq: having fun fixing and introducing new bugs [15:58:50] <kshishkov> arpi_mphq: who are they? Name three or four [15:58:52] <mru> the foundation is sponsoring ruggles to work ac3enc [15:59:00] <cartman> arpi_mphq: someone tried to bribe someone to join neu team [15:59:08] <mru> but that's hardly what that email says [15:59:14] <kshishkov> allegedly [15:59:30] <DonDiego> merbzt: not yet, but i finally added the mplayer flattr button to the mplayer homepage [15:59:33] <kierank> kshishkov: ian hislop quote [16:00:13] <spaam> mru: going to tell MN about that? :) [16:00:14] <superdump> i assume michael isn't talking about himself indirectly and that none of the 'new team' have offered michael money [16:00:18] <arpi_mphq> cartman: it was not originated from MN [16:00:22] <kshishkov> kierank: ? [16:00:23] <mru> spaam: tell him what? [16:00:40] <cartman> arpi_mphq: its useless without evidence [16:00:40] <mru> spaam: michael is a director of the foundation, he knows everything it does [16:00:48] <cartman> Nigerian scammers offer 300.000$ everyday [16:00:50] <spaam> mru: about the foundation sponsring ruggles.. [16:00:59] <spaam> mru: ah ok [16:01:05] <DonDiego> merbzt: should i just create the flattr button through my flattr account or do we setup something through the foundation? i'm not sure if such a foundation account is possible, however... [16:01:06] <kierank> kshishkov: he's editor of a newspaper here who's been sued for libel so many times. On TV he always says something happened...allegedly [16:01:17] <mru> spaam: and that was decided a long time ago [16:01:47] <spaam> mru: ah that explains some stuff :) [16:01:53] <lu_zero> DonDiego: not sure what works best [16:02:00] <kshishkov> mru: wasn't it more about recruiting new devs with foundation money behind his back? [16:02:14] <mru> kshishkov: that hasn't happened [16:02:15] <av500> kshishkov: I never got anything offered :( [16:02:26] <cartman> av500: we were all bribed [16:02:47] <av500> cartman: you was bribed to start work on libswscale2 [16:02:49] <DonDiego> lu_zero: me neither, i can try to investigate if it's possible... [16:02:54] <av500> one can clearly see that [16:02:57] <cartman> av500: sure sure [16:03:01] <DonDiego> why wasn't i bribed? [16:03:20] <av500> DonDiego: your status as poor student could not be endangered [16:03:21] <cartman> we were all bribed with the promise of friendliness ;P [16:03:22] <lu_zero> DonDiego: you were the one bribing [16:03:30] * elenril should have asked KotH for some chocolate in exchange for joining [16:03:34] <DonDiego> i'm piss-poor, at least i wouldn't waste the money on a new yacht ... [16:03:43] <av500> elenril: he did *not* offer you some? [16:03:53] * Compn replies to michael [16:03:58] <elenril> av500: see how evil he is! [16:04:02] * av500 munches on chocolate [16:04:06] <DonDiego> ok, enough fun, i have some work to do here.. [16:04:11] <spaam> av500: KotH want all his chocolate for himself.. [16:04:17] <elenril> av500: go review my patches [16:04:30] <DonDiego> @everybody: shut up and drop the subject, you have already been trolled into replying and wasting time [16:04:50] <av500> thats what I came here for! [16:05:07] * cartman goes back to slacking [16:05:33] <arpi_mphq> good luck assholes [16:05:37] <spaam> haha [16:05:39] <cartman> LOL [16:05:41] <ubitux> :s [16:05:41] <lu_zero> uhm [16:05:42] <av500> lol [16:05:46] <kshishkov> thanks for his kind words [16:05:46] <mru> same old arpi [16:05:54] <lu_zero> I wonder what he really wanted [16:06:03] <av500> lu_zero: to say assholes [16:06:06] * elenril hoped for a better troll [16:06:08] <lu_zero> ah [16:06:24] <cartman> he was here for the teh neu codez [16:07:03] <lu_zero> all in the git =P [16:07:14] <cartman> except my super duper yuv2rgb.c :P [16:07:14] <kshishkov> spaam, kierank: why does his nick reminds me of Basty? [16:07:44] <kierank> who's nick? [16:07:46] <kierank> whose* [16:07:50] <kshishkov> cartman: my humble yuv2rgb.c was eventually accepted into SwS, so you still have a lot to achieve [16:07:59] <kshishkov> kierank: arpi_mphq [16:08:07] <spaam> kshishkov: i dont know. [16:08:29] <kierank> MPHQ is an amiga group [16:08:31] <cartman> kshishkov: nah all I need is to hookup it with omapfbplay and I'll be done [16:08:33] <kierank> haven't you haearD? [16:09:50] <kshishkov> kierank: well, I remember seeing one gross enourmous pile of hacks there and it was not libavseq [16:10:38] <lu_zero> I didn't grasp exactly the extents of what was the proposed libavseq [16:10:53] <kshishkov> lu_zero: an engine for tracker and MIDI files [16:10:59] <av500> lu_zero: is there a need to grasp it now? [16:11:10] <lu_zero> av500: I'd let it alone [16:12:09] <merbzt> DonDiego: create it with your own account [16:12:19] <spaam> lu_zero: with avseq ffmpeg will grow twice the size in code.. and kierank can play his amiga stuff ;D [16:13:15] <merbzt> amiga !!!! [16:14:50] <BBB> wbs: how did you do the undo_setup()? (I didnt' check the patch yet) [16:14:54] <BBB> wbs: was TEARDOWN enough? [16:15:14] <kshishkov> merbzt: have you convinced someone to finish REing those video files from Cryo? [16:15:38] <merbzt> I thought I convinced you ... [16:16:10] <kshishkov> well, now convince my free time, I'd gladly work on it (eventually) [16:16:25] <Tjoppen> ah, DVCPRO HD is specified in S370m. I almost feel like fixing lavc's encoder (it messes up the AC encoding) [16:17:05] <Tjoppen> it's a little annoying that it can encode everything else :o [16:17:09] <merbzt> Tjoppen: afaik the encoder was never committed [16:17:28] <merbzt> dvcpro hd 100 or something [16:18:16] <Tjoppen> ah. because it looks like it "almost" working. meaning it outputs something that looks sort of right except the AC is inverted or something [16:19:12] <spaam> Tjoppen: fixa det . kshishkov bjuder pÃ¥ trocadero om du gÃ¶r det [16:19:53] <Tjoppen> :) [16:19:57] <Tjoppen> are the patches around somewhere? [16:20:07] <merbzt> Tjoppen: look back in the mail history, I think the guy behind mars digital coded it up and I think Roman tried to get it included but never finished it [16:20:22] <merbzt> rsv@sun me thinks [16:20:34] <merbzt> rebase and send it again IIRC [16:20:44] <merbzt> then patchwork will find it [16:22:43] <Tjoppen> I see the thread for the decoder. I'll have to google around a bit more for the encoder [16:23:53] <mru> hmm, a TI dsp compiler has an int40_t type [16:24:13] <Flameeyes> 40? o_O [16:24:24] <mru> apparently it supports 40-bit ints [16:24:27] <superdump> awesome [16:24:43] <av500> 8 bit ecc info [16:24:50] <mru> :) [16:25:07] <av500> mru: or its used to fix that gcc float bug [16:25:45] <mru> and they claim to have finally fixed designated initializers for unions [16:25:50] <mru> compiler used to crash on those [16:26:11] <av500> wrt symbian, sin() as a macro? [16:26:21] <mru> sin() might be a macro, sin is not [16:26:39] <mru> it wouldn't compile if it were [16:27:00] <mru> spec says "The following shall be declared as functions and may also be defined as macros" [16:27:05] <mru> then lists all the math.h functions [16:27:34] <av500> #define sin(x) x // works for me for small x [16:27:37] <kshishkov> mru: and we have 80-bit lagarith_state_t on x87 [16:27:53] <mru> kshishkov: that's floating point [16:28:09] <mru> some TI dsps have 40-bit integers [16:29:17] <kshishkov> yes, but I don't see principal difference between them - both are weird nonportable types [16:34:55] <Compn> isnt there some ffmpeg rule about not having OS hacks ? [16:35:09] <Compn> e.g. for symbian or mingw or bsd or anything [16:35:20] <mru> they should be kep to a minimum and isolated from real code [16:35:31] <av500> fflibm [16:35:34] <av500> er, libavm [16:35:44] <Compn> wasnt there a liboshacks or something [16:35:47] <Compn> where did that go [16:35:55] <av500> it was discussed [16:37:48] <Flameeyes> mru: about the unversioned symbols I noted... [16:37:57] <mru> go on [16:40:11] <Flameeyes> what's the plan? [16:40:20] <mru> find the bug and fix it [16:40:36] <mru> which .so has the bad symbols? [16:42:55] <Flameeyes> avformat and avcodec â want me to send a patch to simply version them in the future (accepting the issue is still present in git, need to check that) [16:43:33] <mru> do you know why they are missing a version? [16:44:33] <Flameeyes> haven't looked into that, was wondering if you had an idea already â will look into it now, I guess it's as good a time as any other to convert the stuff I had in the old ffmpeg git clone to the official git [16:44:54] <siretart> Flameeyes: sorry for not getting earlier at it, I've got caught up at work here [16:45:01] <Flameeyes> siretart: don't worry :) [16:45:22] <mru> Flameeyes: the libavcodec version script is quite simple [16:45:28] <mru> I don't see how it could miss a few symbols [16:45:36] * Flameeyes has some free time, waiting for IBM people to answer him [16:45:41] <Tjoppen> found the dvcpro hd patches [16:45:42] <mru> it has a single global: * directive [16:45:58] <siretart> btw, my plan to have daily builds of ffmpeg worked out: https://code.launchpad.net/~motumedia/+recipe/ffmpeg-daily \o/ :-) [16:46:58] <mru> nice [16:47:23] <mru> but please, must you call it 0.7? [16:47:26] <av500> mru: another SW soon only be had from ubuntu PPA ;) [16:47:28] <mru> there is no 0.7 [16:48:06] <wbs> BBB: no, it just clears the data structures. TEARDOWN makes the server close the control channel on DSS and ms-rtsp servers [16:48:19] <spaam> mru: maybe you should give him a better name for it ? [16:48:38] <wbs> BBB: (but teardown helps a bit on real-rtsp, although I havent got that working fully yet) [16:49:24] <Flameeyes> mru: uhm I think I know why it happens: they seem all to be common symbols (.bss) [16:49:42] <siretart> mru: what else shall I call it? [16:49:50] <mru> siretart: good question [16:50:19] <spaam> siretart: mru_allstars [16:50:22] <siretart> it is called 0.7~~ to indicate that it is a pre-pre version of what will end in 0.7 [16:50:40] <mru> what kind of naming convention is that? [16:51:15] <siretart> a weird one. in the dpkg version comparision algorithm, the '~' directive roughly means "earlier" [16:51:26] <lu_zero> Flameeyes: cough [16:51:49] <thresh> mru: why do you care? You're not using debian AFAIR, and debian users know what that means :) [16:52:17] <av500> but it might never be 0.7 if we fork again :) [16:52:35] <siretart> it will be superseeded by any 'real' 0.7 distro package [16:52:40] <thresh> I'm pretty sure it's possible to override the version then :) [16:53:19] <Flameeyes> lu_zero: uhm? [16:53:23] <siretart> when we branch 0.7, I will go with 0.7~ for the distro packages until release, 0.7 for the release packages, and move 0.8~~ for the dailies. [16:53:41] <mru> what does ~~ mean compared to ~? [16:54:17] <siretart> it is the "earlier" directive applied twice [16:54:33] <siretart> 0.7~rc1 will win over 0.7~~something [16:54:35] <mru> whatever you say... [16:54:44] <mru> do whatever you think is right [16:54:49] <lu_zero> siretart: proposing _preN would be considered heresy? [16:55:06] <lu_zero> =) [16:55:07] <siretart> lu_zero: '_' is not an allowed character in version strings [16:55:19] <lu_zero> ah [16:55:27] <siretart> '+' would be. or '-' [16:55:28] <elenril> how about we converge to sqrt(2)/2 [16:55:41] <BBB> wbs: oh, I see, you didn't fix the issue for real - can you still do that? [16:55:43] <siretart> that would be tex/latex like [16:57:41] <elenril> awesome, spammers finally noticed by mailserver [16:57:54] <elenril> took them quite long [16:57:55] <Flameeyes> lu_zero: if you were asking what I said means is simple: by default GCC emits common symbols, so each uninitialised variable is declared to be merged at the final link stage for all the objects using it... [16:59:06] <mru> Flameeyes: all of those symbols should eventually be hidden [16:59:14] <Flameeyes> mru: quite definitely [16:59:22] <Flameeyes> in the case of one (qmf_window) I wonder why it is not static actually [16:59:24] <mru> once the api cleanup is complete [16:59:53] <mru> patches welcome [17:00:01] <Flameeyes> I know, I'll send some in the next days [17:00:30] <Flameeyes> ff_* symbols are reserved/internal right? [17:02:45] <siretart> Flameeyes: yes, only other ffmpeg libraries are allowed to use them [17:03:06] <siretart> that's why we cannot hide them in the symbol files [17:03:56] <siretart> ideally, we make the symbol versioning scripts hide anything not matching av_* or ff_*. this doesn't work out for libavformat and libavcodec, though. [17:04:13] <Flameeyes> siretart: and if we were to use ff_avc_* for those that need to stay local? [17:04:15] <mru> the ff_ ones should be internal to each lib [17:04:37] <siretart> Flameeyes: what's the problem with ff_*? [17:04:37] <superdump> what is mp3on4? [17:04:52] <mru> some ugly hack on mp3 [17:04:53] <Flameeyes> siretart: if ff_* can be used avfâavc [17:05:11] <mru> Flameeyes, siretart: ff_* should be lib-private [17:05:30] <Flameeyes> mru: so those could be hidden already? [17:05:41] <Flameeyes> [given no software used them that is] [17:06:23] <siretart> mru: 'lib-private' means "only in the very same lib", then it should be hidden and not exported at all [17:06:33] <mru> libavcodec and libavformat currently export everything because the patterns required to match the correct things are too convoluted [17:06:33] <superdump> not mp3pro related or something to do with mp3 in mpeg-4 aac or something? [17:06:43] <av500> yes [17:06:45] <mru> due to all sorts of public symbols not having correct prefixes [17:07:00] <siretart> yes [17:07:35] <Flameeyes> mru: but then again you could "export everything BUT ff_*" [17:08:00] <mru> it's not that easy [17:08:14] <mru> some ff_ symbols need to be changed to av_ and made public [17:08:39] <siretart> this has happened for some symbols in the past already [17:08:50] <mru> yes, but the transition is incomplete [17:08:55] <Flameeyes> okay thus my proposal of renaming those that really _really_ shouldn't be exported to ff_avc_* so that they can be hidden right now... [17:08:57] <siretart> indeed [17:09:05] <Flameeyes> [or something similar] [17:09:11] <kierank> anybody know anything about gpio? [17:09:23] <av500> kierank: lol [17:09:24] <Flameeyes> then you could link ff_* to interlib-private, and av_* to public [17:09:42] <kierank> av500: what? [17:09:42] <mru> Flameeyes: is this lack of version a huge problem? [17:09:54] <siretart> Flameeyes: I think we should first fix/enforce public symbols to start with av_*, and then reconsider what to hide [17:10:04] <mru> +1 [17:10:13] <av500> +1 [17:10:20] <Flameeyes> mru: the version was added to avoid collisions, wasn't it? the lack of version of those will make the whole version idea moot [17:10:33] <Flameeyes> siretart: you know I read that so many times by now that I lost count? [17:10:47] <av500> Flameeyes: add one :) [17:11:01] <Flameeyes> av500: I don't see it as something to be happy or proud with [17:11:05] <mru> Flameeyes: only if something external uses them, which it shouldn't [17:11:17] <siretart> Flameeyes: then let's start working on it :-) - but TBH, this smells like post 0.7 stuff to me [17:11:19] <mru> internal references are already bound to the local lib [17:11:33] <mru> siretart: why not do it _before_ 0.7? [17:11:41] <Flameeyes> what mru said... [17:11:44] <uau> are there many ff_ symbols that would need to be made public [17:11:50] <siretart> mru: I fear it would delay 0.7 for a long time [17:11:53] <Flameeyes> mru: I'm not sure if common symbols are bound to -bsymbolic [17:11:57] <uau> i checked that mplayer2 uses none [17:12:08] <mru> Flameeyes: that's easy enough to check [17:12:08] <siretart> for instance, I still haven't heard a comment on what to do with libavfilter [17:12:21] <siretart> is the API/ABI already frozen? or still in flux? [17:12:47] <mru> some internal interfaces need to change for sure [17:12:53] * Kovensky melts APIs and doesn't afraid of anything [17:12:58] <mru> I don't know if that will propagate to the public api [17:13:05] <Flameeyes> also, while gentoo might not have everything on the planet, the list I sent to the ml should cover most of the issues out there, no? [17:13:11] <Kovensky> and hi Flameeyes [17:13:19] <siretart> well, we can bump major for public api changes, right? [17:13:37] <siretart> anyway, sorry, I need to run home to my wife now. cu later! [17:13:43] <uau> Flameeyes: making any symbols "interlib-private" is problematic as long as the libraries have independent major versions [17:13:57] <av500> and do we need them to have that? [17:14:02] <Flameeyes> uau: that was more a declaration than something enforceable of course [17:14:04] <Flameeyes> hi Kovensky [17:14:28] <uau> Flameeyes: i mean that you can't count on the ffmpeg libraries having matching versions [17:14:35] <Flameeyes> and? [17:14:51] <uau> so any benefits from them being "private" would be limited [17:15:03] <uau> you'd still need to track compatibility in them [17:15:09] <mru> that technical detail aside, I don't like the idea of libs accessing each other's internals in spaghetti fashion [17:15:27] <av500> liavinterlibdeps [17:15:28] <Flameeyes> [fwiw the only ff_ symbol of which I found use outsize of interlibs is ff_codec_get_tag [17:15:30] <av500> lib [17:15:33] <Flameeyes> used by bombono [17:15:45] <mru> wtf is that? [17:15:46] <Kovensky> libavlasagna (or libasagna) [17:15:59] <Flameeyes> mru: http://www.bombono.org/cgi-bin/wiki/ [17:16:27] <av500> mru: pardon my ignorance, but why must av libs be able to have different version numbers? [17:16:38] <Dark_Shikari> .... LOOOL. [17:16:41] <mru> av500: that's not the point [17:16:44] <Dark_Shikari> Someone asked me what compression I would use to stream audio + 480x272 video [17:16:49] <Dark_Shikari> if I had a 64bps connection [17:16:50] <av500> gzip? [17:16:52] <mru> that's just a consequence of having a sane api [17:17:02] <Dark_Shikari> I answered zlibbed MIDI and procedurally generated video. [17:17:12] <av500> he forgot a "k"? [17:17:37] <mru> Dark_Shikari: mpeg4-2 wireframe ftw [17:17:49] <Flameeyes> http://paste.pocoo.org/show/326089/ while this is the list of interlib symbols [17:19:47] <mru> Flameeyes: that list looks managable [17:20:30] <mru> the header parsing functions could be folded into parsers [17:20:35] <mru> with a generic api [17:21:26] <elenril> BBB: afraid to push the patch yourself? ;) [17:21:38] <BBB> no, busy with other stuff [17:21:40] <mru> elenril: he has gmail issues [17:21:50] <av500> he has gmail [17:22:24] <elenril> oh.....accept my sincere lolgmail [17:23:24] * av500 slaps everybody that mentions "leader" on -devel with a wet trout [17:25:08] <Compn> lol [17:26:03] <av500> please use "voted leader" or "revoluted leader" [17:26:36] <iive> av500: michael was co-leader with fabrice, long before ffmpeg moved to mphq [17:26:49] <elenril> av500: supreme leader? [17:26:53] <elenril> or eternal leader [17:27:00] <av500> iive: sure, I know the history [17:27:13] <av500> iive: its just that this work has lost meaning to me wrt -devel [17:27:24] <iive> av500: but you try to rewrite it. [17:28:20] <superdump> i suspect av500 was joking [17:29:00] <iive> he is not funny. [17:31:13] <CIA-43> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r07b48f8c7a ffmpeg/ffmpeg.c: [17:31:13] <CIA-43> ffmpeg: Do not set audio_resample to 0 if audio_sync_method is > 1. [17:31:13] <CIA-43> ffmpeg: If audio_sync_method is >1 the resampler is used for audio drift [17:31:13] <CIA-43> ffmpeg: compensation, and do_audio_out() was causing an assert failure because [17:31:13] <CIA-43> ffmpeg: audio_resample was not set. [17:31:13] <CIA-43> ffmpeg: Fix issue 2516, which was introduced by SVN r25939. [17:31:14] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:32:21] <elenril> rounddown is up? [17:37:43] <superdump> i'm curious - who is on 'michael's side'? [17:39:04] <BBB> define "on ... side" [17:39:46] <BBB> wants him to be leader? I've seen little support for that, "disagrees with the way we un-bdfl'ed him"? quite a few, "wants to commit to git.videolan"? I think stefano atm, but he wants to keep the two trees synced [17:41:07] <mru> most likely he made it up [17:41:18] <mru> just like the part about foundation paying people to "switch sides" [17:41:41] <mru> we know for a fact that didn't happen [17:45:33] <av500> Compn: avi with >100 streams, you really need that? [17:46:42] <superdump> i'm inclined to believe it was either someone else using michael to stir up the situation or michael misinterpreting or misunderstanding something [17:54:20] <superdump> have fun [18:07:22] <elenril> o_0 reimar committing to the videolan tree [18:09:41] * BBB agrees with superdump, probably a misunderstanding [18:10:03] <mru> question is _what_ was being misunderstood [18:10:33] <mru> the foundation hasn't offered anyone money since ruggles' ac3enc work was approved [18:24:54] <Tjoppen> I took a stab at rebasing that dvcpro hd patch, but it was a bit harder than I thought since it was written prior to the dv encoder becoming multithreaded [18:38:03] <lu_zero> uff [18:38:14] <mmu_man> huff [18:38:19] <mru> puff [18:38:38] <lu_zero> apparently somebody was playing BGP w/out knowing the rules... [18:39:09] <mru> gateway thing? [18:40:47] <lu_zero> mru: IX thing... [18:41:13] <mru> border gateway protocol? [18:41:14] <lu_zero> the fun of sitting right on the border... [18:41:50] <lu_zero> lscube.org is hosted on the second Italian internet exchange [18:42:20] <lu_zero> so from time to time we get strange issues ^^; [18:42:44] <spaam> like what? :) [18:44:50] <lu_zero> spaam: missing few routes to the outside [18:45:15] <lu_zero> not that often luckily [18:45:37] <lu_zero> this border is mostly safe [18:46:22] <av500> no smugglers? [18:49:05] <lu_zero> those usually prefer the MIX for obvious reasons [18:54:40] <Compn> av500 : like i said, not me, but maybe someone wants it :P [18:55:01] <lu_zero> Compn: smuggling packets? [19:26:38] <{V}> did git.videolan switch to some other mailinglist than ffmpeg-cvslog ? [19:27:52] <av500> no [19:27:56] <av500> its still this ml [19:28:39] <av500> but they are pulling a lot of patches from the other git [19:29:27] <{V}> odd. My mailbox (and http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/ ) seems to be missing the latest commits to the ffmpeg repo on videolan [19:30:59] <{V}> those by Reimar for example [19:31:45] <{V}> hmmm just the last 2 by Reimar it seems [19:32:10] <mru> +1 [19:34:03] <jannau> I can't see them in the archive either [19:34:39] <mru> nor moderation queue [19:35:31] <jannau> j-b, thresh: ping, notify mails from git.videolan.org:ffmpeg.git seems to be broken [19:35:50] <j-b> jannau: the ones from reimar, yes [19:36:08] <j-b> because of the "ö" [19:36:40] <elenril> he fails at utf-8? [19:36:42] <elenril> or you do? [19:37:24] <j-b> one of us... [19:37:27] <j-b> thresh will know [19:38:05] <elenril> thresh belongs to the videolan sect? [19:38:15] <jannau> we have a proposal for a new logo, http://www.heise.de/open/artikel/Die-Woche-Meuterei-auf-der-FFmpeg-1174538.… [19:38:19] <spaam> maybe git.videolan.org live in the past with iso8859-1 :/ [19:38:21] <jannau> ignore the article [19:38:43] <spaam> what does the article say? [19:39:05] <j-b> elenril: it isn't a sect (yet) [19:39:13] <spaam> i dont see the logo jannau ;S [19:47:50] <jannau> spaam: argh, it's not in the article. http://www.heise.de/open/imgs/10/6/2/0/1/6/2/ffmpeg-pirat-95x90-278105162ee… [19:48:51] <mru> :) [19:49:34] <CIA-43> ffmpeg: Kostya <kostya.shishkov(a)gmail.com> master * r3bdc886c22 ffmpeg/ (libavcodec/wavpack.c libavformat/wv.c): [19:49:34] <CIA-43> ffmpeg: Extend WavPack demuxer and decoder to support >2 channel audio [19:49:34] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [19:49:46] <CIA-43> ffmpeg: Kostya <kostya.shishkov(a)gmail.com> master * rdacbcd170a ffmpeg/ (libavcodec/wavpack.c libavformat/wv.c): [19:49:46] <CIA-43> ffmpeg: reindent after last commit [19:49:46] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [19:50:29] <mru> j-b: regarding the 'Ã¶', I edited the notification script on ffmpeg.org to properly mime-escape such things [19:52:24] <Compn> is there no way to resend those mails from git or are they lost forever btw ? [19:53:27] <Compn> spaam : google translate :P [20:04:35] <jannau> bah, and patchwork chokes on reimar's patches too [20:05:40] <Compn> should i send a mail to ffmpeg-devel about lost commit messages ? [20:05:49] <Compn> j-b , jannau , mru ? [20:05:59] <jannau> Compn: already done [20:06:03] <Compn> oh ok :) [20:06:59] <lu_zero> ... [20:08:39] <Compn> wb there lu_zero and lu_zero's doppleganger [20:08:56] <lu_zero> where ? [20:09:05] <lu_zero_> there [20:09:08] <lu_zero_> ok [20:09:10] <elenril> fork( lu_zero_ ) [20:09:19] <lu_zero_> still BGP weirdness [20:09:45] <Compn> lu_zero : have you gotten your country to learn ipv6 yet ? :P [20:10:17] <lu_zero_> Compn: not sure who is messing with bgp [20:10:23] <lu_zero_> tomorrow I'll know [20:10:41] <lu_zero_> hi saste [20:10:45] <j-b> mru: ok, should I fix something on my side? [20:11:04] <mru> j-b: you need to mime-escape the From header [20:11:20] <mru> I don't know how you're setting it currently [20:11:35] <saste> lu_zero: ciao luca [20:11:37] <j-b> I don't know either :) [20:11:45] <mru> replacing $author with encode("MIME-Q", $author) in some place should do the trick [20:12:06] <mru> does for us anyway [20:13:10] <wbs> BBB: I didn't get resetup working (easily) with real at least... if I don't do teardown, I get an error saying that the method isn't supported at that point.. if I do teardown, everything seems to succeed, but I never actually get any packets over TCP... so I'm not sure if I'd have to close the whole connection and start over from scratch with a new connection instead [20:13:52] <wbs> BBB: on the other hand, if one just closes the connection and does that, but don't go through the full options/describe phase, it might not be all that hacky [20:15:05] <siretart> wow. I'm impressed [20:15:34] <siretart> it seems that all of vlc, mplayer and gst-ffmpeg compiled against 0.6 still work with 0.7 [20:15:55] <j-b> stop using drugs! :D [20:16:14] <saste> siretart: we've been obsessed by the idea of not breaking apps in the last year [20:16:24] <saste> siretart: we did it pretty well [20:16:35] <jannau> siretart: stop using fake releases ;) [20:17:25] <siretart> saste: indeed, I have to congratulate to everyone working on that! [20:17:30] <BBB> wbs: can you try? would be nice if it works with real also [20:17:43] <wbs> BBB: I can give it a try. it might be cleaner for the other cases, too [20:17:45] <mru> siretart: I don't mind if you call your ubuntu packages 0.7~~#*@~, but don't refer current master as simply "0.7" [20:18:03] <BBB> wbs: not necessary for the other cases, this is networking, it'll introduce significant latency if we reconnect completely, I'm affraid [20:18:20] <wbs> BBB: but I'm not sure how the real cookie/challenge stuff works if we just keep the same data from the previous connection [20:18:24] <siretart> mru: ok, I'll be more careful in the future. [20:18:52] <wbs> BBB: or if we really need to do the full setup from the start in order to get a new challenge etc [20:20:21] <lu_zero> wbs: ? [20:20:24] <CIA-43> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r2b0decf60b ffmpeg/libavformat/applehttp.c: [20:20:24] <CIA-43> ffmpeg: applehttp: Fix the key check in handle_variant_args [20:20:24] <CIA-43> ffmpeg: The key string is supposed to contain the equals character, [20:20:24] <CIA-43> ffmpeg: too. Since the checked string was wrong, and the return value [20:20:24] <CIA-43> ffmpeg: check was wrong too, it incorrectly seemed to work right before. [20:20:25] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:20:26] * lu_zero missed the start [20:20:55] <mru> jannau: http://pastebin.com/SEFvmLMr [20:21:07] <BBB> wbs: test it :) [20:21:16] <wbs> BBB: yeah, that's the only way of finding out :-) [20:21:27] <BBB> wbs: also, no pakcets over TCP [20:21:33] <BBB> wbs: did you send a aubscribe afterwards? [20:21:50] <BBB> I'd love to see a wireshark trace of that [20:21:51] <wbs> BBB: hmmm, perhaps that's missing [20:22:34] <BBB> no subscribe means it won't send anything [20:22:36] <BBB> it's normal [20:22:46] <BBB> "normal" :-p [20:22:52] <wbs> real-rtsp sure is weird ;P [20:23:11] <lu_zero> could someone give me a backlog? [20:24:24] <BBB> wbs: indeed [20:25:33] <CIA-43> ffmpeg: Reimar DÃ¶ffinger <Reimar.Doeffinger(a)gmx.de> master * r032f406864 ffmpeg/libavutil/lzo.c: [20:25:33] <CIA-43> ffmpeg: Handle input or output len of 0 properly in lzo decoder. [20:25:33] <CIA-43> ffmpeg: (cherry picked from commit 7d5082600ee63d879c2a325974ea09c8ace05019) [20:25:37] <jannau> mru: I know [20:25:37] <CIA-43> ffmpeg: Reimar DÃ¶ffinger <Reimar.Doeffinger(a)gmx.de> master * r4be170c937 ffmpeg/libavcodec/nuv.c: [20:25:37] <CIA-43> ffmpeg: Use av_fast_malloc instead of av_realloc. [20:25:37] <CIA-43> ffmpeg: This should be faster, is less code and fixes issue 2524 [20:25:37] <CIA-43> ffmpeg: (allocation error would lead to crash). [20:25:38] <CIA-43> ffmpeg: (cherry picked from commit e7b95918fca1c3d057d35f77ba58ee2d00d03151) [20:26:27] <mru> jannau: did you miss my comment about "cherry-picked from"? [20:26:54] <jannau> mru: no, see my reply [20:26:59] <jannau> http://patchwork.libav.org/user/bundle/1/?state=* [20:27:23] <jannau> for Vitor's patches [20:28:01] <mru> I don't see a reply [20:28:28] <jannau> now sent, sorry [20:28:55] <mru> having a hash is useless without knowing where to find it [20:29:49] <mru> does google index them in gitweb? [20:30:43] <jannau> doesn't look like it does, only hit for e7b95918fca... is my mail [20:31:51] <jannau> git show $SHA1 will just work if both repos are configured as remotes [20:32:01] <mru> yes, I know [20:33:04] <relaxed> Just to be sure, on my Freebsd 8 box './configure --enable-gpl' enables #define HAVE_AMD3DNOW 1 and #define HAVE_AMD3DNOWEXT 1 in config.h even though I have an Intel T7600. After compiling it crashes when using 'vf scale=$W:$H' which I backtraced to swsscale trying to use 3dnow. I should file a bug report, correct? [20:33:35] <mru> sounds like the runtime detection went wrong [20:33:47] <mru> so yes, that's a bug [20:33:50] <jannau> I'm undecided, a agree that the default cherry-pick -x message is not ideal [20:34:14] <jannau> mru: there is no runtime detection in swscale [20:34:20] <mru> if it included the url of the remote it would be more useful [20:34:26] <mru> jannau: so that's wrong then [20:34:40] <mru> relaxed: does it work if you add --disable-amd3dnow? [20:34:47] <relaxed> yes [20:34:49] <mru> or whatever the flag is called [20:35:45] <relaxed> This looks similar. https://roundup.ffmpeg.org/issue893 [20:35:57] <jannau> someone thinks that HAVE_AMD3DNOW means the CPU has it vs the assembler being able to assemble it [20:37:09] <mru> and there gcc/binutils are horribly inconsistent [20:37:10] <jannau> argh: libswscale/x86/yuv2rgb_mmx.c:#undef HAVE_AMD3DNOW [20:37:31] <mru> on arm and mips, they reject instructions not supported by the selected cpu [20:37:37] <mru> on intel and ppc they always accept anything [20:37:57] <mru> at least on intel you can do runtime detection reliably [20:38:12] <mru> ppc doesn't have a portable way to do that [20:38:43] <uau> jannau: there is some runtime cpudetection support in swscale [20:38:44] <lu_zero> sadly =_= [20:39:06] <mru> linux traps and emulates the relevant instructions since quite a while [20:39:17] <mru> but obviously macos doesn't [20:39:22] <mru> no idea what aix does [20:39:49] <jannau> uau: only if explicitly enabled [20:40:08] <mru> hopefully that's something we can fix once lu_zero is done cleaning it up [20:40:18] <mru> lu_zero: we're counting on you [20:40:53] <uau> jannau: and why that "argh"? you realize that's just setting different variations when compiling a template? [20:41:32] <mru> uau: argh accurately sums up most of libswscale [20:41:43] <jannau> I could refresh my patches from october but I fear it would make lu_zero job harder [20:42:30] <mru> perhaps I should try once more raising the idea that --cpu=foo should disable things cpu foo doesn't support [20:42:35] <jannau> uau: I know but redefining a config.h is just wrong and broken [20:42:46] <mru> +100 [20:42:54] <jannau> +define [20:43:54] <relaxed> mru: For the record, I wasn't using --cpu=foo [20:44:38] <mru> I would also suggest disabling 3dnow by default [20:45:05] <mru> if no --cpu is specified, I'd expect the result to run on most current machines [20:45:08] <mru> whether intel or amd [20:45:54] <lu_zero> mru: I went a bit further yesterday [20:49:12] <wbs> BBB: sending a new subscribe seems to work fine, thanks :-) [20:49:36] <wbs> BBB: I'll brush it up and resubmit patches for those parts that need changing [20:51:43] <siretart> is svn://svn.ffmpeg.org/soc/libavfilter still being in use? [20:51:51] <mru> do all fate runners update samples every 24h? [20:52:21] <siretart> seems that it's checkout.sh fails due to the remove libswscale external [20:52:46] <siretart> now I wonder if it's worth to fix or if we should better import it into some git branch [20:52:54] <wbs> I guess the rest of the libavfilter soc repo should be imported as a git branch somewhere [20:53:11] <wbs> which makes it _much_ easier to deal with than the current soc svn repo [20:55:06] <lu_zero> hopefully ^^; [20:57:24] <siretart> wbs: how to keep the 'new' soc repo synced with master? [20:59:13] <wbs> siretart: it can be done as a branch that is rebased on top of master.. or merging in master if you prefer that [21:02:27] <mru> hmm, the gcc 4.6 snapshots have non-deterministic warnings [21:02:51] <lu_zero> why are you using 4.6? [21:02:57] <mru> I'm not [21:03:02] <mru> someone is running fate with it [21:03:41] <mru> warning count fluctuates [21:03:49] <siretart> wbs: I've not worked with the soc branch at all so far, so I'm totally indifferent [21:03:51] * lu_zero wonders what would be running ffmpeg on parrot [21:03:54] <mru> even with commits not touching any code it sees [21:04:20] <andoma> weird.. a friend posted this on facebook for me: [21:04:25] <andoma> echo `grep "make mbaff " libavcodec/h264_mvpred.h | awk '{ print $4; }' | cut -c1-5` `grep '2007;$' ffprobe.c | cut -d_ -f2` `grep getti libavutil/des.c | cut -c14-16` `git log | grep -A1 f06d6c751f708 | grep \>$ | awk '{ print $2,$3; }'` [21:05:41] <lu_zero> O_o? [21:06:48] <wbs> andoma: haha, nice [21:07:09] <spaam> what does it do? [21:07:16] <andoma> it prints a message [21:07:17] <mru> try and see [21:08:35] <spaam> awesome [21:09:21] <lu_zero> funny [21:09:39] <andoma> same guy also implemented an mp3 decoder in haskell [21:11:19] <mru> ouch [21:11:39] <mru> that's just not sane [21:13:32] <andoma> no, it isn't :) [21:15:45] <lu_zero> haskell... [21:23:49] <mru> haskell may have uses, though I've yet to see one, but codecs ain't one [21:24:27] <Dark_Shikari> mru: I could imagine haskell being useful for high-level stuff. [21:24:38] <Dark_Shikari> That is, consider writing high-level design in haskell, and DSP functions in asm and C. [21:24:56] <Dark_Shikari> Not necessarily the best idea, but it would be a less stupid model. [21:25:05] <mru> that's not what andoma said [21:27:31] <andoma> anyway, the guy wrote a blog post about it... [21:27:34] <andoma> http://blog.bjrn.se/2008/10/lets-build-mp3-decoder.html [21:28:14] <andoma> rather good, especially if you want to know a bit about mp3 itself [21:28:25] <Kovensky> <@andoma> same guy also implemented an mp3 decoder in haskell <-- link [21:28:31] <Kovensky> so I can break a haskellfag's mind [21:28:38] * Kovensky scrolls down and sees it [21:28:46] <andoma> ^ that's the link [21:29:53] <BBB> wbs: not surprised. Thanks for testing, great b/c now it'll work with real also :) [21:31:42] <j0sh> ghc (haskell compiler) is supposed to be pretty good [21:32:12] <ruggles> what is a nice generic name for format conversion dsputils when i split them out from DSPContext? i was thinking fmtconvert.c/h/asm/S/etc... and FmtConvDSPContext or put in libavcore and call it AVFmtConvDSPContext? [21:32:32] <BBB> wbs: why do you need to initialize real_challenge[] to ""? [21:32:55] <lu_zero> j0sh: at least twice as painful to bootstrap than gcc [21:33:04] <wbs> BBB: because we unconditionally copy it into rt->real_challenge, and if uninitialized, we'd might read out of bounds or read uninitialized data there [21:33:20] <BBB> the original one only uses it if server == REAL [21:33:26] <BBB> maybe that's what you should do here also? [21:33:34] <mru> compiler ... pretty good .. lol [21:33:54] <wbs> yeah, it's only used if server == REAL, but it feels less cluttered that way to copy it in every case [21:34:22] <mru> ruggles: talking about float/int conversion etc? [21:34:23] <BBB> it's NULL vs. "\0", not exactly identical [21:34:32] <BBB> well I don't care [21:34:50] <wbs> BBB: no, if it's an array, it's not NULL, it just contains uninitialized data [21:34:52] <BBB> it's just that in one place it's server==REAL?real_challenge:NULL now, and in the other it's real_challenge and for that you initialize it to "" [21:35:17] <BBB> it's a little inconsistent is all I wanted to say :-p [21:35:20] <wbs> ah ;P [21:35:21] <BBB> I know "\0" != NULL [21:35:30] <BBB> anyway, if you prefer it this way it's fine [21:35:34] <BBB> it works, which is more important [21:35:35] <mru> ruggles: I'd say drop the "DSP" from the name [21:35:50] <mru> and maybe abbreviate a bit less [21:35:59] <mru> formatconv or fmtconvert perhaps [21:37:22] <BBB> FmtConvert is short enough [21:37:41] <ruggles> i like that one better. more similar to AV_SAMPLE_FMT_* [21:38:00] <mru> then it's settled [21:38:15] <ruggles> should it go in libavcore? or wait until all of audioconvert is there? [21:38:16] <mru> oh no, I'll never fit a bike in this tiny shed [21:38:22] <ruggles> :) [21:38:46] <mru> ruggles: keep in in lavc for now [21:38:59] <mru> let's see what it ends up looking like, then we can decide where to put it [21:39:09] <ruggles> sounds good. [21:46:35] <Kovensky> <@BBB> I know "\0" != NULL <-- ofc not, "\0" is just 2 bytes, NULL is 4 or 8 bytes depending on the word size :) [21:46:56] <Kovensky> or are there any platforms people still care about that have a non-0 NULL? [21:54:08] <j0sh> where did the ffmpeg foundation money come from? (just wondering) [21:54:25] <merbanan> gsoc [21:54:32] <merbanan> and settlements [21:54:43] <merbanan> some are donations [21:55:04] <j0sh> settlements? lol [21:55:20] <j0sh> so threatening legal action actually does work? [21:55:26] <merbanan> yes [21:55:30] <j0sh> cool [21:55:33] <merbanan> we have a lawyer [21:55:54] <Compn> a team of lawyers [21:55:55] <CIA-43> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r2762a7a28b ffmpeg/libavformat/ (rtsp.c rtsp.h rtspdec.c): [21:55:55] <CIA-43> ffmpeg: rtspdec: Retry with TCP if UDP failed [21:55:55] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:56:01] <Compn> ;p [21:56:17] <CIA-43> ffmpeg: Martin Storsjo <martin(a)martin.st> master * rfef5649a82 ffmpeg/libavformat/ (rtsp.c rtsp.h): [21:56:17] <CIA-43> ffmpeg: rtsp: Make make_setup_request a nonstatic function [21:56:17] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:56:25] <merbanan> sflc [21:56:28] <CIA-43> ffmpeg: Martin Storsjo <martin(a)martin.st> master * re836b1b085 ffmpeg/libavformat/rtspdec.c: [21:56:28] <CIA-43> ffmpeg: rtspdec: Move rtsp_read_pause up, next to rtsp_read_play [21:56:28] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:56:30] <Compn> yep [21:56:39] <CIA-43> ffmpeg: Martin Storsjo <martin(a)martin.st> master * r93e7490ee0 ffmpeg/libavformat/ (rtsp.c rtsp.h): [21:56:39] <CIA-43> ffmpeg: rtsp: Split out a function undoing the setup made by ff_rtsp_make_setup_request [21:56:39] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:56:41] <CIA-43> ffmpeg: Martin Storsjo <martin(a)martin.st> master * raeb2de1c82 ffmpeg/libavformat/rtsp.c: [21:56:41] <CIA-43> ffmpeg: rtsp: Use ff_rtsp_undo_setup in the cleanup code in ff_rtsp_make_request [21:56:41] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [21:57:03] <thresh> what about the mails? [21:57:55] <Compn> reimar's non utf-8 name got stuck at the scripts [21:58:04] <Compn> i guess [21:58:10] <Compn> if you arent utf8, you arent a person [21:58:21] <Compn> its 1984 all over! [21:58:55] <thresh> haha [21:59:03] <wbs> jannau: hey, where did my 'Ã¶'s go on some of the commits? ;P [21:59:27] <mru> wbs: you sent them that way [22:00:31] <thresh> i've added $author_name = encode("MIME-Q", $author_name); in git-notify [22:00:38] <thresh> should probably work [22:00:42] <wbs> mru: no, they sure look proper to me, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-January/104199.html [22:01:54] <merbanan> wbs: embrace you new name [22:02:34] <wbs> merbanan: I've got no problem with it being either way, as long as it would be consistent... since it was written with an 'Ã¶' in the rewritten svn commits, I've changed to use that in my git commits in this repo, too [22:03:12] <mru> wbs: resistance is futile [22:03:58] <lu_zero> ^^; [22:04:16] <wbs> consistence, too, apparently [22:04:22] <thresh> elenril: and yeah I'm a videolan folk as you might have noticed by /whois thresh :P [22:04:30] <jannau> wbs: sorry, patchwork or the patchwork client seem to have stripped them [22:05:02] <lu_zero> wbs: I could commit using all my names and then remove one or the other [22:06:05] <wbs> lu_zero: yeah, you've got a bit more combinatorics ;P [22:07:35] <lu_zero> =) [22:07:40] <jannau> I'll commit from my mailer from now on, 5/5 with proper Ã¶ was committed from there since patchwork missed the the updated patch [22:09:30] <thresh> btw, were there just two git commits by reimar? [22:09:48] <thresh> I'll just resend the mails [22:10:15] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * refa6ce9982 ffmpeg/ffserver.c: ffserver: put gcc attribute under proper ifdef [22:11:42] <jannau> thresh: yes, only two after the from was changed [22:12:21] <mru> you'd be surprised how many spam mails are stopped by strict header checks [22:15:43] <thresh> thanks, seems fixed [22:21:17] <thresh> mru: well I wonder why spammers are so stupid they don't use proper MTA [22:21:36] <thresh> no idea if postfix is capable of shooting out thousands of mails at a time, though [22:22:11] <mru> postfix maybe doesn't run so well on botnets [22:22:45] <thresh> but still, I would expect them to analyze logs to minimize costs [22:22:55] <thresh> well maybe not, as infecting another machine is cheaper [22:26:53] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * re63dd5fb04 ffmpeg/tests/ (fate/h264.mak ref/fate/h264-extreme-plane-pred): [22:26:53] <CIA-43> ffmpeg: fate: add h264 test for extreme cases in planar prediction [22:26:53] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [22:27:37] <Dark_Shikari> \i/ [22:27:39] <Dark_Shikari> er, \o/ [22:28:05] <mru> I don't want to know what that first thing represents [22:28:55] <Dark_Shikari> a typo. [22:30:11] <merbanan> freudian misshap [22:30:59] <JEEB> FreudWasRight [22:34:25] <CIA-43> ffmpeg: Jason Garrett-Glaser <darkshikari(a)gmail.com> release/0.6 * r4ac56bf7dc ffmpeg/libavcodec/vorbis_dec.c: [22:34:25] <CIA-43> ffmpeg: Fix crashes in vorbis decoding found by zzuf [22:34:25] <CIA-43> ffmpeg: Fixes issue 2322. [22:34:25] <CIA-43> ffmpeg: Originally committed as revision 25591 to svn://svn.ffmpeg.org/ffmpeg/trunk [22:34:25] <CIA-43> ffmpeg: (cherry picked from commit 3dde66752d59dfdd0f3727efd66e7202b3c75078) [22:34:25] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [22:34:33] <CIA-43> ffmpeg: Frank Barchard <fbarchard(a)google.com> release/0.6 * r5e3d023702 ffmpeg/libavcodec/vorbis_dec.c: [22:34:33] <CIA-43> ffmpeg: Check rangebits to avoid a possible crash. [22:34:33] <CIA-43> ffmpeg: Fixes issue 2548 (and Chrome issue 68115 and unknown CERT issues). [22:34:33] <CIA-43> ffmpeg: Patch by Frank Barchard, fbarchard at google [22:34:34] <CIA-43> ffmpeg: Originally committed as revision 26365 to svn://svn.ffmpeg.org/ffmpeg/trunk [22:34:34] <CIA-43> ffmpeg: (cherry picked from commit 13184036a6b1b1d4b61c91118c0896e9ad4634c3) [22:34:35] <CIA-43> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [22:34:43] <_av500_> since the coup, cia spams a lot here :) [22:34:51] * _av500_ kicks CIA-43 [22:34:52] <CIA-43> ow [22:35:11] <Kovensky> what, svn commits:?? o_O [22:35:39] <wbs> cherrypicked to release/0.6 [22:37:09] <_av500_> the donation thread took a strange turn [22:38:53] <Kovensky> oh lol [22:39:09] <Kovensky> the lack of colors on CIA here makes it a bit less obvious ._. [22:39:41] <siretart> jannau: thanks for pushing, though some OK would have been okay, I can push myself. I just solicited for opinions :-) [22:39:45] <spaam> Kovensky: you like colors? ;) [22:43:01] <jannau> siretart: I know, I wanted sligthly different commit messages and figured it would be easier if I just push them [22:43:38] <mmu_man> mIRC colors crash PalmOS clients running on 4800bauds GSM [22:43:49] <mmu_man> but I didn't see anyone using it for some time :) [22:44:07] <spaam> mmu_man: lets start using it? :) [22:44:50] <siretart> jannau: ah, I see, thanks! [22:45:05] <siretart> good night [22:45:10] <lu_zero> nite [22:48:17] <ruggles> mru: what are the parameter constraints for ff_float_to_int16_neon? [22:48:37] <mru> 16-byte aligned, multiple of 8 elements iirc [22:49:07] <ruggles> good. same as x86. [22:52:20] <lu_zero> NASCA DRM FILE - VER1.00 <- rings any bell? [22:53:16] <_av500_> taco bell? [22:54:37] <Flameeyes> hrm, why would ff_acelp_interpolate be unused? o_O [22:56:12] <_av500_> i see 3 codecs use it [22:56:24] <Flameeyes> _av500_: don't they use the final 'f' version [22:56:24] <Flameeyes> ? [22:56:53] <_av500_> i am blind [22:57:25] <lu_zero> Flameeyes: integer and float variants might be incomplete across audio codecs [22:57:59] <Flameeyes> lu_zero: there is no use of the integer version; I was more looking into an answer like "because it was migrated to float" or "because nobody migrated them from float" or "future use" [22:58:23] <mru> BBB: ping [22:59:12] <Flameeyes> sigh trying to make sense of my missingstatic output is difficult [22:59:41] <Flameeyes> because it's not easy to tell what is "unused, for future extension", "no longer used" or "will go away at next ABI bump" [23:01:31] <lu_zero> Flameeyes: nobody had the integer/float implementation done yet [23:03:28] <lu_zero> BBB: rdt adds streams while parsing the sdp as well am I wrong? [23:04:11] <mru> BBB: I know you're there [23:04:15] <mru> I need your help [23:04:24] <BBB> mru: pong [23:04:27] <BBB> lu_zero: it does [23:04:31] <mru> 8x8 planar prediction is busted on x86 [23:04:38] * mru fucked up testing yesterday [23:04:42] <BBB> shit [23:04:45] <BBB> I'll fix tonight [23:04:48] <mru> but I only added the test... [23:05:11] <mru> it's the pred8x8_plane_* functions [23:05:41] <mru> but I can't make heads or tails of it [23:05:56] <mru> it's several times bigger than my neon code... [23:06:06] <BBB> it's unlooped which was a little faster [23:06:09] <BBB> I'll fix it, don't worry [23:06:57] <mru> it's full of ifdefs too [23:07:20] <BBB> x86-64/32 misery [23:07:43] <mru> the only loop in mine is a 3-insn loop of 8 iterations at the end [23:07:48] <mru> and it's memory bound anyway [23:07:58] <BBB> I have that loop also [23:08:01] <BBB> I don't know why mine is bigger [23:08:03] <BBB> it's just messy [23:08:09] <BBB> but it's really fast :) it's faster than x264's [23:08:18] <mru> it has the 32/64 conditionals [23:08:24] <mru> and some svq3 mess [23:08:36] <BBB> oh right, rounding differences [23:08:39] <BBB> fun [23:08:41] <mru> and mmx/sse/ssssseeee [23:08:47] <BBB> yes [23:09:00] <BBB> I'll fix it, don't worry, I'm quite sure I know where the bug is :-p [23:09:12] <mru> good [23:09:53] <BBB> you can try backporting my 16x16 fix to 8x8, if you're adventurous [23:10:05] <BBB> I currently have my tree messy for the emu_edge patch [23:10:11] <BBB> I should learn to create branches per big patch [23:10:15] <BBB> can I do that now? [23:10:42] <mru> I was trying to figure out what the hell that changed [23:11:00] <jannau> BBB: you could just stash your current changes [23:11:06] <jannau> git help stash [23:11:58] <BBB> mru: the sum of H coefficients (8*tl+7*t0...-8*t15) * 17 (I think) [23:12:01] <BBB> overflows in a word [23:12:07] <BBB> I did that as a vector operation in words [23:12:15] <jannau> git checkout -b work/emu_edge && git add -p && git commit -m "wip" would work too [23:12:18] <BBB> it moves it below where it's in a regular register, so dword at least [23:12:32] <BBB> and then it does not overflow [23:12:33] <mru> oh, it's being moved to scalar? [23:12:39] <jannau> that would create your branch [23:12:39] <BBB> yes [23:12:48] <BBB> so I moved the code to a place where we already moved it to scalar anyway [23:12:52] <BBB> then it doesn't get slower [23:13:38] <mru> no 32-bit in vectors? [23:15:26] * Flameeyes mutters something about exuberant-ctags failing badly without pre-processing headers [23:15:26] <BBB> I could, but scalar is faster [23:15:39] <lu_zero> how's possible? [23:16:00] <BBB> lu_zero: it's a single operation, so I don't load multiple values in multiple registers [23:16:05] <BBB> it's just a single mul+shift [23:16:10] <BBB> then scalar is not slower than vector [23:16:14] <BBB> in fact it can be faster [23:16:31] * mru tries to find the corresponding place in the 8x8 code [23:16:33] <mru> without much luck [23:16:47] <lu_zero> the same operation shouldn't be applied over a vector? [23:17:01] <mru> ah, I think I found it [23:17:09] * lu_zero was distracted while looking at rdt and asf [23:17:10] <BBB> pmullw m0, [pw_17] [23:17:11] <BBB> paddw m0, [pw_16] [23:17:11] <BBB> psraw m0, 5 is the stuff to remove [23:17:28] <mru> that much I figured out already [23:17:28] <BBB> movd r1d, m0 [23:17:29] <BBB> movsx r1d, r1w [23:17:36] <mru> and I just spotted that [23:17:36] <BBB> under that movsx, do the mul, add and shift [23:17:40] <BBB> :) [23:17:44] <BBB> you're too quick ;) [23:20:47] <mru> hmm, lea doesn't work here [23:21:02] <BBB> use imul [23:21:09] <BBB> we use pmullw also, it shouldn't be slower [23:22:06] <mru> \o/ it works [23:22:17] <mru> wait, maybe it doesn't [23:22:27] <mru> but it assembles [23:22:43] <BBB> make fate h264-extreme-plane-test [23:22:50] * Flameeyes feels like crying [23:22:57] <mru> hey, it _does_ work [23:23:02] <BBB> Flameeyes: ? [23:23:13] <Flameeyes> exuberant-ctags goes tfu because it doesn't pre-process correctly files [23:23:16] <BBB> mru: OMG YOURE OUR NEW X86 ASM HERO!!! CAN I TAKE A PICTURE WITH YOU?!? [23:23:33] <Flameeyes> so I can't use it to produce a list of symbols to be considered the public API [23:23:55] <Flameeyes> and without that, trying to make heads or tails of what I see missing av or ff prefixes is near impossible [23:25:45] <Flameeyes> beside the fact that ffserver takes up symbols that are not in the public api anyway [23:25:57] <mru> BBB, Dark_Shikari: patch waiting for your review [23:26:00] <BBB> reviewed [23:26:37] <lu_zero> Flameeyes: headers missing? [23:26:47] <Flameeyes> lu_zero: and prefixes.. "rtp_get_local_rtp_port" [23:27:41] <CIA-43> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r80944df720 ffmpeg/libavcodec/x86/h264_intrapred.asm: [23:27:41] <CIA-43> ffmpeg: x86: fix overflow in h264 8x8 planar prediction [23:27:41] <CIA-43> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:27:45] <BBB> ty mru [23:27:50] * BBB continues working on emu_edge [23:28:00] <BBB> brb [23:28:11] * mru washes hands [23:28:14] * lu_zero doesn't like it... [23:28:23] <lu_zero> mru: too much dust? [23:28:32] <mru> too much x86 [23:28:40] * lu_zero is considering how to get the chained demuxer for mpegts [23:29:02] <mru> chained how? [23:29:46] <lu_zero> rtp -> depack -> feed a pb -> mpegts [23:39:48] <Flameeyes> okay I sent a bunch of patches, see which ones make sense please, and at least it should slightly reduce the mess [23:39:57] <mru> on it [23:41:24] <Flameeyes> I guess the next step would be to get a list of symbols exported that need to be renamed at ABI bump... rename them and bump ABI [23:42:07] <Flameeyes> and does anybody have contact with http://www.bombono.org/cgi-bin/wiki/ ? [23:44:06] <lu_zero> Flameeyes: who packaged it in gentoo? [23:44:36] <Flameeyes> lu_zero: dilfridge [23:46:35] <j-b> Flameeyes: glad to see you around... You still are a legend here... [23:47:04] <Flameeyes> j-b: I'm not sure how to read it ^^;; I tend to be very real-world myself :P [23:47:11] <mru> j-b: he's "the other diego" [23:47:22] <j-b> Flameeyes: read it the good way [23:47:50] <j-b> mru: well, he has a few fans... [23:47:59] <Flameeyes> j-b: I will :D thanks, I try to still be around, time allowing to do stuff... hiding ffmpeg's symbols is a veeeery old pet peeve of mine :P [23:48:06] <mru> j-b: ah, that's why he's so noisy [23:48:16] <j-b> Flameeyes: ;) [23:48:21] <mru> j-b: do you think he could be fitted with water cooling instead? [23:48:29] <j-b> no idea :) [23:49:10] <Flameeyes> uhm I wouldn't mind a watercooler in the office actually [23:49:41] <Flameeyes> but I guess a gbit switch would be more useful [23:49:44] <Flameeyes> or a coffee, right now [23:50:03] * mru recently bought a 16-port gbit switch [23:50:17] <Flameeyes> mru: uhm, which brand, where and how much did you pay for it? :P [23:50:54] <Flameeyes> I have a 2x5p here and I don't think they are very happy of working this way :/ [23:51:37] <mru> Flameeyes: this one: http://www.scan.co.uk/products/netgear-gs716teu-pro-safe-16-port-gigabit-sm… [23:52:19] <mru> I got tired of cheap switches locking up, dropping packets or otherwise being a nuisance [23:52:40] <mru> the old one had taken to intermittently hating the mac g4 [23:52:53] <mru> dropping 90% of packets to and/or from it [23:56:00] <Flameeyes> ouch. not exactly cheap but not bad either.. is that a sane site? [23:56:27] <mru> it's usually sane [23:56:55] <mru> I've found the Â£50 switches to be less than reliable [23:57:03] <mru> time to try something better [23:57:06] <Flameeyes> yeah they tend to be [23:57:37] <Flameeyes> I wonder if they sell outside of UK, within EU VAT discount area [23:57:46] <mru> no idea [23:58:02] <mru> but surely someone in .it sells that or something similar [23:59:04] <Flameeyes> mru: at twice the price usually [23:59:18] <mru> hmm [23:59:45] <DonDiego> so... [23:59:50] <DonDiego> WTF? [23:59:57] <roxfan> http://www.amazon.fr/NETGEAR-ProSafe-GS716T-Commutateur-Ports/dp/B0007TFG8U/

1 0

IRC log for 2011-01-23
by irc＠mansr.com 24 Jan '11

24 Jan '11

[00:00:26] <saintd3v> lu_zero and michael sitting in a tree... [00:02:02] <mru> g i t t i n g [00:04:07] <lu_zero> uhm? [00:04:22] <lu_zero> something else happened? [00:05:03] <jannau> lu_zero: michael replied to your mirror mail in a certain way [00:05:12] <superdump> peloverde: ping? [00:05:37] <peloverde> pong [00:06:01] <lu_zero> how so? [00:06:04] <superdump> i didn't respond to your SBR signalling patch because i didn't have some specs to hand at that point [00:06:13] <superdump> which spec is AudioSpecificConfig in again? [00:06:23] * lu_zero doesn't have emails [00:06:31] <superdump> subpart 1 or something? [00:06:33] <peloverde> 14496-3 subpart 1 [00:07:05] <lu_zero> ah [00:07:21] <superdump> i swear i used to have a full 14496-3 [00:07:28] <lu_zero> should I be scared or just afraid? [00:09:13] <siretart> seems launchpad does build something now: https://code.launchpad.net/~motumedia/+recipe/ffmpeg-daily (uses the bzr ffmpeg mirror) [00:15:41] <Dark_Shikari> lu_zero: check your invites, superdump as well [00:33:50] <mru> jannau: how about we point patches.ffmpeg.org at your patchwork server? [00:49:33] <jannau> mru: in principle yes, need to configure it accorgingly but I want first to think if/how I set one up for videolan.org/michael [00:50:05] <mru> I'd let michael worry about himself [00:51:33] <jannau> I tend to think that we should try to work with a single instance, there just too much manual intervention necessary [00:51:52] <mru> we can't have a shared tracker [00:51:57] <mru> that just doesn't work [00:52:08] <jannau> especially if the commit messages don't match [00:52:22] <mru> especially if the _commits_ don't match [00:52:55] <mru> or the patches, for that matter [00:53:16] <lu_zero> ... [00:56:49] <jannau> I forgot btw that lu_zero had proposed to run patchwork [00:57:08] <mru> and michael called it "unacceptable" [00:57:24] <mru> before blurting out a rant about "root" [00:57:55] <lu_zero> I don't recall when and where [00:58:04] <lu_zero> michael dug something [00:58:12] <lu_zero> but it's just a mild no [00:58:18] <lu_zero> not the usual "unacceptable" [00:58:49] <mru> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/44000 [00:59:39] <mru> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/43995 [01:01:05] <lu_zero> ok I'm surely more worn out that should [01:01:43] <jannau> well, I tend to agree that undocumented/missing status changes per mail are inconvenient [01:01:45] <mru> he's been going on like that ever since me/diego/attila started running the server [01:02:02] <mru> remember that the old admin, arpi, allowed the server to melt down completely [01:02:28] <mru> jannau: sure, but that's beside the point [01:02:47] <mru> he didn't like it then, why should we spend any effort on setting it up for him now? [01:07:07] <jannau> I've added a state Committed, was planning to use Accepted as reviewed and ok [01:10:08] <jannau> I'll look into commands per email, I can't believe nobody implemented that during the last 3 years [01:10:51] <mru> let me just say this, michael has repeatedly stated he doesn't want me as "root" [01:11:06] <mru> from my point of view, his wish has come true [01:11:30] <mru> I will not do anything whatsoever for him systemwise [01:11:42] <mru> since that's exactly how he wants it [01:13:33] <jannau> that's fine and you're free act as you wish and I'm too [01:13:41] <mru> of course [01:14:00] <mru> you have no quarrel with him - yet [01:15:39] <jannau> commands per email is something I really want for our instance [01:15:59] <mru> I'm not disputing the utility of email commands [01:16:13] <mru> but lack thereof shouldn't be a total blocker for using an otherwise nice tool [01:28:26] <Tjoppen> god afton [01:34:56] <iive> mru: actually your reply read more you are refusing to install such system on the server because of the low quality of all available solutions. [01:35:18] <mru> I never refused anything [01:35:29] <mru> nobody ever asked for one before that thread [01:37:20] <iive> "Why we don't have one" "Because there is no decent one". [01:38:08] <iive> well [01:38:14] <iive> n8 ppl. [01:38:23] <{V}> g'dnight iive [01:41:34] <BBB> mru: we should give siretart commit access for 0.6.2, or figure out some way for him to be able to do 0.6.2 without us committing for him [01:41:46] <mru> I already gave him access [01:51:13] <BBB> ah good [02:19:39] <saintdev> superdump: what section is that in subpart-1? [02:20:16] <superdump> AudioSpecificConfig [02:21:27] <superdump> 1.6.2.1, table 1.15 [02:21:31] <superdump> in my copy [02:21:42] <superdump> the syncExtensionType [02:22:47] <superdump> there's a special case for syncExtensionType == 0x2b7 [02:22:47] <saintdev> ok, found it. [02:23:12] <superdump> does it say 0x2b7 there too? [02:23:36] <saintdev> yeah, and i have the same copy as alex, so it was a typo [02:24:58] <superdump> me too actually :) [02:25:13] <saintdev> oh, lol [02:25:29] <superdump> well, in any case, the document should be correct so it's still a typo [02:26:11] <saintdev> well it _could_ be a final draft/release spec change [02:26:49] <superdump> unless i'm mistaken, it doesn't look like they touched that bit [02:27:06] <saintdev> about 99% more likely it was just a typo, though [02:27:34] * superdump nods [02:27:42] <superdump> we all know peloverde has newb typing fingers [02:27:52] <peloverde> superdump: is correct [02:28:00] <superdump> :) [02:28:01] <peloverde> i will fix it tonight/tomorrow if no one beats me [02:28:02] <Dark_Shikari> BBB: crap, accidentally spammed you [02:28:05] <Dark_Shikari> gmail apparently copies 1000 lines when I select 5 [02:28:07] <Dark_Shikari> tell me when the spam is over :> [02:28:19] <saintdev> spaam: get out of BBB's inbox [02:28:37] <superdump> i have some gmail labs extension set up to only use the bit i highlighted methinks [02:28:38] <saintdev> oh, erm his PM [02:29:04] <mru> whatever version of the doc I have, it says 0x2b7 [02:29:30] <superdump> good job i checked :B [02:30:05] <mru> mine is N7129 [02:30:20] <mru> I think I gave it to some of you guys in the past [02:31:09] <superdump> we have n9500 [02:31:16] <mru> that's not fair [02:31:24] <saintdev> ner ner [02:31:35] * superdump dances [02:32:44] <superdump> mru: now you do too [02:33:20] <saintdev> aww [02:34:04] <mru> ta [04:23:02] <peloverde> Does this timeline seem correct: http://pastebin.com/9pTDeQp5 [04:23:32] <mru> that's ancient history [04:23:39] <mru> how do you expect us to remember? [04:23:44] <mru> better ask mike melanson [04:27:12] <Compn> peloverde : why mention vp3 but not theora ? didnt the spec come first ? or am i thinking theora spec first? [04:27:27] <mru> theora is vp3 [04:27:51] <mru> or some hacked-up version of it [04:27:57] <Compn> hacked-up version yes [04:28:40] <mru> peloverde: some entires aren't in order [04:29:39] <Compn> oh theora is listed, doh [04:29:42] * Compn blind [04:42:30] <peloverde> I feel very frustrated when I see all kinds of nonsense from idiots gaining a ton of mindshare [04:43:03] <mru> understandable [04:43:29] <peloverde> like "Is there any significance to the fact that Google chose IETF instead of ISO (where MPEG-LA and M$ submitted H.264 and OOXML)?" [04:43:50] <mru> there is, actually [04:43:58] <ohsix> if it's vague enough then people show up to fill th eseats [04:44:02] <mru> the process is much more rigorous with ISO [04:44:13] <peloverde> H.264 wasn't submitted by MPEG-LA to ISO [04:44:17] <mru> ISO/IEC in this case [04:44:36] <mru> h264 was developed by iso, iec, and itu [04:44:52] <mru> well, by their members [04:45:12] <mru> but why do you read that crap anyway? [04:45:25] <mru> idiots will never go away [04:46:03] <peloverde> h.264 was developed by researchers from a variety of organizations, MPEG-LA went and licensed patents after the fact [04:46:07] * Compn wonders what site's comments are getting peloverde riled up [04:46:13] <peloverde> slashdot [04:47:01] <mru> mpeg-la is a patent pool set up by the majority of the rights holders of patents related to the mpeg family of codecs [04:47:13] <Compn> theora google-hating commentors ? seems like a stereotype [04:47:26] <mru> the _only_ thing mpeg-la does is sell licenses and distribute the royalties [04:47:34] <peloverde> mpeg-la is an independent company that tries to organize patent pools for a variety of standards [04:47:50] <mru> aren't they owned by the patent holders? [04:48:04] <mru> or at least originally founded by [04:48:33] <mru> they exist as a consequence of the patent system, not the other way around [04:48:59] <peloverde> they exist as a consequence of the patent system but as far as i know they are independent [04:49:03] <Compn> independent company ? what ? [04:49:13] <Compn> they are independent from sony ? [04:49:20] <Compn> maybe i dont know your definition of independent [04:49:21] <mru> and given the patent situation, mpeg-la is a _good_ thing [04:49:52] <peloverde> mru: agreed [04:50:07] <peloverde> Compn: they are not owned by sony, they negotiated a deal to sub-license sony patents along with patents owned by others [04:51:18] <peloverde> but the whole situation is presented backwards in the blogosphere [04:51:35] <mru> the bogosphere [04:51:45] <peloverde> MPEG-LA is an evil company who developed H.264 in secret with Apple, patented it and forced it through ISO [04:52:24] <peloverde> Yes but idiots like Mozilla pushed on Google until they dropped H.264 support [04:53:51] <peloverde> As Chris Blizzard said as FOSDEM, he knows what the best codec for the web is and doesn't need any technical knowledge to make that decision [04:54:24] <peloverde> And his mp4 that was 90% hint track was proof of his technical illiteracy on this issue [04:55:13] <saintdev> peloverde: everybody know's that it's SVQ1 [04:55:48] <mru> the slowest encoder in ffmpeg [05:25:41] <kshishkov> mru: I know it's icorrect to compare audio and video decoders speed but I think my AAC encoder once was even slower [05:26:04] <kshishkov> mru: also we may write Monkey Audio encoder one day [05:47:24] <Flameeyes> mru, peloverde: the results are on the ML for you to cry at :) [05:49:09] <saintdev> kshishkov: your trellis is a beast [05:50:27] <saintdev> oh no, ffmpeg is using private symbols! [05:51:30] <kshishkov> saintdev: iKnow [05:51:55] <Flameeyes> saintdev: or some symbols that should be public aren't prefixed with av_ :) [05:51:59] <kshishkov> still, it's funny how APE decoding took more CPU than H.264 SD [05:52:10] <Flameeyes> afaict at least the url_* set is a false positive, not sure about dump_format [05:53:03] <Flameeyes> if I do exclude those two, the list of packages is six packages shorter [05:53:14] <kshishkov> saintdev: IIRC I started with something simpler, faster and quite as effective [05:53:46] <saintdev> then michael kept telling you 'viterbi' ? [05:54:11] <kshishkov> you said that [05:54:20] <saintdev> huh? [05:54:31] <ohsix> viterbi 4 lyf [05:54:55] <ohsix> i never quite got why everyone calls it trellis in here [05:55:18] <kshishkov> because of certain Austrian [05:55:40] <ohsix> no time better than the present to elaborate :] [05:55:46] <kshishkov> and because it's most known use of it [05:56:17] <ohsix> which austrian? [05:56:27] <kshishkov> the one who blogged about it [05:57:19] <ohsix> url? [05:57:54] <saintdev> kshishkov: i seem to remember something like michael kept wanting you to trellis more and more stuff. [05:58:06] <Dark_Shikari> ohsix: "trellis quantization" [05:58:13] <Dark_Shikari> so everyone calls viterbi stuff in video "trellis" [05:58:16] <Dark_Shikari> as a result. [05:58:25] <ohsix> okie dokie [05:58:27] <saintdev> or maybe i'm just imagining things. i wasn't part of the mailing list when all that was going down [05:59:13] <kshishkov> saintdev: it was more like "make encoder optimal first" [05:59:35] <kshishkov> saintdev: no matter it would be as fast as H.265 [06:01:20] <ohsix> what's the austrians name anyways i'm not up to speed [06:02:00] <kshishkov> ohsix: Michael [06:02:05] <saintdev> kshishkov: but the h.265 reference software is faster than JM! [06:02:23] <kshishkov> Dark_Shikari: ^^^ [06:02:25] <saintdev> one small caveat: it's more optimized than JM =P [06:02:25] <ohsix> k [06:03:01] <saintdev> kshishkov: so of course, they can now claim h.265 is faster than h.264! [06:03:58] <kshishkov> saintdev: http://x264dev.multimedia.cx/archives/360 [06:05:22] <saintdev> kshishkov: i know, that was one of the proposals. they just cherry-pick ideas from the proposals to use in the final spec [06:06:21] <kshishkov> well, I expect them to pick only the slowest things [06:08:21] <saintdev> <Dark_Shikari> Alex_W: their numbers are still hilarious though [06:08:21] <saintdev> <Dark_Shikari> they're claiming the low complexity version is less complex than h264 [06:08:21] <saintdev> <Dark_Shikari> because they've optimized it better than JM [06:08:24] <saintdev> kshishkov: ^ [06:09:45] <kshishkov> well, "better than JM" means that they've implemented not in the most pessimal way [06:13:23] <kshishkov> once I had to optimise reference G.722 codec in at least two times [06:13:58] <kshishkov> by simply inlining functions and dropping few saturation checks I've made it four times faster [07:26:42] <siretart> did anyone try to build a shared libswscale.so on x86_64 lately? [07:26:51] <siretart> I get this: /usr/bin/ld: libswscale/rgb2rgb.o: relocation R_X86_64_PC32 against symbol `ff_bgr2YCoeff' can not be used when making a shared object; recompile with -fPIC [07:37:57] <drv> siretart: seems to work ok here [07:44:06] <siretart> hm. what did I do wrong then here? http://launchpadlibrarian.net/62653248/buildlog_ubuntu-natty-amd64.ffmpeg_0… [07:45:33] <drv> maybe different binutils or gcc version? [07:45:52] <ohsix> also gold is in play [07:47:29] <Dark_Shikari> Flameeyes: ping [07:47:36] <Dark_Shikari> how do we know which private symbols are being used? [07:51:13] <Dark_Shikari> Flameeyes: [07:51:13] <Dark_Shikari> 18:50 < j^> its about avformat.h:void dump_format [07:51:13] <Dark_Shikari> 18:51 < j^> if thats not public, remove it from avformat.h [07:52:35] <elenril> more like add an av_ prefix [07:55:50] <wooster> i'm trying to port ffmpeg to perl [07:55:57] <wooster> i'm transcoding from mpeg4 to mpeg4 to test [07:56:00] <wooster> i get these errors http://pastebin.com/LK5wtJFw [07:56:07] <wooster> anyone know what might be causing them? [07:56:17] <wooster> i get video output that looks vaugly correct [07:56:28] <wooster> but its pretty messed up [07:56:52] <_av500_> port to perl? [07:56:58] <wooster> yea [07:57:12] <_av500_> you rewrote all the c code in perl? [07:57:12] <thresh_> morning [07:57:22] <wooster> not all of it yet, but yea kinda [07:57:33] <kierank> erm [07:57:37] <wooster> https://github.com/revmischa/Video-FFmpeg-Streamer [07:57:44] <elenril> well wow, that sound lilke a totally cool and not at all braindead idea [07:57:53] <wooster> i am wrapping the features of ffmpeg in XS [07:57:54] <thresh_> ;) [07:58:09] <kshishkov> elenril: my sarcasm detector melted [07:58:21] <wooster> it IS totally cool don't hate [07:59:04] <wooster> anyway does anyone know what those errors might be about? [07:59:09] <elenril> kshishkov: your sarcasm detector wasn't cool enough [07:59:52] <drv> probably using symbols in libavformat which are now in libavcodec [08:00:03] <drv> (there is a compatibility wrapper in lavf now to call the new location) [08:00:40] <wooster> ok, any idea what those might be? and is the "recompile" suggestion misleading? [08:01:50] <_av500_> it misleads you into having higher performance [08:02:09] <drv> those shouldn't cause any problems anyway, just extra noise in the log [08:02:18] <wooster> i mean recompiling won't help me, the problem is with the code [08:02:33] <wooster> i'm more concerned about the mpeg errors [08:02:44] <wooster> i have no idea where to even start to look for the cause of that [08:03:24] <_av500_> well, compare to what your perl does to some known good usage of ffmpeg [08:03:32] <_av500_> -to [08:03:42] <drv> as a first tack, grep for the error message and work backwards from there... [08:04:54] <wooster> ffmpeg does it totally fine [08:05:06] <_av500_> so compare the call sequence [08:05:10] <_av500_> and params used [08:05:31] <wooster> tryin' [08:06:16] <wooster> just wondering if anyone knew of a probable cause [08:35:41] <elenril> hey Yuvi [08:36:59] <thresh> good morning [08:37:53] <Yuvi> hi elenril [08:43:02] <elenril> did you hear the news? [08:43:25] <elenril> also is there some specs or at least samples for mov chapters? [08:43:40] <Yuvi> news? [08:43:50] <Yuvi> if it isn't in qtff.pdf, probably not [08:44:03] <Yuvi> samples sure [08:44:11] <elenril> revolution etc [08:44:51] <Yuvi> Tunisia? [08:45:02] <elenril> ffmpeg [08:45:12] <elenril> there was a coup d'etat [08:45:14] <kshishkov> elenril: wo cares? [08:45:18] <Yuvi> hm, haven't been following the ML [08:45:19] <elenril> the news sites were full of it [08:48:10] <kshishkov> elenril: cnn.com? bbc.co.uk? lidovenovyny.cz? [08:48:35] <kierank> theonion.com [08:59:36] <Yuvi> elenril: http://www.mediafire.com/?3x5p0krks52ebao is what I like to use as an example for mov chapters+subtitles [09:01:15] <elenril> great, thanks [09:01:22] <Yuvi> err, closed captions actually [09:03:08] <Yuvi> though you can do pretty funky things with chapters since they're considered a regular track; that's just the most typical way they're stored I think [09:03:52] <elenril> i'm not going to do anything fancy with them, i was just planning to do some cleanup on your code [09:04:24] <elenril> i.e. i want to unify all the variants of 'read utf-16 string&convert to utf-8' throughout lavf [09:04:44] <Yuvi> sounds good [09:05:00] <Yuvi> the file I posted might use macroman (i forget) but iirc the code ignores that [09:10:03] <lu_zero> siretart: you should have -fPIC [09:11:47] <siretart> lu_zero: shouldn't configure figure that out by itself? - it used to work like that in the past [09:11:58] <siretart> btw, what's the correct clone url for people having push access? [09:14:16] <lu_zero> git@git.ffmpeg.org:ffmpeg [09:14:21] <lu_zero> port 2222 [09:14:26] <siretart> ah, ok. thanks! [09:14:40] <lu_zero> siretart: it should [09:15:23] <lu_zero> let me see [09:15:52] <siretart> I've changed the packaging to include V=1 [09:15:59] <siretart> perhaps that gives more insight [09:15:59] <lu_zero> CONFIG_PIC=yes [09:16:33] <lu_zero> and the *FLAGS got PIC as well [09:17:31] <CIA-29> ffmpeg: Reinhard Tartler <siretart(a)tauware.de> master * r305ca590cf ffmpeg/ffserver.c: [09:17:31] <CIA-29> ffmpeg: ffserver: cleanup [09:17:31] <CIA-29> ffmpeg: remove the trivial function do_switch_stream as it doesn't help to make [09:17:31] <CIA-29> ffmpeg: the code easier to understand. [09:18:27] <siretart> okay, let's see if this daily sync/building via bzr to launchpad ppa machinery actually works :-) [09:21:34] <cartman> http://cekirdek.pardus.org.tr/~ismail/3.png screw UV =P [09:40:41] <_av500_> cartman: i liked the one on drugs better [09:41:22] <cartman> _av500_: heheh [09:41:41] <cartman> _av500_: trying to parse 2x2 pixels correctly [09:41:54] * cartman blames the wikipedia algo. [09:43:21] <cartman> it says; u = yuv[(position.y / 2)* (size.width / 2) + (position.x / 2) + size.total]; [09:43:27] <cartman> but there is a note [09:43:30] <cartman> Here "/" is Div not division. [09:43:35] <cartman> wtf is Div not a division. [09:44:04] <_av500_> maybe / is a "half comment" [09:44:09] <elenril> divergence? [09:44:15] <_av500_> // / 2 [09:44:26] <cartman> _av500_: agreed [09:44:26] <cartman> elenril: wut? [09:44:48] <_av500_> its a diversion [09:45:01] <_av500_> or a divination [09:45:04] <cartman> uhm never heard of it [09:46:09] <_av500_> cartman: wtf is that formula anyway? [09:46:22] <cartman> _av500_: traversing a YUV420 frame [09:46:30] <_av500_> packed or planar? [09:46:33] <cartman> Planar [09:46:43] <_av500_> ah [09:46:53] <_av500_> but you dont do it like that anyway [09:46:58] <cartman> doesn't work correctly for U/V as expected [09:47:03] <_av500_> you setup a Y and U and V pointers [09:47:04] <wbs> cartman: I think it means integer division (in contrast to real division) [09:47:20] <_av500_> and you increment the pointers [09:47:22] <cartman> wbs: ah my code already does that but not working :/ [09:47:48] <cartman> _av500_: since a 2x2 square has the same U/V values how do you handle that case? [09:49:35] <cartman> _av500_: first you setup Y/U/V pointers and then you create Y,U,V tuples? [09:49:44] <_av500_> cartman: er [09:49:55] <_av500_> you convert 2 lines at a time [09:50:06] <cartman> that makes sense :D [09:50:10] <cartman> lol [09:50:10] <_av500_> so you have Y1 and Y2 pointers [09:50:16] <_av500_> and 2 RGB pointers [09:50:48] <_av500_> and you use U and V for both lines [09:50:50] <cartman> Y1,U1,V1 and Y2,U1,V1 and such... [09:51:01] <_av500_> yep [09:51:07] <cartman> thanks! [09:51:24] <_av500_> if you want it extra super, you take care about the positions of U and V [09:51:42] <_av500_> but you need to only for h264 vs theora banchmarks [09:51:47] <cartman> lol :> [09:52:18] <cartman> ok time to take care of the $WIFE[0], see you!;P [09:52:46] <_av500_> i see he made it an array, just in case... [10:31:44] <pross-au> q: i have a 1MiB sample file for inclusion in fate test suite, where do i upload to, who do i need to tell? [10:35:23] <DonDiego> pross-au: mru handles fate [10:36:00] <pross-au> k [10:44:26] <siretart> drv: when testing the shared libswscale.so, did you --enable-gpl? [10:49:59] <siretart> hm. doesn't make no difference here, linking just fails [11:04:08] <elenril> http://pastebin.com/ndeczvuj << how evil is this? [11:17:56] <Flameeyes> siretart: have you seen my latest mail on -devel by chance [11:17:56] <Flameeyes> ? [11:23:39] <royger> Is there any value in MpegEncContext to know if MPV_decode_mb has been called from encode_thread or from mpeg_decode_slice? And if possible could someone explain to me why is the decoding done twice? [11:24:18] <Dark_Shikari> the encoder has to decode what it encodes [11:24:22] <Dark_Shikari> in order to know what the frame will look like [11:24:24] <Dark_Shikari> to use it as a reference [11:24:51] <j-b> duh, url_* are not public? [11:25:19] <royger> Dark_Shikari: but that will mean calling MPV_decode_mb one time only? [11:25:44] <Dark_Shikari> mpeg_decode_slice sounds like you're decoding an input. [11:25:46] <Dark_Shikari> and then encoding it [11:26:59] <royger> Dark_Shikari: yes, I need to recompress a mpeg2 video modifying the DCT coefficients [11:27:18] <Dark_Shikari> So naturally you call decode twice. [11:27:23] <Dark_Shikari> To decode the input, and then to decode the encoded output. [11:27:51] <royger> Dark_Shikari: I'm modifying the coefficients in MPV_decode_mb_internal, but I only want to do it one time, so I need to know when to do it [11:28:37] <Dark_Shikari> you could try not doing it there [11:28:52] <Dark_Shikari> what is with the horde of people trying to implement such a stupid feature? [11:28:55] <Dark_Shikari> is there some class or something? [11:29:02] <royger> Dark_Shikari: where do you recommend me to do it [11:29:41] <royger> Dark_Shikari: I'm working at the university and they made me work on a previous project, that osmeone started as a modification of ffmpeg to add watermarking to mpeg2 videos [11:29:54] <royger> Dark_Shikari: but the current implementation is a mess, and I'm trying to fix it [11:30:16] <elenril> specifically to mpeg2? wtf [11:30:38] <royger> Dark_Shikari: they modified the DCT coefficients in MPV_decode_mb_internal, but if there's a better place to do it please tell me [11:31:24] <royger> elenril: yes, adding a fingerprinting code to the luminance blocks of I-frames, I thinks it's called a COX algorithm [11:32:55] <pross-au> elenril: re the get_utf16le function, can u make maxlen be optional? [11:33:20] <elenril> pross-au: it already is [11:33:37] <elenril> i.e. it stop either on first null OR on reaching maxlen [11:33:41] <elenril> *stops [11:34:06] <elenril> so you just pass maxlen=INT_MAX or something [11:34:46] <pross-au> ok [11:37:51] <siretart> Flameeyes: I did 'tick' it :-) [11:37:56] <royger> so any clues on where should I modify the DCT coefficients instead of MPV_decove_mb_internal? [11:38:54] * elenril spams some patches [11:40:09] <spaam> elenril: spam? nice. any good stuff this time? 90% off? [11:40:32] <Flameeyes> siretart: mostly was curious if you knew why some of the symbols are not versioned [11:46:52] * Flameeyes is implementing more grep(1)-like features on elfgrep [11:51:48] <siretart> Flameeyes: which one aren't? [11:52:00] <Flameeyes> siretart: see my latest mail ;) [11:58:29] <siretart> Flameeyes: I still don't get which are versioned and which not [11:58:33] <siretart> anyway, food time, bbl [11:58:52] <Flameeyes> siretart: uhm my last mail has a bunch of symbols ending with @ -> those are not versioned [12:00:16] <Flameeyes> uhm food time indeed [12:26:55] <cartman> Ehlo [12:27:21] <Flameeyes> hey cartman [12:27:48] <cartman> Lo Flameeyes [12:28:01] <spaam> cartman: time for $WIFE[1] ? :) [12:28:33] <cartman> spaam thats my Nexus1 ;p [12:29:00] <spaam> i thught that was $WIFE[0] [12:29:53] <cartman> Nah [12:32:20] <cartman> Flameeyes which side you are from ? :D [12:32:31] <mru> the dark side [12:32:34] <Flameeyes> Pasta!!! [12:32:41] <cartman> Lol [12:32:42] <Flameeyes> </hetalia> [12:32:52] <mru> pastafarianism? [12:33:54] <cartman> av500 btw read my CV yet? ;p [12:34:27] <spaam> cartman: you want to work for av500 ? [12:34:54] <cartman> spaam we all work for the evillord [12:35:58] * mru doesn't have a cv, he has a reputation [12:36:41] <cartman> mru av500 insisted for something written [12:36:52] <mru> cartman: that's because you don't have a reputation [12:37:02] <mru> other than for being a turk [12:37:06] <spaam> cartman: i didnt have do make a cv for the job i have now ;D [12:37:23] <cartman> mru not in AV world [12:37:29] <mru> spaam: no, that's not required for sewage pipe cleaners [12:37:59] <spaam> mru: pff. i dont have that kind of work. [12:38:14] * cartman has reputation with his b/w images now [12:39:43] <cartman> mru where is yuv2rgb neon btw? [12:39:54] <mru> in my secret stash [12:40:04] <Dark_Shikari> It's next to his weed. [12:40:11] <cartman> mru sharing is caring [12:40:29] <mru> and stashing is hashing [12:40:37] <cartman> Right [12:40:59] <spaam> cartman: what did you share with mru? :) [12:41:00] <mru> I can give you the md5sum of it [12:41:28] * Flameeyes prods mru in saying something about the unversioned symbols he saw [12:41:53] <cartman> spaam my weed and neon lights [12:42:27] <spaam> nice [12:42:56] <Flameeyes> cartman: I thought for hydroponics(sp?) one has to use halogen? [12:43:05] * cartman hash Turkish delight stack [12:43:53] <cartman> Flameeyes weed does wonders [12:44:27] <Flameeyes> stack? you smoke the freshest first? [12:44:58] <cartman> Flameeyes you ever eat Turkish delights? [12:45:26] <Flameeyes> no idea what you're referring to tbh [12:46:10] <cartman> Flameeyes kindly noted. Will fix that sometime ;) [12:48:35] <cartman> Nexus1 keyboard killing me [12:49:23] <mru> Flameeyes: sodium lamps [12:49:53] <Flameeyes> right so no neon :P [12:54:26] <elenril> crazy time (100ns since 1 Jan 0001) << lol [12:54:33] <Flameeyes> uhm I think I exaggerated on the garlic in this imitation of Nando's peri-peri :( [13:13:36] <siretart> urmpf? I managed to reproduce it, now it just works. I'm seriously confused now. [13:14:09] <mru> blame phase of the moon [13:19:02] <siretart> The Moon is Waning Gibbous (82% of Full) [13:20:01] <ohsix> Today is Pungenday, the 23rd day of Chaos in the YOLD 3177 [14:06:08] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r2b39962eb6 ffmpeg/Makefile: [14:06:08] <CIA-29> ffmpeg: Makefile: simplify test tools handling [14:06:08] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:08:39] <mru> DonDiego: any opinions on the other getbits patches? [14:14:34] <BBB> I'm looking at the libmpeg2 one [14:14:38] <BBB> why is it there in the first place? [14:14:52] <mru> nobody knows [14:15:03] <BBB> and what's the A32_BITSTREAM_READER? [14:15:37] <lu_zero> yawn [14:15:39] <mru> it's allegedly faster on some machines without unaligned memory access [14:15:40] * lu_zero wakes up [14:16:22] <BBB> I see [14:16:40] <BBB> and normally we use ALT_? [14:16:54] <mru> yes [14:17:05] <BBB> so libmpeg2 is just cruft and probably doesn't even work? [14:17:16] <mru> it doesn't work [14:17:18] <lu_zero> possibly [14:17:21] <mru> I tested it yesterday [14:17:28] <mru> fails on numerous tests [14:17:33] <mru> as stated in the comment [14:17:49] <BBB> mpeg, h264 [14:17:50] <BBB> yeah [14:17:54] <BBB> important enough to me [14:18:14] <BBB> ok, ack then [14:18:18] <BBB> (just emailed) [14:18:20] <mru> and at least the h264 ones are nontrivial to fix [14:18:37] <mru> svq1 and a few other obscure ones are easily fixed [14:18:48] <mru> but what's the point when important codecs remain [14:19:20] <BBB> license issue also [14:19:23] <BBB> gpl vs lgpl [14:19:25] <BBB> just remove it [14:19:36] <BBB> is libmpeg2 significantly faster? [14:19:57] <mru> the code doesn't come from libmpeg2 [14:20:02] <mru> it's just using the same strategy [14:20:14] <mru> loading 16 bits at a time from the buffer [14:20:34] <mru> but loading 32 bits is just as fast [14:20:36] <mru> and lasts longer [14:20:47] <BBB> so it's slower [14:20:55] <BBB> ok, then DEFINITELY remove it :-p [14:21:01] <mru> it's not quite that clear-cut [14:21:27] <mru> I did some benchmarks a few years ago, and they were all very close [14:21:31] <lu_zero> uh? [14:21:44] <BBB> hi lu_zero [14:21:51] <BBB> headache better now? [14:22:01] <lu_zero> BBB: fever almost gone \o/ [14:22:40] <BBB> good :) [14:23:16] <lu_zero> the sample I took wasn't good [14:23:35] <lu_zero> j-b: how to make vlc reply to requests by sending an I frame first? [14:23:43] <BBB> h264 bug? [14:23:44] <BBB> ugh [14:23:52] <BBB> or well mpegts bug I hope :-p [14:24:06] <lu_zero> BBB: vlc misconfiguration/bug first [14:24:28] <lu_zero> mpegts could be improved to cope with that probably [14:25:08] <j-b> lu_zero: rtsp? [14:27:07] <lu_zero> http [14:27:18] <j-b> http/ts streaming from vlc? [14:27:22] <lu_zero> yes [14:27:41] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r938f72e199 ffmpeg/libavcodec/get_bits.h: (log message trimmed) [14:27:41] <CIA-29> ffmpeg: Remove "libmpeg2" bitstream reader [14:27:41] <CIA-29> ffmpeg: Using the libmpeg2 reader causes errors in a multitude of places, [14:27:41] <CIA-29> ffmpeg: including MPEG and H264 codecs. As the advantage of this reader [14:27:41] <CIA-29> ffmpeg: is questionable, removing it seems the sensible course of action, [14:27:42] <CIA-29> ffmpeg: especially considering the simplifications this allows elsewhere [14:27:43] <CIA-29> ffmpeg: with the bit cache size increasing from 17 to 25 bits as minimum. [14:28:57] <mru> btw, note the pretty right margin in the commit message [14:29:07] <mru> I suggest we make that mandatory :) [14:29:33] <ruggles> what is the advantage of using do{ }while(0) around a macro instead of just { } ? [14:29:46] <mru> if (foo) macro(); else stuff; [14:30:20] <ruggles> just putting braces would work too in that case [14:30:23] <mru> no [14:30:30] <mru> it would give a dangling else [14:30:34] <ruggles> oh, yeah it would screw some stuff up [14:31:01] <Vitor1001> Stupid git questions (not covered in doc/git.txt): [14:31:13] <ruggles> i like to avoid using ; after macros [14:31:19] <mru> that's stupid [14:31:20] <Vitor1001> How do I revert my local (uncommitted) modification done in files? [14:31:56] <mru> Vitor1001: "git checkout $file" for a single file or "git reset --hard HEAD" to discard all uncommitted changes [14:32:13] <ubitux> ruggles: it breaks the indent of the editor if you do that [14:32:23] <ubitux> i mean, if it's code [14:32:45] <mru> not only that, it forces you to remember exactly which names are macros and which are functions [14:32:47] <Vitor1001> mru: Nice, thanks. Also, is ti normal that "git diff" does not show new files? [14:32:54] <mru> yes [14:32:58] <mru> try git status [14:33:02] <mru> that will list untracked files [14:33:06] <j-b> lu_zero: no idea, then [14:37:23] <Vitor1001> mru: works fine, thanks [14:43:38] <Vitor1001> mru: If I just reply to an old thread with a file generated by git format-patch, will patchwork catch it up? [14:43:56] <mru> sometimes [14:44:17] <mru> wait, I see what you mean [14:44:19] <mru> probably not [14:44:25] <mru> but don't worry about that [14:44:37] <Vitor1001> ? [14:44:52] <mru> if you reply to a patch not in patchwork, it will probably be ignored [14:45:24] <mru> but all new patches are picked up, so let's just deal with old ones like we always have done [14:45:28] <Vitor1001> If the very reason I'm replying to a old patch is to make it being caught by patchwork, this is a big problem [14:45:43] <Vitor1001> s/old pathc/old thread/ [14:45:53] <mru> just resend the patch then [14:45:59] <Vitor1001> Ok [14:46:24] <Vitor1001> And patchwork will take what as the short description? [14:46:35] <Vitor1001> The subject of my email, or the one in the diff? [14:46:47] <mru> why are they different? [14:47:16] <Vitor1001> I'd like to use "Old patches thread for patchwork" as subject [14:47:19] <Vitor1001> or something like that [14:47:46] <Vitor1001> So only people interested in old patches will look at it [14:48:08] <jannau> Vitor1001: patchwork should catch all new emails with patches [14:48:22] <jannau> unless it has problems parsing it [14:48:38] <Vitor1001> jannau: Nice, because just replying to the old, original thread, makes much more sense [14:49:02] <Vitor1001> jannau: How fast does patchwork refreshes? [14:49:16] <mru> realtime more or less [14:49:21] <jannau> as soon as the mail get's there [14:49:26] <Vitor1001> So I'll just try it. [14:50:29] <Vitor1001> Nice, it works! [14:57:02] <jannau> hmm, it just added my 'Acked-by:' [14:57:56] <elenril> can patchwork.ffmpeg.org link to it? [14:59:36] <tjoener> hello [14:59:46] <tjoener> I think I found a bug in the ffmpeg h264 decoder [15:00:06] <jannau> elenril: it will become patches.ffmpeg.org [15:00:35] <elenril> great [15:01:07] <tjoener> I've got a scene that gives a small artifact which does not show in DXVA [15:02:54] <iive> tjoener: do you know what is the encoder that created this sample? [15:04:13] <tjoener> no I do not [15:04:17] <tjoener> it's from a bluray [15:04:57] <tjoener> I'm trying to extract the frame that causes the issue [15:04:58] <jannau> tjoener: it plays fine with software decoder? [15:05:02] <tjoener> I think it's an IDR [15:05:13] <tjoener> no it plays fine with the hardware decoder in my gpu [15:05:30] <tjoener> the software decoder (mplayer ==> so ffmpeg) gives the artifact [15:05:38] <tjoener> its the only one ive come across [15:06:02] <tjoener> so maybe its a fault in the bitstream, but i was thinking maybe someone could look at it [15:06:26] <jannau> tjoener: sorry, I can't read [15:06:58] <tjoener> np [15:07:07] <tjoener> H264Visa doesnt show it either [15:07:14] <tjoener> so I guess it really has to be ffmpeg [15:07:16] <tjoener> sorry :( [15:08:32] <jannau> tjoener: do you know the file offset of that frame? you can probably just cut it out with 10M before and after [15:08:43] <tjoener> yeah, been trying to find out :) [15:08:47] <tjoener> its an intra [15:08:51] <tjoener> or an IDR [15:08:56] <tjoener> always get those confused [15:09:01] <kierank> do a bisect [15:09:09] <kierank> probably the intra asm functions [15:10:22] <BBB> tjoener: cut out the frame and send it to roundup, I'll look at it [15:10:40] <BBB> tjoener: also, which software do you use to play (ffplay? vlc?) what commandline and which version? [15:10:44] <BBB> (which date) [15:11:29] <tjoener> crap, its not an IDR [15:11:35] <tjoener> need the others too [15:13:26] <tjoener> so from frame 1 to 49 everything is ok, on frame 50, an I frame, it shows the little error [15:13:42] <tjoener> dont know how legal it is to send 50 frames of a BR over the internet [15:14:49] <kierank> it is fine [15:16:22] <tjoener> its 5MB [15:16:27] <tjoener> dropbox is ok? [15:25:48] <jannau> ftp://upload.mplayer.hu would be preferred [15:26:15] <jannau> see http://ffmpeg.org/bugreports.html [15:28:58] <BBB> tjoener: and then ping me once it's uploaded and you've put a description on roundup [15:31:47] <BBB> elenril: why the get_str16be()? are you going to use that? [15:32:43] <BBB> elenril: and for asfdec 2/4, have you tested that code by artificially failing at those codepoints? [15:33:04] <BBB> elenril: oh n/m the first comment, I see that's mov.c patch [15:50:40] <elenril> BBB: yes, worksforme [15:51:07] <elenril> (not like anybody cares about asf, i wonder why i'm working on it anyway) [15:58:36] <tjoener> elenril: lot's of porn is in asf :) [16:02:18] <tjoener> BBB: it's at upload.ffmpeg.org in the folder MPlayer/incoming (thats what the guide said) [16:02:24] <tjoener> name is "small-artefact-on-frame-53.264" [16:04:22] <tjoener> its between the letters p and i in "pictures" [16:05:14] <tjoener> and my apologies, I appear to have forgotten to make a directory [16:05:38] <BBB> mru: the ftp doesn't work well at all, I keep getting timeouts [16:06:17] <BBB> mru: can you check permission on that file? [16:06:36] <mru> timeouts doing what? [16:07:13] <mru> try again [16:12:09] <BBB> yes works now [16:12:21] <BBB> was it a permission problem? [16:12:25] <BBB> chrome's error reporting sucks :-p [16:12:52] <mru> yes [16:14:05] <BBB> tjoener: which software? [16:14:15] <tjoener> I used mplayer to play it [16:14:20] <tjoener> r.... [16:14:20] <tjoener> sec [16:14:34] <tjoener> MPlayer SVN-r32492-4.2.5 [16:14:47] <tjoener> I do not know which version of ffmpeg that is sadly [16:15:03] <tjoener> if you have an svn ffmpeg build that can play something, i'll check [16:18:27] <Vitor1001> mru: I'm not doing your zlib patches since I'm pretty sure you have them in a git tree somewhere [16:18:37] <mru> I do indeed [16:18:44] <mru> and newer versions of them too [16:18:49] <lu_zero> nice =) [16:19:09] <mru> there's still a nasty corner-case bug I need to take care of [16:19:27] <tjoener> BBB: if the checkout is of the same date as the revision, it could be either of 25473 or 25472 [16:19:47] <lu_zero> btw for ssl needs should we use an external lib or try to bake something out what we have? [16:20:31] <mru> let's link to openssl and watch debian get its knickers in a twist [16:22:17] <siretart> there are much nicer ssl implementations than openssl [16:22:27] <lu_zero> I was thinking nss [16:22:27] <elenril> gnutls? [16:22:40] <lu_zero> elenril: gnutls is... icky [16:22:41] <mru> pick your licence poison [16:22:59] <tjoener> oh and x264 has the same issue [16:23:02] <elenril> lu_zero: what's so bad about it? [16:23:08] <mru> it's gnu [16:23:12] <mru> what do you expect? [16:23:21] <elenril> gnu make is rather nice [16:23:26] <elenril> OrSoIHeard [16:23:32] <mru> that's the exception [16:23:42] <mru> and I'm sure the code is ugly as sin [16:23:55] <mru> moreover, make isn't critical for security [16:24:09] <tjoener> bbb: and the version I got it from (x264.nl) uses ffmpeg revision 25563 [16:24:24] <elenril> openssl isn't gpl-compatible :/ [16:24:39] <elenril> for no better reason that lolitrollu [16:24:41] <mru> 4 minutes, not bad [16:25:18] <kshishkov> elenril: please all well-written GNU projects [16:27:09] <tjoener> i'm playing bfbc2 [16:27:16] <tjoener> if you find anything, let me know :) [16:34:20] <tjoener> or if you need anything else [16:41:48] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rbf5f9b528b ffmpeg/libavcodec/ (get_bits.h mjpegdec.c): [16:41:48] <CIA-29> ffmpeg: Sanitise get_bits macros, part 1 [16:41:48] <CIA-29> ffmpeg: Some of the macros in get_bits.h include a final semicolon, [16:41:48] <CIA-29> ffmpeg: some do not. This removes these or adds do {} while(0) around [16:41:48] <CIA-29> ffmpeg: the macros as appropriate and adds semicolons where needed in [16:41:49] <CIA-29> ffmpeg: calling code. [16:41:50] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:41:50] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rfb5c841d5f ffmpeg/libavcodec/get_bits.h: [16:41:51] <CIA-29> ffmpeg: Sanitise get_bits macros, part 2 [16:41:51] <CIA-29> ffmpeg: These whitespace changes improve the readability of the get_bits [16:41:52] <CIA-29> ffmpeg: macros. [16:41:52] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:41:53] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r611a6f59ce ffmpeg/libavcodec/get_bits.h: [16:41:53] <CIA-29> ffmpeg: get_bits: move tracing macros to end of file [16:44:56] <Vitor1001> mru: Why are you reviewing the patches I'm sending? [16:45:10] <mru> not all [16:45:13] <Vitor1001> Ok. [16:45:14] <mru> that one was easy [16:45:33] <mru> and what's the point in sending them if you don't expect a review? [16:45:34] <Vitor1001> Just to be sure you know the original submitter say he will not be working on it [16:45:38] <Vitor1001> Me neither. [16:46:59] <Vitor1001> The point is that they bitrot more slower if it is easy to apply and test [16:47:27] <Vitor1001> And a nice place where people can look for old, but interesting patches, to work on. [16:47:54] <Vitor1001> I expect someone to work on them to get them committed [16:48:13] <Vitor1001> but revieweing is a second step [16:49:15] <Vitor1001> That said, working on the smush patch looks fun [16:49:27] <mru> nice and simple [16:49:43] <Vitor1001> Exactly [16:49:47] <BBB> tjoener: what is the artifact? [16:49:56] <BBB> tjoener: can you make a png and circle the artifact in photoshop or so? [16:50:10] <BBB> tjoener: or just describe where it is [16:51:37] <BBB> tjoener: because I don't see anything on frame 53 between the p and the i [16:51:46] <BBB> tjoener: so it may have been fixed already or I'm looking at the wrong frame [16:52:28] <BBB> nothing in the frames around it either [16:52:50] <BBB> tjoener: probably it's fixed already, this is probably the plane overflow asm that I fixed 1-2 weeks ago [17:05:47] <j-b> any know regressions on Wavepack in master? [17:08:04] <kshishkov> ? [17:15:33] <BBB> j-b: not that I know [17:16:10] <j-b> ok, weird [17:16:18] <tjoener> ah BBB: could be, i'll post an image [17:16:30] <BBB> ok thanks [17:20:18] <tjoener> BBB: http://tjoener.be/Upload/shot0001.png [17:20:26] <tjoener> and http://tjoener.be/Upload/shot0002.png [17:21:33] <tjoener> the 0001 is the first error, the 0002 is 2 frames later, and it stays that way [17:21:41] <tjoener> until the next keyframe [17:26:25] <tjoener> BBB: is that revision 26381 you fixed? The plane 16x16 ASM? [17:34:58] <BBB> tjoener: I can't reproduce the bug, and I'm almost definitely sure that the plane asm fix fixed it [17:35:25] <BBB> yes that's 26381 [17:35:45] <BBB> it looks a lot like the artifact produced by that bug [17:36:06] <tjoener> aaah [17:36:48] <tjoener> BBB: care to enlighten what the bug waS? I'm not really an ASM guy, but I am interested, because that has to be a cornercase if I ever saw one [17:37:06] <tjoener> been using the software h264 decoder a while and never saw something like this [17:37:33] <BBB> tjoener: it's an integer overflow [17:38:19] <BBB> tjoener: for plane16x16, you take the top edge 16 pixels and multiply them by 8,7,6,5,4,3,2,1,0,-1,-2,-3,-4,-5,-6,-7,-8 (from top-left edge to end of the row above) [17:38:26] <BBB> tjoener: then you multiply that with a constant [17:38:26] <tjoener> indeed [17:38:36] <BBB> tjoener: the overflow occurs on b/w boundaries [17:38:51] <BBB> such as dark/light text on a light/dark background halfway the MB [17:38:57] <tjoener> ah yes [17:39:04] <tjoener> so it just needed a particular mb [17:39:09] <BBB> what happens is that you get 8+7+6+5+4+3+2+!)*255*multiplyconstant-(8+...)*0 [17:39:18] <BBB> and that basically _just_ overflows wordsize [17:39:23] <BBB> I was calculating that in wordsize [17:39:29] <BBB> changing it to dwordsize fixed it [17:39:30] <tjoener> like in 99.9% of plane i16x16s it wouldnt be a problem [17:39:35] <BBB> exactly [17:40:15] <tjoener> and offcourse, pixars razorsharp graphics had to contain one of those :) [17:40:20] <BBB> \o/ [17:40:54] <tjoener> a word is 16 bits right? or are we using the modern equivalent now? [17:45:21] <tjoener> BBB: I thank you for addressing this [17:45:32] <tjoener> Now I'll be looking for new builds :) [17:51:55] <BBB> tjoener: np and yes a word is 15 bits + 1 sign bit [17:53:12] <tjoener> so a short, ok [17:53:45] <tjoener> brb [17:53:46] <tjoener> dinner [17:57:16] <CIA-29> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * r2fd9035ddc ffmpeg/libavcodec/aacenc.c: aacenc: fix typo in sync extension constant in 8ae0fa2 [18:04:16] <j-b> kshishkov: does your patch support 8channels in .wv ? [18:06:06] <kshishkov> I've tested it with 7.1, seemed to work [18:10:55] <BBB> Vitor1001: ah thanks for the fate test :) [18:12:24] <kshishkov> j-b: but who cares, I don't think anyone is going to review it let alone applying [18:12:40] <j-b> kshishkov: well, I care [18:13:05] <j-b> but, true, I cannot apply :) [18:13:06] <kshishkov> j-b: there's somebody caring about Bink-b but he's also ignored [18:14:52] <kshishkov> BBB: also if you're interested I've tried to add RV4 PTS parser but playback was still not ok even if parser gave correct PTSes [18:16:28] <BBB> kshishkov: don't be so pessimistic, we're trying to review everything we get [18:17:18] <kshishkov> BBB: well, now you have very old patches in queue, some of them because of me :( [18:18:17] <Vitor1001> BBB: You are welcome [18:18:34] <Vitor1001> But if you could give some help suggesting some name for the test, it would be nice [18:18:56] <Vitor1001> I don't really understand all the details of the bug it concerns [18:19:27] <kshishkov> bbb-ununderstood-bug [18:19:28] <Vitor1001> (I suppose that if one do some operations in the wrong order some quantity overflows) [18:19:49] <Vitor1001> kshishkov: descriptive. [18:19:58] <j-b> kshishkov: ok, if you care, I've tested the 5.1 on my 5.1 system and it works fine [18:20:00] <BBB> Vitor1001: no, the reordering just helped to prevent increasing instruction count [18:20:09] <j-b> kshishkov: setting up my 7.1 system to test the other on [18:20:27] <BBB> Vitor1001: the problem is plane 16x16 overflow on MBs where the left and right have sharp contrast (e.g. black/white border or so) [18:20:28] <kshishkov> j-b: I've tested it only with mono, stereo, 4.0, 5.1, 6.1 and 7.1 [18:20:44] <BBB> Vitor1001: just call it plane-hcoeff-overflow or so [18:20:46] <j-b> kshishkov: I meant with my 7.1 output [18:20:47] <kshishkov> j-b: by decoding to file and using Audacity afterwards [18:20:58] <Vitor1001> Maybe h264-issue-2547 [18:21:04] <jannau> applying is not the problem once it's reviewed [18:21:17] <Vitor1001> It makes a nice precedent for bugs created after an issue [18:21:20] <kshishkov> jannau: you spoil all the fun [18:21:31] <Vitor1001> and an easy way to find out more about the sample [18:21:55] <kshishkov> Vitor1001: h264-hiprecision or intoverflow would be better [18:22:05] <mru> Vitor1001: just name the function that's problematic [18:22:18] <mru> then if it fails, we know where to look [18:22:39] <j-b> kshishkov: 5.1 order is correct [18:22:48] <Vitor1001> I like the idea of using the issue number. [18:22:52] <mru> I don't [18:22:55] <Vitor1001> Does anyone see any disadvantage? [18:23:01] <mru> that's a useless level of indirection [18:23:23] <BBB> Vitor1001: ok also [18:23:27] <BBB> 2393 iirc [18:23:30] <mru> what is the name of the thing where it overflows? [18:23:38] <kshishkov> j-b: sorry [18:23:48] <Vitor1001> Ok, both can be done, a comment in .mak indicating the issue # [18:23:52] <BBB> mru: hcoeff [18:23:53] <Vitor1001> brb, dinner [18:24:03] <jannau> mru: patches.ffmpeg.org should work once it has a dns entry [18:24:06] <mru> so call it h264-hcoeff-range [18:24:36] <BBB> h264-plane16x16-hceff-... [18:24:55] <mru> fine with me [18:25:05] <j-b> kshishkov: works with the right order, in .wv and mkv for 4.0, 5.1 and 7.1 on windows [18:25:16] <BBB> feeding baby sorry for the typos :-p [18:25:22] <mru> then if it fails, we know immediately where to look [18:25:29] <BBB> right [18:26:17] <kshishkov> j-b: I'm terribly sorry, use vanilla FFmpeg repo [18:27:15] <j-b> can't I use the chocolate one? [18:27:42] <kshishkov> I don't remember having Swiss fork [18:27:56] <j-b> too bad [18:28:02] <mru> jannau: done [18:28:08] <kshishkov> so we have only vanilla, extrawürst and surströmming flavours [18:28:15] <j-b> kshishkov: well, I may just apply the patch before doing the windows release and wait [18:28:33] <wbs> DonDiego: stdint.h is implicitly included by avcodec.h iirc, individual .c files don't need to include it (no ohter ones does) [18:29:06] <DonDiego> wbs: i disagree with that policy [18:29:21] <mru> +1 [18:29:40] <DonDiego> when you shuffle #includes around, you will get a cascade of breakage [18:29:48] <kshishkov> j-b: so you're going to fork and create fricasse+escargot flavour? [18:29:59] <DonDiego> that's why i advocate making files as standalone as possible, headers more so [18:30:18] <DonDiego> mru: still want me to look at some patch? [18:30:36] <mru> DonDiego: my immediate queue is empty right now [18:30:45] <mru> I have dozens more though [18:30:53] <DonDiego> ok, keep them coming :) [18:31:29] <wbs> generally yes, but _everything_ in ffmpeg uses stdint.h, any one of the headers will include it, especially if you explicitly include avcodec.h, I'd count on it already being included [18:31:36] <mru> DonDiego: as you wish [18:31:47] <wbs> but headers should be standalone yes, as make checkheaders tests [18:36:59] <mru> wbs: never assume anything [18:37:22] <mru> if documentation says one header includes another, then it's ok to only include the first [18:37:30] <mru> as with inttypes.h and stdint.h [18:38:06] <wbs> could we spec somewhere that avcodec/avformat/avutil.h do include stdint.h so individual .c files don't need to explicitly include it, then? [18:40:04] <mru> jannau: could you hack the patch view with a link to http://news.gmane.org/find-root.php?message_id=$id ? [18:40:24] <mru> the message is already displayed so it can't be that hard [18:42:48] <soroushi> Hi [18:43:02] <soroushi> I am using VLC to stream on RTP and use FFmpeg save it to file but the saved video has unacceptable jitter, freezing and, seemingly, frame drops. here is the command line and output: http://pastebin.com/hDMx3PNd [18:43:27] <DonDiego> soroushi: #ffmpeg is your channel [18:43:44] <soroushi> ok [18:44:25] <mmu_man> grr stupid VLC, when asking to record all streams it plays both english and french streams also, and selecting one drops the other in the stream dump, bleh [18:44:39] <jannau> mru: I'll look [18:45:01] <mru> mmu_man: who needs french anyway? [18:45:39] <spaam> mru: j-b and ubitux ... [18:45:46] <kierank> vlc broke my mouse [18:45:53] <kierank> i had to unplug it an replug it [18:45:54] <kierank> :/ [18:46:01] <spaam> :( [18:46:05] <ubitux> spaam: mmh? [18:46:23] <spaam> ubitux: read the like above.... [18:46:27] <spaam> line [18:46:38] <j-b> mmu_man: recording how? [18:46:38] <ubitux> I hate dubbed audio stream [18:47:01] <ubitux> and i really don't care about a single french thing [18:47:11] <kshishkov> us neither ;) [18:47:21] <mru> ubitux: not even cheese or wine? [18:47:34] <ubitux> i don't drink alcohol :) [18:47:46] <mru> cheese is neither alcoholic nor drunk [18:47:49] <ubitux> and i eat cheese just because you don't need to prepare it :) [18:47:50] <jannau> mru: done [18:48:07] <kshishkov> mru: it's either runny or mouldy [18:48:24] <kshishkov> mru: and for mouldy Adelost would do just as fine [18:49:31] <_av500_> cheddar ftw [18:49:45] <kshishkov> _av500_: tss, don't tell mru [18:50:14] <_av500_> i wont [18:51:27] <jannau> and committed patches have now a link to the gitweb commit too [18:52:38] <j-b> mmu_man: seeing that they are 4 main ways of recording, this is too vague, sorry [18:53:03] * kshishkov goes to drool over http://www.arla.se/Default____17804.aspx?SelectedMenuItem=18401 [18:53:51] <_av500_> is this genuine cheddar and D.O.C ? [18:54:10] <mru> that's cheap swedish imitation [18:54:27] <mru> real cheddar comes from Cheddar [18:54:35] <kshishkov> of course [18:54:58] <kshishkov> though I guess it's hard to find even there [18:55:08] <mru> there are actually regulations about that [18:55:25] <_av500_> the cheddar act [18:55:31] <mru> indeed [18:55:33] <mru> 1856 [18:55:46] * kshishkov likes cheese from area around Umeå [18:55:47] <_av500_> thouc shalt not have any other cheese beside me [18:56:10] <kshishkov> _av500_: and you are completely right - they don't have [18:58:29] <kshishkov> mru: any word against Västerbottenost? [18:59:17] <mmu_man_> j-b: -v --sout-all "$u" --sout '#duplicate{dst=display,dst="standard{mux=ts,dst=/Volumes/Data/continuum.ts,access=file}"}' [18:59:33] <mmu_man_> u=rtsp://... [19:00:14] <mmu_man_> great being able to record all audio, but not so nice having to listen to all of them at once :p [19:01:57] <j-b> mmu_man_: because you ask display inside the sout [19:02:06] <j-b> mmu_man_: you need to see too? [19:03:46] <mmu_man> well it's easier to know when to cut :p [19:04:01] <j-b> mmu_man: why not using the record button then? [19:04:09] <mmu_man> the other option being to read the dump with another instance but it lags a bit [19:04:10] <mru> kshishkov: västerbottenost is nice [19:04:22] <mmu_man> record button ? [19:04:31] <mmu_man> I don't think VLC has this in OSX yet [19:04:40] <j-b> mmu_man: shift+'r' [19:05:01] <j-b> and fuck, I need to change the UI [19:05:04] <mmu_man> oh, good to know, though I'm not sure the shortcuts are the same in OSX [19:05:21] <kshishkov> mru: and I'm not sure if I've seen decent kryddost replacement [19:05:54] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r7a5a168abe ffmpeg/ (libavcodec/mips/mathops.h libavutil/mips/intreadwrite.h): MIPS: use inline asm only when supported by compiler [19:06:33] <j-b> mmu_man: KEY_MODIFIER_COMMAND|KEY_MODIFIER_SHIFT|'r' then [19:07:05] <mmu_man> hmm yeah, the menu shows "Montrer dans le Finder" which is not really the same [19:07:23] <mmu_man> damn I've been complaining about having to go through all the wizard each time [19:08:02] <mmu_man> and the menu entry is even disabled [19:08:06] <mmu_man> but it does record [19:08:11] <mmu_man> now does it record all streams ? [19:08:11] <j-b> mmu_man: not to mention that to sout, the short syntax is better: --sout-all --sout file/ts:///Volumes/Data/continuum.ts [19:08:38] <mmu_man> hmm yeah but it doesn't display then, right ? [19:08:44] <j-b> it doesn't. [19:09:34] <BBB> kshishkov: ask alex (peloverde) to review audio stuff for now [19:09:47] <BBB> kshishkov: I had a quick look at the wavpack patch and don't understand much of it [19:09:55] <BBB> it looks ok but I don't get much of it [19:10:51] <kshishkov> BBB: why? It should be clear enough [19:11:09] <mmu_man> hmm Cmd-Shift-r only record the played channels though, not both audio [19:11:26] <mmu_man> anyway, thx it's still useful for usual things [19:11:50] <j-b> mmu_man: there is an option for that on Mac [19:11:58] <j-b> I just need to find it [19:12:32] <mmu_man_> I was too lazy to even grep the sources to see if there was [19:12:50] <mmu_man_> I recall building vlc on BeOS once and I didn't really want to retry :D [19:14:08] <j-b> mmu_man_: it is much easier now [19:14:12] <j-b> mmu_man_: except on Windows [19:14:43] <kshishkov> and BeOS - hello from FFmpeg [19:15:19] * mmu_man_ throws an Haiku R1/alpha2 CD over kshishkov [19:15:40] <BBB> mru, Vitor1001: for the repeated frames, use vsync 0 [19:15:53] <BBB> looking at the timestamp code is on my list, but not high enough yet [19:16:09] <mru> we should really do something about the timestamp mess [19:16:18] * kshishkov just watches it to crumble into dust in mmu_man hands [19:16:21] <mru> and I want to make -strict 1 default [19:16:56] <siretart> wow, this ffmpeg build failure on amd64 is really strange. sometimes it happens and sometimes it doesn't. /me hates nondeterministic toolchains :-/ [19:17:01] <mmu_man_> Haiku works fine [19:17:11] <lu_zero> Gentoo works fine [19:17:17] <j-b> Hurd works fine [19:17:19] * lu_zero runs [19:17:28] <thresh> windows forks wine [19:17:50] <lu_zero> siretart: jokes aside [19:17:58] <mmu_man> last time I saw, Hurd crashed fine, actually [19:18:05] <lu_zero> the config.mak [19:18:10] <lu_zero> when it fails [19:18:25] <lu_zero> does have PIC enabled? [19:18:49] <siretart> lu_zero: yes. always [19:19:18] <siretart> gcc (Ubuntu/Linaro 4.5.2-1ubuntu6) 4.5.2 [19:19:32] <kshishkov> mmu_man: there's Hurd-NG even [19:20:09] <mmu_man> wow [19:20:15] <mru> when will they make hurd-ds9? [19:20:37] <kshishkov> mmu_man: http://www.gnu.org/software/hurd/hurd/ng.html [19:20:58] <kshishkov> mru: hurd-voyager is the best you can get I fear [19:21:10] <mru> perhaps if cisco were to fork... [19:21:54] <lu_zero> ? [19:22:20] <lu_zero> and the binary sometimes doesn't get built with pick nonetheless [19:28:42] <mmu_man> lol [19:28:47] <mmu_man> reminds me about Lunix-NG [19:29:19] <mmu_man> http://lng.sourceforge.net/ [19:30:05] <saintdev> -ng is so oooold, everything is -Kit now [19:32:07] <mmu_man> bleh, *Kit is nothing new [19:32:13] <mmu_man> BeOS did it 15y ago :D [19:33:06] <saintdev> yeah, but it's the new hotness [19:33:44] <mru> it's the new cargo cult [19:33:48] <mru> cargokit [19:33:59] <mmu_man_> yeah, just like tickless, and many other things ppl claim to have invented :p [19:34:14] <mmu_man_> LicKit :p [19:34:34] <saintdev> mru: cultkit? [19:48:01] <mmu_man> BreaKit [19:52:13] <elenril> how do i configure git show to include a stat by default [19:53:56] <DonDiego> Dark_Shikari: Subject: [FFmpeg-devel] [PATCH] set b_tff in libx264.c since it is not set now [19:55:37] <siretart> hm. is it possible that "-Wl,-Bsymbolic-functions" in LDFLAGS breaks the shared library build? [19:56:09] <mru> siretart: does that override -Bsymbolic? [19:56:17] <mru> if so, it would indeed break things [19:57:54] <siretart> if that is true, then it would explain a lot of confusion here... [19:58:22] <mru> why are you adding that flag? [20:00:22] <siretart> it seems dpkg is injecting this for some reason. not exactly sure why [20:00:55] <Dark_Shikari> DonDiego: I'm working on another ML thread, moment [20:01:18] <DonDiego> Dark_Shikari: sure, just wanted to ping you about that thread [20:01:21] <Dark_Shikari> good idea [20:01:24] <Dark_Shikari> keep pinging me please [20:01:30] <DonDiego> i will :) [20:01:40] <lu_zero> which thread? [20:04:31] <siretart> mru: afaiu the mainpage, -Bsymbolic applies to global variables, and -Bsymbolic-functions to, well, functions. [20:04:43] <siretart> trying another build with LDFLAGS pruned. [20:05:30] <mru> siretart: my interpretation is that -Bsymbolic applies to all symbols, -Bsymbolic-functions only to functions [20:08:00] <siretart> hm. I see. smells like an ld bug to me. [20:08:33] <mru> it was a data symbol it failed on, right? [20:09:08] <siretart> /usr/bin/ld: libswscale/rgb2rgb.o: relocation R_X86_64_PC32 against symbol `ff_bgr2YCoeff' can not be used when making a shared object; recompile with -fPIC [20:09:08] <Dark_Shikari> mru: ridiculous extremal plane test uploaded [20:09:16] <mru> Dark_Shikari: thanks [20:09:19] <Dark_Shikari> I HIGHLY recommend that you test this file with your arm asm, if you have planar pred asm [20:09:28] <Dark_Shikari> it broke a lot of our asm in x264 on 9-bit and 10-bit (but 8-bit managed to work fine) [20:09:28] <mru> will do [20:09:44] <siretart> mru: indeed [20:10:01] <mru> Dark_Shikari: so _where_ is the sample? [20:10:10] <mru> and what is the correct output? [20:11:41] <Dark_Shikari> mru: Just decode with JM for the correct output, what do you want [20:11:48] <Dark_Shikari> the sample is on incoming [20:11:52] <mru> name? [20:11:56] <Dark_Shikari> Look at my email. [20:13:11] <Dark_Shikari> http://pastebin.com/pBVEzkKu <--here's a framemd5 made with the yuv file [20:13:17] <Dark_Shikari> i.e. decode with JM, then send yuv through ffmpeg [20:13:26] <Dark_Shikari> use this to make sure your framemd5 is right (made using ffmpeg without asm or similar) [20:16:07] <Dark_Shikari> (is this sufficient?) [20:16:16] <mru> should be [20:17:00] <BBB> if you find bugs, feel free to put that sample in fate instead [20:17:13] <mru> I intend to [20:17:15] <Dark_Shikari> It should be in fate [20:18:07] <Dark_Shikari> also, that clip triggers another, unrelated cosmetic bug [20:18:09] <Dark_Shikari> which causes ffmpeg to spam warnings [20:21:49] <peloverde> Interesting that michael committed "Remove H.264 encoder fragments" I could have sworn that he was vehemently against it last time it was discussed [20:22:00] <mru> +1 [20:22:06] <mru> same for my getbits cleanup [20:22:14] <Dark_Shikari> lol. [20:22:36] <mru> why do you think I have so many patches queued up? [20:23:17] <ubitux> he does that to easier next merges imo [20:24:17] <siretart> mru: it seems I'm right. When configure runs with LDFLAGS set to "-Wl,-Bsymbolic-functions" breaks the build with that confusing error message [20:24:33] <mru> well, get rid of it [20:24:34] <siretart> this is with binutils 2.21 [20:24:40] <mru> try 2.20 [20:24:40] <siretart> yes, this is what I'm going to do [20:24:57] <siretart> i.e., getting rid of it by pruning ldflags [20:24:58] <mru> what order are the flags? [20:25:33] <siretart> order? I see this in the buildlog: [20:25:47] <siretart> dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions [20:25:58] <mru> yeah, but what ends up in the link command? [20:27:07] <mru> Dark_Shikari: plugging your paste into fate as reference it passes on x86 [20:27:13] <mru> that's all I tested [20:27:23] <Dark_Shikari> ok, great. [20:27:33] <Dark_Shikari> x86 should work, it uses the same algorithm as x264 does iirc [20:27:34] <siretart> -Bsymbolic, then a lot of search directives, then -Bsymbolic-functions [20:27:53] <mru> siretart: so maybe the second flag disables it for data symbols [20:28:03] <mru> ld manual isn't very informative in that regard [20:28:34] <siretart> that's indeed a theory that would explain this mess [20:28:49] <siretart> I'm only glad that I finally found a workaround [20:29:54] <mru> Dark_Shikari: so there's nothing like that in the official conformance tests? [20:30:20] <Dark_Shikari> No way [20:30:38] <Dark_Shikari> official conformance tests also seem to be missing some things like extremal quant situations [20:30:39] <mru> lame [20:43:54] <merbanan> Dark_Shikari: how about we supply some to the proper place ? [20:49:35] <merbanan> ie send them to itu or whatever org holds them [20:55:40] <thresh> andoma: did you succeed in building ffmpeg for PS3? [21:01:29] <andoma> thresh: not really.. the toolchains does still not build the altivec asm code [21:01:45] <andoma> but i've not put more effort into fixing that (yet) [21:01:49] <mru> the intrinsics or the real asm? [21:01:52] <andoma> real asm [21:02:10] <mru> that file is so much fun... [21:02:32] <mru> gnu syntax, apple syntax, different abis, etc [21:02:37] <andoma> yeah [21:02:45] <thresh> andoma: OT: you didnt try backup stuff / games, right? [21:02:53] <andoma> thresh: no [21:03:12] <andoma> i've no interest whatsoever in such things [21:20:30] <BBB> mru: wheheh that looks like the same overflow I had also [21:20:31] <BBB> :) [21:21:01] <BBB> mru: is that the horizontal coefficient (H in C code) right after multiplication before shift-right? [21:21:13] <mru> not really sure [21:21:22] <mru> it looked like a likely place for overflow [21:21:24] <Dark_Shikari> BBB: Look at what we did in x264, btw, for 9 and 10-bit. [21:21:29] <mru> and it was easy to expand to 32-bit there [21:21:35] <mru> so I tried and it worked [21:21:46] <Dark_Shikari> but it's probably not necessary here, just amusing though [21:22:27] <kierank> [20:30] Dark_Shikari: official conformance tests also seem to be missing some things like extremal quant situations --> not as good as the 1080p50 mpeg-2 compliance tests which are actually interlaced videos encoded as progressive [21:23:44] <Dark_Shikari> basically all the common bugs in h264 decoders are things that don't show up in conformance tests [21:23:48] <Dark_Shikari> multi-refdupe with different weights [21:23:59] <Dark_Shikari> delta quant over 26 (since nobody uses delta quant in ref encoders) [21:24:05] <Dark_Shikari> delta quant + PCM blocks [21:32:55] <DonDiego> gnite [22:07:30] <superdump> jannau: that patchwork thing is nice :) [22:08:21] <superdump> nice to have a patch stack thing so one can just look on there and see what needs doing rather than trawling through the ML to see what has been OKed or not [22:08:48] <superdump> though i wonder how it will manage submission of updated patches due to reviews and stuff like that [22:09:03] <mru> not that well is the answer [22:09:09] <superdump> mmm [22:09:34] <superdump> i guess there's some kind of admin method of removing stuff from the list though [22:10:33] <mru> you can set status to superseded or whatever in the web interface [22:10:46] <superdump> good good [22:10:47] <superdump> i like it [22:14:02] <ruggles> arguments in yasm seem to be loading into the wrong registers... where should i start looking for what's going wrong? [22:14:50] <roxfan> what platform? [22:14:56] <ruggles> x86-64 [22:15:55] <ruggles> i imagine something weird is going on in the cglobal/PROLOGUE macro, but i can't tell what... [22:16:15] <roxfan> could it be trying to use win64 calling convention? [22:16:52] <ruggles> o [22:17:23] <ruggles> i'm running ubuntu 64-bit [22:18:41] <ruggles> how do i see the pre-processed output from yasm? [22:19:02] <mru> yasm --help [22:59:45] <mru> hmm, someone likes ifdefs [23:00:02] <j-b> hmm, someone likes ifdef and doesn't know how to read man [23:00:28] <mru> and mangles patches [23:00:53] <j-b> who will give him -D__USE_MINGW_ANSI_STDIO=1 ? [23:01:46] <mru> j-b: feel free to reply [23:01:51] <mru> if you know the answer [23:02:02] <mru> is that something we should be adding to configure? [23:02:10] <j-b> yes [23:02:18] <mru> patches welcome [23:02:22] <j-b> well, in case of mingw, yes [23:02:37] <j-b> this will indeed tell mingw to not use msvcrt mess [23:02:41] <j-b> but its own mess [23:06:26] <j-b> and the patch will be a oneliner + add_cppflags -D__USE_MINGW_ANSI_STDIO=1 line 2377 [23:06:39] <Kovensky> j-b: does its own mess work [23:07:12] <j-b> Kovensky: define "work". [23:07:38] <Kovensky> j-b: what does it do differently from windows' mess? [23:07:54] <j-b> Kovensky: I've been using this mingw mess on VLC for Windows since 3 years, and the VLC debug messages and FFmpeg messages are outputted correctly [23:08:16] <j-b> Kovensky: well, it doesn't use printf* from msvcrt but their own (derived from linux) [23:08:32] <Kovensky> j-b: ah [23:08:45] <j-b> and their own, understand %z , %t or else [23:09:04] <Kovensky> when will they add support for UTF-8 filenames ;_; [23:09:13] <j-b> ;) [23:09:30] <j-b> however, some version of gcc behave differently, so it isn't always the most simple [23:09:48] <j-b> but at least, you don't need to use %Id or other horrible things [23:10:20] <pJok> since when did gcc behave the same between versions? [23:50:00] <peloverde> Is there a way to make gitk show the comitter timestamp instead of the author timestamp? [23:50:31] <mru> hack the source [23:51:38] <j-b> use tig?

1 0

IRC log for 2011-01-22
by irc＠mansr.com 23 Jan '11

23 Jan '11

[00:02:17] <jannau> ubitux: patchwork seems to have problems with your name [00:02:50] <ubitux> just trash it if you need; é → e, œ → oe, i don't really care :p [00:03:01] <spaam> pfff [00:03:30] <spaam> jannau: they need to fix their stuf so it works with the future where we have unicode... [00:04:09] <jannau> spaam: it should handle unicode just fine [00:05:06] <spaam> it should yes.. but it does not. it have some problem with frog eating ubitux ;D [00:05:21] <ubitux> :) [00:05:26] <saintd3v> so now that we have new leadership, when do we get per-codec defaults [00:05:28] * saintd3v hides [00:11:06] <JEEB> saintd3v, watches pelcome is what was said to me [00:12:24] <saintd3v> where's Dark_Shikari's patch? [00:13:25] <JEEB> it was he whom said it to me ;) [00:24:16] <ubitux> what is the queue system for? does it allows a fate-run before getting the patchs upstream? [00:25:44] <jannau> there is no queue system. http://patchwork.libav.org is just for keeping track of patches [00:27:20] <saintd3v> fate is in the process of breaking [00:27:31] <mru> no [00:27:38] <mru> a few broke and then we fixed it [00:27:43] <saintd3v> ah [00:28:00] * saintd3v crawls back into the shadows [00:29:42] <ubitux> does patchwork detect incoming patchs, apply and rejection from patterns in the ml? [00:31:22] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rf4b1e21a63 ffmpeg/tests/ (21 files in 2 dirs): [00:31:22] <CIA-29> ffmpeg: fate: make lavfi tests output only md5 [00:31:22] <CIA-29> ffmpeg: Instead of saving huge raw files, use the md5: output pseudo-protocol [00:31:22] <CIA-29> ffmpeg: to calculate the checksum of the file directly. This is especially [00:31:22] <CIA-29> ffmpeg: useful when testing on remote targets as it avoids transferring 3.6GB [00:31:22] <CIA-29> ffmpeg: over the network. [00:31:56] <CIA-29> ffmpeg: Clément Bœsch <ubitux(a)gmail.com> master * r045b80e52d ffmpeg/ (libavcodec/mpegaudiodec.c libavformat/mp3dec.c): [00:31:56] <CIA-29> ffmpeg: Move ID3v1 skip from decoder to demuxer [00:31:56] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [00:33:14] <jannau> it get patches and comments from the ml, apply from a git repo [00:34:07] <ubitux> purge of rejected/invalid patchs is manual? [00:34:41] <jannau> I have to check if it supports commands from mails [00:36:18] <BBB> jannau: if you want to queue more patches, the last few of elenril that were not committed yet can be committed now also [00:36:58] <BBB> oh mru is still awake [00:37:29] <mru> I'm not the _only_ one who can push patches [00:56:00] <jannau> BBB: care to ok them on the ml? [00:57:48] <BBB> jannau: done [01:06:26] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rcb6bc57681 ffmpeg/libavformat/ (id3v2.c id3v2.h mp3enc.c): [01:06:26] <CIA-29> ffmpeg: id3v2: split tables for various ID3v2 versions [01:06:26] <CIA-29> ffmpeg: This is needed for upcoming ID3v2.3 muxing support. [01:06:26] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [01:06:38] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r8c3caf7fb1 ffmpeg/libavformat/mp3enc.c: [01:06:38] <CIA-29> ffmpeg: mp3enc: handle errors in id3v2_put_ttag [01:06:38] <CIA-29> ffmpeg: make the initialization of put clearer [01:06:38] <CIA-29> ffmpeg: this are the differences between [01:06:38] <CIA-29> ffmpeg: [FFmpeg-devel] [PATCH 1/3] mp3enc: add support for writing UTF-16 tags [01:06:38] <CIA-29> ffmpeg: and the already applied 187e23478bc5c066ff8eef562925471ac179644e [01:06:39] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [01:06:40] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r22272f61bb ffmpeg/libavformat/mp3enc.c: [01:06:40] <CIA-29> ffmpeg: mp3enc: support for id3v2.3 tags using a per-muxer AVOption [01:06:40] <CIA-29> ffmpeg: fixes issue2562. [01:06:41] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [01:14:30] <mru> new fate feature [01:15:00] <mru> build errors show the last few lines of the log directly in the index view [01:15:05] <BBB> \o/ [01:15:07] <BBB> that is awesome [01:16:06] <BBB> would be better if it used newlines where appropriate :-p [01:16:13] <mru> huh? [01:16:17] <BBB> what's all those compile errors in arm etc? [01:16:27] <mru> random compiler crash [01:16:39] <mru> the arm one [01:16:44] <relaxed> mru: you added freebsd, thanks! [01:16:52] <mru> relaxed: not me [01:17:10] <mru> BBB: then we accidentally broke shared libs earlier [01:17:10] <relaxed> oh, then thanks to however did. [01:17:12] <mru> fixed now [01:17:24] <BBB> oh that ok [01:17:26] <mru> relaxed: michael kostylev runs those [01:17:44] <mru> BBB: but what about newlines? [01:17:55] <BBB> the compiler output in main view has no newlines [01:17:59] <mru> does here [01:18:03] <BBB> hm... [01:18:07] <BBB> chrome doesn't display them [01:18:08] <mru> maybe youre crappy browser doesn't support proper css [01:18:18] * BBB goes watch movie [01:18:19] <BBB> brb [01:18:29] <mru> try in firefox [01:18:41] <BBB> fix it in chrome! [01:18:52] <mru> I can't fix what I can't see [01:22:06] <mru> try now [01:22:26] <jannau> updating patchwork from the post-receive hook works [01:23:21] * jannau wonders if he should try to import patch backlog into patchwork [01:26:12] <mru> how far back? [01:26:33] <mru> can it handle svn diffs? [01:37:17] <jannau> just a couple of days/weeks. It claims to be scm agnostic and creates a hash of the diff [01:38:19] <mru> how does it deal with patch revisions? [01:42:30] <jannau> it seems to handle them badly looking at http://patchwork.libav.org/patch/171/ [01:48:23] <jannau> mru: please mirror to gitosis@git.jannau.net:ffmpeg-pw [01:51:02] <mru> using what credentials? [01:51:09] <jannau> private key per mail [01:51:40] <mru> which is the proper hook for this? [01:52:27] <jannau> post-receive [01:54:11] <mru> application/vnd.lotus-organizer wtf? [01:54:11] <jannau> while read oldrev newrev refname; do [01:54:36] <jannau> git push patchwork $refname:$refname [01:54:39] <jannau> done [01:55:46] <mru> I've forbidden creation of new branches for now [01:56:00] <mru> to guard againt accidental weird pushes [01:57:29] <jannau> pushes for release/0.6 are not impossible [01:57:40] <mru> right [01:57:51] <mru> I was doing the loop anyway [02:02:23] <mru> should be all set [02:02:57] <mru> now we just need something to push [02:07:52] <jannau> one of the profiles patches was oked, I'll push it [02:11:09] <mru> what happened to patch queue? [02:11:22] <CIA-29> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * rb92f76e209 ffmpeg/libavcodec/libfaac.c: [02:11:22] <CIA-29> ffmpeg: libfaac: add recognized profiles array [02:11:22] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [02:11:42] <jannau> mru: remote: Host key verification failed. [02:11:50] <mru> hmpf [02:14:08] <jannau> I'm bouncing atm the last 1500 mails to patchwork, will get cleaner after updating the status from commits from same period [02:14:22] <mru> ok [02:14:24] <jannau> hopefully [02:14:46] <mru> now how to debug the key problem? [02:15:41] <jannau> is the host key in ~git/.ssh/known_hosts ? [02:16:16] <mru> guess not [02:16:58] <mru> now it is [02:22:12] <mru> see any more approved patches? [02:53:12] <jannau> "fate: add lossless h264 test" should be safe now [03:09:37] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r76edf2c137 ffmpeg/tests/ (fate/h264.mak ref/fate/h264-lossless): [03:09:37] <CIA-29> ffmpeg: fate: add lossless h264 test [03:09:37] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [03:10:20] <mru> jannau: http://pastebin.com/K781TqZB [03:11:04] <CIA-29> ffmpeg: Mike Scheutzow <mjs973(a)optonline.net> master * r20ac9de3df ffmpeg/ (doc/ffmpeg.texi ffmpeg.c): (log message trimmed) [03:11:04] <CIA-29> ffmpeg: streamid does not work with newaudio, newvideo, newsubtitle [03:11:04] <CIA-29> ffmpeg: fixes issue2465. [03:11:04] <CIA-29> ffmpeg: The problem is that the ffmpeg (the app) -streamid option did not work [03:11:04] <CIA-29> ffmpeg: with -newaudio/-newvideo/-newsubtitle. [03:11:05] <CIA-29> ffmpeg: The cause was a conflict between the feature where streamid values were [03:11:06] <CIA-29> ffmpeg: reset to default for each output filename, and the implementation of [03:12:31] <jannau> mru: nice, seems to work [03:13:46] <mru> now we need to clean out applied patches [03:13:48] <jannau> it doesn't seem to like the rewritten commit msg from svn commits [03:47:21] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r98cfadd648 ffmpeg/libavcodec/iirfilter.c: [03:47:21] <CIA-29> ffmpeg: 10l: reverse the biquad coefficients. [03:47:21] <CIA-29> ffmpeg: I did not notice that the filter implementation uses a reversed history state. [03:47:21] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [03:57:53] <BBB> uh so you guys can now remotely push? [04:00:20] <jannau> no, my current workflow is: pwclient view $PATCH_NUM | git am -s - ; git pull --rebase ; git push [04:01:09] <jannau> ommitting looking at the patch and building it [05:00:55] <peloverde> Anyone know a smart visual tool for diffing binaries? [05:04:15] <pross-au> vbindiff [05:08:43] <peloverde> nope [05:09:07] <peloverde> vbindiff doesn't seem to make any attempts to resynchronize [05:12:00] <peloverde> for now I'm using gvimdiff and the debug prints in mov.c [05:12:28] <peloverde> But I think a content aware mov/mp4 differ/hexeditor would be awesome [05:23:20] <saintdev> not the cyborg apocalypse! [05:23:55] <saintdev> 16saayunz must be the instigator, we must find him and destroy him. [05:23:57] <peloverde> sadly I thought a program had locked my soundcard but it turns out I had headphones plugged in [05:24:23] <saintdev> lol! [05:24:46] <peloverde> Computers are dumber than humans but smarter than programmers [05:26:18] <saintdev> fuser /dev/snd/* [08:34:13] <_av500_> jannau: so remark on it [08:36:11] <_av500_> jannau: i guess is ignore that since my french coworkers like epic variable names [08:36:39] <_av500_> some derserve an ISBN even [08:37:41] <kierank> why do french coworkers like epic variable names? [08:44:17] <_av500_> too much lit classes in school or so [08:55:29] <pJok> _av500_, thisvariablenameistooshortsoineededtomakeitevenlongerforittobeclosetoratherepic ? [08:56:37] <kierank> pJok: wrong language [08:56:51] <pJok> i dont speak french [08:57:09] <pJok> but since french people usually don't speak anything else, it doesn't matter [08:57:35] <pJok> or wait, i think that were actually french belgians that refused to understand anything other than french [11:41:31] <kierank> peloverde_: does anyone use mpeg-2 aac with bandwidth extensions? [11:51:38] <merbanan> there we go [11:51:44] <merbanan> bugs and wishes [11:52:37] <kshishkov> var? [12:22:54] <merbanan> the roundup tracker [12:25:07] <kshishkov> well, you can do it with inputting file as raw PCM16 and remuxing it into wav [12:33:33] <elenril> wtf is bytestream_get_le16 [12:34:59] <_av500_> kshishkov: is ffpcmenc still experimental? [12:35:18] <kshishkov> _av500_: no, it's mature enough even for you to use it [12:36:05] <elenril> anyone? [12:36:15] <elenril> i don't see it defined anywhere [12:36:37] <kshishkov> elenril: it's all in bytestream.h [12:36:44] <kshishkov> expanded from macros [12:37:07] <lu_zero> jannau: is there anything I should know about pwclient? [12:37:12] <kshishkov> it reads 2 bytes from buffer as 16-bit LE integer and adjusts buffer position [12:37:22] <elenril> ah [12:37:33] * elenril kicks aurel for using such obscure stuff in lavf [12:38:17] <kshishkov> elenril: it's rather obvious and useful too [12:40:43] <jannau> lu_zero: it's a command line client for patchwork [12:40:58] <lu_zero> yup [12:41:09] <lu_zero> I wanted to know more =) [12:41:30] <kierank> [12:33] elenril: wtf is bytestream_get_le16 --> is it not rather self-explanatory ;) [12:42:03] <elenril> the side effects aren't =p [12:42:12] <jannau> lu_zero: http://patchwork.libav.org/help/pwclient/ [12:43:16] <jannau> can be used to list, view and download patches from patchwork [12:44:08] <kierank> elenril: is aurel not worthy of a stab [12:44:48] <elenril> :eff: [12:45:03] <jannau> makes it easier to use in your git repo [12:45:12] * kierank stabs elenril [12:45:17] <_av500_> +1 [12:46:15] * kshishkov prescripts Ceasar's pill to elenril [12:46:41] <_av500_> ceasar was on the pill? [12:46:58] <_av500_> i thought he used the calender method... [12:47:09] <lu_zero> jannau: could you send me the proper rc ^^; [12:47:25] * elenril wonders what evil person wrote mov chapter code [12:47:30] <kshishkov> _av500_: he took 22 stabs to cure him of being dictator [12:48:20] <elenril> ah, Yuvi [12:48:31] <elenril> how fitting for an apple minion [12:49:59] <jannau> lu_zero: http://patchwork.libav.org/project/FFmpeg-devel/pwclientrc/ [12:51:03] * mru adds a .caesar section to elenril's elf files [12:51:39] <mru> jannau: patchwork still shows mostly applied patches [12:52:09] <elenril> morning our glorious BDFL [12:55:53] <jannau> mru: untrue, I've closed > 50%. it doesn't catch svn commits and doesn't supercede patches automatically if a new version is send [12:56:17] <mru> most of the patches listed have been applied in some form or other [12:56:29] <mru> even though you've cleaned out many [12:57:11] <jannau> I'm inclined to close all before 2011-01-21 [12:57:46] <lu_zero> it might be worth an announce [12:57:46] <jannau> the other form is the problem [12:58:18] <jannau> sure, I wanted to test it first [13:00:24] * elenril wonders if it's just him, or mov_read_chapters really leaks like crazy [13:00:45] <mru> a lot about mov is crazy [13:02:47] <mru> jannau: feel free to discard old stuff [13:03:19] <mru> I'd rather have it incomplete and usable than have it cluttered by already applied or rejected patches [13:03:31] <mru> btw, how does are rejected patches handled? [13:06:53] <_av500_> burned at a stake? [13:07:05] <CIA-29> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rdb2ddd3885 ffmpeg/ffplay.c: [13:07:05] <CIA-29> ffmpeg: Remove outdated and confusing comment. [13:07:05] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:16:28] <elenril> what would be the best way do le/be variants of put/get_str16? [13:16:43] <elenril> with a macro? [13:16:49] <mru> with magic [13:18:37] * elenril casts magic missile at mru [13:18:58] <microchip_> you a wizard? [13:19:33] <kshishkov> elenril: you just don't know how "to do magic" sounds in mru's native language [13:19:52] <mru> "trolla" [13:20:14] <mru> so who better then elenril to do it? [13:20:48] <kshishkov> C-E Hoyos [14:31:57] <BBB> mru: nwlines are good now [14:31:59] <BBB> thnks [14:35:55] <elenril> http://tech.slashdot.org/story/11/01/22/130201/Google-Submits-VP8-Draft-To-… [14:47:02] <mru> BBB: how can you see them? there are no errors now [14:48:53] <elenril> kshishkov: i knew it! [14:49:11] <kshishkov> elenril: knew what? [14:49:18] <mru> *it* [14:49:24] <elenril> you lied! [14:49:34] <mru> but now av500 knows *it* [14:50:07] <elenril> pross-au: how come your get_utf16z function doesn't call GET_UTF16/PUT_UTF8 [14:50:08] <kshishkov> elenril: not(iKnow(iT)) [14:50:48] <kshishkov> pross-au: how come there's no bink-b support patch from you? [14:51:24] <CIA-29> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r10ed96c78f ffmpeg/doc/demuxers.texi: [14:51:24] <CIA-29> ffmpeg: Amend documentation for the image2 demuxer, to better reflect the current behavior. [14:51:24] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:54:11] <pross-au> keep the how comes coming please [14:54:36] * elenril would prefer some answers [14:54:39] <pross-au> elenril: i will rename it to get_unicodez [14:54:46] * jannau curses mru [14:54:53] <elenril> that doesn' really answer my question [14:54:53] <mru> why? [14:54:55] <kshishkov> pross-au: how come there's no cutscenes support in opensource Z engine reimplementation? [14:55:28] <pross-au> kshishkov: somebody is rewriting Z? [14:55:37] <mru> jannau: what did I do? [14:55:38] <CIA-29> ffmpeg: Alex Converse <alex.converse(a)gmail.com> master * r8ae0fa243e ffmpeg/libavcodec/aacenc.c: [14:55:38] <CIA-29> ffmpeg: aacenc: mark SBR absent [14:55:38] <CIA-29> ffmpeg: Use backwards compatible explicit signalling to denote the absence of [14:55:38] <CIA-29> ffmpeg: SBR. [14:55:38] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [14:55:40] <elenril> pross-au: the data is guaranteed to be ascii? [14:56:12] <jannau> mru: you pushed stefano's patch [14:56:19] <mru> someone approved it [14:56:25] <mru> and it didn't look too bad [14:56:27] <pross-au> elenril: all my samples contain unicode [14:56:44] <jannau> just before I was going to push it [14:56:46] <elenril> pross-au: then how is it supposed to work? [14:56:59] <mru> jannau: git should handle that just fine [14:57:19] <jannau> git am didn't [14:57:27] <mru> git am -3 [14:58:01] * jannau wonders why patchwork didn't catched the commit [14:58:09] <pross-au> elenril: let me get back to you on that.. [14:58:16] <elenril> pross-au: i mean you're writing uint_16's into chars [14:58:25] <mru> remote: remote: I: patch #449 updated using rev db2ddd38859b26c0a4e4bf92619625cd7e0e7f42. [14:58:29] <mru> remote: remote: E: failed to find patch for rev 10ed96c78fde80da9d5bac9b267369861a4f33ba. [14:58:44] <jannau> I blame the attachment [14:58:55] * elenril thinks somebody should just write a common 'read an utf16 string and convert it to utf8' function [15:00:09] * kierank thinks utf-* is a waste of time [15:00:26] <mru> kierank: good luck converting the world to 7-bit ascii [15:00:30] <kierank> have we seen the return of __troll__ yet? [15:00:45] * elenril feeds the _troll_ [15:00:59] <kierank> BBB tried to replace you _troll_ for a while [15:01:10] <kierank> but he wasn't very good [15:01:27] <elenril> av500 tried too, with somewhat greater success [15:01:37] <_troll_> there's no such thing as a dutch troll [15:01:39] <kierank> but av500 didn't use the nick [15:01:49] <kierank> BBB actually changed his nick to troll [15:01:49] <_troll_> he can't, it belongs to me [15:02:07] <kierank> he used __troll__ I think [15:02:10] <kierank> or something like that [15:02:24] * _troll_ needs to register more nicks [15:03:32] <BBB> I used _troll_, and then nickserv changed me to something else because it was taken [15:03:39] <BBB> btw, I think I found the h264 bug on roundup [15:03:43] <BBB> still working out a proper fix [15:03:46] <_troll_> "the"? [15:03:52] <BBB> but at least I'm starting to truly get the internals of the code [15:03:56] <BBB> one of the? [15:04:01] <kierank> fix the mbaff bug kthx [15:04:04] <kshishkov> _troll_: you should use __troll_t [15:04:06] <BBB> #2393 is the one I'm working on right now [15:04:24] <_troll_> kshishkov: that is reserved for the implementation [15:04:31] <_troll_> oh right, I am the implementation [15:04:58] <kshishkov> compliant one too [15:05:36] <_troll_> is there an international standard for troll? [15:05:50] <kierank> iso-3489238423432 [15:05:58] <kierank> except its impossible to find [15:06:18] <_troll_> kshishkov: btw, we've stopped being totally anal about indentation patches [15:07:19] <kshishkov> _troll_: iKnow but I'm still adapting [15:07:25] <_troll_> use common sense [15:07:41] <_troll_> sometimes it is of course easier to see what's going on if cosmetics are done afterwards [15:09:08] <j-b> kshishkov: thanks. Will this wv 5.1 work with external demuxers or just lavf ones? [15:10:13] <kshishkov> j-b: depends. MKV should work fine, WV demuxer should follow packet format from lavf [15:10:54] <j-b> kshishkov: we don't have a WV demuxer, we use lavf for that. [15:11:24] <kshishkov> j-b: keep on that [15:11:26] <j-b> kshishkov: I will try... THis is _really_ cool [15:12:01] * _troll_ has never seen a wavpack file in the wild, fails to feel the cool [15:12:44] <kshishkov> _troll_: you just download your music from different source [15:12:52] <_troll_> my music is in flac [15:13:01] <kshishkov> exactly [15:13:02] * j-b has received a fucking lot of request for 5.1 wv support [15:13:11] <_troll_> j-b: if you say so [15:13:14] <j-b> this is probably the #2 request for audio [15:13:16] <kshishkov> j-b: me too - one request [15:13:21] <_troll_> is it a regional thing? [15:13:25] <j-b> _troll_: possibly [15:13:34] <_troll_> like rv being *the* codec in china [15:13:41] <j-b> _troll_: and remember: my users are possibly stoopid and clueless [15:13:41] <kshishkov> j-b: if #1 is TAK go kill yourself [15:13:49] <j-b> kshishkov: #1 is AAC encoder [15:14:04] <j-b> #1 was amr, but this is solved now [15:14:17] <_troll_> kshishkov: can't you troll ivan into fixing ffaacenc? [15:14:28] <elenril> j-b: and kshishkov is to be blamed for both [15:14:31] <kshishkov> _troll_: nope :( [15:14:32] <elenril> coincidence? [15:14:33] <_troll_> ivan dimkovic, that is [15:15:08] <_troll_> kshishkov: tried? [15:15:31] <j-b> well, faac was kind of ok [15:15:43] <kshishkov> _troll_: no, but he's not that interested in AAC these days :( [15:15:57] <_troll_> but he knows a lot about it [15:16:15] <_troll_> lack of interest -> need for trolling [15:17:07] <j-b> but, yes, wv5.1 was requested quite a bit [15:17:41] <j-b> video is more MSS2, G2M3, vc-1 inter, some rv* [15:17:46] <kshishkov> _troll_: maybe try your disciple first - they are of the same nationality and he has better trolling skills [15:18:09] <kshishkov> j-b: some rv*? [15:18:31] <j-b> kshishkov: it would seems some rv40 don't play correctly [15:18:43] <j-b> kshishkov: but I haven't investigated, since it could be the demuxer [15:19:21] <kshishkov> if you don't use lavf the warranty is off [15:19:32] <kshishkov> but it's also void with lavf RM demuxer [15:19:50] <j-b> vlc rm demuxer is crap [15:20:02] <j-b> lavf rm demuxer is ... [15:20:03] <kshishkov> lavf one is too [15:20:27] <j-b> mplayer rm demuxer is kind of better, but messy, IIRC [15:20:33] <kshishkov> maybe you should reuse the one from FFmBC - written by Frenchman even [15:20:41] <j-b> FFmBC ? [15:20:53] <j-b> I could, maybe [15:21:00] <spaam> SRTP is that some kind encrypted version of RTP ? [15:21:17] <kshishkov> j-b: http://code.google.com/p/ffmbc [15:21:34] <j-b> kshishkov: oh, I thought it only cared about mxf or gxf [15:21:46] <kshishkov> j-b: it's fork by Baptiste Coudurier though he's too modest and calls it "FFmbc" [15:21:46] <j-b> spaam: yes, [15:21:58] <j-b> too modest? [15:22:38] <kshishkov> I hope that's not an insult for French [15:22:42] <j-b> this doesn't fit with "French" :) [15:22:47] <j-b> rofl [15:23:07] <j-b> kshishkov: so he has a newer rm demuxer? [15:23:40] <kshishkov> yep, either written from scratch or modified from MOV demuxer [15:26:38] <BBB> hah, I think I've got 2393 fixed [15:26:47] <j-b> modified from mov? O_o [15:26:52] * j-b needs to read doc then [15:27:02] <BBB> _troll_: what's your opinion on adding roundup samples to fate once they're fixed? [15:27:22] <_troll_> BBB: depends on what the problem was of course [15:27:34] <kshishkov> j-b: well, its style reminded me of MOV demuxer immediately [15:27:45] <BBB> resolution change in h264 caused a crash, apparently that's legal but no ref sample tests it [15:27:51] <BBB> so of course it broke [15:27:51] <_troll_> mindlessly creating a test case exactly matching each fix bug is stupid [15:28:01] <j-b> kshishkov: why didn't he port it to "classical FFmpeg" ? [15:28:29] <BBB> _troll_: and re: newlines, I can see the newlines for the failing fate tests also [15:28:31] <kshishkov> j-b: 1) it's totally new and needs to replace old one 2) he didn't care much (I think) [15:28:48] <_troll_> BBB: but there are no build failures currently [15:28:49] <j-b> ok, makes sense [15:29:34] <BBB> _troll_: true, but I assume that if newlines work for fate tests triangles, it'll work for build failure triangles also, no? [15:29:43] <_troll_> no [15:29:47] <BBB> oh [15:29:48] <_troll_> totally different html [15:29:51] <BBB> let me break the build [15:29:56] <_troll_> :) [15:30:24] <_troll_> the failed test listings use tables [15:30:42] <BBB> ah, I see [15:31:32] <_troll_> but I think I fixed the problem you saw [15:31:37] <_troll_> we'll know next time a build fails [15:31:41] <_troll_> it'll happen eventually [15:32:05] <_troll_> actually, I might have some hidden slots with a failure [15:32:16] <BBB> yeah [15:32:16] <BBB> win32 [15:32:50] <_troll_> there, try now [15:33:03] <BBB> yes works [15:33:09] <BBB> very pretty :) [15:33:17] <_troll_> ok, hidden again [15:33:28] <BBB> ty [15:33:39] <kshishkov> BBB: that's because mru had never thought of being Web designer for living [15:33:49] <BBB> I emailed ramiro... he won't be back soon but he'll be at fosdem so you guys can get him drunk and rehypnotize him [15:34:04] <_troll_> BBB: now there's a plan [15:34:23] <BBB> \o/ [15:34:40] * BBB needs to resume working on the emu_edge patch [15:35:00] <BBB> I think the problem was that the jumptable for size-specific copies didn't make it any faster, which of course sucks major ass [15:35:08] <BBB> maybe I should do it in yasm after all... [15:35:14] <j-b> BBB: btw, do you have any idea why projects like VLC use emu_edge? [15:35:27] <BBB> j-b: I may be wrong here, but... [15:35:38] <BBB> j-b: aren't some people in this channel involved in such projects? [15:35:42] <BBB> j-b: like, maybe, ... [15:35:44] <BBB> j-b: you? [15:35:51] <BBB> j-b: you should be telling me dude ;) [15:36:24] <j-b> BBB: do you actually think I know why decisions done 4 years before I join the dying project were made? [15:36:35] <kshishkov> j-b: because you copied it from MPlayer! [15:36:37] <BBB> good point :) [15:36:50] <j-b> kshishkov: MPlayer use emu_edge too ? [15:37:11] <mru> some retarded output devices don't allow stride != width [15:37:19] <j-b> BBB: mru hinted we could do Direct Rendering without emu_edge [15:37:20] <BBB> I believe that some versions of X RGB output had fixed alignment of 4 bytes [15:37:23] <BBB> regardless of pixelformat [15:37:26] <kshishkov> j-b: ask BBB but I think VP* had some problems because of it there too [15:37:34] <BBB> and so everyone just defaulte dto always emuedge [15:37:45] <BBB> but I don't really know [15:37:54] <j-b> kshishkov: yes, we deactivated emu_edge on ffVP8 until 52.101.1 where it was fixed [15:37:58] <mru> xv output easily allows padding [15:38:02] <BBB> j-b: I don't think it matters much that you use it, it makes stuff like 0.5% slower, but not much [15:38:05] <BBB> mru: I meant X RGB, not xv [15:38:11] <mru> same there [15:38:21] <BBB> well that's all I remember ;) I may be plain wrong [15:38:34] <BBB> gst used emu_edge too at that point [15:38:48] <mru> XPutImage (and its shm brother) take a sub-region as argument [15:38:48] <BBB> it may just be that we did it b/c mplayer did and that was the only sample code of how to use ffmpeg at that point [15:39:25] <BBB> our approach was "copy whatever mplayer does, that's the best chance that it won't break every other day, because at least the devs get shouted at by others than us if it breaks in mplayer" [15:39:54] <BBB> any other bugs? going once, going twice, or I go to submitting emu_edge again [15:40:30] <mru> how times have changed [15:41:13] <kshishkov> mru: they change every <quantum of time> [15:41:28] <mru> is there a time particle? [15:41:37] <kshishkov> tachion [15:41:45] <mru> or is it chroniton? [15:41:53] <mru> star trek writers can't seem to make up their minds [15:42:02] <j-b> BBB: lavc in vlc dates from before 2002, it seems [15:42:16] <mru> the dark ages [15:42:28] <j-b> #if LIBAVCODEC_BUILD >= 4615 [15:42:34] <kshishkov> mru: wake me when we have dilithium-ion batteries [15:43:12] <mru> nevermind the warp core, I want to know what powers those phasers [15:44:04] <BBB> \o/ I can send multiple emails now [15:44:04] <mru> and I'd also like to know how firing one can completely vapourise an object without damaging the table it was sitting on [15:44:07] <BBB> awe some [15:44:24] <BBB> gotta work on git am next [15:44:45] <j-b> git obscurity [15:44:55] <kshishkov> mru: you're too picky [15:45:06] <mru> git: 'obscurity' is not a git command. See 'git --help'. [15:45:40] <kshishkov> git obliviate [15:45:53] * mru has a git assimilate command [15:46:07] <kshishkov> git fix-it-for-me --really [15:46:36] <mru> it's just a shorthand for merge; branch -d [15:46:56] <mru> useful for pushing things around between non-bare repos [16:13:03] * mru would like to push the h264enc removal patch [16:13:15] <kshishkov> what blocks it? [16:13:25] <kierank> nothing [16:13:51] * kshishkov would also like mru to push lib*core removal patch [16:14:09] <kierank> replace it with libavsequencer [16:14:24] <kierank> most important patch ever [16:14:46] <spaam> <3 [16:15:02] <kshishkov> not as important as Amiga asm speedup for it [16:15:05] <spaam> kierank: then mru can join the CDBG crew [16:15:15] <kierank> spaam: CDGS [16:15:21] <kierank> get it right [16:15:22] <spaam> ah so it was. [16:15:27] <spaam> im sorry [16:15:35] * kierank allows spaam back into CDGS [16:15:58] <spaam> \o/ [16:16:16] <spaam> kshishkov: when will you join the CDGS crew? :D [16:16:20] <kshishkov> now write asm 68k asm [16:16:25] <CIA-29> ffmpeg: Alex Converse <alex.converse(a)gmail.com> master * rff3d43104f ffmpeg/libavcodec/ (Makefile h264.c h264dspenc.c h264enc.c): [16:16:25] <CIA-29> ffmpeg: Remove H.264 encoder fragments [16:16:25] <CIA-29> ffmpeg: It's incomplete, no one is working on it, and when someone asks about [16:16:25] <CIA-29> ffmpeg: working on it we advise them not to. [16:16:25] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [16:16:51] <spaam> rip ffh264enc [16:16:57] <kshishkov> spaam: when they start making decent Trocadero in Germany [16:17:02] <mru> jannau: why does pw tell me "2 patch(es) updated to state Accepted"? [16:17:24] <mru> the other being the aacsbr thing you applied a few hours ago [16:17:26] <spaam> kshishkov: :) [16:18:11] <kierank> we should have an #ffmpeg-devel skype too [16:18:29] <kshishkov> kierank: support at least iLBC first! [16:18:36] <spaam> kshishkov: after you join the CDGS crew. we can fix bink-b in avsequencer [16:18:58] * kierank reads about iLBC [16:20:21] <kshishkov> spaam: port AdPlug-supported formats into lavseq first [16:20:39] <spaam> kshishkov: why? :) [16:21:43] <kshishkov> spaam: it's logical and would make me interested :-| [16:21:51] <kierank> for anyone who knows about dvb subtitles: so the point of the dds segment is to make them not look large on HDTV channels because they were lazy when creating the first spec? [16:23:36] <jannau> mru: delicious session cookie noticed that you last visited before I pushed the aacsbr patch? just guessing [16:24:06] <mru> cookies in git? I don't think so... [16:24:19] <mru> it printed that from git push [16:24:19] <jannau> web browser [16:24:22] <BBB> actually [16:24:29] <BBB> kshishkov: removing libavcore is on my list also [16:24:36] <BBB> (i.e. merging it back with libavutil) [16:24:41] <BBB> I'd like opinions... [16:24:46] * elenril disagrees [16:24:57] <kshishkov> BBB: my opinion is "HELL YES!!" [16:25:23] <spaam> Why did libavcore split out from libavutil in the first place? [16:25:28] <jannau> ah, I think there's an error in hook it sends old^..new to patchwork [16:25:28] <mru> spaam: michael [16:25:45] <spaam> mru: what was the reason? [16:25:54] <elenril> spaam: michael maintained illusions about people using libavutil standalone [16:25:57] <BBB> it wasn't generic enough for libavutil [16:25:59] <BBB> or so [16:26:07] <BBB> but too specific for libavcodec [16:26:11] <kshishkov> though it may be more reasonable to split them into libavutil, libavcore, libavkernel, libavstuff, libavcommon, libavreused and libavsomebits [16:26:31] <kierank> I used libavcore for something [16:26:47] <BBB> libavsequencer [16:26:49] <BBB> libavgcc [16:26:56] <jannau> if we are going to remove libavcore we should do it fast [16:26:57] <kshishkov> kierank: we all make mistakes sometimes [16:26:57] <spaam> BBB elenril : ok :) [16:26:58] <BBB> kierank: you can now use libavutil then [16:27:08] <spaam> jannau: why? [16:27:09] <elenril> BBB: what's the point in merging it anyway [16:27:19] <kierank> kshishkov: I was too lazy to write channel mapping defines [16:27:22] <BBB> elenril: I think that 20 shlibs is not very useful [16:27:30] <kshishkov> spaam: because it's reasonable [16:27:33] <jannau> removing it causes trouble for downstream projects [16:27:42] <kshishkov> spaam: and no Michael will prevent us [16:27:44] <elenril> other than breaking api, breaking compatibility with TheOtherFFmpeg etc [16:27:44] <BBB> jannau: like deb? [16:28:05] <BBB> let's not do it for now [16:28:09] <elenril> at the very least i'd wait [16:28:09] <saste> there was a reason for libavcore [16:28:11] <jannau> especially should remove it before we release 0.7 [16:28:11] <BBB> but keep it in mind for next time we break abi/api anyway [16:28:15] <BBB> saste: hi :) [16:28:27] <saste> it is even written in the commit log [16:28:40] <jannau> BBB: like mythtv, mplayer, vlc, ... [16:28:41] <saste> someone may want to use libavutil in a non-multimedia app [16:28:51] <BBB> saste: ffmpeg is not non-multimedia [16:28:52] <mru> lol [16:28:57] <BBB> avutil is in ffmpeg [16:28:59] <mru> nobody has ever done that [16:29:05] <BBB> therefore, noone would ever use avutil unless in a multimedia app [16:29:23] <saste> yes but who may know? [16:29:27] <BBB> they'd probably just pick the pieces they need and built it in their binary directly instead of linking [16:29:34] <kshishkov> saste: ever though about what "av" in "libav*" stands for? [16:29:44] <jannau> saste: I don't expect libavutil to grow huge, i.e. if they need something from it, they can still use it [16:30:16] <saste> note that i was quite indifferent to the two options [16:30:32] <saste> but I didn't think that having a separate lib was necessarily evil [16:30:36] <j-b> 17:25 < spaam> Why did libavcore split out from libavutil in the first place? [16:30:43] <j-b> I had the same question [16:30:48] <saste> now if you remove libavcore you're breaking many apps [16:30:57] <saste> it's explained in the commit log!! [16:31:12] <saste> there is a link to the discussion on ffmpeg-devel iirc [16:31:13] <mru> I agree it's not nice to break apps [16:31:30] <mru> but the only reason it was done was because michael was kicking and screaming [16:31:42] <spaam> j-b: http://git.ffmpeg.org/?p=ffmpeg.git;a=commit;h=aac6ca6978306bf0f0254bab8a60… teh commit [16:32:42] <kshishkov> mru: I though it was a nice troll though [16:32:51] <kshishkov> *thought [16:36:47] <uau> speaking of library organization, what about making the ffmpeg libraries share one major version? [16:37:33] <uau> the main problem with the current independent changes is that it forces applications to use non-matching versions (if they use a previous major version of one lib) [16:38:11] <uau> the downside of changing that would of course be more major version changes, but they've been rare enough that unless updates become more frequent i don't think that is a big problem [16:38:53] <BBB> saste: I remember most devs being against avcore when it came up, but nobody cared enough to fight it (me included) [16:39:07] <BBB> saste: let's not break apps now, but let's keep this in mine for when we bump abi/api for some other reason [16:39:10] <BBB> saste: i.e. 0.7 [16:39:11] <kshishkov> good idea, especially if somebody cleans headers out of all those #ifdef VERSION_x < y stuff [16:39:25] <BBB> I thought reimar was doing that [16:39:25] <elenril> yeah, let's bump major [16:39:35] <BBB> not now [16:39:35] <BBB> later [16:39:37] <saste> BBB: I was mildly in favor of having it, and still am... [16:39:39] <elenril> after mt [16:39:44] <saste> think if you want to add DSP to libavcore [16:39:47] <BBB> after mt yes [16:40:05] <BBB> dsp for what? [16:40:12] <saste> many apps may need to use it without libavcodec [16:40:15] <BBB> avutil can have dsp also [16:40:15] * elenril wonders if mt will get merged before DNF [16:40:17] <saste> or fft [16:40:25] <BBB> saste: all that can be moved to avutil [16:40:29] <saste> but then you're blowing lavu too much [16:40:33] <kshishkov> BBB: so you can do accelerated DCT in some demuxer [16:40:34] <BBB> are you? [16:40:48] <BBB> kshishkov: I think he's thinking of sharing stuff between avcodec and avfilter [16:40:53] <saste> I recognize that this is useful only if you want to use avutil in a non multimedia app [16:41:09] <saste> that's not likely but it's not impossible... i see the point of michael... [16:41:12] <kshishkov> BBB: we may have separate libavdsp then [16:42:42] <BBB> no no not before avsequencer [16:42:58] <BBB> saste: my vision is generally to not care until it happens [16:43:03] <mru> I can see a point to separating core stuff from specific codecs [16:43:09] <saste> BBB: DSP may be useful in many filtering application for example, togheter with FFT [16:43:10] <mru> but there are performance penalties for that [16:43:20] <BBB> saste: should we prepare for the world to go down in flames in 2012, just because some idiot in a sect says so? [16:43:31] <BBB> saste: I totally agree filters should use DSP [16:43:40] <BBB> saste: but imo DSP in avutil is fine [16:43:44] <saste> BBB: no I respect the will of the majority [16:43:57] <saste> I don't think that I alone or someone else should decide for everyone [16:44:23] <saste> so most devs want that... but I want to show which are the technical points for keeping the current layout [16:44:32] <BBB> ok [16:44:44] <saste> and I know that many libs are more difficult to manage than few [16:44:45] <BBB> Dark_Shikari: please review my h264 patches again :-p [16:44:55] <saste> but in general they allow you more flexibility [16:46:05] <mru> let's not make any huge changes just now [16:46:13] <mru> wait until the new order of things has settled in [16:46:21] <saste> yes and please discuss on the ML [16:46:28] <mru> of course [16:46:33] <saste> nobody can stay logged on irc 24/24 [16:46:40] <mru> I can [16:46:43] <mru> well, 24/7 [16:46:51] <saste> you're not human ;-) [16:46:53] <kshishkov> trollbot can too [16:47:07] <mru> my irssi has been running continously for ~20 months now [16:47:08] <BBB> saste: we'll discuss, any change goes to ML before anything [16:47:11] <kshishkov> saste: logged != reading that stuff [16:54:29] <mru> uau: mind taking a look at http://patchwork.libav.org/patch/410/ ? [16:56:06] <BBB> is that fully automated? [16:56:10] <BBB> that is kind of awesome [17:01:40] <jannau> patchwork announcement email sent [17:01:44] <lu_zero> yawn... [17:01:50] * lu_zero is feverish [17:01:54] <lu_zero> damn [17:02:27] <jannau> BBB: unfortunately not fully automated [17:02:48] <lu_zero> BBB: there is as least a change from this month breaking h264 decoding [17:02:52] <lu_zero> (noticed yesterday) [17:05:21] <j-b> lu_zero: 24/12 and following days [17:06:47] <BBB> lu_zero: testcase? [17:06:55] <uau> mru: no specific comments, seems to be about what i suggested earlier [17:07:09] <BBB> lu_zero: I'll try to fix as much as I can [17:07:35] <mru> uau: yes, that was the idea [17:08:04] <BBB> I think patch looks ok, I have no strong opinion on it [17:10:14] <lu_zero> BBB: let me dig [17:10:19] <BBB> thnks [17:10:24] <lu_zero> j-b: if you have one please send him ^^; [17:10:37] <BBB> regarding swscale 7/7, why do we keep templating the C functions in altivec? [17:10:40] * lu_zero is really feeling worse now [17:10:55] <lu_zero> BBB: one step at time ^^ [17:10:58] <BBB> so my view of the ppc/ dir is that it's basically a bunch of implementations, most counterparts of C, others are calling altivec_real impls [17:11:13] <BBB> will that be fixed to not be c copies and not wrap altivec_real but just be altivec_real for the ones implemented as such? [17:11:17] <lu_zero> step 8 would be make the C code completely unteplated [17:11:20] <BBB> (I don't want to whine) [17:11:31] <lu_zero> step 9 would fix ppc since is the easiest [17:11:35] <lu_zero> step 10... [17:11:43] <lu_zero> I'll need your and Dark_Shikari help. [17:14:13] <jannau> mru: http://patchwork.libav.org/patch/410/ is ok [17:14:56] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r96aad41e81 ffmpeg/libavcodec/dsputil.h: [17:14:56] <CIA-29> ffmpeg: Make LOCAL_ALIGNED macro fully C99 compatible [17:14:56] <CIA-29> ffmpeg: C99 variadic macros require more arguments than there are named [17:14:56] <CIA-29> ffmpeg: parameters in the definition. This means we must use an extra [17:14:56] <CIA-29> ffmpeg: indirection to avoid having two different macros for arrays with [17:14:57] <CIA-29> ffmpeg: one resp more than one dimension. [17:14:57] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:16:23] <lu_zero> (and that is something I wanted to do today...) [17:24:15] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rfcb7e535dd ffmpeg/libavcodec/h264.c: [17:24:15] <CIA-29> ffmpeg: Reindent. [17:24:15] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [17:24:28] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r9107892624 ffmpeg/libavcodec/h264.c: [17:24:28] <CIA-29> ffmpeg: Fix crash on resolution change (issue 2393). [17:24:28] <CIA-29> ffmpeg: Don't free RBSP tables (containing decoded NAL units) on resolution [17:24:28] <CIA-29> ffmpeg: change, because we actually need this data to decode the frame after [17:24:28] <CIA-29> ffmpeg: reiniting (with new resolution). Fixed issue 2393. [17:24:28] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [17:29:52] * mru bugs jannau for a promotion to maintainer in patchwork [17:35:12] <BBB> lu_zero: I'll help with whatever it is [17:35:17] <BBB> lu_zero: I assume you mean writing optimizations? [17:35:21] <BBB> I don't mind writing a couple [17:37:25] <lu_zero> BBB: =) [17:37:46] <lyakh> I'm sure someone is about to finish bayer support for the rawvideo decoder?...;) [17:38:03] <mru> lyakh: patches welcome [17:38:03] <BBB> I don't even know what bayer is [17:38:13] <mru> BBB: what digital cameras use [17:38:30] <mru> each pixel contains only one colour component [17:38:40] <mru> 1/2 green, 1/4 each red and blue [17:38:52] <lyakh> hm, I've done it a couple of times - for mplayer and gstreamer, none of those has been accepted in the mainline... [17:39:06] <lyakh> ok, not quite true [17:39:07] <mru> to get a proper rgb image you need to interpolate the components [17:39:08] <kierank> "mplayer and gstreamer" ---> there's your problem [17:39:13] <lyakh> gstreamer has it already [17:39:23] <lyakh> I just tried to fix its bugs... [17:40:14] <lyakh> and in mplayer I've done it as a video-filter, they said, it was a wrong way to do it and a wrong place, and basically have sent me to ffmpeg... [17:40:31] <mru> I guess swscale would be the natural place [17:40:39] <mru> so help lu_zero clean it up [17:41:32] <lyakh> that's exactly the problem - it's easy to program, but it's difficult to do it to fit respective project's understanding where and how it has to be done... [17:43:34] <lyakh> not the rawvideo-decoder? [17:46:52] <ruggles> lyakh: it's just another pixel format type. the decoders should output whatever format the source is in. then swscale could convert if needed. [17:48:08] <lyakh> but what part normally does all the conversions - encoders? [17:48:37] <mru> the converters [17:49:54] <ruggles> usually the raw camera image is ljpeg in some tiff variant, not pure raw pixels. and also often double width/half height so the ljpeg prediction is better. decoders would handle all that. but converting to a normal rgb image or whatever would be swscale. [17:51:38] <lyakh> ruggles: jpeg is not very "usual" for raw camera sensors [17:52:53] <ruggles> but most of the cameras store it in whatever proprietary raw image format the company uses. and many of them are a tiff variant with ljpeg compression. [17:52:59] <lyakh> and how is conversion normally handled in ffmpeg? you don't define a converter for each possible pair, right? so, you first decode the source format to some common one, and then encode to the target? so, a decoder, an encoder and something to match them should be used? [17:54:00] <mru> there are direct converters between common pairs [17:54:04] <mru> others use an intermediate format [17:54:27] <mru> converting bayer to rgb would be natural [17:54:35] <lyakh> ruggles: you're talking about USB cameras, I'm talking about camera (CMOS) sensors - just a sensor itself with some minimum logic to crop it, bin / skip pixels, adjust gain, exposure, etc. [17:55:12] <mru> ruggles: many usb cameras output raw bayer data [17:55:26] <mru> that's why people are complaining in the first place [17:55:42] <lyakh> mru: and that would be called a converter, not a decoder? or just integrated into swscaler?... [17:58:04] <ruggles> lyakh: i was talking about consumer-grade DSLR cameras. if you're just grabbing it from a sensor, i guess the raw video decoder would handle that. but not the conversion to something other than bayer. [17:58:43] <mru> ruggles: consumer-grade still cameras generally save jpeg and do all conversions using their own secret algorithms [17:59:04] <mru> ruggles: most DSLRs have an option of raw images too, however [17:59:13] <mru> and these are just that, raw bayer data from the sensor [17:59:37] <mru> this gives maximum control during processing [17:59:59] <ruggles> the raw images are still losslessly compressed and wrapped in something tiff-ish. [18:00:00] <mru> you do everything manually: debayer, white balance, gamma etc [18:00:09] <lu_zero> ruggles: yes [18:00:11] <mru> ruggles: depends on camera model [18:00:19] <mru> they tend to use some compression, yes [18:00:29] <mru> and they often use a tiff container but that's not a given [18:00:34] <lu_zero> mru: canon and nikon should do that [18:00:35] <ruggles> not all. [18:00:38] <mru> nor does it matter for this discussion [18:00:39] <ruggles> but most. [18:01:32] <ruggles> no, either way you decode raw or you decode something compressed and end up with a bayer image, which still has to be converted to enjoy it. [18:02:01] <mru> compressed or not is irrelevant [18:02:14] <mru> bayer comes out of it, whatever file format was used [18:02:20] <ruggles> yes [18:02:50] <ruggles> but that's another reason why NOT to do conversion in a specific decoder. [18:02:58] <mru> of course [18:03:21] <mru> the camera files often do contain useful hints for the conversion though [18:03:32] <ruggles> lol [18:03:39] <mru> what's funny? [18:03:40] <ruggles> buried in layers of crap [18:03:50] <mru> some of it is plain old exif [18:04:00] <mru> and some is proprietary [18:04:06] <mru> but useful nonetheless [18:04:19] <mru> things like white balance settings [18:04:20] <ruggles> some of it is, but a lot of useful parts are proprietary. [18:04:50] <mru> the point I'm trying to make is that there should be a way to feed this information to following stages [18:04:59] <ruggles> i agree completely [18:05:08] <mru> if the photographer had already set up white balance for instance, you'll want to use those settings [18:06:43] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r6eabb0d3ad ffmpeg/libavcodec/ (13 files in 4 dirs): [18:06:43] <CIA-29> ffmpeg: Change DSPContext.vector_fmul() from dst=dst*src to dest=src0*src1. [18:06:43] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:06:45] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r3b924294ea ffmpeg/libavcodec/ (ac3enc.c ac3enc_fixed.c ac3enc_float.c): [18:06:45] <CIA-29> ffmpeg: ac3enc: use dsputil functions in apply_window() [18:06:45] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:06:46] <mru> jannau: please set patch 297 to committed [18:07:01] <ruggles> :) yay [18:07:10] <mru> ah, looks like I can do it myself [18:07:11] <ruggles> so i did the neon part right? [18:07:15] <mru> yes [18:07:20] <ruggles> sweet [18:07:27] <spaam> ruggles: gz :) [18:08:14] <ruggles> ah, i did miss vfp. thanks mru. [18:08:27] <ruggles> one less thing to spend an afternoon trying to figure out. [18:22:06] <BBB> mru: can you add emu_edge h264 tests for the frext samples of the reference suite? [18:22:51] * _av500_ has put kids in front of cartoons in order to read todays backlog... [18:23:17] <BBB> _av500_: mine is in bouncy chair [18:23:29] <kierank> make kids read backlog and watch cartoons yourself _av500_ [18:27:40] <kshishkov> kierank: and then he'll bug them about decoding quality and demanding them to fix h.265 decoder [18:45:57] <cartman> av500: http://cekirdek.pardus.org.tr/~ismail/2.png [18:47:16] <kshishkov> looks like wrong endianness [18:47:29] <cartman> kshishkov: or Y component missing? [18:47:33] <cartman> kshishkov: see the ref.png there [18:49:54] <mru> looks like wrong component order and rather bad saturation [18:50:17] <cartman> hmm ok first try ;) [18:50:24] <cartman> I encoded a png to yuv with ffmpeg [18:50:34] <cartman> now trying to do yuv->rgb24 [18:51:01] <cartman> I am assuming YUV-YUV-YUV… in the YUV file [18:51:03] <cartman> is that correct? [18:51:12] <cartman> each component an unsigned byte [18:51:14] <kshishkov> depends [18:51:37] <cartman> kshishkov: depends on the what? :) [18:52:02] <kshishkov> on encoded YUV output format [18:52:03] <wbs> cartman: if it's yuv444 packed perhaps, but normally you'd have planar yuv 420 [18:52:21] <cartman> wbs: output is YUV420P I think [18:53:00] <cartman> ok at least it looks like the ref. png [18:53:02] <cartman> ;) [18:53:03] <wbs> cartman: then it's first all the Y components, then all the U components for a subsampled plane, then all the V components for a subsampled plane [18:53:18] <cartman> wbs: ah [18:53:33] <wbs> cartman: you really haven't touched these parts before, have you :-) [18:53:45] <cartman> wbs: for 3-4 days now :D [18:55:03] <cartman> thankfully you are all helping me to understand [18:55:17] <wbs> and mocking you a bit along the way, I hope that's ok :-) [18:55:29] <mru> s/a bit// [18:55:51] <cartman> wbs: the master troll is back, thats expected [18:55:52] <cartman> :p [18:55:56] <wbs> cartman: :-) [18:56:31] <spaam> cartman: when can we see this stuff for ffplay? :) [18:56:38] <cartman> spaam: never? :) [18:56:56] <cartman> hopefully never :D [18:57:37] <kshishkov> spaam: there's one Swedish guy working on neon yuv2rgb for sws [18:58:02] <spaam> kshishkov: who? pJok ? [18:58:09] <cartman> kshishkov: yeah and he is hiding it :P [18:58:42] <kshishkov> spaam: nej, en man från Norrland [18:59:21] <spaam> kshishkov: vem kan de vara. merbanan ? [18:59:31] <kshishkov> spaam: precis [18:59:31] <cartman> spaam: mru [18:59:33] <spaam> eller menar du Tjoppen + [18:59:45] <spaam> kshishkov: okej :) [18:59:49] * mru is not from norrland [19:00:10] * cartman mv mru /dev/norrland [19:00:19] <mru> ENODEV [19:00:24] <kshishkov> mru: but your part of Sweden is crazy too - Wikipedia says you gave up runes only in 19th century [19:00:38] <wbs> mru: where are you from then, btw? [19:00:55] * cartman hugs Wikipedia [19:01:01] <spaam> wbs: dalarna [19:01:12] <wbs> ah, thought I remembered something such [19:02:21] <lu_zero> runes are nice [19:02:37] <BBB> speaking of swedes [19:02:45] <BBB> I saw the girl with the dragon tattoo yesterday [19:02:53] <mru> kshishkov: that's a lie [19:02:57] <BBB> gives a weird picture of swedes [19:02:59] <kshishkov> BBB: you're married [19:03:08] <mru> BBB: stieg larsson does that [19:03:14] <kshishkov> mru: do you still use them? [19:03:17] <BBB> suppose so [19:03:43] <mru> kshishkov: no, haven't for centuries [19:03:49] <kshishkov> mru: http://sv.wikipedia.org/wiki/Dalrunor [19:04:13] <BBB> mru: frext h264 conformance samples and -flags emu_edge fate test please? [19:04:20] <wbs> BBB: the books are quite good, the film isn't really as good IMO [19:04:28] <BBB> wbs: I didn't read the book [19:04:33] <BBB> my wife has it but she's only at chapter two [19:04:45] <BBB> it went so slow that we decided to watch the movie so at least we know what it's about :-p [19:05:02] <wbs> BBB: they're quite long and thick.. and the first like 150 pages are boring, but then you're hooked [19:05:20] <mru> BBB: yes, will do [19:06:06] <kshishkov> wbs: are you talking about "H.264 The Movie"? [19:06:32] <wbs> kshishkov: no, "Män som hatar kvinnor" [19:06:43] <wbs> kshishkov: reading it in Swedish would probably be good for you :-) [19:07:41] <kshishkov> wbs: indeed, but I don't know Swedish contemporary authors at all [19:07:58] <kshishkov> wbs: except Astrid Lindgren of course [19:08:25] <wbs> kshishkov: well, then that one would be a good place to start :-) [19:09:57] <mru> wbs: in sweden, it's women who hate men [19:10:06] <mru> not all of them of course [19:10:15] <mru> but a sizable, very vocal group [19:10:17] <Compn> so uh [19:10:23] <mru> and they have a lot of political influence [19:10:29] <Compn> will x264 merge into ffmpeg ? ;) [19:10:38] <kshishkov> mru: at least you can choose some other women [19:11:33] <lu_zero> Compn: why? [19:11:42] <wbs> mru: did you hear about the school that was critizised for having "bad and outdated" chemistry books, when their chemistry books didn't deal enough with multicultural diversity and gender equality (or whatever you call "jämlikhet") [19:12:05] <Compn> lu_zero : just trolling. [19:12:38] <elenril> wbs: this channel is bad and outdated! [19:13:01] <mru> wbs: that's exa`c [19:13:12] <mru> exactly the kind of thing I'm talking about [19:13:29] * mru typing on kitchen irc station [19:14:13] <wbs> mru: yeah.. luckily it hasn't really gotten to that point over here [19:17:44] <lu_zero> what's exa`c ? [19:18:06] <wbs> lu_zero: someone stumbling on their enter key while typing "exactly" [19:18:17] <mru> lu_zero: a typo caused by me using the kitchen irc station [19:18:22] <lu_zero> ah [19:18:41] <BBB> kitchen irc station [19:18:44] <lu_zero> I thought it was an activism movement or something like that [19:18:52] <mru> lol [19:19:09] <mru> no, it's just my old laptop sitting in my kitchen [19:19:15] <kshishkov> BBB: I also have one but only because my flat has exactly two rooms [19:19:58] <mru> including bathroom? [19:20:00] * lu_zero meanwhile stares as his patchset [19:20:56] <kshishkov> mru: yes [19:21:03] <spaam> lu_zero: how does it go with swscale? :) [19:21:11] * lu_zero wonders why had worked before... [19:21:13] * mru suspects his flat is bigger [19:21:18] <lu_zero> spaam: I'm feverish [19:21:24] <lu_zero> so damn slowly [19:21:36] <kshishkov> mru: IIRC, apartments with joined kitchen and bathroom were built only in Soviet Union [19:21:42] <mru> hehe [19:22:19] <mru> studio flats are bit too claustrophobic for my taste [19:22:30] <spaam> lu_zero: ok =/ but it going forward? [19:22:54] <kshishkov> mru: I can't say I need much space [19:23:16] <mru> kshishkov: just your body needs a lot more space than mine [19:23:38] <lu_zero> spaam: it's just boring refactoring [19:23:38] <mru> wait a few years and see how much junk you accumulate [19:23:59] <kshishkov> I try not to accumulate junk [19:24:15] <kshishkov> and usually I get rid of most of it when it hits some threshold [19:24:27] <mru> but... but... surely you can't be _throwing stuff away_ !??!?! [19:25:01] <kshishkov> I dibelieve in it being stuff before throwing away [19:25:06] <mru> anyone interested in my pile of 2MB S3 pci gfx cards? [19:25:06] <kshishkov> *disbelieve [19:25:11] * elenril is [19:25:14] <mru> or maybe some ati mach64 cards [19:25:21] <mru> several different variants [19:25:25] <kshishkov> mine still works somewhere [19:25:37] <mru> 33.6kbps modem anyone? [19:25:50] <lu_zero> mru: recyclers might [19:25:53] <kshishkov> I reflashed mine to support V.90 [19:27:49] <kshishkov> and Ukrainian garbage bins accept any kind of junk [19:27:59] <kshishkov> mine Acer netbook ended there, for example [19:42:43] <elenril> wow, DonDiego advertising git [19:42:49] <elenril> (on the mplayer ML) [19:42:56] * elenril never thought he'd see that [19:43:14] <mru> diego listens to reason [19:43:24] <kshishkov> elenril: Linus did on FFmpeg-devel :P [19:43:38] <elenril> kshishkov: ? [19:43:42] <mru> I know he's been playing around with git for some time and apparently got used to it [19:44:10] <mru> elenril: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/50310 [19:44:39] <elenril> o_0 [19:44:46] <kshishkov> elenril: see? That's not some Diego [19:44:51] <elenril> that's long ago [19:45:04] <mru> and what a flame war [19:45:09] * elenril wonders what he was doing at the time [19:45:24] <mru> probably reading tvtropes [19:45:36] <wbs> or tagging his mp3's [19:45:37] * elenril had no idea the vcs wars were going on since that ancient history [19:45:53] <wbs> wtf, linus on ffmpeg-devel? [19:46:00] <kshishkov> elenril: yes, our switch to git took a while [19:46:17] <mru> wbs: yes, he's showed up there a few times [19:51:48] <uau> elenril: diego's not doing it particularly well though (that 'git svn clone' will likely take hours, you could give a git-clonable tree and tell how to get started immediately from that with git-svn) [19:52:19] <mru> there's already an auto-synced git-svn tree [20:02:42] <rojas> Hi, This is my first time here. I'm having some build issues if someone could help. [20:02:42] <mru> michael is funny... last time patchwork was discussed he declared it "unacceptable" [20:02:58] <mru> rojas: normally such questions belong in #ffmpeg [20:03:01] <rojas> ah [20:03:04] <rojas> Sorry about that [20:03:07] <mru> np [20:04:09] <rojas> Well actually its not with building ffmpeg, its will linking. I'm using ffmpeg libraries. Still the wrong place? [20:04:18] <mru> still #ffmpeg [20:04:29] <mru> this channel is for hacking on ffmpeg internals [20:04:31] <rojas> gotcha, well thanks for thel heads up [20:04:32] <rojas> ahhh [20:50:37] <siretart> mru: pong [20:50:44] <siretart> (finally @home) [20:51:13] <mru> siretart: it's time to start thinking about the next release [20:51:26] <mru> anything in particular on your wishlist? [20:51:45] <siretart> mru: I fully agree [20:51:46] <_av500_> ponies [20:52:04] <peloverde> vp9 [20:52:05] <siretart> mru: my wishlist: have libavfilter API/ABI stabilized [20:52:27] <siretart> my todolist: now that the bzr import works, write a launchpad recipe that builds daily packages for ubuntu [20:52:45] <siretart> with them, I can start upgrade tests and see if binaries built against 0.6 still work [20:53:01] <mru> I suggest you run fate on those builds and only package those that pass [20:53:03] <siretart> then I can say if we need to fix stuff or should rather bump major [20:53:32] <mru> I think it's time we bumped major regardless [20:53:43] <mru> the list of pending changes is endless [20:53:43] <siretart> regarding fate, I'm considering throwing the samples in a debian package to have it available in the launchpad build daemons (they don't allow internet access at build time) [20:53:59] <mru> whatever you need to do [20:54:26] <siretart> are the samples freely redistributable, or do they have uncertain origins/copyright holders? [20:54:32] <spaam> siretart: that will be a huge package... [20:54:54] <siretart> spaam: a few hundred MB in an arch: all package. so what? [20:54:56] <mru> the copyright status of most of the samples "nobody complained" [20:55:00] <elenril> doesn't fair use or something apply to samples [20:55:13] <siretart> I see [20:55:14] <mru> possibly [20:55:20] <mru> but we never asked anyone [20:55:31] <mru> some of them are from iso/itu test suites [20:55:40] <mru> they have some restrictions on them [20:55:52] <siretart> well, then I'll probably leave that on the PPA. I don't see much use in them in a distro release anyway [20:56:17] <mru> peloverde: you just sent a reply to me instead of list [20:56:24] <peloverde> whoops [20:57:22] <siretart> mru: have you seen CVE-2011-0480? I've got a bugreport filed for that here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610550 [20:57:52] <siretart> mru: I'd like to backport them to release branches. Can I push commits there, or what is the preferred way to go here? [20:58:15] <siretart> CVE-2011-0480 is http://roundup.ffmpeg.org/issue2548 [21:00:05] <mru> siretart: you don't currently have push access, but that can be changed [21:00:17] <mru> I think you can be trusted not to screw up too badly [21:00:27] <peloverde> so the corruption part is fixed and the unfixed parts are just illegal reads [21:00:48] <siretart> mru: I think that would be the easiest for everyone. I had svn access before as well, and the only thing I've touched where the symbol versioning stuff. and backports to release branches of course. [21:01:09] <mru> send me an ssh key then [21:01:19] <mru> or is it already on mphq? [21:03:03] <siretart> I've already sent it to jannau, I think. anyway, you can find it in ~siretart/.ssh/authorized_keys on mphq [21:03:18] <mru> I don't have access to jannau's list [21:04:41] <mru> added [21:05:09] <siretart> thanks! [21:05:15] <mru> I take it you know how to set up a clone to track the release branches [21:05:36] <siretart> yes, I've been using git for packaging for quite some time now [21:06:20] <siretart> what do you think about having debian (and possibly rpm) packaging in master? similar like in mplayer trunk? [21:06:56] <mru> I think it's mostly pointless [21:07:05] <mru> the rpm distros wouldn't use it [21:07:15] <mru> since they patch it to death anyway [21:07:17] <Compn> siretart : why not put it on a branch? ffmpeg-deb ? [21:07:26] * Compn trolls some more [21:07:48] <mru> packaging scripts are better handled by the distros [21:08:00] <siretart> the point is not to have something ready for distros, but to provide easy means to create daily packages from master [21:08:25] <siretart> have you noticed the 'make pkg-deb' target in linux? [21:08:26] <mru> point still stands [21:08:35] <peloverde> if they aren't going to package it we might as well let users make their own packages [21:08:53] <siretart> peloverde: sorry? [21:09:01] <peloverde> rpm distros [21:09:03] <peloverde> fedora [21:09:38] <mru> they do package their own patched versions [21:09:59] <mru> for people building their own, there's not much point in rolling packages [21:10:10] <peloverde> mru: fedora won't ship ffmpeg under anny circumstances [21:10:39] <mru> I thought they shipped one with --disable-everything or similar [21:10:49] <mru> or is that what debian used to do? [21:10:54] <siretart> the 'upstream' packages would provide users an easy means to replace the distro versions with updated, more recent ones. I'm going to do that anyway, and I don't mind having the debian packages seperate. [21:11:07] <siretart> I just wondered it might do a service for our users [21:11:15] <elenril> i'd welcome it [21:14:03] <peloverde> I thin the biggest issue is programs that abuse private symbols [21:14:14] <peloverde> do we have some sort of list of them? [21:14:23] <mru> no [21:14:36] <elenril> coincidence? [21:15:09] <siretart> well, there is the pattern of ff_* for private symbols [21:15:17] <siretart> it's not consistent, though [21:15:42] <peloverde> I mean a list of programs [21:15:44] <peloverde> like audacity [21:15:54] <mru> how could we possibly know? [21:15:59] <mru> audit all source code? [21:16:07] <siretart> by testing [21:16:31] <siretart> audacity is very annoying to test, as they insist on dlopen()'ing libavcodec at runtime [21:16:52] <peloverde> does mplayer still abuse private symbols? [21:17:10] <siretart> of course [21:17:59] <elenril> uau's fork shouldn't [21:18:16] <elenril> svn version does and reimar insists it keeps doing that iirc [21:20:41] <siretart> I remember uau claiming that, so I think that's right. however I don't remember raimar insisting on that. [21:20:59] <siretart> at least I haven't seen (rejected) patches related to this [21:21:18] <mru> I remember someone insisting on it [21:21:24] <mru> might have any of the mplayer devs [21:21:27] <mru> except diego [21:21:28] <elenril> i recall diego trying to support external ffmpeg [21:21:45] <siretart> thinking more about it, I think uau fixed some problems by disabling code, and I think raimar insisted on disabling otherwise working stuff [21:21:49] <elenril> and reimar having objection against thats [21:22:00] <siretart> insisted on *not* disabling, that is [21:24:12] <mru> hmm, stuff fails left and right with LIBMPEG2_BITSTREAM_READER [21:24:48] <mru> we should either fix it or remove that bitstream reader [21:26:36] <uau> siretart: there are some disabled video filters (fspp, mcdeint, qp, spp) that are disabled [21:27:01] <uau> those use dsputil stuff IIRC [21:27:09] <peloverde> I would imagine all disabled video filters are disabled [21:27:17] <peloverde> not just some [21:27:27] <uau> the rest i've fixed to work without using ffmpeg internals [21:28:32] <elenril> peloverde: http://xkcd.com/703/ [21:30:06] <siretart> uau: ah, it seems that I do remember some things correctly after all ;-) [21:30:25] <uau> siretart: i think that if you build svn against shared libavcodec there now in fact MORE disabled stuff [21:30:32] <uau> (and it'll still depend on internals of course) [21:30:43] <uau> /there/there's/ [21:31:44] <uau> so svn as built in debian is strictly worse: it has all those filters disable, plus MORE stuff disabled, plus it still depends on internal symbols that may change in any release [21:32:21] <siretart> I see. will investigate later, I'm focusing on ffmpeg right now [21:32:54] <lu_zero> 22:13 <@peloverde> I thin the biggest issue is programs that abuse private symbols [21:32:58] <lu_zero> 22:14 <@peloverde> do we have some sort of list of them? [21:33:07] <lu_zero> flameeyes should have one [21:33:28] <elenril> didn't see flameeyes in ages here [21:33:41] <lu_zero> elenril: summon him! [21:33:53] * elenril summons some flames [21:33:58] <elenril> and eyes [21:34:03] <lu_zero> he's sleeping [21:34:35] <siretart> lu_zero: is he alright? [21:34:48] <lu_zero> overworked but fine [21:34:53] <elenril> ask him to visit us when he's not [21:35:25] * elenril thinks flameeyes is a pretty cool guy eh trolls gentoo and doesn't afraid of anything [21:36:15] <lu_zero> elenril: =) [21:36:29] <lu_zero> btw he's also keeping for me one of the automirrors for now [21:42:24] <spaam> automirrors? :) [21:42:59] <lu_zero> mail coming soon [21:57:56] * Flameeyes looks around [21:58:06] <Flameeyes> somebody called? [21:58:18] <mru> 21:33 * elenril summons some flames [21:58:43] <peloverde> Flameeyes: I've been told you have some sort of list of programs that abuse private FFmpeg symbols [21:59:19] * mru curses bitstream readers [21:59:29] <Flameeyes> peloverde: not exactly... I did make a few test on that a longish time ago [22:00:07] <Flameeyes> otoh I have almost the whole set of packages available in gentoo built so I can easily scan for usage of a pattern of symbols that are to be considered private [22:00:28] <mru> Flameeyes: could your symbol collision checker be set up with a list of forbidden symbols to report? [22:00:56] <mru> does your list include version tags? [22:01:29] <Flameeyes> mru: even easier, scanelf -gs '-ff_.*' can be used to find binaries with imported reference of all symbols starting with ff_ [22:02:25] <peloverde> A few programs use unnamespaced symbols like match_ext (now av_match_ext) [22:02:29] <mru> could you search it for /(?!av).*@LIBAV/ ? [22:02:47] <mru> +^ [22:02:59] <Flameeyes> mru: uhm the version tag is not matchable with scanelf -gs :( [22:03:17] <mru> shame [22:03:19] <Flameeyes> peloverde: if you have a list of symbols that are gone/going I can build the regex and check for those [22:03:19] <mru> fix it! [22:03:34] <mru> nm libav* | grep -v ^av [22:04:12] <Flameeyes> mru: I could probably write a symgrep command that can do the libav match [22:04:26] <Flameeyes> give me half an hour or so [22:08:26] <mru> so on x86 only ALT_BITSTREAM_READER works at all [22:08:32] <mru> A32 works on ARM [22:08:40] <mru> LIBMPEG2 doesn't work at all [22:09:10] <mru> well, it works mostly, but fails in quite a few places [22:09:33] <mru> such as mpeg and anything using golomb.h [22:10:18] <mru> which includes lossless audio and h264 [22:10:40] <mru> suggestions? [22:11:22] <peloverde> ditch LIBMPEG2? [22:11:38] <mru> that's certainly an option [22:11:52] <mru> it would allow some cleanup round the house too [22:12:18] <siretart> hmrpf. /me fails to reproduce the crashers in http://code.google.com/p/chromium/issues/detail?id=68115 with 0.6 [22:12:47] <mru> http://xkcd.com/583/ [22:13:38] <siretart> lol [22:14:16] <mru> there's an xkcd for just about every situation, and he _still_ keeps churning out new ones [22:32:11] <Flameeyes> mru: uhm ruby's regexp don't seem to accept (?!foo) syntax [22:32:15] <Flameeyes> beside that the script would be ready [22:32:39] <saintd3v> lol @ michael's "can you do this for the videolan repo too?" [22:32:41] <mru> that's perl syntax [22:33:11] <Flameeyes> it _should_ be the same syntax, that's why I'm baffled [22:33:24] <Flameeyes> http://paste.pocoo.org/show/325080/ for an example run [22:33:46] <Dark_Shikari> LOL @ "please get me off your mailing list" [22:34:17] <Flameeyes> [it's an 83 line script including the license header — long live code reuse] [22:35:01] <Jumpyshoes> Dark_Shikari: poor gmail users~ [22:35:59] <j-b> Jumpyshoes: poor gmail users with no brain [22:36:23] <Jumpyshoes> :D [22:36:27] <Jumpyshoes> <-- gmail user [22:38:19] <lu_zero> saintd3v: not a _big_ problem giving him that one [22:39:16] <saintd3v> lu_zero: yeah, but twice in one day just makes it humorous [22:39:32] <saintd3v> Dark_Shikari: LOL [22:39:39] <lu_zero> ? [22:39:56] <saintd3v> Git automirrors, and patchwork [22:40:45] <lu_zero> ah [22:41:37] <lu_zero> well it's wiser IMHO. [22:47:47] <saintd3v> LOL "please get me out of this shopping mall, it's full of people" [22:47:50] <mru> michael always bitched about "root" not doing things his way [22:47:58] <mru> let him do things himself now [22:50:02] <lu_zero> mru: it's up to Flameeyes and jannau provide those [22:50:29] <lu_zero> I just set up the gitorious space as common courtesy [22:54:04] <lu_zero> uhm [22:54:12] * lu_zero wonders why he couldn't pull [22:57:52] <saintd3v> not holding your tongue correctly? [22:58:25] <mru> lu_zero: how you spend your time is of course up to you [22:59:14] <Flameeyes> mru: okay so what did you want me to look for? [23:00:46] <mru> anything with a @LIBAV.* version tag not starting with av [23:01:28] <Flameeyes> okay... /me adds -l/-L switches to the script [23:03:06] <lu_zero> mru: ^^ [23:04:37] <mru> any suggestions what to run on a spare quad-core? [23:05:04] <peloverde> Is there a way to automirror on github? IIRC they had some method that was completely on their side [23:05:23] <mru> we can set up hooks on our side [23:05:42] <lu_zero> peloverde: it's better use local hooks [23:06:30] <Flameeyes> peloverde: I haven't found a way to do that on their side when I looked, yet I remembered them having one at some point [23:06:43] <Flameeyes> for gitorious it was easier to look up the ToS and then setting up a scripts on my vserver [23:18:45] <Flameeyes> there's a mistake on the grep(1) man page, yuppie [23:23:21] <mru> fun [23:28:22] <mru> Flameeyes: what virtual machine(s) do you use? [23:28:47] <Flameeyes> mru: kvm generally — but the tinderbox and a few other things run on lxc (which is not a virtualisation system!) [23:29:07] <mru> so nothing like vmware esx? [23:29:48] <Flameeyes> nope [23:29:54] <mru> lxc is just namespaces within the same kernel, right? [23:30:08] <lu_zero> right [23:30:21] <mru> less overhead, less isolation [23:30:47] <lu_zero> exactly [23:31:39] <saintd3v> i've been meaning to setup an esxi box :/ [23:31:59] <mru> I just installed it on my core2q [23:32:08] <mru> now I'm trying to figure out how the fuck to control it [23:32:41] <saintd3v> hak5 had some good episodes on esxi [23:34:42] <Flameeyes> mru: I'd add "very little isolation at all" [23:34:47] <jannau> mru: I did already before or shortly after you bugged [23:34:55] <mru> jannau: I noticed [23:37:22] <mru> vmware website sucks [23:38:21] <Flameeyes> okay elfgrep running on tinderbox, will take a bit [23:39:51] <spaam> Flameeyes: do you have all multimedia package installed? [23:40:02] <Flameeyes> spaam: I have almost all of Gentoo installed there [23:40:27] <mru> how much disk space does that use? [23:40:28] <spaam> ok how much space does it take? [23:40:34] <spaam> ;D [23:40:46] <Flameeyes> about 80G [23:41:14] <spaam> how much space does windows vista take? [23:41:35] <mru> all of it [23:42:09] <saintd3v> Flameeyes: that's why i see you everywhere on gentoo bugzilla =P [23:42:14] <Flameeyes> vista no clue, but 7 should take no more than 8G fom base install or something [23:42:39] <Flameeyes> saintd3v: heh likely.. if there is a build failure, I have filed a bug :) [23:43:53] * lu_zero ponders about the windows autobuilds [23:44:16] <spaam> Flameeyes: are you using USE="*" also? :) [23:45:02] <Flameeyes> nope, just an half-decent combination of USE flags [23:50:33] <spaam> how long will it take to recompile all those packages? :) [23:53:16] <Flameeyes> about 6 weeks if nothing goes wrong [23:53:16] <Dark_Shikari> mru / Flameeyes: ping [23:53:19] <Flameeyes> Dark_Shikari: pong [23:53:21] <mru> pong [23:53:24] <Dark_Shikari> I invited you to a channel, join it [23:56:09] <jannau> ruggles: you're also ffmpeg maintainer on patchwork

1 0

IRC log for 2011-01-21
by irc＠mansr.com 22 Jan '11

22 Jan '11

[00:47:52] <mru> I made a little chart: https://spreadsheets.google.com/ccc?key=0AguHvNGaLXy9dHRYMFZpODZ5dXdyV0JNaG… [00:48:10] <mru> running 30-day average number of ffmpeg commits [01:02:28] <lu_zero> mru: the chart is quite interesting [01:03:41] <lu_zero> seems we have some kind of seasonal trends [01:05:08] <mru> some might be gsoc-related [01:05:18] <mru> qualifications tend to see a burst [01:05:34] <lu_zero> yes [01:08:44] <mru> and something happened in 2006 [01:25:04] <jannau> mru: cvs svn switch? [01:25:54] <mru> something gave development a boost [01:27:50] <jannau> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-May/011293.html [01:29:53] <mru> maybe svn is that much better than cvs [01:30:06] <jannau> less hassle to commit with svn than cvs seems a likely cause [01:30:43] <jannau> I think I forgot how bad cvs really was [01:30:51] <iive> there must be few months with zero commits. [01:31:18] <mru> why? [01:31:28] <iive> mphq hardware died [01:31:45] <mru> we had it back up on new hw rather quickly [01:32:00] <mru> that was in may/june 2006 [01:32:08] <iive> not that quickly [01:32:15] <mru> I don't remember [01:32:34] <uau> there was some downtime [01:32:37] <mru> hmm, was ffmpeg still on sourceforgery at the time? [01:32:52] <iive> most probably [01:32:57] <uau> IIRC some extra for at least mplayer because diego wanted to prettify the svn repository history before putting it up [01:33:13] <mru> that would have been days, not months [01:33:16] <iive> moving files [01:33:33] <uau> it was more than days, something like weeks IIRC [01:33:46] <mru> must have been one ugly cvs repo [01:35:20] <uau> there's a gap in mplayer commits from may 18 to 30 [01:40:43] <uau> i don't think the move to svn was a big factor in development btw [01:45:04] <jannau> google soc started 2006 iirc [01:45:13] <mru> yes [01:45:51] <Dark_Shikari> Good news, everyone! The Sandy Bridge is approved and will be built. [01:47:28] * mru would rather have a bridge built from bricks [01:56:03] <Jumpyshoes> Dark_Shikari: the communal one? [02:06:06] <saintd3v> perhaps they should name it "thermae"? [02:08:19] <Dark_Shikari> Jumpyshoes: probalby will be given to me but I'll give out public logins [02:08:56] <Jumpyshoes> Dark_Shikari: okay, nice [02:14:26] <mru> fosdem schedule preview: http://fosdem.org/2011/preview-program [02:14:43] <saintd3v> should probably be "balnea" then :P [02:19:19] <mru> hmm, several trolling targets there [02:19:25] <lu_zero> where? [02:19:33] <mru> fosdem [02:19:36] <mru> systemd: Beyond init (Lennart Poettering) [02:19:58] <mru> BSD-Licensed Toolchain Status (Brooks Davis) [02:20:17] <mru> mk-configure (Aleksey Cheusov) <-- no idea what that is, but it could be troll-worthy [02:20:22] <mru> or perhaps it's something good [02:20:37] <astrange> systemd: we felt like rewriting the startup sequence again without being as good as launchd? [02:20:54] <mru> what's wrong with sysvinit? [02:21:13] <astrange> people start all kinds of things that don't need to run on startup and it makes it take too long [02:21:30] <mru> so they're solving the wrong problem [02:21:52] <mru> and bundling inetd and automount into some all-singing init sounds scary to me [02:22:06] <mru> GNU Autotools (Ralf Wilhenhues) [02:22:18] <mru> Power, Freedom, Software (Karsten Gerloff) [02:22:34] <mru> that last one will probably make me puke [02:23:13] <mru> Android video streaming: Android devices as video prosumers (Fernando Garcia) [02:23:59] <mru> The difficulty of forking (Anne Nicolas, Michael Scherer) [02:24:21] <Dark_Shikari> lols [02:24:25] <mru> Who the bloody hell cares about Debian? (Stefano Zacchiroli) [02:24:54] <Jumpyshoes> :D [02:25:56] <saintdev> mru: "for ffmpeg, we just...." [02:25:57] <Compn> mru : where is the top10 gmane ? [02:26:14] <mru> Compn: http://gmane.org/ [02:26:17] <Compn> oh there it is [02:26:19] <Compn> i'm blind [02:26:24] <mru> #3 [02:26:42] <Compn> activity or gmane accesses ? [02:26:57] <Compn> activity probably [02:27:25] <saintdev> mru: i doubt they cover coups in "difficulty of forking" =P [02:35:38] <uau> astrange: how's it worse than launchd? [02:36:23] <astrange> ah, i missed the part where it mentioned on-demand daemons [02:36:30] <astrange> that's the major feature of launchd i notice [02:36:55] <lu_zero> systemd sounds a _bit_ wrong for servers like apache [02:36:59] <astrange> but it's strange that they mention "elaborate dependency systems" [02:37:05] <lu_zero> among the rest [02:37:08] <astrange> if everything is on-demand, you don't need those... [02:37:18] <lu_zero> uh? [02:38:22] <uau> astrange: which page are you talking about? [02:39:15] <Compn> lu_zero : btw michael said he didnt review your swscale patches yet. how do you assume what he thinks about them? [02:39:22] <uau> the fosdem extended description i guess [02:41:11] <Compn> now i cant find that mail, hrm [02:41:57] <uau> i think not everything can be "on demand" in a way that would remove the need for explicit dependencies [02:42:40] <uau> and when you're not starting services but shutting them down you need to know something about the order to do that in [02:52:00] <lu_zero> Compn: I know he dislikes that way since he told me long ago while I asked my soc student for swscale to do that ^^ [02:57:13] <Compn> ok then :P [02:59:28] <astrange> oh, i think that's dealt with in launchd by suggesting that services be able to stop at any time via kill -QUIT [02:59:37] <astrange> makes shutdown a lot faster if you don't have to cleanup [02:59:41] <astrange> of course that doesn't always work [03:00:46] <uau> are the services also supposed to deal with another service they depend on stopping first? [03:35:19] <mru> uau: please stick your head in this bucket of sand [03:35:33] <mru> good... now, do you see any problems? [04:44:41] <Compn> http://vicerveza.homeunix.net/~viric/soft/bug/ [06:15:28] <peloverde> When did networking in mainstream distros get so bad [06:16:30] <Dark_Shikari> It was never good [06:17:14] <Dark_Shikari> much like /b/ [06:17:29] <peloverde> i've used linux for 10 years, never had a network problem until 6 months ago [06:18:32] <peloverde> well maybe that's a bit of an embellishment, i didn't have a network problem until network manager showed up, then it's been on and off problems [06:20:15] <saintdev> that bad? lol [06:21:05] <thresh> network-manager? yes [06:22:51] <saintdev> thresh: i've never had a problem with it (well, except for it's awful openvpn support) [06:24:06] <thresh> saintdev: yeah, they somehow think there could be only one VPN at a time [06:24:34] <saintdev> thresh: or even worse, no vpns at a time! =P [06:24:34] <thresh> I don't like the whole idea of "first you log in, then you have the network" [06:24:37] * elenril thinks network manager is pure evil [06:26:00] <saintdev> i like network-manager for my netbook. i take it everywhere, and never know what network i'm going to be connecting to. [06:27:33] <peloverde_> it's too gui centric, too wireless centric, and too opaque [06:28:03] <saintdev> peloverde_: true, and that's why i don't use it on my desktop [06:29:35] <peloverde__> it only took two reboots but networking is alive, yay! [06:29:54] * saintdev misses 16saayunz [06:30:49] <peloverde__> that guy was a dick [06:32:56] <saintdev> maybe i'll steal his sweet nick, then [06:48:43] <elenril> it's too gui centric, too wireless centric, and too opaque [06:48:45] <elenril> ^YES [06:49:11] <elenril> at least debian isn't pushing it [06:53:45] <peloverde__> it was the default in squeeze [06:54:23] <peloverde__> 16saayunz :Erroneous Nickname -- "oh noes!" [06:54:53] <saintdev> doh! [06:54:57] <saintdev> should have kept it :/ [06:55:11] <peloverde> I would have lost it anyway, i played some tf2 after work [06:55:26] <I6SAAYUNZ> close enough [06:55:38] <saintdev> rebooting just for steam sucks :/ [06:55:54] <peloverde> fun fact, steam ships ffmpeg [06:55:55] <saintdev> kierank, yeah [06:56:04] <astrange> without committers how do we tell when someone should get ops? [06:56:13] <_av500_> peloverde: wait till they go wemb [06:56:14] <saintdev> kierank: or l6saayunz in lowercase [06:56:16] <kierank> peloverde: well they won't once they upgrade their chromium [06:56:35] <astrange> did they drop ffmpeg for vp3? [06:56:45] <astrange> + mp3 is still in i think [06:57:04] <saintdev> peloverde: yeah, we've discussed that here before, it's because of their chromium embedded [06:57:27] <kierank> while you're here astrange: Do I have to do anything special if I want to stick user_data in the AVFrame in ffmpeg-mt? [06:57:53] <_av500_> user_data-mt [06:58:05] <kierank> for mpeg-2 and h.264 [06:59:01] <elenril> peloverde: i'm pretty sure it wasn't [06:59:18] <elenril> i installed squeeze just a few weeks ago on the machine i'm ircing from [06:59:29] <peloverde> so did I [06:59:51] <elenril> maybe it's installed by default with some desktop crap like gnome [06:59:59] <peloverde> I installed gnome [07:00:01] <elenril> just get rid of it then [07:01:58] <astrange> i don't know when you can safely free() it [07:03:08] <kierank> hmmm [07:03:54] <astrange> ahh. you can free or overwrite it when it comes back from get_buffer() the next time [07:04:22] <kierank> I'm not sure at the moment if i'm passing it to the right pointer [07:04:30] <astrange> except it should be av_fast_malloc instead of free, of course [07:04:49] <kierank> because internally it copies the data but the output data from the api is empty [07:05:15] <astrange> add it to FF_COMMON_FRAME and it should come out the other end [07:05:34] <kierank> that's what i did [07:10:39] <kierank> http://pastebin.com/LHgzzGRW [07:10:47] <kierank> ignore the h.264 one for now [07:14:08] <astrange> mpeg12 isn't mt enabled so that should be the same as mainline [07:14:23] <astrange> (it's written but turned off) [07:14:24] <astrange> sample? [07:16:34] <kierank> hmmm maybe something stupid in my code then [07:18:34] <Dark_Shikari> kshishkov: we found the english equivalent to http://en.wikipedia.org/wiki/How_does_one_patch_KDE2_under_FreeBSD%3F [07:18:43] <Dark_Shikari> someone came to #x264 to ask a question about japanese [07:18:49] <thresh> :) [07:20:21] <elenril> that's a natural thing to do [07:20:32] <elenril> where else would you ask about that [07:20:43] <Dark_Shikari> #japanese? [07:24:39] <peloverde> ADPCM in mov is almost working now... [07:42:21] <Tjoppen> bcoudurier: I need to implement support for opatom in the mxf demuxer. any thoughts? [07:44:54] <cartman> moin [07:45:40] <thresh> moroning [07:53:24] <andoma> morning [07:53:44] <saintdev> hi guys [07:59:01] <peloverde> Any ideas as to why when coding the same stream to different containers I get different numbers of packets? [08:02:47] <astrange> adpcm can have multiple frames per packet. but i don't know what would make the choice different [08:03:06] <astrange> hmm, request to make avcodec_decode_video2 async with mt... i think that's problematic [08:03:43] <peloverde> When writing to mov I'm getting 1142 size 1024 packets [08:03:58] <peloverde> when writing to wav I'm getting 1300 size 1024 packets [08:07:59] <kshishkov> Dark_Shikari: I thought that x264 was only for Touhou tips and tricks [08:12:01] <Tjoppen> peloverde: is either of them correct? [08:12:13] <peloverde> 1300 seems to be correct [08:12:49] <Tjoppen> odd. I'd expect wav to be a little trickier, since both it and avi doesn't handle start_time != 0 very well [08:29:10] <peloverde> It's ALLLLLLIVVVVE [08:29:33] <kshishkov> whut? [08:30:48] <peloverde> adpcm in mov [08:31:09] <pJok> and avi in mov? [08:32:28] <elenril> anyone knows how do per-muxer avoptions work? [08:32:40] * wbs knows [08:32:58] <kshishkov> pJok: you can encapsulate asf in mov, but I've not seen avi-in-mov yet :( [08:33:13] <Tjoppen> wait - ffmpeg displays muxer avoptions without them being usable? [08:33:27] <cartman> is there a way to check the validity of an RGB565 data? [08:33:30] <elenril> wbs: how do i use them? [08:33:38] <wbs> Tjoppen: they're usable, there just aren't any muxers using them yet [08:34:00] <Tjoppen> ah, I see [08:34:03] <wbs> elenril: as in, how do you add options to your muxer? [08:34:26] <elenril> yes [08:34:43] <elenril> and how do i check if the option is set [08:35:02] <pJok> kshishkov, ah yes, it was asf that flip4mac put into mov [08:35:17] <wbs> add a "const AVClass *class"; as the first member of the priv data struct, set the .priv_class field in AVOutputFormat for the muxer [08:35:47] <wbs> and in the AVClass that .priv_class points to, list AVOptions that can set fields in the priv data struct [08:36:00] <DonDiego> kshishkov: what about those patches you wanted to send? :) [08:36:10] <wbs> the http urlprotocol does something similar, you can have a look at that [08:36:37] <wbs> and if they're set, the fields in the priv data struct are initialized with the desired value that the options set [08:36:54] <cartman> anyone? [08:37:10] <wbs> cartman: any data is valid rgb565 data [08:37:28] <cartman> wbs: hmm [08:37:50] <cartman> so I guess I should at least see a picture [08:38:40] <elenril> wbs: thanks, i'll try that [08:39:02] <cartman> wbs: any idea why glTexImage2D would return error code 0x31 ? [08:39:06] <Tjoppen> calculate the energy of each plane and make sure they're within "reasonable" values? [08:39:08] <kshishkov> DonDiego: send me some time first [08:39:17] <Tjoppen> like "not too flat, not too random" [08:39:41] <Tjoppen> but in general -> ocular inspection [08:40:01] <av500> kshishkov: what are you using your 20% time for? [08:40:12] <pJok> kshishkov, is ffmpeg finally getting demuxer chaining? [08:40:52] <wbs> cartman: uhm, glTexImage2D returns void? ;P [08:41:04] <wbs> cartman: do you mean what glGetError() returns afterwards? [08:41:14] <cartman> wbs: yup [08:41:19] <cartman> wbs: lots of 0x31 :/ [08:41:46] <cartman> wbs: I am passing a uint8_t* RGB data with GL_UNSIGNED_SHORT_5_6_5 type [08:41:50] <wbs> 0x31 doesn't seem like a valid gl error code to me, they seem to either be 0 for no error, or 0x500 -> for normal errors [08:42:11] <cartman> wbs: wonder if glGetError() call is fucked up then :D [08:42:25] <cartman> GLint error; [08:42:26] <cartman> for (error = glGetError(); error; error = glGetError()) [08:42:26] <cartman> LOG("after %s() glError (0x%x)\n", op, error); [08:42:30] <cartman> looks correct though [08:42:42] <wbs> looks right to me, too [08:42:50] <wbs> what does your glTexImage2D line look like? [08:43:10] <kshishkov> av500: 1) I'm not working at Google 2) You're supposed to have left - Michael had used word "leader" once again in mail [08:43:12] <wbs> and sure you didn't have that error before calling glTexImage2D too? [08:43:17] <cartman> wbs: http://ffmpeg.pastebin.com/raw.php?i=V5QZtzqb [08:43:41] <cartman> wbs: yep sure, [08:43:50] <cartman> other GL operations check for error too [08:44:11] <wbs> cartman: well that looks right to me. sure that you've initialized the texture object and bound it prior to that? ;P [08:44:43] <cartman> wbs: http://ffmpeg.pastebin.com/raw.php?i=pJ7i650Z [08:44:44] <cartman> :D [08:45:08] <wbs> cartman: looks ok to me [08:45:22] <cartman> wbs: ok then should look for TEXTURE_WIDTH etc. [08:45:37] <cartman> wbs: must be a power of 2 right? [08:45:41] <spaam> is this #opengl? :D [08:45:47] <cartman> spaam: yep [08:45:47] <cartman> :P [08:46:01] <cartman> spaam: working on FFmpeg indirectly :P [08:46:15] <elenril> where is AVClass defined? [08:46:21] <wbs> elenril: avutil somewhere [08:46:24] <elenril> i seems to fail at grepping [08:46:56] <elenril> ah, found it [08:47:19] <spaam> cartman: ok ;) so #ffmpeg-opengl [08:47:32] <cartman> spaam: yup [08:47:36] <astrange> non power of 2 textures are allowed recently [08:47:53] <cartman> astrange: uhm this is OpenGL ES 2 I think [08:47:56] <cartman> how recently? :D [08:47:57] <wbs> cartman: in ES2 it shouldn't be required [08:48:09] <cartman> wbs: oh [08:48:31] <cartman> then why the heck this call would return an error :( [08:49:14] <astrange> ARB_texture_non_power_of_two, probably mandatory in 3.2 and es2 [08:49:25] <cartman> astrange, wbs thanks [08:49:25] <astrange> either that or mandatory not in es2. i forget which [08:50:09] <cartman> that will simplify the code [08:50:46] <peloverde> hmm, something is still off, i'm still seeing a segfault in gstreamer and no output in quicktime [08:51:27] <cartman> astrange: Google confirms you ;-) [08:51:45] <cartman> kind of :P [08:51:58] <kshishkov> peloverde: I'm not sure you're supposed to use M$ ADPCM in mov at all, hence official QT confusion [08:52:11] <av500> does IMA adpcm work in mov? [08:52:18] <av500> or is it AAPL ADPCM only? [08:52:27] <peloverde> kshishkov: it's explicitly listed as allowed in the QTFF spec [08:52:38] <av500> BBB: btw, the guy that hired you steps down now... [08:53:11] <cartman> av500: cashing out like crazy too [08:53:37] <kshishkov> peloverde: what kind of ADPCM is it exactly? [08:53:46] <peloverde> -acodec adpcm_ms [08:53:57] <av500> the 3-5 bit variant [08:54:05] <peloverde> aka Microsoft ADPCM-ACM code 2 [08:54:15] <kshishkov> av500: he said they need no more of his adult supervision, probably because of BBB being hired [08:54:32] <kshishkov> peloverde: it needs extradata [08:54:36] <peloverde> DVI/Intel IMAADPCM-ACM code 17 is also allowed [08:54:43] <peloverde> kshishkov: it has extradata [08:55:39] <kshishkov> can FFmpeg play it? [08:55:51] <peloverde> yes [08:55:53] <peloverde> so can VLC [08:56:06] <peloverde> (which couldn't play it before) [08:56:37] <kshishkov> is "wave" atom present? [08:56:42] <peloverde> yes [08:57:07] <peloverde> and the extradata is in an ms$0$2 atom just like the file generated by quicktime [08:57:48] <kshishkov> so can you print both files' structure and compare them? [08:58:20] <peloverde> that's what I'm working on now [08:59:18] <av500> peloverde: so you dropped AAC to work on ADPCM? :) [08:59:28] <peloverde> hmm, only stereo seems to be broken [08:59:35] <peloverde> just like AAC [08:59:52] <kshishkov> peloverde: it's your karma then ;) [08:59:59] <av500> stereo is dead, most phones have only 1 speaker... [09:00:31] * kshishkov writes a patch for dropping stereo wavpack support [09:01:08] <peloverde> anyone with QT (pro?) on a mac willign to make a stereo file for me? [09:01:15] <wbs> peloverde: sure [09:03:49] <wbs> qt pro doesn't seem to have any ms-adpcm codec out of the box at least, only their own IMA 4:1 [09:04:08] <peloverde> yesterday astrange remuxed a wav [09:04:31] <kshishkov> probably you need qtpro for windows for that [09:04:44] <kshishkov> and old version of it too [09:04:52] * pJok tries qt pro on his windows [09:04:53] <peloverde> I do have qt pro for windows [09:06:19] <pJok> AAC, AMR-NB, ALC, IMA, PureVoice and iLBC are the only options i have [09:06:52] <peloverde> pJok: that's all i have too [09:07:17] <peloverde> crap I'm double natted and can;t seem to connect to FTP [09:08:15] <peloverde> wbs: do you have an audio passthrough option? [09:09:33] <wbs> hmmm, I remember seeing something such somewhere, but can't seem to find it now [09:09:55] <wbs> (I'm looking in the qt player 7 "export" dialog, with the preset "Movie to QuickTime Movie") [09:12:31] <wbs> hah, found it [09:12:46] <wbs> http://albin.abo.fi/~mstorsjo/msadpcm.mov [09:13:13] <wbs> if choosing "movie to hinted movie", it won't transcode anything, just remux.. and you can uncheck the actual hinting [09:13:54] <peloverde> cool [09:13:56] <peloverde> thanks [09:15:43] <astrange> Save As is remux [09:15:51] <astrange> it's difficult to reencode video and remux audio [09:17:28] <wbs> ah [09:17:49] <cartman> http://people.xiph.org/~xiphmont/demo/ghost/demo.html btw [09:19:12] <peloverde> figuring out what's differnet about these files will be a task for tomorrow [09:19:15] <peloverde> good night yall [09:19:19] <av500> ffghostenc [09:21:59] <peloverde> ffhowdowecashinonthepilesofmoneythatredhatandmozillashovelatxiph [09:23:31] <av500> use the money to patent vorbis maybe :) [09:24:06] <peloverde> we've not 'free' enough to get xiph style money and we aren't proprietary enough to get on2 style money... some sort of local minimum [09:24:20] <cartman> peloverde: who is "we" ? [09:24:21] <kshishkov> "First and foremost, Ghost is vapourware." <- one doesn't need to read further [09:24:42] <kshishkov> cartman: FFmpeg [09:24:57] <cartman> kshishkov: ah [09:25:28] <av500> peloverde: we are screwed(tm) :) [09:26:11] <kshishkov> av500: weKnow(tm) [09:26:44] <av500> wiiKnow [09:27:08] <kshishkov> av500: FFmpeg does not belong to Nintendo [09:28:05] <av500> kshishkov: mabye it should [09:28:09] <thresh> ..yet [09:28:27] <peloverde> Make it so! [09:31:35] <kshishkov> FFmario + FFzelda should fix that [09:32:12] <av500> kshishkov: 1st game we should release is a 1st person shouter [09:32:39] <kshishkov> and 3rd person bikeshedder [09:37:07] <saintdev> lol [09:37:23] <kshishkov> it should be quite popular genre out here [09:38:34] <thresh> one should ask blizzard to add 'bikeshedder' class to diablo3 [09:38:41] <wbs> I do think some more clarifications regarding the "new maintainers" should be posted... e.g. http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2011-January/010100.html [09:42:12] <astrange> CELT is rather good, i wonder if there's room for ghost to be better than it [09:42:29] <kshishkov> not for coding speech, at least [09:43:22] * av500 watches ghost in the celt [09:43:58] <Dark_Shikari> astrange: ghost can be better with more latency and larger packet sizes [09:44:04] <Dark_Shikari> the largest celt packet size is still tiny [09:44:14] <Dark_Shikari> celt has to worry a lot about the size of side information [09:44:18] <Dark_Shikari> also celt is designed for error resilience [09:44:22] <Dark_Shikari> so they throw out a lot of possible inter prediction [09:44:28] <Dark_Shikari> esp. entropy coder inter prediction [09:44:31] <Dark_Shikari> e.g. contexts based on past frames [09:47:44] <vipw> wbs: are there any plans to support encryption in http live streaming? [09:48:28] <wbs> vipw: patch welcome I guess, I haven't run into any such and I've mostly skipped over those parts in the specs [09:48:30] <kshishkov> Dark_Shikari: have you made any contributions to CELT spec? [09:56:55] <DonDiego> ogg anyone? reimar is pinging patches... [09:57:23] <Dark_Shikari> no [09:57:28] <Dark_Shikari> I'm not an audio guy [09:58:18] <kshishkov> Dark_Shikari: you're better than me [09:58:50] <pJok> kshishkov, bink audio encoder? [09:59:10] <kshishkov> pJok: only when Dark_Shikari finished Bink video encoder [09:59:24] <saintdev> pJok: only if it's 1/2 the quality of the aac encoder [09:59:31] * saintdev hides [10:00:22] <kshishkov> saintdev: yes, it sports this wondeful property of stereo encoding having half quality of mono encoding [10:03:17] <peloverde> anyone have usac RM9? they are doing a better job of hiding it [10:03:46] <kshishkov> whut? [10:03:51] <av500> +1 [10:04:06] <peloverde> USAC Reference Model 9 [10:04:13] <peloverde> came out today [10:05:11] <peloverde> The only place I know where to find it is MPEG SVN and I don't have an MPEG SVN account [10:06:59] <kierank> ask zmgorynch [10:07:45] <kshishkov> kierank: sounds like totally Russian nick [10:07:59] <kierank> he's israeli i think [10:09:56] <kshishkov> kierank: there's one country that provided half of their Jews and "Jews", guess its name [10:10:07] <peloverde> so it's just like my day job [10:12:02] <kshishkov> peloverde: does it have something to do with MPEG Surround and its claimed 48k per 5.1 stream [10:12:29] <peloverde> usac can use mpeg-surround for multichannel [10:12:39] <peloverde> mpeg surround low bitrate mode is just generalized PS [10:13:04] <kshishkov> not generalised enough - it still codes real audio even in downmix [10:13:38] <peloverde> huh? [10:14:22] <kshishkov> generalised PS would produce any number of channel from zero audio input (like SAOL does) [10:14:47] <peloverde> PS is always 2:1 [10:14:57] <peloverde> MPEG surrround is N:M [10:15:08] <peloverde> where N and M != 0 [10:15:19] <kshishkov> iKnow [10:15:24] <peloverde> there is no Parametric synthesis in PS [10:15:36] <kshishkov> but somehow I dislike that idea [10:15:49] <kshishkov> and I consider DTS Neo6 to be stupid idea as well [10:15:57] <peloverde> you don't even get a decorated signal without a non-zero input signal [10:16:33] <peloverde> MPEG surround non 2:1 is dumb because PS is really only useful as placebo stereo [10:17:44] <cartman> "Add --nomru switch [10:17:47] <cartman> heheh [10:18:04] <kshishkov> where? [10:18:18] <cartman> MacVim , mru = most recently used :D [10:18:46] <kshishkov> that's why mru doesn't use either Mac nor Vim [10:18:59] <cartman> serves him right :P [10:20:14] <thresh> he uses PPP probably though [10:20:48] <kshishkov> pppoe [10:21:00] <elenril> wbs: are per-muxer options supposed to show in help somewhere? [10:21:01] <kshishkov> simple PPP is for Russians [10:21:10] <wbs> elenril: yes [10:21:29] <elenril> ah, here it is MP3 muxer AVOptions: [10:21:41] <elenril> but nothing else [10:21:49] <elenril> i guess i didn't add something somewhere [10:22:02] <wbs> then you apparently has set the priv class properly, but not added the avoptions to the class [10:22:28] <elenril> the options are there [10:22:41] <elenril> i mostly coped that from http [10:22:56] <av500> #endif comments are mandatory? [10:23:37] <cartman> av500: they are lame [10:24:06] <cartman> unless there is an ifdef jungle [10:25:22] <j-b> 'morning [10:25:28] <elenril> wbs: http options don't show in help either [10:26:06] <wbs> elenril: no, the urlprotocol options aren't hooked up to the ffmpeg.c frontend [10:26:06] <j-b> was this an ifdef jungle? [10:26:26] <elenril> oh [10:26:33] <elenril> they probably should be, no? [10:29:00] <wbs> elenril: probably in the future, but that wasn't necessary at the time, they were useful in order to set up some private options used by the rtsp code [10:29:42] <wbs> elenril: or mostly to be able to first allocate the urlprotocol without opening it, then set some options, then proceed with opening it [10:29:56] <av500> I only have to go down the road for ffosdem: http://www.flickr.com/photos/av500/5375127868/ [10:30:23] <elenril> wbs: am i missing something obvious here? http://pastebin.com/gRKZwUrg [10:30:43] <thresh> this looks shopped, no snow [10:30:58] <av500> elenril: what, no v1 support? [10:31:11] <wbs> elenril: no, looks just right to me [10:31:14] <av500> ah, its id3v2 version... [10:31:15] * elenril stabs av500 [10:31:24] <av500> it should be iv3 version [10:33:34] <kshishkov> av500: you mean it should be set in metadata property "version" of file metadata? [10:33:51] * elenril meta-stabs kshishkov [10:34:40] <av500> cartman: a ffreind? :) [10:35:08] <cartman> av500: we can work it out [10:35:09] <cartman> :P [10:35:44] * av500 presses cartman's like button [10:36:20] <mru> moin [10:36:28] * cartman selects a better buddy icon [10:36:28] <av500> hi mru [10:36:43] <cartman> lo mru [10:36:49] <mru> z all [10:37:08] <av500> nc the rest [10:37:19] <wbs> elenril: ah, yeah - you need to set AV_OPT_FLAG_ENCODING_PARAM in the flags field [10:37:28] <wbs> elenril: otherwise ffmpeg.c won't list it (and probably won't set it either) [10:37:31] <cartman> mru: I am nearly getting frames! :) [10:37:57] <wbs> elenril: getting that committed would be good, to get a full working example of it in place [10:38:22] <av500> wbs: no way, the final endif lacks a comment [10:38:34] <cartman> mru: I have one last (no kidding) problem [10:38:35] <wbs> av500: :-( [10:40:17] <cartman> mru: I added neon_pixconv.S add a pixconv driver, but it claims it can't open PIX_FMT_YUV420P which is my dp->pixfmt [10:40:52] * mru not parse [10:41:18] <cartman> mru: so I added neon_pixconv.S to my source list to use it as a pixel converter [10:41:36] <kshishkov> cartman: have you added DRIVER() in C thingie for it? [10:41:50] <cartman> mru: And I set dp->pixfmt to PIX_FMT_YUV420P in driver's _open method [10:41:53] <mru> it only does 420p to 422/nv12 [10:42:02] <cartman> kshishkov: I think its not needed [10:42:20] <mru> if you set the display format to 420p, no conversion is necessary [10:42:37] <cartman> mru: yeah I think the code in omapfbplay should be changed [10:42:50] <cartman> mru: it looks for a pixconv if the driver has no memman routine [10:43:04] <mru> that is correct [10:43:06] <cartman> mru: it shouldn't need one if frame format and display format is the same [10:43:33] <mru> if the driver has no memman, you need at least a null pixconv, aka memcpy [10:43:46] <cartman> mru: ah... [10:43:49] <mru> but memcpy is evil, so there is no such pixconv [10:43:59] <mru> think about it [10:44:07] <mru> if the driver has no memman, malloc is used [10:44:41] <mru> but then without a "pixconv" how would the images move from the malloc buffer to the display buffer? [10:45:06] <av500> magic [10:45:22] <mru> that magic is callid display->memman [10:45:26] <mru> called [10:45:32] <cartman> mru: long story short I need a memman even malloc based one. [10:45:45] <mru> no [10:45:45] <cartman> a basic* [10:46:03] <cartman> mru: you just called memcpy evil :) [10:46:04] <mru> if you can provide buffers suitable for decoding directly into, you should have a memman [10:46:56] <cartman> but I my case I ask for PIX_FMT_YUV420P data [10:47:01] <cartman> there is no need for a conversion [10:47:18] <mru> can you provide direct rendering buffers? [10:47:35] <cartman> mru: don't know what that means :/ [10:47:47] <mru> buffers the decoder can use directly [10:48:07] <cartman> before usable I have to do a YUV->RGB [10:48:16] <mru> this means they must have 16-byte aligned stride and reside in cached memory [10:48:46] <mru> if you need to convert to rgb, you obviously can't do direct rendering [10:48:53] <mru> so you need a yuv to rgb pixconv [10:49:03] * elenril thinks we have too many "convert string between utf16<->utf-8" functions [10:49:08] <cartman> ah thats what my colorconvert.c does [10:49:11] <elenril> doesn't posix define something for this? [10:49:13] <cartman> so it needs to be a pixconv [10:49:19] <cartman> mru: thanks [10:49:35] <mru> elenril: http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html [10:49:36] <av500> elenril: funny thing is, here is $work, its the same :) [10:50:01] <mru> but iconv is overkill for converting between utf variants [10:50:11] <av500> yep [10:50:20] <kshishkov> and it doesn't support utf-9 [10:50:24] <cartman> mru: with a pixconv in place I don't have to do it driver's _prepare myself, right? [10:50:39] <mru> kshishkov: is that some pdp encoding? [10:50:55] <av500> its utf8 with a blink bit [10:51:00] <mru> you should call pixconv->convert() in your prepare() [10:51:07] <cartman> mru: ah true :) [10:51:14] <kshishkov> mru: http://tools.ietf.org/html/rfc4042 it even features PDP asm [10:51:16] <cartman> back to the coding then [10:51:19] <cartman> thanks [10:51:48] <av500> kshishkov: note the date [10:53:05] <wm4> does anyone know the status of mp3 patents? [10:53:17] <wm4> eh, I should ask in #ffmpeg, sorry [10:53:24] <kshishkov> av500: 21st of January - national hug day in USA [10:53:29] <mru> wm4: I'm sure sisvel has on opinion [10:53:29] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r2611e52088 ffmpeg/libavcodec/dcadata.h: [10:53:29] <CIA-29> ffmpeg: dca: pretty-print some tables [10:53:29] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [10:53:52] <av500> wm4: peloverde had a chart/list [10:54:05] <av500> but some are still valid [10:54:41] <wm4> ah [10:55:16] <av500> and new ones pop up all the time: http://fosspatents.blogspot.com/2010/12/hybrid-audio-llc-sues-apple-htc-and… [10:55:53] <wm4> how can new patents pop up, they'd all be invalid due to prior art? [10:56:06] <mru> that's not how patents work [10:56:16] <av500> Filed: February 25, 1997 [10:56:19] <mru> _anything_ can be patented [10:56:32] <wm4> wat [10:56:57] * av500 has a patent on saying "wat" on irc, sues wm4 [10:57:13] <kshishkov> it's Texas-based company and I suspect court will be held in South Texas as well [10:57:22] * wm4 patented breathing and doesn't give av500 a license [10:57:37] <mru> it's also possible to file a patent and then keep it from being approved indefinitely by filing minor amendments once in a while [10:57:46] <av500> aka submarine patents [10:57:58] <mru> then, when everybody thinks they're safe, you activate it [10:58:00] <wm4> how is it possible that patents are valid, even though there's prior art? are these just courts bullshitting and not following the rules or what? [10:58:05] <mru> and _that_ is when the 20 years start counting [10:58:19] <mru> wm4: there's a lot of that too [10:58:20] <av500> wm4: because checking prior art is :effort: [10:58:31] <mru> kshishkov: eastern district of texas [10:58:41] <av500> and proving a patent in invalid is :big effort: [10:59:01] <kshishkov> av500: only when it's really invalid [10:59:01] <mru> av500: although the success rate is very high when attempted [10:59:03] <wm4> another question, are these patents about decoding, encoding, or both? [10:59:08] <av500> both [10:59:30] <av500> mru: yes, but most ppl settle out of court as this is cheaper :) [11:00:12] <miasma> av500: so is there any estimated date when all mp3 (decoding) patents have really expired. no one knows? [11:00:13] <wm4> conclusion: mp3 won't be free even after 2012? [11:00:38] <mru> miasma: yes, it's expected they'll all be gone by year 2600 [11:00:43] <miasma> :DDD [11:00:43] <av500> miasma: I lost track of when what expires [11:00:56] <miasma> it's also strange that apparently they can also patent container formats [11:01:06] <miasma> but the container is just a simple data definition [11:01:11] <mru> miasma: _anything_ can be patented [11:01:14] <av500> or a simple steel box [11:01:19] <mru> or a rock [11:01:24] <miasma> it's almost like "buy milk, sausage, yoghurt" [11:01:29] <wm4> could they patent something that makes e.g. Vorbis suddenly "unfree"? [11:01:33] <astrange> i think i saw someone patenting sticks [11:01:34] <mru> oh yes [11:01:40] <av500> wm4: no need [11:01:44] <mru> astrange: yes, it was on HN a while ago [11:01:55] <wm4> av500: ??? [11:01:55] <av500> wm4: M$ has nice patents on the stuff used in vorbis [11:02:03] <wm4> oh. [11:02:09] <mru> of course someone has patents on it [11:02:15] <kshishkov> av500: patent "use of Xiphophorus fishes in open technologies promoting process" [11:02:19] <mru> anything of that complexity is bound to touch a few patents [11:02:34] <av500> vorbis is "patent-free" by fiat [11:02:43] <wm4> does that mean there's no point in developing "patent free" technologies like xiph does? [11:02:48] <mru> yes [11:03:09] <mru> it's actually much safer to use codecs licensed by mpeg-la [11:03:14] <kshishkov> BTW, how we got to http://www.webmproject.org/about/supporters/ ? [11:03:15] <miasma> xiph has specialized on advanced container formats like ogg =D [11:03:21] <mru> there at least most of the patent holders have come forward [11:03:49] <mru> advanced, thereis lies the problem [11:03:54] <mru> containers should be simple [11:04:09] <wm4> this patent stuff is so full of fucking bullshit, it's like a license for lawyers to go crazy [11:04:20] <mru> why do you think it was invented? [11:04:49] <wm4> erm... to facilitate development of technology and open standards? [11:05:00] <mru> lol [11:05:09] <wm4> but that's what THEY say [11:05:31] <av500> wm4: in a way yes, the only thing that they missed is that internet years are like dog years, so 20ys should be 3 for the protection period... [11:05:55] <mru> 3 days [11:06:21] <mru> actually, 3 years would be acceptable at least for codecs [11:06:34] <lyakh> so, got a report from sh4-fate... anyone wants it? [11:06:36] <mru> h264 is still king of video and it's much older than that [11:07:01] <av500> lyakh: what does it say` [11:07:03] <av500> ? [11:07:07] <mru> lyakh: thanks, but manually passing reports around isn't practical [11:07:16] <mru> lyakh: did anything fail though? [11:07:44] <av500> lyakh: you can hand a printed report to mru at fosdem :) [11:07:47] <lyakh> av500: how do I know? some base64-encoded stuff. or you mean in test.log? [11:08:00] <superdump> kshishkov: because of developing a vp8 decoder and having webm support in our matroska demuxer i would guess [11:08:01] <mru> I'll "borrow" av500's sh4 and set it up to run continuously [11:08:12] <mru> lyakh: test.log will show if there are any errors [11:08:24] <mru> the base64 stuff isn't much fun to read manually [11:08:45] <av500> mru: I think *you* can even do that [11:09:14] <mru> I've been known to read mpeg streams in hex [11:09:41] <av500> 0x47 [11:10:21] <lyakh> so, nothing that I would interpret as an error... [11:10:25] <mru> sync_byte [11:10:34] <elenril> so: id3v2.3 supports only UTF-16; id3v2.4 supports also UTF-8. [11:10:50] <elenril> anybody can think of a reason not to use UTF-16 in both cases? [11:11:09] <lyakh> anyway, since mru will set up a periodic one, I can dismiss mine;) [11:11:11] <mru> lyakh: does test.log consist mostly of "TEST foo" lines? [11:11:21] <lyakh> mru: yes [11:11:35] <mru> good [11:11:40] <lyakh> what would it have if there were errors? [11:11:59] <mru> can you post that file somewhere? [11:12:03] <mru> that's simpler [11:14:46] <lyakh> http://download.open-technology.de/fate-sh4/test.log [11:18:07] <mru> lyakh: squeaky clean [11:18:17] <lyakh> good, thanks [11:19:13] <mru> so those fixes I made a couple of years ago and tested on qemu after fixing _it_ seem to work [11:21:19] * elenril wonders why aren't avio.h functions prefixed with av/ff [11:22:10] <mru> because nobody bothered to add them [11:22:19] <mru> a patch would be very welcome [11:23:13] <elenril> so i should add an av_ if i'm adding a new one [11:23:33] <Tjoppen> and a major version check perhaps [11:23:47] <mru> depends on whether it's meant to be used externally [11:23:57] <mru> Tjoppen: yeah, unfortunately [11:23:57] <Tjoppen> isn't avio.h installed? [11:24:02] <elenril> it's an installed header [11:24:09] <Tjoppen> yep [11:24:15] <Tjoppen> lunch [11:24:18] <mru> there are probably some functions in there that shouldn't be exported [11:24:29] <mru> and thus should have ff_ prefix [11:24:44] <pJok> mru, is someone btw going to add the android ndk to fate as well? [11:25:09] <elenril> this one converts&writes an utf8 strings as utf-16 [11:25:09] <av500> mru: I can donate an N1 to run fate [11:25:09] <mru> pJok: that's a scary thought [11:25:36] <mru> do android phones have nfs and ssh? [11:25:46] <av500> but only if we publish a fate.apk on the market :) [11:25:57] <av500> mru: rooted ones have what you want I guess [11:26:04] <pJok> mru, yes, but seeing as people try to compile ffmpeg for the iphone all the time and probably also for android it would make sense to have them on there [11:26:30] <mru> it would, but when the vendors try their best to make testing impossible... [11:27:11] <pJok> apple yes [11:27:13] <pJok> htc not so much [11:27:32] <pJok> most of their handsets are now one touch root on mac and linux [11:27:45] <pJok> windows does require a driver install first [11:27:59] <mru> android is still a huge pita [11:28:51] <elenril> should i make LE/BE a flag or create two versions? [11:29:05] <pJok> and for nfs, if the samples are downloaded onto the sd card, nfs shouldn't be needed, i guess? [11:31:22] <pJok> av500, making a fate.apk would require someone to do some java coding ;) [11:31:23] <mru> nfs is still needed [11:31:30] <mru> or some kind of shared fs [11:33:16] <lu_zero> a shared fs or a way to do I/O ? [11:33:32] <av500> nfs seems to work at least on rooted phones [11:33:33] <mru> with the current design a shared fs is required [11:33:45] <av500> or cifs [11:33:50] <wbs> I tried doing some hack on the test process in order to call commands for transferring files back and forth.. it was ugly, and adb randomly stuck on like 1/100 of the executions [11:34:05] <av500> mru: in fact we can use on of our products as well [11:34:23] <av500> a debug build is rooted already and I can add all needed kernel drivers [11:34:27] <lu_zero> av500: ready to put a fate on your nifty tablets? [11:34:33] <av500> why not [11:34:50] <av500> but they are wifi only [11:34:55] <kshishkov> mru: at least your phone is worth the price you payed for it [11:35:03] <av500> unless we add usb2eth as well [11:35:35] <pJok> av500, isn't really a bad idea, using a tablet for fate instead of an N1 ;) [11:36:28] <av500> pJok: I can work on making one that does usb2eth and nfs [11:36:35] <av500> and ssh [11:37:07] <pJok> av500, exactly... another target for FATE \o/ [11:37:18] <av500> but its 2.2 only atm [11:37:26] <kshishkov> av500: you can release it with model number in hexadecimal then [11:37:30] <av500> with 2.3 I guess the NDK changes [11:37:47] <pJok> av500, just have the targets that are possible? [11:38:01] <av500> ? [11:38:11] <pJok> as in, if you only have 2.2, then do 2.2 [11:38:19] <av500> sure [11:38:19] <pJok> you can always add 2.3 later? [11:38:52] <av500> we will have 2.3 runnig stuff soon [11:39:00] <thresh> 3.0? :) [11:39:21] <pJok> thresh, 2.4 will be the next newfangled thing afair [11:39:32] <av500> thresh: can u ask you friends to get me 3.0 source code? [11:39:52] <thresh> av500: i will bring you the cd with it [11:39:57] <av500> thx [11:40:23] <av500> thresh: bought at moscow street corner? [11:40:45] <thresh> av500: where else [11:41:31] <av500> I always thought stuff bought there had much nicer security holograms that the M$ ones... :) [11:42:46] <cartman> mru: can my pixconv's _convert be something like (uint8_t *vdst, uint8_t* vsrc[3]) ? [11:42:55] <cartman> mru: since my dst is a uint8_t* buffer [11:45:00] <mru> the convert has to have whatever prototype the struct definition says [11:45:14] <cartman> mru: ok [11:46:10] <av500> cartman: since its you that will consume the converted buffer, you can ignore the other 2 components [11:46:22] <cartman> av500: guessed so :) thanks [11:46:29] <mru> no such dirty hacks [11:46:35] <cartman> why? [11:46:37] <av500> ? [11:46:44] <mru> obviously only the dst[0] is used for packed formats [11:46:53] <av500> thats what I meant [11:46:57] <cartman> yeah [11:46:57] <mru> oh [11:47:02] <cartman> only use the 1st element :D [11:47:18] <mru> and you'll only be using the virtual address pointers [11:47:23] <av500> mru: I dont do dirty hack *all* day long [11:47:32] <mru> anyway, I'm off to troll some old workmates over lunch [11:47:36] <cartman> :D [11:47:38] <av500> have fun [12:10:38] <elenril> ok, anybody here with windows 7 or some other id3v2.3-only reader? [12:11:50] <kshishkov> windows 7 actually does something? [12:12:20] * elenril heard it show a picture of hitler [12:12:23] <elenril> *shows [12:12:34] <kshishkov> yep, XKCD proved that [12:12:39] * elenril pokes Kovensky [12:12:50] * elenril also pokes JEEB [12:13:03] <wbs> elenril: did you get the avoption working? [12:13:20] <elenril> yep [12:13:23] <wbs> nice [12:13:25] <elenril> the flag did it [12:13:33] <elenril> at least i hope [12:13:38] <elenril> now i need to test it [12:20:16] <DonDiego> $dayjob daily WTF: [12:20:19] <DonDiego> $(TARGET_CONFIGURE_OPTS) CFLAGS="$(TARGET_CFLAGS) \ [12:20:19] <DonDiego> -DKERNELVERSION="\\\"\\\"\\\"$(LINUX_VERSION)\\\"\\\"\\\"" -DVERSION="\\\"\\\"\\\"8.4.1\\\"\\\"\\\"" \ [12:20:19] <DonDiego> -DPPPD_VERSION="\\\"\\\"\\\"2.4.3\\\"\\\"\\\"" \ [12:20:19] <DonDiego> -std=gnu99 -fPIC" LDFLAGS="$(TARGET_LDFLAGS)" \ [12:20:19] <DonDiego> $(MAKE) -C $(PKG_BUILD_DIR)/pppd_plugin/src/ [12:20:33] <elenril> ASCII art? [12:20:37] <DonDiego> welcome to backslash hell [12:21:06] <DonDiego> but it does generate valid C strings, they just look slightly weird with """ around them instead of " [12:23:37] <Kovensky> 09:12.39 elenril pokes Kovensky <-- you know I'm on osx =p [12:23:40] <Kovensky> (the windows hdd is bust) [12:23:55] <elenril> you said something about id3v2.3-only player [12:25:51] <elenril> you don't have it anymore? [12:26:26] <av500> elenril: what do you need? [12:26:36] <av500> win7? [12:26:51] <royger> hello [12:26:55] <elenril> av500: yes [12:27:03] <elenril> or anything that can only read id3v2.3 [12:27:14] <av500> I have win7, no idea what it can read [12:27:22] <av500> but i can try your file [12:27:26] <av500> i guess you mean wmplayer [12:27:28] <elenril> try ftp://ftp.khirnov.net/out.mp3 [12:27:32] <elenril> no, i mean explorer [12:27:40] <av500> oh ok [12:27:45] <av500> after lunch [12:27:48] <kierank> royger: hello [12:28:00] <royger> When encoding mpeg2 video, inside the MPV_decode_mb_internal function is there anyway to know the number of DCTELEM blocks of a frame? [12:28:53] <royger> and possibly the position of the block that I'm currently processing [12:31:22] <royger> I've took a look at the MpegEncContext structure, but I can't find it anywhere [12:31:42] <cartman> mru: is it correct that sysmem.c doesn't have OFBP_PHYS_MEM flag? [12:31:51] <cartman> but I guess its still launch :/ [12:32:32] <cartman> av500: feel free to answer that one :D [12:32:36] <av500> cartman: sysmem is malloc, so virtual [12:32:57] <cartman> av500: what does OFBP_PHYS_MEM refers to then? [12:33:15] <kshishkov> royger: use math - there are three planes with blocks, round their dimensions up to 8, divide by 8, multiply dimensions and sum results for all three planes and you'll get it [12:33:32] <thresh> blocks on a plane! [12:33:50] <kshishkov> thresh: чугуниевые бомбы? [12:34:13] <thresh> kshishkov: не смотрел "snakes on a plane"? и правильно сделал. [12:35:11] <cartman> av500: what is really physical? directly rendering into hw overlay? [12:35:22] <av500> yep [12:35:27] <kshishkov> thresh: чего я только не смотрел, и это тоже не смотрел [12:35:32] <cartman> av500: ok, thanks :) [12:35:50] <av500> cartman: your chain should be all non_sys_mem [12:35:56] <av500> err, non PHYS_MEM [12:36:12] <av500> you use lavc and user space buffers [12:36:42] <cartman> av500: yup, fixed it after you told me malloc != !physical [12:36:54] <av500> k [12:36:58] <av500> lunch now [12:37:43] <royger> kshishkov: mb_num is not it? [12:38:24] <royger> kshishkov: I just want to get the number of luminance blocks of each frame [12:38:55] <royger> (of each I-Frame to be more exact) [12:38:56] <kshishkov> royger: then multiply it by four since every MB is 4 luma 8x8 blocks and some chroma blocks [12:40:09] <royger> kshishkov: and the position of the MB inside the frame, can I get it somewhere? I could use a counter, but if it is implemented somewhere else [12:40:38] <kshishkov> s->mb_x/mb_x [12:40:51] <kshishkov> BTW, have you tried reading comment for MpegEncContext? [12:41:18] <cartman> I/OMAPFBPLAY( 3628): after glTexImage2D() glError (0x8252a764) [12:41:21] <cartman> wtf :( [12:41:35] <cartman> looks like a Windows error :p [12:42:40] <royger> kshishkov: yes, sorry for this. At firts I through mb_num was the size in MB (MegaBytes) [12:42:55] <royger> kshishkov: for what I saw in the comment [12:43:59] <royger> kshishkov: but there's mb_x and mb_y and not a single comment explaining what they mean [12:44:44] <kshishkov> should be obvious if you see they belong to macroblock layer and can guess that mb_ stands for macroblock [12:45:31] <royger> kshishkov: yup, sorry for that. I'm not really clever anyway [13:03:24] <Tjoppen> trying out that mxf clip wrap on the ml. for some reason only the first dv frame is decoded still [13:03:35] <Tjoppen> *clip wrap patch [13:04:02] <Tjoppen> even though the muxer outputs several 144000 B packets. or is this where one has to chain the dv demuxer in somehow? [13:04:40] <lu_zero> cartman: look that error up [13:09:14] <cartman> lu_zero: doesn't exist anywhere [13:16:04] <lu_zero> wonderful [13:23:45] <Kovensky> 09:23.55 elenril: you said something about id3v2.3-only player <-- yes, I had one, but it died around a year ago [13:24:22] <kshishkov> heavy id3v2.3 poisoning? [13:24:25] <elenril> good for you [13:25:02] <Kovensky> hey, it was MUCH better at tagging than any other portables I've used since then! [13:25:22] <elenril> heh [13:25:25] <Kovensky> well, my previous one could read id3v2.4 (I think) but it didn't have japanese fonts so I just got boxes [13:25:33] <Kovensky> and my current one doesn't even try to read tags [13:25:40] <Kovensky> in b4 it only supports id3v1 [13:25:53] <elenril> my current one == my cellphone ignores the tags too [13:25:57] <Kovensky> it also doesn't have japanese fonts but instead of showing the characters as boxes it shows them as squares [13:26:00] <Kovensky> er [13:26:03] <Kovensky> it shows them as spaces [13:26:07] <elenril> it also ignores non-latin1 characters in filenames [13:30:46] <elenril> how nice, we now have one ML for two projects [13:30:52] <elenril> this will be fun [13:31:19] <Kovensky> michael forked the antifork? [13:32:43] <Tjoppen> so.. how many repos now? [13:32:47] <elenril> he committed libmpcodecs to the videolan repo [13:33:10] <kshishkov> Tjoppen: from one to infinity [13:33:18] <elenril> wtf, why is it rebuilding the whole lavc now [13:33:25] * elenril blames kshishkov [13:33:26] <Tjoppen> to infinity and beyond [13:33:37] <kshishkov> elenril: avcodec.h was touched, perhaps [13:33:51] <elenril> i didn't touch it [13:33:58] <elenril> i'm not programmer enough for that [13:34:12] <kshishkov> what have you touched then? [13:34:20] <elenril> maybe it's avio [13:34:37] <elenril> oh well [13:34:47] <Tjoppen> so if I send in a patch now, once OK'd it'll get commited to ffmpeg.org while I have to manually push to videolan (since my pubkey is in that system)? [13:34:49] * elenril loves how make -j4 no longer renders the system unusable [13:35:05] <thresh> try -j14 then [13:35:11] <kshishkov> Tjoppen: precis [13:35:26] <Tjoppen> I forsee a great mess until a compromise is reached. luckily git-merge is wonderful [13:35:55] <kshishkov> elenril: slow CPU? [13:36:19] <elenril> kshishkov: i upgraded the memory, remember? [13:36:29] <kshishkov> elenril: yep, and kernel [13:37:00] <elenril> if i tried something like that before, i'd have to spend aeons in iowait [13:37:21] <Kovensky> swappity swap [13:38:42] <jannau> git merge is prohibited in both repos to ensure the real commit to merge commit ratio is better than 20:1 [13:39:07] <jannau> Tjoppen: it's probably easier if you commit only to one repo [13:39:22] <elenril> or cherry-pick [13:39:39] <jannau> if you want to commit to both please use cherry-pich -x [13:39:42] <kshishkov> jannau: sounds a bit like Torrent tracker conditions [13:41:43] <superdump> did i miss something or are you just talking about michael committing to videolan.org? [13:42:37] <{V}> commit:merge ratio is important? [13:43:29] <Tjoppen> might look a bit like a zipper otherwise I suppose [13:43:46] <Tjoppen> commit to either repo -> pulled and merged in other? [13:44:14] * elenril kicks politics [13:44:25] <cartman> If I wrote raw rgb565 data to some file [13:44:31] <cartman> is there a viewer to open it? [13:44:38] <Tjoppen> gimp maybe? [13:44:39] <elenril> gimp? [13:44:45] <Tjoppen> I win :) [13:44:54] <cartman> any extension will do? :) [13:44:56] <Tjoppen> try the raw import thing [13:45:28] <Tjoppen> that is, choos "raw image data" or something like that when you open a file [13:45:30] <cartman> okies [13:45:34] <jannau> {V}: yes, git log will be annoying if every third commit is a merge [13:45:43] <DonDiego> http://gabucino.be/files/ffmpeg-coup.html [13:45:55] <jannau> also there are ways to duplicate commits with git merge [13:45:56] <DonDiego> gabu-style mindless flaming [13:46:59] <{V}> jannau, thanks [13:47:47] <elenril> wow [13:47:50] <elenril> troll troll is troll [13:49:17] <lu_zero> DonDiego: I'm still wondering [13:51:47] <DonDiego> what is there to wonder about? [13:52:16] <lu_zero> about the latest reply from Michael [13:52:38] <kshishkov> DonDiego: being called "the RMS'ish shady backstabber" - is that a compliment or not? [13:53:49] <KotH> lu_zero: -v? [13:55:44] <jannau> 92.5k google results for "rms backstabbing", 2180 for "stallman backstabbing" [13:56:23] <elenril> rms == root mean square [13:56:34] <DonDiego> kshishkov: i guess that you can consider getting flamed by gabucino an accolade [13:56:44] <lu_zero> KotH: "So myself being 24h loged on to IRC would result in you supporting that fork" [13:56:47] <lu_zero> and my decapitation being undone? [13:57:02] <DonDiego> lu_zero: ETOOMANYREPLIES, which one? [13:57:53] <lu_zero> Message-ID: <20110121090347.GZ17803@kiste2> [13:57:55] <superdump> i was hoping for much more after michael's initial responses, but it seems he's given up on that and is lashing out [13:58:39] <superdump> gabu has a point though - what does fabrice think about this? [13:59:09] <DonDiego> geez [13:59:23] <DonDiego> you're not *seriously* falling for this troll comment, are you? [14:00:12] <cartman> Fabrice is happy hacking qemu [14:00:20] <pJok> is Fabrice still alive? [14:00:20] <kshishkov> superdump: should he think about that at all? [14:00:26] <cartman> pJok: yes [14:00:36] <pJok> i thought he was just a myth [14:00:38] <superdump> i just meant that if fabrice expresses distaste for what we did, it seems within his power to order us off ffmpeg.org and order us to no longer use the trademark, no? [14:00:46] <cartman> pJok: he is hacking on qemu [14:00:59] <pJok> ah [14:01:03] <kshishkov> superdump: so? A bikeshed by any other name... [14:01:43] <pJok> i bikeshed for ffmpeg to be called ffbikeshed from now on [14:01:50] <mru> superdump: yes, fabrice control the ffmpeg name [14:02:13] <c45t> hi [14:02:28] <kshishkov> mru: can you register bikeshed.org if possible just for lulz? [14:02:30] * jannau has libav.org [14:02:38] <mru> although by not actively using the trademark himself for a very long time, his claim may be weakened [14:02:42] <c45t> I have a question regarding ffmpeg compilation, should I ask it here or on #ffmpeg ? [14:02:55] <elenril> argh, curses [14:02:56] <mru> kshishkov: already taken [14:03:06] <kshishkov> mru: ffbikeshed.org [14:03:12] <elenril> not to self: don't write two patchsets at once [14:03:16] <DonDiego> superdump: you're falling for classic legal troll FUD - a) this is not so easy b) he has not actively meddled in ffmpeg for years, nor is there a sign he would now [14:03:17] <mru> besides, I have enough domain names already [14:03:23] <Tjoppen> c45t: #ffmpeg is probably better [14:03:36] <c45t> ok, thanks [14:04:31] <iive> cartman: i think he is not actively developing qemu either. [14:05:20] * kshishkov refrains from mentioning not actively maintained tcc [14:05:39] <cartman> iive: he served enough I guess :> [14:05:55] <kshishkov> who knew he created LZEXE [14:06:30] <DonDiego> how do i tell git to delete directories that are now empty? [14:06:53] <DonDiego> i'm sure this will fsck up git-svn once more *sigh* [14:07:01] <thresh> git rm dir/* [14:07:28] <elenril> git doesn't track empty directories [14:07:30] <jannau> DonDiego: git doesn't track empty directories [14:07:32] <mru> DonDiego: git normally does that [14:07:34] <thresh> ah empty [14:08:02] <mru> git deletes directories that were emptied by git as a ressult of a commit or merge [14:08:19] <mru> if you create a directory and don't tell git anything about it, it'll be left alone [14:08:35] <DonDiego> i'm using git-svn at work [14:08:37] <av500> fabrice is mostly after pi digits these days [14:09:10] <av500> and feeding his pleosaurus [14:09:21] <jannau> DonDiego: you want to delete a directory in svn? [14:09:24] <kshishkov> av500: who knows, he may calculate e digits now instead [14:09:25] <mru> DonDiego: git-svn has settings for dealing with directories [14:09:46] <av500> kshishkov: infact, he mihgt, his coworker told me he is "secretive" atm [14:09:47] <jannau> I think git-svn --help has a section how to do that [14:10:00] <DonDiego> i'm afraid the dir will be left behind in the svn repo [14:10:14] <av500> "no dir left behind"(tm) [14:10:20] <mru> git-svn has a setting to delete empty dirs [14:10:37] <mru> I don't remember the name, you'll have to rtfm [14:10:52] <jannau> av500: us laws are public domain and can't have a trademark [14:11:19] <DonDiego> jannau: —rmdir, thx for the pointer [14:12:04] <cartman> uhm Gimp didn't open my raw rgb file [14:12:34] <mru> gimp should be able to open raw files if you tell it exactly what they are [14:12:49] <cartman> hum [14:13:33] <cartman> oh yes [14:13:41] <cartman> and we have garbage it seems :D [14:13:49] <kshishkov> av500: you mean he has a job? [14:14:44] <av500> kshishkov: yes [14:14:49] <av500> at least part time [14:16:01] <cartman> mru: now look at that, http://cekirdek.pardus.org.tr/~ismail/raw.png [14:16:26] <av500> cartman: nice [14:16:31] <cartman> av500: ty [14:16:35] <Tjoppen> hrm.. gimp can only open 24 bpp? [14:16:43] <Tjoppen> why not filter it through ffmpeg? [14:16:46] <cartman> Tjoppen: no my output is like that :) [14:16:53] <Tjoppen> ah, ok :) [14:16:54] <cartman> I think [14:16:56] <av500> cartman: you are doing it wrong [14:16:59] <merbzt> Tjoppen: met your "boss" today [14:17:07] <Tjoppen> yeah, I heard [14:17:23] <cartman> av500: seems like yuv->rgb fucked up [14:17:35] <av500> seems so [14:17:38] <merbzt> Tjoppen: so you are here in Stockholm now ? [14:17:46] <av500> but that part you can test outside of android [14:18:13] <cartman> av500: maybe [14:18:14] <Tjoppen> merbzt: yeah, but leaving in an hour :p [14:18:33] <cartman> image dimensions look wrong too but thats possibly my bug [14:18:36] <Tjoppen> me and a another guy from övik/umeå [14:19:22] <merbzt> Tjoppen: how long will you work from Stockholm ? [14:19:30] <merbzt> just this week ? [14:19:50] <Tjoppen> well, not next week at least [14:20:35] <cartman> av500: is there a known/unoptimized algo. for YUV420->RGB565 conversion? [14:20:37] <Tjoppen> might be a few until next time [14:20:40] <cartman> ie. just to check output [14:21:02] <mru> cartman: it's a simple matrix multiplication [14:21:12] <av500> cartman: wikipedia should have one [14:21:13] <mru> the coeffs are defined by half a dozen specs [14:21:15] <mru> differently [14:21:56] <cartman> mru: do you think yuv->rgb conversion fucked up? I had a similar output with a wrong swscale call. [14:22:09] <mru> hard to tell [14:22:26] <av500> cartman: as said, test it offline 1st [14:22:30] <mru> try simply replicating the y component to all rgb [14:22:40] <mru> that should give you a b/w image [14:22:51] <cartman> mru: how do I do that? [14:23:07] <mru> with code [14:23:12] <cartman> surprisingly [14:23:17] <cartman> ;) [14:23:25] <cartman> ok back to debugging [14:23:30] * elenril spams the ML [14:23:36] <cartman> elenril: yeah :P [14:27:10] <cartman> is there a book with such algorithms like yuv->rgb? [14:27:22] <mru> no [14:27:23] <wbs> cartman: wikipedia [14:27:30] <cartman> interesting [14:27:34] <mru> but perhaps there's half a page somewhere [14:27:34] <cartman> would be a nice book ;> [14:27:45] <kshishkov> cartman: it's too trivial, Wikipedia covers it almost completely [14:27:57] <av500> cartman: 1st google hit: http://www.fourcc.org/fccyvrgb.php [14:27:59] <cartman> kshishkov: I meant for all such algos. [14:28:07] <cartman> av500: search string? [14:28:16] <av500> "can haz conversion" [14:28:18] <mru> cartman: the book you're looking for is called "linear algebra" [14:28:33] <cartman> mru: I sadly passes that class with a A- :P [14:28:35] <av500> cartman: http://www.google.com/search?q=yuv+to+rgb [14:28:44] <cartman> av500: yuv2rgb fail :P [14:28:54] <av500> cartman: not all the internet is l33t [14:29:10] <kshishkov> cartman: even I have managed to write some bits for yuv2rgb in swscaler, so you can too [14:29:15] <lu_zero> http://ffmpeg.pastebin.com/uTcfzsZL <- should I send it? [14:29:22] <cartman> thank you all :) [14:29:28] <cartman> stream [14:29:34] <cartman> streaming RTFM ;) [14:29:38] <mru> lu_zero: kind of pointless asking that question on a public channel [14:29:56] <kshishkov> lu_zero: go drink a cup of coffee, reread it again and finally decide [14:30:07] <kshishkov> lu_zero: that's the best approach with such mails [14:30:07] <lu_zero> mru: it's just a re-re-re-hash of what had been said already [14:30:23] <mru> I don't understand line 29 [14:30:42] <kshishkov> mru: too short line buffer? [14:30:46] <mru> try using less italian grammar [14:31:11] <elenril> lu_zero: can you try a less agressive tone? [14:31:24] <kshishkov> mru: it could be German grammar instead [14:32:02] <mru> german grammar requires lookahead [14:32:03] <lu_zero> elenril: that's another reason I wanted a review =) [14:32:23] <av500> hmm, gabucino blog is "refreshing" [14:32:39] <kshishkov> av500: and as good as written in Hungarian [14:33:01] <elenril> lu_zero: the last part feels really hostile to me [14:33:35] <mru> elenril: well, he keeps asking for clarification [14:33:39] <mru> can't get much clearer [14:33:56] <elenril> it can be made clearer in a less agressive way [14:34:14] <elenril> don't know about you, but i'd really like for him to keep contributing [14:34:19] <elenril> as improbable as that may be [14:34:45] <kshishkov> contributing what? [14:34:53] <royger> kshishkov: sorry to ask another dumb question, but why is MPV_decode_mb_internal called two times during decoding with the same block as parameter? [14:35:11] <{V}> kshishkov, any ffmpeg repository. [14:35:11] <elenril> reviews, patches, fflames, whatever [14:35:54] <lu_zero> elenril: I'm growing annoyied since he's swinging from "let's work together and not fragment" to "treason, I won't support you" [14:35:55] <{V}> oops. I imagined a "to" in "contributing what?" [14:36:11] <superdump> elenril: i was hoping that from what i said, he might perhaps distance himself from the situation for a moment, ignore what had happened, think about what positive thing he wanted to achieve for the project if he had no responsibility to it and then do that [14:36:41] <superdump> but it seems to me from his last few responses that he's decided he's not interested in that [14:36:48] <superdump> maybe he feels too hurt by what happened [14:36:55] <mru> "my way or the highway" [14:37:13] <kshishkov> royger: where? [14:37:29] <av500> lu_zero: I understand, but I also think you should not fan the fflames [14:37:33] <elenril> lu_zero: take a deep breath ;) [14:37:50] <elenril> i mean look at mplayer [14:37:53] <superdump> wear him down with relentless positivity? [14:37:54] <av500> lu_zero: and I would not send it like that [14:37:59] <av500> superdump: :) [14:38:07] <elenril> superdump: yeah! [14:38:56] <superdump> in any case, it seems the announcement was confusing to many [14:39:06] <kshishkov> superdump: as expected [14:39:20] <kshishkov> superdump: any major change confuses people no matter what [14:39:39] * elenril ToldYouSo [14:39:44] <superdump> we need to write something about the organisation, general protocol and intended use of infrastructure to clarify how we intend the project to operate [14:40:02] <royger> kshishkov: when recompressing an mpeg2 file, MPV_decode_mb_internal is called twice with the same block as parameter (at least s->mb_x and s->mb_y are the same) and s->encoding is false [14:40:07] <kshishkov> superdump: army principle - you said it you do it. Move! [14:40:12] <wbs> as I said, there's much confusion about "maintainers" now, e.g. http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2011-January/010102.html [14:40:13] <superdump> reusing the word maintainers for some different meaning was a very confusing and negative move it seems [14:40:22] <superdump> i need to have a map [14:40:36] <superdump> s/map/nap/ [14:40:50] * mru gives superdump a map of maintainer types [14:40:58] <av500> not an enum? [14:41:28] <kshishkov> royger: what about context variable itself? Encoder employs decompression too. [14:42:25] <kshishkov> mru: should we separate something into libavsomethingcore? [14:43:05] <royger> kshishkov: maybe that's it, I will have to take a closer look [14:43:18] <kshishkov> mru: just to keep good old traditions [14:43:19] <royger> kshishkov: thanks [14:43:42] <DonDiego> is there an option for git stash that stashes away single hunks? [14:43:49] <DonDiego> like 'bzr shelve' does? [14:44:17] <superdump> i've wanted something like that too [14:44:22] <DonDiego> bah [14:44:23] <mru> DonDiego: git stash --patch [14:44:32] <DonDiego> i need to RTFM more closely [14:44:34] <mru> second page of manual [14:44:42] <superdump> i think i missed it because i was using -p [14:44:42] * DonDiego assigns himself 5 lamer points [14:44:48] <lu_zero> http://ffmpeg.pastebin.com/Dx4un7hh <- amended [14:44:49] <superdump> and that means something else for stash iirc [14:58:40] <DonDiego> mru: where did you get that %= trick in makefiles from? [14:58:47] <mru> the manual [14:59:01] <DonDiego> my last reading of the gnu make manual was a long time ago and my memory... [14:59:17] <kshishkov> mru: that's the last place where one would search for it [14:59:30] <mru> the gnu make manual is quite ok [14:59:36] <av500> info make [14:59:49] <mru> if you skip the sections ranting about how superior it is [15:00:14] <mru> which may be true, but I find chest-thumping unnecessary [15:01:25] <kshishkov> mru: then you're not Stallman. FSF without hype is not that nice [15:01:50] <DonDiego> i agree that it is well-written - only the section about recursive make needs to be rewritten [15:02:02] <DonDiego> it is too short and contains no warnings about the pitfalls [15:02:08] <mru> and replaced with miller's paper [15:02:27] <lu_zero> or even better, add a section about non-recursive make patterns [15:02:41] <mru> occasionally it is useful of course [15:02:54] <mru> if you're building a 3rd-party lib as part of something bigger [15:03:06] <mru> and their makefile against all odds is good enough to be used as is [15:03:43] <av500> mru: well, android wrote an android.mk for every subproject it swallowed and people rant at that :) [15:04:03] <av500> so its non-recursive :) [15:04:45] <lu_zero> android.mk is overly convoluted [15:04:51] <mru> people rant at it because they did it poorly [15:04:54] <lu_zero> and I guess it's ant-inspired [15:05:16] <av500> mru: s/at it because they did it poorly// [15:06:50] <DonDiego> also, should gabu post on -devel or so, don't forget to ignore him completely, nothing works better against trolls [15:07:16] * av500 will feed him only a little [15:07:38] * mru stocks up on troll poison [15:08:51] * lu_zero adds a procmail rule [15:09:08] <kshishkov> DonDiego: BTW, why is there such activity among people who are not related to FFmpeg nor even to recent MPlayer development? [15:09:19] <cartman> zombies [15:09:27] <lu_zero> kshishkov: Diego got fans [15:10:20] <kshishkov> I'd care about http://www.gameinformer.com/b/news/archive/2011/01/21/exclusive-duke-nukem-… more [15:13:10] <jannau> kshishkov: so 4 months for everyone who promised something for "... when duke nukem forever is released" [15:13:31] <kshishkov> jannau: yep, kinda harsh deadline [15:14:09] <kshishkov> jannau: that's why I prefer something like "FFmpeg 1.0 release" instead [15:15:39] * jannau prefers TeX 4.0 [15:15:49] <lu_zero> isn't that impossible? [15:16:03] <elenril> thatsthepoint [15:16:11] <mru> not of some state congress decides to redefine e as 4 [15:16:28] <jannau> TeX PI woud do too [15:16:55] <kshishkov> mru: are you afraid to say Kansas? [15:17:20] <av500> waering red shoes? [15:17:23] <av500> wearing [15:17:23] <mru> that was pi [15:17:57] <jannau> mru: TeX is PI, metafont version is e [15:18:11] <jannau> approximately [15:18:36] <lu_zero> at least isn't a decreasing version number [15:18:47] <pJok> ffmplayer? [15:18:57] * kshishkov makes elenril stab pJok [15:19:13] <jannau> but both should be be frozen in case of Knuth's death [15:19:43] <mru> when knuth dies we'll have the exact values of both pi and e [15:20:31] <jannau> ah, yes, I misremembered [15:21:00] <jannau> and all bugs are considered features [15:21:05] <DonDiego> mru: hmm, no diff for your "prettyprint tables" commit? [15:21:23] <mru> DonDiego: apparently it was over some threshold [15:21:29] <mru> it was huge [15:21:44] <DonDiego> kshishkov: what people do you mean? [15:21:51] <pJok> kshishkov, but it makes so much sense ;) [15:23:06] <kshishkov> DonDiego: Arpi and Gabu [15:23:28] <mru> DonDiego: I've increased the limit [15:23:57] <BBB> elenril: utf16 vs. utf8, how about keeping both codepaths? I don't mind utf16 for id3v2.3, but would prefer utf8 for id3v2.4, since it's smaller and generally more used [15:24:06] <DonDiego> kshishkov: i guess they couldn't let such a great opportunity for flaming (me) pass ... [15:24:06] <kshishkov> pJok: well, watch git.videolan.org, probably missing bits from MPlayer will be ported soon (unless written not in Austria) [15:24:15] <mru> elenril: what BBB said [15:24:25] <elenril> i asked here earlier today =p [15:24:29] <BBB> ? [15:24:32] <BBB> I wasn't there :-p [15:24:46] <BBB> the code is already there, all you have to do is not delete it :-p [15:25:05] <BBB> can we have two muxers, one for id3v2.3 and one for id3v2.4? or a AVOption to switch between v2.3 and v2.4? [15:25:12] <BBB> there seems demand for it [15:25:23] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rd08928bbea ffmpeg/libavformat/ (Makefile mp3.c mp3dec.c mp3enc.c): [15:25:24] <CIA-29> ffmpeg: Split mp3 demuxer and muxer into separate files. [15:25:24] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:25:25] <BBB> I don't know what the best way to integrate this is, but we support AVOptions for muxers already [15:25:36] <elenril> BBB: read the patch names =p [15:25:37] <BBB> so this shouldn't be terribly impossible to do [15:26:14] <BBB> oh there, it does it [15:26:15] <BBB> do that first [15:26:16] <pJok> ffmp3enc? [15:26:21] <BBB> no, I missed 5/5 [15:26:30] <BBB> elenril: perfect, but please keep using utf8 for id3v2.4 [15:26:38] <elenril> what's the point [15:26:43] <BBB> smaller? [15:26:44] <av500> shorter [15:26:47] <av500> less millicycles [15:26:51] <elenril> it involves more if()s and general ugliness [15:27:01] <wm4> may I ask what exactly the point is michael committing libmpcodecs to ffmpeg? [15:27:01] <BBB> and most apps read as utf8 internally, so it makes decoding easier for them [15:27:10] <BBB> wm4: we don't know [15:27:14] <av500> wm4: yes, please tell us [15:27:16] <jannau> mru: do plan to send a new patch for LOCAL_ALIGNED? [15:27:28] <mru> jannau: yes, once I've tested it on the sgi machine [15:27:40] <BBB> elenril: I do agree the ifs are ugly, but uh, it's only a few lines of code [15:28:02] <BBB> elenril: also it only applies to the top half of the patch, the bttom half can stay as it is [15:28:02] <av500> elenril: please give us one more if() [15:28:03] <mru> and harldy relevant to performance [15:28:15] <BBB> exactly.. smaller files is worth something imo [15:28:26] <elenril> oh well [15:28:42] <mru> we're the maintainers, do as we say :) [15:28:58] <elenril> i knew it! [15:29:51] <av500> :) [15:30:07] <av500> elenril: and please add #endif comment [15:30:19] <lu_zero> wm4: michael thinks avfilter w/out many filters won't appeal users [15:30:24] <mru> what's with the strz names? [15:30:30] <mru> we're not hungarian [15:30:36] <mru> we know strings are nul terminated [15:30:40] <av500> czech? [15:31:20] <mru> "strc prst skrz krk" is apparently a semantically correct sentence in czech [15:31:28] <elenril> strč [15:31:38] <mru> iKnow [15:31:38] <elenril> otherwise it's correct [15:31:39] <cartman> see you guys, have a nice weekend! [15:31:47] <av500> cartman: slacker [15:31:59] <elenril> anyways, there are functions named put/get_strz [15:32:01] <cartman> av500: my eyes went mad [15:32:05] <cartman> gotta rest :/ [15:32:16] <mru> one bad name does not excuse another [15:32:24] <elenril> consistency is good [15:32:31] <mru> we can rename the other one later [15:32:34] <elenril> ok, i'll remove the z [15:32:40] * kshishkov makes elenril stab himself [15:32:52] <mru> we're planning on putting prefixes on them anyway [15:34:25] <wm4> lu_zero: isn't just copying all the mplayer code a bit unclean as opposed to porting the individual filters to ffmpeg? or was that one of those discussion points [15:34:47] <av500> wm4: indeed it was [15:34:56] <av500> but it will port itself once integrated [15:35:03] <uau> what's with the people wanting to make ffplay a good standalone video player? is there really any good argument why that would be desirable? [15:35:22] <mru> none that I can think of [15:35:35] <av500> I mplayer because ffplay has issues [15:35:38] <av500> +use [15:35:52] <mru> av500: wait until omapfbplay gets audio support [15:35:58] <av500> like missing subs when I need to debug subs for $work [15:36:39] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r583fcb528c ffmpeg/Makefile: [15:36:39] <CIA-29> ffmpeg: Makefile: simplify setting of some variables [15:36:39] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:36:43] <mru> who cares about subs, just learn the spoken language [15:36:48] <kshishkov> indeed [15:36:52] <av500> mru: $customers [15:36:55] <av500> not me [15:37:08] <kshishkov> av500: they should too [15:37:10] <av500> ze french can speak no english etc.. [15:37:27] <av500> kshishkov: yes, but you know, they resistance change a lot.... [15:38:06] <kshishkov> av500: time to sell video language courses bundled with your stuff? [15:38:23] <av500> maybe [15:45:10] <pJok> just let everything be in swedish [15:46:23] * elenril resolves conflicts [15:46:26] * elenril glares at BBB [15:47:24] <BBB> what did I do !!! [15:47:31] <BBB> I don't even touch mp3 files [15:48:02] <elenril> your comments produce conflicts [15:51:21] <BBB> uh... [15:51:28] <BBB> which one? [15:52:10] <elenril> the utf-8 vs utf-16 one [15:52:20] <elenril> don't think about it too hard, it's a joke [15:52:31] <BBB> uhm... [15:52:32] <BBB> ok [15:52:41] <BBB> I don't care about function names at all if that helps [15:52:42] <av500> BBB: just /glare at elenril [15:52:44] <BBB> since it's not public api [15:52:51] * BBB gives elenril the evil look [15:53:04] <elenril> it's almost public [15:53:10] <elenril> mplayer-level public [15:53:39] <DonDiego> bbl [15:54:35] <BBB> elenril: it's private api, no matter what mplayer does [15:58:22] <elenril> BBB: functions in avio.h are private? [15:58:26] <elenril> it's an installed header after all [15:58:40] <BBB> ff_() ones are protected by HAVE_AVCONFIG_H or so [15:58:47] <BBB> so they are considered private [15:59:59] <mru> private functions should not be declared in installed headers [16:00:13] <mru> if they are, I guarantee you someone will abuse them [16:00:39] <BBB> like mplayer :-p [16:00:40] <BBB> I agree [16:00:44] <BBB> but this is how it currently is [16:00:46] <BBB> patch appreciated [16:00:50] <mru> so we should fix that [16:00:54] <mru> not perpetuate it [16:01:11] <uau> elenril: is some of those used in mplayer2? [16:01:54] * elenril wonders what's the difference between put_strz() and put_tag() [16:01:56] <elenril> uau: ? [16:01:58] <uau> or did you just give that as a possible example? [16:02:10] <elenril> it was a joke [16:02:23] <uau> i mean you said "mplayer-level public" - i wasn't sure if you meant that as mplayer actually using them or not [16:02:27] <elenril> i have no idea if mplayer really uses them [16:02:32] <uau> since svn actually DOES use stuff like that [16:02:32] <BBB> it likely doesn't [16:02:40] <uau> but i hope i have cleaned up all of those in mplayer2 [16:02:43] <BBB> because when we moved it, nobody from mplayerland complained [16:02:54] <elenril> uau: you're calling it mplayer2? [16:03:05] <elenril> we were hoping for RealMPlayer [16:03:29] <uau> yes, that was the name talked about long ago and i haven't heard any better alternative [16:03:40] <uau> i don't really like naming things [16:03:41] <av500> mp2 [16:03:46] <uau> and haven't tried to come up with anything else [16:03:48] <elenril> i know a better alternative [16:03:55] <elenril> merge with mplayer =p [16:04:14] <uau> merge how? throw svn out, replace with git contents? [16:04:21] <uau> if you can get reimar to agree i'm all for it :) [16:04:26] <elenril> pretty much. [16:04:47] <elenril> but it requires you being willing to cooperate and is therefore pure fantasy [16:04:50] <elenril> (and offtopic) [16:05:09] <mru> elenril: let's be civil, shall we? [16:05:15] <siretart> uau's mplayer (finally) has a name? cool [16:05:23] <BBB> I quickly glanced over "[PATCH 4/5] id3v2: split tables for various ID3v2 version", looks ok to me [16:05:27] <siretart> uau: is there some upstream homepage or something yet? [16:05:29] <uau> siretart: i think i mentioned "mplayer2" to you quite a while ago [16:05:38] <uau> siretart: should be pretty soon [16:05:50] <uau> but not at the moment [16:06:18] <siretart> if so, then I missed that note [16:06:22] <wm4> uau: will it be a full-blown fork then? [16:06:31] <mru> pitchfork [16:06:35] <elenril> great, now we have two ffmpegs and two mplayers [16:06:41] <uau> elenril: when the topic comes up you always seem to concentrate on me being "unwilling to cooperate" [16:06:55] <mru> both of you, stop it [16:07:04] <mru> if you want to fight, do it outside [16:07:18] <uau> mru: not a fight [16:07:40] <elenril> yeah, i'm actually siding with uau's fork [16:07:43] * elenril shuts up now [16:08:00] <uau> elenril: i have posted "undiplomatic" stuff, but i don't think the way i've wanted to do development has been at all unreasonable [16:08:05] <mru> uau: I've argued with you many times, but now I think it's time to bury the hatchet [16:08:23] <BBB> uau: side with ffmpeg - it's the new and improved version of mplayer anyway :-p [16:08:26] <BBB> </troll> [16:09:17] <uau> elenril: you seem to think only "diplomacy" would be needed, but i think that's completely wrong - there are real disagreements with reimar about how to do development and what direction the project should take [16:09:26] <elenril> uau: only the way you present your views is unreasonable [16:09:30] <uau> that are not at any "personal conflict" level [16:09:48] <elenril> oh well, whatever [16:10:41] <uau> btw i think it's about time to start getting interested people on separate irc channels for mplayer2 [16:11:07] <lu_zero> uau: what would be your plan? [16:11:11] <uau> currently only #mplayer2 is registered (it's now open, the key has been removed); probably there will be a separate channel later [16:11:19] <elenril> anyone objects to ff_put_str returning number of bytes written? [16:11:20] <uau> separate development channel i mean [16:11:28] <lu_zero> mplayer2-dev? [16:11:29] <elenril> to make it consistent with ff_put_str16 [16:11:35] <BBB> mru: so how do you want to name ff_put_strz16le()? [16:12:16] <uau> lu_zero: plan regarding what? if you mean mplayer2 release, the website should hopefully be up pretty soon [16:12:39] <mru> _str16le() is fine with me [16:12:42] <uau> once it's tested working i'll release about current code as a beta, then a real release hopefully pretty soon [16:13:21] <BBB> elenril: can you rename it? otherwise the 1/6 is fine with me also [16:13:59] <BBB> elenril: and that's all comments I have [16:14:01] <BBB> rest looks ok [16:15:09] <royger> kshishkov: is there any parameter in MpegEncContext to know if the decoding that is taking place is the one before the encoding? I need to modify some I-frame DCT luminance blocks before they are encoded back to mpeg2 [16:16:30] * mru watches the octane build ffmpeg, slowly [16:20:35] <elenril> will i die a slow and painful death if i include avformat.h from avio.h? [16:20:44] <mru> probably [16:21:07] <mru> that pair has made my head spin on more than one occasion [16:21:12] <mru> what's the problem? [16:21:18] <mru> you need the version? [16:21:19] <elenril> i want to use FF_API_OLD_FOO [16:21:29] <mru> ok, lets fix that [16:21:31] <mru> properly [16:21:47] <mru> move the version macros to version.h and include that wherever needed [16:23:14] <elenril> isn't that autogenerated? [16:23:22] <mru> libavformat/version.h [16:23:34] <elenril> ah [16:23:54] <mru> curious compiler warning: "jumping out of a block containing VLAs" is not currently implemented [16:26:01] <uau> i registered #mplayer2-dev as the development channel [16:26:18] <uau> currently nothing like FFMPEG_VERSION is visible in installed headers right? [16:26:42] <elenril> lol, the I return the LIBAVFORMAT_VERSION_INT constant. You got * a fucking problem with that, douchebag? [16:26:45] <elenril> I return the LIBAVFORMAT_VERSION_INT constant. You got * a fucking problem with that, douchebag? [16:26:53] <elenril> oops [16:27:05] * av500 douches elenril [16:27:17] <elenril> i didn't it was still there [16:27:20] <jannau> version.h is probably too generic for a public header [16:27:31] <mru> it's libavformat/version.h [16:27:31] <uau> i'd like to print the ffmpeg version that mplayer2 was compiled against [16:27:31] <merbzt> we should change that [16:27:52] <jannau> uau: only the library versions [16:27:59] <mru> jannau: if people put $prefix/include/libavformat in their cpp search path they should blame themselves [16:28:01] <uau> (of course someone _could_ install different ffmpeg library headers from different versions, but i think that's not supported) [16:28:42] <mru> I don't think version.h is any worse than common.h [16:28:53] <mru> and we've never had anyone complain about that [16:28:54] <uau> mru: "$ ls include/libavformat" -> "avformat.h avio.h"? [16:29:26] <mru> uau: yes, those headers are currently installed there [16:29:30] <mru> I'm suggesting we add version.h [16:29:51] <uau> ok... the "it's" didn't sound like a suggestion to me [16:30:17] <mru> guess I got a bit ahead of myself there [16:34:31] <elenril> how nice, avio.h already uses tons of FF_API_* [16:34:48] <mru> elenril: yes, it's very ugly [16:34:54] <mru> but now we're going to fix that [16:36:50] * elenril wonders why does it keep recompiling mpegaudiodec [16:39:49] <mru> wbs, BBB: I'm getting errors about INET_ADDRSTRLEN undefined on IRIX [16:39:54] <mru> is there a missing check somewhere? [16:40:28] <elenril> #include "libavformat/id3v1.h" [16:40:30] <elenril> wait, what? [16:40:38] <elenril> in mpegaudiodec.c [16:40:49] <mru> wtf [16:41:41] <elenril> git blames ubitux [16:41:50] <elenril> and apparrently i committed it :) [16:43:04] <elenril> anyway, http://pastebin.com/SVx8XyHf [16:43:19] <mru> hmm, applehttp is built even with --disable-network [16:47:17] <elenril> err, the last entry isn't supposed to be there [16:47:35] <elenril> http://pastebin.com/s2qGeBtM [16:47:43] <ubitux> elenril: oh it broke something? [16:48:15] <elenril> ubitux: it added a dependency on libavformat [16:48:32] <ubitux> is it bad? [16:49:10] <mru> elenril: that won't work right [16:49:22] <mru> it will pick up the top-level version.h [16:49:32] <mru> #include "libavformat/version.h" [16:49:39] <mru> or think of another name [16:49:41] <elenril> compiled fine [16:50:22] <mru> doesn't matter [16:50:25] <uau> ubitux: i think it didn't break anything in this case as there was no runtime dependency [16:50:26] <mru> it could still compiler [16:50:27] <mru> -r [16:50:57] <mru> elenril: put a #error in that file and see if it still builds [16:51:09] <uau> ubitux: but including headers could be seen as somewhat unsafe, as if you use any _function_ from them that'd cause a runtime dependency between the libraries [16:51:32] <elenril> /libavformat/version.h:93:2: error: #error [16:52:06] <mru> hmm, that's odd [16:52:20] <uau> i think the compiler prefers loading "" includes from current directory [16:52:23] <uau> before search path [16:52:31] <mru> even before -I flags? [16:52:37] <elenril> maybe that depends on the compiler [16:52:42] <mru> it does depend on the compiler [16:52:47] <mru> so better to use the full path [16:52:55] <mru> that's unambiguous [16:53:05] <elenril> http://pastebin.com/yiUkX1AZ [16:53:37] <uau> is there some compiler that behaves differently? [16:53:53] <mru> it's explicitly unspecified in the spec [16:54:07] <mru> if there isn't a compiler today, there could be one tomorrow that does differently [16:54:21] <mru> and I'd rather not be the one to debug it [16:54:24] <uau> well the C spec says very little about includes in general, it doesn't even assume a directory-structured file system IIRC... [16:54:49] <ubitux> uau: ok [16:55:18] <ubitux> so what would be the correct fix? [16:55:41] <ubitux> it was just to get access to a macro definining a size [16:55:45] <elenril> you use just one macro from the header [16:55:50] <elenril> you could duplicate it [16:55:57] <mru> but why is it needed at all? [16:56:00] <ubitux> ok :/ [16:56:13] <mru> nobody should feed id3 data to the decoder [16:56:59] <mru> uau: yes, the C standard is rather open-ended on what the name means [16:57:08] <ubitux> well actually, i recently saw the decoder try to decode it anyway [16:57:09] <uau> the C spec says about "" includes "file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read #include <" [16:57:27] <elenril> ubitux: that's right, why don't you check for it in the demuxer? [16:57:33] <uau> that sounds like the additional paths for "" should come before the ones for <> (which -I affects) [16:57:45] <mru> that's implementation-defined [16:58:00] <mru> the implementation may choose to apply -I paths to "" as well [16:58:03] <ubitux> elenril: i thought it was more appropriate here but i don't remember why [16:58:16] <BBB> mru: may be a missing configure check for networking, unless that is outside CONFIG_NETWORK [16:58:22] <BBB> mru: what is CONFIG_NETWORK on that box' config.h? [16:58:22] <uau> mru: of course, but then it might choose to ignore any "libavformat/" prefix in search paths as well... [16:58:30] <ubitux> i'm home in a few hours i'll look again if you can wait :p [16:59:02] <mru> uau: we assume directories are recognised all over the place [16:59:17] <mru> and I've never heard som much as an ancient rumour about a compiler that didn't work like that [16:59:34] <mru> I just prefer being on the safe side [16:59:48] <uau> well have you actually heard of a compiler that'd prefer search path includes to local ones? [17:00:03] <uau> i think that'd cause practical problems [17:00:19] <mru> perhaps, but why tempt fate when it's so easy to avoid? [17:00:42] <mru> now I have to attend a conf call [17:05:26] <lu_zero> apple segmented mpegts should work out of fs not just network [17:05:37] <lu_zero> (or at least that's how I used it not long ago) [17:08:23] * elenril spams some more patches [17:10:30] <thresh> wow, configure now almost works on hpux [17:11:21] <BBB> oh so now we're going to remove all mentions of strz? :-p [17:11:45] <BBB> I don't have any opinion on that honestly, so fine with me - I bet you tomorrow someone will ask us to revert it [17:11:59] <BBB> also it's not publica (av_) api, so no reason to keep the old api [17:12:14] <BBB> elenril: ^^ [17:14:10] <elenril> BBB: it's not all mentions of strz, i just wanted it to be compatible with the _16 version [17:14:24] <BBB> ok [17:14:26] <elenril> i.e. so it'd return the number of bytes written [17:14:38] <elenril> and since i'm at it i might as well rename it [17:15:11] <elenril> now i can use the same code for writing both utf8 and utf16 [17:19:49] <lu_zero> nice =) [17:20:32] <BBB> elenril: ok, like I said, sounds good to me [17:20:55] <BBB> mru: you can queue that patch imo if you have time - also let's keep queueing stefano's work [17:21:06] <BBB> saste: let's keep compatible as much as possible fwiw [17:26:44] <lu_zero> those function are supposed to be private? [17:27:56] <BBB> they have no av_ prefix [17:28:20] <lu_zero> BBB: nor ff_ ^^; [17:28:33] <BBB> elenril is changing that :-p [17:29:03] <lu_zero> I'd consider them useful for external usage [17:29:13] <lu_zero> or I'm missing something? [17:29:25] <BBB> just like dsp is useful to the outside [17:29:28] <BBB> yet it is not public [17:31:25] <elenril> if someone asks for them to be public, they can be changed [17:31:36] <elenril> it's harder to change them back ;) [17:43:37] * elenril thinking about the possibilites opening with per-muxer options [17:45:31] <elenril> also anybody heard from aurel? [17:58:14] <lu_zero> BBB: the header is public and I'm afraid not everybody decided to pick it [17:58:20] <lu_zero> as private [17:59:57] <elenril> hmm, seems i broke --disable-everything --enable-demuxers=mp3 [18:03:03] <mru> fix it! [18:03:25] <elenril> i don't see what's wrong [18:09:21] <elenril> ah, it depends on --enable-parser=mpegaudio [18:09:47] <elenril> dependencies aren't enabled manually? [18:09:49] <mru> let's make it auto-select that [18:12:26] <mru> patch away [18:20:22] <elenril> hmm, there's a ff_put_string in lavc [18:20:50] <mru> that puts to different thing though [18:20:51] * elenril wonders if it does anything exciting [18:21:05] <elenril> PutBitContext, wtf is that [18:21:15] * elenril should learn to libavcodec sometime [18:31:39] * elenril sends another round of renaming patches [18:31:52] * _av500_ renames elenril [18:32:25] <elenril> [Freenode] ::: Nick av500 is already in use [18:32:28] <elenril> curses! [18:37:23] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rc2dd0e9eba ffmpeg/configure: [18:37:23] <CIA-29> ffmpeg: Make demuxers auto-select parsers they need [18:37:23] <CIA-29> ffmpeg: This makes configure --disable-everything --enable-demuxer=foo [18:37:23] <CIA-29> ffmpeg: work as expected. [18:37:23] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:37:27] <mru> elenril: sorry to be annoying, but perhaps prefixing that bunch of functions with avio_ would make sense [18:38:12] <elenril> could've said that earlier =p [18:38:21] <mru> I only thought of it now [18:38:57] <elenril> oh well, another round of rebasing [18:39:00] * elenril <3 rebasing [18:40:17] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r7aa571113f ffmpeg/libavformat/ (id3v2.c id3v2.h): (log message trimmed) [18:40:17] <CIA-29> ffmpeg: id3v2: use an enum for encodings instead of magic numbers. [18:40:17] <CIA-29> ffmpeg: On Fri, Jan 21, 2011 at 02:35:41PM +0000, Måns Rullgård wrote: [18:40:17] <CIA-29> ffmpeg: > Anton Khirnov <anton(a)khirnov.net> writes: [18:40:17] <CIA-29> ffmpeg: > [18:40:17] <CIA-29> ffmpeg: > > --- [18:40:18] <CIA-29> ffmpeg: > > libavformat/id3v2.c | 10 +++++----- [18:40:33] <mru> fuck [18:40:45] <elenril> haha [18:40:51] <BBB> hahaha :) [18:41:12] <Zor> rebase is the swiss knife of distributed source control [18:41:23] <elenril> rewriting history is evil! [18:41:28] <Zor> liessss [18:41:29] <elenril> it hides embarassing mistakes [18:42:50] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rd66eff3685 ffmpeg/libavformat/ (id3v2.c id3v2.h): [18:42:51] <CIA-29> ffmpeg: id3v2: use an enum for encodings instead of magic numbers. [18:42:51] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:42:54] <mru> terribly sorry about that [18:43:03] <mru> I took the liberty to fix it within 30s [18:44:20] <mru> I accidentally piped the entire mail instead of the attachment to git am [18:47:51] <elenril> damn, wrong thread [18:48:22] * elenril wishes mutt had some integration with git [18:48:52] <thresh> http://img-fotki.yandex.ru/get/5003/strangestone.41/0_45160_5aec452b_orig -- check out the icons on the screen ;p [18:50:31] <BBB> thresh: vlc? [18:50:46] * mru sends thresh to #videolan [18:50:56] <thresh> BBB: yeah [18:51:06] <thresh> mru: well, it means FFMpeg is there too [18:51:20] <BBB> the icon of vlc is not based on ffmpeg :-p [18:51:29] <mru> there's no zigzag icon [18:51:35] <BBB> mru: you can queue elenril's 1/6 rename ff_put_str16bla also [18:51:58] <mru> maybe that should be public too [18:51:58] <wbs> mru: applehttp doesn't depend on config_network, you could just as well play a .m3u8 with its .ts files from a local directory [18:52:05] <elenril> i made them all public [18:52:10] <mru> wbs: oh [18:52:13] <elenril> compiling now, will send in a sec [18:52:15] <kshishkov> mru: make them repaint cone into green stripes first ;) [18:52:17] <mru> wbs: http sounded rather networky [18:52:36] <wbs> mru: and regarding INET_ADDRSTRLEN, don't think it requires any configure check, you could add an #ifndef INET_ADDRSTRLEN #define INET_ADDRSTRLEN 50 or similar in network.h [18:52:56] <wbs> mru: yeah, it sounds kinda networky, but I didn't come up with any better name [18:53:03] <mru> it whinged about other things too [18:53:13] <mru> maybe I'll figure it out some day if I'm bored [18:53:17] <wbs> ok [18:53:19] <mru> who cares about irix anyway [18:53:40] <lu_zero> saste: could you check a line using -pix_fmt to output raw frames? [18:54:01] <lu_zero> during this month apparently it broke [18:54:24] <thresh> damn, adding a -D to fix one error in HPUX ffmpeg compile results in broken struct checks [18:54:27] <lu_zero> [buffer @ 0x978f50] Invalid pixel format string '-1' [18:55:04] <lu_zero> ffmpeg -i sample -vcodec rawvideo -pix_fmt uyvy422 -acodec pcm_s16le -ar 48000 -f nut out.nut [18:55:10] <lu_zero> this now breaks [18:55:34] <mru> hpux... thresh must have been a very naughty boy to receive such punishment [18:55:58] <wbs> or perhaps he likes kinky stuff [18:56:08] <pJok> masochism [18:56:18] <saste> lu_zero: what does "sample" contains? [18:56:33] <lu_zero> let me check if it is specific [18:56:33] <saste> lu_zero: looks like the pixel format is not recognized [18:57:36] <thresh> mru: no, i'm just a loser who doesnt have anything better to do on Friday night [18:58:20] <lu_zero> saste: that's what puzzles me since I have a version that works fine with it [18:58:24] * elenril wonder if he'll EVER do this patch right [18:59:50] <saste> saste: works here with a flv file [19:00:07] <elenril> anyone minds if i just resend the whole patchset? [19:00:07] <saste> lu_zero: works here with a flv file [19:00:20] <elenril> replying to single mails is effort [19:00:21] <lu_zero> saste: it is broken here on an rtmp stream [19:00:48] <lu_zero> s/rtmp/http+mpegts [19:01:08] <saste> lu_zero: post the command on pastebin [19:02:02] <saste> saste: then sure a check should be added to ffmpeg.c [19:02:28] <elenril> mru: one of the patches has a typo in it, don't apply them [19:02:37] <saste> lu_zero: then sure a check should be added to ffmpeg.c [19:02:42] <mru> elenril: ok, won't [19:02:51] <elenril> i'll dump the whole branch again [19:04:44] <lu_zero> looks unrelated in the end [19:10:00] <ubitux> is there a MK(BE)TAG24? [19:10:15] <ubitux> or doing it manually is the correct thing? [19:10:36] <mru> you could use 32 with a 0 [19:10:37] <elenril> use MK**TAG32 with a 0 [19:11:03] <ubitux> ok [19:11:08] <ubitux> thanks [19:11:30] <ubitux> i'm looking for moving the tag hack, i'll send a patch asap [19:11:39] <ubitux> (id3 tag) [19:13:45] <elenril> ok, i really hope i did it all right this time [19:18:32] <BBB> mru: when you say "this", in the sentence "this does", in a patch that only removes a line, what should I imagine it doing? [19:18:55] <mru> the change does [19:25:18] <BBB> it's a removal :-p I don't understand configure enough [19:25:23] <BBB> will leave to diego to review [19:25:49] <mru> stuff after patch compared to stuff before patch [19:34:56] <mru> anyone here set up to build for iphone? [19:35:10] * wbs [19:35:30] <mru> wbs: please test this patch: http://git.mansr.com/?p=ffmpeg;a=commitdiff;h=9f490b2 [19:35:41] <mru> make sure the struct offsets are correct [19:35:56] <mru> I made a guess, but it could be wrong [19:50:54] <_av500_> mru: cant we do the sub struct thing at least? [19:51:11] <mru> of course we can [19:51:22] <mru> but I don't want to hold up ruggles' patch waiting for that [19:51:26] <_av500_> ok [19:54:19] <mru> hmm, michael just imported a swath of commits from ffmpeg.org [19:55:12] * elenril just saw it too [19:55:23] <elenril> seems he didn't like me splitting mp3.c [19:55:40] <Dark_Shikari> mru: someone make a bunch of commits that conflict wildly with his [19:55:51] <elenril> how not nice [19:55:56] <mru> I have few nice ones that he rejected in the past [19:55:57] <elenril> we want to cooperate, don't we =p [19:56:04] <Dark_Shikari> elenril: he's pushing a fork, that's not cooperation [19:56:08] <mru> general cleanup stuff [19:56:20] <mru> I think I'll resend some of that [19:56:34] <elenril> Dark_Shikari: he's still around and working on ffmpeg => we can merge his code [19:57:01] <mru> did he skip any? [19:57:42] <ubitux> is it ok to check for id3v1 tag in the demuxer read_packet function? [19:57:51] <wbs> mru: compiles fine for iphone [19:57:59] <ubitux> (the tag is expected at the end of the file) [19:58:15] <mru> wbs: cool, then I'll push the patches [19:58:19] <elenril> ubitux: where else would you want to check [19:58:46] <ubitux> elenril: i don't know, i'm asking :) [19:59:10] * elenril can't think of any other place inside lavf [19:59:11] <_av500_> er, but then you have the tag only at the end, no? [19:59:26] <_av500_> need to listen to all the song to have it? [19:59:41] <ubitux> seems yes [19:59:49] <ubitux> but there is id3v2 most of the time [19:59:55] <ubitux> and actually there is a strange thing [20:00:00] <mru> btw, the bsd boxes are back on fate \o/ [20:00:06] <ubitux> mp3_read_header looks for a id3v1 tag [20:00:08] <_av500_> there is still a ton of v1 out there [20:00:13] <ubitux> but it should nevre find one [20:00:18] <_av500_> think asia [20:00:19] * mru still ponders setting up something bizarre on that old quad-core [20:00:27] <_av500_> mru: hurd [20:00:33] <kierank> DOS [20:00:37] <_av500_> minix3! [20:00:54] <mru> kierank: we have dos already covered [20:00:56] <elenril> lu_zero: i think avio.h has been public since stone age [20:00:56] <ubitux> maybe the mp3_read_header should seek at the end of the file and try to read the id3 tag? [20:01:01] <kierank> mru: yeah but dos on a quad core [20:01:08] <elenril> ubitux: it already does that, no? [20:01:09] <kierank> overkill ftw [20:01:13] <ubitux> and also try to skip it when expecting it in mp3_read_packet? [20:01:29] <thresh> mru: plan9 [20:01:34] <ubitux> elenril: seems not no; i don't think it seeks to the end of the file [20:01:35] <mru> thresh: unpossible [20:01:36] <thresh> if you're that insane [20:01:39] <mru> plan9 sucks too much [20:01:48] <mru> they don't even have a C compiler [20:01:49] <elenril> ubitux: see ff_id3v1_read() [20:01:59] <thresh> *cough*beos*cough* [20:02:00] <elenril> it's only called if there's no v2 tag [20:02:05] <mru> their version of C doesn't support #if FOO [20:02:15] <mru> because they think that's unnecessary [20:02:30] <thresh> hpux is soooo broken :( [20:02:34] <ubitux> elenril: i missed the fact it seek to the end of the file, but ok [20:02:39] <mru> I might try haiku [20:02:40] <thresh> both gcc and their cc [20:02:48] <mru> last time I tried it the installer crashed [20:02:48] <ubitux> well so it only need to ignore the tag in mp3_read_packet [20:03:03] <elenril> yes [20:03:03] <mru> thresh: gcc on plan9 is very much a second-rate citizen [20:03:11] <BBB> shit [20:03:13] <BBB> mingw is gone [20:03:17] <BBB> where is ramiro? [20:03:44] <elenril> what do you mean, 'gone' [20:04:35] <mru> the mingw slots were last updated jan 20 3am with michael's non-building tree [20:04:44] <mru> I've hidden them from the front page [20:05:05] <thresh> you need some protection from malicious forks [20:05:10] <mru> eg http://fate.ffmpeg.org/i686-w64-mingw32-gcc-4.4/latest [20:05:17] <BBB> hm [20:05:29] <mru> thresh: I've been considering options [20:05:30] <elenril> michael's tree doesn't build? [20:06:22] <mru> apparently not [20:06:22] <mru> I find that funny [20:06:22] <thresh> although I have no idea how to do that as I never touched fate myself [20:06:23] * elenril finds that sad [20:06:23] <mru> I can always revoke the keys from anyone who misbehaves [20:06:32] <Dark_Shikari> mru: wait, you're not FATEing michael? [20:06:37] <Dark_Shikari> Now that's potentially evil [20:07:07] <mru> I fate ffmpeg.org [20:07:25] <Dark_Shikari> Yeah, it makes sense -- it just means michael might not be used to working without fate [20:07:40] <mru> I think it's failing only out-of-tree builds [20:07:44] <mru> like fate always does [20:09:12] <BBB> b/c of libmpcodecs? [20:10:43] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r50196a982b ffmpeg/libavformat/ (Makefile avformat.h avio.h version.h): [20:10:43] <CIA-29> ffmpeg: lavf: move the version macros to a new header [20:10:43] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:10:46] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r56f8952b25 ffmpeg/libavcodec/ (12 files in 3 dirs): [20:10:46] <CIA-29> ffmpeg: Move lpc_compute_autocorr() from DSPContext to a new struct LPCContext. [20:10:46] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:10:52] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r1c189fc533 ffmpeg/libavcodec/ (lpc.c x86/lpc_mmx.c): [20:10:52] <CIA-29> ffmpeg: cosmetics related to LPC changes. [20:10:52] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:11:09] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r77a78e9bdc ffmpeg/libavcodec/ (alacenc.c flacenc.c lpc.c lpc.h ra144enc.c x86/lpc_mmx.c): [20:11:09] <CIA-29> ffmpeg: Separate window function from autocorrelation. [20:11:09] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:11:32] <BBB> elenril: in order to be future-compliant, shouldn't we convert id3v2.3 tags anyway, even if none are converted right now? [20:11:38] <BBB> maybe we'll convert 1 or 2 to generic names in the future [20:12:45] <elenril> i don't see how adding a noop now is better than adding function call later [20:13:35] <BBB> I guess... [20:13:47] * BBB thinks elenril's got balls today and wants to kick ass [20:13:56] <BBB> mru: you can queue that one too then [20:14:13] * elenril is supposed to be studying QFT [20:14:59] <BBB> I see you've been studying very hard [20:15:01] <BBB> :-p [20:15:31] <elenril> =p [20:16:04] <elenril> still better than idly procrastinating [20:16:08] <mru> BBB: which one? [20:16:24] <elenril> when i'm not under pressure i waste time playing minesweeper or worse ;) [20:16:42] <mru> watching minesweeper porn? [20:17:12] <BBB> mru: at least the split tables and the one adding the muxer option for id3v2.3 tag writing [20:17:27] <BBB> 1/6 rename ff_str16_nolen is fine also [20:17:29] <BBB> (1/6) [20:17:44] <BBB> 2/6 is fine also (rename put_str()) [20:20:39] <mru> BBB: ff_str16_nolen looks like 3/6 to me [20:20:48] <mru> or am I looking at the wrong patch set? [20:21:23] <BBB> oh yeah gmail bug [20:21:29] <BBB> it shows the title of the original message [20:21:30] <BBB> it's 3/6 [20:21:46] <elenril> wait, gmail groups my mails by subject? [20:21:48] <elenril> lol [20:21:53] <mru> lame [20:21:56] <BBB> anssi's patches for profile are ok also [20:22:03] <BBB> I didn't typocheck them [20:22:45] <BBB> I wanted to look into reimar's patches also and cleanup that stuff some more maybe [20:22:53] <BBB> but then again there's also the h264 regression on roundup [20:23:40] <mru> 5/6 won't apply w/o 4/6 [20:27:21] <mru> btw, if anyone wonder what I have queued, see http://git.mansr.com/?p=ffmpeg;a=shortlog;h=master;hp=origin/master [20:31:00] <BBB> 4/6 I'm still reviewing [20:31:52] <elenril> you people and your error-checking =p [20:31:53] <mru> I don't see anything immediately wrong with it [20:31:53] <elenril> makes my nice short code longer [20:31:53] <BBB> mru: I sent a reply already [20:31:53] <BBB> av_freep(&hx->rbsp_buffer[1]); [20:31:53] <BBB> av_freep(&hx->rbsp_buffer[0]); [20:31:53] <BBB> hx->rbsp_buffer_size[0] = 0; [20:31:53] <BBB> hx->rbsp_buffer_size[1] = 0; [20:31:53] <BBB> why is that code there? [20:31:53] <BBB> (h264.c) [20:32:00] <mru> to free some buffers I presume [20:32:26] <BBB> apparently that causes some invalid reads later on [20:35:14] <BBB> I think the decoding is still running while that code runs... [20:35:32] <mru> mt? [20:35:45] <BBB> no, baseline svn [20:35:48] <BBB> er, git [20:35:53] <BBB> git head, or git trunk [20:35:55] <BBB> git master? [20:36:12] <mru> how can something "still" be doing something while something else is doing anything? [20:36:16] <mru> if it's single-threaded [20:36:48] <BBB> free_tables() does this: [20:36:54] <BBB> for(i = 0; i < MAX_THREADS; i++) { [20:36:54] <BBB> hx = h->thread_context[i]; [20:36:59] <BBB> ... free thread info ... [20:37:01] <BBB> } [20:37:04] <mru> BBB: I have reviewed your review [20:37:06] <BBB> so I think that it's already threaded [20:38:01] <_av500_> elenril: u still need that win7 test? [20:38:14] <mru> BBB: h264 is not threaded [20:38:39] <BBB> I then have no idea what this code does [20:38:41] <mru> or does it have slice threading? [20:39:07] <elenril> _av500_: nah, JEEB was faster than you [20:39:17] <_av500_> k [20:39:20] <BBB> mru: probably slice threading [20:39:37] <_av500_> only got that win7 tablet running now... [20:39:52] <_av500_> had to guess the password... [20:40:00] <mru> admin? [20:40:07] <_av500_> Test [20:40:13] <kierank> hunter2 [20:40:18] <mru> swordfish [20:40:30] <_av500_> note the tricky capital T [20:40:46] * mru did [20:40:50] <mru> cunning [20:42:21] <uau> h264 does have slice threading [20:42:44] <uau> though it gets disabled for most videos as they're not encoded with independent slices [20:43:02] <elenril> arrrgh [20:43:11] * elenril rebuilding libavcodec for the 157th time [20:43:26] <kierank> at least you're not building on windows [20:43:35] <mru> siretart: ping [20:44:18] <spaam> elenril: i hope you are using ccache ;) [20:44:31] <ubitux> elenril: are you sure the demuxer is actually the good place? i mean, mp3_read_packet is not called at the top of the frame, so well i don't have the tag immediately unless i'm missing something [20:44:43] <mru> spaam: I'm not using ccache [20:45:03] <ubitux> mmh, maybe by checking the end of the packet. [20:45:45] <spaam> mru: i now you have a good computer with --omg-optimized stuff.. elenril are just elenril ... using windows7.. [20:47:24] <elenril> this is so obvious it's even beneath stabbing or a tvtropes attack [20:49:13] <spaam> hmm? [20:51:51] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rdccbd97d72 ffmpeg/libavformat/ (asf.c asf.h asfenc.c avio.h aviobuf.c mmst.c): [20:51:51] <CIA-29> ffmpeg: lavf: move ff_put_str16_nolen from asf to avio and rename it [20:51:51] <CIA-29> ffmpeg: It will be useful in the mp3 muxer. [20:51:51] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:51:54] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r4efd5cf34b ffmpeg/libavformat/ (avienc.c avio.h aviobuf.c ffmenc.c version.h): [20:51:54] <CIA-29> ffmpeg: avio: add av_put_str and deprecate put_strz in favor of it [20:51:54] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:51:56] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r93bb9ff08e ffmpeg/configure: [20:51:56] <CIA-29> ffmpeg: configure: simplify exit traps [20:51:56] <CIA-29> ffmpeg: This does the same thing and also fixes the trapping in [20:51:56] <CIA-29> ffmpeg: some (possibly broken) shells. [20:51:56] <CIA-29> ffmpeg: Suggested by Michael Kostylev. [20:51:57] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:54:25] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * ra210bce298 ffmpeg/configure: [20:54:25] <CIA-29> ffmpeg: configure: better test for mktemp [20:54:25] <CIA-29> ffmpeg: Some variants of mktemp require a template, so provide one when [20:54:25] <CIA-29> ffmpeg: checking for the command. We already supply a template in the [20:54:25] <CIA-29> ffmpeg: subsequent uses of mktemp. [20:54:26] <CIA-29> ffmpeg: Thanks to Michael Kostylev. [20:54:27] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:56:35] <elenril> i wonder if a minor bump or something is in place [20:58:03] <ubitux> uint32_t v = AV_RB32(buf) & 0xffffff00; ← any better solution than this? [20:59:07] <ubitux> mmh, found a workaround, forget this. [20:59:39] <mru> AV_RB24()? [21:00:49] <jannau> http://patchwork.libav.org/project/ffmpeg/list/?order=date [21:00:55] <ubitux> mru: yes but changing the MKBETAG used to compare to [21:01:04] <ubitux> too [21:01:21] <ubitux> MKBETAG(0, 'T', 'A', 'G') instead of MKBETAG('T', 'A', 'G', 0) [21:02:06] <jannau> currently not really useful since post-commit magic purging patches is missing [21:02:10] <ubitux> http://pastie.org/1485445 ← does this look good to you elenril? [21:04:05] <mru> jannau: cool [21:04:18] <mru> are you planning on adding purging? [21:04:38] <mru> and can you have it strip the ffmpeg-devel tag? [21:04:51] <mru> having that on all of them just makes it harder to read [21:06:08] <jannau> yes, currently working on the purging [21:07:34] <ubitux> (should i send the patch on ffmpeg-devel?) [21:07:49] <elenril> ubitux: does it work? ;) [21:07:57] <ubitux> elenril: yes it seems [21:08:06] <ubitux> is it surprising? [21:08:35] <elenril> somewhat [21:08:53] <elenril> anyway, i'm not the best person to review it, i'm not very familiar with decoding magic [21:09:25] <ubitux> ok i'm going to send it to ffmpeg-devel [21:09:25] <mru> if you're not so good with magic you should get a spell checker [21:22:07] <jannau> mru: http://patchwork.libav.org/project/FFmpeg-devel/list/ [21:23:13] <mru> how often does it purge committed patches? [21:27:54] <jannau> I'm installing a post-update hook for it [21:28:09] <mru> installing where? [21:30:37] <mru> ouch, we messed up [21:32:00] <jannau> on the patchwork server, which will be set up to mirror git.ffmpeg.org [21:32:10] <mru> ah [21:32:29] <mru> and how will that mirroring be triggered? [21:33:13] <jannau> I was hoping by post-update hook on git.ffmpeg.org [21:33:22] <mru> sure [21:33:58] <jannau> but let me first check if it works [21:35:36] <mru> something works [21:35:44] <mru> it picked up the patch I just sent [21:36:02] <mru> how are multiple patch revisions handled? [21:36:08] <mru> like elenril's recent adventures? [21:36:25] <mru> by title? [21:46:11] <BBB> mru: latest 4/6 is ok with me [21:51:51] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r4ad66441c9 ffmpeg/configure: [21:51:51] <CIA-29> ffmpeg: Fix libavformat version extraction in configure [21:51:51] <CIA-29> ffmpeg: This fixes shared library builds broken by [21:51:51] <CIA-29> ffmpeg: 50196a982bf7c8be9b41053fa0975473c217e709 [21:51:51] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:51:54] * mru needs to figure out a way to do 1-click commit from patchwork [21:52:27] <BBB> whatever you do now is quite good - your patchapplyspeed is amazing [21:52:31] <BBB> for me it takes minutes per patch [21:53:15] <mru> that's because I use a proper mail reader [21:53:28] <mru> I can send a patch to git with a couple of keystrokes [22:18:23] <spaam> BBB: you now.. mru are running gentoo in his emacs os.. super fast. [22:18:31] <spaam> s/now/know [22:21:09] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r187e23478b ffmpeg/libavformat/mp3enc.c: [22:21:09] <CIA-29> ffmpeg: mp3enc: add support for writing UTF-16 tags [22:21:09] <CIA-29> ffmpeg: Also it gets rid of some mysterious magic numbers in code. [22:21:09] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [22:21:24] <CIA-29> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r8f4a5d225c ffmpeg/libavcodec/dca.c: (log message trimmed) [22:21:24] <CIA-29> ffmpeg: dca: consider a stream with XXCh/X96 in ExSS as DTS-HD HRA [22:21:24] <CIA-29> ffmpeg: DTS-HD HRA streams do not always have an XBR extension in the extension [22:21:24] <CIA-29> ffmpeg: substream. Instead they can have only XXCh and X96 extensions in [22:21:25] <CIA-29> ffmpeg: there and still be considered DTS-HD HRA. [22:21:25] <CIA-29> ffmpeg: This is also confirmed with Onkyo TX-SR607 receiver which recognizes [22:21:26] <CIA-29> ffmpeg: such a stream as HiRes Audio. [22:31:19] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r69915b48d6 ffmpeg/libavcodec/ (iirfilter.c iirfilter.h): [22:31:19] <CIA-29> ffmpeg: iir: Change dst param to float* in ff_iir_filter_flt(). [22:31:19] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [22:34:46] <astrange> BBB: are you using mail.app? [22:35:15] <mmu> Mail.app suxor [22:35:37] <mmu> OSX suxor anyway, I really need to change [22:36:13] <mru> mmu: I thought you ran beos [22:37:04] <mmu> on this machine [22:37:12] <mmu> and Haiku [22:37:15] <mmu> but I got a mac last year [22:37:27] <mmu> was kinda forced into it [22:37:35] <lotharkript> [22:37:35] <lotharkript> dw [22:37:35] <lotharkript> aqw [22:37:35] <lotharkript> daqw [22:37:39] <mmu> been finding a bug a day in OSX since then [22:37:50] <mmu> now I know my ennemy, I can switch back :) [22:38:53] <astrange> it changes faster than haiku, the release rate is just less [22:39:09] <mru> why would anyone decide to get a mac? [22:39:22] <mmu> it was beyond me before [22:39:26] <mmu> now it's even further [22:39:35] <mru> apple fans don't make that decision, the steve does [22:39:45] <mmu> well, some things do work fine [22:39:46] <mmu> like suspend [22:40:02] <mru> I care more about how well my computer works when it's running [22:40:04] <mmu> but there are so many unfinished things [22:40:14] <mru> and my sony suspends just fine [22:40:23] <mmu> well yeah but it allows you to keep Safari or Firefox running for months [22:40:37] <mmu> until you have to kill them because they eat 3GB of RAM [22:40:46] <mru> I was getting to that part [22:41:37] <mmu> what is even nastier is OSX allocates by default as much swap as needed [22:42:11] <mmu> so sometimes you see a popup telling "Oh, I don't have enough disk space for swap, I stopped Firefox and Safari, free up some space, and click to resume them" [22:42:17] <astrange> no it doesn't [22:42:17] <mmu> supposedly they got SIGSTOP [22:42:25] <astrange> swapfiles are dynamic in /var/vm [22:42:30] <mmu> which is nice, but their popup doesn't work usually [22:42:37] <astrange> did you make a really small boot partition? [22:42:43] <mmu> so you have to send them SIGCONT manually [22:43:12] <mru> one of the things I truly detest about macos is the global menubar [22:43:19] <mmu> first thing I did was split the disk to have a 100Go with case sensitive HFS for real work [22:43:33] <mru> even for a small window near the bottom of the screen, one has to mouse all the way to the top to do anything [22:43:37] <mmu> but yeah the boot partition sometimes get filled with video recordings [22:43:42] <mru> and that makes focus-follows-mouse useless too [22:44:10] <astrange> if you configure it in a way nobody else does you will run into problems nobody else runs into [22:44:12] <mmu> another thing, for a BeOS user used to 32 workspaces that do work... their Spaces thing is totally buggy [22:44:18] <astrange> symlink /var/vm to a larger partition might work [22:44:23] <mmu> it's clearly an afterthought [22:44:32] <mru> 32 seems plenty indeed [22:44:45] * mru has 6 on each of 2 monitors [22:44:47] <mmu> that's the max as it's a bitmask [22:44:51] <mru> independently switchable [22:44:57] <mmu> windows can be on more than 1 [22:45:05] <mru> same here [22:45:19] <mmu> it's actually virtual desktops, screens are handled by BScreen class, though BeOs never supported more than 1 [22:46:01] <mmu> in OSX, pressing the hotkey for changing Space rapidly will make it go nuts for several seconds due to the useless animation [22:46:17] <mmu> then when you get back it's another window that has the focus [22:46:29] <mmu> sometimes even one you don't see cause it's the one under all otehrs [22:47:34] <mmu_man> wget(64427) malloc: *** error for object 0x101f8b970: pointer being freed was not allocated [22:47:37] <mmu_man> *** set a breakpoint in malloc_error_break to debug [22:47:49] <mmu_man> hmm wget -m on a 600MB website... [22:47:49] <mru> valgrind [22:48:00] <mmu_man> I don't think there is a port to OSX [22:48:11] <mmu_man> seems it got a 404 right before [22:48:12] <mmu_man> oh well [22:50:53] <astrange> valgrind 3.6 works on os x [22:50:57] <astrange> (current release) [22:54:55] <mmu_man> ah good to know [22:55:09] <mmu_man> should try porting it to Haiku someday [22:55:14] <mmu_man> I think Ingo wrote a similar tool [22:55:20] <mru> can't be terribly hard [22:55:23] <mmu_man> he actually wrote his own full GUI debugger [22:55:31] <mmu_man> he probably didn't like gdb [22:55:53] <mru> can't blame him [22:55:55] <mmu_man> but then he puts C++ in the kernel almost each commit too, so... >:-) [22:56:05] <mru> can blame him [22:59:32] <jannau> grrr! web stuff. I can't get the auth working for the patchwork xmlrpc stuff which is required to update patches [23:01:21] <jannau> mru: http://wiki.openembedded.net/index.php/Patchwork has a script to feed patches from patchwork to git am [23:01:43] <merbanan> this patchwork thingy [23:01:50] <mru> what sort of script? [23:02:07] <merbanan> is there some keyword one can say that will mark a sent patchs as oked ? [23:02:25] <mru> jannau: I don't need that [23:02:27] <jannau> shell,perl,python, whatever. that's probably easier than clicking [23:02:42] <mru> I want a way to click the mbox link in firefox and have it fed to a script of my choosing [23:03:07] <mru> which is possible with the somewhat unreliable "open with" option [23:03:21] <mru> it has the habit of reverting back to save or switching apps randomly [23:03:54] <jannau> custom mime type, x-patchwork/x-project [23:04:30] <mru> that's something the server would have to do [23:05:18] <jannau> sure, it shouldn't be a huge problem to add that [23:16:53] <CIA-29> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * rf4096bf6ee ffmpeg/libavcodec/dca.c: [23:16:53] <CIA-29> ffmpeg: dca: add profile names [23:16:53] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:22:08] <jannau> updating patches works, not sure if from git hook [23:22:52] <mru> there should be a ping button that sends a ping to the ml [23:23:57] <jannau> if someone has a patch queued it would be help if itcan be pushed [23:25:37] <mru> as soon as some more get approved... [23:25:47] <_av500_> mru: and a nitpick button? [23:26:21] <mru> _av500_: send mail with randomly inserted comments like "alignment", "alphabetical order"? [23:26:35] <_av500_> yeah [23:27:02] <_av500_> btw, can smb review my flv review? [23:27:46] <jannau> flvtool2 indices one, I didn't since I had more nitpicks [23:27:52] <jannau> +the [23:28:40] <_av500_> ? [23:28:47] <_av500_> yes this one [23:30:51] <_av500_> how its done looks way more complicated compared to what my stuff does [23:30:59] <_av500_> but thats due to the overrecusrivesness [23:41:59] <mru> send more email, we've falled to #9 on gmane top 10 [23:42:03] <mru> *fallen [23:43:11] <jannau> patchwork missed the updated patch for http://patchwork.libav.org/patch/171/ [23:46:24] <jannau> _av500_: he seems to like long lines, defines and variable names

1 0

IRC log for 2011-01-20
by irc＠mansr.com 21 Jan '11

21 Jan '11

[00:08:20] <DonDiego> saste: we know that especially the timing was less than perfect [00:14:26] <saste> DonDiego: but the main problem was not the timing but the fact that it was done like a conspiracy and with an overtake [00:14:40] <saste> DonDiego: i'm not convinced that there was no way to do it in a different manner [00:15:08] <saste> and I'm not convinced that this is going to save flamewars [00:15:17] <saste> i can't just see the "hurry" [00:15:37] <DonDiego> understandable [00:15:44] <BBB> it wasn't exactly done in a hurry from our point of view [00:15:53] <DonDiego> but i did not use that image of a "tidal wave" for nothing [00:16:07] <DonDiego> this has been brewing for months actually [00:16:22] <DonDiego> people have been disgruntled for a loooong time [00:16:38] <DonDiego> it came to a boil with the mans incident [00:16:48] <saste> i know... yes the problem is that that disgruntling wasn't manifest [00:16:51] <DonDiego> and the failed attempt to make amends afterwards [00:17:00] <saste> that was a decision of mans [00:17:07] <saste> mans was always welcome [00:17:18] <DonDiego> not by michael [00:17:28] <saste> michael can't ban anyone [00:17:33] <DonDiego> no? [00:17:40] <saste> no [00:17:55] <saste> and a leader can be changed [00:18:03] <DonDiego> this has just happened [00:18:08] <saste> or the leadership system can be changed [00:18:15] <DonDiego> check [00:18:39] <DonDiego> the way this was done, hmmm... [00:18:58] <DonDiego> there surely is room for improvement [00:19:04] <saste> do you perceive the problem of "legitimation"? [00:19:08] <DonDiego> yes [00:19:33] <saste> you say that a vote is not a solution but was the problem [00:19:56] <DonDiego> i also perceive the problem of lack of empathy with michael's situation [00:20:00] <saste> i want to know why it is not a solution and if you think that there is a better way to "solve" this problem [00:20:20] <saste> i'm open to other solutions [00:20:20] <DonDiego> was the disgruntlement really not noticeable? [00:20:35] <DonDiego> with people leaving or dropping involvement massively? [00:21:17] <BBB> saste: because a vote will leave half of the voters, the half whose side was not chosen, unhappy [00:21:33] <DonDiego> we obviously made some mistakes in our outside communication [00:21:54] <DonDiego> the motives of our actions and our plans are/were obviously less than clear [00:21:55] <BBB> saste: say we do a vote, and given how many people signed off on our initial email, I suppose we would win. the vote would say "let's do things differently"... how would that make people like you less unhappy? [00:22:01] <BBB> saste: the end situation is identical [00:22:11] <BBB> saste: likewise if the vote turned out the other way [00:22:21] <BBB> saste: we would be unhappy developers as now, drop our involvement and walk away [00:22:35] <saste> i don't think everybody has to be happy for the result of a vote [00:22:36] <BBB> in a vote, everyone loses [00:22:42] <saste> i'm not happy now [00:22:46] <saste> and no vote was cast [00:22:52] <DonDiego> we were not happy before [00:23:04] <DonDiego> so we forked [00:23:09] <bryno> "our way or the highway" on both sides [00:23:52] <Compn> so thats why no messages for 40 mins... [00:23:53] <DonDiego> saying that a vote leaves devs unhappy does not mean that there is no friction loss with other ways to go about this [00:24:15] <iive> DonDiego: you didn't fork, you took over. [00:24:27] <bryno> what happens to the maintainers who sided with michael previously? [00:24:54] <bryno> now they are disgruntled and mass leaving? :( [00:25:18] <DonDiego> it is sad to come into such a situation in the first place [00:25:21] <DonDiego> yes [00:25:30] <Compn> iive : DonDiego /ignored you a while back methinks [00:25:54] <Compn> just fyi... [00:25:56] <bryno> what has fabrice's opinion been on this? [00:26:13] <Compn> havent seen fabrice in years :P [00:26:13] <DonDiego> but any which way you go about such a thing, there will always be some bitterness and friction loss [00:26:17] <DonDiego> :-( [00:26:35] <DonDiego> Compn: psshht, don't tell the troll [00:26:47] <bryno> troll? [00:27:04] <saste> i have no problem at accepting a govern for which I didn't vote and which i dislike at most [00:27:10] <DonDiego> bryno: we have a household troll in this channel, his nick is iive ... [00:27:13] <saste> indeed this is what I did in the last ten years [00:27:20] <DonDiego> :) [00:27:23] <bryno> ok. [00:27:56] <DonDiego> saste: nobody is imposing a government on you nor on anybody else [00:28:21] <saste> i'm aware of it [00:28:39] <bryno> out of curiosity, how was michael put into the leadership position in the first place? [00:28:54] <saste> i still want to believe that we can still have just one ffmpeg... and the split can be fixed in an acceptable way [00:29:01] <Compn> DonDiego : i think some people are upset that the git.videolan is not accessible on the download page of ffmpeg.org . i know someone said they were going to publish all forks, so maybe its included in that list ? [00:29:06] <mru> bryno: he declared himself leader over and over again [00:29:09] <iive> bryno: he took the project over after fabrice leaft. [00:29:11] <mru> eventually people started believing it [00:29:30] <bryno> how long ago was that? [00:29:34] <iive> i think he is the oldest developer in it. [00:29:41] <Compn> 2002/2003 maybe [00:29:52] <mru> a little later iirc [00:30:17] <Compn> could be [00:31:08] <mru> my first patches are from 2002 [00:31:40] <Compn> DonDiego : this might be part of the 'take over' argument, that if git.ffmpeg.org is a fork, then both repos would be on the download page... (not that i'm saying one way or another, i'm neutral at this point :P) [00:31:41] <mru> most of the others devs from that time are gone [00:32:06] <mru> Compn: then let's add all known repos to the page [00:32:13] <Compn> surely [00:32:21] <mru> with a brief description of each [00:34:15] <Compn> sounds good [00:34:24] * Compn sneaks away without writing xml code [00:49:15] <lu_zero> Compn: say html code =P [00:55:16] <BBB> lu_zero: reviewing 7/7 now... [00:55:22] <BBB> almost done [00:55:33] <BBB> Dark_Shikari: ping [00:56:52] <lu_zero> BBB: I used that set to play with send-mail and rebase ^^; [00:57:11] <lu_zero> most of this code should disapear in the next 8 patches (more or less) [00:58:36] <Dark_Shikari> BBB: pong [00:59:27] <BBB> please review my patch in the repy to jumpyshoes' patch [01:01:23] * Compn afk [01:04:03] <Dark_Shikari> If it's rare, isn't a branch better than a cmov? [01:04:49] <Dark_Shikari> But it's a nice cleaner approach, I like it [01:04:50] <mru> how can a branch ever be better than cmov? [01:04:59] <Dark_Shikari> cmov is 1 cycle, a branch is zero cycles if predicted perfectly [01:05:04] <Dark_Shikari> er, cmov is at least 1 cycle. [01:05:08] <Dark_Shikari> More on shittier CPUs. [01:05:17] <Dark_Shikari> 6 on a pentium 4, but we really don't want to care about that. [01:05:29] <mru> but every branch consumes branch predictor resources [01:05:46] <Dark_Shikari> Oh, you mean in terms of the overall program [01:05:52] <Dark_Shikari> Ah, I see. [01:05:55] <Dark_Shikari> That's much harder to measure [01:06:11] <mru> adding a branch anywhere can cause another one to mispredict [01:07:10] <mru> maybe I should look at the patch before speculating further... [01:07:41] <BBB> Dark_Shikari: it's unlkely, it's ever only untrue for edges, which is unlikely [01:08:05] <mru> how often is the code in question run? [01:08:31] <BBB> so if a branch is cheap enough, then I could add sth. like test r1, r1 jz end_of_func lea r1, default_func .label rest_of_code RET .end_of_func lea r1, special_case jmp rest_of_code label [01:09:21] <BBB> mru: most programs use dc prediction from what I can see... but basically pred in general is once per MB (or 16x for 4x4 mode, and so on for 8x8), plus twice for chroma [01:09:41] <BBB> Dark_Shikari: do you think the branch is better as long as the default case is branchless as I just said? [01:09:49] <DonDiego> i'm fine with adding multiple git trees to the download page or whereever btw [01:09:52] <Dark_Shikari> mru: probably 10-20% of the time in i8x8 blocks [01:10:02] <Dark_Shikari> given typical likelihood, that would be... *calculates*... [01:10:19] <Dark_Shikari> ~0.5% of 8x8 blocks will use this pred mode. [01:10:30] <Dark_Shikari> So it's not worth optimizing for speed if it'll poison the branch predictor. [01:10:37] <mru> question is, how much happens in between each encounter with this branch/cmov? [01:10:53] <Dark_Shikari> I like BBB's approach, run with it [01:11:10] <mru> will the branch predictor even retain the history between each time? [01:11:27] <Dark_Shikari> Modern x86 CPUs have a freaking huge branch predictor, but let's stick with cmov [01:11:48] <mru> roughly how huge? [01:11:51] * mru is curious [01:12:37] <BBB> cmov is ok then? [01:12:38] <BBB> ok [01:13:20] <BBB> mru: I feel incompetent to review the LOCAL_ALIGNED patch because I don't understand what it fixes... can you provide some example of what goes wrong with the current approach? probably if I see 1 line of code where it would fail (I know the rule that vararg macros need more args then defined in the macro def), I'd approve it [01:13:37] <Dark_Shikari> mru: according to a technical article on the topic [01:13:39] <Dark_Shikari> "While Intel did not disclose the number of targets for Nehalem, the P4 BTB had 4K targets, and it seems reasonable that Sandy Bridge has 8K-16K." [01:16:17] <mru> and the history buffer? [01:17:45] <Dark_Shikari> It only says that it's now bigger, doesn't say how big it is. [01:18:04] <mru> a direct branch doesn't use the target buffer [01:18:08] <Dark_Shikari> Ah [01:18:19] <Dark_Shikari> I know in the Core 2 they hashed branch information. [01:18:19] <mru> since the target is known from the instruction [01:18:28] <Dark_Shikari> i.e. created a hash table of history + branch combinations [01:18:36] <mru> arm does something similar [01:18:49] <Dark_Shikari> This stuff is pretty black magic, they don't document the details. [01:18:50] <mru> they throw the pid in the mix too [01:19:05] <Dark_Shikari> Which is unusual; most Intel and AMD stuff is documented in pretty heavy detail. [01:19:12] <Dark_Shikari> Branch prediction... they just give you a few hints on what not to do. [01:19:19] <Dark_Shikari> Like "don't put more than this many branches in 16 bytes of instructions" [01:19:29] <Dark_Shikari> I think AMD says not more than 4 or something retardedly large. [01:20:30] <uau> BBB: about all the current LOCAL_ALIGNED uses look illegal [01:21:20] <mru> uau: explain [01:21:45] <uau> mru: i mean the current ones (which you're trying to fix i assume) [01:22:06] <mru> yes, most of them have too few args [01:22:11] <mru> the patch fixes it [01:22:22] <mru> I came across a compiler that choked otherwise [01:22:49] <uau> BBB: the last from 'git grep LOCAL_ALIGNED': "LOCAL_ALIGNED_16(float, sumd, [17]);" - this is invalid because "# define LOCAL_ALIGNED_16(t, v, s, ...)" means at least 4 arguments are required [01:22:51] <mru> and, yes, I made a mistake writing those macros the first time [01:23:07] <BBB> Dark_Shikari: please ok it on-list if it looks ok to you, and I'll commit [01:23:18] <BBB> mru: I see, makes sense then [01:23:18] <BBB> ok [01:23:22] <BBB> let me ok on-list [01:23:41] <mru> uau: feel free to comment on the patch if you like [01:23:51] <mru> this is the kind if thing you usually have a handle on [01:24:17] <BBB> right, any person considering himself/herself knowledgeable should help getting this sort of stuff done [01:24:24] <BBB> the more eyes, the better [01:24:39] <mru> so I'd appreciate a comment from uau [01:25:24] <Dark_Shikari> done [01:26:42] <DonDiego> ok, i'm falling asleep here [01:26:43] <DonDiego> gnite [01:30:57] <BBB> uh, I'm no good at this [01:31:03] <BBB> "fatal: The remote end hung up unexpectedly" [01:31:35] <Dark_Shikari> same problem I had [01:31:50] <BBB> did you fix it? [01:31:52] <Dark_Shikari> yes [01:31:57] <Dark_Shikari> 1) in your ~/.ssh/config [01:31:59] <Dark_Shikari> add [01:32:04] <Dark_Shikari> Host *.ffmpeg.org [01:32:07] <Dark_Shikari> Port 2222 [01:32:15] <BBB> I had that [01:32:19] <BBB> I couldn't check out w/o it [01:32:25] <Dark_Shikari> in your .git/config [01:32:30] <Dark_Shikari> url = git@git.ffmpeg.org:ffmpeg.git [01:32:35] <Dark_Shikari> should be there under remote "origin" [01:33:18] <BBB> got it [01:33:43] <BBB> ok, I'm outdated [01:33:58] <mru> then you pull --rebase [01:34:30] * mru suggests doing git config branch.master.rebase true [01:35:19] <BBB> let's do it manually for now [01:35:24] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rb9c7f66e6d ffmpeg/libavcodec/x86/h264_intrapred.asm: [01:35:24] <CIA-29> ffmpeg: Fix horizontal/horizontal_up 8x8l intra prediction x86/simd functions. [01:35:24] <CIA-29> ffmpeg: The original functions did not work correctly for edge pixels, e.g. [01:35:24] <CIA-29> ffmpeg: when CODEC_FLAG_EMU_EDGE is set, leading to corrupt output in e.g. VLC. [01:35:24] <CIA-29> ffmpeg: Based on a patch by Daniel Kang <daniel d kang gmail com>. [01:35:24] <BBB> I'll break tons of stuff in the process anyway [01:35:25] <CIA-29> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje gmail com> [01:35:28] <BBB> \o/ it worked [01:37:49] <mru> BBB: so what did this fix? [01:38:05] <mru> in terms of observed breakage [01:38:10] <Dark_Shikari> h264 decode with emu edge [01:38:13] <Dark_Shikari> vlc was crashing [01:38:40] <BBB> crash or (more likely) corrupt output in vlc [01:38:48] <BBB> the output isn't correct yet, but it's less corrupt [01:38:57] <BBB> there's another bug [01:39:11] <BBB> I don't think it's dc, I think it's h264.c which loads the wrong var in chroma_pred_mode [01:43:46] <uau> mru: i think it would be more readable to do something like this: [01:43:47] <BBB> hm... the ref is wrong [01:43:48] <BBB> omg [01:43:49] <uau> #define LOCAL_ALIGNED_8_INTERNAL(t, v, s, o, ...) DECLARE_ALIGNED(8, t, v) s o [01:43:49] <uau> #define LOCAL_ALIGNED_8(t, v, ...) DECLARE_ALIGNED_INTERNAL(t, v, __VA_ARGS__,,) [01:44:16] <uau> hmm wrong macro name there [01:44:35] <uau> last one should be LOCAL_ALIGNED_8_INTERNAL of course [01:45:28] <BBB> Dark_Shikari: I don't think ffh264 handles streams where chroma pred mode is not coded in the stream [01:45:43] <BBB> it just leaves the predmode to the default (zero), which is of course wrong for edge pixels [01:45:52] <Dark_Shikari> You mean 4:0:0 streams? [01:46:11] <BBB> I think the stream has color [01:46:13] <BBB> or is supposed to have [01:46:18] <Dark_Shikari> "chroma pred mode is not coded" == "4:0:0 [01:46:27] <BBB> check h264-conformance/FRext/HPCAMOLQ_BRCM_B.264 [01:47:00] <BBB> ok, so I guess we don't handle 4:0:0 streams then, because chroma prediction does run and it has tons of valgrind errors because we run dc on edge blocks [01:47:34] <Dark_Shikari> Yes we do [01:47:51] <Dark_Shikari> if there's a bug, fix it [01:47:58] <Dark_Shikari> I posted a patch on the ML the other day to make x264 generate 4:0:0 streams [01:48:01] <Dark_Shikari> for testing [01:48:11] <BBB> that stream above is 4:0:0 in the reference samples [01:48:25] <BBB> that's enough for testing for now :-p [01:50:45] <BBB> the only format I see being output is YUVJ420 btw [01:50:56] <BBB> where's the 400 handling code? [01:53:19] <Dark_Shikari> It outputs 4:2:0 [01:53:26] <Dark_Shikari> even when it's 4:0:0 [01:53:29] <Dark_Shikari> but it _supports_ it [02:06:31] <mru> uau: thanks, that's much better [02:08:30] <mru> I'll test it with the picky compiler tomorrow just to be sure [02:08:57] * mru doesn't want to start messing with old sgi machines at this hour [02:16:39] <BBB> Dark_Shikari: hahaha no it doesn't :-p [02:16:47] <BBB> dark_shikari: ffplay h264-conformance/FRext/HPCAMOLQ_BRCM_B.264 [02:18:01] <Dark_Shikari> What do you mean, it doesn't? I tested it the other day. [02:18:04] <Dark_Shikari> And I even fixed a bug in it. [02:18:07] <BBB> it's green [02:18:15] <Dark_Shikari> Er... and? Look at the Y channel. [02:18:28] <BBB> it shoudl use dc_128, not dc prediction [02:18:30] <Dark_Shikari> If you want to fix it, make it output Y8 instead of yuv420p [02:18:30] <BBB> it uses dc prediction [02:18:37] <Dark_Shikari> It shouldn't touch chroma at all [02:18:41] <BBB> I agree [02:18:45] <Dark_Shikari> This is actually on my list of things to fix for Gaikai. [02:18:49] <BBB> but you agree that the u/v channels are wrong right? :-p [02:18:54] <BBB> ah, ok, I'll not touch it then :-D [02:19:00] <Dark_Shikari> No, you should feel free to fix that. [02:19:05] <BBB> hehe </lazy> [02:19:07] <Dark_Shikari> I doubt I'll completely be able to eliminate all references to chroma. [02:19:07] <BBB> ok, I will [02:19:22] <BBB> but anyway, I'm glad we agree it's broken [02:19:27] <mru> BBB: is that what's called chromatic aberration? [02:19:52] <BBB> I thought that was a microscope term [02:20:00] <BBB> that was just on the midterm of the class that I lecture [02:20:06] <BBB> anyway, probably not what you meant [02:21:03] <mru> it's a general lens term [02:33:02] <saintdev> someone should probably reply to MN's olive branch [02:33:28] <mru> olive branch? [02:35:13] <saintdev> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/124020 [02:39:13] <BBB> there was no patch posted [02:40:21] <bryno> lol, that's the reply to the 'olive branch' [02:40:51] <BBB> oh rly? [02:42:58] <bryno> yes. [02:44:23] <BBB> weird, I don't see a reply in my mail client [02:45:56] <bryno> i think we're in irc [02:46:13] <mru> there is no reply [02:46:37] <bryno> bah. nevermind. [02:58:22] <CIA-29> ffmpeg: Michael Niedermayer master * r45c889a3ad ffmpeg/libavfilter/libmpcodecs/ (vf_detc.c vf_divtc.c vf_palette.c): Add #define _BSD_SOURCE where mplayer is not C99. [02:58:23] <CIA-29> ffmpeg: Michael Niedermayer master * r3be78f7ecd ffmpeg/libavfilter/libmpcodecs/ (libvo/video_out.h mp_image.c mp_image.h vf.h): Hack libmpcodecs to make it buildable. [02:58:49] <CIA-29> ffmpeg: Michael Niedermayer master * re4852fb38d ffmpeg/libavfilter/libmpcodecs/ (75 files in 2 dirs): Add MPlayers libmpcodecs, this will be needed for our libavfilter wraper for it. [02:59:01] <CIA-29> ffmpeg: Michael Niedermayer master * r3aa43978da ffmpeg/libavfilter/vf_mp.c: Add libmpcodecs wrapper for libavfilter, still disabled [02:59:55] <CIA-29> ffmpeg: Michael Niedermayer master * r8e45c103e9 ffmpeg/libavfilter/libmpcodecs/ (vf_delogo.c vf_eq.c vf_hue.c): Remove dependancy of m_option & m_struct from libmpcodecs. [02:59:55] <CIA-29> ffmpeg: Michael Niedermayer master * r4d46361425 ffmpeg/libavfilter/libmpcodecs/vf_pullup.c: Avoid dependancy on global variable verbose in libmpcodecs/vf_pullup.c [03:00:06] <CIA-29> ffmpeg: Michael Niedermayer master * rfd4c59b519 ffmpeg/libavfilter/ (Makefile allfilters.c): Enable libmpcodecs support. [03:00:21] <CIA-29> ffmpeg: Michael Niedermayer master * r61d7f8fed4 ffmpeg/libavfilter/vf_mp.c: Warn about vf_mp [03:00:57] <CIA-29> ffmpeg: Michael Niedermayer master * ra61b0df708 ffmpeg/libavfilter/libmpcodecs/mp_image.h: Add ASMALIGN() hack to patch around its recent removial from configure [03:04:22] <Compn> bryno : iirc stefano is libavfilter maintainer, and he is not currently part of neuteam [03:05:16] <mru> jannau: can we at least have the videolan cia messages tagged with something to distinguish them from ffmpeg.org? [03:06:07] <Compn> i'm guessing no, but would git.ffmpeg allow libmpcodecs in ? [03:06:17] <mru> of course not [03:06:27] <Compn> just thought i'd ask :P [03:09:39] <pengvado> several of the recent commit messages contain a "Signed-off-by:", and some of them give the same name there as both the author and committer fields. [03:09:42] <pengvado> I can understand separating signed-off from committer, if the committer is acting as patch-monkey rather than as reviewer, but why would signed-off ever be equal to author? [03:18:00] <BBB> uh... that's my mistake, I didn't know we shouldn't if they're different [03:18:07] <BBB> I'm new to the git way of doing things [03:18:28] <mru> linux kernel requires one on every commit [03:20:16] <astrange> perian 1.2.2 ran out of bugs. no time to change the svn externals to a git checkout script, good thing they've hardly diverged yet [03:24:35] <mru> ran out of bugs? [03:25:20] <astrange> it's got release milestones and everything [03:25:54] <mru> bugs are in unlimited supply [03:25:59] <mru> one cannot run out [03:26:27] <Plorkyeran> ran out of known bugs [03:26:52] <mru> so open a random source file and stare at it [03:26:54] <mru> there will be bugs [03:26:58] <astrange> well, i haven't imported the h264 crash fix they were talking about up there [03:27:19] <astrange> but it's run past what anyone cares to fix [03:33:06] <uau> pengvado: the kernel documentation says "The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch." [03:40:44] <BBB> uau: ianal bullcrap disclaimer but that line has as much legal meaning as the standard email footers that companies put down their emails [03:42:17] <16SAAYUNZ> The idea is to know who to put on the stand when someone sues you for copyright infringement [03:43:13] <saintdev> peloverde: you're seriously keeping that nick? [03:43:25] <16SAAYUNZ> maybe, we'll see [03:43:30] <saintdev> LOL [03:59:37] <BBB> wait that's peloverde? [04:00:07] <BBB> omg he has ops, it really is peloverde [04:03:07] <saintdev> hurr, lol [04:05:19] <16SAAYUNZ> Has anyone tested adpcm_ms-in-mov recently? It seems very broken [04:06:43] <saintdev> all you math peoples: potential proof P=NP (this time with source code!) http://romvf.wordpress.com/2011/01/19/open-letter/ [04:09:46] <16SAAYUNZ> no demuxer except libavf seems to like the output [04:10:11] <16SAAYUNZ> (segfaults gstreamer; silence with videolan and quicktime) [04:10:22] <BBB> muxer? might not be tested very much [04:10:24] <BBB> :( [04:10:36] <BBB> but gst segfaults :-p [04:11:08] <16SAAYUNZ> I'm going to be nice and send them a bug report [04:11:27] <16SAAYUNZ> and then if my gstreamer experience holds it will rot in bugzilla.gnome.org [04:27:18] <BBB> :-p [04:29:19] <16SAAYUNZ> we let a lot of bugs rot too so I shouldn [04:29:24] <16SAAYUNZ> 't complain too much [04:34:09] <BBB> 16SAAYUNZ: please change your nick, I can't take you seriously with all those caps in your nick [04:34:14] <BBB> it's like a scriptkiddie [04:34:19] <BBB> :-p [04:36:30] <saintdev> should have changed it to 16aayunz [04:37:34] <Jumpyshoes> ;D [04:37:47] <saintdev> oops, missed an s [04:43:09] <BBB> peloverde_: thank you :) [04:43:11] <astrange> i kept reading it as "16 saiyans" [04:43:13] * BBB goes sleep [04:43:23] <BBB> wat does that nick mean anyway [04:43:31] <saintdev> it was bugging BBB so much he couldn't sleep o.O [04:43:37] <BBB> true [04:43:47] <BBB> well, h264 fate failing also bugs me [04:43:48] <peloverde_> it means freenode nick collision loves me [04:45:09] <peloverde_> fate isn't very useful right now seeing as half the configs point in different places [04:46:09] <BBB> indeed [04:46:44] * BBB hopes we can get a win64 box somewhere for fate... [04:50:27] <drv> i could probably run one, would need to configure mingw-w64 first though [05:14:16] <elenril> morning [05:14:43] <Jumpyshoes> morning~ [05:14:50] * elenril reads all the drama [05:15:36] <Jumpyshoes> ;) [05:22:46] * elenril sighs [05:23:04] * elenril still thinks the announcement should've been made more clear [05:32:45] * elenril wonders wtf is the point of get_strz returning the buffer which was passed to it instead of number of bytes read [05:35:06] <andyzweb> will svn.ffmpeg.org become a svn mirrior of git.ffmpeg.org as part of the new source control changes? [05:47:07] <_av500_> no [05:48:46] <andyzweb> so if I want to keep current I will have to switch to git? [05:48:54] <_av500_> yes [05:49:03] <_av500_> just let svn go [05:49:37] <andyzweb> git pull, git pull everywhere [05:49:59] <elenril> git is great [05:50:44] <andyzweb> I agree, I will just have to get my people to switch over to git, they are all stuck in the windows world. [05:52:48] <peloverde_> anyone have a gstreamer-0.10-plugins-good more recent than 0.10.25 and willing to test something for me real quick? [05:54:27] <saintdev> 0.10.23 here :/ [05:54:33] <j45> i have 0.10.25 from ubuntu 10.10 [05:54:49] <elenril> 0.10.26.3-1 in debian experimental [05:55:02] <saintdev> peloverde_: which plugin are you looking for specifically ? [05:55:08] <peloverde_> qtdemux [05:55:40] <peloverde_> I want to see if FFmpeg muxed adpcm_ms crashes a more recent version than what I have [05:56:41] <saintdev> hmm, seems gentoo doesn't split that one out [05:57:11] <elenril> peloverde_: so what should i test [05:58:29] <peloverde_> /incoming/ff_adpcm_ms.mov.bz2 [05:59:29] <elenril> what was the server name? [06:00:03] <peloverde_> samples.mplayerhq.hu [06:00:03] <elenril> nvm, got it [06:00:32] <peloverde_> gst-launch-0.10 -f --gst-debug=qtdemux:3 filesrc location=ff_adpcm_ms.mov ! decodebin [06:03:09] <elenril> http://pastebin.com/fYQ749bU [06:03:18] <elenril> want a backtrace or something? [06:03:50] <peloverde_> that's pretty much all I need [06:03:53] <peloverde_> I have the smae crash [06:04:03] <peloverde_> I just wanted to make sure they hadn't fixed it yet [06:40:46] <peloverde_> anyone have a sample of MS ADPCM muxed by quicktime [06:52:10] <ch3rryc0ke> Hello-- I've built ffmpeg version 26326, and I'm wondering if I need to manually install the RTP H264 patch talked about in this thread: https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/090821.html [06:52:22] <ch3rryc0ke> Was it ever committed? [07:03:15] <astrange> peloverde: i can make one [07:03:45] <peloverde_> that would be awesome [07:04:36] <astrange> http://astrange.ithinksw.net/ffmpeg/scatter.wav.mov resaved from the sample wav on mphq [07:05:09] <KotH> moin [07:05:20] <peloverde_> ch3rryc0ke: supposedly it was commited in june [07:05:26] <KotH> jannau: hmm? [07:05:36] <peloverde_> astrange: thanks [07:05:40] <thresh> how do you guys plan using one ML for two projects? ;o [07:05:53] <ch3rryc0ke> peloverde_: thanks! [07:07:00] <elenril> thresh: we'll pretend the other is not there [07:07:21] <thresh> pfft [07:07:32] <thresh> .procmailrc ftw ;P [07:07:35] <elenril> it has many advantages [07:07:59] <elenril> michael might review our patches assuming they're meant for his part of the ML ;) [07:08:01] <thresh> yay for people wanting their patches to get in [07:08:04] <thresh> haha yeah [07:19:27] <jannau> KotH: http://twitter.com/bash_vi/statuses/27828217876324352 [07:21:49] <jannau> mru: I've nothing to do with the cia notifies from git.v.o [07:22:52] <j-b> good moroning [07:34:22] <cartman> moin [07:54:20] <spaam> God morgon :) [07:54:28] <cartman> elow spaam [07:54:36] <spaam> wzup? [07:56:13] <cartman> messing with Android [07:56:58] <cartman> I/OMAPFBPLAY( 3286): Decoder '(null)' not found. [07:57:00] <kierank> TurkDroid (tm) [07:57:01] <cartman> is the summary :D [07:57:12] <cartman> kierank: there is a TrDroid project for real :D [08:00:10] <spaam> cartman: kierank made it [08:00:25] <cartman> spaam: whoa :P [08:00:44] <spaam> cartman: he is a wannabe turk ;) [08:00:57] * cartman is The Turl [08:00:59] <cartman> Turk too [08:01:00] <cartman> :P [08:01:38] <wbs> av500: about the rtsp/mpegts/latm stream you mentioned yesterday, is the sample still up for grabbing somewhere? [08:03:04] <peloverde_> hmm, fixed gstreamer vlc is still misbehaving [08:04:11] <peloverde_> and if i remux through wav it's all kinds of messed up [08:16:10] <av500> wbs: yes, the pcap stuff is still there and the ts to [08:16:17] <av500> as said, ff plays the ts fine [08:16:23] <av500> but fails to play the live stream [08:16:58] <kierank> av500: "fine" [08:17:01] <kierank> it blocks like crazyt [08:17:11] <av500> :) [08:17:13] <av500> well yes [08:17:23] <av500> but i dont want to debug bad wifi [08:17:44] <av500> I also got a clean stream from the free.fr headend [08:17:48] <av500> that plays fine too [08:17:55] <av500> only over rtsp it fails to have audio [08:18:02] <wbs> av500: hmm, I only saw an url to 0x.deadba.be/~tom/freebox_dump.tar.gz which gives me 404 now [08:18:20] <av500> yes, its a dsl upload thus slow [08:18:25] <av500> I can robot it for you [08:28:25] <wbs> robot it? [08:29:04] <cartman> av500 is a robot [08:29:10] <cartman> mankind's life is at stake [08:30:21] <j-b> robots are nicer than human [08:30:25] <av500> wbs: we have a webservice that we use to up/download stuff with 3rd parties [08:30:34] <av500> and its called "robot" :) [08:30:37] <av500> so we robot things [08:30:41] <wbs> av500: I see :-) [08:31:05] <spaam> ISO Media, MPEG v4 system, part 12 revision .. is that a .mp4 file? [08:31:21] <kierank> yes [08:31:34] <spaam> great :) [08:31:50] <av500> spaam: beware, its patented! [08:31:52] <spaam> i saw a file with ismv extenstion. [08:32:10] <peloverde_> ok, copying adpcm from wav to mov was always broken [08:32:23] <kierank> spaam: maybe some weird varianr [08:32:33] <spaam> kierank: blame netflix :) [08:33:22] <j-b> ismv is Microsoft smooth streaming [08:33:43] <spaam> maybe i need to download more then 1.7mb of the file [08:34:04] <av500> spaam: you need to download it smoothly [08:34:09] <j-b> BBB: awesome... I can release now... [08:34:26] <spaam> av500: i will try. i hope wget can do it [08:34:33] <av500> --smooth [08:36:43] <spaam> great. [08:36:48] <spaam> i found this: http://pastie.org/private/kx8zalnm4rgwyl8ivto99w [08:37:19] <spaam> about that .ismv file :) [08:37:24] <j-b> 52.103.1 << isn't that a bit a weird numbering [08:37:36] <thresh> why? [08:37:41] <av500> is that dewey decimal? [08:43:20] <kierank> av500: nah, library of congress [08:58:15] <av500> elenril: if I have a format that supports having images (as stream) inside, how would I mux a jpg into the id3v2 tag of that same format? [08:58:41] <elenril> av500: easy, we only write id3v2 into mp3s =p [08:58:52] <elenril> everything else is an evil hack [08:58:53] <av500> harhar [08:58:59] <elenril> (actually, id3v2 is an evil hack) [08:59:24] <av500> elenril: I have nice asfs with id3v2 and album art inside [08:59:39] * elenril burns av500 with fire [08:59:47] <elenril> we might want to support reading such files [08:59:53] <elenril> but certainly not muxing them [08:59:59] <av500> elenril: I will work on that :) [09:00:32] <av500> elenril: but my question is still valid [09:00:42] <av500> album art can be outside of od3v2 [09:00:45] <av500> id3v2 [09:01:08] <elenril> my question is still valid too [09:01:16] <elenril> why would you want to do that [09:01:25] <av500> do what? add album art to a flac file? [09:01:28] <av500> or ogg [09:01:30] <av500> or mp4 [09:01:39] <elenril> if the format supports proper images, why write it into id3 [09:02:10] <av500> I removed the id3v2 from the question [09:02:49] <av500> I have a format that supports having images (as stream) inside, how would I mux a jpg into the metadata part of that same format? [09:03:16] <elenril> why would you want to do that [09:03:33] <av500> ok, so album art will be read only... [09:03:54] <av500> I put mine into the folder anyway :) [09:04:09] <av500> saves me from retagging every file [09:06:51] <elenril> well suggestions welcome [09:06:58] <elenril> make it an avoption or something [09:07:09] <elenril> (patches welcome of course =p ) [09:09:42] <av500> :) [09:10:58] <kshishkov> bink-b support patch is extremely welcome too [09:11:29] * elenril hopes kshishkov is not working in wavpack multichannel in the meantime [09:12:10] <kshishkov> elenril: don't worry, I don't work at all meantime (except at $DAYJOB) [09:12:31] * elenril should get a $DAYJOB so he can not work on stuff [09:13:18] <cartman> av500: would uyou happen to know magic-head.S and magic-tail.S? Need some help debugging it. [09:13:34] <kshishkov> elenril: well, once I had dayjob, was working on my bachelor degree thesis and REing RV3 all in the same time [09:14:02] <av500> cartman: its magic [09:14:11] <KotH> jannau: ROTFL [09:14:13] <cartman> av500: apparently :D [09:14:22] <kierank> kshishkov: I like the way REing RV3 is up there with the other two [09:15:22] <cartman> I'll wait for mru then [09:15:24] <kshishkov> kierank: well, at uni they relaxed me a bit since I was working for their company, at company they relaxed me since I had to graduate, so I had time for RV3 ;) [09:15:49] <kshishkov> KotH: I decided to try German chocolate [09:15:53] <cartman> there seems to be a problem when you wrap omapfbplay in a shared library as opposed to being a standalone executable [09:16:16] <kierank> kshishkov: I still don't understand the major question. WHY? [09:16:21] <kierank> why realvideo [09:16:27] <cartman> kierank: Anime [09:16:30] <elenril> masochism [09:16:38] <kshishkov> kierank: because Mike and Benjamin wanted it [09:16:43] <kshishkov> kierank: ask them [09:18:58] <cartman> yes, some bastards took over the ffmpeg project yesterday and fscked up the svn... [09:19:00] <cartman> LOL [09:19:51] <av500> gazillions of chinese need realvideo [09:20:04] <cartman> stop pleasing Chinese [09:20:18] <kshishkov> av500: if you don't know my favourite toast is "what it has to do with us" [09:20:44] * av500 prefers "mighty white" [09:21:11] <kshishkov> av500: sounds like ElenrilTropes entry [09:27:36] <elenril> kshishkov: http://tvtropes.org/pmwiki/pmwiki.php/Main/MightyWhitey [09:27:46] <kshishkov> elenril: thought so [09:28:34] <av500> kshishkov: it is also a defunct toast brand :) [09:29:31] <kshishkov> av500: could be, I have little interest in toasts [09:30:34] <av500> kshishkov: what else do you put peanut butter and jam on? [09:30:46] * elenril wonders why didn't he buy more ram years ago [09:31:09] <av500> elenril: and now its hard to get? [09:31:17] <av500> pre-DDR? [09:31:21] <elenril> av500: no, i bought it yesterday [09:31:36] <elenril> just should've done that much sooner [09:31:45] <elenril> living with just 1GB was a major PITA [09:31:52] <av500> oh [09:31:53] <av500> yes [09:32:42] <kshishkov> av500: I prefer to put my hjortronsylt on smÃ¶rgÃ¥sran [09:33:23] <kshishkov> av500: "pre-DDR" sounds a bit ambiguous concerning your location [09:34:16] <av500> kshishkov: I did not assume elenril runs a 1940's machine [09:41:35] <ohsix> edo or fpm [09:42:08] <kierank> kshishkov: dance dance revolution? [09:42:57] <kshishkov> kierank: what's that? For me DDR will always stand for "Deutsche Demokratische Kommierespublik" [09:43:14] <kierank> some game [09:43:19] <kierank> arcade game where you dance [09:43:33] <av500> kierank: kshishkov's favorite game [09:43:48] <kierank> asians are well known for playing it [09:43:55] <spaam> kierank: come on.. you didnt know what DDR was? :P [09:44:15] <kshishkov> av500: in my case it's "stomp heavily on other people's feet" game [09:44:31] <av500> kshishkov: thats what dancing is about, no? [09:45:28] <superdump> for me DDR used to be double data rate (ram) [09:45:36] <kshishkov> av500: there's another type - being jammed in the crowd - quite popular in disco and night clubs [09:45:48] <av500> thats where you can stomp best [09:45:51] <superdump> but people rarely say ddr in that context anymore [09:46:26] <kshishkov> superdump: and next you'll say "GB" doesn't mean "Chinese standard" for you [09:47:24] <superdump> certainly doesn't [09:47:29] <superdump> i didn't even know that [09:47:35] <av500> BIG5 ftw! [09:47:37] <ohsix> yea the distinction was with rambus at the time [09:48:07] <ohsix> now it's just stuff that transfers on either side of the clock and standard bus rates/arrangements/jedec stuff [09:52:16] <cartman> av500: look at /private :P [09:52:36] <kshishkov> merbzt: can you explain to kierank why I had to work on RV4? [09:53:01] <merbzt> coz we tricked you that is [09:53:14] <merbzt> :) [09:53:33] <DonDiego> BBB: i wonder if it was good to answer michael's question in public [09:53:49] <cartman> av500: you got mail too (unrelated to my question :P) [09:53:54] <KotH> kshishkov: well... just let me tell you taht most german choco is edible, but far from being good [09:54:31] <kierank> kshishkov: here is a swedish residence visa if you finish rv4 ? [09:54:59] <kshishkov> merbzt: no, why you needed it REd [09:55:18] <DonDiego> there is more stuff that one could add, but i'm afraid this could spiral downwards as usual... [09:55:43] <kshishkov> KotH: edible - yes, but lacks taste. I had to resort to LÃ€derach after that [09:56:01] <thresh> "ÐÐ»ÑÐœÐºÐ°" ftw [09:56:05] <merbzt> kshishkov: because you where supposed to implement a decoder for soc [09:56:57] <kshishkov> merbzt: could be some other decoder but you've asked for this one [09:57:17] <KotH> kshishkov: hehe [09:57:41] <KotH> kshishkov: läderach is cool... but where did you get it? i've never seen it outside .ch [09:57:52] <av500> smugglers! [09:58:03] <av500> KotH: and he admitted he was in .ch [09:58:33] <kshishkov> KotH: we have their shop at Marktplatz [09:58:40] <KotH> o_0 [09:58:44] * KotH is astonished [09:58:57] <lyakh> can anyone tell me what that "runcmd" in fate / ffmpeg configs is? [09:58:59] <av500> KotH: swiss export control is getting lax? [09:59:03] <merbzt> kshishkov: I ask about lots of things [09:59:07] <kshishkov> KotH: don't forget that we also have direct connection to Basle and even our own railroad station there [09:59:30] <KotH> av500: more like "i didnt know they have such a large production now that they can open shops in other countries" [09:59:59] <KotH> kshishkov: basel is way of from where läderach comes from [10:00:25] * elenril looks at his covert art hack and is tempted to git reset --hard again [10:00:34] <kshishkov> KotH: look at http://www.laederach.ch/de/shop/shopfinder/welt.php?showAddress=deutschland [10:00:49] <av500> "...LÃ€derach opens second shop in South Korea.." [10:00:50] * KotH looks [10:01:03] <cartman> av500: at least not the North [10:01:25] <kshishkov> KotH: also it's funny that half of places are in Baden [10:01:45] <KotH> hey, they have two in tokyo as well [10:02:31] <av500> and MUC and I will be there soon</plan> [10:02:36] <kshishkov> hey, they have even shops in ZÃŒrich! [10:02:42] <av500> wow [10:02:43] <KotH> lol [10:04:28] <kshishkov> av500: it's a wonder how Switzerland manages to grow that much cocoa [10:04:43] <av500> kshishkov: they have those large caverns in the alps [10:04:53] <av500> and lots of UV lighty [10:04:55] <kshishkov> av500: filled with gold? [10:05:22] <av500> kshishkov: dunno, does cocoa grow on gold? [10:05:39] <kshishkov> av500: only corn does [10:06:06] <lu_zero> 10:53 <@DonDiego> BBB: i wonder if it was good to answer michael's question in public [10:06:21] <kshishkov> av500: but while corn extracts gold from soil it can't beat lawyers and wives [10:06:58] <lu_zero> I was undecided as well [10:07:31] <wbs> lu_zero: I do think it's good to explain it in public [10:07:57] <av500> well, the cabal was critisized to have been too secret.... [10:07:57] <kshishkov> we have nothing to hide now, don't we? [10:08:57] <DonDiego> one could start explaining, yes, but part of it could get ugly [10:09:41] <elenril> it'll get more ugly if it's not clear what our motivation was [10:09:41] <kierank> someone would have leaked it anyway [10:09:43] <wbs> lu_zero: a lot of people have been unaware of the extent of the issue, and the nonpublic discussions between BBB, michael, diego and mru(?) [10:09:49] <elenril> and apparrently it's not clear to many [10:11:07] <KotH> wbs: you can add a few names more there [10:11:56] <wbs> KotH: ah, yes [10:12:32] <wbs> that's probably one of the larger parts of the confusion, people not aware of all that history, and then trying to understand wtf and why [10:13:14] <{V}> does it really matter? it's not like those who undersigned the Announcement are strangers [10:13:59] <KotH> {V}: well... people dont know whether these are strangers or not [10:14:16] <KotH> {V}: there is a lot of misunderstanding due to that [10:14:27] <KotH> {V}: heck, i've been even labled as the leader of the revolution [10:14:57] <elenril> you're not? =p [10:15:20] * KotH configures natsuki to reject all mails from elenril [10:15:23] <{V}> probably just based on that you were the unforunate one to actually send the email [10:15:31] <Kovensky> Attila the Chocolate Hun [10:15:49] <elenril> KotH: how not nice [10:15:56] <KotH> {V}: me sending the mail was a decision we took, there is nothing unfortunate about it [10:16:04] * elenril considers joining michael's fork in revenge [10:16:05] <kshishkov> {V}: that was only because he's True Neutral (from very neutral country too except when you speak about chocolate) [10:17:50] <kshishkov> elenril: at least you can have a lot of metadata with git commits [10:26:11] <kshishkov> mate! [10:26:40] * kshishkov reminds that whatever happens FFmpeg should get Bink-b support [10:27:02] <kierank> http://software.solidot.org/article.pl?sid=11/01/20/0759213 [10:27:13] <kierank> chinese seem to be interested [10:27:54] <pross-au> Wilco [10:28:33] <kshishkov> kierank: why does that site look like Chinese Slashdot ripoff? [10:28:46] <kierank> because it is [10:29:06] <mmu_man> plop [10:29:12] <av500> "The reason is to unify the revolution, FFmpeg serious split the community they have not watch." [10:29:14] <mmu_man> anyone looked into the ARF format yet ? https://intercallcenters.webex.com/docs/T26L/common_docs/en_US/record/man/w… [10:29:36] * mmu_man throws some tunisians in [10:30:05] <cartman> av500: google translate? :P [10:30:08] <av500> mmu_man: patches welcome [10:30:21] <kshishkov> mmu_man: better Tunisians than BeOS users [10:30:24] <mmu_man> just asking, too busy. [10:30:34] <av500> cartman: yup [10:30:43] <mmu_man> kshishkov: well BeOS users freed themselves with Haiku long ago :p [10:30:47] <mmu_man> :^) [10:31:44] <mmu_man> "Converting recordings to Flash format" [10:31:46] <mmu_man> OMFG [10:31:54] <mmu_man> Why would one want to ? [10:32:05] <mmu_man> convert from a proprietary format to yet another proprietary format ? [10:32:11] <kshishkov> probably it's remuxing MP3 stream into WMV or SWF [10:32:36] <mmu_man> guess so, ah yes it exports to WMV too... [10:32:46] <mmu_man> but well that means you need their player first anyway [10:32:47] <mmu_man> sux [10:33:05] <kshishkov> mmu_man: there's one Wikipedia article that makes me laugh really hard - http://en.wikipedia.org/wiki/List_of_BeOS_programs [10:33:13] <mmu_man> "ARF recordings are a proprietary WebEx ARF format" << oh, in case I wasn't sure [10:33:51] <kierank> mmu_man: clearly a french person thought of the name arf [10:34:11] <mmu_man> kshishkov: there are some more on http://bebits.com/ [10:34:19] <mmu_man> kierank: arf, oui :) [10:34:53] <av500> kshishkov: it has vlc, thus it is complete [10:34:57] <kshishkov> mmu: that reminds me - what's the difference between your words "loup" and "garou"? [10:35:12] <kshishkov> av500: unlike your company products [10:35:22] <mmu_man> bleh, stupid player app installs an icon on my desktop [10:35:26] <mmu_man> who told it to ? [10:35:31] <av500> you [10:36:05] <mmu_man> kshishkov: loup == wolf [10:36:25] <mmu_man> the loup garou is more a mythical beast [10:36:37] <mmu_man> that eats bad behaving children [10:36:55] * elenril recalls seein a loup garou in baldur's gate 2 [10:36:57] <mmu_man> the magical one that is actually human during the day [10:37:12] <kshishkov> werewolf? [10:37:15] <elenril> it was an upgraded werewolf iirc [10:37:16] <mmu_man> well looks human [10:37:17] <mmu_man> yeah [10:37:43] <mmu_man> then there is the bÃªte du gÃ©vaudan [10:37:48] <kshishkov> and is word "garou" ever used separately? [10:37:56] <mmu_man> don't think so [10:38:20] <kshishkov> mmu_man: never heard of that beast from Gevaudan forest too [10:38:28] <mmu_man> appart as the scene name of a quebec singer [10:38:57] <DonDiego> btw, i think one of the problems in the announcement was that we overloaded the word "maintainer" [10:39:13] <DonDiego> it has a well-known and fixed meaning in the ffmpeg community [10:39:29] <DonDiego> trying to use it for something else is bound to cause confusion... [10:40:04] <Dark_Shikari> agreed [10:40:08] <Dark_Shikari> you should mention that [10:40:24] <DonDiego> i would like to note that there is a lesson here: [10:40:36] <DonDiego> not every discussion about words and little things is a bikeshed [10:42:33] <Dark_Shikari> heh [10:43:38] <kshishkov> DonDiego: I call it "defining terms", without it you usually have bikesheds because of misinterpretations [10:51:54] <thresh> kshishkov: http://img89.imageshack.us/img89/5259/1295486824752.jpg [10:53:41] <kshishkov> thresh: Ð¿ÐŸÑÐºÐŸÑÐµÐ¹ Ð±Ñ [10:54:21] <merbzt> oh the poor car [10:54:27] <merbzt> I can't watch anymore [10:56:31] <DonDiego> reynaldo: aren't you the WTV guy? [10:56:43] <DonDiego> reynaldo: peter ross is pinging a patch [10:58:10] <mru> moroning [10:58:41] <cartman> mru: morning [10:59:03] <kierank> kshishkov: ever been on a train ferry? [10:59:06] <cartman> mru: having some problems with magic-{head,tail}.S if you have some time [10:59:22] <mmu_man> plop [11:00:21] <mru> cartman: they're magic [11:01:03] <kshishkov> kierank: nope, only on ordinary one (Stockholm-Ãbo) [11:01:04] <cartman> mru: yup [11:01:27] <cartman> mru: find_driver returns NULL for ofbp_codec_start, so its not finding avcodec [11:01:34] <kierank> kshishkov: you'd enjoy that. I can tell [11:01:47] <cartman> mru: objdump on avcodec.o shows me that it has .ofbp_codec defined [11:02:15] <cartman> mru: but there is one "tiny" problem, in Android I am wrapping omapfbplay in a shared library, not an executable [11:02:20] <kshishkov> kierank: well, there's one on the route Berlin-Stockholm but I had no reason to go anywhere via Berlin [11:02:22] <cartman> mru: does that make a difference? [11:02:36] <in3xes> Can anyone tell me what FFV1 is? [11:02:37] <mru> no idea [11:02:42] <cartman> mru: good [11:02:44] <mru> try linking with -Bsymbolic [11:02:55] <cartman> mru: ok [11:03:03] <kshishkov> in3xes: FOURCC for video codec known as FFV1 [11:05:32] <in3xes> How difficult is this http://goo.gl/kEfnX for a starter? [11:05:54] <kshishkov> should not be very hard [11:06:10] <in3xes> Ok. [11:07:03] <kshishkov> especially since it supports RGB32 already [11:07:12] <in3xes> What is the easiest in that list? [11:07:25] <av500> why the easiest? [11:07:33] <av500> you give up so early? :) [11:08:03] <in3xes> No [11:08:05] <cartman> mru: -Wl,-Bsymbolic is the right one I guess? [11:08:46] <kshishkov> in3xes: whatever you feel you'd like to do [11:10:10] <in3xes> I'll try, I still have many thing to understand. [11:10:11] <lyakh> for all the fate-experts here: what is http://pastebin.com/n3KxrT50 supposed to mean?... [11:11:51] <cartman> mru: one more thing is that neon_pixconv.S doesn't like Android toolchain: http://ffmpeg.pastebin.com/raw.php?i=rnVpGFba [11:12:04] <kshishkov> lyakh: probably you've forgotten to download some files or so [11:16:14] <mru> cartman: wrong -mcpu or -march [11:16:32] <mru> I suppose adding overrides in the .S file would make sense [11:18:42] <cartman> mru: it passes -march=armv5te by default [11:19:16] <mmu_man> But, I thought -march was to specify which of the 4 daughters... !? :p [11:20:10] <lyakh> kshishkov: that was an empty (actually non-existent) directory, the fate.sh script has created it from svn [11:20:28] <cartman> mru: -march=armv7-a fixes it indeed [11:20:31] <cartman> thanks [11:22:16] <mru> lyakh: svn? you should be using git by now [11:22:29] <cartman> mru: Shall I pass -mfpu=neon too? [11:22:38] <kierank> astrange: any idea why version.h doesn't appear in latest ffmpeg-mt [11:22:41] <mru> in other news, I've removed the fate slots using the wrong git repo from the view [11:22:53] <cartman> mru: I fixed mine [11:22:57] <mru> kierank: version.h is a generated file [11:23:04] <cartman> ah mine is there ;) [11:23:11] <lyakh> mru: thanks. that's what I use... ah, ok, maybe I should replace that in the fate config file... let me try [11:23:15] <kierank> mru: yeah, i mean it's generation [11:23:35] <kierank> its* [11:23:42] <mru> kierank: it's created when you run make [11:23:49] <mru> or is that what it's not for you? [11:24:02] <kierank> it's not created for some reason and make fails [11:24:08] <mru> hmm [11:24:13] <kierank> in ffmpeg-mt [11:24:17] <kierank> dunno about main [11:24:17] <mru> odd [11:24:22] <mru> main obviously works [11:24:26] <kierank> it was working yesterday [11:24:28] <mru> fate would complain otherwise [11:25:03] <mru> did you do something unusual? [11:25:10] <kierank> nope [11:25:11] <mru> like deleting files other than by make clean? [11:25:29] <lyakh> mru: kshishkov: same with git [11:25:45] <kierank> mru: sometimes i do a make distclean in windows, then compile the same repo in a linux vm [11:25:59] <kshishkov> git status [11:26:14] <mru> kierank: I strongly recommend building in a different directory than the source [11:26:42] <lyakh> ah, I think, those messages is not the actual problem... [11:26:45] <mmu_man> # Untracked IRC channel modified by a bunch of people. [11:28:18] <kierank> mru: ok [11:29:33] <DonDiego> should we call for more/new fate machines [11:29:55] <mru> let me see what I can rustle up at home [11:30:17] <mru> some virtual machines on the spare quad-core should do the trick [11:30:53] <mru> I'd rather not deal with windows though [11:31:01] <mru> so if someone can help out with that I'd be happy [11:31:40] <KotH> mru: what do you need? [11:31:51] * KotH has a xeon dualcore lying around, doing nothing [11:32:04] <superdump> mmu_man: ? [11:32:16] <mru> KotH: I need someone else to run fate on windows [11:32:24] <KotH> uh... [11:32:50] <KotH> if someone can tell me how to get a compilation enviroment on windows ... than i could do it [11:32:50] <mru> as I said, I can install some BSDs etc on a spare quad-core I have [11:32:58] <mru> KotH: therein lies the problem [11:32:59] <mmu_man> superdump: j/k on git status [11:33:01] <mru> it's a world of pain [11:33:06] <KotH> exactly [11:33:38] <mmu_man> KotH: actually I think it might be much simpler to crosscompile with mingw :D [11:33:42] * KotH wonders how people write code on windows w/o stabbing their eyes out, hacking their hands of and continusly banging their had against the desk [11:33:49] <mmu_man> at least this I managed to do for NetSurf once [11:34:12] <av500> I can donate a P3 laptop for some SSE0.5 testing [11:34:31] <thresh> i have a celeron laptop lying around as well [11:34:45] <mru> I have an old celeron desktop [11:34:47] * cartman already donates his MacBook Pro Corei7 2.66 [11:34:48] <mru> and a P4 [11:34:56] <mru> and a macbook [11:34:58] <av500> and I'm throwing away a K6-2 right now :) [11:35:12] <mmu_man> even managed to build Caloric, an ORIC emulator using SDL as a .exe [11:35:21] * kierank donates a calculator [11:35:55] <mmu_man> kierank: which model ? some are rare :p [11:36:10] <kierank> yeah i have a rare one [11:36:42] <spaam> av500: whY? give it to DonDiego .. he likes does amd k6 cpus.. [11:38:43] <{V}> KotH, one TCHAR at a time? [11:39:33] * av500 can donate http://www.vintagecalculators.com/html/sharp_qt-8d.html [11:39:49] <av500> it even has C style += -= etc.. [11:39:55] <mmu_man> gee, nice one [11:40:26] <av500> I bet mike will want to encode vp8 on it by hand.... [11:41:33] <kshishkov> it's faster than with xvp8 anyway [11:42:43] <mru> elenril: ping [11:42:58] <av500> mru: you need to meta-ping hime [11:43:00] <av500> -e [11:43:09] <mru> elenril: meta-ping [11:45:50] <in3xes> Ah, porting must be simpler. [11:46:07] <cartman> Android emulator is killing me [11:46:30] <av500> cartman: with -9? [11:46:45] <cartman> av500: yes :P [11:51:03] <Dark_Shikari> superdump: awesome email fyi [11:51:17] <superdump> thanks [11:51:25] <wbs> superdump: yes, very well written indeed [11:51:51] <cartman> av500: I guess the Android emulator doesn't support armv7 instructions [11:52:01] <wbs> cartman: don't think so [11:52:18] <cartman> it just hangs up loading [11:52:22] <cartman> gotta love Google [11:52:55] <av500> cartman: yep [11:53:01] <av500> emu is an armv5 [11:53:14] <mru> how useful [11:53:24] <cartman> bleh [11:53:25] <cartman> :( [11:53:52] <lu_zero> isn't possible to update to a more recent arm-qemu? [11:54:08] <cartman> they still ship gdb 6.x too ;) [11:54:35] <lu_zero> doesn't sound that up to date... [11:55:05] <mru> qemu is horribly broken for v7 anyway [11:55:28] <lu_zero> mru: less broken than before ^^; [11:55:35] <lu_zero> nearly usable [11:55:49] <mru> yeah, I suppose it's slowly getting fixed [11:55:54] <mru> but I still wouldn't trust it [11:55:58] <av500> mru: most ppl have given up on the emu as starting an app on a connected device is way faster [11:56:08] <thresh> +1 [11:56:15] <thresh> same for maemo/meego [11:56:22] <cartman> av500: the boss stole my tablet :P [11:56:26] <av500> thresh: its also emulated? [11:56:30] <mru> thresh: do you have access to the commit hooks on videolan.org? [11:56:42] <thresh> av500: yep, in Nokia Qt SDK for instance or Meego SDK. [11:56:48] <thresh> mru: I do [11:56:50] <av500> thresh: ic [11:56:57] <mru> cartman: tell your boss you can't do any work until you get it back [11:57:14] <mru> thresh: then can you please stop sending cia notices here for the ffmpeg repo there? [11:57:29] <mru> michael isn't in this channel anyway [11:57:40] <thresh> for maemo they had an abomination called scratchbox, but we call 'ÑÑÐ°ÑÐ±ÐŸÐºÑ' or shitbox as it what it really is [11:57:47] <cartman> mru: he already knows that :) [11:57:52] <cartman> thats how I slack :P [11:57:59] <thresh> mru: is there any othe place that uses CIA notifications except this channel? [11:58:06] <KotH> cartman: you're a true turkish! :) [11:58:14] <mru> thresh: scarebox is the canonical name for that thing [11:58:14] <cartman> KotH: lol [11:58:20] <cartman> KotH: I guess so :P [11:58:29] <cartman> KotH: if you treat me bad I slack :P [11:58:50] <KotH> cartman: if my boss would tread me bad, i'd be gone ;) [11:58:50] <mru> thresh: now we're getting cia notices from two repos here [11:58:52] <mru> it's confusing [11:58:58] <cartman> KotH: I am going man :) [11:58:58] <kshishkov> thresh: /dev/null, /dev/ass, #ffmpeg-devel-for-mn [11:58:59] <mru> KotH: +1 [11:59:07] <mru> cartman: :) [11:59:07] <cartman> things take time [11:59:27] <cartman> I'll be av500's neighbour [11:59:30] <cartman> possibly :P [11:59:35] * KotH quit his last job for exactly that reason.. before having a new one [12:01:19] <Compn> arpi makes his appearance [12:01:25] <Compn> on mplayer-dev-eng [12:01:31] <cartman> Compn: for the lolz [12:01:50] <KotH> cartman: taht's "lulz" :) [12:01:56] <cartman> KotH: doh [12:01:56] <cartman> :D [12:02:51] <mru> it's "for teh lulz" [12:03:04] <av500> does mplayer have another list for flames or is it all in irc? [12:03:18] <mru> there was an mplayer-flames list at some point [12:03:27] <kshishkov> Compn: if his replies are always that correct no wonder he's not missed [12:05:30] <thresh> mru: done [12:06:26] <Compn> kshishkov : well, breaking mplayer compilation is against mplayer policy. probably DonDiego knows this ... :p [12:06:27] <Compn> ehe [12:06:55] <kshishkov> Compn: I thought that's the thing you should do regularly [12:07:05] <Compn> huh? [12:07:20] <mru> Compn: DonDiego replaced an svn external with the real deal [12:07:25] <mru> that broke svn up in existing checkouts [12:07:29] <mru> another weakness of svn [12:07:32] <Compn> ah [12:07:52] <Compn> yes, that would be the problem then [12:08:12] <mru> svn can't cope with a directory being anything other than created or deleted in a single commit [12:08:16] <Compn> would keeping a read only libswscale svn open for older revisions work ? [12:08:23] <mru> replacinga dir witha file is impossible and vice versa [12:08:32] <mru> and apparently the same holds for externals [12:08:54] <mru> Compn: waste of effort [12:09:01] <mru> ffmpeg svn will go away [12:09:33] * lu_zero is back [12:09:39] <lu_zero> anything happened lately? [12:09:51] <mru> patches, reviews, nothing exciting [12:09:52] <Compn> lu_zero : arpi commented on dev-eng [12:10:00] <kshishkov> mru: why? You can keep it somewhere in museum [12:10:01] <cartman> does emu supports OpenGL ES? [12:10:09] <wbs> cartman: 1.x yes [12:10:29] <mru> how useful [12:10:37] <cartman> wbs: if I crash the emu I guess its not 1.x :D [12:10:56] <mru> 1.x is barely usable [12:11:00] <mru> if that [12:11:09] <lu_zero> s/barely/non/ [12:11:12] <wbs> cartman: there were some quite basic bugs with lighting and such that I fixed (fixed in the eclair emulator iirc), but if you're not actually doing 3d stuff I don't think you'll run into those issues :-) [12:11:17] <mru> so if your code does anything useful, it's 2.x [12:11:40] <cartman> mru: yeah [12:11:44] <cartman> man Android is a joke :D [12:11:48] <cartman> mostly :P [12:12:00] * mru as usual pretends to know stuff [12:12:10] <mru> one day I'll be found out... [12:12:25] <mru> but by then I'll _rich_, mwaahahahahaha [12:12:38] <lu_zero> mru: 1.0 is useful to port stuff from old opengl [12:12:39] <kshishkov> mru: I won't live till FFmpeg 2.x I fear :( [12:13:03] <lu_zero> under the hood gles 1 uses gles 2 in most implementations [12:13:29] <mru> anything else would insane [12:13:32] <mru> +be [12:13:43] <cartman> mru: lol [12:13:50] <lu_zero> and gles 2 uses some kind of online shader compiler written in C++ making your whole application funny if you are using C++ already [12:13:59] <lu_zero> </rant> [12:14:23] <mru> lu_zero: the sgx gles you mean? [12:14:29] <lu_zero> any [12:14:32] <lu_zero> mesa included now [12:14:39] <mru> surely it's possible to implement gles without using c++ [12:14:59] <mru> what of nvidia? [12:15:01] * lu_zero should find a month or two to rewrite the mesa compiler in plain C ... [12:15:08] <lu_zero> C++ iirc [12:15:13] <mru> probably c++ too, but I bet it's a different one [12:15:18] <lu_zero> C++ as well for AMD [12:15:27] <wbs> lu_zero: in which way does that interfer with your own app? [12:15:45] <mru> wbs: poorly written in some way I guess [12:15:55] <lu_zero> wbs: if you have your app using C++ already (think Qt) [12:15:56] <mru> allowing c++ uglies to leak outside the api [12:16:06] <lu_zero> mru: worse [12:16:20] <wbs> lu_zero: yes, but what would the problem be? clashes with different c++ runtimes, or what? [12:16:27] <lu_zero> wbs: yup [12:16:33] <wbs> mmkay [12:16:37] <lu_zero> and if you are using link-once stuff [12:16:52] <lu_zero> you might get some _really_ fun stuff [12:16:58] <mru> they include their own runtime and export the symbols? [12:17:17] <lu_zero> mru: by definition C++ doesn't have the problem of exported symbols [12:17:26] <mru> of course it does [12:17:33] <lu_zero> the problem is the runtime [12:17:33] <mru> names can always clash [12:18:04] <lu_zero> mru: you can have fun ABI stuff due libstdc++ being not always perfectly versioned [12:18:24] <cartman> so I can't really work without a real device [12:18:32] <cartman> sob no more, slack++ [12:18:33] <mru> if a .so included an entirely self-contained runtime with nothing visible from the outside, only exposing a C api, the rest of the app can safely use another c++ runtime [12:18:43] <lu_zero> mru: nope [12:18:50] <mru> why not? [12:18:58] <mru> c++ is not magic [12:18:58] <lu_zero> because internally the C++ runtimes will stomp on each other [12:19:03] <mru> how can they? [12:19:09] <mru> they exist in different realities [12:19:33] <lu_zero> link-once (so Diego explained me) would override stuff [12:19:37] <mru> it _could_ be done that way [12:19:44] <mru> not saying it is [12:19:55] <mru> since you have problems, it is obviously not [12:20:20] <lu_zero> and there are some details regarding stuff it should be unique e.g. exception handler and vtable things [12:20:34] <lu_zero> I didn't want to touch nor be aware of those stuff [12:20:38] <mru> lu_zero: all that can be done internally in the .so [12:20:44] <mru> nothing magical [12:21:05] <lu_zero> the problem isn't if your C app uses the gles that has a compiler written in C++ [12:21:09] <mru> when linking the .so, you'd have to use the static libgcc, libgcc_eh etc [12:21:16] <mru> and libstdc++ [12:21:29] <mru> then make sure _nothing_ from those make it into the symbol table [12:21:36] <lu_zero> or you build everything shared and link your C++ app with the same C++ runtime used [12:21:37] <mru> and use -Bsymbolic on the whole thing [12:21:37] <cartman> -ffreestanding ? [12:21:57] <lu_zero> mru: that was what I considered the solution [12:22:17] <lu_zero> asked to C++/ABI informed people and they told me it would have issues =| [12:22:34] <mru> what they've probably done is include a c++ runtime and exported its symbols [12:23:02] <mru> or rather, they included the subset of the c++ runtime the need and export it [12:23:22] <mru> so when you then pick up the system shared c++ runtime, you get a frankenlink [12:23:49] <mru> due to some symbols being versioned or named differently and some not [12:24:15] <mru> the same could happen with any library [12:24:54] <lu_zero> anyway at least for mesa I hope it could be solved =P [12:25:13] <mru> there are two solutions [12:25:29] <mru> 1) use only the shared system runtime [12:25:37] <mru> 2) fully internalise the one in the lib [12:25:55] <mru> 1 is not viable for binary distribution onto different systems of course [12:29:55] <lu_zero> 1 is what is used right now ^^; [12:31:45] <superdump> i don't know if it's been discussed but is there any chance of doing some kind of quick port of the soc svn repos to git? [12:32:34] <kshishkov> quick - yes, proper - no [12:32:34] <superdump> or getting the svn web interface back online :) [12:32:49] <kshishkov> harddrives would be against that [12:33:23] <lu_zero> superdump: which soc are you interested in? [12:33:40] <mru> a quick git-svn conversion of just the soc bits shouldn't take too long [12:33:46] <andoma> mru: i'm compiling ffmpeg with the ps3 homebrew toolchain (gcc 4.5.2 with newlib 19.0) the aixdesc ABI prefixes external functions with a '.' but does not do anything with data, so ffmpeg's configure misdetects stuff in the symbol mangling check [12:34:14] <mru> andoma: it's more complicated than that [12:34:17] <andoma> ugh [12:34:26] <andoma> ? [12:34:27] <superdump> lu_zero: aac - a guy just emailed me about working on LTP for a small task for qualification for this year's google soc [12:34:30] <superdump> peloverde: ^ [12:34:48] <mru> andoma: the detection might be broken though [12:35:18] <superdump> andoma: you have a ps3 now? [12:35:23] <andoma> superdump: yup [12:35:28] <superdump> hehe [12:35:33] <cartman> andoma: r00ted yet? [12:35:35] <andoma> no games, just jailbreaked :) [12:35:38] <andoma> cartman: ofcourse [12:35:42] <mru> andoma: can you please post config.log and full nm output from the .o used for detecting prefixes? [12:35:44] <DonDiego> should i write a reply to michael as well? [12:36:05] <superdump> if you feel you have something to say, sure [12:36:18] <kierank> how did michael become leader anyway? [12:36:25] <andoma> mru: i'll do that once I get home to my desktop (don't have the setup here at work) [12:36:27] <mru> andoma: ppc64 functions export two names, one with ., the other w/o [12:36:30] <superdump> it just kind of happened i think [12:36:32] <superdump> over time [12:36:50] <superdump> but maybe he was leader before i started working on ffmpeg so i don't really know [12:36:53] <mru> the dotless one includes full gp setup [12:36:59] <andoma> ah [12:36:59] <mru> the dotted one skips that [12:37:21] <mru> when linking, the linker chooses one depending on whether the gp needs updating or not [12:37:37] <mru> so no prefix is correct [12:38:25] <lu_zero> superdump: I'd forward them on gitorious or github [12:38:38] <lu_zero> probably github or gitorious might even help us to set it up [12:38:45] <mru> superdump: most of the devs active around 2002-2003 are gone [12:38:51] <andoma> mru: sounds like the linker is broken then? [12:39:03] <mru> andoma: no, just the detection in the configure script [12:39:09] <mru> I'll need to improve it [12:39:26] <lu_zero> andoma: ffmpeg on ps3 bare metal (lv1?)? [12:39:36] <andoma> lu_zero: yupp [12:39:43] <lu_zero> sounds... gory [12:39:45] <andoma> well not exactly ffmpeg binary [12:39:50] <andoma> but rather a mediaplayer [12:40:08] <mru> superdump: there was a transition and michael was probably the most active (and generally knowledgable about ffmpeg) to bridge the gap [12:40:22] <mru> superdump: so the new devs just assumed he was some kind of leader [12:40:23] <mru> more or less [12:40:27] <superdump> mru: i had that impression [12:40:37] <mru> at least that's how I remember things [12:40:42] <kierank> did you consider asking him to take a sabattical from leading [12:40:47] <cartman> mru: I also remember so... [12:40:49] <superdump> i did [12:41:07] <mru> cartman: you were around back then too? [12:41:18] <cartman> mru: I was lurking since 2001 [12:41:19] <cartman> :P [12:41:19] <superdump> or well, i considered presenting the situation to him basically as i stated in the last paragraph of my mail [12:41:21] <thresh> andoma: which firmware and toolchain you're using? [12:41:40] <superdump> as well as the support for the new way to run things [12:41:59] <andoma> thresh: 3.55 + geohot jailbreak w/ ps1lght [12:42:09] <thresh> i see [12:42:15] <superdump> i hoped he would see the support, accept the situation and maybe even embrace it to do some stuff he found interesting [12:42:18] <cartman> andoma: does it run homebrew yet? [12:42:21] <superdump> but i have rose-tinted glasses [12:42:34] <andoma> cartman: i'm porting my mediaplayer (http://www.lonelycoder.com/showtime) [12:42:35] <superdump> or so i'm lead to believe sometimes :) [12:42:45] <andoma> it kinda works ... it can stream music from the network .. [12:43:03] <andoma> i've got some of the GPU things wokring.. framebuffer works. Vertex-shaders .. [12:43:08] <cartman> andoma: nice [12:43:10] <andoma> but it needs a bit more work [12:43:34] <andoma> pslight recently got support for fragmentshaders so i started on that yesterday night [12:45:13] <lu_zero> andoma: linux / x11 support got improved? [12:45:24] <andoma> lu_zero: on the ps3? [12:45:36] <lu_zero> yup [12:45:38] <kierank> is the ps3 fully rooted or do you still run on top of the hypervisor? [12:46:10] <spaam> andoma: can you use spotify with it? [12:46:12] <andoma> no idea .. i don't follow the linux track thay close [12:46:24] <lu_zero> had been ages since I booted the ps3 ... [12:46:28] <lu_zero> (too busy) [12:46:38] * thresh only uses one application on PS3 since november [12:46:55] <andoma> spaam: yeah.. i theory .. although i find it hard that spotify would release a binary version of libspotify for ps3 homebrew [12:47:10] <andoma> sony (the record label) might not like that [12:47:16] <kierank> lol [12:47:44] <mru> sony music and SCE are totally different companies really [12:47:45] <andoma> kierank: the app runs with lv2 as a kernel [12:47:51] <andoma> mru: yeah i know . but still :) [12:48:00] <andoma> they can probably talk to each other if need may be [12:48:06] <mru> yeah [12:48:28] <mru> console and games divisions are closer though iiuc [12:48:39] <mru> they're both SCE, I think [12:49:56] <andoma> the lv2 kernel provides threads, mutexes, etc and io/network access .. but when it comes to the RSX (the GPU) you're down right to the metal [12:50:29] <cartman> mru: btw, I found some code for YUV420->RGB565, see https://github.com/cartman/glbuffer/blob/master/jni/colorconvert.c [12:50:52] <mru> ugh, .c [12:51:05] <cartman> straight out of Google's opencore :) [12:52:02] <kierank> lol namtrac heavy industries [12:52:06] <cartman> kierank: :D [12:52:12] <superdump> are there any distributions of ffmpeg dll binaries for windows? [12:52:17] <cartman> man I was heavy :P [12:52:32] <lu_zero> cartman: looks normal unaccelerated code? [12:52:39] <lu_zero> superdump: ramiro's I think [12:52:41] <superdump> http://ffmpeg.arrozcru.org/ <--- there perhaps? [12:53:02] <cartman> lu_zero: I am not sure if it does what its supposed to do but some Google search gave me that :) [12:53:06] * mru looks at the code and weeps [12:53:12] <mru> .j [12:53:16] <mru> oops [12:53:24] <mru> lu_zero: that looks worse than unaccelerated [12:53:32] <mru> it's _unoptimised_ [12:54:26] <cartman> for now its OK if it does the conversion without a bug :) [12:57:02] <cartman> just one question [12:57:18] <cartman> yuv data is in uint8_t** src and rgb data is uint8_t* dst [12:57:19] <lu_zero> which one? [12:57:29] <cartman> how do I know what size dst must be? [12:57:34] <cartman> for memory allocation [12:57:39] <kshishkov> depends on rgb format [12:57:44] <cartman> kshishkov: 565 [12:57:46] <cartman> in my case [12:57:55] <lu_zero> each pixel 16bit ? [12:57:55] <kshishkov> 2*stride*height [12:58:17] <cartman> lu_zero: that I am not sure [12:58:19] <kshishkov> or even simply stride*height [12:58:33] <lu_zero> 565 should ^^; [12:58:40] <lu_zero> btw [12:58:54] <lu_zero> why aren't you using swscale? [12:59:11] <kshishkov> because omapfbplay doesn't [12:59:32] <cartman> lu_zero: I failed to find an example conversion too, also what kshishkov said :) [12:59:38] <lu_zero> omapfbplay does use anything? [12:59:44] <cartman> ffmpeg ;> [12:59:51] <lu_zero> cartman: ffplay should give you an example [12:59:52] <kshishkov> lu_zero: it uses mru's knowledge [13:00:16] <cartman> is "stride" == line size? [13:00:50] <kshishkov> yep, in bytes [13:01:00] <cartman> ok, thanks :) [13:01:33] <cartman> kshishkov: looking at frame.h in omapfbplay linesize is a 3 element array, each component has its own linesize? [13:02:19] <mru> yes [13:02:39] <cartman> mru: which one do I use to calculate the destionation RGB buffer? :) [13:02:52] <kshishkov> the zeroeth one, of course [13:03:03] <mru> ack [13:03:16] <cartman> okies [13:03:22] <mru> but you're doing it wrong [13:03:29] <cartman> mru: why? [13:03:44] <mru> you should allocate anything you need in open() or enable() [13:03:52] <cartman> mru: I'll do so :) [13:04:00] <cartman> I am not allocating anything atm. :) [13:04:28] <mru> then why are you asking how much to allocate? [13:04:32] <cartman> mru: how would I go around calculating frame height? [13:04:38] <cartman> mru: because I'll add allocation now :) [13:04:50] <cartman> the other find_driver bug didn't let me move forward yet [13:06:03] <cartman> mru: ah frame_format have it all [13:06:46] <mru> it's a bit of a tangle, I admit [13:07:11] <cartman> looks good in _enable [13:07:20] <cartman> ff->height*ff_ystride [13:07:26] <cartman> s/_/-> [13:07:39] <elenril> mru: meta-pong [13:08:06] <cartman> kshishkov, mru , lu_zero thanks (another round of questions :)) [13:08:21] <mru> elenril: mumble mumble id3 patches mumble [13:08:33] <mru> elenril: let me remind myself what I wanted to ask [13:09:27] <elenril> yes, i fail at english [13:09:31] <elenril> i meant prepend [13:09:54] <mru> and the first patch, is that function not useful at all outside that file? [13:09:57] <kshishkov> elenril: you fail English? That's unpossible! [13:10:01] <mru> or why was it external in the first place? [13:10:07] <elenril> no idea [13:10:15] <elenril> it might've been used somewhere at some point [13:10:23] <elenril> but now it's only used in id3v2.c [13:10:28] <elenril> feel free to git grep [13:10:51] <lu_zero> Dark_Shikari: which x264 preset works better on arm in your experience? [13:11:01] <cartman> lu_zero, wbs any idea why ndk-build doesn't respect the order of files in LOCAL_SRC_FILES while _linking_ ? [13:11:10] <lu_zero> the superfast preset is enough [13:11:18] <lu_zero> cartman: how are you linking? [13:11:33] <cartman> lu_zero: it just orders the object unrelated to the src order [13:11:34] <wbs> cartman: hmm, does the order of object files matter? [13:11:36] <mru> elenril: I trust you if you say it's not used [13:11:44] <cartman> wbs: yes, for mru's magic it does :) [13:11:49] * elenril wouldn't trust himself [13:11:51] <mru> elenril: I was just wondering if it was meaningless to use it directly [13:11:57] <elenril> but it compiles [13:12:03] <cartman> lu_zero: I am not doing anything special [13:12:09] <cartman> it just links to a shared lib. [13:12:25] <mru> cartman: are you not using my makefile? [13:12:32] <cartman> mru: nope [13:12:32] <mru> you _must_ use my makefile [13:12:36] <mru> otherwise it will fail [13:12:43] <mru> it has the magic [13:12:52] <cartman> mru: the order of objects is the magic, no? [13:13:03] <mru> yes [13:13:07] <cartman> see :) [13:13:15] <mru> I suppose replicating the exact order is enough [13:13:18] <cartman> ndk-build is getting in my though [13:13:23] <cartman> mru: I manually link atm. [13:13:24] <mru> but apparently droidmake doesn't let you do that [13:13:27] <cartman> to workaround ndk crap [13:13:37] <kshishkov> lu_zero: got myself efika-mx, any tips about it? [13:13:46] <cartman> mru: seems so it puts assembly files at the end [13:14:30] <mru> do droidmakefiles list source files rather than objects? [13:14:38] <mru> that is so stupid [13:14:42] <_av500_> lu_zero: wrt efika [13:14:47] <cartman> mru: wut? [13:14:50] <lu_zero> kshishkov: do you have already the updated u-boot [13:15:07] <_av500_> lu_zero: lol [13:15:17] <lu_zero> I'm running to have lunch now I can give you a walkthrough [13:15:20] <kshishkov> lu_zero: nope, I'm going to play with it at weekend [13:15:26] <_av500_> that is so #beagle [13:15:26] <lu_zero> it should be pretty straightforward [13:15:42] <lu_zero> and I could send you my gentoo image if you want [13:15:59] <lu_zero> (and point you to the kernel sources and such) [13:16:00] <mru> cartman: in the android build system, do you give it a list of source files to build? [13:16:03] <lu_zero> brb [13:16:07] <cartman> mru: yes [13:16:09] <mru> cartman: and not a list of object files it should build [13:16:12] <mru> cartman: that's stupid [13:16:19] <cartman> mru: yes again [13:16:20] <_av500_> yes [13:16:28] <_av500_> stoopid [13:16:46] <mru> it means there has to some convoluted make variable munging to turn source names into object names so make can figure out the reverse and build them [13:16:47] <cartman> why does it reorder shit I don't know [13:17:11] <cartman> mru: ah so I should say give it *.o files instead of *.c or *.S ? [13:17:33] <mru> because there's probably something like C_OBJS = $(patsubst $(filter $(SRC),%.c),%.c,%.o) somewhere [13:17:38] <mru> etc for other suffixes [13:18:01] <kshishkov> lu_zero: thanks, I can figure out that stuff by myself. But I guess from your reply it's not something outstandingly bad ;). [13:18:49] <cartman> /usr/local/android-ndk-r5/build/core/definitions.mk: _OBJ_ASM_ORIGINAL := $$(patsubst %.o,%.s,$$(_ORG_OBJ)) [13:18:52] <cartman> /usr/local/android-ndk-r5/build/core/definitions.mk: _OBJ_ASM_FILTERED := $$(patsubst %.o,%.filtered.s,$$(_ORG_OBJ)) [13:18:55] <cartman> mru: ^^ [13:20:37] <mru> and then OBJS = $(C_OBJS) $(S_OBJS) ... [13:20:37] <mru> make then takes this list and searches for pattern rules and corresponding source files until it finds a match [13:20:37] <mru> so it's much simpler to just list the object files directly [13:20:38] <mru> cartman: if the build system is set up to take lists of source files there's nothing _you_ can do [13:20:38] <mru> short of replacing the whole thing [13:20:38] <mru> or working on something less annoying entirely [13:20:58] <cartman> mru: I see [13:21:17] <mru> oooh, worse than I imagined [13:21:35] <mru> there's an eval somewhere in there too [13:21:46] <cartman> mru: add magic-head.S to ffmpeg so they'll have to fix their crap to support it ;) [13:21:55] <mru> and gratuituous _ prefixes [13:23:30] <cartman> I will use my relink.sh crap for now [13:23:53] <mru> at least you found the cause of the problem [13:24:01] <cartman> mru: and reported too but [13:24:12] <cartman> David Turner says it won't reorder them [13:24:29] <cartman> contary to what I see [13:25:00] <mru> it probably doesn't reorder .c files relative to each other [13:25:17] <cartman> moves the *.S files at the end [13:25:32] <cartman> yeah *.c files are ordered but not .S [13:25:46] <mru> it orders *.c before *.S [13:25:55] <mru> relative order within those groups is probably maintained [13:26:01] <cartman> seems so [13:27:25] <mru> btw, notice how michael goes on a rampage against me [13:27:54] <cartman> I noticed how he dumped mplayer filter code in ffmpeg [13:28:06] <mru> I knew that was coming [13:28:21] * elenril sighs [13:29:39] <kshishkov> mru: you can just ignore his mails without patches attached, procmail is your friend ;) [13:29:43] <BBB> mru: let it go, for now... the comment was unnecessary [13:30:07] <mru> I'm not going to reply [13:30:55] <kshishkov> maybe you shouldn't have read it too [13:33:03] <kshishkov> mru: obligatory non-XKCD quote http://dilbert.com/strips/comic/2010-12-13/ [13:33:53] <mru> kshishkov: oh please, use dilbert.com/fast [13:34:15] <kshishkov> mru: noted [13:44:20] <cartman> didn't know about /fast, no Flash yey [13:45:16] <mru> http://news.ycombinator.com/item?id=2123511 [13:45:20] * kshishkov has Flash installed only one one of his computers so almost no concern [13:45:44] <cartman> I knew there is a reason to hate Uncle Sam [13:46:13] <kshishkov> thresh: http://static.businessinsider.com/image/4d382fad49e2aec008100000-590/the-pe… [13:46:28] <thresh> kshishkov: ÐÐžÑÐ³ÐŸÐ»ÑÑÐžÐœÐŸÐ¹ Ð¿ÐŸÐ¿Ð°ÑÐžÐ²Ð°ÐµÑ. [13:47:10] <kshishkov> cartman: there's none. He's your best friend. US even produces Camel cigarettes to commemorate American-Turkish friendship (really!) [13:47:35] <kshishkov> thresh: Ð° ÑÑ ÐŸÑÐžÑÐžÐ°Ð»ÑÐœÐŸÐµ Ð»ÐŸÐ³ÐŸ Ð²ÐžÐŽÐµÐ»? ÐÐœÐŸ ÐœÐµ Ð¿ÑÐŸÑÑÐŸ Ð¿ÐŸÐ¿Ð°ÑÐžÐ²Ð°ÐµÑ [13:48:39] <cartman> kshishkov: bleh :P [13:49:18] <kshishkov> cartman: well, it improves official logo a bit [13:49:43] <cartman> http://wikileaks.ch/static/gfx/graphic.png [13:49:52] <cartman> Check the second embassy on the left [13:50:25] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r75aded8328 ffmpeg/libavformat/id3v2.c: [13:50:25] <CIA-29> ffmpeg: id3v2: don't overwrite existing tags [13:50:25] <CIA-29> ffmpeg: Apparently some broken taggers prepend a new ID3v2 tag leaving the [13:50:25] <CIA-29> ffmpeg: existing one intact. Our parser currently reads all tags and overwrites [13:50:25] <CIA-29> ffmpeg: existing values with supposedly outdated ones. [13:50:26] <CIA-29> ffmpeg: fixes issue2419 [13:50:27] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:50:27] <CIA-29> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r46a2da7698 ffmpeg/libavformat/ (id3v2.c id3v2.h): [13:50:28] <CIA-29> ffmpeg: id3v2: make ff_id3v2_parse static [13:50:28] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:50:29] <CIA-29> ffmpeg: Georgi Chorbadzhiyski <gf(a)unixsol.org> master * rc0dd565304 ffmpeg/cmdutils.c: (log message trimmed) [13:50:31] <CIA-29> ffmpeg: libavcodec minor version is > 99 so fix the formating [13:50:31] <CIA-29> ffmpeg: libavcodec minor version is > 99 so when printing the library versions [13:50:32] <CIA-29> ffmpeg: the output is a little bit broken: [13:50:32] <CIA-29> ffmpeg: libavutil 50. 36. 0 / 50.36. 0 [13:50:33] <CIA-29> ffmpeg: libavcore 0. 16. 1 / 0.16. 1 [13:50:34] <CIA-29> ffmpeg: libavcodec 52.108. 0 / 52.108. 0 [13:59:22] <cartman> mru: since the boss still didn't give me my tablet back, let me ask you how is Bsymbolic will help with my ofbp_codec_start problem? [13:59:34] <cartman> mru: google is not helpful I tried [13:59:35] <mru> it won't [13:59:50] <cartman> mru: why do I use it then? :) [13:59:53] <mru> I was just stabbing in the dark [14:00:03] <mru> but it's a good thing to use regardless [14:00:23] <mru> the real problem turned out to be object order, no? [14:00:23] <cartman> mru: might it be due to the fact that I build a shared library not an application? [14:00:32] <cartman> mru: nope, object order was fine :) [14:00:36] <cartman> I manually fixed that [14:00:39] <mru> oh, it's still not working? [14:00:52] <cartman> mru: it wasn't working after I fixed the order [14:00:56] <cartman> didn't try Bsymbolic yet [14:01:23] <cartman> but avcodec.o has ofbp_codec section [14:02:10] <wbs> anyone who happens to have a htc desire Z or HD (not the normal desire) that I could do some remote testing on? [14:02:49] <mru> cartman: pastebin readelf -a on your .so [14:03:00] <cartman> mru: ok [14:05:32] <cartman> mru: http://cekirdek.pardus.org.tr/~ismail/readelf.txt [14:05:54] <mru> ouch, that includes all of ffmpeg [14:06:05] <cartman> static linking *cough* [14:06:09] <mru> yeah [14:06:19] <cartman> 1114: 006556f8 0 OBJECT GLOBAL DEFAULT 16 ofbp_codec_start [14:06:21] <mru> oh well, the info I was looking for is still in there [14:08:21] <cartman> mru: and? :) [14:10:51] <mru> cartman: looks like your compiler is ignoring attribute(used) [14:11:03] <cartman> hmmm [14:11:40] <cartman> mru: I see you use it in util.h [14:11:48] <cartman> but this is just gcc hmmpf [14:11:59] <mru> no, it's _android_ gcc [14:12:14] <mru> do a normal arm build and compare the symbol tables [14:12:24] <mru> you'll see ofbp_codec_avcodec in there too then [14:12:41] <cartman> mru: ah so I am missing ofbp_codec_avcodec symbol? [14:12:42] <cartman> only [14:13:07] <mru> and the other magic ones [14:13:35] <cartman> mru: allright [14:13:37] <cartman> thanks [14:13:54] <mru> try removing the static keywords in the DRIVER macro [14:14:11] <mru> at least the middle one [14:14:52] <cartman> mru: yep works [14:15:06] <cartman> mru: shall I scream that such a basic thing doesn't work? [14:15:14] <mru> yes [14:15:33] <cartman> mru: thank you :) [14:15:48] <mru> np [14:16:05] <cartman> mru: ah Android also doesn't have posix_memalign, I replaced it with a memalign call fwiw [14:16:24] <mru> that should be detected by configure [14:16:35] <mru> oh, in omapfbplay [14:16:41] <mru> I forgot I used it there [14:16:50] <mru> and this is #ffmpeg-devel ... [14:17:06] <mru> I suggest you bitch about that as well [14:17:13] <cartman> mru: #omapfbplay-dev ? :) [14:17:39] <mru> I've been thinking of renaming the thing actually [14:17:43] <mru> call it ofbp or something [14:17:53] <mru> it's not at all omap-specific anymore [14:17:55] <cartman> mru: makes sense :) [14:18:28] <cartman> now hopefully this thing will crash somewhere in my code now :D [14:20:19] <cartman> I guess CodeSourcery gcc could be made to work on Android [14:20:45] <mru> any gcc will work [14:21:00] <cartman> mru: any gcc with arm support will do? [14:21:05] <mru> should [14:21:08] <mru> android uses eabi [14:21:22] <cartman> hmmpf :( [14:21:23] <cartman> :) [14:21:27] <merbzt1> jannau: you drive a train? neat [14:21:29] <mru> use their linker though [14:22:08] <cartman> mru: okies [14:22:32] <kshishkov> merbzt1: probably it's calced from their expression "fahren mit" but you don't care ;) [14:23:58] <kshishkov> now to find an hotel there and get a briefcase of money and platinum credit card somewhere - it's Brussels after all [14:41:38] <cartman> mru: indeed CodeSourcery gcc works as expected with the static keyword [14:48:09] <jannau> av500: full of fail: http://www.heise.de/newsticker/meldung/Entwicklung-der-Codec-Bibliothek-FFm… [14:48:40] <jannau> "Hinweis auf Stefan Niedermayer als Projektleiter" [14:48:47] <mru> lol [14:49:18] <av500> we all know that attila is bundesprojektkanzler now [14:49:28] <thresh> yeah, everyone know he was a ProjektFuehrer [14:50:01] <lyakh> ok, got fate running... so far all tests fail:) I think, I'll document fate setup for cross-build / cross-testing, do we want it somewhere centrally, or I can just post it to my blog;) [14:50:19] <mru> lyakh: what are you running it on? [14:50:31] <lyakh> mru: sh7724 [14:50:44] <mru> hmm, sh4 isn't very well tested I guess [14:50:44] <av500> lyakh: I have some SH1 EVMs :) [14:50:55] <mru> I have an sh4 board but no jtag to get it running [14:51:07] <lyakh> mru: I guess your guess is right;) [14:51:07] <mru> st7109 chip [14:51:20] <av500> mru: I have that [14:51:23] <av500> and the jtag [14:51:27] <lyakh> av500: sh1... don't think it's going to help much here;) [14:51:36] <av500> lyakh: cmon, be creative [14:51:42] <lyakh> lol [14:51:47] <mru> lyakh: use 4 of them [14:51:55] <mru> then you'll have an shshshsh4 [14:52:00] <av500> mru: for a combined 1MB of ram, yes [14:52:03] <mru> or is that an sssshhhh4 [14:52:14] <lyakh> sh4^4 [14:52:19] <mru> the successor to ssssssse3 [14:52:48] <mru> av500: you have an st microconnect or similar? [14:52:58] <av500> mru: er, no idea [14:53:01] <av500> I have something [14:53:28] <lyakh> so, why are they failing? is there a timeout? or precision insufficient? or little RAM? [14:53:32] <lyakh> error 127 [14:53:43] <mru> that's command not found [14:53:57] <lyakh> EKEYEXPIRED:) [14:54:04] <mru> what command is it actually trying to run? [14:54:07] <mru> make fate V=1 [14:54:38] <lyakh> what command not found?... what PATH is it getting? not like for the usual shell? /usr/local/bin? [14:54:50] <mru> that's what I'm trying to figure out [14:54:53] <av500> mru: yup, microconnect [14:55:00] <mru> but I need the output of "make fate V=1" [14:55:02] <mru> av500: v2? [14:55:14] <mru> iirc that's required for the 7109 [14:55:30] <av500> well, it was given with the 7109 [14:55:44] <lyakh> yes, but wait... I have an idea...:) [14:55:59] <mru> av500: what does it look like? grey plastic or white metal with black front panel? [14:56:10] <av500> metal [14:56:35] <thresh> av500: so, what about 101? :) [14:56:36] <mru> what kind of connector? IDC or something scsi-like? [14:57:13] <av500> for jtag? 29pin idc [14:57:16] <av500> 28 [14:57:31] <mru> huge brick of a psu? [14:57:36] <av500> u bet [14:57:41] <mru> it's a v1 then [14:57:54] <av500> :( [14:57:59] <av500> 8.5A [14:58:11] <mru> if it came with the board, it must be good enough [14:59:09] <av500> we never even powered it [14:59:14] <cartman> wbs: could you remind me where was AOSP bugzilla? [14:59:23] <mru> av500: wtf do you have it for then? [14:59:29] <av500> mru: flickr? [14:59:35] <mru> fair enough [14:59:42] <av500> mru: remeber the tale of the 2 laptops [14:59:46] <av500> ppl tend to leave stuff here [14:59:49] <wbs> cartman: http://code.google.com/p/android/issues/list [15:00:07] <cartman> wbs: thanks [15:00:18] <av500> wbs: for iOS is ../plist? [15:00:28] <wbs> av500: lol [15:00:29] <cartman> wbs: ah I was looking for something NDK specific one [15:00:54] <wbs> cartman: dunno if that fits there.. or just mail to android-ndk and nag, or submit a patch in gerrit [15:01:05] <cartman> wbs: I see [15:01:08] <cartman> good old ways :p [15:01:49] <lyakh> does it need samples on the host and transfers them to the target, or do they have to be on the target? [15:02:27] * kierank lols at michaels fork [15:02:33] <mru> lyakh: simplest is to nfs-mount build and samples dirs from host to target [15:02:47] <mru> lyakh: at the same path [15:03:01] <lyakh> aha, so, samples too... but that path in the config - is it for both?... oooh.... [15:03:22] <mru> if you mount the samples at the same location on both it will work [15:03:35] <lyakh> can it work if locations differ?;) [15:03:35] <mru> the target also needs r/w access to the build dir [15:03:43] <lyakh> damn... [15:03:44] <mru> lyakh: not presently [15:03:51] <lyakh> that's all dead-obvious [15:04:13] <mru> the build tree can be mounted at different paths [15:04:20] <benoit-> moin [15:04:25] <mru> hi benoit- [15:05:12] <benoit-> wow... It's been a while since I last came. [15:05:32] * mru chooses not to interpret that imaginatively [15:05:36] <benoit-> I totally missed everything in the last months... at least I had things to read when I came back! [15:05:38] <benoit-> heh [15:05:38] <andoma> lol [15:05:41] <benoit-> hehe [15:06:34] <DonDiego> benoit-: hi [15:06:45] <DonDiego> benoit-: well, i guess there are news... [15:07:21] <benoit-> I'm trying to integrate them [15:10:56] <lyakh> ok, so, I need the install path, build dir, and samples nfs-mounted. install path is ok, samples have to be at the same location and specified in "samples=" config var. build on host is specified in "work_dir=", where is it specified for the target? [15:11:18] <mru> you don't need to install at all [15:11:29] <mru> the tests run out of the build tree [15:11:46] <mru> I suggest starting w/o shared libs as they complicate things a bit [15:12:11] <KotH> .o0(i should get my subject to pay taxes to me... in swiss chocolate) [15:12:19] <KotH> s/subject/subjects/ [15:13:32] <lyakh> mru: huh... but running tests/fate.sh does a "make install" [15:13:39] <lyakh> and I do use shared libs [15:14:12] <lyakh> if I use "make fate" - how do I specify the config-file? [15:14:18] <mru> it does a make install a) to make sure this works, and b) because it makes shared libs easier to use [15:14:20] <lyakh> will it then skip install? [15:14:41] <mru> you don't need to use the fate.sh script at all if you run make fate manually [15:15:09] <mru> the fate.sh script is mostly intended for automatic runs reporting to a server [15:15:16] <lyakh> ok, so, as long as those shared libs end up under /usr/local/lib and ld.so finds them, then it's ok [15:15:35] <mru> do yourself a favour and skip the shared libs for now [15:15:48] <lyakh> ok, how do I specify the config to "make fate" then? [15:16:22] <mru> you run configure with whatever arguments necessary [15:19:42] <av500> why does mp still use libmpeg2? [15:21:32] <lu_zero> because this way you can do stuff with libmpeg2 only [15:21:34] <lu_zero> and nothing else [15:22:00] <av500> lu_zero: ah, for fedora :) [15:28:22] <j-b> av500: many people complain since we've moved from libmpeg2 to lavc [15:28:34] * lu_zero reads the emails [15:28:37] <lu_zero> j-b: why? [15:28:42] <kshishkov> j-b: why? [15:28:51] <lu_zero> beside the small glitches you fixed and I reported in rtsp? [15:28:52] <j-b> video quality, sharpness [15:29:06] <lu_zero> really? [15:29:10] <j-b> many more issues with DVDs [15:29:17] <bilboed-pi> same thing for gst. Switched to the ffmpeg dec being the default, and had to quickly switch back to libmpeg2 [15:29:18] <j-b> and those are remarks from broadcasters and so on [15:29:35] <j-b> but we keep lavc, because it doesn't crash [15:30:10] <mru> seeing as both are allegedly conforming decoders, my first suspicion would be the idct [15:30:15] <kshishkov> do you mean lavc does not decode mpeg2 properly or that libmpeg2 has videophile mode? [15:30:20] <mru> since that's the only part allowed to vary [15:30:24] <kierank> kshishkov: I was thinking latter [15:30:37] <mru> lavc does have a shitty mmx2 idct [15:30:45] <mru> if that one is chosen you might get bad picture [15:31:03] <j-b> I don't know [15:31:13] <mru> the one that does everything in 16-bit all the way [15:31:23] <mru> that obviously loses precision [15:31:27] <j-b> but seeing the user base of VLC, and the complaints, it isn't just one guy, but quite a common reproach [15:31:41] <mru> I'd like to see some actual images [15:31:46] <mru> pix or it didn't happen [15:31:49] <cartman> need bugreports ;) [15:31:58] <av500> j-b: find some user with a clue and have him report here [15:31:59] <j-b> exactly why you haven't seen one [15:32:09] <j-b> too afraid to post [15:32:13] <kierank> mru: or in x264, samples and/or command line or it doesn't happen [15:32:13] <av500> j-b: we promise not to eat him [15:32:28] <j-b> av500: but, over the last year, I've seen quite a number of people [15:32:37] <j-b> many people use older version, or bump back the libmpeg2 module [15:32:44] <av500> "seen" does not count [15:33:09] <av500> we can only sit here and believe our code is da greatest until you tell us [15:33:34] <kshishkov> kierank: since we don't encode command line is not necessary [15:33:41] <j-b> you know me, if I had time+screenshots, the bug would be posted already... [15:33:49] <kierank> kshishkov: [15:33:52] <j-b> av500: I am just reporting something that many people complained about. [15:33:56] <kierank> kshishkov: that's the rule for x264 crashes/bugs [15:34:01] <cartman> j-b: a buggy sample would be enough actually [15:34:05] <mru> j-b: we're not accusing you of anything [15:34:05] <j-b> av500: and I had my last fight with walken one year ago [15:34:11] <kshishkov> av500: may I also say that I found lavc MP3 decoder to decode MPEG-2/2.5 audio wrongly? [15:34:14] <av500> christopher? [15:34:23] <mru> j-b: but this is the first I've heard of this issue [15:34:37] <j-b> and I'll take back the maintainership of those libs anyway (beside) [15:34:43] <j-b> av500: yes, I think so [15:34:44] <kshishkov> kierank: I believe you (and that's quite reasonable rule too) [15:34:55] <j-b> I am glad bilboed-pi has seen the same [15:34:57] <thresh> :) [15:35:41] <kierank> speaking of -philes this is the greatest audiophile thread ever http://forum.doom9.org/showthread.php?p=1472980#post1472980 [15:36:08] <kshishkov> j-b: ask thresh, what proverb "ÐœÐµ ÑÑÐŸÐ¶Ñ Ð³ÐŸÐ²ÐœÐŸ - Ð²ÐŸÐœÑÑÑ ÐœÐµ Ð±ÑÐŽÐµÑ" means and how it applies to Walken [15:36:28] <j-b> kshishkov: I will [15:36:29] <KSHawkEye> Hey, what is this I hear about a ffmpeg mutiny? [15:36:53] <thresh> haha [15:37:20] <KSHawkEye> ? [15:37:21] <kierank> yarrr [15:38:44] <lyakh> ok, now it seems to be doing something... [15:40:02] <lyakh> hey, any specific event planned at FOSDEM? [15:40:47] <av500> theres no ff booth this year [15:40:56] <av500> mru and me will be at the beagle booth [15:41:30] <kshishkov> well, mru is synonimous both with BB and FF :) [15:41:35] <DonDiego> bbl [15:41:39] <lyakh> is Diego Biurrun around? [15:41:47] <av500> not any more [15:41:54] <lyakh> that was him then? ok:) [15:42:10] <lyakh> he asked about anyone passing via Aachen...;) [15:42:12] * cartman goes to FOSDEM to snag a beagleboard xM from av500 [15:42:22] <av500> lyakh: ah right [15:42:37] <lyakh> shall I bring my bbxm to demonstrate video?... [15:42:54] <av500> lyakh: we'll have plenty of them [15:42:56] <thresh> so you're going to start the ffparty in the train [15:43:12] <cartman> av500: send one my way [15:43:21] <kierank> [15:42] cartman goes to FOSDEM to snag a beagleboard xM from av500 --> is this true [15:43:27] <lyakh> av500: don't think you have that many of them doing _direct_ (not USB) video...;) [15:43:40] <cartman> kierank: nah I am not coming you can relax [15:43:41] <cartman> :p [15:43:41] <av500> ah, video in [15:43:46] <lyakh> yep [15:43:48] <av500> lyakh: sure bring one [15:43:55] <kierank> cartman: i don't care about you. i care about the free beagleboards ;) [15:44:07] <av500> kierank: cartman's wet dreams [15:44:24] <cartman> kierank: av500 and free is just an oxymoron [15:44:39] <kierank> cartman: does he charge for air? [15:44:48] <av500> 50% off [15:44:59] <cartman> kierank: you'll need air when you run away from him :P [15:45:00] <av500> unless you want it "fresh" [15:45:09] <kierank> lol [15:46:24] <kshishkov> av500: please reserve a pandaboard for me then ("free" is not necessary) [15:46:43] <av500> kshishkov: I wish I could [15:46:46] * kierank is considering going because of cheap eurostar [15:47:06] <av500> so, the less booth we have, the more ffdevs come.... [15:47:28] <j-b> of course [15:47:36] <j-b> because noone wants to do the boring work [15:47:42] <j-b> and booths are boring [15:47:51] <av500> you need boothbabes [15:47:53] <kierank> or maybe cebit will be more interesting [15:48:01] <j-b> people attending fosdem already know the project [15:48:03] <av500> kierank: wear a suit [15:48:10] <thresh> there could be a GwOC task for a booth [15:48:13] <j-b> and you are not a distro to fight with the next one over CD [15:48:14] <kierank> av500: for cebit? [15:48:28] <kshishkov> j-b: compared to VLC booth, FFmpeg booth at LT was overstaffed. Even you hired somebody to go there instead of you! [15:48:29] <kierank> or for fosdem [15:48:30] <andoma> are there places at fosdem to sit and hack if you wanna do that? [15:48:43] <av500> andoma: yes [15:49:05] <kshishkov> av500: can I get free axe for that there? [15:49:41] <kierank> av500: why wear suit? [15:49:53] <av500> its a suits thing [15:50:16] <cartman> mru: yay now it crashes somewhere else :D [15:50:26] <spaam> arpi on the ml ;DD [15:50:43] <kierank> av500: k [15:50:52] <av500> kierank: well, you can do without [15:51:06] <av500> havent been to cebit since 2001 or so [15:51:11] <av500> or 02 [15:51:16] <kierank> someone told me there are lots of chinese that tell you they can do what you're doing for 10 times cheaper [15:51:20] <kierank> at cebit [15:51:23] <j-b> kshishkov: LT and FOSDEM are not the same [15:51:45] <av500> kierank: yes, huge chinese presense [15:52:05] <kierank> many women? [15:53:09] <av500> chinese booth babes [15:53:22] <kshishkov> "ffmpeg and mplayer should be merged completely together" <- I've talked about making FFplayG2 out of MPlayer for ages! [15:53:38] <av500> +1 [15:54:33] * kierank will dress up like he is a ceo then [15:55:15] <thresh> Ð)) [15:56:14] <kshishkov> kierank: and I'll dress like ordinary FFmpeg dev :P [15:56:57] <kierank> i'll pretend to be your boss kshishkov [15:57:03] <av500> kierank: http://img.hexus.net/v2/internationalevents/cebit_hannover_2005/store/cebit… [15:57:23] <av500> it was obviously a cold year [15:57:37] <kshishkov> av500: judging from Intel logo they really need babes to sell their products [15:58:49] <av500> serbian babes are more modest: http://www.sol.rs/images/photos/cebit2004_crowd_front-big.jpg [15:59:04] <kierank> lol [15:59:38] <thresh> lol @ a'rpi mail [15:59:48] <thresh> the second one [15:59:50] <bilboed-pi> :) [15:59:55] <lu_zero> where? [16:00:11] <thresh> the same place [16:00:25] <thresh> FFMMppeegg devel mailing list [16:00:47] <thresh> or should I say ffmpeg and ffmpeg development mailing list? :) [16:01:06] <kshishkov> still, Arpi+MN ~= binary codec loader and libmpeg2 in lavc (may be "revolting" instead of "revolutionary" though) [16:01:33] <av500> one more time he says leader and I will leave for good.... [16:01:48] <lyakh> ok, there are even not too many errors so far;) [16:01:53] <j-b> av500: leave where? [16:02:04] <thresh> gst, obviously [16:02:06] <thresh> what else! [16:02:13] <av500> j-b: no idea, does vlc take ppl [16:02:15] <av500> ? [16:02:26] <av500> i could work on libmpeg2... [16:02:27] <kshishkov> av500: what do you have against our Josip Broz Micho? [16:02:55] <j-b> av500: we do. and libmpeg2 is not even a VideoLAN project... Walken forbids us to work on it... [16:03:08] <thresh> i have a cunning plan [16:03:11] <cartman> mru: I/OMAPFBPLAY( 3708): Error allocating frame buffers: 67043328 bytes. [16:03:17] <cartman> mru: too many bytes? :D [16:03:25] <av500> cartman: 64MB? [16:03:26] * kshishkov renames thresh to baldrick [16:03:30] <cartman> av500: yeah [16:03:33] <thresh> what if we import libmpeg2 into git, host it on videolan and change the URL in website's svn? [16:03:34] <cartman> mru: I/OMAPFBPLAY( 3708): Using 124 frame buffers, frame_size=540672. [16:03:40] <thresh> kshishkov: yes, milord! [16:03:45] <av500> thresh: let mn invade in winter and wait for spring? [16:04:08] <cartman> looks wrong [16:04:28] <lu_zero> 17:01 <+av500> one more time he says leader and I will leave for good.... [16:04:30] <lu_zero> uh? [16:04:36] <cartman> 0.5mb for each frame [16:05:18] <av500> lu_zero: personally, I find michael referring to himself as "leader" all the time the most offensive... [16:05:49] <kshishkov> av500: do you think he should assume proper German title instead? [16:06:05] <lu_zero> I feel that arpi should just shut up btw [16:06:14] <av500> kshishkov: I think he does not need to use that term at all [16:06:27] * j-b is trying to not reply [16:06:53] <kshishkov> av500: well, MÃ¥ns told him that few times, see the result [16:07:20] <kshishkov> lu_zero: who cares about him? Or who has heard anything about him? [16:07:21] <bilboed-pi> is libmpeg2 being maintained ? [16:07:29] <kshishkov> lu_zero: for the last N years? [16:08:07] <kshishkov> bilboed-pi: we call it a guard dog on haystack situation - maintainer only prevents everybody else from touching it and does nothing else [16:08:19] <bilboed-pi> reminds me of another project [16:08:29] <bilboed-pi> +1 for a git libmpeg2 mirror though [16:08:37] <kshishkov> which one? [16:09:02] <j-b> bilboed-pi: yes, it is maintained, more or less [16:09:28] <j-b> bilboed-pi: and we'll switch it to git, sometime soon... When I can take the time to tell walken "fuck" [16:10:04] <kierank> who's walken [16:10:09] <kierank> also j-b how do i get a ticket to cebit [16:10:10] <bilboed-pi> last modification... 210days ago [16:10:24] <lyakh> is Luca Barbato here? [16:10:36] <lu_zero> lyakh: hi [16:10:36] <av500> lyakh: yep [16:10:50] <kshishkov> kierank: the guy who complicated situation with yuv2rgb for us [16:10:53] <lyakh> lu_zero: hi, sorry, didn't understand your question... [16:11:05] <lu_zero> which one? [16:11:17] <lyakh> those macros _are_ of course sh4-specific - their implementation that is [16:11:23] <j-b> bilboed-pi: of course, do you have any patches and complaints? [16:11:27] <lyakh> lu_zero: regarding the sh4 mp3 optimization [16:11:34] <j-b> bilboed-pi: it applies patches when patches come [16:11:45] <thresh> so walken is not human [16:11:55] <j-b> he isn't [16:12:10] <lu_zero> lyakh: ah [16:12:13] <lyakh> lu_zero: but the addition of those macros to the decoder file doesn't break anything - any other platform [16:12:16] <bilboed-pi> j-b, just wondering that's all [16:12:17] <kshishkov> kierank: http://www.fosdem.org/2011/faq I can sell you Fosdem ticked for fifty quid though [16:12:38] <lu_zero> lyakh: yes, the question is if those are so useful it would be better to implement them on the other arches [16:12:56] <cartman> memalign fails [16:12:56] <j-b> bilboed-pi: it decodes mpeg2 quite well, and has one major issue, that is still not fixed, but appart from that, i don't know what would need to be in. [16:12:57] <lu_zero> since from what I read those are just specializations of the generic macro [16:12:58] <cartman> hmmpf [16:13:17] <lyakh> lu_zero: whether anyone else can benefit from them - maybe, if there are arches, that have similar multiply-and-accumulate instructions [16:13:50] <peloverde_> bilboed-pi: thanks for thw quick response on qtdemux [16:14:09] <bilboed-pi> peloverde_, it'll be in the release also :) [16:14:28] <lyakh> lu_zero: implement for other arches - well, if anyone has those arches and is interested in doing that... sure, why not?;) [16:14:37] <mru> lyakh: I think that approach to optimising the mp3 decoder is a dead end [16:14:48] <lyakh> mru: why? [16:15:18] <mru> you'd get better results by writing the entire windowing loop in asm [16:15:27] <mru> and the dct [16:15:38] <lyakh> mru: I cannot say about this specific loop [16:15:51] <lyakh> but from what I've seen why trying to optimize some other paths [16:16:00] <lyakh> the gcc is pretty damn good at that [16:16:06] <mru> I've been toying with that loop in the past [16:16:06] <lyakh> or I am way too bad... [16:16:11] <mru> and gcc is pretty fucking shit at it [16:16:41] <lyakh> mru: what specifically does it screw up? [16:16:55] <lu_zero> mru: maybe gcc for sh4 isn't that bad nowadasy [16:16:56] <cartman> mru: why would memalign return errno 25? [16:17:07] <lu_zero> nowadays =P [16:17:55] <cartman> mru: and error 25 is "Not a typewriter" [16:17:56] <cartman> wtf lol [16:18:07] <lyakh> it is a bog-standard "for" loop... what can be so special about it? [16:18:27] <mru> lyakh: gcc can mess up in any number of ways [16:18:51] <mru> most common are excessive stack load/store and piss-poor insn scheduling [16:19:29] <lyakh> mru: yes, I thought the same about other paths... [16:19:40] <mru> I don't know about sh4, but on both arm and ppc gcc compiles that loop into utter crap [16:19:43] <lyakh> but optimizing them didn't bring a 1% improvement, really... [16:19:53] <lyakh> ok, so, what I could do [16:20:16] <lyakh> I could extract the content of that loop into a function in a separate file [16:20:21] <lyakh> to prevent inlining;) [16:20:28] <lyakh> and then look at asm... [16:20:40] <lyakh> and also look at it with the normal version [16:21:23] <lyakh> but I really don't think saving a couple of loads / stores would bring any significant result... [16:21:37] <mru> I'm not talking about a couple [16:21:48] <mru> I'm talking about reducing the code size by 50% [16:22:34] <lyakh> mru: sorry, don't think this would work. Looking at that loop - apart from those two macros, that already are asm, there's very little C left... [16:22:41] <lyakh> ok, let me have a look at the asm... [16:22:47] <mru> enough for gcc to mess up [16:22:57] <mru> and gcc tends to mess up worse around inline asm [16:25:35] <mru> lyakh: I don't mean to criticize what you've done, but I think if we worked together we could make it even better [16:25:37] <kshishkov> you still can't forgive that little trick GCC plays on storing float into indexed array, do you? [16:25:50] <mru> grr [16:26:25] <kshishkov> just don't say you want GCC devs to work on Hurd instead [16:26:59] <mru> hmm, I'm not sure who'd be most punished by that [16:28:09] <kshishkov> weren't you saying Hurd is a kind of bit-bucket for devs who could cause harm elsewhere? [16:28:26] <mru> I may have said something to that effect [16:29:43] <kshishkov> so it's not punishment, it's win-win-gnu situation [16:30:57] <lyakh> mru: ok, even if you're right and that loop can be optimized (no, I haven't found anything wrong in the asm yet) - can we not first commit the first step - as in my patch but with a copy for sh4, and then look at that loop in the second step? [16:32:20] <lu_zero> lyakh: the idea is that might be a quick win [16:33:22] <lyakh> lu_zero: it's not _that_ quick, with all those round-samples... [16:34:21] <mru> the whole apply_window_mp3_c function is easy enough to write entirely in asm [16:36:25] <lyakh> sure, why don't we rewrite the complete ffmpeg in asm?;) [16:36:35] <mru> that's not trivial [16:36:41] <mru> but it would be 50% faster [16:37:04] <mru> there are even hooks in place to write that very function in asm [16:37:13] <lyakh> CPU time is cheap, developer time is expensive... [16:37:34] <mru> cpu time happens every time you play a song, dev time happens once [16:37:46] <superdump> such functions as windowing are just begging for asm [16:38:53] <lu_zero> let me see better [16:39:53] * lu_zero wonders why ff_mpa_synth_filter does call apply_window_mp3_c [16:40:01] * mru was just looking at that too [16:40:19] <lu_zero> lyakh: you made us discover _lots_ of stuff ^^; [16:40:25] <mru> I remember michael rushing in the float stuff without doing everything properly [16:40:55] <lyakh> lu_zero: you're welcome, where can I send the bill?;) [16:41:10] <mru> lyakh: to renesas [16:41:42] <lyakh> mru: hm, I'll think about it;) [16:42:04] <mru> seriously, if they care they should [16:42:39] <mru> ARM does... [16:44:03] <av500> too bad goog did not pick sh4 for android... [16:44:19] <lu_zero> apply_window_mp3 is just implemented for ppc and x86 .... [16:45:34] <lyakh> av500: there's android on sh... [16:45:47] <mru> and only float version [16:47:56] <av500> lyakh: I know [16:48:02] <av500> its there on mips too [16:52:28] * lu_zero will port it on amd64 just to make the world more weird [16:53:31] <lu_zero> or not [16:54:10] <lyakh> better to atmega;) [16:54:29] <mru> ugh, this is not pretty [16:54:56] <lu_zero> mru: MPA_INT? [16:55:09] <mru> no, that's just a minor blemish [16:55:28] <mru> the int and float versions of ff_mpa_synth_filter have different prototypes [16:55:30] <lu_zero> DonDiego: do you remember which was last year hotel? [16:55:53] <DonDiego> i was in a youth hostel [16:56:00] <mru> one takes an MPADecodeContext*, the other does not [16:56:01] <DonDiego> forgot the name of course [16:56:07] <lyakh> DonDiego: hi, so, you're in AC too? [16:56:22] <lu_zero> RENAME(ff_mpa_synth_filter)( [16:56:30] <lu_zero> why that makes me shiver? [16:56:33] <DonDiego> lyakh: yes, why? [16:56:45] <lyakh> DonDiego: I just replied to your mail on the list [16:57:05] <lyakh> I'll (probably) also be going to FOSDEM from AC (and back) [16:57:11] <mru> DonDiego: http://maps.google.co.uk/?ie=UTF8&ll=50.853046,4.358246&spn=0.006184,0.0133… [16:57:11] <lyakh> I _might_ be driving... [16:57:12] <jannau> lu_zero: it gives you libswscale nightmares? [16:57:15] <mru> that's the place you were in [16:57:21] <lu_zero> jannau: yup [16:57:26] <lyakh> DonDiego: don't know the times yet... [16:57:51] <lyakh> DonDiego: do you want to be there from hour 1 to hour last? [16:58:06] <av500> DonDiego: get on the beer train! [16:58:17] <mru> the friday beer event is not to be missed [16:58:27] <mru> that's half the reason for going at all [16:58:28] <lyakh> heh, yeah, sure, that's a choice;) [16:58:46] <DonDiego> cool [16:58:56] <DonDiego> but yes, the beer event is not to be missed [16:59:06] <lyakh> ok, then we'll meet there;) [16:59:20] <mru> delirium ftw [16:59:50] <thresh> mru: when are you coming to Brussels? [16:59:57] <mru> on the friday [17:00:05] <DonDiego> hmm [17:00:14] <mru> thresh: where are you staying? [17:00:27] <DonDiego> michael claims to always follow the rules now... [17:00:35] <thresh> mru: the same hotel as all videolaners, http://www.accorhotels.com/gb/hotel-7863-mercure-brussels-center-louise/ind… [17:00:49] <thresh> i'm coming on Thursday [17:00:58] <DonDiego> lyakh: where are you staying? [17:01:07] <lyakh> no idea yet... [17:01:09] <thresh> that reminds me i need to book it :) [17:01:14] <jannau> can anyone please proof read http://pastie.org/1481354 [17:01:18] <lyakh> I was waiting for the time-table [17:02:09] <DonDiego> oh, arpi posting [17:02:16] <BBB> hm... so now two h264 files give different output in emu_edge vs. normal decoding [17:02:17] <DonDiego> shall i skip reading? [17:02:22] <BBB> and both re 4:0:0 files [17:02:25] <DonDiego> nah, it will be the usual flames :) [17:02:25] <BBB> DonDiego: please do [17:03:01] <mru> thresh: that's not very central... [17:03:28] <DonDiego> BBB: skip reading? [17:03:32] <lu_zero> the price is comparable to mru's [17:03:32] <BBB> DonDiego: yes [17:03:42] <lu_zero> mru: remind me yours [17:03:42] <DonDiego> too late, but it's amusing in any case.. [17:03:56] <lu_zero> DonDiego: he didn't meant to send it to the list [17:03:56] <DonDiego> arpi back, michael will love that... [17:03:57] <mru> lu_zero: st nicolas, 75EUR per night [17:03:59] <BBB> a simple way to "support" 4:0:0 files is to simply set DC_128 pred mode to be defined as zero, because then all chroma samples are sety to 128 by default = gray [17:04:03] <BBB> what do people think of that? [17:04:05] <BBB> it's a hack, I admit [17:04:10] <BBB> but who cares :-p [17:04:34] <lu_zero> in fact it is arpi in the email is less caustic than usual [17:04:56] <lu_zero> s/it is// [17:05:04] <BBB> hm, maybe I can fix it some other way [17:05:19] <mru> lu_zero: where are you staying? [17:05:55] <mru> jannau: didn't you post that on the ml already? [17:06:10] <lu_zero> st nicolas seems overall better [17:06:19] <thresh> mru: but should be pretty close to fosdem place [17:06:31] <mru> distance to delirium is more important [17:06:46] <lu_zero> DonDiego: single and double cost the same, want to share? [17:07:04] <BBB> mru: any more comments on ruggles' patches? I'm about to commit them [17:07:08] <thresh> haha [17:07:16] <BBB> (want to get used to being a patch monkey, so need to figure out how that works) [17:07:19] <mru> BBB: reading them now [17:07:29] <jannau> mru: yes, but now hopefully without spelling errors [17:07:44] <mru> BBB: my mail reader can pipe the message directly to git am [17:07:47] <mru> or any other command [17:07:48] <av500> thresh: fosdem is one shared taxi away [17:07:50] <mru> very useful [17:08:04] <DonDiego> lu_zero: yes, arpi is surprisingly calm - probably because he thought he was not writing to the list ;) [17:08:13] <av500> crawling to hotel after beer, priceless [17:08:19] <mru> jannau: looks good [17:08:32] <thresh> av500: mmm true [17:08:45] <thresh> and cheaper than that mercure [17:08:46] <mru> to finish off with another beer in the hotel bar [17:08:59] <lu_zero> BBB: I think mr queues patches in a mail box and then issues git-am over it [17:09:01] <av500> thresh: at least in paris, mercure is expensive [17:09:03] <lu_zero> mru [17:09:14] <DonDiego> lu_zero: share a room, sure, why not... [17:09:16] <j-b> av500: it is expensive. [17:09:17] <mru> no [17:09:24] <DonDiego> lyakh: you sure you will drive? [17:09:37] <lyakh> DonDiego: not yet [17:09:40] <j-b> av500: but was the first hotel, near ULB, where we could get easily 10 people and under 75EUR [17:09:40] <mru> I git am them directly from mail reader into staging branch [17:09:42] <DonDiego> maybe we can pick up reinhard if he comes to aachen by train [17:09:45] <av500> thresh: but I saw j-b has a nice credit card [17:09:55] <thresh> av500: i'm paying for my hotels [17:09:59] <av500> j-b: under75 is cheap [17:09:59] <lu_zero> j-b: under 75eur/night? [17:10:01] <mru> when I say "queued" it means I've applied it to my repo but not pushed yet [17:10:07] <lu_zero> ah [17:10:07] <thresh> j-b only pays for my plane tickets :) [17:10:08] <jannau> should we added: another signed-off-by: or reviewed-by line for commits reviewed by somebody else? [17:10:13] <BBB> mru: can gmail do that? [17:10:24] <av500> BBB: mru and gmail? [17:10:26] <mru> BBB: wishful thinking [17:10:27] <jannau> should we add [17:10:42] <lu_zero> hi j0sh_ [17:10:44] <BBB> hi j0sh_ - we should update you on some stuff :-p [17:10:57] <lu_zero> a _small_ number of details ^^; [17:11:02] <av500> j0sh_: you now report to KotH [17:11:29] <BBB> can I c/p the patch from a patch file into a vim termianl window and then run git-am on that? [17:11:29] <j-b> av500: I paid 75EUR for the double queen beds and 68EUR for the king bed [17:11:36] <BBB> what is git-am anyway [17:11:38] <av500> j-b: cool [17:11:45] <j-b> av500: and I paid for all travels, of course [17:11:45] <mru> it's cool [17:11:54] <av500> j-b: you are a great "leader" [17:11:57] <lu_zero> BBB: git am and git format-patch [17:11:58] <thresh> j-b, the millionaire [17:12:10] <j-b> av500: but the hotel is on a 10minutes ride on the tram94 to ULB [17:12:22] <j-b> so it was the best solution [17:12:24] <lu_zero> so if you can manage to get the emails in a mbox [17:12:50] <lu_zero> git am mbox applies all of them [17:12:53] <BBB> Patch does not have a valid e-mail address.... [17:12:56] <BBB> what does that mean [17:13:02] <BBB> should I use git format-patch? [17:13:04] <mru> it means you got only the attachment [17:13:06] <j-b> BBB: git am -s or, if doesn't work, edit patch git apply and then git commit -s --author [17:13:22] <mru> ruggles seems to be sending the comment as email body and the diff as attachment [17:13:23] <lu_zero> BBB: do you have imap configured on your gmail? [17:13:30] <BBB> yes [17:13:40] <mru> I can take care of this patch [17:13:41] <BBB> but I use the web-interface [17:13:41] <lu_zero> so you can access gmail through imap [17:13:47] <BBB> ok, I'll let mru do it for now [17:14:04] <mru> BBB: no more comments from you either? [17:14:12] <lu_zero> use a label for the emails and then configure a client like imapsync to monitor that label/directory [17:14:12] <BBB> both are good [17:14:23] <BBB> I'll comment on 1/2 but it's a question, it should be queued anyway [17:14:28] <CIA-29> ffmpeg: Janne Grunau <janne-ffmpeg(a)jannau.net> master * re5fe65512b ffmpeg/libavformat/mpegtsenc.c: [17:14:28] <CIA-29> ffmpeg: mpegtsenc: prefer metadata keyed with "service_name" [17:14:28] <CIA-29> ffmpeg: title metadata is only used as fallback if no service_name is available. [17:14:28] <CIA-29> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg(a)jannau.net> [17:15:40] <DonDiego> lu_zero: what sort of room do you want to share? [17:15:56] <mru> the presidential suite of course [17:16:08] <DonDiego> this channel is getting busy - because of the news? [17:16:08] <av500> DonDiego: one with large dressing mirror [17:16:21] <lu_zero> looking at the options now ^^ [17:16:30] * lu_zero always mixes up double and twin [17:16:35] <av500> http://www.flickr.com/photos/av500/4767108775/ [17:16:38] <DonDiego> av500: for guys with long hair? :) [17:17:18] <av500> :) [17:17:40] <ruggles> mru: what i really wanted was the whole commit message in the body rather than (or in addition to) the subject, but i couldn't figure out how to get git send-email to do that. [17:17:44] <mru> lu_zero: double is for sharing with girls [17:18:18] <mru> ruggles: I get conflicts applying that diff [17:18:35] <lu_zero> mru: eh eh [17:18:40] <lu_zero> so twin is the right one [17:18:44] <av500> yes [17:18:50] <mru> ruggles: it's the sstep/dstep fix [17:19:03] <mru> your patch includes that but it was already pushed [17:19:05] <av500> lu_zero: but the hotel will mess it up anyway [17:19:08] <ruggles> mru: oh, ok. i'll pull again. [17:19:14] <lu_zero> av500: iknow [17:19:26] <av500> the ui is only to make people happy :) [17:19:34] <mru> hmm, what if sharing with two girls? [17:19:45] <av500> double->trouble [17:19:57] <mru> double trouble [17:20:02] <av500> ask for a trouble room [17:21:13] <lu_zero> mru: the right answer is a double queen room with middle door [17:21:37] <lu_zero> DonDiego: how many days? [17:22:08] <ruggles> BBB: i did comment on the celp filters [17:23:32] <DonDiego> lu_zero: two nights i guess, fr/sa, sa/su [17:23:53] <BBB> oh there, different thread [17:23:55] <BBB> ruggles: sorry [17:23:58] * BBB reads [17:24:21] <ruggles> mru: just sent new patch rebased to master [17:24:40] <mru> ruggles: fwiw, plain git send-email without attachment works fine for me [17:24:44] <mru> don't know about others [17:24:54] * lu_zero checks his flight [17:24:58] <BBB> ruggles: ok that answers my question, let's leave it separate then [17:25:01] <BBB> ruggles: patch itself is ok [17:25:22] <mru> lu_zero, DonDiego: I'm staying until monday [17:25:28] <mru> the only flight home on sunday is too early [17:25:35] <lu_zero> Probably I'll have to do that as well [17:25:53] <ruggles> mru: i think thunderbird was screwing something up so i changed my global settings. i don't remember for sure. [17:26:23] <lu_zero> ruggles: do you send them with git send-email or thunderbird? [17:26:34] <ruggles> git send-email [17:26:44] <mru> there's nothing in the path between ffmpeg.org and my git repo that mangles patches [17:26:55] <mru> others may be using less careful mail readers [17:28:21] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r0a3d7697b4 ffmpeg/libavcodec/ (iirfilter.c iirfilter.h): [17:28:21] <CIA-29> ffmpeg: Add function ff_iir_filter_flt() to accept floating-point input and output. [17:28:21] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:28:23] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rebb230279a ffmpeg/libavcodec/iirfilter.c: [17:28:23] <CIA-29> ffmpeg: cosmetics: wrap long line [17:28:23] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [17:30:07] <ruggles> now i remember. it think it was for svn. i wanted to be able to use "git format-patch --no-prefix" and then be able save the patch separately from the email to apply it to svn. [17:31:15] <mru> it's all the same to me [17:31:21] <mru> I can accept anything send-email spits out [17:31:30] <ruggles> ok [17:31:52] <mru> more primitive mail readers may prefer either all in the body or all as attachment [17:32:20] <av500> time for ffmail [17:32:30] <DonDiego> lyakh: when will you decide if you go or not? [17:33:08] <lyakh> DonDiego: I most likely will go, just not sure by car or train... I'll try to clarify this tonight [17:34:13] <BBB> also, Dark_Shikari, warning on x86-64 with your changes: /Users/ronaldbultje/Projects/ffmpeg-git/libavcodec/h264.c:1204: warning: passing argument 2 of âh->h264dsp.h264_chroma_dc_dequant_idctâ from incompatible pointer type [17:34:19] <BBB> Dark_Shikari: can you fix that? (I can too if you're busy) [17:35:17] <DonDiego> lyakh: ok, cool, let me know [17:35:24] <lyakh> DonDiego: ok, will do [17:35:55] <funm4n> hello [17:36:39] <lyakh> DonDiego: but also when... as I said, I won't be going on Friday almost for sure, Saturday - well, some time in the morning, leaving some time in the afternoon / evening on Sunday... I mean, if you're specifically interested in any early / late sessions - let me know [17:36:40] <funm4n> should http://ffmpeg.org/download.html be updated to remove svn mention? [17:37:08] <BBB> probably, yes [17:37:12] <BBB> didn't we already? [17:37:15] <BBB> I thought I grepped for it [17:37:23] <BBB> I think the website isn't updating automatically atm [17:37:38] <BBB> oh no it is [17:37:39] <funm4n> ah perhaps there is a proxy between me and the site also [17:37:54] <lyakh> damn:( [17:37:54] <lyakh> TEST lavf-png [17:37:54] <lyakh> diff: tests/data/regression/lavf/png: No such file or directory [17:37:54] <lyakh> make: *** [fate-lavf-png] Error 1 [17:38:06] <mru> I see the svn repo still mentioned after the git stuff and with a big warning that it's going away [17:38:24] <BBB> lyakh: update your fate samples collection [17:38:26] <mru> lyakh: you probably don't have zlib for the target [17:38:36] <BBB> or that [17:38:40] <mru> BBB: that test doesn't need the samples [17:38:42] <lyakh> BBB: just have done that [17:38:46] <lyakh> (updated) [17:38:47] <siretart> it seems that the new -commits mailing list is not available via gmane yet. Could someone please have a look into this? [17:38:58] <BBB> siretart: dondiego filed a request [17:38:59] <mru> siretart: I sent a request [17:39:04] <BBB> damnit I'm always wrong [17:39:05] <siretart> thanks! [17:39:09] * BBB shuts up [17:39:19] * BBB goes fix the h264 4:0:0 thing again [17:39:31] <lyakh> zlib or zlib-dev? [17:39:46] <mru> lyakh: whatever is needed to build stuff against it [17:40:32] <mru> the exact answer depends on what system/distro/environment you're using [17:40:44] <lyakh> it's doing some building on the target???..... [17:40:46] <lu_zero> btw lyakh the beer event is worthy [17:40:57] <siretart> oh, and it seems that -devel-irc is missing as well [17:41:02] <lyakh> what if I don't have any cc on it at all???... [17:41:36] <lyakh> lu_zero: what's so worthy about it? apart from beer:) [17:41:52] <mru> it's not just any beer [17:42:25] <mru> lyakh: no, you don't need a compiler on the target [17:42:26] * lyakh dares a remark, that he's in Germany;) [17:42:38] <mru> but your cross-compiler must find zlib headers and libs somehow [17:42:40] <lyakh> mru: so, why building against zlib? [17:42:42] <thresh> german beer < * [17:42:57] <funm4n> didn't you taste french beer yet? [17:43:08] <mru> funm4n: there is no such thing [17:43:13] <av500> +1 [17:43:29] <thresh> I think i tried kroenenbug [17:43:33] <av500> the last time a frenchman praised a beer, I told him it was belgian [17:43:35] <mru> that's not beer [17:43:37] <lyakh> mru: sorry, don't understand... the build stage has completed. it's not running tests, why does it need libs for that? [17:43:54] <mru> it needs zlib to build the png decoder [17:44:00] <funm4n> i plan to taste north american french beer soon [17:44:07] <av500> mru: didnt you have a zlib :) [17:44:10] <mru> if you don't have zlib, png is excluded from the build and the png test fails [17:44:24] <mru> av500: only a decoder and there's one bug remaining [17:44:32] <lyakh> mru: but then not on the target, but on the host? in the cross-build env? [17:44:42] <mru> yes [17:44:54] <lyakh> ic... [17:45:07] <lyakh> is there a way to exclude the png test? [17:45:37] <ruggles> that reminds me. should not having a test component make the test fail or not run? [17:45:53] <mru> ruggles: yes, the deps are incomplete [17:46:20] <av500> but then ppl could cheat on fate by not enabling anything... [17:46:34] <ruggles> mru: ok. nobody ever commented on my test deps patch... is why i ask. thought maybe i was on the wrong track. [17:46:35] <mru> av500: that would show fewer tests in total [17:46:35] <av500> "my Z80 port is all green" [17:46:54] <mru> ruggles: I'll have a look at it, but I have the feeling it could be done simpler [17:50:02] <ruggles> thanks [17:52:49] <av500> who is flvdec maintainer? [17:54:16] <lu_zero> av500: uhmmm, I'm looking the pcap dumps [17:54:29] <lu_zero> dump/from_archos/ld_fr2.pcap <- no audio at all [17:54:53] <av500> ic [17:55:02] <av500> but there is audio in the .ts, no? [17:56:04] <lu_zero> uhm [17:56:05] <lu_zero> wait [17:56:13] <lu_zero> rtp/avp 33 [17:56:21] <lu_zero> mpegts in rtp.... [17:57:23] <av500> yes [17:57:51] <lu_zero> then isn't rtp support for aac [17:58:00] <lu_zero> it should be a chained demuxer [17:58:29] <av500> but why does video work? [17:59:26] <av500> lu_zero: could I make lavf rtp to give me the whole ts stream? [18:00:06] * elenril starts reading arpi's response [18:00:06] <elenril> wait, WHAT? [18:02:09] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rf0f54c297f ffmpeg/configure: [18:02:09] <CIA-29> ffmpeg: Make PNG test depend on PNG codec [18:02:09] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:03:34] <mru> ruggles: btw, any idea why the ac3 test uses rm container? [18:03:39] <mru> ac3 works just fine raw... [18:04:11] <lu_zero> av500: it should do that [18:04:15] <lu_zero> let me re-read the code ^^; [18:04:31] <av500> and as said, video works [18:04:32] <ruggles> mru: historical. i'd be happy changing it. [18:04:43] <mru> ruggles: me too [18:05:06] <lu_zero> and if you copy to mpegts works as well? [18:05:09] <ruggles> probably someone wanted to cover more things in a single test. but lavf-rm uses ac3 too so that covers it. [18:05:31] <mru> ac3 is one of the oldest parts of ffmpeg [18:05:49] <mru> ruggles: btw, nice work on the encoder [18:05:53] <ruggles> thanks :) [18:06:00] <mru> I'll be optimising it for arm soon [18:06:54] <ruggles> yay. i was hoping for that. there are more things in the ac3 encoder i want to dsputil-ize as well, but other things come first. [18:07:30] <mru> they're paying me for it [18:07:51] <ruggles> cool. arm probably already has a better mdct. [18:08:04] <mru> it has a good float mdct [18:08:18] <lu_zero> ret = ff_mpegts_parse_packet(s->ts, pkt, buf, len); [18:08:19] <mru> probably the best there is [18:08:21] <lu_zero> meh [18:08:23] <ruggles> yeah. since you wrote the whole thing in asm, not just the fft. [18:08:36] <mru> some arm dude did the fft core [18:08:38] <mru> or most of it [18:08:45] <mru> I did the mdct wrapper [18:08:52] <lu_zero> av500: it directly call the ts parser [18:09:14] <av500> lu_zero: ok, and that means? [18:09:42] <mru> ruggles: is it safe to assume the already pointerized functions will stay the way they are? [18:10:08] <lu_zero> av500: that there isn't _that_ simple way [18:10:14] <av500> lu_zero: so its already chained? [18:10:15] <lu_zero> still copy should work fine [18:10:59] <av500> lu_zero: see here: [18:11:04] <ruggles> mru: most, but possibly not all. channel coupling will be a pretty significant change. [18:11:05] <av500> [13:54:49] <wbs> quick verdict on the mpegts/rtp stuff: they way rtp/mpegts is interconnected, the normal mpegts_read_header never is called [18:11:09] <av500> [13:55:22] <wbs> which means streams/codecs aren't set up properly by reading the PMT(?) (I've got no clue on mpegts details) [18:11:14] <av500> [13:55:54] <wbs> which means they're assigned CODEC_ID_PROBE, which tries to probe the codec but apparently doesn't succeed, taking half an eternity to bail out [18:11:28] <mru> ruggles: ok, I'll check back with you before I do any real work [18:11:49] <lu_zero> av500: agreed [18:11:54] <ruggles> mru: that's one of the problems i had with aften. it was micro-optimized, then when i tried to add channel coupling it was a pain. i tried several times but never completely finished it. [18:12:30] <lu_zero> av500: you need that working soon? [18:13:45] <ruggles> mru: and the AC3 256-point MDCT is a weird one. before i used the vorbis mdct in aften, i split up the mdct into a dct-iv to simplify the 256-point case. [18:14:01] <av500> aften? [18:14:13] <av500> ah got iz [18:14:15] <av500> it [18:22:15] <lu_zero> BBB: poing [18:25:24] <BBB> piong [18:28:35] <BBB> lu_zero: piong [18:30:52] <BBB> mru: next two of ruggles' patches are ok also, if you want to queue more [18:31:03] <Compn> funny that arpi and i think mplayer + ffmpeg should be merged :D [18:31:11] * Compn thought he was alone [18:31:33] <Compn> everyone seems to hate mplayer now :( [18:31:50] <mru> I don't hate mplayer, but I think it should be separate from ffmpeg [18:32:23] <iive> Compn: haven't you noticed that most of mplayer development now is removing stuff and using it from ffmpeg? [18:33:05] <Compn> iive : yes , i have :) [18:33:14] <Compn> but thats the smart way to do it [18:33:20] <Compn> e.g. no more faad [18:33:38] <lu_zero> BBB: you have experience with chained demuxer [18:33:50] <BBB> a little [18:33:58] <BBB> \o/ fate/h264 works with -flags emu_edge [18:34:01] <lu_zero> to fix av500 problem we need to move mpegts to that [18:34:02] <BBB> j-b: you owe me beer [18:34:52] <lu_zero> =) [18:35:05] <lu_zero> I'm looking at the asf and the qt one [18:35:23] <lu_zero> the question is, how do you add streams properly? [18:36:16] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r75b98610a7 ffmpeg/libavcodec/ (iirfilter.c iirfilter.h psymodel.c): [18:36:16] <CIA-29> ffmpeg: cosmetics: vertical alignment and line wrap [18:36:16] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:36:26] <iive> Compn: haven't you noticed that most of mplayer development now is removing stuff and using it from ffmpeg? [18:36:27] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rd42dc217ed ffmpeg/libavcodec/ (iirfilter.c iirfilter.h psymodel.c): [18:36:27] <CIA-29> ffmpeg: Add memory allocation failure checks to ff_iir_filter_init_coeffs(). [18:36:27] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:37:26] <BBB> lu_zero: for (n=0;n<subctx->nb_streams;n++) { av_new_stream(my_ctx, -1);} etc. [18:38:50] <lu_zero> BBB: let me dig a bit more [18:39:05] <BBB> soryr, there isn't really a nice convenience function [18:39:14] <BBB> but the asf in rtp is completely chained, it's quite nice [18:39:18] <BBB> look at that as an example [18:39:40] <BBB> but then again all streams exist already in rtsp so I don't need this hack [18:39:44] <BBB> rdt uses it though [18:39:50] <BBB> maybe look at that [18:42:49] <BBB> Dark_Shikari: also, patch to review for you on ML [18:42:55] * BBB will figure out soon how git send-email works [18:43:03] <BBB> do I need a local mailserver for that? [18:43:54] <jannau> BBB: no, git send-mail --help [18:44:05] <lu_zero> you can configure it to use gmail =P [18:44:13] <lu_zero> (or any other smtp) [18:45:53] <lu_zero> ok, time to run back home ^^ [18:47:45] <lu_zero> btw [18:48:22] <BBB> ah I did [18:48:54] <lu_zero> oh [18:48:58] <lu_zero> interesting [18:49:12] <lu_zero> michael branch has the value added of libmpcodecs [18:53:03] * Compn still waiting for valid reasons to reject libmpcodecs [18:53:14] <Compn> aside from it being fugly code [18:56:18] <BBB> git send-email --compose 75b98610a7ce7acf34f583a04aaccd8c619947fe [18:56:20] <BBB> why does that not work? [18:56:25] <BBB> it says "no patch file specified" [18:56:50] <elenril> it takes a range of commits [18:56:51] <BBB> "No patch files specified!" [18:57:00] <BBB> I don't know what that means [18:57:08] <elenril> git send-email -1 to send the last commit [18:57:25] <elenril> git send email <some hash>^..<some hash> to send a specific commit [18:57:44] <elenril> git send-email origin/master to send the whole branch [18:57:48] <BBB> that sends justin's patch [18:57:52] <BBB> I want to send my own patch [18:58:16] <elenril> git send-email --compose 75b98610a7ce7acf34f583a04aaccd8c619947fe^..75b98610a7ce7acf34f583a04aaccd8c619947fe [18:58:31] <BBB> hm... [18:58:41] <BBB> can I see the revlist in some graphical way? [18:58:52] <elenril> (i suspect there's an easier way to say that) [18:58:55] <elenril> gitk [18:58:56] <lu_zero> elenril: git send-email --compose master.. might be a nice shortcut [18:59:29] <lu_zero> gitview as well [18:59:50] <BBB> omg it threw out my changes [18:59:51] <BBB> wtf [19:01:00] <elenril> what threw out your changes? [19:01:35] <BBB> git pull --rebase [19:02:05] <elenril> well yes, it does a reset --hard [19:02:23] <bilboed> unstashed data is consider as irelevant by git [19:02:39] <bilboed> s/stash/stag/ [19:03:05] <elenril> BBB: do you know about git stash? [19:03:37] <Compn> BBB : when you figure how to commit, add it to the githowto will ya? :) [19:04:31] <BBB> huh? no the patch was committed [19:04:43] <BBB> I had it committed locally, then ran git pull --rebase [19:04:49] <BBB> so I can push or send-email or so [19:04:52] <BBB> and then it threw it out [19:04:53] <BBB> wtf [19:04:55] <bilboed> that means a similar patch was already present upstream [19:05:44] <bilboed> s/patch/commit/ [19:05:45] <BBB> I can assure you it wasn't, because my patch is not present in the code anymore [19:05:49] <BBB> the code I wrote is gone [19:05:52] <BBB> gone [19:05:52] <BBB> gone [19:05:55] <bilboed> no it's not [19:05:55] <BBB> grmbl [19:05:57] <bilboed> chill [19:05:58] <bilboed> git reflog [19:06:06] <BBB> git getabrain [19:06:24] <superdump> git unshootfoot [19:06:32] <BBB> that would be wonderfulk [19:06:42] <bilboed> BBB, git reflog will show you the previous states you were in [19:06:47] <elenril> if you committed it then it's not lost [19:06:51] <elenril> git log -g [19:07:06] * elenril wonders how could that have happened though [19:07:18] <BBB> I already rewrote the patch [19:07:22] <BBB> I already have a headache [19:07:54] * elenril applauds superdump's speech [19:08:43] <bilboed> elenril, nice trick with the git log -g, much more useful than git reflog [19:09:04] <BBB> superdump: uh yeah that email is long [19:09:07] <BBB> I'm not evenhalfway it [19:09:21] <superdump> sorry for the length [19:09:29] <superdump> i hope the content is worth reading [19:09:40] <BBB> we'll see in about an hour :-p [19:09:45] * elenril thinks more people should reply and ask michael to stay [19:09:56] <superdump> i know i find gettys' blog posts too long to be bothered to read them... [19:11:36] <superdump> time for more food [19:13:40] <superdump> BBB: maybe take comfort in the fact that it took me longer to write it...? :) [19:13:45] <superdump> back in a bit [19:13:58] <uau> i thought it was kind of rambling [19:14:39] <BBB> \o/ it worked [19:17:01] <ubitux> I don't know if Rob is here on IRC, but I'd like to say I really appreciate what he says and the way he says them ('referring to the "Preliminary announcement about the current situation" thread) [19:17:57] <BBB> rob=superdump, he's here [19:18:01] * mru discovers that lossless h264 is broken [19:18:07] <uau> just quit actually [19:20:36] <Compn> mru : no fate test for it ? [19:20:44] <mru> apparently not [19:20:56] * mru bisects [19:21:14] <Compn> is it hard to make fate tests? is there a way to script up an easier run script && its done ? [19:21:33] <BBB> mru: yeah, add more fate tests [19:21:47] <Compn> so you just ./fate-add -vd file.avi , and it adds file.avi for that video decoder ? [19:21:47] <BBB> mru: do you want the IDs of those fate tests I want to run with -flags emu_edge? [19:30:18] * _av500_ wonders if thresh already went drinking for the night [19:36:15] <saintd3v> michael was actually planning on getting on irc o.O [19:36:34] <mru> so he says [19:36:50] <iive> he's been on irc before, not big deal. [19:37:12] <mru> twice in 10 years hardly counts [19:37:34] <saintd3v> iive: except that he's publicly stated he doesn't like irc =P [19:37:39] <vipw> irc is full of trolls anyway [19:37:57] <vipw> kind of like mailing lists [19:38:04] <BBB> omg he talked about the gst indent script [19:38:10] <BBB> I remember how that fucked up tables :-p [19:38:12] <BBB> anyway... [19:38:15] <BBB> </flame> [19:38:30] <bilboed> *cough* [19:38:37] <iive> saintd3v: i guess he have reason not to like it. [19:38:53] <bilboed> BBB, sure, it's not perfect... but at least we don't have to give a $#@*(%$# about indentation. Just hack :) [19:39:11] <bilboed> </nonflame> [19:39:18] <BBB> I think we should give dondiego free commit access to fix _anything_ indentation-wise [19:39:58] <iive> BBB: he can give it himself. [19:41:17] <DonDiego> oh wow, there it is [19:41:29] <j-b> BBB: no pb, you awe me more [19:41:36] <j-b> *oweù [19:41:37] <DonDiego> i'm surprised it took so long to spiral down into personal attacks against me [19:41:38] <j-b> rah [19:41:42] <BBB> j-b: indeed :-p [19:42:13] <spaam> DonDiego: the new expert maintainer? :) nice [19:42:39] <DonDiego> well, coming from the expert leader... [19:43:09] <BBB> enough... [19:43:15] <BBB> at least people have opinions now [19:43:17] <BBB> :) [19:43:25] <spaam> :) [19:43:40] <BBB> oh also I've seen more mailinglist activity than ever [19:45:20] <mru> Dark_Shikari: 2a1f431d38ea9c05abb215d70c7dc09cdb6888ab broke lossless h264 [19:46:01] <mru> http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=2a1f431d38ea9c05abb215d7… [19:46:45] <mru> or it was broken before and that fixed it [19:47:26] <lyakh> DonDiego: so, looks like indeed I'll have the car at my disposal - of course, modulo I get ill, the car breaks down, the German-Belgian border closes etc;) [19:47:31] <j-b> BBB: the latest patch on the ml ? [19:47:42] <BBB> j-b: yeah, that fixes most remaining issues for me [19:47:46] <BBB> let me try with valgrind to make sure [19:48:37] <BBB> yeah it's clean now [19:50:51] <_av500_> lyakh: but u drive on friday! [19:52:52] * Compn confused about lack of transportation, thought euro was full of trains [19:53:13] <lyakh> _av500_: nooo, you haven't convinced me, that that beer's worth it;) [19:54:02] <roxfan> trains can be a bit on expensive side when crossing borders [19:54:52] <Compn> ah [19:57:44] <Dark_Shikari> mru: oh. oops. you're right. [19:57:45] <Dark_Shikari> shit, I'm stupid [19:58:02] <thresh> _av500_: nop, i'm here [19:58:05] <Dark_Shikari> wait why is there no lossless h264 in fate [19:58:07] <Dark_Shikari> what the christ [19:58:13] <roxfan> hmm, cheapest thalys aachen-brussels is 23 euro [19:58:17] <roxfan> not bad [19:58:19] <Dark_Shikari> mru: can you just revert that, I'll fix it later [19:58:23] <mru> Dark_Shikari: I's as baffled as you are [19:58:37] <Dark_Shikari> It's not important for speed so it's not important for it to be in [19:58:42] <Dark_Shikari> and it was the last of my patches [20:00:00] <roxfan> oh hm even 15 eur [20:00:48] <Dark_Shikari> please note in the revert something about no lossless fate sample [20:01:59] <lyakh> hm, how long does fate take on a "moderate ARM?" [20:02:21] <mru> define moderate [20:02:28] <mru> 600MHz omap3 takes ~50min [20:02:52] <mru> it's spending stupid amounts of time in the filter tests [20:02:56] <Dark_Shikari> mru: does it work with lossless without that patch? [20:02:59] <mru> I have an idea to speed those up [20:03:20] <lyakh> mru: with VFPU? [20:03:43] <mru> the problem with those tests is that they produce huge output files [20:03:47] <mru> several GB of data [20:03:53] <lyakh> wow... [20:03:57] <mru> sending that over slow comms takes a while [20:04:16] <mru> I think simply checksumming it on the fly might speed it up [20:04:18] <lyakh> all under tests/data? [20:04:22] <roxfan> compress them? [20:04:34] <mru> roxfan: no point [20:04:41] <mru> all the host does is do an md5sum anyway [20:04:57] <roxfan> ah [20:05:18] <roxfan> yeah then it makes sense to do it on the device [20:05:23] <mru> the files are deleted after each test so the free space needed to run isn't too bad though [20:06:02] <lyakh> 50min with FPU? [20:06:16] <mru> with everything [20:07:39] <Dark_Shikari> mru: ok, I'll revert it [20:07:54] <_av500_> lyakh: yep, omap3 has afpu [20:08:11] <mru> of sorts [20:08:27] <lyakh> _av500_: I knew it had it, I didn't know whether it was used in that 50min test... [20:10:54] <BBB> Dark_Shikari: what's the problem? I can look into fixing it if you want [20:10:59] <BBB> I don't see the issue right now though [20:11:56] <Dark_Shikari> Oh, you want to fix it correctly [20:11:58] <Dark_Shikari> it's not hard [20:12:02] <Dark_Shikari> ok, let me explain: [20:12:08] <Dark_Shikari> 1) I converted luma dc to work A Better Way [20:12:21] <Dark_Shikari> 2) This involved adding a line or two of code to copy over luma "dc" coefficients in the case of lossless mode. [20:12:25] <Dark_Shikari> to put them in their place [20:12:30] <Dark_Shikari> 3) I did the same to chroma dc [20:12:32] <Dark_Shikari> 4) and I forgot step 2. [20:12:53] <astrange> 06:22 < kierank> astrange: any idea why version.h doesn't appear in latest ffmpeg-mt <- hmm? wfm after configuring [20:13:00] <Dark_Shikari> in short, in lossless, we don't run chroma_idct_dequant [20:13:13] <Dark_Shikari> instead we just copy the "dc coefficients" into the dct data [20:13:18] <Dark_Shikari> because they're really just one pixel each [20:13:48] <Dark_Shikari> See what luma does and it should be obvious. [20:13:56] <Dark_Shikari> If you don't want to do it today, say so and I'll revert my patch instead. [20:16:59] <BBB> where do I find the luma code? I'll see if I can decipher it [20:17:05] <BBB> also need a testcase that fails [20:17:48] <lyakh> so, guys, is there going to be any kind of an ff-meeting at fosdem? [20:18:01] <mru> a bunch of ffpeople will be there [20:18:06] <mru> meetings are bound to take place [20:18:49] <BBB> Dark_Shikari: dcmapping[]? [20:18:50] <lyakh> mru: heh, yeah, I meant like something more organised with a _certain_ time and place [20:19:05] <mru> friday night, delirium cafe [20:19:19] <mru> saturday night, $bar [20:20:02] <lyakh> ok, spontaneous and flexible;) [20:20:53] <Compn> Dark_Shikari : michael said to ping him on mails he missed if you were interested in doing that... [20:21:00] * Compn wonders why hes playing telephone to people [20:21:32] <lyakh> wooow, cool, the test has just completed!:) [20:21:41] <lyakh> 2h15' [20:22:11] <mru> what speed is that cpu? [20:23:55] <lyakh> mru: I think 500MHz [20:24:07] <pasteeater> where can i get the web site sources to patch some little html errors? [20:24:55] <mru> pasteeater: svn://svn.ffmpeg.org/ffmpeg.org/trunk [20:24:56] <BBB> mru: please send me a sample [20:24:56] <lyakh> so, where's the report and how do I submit it? I only see separate .rep files [20:25:19] <mru> lyakh: that's where the fate.sh scripts comes in [20:26:02] <pasteeater> mru: thanks. [20:26:12] <lyakh> so, having run "make fate" manually I cannot get such a report? have to re-run with fate.sh? [20:26:51] <Dark_Shikari> BBB: yes, dcmapping[] [20:27:03] <Dark_Shikari> Compn: ? [20:28:27] <mru> lyakh: the final report is made by catting all the .rep files with a header created by fate.sh, then tarring it up together with various logs of the build and test outputs [20:28:42] <mru> you could piece one together manually but I see no point [20:28:54] <lyakh> ic, nice... [20:29:01] <lu_zero> Dark_Shikari, Comp what was the question? [20:29:14] <mru> you can see what happens in the report() function in fate.sh [20:29:18] <BBB> Dark_Shikari: what is the array? 0*16 1*16 2*16 3*16? or are 1 and 2 inverted? [20:29:26] <BBB> Dark_Shikari: too lzy to look up [20:29:40] <BBB> mru: can you send me a lossless h264 sample? [20:29:46] <mru> lyakh: now there's not much point submitting a report unless you tend to run it regularly [20:29:52] <mru> BBB: yes, I will [20:29:54] <BBB> thnx [20:30:05] <mru> lyakh: and then you might as well use the proper script [20:30:24] <lyakh> mru: well, I could do it from time to time like weekly or biweekly... [20:30:43] <lyakh> but yes, will try to re-run with the script tomorrow [20:30:45] * mru should get that microconnect off av500... [20:31:14] <mru> I could have it running continuously [20:31:29] <Compn> Dark_Shikari : last reply from michael to -devel [20:32:42] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r30112adadf ffmpeg/libavcodec/iirfilter.c: [20:32:42] <CIA-29> ffmpeg: Split out Butterworth filter coeff init to a separate function. [20:32:42] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:35:36] <Dark_Shikari> BBB: Just use the start of the array, the first 4 items [20:35:42] <DonDiego> lyakh: so we have a plan? [20:35:47] <Dark_Shikari> BBB: jus tmake one with x264 [20:35:50] <Dark_Shikari> x264 input --qp 0 -o output [20:36:25] <Dark_Shikari> Compn: I know, I did ping him, and it worked [20:36:27] <Dark_Shikari> it was successful in the past [20:37:28] <lyakh> DonDiego: well, if you don't have to be there on Friday or on Saturday before 10a.m., and do not have to stay after Sunday, say, 6p.m., sure, I can give you a lift:) [20:37:39] <mru> aren't there any lossless samples in the official conformance suite? [20:38:04] <BBB> Dark_Shikari: that would overflow [20:38:15] <Dark_Shikari> BBB: ? [20:38:18] <Dark_Shikari> There are only 4 entries for chroma. [20:38:24] <BBB> Dark_Shikari: the array should be filled 4*16 entries, and the dc_mapping[] = 0*16, 1*16, 4*16, 5*16, 2*16, 3*16, [..] [20:38:24] <mru> lyakh: what, you're skipping the beer event? [20:38:33] <Dark_Shikari> BBB: um... [20:38:36] <Dark_Shikari> you're copying over 4 values. [20:38:39] <Dark_Shikari> why do you need 64 entries? [20:39:14] <j0sh_> hi guys [20:39:18] <j0sh_> lu_zero: did you ping earlier? [20:39:30] <lyakh> mru: I'm not that much interested in the "beer" part, and noone managed to justify, why I need the "event" part;) [20:39:54] <mru> lyakh: suit yourself [20:40:02] <lyakh> sure:) [20:44:04] <j0sh_> is there any interest in a composition filter [20:44:28] <j0sh_> eg, taking two (or more) streams and outputting them side-by-side [20:44:43] <merbanan> j0sh_: sure that would be nice [20:45:09] <merbanan> some 3d film folks would be happy then [20:45:19] <j0sh_> hmm didn't think of that case [20:45:21] <relaxed> j0sh_: isn't that possible with the movie and overlay filters? [20:45:55] <j0sh_> relaxed: i'll look into those [20:45:55] <BBB> Dark_Shikari: dc_mapping[] in luma puts it in 0*16, 1*16, 2*16, i.e. the DC of the coefficients, I should do the same thing here, no? the question is in what order do I place them [20:45:59] <DonDiego> mru: do you want a sparc for running fate on? [20:46:05] <Dark_Shikari> BBB: Exactly the same [20:46:10] <Dark_Shikari> for each chroma channel: [20:46:14] <Dark_Shikari> for each DC coefficient: [20:46:25] <DonDiego> lyakh: i'd like to be there on friday [20:46:26] <Dark_Shikari> place the DC coefficient in dc_mapping[dc coeff index] (index goes from 0 to 3) [20:46:34] <DonDiego> lyakh: but maybe we can share the commute home.. [20:46:38] <BBB> that's what I asked :) ok so it's 0,1,2,3 :) [20:46:40] <BBB> got it [20:46:42] <BBB> thanks [20:46:46] <relaxed> j0sh_: I don't know why I formed that as a question. It is possible with those filters. :) [20:46:46] <Dark_Shikari> oh, then you don't need dc mapping [20:47:03] <Dark_Shikari> so you do h->mb[256+c*64+idx*16] = chroma_dc[c][idx]; [20:47:28] <BBB> I just wrote that myself :-p [20:47:37] <j0sh_> relaxed: what is the 'movie' filter called? i don't see it [20:48:08] <relaxed> j0sh_: It's in the libavfilter soc branch on svn. [20:48:25] <lyakh> DonDiego: sure, you've got my email address, right? or let me pm you my mobile coordinates, in case we don't meet personally before Sunday and I don't find a way to check my main mail [20:48:36] <relaxed> j0sh_: http://ffmpeg.org/libavfilter.html [20:49:21] <DonDiego> lyakh: ok, fine [20:49:28] <relaxed> j0sh_: It's the testing ground for new filters. [20:49:49] <j0sh_> relaxed: got it, thanks [20:50:23] <astrange> Dark_Shikari: can you still get google to host a conf? [20:51:44] <Dark_Shikari> astrange: talk to BBB [20:51:47] <Dark_Shikari> it's his responsibility [20:52:13] <BBB> huh? :-p [20:52:20] <BBB> omg I haven't even started yet [20:52:23] <BBB> but yes [21:00:03] <merbanan> BBB: can you get us those unicorns also ? [21:03:02] <BBB> I will try [21:03:05] <lyakh> regarding fate: it would be nice to have some unoptimized reference for all single benchmarks just to be able to compare - which of them run way too slow on this arch, and which one benefit from optimizations... [21:03:12] <BBB> so far they weren't sure if google could afford them [21:03:25] <BBB> but if the profits for this year are as they should be, they will consider donating one [21:03:33] <BBB> then we'll have to vote (!!!!!) over who gets it [21:03:40] <BBB> or do a timeshare [21:04:14] <DonDiego> what are you talking about? [21:04:25] <merbanan> I'm going to have sex with it [21:04:36] <mru> with a unicorn? [21:04:53] <lyakh> DonDiego: whom are you asking? [21:05:09] <BBB> someone is drunk here [21:05:12] <BBB> :-p [21:05:13] <mru> merbanan: I didn't know you were a mythozoophiliac [21:05:48] <merbanan> well I'm a complex man [21:06:11] <lyakh> wow! that's a new perversion!;) [21:06:22] <DonDiego> lyakh: i want to know what this unicorn thing is all about... [21:06:29] <merbanan> BBB: but seriously we need some Android phones [21:06:29] <lyakh> ic [21:06:37] <merbanan> we have no fate test for it yet [21:06:38] <mru> lyakh: at least nobody is harmed by it [21:06:51] <j-b> was someone working on WVPK 5.1 ? [21:06:51] <mru> merbanan: for the unicorn? [21:06:51] <merbanan> except maybe me [21:07:31] <merbanan> mru: yes for the unicorn, how else are we going to talk to it [21:07:49] <merbanan> j-b: kostya was somewhat doing that [21:08:01] <j-b> merbanan: do we meet at FOSDEM? [21:08:16] <mru> j-b: we will find you [21:08:22] <mru> j-b: don't bother trying to hide [21:08:31] <merbanan> yes I will be there [21:08:33] <mru> we'll just follow the smell of frogs and cheese [21:08:37] <j-b> mru: :) [21:08:52] <j-b> mru: I have things to discuss with merbanan especially [21:08:57] <j-b> merbanan: great. [21:09:05] <superdump> i will be there too :) [21:09:32] <j-b> I'll see if Michael from linux-md will be there [21:09:43] <mru> md? [21:10:17] <lu_zero> what's that? [21:10:48] <merbanan> legacy boys [21:11:23] <mru> what's that? a 60s-style boy band? [21:11:37] <bilboed> manual decoders [21:11:37] <BBB> damnit everyone except for me goes to fosdem [21:11:43] <merbanan> http://en.wikipedia.org/wiki/MD [21:11:44] <BBB> why are there no free software conferences in the US? [21:11:54] <merbanan> pick your poison [21:11:55] <BBB> mru: still waiting for sample :-p [21:11:57] <mru> BBB: because americans are all about money [21:12:02] <pasteeater> should my web site cleanup patch include all changed pages, or do you prefer 1 patch for each updated page file? [21:12:03] <j-b> because US visa and imagration laws are fuck? [21:12:09] <BBB> yes they are [21:12:18] <j-b> +fixes [21:12:42] <lu_zero> BBB: there are [21:12:45] <bilboed> j-b, not for going to a conf. Try getting a long stay visa in Europe if you're american : bonne chance [21:12:46] <lu_zero> SCALE is great [21:12:56] <Dark_Shikari> BBB: ping me when it's fixed [21:13:03] <j-b> bilboed: oh, never tried the other way [21:13:13] <bilboed> j-b, it's... a clusterfuck [21:13:39] <lu_zero> bilboed: oh well you have enough country to get a turist visa cycle nearby ... [21:13:58] <bilboed> lu_zero, well... Schengen zone == 1 visa [21:14:01] <bilboed> lu_zero, but yes [21:14:09] <thresh> try getting any visa if you're russian [21:14:18] <bilboed> visa gets you in russia [21:14:20] <bilboed> (sorry) [21:14:24] <lu_zero> bilboed: still closer than australia vs nz vs japan vs china [21:14:25] <thresh> even funnier, try staying in Moscow if you're russian [21:14:30] <bilboed> lu_zero, totally [21:14:33] <thresh> (you need a registration and a couple of bribes) [21:14:49] <BBB> Dark_Shikari: it is, I need a test and am too lazy to make one myself [21:14:53] <lu_zero> (common "turist cycle" done by foreingers not will to bother about long term visas) [21:15:01] <BBB> Dark_Shikari: but I'll make one myself in a few minutes though [21:15:19] <bilboed> lu_zero, but I heard rumors advising against doing the 6 months in UK / 6 months in Schengen trick [21:15:29] <bilboed> lu_zero, they spot that pretty quickly [21:15:50] <lu_zero> bilboed: the trick requires at least 3-4 countries [21:16:07] <bilboed> lu_zero, yes, it's called jet-setting, but then you do that for another reason :) [21:16:21] <lu_zero> and even in that case it's better get some good excuse [21:16:22] <thresh> why would anyone want to go to europe from US anyway [21:16:32] <lu_zero> thresh: _many_ reasons [21:16:46] <bilboed> lu_zero, I've got ants in my pants so I need to ... hmm... switch countries ? :) [21:16:55] <mru> BBB: sent [21:17:23] <mru> moving around a lot can have tax benefits [21:17:37] <mru> play it right, and you won't be considered resident anywhere [21:17:49] <lu_zero> bilboed: "ants in my pants" means something specific or is just itching to move around? [21:17:55] <bilboed> mru, ... and won't have any country protecting your ass when you get in trouble [21:18:08] <merbanan> thresh: I've experienced Russian bureaucracy, can't believe they run a complete country like that [21:18:13] <bilboed> lu_zero, the second meaning + the title of a James Brown tune [21:18:15] <mru> bilboed: a citizenship still counts for something [21:18:18] <thresh> country? protecting its citizen? sounds sooo untrue :) [21:18:35] <thresh> merbanan: well the trick is they dont really [21:18:44] <bilboed> mru, riiiiight : "so, you want protection ? Right, so you owe us XXX XXX XXX EUR of unpaid taxes, cough up" [21:19:01] <mru> bilboed: I'm talking about _legally_ not paying tax [21:19:06] <bilboed> sure [21:19:08] <thresh> merbanan: all that 'power vertical' Putin built is shaky [21:19:17] <mru> at least in the UK, you only pay tax if you're resident or ordinarily resident [21:19:39] <bilboed> mru, same for all (?) EU countries [21:19:44] <mru> the meanings of which are a bit fuzzy [21:20:06] <mru> but if you spend less than 180 days per year in any one country for a few years it should work [21:20:32] <merbanan> thresh: my exwife had the pleasant experience of changing her last name in her passports, turns out you cant do that abroad ... [21:20:33] <lu_zero> mru: you still have one that you should mark as residential place [21:20:36] <bilboed> mru, the opposite is fun. Reminds me of the owner of a certain linux distro who wasn't staying long enough in his 'official' place of residence to benefit the tax exemptions. He uses his jet a lot less nowadays :) [21:20:44] <mru> lu_zero: and that can be a tax haven [21:20:46] <thresh> merbanan: bah [21:21:28] <lu_zero> mru: but then you might get people interested on you [21:21:29] <spaam> mru: so. if you stay more then 180days. they say that you live there? [21:21:32] <lu_zero> anyway [21:21:50] <bilboed> spaam, problem is proving you're living there 180 days [21:22:01] <mru> spaam: in are in the uk more than 180 days in one year you are considered resident for that year [21:22:08] <lu_zero> given how much costs travelling it might be worthy only if you like travel that much, have a job that needs [21:22:16] <lu_zero> travelling [21:22:21] <mru> but if that's a one-off and you normally live elsewhere, you're not "ordinarily resident" and don't have to pay tax [21:22:25] <mru> uk tax [21:22:31] <mru> you have to pay tax in the other country of course [21:22:40] <BBB> mru: expected md5? [21:23:02] <mru> 3ae12544549f3fcfb363694f9b23c32b [21:23:04] <BBB> MD5=42aabc74089e547a29030e071f8162d9 is what I get [21:23:07] <BBB> damnit :p [21:23:18] <mru> 42... is the bad one [21:23:20] <superdump> i think the uk rule is a little more complex [21:23:28] <superdump> there's some kind of average over four years [21:23:28] <mru> superdump: it's a lot more complex [21:23:43] <mru> there's also the question of where you are domiciled [21:23:49] <mru> which can be a third place [21:24:04] <mru> and also where the income originates [21:25:43] <mru> if you have family their location also matters [21:25:59] <mru> I wonder what they'd do if you had two separate families [21:26:08] <mru> obviously not knowing about each other [21:26:26] <mru> the taxman in each country would be told about the other one [21:26:47] <BBB> mru: oh I did sth. stupid [21:28:24] <lu_zero> mru: still, the best is picking a good place in australia, make it your own country hail the queen and live happy [21:32:26] <superdump> or be a completely crazy person and pay taxes... [21:32:51] <mru> or be a stark raving mad person, move to sweden, and pay taxes [21:33:52] <lu_zero> mru: I'd do [21:34:07] <mru> what, move to sweden? [21:34:08] * lu_zero is paying more than he'd pay in Sweden [21:34:14] <mru> oh [21:34:16] <lu_zero> eh [21:34:24] <mru> uk is less than sweden [21:34:48] <lu_zero> and at least in Sweden there are good services given for the taxes paid [21:35:00] <pJok> sweden has low taxes [21:35:06] <mru> lu_zero: that's what they want you to believe [21:35:20] <pJok> except the 30% fee that the employer has to pay the state directly [21:35:29] <mru> sure, healthcare is decent, provided you make it through the queues before you die [21:35:38] <mru> pJok: that's also tax [21:35:44] <pJok> mru, no no... its a fee! [21:35:46] <pJok> ;) [21:35:58] <mru> uk has "employer's national insurance" though [21:36:04] <mru> which is roughly the same thing [21:36:36] <mru> if it's a percentage of income, it's a tax [21:36:46] <lu_zero> pJok: that 30% what would encompass? [21:36:59] <pJok> lu_zero, its actually a tax, but its not sold as one [21:37:01] <mru> also don't forget the 25% VAT [21:37:02] <thresh> hehe, some say we Russians pay a lot of taxes as well. Though our taxes are mostly bribes. [21:37:14] <mru> and the property tax [21:37:16] <pJok> mru, food has lower VAT unlike denmark [21:37:25] <mru> food as zero VAT in uk [21:37:28] <mru> has [21:37:45] <mru> food really is much cheaper here [21:37:46] <lu_zero> here is a flat 20% over almost everything ^^; [21:37:55] <thresh> imagine every time you are stopped by the road police, you have to pay him. true story. [21:38:25] <pJok> thresh, you'd be stopped a lot more often then [21:38:46] <BBB> blegh I keep getting different output [21:39:09] * pJok ponders on working in sweden now that the advantage of getting a higher pay in denmark is shrinking [21:41:40] <superdump> i'm inclined to think sweden is generally expensive, but it's difficult for me to tell living in stockholm [21:41:45] <thresh> pJok: well they know places with non-obvious or erroneus traffic lane markings where you are doomed to violate it (especially on federal highways etc).. that's where they feed [21:42:07] <spaam> superdump: everything is expensive in fjolltrÃ€sk [21:42:14] <superdump> i lived in the countryside in england the the nearby town wasn't so big [21:42:57] <spaam> but you can earn more $$$ in stockholm then rest of sweden. [21:43:35] <superdump> but the total cost of employing someone for the same money for them after tax is a lot higher than in the uk [21:43:37] <mru> property is very expensive in stockholm [21:43:49] <mru> public transportation is cheap [21:43:57] <mru> and actually quite good [21:44:03] <superdump> sl card for one month is 670kr methinks [21:44:12] <mru> that's very cheap [21:44:20] <lu_zero> that's something I don't like much about sweden [21:44:23] <lu_zero> non-euro [21:44:31] <mru> non-euro is cool [21:44:34] <spaam> yeah [21:44:34] <lu_zero> depends [21:44:37] <superdump> i don't give a crap, but then uk uses gbp anyway [21:44:37] <mru> all hail the queen [21:44:40] <superdump> :) [21:45:22] <BBB> I think I do the same as luma, but output is still different from what mru just said [21:45:32] <BBB> Dark_Shikari: probably best to revert until I get a better handle of this shit [21:45:48] <lu_zero> BBB: shift it on a branch [21:45:54] <Dark_Shikari> BBB: before you do that [21:46:04] * Dark_Shikari quickly checks, one moment [21:47:13] <Dark_Shikari> Oh hmm, nevermind. Show me the patch and I can look at it [21:47:25] <Dark_Shikari> actually can you PM me the patch? wireless is horribly broken atm [21:47:32] <BBB> ok [21:47:32] <Dark_Shikari> so I can't open new connections [21:48:19] <superdump> mru: i do wonder where the money goes though [21:48:29] <superdump> sweden has better internet infrastructure from what i can tell [21:48:40] <superdump> seems cleaner and greener [21:48:54] <mru> much of the internet infrastructure is privately funded [21:48:56] <superdump> healthcare is more expensive :) [21:49:26] <superdump> perhaps pensions and unemployment benefits are better [21:49:41] <mru> I'm not afraid of unemployment [21:49:52] <superdump> you grab it by the horns [21:50:02] <mru> no, by the ARMs [21:50:06] <superdump> hehehe [21:52:50] <pasteeater> superdump: what do you think should be done to the site to make it not "in the dark ages"? [21:53:07] * mru likes it the way it is [21:53:17] <mru> we don't need no stinkin web 2.0 [21:53:29] <kierank> needs more <video> tag [21:53:31] <kierank> dih [21:53:32] <kierank> duh* [21:54:53] <superdump> pasteeater: well i'm no web developer and i did the current CSS and stuff :) [21:55:32] <pasteeater> i was just wondering what you didn't like about it. [21:56:07] <superdump> i think it's more about the content than the pages themselves i guess [21:56:18] <superdump> plus i still hate the makefile crap [21:56:31] <astrange> ffmpeg.org isn't going to be used for much anyway [21:56:40] <mru> huh? [21:56:56] <superdump> mostly i think effort needs to be put into documentation and what information is where [21:57:03] <astrange> well i see http://ffmpeg.org/projects.html is a useful page and the text is rather off-center, that's something [21:57:25] <superdump> i think it should be structured according to the viewers interests [21:57:30] <mru> yeah, those columns should be centred [21:58:09] <astrange> there's a pr problem with the hall of shame page, eg for mediacoder it links to the bug tracker entry which mostly contains the author of mediacoder complaining about it [21:58:17] <astrange> people read it and don't see what the problem is or think he's right [21:59:07] <superdump> as i recall i split the content into four main sections - obtaining ffmpeg (source/binaries), using ffmpeg command line utilities, developing using libav* apis and contributing to ffmpeg development [21:59:48] <superdump> last time i looked there were multiple help documents covering the same topics [21:59:55] <BBB> mru: MD5=3ae12544549f3fcfb363694f9b23c32b after revert... ok to commit that? [22:00:15] <mru> BBB: you gave up fixing? [22:00:22] <superdump> and i really think something like a wiki, on ffmpeg.org, would be good for managing documentation so that non-coders could contribute [22:00:59] <superdump> we could use the multimediawiki, but i really think it should be on ffmpeg.org so that it is easily accessible and easy to find [22:01:02] <spaam> hey and welcome spam spam spam [22:01:09] <kierank> yeah wiki = spam spam spam [22:01:23] <lu_zero> reg only wiki -> fine [22:01:36] <mru> superdump: we could point wiki.ffmpeg.org at multimediawiki easily enough [22:01:57] <spaam> still you can get some spam there lu_zero ;) we have that problem sometimes on redmine.lighttpd.net ;D [22:01:58] <BBB> mru: yes... I tried the same as luma but it didn't fix it correctly... [22:02:05] <BBB> so D_S suggests just reverting for now [22:02:21] <spaam> lu_zero: but sure. its not that much. [22:02:23] <mru> let's do that then [22:02:29] <mru> I'll add a test [22:04:24] <superdump> mru: or a subsection of mm.cx... yeah [22:05:46] <lu_zero> spaam: I'd say redmine is at fault [22:06:18] <lu_zero> but I'm not sure it is really redmine fault since I hadn't read its code [22:06:34] <superdump> heading off now [22:06:36] <superdump> have fun [22:25:30] * BBB tries another round of git send-email [22:25:43] <BBB> how do I push one patch that I committed but not another? [22:26:47] <mru> where is the commit you want to push in relation to origin? [22:27:40] <mru> here's a method that always works: [22:27:44] <mru> git checkout -b tmp [22:27:49] <mru> git rebase -i origin [22:27:59] <mru> [remove anything not ready for push] [22:28:05] <mru> git push origin tmp:master [22:28:30] <mru> git rebase origin master [22:28:37] <mru> git branch -d tmp [22:29:05] <mru> that's often overkill though [22:29:31] <mru> if you just want to push a single commit immediately following origin, you simply [22:29:38] <mru> git push origin $hash:master [22:29:48] <mru> where $hash is the rev hash of the commit in question [22:29:58] <mru> that works for any sequence on top of origin of course [22:30:24] <BBB> ok [22:30:26] <BBB> I'll try that [22:30:32] <BBB> I think my email didn't arrive this time [22:33:24] <jannau> michael asked what's the best way of importing changes from git.ffmpeg.org into git.videolan.org [22:34:46] <jannau> git merge would be currently the cleanest solution except that merge commits are disallowed [22:34:54] <j-b> cherry-pick ? [22:34:54] <BBB> ah there it is [22:35:15] <mru> lots of cherries [22:35:25] <BBB> that's because we finally develop again [22:35:29] <BBB> mru: can you ok the patch? [22:35:31] <jannau> but I guess it will get ugly once we cherry pick from git.videolan.org [22:35:32] <BBB> then add a fate test? [22:35:44] <mru> fate test is already written [22:36:03] <mru> I'll send it for review and push it tomorrow when fate servers have synced [22:36:12] <jannau> so I think git cherry-pick -x is best the solution [22:40:53] <_av500_> mru: about the 7109, it sits unused here [22:41:04] <_av500_> id be glad to have it run fata [22:41:08] <_av500_> fate too [22:42:02] <mru> _av500_: let's put it to use then [22:42:19] <_av500_> i just have 0 st knowledge [22:42:27] <mru> I have some [22:42:28] <lyakh> damn, just realised - that 2h15' was a bs - I used a config for profiling... [22:42:41] <lyakh> with all optimizations off etc;) [22:42:45] <Dark_Shikari> yay, we're in a contest to out-commit michael [22:43:11] <_av500_> Dark_Shikari: remember, we are polite and friendly too now [22:43:40] <mru> _av500_: you can either "lend" me the board, or I can drop by when convenient and set it up if you don't know how [22:43:51] <_av500_> mru: both will work [22:44:07] <mru> handover at fosdem? [22:44:13] <_av500_> its huge [22:44:17] <mru> how huge? [22:44:23] <_av500_> [ ] [22:44:40] <_av500_> mru: ill have a look [22:44:46] <_av500_> the box is huge [22:44:53] <mru> the box is always huge [22:45:41] <_av500_> ok [22:46:16] <mru> if it really is too big for a standard plane cabin case, we'll do something else of course [22:46:17] <_av500_> mru: i have a corporate fedex account :) [22:46:20] <mru> ah [22:46:24] <mru> works for me [22:46:34] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r8bcfe7f7fd ffmpeg/libavcodec/ (h264_cabac.c h264_cavlc.c): [22:46:34] <CIA-29> ffmpeg: Set gray (128) U/V planes for chroma-less samples. Fixes two fate samples [22:46:34] <CIA-29> ffmpeg: when played with -flags emu_edge. [22:46:41] <lyakh> yeeks... no... it was "-g -O3"... hmmm [22:46:45] <mru> I do have a 7109 board already [22:46:48] <BBB> shit [22:46:50] <BBB> it committed both [22:46:53] <BBB> sorry guys [22:46:54] <mru> but I'm not entirely sure it works [22:46:55] <CIA-29> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r66c6b5e2a5 ffmpeg/libavcodec/ (10 files): Revert 2a1f431d38ea9c05abb215d70c7dc09cdb6888ab, it broke H264 lossless. [22:47:01] <BBB> now what do I do? [22:47:15] <mru> nothing [22:47:16] <Dark_Shikari> Isn't that fine? [22:47:17] <_av500_> undi [22:47:19] <_av500_> undo [22:47:28] <mru> the other patch looked fine to me [22:47:31] <BBB> the first patch wasn't approved yet I think [22:47:33] <mru> but I'd rather have Dark_Shikari say so [22:47:59] <mru> it's the patch you mailed, right? [22:47:59] <Dark_Shikari> Now it's approved. [22:48:07] <Dark_Shikari> BBB: in the future, push pushes ALL your patches. [22:48:31] <BBB> yes it's the one I mailed [22:48:34] <mru> oh well, no harm done [22:48:49] <BBB> Dark_Shikari: so how do I push just one? mru said origin hash:master, I did that but it pushed both [22:49:03] <mru> that pushes everything between origin and $hash [22:49:09] <BBB> oh [22:49:14] <mru> I said do that if $hash immediately follows origin [22:49:21] <mru> and you have more work on top that's not ready [22:49:26] <BBB> oh, I thought origin was my local head [22:49:35] <BBB> I'm confused by these terms [22:49:37] <mru> origin is remote head, give or take [22:53:14] <BBB> got it [22:57:36] <DonDiego> pasteeater: what about the website? [23:02:19] <DonDiego> omg, libmpcodecs... [23:02:31] <DonDiego> mru: what's the status of zlib? [23:02:34] <Dark_Shikari> lol yes he merged it [23:03:09] <mru> DonDiego: I need to fix a bug [23:03:19] <mru> and I will fix it, but not tonight [23:03:27] <DonDiego> sure [23:03:28] * Compn still wants valid reasons to nix libmpcodecs :P [23:03:33] * Compn afk now tho [23:03:43] <DonDiego> we should look out for distinctive features [23:06:00] <DonDiego> should i make the ffmpeg.org commits go to -commits? [23:09:58] <DonDiego> mru: i'll look at build system stuff tomorrow when i'm properly awake [23:10:01] <DonDiego> gnite guys [23:18:08] <saste> hi all [23:18:31] <mru> hi saste [23:18:37] <saste> hi mans [23:30:53] <lyakh> wow... just noticed and read that "maintenance" thread... seems like a tough time for the project... [23:32:09] <lyakh> ok, gn8 all [23:47:26] <mru> http://gmane.org/ [23:47:30] <mru> look at the top 10 [23:57:55] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rfcdf0a43cd ffmpeg/libavcodec/ (iirfilter.c iirfilter.h): [23:57:55] <CIA-29> ffmpeg: Add biquad high-pass and low-pass IIR filters. [23:57:55] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [23:58:03] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r0361d13cf3 ffmpeg/libavcodec/iirfilter.c: [23:58:03] <CIA-29> ffmpeg: iir: change filter type if/else to a switch. [23:58:03] <CIA-29> ffmpeg: Simplifies error handling and makes it easier to add additional filter types. [23:58:03] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com>

1 0

IRC log for 2011-01-19
by irc＠mansr.com 20 Jan '11

20 Jan '11

[00:00:19] <lu_zero> who? [00:00:55] <DonDiego> you maybe or janne [00:01:55] <lu_zero> everybody is ok with this text? [00:02:04] <DonDiego> or dunno, lots of names there :) [00:02:22] <DonDiego> just a sec [00:03:40] <{V}> are you going to list all the names again (instead of the undersigned). If you don't, then it's not really the undersigned. [00:04:55] * {V} hopes he's making sense [00:05:17] <DonDiego> http://pastebin.com/dsG3J2kB [00:13:01] <lu_zero> I like the change better [00:15:02] <lu_zero> yai [00:15:09] * lu_zero eventually fixed ssmtp [00:16:21] <jannau> DonDiego: ok [00:17:29] <jannau> lu_zero: I use msmtp [00:19:03] <jannau> and should send it, it'll be hard to deny that you wrote it [00:19:58] <DonDiego> whoever feels like sending, send [00:21:31] <DonDiego> good evening robert [00:34:01] <lu_zero> I'd like to have a list of people as well (on that email) [00:34:06] <lu_zero> and it's getting late here [00:36:01] <superdump> ahoy [00:59:13] <DonDiego> gnite [00:59:38] <DonDiego> too late, i sent the email [00:59:51] <DonDiego> a list of names might not have hurt though [00:59:59] <DonDiego> i'm too tired [01:00:04] <DonDiego> gnite [01:23:45] * saintdev wonders where diego sent the email to... [01:24:34] * mru too [01:25:00] <saintdev> /dev/null(a)localhos.tr perhaps? [01:26:15] <Kovensky> perharps lu_zero will have to share his expertise in fixing sendmail? =p [01:26:22] <saintdev> lol [01:30:35] <BBB> does anyone see harrypottersample.avi on incoming? [01:30:38] <BBB> I can't find it [01:30:43] <mru> it's been deleted [01:31:13] <mru> by someone using the 'mplayer' ftp account [01:31:34] <mru> someone in austria [01:31:35] <BBB> uh... [01:31:39] <mru> carl eugen probably [01:31:49] * mru is looking at server logs [01:32:04] <Jumpyshoes> hrm, is it possible to obtain access to the roundup samples? [01:32:34] <BBB> Jumpyshoes: on request, I can give you the samples... [01:32:45] <Jumpyshoes> oh, okay [01:32:48] <BBB> just mention which one you're looking for [01:32:58] <Jumpyshoes> i remember that one time i accidently deleted a sample i had and couldn't find it [01:33:01] <BBB> one of the server admins can help you get access if they feel like it'd help [01:33:02] <Jumpyshoes> but i don't need anything atm [01:35:10] * mru is going through a huge moderation queue [01:35:30] <mru> the listed moderators are obviously not doing their jobs [01:37:58] <bcoudurier> feel free to do better [01:38:31] <Kovensky> bcoudurier: isn't that precisely what he's doing atm? =p [01:38:51] <bcoudurier> doing it once is easy [01:39:11] <mru> I used to go over the list regularly [01:39:33] <mru> if you do it once a week, it doesn't take long [01:39:52] <mru> bcoudurier: if you don't want to be official moderator, just say so [01:47:38] <BBB> mru: so who deleted the file? [01:47:46] <BBB> can it be recovered or should I ask for it to be reuploaded? [01:47:52] <BBB> and can the account of that person be disabled? [01:47:58] <mru> chello080108089202.30.11.tuwien.teleweb.at deleted it [01:48:11] <mru> he used the shared mplayer account [01:48:35] <mru> about 1h after it was uploaded [01:49:07] <iive> i thought that account is to only read files. [01:49:15] <iive> are you sure it is not moved? [01:49:23] <mru> Thu Nov 25 01:29:00 2010 [pid 21631] [mplayer] OK DELETE: Client "80.108.89.202", "/incoming/harrypottersample.avi" [01:49:30] <mru> that's the ftpd log file [01:49:50] <mru> it was downloaded before that [01:50:05] <mru> and deleted 30s later [02:08:50] <BBB> mru: that sucks sucks sucks [02:09:00] <BBB> ok, I'll ask them to reupload [02:09:10] <BBB> mru: should we change the incoming shared pwd? [02:09:13] <BBB> or make it read-only? [02:09:23] <BBB> this isn't terribly useful [02:15:19] <Dark_Shikari> http://it.slashdot.org/comments.pl?sid=1956008&cid=34922474 [02:19:21] <Jumpyshoes> LOL [02:20:54] <Dark_Shikari> Jumpyshoes: so do you have a patch to fix things yet? [02:20:55] <Dark_Shikari> if so send it to th eml [02:21:49] <Jumpyshoes> oh, i don't actually know if it fixes his issue, since i can't get vlc to crash :/ [02:24:44] <roxfan> heh, didn't see this version (with the second part) before [02:25:13] <Dark_Shikari> Jumpyshoes: It's a bug though. [02:25:16] <BBB> time to read lu_zero's patches [02:25:17] <mru> roxfan: jokes grow with time, you know [02:25:25] <Dark_Shikari> Sumbit it and note that it isn't tested. [02:25:29] <Dark_Shikari> And if he comes back on, update your thread [02:25:31] <Jumpyshoes> Dark_Shikari: okay [02:26:01] <roxfan> i've seen versions with mathematicians and programmers [02:26:58] <mru> back in those days, it was popular to include microsoft in it [02:27:17] <mru> now they're not even worth making fun of anymore [02:30:34] <Dark_Shikari> http://seattletimes.nwsource.com/html/technologybrierdudleysblog/2013964154… [02:32:54] <Jumpyshoes> Dark_Shikari: sent patch to ml [02:34:06] <Dark_Shikari> If the guy who reported the bug doesn't come on, we'll commit it anyways as long as it passes fate with emu edge on [02:34:47] <Jumpyshoes> k [02:36:20] <mru> BBB: yep, it was carl eugen who deleted the file [02:36:27] <mru> or someone with his IP address at any rate [02:46:41] <BBB> sad :( [02:47:22] <mru> I wonder why [02:51:51] <BBB> I'll email him [02:52:17] <BBB> Dark_Shikari: did you look at jumpyshoes' patch? [02:53:59] <BBB> more lines deleted than added is generally weird for a bugfix in optimizations, but I'm intrigued nonetheless [02:57:45] <BBB> mru: "(And no, I don't remember the file.)" [02:57:51] <BBB> is his response, plus some other stuff [02:58:24] <Jumpyshoes> BBB: only the first edge needs to be accessed [02:58:38] <Jumpyshoes> BBB: in the case of no top_right, the left edge is duplicated [02:58:59] <BBB> right, same for vp8 [02:59:00] <Jumpyshoes> BBB: the old code was fixing that AFTER accessing the top left edge [02:59:01] <mru> BBB: more - than + can come as a result of moving something so a constant no longer needs to be reloaded or similar [02:59:20] <BBB> hm, baby cries [02:59:22] <BBB> one sec [02:59:25] <Jumpyshoes> BBB: so if you move the check up, it gets rid of the part i got rid of [02:59:46] <Jumpyshoes> BBB: this *may* apply to other predicts, but i'm a bit busy atm, so i'll check it later [03:18:46] <Dark_Shikari> hey, michael is back [03:18:49] <Dark_Shikari> fflames time [03:19:13] <Compn> lol [03:19:20] <Compn> someone paste to me what happened for an hour [03:19:25] * Compn curses internet [03:20:13] <Dark_Shikari> Michael is back, so flllaaammmesss time [03:21:06] <Jumpyshoes> i expect him to come on irc in ~secret~ mode [03:21:25] <Compn> Dark_Shikari : can you copy/paste the last hour of #ffmpeg-devel to me ? [03:21:38] <Compn> who michael? i dont think i've ever seen him [03:23:07] <Dark_Shikari> Nothing important [03:23:14] <Dark_Shikari> Last hour was just a discussion about Jumpyshoes' bugfix [03:23:48] <Compn> ah [03:23:49] <Compn> ok thx [03:28:11] <Compn> hmm [03:28:24] <Compn> now i cant remember if i asked bcoudurier about being ffmpeg list moderator [03:28:40] <Compn> i asked michael, he said to ask other mods [03:28:49] * Compn sees no other mails [03:31:15] <Compn> who is avcoder ? [03:31:19] <BBB> Jumpyshoes: I think it looks good to me... have to admit here though, I'm a little confused, b/c vp8 does the topright-setting from the C code [03:31:43] <BBB> Dark_Shikari: what's the story there? either h264pred does it in asm where it shouldn't, or vp8 does it in c where it shouldn't [03:31:47] <BBB> there's cycles to be won here [03:32:24] <BBB> but admittedly if that's how h264.c does it (seems that way), that's fine [03:32:31] <Compn> nextplayer guy it seems, nm [03:32:36] <Dark_Shikari> BBB: ? [03:32:40] <Dark_Shikari> it's not about cycles [03:32:45] <Dark_Shikari> it's about "in emu edge, does it crash on the top row" [03:33:13] <BBB> true [03:33:28] <BBB> but what I mean is: should the branch be there? [03:33:34] <Dark_Shikari> why not [03:33:37] <Jumpyshoes> the branch needs to be there [03:33:37] <BBB> (unrelated to jumypshoes' patch) [03:33:53] <BBB> and if so, why does vp8 have that same if in the calling code? [03:35:21] <BBB> anyway n/m about it, I'm probably confusing you [03:35:30] <BBB> mayme baby makes my brains spongy [03:36:15] <BBB> I ran fate once using emu_edge [03:36:16] <BBB> let me check [03:36:35] <Dark_Shikari> it might only crash on some OSs [03:36:36] <Dark_Shikari> or by luck [03:36:40] <Dark_Shikari> based on whether those bytes are outside the page [03:37:49] <BBB> in tests/fate/h264.mak, do a search-and-replace on "framecrc" to "framecrc -flags emu_edge" [03:37:54] <BBB> then re-run make fate-h264 [03:38:18] <astrange> valgrind it? [03:40:04] <BBB> jumpy has win, I have mac [03:40:06] <BBB> no valgrind [03:41:19] <astrange> valgrind works fine on os x [03:41:57] <BBB> a while ago I needed to manually patch it to compile and run on 10.6... [03:42:51] <astrange> there were more releases since then, 3.6 has working memcheck [03:42:57] <astrange> svn has working helgrind [03:43:37] <BBB> hm, I guess I haven't checked it out in a while [03:43:38] <BBB> will re-check [03:45:22] <BBB> astrange: submit ffmpeg-mt patch [03:45:32] <BBB> let's applt and fix whatever we find to be broken [03:48:32] <Jumpyshoes> uhhhhh BBB i did what you said and fate-h264 fails without any asm period <_< [03:49:29] <astrange> fixing review comments introduced valgrind failures, working on it [03:50:21] <Jumpyshoes> hrm, reimar was the guy checking issue 2524, this is going to be an issue if he's pissed [03:50:49] <BBB> seriously? [03:50:51] <BBB> let me check [03:51:14] <astrange> even if you want experimental but workingish code in trunk i think you don't want fate failures [03:51:28] <BBB> which one fails, Jumpyshoes ? [03:51:40] <BBB> astrange: depends on which fate failures [03:51:49] <BBB> and how long it'll take us to fix it :) [03:52:04] <BBB> fate-h264-conformance-frext-hpcamolq_brcm_b fails for me with emu_edge set [03:52:31] <mru> for all we know emu_edge has never worked [03:52:40] <Jumpyshoes> BBB: h264-conformance-frext-hpcamolq_brcm_b [03:52:48] <mru> how does it fail? [03:53:01] <BBB> mru: no it worked a month ago [03:53:05] <BBB> I test it every once in a while [03:53:08] <astrange> h264 uses emu edge for PAFF [03:53:11] <astrange> always [03:53:13] <Jumpyshoes> http://ffmpeg.pastebin.com/YqwysSRn [03:53:18] <astrange> so it gets some testing [03:53:21] <BBB> Jumpyshoes: ok, will work on it [03:53:27] <Jumpyshoes> at least i know i didn't blow it up! [03:53:31] <Jumpyshoes> ... i think [03:54:44] <astrange> http://pastebin.com/XF0gbfwU [03:54:45] <{V}> BBB, you want to apply the ffmpeg-mt patch and then fix ? does that pass the new/restated "All changes shall be reviewed and approved by at least one other developer competent in the affected area. This rule applies equally to the maintainer team." rule [03:54:57] <{V}> ? [03:55:14] <BBB> not necessarily in that order [03:55:19] <BBB> but ffmpeg-mt needs to get done [03:55:22] <BBB> it can't sit around forever [03:55:23] <{V}> okay [03:55:25] <BBB> it needs >1 hand [03:56:24] <BBB> hm, h264 failures... [03:56:36] <BBB> astrange: post patch again, I'll try to look into them [03:57:01] <astrange> that's my master. the patch is large [03:57:33] <j-b> To be honest, as a huge libavcodec user, the only thing I care about now is -mt [03:57:37] <astrange> git diff mainline/master master|pbcopy [03:57:42] <Jumpyshoes> what is -mt? [03:57:43] <astrange> oops [03:57:46] <astrange> http://pastebin.com/6u9m2QVg [03:58:05] <j-b> Jumpyshoes: libavcodec-fast :D [03:58:15] <{V}> Jumpyshoes, multithread [03:58:21] <Jumpyshoes> j-b: ooh, i see [03:58:27] <astrange> that's also the tree i'm typing stuff in right now so i think it crashes at the end of decode [03:58:52] <astrange> oh, diff to last commit so safer than that [03:58:55] <Jumpyshoes> BBB: i suspect my asm *does* break emu_edge... so you should disable it when testing [03:59:02] <BBB> Jumpyshoes: ok [03:59:04] <j-b> yes [03:59:07] <BBB> will have a quick look at it [03:59:10] <BBB> got valgrind now [03:59:12] <j-b> svn HEAD is broken for me [03:59:22] <BBB> will fix [03:59:29] <BBB> we need emu_edge in fate :) [03:59:40] <Jumpyshoes> BBB: k, i'm busy for the next few days, but i'll fix my asm eventually [03:59:43] <j-b> I can't release VLC 1.1.6 with svn HEAD, because some h264 main and high are broken [03:59:43] <BBB> mru: can we repeat the vp8 trick in h264 and some other popular codecs also? [03:59:54] <j-b> I need to find an older rev :) [04:00:02] <mru> running all the h264 tests twice will take insanely long time on the slower machines [04:00:16] <astrange> you only need to run one mbaff test and one progressive test [04:00:24] <mru> could we find a nice subset that's likely to trigger any bugs specific to emu_edge? [04:00:34] <astrange> oh, i guess not if you have to cover all the predict modes. not sure what's good for that [04:00:53] <mru> and make sure MVs actually go off the edge [04:01:48] <BBB> I can look into that for the next dew days [04:01:53] <BBB> right now, about 5 of them break [04:01:54] <Jumpyshoes> mru: the frext* stuff breaks h264 very nicely [04:01:56] <BBB> that might be enough [04:01:57] <Jumpyshoes> when i was testing [04:02:00] <Jumpyshoes> my asm [04:02:17] <Jumpyshoes> conformance(not frext) doesn't even trigger retarded bugs in predict [04:02:32] <mru> guess why all those tests are there [04:02:57] <Jumpyshoes> i mean, if you want a few tests for the edge cases, frext is good [04:03:15] <mru> frext uses more fancy prediction modes [04:03:22] <mru> other tests use other features [04:03:24] <Dark_Shikari> i8x8, yes [04:03:36] <Jumpyshoes> ah, i see [04:03:40] <Dark_Shikari> i8x8 is frext only [04:04:16] <mru> for testing emu_edge we need tests that invoke that function in all modes [04:04:37] <mru> which may or may not be frext [04:04:47] <Dark_Shikari> only frext includes i8x8 [04:05:01] <BBB> hm, some are 100% broken... [04:05:02] <BBB> not good [04:05:05] <BBB> even w/o asm [04:05:18] <mru> Dark_Shikari: yes, but that's no reason to assume they use _all_ modes [04:09:30] <BBB> wasn't there this thing called git bisect? [04:09:35] <BBB> seems I should try that here [04:09:36] <mru> yes [04:09:46] <BBB> anyone got a howto? [04:09:52] <mru> man git-bisect [04:10:35] <astrange> git help bisect, too [04:10:41] <astrange> goes to the same place [04:10:42] <mru> same thing [04:10:55] <mru> man is one keystroke less [04:27:35] <BBB> Dark_Shikari: have you tested your recent commits with emu_edge? [04:28:25] <Dark_Shikari> no, but my commits didn't affect intra pred at all [04:28:39] <Dark_Shikari> they don't eve read neighboring pixels [04:28:39] <Dark_Shikari> afaik [04:32:16] <saintdev> \o/ MN woke up. ffdrama continues [04:58:35] <BBB> Dark_Shikari: it's not intra pred related [04:58:50] <BBB> Dark_Shikari: it's simply that emu_edge is broken for a few files... not related to intra pred or anything afaics [04:59:01] <BBB> I'll figure out which commits did it tomorrow [04:59:05] <BBB> hopefulyl :-p [05:06:05] <BBB> so if I want to change my git co to some other revision, I do git pull hashtag? [05:06:36] <Dark_Shikari> git checkout HEAD~100 will check out a revision 100 ago. [05:06:43] <Dark_Shikari> or git checkout <revname> [05:07:59] <BBB> ok, on it [05:08:09] <BBB> although I'm falling asleep... [05:08:44] <Jumpyshoes> sleep [05:19:19] * elenril yawns [05:19:35] * elenril is disappoint by the amount of drama mails [05:20:01] <saintdev> elenril: lol [05:20:11] <saintdev> elenril: MN finally woke up! [05:33:26] <kierank> elenril: yeah i expected a massive drama thread [05:34:54] <elenril> how boring, there's more flames over in #mplayerdev [05:35:17] <astrange> not enough time [05:36:34] <saintdev> you mean i have to join another channel to observe the ffdrama? [05:38:41] <Jumpyshoes> lol, more drama in another channel about this project? [05:39:03] <relaxed> not really [05:40:09] <elenril> no, it's unrelated [05:40:41] <relaxed> mplayer is in a state of limbo now [05:42:08] <Jumpyshoes> oh [05:46:13] <Dark_Shikari> mplayer has been in limbo for a few years now [05:46:49] <relaxed> well true but now they have to figure out what to do since svn won't be updated. [05:46:54] <elenril> uau's fork got quite many new features [05:47:40] <peloverde> they should switch to hg... mix things up [05:48:36] <Dark_Shikari> hahahahaha [05:50:13] <relaxed> elenril: yeah, I wouldn't mind seeing his fork made into the official repo. [05:50:54] <elenril> so why didn't any insurgents reply to the drama [05:51:11] <astrange> they went to sleep [05:51:37] <astrange> i got lost on what happened to git on videolan [05:51:49] * elenril sees Dark_Shikari awake [05:52:11] <astrange> maybe it was supposed to be preserved with michael in maintainer but that wasn't actually mentioned? [05:52:40] <saintdev> peloverde: only if they make their commit ml mplayer-gitlog! [06:09:49] <thresh> hmm, no drama [06:11:13] <thresh> what's that about old messages (from Nov f.i.) being sent to ffmpeg-devel? [06:12:03] <astrange> the email moderation queue got stuck [06:12:43] <thresh> ah k [07:51:44] <spaam> God morgon [07:56:06] <wbs> nice split we're having... [07:59:12] <peloverde> the other side is far better [07:59:32] <spaam> :) [07:59:43] <wbs> it usually is :-) [08:26:17] <cartman> moin [08:27:27] <lu_zero> good morning [08:27:58] <superdump> ? [08:27:59] <saintdev> netsplit over! [08:28:00] <saintdev> that was a long one [08:28:14] <superdump> ouch [08:28:21] <superdump> i'll say that again then... [08:28:23] <superdump> morning [08:28:30] <kshishkov> hejsan [08:28:36] <Guest95325> moin [08:28:39] <Guest95325> whoa [08:28:54] <KotH> günaydin Guest95325 [08:29:34] <cartman> moin moin [08:29:37] <elenril> kshishkov: dunno, kinda unfunny [08:29:37] <elenril> wtf? [08:29:37] <elenril> kshishkov: maybe i'm deformed by doing this trick constantly in QFT [08:29:37] <pJok> kshishkov, i think bigs are flying now... swscale cleanup, mans is back... [08:29:37] <elenril> o_0 [08:29:37] <elenril> nice one, freenode [08:29:37] <pJok> was there a split? o_O [08:29:37] <pJok> ah yes [08:29:37] <pJok> 2 hours ago [08:29:44] <spaam> pJok: fail ;P [08:30:18] <kshishkov> elenril: well, "multiplying by complex conjugate" and saying then "...got REAL" is funny for me [08:30:18] <saintdev> pJok: you forgot: MN is no longer leader [08:30:41] <cartman> Android has no posix_memalign [08:30:43] <cartman> pffft [08:30:49] <16SAAYUNZ> why did unidentified me bump identified me? [08:30:54] <superdump> i thought it was funny too [08:31:05] <superdump> in a big and obvious humour kind of way [08:31:07] <pJok> saintdev, ah yes, hell did freeze over [08:31:12] <kshishkov> pJok: yes, nothing beats a flock of flying pigs [08:31:23] <saintdev> DonDiego: there's the mail, made it through this time [08:31:34] <thresh> moroning, fellow ffmpeg developers [08:31:49] <saintdev> can pigs fly in frozen hell? I would think it's too cold for them [08:32:02] <kshishkov> pJok: as we say here "if hell freezes over or pigs fly, it will cause delays at Frankfurt Airport anyway" [08:32:13] <saintdev> lol [08:32:17] <kshishkov> sainted: that's why they are flying away [08:32:23] <saintdev> ahh [08:32:37] <saintdev> migrating pigs [08:32:53] * thresh had stumbled across nice indian RPM package [08:33:00] <thresh> http://pastebin.com/bBPSgbJ6 [08:33:05] <DonDiego> saintdev, relaxed, actually, that is the newer one, thx [08:33:53] <pJok> kshishkov, so ffmpeg development will cause delays at Frankfurt Airport now? ;) [08:33:55] <saintdev> DonDiego: i thought you removed "the undersigned" on the newer one? [08:35:20] <superdump> won't the real peloverde please stand up [08:35:22] <kshishkov> thresh: do you mean that small postintall clause that makes it free of jre dependency? [08:35:28] <kshishkov> pJok: everything does [08:36:09] <thresh> kshishkov: indeed, postuninstall script destroy everything needed to run the software, if one updates the package :) [08:36:13] <kshishkov> saintdev: do you see anybody signed under that except standard FFmpeg-devel ML footer? [08:36:29] <thresh> destroys [08:36:30] <saintdev> kshishkov: was talking about the pastebins [08:37:08] <saintdev> he emailed the newer one, so it's really a moot point. [08:38:12] <16SAAYUNZ> i kind of like this nick, peloverde has been my nick for 10 years give or take a few days [08:38:25] <saintdev> kshishkov: can you help me buy one of these http://www.blogcdn.com/www.engadget.com/media/2011/01/11x011982fru.jpg [08:38:33] <saintdev> peloverde: lol [08:38:54] <superdump> DonDiego: looks good to me [08:38:58] <kshishkov> saintdev: I'd be glad to help you. [08:39:20] <DonDiego> it appeared on the list now [08:39:33] <superdump> 16SAAYUNZ: it almost looks like something urging one to support gnome (vincent untz [sp?]) [08:39:35] <DonDiego> apparently i need to look into a new email provider - whatever ... [08:39:46] <kshishkov> saintdev: I heard there's one not so far from here [08:40:16] <kshishkov> DonDiego: wasn't you your own email provider? [08:40:32] <spaam> DonDiego: let google host your mail ;) [08:41:39] <saintdev> kshishkov: really, lol. there's random crap all over the former ussr, isn't there. [08:42:25] <kshishkov> saintdev: actually there's one in Transport Museum in Rhineland-Pfalz [08:48:58] <KotH> DonDiego: ssh -t natsuki -C -L2525:127.0.0.1:25 ; iptables -t nat -I OUTPUT -p TCP -d natsuki --dport 25 -j DNAT --to-destination 127.0.0.1:2525 [08:49:17] <KotH> DonDiego: then use natsuki as mail relay [08:50:04] <elenril> can i av_log a byteiocontext? [08:50:33] <wbs> elenril: nope [08:50:45] <wbs> elenril: the first member must be an AVClass* for that to work [08:51:02] <elenril> meh [08:51:54] * elenril doesn't want to add yet another argument just for logging [08:52:01] <lu_zero> or pass NULL as first parameter but then won't be this useful [08:52:25] <KotH> elenril: that should be "can i av_log CHEEZBURGER" :) [08:52:26] <elenril> that's pretty ugly [08:53:20] <elenril> av_log(KotH, "i can haz choklit"); [08:54:49] <KotH> i haz choklit [08:55:01] <cartman> heheh [08:57:37] <wbs> oh the wonders of finnish grammar: http://www.ling.helsinki.fi/~fkarlsso/genkau2.html [08:58:19] <DonDiego> mpegts stuff [08:58:27] * DonDiego looks at mru [08:58:57] <DonDiego> mru: btw, what about that zlib stuff and the ts muxer/demuxer you said you had lying around? [08:59:36] <kshishkov> wbs: generated by Fred Karlsson - that's right Finnish guy for wrong Finnish language ;) [09:00:00] <wbs> kshishkov: well, you can't have it all ;P [09:00:36] <kshishkov> wbs: but yes, sometimes Finnish words put Germans to shame [09:09:12] <JEEB> Which is exactly why I never try teach much Finnish to foreigners. [09:09:36] <kshishkov> even Estonians? [09:10:05] <JEEB> They're already similar enough [09:10:25] <Dark_Shikari> bcoudurier: GSL! [09:10:30] <Dark_Shikari> Idra vs Jinro gogogogogo [09:11:58] <cartman> is there a powerof2 macro in ffmpeg? finding the nearest power of 2 of a number? [09:12:06] <kshishkov> JEEB: when I briefly stayed at Helsingfors it looked like Swedish was fine there. Though Finns need to get rid of Russian tourists first [09:12:19] <av500> do we support .jps? [09:12:28] <kshishkov> what's that? [09:12:40] <elenril> encrypted jpg? [09:12:43] <av500> 3d [09:12:45] <av500> stereo [09:12:49] <av500> images [09:14:00] <JEEB> kshishkov, Well, it's the official second language so people are made to learn it... to a level >_> [09:14:54] <elenril> hey JEEB [09:15:01] <elenril> you should join our quest for better ffmpeg [09:15:33] <kshishkov> av500: yes, it seems so, you just need to combine both parts into single 3-pic in your viewer. Otherwise it's standard JPEG [09:15:43] <spaam> JEEB: swedish? :) [09:15:51] <JEEB> Yes [09:15:57] <JEEB> Which is why all the signs are in two languages [09:16:10] <kshishkov> spaam: well, I suspect few decades ago they've learn Russian instead [09:18:28] <spaam> kshishkov: mm.. but we know that swedish is better ;) [09:18:39] <kshishkov> spaam: javisst! [09:22:15] * JEEB mostly overwrote his Swedish with Japanese [09:22:30] <Dark_Shikari> It's certainly more useful~ [09:22:46] <elenril> inb4 swedish weaboos [09:24:10] * kshishkov has Japanese peacefully coexisting along with Swedish and even Russian [09:24:27] <kshishkov> languages, of course [09:24:28] <JEEB> Then you must actually use that language :3 [09:25:19] <JEEB> Because Swedish here is a strictly school language unless you plan to go deep into it. Also, living in Japan for a year+ while you're supposed to study Swedish kind of breaks the rhytm nicely. [09:25:27] * kshishkov neglects Ukrainian but not that much as Ukrainian government though [09:25:45] <elenril> anyone got samples of id3v2 with cover art? [09:25:55] <av500> elenril: sure [09:26:00] <kshishkov> JEEB, I can use Swedish only few weeks per year :( [09:26:08] <av500> elenril: sec [09:27:20] <JEEB> kshishkov, then I commend that capability of yours to actually keep it workable in your brain. I can still read and maybe listen to some Swedish but don't remind me how bad I am at writing/talking... Can't even ask where a supermarket is close by in Stockholm >_> [09:29:52] <kshishkov> JEEB: well, you usually don't need to ask it, just find the closest station ;) [09:30:00] <elenril> av500: maybe you should upload to mplayerhq [09:30:17] <av500> elenril: :effort: ;) [09:30:43] <kshishkov> av500: will you help me finishing Bink-b support? [09:31:13] <spaam> what? going to help pross? [09:31:34] <kshishkov> yes [09:32:15] <kshishkov> av500: also I've seen two Bink decoders based on mine but rewritten in C++ in different game engines [09:32:27] <spaam> how are you kshishkov ? anything wrong? [09:32:43] <av500> spaam: must have hit his head this morning or so... [09:32:59] <spaam> av500: i guess [09:33:18] <kshishkov> spaam: so far av500 was the only (constantly present) guy showing interest in Bink here [09:36:12] <spaam> ok :) [09:42:38] <av500> kshishkov: I have no interest in bink [09:44:23] <kshishkov> av500: so you haven't convinced Dark_Shikari to produce xbink? [09:45:11] * Dark_Shikari hits kshishkov [09:45:45] <kshishkov> Dark_Shikari: xbink fits nicely with xvp8 and xrv3, not so nicely with xmp2 though [09:45:59] <kshishkov> s/xmp2/x262/ [09:48:38] <DonDiego> luca a making a statement... [09:50:30] <kshishkov> DonDiego: wasn't it predicted you'd get many statements? [09:50:43] <superdump> personally i thought there would be far more [09:50:55] <superdump> but then the vast vast majority of top committers were on board [09:50:59] <kshishkov> post-switch shock, I beliebe [09:51:03] <kshishkov> *believe [10:08:50] <pJok> kshishkov, probably going to come over the next few days/weeks [10:09:32] <kshishkov> well, I won't mind if it lasts for years for some persons [10:10:55] <saintd3v> kshishkov: don't forget xaac [10:11:12] <kshishkov> saintd3v: so _you_ can forget about it? [10:13:15] <saintd3v> the more xvaporware, the better :P [10:17:12] <pJok> what about xvp6? [10:18:30] <kshishkov> xvp7 FTW [10:18:38] <kshishkov> and xvp4 of course [10:20:00] <superdump> xdtm{1,2}? (it was Duck True Motion, right?) [10:20:07] <Dark_Shikari> xx264 [10:20:15] <Dark_Shikari> xyuv [10:20:17] <Dark_Shikari> xgif [10:20:18] <Dark_Shikari> xpng [10:20:43] <kshishkov> superdump: there is version called TM2X, so xtm2x would be awesome [10:21:00] <kierank> xjpeg [10:21:04] <kierank> and xjpeg2000 [10:21:11] <Dark_Shikari> xsnow [10:21:12] <kshishkov> xjpeg-xr [10:21:28] <kshishkov> and xape please :) [10:21:36] <Dark_Shikari> xflac [10:21:43] <Dark_Shikari> xlagarith [10:22:16] <superdump> xyamum [10:22:37] <kshishkov> xxvid? [10:22:43] <Dark_Shikari> xxxvid [10:22:57] <kshishkov> that would be extremely popular [10:23:24] <av500> xxxxxxxxxxxxxxvid [10:23:28] <kierank> xav500 [10:23:35] <av500> xx500 [10:23:51] <kshishkov> and x100.500 for thresh [10:23:52] <kierank> xpad [10:23:54] <kierank> xpod [10:24:24] <thresh> huh? [10:25:11] <kshishkov> thresh: ÐºÐŸÐŽÐµÐº ÐžÐºÑ-ÑÑÐŸÐ¿ÐžÑÑÐŸÑ [10:25:12] <superdump> xbox? [10:39:19] <kshishkov> DonDiego: http://www.ifitweremyhome.com/compare/DE/SE [10:40:44] <kierank> link doesn't work [10:41:08] <kshishkov> probably slashdotted, try reloading [10:41:43] <kierank> loads verry slowly [10:41:49] <av500> works here [10:42:35] <kierank> http://www.ifitweremyhome.com/compare/GB/SE [10:45:30] <kshishkov> if you want to be proud, compare GB to RU [10:46:06] <av500> kshishkov: to be fair you have to try all countries [10:46:46] <kierank> or http://www.ifitweremyhome.com/compare/GB/AF [10:48:18] <cartman> http://www.ifitweremyhome.com/compare/TR/DE [10:48:20] <cartman> heheh [10:48:33] <ubitux> the funny thing is to compare to US [10:48:36] <kshishkov> yep, the only pair suitable for av500 [10:51:04] <cartman> http://www.ifitweremyhome.com/compare/DE/FR [10:51:06] <cartman> weeee [10:51:54] <kshishkov> "This is by a very far stretch below the belt line." <- does that mean "pulling one's leg"? [10:52:17] <cartman> kshishkov: something about the balls [10:53:48] <av500> anybody here that has french *free* internet? with iptv? [10:55:05] <kierank> av500: ask the guy who works for *free* iptv [10:55:23] <av500> kierank: sure, who is it? [10:55:27] <kierank> Meuuh [10:55:40] <kierank> in #x264dev [10:55:48] <av500> kierank: thx [10:56:20] <av500> but its actually about an ff problem [10:56:35] <av500> current ffmpeg fails to play some rtsp stream that the freebox outputs [10:56:46] <av500> and I cannot debug it from .DE :( [10:57:09] <kierank> they use x264 iirc [10:57:20] <kierank> and vlc [10:58:15] <Dark_Shikari> Yes [10:58:43] <vipw> kshishkov: "below the belt" is from boxing, since it's not allowed to punch someone in the genitals, being far stretch below the belt no longer makes sense as a metaphor [10:58:57] * kshishkov likes quote from VLC fortunes.txt: < xand_> guys how can i force ffplay to use avcodec ? [10:59:30] <kshishkov> vipw: I know about that boxing term [11:29:11] <DonDiego> somebody please go and clarify that no accounts were closed or anything [11:29:27] <DonDiego> nothing was done to the videolan repo and svn was read-only anyway [11:29:49] <DonDiego> apparently this is a point that needs clarification [11:30:08] <DonDiego> but i'd prefer if somebody else could say it [11:30:13] <DonDiego> ruggles: you around? [11:36:27] <{V}> DonDiego, I can ask if Michael meant accounts to git.ffmpeg or git.videolan [11:37:59] <DonDiego> who are you? [11:38:04] <av500> DonDiego: jannau mentioned "We have no plans of maintaining the repo on git.videolan.org further." [11:38:17] <av500> that might sound like the videolan one is dead/gone [11:38:19] <DonDiego> apparently that was not clear enough [11:38:30] <av500> yes :( [11:38:49] <DonDiego> av500: maybe you can post and say that videolan was never touched? [11:39:20] <DonDiego> well, apart from jannau syncing a few commits, but i guess that's minor and not quite intended by anybody [11:40:27] <av500> done [11:40:45] <DonDiego> ruggles: i'd gladly cede my maintainership position, at least until i'm more prepared to deal with it - i currently have plenty of work and all my computers at home are broken, i don't even have a proper git setup yet :-( [11:40:48] <{V}> DonDiego, I'm a nobody :) (just a few patches that were submitted a few years back). I mean: _I_ can't verify/clarify which repo does or does not have write access for Michael (for example), but as an outsider I can ask him (publicly) which repo he meant. [11:41:28] * av500 opens a donation fund to get DonDiego a computer [11:41:51] <av500> I just got a P-III laptop, interested? [11:42:12] <av500> might be P-II even [11:42:36] <DonDiego> {V}: oh, ok, i understand now and i remember you - sure, post whatever you wish [11:42:56] <ohsix> av500: too fast! are you trying to kill him? [11:43:05] <DonDiego> av500: a friend gave me a new desktop computer, but it's waiting for me to have time to install it [11:43:17] <kierank> I have a pentium II 200mhz laptop [11:43:19] <kierank> do you want it [11:43:39] <DonDiego> i got a laptop lent from the institute, but it fell down and broke the display [11:43:47] * DonDiego is plain stupid and clumsy sometimes [11:44:08] <DonDiego> but yes, i'm looking for a laptop of my own again, sure [11:44:15] <DonDiego> donations are more than welcome :) [11:44:24] <kshishkov> you can coonect that laptop to some display though [11:44:27] <kshishkov> *connect [11:44:39] <{V}> you remember me? ... errr should I worry? :p [11:44:42] <av500> ohsix: I felt the new "leader" must have similar HW like the old "leader" :) [11:44:43] * DonDiego hopes not to kill his next computer right away [11:44:49] * av500 hides [11:45:01] <DonDiego> kshishkov: yes, but i had to have it repaired of course and i'm still waiting to get it back... [11:45:02] <ohsix> i must have missed something [11:45:09] <Dark_Shikari> ohsix: diego better not be the new leader =p [11:45:22] <kshishkov> DonDiego: remember the laptop Stephen Gehrer had at LT? You should get something like that [11:45:24] <cartman> av500: could I ask you some things about omapfbplay or shall I wait for mru instead? [11:45:39] <DonDiego> spare me the bad jokes please, this channel is now logged [11:45:54] <av500> but are logs mailed? [11:46:13] <Dark_Shikari> Bad jokes are part of what IRC is about. [11:46:17] * kierank didn't notice the existence of fftrollbot [11:46:23] <Dark_Shikari> If you can't handle the heat, step out of the ffflames. [11:46:28] <DonDiego> yes, they are on lists.mplayerhq.hu again [11:46:31] <kshishkov> ohsix: we have moved from "ProjektfÃŒhrer" model to "Bundesdevelopers" model [11:46:39] <Dark_Shikari> kshishkov: LOL [11:46:40] <DonDiego> i was only being moderately serious ;) [11:46:43] <av500> lol [11:47:17] <av500> cartman: shoot [11:47:59] <kierank> kshishkov: is the next step integration with other regional multimedia projects [11:48:06] <kierank> and then gstreamer collapses [11:48:11] <kierank> and needs a bailout? [11:48:19] <cartman> av500: private, because the code is ugly [11:48:34] <Dark_Shikari> kierank: x264 stays separate through, with its own currency [11:48:45] <kierank> lol x264 is britain [11:48:46] <kshishkov> Dark_Shikari: FFmpeg situation would make even Godwin refer to it this way [11:48:53] <Dark_Shikari> kierank: exactly [11:48:58] <kierank> and closed borders (gpl) [11:49:03] <Dark_Shikari> loool [11:49:12] <kierank> and an alliance with the evil USA (dual licensing) [11:49:16] <kshishkov> though not that effective as Britain [11:49:36] <Dark_Shikari> And like Britain, we have some weird cultural attributes that nobody in the rest of europe seems to understand. [11:49:49] <av500> Dark_Shikari: do you also have a tunnel into? [11:49:57] <Dark_Shikari> av500: The tunnel is x264's lavf input. [11:50:07] <kshishkov> or shared devels [11:50:27] * kshishkov tries to remember who maintains libavcodec/libx264.c [11:50:48] <av500> kshishkov: now, its a commitee [11:50:59] <thresh> with no commit rights [11:51:07] <Dark_Shikari> kshishkov: me [11:51:24] <Dark_Shikari> Weird cultural attributes in britain: British humor [11:51:24] <spaam> cartman: are you afraid to show your ugly code in public? :) [11:51:26] <Dark_Shikari> in x264: Touhou [11:51:26] <kshishkov> Dark_Shikari: you make me wonder if you have any relation to x264 then [11:51:35] <spaam> Dark_Shikari: dont froget SC2 ;D [11:51:42] <spaam> forget [11:51:56] <kshishkov> Dark_Shikari: what's weird about British humour? It's not British sausages. [11:52:14] <av500> spaam: I have the pastebin and will use it against him if needed [11:52:32] <cartman> av500: damn you, lol [11:52:41] <kshishkov> av500: you'd empty pastebucket on him? [11:52:43] <cartman> spaam: it shows my OpenGL skillz [11:52:58] <cartman> non-existing ones [11:53:51] <spaam> av500: Nice :D [11:54:16] <spaam> cartman: awesome skillz? [11:55:06] <cartman> spaam: nope [11:55:24] <spaam> :( [11:55:38] <spaam> cartman: going to fix opengl stuff for ffplay? [11:56:17] <cartman> spaam: nope [11:59:24] <lu_zero> bad [12:01:27] <av500> lu_zero: your swscale effort is for adding neon to colorconv? [12:02:10] <lu_zero> yup [12:02:22] <kshishkov> well, at least it may allow mru not to shudder when seeing swscaler [12:02:27] <av500> lu_zero: you have a (paying) customer :) [12:02:30] <av500> cartman: ^^^^ [12:02:37] <lu_zero> oh, really? [12:02:43] <lu_zero> neat =) [12:03:34] <cartman> av500: bah [12:03:35] <av500> lu_zero: not sure about the "paying" bit :) [12:03:38] <cartman> yeah [12:03:40] <cartman> indeed :D [12:03:44] <av500> its that turkish thing, you know [12:03:47] <cartman> that bit is unset man [12:03:52] <lu_zero> sure about the interest I guess =) [12:04:09] <av500> cartman: buy some gold in the bazaar! [12:04:13] <cartman> av500: :( [12:04:22] <lu_zero> merbzt did something in this regard btw [12:04:26] <cartman> lu_zero: Need a fast way to do YUV->RGB in *Droid [12:04:29] <av500> or send him lots of tr delights [12:04:31] <kshishkov> av500: you can buy some from vending machine, can't you? [12:04:35] <cartman> av500: delights work fine [12:04:39] <kshishkov> lu_zero: yes, he did [12:04:47] <lu_zero> cartman: merbzt hacked sdl a bit [12:04:50] <Dark_Shikari> cartman: shader [12:04:57] <kshishkov> cartman: do they work fine with KotH? [12:04:59] <cartman> lu_zero: hmmpf [12:05:06] <av500> Dark_Shikari: I was told shader had issues [12:05:10] <cartman> kshishkov: mines do, I know his fav. Turkish chaklÄ±t [12:05:14] <av500> j-b: no? ^^^ [12:05:31] <lu_zero> Dark_Shikari: shader might not work for certain resolutions or so I'm said from xbmc people [12:05:45] <kshishkov> lu_zero: I've talked to Benjamin, he was trying to implement yuv2rgb in NEON [12:05:53] <j-b> av500: ? [12:05:55] <lu_zero> yup [12:06:16] <av500> j-b: yuv2rgb and shaders [12:06:20] <kshishkov> he also blamed you for porting SDL to that platform IIRC [12:06:31] <lu_zero> kshishkov: just partially [12:06:50] <j-b> av500: yes, they have, and I never understand in which ways :D [12:06:54] <lu_zero> I just re-hacked something halfway working to something 3/4 working [12:06:57] <mru> morning [12:06:59] <av500> lunch [12:07:02] <lu_zero> good morning [12:07:07] <kshishkov> god morgon, mru [12:07:44] <cartman> mru! [12:09:37] <pJok> god morgon, mru [12:16:10] <_av500_> cartman: kÃ¶fte! [12:17:16] <cartman> _av500_: ich mÃ¶hte kÃ¶fte baby [12:17:34] <_av500_> ja [12:31:46] * KotH wouldnt mind some köfte now [12:31:54] <KotH> the pide was a bit small [12:32:38] <merbzt> my neon code was 10 times faster then the C code [12:34:24] <mru> how many cycles per pixel? [12:34:45] <pJok> KotH, its been ages since i've had kÃ¶fte... and there are some nice places around here that actually make good ones [12:34:51] <{V}> is ffmpeg-cvslog setup to receive updates from git.ffmpeg? [12:34:54] <{V}> ffmpeg-cvslog does not seem to have received Mans' "configure: fix mktemp test and fallback function" commit [12:35:05] <mru> {V}: it's ffmpeg-commits now [12:35:15] <mru> we felt -cvslog was a bad name [12:35:34] <thresh> did you resubscribe everyone there? [12:35:42] <mru> no [12:35:46] <mru> do you think I should? [12:36:21] <thresh> well, you (not personally, I have no idea who was the driving force around all that) did your worst moves already, so... [12:37:08] <mru> if it were just a simple renaming matter, I'd of course move the subscribers over [12:37:16] <mru> but it's a little more complicated than that [12:37:26] <thresh> I never administered mailman, is it that bad? [12:37:33] <{V}> ah I see it mentioned in the Announcement now. Could've been mentioned a little clearer. [12:37:37] <mru> it is, but that wasn't my point [12:37:37] <thresh> i know it's in python, so probably is.. [12:38:05] <mru> I meant the entire situation surrounding this [12:38:24] <mru> I don't want people to feel I'm making choices for them [12:38:37] <thresh> I can argue on that last sentence [12:38:43] <thresh> but I see your point [12:39:18] <mru> + any more than is already the case [12:39:37] <mru> there are now two repos, people are free to follow whichever or both [12:42:10] <DonDiego> is the website updated to point at -commits instead of -cvslog? [12:42:28] <mru> you're the subversion master [12:45:33] <DonDiego> what about converting the the website repo? [12:45:46] <mru> let's wait a little with that [12:45:52] <mru> there's enough going on now [12:45:54] <DonDiego> ok, fine [12:48:19] <jannau> {V}: it would have been wiser if I hadn't sync changes back to git.videolan.org and hence no commits to mails to -cvslog [12:50:31] <DonDiego> updated [12:50:38] <DonDiego> website i mean [12:50:54] <DonDiego> jannau: yes, i guess one is always smarter afterwards [12:52:05] <ubitux> does this need we need to re-register? [12:52:12] <ubitux> mean* [12:52:33] <kshishkov> DonDiego: congratulations, you've almost literally cited a Russian proverb! [12:52:58] <mru> kshishkov: that's a rather universal proverb [12:54:35] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * ra4f5af13fb ffmpeg/tests/ (lavf-regression.sh ref/lavf/voc_s16): [12:54:35] <CIA-29> ffmpeg: Add regression test for stereo s16le in voc. [12:54:35] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:54:36] <kshishkov> mru: well, but in Russian there's even a special term for it [12:55:34] <{V}> ubitux, to -commits ? yes, apparently so. [12:55:47] <thresh> Ð·Ð°ÐŽÐœÐžÐ¹ ÑÐŒ [12:56:08] <{V}> ubitux, if you want to have commits to git.ffmpeg.org sent to you [12:57:00] <kshishkov> thresh: Ðž ÐœÐ°ÑÐŸÐŽÐžÑÑÑ ÐŸÐœ ÑÐ°ÐŒ, ÑÐµÑÐµÐ· ÑÑÐŸ Ð²ÑÑ Ð² Ð ÐŸÑÑÐžÐž ÐŽÐµÐ»Ð°ÐµÑÑÑ [12:57:17] <ubitux> with -cvslog I will receive only from git.videolan.org? [12:58:04] <jannau> ubitux: yes [12:58:39] <ubitux> ok thannks; a summary of all of this on the mainpage may be useful [13:18:06] <Tjoppen> whoa [13:18:23] <Tjoppen> sick today and didn't check the mail until just now [13:18:49] <spaam> Tjoppen: slacking? [13:21:22] <elenril> so i finally replaced one of the two 512-MB modules in my craptop with a 2GB one [13:21:31] <elenril> BIOS says it can see 2560MB [13:21:55] <Tjoppen> spaam: heh [13:21:56] <elenril> yet the system claims i only have 882 [13:22:01] <elenril> why that might be? [13:22:15] <kshishkov> because it's craptop [13:22:29] * elenril stabs kshishkov [13:22:30] <mru> elenril: HIGHMEM not enabled? [13:22:50] <kshishkov> videocard allocated a bit too much memory for itself? [13:23:11] <elenril> mru: highmem is only needed for >4 GB, no? [13:23:13] <kshishkov> mru: ugh, the stuff like EMS/XMS? [13:23:20] <mru> elenril: not necessarily [13:23:35] <mru> I don't know exactly what sets the limit [13:23:40] <mru> but I've seen it kick in much sooner [13:23:41] * elenril goes to recompile his kernel [13:23:52] <mru> what's your dmesg like anyway? [13:23:54] <thresh> 512M IIRC [13:25:13] <elenril> http://pastebin.com/4C90xhtE [13:25:37] <mru> ugh, that's missing the start [13:26:10] <mru> do you have a /var/log/dmesg? [13:26:13] <elenril> no, it starts there [13:26:23] <mru> yes, the kernel buffer is missing the start [13:26:38] <mru> check for that ^ file, it might contain the full log [13:27:01] <mru> or rather, the log at an early stage before so much junk has pushed the interesting parts out of the buffer [13:27:52] <mru> eeek, 8139 [13:27:55] <elenril> http://pastebin.com/Kc26pTUp [13:28:10] <elenril> what's so wrong with 8139 [13:28:15] <av500> all of it [13:28:20] * elenril has about 3-4 at home [13:28:24] <elenril> never had problems with them [13:28:37] <mru> have you ever tried an intel nic? [13:28:46] <mru> or a dec tulip back in the day? [13:28:59] <elenril> sure, there is one on the machine i'm ircing from [13:29:05] <mru> those _work_ [13:29:17] <mru> and that last pastebin is even more incomplete [13:29:50] <mru> the first line should be "Linux version 2.6...." [13:30:48] <elenril> that's all there is in /var/log/dmesg [13:30:55] <ohsix> or initializing cgroups if you're using a modern distro [13:30:57] <mru> what broken system is this? [13:32:05] <kshishkov> Slackware 3.11? [13:32:53] <elenril> i guess i disable something in the kernel :) [13:33:03] <elenril> oh well, compile time [13:33:22] * elenril wonders how many things will 2.6.37 break [13:33:47] <mru> make the log buffer bigger [13:34:28] <mru> that would be CONFIG_LOG_BUF_SHIFT [13:34:37] <av500> mru: he cant, not enough RAM [13:34:44] <mru> mine's 18 [13:34:53] <mru> 15 should be the minimum on a system with that much ram [13:35:05] <mru> you can surely spare the 32k [13:35:11] <elenril> so much!!! [13:35:20] <elenril> my precioussss ram [13:35:38] <KotH> elenril: highmem is needed from something around 700mb upwards on 32bit systems [13:36:05] <kshishkov> can't we donate Gdium to elenril? [13:36:05] <ohsix> stupid pci devices~! [13:36:13] <mru> hmm, the pasted log is 26k [13:36:38] <elenril> i trimmed the boring parts at the end [13:36:45] <elenril> about connecting my usb devices etc [13:36:50] <mru> so it's probably 32k in total [13:36:59] <mru> what does dmesg | wc -c say? [13:37:46] <elenril> 31370 [13:37:50] <elenril> so yeah [13:37:51] <mru> close to 32k [13:37:55] <mru> so you're at 15 now [13:37:59] <mru> bump that to 17 [13:38:04] <elenril> already did [13:38:18] <mru> and enable highmem [13:38:41] <ohsix> and get an extra shot of espresso [13:38:45] <elenril> ack [13:38:49] * elenril eats chocolate [13:40:02] <kshishkov> elenril: KotH would object, you should call it "brown substance called chocolate in countries != .ch" [13:40:22] <mru> aka mud [13:40:48] <elenril> ok, /me eats some sweet brown mud [13:41:06] <av500> midpie [13:41:07] <KotH> kshishkov: be aware that mru largely agrees with my understanding of chocolate :) [13:41:09] <av500> mudpie [13:41:17] <ohsix> have you seen that documentary on chocolate yet [13:41:47] <av500> if they had time to film it, it was not good [13:41:57] <av500> the chocolate I mean [13:42:19] <elenril> Big Kernel Lock (BKL) [Y/n/?] (NEW) ? << haha [13:42:35] <av500> put ? [13:43:04] <kshishkov> that's really human interface [13:43:11] <kshishkov> ohsix: no, is there any? [13:43:12] <ohsix> elenril: that's largely added so they can put kconfig deps on it fro drivers that still have bkl parts [13:44:30] <ohsix> http://www.thedarksideofchocolate.org/ DOOOM [13:55:08] <lu_zero> KotH: you still have to come there and visit few places [13:55:40] <lu_zero> Leone and Stroppiana at least [13:55:55] <mru> hmm, perhaps I should ally myself with KotH and invade italy... [13:56:00] <av500> italian girls have funny names.... [13:56:20] <mru> italian _guys_ have funny names [13:56:22] <kshishkov> mru: your ancestors did that for you [13:56:24] <mru> girl's names [13:57:05] <spaam> mru: do you mena that lu_zero have a girl name? [13:57:14] <mru> not all of them [13:59:09] <lu_zero> Leone http://www.pastiglieleone.it/fabbrica-cioccolato.php [13:59:52] <av500> so Stroppiana is not a girl either? [14:00:24] <lu_zero> av500: another sort of important chocolate maker [14:00:49] <kshishkov> lu_zero: I know only Venchi from Italian chocolate makers [14:01:54] <kshishkov> lu_zero: though I remember buying some other chocolate brands from Italy too [14:01:54] <lu_zero> kshishkov: isn't that bad but at least Caffarel should be known [14:01:55] <lu_zero> http://www.caffarel.it/tool/home.php [14:02:51] <kshishkov> lu_zero: "isn't that bad" only because it's located in Torino? [14:03:16] <lu_zero> kshishkov: Torino has a long tradition about chocolate ^^; [14:03:42] <KotH> lu_zero: you have yet to prove that torino has chocolate ;) [14:03:50] <av500> lu_zero: famous FICT company? [14:04:06] <lu_zero> KotH: it's nearby [14:04:13] <lu_zero> come and see =P [14:04:48] <lu_zero> I'll bring you to some interesting places [14:05:19] <KotH> lu_zero: if i had time i would ^^' [14:05:34] * KotH has half a dozen invitations to see various places around europe [14:05:49] <mru> time to cash in on some of them? [14:05:50] <kshishkov> lu_zero: you don't understand. Proper Swiss chocolate is made only from the best Swiss cocoa beans, sometimes with addition of the best Swiss milk and sugar [14:06:04] <KotH> mru: as i said "if i had time" [14:06:11] <kshishkov> KotH: go to Moscow, you should visit it once a lifetime [14:06:21] * KotH would like to have a look at südtirol during winter [14:06:26] <mru> kshishkov: you have several lifetimes? [14:06:26] <av500> kshishkov: swiss sugar cane plantations are a real sight! [14:06:56] <kshishkov> mru: no, but I've never been to Moscow (and don't want to go neither there nor to Russia) [14:07:09] <kshishkov> av500: indeed [14:11:28] <thresh> kshishkov: if you don't come to Moscow, Moscow might come to you [14:11:30] <KotH> kshishkov: friend of mine had a thread manufactury near moscow... i think that's enough [14:11:42] <lu_zero> mru: got some spare time to visit? [14:12:01] <mru> lu_zero: I think I can find it [14:12:06] <mru> when's a good time of year? [14:12:07] <kshishkov> KotH: even thresh will tell you that near Moscow is totally different from Moscow [14:12:42] <lu_zero> mru: do you like better cold (up to -20) or hot (up to 40) or mild? [14:12:56] <mru> I prefer 20-30 [14:13:00] <thresh> indeed, I live in a quiet village 10km away from that hopeless filth-filled swarm of freaks [14:13:28] <lu_zero> The best traditional recipes taste better in autumn (that is warm and a little rainy in the end) [14:13:57] * KotH makes some notes to make fftorino in autumn [14:14:22] <lu_zero> spring is nice as well but you have less fresh mushrooms and truffles [14:14:25] <thresh> i seriously hope Brussels would be warmer in Feb than Moscow [14:14:32] <lu_zero> thresh: should [14:14:34] <mru> thresh: it should [14:14:45] <lu_zero> and that reminds me I must book my flight/stuff =P [14:14:54] <mru> last year it was just below freezing iirc [14:14:55] <thresh> it's about -20 here now and i'm freezing my pants off [14:15:11] <mru> even slightly above in the afternon [14:15:37] <thresh> not really sunny I would expect? [14:15:48] <mru> there was some sun [14:16:24] <elenril> o_0 people making sense? in my ffdrama? [14:16:34] <elenril> this must be stoppped until it spreads! [14:21:44] <spaam> what is the content-type for webm? [14:21:56] <kierank> video/whocares [14:21:57] <spaam> video/webm? [14:22:09] <spaam> kierank: i need to know it.. [14:22:18] <kierank> video/webm apparently [14:22:25] <spaam> ok. good :) [14:22:29] <kierank> http://www.webmproject.org/code/specs/container/ [14:22:31] <mmu_man> wtf... [14:22:44] <spaam> kierank: good.. [14:22:48] <lu_zero> elenril: where? [14:23:44] <av500> lu_zero: wbs: lavf rtsp supports HE-AAC? [14:29:46] <lu_zero> got asked about that few days ago [14:29:50] <av500> and? [14:30:10] <lu_zero> he-aac is aac-lc + ps and sbr [14:30:27] <lu_zero> IIRC ffaac has those halfway [14:30:36] <lu_zero> but, why asking us? [14:30:48] <av500> lu_zero: because it plays as a .ts capture [14:30:52] <av500> but not via rtsp [14:31:15] <av500> does lavf rstp stack handle that? [14:31:16] <lu_zero> uh? [14:31:31] <av500> lu_zero: free.fr sends that out from their home routers [14:31:35] <av500> as rtsp [14:31:39] <av500> and ffplay cannot play it [14:31:40] <lu_zero> they made a variant for he-aac? [14:31:55] <av500> lu_zero: you are the rtsp expert, no me :) [14:31:58] <av500> not [14:32:06] <av500> it's 0xf for ADTS [14:32:13] <av500> ^^ thats what I got told [14:32:29] <lu_zero> O_o [14:32:35] <lu_zero> do you have a sample? [14:32:47] <av500> of the rtsp stream? [14:32:53] <av500> how? [14:33:10] <av500> as said, the .ts capture is fine [14:33:56] <lu_zero> ffmpeg -i rtsp://the/thing -acodec copy -vcodec copy dump.nut works? [14:34:18] <av500> we will try [14:34:22] <lu_zero> wireshark might be helpful btw [14:36:08] <av500> lu_zero: I cant tell now, my french minion has to do it from his home in the evenings [14:36:54] <lu_zero> anyway a wireshark dump might help [14:37:03] <lu_zero> could you pass me the ts btw? [14:37:09] <av500> sure [14:37:26] <av500> there is also a pcap file [14:37:38] <lu_zero> so I can try locally with feng [14:37:43] <lu_zero> oh [14:37:48] <lu_zero> great pass everything =) [14:39:19] <av500> http://ffmpeg.pastebin.com/rqsA7XnS [14:39:23] <av500> this is the ffmpeg log [14:40:29] <kierank> av500: can you send me the ts, I want to see if they do anything weird [14:40:35] <av500> sure [14:43:13] <elenril> http://i.imgur.com/oCHE1.png awesome [14:43:15] <elenril> mru: thanks [14:43:19] <elenril> that was really helpful [14:45:17] <av500> lu_zero: kierank: http://0x.deadba.be/~tom/freebox_dump.tar.gz [14:45:26] <kierank> thx [14:45:49] <kierank> lol 1hr left [14:46:01] <av500> er [14:46:05] <av500> sec [14:46:22] <kshishkov> av500: that site should have Austrian mirror [14:47:06] <kierank> kshishkov: why austrian? [14:47:36] <cartman> mru: when I set dp->pixfmt = PIX_FMT_RGB24 does this mean frame data will be RGB or I must pass YUV420P as pixfmt? [14:47:42] <kierank> kshishkov: never mind [14:49:19] * cartman has so many questions [14:50:33] <av500> cartman: here: "????????????" have some [14:50:50] <kshishkov> cartman: you still have a long way to go to ask questions worthy of mru's attention [14:50:54] <cartman> av500: let me split() that [14:51:07] <cartman> kshishkov: you bet, mru helped me a lot :D [14:51:34] <kierank> kshishkov: ask him to send u the codez [14:51:50] <kshishkov> cartman: so he managed to convince you RTFM? [14:52:04] <kshishkov> kierank: codez for whut? [14:52:06] <cartman> kshishkov: nope, he explained and all that ;) [14:52:16] <cartman> kierank: I want the teh asm [14:52:19] <cartman> and codecz [14:53:18] <av500> kierank: its a home dsl upload, sorry [14:53:46] <cartman> I need PIX_FMT_RGB565LE actually [14:53:47] <kierank> doesn't amtter [14:53:53] <cartman> reading some Android docs [14:59:02] <av500> kierank: should be faster now [15:01:06] <mru> cartman: you should set dp->pixfmt to the format output accepts [15:02:22] <cartman> mru: I can't see it freely I guess? [15:03:03] <cartman> mru: I mean it doesn't auto-convert between the output and the requested pixfmt, right? [15:04:31] <mru> ff->pixfmt is the decoder output format [15:05:02] <mru> if you can support that format, you should use that [15:05:45] <cartman> mru: since xv.c sets its to YUV420P unconditionally, that must be working for most(all?) decoders? [15:05:53] <mru> that's laziness [15:06:09] <mru> see v4l2 for a more complete example [15:06:29] <mru> it queries the device capabilities and searches for a good match [15:06:38] <cartman> mru: hmmmpf ok, if I pass something like PIX_FMT_RGB565LE , it wouldn't work with any decoder I guess? [15:06:48] <mru> the whole pixfmt matching could be cleaned up a bit [15:07:18] <mru> if you return a format different from the decoder output, it will look for a converter [15:07:23] <kierank> how does lavf handle channel changes in ts? [15:07:28] <mru> there isn't currently any yuv to rgb converter [15:07:30] <kshishkov> badly [15:07:35] <cartman> mru: and does the convertion automagically if that exists? [15:07:37] <mru> only a couple of yuv repacking ones [15:07:43] <cartman> mru: i.e they are convertable [15:07:47] <mru> not quite automatically [15:08:04] <cartman> mru: I see some pixconv->convert() calls but not sure how it works [15:08:15] <av500> thats is just yuv reshuffling [15:08:20] <av500> no yuv to rgb [15:08:25] <mru> av500: it could be extended with yuv to rgb [15:08:29] <cartman> av500: why does it reshuffle? [15:08:30] <mru> it's all modular [15:08:46] <mru> cartman: for devices that don't support planar yuv [15:08:51] <av500> cartman: because e.g. codecs output planar and overlays expect packed [15:09:08] <cartman> mru: I was guessing that swscale would convert if needed [15:09:15] <cartman> av500: ah ok [15:09:22] <mru> swscale isn't used [15:09:32] <cartman> thats why its fast :-D [15:09:33] <cartman> :p [15:09:37] <mru> you must keep in mind the origin of this [15:09:39] <av500> certain allergy... [15:09:42] <mru> it was created as a speed demo [15:09:48] <cartman> mru: yup :) [15:09:51] <mru> using swscale would defeat the purpose [15:09:52] <jannau> kierank: what do you understand under channel changes? different program number in the same multiplex as boradcasted? [15:10:23] <cartman> is there list somewhere that what decoder outputs in what format? :) [15:10:24] <jannau> or entirely different multiplex [15:10:39] <av500> cartman: assume planar for most video codecs [15:10:57] <mru> no need to assume [15:10:59] <kierank> jannau: just for single program transport stream for now. if say a new stream is added in the pmt [15:11:05] <mru> ff->pixfmt tells [15:11:27] <mru> enable() will be passed a non-null pixconv if conversion is needed [15:12:01] <mru> you'd typically call pixconv->convert() in the prepare() function [15:12:15] <mru> then pixconv->finish() from show() before actually displaying the frame [15:12:23] <mru> that allows async conversion in background [15:13:11] <mru> if pixconv is null, prepare() doesn't need to do anything [15:13:18] <mru> unless the device requires some configuration of course [15:13:27] <cartman> mru: ah thats why it does if (pixconv) [15:13:31] <jannau> kierank: not sure, I would assume it won't notice new streams since it stops parsing the pmt [15:15:18] <jannau> adding support for that won't be hard. mythtv's version supports that [15:15:45] <jannau> removed streams are much harder to deal with [15:15:52] <cartman> nice nice [15:16:01] <cartman> I might be actually learning something :D :P [15:16:43] <mru> oh, and your display driver must call ofbp_put_frame() with it's done with a struct frame [15:16:52] <Kovensky> recarding Cyril's email, will patch review still be strict about cosmetics or will that be relaxed for git? [15:17:10] <mru> typically after pixconv is finished [15:17:13] <Kovensky> at least I remember seeing some explanation that the cosmetics+code separation was done because of some cvs thing that for historical reasons stuck with the move to svn [15:17:27] <cartman> mru: that says the frame is done, serve next, I think? [15:17:27] <av500> Kovensky: I have a script to insert randomly tabs and trailing spaces to the code base :) [15:17:32] <mru> or when the next frame is displayed in case of direct rendering [15:17:50] <Kovensky> av500: ofc inserting tabs and trailing spaces is dumb and should be fixed before commit =p [15:17:56] <mru> ofbp_put_frame() puts the frame back in the pool of unusued frames [15:18:09] <mru> so it can be passed to the decoder later [15:18:14] <Kovensky> av500: the question is about patches that edit lines and end up changing whitespace [15:18:22] <av500> ic [15:19:07] <cartman> mru: okies [15:19:07] <Kovensky> av500: for example, a patch that refactors some code would have to be done in two passes, one that changes the code that is actually edited (without changing indentation), then other to reindent everything [15:19:18] <av500> yes [15:19:20] <av500> I know [15:19:44] <mru> cartman: exploring the git history might explain some things [15:19:54] <mru> the comments occasionally contain useful information [15:19:57] <Kovensky> at least on x264 git that is completely a non-issue, but ffmpeg didn't adopt x264's git model =p [15:20:11] <Kovensky> I actually don't know how the kernel model works :S [15:20:16] <cartman> mru: thanks! :) [15:20:26] <cartman> I am on 3G, see you later! [15:20:41] <mru> Kovensky: the indentation rule is silly and needs to be revised [15:20:45] <Kovensky> IIUC it's just linus merging maintainer trees onto his, plus some monkeying / some of his own code, then publishing [15:21:22] <mru> it is true that occasionally a patch is easier to read if whitespace changes are ignored [15:21:29] <mru> but any sane diff tool has an option for that [15:22:16] <mru> it has really only been one person insisting on the strict no-whitespace rule [15:24:03] <Kovensky> Why couldnât you have forked, or held a vote? [15:24:03] <Kovensky> Because the overabundance of votes contributes to the problem. Please, [15:24:03] <Kovensky> no more votes. [15:24:05] <Kovensky> Contributes to what problem? [15:24:08] <Kovensky> Thilo needs some enlightenment [15:24:32] <mru> voting always means stomping one side on the head [15:24:52] <av500> revolution too :) [15:25:02] <mru> no, that chops off heads [15:25:09] <av500> ah, subtle difference [15:25:20] <pJok> at least no ffmpeg coder set himself on fire [15:25:35] <Kovensky> instead they set the mailing list on fire [15:25:37] <Kovensky> fflames \o/ [15:25:44] <kshishkov> mru: there's a saying: 'Russians always liked drinking, fighting and cockroach races. Elections combined it all for them' [15:25:45] <av500> Kovensky: by my count, the last vote had a majority of ppl saying "michael, yes, but with changes" [15:26:05] <kshishkov> av500: so we changed indeed [15:26:11] <av500> he did not follow up with it [15:26:12] <Kovensky> av500: votes are just bikesheds [15:26:39] <mru> ffvotes have always turned into a game of who can find the best counting method [15:26:56] <kshishkov> isn't that the whole purpose of all votes? [15:27:09] <av500> mru: yes, but in the last one, it was not even counted [15:27:14] <mru> alternatively who can pick the most biased options [15:27:29] <kshishkov> av500: that's also a legal method in some countries [15:27:51] <Kovensky> if I ever speak at an open source software event I'll bring a bikeshed and lots of paint, then tell the audience to paint it [15:28:20] <mru> only one requirement: the entire shed must be one colour when they're done [15:28:56] * av500 is the last one to paint [15:29:07] * av500 puts C4 into the paint can [15:29:18] <kshishkov> you vandal! [15:29:21] <Kovensky> av500: Mr. Bean tried that technique [15:29:30] <av500> Kovensky: I remember [15:29:34] <kshishkov> av500: that was good BeagleBoard revision! [15:30:45] <mru> av500: http://www.youtube.com/watch?v=GURvHJNmGrc [15:31:40] <{V}> Kovensky, yes, but not with C4 [15:32:04] <av500> mru: single color, yeah right [15:55:40] <kierank> there should be votes to have a vote [15:55:46] <kierank> if it works for the un it should work for everyone ;) [15:56:29] <mru> votes all the way down [15:56:56] <mru> allocate, say, 50MB and vote on each bit [15:57:02] <av500> before votes we need constitution [15:57:13] <kierank> av500: nah unwritten constitution works well [15:57:31] <lu_zero> sigh [15:58:53] * av500 calls open source supreme court to help [15:59:34] <kierank> rms? [15:59:57] <av500> kierank: rms, linux and sballmer [16:00:02] <av500> er, linus [16:01:25] <kshishkov> i.e. freedom, real things and developers!developers!developers! [16:01:49] <av500> kshishkov: sballmer only to prevent to other 2 from conspiring :) [16:02:00] <DonDiego> Kovensky: maybe you can try to explain to thilo how votes leave 49% of the people unhappy (i.e. a group large enough to fork) and are just a dictatorship of the (slight) majority? [16:02:10] <kshishkov> av500: do you think rms can conspire with anybody else? [16:02:50] <DonDiego> av500: maybe you can post your numbers now that somebody asked for them? [16:03:16] <av500> I lost the pastebin url :) [16:03:57] <DonDiego> somebody here must have logs [16:04:15] <DonDiego> or recount, maybe you get some GWB results ;-p [16:04:53] <mru> DonDiego: you were already compared to him [16:05:57] <mru> http://ffmpeg.pastebin.com/1PT53QVr [16:06:04] <mru> irc logs ftw [16:06:18] <DonDiego> mru: that's where i learned the acronym [16:06:59] <DonDiego> well, my language was a little bit on the - flowery - side, but hey, i thought they were some pretty expressions [16:08:28] <kierank> av500: what's the voting for? [16:08:38] <av500> ? [16:08:44] <kierank> in the pastebin [16:08:48] <av500> the last one [16:08:51] <kierank> yeah [16:09:11] <av500> A. I trust michael and wish him to continue to lead the ffmpeg project [16:09:16] <av500> B. I distrust michael and wish him to step back [16:09:27] <kierank> oh that [16:09:43] <av500> C. I want michael to stay our leader, but to abide by the same rules as everyone else. That is, Michael should be a prime minister, not a BDFL [16:09:48] <superdump> it's not a question of trust for me [16:10:06] <av500> superdump: that was how the vote was worded [16:10:12] <superdump> ah that vote [16:10:15] <superdump> i recall [16:11:01] <mru> also remember _who_ chose the options [16:11:12] <av500> C was chosen by jason [16:11:16] <av500> :) [16:11:28] <av500> or rather "added" [16:12:09] <DonDiego> somebody may wish to publish those numbers... [16:13:20] <mru> it's worth noting that some big names are missing entirely from that list [16:13:59] <DonDiego> yes [16:14:27] <mru> and the presence of some pure trolls [16:14:45] <mru> well, one [16:14:50] * kshishkov scans that list for VladimirP [16:15:40] <merbzt> lwn picked it up now [16:15:56] <16SAAYUNZ> last vote I was the only one to vote B [16:16:24] <mru> 16SAAYUNZ: what kind of nick is that? [16:17:08] <16SAAYUNZ> the kind freenode gives you due to nick collision [16:17:22] <merbzt> cool [16:17:22] <merbzt> keep it [16:17:46] <Kovensky> he did say he liked that nick :> [16:18:09] <mru> I suppose in retrospect you could say I voted "D fuck off" [16:18:23] <merbzt> I wonder how I will get out of this building today ... [16:18:33] * alfreddo is searching for blood and barricades [16:18:38] <merbzt> rfid chip in my access card sort of died [16:18:56] <Kovensky> why does lwn make it so annoying to open an article on another tab, or even to get a link to it [16:19:35] * mru is still struggling to understand how lwn works [16:20:06] <DonDiego> 16SAAYUNZ: please go back to your original nick, "green hair" in spanish is a great name :) [16:20:19] <KotH> lol [16:20:48] <Kovensky> DonDiego: it's "green hair" in portuguese too =p [16:20:57] <16SAAYUNZ> it has been years since my hair was last green [16:20:57] <Kovensky> except in that case it can't refer to the hair on your head, only body hair [16:21:13] <mru> Kovensky: spanish and portuguese are rather similar [16:21:20] <mru> but with dangerous differences [16:21:55] <mru> they sound quite different though [16:21:55] <Kovensky> indeed [16:22:25] <mru> and the people look different (the european ones) [16:23:07] <Kovensky> brazilian portuguese is also substantially different from european portuguese [16:23:21] <mru> so I've been told [16:23:26] <Kovensky> they have different pronunciation, different vocabulary, different adjectives, different verbs, different verb conjugations [16:23:27] * mru does not pretend to know either [16:24:07] <Kovensky> and it's impossible to understand computer stuff in european portuguese unless you study its vocabulary [16:24:18] <DonDiego> 16SAAYUNZ: doesn't matter, nicks stick :) [16:24:24] <Kovensky> brazilian portuguese borrowed most things from english; portugal decided to translate or make up their own words [16:24:45] <mru> I can't understand computer stuff in swedish [16:24:50] <mru> at least not translated apps [16:25:04] <lu_zero> ^^; [16:25:08] <mru> technical literature is easier [16:25:11] * KotH can't understand computer stuff in japanese [16:25:14] <KotH> ;) [16:25:24] <lu_zero> how so? [16:25:32] <lu_zero> most of them are imports [16:25:51] * lu_zero can barely _read_ computer stuff in japanese [16:25:56] <Kovensky> most of them are in engrish =p [16:26:20] <mru> imported and mutilated [16:26:40] <mru> and that's not limited to computing [16:27:18] <spaam> mru: you dont like the word sÃ€ndlista? [16:27:34] <mru> that word is much older than email [16:27:42] <mru> just like mailing list is [16:28:02] <av500> sandinista? [16:29:47] <kierank> shit is going to hit the fan on cnet soon it seems [16:30:04] <kierank> http://twitter.com/stshank [16:30:36] <spaam> omg kierank [16:30:49] <kierank> spaam: duck and cover [16:31:23] <av500> does cnet report on open source? [16:31:36] <KotH> kierank: it hit the fan when lwn reported on it [16:31:55] <av500> ah, its on their homepage [16:32:05] <kierank> KotH: lwn isn't particularly mainstream [16:32:49] <KotH> kierank: it is widely read... especially among the "older" OSS people [16:33:04] <av500> with beards? [16:33:05] <kierank> older being what, 30+ [16:33:39] * av500 does not read lwn [16:34:13] <kierank> "If ffmpeg went all Tunisia, what does that make poor Mike Niedermeyer? Ask him (michaelni(a)gmx.at) and you got a story" [16:34:38] <KotH> kierank: older in the sense of "being involved in oss for quite a few years" [16:34:50] <KotH> kierank: ??? [16:34:59] <kierank> some journalists post on twitter [16:35:08] * kierank pretends he is on cnn [16:35:14] <kierank> twitter > facts [16:35:29] <DonDiego> http://twitter.com/glynmoody/status/27755583767584768 [16:35:45] <kierank> who came up with that wording [16:35:48] <kierank> it's pretty good [16:35:57] <av500> DonSomething [16:37:24] <kierank> av500: pfft you left #x264dev [16:37:42] <av500> kierank: irc overload [16:38:54] <kierank> ohhhhh that glen moody guy wrote rebel code [16:38:57] <BBB> how do I go back to a HEAD checkout of my git repo? [16:38:59] <kierank> no wonder he sounded familiar [16:39:11] <kierank> BBB: git reset --hard [16:39:12] <BBB> git checkout $tag goes to any tag, but I want the latest again after having done like 20 tags or so [16:39:22] <BBB> I remember git reset doing bad stuff [16:39:44] <remur_030_v2> BBB: it deletes all the changes which have not been commited yet [16:39:45] <kierank> yeah maybe don't do that if the situation is complicated [16:39:49] <remur_030_v2> only for tracked files though [16:40:04] <Kovensky> BBB: git checkout master [16:40:07] <Kovensky> or whatever is the name of the branch [16:40:18] <remur_030_v2> Kovensky: doesn't work with uncomitted changes [16:40:31] <Kovensky> git stash them :D [16:41:03] <BBB> git checkout master worked [16:41:48] <remur_030_v2> BBB: what else we you trying to get to the master branch again? [16:41:57] <BBB> nothing so far [16:42:10] <BBB> I was trying to see which revision broke a change [16:42:13] <BBB> quite fun [16:42:18] <BBB> but all revisions I tested were similarly broken [16:42:23] <BBB> so now I go back to HEAD and fix it [16:42:30] <Kovensky> don't git checkout them individually [16:42:33] <Kovensky> git bisect --help [16:42:43] <remur_030_v2> BBB: there is git bisect for this [16:42:48] <remur_030_v2> ah I'll just shut up =P [16:42:52] <Kovensky> (git bisect does the checkouting for you but in a binary search fashion) [16:43:01] <mru> checkout does work with changes as long as the new rev doesn't alter the changed files [16:43:23] <BBB> I was going back to before fate existed [16:43:29] <BBB> so believe me, all files were changed somehow :-p [16:43:47] <mru> yeah, then it would report a conflict and abort [16:45:23] <BBB> /bin/sh: llvm-ar: command not found [16:45:29] <BBB> can I alias those somehow? [16:45:35] <BBB> (I'm trying to use --cross-prefix=llvm-) [16:46:08] <mru> try --ar=whatever [16:46:19] <mru> or just --cc=llvm-whatever [16:46:29] <mru> optionally with a working --cross-prefix [16:47:55] <DonDiego> what took ivan so long? [16:48:12] <DonDiego> and he ++ed his troll skills... [16:48:19] <mru> what took everybody so long? [16:48:58] <lu_zero> uh? [16:49:07] <av500> lu_zero: ml [16:50:39] <lu_zero> read now [16:50:51] <lu_zero> it's quite over details [16:50:59] <mru> it's a troll [16:51:02] <mru> don't feed it [16:52:57] <lu_zero> he's here I think [16:53:07] <mru> same rule applies [16:53:35] <av500> more revolutionaries from aachen arrive [16:53:50] <merbzt> is trollbot logging to the mailinglist ? [16:54:11] <mru> merbzt: yes, isn't that what you wanted? [16:54:38] <merbzt> yes [16:54:46] <merbzt> I'll announce that [16:55:04] <merbzt> can it be added to the topic that this channel is logged ? [16:55:15] <mru> feel free [17:00:39] <merbzt> done [17:02:41] <BBB> great [17:08:42] <mru> btw, linuxtag project application is open [17:09:25] <BBB> I get "WARNING: newer than config.h, rerun configure" when trying to run fate after a complete new build in a new dir [17:09:28] <BBB> what does that mean? [17:11:18] * BBB is already frustrated with git now [17:11:24] <BBB> let me re-checkout in a new dir [17:11:37] <bryno> is the SVN repo no longer up-to-date? [17:11:57] <BBB> no, we use git now [17:12:14] <remur_030_v2> BBB: won't take long and you'll think totally different about git =) [17:12:30] <bryno> from how I understood it, git+svn was used previously. but it will no longer be used? [17:12:52] <av500> bryno: svn is ove4r [17:12:54] <av500> over [17:12:59] <bryno> I'm really just wondering if my svn updates are useless now :P [17:13:01] <bryno> ok. [17:13:10] <av500> you can still svn up daily [17:13:11] <kierank> BBB: if you'd done work on xvp8 maybe you'd be more familiar with git ;) [17:13:18] <remur_030_v2> bryno: this was up to the developers discretion, it is just providing git for the local user [17:13:28] <bryno> but will it be sync with git? [17:13:31] <av500> no [17:13:37] <av500> its read only and fixed [17:13:39] <BBB> kierank: screw that, I wrote the vp8 decoder with yuvi using git && github :-p [17:13:42] <bryno> ok. [17:14:04] <merbzt> I'm booked for FOSDEM [17:14:08] <av500> good [17:14:20] <merbzt> will you be there ? [17:14:41] * mru will [17:14:42] <av500> yup [17:15:21] <kierank> mru: how are you getting there [17:15:27] <mru> plane from SOU [17:15:33] <mru> BBB: that means some unidentified file has been modified after configure was run [17:15:48] <mru> it's meant to catch changes to allcodecs.c and friends [17:16:05] * thresh arrives on 3rd Feb with some friends and vodka [17:16:07] <mru> changes there usually mean codecs have been added and then build will fail without reconfigure [17:16:17] <mru> in this case, something seems to have been confused [17:16:23] <mru> nothing to worry about [17:16:31] <BBB> it reruns the build while trying to run fate [17:16:34] <BBB> it reruns the complete build! [17:16:37] <BBB> every single time! [17:16:47] <BBB> something is seriously confused [17:17:01] <merbzt> I'm guessing you ? [17:17:47] <kierank> BBB: at least you're not on windows [17:18:02] <mru> BBB: are you bisecting or something? [17:18:03] <BBB> probably me [17:18:07] <BBB> mru: I was :) [17:18:12] <BBB> I tried going back to head [17:18:15] <BBB> I think I fucked up or so [17:18:21] <mru> well, changing avcodec.h triggers an almost full rebuild [17:20:29] <BBB> only once though [17:20:31] <BBB> it does it every time now [17:20:32] <BBB> ohwell [17:20:36] <BBB> new checkout and now it works again [17:20:40] <mru> every time you change it, yes [17:27:37] <bryno> is michael no longer part of the ffmpeg development team? [17:28:37] <av500> up to him [17:29:00] <bryno> he's no longer the guy in charge though, right? [17:29:26] <mru> he's not in charge of ffmpeg.org [17:29:57] <bryno> who is now? [17:30:12] <superdump> there is no leader [17:30:14] <mru> the new team [17:31:40] <bryno> i've been using ffmpeg for years, but never really paid attention to internal conflicts in the project. [17:31:48] <bryno> sorry for the questions that i'm sure have been asked plenty of times already :P [17:32:24] <bryno> it's exciting to see change, but i do wonder about the future [17:32:42] <mru> we hope the change will be for the better [17:32:55] <bryno> can i submit c++ patches now? jk [17:33:01] <mru> nice try [17:33:09] <mru> I said _better_ [17:33:13] <bryno> mru: i know you hate c++ :P [17:35:42] <mru> not as much as what people do with it [17:36:53] <merbzt> you can do nice things with c++, but most of the times the result is a complex mess that nobody understand [17:37:13] <mru> even the nice things [17:39:03] <siretart> hey, we already have a bzr mirror: https://code.launchpad.net/~vcs-imports/ffmpeg/master :-) [17:39:17] <av500> how bizzar [17:40:26] <mru> example of c++ gone mad: http://pastebin.com/BtpThxfR [17:40:31] <mru> that's _one_ symbol name [17:40:37] <siretart> this should allow me to have launchpad create daily packages for ubuntu from trunk [17:40:56] <mru> imagine getting a few of those in an error message [17:41:03] <siretart> mru: that's boost [17:41:11] <mru> which is written in c++ [17:41:20] <siretart> uh, and not even that, you're looking at spirit [17:41:30] <siretart> bad programmers can write bad code in any language [17:41:31] <mru> it's the longest symbol name I could find [17:41:41] <mru> ~36k [17:42:19] <siretart> I guess that's mainly because of template parameters? I guess g++-4.6 should help with them a bit [17:42:37] <mru> I have no idea how something so dreadful arises [17:43:46] <mru> and your excuses are irrelevant [17:43:48] <siretart> will there be an FFmpeg/mplayer stand at fosdem this year? [17:43:53] <mru> no [17:43:56] <siretart> :-( [17:44:04] <av500> siretart: nobody took initiative [17:44:10] <mru> that's what happens when you kick out the event organiser [17:44:47] <DonDiego> bbl [17:44:48] <siretart> who will be at fosdem this year nevertheless? [17:44:53] * mru will [17:44:57] <siretart> I'm still considering [17:44:59] <mru> on beagleboard stand [17:44:59] <siretart> ah, cool! [17:45:04] <av500> mru: I guess we can run a "powered by FFmpeg" banner on our booth? [17:45:11] <mru> of course [17:45:41] <thresh> ffmpeg will have a booth ? [17:45:48] <av500> [18:43:53] <mru> no [17:45:58] <mru> beagleboard will [17:46:05] <thresh> some irc messages are freezing on the way here [17:46:09] <av500> same trolls, different booth [17:46:16] <mru> pretty much [17:46:18] <mru> +koen [17:46:29] <av500> he is the one we troll [17:46:43] <mru> don't know if roger is coming [17:47:35] <av500> he better if he wants his wall back [18:04:05] <Kovensky> how are the fflames going [18:08:16] <superdump> siretart: i'll be at fosdem too [18:08:32] <mru> siretart: do come along [18:08:58] <av500> mru: we will have to push koen to the side to make room :) [18:17:14] <CIA-29> ffmpeg: Michael Niedermayer master * rfe67841355 ffmpeg/doc/git-howto.txt: [18:17:14] <CIA-29> ffmpeg: Revert "Update git-howto with ffmpeg.org URLs" [18:17:14] <CIA-29> ffmpeg: This reverts commit 69c92320d760d3925d5c83c4fbca6012deef4195. [18:17:14] <CIA-29> ffmpeg: Reason is that this has been commited by mistake as discussed. [18:17:25] <CIA-29> ffmpeg: Michael Niedermayer master * r111ccca602 ffmpeg/MAINTAINERS: [18:17:25] <CIA-29> ffmpeg: Revert "Initial MAINTAINERS update" [18:17:25] <CIA-29> ffmpeg: This reverts commit f4f5cab94e0881cd30965b28f3d78d9c63d6918e. [18:17:25] <CIA-29> ffmpeg: Reason is that this has been mistakely commited as discussed. [18:18:42] <mru> jannau: can we please not have those cia notices here? [18:18:50] <mru> it's confusing [18:19:02] <av500> commitfight [18:30:58] <ruggles> in the git repo, do we still need to wrap commit messages at 80 chars? [18:34:34] <mru> yes [18:34:40] <mru> and I'll enforce it [18:34:42] <ruggles> ok [18:37:32] <j-b> Hello people [18:37:39] <Kovensky> <CIA-29> ffmpeg: Reason is that this has been commited by mistake as discussed. <-- discussed where? [18:37:54] <elenril> on the ML [18:38:48] <Kovensky> topics [18:39:45] <elenril> Search, and you will find. [18:39:48] <thresh> what does mn mean by 'unabreviated'? [18:43:29] <j-b> full log, I think [18:44:59] <thresh> ah, full diff. [18:45:11] <j-b> yes [18:45:51] <thresh> well it's more than 10000 lines [18:46:29] <thresh> s/lines/bytes [18:47:49] <j-b> thresh: ask for the limit [18:47:56] <av500> INFTY [18:48:13] <j-b> And beyond! [18:48:20] <j-b> good moroning av500! [18:48:27] <av500> gm [18:49:05] <kshishkov> elenril: http://www.dorktower.com/images/comics/DorkTower911.gif [18:51:15] <elenril> kshishkov: pure truth [18:52:44] <av500> merbanan: tonights build is fubar :( [18:53:42] <kierank3g> did i miss any dra [18:53:52] <kierank3g> drama [18:55:22] <j-b> merbanan: plz, when you know if you are going to FOSDEM, I'll be interested [19:04:39] <Compn> jannau : i think i sent you my ssh key for git.videolan , but i may have encrypted it with my pubkey first , doh [19:04:47] * Compn will resend [19:05:01] <av500> Compn: just send privkey too [19:05:41] <Compn> av500 : for ssh or pgp? :P [19:05:42] <Compn> ehe [19:05:53] <elenril> both to be sure [19:06:11] * Compn wonders why keys arent properly filenamed [19:06:16] <Compn> id_rsa.pub , sure [19:08:10] <j-b> yep [19:08:28] <j-b> Compn: I don't see yours in the gitosis [19:09:10] <j-b> Compn: I'll do it [19:11:08] <j-b> Compn: done [19:11:25] * Compn dunno what 'gitosis' is ehe [19:11:37] <j-b> Compn: git repo management [19:11:55] <j-b> we have a git repo to manage git repo rights [19:12:24] <Compn> yeah, i think i can guess what it is now [19:12:32] <Compn> one repo for keys and you can pick who has acceesss [19:12:37] <j-b> yes [19:12:52] <j-b> and some people have write access to this repo, so they can give more access to people [19:13:00] <j-b> it works, kind of ok, but very buggy [19:16:25] <Compn> j-b : thanks [19:16:35] <j-b> Compn: tell me, if it doesn't work [19:16:48] <Compn> ok, will do, after i install this git thing [19:16:52] <Compn> and find something to commit :P [19:24:03] <elenril> wtf is with all the netsplits [19:24:57] <thresh> freenode is the f [19:28:29] <iive> it must be freenode revolution. [19:30:57] <bamiaux> tidal waves [19:31:24] <Compn> lol @ iive [19:31:57] * elenril thinks we should behead iive for not having the right revolutionary attitude [19:33:37] <Compn> elenril : you know iive lives in one of those countries that beheads people ? [19:33:50] * Compn guesses [19:34:33] * elenril wonders how long until we're slashdotted and/or phoronixed [19:34:55] <kshishkov> Compn: nope, his country is not part of Turkey yet [19:35:22] <iive> Compn: nope, we don't have dead penalty anymore. And during comunist sentances were executed by shot in the head.before that [19:35:33] <kshishkov> elenril: who cares about us (till we drop H.264 support)? [19:36:37] <Compn> kshishkov : that sounds like a good idea for april fools [19:36:42] <Compn> ffmpeg drops h264 [19:36:51] <Compn> goes 'patent-free only' [19:37:36] <kshishkov> "in order to open formats FFmpeg drops all codec support except for {Bink,Lagarith,TrueMotion 1} [19:37:42] <Dark_Shikari> YES [19:37:45] <Dark_Shikari> YES YES YES YES YES. [19:37:49] <Dark_Shikari> Let's do that. [19:37:55] <kshishkov> too early :( [19:38:09] <Dark_Shikari> Let's drop everything except Snow and APE in NUT [19:38:19] <elenril> s/APE/TAK/ [19:38:32] <elenril> oh wait, we don't have a decoder [19:38:40] <kshishkov> that's even better! [19:38:41] <elenril> ape is too well-known [19:39:01] * kshishkov feels he'd RE TAK sooner or later since it's getting annoying [19:40:51] <Dark_Shikari> Wow, Michael seems to have mellowed up a bit. [19:40:58] <Dark_Shikari> I'm... surprised. [19:41:01] <elenril> good [19:41:20] <elenril> maybe he'll want to cooperate in a few weeks [19:41:36] * elenril wonders how to handle creating new streams from id3v2 parser [19:41:59] <kshishkov> elenril: one stream per metadata item? [19:42:07] <elenril> kshishkov: cover art [19:43:33] * elenril welcomes our new DonDiego overlords [19:43:59] <DonDiego> http://lwn.net/Articles/423733/ [19:44:14] <kshishkov> the best kind of overlord - not interested in power and not having enough time to abuse it [19:44:19] <DonDiego> best comment ever [19:44:36] <Dark_Shikari> DonDiego: It's true, except for the whole bit about control of the website. [19:44:38] <DonDiego> kshishkov: lol ... [19:45:32] <DonDiego> well, the thing with the videolan repo was a bit of a stupid mishap, but what can you do... [19:47:21] <kshishkov> DonDiego: well, at least now you have totally independent (from you) repo for FFmpeg devs [19:48:51] <DonDiego> yes [19:55:09] <DonDiego> anybody seen stefano online? [19:55:31] <DonDiego> i managed to catch him on the phone today, but we did not speak for long [19:55:49] <kshishkov> what's your impression? [19:56:49] <DonDiego> that i need to talk to him a bit longer and explain things because he does not understand our motivation [19:57:27] <DonDiego> he is torn and does not yet know what to think [20:01:39] <lu_zero> ^^; [20:01:45] * lu_zero didn't helped much [20:02:41] <kshishkov> lu_zero: send him Italian chocolate ;) [20:03:03] <kshishkov> probably some people just need some time to determine, let them have it [20:03:16] <_av500_> elenril: sry, forgot to upload [20:03:22] <_av500_> elenril: poke me tomorrow [20:03:27] <elenril> _av500_: nvm, already got some [20:03:35] <_av500_> elenril: also, did you consider the muxing side? [20:03:38] <elenril> yes [20:03:50] <elenril> that should be quite easy [20:03:57] <elenril> demuxing will be harder [20:04:00] <elenril> and/or hackier [20:04:18] <elenril> unless i go with binary metadata/attachements, but i really don't want to [20:07:56] <_av500_> elenril: i still done like the stream idea [20:08:08] <_av500_> i prefer all metadat in one place [20:08:19] <_av500_> but i guess i have to ffork :) [20:08:25] * elenril stabs _av500_ [20:08:30] <elenril> it's harder to work with [20:08:38] <elenril> why would you want that [20:37:16] <DonDiego> somebody talking about xfree86 [20:37:35] <DonDiego> nothing ever refreshed X dev more than that fork... [20:39:38] <Dark_Shikari> lol [20:39:50] <Dark_Shikari> or egcc [20:39:51] <Dark_Shikari> or whatever [20:40:03] <iive> too bad you didn't fork :P [20:40:27] <elenril> but we did [20:40:32] <elenril> there are two repos now [20:40:46] <elenril> so by divergence theorem ther must have been a fork somewhere [20:41:21] <DonDiego> elenril: i see you haven't learned to ignore the household troll yet.. [20:41:29] <DonDiego> i suggest the use of /ignore [20:41:52] <DonDiego> i notice i haven't set up this client properly yet in this regard [20:41:57] * DonDiego goes on to fix this [20:42:12] * elenril feeds the troll [20:45:40] <bryno> was this take over orchestrated by mru? [20:45:52] <BBB> speaking of trolls [20:46:13] <BBB> (no it was not) [20:46:39] <bryno> at least looking at the mailing list, there's the good-bye in december, then suddenly he's back [20:46:59] <DonDiego> bryno: there is a list of signatures, there is your answer [20:47:09] <elenril> speaking of trolls - how's the -mt merge looking ;) [20:47:17] <DonDiego> astrange: ? [20:47:23] <DonDiego> mru: how about zlib? [20:48:09] <mru> DonDiego: I need to fix a minor glitch [20:48:46] <bryno> BBB: that question wasn't to incite arguing. i was just curious, as an outsider looking in [20:49:06] <BBB> bryno: fair enough :) the move is supported - as pointed out by diego - by a list of devs [20:49:20] <BBB> bryno: we all signed, and we sent it out together (or well, attilla did, but he speaks for all of us) [20:49:28] <BBB> mru is one of the 20 or so people in that list [20:51:38] <DonDiego> any other opinions about the libswscale external in the ffmpeg svn repo? [20:52:26] <lu_zero> DonDiego: I have no opinion so far [20:53:22] <mru> DonDiego: go for it [20:53:36] <bamiaux> btw, does libswscale does anything apart from resize/color conversion ? [20:54:06] <DonDiego> it makes your head spin when you look at it ;) [20:54:27] <mru> DonDiego: I wonder if that property could be weaponized [20:56:39] <DonDiego> weapons of mass rescaling? [20:57:24] <Compn> mass head spinning [20:57:27] <_av500_> head spin of more than 180 deg is enough [20:57:47] <BBB> where's Jumpyshoes [20:59:06] <bamiaux> another thing, what is needed to make ffmpeg-commits ML appear on gmane ? [20:59:22] * mru investigates [21:01:44] <_av500_> lu_zero: did you look at the pcap? [21:03:29] <mru> request sent [21:03:57] <elenril> wrapping nazis return! [21:07:56] <mmu> plop [21:08:01] <mmu> oh, an mru [21:08:07] <mru> hi mmu [21:08:22] <BBB> this complicates tab completion [21:08:27] <mmu> so you did your coup d'état ? ;) [21:08:28] <BBB> fortunately m/r are far away [21:09:07] <mru> BBB: shall we talk about oversized rabbits? [21:09:12] <DGMurdockIII> no [21:09:13] <BBB> ok [21:09:16] <DGMurdockIII> no [21:09:22] <BBB> no? [21:09:34] <BBB> I think I got some of the valgrind errors of j-b figured out [21:09:35] <BBB> now to fix it [21:09:36] <BBB> ... [21:10:03] <DonDiego> hey, shall we invite michael to fosdem? [21:10:07] <DonDiego> :) [21:10:15] <j-b> BBB: not my fault ;) [21:10:19] <elenril> invite him to irc [21:10:24] <mru> DonDiego: you know that's a waste of electrons [21:10:25] <DGMurdockIII> michael who? [21:10:38] <DGMurdockIII> michael meeks? [21:10:43] <DonDiego> DGMurdockIII: was that a devious troll comment? :) [21:10:54] <mru> DonDiego: DGMurdockIII is a know troll [21:10:57] <mru> +n [21:10:59] <elenril> mru: http://en.wikipedia.org/wiki/Conservation_of_charge [21:11:02] <kshishkov> iive: I do, few boxes [21:11:19] <BBB> time to fix it [21:11:37] <BBB> j-b: if you hadn't told me, I wouldn't have known they existed, and for all I know they wouldn't have existed at all [21:11:58] <BBB> so j-b, it is partly your fault, depending on whether you believe that the world still exists when you close your eyes [21:12:05] <BBB> what philosophical stream was that again? [21:12:08] <CIA-29> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rc3897d7690 ffmpeg/libavcodec/iirfilter.c: [21:12:08] <CIA-29> ffmpeg: Fix use of sstep/dstep in ff_iir_filter(). [21:12:08] <CIA-29> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:12:15] <elenril> sollipsism [21:12:25] <elenril> or something like that [21:12:30] <alfreddo> one l [21:12:59] <mru> solipsism is the belief that the universe only exists in one's imagination [21:14:49] <j-b> BBB: world doesn't exist, even with eyes open [21:15:27] <alfreddo> skepticism :) [21:19:23] <mru> it's on reddit [21:19:28] <mru> http://www.reddit.com/r/opensource/comments/f58j1/revolution_in_the_ffmpeg_… [21:19:36] <mru> as noticed by DGMurdockIII [21:19:53] <DGMurdockIII> yeah [21:21:19] <mru> and the commentards are as clueless as ever [21:23:41] <JEEB> indeed [21:24:04] <bryno> well, fill them in [21:24:24] <mru> pointless [21:24:56] <bryno> who is ffmpeg's PR team? :P [21:25:19] <mru> DonDiego I suppose [21:25:47] <mru> not so much a team perhaps [21:25:52] <_av500_> mru: pah, me: http://www.linux-magazin.de/NEWS/Linuxtag-2010-FFMPEG-wird-0.6-und-fuettert… [21:25:55] <mru> but he usually does the talking [21:26:07] <mru> _av500_: right, I forgot [21:27:04] <_av500_> what pr do you want me to spin? [21:31:12] <BBB> j-b: hah, I got the first bug fixed I think [21:31:53] <BBB> wooho [21:32:10] <mru> bugs where? [21:32:25] <_av500_> j-b has bgs [21:32:27] <_av500_> bugs [21:32:33] <_av500_> its a french thing [21:32:33] <BBB> mru: h264 decoder with emu_edge [21:32:49] <BBB> there's still valgrind output left, and the md5 is still wrong, but some are gone now [21:32:51] <j-b> _av500_: frog bugs :) [21:32:52] <BBB> I'm doing them one at a time [21:33:10] <BBB> we need a few vagrind frext tests (I'll tell you which one) with -flags emu_edge once I've got those fixed [21:33:42] <mru> we need to figure out a nice set to run with emu_edge in general [21:33:56] <mru> once that's done, the all-valgrind test will pick them up [21:34:22] <BBB> yeah [21:34:28] <BBB> I'll give you a list once I have it fixed [21:34:34] <BBB> I don't want it to start off all red [21:34:35] <BBB> :-p [21:34:42] <BBB> 2-4 should be enoug [21:34:55] <BBB> the frext samples test a lot of prediction modes at once [21:35:31] <mru> sounds good [21:35:45] <mru> running all the h264 tests twice is just too time-consuming [21:57:10] <DonDiego> astrange: ping -mt :) [21:57:52] <elenril> Wed, Jan 19, diego [FFmpeg-cvslog] r26401 - trunk/libavfilter/x86 << wait, what? [21:58:05] <astrange> got stuck implementing an optimization that's not worth the time [21:58:16] <astrange> sticking it onto a branch and moving on [21:58:26] <DonDiego> good to hear :) [21:58:26] <astrange> (it was the first review comment) [22:06:51] <Jumpyshoes> BBB: thanks for updating the patch [22:10:25] <j-b> BBB: I confirm that the issues only happen with dr [22:11:32] <lu_zero> mru: might be nice adding the clone url directly on gitweb [22:11:49] <mru> lu_zero: will do [22:12:09] <lu_zero> meanwhile the gitorious mirror is getting prepared [22:16:12] <mru> done [22:20:11] <lu_zero> the push url is git@git.ffmpeg.org:ffmpeg isn't it? [22:20:36] <mru> or ffmpeg.git at the end, I think both work [22:20:51] <mru> but there's no need to advertise that and confuse people [22:21:07] <mru> it's only accessible to the committer team anyway [22:22:20] <lu_zero> mru: I was doing for myself =) [22:38:11] <jannau> DonDiego: was r26401 needed? is it possible to pin svn:externals to a specific version? I would prefer that over a copy of libswscale [22:38:56] <astrange> it is possible [22:39:19] <jannau> DonDiego: see http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html [22:39:44] <uau> jannau: i think he wants to remove a copy of libswscale from the mplayer svn repo [22:40:03] <BBB> Dark_Shikari: can you review my patch (reply to jumpyshoes' email)? [22:40:13] <uau> hmm i guess you were referring to that with "pinning" (using a version from before the removal) [22:42:27] <jannau> uau: yes, we would pin it to current rev and it should work as long as the mplayer svn repository exists [22:43:52] <jannau> DonDiego: just add '-r32800' between the directory and svn repo url for the svn:externals property [22:49:46] <j-b> BBB: confirmed, only SSSE3 + dr makes it crash [22:50:28] <mru> and emu_edge? [22:50:32] <BBB> j-b: ? [22:50:40] <BBB> I'm not done yet, I'm just getting started [22:51:44] <BBB> I made the patch a little smaller also [22:51:59] <j-b> mru: emu_edge is what I call dr, I think. [22:52:09] <mru> j-b: the two are unrelated [22:52:26] <BBB> it doesn't matter [22:52:44] <mru> _my_ video player does dr w/o emu_edge [22:52:52] <BBB> j-b: backtrace? what function? I've got fixes for 8x8l_horizontal_up and 8x8l_horizontal so far [22:53:10] <astrange> most players doing dr set emu_edge but it's not necessary [22:53:22] <j-b> mru: what we call "ffmpeg-dr" in vlc is a language abuse for EMU_EDGE, if I read correctly the code [22:53:59] <j-b> if( p_sys->b_direct_rendering ) p_sys->p_context->flags |= CODEC_FLAG_EMU_EDGE; [22:54:37] <Kovensky> http://metaleks.net/programming/the-evolution-of-a-python-programmer [22:56:48] <saste> hi all [22:57:07] <jannau> hi stefano [22:57:11] <_av500_> hi [22:57:16] <jannau> DonDiego: ping [22:57:29] <saste> it was a long time since the last time I was here [22:57:31] <jannau> hmm, I guess [22:58:00] <jannau> DonDiego is not really online and uses now the irssi in screen approach [22:58:17] <saste> no prob i can wait [23:00:16] <jannau> it will probably take until business hours tomorrow, he has currently no working computer at home [23:00:50] <saste> ok... anyway i would like to know if there is some way to fix this mess [23:00:59] <saste> and if there is some space for reconciliation [23:01:08] <saste> if I can do something for it [23:01:10] <saste> i hope so [23:01:41] <Jumpyshoes> how is mn taking it? [23:02:23] <saste> i have no idea but currently it is not clear what's happening and for what the posted patches are [23:02:25] <BBB> hah [23:02:31] <BBB> Jumpyshoes: please check my updated patch [23:02:34] <BBB> I'll send another one now [23:02:41] <saste> also i see that many commits went to the videolan repo [23:02:46] <lu_zero> hi saste [23:02:53] <saste> was that wanted? [23:02:57] <saste> hi luca [23:03:45] <Jumpyshoes> BBB: cmovnz = mov if not zero? [23:03:48] <BBB> saste: I think the commits to videolan were a mistake, unwanted, I think [23:03:52] <BBB> Jumpyshoes: yes [23:04:04] <j-b> BBB: windows, so I don't know in which function it crashes [23:04:10] <lu_zero> already told also on ml ^^; [23:04:17] <BBB> j-b: with or without my patch? [23:04:20] <jannau> saste: that's my fault. I thought cooperation would be easier if both repos were as similiar as possible [23:04:51] <j-b> BBB: without [23:05:01] <BBB> j-b: ok, try with my patch which I just posted to the ML [23:05:17] <j-b> BBB: ok [23:05:21] <BBB> now the only function giving valgrind problems is 8x8_dc_mmxext [23:05:22] <jannau> and I didn't thought of the two obviously unwanted commits [23:05:38] <saste> uhm ok [23:05:40] <BBB> so I'm looking at that one, can't really figure out what's wrong yet [23:05:53] <saste> what about the ffmpeg.org svn repo? [23:05:57] <BBB> saste: now, as for "fixing this mess"... what do you have in mind? [23:06:04] <saste> who has still access there? [23:06:10] <saste> a vote [23:06:18] <saste> there is a legitimation problem now [23:06:24] <saste> i believe it should be solved [23:06:25] <jannau> saste: theoretically it is read only [23:06:46] <Jumpyshoes> BBB: hrm, i haven't tested it yet but... seems good. i assume it passes fate w/o emu_edge? [23:06:51] <BBB> saste: not to be incredibly insulting, but the voting is part of the problem imo [23:06:54] <BBB> Jumpyshoes: yes [23:07:05] <saste> BBB: what's the alternative then? [23:07:10] <BBB> Jumpyshoes: I'm trying to make fate pass with emu_edge also [23:07:14] <Jumpyshoes> BBB: yea i think it's good [23:07:18] <BBB> Dark_Shikari: ^^ [23:07:23] <BBB> Dark_Shikari: please review patch again [23:07:30] <jannau> diego wanted to change the libswscale svn:external but only fixed something entirely unrelated [23:07:52] <BBB> saste: a vote is two extremes deciding by simple majority which of the two sides is going to force its opinion on the other half [23:08:10] <BBB> saste: a more reconciliatory approach would be to actually _fix_ the problem, so that _both_ sides are happy [23:08:27] <jannau> the external needs to be changed since libswscale will be deleted in mplayer's svn repo [23:08:37] <BBB> saste: some people in that list of signees have called the recent way-too-many-votes one of the biggest symptoms of our problems [23:08:49] <saste> BBB: if there is such a way... i'm all for taking it [23:08:58] <BBB> saste: it shows we can't come to normal consensus anymore, and so we just "vote" and pick one extreme [23:09:00] <_av500_> none of the last few votes was taken seriousl i think [23:09:08] <BBB> _av500_: absolutely correct [23:09:25] <saste> BBB: i have no problem at accepting a non optimal solution if this is good for the majority [23:09:28] <BBB> saste: it'll require some thinking... but a vote won't solve anything - not before and not after what just happened [23:09:39] <saste> BBB: that's not perfect but it still better than a fork [23:09:54] <BBB> noted :) [23:10:02] <saste> BBB: ok but please let's do an effort to find a solution [23:10:16] <saste> as for me i won't work on code until the situation is clear [23:11:10] <BBB> ok, so problem one: we need no more votes, problem 2: we need a more friendly approach where focus is back on development, away from nitpicks, typos, stylistic issues, micro-optimizations for macro-code. ffmpeg-mt took how long to get in? it's insulting to the developer. it should go in, with all its problems, so we can work on it _together_ instead of just demanding more work off of astrange [23:11:30] <BBB> actual development has been way down over a couple of months now, and we need a solution for that problem [23:12:19] <BBB> problem 3, possibly (probably) related: we need to get rid of this idea of a BDFL, or in other words the idea that some developers are - just by their mere status - have more say over the project than others. there's many smart developers here and one's vision isn't necessarily absolutely correct [23:12:46] <BBB> and a personal opinion: we (ffmpeg) are not mplayer (anymore?) [23:13:42] <saste> as for the nitpick problem i agree [23:14:21] <saste> note that in the last time i was marking in reviews with "nit" "nit+" etc. that meant that i didn't care if the contributor was going to fix it [23:14:23] <uau> BBB: what do you mean by "not being mplayer"? [23:15:03] <saste> but at the end i believe the maintainer of a file should have a final say on it as he's the person which is going to read again and again the code [23:15:08] <lu_zero> before I delve again on swscale, this non-fork o re-fork is a form of vote if you like [23:15:14] <saste> then there is the problem of the multiple / single vision [23:15:20] <saste> i have not a strong point on it... [23:15:38] <BBB> uau: what's good for mplayer, or what exists in mplayer, is not by definition true for ffmpeg just because it is in/for mplayer [23:15:39] <saste> both centralized and de-centralized models have their merit... [23:15:47] <BBB> uau: most blatant example is libmpcodecs [23:15:54] <saste> the problem is what best suits ffmpeg [23:16:06] <BBB> that whole thing was outrageous and shows why the bdfl model is problematic [23:16:20] <uau> BBB: so you're mainly referring to michael's arguments regarding how stuff was done in mplayer? [23:16:28] <lu_zero> BBB: I'm thinking about proposing a clean solution for mpcodecs borrowing from openbsd [23:16:30] <saste> now that we have git to work in a decentralized way is much easier [23:16:53] <lu_zero> uau: the referral is that one [23:16:57] <saste> but at the end of the day you have to say to the user: *this* is the repo [23:17:13] <lu_zero> michael extremely positive view on mplayer-old-ways [23:17:29] <lu_zero> saste: in that case it's simple [23:17:54] <lu_zero> gentoo will use mine if I don't mess up too much or siretart's one [23:18:20] <lu_zero> ubuntu and debian siretart's [23:18:58] <lu_zero> nothing changes that much in practice [23:19:22] <uau> yes michael was one of the developers who favored "traditional" mplayer development (and who i had conflicts with for that reason) [23:19:23] <lu_zero> maybe some of my users will be happy if the -mt branch gets merger sooner (now?) [23:19:25] <saste> what if the branches start to diverge (from the API/ABI point of view)? [23:19:36] <uau> of course the result of that in mplayer was a complete mess [23:19:36] <saste> that's going to be an hell [23:19:56] <uau> but somehow the people involved thought the bad results didn't indicate problems with the process [23:20:16] <lu_zero> saste: if it diverges then it's because there is something we couldn't really agree [23:20:33] <lu_zero> so people would wait for the disagreement to settle [23:20:37] <astrange> it can diverge because someone didn't keep up merging [23:20:41] <lu_zero> or pick one they feel works better [23:21:01] <BBB> saste: will you submit your work to both? [23:21:32] <lu_zero> but I think it would be quicker than today since experimenting and publishing experiments should be easier [23:21:41] <saste> i don't know what's going to happen with the posted patches [23:21:48] <saste> we have an ffmpeg with two heads [23:21:59] <BBB> yeah [23:22:05] <lu_zero> we did even before (3 to my count) [23:22:15] <saste> i don't want to duplicate my work or letting people waste theirs [23:22:27] <lu_zero> and -mt had been used on a number of places already [23:22:34] <saste> i'll stop to code for now until we'll find an agreement or at least a clear situation [23:22:36] <BBB> saste: but you don't want to choose sides either [23:22:45] <saste> not now [23:22:53] <lu_zero> and if you post a patch fixing a problem [23:22:54] <BBB> saste: that's really the poorest of solutions, sorry to be blunt [23:23:02] <saste> not if we don't tackle the legitimation problem [23:23:10] <lu_zero> I'm quite sure somebody will pick it up =) [23:23:16] <BBB> saste: the situation at this moment was that various developers did not want to work under the old-style regime anymore [23:23:21] <saste> with a vote or with something else [23:23:22] <BBB> saste: _that_ is an equal nightmare [23:23:30] <BBB> saste: because we _silently_ loose developers [23:23:39] <BBB> and we will never notice until we start searching for the sound [23:23:45] <kierank> really you need an outside person to mediate [23:23:55] <kierank> (read: a manager) [23:23:59] <kierank> who doesn't write any code [23:24:13] <uau> saste: what legitimization does it need? certainly people can set up whatever project they want [23:24:30] <uau> the only potentially questionable thing is confusion about names and website ownership [23:24:31] <saste> yes they can [23:26:05] <saste> i don't like the way it has been done the switch.. i could have joined if there was public discussion and announce [23:26:09] <saste> now it is not so easy [23:26:09] <mru> until fabrice says otherwise, everybody has equal rights to the name [23:26:24] <jannau> kierank: you mean a person which both sides can equally hate and then unite in their hate ;) [23:26:26] <saste> the same is true for many other developers from what can i read [23:26:30] <mru> saste: we tried for several days to reach you [23:26:45] <saste> i received some calls yesterday from diego [23:26:59] <saste> i was busy and i couldn't answer [23:27:13] <saste> then when i called luca it was too late [23:27:15] <BBB> we heard that from a few people [23:27:23] <BBB> sorry, we can't wait forever :( [23:27:38] <kierank> jannau: doesn't matter if they are hated, as long as they are accepted to be neutral [23:28:45] <kierank> a bit like the speaker of the house of commons... [23:29:08] <uau> kierank: exactly what would such a person mediate? [23:29:42] <uau> if there are disagreements about how to do development do you really expect someone "who doesn't write any code" to be qualified to resolve them? [23:30:10] <kierank> well both sides will argue their case [23:30:28] <kierank> and that person will take the decision based on perceived merit instead of taking sides [23:30:38] <kierank> that's not to say the person won't know how to code [23:31:01] <BBB> I'm basically with uau here, this sounds like a bureaucracy-style solution [23:31:04] <mru> and why would anyone want to hold this position? [23:31:04] <BBB> Dark_Shikari: ping [23:31:26] <uau> kierank: and you think someone who doesn't program is qualified to make a decision? or you think there would be some expert programmer who'd no absolutely no development related to ffmpeg himself but would hang around the project just mediating between others? [23:31:58] <mru> for once I find myself in agreement with uau [23:32:13] <mru> uau: savour the moment [23:32:19] <Kovensky> lol [23:32:23] * _av500_ takesscreenshots [23:32:50] <kierank> well it's have someone neutral or have this project on the brink of splitting into two [23:32:50] <Kovensky> someone with write access add that to the quotes page on multimediawiki [23:33:40] <BBB> Dark_Shikari: what does h264 prescribe (standards-wise) if an edge block (chroma) uses dc prediction? should it use top_dc/left_dc/dc_128? and does ff264 do that? [23:34:40] <mru> BBB: rtfs? [23:34:46] <mru> s == source/spec [23:35:03] <BBB> the source does nothing and valgrind cries out foul about both c and asm code [23:35:10] <BBB> I wonder if the source is wrong [23:35:12] <pengvado> top_dc/left_dc/dc_128 are for any case where some of the neighbors don't exist. including edges. [23:35:17] <_av500_> http://www.flickr.com/photos/av500/5370834037/ [23:35:22] <BBB> pengvado: thanks [23:38:27] <iive> kierank: there is another solution, it is one of the "maintainers team" taking over the leadership, even if it is not official. [23:39:01] <kierank> that still leaves some developers unhappy [23:39:37] <lu_zero> mru __aeabi_d2ulz rings any bell? [23:39:42] <uau> kierank: and you don't think a compromise that requires mediating wouldn't leave the participants unhappy? [23:40:25] <kierank> well by definition a compromise means both sides are happy [23:40:30] <DonDiego> saste: hi, i tried calling again, but no luck.. [23:41:06] <iive> kierank: in long run it depends how competent would be the leader. [23:41:17] <iive> kierank: no, compromise means both sides are equally unhappy. [23:42:21] <_av500_> lol: http://twitter.com/bash_vi/statuses/27828217876324352 [23:42:26] <mru> lu_zero: that's a helper function for converting a double to unsigned long [23:42:41] <mru> where did you encounter it? [23:42:51] <mru> normally it would only be used in softfloat builds [23:45:30] <jannau> KotH: hail to the leader [23:47:39] <lu_zero> mru: Diego (flameeyes) got it while adding amr support to his symbol collision tools [23:48:08] <_av500_> symbol super collider? [23:48:21] <DonDiego> Transmitting file data ....................... [23:48:21] <DonDiego> Committed revision 26402. [23:48:23] <mru> that function is part of libgcc (or equivalent) [23:48:31] <lu_zero> =) [23:48:32] <DonDiego> first post - last commit :) [23:49:14] <DonDiego> and now it's read-only again.... [23:50:45] <jannau> DonDiego: so you ignored my suggestion of pinning the svn:external revision? [23:50:59] <DonDiego> i didn't see it [23:51:14] <jannau> not that I would care deeply about the svn repo anymore [23:51:42] <DonDiego> the problem is that the mplayer repo might go away [23:51:56] <DonDiego> as in - not be available alongside the ffmpeg repo [23:53:14] <DonDiego> i'm also quite lagged on email [23:53:17] <jannau> going away completely? I should stop - I simply don't care [23:53:58] <jannau> DonDiego: it was here, 20min before saste joined [23:54:26] <DonDiego> i've been on the phone with reynaldo, i haven't read half the backlog yet, sorry [23:54:44] <jannau> np [23:54:57] <saste> DonDiego: i'm here [23:55:14] <jannau> we spent already more time on it than it's worth

1 0

IRC log for 2011-01-18
by irc＠mansr.com 19 Jan '11

19 Jan '11

[22:10:53] * /join #ffmpeg-devel ... [22:10:57] *** 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. | The revolution has come! [22:10:57] *** TOPICINFO: DonDiego!~diego(a)slaughter.informatik.RWTH-Aachen.DE, 1295377135 [22:11:46] <DonDiego> moin fftrollbot :) [22:11:51] <jannau> beware of the fftrollbot [22:12:00] <microchip_> LOL [22:13:45] <mru> jannau: perhaps we should disable the cia notifier on the videolan repo [22:13:52] <mru> once is enough [22:14:49] <thresh> is that doable on cia site? because we're using one script for all repos [22:15:19] <mru> the commit hook that calls it is per repo though, no? [22:15:34] <thresh> yeah, but that would also involve not sending a mail to ffmpeg-cvslog@ [22:15:40] <mru> no [22:15:48] <mru> just remove the -c ffmpeg args [22:15:53] <Dark_Shikari> so michael still hasn't awoken yet [22:15:57] <jannau> yes. I'm still undecided what we should do with the repo. I decided to sync it for now to make life of everyone who switched yesterday easier [22:15:59] <thresh> mru: oh ok [22:16:42] <thresh> indeed [22:17:31] <thresh> I'm a bit reluctant to change anything atm, I'll wait for things to cool down a bit [22:18:09] <CIA-29> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r09a5c2452c ffmpeg/configure: configure: fix mktemp test and fallback function [22:19:12] <jannau> thresh: the fflames haven't started yet [22:19:35] <thresh> yeah and I expect them to rise [22:20:14] <Kovensky> ffdrama [22:20:38] <DonDiego> jannau: just give up the videolan repo IMO, we will not continue maintaining it forever [22:20:45] <DonDiego> so better drop it now [22:21:03] <DonDiego> people cannot have done much with it yet, it was up for little more than a day iirc [22:21:51] <thresh> isnt ffmpeg.org the same anyway? [22:21:59] <thresh> +- url [22:22:06] <bamiaux> there is even two git reps ? [22:22:21] <lu_zero> uff [22:22:27] <mru> thresh: yes, same contents [22:22:37] <lu_zero> redoing the swscale cleanup is annoying =_= [22:22:38] <Kovensky> bamiaux: one was a decoy [22:22:42] <Kovensky> or so it seems [22:22:42] <Kovensky> =p [22:22:51] <Kovensky> lu_zero: redoing? [22:23:58] <bamiaux> the way it is handled is quite sad [22:24:12] <Kovensky> if you mean moving from v.o to ffmpeg.org, just add a new remote and rebase to it [22:24:16] <mru> the way what is handled? [22:25:11] <lu_zero> Kovensky: mru broke the patchset with his change and amending the patch isn't working that well ^^; [22:25:24] <bamiaux> the whole 'undersigned' thing [22:25:45] <lu_zero> bamiaux: what you'd do? [22:25:54] <Kovensky> well, it's a coup d'etat, ofc it doesn't happen "cleanly" =p [22:26:02] <mru> bamiaux: you don't know the whole story [22:26:22] <saintdev> i'd say for a coup it happened pretty cleanly, no blood was shed =P [22:26:25] <Kovensky> mru: a blag post on hardwarebug would be nice [22:26:57] <jannau> Kovensky: no, git remote set-url origin is enough since the repos are fully compatible [22:27:01] <jannau> see my mail [22:27:33] <Kovensky> jannau: ic, it would've been needed if the repos were desynced though [22:27:59] <jannau> yes [22:28:27] <bamiaux> lu_zero: fork [22:36:06] <jannau> yes [22:39:52] <DonDiego> bamiaux: why not keep the infrastructure that we are already using? [22:40:11] <DonDiego> michael wanted to move to videolan anyway [22:40:21] <DonDiego> so putting up git on mphq is fine... [22:43:03] <bamiaux> it was not clear to me that both repositories would be alive [22:44:58] <lu_zero> bamiaux: from my point of view too many people moved to this tree and/or shown interest when asked about [22:47:10] * lu_zero meanwhile is figuring out what's wrong with his local sendmail [22:47:28] <mru> lu_zero: that it's not postfix? [22:49:37] <DonDiego> bamiaux: only time will tell [22:50:46] <lu_zero> something smaller here ^^; [22:51:58] <lu_zero> ssmtp [22:52:19] <Kovensky> at least it isn't traditional sendmail [22:53:13] <mru> oh, ssmtp [22:53:31] <mru> it's not very good at receiving mail though... [22:53:38] <mru> but I use it on my laptop [22:53:44] <mru> no need for a fullblown MTA there [22:53:48] <lu_zero> it is supposed to send them properly [22:53:51] <lu_zero> and was [22:54:45] <DonDiego> who is anders grönberg? [22:55:18] <Kovensky> sounds swedish [22:55:33] <DonDiego> we should decide what to do with the flamage [22:55:49] <DonDiego> best not get into it [22:56:14] <DonDiego> but maybe we need to make some statements [22:56:39] <saintdev> i like that stefano would have preferred a bikeshed [22:56:45] <Dark_Shikari> Exactly [22:56:53] <Dark_Shikari> A discussion would have ensured nothing had happened. [22:57:28] <hyc> sometimes that's the correct outcome, to maintain a community [22:57:29] <jannau> he has at least 3 patches in ffmpeg [22:57:41] <DonDiego> hyc: what do you mean? [22:58:01] <hyc> If you want everyoen to feel like they are valued participants, you have to allow them the opportunity to participate. [22:58:16] <hyc> When you do this, you send the clear message that they are not valued. [22:58:16] <mru> that is _exactly_ what we are doing [22:58:47] <bcoudurier> jannau, there are some problems with my email in some commits [22:59:00] <bcoudurier> my email @smartjog.com which is outdated [22:59:24] <Kovensky> 19:57.32 jannau: he has at least 3 patches in ffmpeg <-- who, anders or stefano? [22:59:32] <jannau> bcoudurier: damn, could you have noticed earlier [22:59:36] <hyc> Anyway, I tended to agree with Stefano's post - the end result may have been no different, and this result may in fact be the best going forward [22:59:45] <DonDiego> hyc: you have a point there, but it's a bit more difficult than that [22:59:47] <jannau> Kovensky: anders, all from december 2008 [22:59:55] <DonDiego> we were running into timing problems [23:00:20] <DonDiego> at some point it was clear that there was no stopping this [23:00:45] <DonDiego> and with a group of about 20 people it's also clear that it's enough to keep it alive and going [23:00:52] <DonDiego> the first idea was to fork [23:01:13] <Kovensky> I knew about the fork idea [23:01:22] <DonDiego> but why should we fork when we are the majority and when michael has done what he could to fork away from us in the past? [23:01:53] <Kovensky> fork away from you? [23:02:22] <DonDiego> kicking out people, being generally paranoid and moving away from mphq [23:02:44] <DonDiego> there have been multiple tries to make amends with michael behind the scenes [23:02:51] <DonDiego> but they all failed [23:03:15] <wm4> being paranoid? [23:03:26] <DonDiego> also it was a bit a question who was available on irc [23:03:28] <Dark_Shikari> Then post to the ML about that. [23:03:46] <DonDiego> so something of good/bad luck and timing [23:03:51] <Kovensky> I also found weird michael's complete refusal to participate on IRC [23:03:52] <DonDiego> Dark_Shikari: who? [23:03:59] <Dark_Shikari> DonDiego: you [23:04:03] <Dark_Shikari> explain your reasoning. [23:04:23] <Kovensky> basically, throw oil in the ffflames [23:04:27] * Kovensky ducks [23:04:31] <DonDiego> that's what i want to avoid [23:05:03] <hyc> I'm perturbed that we are not using FaceBook as the primary developer communication medium. [23:05:13] <DonDiego> lol [23:05:19] * Dark_Shikari hits hyc with a giant hammer [23:05:22] * Kovensky facebooks [23:05:38] <mru> they should have project hosting on facebook [23:05:44] * saintdev Likes this. [23:05:45] <mru> then we could "like" commits [23:05:50] <hyc> Ooooo [23:06:03] <Kovensky> I thought you could "like" commits on github [23:06:04] <merbanan> what is this facebook everybody talks about ? [23:06:20] <Kovensky> it's when you take a book and thrust your face against it [23:06:21] * Kovensky ducks [23:06:27] <saintdev> Kovensky: beat me to it [23:06:32] <mru> merbanan: http://www.youtube.com/watch?v=e4q6eaLn2mY [23:06:39] <saintdev> Kovensky: preferably hardcover [23:06:48] <Dark_Shikari> merbanan: http://i51.tinypic.com/15yis7t.gif [23:06:50] <Dark_Shikari> That's a facebook. [23:07:32] <BBB> why like commits [23:07:33] <BBB> like bugs [23:07:37] <BBB> vote for bugs [23:07:47] <BBB> I WANT THIS FEATURE! I LIKED IT!!! WHY DONT YOU DO IT! [23:07:57] <jannau> bcoudurier: that were patches someone else committed and I took the email address from the commit message [23:07:59] <Kovensky> uservoice! [23:07:59] <BBB> (I know, bugzilla has that feature, it's retarded) [23:08:02] <saintdev> BBB: you need the fabled dislike button for bugs [23:09:31] <DonDiego> hmmmmmm [23:09:44] <jannau> mru: I have though of extending cgit for flattr'ing of commits [23:10:41] <bcoudurier> jannau, no [23:10:47] <bcoudurier> see a4dc7aa5b5f2b8d1a2993b9887c0428e6b01677f [23:12:15] <jannau> bcoudurier: the "patch by" has only a single email address for every name [23:13:06] <jannau> +parsing script [23:13:42] <lu_zero> jannau: sounds interesting [23:14:00] <bcoudurier> jannau, why does this commit in the middle of nowhere has this email address ? [23:14:34] <bcoudurier> err [23:14:47] <jannau> lu_zero: http://git.jannau.net/git/FFmpeg.git.convert/tree/map_patchby.sh [23:15:18] <jannau> bcoudurier: it was committed by stefano and has "Patch by Baptiste" in it's commit message [23:15:35] <mru> ot: anyone interested in working at amazon on the kindle? [23:15:45] <DonDiego> doing what? [23:15:45] <mru> they're still hiring apparently [23:15:58] <bcoudurier> why is the mail smartjog ? [23:15:58] <BBB> does anyone want to work for cisco as a consultant? [23:16:00] <bcoudurier> this is wrong [23:16:11] <mru> they're looking for both OS and browser devs [23:17:00] <bcoudurier> is it too late to fix ? [23:17:14] <mru> it will ruin everybody's clones [23:17:18] <jannau> bcoudurier: I'm sorry, but it was a massive amount of work to get the mappings done and nobody was interested in reviewing it [23:17:37] <bcoudurier> well I don't see how this could slip in [23:17:51] <bcoudurier> this is a bug in the script [23:18:12] <mru> bcoudurier: maybe jannau doesn't know which email addresses are current for all developers [23:18:13] <jannau> mru: as far as I know they are only looking for US based devs [23:18:23] <mru> jannau: they'll assist with relocation [23:18:58] <mru> "We're interested in hiring the best talent available on a truly global basis, and would be interested in hearing from talented engineers regardless of current locale." [23:19:05] <jannau> the recruiting spam I got in december was US only [23:20:33] <BBB> mru: send to mike and alex converse [23:20:36] <BBB> mru: they're looking [23:20:44] <BBB> brb [23:22:30] <jannau> or at least I was on their US-based kernel hackers list [23:23:14] <mru> mike melanson? [23:23:21] <mru> has he had enough of flash? [23:32:29] <DonDiego> bcoudurier: work for cisco doing what? [23:32:33] <TheUni> mru: welcome back (cory, from xbmc) [23:32:47] <TheUni> mru: any reason to allow dirlisting here: http://git.ffmpeg.org/ffmpeg.git/ ? [23:33:33] <lu_zero> TheUni: http clone I think [23:35:55] <mru> does that require dirlisting? [23:36:00] <mru> not that allowing it does any harm [23:36:23] <TheUni> mru: if you're going to list it, i'd at least hide it from crawlers [23:39:47] <jannau> mru: post-receive hook calls git update-server-info for http access [23:40:14] <mru> right, I should know that... [23:47:49] <mru> there, fixed [23:47:56] <mru> thanks for noticing [23:48:08] <TheUni> yup, good, thanks [23:48:24] <TheUni> don't think much would've come of it other than bots hitting you for useless files [23:49:38] <mru> yeah, it's not like anyone could cause any real damage [23:51:31] <TheUni> mru: also, https cert issues. I'm not sure if you're doing pubkey auth only or not, but our win32 devs have found that https pushes ease the pain of moving to git [23:51:51] <mru> we're using ssh only [23:52:12] <mru> I don't trust web servers to write my repos [23:52:27] <TheUni> ok [23:52:45] <mru> we support read-only git and http of course [23:52:46] <DonDiego> http://pastebin.com/Un0xHjkw [23:52:49] <DonDiego> reply [23:54:28] <mru> looks good [23:55:19] <DonDiego> jannau, BBB, Dark_Shikari, merbanan, whomever? [23:56:41] <Dark_Shikari> You might want to state something along the lines of "this was to avoid a fork" [23:56:51] <Dark_Shikari> with regard to the mention of the fork [23:57:22] <DonDiego> just a sec [23:57:36] <DonDiego> i'd again appreciate if somebody less controversial could send

1 0