Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2011

1 participants
28 discussions

IRC log for 2011-02-27
by irc＠mansr.com 28 Feb '11

28 Feb '11

[00:38:16] <j0sh> merbanan: ah alright [07:22:26] <ohsix> what are the odds of something like this uses mplayer or ffmpeg? http://www.dealextreme.com/p/1080p-full-hd-2-5-sata-hdd-media-player-with-h… [07:22:51] <kierank> maybe for demuxing [07:23:41] <ohsix> i wanna get one but theres never any information on what they actually play, aside from a list of formats and containers [07:24:27] <ohsix> need vobsub too D: [07:24:51] <kierank> there's never any information probably because the manufacturer doesn't even know themselves [07:26:32] <ohsix> i have a drive free thatneeds a case anyways, figured i'd do both [10:05:53] <mmu> gee, the fate run I started before going to bed isn't finished [10:30:08] <lu_zero> mmu how so? [10:31:01] <mmu> athlon xp ... [10:31:16] <mmu> could use a progress indicator on stdout [10:31:46] <mmu> it's at fate-musep... [11:00:51] <lu_zero> uhm [11:59:07] <DonDiego> BBB: still queueing patches for ruggles? why? [12:21:40] <mmu> real 411m27.047s [12:21:41] <mmu> user 33m57.142s [12:21:42] <mmu> sys 304m18.420s [12:21:59] <mru> os not so good [12:22:44] <uau> lu_zero: why "pkg-config sdl --modversion > /dev/null 2>&1" instead of "pkg-config --exists sdl"? [12:23:13] <mmu> building vbox along [12:23:25] <mmu> http://fate.ffmpeg.org/x86_32-haiku-gcc-4.4.4 [12:39:42] <lu_zero> uau: no reason at all, your proposal makes more sense [12:47:15] <DonDiego> btw, i'm (finally) fixing the snapshot generation script [12:47:30] <lu_zero> =) [12:47:31] <lu_zero> nice [12:47:58] <DonDiego> should the tarball unpack to a directory called plain 'ffmpeg' or 'ffmpeg-something' where 'something' is the git hash for HEAD or so? [12:48:19] <DonDiego> i've got a better idea - i will go with the date.. [12:48:23] <lu_zero> =) [12:48:30] <lu_zero> that would be nicer indeed [12:50:07] <DonDiego> confessional style of debugging strikes again :) [12:50:27] <DonDiego> it's funny how often you get better ideas on your own when you explain a problem... :) [12:50:44] <andoma> yeah :) [12:51:03] <mru> sometimes it's only when you try to explain it that you actually fully formulate the problem [12:57:23] <DonDiego> yes [12:57:48] <DonDiego> what should i use as name for the snapshot tarballs? [12:58:10] <DonDiego> i'm creating one with full git history and another one with the .git subdir deleted [12:58:38] <DonDiego> previously they were called 'checkout' and 'export' to mirror the respective svn commands used to generate them [12:58:58] <DonDiego> 'history' and 'bare' maybe? [12:59:04] <mru> what's the point of creating snapshots with .git included? [12:59:17] <mru> people who want that are better off using git directly [12:59:34] <mru> see also the "git archive" command [12:59:51] <DonDiego> maybe git is not allowed through the company firewall or similar [13:00:04] <mru> then clone over http [13:00:08] <mru> we support that [13:00:15] <DonDiego> and probably less bandwidth used and less load for our server [13:01:00] <mru> I doubt a few http cloners will be a problem [13:07:36] <DonDiego> i don't think so either, but a git tarball cannot hurt [13:07:57] <DonDiego> it could be useful for some people [13:08:31] <DonDiego> it's just a few more commands in the shell script... [13:54:18] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r0b32da90f8 ffmpeg/libavcodec/arm/vp8_armv6.S: [13:54:18] <CIA-15> ffmpeg: ARM: VP8: fix build on systems with global symbol prefix [13:54:18] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:54:20] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r8b454c352f ffmpeg/libavcodec/arm/vp8dsp_neon.S: [13:54:20] <CIA-15> ffmpeg: ARM: fix vp8 neon with pic enabled [13:54:20] <CIA-15> ffmpeg: The assembler emits literal pools too far from the load instructions, [13:54:20] <CIA-15> ffmpeg: so we must do it explicitly at a suitable location. [13:54:21] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:55:00] <lu_zero> mru: is there a specific reason for that? [13:55:12] <mru> which? [13:57:05] <lu_zero> The assembler emits literal pools too far from the load instructions [13:57:13] <mru> buggy assembler [13:57:16] <mru> what else? [13:57:32] <lu_zero> that's what I'm wondering [14:21:59] <BBB> lu_zero: can you please re-queue it? not sure how but it got lost [14:22:05] <BBB> although I'm pretty sure I did queue and push it [14:22:07] <BBB> odd [14:25:25] <lu_zero> just noticed now it was missing ^^; [14:25:35] <lu_zero> wine-tested it though [14:25:39] <lu_zero> seems working fine [14:25:46] <lu_zero> queuing up myself then =) [14:27:01] <lu_zero> curious it doesn't apply anymore to master... [14:27:19] <lu_zero> uhm [14:27:25] <lu_zero> got in already [14:47:19] <BBB> where is kshishkov [14:51:19] <siretart> DonDiego: ffmpeg 0.5.4? [14:56:16] <lu_zero> BBB: btw [14:56:22] <BBB> ? [14:56:34] <lu_zero> the applehttpproto does solve a number of issues [14:56:40] <BBB> ? [14:56:56] <lu_zero> (some are solved removing the timestamp guessing code but I'm digressing) [14:57:04] <BBB> :-p [14:58:33] <lu_zero> BBB: still I'd push martin's alternative as well [14:59:08] <BBB> I'm lost [14:59:16] <BBB> which lternative? [15:00:24] <lu_zero> we have two implementations from martin [15:01:23] <BBB> I probably missed them :-p [15:01:27] <BBB> looking into some major vc1 issues [15:01:28] <lu_zero> as protocol -> more robust towards non-standard implementation, relies on the mpegts demuxer [15:02:12] <lu_zero> as chain demuxer -> gets the best of the timestamp guessing code breaking remuxing and can miss segments in certain situations [15:08:02] <lu_zero> btw I'm thinking about having the tcp protocol have a listen option [15:09:06] * lu_zero found useful do stuff like ffmpeg -i tcp://localhost:1234 on an host and ffmpeg -i stuff tcp://thathost:1234 on another [15:10:02] <siretart> neat [15:27:45] <lu_zero> uhmm [15:27:58] <lu_zero> do we really need that rentry code on tcp.c? [15:37:03] <Sean_McG> if I'm fixing a patch using git, do I have to unstage it, fix it and recommit or is there a way to edit it? [15:38:03] <jannau> Sean_McG: if it's the last commit: edit; git add -p; git commit --amend [15:38:56] <Sean_McG> OK [15:46:22] <mru> fate is looking very green today [15:46:43] <mmu> including for Haiku :) [15:49:17] <mru> all the failures are actually compiler bugs [15:49:53] <mmu> eh [15:56:47] <spaam> mru: did you report them? [15:57:13] <mru> some of them [16:10:30] <siretart> mru: can we keep it green until we bump and branch 0.7? ;-) [16:23:27] <mru> siretart: wouldn't that be great? [16:26:34] <siretart> mru: absolutely! [17:41:23] <Kovensky> supergreen! [17:42:07] * mru adds some more broken compilers [17:42:26] * Kovensky suggests tcc [17:42:44] <mru> I have no interest in tcc [17:47:23] <mmu> sdcc maybe ? [17:47:45] <BBB> mycc! [17:48:35] <BBB> mru: http://software.intel.com/en-us/forums/showthread.php?t=81056&o=a&s=lr [17:48:38] <mmu> PacifiC but I don't think it knows mmx in 16bit [17:48:40] <BBB> mru: we should submit problem reports to icc [17:48:41] <mmu> :p [17:48:52] <mru> go right ahead if you like [17:49:45] <BBB> who's interested in icc here? [17:49:48] <mru> there, another clang bug filed [17:49:49] * BBB scans for victims [17:49:57] <BBB> used to be carl eugen, but he's not on irc [17:51:00] <BBB> also I have the vc1 reference decoder running [17:51:10] <BBB> now I can see if weird crap output by our decoder is actually sane [17:51:24] <mmu> FCC ? [17:51:33] <mmu> ah no that's a stupid US admin [18:04:47] <kshishkov> BBB: I'll look at VC-1 in half an hour or so [18:04:57] <BBB> awesome [18:05:08] <BBB> I'm gonna run the testsuite with reference decoder and then compare [18:09:55] <Kovensky> 14:42.45 mru: I have no interest in tcc <-- I know, it's just to see it crying like a little girl in the corner when faced with ffmpeg [18:10:12] <mru> it's more fun doing that with "serious" compilers [18:14:02] <BBB> kshishkov: reference decoder picture order is as screwed up as with ours - I'm pretty sure this is not intended but maybe it's a bitstreambug or so? looks really weird [18:27:07] * mru finds a /* WTF?? */ comment in binutils [18:27:09] <mru> scary stuff [18:59:45] <kshishkov> BBB: I think they didn't care [19:01:33] <kshishkov> BBB: so neither should I :P [19:02:17] <Sean_McG> what's tcc? [19:02:27] <iive> tiny c compiler [19:02:30] <kshishkov> C compiler from FFmpeg creator [19:02:35] <kshishkov> (QEMU too) [19:02:38] <Sean_McG> ah [19:02:55] <iive> qemu uses it to compile code in realtime.. (kind of) [19:03:35] <kshishkov> mru: have you tried PCC release or the fact BSD loves it is enough to shun it? [19:03:54] <mru> ICE on ffmpeg [19:03:58] <mru> several [19:04:28] <mru> and it generally sucks too [19:04:32] <kshishkov> well, even if its current devs are crazy they may listen to you [19:32:46] <mru> hmm, maybe I should file another clang bug [19:33:44] <kshishkov> got hooked on compiler bug reporting? [19:34:42] <Sean_McG> I'm admittedly not smart enough to fix the bugs I've reported on GCC, but I like to know that I at least helped [19:44:20] <lu_zero> kshishkov: the current devs are more crazy than gcc ones? [19:45:01] <kshishkov> lu_zero: who knows - but tey are crazy by definition. Ask mru what he thinks about devs from Umeå [19:45:32] <mru> luleå [19:45:56] <kshishkov> ah yes [19:46:04] <kshishkov> same thing for you though [19:46:53] <lu_zero> ^^; [19:49:36] <lu_zero> the fact they use cvs tells everything... [19:49:43] <Sean_McG> lol [19:49:50] <kshishkov> that they are still in 70s? [19:49:58] * lu_zero ponders to suggest them to move to git in their mailing list [19:49:59] <Sean_McG> I shouldn't laugh, I have to use cvs at work (government standards SUCK) [19:50:09] <lu_zero> Sean_McG: O_o? [19:50:24] <lu_zero> which government is that retro`? [19:50:35] <Sean_McG> yeah I tried to get subversion and they said we haven't approved it for use yet [19:50:41] <Sean_McG> I'm Canadian [19:51:16] <kshishkov> lu_zero: nowadays I find git-svn extremely useful [19:51:17] <lu_zero> ah [19:51:25] <lu_zero> kshishkov: ^^ [19:51:40] <kshishkov> I think I'm the second guy who used it at work [19:52:06] <mru> Sean_McG: I'd suggest running some kind of git frontend on your workstation [19:52:20] <mru> and obviously don't tell IT dept about it [19:52:28] <Sean_McG> they have inventory scanners. [19:53:14] <Sean_McG> so I just put up with it... and Rational Developer doesn't have integration with other SCMs anyways [19:53:19] <Sean_McG> other than CVS & ClearCase [19:53:33] <Sean_McG> and we don't have ClearCase licenses [19:54:28] * kshishkov always thought that IBM software was just a subliminal way to promote IBM hardware [19:54:45] <Sean_McG> in the case of WebSphere I'm not so sure [19:55:00] <Sean_McG> most of our server are HP blades [19:56:14] <mru> what, you can't install your own sw? [19:56:23] <Sean_McG> nope [19:56:35] <mru> do yourself a favour and quit [19:56:37] <mru> NOW [19:56:38] <Sean_McG> I've actually had an IT Sec. guy come to my desk when I installed the Active Directory toolkit [19:57:00] <Sean_McG> mru: I'm looking to leave, but there isn't much here for my skillset (I'm a Tivoli guy) [19:57:17] <mru> where's "here"? [19:57:29] <mru> and how far are you willing to move? [19:57:37] <Sean_McG> I'm with Canada Revenue, and I'm not really willing to move [19:58:09] <mru> I was expect a city as answer... [19:58:11] <mru> +ing [19:58:17] <Sean_McG> oh.... Ottawa, Ontario [19:58:26] <Sean_McG> Canada's capital [19:58:51] * thresh shudders when he hears IBM [19:58:54] <kshishkov> not for all Canada though :P [19:59:02] <mru> well, if you don't want to move... [19:59:03] <kshishkov> thresh: HP C compiler is better? [19:59:08] * thresh shudders more [19:59:19] <mru> IBM's xlc compiler also fails on ffmpeg [19:59:26] <Sean_McG> really? I'd figure vendor compilers blew away gcc [19:59:35] <Sean_McG> mru: are there a lot of gcc-isms in ffmpeg? [19:59:39] <mru> none [19:59:42] <mru> only inline asm [19:59:52] <mru> and some attributes [19:59:57] <mru> but they're all optional [20:00:08] <mru> a pure c99 compiler should work [20:00:34] <kshishkov> Sean_McG: we actually learned about lots of IBM products at uni, our department is even IBM Business Partner but I ended not working by speciality and proud of it! [20:01:01] <Sean_McG> kshishkov: *nodnod* [20:01:05] <Sean_McG> kshishkov: where did you study? [20:01:41] <mru> it was fun playing with an ibm (ex) supercomputer at uni [20:01:49] <kshishkov> Sean_McG: National Technical University "Kharkiv Polytechnical Institute" (Ukraine) [20:02:13] <Sean_McG> I guess the beefiest machine we have at work is our zSeries [20:02:29] <Sean_McG> I've done mainframe stuff before, it's kinda boring [20:02:42] <kshishkov> mru: at our uni we had documentation for one ordered to be thrown away short before we got server [20:03:48] <mru> they let us play on an sp/2 system [20:03:57] <Sean_McG> processing tax data is more I/O intensive than compute [20:04:16] <Sean_McG> they proved that when they tried to switch to Sun and the machines keeled over with the load [20:04:40] <kshishkov> mru: we had Intenet access at some classes but it being ~2 KB/sec (for whole class) was not very appealing [20:05:06] <mru> kshishkov: heard of sunet? [20:05:17] <kshishkov> nope [20:05:22] <mru> swedish university network [20:05:36] <mru> very fast [20:05:55] <kshishkov> we had an access to Ukrainian universities network but nobody actually knew where it is and how to use it [20:06:41] <spaam> sunet is awesomre [20:06:47] <spaam> awesome [20:07:02] <kshishkov> Swedish Internet in general too [20:07:16] <kshishkov> even ordinary grannies can get fast enough access [20:07:54] <mru> does clang use a builtin assembler? [20:08:12] <kshishkov> yep [20:08:21] <mru> that explains it [20:08:37] <mru> time for a bug report, I think [20:09:21] <ruggles> Tjoppen: ping [20:09:23] <Sean_McG> mmm fiber to the home [20:09:30] <Sean_McG> so jealous [20:09:58] <mru> it would be nice, but adsl is usually good enough [20:10:18] <mru> the only time I've really suffered was when I got slashdotted [20:10:31] <mru> had to quickly mirror the page elsewhere [20:10:34] <kshishkov> or when you have to upload something somewhere else [20:11:10] <Sean_McG> I get 10mbit/512kbit cable here, and pay ~$50 a month for the priviledge! [20:11:25] <Sean_McG> (it's well known that Canadians pay WAAAAAY too much for Internet) [20:12:04] <mru> I pay about £30 for 24M/2M and 8 static IP [20:12:25] <kshishkov> I pay ~30EUR for 32/1M [20:12:41] <spaam> kshishkov: http://www.sunet.se/download/18.6d7c8917128274d3dd080006061/optosunetbrosch… about sunet :) [20:13:41] <kshishkov> spaam: not useful for me [20:15:29] <spaam> ok :) [20:17:15] <kshishkov> here even the only decent lingonsylt is the one made from Scandinavian berries [20:17:47] <Sean_McG> mmm lingonberry juice... now I wanna go to Ikea! [20:18:06] * kshishkov wants to go to Sweden but that's no news [20:19:21] <kshishkov> the best sausage I've ever tried is called Hjörtkorv too [20:20:02] <mru> sure that's not hjort? [20:20:20] <kshishkov> no [20:20:35] <kshishkov> could be renkorv though too [20:20:39] <mru> google gets exactly one hit for Hjörtkorv [20:21:35] <mru> and that one seems to be a typo [20:21:45] <kshishkov> indeed [20:26:25] <Sean_McG> damn, I never wrote down how I didn my 64-bit openssl builds [20:26:38] * mru does emerge openssl :) [20:26:42] <spaam> :) [20:26:51] <Sean_McG> I'm on Solaris 10 SPARC in this case :P~ [20:27:00] <mru> you can still use portage [20:27:00] <Sean_McG> SunFreeware's package is only 32-bit [20:27:20] <lu_zero> Sean_McG: gentoo-prefix is your friend [20:27:54] <Sean_McG> I'm not sure I want to install a whole new packaging system [20:28:33] <mru> portage is awesome [20:28:35] <lu_zero> http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml [20:28:57] <spaam> kan you use portage on osx? [20:29:03] <lu_zero> sure [20:29:10] <mru> I've seen it running on windows even [20:29:15] <kshishkov> I used itthere [20:29:18] <spaam> haha cool [20:29:24] <mru> does it work on irix? [20:29:25] <lu_zero> http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-macos.xml [20:29:34] <spaam> cool [20:29:35] <lu_zero> same guide as solaris [20:29:44] <spaam> then i can remove macports :) [20:30:03] <lu_zero> spaam: help and contributions welcome =) [20:32:12] <spaam> lu_zero: i will try it tomorrow at work :) [20:33:38] <lu_zero> =) [20:36:56] <Tjoppen> ruggles: you rang? [20:38:00] <Dark_Shikari> http://www.theonion.com/articles/nation-shudders-at-large-block-of-uninterr… [20:39:00] <mru> Dark_Shikari: they should try reading german [20:39:32] <mru> I once saw a single sentence span an entire page [20:39:50] <mru> if I read german more often, I'd probably see more of those [20:44:19] <kshishkov> mru: I wrote such sentences in Russian too! [21:53:03] <DonDiego> siretart: still online? [21:53:30] <DonDiego> siretart: i gave you a paste with changes for 0.5.4, did you apply them already? [21:55:51] <siretart> DonDiego: no, I didn't see the past [21:55:56] <siretart> maybe my client crashed [21:56:00] <siretart> and I'm about to crash as well [21:56:51] <DonDiego> beastd: hi, long time no see [21:57:15] <mru> peloverde: nice link [21:57:29] <beastd> Hi Diego [21:57:54] <Sean_McG> watching this poisonous people clip that Alex posted (I've never seen it before) [21:59:42] <siretart> DonDiego: what changes do you have? [22:02:04] <Sean_McG> 5PM and I am nowhere near done the chores I need to do, plus I was gonna make a pot of chili [22:02:07] <Sean_McG> argh [22:21:11] <ruggles> Tjoppen: do you have any lxf 20-bit pcm samples? we have the decoder but i can't find a sample to test with anywhere. [22:21:58] <spaam> ruggles: cant you create 20bit pcm stuff with rox ? [22:22:01] <spaam> sox. [22:22:05] <merbanan> ruggles: I'll remind him tomorrow [22:22:24] <saintd3v> peloverde: did you get a chance to glance at that patch? [22:22:33] <ruggles> spaam: it's a special format, not normal 20-bit pcm [22:22:47] <ruggles> CODEC_ID_PCM_LXF [22:22:56] <spaam> ruggles: ah ok :) [22:25:27] <BBB> ruggles: is aften merge done? [22:26:57] <ruggles> BBB: not yet. basically setting ac3 metadata via avoption is the only part left that is currently in aften and is worth porting. [22:27:49] <ruggles> but i took a small break to work on audio decoding API. just going back through all decoders to double-check and test things not covered by fate. [22:28:41] <ruggles> which is why i need a PCM_LXF sample. :) [22:28:49] <saintd3v> ruggles: did you see the FFPsyContext patch? [22:29:07] <ruggles> saintd3v: no... [22:29:19] <ruggles> on ffmpeg-devel? [22:31:39] <saintd3v> no [22:32:02] <saintd3v> swear i posted a link here, but can't find it in my logs... [22:32:13] <saintd3v> ruggles: http://pastebin.com/j4gNgj4e [22:34:20] <Tjoppen> ruggles: I do. I can take a look at work tomorrow [22:34:25] <ruggles> saintd3v: ac3 needs 7 channels. there is a separate coupling channel that goes through the psy model & bit allocation. [22:34:28] <ruggles> Tjoppen: thanks [22:34:48] <Tjoppen> 4-cba e [22:34:54] <Tjoppen> *4-channel 20-bit IIRC [22:35:44] <ruggles> saintd3v: i like the patch though [22:42:11] <saintd3v> ruggles: sure, 6 was just an arbitrary number, it could be 20 for all it really matters. [23:08:40] <DonDiego> gnite [23:32:46] <peloverde> saintd3v: the patch doesn't seem to play nice with the spreading changes [23:37:11] <saintd3v> oh, forgot i had comitted the energy spreading changeset already [23:41:38] <saintd3v> peloverde: this is vs. ffmpeg.org http://pastebin.com/MwPKkzyj [23:44:14] <mru> anyone here on friendly terms with clang? [23:44:31] <mru> error: unable to interface with target machine [23:44:41] <mru> ^^ any ideas what that means? [23:44:57] <mru> Yuvi: ^^ [23:47:54] <Sean_McG> brb [23:48:09] <roxfan> haha [23:48:32] <roxfan> at fosdem they bragged about how their error messages are so much better than gcc [23:48:55] <mru> some of their code error messages are better [23:49:04] <mru> but their command line syntax is a complete mess [23:49:25] <mru> there are at least 3 layers of option handling [23:49:33] <peloverde> saintd3v: what is aacpsy.c using from float.h? [23:50:48] <saintd3v> nothing any more. i was using FLT_MIN somewhere. [23:51:19] <roxfan> looks like it happens if TM->addPassesToEmitFile fails [23:51:19] <saintd3v> oh, for pe_max [23:51:22] <roxfan> "This method should return true if emission of this file type is not supported, or false on success." [23:52:14] <saintd3v> but i just recently changed that to use shoehorn values similar to what 3gpp uses

1 0

IRC log for 2011-02-26
by irc＠mansr.com 27 Feb '11

27 Feb '11

[00:02:15] <skal> ;5D/win goto 2 [00:02:18] <skal> blah [00:29:45] <pross-au> fast decoder != on2 profit [00:29:59] <kierank> of course [00:30:17] <kierank> but a quality product is conducive towards more profit [00:30:48] <pross-au> agree totally [00:31:06] <mru> for that it has to be actually good [00:31:16] <pross-au> besides, you gotta leave scope for vp9 [00:31:16] <mru> not merely good enough to sell [00:31:22] <pross-au> otherwise be out of a job [00:31:56] <mru> the profit/effort is often higher in churning out a series of mediocre products and spending some money on marketing hype [00:32:29] <pross-au> precisely [00:32:43] <pross-au> theres something inherently wrong with that, the world [00:35:13] <mru> solution: shoot the PHBs [00:40:47] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r13ff92d197 ffmpeg/libavformat/movenc.c: [00:40:47] <CIA-15> ffmpeg: movenc: remove uses of deprecated API. [00:40:47] <CIA-15> ffmpeg: Replace put_tag() with ffio_wfourcc() and ByteIOContext with AVIOContext. [00:41:24] * Terminating due to: TERM [00:41:37] * /join #ffmpeg-devel ... [00:41:41] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | Channel is logged. [00:41:41] *** TOPICINFO: merbzt!~benjamin(a)m83-186-120-172.cust.tele2.se, 1295456661 [01:26:18] <BBB> Dark_Shikari: don't forget that "sharing code between ffvp8 and rest of ffmpeg" is our attempt at a PR thing [01:26:36] <BBB> Dark_Shikari: it doesn't have to be super-significant, I mean, "goldenframes, woohoo!!!", it's all about how it sounds to the public [01:27:02] <BBB> Dark_Shikari: and sharing code sounds fantastic to the public :) [01:27:37] <kierank> PR thing and a troll at the same time [01:27:45] <kierank> bbbut vp8 uses h.264 prediction [01:27:49] <kierank> what about the patents! [01:29:12] <gnafu> OMGNO! [01:29:22] <gnafu> :-P [03:29:36] <Dark_Shikari> http://pic.phyrefile.com/s/sf/sft/2011/02/24/keepern_1.png [03:29:47] <Dark_Shikari> screenshots from the first commercial fully-x264-encoded bluray. [03:30:11] <mru> not bad [03:30:17] <mru> what film? [03:30:17] <Dark_Shikari> http://pic.phyrefile.com/s/sf/sft/2011/02/24/keepern_2.png [03:30:19] <Dark_Shikari> http://pic.phyrefile.com/s/sf/sft/2011/02/24/keepern_3.png [03:30:28] <Dark_Shikari> http://www.imdb.com/title/tt1488574/ [03:30:36] <Dark_Shikari> Norwegian comedy film. [03:33:25] <Dark_Shikari> Note the error-diffusion dither from 10-bit input. [03:34:41] <mru> so those are the good frames, what are the bad ones like? [03:35:02] <Dark_Shikari> Dunno, those were just the ones someone posted. [03:35:23] <Dark_Shikari> There's one bit of information those frames give you: it wasn't lowpassed. [03:35:39] <mru> of course, bluray has enough bitrate that bad frames aren't really excusable [03:36:28] * saintd3v waits for the blug post [03:36:30] <saintd3v> =P [03:36:45] <Dark_Shikari> I have more important things to do, like play more civ4 [03:37:01] <saintd3v> blog about civ4! [03:38:00] <mru> when will they include blogs as a game element? [03:39:16] <j0sh> isn't civ5 out already [03:39:20] <Dark_Shikari> yes. it's crap. [03:39:21] <saintd3v> even better, little awards that are automatically posted to your facebook prof....oh, wait... [03:39:46] <j0sh> i swore off civ after i started college. wasted too much time in high school on civ3 [03:39:48] <mru> saintd3v: no, I mean virtual in-game-only blogs [03:40:05] <saintd3v> mru: virtual in-game facebook, lol [03:40:34] <mru> http://www.youtube.com/watch?v=Rw8gE3lnpLQ [03:41:26] <saintd3v> onion \o/ [03:41:49] <drv> there's already an in-game facebook in the newest need for speed [03:42:14] <mru> I thought need for speed was a racing game [03:42:16] <kierank> there's also those random microsoft things in arkham asylum [03:42:18] <drv> it is [03:42:20] <mru> clearly I have not been paying attention [03:42:23] <drv> when you beat your friends, it posts that to your "wall" [03:42:32] <mru> oh, that's something else [03:42:40] <saintd3v> kierank: you mean the achievements? [03:42:50] <kierank> yes [03:43:04] <saintd3v> yeah, achievements are old.. [03:43:16] <kierank> yeah but it posts them to your hotmail account [03:43:24] <kierank> and iirc you couldn't start playing without logging in [03:43:34] <saintd3v> yeah you can [03:43:52] <saintd3v> you have to setup an offline games for windows account [03:44:12] <saintd3v> and you can't carry your game progress over to an actual games for windows account [03:44:58] <saintd3v> found that out _after_ i had beaten the game, and wanted to go back and get some of the achievements :/ [03:45:07] <Dark_Shikari> "achievements" lololol [03:45:48] <saintd3v> Dark_Shikari: well they tell more of the story [03:45:54] <kierank> they do? [03:45:55] <Sho_> The only achievement I'm perpetually unlocking is not to care about the achievements metagame [03:46:43] <mru> some game I was playing once crashed in a curious fashion [03:46:45] <saintd3v> kierank: all of arkham's writings [03:47:15] <kierank> oh those. don't care about them [03:47:16] <mru> after restarting the ps3, it listed all the extras as completed [03:47:17] <saintd3v> needless to say i didn't feel like beating the game again just to do it, so i gave up [07:40:36] <rukhsana> Hi [07:41:16] <rukhsana> 'I want to participate in GSoC this year' [07:42:06] <rukhsana> 'I want to work on JPEG 2000 project which was abandoed last year' [07:43:31] <kierank> did you complete your qualification task [07:43:43] <rukhsana> 'I already have created an account in gitorious repository in order to create a clone to work on ffmpeg' [07:44:20] <rukhsana> 'Actually I just have started, I did not pass the qualification task yet' [07:44:34] <in3xes_> how to debug demuxer_probe() [07:44:48] <kierank> rukhsana: I mean your other qualification task [07:45:16] <kierank> top-posting one [07:45:35] <rukhsana> 'yes, I have passed that probably' [07:46:11] <rukhsana> 'right now, I know what is top-posting and will avoid it from now on' [07:46:45] <kierank> why do you write in single quotes? [07:47:04] <rukhsana> I did not user IRC before [07:47:20] <rukhsana> this is the first time i am using ITC chat [07:47:40] <rukhsana> that's why I was probably making mistake [07:48:01] <rukhsana> Thanks for the correction [07:48:49] <kierank> do you have the jpeg2000 spec? [07:48:51] <in3xes_> calling av_log() in xxx_probe() and `ffprobe input_sample` should work? [07:50:09] <rukhsana> I just have the JPEG 2000 code downloaded from svn. however, i did not see spec for JPEG 2000 [07:52:27] <kierank> lemme see if i can find it [07:53:53] <rukhsana> Thank you kierank [07:59:34] <kierank> http://dl.dropbox.com/u/2701213/Specs/JPEG2000/15444-1annexi.pdf [07:59:47] <kierank> seems to be on the mplayerhq ftp [08:00:07] <rukhsana> Thank you very much [08:00:18] <rukhsana> I will go through it [08:00:47] <kierank> probably easier to try understanding the code [08:00:59] <kierank> or finding a book that summarises jpeg2000 [08:01:41] <rukhsana> ok, I will go through the code too [08:02:05] <kierank> i would strongly recommend finding a book that explains the basics otherwise you will get nowhere [08:02:19] <rukhsana> I will get back to you guys soon. [08:03:09] <rukhsana> I will try to find a book too [08:04:04] <kierank> something like http://www.amazon.co.uk/JPEG2000-Compression-Fundamentals-International-Eng… [08:04:50] <rukhsana> ok, thank you very much [08:05:55] <in3xes> Suggest me simplest demuxer to look at the code [08:12:40] <kierank> in3xes: wav [08:12:52] <saintdev> peloverde: ping [08:13:44] <in3xes> Ok [08:14:04] <peloverde> saintdev: pong [08:14:50] <saintdev> peloverde: would you mind doing a review on my current tree? [08:15:46] <peloverde> I should have some time for it tomorrow, it's kind of late here right now, and I'm knee deep in minecraft [08:16:13] <saintdev> minecraft, hehe [08:19:02] <peloverde> now that I've gotten the hang of it, it has become fun [08:19:48] <saintdev> built yourself a computer yet? [08:22:07] <peloverde> yes, the next goal is to port ffmpeg to it :) [08:23:29] <saintdev> new arch on fate? [08:24:38] <pJok> ffminecraft? [08:25:07] <saintdev> minecraft-ffmpeg-minecraftcc-1.0 [08:25:15] <kierank> cuda edition (tm) [08:27:34] <pJok> well [08:27:37] <pJok> its all java [08:27:44] <pJok> so it will take ages to get anywhere ;) [08:57:47] <saintdev> grr, how come every command line pastebin script seems to be broken :( [09:10:33] <saintdev> peloverde: whenever you get a chance. I've still got more work to do, so no rush. http://pastebin.com/2ENEGzxQ [09:13:24] <saintdev> oops, forget the top change =P [10:15:35] <cryptw> saintdev: use sprunge [11:32:45] <BBB> mru: please update clang, 126540 should fix it [11:33:02] <mru> updating [11:33:25] <mru> so it was a clang bug [11:33:30] <Dark_Shikari> What'd they change? [11:35:00] <kshishkov> switched to pure C? [11:45:16] <mru> hmm, there's still a fixme in the code [11:45:22] <mru> let's break it! [11:45:27] <Dark_Shikari> link to the diff? [11:45:29] <Dark_Shikari> or the commit? [11:45:33] <mru> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?r1=126… [11:46:28] <Dark_Shikari> oh ho ho [11:49:28] <mru> updated [11:49:38] <Dark_Shikari> ? [11:49:46] <Dark_Shikari> oh, on the fate box. [11:52:43] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * raa3805a486 ffmpeg/configure: [11:52:43] <CIA-15> ffmpeg: fate: get samples location from env var if not explicitly set [11:52:43] <CIA-15> ffmpeg: Use the FATE_SAMPLES environment variable if samples location [11:52:43] <CIA-15> ffmpeg: is not set with the --samples configure option or on the make [11:52:43] <CIA-15> ffmpeg: command line. [11:52:44] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [11:56:10] <wbs> mru: I'm getting errors building the vp8 neon assembler code with the android NDK, these errors: http://pastebin.com/2fGRcamE [11:56:28] <mru> buggy assembler [11:56:34] <mru> and why are you building PIC? [11:57:30] <wbs> good question [11:57:40] <kurosu> ndk mandates it [11:57:48] <mru> madness [11:57:57] <kurosu> check toolchain/<version>/setup.mk [11:58:05] <MrNaz> ok i'm getting this: No such filter: 'pixelaspect' <-- didn't the syntax for setting the PAR *just* change recently? http://paste.pocoo.org/show/344767/ <--- that's the command i'm using... ffmpeg and libx264 were built using current svn pull (an hour ago) and latest x264 tarball (also an hour ago)... (yes i know svn is deprecated i'll rebuild from git once i solve this) [11:58:06] <wbs> normally I do build it as shared libraries, to ease LGPL compliance in a commercial app [11:58:09] <mru> they don't allow sharing libs between processes anyway, do they? [11:58:15] <MrNaz> woops that was meant for #ffmpeg [11:58:16] <Dark_Shikari> mru: ffmpeg doesn't use svn anymore [11:58:25] <kurosu> TARGET_CFLAGS := -fpic -mthumb-interwork -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ [11:58:25] <mru> MrNaz: ^^ [11:58:49] <mru> omg what a broken command line [11:59:10] <MrNaz> mru mine? [11:59:12] <kurosu> yeah, the shared libs are specific to an application, nobody except the system is allowed to access them [11:59:23] <mru> MrNaz: no, kurosu's [11:59:33] <kurosu> ndk's, please :) [11:59:40] <kurosu> I'm not responsible for it :) [11:59:40] <mru> kurosu: so there's nothing to be gained from pic [12:00:01] <kurosu> there's a lot of weird stuff anyway, maybe making more sense to you than me [12:00:30] <kurosu> the only arch that can be targeted are armv5 or armv7, no armv6 and its FPU [12:00:55] <kurosu> (i may not make sense or use proper words, but i guess you should get what i mean) [12:01:30] <mru> wbs: does this fix it? http://pastie.org/1609516 [12:01:56] <mru> ok, here's what's wrong with those flags: [12:02:09] <mru> -fpic makes code slow for no benefit (since sharing is not allowed) [12:02:26] <mru> thumb interworking is only required on armv4t, which is not supported [12:02:50] <mru> -ffunction-sections can help remove dead code, but can also impact performance [12:03:09] <wbs> mru: yes, that helps, thanks :-) [12:03:19] <kurosu> how much slower for fpic? i thought this was mostly true for x86 due to register pressure [12:03:30] <mru> -funwind-tables is automatically enabled as needed [12:03:54] <mru> -fstack-protector is rather pointless in a sandbox environment [12:04:17] <kurosu> for thumb interworks, i guess it's dangerous as other parts of the system may depend on it (you do have access to system libs compiled with that) [12:04:26] <mru> -fno-short-enums is default [12:04:57] <mru> the __ARM_FOO__ symbols are defined automatically based on -march [12:05:20] <mru> kurosu: thumb interworking is simply not necessary on v5 and up [12:05:43] <kurosu> ok [12:05:45] <mru> v5t has the bx and blx instructions instead [12:06:02] <BBB> kurosu: you were right btw, vc1 idct must be done in 24 bits (and thus in 32 bits/int) [12:06:04] <kurosu> other cflags: -march=armv5te -msoft-float [12:06:30] <mru> see, that -march already defines all the __ARM_FOO__ things [12:06:34] <kurosu> BBB: i was wrong in fact, hoping we could get away with it [12:06:50] <mru> at least they don't conflict... [12:06:56] <kurosu> mru: yeah they add counter-effect cflags [12:07:09] <kurosu> not conflict, but break what the other implies [12:07:18] <BBB> kurosu: oh, well, join the club then, we were both wrong [12:07:28] <BBB> kurosu: I think you can almost get away with it, but it'll fail in corner cases [12:07:35] <BBB> kurosu: so needs 32bit I'm affraid [12:07:46] <kurosu> BBB: maybe branch based on qp ? (not sure at all) [12:07:59] <mru> apparently you can get away with it in most real videos [12:08:02] <kurosu> that's a lot of efforts probably [12:08:29] <BBB> I was actually thinking that also [12:08:49] <BBB> not just qp, but still [12:08:52] <BBB> something like that [12:09:09] <BBB> need to hook up the vc1 testsuite and see if it fails [12:09:13] <BBB> if it fails, then that's good [12:09:20] <BBB> if it doesn't, we don't care :) [12:09:22] <mru> kurosu: it's not as bad as what a hardware vendor insisted we use once: -mbig-endian ... -mlittle-endian [12:09:28] <kurosu> assuming 16bits arith will... at most double the throughput of the function, right? but would that really improve much? vc1 subpel interpolation still uses mmx, there'd be probably much more to be gained to add ssse3 versions [12:09:28] <mru> of course it broke [12:09:49] <BBB> kurosu: idct8x8 takes 15% here [12:09:52] <BBB> kurosu: so that first [12:09:57] <BBB> kurosu: but I'll do the others also [12:09:59] <Dark_Shikari> subpel takes less than idct? [12:10:06] <BBB> currently yes [12:10:08] <Dark_Shikari> have you summed up all the subpel functions? [12:10:12] <BBB> no [12:10:18] <kurosu> BBB: i mean having 16bits and 32b arith dct functions rather than ssse3 subpel [12:10:22] <Dark_Shikari> They probably use more when summed up [12:10:28] <BBB> possibly [12:10:32] <kurosu> mru: a *hardware* vendor ? do they not understand what they build? [12:11:58] * kurosu goes on removing cflags from its ndk command lines [12:12:30] <kurosu> it feels like cranking up to -funroll-loops=11! [12:13:14] <mru> kurosu: no, they do not [12:13:35] <mru> they take a chip and a ref board, slap their logo on it, and call it a product [12:14:16] <kurosu> yeah, i thought of writing rather manufacturate, and vendor says it all anyway [12:14:35] <mru> I don't remember which one it was [12:15:10] <kurosu> i'm just doing this as a hobby anyway, so the non-recommandation will not be of much use to me :) [12:15:21] <kurosu> and they are probably already bankrupted now :D [12:15:25] <mru> I doubt it [12:15:47] <kshishkov> kurosu: hw and sw vendors offering silliest stuff usually survive [12:15:47] <mru> likely candidates are thomson and humax [12:16:03] <kshishkov> mru: there's no thomson anymore [12:16:08] <mru> who bought them? [12:16:12] <wbs> I argued with an indian once... there was an api for setting/getting key-value pairs, like set(uint32_t key, uint32_t value); set(uint32_t keu, float value); (c++ with overloading etc)... for the keys, there were definitions like uint32_t keyFoo = 0x01; uint32_t keyBar = 0x02; etc. then he added float keyBaz = 0x04;, and I was unable to convince him that the key still should be uint32_t even if the _value_ stored with the ... [12:16:18] <wbs> ... key was float [12:16:31] <kshishkov> mru: they bought Technicolor and renamed themselves to it [12:16:42] <mru> so they still exist [12:16:45] * kierank knows of someone at humax [12:17:03] <mru> humax are a real pain to work with [12:17:08] <kshishkov> mru: of course, along with MP3 [12:17:28] <kierank> mru: the guy who I spoke to seemed quite helpful... [12:17:43] <kurosu> thomson *is* bankrupted essentially, their debt was pushed back again and again [12:17:55] <mru> kurosu: good [12:18:02] <kurosu> i think it's the other way around: technicolor bought them, afaik [12:18:03] <kshishkov> excellent! [12:18:05] <mru> kierank: they're friendly but mostly clueless in my experience [12:18:14] <mru> at least the people they'll let you talk to directly [12:18:27] <kurosu> i doubt banks would like an almost-dead company buying companies [12:18:32] <kshishkov> kurosu: next thing yu'll say that SCO bought Caldera [12:18:47] <kurosu> kshishkov: i'm indeed unsure, but that didn't make sense to me [12:18:54] <kierank> kurosu: the thomson h.264 encoder is quite good [12:19:06] <kurosu> is that grassvalley rather ? [12:19:33] <kierank> well I think it's all under the technicolor umbrella now [12:19:41] <kierank> but yes grassvalley [12:20:30] <mru> thomson gazelles grazing? [12:20:35] * mru sends in the lions [12:20:39] <kshishkov> kurosu: http://en.wikipedia.org/wiki/Technicolor_SA [12:21:04] <kurosu> yeah was checking that [12:21:17] <kurosu> didn't know it was already a subsidiary [12:23:04] <kshishkov> and they have shitloads of ideas about adding AAC extensions to MP3 too. Luckily none of them really catched up [12:24:38] <kurosu> kshishkov: though "they bought Technicolor and renamed themselves to it" was a bit misleading to me, as the 2 events seems quite separated in time (and having no link of causality); not an important matter anyway [12:54:52] <CIA-15> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * r52b3cc6047 ffmpeg/configure: [12:54:52] <CIA-15> ffmpeg: configure: document FATE_SAMPLES env var in --help text [12:54:52] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:07:21] <mru> clang is back to green \o/ [13:26:42] <mmu_man> plop [13:26:46] <mmu_man> Support the nomination of the International FLOSS Community to Prince of Asturias Award 2011 : http://www.cenatic.es/swlppa/en [13:26:49] <mmu_man> \o/ [13:28:38] <BBB> mru: awesome :) [13:31:57] <mmu_man> clang... reminds me the name of the bad ET in TMNT [13:32:08] <mmu_man> ah no that was Crang :D [13:33:02] * kshishkov should remind mmu_man what most people outside Japan think about haikus [13:33:34] <mmu_man> that it's a fine OS that rulz d4 w0rlD [13:34:08] <kshishkov> no, that's rather obscure short pieces nobody except its author cares about [13:35:26] <mru> so it's an apt name for that OS [13:38:09] <mmu_man> hmm that deserves a FATE run to slap you :p [13:46:23] <mru> how the fuck does one build clang as a cross-compiler? [13:56:32] <BBB> I guess I have to wait for kostylev to update his systems? I told him it's fixed [13:56:53] <mru> which ones? [13:57:04] <mru> ah, the bsds [14:00:28] <BBB> yeah [14:00:39] <BBB> so, most x86-like failures are now on icc [14:00:50] <BBB> is anyone on top of helping the icc devs figuring out their mistakes? [14:01:01] <BBB> I think I tried and it made no difference [14:01:06] <BBB> I need a contact in their dev team maybe [14:01:15] <mru> each release seems to fix some bugs and add new ones [14:01:22] <kshishkov> try somebody in America with cluebat [14:01:39] <BBB> mru: that's my impression also [14:01:57] <kshishkov> mru: it's called M$ release [14:12:34] * pross-au working on: s/get_bits/ffbits_r/g [14:17:41] * mru curses clang [14:31:27] * elenril summons some reviewers for avio_get_str [14:35:21] <elenril> any reason to use url_feof() instead of checking AVIOContext.eof_reached directly? [14:35:54] <mru> for that authentic java feeling (tm) [14:36:07] <elenril> i'm deprecating it then [14:36:20] <mru> I have no idea why it's there [14:36:32] <elenril> because it's always been there? [14:38:30] <kshishkov> it's shorter and reflects stdio [14:45:43] <elenril> avio > stdio =p [14:58:03] <Kovensky> why not rename eof_reached to eof [14:58:10] <Kovensky> solves the length issue :> [15:02:02] <kshishkov> well, I feel a bit uneasy accessing structure contents not created by me [15:08:07] <elenril> you should switch to java then =p [15:08:50] <Yuvi> mru: clang doesn't really support cross compiling except from darwin -> darwin [15:09:03] <mru> Yuvi: so I've noticed [15:09:12] * kshishkov translated elentril into JVM bytecode and runs garbage collection over him [15:09:31] <Yuvi> using the hidden options -ccc-host-triple and -ccc-gcc-name somewhat works for cross compiling, but isn't really supported [15:09:33] <mru> I see a lot of talk about how great a cross-compiler clang is and how they're going to improve cross-compilation [15:10:21] <kshishkov> mru: so you've been to FOSDEM [15:10:42] <mru> that talk has been going since at least 2009 [15:10:47] * elenril doesn't stab kshishkov [15:10:52] <mru> and nothing ever materialises [15:11:17] <kshishkov> mru: Apple toolchain for ARM is not completely nothing [15:11:18] <mru> Yuvi: great, even more hidden flags [15:11:24] <mru> I already found about 4 sets of hidden flags [15:11:41] <Yuvi> mru: well, in this case you really aren't supposed to be using them ;) [15:14:44] <Yuvi> I'm pretty sure they want something like -ccc-host-triple as the only option you have to specify for cross compile, but I dunno what they'll do about linking [16:02:17] <mru> Yuvi: I've found a magic incantation to make clang spit out arm code [16:02:31] <mru> but I can't make it do hard-float abi [16:02:46] <mru> none of the 8 or so different flags for that seem to make a difference [16:03:06] <kshishkov> mru: maybe hadfp is not glamorous enough to be supported [16:03:18] <mru> the help output claims it is [16:03:23] <mru> but the argument is ignored [16:03:35] <mru> sometimes with a warning, sometimes not [16:08:20] <Yuvi> mru: Does clang -v say anything about the float abi? [16:09:08] <mru> if I use flags like -mllvm -float-abi=hard they show up there [16:09:13] <mru> but then seem to go nowhere [16:10:51] <mru> -Xclang -msoft-float results in pure softfloat code [16:11:00] <mru> otherwise I get vfp code with softfloat abi [16:11:39] <mru> -mllvm -soft-float has no effect [16:11:58] <Yuvi> -Xclang? [16:12:14] <Yuvi> It's possible llvm doesn't implement it I forget [16:12:19] <mru> don't ask me what it is [16:12:33] <mru> -mllvm -help lists it as an option [16:12:51] <mru> and the source code suggests it does something with it during code gen [16:13:02] <mru> but the option is lost somewhere along the way [16:17:25] <mru> let's patch the default and see what happens [16:28:46] <lu_zero> mru: what are you doing? [16:28:58] <mru> messing with compilers [16:33:17] <mru> that worked [16:36:47] <spaam> mru: going to use clang for arm ? [16:37:21] <mru> more like going to watch it fail [16:40:21] <spaam> can it compile some stuff for arm? [16:45:11] <mru> it hates arm inline asm apparently [16:46:28] <mru> at least some instructions [16:46:56] <spaam> neon stuff? [16:47:04] <mru> some armv6 stuff [16:48:19] <mru> hey, it built [16:48:36] <spaam> :) [16:48:54] <mru> but running is another matter [17:25:11] <mru> found one bug [17:25:17] <mru> in clang that is [17:25:24] <mru> it creates bad relocations [17:26:08] <mru> enabling pic prevents that particular relocation type, so the code runs [17:27:07] <mru> now it even passes some tests [17:27:11] <mru> *some* [17:27:28] <lu_zero> nice [18:15:22] <_av500_> gm [18:15:56] <mru> morning [18:16:19] <_av500_> we are out of beer [18:16:35] <mru> sounds awful [18:17:01] <kshishkov> so you use Internet as cheap beer substitute? [18:17:03] <_av500_> well, red wine and lot of spirits are still there [18:17:16] <mru> it ain't the same [18:17:35] <_av500_> mru: too much beer makes me not board well [18:18:22] <_av500_> so i prefer the high % stuff atm [18:19:00] <kshishkov> what mountains you are at? [18:19:40] <_av500_> .at [18:20:06] <lu_zero> oh [18:20:11] <kshishkov> Harz? Voralrberg? [18:20:21] <lu_zero> red wine in .at? [18:20:40] * lu_zero knows some white wines [18:21:28] <_av500_> lu_zero: imported [18:21:38] <_av500_> kshishkov: zell am ziller [18:21:55] <lu_zero> ah [18:22:11] <lu_zero> going to detour a bit? [18:22:31] <_av500_> detour? [18:22:47] <mru> detour de france? [18:23:22] <kshishkov> _av500_: big deal, I have at least two Zells in < 2hrs of train [18:23:49] <lu_zero> _av500_: to taste some troll beer =P [18:24:06] <kshishkov> lu_zero: Austrian trolls are tasteless indeed [18:24:33] <lu_zero> kshishkov: =) [18:24:48] <mru> next clang bug: misaligning static data [18:25:01] <kshishkov> lu_zero: ask our local troll expert if you don't believe me [18:26:35] <lu_zero> mru: by the end of the day you'll be the top reporter... [18:27:08] <mru> they'll probably just blame it on my build methods [18:27:33] <kshishkov> mru: well, there are many compilers out there, some will listen [18:27:50] <lu_zero> kshishkov: s/many/2/ ? [18:28:13] <kshishkov> lu_zero: armcc, ticc too [18:28:39] <mru> when I downloaded that iar compiler I got an automatic "personal" email "from" some support person [18:28:59] <mru> offering help with my evaluation [18:29:14] * kshishkov thought it would be threats [18:29:22] <mru> I'm thinking of writing something snarky about the quality [18:29:43] <kshishkov> "usable only on enterprise code" [18:38:10] <lu_zero> ticc? [18:38:41] <Sean_McG> hey mru how the heck do you get gcc 4.0.4 on Gentoo PPC, it's like, not even marked unstable [18:39:33] <mru> Sean_McG: "sys-devel/gcc **" in package.keywords [18:39:39] <Sean_McG> ahhh [18:39:40] <Sean_McG> cheers [18:39:58] <lu_zero> ^^; [18:42:20] <mru> I even run gentoo on arches it doesn't know about [18:42:40] <Sean_McG> wow [18:42:49] <Sean_McG> that blackfin box? [18:42:55] <mru> takes a little coercion but it works [18:42:59] <mru> avr32 [18:43:01] <spaam> mr cool award goes do.. *drums* mru [18:43:14] <mru> the blackfin too [18:43:21] <mru> but there's barely anything on it [18:43:33] <mru> uclibc, busybox, and dropbear only [18:43:43] <mru> a 5-line init script [18:43:46] <Sean_McG> how much RAM on it? [18:48:41] <mru> 64MB [18:49:03] <mru> I'm doing some rather evil things with that though [18:49:17] <mru> to avoid fragmentation [18:49:21] <kshishkov> fax-g3 test for FATE? [18:49:47] <mru> that's trying to allocate more memory than is available [18:49:58] <spaam> mru: like what? [18:50:56] * Sean_McG has a chai latte [18:51:09] <Sean_McG> of the Tassimo variety, sadly [18:52:34] <mru> spaam: like setting aside a portion of the ram and with kernel patches and linker flags placing ffmpeg's bss+heap there [18:53:05] <Sean_McG> ah so a nonstandard config then [18:53:12] <mru> spares the kernel the effort of trying to allocate all those megabytes contiguously every time [18:53:20] <mru> which fails pretty quickly [18:53:55] <mru> it's still not stable though [18:54:04] <mru> I've no idea what's wrong with it [18:56:13] <Sean_McG> hey what fixed the clang build? [18:56:25] <mru> clang [18:56:29] <Sean_McG> ah [19:18:46] <BBB> mru: have you ever been able to look into writing emu_edge versions of the frext h264 conformance tests for fate? [19:19:40] <mru> I forgot all about that actually [19:37:04] <_av500_> j-b: http://www.flickr.com/photos/av500/5471488290/ [20:06:08] <BBB> mru: where is h264.mak included in soem other makefile? [20:06:19] <mru> grep? [20:06:43] <BBB> oh nm, toplevel Makefile [20:06:48] <BBB> I grepped all over tests/ and couldn't find it [20:08:37] <BBB> http://ffmpeg.pastebin.com/Srkjszfd why doesn't that work? [20:08:58] <BBB> tests/fate/vc1.mak:1: *** Recursive variable `FATE_VC1_AP_L0' references itself (eventually). Stop. [20:09:07] <BBB> h264.mak does that also, appears to work there [20:09:26] <mru> that's very repetitive [20:09:55] <BBB> sorry dude I suck at makefiles and this won't go upstream anyway [20:09:59] <BBB> :) [20:10:05] <BBB> (I don't own copyrights over the testsuite) [20:11:48] <mru> remove the \ on line 4 [20:14:22] <BBB> ah [20:14:37] <BBB> \o/ [20:14:41] <BBB> stupid me, sorry :) [20:14:52] <BBB> now I gotta generate all output and make sure it's ok [20:15:16] <BBB> I guess there's no quick way to do that? [20:15:16] <mru> does the reference decoder work? [20:15:46] <BBB> I can look at it, but I was really just planning to use this to validate our C agianst our ASM [20:16:02] <BBB> or, well, the other way around [20:16:05] <BBB> validate our ASM against our C [20:16:13] <mru> then you can simply run it once and copy the output files to the ref location [20:16:19] <BBB> ok [20:16:39] <mru> it will of course "fail" on that run [20:17:00] <BBB> of course [20:17:01] <BBB> that's ok [20:17:11] <BBB> let's try [21:11:21] <j-b> av500: cool [21:16:47] <BBB> kshishkov: ping [21:16:58] <BBB> [vc1 @ 0x102803200] Luma scaling is not supported, expect wrong picture [21:16:58] <BBB> [vc1 @ 0x102803200] Chroma scaling is not supported, expect wrong picture [21:17:05] <BBB> kshishkov: what is that? the picture actually looks good [21:17:37] <mru> good can still be wrong [21:17:47] <mru> if you order pizza and get icecream, that's wrong, right? [21:17:53] <Sean_McG> heheheheh [21:17:57] <Sean_McG> nice analogy there [21:20:17] <BBB> mru: well, that's what kshishkov is for [21:20:27] <BBB> this is SA00048.vc1 btw [21:20:28] <kurosu> delivering pizzas? [21:20:45] <BBB> [vc1 @ 0x101828c00] Sliced decoding is not implemented (yet) [21:20:45] <BBB> [vc1 @ 0x101828c00] warning: first frame is no keyframe [21:20:50] <BBB> SA00049.vc1 [21:20:53] <BBB> kshishkov: ^^ [21:21:30] <BBB> SA00054.vc1 gives a combination of the two above [21:22:29] <Kovensky> mru: arguably, the result is improved in that case :> [21:23:05] <mru> no good pizza in brazil? [21:23:14] <Kovensky> there is [21:23:20] <Kovensky> but arguably ice cream is better than pizza! [21:23:28] * Kovensky has a sweet tooth :3 [21:23:42] <mru> that's worse than comparing apples and oranges [21:23:54] * mru sends Kovensky some garlic icecream [21:24:04] <Kovensky> nuu D: [21:24:18] <Sean_McG> actually that would be interesting to try sometime [21:25:48] <elenril> obviously apples > oranges [21:30:35] <lu_zero> but Orange > apple [21:30:45] <lu_zero> (or not?) [21:30:57] <mru> apples > oranges [21:31:00] <mru> oranges > pears [21:31:04] <mru> pears > apples [21:31:50] <lu_zero> might make sense [21:39:46] <saintd3v> * mru sends Kovensky some garlic icecream <-- we made guinness ice cream once [21:40:57] <BBB> I had guiness icecream once [21:40:59] <BBB> it's delicious [21:41:14] <BBB> how come vc1 duplicates so many frames even when using -vsync 0? [21:41:19] <BBB> are there other sync options? [21:41:27] <Sean_McG> does it get you wasted as much as drinking a Guinness? [21:41:44] <BBB> Sean_McG: not really [21:42:40] <saintd3v> BBB: it wasn't as bad as i expected, but i don't drink guinness or beer for that matter. [21:42:57] <Sean_McG> it's the beer that eats like a meal [21:43:49] <mru> guinness is good for you [21:44:02] <thresh> +1 [21:44:12] <thresh> morning [21:44:23] <Sean_McG> happy $TIMEZONE [21:44:32] * lu_zero had menabrea ice cream more than once [21:45:46] <Sean_McG> myself I don't have a sweet tooth really [22:28:17] <BBB> kshishkov: ping a ping [22:34:12] <j0sh> merbanan: do you have neon for yuv->rgb conversion? [22:34:58] <kierank> [22:28] BBB: kshishkov: ping a ping --> ping a ping a roses, a pocket full of posies... [23:04:29] <saintd3v> mru: good for me, like pre-dinner mayo? [23:10:31] <MrNaz> google returns quite a few hits for "libavfilter yadif" am i to understand that yadif has been implemented in libavfilter? if so, that would totally rock my underpantaloons [23:12:34] <drv> ffmpeg -filters | grep yadif [23:12:59] <MrNaz> drv i just saw it [23:13:05] <drv> :) [23:13:17] <MrNaz> my underpantaloons are currently rocking [23:58:56] <merbanan> j0sh: not that I can share :/

1 0

IRC log for 2011-02-25
by irc＠mansr.com 26 Feb '11

26 Feb '11

[00:16:58] <kierank> just to double check, the width in av_image_fill_linesizes includes the edges, right? [00:18:20] <BBB> caller includes edges [00:18:47] <kierank> BBB: yeah that's what i meant [00:20:09] <in3xes> svn.ffmpeg.org/soc/ is up? [01:32:59] <BBB> astrange: looking at it more, I think the bigger issue is that p->state is used for two things - to indicate that buffers are needed/available, and to indicate that the thread is waiting for input [01:33:14] <BBB> astrange: the two conflict and overwrite each other, I think they should either be separate or they should be flags [01:33:41] <BBB> separate makes sense since you can then indicate that multiple threads need buffers, which would require it to be a counter (i.e. integer) instead of a flag anyway [01:35:50] <astrange> p-> is per-thread, so the state machine is per-thread too [01:36:06] <astrange> i don't think multiple threads should be stomping on each others' state [01:37:11] <BBB> so I'm supposed to scan neighbouring thread's p-> to see if they need a buffer? [01:38:33] <astrange> intra codecs (the problem here) only call get_buffer once [01:38:44] <astrange> so submit_frame just waits for it after starting the thread [01:39:07] <astrange> that always satisfies the request before returning, so there's never any outstanding [01:39:32] <BBB> for -threads 2, I get at least 3 calls to get_buffer [01:39:39] <mru> what, they insist on using the same buffer for every frame? [01:39:47] <BBB> not surprisingly, the third one blocks [01:39:50] <astrange> once per decode() call [01:39:52] <astrange> not once ever [01:39:55] <mru> oh [01:40:31] <dalias> lovely.. [01:41:34] <astrange> or rather, that's the idea, but obviously it breaks somewhere [01:41:43] <astrange> i'm getting called away again :/ [01:42:04] <BBB> window, latch, open, throw out phone [01:42:05] <BBB> done [01:42:32] <gnafu> s/phone/baby? [01:42:38] <gnafu> (Or was that too far?) [01:42:46] <gnafu> (If so, I apologize.) [01:42:51] <gnafu> (If not, I do not.) [01:43:21] <gnafu> (Define far, I guess.) [01:43:41] <mru> don't throw it too far [01:43:49] <BBB> baby is cute and undisturbing [01:43:54] <BBB> apparently, astrange's phone is not [01:44:11] <gnafu> Most phones are definitely not cute. [01:44:28] <gnafu> What some people do with their phones is most disturbing. [01:44:41] <mru> gnafu clearly has the wrong background image on his phone [01:45:17] * gnafu has a phone that is so old that his background image is actually just a random doodle he created with the built-in drawing application. [01:46:33] <gnafu> But soon, I'll have an Android phone, and perhaps I will locate a suitably cute background image. [01:46:42] <gnafu> But preferably not disturbing. [01:48:15] * BBB has a babypicture as background picture [01:49:45] <gnafu> I suppose I should have a picture from my wedding or something until I have a baby. [01:50:01] <gnafu> I think I look cute in my purple bowtie. [01:51:39] <gnafu> But perhaps a bit disturbing if I have a picture of /just/ me for a background. [01:52:26] <mru> that might seem a little narcissistic [02:13:46] <dalias> haha [02:30:38] <BBB> astrange: if submit_packet() is supposed to ensure that a buffer is provided to each thread, then it's not doing that for any thread. problem is that (even though I think your patch 1/2 is supposed to prevent that), ff_thread_finish_setup() sets p->state to STATE_FINISHED_SETUP, causing the thread to pass the get_buffer stage. or in other words, get_buffer is never actually called, ever [02:30:59] <BBB> astrange: you probably know when ff_thread_finish_setup is supposed to be called and when not, so please have a look there [02:42:14] <BBB> astrange: in fact, if I remove the ! (so && avctx->thread_safe_callbacks instead of && !avctx->thread_safe_callbacks) in your first hunk of patch 1/2, it works correctly [02:42:46] <BBB> astrange: looks like a typo to me anyway, I don't see why you'd want to run ff_thread_finish_setup() there if the get_buffer() callback is _not_ threadsafe [02:44:31] <BBB> astrange: that said, my wife wants me to sleep, so please submit a new patch and let's keep this stuff rolling :) [02:48:29] <in3xes> Where is the SoC repo which has JPEG2000 ? [02:48:54] <in3xes> pengvado: Any idea? [02:53:20] <gnafu> Would it be the one mentioned here?: [02:53:23] <gnafu> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-February/107863.html [02:54:16] <kierank> lol jpeg2000 [02:56:21] <gnafu> kierank: I've been getting that impression lately. [02:57:12] <kierank> we really need an xjpeg2000 [02:57:17] <kierank> all the encoders are awful [02:57:47] <mru> why do we need jpeg2k at all? [02:57:52] <Dark_Shikari> what mru said [02:58:10] <kierank> http://code.google.com/p/opencinematools/ [02:58:17] <kierank> that's why [03:03:19] <in3xes> How difficult is writing a demuxer? I mean, considering SoC qualification task. [03:04:13] <Dark_Shikari> depends on how complicated the format is [03:04:39] <in3xes> Okay [03:05:28] <kierank> in3xes: there's a guide on the wiki [03:05:56] <in3xes> kierank: I am already following that [03:06:57] <in3xes> I just started with VIVO. I'll be lucky if I am able to finished by weekend. [03:07:13] <in3xes> finish* [03:08:06] <in3xes> kierank: Thanks for pointing, anyway :) [06:01:49] * elenril pokes BBB [07:48:55] <Tjoppen> low pressure on the ml. only 20 new mail in a day [07:52:03] <kierank> someone didn't learn what top-posting is... [07:54:03] <spaam> kierank: tell him about it [07:54:18] <Tjoppen> yeah, I saw that. hilarious [07:54:21] <kierank> I think it's a she spaam [07:56:00] <spaam> kierank: its tru.. [07:56:04] <spaam> true [07:56:11] <spaam> i found her on facebook.. [07:57:13] <kierank> .... [07:57:28] <kierank> people like you are why i don't do social networking [07:59:03] <spaam> come on.. you can change the privacy settings so only your friends can see your profile.. [08:00:15] <spaam> i changed my things to that after i found my mother on facebook... [08:00:29] <Dark_Shikari> quite easily [08:00:33] <Dark_Shikari> click "delete account" [08:00:33] <Dark_Shikari> bam [08:00:36] <Dark_Shikari> your profile is now private. [08:01:08] <kierank> AND NOTHING OF VALUE WAS LOST [08:01:13] <Dark_Shikari> ^ [08:01:32] <kierank> except maybe the x264 facebook group [08:01:39] <Dark_Shikari> >facebook group [08:01:39] <spaam> awww [08:01:40] <Dark_Shikari> >value [08:02:01] <spaam> facebook is nice.. [08:02:07] <Dark_Shikari> nice... [08:02:10] <Dark_Shikari> FOR ME TO POOP ON. [08:02:25] <peloverde> didn't you used to work for facebook? [08:02:39] <spaam> Dark_Shikari: you know.. even KotH have facebook ;) [08:03:06] <Dark_Shikari> peloverde: yes [08:04:00] <cartman> moin [08:04:02] <spaam> cartman: BBB did miss you last night.. [08:05:55] <cartman> spaam: did he found the bug? [08:06:30] <spaam> he was asking you "any progress". [08:06:46] <cartman> spaam: you should have handed him a void* [08:13:29] <TheFluff> I have facebook because it's a convenient way to get invited to parties [08:13:39] <TheFluff> if you set it to the most antisocial settings possible it's not too bad [08:14:18] <Dark_Shikari> Er, why would I want to get invited to parties? [08:14:30] <TheFluff> becau- [08:14:33] <TheFluff> oh wait, right, nerd. [08:14:35] <TheFluff> never mind. [08:14:46] <Dark_Shikari> Parties are just a place for a bunch of stupid frat boys to get drunk and do stupid things. [08:14:52] <Dark_Shikari> While listening to very bad music. [08:15:10] <peloverde> i think in the movie zuck said that they are fun and lead to a better life [08:15:23] <Dark_Shikari> He's obviously never been to a party [08:15:25] <TheFluff> either you'll growp to be a unix beard or you'll understand when you get older, young man [08:15:26] <saintdev> you actually watched that? [08:15:34] <TheFluff> grow up* [08:15:50] * thresh likes parties [08:15:53] <Dark_Shikari> sorry, I don't subscribe to the "grown-ups aren't allowed to have fun" rule [08:15:57] <spaam> Dark_Shikari: come on.. you can have a party with your friends and play with your things.. [08:16:03] <Dark_Shikari> LAN parties aren't really parties. [08:16:36] <kshishkov> thresh: вечеринки, светские рауты, корпоративы или пьянки? [08:16:37] <peloverde> it was an awesome movie [08:16:38] <TheFluff> have you ever been to breakpoint or any of the other big european hacker cons? [08:16:43] <Dark_Shikari> Those aren't parties, those are cons [08:16:55] <thresh> kshishkov: вечеринки, плавно переходящие в пьянки [08:17:03] <Dark_Shikari> a party has ~10-200 people, usually at a college dorm, drinking while listening to loud rap music and bad techno. [08:17:06] <TheFluff> call them whatever you want but there's a lot of very loud music and alcohol at them [08:17:16] <TheFluff> that's a pretty narrow definition of a party [08:17:20] <saintdev> <Dark_Shikari> Parties are just a place for a bunch of stupid frat boys to get drunk and do stupid things. <-- Those aren't parties, those are just frat houses [08:17:24] <Dark_Shikari> that seems to be about 90% of the parties out there [08:17:27] <thresh> hmm, that's american definition of parties [08:17:35] <Dark_Shikari> Yes, ok, american parties are crap. [08:17:42] <Dark_Shikari> Can't judge european ones. [08:17:50] <Dark_Shikari> (We don't seem to have those awesome hacker cons here for some reason) [08:17:50] <kshishkov> try Russian [08:17:53] <TheFluff> college dorm parties suck here too [08:18:03] <TheFluff> no surprise there [08:18:11] <kshishkov> Dark_Shikari: because everybody knows what happens to hackers coming to USA [08:18:15] <Dark_Shikari> `-` true [08:18:22] <TheFluff> if you've only been to those it's not that strange you hate parties [08:18:27] <TheFluff> europe parties harder than the US [08:18:43] <TheFluff> lasers <3 [08:19:04] <TheFluff> anyway go to breakpoint sometime [08:19:32] <TheFluff> or, well, breakpoint doesn't really exist anymore but there are successors [08:19:39] <TheFluff> lots of cool people, awesome demos, awesome music, etc etc [08:19:57] <cartman> Does code.google.com works for anyone? Gives 500 here. [08:20:08] <TheFluff> dreamhack in sweden is p cool too but there are too many gamers and not enough hackers [08:20:11] <andoma> cartman: works fine for me [08:20:14] <TheFluff> also you can't drink at dreamhack [08:20:19] <cartman> andoma: thanks :/ [08:20:25] <Dark_Shikari> TheFluff: sounds like a minus and a plus [08:20:33] <kshishkov> TheFluff: that's what I like in Sweden [08:20:35] <Dark_Shikari> probably the minus is worse though. [08:20:49] <votz> TheFluff: they didnt let people drink at CPL events either [08:21:10] <votz> everyone just went to the hotel bars just outside, though :) [08:22:03] <TheFluff> at last breakpoint you could just go to the shop inside and ask for "apple juice" and you'd get a beer [08:22:12] <TheFluff> iirc [08:22:24] <votz> some 'upgraded juice' [08:22:31] <TheFluff> :V [08:22:35] * thresh asks for a beer and gets beer usually [08:24:01] <andoma> mm beer [08:24:06] <kshishkov> thresh: well, _you_ call it beer [08:24:15] <Tjoppen> TheFluff: unfortunately dreamhack treats the sceners like shit [08:24:19] <TheFluff> yeah [08:24:21] <TheFluff> I know [08:24:23] <kshishkov> thresh: I'm not sure that even Danish would drink that [08:24:31] <thresh> kshishkov: I don't drink Russian beer, if you mean that :) [08:24:36] <TheFluff> they've been working on making creative better these last few years though [08:24:37] <thresh> well Russian "beer" [08:24:41] <TheFluff> or at least trying [08:24:45] <Tjoppen> "here, you can sit right where the people walk, right next to the nacho cheese guy" [08:24:51] <andoma> hahaha [08:25:12] <andoma> are there any decent demo partys in the nordics anymore? [08:25:20] <TheFluff> assembly in finland [08:25:23] <andoma> ah [08:25:27] <kshishkov> thresh: well, have tried comparing the same beer brand bought in Russia and somewhere in Andorra for example? [08:25:36] <TheFluff> is said to be good, I've never been there though [08:25:47] <thresh> kshishkov: yeah, imported bottles == same stuff [08:25:49] <andoma> i only went to The Part and The Gathering back in the days (early 90ties) [08:25:55] <andoma> The Party... even [08:26:06] <TheFluff> Tjoppen: I was at the creative section at DH, uh, last DH winter? [08:26:07] <TheFluff> I think [08:26:10] <Tjoppen> yes, assembly was good. going there again this summer probably [08:26:14] <TheFluff> I got third in the useless utility competition [08:26:28] <Tjoppen> we were there.. hm [08:26:42] <Tjoppen> we won the useless utility when we were there [08:26:55] <TheFluff> were you the guys with the windows achievements? [08:26:59] <Tjoppen> yes :) [08:27:01] <TheFluff> :D [08:27:07] <TheFluff> mine was the cuckoo clock [08:27:15] <TheFluff> the video was so shitty you couldn't see what it was doing though [08:27:16] <Tjoppen> also placed third with our partyprod [08:28:23] <kshishkov> TheFluff: http://www.oldskool.org/pc/8088_Corruption [08:28:29] <Tjoppen> for assembly I'm trying to cobble together bits and pieces for an atari 2600 prod, and an entry in the game competition on the same platform :) [08:28:34] <TheFluff> (it announced whole hours by ejecting the cd sled, going "cuckoo" and retracting it again) [08:29:24] <TheFluff> Tjoppen: you don't happen to know a guy known as kalaspuff, do you? [08:29:31] <Tjoppen> nope [08:29:32] <TheFluff> (his last name's aaro, if it helps) [08:29:35] <TheFluff> mmk [08:30:01] <TheFluff> he seems to know almost everyone, figured he might know you too [08:30:05] <TheFluff> (we work together) [08:30:51] <Tjoppen> we haven't been doing demos for long. well, on and off a bit over the years. probably should at least get an account on pouet [08:31:28] <TheFluff> I don't really do demos at all [08:31:33] <TheFluff> he does, though [08:31:42] <TheFluff> I just like watching :V [08:31:46] <Tjoppen> hangaround? :) [08:32:01] <Tjoppen> brb, meeting [08:32:33] <TheFluff> yep [08:44:39] <pross-au> kshishkov: https://github.com/clone2727/scummvm/compare/ra-smush [08:46:14] <kshishkov> pross-au: yep, seen it [08:46:26] <kshishkov> pross-au: I even lol'd at http://www.xvid.org/News.64.0.html?&cHash=d69f350538&tx_ttnews[backPid]=64&… [08:47:45] <pJok> god morgon [08:47:56] <kshishkov> goda morgnar, pJok [08:49:08] <pross-au> kshishkov: Art is never finished, only abandoned [08:49:47] <saintdev> pross-au: unless you're george lucas [08:50:10] <kshishkov> saintdev: well, jar-jar was a masterpiece [08:51:46] <saintdev> well things no longer sound horrible, yipee [08:52:33] <kshishkov> even with ffaacend? [08:52:38] <kshishkov> *ffaacenc [08:53:06] <pJok> ffaacenc got fixed? o_O [08:53:26] <saintdev> pJok: of course not [08:53:34] <saintdev> just not as horrible as it sounded last night [08:53:38] <pJok> hehe [08:53:46] <pJok> well, thare are various degrees of fixed [08:54:22] <saintdev> ok, then fixed my stupid mistakes. [08:54:32] <saintdev> or wait, kshishkov said i could blame him. [08:54:48] <saintdev> s/my/kshishkov's/ [08:55:09] <kshishkov> exactly [08:57:41] <pJok> there* [08:57:46] <pJok> time to do some hp [08:57:48] <pJok> php* [09:09:59] <saintdev> hmm, my RAM seems to have asploded :/ [09:10:45] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/MadeOfExplodium ? [09:11:07] <saintdev> quite possibly [10:03:14] <cartman> BBB: I am bisecting atm. Should be over today. [11:58:21] <cartman> BBB: bisect finished, bug updated [12:00:03] <kshishkov> i.e. "this patch will make clangs demonstrate this bug more reliably and harder to fix"? [12:00:31] <kshishkov> cartman: also judging from last av500's photos he's on vacation [12:00:33] <cartman> well bisect shows that so called "TBAA" optimization pass broke code [12:00:36] <cartman> kshishkov: yeah :D [12:03:35] <Dark_Shikari> TBAA? [12:03:56] <kshishkov> "take bytes and alter" [12:04:21] <cartman> Type Based Alias Analysis [12:14:55] <Dark_Shikari> ALIASING! [12:14:56] <Dark_Shikari> I knew it. [12:15:08] <cartman> you better tell us next time... [12:15:36] <cartman> 1 hour 55 minutes of computing power lost while bisecting :P [12:17:05] <iive> cartman: i told you. but nobody ever listens to me. [12:17:47] <cartman> iive: I somehow missed it then, sorry! :) [12:22:10] <Dark_Shikari> I was told that Clang didn't do aliasing optimizations yet [12:22:31] <cartman> Dark_Shikari: yeah its newly enabled, in December 2010 [12:22:40] <cartman> and looks like still buggy [12:23:34] <kshishkov> yep, old-fashioned GCC bugs are better [12:23:53] <cartman> gcc 4.6 has the lowest regression count ever, its good news :> [12:24:08] <cartman> >> Still 119 regressions in 4.3, 116 in 4.4, 122 in 4.5 and 93 in 4.6 [12:24:54] <iive> cartman: give it some time ;) [12:28:14] <mru> cartman: of course the regressions go down [12:28:27] <mru> with each version, there are less things left working [12:28:42] <mru> break the same percentage each time, and the total count will go down [12:29:09] <cartman> mru: lol :) [12:35:53] <BBB> elenril: sprry, forgot, hopefully today, past 3 days were busy at work [12:36:41] <kshishkov> BBB: so that's why nobody committed bink-b audio patches? [12:37:24] <BBB> am I nobody? [12:37:42] <cartman> at least, nobody is perfect [12:37:55] * BBB awaits astrange [12:38:03] <BBB> btw thanks cartman :) [12:38:20] <cartman> ah np, lets see what happens now [12:40:20] <kshishkov> BBB: you belong there too, it seems - http://patches.ffmpeg.org/patch/1218/ for instance [12:41:20] <BBB> ok ok I get the hint [12:41:30] <BBB> were they all OK? [12:41:53] <kshishkov> yep [12:43:17] <BBB> kshishkov: ok will look at it at work [13:56:27] <siretart> kshishkov: sorry, I didn't get to your patches yesterday, I'm basically drowning in day-job work :-( - and the weekend doesn't look much better [13:57:04] <siretart> kshishkov: moreover, my emacs crashed here, so I lost your link(s) from yesteday :-( [14:02:02] <Tjoppen> why doesn't lavc adjust qscale by default for cbr mpeg2video output? [14:02:19] <Tjoppen> I was trying to simplify http://www.itbroadcastanddigitalcinema.com/ffmpeg_howto.html#Encoding_D10 [14:02:35] <Tjoppen> especially having to set qmax=3 to not get crap output seems.. arbitrary [14:03:56] <kshishkov> siretart: okay :( [14:04:38] <Dark_Shikari> setting a qmax like that will cause vbv underflow [14:04:52] <Dark_Shikari> you might as well not use maxrate/bufsize if you're going to do that [14:05:30] <Dark_Shikari> your problem is likely that lavc's vbv ratecontrol is a pile of ass and terrible [14:05:41] <Dark_Shikari> I wouldn't recommend using lavc mpeg2 for anything serious that requires vbv [14:06:12] <mru> how hard would it be to make x264 encode mpeg2? [14:06:13] <Tjoppen> I see [14:06:16] <Dark_Shikari> mru: it's being done [14:06:22] <Dark_Shikari> x262 already does I and P-frames [14:06:23] <Tjoppen> x262= [14:06:29] <Tjoppen> :) [14:06:29] <mru> nice [14:06:32] <mru> didn't know that [14:06:39] <mru> who's doing that? [14:06:44] <Dark_Shikari> ifb and kierank [14:06:47] <Dark_Shikari> for the open broadcast encoder [14:06:57] <Dark_Shikari> it's going to be done faster than xvp8 which will make me laugh. [14:07:16] <elenril> ETA until we remove all encoders, rename lavc into lavd and x264 into lave [14:07:17] <mru> mpeg2 is a relatively simple coded [14:08:47] <Dark_Shikari> the interlaced mode will still be messy to do though [14:15:09] <Tjoppen> feels like getting the current encoder not to act completely retarded "shouldn't be that hard" [14:16:11] <Tjoppen> I did have a look at the mpeg internals to try and figure out what it does, but.. my eyes [14:16:21] <superdump> :) [14:16:55] * mru experiments with the iar compiler [14:17:24] <mru> only one ICE building ffmpeg [14:17:27] <mru> I'm impressed [14:17:30] <kshishkov> which arch? [14:17:35] <mru> arm [14:18:07] <superdump> Dark_Shikari: is x262 going to get merged into the x264 tree when it's done? [14:24:15] <pJok> Dark_Shikari, will it actually get an mpeg audio layer 2 encoder with predictive output maximum peak? [14:46:48] <Kovensky> 11:07.16 elenril: ETA until we remove all encoders, rename lavc into lavd and x264 into lave <-- "lave" is the imperative form of "to wash" in portuguese [14:47:34] <kshishkov> Kovensky: we have some time till xbink [14:47:51] <kshishkov> Kovensky: and that's definitely not the worst scenario [14:48:00] <Kovensky> lul [14:53:54] <mru> crappy compiler can't align struct members [14:59:39] <kshishkov> s/crappy/professional(or enterprise)/ [15:00:09] <mru> quite a few can do it [15:00:37] <mru> the amusing ones are the ones that can align data objects but not struct members [15:00:40] <mru> iar is one of those [15:01:37] <kshishkov> aligning is always funny [15:01:49] <kshishkov> especially when it works selctively [15:02:07] * cartman notes that iar is pricey too [15:02:07] <kshishkov> i.e. not on stack or not in structures [15:02:16] <mru> the TI compilers are a bit obscure [15:02:28] <kshishkov> GCC too [15:02:32] <mru> they can do all kinds of alignment but the syntax differs wildly [15:03:54] <Kovensky> binutils can't align rodata [15:03:57] <Kovensky> windows binutils that is [15:04:58] * mru builds w/o asm and watches fate errors instead [15:05:14] <cartman> you are lucky that binutils run on Windows [15:05:23] <mru> I'm not on windows [15:05:32] <mru> iar compiler runs fine under wine [15:05:34] <cartman> mru: that was for Kovensky [15:05:53] <cartman> iar under wine eeeeeeeeek [15:06:05] <mru> what's wrong with that? [15:06:12] <cartman> mru: I never trust wine :P [15:06:15] <bilboed-pi> works perfectly fine [15:06:16] <KotH> mru: apropos iar, do you have experience with iar for arm? [15:06:26] <mru> KotH: getting some now [15:06:30] <mru> and it ain't good [15:06:33] <cartman> just use a VM [15:06:35] <KotH> :-) [15:07:05] <KotH> mru: iar got dropped here because it miscompiled stuff a couple of years ago... and support didnt respond within a month.. not even an ack [15:07:20] <cartman> not nice [15:07:30] <KotH> mru: now we've customer who wants to have some stuff done with iar [15:07:39] <mru> change customer [15:07:45] <KotH> lol [15:07:49] <kshishkov> do the same to him as iar [15:07:55] <cartman> pluggable customers ftw [15:08:01] <mru> works for me [15:08:29] <cartman> mru: whats the preffered working arm compiler? Arm's own? [15:08:48] <mru> depends [15:09:00] <mru> for random open source stuff I'd recommend gcc [15:09:31] <cartman> for $$$serious work? [15:09:41] <mru> depends [15:09:53] <mru> gcc is usually ok [15:10:08] <cartman> codesourcery or self built? [15:10:09] <mru> armcc gives more control over some low-level aspects [15:10:23] <mru> for linux apps I'd start with gcc [15:10:30] <mru> less hassle [15:10:34] <kshishkov> cartman: there's also Linaro toolchain these days [15:10:43] <mru> vanilla or linaro would be my choice [15:10:45] <cartman> kshishkov: yeah I wonder how it performs [15:10:57] <kshishkov> cartman: what do you expect from GCC? [15:11:02] * mru should do another compiler benchmark run [15:11:11] <cartman> kshishkov: miscompilations [15:11:18] <mru> cartman: check fate [15:11:32] <spaam> cartman: did you fix the bugs yet? [15:11:33] <cartman> mru: my fate is not green, stop making me sad [15:11:43] <cartman> spaam: found the faulty commit [15:11:48] <spaam> Nice [15:11:54] <spaam> where is that report? [15:11:57] <KotH> cartman: we're working with gcc here and have not had any serious problems yet [15:12:00] <mru> fate/arm is has errors with latest vanilla gcc and latest armcc [15:12:04] <mru> linaro gcc passes [15:12:07] <cartman> KotH: cool [15:12:21] <KotH> cartman: sometimes it's a bit akward, but that goes with the field of embedded systems [15:12:22] <cartman> spaam: http://llvm.org/bugs/show_bug.cgi?id=9307 [15:12:39] <cartman> KotH: Hopefully one day I'll get my hands on some <Foo>Board [15:12:54] <KotH> cartman: we build those <foo>boards ourself :) [15:13:01] <cartman> KotH: awesome :( [15:13:02] <cartman> :) [15:13:12] <KotH> cartman: having the right job in the right company helps ;) [15:13:35] <cartman> KotH: yeah well my embedded job is over, had fun :P Maybe in the future [15:13:45] <KotH> but having to review code i've written a year ago sucks .... [15:13:55] <KotH> cartman: you didnt had an embedded job [15:13:57] <mru> that's why you switch jobs often [15:14:06] <KotH> cartman: you had a job working with portable PCs [15:14:07] <mru> make it somebody else's problem [15:14:09] <cartman> KotH: I had access to some tablets :) [15:14:14] <cartman> mru: lol [15:14:40] <cartman> KotH: overriding malloc on WinCE was fun :-P [15:14:47] <mru> unfortunately it works both ways [15:14:53] <KotH> cartman: embedded is when you dont have a full fledged OS with networking and everything in your toaster, but run your code on bare metal [15:15:06] <cartman> KotH: I had an offer for a job like that [15:15:11] <KotH> mru: somebody made it my problem ^^' [15:15:21] <mru> everyone is someone's someone else [15:15:27] * cartman has a friend whose company produces 2-3$ chips [15:15:51] <KotH> cartman: you should do it like me: tell your friend whos company is looking for an engineer that youre looking for a new job :)$ [15:16:03] <cartman> KotH: but its in Turkey [15:16:06] <cartman> I wanted EU [15:16:19] * KotH holds cartman to the light [15:16:27] * KotH thinks that something is missing [15:16:28] * cartman sees Ataturk [15:16:30] <cartman> :P [15:16:42] <cartman> I have a masterpiece at $HOME [15:16:43] <kshishkov> cartman: well, .ch is not that bad [15:16:57] <cartman> Mustafa Kemal Ataturk watching Sabiha Gökçen's first flight [15:17:00] <cartman> now beat that kshishkov [15:17:02] <cartman> KotH* [15:17:02] <cartman> :D [15:17:16] <KotH> cartman: i know where you live! ;) [15:17:20] <cartman> lol [15:17:28] <kshishkov> KotH: he's moving! [15:17:36] <cartman> kshishkov: sssssssssh! [15:17:41] <kshishkov> KotH: so it will be easier for you to reach him! [15:17:49] * cartman welcomes KotH [15:18:03] <kshishkov> KotH: I think there should be rather direct train Zürich-Nürnberg [15:18:03] <mru> something in the mpeg2/4 decoders miscompiles with iar... [15:19:03] <cartman> kshishkov: good for me! [15:36:56] <cartman> trains are too expensive though [15:37:03] * cartman would like to see his sister in Amsterdam [15:37:33] <thresh> it's not easy to get out of amsterdam in a sane state of mind [15:37:44] <cartman> thresh: I do manage fine :) [15:39:47] <cartman> have a nice weekend! [15:44:26] <mru> wow, ffvp8 is 63% faster than libvpx on one clip [15:44:33] <mru> on cortex-a8 [15:45:44] <kshishkov> that means other pathways are not that optimised [15:46:10] <mru> I don't know what's magical about that clip [15:46:17] <mru> maybe profiling will tell [16:18:12] <BBB> mru: 63% is good right? [16:18:20] <mru> very [16:18:25] <BBB> or were you expecting at least 500% faster per clip? [16:18:26] <BBB> :) [16:18:31] <mru> no [16:18:58] <BBB> thank dark_shikari, he did really crazy stuff [16:19:06] <mru> btw, that number means (ffvp8 fps)/(libvpx fps) = 1.63 [16:19:15] <BBB> I know :) [16:19:42] <BBB> also, I'm thinking about adding edge writing to the buffer after frame decoding completes, so we can do away with MC edge emulation [16:19:52] <BBB> dark_shikari has been pestering me to do that since, like, well, forever [16:21:17] <BBB> might make it another 10% faster [16:21:22] <BBB> er, not 10% [16:21:24] <BBB> 0.1% [16:21:25] <BBB> sorry [16:24:25] <lu_zero> still something =P [16:54:06] <BBB> lu_zero: 0.1% is pretty significant [16:54:16] <BBB> I'd say a couple of 0.1% improvements can easily make a noticeable difference [16:54:38] <BBB> optimized codecs are difficult to optimize by 10% "just like that" [17:11:03] <lu_zero> mans mind if I add a ${SDL_CONFIG:-${cross-prefix}sdl-config}? [17:11:29] <mru> if that's how it's meant to be.. [17:13:11] <lu_zero> right now I'm installing sdl to /usr/CHOST/usr/ [17:13:24] <lu_zero> and the sdl-config resides in /usr/CHOST/usr/bin/ [17:13:28] <lu_zero> w/out prefixes [17:14:00] <mru> of course it'll still fail miserably with a sysroot setup [17:14:31] <lu_zero> right now I workarounded this way [17:15:34] <lu_zero> I'd propose to check for sdl-config OR use pkg-config [17:16:00] <mru> pkgconfig is perhaps slightly more predictable [17:16:59] <lu_zero> yup [17:17:13] <lu_zero> I'll check what's working better [17:19:38] <Tjoppen> http://www.youtube.com/watch?v=aYBkDxao3wg Regular Ordinary Swedish Meal Time - Superior Smörgåscake [17:36:18] <shahriman> i am trying to compile ffmpeg in windows 7 (MSYS) [17:36:23] <shahriman> i got this error [17:36:24] <lu_zero> shahriman: hi [17:36:24] <shahriman> libavformat/avidec.c: In function 'avi_metadata_creation_time': [17:36:25] <shahriman> libavformat/avidec.c:288:13: error: implicit declaration of function 'strcasecmp [17:36:25] <shahriman> ' [17:36:36] <lu_zero> your string.h is bogus [17:36:43] <shahriman> lu_zero:hi [17:36:59] <lu_zero> edit it to not ifdef or ifndef on __STRICT_ANSI__ [17:37:11] <lu_zero> (yes apparently errors are infective) [17:37:46] <shahriman> thanks lu_zero, trying it right now [17:38:05] <lu_zero> shahriman: ping me on #ffmpeg if you need more help [17:40:08] <shahriman> lu_zero: where exactly is string.h.. i can't find it [17:50:31] <BBB> hm [17:50:34] <Kovensky> 14:36.36 lu_zero: your string.h is bogus <-- strcasecmp is defined in strings.h on mingw [17:50:36] <BBB> apple guys think it's a bug in our code [17:50:39] <BBB> I wonder how to debug that [17:50:41] <Kovensky> it's wrong, but that's where it's defined [17:55:51] <mru> hmm, iar can't multiply [17:58:20] <BBB> also, did we have a valgrind fate box? [17:58:25] <mru> yes [17:58:37] <mru> x86 and ppc [17:58:39] <mru> both green [17:59:14] <BBB> awesome [17:59:26] * BBB tries to find people to do a cygwin and minw64 x86-64 fate box [18:01:16] * elenril yawns [18:01:56] <thresh> I think we have some buildbot with mingw64 on videolan servers [18:01:58] <BBB> elenril: interested? [18:02:12] <BBB> thresh: that'd be awesome also [18:02:13] <thresh> I'm not in a mood of configuring that python abomination though [18:02:17] <BBB> thresh: but it needs to run fate [18:02:25] <BBB> elenril: yes your patch I know, going through it [18:02:29] <BBB> (after lunch) [18:02:40] <elenril> where are all the reviewers who aren't you [18:04:45] <elenril> oh well, i guess i could do some work instead [18:06:27] <elenril> btw did i mention that QFT is the best thing ever? [18:07:12] <shahriman> lu_zero: thanks a lot, i just finished compiling ffmpeg [18:07:41] <shahriman> got loads of warnings ... is it normal? [18:08:13] <iive> yep [18:12:39] <mru> no matter what you do, you'll always get warnings with some compilers [18:13:05] <mru> and even if targeting only a single compiler, some warnings should be considered acceptable [18:13:21] <mru> the alternative is to turn off entire classes of warnings [19:23:40] <Kovensky> <@elenril> btw did i mention that QFT is the best thing ever? <-- getting over your QFT trauma by being traumatized by solid state physics instead? [19:30:41] <elenril> i got over solid state too [19:30:45] <elenril> now it's group theory [19:31:21] <kshishkov> huh? [19:31:44] <kshishkov> so now you'll learn the math you used in physics before that? [19:31:55] <elenril> exactly! [19:32:09] <kshishkov> ah, so it's traditional education [19:32:10] <BBB> mru: could you apply http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-February/107476.html ? [19:33:19] <kshishkov> BBB: you're not pross-au but still I have to nag you about bink-b [19:33:26] * elenril stabs kshishkov [19:33:40] <elenril> no, my patches are more important =p [19:33:44] <BBB> elenril: you first [19:33:48] <BBB> elenril: title of patch threads? [19:34:35] <elenril> [PATCH 1/4] lavf: use a new ffio_wfourcc macro instead of put_tag() where possible [19:35:39] <elenril> (and 2/4, 3/4 and 4/4) [19:35:46] <elenril> didn't you review them already? [19:36:13] <mru> BBB: dxva patch queued, will push out later [19:36:18] <BBB> thank you [19:36:26] <BBB> elenril: I did, I'm queueing them and testing them only [19:39:08] <BBB> fate is running, seems good so far [19:40:59] <BBB> then I'll get to kostya's bink-b-audio patches [19:42:45] * BBB loves make -j8 fate [19:43:33] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r0abdb29317 ffmpeg/libavformat/ (12 files): [19:43:34] <CIA-15> ffmpeg: lavf: use a new ffio_wfourcc macro instead of put_tag() where possible [19:43:34] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [19:43:38] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r99f42c27ab ffmpeg/libavformat/avienc.c: [19:43:38] <CIA-15> ffmpeg: avienc: replace &tag[0] with tag. [19:43:38] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [19:43:40] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rbbc413f943 ffmpeg/libavformat/ (8 files): [19:43:40] <CIA-15> ffmpeg: lavf: replace remaining uses of put_tag with avio_write [19:43:40] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [19:43:42] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r61840b4360 ffmpeg/libavformat/ (avio.h aviobuf.c): [19:43:42] <CIA-15> ffmpeg: avio: deprecate put_tag [19:43:42] <CIA-15> ffmpeg: it's not used internally anymore and shouldn't be public. [19:43:42] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [19:45:08] <BBB> elenril: anything else? [19:45:39] <BBB> if not, let's move on to kshishkov [19:45:48] <BBB> kshishkov: list of patch thread subjects? [19:47:29] <kshishkov> BBB: http://patches.ffmpeg.org/patch/1214/ till 1219 [19:47:46] <elenril> BBB: avio_get_str [19:47:52] <BBB> elenril: oh right [19:48:48] <BBB> needs a rebase [19:49:03] <CIA-15> ffmpeg: Dave Yeo <daveryeo(a)telus.net> master * rcc4e9d2a24 ffmpeg/configure: [19:49:03] <CIA-15> ffmpeg: OS/2: lxlite should use stdout [19:49:03] <CIA-15> ffmpeg: This causes lxlite to use stdout instead of vioXXX [19:49:03] <CIA-15> ffmpeg: functions. This improves fate and build logs readability. [19:49:03] <CIA-15> ffmpeg: Affects OS/2 only. [19:49:04] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [19:49:13] <CIA-15> ffmpeg: Kyle <kshawkeye(a)gmail.com> master * r04973f8082 ffmpeg/libavcodec/dxva2_internal.h: [19:49:13] <CIA-15> ffmpeg: dxva2: define required feature selection macros [19:49:13] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [19:49:41] <BBB> you know, reimar has a point [19:49:54] <BBB> stream copy destroys the codec id, are we sure that's a good way to do this? [19:50:00] <BBB> if you think it is, it's fine with me... [19:50:36] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r8997bb8807 ffmpeg/libavcodec/bink.c: [19:50:36] <CIA-15> ffmpeg: bink: use LOCAL_ALIGNED for aligned stack data [19:50:36] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [19:50:40] <kshishkov> it doesn't matter here [19:52:11] <BBB> ok, then it's fine I guess [19:54:03] <BBB> it doesn't wan to apply [19:54:03] <BBB> odd [19:56:05] <kshishkov> get_le16 in the way? [19:56:25] <BBB> indeed [19:56:28] <BBB> fixed, queued [19:56:34] <kshishkov> thanks [19:56:51] <kshishkov> five more left ;) [20:06:30] <BBB> kshishkov: 5? 4 more [20:06:32] <BBB> it's 5 in total [20:07:27] <kshishkov> and http://patches.ffmpeg.org/patch/1219/ [20:08:56] <BBB> got it [20:09:03] <BBB> were the idct prevent overflows patches ever applied? [20:11:01] <kshishkov> BBB: it seems not :( [20:14:10] <BBB> kshishkov: you should push us more :-p [20:14:26] <kshishkov> it's you who should patches, not me [20:15:12] <BBB> you push me, I push patches [20:15:15] <BBB> all 7 queued [20:15:21] <kshishkov> thank you [20:17:30] <BBB> anyone have an opinion on wbs' av_pkt_dump_log()? should it take an AVStream stream or a AVRational time_base? [20:18:02] <BBB> I essentially don't care a lot, but AVRational makes a little more sense since, well, it really only uses that much [20:19:43] <kshishkov> and it's a bit more independent then [20:21:48] <mru> this iar compiler is funny [20:21:59] <kshishkov> obvious from name [20:22:52] <mru> guess how it compiles int x; /* ... */ int s = ~x >> 31; [20:23:07] <kshishkov> 32-bit? [20:23:11] <mru> yes [20:24:00] <kshishkov> not;shl ? [20:24:09] <mru> this is arm [20:24:21] <kshishkov> should be one instruction then [20:24:57] <CIA-15> ffmpeg: Peter Ross <pross(a)xvid.org> master * r582ac86d19 ffmpeg/libavcodec/binkaudio.c: [20:24:58] <CIA-15> ffmpeg: binkaudio: perform band table scaling in decode_init [20:24:58] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:25:07] <BBB> kshishkov, pross-au: all pushed [20:25:08] <CIA-15> ffmpeg: Peter Ross <pross(a)xvid.org> master * rf0ca29eb5f ffmpeg/libavformat/bink.c: [20:25:08] <CIA-15> ffmpeg: bink: set audio stream codec_tag such that binkaudio decoder can identify bitstream version [20:25:08] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:25:09] <CIA-15> ffmpeg: Peter Ross <pross(a)xvid.org> master * rccfcddb3f2 ffmpeg/ (Changelog libavcodec/avcodec.h libavcodec/binkaudio.c): [20:25:09] <CIA-15> ffmpeg: Bink version 'b' audio decoder [20:25:09] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:25:10] <BBB> let me know if any are left [20:25:14] <CIA-15> ffmpeg: Peter Ross <pross(a)xvid.org> master * ra304def1dc ffmpeg/libavcodec/binkaudio.c: [20:25:14] <CIA-15> ffmpeg: binkaudio: remove unnecessary loop [20:25:14] <CIA-15> ffmpeg: decode_init sets bands[0] == 2, so this loop always sets the band table [20:25:14] <CIA-15> ffmpeg: index (k) to zero. [20:25:14] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:25:16] <CIA-15> ffmpeg: Peter Ross <pross(a)xvid.org> master * r8a8c283edd ffmpeg/libavcodec/binkaudio.c: [20:25:16] <CIA-15> ffmpeg: binkaudio: simplify frame_len_bits and frame_len calculation [20:25:16] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:25:18] <kshishkov> BBB: thanks, man [20:25:18] <CIA-15> ffmpeg: Peter Ross <pross(a)xvid.org> master * r588a3ffd96 ffmpeg/libavformat/bink.c: [20:25:19] <CIA-15> ffmpeg: bink: decode audio track identifiers into AVStream.id [20:25:19] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:25:25] <CIA-15> ffmpeg: Peter Ross <pross(a)xvid.org> master * re211e255aa ffmpeg/ (libavcodec/binkidct.c tests/ref/fate/bink-demux-video): [20:25:25] <CIA-15> ffmpeg: bink: prevent overflows within binkidct by using int-sized intermediate array [20:25:25] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:25:41] <kshishkov> BBB: and you have http://patchwork.libav.org/project/FFmpeg-devel/list/ for monitoring [20:25:45] <mru> kshishkov: yes, it _can_ be done in one instruction [20:26:32] <kshishkov> mru: and, obviously, this I-or compiler manages to use three instructions? [20:26:44] <mru> it manages to get the wrong result [20:26:53] <kshishkov> even better [20:27:09] <pJok> nice [20:27:13] <pJok> more bink audio [20:27:31] <kshishkov> pJok: now we support more Bink variants than RAD tools :P [20:27:43] <pJok> kshishkov, frightening :P [20:27:50] <kierank> kshishkov: have bink ever contacted you? [20:27:59] <pJok> now when is ffbikenc ready? [20:28:25] <kshishkov> kierank: http://codecs.multimedia.cx/?p=196#comments [20:29:09] <mru> kshishkov: of the compilers I have at hand, only TI does it with one instruction [20:30:27] <kshishkov> mru: troll ARMcc devs with it ;) [20:30:45] <mru> armcc at least gets the right result [20:31:13] <kshishkov> even GCC sometimes can do that, big deal [20:31:35] <mru> armcc and gcc both do (~x)>>31 [20:31:41] <mru> TI does ~(x>>31) [20:31:45] * kshishkov still remembers that wonderful optimisation GCC performs on float arrays on ARM [20:31:54] <mru> that one is fixed [20:32:05] <pJok> mru, reroll gcc random code generator? [20:32:10] <mru> iar does (x >> 31) ^ 1 [20:32:28] <kshishkov> lol [20:33:01] <kshishkov> why cannot it be called i-or instead? [20:35:39] <pasteeater> are inserted or attached patches preferred on the devel ML? i see both being used. [20:35:53] <mru> pasteeater: either is fine as long as the patch isn't mangled [20:36:27] <pasteeater> i see. thanks. [20:36:34] <mru> if you're unsure, attach [21:09:05] <astrange> BBB: agreed with the diagnosis. let me finish my homework... [21:19:02] <lu_zero> merbanan: you around? [21:21:07] <lu_zero> BBB: I'm about to push the "mov tkhd' width and height usage" patchset [21:32:18] <CIA-15> ffmpeg: Maksym Veremeyenko <verem(a)m1stereo.tv> master * r77d207cbe6 ffmpeg/libavformat/movenc.c: [21:32:18] <CIA-15> ffmpeg: reindent after tapt patch [21:32:18] <CIA-15> ffmpeg: Signed-off-by: Luca Barbato <lu_zero(a)gentoo.org> [21:32:22] <CIA-15> ffmpeg: Maksym Veremeyenko <verem(a)m1stereo.tv> master * rea1afa124c ffmpeg/libavformat/movenc.c: [21:32:22] <CIA-15> ffmpeg: use tapt atom for sample aspect ratio [21:32:22] <CIA-15> ffmpeg: Signed-off-by: Luca Barbato <lu_zero(a)gentoo.org> [21:32:27] <CIA-15> ffmpeg: Maksym Veremeyenko <verem(a)m1stereo.tv> master * rd184c86cd3 ffmpeg/libavformat/movenc.c: [21:32:27] <CIA-15> ffmpeg: store pasp atom for all types of quicktime movie [21:32:27] <CIA-15> ffmpeg: Signed-off-by: Luca Barbato <lu_zero(a)gentoo.org> [22:22:01] <mru> BBB, elenril: you added some warnings: http://fate.ffmpeg.org/arm-linux-gcc-4.3/20110225221948/compile/20110224221… [22:31:18] <BBB> lu_zero: I trust you fully, so push it if you feel confident about the patch [22:31:20] <BBB> mru: on it [22:31:44] <lu_zero> BBB: just in case =) [22:32:39] <BBB> mru: grep put_tag libavformat/* returns nothing except the old function definition [22:32:44] <BBB> mru: so I think that warning is old [22:33:06] <BBB> oh, it's maksym's patches [22:33:15] <BBB> somebody forgot to update them to the new API [22:33:17] <mru> BBB: fate says it showed up between those two dates in the url [22:42:25] <BBB> mru: fixed, see 2nd email [22:42:29] <BBB> first one is incomplete, I forgot one [23:01:51] <Dark_Shikari> mru: ffvp8 is like, generally 50% faster or so. [23:01:57] <Dark_Shikari> it's really kinda embarassing [23:02:17] <Dark_Shikari> "lol, this decoder that got ~3 man-weeks put into it is 50% faster than something with a dozen full-time maintainers" [23:05:07] <superdump> that kind of discounts the number of people and amount of time put into the shared code used in the vp8 decoder, no/ [23:05:17] <superdump> ?* [23:05:33] <superdump> (the vp8 decoder == ffvp8) [23:09:33] <Dark_Shikari> ? [23:12:20] <superdump> i'm saying the 3 man-weeks is probably not a fair total estimate if it is leveraging shared functions from ffh264 or so [23:15:49] <Dark_Shikari> It didn't leverage much shared stuff [23:15:54] <Dark_Shikari> things it leveraged: [23:16:01] <Dark_Shikari> some predict functions (trivial) [23:16:08] <Dark_Shikari> emulated edge mc (a few minutes of work) [23:16:18] <Dark_Shikari> the bitstream reader/etc [23:16:25] <Dark_Shikari> vp56 arith decoding (which we rewrote 3 times anyways...) [23:19:50] <superdump> fair enough then [23:43:45] <mru> Dark_Shikari: it obviously also shares all the buffer management and other high-level things [23:50:38] <Dark_Shikari> True, but that stuff isn't very complicated. [23:51:17] <mru> doing it all from scratch still takes some time [23:52:16] <Dark_Shikari> not 6+ years [23:53:29] <mru> of course not [23:53:41] <mru> but a few weeks perhaps [23:53:46] <kierank> on2's cto doesn't come on #x264 any more [23:53:56] <kierank> you could have told him [23:54:05] <kierank> probably run away with his $$$

1 0

IRC log for 2011-02-24
by irc＠mansr.com 25 Feb '11

25 Feb '11

[00:00:58] <dalias> :/ [00:01:37] <mru> dalias: now that your libc is more or less done, will you do a compiler too? [00:05:32] <dalias> :) [00:05:39] <dalias> that sounds a lot more difficult [00:05:50] <mru> you're probably right [00:06:06] <dalias> libc is "easy" because most functionality is self-contained [00:06:54] <mru> and much of it is trivial [00:07:32] <dalias> the only parts with any major cross-interaction are stdio/locale/malloc/pthread/regex [00:07:52] <mru> I was going to say stdio, malloc, and pthreads [00:08:01] <mru> I don't care much about locale [00:08:32] <mru> how much is libc regex actually used? [00:09:48] <dalias> regex is not used by other things [00:09:55] <dalias> but it depends on locale to some extent [00:09:56] <mru> I mean by apps in general [00:10:22] <dalias> lots of apps don't use it because they either don't trust it to be a good implementation, or they want to know they have certain extensions :( [00:10:39] <mru> gnu grep and friends probably use their own [00:10:50] <dalias> however using the libc regex is the only way you can get access to collation classes [00:11:02] <mru> how so? [00:11:12] <dalias> gnu grep and friends basically do a test if (libc=glibc) use libc else use their own [00:11:35] <dalias> the [=sym=] stuff [00:11:52] <dalias> there's no other api but regex to access that part of the locale data [00:12:23] <dalias> strxfrm uses it but doesn't really provide the application any info other than giving a sort key for the string [00:12:54] <dalias> i would like to eventually support collation classes [00:14:21] <mru> an application could duplicate the entire locale system [00:14:35] <dalias> yeah but then it can't ensure that it matches the system's [00:14:59] <mru> many locales are well-defined [00:15:04] <dalias> and therefore it might not correctly support the user's locale requirements [00:16:16] <dalias> that works for widely-used locales, but if the user has had to define their own or make fixes to their own, an application insisting on using its own version might break :/ [00:16:41] <dalias> at least in the past, glibc was notorious for being extremely slow in following unicode [00:17:23] <dalias> so if your language was one only recently encoded by unicode, or that recently got new important characters added, or that was just never properly tested, you might encounter trouble :( [00:17:34] <mru> yeah, I'm sure there'd be problems in reality [00:18:08] <dalias> i dunno if it's been fixed, but glibc used to consider all non-spacing combining characters (class Mn in unicode) non-letters [00:18:25] <dalias> which breaks many languages, including tibetan, which have non-spacing letters [00:19:05] <dalias> in theory it also breaks hebrew with vowels (which usually aren't written), and thai, i think [00:19:30] <dalias> in that [[:alpha:]]+ will fail to match words in these languages [00:19:44] <mru> great [00:20:19] <mru> I can understand tibetan quirks being overlooked, but hebrew and thai are rather common, no? [00:20:28] <dalias> as long as the application is going thru the libc for locale, at least this is fixable (either the user can fix it locally with localedef, or get it fixed upstream) [00:21:24] <dalias> but if you're bypassing libc and doing it yourself, you need to be extra-careful to use correct character data from unicode, rather than just rolling your own or copying "known correct" data from glibc [00:21:39] <dalias> otherwise you'll make it impossible for users of certain languages to get proper support [00:21:57] <mru> say hi to my enterprise java application [00:28:40] <mru> binutils 2.18 works [00:28:49] <mru> 2.19 and later all fail [00:29:09] <mru> and what's worse, they fail to link anything produced by recent llvm-gcc [00:32:32] <Kovensky> oh, a dalias [00:35:42] <asdf1234> is anyone going to tell Rukhsana Ruby to stop top posting [00:37:51] <kierank> I thought it was someone just asking how to use get but I guess "the url of the repo" is a plausible question to ask right now [00:40:36] <kierank> git* [00:46:29] <dalias> kovensky, ? [01:14:26] <BBB> hah, I have it neared down to a five-liner change [01:27:32] <BBB> http://llvm.org/bugs/show_bug.cgi?id=9307 [01:28:50] <Dark_Shikari> nice [01:29:59] <Compn> isnt ffmpeg in the clang testsuite by now ? [01:30:01] <Compn> ehhe [01:35:23] <BBB> it should be [01:35:27] <BBB> Dark_Shikari: btw that is your patch [01:35:33] <BBB> Dark_Shikari: go be ashamed, you broke clang! :-p [01:35:37] <BBB> (good job!) [01:35:58] <Kovensky> BBB: in case it isn't in the testsuite, open a bug saying that ffmpeg isn't in the testsuite \o/ [01:45:30] <dalias> lol [01:45:32] <dalias> http://www.ohse.de/uwe/articles/whyidontsendapatch.html [01:47:15] <roxfan> o.O a fax [01:47:56] <BBB> probably for copyright transfer agreements [01:48:04] <roxfan> oh [01:49:02] <dalias> yeah [01:54:31] <saintdev> ruggles: http://dpaste.com/442957/ [02:06:21] <dalias> mru, any luck finding me someone for arm port? :) [02:27:41] <mru> dalias: I wasn't aware I was your personal headhunter [02:29:16] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * ra58bcb40b1 ffmpeg/libavcodec/vmdav.c: [02:29:16] <CIA-15> ffmpeg: vmdaudio: fix raw_block_size calculation. [02:29:16] <CIA-15> ffmpeg: The size should depend on the output sample size, not the internal bit depth. [02:29:16] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:29:18] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r1328d43313 ffmpeg/libavcodec/vmdav.c: [02:29:18] <CIA-15> ffmpeg: vmdaudio: remove duplicated code by merging mono and stereo decoding. [02:29:18] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:29:26] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r9b73f78600 ffmpeg/ (libavcodec/vmdav.c tests/ref/fate/sierra-vmd): [02:29:26] <CIA-15> ffmpeg: vmdaudio: output audio samples for standalone silent blocks. [02:29:26] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:29:28] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rdd1af5136f ffmpeg/libavcodec/vmdav.c: [02:29:28] <CIA-15> ffmpeg: vmdaudio: use macros and a local variable for block type. [02:29:28] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:29:34] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r6989cb2dae ffmpeg/libavcodec/vmdav.c: [02:29:34] <CIA-15> ffmpeg: vmdaudio: correct the silent chunk count in the first block. [02:29:34] <CIA-15> ffmpeg: This fixes A/V sync with several samples, notably: [02:29:39] <CIA-15> ffmpeg: http://samples.mplayerhq.hu/game-formats/sierra-vmd/swat_*.vmd [02:29:39] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:29:39] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r2d213695fc ffmpeg/libavcodec/vmdav.c: [02:29:39] <CIA-15> ffmpeg: vmdaudio: simplify buffer pointer and header size handling. [02:29:40] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:29:40] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r7a4fb3fd93 ffmpeg/libavcodec/vmdav.c: [02:29:41] <CIA-15> ffmpeg: vmdaudio: set *data_size to zero when skipping small packets and add a warning log message. [02:29:41] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:29:42] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r22f893e1c9 ffmpeg/libavcodec/vmdav.c: [02:30:24] <CIA-15> ffmpeg: vmdaudio: validate block type [02:30:24] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:33:39] <BBB> ruggles: the rest of your patches doesn't apply, or I'm applying in the wrong order [02:34:02] <mru> aren't they numbered? [02:41:09] <BBB> mru: I aplied them in that order [02:41:11] <BBB> but they stopped applying [02:41:42] <BBB> gmail displays subjects of thread starters, not thread followers [02:42:02] <BBB> so if you send patches as updates in threads but in different order, such as what happened here, I can't see what the order is in my inbox anymore [02:43:49] <mru> they are numbered in the subject, no? [02:45:13] <BBB> yes but if the order changes [02:45:20] <BBB> let's say I had 16 patches numbered 1-16 [02:45:25] <BBB> now I reorder them for whatever reason [02:45:30] <BBB> so what used to be patch 1 is now 3 [02:45:34] <mru> then you have only yourself to blame [02:45:34] <BBB> with 2 new patches before it [02:46:26] <BBB> for using gmail? [02:47:09] <mru> for reordering dependent patches [02:47:12] <mru> and for using gmail [02:48:10] <dalias> mru, :) [02:54:05] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r8e9027d266 ffmpeg/libavcodec/vmdav.c: [02:54:05] <CIA-15> ffmpeg: cosmetics: remove debugging cruft [02:54:05] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:16] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r762b386e4a ffmpeg/libavcodec/vmdav.c: [02:54:16] <CIA-15> ffmpeg: vmdaudio: move all silence chunk handling to vmdaudio_loadsound(). [02:54:16] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:18] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r868f2f4d90 ffmpeg/libavcodec/vmdav.c: [02:54:18] <CIA-15> ffmpeg: cosmetics: reindent after previous commit [02:54:18] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:21] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * rba9516cca8 ffmpeg/libavcodec/vmdav.c: [02:54:21] <CIA-15> ffmpeg: cosmetics: reindent after previous commit [02:54:21] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:24] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r1574eff3d2 ffmpeg/libavcodec/vmdav.c: [02:54:24] <CIA-15> ffmpeg: vmdaudio: simplify vmdaudio_decode_frame() by handling block_type first, then making a single call to vmdaudio_loadsound(). [02:54:24] <CIA-15> ffmpeg: This also adds output buffer size checks for AUDIO and SILENCE block types. [02:54:24] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:27] <BBB> wtf @ gmail [02:54:38] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r1108f8998c ffmpeg/ (libavcodec/vmdav.c tests/ref/fate/sierra-vmd): [02:54:38] <CIA-15> ffmpeg: vmdaudio: output 8-bit audio as AV_SAMPLE_FMT_U8. [02:54:38] <CIA-15> ffmpeg: There is no need to expand to 16-bits. Just use memcpy() to copy the raw data. [02:54:38] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:38] <BBB> note how there's two patches called "reindent after previous commit" [02:54:40] <BBB> guess what gmail did [02:54:41] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r2ec7862db8 ffmpeg/libavcodec/vmdav.c: [02:54:41] <CIA-15> ffmpeg: vmdaudio: remove unnecessary fields from VmdAudioContext and use the corresponding AVCodecContext fields instead. [02:54:41] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:42] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles(a)gmail.com> master * r1e86d685e0 ffmpeg/libavcodec/vmdav.c: [02:54:42] <CIA-15> ffmpeg: vmdaudio: add out_bps to VmdAudioContext and use it to replace hard-coded sample size. [02:54:42] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [02:54:47] <BBB> IT PUT THEM IN THE SAME THREAD [02:54:52] <BBB> that's why they didn't apply [02:54:59] <BBB> crap [02:55:01] <BBB> anyway [02:55:03] <BBB> applied now [03:07:15] <DrMcCoy> You know, ScummVM currently has a VMD decoder that works for, to my knowledge, all VMD files up to the ones in later Addy games (around 1999) :P [03:08:32] <DrMcCoy> ffmpeg currently locks up in, for example, the Woodruff intro. And the GK2 sound has clicks :P [03:10:09] <DrMcCoy> Also, Urban Runner's VMDs have the video frame data Indeo3 encoded [03:15:52] <astrange> file a bug about the lockup, that's a low-grade security issue [03:20:26] <DrMcCoy> Hmm, on second look, it seems to be rather strange behaviour on pause than a straight lookup. It did continue after more than 60 seconds of stalling [03:20:55] <DrMcCoy> Just thought I'd let you know, since there's apparently someone just now working on vmdaudio [03:21:12] <Compn> i think we knows about such issue [03:21:16] * Compn checks roundup [03:21:22] <DrMcCoy> Okays [03:21:56] <Compn> well its not in roundup [03:21:59] <Compn> so could add it [03:22:03] <Compn> :) [03:24:22] <BBB> astrange: what should I do with your -mt patches? you asked me to hold off for now with the 2 you posted, should I wait still? [03:24:53] <astrange> yes. i have a gdb session open on a deadlock with them [03:25:01] <astrange> and i haven't had time to touch it since i opened it :/ [03:25:10] <BBB> heh :) [03:25:19] <BBB> can I help with anything? [03:25:34] <BBB> should I make ffmpeg.c autodetect #thread on -threads0 by reading /proc or so? [03:26:02] <astrange> POSIX method is sysconf(_SC_NPROCESSORS_ONLN) * 1.5 [03:26:37] <astrange> a patch setting that for threads==0 is fine with me. i don't have enough cores to benchmark the * x factor [03:26:44] <astrange> but i'm pretty sure 1.5 is right [03:26:56] <astrange> the deadlock command with those patches is '--args ./ffplay_g -threads 3 /Users/astrange/Downloads/angels_480-huffyuvcompress.avi' [03:27:09] <astrange> with http://samples.mplayerhq.hu/V-codecs/HuffYUV/angels_480-huffyuvcompress.avi [03:27:28] <astrange> gdb --args [03:27:31] <BBB> can't help, I only have 2 cores, I think [03:27:37] <astrange> i can get back to it maybe tomorrow, definitely friday [03:27:54] <BBB> but we can do 1.5 as a start, and then finetune it when someone has a better testcase [03:28:12] <BBB> also, can we already do _both_ slice-based and frame-based mt? [03:28:23] <BBB> for h264 on super-multi-core systems that might provide slight extra benefits [03:29:23] <astrange> it's theoretically possible but not implemented in any codec [03:30:01] <astrange> i think it nearly works if you set thread_count = something active_thread_type = 3 on a frame thread's context in h264 (in the -mt repository) [03:30:27] <astrange> it'd be better to actually respect thread_count. the plan there is basically to count the slices in the previous frame then steal that many threads and use them for slices in the next frame [03:30:54] <astrange> also slice threading in h264 is actually broken atm. the frame crcs don't match. but i don't think the error is visible [03:31:49] <BBB> dark_shikari complained about something related to that also [03:32:22] <BBB> doing this in something like h264 shouldn't be difficukt [03:32:56] <BBB> i.e. not more difficult than frame-based and slice-based separately [03:33:13] <BBB> then again I'm likely missing all kind of details [03:34:25] <astrange> nothing hard about it at all. you just have to turn it on and find the memory allocations you forgot to add [03:38:46] <BBB> fair enough, I can work on that... there's other stuff I wanted to do also, like adding a LIBRARY_SUPPORTS_THREADS like flag for x264 [03:39:09] <BBB> and a CODEC_CAP_SLICE_THREADS so that we don't uselessly allocate threads if the codec doesn't support it [03:39:36] <BBB> and then some way to detect slice-threads in use so we can optimally combine slice-threads and frame-threads [03:39:53] <BBB> if a particular file has only 1 slice, it makes no sense to allocate 2 frame-threads and 8 slice-threads [03:40:04] <BBB> better do 9-1 [03:40:19] <BBB> and if the file has 8 slices, maybe do 6-4, or something, I don't know what the math would be [04:15:18] <peloverde> "Lots of people have talked here about the difficulty in reusing OpenSSL. I once had the distinct displeasure of trying to reuse ffmpeg as a library." [04:15:48] <peloverde> BBB: just access you ffmpeg label via imap [04:16:48] <peloverde> also doesn't linus use gmail [04:16:57] <Dark_Shikari> astrange: michael broke it [04:17:04] <Dark_Shikari> when he reordered how deblocking was done [04:17:13] <Dark_Shikari> his per-row deblocking is broken in the case of slice threading [04:17:19] <Dark_Shikari> the error is DEFINITELY visible [04:17:30] <Dark_Shikari> we found it when testing gaikai, the error propagates until it's atrocious [04:18:17] <kierank> peloverde: thought the quote was from linus [04:18:27] <saintdev> that sounds like lagarith, except that's defined as part of the format ^_^ [04:22:10] <Compn> peloverde : hyc found some good openssl alternatives ... [04:22:30] <Compn> Dark_Shikari : did you report bug to michaelni ? [04:22:48] <Dark_Shikari> yes [04:22:48] <Dark_Shikari> ages ago [04:22:52] <Dark_Shikari> he has no interest in fixing it [04:23:02] <Dark_Shikari> I have bothered him repeatedly [04:42:50] <saintdev> well, I seem to have successfully made ffaac _worse_ [04:42:52] <saintdev> \o/ [04:45:28] <kierank> hurry up and commit [04:47:19] <j45> so do the opposite of what made it worse ;) [04:47:39] <Dark_Shikari> that often makes it worse too [04:47:54] <j45> :p [04:53:44] <saintdev> j45: it's not like negative and positive: !worse != better ... !worse == worser [06:06:00] <peloverde> then fix it yourself or revert it? [06:06:49] <saintdev> peloverde: intermediate steps. just happened to listen to the output, and lol'd [06:24:18] <benoit-> moin [07:38:21] <Dark_Shikari> http://doom10.org/index.php?topic=1353.0 stupid of the day [07:40:18] <elenril> how do i shot web? [07:40:36] <Dark_Shikari> please send me teh codez [08:04:12] <peloverde> exec("neroAacEnc"); problem solved? [08:08:44] <spaam> yes. [08:23:54] <saintdev> hmm, limiting min_snr seems to help quality. and lowers bitrate! [08:40:30] <lu_zero> uh? [08:40:34] <lu_zero> good morning [08:40:44] <spaam> lu_zero: hur är det? :) [08:44:18] <lu_zero> spaam: sett bättre dagar [08:44:30] <lu_zero> if google translate is ok [08:44:35] <spaam> yes :) [08:46:17] <thresh> kshishkov: http://top.rbc.ru/society/24/02/2011/549203.shtml [08:46:23] * lu_zero should check the pronounce [08:47:23] <kshishkov> lu_zero: here you are - http://slayradio.com/mastering_swedish_lesson_3.php it has both speech and text [08:48:18] <kshishkov> thresh: Нургалиев наградил? [08:48:32] <lu_zero> kshishkov: iknow has something but I hadn't the time to clear it yet [08:48:45] <lu_zero> (and I should review my japanese scorecards as well =P) [08:49:03] <kshishkov> lu_zero: I never scored anything in Japanese, easy for me [08:49:29] <thresh> kshishkov: ага, и опустил нанопрезидента [08:49:34] <lu_zero> I need to setup the ime/deadkeys to write the accents =P [08:49:55] <lu_zero> japanese has a builtin js ime so it was easier [08:50:30] * lu_zero has left halfway the french sets since he couldn't type easily the accents... [08:50:30] <kshishkov> thresh: а нефиг под ногами у взрослых мешаться! [08:51:32] <kshishkov> lu_zero: I just assigned combine key, I don't need those weird European letters that much [08:51:53] <lu_zero> kshishkov: how did you set it up? [08:51:58] <saintdev_> privet [08:52:12] * saintdev_ has exhausted his russian knowledge [08:55:57] <lu_zero> what's the difference between sett and Jag ser? [08:56:12] <kshishkov> sett is supine IIRC [08:56:19] <kshishkov> jag ser is "I see" [08:56:49] * lu_zero fed the same expression in different languages [08:57:58] <kshishkov> lu_zero: and look at http://en.wikipedia.org/wiki/Compose_key [09:02:13] <lu_zero> uhmm [09:02:21] * lu_zero will have to remap some of those [09:04:29] <merbzt> is any merge happy person awake ? [09:04:57] <kshishkov> mergentainers? [09:07:55] <cartman> moin [09:09:33] <kshishkov> moinli</KotH-mode> [09:13:34] * KotH stabsli kshishkovli [09:14:20] <kshishkov> KotH: that sounds like that troll book [09:15:04] <lu_zero> merbzt: I'm sad but I'm around [09:15:25] <cartman> wbs: \o/ [09:15:30] <KotH> lu_zero: sad? [09:15:39] <cartman> wbs: send me the Mac gcc patch as an attachment please? :) [09:15:43] <lu_zero> KotH: yup =P [09:15:58] <wbs> cartman: I'm working on it, I'll push it to review.source.android.com when I'm done with it [09:16:04] <cartman> wbs: cool! [09:18:36] <merbzt> lu_zero: sad about what ? [09:19:00] <merbzt> lu_zero: and I need a merge of the mp4 muxing patches from Maksym [09:19:51] <kshishkov> merbzt: ask mru/siretart/BBB when any of them is here [09:20:48] * siretart notices a hilight [09:21:30] <merbzt> siretart: [FFmpeg-devel] [PATCH] mov tkhd' width and height usage [09:22:34] <lu_zero> merbzt: let me have a look [09:22:59] <siretart> this one http://patches.ffmpeg.org/patch/1110/ ? [09:23:09] <siretart> hm. patches.ffmpeg.org could really use some cleanup [09:23:26] <siretart> lu_zero: thanks [09:27:00] <lu_zero> 4D5A5BBC.70400(a)m1stereo.tv ? [09:27:37] <merbzt> no [09:27:50] <lu_zero> which ones ^^? [09:27:58] <merbzt> verem [09:28:05] <merbzt> @m1stereo.tv [09:28:24] <lu_zero> yes but which email ^^? [09:28:35] * lu_zero pointed the last email by message-id [09:29:52] <lu_zero> 02/15/2011 11:55 AM ? [09:29:54] <merbzt> 02/15/2011 11:55 AM [09:30:06] <merbzt> yes, it needs a fix before commit [09:30:21] <lu_zero> which one? [09:30:32] <lu_zero> could you comment on it the thread? ^^ [09:30:44] <merbzt> I did [09:30:49] <lu_zero> uhm [09:30:58] <lu_zero> ... [09:31:12] * lu_zero should restart the socks5 ssh... [09:34:39] * siretart suggests referencing urls on http://patches.ffmpeg.org [09:37:06] <merbzt> well in this case email is better as I had comments for changes [09:37:47] <kshishkov> siretart: also there are unapplied binkaudio patches IIRC [09:38:15] <siretart> kshishkov: links? [09:42:42] <kshishkov> siretart: http://patches.ffmpeg.org/patch/1214/ http://patches.ffmpeg.org/patch/1215/ http://patches.ffmpeg.org/patch/1216/ http://patches.ffmpeg.org/patch/1217/ http://patches.ffmpeg.org/patch/1218/ http://patches.ffmpeg.org/patch/1219/ [09:43:11] <siretart> can't these patches be merged to a bundle, so that you have only one link? [09:45:47] <siretart> kshishkov: I don't have time right now to look at it, I'd put it on my list for this afternoon/tonight [09:48:08] <kshishkov> siretart: thanks for that [09:56:56] <wbs> cartman: https://review.source.android.com/21419 [09:57:19] <cartman> wbs: lets see [09:58:02] <Kovensky> http://pastebin.com/qcZVZvD8 hah [09:59:08] <kshishkov> Kovensky: wait until elenril hears this [09:59:55] <Kovensky> indeed [10:39:58] <Tjoppen> libavfilter seems to have a rather.. interesting program flow [10:40:22] <Tjoppen> as in, I'm a bit sceptical of filters calling eachother directly [10:46:24] <kshishkov> try gstr**m*r [10:46:41] <Tjoppen> heh [10:47:35] <merbzt> Tjoppen: well the api has been deved for years [10:47:41] <merbzt> it should hold up [10:48:32] <Tjoppen> I'm just a little worried that for instance multi-input graphs appear able to fill up RAM [10:48:45] <Tjoppen> lunchtime [10:50:38] <merbzt> that sounds er, neat maybe [10:54:21] <kshishkov> Tjoppen: Parkinson's law - every program tries to eat all RAM [11:09:44] <mru> btw, latest llvm-gcc passes all the tests [11:11:22] <siretart> \o/ [11:11:35] <mru> clang fails [11:11:48] <siretart> oh, I confused those two [11:11:52] <mru> does that mean it's a frontend problem? [11:12:16] <siretart> could also be a bug in llvm that only the clang frontend triggers [11:12:23] <mru> or that, yes [11:58:45] * elenril throws some vector bosons at kshishkov [11:59:13] * kshishkov relies on air to protect him [11:59:33] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/LuckilyMyPowersWillProtectMe [11:59:59] <kshishkov> nope, I'm merely friends with laws of physics :P [12:00:59] <elenril> they won't protect you in this case =p [12:01:16] <kshishkov> huh? [12:01:47] <kshishkov> I don't think those bosons will survive after colliding any air molecule [12:02:10] <elenril> air generally doesn't shield from γ radiation [12:02:19] <kshishkov> it does [12:02:53] * kshishkov thinks about major source of gamma rays in this system and Earth atmosphere [12:03:08] <elenril> you'd need a pretty thick layer of air for that [12:04:17] <kshishkov> depends on how many particles you can throw [12:04:29] <kshishkov> and with what energy of course [12:04:41] <kshishkov> and their time of life [12:05:57] <elenril> a photon doesn't decay =p [12:06:34] <kshishkov> that's only one instance of vector bosons [12:08:08] <elenril> W and Z aren't very useful when you're building death rays [12:08:51] <kshishkov> well, the only useful death ray ever was built with photons indeed [12:09:14] <siretart> DonDiego: I'm still waiting for your changes for 0.5.4 [12:09:31] * elenril goto uni [12:11:53] <mru> photons may not decay, but they can be absorbed [12:11:56] <mru> and scattered [12:12:05] <kshishkov> and annihilated! [12:15:28] <mru> if you have two of them [12:15:48] <DonDiego> siretart: right... [12:16:42] <kshishkov> or just collide them [12:19:20] <cartman> http://www.halolz.com/wp-content/uploads/2010/03/halolz-dot-com-sony-playst… [12:19:49] <mru> innovation ended a few decades ago [12:20:13] <cartman> WiiMote was an innovation [12:20:17] <mru> not really [12:20:51] <mru> the transistor was an innovation [12:22:14] <iive> not really, the lamp was. [12:22:23] <kshishkov> well, we were given such definition "innovation is successfully commercialized invention" [12:23:25] <mru> m-w defines it as "a new idea, method, or device" [12:23:31] <mru> there's nothing new in the wiimote [12:23:42] <cartman> http://www.macrumors.com/2011/02/24/15-17-inch-macbook-pro-specs-amd-gpu-qu… [12:23:45] <cartman> official! [12:23:46] <mru> acceleromoters have been around forever [12:23:53] <mru> +spelling [12:24:12] <Tjoppen> by that logic, nothing is an innovation [12:24:20] <Tjoppen> (which may be true) [12:24:31] <mru> Tjoppen: I said the transistor was [12:24:38] <mru> there was nothing quite like it before [12:24:55] <mru> sure, there was the vacuum tube [12:24:56] <Tjoppen> does not the work on the transistor build on top of the work on point contact diodes? [12:25:32] <mru> possibly [12:25:41] <mru> but the difference is fairly large [12:27:10] <iive> first computers were done with vacum tubes/lamps [12:27:11] <mru> the wiimote is just a new gadget built with existing components [12:27:16] <Tjoppen> true. feels like we're walking into a discussion about semantics though [12:27:20] <mru> and it's not even that new [12:28:06] <mru> motion sensors were used well before the wii [12:29:03] <iive> the innovation was not in using motion sensers, but how they were used. [12:29:28] <mru> "making it cheaper" is not an innovation [12:30:35] <mru> another real innovation: the internal combustion engine [12:30:51] <kshishkov> by whom? [12:31:14] <mru> I don't remember who built the first one [12:31:28] <mru> but it was a radically new approach compared to the steam engine [12:31:39] <mru> which was of course also an innovation [12:31:44] <kshishkov> aka external combustion engine [12:32:21] <mru> I find it a bit ironic that a nuclear power plant is really not much more than a glorified steam engine [12:32:39] <Tjoppen> well, I wouldn't be surprised if ICE is an older concept then ECE [12:33:01] <kshishkov> it was hard to get fire inside [12:34:14] <kshishkov> mru: and nuclear plants are also very eco-friendly (unless built in Ukraine) [12:34:16] <iive> Tjoppen: I'm still not aware of ICE that uses gunpowder. [12:34:17] <DonDiego> siretart: http://pastebin.com/Na6ecL4D [12:34:39] <Tjoppen> iive: there were attempts [12:35:18] <Tjoppen> but whatever. IMO there's only two ways to look on these things: either everyone innovates, or noone does (because eveything is built ontop of the works of others) [12:35:23] <kshishkov> it was hard to make homohenous pellets and feed them at constant rate [12:36:12] <kshishkov> Tjoppen: it's the same story with inventions - an improvement should be non-obvious knowing state-of-the-art methods [12:37:14] <mru> Tjoppen: most things are merely minor tweaks of existing technology [12:37:22] <BBB> mru: is it normal that they expect me to find the bug in the compiler? last time they were more helpful [12:37:22] <mru> innovations add something fundamentally new [12:37:41] <mru> BBB: compiler devs can be quite obnoxious [12:37:47] <cartman> BBB: clang people? [12:38:01] <BBB> cartman: yes [12:38:04] <BBB> cartman: I found your bug [12:38:08] <BBB> cartman: http://llvm.org/bugs/show_bug.cgi?id=9307 [12:38:12] <Tjoppen> I don't see the point in making any distinction, because in that case you need to set some kind of limit when things become innovative [12:38:17] <cartman> BBB: Awesome, lets get it fixed [12:38:27] <BBB> cartman: it's a clang bug, I don't fix it, they fix it [12:38:34] <cartman> BBB: I'll bug them :P [12:38:50] <kshishkov> Tjoppen: told you, when it's non-obvious to engineer knowing state-of-the-art methods [12:39:05] <cartman> BBB: you didn't find a bug you just reported a bug with no testcase [12:39:06] <cartman> pffff [12:39:17] <kshishkov> Tjoppen: aka making transistor from diode is not obvious, making solid-state diode - too [12:39:40] <kshishkov> Tjoppen: but using plastic case instead of metal one is not [12:40:01] <BBB> peloverde: where did that quote come from? [12:40:13] <BBB> cartman: I did: download ffmpeg, make fate-vp8 [12:40:15] <BBB> doesn't take long [12:40:33] <cartman> BBB: thats not how compiler bugs are resolved [12:40:39] <cartman> see my older miscompilation results [12:40:42] <cartman> you need a small testcase [12:40:55] <BBB> ffmpeg is small [12:41:06] <cartman> small as in 10-20 lines [12:41:11] <kshishkov> especially if you don't compile motion_est.c [12:41:51] <cartman> I'll bisect it. [12:41:54] <cartman> At least can do that :P [12:42:09] <BBB> cartman: can you bisect which version of clang broke it? [12:42:14] <BBB> (which revision) [12:42:22] <BBB> they asked for that, and you may be much faster than me [12:42:30] <cartman> BBB: yeah will do now [12:42:34] <BBB> thanks [12:42:43] <cartman> no, thank you for reporting it [12:42:46] <cartman> I was being lazy [12:42:50] <mru> a smaller test case is always better of course [12:43:01] <cartman> cd [12:43:04] <cartman> oops [12:43:20] <mru> but I've had arm fix bugs when the best I could say was it happened somewhere in mjpeg.c and was related to inlining [12:43:20] <BBB> good start [12:43:58] <cartman> sometimes compiler developers are in the good mood and they reduce it themselves :P [12:47:02] <BBB> cartman: I think if you tell them which revision broke it, they can figure it out themselves [12:47:29] <BBB> I may try to reduce the testcase but it's a massive amount of work, so I'm not too happy about it... [12:47:48] <cartman> BBB: yeah bisect might work [12:50:47] <uau> BBB: btw that paste doesn't really show it's a compiler bug - it's generally hard to show that unless you already have a reduced testcase or look at the asm output and see something obviously wrong with that [12:51:01] <uau> otherwise there could be undefined behavior somewhere in the program being tested [12:51:58] <mru> the test case should preferably be small enough that there is obviously no undefined behaviour [12:52:37] <mru> and small enough that manually analysing the asm is feasible [12:58:17] <BBB> uau: ENOTMYJOB [12:58:36] <BBB> uau: if the clang developers want an awesome compiler that can compile > hello world, I welcome them to look at this bug [12:59:07] <BBB> uau: if, on the other hand, they are happy to be merely a test subject in our fate suite that fails at random testcases and we don't care to look at, then I'll happily accept that fate and move on [13:00:38] <mru> clang does better than many other compilers at least [13:00:49] <mru> most compilers I try don't even build ffmpeg at all [13:02:32] <uau> BBB: i didn't say that it would be your job to debug it [13:02:59] <uau> but rather that what you've done so far does not reliably show it to be a bug in clang (and not in ffmpeg) [13:03:51] <lu_zero> ^^; [13:05:37] <cartman> http://ffmpeg.pastebin.com/raw.php?i=vcKYPJ8p its gonna be OK :P [13:05:58] <BBB> \o/ [13:06:13] <BBB> go cartman [13:06:22] <cartman> heheh [13:06:24] <BBB> if, after this, they need a reduced testcase, I can look into it [13:06:26] <BBB> but first this [13:06:27] <BBB> :) [13:06:30] <cartman> alright [13:06:42] <cartman> My last week with my MacBook Pro, better use it for good! :P [13:07:19] <kshishkov> cartman: has your ex-boss returned your Android tablet at least? [13:07:36] <cartman> kshishkov: yeah we got many tablets now but now I am going away :D [13:45:44] <BBB> elenril: will look at your patches also [13:52:42] <elenril> awesome [13:53:29] <elenril> btw any ideas for a nice name for put_flush_packet or whatever it's called [13:53:47] <wbs> avio_flush_packet? [13:54:02] <elenril> maybe just avio_flush()? [13:55:12] <wbs> perhaps, I don't remember exactly what that one does, but if it's mostly used by the packet stuff, keeping it in the name might be good, otherwise I don't have much of an opinion on that [13:58:00] <elenril> anyway, going home [13:58:18] <BBB> elenril: will look at it [13:58:23] <BBB> elenril: btw thanks for doing this in small chunks [13:58:28] <BBB> this is great for review purposes [14:08:29] <BBB> mru: did you test whether llvm-gcc also has the vp8 bug? [14:12:24] <mru> BBB: check fate [14:12:30] <mru> it passes [14:15:41] <cartman> mru, BBB even clang r80000 fails and current revision is 120.000 something [14:20:04] <mru> what rev was 2.8 release? [14:30:22] <wbs> cartman: btw, the ndk/gcc-4.4.0/osx fix hit git master now [14:31:39] <cartman> wbs: thanks! [14:31:54] <cartman> not that I'll touch OSX again though [14:32:38] <kshishkov> yes, it's all SuSE for you now [14:32:46] <cartman> indeed so. [15:11:14] <siretart> does one suggest to consider or suggest considering something? [15:12:05] <kshishkov> either [15:12:43] <siretart> thanks [15:13:14] <Dark_Shikari> latter [15:14:02] <siretart> thanks [15:46:10] <BBB> cartman: do a binary dissect between 123237 (known to fail) and 2.8 release (known to be good) [15:46:28] <BBB> cartman: and first confirm indeed that 2.8 release is good [15:50:14] <Dark_Shikari> Gotta love Apple. Introducing an amazing revolutionary new display port that can transfer an amazing 10gbps... almost 60% as much as DisplayPort has supported for half a decade. [15:50:38] <kshishkov> don't forget most confusing sign for it [15:50:46] <Dark_Shikari> Ah yes, its symbol is that of "high voltage, danger". [15:51:12] <cartman> BBB: git cloning llvm atm, svn is being a pain [15:51:22] <kshishkov> and HDMI is 10Gbps too, designed eight years ago [15:52:19] <cartman> kshishkov: Quad Core i7 is pretty though [15:52:59] <kshishkov> cartman: ? [15:56:09] <cartman> kshishkov: I mean the machine itself is good minus the hype [15:57:10] <kshishkov> cartman: and the hype inflates the price [15:57:26] <Dark_Shikari> also, the battery life is 3 hours worse than the previous version. [15:58:00] <cartman> Dark_Shikari: the previous version was lying, this one lies less [15:58:05] <Dark_Shikari> How do you know? [15:58:07] <Dark_Shikari> psychic powers? [15:58:13] <Dark_Shikari> apple isn't even claiming that. [15:58:14] <cartman> Dark_Shikari: using a Mac helps [15:58:17] <cartman> a 2010 mac helps a lot [15:58:22] <Dark_Shikari> You have a new Powerbook? [15:58:25] <Dark_Shikari> I'm pretty sure it isn't in stores yet. [15:58:28] <cartman> even 2 macs helps more ;) [15:58:42] <cartman> previous claim of 8-9 hours was a lie [15:59:00] <Dark_Shikari> Yes, and so is the claim of 5 hours [15:59:02] <Dark_Shikari> they're equally lies [15:59:08] <Dark_Shikari> if 8 hours was overstated by 30%, 5 hours will be overstated by 30% [15:59:16] <cartman> uhm no my MBP works fine with 5 hours [15:59:20] <Dark_Shikari> ... [15:59:22] <Dark_Shikari> You don't have the new MBP. [15:59:26] <Dark_Shikari> How do you know it will last 5 hours? [15:59:32] <Dark_Shikari> ESP? [15:59:35] <cartman> Dark_Shikari: physcic powers [15:59:42] <cartman> you should trust me [15:59:47] <cartman> I am the Mac whisperer [15:59:47] <Dark_Shikari> `-` [16:00:19] <cartman> where the fuck is av500 anyway [16:00:24] <cartman> kshishkov: do you know? [16:01:08] <kshishkov> cartman: probably in business trip or hardly working [16:01:20] <cartman> kshishkov: ah, ok :) [16:01:26] <cartman> one misses his sneaky comments [16:01:37] <kshishkov> sneaky as him? [16:01:55] * cartman is not sure if he has the right word [16:01:58] <cartman> but yes [16:02:06] <cartman> see ya! [16:02:15] <mru> I've had my sony running for 7 hours on a single charge [16:02:53] <kshishkov> mru: what did it run? [16:03:17] <mru> normal linux stuff [16:06:37] <kshishkov> was that with default battery? [16:08:12] <Dark_Shikari> Also, many of these things do run 8 hours -- for the first week [16:08:17] <Dark_Shikari> then they start losing their charge. [16:25:08] <astrange> 10:57 <@Dark_Shikari> also, the battery life is 3 hours worse than the previous version. <- the battery test changed [16:26:01] <astrange> mine (2010) is edition is down to 6400 mAh from 6900 mAh when it was manufactured [16:26:13] <astrange> *mine (2010 edition) [16:26:20] <astrange> which is not much of a loss [16:26:53] <dalias> my eeepc still lasts ~6 hours after almost 2 years [16:27:27] <mru> you'll probably find that the hours have got shorter too [16:27:28] <kshishkov> my Gdium doesn't last from the very beginning [16:27:45] <mru> my gdium battery holds less charge than a brick [16:28:27] <kshishkov> I've never managed to charge it to 100% but you saw me using Gdium at FOSDEM [16:28:36] <dalias> mru, lol [16:28:46] <mru> I'm not joking [16:28:48] <dalias> is that due to posix not having leap-seconds? [16:29:04] <kshishkov> due to RTC being a bit screwed [16:29:56] <mru> on my old laptop the time remaining estimate drops significantly faster than the wall clock [16:30:07] <mru> wall clock dropped from a 3rd floor window, that is [16:32:29] <dalias> well time on the 3rd floor and 1st floor will be slightly different [16:32:32] <dalias> due to gravity [16:32:46] <dalias> :) :) :) [16:32:59] <mru> not if there's a massive weight on the 4th floor [16:33:16] <dalias> your mom is on the 4th floor? [16:33:20] <dalias> ;-) [16:33:51] <mru> reminds me of an accident that happened in sweden a while ago [16:34:05] <mru> a floor collapsed [16:34:20] <mru> the weight watchers were having a meeting in the room [16:36:15] <ruggles> i think i got unlucky with my eeepc. the previous model lasts 6 hrs, mine only lasts 3 hrs, then the next model lasts 6 hrs. it's like they pushed the speed out first, then got the power usage under control in the next round. [16:36:16] <Dark_Shikari> well, naturally. if you're in "weight watchers", you're fat. [16:36:23] <Dark_Shikari> if you weren't, you wouldn't be there. [16:41:11] <ruggles> \o/ make fate passes after modifying all 121 audio decoders! [16:42:23] <ruggles> now it's time to pull/rebase and submit a gigantic patch. [16:42:54] <ruggles> what is the ML size limit? [16:43:22] <dalias> lol why such a big change? [16:43:48] <ruggles> changing audio decoding API to use get/release_buffer() and output to AVFrame [16:44:34] <mru> ruggles: \o/ [16:54:40] <merbzt> ruggles: \o/ [16:54:45] <merbzt> jolly goood [16:55:23] <ruggles> :) it has been an exhausting week. i never realized there were so many audio decoders. [16:55:28] <Kovensky> zomg, now I'll have to do actual work on x264-audio! [16:56:26] <BBB> ruggles: that's awesome! [16:58:08] <peloverde> BBB: it came from HN [16:58:15] <BBB> hn? [16:58:50] <BBB> damnit, apple has a quadcore macbookpro [16:58:54] <BBB> now I have to go buy a new one again [16:59:30] <mru> peloverde: you moved from reddit to hn? [16:59:41] <mru> that's good, you should be less annoyed [17:00:08] <Kovensky> BBB: wait until they release the sandy ones [17:00:32] <mru> i.e. 3 years after everybody else does [17:02:03] <Kovensky> lol [17:02:17] <Kovensky> well, current apple rumors is that the upcoming keynote will announce that [17:04:41] <astrange> it is SNB [17:05:02] <astrange> i7-2720QM [17:06:41] <Kovensky> oh [17:06:44] <astrange> i believe thw hw encoder is used for facetime [17:07:09] * Kovensky wonders if there'll be anything interesting on 10.7 [17:38:47] <kierank> [16:44] ruggles: changing audio decoding API to use get/release_buffer() and output to AVFrame --> \o/ [17:40:06] <Kovensky> what does that change for API users btw? [17:42:19] <ruggles> Kovensky: don't have to allocate their own output buffer. unless they want to override get/release/buffer(). [17:42:35] <Kovensky> o [17:43:12] <ruggles> basically audio decoding will be like video decoding. AVPacket in, AVFrame out, output buffers handled internally. [17:43:15] <Kovensky> but then if I want to cache the output I need to do a memcpy? [17:44:03] <ruggles> only if you use the default get_buffer() [17:44:10] <ruggles> like video decoding [17:46:19] <Kovensky> hm [17:46:42] <Kovensky> I guess I'm better off not caching then, and writing a filter that does the caching if needed [17:47:31] <Kovensky> if I get around to it, that is :X [17:47:38] * Kovensky has thought of several things to reduce his procrastination but he hasn't gotten around to trying them yet [17:48:00] <gnafu> Procrastinators unite! Tomorrow... [17:53:09] <Kovensky> gnafu: nah, maybe next week... [17:53:28] <gnafu> No, next week doesn't work for me. How about early April? [17:55:00] * Kovensky wonders if he should answer that now or later [17:58:23] <gnafu> Better give it some thought and get back to me. [18:27:43] * elenril sees his patches still not applied [18:29:03] <mru> elenril: would you mind marking your old patches in patchwork? [18:36:46] <elenril> done [18:37:58] <mru> thanks [18:52:02] * gnafu sees that someone finally said something about top-posting in the JPEG 2000 ML thread... [18:52:24] <gnafu> :-D [18:56:00] <Dark_Shikari> gg [20:28:49] <spaam> yssna på musik och irka.. nej tack. [20:29:52] <spaam> hmm [20:40:13] <Kovensky> spaam: what's with the BlackSpeech [20:40:36] <spaam> Kovensky: my internet connection did lag ;S [20:41:07] <spaam> and i was going to write that in another channell.. [21:18:54] <saste> mru: there are no checks if pkg-config fails (e.g. in case of missing libs) [21:19:11] <saste> configure succeeds but then linking fails [21:19:24] <mru> example? [21:19:47] <saste> librtmp... I just upgraded and I hadn't libssl installed [21:20:06] <saste> I can see the pkg-config error message on the output but configure exits with 0 [21:20:26] <mru> doesn't the link check fail? [21:20:40] <saste> no [21:20:52] <mru> why not? [21:21:21] <saste> dunno ... going to check the log [21:30:27] <CIA-15> ffmpeg: Anssi Hannula <anssi.hannula(a)iki.fi> master * r7e06e0ede3 ffmpeg/libavcodec/dca.c: [21:30:27] <CIA-15> ffmpeg: dca: use EXT_AUDIO_ID field to determine core extensions [21:30:27] <CIA-15> ffmpeg: This avoids the core substream extensions scan when the EXT_AUDIO_ID [21:30:27] <CIA-15> ffmpeg: field indicates no extensions or only unsupported extensions. The scan [21:30:27] <CIA-15> ffmpeg: is done only if the value of EXT_AUDIO_ID is unknown or indicates a [21:30:28] <CIA-15> ffmpeg: present XCh extension which we can decode. [21:30:29] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [21:36:10] <saste> mru: http://pastebin.com/b2Tmi2VA [21:36:23] <saste> bah a weird opencv / librtmp interaction [21:36:46] <saste> --enable-librtmp fails... --enable-librtmp --enable-opencv doesn't [21:38:39] <mru> hard to guard against that [21:39:44] <saste> mru: anyway it's a minor and unlikely bug.. maybe a preventive check on the result of pkg-config may help [21:40:03] <mru> perhaps [21:40:36] <mru> I'll consider it if we run into more of these [21:40:43] <mru> otherwise it's just clutter [21:40:54] <mru> and you know I'd rather not use pkgconfig at all [21:51:20] <Flameeyes> saste: uhm, how do you install librtmp? [21:52:38] <saste> Flameeyes: I have a local install with --prefix=$HOME [21:52:55] <Flameeyes> saste: ah, hm [21:53:14] <Flameeyes> 'cause if it came from a distro I'd have told you to kick them for not depending on openssl/libssl-dev and variants [22:34:19] <BBB> cartman: any progress? [22:35:53] <spaam> BBB: cartman is not here.. [22:36:09] <BBB> tab completion works for me [22:36:27] <spaam> not for me :S [22:36:45] <spaam> cant find him in the nicklist.. [22:36:56] <mru> no cartman here either [22:37:09] <spaam> 170210 -!- cartman [~ismail@kde/ismail] has quit [Quit: good day] [22:37:21] <spaam> last thing i have about him.. [22:37:44] <spaam> thats ~6h ago... [22:39:13] <BBB> hm [22:39:18] <BBB> why does tab completion work then? [22:39:24] <BBB> the irc bouncer must be screwed up [22:39:28] <mru> bad irc client? [22:39:38] <BBB> bouncer, not client [22:39:46] <BBB> what shall I do today... [22:39:57] <mru> you're using some nasty mac irc client [22:40:01] <BBB> baby sleeps, clang bug report submitted and delegated to cartman [22:40:16] <kierank> BBB: merge ffmpeg-mt ;) [22:40:18] <BBB> it's not nasty, it has pretty colors [22:40:29] <BBB> kierank: astrange asked me to hold, one bug he's working on [22:40:36] <mru> help him [22:41:00] <astrange> read the timestamp thread [22:41:13] <BBB> astrange: I'm demotivated to fix timestamps [22:41:20] <BBB> I'll work on ffmpeg-mt though [22:43:28] <BBB> astrange: sample + command to reproduce bug? [22:43:31] <BBB> I can try [22:43:54] <astrange> http://samples.mplayerhq.hu/V-codecs/HuffYUV/angels_480-huffyuvcompress.avi ffplay -threads 3 [22:45:45] <saste> mru: libcvaux required by libopencv links against librtmp [22:46:00] <saste> mru: so the linking test doesn't fail when libopencv is installed and enabled [22:46:11] <mru> so you do have librtmp? [22:46:29] <mru> sounds like your pkgconfig is busted somehow [22:46:35] <saste> mru: yes but pkg-config was complaining because of the missing libssl [22:46:50] <mru> so do you have it or not? [22:46:54] <saste> mru: no result -> no librtmp flags -> linking failure [22:47:05] <mru> so how did the link test pass? [22:47:45] <saste> mru: the libopenc test added the libcvaux flags to the linker [22:48:08] <mru> how can the configure test pass and the real link fail? [22:48:46] <saste> mru: libcvaux links dinamically against librtmp [22:48:59] <mru> you're still not answering the question [22:49:15] <mru> why do you get an error if the libs are there? [22:49:54] <saste> mru: pkg-config fails -> no output -> no librtmp flags added [22:50:02] <saste> mru: so the configure linking test fails [22:50:15] <mru> but you said it passed [22:50:53] <saste> mru: sorry i've been confusing... it passes with --enable-librtmp --enable-libopencv [22:51:00] <mru> yes [22:51:07] <mru> and then what? [22:51:20] <mru> is there a case where configure succeeds and final link fails? [22:51:25] <mru> if no, there is no problem [22:51:31] <mru> if yes, there is a problem on your computer [22:53:36] <mru> now checking pkgconfig return status might be a good idea [22:53:48] <mru> but your patch isn't the best way to do that [22:57:08] <saste> mru: http://pastebin.com/nBR9HjUj [22:57:48] <saste> mru: anyway feel free to fix the patch of suggest how to improve it [22:58:06] <mru> I will, but not tonight [22:58:32] <saste> no hurry [23:05:44] <BBB> astrange: in ff_thread_get_buffer(), it seems one thread is waiting in pthread_cond_wait(&p->progress_cond, &p->progress_mutex);, with p->parent->buffer_mutex held, and the other thread is blocking in pthread_mutex_lock(&p->parent->buffer_mutex); [23:07:27] <BBB> (with -threads 2 it hangs here too) [23:10:16] <BBB> astrange: is that p_cond_wait() waiting for some other thread to actually "do" the get_buffer()? [23:10:21] <BBB> astrange: and if so, where is that code? [23:12:55] <astrange> yes. it's at the end of submit_frame() [23:13:24] <astrange> ah, i see in my backtrace that the thread which should be doing that (the one that called decode_video) somehow got past there [23:13:31] <BBB> ah, submit_packet() [23:14:17] <BBB> that one is in while (p->state != STATE_INPUT_READY) [23:14:17] <BBB> pthread_cond_wait(&p->output_cond, &p->progress_mutex); [23:14:20] <BBB> I think [23:14:27] <BBB> hm, baby wants a bottle [23:14:30] <BBB> brb [23:18:18] <BBB> astrange: so do you have time to fix it or should I hack a get_buffer() in that wait (and possibly others over there also)? [23:21:02] <astrange> i can look [23:23:17] <kierank> is there any information about how to write a custom get_buffer? [23:23:36] <mru> kierank: probably not [23:24:04] <mru> kierank: I couldn't find any at least [23:24:27] <mru> I did figure it out in the end [23:26:11] <kierank> chromium has one but it's c++ :/ [23:26:27] <mru> feel free to look at omapfbplay [23:29:47] * kierank looks [23:30:35] <mru> note that it probably only works with yuv420 format [23:32:40] <astrange> ffplay contains one [23:32:55] <mru> good luck understanding ffplay [23:37:23] <BBB> astrange: so how come vp3 doesn't suffer from this? I know it's a race but a pretty obvious one, is get_buffer() "thread-safe" for vp3? [23:39:01] <astrange> presumably it's to do with the difference between inter/intra codecs (what the patch 1/2 does) [23:47:41] <BBB> also there's two conds, output_cond and progress_cond, can the two conflict and lead to deadlocks? they share the same mutex... [23:49:04] <mru> a single mutex can never deadlock [23:52:06] <BBB> if multiple threads lock on it, but use different conds to signal the other to wake up [23:52:13] <BBB> then one signals, but the other doesn't wake up [23:53:11] <mru> the mutex is unlocked while blocking on the cond [23:53:13] <BBB> I guess it's not relatd to the mutex but to the conds then [23:53:29] <BBB> right, what I meant is that there's a lot of conds and I'm not sure the logic always makes sense [23:53:33] <BBB> unrelated to the mutex [23:53:48] <mru> it might not make sense, but one mutex alone can never deadlock

1 0

IRC log for 2011-02-23
by irc＠mansr.com 24 Feb '11

24 Feb '11

[01:34:09] <saintdev> awww, he just left http://danbooru.donmai.us/post/show/859807 [01:37:41] <saintdev> gah, keep doing that [05:17:52] <saintdev> peloverde: ping [05:31:27] <saintdev> actually, also ruggles: ping [06:52:07] <saintdev> lol "(float)1.0f" [06:52:41] <superdump> where's that? [06:52:51] <saintdev> 3gpp source [06:53:17] <saintdev> superdump: check your blog [06:53:39] <superdump> already responded [06:53:55] <saintdev> i guess emails are off :/ [06:54:09] <superdump> i'll check [06:55:05] <saintdev> superdump: dmcrypt is a gentoo init script included with the cryptsetup packages to handle automic setup/open/close of encrypted volumes [06:55:19] <saintdev> check out /etc/conf.d/dmcrypt [06:56:00] <saintdev> *automatic even [06:59:21] <superdump> saintdev: interesting... [06:59:25] <saintdev> superdump: i use it for encrypted swap [06:59:29] <superdump> is that only in openrc or in older stuff? [06:59:53] <superdump> i just had a look through and it seems like it could do what i want quite simply [07:00:27] <superdump> although... it's in /etc [07:00:34] <saintdev> afaik openrc, but the scripts belong to sys-fs/cryptsetup [07:00:48] <superdump> so i need to unlock root before i can access this [07:01:02] <saintdev> yeah, that's why i don't know if it can handle encrypted root [07:01:19] <saintdev> probably not, but you can use it for the other partitions/swap [07:01:52] <superdump> i don't think i really had to do anything for the other partitions as they're all lvm volumes inside the crypt partition [07:02:08] <superdump> once the crypt partition is unlocked, lvm does the rest [07:02:19] <saintdev> oh, you're doing lvm on top of the encrypted partition [07:02:20] <superdump> (though it doesn't seem to be unmounting them properly at the end) [07:02:23] <superdump> yes [07:02:53] <superdump> not really necessary as it's a laptop and i just have root, home and swap in there, but hey [07:03:45] <superdump> it means i only have to remember and type one passphrase [07:05:59] <superdump> hmm [07:06:01] <saintdev> also theoretically ctr mode can be faster than cbc mode. not sure if the actual implementation is or not [07:06:29] <superdump> i don't see any options anywhere to make wordpress send email to users who commented on a post [07:06:36] <superdump> only to me [07:07:37] <saintdev> lol, and i have almost nothing in my control panel :/ [07:09:06] <superdump> hrm [07:09:09] <superdump> sorry about that [07:09:39] <saintdev> i can see your askimet stats, though! [07:09:40] <saintdev> lol' [07:10:03] <superdump> you can? [07:10:12] <superdump> brooooooken [07:10:18] <superdump> how? [07:10:31] <saintdev> clicking on Dashboard from my control panel [07:51:37] <cartman> moin [08:24:57] <saintdev> we lost that netsplit, big time [08:26:29] <wbs> indeed [08:32:41] <pJok> kshishkov, not if using a cattleprod [08:33:54] <KotH> does saintdev have kids? if so, using a catleprod would be a moderate psychological pressure ;) [08:34:21] <kshishkov> KotH: no, he seems to be a good developer [08:34:26] <saintdev> what were you guys talking about, i ended up on the loosing side of the netsplit [08:34:47] <saintdev> getting me to fix aacenc? [08:34:52] <kshishkov> saintdev: how to make you into making ffaacenc being faster and better than faac [08:35:03] <kshishkov> saintdev: before 0.7 release preferably [08:35:07] <saintdev> o.O [08:35:39] <KotH> kshishkov: so no gf either? damn! [08:35:57] <saintdev> pe = inf, desired = 613.749878 [08:35:57] <saintdev> en = 4149235.750000, thr = 25190834.000000, nz = 3.105415, act = 3.105415, ah = 2 [08:35:57] <saintdev> en = 3235864.000000, thr = 402199.812500, nz = 12.661351, act = 12.661351, ah = 2 [08:35:58] <saintdev> ;) [08:36:29] <kshishkov> looks like debug dump from ffaacpsycho [08:38:04] <saintdev> that's what i'm currently looking at in my console ;) [08:39:19] <superdump> what do each of the values mean? [08:39:32] <kshishkov> they are meaningless [08:39:41] <kshishkov> though somehow realted to signal energy [08:40:11] <saintdev> pe = perceptual entropy, desired = target pe [08:41:21] <saintdev> en = scalefactor energy, thr = scalefactor threshold, nz = number of non-zero spectral lines, act = number of active spectral lines, ah = hole avoidance flag [08:43:51] <kshishkov> saintdev: have you tried rewriting psymodel from scratch after 3GPP spec? [08:44:22] <saintdev> kshishkov: no need. what's there is correct, just incomplete [08:44:40] <peloverde> saintdev: I'm sure at some point people will mention some details about CELT preserving energy in all bands, I recommend you ignore them until you have something 3GPPish working first [08:44:42] <saintdev> also the spec is incomplete [08:46:12] <saintdev> peloverde: are you against adding feedback between the coder and the psymodel to FFPsyContext? [08:46:49] <peloverde> I'm against being more ambitious than 3GPP until we have something working [08:46:55] <saintdev> the coder needs the frame-wide PE, and the psymodel needs the state of the bitreservoir [08:47:42] <peloverde> there is nothing wrong with the psymodel having access to the bit reservoir [08:48:26] <saintdev> i just want to make sure putting it in FFPsyContext is ok. [08:49:03] <peloverde> yeah [08:49:38] <kshishkov> s/having access/making encoder report/ [08:52:24] <saintdev> yay, pe is no longer â [08:57:22] <ubitux> http://undeadly.org/cgi?action=article&sid=20110223045047 [08:59:18] <kshishkov> saintdev: it's infinity when some NAN occures somewhere (and with my sloppy coding and poor understanding of standards...) [09:01:34] <Tjoppen> hm [09:01:51] <Tjoppen> does ffmpeg indeed only do straight filter graphs? [09:02:14] <saintdev> kshishkov: it was my fault. stupid bug. [09:02:16] <Tjoppen> reading over the it seems that way [09:03:54] <kshishkov> saintdev: but in most cases you can blame it all on me [09:04:33] <saintdev> oh wow, even in functions that i wrote completely myself! thanks! [09:12:31] <saintdev> well, that's...decidedly worse [09:43:24] <Kovensky> http://i.imgur.com/ZyeCO.jpg [09:45:19] <kshishkov> meh [09:54:14] <Kovensky> mru: what the... britland is changing timezones? [09:54:43] <kshishkov> Kovensky: they are obviously following Russian example [09:55:37] <kshishkov> Kovensky: see http://en.wikipedia.org/wiki/Decree_time too [09:56:57] <Kovensky> Ð²ÑÐµÐŒÑ is time? [09:57:00] * KotH doesnt mention that .fr should actually move it's time zone back one hour [09:57:04] * Kovensky will probably promptly forget it in 10 minutes [09:57:17] <kshishkov> Kovensky: yep [09:57:41] <Kovensky> why so many ya/yo/ye sounds, they're annoying to pronounce :D [09:57:47] <kshishkov> KotH: sounds wrong. French people should adjust timezone by 79 minutes [09:58:11] <kshishkov> Kovensky: try French with its Ã©,Ãš and Ãª [09:58:40] <Kovensky> well, I know Ã© and Ãš because the diacritics happen to do exactly the opposite of what they do in portuguese [09:58:43] <Kovensky> no idea about Ãª though [09:59:21] <kshishkov> it's long e IIRC [09:59:33] <Kovensky> actually... not very sure about Ã© either, since there's no ` diacritic in portuguese, and when it existed, it only applied to a, and it didn't change its sound [09:59:55] <ubitux> 'Ãª' sounds a bit like the "heh?" in japanese [10:00:13] <ubitux> or like a sheep, as you prefer [10:00:21] <Kovensky> baa [10:01:33] <kshishkov> wikipedia says it's a tombstone for dead consonants [10:01:43] <kshishkov> http://en.wikipedia.org/wiki/Circumflex#Deletion [10:09:11] * siretart likes http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-… [10:11:15] <kshishkov> time to switch to Ruby? [10:11:43] <jannau> or C++ [10:12:09] <kshishkov> that would generate much profanity by itself [10:26:46] <pross-au> They didnt cover common lisp [10:28:08] <kshishkov> it's hard to swear with parentheses [10:28:23] <pross-au> (Asshole) [10:30:13] <kshishkov> nay, that's too lame [10:30:30] <kshishkov> at least Russians seldom swear [11:43:37] <mru> the total amount of profanity is constant [11:43:53] <mru> those languages with little of it in comments simply have it in the code [11:45:19] <kshishkov> mru: there's Russian where people can completely speak in profanities [11:46:01] <kshishkov> computer code analogy would be probably corporate code [11:47:24] <BBB> siretart: that mostly sounds what my lawyers came to conclude also - but so you think the license allows it to be redistributed? [11:48:02] <BBB> siretart: not that I care a lot of course, all I care about is that lavcodec+faac is not allowed to be linked together [11:48:35] <kshishkov> BBB: your lawyers? You're very evil man then [11:50:59] <BBB> SFLC :) [11:51:03] <BBB> they're "good" lawyers [11:51:21] <siretart> BBB: TBH, I don't care that much either, but this is the conclusion of the ubuntu technical board [11:52:28] <siretart> I'm currently thinking about an answer to that [11:53:06] <BBB> from my point of view, you can tell them I'm happy to see they concluded libavcodec cannot legally link to libfaac :) [11:53:22] <siretart> nobody really proposed that anyway [11:53:36] <BBB> DonDiego: please look at https://roundup.ffmpeg.org/issue455 [11:54:09] <siretart> BBB: would you still veto a libfaacbin wrapper that loads faac bin at runtime, similar to other wrappers we already have? [11:54:17] <BBB> yes [11:54:34] <BBB> the libfaac glue code can stay [11:54:36] <kshishkov> maybe other binary loaders as well [11:54:37] <BBB> the code is not illegal [11:54:44] <BBB> neither is building it yourself [11:54:49] <BBB> but you cannot redistribute the combination [11:55:11] <siretart> that's not what's happening [11:55:34] <siretart> they are still distributed seperately [11:55:38] <BBB> you're trying to create a libfaacbin so people can compile/install libfaac themselves and ffmpeg will pick it up [11:55:48] <BBB> I don't think that is the right message to send to people [11:55:58] <BBB> the right message is: please help us make ffaacenc better [11:56:12] <BBB> but if others think it's a good idea I can be overruled of course [11:56:30] <BBB> I don't like the libfaacbin idea, but I hate vetos more :) [11:56:33] <siretart> we trying to send that message out for years. in reality, people rather fetch (broken) packages that illegally dynamically link against libfaac [11:56:42] * kshishkov doesn't like any binary lib loader [11:56:44] <siretart> I'd like that to stop. fast. [11:57:05] <kshishkov> siretart: I can tell you how to get to Nero [11:57:24] <siretart> kshishkov: I doubt they would help to improve ffaac [11:57:34] <mru> kshishkov: shall I tell them about the backdoor I left? :) [11:58:18] <kshishkov> mru: next time they invite you to work [12:01:06] <kshishkov> siretart: well, Ivan Dimkovic said that Polish guy virtually rewrote faac making it much better that original Menno's [12:01:39] <mru> doesn't matter, as long as that file with the bad licence is there [12:02:12] <kshishkov> mru: well, faac AUTHORS file contains your name too! [12:04:21] <mru> what? [12:04:21] <siretart> kshishkov: how does this help getting ffaac improved? [12:05:17] <kshishkov> mru: yep, in contributors section [12:05:41] <mru> I must have sent a patch some time [12:06:46] <kshishkov> siretart: in no way [12:06:56] <kshishkov> siretart: but maybe you can work on improving it? [12:07:23] <kshishkov> siretart: I suspect it's on reference decoder level, i.e. any change would only improve it [12:08:17] <wbs> BBB: would you mind pushing the win/errno patch you queued yesterday, so we could close the roundup ticket? [12:08:32] <siretart> kshishkov: I put it on my list [12:08:46] <siretart> kshishkov: but don't expect me to get to that in the next 2 years ;-) [12:10:34] <kshishkov> BTW, what's the status with Bink-b audio patches? [12:22:01] <BBB> wbs: done [12:22:20] <CIA-15> ffmpeg: Martin StorsjÃ¶ <martin(a)martin.st> master * r28c4741a66 ffmpeg/ (8 files in 2 dirs): (log message trimmed) [12:22:20] <CIA-15> ffmpeg: libavformat: Remove FF_NETERRNO() [12:22:20] <CIA-15> ffmpeg: Map EAGAIN and EINTR from ff_neterrno to the normal AVERROR() [12:22:20] <CIA-15> ffmpeg: error codes. Provide fallback definitions of other errno.h network [12:22:20] <CIA-15> ffmpeg: errors, mapping them to the corresponding winsock errors. [12:22:21] <CIA-15> ffmpeg: This eases catching these error codes in common code, without having [12:22:22] <CIA-15> ffmpeg: to distinguish between FF_NETERRNO(EAGAIN) and AVERROR(EAGAIN). [12:22:22] <BBB> wbs: sorry I hadn't done it before, I had it patch -p1'ed instead of git am'ed, so it didn't show up as a queued patch, my fault [12:22:39] <mru> why would you do that? [12:22:40] <wbs> BBB: np, and thanks for pushing [12:22:48] <BBB> mru: accident [12:22:58] <mru> strange accident [12:23:06] <BBB> not sure why I did that [12:23:31] <BBB> kshishkov: if they're OK'ed, I can apply [12:26:19] <kshishkov> BBB: let's see... [12:26:36] <BBB> I first have to apply elenril's patches though [12:26:42] <BBB> I still don't like put_tag() [12:27:35] <kshishkov> you prefer pull_tag()? [12:28:50] <BBB> I feel that with proper work, avio_wl32() could write 4 bytes at once, and most put_tag() uses could then use avio_wl32() with a MKTAG fourcc, possibly as a macro so it's easier to write [12:29:25] <BBB> for the few remaining cases, we could use avio_put_str() (which should be avio_write_str()), with an extra argument indicating if we want to write the terminating zero [12:29:59] * elenril doesn't really like adding one more argument [12:30:07] <elenril> but we can decide that later [12:31:55] <BBB> we can keep that version internal [12:32:12] <BBB> just like put_tag [12:35:39] <mru> has anyone looked into that vp8 clang bug? [12:36:33] <kshishkov> we have cartman for clang [12:38:37] <mru> yeah, but has he looked at it? [12:41:11] <mru> elenril: http://abstrusegoose.com/342 [12:43:22] <kshishkov> mru: rather silly question. He should have started with physical meaning of acceleration - it's meters divided by SQUARE SECONDS!!! [12:44:12] <mru> there's more than one time dimension, you know [12:44:26] <mru> a square second is one second in each of two time dimensions [12:44:34] <kshishkov> explain that to a man who rejects math [12:45:21] * Kovensky prefers round seconds [12:45:51] * mru multiplies Kovensky's seconds by pi [12:45:59] <mru> Kovensky: better? [12:46:13] * Kovensky confuzzled [12:47:32] <mru> Kovensky: when's your birthday? I was thinking of getting you a square pie plate [12:47:47] <Kovensky> lol [12:58:23] <BBB> cartman: ping [12:58:28] <BBB> mru: I've told him how to debug it [12:58:31] <BBB> mru: he didn't do it [12:59:05] <BBB> michael kostylev gave me shell on a system having that bug [12:59:09] <BBB> maybe I should look at it [12:59:42] <BBB> mru: also, are you sure vc1 idct can be done in words/17bit? because if counting from 12bit input (see specs), range can go up to 23-24 bits, if I count correctly [13:01:44] <kshishkov> BBB: he's implemented NEON VC-1 transform, I think, so he should know [13:01:58] <mru> I could have made a mistake [13:02:27] <mru> such as believeing ivan when he said 17 bits was enough [13:02:32] <mru> -e [13:02:55] <mru> kshishkov: look at your mmx/sse code [13:03:01] <mru> iirc it uses 16 bits all the way [13:03:08] <mru> and hopes for the best [13:04:15] <kshishkov> mru: it wasn't mine, I did altivec only [13:04:28] <mru> kshishkov: yours as in your employer's [13:04:59] <cartman> BBB: I am busy with real $job atm, clang thing is not easy to debug (at least for me) [13:06:01] <kshishkov> mru: yes, that one seems to be pure 16-bit [13:07:47] <kshishkov> probably because everybody ignores that BS about overlap transform extending range to 10 bits [13:07:57] <kshishkov> s/transform// [13:08:29] <mru> the spec says input to the transform is 12-bit signed [13:08:40] <mru> output of first stage is 13-bit signed [13:08:52] <mru> says spec [13:09:15] <kshishkov> indeed [13:09:23] <mru> and output is 10-bit signed [13:09:45] <BBB> I don't see the output being 13-bit [13:09:54] <mru> the spec says it must be [13:09:56] <BBB> if you take the first line, 16+15+9+4*some input [13:10:04] <BBB> then that's 12-bit*(16+15+4+9) [13:10:09] <BBB> =12+6 bits [13:10:11] <BBB> =18 bits [13:10:16] <kshishkov> BBB: intermediate matrices are in -4096..4095 range - i.e. 13 bits [13:10:29] <BBB> first part similar [13:10:33] <BBB> so input before >>3 is 19 bits [13:10:37] <BBB> so after >>3 16 bits [13:10:39] <BBB> how did it become 12? [13:10:47] <kshishkov> clipping [13:11:05] <BBB> hm... [13:11:11] <BBB> so is it all done in words [13:11:20] <BBB> or is it done in dwords and then intermediate clipping to words? [13:11:30] <BBB> as in, how much can I clip? [13:11:37] <mru> anyhow, in the second stage the coeffs sum to 90 [13:11:57] <kshishkov> and 96 in the first stage [13:11:58] <BBB> 90 *13bits > 16 bits [13:12:02] <BBB> so I don't see it fitting [13:12:07] <mru> you're right, it doesn't [13:12:09] <BBB> 90 = 7 bits [13:12:10] <BBB> so it's 20 [13:12:17] <BBB> ok, I'll do it in dwords then [13:12:45] <BBB> altivec code is in ints btw [13:12:46] <mru> I had some doubts, but ivan said it was fine... [13:12:54] <BBB> ivan just told me it wasn't fine [13:13:02] <mru> different ivan [13:13:04] <BBB> oh [13:13:04] <BBB> ok [13:13:19] <mru> one of the ivans in kshishkov's office [13:14:39] <BBB> as in, there's ten of them, and this is #7? [13:15:07] <mru> not quite that many [13:15:29] <kshishkov> aac one and smoking one [13:24:13] <lu_zero> o_O [13:24:18] * lu_zero is still on break [13:25:56] * iive wonders what is the family name of the smoking one [13:26:15] <BBB> "cigarette man" [13:26:37] <kshishkov> BBB: nope, he prefers cigars [13:26:55] <kshishkov> iive: not Bulgarian [13:35:59] <elenril> mru: spin is a certain feature of our mathematical models of reality [13:36:05] <elenril> it doesn't get much better than that [13:36:07] <mru> elenril: iKnow [13:36:30] <kshishkov> elenril: I always remeber Feynman's quote about electron [13:36:35] <kshishkov> *remember [13:37:17] <cartman> kshishkov: feel free to share Feynman quotes [13:38:04] <kshishkov> cartman: "when I think about an electron I imagine a bunch of graphics and formulae" [13:38:27] <cartman> lol :> [13:38:50] <kshishkov> that's the only way to imagine it properly [13:39:27] <cartman> true :) [13:48:06] <lu_zero> ^^; [13:49:18] <elenril> nah, electron is a rotating yellow point [13:49:47] <kshishkov> * NielsBohr stabs elenril [13:49:50] <mru> actually, it's white now [13:51:09] <mru> sorry, old kth joke [13:52:07] * kshishkov remembers SL joke on KTH [13:52:14] <elenril> kth? [13:52:24] <mru> kth.se [13:53:12] <elenril> meh, engineers [13:53:39] <pJok> elenril, spin is what politicians do... [13:53:56] <deppan> engineers are cool [13:53:58] <deppan> especially kth ones [13:54:23] <elenril> theoretical physicists are way cooler [13:54:29] <deppan> no [13:54:33] <mru> bullshit [13:54:39] <mru> engineers actually do shit [13:54:46] * kshishkov is also an engineer from KTH but different one [13:54:52] <deppan> theoretical physicists just whines and claims stuff wont work [13:55:01] * deppan has watched lots of stargate [13:55:01] * cartman is distinguished slacker [13:55:13] <mru> engineers get stuff done, whether possible or not [13:55:21] <deppan> många kth'are här eller? [13:55:33] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BeyondTheImpossible [13:55:39] <kshishkov> deppan: those are experimenters, theoreticians don't care about real world at all [13:55:41] <mru> deppan: minst tvÃ¥ iaf [13:56:00] <deppan> tre då+ :) [13:56:04] <mru> tre? [13:56:30] <deppan> kshishkov också? [13:57:05] <mru> kshishkov Ã€r frÃ¥n kharkov [13:57:06] <kshishkov> deppan: for me it was Kharkivska Tekniska (inte-so-)HÃ¶gskolan [13:57:22] <mru> deppan: elektro? [13:57:25] <deppan> oh. [13:57:27] <deppan> mru: nä data [13:57:30] <mru> meh [13:57:47] <deppan> håller på med exjobbet atm [13:58:55] <spaam> kth.. tacka vet ja bth ;P [13:59:12] <spaam> </ironi> [13:59:28] <elenril> so when are the engineers who actually do stuff going to commit my patches [13:59:43] <elenril> oh wait, BBB isn't an engineer [13:59:47] <elenril> makes sense now [13:59:50] <spaam> hohohoh [14:17:53] <Dark_Shikari> http://news.ycombinator.com/item?id=2253945 [14:20:12] <mru> solution: be that "perfect candidate" instead [14:20:57] <Dark_Shikari> That's the best bet, indeed~ [14:21:22] <mru> and the best jobs are never advertised at all [14:21:30] <Dark_Shikari> Except because of #3. [14:21:37] <mru> those are not the best jobs [14:21:49] <mru> simply because the best jobs are not in companies with such policies [14:21:58] <Dark_Shikari> true. [14:22:23] <lu_zero> or the best job is for hr-type and the job is reorganize that part [14:22:50] <mru> self-obsoleting jobs... [14:23:08] <mru> do your job too well, and you won't have one [14:24:16] <lu_zero> you do your job well and move to something else [14:24:27] <lu_zero> then if the need arise they'll call you back =P [14:32:21] <kshishkov> lol at MN's mail: ".. but if you think[,] you are smarter than the previous people who worked on it." [14:37:24] <mru> he has a point [14:37:42] <mru> and jpeg2k is dead anyway [14:38:00] <mru> or is it still used by dcinema? [14:38:45] <Dark_Shikari> used by "professional" shit [14:38:53] <Dark_Shikari> i.e. still matters despite being awful [14:38:56] <kshishkov> but it's _wavelets_! [14:39:30] <mru> like any codec, with a low enough quantiser it gives decent picture [14:39:46] <mru> except maybe theora [14:40:02] <mru> theora has some really ugly artifacts [14:40:28] <kshishkov> mru: it's called design [14:40:52] <Dark_Shikari> theora should work fine as well [14:40:57] <Dark_Shikari> unless you're using like some version using the old VP3 encoder [14:41:02] <Dark_Shikari> which had insane fdct/idct mismatch [14:41:04] <Dark_Shikari> due to being written by on2 [14:41:50] <mru> sure, but haven't you noticed the peculiar artifacts you get with theora? [14:41:58] <mru> they're not like anything I've seen elsewhere [14:42:02] <Dark_Shikari> eh? nothing that looks atypical for an 8x8dct format [14:42:24] <Dark_Shikari> Pre-1.2 it had some really obnoxious artifacts at low rates in motion due to overzealous ungated skip decision [14:42:43] <kshishkov> mru: scalable JPEG? [14:43:05] <mru> Dark_Shikari: it uses a slightly different dct than the mpeg family [14:43:10] <mru> maybe that's the reason [14:43:12] <mru> I don't know [14:43:12] <Dark_Shikari> it's still an 8x8dct [14:43:23] <mru> or maybe it's the mismatch you mentioned [14:43:24] <Dark_Shikari> sure it's not exactly the same but neither is h264's or vc-1's [14:43:29] <Dark_Shikari> mismatch was fixed years ago [14:43:38] <mru> h264 isn't even a dct strictly speaking [14:43:49] <Dark_Shikari> It's close. Vaguely. [14:43:56] <mru> it has similar properties [14:44:03] <mru> which makes it a good choice for video coding [14:44:06] <mru> but it's not a dct [14:44:40] <Dark_Shikari> how close to a dct does it have to be for you to call it a dct? [14:44:51] <mru> dct has a precise mathematical definition [14:44:57] <mru> either something is one or it isn't [14:44:59] <Dark_Shikari> so simpledct isn't a dct? [14:45:11] <Dark_Shikari> it's not quite exactly equivalent. [14:45:30] <mru> it uses approximate values for the coeffs [14:46:01] <skal> at least it's orthogonal [14:46:05] <skal> could be worse [14:46:18] <mru> the h264 transform is all shifts and adds [14:46:22] <mru> no multiplications [14:46:27] <mru> with is wonderful to implement of course [14:46:33] <mru> but it's not a dct by a far cry [14:46:41] <Dark_Shikari> <insert snarky comment about how multiplications are just shifts and adds> [14:46:50] <mru> right [14:47:00] <mru> shifts by _one_ [14:47:27] <mru> coeffs of 1, 2, and 3 don't make a dct [14:47:42] <Dark_Shikari> the h264 dct has more complex coeffs than that [14:47:49] <Dark_Shikari> they're just factored into quant/dequant instead [14:48:43] <kshishkov> look at VC-1 [14:49:29] <mru> a dct decomposes a signal into a sum of cosines [14:49:37] <mru> a transform that doesn't do that isn't a dct [14:49:59] <Dark_Shikari> You can factor multiplication factors from a DCT into quant/dequant too [14:50:00] <Dark_Shikari> i.e. a real DCT [14:50:03] <Dark_Shikari> Not all of them, but many of them [14:50:09] <mru> first stage yes [14:50:12] <Dark_Shikari> And last stage [14:50:15] <Dark_Shikari> iirc [14:50:26] <Dark_Shikari> Oh, depends what you're calling first and last of course. [14:50:45] <mru> first stage for inverse, last stage for forward [14:50:56] <mru> or decode/encode if you will [14:50:56] <Dark_Shikari> yeah [14:52:59] <mru> I don't see any cosine-like coeffs in any stage of the h264 transform [14:53:33] <Dark_Shikari> http://cerezo.name/blog/2011/02/16/automatic-exploit-generation/ [14:53:57] <mru> only shifts by one or two and add/sub [14:53:59] <Dark_Shikari> a program that, given an input, finds vulnerabilities in said input program, and automatically generates exploits. [14:54:37] <mru> btw, is libjpeg or omx more likely to have a weird idea of dct? [14:56:04] <mru> plugging an omx idct into libjpeg needs a dc bias [14:59:09] <skal> jpeg's DC value is 0-centered [14:59:51] <mru> and mpeg is 128 [14:59:54] <mru> apparently [15:01:54] <skal> well, that's not counting with the various predictors [15:02:13] <skal> but yes [15:02:32] <Dark_Shikari> He's referring to the first block. [15:05:09] <BBB> elenril: why prevent deprecating symbols? [15:05:16] <BBB> elenril: I oppose that patch a little [15:05:51] <BBB> elenril: can't you just replace all put_tag by a pretty printed macro doing a avio_wl32(pb, MKTAG(str[0],str[1],str[2],str[3]))? [15:05:58] <BBB> elenril: otherwise I have to do it and I AM LAZY :-p [15:06:07] <BBB> elenril: plus all the stuff you just said [15:07:30] * Kovensky deprecates elenril [15:09:05] <elenril> BBB: ? [15:09:57] <BBB> elenril: instead of renaming put_tag and being silly, I'd like to get rid of it [15:10:02] <BBB> I think it's a silly function [15:10:19] <elenril> :effort: [15:10:26] <elenril> ok, i'll try [15:10:49] <BBB> how about for each non-four-letter one, we introduce an internal function called ffio_write_str(AVIOContext *pb, const char *str, int include_terminating_zero) [15:10:58] <elenril> btw [15:10:59] <BBB> then have avio_put_str() use that internally [15:11:06] <elenril> what to do about avio_put/get_strfoo [15:11:27] <BBB> and for each four-letter one have an internal macro ffio_write_fourcc() that calls avio_wl32() [15:11:38] <BBB> elenril: leave them for now [15:11:45] <BBB> naming is sub-ideal but it's ok, not a big deal [15:12:45] <BBB> we can change it if you feel like it, but then let's figure out if we want avio_write_str(AVIOContext *, const char *str) or avio_write_str(AVIOContext *, const char *str, int include_terminating_zero) [15:12:56] <BBB> important distinction [15:13:39] <elenril> meh, let's keep them [15:14:06] <BBB> :) [15:14:31] <elenril> yeah, i'm lazy [15:14:45] * BBB high-fives elenril [15:14:46] <elenril> can you commit url_fopen/fclose? [15:14:54] <BBB> I'll have a look [15:17:22] <BBB> they look good [15:17:24] <BBB> let me queue 'em [15:19:17] <BBB> queued [15:20:44] <elenril> avio_wl32(pb, MKTAG(str[0],str[1],str[2],str[3])) << will that work properly on all the weird archs? [15:22:05] <BBB> (str)[n] [15:22:07] <BBB> not str[n] [15:22:10] <BBB> (said mru) [15:22:18] <BBB> and yes it'll work on all weird archs [15:22:23] <BBB> MKTAG() automatically writes a LE tag [15:22:37] <cartman> where is av500 ? http://feedproxy.google.com/~r/Techcrunch/~3/e2gCRFfuUDs/ [15:31:16] <BBB> cartman: please find clang 2.9 bug thanks! :-p [15:32:04] <elenril> char tag[5]; put_tag(&tag[0]) << wtf [15:32:17] <cartman> BBB: I would if I could just fix this damn Android bug [15:35:58] <BBB> elenril: where? [15:36:08] <elenril> BBB: avienc [15:37:40] <ruggles> saintdev: you pinged? [15:38:10] <BBB> avi_stream2fourcc looks buggy with >10 streams [15:38:54] <mru> ruggles: isn't the past tense of "ping" "pang"? [15:39:00] <mru> compare "ring" [15:39:53] <ruggles> :) [15:41:19] <ruggles> google says it's "pinged" [15:41:33] <ruggles> first definition: hit with a pinging noise; "The bugs pinged the lamp shade" [15:41:57] * elenril pours some hate on mov [15:42:04] <mru> ruggles: different ping [15:42:25] <kshishkov> pingeth? [15:43:22] <kshishkov> mru: also http://www.learnersdictionary.com/search/ping [15:44:00] <mru> that's an archaic form [15:45:11] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r22a3212e32 ffmpeg/ (14 files in 2 dirs): [15:45:11] <CIA-15> ffmpeg: avio: rename url_fopen/fclose -> avio_open/close. [15:45:11] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [15:45:19] <CIA-15> ffmpeg: longstone <zhibing.min(a)hotmail.com> master * r4acc94e97a ffmpeg/libavformat/ (avi.h avienc.c): [15:45:19] <CIA-15> ffmpeg: avienc: fix AVI stream index for files with >10 streams [15:45:19] <CIA-15> ffmpeg: Fixes issue 2563. [15:45:19] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [15:46:51] <pJok> thou shalt not pingeth? [15:47:16] <kshishkov> "du ska inte pingar" even [15:47:35] <elenril> BBB: all the remaining uses of put_tag use constant strings [15:47:45] <elenril> so we can just put_buffer(sizeof()) [15:47:59] <elenril> no need to modify put_str [15:48:11] <BBB> elenril: really? [15:48:21] <BBB> elenril: if others are OK with that, then I am too [15:49:24] * elenril compiles [15:49:29] <BBB> and thanks for pointing out that avienc code to me [15:49:35] <BBB> I had a pending patch on roundup for that [15:49:41] <mru> elenril: sizeof("string") includes the null terminator [15:49:49] <elenril> iKnow [15:50:04] <mru> just checking, wasn't sure which you wanted [15:59:14] <elenril> BBB: patch sent [16:00:37] <BBB> awesome [16:02:00] <ruggles> kshishkov: is there any easy way to get the number of samples in a wavpack frame before the decoder starts writing the output? [16:02:14] <ruggles> the source is driving me crazy [16:02:22] <BBB> x?"AIFF":"AIFC" <- I wonder if the compiler does silly shit like MKTAG(x?'A':'A', etc.) [16:02:29] <ruggles> kshishkov: or even maximum number of samples [16:16:51] <BBB> elenril: commented [16:17:15] * BBB tihnks elenril will top our commit stats over 2011 [16:17:36] <spaam> cool guy [16:17:48] <spaam> BBB: who won last year? [16:17:56] <BBB> dunno [16:18:16] <BBB> mans, it seems [16:18:35] <BBB> (lines of code changed) [16:22:40] * mru goes to find some more tables [16:22:59] <mru> in fact, I have a patch messing with the twinvq tables somewhere [16:25:15] <merbzt> gotta love those [16:25:32] <merbzt> boom, ffmpeg got 500kb larger [16:25:42] <lu_zero> uhm? [16:25:50] <mru> my patch should make them a little smaller (compiled) [16:25:56] <mru> more efficient packing [16:26:08] <mru> perhaps I should dig it out again [16:27:40] <BBB> holy shit 500kb tables? [16:28:03] <BBB> does it load those tables if you don't actually use 'em? [16:28:21] <mru> depends on the OS [16:30:08] * mru tries to build ffmpeg with pcc, finds loads of bugs [16:30:11] <mru> in pcc [16:33:07] <lu_zero> pcc? [16:33:43] <mru> http://pcc.ludd.ltu.se/ [16:33:48] <lu_zero> http://pcc.ludd.ltu.se/news/ [16:33:52] <lu_zero> ok =) [16:35:42] <lu_zero> I wasn't aware it was still developed actively [16:36:02] <Flameeyes> decisions are made or taken? :| I never remember [16:36:18] <mru> made [16:36:30] <mru> actions are taken [16:36:32] <mru> and hostages [16:36:42] * elenril takes a cookie [16:36:43] <Flameeyes> thanks [16:36:59] <mru> cookies can also be made [16:37:51] * elenril prefers taking them [16:38:40] <Flameeyes> I think I'll go make some tea [16:48:05] <elenril> BBB: i'll send a separate patch for &tag[0] [17:01:35] <BBB> elenril: fine, I'll apply this then, looks good from my angle [17:05:16] * BBB stabs elenril for almost breaking fate [17:05:39] <elenril> what did i do again [17:06:02] <BBB> put_tag("FLV") != ffio_wfourcc() [17:06:14] <elenril> oops [17:06:17] <elenril> this is evil [17:06:22] <elenril> i thought i caught them all [17:34:29] <merbzt> http://www.h-online.com/open/news/item/Unicode-6-adds-astonished-face-11958… [17:35:46] * mru would use one but doesn't have the font [17:38:11] <merbzt> â [17:40:52] <kshishkov> ruggles: yes, it's in frame header [17:42:01] <ruggles> kshishkov: is the samples_left stuff just for multichannel? [17:43:02] <kshishkov> nope [17:43:19] <siretart> merbzt: for me that looks more like a turd than a snowmanâŠ [17:43:51] <kshishkov> ruggles: lossy wavpack files also tend to have more samples in a block than can fit default av buffer [17:45:00] <ruggles> ok, is the only thing samples_left is for? [17:45:50] <kshishkov> it's for signalling there are still some samples left undecoded in this block [17:46:04] <ruggles> and they're only left undecoded because of the output buffer size? [17:46:12] <kshishkov> yep [17:46:35] <ruggles> wow, that can go away completely with get/release_buffer() [17:46:56] <kshishkov> indeed [17:47:37] <ruggles> it looks like mkv mode and multichannel are the only cases where wavpack_decode_block() is called more than once for a frame. [17:47:50] <ruggles> and mkv mode has samples in the frame header [17:48:09] <kshishkov> all of them have\ [17:48:27] <kshishkov> mkv just stores them in first block, lavf demuxer - in all blocks [17:49:49] <kshishkov> and mono/stereo is just trivial case of multichannel :) [17:51:06] <ruggles> right, but it only has 1 block correct? the decoder sets frame_size = buf_size in the first loop iteration. [17:52:10] <kshishkov> yep [17:52:21] <ruggles> but multichannel has multiple blocks for multiple sets of 1 or 2 channels? [17:52:45] <kshishkov> yes [17:53:17] <ruggles> ok. so sample count is the same in each block, it just sets a different channel offset in the output buffer correct? [17:53:43] <kshishkov> yes [17:54:14] <ruggles> ok good. that samples_left part was throwing me for a loop... thanks for clarifying it. [17:55:18] <ruggles> nice solution for getting around the buffer size limit though :) [17:55:29] <kshishkov> it was rather obvious [17:55:44] <kshishkov> luckily it doesn't need that much of context to save [18:06:31] <therealgalen> irock: what's the status of your 10-bit ffmpeg code? is it usable for playing back h.264? [18:35:39] <saintd3v> ruggles: do you plan on using the psymodel at all (psymodel.{ch})? [18:37:44] <kshishkov> I fear it's not usable right now for AC3 [18:38:51] <saintd3v> kshishkov: well of course not [18:39:38] <ruggles> saintd3v: possibly if it improves it could be useful [18:40:12] <saintd3v> ruggles: i just mean the wrapper, not the stuff in aacpsy [18:41:59] <ruggles> saintd3v: oh, maybe. it depends on how complex a secondary psy model for ac3 would need to be. that just has critical band structure and function prototypes correct? [18:43:06] <ruggles> saintd3v: oh, the wrapper needs to support float samples though. now it just takes int16_t. [18:44:39] <saintd3v> ruggles: hmm, good point. [18:45:15] <kierank> hehe that mpeg-ts demuxer for flash remuxes the file into an flv in-memory [18:45:25] <kierank> I thought it was a bit dubious [18:45:48] <saintd3v> ruggles: if you're planning on using it, i was going to run some api changes by you (once i get back home). if not, i'll just do my own thing. [18:48:11] <ruggles> saintd3v: it would be good to see what you have in mind [18:51:12] <saintd3v> ruggles: ok, nothing big. just feedback from quantization for the state of the bitresevior (ac3 is pure cbr, isn't it?) and a way to pass frame-wide PE to quantization. [18:52:08] <mru> there's nothing to stop you changing bit rate between frames in ac3 [18:52:15] <ruggles> the ac3 encoder is currently pure cbr, and that's pretty much all that is used in practice. [18:52:16] <mru> don't know if that's allowed by the spec though [18:52:18] <ruggles> but it can be vbr [18:52:23] <ruggles> spec doesn't address it [18:52:29] <ruggles> aften does vbr ac3 [18:52:31] <mru> then it's allowed [18:52:49] <ruggles> i haven't gotten enough feedback to know what device support is like though [18:53:18] <ruggles> which probably means nobody is using it or that it doesn't break anything [18:53:52] <mru> I can imagine it breaking various spdif receivers [18:54:29] <saintd3v> mru: that was my first thought, lol [18:55:20] <mru> the receiver has to derive its clock from the signal, and I don't know how it would do that with vbr [18:55:35] <ruggles> what does it do when the program changes? [18:55:59] <ruggles> it would just be a program change every frame. :) [18:55:59] <mru> resyncs to the new rate I guess [18:56:12] <mru> but a frame is too short to sync properly [18:56:17] <ruggles> yeah, probably so [19:00:56] <kierank> mru: the spdif muxer can pad the frames out [19:01:12] <mru> but then it's cbr [19:01:28] <mru> and you'd be better off using those bits for actual audio instead [19:05:19] <ruggles> saintd3v: it looks like the psymodel api can only report bit allocation per band, correct? [19:14:29] <irock> therealgalen: yes, it works with 8-10 bits depth. [19:15:21] <irock> what's left to do is basically clean up and some refactoring [19:16:12] <irock> but it's usable as is right now [19:20:45] <saintd3v> ruggles: currently yes. [19:21:16] <saintd3v> which seems rather useless, imo. [19:21:41] <ruggles> yeah. ac3 does bit allocation per bin based on the energy estimate for that bin and the masking threshold for the corresponding band. [19:22:26] <ruggles> and the snr offset "quality" setting, which is adjusted to fit the cbr frame [19:22:43] <therealgalen> irock: good, i'm trying to package it up into a useful player, but i'm sure i'm doing something stupid at the moment [19:54:20] <irock> well, ask any question you like if it doesn't work for you [19:54:31] <irock> therealgalen: ^ [19:55:07] <therealgalen> irock: i think ffplay is not building for stupid local reasons, missing a library or something [19:55:27] <therealgalen> irock: i'm going to sort it out further but i have a few other things distracting me right now [19:55:40] <irock> ok, :) [20:08:26] <elenril> hmm, make fate fails on ./tests/data/vsynth1/flashsv.flv for me [20:09:39] <Kovensky> it's fate [20:09:56] <spaam> hohoh Kovensky was funny [20:10:19] * Kovensky spams spaam away [20:10:39] <spaam> instantrimshot.com [21:08:19] * elenril pokes BBB [21:11:05] * mru hands elenril a pointy stick [21:11:44] <elenril> mru: why does fate hate me? [21:12:40] * elenril wonders if he should blame clang [21:17:38] <mru> elenril: how does it hate you? [21:21:16] <elenril> http://pastebin.com/RViQ5jyY [21:22:15] <mru> it died during decoding [21:22:23] <mru> look for a .err file with more details [21:22:48] <mru> tests/data/vsynth1/flashsv.err or something [21:25:20] <elenril> http://pastebin.com/jLUXtFYk weird [21:26:28] <mru> the encoding step worked fine [21:26:49] <mru> since the checksum there didn't change [21:28:42] <mru> seems like something failing miserably reading the header [21:28:56] <elenril> well that happens on master [21:29:04] <mru> blame clang [21:30:50] * mru updates his copy of clang [21:30:54] * elenril tries gcc [21:35:37] <elenril> still fails with gcc [21:35:48] * mru blames elenril [21:36:52] * elenril wonders [21:39:44] * elenril sleeps [21:51:50] <ruggles> BBB: does wmavoice support stereo? [22:55:56] <BBB> shit [22:56:21] <BBB> clang-2.9 is definitely compiler bug, it's reproducible at -O2/3, not -O0/1 [22:56:25] <BBB> I wonder how to debug that [22:56:49] <mru> a new one? [22:57:12] <Yuvi> http://llvm.org/docs/HowToSubmitABug.html#miscompilations [22:59:19] <BBB> Yuvi: that's a massive document [22:59:31] <BBB> btw, Yuvi, weren't you buried in work at apple? is the iphone/ipad finished? :-p [22:59:42] * BBB checks pre-order to see if it shipped [23:00:28] <BBB> I wonder if they accept a bug if I tell them "ffmpeg version git-#@%&!$#(^&!#(%&!@% fails at make fate-vp8, but succeeds if compiling this one file at -O1, and this happens since this patch was applied" [23:00:58] <mru> BBB: same old bug? [23:01:28] <BBB> the clang-2.9 one failing vp8-fate since dark_shikari's patch [23:02:05] <mru> that's the one I meant [23:03:09] <BBB> yes that one [23:03:20] <BBB> is there an existing bug report for it? [23:03:42] <mru> are we sure it's not a bug in our code? [23:05:20] <Kovensky> well, he did say it only happens on -O2 and -O3 [23:05:27] <Kovensky> -O1 / -O0 don't trigger it [23:06:37] <mru> doesn't mean it's not our bug [23:07:04] <iive> aliasing? [23:08:00] <mru> or just about anything else [23:08:49] <kierank> [22:59] BBB: btw, Yuvi, weren't you buried in work at apple? is the iphone/ipad finished? :-p --> should I ask a friend of mine who told me about it early last time? [23:09:18] <mru> who cares about rotten fruit anyway? [23:09:23] <mru> nothing personal, Yuvi [23:09:24] <BBB> I love apple :) [23:09:30] <kierank> mru: women [23:12:55] <Yuvi> BBB: no comment on potential future hardware ;) [23:13:03] <BBB> well d'uh [23:13:08] <BBB> but good to have you back anyway :) [23:17:07] <Yuvi> actually, is it clang only or does it happen with llvm-gcc too? [23:17:50] <mru> llvm-gcc seems fine [23:19:20] <superdump> lu_zero: ping? [23:20:06] <Yuvi> it looks like the llvm-gcc configs on fate are r123173 and the clang 2.9 configs are r 125085 or newer [23:20:32] <mru> updating [23:20:40] <BBB> mru: thanks [23:20:48] <BBB> I could compile with llvm-gcc on kostylev's machine also [23:20:59] <BBB> locally I only have clang 1.5/2.8 and that works fine [23:21:08] <mru> those are ancient [23:21:24] <BBB> 2.9 isn't released yet [23:21:30] <mru> they could have added an optimisation that exposes a bug in our code since then [23:21:39] <BBB> probably [23:21:48] <mru> released or not, there have been a lot of changes since 2.8 [23:22:03] <BBB> or they could have added a bug that specifically creeps up when compiling ffmpeg [23:22:07] <BBB> wouldn't be the first time :-p [23:22:31] <BBB> brb [23:29:44] <mru> now I remember why llvm-gcc is stuck at an old version [23:30:00] <mru> linker crashes building it [23:56:31] <mru> anyone know a good gcc/binutils combination for building llvm-gcc? [23:56:45] <mru> everything I've tried fails

1 0

IRC log for 2011-02-22
by irc＠mansr.com 23 Feb '11

23 Feb '11

[00:10:42] <BBB> kurosu: ping, what was the avg workaround? [00:11:03] <BBB> Dark_Shikari: or maybe you know, is there a quick way to get (a+b)>>1 without losing the 17th bit? [00:11:27] <mru> if you have an avg instruction, sure [00:11:39] <BBB> avg is (a+b+1)>>1 [00:11:50] <BBB> want (a+b)>>1 and (a-b)>>1 [00:11:52] <mru> right, x86 is stupid and has only one of them [00:12:53] <Yuvi> (a+b)>>1 == ~(~a+~b+1)>>1 [00:13:45] <Yuvi> dunno (a-b)>>1 off the top of my head [00:16:41] <CIA-15> ffmpeg: Tony Strauss <tony(a)animoto.com> master * r6c065f0acd ffmpeg/libavformat/mpegtsenc.c: [00:16:41] <CIA-15> ffmpeg: mpegtsenc: use correct PES stream_id for AAC [00:16:41] <CIA-15> ffmpeg: This adds the AAC codec to the list of audio codecs that results [00:16:41] <CIA-15> ffmpeg: in a PES stream_id of 0xc0 (audio stream). [00:16:41] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:19:49] <CIA-15> ffmpeg: Alex Converse <alex.converse(a)gmail.com> master * r203df50d10 ffmpeg/version.sh: Remove old VCSs from version.sh [00:22:34] <Dark_Shikari> BBB: ask pengvado ,he knows this stuff [00:22:48] <Dark_Shikari> or check the "SIMD without SIMD" post on michael's blog [00:23:03] <mru> when will intel come to their senses and add non-rounding avg? [00:24:49] <iive> i though they already have round [00:25:19] <mru> yes, but not non-rounding [00:28:03] <peloverde> Is it just me or is patchwork stuck? http://git.ffmpeg.org/?p=ffmpeg.git;a=shortlog [00:42:20] <CIA-15> ffmpeg: Young Han Lee <cpumaker(a)gmail.com> master * re22910b21a ffmpeg/libavcodec/ (aac.h aacdec.c): [00:42:20] <CIA-15> ffmpeg: aacdec: Reduce the size of buf_mdct. [00:42:20] <CIA-15> ffmpeg: It was doubled in size for the LTP implementation. This brings it back [00:42:20] <CIA-15> ffmpeg: down to its original size. [01:06:36] <BBB> Yuvi: thanks [01:17:58] <BBB> next question, how do I ~ in x86 simd? [01:18:06] <BBB> I know pandn, but there's no pnot [01:18:40] <Dark_Shikari> not is just a xor with all 1s [01:18:51] <Dark_Shikari> all 1s can be gotten via pcmpeqb xmm0, xmm0 [01:22:12] <Compn> BBB : btw i think maintainers is a good file in case someone wants to work on said file and maybe needs some help with it [01:22:28] <Compn> but if all those names correspond with copyrights in the files , then its probably duplicate [01:22:48] <BBB> Dark_Shikari: ah ok [01:23:26] <Compn> BBB : and if you frame the discussion like that i'm sure more people would understand. since i think maintainers was around before Diego fixed all the license and copyright headers ;) [01:25:46] <BBB> Dark_Shikari: lots of extra instructions though :( [01:25:55] <BBB> I'll see what I can prevent by doing various things [01:26:23] <Dark_Shikari> fuck mmx [01:26:45] <BBB> pengvado: any ideas on a quick way to accomplish (a-b+1)>>1 without losing the 17thbit? ideally without having to do xor mm, and then psub mm, b followed by pavgw [01:26:58] <Dark_Shikari> are a and b int16_t or uint16_t? [01:27:05] <BBB> int16_t vector [01:27:18] <BBB> oh wait was pavgw unsigned? [01:27:24] <Dark_Shikari> yes [01:27:37] * BBB curses [01:27:39] <Dark_Shikari> (a-b+1)>>1 can be signed, there's your problem [01:27:41] <Dark_Shikari> the output can be 17-bit! [01:27:49] <Dark_Shikari> i.e. 16 bits + 1 sign bit [01:27:59] <BBB> yes [01:28:01] <Dark_Shikari> i.e. (0-65535+1)>>1 [01:28:24] <Dark_Shikari> =-32767 ... oh wait [01:28:25] <Dark_Shikari> it fits. [01:28:38] <BBB> (-65536-65535+1)>>1 [01:28:39] <BBB> ? [01:28:41] <BBB> well anyway [01:28:44] <Dark_Shikari> You said [01:28:45] <Dark_Shikari> your inputs [01:28:46] <Dark_Shikari> are unsigned [01:28:52] <Dark_Shikari> -65536 isn't an int16_t or uint16_t [01:29:01] <BBB> the inputs are signed [01:29:03] <BBB> everything is signed [01:29:14] <Dark_Shikari> But you said pavgw... [01:29:19] <BBB> I know, I'm stupid [01:29:26] <BBB> I have a problem here [01:29:32] <BBB> I'm stupid _and_ it doesn't fit [01:29:45] <Dark_Shikari> -65536 is not an int16_t [01:29:48] <BBB> true [03:02:06] <BBB> mru: ping, so I'd really like to see how you did this, because I'm going through the spec and I can't figure out how to do it; regardless of instructions, the range of numbers from 12-bit input (8.1.3.9) gets to 18 bit for the first part already, then >>3 = 16 bit, and then up to 23 bit for the second part (right before the >>= 7, which makes it 16 again) 23 bit never fits in a word, no matter how fantastic your instruction set is at rounding o [03:02:06] <BBB> non-rounding [03:02:46] <Yuvi> neon has (a-b)>>1, (a+b)>>1, (a+b+1)>>1 on signed and unsigned 8 to 32 bit values [03:03:01] <Yuvi> oh 23 bits [03:03:08] <BBB> he said he wrote it in words, I wonder if he wrote it in dwords [03:03:48] <Yuvi> well, output range beyond 9 bits signed doesn't matter [03:04:04] <Yuvi> since you're adding + saturating to 8 bits unsigned [03:05:26] <BBB> if you do a lot minis a lot, the outcome in the scale [0,255] depends on how much a lot each of the two operands was :-p [03:05:33] <BBB> minis=minus [03:05:52] <BBB> if one is 1000 and the other is 1500, then the outcome is 0 [03:05:56] <BBB> inverse the outcome is 255 [03:05:56] <Yuvi> aren't you adding to 8 bits unsigned? [03:06:13] <Yuvi> or is there more to vc1? [03:06:29] <BBB> it's not an add [03:06:31] <BBB> it's a put [03:06:35] <BBB> (mostly) [04:53:40] <saintdev> peloverde: any suggestions for another name for the "constant part" of the pe calculation? [04:54:13] <peloverde> not off the top of my head [04:55:14] <saintdev> i can't think of a good one, and calling it "constant" is very non-descriptive :( [05:18:48] <peloverde> fixed [05:25:01] <peloverde> as in fixed vs variable [05:28:03] <saintdev> band->fixed band->fixed_part band->pe_fixed [05:28:06] <saintdev> hmm, not sure i like those any better, lol [05:29:45] <saintdev> but it's shorter, lol [05:36:11] <peloverde> i think band->pe_fixed is okayish [05:37:45] <saintdev> yeah i thought so also, but then i realized it also was the worst because it could also mean the 'corrected' pe [05:38:08] <saintdev> stupid english ambiguity [05:38:26] <peloverde> band->pe_nonvolatile [05:38:34] <peloverde> lol [05:39:00] <saintdev> lol [05:39:34] <dalias> is this a flag? [05:41:56] <saintdev> dalias: no, it's the constant pre-calculated part of the pe calculations [06:12:28] <saintdev> peloverde: band->pe_static [06:15:19] <peloverde> that might be confused with noise substitution or some other nonsense [06:15:27] <peloverde> band->pe_const? [06:16:03] <saintdev> that's what i have now, lol [06:16:08] * saintdev stabs english [06:18:02] <dalias> :) [06:35:24] <thresh> moroning [06:35:57] <kshishkov> whew, the things are as usual again [06:36:16] * kshishkov is undecided about morning though [06:37:35] <thresh> what do you expect on a friday anyway [06:40:26] <kierank> erm [06:44:53] <kshishkov> thresh: here it's tuesday already [06:46:58] <thresh> kshishkov: but tomorrow's a holiday here [06:47:06] <thresh> so that automatically turns tuesday to a friday [06:49:09] <thresh> а каждую пятницу я в говно и далее по тексту [06:49:51] <kierank> is there any generic "syncword search" code in ffmpeg? [06:50:05] <kierank> or does each codec do it by itself [07:10:42] <kurosu> BBB: specs (s421m.pdf) says contents after first pass (whether vertical or horizontal) must be within [-4096;4095] ("signed 12bits range"), and that's after the >>3, so the specs guarantee that intermediates fits within the intended 16bits range [07:12:23] <kurosu> hum, but for 2nd pass, it says range [-512;511]... that doesn't fit [07:12:52] <kurosu> however, that's an idct, why would it output that range in the end? [07:13:30] <kurosu> that's a residual, it should at worst be within [-255; 255] [07:14:04] <kurosu> anything below outside doesn't matter as it will get truncated when going back from residual to pixel domain [07:14:14] <kurosu> s/below// [07:15:39] <kurosu> however, the guarantees provided by this spec are a bit dubious... how do they do that at the encoder? clamp the intermediates after each pass of the fdct ? [07:17:56] <kurosu> (oh my, so many grammar errors, i guess i should have waited for my coffee) [07:21:28] <kurosu> I agree with Yuvi about last pass output [07:22:44] <kurosu> I'm looking at Annex A, section 1 and the range for E and R matrices [07:25:14] <kurosu> if we read pessimistically it, the limitations about range for E and R could only mean that, whatever the result of a pass, it gets clamped before being output to either E and R [07:25:56] <kurosu> that doesn't help us, as there's wraparound when you do your 16bits SIMD arithmetics [07:32:04] <Yuvi> add/sub can be saturated but mul can't in SSE [07:32:33] <Yuvi> it does help because if you assume 10bit signed output, t1-t8 can be saturated to 16 bits signed in the second stage [07:33:23] <Yuvi> regardless of whether the encoder really guarantees 12-bit signed input to the second stage [07:35:57] <mccoffein> good morning [07:36:10] <kierank> hello [07:37:21] <cartman> moin [07:44:20] <Yuvi> or actually, BBB was right, if you have e.g. (32896-32768+1)>>7 then saturating them to 32767 before that is wrong... [07:48:10] <Yuvi> still, even [-4096,4095] into the 2nd pass means for 19 bit intermediates, at which point it's possibly faster to just pmaddw to 32 bits and not worry about it [07:50:46] <siretart> god moroning! [07:53:17] <andoma> hello [08:45:39] <cartman> https://twitter.com/#!/djrbliss/status/38238822072451072 [08:45:40] <cartman> uh oh [08:46:15] <spaam> höhö [08:46:37] <kierank> someone tweet back using the official ffmpeg account: "yeah we know. what's the big deal?" [08:48:17] <kshishkov> "breaking Mozilla's FFmpeg - impossible" [08:50:36] <superdump> i wonder who djrbliss is anyway [08:50:43] <superdump> dan rosenberg... [08:50:44] <superdump> hmmm [08:50:48] <cartman> superdump: some 0day guy [08:51:06] <superdump> ah, ok [08:51:15] <kshishkov> superdump: why should you care? [08:51:56] <superdump> curiosity [09:39:42] <kshishkov> mate! [09:39:52] <kshishkov> where are Bink-d samples? [09:39:53] <pross-au> comrade! [09:40:14] <pross-au> Good question. Can you lobby Vag to tell us where they are! [09:41:27] <kshishkov> I suspect they just don't exist at all [09:41:55] <pross-au> He's got a keen eye for these things [09:42:50] <kshishkov> well, I think it will be easy to add once samples and decoder appear [09:43:10] <pross-au> Yep [09:44:08] <pross-au> One can isolate it roughly [09:44:22] <pross-au> HOMM3 was released ~1999 [09:44:39] <pross-au> Diablo2 middle of 2000 [09:44:50] <pross-au> Somewhere between there [09:45:05] <kshishkov> VAG said that it was supposed to appear in MM7 or so [09:45:27] <spaam> kshishkov: do you have bink-c samples? [09:45:45] <kshishkov> spaam: I'm not sure if even RAD has them [09:45:52] <pross-au> Haha [09:48:13] <kshishkov> pross-au: BTW, can you look at http://shishkov.homeunix.net/0001-SMUSH-decoder-v0-and-1.patch and say why it has issues with some codec-37 files? [09:48:19] <kshishkov> pross-au: like http://samples.mplayerhq.hu/game-formats/la-san/dig/pigout.san [09:50:53] <pross-au> Okay. Give me a day or so [09:50:59] <kshishkov> take two [12:24:03] <CIA-15> ffmpeg: Benjamin Larsson <benjamin(a)southpole.se> master * r8f935b9271 ffmpeg/libavformat/isom.c: [12:24:03] <CIA-15> ffmpeg: Add more AVC Intra FOURCCs [12:24:03] <CIA-15> ffmpeg: Also change the comments a bit since the FOURCCs aren't specific to Flip4Mac [12:24:03] <CIA-15> ffmpeg: and different ones are used for 720 versus 1080 lines. [12:24:03] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [12:34:29] <Compn> ugggggg fourcc [12:36:11] <spaam> :D [12:36:16] <spaam> Fix it Compn ! [12:38:14] <kshishkov> spaam: it's not that, he's envious for not reporting them in first place [12:39:38] <spaam> kshishkov: haha [12:39:48] <spaam> Compn: where is that commit for mplayer? [12:39:48] <Compn> i mean ugh as in why is flip4mac putting h264 in avi ? [12:40:07] <spaam> why not? [12:40:15] <Tjoppen> Compn: mov actually [12:40:16] <JEEBsv_> because it likes the perverseness of it? [12:40:26] <Compn> Tjoppen : then its an isom tag not a fourcc [12:40:34] <Compn> er not a riff tag [12:40:36] <Compn> isom.c [12:40:42] <Tjoppen> tomato, tomahto [12:40:56] <Compn> well bcourdier hates it when you commit isoms to riff list ... [12:41:59] <Tjoppen> r8f935b9271 ffmpeg/libavformat/isom.c [12:42:14] <mru> for good reason [12:42:22] <Compn> doh [12:42:30] <cartman> fo(u)r CCs [12:42:33] * Compn cant read :) [12:42:52] <Compn> well then its not avi [12:42:59] <Compn> but why are they making more tags ? :P [12:43:12] <mru> because they can [12:43:16] <Compn> of course [12:45:30] <Tjoppen> baptiste supplied me with more by running strings on quicktime IIRC [12:45:42] <Tjoppen> but we don't have samples for those [12:46:01] <Tjoppen> like 10-20 of 'em [12:46:09] <Compn> using qt_tools would probably be easier... [12:46:20] <Compn> anyways if you have a list, share it and i'll keep my eyes open for them ;) [12:46:39] <Tjoppen> of course, this is nothing compared to MXF and its massive lists of ULs [12:47:15] <kshishkov> Tjoppen: just list all five invalid UL's and use codec autodetection otherwise ;) [12:47:47] <Tjoppen> uhm.. ah, right. some codecs have probe functions in lavf :p [12:52:01] <Tjoppen> which reminds me: there is still no way to probe pictures [12:52:23] <Tjoppen> although that might change in a week or two [13:08:20] <mccoffein> hy [13:34:09] <Tjoppen> why is ticks_per_frame required any more? can't the mpeg2video and h264 decoder just set time_base correecctly or am I missing something? [13:34:21] <mru> lol @ omx asm code [13:34:38] <mru> first they define a bunch of aliases for various registers [13:34:53] <mru> then every time they use one, they name the real register in a comment alongside [13:35:45] <kshishkov> probably it was company policy to use aliases but devs kept forgetting which register they were using [13:36:32] <mru> having many names for each one only makes things confusing imo [13:36:55] <Flameeyes> mru: company policy and usefulness in the same phrase would be an oxymoron [13:37:03] <thresh> oh god now hpux cc fcuked up the .d files [13:37:18] <thresh> every .d now contains "you have a demo, pay us bucks" [13:37:30] <mru> thresh: you might want to add specific rules for that compiler [13:37:41] <thresh> mru: sure [13:37:48] <kshishkov> mru: no need, compiler has added them already [13:37:59] <thresh> true, but somehow gmake chokes on those :( [13:38:25] <thresh> well actually it worked before that compiler started to whine about being a demo [13:38:33] <kshishkov> of course - just propose Stallman's creation to pay for something and you'll get the same reaction [13:40:03] <Flameeyes> kshishkov: you shouldn't be a developer if you want to make money! go work as a chaffeur intead! </stallman-troll-mode> [13:43:37] <wbs> mru: who's omx implementation is written in asm? [13:43:56] <mru> something from ARM [13:57:09] <Flameeyes> does it make me a bad developer if I fill in a technical document of UML diagrams to make it feel "beefier"? [13:57:26] <mru> yes [13:57:26] <kshishkov> yes [13:58:35] <Flameeyes> sigh :'( [14:23:32] <{V}> print it out single sided on cardboard, that should help making it feel beefier [14:23:53] <bilboed-tp> or print it on meat directly [14:24:22] <kshishkov> documentation el vaco? [14:28:58] <pJok> documentation el maco? [14:30:50] <kshishkov> nej, nötdokument [14:31:38] <bilboed-tp> we'd need a meating to figure out what to call it [14:32:37] <kshishkov> well, the cows with pigment forming printed pages on their sides would form the beefiest document ever [14:47:10] <pJok> kshishkov, nöttdokument? [14:47:46] <kshishkov> nötköttdokument (he wanted to make it fully beefed) [14:47:55] <pJok> ah yes [14:49:49] <uau> elenril: i think some of the scheduled deprecated API drops are too aggressive for a bump now [14:50:00] <uau> for example AVSampleFormat was only added a couple of months ago [14:50:23] <uau> yet SampleFormat is scheduled to be already dropped at the next libavcodec version bump [14:50:31] <mru> it's a trivial change in source code [14:50:42] <uau> that's not the point [14:50:56] <uau> the issue is not how easy it is to switch from one to the other [14:51:09] <mru> deprecations requiring actual work in the apps should have a longer cycle [14:51:15] <uau> but rather whether you can already depend on the new version being available everywhere that matters, and how hard it is to support both [14:51:23] <mru> for a simple search and replace a couple of months is plenty [14:51:39] <uau> you're viewing it from the wrong angle [14:51:51] <mru> of course I am [14:51:56] <mru> I'm talking with you [14:52:02] <mru> and therefore I am by definition wrong [14:52:05] <uau> sure it would be very easy for me to replace every use of SampleFormat in mplayer2 with AVSampleFormat [14:52:26] <kshishkov> uau: then please do it in advance [14:52:28] <uau> but that'd needlessly break it with new libavcodec versions [14:53:09] <uau> and as AVSampleFormat has only been added so recently you can't rely on it being available [14:54:43] <uau> kshishkov: do it in advance how? add version-specific defines in the code to automatically switch depending on libavcodec version? [14:55:06] <kshishkov> nope, rename it to AVSampleFormat [14:55:24] <uau> then compilation will break with all distro versions [14:56:33] <kshishkov> well, FFmpeg is not Debian you know [14:57:38] <uau> IMO it'd be a lot more reasonable to do a release with the new API first, then after that has been out for some time drop the deprecated version [15:04:32] <uau> so the issue is not just how easy/hard it is to switch from the old version to the new - what also matters is how easy it is to write one version of code that can be compiled against _either_ ffmpeg version without changes during a transition period when different versions will be in use [15:04:46] <uau> and if there is a major API/ABI bump then there will be such a transition period [15:41:55] <Flameeyes> uau: we agree that the _ABI_ bump needs to be done before release though? [15:42:35] <uau> yes [15:43:21] <Flameeyes> k then we're on the same page here [16:27:55] * elenril wonders what are people talking about on the ml [16:28:20] <_av500_> fflames? [16:28:34] <elenril> uau: the incompatibilities that were introduced recently can be postponed until the next big bump [16:29:07] <j-b> 'morning [16:29:11] <elenril> i'm not writing all those avio wrappers just to drop them after two weeks [16:30:02] <uau> elenril: well just make sure that's actually done for the already "scheduled" drops, like SampleFormat (AVSampleFormat added in november) [16:40:51] <elenril> bleh, new clang fails with --disable-optimizations [17:02:07] <mru> meh, who cares about that? [17:20:10] <Flameeyes> let me guess, there is no free to access posix specification? [17:33:19] <elenril> BBB: ping [17:33:32] <BBB> elenril: pong [17:33:48] <elenril> you busy? [17:33:51] <elenril> renames are waiting [17:33:56] <BBB> today is bad day [17:34:00] <BBB> I can try tonight [17:34:15] <elenril> ok, i'll do something else for now [17:34:24] <BBB> I don't like put_tag, but I'll take it for now since it's private [17:35:02] <BBB> fopen/close is probably fine [17:35:05] <BBB> didn't look at that one yet tbh [17:36:14] <elenril> i'm wondering what to do with av_url_read_seek [17:36:29] <elenril> not sure why is it even needed and why is it public [17:37:21] <wbs> elenril: it's needed to request a seek for e.g. rtmp [17:37:42] <wbs> which is visible to the demuxer as a flv bytestream, but is a seeking-capable protocol in itself [17:38:42] <elenril> can't it be done more automagically on the avformatcontext level? [17:39:26] <wbs> not really [17:40:11] <wbs> think of it as a magic file that produces an flv stream that you can play back, but you can also request it to seek to a certain point (given in seconds) [17:40:40] <wbs> ah, well, it perhaps can be lavf-internal yes, but still needs to be exposed to the demuxers in the URLContext layer [17:40:41] <uau> Flameeyes: there's a lot of posix stuff on opengroup.org at least (you didn't tell what exactly you were looking for) [17:42:15] <elenril> wbs: well my naive view would be that a client app calls seek(avformatcontext, timestamp) and lavf detects by itself that the URLProtocol supports this kind of magic and does TheRightThing [17:42:49] <wbs> elenril: yes, the user app in itself doesn't need to do it [17:43:08] <wbs> elenril: except if you for some reason use URLContext directly (but was that api going to be private for now?) [17:43:19] <wbs> elenril: it's all handled within the demuxers [17:44:33] <BBB> elenril: I'm all with you [17:44:38] <BBB> elenril: imo it should have been internal only [17:44:40] <in3xes> what is this? http://www.ffmpeg.org/doxygen/trunk/avformat_8h-source.html#l00239 [17:44:46] <BBB> elenril: e.g. mms can do that sort of stuff also [17:44:54] <elenril> well URLContext should be public [17:45:00] <elenril> so apps can write their own protocols [17:45:09] <elenril> err i mean URLProtocol [17:45:12] <BBB> elenril: but that rtmp guy was all over the place and insisted that this was the ONLY WAY___ and therefore it was to be or else hell and doom [17:45:34] <BBB> oh yeah did I mention I don't like that librtmp guy? [17:48:15] <Kovensky> you did, just now, at least :) [17:48:30] <Flameeyes> uau: was looking to point exactly at the specifications of posix mq :/ mq_overview only lists "conforming to POSIX.1-2001" [17:51:14] <mru> Flameeyes: http://pubs.opengroup.org/onlinepubs/9699919799/ [17:52:47] <Flameeyes> mru: is that the actual text or just a reference? 'cause the only stuff I've seen seem to be nothing more than the Np man pages :/ and it reaaaly makes me doubt of lu_zero's sanity if that's the only definition of mq [17:53:34] <mru> that's the full spec [17:53:49] <Flameeyes> okay I officially doubt of lu_zero's sanity now =_= [17:53:50] <Flameeyes> thanks mru! [17:54:44] <elenril> who's the librtmp guy? [17:54:52] <merbzt> hyc [17:55:00] <mru> he can be annoying [17:55:49] <merbzt> maybe not hyc then [17:57:56] <BBB> mru: any more comments on the FF_NETERROR patch? [18:00:50] <mru> fine with me [18:11:09] <in3xes> What is "AVProbeData" ? how should it be used ? [18:20:23] <BBB> in3xes: used to probe the filetype [18:20:32] <BBB> in3xes: load the first few bytes of a file in AVProbeData [18:20:48] <BBB> it'll tell you what type of file the data likely came from [18:24:28] <in3xes> Okay [18:57:47] <elenril> what's up with people decoupling bump and breaking compatibility [18:59:44] <mru> if you can't find a bikeshed, build one [18:59:52] <elenril> uau: major bump is by definition equivalent with breaking compatibility [19:00:01] <elenril> or did i misunderstand your mail? [19:00:29] <mru> whatever you say, uau will generally disagree [19:00:51] <mru> try it some time, a few days after he's said something, present it as your own idea and watch him pick holes on it [19:00:54] <mru> *in [19:04:31] <Flameeyes> elenril: you can bump and break the ABI, but keep a compatible API... [19:04:42] <Flameeyes> which is most likely the desired situation for 0.7 [19:05:16] <uau> elenril: the basic problem that needs addressing here is that not every distro/user will switch ffmpeg version at the same exact moment [19:05:42] <uau> thus it's a problem if updating your application to work with the new ffmpeg version necessarily breaks it with the old one [19:05:46] <elenril> Flameeyes: i think we want to break both now [19:05:54] <elenril> for things that were deprecated for a long time [19:06:06] <Flameeyes> elenril: for the things that were deprecated on 0.6, please go on :) [19:06:22] <Flameeyes> it's for the "new" stuff (i.e. stuff that wasn't deprecated at the ti me 0.6 was released) that I'd suggest keeping compatibility [19:06:27] <Flameeyes> at least source-level compatibility [19:06:34] <elenril> yeah, i think everybody agrees [19:09:14] <uau> elenril: so decoupling the bump and dropping old api is not so much a goal in itself; rather the goal is to only drop old API after a release containing the old API has been out for some time [19:09:37] <uau> and for other reasons it's desirable to do a bump _before_ release [19:09:43] <uau> does that answer your question? [19:09:52] <elenril> this was the idea since the beginning [19:09:59] <elenril> i don't understand where's the problem [19:10:07] <uau> s/release containing old API/release containing new API/ [19:10:45] <Flameeyes> elenril: I think the problem was BBB bringing up the "before or after?" question [19:11:05] <uau> elenril: well there's still stuff like "#define FF_API_OLD_SAMPLE_FMT (LIBAVCODEC_VERSION_MAJOR < 53)" in the sources [19:12:40] <uau> so current state of the sources at least doesn't yet match that "idea since the beginning" [19:12:57] <elenril> current state of the sources doesn't match many things [19:13:18] <elenril> those things should be fixed before bumping [19:14:37] <uau> elenril: and i don't think that there has been a widespread understanding/consensus that those would be changed before the bump [19:19:31] <elenril> sierra vmd audio? [19:19:33] <elenril> what's that? [19:21:32] <Kovensky> probably some 90s game codec [22:42:04] <ruggles> kshishkov: ping [23:21:37] <ubitux> bcoudurier: i expected http://roundup.ffmpeg.org/issue2246 with a few mp4 (from the same series) / Måns and Uoti have discussed the issue; do you need the irc log? could you have a look on it? [23:27:39] <ubitux> almost everything is said here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel-irc/2011-February/000260.h…

1 0

IRC log for 2011-02-21
by irc＠mansr.com 22 Feb '11

22 Feb '11

[00:57:58] <BBB> oh wth, pavgw is mmx, not mmx2 [00:58:01] <BBB> awesome [01:04:34] <iive> BBB: hum? where did you read that? [01:15:03] <iive> i'm quite sure it is mmx2. (pavgw 0x0F, 0xE3) [01:28:54] <BBB> it says katmai in my guide [01:30:09] <iive> katmai is Pentium3 and it is SSE (1) capable [01:30:29] <BBB> oh [01:30:30] <iive> actually that is the only thing that differs from P2 (and the clock of course). [01:30:31] <BBB> fuck [01:30:34] <BBB> you're right [01:31:01] <BBB> ohwell [01:31:05] <BBB> no mmx idct then [01:31:05] <iive> :) and mmx2 is sse integer. [01:31:07] <BBB> mmx2 is fine [01:31:26] <iive> there is macro/trick that emulates avg [01:31:48] <iive> it should still be faster than C [01:32:11] <iive> I've seen it in the MC code. [01:32:23] <BBB> it doesn't work over 17 bits [01:32:28] <BBB> I need 17 bits [01:32:29] <BBB> :( [01:32:34] <iive> yes it does [01:32:36] <BBB> ? [01:32:41] <BBB> I'll look [01:32:46] <BBB> I'm probably confused [01:32:52] <BBB> still, who cares about mmx [01:32:55] <BBB> it's 10 years old [01:33:13] <BBB> it's more like "hey, if I can do this hell of a function in mmx, just guess how much easier and more efficient it'll be in sse2" [01:33:18] <BBB> :-p [01:34:10] <iive> last time I heard nasa was still using 486... something with cosmic rays and stuff. [01:34:29] <Sean_McG> flip the wrong bit and kaboom [01:35:42] <BBB> iive: right [01:35:44] <BBB> iive: so... [01:35:48] <BBB> iive: nasa is using vc1 for ... [01:35:48] <BBB> ? [01:35:52] <BBB> please fill in my blank [01:35:59] <Sean_McG> space porn? [01:36:01] <iive> huble [01:36:01] <kierank> you'd be surprised [01:36:07] <BBB> to compress their cosmic rays? [01:36:14] <kierank> they used vc-1 on some videos once ;) [01:36:15] <BBB> I mean, I feel really sorry for those guys [01:36:24] <BBB> not only is al detail in their rays gone [01:36:29] * kierank wonders why BBB is working on vc-1 [01:36:29] <BBB> if their porn was indeed in vc1 [01:36:36] <BBB> they'd have no idea about what they're looking it [01:36:38] <BBB> imaginary porn [01:36:44] <BBB> kierank: good question [01:36:53] <BBB> kierank: I found a movie, it played disastrously sloly [01:36:56] <BBB> so I work on it [01:36:56] <kierank> next we're going to hear that you're going to write vc-1 interlaced [01:37:01] <BBB> \o/ [01:37:07] <BBB> pay me [01:37:26] <Dark_Shikari> I think we could justify at least a $5k foundation bounty for that. [01:37:29] <iive> have you asked the foundation? [01:37:33] <Dark_Shikari> It's the one thing missing for blu-ray decoding [01:38:00] <kierank> and mvc ;) [01:38:10] <Dark_Shikari> mvc isn't part of original blu-ray [01:38:17] <BBB> dudes [01:38:22] <Dark_Shikari> and you can decode 3D blu-ray without an mvc decoder [01:38:23] <BBB> I'm not gonna implement vc1 interlaced [01:38:26] <BBB> I'm lazy [01:38:28] <BBB> besides I have a job [01:38:29] <Dark_Shikari> then why'd you say pay me [01:38:34] <kierank> iirc we still fail on backwards compatible 3d [01:38:39] <kierank> might be wrong though [01:39:05] <BBB> Dark_Shikari: usually people shut up when ypu say that :) [01:40:49] <iive> you used to be such a nice guy. [01:40:58] <Dark_Shikari> and then google hired him and sucked his soul [01:42:41] <BBB> iive: :( I'm no longer nice? [01:42:52] <BBB> iive: besides I do work on vc1 opts [01:42:55] <BBB> I try at least [01:43:13] <BBB> but yeah I'll give my soul for my kid's college [01:43:17] <BBB> he's cute :) [01:44:34] <iive> I had no idea education is so much expensive in USA. [01:45:56] <BBB> depends on the college ... [01:47:08] <saintdev> Mudd [01:47:10] * saintdev runs [01:49:31] <Dark_Shikari> You can get him like me and get him to pay half of it `-` [01:52:14] <saintdev> Dark_Shikari: how does mudd's tuition compare to mit or cmu? [01:52:25] <iive> BBB: well... imho if things keep going on like this, there will be second financial crysis, most probably in about 2 years, maybe even on time for electing the correct president. [01:52:44] <BBB> who's the correct president [01:52:44] <Dark_Shikari> saintdev: same [01:52:50] <Dark_Shikari> ~$52000 per year including room/board [01:54:11] <iive> BBB: too early to say. [01:54:19] <BBB> well that's useful :) [01:54:20] <BBB> anyway [01:54:23] <BBB> I'll just work on vc1 [01:54:31] <BBB> surely nobody will complain about me improving vc1 :) [01:54:47] <saintdev> i object! [01:56:15] <iive> n8 ppl. [02:21:03] <asdf1234> saintdev: pretty much *every* private college in the US costs $50k+ a year [02:21:18] <asdf1234> (undergrad) [02:21:36] * mru is happy with his free swedish education [02:22:10] <asdf1234> that is, if your family makes under $50k a year [02:22:27] <asdf1234> then private colleges are actually usually cheaper than public schools [02:22:39] <asdf1234> as in free [03:21:46] <Jumpyshoes> where are the deblock functions for h264 initialized? [03:24:36] <Dark_Shikari> grep [03:25:42] <frunksock> how can I get make to show me the entire compile command instead of abbreviating it to "CC foo.o" [03:36:39] <frunksock> does ffmpeg include the ffmpeg-mt stuff yet? [03:37:03] <Dark_Shikari> some of it [03:40:24] <peloverde__> frunksock: make V=1 [03:40:50] <frunksock> thanks peloverde__ [03:41:07] <frunksock> I had been trying VERBOSE=1 to no effect [06:11:45] <cartman> moin [06:19:40] <dalias> hi [06:24:23] <thresh> moroning [06:40:56] <Dark_Shikari> Actual quote from the Google C++ style guide: [06:41:03] <Dark_Shikari> "If your function crashes upon error, you should append OrDie to the function name." [06:41:11] <Dark_Shikari> (e.g. "OpenFileOrDie") [06:41:19] <spaam> God morgon :) [06:41:25] <cartman> Dark_Shikari: Perl like [06:41:29] <Dark_Shikari> Yup [06:45:06] <KotH> ohayou gozaimasu! [06:56:36] <KotH> cartman: Türk insan\u0131 para gibidir; \u0131\u015f\u0131\u011fa tut,\u0130çinde Atatürk yoksa sahtedir.... [06:57:52] * elenril drops an anvil on KotH [06:58:01] <cartman> KotH: ;> [07:07:06] <kurosu> BBB: is that really 17bits or 16bits with an offset (for instance [-13000;48000]) ? [08:37:35] <kshishkov> lu_zero: http://satwcomic.com/art/your-time-is-up.jpg [08:39:32] <lu_zero> kshishkov: god morgon [08:39:42] <cartman> nice one [08:40:21] <lu_zero> sigh... [08:43:57] <lu_zero> close [08:44:22] <spaam> lu_zero: Hur Ã€r det idag? :) [08:44:38] <kshishkov> spaam: kanske inte sÃ¥ bra [08:44:46] <spaam> kshishkov: varfÃ¶r dÃ¥? [08:45:17] * spaam sitter och dricker trocadero [08:45:26] <kshishkov> spaam: fel, du mÃ¥ste fraga "voffor dÃ¥" [08:45:53] * kshishkov vill gÃ€rna dricka Trocadero men hon har inget [08:46:01] <wbs> hon? ;P [08:46:14] <spaam> kshishkov: han menar du. [08:46:17] <kshishkov> I always confise [08:46:22] <kshishkov> *confuse [08:46:22] <spaam> kshishkov: du Ã€r vÃ€l en man? [08:46:29] <kshishkov> those two pronouns [08:46:44] <spaam> wbs: han kanske blev en kvinna i helgen :) [08:47:16] <kshishkov> spaam: riktig, men engelska("he")==ryska("ÐŸÐœ"("on")) [08:47:32] <lu_zero> =) [08:51:03] <lu_zero> wbs: poing [08:51:14] <wbs> lu_zero: pong [08:51:40] <lu_zero> do you still have your applehttp-as-protocol patch around? [08:51:59] <wbs> yes, one sec [08:52:25] <lu_zero> I'm trying to sort out whose fault of what [08:52:47] <wbs> what issue are you having? incomplete packets at segment boundaries should at least be fixed by that patch [08:53:05] <lu_zero> the equal dts seem an artefact of timestamp guessing [08:53:29] <lu_zero> I have an additional issue with the streaming expiring the buffers in realtime [08:53:44] <lu_zero> (so stuff like find_info or just slow network cause problems) [08:53:55] <wbs> hmm, ok, I don't think that should be affected - do you get the same issue if you play the segment files straight without the applehttp playlist inbetween? [08:54:20] <lu_zero> and then there is the wonderful 5k or problems issue due the mpegts demuxer [08:54:41] <lu_zero> your patch should fix that one at least [08:54:58] <wbs> yes [08:55:26] <lu_zero> using url_read or url_read_complete doesn't seem to change anything btw [08:56:02] <wbs> then everything's right at that layer at least - changing which one of those is given to AVIOContext shouldn't matter [08:56:18] <wbs> except that it might give slightly different buffer usage, helping weird seeks and such, but not much else [09:01:20] <wbs> lu_zero: https://github.com/mstorsjo/ffmpeg/tree/applehttp-urlprotocol [09:01:29] <wbs> rebased on top of the latest master [09:01:42] <lu_zero> thank you =) [09:25:47] <Kovensky> 22:37.34 Dark_Shikari: It's the one thing missing for blu-ray decoding <-- and .ts seeking [09:27:25] <kshishkov> Kovensky: well, speak to mru about accurate .ts seeking and to me about implementing interlaced VC-1 decoder. You'll get the same answer [09:28:23] <lu_zero> curious it complains about usleep [09:28:54] <Kovensky> kshishkov: doesn't have to be *accurate*, being just as inaccurate as the other demuxers would be better already =p [09:30:03] <Kovensky> without seeking you can't use -ss on ffmpeg nor make playback software using ffmpeg unless they make their own demuxers [09:30:31] <Kovensky> and having to make your own demuxer kinda defeats the point of libavformat [09:38:07] <superdump> swedes: i confuse hon/han as well for two reasons [09:38:31] <superdump> 1) in most other european languages, 'a' is feminine and 'o' is masculine [09:39:24] <superdump> and 2) honom is him and henne is her [09:39:39] <superdump> hon, henne; han, honom [09:39:41] <superdump> eh? [09:39:42] <superdump> :) [09:39:59] <wbs> :-) [09:40:19] <wbs> finnish is great then, too - you don't have any gender-specific personal pronouns at all, only "hÃ€n" meaning both he and she [09:40:47] <lu_zero> ^^; [09:40:50] <superdump> awesome [09:43:20] <vipw> han solo -- easy to remember [09:45:23] <superdump> weird - /usr/local/lib is at the top of my /etc/ld.so.conf and libx264.so.114 is in there but when building ffmpeg it gets an undefined reference to x264_encoder_open_114 [09:45:53] <spaam> old header somewhere? :) [09:46:29] <superdump> shouldn't matter as the build numbers are the same [09:46:53] <uau> superdump: correct .so symlink? [09:48:04] <uau> -lx264 won't make the the linker try to access libx264.so.114 directly, but rather libx264.so [09:48:07] <superdump> some interesting stuff here - /usr/local/lib is a symlink to /usr/local/lib64; in there /usr/local/lib/libx264.so -> libx264.so.114 [09:48:18] <superdump> so it's correct [09:48:22] <superdump> afaict [09:49:58] <superdump> how do i make the ffmpeg makefile print commands? [09:50:14] <andoma> V=1 [09:50:24] <andoma> IIRC [09:50:28] <spaam> yes [09:52:31] <superdump> hmmmmm [09:52:32] <Kovensky> superdump: check if there isn't any -L/usr/lib before the -lx264, or if there is put a -L/usr/local/lib/ right before -lx264 [09:53:04] <Dark_Shikari> superdump: is local lib in your ld.so.conf? [09:53:06] <Dark_Shikari> I am going to assume no. [09:53:10] <Dark_Shikari> because distros are fucking retarded. [09:53:48] <superdump> it is (gentoo) [09:54:06] <superdump> and i did ldd on the libavcodec.so that was failing with the undefined reference [09:54:13] <Dark_Shikari> LD_LIBRARY_PATH? [09:54:27] <superdump> it is looking at a .107 so from /usr/lib [09:54:37] <superdump> and i don't see any /usr/lib in the command [09:54:40] <superdump> check env [09:54:47] <thresh> it's kind of stupid to put /usr/local/lib in ld.so.conf [09:54:56] <superdump> nope [09:54:57] <thresh> in distros [09:55:03] <superdump> no LD_LIBRARY_PATH [09:55:16] <superdump> very weird indeed [09:55:25] <Kovensky> better double check then? [09:55:37] <Kovensky> (the ld.so.conf thing) [09:55:47] <Kovensky> and add the -L/usr/local/lib anyway for good measure if it still doesn't fix [09:56:58] <superdump> local is the first non-comment line in ld.so.conf [09:57:26] <superdump> and local is the first LD_PATH in the first file (alphanumerically) in /etc/env.d (gentoo people might know what i mean there) [09:57:41] <superdump> /etc/env.d/00basic:LDPATH="/usr/local/lib" [09:58:48] <superdump> meh [09:58:54] * superdump unmerges the system x264 [09:59:29] <superdump> there we go [10:05:23] <lu_zero> superdump: emerge the 9999 one [10:05:53] <superdump> lu_zero: is that masked? [10:05:59] <lu_zero> yup [10:06:28] <lu_zero> for certain packages we keep the live ebuilds in portage and not in overlays... [10:22:41] <lu_zero> uhm [10:22:57] <lu_zero> what's including unistd.h w/out defining _BSD_SOURCE now? [10:23:09] <lu_zero> (in the global headers) [10:24:54] <superdump> lu_zero: you have a query message :) [11:46:33] <Dark_Shikari> hahahahhahaha [11:46:39] <Dark_Shikari> Leonardo Chiariglione is trolling again [11:47:05] <lu_zero> where? [11:47:30] <elenril> the "it's not h.264" guy? [11:47:32] <lu_zero> should I go and deliver a message from you directly? [11:47:44] * kshishkov looks at http://www.fsf.org/campaigns/priority-projects/index_html and thinks what PowerVR drivers are doing there [11:47:57] <thresh> omg, my C compiler will expire in 28 days [11:48:14] <kshishkov> thresh: HP-SUX one? [11:48:20] <thresh> kshishkov: you knew [11:48:23] <lu_zero> thresh: put it in the fridge [11:48:37] <lu_zero> or bake it [11:48:44] <mru> thresh: there are always ways to extend a licence [11:49:15] <kshishkov> mru: you tell that a man from a country with software piracy being almost a governmental policy? [11:51:48] <Dark_Shikari> elenril: yes [11:51:55] <Dark_Shikari> the its not h264 guy [11:51:59] <Dark_Shikari> the Stallman of MPEG [11:52:03] <Dark_Shikari> ITS GNU/LINUX [11:52:59] <mru> Dark_Shikari: url? [11:53:33] <kshishkov> Dark_Shikari: http://www.gnu.org/philosophy/open-source-misses-the-point.html [11:53:48] <Dark_Shikari> mru: this time it's just [11:53:55] <Dark_Shikari> >I am writing a wrapper to H.264 decoder. [11:53:55] <Dark_Shikari> In that case this is not the right forum to address the question [11:53:56] <Dark_Shikari> Leonardo [11:54:20] <mru> where? [11:54:20] <Dark_Shikari> because he's talking about "H.264" as opposed to "ISO/IEC alskjdfksjadlfkjsadlkjf MPEG-4 Part 10 AVC" [11:54:23] <Dark_Shikari> jvt-experts [11:54:42] <mru> what a troll [11:54:47] <Dark_Shikari> he's like a head mpeg guy [11:54:54] <mru> I know [11:55:00] <lu_zero> still a troll [11:55:08] <Dark_Shikari> yup [12:20:14] <Compn> Dark_Shikari : you should photoshop his face onto stallmans [12:20:35] <Compn> Its called AVC herpppp [12:20:58] * Compn actually thinks stallman is a cool dude [12:25:46] <lu_zero> stallman is fun in small doses [12:26:07] <mru> his rambling gets old quickly [12:26:23] <kshishkov> mru: isn't he political activist stuck in 60s? [12:50:49] <DonDiego> if we didn't have rms we would have to invent him :) [12:51:18] <DonDiego> plus, he gave the world a very lasting contribution: copyleft [12:51:46] <BBB> kurosu: docs don't say, they just say 10-bit block post-idct, which means 17-bit inside the end of idct [12:52:30] <BBB> lu_zero: ping [12:52:35] <BBB> lu_zero: ppc ops in patch please? [12:54:56] <BBB> everyone: naming of get_strz -> avio_get_str, is get_str() really what we want? [12:55:07] <BBB> should it be avio_read_str()? or rstr()? [12:59:52] <Zor> the former makes much more sense without looking at what the function does [13:00:53] <lu_zero> BBB: which ops? [13:01:04] <BBB> vc1 idct dude [13:01:06] <lu_zero> drop me an email and I'll write them =) [13:01:09] <lu_zero> uhm? [13:01:29] <lu_zero> I wrote you already the missing bit or I misunderstood the function? [13:02:41] <BBB> I didn't see that [13:05:43] <lu_zero> last night ^^; [13:05:48] <lu_zero> I nopasted it [13:06:10] <lu_zero> basically I made the idct have 2 more parameters [13:06:13] <lu_zero> and then [13:06:34] <BBB> I do that for C also [13:06:50] <BBB> can you send me the patch? [13:06:54] <BBB> I didn't see the nopaste [13:06:57] <BBB> nopasta? [13:06:58] <BBB> antipasta [13:07:09] <lu_zero> if (rangered ) { if (!sign) {vec_sub() ...} vec_sl()... } [13:07:18] <lu_zero> let me pick the one [13:09:28] <lu_zero> http://ffmpeg.pastebin.com/VMSP4Zzh [13:09:41] <lu_zero> that should do what you want [13:10:14] <BBB> where does this thing do the >>= 7 that the C code does? [13:10:17] <BBB> (the original) [13:10:23] <BBB> I couldn't understand a bit of the original code [13:10:51] <lu_zero> there are some macros [13:12:12] <lu_zero> SHIFT_VERT8 [13:12:15] <lu_zero> and SHIFT_VERT4 [13:12:33] <lu_zero> btw I guess might be useful implementing the 8x4 as well, am I wrong? [13:12:49] <Dark_Shikari> BBB: did you go back and look at my old overlap filter asm code? [13:12:51] <Dark_Shikari> while you're at it? [13:13:43] <BBB> Dark_Shikari: no [13:13:46] <BBB> Dark_Shikari: where is it? [13:13:50] <Dark_Shikari> ml [13:14:30] <BBB> later [13:14:33] <BBB> I'm not doing overlap right now [13:14:35] <Dark_Shikari> put it on your list [13:14:37] <Dark_Shikari> don't forget about it [13:14:40] <BBB> one thing at a time [13:14:44] <BBB> right now idct8x8 [13:14:48] <Dark_Shikari> I was never able to test it because vc-1 decoding on my only overlap filter sample was nondeterministic on my computer [13:14:51] <BBB> I'll do other idcts after, they are much cimpler [13:15:03] <BBB> then I'll look at overlap etc. [13:15:22] <BBB> I think we can easily speed this up to be twice as fast [13:15:28] <BBB> but need to stay organized :) [13:15:40] <BBB> so sure will look but haven't yet so far [13:15:51] <BBB> kshishkov: go review my patch! [13:15:56] * BBB goes shower [13:15:57] <kshishkov> ok [13:16:35] <BBB> after this the C code is done and I can re-do the asm to be faster and better and nicer and 17-bit-capable [13:17:19] <kshishkov> BBB: you forgot a line [13:17:26] <kshishkov> <<=1 after each coeff [13:17:54] <Dark_Shikari> do you have rangered samples for testing? [13:17:56] <kshishkov> err, "<<= 1 for each coeff" [13:18:18] <kshishkov> there were some in test bitstreams [13:18:33] <Dark_Shikari> also wtf is rangered for? [13:18:42] <Dark_Shikari> shifting up every coeff just sounds like a higher quant t ome [13:19:19] <kshishkov> it's centered around 128 [13:20:16] <Dark_Shikari> it still doesn't make sense [13:20:44] <BBB> kshishkov: which line where? [13:20:57] <kshishkov> BBB: see in review in a minute [13:21:07] <BBB> kshishkov: I moved the <<= 1 inside the idct [13:21:18] <BBB> I want to merge the idct and the putpixels(), so <<= is now inside the idct [13:22:33] <kshishkov> sent [13:23:25] <BBB> oh [13:23:35] <BBB> lu_zero: you didn't send me that as part of your patch [13:23:36] <BBB> darnit [13:23:37] <BBB> :-p [13:23:52] <BBB> kshishkov: I'll fix that, the idct does that in altivec also but I didn't update the function calls [13:25:04] <BBB> I guess I have to test it now [13:25:14] * BBB goes figure out if ppc crosscompile works on his mac [13:27:58] <BBB> hm, seems to work [13:28:00] <BBB> not bad [13:33:45] <lu_zero> BBB: which? [13:36:42] <BBB> /Users/ronaldbultje/Projects/ffmpeg-git/libavcodec/ppc/vc1dsp_altivec.c:222: error: invalid parameter combination for AltiVec intrinsic [13:36:58] <BBB> that's vec_sub(src0, unsigned_bias); [13:37:12] <kshishkov> signedness mismatch I think [13:37:33] <lu_zero> strange [13:37:43] <kshishkov> maybe bias should be signed? [13:37:53] <lu_zero> they should be the same... [13:37:55] <lu_zero> let me look [13:39:16] <lu_zero> right [13:39:22] <lu_zero> unsigned_bias should be signed =P [13:47:49] <BBB> kshishkov: new msg sent [13:48:07] <kshishkov> let's see... [13:48:21] <BBB> michaelni: yeah I'm a terrible coder, you should just never accept any of my code in ffmpeg@videolan, I'm useless and my code is slow and cranky [13:48:38] <BBB> michaelni: also, make sure to never look at my code, it might be infectious [13:49:02] <lu_zero> what's going on? [13:49:22] <kshishkov> BBB: does that no spew a warning/error on signed_bias init? [13:49:36] <BBB> kshishkov: not for me [13:49:37] <BBB> should it? [13:49:52] <BBB> because of the u16 init? [13:49:56] <BBB> seems to work here [13:49:58] <BBB> should it be s16? [13:50:17] <BBB> both fit [13:50:19] <BBB> so it's fine [13:51:14] <BBB> the second one has to be u16 [13:51:18] <BBB> the first one can be either s16 or u16 [13:51:22] <BBB> maybe s16 is more correct [13:51:30] <BBB> I'm not an altivec expert, just trying to not break existing ops [13:51:44] <lu_zero> ^^; [13:51:53] <lu_zero> and I should be out in -15min... [13:51:54] <lu_zero> =| [13:53:03] <Kovensky> hm, I wonder how to "cyrillize" a syllable that sounds like "ããã", but there's no pause between "ãã" and "ã", so it isn't Ð°ÐœÑÐŸ or Ð°ÐœÐŸ [13:54:13] <kshishkov> Kovensky: Ð°Ðœ'Ð° [13:54:53] <Kovensky> Ð°Ðœ'ÐŸ you mean, or Ð°Ðœ'Ð° indeed? [13:55:23] <kshishkov> Ð°ÐœÑÐŸ it should be officially - see http://en.wikipedia.org/wiki/Polivanov_System [13:55:53] <kshishkov> not that anyboady cares about that [13:56:00] <Kovensky> except I'm not trying to transliterate japanese, it's a portuguese phoneme, it's just that it's the closest one I could think of to explain ._. [13:56:34] <kshishkov> what's original? [13:56:36] * Kovensky is having a try at memorizing cyrillic by using it as a substitution cypher for portuguese / english [13:56:44] <kshishkov> (in Portuguese) [13:56:46] <Kovensky> "Ã£o" [13:56:58] <kshishkov> Ð°ÐœÑÐŸ [13:57:13] <Kovensky> so my blind guess was correct? :D [13:57:25] <kshishkov> not exactly [13:57:49] <kshishkov> it's ÐœÑ for Ã± [13:57:57] <Kovensky> well, that's what I used to write "sÃ£o", ÑÐ°ÐœÑÐŸ [13:58:14] <kshishkov> we write simply "ÑÐ°Ðœ" [13:59:21] <Kovensky> well, I want the ÑÐ°Ðœ sound but with a vowel following it [14:00:02] <kshishkov> it's Russian, nobody cares much since it often sounds differently from written form [14:07:37] <BBB> kshishkov: thanks, will get back to simd now [14:07:45] <BBB> time to make this codec faster [14:07:55] <kshishkov> :) [14:08:08] <kshishkov> I'd like it to have more supported features instead [14:08:16] <BBB> the two are orthogonal [14:08:19] <kshishkov> i.e. WVP2 [14:08:26] <BBB> why don't you make it have more features, and I'll work on more speed [14:08:29] <BBB> wvp2 would be nice [14:08:40] <BBB> I looked at it and I have to admit, the dll was cryptic to me [14:09:00] <kshishkov> I'm maintaining it (newspeak for not doing anything if you forgot) [14:09:11] <BBB> I notice :-p [14:09:20] <BBB> why don't you give up maintainership and go do cool stuff with it [14:09:23] <BBB> say, interlaced [14:09:34] * kshishkov is working on SMUSH instead [14:09:35] <kierank> interlaced is not cool [14:09:43] <kshishkov> by definition [14:10:00] <kshishkov> BBB: http://codecs.multimedia.cx/?p=295 to refresh your memory [14:12:28] <BBB> "include me out" ? :-p [14:12:31] <BBB> =exclude me [14:13:32] <BBB> kshishkov: I'll buy you beer if you finish vc1-interlaced [14:13:47] <BBB> brb [14:14:22] <kshishkov> BBB: 1) those were famous words of Samuel Goldwyn 2) I don't drink beer, so include me out there as well [14:14:24] <kierank> that's going to do a lot of good... [14:14:52] <Kovensky> BBB: buy kshishkov trocadero instead [14:15:12] <kshishkov> Kovensky: exactly! [14:15:24] <kshishkov> Kovensky: though good luck finding it outside Sweden [14:15:36] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * rc8c0189d62 ffmpeg/libavfilter/ (Makefile vf_pad.c vsrc_color.c): [14:15:36] <CIA-15> ffmpeg: lavfi: put color source in a dedicated file [14:15:36] <CIA-15> ffmpeg: Move the color source code from vf_pad.c to vsrc_color.c. [14:15:36] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:15:40] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r5ad06110e0 ffmpeg/libavfilter/ (Makefile drawutils.c drawutils.h vf_pad.c): [14:15:40] <CIA-15> ffmpeg: lavfi: add drawutils [14:15:40] <CIA-15> ffmpeg: Add drawutils.h and drawutils.c, and use them in the pad filter. [14:15:40] <CIA-15> ffmpeg: The new functions are going to be shared by other filters. [14:15:41] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:15:53] <kierank> probably some trocadero in london [14:16:21] <lu_zero> 15:15 <@kshishkov> Kovensky: though good luck finding it outside Sweden [14:16:45] <lu_zero> if it is a apple+lemon juice diluited in water [14:16:47] <lu_zero> I found it [14:16:56] <kshishkov> apple+orange+cola [14:17:09] <lu_zero> cola or soda? [14:17:35] <kshishkov> http://en.wikipedia.org/wiki/Trocadero_%28drink%29 <- look for word Caffeine [14:17:42] * lu_zero grew fond of apple+lemon+still water [14:18:19] <kshishkov> some Germans love cola+orange juice but they still haven't reinvented Trocadero [14:19:10] <mru> germans are crazy [14:19:15] <mru> they mix beer with other things [14:19:34] <kshishkov> because they're not allowed to premix them [14:19:45] <kshishkov> (and still call it beer) [14:20:10] <twnqx> you can buy Diesel or Radler just fine (beer+cola, beer+applejuice+soda) [14:20:36] <mru> kshishkov: proper english bitter ain't mixed with anything [14:20:52] <mru> it's brewed from the purest barley, hops, yeast, and pond water [14:21:53] <Kovensky> reminds me to go play Pharaoh [14:21:59] <Kovensky> beer was srsbsnss in ancient egypt [14:23:34] <kshishkov> so? [14:23:49] <thresh> mmmm, beer [14:24:05] <kshishkov> hmm, Homer Simpson [14:24:06] <lu_zero> pond water? [14:24:20] <lu_zero> as in murky water? [14:24:34] <kshishkov> lu_zero: yep, if nobody lives in that water it's not suitable for drinking [14:24:36] <mru> lu_zero: ale can be similar in appearance to pond water [14:25:01] <lu_zero> ^^' [14:25:37] <mru> kshishkov: you should go to new york then, they have little critters living in the tap water [14:25:48] <lu_zero> o_O [14:25:51] <mru> much to the annoyance of the local jews [14:25:59] <lu_zero> why? [14:26:06] <mru> not kosher [14:26:12] <lu_zero> ... [14:26:47] <kshishkov> mru: well, I liked water from lake MÃ€laren [14:28:14] <kierank> I drank a bottle of holy water once [14:28:25] <mru> lu_zero: http://www.wwdmag.com/wwd/index.cfm/fuseaction/shownewsitem/newsitemid/7199 [14:31:24] <kshishkov> kierank: well, for you it's not as bad as eating holy beef [14:31:44] <kierank> for me? [14:31:48] <kshishkov> yep [14:32:16] <mru> and unholy beef? [14:32:28] * kierank wasn't aware beef was holy [14:32:53] <mru> a well-prepared steak sure tastes divine... [14:33:00] <kshishkov> kierank: come to British outsourced ex-colony and ask [14:33:24] * kshishkov prefers holy and kosher prok instead [14:33:36] <kierank> kshishkov: I don't plan to go there [14:33:51] <mru> remember the time ods15 ate pork? [14:34:00] <cartman> kierank: fear of cavity search? [14:34:20] <kshishkov> mru: I fear not many people here remember Oded at all [14:34:34] <mru> wiesbaden '06 [14:34:45] * cartman remebers Oded [14:34:52] <cartman> and his damn broken vorbis encoder [14:35:03] <cartman> so does some people over at youtube I think :P [14:35:07] <mru> he and kshishkov are running a competition [14:35:18] * kshishkov is still in winning position [14:35:33] <lu_zero> ods15: still alive? [14:36:52] <cartman> wbs: they finally fixed my crasher bug \Ã¶/ (NDK) [14:36:58] <mru> "Moore's Law of Mad Science: Every 18 months, the minimum IQ necessary to destroy the world drops by one point." - Eliezer Yudkowsky [14:37:46] <lu_zero> "press button to end" [14:38:14] <lu_zero> cartman: \o/ [14:38:28] <kshishkov> lu_zero: when it will be that easy people would be complete morong not able to do it anyway [14:38:32] <wbs> cartman: wooh, congrats [14:38:42] <wbs> cartman: any link to info about it? [14:38:46] <mru> cartman: which bug? [14:39:04] <cartman> wbs, mru https://review.source.android.com//#change,21309 [14:40:16] <lu_zero> eh eh [14:40:38] <kshishkov> lu_zero: see, it's good to be an optimist [14:41:07] <mru> well, pessimism isn't likely to work [14:41:19] <kierank> cartman: gerrit code review is horrible [14:41:31] <cartman> kierank: agreed [14:41:39] <mru> kierank: yes, we know [14:41:52] <kierank> though not as bad as melange [14:41:57] <cartman> in other news my boss claims to find an Android tablet with Android *2.5* [14:42:06] <kierank> cartman: fake chinese one? [14:42:16] <kshishkov> cartman: you can hack it to report any version you like [14:42:17] <cartman> kierank: at least I warned him :D [14:42:23] <cartman> kshishkov: I know [14:42:30] <kshishkov> cartman: I owned RAR version 5.0 [14:42:34] <lu_zero> kierank: why horrible? [14:42:44] <cartman> kshishkov: nice patching skillz [14:42:46] <kshishkov> cartman: in the time when only v2.0 was available [14:42:52] <mru> lu_zero: try using it [14:43:01] <lu_zero> did [14:43:11] <cartman> Gerrit works fine with read only mode [14:43:12] <mru> did you succeed? [14:43:15] <lu_zero> at least in the vpx incarnation [14:43:17] <lu_zero> sure [14:43:24] <lu_zero> was quite easy... [14:44:32] <kierank> lu_zero: gerrit looks awful. totall unreadable [14:44:39] <kierank> needs a ux consultant stat [14:48:12] <mru> why are _all_ the search bots crawling my server at the same time? [14:48:21] <mru> google, yandex, and bing [14:48:31] <mru> and yahoo [14:49:01] <thresh> well, I can surely say for yandex one [14:49:10] <thresh> it tries to be as good as goog one [14:49:30] <mru> bing is evil [14:49:30] <thresh> and why does bing try to crawl your server is unknown... [14:49:44] <mru> well, try it might... I blocked it [14:49:53] <lu_zero> ^^; [14:49:56] <mru> it was way too aggressive [14:50:08] <mru> google is much nicer [14:50:18] <mru> doesn't pull everything as fast as possible [14:50:39] <mru> and I don't care about bing [15:04:48] <elenril> BBB: ping [15:05:58] <mru> who the hell wrote this? while (h --> 0) [15:06:06] <elenril> lol [15:06:23] <kshishkov> mru: it's self-explanatory [15:06:30] <kierank> as h tends to zero [15:06:31] <elenril> a mathematician [15:06:31] <mru> git says it was Yuvi [15:06:50] <kierank> FruitCode (tm) [15:06:51] <mru> points for creative use of C operators [15:07:05] <Tjoppen> hah, awesome [15:09:17] * elenril wonders what happened to mergig -mt [15:09:28] <kshishkov> BBB happened [15:09:44] <elenril> he said it's working and ready [15:13:08] <BBB> mru: I saw that somewhere also [15:13:12] <BBB> mru: I thought it looked funny [15:13:19] <BBB> kshishkov: ? [15:13:27] <mru> BBB: vp8 altivec code [15:13:32] <BBB> elenril: pong, patch is queued, was waiting for kostya to review my vc1 patch so I can commit together [15:13:41] <BBB> mru: aha... the one that's still broken [15:13:49] <mru> should be easy to fix [15:14:01] <BBB> kshishkov: so ok to commit all my stuff? [15:15:20] <BBB> elenril: unless the ping was for something else [15:15:53] <BBB> elenril: oh and for -mt, atrange had a patch but told me to not commit it yet (huffyuv) [15:16:03] <BBB> elenril: so I'm waiting for astrange to respond to that [15:22:05] <kshishkov> BBB: not all, only the one I sayed okay to commit [15:22:22] <BBB> right :) [15:22:36] <BBB> did someone ok the non-static'ing of ff_put/add/put_signed_pixels? [15:22:47] <BBB> *_clamped_c() [15:23:10] <ruggles> if i get "(standard_in) 1: syntax error" when running a fate test, where should i start looking for the problem? [15:23:13] <BBB> I think mru and alex did [15:23:26] <BBB> ruggles: make V=1 [15:23:57] <elenril> BBB: what about get_* [15:24:07] <BBB> elenril: will review after that [15:24:18] <elenril> ok [15:24:20] <mru> ruggles: that usually means the decoder died without producing any output [15:24:20] <BBB> elenril: sorry, I do think full review of these patches is good, even if the conceptually look good [15:24:25] <BBB> and you have to admit, they are massive :) [15:24:28] <elenril> "full" [15:24:34] <ruggles> mru: thanks [15:24:35] <BBB> so I like your "small" patches, I can at least read them [15:24:38] <elenril> you're going to read through 3k lines? [15:24:42] <BBB> sorta [15:24:47] <elenril> good luck with that :) [15:24:48] <BBB> someone has to do it [15:25:00] <BBB> did you fix the rbe32 -> rb32? [15:25:04] <mru> ruggles: I suppose the error message could be improved [15:25:13] <elenril> you said you'd fix it yourself [15:25:23] <elenril> but i think i fixed that locally too [15:25:27] <BBB> oh right I did [15:25:28] <elenril> should i send it? [15:25:29] <BBB> no [15:25:31] <BBB> I'll do it [15:25:43] <BBB> I'm just getting in office, so I'm a little sleepy [15:25:45] <BBB> need coffee [15:25:50] <BBB> please excuse my nonsense [15:26:09] * elenril mumbles something about people in weird timezones ;) [15:26:27] <BBB> make -j8 fate is awesome indeed [15:26:29] * BBB pets mru [15:26:33] <BBB> good boy [15:26:42] <BBB> now can we make fate use threads by default if the codec supports it? [15:26:45] * elenril wishes he had a cpu for that [15:27:21] <elenril> also anybody with knowledge of mpegaudio here? [15:27:39] * mru knows it's obsolete [15:27:55] * elenril deprecates mru [15:27:57] <kshishkov> elenril: probably me [15:28:20] <BBB> committed [15:28:24] <BBB> elenril: on the get_ patch now [15:28:27] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rbbfd2e7ab4 ffmpeg/libavcodec/vc1dec.c: [15:28:27] <CIA-15> ffmpeg: VC1: inline vc1_put_block() in vc1_decode_i_blocks(). [15:28:27] <CIA-15> ffmpeg: Advantage is that it allows us to combine several loops into a single [15:28:27] <CIA-15> ffmpeg: one, and these can eventually be merged into the IDCT itself. Also, it [15:28:27] <CIA-15> ffmpeg: allows us to remove vc1_put_block(), and makes CODEC_FLAG_GRAY faster. [15:28:29] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r8d9ac969cb ffmpeg/libavformat/ (avidec.c avio.h aviobuf.c rdt.c wtv.c): [15:28:29] <CIA-15> ffmpeg: avio: rename av_alloc_put_byte -> avio_alloc_context for consistency [15:28:29] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [15:28:33] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rf8bed30d8b ffmpeg/libavcodec/ (ppc/vc1dsp_altivec.c vc1.c vc1dec.c vc1dsp.c vc1dsp.h): [15:28:33] <CIA-15> ffmpeg: VC1: merge idct8x8, coeff adjustments and put_pixels. [15:28:33] <CIA-15> ffmpeg: Merging these functions allows merging some loops, which makes the [15:28:33] <CIA-15> ffmpeg: results (particularly after SIMD optimizations) much faster. [15:28:34] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r484a337cd7 ffmpeg/libavcodec/ (dsputil.c dsputil.h): dsputil: make {add/put/put_signed}_pixels_clamped() non-static. [15:29:01] <elenril> kshishkov: does http://pastebin.com/h9wNxjtV look remotely sane as a solution to https://roundup.ffmpeg.org/issue2598 [15:29:57] <BBB> oh yeah [15:29:58] <kshishkov> elenril: yes and no [15:30:03] <BBB> elenril: ping, what about read_partial [15:30:04] <BBB> ? [15:30:19] <BBB> elenril: I'd prefer it private if we can't figure out why specifically it would have to be exposed [15:30:24] <kshishkov> elenril: it will make results the same but I don't know if that's wanted behaviour [15:30:26] <elenril> dunno, looks potentially useful [15:31:04] <elenril> kshishkov: why not? [15:31:14] <mru> elenril: I think it makes sense [15:31:36] <mru> flush() should reset all state [15:32:48] <elenril> BBB: ok, i'll make it private for now and wait for people to complain [15:34:30] <elenril> fortunately it's only used in one place so splitting it out is easy [15:35:04] * elenril <3 git checkout -p [15:38:32] <Kovensky> 12:37.16 marcan: last time I tried comparing MSVC vs. gcc, gcc produced 30% faster code, but only if you optimize for i386 instead of core2 :P [15:38:35] <Kovensky> 12:37.36 marcan: (i.e. i386 gcc was 30% faster than core2 msvc, core2 gcc was roughly the same) [15:38:39] <Kovensky> 12:37.40 marcan: (beats me) [15:38:43] <BBB> elenril: simply ignore read_partial for now [15:38:53] <BBB> elenril: so leave it as get_buffer_partial [15:38:58] <BBB> we'll rename it with the other private symbols later [15:39:03] <BBB> smaller patch = awesome [15:39:16] <elenril> i'll split it in a separate patch [15:39:22] <BBB> elenril: if you can send a new patch I'll review it right away [15:39:49] <Kovensky> 12:39.03 BBB: smaller patch = awesome <-- no, no, you're doing it wrong, it's "smaller = awesomer" [15:40:50] * elenril make -j4 [15:41:20] <elenril> arrrgh, it's rebuilding lavc for whatever reason again [15:41:41] <mru> get a real computer [15:41:44] <mru> then you won't care [15:41:58] <elenril> ENOMONIES [15:42:22] <mru> get a job [15:42:23] <spaam> elenril: use ccache! [15:42:32] <mru> or use cash [15:42:43] <elenril> physics > job [15:42:47] <spaam> "get a job"++ [15:42:57] <spaam> even i got a job ;) [15:43:07] <elenril> anyway, patch sent [15:44:18] <mru> there, valgrind is happy again [15:50:06] <BBB> mru: \o/ [15:50:19] <spaam> mru: good boy [15:51:08] <mru> why do people write such sloppy code [15:51:20] <mru> the proper one is faster too [15:51:29] <BBB> because we're lazy [15:53:07] <spaam> mru: time to get better to review code ;) [15:56:23] <BBB> - if ((ret = get_buffer(s->pb, header, 8)) < 0) [15:56:24] <BBB> + if ((ret = avio_read(s->pb, header, 8)) < 0) [15:56:24] <BBB> return ret; [15:56:24] <BBB> fourcc_tag = AV_RL32(&header[0]); [15:56:24] <BBB> size = AV_RL32(&header[4]); [15:56:27] * BBB wonders ... [15:56:37] <elenril> i was just wondering if you fell asleep yet [15:57:04] <BBB> I guess I was about to [15:58:26] <elenril> what's so interesting in the abov code? [15:59:26] <elenril> and what do you hope to prove by reading through it? bugs in sed? [16:01:12] <BBB> fourcc_tag = avio_rl32(s->pv); etc. [16:01:30] <BBB> it's not a bug in your patch [16:01:36] <BBB> it's an inconsistency in the original code [16:01:44] <BBB> - get_le32(pb); /* CRYO */ [16:01:44] <BBB> - get_le32(pb); /* _APC */ [16:01:44] <BBB> - get_le32(pb); /* 1.20 */ [16:01:44] <BBB> + avio_rl32(pb); /* CRYO */ [16:01:45] <BBB> + avio_rl32(pb); /* _APC */ [16:01:45] <BBB> + avio_rl32(pb); /* 1.20 */ [16:01:50] <elenril> yeah i guess [16:01:50] <mru> elenril: ffmpeg is known to expose bugs in almost anything [16:01:52] <BBB> another one, this should be url_fskip() [16:02:20] <BBB> elenril: don't change your patch, I'm just rambling about stuff as coffee takes effect [16:02:22] <BBB> your patch is fine so far [16:02:25] <mru> BBB: sure, but that's orthogonal to this patch [16:02:30] <elenril> i think you're wasting time on this [16:02:38] <BBB> ok I'll go quicker [16:03:10] <elenril> obviously you'll find tons of broken/suboptimal code [16:03:17] <elenril> we can't fix all of it at once [16:03:43] <BBB> ff_ape_parse_tag(), your patch misaligns comments [16:04:14] * BBB fixes locally [16:04:15] <elenril> and in a zillion other places i guess [16:04:25] <elenril> there should be a tool for aligning comments [16:04:50] <elenril> more importantly though -- what should we do about put_nbyte/put_tag? [16:05:02] <elenril> make them private perhaps? [16:05:13] <elenril> and wait if anyone complains [16:06:11] <merbzt> put_nbyte is new [16:07:27] <elenril> i see it's only used in the spdif muxer [16:07:30] <BBB> what is put_nbyte()? [16:07:57] <elenril> memset [16:08:01] <elenril> basically [16:21:08] <BBB> elenril: sounds like it can be internal for now, I don't see a need for that to be exposed [16:23:28] <elenril> put_tag looks much more useful OTOH [16:23:47] <elenril> git grep returns 170 lines [16:24:37] <BBB> so that's basically put_str() except you don't need to tell it the length of the string? [16:24:44] <BBB> it sounds like the equivalent of get_strz() [16:25:10] <BBB> patch looks good, I did some formatting things but nothing major [16:25:23] <BBB> let's run make fate [16:25:26] <elenril> not it's exactly the same as put_str, but it doesn't terminate the string [16:27:14] <BBB> sounds like put_str() doesn't need to always write the null anyway [16:27:39] <BBB> it doesn't use put_buffer, so it wouldn't be as fast [16:30:06] <BBB> it makes me wonder whether we shouldn't just merge the two, have an extra argument "int needs_zero" or so [16:30:43] <mru> BBB: was that you who broke the ppc build? [16:30:49] <BBB> mru: no! I tested it! [16:30:59] <mru> fate disagrees [16:31:13] <BBB> :'( [16:31:16] <BBB> I really tested it [16:31:18] <BBB> I promise [16:31:24] <mru> tell that to fate [16:31:40] <elenril> yeah, that might be better [16:31:55] <mru> it's fussing about signed/unsigned mismatch [16:32:04] <elenril> but adding a new argument to all those put_tag() will be fun [16:32:06] <mru> iirc lu_zero was saying something to the same effect a while ago [16:32:15] <BBB> mru: const vector signed short signed_bias = vec_sl(vec_splat_u16(4), [16:32:15] <BBB> vec_splat_u16(4)); [16:32:19] <BBB> mru: change the first u16 into s16 [16:32:23] <BBB> mru: that would fix it [16:32:38] <BBB> my compiler didn't care [16:33:35] <BBB> as for the "statement with no effect", I don't know, lu_zero wrote it [16:33:48] <BBB> maybe you need to store the result, as in src0 = vec_sl(src0, ..);? [16:33:58] <mru> blaming the italians, are we? [16:34:05] <BBB> he should know altivec better than me [16:34:19] <mru> better than me as well [16:34:26] <BBB> not good enough apparently [16:34:57] <mru> how did you test it? [16:34:59] <BBB> can you fix or should I fix? [16:35:05] <BBB> I tested that it compiled [16:35:16] <mru> on what system? [16:35:27] <BBB> cross-compile using powerpc-gcc on x86 [16:35:35] <BBB> I have a cross-compile toolchain from apple for ppc [16:35:42] <BBB> altivec and so on was enabled [16:36:10] <mru> you're using apple stuff to test things!???!!! [16:36:23] * BBB associates ppc with apple [16:36:33] * mru associates apple with rotten [16:36:47] * BBB learns that ppc associates with rotten [16:37:07] * divVerent associates Amiga with 68k [16:37:16] * elenril learns that rottenness is transitive [16:37:17] * divVerent associated 68k with Apple [16:38:09] <BBB> mru: you or me? [16:38:17] <BBB> mru: I can re-test it on your ppc and fix it properly [16:38:24] <BBB> it just takes forever [16:38:31] <mru> do you have a file that uses that code? [16:38:58] <BBB> not in fate [16:39:03] <mru> anywhere? [16:39:16] <BBB> probably in my collection, I have to scan it [16:40:19] <BBB> for now, use src0 = vec_sub/sl(src0, ...) instead of vec_sub/sl(src0, ...) [16:40:25] <BBB> and change u16 -> s16 [16:40:27] <BBB> should work [16:40:35] <mru> that builds [16:40:35] <BBB> I'll figure out a test that we can add to fate [16:40:44] <mru> but I'd prefer to test it too [16:40:52] <BBB> I don't have a sample right now [16:45:55] <BBB> mru: elenril's last patch ok? [16:50:43] <mru> hmm, seems like old gcc is less picky about that code [16:50:52] <mru> and apple is old [16:50:57] <mru> old apples are rotten [16:51:48] <BBB> apple <3 [17:02:51] <_av500_> gm [17:04:22] <elenril> libavformat/movenc.c | 880 +++++++++++++++++++++--------------------- << wow [17:08:44] <BBB> elenril: ? [17:09:36] * _av500_ guesses somwe av prefixing work [17:09:41] <_av500_> -w [17:10:14] <mru> _av500_: I see you already got yours [17:10:31] <_av500_> yeah [17:10:41] <_av500_> i was but number [17:10:44] <_av500_> +a [17:10:56] <_av500_> damn tiny kbd [17:28:12] <elenril> BBB: that's prefixes for put_ [17:29:02] <elenril> so are we waiting for something? [17:29:13] <BBB> nobody else wants to review? [17:29:17] <BBB> last one looked ok to me [17:29:18] <BBB> let me apply [17:29:56] * elenril creates a mailbox for death threats [17:30:14] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rb7effd4e83 ffmpeg/libavformat/ (107 files): (log message trimmed) [17:30:14] <CIA-15> ffmpeg: avio: avio_ prefixes for get_* functions [17:30:14] <CIA-15> ffmpeg: In the name of consistency: [17:30:14] <CIA-15> ffmpeg: get_byte -> avio_r8 [17:30:14] <CIA-15> ffmpeg: get_<type> -> avio_r<type> [17:30:15] <CIA-15> ffmpeg: get_buffer -> avio_read [17:30:15] <CIA-15> ffmpeg: get_partial_buffer will be made private later [17:33:00] <Tjoppen> damnit, psu fan is starting to give up [17:34:57] * elenril kicks clang [17:35:13] <elenril> why doesn't it warn about return foo; in a void function [17:40:52] <Tjoppen> does it warn about non-void not returning anything? [18:25:16] <BBB> elenril: read_partial doesn't apply [18:25:24] <BBB> elenril: it looks good, can you rebase and such? [18:26:11] <elenril> rebases fine for me [18:28:39] <BBB> odd [18:28:44] <BBB> let me look at it again after lunch [18:29:15] <elenril> sent rebased version [18:29:22] <elenril> and a little bonus [18:29:34] <DevilCode2> hey all [18:30:40] <DevilCode2> Can anyone tell me why when i try to make a .mpeg from a folder of jpg's i get just a black video [18:32:06] <elenril> DevilCode2: user questions belong in #ffmpeg [18:32:16] <DevilCode2> i know but there is no one there [18:33:13] * elenril sees 176 people there [18:33:15] <DevilCode2> oh i mistyped [18:33:18] <DevilCode2> dam ././ [18:33:20] <DevilCode2> sry [18:34:47] <elenril> BBB: any ideas for a new name for put_nbyte [18:34:57] <elenril> ffio_wn8 sounds obfuscated [18:35:13] <mru> ffio_fill? [18:37:40] <BBB> ffio_memset, ffio_fill, ffio_splat [18:37:45] <BBB> whichever you want [18:37:58] <mru> mem? [18:38:06] <BBB> good point [18:38:10] <BBB> ffio_set sounds stupid [18:38:15] <BBB> so let's forget about that one [18:38:19] <BBB> ffio_fill/splat is ok with me [18:39:02] <mru> elenril: take your pick [18:41:09] <BBB> and get_partial applied [18:41:49] <BBB> (locally) [18:41:54] <BBB> now on to the put one [18:42:01] <BBB> elenril: the put one is the last massive one right? [18:50:07] <elenril> BBB: i hope so [18:50:13] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rb3db9ceef1 ffmpeg/libavformat/ (avio.h avio_internal.h aviobuf.c rawdec.c): [18:50:13] <CIA-15> ffmpeg: avio: make get_partial_buffer internal. [18:50:13] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [18:50:17] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r78e2380a6d ffmpeg/libavcodec/targa.c: targa: prevent integer overflow in bufsize check. [18:50:28] <elenril> BBB: what's up with CCs [18:50:45] <mru> git-send-email config thing [18:51:20] <elenril> no, those aren't git-send-emailed [18:51:30] <mru> git send-email sets a cc by default [18:51:37] <mru> and that's picked up various mailers when you reply [19:05:49] <BBB> ah damnit, I lost [19:06:37] * elenril devises a regexp to add an argument to all instances of put_tag [19:09:30] <BBB> elenril: don't, yet [19:09:31] <Kovensky> /elenril/d [19:09:39] <BBB> elenril: that was just my personal opinion, make sure others agree [19:09:46] <BBB> otherwise you waste your time [19:09:48] <BBB> which would suck [19:10:03] <BBB> so ffio_splat() is not fashionable? [19:10:20] * elenril is iowaiting anyway [19:10:23] <mru> I would choose fill personally [19:10:35] <BBB> he did too [19:10:37] <mru> but I'm not going to fuss over the name [19:10:37] <BBB> ok, will apply [19:10:42] <BBB> no, fill is fine [19:10:48] <BBB> just spat sounds fancy [19:11:11] <elenril> obscure to non-native speakers [19:11:32] <mru> native to obscure speakers [19:12:05] <BBB> I guess that patch needs put first [19:12:09] <BBB> ok, will continue on that one then [19:12:11] <BBB> blegh [19:15:20] <BBB> elenril: now, as for put_tag [19:15:29] <BBB> I'm seeing a lot of four-letter strings being written that way [19:15:36] <BBB> that is not a great way of doing business [19:16:32] <BBB> not sure how difficult that is to do regexp-wise, but can you cahnge put_tag("????") into avio_wl32(AV_RL32("????")) for these cases? [19:16:45] <BBB> or alternatively use MKTAG(), but that may be supercomplex [19:17:01] <mru> we really shouldn't be doing AV_RL32("....") [19:17:04] <BBB> the compiler should be able to optimize out the AV_RL32("????") into a proper 32-bit int [19:17:10] <mru> no, it can't [19:17:14] <BBB> hm [19:17:16] <mru> it's inline asm on some targets [19:17:18] <BBB> I've seen it used in various places [19:17:24] <mru> those should be fixed [19:17:26] <BBB> ok [19:17:27] <elenril> i'd go with MKTAG [19:17:30] <BBB> then it should be MKTAG [19:17:33] <BBB> now, I agree this sucks [19:17:38] <BBB> but it would perform much better [19:18:04] <mru> perhaps we should introduce a variant of the macro to be used on constant data [19:18:24] <elenril> BBB: your mind was corrupted by writing speed-critical code too long =p [19:19:03] <mru> no, his mind was cleansed [19:20:00] <elenril> in most/all those put_tag() calls, readability is much more important than performance [19:21:06] <BBB> I think it makes sense to keep the "...." as a string [19:21:12] <mru> yes [19:21:22] <BBB> but for four-letter ones, I think it makes sense to write all four bytes at once [19:21:26] <BBB> using avio_wl32 [19:22:48] <BBB> unless you want to define it as a private wrapper around it, e.g. #define (or static inline) ffio_write_tag(pb, "xxxx") ffio_wn32(pb, *(uint32_t*)"xxxx") [19:22:53] <BBB> where wn32 is the native variant [19:22:59] <BBB> there's probably a reason why the above isn't valid [19:23:08] <BBB> but something along those lines would be ok [19:23:14] <BBB> and probably remove 99% of all put_tag() uses [19:23:35] <mru> *(uint32_t*)"xxxx" is a bad idea [19:24:01] <elenril> is that even valid? [19:24:06] <mru> the compiler might do the right thing, but the C spec doesn't guarantee it [19:24:25] <mru> gcc is extra buggy actually [19:24:36] <mru> it believes string literals aren't lvalues [19:24:58] <mru> and throws a wobbly if you use them with memory constraints in inline asm [19:25:32] <BBB> hm [19:25:34] <BBB> so [19:25:39] <BBB> something along those lines then [19:26:29] <BBB> #define ffio_wtag(pb, str) av_wl32(pb, MKTAG(str[0],str[1],str[2],str[3])) [19:26:35] <BBB> should be valid [19:27:51] <mru> should be [19:28:24] <BBB> elenril: is that useful? [19:28:51] <elenril> rewriting all those put_tag() will be PITA [19:29:09] <mru> sed it [19:29:11] <BBB> elenril: you can even do (if you care a lot) #ifdef LITTLE_ENDIAN the above #else #define ffio_wtag(pb, str) av_wb32(pb, MKBETAG(str[0], str[1], str[2], str[3])) #endif [19:29:49] <BBB> but I don't think it matters much right now [19:29:51] <BBB> so don't do it [19:29:58] <mru> lu_zero: ping [19:30:41] <BBB> mru: could we cheat and make av_wn{16,32} abuse proper-endianness of input and write multiple bytes at once? [19:30:49] <BBB> or is that again undefined? [19:31:22] <mru> they could use AV_W* macros internally [19:31:52] <mru> lu_zero: please review my ppc patches [19:41:55] <BBB> would require a lot of ifs [19:42:15] <BBB> if (buf_end-buf>=4)AV_WL32() else av_w8 loop [19:42:21] <BBB> but would be useful, ues [19:56:14] * lu_zero is just back... [19:58:26] <BBB> no more comments on the put patches? [19:59:43] <lu_zero> let thunderbird fetch the emails =) [20:00:06] * Flameeyes replaces lu_zero's thunderbird with gnus [20:00:25] <lu_zero> Flameeyes: it would have problems with the threads I'm afraid... [20:00:49] <Flameeyes> why would it? gnus was born to handle newsgroups, it's tremendously nice for mailing lists as well [20:00:57] <mru> and mail in general [20:01:11] <mru> it's a tad slow opening huge imap folders [20:01:14] <lu_zero> I'll give a try [20:01:24] <lu_zero> mru: ugh... [20:01:36] <mru> Flameeyes: have you noticed that too? [20:01:40] <mru> or am I holding it wrong? [20:02:23] <mru> lu_zero: what I mean is it takes a few seconds to open a folder with several years worth of ffmpeg-devel [20:03:04] <Flameeyes> mru: I have actually stopped using it a while back for various issues [20:04:22] <mru> I haven't found anything better [20:04:28] <lu_zero> mru: I'll give a try sooner or later [20:05:32] <bilboed> takes 2s to open a folder with 834092 mails in evolution... [20:05:41] <lu_zero> bilboed: which network? [20:05:55] <lu_zero> thunderbird is perfect on decent networks... [20:06:11] <bilboed> what do you mean "which network" ? You're a masochist if you don't cache the headers locally [20:06:58] <mru> I think the problem has something to do with gnus liking to keep a private record of exactly which messages I've replied to or done other things with [20:07:04] <lu_zero> bilboed: even if you cache it... [20:07:49] <bilboed> lu_zero, try 2.91.6.2 :) [20:07:49] <mru> on ffmpeg-devel I reply to a lot of messages, so it ends up with a _very_ long list [20:09:29] * BBB hears no more comments [20:09:38] * BBB pushes elenril's last patches [20:10:14] * Kovensky sees no push [20:10:20] <BBB> slow... [20:10:23] <BBB> big patch [20:10:29] * BBB gives elenril the evil look [20:10:36] * Kovensky wonders what about h264-mt [20:10:44] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r77eb5504d3 ffmpeg/ (59 files in 2 dirs): (log message trimmed) [20:10:45] <CIA-15> ffmpeg: avio: avio: avio_ prefixes for put_* functions [20:10:45] <CIA-15> ffmpeg: In the name of consistency: [20:10:45] <CIA-15> ffmpeg: put_byte -> avio_w8 [20:10:45] <CIA-15> ffmpeg: put_<type> -> avio_w<type> [20:10:45] <CIA-15> ffmpeg: put_buffer -> avio_write [20:10:45] <CIA-15> ffmpeg: put_nbyte will be made private [20:10:46] * elenril gets moar git blame points [20:10:53] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r0ac8e2bf2b ffmpeg/libavformat/ (avio.h avio_internal.h aviobuf.c spdifenc.c): [20:10:53] <CIA-15> ffmpeg: avio: make put_nbyte internal. [20:10:53] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [20:10:54] <BBB> there you go [20:10:59] <elenril> \\o// [20:11:04] <BBB> you must be top patch committer in number of lines at least now [20:11:17] <BBB> maybe we should subtract number of lines removed [20:11:21] <gnafu[away]> elenril: Is that Goro when he's rejoicing? [20:11:26] <elenril> i think mru's dca prettyprinting is still bigger [20:11:49] <BBB> what's next? [20:11:57] <elenril> put_tag? [20:12:02] <BBB> is the macro ok? [20:12:27] <BBB> #define ffio_wtag(pb, tag) ffio_wl32(pb, MKTAG(tag[0], tag[1], tag[2], tag[3])) [20:12:49] <mru> lu_zero: and the altivec vp8 epel patch? [20:13:11] <mru> BBB: maybe add some () like so: (tag)[0] etc [20:13:14] <mru> just in case [20:14:43] <BBB> I see only 2 cases whereit's not 4 chars [20:14:58] <mru> and what is it there? [20:15:02] <BBB> for these, we can figure out something else... maybe avio_put_str() can be converted [20:15:05] <mru> and what might someone do in the future? [20:15:11] <BBB> libavformat/swfenc.c: put_tag(pb, "FWS"); [20:15:12] <BBB> libavformat/swfenc.c: put_tag(pb, "video"); [20:15:14] <dalias> greets [20:15:18] <BBB> libavformat/rmenc.c: put_tag(s,"VIDORV10"); [20:15:18] <BBB> libavformat/rmenc.c: put_tag(s,"VIDORV20"); [20:15:29] <BBB> the rmenc ones can be replaced by two put_tags [20:15:38] <BBB> the one in swfenc ... well ... dunno [20:15:53] <mru> it has a terminating nul byte [20:15:59] <BBB> put_tag(pb, "video"); [20:15:59] <BBB> avio_w8(pb, 0x00); [20:16:02] <BBB> easy enough [20:16:04] <BBB> :) [20:16:21] <BBB> FWS has no zero byte [20:16:23] <siretart> how's the big bump coming along? how far do you guys estimate it from now? [20:16:35] <mru> BBB: what does put_tag() do? [20:16:39] <BBB> oh [20:16:41] <BBB> it abuses put_tag [20:16:45] <elenril> haha [20:16:46] <BBB> put_tag(3 letters) [20:16:54] <BBB> then put_byte(version) [20:17:00] <BBB> so you can make it 4 chars also [20:17:11] <elenril> siretart: finish avio rename first [20:17:25] <elenril> i guess the same should be done in lavc/lavu too [20:17:27] <mru> maybe those really ought to be put_somethingelse [20:18:50] <drv> libavformat/mmf.c: put_tag(pb, "VN:libavcodec,"); /* metadata ("ST:songtitle,VN:version,...") */ [20:19:52] <drv> and the ones in ffmetaenc [20:19:55] <BBB> libavformat/gif.c: put_tag(pb, "NETSCAPE2.0"); // bytes 4 to 14 [20:20:51] <drv> gfxenc has some too [20:20:54] <mru> so put_tag() is actually "put string" [20:21:05] <elenril> mru: put string without NULL [20:21:08] <BBB> it seems it is indeed sometimes put_string without null [20:21:12] <BBB> and sometimes put_fourcc [20:22:12] <mru> so if you want a special function to write "fourcc" tags, you'll have to provide something else for those places where an arbitrary-length string is passed [20:24:14] <drv> so really avio_put_str should perhaps be avio_put_strz and current put_tag could be avio_put_str [20:25:16] <elenril> i doesn't have to be public [20:26:04] <ods15> 16:33:52 <@mru> remember the time ods15 ate pork? [20:26:07] <ods15> 16:34:34 <@mru> wiesbaden '06 [20:26:20] <mru> he's alive!! [20:26:24] <ods15> damn, 06?? that was 5 years ago??? [20:26:29] <ods15> time flies [20:26:57] <ods15> anyway, i don't remember at all.. i wonder if that was my first time then [20:27:25] <mru> you were looking for non-pork options but finally gave in [20:27:27] <mru> as I recall [20:27:40] <ods15> i don't eat pork at all in israel, i'm rarely in such restaurants, but in u.s. i ate bacon every morning at the hotel... [20:27:58] <mru> of course you don't eat pork in israel, the stuff doesn't exist there [20:28:01] <ods15> wow, weird.. don't remember it at all [20:28:09] <ods15> it exists, but fairly rare [20:28:27] <mru> since few people would buy it [20:28:42] <bilboed> it's like negative-spain [20:28:51] <ods15> quite a few restaurants serve meat with cheese, and a small subset of those also have pork [20:28:55] <ods15> lol [20:29:30] <bilboed> (Spain pushed strongly for porc while trying to kick out the maures) [20:29:35] <ods15> in tel aviv i think kosher restaurants are more rare than non-kosher [20:30:03] <mru> kosher by which definition? [20:30:04] <ods15> ("more-rare" is a bad phrase. i mean simply, "in the minority"...) [20:30:09] <ods15> certified [20:30:32] <ods15> i think there are a whole bunch of different kind of certifications, some more strict than others [20:30:45] <mru> but most people don't really care about certification, do they? [20:30:52] <ods15> but i can simply divide them by "have any certif", vs. "none at all" [20:31:06] <ods15> oh, most that care about it at all, do [20:31:20] <ods15> the question "are you kosher" means "do you have kosher certif" [20:31:45] <ods15> it hardly means, "is your food kosher" :) cause anyone who has a clue knows that the whole certif is just a money fraud [20:31:53] <mru> yeah [20:32:20] <ods15> only the very crazy care about which certif you have [20:32:23] <Flameeyes> [just wondering out of my mind while trying not to get myself too down on the stuff I'm doing... anybody tried OpenMP lately?] [20:32:23] <mru> what I meant was, there are probably more people who don't eat pork than who care about the certificate [20:32:35] <mru> Flameeyes: for what purpose? [20:32:38] <ods15> oh, yeah, thats true [20:32:51] <Flameeyes> mru: media-related :) [20:33:04] <mru> Flameeyes: I'd say it's useless [20:33:12] <ods15> because pork is just a rarity in israel, it's still quite stigmitizedas "unclean"... perpetuating the rarity... [20:33:36] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r381efba0ec ffmpeg/libavcodec/ppc/vc1dsp_altivec.c: [20:33:36] <CIA-15> ffmpeg: ppc: fix vc1 inverse transform, unbreak build [20:33:36] <CIA-15> ffmpeg: GCC 4.3 and later are more particular about signedness matching [20:33:36] <CIA-15> ffmpeg: in vector operations. The operations under if(rangered) were [20:33:36] <CIA-15> ffmpeg: missing assignments and thus had no effect. [20:33:37] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:33:37] <mru> that's the impression I've got from meeting israelis [20:33:38] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * re0e46cae37 ffmpeg/libavcodec/ppc/vp8dsp_altivec.c: [20:33:38] <CIA-15> ffmpeg: vp8: ppc: fix invalid reads in altivec epel mc [20:33:39] <CIA-15> ffmpeg: The 4-tap filters should only access one row/column before the [20:33:39] <CIA-15> ffmpeg: reference block. [20:33:40] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [20:33:52] <Flameeyes> mru: k.. was just wondering â I started looking into that years ago for xine but then never had the time to work on it seriously [20:34:17] <mru> Flameeyes: openmp is only (possibly) useful when you have parallelism at a high level [20:34:21] <ods15> whats up with "signed-off-by"? is this a gpl thing? [20:34:57] <mru> so each thread processes its slice for a fairly long time without interaction with others [20:35:09] <mru> typical hpc stuff [20:35:15] <ods15> hey, i just noticed that the revisions CIA-15 says are git revisions... is this a CIA-15 thing, or is ffmpeg finally git? [20:35:26] <mru> ods15: it's git all the way [20:35:26] <bilboed> finally git :) [20:35:33] <mru> ods15: what rock have you been under? [20:35:33] <ods15> insanity! [20:36:22] <ods15> mru, actually, it's rather surprising that i knew at all that you guys were STILL working on the switch to git just a few months ago, i was bored and happenned to catch on that mailing list thread and read it [20:36:28] <mru> Flameeyes: the only video coding parts that a compiler has any hope in hell of parallelising are the ones best done in simd anyway [20:36:35] <ods15> but otherwise, i have no clue at all whats going on in mplayer/ffmpeg [20:36:39] <Flameeyes> mru: i see [20:37:03] <mru> Flameeyes: I'm sure the hpc compiler guys will tell you another story of course [20:37:20] <mru> one about how openmp is the salvation from all evil and will cure cancer etc [20:37:25] <ods15> a few months ago, some of my friends from uni, who are studying CS, got a homework project with ffmpeg :) [20:37:38] <ods15> i showed em my names in the credits, which was funny :) [20:37:41] <ods15> name* [20:38:43] <mru> BBB: elenril: !!!!!!!!!!!!! [20:38:52] <BBB> ? [20:38:54] <BBB> what? [20:38:55] <mru> you killed fate [20:38:58] <BBB> huh? [20:39:00] <mru> second time today [20:39:02] <BBB> I did not [20:39:12] <mru> libavformat/spdifenc.c:528: error: implicit declaration of function 'ffio_fill [20:39:25] <BBB> oh that [20:39:30] <BBB> my compiler doesn't error on that [20:39:35] <BBB> I'm not sure why [20:39:37] <BBB> let me fix that [20:39:42] * BBB goes hide in shame [20:40:43] <BBB> email sent [20:40:57] <mru> compiler too old [20:40:57] <elenril> oops [20:41:03] <mru> I've told you not to use apple crap [20:41:11] <BBB> but I love my mac [20:41:25] <mru> sorry pal, she's cheating on you [20:41:31] <BBB> :'( [20:41:42] <BBB> I'll win her back! I WILL! [20:41:49] <BBB> now go ack my patch [20:42:08] <mru> nak [20:42:15] <BBB> ? [20:42:21] * elenril o_0@the amount of put_tag() in movenc.c [20:42:28] <elenril> what's wrong with that muxer [20:42:36] <mru> it's a mov muxer [20:42:45] <BBB> elenril: good luck with that [20:43:19] <BBB> mru: what's wrong with the patch? [20:43:26] <mru> read your email [20:43:29] <BBB> oh [20:43:46] <ods15> mru, got a Q, i use git at work [20:44:01] <mru> authorised or unauthorised? [20:44:08] <ods15> is the general git philosophy, if i have local topic branches, i should NOT sporadically update? [20:44:25] <mru> you do whatever you feel like [20:44:28] <elenril> is it because movenc sucks or because mov sucks? [20:44:28] <ods15> if by "nonauthorized" you mean, we still use svn, then yes, we still use svn [20:44:32] <mru> git doesn't dictate how you work [20:44:32] <elenril> or both [20:44:52] <mru> I know mov sucks [20:44:54] <BBB> oh I guess I should keep it alphabetical? [20:45:09] <mru> BBB: why don't you go and read my reply? [20:45:10] <ods15> well, for this end i made a script "git-update" which does the equivalent of "for `git for-each-ref`; git rebase master $I" [20:45:16] <BBB> mru: I did [20:45:17] <mru> BBB: and for the record, I am not DonDiego [20:45:18] <BBB> mru: I responded [20:45:28] <BBB> mru: so I figured "maybe something else is wrong also" [20:45:36] <BBB> where is dondiego anyway [20:45:39] <BBB> he isn't reviewing patches [20:45:39] <ods15> and, well, it really doesn't work very well when starting to collaborate... [20:45:48] <mru> he tab completes, that's something [20:46:32] <BBB> there's another guy starting with don also [20:47:32] <Flameeyes> BBB: there's also another Diego :P [20:47:53] <BBB> not on irc :) [20:48:12] <BBB> (as in: nick doesn't look like diego on irc) [20:48:14] <elenril> srsly, wtf is with movenc being a pile of lasagna [20:48:33] <merbzt> elenril: what are you talking about ? [20:48:37] <merbzt> what is the problem ? [20:49:27] <elenril> merbzt: it takes up a huge part of my renaming patches [20:49:43] <elenril> which probably doesn't mean anything nice [20:50:12] <BBB> well our mov muxer is tons more complete than most others, and supports a lot more features than most others [20:50:27] <BBB> multiple video/audio codecs, with special extradata, stuff like that, rtp hinting, subtitles [20:50:35] <BBB> only matroskaenc supports as much, I think [20:50:49] <BBB> and that's a pile of ebml_puts instead of put_tags [20:51:29] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r0f86fcabdf ffmpeg/libavformat/spdifenc.c: spdifenc.c: fix compile because of missing include avio_internal.h. [20:51:41] <BBB> also, shall we deprecate MAINTAINERS? [20:52:11] <merbzt> BBB: yes, at least apply Reimars patch [20:52:34] <merbzt> I oked it [20:53:02] <Kovensky> 17:48.14 elenril: srsly, wtf is with movenc being a pile of lasagna <-- it isn't object oriented, so it's plain old spaghetti [20:53:31] <ohsix> all my objects are oriented [20:56:26] <elenril> anyway, i'd just make put_tag internal for now [20:56:37] <elenril> or do we want it public? [20:56:48] <Flameeyes> ohsix: pointing north? [20:57:01] <ohsix> just oriented [20:57:10] <BBB> elenril: no, not public [20:57:24] <BBB> elenril: internal is fine, as long as we can remove it and replace it with something better [20:57:27] <elenril> BBB: then i'll just rename it and we can fix it later [20:57:34] <BBB> that's ok [20:57:38] <ohsix> that was the joke, just because their oriented doesn't say about their grouping or where they're facing, or if they're tipped over and thats not the proper state of them ... huhu [20:59:06] <elenril> oriented == surface+normal [21:03:26] <BBB> ok, whoever is in for another flame, let's remove MAINTAINERS [21:05:33] <bilboed> +1 [21:05:38] <bilboed> there's git for that [21:06:01] <Flameeyes> BBB: I'm always in on the flame! [21:06:11] <Flameeyes> I suggest we add a .mailmap file though, in that case [21:06:25] <Flameeyes> [i.e. I'm pretty sure I currently appear with a couple different identities over the repository] [21:17:30] <elenril> 20 files changed, 196 insertions(+), 170 deletions(-) [21:17:35] <elenril> hmm, this one is pretty big too [21:19:15] <Kovensky> git doesn't say who the maintainer is does it [21:19:27] <BBB> git has a solution for world hunger [21:19:47] <elenril> BBB: patch sent [21:19:52] <BBB> noticed [21:21:36] <elenril> so shall we do url_ffoo next? [21:22:32] <BBB> yeah, let's [21:22:45] * Flameeyes just loves emacs [21:22:48] <BBB> now [21:22:49] <BBB> so [21:22:52] <BBB> for put_tag [21:22:58] <BBB> ffio_wtag I mean [21:22:59] <BBB> :-p [21:23:21] <BBB> do we want to put any effort in merging this with avio_put_str or avio_wl32()? [21:23:42] <elenril> you mean weffort [21:24:22] <elenril> when it's used for fourccs it should be eliminated [21:24:28] <elenril> in other places, :effort: [21:24:35] * Kovensky flames Flameeyes with TECO [21:24:47] * Kovensky wonders what happens if one writes "Flameeyes" on TECO [21:24:57] <Flameeyes> Kovensky: probably something very very bad [21:26:24] <Flameeyes> it could either go up in smoke [21:26:31] <Flameeyes> or decide to write a ruby-based clone of itself [21:27:40] <wbs> anyone care to comment on the ff_neterrno() patch I sent a few days ago? [21:28:25] <elenril> url_fopen/fclose/fseek/fskip/ftell/fsize look ObviouslyPublic [21:28:57] <Flameeyes> wbs: poke lu_zero :P [21:29:08] * Kovensky wonders if there'll ever be a way to make ffmpeg open a file descriptor, or a way to feed it a FILE* [21:29:25] <Kovensky> s/ffmpeg/libavformat/ [21:37:28] <elenril> Kovensky: send patches [21:37:43] <elenril> (see them being rejected) [21:38:31] <BBB> url_fdopen() [21:38:35] <BBB> with fileno(FILE*) [21:38:46] <BBB> anything else? [21:38:54] <wbs> BBB: url_fdopen takes an URLContext [21:38:59] <BBB> oh [21:39:00] <BBB> that sucks [21:39:01] <BBB> ohwell [21:40:36] <Kovensky> that's terribly named then =p [21:41:11] <wbs> no, it's perfectly right named, just like fdopen() wraps a file descriptor into a high-level buffered FILE*, url_fopen takes a low-level, unbuffered URLContexts and wraps it into a buffered AVIOContext [21:41:23] <wbs> Kovensky: btw, pipe:<number> lets you use an existing fd [21:41:53] <Kovensky> does fileno() work even on windows? [21:42:17] <Dark_Shikari> "man fileno" returns a man page [21:42:19] <Dark_Shikari> so I'd assume yes. [21:42:49] <Kovensky> Dark_Shikari: cygwin != windows [21:44:23] <Dark_Shikari> what, are you going to build ffmpeg in visual studio now? [21:44:43] <Flameeyes> Dark_Shikari: I thought people did already? [21:44:53] <Flameeyes> [or at least with mingw [21:49:19] <Kovensky> Dark_Shikari: mingw [21:49:45] <Dark_Shikari> mingw has wrappers for posix functions [21:49:47] <elenril> ok, enough api breakage for today [21:49:49] * elenril sleeps [21:52:19] <Kovensky> Dark_Shikari: not enough wrappers [21:56:58] <mru> ENOWRAPPER [22:36:05] <Compn> arg bbb left [22:36:54] <saintdev> Compn: wow, that was a good summoning [23:13:52] <DonDiego> gnite

1 0

IRC log for 2011-02-20
by irc＠mansr.com 21 Feb '11

21 Feb '11

[00:01:53] <kierank> mmu_man: it'll probably work but the file won't be spec compliant [00:04:58] <mmu_man> well the idea is to just join back parts and remove advertisements, and to remux to a .mp4 anyway [00:05:20] <mmu_man> but I'll need to remux to a PS to seek correctly anyway to locate where to cut [00:05:44] <mmu_man> VLC nor ffplay seem to find the time when seeking [00:06:24] <kierank> there are tons of ts cutting apps [00:06:59] <mmu_man> ffmpeg being one of them, just can't locate where to cut easily [00:10:26] <mmu_man> SGU in HD with en & fr audio on NRJ12... [00:11:00] <kierank> french channel with English audio. wow [00:13:14] <mmu_man> yeah, quite rare [00:13:34] <mmu_man> France4 used to broadcast DrWho in english during the night [00:13:38] <mmu_man> but not anymore :( [00:13:53] <mmu_man> then they wonder why they suck so much at english [00:14:10] <kierank> someone has to defend the liberte, equalite and fraternite [00:14:21] <mmu_man> arte shows antique eps of The Avengers though [00:14:29] <mmu_man> oddly they have german dubbing but no french [00:14:46] <kierank> arte's good [00:14:54] <kierank> tons of interesting stuff [00:15:00] <mmu_man> well, sadly those are getting weaker at least on the net due to all those HADOPI and LOPPSI crap [00:15:16] <mmu_man> yeah they just show more and more pr0n :D [00:15:29] <mmu_man> supposedly artistic :D [00:19:32] <BBB> kshishkov: I've got many more questions coming [00:22:47] <mmu_man> #define FFMPEG_VERSION "git-svn-rgit: 'svn' is not a git-command... [00:22:50] <mmu_man> f* [00:24:45] <mmu_man> I guess git is too old and I'm stuck as I can't update it [00:26:52] <mmu_man> damn can't install git-svn on this box, too old [00:32:43] <mmu_man> http://revolf.free.fr/beos/patches/ffmpeg-version-old-git-no-gitsvn.diff [00:32:58] <mmu_man> seems old git with no git-svn installed spit stuff to stdout... [00:53:51] <mmu_man> [mp4 @ 0x101022c00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 73000 >= 73000 [00:53:55] <mmu_man> WTF [00:54:53] <Flameeyes> WTF has Oki to do with H.264?! [00:55:52] <kierank> ? [00:56:05] <Flameeyes> kierank: RFC3016 [00:56:11] <Flameeyes> [RTP/H.264 payload] [00:56:25] <Flameeyes> all japanese authors.. one coming from Oki.. I thought they did printers.. [00:56:52] <kierank> 3016 is mpeg-4 visual [00:57:21] <ohsix> oki does a _ton_ of stuff [00:57:43] <Flameeyes> kierank: okay I'm definitely on acid, let me check I didn't fill it in the wrong table now =_= thanks! [01:29:32] <mru> mmu_man: what were you trying to do? [01:37:51] <mmu_man> mru: cut something out of a dump from my DSL box [01:38:19] <mmu_man> which streams stuff on rtsp which I saved as a .mp4 from vlc [01:38:48] <mmu_man> seems VLC managed to cut it by itself once I realized it wanted numbers of seconds as units [01:39:13] <mmu_man> maybe it was some dupped frame [07:03:48] <elenril> BBB: are you really sure ByteIOContext should be public? [07:04:09] <elenril> i don't see much people accessing its contents [07:04:42] <elenril> michaelni: ^ [07:19:22] <uau> elenril: demux_lavf sets read_seek in ByteIOContext directly (it's not at argument to the init functions) [07:19:45] <elenril> ok then [08:08:59] <wbs> elenril: accessing ByteIOContext is critical for getting custom IO for muxers (e.g. when outputting straight into memory, instead of to a file) [08:45:36] <CIA-15> ffmpeg: Reinhard Tartler <Reinhard.Tartler(a)informatik.uni-erlangen.de> release/0.5 * r2adad90ae7 ffmpeg/Changelog: Amend Changelog for 0.5.4 [08:45:47] <CIA-15> ffmpeg: Reinhard Tartler <Reinhard.Tartler(a)informatik.uni-erlangen.de> release/0.5 * r31c8dcedb2 ffmpeg/RELEASE: release notes for 0.5.4 [08:50:18] <siretart> fuck [08:50:38] <siretart> git picked up my 'university' email adress [08:51:24] <spaam> you forgot to change it :) [08:51:38] <siretart> no idea how this happened [08:51:59] <siretart> and I suppose that's really not worth rewriting the branch [09:07:52] <mmu_man> plop [09:08:01] <mmu_man> hmm damn again an error reading a .ts [09:22:54] <siretart> what would be a good benchmark for daniel kangs avx patches? [09:24:08] <kurosu> he worked on the same thing in x264 so maybe h264 decoding ? [09:24:38] <Dark_Shikari> read the patches and see what they change? [09:28:03] <siretart> so this sample should do, I think, no? http://samples.mplayerhq.hu/V-codecs/h264/HD-h264.ts [09:31:29] <spaam> try? [09:31:51] <spaam> or you can try Big buck bunny [09:37:22] <siretart> preliminary results on my sandy bridge: http://pbot.rmdir.de/ca03aa087199e1f5ebed93407affa75d [09:37:31] <siretart> downloading big buck bunny now [09:43:24] <Dark_Shikari> his patch doesn't do any optimizations [09:43:27] <Dark_Shikari> ok, it does like two lines [09:43:28] <Dark_Shikari> nothing of note [09:43:37] <Dark_Shikari> the main important part (deblock) isn't ported yet [09:43:40] <Dark_Shikari> his patch is mostly infrastructure [09:43:42] <Dark_Shikari> not optimizations yet [09:43:45] <Dark_Shikari> same as his first patch in x264 [09:45:01] <siretart> sure, still I can confirm that they work :-) [09:45:06] <Dark_Shikari> of course~ [09:47:54] <siretart> Subject: [PATCH 3/3] Implement pred8x8l_down_right_avx for h264. [09:48:12] <Dark_Shikari> Yes, that's a single rarely-used function as a starting point [09:48:14] <siretart> that third patch seems to already optimize a few percent [09:50:57] <siretart> hm, ok hardly [11:36:23] <ubitux> mru: it looks like the 185 also has the issue [11:40:15] <lu_zero> good morning [11:40:19] <lu_zero> wbs: poing [11:58:28] <BBB> siretart: that's what I wanted to know - does it work [11:58:51] <BBB> siretart: and if that particular function is a little faster that'd be nice [12:06:21] <mru> shall go ahead and push the configure and flags patch? [12:08:48] <lu_zero> astrange: you around? [12:10:27] <lu_zero> mru: dropping all the timestamp heuristics fixes my mpegts sample as well [12:10:39] <mru> I figured it might [12:12:23] <lu_zero> and result is a quite improvement on aviad mpegts streams on ffplay and a strange behaviour on ffmpeg [12:12:46] <lu_zero> but I guess there are other issues to be fixed... [12:33:03] <BBB> mru: yes, the patch looks fine to me [12:36:53] <BBB> mru: don't forget to merge the two #if's [12:37:15] <mru> that's not in my patch [12:37:39] <mru> I was talking about the first one only [12:42:52] <BBB> elenril: <bikeshed> I was hoping to prevent ff_av*() function names [12:43:11] <BBB> elenril: e.g. ff_init_io_context() [12:45:09] <BBB> elenril: don't send a new patch, I can sed that in the patch itself without problem [12:45:16] <BBB> let's just prevent further flames and trolls :) [12:45:29] <BBB> michaelni, mru: ff_init_io_context() fine as function name? [12:45:35] <BBB> anyone else have opinions? [12:45:42] <mru> what's in a name? [12:45:51] <Dark_Shikari> What is a man? [12:46:05] <mru> Dark_Shikari: someone old enough to drink beer [12:46:14] <Dark_Shikari> A miserable little pile of secrets! [12:46:40] <BBB> oh boy dark_shikari's awake, and it smells like he had beer indeed [12:46:49] <Dark_Shikari> Nope~ [12:47:11] <Dark_Shikari> That smell on my breath is tea, not beer. [12:50:00] <lu_zero> BBB: right now we have this av+ff namespace but we could extend it to pick other names IMHO [12:50:50] <mru> we have av_ and avfoo_ for public things [12:51:05] <lu_zero> yup [12:51:30] <BBB> I'd like to prevent having ff_av_ or ff_avfoo_ for private things [12:51:34] <BBB> it's a little double [12:51:38] <lu_zero> indeed [12:51:38] <BBB> long typing [12:51:42] <mru> yeah [12:51:51] <BBB> hence my request for ff_init_io_context [12:52:00] <lu_zero> it's fine IMHO [12:52:00] <BBB> the public equivalent allocating the context is called av_alloc_put_byte() [12:52:07] <BBB> and should be renamed to av_alloc_io_context() [12:52:15] <mru> not avio_? [12:52:34] <BBB> maybe yes [12:52:36] <lu_zero> if the namespace picked is avio_ makes sense [12:52:39] <mru> we could use ffio_ for corresponding internals [12:52:52] <BBB> ff_io or ffio? :-p [12:53:02] <BBB> just make sure to hide all ff symbols then, not just ff_ [12:53:03] <mru> what's in an underscore? [12:53:06] <BBB> or ff_ + ffio_ [12:53:38] <BBB> so ffio_init_context() and avio_alloc_context()? [12:53:46] <BBB> elenril: ^^ [12:54:39] <Kovensky> 09:46.40 BBB: oh boy dark_shikari's awake, and it smells like he had beer indeed <-- what's so good about beer anyway, it's just a bitter drink that makes you dumb for a while after drinking it :S [12:55:01] <wooster> uh [12:55:04] <BBB> Kovensky: beer's like wine, you need to know it to appreciate it [12:55:07] <BBB> some beers are fantastic [12:55:12] <BBB> some are bitter [12:55:17] <BBB> just like people [12:55:19] <BBB> some are fantastic [12:55:21] <BBB> some are bitter [12:55:24] <mru> ah, ringwood's best bitter... [12:55:40] * Kovensky doesn't like anything bitter [12:55:48] <mru> it's a nice local brew [12:58:35] <michaelni> BBB, maybe we should throw a b in the ffio_init stuff somewhere to make it clear its about ByteIO and not url stuff [12:59:06] <mru> let the bikeshedding begin [12:59:12] <BBB> I started it this time [12:59:18] <mru> ffio is fine [12:59:25] <mru> the url ones should have url in the name [12:59:32] <BBB> michaelni: we'll call url ff_url or ffurl_*() [12:59:44] <michaelni> id prefer something shorter [12:59:47] <lu_zero> hopefuly we won't have different io stuff [12:59:54] <mru> shorter than 3 chars? [12:59:57] <michaelni> yes [13:00:02] <michaelni> like 1 char [13:00:04] <mru> you're being silly [13:00:10] <BBB> ffx? [13:00:11] <michaelni> thanks [13:00:13] <mru> and inconsistent [13:00:20] <michaelni> ffu [13:00:20] <lu_zero> ffu is too short IMHO [13:00:21] <mru> you wanted to _add_ something to io [13:00:27] <mru> and now url is too long [13:00:32] <mru> you can't have it both ways [13:00:41] <mru> ffio+ffurl it is [13:00:41] <michaelni> 3+0 is worse than 1+1 [13:00:42] <mru> done [13:00:43] <BBB> michaelni: let's leave url for a little later [13:00:56] <BBB> ffu and ffio don't conflict [13:00:59] <BBB> ffio ok then? [13:01:11] * michaelni still would prefer ffbio [13:01:20] <mru> bio makes me think of block io [13:01:25] <BBB> bio = biology [13:01:29] <BBB> where I got my PhD in [13:01:29] <michaelni> ffbyio [13:01:30] <mru> or that [13:01:33] <andoma> same here (block io) that is [13:01:34] <mru> byo [13:01:46] <michaelni> ok too [13:01:52] <BBB> byo has no input [13:01:59] <BBB> man we are trolls here [13:02:00] <michaelni> it has its a typo [13:02:01] <mru> ffio is fine [13:02:03] <mru> just do it [13:02:07] <BBB> ffio is fine I think [13:02:29] <lu_zero> byouki =P [13:02:31] <wooster> gnu_ffio_ffurl_* [13:02:51] <lu_zero> being serious [13:03:20] <lu_zero> namespaces could be ffurl and ffbio if we want to keep them consistent on 3 letters [13:03:21] <BBB> we can rename all get/put byte functions into ffio_[wr]{byte,[lb]e{16,24,32}}()? [13:03:41] <mru> why should those be private? [13:03:47] <michaelni> lu_zero, looks nice [13:03:51] <lu_zero> if we keep the namespace to "easy to spot" [13:04:02] <lu_zero> then ffu is harder to spot than ffio [13:04:04] <BBB> mru: I'm not sure if they should [13:04:13] <mru> they seem quite useful [13:04:17] <michaelni> yes [13:04:17] <lu_zero> they are [13:04:24] <lu_zero> and apparently already used around [13:04:36] <michaelni> iam not against making them public [13:04:36] <mru> then make them public [13:04:45] <michaelni> iam against rushing it without tjought [13:04:55] <BBB> btw if we use ffbio, it should also be avbio [13:05:05] <michaelni> yes [13:05:13] <BBB> I'm gonna make this my pet project, "Audio/Video combined with Biology" [13:05:21] <michaelni> :) [13:05:22] <BBB> "see, mom, my PhD was not useless" [13:05:23] <BBB> oops [13:05:44] <lu_zero> BBB: and... damn could _really_ make sense... [13:06:01] <Kovensky> 10:05.13 BBB: I'm gonna make this my pet project, "Audio/Video combined with Biology" <-- like every other documentary on Animal Channel? [13:06:01] <mru> the get_foo() functions take a single argument and return a number, I don't see how they could be improved [13:06:21] <BBB> we can make 'em public now [13:06:37] <BBB> get_byte/[bl]e{16,24,32} are perfect [13:06:41] <BBB> nothing to be improved about [13:06:51] <BBB> get_buffer is fine also [13:07:04] <BBB> the rest we can leave private if we feel uncertain [13:07:07] <michaelni> mru, static inline (not suggesting it just saying it would improve something that is speed) [13:07:16] <mru> that's unrelated [13:07:25] <mru> and you are deliberately stalling [13:07:27] <mru> stop it [13:07:37] <mru> we will ignore you [13:07:42] <michaelni> ohh my [13:07:54] <mru> if you keep being obstructive [13:08:09] <michaelni> iam neither obstructive nor deliberate stalling [13:08:15] <mru> sure looks like it from here [13:08:34] <michaelni> perception ... [13:08:45] <michaelni> subjective perception [13:08:48] <lu_zero> just soemthing [13:08:50] <lu_zero> something [13:09:02] <BBB> I'll fix up elenril's patches and apply [13:09:05] <BBB> let's move on from here [13:09:11] <lu_zero> the bio namespace is used at least by ssl ^^; [13:09:11] <BBB> the goal is to hide the symbols [13:09:14] <lu_zero> (and linux) [13:09:21] <BBB> lu_zero: ffbio, not bio [13:09:25] <lu_zero> BBB: sure [13:09:30] <mru> still confusing [13:09:38] <BBB> or avbio [13:09:47] <mru> the acronym is established for block io [13:09:55] <michaelni> ffio / avio is confusing to me [13:10:02] <mru> only to you [13:10:05] <mru> you are minority [13:10:08] <mru> resistance is futile [13:10:27] <michaelni> iam the one maintaining that code ... [13:10:59] <elenril> yay, bikesheds [13:11:06] <michaelni> you dont want ti confuse the one maintaining the code normally [13:11:11] * mru throws some paint at elenril [13:11:24] * elenril paints avio black with purple dots [13:11:30] <lu_zero> nooo [13:11:31] <lu_zero> RED [13:11:44] <elenril> anyway [13:11:46] <mru> alright, you can have red for input if we make output green [13:11:49] <lu_zero> because "red un's 'r fasta!" [13:11:57] <mru> elenril is green here [13:12:02] <lu_zero> anyway [13:12:03] <elenril> i don't really like the b/byte part [13:12:08] <mru> elenril: nobody does [13:12:10] <elenril> it makes things unnecesarily longer [13:12:27] <elenril> and AVIOContext is much prettier than AVByteIOContext [13:12:32] <mru> +1 [13:12:41] <michaelni> AVBIOContext :) [13:12:50] <mru> stop it [13:12:58] <elenril> and there will be no confusion if we rename all the rest to av_url or avurl [13:13:03] <michaelni> kick me when you are out of arguments [13:13:18] <lu_zero> michaelni: arguments so far [13:13:36] <michaelni> lu_zero, you dont want ti confuse the one maintaining the code normally [13:13:52] <lu_zero> - bio stands for at least 2 different contexts outside [13:14:00] <mru> seems to me elenril is the one maintaining it right now [13:14:02] <lu_zero> - we don't have different ios [13:14:13] <michaelni> mru, elenril is doing cleanup aka cosmetics [13:14:32] <michaelni> lu_zero, we have 2 IO layers [13:14:38] <mru> michael doing nothing: maintenance [13:14:40] <lu_zero> which ones? [13:14:42] <michaelni> the url and byte io stuff [13:14:43] <mru> others doing stuff: cosmetics [13:14:44] <lu_zero> mru: quiet! [13:15:32] <lu_zero> michaelni: so if you find something with url is url, if you find something with io is io [13:15:48] <lu_zero> as I wrote before [13:16:21] <lu_zero> 2 letter are enough to match bit&byte (memory) io [13:16:22] <michaelni> and wheres the logic in this? url being low level, io being high level with buffer ... [13:16:42] <lu_zero> 3 are the least sufficient to match the protocols [13:16:50] <lu_zero> (that we identify by urls) [13:18:36] <lu_zero> the whole "I am special" should be avoided. [13:18:55] <lu_zero> since that's what you are saying [13:19:28] <lu_zero> and it is quite childish, or, as mru said at the start, silly. [13:20:15] <BBB> I personally prefer AVIOContext and avio_*()/ffio_*() also [13:20:17] <siretart> BBB: yes, it does work, and the first optimization is hardly measurable, cf. http://pbot.rmdir.de/ca03aa087199e1f5ebed93407affa75d [13:20:19] <BBB> shall we vote? [13:20:23] <michaelni> lu_zero, author of code and the person who maintains it are 2 special people [13:20:29] <BBB> siretart: ok, mru feel free to apply avx patch then [13:20:55] <michaelni> BBB: on the ML yes, here is unfair [13:21:20] <BBB> takes too long [13:21:24] <BBB> elenril: your patch, you choose [13:21:29] <mru> just f*cking do it [13:21:30] <BBB> easiest solution [13:21:30] <lu_zero> michaelni: drop it. [13:21:49] <BBB> I think everyone prefers AVIOContext and av/ffio_*() [13:22:08] <mru> yes [13:22:15] <elenril> BBB: i already said what i prefer [13:22:35] <michaelni> politics ... [13:23:02] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r87f1355f9b ffmpeg/ (4 files in 3 dirs): [13:23:02] <CIA-15> ffmpeg: x86: check for AVX support [13:23:02] <CIA-15> ffmpeg: This adds configure and runtime checks for AVX support on x86 CPUs. [13:23:02] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [13:23:09] <michaelni> and manipulation by selective voting [13:23:21] <michaelni> now kick me [13:23:24] <lu_zero> michaelni: are you describing your last 3 tries with [vote]? [13:23:43] <lu_zero> the reversal strategy is well known... [13:24:15] <lu_zero> the condorcet website is what I proposed if we want to have a proper vote [13:24:33] <mru> we don't want a vote [13:24:35] <michaelni> lu_zero, iam still waiting for your better vote with 2+weeks discussion and people proposing option and then condorcet [13:24:36] <mru> voting is evil [13:25:04] <lu_zero> michaelni: said what to do, up to the others say yai or nay. [13:25:33] <michaelni> lu_zero, i cant start it or people will say i manipulated it by magic again [13:26:02] <lu_zero> I can't start it otherwise somebody we know will say I manipulated it [13:26:25] <elenril> BBB: will you sed it? [13:26:31] <BBB> elenril: sure [13:26:34] <elenril> great [13:26:35] <mru> what sedding is required? [13:26:49] <elenril> the latest patch has AVByteIOContext [13:26:58] <elenril> but we just agreed on AVIOContext [13:27:00] <mru> yeah [13:27:15] <mru> BBB: just be sure to test before push [13:29:30] <BBB> I will test-compile and make-fate [13:29:48] <elenril> and don't forget to change the commit message [13:29:49] * BBB does his magic s/AVByteIOContext/AVIOContext/g [13:29:57] <BBB> elenril: doesn't it sed that automagically also? [13:30:25] <elenril> if you're sedding the patch file, then yes [13:30:26] <mru> I don't think anyone implemented git-sed yet [13:30:41] <mru> ah, sedding the patch [13:30:45] <BBB> elenril: I'm sedding your email before git am -s [13:35:58] <BBB> hm, I had to s/AVByteIOContext/AVIOContext/g on the second patch also, or it doesn't apply, of course [13:36:00] * BBB runs make fate [13:36:09] <BBB> so AVIOContext and ffio_init_context() [13:36:22] <BBB> avio_internal.h is fine with me as filename btw [13:36:33] <BBB> elenril: both are queued [13:37:43] <BBB> make -j4 fate is awesome [13:37:59] <mru> make -j8 fate is awesomer [13:38:11] <BBB> I don't have 8 cores :( [13:38:15] <BBB> I think [13:38:23] <BBB> how many cores does an i7 have? [13:38:27] <mru> 4+ht [13:38:39] <mru> -j8 runs a bit faster than -j4 [13:38:54] <mru> 20-30% or so [13:40:20] <BBB> hm [13:40:21] <BBB> ok [13:40:22] <BBB> will try [13:40:31] <BBB> have to write doc/APIChanges and will commit [13:46:17] <elenril> ok, what next [13:46:36] <BBB> buy me a 16-core machine [13:46:48] <elenril> av_alloc_put_byte -> avio_alloc_context [13:46:49] <BBB> av_alloc_put_byte() should of course be av_alloc_io_context() [13:46:55] <BBB> avio_alloc_context indeed [13:46:56] <BBB> sorry [13:47:00] <BBB> so do that next [13:47:16] <elenril> can you push now? [13:47:28] <elenril> or i'll have to repeat your sedding [13:48:11] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r70aa916e46 ffmpeg/libavcodec/vc1dec.c: [13:48:11] <CIA-15> ffmpeg: VC1: don't use vc1_put_block() in vc1_decode_i_blocks_adv(). [13:48:11] <CIA-15> ffmpeg: Advanced profile never uses "range reduction", so vc1_put_block() quite [13:48:11] <CIA-15> ffmpeg: literally just calls put_pixels_clamped() from vc1_decode_i_blocks_adv(). [13:48:11] <CIA-15> ffmpeg: By inlining the function, we can prevent calling IDCT8x8 if [13:48:11] <CIA-15> ffmpeg: CODEC_FLAG_GRAY is set, and we don't have to scale the coeffs in the [13:48:12] <CIA-15> ffmpeg: [0,256] range, but can instead use put_signed_pixels_clamped(). [13:48:12] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rae628ec1fd ffmpeg/ (140 files in 2 dirs): [13:48:13] <CIA-15> ffmpeg: avio: rename ByteIOContext to AVIOContext. [13:48:13] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:48:14] <BBB> done [13:48:20] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rd2bbf82e65 ffmpeg/ (doc/APIchanges libavformat/version.h): [13:48:20] <CIA-15> ffmpeg: Update version and APIchanges. [13:48:20] <CIA-15> ffmpeg: Update libavformat/version.h and doc/APIChanges after renaming [13:48:20] <CIA-15> ffmpeg: init_put_byte() and ByteIOContext to ffio_init_context() (private) [13:48:21] <CIA-15> ffmpeg: and AVIOContext, (public), and deprecating the originals. [13:48:23] <elenril> awesome [13:48:23] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * re731b8d872 ffmpeg/libavformat/ (14 files): [13:48:23] <CIA-15> ffmpeg: avio: move init_put_byte() to a new private header and rename it [13:48:23] <CIA-15> ffmpeg: init_put_byte should never be used outside of lavf, since [13:48:23] <CIA-15> ffmpeg: sizeof(AVIOContext) isn't part of public ABI. [13:48:23] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [13:48:33] <mru> \o/ [13:48:40] <BBB> elenril: sorry this takes so long, bikeshedding is a very delicate business [13:48:52] * BBB goes have breakfast [13:48:58] <BBB> I'll apply your avio patch as soon as I finish [13:59:51] <elenril> bumping minor for each small rename is annoying [13:59:58] <elenril> maybe we should setup a branch for this [14:00:07] <elenril> and then merge it after everything is renamed [14:00:43] <mru> I think it's ok to bump minor once for a batch of related commits [14:01:01] <elenril> yeah, but bumping for each two or three renames is too much [14:07:58] <BBB> I can not bump the version for a while [14:08:28] <elenril> so what about get/put_ [14:08:36] <elenril> we make them public, right [14:08:39] <BBB> yes [14:08:45] <BBB> avio_get_ is too long [14:08:59] <BBB> I was thinking avio_[rw]{byte,[lb]e{16,24,32}} [14:09:45] <BBB> similar to AV_W[NLB]{16,24,32}{,A} [14:09:50] <BBB> I meant W or R [14:10:08] <BBB> others have opinions? [14:10:25] <BBB> the rename should still be a couple of seds over the whole source tree at best [14:11:40] <BBB> as for how to do this without version bumps, I can setup a branch for your accepted commits, you can do your own branch, but I'd like to not do that since I'm affraid it'll get lost or forgotten or ignored [14:13:01] <BBB> this way may be easiesty [14:13:06] <BBB> we push 'em one by one [14:13:15] <BBB> you keep a log of all we've done as a APIchanges patch [14:13:20] <BBB> and we'll commit that when we're satisfied [14:14:37] <elenril> i don't have a preference here [14:17:04] <Kovensky> BBB: just commit (and push) everything to a branch (say "api_renames"), and when done do a git merge with "--no-ff --no-commit", git add the version bumps and commit the merge commit [14:17:25] <Kovensky> that might not be the cleanest thing though; you may want to do the version bumps as the last commmit in the api_renames branch and then just `git merge --no-ff` [14:17:45] <Kovensky> (the --no-ff keeps a commit saying it was a merge from branch X, even if it applies cleanly) [14:18:27] <mru> I'd rebase the branch onto master and fast-forward master when ready [14:19:56] <elenril> BBB: i dunno, e.g. avio_rbuffer doesn't look very readable to me [14:22:15] <mru> there, another armcc bug filed [14:22:34] <mru> they've confirmed the previous one [14:24:28] <mru> oh crap [14:27:13] <Kovensky> http://tvtropes.org/pmwiki/pmwiki.php/Main/OhCrap [14:31:58] * elenril going to prague, see you in 3 hours [14:33:56] <BBB> elenril: let's brainstorm [14:33:59] <lu_zero> take care [14:34:05] <BBB> avio_rb32/rl32 is ok? [14:34:11] <BBB> oh he's gone [14:34:16] <mru> seems reasonable to me [14:36:40] <BBB> then avio_rbyte/wbyte is also ok? [14:36:57] <mru> r8/w8? [14:37:05] <BBB> yeah, better [14:37:08] * mru compares to intreadwrite [14:37:20] <BBB> avio_rbuf/wbuf? [14:37:34] <mru> how about read/write? [14:37:39] <BBB> oh, well duh [14:37:41] <BBB> :) [14:37:46] <BBB> elenril: ^^ there you go [14:39:33] <mru> there, fixed [14:41:55] * BBB thinks vc1 is a piece of crap [14:43:10] <mru> the world agrees [15:35:27] <mru> I'm getting frighteningly good at this... picked the one line triggering an armcc bug in a 1k-line file just be looking at the C code [15:35:35] <mru> *by [15:36:18] <DonDiego> time to get paid for armcc testing? :) [15:43:17] <siretart> DonDiego: can you please have a look at the 0.5 branch? I've already cut tarballs in my home (look in public_html), but if you find issues/corrections, I'm happy to roll them again [15:45:43] * Flameeyes needs to fix a problem with .pc files [15:46:02] <mru> delete them [15:46:05] <mru> should fix it [15:46:08] <Flameeyes> mru: I wish [15:46:15] <Flameeyes> would get worse [15:46:36] <mru> pkgconfig is a bad solution for the wrong problem [15:47:10] <Flameeyes> "ld-deps" file in .a files would probably be better, agreed [15:47:45] <mru> with gnu ld it can be done by replacing the .a with a linker script referencing the real .a and all deps [15:48:16] <siretart> Flameeyes: I wonder if someone actually uses the -uninstalled variants of the .pc files [15:48:24] <Flameeyes> true, problem is most people have no clue what a linking script is [15:48:26] <Flameeyes> siretart: I do [15:48:35] <lu_zero> mru: next large meeting we should try to get more people on fixing it for good [15:48:42] <mru> impossible [15:48:49] <lu_zero> why? [15:48:55] <mru> the hordes don't even see there's a problem [15:49:40] <lu_zero> the .pc is the best incomplete solution if you come to think about it [15:49:58] <mru> but it doesn't work [15:50:08] <siretart> it works for surprisingly many cases [15:50:13] <mru> and it's open to abuse [15:50:17] <lu_zero> it does up to a point (now that they fixed some parts of it) [15:50:25] <mru> people put all sorts of crazy flags in there [15:50:25] <Flameeyes> okay.. now I'm baffled [15:50:30] <Flameeyes> the .pc generation is _correct_ in ffmpeg [15:50:54] <mru> it's not unusual to find very gnu-specific flags in .pc files [15:51:05] <mru> like -std=gnu99 [15:51:12] <mru> which can seriously fuck up a build [15:51:29] <lu_zero> mru: I bet we'd get something even worse in the linker scripts [15:51:44] <mru> provide some tools to generate them [15:51:50] <siretart> mru: my favorite flag found in a .pc file was '-fvisibility=hidden' [15:51:59] <mru> another good example [15:52:41] <siretart> still doesn't mean we should shoot all pkg-config users [15:52:51] <mru> but we can try [15:53:09] <lu_zero> please don't kill me [15:53:18] <mru> /kill lu_zero [15:53:25] <j-b> 'moroning [15:53:32] <lu_zero> hi j-b [15:53:49] <lu_zero> ca va? [15:54:00] <j-b> 've been better [15:54:14] <mru> better moron? [15:57:46] <DonDiego> Flameeyes: fwiw, i did spend some time on reviewing the patches for .pc file generation, but every other month somebody new seemed to pop up complaining about new issues... [15:58:07] <mru> most of them imagined [15:59:03] <Flameeyes> DonDiego: I think my first patches to ffmpeg have been about getting those right [15:59:27] <mru> yours were probably good [15:59:42] <Flameeyes> I was assuming a small mistake in it for a customer's build failure, but by now I suppose the answer is a conflict with system-installed ffmpeg on ubuntu.. need to review what my colleague wrote for them [15:59:44] * Flameeyes eyes lu_zero [16:05:05] * lu_zero is innocent [16:05:20] <Flameeyes> you're most definitely not. [16:08:25] <BBB> bilboed: ping [16:08:29] <bilboed> pong [16:08:44] <BBB> so, gst-ffmpeg uses this custom URLProtocol way to interact with lavformat right? [16:08:51] <bilboed> yes [16:09:00] <BBB> bilboed: can I urge you to rewrite that by using ByteIOContext, which is what mplayer, xine and VLC do? [16:09:11] <BBB> bilboed: I'm about to deprecate URLProtocol from our public API [16:09:27] * mru deprecates gst [16:09:34] <BBB> I'm trying to be nice :-p [16:09:46] <bilboed> I need to spend some quality time updating gst-ffmpeg to use new APIs [16:09:54] <mru> BBB: didn't you just rename that to AVIOContext? [16:09:59] <BBB> ohright [16:10:01] <bilboed> BBB, I'm fine if you deprecate it now [16:10:03] * BBB smacks himself [16:10:10] <BBB> bilboed: AVIOContext, not ByteIOContext [16:10:20] <BBB> bilboed: also, if you have more API suggestions, now's a fantastic time [16:10:31] <bilboed> as long as it clearly says "deprecated, use this instead" [16:10:36] <BBB> doc/APIchanges [16:10:41] <BBB> says all of that [16:10:42] <bilboed> right [16:10:54] * bilboed scratches head [16:12:04] <bilboed> apart from having more introspectable info/options/.. from each component, not really. [16:12:27] <mru> we're getting there, but it's taking time [16:12:27] <bilboed> ex : being able to know an encoder can only take some width/height/framerate/colorspace in input for ex [16:12:39] <uau> Flameeyes: there are some bugs in current ffmpeg .pc files for static linking at least [16:12:43] <mru> pixel formats are already covered [16:12:44] <bilboed> in a programmatic way, and not via debug messages [16:12:50] <uau> missing libavutil and libm dependencies [16:13:21] <BBB> bilboed: got it, we're gonna move a lot of stuff like AVCodecContext stuff into private codec-specific AVOptions [16:13:29] <BBB> bilboed: this isn't easy, so it won't be done tomorrow, but it'll happen [16:13:32] <bilboed> BBB, yah, so no, apart from that not much [16:13:36] <BBB> ok, thanks [16:13:39] <bilboed> de nada [16:21:27] <BBB> kshishkov: with the current patch, is a VC1DSPContext.vc1_inv_trans_8x8_put{,_signed}[2] ok? [0] is regular range, [1] is rangeredfrm, which is <<=1 for signed or -64<<=1 for unsigned [16:21:38] <BBB> kshishkov: once that's done, I'll go back to simd [16:24:20] <uau> mru: if you complain about a couple of projects using gcc-specific flags in their .pc files, then how would making the whole _infrastructure_ fundamentally depend on a particular linker be an improvement over that? [16:25:39] <mru> if someone made a sane proposal for a libdeps file in .a archives, I'm sure vendors could be persuaded to adopt it [16:26:22] <mru> gnu binutils would be a reasonable place to start [16:27:51] <mru> to answer your question, the "design" of pkgconfig already assumes everybody is using gnu tools [16:28:00] <uau> and the advantage over the already widely working pkg-config would be what? that after a transition period of years we'd have a system which no longer supports arbitrary library-specific C flags (which also makes many things more cumbersome)? [16:28:16] <mru> pkgconfig doesn't work [16:28:19] <mru> that is the problem [16:28:38] <uau> many people are using it and it works for them... [16:28:48] <mru> and if fails for many others [16:29:21] <uau> not using it would fail for a lot more [16:29:38] <mru> solving the real problem would work for everybody [16:30:06] <lu_zero> sure [16:30:10] <uau> there's no single "real problem" [16:30:18] <mru> yes, deps for static libs [16:30:19] <lu_zero> in the mean time pkg-config works fine for most usages [16:30:23] <uau> and nothing depending on linker changes could work for everybody [16:31:14] <lu_zero> uau: ABI changes happen ^^; [16:31:14] <mru> try building anything at all on a modern system with an old linker [16:31:15] <mru> it won't work [16:31:29] <mru> so linker changes happen and are relied on [16:32:39] <lu_zero> and switching from flat archives to flat archives with deps [16:32:48] <lu_zero> doesn't sound _that_ wrong [16:33:22] <uau> it's take a lot of years before you could rely on linkers being updated "naturally" [16:33:32] <uau> anyway what advantage would that have over pkg-config? [16:33:45] <lu_zero> one less program [16:33:53] <mru> that's a bonus [16:34:02] <lu_zero> one less program that needs a variant for each toolchain you are using [16:34:19] <mru> tightly coupling the dep information to the thing that actually has the dependency is more robust [16:34:19] <lu_zero> one less file around your disk per library [16:34:39] <mru> no risk of picking up the wrong dep file [16:34:50] <mru> as pkgconfig has a habit of doing [16:34:52] <lu_zero> so it isn't that wrong as idea [16:35:12] <lu_zero> one copy of glib less in your system btw [16:35:12] <mru> all the other things pkgconfig does don't need to be done [16:35:26] <lu_zero> mru: which are? [16:35:33] <mru> --cflags comes to mind [16:35:36] <uau> why would there be no risk of picking the wrong file? [16:35:50] <mru> uau: then you'd be picking the wrong lib too [16:35:54] <uau> how would they be coupled to avoid that? [16:36:01] <uau> to prevent updating one without the other etc? [16:36:11] <mru> have you ever seen a linker pick the DT_NEEDED entries from the wrong .so? [16:36:19] <lu_zero> they are the same file ^^; [16:37:01] <uau> mru: there's just one .so file [16:37:07] <mru> exactly [16:37:08] <uau> you talked about separate linker script file [16:37:16] <lu_zero> embedded in the .a [16:37:20] <mru> I talked about placing a dep file inside the .a [16:38:07] <uau> "replacing the .a with a linker script referencing the real .a and all deps" <- so you meant just the current gnu ld with that, and wanted that to change too? [16:42:05] <uau> anyway the cflags support in pkg-config is often beneficial [16:42:13] <mru> I disagree [16:42:23] <uau> for example it allows switching libraries with a simple PKG_CONFIG_PATH change [16:42:32] <mru> C_INCLUDE_PATH [16:43:15] <uau> wouldn't work for linking [16:43:29] <mru> LIBRARY_PATH [16:43:49] <mru> and you still need to update the dynamic loader search path separately [16:50:20] <uau> another thing is different library versions installed simultaneously [16:50:41] <mru> which pkgconfig has no notion of [16:51:41] <divVerent> 17:13:21 @BBB | bilboed: got it, we're gonna move a lot of stuff like AVCodecContext stuff into private codec-specific AVOptions [16:51:46] <uau> you can have /usr/include/foo2/foo/foo.h, /usr/include/foo3/foo/foo.h; applications include <foo/foo.h>, pkg-config file can select which one is added to path [16:51:51] <divVerent> will you do this keeping the current option names? [16:52:22] <mru> as can C_INCLUDE_PATH [16:52:44] <uau> again doesn't work for linking [16:52:50] <mru> again, LIBRARY_PATH [16:52:54] <mru> if you want, you can make a tool to manipulate those vars [16:53:01] <mru> in fact, such tools exist [16:53:03] <uau> no library_path doesn't help there [16:53:28] <mru> of course it does [16:53:38] <mru> the linker searches $LIBRARY_PATH after -L paths [16:54:20] <uau> and using two variables plus explicit paths gets cumbersome [16:54:39] <mru> so make a tool to set them for you [16:54:43] <mru> call it pkgconfig if you like [16:55:49] <uau> and what would be the benefit over current pkg-config? a lot more cumbersome to use, with a lot less functionality (which you think can be abused, but which is also useful)? [16:56:58] <uau> also i think i already mentioned before the case of headers exposing functionality from other libraries - in that case you need pkg-config even with shared libraries [16:57:25] <mru> /ignore uau [16:58:07] <uau> pkg-config is used to solve real problems by linux distributions and other users [16:58:24] <uau> and no those problems could not be solved by any linker .a dependency support or other such means [17:01:41] <divVerent> you two didn't even talk about the same thing [17:01:54] <divVerent> in MY opinion, we need BOTH pkg-config, and this "libdeps" stuff ideally inside the .a [17:01:55] <mru> divVerent: that's uau in a nutshell [17:02:06] <divVerent> these things are meant to solve different problems [17:02:18] <divVerent> pkg-config = convenient way to get CFLAGS/LDFLAGS/... for linking with a library [17:02:28] <divVerent> however, IMHO static and dynamic linking should NOT need different -l flags [17:02:37] <divVerent> which some "libdeps" support would fix [17:02:41] <mru> it's wrong of a library to require specific cflags [17:02:47] <divVerent> no [17:02:57] <mru> show me an example where it's needed [17:02:58] <divVerent> library has every right to require -I/usr/include/mylib [17:03:01] <mru> no [17:03:10] <divVerent> however, this is the ONLY flag the library should require [17:03:20] <divVerent> so instead of -I options, a list of paths would be just as good [17:03:22] <mru> if I install it with --prefix=/usr, no more flags should be needed [17:03:30] <mru> if I install it to some other prefix, that's my problem [17:03:30] <divVerent> tell that to the Gtk guys [17:03:42] <mru> yes, gtk et al are badly designed [17:03:56] <divVerent> it does make sense though... it MAY help at fixing clashes [17:04:22] <divVerent> one issue BTW: wouldn't it be good to allow installing multiple versions of the same package into one prefix? [17:04:24] <mru> I don't understand why they put their headers inside an extra level of directories [17:04:25] <divVerent> in /usr/lib you can [17:04:31] <divVerent> just multiple libfoo.version.so files [17:04:40] <divVerent> but in /usr/include there is no support for that [17:04:42] <mru> but it's not one prefix that way [17:04:51] <divVerent> this is what people are building with the include path stuff [17:04:53] <mru> it's different prefixes with a common prefix [17:04:57] <divVerent> we still NEED some handling for that [17:05:04] <divVerent> like: you have multiple apps in your distro [17:05:08] <divVerent> one for libjpeg62 [17:05:10] <divVerent> other for libjpeg8 [17:05:15] <divVerent> this is fine for dynamic linking [17:05:19] <mru> libjpeg8 sucks anyway [17:05:24] <divVerent> but you wouldn't be able to recompile them in a single prefix [17:05:34] <divVerent> IMHO we need a solution that is BETTER than the current -I hack [17:05:43] <divVerent> but we still need a way to have two versions of one lib in one prefix [17:05:52] <mru> it's not one prefix [17:05:56] <divVerent> IT IS [17:05:57] <mru> it's two [17:05:59] <divVerent> same /usr/lib directory [17:06:02] <divVerent> same path of the .so file [17:06:12] <mru> you're confusing things [17:06:19] <divVerent> both have --prefix=/usr [17:06:27] <mru> the dynamic loader works with multiple versions in the same directory [17:06:30] <mru> the link editor does not [17:06:42] <divVerent> yes, another thing to be solved there [17:06:43] <mru> there's only one .so but multiple .so.X [17:06:49] <divVerent> we also need support for libx.version.a [17:07:12] <mru> easy: put them in /usr/blah-vX/{include,lib} [17:07:14] <divVerent> thing is... the current way, you can have applications in your prefix that you cannot recompile on your system [17:07:16] <divVerent> and THAT sucks [17:07:35] <divVerent> okay... assume an app needs nondefault libjpeg62, AND nondefault libboost [17:07:38] <divVerent> where does it go? [17:07:42] <divVerent> /usr/jpeg-v62 [17:07:45] <divVerent> or /usr/boost-v1.30? [17:07:59] <mru> neither [17:08:05] <mru> jpeg goes in jpeg, boost in boost [17:08:14] <divVerent> yes, but where does your application go that needs both? [17:08:14] <mru> you _build_ the special app with special flags [17:08:20] <mru> that makes it link to the right sonames [17:08:24] <divVerent> so you basically install every single lib into a separate prefix? [17:08:27] <mru> the .so.X files can be in a common place [17:08:41] <divVerent> how is that better than the current way of the include subfolders? [17:08:49] <divVerent> it looks like the very same mess to me [17:09:02] <mru> you can have one default version available in /usr/include [17:09:07] <mru> by symlinks or whatever [17:09:17] <divVerent> I mean... if you do this, do it consistently [17:09:22] <divVerent> install EVERY app into its own prefix [17:09:22] <mru> and override with flags or env vars when needed [17:09:24] <divVerent> and every lib [17:09:27] <divVerent> and symlink them to the common dirs [17:09:31] <mru> I'd be fine with that [17:09:34] <divVerent> THAT would actually be sane in the end [17:09:46] <divVerent> although... it'd be cloning C:\Program Files :P [17:09:46] <mru> I used to have a system built like that [17:09:50] <mru> no [17:09:53] <divVerent> yes, it was called Windows :P [17:10:02] <mru> windows is a mess [17:10:16] <divVerent> yes, it contains many good ideas, but slapped together in a bad way [17:10:22] <divVerent> C:\Program Files is nice [17:10:24] <wbs> lu_zero: pong [17:10:26] <divVerent> but not having the programs in PATH sucks [17:10:36] <divVerent> and still dumping the DLLs into system32 sucks more [17:10:37] <mru> and each bundling their own dlls sucks [17:11:01] <mru> separate install dirs and some symlinks could solve a lot of things [17:11:10] <j-b> Saying C:\Program Files is nice is a stupid attempt to troll [17:11:12] <mru> in fact, many distros do just that for selected packages [17:11:16] <divVerent> still, I am not opposed to include paths per library, as a somewhat "lightweight prefix" [17:11:20] <j-b> mru: you mean, like /Applications? [17:11:20] <divVerent> but it should also be optional, IMHO [17:11:23] <mru> cf debian alternatives or gentoo eselect [17:11:35] <mru> j-b: now who's trolling? [17:11:38] <divVerent> j-b: c:\program files is not that bad... just "fix it" ;) [17:11:42] <divVerent> it is broken, but a good idea [17:11:44] <divVerent> implemented wrong [17:12:04] <j-b> divVerent: it is broken in so many ways... /Applications is way betterly done. [17:12:13] <divVerent> yes, but also broken [17:12:17] <divVerent> also not in PATH, for example [17:12:23] <divVerent> but yes, better done than on Windows [17:12:30] <divVerent> at least it makes installing/uninstalling easy [17:12:41] <divVerent> as applications are ENTIRELY in their dir (by the idea, not in practice on OS X, though) [17:13:00] <divVerent> too many OS X apps "install" stuff to system-shared locations for no good reason, though [17:13:13] <BBB> divVerent: what do you mean? current existing AVOptions? mostly, if they match [17:13:14] <divVerent> but that is clearly fault of the apps [17:13:18] <j-b> And it doesn't have the space in the middle of the name, and it doesn't have this stupid (x86) in it [17:13:19] <BBB> divVerent: we'll keep compatibility of course [17:13:22] <BBB> divVerent: but only so far [17:13:24] <divVerent> BBB: great [17:13:49] <divVerent> I just changed my own code that used 2 x264 specific options from using AVCodecContext->refs (and max_b_frames) to the get_int and set_int functions [17:13:53] <divVerent> to make this transition easier [17:14:40] <divVerent> j-b: space in the middle name, solved in German Windows ;) [17:14:44] <divVerent> C:\Programme [17:15:06] <divVerent> and of course, you can always hint to another stupid design flaw of windows, and just call it c:\progra~1 [17:15:17] <divVerent> which STILL WORKS ON NTFS FOR NO GOOD REASON WHATSOEVER [17:15:57] <j-b> divVerent: right, great idea to rename this folder in every $LANG [17:16:14] <divVerent> j-b: not THAT bad [17:16:22] <divVerent> applications should not explicitly reference it by name anyway [17:16:30] <j-b> /Applications is therefore, better [17:16:38] <divVerent> almost [17:16:41] <j-b> not to mention simpler [17:16:48] <divVerent> /Applications is too reliable, unfortunately [17:17:07] <divVerent> so I am sure some crappy app coder relies on his app to be EXACTLY in /Applications, EXACTLY under the correct name [17:17:13] <divVerent> so if the user moves or renames it, it breaks [17:17:23] <divVerent> which is EXACTLY WHAT /Applications IS SUPPOSED TO MAKE EASY [17:17:47] <divVerent> thing is, everyone knows that hardcoding c:\program files will break your app [17:17:58] <divVerent> but hardcoding /Applications/Foo.app on OS X... I can see that happen [17:18:15] <mru> divVerent: localising names of system directories is annoying as hell too [17:18:24] <divVerent> mru: I do not like that [17:18:36] <divVerent> but also hate apps that assume they are installed in a hardcoded location [17:18:52] <divVerent> bad enough that *x binaries typically assume such a thing (or rather, assume to know where the libraries are, although this is fixable) [17:29:03] <mmu_man> cc7ywhbe.s:273:no such instruction: `xgetbv' [17:29:05] <mmu_man> oops [17:31:39] <elenril> o/ [17:34:00] <mmu_man> f* can't seem to get a way to remux those .ts properly :((( [17:34:19] <mmu_man> ffmpeg complains and stops, and vlc goes along but the resuls doesn't have audio it seems [17:34:31] <mru> mmu_man: try -fflags +nofillin-genpts [17:34:52] <mru> and possibly also -strict 1 -vsync 0 [17:35:07] <mru> those should disable most of the insane pts butchering [17:38:58] <Kovensky> 14:15.18 divVerent: which STILL WORKS ON NTFS FOR NO GOOD REASON WHATSOEVER <-- do you know why files can't have [:/?*><] in their names in windows? because of DOS backwards compatibility, even on NTFS which supposedly treats filenames as opaque data [17:39:24] <divVerent> sure [17:39:31] <divVerent> well, : would be a problem anyway [17:39:33] <Kovensky> they can't have '\' for obvious reasons, but NTFS still doesn't forbid it [17:39:37] <divVerent> and on POSIX / is not allowed either [17:39:53] <divVerent> so, forbidding :, \ and / is excusable [17:40:00] <divVerent> (Windows API allows generally / and \ as path separator) [17:40:05] <Kovensky> yes, but they don't forbid / because of POSIX, they forbid / because it confuses the DOS parser [17:40:17] <mru> ntfs also uses : for the ridiculous "forks" [17:40:24] <divVerent> so they only support POSIX style paths because / was confusing DOS apps anyway [17:40:29] <divVerent> mru: yes [17:40:30] <Kovensky> if / was valid then it'd have to decide if "dir/w" was "file w in folder dir" or "dir /w" [17:40:31] <divVerent> which is funny [17:40:42] <divVerent> if in your current dir, you have a file "c" with an alternate data stream "foo"+ [17:40:49] <divVerent> how do you e.g. type it? [17:40:53] <divVerent> type c:foo = FAIL [17:40:59] <Kovensky> mru: : is forbidden though because of relative paths [17:41:07] <Kovensky> each drive letter has its own CWD [17:41:12] <mru> I know [17:41:14] <mru> it's insane [17:41:20] <divVerent> still... how to do this [17:41:23] <divVerent> type .\c:foo [17:41:25] <divVerent> or what? [17:41:34] <divVerent> not like POSIX is much better for that... [17:41:40] <mru> posix doesn't have forks [17:41:40] <divVerent> as an exercise: [17:41:42] <divVerent> su - [17:41:45] <divVerent> cd ~unsuspecting_user [17:41:45] <mru> well, posix has fork() [17:41:50] <divVerent> touch -- '-rf *' [17:41:50] <mru> which windows doesn't [17:41:53] <divVerent> wait for him to delete it [17:41:54] <mmu_man> mru: ahh thx, will try this [17:42:08] <mmu_man> testing with vlc on the mac atm, maybe it's less buggy than the old one [17:42:08] <mru> mmu_man: the xgetbv patch? [17:42:16] <mmu_man> pts stuff [17:42:23] <divVerent> mru: I mean, using : as separator for both drive letters AND alternate dara streams is insanely badly designed [17:42:29] <mmu_man> got a patch to test for xgetbv ? [17:42:31] <divVerent> as it makes paths like "c:foo" ambiguous [17:42:40] <mru> mmu_man: of course [17:42:46] <mru> if I break stuff, I fix it [17:43:01] <divVerent> I wonder... "x:foo" - will this be a stream "foo" of file "x" if drive letter x: does not exist, and X:(current cwd of X:)\foo if it does exist? [17:43:02] <Kovensky> 14:41.54 divVerent: wait for him to delete it <-- that tab completes to -rf\ * though [17:43:06] <mmu_man> Kovensky: at least : on NTFS serves as named stream separator [17:43:07] <elenril> so get_buffer -> avio_read? [17:43:10] <mru> lu_zero: ok to push the xgetbv patch? [17:43:12] <divVerent> Kovensky: which still fails, though :P [17:43:16] <mru> elenril: that's the plan [17:43:20] <elenril> sounds nice [17:43:25] <elenril> doesn't it conflict with anything? [17:43:32] <mru> don't think so [17:43:53] <divVerent> Kovensky: only ways to delete it, apart from using wildcards, are stuff like ./-rf\ \*, or -- '-rf *' [17:44:13] <mru> './-rf *' [17:44:16] * Kovensky prefers to use the ../ approach [17:44:18] <divVerent> especially fun, if you do something on * (wildcard), and have files that start with - [17:44:20] <Kovensky> ./* [17:44:23] <Kovensky> derp [17:44:26] <divVerent> yes [17:44:32] <divVerent> I also prefer the ./ [17:44:34] <divVerent> but it sucks :P [17:44:42] <divVerent> I think the UNIX haters handbook mentions this issue already [17:44:53] <mmu_man> hmm the OSX gui for vlc freaks out sometimes... [17:44:55] <divVerent> not that windows would do it any better, though [17:45:02] <mmu_man> [0x10029f9f8] macosx interface debug: input has stopped, refreshing interface [17:45:06] <mmu_man> [0x10029f9f8] macosx interface debug: input has changed, refreshing interface [17:45:09] <mmu_man> [0x10029f9f8] macosx interface debug: input has stopped, refreshing interface [17:45:13] <mmu_man> [0x10029f9f8] macosx interface debug: input has changed, refreshing interface [17:45:16] <mmu_man> :)) [17:45:55] <mru> I read some horror story somewhere about a script containing the line "rm -rf $foo/$bar" to do some cleanup towards the end [17:46:01] <divVerent> had they e.g. used "::" for alternate data streams, it would have been SO much nicer [17:46:13] <mru> as luck would have it, on one run, both $foo and $bar were empty... [17:46:35] <mru> and the machine had nfs-mounted lots of things as well [17:46:45] <mru> so before anyone knew it, the entire network was blank [17:47:15] <divVerent> mru: hehe... mru I once had this in a makefile of a project of mine [17:47:17] <divVerent> + [ "$(OS)" != "Darwin" ] || $(RM_R) $(INSTALLDIR_BASE)/ [17:47:26] <mmu_man> mru: ouch :)) [17:47:29] <divVerent> also, INSTALLDIR_BASE was ONLY set if OS is Darwin [17:47:41] <mmu_man> mru: running as root of course [17:47:44] <divVerent> it didn't dop any harm... [17:47:53] <divVerent> but the "rm -rf /" printed by make was quite scary to someone :P [17:48:57] <mru> guess why I run untrusted scripts in sandboxes [17:49:17] <divVerent> just, what DO you trust [17:49:40] <divVerent> also, if you don't trust the scripts of the app you compile [17:49:45] <divVerent> why would you trust the program itself any more [17:50:52] <divVerent> speaking of [ ... || ... [17:51:04] <elenril> BBB: can you look at the av_alloc_put_byte renaming patch? [17:51:10] <elenril> it's pretty small, shouldn't take you long [17:51:11] <divVerent> at work, we had a script using if [ foo == bar ]; then notation [17:51:21] <mru> == is wrong [17:51:25] <divVerent> not on Linux [17:51:28] <mru> not in bash [17:51:31] <divVerent> but that script tested uname result for Solaris :P [17:51:35] <mru> bash != linux [17:52:06] <divVerent> indeed, /usr/bin/[ also does not know == here [17:52:25] <divVerent> just... the code SHOULD have assumed Solaris as the last else case [17:52:37] <divVerent> BUT: Solaris's shell aborts the script on [/test related syntax error [17:52:43] <mru> also watch out for [ $foo = $bar ] expanding to something like [ foo = bar -o a = a ] [17:52:47] <divVerent> yes [17:52:57] <divVerent> I always use [ x"$foo" = x"$bar" ] if I don't trust the input [17:52:59] <mru> always good practice to use [ "x$foo" = "x$bar" ] [17:53:04] <relaxed> bsd's sh will fail with == too [17:53:04] <divVerent> same thing :P [17:53:14] <divVerent> I like putting the x outside, but this is just cosmetics [17:53:25] <mru> yeah, saw your line as I pressed enter [17:53:55] <mru> people bitch about these things [17:53:55] <divVerent> zsh has a nice feature... which unfortunately is default [17:53:59] <divVerent> it prevents word splitting on $foo [17:54:13] <divVerent> however, I rely on word splitting often in my scripts, at other places [17:54:17] <mru> but they haven't understood how to use them cleverly [17:54:38] <divVerent> so I ended up having to setopt SH_WORD_SPLIT in my script if ZSH_VERSION is set [17:54:56] <mru> the ffmpeg scripts do all sorts of crazy things [17:54:57] <divVerent> also, many of my scripts have a variable defined like this: [17:54:59] <divVerent> LF=" [17:55:01] <divVerent> " [17:55:25] <divVerent> seems to be the only portable way to get a linefeed [17:55:30] <divVerent> even `echo` is unreliable :P [17:55:30] * elenril rtfms about some sed-fu [17:55:42] <divVerent> or even, usually not even generating a linefeed [17:55:49] <divVerent> because the shell is so nice and strips it again [17:55:53] <divVerent> LF=`echo;echo` :P [17:56:09] <Sean_McG> 'lo folks [17:56:18] <divVerent> wait, not even that works :P [17:56:49] <mru> I ran into a weird one along those lines once [17:57:04] <mru> using an alternate expansion containing double-quotes inside a here-doc [17:57:12] <mru> apparently doesn't work in some shells [17:57:19] <mru> not quite sure what the spec says [17:58:01] <mru> but some shells do quote removal on the expansion, some don't [17:58:18] <Sean_McG> here's lookin' at you, bash [17:58:18] <mru> quote='"' solved it [17:58:56] <elenril> get_partial_buffer -> avio_read_partial? [17:59:02] <Sean_McG> it's "fun" trying to wrestle with that when configure scripts have --extra-[cflags|ldflags|libs] [17:59:29] <mmu_man> hmm still haven't understood this --sout syntax on vlc... seems it doesn't work the same on old versions [18:00:31] <mmu_man> and I can't assert if those streams are interlaced or not, there are strange artifacts when things move but deinterlacing isn't much better [18:00:38] <divVerent> one sometimes broken thing I do rely on in my scripts is "$@" [18:00:48] <divVerent> I don't go with the ${1+"$@"} crap [18:01:25] <divVerent> POSIX says "$@" is nothing (not "") if $# is 0, and I do not see any reason to support BROKEN shells [18:01:38] <divVerent> especially as ${1+"$@"} breaks in zsh :P [18:01:43] <mru> to my knowledge, ffmpeg configure works with a strict posix shell [18:02:03] <Sean_McG> what's your reference? [18:02:04] <mru> zsh doesn't even try to be posix [18:02:10] <Sean_McG> POSIX compliance is such an iffy thing [18:02:18] <mru> Sean_McG: I read the spec [18:02:29] <mru> and I run the scripts in many different shells [18:02:30] <Sean_McG> OK, and what about the implementations? or [18:02:39] <Sean_McG> anyways just playing devils advocate [18:02:59] <mru> it works with bash, dash, ksh, /usr/xpg4/bin/sh, irix sh, tru64 sh, qnx sh, etc, etc [18:03:13] <divVerent> hehe [18:03:14] <mru> apple sh too [18:03:15] <Sean_McG> you have access to a QNX box? [18:03:19] <mru> sure [18:03:27] <mru> it's free for non-commercial use [18:03:45] <mru> and if you say you're a "consultant" [18:03:58] <mru> a sane business model if you ask me [18:04:02] <Sean_McG> ah, yeah there's one in FATE...never noticed it before (probably because it's green) [18:04:17] * kshishkov usually gives name of imaginary friend in Kazakhstan in these cases [18:04:31] <mru> Sean_McG: note the 0 in the gcc version string there [18:04:35] <mru> that's a bug in qnx expr [18:08:23] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * ref66953875 ffmpeg/libavutil/x86/cpu.c: [18:08:23] <CIA-15> ffmpeg: x86: use raw opcode for xgetbv instruction [18:08:23] <CIA-15> ffmpeg: This allows the CPU detection to work with assemblers not supporting [18:08:23] <CIA-15> ffmpeg: the xgetbv mnemonic. These include clang and some BSD versions. [18:08:23] <CIA-15> ffmpeg: All AVX code will be written for yasm, where the main assembler [18:08:24] <CIA-15> ffmpeg: is not involved. [18:08:25] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:08:28] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r1efa772e20 ffmpeg/libavcodec/amrnbdec.c: [18:08:28] <CIA-15> ffmpeg: amrnb: use correct size when copying lsf_r array [18:08:28] <CIA-15> ffmpeg: lsf_r is an array of int16_t, not float. [18:08:28] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:08:33] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r08df7f8666 ffmpeg/Makefile: [18:08:33] <CIA-15> ffmpeg: Makefile: include deps from tools directory [18:08:33] <CIA-15> ffmpeg: This ensures the tools are rebuilt when necessary. Specifically, [18:08:33] <CIA-15> ffmpeg: lavfi-showfiltfmts was sometimes not rebuilt causing spurious test [18:08:34] <CIA-15> ffmpeg: failures. [18:08:34] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [18:08:53] <mru> mmu_man: xgetbv workaround committed [18:10:21] <ruggles> ??? where is avcodec_parse_frame() implemented? [18:11:45] <mru> huh? [18:12:03] <mru> mmu_man has a shitty assembler that doesn't know the xgetbv instruction [18:13:02] <kshishkov> mru: don't they still use GCC 2.95 in Haiku? [18:13:31] <mmu_man> kshishkov: that was in OSX [18:13:32] <mru> kshishkov: fate says 4.4.4 [18:13:49] <mmu_man> well we use both actually [18:13:56] <mmu_man> didn't even try to build with 2.95 [18:14:03] <mmu_man> yet [18:14:10] <ruggles> mru: if you were referring to my question, avcodec_parse_frame() is in avcodec.h but I can't find the actual implementation anywhere. [18:14:21] <kshishkov> mmu_man: my outdated OSX still had 3.3 and 4.0 IIRC [18:14:41] <mru> ruggles: it doesn't exist [18:15:19] <mmu_man> mru: builds now [18:15:37] <mmu_man> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) [18:15:44] <mmu_man> didn't apply the latest OSX update yet [18:15:50] <mmu_man> the one with this crappy app store [18:17:44] <ruggles> mru: that's weird. why is the prototype still there? and the documentation for CODEC_CAP_PARSE_ONLY still refers to it. [18:18:10] <mru> I can't find evidence of it ever existing [18:18:33] <kshishkov> ruggles: why do we have parsers then? [18:20:04] <ruggles> kshishkov: this is something different. decoding without writing output. not splitting packets into frames. [18:20:26] <ruggles> i think... [18:21:20] <mru> it was meant to decode only the frame headers [18:21:29] <mru> for things like picture reordering [18:23:32] <ruggles> the CODEC_CAP is only used by the mpegaudio decoder [18:25:28] <mmu_man> [mp4 @ 0x8bb6c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 30738 >= 30738 [18:25:32] <mmu_man> mru: still no way [18:25:43] <mmu_man> ffmpeg -i sgu_0008.ts -acodec copy -vcodec copy -fflags +nofillin-genpts -strict 1 -vsync 0 tmp_0003_test.mp4 [18:32:10] <Sean_McG> awwww crap, I forgot... my fate-suite is at home [18:32:13] <mru> mmu_man: -fflags before -i [18:32:27] <Sean_McG> oh well, I guess I'll watch some of my Dr. Who DVDs [18:32:52] <mru> or grab a new copy of the fate suite [18:32:56] <Sean_McG> mru: maybe we should error out on that? [18:33:08] <Sean_McG> (the fflags bit) [18:34:09] <mru> fflags can apply to output as well [18:34:28] <Sean_McG> ah [18:35:01] <mmu_man> mru: yeah I noticed that, oddly the result is quite small then [18:36:42] <mmu_man> vlc seems to work on the mac, just implies reading and writing to SMB shares but well [18:36:42] <mru> mmu_man: apparently you're victim of the same "illusion" as myself and lu_zero then [18:36:49] <mmu_man> ah [18:37:00] <mmu_man> maybe it's just my glasses that need an upgrade [18:37:07] <mru> certain individuals insist there's nothing wrong with the code [18:38:10] <Sean_McG> I have a gcc trunk build failure to bugzilla today anyways [18:38:40] <mmu_man> the resulting file is 261 bytes [18:38:56] <mmu_man> nice compression from 700MB [18:42:56] <mmu_man> cartainly competes with I2BP [18:43:32] <mru> heh [18:55:28] * elenril wonders what to do with put_nbyte and put_tag [18:56:49] <Anssi> I'd do to put_nbyte the same as for put_byte, to stay consistent [18:57:33] <elenril> avio_wn8 doesn't look all that readable [18:59:09] <lu_zero> bilboed-tp: could you convince Gustavo Noronha to drop the use of cmake? [19:00:21] <elenril> BBB: appears mpd is using URLContext as well [19:00:48] <Sean_McG> mru: any objections to a patch to force fate.sh to use LANG=C and LC_*=C ? would prevent those wierd ligature characters in the reports [19:06:06] <elenril> BBB: yeah, get rid of the 'e' [19:06:15] <elenril> i was just going to do that myself [19:15:15] <mru> hmm, this food actually came quite edible... [19:34:38] <Flameeyes> I .. can't... belive... this ... crap! [19:35:03] <kshishkov> order to beam it up [19:35:03] <mru> need some help? I can believe almost any crap [19:35:22] <kshishkov> mru: believe GSt then :P [19:35:27] <mru> kshishkov: one crap to beam up? [19:35:31] <Flameeyes> mru: the bug is NOT in ffmpeg's .pc files [19:35:34] <Flameeyes> it's in pkg-config itself.. [19:35:42] <elenril> no Flameeyes, you are the demons [19:35:43] <Flameeyes> or at least in the version available on ubuntu... [19:35:44] <mru> Flameeyes: I've believed that for a long tmie [19:37:31] <Flameeyes> flame@yamato static % PKG_CONFIG_PATH=$(pwd)/libavformat:$(pwd)/libavcodec:$(pwd)/libavutil:$(pwd)/libavcore pkg-config --libs 'libavformat >= 52.31.0 libavcodec >= 51' [19:37:31] <Flameeyes> /home/flame/devel/repos/git/ffmpeg/static/libavformat/libavformat.a -pthread /home/flame/devel/repos/git/ffmpeg/static/libavcodec/libavcodec.a /home/flame/devel/repos/git/ffmpeg/static/libavutil/libavutil.a /home/flame/devel/repos/git/ffmpeg/static/libavcore/libavcore.a -ldl -lasound -lm -lbz2 -lz [19:37:31] <Flameeyes> flame@yamato static % PKG_CONFIG_PATH=$(pwd)/libavcodec:$(pwd)/libavformat:$(pwd)/libavutil:$(pwd)/libavcore pkg-config --libs 'libavformat >= 52.31.0 libavcodec >= 51' [19:37:31] <Flameeyes> /home/flame/devel/repos/git/ffmpeg/static/libavcodec/libavcodec.a -pthread /home/flame/devel/repos/git/ffmpeg/static/libavformat/libavformat.a /home/flame/devel/repos/git/ffmpeg/static/libavutil/libavutil.a /home/flame/devel/repos/git/ffmpeg/static/libavcore/libavcore.a -ldl -lasound -lm -lbz2 -lz [19:37:35] <Flameeyes> [sorry for the small flood] [19:38:09] <Flameeyes> it prints the libs ordering "first found, first printed", not "first requested, first printed" [19:38:32] <Flameeyes> _even_ if I don't explicit libavcodec (and is thus brought in as a libavformat Require) [19:38:41] <Flameeyes> but this breaks positional argument parsing! [19:41:30] <lu_zero> ... [19:41:33] <lu_zero> wonderful... [19:42:45] <Flameeyes> [and since this is Gentoo, the bug is still there..] [19:44:42] <kshishkov> Flameeyes: ask mru for ffmpeg.m4 instead [19:45:05] <mru> the only m4 you'll find around here is cortex [19:45:28] <Flameeyes> kshishkov: uhm, you do know I write on spare time an autotools guide, right? :) [19:45:48] <kshishkov> Flameeyes: nope, I still had some respect for you [19:45:59] <kshishkov> mru: but you like macro languages [19:46:17] <uau> Flameeyes: hmm what exactly broke there? [19:46:19] <Flameeyes> kshishkov: it is tremendously helpful to write how to do things sanely, when pointing upstreams to fix their crap [19:47:04] <Flameeyes> uau: ld discards libavcodec.a because it's not required by anything at that point, then it picks up libavformat.a, which requires libavcodec.a, (which was discarded earlier) [19:48:31] <lu_zero> kshishkov: the autotools guide show how to unbreak autotools [19:49:10] <kshishkov> lu_zero: 0. don't install autotools 1. tell maintainers not to use it too [19:52:01] <Flameeyes> kshishkov: so you end up with a bunch of custom-written unusable build systems [19:52:12] <Flameeyes> trust me, I know they are bad, but I have seen much worse by people trying to avoid them. [19:52:21] * kshishkov looks at FFmpeg [19:52:46] <Flameeyes> ffmpeg is a rare exception, really. [19:53:55] <ohsix> is that sum special pleading i see there [19:54:20] <lu_zero> kshishkov: the result is cmake [19:54:25] <lu_zero> that is even more icky... [19:54:38] <ohsix> and scons [19:54:49] <ohsix> the problem is you actually need to build software, which is lame! [19:54:54] <Flameeyes> ohsix: thanks, now I'll have nightmares for anothre week [19:54:56] <lu_zero> ohsix: scons is getting better usage [19:55:04] <Flameeyes> lu_zero: no it's not [19:55:09] <lu_zero> waf on the other hand is getting misused even more [19:55:31] <Flameeyes> scons makes me wish imake was still in use... wait it is. [19:55:39] <lu_zero> O_o... [19:55:42] <lu_zero> imake... [19:55:47] <mru> imake isn't that bad [19:55:50] <lu_zero> now I'll have nightmares... [19:55:51] <Flameeyes> mru: scons is. [19:55:57] <mru> for the specific domain it was intended for [19:55:57] <lu_zero> mru: imake IS bad [19:56:02] <kshishkov> lu_zero: xmkmf -a [19:56:15] <lu_zero> expecially for xf86 it was bad [19:56:25] <mru> I never had any trouble with it [19:56:28] <ohsix> imake was for purpose, if you're saying imake is bad isn't that a knock at any NIH build systems? [19:56:55] <lu_zero> mru: did, a number of times ^^; [19:57:11] <ohsix> imake was a blocker for it being broken up even a little, that's about it [19:57:26] <mru> lies [19:58:01] <mru> and the damn "modular" x is a disaster [19:58:18] <mru> with the monolithic one you at least got matched versions of things [19:58:34] <ohsix> they're putting some of the bits back together to make it easier to build, some things did really belong together when it finally shook out [19:58:45] <Flameeyes> ohsix: like includes and libraries? :D [19:58:46] <ohsix> but that's with everyone moving at once [19:58:47] <mru> now, if you get the wrong micro version of some obscure lib, things start blowing up at runtime [19:59:22] <ohsix> Flameeyes: like the drm bits and some of the trivial extensions, the rest i don't have a clear picture on [19:59:23] <lu_zero> mru: it's part of the trade off [19:59:31] <mru> it's a tradeoff I'd rather not make [19:59:40] <lu_zero> now it builds in minutes and not hours [19:59:48] <mru> the old one was faster to build and worked every time [20:00:02] <lu_zero> and now a breakage in some stupid fringe bit won't bring everything down [20:00:04] <ohsix> now jhbuild does it for you D: [20:00:17] <mru> now you have to run configure scripts for minutes to compile a single .c file [20:00:30] <ohsix> i don't [20:00:44] <lu_zero> mru: what they do had been overzealous I do agree [20:00:50] <mru> moving out some of the utilities might be a good idea [20:00:55] <mru> but the core libs should stay together [20:00:56] <lu_zero> still better than the past [20:01:04] <lu_zero> mru: which core libs? [20:01:05] <ohsix> and config.cache when you're building a bunch of related stuff with matching tests can save some time [20:01:11] <mru> lu_zero: the ones you can't be without [20:01:14] <lu_zero> motif? ^^ [20:01:25] <Flameeyes> ohsix: sorta [20:01:29] <lu_zero> Xt? [20:01:45] <Flameeyes> ohsix: config.cache is very unreliable on my experience [20:01:46] <lu_zero> still it might grouped better [20:01:49] <ohsix> Flameeyes: i know it breaks, was just sayin' [20:02:03] <lu_zero> it's like we split each libav* in a separate package [20:02:03] <ohsix> right, mismatched tests and different versions of aclocal [20:02:08] <mru> lu_zero: most of the libX* ones [20:02:13] <lu_zero> with ffplay and ffmpeg split as well [20:02:16] <lu_zero> and every tool [20:02:32] <Flameeyes> ohsix: even mismatched languages.. ac_cv_* variables are language-agnostic.. breaks pretty badly when you mix C, C99 and C++ :( [20:03:15] <ohsix> i'm just thinking with jhbuild + the xorg modules; i know its untenable as a global cache [20:03:49] <ohsix> they could version everything in the cache and make it more ugly :D [20:04:41] <ruggles> there is no fate test for the mp3 decoder? wtf? [20:04:58] <ohsix> mp3 is for communists [20:05:06] <uau> Flameeyes: looks like pkg-config has some logic to keep things in path order, to keep -L arguments in correct search path order; OTOH it looks like -l and -L should get handled separately [20:05:15] <Sean_McG> lol [20:05:23] <kshishkov> ruggles: well, you obviously use only AC3 and FLAC for your files [20:05:33] <ruggles> :P [20:06:12] <kshishkov> I just try to play whatever I got with my decoders [20:17:45] <uau> Flameeyes: i think your problem occurs because in your case pkg-config is picking up the -uninstalled variants of the .pc files, and those use 'path/foo.a' instead of '-Lpath -lfoo'; the former isn't recognized as an -l argument that should be sorted in dependency order [20:18:08] <Flameeyes> uau: it still should reflect the Requires: order not the PKG_CONFIG_PATH order. [20:18:34] <uau> no, it should not do that for all the arguments [20:18:49] <uau> doing that for -L would be wrong [20:19:06] <uau> because it would lead to the wrong library being picked up if versions existed in multiple directories [20:21:43] <Flameeyes> uau: well it leads to libraries to be dismissed randomly the way it is done now, so what's worse? [20:22:05] <ruggles> i'm trying to test the mp3float decoder, but i can't seem to get ffmpeg to select it. any suggestions? [20:22:35] <mru> whatever fate-mp3-float-* does [20:23:52] <uau> Flameeyes: the problem is specific to the use of arguments other than -lfoo to load the libraries; if you change the .pc file to use "-Lpath -lfoo" instead of "path/foo.a" i think it should work [20:24:32] <ruggles> mru: ah, thanks. i missed the separate fate Makefile for mp3 [20:25:33] <Sean_McG> mru: what *is* that 0 in the qnx gcc ident? [20:26:29] <uau> Flameeyes: why are you using the uninstalled versions btw? rather than installing to a temporary dir? [21:05:27] <BBB> elenril: sorry, was out for a little, so had to communicate using an iDevice [21:06:19] * elenril almost has a get_strz replacement done [21:07:58] <ruggles> wow, found a bug in reverse. looking at the code, i thought "this looks like mono mpc will crash on x86". and sure enough it does. [21:09:32] <ruggles> hmm. nevermind. [21:10:03] <ruggles> but it should ;) i'm probably just missing something. [21:13:15] <ruggles> oh, mpc uses fixed-point not floating-point. that explains it. oops. [21:14:35] <CIA-15> ffmpeg: Reinhard Tartler <siretart(a)tauware.de> release/0.5 * r2c4d6aeabc ffmpeg/VERSION: Bump version number for 0.5.4 release. [21:21:56] * elenril sleeps [21:34:36] <BBB> omg [21:34:51] <BBB> ppc/* has no code for clamped pixels (short->byte) [21:39:57] <BBB> mru: ping [21:40:01] <BBB> (or anyone knowing ppc asm) [21:42:29] <Sean_McG> I'd like to learn ppc asm... I bought a used G4 Mini yesterday but haven't set it up yet [21:43:30] <mru> pong [21:48:53] <siretart> my prof loves ppc asm for some reason… [21:49:56] <ohsix> xbux [21:50:12] <Sean_McG> ps3 has a POWER core too ;) [21:50:19] <mru> BBB: you had a question? [21:50:23] <mru> Sean_McG: not really [21:50:43] <mru> ps3 has a stripped-down hyperthreaded ppc core [21:51:02] <BBB> mru: can you look at vc1dsp_altivec.c and tell me for the result of inv_trans_8x8_altivec, how do I add or subtract a value from the resulting coeffs or left-shift it by one? [21:51:04] <mru> and 7 vector coprocessors [21:51:11] <Sean_McG> it's a slightly anemic G3, plus those SPU processors elements, if I recall correctly [21:51:16] <mru> no [21:51:17] <BBB> mru: as in, if I send you a 3/4 finished patch, can you fix make fate on altivec? [21:51:25] <mru> it's a very anemic 970 [21:51:31] <Sean_McG> oh...G5 [21:51:35] <Sean_McG> my bad [21:51:38] <mru> it's machine code compatible with 970 [21:51:59] <mru> but has very few execution units [21:52:00] <BBB> mru: also, altivec has no put/add_{,signed_}pixels_clamped(), which is kinda shameful [21:52:08] <BBB> mru: someone (you) should implement that [21:52:18] <mru> doesn't even have a barrel shifter iirc [21:52:22] <Sean_McG> could the clamping be done with a permute? [21:52:32] <BBB> ?? [21:52:36] <mru> altivec has saturating arithmetic [21:52:52] <BBB> I meant grep clamp ppc/*.c comes up empty [21:53:01] <BBB> I'm sure it has instructions for it [21:53:03] <BBB> of course it does [21:53:06] <mru> BBB: I understand what you mean [21:53:06] <Sean_McG> ah [21:53:13] <Sean_McG> sorry, forget I said anything [21:53:18] <mru> BBB: I'm just not highly motivated to work on it [21:53:23] <BBB> mru: can I send you a patch and you fix it up for me? [21:53:25] <BBB> oh [21:53:30] <BBB> who else does ppc here? [21:53:33] <BBB> Yuvi: ping! :-p [21:53:42] <mru> I can review patches [21:53:48] <Sean_McG> mister Conrad did the stuff for vp8 [21:53:54] <BBB> conrad is yuvi [21:53:57] <Sean_McG> ah [21:54:25] <mru> I finished up the fft once upon a time [21:54:28] <mru> that was an adventure [21:54:46] <siretart> oh. qemu uses launchpad as upstream bugtracker?! interesting.. http://wiki.qemu.org/Contribute/ReportABug [21:55:00] <mru> ppc abis are not to be taken lightly [21:56:09] <kierank> BBB: there's also LordRPI in #x264dev [21:56:26] <mru> BBB: why the interest in ppc? [21:57:26] <BBB> mru: ppc has existing vc1 optimizations [21:57:31] <BBB> I will break them in my next patch [21:57:39] <mru> I see [21:57:42] <BBB> trying to see if I can unbreak them [21:58:04] <mru> do you have an altivec manual? [21:58:09] <BBB> no [21:58:11] <mru> it's somewhere on ibm's website [21:58:20] <Sean_McG> sec, I have URLs for those [21:58:22] <BBB> I hope someone will do it for me if I tell them what I want the code to do :-p [21:58:27] <BBB> maybe lu_zero [21:58:33] <BBB> lu_zero: do you know ppc / altivec? [21:59:32] <Sean_McG> http://www.mactech.com/articles/mactech/Vol.15/15.07/AltiVecRevealed/ <-- scroll to the bottom [22:00:08] <Sean_McG> errr hrm wait no... those link to sps.mot, which are probably dead links [22:01:28] <BBB> mru: or alternatively I just break 'em [22:01:47] <Sean_McG> here we go: http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf [22:01:53] <BBB> mru: I can "just" implement the "add" idct8x8, and leave the 8x8_put ones unoptimized [22:01:56] <BBB> that way the code is there [22:02:01] <BBB> and it's easy to fix for whoever wants to [22:02:11] <BBB> mru: but it'll be a significant slowdown on altivec [22:05:00] <mru> BBB: https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/FBFA164F824370F98… [22:06:25] <Flameeyes> BBB: lu_zero definitely knows altivec — the quesiton is whether lu_zero is awake [22:06:35] <BBB> Flameeyes: can you awaken him? [22:07:06] <Flameeyes> BBB: I hope he is since he should review stuff from me for work [22:09:38] <mru> Sean_McG: about that 0 on qnx, it's a bug the expr : operator [22:10:51] <lu_zero> yawn [22:11:51] <lu_zero> BBB: what to do? [22:11:54] <Flameeyes> BBB: see? I did it :D [22:12:27] <lu_zero> (ps using jabber would have the same effect..) [22:12:35] <BBB> \o/ [22:12:47] <BBB> lu_zero: can you fix up a function in vc1dsp.c for me now that I'm about to break it? [22:13:04] <BBB> lu_zero: I can sort of tell you what to fix and set up the functions, and you then fill in the blanks [22:13:07] <BBB> lu_zero: is that ok? [22:13:14] <lu_zero> ok [22:13:36] <mru> great, I don't like altivec loads and stores [22:21:01] <lu_zero> mru: too inflexible? [22:21:03] <lu_zero> =) [22:21:18] <lu_zero> (neon load+shuffle is neat) [22:22:23] <Sean_McG> ooh cheers for the IBM link [22:22:50] <mru> lu_zero: I'd be fine with plain unaligned load/store [22:23:19] <Sean_McG> seems like a lot of the RISC platforms don't have that, or do with a significant performance penalty [22:23:40] <mru> arm takes a 1-cycle penalty [22:25:36] <lu_zero> arm from time to time seems too wonderful [22:25:46] <lu_zero> ppc is _way_ simpler though [22:25:50] <lu_zero> (and mips even more) [22:28:13] <BBB> lu_zero: do you want me to pastbein it [22:28:14] <BBB> ? [22:28:21] <BBB> (sorry, baby cried) [22:28:33] <lu_zero> BBB: yes please =) [22:28:39] <Sean_McG> AltiVec code makes babies cry? that's not good. [22:29:19] <BBB> lu_zero: http://ffmpeg.pastebin.com/B3952rsB [22:29:31] <BBB> line 42 and 55 are the blanks for you [22:29:40] <BBB> feel free to change anything you want on top of this patch to achieve it [22:30:00] <BBB> lu_zero: also, implementin altivec ff_add,put,put_signed_pixels_clamped would help a lot [22:31:00] <lu_zero> thinking about it [22:31:01] <lu_zero> so [22:31:12] <lu_zero> sub 64 and shift by 1 ? [22:31:38] <lu_zero> uhmm [22:31:53] * lu_zero wonders if he should be lazy and let gcc do the work... [22:31:55] * Sean_McG looks out of idle curiosity [22:32:16] <lu_zero> in altivec consts are made out of splats and shifts [22:32:42] <lu_zero> (till 4 ops per const is better than load from memory and splat) [22:32:56] <lu_zero> gcc does that for you nowadays [22:33:00] <lu_zero> </lesson> [22:36:10] <lu_zero> (in case you were wondering why const vector signed int vec_64 = vec_sl(vec_splat_s32(4), vec_splat_u32(4));) [22:36:55] <Sean_McG> yeah it's cool that the intrinsics are already functions [22:37:29] <lu_zero> altivec intrinsics are something leave you with mixed feelings [22:37:49] <lu_zero> they are nicer to write but then if your compiler has bugs... [22:38:02] * lu_zero still recalls gcc-3.3 [22:38:11] <Sean_McG> seems to be quite a few people at IBM helping with gcc now [22:38:21] <Sean_McG> (probably because of POWER7) [22:38:32] <Sean_McG> wonder if Watson was compiled with gcc ;) [22:38:38] <lu_zero> it's sad they gave up the consumer market [22:38:44] <Sean_McG> that's Apple's fault. [22:39:06] <Sean_McG> and partially Motorola for not giving a shit [22:39:12] <lu_zero> Sean_McG: it's shared with IBM/Freescale [22:39:37] <lu_zero> inside freescale there were a number of people actively AGAINST going into that market [22:39:54] <Sean_McG> see I didn't know that [22:39:58] * lu_zero still recall a meeting/show in Frankfurt [22:40:15] <Sean_McG> was the Freescale thing after Mot left the PPC alliance? [22:40:30] <lu_zero> basically we got insulted because we were supporting g4 on desktop and showing up how good it was [22:40:42] * BBB awaits lu_zero's results [22:40:46] <lu_zero> (well we got also praised by the other faction [22:40:47] <lu_zero> ) [22:40:49] <lu_zero> uhm [22:41:00] <lu_zero> mind if I do something more invasive? [22:41:07] <lu_zero> I'm feeling lazy [22:41:27] <Sean_McG> invasive and lazy usually don't go well together ;) [22:41:39] <lu_zero> Sean_McG: if you are curious [22:41:41] <lu_zero> static void vc1_inv_trans_8x8_altivec(DCTELEM block[64]) [22:41:52] <Sean_McG> very curious [22:42:03] <lu_zero> around line 216 [22:44:22] <Sean_McG> 8 separate stores even though the addresses are contiguous [22:44:47] <lu_zero> ehm [22:44:56] <lu_zero> count the elements [22:45:36] <lu_zero> 16*8byte to move [22:45:39] <Sean_McG> a DCTELEM is a short, yes? [22:47:43] <Sean_McG> I'm sorry, if I'm talking nonsense don't hesitate to let me know [22:48:16] <lu_zero> altivec has a register of 16byte [22:49:20] <Sean_McG> ahhhh... yes of course [22:49:23] <lu_zero> unsigned has -64 just in a single case? [23:00:44] <BBB> lu_zero: go for it, you can do anything [23:01:12] <Sean_McG> I guess I need to start with the basics... I'll read a bit of this IBM PDF [23:03:56] <mru> arm neon is fantastic [23:04:18] * BBB pets mru [23:04:30] <mru> then again, they had the mistakes of sse and altivec to learn from [23:04:43] <Sean_McG> other than the ones attached to my shoulders, I don't have an arm ;) [23:04:45] <BBB> so interestingly, MS guarantees not 16bit, but 17bit results [23:04:48] <Sean_McG> anyways, dinnertime [23:04:50] <BBB> mru: so how did you do that? [23:05:13] <BBB> because the result is 10 bit, from a 7 shift right source, so the result of all math is 17bits [23:05:17] <BBB> how to fit that in 16? [23:05:17] <mru> BBB: in the idct? [23:05:20] <BBB> yeah [23:05:57] <DonDiego> siretart: still online? [23:08:15] <mru> BBB: I told you neon is good :) [23:09:12] <mru> BBB: I don't remember how I did it, maybe some halving add trick [23:09:24] <mru> that instruction can be a lifesaver [23:10:02] <lu_zero> BBB: something like http://ffmpeg.pastebin.com/9CV4ejwY [23:10:29] <lu_zero> so you call the function with constants and gcc should do the rest [23:14:37] <mru> what does "rangered" mean? [23:17:02] <lu_zero> mru: picked up from ronald patch [23:17:14] <mru> BBB: ^^ [23:19:36] <DonDiego> siretart: anyway, i have a few minor nits for the release docs [23:19:50] <DonDiego> will fix tomorrow [23:24:40] <lu_zero> BBB: I'm heading to bed tell me in 8-9 hours [23:27:49] <mru> ah, it's range reduction [23:29:56] <DonDiego> gnite [23:30:51] <BBB> mru: like averaging? yeah [23:30:54] <BBB> lu_zero: ok [23:31:02] <BBB> mru: range reduction frame, yes [23:31:16] <mru> BBB: neon has an instruction that does (a+b)>>1 [23:31:42] <mru> so yes, average [23:31:58] <mru> it also has (a-b)>>1 [23:32:03] <Dark_Shikari> and (a+b+1)>>1 [23:32:13] <mru> and (a-b+1)>>1 [23:32:28] <mru> I can't remember ever using the halving sub ones [23:33:13] <mru> oh, I have [23:33:16] <mru> in one place [23:33:28] <Dark_Shikari> Might they be useful in an h264 idct? [23:33:56] <mru> h264 weighted pred [23:34:16] <mru> h264 idct doesn't overflow even without trickery [23:34:22] <Dark_Shikari> h264 idct does (A>>1)-B and A+(B>>1) [23:34:46] <mru> which isn't the same thing [23:34:53] <Dark_Shikari> I wonder if it could be abused for that, hmmph [23:35:04] <Dark_Shikari> I guess the loss of precision means no. [23:35:08] <mru> I couldn't think of any tricks for that [23:35:23] <mru> doesn't mean there aren't any of course [23:35:49] <mru> the weighted prediction is evil [23:36:10] <mru> the obvious way needs 17 bits

1 0

IRC log for 2011-02-19
by irc＠mansr.com 20 Feb '11

20 Feb '11

[00:00:15] <BBB> Yuvi: I thought of that, but like I said, it's not always +128, it's also -128 (and no it's not going from signed->unsigned is always +128 and unsigned->signed is always -128, it's a little weirder than that [00:00:26] <BBB> should I just provide a "bias" argument to the put_idct8x8 function? [00:00:32] <BBB> that's kinda lame [00:01:09] <BBB> also one of them does <<= 1 [00:01:39] <BBB> I'm currently considering having an idct_put_8x8[2], where [0] is the default one and [1] does the <<= 1, such as not to slow it down too much [00:01:44] <BBB> vc1 is really weird [00:02:02] <Dark_Shikari> Is the <<1 the range extension thing? [00:02:25] <BBB> yes [00:06:36] <BBB> or well VC1Context calls it range reduction [00:14:10] <iive> BBB: one more thing, while we are in idct wave. is your mmx implementation working on words only? the C version uses int. [00:14:47] <iive> the posibility of overflow with the "naive" version was the reason we didn't got mmx 3 years ago. [00:16:40] <BBB> yes it's words only [00:16:48] <BBB> the spec says you can do it in words [00:16:52] <BBB> I don't know if the spec is right [00:17:02] <BBB> make fate-vc1 is not affected [00:17:13] <BBB> I'm hoping to get a bigger vc1 testsuite to test some more [00:17:26] <BBB> I could try to mathematically show it but ohwell [00:18:29] <iive> well... it says it is possible, it doesn't say _how_ :E [00:18:59] <iive> aka, if binary version is also straight forward... then no-problem. [00:21:37] <astrange> use dct-test [00:23:27] <BBB> will look [00:23:29] * BBB brb [00:36:30] <j0sh> http://news.ycombinator.com/item?id=2237898 [02:23:39] <mru> Dark_Shikari: ping [02:23:56] <Dark_Shikari> pong [02:24:01] <mru> you broke vp3 [02:24:05] <Dark_Shikari> what [02:24:07] <Dark_Shikari> I tested it [02:24:12] <mru> http://fate.ffmpeg.org/ [02:24:33] <mru> fate does not lie [02:24:50] <dalias> :) [02:25:48] <Dark_Shikari> passes here [02:26:00] <mru> seems 64-bit only [02:26:11] <mru> and qnx [02:26:24] <mru> and mingw [02:26:37] <Dark_Shikari> could it relate to linesizes and signedness? [02:26:55] <mru> no idea [02:27:03] <mru> but I suggest you find out [02:27:13] <Dark_Shikari> I don't know enough about VP3... [02:27:26] <mru> it's a segv, how hard can it be? [02:27:39] <mru> valgrind it or something [02:27:39] <Dark_Shikari> oh. a segfault. [02:28:01] <Dark_Shikari> I don't have any such boxes to test on though [02:28:22] <mru> no 64-bit or mingw? [02:28:27] <mru> I find that hard to believe [02:28:34] <Dark_Shikari> oh, let me try mno-cygwin [02:28:56] <mru> it crashes on cygwin too actually [02:29:12] <Dark_Shikari> Works here [02:29:15] <Dark_Shikari> I'm on cygwin [02:29:26] <mru> kostylev's cygwin fails [02:34:53] <mru> valgrind has a lot to say [02:35:23] <Dark_Shikari> what is s->current_frame.linesize[0] when edge_emu_buffer is allocated? [02:35:44] <mru> it's complaining about edge_emu_buffer [02:39:51] <mru> allocating a bit more makes it work [02:40:08] <Dark_Shikari> o.0 [02:40:15] <Dark_Shikari> Was it only working before because too much was allocated? [02:40:39] <Dark_Shikari> That seems unlikely? It only needs 9 rows... [02:41:14] <mru> another 16 bytes makes it work [02:41:21] <Dark_Shikari> o.0 0.o o.0 0.o [02:41:36] <Dark_Shikari> do I blame BBB's asm? [02:41:43] <mru> no [02:41:49] <mru> it fails on alpha and ia64 too [02:42:21] <mru> 9 extra bytes is enough [02:42:46] <mru> related to the 9 rows? [02:42:49] <Dark_Shikari> I don't understand why it needs extra bytes... [02:49:21] <mru> maybe you should figure it out then... [02:49:29] <mru> I don't know that code any better than you do [02:49:56] <Dark_Shikari> uint8_t *temp= s->edge_emu_buffer; [02:49:56] <Dark_Shikari> if(stride<0) temp -= 9*stride; [02:49:57] <Dark_Shikari> else temp += 9*stride; [02:50:01] <Dark_Shikari> what is going on here? [02:50:26] <mru> looks like you found your overflow [02:51:03] <Dark_Shikari> But that would have broken before too. [02:51:22] <Dark_Shikari> I don't understand how emulated edge mc works... [02:51:27] <Dark_Shikari> i.e. why we have to do += 9*stride [03:11:15] <Dark_Shikari> Yeah, I'm lost here, sorry. [03:11:23] <Dark_Shikari> I don't know how to fix it, and the original code clearly worked by coincidence. [03:12:54] <kierank> the troll hunter was really good [03:17:12] <Yuvi> Dark_Shikari: probably you really only have to do that for negative stride (which theora basically always has since it's flipped) [03:18:05] <Dark_Shikari> I tried only doing it for negative strides, it broke fate [04:06:25] <Jumpyshoes> http://ffmpeg.pastebin.com/jR7Dh9aR both are on cygwin, does anyone know why one uses window's tmp dir while the other tries to use linux style tmp dir? [04:18:58] <drv> maybe something sets TEMPDIR or TMP in between? [04:20:32] <Jumpyshoes> should be the same config though, i think [04:46:45] <kierank> http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread… [04:46:49] <kierank> mike <3 [05:30:02] <Sean_McG> dinky little 200MHz SH-4, woopty do [05:35:01] <pross-au> Sean_McG: the were a great console. i still have mine! [05:35:31] <Sean_McG> I had one too, sold it about a year ago when I was cleaning up [05:55:26] <Sean_McG> bootstrapping gcc trunk on one of my VMs, and building libgpac on my SPARC... both of these will take time so I'mma go get some sleep [06:25:06] <Dark_Shikari> so, uh, yeah, anyone feel like figuring out why vp3 is broke? [06:25:12] <Dark_Shikari> anyone who understands emulated edge mc at least? [06:25:26] <Dark_Shikari> and why temp += 9*stride is required to make it work if stride > 0? [07:14:41] <Yuvi> Dark_Shikari: do you mean stride > 0 for the buffers from get_buffer or stride > 0 as in non-flipped vp3? [07:16:57] <Dark_Shikari> I mean in the emu_edge [07:17:03] <Dark_Shikari> what's with the += 9*stride? [07:35:02] <lu_zero> 9 rings a bell [07:35:06] <lu_zero> well [07:35:21] <lu_zero> any multiple of 3 rings a bell in vp3 [07:35:38] <lu_zero> but I just woke up and never touched that code =_= [07:39:08] <dalias> hi [07:39:10] <thresh> good morning [07:41:08] <lu_zero> good morning [07:43:45] * kshishkov does not believe thresh [07:46:18] <thresh> kshishkov: yup, I don't believe myself either [07:47:36] <kshishkov> probbly next thing would be ALT Linux rebasing on MeeGo [07:47:52] <thresh> they actually think about autoimporting Fedora packages [07:48:00] <thresh> not that I care much, I left the project [07:52:41] <_av500_> and joined CTRL Linux? [07:53:35] <lu_zero> good morning =) [07:53:52] <lu_zero> feels another day already =P [07:54:09] <pJok> ohayou gozaimasu [08:18:34] <Yuvi> Dark_Shikari: get rid of the else, change -= 9 to -= 8 [08:20:09] <Dark_Shikari> if it works, want to just commit it? since its your fix [08:25:26] <Dark_Shikari> it works here, but I don't know if it fixes the crash [08:39:03] <Yuvi> http://pastebin.com/VUT7grDs [08:39:04] <Yuvi> good thing huffman_table is so big or that would have been potentially exploitable for all released ffmpeg [08:40:31] <spaam> good thing that you removed that pastebin.. [08:42:37] <Dark_Shikari> Yuvi: just commit it? [08:42:49] <Dark_Shikari> or send a mail and I'll approve it [08:42:53] <Dark_Shikari> oh wait, do you have commit access? [08:43:17] <Dark_Shikari> Wait, you're saying that it was broken before too? [08:43:21] <Dark_Shikari> And it just happened to run into the huff table? [08:43:50] <lu_zero> Dark_Shikari: what? [08:43:54] <lu_zero> calm =) [08:44:15] <Dark_Shikari> ? [08:45:13] <lu_zero> what's up? [08:45:44] * lu_zero doesn't have access to the pastebin [08:54:25] <Yuvi> geh, what happened to that paste [08:54:28] <Yuvi> http://pastebin.com/7Cp1d83m [08:54:34] <Yuvi> don't have commit access I'm pretty sure [08:56:41] <Dark_Shikari> send it to the ml and I'll commit it [09:00:10] <CIA-15> ffmpeg: Young Han Lee <cpumaker(a)gmail.com> master * r9707f84fa7 ffmpeg/libavcodec/aacdec.c: aacdec: dsputilize the scalar multiplication in intensity stereo [09:00:35] <lu_zero> hi j0sh [09:02:00] * _av500_ proposes to make lavc and lavf only use RTS [09:04:04] <j0sh> lu_zero: yo [09:06:30] <j0sh> lu_zero: you won't like what i'm trying right now. replacing blocking read() with coroutines in librtmp [09:09:54] <lu_zero> j0sh: why dislike? [09:10:02] <lu_zero> if it works why not? [09:10:26] <lu_zero> (I don't dislike the idea, last time I was looking for a quick fix ^^) [09:10:46] <j0sh> heh... if it works, i will let you know in a few :) [09:12:15] <kurosu> I'm having problem cloning: [09:12:18] <kurosu> $ git clone http://git.ffmpeg.org/?p=ffmpeg.git ffmpeg [09:12:18] <kurosu> Cloning into ffmpeg... [09:12:32] <kurosu> fatal: http://git.ffmpeg.org/?p=ffmpeg.git/info/refs not found: did you run git update-server-info on the server? [09:12:37] <lu_zero> kurosu: wrong url =) [09:12:50] <kurosu> urg [09:12:51] <kurosu> right [09:12:57] <lu_zero> git://git.ffmpeg.org/ffmpeg.git [09:12:57] <lu_zero> http://git.ffmpeg.org/ffmpeg.git [09:13:06] <kurosu> yeah, just notice the "clone url" [09:14:30] <kurosu> i was not getting why it wanted to clone into "?p=ffmpeg" [09:16:21] <Dark_Shikari> Yuvi: you going to post it? [09:43:26] <CIA-15> ffmpeg: David Conrad <davedc(a)kozue.local> master * ra89f4ca005 ffmpeg/libavcodec/vp3.c: [09:43:27] <CIA-15> ffmpeg: Fix VP3 edge emulation [09:43:27] <CIA-15> ffmpeg: With negative stride, the start of the edge_emu buffer should be pointing to [09:43:27] <CIA-15> ffmpeg: the last line, not the end of the buffer. [09:43:27] <CIA-15> ffmpeg: With positive stride, pointing to the end of the buffer was completely wrong. [09:51:33] <astrange> 04:10 <@lu_zero> if it works why not? <- generation of dts from pts is easy if you have pts for every frame [09:51:37] <astrange> sort it and you're done [09:51:54] <astrange> but i don't know 1. what to do about sparse files 2. what to do about the last few frames in a file [09:52:09] <lu_zero> astrange: I was referring to libtask =) [09:52:23] <astrange> and you need generation of pts from dts to make mkvs [09:52:38] <astrange> either way, it's educational [09:52:56] * lu_zero is missing something... [10:49:40] <mru> moroning [10:50:05] <kshishkov> hello, dalatrollkarl [10:55:56] <Flameeyes> lu_zero: aren't you supposed to .. not be home? [10:56:29] <lu_zero> Flameeyes: I woke up exactly at 8 feeling really bad [10:56:55] <Flameeyes> lu_zero: oh well, good news for me then, as I can get your help :P [10:58:12] <lu_zero> sure [11:20:26] <elenril> nice bikeshed about scalar products [11:37:30] <ubitux> anyone knows a but about ctts (atom)? [11:37:33] <ubitux> bit* [11:37:38] <mru> dts [11:37:49] <mru> sorry, pts [11:37:54] <mru> composition time [11:37:57] <mru> in mp4-speak [11:38:53] <ubitux> i have a sample here with a big negative value, but it seems the workaround baptiste made is not enough/wrong [11:39:17] <ubitux> in lavf/mov.c:mov_read_ctts [11:40:10] <ubitux> the end of the samples look like this: http://pastie.org/1581970 [11:40:21] <mru> ctts defines the difference between dts and pts for each frame [11:40:35] <mru> each entry in the table is non-negative by definition [11:42:05] <mru> the dts is defined by the stts box, which lists positive deltas from the initial value provided by an edit list, if any [11:43:13] <ubitux> why is there a negative value here? [11:43:27] <ubitux> is the count invalid? is it a special case? [11:44:29] <ubitux> ignoring the duration < 0 seems enough to fix the issue, but there is certainly something smarter to do [11:45:29] <mru> what value is negative? [11:45:39] <ubitux> the duration, look at the pastie [11:45:40] <mru> the edit list duration is unsigned too [11:46:13] <mru> where does that duration value come from? [11:46:28] <ubitux> so the MOVStts struct is wrong? [11:46:38] <ubitux> http://roundup.ffmpeg.org/issue2246 ← this is the issue [11:47:09] <ubitux> the print is put in this loop: for(i=0; i<entries; i++) from mov_read_ctts (lavf/mov.c) [11:48:01] <mru> those should be unsigned [11:48:08] <mru> that's what the spec says [11:48:09] <ubitux> int duration should be uint32_t then? [11:48:16] <ubitux> (in the MOVStts struct) [11:48:34] <mru> if that's supposed to correspond to entries in the stts box, yes [11:48:52] <astrange> if the value in the file is large enough to wraparound to negative it's probably muxed wrong [11:48:57] <ubitux> the value looks pretty big btw [11:49:01] <astrange> but the torrent isn't seeded [11:49:13] <ubitux> i have another torrent [11:49:20] <ubitux> want it? [11:50:12] <ubitux> astrange: that what i thought too, compared to the other values [11:50:13] <mru> ubitux: what produced the content of your pastie? [11:50:27] <ubitux> mru: as i said: <+ubitux> the print is put in this loop: for(i=0; i<entries; i++) from mov_read_ctts (lavf/mov.c) [11:50:34] <ubitux> "COUNT=%d | DURATION= %10d (%10u) | dts_shift=%d\n", count, duration, duration, sc->dts_shift [11:50:45] <ubitux> after count and duration are read [11:50:47] <mru> there's nothing of the kind in my copy of ffmpeg [11:51:01] <ubitux> i added it :p [11:51:16] <mru> there's a different similar-looking debug line there though [11:53:23] <mru> the value is absurdly large of course [11:53:46] <mru> and what's with the 0-duration samples? [11:53:53] <ubitux> since it's the last one i thought the count is wrong [11:53:57] <ubitux> dunno [11:54:40] <ubitux> it's like that since almost the first samples [11:54:41] <mru> that's also invalid [11:54:57] <mru> you can't have multiple frames with the same dts [11:55:12] <mru> the spec is quite clear: The sample entries are ordered by decoding time stamps; therefore the deltas are all non-negative. [11:55:40] <mru> wait a minute, you said ctts [11:55:48] <mru> those can be zero of course [11:58:36] <ubitux> http://paste.pocoo.org/show/341254/ ← here is the full sample table [11:59:16] <siretart> lu_zero: regarding reimars patch, if you say it is okay, I'll push it, the thing is that it doesn't seem to make any difference on the sample in the bug: http://pbot.rmdir.de/ce71375b1d4aad1f827522f9c458f2ea [12:00:27] <siretart> lu_zero: and https://roundup.ffmpeg.org/issue2584 (AKA CVE-2011-0723) seems to remain unfixed [12:01:36] <siretart> oh, wait, I think I screwed up [12:01:41] <siretart> redoing the diff [12:03:37] <ubitux> btw mru, the video plays fine when the ctts are ignored, so what are there for? is it not noticable because of various workaround? [12:03:48] <mru> ctts are pts [12:03:50] <ubitux> (not only the last one, but all of them) [12:04:45] <mru> or rather, stts defines pts, ctts defines pts-dts [12:06:09] <siretart> lu_zero: yes, I did screw up. the diff clearly shows fixed overreads: http://pbot.rmdir.de/e5dedc8f07194683d6828fdc863ddd1a [12:06:37] <siretart> do you guys think that this (arguably very long) diff of valgrind outputs is worth to copy in the commit message? [12:09:31] <astrange> doesn't load [12:09:43] <lu_zero> siretart: put it on the bug on roundup [12:09:52] <lu_zero> hopefully roundup could stay stable [12:10:40] <uau> ubitux: i looked at that issue2246 briefly before [12:11:09] <uau> it's caused by insufficient handling of the dts_shift field in the lavf mov demuxer [12:11:20] <astrange> i think -/+ on the error summary at the end is enough [12:11:45] <mru> uau: please explain [12:11:51] <mru> uau: those values are _unsigned_ [12:11:56] <mru> according to spec [12:12:04] <mru> they cannot be negative, so the code makes no sense at all [12:12:57] <twnqx> which bok was the dvd video? orange book? [12:12:58] <uau> mru: i don't remember exactly what the values were (though i think they actually were calculated to be negative, whether conforming to the spec or not) [12:13:00] <twnqx> book* [12:13:12] <uau> but the actual problem was that other code didn't take the dts_shift amount into account [12:13:21] <mru> uau: I'm looking at the code now [12:13:31] <mru> the "negative" value is pulled directly from the file [12:13:39] <twnqx> oh, no books for dvd, they were cd only, my bad. [12:13:56] <uau> IIRC it was something like it calculated initial pts values, and then placed initial_pts+dts_shift into packet fields (where dts_shift was a *large* value) [12:14:05] <uau> the resulting value the demuxer placed in packets was correct [12:14:28] <mru> uau: why don't you look at the code if you want to discuss it? [12:14:53] <uau> but other code used the unadjusted values; in particular code to interleave audio and video packets used the unadjusted values [12:15:16] <uau> which resulted in all video packets being placed before audio or vice versa [12:16:46] <mru> what's the dts_shift all about anyway? [12:17:00] <mru> mp4 doesn't allow discontinuous timestamps [12:17:08] <mru> edit list trickery aside [12:17:50] <uau> i haven't checked any specs - the impression i got from checking the problem case was that there was a large offset in the coded pts values for video and audio in some files [12:18:23] <uau> like one track going approximately from -2000 to 0, another from 0 to 2000 [12:18:37] <mru> you can't have negative values in mp4 [12:19:25] <astrange> you can have negative pts after applying the edit list [12:19:49] <mru> how? [12:20:00] <astrange> variables reading values directly from the file won't be negative though [12:20:22] <mru> but the code wrongly uses signed types... [12:20:52] <uau> anyway the main problem seemed to be that various code didn't use the dts_shift value (it was only used to calculate the final pts placed in output packet, when comparisons etc elsewhere should also have taken it in account) [12:21:14] <mru> I'd like to see the contents of stts and ctts boxes in that file [12:21:33] <mru> and elst [12:21:51] <ubitux> want the beginning of the file/torrent? [12:22:19] <ubitux> (notice for the torrent) [12:22:26] <mru> whatever part of the file contains the headers [12:23:01] <ubitux> (it's ep 178) [12:25:52] <mru> is that relevant? [12:26:38] <CIA-15> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> master * r2bbec1eda4 ffmpeg/libavcodec/vc1dec.c: [12:26:38] <CIA-15> ffmpeg: Fix invalid reads in VC1 decoder [12:26:38] <CIA-15> ffmpeg: Patch discussed and taken from https://roundup.ffmpeg.org/issue2584 [12:26:55] <uau> the file i tested with is numbered 185v2, not sure if there are any differences [12:26:58] <astrange> run qt-faststart and upload the first 5mb [12:27:14] <astrange> or copy the first 5mb, see if that starts playing, upload if so [12:27:40] <astrange> there's a negative start time mov in incoming/negative_start_time.mov according to issue1086 [12:27:51] <siretart> lu_zero: done [12:28:00] <astrange> quicktime generates them as a way of letting you cut files at non-keyframes [12:28:01] <lu_zero> siretart: thank you [12:28:25] <uau> mru: want that 185 file? [12:28:43] <astrange> the audio starts at time 0 or so but video has the first frame after the cut at time 0, and the keyframe+earlier frames needed for decode included [12:28:52] <astrange> with the edit list shifting the track so they aren't displayed [12:29:13] <astrange> ffplay/etc display the hidden parts but may have started syncing audio to the right place at some point [12:29:29] <uau> has incoming been fixed to make files readable without excessive delay? i guess not? [12:29:33] <astrange> anyway i don't feel like looking in there to remember what the edts/elst look like [12:29:52] <astrange> it's sort-of a feature that should be implemented as playlists though [12:30:16] <mru> astrange: nothing in mp4 can ever produce a negative timestamp [12:30:48] <mru> if tracks start at different time, you must apply a positive offset the ones starting later [12:30:58] <BBB> elenril: not lazy, I said I'd do it [12:31:19] <uau> btw i recently added support for an external EDL file format to expose the timeline support i created for ordered chapters in mplayer2 [12:31:47] <uau> if the mov edit list information was exported that could probably also be used [12:32:09] <astrange> ah, quicktime file format says that elst "media time" can be negative, but not very well [12:32:26] <astrange> it says it's an integer and that -1 is a deletion [12:32:30] <mru> I'm reading iso 14496-12 [12:32:52] <astrange> yes, they aren't exactly the same format [12:33:01] <mru> there duration is unsigned [12:33:15] <mru> and media_time=-1 means an "empty edit" [12:33:17] <mru> aka gap [12:33:35] <mru> so an empty edit at the start of a track gives a positive offset [12:33:40] <mru> you can't encode a negative offset [12:34:04] <mru> the file linked from that issue has ftyp isom so the iso spec applies [12:38:39] <uau> hmm seems the negative time stamps are themselves produced as a result of the dts_shift value set [12:38:49] <uau> current_dts -= sc->dts_shift; [12:38:57] <mru> now we're talking [12:47:28] <uau> well i'm uploading the file to incoming as issue2246.mp4 if anyone is interested [12:47:45] <mru> is it not the torrent linked in the issue? [12:48:12] <uau> different file from the same series [12:48:37] <mru> which file has the values ubitux pasted? [12:48:40] <uau> probably you can get that from torrent too (though getting just the start of a file from torrent is harder) [12:48:46] <mru> I grabbed the torrent [12:48:47] <ubitux> mru: ep 178 [12:48:57] <ubitux> from the torrent i noticed you [12:49:02] <elenril> BBB: ofc you are lazy, all hackers are lazy =p [12:49:26] * elenril is the laziest of them all [12:51:02] <mru> I see the bad value [12:51:15] <mru> the second last ctts entry [12:51:45] <mru> the stts entries are all sane [12:53:42] <mru> there doesn't seem to be an edit list [12:54:16] <mru> looks like a simple case of fucked up file [12:54:19] <uau> so r20458 fixed one kind of problematic/invalid file and broke another? [13:00:07] <BBB> elenril: ok, I'll get on it then [13:00:16] <BBB> seems like vc1 is not gonna progress for a couple of hours [13:00:21] <BBB> then again, who uses vc1 anyway [13:00:33] <BBB> andoma: ping [13:00:33] <kshishkov> exactly [13:01:14] <andoma> BBB: yeah [13:03:04] <mru> taken literally, that file encodes the pts of the last frame as ~3h after the second-last one [13:03:15] <mru> which is absurd but valid [13:11:21] <uau> mru: the current code sets dts_shift because it sees a negative duration [13:11:30] <mru> which isn't possible by spec [13:11:32] <uau> so is something negative or is it overflow? [13:11:34] <mru> so wtf is it meant to do? [13:11:40] <mru> it's overflow [13:11:51] <mru> the values are 32-bit unsigned in the file [13:14:43] <uau> the duration interpreted as signed is -505555050 [13:14:49] <mru> that's a bug [13:14:55] <uau> which is almost exactly minus the length of the file [13:15:00] <mru> the file uses a time base of 1/360000 s [13:15:12] <mru> the last frame has an insane pts set [13:15:26] <mru> the file is syntactically valid [13:15:30] <mru> afaics [13:15:44] <uau> but insane in a way that looks like it's been set as signed [13:15:51] <mru> no [13:15:57] <mru> it's just a large unsigned value [13:15:57] <ubitux> isn't it possible to check duration > max_duration or such? [13:16:07] <mru> what duration? [13:16:12] <mru> that variable is badly named [13:16:14] <ubitux> of the whole file? [13:16:17] <mru> these fields are not durations [13:16:40] <ubitux> i read somewhere it was offset [13:16:50] <ubitux> a random forum post [13:16:55] <mru> the stts box codes dts for each frame as a delta from the previous one [13:17:03] <mru> ctts codes pts as offset from dts [13:17:14] <mru> I'm reading the spec [13:17:34] <uau> mru: -505555050 / 360000 = -1404, and file duration is 1404 seconds - doesn't look like random (even if it should be unsigned according to spec) [13:18:17] <uau> i guess the error is basically pts resetting back to 0 at the end [13:20:38] <mru> good catch [13:20:54] <mru> so it's a case of insane muxer [13:24:14] <lu_zero_> ^^; [13:29:40] <mru> wtf is that dts_shift meant to do? [13:30:54] <mru> does the file play if dts_shift is forced to zero? [13:31:06] <uau> what's the "cslg" atom? [13:31:15] <uau> that's what the first commit adding it referred to [13:31:24] <mru> not in the spec [13:31:30] <mru> probably a quicktime thing [13:36:30] <mru> nope, not in the quicktime spec either [13:39:09] <uau> google finds it at http://www.mp4ra.org/atoms.html [13:39:23] <uau> "Defined in/by: ISO" [13:43:38] <BBB> elenril: you didn't do put_flush_packet() in your avio_ prefix thing [13:44:46] <mru> uau: ah, it's in an amendment [13:44:48] * mru downloads [13:48:35] <elenril> BBB: it doesn't really belong with the other put_* functions [13:49:06] <elenril> and i think the name is prett confusing and should be changed [13:49:08] <BBB> why? it takes a ByteIOContext [13:49:15] <BBB> and it starts with put [13:49:22] <mru> so the amendment adds a new version of the ctts box with signed offsets [13:49:42] <mru> but the file we're looking at uses version 0 of that box [13:49:46] <mru> so it's still unsigned [13:50:19] <elenril> BBB: the other put_* also take a 'what to put' [13:51:12] <BBB> right, but you'd expect that [13:51:30] <BBB> after all, open(2) and close(2) don't take data, but write(2) and read(2) do [13:51:48] <BBB> and flush is called fflush() for the f*() API, or fdatasync (I believe) for this API [13:51:56] <BBB> I'd recommend changing it also [13:51:57] <BBB> it is public [13:51:59] <BBB> isn't it? [13:52:25] <elenril> yes, it should be renamed of course [13:52:29] <elenril> just not in this batch [13:53:10] <elenril> i'd rename it into something like avio_flush_buffer [13:53:42] <BBB> hm... ok I guess [13:56:55] <BBB> just don't forget it :) same for get_strz() did you already submit a patch for that? [13:57:07] <BBB> if we fix it, I'd like to fix it all, not sort of half-fix it lamely and then forget about it [13:57:28] <BBB> (i.e. I'm going through your patches now, ideally this is all committed at the same time, so that our API is fixed once-and-for-all[TM] :) [13:57:58] <BBB> mru: it was already misaligned [13:58:06] <BBB> mru: MANGLE(..) used to be a function argument [13:58:10] <BBB> back before that it was aligned [13:58:17] <BBB> it's misaligned now, and still is after this patch [13:58:22] <mru> do as you please [13:58:49] <BBB> ty [14:01:14] <elenril> BBB: i'll fix it all before the bump ;) [14:06:48] <mru> http://pastie.org/1582278 [14:06:59] <mru> that makes the file play sanely in ffplay [14:07:03] <BBB> elenril: going through the patch I'll take a while, it's massive [14:07:17] <BBB> elenril: I guess I'll have to do them one-by-one because it's way too massively big to all do at once [14:11:20] <elenril> use the sed luke? [14:11:26] * elenril did [14:12:26] <uau> mru: issue419 (which looks like it was the motivation to change the logic from using cslg to the current one) has a comment from bcoudurier saying "File is non standard compliant, negative ctts are not allowed in atom version 0 in mp4." [14:13:11] <uau> so i guess you could just as well revert r20458 (and break the file from issue419) [14:14:05] <mru> the dts offset needs to be calculated somehow [14:14:46] <mru> the cslg box is optional [14:15:24] <mru> why you'd ever code pts<dts still stumps me though [14:15:42] <uau> it was apparently changed from using cslg to the current calculation because of a file with version 0 and negative entries [14:16:21] <uau> so i'd expect your change to break at least the file the current heuristic was originally created for [14:16:37] <uau> do you think there are other files for which cslg wouldn't work but your code would? [14:16:54] <mru> any file with negative ctts offets and no cslg [14:22:51] <mru> the current code is plain wrong [14:23:13] <mru> it's trivial to construct a file where it does something ridiculous [14:23:32] <mru> just set a very small timebase [14:23:52] <mru> so it pushes normal offsets into "negative" range [14:44:03] <Sean_McG> wow, it failed bootstrap again...fun fun [14:45:40] <kshishkov> sun sun [15:23:23] <siretart> BBB: michael has a point. we should be very careful when making some API public. private APIs are (obviously) much easier to fix [15:23:52] <mru> he has a point, but the way he makes it nobody will want to listen [15:24:51] <kshishkov> mru: looks like you've worked for a long time with idiots, you should be a bit more tolerant [15:25:15] <mru> working with idiots makes a man cynical, not tolerant [15:25:25] <Sean_McG> mru++ [15:25:48] <mru> and I had cynical tendencies even before the idiots... [15:25:51] <mru> you do the maths [15:26:12] <siretart> :-) [15:29:20] <elenril> siretart: basically everything in avio is already de facto public [15:29:23] <elenril> and widely used [15:29:29] <michaelni> elenril, where? [15:29:47] * siretart suspects mplayer [15:29:56] <michaelni> siretart, good you find insults funny [15:30:12] <michaelni> about mplayer, it uses internal API [15:30:22] <elenril> mpd does too [15:30:25] <michaelni> that doesnt mean we should make it public, should we [15:30:34] <michaelni> what is mpd? [15:30:35] <siretart> michaelni: you misread me [15:30:35] <mru> are the functions useful? [15:30:41] <mru> if yes, why not make them public? [15:30:43] <elenril> music player daemon [15:30:45] <mru> or some variant at least [15:31:06] <elenril> michaelni: your trolling stopped being amusing long ago [15:31:25] <elenril> if you have specific suggestions about what should be kept private, i'll listen [15:31:29] <michaelni> iam not against making them public but that doesnt belong in a "cosmtic" patch [15:31:39] <elenril> but keep your insults to yourself [15:31:40] <michaelni> elenril, no, fuck the api up [15:32:33] <siretart> mru: I think /ignore would have been more appropriate at this point [15:32:41] <Dark_Shikari> what siretart said. [15:32:50] * Sean_McG sighs [15:32:54] <mru> /ignore doesn't solve the problem [15:33:12] <kshishkov> global /ignore called /ban does ;) [15:33:33] <mru> I thought I was being nice by only kicking and not banning [15:33:45] <uau> elenril: hmm how much of avio does mplayer use? [15:34:26] <uau> demux_lavf uses something [15:35:20] <elenril> and stream_ffmpeg [15:35:34] <uau> yes was just looking at stream_ffmpeg [15:35:40] <uau> that's probably the biggest user [15:35:50] <uau> it's a 150 line file total though [15:36:01] <uau> so not particularly hard to change if needed [15:37:04] <BBB> siretart: which api is non-public? [15:37:05] <uau> url_open, url_close, url_filesize, url_seek, av_url_read_seek, url_write, url_read_complete [15:37:18] <uau> BBB: at least those are in installed avio.h [15:37:28] <kurosu> I don't really see an insult in "fuck <something> up"; I don't know if that's the word, but isn't that "colloquial" language [15:37:34] <BBB> siretart: because my impression is that all of this is installed and used by mplayer [15:37:40] <mru> didn't Flameeyes have a list of fuctions used externally? [15:37:40] <BBB> siretart: which pretty much means public [15:38:04] <michaelni> i had no intent to insult anyone, i just wanted to point out that i wont/cant stop you from exportung randion functions [15:38:09] <uau> the above are used in stream_ffmpeg [15:38:12] <mru> kurosu: in general yes, in this particular case, no [15:38:19] <wbs> michaelni: i thought all url_*() functions were public already [15:38:40] <uau> i didn't read that as particularly insulting either [15:39:05] <kurosu> nevermind anyway, i was not making any case on one or another side [15:39:44] <elenril> if it's not public than what is it doing in an installed header [15:39:46] <BBB> michaelni: I agree, we should make stuff public if not necessary [15:40:02] <BBB> michaelni: unfortunately mplayer and other apps use a lot of this stuff already, and the avio.h header is installed [15:40:19] <BBB> url_*()/put_*()/get_*() is not under #if HAVE_AV_CONFIG_H or anything [15:40:26] <BBB> which pretty much implies it's public [15:40:27] <uau> see also r11086 [15:40:44] <uau> that added av_url_* functions which are pretty much useless without the existing url_ ones i think [15:41:17] <uau> looks like the idea was to use "right" names for the new functions, with the assumption that the existing functions already were public (even if not correctly named) [15:41:32] <BBB> so we're "stuck" with av_url_*() as prefix then? [15:41:34] <BBB> that sucks [15:41:37] <BBB> I prefer avurl_*() [15:41:46] <BBB> or anything shorter [15:42:10] <Sean_McG> doesn't it make it easier for the prefix to have an _ ? [15:42:19] <elenril> since we're renaming everything else already, renaming the few av_url to avurl_ isn't a big deal [15:42:20] <michaelni> i greped in mplayer get_be and get_le but i dont think the matches are using the functions from ffmoeg [15:42:26] <Sean_McG> in terms of regexs and all that? [15:43:35] <Sean_McG> if you really wanted to make stuff private, you could deprecate it for a version or two [15:44:03] <BBB> Flameeyes: ping [15:44:09] <BBB> let's see what flameeyes' list has to say [15:44:19] <BBB> he had actual, real data on this stuff [15:44:28] <BBB> i.e. he knows which apps use which symbols [15:44:34] <uau> get_be/get_le are not used in mplayer [15:44:35] <Sean_McG> *nod* [15:45:18] <michaelni> libavformat / codec is optional in mplayer if iam not mistaken so it shouldnt use it outside the wrapers and tiny bits of code depending on libav* [15:45:47] <uau> michaelni: avio.h is only included in stream_ffmpeg and demux_lavf [15:46:14] <michaelni> avio.h says at the top that its not allowed to include it directly :) [15:47:07] <uau> well it's included by avformat.h [15:47:15] <siretart> BBB: right. well, we can cleanup the names with the 'big bump' [15:47:56] <mru> whatever that comment says, the things defined in that header are de facto public [15:48:25] <uau> that comment was added in r17626 [15:48:35] <michaelni> public things have av* prefix if they dont they are not clearly public [15:48:46] <uau> with commit message "This should prevent its direct inclusion in an external project, which results broken if avformat.h is not included before." [15:49:01] <mru> that's not true anymore [15:49:31] <uau> that sounds like it not really being internal, but rather just that it's supposed to be accessed by including avformat.h (which includes it) [15:49:34] <mru> we've fixed all (?) implicit header dependencies [15:52:01] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * rbf6fa73245 ffmpeg/libavcodec/x86/dsputil_mmx.c: [15:52:01] <CIA-15> ffmpeg: dsputil_mmx.c: remove ff_vector128. [15:52:01] <CIA-15> ffmpeg: Remove ff_vector128, it is identical to ff_pb_80. [16:38:25] <Flameeyes> BBB: I need to re-generate the data, I'm afraid, but you should have my mails with it [16:40:29] <BBB> can't find the symbol names, just the project names :( [16:42:22] <Flameeyes> uhm, okay anyway I'll re-gen the list [16:43:15] <BBB> thanks [16:47:34] <Flameeyes> launched; with jruby it shouldn't take much time [17:10:21] <Flameeyes> two bugfix later, it's still running [17:15:04] <lu_zero> ^^; [17:15:07] <lu_zero> meanwhile [17:15:30] <lu_zero> libxml2 python bindings are a bitch to cross compile =_= [17:18:33] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> release/0.5 * rf7494394ee ffmpeg/libavcodec/ (bitstream.h dv.c): [17:18:34] <CIA-15> ffmpeg: Make get_bits_left() available for use in libavcodec (was previously held [17:18:34] <CIA-15> ffmpeg: private in dv.c for some reason). See "[PATCH] get_bits_left()" thread. [17:18:34] <CIA-15> ffmpeg: Originally committed as revision 20490 to svn://svn.ffmpeg.org/ffmpeg/trunk [17:18:34] <CIA-15> ffmpeg: (cherry picked from commit c47ca25e74bbe465cdc8b99d4f6ab4f0ad5e4229) [17:18:36] <CIA-15> ffmpeg: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> release/0.5 * r8069e2f6fb ffmpeg/libavcodec/vc1.c: [17:18:36] <CIA-15> ffmpeg: Fix invalid reads in VC1 decoder [17:18:36] <CIA-15> ffmpeg: Patch discussed and taken from https://roundup.ffmpeg.org/issue2584 [17:18:36] <CIA-15> ffmpeg: (cherry picked from commit 2bbec1eda46d907605772a8b6e8263caa4bc4c82) [17:18:37] <CIA-15> ffmpeg: Change related to CVE-2011-0723 [17:18:39] <CIA-15> ffmpeg: Kostya Shishkov <kostya.shishkov(a)gmail.com> release/0.5 * r808f9ce727 ffmpeg/libavcodec/rv34.c: [17:18:39] <CIA-15> ffmpeg: Call avcodec_set_dimensions() instead of simply setting avctx->width/height [17:18:39] <CIA-15> ffmpeg: when frame dimensions change in RV3/4. [17:18:39] <CIA-15> ffmpeg: Originally committed as revision 20595 to svn://svn.ffmpeg.org/ffmpeg/trunk [17:18:39] <CIA-15> ffmpeg: (cherry picked from commit d90aeeaf569e4a08c30b3d1d09c3cff3a86eb431) [17:19:58] <Flameeyes> lu_zero: mlt _still_ bundles its own ffmpeg? [17:20:18] <mru> siretart: planning a new 0.5 release? [17:20:32] <lu_zero> Flameeyes: I guess... [17:22:00] <siretart> mru: yes, I want to get 0.5.4 out and start then on 0.6.2 [17:22:24] <siretart> mru: the last open thing I'm aware of is https://roundup.ffmpeg.org/issue2584 (AKA CVE-2011-0723), but that's still unfixed in master [17:22:57] <siretart> mru: anyway, need to run to my parents-in-law now, cu later/tomorrow [17:23:10] <lu_zero> siretart: take care =) [17:23:44] <Flameeyes> uhm I/O error [17:23:50] <Flameeyes> trying agian [17:27:59] <BBB> Flameeyes: that's kinda funny [17:28:03] <BBB> thank for trying so hard :) [17:30:09] <Flameeyes> elfgrep: /media/tinderbox/opt/scratchbox/compilers/cs2009q1-eglibc2.8-armv7/arm-none-linux-gnueabi/libc/usr/lib/Scrt1.o: Unknown section type 0x70000001 for section .ARM.exidx (Elf::Section::UnknownType) [17:30:09] <Flameeyes> guh :| [17:30:21] <Flameeyes> stupid scratchbox [17:30:25] <BBB> kshishkov: patch on ML for you, I'd appreciate if you could comment on my question there [17:30:28] <Flameeyes> limiting to /usr instead [17:30:33] <lu_zero> wbs: poing [17:30:48] <BBB> kshishkov: in particular, my handling of the if(pq>=9&&overlap)/if(rangeredfrm) parts [17:32:11] <Jumpyshoes> Dark_Shikari, pengvado, BBB, etc: can i copy x86inc directly without licensing mess? do i need to get approval? [17:32:25] <BBB> x86inc is BSD [17:32:27] <BBB> so you can [17:32:38] <Jumpyshoes> ok [17:33:40] <Jumpyshoes> uh, should i change the header? aka copyright info [17:37:14] <lu_zero> why? [17:37:25] <Jumpyshoes> it's outdated [17:37:36] <BBB> ? [17:37:45] <BBB> what do you mean? [17:37:59] <Jumpyshoes> well it's copyright 2005-2008, should be 2011 [17:38:06] <BBB> it's ok [17:38:10] <Jumpyshoes> okay [17:38:18] <BBB> hasn't been changed since then, has it? [17:38:39] <Jumpyshoes> well, i just changed it for AVX support [17:40:58] <BBB> ah, then you can, yes [17:41:02] <BBB> in the same patch :) [17:41:44] <Jumpyshoes> kk [17:44:14] <Flameeyes> BBB: http://www.flameeyes.eu/tmp/elfgrep.log [17:49:25] <Jumpyshoes> derp [17:49:27] <Jumpyshoes> how do i [17:49:35] <Jumpyshoes> er, is it possible to enable gpl [17:49:43] <Jumpyshoes> without distclean [17:50:19] <elenril> thanks Flameeyes [17:50:26] <elenril> michaelni: ^ [17:58:44] <BBB> xbmc uses put_buffer and put_byte [17:58:52] <BBB> also get_buffer [17:59:10] <BBB> put_be16/32 also [17:59:19] <BBB> init_put_byte [17:59:38] <wbs> init_put_byte shouldn't be used, the one that allocates should be used instead [17:59:55] <BBB> I agree, but I'm just saying what it uses right now [18:03:30] <elenril> in any case, imo it's sufficient proof that get/put_ should be officially public [18:04:31] <BBB> elenril: agreed [18:04:46] <BBB> maybe Michaelni wanted to see which are used and which are not [18:05:18] <kshishkov> well, they are rather stable too [18:05:20] <BBB> so we can make some public (get/put_buffer/{be/le}{16,24,32},byte}) but not others (tag, stuff [18:11:06] <Jumpyshoes> is there a way to update fate samples without cloning the entire thing again [18:11:38] <Jumpyshoes> and is there any way to set fate samples without having to configure and build again? [18:11:58] <mru> make SAMPLES=/some/path fate [18:12:08] <Jumpyshoes> thanks [18:12:09] <mru> rsync only copies what's changed [18:12:34] <Jumpyshoes> okay, cool [18:15:46] <lu_zero> BBB: I'd like to know which ones should be private... [18:16:22] <BBB> me too [18:16:32] <BBB> kshishkov: I really need a conformance suite at this point [18:16:35] <lu_zero> since I'd consider public any one used in a demuxer... [18:16:46] <lu_zero> btw [18:17:00] <BBB> lu_zero: well I'm not sure if I agree with it, demuxers are internal [18:18:12] <lu_zero> BBB: couldn't we register external demuxers? [18:18:23] <lu_zero> (or codecs) [18:19:16] <BBB> maybe... but these usually have their own I/O anyway [18:19:21] <BBB> e.g. libogg, libnut, etc. [18:20:06] <lu_zero> BBB: When I think about those I try to consider this way: [18:20:33] <lu_zero> - does it use internal stuff that could/I want randomly change in the future? [18:21:28] <lu_zero> - could I consider an outside usage for it? [18:21:58] <lu_zero> anyway [18:22:19] <lu_zero> I'm thinking about adding a poll function pointer for protos [18:24:23] <Flameeyes> mru: where can I find the documentation of ELF sections for ARM? seems like glibc's elf.h fails [18:24:34] <lu_zero> it should be useful since it might lead to factor the polling code for the normal protocols (udp, tcp) [18:24:36] <kshishkov> BBB: ask merbzt, I told you [18:24:49] <mru> Flameeyes: infocenter.arm.com [18:24:56] <Sean_McG> Flameeyes: would ARM's dev si... yeah what mru said [18:25:01] <mru> there's a section there on ABI stuff [18:25:09] <BBB> kshishkov: he's offline [18:25:10] <BBB> :( [18:25:17] <Flameeyes> mru: thanks [18:25:41] <mru> Flameeyes: http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html [18:25:44] <kshishkov> BBB: send a mail [18:25:48] <BBB> I did [18:25:50] <BBB> no response [18:25:57] <BBB> and vc1 makes no sense to me [18:26:02] <BBB> this is outrageous [18:26:15] <Sean_McG> anyone good at regexes? [18:26:18] <kshishkov> I hope you fully comprehend ITU H.264 then [18:26:31] <BBB> kshishkov: I would not in a 1000 years dare make that claim [18:26:33] <Sean_McG> I need to filter out all lto options from CFLAGS [18:27:30] <kshishkov> BBB: grab a copy of spec at least [18:27:38] <BBB> got a link? [18:27:54] <BBB> (vc1 spec) [18:28:12] <BBB> hm, gotta go [18:28:12] <BBB> bbl [18:28:16] <Sean_McG> I guess what I need to match is: -flto<non-whitespace chars> [18:28:18] <kshishkov> BBB: http://multimedia.cx/mirror/s421m.pdf [18:28:46] <roxfan> Flameeyes: what section is an issue? [18:28:54] <mru> Sean_McG: what flavour of regexes? [18:29:02] <Sean_McG> bash script [18:29:07] <mru> non-answer [18:29:12] <mru> BRE, ERE, Perl, etc? [18:29:21] <Sean_McG> it's not grep or perl or.. [18:29:25] <mru> what then? [18:29:44] <roxfan> i don't think bash has built-in regexps [18:29:50] <Flameeyes> roxfan: mostly found files in scratchbox with section types not listed in the elf.h files I used to set the section type ranges — I don't have time now, but at some point I'll probably add support for parsing those, now that I have the specs ;) [18:29:51] <Sean_McG> bash variable replacement, currently I'm using ${CFLAGS//-flto/} , but that... OH. [18:29:52] <roxfan> so you probably need sed or something [18:29:59] <mru> Sean_McG: that's not a regex [18:30:02] <Sean_McG> OK... I'll google [18:30:12] <Flameeyes> it's a glob pattern [18:30:36] <mru> you can do it with a shell function and a replacement expansion on $@ [18:30:42] <mru> in bash [18:30:49] <mru> not straight sh [18:31:03] <Sean_McG> argh... [18:31:21] * Sean_McG punches Solaris /bin/sh in the junk [18:31:32] <mru> that one is even worse [18:31:34] <roxfan> afair there's only a couple of arm-specific sections and i think i've only seen .ARM.exidx in real life [18:32:00] <roxfan> ah, also .ARM.attributes [18:32:18] <Sean_McG> anyways, this is for GPAC which I suppose is off-topic here so I'll go poking around some more [18:32:42] <Flameeyes> roxfan: exidx is the one I was missing [18:33:40] <mru> ugh, exception unwinding nasties [18:34:06] <Sean_McG> just another reason that C++ sucks ;) [18:34:08] <kierank> Sean_McG: lol gpac [18:34:22] <Sean_McG> kierank: yeah I'm well aware of how it's perceived [18:34:38] <mru> gpac was responsible for that crazy mp4 file we were looking at earlier today [18:36:46] <kierank> BBB: do you want a newer vc-1 spec? [18:37:12] <kshishkov> kierank: it was standardised in 2006 anyway. [18:37:20] <kierank> there are amendments [18:37:28] <kshishkov> I would want them [18:37:35] <kierank> http://dl.dropbox.com/u/2701213/Specs/SMPTE/SMPTE%20Standards/S421m-2006.pdf [18:37:40] <kierank> http://dl.dropbox.com/u/2701213/Specs/SMPTE/SMPTE%20Standards/S421m-Am1-200… [18:37:49] <kierank> all are on the ftp as well now [18:39:25] <kshishkov> hmm, nothing serious in amendment though [18:39:29] <kshishkov> that's good [18:39:49] <elenril> Flameeyes: why am i getting 403 forbidden when trying to download that log [18:40:09] <Flameeyes> elenril: wait [18:40:15] <kierank> kshishkov: there are also compliance bitstreams on your nearest bay of pirates [18:40:46] <Flameeyes> elenril: heh -U 'Pretty please' [18:41:04] <Flameeyes> I forgot to disable the no-downloaders from my main website :) [18:41:16] <elenril> heh [18:41:23] <kshishkov> kierank: I've downloaded them long time ago, but please give a link to BBB [18:41:32] <kierank> hmmm no seeders left [18:41:34] <kierank> ah well [18:46:29] <elenril> Flameeyes: i'll send a copy of it to the ml [18:46:37] <Flameeyes> elenril: sure [18:47:15] * elenril watches a cascade of conflicts [18:47:26] <elenril> BBB: this is why i want them applied gradually ;) [20:26:30] <Yuvi> Dark_Shikari: sorry, fell asleep [20:26:30] <Yuvi> mru: ctts in .mov is allowed to be (and often is) negative [20:26:30] <Yuvi> ISO 14496-12 defines the entries in ctts as a non-negative int(32) [20:27:14] <mru> wrong [20:27:46] <mru> isom ctts v0 is unsigned [20:27:55] <mru> ctts v1 is signed [20:28:12] <_av500_> kshishkov: btw, our players play .rcv [20:28:12] <mru> but why the hell would you ever use a negative value? [20:28:45] <_av500_> kshishkov: i wanteds to add it to ff then i saw you did thatalready :) [20:28:58] <Yuvi> to get a pts of 0 in a cfr track w/ reordering [20:29:18] <Yuvi> since dts can't be negative in either mov or mp4 [20:29:26] <mru> ah [20:29:34] <mru> but why is pts of zero so important? [20:29:51] <mru> just set a non-zero first pts for audio as well [20:29:52] <_av500_> its the pts of the big bang [20:31:33] <Yuvi> quicktime didn't show the first frame if pts was >0 when you opened a file (since it starts paused at 0 [20:31:57] <kierank> never really understood why mp4 didn't take vbv into consideration [20:32:01] <kierank> like mpegts [20:32:21] <kierank> so the first dts would never be zero [20:32:47] <kshishkov> _av500_: make them play .ivf as well [20:33:04] <kierank> dear Yuvi fix quicktime aac encoder bug. kthxbye [20:33:18] <_av500_> kshishkov: when i am bored enough [20:33:21] <Yuvi> kierank: totally not my area :P [20:33:34] <_av500_> kshishkov: i even invented rcrv for real video testing [20:34:03] <kierank> I wonder if I could release a binary patch to quicktime's aac encoder [20:34:05] <kierank> that might work [20:34:25] <_av500_> kierank: via the itunes store? [20:34:44] <kierank> lol [20:34:47] <_av500_> youd get 70% [20:34:52] <kierank> 70% what? [20:35:06] <_av500_> kierank: apple users pay for sw [20:38:08] <kierank> I wonder if apple will accept bugfixes in the app store [20:38:11] <kierank> probably will be rejected [20:38:24] <kierank> and knowledge of the bug denied [20:48:58] <lu_zero> yawn [20:53:31] <_av500_> +1 [20:55:35] <lu_zero> michaelni: do you enjoy insulting people? [20:55:53] <michaelni> lu_zero, what? [20:56:26] <lu_zero> and that probably is the N-th time I tell you. [20:57:07] <michaelni> is the truth an insult to you? [20:59:03] <lu_zero> michaelni: I could say that you are particular and you should balance your opinion and try to deliver your concerns in a more proper way [20:59:06] <lu_zero> OR [20:59:30] <lu_zero> I COULD STATE THAT YOU ARE A FUCKING PRICK AND YOU SHOULD JUST SHUT THE HELL UP INSTEAD OF SPOUTING NONSENSE [20:59:43] <lu_zero> I think you could tell the difference [20:59:44] <mru> lu_zero: calm down [21:00:15] <lu_zero> you usually are closer to the latter tone [21:01:09] <mru> also, attaching a "btw, you suck" at the end of every message isn't very polite either [21:01:28] <mru> even if the main part of the message wasn't directly insulting [21:01:57] <mru> now about what's public api [21:02:06] <mru> it doesn't really matter what is actually used [21:02:28] <mru> even things not currently (to our knowledge) used can still make sense being public [22:25:19] <Jumpyshoes> BBB, mru, Dark_Shikari, etc: any comments to the avx patch besides i can't test for speed atm? (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-February/107514.html) [22:26:39] <BBB> michaelni: I think what would help is that instead of complaining, you propose constructive solutiobs [22:27:06] <BBB> michaelni: for example, your point of view is probably (please confirm) that we should split avio.h into public and private API, or even make all of it private [22:27:34] <BBB> although I think stuff like ByteIOContext should be public, as should av_alloc_put_byte() [22:27:41] <BBB> the rest can possibly be private [22:28:18] <BBB> ByteIOContext, if public, needs a AV prefix also [22:28:28] <BBB> like AVIOContext or AVByteIOContext [22:29:50] <BBB> kshishkov: not getting any replies from sweden today - any other sources for vc1 conformance suite? [22:31:44] <Flameeyes> BBB: it's fun.. microsoft's license on their specs is actually an acceptable one :P [22:53:32] <CIA-15> ffmpeg: Marton Balint <cus(a)passwd.hu> master * r74d6871d62 ffmpeg/libavformat/mms.c: [22:53:32] <CIA-15> ffmpeg: MMS: also discover streams in extended stream properties object [22:53:32] <CIA-15> ffmpeg: Allows playback of nonprimary audio streams in multiple bitrate sources, [22:53:32] <CIA-15> ffmpeg: such as mmsh://wmscr1.dr.dk/e02ch03m [22:53:33] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [22:57:48] <j-b> this code looks quite like vlc's [22:58:13] <mru> j-b: implying something? [22:58:26] <j-b> no [22:58:52] <j-b> just http://git.videolan.org/?p=vlc.git;a=commitdiff;h=dd3d1962db04a7d2c5e790056… [22:59:21] <j-b> might be just following the spec :) [23:01:40] <iive> j-b: aren't both from same author? [23:02:50] <BBB> wtf smpte 421 is like $400 [23:03:02] <michaelni> BBB, iam not against making all/most of avio.h public but iam against that this is done without reviewing each function one by one to make sure we want it to be public and that we understand the ABI issues we might have due to it [23:03:11] <j-b> iive: yes, exactly [23:03:17] <BBB> michaelni: now that sounds a lot nicer, great work! [23:03:32] <BBB> michaelni: which ones would you like to see/not see exposed specifically? [23:03:53] <ohsix> is it a form of bikeshedding to insist someone explain something a certain way [23:04:40] <kierank> is it a form of bikeshedding to decide what bikeshedding means [23:04:45] <michaelni> i think one question we should awnser first is if we want demuxers written outside to use this API [23:05:02] <mru> ohsix: asking people not to be excessivly rude and insulting is not bikeshedding [23:05:03] <michaelni> there are good argumebts for either way ... [23:05:05] <ohsix> how do you name it without a definition, at best without one it acts as a pejorative [23:05:29] <BBB> michaelni: well, so my take on it is that put/get is a wrong prefix [23:05:35] <BBB> michaelni: internal is ff, otherwise it's av [23:05:38] <michaelni> yes [23:05:40] <BBB> michaelni: so we have to rename it either way [23:05:43] <michaelni> yes [23:05:43] <BBB> so let's do it right :) [23:05:52] <BBB> I would hate to do a mass-commit twice [23:05:56] <BBB> waste of my time (and yours) [23:06:10] <michaelni> 3sec cherrypick [23:06:14] <michaelni> ill survivie it [23:06:20] <mru> possibly some functions should be made public in a slightly different form [23:06:22] <BBB> yeah, well, I have to review the patch [23:06:43] <BBB> so, do you want this api public? I don't care either way tbh [23:06:53] <BBB> as long as AVByteIOContext and av_alloc_put_byte() are public [23:06:58] <BBB> quite some apps use these 2 [23:07:04] <BBB> to hook into lavf demuxers [23:07:07] <BBB> using their own i/o [23:07:15] <mru> so it's obviously useful [23:07:44] <mru> if the current interface is unsuitable to export, we should export the same functionality in a better way [23:08:08] <BBB> I'm open to proposals [23:08:15] <BBB> the api itself seems fine to me [23:08:24] <BBB> whether to export it is indeed a different question [23:08:41] * BBB can't find a free copy of the vc1 specs [23:08:50] <mru> if the api is ok as is, there's no reason to make it private [23:08:53] <kierank> BBB: I posted them above [23:09:03] <BBB> oh [23:09:05] <BBB> lemmesee [23:09:42] <BBB> kierank: you have the testsuite also? [23:09:49] <kierank> nope [23:09:59] <kierank> only a document which describes the testsuite ;) [23:10:38] <michaelni> /* not implemented */ [23:10:42] <michaelni> url_poll() ;) [23:11:01] <mru> url_poll() is useless [23:11:15] <mru> more useful would be a way to get at the underlying fd [23:11:31] <michaelni> url_get_file_handle() ? [23:11:35] <mru> and feed it to poll together with unrelated fds the app might have for other reasons [23:11:48] <michaelni> which needs better docs IMHO [23:12:23] <mru> ah, it already exists [23:13:14] <michaelni> extern URLInterruptCB *url_interrupt_cb; [23:13:35] <michaelni> wasnt there some issue with globals ... [23:14:28] <mru> globals are evil [23:15:04] <michaelni> they are usefull in small programs but here i agree [23:15:32] <lu_zero> mru: would be nicer not have a poll on every write or read call ^^; [23:16:05] <mru> lu_zero: either you use blocking i/o or you use poll [23:16:45] <mru> doing a poll/read loop that emulats a blocking read is of course silly [23:16:54] <michaelni> I think the ByteIOContext and URLContext stuff should be put in 2 seperate headers [23:17:08] <mru> avurl.h? [23:17:17] <michaelni> whatever you prefer [23:18:33] <michaelni> and all functions should be documented (except trivial ones) [23:20:33] <BBB> lu_zero: that can be another URLContext flag [23:20:38] <BBB> lu_zero: caller_will_poll_flag or so [23:20:40] <michaelni> URLContext *url_fileno(ByteIOContext *s); <-- no docs [23:20:46] <ohsix> uri? [23:20:48] <BBB> lu_zero: also useful for rtsp [23:20:55] <lu_zero> BBB: indeed ^^; [23:22:06] <michaelni> int udp_set_remote_url(URLContext *h, const char *uri); [23:22:13] <michaelni> somehow that looks ugly in there [23:23:31] <michaelni> Also important is that all structs avio.h needs have allocator functions so we can add fields withiut ABI issues [23:23:47] <BBB> udp_set_remote_url() is strictly internal [23:24:00] <michaelni> good we agree [23:24:12] <michaelni> theres a second udp_ function too [23:24:13] <BBB> might need to move to udp.h [23:24:20] <BBB> lu_zero: can you fix that? :) [23:25:22] <michaelni> URLPollEntry is only used by url_poll() [23:25:45] <BBB> function and struct need to die [23:25:50] <BBB> elenril had patches to deprecate them [23:25:57] <BBB> we can also just remove them [23:27:24] <michaelni> url_is_streamed() looks useless [23:27:39] <michaelni> ist just return s->is_streamed [23:30:19] <michaelni> The structs look fine to me [23:30:37] <BBB> structs = URLContext/ByteIOContext? [23:30:39] <BBB> yeah, they're fine [23:30:47] <michaelni> and URLProtocol [23:30:51] <iive> is the struct public? [23:30:51] <BBB> URLContext and url_*(): internal or extenral? [23:31:02] <BBB> I don't think URLContext has any clear use on the outside [23:31:18] <BBB> URLProtocol indeed also [23:32:20] <iive> if struct is not public, and it is not recommended to be read directly, then you need functions to do that for you. [23:32:48] <BBB> we don't have private structs with public API, afaics [23:33:00] <BBB> unless you count things like AVFormat/CodecContext->priv_data [23:34:48] <mru> and in other news, armcc outdoes itself with another botched loop unrolling [23:35:03] <mru> this time it segfaults if called with a count of zero [23:36:17] <michaelni> BBB, if you want to implement URLProtocols outside, i think you need URLContext [23:36:41] <BBB> hm [23:36:45] <BBB> oh right gstreamer does that [23:36:47] <BBB> ugh [23:36:56] <michaelni> mplayer did in the past too [23:36:57] <thresh> kshishkov: heard of KBR & Elbrus stuff? :( [23:36:59] <BBB> do we want to keep supporting that? [23:37:09] <BBB> where's bilboed when you need him [23:37:16] <michaelni> ive no strong oppinon either way [23:37:32] <mru> thresh: the elbrus name always cracks me up [23:37:39] <mru> thresh: do you know what that means in swedish? [23:37:43] <thresh> mru: nope [23:37:47] <mru> electrical noise [23:37:57] <thresh> heh [23:38:04] <mru> so apt [23:38:24] <thresh> anyway, 3 tourists killed & ropeway blasted there. friends of mine are going home from that place tomorrow... [23:38:45] <thresh> others cancel their tickets on vacations out there [23:39:46] <mru> "there"? [23:39:56] <thresh> in Caucasus [23:40:06] <Flameeyes> lu_zero: ping [23:40:31] <thresh> KBR stands for http://en.wikipedia.org/wiki/Kabardino-Balkaria [23:41:02] <BBB> yeah gst still does that [23:41:04] <BBB> that's not good [23:41:27] <BBB> michaelni: I'd say we should promote people to not do that, the ByteIOContext* method is easier [23:41:38] <BBB> and has less overhead anyway [23:41:57] <BBB> let's make URL* and url_*() private (so ff_url_*() for functions, struct stays at it is) [23:42:29] <BBB> michaelni: then make ByteIOContext public, AVByteIOContext, along with av_alloc_put_byte() which was already public [23:42:43] <BBB> michaelni: as for the get/put_*() functions, there is some use, see ML, let's see if we want to support that [23:42:59] <BBB> I might argue that stuff is better implemented inside lavf, e.g. a dvd player, would be nice to support [23:43:30] <mru> some things are still better done outside [23:44:10] * michaelni is always in favor of keeping things private if possible as its easy to make things public but hard the other way around [23:44:40] <BBB> mru: well then again, all it uses it for is for writing out nals and an avcc atom [23:44:47] <mru> true, but here we're dealing with things that are public, if by accident [23:45:07] <mru> BBB: I wasn't talking about any specific case [23:45:15] <BBB> fair enough [23:46:43] <BBB> elenril: ping [23:47:03] <BBB> elenril: let's start at the easy stuff, can you post a patch that renames ByteIOContext to AVByteIOContext? at least that one everyone agrees on [23:58:54] <mmu_man> hmm I don't suppose mpeg2 TS allows the cat trick like PS, does it ? [23:59:00] <mmu_man> the one on http://ffmpeg.org/faq.html#SEC27 [23:59:19] <mmu_man> oh well, I need to cut anyway, I can always remux to PS

1 0

IRC log for 2011-02-18
by irc＠mansr.com 19 Feb '11

19 Feb '11

[00:01:14] <Jumpyshoes> is there a benefit to ffmpeg's config style vs. x264's? [00:01:33] <mru> ffmpeg's is better :) [00:02:33] <Sean_McG> mru: out of nothing more than idle curiosity, can I ask what kind of G4 saracen is? [00:02:43] <mru> windtunnel [00:02:46] <Sean_McG> ah [00:02:58] <Sean_McG> yeah I used to have a Quicksilver [00:03:09] <mru> I keep it behind a closed door :) [00:03:13] <Sean_McG> buying a used G4 Mini from an acquaintance [00:03:24] <Sean_McG> I wanna learn POWER more. [00:03:48] <mru> get ready for the 5-operand shift/rotate [00:06:19] <drv> sounds like barrels of fun [00:07:12] <Sean_McG> I need something to take my mind off my job before it devours what's left of my soul :\ [00:08:42] <mru> Sean_McG: why don't you change jobs? [00:09:00] <Sean_McG> there's not a lot available for my skillset [00:09:02] <mru> few things are more satisfying than quitting a shitty job [00:09:24] <Sean_McG> I do IBM Tivoli stuff, and I hate it [00:09:30] <mru> so learn something new while pretending to work [00:09:47] <Sean_McG> that only works when you have time, and a team leader who isn't f**king micromanaging [00:10:24] <mru> oh, your job really sucks... [00:11:26] <Sean_McG> in the beginning it wasn't so bad, but the past 6 months have been really shitty [00:11:37] <mru> it's always like that [00:11:49] <mru> in the beginning it's at least different from what you did before [00:12:00] <mru> and all companies get worse over time [00:12:06] <Sean_McG> aye... in the beginning I was a severely underpaid web developer [00:12:37] <Sean_McG> well, I work for the government so really it should be a given... the whole "do more, with less money" thing [00:12:49] <mru> if you don't have to lower your demands, you're not asking for enough [00:12:58] <mru> so I've learned [00:14:59] <Sean_McG> past 2 weeks have been really bad... I feel like I'm on a sinking ship :| [00:16:02] <mru> have the rats left the building? [00:16:17] <Jumpyshoes> where do you work at? [00:16:23] <Sean_McG> Revenue Canada [00:16:52] <Jumpyshoes> oh, canada [00:17:00] <Sean_McG> heh [00:17:58] <Jumpyshoes> don't know anything about canada [00:18:43] <mru> it's that empty place in the north [00:19:06] <mru> but it's not actually as big as it looks on the maps [00:19:14] <mru> they're cheating, you see [00:20:53] <kierank> [00:17] Jumpyshoes: oh, canada --> *rimshot* [00:21:02] <Jumpyshoes> what [00:21:11] <Jumpyshoes> i thought Sean_McG was in the US [00:21:21] <mru> it's pretty obvious he's not [00:21:32] <mru> from the rogers.com IP if nothing else [00:21:46] <Jumpyshoes> i don't whois people [00:21:50] <Jumpyshoes> generally [00:21:55] <mru> my irc client displays it when he comes on [00:22:07] <Sean_McG> wow, why so much red on fate today? [00:22:37] <mru> Sean_McG: yeah, BBB broke ppc [00:22:46] <Sean_McG> ahhh the VC1 stuff [00:22:58] <BBB> orking on it [00:23:51] <BBB> baby cries unstoppingly [00:23:52] <BBB> hard to work [00:23:55] <BBB> I mostly got it fixed [00:23:57] <Sean_McG> ouch [00:25:11] <mru> BBB: maybe they're related: baby cries when fate is red [00:26:08] <Sean_McG> hmmm well, I think I'mma watch some Doctor Who [00:26:15] <Sean_McG> later folks [00:32:54] <BBB> ok works now [00:32:59] <BBB> will send a patch [00:33:10] <mru> \o/ [00:34:28] <BBB> patch sent [00:34:30] <BBB> have a look [00:35:30] * BBB isrocking baby with one foot typing with two hands and using the other foot to remain stable on his chair [00:35:40] <BBB> bouncy chair \o/ [00:35:44] <BBB> anyway [00:36:00] <BBB> now let's go back to fixing vc1 performance for real [00:39:38] <mru> BBB: I'm not entirely happy with the amount of added ifdeffery [00:39:54] <mru> can't the vc1 bits simply be moved to another file? [01:02:39] <BBB> mru: they depend on stuff shared in that template file [01:02:51] <BBB> mru: so I'd have to split the template file in two and add the shared stuff in a third file [01:02:57] <BBB> mru: which looked messy to me [01:03:17] <mru> CHROMA_MC8_ALTIVEC_CORE? [01:04:07] <mru> btw that file looks like whoever wrote it was trying to make altivec as messy as mmx [01:04:35] <Sean_McG> yeah the propensity for macros in the altivec files make the baby jesus cry [01:04:37] <BBB> hehe :) [01:07:44] <BBB> mru: so what do you suggest I do? move the CORE into a header and split the template file? [01:10:50] <mru> is that the only common part? [01:11:04] <BBB> I think so [01:14:03] * BBB pokes mru [01:14:31] <mru> gah, can't make up my mind [01:14:39] <mru> it's all ugly [01:14:41] <BBB> I can just keep ppc broken [01:14:45] <BBB> and yes it's ugly [01:14:53] <BBB> how do you call this type of asm again? [01:14:59] <BBB> it's not yasm, it's not inline asm [01:15:05] <mru> intrinsics [01:15:08] <mru> worst kind [01:15:10] <BBB> oh yeah, intrinsics [01:15:15] <BBB> I remember the mmx intrinsics [01:15:19] <BBB> wasn't that called mmx.h? [01:15:22] <BBB> that was fabulous [01:15:27] <BBB> like Sex and the City III [01:15:34] <BBB> absolutely horrid [01:16:58] <kierank> women and gay people would beg to differ [01:17:10] <mru> some find gay people horrid too [01:17:26] <mru> not that I'd ever endorse such opinions [01:17:45] <kierank> what's that got to do with women and gay people liking sex and the city [01:17:53] <mru> nothing [01:18:34] <Jumpyshoes> i thought the women in sex and the city 3 were old [01:18:59] <mru> Jumpyshoes: you're young... [01:20:16] <Jumpyshoes> one of the main actresses is currently 45 and the show ended in 2004 [01:20:21] <mru> not that I'd know how old aforementioned women are, not having seen the film [01:20:40] <mru> nor the show [01:20:48] <mru> some things are better left unseen [01:21:31] <Jumpyshoes> well i haven't watched it either, i just read an article about old women in the movie [01:21:49] <mru> don't believe everything you read [01:21:55] <mru> unless it's on irc [01:22:00] <mru> everything on irc is true [01:23:03] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * red040f35f2 ffmpeg/libavcodec/ppc/ (h264_altivec.c h264_template_altivec.c vc1dsp_altivec.c): Fix PPC build. [01:24:54] <kierank> Jumpyshoes: ask BBB [01:24:58] <kierank> he's the satc expert [01:25:32] <Jumpyshoes> i did not know that [01:26:52] <BBB> huh? [01:26:53] <BBB> dude [01:26:56] <BBB> you gotta be kidding me [01:26:59] <BBB> my wife made me go [01:27:01] <BBB> or actually her sister [01:27:13] <BBB> my wife's sister's boyfriend had to go to, he hated it also [01:27:19] <Jumpyshoes> sometimes you need to step up and say no` [01:27:23] <BBB> and we went to watch the worldcup matches afterwards :) [01:28:31] <kierank> you mean watch holland get beaten by spain? [01:31:19] <bcoudurier> I didn't know the 3rd was out yet [03:38:35] <Dark_Shikari> Anyone know what the heck qscale_table is used for in the vp3 decoder? [03:38:39] <Dark_Shikari> It's written to everywhere, and used nowhere. [03:40:15] <astrange> libpostproc [03:40:24] <Dark_Shikari> memset(s->qscale_table, (FFMAX(s->qmat[0][0][0][1], s->qmat[0][0][1][1])+8)/16, 512); //FIXME finetune [03:40:27] <Dark_Shikari> what is with this? [03:40:29] <Dark_Shikari> why are only 512 bytes set? [03:40:32] <Dark_Shikari> why is it [2048]? [03:40:36] <Dark_Shikari> this makes no sense [03:40:43] <astrange> and/or mplayer -lavdopts vstats [03:41:01] <Dark_Shikari> I'm fixing vp3 to work with widths > 2048 [03:41:50] <astrange> qscale_table assumes MPEG1-4, unfortunately [03:42:01] <Dark_Shikari> What does h264 set it to? [03:42:01] <Dark_Shikari> etc [03:42:11] <astrange> so the values are the QP for every 16 pixels [03:42:29] <Dark_Shikari> But what's the memset for [03:43:07] <astrange> beats me. maybe the qps in vp3 aren't the same scale as mpeg [03:43:15] <Dark_Shikari> Why 512 bytes? [03:44:46] <Dark_Shikari> what if qscale_table isn't set? [03:44:49] <Dark_Shikari> what if it's null? [03:44:49] <Dark_Shikari> etc [03:45:26] <astrange> it's always set if it's a static array [03:45:27] <astrange> b928ec64 (Michael Niedermayer 2003-08-20 07:35:23 +0000 707) memset(s->qscale_table, (FFMAX(s->intra_y_dequant[1], s->intra_c_dequant[1])+8)/16, 512); //FIXME finetune [03:46:16] <astrange> 512 should be picture width in 16x16 macroblocks [03:46:18] <BBB> omg slashdot alert, D_S h264 expert switches to theora, dumps vp8?!?one [03:47:17] <Dark_Shikari> astrange: why is it just one row? [03:47:49] <Jumpyshoes> lol BBB [03:48:14] <astrange> well it shouldn't be that either, but that's more correct at least [03:48:26] <astrange> in that it doesn't set things that aren't read [03:48:45] <astrange> but it should be something kind of like a macroblock qp, or else nothing [03:49:07] <Dark_Shikari> how does postproc use it? [03:49:09] <Dark_Shikari> what if it isn't set? [03:49:25] <astrange> increases deblock/dering strength based on qp as if it were mpeg4 [03:49:34] <astrange> if it's not set, no pp [03:49:51] <Dark_Shikari> what should we do then? [03:50:03] <astrange> well pp doesn't even make sense for vp3 so that doesn't matter [03:50:12] <Dark_Shikari> so we should just kill it? [03:50:14] <Dark_Shikari> leave it null? [03:50:29] <astrange> i'd delete it. qscale_table doesn't have to be set in AVFrame [03:50:31] <Dark_Shikari> oh I see [03:50:33] <Dark_Shikari> it set qstride to 0 [03:50:36] <Dark_Shikari> to repeat the same row over and over [03:51:03] <astrange> only useful for the stats files mplayer prints, but if they aren't real numbers in the bitstream i don't think it's good for research [03:54:28] <bcoudurier> some people use it to retrieve qps [03:54:58] <Dark_Shikari> .... oh god, this is more embarassing than I thought [03:55:00] <Dark_Shikari> 14:49 < gmaxwell> https://people.xiph.org/~greg/vp8/primer-a.00000001.png [03:55:00] <Dark_Shikari> 14:49 < gmaxwell> https://people.xiph.org/~greg/vp8/primer-b.00000001.png [03:55:00] <Dark_Shikari> 14:49 < gmaxwell> https://people.xiph.org/~greg/vp8/primer-c.00000001.png [03:55:08] <Dark_Shikari> Guess which codec each of these is... then read the spoilers. [03:55:14] <Dark_Shikari> You'll laugh your head off [03:55:21] <astrange> theora, vp8, x264 or newer theora? [03:55:25] <Dark_Shikari> A: VP8 encode from many months ago. B: VP8 encode from today. C: Theora [03:55:32] <astrange> ... [03:56:51] <bcoudurier> theora is shifted [03:57:02] <Dark_Shikari> Yes, it's not exactly the same frame, due to ffmpeg not being frame-exact. [03:57:11] <Dark_Shikari> A/B are enough to be hilarious though. [03:57:27] <bcoudurier> frame exact ? you mean seeking ? [03:57:33] <Dark_Shikari> yes, i.e. using -ss to grab a frame [03:57:37] <Dark_Shikari> for a screenshot [03:57:43] <Dark_Shikari> ffmpeg -i input -ss whatever -vframes 1 [03:57:43] <bcoudurier> ah [03:57:56] <bcoudurier> yep [03:58:00] <Dark_Shikari> anyways, it's hilarious. [03:58:06] <Dark_Shikari> libvpx has actually gotten WORSE. [03:58:11] <BBB> 1 is better than 2 [03:58:15] <Dark_Shikari> That's the point [03:58:15] <BBB> what the hell [03:58:22] <Dark_Shikari> This is why x264 and xvp8 will win [03:58:25] <Dark_Shikari> because libvpx is not just bad [03:58:29] <Dark_Shikari> it gets worse every month they develop it for [03:58:35] <BBB> e.g. look at the detail of his beard, it's completely fuzzy [03:58:37] <BBB> how did they do that [03:58:43] <Dark_Shikari> Turning on ARNR by default [03:58:53] <Dark_Shikari> `-` [03:59:14] <Dark_Shikari> Bitrate of 2 is apparently a bit lower, a few % [03:59:17] <Dark_Shikari> due to ratecontrol fuckery [03:59:19] <Dark_Shikari> but not massively [03:59:32] <Dark_Shikari> 14:59 < gmaxwell> I think it's even worse in motion, the new one is obviously splotchy. [04:00:27] <BBB> kshishkov: ping, do you have some kind of a vc1 testsuite? I'd like a variety of samples that use different vc1 features, e.g. where v->rangeredfrm is enabled or where v->pq has >9 values, since that apparently enables different decoder features [04:00:53] <BBB> Dark_Shikari: nice future for libvpx :( [04:02:03] * BBB sleep [04:02:18] <kierank> BBB: there is an official one iirc [04:04:19] <kierank> meh it costs $450 [04:05:22] <saintdev> Dark_Shikari: I'm guessing my choices are vp8, theora (ptalarbvorm), and x264? [04:06:29] <Dark_Shikari> saintdev: there's no x264 btw [04:06:33] <kierank> hmm there's a torrent [04:06:48] <saintdev> so theora (current?), and ptalarbvorm? [04:07:23] <saintdev> just trying to get my choices, or is that part of the fun? [04:08:03] <gnafu[away]> saintdev: Are you referring to the PNGs Dark_Shikari linked to? He already said what they were. [04:08:21] <saintdev> i know, i want to play along, so i'm not reading anything below those lines [04:08:30] <saintdev> or rather i assumed he did [04:08:35] <Dark_Shikari> Just guess for yourself, and then read it [04:08:36] <Dark_Shikari> and thne laugh [04:09:15] <saintdev> well i'm guessing B is vp8 (lolblur) [04:09:42] <saintdev> oh they're both vp8, hahahaha [04:10:49] <saintdev> Dark_Shikari: but isn't video _supposed_ to be blurry? ^_^ [04:17:26] <saintdev> peloverde: ping [04:35:13] <Sean_McG> so IBM actually has a Watson commercial [04:35:18] <Sean_McG> like anyone could afford one [04:36:03] <gnafu> Watson commissioned it... as a warning. [04:36:49] <Sean_McG> now that Watson has beaten Ken Jennings, how much closer are we to booting Skynet? [04:40:40] <ohsix> watson just cross correlated a few data sources & found a fitness function that'd find the most likely from its large set of inferences [04:42:26] <Sean_McG> thanks for killing the joke [04:43:26] <gnafu> ohsix: That's just what they want you to think. [04:44:17] <ohsix> i'm saddled with the knowledge of how to do it, i blame henry winston [04:45:03] <Jumpyshoes> stupid question. how do i add a directory for ffmpeg to search for yasm? and prefix it, so it will stop after finding that dir [04:45:22] <Sean_McG> I think they call it $PATH [04:45:50] <Jumpyshoes> without actually modifying path, isn't there an option in configure? [04:48:49] <saintdev> --as ? [04:49:41] <saintdev> although that probably gcc's as also [04:49:46] <Sean_McG> I've got yasm in /usr/local/bin so I just add that to the end of $PATH, which seems to follow standards(5) just fine, at least on Solaris [04:49:47] <saintdev> *overrides [04:53:01] <Jumpyshoes> i also have yasm, but it doesn't work. so i need to build another version that's unix compliant [05:18:32] <j0sh> Jumpyshoes: cflags/ldflags? [05:31:03] <peloverde> saintdev: pong [05:32:34] <saintdev> peloverde: did you get a chance to look that over? [05:37:18] <peloverde> sections of it don't seem to match the text [05:38:57] <peloverde> but some expressions may be folded [05:39:40] <peloverde> I do see the 115% stuff, i thought you said that part was missing [05:44:42] <saintdev> not that it's missing, but I guess that was a bad example. [05:46:25] <peloverde> what you sent does look like a pretty good pseudo code explanation of what the pe code should look like [05:47:06] <saintdev> you think it would be safe to work off of that? [05:47:45] <saintdev> and it does leave a few things out, and a few things are (intentionally) under-specified. [05:50:26] <peloverde> yeah it looks ok [06:07:11] <cartman> moin [06:10:42] <pJok> ohayou gozaimasu [06:10:54] <lu_zero> god morgon [06:13:09] <cartman> you guys are earlier than me :) [06:17:57] * elenril glares at BBB [06:24:32] <thresh> moroning [06:25:50] <kshishkov> a wonderful MKAD morning to you [06:26:22] <thresh> are you inside of MKAD? [06:27:43] <kshishkov> of course not [06:27:51] <kshishkov> not even close [06:28:05] <thresh> I'm not either [06:28:16] <thresh> so technically I'm in Russia [06:29:28] <kshishkov> by you're close to its internal border [06:30:27] <kshishkov> а в Москве небось и утро блатное, не то что у вас в Королёве [06:30:40] <thresh> что тут что там -28 градусов сегодня было [06:32:29] <j0sh> how do you guys type cyrillic on the same keyboard [06:32:32] <j0sh> sticky modifiers? [06:32:54] <kshishkov> keyboard layout switcher [06:33:28] <kshishkov> 日本語も [06:33:34] <j0sh> heh cool [06:33:43] <saintdev> IME [06:34:05] <astrange> 語 looks really odd in this font [06:34:15] * cartman hates when people are late to the early morning meetings [06:34:23] <astrange> read it as 望 [06:34:41] <kshishkov> cartman: you have left the company, so no problem for you [06:34:57] <cartman> kshishkov: the meeting is about my resignation :D [06:35:04] <cartman> and I am the only one here atm. :D [06:35:30] <lu_zero> makes sense [06:36:33] <thresh> j0sh: I don't look at the keyboard at all [06:37:11] <kshishkov> I look at mine, it has only english anyway [06:37:26] * cartman looks at the synergy daemon [06:38:27] <spaam> did you find anything? [06:38:36] <cartman> :P [07:24:38] <lu_zero> bcoudu: hi [07:26:29] <bcoudu> hi [07:41:05] <Tjoppen> morrn [07:49:53] <spaam> God morgon [07:54:20] <peloverde> happy thursday [07:54:27] <cartman> you mean friday! [07:55:02] <peloverde> it's still thursday here [07:55:20] <spaam> friday here :D [07:55:28] <cartman> peloverde: http://nelsonhaha.com [07:56:44] <superdump> ahoy [07:57:27] <cartman> ehlo superdump [08:38:48] <astrange> lu_zero: post ts samples please [08:39:05] <astrange> lu_zero: in the meantime i'm explaining how to fix lavf [08:39:15] <lu_zero> I asked for a stable url to the reported [08:39:18] <lu_zero> reporter [08:39:34] <lu_zero> I fixed his problem hacking the heuristic to behave differently [08:41:08] <lu_zero> astrange: still [08:41:23] <lu_zero> what's particularly wrong in what I said? [08:42:11] <astrange> well i don't really see the difference in adding a field and adding a utility function. either way i want to be able to ask people "change your code this way" so they fix some a/v sync bugs from mt [08:42:21] <astrange> but i think "read this field instead of the other one" is a bit easier [08:42:46] <astrange> i'm trying to remember the problem with using dts timing entirely... it's easier to generate... [08:43:13] <astrange> oh. with field samples, if you use pkt_dts, the frame combined from the 2 fields gets the time assigned to the second field [08:43:41] <astrange> and the same for other combined-packet things, it gets the time of the last packet [08:43:48] <astrange> (other = just mpeg-4 N-VOPs) [08:44:55] <lu_zero> the utility function makes easier to opt out [08:58:12] <iive> lu_zero: may I ask you something technical, and please don't get offending. [08:58:23] <iive> I'm starting to suspect that you may not know what b-frame lag is, and how reordering is done. [08:58:34] <iive> do you want explanation of that? [09:23:31] <peloverde> Mike is up yo more crazy http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread… [09:24:03] <kshishkov> peloverde: repost this link when lyakh is around [09:24:07] <astrange> discovering many odd things about mpeg files... [09:24:36] * lyakh is around [09:25:04] <kshishkov> okay, then the news have found its target [09:29:08] <lyakh> yeah... nice, thanks... do I remember it right, that libvpx wasn't particularly faster on vp8 decoding, than ffmpeg? [09:30:54] <Dark_Shikari> "wasn't particularly faster" [09:30:56] <Dark_Shikari> more like 50% slower [09:31:55] <lyakh> Dark_Shikari: yes, I didn't want to be impolite, in case I remembered it wrongly;) [10:10:48] <j-b> mike? [10:11:28] <kshishkov> Mike Melanson, ex-Xinde dev [10:11:31] <kshishkov> *Xine [10:11:37] <kshishkov> so you don't know him [10:11:59] <j-b> I know mike [10:12:19] <j-b> I was just wondering if he was on IRC [10:12:46] <thresh> he was [10:14:50] <j-b> kshishkov: I've met him twice in the USA [10:15:38] <Dark_Shikari> je [10:15:40] <Dark_Shikari> er [10:15:42] <Dark_Shikari> he's on irc rarely [10:15:46] <Dark_Shikari> like once every 3 years [10:16:24] <peloverde> I think we saw him quite recently so the Mike comet will return sometime in 2014 [10:19:15] <superdump> his nick is MultimediaMike when he comes on here [10:19:19] <kshishkov> maybe he'll re some game codecs [10:19:24] <Dark_Shikari> peloverde: Hah~ [10:19:40] <superdump> he mostly only comes on when asked though [10:49:39] <kshishkov> mate! [10:50:01] <kshishkov> I don't have anything to bug you with, no worries [10:50:22] <pross-au> A first [10:50:34] <pross-au> Lets flip the table [10:50:53] <pross-au> Smush! Smush! [10:51:09] <kshishkov> ohkay, the patch is on the list [10:51:36] <pross-au> its needs to get off the list and into the tree [10:51:41] <kshishkov> indeed [10:51:52] <kshishkov> but it involves complete rewrite [11:08:40] <ubitux> oh great, draw_text filter at least :) [11:11:03] <kshishkov> once I even made "running line" filter for MPlayer [11:15:00] <j-b> lu_zero: ping [12:02:34] <Compn> kshishkov : why didnt you post patch? [12:02:35] <Compn> :) [12:04:08] <kshishkov> Compn: was too lazy and considered it to be too insignificant [12:05:00] * elenril kicks committers [12:05:08] <elenril> wake up lazy british people [12:05:15] <elenril> patches are waiting [12:05:18] * Compn needs a video stabilization filter [12:05:32] <Compn> e.g. entire video jumps up/down 4 pixels or so due to bad vcr/vhs tape [12:06:36] <kshishkov> there was one somewhere [12:20:14] <Compn> i should use it :) [12:20:21] <Compn> i think i searched for them before [12:30:05] <cartman> mru: do you remember Beagleboard 2010 student, "maltanar" ? [12:30:37] <cartman> GSoC that is [12:30:53] <mru> name sounds familiar [12:31:00] <mru> forgot what he was working on [12:31:01] <cartman> Yaman Umuroglu [12:31:07] <kshishkov> POSIX for DSPEasy [12:31:08] <cartman> dsp something [12:31:10] <cartman> yeah [12:31:36] <cartman> He is my colleague from my current $COMPANY [12:31:49] <cartman> taught me how to pronounce your name :p [12:32:00] <thresh> 'kostya' is easy [12:32:11] <cartman> thresh: try mru's name :) [12:32:15] <kshishkov> thresh: you won't believe how many people get it wrong [12:32:21] <thresh> kshishkov: wouldnt I?.. [12:32:21] <mru> cartman: nothing hard about my name [12:32:22] <thresh> :) [12:32:29] <mru> most languages have the required sounds [12:32:31] <cartman> mru: the funny a is problematic [12:32:36] <spaam> cartman: how hard is it? :P [12:32:40] <cartman> sounds like an ou [12:32:48] <kshishkov> cartman: it $COMPANY==SuSE or some Turkish? [12:32:56] <cartman> kshishkov: Turkish one [12:33:04] <cartman> I told him to stay away from av500 of course [12:33:20] * kshishkov sees no problems pronouncing Måns, it's not like it has "skj" in it [12:33:20] <thresh> because he cant pronounce his name? [12:34:01] <cartman> for some other reasons :P [12:34:07] <spaam> kshishkov: can you say this: Sju sjösjuka sjömän sköttes av sju sköna sjuksköterskor [12:34:46] <mru> spaam: that's a good one [12:35:07] <kshishkov> spaam: I used this - http://slayradio.com/mastering_swedish_lesson_3.php [12:35:13] <cartman> lol @ google translate [12:35:26] <cartman> Seven seasick seamen were handled by seven beautiful nurses [12:35:28] <spaam> cartman: http://upload.wikimedia.org/wikipedia/commons/f/f9/Sv-sju_sj%C3%B6sjuka_sj%… if you want to listen to it ;) [12:35:57] <cartman> whoa [12:35:58] <cartman> tough one [12:37:16] <lu_zero> j-b: pong [12:37:38] <cartman> spaam: try "Bir berber bir berbere gel beraber bir berber dükkanı açalım demiş." in Google Translate, Turkish [12:38:07] <thresh> both those languages look like someone accidently smashed his keyboard. [12:38:52] <lu_zero> unpong [12:39:01] * lu_zero goes back to the meeting [12:39:03] <spaam> cartman: haha [12:39:18] <cartman> spaam: sounds weird ha :D [12:39:22] <spaam> yeah [12:40:55] <kshishkov> thresh: ну здравствуйте! [12:42:19] <kshishkov> thresh: ваши скороговорки вида "шел Лукашенко по шоссе" ничуть не лучше [12:52:56] <BBB> elenril: is the patch fine now? no more second thoughts? [12:56:06] <thresh> kshishkov: ты так говоришь "ваши"... [12:56:26] <kshishkov> thresh: а еще я сало ем [12:56:51] <thresh> kshishkov: в шоколаде? [12:57:05] <kshishkov> thresh: было дело [13:06:22] <elenril> BBB: i think so [13:06:39] <elenril> at least it compiles without any visible warnings :) [13:07:06] <mru> did you check for invisible warnings? [13:07:41] <mru> maybe they were printed in ultraviolet [13:07:58] * elenril tries grep --ultraviolet [13:11:07] <kshishkov> try grep --contractclauses next if warnings were printed in usual 0.000005pt font [13:25:36] <j-b> lu_zero: 1) did not got your mail. 2) libnemesis patch, YOU HAZ? [13:38:01] <Flameeyes> j-b: I think we're going to declare libnemesi completely dead in favour of libavformat's rtsp support ^^;; [13:38:41] <kshishkov> so FFmpeg is libnemesi's nemesis? [13:39:25] <j-b> Flameeyes: arf [13:41:40] <thresh> rofl [13:46:56] <Flameeyes> j-b: we're so swamped out that I'm now writing reports... and I hate writing reports [13:48:01] <j-b> Flameeyes: :'( [14:08:24] <Tjoppen> it seems someone broke muxing ts to a pipe [14:13:42] <Tjoppen> somewhere between today and two months ago.. git-bisect shall deduce whom [14:19:53] <Tjoppen> my fault, forgot -y [14:21:05] <spaam> Tjoppen: fail [14:29:40] <spaam> mru: what do you say about http://www.linaro.org/snowball-announcement/ ? :D [14:30:24] <spaam> good shit? [14:31:14] <mru> I'm not that impressed [14:31:30] <kshishkov> it looks smaller than Panda [14:31:47] <mru> cheap board is good, but it doesn't end there [14:31:49] <BBB> elenril: gotta go now, will apply patches [14:32:07] <mru> I expect they'll release a single, old, ugly kernel patch that barely works [14:32:11] <mru> and that'll be it [14:32:21] <mru> or worse, and sdk [14:32:24] <mru> *an [14:32:54] <mru> and of course no trm [14:35:42] <cartman> trm? [14:35:53] <mru> technical reference manual [14:35:56] <cartman> ah :) [14:56:24] <lu_zero> http://bbrv.blogspot.com/2011/02/95-smarttop.html [14:56:39] <lu_zero> cheap and more or less well supported kernel wise =P [14:56:43] <lu_zero> </plug> [14:58:15] <kshishkov> and I'd say partially Luca-supported too! [14:59:57] <lu_zero> that means that you can blame me if something breaks ^^; [15:00:08] <kshishkov> nope, I'll just run to you for help [15:00:17] * kshishkov mostly blames Freescale [15:00:48] <kshishkov> though it's still A8, A9-based system would be much nicer [15:01:44] <mru> A8 is faster for some things [15:01:52] <lu_zero> kshishkov: imx53 looks nicer but still a8 [15:03:44] <kshishkov> mru: it's just more about being dual-core [15:04:21] <mru> better make sure your apps are multi-threaded then [15:05:01] <kshishkov> but you can run two of them! [15:09:33] <CIA-15> ffmpeg: Jean-Daniel Dupas <jd.dupas(a)ninsight.com> master * r351423ae1f ffmpeg/libavcodec/targa.c: [15:09:34] <CIA-15> ffmpeg: targa: fix potential buffer overreads [15:09:34] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [15:11:33] <mru> elenril: ping [15:20:25] <lu_zero> j-b: ping [15:22:19] <elenril> mru: pong [15:23:12] <mru> elenril: would you mind taking a look at patchwork to see if any of your patches there need to have their status updated? [15:24:26] <elenril> http://patches.ffmpeg.org/patch/1133/ and http://patches.ffmpeg.org/patch/1130/ are obsolete [15:24:48] <mru> mind updating them? [15:25:19] <elenril> i have to register for that, right? [15:25:46] <mru> yeah [15:25:59] <mru> and have jannau give the right permissions [15:26:43] <jannau> you should be able to change the status of your own patches if you register with the same mail address [15:32:56] <elenril> what does archiving do? [15:33:30] <mru> sets the archive flag, whatever that means [16:20:54] <uau> another issue with the lavf avi demuxer: seeks without index won't go to video keyframes [16:22:30] <bilboed-tp> anyone has a list of rtmp urls to test ? [16:23:15] <Compn> bilboed-tp : you dont like the ones on the wiki ? [16:23:24] * bilboed-tp facepalms [16:23:26] <bilboed-tp> thanks :) [16:23:34] <mru> uau: how would you find key frames in avi without index? [16:25:47] <uau> mru: i've never looked at the details of avi, but mplayer's old internal demuxer seems to be able to build a working index [16:25:52] <uau> i'll see what it does [16:25:59] <mru> probably parses the video data [16:26:04] <mru> there's no other way [16:26:22] <mru> the key frame flag is only in the index [16:26:41] <mru> my personal favourite is avi files where packets and index disagree [16:27:36] <uau> it does have this comment at least // Fix keyframes for DivX files: [16:27:42] <uau> so could be specific to mpeg4 [16:27:58] <mru> the packet header in avi has only stream number and size [16:30:44] <mru> "unreasonable forms of switch (e.g. Duff's device)" [16:32:32] <uau> the relatively simple special case (selecting mode based on fourcc, and a couple of lines to parse data) seems to work pretty well in practice though [16:32:44] <uau> as mpeg4 is the most common codec for avi [16:34:19] <mru> of course it does [17:20:54] <j-b> lu_zero: ? [17:23:02] <lu_zero> diego told me to ping you [17:58:00] <kierank> why is av_url_split not in libavutil? [17:59:27] <elenril> because you didn't move it there [17:59:40] <kierank> k [18:01:35] * kierank moves it there [18:03:35] <elenril> inb4 i get a gazillion conflicts [18:03:42] * elenril pokes BBB [18:03:58] <BBB> kkk [18:04:06] <BBB> let me have lunch for a sec [18:04:10] <BBB> I will commit it, patch is fine [18:04:13] <BBB> just need time to test :-p [18:04:38] <elenril> lunch is a good idea [18:04:45] * elenril greps house for food [18:08:45] <kierank> elenril: remember internet connected fridges [18:08:54] <kierank> dotcom bubble ftw [18:11:16] <kierank> erm what do I do with FF_API_URL_SPLIT [18:12:46] <elenril> ? [18:13:10] <kierank> there's some old attribute_deprecated void ff_url_split lying around [18:14:11] <elenril> make FF_API_URL_SPLIT_2? [18:14:12] <elenril> or something [18:14:19] <elenril> why do you want it in lavu anyway? [18:15:19] <kierank> so I can use it for url parsing without having to include lavf [18:19:36] * kierank is drinking the lavu kool-aid [18:23:48] <elenril> anybody against removing url_fgets()? [18:23:52] <elenril> it's not used anywhere [18:24:18] <mru> is it considered public? [18:24:30] <elenril> it's in avio, so i guess yes [18:30:00] <elenril> err....why is url_fprintf under CONFIG_MUXERS? [18:37:02] <kierank> dammit yahoo mail, hurry up and send my mail [18:46:09] <_av500_> yahoo still exists? [18:46:30] <kshishkov> you mean M$ Bing frontend? [18:46:40] <kierank> yeah, for $1.99 domain names they still exist [18:47:26] <_av500_> per year? [18:47:33] <kierank> yes [18:47:47] <kierank> or maybe for one year [18:47:54] <kierank> still a good deal nonetheless [19:30:17] <BBB> lu_zero: related to the URLContext.slave thing, is that a good idea? [19:30:40] <BBB> lu_zero: we used to have this get_file_handle() thing, which didn't work at all with rtp, because rtp has two file handles, and rtsp has even more [19:30:50] <BBB> lu_zero: when desining this, we want to make sure it fits in with rtsp also [19:31:31] <BBB> maybe it works [19:31:35] <BBB> haven't quite checked it out yet [19:31:40] <BBB> just mentioning we should keep it in mind [19:35:58] <Flameeyes> mpeg4 part 12 is iso media, right? [19:36:12] <mru> yes [19:36:24] <Flameeyes> thanks [19:36:27] <lu_zero> BBB: uhm [19:36:36] <lu_zero> right now I'm a funny issue with the protocols [19:36:43] <lu_zero> I'm trying to complete sctp [19:36:49] <lu_zero> to add it to our rtp/rtsp [19:37:10] <kierank> lu_zero: people use sctp? [19:37:15] <Flameeyes> kierank: no. [19:37:28] <Flameeyes> lu_zero: I'd sincerely redesign it from scratch if you gave me a bit more time :) [19:37:46] <lu_zero> kierank: some [19:37:48] <Flameeyes> unless of course you _need_ it ... [19:37:53] <lu_zero> Flameeyes: redesign how? [19:37:59] <lu_zero> and what? [19:38:06] <Flameeyes> lu_zero: let it be usable as seqpacket rather than only as a stream [19:38:09] <lu_zero> the protocol layer or the rtsp-sctp? [19:38:14] <Flameeyes> rtsp-sctp [19:38:16] <lu_zero> it _should_ =_= [19:38:31] <Flameeyes> no it cannot be used a seqpacket, we already discussed that [19:38:35] <mru> kierank: there's a patch from you sitting in the moderation queue... [19:38:44] <Flameeyes> for seqpacket you need to use it like it was udp, not like it was tcp [19:38:52] <lu_zero> yup [19:39:06] <Flameeyes> our current implementation in feng will only work as a stream; sure it keeps the multiqueue, sure it keeps sack, sure it makes a lot of sense already but it doesn't use seqpacket [19:39:36] <kierank> mru: yeah, had to send it from another email address and forgot that it wasn't subscribed [19:39:53] <mru> so it didn't get through yet? [19:40:25] <kierank> mru: dunno what happened to the first one i sent from my normal email address [19:40:40] <mru> ok, approved now [19:40:58] <kierank> thanks [19:41:02] <lu_zero> Flameeyes: so it's our implementation mimiking too much tcp interleaved... [19:41:11] <Flameeyes> yah [19:41:27] <Flameeyes> right now we have a tcp interleaved on steroid.. not bad, but not great either [19:41:27] <lu_zero> (not that the way I'm trying to implement sctp in ffmpeg is that different... [19:42:01] <lu_zero> and even there we have some stream-even-when-we-have-packets issue ^^; [19:42:07] <kierank> lu_zero: can feng do rtsp vod? someone was asking me the other day [19:43:45] <lu_zero> kierank: yup [21:20:59] <saintd3v> BBB: ping [21:31:14] <BBB> pong [21:32:50] <BBB> saintd3v: privmsg me, gotta run [21:32:59] <saintd3v> was going to anyway =P [21:43:50] <ruggles> hmm. it seems there is a file in the fate suite that isn't actually tested. [21:43:59] <ruggles> /iff/8svx_fib.iff [21:46:35] <kierank> lol iff [22:41:32] <Sean_McG> it's Friday! [22:41:38] <Sean_McG> and almost beer o'clock [22:42:02] <CIA-15> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r902685b8ab ffmpeg/libavcodec/vp3.c: [22:42:02] <CIA-15> ffmpeg: VP3: fix decoding of videos with stride > 2048 [22:42:02] <CIA-15> ffmpeg: Also remove qscale_table code; this didn't make sense anyways as VP3 doesn't [22:42:02] <CIA-15> ffmpeg: use an MPEG-like quantizer scale. [22:57:20] <kierank> mru: what happened to that tomi cpu? [22:57:56] <ruggles> in case this is useful to anyone: http://ffmpeg.pastebin.com/fGaRYVLF [23:28:34] <Sean_McG> mru: those odd characters in FATE reports can be fixed if you export LANG=C and LC_*=C in fate.sh [23:29:36] <Sean_McG> mru: gcc doesn't seem to like 'en_CA.UTF8' [23:34:58] <BBB> Dark_Shikari: let's discuss here then [23:35:17] <BBB> Dark_Shikari: so I want to add a fixed value to each dc/ac coeff, like (for int i=0;i<64;i++)block[i]+=1; [23:35:29] <BBB> Dark_Shikari: that should be easy, like adding 1 to the block[0] before idct [23:35:33] <Dark_Shikari> yes [23:35:38] <BBB> Dark_Shikari: but that doesn't add exactly 1 to each [23:35:47] <BBB> rather, it usually adds one, sometimes zero and sometimes two [23:35:48] <BBB> why? [23:36:00] <BBB> (vc1 idct, not h264 idct, in case you're wondering) [23:36:42] <bcoudurier> init last dc to some value [23:36:48] <Dark_Shikari> BBB: dither? [23:36:57] <BBB> (also, it's not actually 1:1, it's more like adding 0x100 to each after idct == adding 0x380 before idct, I guess that's scaling? [23:37:24] <iive> 2048->256 ? [23:38:06] <bcoudurier> Init last dc to 1024 for i += 128 [23:39:57] <BBB> I thought block[0] is the dc and the rest is ac? [23:40:20] <BBB> so which is the "last" dc? [23:40:36] <astrange> last dc = previous dc [23:40:47] <astrange> used in dc prediction [23:41:21] <BBB> oh [23:43:39] <BBB> but doesn't do the same thing as (just before, or even in the idct) doing block[0] += somevalue;? [23:45:26] <bcoudurier> well it's faster, even if it's the same [23:46:07] <BBB> right, but my problem is that it dithers (or something like that) :( [23:46:09] <bcoudurier> ie dc is init at the beginning of each row, although it might be different for vc1 [23:46:59] <bcoudurier> anyway if the vc1 decoder do it this way, there might be a reason [23:49:49] <iive> BBB: i didn't quite get what are you doing, why, what result do you expect instead. [23:50:46] <BBB> vc1 decoder does this: read DCT'ed coeffs from bitstream, run idct, then for (i=0;i<64;i++) block[i] += 128; (or 64, or whatever, sometimes with an if, depending on which part of the decoder you look at) [23:51:07] <BBB> I was wondering if you could do this without the loop by adding 128 or 64 under that "whatever if" to block[0] before idct [23:51:10] <BBB> so you get rid of the loop [23:51:21] <BBB> but that changes the post-idct coeffs slightly, i.e. the dithering [23:51:33] <BBB> most have 128 added, but some 127, some 129 [23:51:38] <bcoudurier> well the dnxhd decoder does it like I told you [23:51:40] <bcoudurier> and it works [23:51:48] <bcoudurier> dnxhd is mpeg2 basically [23:51:51] <BBB> vc1 is probably weird ... [23:51:58] <bcoudurier> I don't know what vc1 does, but something funky is happening [23:52:03] <BBB> yeah [23:53:15] <Yuvi> add/put_pixels_signed vs. unsigned? [23:54:48] <BBB> Yuvi: that's what it looks like, yes [23:57:05] <Yuvi> do that then I think, either merge it w/ the idct as idct_add/idct_add_signed or keep it separate and change a local put_pixels pointer [23:57:36] <Dark_Shikari> not merging -> slower

1 0