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