[FFmpeg-devel-irc] IRC log for 2010-04-19

[irc at mansr.com]

[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-ppc_sdl.dmg.gz
[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