Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2010

1 participants
30 discussions

IRC log for 2010-04-19
by irc＠mansr.com 20 Apr '10

20 Apr '10

[05:36:57] <thresh> moroning [07:25:07] <av500> m0rn1ng [07:26:45] <KotH> 3n \/\/ud3R5C|-|ÖN3 6U373 |\/|0R63 [07:27:41] * elenril drops a 1337 h4>< on KotH [07:28:18] <elenril> also morning/learn2utf8 [07:29:47] <KotH> you mean utf1337 [07:31:51] <KotH> but tell me, how is life in lazyland? [07:33:12] <elenril> life is :effort: [07:38:51] <pJok> *gasp* no kostoya! [07:42:31] <KotH> pJok: but at least a knoppix user :) [07:46:32] <pJok> KotH, you say that like its a good thing ;) [07:48:38] <KotH> pJok: we could have suse users here ;) [07:49:45] <scaphilo> anyone has an idea where i have to look for a mistake in my encoder when i get toe following errors [mpeg4 @ 0xa0790b0]Error at MB: 0 [07:49:45] <scaphilo> [mpeg4 @ 0xa0790b0]concealing 1200 DC, 1200 AC, 1200 MV errors playing the video in ffplay? [07:51:23] <astrange> break on fprintf in gdb and wait until you get to that error [07:51:29] <astrange> (or just search for the error string) [07:52:46] <pJok> KotH, or worse... Slackware ;) [07:55:53] <KotH> pJok: slack isnt that bad... at least you know that you have a masochist there [08:11:11] <pJok> KotH, i thought the masochists used gentoo ;) [08:12:28] <KotH> nah.. those are just wannabes :) [08:12:40] <elenril> gentoo is for ricers ;) [08:13:18] <KotH> though, true masochists work with win3.11 :) [08:13:41] <peloverde> When I used gentoo I didn't have enough RAM to compile OO.o the situation was... suboptimal [08:14:58] <twnqx> you don't compile ooo, you use the -bin [08:15:13] * bilboed-pi guesses the topic was gentoo :) [08:15:37] <twnqx> congratulations, you just won an inflatable washing machine! [08:15:40] <bilboed-pi> w00t [08:16:19] <bilboed-pi> USE="washable inflatable" emerge electric-appliance/washing-machine [08:17:15] <elenril> you forgot omg-optimized [08:17:27] <bilboed-pi> nah, already defined in /etc/make.conf [08:18:17] * superdump is an ex-gentoo user [08:18:44] * twnqx uses gentoo for about 8 years now [08:19:05] * elenril wonders if there's something like oo.o viewer that eats less ram [08:19:05] * pJok uses what ever he finds practical to use [08:19:31] <pJok> so far it seems like xp, win7, vista, os x, freebsd and debian are the candidates to that [08:19:50] <superdump> vista? [08:20:03] <superdump> windows? [08:21:18] <peloverde> vista is just win7 without a few ui tweaks, most of the vista problems (that weren't already a problem in windows) comes from shoddy third party apps, by the time 7 came out they had all been fixed due to vista [08:21:19] <pJok> yeah [08:21:40] <pJok> i find vista friendly and useable [08:22:54] <astrange> the ui design feels like a shotgun approach where they stick random links to everything in every open window [08:22:57] <astrange> but it's tolerable [08:23:24] <astrange> the default color scheme is still very ugly and the control panels still insist on displaying technical nonsense to you [08:23:26] <Dark_Shikari> they changed every control panel for no good reason [08:23:31] <astrange> like where in physical memory your keyboard is mapped [08:23:32] <Dark_Shikari> and made them much more complex [08:26:38] <peloverde> These days I use win7 for games, syncing my phone, and making PDFs of MPEG documents, and Ubuntu for everything else [08:29:46] <superdump> i haven't really used windows for years now and i used to use it day-in day-out [08:30:55] <peloverde> I had a job where I had to use windows, thank god for cygwin [08:55:01] <twnqx> heh [08:55:10] <twnqx> i just encountered an FLV4 in .mkv file [08:55:18] <twnqx> [matroska @ 0x63b3d0]Unknown/unsupported CodecID V_MS/VFW/FOURCC. [08:55:19] <twnqx> :P [08:55:27] <Dark_Shikari> patches welcome [08:55:32] <twnqx> (however, track identification succeeds) [09:12:00] <twnqx> libavcodec/motion_est.c:1522: warning: large integer implicitly truncated to unsigned type <-- never saw that type of warning before [09:12:40] <Dark_Shikari> gcc 4.5? [09:13:08] <twnqx> 4.4.3 [09:13:41] <twnqx> hm, something breaks with x264 on my sys [09:13:45] <twnqx> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libx264.so.85, needed by /home/charlie/Projects/ffmpeg/trunk/libavcodec/libavcodec.so, not found (try using -rpath or -rpath-link) [09:14:04] <Dark_Shikari> old x264 >_> [09:14:10] <twnqx> however, i have 92 installed... only. [09:14:21] <twnqx> so why does it even look for 85 [09:14:35] <Dark_Shikari> because you have an old version linked [09:14:42] <twnqx> mh [09:14:43] <Dark_Shikari> isn't linux linking great? [09:14:59] <twnqx> but where would that old linking come from? :S [09:15:12] <Dark_Shikari> your new x264 being in /usr/local [09:15:15] <Dark_Shikari> and the old one being in /usr/ [09:15:19] <Dark_Shikari> and ld.so.conf not having local in it [09:15:20] <twnqx> nope, new one in /usr [09:15:21] <Dark_Shikari> because your distro is shit [09:16:01] * twnqx runs the dependency checker [09:18:07] <twnqx> ld.so.cache contains .92 too [09:18:40] <twnqx> how do i get the full calls, make V=1? [09:19:55] * twnqx bets on "error: no make clean performed" [09:20:19] <twnqx> it's more an issue of borked dependency tracking [09:20:56] <twnqx> like, with the old .so around in the build dir it doesn't realise that one needs to be updated before linking against it [09:32:16] <pJok> hmm... ffthreads? [09:34:14] <twnqx> is there a macro to print a fourcc? [09:35:58] <twnqx> well... after lunch. [09:36:21] <av500> %.4s? [09:57:04] <twnqx> hm... right, that wouldn't require the 0 [09:57:11] <twnqx> need to program more. [10:02:34] <twnqx> right... will fourcc additions based on "encountered in the wild" be accepted? [10:03:47] <Dark_Shikari> https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/357218 [10:04:21] <astrange> i forget if ffmpeg accepts any old fourcc [10:04:23] <astrange> mplayer does [10:04:26] <astrange> compn would know [10:05:11] <twnqx> lol [10:05:26] <twnqx> (@ D_S'S link) [10:05:46] <twnqx> is FLV4 old? [10:06:18] <Dark_Shikari> it's vp6 [10:06:24] <Dark_Shikari> and yes it's old [10:08:17] * twnqx is confused [10:08:41] <twnqx> so if i wanted to add a 4CC, which CODEC_ID would i have to link it to? CODEC_ID_VP6? [10:08:47] <Dark_Shikari> vp6f probably [10:11:02] <twnqx> lol [10:11:09] <twnqx> i was starting the file in ffplay [10:11:13] <twnqx> and thought "WTF?" [10:11:27] <twnqx> until i realized it just shows a FFT of the audio >_> [10:13:14] <twnqx> well, mplayer uses vp6f, indeed. [10:15:55] <twnqx> and now ffplay plays it as well :) [11:15:01] <Compn> twnqx : i think a few of those files with incorrect fourccs were created with mencoder :P [11:15:17] <Compn> like ovc copy vp6 flv to avi or something dumb [11:15:33] <twnqx> possible, since this is a webrip [11:16:28] <Compn> if its some fourcc combo which wont be another one (like flv4 in avi) then i think its fine to map it in ffmpeg :) [11:16:36] <Compn> wont be another codec* [11:19:16] <twnqx> well, posted the oneliner to the mailing list [11:41:34] <CIA-81> ffmpeg: lu_zero * r22906 /trunk/libavformat/ (rtpdec.h rtpproto.c): Make rtp protocol obey rfc3550 [11:42:54] <CIA-81> ffmpeg: lu_zero * r22907 /trunk/ffserver.c: Make ffserver support rfc3550 [11:52:36] <CIA-81> ffmpeg: mru * r22908 /trunk/tests/ref/fate/nsv-demux: FATE: update nsv-demux checksums [12:50:43] <CIA-81> ffmpeg: mru * r22909 /trunk/configure: configure: simplify vdpau dependencies [12:50:43] <CIA-81> ffmpeg: mru * r22910 /trunk/configure: configure: simplify vaapi dependencies [12:50:44] <CIA-81> ffmpeg: mru * r22911 /trunk/configure: [12:50:44] <CIA-81> ffmpeg: configure: simplify $COMPONENT_LIST handling [12:50:44] <CIA-81> ffmpeg: This lets check_deps set the generic CONFIG_ENCODERS and friends using [12:50:44] <CIA-81> ffmpeg: an _if_any construct. [13:00:32] <Vitor1001> mru: ping [13:01:12] <mru> pong [13:01:28] <Vitor1001> Can you review this one-liner patch: http://ffmpeg.pastebin.ca/1867769 [13:01:36] <merbzt> mru: what do you use to play video on your nexus ? [13:01:49] <mru> merbzt: I haven't found anything good [13:01:53] <merbzt> :) [13:02:01] <merbzt> miserable [13:02:08] <merbzt> got a htc desire [13:02:13] <mru> the builtin player is truly piss-poor [13:02:17] <Vitor1001> mru: To put some context: "make fate" simply fail if ffmpeg is not compiled [13:02:26] <merbzt> where can I find that one ? [13:02:31] <mru> Vitor1001: I figured as much [13:02:42] <mru> merbzt: find what? [13:03:00] <merbzt> the videoplayer app [13:03:15] <mru> it came installed on the nexus [13:03:26] <mru> lauches automatically if you try to open a video file [13:03:45] <Vitor1001> mru: err, I missed an $(EXESUF) [13:03:51] <mru> Vitor1001: yep, you did [13:04:01] <mru> Vitor1001: ok if you add that [13:04:11] <av500> merbzt: mru: port ffplay [13:04:24] <Vitor1001> mru: nice, will commit soon [13:04:40] <mru> thanks for the fix [13:05:23] <av500> merbzt: most android video player apps are just filebrowsers and use the builtin video view as display [13:05:33] <merbzt> yeah I noticed [13:06:10] <mru> coreplayer should become available eventually [13:06:15] <CIA-81> ffmpeg: vitor * r22912 /trunk/Makefile: Makefile: make fate target depend on compiling ffmpeg [16:07:58] <BBB> wbs: will quickly skim over the rtp/sync patch today, promise, but I remember it being ok so don't expect too much from me ;) [16:18:52] <wbs> BBB: good :-) [16:25:39] <BBB> is sumit or marcelo online here? [16:39:32] <BBB> or michael chinen or sebastian vater ("bastycdgs") maybe? [17:57:44] <BBB> merbzt: ping [17:58:06] <BBB> (or any derivative thereof) [17:58:28] <metbztt> Im here in reduced capacity [17:58:56] <av500> ash cloud? [17:59:21] <metbztt> Using an Android client [17:59:38] <BBB> lol :) [17:59:50] <metbztt> No traveling by boat [18:00:01] <wbs> where to? :-) [18:01:51] <metbztt> Estonia [18:02:13] <BBB> do you know jorn? [18:02:15] <av500> they have open airports? :) [18:02:48] <metbztt> Nooooo [18:03:24] <metbztt> They have not [18:05:16] <metbztt> Thats why i travel by boat [18:05:22] <av500> :) [18:05:26] <metbztt> :/ [18:05:44] <av500> final destination? [18:13:49] <mru> somewhere w/o ping apparently [18:14:16] <thresh> his boat went into ash cloud so he lost connectivity. [18:25:37] <mru> swScaler: rgb565le is not supported as input pixel format [18:25:44] <mru> FATE is reporting that on all big endian systems [18:35:33] <Dark_Shikari> mru: stop being intentionally retarded [18:35:42] <Dark_Shikari> your logic can be used to omit anything from ffmpeg by default [18:36:09] <Dark_Shikari> "For those who do not want or need swscale, enabling it by default will be an annoyance. Until you can make it read people's minds, it will always be wrong for someone." [18:36:09] <mru> Dark_Shikari: every time you use the word "retarded", I stop listening [18:36:15] <Dark_Shikari> "For those who do not want or need zlib, enabling it by default will be an annoyance. Until you can make it read people's minds, it will always be wrong for someone." [18:36:20] <Dark_Shikari> "For those who do not want or need libavformat, enabling it by default will be an annoyance. Until you can make it read people's minds, it will always be wrong for someone." [18:36:21] <mru> swscale is not optional [18:36:33] <Dark_Shikari> "For those who do not want or need h264, enabling it by default will be an annoyance. Until you can make it read people's minds, it will always be wrong for someone." [18:36:53] <mru> next time will be ban [18:37:27] <thresh> OP WARS [18:37:29] <Dark_Shikari> now stop it. [18:37:40] <mru> you started [18:37:44] <Dark_Shikari> mru: um... you kicked me first [18:37:47] <Dark_Shikari> how did I "start it"? [18:37:52] <mru> you called me retarded [18:37:54] <Dark_Shikari> thresh: nananananananananananana OP WARS [18:37:58] <mru> and started flooding crap [18:37:59] <Dark_Shikari> no I didn't. [18:38:02] <Dark_Shikari> I said you were being retarded. [18:38:05] <Dark_Shikari> Smart people can be retarded at times. [18:39:01] * iive thought retard is actual sickness. [18:39:12] <Dark_Shikari> Anyways, I was giving you examples of why your argument was stupid [18:39:22] <mru> no, you were flooding the channel with junk [18:39:23] <Dark_Shikari> reductio ad absurdum [18:39:32] <mru> you're suggesting we change the default in a radical way [18:39:32] <Dark_Shikari> yes, it's "junk" because it proves you wrong [18:39:36] <mru> fuck off [18:39:42] <Dark_Shikari> You yourself agreed ffmpeg defaults sucked. [18:39:47] <Dark_Shikari> And now when we go to change them, you object? [18:39:53] <Dark_Shikari> because it's better to keep shit defaults than to have to change things? [18:40:05] <mru> I agree default codec settings are bad [18:40:07] <Dark_Shikari> This is why ffmpeg is such shit. the devs constantly complain about things [18:40:12] <Dark_Shikari> but when it comes time to fix them [18:40:14] <Dark_Shikari> they refuse to let it happen [18:40:16] <mru> that doesn't extend to default configure settings [18:40:17] <Dark_Shikari> it isn't laziness [18:40:24] <Dark_Shikari> it's refusal to change [18:40:33] <mru> and I'm open to actual arguments for changing the default [18:40:35] <Dark_Shikari> Yes, the default configure settings are shit. [18:40:39] <Dark_Shikari> --enable-libx264 WILL FAIL BY DEFAULT. [18:40:46] <mru> but it has be something better than "I'm in the group that wants it on" [18:40:50] <Dark_Shikari> --enable-libx264 WILL FAIL BY DEFAULT. [18:40:54] <Dark_Shikari> that is a good enough argument [18:41:05] <mru> I could use that argument to say pthreads should be off by default in x264 [18:41:10] <Dark_Shikari> You don't control x264. [18:41:16] <mru> I can argue [18:41:19] <Dark_Shikari> the solution to a problem in ffmpeg cannot be "fix this system library" [18:41:28] <Dark_Shikari> ffmpeg has to adapt. [18:41:30] <mru> I control x264 exactly as much as you control ffmpeg [18:41:40] <mru> one silly lib can't dictate the defaults for everybody [18:41:46] <Dark_Shikari> Sure it can. [18:41:49] <Dark_Shikari> ffmpeg uses x264 [18:41:52] <Dark_Shikari> x264 can control what defaults ffmpeg uses [18:41:54] <Dark_Shikari> in fact, we DID [18:41:59] <Dark_Shikari> by making x264 refuse to open with ffmpeg's defaults [18:42:06] <Dark_Shikari> so your point is moot [18:42:19] <mru> that's x264 being anal, to use your language [18:42:25] <Dark_Shikari> It is not x264's responsibility to cater to every program that uses it. [18:42:30] <Dark_Shikari> ffmpeg is an exception. The only exception. [18:42:33] <Dark_Shikari> NOTHING ELSE has this problem. [18:42:40] <Dark_Shikari> upon hundreds of apps using x264 [18:42:48] <mru> besides, libx264 is off by default in ffmpeg [18:42:51] <Dark_Shikari> If we changed in reverse, we would break all those hundreds of apps [18:42:55] <Dark_Shikari> mru: --enable-X should enable X. [18:42:59] <Dark_Shikari> it should not cause a link error on build time. [18:43:00] <Dark_Shikari> Ever. [18:43:08] <Dark_Shikari> ffmpeg already has special-casing for dirac and schroedinger [18:43:09] <mru> that's your opinion [18:43:11] <Dark_Shikari> Why not x264? [18:43:21] <Dark_Shikari> Why is dirac better than x264? [18:43:28] <mru> I'd _remove_ dirac support in a heartbeat [18:43:37] <Dark_Shikari> And this is why you're not the maintainer. [18:43:46] <Dark_Shikari> stop talking about things that you hate. [18:43:47] <mru> not maintainer of what? [18:43:50] <Dark_Shikari> if you don't like it, don't talk about it. [18:43:55] <Dark_Shikari> you don't like dirac, you don't like x264 [18:44:05] <Dark_Shikari> so stop expressing opinions on how they should work [18:44:05] <mru> I _am_ maintainer of the configure script [18:44:07] <mru> deal with it [18:44:13] <Dark_Shikari> Then why haven't you removed dirac? [18:44:25] <mru> I don't really mind it being there [18:44:29] <mru> it's only a few lines [18:44:42] <mru> are you saying it auto-enables threads? [18:45:05] <mru> if that's true, diego must have done that when I wasn't watching [18:45:06] <Dark_Shikari> dirac uses pkg-config to auto-enable linking to all necessary libs [18:45:12] <mru> idiots [18:45:14] <Dark_Shikari> Why? [18:45:16] <Dark_Shikari> It makes it WORK [18:45:20] <Dark_Shikari> otherwise it doesn't WORK [18:45:20] <mru> it makes it FAIL [18:45:25] <Dark_Shikari> Currently it ALWAYS FAILS [18:45:25] <mru> ever tried to cross-compile? [18:45:27] <Dark_Shikari> x264 fails 100% of the time [18:45:31] <Dark_Shikari> not just in cross-compilation [18:45:31] <Dark_Shikari> 100% [18:45:41] <mru> works fine with shared libx264 [18:45:44] <Dark_Shikari> But shared isn't default. [18:45:49] <Dark_Shikari> As I said, in the _default case_ it fails. [18:46:05] <Dark_Shikari> Sure, you can munge it into working [18:46:07] <Dark_Shikari> but the default case should work. [18:46:10] <mru> default is no libx264 and no pthreads [18:46:13] <mru> that works fine [18:46:17] <Dark_Shikari> I meant default with x264 enabled. [18:46:22] <Dark_Shikari> come on you're being intentionally thick [18:46:24] <mru> that's no longer default [18:46:26] <Dark_Shikari> ...... [18:46:43] <mru> if you say "default with changes" you may as well not say default at all [18:47:06] <Dark_Shikari> ok, then I'll commit pkg-config support for x264. [18:47:12] <Dark_Shikari> You can disable it when cross-compiling if you want. [18:47:18] <Dark_Shikari> But it should at least run when you're not cross-compiling. [18:47:20] <Dark_Shikari> How about that? [18:47:27] <mru> you will do no such thing [18:47:29] <Dark_Shikari> Should be the same with dirac. [18:47:35] <Dark_Shikari> I'm not allowed to commit a fix for my own fucking library? [18:47:39] <mru> I will revert and remove your commit rights if you do [18:48:19] <Dark_Shikari> The fuck? [18:48:23] <mru> I could probably be persuaded to enable pthreads if x264 is enabled [18:48:30] <mru> but not by calling me a retard [18:48:31] <Dark_Shikari> dude, what the fuck? [18:48:42] <Dark_Shikari> I can't fix my own library, that I maintain? [18:48:44] <mru> I listen to logic, not insults [18:48:50] <Dark_Shikari> .... [18:48:53] <Dark_Shikari> I just gave you my logic [18:48:55] <Dark_Shikari> you ignored it completely [18:48:59] <Dark_Shikari> the only thing you have listened to is insults [18:49:00] <ohsix> he said the argument was [18:49:02] <mru> you maintain x264 [18:49:08] <mru> do whatever you want there [18:49:12] <mru> I maintain ffmpeg configure [18:49:15] <mru> you don't touch it [18:49:15] <Dark_Shikari> Yes, and I maintain x264 in fmfpeg [18:49:22] <mru> not configure [18:49:24] <Dark_Shikari> Yes I do. [18:49:27] <mru> no you don't [18:49:32] <Dark_Shikari> I maintain the x264 checks in configure. [18:49:38] <Dark_Shikari> I have updated them without approval in the past. [18:49:40] <mru> I'm warning you, touch and you lose commit rights [18:49:44] <Dark_Shikari> I will update them without approval in the future. [18:49:59] * BBB grabs popcorn [18:50:05] * dgt84 joins BBB [18:50:30] <iive> Dark_Shikari: make your changes, post them on the maillist, see what other developers think. [18:51:10] <BBB> uhm... that might not have been smart... [18:51:12] <iive> The project leader and majority of developers should be able to overturn maintainer decision, if it is unreasonable. [18:51:27] <Dark_Shikari> I don't give a fuck. mru doesn't want me in ffmpeg, so I'll leave. [18:52:08] <BBB> <Dark_Shikari> I don't give a fuck. mru doesn't want me in ffmpeg, so I'll leave. [18:52:25] <BBB> sometimes I wonder if it's his age... [18:52:33] <mru> I think it is [18:52:41] <mru> but that's no reason to go easy on him [18:53:27] <BBB> well this all was a little unnecessary, but I'll leave it to you 2 to fight it out [18:53:34] <thresh> what is he, 18? [18:53:44] <BBB> 19 right? [18:53:45] <mru> 20 [18:53:47] <BBB> maybe he's 20 now [18:53:49] <thresh> hmm [18:53:51] <mru> or maybe still 19 [18:53:56] <BBB> around there :) [18:54:09] <BBB> let's check facebook for his dob [18:54:13] <mru> he reminds me of myself at that age [18:55:41] <ohsix> http://en.wikipedia.org/wiki/Reductio_ad_absurdum ftw [18:56:19] <mru> it's great, but only when correctly applied [18:56:52] <ohsix> being arbitrary and capricious notwithstanding [18:57:14] <mru> I'm all for auto-enabling pthreads when libx264 needs it [18:57:25] <mru> but the patches posted so far did much more than that [18:57:29] <mru> and did so in an ugly way [19:06:18] <iive> then do it right, you seem to be the only one who could do it. [19:06:50] <Kovensky> <@mru> ever tried to cross-compile? <-- ffmpeg's configure does it wrong by hardcoding the pkg-config binary name [19:07:09] <mru> pkg-config is inherently broken for any kind of cross-compiling [19:07:09] <Kovensky> x264 and autotools look for $cross_prefix-pkg-config first [19:07:33] <mru> I've explained the problems many times [19:07:39] <mru> search the archives if you care [19:07:51] <iive> put it on your blog. [19:09:26] <Kovensky> <@mru> pkg-config is inherently broken for any kind of cross-compiling <-- it works just fine for me if I fix the configure to try $cross_prefix-pkg-config first, since I built a pkg-config with that prefix that looks only on /usr/local/$cross_prefix/lib/pkgconfig for libraries [19:09:51] <mru> maybe you're just lucky [19:09:54] <Kovensky> though I admit that pkg-config's build system is broken for having you give it three options to configure instead of just using --target [19:10:01] <mru> for many packages, it insists on adding -L/usr/lib to the flags [19:10:18] <Kovensky> no, that's only if it finds the /usr/lib/pkgconfig file before any other [19:10:42] <Kovensky> that's why you don't use PKG_CONFIG_PATH and instead make it only search on the cross-prefix [19:10:50] <mru> how do you do that? [19:11:07] <mru> I've tried setting PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR [19:11:13] * Kovensky gets pkg-config sources [19:11:18] <mru> and PKG_CONFIG_SYSROOT_DIR as someone suggested [19:11:22] <mru> nothing works [19:11:22] <Kovensky> as I said, you have to give some 2 or 3 parameters to pkg-config's configure to make a working one [19:11:51] <mru> besides, pkg-config is solving a non-problem [19:12:11] <Kovensky> it if wasn't a problem it wouldn't exist [19:12:28] <mru> there may be a problem, but pkg-config doesn't solve it [19:12:32] <mru> only rearranges it [19:12:46] <mru> the real problem is badly written libs [19:13:19] <Kovensky> duh, 2kB/s download... [19:15:59] <Kovensky> ./configure --program-prefix=$crossprefix- --with-pc-path=/usr/local/$crossprefix/lib/pkgconfig [19:16:08] <Kovensky> adjust with-pc-path to suit your system [19:16:43] <mru> that's insane [19:16:51] <Kovensky> you need one pkg-config per cross-prefix, and you can't use those env vars, but it works (as in only finds cross libs and doesn't find non-cross ones) [19:17:52] * Kovensky thinks it should have a --target that would automatically do --program-prefix=$target- --with-pc-path=$prefix/$target/lib/pkgconfig [19:18:06] <Kovensky> but alas, giving --target gives you an error [19:18:21] <_av500_> what is the point in compiling a pkgconfig per target? [19:18:33] <_av500_> or per cross prefix [19:19:28] <Kovensky> _av500_: so it doesn't find libraries from the wrong host [19:19:32] <ohsix> its like any other dep if you're gonna use it [19:19:51] <mru> but there's nothing target-specific in pkg-config [19:20:03] <mru> why can't it obey the environment variables? [19:20:05] <Kovensky> mru: no, that's why there's this hack [19:20:09] <_av500_> Kovensky: but why hard code that? [19:20:19] <_av500_> its like using a specific make for arm [19:20:25] <_av500_> and another one for x86 [19:20:25] <Kovensky> and autotools kind of supports the hack, by first looking in the path for $crossprefix-pkg-config [19:20:28] <mru> good analogy [19:20:33] <Kovensky> _av500_: well, think of it as a cross-pkg-config [19:20:38] <Kovensky> (it is) [19:20:43] <mru> THERE SHOULD BE NO NEED FOR TAHT [19:20:47] <ohsix> if make was looking for arch independent files in cross locations; you'd need to build make too :> [19:20:47] <Kovensky> just like you need a cross-linker instead of the system linker [19:21:05] <mru> make looks exactly where you tell it to [19:21:06] <Kovensky> well, it's broken, that's the workaround :V [19:21:09] <mru> why can't pkg-config do the same? [19:21:27] <mru> you need a cross-linker because the output format depends on the target [19:21:34] <Kovensky> ohsix: eh, it looks for arch dependent files outside the right arch folder [19:21:39] <mru> actually, you can configure gnu ld to support multiple targets [19:21:50] <Kovensky> mru: the libraries also depend on the target [19:21:55] <Kovensky> ew, multilib [19:21:58] <ohsix> Kovensky: ya, it'll look a bunch of places [19:22:16] <ohsix> its implicit that they're arch files but how they're searched is not [19:22:20] <mru> nothing pkg-config does depends on anything other than the input files [19:22:30] <mru> if it only looked for those in the places you tell it, there would be no problem [19:22:34] <mru> well, not that problem [19:22:40] <mru> all the other problems would remain [19:22:47] <_av500_> Kovensky > _av500_: well, think of it as a cross-pkg-config [19:23:21] <_av500_> Kovensky: i thought pkgconfig is supposed to be the one who thinks for me [19:23:47] <Kovensky> yes, it finds the library; the problem is that it doesn't know the arch of the .pc [19:23:51] <_av500_> and a e.g. PKGCONFIG_CROSS_PREFIX=foo is all i need [19:24:23] <Kovensky> pkg-config is also unmaintained, or at least pretends to be, since the last release is 2 years old [19:24:31] <Kovensky> though one could say the same of mplayer =p [19:24:42] <_av500_> mplayer has svn activity... [19:24:44] <ohsix> not often, but sometimes the arch changes the content of the .pc file as well; and they're not marked, so you put it in your prefix as a dep [19:24:59] <Kovensky> <_av500_> mplayer has svn activity... <-- svn != release [19:25:51] <mru> the .pc files for my cross-libs go in my cross-root [19:26:16] <Kovensky> mru: I know [19:26:26] <mru> if pkg-config had a simple --sysroot parameter or equivalent env var, there wouldn't be any conflict [19:26:39] <Kovensky> it's that pkg-config falls back to the non-cross-root ones if it doesn't find one on the cross-root, because some genius thought having that would be good [19:27:08] <ohsix> well there were a few places to store pc files; it has to look at them, thats the problem [19:27:18] <mru> so shoot that "genius" [19:27:35] <ohsix> it shouldn't look outside of the prefix when you cross though [19:27:46] <mru> if I say some dir is the sysroot, _nothing_ should make it look outside it [19:28:54] <Kovensky> anyway, the workaround is --with-pc-path, because apparently it's based on prefix not on sysroot [19:29:22] <mru> that's a compile-time hack [19:29:23] <Kovensky> or any other sane value [19:29:26] <mru> it shouldn't be required [19:29:33] <mru> we don't have a fucking cross-ls [19:31:32] <ohsix> sores seems to indicate if you set both _LIBDIR and _PATH, the other search paths aren't added to the lookup area [19:31:46] <_av500_> or better we dont compile the path that ls <path> shows into ls [19:32:37] <mru> oh well, I've managed to wrap it in enough scripts that it works [19:32:49] <mru> I'm not going to mess with it [19:32:55] <mru> I know it won't work anyway [19:33:00] * Kovensky also likes that compile-time hack because he's freed from having to set up env vars whenever he wants to cross-compile [19:33:02] <mru> I'll only waste time and get angry [19:33:16] <mru> I have scripts to set the env vars [19:33:32] <ohsix> it'll get top_builldir from automake too [19:35:00] <ohsix> and it looks like it heeds its own sysroot thing [19:35:33] <CIA-81> ffmpeg: darkshikari * r22913 /trunk/configure: Fix libx264 configure check to use pkg-config if available. [19:35:46] <mru> ok, that's it [19:35:48] <mru> I warned him [19:36:15] <ohsix> was just looking at the source to see if it puts arch specific stuff in pkg-config itself, for weird targets; but theres like nothing to it, except the bundled glib :> [19:37:09] <ohsix> Kovensky: did you grab the source? getenv invocations in main.c, were those the variables you wanted to not set on every cross build? [19:37:32] <Kovensky> ohsix: I never read the source [19:38:03] <ohsix> oic, theres nothing to it; its got a sysroot definition that it uses for building lookup paths in pkg.c; if you feel like trying it out [19:38:05] <Kovensky> but having $cross-pkg-config already do the "right thing" is less effort than having to set env vars on my shell and then being stuck on cross-compiling mode [19:38:13] <ohsix> right [19:38:20] <CIA-81> ffmpeg: mru * r22914 /trunk/configure: [19:38:20] <CIA-81> ffmpeg: Revert "Fix libx264 configure check to use pkg-config if available." [19:38:20] <CIA-81> ffmpeg: This was done out of pure spite. Commit rights revoked. [19:38:44] <ohsix> most people have other cross stuff they put in a script; or come from a tinderbox script that already does it for them [19:39:14] <_av500_> Kovensky: your env vars will come from some top level make anyway, no? [19:39:17] <ohsix> mru: did you check and see if he'd actually updated it in the past without fanfare? [19:39:23] <Kovensky> nope [19:40:15] <mru> ohsix: never without a discussion [19:40:18] <Kovensky> on autotools, './configure --host=$cross --prefix=/usr/local/$cross' always does the right thing with the $cross-pkg-config, without having to touch any environment or $PATH or anything at all [19:40:27] <mru> and never anything he *knew* was controversial [19:40:56] <ohsix> heh controversial; most people dont' hate autotools :P [19:41:14] <ohsix> well, hate is the wrong word, everyone hates autotools; but they get by [19:43:20] <_av500_> Kovensky: just as much as it could call pkgconfig --cross=$cross ... [19:44:37] <ohsix> _av500_: GNU has a bunch of rules for doing cross compiles; its pretty complex and only implicitly documented :[ (host triplets and macros hooray) [19:46:16] <mru> and their naming only makes sense for building compilers [19:46:37] <ohsix> which you typically do for a new target [19:46:41] <mru> and then only a little [19:46:52] <ohsix> it brings in the gloss in the libc and junk too [19:46:53] <mru> most things I build are not compilers [19:47:18] <ohsix> heh; that doesn't mean when you build a toolchain it should all change :P [19:48:57] <pJok> ffcc *coughs* [19:57:02] <BastyCDGS> a wonderful evening to all :) [19:57:29] <BBB> hey there [19:57:42] <BastyCDGS> how are u? [19:57:45] <BBB> I was going to ask, how's the qualification task and your familiarity with the project's code going? [19:58:14] <BastyCDGS> pretty well have just finished converting the c++ header file of iffanim to standard c [19:58:23] <BastyCDGS> just waiting for saste reviewing it [19:58:57] <BBB> why would you convert it? [19:59:02] <BBB> does it contain useful tables? [19:59:05] <BastyCDGS> because it's c++ [19:59:09] <BastyCDGS> and thus a class [19:59:48] <BastyCDGS> i thought it's useful just do a naive conservation and then optimizing unnecessary stuff out [20:01:15] <BBB> I guess that's one way [20:01:18] <BBB> is the license compatible? [20:01:23] <BastyCDGS> LGPL [20:01:27] <BBB> oh ok then it's fine [20:01:52] <wbs> BastyCDGS: is the author somebody else than you? did you keep the copyright statements for those code parts? [20:01:55] <BastyCDGS> just a bit sad that jason wants to leave ffmpeg devel team [20:02:13] <BBB> he'll come back [20:02:28] <saste> BastyCDGS: hi sebastian [20:02:29] <BBB> yeah make sure you keep copyright lines intact, it's good for tracking stuff back where relevant [20:02:30] <BastyCDGS> I was admitting him to just take a sleep about all this [20:02:38] <BastyCDGS> hey saste, nice to meet you! :) [20:03:07] <saste> saste: well it's nice to me too :-) [20:03:08] <BastyCDGS> so you had a nice work today? [20:03:36] <saste> work is work... sometimes is nice sometimes not [20:03:43] <BBB> this is getting like the housewives of orange county tv show [20:03:45] <BastyCDGS> I'm trying to convince jason to stay within the ffmpeg team if you haven't noticed the argue already [20:03:53] <saste> BBB: lol [20:04:05] <BastyCDGS> :D [20:04:20] <BBB> BastyCDGS: best thing to do is to stop the argument, and not reply to them... they'll stop, I'm hoping mru will stop emailing and tomorrow most of this will be forgotten [20:04:27] <mru> this isn't the first time he's stomped out and slammed the door [20:04:28] <BBB> taking the argument public gets worse with every new reply [20:04:33] <mru> as I said, he's an angry teenager [20:04:43] <BBB> as mru says, it happens occasionally [20:04:53] <BBB> he (jason)'s a little young [20:05:23] <BastyCDGS> well I'm not long here enough to really have an overview of this, but there's always a solution... [20:05:47] <BastyCDGS> we've probably been all a bit weird when we were young...right? [20:06:08] <BBB> yup [20:06:28] <BBB> just, most young kids smoke pod or drink beer. oddly, jason does neither of those two [20:06:43] <BBB> instead, he's this brilliant asm coder with a slightly short temper :) [20:07:36] <BastyCDGS> sometimes the ego just gets too much power... [20:07:59] <BastyCDGS> saste, have you checked my stuff I sent you? [20:08:23] <jai> hmm [20:08:28] <jai> hello BBB [20:08:31] <mru> hi jai [20:08:42] <jai> BBB: sorry, i was afk for a long while [20:08:47] <jai> hi there mru [20:08:50] <BastyCDGS> hey jai [20:09:14] <jai> hello BastyCDGS :) [20:09:40] <jai> BastyCDGS: you are working on the module playback stuff right? [20:10:09] <BastyCDGS> yes when I have finished the qualification task [20:11:05] <jai> cool, keep at it :) [20:11:35] <BBB> jai: that's ok [20:11:45] <BBB> jai: so I see you're popular today ;) [20:11:52] <pJok> evenings jai [20:12:33] <BastyCDGS> jai, I finished the header file (converted from the iffanim.h C++) [20:12:41] <BastyCDGS> removing all this class stuff [20:13:01] <jai> BastyCDGS: ah, that's some old crufty code [20:13:10] <jai> good evening pJok :) [20:13:38] <jai> BBB: it would seem so, though i havent thought about gsoc for the past week :| [20:13:54] <jai> BBB: i guess i better get back to that [20:13:57] <BastyCDGS> i have converted protected methods to static functions [20:14:01] <BastyCDGS> and public to normal functions [20:14:17] <BBB> jai: well you still have some time [20:14:20] <jai> BastyCDGS: btw, which packing mode are you working on? [20:14:22] <BastyCDGS> heyho pJok [20:14:41] <_av500_> BastyCDGS: and "this" to "that"? [20:14:45] <pJok> hola BastyCDGS [20:15:02] <BastyCDGS> lol [20:15:24] <BastyCDGS> IFF-ANIM has more packing modes [20:15:38] <BastyCDGS> but I just finished the header file, wanted to hear saste's comments in this first before I go on [20:15:48] <BBB> BastyCDGS: I think the deeper meaning of converting it is to see what the code actually does... for a simple format as iff-anim, each packing mode should be relatively simple and you could probably rewrite it in <100 lines of C code [20:16:45] <jai> i agree with BBB [20:16:50] <BastyCDGS> yes it's mostly delta compression [20:16:56] <jai> the unpacking code is what we are interested in [20:17:00] <mru> start with the simplest mode first [20:17:11] <mru> then add the others one at a time [20:17:34] <BastyCDGS> I'm just figuring out how to use the ffmpeg framework for this [20:17:43] <BastyCDGS> should I use url_fopen etc. [20:18:44] <BastyCDGS> mru, a small question, was I right with my assumptation that you didn't want x264 as default because of the patent issues? [20:19:25] <mru> no [20:19:28] <mru> I don't care about patents [20:19:42] <mru> ffmpeg policy is to not enable external libs by default [20:19:54] <BBB> BastyCDGS: a demuxer (which I think already exists) would do the right thing for file opening already [20:20:04] <BBB> BastyCDGS: your decoder would receive one packet at a time in its decode function [20:20:12] <BBB> that's the AVPacket *data argument [20:20:31] <BBB> see other simple decoders, e.g. other iff decoders [20:20:57] <BastyCDGS> there is an iff demuxer already yes [20:21:20] <BastyCDGS> but only for IFF-ILBM images, but after all IFF-ANIM is just a series of IFF-ILBMs with delta compression [20:22:47] <BastyCDGS> mru, i don't care too...since here in belgium there's not such crazy stuff [20:23:07] <BastyCDGS> hope this stays so and US will stop this soon, too [20:26:01] <BastyCDGS> btw [20:26:02] <BastyCDGS> http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto [20:26:05] <BastyCDGS> this is out of date [20:26:15] <BastyCDGS> e.g. [20:26:17] <BastyCDGS> libavcodec/allcodecs.c [20:26:20] <BastyCDGS> is now: [20:27:04] <BastyCDGS> libavcodec/allformats.c [20:27:20] <BBB> not in my checkout? [20:27:28] <BBB> $ ls libavcodec/all*.c [20:27:29] <BBB> libavcodec/allcodecs.c [20:27:32] <BastyCDGS> it's in my latest svn [20:27:38] <BBB> libavformat/allformats.c [20:27:39] <BastyCDGS> and i haven't the other file at all [20:27:51] <BBB> are you in libavformat/? [20:27:53] <BastyCDGS> yes [20:28:00] <BBB> go back, enter libavcodec/ [20:28:16] <BastyCDGS> seems someone removed it from SVN before I did the first checkout [20:28:46] <BBB> cd .. [20:28:47] <BBB> cd libavcodec/ [20:28:51] <BBB> ls all*.c [20:28:55] <BBB> try that [20:29:31] <BastyCDGS> oops you're right, nuff said ;) [20:29:43] <BBB> :) [20:30:16] <BastyCDGS> was probably changing there because of looking into rm.c [20:30:21] <BastyCDGS> and just forgot to change back [20:30:23] <BastyCDGS> sorry [20:31:08] <BBB> ok, so if iff/anim is just a delta compression format, you should be able to reuse most functions from iff/ilbm [20:32:08] <BastyCDGS> different delta compressions but they're pretty similar from what I've seen yet [20:35:05] <BastyCDGS> btw, when i have finished iff-anim can i do then the other stuff we discussed last time here? [20:35:10] <jai> yes, you just need to write code to unpack different modes as i said before [20:35:12] <BastyCDGS> the asm framework [20:36:06] <jai> also, code can be reused between some modes [20:36:09] <BastyCDGS> so I have something useful to do at next weekend [20:36:31] <jai> i dont recall details but if i can look into this again if time permits [20:36:46] <jai> -if [20:38:04] <BastyCDGS> audioconvert.c [20:38:14] <jai> what about it? [20:38:16] <BastyCDGS> preparing that it can call SSE/SSE2/SSE3/3dnow! stuff [20:38:19] <BastyCDGS> that was it [20:38:27] <jai> libawscale ;)? [20:38:33] <BastyCDGS> avcodec [20:38:47] <dgt84> This may seem like a silly quesion - but what's the proper way to add a .c and .h file to FFmpeg where e.g. a filter would include the .h and use one of the methods? I've added the .o to OBJS in libavfilter/Makefile and the filters build but on linking I get undefined references? [20:39:25] <dgt84> I guess I need libavfilter to include the .o but I'm not sure how to with the configure/build system [20:40:17] <BBB> isn't there a libavfilter/Makefile for that? [20:41:02] <BBB> BastyCDGS: you can surely do it, in fact you can do it anytime you want, but don't feel obliged :) [20:41:06] <BBB> you'll be qualified already [20:41:20] <BBB> but of course, good patches are always accepted, regardless of SoC or not [20:43:23] <dgt84> BBB yeah but how do I get my .o included in the linking step? I don't normally mess around with makefiles and configure scripts... [20:43:44] <BastyCDGS> well I have to do it at next weekend because I have then to prepare my exams which is middle of may [20:43:53] <BastyCDGS> have to learn lots of math stuff for it [20:44:01] <jai> math is good [20:44:09] <jai> liberal arts however... [20:45:34] <BastyCDGS> yes, although I sometimes wish it could be more practical orienated (for programmers) [20:45:54] <BastyCDGS> a lot of stuff is too theoretical to be usable for "normal" programming tasks [20:46:02] <_av500_> do math in hex :) [20:46:27] <BastyCDGS> hehe [20:46:53] <BastyCDGS> well the best thing though when I've finished that is that I never have to program in java again [20:46:57] <BastyCDGS> really don't like it [20:46:58] <jai> what exactly are you studying? [20:47:08] <saste> dtg84: maybe you're simply missing to run configure after you edited Makefile/allfilters.c [20:47:11] <jai> they teach java in universities? [20:47:12] <BastyCDGS> mathematical / scientific programming [20:47:13] <jai> wtf? [20:47:30] <BastyCDGS> it's standard in germany [20:47:35] <jai> o_O [20:47:42] <Kovensky> <@jai> they teach java in universities? <-- I was forced to "learn" it last year [20:47:45] <BastyCDGS> I study in aachen but live in belgium now [20:47:51] <Kovensky> this semester, I'll be forced to learn PHP >_> [20:47:53] <jai> BastyCDGS: RWTH? [20:48:02] <BastyCDGS> yes a joint venture between RWTH and FH [20:48:06] <jai> Kovensky: :/ [20:48:17] <jai> BastyCDGS: k [20:48:54] <dgt84> saste, should I edit allfilters.c? I'm not adding a filter, just adding a file that a filter will use - trying to move common code into a transform.c/.h that filters can use to transform frames with an affine matrix [20:49:19] <BastyCDGS> jai, you have been at RWTH? [20:49:23] <Kovensky> dgt84: then no I think, add it to the Makefile only [20:50:00] <jai> BastyCDGS: nah, some friends studied there in the past [20:50:58] <BastyCDGS> hey just reading that jason decided to stay :) [20:51:08] <dgt84> Kovensky, I added transform.o to OBJS in the Makefile and it builds transform.o and compiles the filters but when linking tells me I have undefined symbols [20:51:22] <saste> dgt84: no in that case no need to edit allfilters.c and then linking shouldn't fail [20:51:29] <BastyCDGS> although under the assumption that his patch is reconsidered [20:51:36] <saste> dgt84: i suppose you're using shared libs [20:52:16] <BastyCDGS> what were they studying there, jai? [20:52:18] <BBB> BastyCDGS: as we told you, he'll come back :) [20:52:23] <dgt84> saste, no, static. if a filter depends on another file being included in libavfilter where should I edit exactly? I added transform.o to OBJS - do I need to add anything to the filter lines themselves? [20:53:09] <BastyCDGS> btw. something for fun [20:53:10] <BastyCDGS> http://xkcd.com/327/ [20:53:56] <saste> dgt84: no that should be enough [20:55:18] <jai> BastyCDGS: automotive systems [20:57:09] <BastyCDGS> oops, I misread sth. jason just wants his commit rights back [20:57:16] <BastyCDGS> not the patch revised [20:58:50] <dgt84> saste, Kovensky, http://ffmpeg.pastebin.com/eytj93Pz [20:59:06] <dgt84> should I not be using static functions? Can that make a difference? [20:59:17] <dgt84> The error is at the bottom of the paste [21:00:02] <BastyCDGS> btw, when I test my stuff, is it enough to do this on linux online or shall I check with mingw (have cross-compiler ready) too? [21:00:14] <BBB> dgt84: static is not-exported [21:00:17] <BastyCDGS> s/online/only [21:00:19] <BBB> dgt84: so that definitely would break [21:00:22] <saste> dgt84: exactly a static function cannot be referenced outside the file where it is defined [21:00:27] <dgt84> d'oh [21:00:33] <BBB> BastyCDGS: only linux is fine [21:00:46] <BBB> BastyCDGS: don't purposely break win32 support, but if you accidently break it we'll fix it as soon as we notice [21:00:59] <BBB> check http://fate.multimedia.cx/ [21:01:15] <BastyCDGS> it should at least be useful to check this on a big-endian CPU [21:01:32] <dgt84> BBB, saste, thanks. I knew it was something stupid and obvious I was missing. Works now :-) [21:01:38] <jai> yes [21:01:41] <BastyCDGS> but I haven't one which works with ffmpeg (m68k isn't supported, right?) [21:02:27] <BBB> BastyCDGS: submit the code and we'll find the endianness-unsafe parts [21:02:32] <BBB> don't worry, we're quite good at this ;) [21:02:58] <BastyCDGS> well normally that isn't for me a problem, too...but you know, bugs...;) [21:03:10] <BBB> right, so that's what peer review does [21:03:21] <BBB> you submit good code, we make it a little better, and you get ... the best code :) [21:04:14] <BastyCDGS> good is not good enough it shall at least be very good...;) [21:05:00] <BastyCDGS> btw, anyone checked out my TuComposer stuff? [21:06:32] <BBB> I had a quick look at it when going through the soc proposal [21:06:50] <BBB> I'll probably go ore through it next week to (hopefully) be helpful in assisting in your project plan [21:06:58] <BastyCDGS> one of you was asking me last time what the reverse engineering stuff was, I found it, it was dctv iff-anim [21:07:54] <BastyCDGS> i can prepare a uae hdf file for you so you can test it [21:09:28] <BastyCDGS> and of course, an uae config file [21:09:41] <BBB> better yet, upload it to ftp://anonymous@upload.mplayerhq.hu/incoming/ [21:10:20] <BastyCDGS> i think you're prefering an e-uae instead of a WinUAE config, right? [21:10:39] <BBB> what's the difference? [21:10:54] <BastyCDGS> first runs under linux and second under windows (and wine) [21:11:09] <BastyCDGS> WinUAE is more recent and has more features but tucomposer works with both very well [21:11:37] <BastyCDGS> there isn't a GUI yet, but I have done a command line tool to playback modules [21:12:59] <BastyCDGS> you have a kickstart rom? [21:13:08] <BastyCDGS> (2.0 is at least required) [21:14:12] <BBB> I have none of this, the i files look very weird [21:14:28] <BastyCDGS> i will also copy my complete modules in TuComposer Module format (which i converted from MOD/S3M/XM/IT/FC13/FC14) [21:14:28] <BBB> is there anything that runs on a mac? [21:15:04] <BBB> or even better, in plain C? :) [21:15:27] <BastyCDGS> http://www.rcdrummond.net/uae/e-uae-0.8.29-WIP4/e-uae_0.8.29-WIP4_macosx-pp… [21:16:48] <BastyCDGS> as said it works on amiga only right now since I haven't ported the device drivers yett [21:16:56] <BastyCDGS> but want to do a SDL port anyway [21:18:01] <BastyCDGS> btw, TuComposer is much like IFF-ANIM just that it's a IFF-TCM1 header and different chunks ;) [21:19:27] * BBB needs a howto on how to get that tucomposer source code to work with this [21:19:58] <BastyCDGS> just open tucomposer.library.s in devpac and press ctrl+A :D [21:20:12] <BastyCDGS> it assembles in 2-5 seconds to a 400kb library [21:20:28] <BastyCDGS> for the 100% asm version [21:21:10] <BastyCDGS> for the C version just start StormC and start building the project, that's an IDE [21:21:11] <CIA-7> ffmpeg: darkshikari * r22915 /trunk/libavcodec/libx264.c: vertical align in libx264.c [21:21:21] <BastyCDGS> somewhat similar to eclipse [21:22:01] <BastyCDGS> btw, just noticed I mixed file sizes, the 100% asm is somewhat 100kb the C version is 400kb [21:22:27] <BastyCDGS> the C version still has asm optimized routines for the mixing engine and playback IRQ handler [21:22:39] <BastyCDGS> but there are also native C implementations of both [21:22:59] <mru> the ffmpeg way is to write plain C first [21:23:05] <mru> then optimise the parts that matter [21:23:39] <mru> although writing it all in asm would probably gain another 20% [21:23:50] <BastyCDGS> yeah I would do this today, too...but tucomposer was started 100% as asm [21:23:52] <Kovensky> and kill maintainability? =p [21:23:57] <mru> yep [21:24:30] <Kovensky> zsnes is 99% nasm, the rest is OS glue code [21:24:33] <BastyCDGS> well considering file size it's a gain of 400% ;) [21:24:40] <Kovensky> same for rollercoaster tycoon 1 and 2 [21:24:45] <mru> are you sure that's not debugging symbols and such? [21:24:46] * twnqx mails mru one of the C64s he has around so he can implement ffsid [21:24:52] <BastyCDGS> all stripped out [21:24:53] <Kovensky> but you don't get code for the former two =p [21:25:31] <mru> for some targets my code is twice as fast as gcc's [21:25:32] <twnqx> hm [21:25:36] <mru> even non-vector code [21:25:42] <Kovensky> twnqx: I wonder if ffmpeg works on a C64, I think it'd run out of RAM instantly :P [21:25:46] <twnqx> .sid surely can't be played by ffmpe yet, can it? [21:25:55] <BastyCDGS> well wasn't there a mp3 player recently released for C64? [21:26:04] <twnqx> yeah.. .but a limited one [21:26:18] <Kovensky> oh, solution: make it swap! [21:26:22] <Kovensky> good luck seeking on tapes :D [21:26:31] <twnqx> well, not really a surprise, given the c64 has no DAC [21:26:40] <twnqx> Kovensky: solution: 16MB REU [21:26:50] <Kovensky> oshi- [21:26:55] <twnqx> there was a demo last breakpoint that used it [21:26:59] <mru> when your cpu clock runs at more or less sample rate, things get tricky [21:27:02] <twnqx> actually it was a video player [21:27:18] <twnqx> which was really funny :P [21:27:22] <BastyCDGS> with H.264 encoding? :p [21:27:25] <twnqx> preload 16MB c64-class video [21:27:30] <twnqx> nah, uncompressed :P [21:27:34] <twnqx> then play it back :D [21:27:53] <twnqx> people didn't catch on to it in time, i think it won the wild competition :P [21:28:36] <twnqx> and i need to get a 12.6V zener diode tomorrow... [21:28:40] <twnqx> SOMEHOW, SOMEWHERE [21:30:12] <BastyCDGS> build one: [21:30:13] <BastyCDGS> http://www.allaboutcircuits.com/vol_3/chpt_3/11.html [21:31:31] <BastyCDGS> one question regarding charsets, is there an ffmpeg desired way of handling charsets? [21:31:50] <mru> convert everything to utf8 iirc [21:31:50] <BastyCDGS> IFF-ANIM is probably always iso-8859-1 (which was amiga's native one) [21:32:38] <mru> I guess amiga didn't support asian scripts? [21:33:19] <BastyCDGS> there's probably an utf8 library hanging around in aminet but I doubt anyone is using that [21:33:27] <BastyCDGS> but I know there are cyrillic fonts for it [21:33:45] <mru> cyrillic is easy to support with a different font [21:33:55] * mru saw that being done on DOS [21:34:09] <mru> japanese etc have way too many symbols for that to work [21:35:17] <BastyCDGS> just reading your idea about removing all non-pthreads support [21:35:33] <Kovensky> old japanese computers just used half-width katakana [21:35:36] <BastyCDGS> the patch for pthreads-win32 probably won't be applied because it breaks other things [21:35:51] <Kovensky> what does it break? [21:36:04] <BastyCDGS> when i remember correct memleak due to a missing DLL release call [21:36:24] <mru> an all-static build doesn't use dlls [21:36:31] <mru> so there can be nothing to release [21:37:44] <BastyCDGS> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01243.html [21:38:31] <BastyCDGS> compatilibity issues with win9x [21:38:44] <mru> why should that matter? [21:39:12] <mru> good luck trying to make current stuff work with "linux-95" [21:39:19] <Kovensky> do we care about win9x? [21:39:21] <mru> that would've been libc4 and no threads, btw [21:39:41] <mru> Kovensky: we obviously don't, but maybe they do [21:39:45] <BastyCDGS> well i use it still for impulsetracker DOS [21:39:56] <Kovensky> lol [21:40:23] <BastyCDGS> it doesn't run even with VDMsound on my machine on 2k upwards [21:40:31] <BastyCDGS> (doesn't find EMS) [21:41:03] <BastyCDGS> and in plain DOS mode it doesn't find my soundcard due to lack of DOS drivers [21:41:17] <Kovensky> install win95 on dosbox? :) [21:41:33] <BastyCDGS> my laptop handles this but my desktop is too slow [21:42:09] <BastyCDGS> enabling 32-bit interpolated with 45454 Hz (SB16 mode) requires a P2 around 400MHz at 64 channels [21:42:48] <BastyCDGS> there are also MMX drivers but I never really worked with them so I dunno speed there [21:43:22] <BastyCDGS> ok I don't do anything else with win9x so it shouldn't matter in case of ffmpeg [21:43:54] <BastyCDGS> but the mingw devs probably won't break compatilibity and therefore having only pthreads will force a mingw10.dll [21:44:11] <BastyCDGS> so maybe the best idea is drop everything except pthreads and win32 [21:44:57] <Kovensky> mingw not dropping win9x support is REALLY ANNOYING for portability btw [21:45:42] <Kovensky> programs that work with arbitrary filenames just fine on every other OS fail on win2k+ because they have to use the "ANSI" API because using the Wide API breaks win9x [21:46:03] <BastyCDGS> not if you use unicows.dll and -lunicows ;) [21:46:18] <BastyCDGS> i have tested this with unicode build of wxwidgets works like a charm [21:46:31] <BastyCDGS> unicows.dll is also only loaded if it's really launched at a win9x system [21:46:42] <Kovensky> <BastyCDGS> not if you use unicows.dll and -lunicows ;) <-- yes, but that means distributing one more dll to the poor win9x users and obviously they can't have that [21:48:37] <BastyCDGS> that's the price ;) [21:49:24] <BastyCDGS> there's also an open source variant of unicows [21:49:29] <BastyCDGS> opencows or something like that [21:50:14] <BastyCDGS> we might of course consider if they require unicows anyway we just add mingw10.dll requirement for win9x users too [21:50:26] <BastyCDGS> then we can drop win32 too [21:53:38] <BBB> BastyCDGS: how's iff/anim going? ;) [21:54:06] <BastyCDGS> i discussed some stuff with saste before we went away with ping timeout [21:54:23] <BastyCDGS> will continue tomorrow, i'm pretty tired right now because I'm up since around 3:30 [21:54:49] <BastyCDGS> and I doubt it's a good idea coding in this state, will just produce code which is more bad than it should be [21:55:30] <BastyCDGS> I think I'll finished most of the stuff tomorrow evening [21:55:54] <BastyCDGS> isn't really much to do now, most things regarding ffmpeg stuff have been clarified now [21:56:14] <bcoudurier> hi guys [21:56:21] <BastyCDGS> maybe I even get dctv reverse engineering finished until 21st [21:56:29] <BastyCDGS> hi bcoudurier [21:58:01] <BBB> looking forward to the code then :) [22:00:15] <BastyCDGS> just look? no writing? :) [22:00:18] <BastyCDGS> hihi [22:48:13] <BastyCDGS> good night to all, I'm getting some sleep soon... [22:48:30] <BastyCDGS> I'll need my power for tomorrow [22:49:21] <iive> let's hope you paid your bill to the power company. [22:49:36] <iive> ;) [22:50:48] <BastyCDGS> power is really cheap in belgium, it's just 22,14 â¬ per month...100% regenertive energy [22:52:12] <BastyCDGS> so that's not a big issue ;) [22:52:26] <BastyCDGS> unless you're economical like bush haha [22:52:47] <BastyCDGS> so beautiful dreams to all

1 0

IRC log for 2010-04-18
by irc＠mansr.com 19 Apr '10

19 Apr '10

[00:40:39] <hyc> yay, nothing left holding up rtmp seek patches [01:11:54] <BBB___> how do I move files around via ftp? [01:15:10] <BBB> hm, apparently rename is the ftp-version of the shell-mv command [01:15:11] <BBB> odd [01:17:13] <Kovensky> IIRC there are two commands [01:17:24] <Kovensky> IIRC they are rnfr and rnto, but don't quote me on that [01:17:37] <mru> who the fuck uses ftp for such things nowadays? [01:17:38] <Kovensky> but any ftp client will have a 'mv' command that sends those instructions =p [01:17:54] <Kovensky> talking about 'any ftp client', lol @ lftp's mv only working with absolute paths on sftp [01:18:05] <Kovensky> if I give a relative path it whines about file not found [01:21:18] <BBB> I'm using commandline fto [01:21:19] <BBB> ftp [01:21:23] <BBB> and it didn't do it :) [01:21:37] <BBB> mru: and I'm sorry for being prehistoric, but this is all silly osx comes with, I think [01:21:48] <BBB> I'm too lazy to set up Finder to log on to upload.mphq.hu [01:22:18] <mru> are people still using osx? [01:22:19] <mru> seriously? [01:22:33] <BBB> no, I'm sort of an outlier [01:22:34] <mru> I thought only the jobs zombies touched that [01:22:58] <BBB> it's convenient, it runs MS Word and Photoshop, so I can interact with other university people [01:23:24] <BBB> you know, these people who are not freetards and don't know and have never heard of and don't ever want to start hearing of GIMP or OOO.org [01:23:28] <mru> openoffice sucks, but it does read msword files [01:23:44] <peloverde> not the ones I want to view :( [01:23:51] <BBB> interoperability is poor enough that I stopped that silly excuse for a miserable product years ago [01:23:53] <mru> I've never, ever been sent a photoshop file [01:24:11] <BBB> and believe me, in science publishing, photoshop is all you see [01:24:18] <BBB> how else do you think they make nature paper figures? :) [01:24:31] <BBB> they could do it in gimp [01:24:33] <mru> all I ever saw was LaTeX [01:24:34] <BBB> but they don't have gimp [01:24:36] <BBB> so they don't [01:24:42] <BBB> latex is for math, I'm in biology [01:24:45] <mru> and a bit of matlab [01:25:28] <BBB> anyway, MS Word is a good product, I wouldn't trade it for OOO.org if I had to sell my soul to the devil [01:25:28] <BBB> which I presumably already did by buying a license for it [01:25:30] <BBB> :) [01:25:38] <BBB> same for photoshop, it's a very solid product [01:26:08] <mru> msword is not good by any imagination [01:26:28] <BBB> fine... but it's interoperable when you interact with other Word users [01:26:32] <BBB> which is all I care about [01:26:34] <mru> I haven't used photoshop enough to form an opinion [01:26:35] <Kovensky> <@mru> are people still using osx? <-- I know some art people that wouldn't trade it for anything [01:26:49] <Kovensky> at least one of them keeps trying linux but keeps getting disappointed at the tablet support [01:26:52] <mru> guess I don't talk go many art people [01:27:00] <BBB> move to williamsburg [01:27:07] * mru declies [01:27:10] <mru> +n [01:29:41] * BBB goes back down then [01:57:18] <astrange> os x comes with lftp which isn't bad [01:57:26] <astrange> certainly better than the sftp client [01:57:42] <mru> sftp is an entirely different thing [01:58:00] <astrange> not when your server has both [01:59:51] <mru> still very different [02:01:02] <astrange> what does that have to do with the client not supporting tab completion? [02:01:15] <astrange> actually, on os x it doesn't even support backspace. i wonder whose fault that is [02:02:13] <mru> idiot's [09:29:07] <KotH> moin [10:40:39] <Yuvi> hm, random internet commenter says they talked to on2 at one point about licensing vp8 and were told that part of the vp8 license fees went to the mpeg-la [10:42:48] <mru> rotfl [12:43:55] <lu_zero> wbs: the patch 4 seems to break seeking in feng [12:44:13] <lu_zero> and I'm experiencing slowdowns after seeking when patch 3 is in [12:45:41] <wbs> hmm, ok [13:33:24] <peloverde> Should I close this as invalid? https://roundup.ffmpeg.org/issue1882 [13:34:10] <peloverde> I really have faa{c,d} [13:34:58] <peloverde> They really should rename it to nnaa (nero nonfree aac approximation) [13:35:44] <pJok> have or hate? [13:36:01] <peloverde> hate, sorry [13:36:04] <pJok> ;) [13:36:17] <pJok> my T9 does that all the time when i use my phone for irc [13:36:47] <peloverde> yes, lets pretend i'm sending this message from my phone, less embarrassing for me [13:38:13] <pJok> i just pretend that i read hate [13:38:44] <pJok> and someone should just fix ffaac ;) [13:39:01] <peloverde> the file isn't aac [13:39:36] <peloverde> AAC forbids two identical element instance tags on the same non fill channel element in the same frame [13:40:09] <peloverde> This file fails to meet that criterion and thus fails to be aac [13:40:42] <wbs> lu_zero: sure that patch #3 adds the slowdowns after seeking, btw? that one should just parse headers and populate the data structures but not actually do anything with it.. so in that case, it's #1 or #2 doing something [13:41:05] <wbs> lu_zero: but i've seen weird slowdowns in ffplay when watching rtsp-streams, too, haven't figured out exactly what's causing it [17:38:11] <CIA-81> ffmpeg: stefano * r22901 /trunk/libavformat/avio.c: [17:38:12] <CIA-81> ffmpeg: Make url_seek() return AVERROR(ENOSYS) rather than AVERROR(EPIPE) in [17:38:12] <CIA-81> ffmpeg: the case where the seek operation is not defined in the protocol [17:38:12] <CIA-81> ffmpeg: handler. [17:38:12] <CIA-81> ffmpeg: stefano * r22902 /trunk/libavformat/aviobuf.c: [17:38:12] <CIA-81> ffmpeg: Make url_fsize() return AVERROR(ENOSYS) rather than AVERROR(EPIPE) if [17:38:13] <CIA-81> ffmpeg: the seek operation is not defined in the ByteIOContext. [18:29:17] <hyc> anyone got a free second to commit this? https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086781.html [18:49:38] <saste> hyc: I'm working on that right now [18:49:52] <hyc> cool, thanks [18:49:54] <saste> hyc: but I wanted to put a meaningful comment [18:50:45] <saste> hyc: for example it puzzled me that we have the implementation of that read_seek2 but ifdeffed [18:51:45] <hyc> that implementation is mostly a copy of avformat_seek_file() [18:52:27] <hyc> as Michael pointed out, it really doesn't support the intended semantics of read_seek2() [18:52:34] <saste> can you comment on the if (stream_index < 0) check added in rtmp_read_seek()? [18:52:38] <hyc> but I figured I would leave it in for future reference [18:52:55] <saste> yes so I'm going to keep that... [18:53:14] <hyc> sure; the documentation says stream_index must never be -1 at this API level [18:53:47] <hyc> but ... we need to handle this case.... [18:53:52] <hyc> my mplayer patch depends on it [18:54:00] <saste> ok [19:10:12] <CIA-81> ffmpeg: stefano * r22903 /trunk/libavformat/librtmp.c: [19:10:12] <CIA-81> ffmpeg: Prefer AVERROR(ENOSYS) over AVERROR_NOTSUPP. [19:10:12] <CIA-81> ffmpeg: AVERROR_NOTSUPP is (maybe) going to be deprecated. [19:10:13] <CIA-81> ffmpeg: stefano * r22904 /trunk/libavformat/ (librtmp.c flvdec.c): (log message trimmed) [19:10:13] <CIA-81> ffmpeg: Implement librtmp seek support. [19:10:13] <CIA-81> ffmpeg: Implement flv_read_seek(), add a missing check on stream_index [19:10:13] <CIA-81> ffmpeg: and fix timestamp rounding in rtmp_read_seek(). [19:10:14] <CIA-81> ffmpeg: Also add the flv_read_seek2() function, which is not enabled but is [19:10:14] <CIA-81> ffmpeg: useful as reference. [19:10:15] <CIA-81> ffmpeg: To actually implement flv_read_seek2() correctly, there would need to [19:12:30] <hyc> great, thanks [19:15:51] <saste> hyc: np :) [20:11:37] <CIA-81> ffmpeg: stefano * r22905 /trunk/libavfilter/avfiltergraph.c: [20:11:37] <CIA-81> ffmpeg: Fix leak in avfilter_graph_add_filter(). [20:11:37] <CIA-81> ffmpeg: In case of reallocation failure the pointer to the original filter [20:11:37] <CIA-81> ffmpeg: array was lost. The correct behavior seems to just keep the old array [20:11:37] <CIA-81> ffmpeg: and count.

1 0

IRC log for 2010-04-17
by irc＠mansr.com 18 Apr '10

18 Apr '10

[00:07:40] <bcoudurier> well [00:07:50] <bcoudurier> I'm concerned about the code license [00:07:58] <bcoudurier> it was inspired from the ffmpeg muxer [00:15:36] <ramiro> the license in the zip file reads: Added by Clavain Technologies Ltd. with approval from CodeShop B.V.: The FFmpeg Output Patch will be released under the LGPL after a code-rework is done. [00:16:17] <bcoudurier> that is impossible I'm afraid [00:16:33] <bcoudurier> the file contains code from ffmpeg licensed under LGPL [00:16:34] <ramiro> even "with approval from CodeShop B.V."? [00:16:46] <bcoudurier> you cannot ship as creative common [00:17:05] <bcoudurier> there was a change forbidden in the first place [00:17:16] <ramiro> i think codeshop's code has no ffmpeg stuff in it, but I didn't check. clavain technologies added ffmpeg stuff. [00:17:54] <bcoudurier> ah [00:18:42] <SmkMnstr> im hugely respected in dev community, once i start using ffmpeg its going to catch on fast [00:19:10] <ramiro> SmkMnstr: what dev community? [00:19:14] <Dark_Shikari> lol [00:19:19] <SmkMnstr> jk [00:20:10] <ramiro> oh, good =) [00:20:32] <ramiro> I was about to unleash a huge congratu-fucking-lations =) [00:22:12] <ramiro> bcoudurier: what parts specifically are from ffmpeg on that patch? [00:23:00] <bcoudurier> have a look [00:24:09] <bcoudurier> there is some copy-pasted code from utils.c [00:24:39] <bcoudurier> and movenc.c was copied in the first place then they replaced the code in the functions [00:25:09] <bcoudurier> anyway I sent a mail to code-shop, if they are not responsible for the patch, I hope they will point me to the right person :> [00:27:19] <ramiro> ok [00:27:32] <ramiro> anyways, I'm off again... [00:28:00] <bcoudurier> bye [00:39:15] <bcoudurier> hummmm [00:41:34] <bcoudurier> code ripers [00:43:25] <bcoudurier> they ripped the mpeg ts muxer code [00:44:23] <bcoudurier> that's not the most beautiful piece of code in the codebase for sure ;) [02:05:24] <CIA-81> ffmpeg: conrad * r22896 /trunk/libavcodec/ (9 files in 3 dirs): [02:05:24] <CIA-81> ffmpeg: vp3: DC-only IDCT [02:05:24] <CIA-81> ffmpeg: 2-4% faster overall decode [02:05:25] <CIA-81> ffmpeg: conrad * r22897 /trunk/libavcodec/vp3.c: [02:05:25] <CIA-81> ffmpeg: vp3: Don't crop if there's a left/top offset, it's wrong [02:05:25] <CIA-81> ffmpeg: Fixes issue1834 [02:05:25] <CIA-81> ffmpeg: conrad * r22898 /trunk/libavcodec/vp3.c: vp3: Read fps and aspect ratio in the decoder [02:16:35] <Yuvi> hm, ffmpeg is a bit slower than libtheora on atom [02:18:22] <Dark_Shikari> probably function selection [02:18:31] <Dark_Shikari> libtheora probably has less sse code [02:18:34] <Dark_Shikari> and some sse code is terrible on atom [02:18:41] <Dark_Shikari> also, multiplies are sloooow [02:18:49] <Yuvi> well, the sse2 idct is still a lot faster than mmx on atom [02:19:05] <Dark_Shikari> also, out of order execution issues [02:19:12] <saintdev> does gcc reorder instructions when you use march=atom? [02:19:16] <Dark_Shikari> maybe the libtheora stuff is better-scheduled [02:22:23] <Yuvi> loop filter maybe, sse2 idct seems to have been written assuming no oooe [02:22:33] <Yuvi> the mmx idct is pretty much identical [10:38:33] <CIA-81> ffmpeg: conrad * r22899 /trunk/libavcodec/vp3.c: vp3: Use avctx pointer directly [10:48:38] <mru> lol @ vp8 is 5 more better than vp3 [10:48:41] <mru> mike's blog [10:54:35] <kierank> I lol'd at this link from the blog: http://www.stickergiant.com/charts-and-graphs_d49.html [11:01:44] <CIA-81> ffmpeg: cehoyos * r22900 /trunk/libavcodec/huffyuv.c: [11:01:45] <CIA-81> ffmpeg: Add const to some pointer parameters. [11:01:45] <CIA-81> ffmpeg: Patch by Michael Kaufmann, hallo michael-kaufmann ch [11:29:12] <Kovensky> http://27.media.tumblr.com/tumblr_l0z3o57qT31qzou68o1_500.jpg [11:29:13] <Kovensky> mru: lol [11:30:00] <mru> lol [17:25:30] <DonDiego> Yuvi: you around? [18:08:52] <siretart> hi DonDiego! [18:45:59] <Yuvi> DonDiego: yo [18:48:15] <siretart> hi Yuvi [18:48:24] <Yuvi> hi [19:42:12] <DonDiego> Yuvi: what's the status with ogg and theora? [19:44:27] <Yuvi> DonDiego: the crashers are fixed, there's one issue I introduced last night with aspect ratio (encoding from theora gives the wrong one) that I need to look at [19:47:48] <Yuvi> But thtS pretty minor [19:48:02] <Yuvi> Other thAn that it should be good [19:48:25] <DonDiego> ok [19:48:28] <DonDiego> what about feature work? [19:48:35] <DonDiego> i kinda lost track [19:48:43] <DonDiego> do you have some speedups in the queue still? [19:48:50] <DonDiego> some other features? [19:48:56] <DonDiego> chained ogg or whatnot? [19:49:38] <Yuvi> Yes to the speedups, but those are fairly involved (mAybe regression prone) [19:49:49] <DonDiego> ok [19:49:52] <DonDiego> anything else? [19:50:28] <DonDiego> btw, we should look into nicking all the speedups we can get from libtheora and theorarm [19:50:35] <Yuvi> No features in the works, the chained off patch needed some big reworking to not fail sometimes [19:51:00] <DonDiego> though i'm only aware of mmx asm in libtheora [19:51:09] <DonDiego> Yuvi: so nothing is pending? [19:51:39] <DonDiego> and what about the chained off patch (i haven't followed the ml) [19:51:43] <DonDiego> ? [19:52:30] <Yuvi> I have some armv6 optimizations in progress, most of theorarm is for older arms /bad compiler [19:53:02] <Yuvi> It failed badly if the streams [19:53:17] <Yuvi> If the chains had different extradata [19:53:53] <DonDiego> will you get that fixed (soon)? [19:59:26] <Yuvi> Not soon, I'll probabavly do more optims first [20:02:51] <DonDiego> ok [20:02:59] <DonDiego> we're good to go for the release then [20:03:44] <siretart> \o/ [22:42:21] <Dark_Shikari> mru: you know anything about prefetch on ppc? does it crash/die on invalid address, or ignore it? [22:50:24] <astrange> prefetch (dcbt) ignores errors [22:57:18] <Dark_Shikari> ok

1 0

IRC log for 2010-04-16
by irc＠mansr.com 17 Apr '10

17 Apr '10

[00:21:02] <CIA-81> ffmpeg: ramiro * r22888 /trunk/ (libavformat/rtsp.c cmdutils.c): [00:21:02] <CIA-81> ffmpeg: AVERROR(FF_NETERROR(x)) -> FF_NETERROR(x) [00:21:02] <CIA-81> ffmpeg: FF_NETERROR is implicitly an AVERROR. [01:57:05] <roozhou> hi, when will you guys fix ETIMEDOUT undeclared bug in rtsp.c under win32? [02:24:53] <Compn> roozhou : probably when you enter bugreport on http://roundup.ffmpeg.org [02:25:00] <Compn> or paste me enough info so i can create report [02:25:12] <Compn> fate should have picked up on it actually... [02:26:28] <roozhou> here: http://ffmpeg.arrozcru.org/autobuilds/ [02:26:40] <roozhou> see the build log [02:30:02] <Compn> thats for 22884 [02:30:24] <Compn> fate says 22888 is working [02:30:32] <Compn> http://fate.multimedia.cx/index-v3.php [02:31:35] <Compn> [14:38] <CIA-81> ffmpeg: rbultje * r22887 /trunk/libavformat/ (rtsp.c network.h): [02:31:36] <Compn> [14:38] <CIA-81> ffmpeg: Fix compile error on cygwin where ETIME is missing (because it's a WSA error). [02:32:01] <Compn> roozhou : maybe you need to svn update ? [02:33:31] <roozhou> great [06:24:50] <Tjoppen> we have a student doing a video related master thesis in our office. any suggestions what he should pick for his in-depth theoretical study? I suspect MPEG-1 video wouldn't be too bad [06:26:00] <wbs> I guess it depends _very_ much on exactly what he's doing, "video related" could be just about anything [06:26:17] <astrange> how long is it supposed to be? mpeg-1 is extremely simple [06:26:50] <Tjoppen> well, it's not simple to a newbie. I don't think the average CS student even knows how JPEG works [06:27:11] <Dark_Shikari> MASTER THESIS? [06:27:27] <Dark_Shikari> er.... doing something mpeg-1 related for a master thesis? is this a joke? [06:27:47] <Tjoppen> no. that's why I'm asking [06:27:50] <Dark_Shikari> ffs, even when I wrote a toy memory allocator in a one-off lab assignment for a mid-level CS class I tried to do something mildly interesting [06:28:27] <Dark_Shikari> for a master thesis I would recommend implementing a new feature in x264 or something similarly difficult. [06:28:34] <Tjoppen> the thing is this is just a minor part of the thesis, if I understand correctly [06:28:36] <Dark_Shikari> Anything less than a Google Summer of Code project for a masters' thesis is a joke. [06:28:40] <Dark_Shikari> ah [06:28:42] <Dark_Shikari> should have said that then. [06:28:47] <Tjoppen> yeah :o [06:28:47] <Dark_Shikari> What exactly is it for? [06:29:53] <Tjoppen> not sure how much I can reveal, but it's for one of the systems we're developing. he's already done the main work is done, but seems to need some theory to complement it [06:30:07] <Tjoppen> s/is done// [06:30:31] <Tjoppen> to prime the reader I guess would be a good explaination [06:30:38] <Dark_Shikari> prime what reader [06:30:56] <Tjoppen> of the thesis. via a theory section [06:31:09] <Dark_Shikari> how can you expect people to advise you about something you can't talk about? [06:31:17] <Tjoppen> heh [06:31:22] <Tjoppen> fair enough [06:40:36] <peloverde> So the spec says not to run ipd/opd at all when the enable_ipdopd flag is zero but the reference decoder seems to run it anyway, FML [06:40:54] <Dark_Shikari> that looks like a mixed up ipod [06:41:14] <peloverde> google thinks so too, it drives me mad to no end [06:41:31] <wbs> peloverde: btw, regarding AAC, I recently studied it a bit, and was horrified about the (undefined number of) priming samples showing up in the output [06:41:49] <peloverde> wbs, those samples are not undefined [06:42:01] <peloverde> TDAC initializes to zero [06:42:08] <wbs> but different encoders produce different amount of them? [06:42:38] <Yuvi> using '+' works wonders to combat google's helpfulness [06:42:39] <peloverde> editlists should be used to compensate for encoder delay [06:43:21] <wbs> ok, ffmpeg (with faac) doesn't seem to use that at least [06:43:44] <wbs> as a constructed example, I repeatedly encoded an mp4 file with aac into another file with the same format [06:43:51] <wbs> after a few rounds, the a/v sync was way off [06:44:05] <wbs> (did this with quite low sampling rate, to make the effect much larger) [06:44:25] <peloverde> the encoder needs to set editlists [06:44:48] <peloverde> There is no way to know what the encoder delay is without them [06:44:53] <wbs> exactly [06:45:28] <peloverde> Apparently it is discussed in detail in 14496-24 but I don't have that one [06:46:50] <Dark_Shikari> any idea why this http://pastebin.org/153329 would cause this http://pastebin.org/153328 ? [06:46:54] <Dark_Shikari> (GCC ICEs ftw) [06:47:11] <Yuvi> "+m"(M64()) ? [06:47:13] <wbs> ok.. is there any point in filing a roundup case about it, to remind that it should be handled in some way? [06:47:22] <Dark_Shikari> Yuvi: it was the [i], just figured it out [06:47:25] <Dark_Shikari> mvc[i] caused it to ICE [06:47:47] <Dark_Shikari> recursive dependency [06:48:21] <peloverde> I don't have the write specs to do anything on that, and I'm not paying 200 CHF for a 15 page pdf [06:49:04] <peloverde> Also I think google is trolling me http://i.imgur.com/upnzs.png [06:49:20] <wbs> haha [06:49:44] <peloverde> s/write/right/ [06:50:03] <pJok> peloverde, http://www.pdfqueen.com/html/aHR0cDovL3dlYnN0b3JlLmllYy5jaC9wcmV2aWV3L2luZm… ? [06:50:19] <peloverde> pJok, that's -12 [06:50:22] <peloverde> I need -24 [06:50:25] <pJok> gah [06:50:26] <pJok> that was only the 12 [06:50:33] <Yuvi> no encoder as of 2008 outputed ipd/opd? [06:51:12] <astrange> Dark_Shikari: does a "new" gcc do that? [06:51:32] <peloverde> Yuvi, no idea [06:51:43] <astrange> it would be a gcc ice-on-invalid bug [06:52:30] <Dark_Shikari> astrange: that was 3.4 [06:52:38] <Dark_Shikari> let me try 4.3.4 [06:53:05] <Yuvi> peloverde: first result of http://www.google.com/search?&q=%2Bipd+%2Bopd+%2Baac claims so, second implies that there's only a single sample that uses them in existence [06:53:47] <Dark_Shikari> astrange: nah, fixed. in fact, it compiles now [06:53:48] <Dark_Shikari> lol [06:55:11] <peloverde> Yuvi, I decoder is not Level 5 con formant without IPD/OPD support, it doesn't matter that no one uses it now [06:56:00] <peloverde> remember when thunselda started using uncoded 4MV, etc. and all sorts of stuff started coming up as broken in fftheora? [07:19:47] <peloverde> that said, since there is conflict, I think i will err on the side of what computationally simpler [08:01:28] <KotH> salve ffmpeg! morituri te salutat! [08:14:20] <Dark_Shikari> oh wow, I stumbled across that old inline asm bug report on gcc [08:14:32] <Dark_Shikari> where the devs claimed that register-allocation was turing-hard [08:14:37] <Dark_Shikari> er, halting-problem-hard [08:36:58] <KotH> hmm? [08:37:16] <KotH> register allocation might be an NP complete problem, but then, you dont have millions of registers [08:40:31] <Dark_Shikari> yeah, x86 has 7 [08:40:36] <Dark_Shikari> but nevermind that, they claimed it was halting-problem hard [08:40:46] <Dark_Shikari> merbzt: was it you who told me how to use ccc-analyzer? [08:40:55] <Dark_Shikari> when I compiled llvm/clang it didn't come with ccc-analyzer... [08:43:08] <astrange> it's a perl script in http://checker.minormatter.com/checker-240.tar.bz2 [08:43:48] <Dark_Shikari> ah [08:44:45] <astrange> it's also practically useless for c but you can try it every so often [08:44:54] <Dark_Shikari> er.... merbzt I think ran it on ffmpeg [08:44:57] <Dark_Shikari> and got like 400+ results [08:45:01] <Dark_Shikari> many of which were real bugs [08:45:07] <Dark_Shikari> And I don't see it in that tar.gz [08:45:14] <Dark_Shikari> I see a binary compile of a half year old version of clang [08:45:30] <Dark_Shikari> oh, libexec [08:46:26] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/ most of these aren't real bugs [08:46:37] <Dark_Shikari> well just ignore the dead stores [08:46:40] <Dark_Shikari> those are always useless [08:46:50] <astrange> if i turned on experimental analyses it'd warn whenever a function called malloc() and returned the result [08:46:58] <astrange> and on any cast to av_alias, i think [08:47:03] <astrange> but those are experimental at least [08:49:45] <Dark_Shikari> damn, it's pretty slow. [08:50:22] <Dark_Shikari> like, taking 10 seconds for single functions slow [08:50:45] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/report-XkkEMF.html#EndPath well... that one's valid [08:50:56] <KotH> Dark_Shikari: hmm.. what is the difference between NP complete and halting problem hard for someone who isnt CS savy? [08:51:17] <Dark_Shikari> KotH: NP complete means that we think it can probably only be solved in exponential time with respect to the size of the input [08:51:24] <Dark_Shikari> more specifically [08:51:33] <Dark_Shikari> if you have a polynomial-time algorithm for ANY np-complete algorithm [08:51:38] <astrange> np can be checked polynomial and maybe only solved optimally in exponential [08:51:43] <Dark_Shikari> you can use that to solve _any other_ NP-complete problem. [08:51:52] <astrange> halting problem is unsolvable in finite time for some input [08:52:06] <Dark_Shikari> and yeah, that. [08:52:17] <KotH> hmm... WTF? [08:52:24] <Dark_Shikari> to which [08:52:48] <Dark_Shikari> in short, P is Easy, NP is Hard, halting is Impossible [08:52:49] <astrange> i think that guy was just mad that people kept reporting RA bugs [08:53:11] <astrange> that was before 4.4 had a new ra so at that point the last two or three projects to write one had failed [08:53:55] <KotH> yes, but still, claiming something as impossible to solve isnt going to help you [08:54:04] <Dark_Shikari> KotH: sure it does [08:54:08] <Dark_Shikari> if you know that X is impossible [08:54:15] <Dark_Shikari> and solving Y means you could solve X [08:54:18] <Dark_Shikari> that means solving Y is impossible [08:54:22] <Dark_Shikari> Equally, with NP-completeness [08:54:24] <Dark_Shikari> if you know X is hard [08:54:28] <Dark_Shikari> and you can prove Y is at least as hard as solving X [08:54:31] <Dark_Shikari> then Y is hard too. [08:54:58] <Dark_Shikari> That's what NP-completeness is all about: X is hard, and if I could solve Y easily, I could also solve X easily. So Y is probably hard too. [08:56:42] <KotH> Dark_Shikari: yes, from a theoretical point of view. but if you are dealing with users, then telling them that the problem is so hard you cannot solve it, doesnt help [08:56:52] <Dark_Shikari> Sure it does. [08:56:55] <KotH> Dark_Shikari: even if it's true (which isnt in this case) [08:56:57] <Dark_Shikari> Your boss says he wants an optimal solution for X [08:57:07] <Dark_Shikari> you tell him it's NP-complete, thus practically not possible, so you will have to use an approximation instead. [08:57:33] <KotH> juup [08:57:45] <Dark_Shikari> approximation algorithms for Hard Problems is also a big domain of complexity theory [08:57:51] <Dark_Shikari> proving that a given algorithm will always get within some factor of optimal [08:58:07] <Dark_Shikari> some problems are really "easy" in that regard [08:58:14] <Dark_Shikari> for example, suppose you have two hard disks and a bunch of files [08:58:26] <Dark_Shikari> and you want to maximize the number of files that you can fit on the disks (the rest will go on tape backup) [08:58:52] <Dark_Shikari> So you sort the files by increasing size. Start at the smallest, stick them all on disk one. Then when disk one fills up, stick the rest on disk two, in order of increasing size as per before. [08:59:01] <Dark_Shikari> You're guaranteed to get within one file of optimal. [08:59:20] <Dark_Shikari> Even though the actual problem is NP-complete. [08:59:42] <Dark_Shikari> so optimal takes exponential time, one-less-than-optimal costs one sort. [09:00:53] <merbzt> Dark_Shikari: yes it was me [09:01:01] <Dark_Shikari> no problem, got it working now [09:01:05] <merbzt> you need to compile llvm with clang [09:01:05] <Dark_Shikari> it's slooooooooowly going [09:01:22] <merbzt> you need to compile in release mode [09:01:28] <merbzt> but it is slow anyway [09:05:12] <scaphilo> question: how would i find the forward motion vector for a specific mb in motion_val: here? motion_val[0][mb_xy][0 and 1] but mb_xy-address of a pixel or of a macroblock? [09:05:24] <scaphilo> http://dpaste.com/184460/ [09:06:15] <scaphilo> it looks as if its grid is pixel but thats a bit strange for me [09:06:25] <Dark_Shikari> probably the address of a partition [09:06:33] <Dark_Shikari> for mpeg-2 it'd probably be per-mb [09:06:37] <Dark_Shikari> for mpeg-4, probably per 8x8 [09:06:42] <Dark_Shikari> for h264, probably per 4x4 [09:07:04] <scaphilo> so i have to find out how its stored in mpeg2 [09:07:16] <scaphilo> that could be different [09:07:26] <scaphilo> ill check that [09:07:29] <Dark_Shikari> merbzt: so where does it put the results? [09:20:08] <scaphilo> Well this explains why i dont find any motion vectors in my motion val. Do i have to set this manually or is there a way to set it in command line? if(s->current_picture.motion_val[0] && !s->encoding){ //note motion_val is normally NULL unless we want to extract the MVs [09:38:15] <peloverde> wbs, there is already a bug open about the aac delay [09:38:31] <wbs> peloverde: yeah, saw that one [09:39:02] <wbs> I was actually mostly interested in knowing how it is supposed to be signalled [09:39:44] <wbs> for a streaming case (like rtp or something similar) where one can't really add edit lists or something such; would it be sensible to offset the packet timestamps with the encoder delay? [09:40:08] <wbs> so if the first encoder input data would have timestamp 0, the first output packet would get a timestamp of -delay? [09:50:02] <scaphilo> question by the way: With which tool do you develop c apps in linux? eclipse is crap [09:50:12] <Dark_Shikari> vim [09:52:42] <KotH> scaphilo: lol [09:52:45] <scaphilo> not really? that takes 100 times longer to dev something i mean you can do so with object oriented languages but not with c [09:53:10] <KotH> scaphilo: forget everyhting you learned about programming you heard at HSR or from people "programming" on windows [09:53:16] <scaphilo> Dark_shikari nano is better by the way ;-) [09:53:18] <KotH> scaphilo: they are all lagging about 20 years behind the times [09:53:53] <elenril> lolnano [09:54:02] <scaphilo> its better than vi [09:54:13] <Dark_Shikari> vi != vim [09:54:15] <KotH> it's better than sun's vi.. taht for sure ;) [09:54:18] <Dark_Shikari> also, merbzt, thanks, already found two bugs. [09:54:42] <elenril> what D_S said, +vi has some neat features ;) [09:55:25] <scaphilo> am your kidding me you dont code with vim are you? [09:55:58] * wbs codes with vim [09:56:13] * elenril writes pretty much everything in vim [09:56:35] * Dark_Shikari mostly uses notepad++, but uses vim whenever he's on unix [09:57:04] * peloverde codes exclusively in vim [09:57:54] <peloverde> I hear some others around here use emacs [09:58:34] <scaphilo> am ... but ... c ? you have to jump arrount the code. Does vim support this references or what? [09:58:43] <scaphilo> from one file to an other [09:59:05] <Dark_Shikari> ctags [09:59:42] <wbs> scaphilo: just open a few xterms with a vim session in each, and use / for searching within the current file [10:00:34] <peloverde> I use grep to find the relevant file then open it as a new buffer [10:00:37] <scaphilo> perhpas i have to test vim as well ... i never expected that :-) [10:01:04] <scaphilo> thats so strange [10:01:15] <Dark_Shikari> welcome to the world of development on every OS except windows [10:02:08] <scaphilo> early days eclipse was a good way to do that [10:02:24] <astrange> i use the xcode organizer window + ack for searching, terminal editors don't quite do it for me [10:02:28] <scaphilo> but currently i develop pyhton and java with a texteditor [10:02:29] <astrange> ctags would be faster than ack, though [10:04:02] <scaphilo> thank you for this info, ill have to check out this kind of developing c [10:04:40] <wbs> why wouldn't you have to "jump around" just as much when developing in some "object-oriented language"? [10:05:20] <Dark_Shikari> in fact I would think you would have to jump aroudn more ... [10:05:27] <Dark_Shikari> since everything is divided into five gajillion classes [10:05:39] <scaphilo> just because you always know where you find the function your looking for [10:06:28] <scaphilo> in c i never no where i have to look for it [10:06:37] <Dark_Shikari> that sounds like a case of knowing the code vs not knowing the code [10:06:39] <Dark_Shikari> nothing to do with the language [10:08:52] <scaphilo> its a bit of both i think. but if you really code nicely with an oo language its easier to revers engineer [10:09:32] <scaphilo> anyway i was just wondering how your developing in c. i cant change the language its the most efficient [10:09:42] <wbs> no, then you haven't seen the cases in OOP where you split up everything into interfaces and stubs and never know where the actual implementation is [10:09:52] <Dark_Shikari> wbs: with multiple inheritance, of course [10:10:04] <Dark_Shikari> and of course, you have that great pattern where you have one class per interface [10:10:11] <Dark_Shikari> which is really fun! [10:10:29] <scaphilo> well i dont prefer java [10:10:37] <scaphilo> python doesnt have this problems [10:10:38] <astrange> i tried to find the code in audacity that draws the waveform display and gave up eventually [10:10:47] <Dark_Shikari> python isn't an OO language [10:10:50] <Dark_Shikari> it's a multi-paradigm language [10:11:22] <astrange> except for the paradigms the maintainers claim not to understand [10:11:23] <Dark_Shikari> if you're boring, stupid, and like java, you can write tons of OO code in it. [10:11:27] <Dark_Shikari> lol [10:11:38] <astrange> like tail calls [10:12:03] <elenril> wbs: that's even more fun in C [10:12:10] <elenril> *cough*wine*cough* [10:12:30] <Dark_Shikari> closures in C are fun [10:15:23] <scaphilo> this is fun: define private public :-D [10:15:57] <KotH> scaphilo: ever worked in a comercial enviroment? [10:16:10] <KotH> scaphilo: ie, programming or reading code written by "professionals"? [10:16:21] <scaphilo> no [10:16:38] <KotH> be glad... be very glad... [10:17:17] <wbs> peloverde: any comment on the aac/timestamps issues in streaming, as I mentioned a few screens up? [10:17:20] <KotH> even mplayers code as it was 10y ago,was very clean and well structured to what can be seen in software companies [10:17:41] <KotH> and it doesnt matter whether it's c, c++, java or pascal... [10:18:01] <peloverde> wbs, no idea i don't do streaming, I would look at the relevant RFCs [10:18:11] <scaphilo> oh you mean this microsoft code? thats bader than ugly [10:18:29] <KotH> i think, worst i've ever seen was an implementation of a ring buffer in c. there were at least 15 bugs (thinkos) within less than 100 loc [10:18:41] <Dark_Shikari> the daily wtf has worse. [10:18:43] <Dark_Shikari> Always. [10:18:57] <Dark_Shikari> http://thedailywtf.com/Articles/The-Doubleton-Patten.aspx from the other day is a fun one [10:19:03] <KotH> and that whole shit worked only, because the ring buffer dropped a byte once in a while [10:19:06] <Dark_Shikari> http://thedailywtf.com/Articles/The-Doubleton-Patten.aspx is brilliant [10:19:34] <KotH> Dark_Shikari: tdwtf is a collection what can be seen worldwide... that's a much larger sampling base than i have :) [10:20:04] <Dark_Shikari> indeed [10:20:17] <Dark_Shikari> er, oops [10:20:22] <Dark_Shikari> the second link was supposesd to be http://thedailywtf.com/Articles/Check-Digit-Check.aspx [10:20:36] <Dark_Shikari> That page is why we should ban ctrl-V from use by new programmers. [10:22:14] <scaphilo> very mice [10:22:17] <scaphilo> nice [10:32:00] <Kovensky> <@wbs> scaphilo: just open a few xterms with a vim session in each <-- pfft xterms, use gnu screen :> [10:32:17] <Kovensky> or emacs buffers :> [10:33:30] <jai> astrange: http://code.google.com/p/audacity/source/browse/audacity-src/trunk/src/Freq… isn't it? [10:34:07] * elenril throws http://vimdoc.sourceforge.net/htmldoc/windows.html#windows at Kovensky [10:36:05] <elenril> hmm, picking individual lines/hunks to commit in git gui is nice [10:36:23] <Kovensky> desyou [10:36:25] <peloverde> I prefer git add -p [10:36:36] <peloverde> though as long as you are using git I don't really care :) [10:36:47] <elenril> o_0 [10:37:11] <elenril> yeah, i was just doing to say i'd prefer doing it vim [10:37:15] <Kovensky> git add -p doesn't seem to have line accuracy, though I only read the short description [10:37:16] * elenril should rtfm more often [10:38:02] * Kovensky goes to college :V [10:38:06] <peloverde> 'e' puts it in line by line mode [10:38:38] <elenril> this is awesome [10:38:53] <elenril> why are people still using svn? </troll> [10:42:20] <jai> because svn has revision numbers </lame-retort> [10:53:01] <pJok> ffmpeg should use cvs </lame-troll> [12:22:22] <CIA-81> ffmpeg: conrad * r22889 /trunk/libavformat/ (oggdec.c oggdec.h): oggdec: Remove write-only variable [12:22:23] <CIA-81> ffmpeg: conrad * r22890 /trunk/libavformat/oggdec.c: oggdec: Fix duration calculation if the last page in a file has no granule [12:22:24] <CIA-81> ffmpeg: conrad * r22891 /trunk/libavformat/oggdec.c: oggdec: Move warning about missing granule to the correct place [12:22:24] <CIA-81> ffmpeg: conrad * r22892 /trunk/libavcodec/vp3.c: vp3: Remove internal debug statement [12:22:25] <CIA-81> ffmpeg: conrad * r22893 /trunk/libavcodec/vp3.c: [12:22:25] <CIA-81> ffmpeg: vp3: More buffer length checks [12:22:25] <CIA-81> ffmpeg: .5% slower to fix some crashes on invalid streams [14:16:26] <BBB> superdump: ping, how's marcelo's qualification task going? [14:17:45] <superdump> he contacted me asking a few questions, i saw it late at night a couple of nights ago and only responded when i remembered last night [14:17:57] <superdump> i haven't seen anything more code-wise yet though [14:18:08] <superdump> we'll see [14:19:02] <BBB> can you ask him to be on irc? [14:19:12] <BBB> it'd be useful to be able to discuss with him and see how good he really is [14:19:34] <BBB> as in: does he understand C? does he get ffmpeg? does he understand how you'd write a decoder, basics? can he read specs? etc. [14:52:29] <superdump> BBB: true [14:52:49] <superdump> i don't know that he'll/i'll have time for that before the deadline though :/ [14:53:02] <BBB> for the qualtask, you mean? [14:53:03] <BBB> that's true [14:53:08] <BBB> that's why I want at least a feel of his skills [14:53:20] <BBB> I did it lastyear, just sit with the student on IRC for a night discussing his qualtask [14:53:37] <BBB> was very enlightening [14:55:27] <wbs> BBB: in a positive or negative way? :-) [14:55:40] <BBB> unfortunately that was in a negative way [14:56:11] <wbs> ok, but it's at least good to be enlightened about such things as early as possible [14:58:30] <BBB> exactly [20:17:15] <bcoudurier> hi guys [20:17:39] <BBB> hello bcoudurier [20:17:50] <BBB> do you know anything about mchinen's qualtask for gsoc? [20:18:00] <bcoudurier> sure [20:21:05] <BBB> how's he progressing? [20:31:15] <bcoudurier> not much yet [20:37:12] <CIA-81> ffmpeg: mstorsjo * r22894 /trunk/libavformat/mov.c: [20:37:13] <CIA-81> ffmpeg: Parse strf mov atoms [20:37:13] <CIA-81> ffmpeg: This fixes roundup issue 1270. [20:42:50] <wbs> hooray, my first attempt at meddling with mov containers \o/ [20:43:02] <BBB> \o/ [20:43:13] <BBB> on to RE'ing codecs! [20:43:29] <BBB> before you know, you'll be messing with fuzzy SSE3 code that nobody including you understands [20:45:29] <wbs> yeah, RE'ing codecs (or generally implementing stuff that has got proper specs) would be really interesting, too [20:45:41] <wbs> let's see when I get a bad enough itch that I try to scratch :-) [20:49:50] <saintd3v> BBB: black magic :O [20:50:07] <BBB> isn't most of ffmpeg black magic? [20:53:43] <wbs> BBB: btw, do you know someone who knows rtp/aac in intimate detail? [20:53:55] <BBB> luca abeni [20:53:56] <wbs> (I'm wondering about a thing that I didn't find any answer to in the RFCs) [20:54:19] <BBB> luca abeni is our rtp god [20:54:34] <BBB> but you can always try and maybe one of us knows [20:55:03] <Kovensky> isn't luca lu_zero [20:55:10] <BBB> that's luca barbato [20:55:39] <wbs> ok - I discussed this thing with peloverde earlier today... in AAC, the encoder inserts some undefined number of samples at the start of the stream (that the decoder actually outputs) [20:56:08] <wbs> to get back to proper sync, the number of extra samples need to be communicated out of band in some way, and these should ideally be dropped before returning them to the user [20:56:37] <wbs> for mp4, this can be done with edit lists, but if doing a rtp stream with aac audio, how is this delay communicated? [20:57:07] <BBB> aha [20:57:13] <BBB> I would expect the SDP to contain that information [20:57:38] <BBB> not sure where exactly, though... [20:57:43] <wbs> one guess is that one should offset the timestamps by the number of inserted samples, so that the decoded stream seems to start n samples earlier than it actually does, so that the first user-inputted sample lands at the correct timestamp [20:57:51] <wbs> yeah, that was my guess too, but didn't find anything such [20:58:59] <BBB> hm, ok, so I guess ask luca abeni then [20:59:30] <wbs> ok, will do :_) [21:03:22] <Kovensky> <@BBB> that's luca barbato <-- well... he IS luca :> [21:03:26] <Kovensky> just the wrong luca =p [21:03:31] <BBB> indeed [21:03:55] <wbs> good thing that both of them work with rtsp/rtp, too ;P [21:04:15] * Kovensky wonders if one is a fork() of the other [22:59:49] <CIA-81> ffmpeg: bcoudurier * r22895 /trunk/ffmpeg.c: [22:59:49] <CIA-81> ffmpeg: Take ticks per frame into account when warning about difference between [22:59:49] <CIA-81> ffmpeg: container and codec frame rate. [23:00:53] <Kovensky> what is "ticks per frame"? [23:01:24] <Kovensky> the length of a CFR stream's frame in time_base units? [23:48:52] <ramiro> in case anyone is interes in microsoft's smooth streaming whatever for silverlight: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=1371 [23:50:36] <ramiro> there's some code that the user in the forum says could be made lgpl, even though the original code uses creative commons for noncommercial use (which i believe might not be compliant to the lgpl)

1 0

IRC log for 2010-04-15
by irc＠mansr.com 16 Apr '10

16 Apr '10

[00:00:53] <BastyCDGS> anyway, even if not, if we're using sse then we should also use march=pentium3 since pentium 3 is required as mininum anyway [00:01:12] <BastyCDGS> and thus allows gcc to use other stuff which is non-sse specific in the p3 [00:06:55] <BastyCDGS> lol [00:06:58] <BastyCDGS> according to: [00:07:01] <BastyCDGS> http://gcc.gnu.org/ml/gcc/2002-12/msg00235.html [00:07:18] <BastyCDGS> -march=pentium3 equals exactly -mcpu=i686 -msse [00:07:44] <BastyCDGS> mcpu == march [00:08:42] <BastyCDGS> although the reply post states it isn't the same, more like that what I stated above [00:09:11] <BastyCDGS> i.e. msse just enables sse instruction set and doesn't force normal p3 instruction set automatically [03:36:09] <ramiro> j-b: my fault, patch awaiting at "[PATCH] Fix function parameters for rgb48 to YV12 functions." [03:36:27] <ramiro> too busy/lazy to do anything about it. I'm currently patching my 64-bit builds for this. [05:45:35] <_av500_> http://newteevee.com/2010/04/14/did-google-just-kill-ogg-theora/ [05:45:56] <_av500_> kshishkov: SCNR [05:46:45] <kshishkov> that site seeks dubious fame [05:47:05] <kshishkov> please tell me when they post something about DN Forever [05:53:21] <superdump> mornin [05:53:24] <superdump> g [06:48:18] <KotH> salut mes enfants [06:48:46] <kshishkov> shalom, goyim [07:00:44] <Tjoppen> hej barn [07:01:43] <kshishkov> hej hej [07:02:26] * kshishkov kan få ungdombiljett [07:02:59] <scaphilo> good morning [07:03:06] <kshishkov> if you say so [07:03:16] <thresh> well it is simply not true. [07:03:34] <scaphilo> my openloop transcoder works quite fine now :-) [07:03:38] <jai> thresh: fell of the bike again? ;) [07:03:43] <scaphilo> not perfect yet [07:04:02] <scaphilo> :-) what bike [07:04:09] <thresh> jai: no. no morning can be good. [07:04:31] <thresh> though i'm still in pain [07:04:34] <scaphilo> anyway good (GMT)morning [07:07:08] <KotH> thresh: pain? [07:07:24] <thresh> KotH: http://fear999.users.photofile.ru/photo/fear999/150396127/159361076.jpg [07:07:28] <KotH> scaphilo: good (CEST) morning to you too [07:07:30] <thresh> that's me. [07:08:05] <kshishkov> at least bike seems to be not harmed [07:08:10] <KotH> someone is throwing a bike at you, while you're sleeping on the ground? [07:08:15] <KotH> how mean! [07:08:20] <thresh> i stopped there to pick up a coin. [07:08:22] <scaphilo> :-) [07:08:27] <jai> thresh: ah :| [07:08:45] <thresh> and what more cool is I have a video of that accident from my helmet cam :) [07:08:49] <KotH> thresh: i hope no major injuries? [07:08:54] <jai> that's the one i saw [07:08:57] <jai> epic [07:09:34] <jai> meh [07:09:39] <thresh> KotH: just a tension in a wrist plus some abrasions on my knees. [07:09:56] <thresh> and a broken helmet visor [07:10:16] <KotH> hmm.. the visor is the only thing that wont fully heal... [07:10:26] <scaphilo> may i transcode you video plz [07:10:42] <kshishkov> KotH: in Russia people can be replaced [07:10:51] <kshishkov> visors can't though [07:12:20] <scaphilo> http://www.hirnfick.to/Videos/2135/schlag_den_raab__mountainbike_unfall.html [07:12:28] <KotH> be glad that you're not in china, where people are expendable materials [07:12:50] <kshishkov> KotH: no big difference [07:17:10] <scaphilo> is there a good video analysing tool? where i can step thorugh the vidio frame by frame? [07:17:24] <scaphilo> not i frame by i frame [07:17:50] <KotH> yes, mplayer [07:17:53] <kshishkov> xanim could [07:18:03] <jai> scaphilo: ffplay, s [07:18:10] <thresh> vlc also can do that [07:18:39] <scaphilo> oh ok thx [07:18:49] <KotH> alternatively, you can decode the video into raw bitmap pics, and step trough these [07:29:12] <scaphilo> thresh: how would you do that with vlc? [07:58:19] <j-b> ramiro: bad ramiro :) [08:27:56] <CIA-81> ffmpeg: gb * r22883 /trunk/libavcodec/h264.c: H.264: move avctx->refs init before AVCodecContext.get_format(). [08:31:36] <CIA-81> ffmpeg: gb * r22884 /trunk/libavcodec/h264.c: H.264: move avctx->{profile,level} init before AVCodecContext.get_format(). [08:47:26] <j-b> scaphilo: 'e' hotkey [08:48:18] <scaphilo> j-b:thx very much :-) [09:18:57] <lu_zero> wbs: ping [09:19:11] <wbs> lu_zero: pong [09:32:18] <lu_zero> wbs: diego couldn't reproduce your issue with quicktime [09:33:03] <wbs> lu_zero: hmm, the tcp interleaving thing? sure that his quicktime actually tried the interleaved mode? [09:33:25] <lu_zero> he put it in http tunnel mode [09:33:34] <lu_zero> at least he's quite sure about it [09:34:17] <wbs> ok... it would be interesting to get a packet capture of that one, to see whether the qt player manually specified the interleaving channel ids in that case [09:35:23] <lu_zero> once he got his house wired back hopefully we could ask directly to him ^^ [09:37:06] <lu_zero> btw, do you have knowledge of the dss sources? [09:37:24] <lu_zero> I'm trying to fix the rtp_port naivety but I'm out of sane ideas [09:37:33] <wbs> what naivety is that? [09:42:57] <lu_zero> wbs: basically it does some kind if bookkeeping but assumes all the ports are dedicated to the application [09:43:10] <lu_zero> thing that could be far from true [09:44:18] <lu_zero> the simplest way to solve that case is to preallocate them and do actual bookkeeping on that [09:45:39] <wbs> ok, so what's the actual problem scenario? [09:46:23] <lu_zero> thing about somebody using the streaming server and other servers [09:46:53] <lu_zero> both servers bind with reuse the same udp port and you get a clash [09:47:17] <wbs> ah, I see.. [09:48:25] <lu_zero> so I'm trying to figure out what the others were doing to address that issue [09:48:57] <wbs> on that note, btw, it would be good to make lavf/rtsp start from some random port, since it otherwise uses the same client port each time. and if repeatedly connecting to dss to watch something, then stopping, and starting a new stream, dss might not have noticed that the old stream has stopped [09:49:13] <wbs> so the client receives rtp packets from both the old and the new stream at once, which doesn't work too well [09:50:06] <lu_zero> that is a similar issue [09:50:15] <wbs> yeah [09:50:36] <wbs> but as an answer to your question, no, i'm not familiar with the dss code at that level so I can't really say what they do or don't do [09:51:17] <lu_zero> you'd be more annoyed to have a pool of udp ports allocated for future usage [09:51:35] <wbs> yeah, that's no good solution either [09:53:50] * lu_zero is thinking about binding at will and just hope the clients support rfc3605 ... [09:53:57] <lu_zero> that is the cleanest solution [09:55:41] <wbs> so you'd try to bind one port for each of rtp and rtcp, but disregard the normal assumption that they should be consecutive and the rtp one be even? [09:57:00] <lu_zero> that would make the server simpler but requires the client to support it [09:57:12] <lu_zero> yet that rfc seems quite sip oriented [09:58:38] <lu_zero> I'm quite out of sane ideas on how to fix sanely this issue [09:59:45] <wbs> would it be possible to first try the whole range for available rtp+rtcp ports in the normal fashion, and only revert to mismatched ports requiring that rfc if there are no free n,n+1 ports available? [10:00:17] <wbs> that is, if some odd port happens to be in use, you'd still get normal port numbers for everything else, as long as they're not totally exhausted? [10:06:33] <lu_zero> uhmmm [10:20:26] <lu_zero> rfc3550 chapter 11 frees me =E [10:24:26] * lu_zero now changes ffmpeg and feng accordingly [10:51:32] <wbs> what conclusion did you get from that chapter, and what are you going to do? [10:53:39] <lu_zero> rtpproto will have rtp and rtcp local port as parameters [10:54:07] <lu_zero> if you set none two random port will be bound [10:54:53] <lu_zero> if you set rtp alone it will try to bind that port and port+1 as now [10:55:08] <lu_zero> if you set both it will try to bind accordingly [10:55:24] <wbs> ah, that sounds reasonable [10:57:04] <lu_zero> yup [10:57:29] <lu_zero> hopefully [12:36:35] <j-b> lu_zero: if I pass "rtsp://193.126.232.33/pgrande" to url_open, it doesn't seem to open it. Any idea why? [12:43:29] <wbs> j-b: rtsp is a muxer/demuxer, not an urlprotocol, so you need to open a full demuxer with av_open_input_file [12:43:58] <wbs> and since it has the AVFMT_NOFILE, you're not supposed to open the ByteIOContext yourself, since the muxer does that itself internally [12:45:18] <j-b> hmm, that might explain :) [12:46:16] <j-b> wbs: thanks. [13:13:56] <bilboed-pi> __gb__, ping [13:17:30] <__gb__> pong bilboed-pi [13:17:42] <CIA-81> ffmpeg: gb * r22885 /trunk/libavcodec/h264.c: H.264: cosmetics (vertical align). [13:17:55] <bilboed-pi> __gb__, is there a software-only backend for vaapi ? [13:19:06] <bilboed-pi> __gb__, so one can test vaapi frontends without having a compatible card (or driver) [13:19:07] <__gb__> bilboed-pi, no, but this is something I would liked to have (at least for testing the encoding stuff without HW) [13:19:20] <bilboed-pi> ok [13:19:45] <__gb__> someone could write it thoug, something like what bellagio is for openmax [13:19:57] * bilboed-pi pukes at mention of bellagio [13:20:00] <bilboed-pi> thx [13:22:36] <__gb__> on the other hand, VA-API normally supports a large set of desktop GPUs nowadays :) [13:23:44] <bilboed-pi> is there a document/site listing all supported backends/gpus ? [13:24:56] <__gb__> http://www.freedesktop.org/wiki/Software/vaapi -- the SW users list is not up-to-date though [13:25:34] <__gb__> if you think it needs more details, just tell, thanks [13:26:35] <__gb__> hopefully, 3 more drivers would come in a few months [13:29:15] <Compn> http://samples.mplayerhq.hu/V-codecs/mj2c.avi [13:29:27] <Compn> there, an avi jpeg2000 sample :P [13:31:03] <CIA-81> ffmpeg: rbultje * r22886 /trunk/libavformat/rtpdec_xiph.c: [13:31:03] <CIA-81> ffmpeg: Remove useless assert(), since this can (in theora) be used for any Xiph [13:31:03] <CIA-81> ffmpeg: codec, so there's no reason to (invalidly) limit it to only Theora. [13:31:03] <CIA-81> ffmpeg: Also fixes issue 1880 (assert triggers on -DDEBUG + Vorbis). [13:36:45] <bilboed-pi> __gb__, ok, thx [13:48:50] <lu_zero> wbs: how did you manage to have dss get confused about opened rtp ports? [13:50:37] <wbs> lu_zero: it doesn't always notice that the client has disconnecting, so it keeps sending rtp packets to the port pairs for some time afterwards... so if I connect to the same server from the same client again, and the client uses the same port numbers as the previous attempt, I get the packets belonging to the previous session, too [13:50:55] <lu_zero> uhmm [13:51:09] <lu_zero> I'm not sure how I could fix that [13:51:39] <lu_zero> and after I'm finished with this probably we'll need to check how many incompatible server would break [13:51:52] <wbs> no, neither do i :-) one band-aid fix would be to make lavf choose a start port randomly, so it doesn't always start using the same port [13:52:52] <lu_zero> as standard rtsp server I'm considering dss feng google and gst [13:53:07] <lu_zero> I'm missing others? [13:53:35] <wbs> what's the google rtsp server based on? weren't they using dss/qtss earlier? or is it derived from that one? [13:55:26] <lu_zero> wbs: did not investigate much [13:55:31] <lu_zero> it seems quite standard [14:45:24] <lu_zero> wbs: ok, now I need some public servers =} [14:46:17] <lu_zero> dss pukes on rfc3550 =_= [14:47:47] <lu_zero> or not? [14:50:57] <lu_zero> http://pastie.org/921333 pukes indeed... [16:34:17] * elenril facepalms [16:34:26] <kshishkov> good greeting [16:34:36] <elenril> hey kshishkov [16:34:55] <elenril> answer me - why are people putting config files under /usr/ [16:35:14] <kshishkov> it's user data? [16:35:15] <elenril> and where can i get some of the stuff they're smoking [16:35:42] <kshishkov> some people thought that --enable-shared was to compile _redistributable_ version of FFmpeg [16:36:48] <elenril> non sequitur? [16:37:45] <kshishkov> RTFM [16:41:57] <Kovensky> <+elenril> answer me - why are people putting config files under /usr/ <-- kdm does it, it must be good rite [16:42:05] <elenril> wut [16:42:14] <elenril> it didn't last time i used it [16:42:38] <elenril> srsly what's WRONG with freedesktop people [16:43:18] <kshishkov> ask gb [16:44:23] <Kovensky> elenril: /usr/share/config/kdm/kdmrc [16:44:42] <elenril> o_0 [16:46:25] <Kovensky> there are a lot of kde files there actually [16:46:47] <Kovensky> @ /usr/share/config [16:47:58] * kshishkov checks his notes for "KDE sucks" entry and finds a lot of duplicates [16:48:02] * elenril doesn't even have a /usr/share/config [16:49:56] * Kovensky wonders how many "Gnome sucks" entries are in those notes [16:50:22] <kshishkov> maybe 1/4th of "KDE sucks" notes [16:50:45] <kshishkov> Motif in Ubuntu sucks too [16:51:38] <pJok> /etc wasn't good enough for some people [16:52:12] <thresh> well you can put read-only 'default' stuff into usr [16:52:15] <pJok> /opt was also silly [16:53:00] <pJok> oh and /usr/local/etc [16:53:59] <elenril> thresh: yeah, they say those aren't really config files [16:54:22] <elenril> for some reason i think it's BS [16:54:26] <thresh> you may as well say ffpresets are configs :-) [16:54:33] <thresh> as they really are [16:55:20] <elenril> no they're not? [17:18:00] <BBB> dgt84: do you want to do another blind test, same as last time? [17:18:53] <dgt84> BBB, sure, though I'm not sure how Michael played both files at the same time, one in each ear to hear differences between the two [17:19:02] <BBB> I'd like to know that also [17:23:39] <Kovensky> o_O [17:34:53] <dgt84> BBB, you can load both files into Audacity and then set one to be 100% left and the other to be 100% right [17:35:02] <DonDiego> elenril: /usr/local/etc/ is a standard location for config files [17:37:22] <elenril> DonDiego: i was talking about /usr/lib/X11/xorg.conf.d/ [17:37:51] * elenril wonders where to get docs for quartz.dll [17:38:43] <kshishkov> sounds like VfW API [17:38:52] <elenril> yeah [17:38:59] <BBB> dgt84: ok, so what's your impression? [17:39:02] <kshishkov> I use mplayer/loader/vfw for it :) [17:39:15] <elenril> kshishkov: i'm hacking wine [17:39:31] <elenril> want to get videos to work in R11 [17:39:46] <kierank> no [17:43:31] <BBB> dgt84: I don't hear much of a difference tbh [17:45:09] <dgt84> BBB, yeah I'm trying really hard here but am having a lot of trouble hearing much difference between any of the files... [17:46:03] <BBB> ok, well, at least my patch doesn't make it worse anymore then [17:46:07] <BBB> maybe the input quality is too good [17:46:08] <dgt84> If I had to guess I'd say r3 sounds worst to me [17:46:11] <BBB> it's postfilter after all [17:46:49] <BBB> 3 is the one without postfilter, so now the result becomes good then... [17:46:50] * BBB happy [17:47:15] <dgt84> yeah that's about the best I can say at this point - will mail the list [17:47:59] <dgt84> I should note the office is quite noisy here and I have fairly cheap headphones, so maybe a real audiophile is what you need ;-) [17:48:13] <kshishkov> noooooo [17:48:32] * Kovensky queries one of the audiofags he knows [17:48:35] <BBB> well there is one [17:48:39] <BBB> kshishkov: go go go! [17:48:41] <BBB> test please [17:48:41] <BBB> thanks [17:48:48] <BBB> kthx!!1one [17:49:16] <kshishkov> well, my current DSP is too noisy by itself [17:49:20] <elenril> anyone got directx sdk installed? [17:50:01] <BBB> kshishkov: oh ome on you've gotten lazy ;) [17:50:38] <kshishkov> BBB: I'm also original ffaacenc author, so I refrain from testing audio quality now [17:50:50] <kshishkov> and I'm always lazy [17:50:53] <BBB> haha that explains [17:51:03] * pJok blames kshishkov for all the bad in the world [17:51:23] <pJok> you can take it, its less than you are used to seeing you live in ukraine ;) [17:51:28] * kshishkov balmes Denmark [17:52:01] <kshishkov> good typo [18:18:19] <BBB> ** Unknown command `@headitem' (left as is) (l. 225) [18:18:32] <BBB> is that normal? or is my htmlgen thing too old? [18:18:49] <kshishkov> look at the output [18:18:55] <kshishkov> probably it's too old [18:23:02] * BBB wants his qcelp postfilter patch in [18:23:03] <BBB> htmnl [18:23:15] <BBB> that was an interesting typo [18:23:26] * kshishkov wants WVP2 support patch in [18:23:44] * mru wants a pony [18:24:18] * kshishkov has Dalahärs [18:27:13] <mru> häst [18:27:25] <kshishkov> sorry [18:27:43] <kshishkov> still better than a pony [18:28:27] <CIA-81> ffmpeg: rbultje * r22887 /trunk/libavformat/ (rtsp.c network.h): [18:28:27] <CIA-81> ffmpeg: Fix compile error on cygwin where ETIME is missing (because it's a WSA error). [18:28:27] <CIA-81> ffmpeg: This patch also changes FF_NETERROR() to be an AVERROR(), i.e. it is always [18:28:27] <CIA-81> ffmpeg: negative, whereas it was previously positive. [18:47:17] <BBB> kshishkov: did you contact sumit regarding his soc project? [18:47:28] <kshishkov> no [18:47:39] <BBB> could you please? otherwise I'll move him to the "no" part of the list [18:47:51] <kshishkov> why can't you do that? [18:47:55] <BBB> I already did [18:47:58] <BBB> he didn't respond ;) [18:48:06] <BBB> I was hoping he'd listen to you since he wants you to be his mentor [18:48:14] <kshishkov> unlikely [18:48:19] <mru> then he's out imo [18:48:21] <BBB> ok, so no then? [18:48:26] <kshishkov> anyway, I'll be offline till Tuesday [18:49:25] <Kovensky> kshishkov: what happen [18:49:40] <kshishkov> Kovensky: countryside [18:49:49] <Kovensky> oic [18:50:04] <Kovensky> have fun :> [18:50:12] <kshishkov> I definitely won't [18:50:19] <Kovensky> lol [18:50:24] <Kovensky> then why are you doing this :P [18:50:52] * mru is reminded of torchwood episode titled "countrycide" [18:50:52] <kshishkov> some things are done without consent of all people involved [18:51:35] <kshishkov> mru: wanna compare Swedish and Ukrainian countryside? [18:52:03] <mru> no [18:52:13] <kshishkov> neither do I [18:52:30] <mru> but you're in a position to do so [18:52:39] <mru> you've at least traveled through some swedish countryside [18:52:47] <kshishkov> it was even worse last year when I got there one day after I just returned from Stockholm [19:00:10] <thresh> yeah ukrainian countryside is even worser than russian one [19:00:26] <kshishkov> at least some people are working there [19:01:35] <thresh> i would enjoy living outside a big city oh wait i already do [19:02:02] <mru> living _in_ a small city is much better than living _outside_ a big one [19:02:26] <mru> I've never lived in a big city so I can't compare that [19:02:31] <kshishkov> what about living in rather rural area _inside_ big city? [19:02:41] <mru> we don't have that over here [19:02:44] <thresh> guess it really depends on a country [19:02:47] <mru> well, there's Hyde park [19:03:11] <thresh> there's no life outside Moscow here [19:03:26] <kshishkov> and St. Putinsburg [19:03:27] <thresh> only forests, oil and snow. [19:04:26] <kshishkov> and undead villages where people drink samogon [19:04:36] <kshishkov> and vote for Edinaya Rossiya [19:05:10] <thresh> yes, villages nearby oil rigs. [19:05:37] <mru> are those the lone lights you see if you fly over siberia at night? [19:06:30] <thresh> those could also be fires from GULAG burning dissidents. [19:06:51] <kshishkov> or villas of oil rig owners [19:08:47] <kshishkov> but some Moscow scientists believe that there's some life outside MKAD [19:09:39] <thresh> i've heard british scientists are helping them, too. [19:09:39] <kshishkov> maybe even intelligent life [19:15:50] <Kovensky> http://feedproxy.google.com/~r/ConfusedOfCalcutta/~3/Hg9qIrc9whA/ lolcopyright [20:56:26] <ubitux> hi [20:57:34] <BBB> hi [21:00:21] <merbanan> hi [21:01:51] <Kovensky> lo [22:53:50] <j-b> ramiro : cmp %r8d, %rax [22:53:55] <j-b> this is what fails [23:02:02] <Compn> `-absf bitstream_filter' [23:02:03] <Compn> Bitstream filters available are "dump_extra", "remove_extra", "noise", "mp3comp", "mp3decomp". [23:02:16] <Compn> are those the only bsfs available? [23:06:26] <bcoudurier> hey [23:06:45] <Compn> a non automated greeting from bcoudurier, nice [23:06:47] <Compn> :) [23:08:39] <janneg> or he just changed the greeting in the script [23:11:05] <Dark_Shikari> could be, we'll figure out soon enough [23:11:07] <Dark_Shikari> or he made it rotating

1 0

IRC log for 2010-04-14
by irc＠mansr.com 15 Apr '10

15 Apr '10

[01:04:54] <astrange> how do you test a lavfi filter? i see client code in ffplay but not ffmpeg [03:21:47] <ShadowJK> Anyone know what vp8 is? Presumably on2... [03:21:51] <ShadowJK> I'd assume NIH h264 [03:23:06] <peloverde> I think there are bigger mysteries afoot: http://archosfans.com/wp-content/uploads/2010/04/gen_8_china4.jpg [03:28:56] <Vitor1001> ShadowJK: vp8 is very likely just an improved vp3 [03:29:26] <Vitor1001> It would be hard otherwise to avoid some random patent bitting on2 [03:30:52] <peloverde> there is this totally unsubstantiated notion that VP8 doesn't step on any non-on2 patents [03:30:52] <Vitor1001> why would they be stupid? [03:31:00] <peloverde> it may not have been intentional [03:31:10] <Vitor1001> do you think they have that many patents to defend themselves? [03:31:18] <peloverde> look at VC-1 which was supposed to be patent free [03:31:30] <peloverde> or microsoft patents only [03:31:34] <Vitor1001> VC-1 wasn't designed to be patent-free [03:32:16] <Vitor1001> probably whoever designed it could pretty well expect it was covered by some unknown-to-them patents [03:32:37] <Vitor1001> but why care? MS has a big patent portfolio to fight back whoever tries to sue them. [03:32:56] <peloverde> not necessarily, not all of the litagents make products [03:33:10] <peloverde> some of them only collect IP and license it [03:33:14] <Vitor1001> Are there video coding patent trolls? [03:34:42] <peloverde> There are university held patents, sometimes those get sold [03:35:09] <Vitor1001> :p [03:35:10] <peloverde> isn't that how eolas got their plugin patent [03:35:16] <Vitor1001> Great use of public money [03:36:10] <peloverde> Presumably if the public funded the universities more they wouldn't have to sell off their patent portfolios [03:36:59] <peloverde> On2 has been pimping vp8 since way before the google takeovers tuff started [03:37:18] <peloverde> there must be some reason why they haven't actually released anything [03:37:24] <Vitor1001> I know. But never releasing. [03:37:39] <Vitor1001> BTW, there is a rumor google will opensource vp8 mid-may [03:38:31] <Vitor1001> http://arstechnica.com/open-source/news/2010/04/google-planning-to-open-the… [03:39:14] <peloverde> there have been rumors that google will opensource vp8 for months [03:39:59] <Vitor1001> Actual rumors or "if I were google ..." [03:40:01] <Vitor1001> ? [03:40:22] <peloverde> I heard "actual rumors" at FOSDEM [03:41:17] <Vitor1001> Well, the arstechnica one was a rumor with a fixed date ;) [03:45:50] <peloverde> Anyway I'm going back to my policy of ignoring VP8 until something, anything, is actually released, a spec, a binary decoder, some source, anything [03:47:20] <Vitor1001> OF course. It is just that speculating is fun... [03:49:20] <peloverde> We are missing a significant number of non vaporware formats, let's not get all worked up over a codec that hasn't managed to leave google/on2 doors [03:49:51] <hyc> but who uses those other formats? or requests them... [03:50:24] <Vitor1001> Which ones are not very rarely found on the wild? [03:50:34] <Vitor1001> MS Screen codec? VP7? [03:50:45] <Vitor1001> DolbyE? [03:51:27] <peloverde> HE-AACv2? [03:51:32] <peloverde> AMR-WB [03:51:43] <peloverde> AAC encoding, SBR encoding [03:51:55] <peloverde> really any lossy audio encoding [03:52:06] <hyc> amr-wb used to be supported [03:52:15] <hyc> then they switched to opencores [03:52:18] <hyc> oh well [03:52:22] <Vitor1001> yeah, encoding is progressing slowly [03:52:39] <Vitor1001> btw, how is HE-AACv2 going? [03:52:47] <peloverde> almost done [03:52:50] <Vitor1001> cool [03:52:54] <Vitor1001> any public branch? [03:53:11] <peloverde> not at the moment [03:53:29] <Vitor1001> is amr-wb used in the wild? [03:53:38] <peloverde> the code works pretty well but is still super ugly [03:53:59] <Vitor1001> code is born like that ;) [03:54:56] <peloverde> more missing format i've seen in the wild: 3GPP metadata, mp3pro, GoToMeeting [03:55:45] <peloverde> BSAC [03:55:55] <peloverde> LATM [03:56:49] <peloverde> icod [03:56:54] <Vitor1001> Ugh, I forgot the GoToMeeting one [03:56:55] <Vitor1001> :p [03:58:00] <Vitor1001> BBL [03:58:02] <Vitor1001> good night [03:58:08] <peloverde> good night [03:59:47] <hyc> AVERROR_PATCHWELCOME should be AVERROR_PATCHWILLBEMOSTLYIGNORED [04:00:57] <astrange> i thought there was a gotomeeting codec for quicktime but i can't find it [04:09:39] <peloverde> maybe it's time to make hyc a committer [04:12:39] <astrange> i just installed a bunch of commercial lossless qt codecs then realized they were probably in the mplayer package already [04:57:50] <hyc> peloverde: I guess that would help some, but not if every patch still needs to be reviewed before it's allowed to be committed [04:59:08] <peloverde> yeah but generally after two or three pings on a patch you can push it anyway under the doctrine of nobody else seems to care [04:59:53] <hyc> ahhh [05:00:21] <hyc> yeah that would help ;) [05:00:48] <kshishkov> peloverde: if you have commit rights [05:01:01] <peloverde> yes if you have commit rights [05:04:28] <av500> peloverde: what is the mystery afoot? [05:08:22] <peloverde> with multitouch are you moving to capacitive touch-screens? [05:11:01] <av500> I'd guess so [05:11:39] <peloverde> I mostly brought ti up for the sake of speculating about something that doesn't begin in V and end in 8 [05:12:00] <av500> ah :) [05:12:49] <kshishkov> peloverde: you can prematurely name that Theora2 anyway ;) [05:14:09] * peloverde declines to comment further on the vaporcodec [05:14:43] * kshishkov hasn't got a clue what peloverde is talking about anyway [05:15:28] <kshishkov> have we got netbooks on OMAP4 yet? [05:15:34] <av500> kshishkov: nope [05:15:45] <av500> but they will come [05:16:09] <kshishkov> d'you mean iPad? [05:16:13] <hyc> not this year I'd suspect [05:16:21] <hyc> all the initial allocation is to smartphones [05:17:03] <av500> hyc: hmm, not sure about that [05:17:10] <av500> kshishkov: but they wont be "netbooks" [05:20:11] <hyc> av500: what are you thinking of? [05:21:28] <av500> a netbook is by (current) market definition a small laptop running windows (7) [05:21:35] <av500> and that is unlikey to change [05:21:57] <av500> now, remove the keyboard and you suddently have a "tablet" which are all the rage [05:22:26] <peloverde> I'm more excited about LTE devices 3G is old hat [05:22:50] <hyc> ah. hohum. I wouldn't mind having a TouchBook based on OMAP4 [05:23:16] <peloverde> In The Feb 2010 Issue of the comsoc magazine there is a great article about LTE [05:23:33] <av500> hyc: sure, neither would I [05:23:56] <av500> but both of us are not "the customers" [05:24:05] <hyc> right [05:24:24] <hyc> and companies like that are far from the front of the line [05:24:37] <av500> customer see screen and keyboard, thinks word/excel [05:25:48] <hyc> well, the TB can be bought without the keyboard, just as a tablet [05:25:59] <hyc> personally I could never use it like that [05:26:33] <av500> so you are back at a linux running netbook... [05:27:11] <hyc> yep [05:28:47] * kshishkov wants ARM-based portable system that he can compile FFmpeg on [05:29:03] <hyc> you can compile ffmpeg on the touchbook [05:29:07] <hyc> if you have a lot of patience [05:29:36] <hyc> I rebuilt gcc and the 2.6.29 kernel on mine [05:29:37] <kshishkov> I started with PII-266 [05:29:46] <hyc> not the most thrilling useo f time [05:30:36] <hyc> not sure what real purpose tablets serve, don't like handwriting as an input method [05:30:36] <kshishkov> you can do something else on other hw [05:31:06] <hyc> and I'm not enough of an artist to take advantage of it for freehand drawing/sketching [05:32:59] <hyc> I'd like a portable machine with eyeglass display. I don't even think a foldable/rollable flexi screen would satisfy [05:35:47] <hyc> I didn't realize displays were such a touchy subject for kshishkov :P [06:03:33] <pJok> god morgon kshishkov :) [06:03:41] <kshishkov> goda morgnar [06:13:40] <ramiro> mru, j-b: there is no way to shut that warning up (at least last time I looked at gcc's code) [06:19:37] <ramiro> someone please tell BBB (when he's back) please commit. [06:20:19] <ramiro> and someone please tell him again what irssi is and why it's much better to leave a client always on =) [06:26:41] <jai> maybe he's using a laptop? [06:26:55] <av500> a Mac laptop even [06:27:06] <av500> and as they do not multitask.... [06:32:33] <superdump> iphone os 4 brings multi-tasking! [06:32:46] <av500> but it is not released yet [06:33:06] <av500> and apple did not mention irc as a supported background task [06:33:27] <av500> :) [06:33:35] <kierank> mac users: irc, is that a form of twitter? [06:34:03] <av500> @kierank: lol [06:34:27] <kierank> RT: @av500 @kierank:lol [06:34:47] <jai> #fail [06:36:49] <pJok> vp8 open source #rumors [06:38:02] * kshishkov thinks it may be the time to kick anybody who mentions Theora2 here [06:38:14] <merbzt> you just did [06:38:20] <pJok> KICK HIM! [06:38:22] <pJok> ;) [06:39:36] <av500> "...One of the most exciting innovations in VP8 is the constructed reference frame. A constructed reference frame is a frame of image data (a reference buffer) that's encoded into the bitstream but never displayed. It serves solely to improve the encoding of subsequent frames by providing an additional and hopefully better predictor than any previously transmitted "normal frames."... [06:40:17] <ramiro> kshishkov: we once talked about chanson. is this something related to your chanson, but in german? http://www.youtube.com/watch?v=U_j6q6GB0ZI [06:40:40] <merbzt> av500: well that was sort of interesting [06:41:00] <thresh> ramiro: if they sing about prisons, then yes [06:41:19] <kshishkov> ramiro: I cherish my ignorance of German language [06:41:26] <av500> merbzt: http://www.dspdesignline.com/howto/214303691 [06:41:50] <ramiro> thresh, kshishkov: I don't undertand german enough to understand the words, but the music sounds just as corny =) [06:42:19] <kshishkov> ramiro: music does not matter for Russian chanson anyway [06:43:17] <kshishkov> it may range from prison blues to j(ail)-pop [06:46:02] <ramiro> Kovensky: this sounds more like our brega... [06:46:38] <av500> well, element of crime is not about jail :) [06:46:57] <ramiro> av500: hmm, you're german, right? [06:47:02] <kshishkov> av500: "A New Take on Loop Filtering" is laughable - even RV4 uses loop filter that fits that description [06:47:20] <jai> kshishkov: that's marketing for you :) [06:47:25] <av500> ramiro: somewhat [06:48:50] <kshishkov> well, Russian chanson includes everything from songs about everyday life of Assi to the ballads about criminals like in Australia [06:49:39] <ramiro> av500: but you know the band? [06:49:47] <av500> yes [06:51:42] <kshishkov> av500: do you know what "Assi" in German means? [06:51:55] <av500> I can imagine [06:52:21] * ramiro is curious... [06:56:03] <kshishkov> av500: well, I just heard it's German equivalent of most of Ukrainian population (including Ukrainian president in youth) [06:56:23] <kshishkov> I just don't know how to translate it properly into English [06:56:29] <kshishkov> hoon? [06:56:49] <av500> well, the german assi is from "asozial" which is anti-social [06:57:36] <kshishkov> are those the people who seemingly do nothing but will be glad to lighten your burden of money and valuables in the dark? [07:05:00] <hyc> irssi? I just run finch in a screen session on my web server [07:05:05] <hyc> and ssh in [07:07:00] * kshishkov runs irssi in a screen session on his web server/rounter/the only x86 box and uses ssh too [07:15:34] <__gb__> pong superdump, sorry, I am not always at the office since bus drivers are on strike around here [07:15:45] <superdump> no problem :) [07:15:57] <kshishkov> PCI-Express bus or AGP bus drivers? [07:16:03] <kierank> lol country stereotypes ;) [07:16:07] <av500> french bus [07:16:18] <superdump> i was just wondering if that i965 h.264 branch affected the gma x4500mhd [07:16:26] <superdump> of libva [07:16:28] <kshishkov> ah, frech transport drivers seem to be always on strike [07:16:42] <kierank> kshishkov: french * seem to be always on strike [07:16:54] <ramiro> __gb__: les francais aiment la greve... [07:17:53] <kshishkov> kierank: english transport is not much better though [07:18:00] <__gb__> superdump, there probably are regressions for older G45, but I am not aware of any [07:18:12] <kierank> kshishkov: well of course [07:18:15] <__gb__> if you say so, then probably :) [07:18:40] <superdump> __gb__: well, i want to know is if that branch adds support for h.264 decoding using the gma x4500mhd [07:18:46] <superdump> or if it's already in master... [07:18:48] <superdump> :) [07:18:57] <superdump> or if neither [07:19:05] <kshishkov> __gb__: you should have an array of video cards (donated by vendors) to test it [07:19:17] <__gb__> kshishkov, our parisian transportation service also has a good technique: they can be on strike again to force management to pay their days they were on strike... [07:19:39] <kshishkov> ah, Paris [07:19:43] <kshishkov> that explains all [07:19:58] <__gb__> superdump, not yet, only for Arrandale/Carkdale platforms (Ironlake) at this time [07:20:12] <superdump> i wish they wouldn't use codenames all the time [07:20:14] <__gb__> they will support older G45 when the current code stabilises [07:20:17] <superdump> list the damn gpus :) [07:20:40] <__gb__> ok, I think this is Intel HD Graphics, the integrated GPU to Core iX :) [07:21:03] <superdump> after mine then [07:21:05] <superdump> hrm [07:21:11] <kshishkov> superdump: codenames are not bad when they applied correctly - like to furniture [07:23:38] <superdump> well, my issue is, it's a level of indirection [07:24:09] <superdump> when people look at their laptop to figure out if their gpu has hardware decoding support, they'll look at the gpu name, not try to figure out what codename was used for their whole chipset [07:25:06] <kshishkov> superdump: they look on the pasted label saying "Designed for Windows 98" or something [07:25:14] <astrange> they won't be able to figure out anyway because they have to know the level of the video being played [07:26:49] <__gb__> superdump, they will try to target support for older G45 by Q3 [07:27:12] <kshishkov> "by Q3"? in half a year? [07:28:08] <__gb__> interestingly, their implementation (at least on Arrandale), can cope with 1 HD + 1 SD stream simultaneously [07:28:24] <__gb__> kshishkov, yes, could be [ July - September ] :-/ [07:29:36] <kshishkov> __gb__: fine with me [07:29:58] * kshishkov does not own anything supported by vaapi anyway [07:31:04] <kshishkov> or anything that could be supported by it [07:31:57] <superdump> __gb__: the claims i saw about the gma hd was that it had ~50% better performance than the x4500hd though [07:32:07] <superdump> still, 1 HD would be nice [07:32:10] <superdump> :) [07:32:45] <av500> DTS/DCA has fixed block sizes? [07:32:49] <__gb__> :) [07:32:56] <kshishkov> nope [07:33:06] <kshishkov> its block size is stored in header IIRC [07:33:13] <av500> ok [07:33:34] <superdump> __gb__: thanks for the response though :) good to know roughly when it's due [07:38:08] <kshishkov> http://www.ubersoft.net/files/comics/hd/hd20100413.png?1271158276 [08:24:22] <Kano> hi, is there a time estimation when [08:24:27] <Kano> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086859.html [08:24:32] <Kano> will be merged? [08:24:52] <kshishkov> of course not [08:25:03] <Kano> i tested it with vlc and mplayer it works [08:25:07] <kshishkov> could be quite soon though [08:25:38] <Kano> would be fine, then i dont have to patch it everytime [08:26:42] <superdump> Kano: well, i guess as long as __gb__ is responsive to michael's reviews, it shouldn't take too long [08:26:47] <superdump> it's a small piece of code [08:27:22] <av500> he might be on strike [09:06:40] <mru> q [09:06:57] <peloverde> r [09:07:13] <pJok> s [09:08:34] <av500> t [09:10:26] <superdump> u [09:13:29] <saintdev> v [09:13:49] <__gb__> w [09:13:51] <elenril> c-c-combo breaker [09:16:43] <kshishkov> you could continue that till Ã¶ [09:17:00] <bilboed-pi> you have the whole of unicode if you insist [09:17:28] <kshishkov> no, our alphabet is from a to Ã¶ [09:17:38] <kshishkov> not from \u0000 to \uFFFF [09:17:47] <j-b> __gb__: tu pourrais au moins avoir un avatar :) [09:19:08] * __gb__ pige rien Ã ces interfaces et s'en fout :) [09:21:00] <j-b> :) [09:22:12] <kshishkov> varfÃ¶r talar ni pÃ¥ franska i svensk kanal? [09:22:16] * KotH is reminded of fried french... er.. french fries [09:22:20] * KotH is getting hungry [09:22:28] <av500> schoggi? [09:22:32] <kshishkov> * KotH is not getting Hungary [09:22:41] <KotH> av500: schoggi is energy, not nutrition [09:23:01] <kshishkov> av500: do you feast on shoggots now? [09:23:08] <KotH> kshishkov: been there, got it, didnt like it, left it [09:23:36] <av500> kshishkov: \\\ooo/// [09:24:14] <kshishkov> KotH: there is a saying that man should try everything in his life except folk dancing and visiting Ukraine [09:24:26] <kshishkov> av500: (,,;,,;,,) [09:24:44] <av500> kshishkov: nice [09:55:07] <Dark_Shikari> wooohooooo bikeshed arguments on ffmpeg-devel ML! [09:55:30] <kshishkov> again? [09:58:22] <mru> again implies they ended [09:59:00] <peloverde> bikeshedding, me still being up at 6 am, ... what else is new [09:59:53] * pJok hands Dark_Shikari a bucket of black paint [09:59:59] <peloverde> I have this gut feeling that one of these days this little coalition of ours is going to fall apart and we are going to split in 2-4 directions (forks) [10:00:02] <peloverde> but who knows its lasted this long [10:00:23] <kshishkov> pJok: the only proper paint for bikesheds is FalurÃ¶da [10:00:23] <mru> where would we go? [10:00:34] <pJok> hehe [10:00:45] <kshishkov> peloverde: we have ffmbc already [10:00:53] <mru> seriously, there's nowhere else to go [10:01:03] <mru> and our differences aren't that bad [10:01:20] <pJok> i've seen wrose [10:01:24] <pJok> worse* [10:01:41] <pJok> you agree on most things and you mostly agree to disagree on things you dont agree about [10:02:10] * kierank goes to register openffmpeg, netffmpeg and freeffmpeg [10:02:23] <peloverde> If there were a serious fork using git an interleaved swscale i'd jump [10:02:46] <mru> I could set up such a "fork" right there on ffmpeg.org :-) [10:03:05] <pJok> fffmpeg? ;) [10:03:07] <mru> you can help by preaching to diego and michael [10:03:58] <peloverde> I tried at delirium :) [10:04:04] <kshishkov> Kierank: you versions will lack H.263 decoder [10:04:19] <mru> peloverde: use more beer [10:04:41] <kierank> kshishkov: why h.263? [10:04:46] <kshishkov> peloverde: hint - Michael is more important [10:05:12] <kshishkov> kierank: dunno, but those BSD variant always seem to lack something substantial [10:05:27] <mru> yes, c99 support [10:05:38] <mru> but hey, they've got theo de rant [10:05:41] <mru> gotta be good [10:06:05] <pJok> mru, they will just reimplement ffmpeg if they think its the wrong license [10:06:38] <peloverde> I wasted a good day on PS tracking down a handful of bugs resulting from doing complex arithmetic manually [10:06:42] <pJok> and make their version almost, but not quite, compatible in arguments [10:06:46] * peloverde shakes fist at non-c99 systems [10:06:56] <kshishkov> pJok: well, someone should make swscaler LGPL [10:07:15] * mru wouldn't trust a compiler to do complex maths efficiently anyway [10:07:27] <pJok> kshishkov, first someone should do the "svn commit" and run ;) [10:07:50] <peloverde> I feel like it really shouldn't be that hard (which doesn't mean gcc does it right) [10:08:03] <pJok> mru, do you even trust gcc to do simple math efficiently? [10:08:30] <mru> no [10:08:41] <KotH> it might not been hard, but it's more complex than a simple "if this basic_block, then write this_code" [10:08:59] <Kovensky> lol de rant [10:09:19] <mru> pJok: how did you think I sped up the dca decoder by >4x? [10:09:24] <KotH> kshishkov: theo de rant? [10:09:34] <pJok> mru, prybar? [10:09:37] <peloverde> you reduce it to scalar arithmetic, then you remove all dead-state, that's how it gets done by hand [10:09:52] <Kovensky> * @peloverde shakes fist at non-c99 systems <-- the fun: there was actually a patch that implemented all log\d\d?f? functions for freebsd's libc... in 2006 [10:09:57] <Kovensky> it never got anywhere afaik [10:09:59] <mru> peloverde: and then you simd as much as possible [10:10:19] <peloverde> mru, yes, that's the second phase [10:11:03] <peloverde> I'm thinking about writing all new code with complex.h then converting to scalar once it's all been verified [10:11:47] <mru> especially when doing complex arithmetic, you'll often end up several independent operations [10:11:56] <mru> by careful register allocation you can simd those [10:12:20] <peloverde> that is true, but it's not like we use the autovectorizer anyway [10:12:29] <kshishkov> KotH: that's more correct version of Theo de Raadt name IIRC. Kinda Dalias for BSD [10:12:37] * peloverde remembers he has that half finished simd rdft patch [10:13:01] <peloverde> I really need to clone myself or something, too few hours [10:13:32] * pJok gets the cloning equipment from the basement [10:14:01] <kshishkov> peloverde: and I have half-finished VC-1 8x8 transform patch [10:14:26] * kshishkov does not think this world can hold more than one instance of him [10:14:53] * mru places a clone of kshishkov on mars [10:15:00] <mru> sorry about the ping time [10:16:32] <jai> DTN ftw :) [10:17:10] <peloverde> I wonder if there is a way we can find some new competent contributors [10:17:37] <mru> peloverde: huh? they're arriving all the time [10:18:05] <peloverde> not fast enough [10:19:11] <jai> post on reddit, that seemed to help vlc [10:20:02] <peloverde> At fosdem noticed an estimated 4:1 interest ratio from vlc to ffmpeg [10:20:12] <Dark_Shikari> that's because people like the frontends, not the backends [10:20:14] <peloverde> and it's probably lower once you factor out OGP :) [10:21:09] <kshishkov> time for FFplay G2 [10:21:23] <mru> we need a bigger video wall [10:21:28] <peloverde> clearly [10:21:34] <mru> more beagles and monitors, anyone? [10:22:07] <kshishkov> nah, we need holographic output this time [10:22:14] <peloverde> I know I was a recession recruit to FFmpeg and there have to be others who found themselves out of work and looking to keep busy [10:22:20] <Dark_Shikari> those are a little expensive [10:22:24] <jai> also free beer at ffmpeg's stall [10:22:37] <Dark_Shikari> btw, I may be able to get some funding for ffmpeg [10:22:46] <peloverde> I was actually thinking about doing stickers or something [10:22:48] <Dark_Shikari> I'm working with a guy who is currently getting money THROWN at him by creative to try to use their incredibly awful hardware [10:22:58] <Dark_Shikari> and "using their hardware" involves "making the decoder support what the hardware does" [10:23:02] <Dark_Shikari> and the decoder is ffmpeg [10:23:17] <mru> what does the hardware do? [10:23:37] <peloverde> gather dust? [10:23:47] <Dark_Shikari> I'm sorta under NDA, but I think it's just some box [10:23:47] <mru> ah, it's a roomba [10:23:58] <Dark_Shikari> and it has stuff like an (insanely awful) encoder [10:24:03] <peloverde> FFroomba [10:24:04] <Dark_Shikari> which can only do slices if FMO is on [10:24:06] <Dark_Shikari> etc [10:25:03] <Dark_Shikari> I also wonder how much michael would charge for SVC [10:25:06] <Dark_Shikari> he quoted $10k for FMO [10:25:27] <peloverde> ahh FMO that brings back good memories of my early codec hacking [10:25:44] <Dark_Shikari> FMO might be useful if it wasn't baseline-only :/ [10:26:11] <peloverde> yes, the non main features of baseline that no one uses [10:26:13] <peloverde> once upon a time I started out with H.264 and ASP decoders [10:26:29] <mru> you're young [10:26:31] <peloverde> maybe sometime I'll get back to video [10:26:38] <peloverde> 2005 is half a decade ago [10:26:56] <mru> that's recent [10:27:09] <peloverde> It seems like a long time ago to me [10:28:37] <KotH> does anyone know a good explanation of unified diff format? i couldnt find one that's easy to understand and not a foot note in a huge document [10:28:55] <mru> the format is rather obvious to me [10:28:56] <KotH> need it as reference for in-house documentation [10:29:36] <KotH> the format is obvious if you come from unix, if you come from electronics or, heaven forbid, from windows, it's far from being obvious [10:29:53] <mru> wrong [10:30:00] <mru> the format has nothing unixy about it [10:30:14] <mru> if you know what it's supposed to represent, it should be obvious [10:30:26] <mru> if not, you've no business using a computer [10:30:29] <peloverde> it's very simplistic, more simplistic than non-unified diff [10:30:48] <KotH> mru: it is not unixy, but people with a unixy-mindset have less probs to grasp it [10:31:15] <KotH> bbl... lunch time [10:31:18] <mru> seriously, how any anyone not understand it? [10:31:25] <mru> -line to delete [10:31:27] <mru> +line to add [10:31:38] <mru> untouched context line [10:33:20] <kierank> [11:31] <@mru> seriously, how any anyone not understand it? --> needs some xml [10:33:22] <mru> @@ -old_line_num,old_num_lines +new_line_num,new_num_lines @@ comment [10:33:31] <mru> --- old filename [10:33:34] <mru> +++ new filename [10:33:37] <mru> that's it [10:34:09] <mru> http://gist.github.com/363107 [10:34:26] <mru> ^^ parser generator in xslt [10:34:56] <jai> ugh [10:35:30] <j-b> my eyes! [10:36:10] <kshishkov> hmm, kinda obvious [11:08:37] <KotH> mru: never underestimate the stupidity of average people [11:10:45] <twnqx> kierank: register ffmpeg-ng, too [11:11:25] <kshishkov> ffmpeg-next and ultimate-ffmpeg [11:11:40] <KotH> and ffmpeg-for-ever [11:11:47] <Tjoppen> mru: looks like it generates code for xml data binding, or? [11:13:15] <Tjoppen> we butted heads with xmlbeansxx for quite some time here, before we eventually grew fed up with its idiotic dependencies (JDK, Ant and Maven för a C++ library!?) [11:17:23] <mru> wow [11:18:18] <kierank> twnqx, which program uses -ng? [11:18:29] <twnqx> none (yet) [11:20:03] <kshishkov> yaffmpeg? [11:20:45] <pJok> ffmpeg-2010 [11:23:54] <KotH> pJok: ffmpeg-2013 "after the end of the world edition" [11:24:14] <pJok> that too [11:24:29] <pJok> and ffmpeg-classic [11:26:36] <kshishkov> don't forget ffmpeg-enterprise for mru/av500 [11:27:25] <mru> EEmpeg [11:27:30] <mru> enterprise edition [11:27:41] <_av500_> huh [11:27:48] <kshishkov> sounds like --FFmpeg [11:30:21] <KotH> FFmpeg/400 ? [11:30:42] <pJok> FFmpeg mainframe edition? [11:30:43] <kshishkov> exclusively for AIX? [11:31:04] <pJok> yes [11:31:16] <kshishkov> FFmpeg Transuranium [11:31:36] <kshishkov> (why settle for lighter metals?) [11:31:57] <pJok> hehe [12:08:13] <Kovensky> < kierank> twnqx, which program uses -ng? <-- lincity? :> [12:47:43] <mru> ping gsoc people [12:48:00] <Dark_Shikari> "gsoc people"; students? [12:48:12] <mru> no, admins/mentors [12:48:22] <Dark_Shikari> btw, mru, what do you know about explicit prefetch on modern cpus? [12:48:24] <kshishkov> wait till evening and BBB then [12:48:37] <mru> Dark_Shikari: that's a vague question [12:48:40] <Dark_Shikari> How many prefetches can said CPUs that you know about take at once, and what if you exceed the limit? [12:48:45] <Dark_Shikari> Do they queue them up, or ignore them? [12:48:47] <mru> we had a gsoc slot too many, right? [12:49:20] <kshishkov> wanna participate as a student? [12:49:23] <Dark_Shikari> lol [12:49:30] <Dark_Shikari> mru isn't in bloody school >_> [12:50:22] <kshishkov> there are public schools in Britain ;) [12:55:59] <mru> Dark_Shikari: there are as many answers to that question as there are cpus [12:56:05] <mru> and the values are rarely documented [12:56:19] <mru> publicly [12:56:21] <Dark_Shikari> For those you know about =p [12:56:40] <Dark_Shikari> for those you know answers to said questions for [12:56:43] <mru> I'd have to check the docs [12:58:21] <Dark_Shikari> I'd like to know for cortex and modern x86 chips [12:58:31] <mru> which cortex? [12:58:36] <mru> there's about a dozen of them [12:58:38] <Dark_Shikari> lol [12:58:43] <av500> M1 [12:58:45] <Dark_Shikari> The ones we care about, i.e. A8+ [12:59:32] <mru> there's a5, a8, a9, m0, m1, m3, m4, and r4 [12:59:42] <mru> and each of those has multiple revisions [13:00:01] <mru> and many of them are configurable by the silicon builder [13:00:35] <mru> cortex-a8 has 3 major revisions, each with rather different cache/memory interfaces [13:00:46] <Dark_Shikari> and? pick one [13:08:00] <Dark_Shikari> hmm. also, how long has __builtin_prefetch been around? [13:08:14] <mru> 3.x I think [13:08:29] <mru> varies depending on cpu [13:08:48] <Dark_Shikari> not talking about per cpu [13:08:52] <Dark_Shikari> I'm fine with it just ignoring it on old versions [13:08:55] <Dark_Shikari> I want to know when I can start using it [13:09:01] <Dark_Shikari> and know it won't fail to compile =p [13:09:18] <Dark_Shikari> hmm. seems to be 3.1 or 3.2 depending on which source [13:09:43] * Dark_Shikari goes with 3.2 [13:10:32] <Dark_Shikari> also, in the general case, are cache misses on stores "free" if we don't load from there for a while? [13:10:39] <Dark_Shikari> I would assume the cpu can pipeline them away [13:10:43] <Dark_Shikari> since there's no data dependency [13:18:55] <mru> miss on store depends on many things [13:19:14] <mru> often it's a per-page setting [13:19:22] <Dark_Shikari> explain? [13:19:29] <Dark_Shikari> how is whether or not it stalls the pipeline a per-page setting? [13:19:51] <mru> allocate-on-write is a per-page setting [13:20:11] <Dark_Shikari> allocate-on-write? I mean pages that are already allocated obviously [13:20:15] <Dark_Shikari> I mean "cache miss" not "page fault" [13:20:20] <mru> I mean cache line allocate [13:20:21] <Dark_Shikari> if I meant page fault, I would have said page fault [13:20:23] <Dark_Shikari> ah [13:20:25] <mru> it's common terminology [13:20:37] <Dark_Shikari> But why would that affect anything? [13:20:43] <Dark_Shikari> Even if it has to allocate a cacheline, there's no data dependency [13:20:46] <Dark_Shikari> it should happen in the background [13:20:50] <mru> sometimes it's better to let a miss on write simply write through [13:21:08] <mru> so suppose you do allocate on write [13:21:19] <mru> there are different ways of dealing with that [13:21:52] <mru> one way is to put the write in a store queue, issue the line fetch, and commit the store to cache once the line has been filled [13:22:04] <mru> the pipeline can then proceed without delay [13:22:10] <mru> some cpus do this [13:22:32] <mru> others simply block while waiting for the data to arrive [13:22:39] <mru> that's much simpler to implement [13:22:58] <Dark_Shikari> what do modern x86 chips do? [13:23:05] <mru> some non-blocking implementations have nasty bugs in unusual corner cases too [13:23:06] <Dark_Shikari> I would assume the former, since they like to do complicated things [13:23:36] <mru> it's good for performance too, so yes they probably do it [13:23:48] <Dark_Shikari> k, then I only have to prefetch for loads, not stores [13:24:11] <mru> some cpus do have special prefetch-for-write instructions [13:25:12] <Dark_Shikari> the next issue I have is the following corner case [13:25:14] <mru> and some have prefetch and mark as low priority [13:25:22] <mru> which is good when iterating over large blocks [13:25:32] <Dark_Shikari> suppose we're doing something simple like fetching the mvs for top left, top, and top right MBs [13:25:49] <Dark_Shikari> If we run the prefetch on "top left", we get all the MVs, unless it crosses a cacheline [13:25:55] <Dark_Shikari> then we don't [13:26:01] <mru> also don't forget predictive, speculative prefetching in some cpus [13:26:07] <Dark_Shikari> the question is whether it's worth running two prefetches (mv top left, and top right) [13:26:11] <Dark_Shikari> to catch that corner case [13:26:14] <Dark_Shikari> or whether it's a waste of time [13:26:32] <mru> how often do you reckon it happens? [13:26:35] <Dark_Shikari> my thought is that since we _wrote_ the cached data only one row ago, it's guaranteed to be in L2 (we're doing this to fetch to L1), so a miss couldn't be too expensive [13:26:45] <Dark_Shikari> But obviously it's expensive enough that prefetches are helpful [13:27:03] <Dark_Shikari> well, each row of an MB is 2 * 2 * 4 = 16 bytes of data [13:27:06] <Dark_Shikari> so it happens once every 4 MBs [13:27:26] <Dark_Shikari> for reference frames, every 32 MBs (2 bytes of data per MB) [13:27:34] <Dark_Shikari> so maybe worth it for MVs, maybe not for refs [13:27:40] <Dark_Shikari> it depends on how many prefetches the CPU will let us run at once [13:27:47] <mru> try both and compare [13:27:59] <Dark_Shikari> I need 3+3+6*2+2*2 prefetches at once, roughly [13:28:09] <Dark_Shikari> where "at once" means "in relatively close proximity" [13:28:25] <Dark_Shikari> i.e. within a space of 100 clocks [13:29:51] <Dark_Shikari> I wonder if this would be a reason to store MVs on a per-MB basis [13:29:56] <Dark_Shikari> instead of in an 2D array [13:30:08] <Dark_Shikari> i.e. [MB index][0 to 15] [13:30:16] <Dark_Shikari> This would be more friendly cache-wise: one cacheline per MB [13:30:33] <Dark_Shikari> currently it's up to 6 cachelines per MB for loading data, this would bring it down to 4 [13:40:54] <mru> BBB: ping [13:47:06] <Dark_Shikari> oh god cdecl [13:47:49] <Dark_Shikari> mv: int16_t (*mv[2])[16][2]; [13:47:50] <Dark_Shikari> int16_t (*l1mv[2])[16][2] = { h->fref1[0]->mv[0][h->mb.i_xy], h->fref1[0]->mv[1][h->mb.i_xy] }; [13:47:57] <Dark_Shikari> the latter warns about initialization from incompatible pointer type [13:50:03] <Dark_Shikari> mru: any idea? [13:50:27] <Dark_Shikari> ah, it seems I have to remove the "16" [14:08:08] <mru> lol, did you know there exists a Japan Highway Public Corporation Tokyo First Operation Bureau Facilities Maintenance Division [14:09:41] <kshishkov> sounds reasonable [14:10:06] <mru> now translate it to german [14:10:12] <kshishkov> one word? [14:12:27] <kshishkov> Russian establishment usually bear the names like "Federal X division of Federal organization Y of Russian Federation" [14:13:17] <mru> some soviet outfit used to hold the guiness record for longest organisational name [14:13:49] <kshishkov> could be, Russia is improving German model since XIXth century at least [14:14:24] <kshishkov> sometimes mere abbreviation takes about ten letters [14:15:30] <kshishkov> for example, my internal passport issues by "Nth RVKhMUUMVS of Ukraine in Kharkiv region" [14:16:04] <kshishkov> (and I had to write it by hand for so many times :( [14:16:55] <av500> mru: that does not translate cleanly to german [14:18:21] <kshishkov> av500: japanischepublikautobahntokioersteoperationenbueronagÃ¥ntingmaintenanz? [14:19:24] <av500> no [14:19:31] <av500> japanische would be a separate word [14:19:48] <mru> damn [14:19:49] <twnqx> and Ã¥ isn't even a german letter :P [14:20:03] <av500> public as well [14:20:07] <kshishkov> well, it's a typo anyway [14:20:13] <av500> i assumed that much [14:20:48] <kshishkov> it should be "nÃ¥gonting" [14:21:04] <mru> that's etwas [14:21:14] <mru> or irgendwas [14:21:16] <mru> depends [14:21:26] * kshishkov does not know German but thinks of Swedish as more acceptable substitute [14:23:25] <pJok> kshishkov, eller nånting om man är lat ;) [14:23:42] <mru> eller nÃ¥t om man e latare [14:23:49] <pJok> japp [14:24:21] * kshishkov is not that lazy [14:24:22] <mru> danish has gone quite far in reducing all words to single-syllable gurgles [14:24:39] <pJok> of course [14:24:42] <andoma> Ãž [14:24:47] <pJok> just take my name [14:24:47] <kshishkov> 0 [14:24:53] <pJok> noone pronounces it fully [14:24:59] <pJok> noone says Jørgen [14:25:01] <mru> andoma: hey, didn't know you speak danish [14:25:04] <pJok> its Jørn mostly [14:25:21] <kshishkov> same here [14:25:29] <andoma> mru: :) [14:25:29] <mru> kshishkov: no, that's different [14:25:43] <mru> russians etc all have two quite distinct names [14:25:49] <mru> one official, one that people call them [14:26:05] <mru> and some have one that people refer to them as in third person [14:26:12] <mru> or something like that [14:26:15] * kshishkov has Ukrainian name as well [14:27:09] <kshishkov> given name, some form of it for close friends, patronymic name (used for calling middle-aged men too) and last name [14:27:33] <pJok> kosi? [14:27:35] <pJok> ;) [14:27:43] <kshishkov> kostya [14:28:06] <kshishkov> as a bonus it's short version of both Russian and Ukrainian name [14:28:16] <mru> that's a fairly standard contraction of konstantin [14:28:43] <mru> but in a formal setting you'd probably be called by the full name [14:28:49] <mru> not so in danish [14:32:26] <j-b> ramiro: /tmp/ccUKMx1c.s:13310: Error: operand type mismatch for `cmp' when compiling swscale? [14:33:16] <av500> kshishkov: I call you whatever tab completion calls you :) [14:36:56] <pJok> av500, like Kovensky ? [14:36:57] <pJok> ;) [14:37:49] <j-b> ramiro: cmp on Win64 isn't correct? [14:38:00] <av500> for reasons (unknown to me), this tab places kshishkov before Kovensky [14:39:07] <thresh> because irssi has adaptive completion [14:39:12] <pJok> it just wants to mess with you [14:39:15] <thresh> like, who's been last active. [14:40:01] <av500> I think that it rates "k" < "K" [14:40:12] <pJok> it doesn't [15:24:54] <BBB> mru: pong [15:26:17] <mru> BBB: did we have one gsoc slot too many? [15:26:44] <BBB> nope [15:27:06] <mru> didn't or don't? [15:27:13] <BBB> we did, but we don't [15:27:20] <BBB> but we still probably have 2-3 that we won't use [15:27:30] <BBB> I don't see all of these students qualifying in the next 7 days [15:27:36] <BBB> but that might just be me being negative or so [15:27:42] <BBB> what would you like to do with 'em? [15:28:01] <mru> I'm asking because an xbmc guy applied to the beagle soc and it looks like he might not get it [15:28:05] <mru> beagle only got 4 slots [15:28:29] <merbzt> BBB: we can give slots to orgs we like to give to [15:28:45] <BBB> so would you like me to ask carol to assign it to them? [15:28:45] <merbzt> or at least suggest [15:28:49] <kshishkov> yay, bribes! [15:28:56] <mru> xbmc is good for ffmpeg, so I though if we have extra slots, we could give one to him [15:29:08] <BBB> ok, I'll ask carol to give it to them [15:29:28] <mru> wait until we've hammered out the beagle situation properly [15:29:32] <BBB> ok [15:29:36] <kshishkov> mru: really? What except APE decoder and RTMP stuff we got from them? [15:29:48] <mru> they use ffmpeg, got to be good [15:29:51] <BBB> keep me updated and I'll do as you say [15:29:57] <merbzt> that's rockbox [15:29:59] <BBB> gstreamer uses ffmpeg, does that make them good? [15:30:03] <mru> no [15:30:05] * BBB hides [15:30:12] <kshishkov> mru: a lot of projects do, some of them are in hall of shame [15:30:18] <mru> oh, come on [15:30:24] <mru> you know the xbmc people [15:30:27] <mru> they're good [15:30:30] <BBB> we're kidding dude [15:30:32] <BBB> I know they're good [15:30:36] <BBB> I communicated with a few of them [15:30:37] <BBB> they're nice [15:31:09] <andoma> I drank beer with one of them. Can't remember anything... [15:31:20] <mru> we met a few at linuxtag [15:31:25] <kshishkov> so what, bilboed-pi is not that bad as gstreamer either [15:31:41] <mru> that's on a more personal level [15:31:50] <mru> gst as a project despises us [15:31:55] <mru> and we them [15:31:58] <bilboed-pi> eh what ? [15:32:00] <bilboed-pi> no [15:32:27] <ohsix> sounds like projection [15:32:29] <bilboed-pi> any open-source multimedia project that needs codecs... would be utterly stupid to despire ffmpeg [15:32:32] <bilboed-pi> *despise [15:32:34] <mru> gst is always there, picking crumbs from the corporate table [15:32:49] <mru> then they ignore they are totally dependent on ffmpeg [15:32:58] <mru> and put the ffmpeg support in gst-plugins-ugly [15:32:59] <bilboed-pi> mru, right, because you're living off charity maybe ? [15:33:03] <mru> or was it dirty? [15:33:12] <Dark_Shikari> mru: er, it's in ugly because they are lazy and don't want to decouple the gpl parts [15:33:19] <ohsix> ffmpeg elements are in all sorts of the split packages [15:33:21] * bilboed-pi laughs :) [15:33:25] <Dark_Shikari> Now, what _is_ obnoxious about gstreamer [15:33:29] <Dark_Shikari> though probably less so gstreamer's fault [15:33:34] <bilboed-pi> it's actually in a standalone module : gst-ffmpeg [15:33:36] <mru> of course taking money from companies is fine [15:33:36] <Dark_Shikari> is promotion of proprietary codecs [15:33:49] <Dark_Shikari> gstreamer is a very popular platform for promoting proprietary garbage [15:33:50] <mru> it's the way they do it I don't like [15:33:53] <bilboed-pi> Dark_Shikari, show me where we promote proprietary codecs on gstreamer website [15:33:56] <ohsix> allowing them is promoting them? [15:33:56] <mru> look at the fluendo stuff [15:33:59] <Dark_Shikari> particularly promoting propietary garbage _as a replacement for ffmpeg_ [15:34:02] <Dark_Shikari> fluendo in particular [15:34:10] <Dark_Shikari> I didn't say gstreamer devs in particular were the primary ones at fault [15:34:11] <bilboed-pi> fluendo hasn't been a gstreamer contributor in ... 4 years ? [15:34:26] <ohsix> its been a long time :] [15:34:28] <mru> what can I say, a bad reputation sticks [15:34:29] <bilboed-pi> despite them still stating they hire "core contributors" [15:34:30] <Dark_Shikari> bilboed-pi: and yet people still promote fluendo gstreamer elements as a replacement for open source ones [15:34:43] <bilboed-pi> Dark_Shikari, I know, and I want to slap them really hard every time they do that [15:34:56] <Dark_Shikari> This is like the people who say to use mplayer binary codecs instead of libavcodec. [15:35:55] <Dark_Shikari> But yes, mru bitches too much about gstreamer [15:36:02] <Dark_Shikari> gstreamer is hardly evil, just incompetent. [15:36:03] * Dark_Shikari runs [15:36:13] * bilboed-pi brings out the railgun [15:36:18] <bilboed-pi> run little jason, run [15:36:26] <mru> Dark_Shikari: there's little difference in practice [15:36:32] <Dark_Shikari> mru: evil is more effective [15:36:46] <kshishkov> mru: evil is a cure for incompetence ;) [15:37:00] <ohsix> don't ascribe malice to wit can be explained adequately by stupidity [15:37:02] <BBB> bilboed-pi: even I agree with them though, you guys do an absolutely horrible job at giving credit where due [15:37:12] <bilboed-pi> BBB, where ? what ? [15:37:16] <BBB> bilboed-pi: ffmpeg gets very little credit and a LOT of criticisim from your little corner [15:37:26] <BBB> just talk with christian for 10 minutes [15:37:34] <BBB> he's sitting there right next to you [15:37:48] <bilboed-pi> BBB, hmm... no, he works in Cambridge, I work in Barcelona [15:37:59] <merbzt> http://www.youtube.com/watch?v=1T5gQHa2pq4&feature=player_embedded [15:37:59] <ohsix> running out of unused frames and aborting is kind of a drag [15:38:16] <BBB> bilboed-pi: you're ignoring the bigger issue [15:38:22] <BBB> bilboed-pi: christian is a pain in giving us proper credit [15:38:39] <BBB> it'd be great if you could at least acknowledge that [15:39:00] <BBB> I know other gst devs are quite happy with what we do, but they are unfortunately not as outspoken or well-spoken or bloggy or whatever you want to call it [15:39:16] <BBB> your vocal minority is a problem [15:39:22] <mru> as always [15:39:30] <ohsix> people can see that its being used; what kind of credit do you mean? like giving information that a nontechnical user wouldn't know what to do with anyways? [15:39:32] <Dark_Shikari> BBB: the technical term we use in the US is [15:39:34] <Dark_Shikari> "overzealous staffer" [15:39:40] <bilboed-pi> BBB, define "your" in "your vocal minority" [15:39:43] <Dark_Shikari> whenever something bad happens, it's the fault of an "overzealous staffer" [15:39:46] <Dark_Shikari> or "overzealous intern" [15:39:54] <Dark_Shikari> it's never the fault of an organization or a higherup [15:39:58] <mru> BBB: it's a bigger issue than that [15:40:26] <mru> the way gst is running around the hw companies, they drop an ugly gst plugin and call it "supporting open source" [15:40:54] <mru> if they didn't have that option, they might, just might, be more likely to provide something we could actually work with [15:41:20] <mru> best case, open specs [15:41:20] * bilboed-pi wished mru knew what he was talking about :) [15:41:42] <mru> not quite as good, a close-to-hardware library not tied to gst [15:42:02] <Dark_Shikari> mru: platform lockin is fine when we do it! [15:42:06] <mru> for the record, I always know what I'm talking about [15:42:34] <BBB> ohsix: I think we care a lot more about the acknowledgement clause of the lgpl than you think [15:42:37] <mru> Dark_Shikari: please note that I didn't suggest they contribute lavc support [15:42:46] <BBB> ohsix: just see how painful we are to license violators [15:42:50] <Dark_Shikari> mru: I was referring to gstreamer [15:43:35] <mru> so I see gst as being actually harmful to open source [15:43:43] <mru> quite aside from being arrogant bastards [15:44:03] <ohsix> i'm harming open source right now [15:45:12] <kshishkov> ohsix, wanna be harmed in return? [15:45:27] <BBB> bilboed-pi: anyway, one thing you could bring up in your corporate office next tie you visit cambridge is that we'd be more than happy to accept donations from your company that assist our always-ongoing RE efforts... also, kshishkov is looking for a job in a developed country [15:45:28] <mru> I don't mind people doing closed source [15:45:33] * KotH passes some bottles of beer around [15:45:37] <KotH> boy, please relax! [15:45:40] <mru> but doing it under the guise of being open bugs me [15:45:41] <ohsix> is that a threat? heh, whats the point of that [15:45:56] <kshishkov> KotH: we are relaxed and lazy trolling :P [15:46:17] <mru> and trying to hack u-boot in another window [15:46:18] <kshishkov> BBB: but both UK and Spain don't qualify as developed countries [15:46:36] <BBB> :-p [15:46:36] <bilboed-pi> kshishkov, you should try USA, I here they're trying to get civilized [15:46:48] <kshishkov> ohsix: no, just a hint on moral code and such stuff [15:47:02] <ohsix> a threat is a lesson on morality eh [15:47:05] <KotH> kshishkov: yeah.. and hitting the poor boy lying on the ground [15:47:09] <BBB> living in "USA" is like living in "Europe", it means nothing [15:47:12] <jai> bilboed-pi: lol [15:47:14] <KotH> anyways.. gtg... have a nice evening [15:47:14] <BBB> it depends on *where* you live [15:47:50] <kshishkov> ohsix: no, it was just a phrase intended to remind you of "don't do unto others what you don't want to be done on you" [15:48:49] <kshishkov> BBB: that's why I determined part of Europe where I want to live [15:48:53] <ohsix> its a difference of opinion, not bore out by anything empyrical; you cant reason about it, so what can you definitively say is being done in reality? [15:49:23] <BBB> enough flaming I guess... [15:49:40] * BBB goes work [15:49:47] <kshishkov> boooring [15:50:13] <ohsix> minutae often is [15:51:35] <superdump> mru: i'm not really sure why you're attacking gstreamer [15:51:47] <superdump> i have more loyalty to ffmpeg than gstreamer [15:51:48] <mru> because they deserve it [15:51:53] <superdump> i don't really know gstreamer too well [15:51:58] <mru> they're annoying as hell [15:52:01] <superdump> but i don't understand what you're talking about [15:52:19] <mru> just take my word for it then [15:52:24] <bilboed-pi> lol [15:52:34] <superdump> but you haven't given any evidence [15:52:47] <superdump> you've just said gstreamer is bad, evil, annoying, arrogant, blah blah [15:52:58] <av500> and it uses glib on top of that [15:52:59] <mru> you're obviously not listening [15:53:06] <superdump> i just read the entire backlog [15:53:13] <mru> and you seem to be in the defend-the-bad-guy-against-mru mood today [15:53:29] <superdump> not really [15:53:30] <mru> I hate it when you do that [15:53:37] <Dark_Shikari> mru: I think it's moreso that annoying people tend to be associated with gstreamer [15:53:45] <merbzt> poor mru [15:53:46] <Dark_Shikari> rather than outright gstreamer's fault. [15:53:54] <mru> is there a difference? [15:53:56] * merbzt sends a hug to england [15:53:57] <Dark_Shikari> most definitely [15:53:59] <Dark_Shikari> =p [15:54:00] <superdump> i defend ffmpeg when people in gst say 'don't use the ffmpeg plugin, it's bad' [15:54:14] <Dark_Shikari> superdump: mru is arguing that said people are why gst is bad [15:54:19] <av500> err, what do you use instead? [15:54:25] <av500> superdump: ^^^ [15:54:33] <mru> gst ships a badly written ffmpeg plugin, it fails, they and the users blame ffmpeg [15:54:33] <Dark_Shikari> av500: proprietary codecs [15:54:36] <mru> ffmpeg gets a bad name [15:54:49] <superdump> so then we should help make the gst plugin better if we can [15:54:55] <ohsix> ^^ [15:54:59] <superdump> and they should contact us about things that aren't good [15:54:59] <mru> they're not interested in that [15:55:01] <Dark_Shikari> mru: then patch ffmpeg to runtime-fail [15:55:02] <ohsix> right now its an ugly situation [15:55:03] <Dark_Shikari> like we did with x264 [15:55:07] <Dark_Shikari> and ffmpeg [15:55:15] <Dark_Shikari> Then they'll be forced to fix it eventually [15:55:20] <bilboed-pi> mru, correction : distribution don't pick the revision of ffmpeg we recommend for gst-ffmpeg, and then the blame goes to gstreamer or ffmpeg [15:55:25] <superdump> unless distributions just patch that out again [15:55:27] <Dark_Shikari> actually that's a rather good point [15:55:29] <Dark_Shikari> handbrake has the same issue [15:55:34] <ohsix> they're basically checkpointing their own versions since the releases aren't fit for purpose [15:55:37] <Dark_Shikari> a ton of distros try to hijack their build system and replace the versions [15:55:41] <dgt84> I've personally met and spent a few days with a lot of the GStreamer guys and they are a pretty cool group. I have a feeling there are some miscommunication issues here and people get into flamefests too easily... [15:55:41] <Dark_Shikari> and shit breaks [15:55:57] <Dark_Shikari> ohsix: well, moreso that gstreamer wants more releases [15:55:58] <mru> I know what I see [15:56:12] <ohsix> you think therefore you are? [15:56:17] <mru> and I see ffmpeg getting blamed for gst failing [15:56:42] <ohsix> this doesn't have anything to do with those aborts does it [15:56:48] <superdump> to use your mantra - patches welcome [15:56:51] <superdump> :) [15:57:03] <jai> well, more like ffmpeg's mantra :) [15:57:07] <superdump> right [15:57:41] <kshishkov> superdump: speaking of which, how many useful ones we've got from gst? [15:57:47] <superdump> i dunno [15:58:05] <superdump> but both sides saying "you're not being helpful to us, you suck, we're not helping you" isn't progressive [15:58:12] <jai> of course not [15:58:21] <jai> more participation on the ML would be nice [15:58:55] <kshishkov> superdump: and why that doesn't happen with MPlayer/VLC/Xine/XBMC? [15:59:14] <BBB> superdump: I just gave patch suggestions to bilboed-pi [15:59:17] <BBB> superdump: scroll up a bit [15:59:19] <bilboed-pi> to be fair... libavcodec has been pretty much flawless for the past year [15:59:22] <BBB> in fact, I gave 3 [15:59:29] <av500> kshishkov: coz they are "g" less :) [15:59:36] <merbzt> jai: is this album for real http://www.bombay-connection.com/en_GB/site/page/1/releases ? [15:59:51] <av500> merbzt: you asked that like 2 weeks ago [15:59:53] <av500> :) [16:00:06] <merbzt> jai: you being the only indian music player I know [16:00:08] <av500> to the same jai [16:00:17] <merbzt> av500: no that was to nfl [16:00:24] <av500> hm [16:00:25] <av500> ok [16:00:28] <jai> merbzt: yeah :) [16:01:24] <jai> merbzt: though i can recommend better artists [16:02:11] <kshishkov> jai: i.e. any artist? [16:03:07] <jai> merbzt: like http://www.youtube.com/watch?v=x4SFOm9CL5A [16:03:19] <jai> merbzt: much better sampling and post-production [16:03:39] <av500> jai: video is stuck on 1st frame here... [16:03:52] <merbzt> jai: well sure but this is from 19 frickin 82 [16:04:46] <jai> av500: err, maybe flashplugin's fault? [16:05:13] <merbzt> like 10 years before its time [16:05:38] <av500> jai: ah, it is a slideshow :) [16:05:41] <kshishkov> jai: http://www.youtube.com/watch?v=ZA1NoOOoaNw - can you also hear what's said in subtitles or you knowledge of that language prevents that? [16:06:04] <jai> merbzt: yeah, i kinda forgot that part :) [16:07:11] <jai> kshishkov: err, yeah its pretty much what the subs say :) [16:07:16] <jai> that's tamil btw [16:07:31] <kshishkov> ah, that must be the reason [16:08:05] <kshishkov> Russian and Swedish examples don't work with me [16:08:11] <kshishkov> this one does [16:09:42] * mru once heard a kurdish(?) song that sounded just like "kill all the russians" [16:09:53] <jai> lol [16:10:00] <mru> didn't even need subs [16:13:24] <kshishkov> too many Gentoo devs here [16:14:01] <av500> kshishkov: you wanted to fflame gentoo now after gst? [16:14:53] <kshishkov> no, just slightly worried about any sudden increase of any other group of devs here [16:15:17] <BBB> too many ffmpeg devs here [16:15:17] <Dark_Shikari> -fomit-all-instructions [16:15:24] <mru> who's a gentoo dev other than lu_zero ? [16:15:42] <mru> -fabandon-all-hope [16:15:50] <elenril> fflameeyes? [16:15:54] <mru> oh, right [16:15:56] <ohsix> Honoome/flameeyes [16:16:21] <Honoome> mru: yeah? [16:16:44] <mru> Honoome: sorry, forgot about you [16:16:47] <nirbheek> Honoome, our increased presence here is making kshishkov uncomfortable :p [16:16:49] <mru> you're kinda new around here [16:16:58] <Honoome> nirbheek: ah there's you as well :) [16:17:08] <mru> nirbheek: well, what _are_ you doing here? [16:17:10] <Honoome> mru: it's mostly that I don't usually am not even around :P [16:17:23] <nirbheek> mru, I'm here because jai told me to join ;p [16:17:34] <mru> now why would he do that... [16:17:50] <elenril> it's a conspiracy to take over ffmpeg [16:18:06] * YuviPanda is here becaus of jai as well [16:18:10] <jai> gst related talk is interesting to nirbheek [16:18:14] <jai> YuviPanda: uh huh [16:18:53] <kshishkov> jai: but we stopped flaming already [16:19:02] <jai> kshishkov: indeed, so its pointless now :) [16:19:10] <nirbheek> kshishkov, jai said that it keeps coming back [16:19:24] <nirbheek> something about 'predicable flamewars' [16:19:40] <mru> did you mean predictable? [16:19:45] <mru> predicable is something else entirely... [16:19:45] <nirbheek> Yes, I did [16:20:19] <mru> this is getting scary [16:20:21] * av500 pretends to download gentoo to blend in [16:20:24] <jai> lol [16:20:43] <Ford_Prefect> av500, you need to -O3 to _really_ blend in [16:21:07] <av500> only -O3?... [16:21:14] <ohsix> Ford_Prefect is gentoo too zomg [16:21:14] <jai> -fzomg-ricers? [16:21:18] * jai hides [16:21:20] <mru> why do people think gentoo is only about -O9? [16:21:26] <nirbheek> -fmake-everything-faster [16:21:27] <Dark_Shikari> mru: NO ITS TOTALLY ABOUT THE USE FLAGS [16:21:40] <mru> it's about control [16:21:46] <ohsix> its build a bunch of packages with deps into a directory [16:21:46] <av500> kshishkov: there is your gentoo fflame :) [16:21:52] <mru> and about the rc system being f*cking ace [16:21:53] <DonDiego> Yuvi: you around? [16:21:56] <Ford_Prefect> it's about keeping your room warm in the winter [16:21:57] <nirbheek> mru, so it's like BDSM? [16:21:58] <DonDiego> YuviPanda: are you Yuvi ? [16:22:07] <YuviPanda> DonDiego: no, I'm not [16:22:08] <kshishkov> av500: thanks but I need neither them nor gentoo [16:22:23] <ohsix> Ford_Prefect: keeping the cat content :] [16:22:27] <Dark_Shikari> >control can I "control" gentoo to stop using 5-page-long config lines for vlc? [16:22:43] <av500> use smaller font? [16:24:50] <kshishkov> Dark_Shikari: yes, do everything manually [16:25:02] <Dark_Shikari> kshishkov: that's probably still easier than portage [16:25:28] <mru> you can always replace the ebuild [16:26:00] <mru> in debian/redhat/suse you can't do a friggin thing [16:26:04] <Dark_Shikari> sure you can [16:26:06] <Dark_Shikari> build it yourself [16:26:08] <Dark_Shikari> same as I do in gentoo [16:26:14] <Ford_Prefect> That's probably there because we don't let the build autodetect anything. (disclaimer: I don't maintain the ffmpeg ebuild and haven't even looked at it) [16:26:19] <ohsix> debian is pretty slick with source packages [16:26:21] <nirbheek> Dark_Shikari, you use gentoo? [16:26:30] <Dark_Shikari> yes [16:26:37] <av500> kshishkov: look what you have started! [16:26:45] <mru> he's like one of those gay homophobes [16:26:47] <ohsix> not as simple as a single text file though (and patches/arch independent files or whatever) [16:27:22] <mru> if I need a simple patch for something, I just drop it in /etc/portage/patches [16:33:20] <av500> mru: btw, aac sbr wants neon love it seems [16:34:21] <mru> oh yes, I know [16:34:31] * mru waits for the highest bidder [16:34:38] <av500> I clock 5.1 at 40% of 500mhz atm [16:35:03] <kshishkov> mru: $5 from me, unless anybody else bids I'm the highest bidder [16:35:24] <av500> $5.50 [16:36:04] <mru> if you add a k to that we're in business [16:36:14] <mru> av500: do you have a good test file? [16:36:31] <kshishkov> you'd better ask peloverde [16:36:43] <av500> al_sbr_cm_48_5.1.mp4 [16:36:53] <av500> mru: ^^ [16:37:00] <av500> from the compliance files [16:37:21] <mru> looks like I'm missing that set [16:38:07] <av500> wow, I get 60% of 500mhz even on a movie tralier [16:39:22] <mru> aren't you using that other aac decoder? [16:39:36] <av500> yes, but it only 2ch atm [16:39:55] <av500> for 2ch, its 6% vs 12% [16:40:09] <mru> sbr? [16:40:12] <av500> yes [16:40:26] <av500> I think for non sbr, lavc is even faster than what I have [16:40:47] <av500> but I have to go now, back at work on monday [16:41:03] <mru> I did optimise it to death [16:41:22] <av500> good [16:41:23] <mru> it spends about 40% of the time in neon asm [16:52:59] <av500> lol: http://spot.livejournal.com/308370.html [16:53:48] <mru> that's not bad [16:54:46] <ohsix> theres a language project called Io that'd hit every one of those demerits [16:56:10] <Ford_Prefect> 40 points for the Linux kernel in the first 2 sections [16:56:21] <Ford_Prefect> Well, 35 [16:57:43] <pengvado> why is "you've written your own source control" more fail than not having any? [16:57:55] <Ford_Prefect> 135 points for the Linux kernel [16:58:00] <Ford_Prefect> I always knew it was made of fail [16:58:36] <kshishkov> pengvado: because relying on any tool you wrote for it gives you 100 points [16:58:42] <elenril> yeah, it's obvivous it'll die soon [16:58:59] <mru> exception if the tool is so good everybody else starts using it too [16:59:03] <kshishkov> not before its year on desktop ;) [16:59:46] * elenril doubts it [16:59:57] <elenril> 2011 is the year of hurd on desktop [17:00:13] <Ford_Prefect> Oooh, ooh, is a 0.1 release planned? :P [17:03:47] <elenril> Your code tries to install into /opt or /usr/local << what's wrong with that? [17:06:39] <kshishkov> well, try to sum points for GCC [17:06:48] <mru> maybe he means it _only_ installs there [17:06:57] <mru> kshishkov: integer overflow [17:07:33] <kshishkov> ok, any other GNU tool [17:17:21] <Kovensky> <+elenril> Your code tries to install into /opt or /usr/local << what's wrong with that? <-- /usr/local is standard location [17:24:26] <elenril> Kovensky: http://tvtropes.org/pmwiki/pmwiki.php/Main/CaptainObvious =p [17:30:57] * Kovensky to the rescue [17:32:46] <Kovensky> * Your source builds using something that isn't GNU Make [ +10 points of FAIL ] <-- what's wrong with building with BSD Make [17:33:19] <kshishkov> again, either GNU sales pitch or scons/cmake [17:34:12] <Kovensky> * Your project does not do releases [ +50 points of FAIL ] <-- lolol [17:34:34] <Kovensky> * Your releases are only in OSX .zip format [ +10 points of FAIL ] <-- OSX has their own zip format? o_O [17:34:36] <kshishkov> yep, now we replaced that with tablegen [17:34:53] <kshishkov> OSX special files in ZIP [17:35:06] <kshishkov> like attributes and other crap [17:35:19] <Kovensky> * Your code is a fork of another project [ +10 points of FAIL ] <-- he clearly hates DVCSes [17:35:30] <kierank> and the zip file has all sorts of mac crap in it or thumbs.db from windows [17:35:46] <Kovensky> if there was +10 points of fail for every person that has a clone of git://git.videolan.org/x264.git ... [17:35:54] <kshishkov> thumbs.db deserves +13 points of FAIL [17:36:07] <kierank> the mac equivalent is worse [17:36:25] <Kovensky> * Your code does not have per-file licensing [ +10 points of FAIL ] [17:36:25] <Kovensky> * Your code contains inherent license incompatibilities [ +20 points of FAIL ] [17:36:28] <Kovensky> * Your code does not have any notice of licensing intent [ +30 points of FAIL ] [17:36:32] <Kovensky> * Your code doesn't include a copy of the license text [ +50 points of FAIL ] [17:36:35] <Kovensky> lol [17:36:37] <Kovensky> I guess all my perl scripts fall in those categories? :S [17:36:57] <Kovensky> well, not on the licensing intent I guess, at least I say it's ISC on Build.PL / README [17:37:14] <Kovensky> * Your code doesn't have a changelog [+10 points of FAIL] <-- `git log` [17:37:36] <kshishkov> not very useful [17:37:38] <kierank> these days I think sourceforge is a fail [17:37:51] <kshishkov> *sourceforget [17:38:08] <Kovensky> now reading the comments [17:38:11] <Kovensky> "MakeMaker for Perl" <-- uh, MakeMaker makes a standard makefile [17:38:39] <Kovensky> - for building static libraries with -fPIC objects. <-- can't this be blamed on binutils on x86_64 being retarded and refusing to link shared libs to non-PIC static libs [17:41:24] * kshishkov prefers PIC on processors where number of register actually allows using it [17:41:37] <Kovensky> "You need a score for "Your code has a licence you made up"." <-- what about the code from the guy that made the WTFPL license, or all the code mrs wrote [17:41:37] <kshishkov> i.e. PPC/MIPS [17:42:27] <kshishkov> GNU projects have +infinity score [17:42:48] <Kovensky> valid point [17:43:29] <kierank> xiph too [17:44:00] <mru> Kovensky: it's _impossible_ to have non-pic code in shared libs on x86-64 [17:45:03] <pengvado> sure, but the impossibility can be blamed on ld.so, not on the hardware. [17:45:16] <mru> it's not that simple [17:45:20] <Kovensky> "# Your build system depends on csh. (+50)" <-- what, I never saw *anything* that uses csh [17:45:26] <Kovensky> <@mru> Kovensky: it's _impossible_ to have non-pic code in shared libs on x86-64 <-- what about -Bsymbolic [17:45:55] <mru> you'd have to require .text+.data+.bss <4G for non-pic shlib to work [17:46:06] <mru> -Bsymbolic is different [17:46:58] <Kovensky> well, it is, but it makes ld not abort :P [17:47:10] <Kovensky> and it makes a working .so that links to a static library somehow [17:47:18] <mru> -Bsymbolic tells the linker to resolve any internal dependencies immediately and not defer it to ld.so [17:47:24] <mru> you'll still have relocations [17:47:36] <Kovensky> never looked into details, but it was the only way I got a shared ffms2 to link with static libav* [17:47:44] <mru> Kovensky: your statement is pointless [17:47:50] <mru> meaningless [17:48:06] <Kovensky> ? [17:48:26] <mru> you can't have a .so that "links to" a .a [17:48:33] <mru> you can link a .a into a .so [17:48:42] <mru> but then it becomes _part of_ the .so [17:48:43] <Kovensky> well, true, the code is stuffed inside the .so [17:49:23] <pasteeater> who is the contact for donations (if any)? [17:49:25] <mru> and any inter-section references will still have to go through the GOT [17:49:57] <mru> with -Bsymbolic you allow the linker to bind intra-section references directly [17:49:58] <kshishkov> pasteeater: BBB should be [17:49:58] <Kovensky> "king_inuyasha" <-- lol @ nick [17:50:12] <mru> so function calls within the .so don't get the plt indirection [17:50:17] <Kovensky> mru: I see [17:50:27] <Kovensky> well, I should read about ELF and ld.so more [17:51:03] <mru> the problem with x86-64 shared libs is that without pic you can end up requiring a 64-bit offset where there's only a 32-bit field [17:51:13] <pasteeater> kshishkov: thanks [17:51:27] <BBB> kshishkov: ? [17:51:29] <Kovensky> but the only difference I noticed, as a non-informed person, between -Wl,-Bsymbolic and no -Wl,-Bsymbolic is that the latter made ld abort with "invalid relocation", the former made the .so :P [17:51:42] <mru> yes, that's quite likely [17:51:50] <kshishkov> BBB: are you donations man? [17:51:50] <mru> -Bsymbolic will remove some relocations [17:51:56] <BBB> oh right [17:51:56] <BBB> yes [17:52:23] <mru> function calls within the same .so can be done as relative call directly to the target [17:52:35] <mru> because the .text section is always loaded as one piece [17:52:53] <pasteeater> BBB: is IRC your preferred method of contact? i was going to reply to a message in ffmpeg-user. [17:53:09] <BBB> whichever is convenient for you [17:53:12] * Kovensky doesn't see why would anyone prefer a ML to IRC [17:53:18] <BBB> Kovensky: log [17:53:22] <BBB> search, also [17:53:26] * mru logs irc [17:53:28] <kshishkov> attachments [17:53:28] <Kovensky> the logs are public now [17:53:44] <BBB> I'm not on that list [17:53:46] <Kovensky> and I have logs from here since late 2008 [17:53:47] <mru> kshishkov: never heard of irc attachments? [17:53:50] <BBB> anyway [17:54:09] <pasteeater> BBB: i'll just tell them to come here and look for you. [17:54:21] <mru> kshishkov: like this @attach:virus.jpg.exe:base64:2l3kdj908834rjlk34j238 [17:54:24] <BBB> pasteeater: ok [17:54:25] <kshishkov> mru: sometimes fftrollbot goes out for a smoke or lunch [17:54:42] <mru> kshishkov: even trolls have some rights [17:54:58] * BBB goes for lunch [17:57:26] <DonDiego> the failmeter is great.. [17:59:03] <kshishkov> you can lower it by returning viewvc or similar [17:59:28] <mru> I've been unable to find a viable replacement [17:59:31] * DonDiego looks at KotH [17:59:32] <mru> they _all_ suck cpu [17:59:53] * DonDiego thought there was cpu to spare, oh well.. [18:00:10] <mru> not when running viewvc [18:00:17] <mru> it KILLED the machine, remember? [18:01:34] <elenril> that git viewer doesn't eat so much cpu? [18:03:26] <mru> not by far [18:03:57] <elenril> then we should switch to git immediately ;) [18:04:16] <_av500_> +1 [18:08:18] <mru> I installed the latest viewvc on my computer [18:08:28] <mru> fetching the log for ffmpeg's configure takes almost 10 seconds [18:08:39] <mru> with hot caches [18:09:35] <mru> on a much faster machine than natsuki [18:10:25] * Kovensky pats ããã [18:10:42] <Kovensky> about "that git viewer", do you mean gitweb elenril [18:11:05] <mru> the only other svn viewers I found were either unmaintained or php [18:11:05] <elenril> i mean this >> http://git.ffmpeg.org/ [18:11:06] <mru> or worse [18:11:07] <Kovensky> I like gitweb, but I miss the syntax hilighting (that github gives) :( [18:11:22] <Honoome> hmm [18:11:25] * Honoome prefers cgit over git [18:11:28] <Honoome> *gitweb [18:11:37] <Kovensky> any cgit example? [18:11:42] <Honoome> unless they finally do cachingâŠ for a while I worked on my own frontend [18:11:44] <Kovensky> elenril: needs to get mplayer too [18:11:46] <Honoome> cgit.lscube.org iirc ;) [18:11:48] <mru> cgit.openembedded.net [18:15:09] <elenril> Kovensky: http://repo.or.cz/w/mplayer.git =p [18:15:57] <Kovensky> elenril: well, I mean for the reimar fork [18:16:13] <elenril> why? people still use it? [18:16:20] * elenril hides [18:16:23] <Kovensky> Honoome: hmm, no syntax hilighting on cgit either :( [18:16:58] <Honoome> I didn't implement it in gitarella eitherâŠ I could have thoughâŠ [18:18:41] * Kovensky still doesn't get why replace ... with the unicode âŠ [18:18:54] <Kovensky> though if you do that to annoy people that don't set up UTF-8 correctly it is a perfectly valid reason :> [18:19:21] <kshishkov> or really poor man who can't afford enough dots [18:19:44] <elenril> Kovensky: for the lulz ofc [18:19:53] <elenril> <insert ED link> [18:20:04] <mru> it's a 3-byte utf8 sequence too, so it doesn't save any bandwidth [18:20:26] <Kovensky> true [18:20:32] <Kovensky> but lol @ saving 1 byte per "..." [18:21:27] <kshishkov> Kovensky: maybe it's a sign "I can use IRC from M$ Word" [18:21:41] <Kovensky> winword does that replacement? o_o [18:21:45] <Kovensky> s/o$/O/ [18:21:57] <elenril> â® hmm, there's a vertical version too [18:22:08] <Kovensky> I think that one's for math [18:22:40] <kshishkov> or Japanese [18:22:43] <Kovensky> lol, âŠ actually saves typing from one POV... compose+.+. instead of ... =p [18:23:08] <Kovensky> kshishkov: I don't think they use that outside informal writing [18:23:11] <twnqx> altgr+. [18:23:14] <twnqx> âŠ [18:23:22] <Kovensky> my compose is altgr =p [18:23:27] <Kovensky> but it requires two . instead of one ._. [18:23:35] <twnqx> mine is right ctrl :P [18:23:39] <twnqx> Ë [18:23:41] <Kovensky> because compose+.+- is Â· [18:23:59] <twnqx> ËÂ·. [18:24:13] <Kovensky> don't know how to make the upper dot [18:24:13] <Kovensky> lol [18:24:53] <twnqx> upper dot for me is compose+.+. [18:24:54] <twnqx> :P [18:25:26] <Kovensky> what do you use for composing [18:25:28] <Kovensky> gtk or xim [18:25:39] <twnqx> huh? [18:25:43] <Kovensky> (or autohotkey with that xcompose -> ahk hack) [18:25:46] <twnqx> i rely solely on X [18:25:59] <Kovensky> gtk has their own hardcoded compose table, they ignore X's [18:26:03] <Kovensky> xim would be X's [18:26:13] <twnqx> this is a gtk app i'm typing in [18:26:21] <twnqx> you're right [18:26:36] <twnqx> in shell compose+.+. gives âŠ :P [18:26:54] <Kovensky> I heard gtk would use xim's if you forced it to use xim as the input method, but I didn't get much success with that :v [18:27:07] <elenril> xim worksforme [18:27:20] <elenril> pretty much anywhere [18:27:30] <Kovensky> switching to xim makes ibus not find xchat :( [18:27:41] <Kovensky> same for urxvt (and that's why I'm not using it instead of konsole) [18:27:48] <Kovensky> stupid konsole and its dumb font restrictions [18:27:56] <Kovensky> I like MS Gothic ok :V [18:28:13] <elenril> => don't use xchat =p [18:28:23] <elenril> ibus works just fine with urxvt [18:28:30] <twnqx> you know way too much about stuff i don't care about \o/ [18:28:30] <Kovensky> howto [18:28:48] <elenril> URxvt.inputMethod: ibus [18:28:56] <elenril> in resources [18:29:11] <Kovensky> hmm, I have "URxvt*inputMethod: xim" [18:29:37] <elenril> s/works just fine/almost fine/ [18:29:53] <elenril> it randomly freezes on client exit if you use urxvtd [18:30:01] <Kovensky> yay, it werks [18:30:05] * elenril should file a bugreport [18:30:35] <Kovensky> URxvt*perl-ext-common: default,readline,matcher,selection-popup [18:30:35] <Kovensky> URxvt*matcher.pattern.1: http:\/\/img\\d+\\.pixiv\\.net\/img\/.*\/(\\d+)(?:_.*?)\\..*? [18:30:38] <Kovensky> URxvt*matcher.launcher.1 /usr/bin/xdg-open http://www.pixiv.net/member_illust.php?mode=medium&illust_id=$1 [18:30:41] <Kovensky> ^ doesn't work though :C [18:31:27] * elenril isn't really into pokemon [18:31:30] <Kovensky> hmm, I forgot to put a \b to terminate the regexp, but that's not the point [19:01:32] <astrange> ah, gcc4.5 came out [19:02:37] <peloverde> too little too late, clang is my compiler now [19:04:23] <Kovensky> peloverde: clang builds ffmpeg correctly now? [19:04:33] <Kovensky> well, llvm [19:04:39] <Kovensky> since the miscompilation was on asm [19:04:47] <Kovensky> also, last time I tested, clang++ didn't build ffms :( [19:05:05] <Kovensky> it generated valid llvm that llvmc didn't like lol [19:05:45] <peloverde> clang++ is a different beast, and it seems to handle our asm these days [19:05:56] <peloverde> plus it gives human readable error messages [19:07:46] <astrange> it's the same backend, still miscompiles x86-32 [19:08:12] <peloverde> (ok clang++ is part of clang but clang is my CC my CXX remains g++) [19:08:59] * elenril wonders wtf is with oom killer randomly killing his processes [19:10:02] <Kovensky> it ran out of mana [19:10:36] <elenril> got over 200MB left [19:25:41] * elenril rage [19:26:20] <mru> if gcc4.5 is out, why doesn't gcc.gnu.org say so? [19:27:09] <mru> and the list of serious regressions is still a mile long [19:28:09] <mru> oh well, I guess I know what my 1GHz cortex-a8 will be doing [19:28:57] <BBB> cross-compiling for cygwin? [19:43:24] <pJok> mru, did you expect them to actually fix faults before releasing a new version? [19:43:30] <mru> no [19:43:34] <mru> just saying [19:44:31] <pJok> gcc's way of fixing a serious regression is to degrade its priority if its not fixed within two weeks anyways [19:44:34] <BastyCDGS> hey greetz to all of thee! [19:44:43] <pJok> regression fault* [19:45:30] <Dark_Shikari> lol [19:45:37] <mru> it's not a joke [19:45:49] <Dark_Shikari> even non-jokes can be funny [19:46:07] <BastyCDGS> seems saste isn't yet here...awaiting him because of discussion of my gsoc proposal [19:48:49] <BastyCDGS> what's that regression? maybe i can be a bit of help [19:49:10] <mru> I just looked at the list on their bugzilla [19:49:13] <mru> it's long [19:49:52] <astrange> most existed since 4.3/4.4 [19:50:04] <BBB> BastyCDGS: his name is "saste", he's usually on irc 10-12 in GMT+1, so he should be on in a little bit [19:50:30] <BBB> oh wait you already knew his nick [19:50:33] <mru> they seemed to lower the quality considerably with 4.3 [19:50:35] <BBB> well nevermind, he'll be on in a bit ;) [19:50:47] <BastyCDGS> yeah he wrote a mail today to me I should be on on IRC [19:52:50] <BastyCDGS> until he is going online maybe it's a good idea to introduce a bit of myself...you surely want to know what I want to do in ffmpeg? ;) [19:53:16] <BastyCDGS> if you haven't read my application yet... [19:53:25] <mru> nah, you'll fail just like the rest :-) [19:54:07] <BastyCDGS> i want to do the resampling stuff... [19:54:59] <BastyCDGS> but he asked me to do a qualification task first [19:55:12] <BastyCDGS> so I took a look and decided to do IFF-ANIM [19:55:28] <BastyCDGS> since I'm coming from the amiga and have huge experience there with m68k asm [19:56:00] <BastyCDGS> reading the description of this task showed me that reverse engineering is required where i'm experienced with [19:56:30] <mru> well, go ahead, show us what you can do [19:56:47] <Dark_Shikari> which task are you doing again? [19:57:10] <BastyCDGS> qualification: IFF-ANIM, main-task: write a multi-channel mixing engine [19:57:24] <BastyCDGS> with resampling capabilities [19:58:19] <BastyCDGS> I already did a mixing engine and a module playback engine on amiga times [19:58:56] <BastyCDGS> it can handle 1-65535 channels, 8-bit vol/pan, 1-32 bit samples (even odd bit depths like 17 bit and 23, 5, etc.) [19:59:18] <BastyCDGS> output is always 32-bit signed right now [19:59:57] <BastyCDGS> source code for amiga is available here: [20:00:01] <BastyCDGS> http://forum.cdgs-crew.com/viewforum.php?f=11 [20:00:18] <BastyCDGS> including a brief description of my sound tracker [20:00:50] <BBB> you know we already have a resampler right? [20:01:01] <BBB> Michael emailed to ffmpeg-soc that he was interested in the mod decoding [20:01:24] <BBB> the resampler is in libavcodec/resample.c and libavcodec/audioconvert.c [20:01:29] <BastyCDGS> yeah but I read also that it needs improvement [20:01:38] <BBB> right, but then you wouldn't rewrite it [20:01:38] <kierank> stupid question but what's the difference between using a 1-channel resampler multiple times and a "multichannel resampler"? [20:01:42] <BBB> you would improve it :) [20:01:49] <mru> the resampler should be mostly ok [20:01:56] <Dark_Shikari> kierank: changing number of samples [20:01:57] <BBB> the converter needs improvement, yeah [20:01:58] <mru> the format conversion needs some love [20:02:01] <Dark_Shikari> mru: it's an awesome resampler! [20:02:07] <Dark_Shikari> it has AUDIOPHILE_KIDDY_MODE ;) [20:02:11] <mru> yeah [20:02:14] <BBB> lol :) [20:02:23] <Dark_Shikari> CONFIG_AUDIOPHILE_KIDDY_MODE [20:02:25] <Dark_Shikari> best #define ever [20:02:25] <BastyCDGS> :D [20:02:35] <BastyCDGS> i agree to that [20:03:37] <BastyCDGS> so i'll add an CONFIG_AUDIOPHILE_ADOLESCENT_MODE :D [20:04:12] <BastyCDGS> I'll also would be glad to see libavcodec able to playback TuComposer modules [20:04:18] <BBB> ok, now, seriously, BastyCDGS, so the resampler is quite fine I think, if you have specifics you'd like to improve we'd love to hear it, but the initial task was optimization of the audio conversion, which is also jai's project... [20:04:31] <BBB> BastyCDGS: so what is your exact plan w.r.t. the audio conversion optimizations? [20:04:37] <BBB> (or that task as a whole) [20:04:56] <BBB> BastyCDGS: and would you be interested in doing the mod decoder for ffmpeg instead? you seem to have the expertise for that [20:05:15] <BastyCDGS> i wanted to do both anyway [20:05:21] <BBB> that's even better :) [20:05:34] <BBB> so, have a look at libavcodec/audioconvert.c, so you get an idea of what it does [20:05:37] <BBB> and why it sucks [20:05:42] <BastyCDGS> so if jai has the resampler stuff it's probably a great idea to let him do that and me concencrating on mod stuff [20:05:51] <BBB> ok [20:06:05] <BBB> so ideally the mod playback would not just be linking an external library into ffmpeg [20:06:12] <BBB> but it would actually be a new, C implementation in ffmpeg [20:06:25] <BastyCDGS> tucomposer's mod engine is already C [20:06:35] <BastyCDGS> back-ported from my original m68k code [20:06:49] <BastyCDGS> because i noticed that m68k assembly isn't portable very much ;) [20:07:21] <BastyCDGS> hey neo [20:07:27] <NeoSchamane> hi basty [20:08:44] <BastyCDGS> btw, tucomposer's mod engine plays all my modules (which is over 1k) perfectly and even deals with undocumented features [20:09:06] <BastyCDGS> it loads and playbacks currently MOD/S3M/XM/IT and futurecomposer modules [20:09:50] <Dark_Shikari> the real fun is dealing with different channel mappings [20:09:52] <BastyCDGS> for those don't know, futurecomposer is a very old amiga module format which mainly was used in demo scene intros [20:11:25] <BastyCDGS> the thing is, while I have C code ready for the playback engine itself and mixing engine, the loaders aren't ported from m68k asm yet [20:11:36] <BastyCDGS> (except the TuComposer Module loader/saver) [20:12:08] <BastyCDGS> but porting this is more trivial although the C code may look at first a bit weird [20:12:57] <BastyCDGS> @dark_shikari what channel mappings do you mean? stereo => 5:1 and that stuff? [20:13:11] <Dark_Shikari> no no [20:13:15] <Dark_Shikari> I mean the five dozen different ways to code 5.1 [20:13:17] <Dark_Shikari> or 7.1 [20:15:10] <BastyCDGS> ahh understand, the mapping to the real speakers and ensuring that output is going there where it should? [20:15:52] <BastyCDGS> or internal sample format of 5.1 and 7.1? [20:16:10] <CIA-81> ffmpeg: andoma * r22881 /trunk/ (3 files in 2 dirs): Add PIX_FMT_Y400A, 8bit gray, 8bit alpha [20:16:47] <CIA-81> ffmpeg: andoma * r22882 /trunk/libavcodec/pngdec.c: pngdec: Add support for PIX_FMT_Y400A [20:17:07] <BastyCDGS> doing a svn checkout right now... [20:20:38] <BBB> BastyCDGS: so we'd love to have that as part of ffmpeg, if you're interested in that as a soc project [20:20:45] <BastyCDGS> so now I'm looking at audioconvert.c [20:20:56] <BastyCDGS> already see some stuff which has potential for optimizations [20:20:56] <BBB> (although that wouldn't be an avfilter, that'd be a decoder in libavcodec/) [20:21:21] <BBB> uh, yeah, that whole file can be optimized millionfold :) that was the soc task ;) [20:21:40] <BastyCDGS> the first I noticed was the forward from zero to anything for loops [20:21:48] <BastyCDGS> such things should be done backward to zero [20:21:52] <mru> BS [20:21:55] <mru> it makes no difference [20:22:02] <BastyCDGS> the reason is that the inner loop gets faster [20:22:12] <mru> why? [20:22:13] <BastyCDGS> because a cmp edx,eax [20:22:15] <BBB> they should be done in asm with sse* ? [20:22:15] <BastyCDGS> jnz loop [20:22:20] <BastyCDGS> can be optimized to: [20:22:22] <BastyCDGS> dec edx [20:22:23] <BastyCDGS> jnz loop [20:22:29] <astrange> compilers know how to reorder loops better than you [20:22:34] <mru> compilers usually do that [20:22:47] <NeoSchamane> ;) [20:23:08] <BBB> BastyCDGS: the idea for optimizations would be to use sse* on systems supporting it, see libswscale/ for an example of what that would look like [20:23:18] <BastyCDGS> normally they should yes, but even gcc 4.4 doesn't do this [20:23:26] <BastyCDGS> i often take a look on asm output [20:23:35] <mru> BBB: do _not_ suggest doing like swscale [20:23:47] <BBB> mru: ok, anything else is fine also, as long as it does sse :) [20:23:54] <BBB> or neon, if you so please [20:24:00] <mru> look at dsputil [20:24:01] <mru> or fft [20:24:38] <BastyCDGS> the backward loop also saves a sparse register [20:24:47] <mru> btw, I know of one cpu where loops are best counted from -x to 0 [20:24:49] <BastyCDGS> which is pretty good on a low-register CPU like x86 [20:25:11] <pJok> mru, the P4? [20:25:17] <BastyCDGS> yes that is pretty the same just that dec is replaced by inc [20:25:28] <mru> pJok: can't say, nda [20:25:29] <BBB> BastyCDGS: it wouldn't make much of a difference, really, one register isn't very much gain, whereas sse could probably make it 5-10-fold faster [20:25:52] <BastyCDGS> yeah of course, but i don't see a problem with mixing both optimisations [20:26:34] <pJok> mru, sounds evil [20:26:49] <BBB> fair enough, just be careful what you choose to optimize, you don't want to spend hours on 0.1% while you could spend less time on 50% optims [20:26:49] <mru> it's a weird thing [20:26:51] <BastyCDGS> btw, I found a nice page on x86 assembly optimisations quite a time ago: [20:26:53] <BastyCDGS> http://mark.masmcode.com/ [20:26:57] <astrange> it's not an optimization unless gcc 3.4/4.2/llvm already don't do it [20:27:06] <mru> pJok: all instructions are 8 bits [20:27:17] <mru> so there had to be some sacrifices [20:27:24] <pJok> sounds even more evil [20:27:26] <mru> it has inc but not dec [20:27:31] <pJok> like AVR/PIC [20:27:32] <BastyCDGS> it also deals with SSE [20:27:36] <mru> inc wrapping to zero sets a flag [20:28:52] <BastyCDGS> as does dec [20:29:11] <pJok> hmm [20:29:28] <pJok> i wonder if anyone will play around with spc [20:30:07] <BastyCDGS> gcc does this optimisation if the loop ends at zero [20:30:43] <BastyCDGS> but it isn't smart enough yet to reverse order the loop direction if start of loop is 0 [20:32:46] <BastyCDGS> @pJok up to now i was playing only with m68k/x86 [20:32:53] <BastyCDGS> but who knows what future will be [20:33:34] <pJok> BastyCDGS, would be fun if ffmpeg actually got support for spc as well [20:34:18] <BastyCDGS> if i would have a spc cpu i would do this [20:34:59] <BastyCDGS> does ffmpeg run at all on spc right now? [20:35:14] <BastyCDGS> i.e. is there a generic C fallback code for non-supported CPUs for all parts? [20:40:07] <BastyCDGS> what I just noticed, what is about SAMPLE_FMT_S24? [20:40:10] <BastyCDGS> seems to be missing [20:40:35] <BastyCDGS> or is that converted to S32 before handling it to the converter? [20:44:38] <BBB> there's CODEC_ID_S24LE/BE [20:44:43] <BBB> which might b what you're looking for [20:45:09] <BastyCDGS> ah ok thx was just wondering since 24 bit samples are quite common [20:45:09] <BBB> there's not really any reason to support 24-bit samples while processing / filtering because you can't represent it as an actual datatype anyway [20:45:21] <BastyCDGS> yes would slow down things [20:47:45] <BBB> yeah, so CODEC_ID_* is what you find in files [20:48:00] <BBB> SAMPLE_FMT_* is what these are represented as in ffmpeg after decoding [20:48:56] <BastyCDGS> but still then, wouldn't it better to have signed samples after decoding all the times [20:49:13] <BastyCDGS> looking at the code seems there is still some unsigned stuff after decoding [20:49:32] <BastyCDGS> e.g. SAMPLE_FMT_U8 [20:49:48] <BBB> I don't think that one is used, really [20:50:13] <BBB> so you can convert to it, but ffmpeg will never explicitely decode to it [20:50:32] <BBB> I'm not really sure why it's there, I agree it's odd [20:50:41] <BastyCDGS> then we shall remove it? [20:50:50] <BastyCDGS> or try to remove and look if that causes harm? [20:51:05] <BBB> it doesn't really hurt to keep it, it's only a few lines of code [20:51:24] <BBB> but you don't want to optimize for it [20:52:35] <BastyCDGS> well the FIXME above the CONV's states unnecessary stuff shall be removed to save some cases [20:52:48] <BastyCDGS> or at least to put them within ifdefs [20:53:33] <BastyCDGS> cases? sorry meant else ifs [20:55:15] <BastyCDGS> suggestion [20:55:35] <BastyCDGS> add sth. like: #define CONFIG_SUPPORT_U8 [20:56:03] <BastyCDGS> and embrace the unsigned stuff around the appreciate ifdef [20:56:12] <BastyCDGS> just an idea [20:57:39] <BastyCDGS> also the FIXME states add rounding and clipping [21:00:08] <BastyCDGS> what about replacing these if-else if stuff with a jump table? [21:01:20] <BastyCDGS> that's also the approach I use in the TuComposer mixing engine [21:01:44] <mru> you're thinking too low-level [21:01:57] <BBB> the founding/clipping is already fixed, my patch did that [21:01:57] <mru> look at fft [21:02:00] <BBB> I didn't apply it yet [21:02:04] <BBB> will do soon [21:02:15] <BBB> actually my patch doesn't fix rounding, just clipping [21:02:16] <BBB> anyway [21:02:22] <BastyCDGS> why? this can be done on regular C also, no need for asm with a jump-table [21:02:24] <BBB> but yeah, look at the fft code to see what we're hoping to get [21:02:34] <BBB> BastyCDGS: because asm can optimize stuff more than a jumptable [21:02:49] <BastyCDGS> ah ok understand [21:03:11] <mru> the conversions should be split into lots of functions [21:03:14] <BBB> asm can do multiple conversions at once, or speed up float<->int conversions, etc. [21:03:20] <mru> one for each supported pair [21:03:38] <mru> the init function should set a function pointer to the correct one [21:03:52] <mru> how it does that is irrelevant for speed [21:04:03] <BastyCDGS> yes this is exactly what I do in TuComposer's mix routine [21:04:08] <BastyCDGS> set a function pointer and just call this [21:04:23] <BBB> right, and so the function pointer would be decided based on cpu flags, etc. [21:04:39] <BBB> so for you and me, it'd call convert_float_to_int16_sse3() [21:04:44] <mru> the init function should also call cpu-specific init functions which can provide optimised work functions if they want [21:04:45] <BastyCDGS> sorry my term jump table was a little bit misleading on this I just noticed [21:04:49] <BBB> instead of crappy_c_function_which_nobody_likes() [21:05:02] <BastyCDGS> :D [21:05:15] <BBB> and mru is awesome so he'd write a neon version [21:05:35] <mru> BastyCDGS: we don't expect you to write all the asm versions [21:05:47] <mru> it important thing is to get the framework in place [21:06:14] <mru> then anyone with a minute to spare can write an asm function [21:06:38] <BastyCDGS> well since I have a hour to spare I can write 60 asm functions then? :D [21:07:02] <BastyCDGS> hehe [21:07:59] <SmkMnstr> if ffmpeg NEON can encode an audio/video stream and decode an audio stream at sametime im gonna be set [21:08:35] <SmkMnstr> ill use the c64+ for my own stuff [21:11:38] <BastyCDGS> I see regarding to fft.c [21:12:04] <BastyCDGS> there's a base fft.c in libavcodec and one in each cpu supported dir [21:12:31] <BastyCDGS> I also seen that the x86/fft.c also sets func ptrs according if 3DNow! etc. is available [21:13:23] <BastyCDGS> so I guess there shall be a similar approach for audioconvert.c [21:13:31] <mru> yes [21:14:42] <BastyCDGS> can I do this as base of a qualification task? [21:14:55] <BastyCDGS> preparing all this stuff and do some asm versions? [21:16:24] <BastyCDGS> as the main gsoc task I would do the mod stuff itself then [21:18:25] <BastyCDGS> btw, just noticed that there's no sub dir for m68k/coldfire [21:18:44] <BastyCDGS> so maybe I could add some m68k optimized asm code? [21:18:54] <BastyCDGS> or isn't m68k a target platform at all? [21:20:36] <astrange> if you write asm for it it'll become a target platform [21:20:54] <mru> m68k is difficult [21:21:15] <mru> gcc rarely compiles ffmpeg for it to begin with [21:21:24] <mru> and hardware capable of running ffmpeg is rare [21:21:59] <mru> the most common m68k hardware is probably old macs and amigas [21:22:13] <mru> we don't support old macos or amigaos [21:22:52] <BastyCDGS> you're right, it's probably not worth the mess anymore... [21:23:03] <peloverde> Doesn't 68k linux still exist? [21:23:17] <BastyCDGS> yes but as far as I know it's tagged as deprecated [21:23:20] <BastyCDGS> even by the kernel [21:23:20] <BBB> BastyCDGS: if you prepare that and write one optimized function, that's enough as qualification for sure... don't forget deadline is 4/21 [21:23:21] <mru> and running linux on those machines is fraught with peril [21:24:25] <BBB> BastyCDGS: make sure you have my patch or you'll be optimizing some old version [21:24:57] <BastyCDGS> then I will do this, or have I to wait for saste agreeing on this? [21:25:15] <BBB> email him to make sure [21:25:20] <BBB> I don't think he'd mentor the mod decoder [21:25:23] <BBB> I'm not sure who would [21:25:25] <BBB> but we'd find someone [21:25:31] <BastyCDGS> btw, what's the best way of submitting patches? [21:25:32] <BastyCDGS> ml? [21:25:34] <BBB> email ffmpeg-soc@ and ask who would like to mentor it [21:25:46] <BBB> ml, yes, ffmpeg-devel@ or (if you prefer) ffmpeg-soc@, where review will be a bit kinder [21:25:56] <BBB> don't be angry if review is harsh, it just is ;) [21:25:56] <BastyCDGS> or shall I straight forward do a svn ci? [21:26:04] <BBB> you don't have permission :-p [21:26:20] <BBB> (try, it'll say "permission denied" or ask for a password) [21:26:37] <BastyCDGS> then I'll try 1234 as in the spaceballs movie as pw :D [21:26:50] * BBB quickly changes his password [21:26:55] <BastyCDGS> lol [21:28:16] <BastyCDGS> so I'll send this log as mail to saste let him read it and decide [21:29:07] <BastyCDGS> is there anything special I should take care off when submitting patches (e.g. special command line params for patch)? [21:29:33] <BBB> patcheck [21:29:35] <BBB> in ... tests/? [21:29:41] <BastyCDGS> ok thx [21:29:45] <BBB> tests for common formatting mistakes in patches [21:31:02] <BBB> but email ffmpeg-soc@ so we can find a mentor for you [21:31:19] <BBB> I can't think of an obvious one fro the top of my head, but shouldn't be a big issue [21:32:14] <BastyCDGS> found that file but it was in tools not in tests [21:32:40] <BBB> oh right, well that one [21:33:43] <BastyCDGS> 7 days until deadline is more than enough, since i have vacation until that date [21:34:34] <BastyCDGS> I think I'll require 1-2 days for getting into it and another 1-2 days for writing and testing [21:35:00] <BastyCDGS> what is the best way with testing the actual routines (ffmpeg cmd line switches or alike that) [21:35:08] <BastyCDGS> to be sure that my functions are actually called? [21:35:14] <BBB> add a printf()? [21:35:16] <BBB> or a break in gdb [21:35:51] <BastyCDGS> yes of course, then I'll see when they are called but I want to know how to get them called initially [21:36:06] <BastyCDGS> can i simply launch a conversion of a WAV lets say from 32 to 16 bit? [21:36:11] <mru> yes [21:36:22] <mru> if not, make that part of the task too [21:36:38] <BastyCDGS> hehe [21:37:56] <BastyCDGS> i haven't any 32 bit wavs out of place but I can easily create one using TuComposer [21:38:28] <mru> or with ffmpeg [21:39:40] <BastyCDGS> ok just to summarize up: [21:40:02] <BastyCDGS> 1. prepare the framework [21:40:10] <BastyCDGS> 2. create 1-3 asm functions [21:40:20] <BastyCDGS> will probably do most common ones, 8, 16 and 32 bit) [21:40:35] <BBB> forget about the 8-bit one [21:40:41] <BBB> just 16<->32 would be awesome [21:40:49] <mru> float to 16-bit is by far the most important [21:40:49] <BBB> and then we'll fight about int16<->floa [21:40:58] <BBB> mru: yes but we were fighting over that one ;) [21:41:08] <mru> I'm not fighting, I'm right [21:41:13] <BBB> yes you are [21:41:23] <mru> then you misunderstood me [21:41:35] <BBB> huh? no, I say "yes you are right" [21:41:49] <BBB> I just hope I'm not the one that has to implement that idea ;) [21:41:52] <mru> I thought you said "yes .. fighting" [21:42:16] <mru> you mean the idea that the old codecs already use? [21:42:22] <BastyCDGS> fighting like the black knight in monty python? :D [21:42:36] <BBB> mru: yes that one, also don't forget the conversion function should clip [21:42:44] <BBB> mru: new codecs don't do that anymore [21:42:57] <mru> and that's where they need to change a little [21:43:04] <mru> they need to accept a scale parameter [21:43:12] <BBB> yes [21:43:22] <BastyCDGS> clipping from float to int16 shouldn't be that hard just clip +/- 1.0 to -32768 and 32767 [21:43:23] <mru> when it's easy to do [21:43:39] <BBB> mru: right... but the caller / converter should clip [21:43:48] <BBB> dsputil.int16_to_float doesn't do that [21:43:56] <mru> yes it does [21:43:57] <BBB> er, the other way around [21:44:01] <BBB> float_to_int16 doesn't [21:44:03] <BBB> oh it does? [21:44:06] <BBB> I didn't know that [21:44:07] <mru> that's the one that does [21:44:15] <BBB> maybe wmadec does i doubly then [21:44:17] <BBB> need to check again [21:44:21] <BastyCDGS> btw, tell me when you have updated audioconvert.c [21:44:25] <BastyCDGS> so I again can checkout [21:44:27] <mru> wmapro outputs float [21:44:33] <mru> which goes through the crappy converter [21:44:37] <mru> which doesn't clip [21:44:55] <BBB> BastyCDGS: see patch in "[PATCH] audio conversion clipping/overflows" thread [21:45:22] <mru> wow, I whacked gcc devs with c99 spec and it stuck [21:47:18] <Dark_Shikari> ? [21:47:26] <mru> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721 [21:48:40] <Dark_Shikari> woot [21:48:47] <mru> fun fact: ppc doesn't trap on div by 0 [21:49:16] <BastyCDGS> i agree to you, expecting a behaviour on div0 violates C std. [21:49:28] <BastyCDGS> AFAIK this is true for all C standards not just C99 [21:51:19] <BastyCDGS> and even for C++ [21:52:24] <Dark_Shikari> nasal demons? [21:54:05] <BastyCDGS> just remembering [21:54:10] <BastyCDGS> this is for integer div0 [21:54:18] <BastyCDGS> fp div0 is well-defined in IEEE [21:54:55] <BBB> there's no % operator in float really [21:54:57] <BastyCDGS> if I'm remembering correctly either result shall be +/- inf or NaN (not exactly sure) [21:55:05] <mru> BBB: only in javascript [21:55:21] <mru> 0/0 = nan [21:56:00] <mru> +/0 = +inf [21:56:04] <mru> -/0 = -inf [21:56:17] <mru> don't remember what 1/-0 is defined as [21:58:02] <BastyCDGS> intuitively I would say -inf [21:58:09] <BastyCDGS> -1/-0 = +inf [21:58:23] <mru> negative zeros are evil anyway [21:58:32] <Dark_Shikari> it makes if( x == 0 ) hard [21:58:38] <Dark_Shikari> or at least annoying [21:58:48] <mru> bitmask [21:58:49] <BastyCDGS> yes I haven't ever heard of somebody really using this [21:58:53] <Dark_Shikari> Yeah, bitmask works [21:58:56] <Dark_Shikari> just more immediate bits [21:59:03] <BastyCDGS> or fabs(x) == 0.0 [21:59:07] <mru> ugh [21:59:10] <BastyCDGS> :D [21:59:21] <mru> shift left one and test for zero [21:59:21] <BastyCDGS> but looks really lame i know [21:59:25] <Dark_Shikari> fabs *is* faster than abs ;) [21:59:36] <Dark_Shikari> clearly we should use one's complement for all data [21:59:39] <mru> if shift also sets flags [22:00:51] <BastyCDGS> luckily I doesn't happen that often that you have to divide some value by george w. bush's IQ :D [22:01:19] <mru> well, suppose you need to calculate wars/iq [22:01:49] <Dark_Shikari> how about pretzels/iq [22:02:01] <mru> wars/pretzel [22:02:46] <BastyCDGS> oh yeah you're right, for dividing by bush's IQ we have to introduce complex numbers [22:02:57] <BastyCDGS> oops dragging sqrt [22:05:59] <BastyCDGS> what about if ( x == 0.0 || x == -0.0 )? [22:06:21] <mru> never compare floats for equality [22:06:51] <SmkMnstr> if (!x<=0 && !x>=0) [22:06:57] <BastyCDGS> depends on use case, i know that you normally should use epsilon comparision [22:07:27] <mru> no, you should write your code so don't need to compare in the first place [22:07:55] <BastyCDGS> luckily I barely use float at all, i prefer fixed-point integers [22:08:02] <SmkMnstr> u have to do screwy stuff like that for nan and infin/-infin [22:08:09] <SmkMnstr> dont quite recall details [22:08:10] <mru> float is often faster than fixed-point [22:08:25] <BastyCDGS> when you need log and sqrt and that stuff yes [22:08:29] <BastyCDGS> if you do only add/muls not [22:08:37] <mru> depends on the hardware [22:08:50] <SmkMnstr> i do relatively few logs, so i can do the rest as muls [22:08:52] <BastyCDGS> is there really hw out there where one fpu cycle is faster than an int? [22:08:52] <BBB> most audio filters and codecs will use sqrt/log/etc [22:09:07] <SmkMnstr> or adds [22:09:16] <mru> a fixed-point mul requires a normalising shift [22:09:50] <BastyCDGS> a 32x32 (64 bit fixed with 32 bit prec) doesn't require a shift [22:09:50] <mru> and float ops use a different execution unit [22:10:02] <BastyCDGS> if its a 32-bit CPU and has a 32x32=64 mul instruction [22:10:02] <mru> so you can do some integer stuff for free in the meantime [22:10:15] <mru> pointers, loop control etc [22:10:16] <BastyCDGS> you then can simply use the reg which stores the upper 32-bits [22:10:30] <mru> if the shift were exactly 32, yes [22:10:46] <mru> but such multiplications are as slow as float [22:12:14] <BastyCDGS> after all it heavily depends on target CPU [22:12:40] <mru> I'm assuming one with decent hardware fpu [22:12:51] <BastyCDGS> then the point goes to you... [22:13:17] <mru> fixed-point is obviously faster if you don't have an fpu [22:13:59] <BBB> most fixed-ints don't use 32-bit shifts exactly anyway, e.g. MS uses 31/30 in their fixed codecs [22:14:13] <BBB> and I'd guess their market share is big enough to be significant [22:14:20] <BBB> poor suckets having bought into windows mobile :) [22:14:29] <BastyCDGS> hehe [22:14:59] <BastyCDGS> now I know why their stuff is such slow :D [22:15:22] <BastyCDGS> wonder they don't use BCD during the whole OS sometimes haha [22:17:17] <BastyCDGS> btw, since I'm still running hardy (8.04) are there some dependencies I've to take care when compiling ffmpeg SVN? [22:18:55] <mru> gnu make 3.81, decent gcc [22:19:42] <BastyCDGS> make is exactly 3.81 [22:19:48] <mru> that's the latest [22:19:58] <BastyCDGS> gcc is 4.2.4 [22:20:03] <mru> should be fine [22:20:35] <BastyCDGS> I'll do a test build now [22:21:37] <peloverde> make sure you have yasm [22:22:20] <peloverde> Also I think hardy's yasm is too old [22:22:33] <BastyCDGS> thank you for mentioning this I hadn't yasm installed [22:23:31] <BastyCDGS> seems you're right [22:23:32] <BastyCDGS> http://ubuntuforums.org/showpost.php?p=6963607&postcount=360 [22:25:22] <peloverde> yasm 1.0 is out? sweet! [22:25:34] <BastyCDGS> just building it right now ;) [22:28:21] <BastyCDGS> works yeah [22:28:40] <BastyCDGS> yasm 1.0.0.2319 [22:29:19] <peloverde> most of the best x86 assembly requires yasm [22:31:53] <BBB> fft is yasm? [22:32:05] <BastyCDGS> yasm was unknown to me, I was using nasm instead [22:34:11] <BastyCDGS> still building ffmpeg... [22:34:23] <BastyCDGS> configure detected compiled yasm should be fine [22:37:24] <astrange> yasm is syntax compatible with nasm but more up to date [22:39:54] <BastyCDGS> just wondering is the yasm stuff done at the end? because console output just says CC xyz.c [22:39:56] <BastyCDGS> upto now [22:40:16] <BastyCDGS> ok question answered [22:40:18] <mru> alphabetical order I think [22:40:28] <mru> x86/* comes near the end [22:41:26] <BastyCDGS> ahh ok [22:41:37] <BastyCDGS> have just seen a yasm line [22:42:22] <BastyCDGS> taadaaa, finished, seems good: [22:42:26] <BastyCDGS> basty@cdgs-basty:~/src/ffmpeg/build$ ./ffmpeg --help [22:42:26] <BastyCDGS> FFmpeg version SVN-r22882, Copyright (c) 2000-2010 the FFmpeg developers [22:42:26] <BastyCDGS> built on Apr 15 2010 00:40:39 with gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu4) [22:42:26] <BastyCDGS> configuration: [22:44:04] <BastyCDGS> so building works now, then I'll apply the clipping patch [22:46:13] <bcoudurier> hi guys [22:46:26] <BastyCDGS> hi [22:49:04] <Dark_Shikari> hi bcoudurier's onjoin script [22:54:28] <BastyCDGS> so have found your patch in march archive [22:54:45] <BastyCDGS> but wondering that there's no patch file, just see the text and the patch as a quoted message [22:54:49] <BastyCDGS> did I miss sth.? [22:56:54] <BastyCDGS> I only see the PGP signature (189 bytes as downloadable attachment) [22:57:59] <BastyCDGS> ahh is it that? [22:58:03] <BastyCDGS> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100315/8513e… [23:00:03] <BastyCDGS> hmm says failed in one file: [23:00:21] <BastyCDGS> basty@cdgs-basty:~/src$ patch -p0 < ffmpeg-svn/patches/attachment.bin [23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavcodec/audioconvert.c [23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavutil/common.h [23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavcodec/amrnbdec.c [23:00:21] <BastyCDGS> patching file ffmpeg-svn/libavcodec/qcelpdata.h [23:00:22] <BastyCDGS> patching file ffmpeg-svn/libavcodec/ra288.c [23:00:22] <BastyCDGS> patching file ffmpeg-svn/libavcodec/sipr.c [23:00:23] <BastyCDGS> patching file ffmpeg-svn/libavcodec/twinvq.c [23:00:23] <BastyCDGS> patching file ffmpeg-svn/libavcodec/wmaprodec.c [23:00:24] <BastyCDGS> Hunk #1 FAILED at 1351. [23:00:24] <BastyCDGS> 1 out of 1 hunk FAILED -- saving rejects to file ffmpeg-svn/libavcodec/wmaprodec.c.rej [23:00:25] <BastyCDGS> patching file ffmpeg-svn/libavcodec/atrac1.c [23:00:25] <BastyCDGS> patching file ffmpeg-svn/libavcodec/qcelpdec.c [23:00:26] <BastyCDGS> patching file ffmpeg-svn/libavcodec/wmavoice.c [23:00:42] <mru> never paste that much into the channel [23:00:48] <BastyCDGS> oh ok sorry [23:01:58] <BastyCDGS> should I care about the failed hunk? [23:02:09] <mru> of course you should [23:02:19] <mru> probably someone edited the file after the patch was made [23:02:27] <mru> you'll have to look and see [23:02:38] <mru> you can probably figure out how to make the change manually [23:04:30] <BastyCDGS> just doing this and it looks that the guy who edited it has changed the for to a while [23:04:42] <BastyCDGS> but your patch (call to clipping func) is included [23:05:32] <BastyCDGS> av_clipf [23:05:53] <BastyCDGS> so I guess it's okay to ignore that failure [23:06:48] <BastyCDGS> will do a rebuild now [23:08:50] <BastyCDGS> if that's successful again then I think I can begin coding [23:08:58] <Dark_Shikari> hmm. why the fuck is prefetch like the only instruction on x86 that doesn't take complex addressing [23:09:04] <Dark_Shikari> Either that or gcc can't use it [23:09:18] <Dark_Shikari> it only seems to be using [REG + CONST] [23:09:53] <BastyCDGS> not sure about this, but maybe the adressing mode is dependant of the target CPU? [23:10:03] <Dark_Shikari> not since 386 [23:10:37] <Dark_Shikari> oh god, mru, you'll lol at this [23:10:41] <Dark_Shikari> actual code generated by gcc [23:10:46] <Dark_Shikari> mov edi,0x80808080 [23:10:46] <Dark_Shikari> mov [ecx+0x4804],eax [23:10:46] <Dark_Shikari> mov eax,0x80808080 [23:10:46] <Dark_Shikari> mov [ecx+0x4af0],edx [23:10:46] <Dark_Shikari> mov edx,0x80808080 [23:10:48] <Dark_Shikari> mov [ecx+0x482c],edi [23:11:08] <Dark_Shikari> (ad infinitum) [23:11:33] <BastyCDGS> lol [23:11:44] <Dark_Shikari> Let's keep storing the same constant value repeatedly in different registers! [23:11:45] <BastyCDGS> i see [23:12:01] <Dark_Shikari> It really seems to like this for some reason [23:12:05] <Dark_Shikari> it won't optimize out repeated constants [23:12:25] <astrange> prefetchtX stores the X in part of the address byte [23:12:37] <BastyCDGS> maybe gcc decided that it's faster to leave the constant in the src param and have one more reg available? [23:12:49] <Dark_Shikari> BastyCDGS: but it wastes tons of registers! [23:12:57] <Dark_Shikari> this is for the purpose of storing the same value to mem repeatedly [23:13:07] <mru> and it wastes tons of instruction space [23:13:10] <Dark_Shikari> That too [23:13:19] <Dark_Shikari> astrange: ah so it only does -128 -> 127 offsets? [23:13:38] <BastyCDGS> gcc version is? [23:13:55] <BastyCDGS> 4.2.4 does some weird stuff for me too...4.4 is much better regarding this [23:14:06] <mru> 4.4 is a very mixed bag [23:14:15] <mru> sometimes it produces 25% slower code [23:14:28] <Dark_Shikari> 3.4 here [23:14:31] <Dark_Shikari> so yeah, partially my fault =p [23:14:48] <BastyCDGS> from where the asm code originates? [23:14:55] <Dark_Shikari> gcc 3.4 [23:14:57] <BastyCDGS> (want to try gcc 4.2.4 on this src) [23:15:03] <Dark_Shikari> oh, local changes to x264 [23:15:07] <Dark_Shikari> to add prefetching to cache handling [23:15:20] <Dark_Shikari> to cut down on those obnoxious L2 -> L1 misses [23:16:14] <Dark_Shikari> oh nice, gcc 4 does something _equally_ dumb, but totally different [23:16:58] <Dark_Shikari> c7 40 04 80 80 80 80 mov dword[eax+0x4],0x80808080 [23:16:58] <Dark_Shikari> 8b 94 24 b0 00 00 00 mov edx,[esp+0xb0] [23:16:58] <Dark_Shikari> c7 82 18 48 00 00 80 80 80 80 mov dword[edx+0x4818],0x80808080 [23:16:58] <Dark_Shikari> c7 40 18 80 80 80 80 mov dword[eax+0x18],0x80808080 [23:17:06] <Dark_Shikari> yes, that's right, that's a 10-byte opcode! [23:17:18] <BastyCDGS> crazy [23:17:27] <Dark_Shikari> Everyone knows that storing a value to memory over and over should be done using immediates! [23:17:36] <Dark_Shikari> 4.3.4 [23:18:02] <BastyCDGS> 10 byte op-codes should be avoided at all [23:18:08] <astrange> the x86 backend tries to duplicate constants because it can't deal with register pressure well [23:18:25] <Dark_Shikari> :/ [23:18:37] <astrange> and it doesn't have the real fix for this (rematerialization pass) [23:18:43] <Dark_Shikari> what's that? [23:19:03] <BastyCDGS> maybe you can manually fix it by sth line: [23:19:14] <BastyCDGS> const uint32_t myval = 0x80808080; [23:19:14] <astrange> http://en.wikipedia.org/wiki/Rematerialization [23:19:17] <BastyCDGS> for (...) { [23:19:19] <BastyCDGS> ... [23:19:22] <astrange> basically that but only when necessary [23:19:27] <Dark_Shikari> BastyCDGS: you'd probably need to do uint32_t myval = ... [23:19:32] <Dark_Shikari> to make it impossible to optimize [23:19:48] <BastyCDGS> i mean move the const out of the loop by hand [23:20:18] <Dark_Shikari> it isn't a loop [23:20:23] <BastyCDGS> oh ok [23:20:24] <Dark_Shikari> and gcc may still optimize it away [23:20:55] <Dark_Shikari> so, I'm getting the feeling that there's at least 5%+ performance to be had in x264 just by killing L1 misses [23:21:26] <pengvado> prefetch takes the same kinds of addresses as anything else, gcc is just being stupid [23:21:28] <BastyCDGS> could you post the C code which causes that crazy code? [23:22:13] <BastyCDGS> btw, ffmpeg just compiled fine with the applied clipping patch [23:22:14] <Dark_Shikari> pengvado: *headdesk* [23:22:26] <Dark_Shikari> BastyCDGS: store any constant repeatedly to multiple memory addresses [23:22:35] <Dark_Shikari> pengvado: so you're saying if I used inline asm, it'd go away? [23:23:11] <BastyCDGS> it surely would, but I would call this a somewhat ugly hack [23:23:36] <Dark_Shikari> inline asm is an ugly hack? [23:23:38] <Dark_Shikari> better not work on ffmpeg then [23:23:48] <astrange> http://i.imgur.com/nmFca.png it's not the same addresses [23:23:50] <BastyCDGS> not in general of coz [23:23:56] <BastyCDGS> but for such a thing [23:24:00] <astrange> http://pastebin.org/151566 and the gcc constant thing [23:24:08] <Dark_Shikari> asm volatile("prefetch %0":"m"(p)); [23:24:12] <astrange> it will unduplicate constants that need movabsq [23:24:15] <Dark_Shikari> how do I make gcc like this? [23:24:19] <Dark_Shikari> it thinks p is an output value [23:24:21] <Dark_Shikari> prefetch has no output [23:24:25] <Dark_Shikari> I've never made an asm block with no output before [23:24:34] <astrange> ::"m"(*p) [23:25:56] <Dark_Shikari> astrange: wait [23:26:01] <Dark_Shikari> what's the difference between prefetch and prefetcht etc [23:26:12] <Dark_Shikari> 2aee: 0f 0d 44 c1 0c prefetch byte[ecx+eax*8+0xc] works [23:26:22] <pengvado> astrange: then gas is broken for not warning when I give complex addresses to prefetch [23:28:36] <astrange> 0f 0d? http://ref.x86asm.net/geek32.html#x0F0D gives that as nop [23:29:00] <pengvado> the difference is that prefetch and prefetchw are 3dnow, while prefetch{t0,t1,t2,nta} are mmx2 [23:29:16] <BastyCDGS> 0d 0f [23:29:21] <BastyCDGS> little endian [23:29:52] <astrange> 0d is orb [23:29:58] <astrange> against ax [23:30:06] <Dark_Shikari> pengvado: ahhhhh [23:30:08] <astrange> ah, 3dnow. this is an intel manual [23:30:12] <Dark_Shikari> so "prefetch" is better address-coding-wise [23:30:47] <Dark_Shikari> But only available on AMD? [23:31:09] <Dark_Shikari> someone explain this. I just ran x264 with "prefetch" being used [23:31:11] <Dark_Shikari> .... on my core i7 [23:31:29] <Dark_Shikari> How does that work? [23:31:32] <Dark_Shikari> No SIGILL. [23:31:46] <Dark_Shikari> and what's with gcc doing stuff like this [23:31:47] <Dark_Shikari> 2b04: 01 f8 add eax,edi [23:31:47] <Dark_Shikari> 2b06: 0f 0d 00 prefetch byte[eax] [23:31:51] <pengvado> as astrange says, the intel manual calls it a nop, and prefetch doesn't actually do anything from a program correctness pov, so it should work. [23:32:18] <Dark_Shikari> But obviously being a nop on intel, it's rather bad. [23:32:35] <Dark_Shikari> So, what's the verdict on prefetcht0 with non-m8 addresses? [23:33:55] <BastyCDGS> searching on the link above for prefetch doesn't find any matches, is prefetch[t?] AMD only [23:34:10] <Dark_Shikari> 3dnow, as we said above [23:34:17] <pengvado> umm, m8 refers to the size of the operand, not the address [23:34:33] <pengvado> i.e. it means char* as opposed to int* [23:34:35] <Dark_Shikari> ah [23:35:13] <Dark_Shikari> Wait, so does http://i.imgur.com/nmFca.png allow full addresses or not? [23:35:39] <BastyCDGS> here's an example of prefetch (10 prefetching data): [23:35:42] <BastyCDGS> http://mark.masmcode.com/ [23:36:17] <BastyCDGS> the site says prefetch is available starting from p3 hmm [23:36:21] <Dark_Shikari> yes, mmx2 [23:39:08] <BastyCDGS> so there are two different prefetches one for 3dnow and one for mmx2 [23:39:15] <Dark_Shikari> More than 2! [23:39:16] <Dark_Shikari> more like 6! [23:39:16] <BastyCDGS> maybe you have to tell gcc to use the mmx2 version [23:39:22] <Dark_Shikari> no, it uses the mmx by default [23:39:42] <BastyCDGS> I'm not sure about this maybe it uses host CPU as default [23:39:59] <BastyCDGS> if you have an 3dnow cpu so it might use 3dnow version? [23:40:14] <Dark_Shikari> no, it uses what you set -march for [23:40:15] <Dark_Shikari> Also [23:40:19] <Dark_Shikari> pengvado: this is interesting [23:40:27] <Dark_Shikari> with gcc 4.3.4, it uses the complex addressing mode... [23:40:29] <Dark_Shikari> ... just incredibly badly [23:40:41] <Dark_Shikari> it'll do "eax+esi" and on the next line do "sub eax, 1" "prefetch eax" [23:40:48] <Dark_Shikari> It does things Right if you use inline asm. [23:41:53] <BastyCDGS> yes but i didn't know what you set -march to or even used it at all sorry [23:41:59] <Dark_Shikari> -march=i686 [23:42:54] <BastyCDGS> this is equal to march=pentiumpro [23:43:11] <mru> +mmx [23:43:28] <mru> or not [23:43:31] <mru> intel is confusing [23:43:49] <BastyCDGS> could you try march=pentium4 and compare that? [23:43:58] <mru> lol [23:44:31] <Kovensky> chrome is built with march=pentium4 [23:44:37] <mru> rotfl [23:45:15] <BastyCDGS> I mean just to be sure if it's not that [23:45:57] <BastyCDGS> pentiumpro is mmx but we need mmx2, right? [23:46:01] <BastyCDGS> that's why I had this idea [23:46:07] <BastyCDGS> pentium4 will ensure even sse [23:46:39] <Dark_Shikari> we use -msse [23:46:46] <pengvado> I think the "use of any ModR/M value other than the specified ones" is referring to the fact that there are only 4 prefetch modes (nta,t0,t1,t2) encoded using 3 bits. thus the other 4 syntactically possible values are undefined. [23:46:55] <Dark_Shikari> pengvado: ahhhh k [23:49:07] <BastyCDGS> or give this a try: [23:49:10] <BastyCDGS> -march=i686 -mtune=pentium3 [23:51:43] <BastyCDGS> was doing some research, according to wikipedia p3 has x86, mmx and sse instruction set [23:51:48] <BastyCDGS> while pentium pro just hast x86 [23:51:58] <mru> sounds about right [23:52:04] <mru> p2 was ppro+mmx iirc [23:52:22] <BastyCDGS> if you use march=i686 it just uses x86 maybe even if you force gcc to sse? [23:52:48] <BastyCDGS> so give at least a march=pentium3 a try [23:53:19] <mru> -msse and friends override -march [23:56:21] <BastyCDGS> maybe it confuses gcc if you use msse with a march which doesn't support it? [23:57:17] <BastyCDGS> http://gcc.gnu.org/ml/gcc-help/2007-09/msg00188.html [23:57:51] <BastyCDGS> gcc mailing lists warns about such things, too.

1 0

IRC log for 2010-04-13
by irc＠mansr.com 14 Apr '10

14 Apr '10

[00:03:33] <Kovensky> <@Vitor1001> Kovensky: My point is that in a first time, it would be better to suppose your filtering framework can ignore these problematic cases... <-- I see [00:04:19] <Kovensky> <@Vitor1001> Am I the only one bothered about the effort duplication between ffmpeg and x264? <-- ffmpeg has too many conflicts with libx264; but I don't wish to take part in that flamewar [00:04:27] <Kovensky> <SmkMnstr> what about about openmax <-- what's openmax anyway [00:04:55] <Vitor1001> Kovensky: Which conflicts? [00:06:15] <Kovensky> IIRC the biggest annoyance is ffmpeg not supporting per-codec defaults, and having obscure / maybe overcomplicated ways to specify common options; but I guess you better ask D_S about those or see ffmpeg-devel logs [00:06:43] <Vitor1001> I don't see how is this related with libavfilter... [00:07:25] <Kovensky> well, the project is just to "support audio encoding in x264", but since there might be resampling / remixing needs, I decided to make it a full audio filtering system ._. [00:08:10] <peloverde> is resampling still super bugged in ffmpeg? [00:09:45] <Kovensky> I wrote a fair bit of code that worked with x264's lavf and ffms demuxers and the flv muxer, but I'm having to scrape it because my design was all wrong :P [00:10:15] <mru> that's motivation to get it right next time :-) [00:10:21] <Kovensky> indeed :) [00:10:42] <Vitor1001> Kovensky: It's normal. Getting the design right is hard. [00:10:44] <Kovensky> the biggest mistake I guess is that I made it work by pushing data, instead of pulling =p [00:10:54] <Vitor1001> hmmm [00:11:03] <Kovensky> the code also had o9k asserts and special cases q_q [00:11:35] <Vitor1001> I'm not sure there is an enormous advantage between pushing/pulling [00:12:29] <Kovensky> well, when you pull, you only do the minimum work required, and it moves most of the complexity to the muxer [00:12:49] * mru has a curious case where adding a 'volatile' makes the code _faster_ [00:13:36] <Kovensky> lolgcc? [00:14:26] <mru> a value needs to be moved from a float reg to an integer reg on cortex-a8 [00:14:28] <mru> that's slow [00:15:07] <mru> making the variable volatile forces gcc to store it in memory and load it with a normal integer load instruction [00:15:15] <mru> and there's a bunch of code between [00:15:23] <mru> so the delay is masked [00:15:48] <mru> without the volatile it does a slow register transfer just before it needs the value [00:19:53] <Vitor1001> <Kovensky> well, when you pull, you only do the minimum work required, and it moves most of the complexity to the muxer [00:20:06] <Vitor1001> Yes, but feeding it with data is tricky [00:49:40] <CIA-81> ffmpeg: mru * r22867 /trunk/libavcodec/arm/Makefile: 10l: fix build on non-NEON ARM [01:20:47] <CIA-81> ffmpeg: vitor * r22868 /trunk/libavformat/vqf.c: Use a suitable timebase in VQF demuxer [01:21:25] <Kovensky> <@Vitor1001> Yes, but feeding it with data is tricky <-- as for pushing, I have run into several queue management problems [01:22:06] <Kovensky> what to do when you can't push a packet to the next filter because a queue is too big? block? that'd force every filter to run on its own thread; fail? what about data that you already consumed? [01:22:55] <Kovensky> also, when using --frames and the audio was from an external source, way more packets were decoded than actually needed [01:22:59] <Vitor1001> This problem remains. For the "delay=1h" filter, for ex. [01:23:08] <astrange> why is the queue a limited size? [01:23:48] <Vitor1001> astrange: If anything needs hundreds of MBs of buffering, its a bug. [01:23:48] <Kovensky> because an unlimited queue could grow too large? [01:25:01] <Kovensky> http://github.com/Kovensky/x264-audio/compare/audio...audio_mess#files_buck… <-- this was my failed attempt at getting it to work on push mode before discarding everything and starting work on pull [01:25:52] <Kovensky> that code compiles and runs, but produces incorrect output, and I couldn't figure out exactly why (dumping raw packets right after the encoder gave correct results on the dump, but it all borked on the muxed file) [01:26:11] <Kovensky> the a/v sync and timestamp ordering code was also pretty hackish >_> [01:26:21] <Vitor1001> I didn't really mean you should use push [01:26:29] <Kovensky> moving that to muxers will make it a lot easier to do proper interleaving [01:26:49] <Vitor1001> I only mean that sometimes the filter framework will want to get more audio data than what has been decoded [01:27:19] <Vitor1001> I'm not sure you can always just keep on demuxing until you get enough audio data [01:27:31] <Vitor1001> what will you do with the video frames in the meantime? [01:28:15] <Kovensky> that'd be a negative af_delay I guess, and yes, I tried thinking about it and it wasn't pretty :S [01:28:35] <Kovensky> it's easy to do on regular files (just open another AVFormatContext and use that for audio), but on pipes... [01:28:52] <Vitor1001> Kovensky: Yes, some buffering will be needed. [01:29:27] <Vitor1001> While "delay=1h" is something completely useless and hard to implement, "delay=1s" is useful (for broken sync files) and should be doable... [01:31:02] <Kovensky> yes [01:32:05] <Kovensky> another thing I had completely forgotten but this delay filter discussion reminded me of: files that do specify the audio delay [01:32:10] <Kovensky> I'd have to copy that delay [01:33:38] <Vitor1001> That's not audio filtering job. [01:33:51] <Vitor1001> This is also true if you are not doing any filtering whatsoever [01:33:56] <Vitor1001> this is demuxer's job. [01:36:15] <Kovensky> I see [05:03:51] * peloverde loves how there is a major special case in the PS spec not covered by the conformance suite [05:04:50] <Dark_Shikari> hey, there are profiles of h264 that aren't fully implemented in the reference decoder [05:05:56] <peloverde> There are sample rates missing from the AAC conformance suite [05:06:51] <peloverde> When I asked their response was: why would you want to use 7350 Hz? My response: I don't know but you put it in the spec and mandated it for this profile [05:07:03] <saintd3v> lol [05:08:22] <Dark_Shikari> I asked about 4:2:0 lossless [05:08:25] <Dark_Shikari> which JM still can't decode [05:09:49] * kshishkov wonders when people start to discuss the greatest piece of news about new open codec [05:10:18] <Dark_Shikari> welcome to 2 months ago [05:10:27] <Dark_Shikari> it was also discussed here only a few hours ago [05:10:47] <kshishkov> fine, checked [05:12:01] <kshishkov> and can 420 lossless H.264 be decoded with lavc? [05:12:32] <Dark_Shikari> yes [05:12:54] <kshishkov> then why not slow down lavc decoder by tenfold and call it the reference one? [05:13:08] <Dark_Shikari> lol [05:16:19] <saintd3v> fork("folding(a)home.exe"); [05:17:24] <kshishkov> IIRC that's used in x264 --placebo mode [05:17:55] <saintd3v> DS hasn't comitted it yet :/ [06:00:41] <Tjoppen> http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/ (via slashdot) [06:00:56] <kshishkov> not a news here [06:01:26] <KotH> hoi zäme [06:01:29] <peloverde> a) we've discussed that twice already today [06:01:38] <peloverde> b) VP8 is still vapor ware at the moment [06:01:45] <Dark_Shikari> c) it's still 2 month old news [06:01:54] <Tjoppen> aw [06:01:55] <peloverde> c) read the ./ comments if you want a laugh [06:02:13] <Dark_Shikari> d) I'll bet $100 it still loses to x264 in SSIM ;) [06:02:16] <Tjoppen> I do. breakfast laughs are the best [06:04:10] <kshishkov> reminds me of "Blizzard disclosed when it's going to announce Diablo 2 release date" news [06:05:03] <kshishkov> s/Diablo/Starcraft/ [06:05:36] <Dark_Shikari> lol [06:05:46] <Dark_Shikari> "blizzard announces the date of its announcement of the date of the starcraft 2 release" [06:05:51] <peloverde> StarCraft 2 isn't vaporware though, I've seen it in the wild [06:05:55] <Dark_Shikari> I have it installed >_> [06:06:02] <peloverde> I can't say the same thing about VP8 [06:06:43] <kshishkov> BTW, what happened with On2 custom codec aptly names "AVC" ? [06:12:44] <superdump> if you're talking about the /. vp8 article... i guess i'm going to join the skeptical club [06:12:50] <superdump> there's no reference at all [06:12:56] <superdump> 'multiple sources' - like who? [06:13:29] <kshishkov> rumours [06:13:32] <superdump> i hear from multiple sources that i'm going to shit out a vp8 codec implementation tomorrow morning [06:13:39] <jai> lol [06:13:40] <Dark_Shikari> mru: ping [06:14:34] <kshishkov> reminds me that we had Rar 3 long before it was released - somebody changed version in Rar 2 and added a virus to it [06:14:56] <superdump> starcraft 2 is real [06:15:08] <Dark_Shikari> speaking of which, anyone want to play a game? [06:15:12] <superdump> Dark_Shikari: i saw that news article about the big scandal [06:15:20] <Dark_Shikari> I need someone who sucks as much as I do [06:15:21] <Dark_Shikari> superdump: which one [06:15:41] <superdump> the e-sports starcraft game fixing [06:15:46] <kshishkov> Dark_Shikari: in you case it will be either StarTouhou 2 or TouhouCraft 2 of which I own none [06:15:49] <Dark_Shikari> wait, what? [06:15:56] <Dark_Shikari> kshishkov: That would be awesome [06:15:59] <Dark_Shikari> starcraft + danmaku! [06:16:11] <Dark_Shikari> And all the units would be replaced with little girls [06:16:27] <superdump> Dark_Shikari: http://games.slashdot.org/story/10/04/13/0359232/StarCraft-Cheating-Scandal… [06:16:35] <kshishkov> good luck finding third species [06:16:37] <peloverde> "If IE doesn't support it [vp8], that might just be the nail in the coffin." [06:16:45] <superdump> hahaha [06:16:51] <peloverde> does slashdot have lead in it's water supply? [06:17:11] <superdump> well, i think getting IE and Safari to support anything other than h.264 now would be hard anyway [06:17:21] <superdump> but that's because IE is lazy [06:17:22] <Dark_Shikari> superdump: oh shit [06:17:22] <Dark_Shikari> wow [06:17:26] <Dark_Shikari> savior? dammmmn [06:17:33] <Dark_Shikari> kshishkov: easy [06:17:34] <superdump> and Safari is tied to h.264 [06:17:35] <Dark_Shikari> Humans == Terran [06:17:42] <Dark_Shikari> Youkai == Protoss [06:17:47] <Dark_Shikari> and third.... er.... [06:17:54] <kshishkov> Zergs [06:17:56] <Dark_Shikari> lol [06:18:00] <Yuvi> fairies? [06:18:04] <superdump> tentacle porn things [06:18:06] <Dark_Shikari> fairies do sorta zerg-swarm [06:18:10] <Dark_Shikari> But they're not exactly a credible threat [06:19:33] <kshishkov> you can grab stratagus engine and hack something with it [06:19:43] <Dark_Shikari> well we already have Touhou Fortress 2 [06:20:37] <Dark_Shikari> http://i228.photobucket.com/albums/ee218/zeldagamer501/ayass5.jpg [06:20:38] <astrange> safari supports theora on my computer [06:20:53] <Dark_Shikari> astrange: perian [06:20:57] <Yuvi> how many people install xiphqt? [06:21:01] <astrange> dunno [06:21:12] <astrange> just need to make the install really user-friendly [06:21:13] <kshishkov> I did [06:30:18] <Dark_Shikari> hmm [06:30:32] <Dark_Shikari> CP128( h->mb.cache.mv[l][i8], h->mb.mv[l][top_4x4] ); [06:30:35] <Dark_Shikari> #define CP128(dst,src) M128(dst) = M128(src) [06:30:37] <Dark_Shikari> #define M128(src) (((x264_uint128_t*)(src))->i) [06:30:42] <Dark_Shikari> typedef union { x264_uint128_t i; uint64_t a[2]; uint32_t b[4]; uint16_t c[8]; uint8_t d[16]; } MAY_ALIAS x264_union128_t; [06:30:45] <Dark_Shikari> typedef struct { uint64_t i[2]; } x264_uint128_t; [06:30:46] <Dark_Shikari> astrange: why is this invalid? [06:30:53] <Dark_Shikari> "incompatible types in assignment" [06:32:07] <astrange> you can't assign arrays to each other [06:32:14] <Dark_Shikari> But I'm not [06:32:18] <Dark_Shikari> I'm assigning structs to each other [06:32:27] <Dark_Shikari> the structs just happen to contain an array. [06:32:36] <astrange> (((x264_uint128_t*)(src))->i) isn't a uint64_t[2]? [06:33:00] <Dark_Shikari> no, it's a x264_uint128_t [06:33:02] <kshishkov> it should cast to union, not int then [06:33:05] <astrange> m128 should be union128 [06:33:06] <astrange> not uint128 [06:33:10] <Dark_Shikari> oh duhhh [06:33:42] <Dark_Shikari> now it fails on M128(x) = 0; cases (there are no cases of assigning constants to M128 other than zero) [06:33:46] <Dark_Shikari> Should it be {0,0}? [06:35:25] <astrange> (__m128i){} or (uint64_t[]){} should work [06:36:26] <Dark_Shikari> so I need to do [06:36:31] <Dark_Shikari> M128(x) = M128_CONST(y) [06:36:44] <Dark_Shikari> where #define M128_CONST(x) (uint64_t[]){x} ? [06:37:05] <astrange> {x,x} [06:37:15] <Dark_Shikari> still won't work [06:37:28] <Dark_Shikari> using (uint64_t[]){0,0} [06:37:30] <astrange> oh [06:37:44] <astrange> i guess that's assigning arrays... [06:38:11] <Dark_Shikari> would it work if we made the struct have two values? [06:38:12] <Dark_Shikari> i.e. a and b [06:38:13] <astrange> (struct {uint64_t i[2]})({{x,x}}) can you do that? (does it generate anything vaguely sane?) [06:38:14] <Dark_Shikari> instead of [2] [06:38:25] <astrange> yeah [06:38:53] <Dark_Shikari> = {0,0} doesn't work for the a,b example [06:40:26] <astrange> it has to be casted [06:40:55] <astrange> you could compile stuff through clang if you can get a build without too much trouble, it'll give somewhat clearer errors [06:41:55] <Dark_Shikari> how do I cast it? [06:41:58] <Dark_Shikari> (uint64_t){0,0}? [06:42:09] <astrange> (struct something with two values) [06:43:01] <Dark_Shikari> your #define M128_ZERO (struct {uint64_t i[2]})({{0,0}}) definitely doesn't work [06:43:18] <Dark_Shikari> even if I add the missing semicolon [06:43:22] <Dark_Shikari> I mean, it just outright parse errors [06:43:56] <CIA-81> ffmpeg: gb * r22869 /trunk/libavcodec/vaapi_h264.c: [06:43:56] <CIA-81> ffmpeg: [VA-API] Fix long-term reference frames addition to the DPB. [06:43:56] <CIA-81> ffmpeg: This fixes MR2_MW_A/MR2_TANDBERG_E on Intel Ironlake and NVIDIA HW. [06:44:27] <astrange> probably because of missing ; [06:44:35] <Dark_Shikari> Got it. [06:44:39] <Dark_Shikari> #define M128_ZERO ((x264_uint128_t){{0,0}}) [06:44:40] <astrange> but that was the same thing as (x264_uint128_t) anyway [06:44:42] <astrange> yeah [06:44:51] <Dark_Shikari> it was the extra () borking it [06:45:04] <astrange> if it's just 0 then {} is the same as {{{{{0,...}...} [06:55:48] <Dark_Shikari> astrange: what's the difference between __m128i and __m128? [06:56:53] <astrange> __m128 is a float vector [06:56:58] <Dark_Shikari> float's fine [06:57:31] <Dark_Shikari> #define M128_CONST(x) ((__m128){{x,x}}) [06:57:33] <Dark_Shikari> that doesn't work [06:57:36] <Dark_Shikari> do I have to do {x,x,x,x} or what? [06:59:19] <astrange> yeah since it's 4x float [07:00:03] <Dark_Shikari> #define M128_CONST(x) ((__m128){{x,x,x,x}}) still doesn't work [07:00:09] <astrange> only one {} [07:00:17] <Dark_Shikari> ah k [07:00:23] <astrange> see _mm_set1_epi32 / _mm_set_epi32 in emmintrin.h [07:00:42] <Dark_Shikari> Holy shit it did the code intelligently [07:00:58] <Dark_Shikari> on gcc 3.4 even [07:01:21] <Dark_Shikari> wait, nevermind that. it reloads the pointers off the stack after every single xmm store. [07:01:22] <astrange> it's not bad when there's no register pressure [07:01:44] <Dark_Shikari> I think that it thinks the store can alias the stack (?!) [07:01:48] <Dark_Shikari> I guess that's the MAY_ALIAS doing its magic... [07:02:11] <Dark_Shikari> nah, dumb without the may_alias too. [07:02:20] <astrange> __m128 is may_alias [07:02:29] <Dark_Shikari> ahhh. [07:03:11] <Dark_Shikari> now time to rewrite all the cache functions then [07:03:30] <Dark_Shikari> woot, taking that into account nicely cut the code by a factor of 3. [07:08:22] <av500> OMG, VP8 OPEN SOURCE!!!11! [07:08:24] * av500 hides [07:08:48] <elenril> x264 is doomed [07:09:02] <kshishkov> well, that slashdot article should also add " FFmpeg devs facepalm" [07:09:35] <av500> m( [07:12:10] <jai> isnt there a site which interviews "FFmpeg devs", maybe they'll cover the news [07:12:34] <kshishkov> I fear there isn't [07:13:15] <jai> hmm, i dont remember the name, they covered the 0.5 release as well [07:13:22] <kierank> phoronix? [07:13:27] <av500> jai: http://weeklyworldnews.com/ ? [07:13:32] <jai> ha, yeah i think it was that [07:13:42] <jai> phoronix [07:13:48] <jai> av500: lol [07:14:09] <saintd3v> moronix? [07:14:36] <kierank> I see what you did there... [07:19:25] <superdump> does anyone here have any documentation of wma profiles/levels? if such things exist [07:19:38] <av500> hmm [07:19:55] <kshishkov> wma profiles? [07:19:58] <kshishkov> unlikely [07:20:08] <av500> superdump: let me check [07:20:16] <superdump> thanks [07:20:19] <kshishkov> but if such thing exists it will be coded in bitstream - like in vc-1 [07:26:43] <CIA-81> ffmpeg: benoit * r22870 /trunk/libavformat/utils.c: [07:26:43] <CIA-81> ffmpeg: Do not probe when the format is known. [07:26:43] <CIA-81> ffmpeg: Patch by Jean-Daniel Dupas devlists shadowlab org [08:11:48] <merbzt> superdump: I have it in my head [08:11:58] <merbzt> what do you want to know ? [08:14:26] <pJok> multiple sources in internet 'news': news sites quoting each other... [08:15:51] <kshishkov> yep, reminds me of several cases when some lie from Wikipedia was reprinted elsewhere, deleted in wiki and then restored with reference to that source [08:15:59] <superdump> pJok: news sites claiming truth from other news sites' speculations as to what might be a good thing? [08:16:06] <superdump> lol [08:16:43] <pJok> superdump, that is how the internet news business works... [08:17:45] <kshishkov> whole internet is tied togetherby copypasting [08:17:57] <av500> and tubes [08:18:10] <av500> and Al Gore [08:18:39] <kshishkov> pr0n for some people [08:19:04] <kierank> its hillarious how murdoch got beaten by copy and paste [08:19:11] <pJok> stories might 'start' or 'originate' on a speculative blog, then being picked up by a less legit news site as 'news' and quoted so many times over and over that more legit sites start picking up on the 'story' and suddenly you have your multiple sources that just started out as a rant on a blog [08:19:21] <peloverde> Is there a list of AAC patents floating around? [08:19:31] <kierank> peloverde: on the via licensing website [08:19:50] <peloverde> I can't find an enumerated list there, just a list of patent owners [08:21:19] <peloverde> I'm particularly interested in mpeg 2 AAC http://www.vialicensing.com/licensing/MPEG2AAC_Licensors.cfm [08:21:45] <kshishkov> what about the list art the end of standard? [08:21:59] <kshishkov> like Appendix I or something [08:22:11] <peloverde> Again just the list of companies [08:22:13] <av500> that might be "informative" only [08:25:31] * kshishkov wonders why he always remembers Michael Palin in certain MPFC sketch after hearing "MPEG LA" [08:26:28] <av500> peloverde: I'm trying to get it [08:26:35] <peloverde> thanks [08:27:10] <andoma> kshishkov: why do you think (Y)luma is not a good name for grey? [08:27:23] <andoma> we seem to use it at other places in pixfmt.h and pixdesc.c [08:27:40] <kshishkov> I don't think "ya" is not a good name for pixfmt [08:28:04] <kshishkov> because in 50% of cases it means "yet another" and is not descriptive enough [08:28:22] <av500> ya bro! [08:28:27] <kshishkov> Y400A is better ;) [08:28:38] <kshishkov> and technically correct too [08:29:00] <andoma> ok, sounds good :) [08:32:07] <kshishkov> andoma: even here it shows better approach to name selection - http://sl.se/templates/Page.aspx?id=1633 [08:34:35] <andoma> :) [08:36:41] <kshishkov> also since it says "Pontus: Namnet Ã€r troligtvis av grekiskt ursprung och betyder âhavâ." and your last name is "Ã-man" you may end with grandchildren called "Vik", "Alv" and "SkÃ€rgÃ¥rden" [08:40:26] <andoma> heh, I've never heard anyone with a lastname of 'skÃ€rgÃ¥rden' though :) [08:41:21] <kshishkov> you have many other last names of marine origin [08:44:04] <andoma> kshishkov: lastnames starting with 'sjÃ¶' is not unheard of [08:44:35] <kshishkov> andoma: ask wbs [08:45:11] <kshishkov> and I suspect that names ending with -strÃ¶m also have something to do with water [08:46:45] <kshishkov> but the easiest thing is to seek for somebody named Persson [08:48:13] <Tjoppen> in roundup, if I suspect something is more serious than previously suspected, should I create a new issue for that and add the previous one as dependent? [08:48:39] <kshishkov> maybe a new comment to that issue is enough [08:49:09] <Tjoppen> https://roundup.ffmpeg.org/issue1695 , but sufficiently high bitrate even causes a segfault [08:50:12] <Tjoppen> ok, fair enough. I should perhaps bump it to "important" though? [08:50:13] <kshishkov> that's probably a different issue [08:50:41] <Tjoppen> yeah, that's what I'm kind of suspecting. it's similar, and I can trigger issue1695 as well [08:51:21] <kshishkov> it should be renamed to "AAC bitrate handling sucks" [08:51:37] <kshishkov> and it's dependent on "AAC encoder totally sucks" [08:53:26] <Dark_Shikari> float *x = (float*)&v4; float f4 = *x; [08:53:33] <Dark_Shikari> Where do I put the may_alias here to shut gcc the fuck up? [08:53:36] <Dark_Shikari> or is there a better way to do it [08:54:12] <kshishkov> why intermediate? [08:54:43] <Dark_Shikari> Doesn't have to be. [08:55:40] <jai> shouldnt that be float *x? [08:56:50] <Dark_Shikari> I guess I need a union here [08:56:55] <scaphilo> does anyone know what the mb_threshold and me_threshold is for? in the MpegEncContext? http://dpaste.com/183185/ [08:57:07] <Dark_Shikari> try reading the code [08:57:51] <Tjoppen> I went with the create-a-new-issue approach: https://roundup.ffmpeg.org/issue1877 [08:59:56] <scaphilo> Dark_shikari i tried if for hours but i dont understand the idea of it do you know? i just know that it has to do something with copying the motion vectors and macroblock types from the decoder to the encoder [09:01:22] <Dark_Shikari> er, no, it doesn't [09:01:26] <Dark_Shikari> at least I highly doubt it [09:01:40] <Dark_Shikari> common/macroblock.c:17: error: unable to find a register to spill in class `SSE_ [09:01:43] <Dark_Shikari> REGS' [09:01:46] <Dark_Shikari> what the fuck? [09:02:02] <kshishkov> hello from gcc reg allocator [09:02:57] <Dark_Shikari> I'm not even allocating registers! [09:02:59] <Dark_Shikari> I'm using one at a time! [09:03:02] <Dark_Shikari> via intrinsics! [09:03:12] <merbzt> poor Dark_Shikari [09:03:16] <kshishkov> and maybe gcc uses all of them for math? [09:03:24] <Dark_Shikari> no, it doesn't [09:03:40] <Dark_Shikari> also, it only started doing that once I fixed aliasing and used unions instead [09:04:13] <merbzt> :) [09:04:21] <kshishkov> gcc -S on the last working version? [09:04:41] <merbzt> "my arm hurt when I do this" " don't do it then" [09:05:09] <peloverde> <kshishkov> it should be renamed to "AAC bitrate handling sucks", it's almost encoder time again [09:05:22] <Dark_Shikari> does that mean you'll make it not suck? [09:05:26] <kshishkov> merbzt: yep, that's our local medical service [09:05:53] <Dark_Shikari> well, it works in gcc 4 [09:05:57] <Dark_Shikari> should we break gcc 3.4 ? :) [09:06:01] <kshishkov> Dark_Shikari: yes, that's his intent [09:06:11] * Dark_Shikari looks [09:06:26] * Dark_Shikari sees that gcc didn't generate vector instructions when using gcc4 [09:06:28] * Dark_Shikari HEADDESKS [09:06:38] <peloverde> That's my goal [09:08:46] <scaphilo> Dark_Shikari: certainly it has to do something with that. The copy_picture_attributes() in mpegvideo_enc.c copies the motion_val and mb_type veriable from the decoder picture to the encoder picture only when the me_threshold is set [09:08:54] <pJok> Dark_Shikari, just start on ffcc ;) [09:09:55] <kshishkov> scaphilo: it may be used in motion estimation to search from reference frame motion vectors with some threshold [09:10:34] <kshishkov> and we may need fflibc as well [09:10:57] <Dark_Shikari> scaphilo: see motion_est.c [09:10:58] * peloverde curses ipd/opd for forcing me to rewrite PS mixing interpolation [09:13:01] <av500> ipod? [09:13:10] <scaphilo> thx for help [09:13:42] <kshishkov> av500: no, probably some obscure variables used for parametric stereo [09:17:08] <kshishkov> as you may know, AAC-HE extensions are fully well-documented and easy to understand and any kid may reimplement decoder from those [09:17:27] * KotH didnt know that kshishkov is a kid [09:18:50] <kshishkov> KotH: how did you infer that conclusion? [09:19:51] <KotH> by extrapolation [09:21:21] <kshishkov> go fix your extrapolator [09:21:48] <kshishkov> I got a passport so I'm not a kid anymore *sigh* [09:23:45] <KotH> ah.. then you can go to .se now! [09:24:17] <kshishkov> I got _wrong_ passport for that [09:27:20] <peloverde> ipd/opd is the phase control for PS mixing [09:29:08] <peloverde> Implementing an AAC decoder is a fun task, I highly recommend it to anyone who has the patience and loves incorrect/misleading documentation [09:29:42] * kshishkov looks at superdump [09:30:06] <superdump> precis [09:38:19] <pJok> who needs documentation? [09:48:38] <Tjoppen> hah, nice. just found a XML schema describing the structure of MXF, including all DMS-1 metadata [09:51:28] <mru> Dark_Shikari: pong [09:55:44] <Dark_Shikari> mru: meh, long past. was just going to ask general questions about using gcc intrinsics for simple stuff like copying [09:55:49] <Dark_Shikari> and I've encountered all their shittiness already [09:56:03] <mru> gcc intrinsics are _always_ shit [09:56:05] <Dark_Shikari> like the gcc register allocator failing [09:56:11] <Dark_Shikari> I haven't seen _that_ one fail before [09:56:16] <Dark_Shikari> Not with intrinsics, that is [09:56:38] <mru> I've seen one single intrinsic spit out a dozen extra loads and stores [09:56:40] <Dark_Shikari> bonus points: it failed on a set of code that used only one register. [09:56:53] <Dark_Shikari> mru: on x86 it actually works if you massage it right [09:56:54] <Dark_Shikari> which is the intend [09:56:57] <Dark_Shikari> *intent [09:57:05] <mru> easier to write it in asm [09:57:07] <Dark_Shikari> No it isn't [09:57:15] <Dark_Shikari> Not for, say, CP128() [09:57:22] <Dark_Shikari> or M128() [09:57:25] <Dark_Shikari> and other type-pun macros [09:57:27] <mru> that's what, two instructions? [09:57:33] <Dark_Shikari> M128() = 0 [09:57:39] <mru> pxor, stor [09:57:40] <mru> e [09:57:40] <Dark_Shikari> Do you do a new xor for every store? [09:57:58] <Dark_Shikari> what if you have four M128() = 0s? [09:58:08] <mru> do you think gcc is clever enough to keep a zero around? [09:58:11] <Dark_Shikari> It does. [09:58:25] <Dark_Shikari> I'm on gcc 3.4 and it did everything properly. [09:58:44] <Dark_Shikari> the single complaint I have is that SPLAT 32 -> 128 did 2x unpacklps [09:58:47] <Dark_Shikari> instead of shufps [09:58:55] <Dark_Shikari> Oh, and of course the register allocator failure. [09:59:33] <Dark_Shikari> oh, the other thing I found, which you may want to consider in your code (not related specifically to intrinsics) [09:59:50] <Dark_Shikari> suppose you have some codec context h, and some dynamically allocated data x in h. [10:00:04] <Dark_Shikari> Suppose you also have some aliasing-avoidance macro like x264 and ffmpeg has. [10:00:18] <Dark_Shikari> And you do CP32( h->x[some expression], blah ) for various "expression" values. [10:00:25] <Dark_Shikari> gcc will recalculate the address in full every single time. [10:00:30] <Dark_Shikari> because "x" could have been overwritten. [10:00:41] <Dark_Shikari> It will do the same for CP32( blah, h->x[some expression] ) too. [10:00:46] <mru> so use a local variable [10:00:48] <Dark_Shikari> I did [10:00:56] <Dark_Shikari> It's just something I found a lot of code doing [10:01:00] <Dark_Shikari> and is a huge optimization potential [10:01:00] <mru> gcc hates complicated expressions [10:01:07] <mru> especially repeating ones [10:01:11] <Dark_Shikari> lol [10:01:19] <Dark_Shikari> it isn't the expressions though [10:01:23] <Dark_Shikari> it's the pointer "x" [10:01:24] <mru> not in this case [10:01:29] <mru> but in general [10:01:57] <mru> we had one case on the list where splitting an expression using a few temps _halved_ the amount of code generated [10:02:38] <hyc> makes me wonder how gcc 2.0 would treat some of this code [10:02:50] <mru> otoh, sometimes using a temp makes things slower too [10:02:58] <mru> I had one of those cases yesterday [10:02:59] <hyc> we did a lot of work on CSE way back when [10:03:19] <Dark_Shikari> "temps making things slower or faster" are rarely gcc sucking [10:03:27] <mru> how not? [10:03:30] <Dark_Shikari> but rather you can use temps to convince gcc to do something different [10:03:33] <Dark_Shikari> something which may be worse or better [10:03:51] <mru> gcc should abstract the temps away and do the right thing in both cases [10:03:58] <hyc> indeed [10:04:00] <Dark_Shikari> sure, in a perfect world [10:04:04] <mru> but it doesn't [10:04:07] <mru> so gcc sucks [10:04:08] <Dark_Shikari> humans are always smarter than compilers [10:04:10] <hyc> it used to [10:04:15] <Dark_Shikari> temps allow humans to give the compiler hints [10:04:22] <mru> I'm just glad it doesn't abstract them away and do the _wrong_ thing in all cases [10:05:04] <Kovensky> I've heard that whenever there's a good and a bad way to do some optimization, gcc almost always prefers the bad =p [10:06:17] <hyc> there may be truth in that. gcc -Os often runs faster. [10:06:33] <Dark_Shikari> only on extremely large applications [10:06:34] <hyc> loop-unrolling vs I$ tradeoffs... [10:06:47] <Dark_Shikari> Or in cases where loop unrolling/inlining is outright broken [10:06:54] <mru> gcc is a bit too eager to unroll and inline [10:07:02] <Dark_Shikari> depends on the arch [10:08:46] <Kovensky> -vomit-frame-pointer \o/ [10:09:18] <mru> loop unrolling is good for two things: 1) reducing branching overhead, and 2) improving instruction scheduling [10:09:28] <Dark_Shikari> 2) is useless on x86 [10:09:36] <mru> and gcc can't do it anyway [10:10:09] <mru> on a modern cpu, branches take one cycle [10:10:17] <Dark_Shikari> one? often zero [10:10:21] <mru> or that [10:10:29] <hyc> x86 is impossible, unless you target a single chip family [10:10:34] <mru> in a long-running loop they'll be perfectly predicted [10:10:37] <hyc> model/revision.. [10:10:38] <Dark_Shikari> hyc: not really [10:10:46] <Dark_Shikari> instruction scheduling is done by the cpu on OOE chips [10:10:57] <Dark_Shikari> explicit instruction scheduling actually hurts performance [10:11:06] <mru> cortex-a8 takes 2 mispreds before it adjusts [10:11:23] <mru> Dark_Shikari: only to an extent [10:11:29] <Dark_Shikari> mru: in my testing it does on x86 [10:11:41] <mru> then your testing was within that extent [10:11:47] <Dark_Shikari> obviously it's a limited extent [10:11:48] <DonDiego> Yuvi: you around and awake? [10:11:56] <Dark_Shikari> the point is in general it's a waste of time [10:12:04] <Dark_Shikari> or, better said [10:12:08] <Dark_Shikari> it's useful _if you consider OOE_ [10:12:09] <mru> how long is the reorder queue on i7? [10:12:14] <Dark_Shikari> which usually means very very long-range reordering [10:12:20] <Dark_Shikari> i.e. in order to compensate for the queue limits [10:12:25] <Dark_Shikari> I think it's like 50 instructions. [10:12:42] <hyc> fetch is only 16 or 32 bytes tho [10:12:49] <hyc> it makes a difference... [10:13:04] <mru> if you fill the queue with dependent instructions or instructions all for the same exec unit, you lose [10:13:09] <Dark_Shikari> mru: of course [10:13:13] <mru> you have to keep a good mix [10:13:15] <Dark_Shikari> that's not an ordering issue [10:13:18] <Dark_Shikari> that's an instruction _choice_ issue [10:13:27] <Dark_Shikari> Which is a huuuuge issue on x86. [10:13:28] <mru> it's ordering too [10:13:43] <mru> suppose you need to do a bunch of loads, some calculations, and a bunch of stores of the results [10:13:55] <mru> interleaving the loads and the calculations helps [10:14:00] <Dark_Shikari> not in my experience [10:14:02] <hyc> yes, instruction choice is what makes "optimal" x8 impossible [10:14:04] <Dark_Shikari> I've tried that in dozens of places [10:14:07] <hyc> x86 [10:14:16] <Dark_Shikari> hyc: for GPR ops, instruction choice is pretty easy [10:14:20] <Dark_Shikari> most cpus except p4 are similar [10:14:23] <mru> in that case all your loads and at least some of the processing must have fit in the queue at once [10:14:30] <Dark_Shikari> for SSE ops, they're already so different in throughput it doesn't matter [10:14:54] * av500 imagines gcc vomit a frame pointer [10:15:52] <CIA-81> ffmpeg: mru * r22871 /trunk/libavcodec/dca.c: [10:15:53] <CIA-81> ffmpeg: DCA: optimise dca_subsubframe() [10:15:53] <CIA-81> ffmpeg: 8% faster overall on Cortex-A8. [10:15:53] <CIA-81> ffmpeg: mru * r22872 /trunk/libavcodec/dca.c: DCA: indent [10:16:14] <Dark_Shikari> so, mru, is this another secret contract? [10:17:18] <av500> Dark_Shikari: I guess he got a bluray boxed set of eastenders [10:17:27] <mru> lol [10:17:47] <Dark_Shikari> seriously though [10:17:49] <Dark_Shikari> stop being so mum =p [10:17:54] <av500> Dark_Shikari: yes [10:18:20] <hyc> a blur-ray disc player? or a set-top box [10:18:58] <mru> av500: yes what? [10:19:01] <mru> you want to know too? [10:19:14] <av500> yes, it is secret [10:19:34] <av500> Dark_Shikari: I confirm it is a secret contract :) [10:20:23] <kierank> it's a black contract [10:20:31] <av500> black money! [10:20:43] <av500> and black helicopters [10:20:54] <kierank> don't forget vans [10:22:11] <av500> sunglasses [10:22:41] <hyc> mail [10:30:31] <hyc> gray alpha? I'm surprised they didn't call it gray-Z [10:30:41] <mru> gralpha [10:30:56] <hyc> whatever happened to z-buffers [10:35:11] <hyc> what does it even mean, render-wise. grayscale plus alpha means what? [10:35:20] <hyc> just extra intensity bits [10:35:41] <mru> it means exactly what it seems [10:35:41] <av500> well, just one alpha channel added [10:36:07] <av500> same as RGB vs RGB-A [10:36:09] <mru> same as argb with r=g=b [10:40:50] <hyc> yeah ok [10:41:24] <hyc> gets confusing to think about what opaque means sometimes [10:41:41] <hyc> transparent black. [10:42:26] <mru> that just means you haven't done it enough [10:42:42] <twnqx`> transparent aluminium? [10:42:48] <hyc> probably true. not recently anyway. [10:42:57] <mru> twnqx`: not invented yet [10:43:15] <twnqx`> :( [10:43:23] <mru> and that was a rubbish film too [10:43:29] <hyc> the last time I did serious graphics coding, "True Color" meant 16 bit RGB(A) [10:46:01] <kshishkov> hyc: man, you're old. It's called "HiColor" in my times [10:46:22] <kshishkov> though on WinCE-based PDAs it's "the only color you can get" [10:46:28] <hyc> lol [10:48:14] <hyc> And "blitter" was the hot buzzword of the age [10:48:31] <kshishkov> indeed [10:48:38] <mru> blitters are nice [10:49:00] * kshishkov searches his harddrive for "svga.bgi" and finds none [10:49:01] <hyc> yes, but not talked about much these days. nobody focuses on 2D [10:49:03] <mru> when you know how to use them [10:49:20] <mru> look inside any current set top box [10:49:24] <mru> blitters all the way [10:49:38] <kshishkov> I saw a lot of blitters in Truemotion 1-VP3 code [10:49:43] <hyc> I just get pissed off watching the Linux X11 work [10:49:56] <hyc> everyone working on 3D shaders, whoop-de-doo [10:50:03] <Dark_Shikari> draw_horiz_band is a blitter [10:50:13] <mru> xorg is being driven into the ground, fast [10:50:21] <mru> Dark_Shikari: I'm talking about hardware [10:50:30] <Dark_Shikari> mru: xorg has been driven into the ground for 30 years [10:50:33] <Dark_Shikari> ok, well just X [10:50:35] <hyc> you still can't play full 1920x1080 H264 cleanly, but look, you can play the latest clone of the FPS 3D shooter [10:50:36] <mru> no [10:50:46] <mru> it was fine before the xfree86/xorg schism [10:51:30] <kshishkov> hyc: maybe that's the reason many players keep OpenGL output driver [10:51:40] <DonDiego> why is xorg being driven into the ground? [10:51:40] <mru> great work, throwing out the best developers [10:51:53] <mru> DonDiego: if only I knew... [10:51:57] <DonDiego> it does look healthy ever since they separated from xfree86.. [10:52:06] <mru> about as healthy as a leper [10:52:18] <hyc> gets a lot of attention at least [10:52:18] <mru> xfree86 _worked_ [10:52:32] <mru> now I can't even find a combination of versions that builds [10:52:35] <mru> let alone runs [10:52:42] <mru> well, I have something installed [10:52:54] <mru> from time to time, gentoo wants to update some component or other [10:53:59] <hyc> I'm pretty pissed off that I never got hardware video codec acceleration for my video card between the time when it was the latest and greatest and the time it became unsupported/obsolete [10:54:05] <mru> and more often than not, it fails to build [10:54:18] <mru> so I just freeze the version at something that works [10:54:48] <kshishkov> mru: just get some old shiffy videocard [10:54:49] <hyc> I guess I should be happy about the shift to kernel modesetting [10:54:52] <kshishkov> *shitty [10:55:03] <hyc> that measn other windowing systems can leverage the work now [10:55:16] <hyc> without having to just reimplement the entire X11 userspace [10:55:21] <kshishkov> what systems? [10:55:23] <mru> kshishkov: I use nvidia cards with binary drivers [10:55:36] <hyc> time to dust off the MGR source tree again [10:55:36] <kshishkov> Plan9 windowing system? [10:55:54] <hyc> is the Plan9 code available somewhere? [10:55:58] <kshishkov> mru: yes, that's the constant source of PITA [10:56:04] <hyc> as I recall that was the successor to MGR [10:56:04] <kshishkov> of course [10:56:49] <kshishkov> hyc: http://plan9.bell-labs.com/plan9/ [10:56:57] <hyc> ah, 8-1/2 [10:57:14] <mru> kshishkov: I've had zero problems with the nvidia drivers [10:57:47] <mru> it's always libXthis not liking some version libXThatProto [10:58:00] <mru> and that in turn failing something else [10:58:18] <mru> they split it into far too many pieces [10:58:38] <mru> oh, and the input drivers don't work properly anymore [10:58:54] <mru> I used to be able to hotplug mice and keyboards [10:59:09] <mru> then they broke that [10:59:17] <mru> then they broke the non-standard keys [10:59:22] <mru> then they broke standard keys [10:59:32] <hyc> hah. they "improved" it by making it depend on HAL [10:59:34] <ohsix> that all sounds like gentoo problems :> [10:59:40] <hyc> which they're now killing... [10:59:54] <mru> every time I start X a few keys are misbehaving [11:00:00] <kshishkov> hyc: _now_ that sounds like M$ Windows [11:00:03] <mru> things like left or down arrow not repeating [11:00:11] <mru> or a shift/control key not working [11:00:46] <mru> poking it with xmodmap or xset get them back [11:00:48] <mru> but it's annoying [12:36:40] <kierank> http://www.telegraph.co.uk/technology/7572285/Music-to-the-ears-of-audiophi… [12:39:22] <av500> nah, true audiophiles know that 24bit is 50% more digital(=bad, evil) than 16 bit... [12:39:30] <mru> lol [13:33:07] * kierank wonders what ubuntu did with MAP_ANONYMOUS [13:33:45] <merbzt> include sys/mem.h or something [13:33:52] <merbzt> grep for it in the includes [13:33:52] <kierank> doesn't exist [13:34:02] <kierank> looks like they removed it [13:34:51] <merbzt> #include <sys/mman.h> ? [13:35:01] <mru> it's not a standard thing anyway [13:35:10] <kierank> it's not in sys/mman.h [13:35:13] <twnqx`> try MAP_ANON only? [13:35:14] <merbzt> :/ [13:35:29] <kierank> let's see what happens if I define it manually [13:35:29] <twnqx`> wait, that one is deprecated [13:35:50] <merbzt> didn't work when I tried :/ [13:36:05] <kierank> seems to work [13:36:13] <kierank> the sections are mapped correctly too [13:36:20] <merbzt> sure ? [13:36:21] <twnqx`> which would mean... [13:36:22] <merbzt> ok cool [13:36:33] <twnqx`> it's behind #ifdef __USE_MISC [13:37:02] <twnqx`> (bits/mmap.h, included my sys/mmap.h) [13:37:02] <merbzt> yeah that was the solution [13:38:36] <twnqx`> #if defined _BSD_SOURCE || defined _SVID_SOURCE [13:38:36] <twnqx`> # define __USE_MISC 1 [13:38:36] <twnqx`> #endif [13:39:30] <kierank> where are you quoting from? [13:39:34] <twnqx`> features.h [13:40:07] <twnqx`> _GNU_SOURCE also activates it, gcc -ansi seems to (by default) deactivate those features [13:40:26] <twnqx`> the documentation at the beginning of that file seems pretty extensive [13:40:59] <kierank> ah yes it explains all [14:19:40] <BBB> http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/ <- that makes no sense, where's the ffmpeg decoder implementation? [14:20:18] <mru> right there with the rest of the vapour [14:20:55] <BBB> I suppose so... :) [14:20:58] <dgt84> bah let's at least wait for something more than a rumor to spread this stuff around... that article has no sources and is horribly written [14:21:19] <BBB> I hear the same thing from my sources... [14:21:42] <dgt84> That they are going to "open source VP8"? that doesn't even make sense... [14:21:54] * BBB loves how NYTimes always quotes sources as "... who preferred to remain anonymous for fear of their lives ..." or something similar [14:22:20] <dgt84> We need an irrevocable, royalty-free patent license with proper specs for VP8 to really even be useful [14:22:28] <BBB> opensource is a misnomer, but the expectation is that they will freely release it under royalty-free terms [14:23:02] <av500> BBB: yes, ppl mix that up a lot today [14:23:13] <BBB> anyway... it's interesting, that's all I wanted to say [14:23:29] <mru> BBB: I doubt those spreading the rumours are even capable of expecting the right thing [14:23:42] <dgt84> Yeah, I agree (I read the story last night) and am hopeful, but until we get some concrete evidence this is happening I wouldn't get my hopes up too much [14:24:26] <BBB> mru: who is spreading which rumour? [14:24:33] <mru> freetards [14:24:36] <mru> vp8 rumours [14:24:37] <BBB> oh... right [14:24:46] <BBB> I thought you had something against specific sources [14:24:55] <BBB> but yeah, freetards say the same and they are problematic noise here [14:25:02] <BBB> unfortunate... [14:25:02] <dgt84> Even if they do the above then there is still the huge hurdle of getting people to use it over H.264, which has a damn good open source encoder, hardware decoders in everything nowadays, etc [14:25:30] <BBB> dgt84: well, I suppose android would support it [14:25:37] <BBB> that's a whole load of phones in the US [14:25:48] <mru> android multimedia support isn't even a joke [14:25:49] <av500> they all do h264 too [14:25:57] <av500> BBB: ^^^^ [14:26:02] <BBB> yeah [14:26:04] <BBB> I know [14:26:06] <BBB> and they should [14:28:45] <superdump> ___gb___: ping? [14:28:48] <BBB> does mplayer wrap the qcelp encoder dll/quicktimething? [14:28:55] <BBB> any mplayer user/dev know that? [14:29:13] <merbzt> BBB: no only decoder api [14:29:22] <BBB> damnit [14:29:25] <merbzt> soundconvert() something [14:30:01] <BBB> maybe I should buy quicktimepro [14:30:05] <CIA-81> ffmpeg: mru * r22873 /trunk/tests/ref/fate/vqf-demux: FATE: update vqf-demux checksum [14:30:20] <superdump> BBB: maybe android would support it, but the underlying hardware DSPs... [14:30:22] <jai> BBB: did you ask Compn [14:30:36] <BBB> jai: no, is he involved in that? [14:30:45] <merbzt> BBB: http://www.qctconnect.com/products/purevoice_downloads.html [14:30:54] <jai> BBB: he might have access to qtpro [14:30:54] <BBB> superdump: that's what david schleef would do ;) [14:30:59] <BBB> jai: aha [14:31:01] <BBB> Compn: ping [14:31:35] <merbzt> BBB: you might need to write a demuxer for it [14:31:43] <BBB> lol: "Qualcomm: v2.0 for Mac OS 7.x - 9.x**" "**NOTE: Support for newer Mac operating systems is not planned." [14:32:11] <merbzt> BBB: is that good enough ? [14:32:23] <BBB> should work, I'll try it in wine [14:32:38] <merbzt> ahh, no linux :/ [14:33:19] <merbzt> install a virtual machine [14:33:26] <merbzt> linux is useful some times [14:33:43] <scaphilo> very often [14:33:45] <BBB> I need a new mac, not enough HD space [14:33:56] <merbzt> oh hello merbanan, nice to see you here [14:34:27] * kshishkov detects a bit of schizophrenia on merbzt [14:34:47] <BBB> yeah, or my sarcasmeter isn't functioning [14:35:28] <BBB> merbzt: thanks for the link ;) [14:35:43] <merbzt> sugerdady got what you need [14:36:32] <BBB> uhm... ... ... ... [14:36:35] * BBB decides not to reply [14:37:08] <merbzt> but you jsut did [14:37:26] <merbzt> we need to massage the SoC apps also [14:37:45] <BBB> should I mark the jmf one as ineligible? [14:37:48] <BBB> it's really crappy [14:38:00] <merbzt> and decide what project we should run [14:38:07] <av500> BBB: swap yourself in as "student" [14:38:09] <merbzt> yeah I think so [14:38:31] <merbzt> he clearly doesn't even know what we want to do [14:38:55] <BBB> ok, I removed it [14:39:24] <BBB> ok, so we have 9 students, 10 proposals now [14:39:40] <BBB> and only 3 finished qualification tasks [14:39:57] <merbzt> have you contacted all ? [14:39:59] <kshishkov> that's better than gsoc 2006 ;) [14:40:16] <superdump> i told marcelo he had until the 19th at the latest to finish his qualification task [14:40:32] <BBB> superdump: are you interacting with him? [14:40:40] <BBB> it'd be better if we had daily interaction with the students [14:41:08] <kshishkov> at least we haven't heard from the guy who wanted to do vc-1, less mentor work for me [14:41:11] <superdump> it would be, yes [14:41:21] <superdump> but i'm not currently [14:43:02] <merbzt> BBB: anyway, I think we should respond that they should sign up on the soc list and do the qualification task so we can find a suitable soc project for them [14:43:26] <merbzt> but now, evening snack [14:43:55] * kshishkov remembers svensk mat and sighs [15:05:32] <Compn> whurt? [15:05:45] <merbzt> need brains ... [15:05:48] <merbzt> er samples [15:05:50] <kshishkov> nuthin' [15:07:10] <Compn> BBB : its easier to register qt to qtpro for educational purposes... [15:07:38] <Compn> mencoder does not support encoding qtaudio for some reason [15:07:45] <Compn> mencoder does have -ovc qtvideo [15:07:53] <Compn> i wonder how hard it would be to hack up -oac qtaudio [15:08:44] <BBB> it's ok [15:08:50] <BBB> I downloaded the purevoice encoder and it appears to work [15:08:56] <BBB> now to get ffmpeg to read these files [15:09:00] <BBB> doesn't appear to be as easy ;) [15:09:55] <kshishkov> encode silence and find out frame formatting from that [15:10:13] <BBB> it's RIFF, but not wave [15:10:16] <BBB> we have a demuxer [15:10:19] <BBB> but it doesn't appear to work [15:11:25] <rtconner> anyone have any examples of taking a stream of data from a camera and making it into video? [15:12:22] * BBB thinks it's the reference decoder messing up [15:12:24] <BBB> let's try again [15:14:34] <kierank> rtconner --> #ffmpeg [15:16:03] <BBB> jai: could you please send a proposal to ffmpeg-devel@ about your project? I think it'd be interesting and we'd want it discussed before soc [15:19:14] <kshishkov> BTW, does anyone remember anything about releasing FFmpeg 0.6 ? [15:21:04] <BBB> diego [15:21:06] <BBB> ah, now it works [15:21:12] <BBB> too bad the reference decoder won't work in my tess [15:21:14] <BBB> ohwell [15:21:32] <BBB> </lazy> [15:24:36] <ohsix> astrange: there? [15:40:12] <BBB> anyone here have time for a listening test (see my email to ffmpeg-devel@) in smaller form? [15:40:16] <BBB> it's only 3 small wav files [15:58:12] <dgt84_> BBB, that's a tough test... 2 and 3 sound better than 1 to me [16:02:16] <kierank> http://www.editshare.com/index.php?option=com_wrapper&Itemid=208 [16:04:09] <kshishkov> anything useful for FFmpeg? [16:05:25] <kierank> probably some RED things and maybe some loose ends with dpx if there are any [16:06:04] <kshishkov> no dolby-e mastering ;) [16:06:25] <kierank> that app's for movies, dolby e is for tv broadcasts [16:08:33] <kshishkov> too bad they don't have formats from the biggest rival [16:09:00] <kierank> rival to whom? [16:09:34] <kshishkov> in movie editing field [16:09:44] <BBB> dgt84_: please email the list, any reason you think 1 is worse? [16:10:11] <BBB> dgt84_: and did you also compare it with the qualcomm-output.wav? [16:10:47] <kierank> kshishkov: dpx, exr and what else? [16:11:29] <kshishkov> kierank: mov [16:12:34] <kierank> I presume you are talking about the fruit-based codecs [16:12:45] <kshishkov> of course [16:13:07] <kshishkov> prores and AIC are often requested to support [16:16:07] <dgt84_> BBB, emailed, and yeah the qualcomm output sounds like 2 and 3 to me [16:21:36] <BBB> dgt84_: thanks [17:01:31] <merbanan> um ? what is the name of our foundation and website ? [17:01:57] <kshishkov> ffmtech.org? [17:02:50] <kshishkov> yes, looks like our website :) [17:03:04] <av500> not much of a website :) [17:05:04] <jai> BBB: okay, i' [17:05:07] <jai> err [17:05:22] <jai> BBB: okay, i'll come with some text and send a mail [17:05:54] <BBB> thanks [17:06:17] <BBB> yes, I'm waiting for koth to install a CMS but he's busy or something [17:06:48] <dgt84_> also seems to be quite a few releases behind for the web server (latest is lighty 1.4.26 afaik) [17:07:07] <mru> why do we need a cms? [17:07:13] <jai> cms? isnt that overkill :) [17:07:23] <av500> isnt that en vogue? [17:07:25] <kshishkov> because somebody is too lazy to commit to svn with pages [17:07:28] <mru> whoever makes the website can run whatever he wants locally and export flat html [17:08:53] <kshishkov> M$ Frontpage? [17:09:09] <mru> he wouldn't want that [17:09:13] <jai> Dreamweaver? with html5 support ;) [17:09:14] <av500> Netscape Navigator Composer? [17:10:15] <mru> 3.04 gold ftw [17:10:23] <av500> yup [17:10:44] <av500> ok, we settled that then :) [17:12:36] <jai> and here you go http://sillydog.org/narchive/full123.php [17:12:38] <jai> av500: ^ [17:14:21] <av500> "...With audio and video support, providing users with an integrated solution that extended the multimedia and communications capabilities of their desktops...." [17:14:30] <av500> sounds like a winner to me [17:15:41] <merbanan> you only need 6mb to run it also [17:16:04] <jai> do the linux binaries even work? [17:16:56] <merbanan> no :/ or they shouldn't [17:17:07] <merbanan> libc issues should occur [17:17:09] <av500> jai: I doubt it [17:17:16] <av500> but I trust the win ones will [17:17:26] <mru> the links are dead [17:17:34] <av500> good riddance [17:17:34] <merbanan> the vqf sdk didn't work [17:17:50] <mru> I have some old netscape on an irix machine... [17:17:51] <merbanan> though it was old c++ code [17:18:32] <jai> yeah, thought as much [17:30:52] <rtconner> kshishkov is there an irc for using the avcodec api? #ffmep seems to be just for using it command line [17:31:06] <rtconner> #ffmpeg [17:33:26] <kshishkov> personally I don't know [17:34:03] <rtconner> (i thought that was this room :blush:) [17:34:11] * mru thought #ffmpeg was for converting stuff to flv [17:34:40] <relaxed> rtconner: maybe https://lists.mplayerhq.hu/mailman/listinfo/libav-user/ [18:15:05] <Kovensky> I remember this "Kurso de Esperanto" program, some abandoned freeware program [18:15:09] <Kovensky> it has windows and linux builds [18:15:18] <Kovensky> the latest linux build IIRC is for debian woody [18:16:44] <elenril> Yuvi: where do matroska specs say that tags must be uppercase? [18:22:00] <Kovensky> o_O [18:22:13] <Kovensky> I remember reading a bit of matroska specs and I don't remember that detail [18:22:19] <Kovensky> if anything they'd be CamelCase ._. [18:23:14] <elenril> no, the "official" tags are uppercase [18:23:27] <elenril> but nothing says that this applies to all tags [18:26:07] <jai> elenril: "The TagName should always be written in all capital letters and contain no space." [18:26:54] <elenril> oh, thanks [18:27:01] * elenril was searching for uppercase [18:27:22] <Kovensky> meh [18:27:23] <elenril> except it's retarded [18:27:25] * Kovensky needs to read more [18:27:29] <Kovensky> elenril: indeed [18:27:46] <elenril> what does uppercase mean for the moon language? [18:27:58] <elenril> or are keys limited to latin1? [18:28:05] <Kovensky> writing in all katakana? =p [18:28:14] <Kovensky> but I don't think tag names are in moon [18:28:15] <mru> afaik only latin and cyrillic have upper/lower case [18:28:28] <kshishkov> georgian too [18:28:37] <mru> what does that look like? [18:28:37] <kshishkov> greek [18:28:42] <mru> ah, greek of course [18:28:45] <mru> how could I forget that [18:29:16] <mru> the point remains, most scripts don't have it [18:29:41] * BBB kicks stupid IRC client [18:29:53] <elenril> use irssi =p [18:31:05] <Kovensky> Colloquy... never heard about that ._. [18:31:10] <kshishkov> mru: I don't think Matroska creators cared about other languages [18:31:17] <mru> Kovensky: iphone irc client [18:31:19] <kshishkov> Kovensky: it's for MacOSX [18:31:28] <kshishkov> desktop too [18:31:40] <Kovensky> kshishkov: I think they did, since all text in it is (afaik) utf-8 [18:31:43] <elenril> kshishkov: more like they forgot to use that thing in their heads [18:31:47] <mru> there were a lot of things matroska creators didn't care about [18:31:54] <Kovensky> maybe "all capital letters" can be ignored for scripts that don't have capital letters? =p [18:32:17] <kshishkov> elenril: eyes or brain? [18:32:30] <kshishkov> of course it can [18:32:37] <elenril> Kovensky: or maybe we can check what haali's splitter does ;) [18:32:59] <Kovensky> elenril: you're willing to reverse engineer Haali code? =p [18:33:12] <Kovensky> well, can't be worse than gabest code [18:33:18] <jai> contrive a sample and see what haali's code does [18:33:38] <elenril> or i could apt-get source mkvmerge [18:33:45] <jai> ..or that [18:33:46] <Kovensky> that's mosu code =p [18:33:57] <mru> haali's code is not pretty, but I've seen worse [18:34:04] <jai> mlvtoolnix is quite readable [18:34:06] <Kovensky> (also, mkvmerge's tag handling was p. bad last time I checked) [18:34:16] <jai> haali releases code? [18:34:28] <Kovensky> jai: his matroska parser, used in ffms2 [18:34:40] <jai> hmm [18:35:07] <Kovensky> <@mru> haali's code is not pretty, but I've seen worse <-- where, tdwtf? :> [18:35:37] <kshishkov> Kovensky: almost any enterprise code is extremely ugly [18:36:32] <Kovensky> tdwtf then ._. [18:36:44] <Kovensky> at least almost everything that ends up there is enterprise code =p [18:37:20] <kshishkov> enterprise = written in big corporations (usually by Indians/Chinese/Hungarians) [18:37:46] <Kovensky> lol hungary [18:38:04] <Kovensky> why have I never heard about anything from hungary other than hungarian notation and Dalriada [18:38:18] <Kovensky> oh, and gabest [18:38:20] <kierank> and hippos [18:38:22] <kshishkov> and the first thing was invented by M$ programmer! [18:38:22] <jai> and the hungarian demoscene groups [18:38:58] <Kovensky> there are hippos in hungary? o_O [18:39:02] <kshishkov> and MPlayer creator [18:39:07] <Kovensky> oh, arpi [18:43:02] <thresh> lol @ ubuntu, apache, java: https://blogs.apache.org/infra/entry/apache_org_04_09_2010 [18:45:37] <Kovensky> "This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights." <-- lrn2noscript :P [18:47:05] <kshishkov> long live Bobby Tables too! [18:47:17] <Kovensky> :3 [18:49:38] <elenril> hmm, mkvmerge happily muxes tags in japanese [18:50:27] <jai> do those work with lavf? [18:50:32] <kshishkov> try lowercase [18:50:52] <elenril> jai: ofc [18:50:54] <jai> k [18:51:47] <Kovensky> <+elenril> hmm, mkvmerge happily muxes tags in japanese <-- as in tags with japanese values or japanese names [18:52:06] <dgt84_> Anyone know how a libavfilter filter would work with several reference frames into the future of the current frame? I.E. how can it store X frames, then start outputting data? It's not obvious from the API [18:52:33] <elenril> Kovensky: both [18:52:39] <elenril> kshishkov: those remain lowercase [18:53:22] <kshishkov> fine [19:10:14] <Yuvi> DonDiego: pong [20:49:28] <j-b> ramiro ? [20:49:29] <j-b> libavcodec/adxdec.c:1: warning: -fPIC ignored for target (all code is position independent) [20:50:27] <drv> is that mingw-w64? i get that too, probably needs some additional configure trickery [20:50:35] <drv> but it seems to work other than that [20:50:39] <j-b> drv: yes mingw-w64 [20:53:14] <mru> fix the compiler to shut up that warning [20:54:05] <BBB> m... [20:54:10] <BBB> we've been assigned 10 slots [20:54:13] <BBB> but we only have 9 students [20:54:18] <BBB> that's a little problematic [20:54:27] <_av500_> BBB: beagle will gladly take one [20:54:45] <saintdev> auction one off :P [20:55:41] <_av500_> BBB: i guess you would love a BB :) [20:58:06] <mru> to play BBB on [20:58:28] <_av500_> BBB playing BBB on BB [20:58:34] <Dark_Shikari> But can you play the BBB blu-ray we're about to release? [20:59:12] <mru> maybe with the beagle xm we're about to release [20:59:17] <mru> no, doubtful [20:59:23] <mru> but the next one will play it [20:59:53] <peloverde> how is vlc/x264 doing? [20:59:56] <peloverde> do they need extra? [21:00:00] <Dark_Shikari> we got 15 [21:00:06] <Dark_Shikari> Probably more than we need. [21:00:14] <Dark_Shikari> 48 apps, 15 slots [21:00:15] <mru> is it allowed to trade slots? [21:00:18] <Dark_Shikari> Yes iirc [21:06:45] <j-b> we will give slots back [21:32:47] <peloverde> It's a shame, perhaps next year we need to find a way to market ourselves better [21:34:43] <_av500_> next year, there will be so many VP8 related projects :) [21:39:54] <Dark_Shikari> lol right =p [21:41:47] * mru cynically suspects the number of successful projects will be roughly the same this year as in previous years [21:42:02] <mru> roughly = 0.5 [21:42:11] <DonDiego> Yuvi: ping timeout [21:43:03] <DonDiego> BBB: the application deadline has passed, so it's not possible to generate some new students out of thin air? [21:43:10] <DonDiego> Yuvi: ping timeout [21:43:12] <BBB> no, unfortunately [21:43:16] <BBB> that'd be a good idea [21:43:28] <saintdev> DonDiego: you must be having routing issues to Yuvi [21:43:53] <BBB> we tried to market but I don't think it made much of a difference [21:43:54] <BBB> ... [21:43:55] <BBB> :-/ [21:43:55] <DonDiego> Yuvi: around? awake? [21:44:34] <DonDiego> i don't think past years were too good a marketing [21:44:50] <DonDiego> but i'll shut up before i get misquoted out of context again [21:45:12] * DonDiego has a mail drafted to the soc-mentors list somewhere.. [21:50:25] <DonDiego> can somebody confirm that my h.264 patch is safe to commit? [21:50:44] <mru> should be [21:50:53] <DonDiego> moving the static function fill_filter_caches() from h264.h to h264.c.. [21:51:03] <mru> the only change was a reversed comparison and conditional jump [21:51:11] <mru> why it did that mystifies me [21:51:20] <mru> but it shouldn't matter [21:51:47] <DonDiego> what are those instructions? [21:51:59] <DonDiego> cmpl, ja, jb [21:54:02] <drv> ja is jump if above, jb below (both unsigned) [21:54:34] <drv> and cmpl is just comparison [21:55:38] <Yuvi> DonDiego: back [21:55:50] <DonDiego> ok, then it's identical, just reversed [21:55:59] <DonDiego> gcc was rolling the dice.. [21:56:07] <DonDiego> i'll commit [21:56:08] <hyc> heh [21:56:25] <hyc> hey DonDiego, while you're here - how about committing my librtmp logging patch? [21:56:33] <drv> more like a magic 8 ball, sometimes you just get "try again later" ;) [21:56:35] <hyc> I doubt anyone else on the mailing list cares [21:56:49] <DonDiego> hyc: ffmpeg? mplayer? [21:56:56] <hyc> ffmpeg [21:57:00] <hyc> lemme dig up the post [21:57:28] <hyc> https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086629.html [21:57:31] <DonDiego> geez, did we run out of patch monkeys already? [21:57:51] <hyc> nobody has replied, I could ping the list again if that's better [21:57:53] <DonDiego> more than 20 lazy-ass ops around here.. [21:58:06] <DonDiego> hyc: btw, are you identified? [21:58:17] <hyc> but it's obviously code that only I care about [21:58:21] <hyc> eh? identified? [21:58:29] <mru> I'm not lazy, I just don't care :-) [21:58:56] <DonDiego> hyc: identified to nickserv [21:59:02] <hyc> should be [22:04:31] <DonDiego> hyc: you're the author of that file, right? [22:06:17] <hyc> Diego: right [22:06:47] <DonDiego> i'll commit it in a moment if you suggest a good commit message [22:08:54] <hyc> umm. "Plug librtmp logging into av_log." ? [22:09:42] <CIA-81> ffmpeg: diego * r22874 /trunk/libavformat/librtmp.c: whitespace cosmetics [22:10:07] <DonDiego> hyc: nit: space after switch [22:10:12] <hyc> ok [22:10:38] <DonDiego> next nit: place system headers before local ones [22:11:53] <hyc> so: switch (level) { [22:12:14] <CIA-81> ffmpeg: diego * r22875 /trunk/libavformat/librtmp.c: [22:12:14] <CIA-81> ffmpeg: Plug librtmp logging into av_log. [22:12:14] <CIA-81> ffmpeg: patch by Howard Chu, hyc highlandsun com [22:12:18] <DonDiego> yes [22:13:58] <hyc> Thanks for that [22:15:37] <BBB> switch(level) { is also ok right? [22:15:54] <DonDiego> nope [22:15:58] <hyc> that's what it was [22:16:05] <BBB> oh [22:16:08] <DonDiego> K&R says: space after keyword [22:16:19] <DonDiego> between keyword and '(' [22:16:24] <BBB> function_call(x, y, z); has no space? [22:16:29] <DonDiego> yes [22:16:32] <drv> that's not a keyword :) [22:16:43] <CIA-81> ffmpeg: diego * r22876 /trunk/libavcodec/ (h264.c h264.h): [22:16:43] <CIA-81> ffmpeg: Move static function fill_filter_caches() from h264.h to h264.c. [22:16:44] <CIA-81> ffmpeg: The function is only used within that file, so it makes sense to place [22:16:44] <CIA-81> ffmpeg: it ther. This fixes many warnings of the type: [22:16:44] <CIA-81> ffmpeg: h264.h:1170: warning: ?fill_filter_caches? defined but not used [22:16:54] <DonDiego> this fixes at least a dozen warnings [22:17:15] <DonDiego> hyc: anything else i can do for you? :) [22:17:23] <drv> i wish gcc wouldn't try to use those silly fancy quotes [22:18:18] <mru> what locale have you set? [22:18:39] <drv> utf8 something, i guess [22:18:43] * DonDiego waits in vain for the cheers [22:18:45] <hyc> DonDiego: that's plenty for now, thanks. just waiting for Michael to make a decision on https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086805.html [22:20:07] <hyc> he already gave the OK for the main patch https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086785.html [22:20:18] <hyc> but it's still broken until the error code discrepancy is fixed [22:20:55] <DonDiego> i think we can quickly move you through the ranks and make you a committer if you are interested in staying around for the long haul [22:21:36] <DonDiego> you're a pretty senior dev already.. [22:21:47] <hyc> that's hard to say. I would not have expected to, but in fact I find I've had local SVNs since 2007 so apparently I have long term itnerest and just didn't know it :P [22:21:49] <BBB> DonDiego: can you apply http://archives.free.net.ph/message/20100406.133102.59b83dec.el.html? [22:22:14] <BBB> or http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107400, same [22:22:20] <BBB> actually, maybe I should do it [22:22:24] <Kovensky> <@drv> i wish gcc wouldn't try to use those silly fancy quotes <@mru> what locale have you set? <@drv> utf8 something, i guess <-- it'd use `these retarded quotes instead' [22:22:26] <BBB> I think ramiro wanted me to change something [22:22:39] <Kovensky> (if you were in a latin-1 locale, that is) [22:22:46] <drv> yeah, `' quotes are almost worst [22:22:57] <drv> but at least they don't get mangled by utf-8 unaware software [22:22:58] <mru> better than the utf8 ones [22:24:17] <Kovensky> move gcc to "real-gcc", make gcc do $(real-gcc "$@" | perl -pe"s/'\`/\"/g") [22:24:28] <hyc> ugh [22:24:39] <hyc> weren't we just talking about how much inserting perl slows down the compile? [22:24:40] <Kovensky> it gets rid of the silly quotes :P [22:24:47] <hyc> no wait, that was #mplayerdev [22:24:48] <Kovensky> add the UTF-8 ones to the s/// list~ [22:24:54] <Kovensky> hyc: o rly [22:25:03] <mru> tr is probably faster than perl [22:25:09] <hyc> yep [22:25:11] <Kovensky> mru: true, but you'd need multiple trs [22:25:14] <mru> no [22:25:21] <Kovensky> tr can do multiple replaces? [22:25:26] <mru> of course [22:25:31] <hyc> yes list1 -> list2 [22:25:59] <Kovensky> oic [22:26:00] <hyc> it's a poor man's clone of the IBM 360 TRT instruction [22:26:08] <mru> in this case, simply put multiple ' in the second list [22:26:28] <DonDiego> BBB: why should i apply some ff_neterrno patch that you sent? [22:26:46] <BBB> I'm lazy and have no time [22:27:00] <BBB> but it's ok I'll do it [22:27:05] <BBB> but it'll have to wait for another day or so :( [22:41:53] <DonDiego> Yuvi: re: ogg and theora - what's the status? [22:42:12] <saintdev> peloverde: ping [22:42:19] <peloverde> pong [22:42:37] <saintdev> i don't have my logs, but why were you saying not to use psnr for audio? [22:42:52] <saintdev> s/i don't have/it's not in/ [22:44:03] <peloverde> not using psnr for audio to do what? [22:44:39] <peloverde> judge an encoder? verify a decoder? [22:44:49] <saintdev> judge an encoder [22:45:17] <peloverde> because the psymodel completely fucks PSNR [22:45:21] <saintdev> i know why psnr in general is a bad idea, but there was something specific to audio you stated that made it extra bad [22:45:40] <saintdev> well yeah, psy will do that :P [22:45:54] <saintdev> is it just that audio encoders use more psyopts than video encoders generally? [22:46:46] <peloverde> you wouldn't want to run an audio encoder with a psymodel off except for testing purposes or at extremely high bitrates [22:47:12] <peloverde> there are other metrics that take the psymodel into account that can be used to numerically estimate quality [22:47:16] <peloverde> like NMR [22:47:18] <Kovensky> IIRC the only reason vorbis is better than the other current encoders is because of better psy optimization [22:47:34] <Kovensky> (I'm not sure if it's better than neroaac, but last time I checked it was better than everything) [22:47:43] <Kovensky> vorbis as in aotuv's libvorbis [22:49:02] <peloverde> At SBR bitrates it doens't hold up to nero [22:49:24] <peloverde> At mid and high bitrates last I saw they are tied [22:51:35] <DonDiego> peloverde: btw, aacsbr.c spits out a lot of warnings.. [22:51:51] <peloverde> DonDiego, see the discussion during patch review [22:52:08] <peloverde> It's the multilevel array const cast issue [22:53:02] <CIA-81> ffmpeg: diego * r22877 /trunk/libavcodec/error_resilience.c: Add rectangle.h #include for fill_rectangle(). [23:06:59] <DonDiego> Yuvi: ping [23:07:11] <DonDiego> geez, we have a knack for missing each other on irc.. [23:20:16] <iive> peloverde: should i understand the above as a sign that the aac encoder is progressing well? [23:20:51] <iive> and that maybe after it is complete the ff vorbis enc may get magically a lot better than now. [23:21:03] <peloverde> Not really, I'm still finishing PS [23:23:11] <CIA-81> ffmpeg: stefano * r22878 /trunk/libavfilter/avfiltergraph.c: [23:23:11] <CIA-81> ffmpeg: Make avfilter_graph_add_filter() returns AVERROR(ENOMEM) in case of [23:23:11] <CIA-81> ffmpeg: failed reallocation, rather than just -1. [23:25:15] <CIA-81> ffmpeg: stefano * r22879 /trunk/libavcodec/utils.c: Factorize code in get_bit_rate(). [23:28:51] <DonDiego> ok, i'm off to bed.. [23:42:39] <CIA-81> ffmpeg: stefano * r22880 /trunk/ffprobe.c: [23:42:39] <CIA-81> ffmpeg: Fix computation of the display aspect ratio. [23:42:39] <CIA-81> ffmpeg: Previously ffprobe was wrongly outputting the sample aspect ratio as [23:42:39] <CIA-81> ffmpeg: display aspect ratio. [23:42:39] <CIA-81> ffmpeg: Patch by Robert Kr?ger $(echo k-r-u-e-g-e-r(a)s-i-g-n-a-l-7.d-e | sed s/-//g).

1 0

IRC log for 2010-04-12
by irc＠mansr.com 13 Apr '10

13 Apr '10

[00:09:30] <SmkMnstr> got ffmpeg linking with my app in linux & windows [00:14:46] <ramiro> nice flamebait from AzureSky in issue1162... [00:16:22] <ramiro> SmkMnstr: mind I ask, what app is it? [03:31:14] <Compn> ehe [03:31:54] <Compn> i had to reply to troll, just in case any people got trolled, we'd be flooded by 'why u so mean?' questions if it were posted to slashdot... [03:35:43] <Dark_Shikari> he'd be mocked on slashdot [03:35:46] <Dark_Shikari> ffs he bragged about his iq [03:40:06] <Dark_Shikari> mru: __asm__ volatile ("bl __aeabi_idivmod [03:40:08] <Dark_Shikari> is that portable? [03:40:11] <Dark_Shikari> that looks compiler-specific [03:44:09] <ohsix> its part of the abi [03:45:59] <Compn> Dark_Shikari : stupid trolls get bites too [03:46:00] <Dark_Shikari> wow, so the abi defines the name of functions like that? [03:46:16] <Compn> how is babby formed? [03:54:35] <kierank> licensing is hard. lets go shopping [05:30:40] <pJok> god morgon kshishkov :) [07:14:02] <KotH> en wunderschöne guete morge! [07:15:55] <kshishkov> in some places [07:16:47] <KotH> a good morning begins in your head [07:16:50] <KotH> ;) [07:17:10] <kshishkov> guess what messes with my head in the first place [07:20:27] <KotH> your brain? [07:20:38] <kshishkov> no, local environment [07:20:57] <KotH> you cannot change your enviroment, without first changing yourself [07:21:38] <hyc> how very zen [07:21:44] <kshishkov> circumcision? [07:22:24] <KotH> might be a way, but i wouldnt start with a lobotomy [07:25:20] <CIA-81> ffmpeg: thardin * r22846 /trunk/libavformat/movenc.c: Predicting the size of the hdlr, string data and trkn tags in the MOV muxer [07:26:21] <superdump> morning [07:26:30] <kshishkov> morrow [07:38:39] <av500> 'ng [07:39:48] <kshishkov> learn how to speak [07:40:29] <KotH> ze jermans könt spiiik [07:41:42] <kshishkov> indeed, but German words may scare even Finns [07:44:41] <av500> jetzt hab dich nicht so [07:45:17] <kshishkov> not really [07:45:33] <kshishkov> Russian language is a poor cousin of German language [07:46:22] <KotH> av500: i think we should teach kshishkov some german :) [07:46:37] <av500> "Papiere bitte!" [07:49:31] <kshishkov> KotH: I mentioned it several times that I have rather good German accent [07:52:47] * av500 larts theorarm for requiring libogg [07:53:33] <kshishkov> but Ogg and Theora is like communism and Lenin! [07:56:06] <kshishkov> (or XML and Java) [07:56:31] <Dark_Shikari> open sores is communism!1!! [07:56:33] <peloverde> What always bugs me about these theora articles is the way they frame things they imply that there is no open source implementation of the standard codecs [07:57:04] <kshishkov> peloverde: maybe because theraplay can't handle h264+aac [07:57:29] <peloverde> theraplay? [07:58:03] <kshishkov> err, default theora player shipped with libtheora [07:58:04] <KotH> there is no opensource implementation! there is no reference code! [07:58:07] <KotH> ^^' [08:42:42] <superdump> peloverde: seen that sample someone posted about the ugly transitions? [08:44:03] <Yuvi> mru: btw, ffvorbis is 2x faster than tremor on a8 [08:44:41] <kshishkov> Yuvi: that does not matter, FFmpeg does not exist it their eyes [08:45:06] <Yuvi> just congratulating him ;) [08:45:33] <Yuvi> it's about even on arm11 if anyone cares enough about that to write a ton of vfp [08:47:42] <andoma> I don't think VFP is much faster than normal FPU code, it's just a bit more compact [08:50:02] <Yuvi> I'd think should be able to use its vector mode for some speedup, but I haven't looked at it too closely (other than that it's depreciated in favor of neon simd going forward) [08:54:01] <andoma> I think the only speedup you would gain is lower pressure on the I-cache [08:54:46] <andoma> AFAIK the VFP instructions basically loops multiple FPU instructions to "emulate" some kind of vector behaviour [08:54:53] <andoma> but i think MÃ¥ns knows all the details [09:06:23] <Yuvi> looks like it, but it also looks like you can't keep multiple vfp pipelines fully busy unless you use short vectors [09:07:05] <Yuvi> so there's some room for improvement over compilers [09:13:54] <peloverde> superdump, yes [09:14:54] <superdump> and? are there really audible artifacts because of the transitions? :) [09:14:58] <superdump> or is the file just garbage [09:15:00] <superdump> ? [09:53:27] <peloverde> I haven't actually looked at the file [09:54:28] <peloverde> my guess is that it isn't actually an audible artifact from the window transition but I have yet to verify [09:54:40] <peloverde> I've been trying to iron the last few bugs out of the ps decorrelator [09:57:43] <superdump> :) [09:58:15] <kshishkov> well, maybe your PS work makes AAC encoder usable as a side effect [09:58:27] <superdump> umm [10:02:42] <kshishkov> superdump, you should remember certain consequences of your work on AMR-NB [10:41:11] <mru> andoma: vfp vector ops are not truly parallel, but you can carry on doing integer stuff while it executes in the background [10:43:17] <kshishkov> that's what coprocessors are for! [10:44:42] * kshishkov remembers x87 and shudders [10:45:04] <thresh> copro-cessors? [10:45:48] <kshishkov> in case of Intel - yes [10:46:02] <thresh> moroning, btw [10:47:02] <kshishkov> it's too late for that [10:48:30] <mru> not here [10:50:01] <kshishkov> wait a bit then [11:15:37] <CIA-81> ffmpeg: mru * r22847 /trunk/libavcodec/dca.c: DCA: use some type-punning in qmf_32_subbands() [11:15:40] <CIA-81> ffmpeg: mru * r22848 /trunk/libavcodec/dca.c: [11:15:40] <CIA-81> ffmpeg: DCA: use a local variable for loop boundary [11:15:40] <CIA-81> ffmpeg: This prevents gcc reloading the value from memory on each iteration [11:15:40] <CIA-81> ffmpeg: of the loop. [11:15:40] <CIA-81> ffmpeg: mru * r22849 /trunk/libavcodec/ (dcadata.h dca.c): [11:15:41] <CIA-81> ffmpeg: DCA: simplify lfe_interpolation_fir() [11:15:42] <CIA-81> ffmpeg: This reorders the lfe_fir tables, and drops the mirrored half, [11:15:42] <CIA-81> ffmpeg: such that the loops in lfe_interpolation_fir() can be simplified. [11:15:43] <CIA-81> ffmpeg: The new loop structure should be easier to implement with SIMD. [11:15:43] <CIA-81> ffmpeg: Static data size is reduced by 2kB. [11:15:44] <CIA-81> ffmpeg: 3% faster on Cortex-A8. [11:28:32] <CIA-81> ffmpeg: diego * r22850 /trunk/doc/general.texi: Fix extra object path in Solaris section. [12:00:58] <av500> hmm, FFMPEG_VERSION is not exported in lavf, lavc? [12:01:28] <mru> seems not [12:01:54] <mru> patches welcome I guess [12:01:58] <av500> :) [12:02:15] <av500> atm it does not work for me anyway, as my tgz snapshots dont get it... [12:03:07] <av500> so it is "UNKNOWN" :( [12:27:11] <pentanol> hello :) [12:28:14] <pentanol> anybody knows, how watermark actually should work? i.e if I tries change everyone picture from video stream by algorithm dugad or cox, it can be right? or I should involve another picture here and how it compute then? [12:29:06] <pentanol> I've seen this http://thread.gmane.org/gmane.comp.video.ffmpeg.user/5959/focus=5960 and that http://thread.gmane.org/gmane.comp.video.ffmpeg.user/11625 and this confuse me [13:22:34] <CIA-81> ffmpeg: jai_menon * r22851 /trunk/libavcodec/alacenc.c: Remove useless header inclusion. [13:29:49] <CIA-81> ffmpeg: mru * r22852 /trunk/libavcodec/arm/synth_filter_neon.S: ARM: fix NEON synth_filter_float with hardfp calls [13:54:35] <BBB> we should really buy vitor more beer, he's genious [15:04:20] <CIA-81> ffmpeg: cehoyos * r22853 /trunk/libavformat/aviobuf.c: [15:04:20] <CIA-81> ffmpeg: Do not set pos to an error value. [15:04:20] <CIA-81> ffmpeg: Patch by Howard Chu, hyc highlandsun com [15:17:41] <CIA-81> ffmpeg: diego * r22854 /trunk/doc/general.texi: [15:17:41] <CIA-81> ffmpeg: Add DOS section to the platform documentation. [15:17:41] <CIA-81> ffmpeg: patch by Michael Kostylev, michael.kostylev gmail com [16:05:59] <CIA-81> ffmpeg: mru * r22855 /trunk/libavcodec/dca.c: DCA: use FASTDIV in decode_blockcode() [16:17:34] <CIA-81> ffmpeg: benoit * r22856 /trunk/libavcodec/huffyuv.c: [16:17:34] <CIA-81> ffmpeg: Extradata length checks for Huffyuv. [16:17:34] <CIA-81> ffmpeg: Patch by Michael Kaufmann hallo $(name) dash $(surname) ch [17:44:21] <elenril> Yuvi: ping [18:51:03] <stupid> @mru : Does ffmpeg runs any codes on DSP ? I want to port some part of mplayer on dsp so that mplayer can use both ARM & DSP for video decoding [18:51:14] <kshishkov> it doesn't [18:51:36] <j-b> I want a poney too [18:52:05] <kshishkov> take Citroen 2CV instead [18:52:17] <bilboed> a poney pulling a 2CV filled with mars bars [18:52:20] <stupid> HI ALL : Does ffmpeg runs any codes on DSP ? I want to port some part of mplayer on dsp so that mplayer can use both ARM & DSP for video decoding [18:52:34] <hyc> stupid: you already got your answer [18:52:52] <kshishkov> and appropriate nick for repeating that question [18:53:06] <hyc> besides, you haven't said *which* DSP... [18:53:27] <kshishkov> C64 most probably [18:53:46] * twnqx` has a defective C64 straight in front of him [18:53:48] <kshishkov> the answer is still no [18:53:53] <hyc> lol [18:53:56] <SmkMnstr> if so yes i believe ffmpeg has c64+ and NEON codec impls [18:54:06] <hyc> c64 only if it's TI [18:54:06] <SmkMnstr> ah no? u sure? [18:54:18] <hyc> and no, ffmpeg only does NEON [18:54:37] <SmkMnstr> hm theres also dvsdk [18:54:48] <j-b> Use OpenMax IL on DSPs, if you are lucky [18:55:00] <stupid> I am using C64DSP on beagleboard [18:55:15] <stupid> hyc : i am usign C64+ DSP on beagleboard [18:55:34] <hyc> I hear an echo in here [18:55:43] <stupid> I already ported mplayer on Android. I activated DSPLINK drivers in there [18:55:57] <kshishkov> I'm not a prophet of MÃ¥ns but I believe he spake that TI C64+ compiler was hard to interface so no C64+ DSP support in FFMpeg [18:56:13] <stupid> I want to know exactly which codes do i need to port [18:56:26] <hyc> I asked mru about this back in Auguest/September [18:56:28] * elenril gives hyc a clue stick [18:56:41] <jai> elenril: cluebat works better [18:56:54] <j-b> Doesn't beagleboard has OpenMax IL ? [18:57:17] <hyc> OpenMax is kind of a mess to build [18:57:23] <bilboed> s/to build// [18:57:30] <stupid> No android doesn't uses that .. Bt i ported mplayer and tested it there [18:57:36] <kshishkov> and so will be FFmpeg with DSP support [18:58:15] <hyc> took me days to get it all to build for my AI TouchBook, and it still didn't run properly in the end [18:58:42] <hyc> AI TouchBook is derived from an early rev Beagleboard... [18:58:46] <kshishkov> maybe you should've used crosscompiler [18:58:59] <stupid> @kshishkov : Could you please tell me exactly which codes do I need to port on DSP [18:59:27] <kshishkov> stupid: probably decoders and functions from dsputil [18:59:50] <hyc> yes, I was crosscompiling from my laptop, the time was mostly from obtaining consistent source code [19:00:20] <SmkMnstr> ive been gearing up to use ffmpeg, but now i need to be more aware of openmax [19:00:21] <hyc> there were 3 different TI web sites offering the code, 2 of them were obsolete [19:01:50] <kshishkov> so what? none of them worked at the end for you [19:02:21] <hyc> well, I sent a couple patches back to the maintainers after I got it close [19:02:36] <hyc> but yeah, mostly a waste of time [19:02:52] <kshishkov> that's why I develop FFmpeg instead [19:03:01] <hyc> should've ended this conversation at "I want a pony" [19:04:23] * kshishkov wonders why ponies are so popular [19:04:47] <SmkMnstr> how much resources does it take to stream a/v from a beagle? [19:05:04] <kshishkov> three [19:05:07] <SmkMnstr> from a webcam/mic [19:05:08] <hyc> dunno. comes from some stereotype of little girls saying "I want a pony for christmas" [19:05:15] <SmkMnstr> u can tell me size/bitrate and cpu% [19:05:26] <SmkMnstr> framerate, etc whatev relevant [19:05:47] <hyc> SmkMnstr: stream what a/v? [19:05:49] <kshishkov> you'd better try it and measure [19:05:57] <SmkMnstr> well i will soon enough [19:06:26] <kshishkov> some cpu may be eaten by USB/network stuff [19:06:58] <SmkMnstr> i wont actually have my gizmos up for another month or so [19:07:11] <SmkMnstr> anxiously awaiting their shipment [19:07:18] <hyc> playing hulu live on the TouchBook is a near thing [19:07:25] <hyc> rtmpdump takes 1-2% CPU [19:07:34] <SmkMnstr> in the meantime i have a cross platform build tree im preparing for the day i have gizmos [19:07:48] <hyc> mplayer takes ~85% CPU on average, for 512x288 VP6 [19:07:50] <kshishkov> hyc: it takes 0% on any CPU here :P [19:08:15] <hyc> 400kbps [19:08:54] <hyc> kshishkov: eh? I haven't seen any accelerated VP6 [19:09:26] <kshishkov> hyc: in my case it's all accelerated by skipping it totally, including never visiting Hulu site [19:09:42] <Yuvi> elenril: pong [19:10:00] <hyc> well, that was the task that broguht me here in August... [19:10:26] <elenril> Yuvi: can you review tags writing for matroska? [19:10:53] <elenril> it's been a few weeks, i was wondering if you forgot about it [19:10:58] <Yuvi> elenril: right, I need to get caught up with my email [19:15:29] <elenril> no hurry, as long as it's not completely forgotten :) [19:17:14] <Kovensky> oh, Yuvi; long time no see =p [19:21:59] <CIA-81> ffmpeg: stefano * r22857 /trunk/libavcodec/eval.c: Remove unnecessary header inclusion directives. [19:22:02] <CIA-81> ffmpeg: stefano * r22858 /trunk/libavcodec/ (eval.c eval.h ratecontrol.c): [19:22:02] <CIA-81> ffmpeg: Rename ff_parse() to ff_parse_expr(). [19:22:02] <CIA-81> ffmpeg: The new name is more expressive and fits better in the overall naming [19:22:02] <CIA-81> ffmpeg: scheme for the revisited eval API. [19:22:02] <CIA-81> ffmpeg: stefano * r22859 /trunk/libavcodec/ (eval.c eval.h): [19:22:02] <CIA-81> ffmpeg: Change constness for func[12]_name parameters of ff_parse_expr() and [19:22:03] <CIA-81> ffmpeg: ff_parse_and_eval_expr(). [19:22:03] <CIA-81> ffmpeg: Change attribute from "const char **" to "const char * const *". [19:22:04] <CIA-81> ffmpeg: The name arrays are not supposed to be changed by the function. [19:41:28] <mru> hyc: you use vp6? [19:42:04] <hyc> mru: we didn't have enough CPU to do H264 at the time [19:42:36] <hyc> I haven't checked if more recent neon code does better [19:44:04] <hyc> most stuff on hulu is still available as 400kbps VP6, in addition to 3 choices of H264 (400k, 650k, 1Mbps) [19:44:18] <hyc> hm, 480kbps VP6 [19:44:33] <mru> what resolution are those h264 streams? [19:45:09] <hyc> 512x288, 640x360, 720x400 [19:45:26] <mru> should play fine on omap3 [19:45:36] <mru> unless they've used insane encoding settings [19:45:51] <hyc> it's all main profile [19:46:02] <mru> btw, I can double the vp6 decoder speed if you ask nicely [19:46:27] <hyc> oooo, I was just about to ask if anyone has looked at accelerating it [19:46:43] <mru> there's some very low-hanging fruit there [19:47:09] <hyc> but if we can use the H264 streams, they look better anyway [19:47:17] <mru> no doubt [19:49:37] <hyc> still I imagine there are other sites still using VP6. worth doing? [19:50:01] <mru> I didn't think anyone still used it [19:50:42] <hyc> I guess it's only leftover on hulu at this point [19:51:03] <hyc> for some of the really old shows on hulu they also have 640x360 700kbps vp6 [19:51:25] <Dark_Shikari> vp6 is only really slow if you keep the postprocessors [19:51:45] <hyc> but most of the new shows are 3 H264 streams and the 512x288 vp6 [19:58:47] <hyc> so aside from my screwup in that aviobuf.c patch, the rtmp seek patch is OK to commit [19:59:00] <hyc> no one has said anything about the rtmp logging patch [20:23:59] <CIA-81> ffmpeg: stefano * r22860 /trunk/libavcodec/ (eval.c eval.h): (log message trimmed) [20:23:59] <CIA-81> ffmpeg: Fix constness for func[12] parameters in ff_parse_expr() and [20:23:59] <CIA-81> ffmpeg: ff_parse_and_eval_expr(). [20:23:59] <CIA-81> ffmpeg: Change func[12] attributes from "** func" to "* const * func". [20:23:59] <CIA-81> ffmpeg: This is consistent with the semantics of the provided arrays of [20:23:59] <CIA-81> ffmpeg: functions, which are not supposed to be changed by the ff_parse_* [20:24:00] <CIA-81> ffmpeg: functions. [20:31:39] <mru> latest patches make dca 3.9x faster than when I started [20:31:46] <mru> on cortex-a8 [20:32:23] <Dark_Shikari> why do we care about dca on cortex [20:32:35] <mru> someone with money does [20:34:04] <hyc> what's dca? :P [20:34:16] <mru> dts without trademark [20:38:41] <merbanan> hyc: dts coherent acoustics [20:40:58] <Dark_Shikari> mru: another secret contract? [20:46:22] <CIA-81> ffmpeg: mru * r22861 /trunk/libavcodec/ (dcadsp.h dca.c Makefile dcadsp.c): [20:46:22] <CIA-81> ffmpeg: DCA: break out lfe_interpolation_fir() inner loops to a function [20:46:22] <CIA-81> ffmpeg: This enables SIMD optimisations of this function. [20:46:23] <CIA-81> ffmpeg: mru * r22862 /trunk/libavcodec/dcadata.h: DCA: 16-byte-align lfe_fir tables [20:46:23] <CIA-81> ffmpeg: mru * r22863 /trunk/libavcodec/ (5 files in 2 dirs): DCA: ARM/NEON optimised lfe_fir [20:49:12] <hyc> (thx for info) [20:55:49] <DonDiego> moin [20:59:42] <DonDiego> mru: what's with all those extra cflags you pass to the fate boxes? [20:59:59] <mru> which ones? [21:00:11] <DonDiego> --target-os=linux --arch=arm --cpu=cortex-a8 --extra-cflags='-mfpu=neon -mfloat-abi=softfp' [21:00:15] <DonDiego> for example [21:00:23] <DonDiego> this is necessary for the crosscompiler? [21:00:31] <mru> those cflags are required for that compiler to do the right thing [21:00:43] <DonDiego> yes, i expected that [21:00:52] <DonDiego> my question is: [21:00:54] <mru> it will still do _something_ without them [21:00:58] <mru> so they can't be detected [21:01:07] <DonDiego> should that stuff be in configure and/or the docs? [21:01:31] <mru> people who don't know what to pass have no business building ffmpeg [21:01:38] <mru> they'll screw up much worse elsewhere anyway [21:01:46] <DonDiego> :) [21:01:57] <DonDiego> now ease up and answer my question [21:02:20] <mru> I don't think duplicating half the arm and gcc manuals is a good idea [21:02:20] <DonDiego> i have almost all the rest nailed and documented now [21:02:41] <DonDiego> ok, so it's supposed to be common knowledge? [21:02:55] <mru> you'd better know what ABI you want to build for before building [21:04:08] <mru> trying to enumerate all valid combinations and when to use them is pointless [21:04:16] <mru> you should know your hardware [21:04:19] <DonDiego> --extra-ldflags=-Tbss=0x2000000 [21:04:29] <DonDiego> that's from the blackfin box [21:04:30] <mru> that's a dirty hack [21:04:45] <mru> it'll build without it too [21:04:49] <mru> and run [21:05:20] <mru> that's just to help a bit with memory fragmentation [21:05:32] <DonDiego> so no need to document it? [21:05:39] <mru> no [21:05:44] <DonDiego> ok [21:05:47] <mru> it needs a kernel hack to work too [21:05:55] * DonDiego scratches another box from the list [21:06:08] <mru> and my special malloc lib [21:06:22] <DonDiego> ok, then there's the m32/m64 issue [21:06:29] <DonDiego> lots of fate boxes pass either flag [21:06:47] <DonDiego> why is that? [21:06:50] <mru> I guess that's to switch the compiler from whatever its default is [21:07:01] <mru> iirc gcc on osx is -m32 by default [21:07:08] <mru> linux is usually -m64 by default [21:08:05] <DonDiego> yeah, but it seems weird to me [21:08:14] <mru> tell that to steve jobs [21:08:25] <DonDiego> oh, it's not just used on os x.. [21:08:44] <DonDiego> http://fate.multimedia.cx/index.php?build_record=205613 [21:08:47] <DonDiego> gcc on linux [21:08:50] <mru> well, how did you expect to choose something other than the default? [21:09:13] <DonDiego> why is there a need to deviate from the default i wonder [21:09:14] <mru> that's doing a 32-bit build on a 64-bit machine [21:09:43] <mru> it makes sense for 64-bit to be the default on a 64-bit machine [21:09:54] <DonDiego> where do you see it's a 64 bit machine? [21:09:59] <mru> I assume it is [21:10:13] <pJok> os x is 32bit kernel with 64bit userland afair [21:10:15] <mru> and the /fate64 path suggests it is [21:10:25] <DonDiego> let me doublecheck.. [21:10:42] <mru> pJok: that's not possible [21:10:47] <astrange> it is possible [21:10:51] <mru> wtf? [21:10:52] <pJok> mru, of course it is [21:10:55] <astrange> that's what it does [21:11:06] <mru> how the fuck do you run a 64-bit userland on a 32-bit kernel? [21:11:14] <pJok> ask apple [21:11:21] <astrange> by caring really hard about driver compatibility [21:11:24] <hyc> lol [21:11:36] <mru> normal systems often do the opposite [21:11:45] <mru> especially on ppc and mips [21:11:53] <hyc> nope, not possible. unless you restrict the entire machine to less than 4GB of memory [21:11:59] <mru> that's what I thought [21:12:04] <pJok> can't see why 32bit kernel and 64bit userland shouldn't work [21:12:14] <hyc> it could work but it would be stupid [21:12:18] <pJok> hyc, virtual memory cures that anyways [21:12:22] <astrange> it works with more than 4gb [21:12:23] <hyc> no it doesn't [21:12:29] <astrange> http://www.google.com/patents/about?id=DumnAAAAEBAJ [21:12:29] <mru> how will a 32-bit kernel cope with userspace passing 64-bit pointers in syscalls? [21:12:34] <hyc> exactly [21:13:09] <astrange> it constantly remaps part of the kernel space [21:13:16] <astrange> wastes a lot of tlb misses but it works [21:13:23] <mru> eh, that won't help you [21:13:28] <astrange> 64-bit kernel is much faster on (some) supported systems [21:13:39] <mru> a 32-bit kernel _has no concept_ of 64-bit pointers [21:13:39] <peloverde> It uses PAE, no? [21:13:48] <mru> PAE is something different entirely [21:13:58] * pJok has no idea how apple did it [21:14:03] <pJok> and i find the idea stupid [21:14:03] <mru> PAE is 40-bit (iirc) physical addresses [21:14:08] <pJok> but it works, aparantly [21:14:08] <mru> mapped into 32-bit virtual [21:14:27] <hyc> PAE is only 36 bit [21:14:35] <mru> right, it was tiny [21:14:41] <hyc> any way you slice it, cannot handle 64 bit pointers [21:14:54] <peloverde> PAE is 52-bits [21:15:05] <mru> I doubt that [21:15:18] <mru> I've never heard of _any_ machine with 52-bit physical [21:15:32] <mru> they usually top out around 48 [21:15:35] <hyc> right, current x86s top out at 40 bits [21:15:45] <peloverde> http://support.amd.com/us/Processor_TechDocs/24593.pdf [21:15:53] <Dark_Shikari> mru: ppc [21:16:06] <mru> I doubt that [21:16:14] <mru> why would you have that many address bits? [21:16:22] <Dark_Shikari> ppc32 has a 52-bit address space [21:16:28] <Dark_Shikari> It's actually rather amusing [21:16:34] <mru> that's crazy [21:16:46] <pJok> wiki says PAE is UP TO 52bit [21:16:49] <mru> which ppc32 btw? [21:17:06] <Dark_Shikari> all, I think [21:17:16] <mru> pJok: oh, maybe the register format can handle it [21:17:23] <Dark_Shikari> it's a "virtual address space" technically [21:17:26] <Dark_Shikari> but it acts like a physical one [21:17:38] <hyc> peloverde: the AMD doc says up to 52 bits may be supported, current AMD64 arch supports 40. [21:17:40] <mru> wtf does that mean? [21:17:50] <mru> Dark_Shikari: ^^ [21:17:54] <pJok> "x86 processor hardware architecture is augmented with additional address lines used to select the additional memory, so physical address size is increased from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB. The 32-bit size of the virtual address is not changed, so regular application software continues to use instructions with 32-bit addresses and (in a flat memory model) is limited to [21:18:03] <pJok> dunno how much of that got cut off [21:18:08] <Dark_Shikari> mru: ok, if I recall correctly, here's how it works [21:18:12] <mru> I know how x86 pae works [21:18:18] <Dark_Shikari> the top 4 bits of each 32-bit address is a segment identifier [21:18:21] <mru> wider physical than virtual, simple [21:18:29] <Dark_Shikari> this maps to a list of 16 segments (like a mini page table) [21:18:37] <Dark_Shikari> each segment maps to a list of pages for that segment [21:18:41] <Dark_Shikari> the pages are in a 52-bit virtual address space [21:19:00] <hyc> none of this matters. 64 bit userland uses 64 bit flat pointers. [21:19:54] <DonDiego> --cc='ccache suncc' --extra-cflags=-Wa,-a32 [21:20:02] <DonDiego> what weird stuff is that? [21:20:03] <peloverde> then limit each process to 4GB? [21:20:07] <mru> someone wants to use ccache, normal stuff [21:20:13] <mru> don't know about the -a32 [21:20:44] <pJok> "Mac OS X for Intel Macs supports PAE and the NX bit on all CPUs supported by Apple (from 10.4.4, the first Intel release, onwards). Mac Pro and Xserve systems can currently support 32 GB of RAM, even though the Mac OS X 10.5 Leopard kernel remains 32-bit. The Mac OS X 10.6 Snow Leopard kernel can optionally run in 64-bit on certain systems.[6]" [21:21:22] <DonDiego> i meant the -Wa,-a32 [21:21:36] <hyc> so, 10.6 is a 64 bit kernel [21:21:54] <hyc> and 10.5 was pure 32 bit [21:22:11] <astrange> it's optionally 64 bit but not by default [21:22:23] <mru> then 64-bit userland is optional too [21:22:24] <astrange> and it's invisible to userland whether it is or not (excepting sysctl) [21:22:55] <mru> they must have a _really_ contorted syscall interface if that's possible [21:22:59] <hyc> it would be fake 64 bit then. 64 bit wide pointers that always contain only 32 bits [21:23:46] <hyc> and they would still have to rearchitect when going to a native 64 bit kernel. yeah, makes no sense [21:23:52] <astrange> i'm running it right now and it works completely normally [21:24:00] <hyc> unless they always used 64 bits in the syscall interface [21:24:03] <astrange> do you not believe that actual running systems work? [21:24:06] <mru> I have yet to see _anything_ normal on a mac [21:24:16] <hyc> sure they work, just not the way you seem to believe [21:24:17] <astrange> and yes, the syscall interface is 64-bit on the user side [21:24:22] <DonDiego> where do i see who maintains each fate box? [21:24:33] <mru> there's a list on the wiki [21:24:35] <astrange> i've been to the wwdc kernel session about this [21:24:42] <siretart> greetings from Paris! [21:25:01] <mru> siretart: enjoy the expensive beer [21:25:13] <thresh> and lack of taxis [21:25:19] <mru> that too [21:25:23] <mru> crazy city [21:25:36] <siretart> indeed, I can confirm both [21:25:53] <mru> of course, we wouldn't make stuff up, would we? [21:26:06] <siretart> heh [21:27:36] <DonDiego> bah [21:27:54] <DonDiego> i cannot match up fate runs with the machine descriptions on the wiki.. [21:27:56] <DonDiego> *sigh* [21:28:54] <DonDiego> how can i tell which one is testing suncc? [21:29:32] <pJok> http://www.appleinsider.com/articles/08/08/26/road_to_mac_os_x_10_6_snow_le… [21:29:53] <pJok> there's something about tiger running 64bit apps with 32bit kernel [21:30:05] <astrange> that's normal [21:30:11] <astrange> snowleopard/10.6 is the only one that does new stuff [21:30:27] <astrange> er, i read that backwards [21:30:48] <pJok> http://images.appleinsider.com/road-to-sl-080826-3.gif [21:32:23] <pJok> mru, thats where you have the 32bit kernel/64bit userland [21:33:43] <hyc> ok. it's a 64-bit clean syscall interface [21:33:49] <hyc> but a 32 bit kernel with PAE [21:34:08] <hyc> that would explain one reason why their kernel was so slow [21:34:30] <astrange> xnu is slow all by itself [21:34:54] <astrange> partially because it has 4gb kernel/4gb userland on 32-bit so there's never any situation where it can do fast kernel<>userland copies [21:35:18] <astrange> ...except with x86-64 kernel and userland [21:36:18] <DonDiego> Build string: 'rm -rf /home/mik/src/fate/build && mkdir -p /home/mik/src/fate/build/tmp && cd /home/mik/src/fate/build && /home/mik/src/fate/source/configure --cc=gcc-4.4 --disable-stripping --disable-optimizations --extra-cflags='-O3 -fno-omit-frame-pointer' --target-exec='valgrind --leak-check=full --error-exitcode=1 --malloc-fill=0xff --suppressions=/home/mik/src/fate/fate.supp --log-file=/home/mik/src/fate/build/fate-valg [21:36:29] <DonDiego> what weird config is that? [21:37:05] <drv> is that the valgrind one? [21:37:46] <DonDiego> that would explain it.. [21:37:51] <DonDiego> Yuvi: you around? [21:39:06] <drv> http://lists.mplayerhq.hu/pipermail/fate/2010-March/000001.html is the FATE thread about valgrind [21:39:32] <pJok> Still doesn't explain why flash is so slow under os x though... [21:40:32] <hyc> flash is slow on any OS [21:40:52] <astrange> they don't spend any time caring and the netscape plugin api was poorly adapted to os x's double buffered windows [21:40:53] <hyc> it's just poorly written [21:41:10] <astrange> supposedly they're working it out now, but iirc plugin drawing is still based on polling [21:41:12] <Compn> its explained in mike's post on why flash is so slow [21:41:27] <Compn> e.g. overlay crap on top of video [21:41:40] <mru> I can tell you _exactly_ why flash is slow [21:41:40] <Compn> not to mention that its crap... [21:41:43] <pJok> Its certainly slower on my mac which is more powerful than my pa laptop [21:41:45] <mru> IT'S CRAP [21:41:49] <hyc> even without those issues flash would still be slow [21:41:55] <DonDiego> Compn: that does *not* explain it [21:41:56] <mru> the source code is mostly ifdefs [21:41:58] <Compn> ehe [21:41:58] <hyc> it's like trying to write a kernel in BASIC [21:41:59] <pJok> Macbook* [21:42:08] <Compn> can anyone explain why quicktime is so slow? [21:42:09] <Compn> :P [21:42:13] <mru> it's crap [21:42:17] <hyc> lol [21:42:32] <DonDiego> mplayer is 5x faster even with vo_x11, i.e. with color conversion [21:42:33] * drv sends out to get a rubber stamp with "It's crap" on it [21:42:48] <hyc> get extras, I need one ;) [21:42:51] <pJok> At least you can single frame step in quicktime player... [21:43:00] <mru> mplayer is pretty weird, but it's usually quite fast [21:43:06] <mru> when it doesn't crash [21:43:16] <drv> qt player takes about 20-30 seconds to start on windows, fairly pitiful [21:43:47] <j-b> http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/ bye bye theora? [21:44:17] <mru> "multiple sources" have been spouting that stuff for a long time [21:44:31] <hyc> of course they just spent money on theora [21:44:34] <mru> that doesn't look any more credible than the earlier ones [21:44:43] <astrange> can we send someone to i/o to yell at them until they let someone else review the bitstream format? [21:44:54] <pJok> With an older version of itunes, try uninstalling qt and make either work again... [21:44:54] <DonDiego> i/o? [21:45:01] <astrange> the google conference [21:45:23] <DonDiego> what bitstream format are they reviewing? [21:45:32] <astrange> the one in j-b's link [21:46:13] <mru> I'll believe it when I see an official press release from google [21:46:15] <mru> not sooner [21:47:33] <peloverde> not to mention that that vp8 may very well not be the panacea they make it out to be [21:47:43] <mru> of course it's not [21:47:48] <peloverde> And Bilski v Kappos comes back soon [21:47:50] <Yuvi> DonDiego: pong [21:48:07] <DonDiego> Yuvi: ah, good you're around again.. [21:48:11] <DonDiego> Yuvi: seen my mail? [21:48:33] <Yuvi> not yet, I'm still catching up [21:48:40] <BBB> KotH: ping [21:48:57] <DonDiego> Yuvi: you were away? [21:49:15] <Yuvi> yeah, dealing with family stuff across the country [21:49:20] <mru> how are we doing for gsoc btw? [21:49:57] <CIA-81> ffmpeg: stefano * r22864 /trunk/libavcodec/eval.h: Remove stray empty line. [21:49:57] <CIA-81> ffmpeg: stefano * r22865 /trunk/libavcodec/eval.h: Fix grammar: a expression -> an expression. [21:50:55] <BBB> mru: 11 applications, 10 of which are non-spam [21:50:56] <Yuvi> so I unfortunately haven't done anything with ogg/theora [21:51:08] <Yuvi> chained ogg? I'll look at that [21:51:08] <BBB> mru: awaiting qualification task results for them [21:51:32] <BBB> mru: expect ~ 4-8 soc projects [21:52:59] <DonDiego> Yuvi: there were some crashers that Dark_Shikari found with the fuzzer [21:53:13] <DonDiego> do you remember if they could have been exploitable? [21:53:33] <Yuvi> iirc just DoS / overreads [21:53:55] <Yuvi> so probably not [21:54:40] <DonDiego> ok [21:54:51] <DonDiego> will you be around in the next few days? [21:55:03] <Yuvi> yep, I'm back home now [21:55:13] <DonDiego> i'll try to catch you on irc/email then, i'm terribly tired right now.. [21:56:59] <DonDiego> gnite [22:06:09] <CIA-81> ffmpeg: stefano * r22866 /trunk/libavcodec/raw.c: [22:06:09] <CIA-81> ffmpeg: Change ff_raw_pixelFormatTags RGB entries (RGB555, BGR555, RGB565, [22:06:09] <CIA-81> ffmpeg: BGR565, RGB565) to make them specify the tags for the LE variants [22:06:09] <CIA-81> ffmpeg: rather than for the native endian ones. [22:06:09] <CIA-81> ffmpeg: Fix NUT compatibility. [23:07:37] <BBB> Vitor1001: thanks for the comments [23:16:38] <Vitor1001> I hope I didn't said anything meaningless [23:25:44] <BBB> no, quite the contrary, especially the review of that denoise filter was useful, it's still dark-grey magic to me [23:25:51] <BBB> but not completely black anymore, maybe [23:36:05] <Kovensky> ohi Vitor1001 [23:36:18] <Vitor1001> Kovensky: Hi [23:36:37] <Kovensky> does libavfi handle audio filtering already [23:36:46] <Vitor1001> No [23:36:54] <Kovensky> hmm [23:36:58] <Vitor1001> There also much little code wrote during soc [23:37:09] <Kovensky> any idea on what I could read to know how to make an audio filtering system? =p [23:37:24] <Kovensky> gonna do one for x264 for gsoc [23:37:34] <Kovensky> (if they approve me) [23:37:49] <Vitor1001> x264? [23:37:53] <Vitor1001> you mean vlc? [23:38:02] <Kovensky> well, vlc is the org, but the project is for x264 [23:38:16] <mru> hardcore [23:38:42] <j-b> no, vkc is not an org [23:38:46] <Kovensky> it's to support x264's video filtering system and the future --device option [23:38:47] <j-b> VideoLAN is [23:39:06] <Kovensky> x264 randominput --device psp output.mp4 <-- file ready to put on a psp and play [23:39:10] * Vitor1001 thinks x264 is trying to reinvent ffmpeg [23:39:12] <Kovensky> well, -o output.mp4 [23:40:07] <Kovensky> perhaps [23:40:11] <Vitor1001> Kovensky: I'd say if you are working in a audio filtering API, focus on the API side [23:40:23] <Vitor1001> That's hard, and it should be done right [23:40:27] <Kovensky> that's what I'm stuck at right now [23:40:37] <Kovensky> I don't know how to handle the passing of packets between filters [23:40:59] <Kovensky> since a filter will request packets from the previous one; and I don't know what unit should be an "audio frame" at the filter level [23:41:15] <Vitor1001> I'd say you will need some ref-counted allocation [23:41:24] <Kovensky> (and how to convert the filter-level audio frame to container-level frame on the demuxer / decoder / encoder / muxer) [23:41:41] <Vitor1001> I'd say anything... There is no restriction you can put that will be uniform across filters [23:42:33] <Kovensky> an idea I had was 1 frame = 1 sample, since I heard that's what avs uses [23:42:38] <Vitor1001> I'd say a filtering framework would get some arbitrarily sized packet as input and output an arbitrarily sized (of a possibly different size) packet [23:42:40] <Kovensky> but then I get stuck at the demuxing level thing [23:42:52] <Vitor1001> 1 sample?? [23:43:03] <Vitor1001> You mean 2 bytes for signed 16-bit? [23:43:13] <Kovensky> 4 bytes for 2ch s16le, etc [23:43:21] <Vitor1001> Thats _way_ inefficient [23:43:32] <Kovensky> a filter wouldn't request an individual frame, it'd request ranges [23:44:28] <Vitor1001> what do you mean a range? [23:44:42] <Vitor1001> More precisely, what would mean the start of the range? [23:45:02] <Vitor1001> You mean it request a number of samples? [23:45:29] <Kovensky> yes [23:46:02] <Kovensky> encoder wants to encode a frame, requests (encoder's frame size) samples to previous filter, and it cascades down to the decoder [23:46:53] <Vitor1001> Looks good [23:47:08] <Kovensky> but then I get stuck at 1) how does the muxer make the request to the encoder, and 2) how does the decoder make the request to the demuxer [23:47:14] <Vitor1001> but there should be a way to avoid duplicating some caching in each filter [23:47:29] <Kovensky> I thought about having a cache filter between each one, but that might be too heavy weight [23:48:08] <Vitor1001> You have to cache only after the filters that cannot output some arbitrary sizes [23:48:45] <Vitor1001> Gluing it up to x264 is a different problem [23:48:47] <Kovensky> also, I not always have control over the demuxing; since for example on x264's lavf demuxer, the video reader reads packets until it gets one it likes; so I'd have to make it a bastard audio demuxer that pushes packets to a queue as it finds them [23:49:06] <Vitor1001> if the library is supposed to be self-contained, it should not dictate too much its design. [23:49:40] <Kovensky> I think I can make it self-contained, at least that's what I'm doing for now (to simplify testing) [23:49:48] <Vitor1001> And you should make a decision. [23:49:59] <Kovensky> which decision [23:50:05] <Vitor1001> Will you support "delay=1h" filter? [23:50:18] <Vitor1001> (which would delay the audio 1 hour)? [23:50:44] <Kovensky> that's a weird filter [23:50:59] <Vitor1001> I know. [23:51:00] <Kovensky> it could work by rewriting requested timestamps and returning silence when needed [23:51:19] <Vitor1001> Yes, but it will need either: [23:51:27] <Vitor1001> 1- Buffer one hour of audio [23:51:40] <Vitor1001> 2- Seek back everytime it need a audio frame [23:52:03] <Vitor1001> I would suggest you not try to do this kind of thing in a first audio filtering framework [23:52:11] <Kovensky> indeed... [23:52:34] <Kovensky> I know for sure I can't seek back because input from libavformat is not guaranteed to be a regular file [23:53:04] <Vitor1001> Buffering an hour of raw audio to RAM is also not a good idea [23:53:24] <mru> ram is cheap :-) [23:53:35] <Kovensky> when I know that a file is a regular file (like when the ffms2 demuxer is used on x264), I don't bother dealing with ffms; I just make the audio-specific lavf demuxer open the file again [23:53:42] * Vitor1001 invites mru to do the same with video ;) [23:54:03] <mru> I'm not _that_ rich... [23:54:05] <Kovensky> then it doesn't need seeking or buffering; but I guess that counts as a seek for the HDD =p [23:54:34] <Kovensky> well, be back soon; dinner [23:55:59] <Vitor1001> Kovensky: My point is that in a first time, it would be better to suppose your filtering framework can ignore these problematic cases... [23:56:56] <Vitor1001> Am I the only one bothered about the effort duplication between ffmpeg and x264? [23:58:24] <SmkMnstr> what about about openmax [23:58:33] <mru> lol [23:58:45] <mru> openmax is _multiplication_ of effort

1 0

IRC log for 2010-04-11
by irc＠mansr.com 12 Apr '10

12 Apr '10

[00:44:26] <CIA-81> ffmpeg: michael * r22831 /trunk/libavformat/utils.c: [00:44:26] <CIA-81> ffmpeg: Raise needed score for codec probing in CODEC_ID_PROBE before the last packet. [00:44:26] <CIA-81> ffmpeg: Fixes issue1871 [06:16:08] <siretart> Dark_Shikari: hi [06:18:15] <Dark_Shikari> siretart: we're considering dropping gpac in x264 for lavf [06:18:19] <Dark_Shikari> because gpac sucks and is annoying to package/compile [06:18:29] <Dark_Shikari> any opinion on this from an ubuntu/deb standpoint? [06:33:02] <siretart> Dark_Shikari: lucid's lavf is too old, so this is maverick stuff anyways [06:33:16] <Dark_Shikari> I mean in the future. [06:33:20] <Dark_Shikari> I don't mean for this release. [06:33:56] <siretart> ah, I see. no, I don't have concerns. one build dep less to care for. yay :-) [06:34:03] <superdump> do we have an ffmpeg ppa? [06:34:21] <superdump> or is that still on the todo? [06:34:34] <kshishkov> ppa? [06:34:37] <siretart> superdump: we could use the motumedia ppa. I've been using it for ffmpeg packages in the past [06:34:58] <siretart> kshishkov: package archives with autobuilders for ubuntu [06:35:05] <kshishkov> bleh [06:35:16] <kshishkov> port description file anyone? [06:36:52] <jai> bsd? macports? [06:37:16] <kshishkov> yep, whatever [06:37:21] <Dark_Shikari> siretart: oh yeah, and did we ever get an answer on what to do about ffms? [06:37:42] * kshishkov has not used FFmpeg in distros since 0.4.5 [06:39:22] * kshishkov also curses for he finds no obvious way to force "xmmword" declaration in IDA where appropriate [07:04:16] <superdump> mru: http://wss.co.uk/pinknoise/theorarm/ <--- maybe you should get some money from google for optimising ffmpeg's theora decoder and whooping its ass...? [07:04:38] <kshishkov> superdump: read log from yesterday [07:04:56] <Dark_Shikari> yay for reinventing the wheel eh [07:05:07] <Yuvi> ffmpeg's already 10% faster than that (except maybe on armv5 and older) [07:05:30] <Dark_Shikari> do a blog post about it or something [07:06:00] <Yuvi> plus it's a pain in the ass to compile, the half-assed build system doesn't actually work [07:07:22] <Dark_Shikari> also, superdump, MSU sent out the drafts of their 2010 benchmarks [07:07:31] <superdump> yeah, seen that [07:07:49] <Dark_Shikari> it's a bit embarassing how many h264 encoders are barely beating xvid [07:09:32] <kshishkov> someone should try at least comparing VP family [07:09:42] <kierank> speaking of encoders which are worse than xvid, was dicas in the msu test? [07:09:46] <Dark_Shikari> no [07:09:48] <Dark_Shikari> not this year [07:10:04] <Dark_Shikari> go read the pdf [07:10:11] <kierank> wanted to save themselves the embarassment [07:10:25] <Dark_Shikari> they benched various others even though companies told them not to [07:10:26] <Dark_Shikari> e.g. divx [07:11:06] <superdump> Dark_Shikari: you said it used the last release of theora, does that include the thusnelda improvements? [07:11:09] <superdump> i don't recall [07:11:10] <Dark_Shikari> yes [07:11:11] <Dark_Shikari> they used 1.1 [07:11:16] <superdump> oh dear... [07:11:27] <Dark_Shikari> now, notably, there are two things to consider [07:11:35] <Dark_Shikari> 1) the Ironman test is completely screwed because their decoder ignored the "offset" [07:11:38] <Dark_Shikari> 1080p is encoded at an offset of 4 [07:11:41] <Dark_Shikari> i.e. croptop = 4 [07:11:56] <Dark_Shikari> 2) Their "high speed" encodes used -speedlevel 2, aka no motion estimation [07:12:01] <Dark_Shikari> because theora was slow as balls [07:12:12] <Dark_Shikari> But even if you ignore both of these, it still gets utterly thrashed. [07:12:23] <Dark_Shikari> I told them about 1), hopefully they will fix it. [07:16:01] <superdump> Bitrate/Quality. Usage area “Movies”, “Ice Age” sequence, [07:16:03] <superdump> “High Speed” preset, Y-PSNR [07:16:17] <superdump> mainconcept actually matches x264 [07:16:19] <superdump> hehe [07:16:45] <Dark_Shikari> in PSNR [07:16:47] <superdump> Dark_Shikari: omg, your point 2) is hideous [07:16:49] <Dark_Shikari> x264 is set to optimize for SSIM [07:16:50] <superdump> yeah, i know :) [07:17:01] <Dark_Shikari> Now, the single most interesting result from their tests [07:17:07] <Dark_Shikari> is the Amazon graph. [07:17:18] <Dark_Shikari> x264 _massacres_ everything else at high bitrates by 2db psnr or more. [07:17:21] <Dark_Shikari> This makes no sense. [07:17:23] <Dark_Shikari> x264 is optimizing for SSIM. [07:17:34] <Dark_Shikari> And its advantage increases with bitrate very rapidly [07:17:42] <Dark_Shikari> This makes me suspect something weird is going on. Maybe it's MB-tree. [07:18:13] <kierank> They should also correct the first page so that theora matches xvid since xvid says: "XviD (MPEG-4 ASP codec) " but theora just says "Theora" [07:19:03] <kshishkov> kierank: but it's just Theora, nothing to add [07:19:38] <kierank> It's called the "MPEG-4 AVC video codecs comparison" [07:19:47] <kierank> so maybe they should clarify [07:25:05] <siretart> Dark_Shikari: what about ffms? AFAIUI, it needs packaging, or is there any other open issue? [07:25:41] <Dark_Shikari> siretart: just that [07:25:44] <Dark_Shikari> it needs packaging [07:25:48] <Dark_Shikari> btw, they switched from cmake to autoconf [07:25:52] <Dark_Shikari> might make things easier [07:27:01] <kshishkov> I never knew you'd praise autoconf like that [07:27:13] <Dark_Shikari> given how awful the cmake build system was... [07:28:42] <Dark_Shikari> hmm. within the next month we're going to be announcing official x264 blu-ray support and releasing a free demo blu-ray image. [07:28:55] <Dark_Shikari> what's the best way to get this kind of thing promoted? [07:29:08] <kshishkov> add AACS support ;) [07:29:10] <Dark_Shikari> lol [07:29:18] <Dark_Shikari> it'll be a DVD-size, unencrypted blu-ray [07:29:36] <Dark_Shikari> with 3 free full HD short films from lossless source [07:29:44] <Dark_Shikari> I imagine you can figure out what two of them are. [07:31:02] <Dark_Shikari> guess we'll want to submit it to digg, /. , etc. [07:31:25] <kshishkov> you'd better make several labels for them, like "Enterprise quality from free product", "Advanced format made purely with opensource apps" and "From Touhou fans to Touhou fans" [07:31:38] <Dark_Shikari> lol [07:31:45] <kshishkov> that should cover ~90% of your target audience [07:31:52] <Dark_Shikari> it doesn't contain any touhou [07:32:14] * Dark_Shikari even created a cool little x264 title bumper http://mirror05.x264.nl/Dark/intro.mkv [07:32:23] <superdump> Dark_Shikari: an interesting note that theora is included in the expections list for the settings used bein recommended by the developers [07:32:34] <Dark_Shikari> no it isn't [07:32:41] <Dark_Shikari> it's in the list of settings _not_ recommended by devs [07:33:15] <siretart> Dark_Shikari: it is still on my todo list, unfortunately, there are higher priority items :-( [07:43:05] <superdump> Dark_Shikari: that's what i meant [07:43:14] <Dark_Shikari> oh k [07:43:24] <superdump> i just wrote it badly (distracted) :) [11:48:20] <CIA-81> ffmpeg: stefano * r22832 /trunk/libavcodec/eval.h: [11:48:20] <CIA-81> ffmpeg: Move AVEvalExpr declaration at the beginning of the file, where it is [11:48:20] <CIA-81> ffmpeg: less distracting. [11:48:20] <CIA-81> ffmpeg: stefano * r22833 /trunk/libavcodec/ (ratecontrol.h eval.c eval.h): [11:48:20] <CIA-81> ffmpeg: Rename AVEvalExpr to AVExpr, as suggested by Michael. [11:48:21] <CIA-81> ffmpeg: The new name is shorter and less confusing. [11:48:22] <CIA-81> ffmpeg: stefano * r22834 /trunk/libavcodec/ (eval.c eval.h ratecontrol.c): Rename ff_eval_free() to ff_free_expr(). [11:54:25] <blez> how can I export the error strings of ffmpeg [11:54:33] <blez> and separate them into critical and not [12:14:06] <pentanol> blez in a maling lists [12:16:28] <blez> maling lists? [12:22:19] <CIA-81> ffmpeg: cehoyos * r22835 /trunk/libavformat/flvdec.c: [12:22:19] <CIA-81> ffmpeg: Set audio bit rate. [12:22:19] <CIA-81> ffmpeg: Patch by Howard Chu, hyc highlandsun com [12:28:01] <Compn> blez : probably you want to ask that question in the libav-users mailing list [12:44:46] <mru> lol@dilbert: "we're using the law to keep justice away" [14:10:14] <CIA-81> ffmpeg: stefano * r22836 /trunk/libavcodec/imgconvert.c: [14:10:14] <CIA-81> ffmpeg: Make ff_fill_linesize() use the information stored in [14:10:14] <CIA-81> ffmpeg: av_pix_fmt_descriptors. [14:10:14] <CIA-81> ffmpeg: Allow simplification and a more generic implementation. [14:16:44] <CIA-81> ffmpeg: stefano * r22837 /trunk/libavcodec/eval.h: Doxument ff_free_expr(). [14:51:11] <kshishkov> wbs: http://translate.google.com/#auto|en|Styrmansgatan [14:55:47] <pJok> o_O [14:58:17] <jai> en != fi last i checked [15:00:31] <wbs> kshishkov: yeah, i think you've shown it before. quite fantastic, and a good example of the drawbacks in the google translate method :-) [15:42:35] <j-b> good moroning [15:42:45] <mru> morning j-b [15:43:03] <kshishkov> is that standard VLC greeting now? [15:43:27] <mru> ffmpeg dominates in subtle ways [15:44:08] <j-b> kshishkov: I don't remember who introduced that to the channel, but yeah ;) [15:44:14] <kshishkov> nope, the other person who uses it is also realted to VLC and (almost) no FFmpeg work [15:44:19] <kshishkov> j-b: thresh [15:44:36] <j-b> kshishkov: very likely :) [15:47:00] <_av500_> bonjour j-b [15:47:07] <_av500_> err, bonojour [15:47:52] <kshishkov> boneaujour then ;) [15:49:17] <jai> mru: http://pastie.org/914194 [15:49:20] <jai> merbzt: ^ [15:50:27] <BBB> anyone have suggestions on how to test my qcelp postfilter? [15:50:40] <BBB> as in, does anyone know of a good qcelp encoder I could use? [15:50:44] <mru> jai: please commit [15:50:47] <mru> it's correct [15:50:55] <mru> I simply forgot to do it [15:51:05] <kshishkov> fine with me and I'm DCA maintainer [15:51:45] <_av500_> kshishkov: i follow simple rule to add o after 3 chars [15:52:17] <BBB> helolo? [15:52:28] <kshishkov> _av500_: don't you know how French write "o" in their words? [15:52:55] <BBB> j-b: we should talk about doing interesting things with money [15:53:04] <BBB> j-b: how about some shared bounties? [15:53:48] <j-b> BBB: agreed. [15:53:56] <mru> giving it to me is interesting... [15:54:20] <kshishkov> mru: you have no interest in petty cash [15:54:20] <BBB> mru: how about beating theoraarm (as proposed by google) by making our theora better than theirs on arm? [15:54:39] <j-b> and be LGPL [15:54:44] <BBB> mru: you could do that [15:54:54] <BBB> yes, lgpl please [15:54:58] <jai> mru: done [15:55:12] <j-b> is merbzt around? [15:55:14] <jai> kshishkov: ah, i must've forgotten :| [15:55:34] <CIA-81> ffmpeg: jai_menon * r22838 /trunk/libavcodec/dcadata.h: DECLARE_ALIGNED usage requires #inclusion of 'mem.h'. [15:58:18] <BBB> j-b: it says here theorarm is bsd now (?) [15:58:36] <j-b> did it change? [15:58:38] <BBB> yeah [15:58:53] <j-b> ok [15:59:14] <j-b> that is why they paid, I guess [15:59:28] <BBB> still, this libXYZ thing is like a disease, better put it all in ffmpeg [15:59:44] <BBB> worst thing is, theorarm isn't part of xiph's libtheora :) [15:59:48] <kshishkov> BBB: thanks for our next motto [16:01:37] <BBB> my pleasure [16:24:46] <j-b> how many applications do you have for SoC? [16:25:37] <BBB> 11, but one of them is probably spam [16:25:45] <BBB> I'm saying probably because if it is, it's quite good spam [16:25:50] <BBB> so 10 realistically [16:26:11] <BBB> kshishkov: can you apply as mentor? someone wants to do vc-1 interlaced [16:27:37] <BBB> j-b: what about you? [16:27:39] <kshishkov> I don't know how well it will go for me, so just use some sitz-mentor and I'll lend my hoof [16:29:44] <j-b> BBB: 48 [16:29:54] <BBB> holy shit [16:30:06] <BBB> kshishkov: I need you to talk to the student and make sure he's capable [16:30:25] <j-b> BBB: we had 85 last year. [16:31:00] <jai> BBB: tell him to come to IRC [16:31:03] <jai> :) [16:32:08] <j-b> BBB: so 11 applications, how many slots do you want? [16:32:33] <kshishkov> ten, obviously [16:32:42] <jai> heh [16:33:33] <kshishkov> VLC ideas seems to be extremely simple compared to FFmpeg [16:33:38] <j-b> indeed, they are. [16:33:52] <jai> next time we should bait students with tasks like "cloud support for libavdevice" or something [16:33:55] <kshishkov> how many people applied to x264 part though? [16:34:08] * elenril wonders wtf is firefox trying to read ~/.lockmail [16:34:12] <jai> a lot of people would apply if the buzzword count is just right [16:34:12] <j-b> kshishkov: 8 [16:34:25] <j-b> jai: almost noone applied for the cloud one [16:34:35] <thresh> that was a bad buzzword then [16:34:38] <jai> j-b: heh, i would have bet otherwise :) [16:34:49] <j-b> thresh: yeah, I need a new one for next year [16:35:03] <j-b> thresh: somehting with 'Utlra-HD' in it [16:35:09] <j-b> 'Ultra-HD' [16:35:12] <_av500_> j-b: next year, recode it in objective c [16:35:22] <j-b> _av500_: ;) [16:35:38] <jai> "python bindings for ffmpeg" :) [16:35:49] <elenril> that would be pretty cool actually [16:35:54] <jai> :o [16:37:05] <jai> hmm, actually that might even work [16:37:32] <BBB> I think we should wrap ffmpeg into a libffmpeg [16:37:40] <BBB> and then make applications use that instead of ffmpeg [16:37:43] <BBB> great soc project [16:37:58] <BBB> libffmpeg could also wrap libtheora and libvorbis and librtmp, so we can remove that from ffmpeg proper [16:38:02] <BBB> we'll call it a "framework" [16:38:11] <jai> with ctypes, it should work on windows too [16:38:17] <BBB> excellent idea! [16:38:24] <BBB> in fact, it could wrap directshow and quicktime also [16:38:30] <BBB> I think that's an amazing idea [16:38:34] <BBB> I shall apply for it next year [16:38:35] <jai> World Domination FTW [16:38:57] <elenril> BBB: isn't that called mplayer? ;) [16:39:25] <BBB> elenril: amongst others, probably [16:40:09] <j-b> gosh, this year SoC WebApplication is shityt [16:40:23] <jai> its been pathetic for quite sometime [16:40:37] <jai> atleast since 2009 [16:41:07] <j-b> from an admin PoV it is the worse shit ever [16:41:33] <j-b> You cannot middle-click from the list of application to open them in a new tab [16:42:20] <jai> weird [16:42:21] <BBB> the lack of email notifications is terrible [16:42:33] <jai> i thought there were email notifications [16:42:40] <BBB> not for admins :( [16:42:47] <jai> ah ok [16:42:49] <BBB> afaics [16:43:03] <BBB> j-b: I'd guess 8 slots would be great, 10 would be better but I'm not counting on it [16:43:14] <BBB> j-b: also, don't forget we want students to pass qualification tasks and only 3 have so far [16:43:29] <BBB> the libavfilter/audio guy is at least working on it, so that'd be 4 [16:43:34] <BBB> but I haven't heard from the others yet [16:44:51] <jai> is he doing the task for ffmpeg or videolan? [16:45:16] <_av500_> j-b: ack, the web app sucks [16:45:32] <_av500_> it open in sep tab once it is not a "new" proposal any more [16:45:55] <_av500_> so. add one comment to each and they all open in new tabs.. [16:45:57] <j-b> BBB: same for us. But we have had many people passing the qualification, this year [16:46:46] <j-b> BBB: especially, since we have applications from developers of ffmpeg, xmms2, lives this year... [16:47:15] <BBB> ffmpeg? hmm... who? :) [16:47:27] <BBB> btw, is fedora shipping vlc? [16:47:42] <j-b> BBB: ffmpeg? I won't tell :) [16:47:53] <BBB> maybe he applied to us as well ;) [16:48:13] <BBB> or was it kshishkov? :) [16:48:43] <j-b> BBB: fedora are just plain assholes, but we are discussing with them... [16:49:03] <BBB> I'd like to discuss that with them as well... I mean, I can't believe theyr [16:49:03] <BBB> e [16:49:22] <BBB> they're excluding one of the most popular freesoftware projects for fear of the P-word [16:49:32] <BBB> thye could ship a crippled version [16:55:44] <kshishkov> BBB: you're right, I've equally refused to be VLC GSoC mentor and/or student as well. Not that anybody has asked me... [17:24:53] <merbanan> what am I missing ? [17:27:24] <kshishkov> nothing serious I think [17:28:29] <merbanan> debian issue or ? [17:29:19] * kshishkov may have missed more than morebananas [18:45:42] <CIA-81> ffmpeg: stefano * r22839 /trunk/libavcodec/ (eval.c eval.h): [18:45:42] <CIA-81> ffmpeg: Avoid the use of the symbol ff_expr_s for referencing AVExpr. [18:45:42] <CIA-81> ffmpeg: This way we have to deal only with struct AVExpr and AVExpr, which is [18:45:42] <CIA-81> ffmpeg: slightly less confusing as the association between the two symbols is [18:45:42] <CIA-81> ffmpeg: obvious. [19:26:10] <SmkMnstr> i want libavcodec/libavformat for win32, osx, linux, and angstrom [19:26:57] <SmkMnstr> i guess ill try to massage a ffmpeg dist that works for all and then rarely upgrade [19:33:56] <mru> those are all supported targets [19:35:36] <Kovensky> angstrom? o_O [19:38:11] <mru> that's just linux [19:38:21] <mru> it has fairly up to date ffmpeg packages [19:39:21] <Dark_Shikari> that's like [19:39:24] <Dark_Shikari> "windows, osx, linux, and ubuntu" [19:39:38] <Dark_Shikari> "rocky planets, gas giants, and mars" [19:39:45] <Dark_Shikari> http://tvtropes.org/pmwiki/pmwiki.php/Main/AndZoidberg [20:05:17] <CIA-81> ffmpeg: stefano * r22840 /trunk/libavcodec/ (eval.c eval.h): [20:05:17] <CIA-81> ffmpeg: Remove redundant file descriptions from copyright headers. [20:05:17] <CIA-81> ffmpeg: File description is only kept in the @file doxy. [20:05:17] <CIA-81> ffmpeg: stefano * r22841 /trunk/libavcodec/eval.h: [20:05:17] <CIA-81> ffmpeg: Place some empty line in the doxy. [20:05:18] <CIA-81> ffmpeg: Improve readability, also consistent with the predominant doxy style. [20:06:44] <_av500_> Dark_Shikari: win, osx, linux x86 and linux arm :) [20:13:28] <SmkMnstr> on angstrom/ARM the NEON and C64x+ implementations are very important [20:13:30] <SmkMnstr> but i just found out it will be open embedded and not angstrom :) [20:13:44] <SmkMnstr> now im determining what all libs will be needed under windows [20:13:46] <mru> angstrom is a special case of open embedded [20:14:19] <mru> ~curse gcc [20:14:41] <mru> it doesn't realise it gets a/b and a%b at the same time [20:14:47] <Dark_Shikari> lol [20:14:57] <SmkMnstr> if this invovlves having a locale directory im going to be upset [20:15:01] <mru> nothing a little asm can't fix :-) [20:15:52] <Kovensky> * @diakopter helped build an actual bikeshed, 13 years ago. [20:15:52] <Kovensky> <masak> what color was it? [20:15:52] <Kovensky> <@diakopter> wood [20:15:52] <Kovensky> <masak> sounds like a Solomonian solution to the whole issue. [20:15:53] <Kovensky> <@diakopter> yeah. those who want to see it a certain color can just wear tinted glasses [20:15:56] <Kovensky> <masak> :) [20:16:07] <Kovensky> TODO: give tinted glasses to each developer in their favorite color [20:16:18] <SmkMnstr> should i try just making visual studio project files for this and porting it? [20:16:21] <Kovensky> :> [20:16:22] * mru wants his rose-coloured [20:16:25] <SmkMnstr> what could be the big diff why it 'dosnt build in windows' [20:16:28] <SmkMnstr> i guess i can find out [20:16:40] <mru> do not touch visual studio [20:16:41] <SmkMnstr> without mingw that is [20:16:44] <SmkMnstr> lol [20:16:44] <mru> we will kill you [20:16:50] <Dark_Shikari> heh, I got CC'd on a discussion about hugepages in linux kernel [20:16:57] <Dark_Shikari> Linus is raging again [20:16:58] <Kovensky> MSVC doesn't compile ffmpeg, and never will [20:17:04] <SmkMnstr> why [20:17:08] <Kovensky> ffmpeg is C99, MSVC only implements C89 and C++ [20:17:15] <Dark_Shikari> SmkMnstr: it doesn't compile the language ffmpeg is written in [20:17:23] <SmkMnstr> oh hrm [20:17:35] <Kovensky> and it only implements the part of C89 that C++ mandates IIRC [20:17:43] <SmkMnstr> ok sorry i read about this earlier heh [20:17:53] <SmkMnstr> it looks like c code to me [20:17:59] <Dark_Shikari> yes, which msvc doesn't support [20:18:01] <Dark_Shikari> it only supports C89 [20:18:07] <Dark_Shikari> a very old version of C [20:18:20] <Dark_Shikari> Simple example of code that won't compile in msvc: [20:18:24] <Dark_Shikari> int i; [20:18:25] <Dark_Shikari> i = 0; [20:18:26] <Dark_Shikari> int x = i; [20:18:50] <SmkMnstr> that will def compile in msvc as c++ [20:18:54] <Dark_Shikari> Yes, but this isn't C++ [20:18:59] <SmkMnstr> could be in my project file [20:19:07] <Dark_Shikari> That would make things harder [20:19:11] <Dark_Shikari> C++ and C disagree on various things. [20:19:22] <Kovensky> the most obvious one is casts to and from void* [20:19:50] <mru> int class; [20:19:52] <mru> int new; [20:19:59] <Dark_Shikari> lol [20:20:04] <Dark_Shikari> +1 [20:20:11] <Kovensky> void *new = &class; [20:20:15] <enkidu> hi there. what about some kind of "garbage collector" for killing probably-dead ffserver connections? [20:20:22] <andoma> typedef struct class new; [20:20:25] <mru> there are some more subtle ones too involving structs [20:20:27] <SmkMnstr> u just have to add a (void*) cast big woop [20:20:40] <mru> (void*) casts are evil [20:20:42] <SmkMnstr> im ignoring the reserved words criticism [20:20:46] <mru> and casts of void* [20:20:57] <Kovensky> also, inline struct initializers [20:21:04] <Kovensky> that's the single most useful C99 feature IMO :P [20:21:14] <mru> designated initialisers? [20:21:16] <mru> .foo = bar [20:21:17] <mru> ? [20:21:18] <Kovensky> yes [20:21:19] <SmkMnstr> void* casts are no worse than void* pointers IMO [20:21:23] <mru> yes they are [20:21:29] <mru> they are POINTLESS [20:21:35] <SmkMnstr> ok slightly worse [20:21:36] <mru> therefor they are evil [20:21:44] <Kovensky> <@mru> they are POINTLESS <-- I see what you did there [20:21:58] <mru> no pun intended [20:22:00] <mru> honest [20:22:08] <SmkMnstr> heh [20:22:10] <Kovensky> heh [20:22:17] <Kovensky> but finding puns is fun :) [20:47:05] <Dark_Shikari> what's the easiest way to do a recursive find and replace on a lot of files? [20:48:32] <mru> explain [20:50:40] <Dark_Shikari> I want to replace one string with another [20:50:41] <Dark_Shikari> across a ton of files [20:51:06] <mru> do you have an easy way of listing the files? [20:51:55] <Dark_Shikari> I guess I don't need recursive [20:52:00] <Dark_Shikari> so in that case while * [20:52:14] <Dark_Shikari> er, for file in * [20:52:15] <mru> perl -pi -e 's/from/to/g' * [20:52:34] <Dark_Shikari> what special characters won't that work with? [20:52:44] <mru> that's a perl regex [20:53:04] <Dark_Shikari> I meant for escaping things in the regex [20:53:15] <mru> as I said, it's a perl regex [20:53:18] <Dark_Shikari> I don't know perl [20:53:20] <mru> standard rules apply [20:53:25] <mru> you should learn perl [20:54:24] <mru> \-escaping anything non-alphanumeric should be safe [21:04:27] <iive> Dark_Shikari: npp can do that. [21:27:00] <CIA-81> ffmpeg: stefano * r22842 /trunk/libavfilter/avfiltergraph.h: Apply grammar/consistency nits to avfilter_graph_add_filter() doxy. [21:32:10] <SmkMnstr> got it building it windows :), now to integrate with my opengl app [21:45:13] <CIA-81> ffmpeg: stefano * r22843 /trunk/libavformat/ (matroskadec.c internal.h cutils.c avformat.h mpegtsenc.c): Move the internal function declarations in avformat.h to internal.h. [22:10:01] <mru> patches for another 7% faster dca decoding posted [22:21:42] <Compn> nice [22:22:18] <mru> I expect to boost it by another 20% at least [22:23:22] <Compn> do you think google's theorarm project will have any good generic arm optimizations ffmpeg can copy ? [22:23:32] <mru> no [22:29:29] <Yuvi> only thing that might be useful is armv4 vp3 idct, if you care about pre-armv5 that is [22:31:29] <mru> the code is ugly [22:31:32] <mru> ugly code is rarely good [22:31:44] <mru> and it's just base ARM, not even v6 [22:32:25] <mru> or indeed v5 [22:32:32] <Yuvi> there's some usat and uhadd8, but it's all mixed in [22:32:44] <mru> must have missed those [22:32:50] <CIA-81> ffmpeg: stefano * r22844 /trunk/libavcodec/ (eval.c eval.h ratecontrol.c): [22:32:50] <CIA-81> ffmpeg: Rename ff_parse_eval() to ff_eval_expr(). [22:32:50] <CIA-81> ffmpeg: The new name expresses better what the function does. [22:32:50] <CIA-81> ffmpeg: stefano * r22845 /trunk/libavcodec/ (opt.c eval.c eval.h): [22:32:50] <CIA-81> ffmpeg: Rename ff_eval2() to ff_parse_and_eval_expr(). [22:32:51] <CIA-81> ffmpeg: The new name better expresses what the function does. [22:32:58] <Yuvi> neon too [22:33:56] <Yuvi> also, fun fact: apple's gas only accepts lowercase instructions [22:34:13] <mru> omg, that neon code sucks [22:35:28] <Yuvi> have you done any tremor vs. ffmpeg comparisons on a cortex? [22:35:35] <mru> no [22:35:37] <Vitor1001> mru: Is FFmpeg theora decoder is faster on arm than theorARM? [22:35:43] <Yuvi> yes [22:35:52] <mru> how much? [22:36:12] <Yuvi> on a8, around 10% on average [22:36:40] <mru> is that with all your speedups? [22:36:58] <Yuvi> don't think so [22:37:37] <Yuvi> it's been a bit since I tried, theorarm doesn't seem to have improved though [22:38:29] <Compn> oh i thought theorarm was new or something [22:38:40] <mru> nothing new about it [22:38:44] <mru> it's been around for years [22:38:46] * Compn not read blog post correctly [22:38:49] <Compn> ah [22:38:57] <Yuvi> 8 months or so I think [22:39:04] <mru> apparently google paid the author to relicense it or something [22:39:08] <Compn> ahhhh [22:39:13] <mru> why they did that beats me [22:39:16] * Compn not read article at all [22:39:31] <Compn> well [22:39:48] <Compn> cheaper to throw money at a problem than to throw a developer on a problem [22:40:03] <mru> why not use ffmpeg if it's already faster? [22:40:35] <Yuvi> (and they already use ffmpeg for chrome...) [22:40:47] <Yuvi> probably a different part of google payed for it though [22:48:59] <j-b> "Unknown Cook version, report sample!" whom should I report too [22:49:01] <j-b> ? [22:49:30] <peloverde> to samples.mplayerhq.hu of course [22:49:41] <peloverde> and open a bug [22:55:02] <Compn> at http://roundup.ffmpeg.org [22:55:12] <Compn> upload to: ftp://upload.mplayerhq.hu/MPlayer/incoming [22:55:19] <Compn> or your own file host, whichever is easier [22:59:07] <Yuvi> yep, Chris DiBona says it was his department that funded it which is the same dept as GSoC

1 0

IRC log for 2010-04-10
by irc＠mansr.com 11 Apr '10

11 Apr '10

[01:20:43] <blez> I'm sending 200kb chunks thru a named pipe to ffmpeg [01:20:59] <blez> and near 3mb output size it freezes [01:21:17] <blez> http://codepaste.net/7bmuha [01:21:25] <blez> is that a bug? [05:39:34] <kierank> Tjoppen: tourists seem to like the London Eye. [06:47:04] <kierank> Tjoppen: also the British Museum (Rosetta Stone, elgin marbles) is worth seeing [08:24:42] <cecil`> When using -mp3lame you need also to use -ar, but it is not checked. I was thinking about a patch that when the option -mp3lame is used, but not the option -ar gives an error message and quits. Anyone an idea how and where to do this? [08:25:10] <kshishkov> sounds like a wrong approach at all [08:26:34] <cecil`> Okay, what would be a good approach? [08:26:56] <kshishkov> understand what you're doing wrong and don't do it [08:29:34] <cecil`> That is not very helpful I think. If you do not know that when using -mp3lame, you also need to use -ar (and the documentation does not say it, it even has a example without -ar), then you cann lose valuable time for nothing. What is wrong with giving a message when there is a missing parameter? [08:33:04] <kshishkov> because you can set -ab instead [08:34:04] <kshishkov> and not specifying any parameter means you don't know what you're doing [08:34:10] <jai> you shouldn't _need_ to add -ar [08:34:34] <jai> cecil`: ^ [08:35:04] <kshishkov> and -aq can be used instead of those two as well [08:37:35] <jai> of course that too [08:38:29] <cecil`> Okay, that I did not know. (I am new to ffmpeg.) But I still think that when you use -mp3lame without using -ab, -ar or -aq you should get a message and ffmpeg should stop. I'll post what happens now. Wait a second. [08:40:26] <cecil`> I tried to convert a video with: [08:40:26] <cecil`> ffmpeg -i input.mov -f avi -vcodec mpeg4 -b 400k -g 150 -bf 2 -acodec libmp3lame -ab 64k output.avi [08:40:27] <cecil`> [08:40:27] <cecil`> At input I get: [08:40:30] <cecil`> Stream #0.1(eng): Audio: pcm_u8, 7875 Hz, 1 channels, u8, 63 kb/s [08:40:33] <cecil`> and at output I get: [08:40:35] <cecil`> Stream #0.1(eng): Audio: libmp3lame, 7875 Hz, 1 channels, s16, 64 kb/s [08:40:38] <cecil`> [08:40:41] <cecil`> So far so good, but I also get: [08:40:45] <cecil`> Error while opening encoder for output stream #0.1 - maybe incorrect parameters such as bit_rate, rate, width or height [08:40:48] <cecil`> [08:41:08] <kshishkov> ah, so mp3 does not encode that weird sampling rate [08:41:30] <cecil`> Someone told me to use -ar, that is why I switched to: [08:41:34] <cecil`> ffmpeg -i input.mov -f avi -vcodec mpeg4 -b 400k -g 150 -bf 2 -acodec libmp3lame -ar 8000 -ab 64k output.avi [08:44:41] <cecil`> Yes when using -acodec libmp3lame (not -mp3lame, my bad), you need to give at least one other parameter. When you do not know this, you can spend a 'little' time to get things working. [08:45:32] <kshishkov> nope, had your file been 8kHz you could get away without -ar *and* -ab [08:46:34] <kshishkov> and it depends on the library - you go convince libmp3lame devs to print what's wrong on encoding [08:47:08] <cecil`> Okay, that I did not know. How can I find out what sampling rate my input file uses? [08:47:36] <kshishkov> it prints that, use ffprobe or ffmpeg -i infile [08:48:42] <cecil`> Okay, I was barking up the wrong tree. The problem lies with mp3lame, not with ffmpeg. From your reply I understand there is not much chance they will do about it. [08:52:39] <cecil`> When using ffmpeg -i, I get: [08:53:04] <cecil`> Stream #0.1(eng): Audio: pcm_u8, 7875 Hz, 1 channels, u8, 63 kb/s [08:53:04] <cecil`> [08:54:04] <cecil`> So because it is just a little to low (7875 Hz -> 8kHz) it goes wrong? [08:54:24] <kshishkov> no, MP3 has some fixed set of sampling rates to enccode [08:55:07] <cecil`> Where do I find those? And I should always use one of those? [08:55:26] <cecil`> ffmpeg -i also gives: [08:55:39] <cecil`> Seems stream 0 codec frame rate differs from container frame rate: 600.00 (600/1) -> 15.00 (15/1) [08:55:39] <cecil`> [08:56:16] <cecil`> Why is that? (I am new to the video stuff.) [08:56:24] <kshishkov> ignore that [08:56:51] <cecil`> Okay, it is nothing to worry about? [08:57:07] <kshishkov> yes and check http://lame.sourceforge.net for docs on MP3 [08:58:11] <cecil`> I'll do that. [08:58:36] <kshishkov> and in future you'd better direct such questions to #ffmpeg channel [08:59:54] <cecil`> Sorry. I thought I had to change something to the ffmpeg code. [09:02:07] <cecil`> So far so good, but would it not be a nice idea to give a message about the allowed sampling rates when you get: [09:02:08] <cecil`> Error while opening encoder for output stream #0.1 - maybe incorrect parameters such as bit_rate, rate, width or height [09:02:08] <cecil`> or am I asking to much? [09:02:32] <kshishkov> you are [09:02:59] <cecil`> Okay, I'll shut up. [09:03:09] <cecil`> Thanks for the help. [09:03:43] <kshishkov> no problem [09:36:06] <Dark_Shikari> oh god! the latest MSU codec comparison (I have the draft) includes theora [09:36:27] <kshishkov> and it bets x264? [09:36:30] <kshishkov> *beats [09:37:21] <Dark_Shikari> lol no [09:37:25] <Dark_Shikari> they intentionally have two copies of all the graphs [09:37:27] <Dark_Shikari> one set with theora [09:37:29] <Dark_Shikari> one set without [09:37:34] <Dark_Shikari> because it screws up the Y axis so badly [09:37:51] <Dark_Shikari> it gets utterly massacred, way way way worse than xvid [09:38:02] <Dark_Shikari> I think they must be using an old version, even theora shouldn't be this utterly atrocious [09:38:15] <kshishkov> while pross-au is not here, what's wrong with xvid? [09:38:43] <Dark_Shikari> x264 vs xvid is a smaller difference than xvid vs theora. [09:38:49] <Dark_Shikari> that shouldn't be the case. [09:39:35] <iive> some new comparison? [09:41:30] <Dark_Shikari> I have the draft of MSU's latest comparison [09:41:36] <Dark_Shikari> summary: x264 owns the shit out of everyone by huge margins [09:41:38] <Dark_Shikari> and they included theora [09:41:48] <Dark_Shikari> which is so hilariously bad it skews every single graph so much that they include two copies of all the graphs [09:41:54] <Dark_Shikari> one with theora, one without [09:42:54] <pJok> in theora, noone can hear you scream [09:43:27] <Dark_Shikari> it shows x264 as 4 times better than theora [09:43:37] <Dark_Shikari> on average over their "movie" tests [09:43:41] <Dark_Shikari> for the same SSIM [09:44:41] <Dark_Shikari> http://i40.tinypic.com/mslond.png [09:46:13] <twnqx> lol pJok :P [09:46:52] <pJok> twnqx, its true... its a video codec... ;) [09:47:21] <pJok> in vorbis on the other can, anyone with a suitable decoder can hear you scream ;) [09:48:00] <twnqx> i prefer your screams in alac! [09:48:14] <twnqx> (just because that doesn't fit in ogg) [09:48:30] <pJok> hand* [09:48:54] <iive> pJok: in theora you have no mouth. [09:49:11] <pJok> i thought that was in the matrix [09:49:16] <pJok> at least i have no ear [09:49:17] <pJok> http://right.frequency.dk/~jok/ear.jpg [09:49:49] <iive> i'm refering to another sci-fi work. "I have no mouth and I can't screen" or something that should mean the same. [09:50:57] <pJok> ah [09:51:51] <iive> scream [09:52:29] <iive> blah... my typing skills are in decline. [09:54:05] <pJok> hehe [09:54:09] <pJok> this is the internet [09:54:14] <pJok> who needs typing skills [09:54:23] <pJok> they are only for typonazis anyways [09:55:32] <iive> don't mention that word. I got banned and stripped of rang for using it. [09:55:57] <pJok> hehe [10:08:28] <Dark_Shikari> http://i41.tinypic.com/somph3.png http://i44.tinypic.com/2hdbmf8.png [10:11:03] <Dark_Shikari> so, I take back anything I said about theora getting anywhere near xvid =p [10:21:31] <kshishkov> Dark_Shikari: you just wait and see ho wXiph interprets that data [13:01:50] <jai> wb saste [13:02:32] <pJok> afternoon jai :) [13:03:49] <saste> jai: hi [13:05:54] <jai> hey there pJok :) [13:06:00] <DonDiego> Dark_Shikari: is that msu comparison available somewhere? [13:36:13] <kierank> ETIMEDOUT isn't defined in mingw if you didn't know already [13:37:33] <kshishkov> no we don't [13:37:48] <kshishkov> it's like BSD for Windows anyway in terms of lacking API [13:38:11] <mru> WinBSD [13:38:36] * kierank considers finally moving to cygwin [13:38:46] <mru> why not go all the way to linux? [13:40:04] <kierank> mainly because of random programs that don't work in wine [13:40:42] <kierank> but I do have a partition anyway [14:59:32] <kshishkov> lol, http://google-opensource.blogspot.com/2010/04/interesting-times-for-video-o… [15:00:05] <jai> yeah :) [15:04:38] <kshishkov> "The complexity of Theora is considerably less than that of many of its peers" - well, unless you talk about H.264 everything else is _less_ complex [15:14:07] <merbanan> would be fun if we were able to create a faster implementation for arm [15:14:43] <mru> is that theorarm thing any good? [15:14:47] <kshishkov> it's hard since Måns has shotgun [15:15:01] <kierank> merbanan: then someone could write a bizarre blog post to go with it [15:15:26] <merbanan> yes [15:15:53] <merbanan> more blog posts [15:17:31] <kshishkov> you can get bulletproof jacket, jetpack (to counter raised floors) and convince Måns to write superfast Theora decoder for ARM [15:17:38] <kshishkov> and encoder while you're at it [15:17:58] <merbanan> I think just money would do it [15:19:14] <kshishkov> you don't have enough [15:19:42] <mru> I get enough money working on sensible things [15:21:38] <kshishkov> merbanan: alternatively you can ask Luka, he lives in an area known for people who know how to give an offer you cannot refuse [15:22:41] <merbanan> :) or you can get a horse head [15:24:31] <kshishkov> anyway, the main problem is that sets of people who can do stuff for ARM and people who want to do Theora decoder do not intersect [15:25:11] <kshishkov> and I suspect if you educate people from the second set they will lose interest in it too [15:29:45] <merbanan> money can motivate, maybe [15:30:38] <kshishkov> maybe [16:04:16] <mru> right now I'm motivated to speed up dts decoder [16:04:40] <kshishkov> tack så mycket [16:04:54] <kshishkov> if you have any questions don't hesitate to ask Benjamin [16:05:01] <mru> I have some asm [16:05:06] <mru> just need a new function pointer [16:05:46] <kshishkov> which you can reuse for MPEG Audio as well ;) [16:06:18] <mru> need to decide where to put the pointer [16:06:27] <kshishkov> dsputil.h [16:06:52] <mru> we're trying to split that up [16:07:00] <mru> and it needs fft [16:07:04] <kshishkov> dsputil_audio.h then ;) [16:07:10] <mru> nothing in dsputil needs fft now [16:08:32] <kshishkov> to mdct funcs then [16:26:28] <merbanan> mru: ok ok [16:27:12] <mru> wow, that was quick [16:28:03] <ramiro> mru: in path 2/3, isn't ff_synth_filter_init_arm being called before it's added in patch 3/3? [16:28:31] <mru> ouch, split them wrongly... [16:28:34] <mru> oh well [16:28:41] <CIA-81> ffmpeg: mru * r22826 /trunk/libavcodec/ (dcadata.h dca.c): [16:28:41] <CIA-81> ffmpeg: DCA: align some arrays [16:28:41] <CIA-81> ffmpeg: Optimised implementations of the synth filter will require these [16:28:41] <CIA-81> ffmpeg: arrays 16-byte aligned. [16:28:41] <CIA-81> ffmpeg: mru * r22827 /trunk/libavcodec/ (dca.c synth_filter.c synth_filter.h): Make synth_filter a function pointer [16:28:42] <CIA-81> ffmpeg: mru * r22828 /trunk/libavcodec/ (4 files in 2 dirs): [16:28:42] <CIA-81> ffmpeg: ARM: NEON optimised synth_filter_float [16:28:42] <CIA-81> ffmpeg: 2.7x faster DCA decoding on Cortex-A8 [16:28:44] <kshishkov> mru: still patch ok [16:29:57] <mru> next: try to speed it up another 30% [16:30:47] <kshishkov> patch ok :) [16:31:39] <kshishkov> DCA decoder has two maintainers and both are quite permissive ;) [16:58:37] <_av500_> \\\ooo/// [17:01:38] * DonDiego fears that _av500_ morphed into a weird three-headed alien.. [17:03:14] <mru> no, that troll from the holy grail [17:14:36] <kshishkov> mru: did you mean three-headed knight or the monster from castle Aargh? [17:16:59] <mru> I mean the 3-headed thing sir robin ran away from [17:17:28] <kshishkov> a knight [17:17:42] <kshishkov> s/ran away/bravely ran away/ [17:17:57] <mru> that was no knight [17:18:24] <_av500_> calm down it is only motion blur [17:18:57] <mru> "it's only a model" [17:19:18] <kshishkov> http://www.youtube.com/watch?v=c4SJ0xR2_bQ [17:33:36] <CIA-81> ffmpeg: jai_menon * r22829 /trunk/libavcodec/alacenc.c: alacenc : Report supported input sample formats. [18:08:39] <kshishkov> .quit [19:01:16] <Dark_Shikari> DonDiego: not published yet [19:05:19] <Dark_Shikari> siretart: ping [19:13:13] <DonDiego> Dark_Shikari: when will it get published? [19:14:10] <Dark_Shikari> I'll upload it somewhere. [19:16:07] <iive> encoders comparison? i hope there is latest theora beta/dev version too, or they will say "you used older theora encoders on purpose" :) [19:17:13] <DonDiego> yes [19:20:49] <Dark_Shikari> it's the last theora release :) [19:21:48] <Dark_Shikari> http://www.mediafire.com/?djym2vmjddm <--comparison [19:22:01] <iive> well, then you should compare it to the last x264 release :P [19:22:21] * iive tries to remember have there ever been x264 release. [19:22:43] <Dark_Shikari> This is why we don't have releases! [19:22:46] <Dark_Shikari> I've said this over and over [19:22:56] <Dark_Shikari> If you don't have releases, nobody can get away with "using the last release" because there is none ;) [19:24:33] <DonDiego> Dark_Shikari: can i pass this thing around? [19:25:09] <Dark_Shikari> hmm... sure. [19:25:13] <DonDiego> ok [19:25:20] <DonDiego> anyway, gtg, cu guys [19:29:16] <iive> Dark_Shikari: honestly. Don't give them escape route. If you make the comparison, add the latest dev version, so the people would know that even next release won't be as good as xvid. [19:29:32] <Dark_Shikari> They'd just say you were using a buggy recent version [19:29:37] <Dark_Shikari> and you should use the last release [19:29:43] <iive> keep both. [19:29:47] <Dark_Shikari> lol [19:34:19] <iive> if you want just one version, then make the test and include the one that is better. then mention the other performs worse. [19:39:43] * elenril lols@usage of AndZoidberg in that comparison [19:43:49] <Dark_Shikari> it's true [19:52:56] <Compn> so uh [19:53:18] <Compn> nm, must be mp3 encoding time [20:32:26] <BBB> so google funds (in some way) theora now? [20:32:35] <BBB> that's an interesting turn of events... </sarcasm> :) [20:34:26] * _av500_ remembers the theorarm from some time ago... [20:34:38] <_av500_> so what is new? [20:35:30] <BBB> I just heard about that today - I'm surprised, I'd figure they'd release vp8 by now [20:35:44] <CIA-81> ffmpeg: koorogi * r22830 /trunk/ (libavfilter/avfilter.h Changelog): Bump libavfilter minor version and Changelog for unsharp filter [20:35:51] <BBB> instead, they're still monkeying around with the 12-year-old vp3-related technology [20:36:30] <_av500_> ill wait for it to alpear in android.. [20:37:01] <_av500_> if they are serious.. [20:38:08] <Compn> i'm still betting that google sits on all of on2 until h264 charges for web licenses [20:38:09] <Dark_Shikari> what's the news? [20:38:21] <Compn> then google can charge less and win the internet video wars [20:38:46] <_av500_> Compn: cool. so never :) [20:39:26] <BBB> that's a great way to negotiate [20:39:38] <BBB> well, good for google with their big walle [20:39:44] <Dark_Shikari> what's this news today? [20:40:05] <_av500_> googtheora [20:40:08] <Dark_Shikari> where [20:40:41] * _av500_ is in tram cannot paste url [20:41:08] <_av500_> scroll back [20:42:07] <Dark_Shikari> I don't see it [20:43:30] <_av500_> google opensrc blog [20:43:34] <BBB> http://google-opensource.blogspot.com/2010/04/interesting-times-for-video-o… [20:44:07] <_av500_> thx [20:44:53] <Dark_Shikari> lol [20:44:55] <Dark_Shikari> "stands up quite well" [20:44:58] <Dark_Shikari> "being simpler to decode" [20:45:07] <_av500_> :) [20:45:07] <Dark_Shikari> mpeg-4 sp is lower complexity than theora [20:45:19] <_av500_> h263 ftw [20:45:24] <Dark_Shikari> even google has drunk the koolaid now [20:45:31] <Dark_Shikari> well, odds are more likely it's just the guy writing the blog post [20:45:31] <_av500_> goolaid [20:45:56] <_av500_> 100% evil free [20:46:39] <BBB> #define evil [20:47:19] <_av500_> !nice [22:25:41] <_av500_> Dark_Shikari: lol at how they need to remove theora from the graphs [22:26:10] <_av500_> that is the most impressive argument [22:50:27] <Dark_Shikari> _av500_: lol yes [23:44:51] <Kovensky> where's vitor :X [23:44:58] <Kovensky> (or someone else that knows about audio filtering)

1 0