Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2010

1 participants
28 discussions

IRC log for 2010-02-07
by irc＠mansr.com 08 Feb '10

08 Feb '10

[01:14:49] <CIA-17> ffmpeg: michael * r21661 /trunk/libavcodec/h264_direct.c: ref_offset must be added after checking references validity. [01:15:47] <CIA-17> ffmpeg: michael * r21662 /trunk/libavcodec/h264_direct.c: Add assert(sps.direct_8x8_inference_flag) to FIXME comment. [01:18:04] <CIA-17> ffmpeg: michael * r21663 /trunk/libavcodec/h264_direct.c: Fix reference selection for colocated MBs from frames to fields. [01:18:50] <CIA-17> ffmpeg: michael * r21664 /trunk/libavcodec/h264_direct.c: Fix colocated map. [02:00:51] <CIA-17> ffmpeg: michael * r21665 /trunk/libavcodec/h264_loopfilter.c: [02:00:51] <CIA-17> ffmpeg: Fix CAVLC+8x8DCT+MBAFF loopfiltering. [02:00:51] <CIA-17> ffmpeg: Fixes issue1250 [02:02:04] <Dark_Shikari> nice [02:09:54] <Kovensky> lol interlacing :D [08:00:13] <_av500_> gee, headaches [08:01:05] <kshishkov> why? [08:01:32] <_av500_> beer? [08:01:57] <_av500_> i doubt its the brussels tapwater [08:04:56] <kshishkov> why do you get hangover from either of those? [08:06:17] <_av500_> -EDONTKNOW [08:07:40] <kshishkov> in Denmark they write on alcoholic drink ads "Enjoy $drink responsibly", here they write "Alcohol may be harmful to your health" [09:07:37] <_av500_> kshishkov: good breakfast mostly cured it.. [09:08:32] <kshishkov> good for you [09:09:25] <thresh> i've got a headache too, but i didnt drink enough alcohol yesterday to get it [09:09:58] <kshishkov> what have you done instead? [09:10:01] <jai> how was fosdem? [09:10:11] <jai> s/was/is [09:10:14] <pJok> _av500_, just eat before sleep [09:10:21] <pJok> works every time fo rme [09:10:24] <pJok> for me* [09:10:35] <_av500_> pJok: hmm [09:10:39] <kshishkov> pJok: I eat instead of drinking alcohol, works even better for me [09:11:00] <pJok> kshishkov, and you are ukranian... aren't you supposted to take baths in vodka? ;) [09:11:17] <thresh> kshishkov: slept :-( [09:11:17] <kshishkov> pJok: no [09:11:50] <pJok> kshishkov, i guess not all ukranians drink then... :) [09:12:15] <thresh> pJok: i prefer a couple of aspirin tablets before the sleep [09:14:54] <_av500_> jai: flickr.com/photos/av500 has fosdem pics [09:15:27] <_av500_> videowall of 6 beagleboard running mrus ffplay in sync [09:15:45] <pJok> thresh, eating works way better than any painkillers before sleep [09:17:32] <thresh> not for me :( [09:17:57] <jai> av500: awesome [09:18:14] <kshishkov> thresh: "закуска градус крадет"? [09:24:07] <thresh> av500: are those in 720p? [09:29:37] <thresh> kshishkov: не, просто не помогает избавиться от головной боли [09:43:50] <_av500_> thresh: 1080p movie cut in 6 parts, but movie trailers are 2.35 so less vertical pixels [09:44:06] <_av500_> monitors run 1024x768 [09:44:34] <thresh> nice anyway [09:47:45] <_av500_> yep [09:48:13] <_av500_> it is hard to get material larger than 1080p to spread over 6 monitors... [09:54:45] <jai> _av500_: which camera is that? [09:54:53] <jai> the one you used to take the pictures [09:55:12] <thresh> it says on flickr page [09:55:34] <jai> hmm, i seem to have missed that [10:05:21] <lu_zero_fosdem> h [10:05:22] <lu_zero_fosdem> i [10:05:45] <kshishkov> h [10:05:46] <kshishkov> e [10:05:47] <kshishkov> j [10:05:58] <lu_zero_fosdem> Dark_Shikari: we got a question about x264.c in ffmpeg [10:06:25] <lu_zero_fosdem> how hard would be make branch 0.5 and trunk in sync in your opinion? [10:06:37] <lu_zero_fosdem> (and would it be worthy?) [10:18:06] <_av500_> jai: crappy g1 [10:22:14] <twnqx> lu_zero_fosdem: given how long ago 0.5 was released, and how many changes there are since... i'd say very [10:25:25] <_av500_> lu_zero_fosdem: gm [10:26:55] <CIA-17> ffmpeg: stefano * r21666 /trunk/ (5 files in 2 dirs): [10:26:55] <CIA-17> ffmpeg: Implement a physical concatenation protocol. [10:26:55] <CIA-17> ffmpeg: Patch by Michele Orr? reverse(<moc.liamg(a)yp.rekam>). [10:30:37] <lu_zero_fosdem> good morning [11:00:59] <_av500_> http://www.youtube.com/watch?v=9pwUdRKllo0 [11:04:59] <superdump> Dark_Shikari: fyi, siretart is also interested in updating the libx264 shipped with ffmpeg 0.5 to work with curretn x264 iirc [11:05:09] <superdump> maybe it was he that made the suggestion [11:05:15] <superdump> i would think that it isn't difficult [11:05:23] <superdump> and we could update the preset files too [11:05:33] <superdump> then maybe it could land in lucid [11:10:31] <twnqx> uh [11:10:42] <twnqx> why not just release 0.6 or even 1.0? [11:13:01] * twnqx never really understood that idea of backporting things to obsolete versions [11:18:29] <superdump> twnqx: because we could push out a 0.5.1 almost immediately but there are a number of things we would like to land in 0.6 [11:19:17] <twnqx> but would the 0.5 api break any recent version of other apps anyway? [11:19:23] <twnqx> wouldn't [11:20:32] <Dark_Shikari> superdump: good idea [11:20:35] <Dark_Shikari> I have a patch that does that. [11:23:07] <Dark_Shikari> http://pastebin.com/m3769ee76 [11:23:11] <Dark_Shikari> that does up to API version 79 [11:23:16] <Dark_Shikari> adding the 83 changes is one more diff [11:29:34] <peloverde> Do branch users want to update their libx264? [11:30:07] <Dark_Shikari> I say "they should" ;) [11:30:14] <kshishkov> peloverde: somebody called ffaacenc useful, it's your fault [11:30:17] <Dark_Shikari> of course, if we do update the branch as siretart requests [11:30:21] <Dark_Shikari> it _WILL NOT_ work with older libx264s [11:30:50] <peloverde> Yes but if they are using branch and not trunk they may not want to update x264 substantially [11:30:58] <Dark_Shikari> exactly [11:31:56] <peloverde> Anyway I have to go because apparently the airline screwed my over on flights and I don't want to get stuck in BRU [11:32:16] <peloverde> I'll try to catch up with siretart at the stand [12:15:23] <siretart> Dark_Shikari: any change to create a change for ffmpeg 0.5 that works with both the version currently in ubuntu and with newer versions? [12:33:37] <superdump> Dark_Shikari: i think one of siretart's prerequisites to addressing that possibility was that it must be backward compatible (i.e. it should work with both new and old libx264) [12:33:48] <superdump> i guess it doesn't because of b_ to i_ changes and such [12:36:50] <Dark_Shikari> superdump: worse than that [12:36:55] <Dark_Shikari> the nal encapsulation change [12:37:01] <Dark_Shikari> Of course, you can just ifdef the entire file if you want [12:38:18] <Dark_Shikari> siretart: I could do it of course, but it'd basically involve a whole-file ifdef [12:38:44] <Dark_Shikari> and I think that's too ugly, even if only to put in a branch that only exists to please outdated binary distros [12:40:22] <twnqx> honestly... just deprectae distros that make such requirements [12:41:04] <twnqx> it's like "udev 151 must support every kernel down to 2.4.0" [12:41:59] <Dark_Shikari> the thing I cannot understand is [12:42:02] <Dark_Shikari> "we want a new x264, but an old ffmpeg" [12:42:04] <Dark_Shikari> why? [12:42:10] <Dark_Shikari> can't you use a new x264, and a new ffmpeg? [12:42:13] <Dark_Shikari> or an old x264, and an old ffmpeg? [12:42:16] <twnqx> so you do not have the the new features! [12:42:27] <superdump> the old ffmpeg is 'well-tested' as it's been distributed for a long time [12:42:30] <twnqx> so your retarded users don't have to look hem up [12:42:33] <superdump> its issues are better known now [12:42:36] <superdump> i guess [12:43:05] <twnqx> i mean.. are new codecs backported to ffmpeg-0.5? [12:43:09] <Dark_Shikari> no [12:43:12] <Dark_Shikari> not even bugfixes are backported [12:43:17] <twnqx> to it's basically useless [12:43:22] <Dark_Shikari> superdump: "well tested" means nothing if bugfixes aren't backported [12:43:23] <twnqx> remove the branch and be happy [12:43:42] <superdump> if it's not possible to have an ffmpeg binary that supports both new and old libx264 then it probably won't be done [12:43:50] <Dark_Shikari> IMO, put simply, unless you backport all bugfixes, "latest release" is no different from "latest svn" stability-wise [12:43:59] <Dark_Shikari> a binary? now that is physically impossible [12:44:00] <superdump> however, there's a possibility of a ppa [12:44:03] <twnqx> current applications do not link or build against ffmpeg 0.5 due to api changes [12:44:05] <Dark_Shikari> it's possible to have a _source tree_ that does [12:44:07] <superdump> which is more interesting [12:44:13] <Dark_Shikari> but not a single binary that does [12:44:30] <superdump> mmm [12:44:40] <twnqx> lots of bugs are - and will stay - unfixed, several of today's actually used formats are unsupported [12:44:41] <Dark_Shikari> (ok, so in theory, you could make such a binary with gratuitous use of dlopen) [12:44:41] <superdump> then i don't think it will pass ubuntu/debian policies [12:44:55] <Dark_Shikari> by duplicating all the libx264.c code [12:44:58] <Dark_Shikari> adding tons of function pointers [12:45:01] <superdump> so rather 0.5.1 would just be with some backported bug fixes [12:45:02] <Dark_Shikari> and similar things [12:45:16] <Dark_Shikari> things which are far uglier than anything I've proposed so far [12:45:17] <superdump> 0.6 will be too late for lucid [12:45:18] <twnqx> superdump: is that really worth developer's time? [12:45:22] <Dark_Shikari> or in fact, uglier than anything I have ever implemented [12:45:29] <superdump> twnqx: if siretart wants to do it... [12:45:51] <twnqx> well, debian is all about obsolete software, so it makes kinda sense... [12:45:59] <superdump> Dark_Shikari: i think a nightly ppa would be more interesting personally [12:46:08] <Dark_Shikari> superdump: yes, because it would make the distro quite a bit less shit [12:46:25] <superdump> Dark_Shikari: that's the aim [12:46:30] <Dark_Shikari> a distro is shit when you have threads on the distro's forums with guides on how to compile software for that distro, because the distro's own packages are totally useless [12:46:34] <superdump> current x264 and ffmpeg easily installable :) [12:46:58] <twnqx> Dark_Shikari: +1 [12:47:19] <superdump> and built by someone who knows 1) packaging for debian/ubuntu and 2) talks to us about it [12:48:08] <Dark_Shikari> also, I'm bitter about ubuntu not supporting my laptop [12:48:17] <twnqx> laptop is too new? [12:48:22] <Dark_Shikari> yes [12:48:27] <Dark_Shikari> windows 7 supported it, ubuntu did not [12:48:36] <Dark_Shikari> because the version freeze for latest ubuntu was older than for windows 7 [12:48:43] <Dark_Shikari> yes, that's right: microsoft is more up to date than ubuntu [12:48:55] <twnqx> that's pretty normal, don't you think? [12:49:02] <Dark_Shikari> microsoft is _HARDLY_ known for being up to date [12:49:15] <Dark_Shikari> hell, they don't even release critical security patches more than once a month [12:49:20] <jai> Dark_Shikari: is there a problem with specific h/w? [12:49:22] <Dark_Shikari> even when their OS is getting rooted left, right, and center [12:49:23] <twnqx> but commercial drriver developers are more likely to support win than linux [12:49:29] <Dark_Shikari> jai: sound driver requires a specific quirks mode [12:49:38] <Dark_Shikari> took me half a day to figure that out [12:49:49] <Dark_Shikari> also, lan/wireless are really finicky, never solved that [12:49:52] <superdump> some intel hda quirk? [12:49:55] <jai> Dark_Shikari: k [12:49:57] <Dark_Shikari> dell-m6 quirk [12:50:07] <superdump> Dark_Shikari: but through intel hda? [12:50:19] <superdump> i.e. you have to select the correct codec variant? [12:50:28] <jai> Dark_Shikari: my only suggestion would be to run a very recent kernel :) [12:50:29] <superdump> for the correct quirks to be applied [12:50:40] <Dark_Shikari> superdump: something like that [12:50:43] <superdump> mmm [12:50:50] <superdump> hda is a bit fucked up sometimes [12:59:33] <Kovensky> <@Dark_Shikari> jai: sound driver requires a specific quirks mode <-- pretty much every realtek hda-based chip requires a special driver on win7 ._. [12:59:49] <Kovensky> because of some new audio mode called 'pull mode' that realtek decided to enable without actually checking that it works [12:59:56] <Dark_Shikari> gg [13:00:03] <Kovensky> with pull mode enabled, sound cracks, pops, and overall sounds like a bad vinyl recorder [13:00:30] <Kovensky> reducing sample rate / bits per sample helps reduce the noise, but doesn't kill it; you need to get a special "no pull mode" driver [13:02:30] <superdump> good job realtek [13:04:44] <jai> heh [14:16:41] <siretart> Dark_Shikari: probably not worth for 0.5, but it would really great if post 0.6 versions of libx264.c/x264 could keep compatibility with versions that go with the 0.6 release [14:17:00] <siretart> Dark_Shikari: as for ifdefs, it seems that dondiego and mru are fine with that [14:56:50] <CIA-17> ffmpeg: michael * r21667 /trunk/libavcodec/h264_direct.c: Skip the fill_colmap() case thats for MBAFF if we dont have an MBAFF frame. [15:06:08] <tetsuo55> anyone happen to see these warnings when compiling through visual studio? [15:06:09] <tetsuo55> 24>h:\progs\Compiling\mpc-hc_dev\src\filters\transform\mpcvideodec\ffmpeg\libavcodec\h264.h(1283) : warning C4047: 'initializing' : 'int (*)[64]' differs in lev [15:06:09] <tetsuo55> els of indirection from 'int *' [15:06:34] <tetsuo55> and [15:06:45] <iive> msvc is not supported [15:07:09] <tetsuo55> 24>h:\progs\compiling\mpc-hc_dev\src\filters\transform\mpcvideodec\ffmpeg\libavcodec\h264_mvpred.h(81) : warning C4002: too many actual parameters for macro 'tprintf' [15:07:41] <tetsuo55> yeah i know [15:07:50] <tetsuo55> but it didnt give these warnings before the h264 split [15:08:08] <tetsuo55> we use gcc to compile it, but gcc is called from visual studio [15:09:20] <tetsuo55> we tried to figure out why msvc is complaining but have been unable to understand what that line of code is doing [15:13:31] <CIA-17> ffmpeg: michael * r21668 /trunk/libavcodec/h264_ps.c: Check direct_8x8_inference_flag. [15:14:47] <CIA-17> ffmpeg: michael * r21669 /trunk/libavcodec/h264_direct.c: Remove FIXMEs for cases that are disallowed by the spec. [15:27:10] <tetsuo55> hmm, i guess we can consider h264 to be a wip for now [15:27:14] <tetsuo55> :) [15:32:22] <iive> aha, the warnings are definitely from msvc compiler, but you use them only for the client application, not to compile lavc [15:32:37] <iive> i mean, you use the headers in the... [15:32:49] <tetsuo55> i think i know why its happening [15:32:53] <tetsuo55> we still have hybrid files [15:32:55] <tetsuo55> grr [15:33:05] <tetsuo55> (mixed old/new ffmpeg files) [15:47:10] <CIA-17> ffmpeg: stefano * r21670 /trunk/cmdutils.c: [15:47:10] <CIA-17> ffmpeg: Make parse_options() explicitely handle the case where an opt_func2 [15:47:10] <CIA-17> ffmpeg: function returns a negative value, rather than erroneously trigger the [15:47:10] <CIA-17> ffmpeg: code which manages the case of unknown option. [16:27:50] <CIA-17> ffmpeg: michael * r21671 /trunk/libavutil/ (mathematics.h mathematics.c): av_compare_ts() [16:27:51] <CIA-17> ffmpeg: michael * r21672 /trunk/libavformat/utils.c: Use av_compare_ts() for interleaving per dts. [17:14:47] <CIA-17> ffmpeg: michael * r21673 /trunk/libavutil/avutil.h: Bump minor for av_compare_ts() [17:16:09] <CIA-17> ffmpeg: michael * r21674 /trunk/libavcodec/h264_direct.c: Factorize setting sub_mb_type out. [17:41:13] <CIA-17> ffmpeg: michael * r21675 /trunk/libavcodec/h264_direct.c: Set direct MB partitioning for 16x8 and 8x16 colocated MBs to the respective true partitioning. [18:47:42] <siretart> hi DonDiego [18:47:46] <DonDiego> hi [18:49:00] <siretart> no, im not at home yet [18:49:41] <DonDiego> haha :) [19:10:54] <CIA-17> ffmpeg: michael * r21676 /trunk/libavformat/utils.c: [19:10:54] <CIA-17> ffmpeg: Directly use av_rescale_rnd() instead of av_convert_ts() as this cuts the [19:10:54] <CIA-17> ffmpeg: number of calls to it down by 2. [19:51:59] <Dark_Shikari> siretart: we don't intend to have any large, obnoxious API changes in x264 any time soon, so that should not be too hard [19:52:46] <Dark_Shikari> how exactly do you want to do it? [19:53:04] <Dark_Shikari> do remember it is impossible for a single binary to support multiple x264 API versions [19:53:11] <Dark_Shikari> because a binary can only include one x264.h [19:56:30] <DonDiego> about the 0.5 branch backports? [19:56:47] <DonDiego> the binary need not support multiple versions [19:56:54] <DonDiego> the source needs to [20:02:41] <Dark_Shikari> siretart said the binary needs to, iirc [20:02:56] <Dark_Shikari> which is probably not possible with extreme amounts of dlopen magic [20:02:59] <Dark_Shikari> *without [20:03:11] <DonDiego> i think that's a misunderstanding [20:03:21] <Dark_Shikari> in that case, I can set up a patch to backport things [20:03:27] <Dark_Shikari> it will be staggeringly ugly [20:03:43] <DonDiego> we currently have a problem because some distros have a new enough x264 and others don't [20:04:02] <DonDiego> it would be nice if both could build against 0.5 [20:04:29] <DonDiego> i don't mind a few ifdefs on the branch [20:04:41] <DonDiego> it's nothing that we shall have to live with [20:05:19] <Dark_Shikari> wait wait [20:05:24] <Dark_Shikari> do you mean it should work with "0.5 x264, and new x264"? [20:05:25] <DonDiego> hmm? [20:05:28] <Dark_Shikari> or "OLD x264, and 0.5 x264?" [20:05:38] <Dark_Shikari> your last statement implied the latter I think? [20:06:00] <DonDiego> the 0.5 branch should work with: [20:06:15] <DonDiego> - an x264 from the time the branch was cut (which it does atm) [20:06:30] <DonDiego> - a current x264 (which it does not atm) [20:06:38] <Dark_Shikari> ok, I can do that [20:06:39] <DonDiego> clear now? [20:06:49] <Dark_Shikari> as long as there are no requirements on code quality ;) [20:06:55] <DonDiego> :) [20:06:59] <Dark_Shikari> I won't do it if it's required that I make the code as clean and simple as possible [20:07:04] <Dark_Shikari> but... it's 0.5, screw that =p [20:07:08] <DonDiego> yes [20:07:25] <DonDiego> ping me when you have it ready, i'll quickly review and approve it [20:08:12] <Dark_Shikari> ok, I will maybe do it sometime today [20:08:18] <DonDiego> cool [20:08:23] <Dark_Shikari> btw, does it have to work with every x264 in between, too? [20:08:33] <Dark_Shikari> I can do that, it will just be slightly trickier [20:08:41] <DonDiego> i'll go to bed soonish, send me a mail if i should be offline [20:08:51] <DonDiego> not necessarily [20:09:03] <DonDiego> we were thinking about the changes that are in current trunk [20:09:14] <DonDiego> these are two specific points [20:09:24] <DonDiego> are there many in between? [20:09:45] <Dark_Shikari> lemme see. is there a good way to find all revisions that modified a given file when using git? [20:09:58] <Dark_Shikari> oh, nevermind, the commit messages say when the API changed [20:10:12] <elenril> git log file? [20:10:17] <Dark_Shikari> ah, yup [20:10:33] <Dark_Shikari> API change in local tree: 85, nothing that will affect ffmpeg. [20:10:49] <Dark_Shikari> API change, DTS compression: 84, not used by ffmpeg [20:11:01] <Dark_Shikari> API 83: x264_encoder_parameters, not used by ffmpeg but might be useful [20:11:22] <Dark_Shikari> API 82: periodic intra refresh, not used by ffmpeg, but the b_keyframe feature is, so we'd have to count that [20:11:32] <Dark_Shikari> API 81: timebase parameters added with vfr input support [20:11:35] <Dark_Shikari> so we have to count that [20:11:50] <Dark_Shikari> API 80: sliced threads, but _still_ not available in ffmpeg [20:12:06] <Dark_Shikari> API 79: weightp, used by ffmpeg [20:12:14] <Dark_Shikari> API 78: new b-pyramid mode, used by ffmpeg [20:12:20] <Dark_Shikari> API 77: constrained intra, not used by ffmpeg [20:12:29] <Dark_Shikari> API 76: The Big Change that broke everything, nal encapsulation simplification [20:12:39] <Dark_Shikari> API 75: threaded lookahead, not available through ffmpeg [20:12:53] <Dark_Shikari> API 74: intentional forcing of link error in case of incompatible API, not referenced in ffmpeg code [20:13:06] <Dark_Shikari> API 73: multi slice, _still_ not available in ffmpeg [20:13:25] <Dark_Shikari> API 72: frame-accurate parameter changing, not used by ffmpeg [20:13:31] <Dark_Shikari> API 71: encoder_delayed_frames, not used by ffmpeg [20:13:39] <Dark_Shikari> API 70: MB-tree, used by ffmpeg. [20:13:47] <Dark_Shikari> API 69: new AQ, not available through ffmpeg [20:14:11] <Dark_Shikari> that leaves us with 82, 81, 79, 78, 76, 70. [20:16:34] <Dark_Shikari> Yeah. We have a lot of API changes. [20:23:44] <DonDiego> maybe that is where ffmpeg's reputation comes from.. [20:25:57] <Dark_Shikari> We almost never break backwards compatibility though [20:26:02] <Dark_Shikari> once in 2-3 years at most [20:26:39] <Dark_Shikari> the main issue is that because ffmpeg uses the variables directly instead of the recommended param_parse API, it forces an x264 upgrade every single time ffmpeg is updated [20:26:55] <Dark_Shikari> key/value pairs would avoid this problem [20:27:14] <DonDiego> implement it [20:27:27] <Dark_Shikari> it won't give any benefit until we have codec-specific options ;) [20:28:10] <Dark_Shikari> also, I _like_ being able to use ffmpeg to force people to upgrade their x264 [21:09:58] <CIA-17> ffmpeg: michael * r21677 /trunk/libavcodec/h264_direct.c: Precalculate a few variables for direct mv prediction for interlaced MBs. [21:54:45] <CIA-17> ffmpeg: michael * r21678 /trunk/libavcodec/h264_direct.c: [21:54:45] <CIA-17> ffmpeg: Merge mv&ref related code for spatial direct MV code. [21:54:45] <CIA-17> ffmpeg: a bit more than 10 cpu cycles faster. [22:09:35] <astrange> Assertion failed: (false && "Ran out of registers during register allocation!"), function assignRegOrStackSlotAtInterval, file RegAllocLinearScan.cpp, line 1183. [22:09:38] <astrange> i liked gcc's better [22:47:23] <astrange> michael broke the build :( [22:58:56] <CIA-17> ffmpeg: michael * r21679 /trunk/libavcodec/h264_direct.c: Zero a/b only in the branch where they need to be zeroed. [23:16:41] <CIA-17> ffmpeg: michael * r21680 /trunk/libavcodec/h264.h: Ooops, 10l forgot to commit h264.h. [23:17:14] <Compn> Dark_Shikari : have you already put in 'if x264 version is XXX and ffmpeg version is YYY then error "you need to upgrade ffmpeg and x264!" ? :P [23:17:40] <Dark_Shikari> lol michael [23:57:40] <Compn> fosdem over or are you irc from there ? [23:57:57] <Compn> any interesting questions/comments from people ?

1 0

IRC log for 2010-02-06
by irc＠mansr.com 07 Feb '10

07 Feb '10

[00:06:28] <CIA-17> ffmpeg: stefano * r21649 /trunk/ffplay.c: [00:06:29] <CIA-17> ffmpeg: Remove unused variable ref_clock, fix the warning: [00:06:29] <CIA-17> ffmpeg: ffplay.c: In function ?compute_frame_delay?: [00:06:29] <CIA-17> ffmpeg: ffplay.c:1064: warning: unused variable ?ref_clock? [00:11:29] <CIA-17> ffmpeg: stefano * r21650 /trunk/ffmpeg.c: [00:11:30] <CIA-17> ffmpeg: Add parentheses in boolean expression: (A && B || C) => ((A && B) || C), [00:11:30] <CIA-17> ffmpeg: fix the warning: [00:11:30] <CIA-17> ffmpeg: ffmpeg.c: In function ?output_packet?: [00:11:30] <CIA-17> ffmpeg: ffmpeg.c:1317: warning: suggest parentheses around && within || [00:34:11] <CIA-17> libswscale: stefano * r30518 /trunk/libswscale/swscale.h: [00:34:11] <CIA-17> libswscale: Satisfy consistency need: [00:34:11] <CIA-17> libswscale: int * sws_getCoefficients -> int *sws_getCoefficients. [00:34:11] <CIA-17> libswscale: stefano * r30519 /trunk/libswscale/swscale.h: Apply misc fixes to sws_getCoefficients() doxy. [00:34:11] <CIA-17> libswscale: stefano * r30520 /trunk/libswscale/utils.c: Simplify how usesVFilter and usesHFilter are set. [02:38:39] <elenril> MKV files don't work on bloody anything reliably except VLC, even though they're theoretically an h264 variant. [02:38:48] * elenril lols@slashdot comments [02:56:48] <CIA-17> ffmpeg: michael * r21651 /trunk/libavcodec/h264_direct.c: [02:56:48] <CIA-17> ffmpeg: Long term references behave different from short term in spatial direct MV calculation. [02:56:48] <CIA-17> ffmpeg: Fixes FRExt_MMCO4_Sony_B / issue1251 [03:21:18] <microchip_> elenril: waaaa? LMAO! [03:28:13] <saintdev> lmao: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel-irc/2010-February/000008.h… [03:29:06] <saintdev> looks like trollbot was sufficiently confuzzled [03:30:13] <Kovensky> lol [03:31:37] <microchip_> saintdev: why i see music notes in michael's commit's? lol [03:32:07] <elenril> because he's secretly japanese? [03:32:20] <microchip_> lol [03:32:27] <Kovensky> microchip_: lol [03:32:34] <Kovensky> because you're using a wrong encoding :P [03:32:57] <ohsix> the mail is [03:33:01] <Kovensky> those are mIRC color codes that trollbot doesn't strip [03:33:28] <saintdev> Kovensky: no they're not [03:35:11] <Kovensky> ugh [03:35:13] <saintdev> Kovensky: Ｔｈｅｙ＇ｒｅｕｔｆ８ｆｕｌｌｗｉｄｔｈｃｈａｒａｃｔｅｒｓ． [03:35:23] <Kovensky> yes, I just saw down the log [03:35:27] <Kovensky> I was thhinking about the CIA commits [03:35:35] <saintdev> oic [03:35:37] <Kovensky> the \x0f need to be stripped too [03:36:45] <microchip_> it'll be nice to CIA to report michael's mood... when he's listening to music, you get notes, when he's angry or mischievous, you get lil devils, etc :p [03:38:10] <saintdev> Kovensky: Ｍｙｆａｖｏｒｉｔｅｉｓｔｈｅｓｅｎｔｅｎｃｅｗｉｔｈａｐｌａｉｎｔｅｘｔ michael ｔｈｒｏｗｎｉｎｔｈｅｍｉｄｄｌｅｏｆｉｔ＝Ｄ [03:39:56] <saintdev> Ｈｅ＇ｓｇｏｉｎｇｔｏｈａｔｅｍｅａｎｄｔｈｉｎｋＩ＇ｍａｌｗａｙｓｓａｙｉｎｇｂａｄｔｈｉｎｇｓａｂｏｕｔｔｈｅ H.264 ｄｅｃｏｄｅｒ． [03:40:58] <Dark_Shikari> lol [03:41:07] <Dark_Shikari> mru: ping [03:41:20] * Dark_Shikari spent the past two days at Green Hills Software, thought you might be interested [03:41:28] <Dark_Shikari> Also, they have an ARM compiler that's 10% better than armcc [03:42:53] <Kovensky> saintdev: ｏｕ [03:43:36] * elenril wonders why are so many people awake at 4 in the morning [03:43:46] <Dark_Shikari> it's 7:40 PM [03:44:15] <Kovensky> it's 0:45 [03:44:17] <elenril> evil lies [03:44:30] <Compn> 10:54 here :P [03:44:35] <Compn> but my clock is fast [03:44:39] <Kovensky> Dark_Shikari: west coast? [03:45:02] <Compn> Dark_Shikari : you know of any shakey-cam removal / video smoothing software? [03:45:20] <Compn> i want to watch a shakey cam movie without vomitting [03:45:26] <Dark_Shikari> Kovensky: yes [03:45:29] <Dark_Shikari> Compn: avisynth, depan [03:45:33] <Kovensky> deen the motion away [03:45:37] <Kovensky> :D [03:45:43] <Compn> deen? [03:45:44] <Compn> thanks Dark_Shikari [03:45:59] <Kovensky> srsly, there's an anime that I'm watching this week [03:46:05] <Kovensky> the encode is practically an eDeen() demo [03:46:18] <Compn> NOOOOOOOOOOOOOOOOOOOO [03:46:30] <Compn> twitter results live in google search [03:46:44] <Kovensky> Compn: what [03:46:56] <Compn> google has live twitter in its search results... [03:49:57] <Kovensky> o_o' [04:39:31] <Compn> http://www1.mplayerhq.hu/~compn/shaken.avi [04:39:54] <Compn> this is the future of movies guys ^^ [04:40:43] <Dark_Shikari> LOL [04:41:00] <Dark_Shikari> can someone say pan and scan [04:41:19] <Kovensky> pan and scan [04:41:21] <Kovensky> there [04:41:28] <Kovensky> anyway, night ._. [07:46:35] * elenril wonders what would be a good place to set muxer ident string globally [07:47:31] <kshishkov> to set what? [07:48:36] <elenril> encoder="Lavf xx.xx" [07:49:55] <elenril> doing it as a special case in each muxer is annoying [07:54:52] <jai> avformat.h? [07:55:29] <kshishkov> wince all muxers do it in their own way, no problem with special cases [07:57:58] <elenril> no there is a problem [07:58:17] <elenril> with the new metadata system i should be able to do 'for tag in metadata: write_tag()' [07:59:04] <elenril> having to handle writing muxer ident separately makes it more complicated than necessary [08:01:07] <elenril> hmm, av_write_header() seems like a nice place [08:02:45] <jai> question : is it okay to commit trivial cleanups? [08:02:50] <jai> or do i send patches [08:14:08] <kshishkov> trivial is fine [08:24:49] <jai> kshishkov: k, thx [10:35:41] * _av500_ is at ff booth ff is not :( [10:39:33] * janneg guesses ff had a beer too much yesterday [10:45:11] <jai> heh [10:45:24] <jai> _av500_: try and hook up with mru maybe [11:12:01] <CIA-17> ffmpeg: michael * r21652 /trunk/ffmpeg.c: (log message trimmed) [11:12:01] <CIA-17> ffmpeg: Revert r21615 | cehoyos | 2010-02-02 23:23:09 +0100 (Tue, 02 Feb 2010) | 5 lines [11:12:01] <CIA-17> ffmpeg: Guess the duration before converting video and write guessed duration [11:12:01] <CIA-17> ffmpeg: into flv header. [11:12:01] <CIA-17> ffmpeg: Patch by Justin Johnson, justin D johnson3 A gmail [11:12:02] <CIA-17> ffmpeg: The change to ffmpeg.c is wrong as input and output files arent connected 1:1 [11:12:02] <CIA-17> ffmpeg: (i seem to have missed that) [12:03:20] <jai> elenril: is there a reason why "ISFT" is commented out? [12:03:44] <jai> i havent read the thread in detail so might be missing something though [12:04:07] <elenril> because it means 'encoder' so it's treated differently [12:05:21] <elenril> i'm working on a patch that would remove this special case atm [12:07:07] <jai> right, asked because i saw it in the conv table [12:16:36] <elenril> can you apply it? [12:19:52] <jai> elenril: sure [12:21:39] <jai> elenril: running regtests [12:21:48] <elenril> they should pass [12:21:56] * elenril tested this morning [12:33:36] <CIA-17> ffmpeg: jai_menon * r21653 /trunk/libavformat/ (avidec.c Makefile avi.c avi.h avienc.c): [12:33:36] <CIA-17> ffmpeg: Add AVI metadata conversion table. [12:33:36] <CIA-17> ffmpeg: Patch by Anton Khirnov (gmail{wyskas}). [12:34:26] <elenril> thanks [12:34:41] <jai> np [12:39:33] <CIA-17> ffmpeg: jai_menon * r21654 /trunk/libavcodec/alac.c: alac.c : Use av_freep instead of av_free. [12:40:35] <kierank> damn this stupid software seems to find a way to figure out that it's being run in a vm [12:40:51] <elenril> lol [12:41:03] <elenril> what's so secret about it anyway? [12:41:55] <elenril> hmm, i get ridiculous pts when encoding with ffaac [12:42:01] <elenril> is this expected/known? [12:42:01] <kierank> kept secret so that it can be sold for thousands of pounds [12:42:09] <jai> elenril: Red pill blue pill [12:42:27] <kshishkov> elenril: it's ridiculous you encode with ffaac [12:42:50] <elenril> just wanted something to mux to avi [12:43:01] <elenril> probably should have used flac [12:43:01] <kshishkov> not that encoder did something with pts though [12:49:16] <elenril> who is the maintainer of ogg/flac [12:49:26] <CIA-17> ffmpeg: jai_menon * r21655 /trunk/libavcodec/alac.c: Remove redundant use of numchannels since it is 1 for mono. [12:53:11] <CIA-17> ffmpeg: jai_menon * r21656 /trunk/libavcodec/alac.c: Avoid using an intermediate variable. [12:53:23] <elenril> bcoudrier is on fosdem? [12:54:17] <CIA-17> ffmpeg: reimar * r21657 /trunk/libavcodec/ (h261enc.c h261dec.c): Add include necessary for ff_set_qscale [12:54:30] <jai> elenril: possibly justin or Yuvi [12:55:18] * elenril wants vorbiscomment writing patch applied [12:57:43] <jai> elenril: was it approved? [12:59:12] <elenril> i don't think so [13:00:03] <elenril> it seems jruggles approved it, but wanted some comments from others [13:01:47] <jai> right, its been 3 days since the updated patch was sent [13:02:02] <jai> so maybe wait for a week to go by and ping again [13:05:10] <jai> also, i applied a few trivial patches i had for ffalac, if michael is reading this, i hope you are okay with it :) [13:16:07] <CIA-17> ffmpeg: jai_menon * r21658 /trunk/ffplay.c: cosmetics : re-indent after r21639. [13:55:49] * kierank reads kshishkov's blog post [13:59:53] * kshishkov did not [14:01:29] <janneg> the blog is write only memory? [14:02:00] <kshishkov> looking at most blogs it is [15:05:23] <kierank> could qemu be used for disassembly [15:09:43] <jai> kierank: wat [15:10:13] <kierank> i think that might work actually [15:10:56] <kierank> because you can dump the current instructions without the kernel module getting involved [15:31:11] <kshishkov> it can [16:35:49] <elenril> who runs git.ffmpeg.org? [16:36:21] <kierank> KotH [16:37:33] * elenril summons KotH from depths of hell [16:38:05] <kshishkov> well, "Belgium" is shorter [16:39:42] * elenril should go to fosdem too some time [16:39:59] * kshishkov should go wherever [16:40:58] <kierank> i think the html5 talk starts now [16:41:07] <kshishkov> heh [16:41:15] <elenril> that could be funnny [16:41:16] <kshishkov> tell us when HTML5 flames start [16:43:54] <kierank> might be a video stream [16:53:30] <CIA-17> ffmpeg: siretart * r21659 /trunk/configure: [16:53:30] <CIA-17> ffmpeg: libgsm installs headers in a subdirectory, use gsm.h from that subdirectory. [16:53:30] <CIA-17> ffmpeg: Approved by Diego at FOSDEM. [16:56:52] <_av500_> gm [16:57:05] <kshishkov> nv [16:57:41] <_av500_> html talk was too packed to get in.... [16:59:08] <Compn> ooooo man [16:59:15] * Compn wants to see more html5 flames [16:59:17] <Compn> FLAME ON [16:59:40] <ohsix> :M [17:10:31] <elenril> http://arstechnica.com/tech-policy/news/2010/02/studios-crushed-isp-cant-be… << awesome [17:13:00] <jai> elenril: lol @ treasure analogy [17:14:16] <jai> Compn: was that a Human Torch reference [17:17:36] <Compn> i guess so [17:42:33] <Kovensky> lolaustralia [17:42:48] <Kovensky> 14:21.29 <&Emess> well [17:42:49] <Kovensky> 14:21.33 <&Emess> after seeing that [17:42:54] <Kovensky> 14:21.34 <&Emess> I lol'd [17:43:04] <Kovensky> 14:21.37 <&Emess> because [17:43:04] <Kovensky> 14:21.39 <&Emess> most ISP's here dont give a shit [17:43:04] <Kovensky> 14:21.49 <&Emess> seeing as all their employees fileshare like teh fist of the north star [17:43:07] <Kovensky> 14:21.55 <&Emess> AND iinet is a west coast isp [17:43:20] <Kovensky> 14:22.13 <&Emess> the big west coast isp's have something called WAIX [17:43:20] <Kovensky> 14:22.18 <&Emess> essentially a high speed no cost network over the whole state [17:43:24] <Kovensky> 14:22.24 <&Emess> that lets people share stuff without a quota [17:43:26] <Kovensky> 14:22.32 <&Emess> although iinet withdrew from it last year the fuckers [17:43:28] <Kovensky> 14:22.37 <&Emess> anyway [17:43:31] <Kovensky> 14:22.44 <&Emess> most isps here are like talk to the cops, we dont care [17:43:33] <Kovensky> 14:22.56 <&Emess> my own isp hosts 4 trackers that I am aware of even [17:43:36] <Kovensky> 14:23.08 <&Emess> along with an FTP that downloads latest tv caps and shit in HD every week [17:43:43] <twnqx> come on [17:43:53] <twnqx> i know more than one european or US isp where it's the same [17:43:56] <Kovensky> hi charlieb [17:44:03] <twnqx> it's just normal. [17:44:11] <kierank> not any more now this channel is logged ;) [17:44:35] <twnqx> this channel was always logged [17:44:49] <kshishkov> now it's explicitly logged [17:44:50] <kierank> not publically [17:44:57] <twnqx> i know [17:45:08] <twnqx> but it doesn't change a thing [17:45:54] * Kovensky has logs dating back to early 2009 [17:46:27] <kierank> but the logs appear in google [17:46:47] <kierank> i.e. I search for stuff about smpte specs and find discussion of me [17:47:10] <kierank> be nice to have robots.txt on that mailing list [17:48:15] <Kovensky> I wonder how seriously will the logs here be taken [17:49:24] <kshishkov> kierank: so you are expecting a visit from nice guys of D*lby yet? [17:49:40] <kierank> not them i'm worried about [17:50:05] <kierank> people quoting me from here out of context is more of a problem [17:51:54] <kierank> also it seems this stupid drm can detect qemu [17:54:55] <twnqx> wow [17:55:00] <twnqx> that's pretty advanced [17:55:43] <kshishkov> no, virtual machine or debugger detection is rather old [17:56:00] <kierank> works nicely in virtualbox for some reason [17:56:24] <twnqx> debugger is old indeed [17:56:28] <ohsix> qemu is easy to detect too; virtualbox/vmware use secret knocks and stuff :> [17:56:49] <twnqx> i once ran into a linux virus that would detect if it was straced >_> [17:57:03] <kshishkov> wow [17:57:10] <kshishkov> linux virus FTW [17:57:18] <ohsix> ptracing yourself is oldschool too [17:57:20] <twnqx> that was like... hm... 10 years back or so [17:57:53] <twnqx> i noticed it more because the infected binaries wwouldn't run at all any more [17:58:03] <twnqx> and it infected /bin [17:58:52] <kierank> this thing goes as far as crashing qemu [17:59:52] <kshishkov> try virtualbox then [18:00:35] <kierank> virtualbox doesn't have much in the way of built in debugging [18:08:22] <Compn> hey [18:08:39] <Compn> heres a spam site installing vlc and ffdshow and other ffmpeg related stuff bundled with spyware >> http://www.video-buzz.com/ [18:09:02] <kshishkov> wanna ask them for malware sources? [18:09:46] <Compn> no, but you can [18:13:48] <kierank> lol it has TrustE [18:14:22] <kierank> whoops wrong camelcase, it's TRUSTe [18:14:36] <Compn> must be trustworthy [18:14:46] <Compn> kierank : feel free to put on roundup for me :D [18:14:56] <Compn> kshishkov : so are you going to merge x264 into ffmpeg? [18:15:04] * Compn trolls around [18:15:34] <kshishkov> Compn: no, I was merely saying that in N years it won't be so rapidly developed and will be ready for merge [18:16:47] <Compn> ah [19:26:03] <pscherer> Does anyone know if FFmpeg will be part of the google summer of code 2010? [19:26:17] <kshishkov> only Google does [19:26:34] <kshishkov> we want to participate though [19:26:54] <rsk> didnt ffmpeg get the maximum ammount of slots 2009? [19:27:18] <kshishkov> nope, other projects got slots as well [19:28:17] <pscherer> If you are part of it again I am interested in doing something for FFmpeg [19:29:00] * kshishkov is always interested to do something for FFmpeg [19:29:11] <tetsuo55> hello [19:29:19] <tetsuo55> i think i found a sort of bug, an uninitilised variable in ituh263dec.c [19:29:25] <tetsuo55> if s->mb_intra is true, and CONFIG_RV10_DECODER is not defined, and s->codec_id == CODEC_ID_RV10 is true, level is uninitialized [19:29:34] <tetsuo55> level seems to have too broad scope, it would make more sense to declare it inside the if(s->mb_intra) [19:29:42] <tetsuo55> what do you guys think? [19:29:47] <kshishkov> CONFIG_* vars are always defined [19:30:09] <tetsuo55> for every build option and platform? [19:30:14] <kshishkov> yes [19:30:18] <kshishkov> 0 or 1 [19:30:23] <tetsuo55> awesome [19:30:23] <tetsuo55> :D [19:31:39] <tetsuo55> oops [19:31:57] <tetsuo55> its suppsed to say "when defined as 1" instead of "when not defined" [19:32:47] <kshishkov> I suspect that condition should not happen in that file anyway [19:33:48] <tetsuo55> still, better safe than sorry or "wontfix" ? [19:34:30] <kshishkov> "shouldnothappen" [19:35:08] <kshishkov> CONFIG_RV10_DECODER=1 enables rv10 decoder, so when it's zero, it will refuse to decode rv10 and that check won't happen [19:37:36] <tetsuo55> i think thats what he mean [19:37:38] * tetsuo55 asks [19:39:09] <kshishkov> no need to be too safe in this case [19:59:28] <jai> hmm, do we have any aobs with mlp on mphq? [19:59:45] <kshishkov> aobs? [20:00:02] <jai> mpeg ps dvd audio [20:01:27] <kshishkov> no [20:04:01] <kierank> jai: do you want some? [20:04:35] <jai> kierank: if you have some, then sure [20:04:59] <kierank> i can get some [20:05:01] <jai> kierank: thanks :) [20:06:18] <jai> kierank: wait, do they have an mlp stream? [20:06:35] <jai> kierank: if they do, do they demux properly for you with lavf? [20:10:25] <kierank> yes they are mlp [20:10:27] <kierank> mediainfo says that [20:10:30] <kierank> ffmpeg says: [20:10:30] <kierank> Stream #0.0[0xa1]: Audio: pcm_s16be, 32000 Hz, 3 channels, s16, 1536 kb/s [20:10:30] <kierank> At least one output file must be specified [20:12:45] <jai> kierank: exactly, we need to fix that [20:13:13] <kierank> gimme a few minutes and i'll upload you a sample [20:13:21] <jai> kierank: thanks [20:18:52] <kierank> http://dl.dropbox.com/u/2701213/mlp.aob [20:21:30] * elenril sighs [20:21:46] <elenril> i suppose asking if anybody here understands how nut index works would be pointless [20:22:59] <iive> why? [20:24:39] <elenril> because i don't think anybody except people who wrote the specs know that ;) [20:25:56] <iive> please, ask your question and don't smear around. [21:11:10] <Compn> pscherer : get started working on a qualification task now, if so [21:11:29] <Compn> check small tasks page on http://wiki.multimedia.cx [22:43:35] <pscherer> Compn: will do [23:26:09] <CIA-17> ffmpeg: stefano * r21660 /trunk/doc/APIchanges: Add missing entries for the recent lsws API changes.

1 0

IRC log for 2010-02-05
by irc＠mansr.com 06 Feb '10

06 Feb '10

[00:13:38] <DonDiego> Yuvi: say, where was your theora speedup tree? [00:14:43] <Yuvi> DonDiego: http://github.com/yuvi/ffmpeg/tree/vp3-rewrite [00:15:01] <DonDiego> how much faster is that thing? [00:15:10] <Yuvi> just finished fixing the final bugs, but it's slower than it should be because I assumed theora was too much like sane codecs [00:15:12] <DonDiego> compared to trunk and libtheora 1.1? [00:15:21] <Yuvi> currently 15% for cases that matter, probably about the same speed as 1.1 [00:15:39] <DonDiego> so you're going to get it merged soon? [00:15:57] <Yuvi> yeah, I mainly need to not do MC twice for uncoded blocks [00:17:20] <DonDiego> do you know if it will be faster than 1.1 in the end? [00:17:31] <DonDiego> we should have much more (x86) asm.. [00:20:03] <Yuvi> almost certainly; that doesn't (yet) include DC-only IDCT (or near DC-only), asm for the x,y MC, or the faster DC prediction that 1.1 has [00:20:33] <DonDiego> can we steal some asm from them? [00:21:06] <Yuvi> yeah, but the only thing that would be useful is 10-element mmx IDCT which I'd probably end up rewriting for sse anyway [00:21:14] <DonDiego> k [00:38:30] <CIA-17> ffmpeg: michael * r21638 /trunk/ffplay.c: [00:38:30] <CIA-17> ffmpeg: Fast seeking. [00:38:30] <CIA-17> ffmpeg: Try clicking with the mouse in the window, hold the button and drag. [01:57:56] <Compn> Try clicking with the mouse in the window, hold the button and drag. [01:57:59] <Compn> madness! [02:07:28] <CIA-17> ffmpeg: michael * r21639 /trunk/ffplay.c: Pretty RDFT audio visulaization. [02:20:12] <Vitor1001> Is it just for me that "ffplay -h" segfaults? [02:21:45] <drv> crashes here too [02:22:06] <Vitor1001> :p [02:24:25] <drv> but hey, what developer ever reads the help? ;) [02:25:55] <Kovensky> now, michael, go worry about actually useful things, like making h264 faster :P [02:26:15] <drv> pretty visualizations are good too [02:33:22] * Compn waits for the day that someone replies via email to the -devel-logs list [02:33:33] <Compn> irc>email interface [02:34:18] <Kovensky> that list was actually made? [03:04:41] <Compn> yes [04:08:41] <justlooking> @''# [04:43:12] <CIA-17> ffmpeg: vitor * r21640 /trunk/ffplay.c: Do not segfault when doing "ffplay -h" [06:40:32] <pJok> mornings [06:40:44] <kshishkov> goda morgnar [06:41:53] * pJok mails kshishkov some swedish snow [06:42:06] <av500> ikea catalogue? [06:42:28] <pJok> those are like the bible, you can find them anywhere in the world [06:42:54] <pJok> sweden looks like a winter wonderland [06:44:50] <kshishkov> av500: would you believe we don't have those either? [06:46:36] <av500> yes [06:47:35] <kshishkov> BTW, I've been near the biggest Ikea store in the world but have't visited any of them so far [06:48:59] <pJok> neat [06:49:16] <pJok> the biggest ikea in sweden is afair the one they are rebuilding at Väla here in skåne [06:50:11] <kshishkov> nej, det ligger i SkÃ€rholmen, Stockholms lan [06:50:27] <pJok> at the moment, yes :P [06:50:57] <pJok> oh its also the worldds biggest [06:50:58] <pJok> neat [06:51:11] <pJok> i did not know that [06:52:38] <kshishkov> also visit SkÃ€rholmen at night to experience Russian life [06:53:42] <pJok> i have no idea when i'll get to stockholm again [06:53:55] <pJok> last time i was just there for a transit to gran canaria [06:54:01] <pJok> and that was nearly a year ago [06:55:16] <kshishkov> and I've been for a transit in MalmÃ¶ once [06:57:41] <pJok> im mostly in malmö for transit [06:57:58] <pJok> since its just a lump of city in the middle of a perfectly good motorway [06:58:20] <pJok> it means that you have to drive nearly three times the distance just to get around it instead of driving through or under [06:58:50] * kshishkov does not drive [07:00:22] <pJok> i do when i need to, usually i just take the train, but its the same story with that [07:00:36] <pJok> at least the citytunnel is ready in 10 months time [07:00:46] <kshishkov> indeed [07:01:13] * kshishkov hates local railroads [07:01:15] <pJok> not that its doing much to my trip to work other than cut 7 minutes off my train time [07:02:22] <kshishkov> http://fc03.deviantart.net/fs32/i/2008/224/4/7/Marxsoft_Windows__Iron_Curta… [07:03:59] <pJok> mmmmh, iron curtain [07:32:43] <Yuvi> is svq1 tested on fate? [07:33:30] <astrange> one file http://fate.multimedia.cx/index.php?test_spec=142 [07:34:19] <astrange> http://fate.multimedia.cx/index.php?test_result=42337938 last frame is being dropped? [07:38:12] <kshishkov> seems so [08:35:47] <DonDiego> What's this fftrollbot thingie? [08:35:59] <kshishkov> IRC logger [08:36:09] <DonDiego> logging to where? [08:36:17] <kshishkov> ffmpeg-devel-irc ML [08:36:34] <av500> so nm can read when he gets flamed [08:36:50] <DonDiego> this was announced where? [08:37:05] <kshishkov> here on IRC, I guess [08:37:05] <Dark_Shikari> the ML and on IRC a few dozen times [08:37:14] <DonDiego> not to me.. [08:37:32] <av500> $topic [08:37:37] <Dark_Shikari> that too. [08:42:58] <DonDiego> ugh, the log is not even in utf-8 .. [08:44:36] <Dark_Shikari> fail [08:45:01] <Dark_Shikari> let's screw with it then. everyone post in katakana! [08:45:11] <kshishkov> ok, you have a chance to see bot developer in person and tell him to fix [08:45:25] <elenril> or we can write like this [08:45:59] <kshishkov> Dark_Shikari: nah, use cyrillic [08:46:37] <Dark_Shikari> ããµããããã¢ã¬ããããã€ã®ããããã®ã€ããã¬ãããŒã€ [08:47:14] <Dark_Shikari> yes, we should all chat using transliterated kana [08:47:57] <superdump> that only works if people can understand it / translate it back to a-z or so [08:48:33] <Dark_Shikari> a-z? >implying that japanese can even represent all the english letters losslessly [08:49:07] <kshishkov> of coulse [08:49:52] <kshishkov> æ¥æ¬èªäœ¿ãé£¯ãããã ã [08:50:27] * kshishkov notes that Japanese input in terminal does not work so good [08:50:39] <Dark_Shikari> what's wrong with it? [08:50:46] <Dark_Shikari> it's no different than outside a terminal [08:50:52] <elenril> your terminal fails? [08:51:08] <Dark_Shikari> but if you mean that japanese input fails i ngeneral, you are correct [08:51:08] <kshishkov> yep, different character width screws displaying here [08:51:14] <kshishkov> of course not [08:51:26] <Dark_Shikari> works fine here in putty [08:51:52] <saintdev> ïŒ€ïœïœïœïŒ¿ïŒ³ïœïœïœïœïœïœïŒãïœïœïœïœãïœïœïœïœïœãïœïœïœïœïŒïœïœïœïœïœãïœïœïœïœïœïœïœïœïœïœïŒ [08:51:55] <kshishkov> but we could use Vietnamese instead [08:52:22] <kshishkov> the same Latin letters with useless marks [08:52:28] <Dark_Shikari> ïœïœïœïœïœïœïœïœïŒãïœãïœïœïœïœïœãïœïœïœïœïœïœïœïœïœïœïŒ [08:56:18] <saintdev> ïœïœ ïœïœïœïœïœïœïœïœïœïœïœïœïœïœïœ ïœïœïœïœïœïœïœïœïœïŒ ïœïœïœïœ ïœïœïœïŒïŒ ïœïœïœïœïœïœïœïŒ [08:57:45] <DonDiego> umlauts: Ã€Ã¶ÃŒ ÃÃÃ [08:57:58] <kshishkov> Vietnamese [08:57:59] <DonDiego> more stuff: Ã Ã± [08:58:11] <twnqx> now Ã is a normal character. [08:58:13] <superdump> ÃŠ [08:58:20] <DonDiego> â¬ [08:58:25] <twnqx> âŠ [08:58:32] <Dark_Shikari> DonDiego: nicht veilleicht mit die Schreibreforme [08:58:48] <twnqx> doch, immer noch, nur seltener. [08:58:51] <kshishkov> á» [08:58:57] <Dark_Shikari> ja ja [08:59:00] <kshishkov> Ä [08:59:23] * superdump needs to map swedish letters to useful keys [08:59:28] <kshishkov> IPA would be even funnier [09:00:21] <kshishkov> superdump: and what's the problem? I can type both Swedish and Russian on my Apple US keyboard [09:00:22] <thresh> indian pale ale? [09:00:40] <saintdev> ïŒ·ïœïœïœ ïœïœ ïœïœïœïœïœïœ ïœïœïœïœ ïœïœ ïœïœ ïœïœ ïœïœïœïœ ïœïœïœ ïŒmichaelïŒ ïœïœ ïœïœïœïœïœ ïœïœïœïœ ïœïœ ïœïœïœ ïœïœïœïœïœïœ ïœïœ ïœïœïœïœ ïœïœïœïŒïŒ [09:01:04] <kshishkov> saintdev: throw H.264 somewhere too [09:02:19] <saintdev> ïŒ¯ïœ ïœïœïœïœ ïœïœïœïœïœïœ ïœïœïœïœïœ ïœïœïœ H.264 [09:02:42] <saintdev> ïŒ²ïœïœïœïœïœ ïœïœ ïœïœïœïœïœïœ ïœïœïœïœïœïœïœïœïœïŒïŒïŒ [09:03:03] <kshishkov> it should be a task for fftrollbot itself [09:05:58] <DonDiego> Dark_Shikari: btw, those patent links you gave me are somewhat too new.. [09:06:15] <saintdev> ïŒ¯ïœ ïœ ïœïœïœïœ ïœïœïœïœïŒ ïœïœïœïœïœïœïœïœïœ ïœïœïœïœïœïœïœïœïœïœ ïœïœïœïœ ïœïœïœïœïœïœïœïœ ïœïœ ïŒ€ïœïœïœ ïŒ¶ïœ ïŒ³ïœïœïœ ïŒïœïœïœ [09:07:06] <kshishkov> saintdev: it's mostly the fact kerning is awful and characters are probably bitmap [09:08:30] <av500> you have to try harder, so far my irrsi session shows all chars ok [09:08:55] <saintdev> ïœïœïœïœïœïœïœïœïœïŒ ïœïœ ïœïœïœïœïœ ïœïœ ïœïœ ïœ ïœïœïœïœïœ ïœïœïœïœïœïœïœïœïœ ïœïœïœïœïŒ ïŒŽïœïœïœ ïœïœïœïœ ïœïœ ïœïœ ïŒ€ïœïœïœ ïŒ¶ïœ ïŒ³ïœïœïœ ïŒïœïœïœïŒïœïœïœïœïŒ [09:08:59] <kshishkov> av500: probably not in log [09:09:33] <saintdev> ïŒŽïœïœïœ ïœïœïœïœ ïœïœïœïœ ïœ ïœïœïœïœïœïŒïœ ïœïœïœïœïœïœïœïœïœïœïœ [09:12:13] <superdump> they look fine in my logs [09:12:30] <kshishkov> superdump: look at yesterday log on ML [09:13:49] <saintdev> ïœïœïœïœïœïœïœïœïœïŒ ïœïœïŒïœïœ ïœïœïœïœïœïœïœ ïœïœïœïœ ïœïœïœïœïœïœïœïœïœïœ ïŒïœïœïœïœïœïœïŒïœïœïœïœïœïŒïœïœïœ ïŒïŒ¬ïŒïŒ ïœïœïœ ïœïœ ïœïœïœïœ michael [09:14:12] <superdump> mostly fine, some garbled crap [09:15:06] <saintdev> ïœïœïœïœ ïœïœïœïœïœïœïœ ïœïœïœïœ ïœïœïœïœ ïœïœïœïœïœïœïœ ïœïœ ïœïœ ïœïœïœïŒïŒïŒïŒïŒ [09:15:20] <superdump> kshishkov: i guess i want something like alt gr + a is a with a circle on top, alt gr + e is a with diaresis and alt gr + o is o with diaresis [09:16:01] <saintdev> ïœïœïœïœïœ ïœïœ ïœïœïœïœïœïœïœïœ ïœïœïœ ïœïœïœïœïœïœïœïœïœ ïœïœïœïœïœïœïœïœïœïœ ïŒïœ [09:16:04] <superdump> i'll xmodmap it [09:16:40] <superdump> currently i get ÃŠeÃž [09:16:45] <superdump> respectively [09:17:06] <kshishkov> seems Danish [09:17:28] <superdump> mmm [09:17:46] <superdump> is there any better way to switch the level 3 chars about than manually doing it with xmodmap? [09:18:03] <superdump> i guess i could hack an xkb layout or something [09:18:09] <saintdev> superdump: yes, forget what's called, though [09:20:08] <saintdev> it's the one where you can press the key, then the keys that it looks like [09:20:52] <saintdev> æ = <whateveritscalled>, a, e [09:21:34] <saintdev> compose key! [09:22:07] <superdump> compose key? [09:22:16] <superdump> which key is that? [09:22:18] <saintdev> https://help.ubuntu.com/community/ComposeKey [09:22:30] <saintdev> meh, that's not the good article [09:22:52] <saintdev> erm wait, yeah it is, just have to skip to #5 [09:23:44] <saintdev> Shift+AltGr, <key1>, <key2> [09:25:50] <superdump> doesn't work too reliably [09:26:14] <saintdev> for me it did, but I had to set it to something non-default [09:26:29] <saintdev> and i don't use gnome/ubuntu [09:28:08] <saintdev> anyway, off to bed. [09:41:34] <elenril> anyone knows where i can find specs for avi metadata? [09:43:30] <mru> what metadata? [09:43:36] <mru> the I* tags? [09:43:54] <elenril> yes [09:43:55] <superdump> Ã¥ÃÃ€ÃÃ¶Ã [09:43:58] <superdump> winner [09:44:05] <superdump> MÃ¥ns [09:44:12] <superdump> </tribute> [09:44:25] <mru> ;-) [09:44:29] <kshishkov> elenril: wiki.multimedia.cx has links to AVI specs [09:50:13] * elenril kicks m$crosoft [09:50:26] <elenril> found a huge list of tags on some random page, but nothing official [09:51:27] <mru> there is nothing official [09:51:34] <kshishkov> it's "extensible" - you can have a cartload of tags invented purely by yourself [09:51:50] <elenril> pure w00tness [09:53:02] <elenril> well microsoft docs mention a few of them, so i'd expect a list somewhere [09:54:19] <av500> mru: eta tomorrow morning [09:54:55] <av500> mru: somehow 3 of the 6 do not like 1280x1024 (from an A5) dunno if it is better from BB, so be prepared to run 1024x768 [09:55:04] <mru> ok [09:55:36] <av500> less stress on the sdram anyway :) [09:55:42] <av500> mru: u have content? [09:55:45] <mru> yes [09:55:50] <mru> got 2 more beagles? [09:55:53] <av500> yes [09:55:59] <mru> all good then [09:56:04] <mru> I'll pick up some sd cards today [09:56:18] <av500> I have one 6x extension cord, so I need 1 free plug for my part [09:56:57] <av500> try to secure something sturdy to place this on, this beast is heavy (60pounds) [10:04:08] <kshishkov> av500: there's always floor [10:04:27] <av500> yes [10:04:36] <av500> floor is plan B [10:04:52] <av500> destroy fosdem wall with power drill was plan A [10:14:36] <elenril> but everything starting with I should be an info tag, right? [10:14:53] <kshishkov> not necessarily [10:15:59] <elenril> counterexamples? [10:16:10] <av500> ipad [10:16:49] * elenril shoots av500 [10:16:58] <elenril> besides that's 'i', not 'I' =p [10:19:59] * DonDiego packs for FOSDEM [10:20:02] * elenril looks at mplayer's demuxer [10:20:20] <mru> ipad is obviously for padding [10:20:24] <mru> padding metadata, that is [10:20:42] * elenril head explodes [10:20:55] <mru> idx1 als isn't an info tag [10:20:58] <mru> *also [10:21:14] <av500> mru: it informs you of where nice video frames are [10:21:48] <mru> elenril: why don't you come to fosdem? [10:21:56] <elenril> exams? [10:22:04] <elenril> no money? [10:22:14] <av500> fix a bug, get money [10:22:23] <elenril> that's still all 'i', not 'I' [10:25:14] <elenril> o_0 read_avi_header() 673 lines [10:30:35] <mru> elenril: what about Ä±pad? [10:31:30] <elenril> ? [10:32:35] <mru> or Ä° [10:33:16] <av500> Ïpad [10:34:20] <av500> ÐžÐ¿Ð°ÐŽ [10:34:43] <thresh> unag, you say? [10:35:09] <elenril> http://www.alliednetservices.com/clipart/ipad.jpg ? [10:35:24] <mru> http://www.youtube.com/watch?v=8eF0y0IfpPU [10:36:14] <av500> thresh: do I? [10:39:25] <thresh> at least the letters look similar using terminus [11:25:12] * elenril loves it when sdl crashes x [11:26:07] <kshishkov> think about WIndows then [11:26:09] <elenril> does AV_WB32 do what i think it does? [11:26:28] <kshishkov> depends on your thoughts [11:26:42] <kshishkov> if you think it writes 32 bit-endian integer then yes [11:26:50] <CIA-17> ffmpeg: michael * r21641 /trunk/ffplay.c: [11:26:50] <CIA-17> ffmpeg: Scale rdft vissualization up by 2 so theres no unused space on the top [11:26:50] <CIA-17> ffmpeg: but rather the unimportant high frequencies are cut off if the window is [11:26:50] <CIA-17> ffmpeg: not a multiple of 2 high. [11:27:32] <kshishkov> EComprehensionError [11:30:51] * elenril sighs [11:30:54] <elenril> this avi stuff is amess [11:31:05] <kshishkov> yes [11:31:42] <elenril> hmm, apparrently avidec can't read metadata written by avienc [11:31:56] <kshishkov> why should it? [11:32:26] <av500> what is the longest chain of mux demux with different format that lavf can handle :) [11:32:29] <elenril> why not [11:34:12] <av500> mru: ping [11:34:34] <kshishkov> elenril: you've looked at this? http://abcavi.kibi.ru/infotags.htm [11:34:52] <elenril> yes, found it an hour ago [11:36:21] <elenril> i think i'll just try to read everything that starts with 'I' as an info tag [11:39:41] <kshishkov> heh, no luck [11:39:45] <kshishkov> read ODML specs [11:39:58] <kshishkov> http://www.the-labs.com/Video/odmlff2-avidef.pdf [11:40:18] <kshishkov> section "Microsoft-Defined Tombstone Data" [11:43:14] <elenril> we don't read/use this ISMP thing anyway [11:43:26] <kshishkov> nor metadata :P [11:43:49] <elenril> so it won't break anything [11:51:34] <CIA-17> ffmpeg: michael * r21642 /trunk/libavformat/avidec.c: Correcting wrong looking stream_id validity check in avidec. [11:51:48] <elenril> o_0 [11:55:31] <superdump> :) [12:17:52] <CIA-17> ffmpeg: michael * r21643 /trunk/libavformat/avidec.c: Support strn tag in avidec. [12:19:34] <elenril> srsly wtf [12:20:10] <kshishkov> what, you don't like the fact someone is working at improving AVI demuxer? [12:21:50] <elenril> no, he just picked a weird time for that [12:22:25] <elenril> now i'll get ten million conflicts [12:23:15] <kshishkov> so, some of you should have done his work earlier [12:23:42] <superdump> elenril: maybe send him an e-mail and ask him what he's working on and talk about what you're working on [12:23:54] <superdump> maybe he can give you some pointers and let you do the work rather than doing it himself [12:24:00] <superdump> and then he can look at something else [12:24:36] <kshishkov> yeah, like Ð.264 [12:26:29] <elenril> yeah or i can ask him to admit he's hiding here :) [12:27:05] <kshishkov> he's hiding at former capital of your country [12:28:04] <elenril> my country: destination not found [12:29:06] <kshishkov> .cz [12:30:04] <elenril> not really my country -- my papers stilll say i'm ukrainian :( [12:30:34] <kshishkov> do you feel that Ukraine is your country? [12:30:37] <thresh> now now want to change your nationality mister? [12:30:58] <elenril> ofc not [12:31:00] <kshishkov> citizenship at least [12:31:27] <elenril> thresh: you don't? [12:31:48] <kshishkov> at least I don't feel that Ukraine is my country and I'm really Ukrainian [12:31:53] <thresh> i don't really know [12:31:59] <thresh> probably the same as kshishkov [12:32:04] <thresh> although i miss Russia when i'm away [12:32:48] <kshishkov> I miss Sweden [12:33:10] <thresh> i didnt really like any of places i've been too [12:33:13] <thresh> -o [12:33:38] <elenril> chocolateland is nice [12:33:46] <thresh> well except for mountains and i couldnt live there because there are no large cities in there [12:34:02] <elenril> large cities ftl [12:34:16] <kshishkov> thresh: you live in a small town [12:34:21] <thresh> yeah, called Moscow [12:34:40] <kshishkov> really? I was thinking it's outside Moscow border [12:35:06] <thresh> yeah, 5 km away from mkad [12:35:20] <av500> walking distance [12:35:43] <kshishkov> thresh: and it's not Zelenograd either :P [12:36:20] <kshishkov> av500: true, you can only _walk_ there [12:36:29] <thresh> exactly [12:36:58] <thresh> trains are overcrowded, the only road has huge traffic jams [12:37:37] <Compn> its not that big cities themselves are the good part, but they attract the international foods/shops which are better than small town shops ? ehe [12:37:55] <Compn> of course, big cities have more entertainment ... [12:38:00] * elenril thinks those are overrated [12:38:09] <thresh> yes, i only care about entertainment in Moscow [12:56:09] <DonDiego> does chromium support h264? [12:56:15] <DonDiego> or just google chrome? [12:56:30] <DonDiego> both use ffmpeg iirc, but i forget how they built it.. [12:56:41] <DonDiego> does anybody remember the links to the repo? [12:59:16] <jez9999> anyone know where BBB is? [12:59:25] <jez9999> he been online recently? [13:01:26] <janneg> http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob;f=third_pa… [13:01:31] <janneg> DonDiego: ^^^ [13:02:04] <janneg> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ [13:03:23] <janneg> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.… [13:03:54] <janneg> for chromium all except --enable-decoder=theora --enable-decoder=vorbis --enable-demuxer=ogg is disabled [13:04:26] * elenril just realized he's been muxing flac to avi for about half an hour [13:04:32] <elenril> and it works o_0 [13:28:20] <superdump> Dark_Shikari: http://gunshotfx.com/libavcodec/ [14:06:43] * superdump wonders why we hadn't added a link to fate from ffmpeg.org yet... [14:07:29] <kshishkov> devs know, nobody else cares [14:15:36] <Compn> superdump : you can commit to ffmpeg.org repo at any time :P [14:15:48] <superdump> indeed i shall [15:16:01] <CIA-17> ffmpeg: michael * r21644 /trunk/libavformat/avienc.c: [15:16:01] <CIA-17> ffmpeg: strn muxing in avi support. [15:16:01] <CIA-17> ffmpeg: untested as ffmpeg.c has no means to set AVStream metadata (patchwelcome) [15:17:30] <CIA-17> ffmpeg: michael * r21645 /trunk/ffplay.c: [15:17:30] <CIA-17> ffmpeg: Make sure the rdft has enough audio available. [15:17:30] <CIA-17> ffmpeg: 10l (looks cleaner now) [15:19:39] <merbzt> elenril: suck t [15:19:42] <merbzt> o bye you :) [15:19:48] <merbzt> be you [15:20:03] <merbzt> now the avi muxer supports the I meta data flags [15:20:33] <kierank> next thing we know he'll just RE that neyrink software and write the decoder and also an encoder [15:20:44] <superdump> neyrink? [15:21:12] <kierank> company that makes the dolby encoders [15:21:17] <kierank> whole suite of them iirc [15:21:23] <elenril> srsly this is getting annoying [15:21:26] * elenril kicks sdl [15:22:11] <elenril> merbzt: lol [15:23:02] <kshishkov> kierank: why they are called "dolby" then? [15:23:09] * elenril wonders how is he supposed to store utf-8 in avi [15:23:22] <kshishkov> you are not supposed to do that [15:23:55] <kshishkov> it's Windows way - either UCS16 or local codepage [15:24:05] <kshishkov> I'd bet on the second [15:24:12] <av500> kshishkov: avi supports UCS16? [15:24:31] <merbzt> elenril: does your metadata work enable the tags to follow the file as you transcode files to other containers ? [15:24:43] <kierank> [15:23] <@kshishkov> kierank: why they are called "dolby" then? --> because dolby only do hardware [15:24:45] <kshishkov> av500: I doubt it, but it's more likely than utf-8 [15:24:54] <kierank> also they should be known as trollby [15:25:07] <av500> kshishkov: for sure, but i guess when they made it up they had ascii in mind [15:25:08] <elenril> kshishkov: :effort: to implement in ffmpeg [15:25:09] <kierank> for keeping shit like ac-3 in the market [15:25:13] <kshishkov> who wrote that ATSC A/52 codec then? [15:25:43] <kierank> I mean hardware as in hardware encoders [15:25:50] <elenril> merbzt: that should work even now [15:26:13] <kierank> hmm apparently dolby do software [15:26:19] <kshishkov> elenril: to cheer you up a bit - it sucks even more to be _me_ [15:26:35] <elenril> heh [15:27:15] <elenril> i still find it weird that codec companies aren't fighting over you with your experience [15:27:31] <CIA-17> ffmpeg: michael * r21646 /trunk/ffplay.c: [15:27:31] <CIA-17> ffmpeg: make the RDFT vissualizatiom default, the scopes are ugly and eat CPU like [15:27:31] <CIA-17> ffmpeg: piranhas. [15:27:44] * kshishkov is not sure how to treat possible invitation from Buffering Inc. though [15:28:07] <kierank> LOL [15:28:43] <kierank> reply every minute with Buffering....5%, etc [15:28:51] <Dark_Shikari> piranhas [15:28:51] <Dark_Shikari> lol [15:29:15] <Dark_Shikari> elenril: they don't seem to be interested in people with actual skills [15:29:18] <elenril> rdft? [15:29:34] <Dark_Shikari> I haven't received one invitation from a codec company [15:29:37] <Dark_Shikari> well, encoder, at least [15:29:38] <kshishkov> real-part discrete Fourier [15:29:42] <elenril> o_0 [15:30:03] <elenril> you worked for corecodec, right? [15:30:05] <kshishkov> Dark_Shikari: you seem to have some ties to DivX and CoreCodec though [15:30:19] <Dark_Shikari> divx? lol [15:30:27] <Dark_Shikari> unless by ties you mean "we crashed their halloween party and routinely make fun of them" [15:30:31] <Dark_Shikari> corecodec doesn't do encoders [15:30:41] <kshishkov> yes [15:30:56] <kierank> they said they were going to make an h.264 encoder at one point [15:31:02] <Dark_Shikari> kierank: if they release one, it will be x264 [15:31:05] <elenril> kshishkov: real-part? [15:31:16] * elenril should read about discrete ft sometime [15:31:22] <kshishkov> elenril: yes, no imaginary part of complex numbers [15:31:54] <kshishkov> elenril: all Fourier transforms around here are discrete - no analogue transforms in digital world [15:31:57] <elenril> we defined ft only from R->R [15:31:58] <av500> kshishkov: so they only way to lure you out of .ua is an encoder job? [15:32:14] <kshishkov> av500: no, almost any job really [15:33:01] * elenril had integral transformations this semester [15:33:20] <kshishkov> av500: and it's not "lure", it's mostly "give a possibility to escape from .ua" [15:33:23] <superdump> Dark_Shikari: did you see the continuation of that h.264 decoding thread on -user? [15:33:31] <superdump> the guy posted a sample on the page now [15:33:31] <av500> kshishkov: I know :) [15:33:36] <Dark_Shikari> idiots being idiots? [15:33:43] <superdump> so maybe we can check it and tell him what he's doing wrong [15:34:00] <elenril> what thread? [15:34:03] <kshishkov> elenril: and I had nothing regarding transforms [15:34:33] <kshishkov> elenril: not thread, webpage telling lavc H.264 decoder sucks in colours [15:34:40] <superdump> elenril: one about h.264 decoding being inferior in libavcodec compared to quicktime, final cut, adobe after effects and so on [15:34:56] <elenril> obvious troll is obvious [15:35:43] <av500> superdump: also inferior to th***? :) [15:35:43] <kshishkov> superdump: would be funnier if it turned out to be inferior to Perian, FFdshow and VLC [15:36:04] <superdump> it would be funnier, yes [15:36:12] <superdump> i don't think it's trolling [15:36:23] <superdump> i think it's rather something to do with the way they're handling the decoder output [15:36:30] <superdump> that differs from what is going on with quicktime [15:36:45] <superdump> from the screenshots it almost looks like quicktime is adding noise [15:37:18] <kierank> microsoft does that with mpeg-4 asp iirc [15:37:30] <kierank> postprocessing you can't turn off [15:37:51] <kshishkov> "film corn"? [15:38:06] <superdump> kierank: they do it with wmv [15:38:18] <superdump> i think you can turn it off with some registry settings [15:38:33] <superdump> i don't think i've looked at that in about 8 years [15:38:36] <superdump> lol [15:38:36] <kshishkov> superdump: Th***a does that too [15:38:52] <superdump> theora's deblocking is in-loop, no? [15:39:32] <kshishkov> no, it also employs postprocessing [15:39:50] <kshishkov> deringing, another deblocking, something else [15:40:09] <Yuvi> superdump: yes, similar loop filter to h.263's [15:40:44] <Dark_Shikari> any chance we can ban those trolls from the ML? [15:41:30] <superdump> Dark_Shikari: which trolls? [15:41:36] <Dark_Shikari> the ffmpeg-user ones [15:41:41] <superdump> i would rather figure out what the problem is and conclude the issue [15:41:50] <superdump> so that if it happens again we can point people to it [15:42:05] <Dark_Shikari> they won't [15:42:06] <kshishkov> Dark_Shikari: so you _read_ that list? [15:42:09] <Dark_Shikari> they refuse to listen to any answers [15:42:10] <ohsix> Dark_Shikari: http://rationalwiki.com/wiki/Special_pleading [15:42:11] <Dark_Shikari> therefore, they are trolls [15:42:14] <Dark_Shikari> therefore, they should be banned [15:42:19] <superdump> refuse to listen to any answers? [15:42:22] <superdump> bullshit [15:42:29] <Dark_Shikari> superdump: read the thread [15:42:32] <superdump> i did [15:42:35] <superdump> i've been following it [15:42:40] <Dark_Shikari> they still do not understand what H.264 is [15:42:48] <Dark_Shikari> despite having been told by multiple professionals [15:42:55] <ohsix> you dont listen all that much either Dark_Shikari, i'd just duck out if i were you [15:42:58] <Dark_Shikari> they follow the "I'm right, everyone else is wrong" methodology [15:43:30] <superdump> you're not listening to what they're saying - we know the decoder output is identical [15:43:31] <kierank> lol at that guy who says you can choose to deblock [15:43:35] <superdump> or it should be [15:43:39] <Dark_Shikari> superdump: but that isn't what the guys I responded to are saying [15:43:41] <Dark_Shikari> read again! [15:43:47] <Dark_Shikari> they insist the deblocker is not only optional [15:43:52] <Dark_Shikari> but can be performed validly in whatever way the decoder wants [15:44:02] <Dark_Shikari> and the reason lavc is worse is because "it's deblocking too strong" [15:44:34] <kshishkov> give them autoinserted pp filter! [15:44:50] <kshishkov> s/pp/shapness+gauss noise/ [15:45:09] <superdump> he's confused and you're not willing to listen and try to figure out what's wrong [15:45:21] <Dark_Shikari> I already know what's probably wrong [15:45:25] <Dark_Shikari> 99% chance, it's a colorspace conversion issue [15:45:31] <Dark_Shikari> however, he won't listen to me when I told him that [15:45:45] <elenril> crap, i just did git commit --amend instead of git rebase --continue [15:45:47] <Dark_Shikari> he is absolutely, utterly convinced that libavcodec must be wrong [15:45:47] <superdump> he did listen and he's been trying to figure that out code-wise [15:45:52] <elenril> any way to undo it? [15:45:54] <Dark_Shikari> Then why is he still claiming the deblocker is wrong? [15:46:12] <Dark_Shikari> You may be talking about a different "he" [15:46:19] <superdump> because he doesn't understand [15:46:28] <Dark_Shikari> um, but you said he did listen [15:46:35] <Dark_Shikari> and he's "trying to figure out" the colorspace conversion [15:46:49] <Dark_Shikari> how can he have "listened" and be "trying to figure out" the colorspace conversion _while_ believing that the deblocker is wrong? [15:46:49] <superdump> he listened, but that doesn't mean he suddenly understands how to fix the problem [15:46:55] <Dark_Shikari> I didn't say that. [15:47:01] <Dark_Shikari> If he listened, he should know what _isn't_ the problem [15:47:13] <Dark_Shikari> considering part of what he should have listened to included an explanation of why that isn't the problem [15:47:17] <Yuvi> elenril: git reflog, find the unammended commit, do a diff to the current head [15:48:03] <superdump> in his last e-mail with the updated test after i'd told him about the swscale stuff and you'd told him about the bit exactness of decoding, thomas didn't say anything about deblocking being the issue [15:48:26] <superdump> he pointed to some flags in swscale that seemed relevant that he's been playing with [15:48:33] <superdump> but he still has some issue with that [15:48:44] <Yuvi> not entirely sure how that'll interact with the rebase though [15:48:44] <Dark_Shikari> um, did you read what I quoted in my emails?! [15:48:51] <Dark_Shikari> I quoted him saying exactly what you said he didn't say [15:48:54] <superdump> i haven't read your last e-mail yet [15:49:48] <superdump> i was referring to his last e-mail, not that one you responded to [15:51:28] <elenril> hmm, maybe i'll just do a soft reset+add+rebase --continue [15:54:15] <superdump> Dark_Shikari: i was hoping that you'd have some humility and focus on what the problem might be rather than jumping all over their ignorance of how h.264 works [15:54:43] <Dark_Shikari> superdump: ignorance is fine [15:54:45] <Dark_Shikari> I have no problem with ignorance [15:54:46] <superdump> rather than expending effort being destructive, why not be constructive [15:54:46] <Dark_Shikari> I never have [15:54:52] <Dark_Shikari> I have a problem with arrogance [15:54:57] <Dark_Shikari> with people who insist that they are right, despite being ignorant [15:54:57] <superdump> clearly [15:55:11] <Dark_Shikari> ignorance is fine as long as you realize you are ignorant and are willing to learn [15:55:25] <Dark_Shikari> but the instant you start insisting that your ignorant opinion is right and every professional in the world is wrong [15:55:33] <Dark_Shikari> I instantly lose every last bit of caring for your position. [15:56:28] <superdump> aren't you interested in having some provable way to use ffmpeg to provide output that is identical to quicktime/final cut pro/adobe after effects/whatever other widely used tool one might stumble across? [15:56:31] <Dark_Shikari> Yes [15:56:33] <Dark_Shikari> of course I am [15:56:40] <Dark_Shikari> that's why I went out of my way to explain how ffmpeg worked [15:56:44] <Dark_Shikari> and the difference between libavcodec and swscale [15:56:48] <Dark_Shikari> and the difference betwee yuv and rgb [15:56:58] <Dark_Shikari> and at what stage the difference occurs [15:57:02] <Dark_Shikari> and why it owuld occur [15:57:04] <Dark_Shikari> and what the proble might be [15:57:06] <Dark_Shikari> *problem [15:57:13] <Dark_Shikari> is this still not enough? [15:57:54] <superdump> feel free to discontinue your involvement in the thread if you're not interested in figuring out how to manage the correct configuration of swscale [15:58:10] <Dark_Shikari> and people wonder why nobody wants to help on ffmpeg-user [15:58:16] <Dark_Shikari> support people are treated like utter shit [15:58:43] <Dark_Shikari> if anyone so much as gets together and helps someone, they get flamed [15:58:57] <Dark_Shikari> the more useful information they post, the more they get flamed [15:59:03] <Dark_Shikari> in the end, you end up with an ML full of unanswered questions [15:59:08] <Dark_Shikari> because nobody wants to help. [15:59:18] <superdump> maybe the people requesting support would be receptive to correction and information about why they're wrong if they're provided with a solution for their problem first [15:59:34] <Dark_Shikari> I already told them the problem: it's a BT.709 vs BT.601 issue [15:59:38] <Dark_Shikari> this is a long-standing problem with swscale [15:59:48] <superdump> one that i think can be worked around [15:59:57] <Dark_Shikari> it doesn't pass BT.601/BT.709 flags correctly from libavcodec [16:00:24] <superdump> http://git.ffmpeg.org/?p=libswscale;a=blob;f=utils.c;h=928a5fd85e5480dbbb00… [16:00:27] <superdump> no [16:00:30] <superdump> but maybe one can code something to do it [16:01:01] <Yuvi> hm, did I not apply my patch series [16:01:06] <Yuvi> not that it'd probably help in this case [16:01:09] <superdump> and [16:01:11] <superdump> http://git.ffmpeg.org/?p=libswscale;a=blob;f=swscale.h;h=9e14262d30f4311ef7… [16:01:35] <Dark_Shikari> btw, 601 is used for SD and 709 for HD, right? [16:01:49] <kierank> yes [16:01:55] <superdump> i think if one called getContext first and then called that function afterwards with the correct parameters, it would work correctly [16:02:05] <superdump> according to wikipedia at least, yes [16:02:25] <superdump> i was thinking maybe we could autodetect within get context and set the right option rather than just using default [16:02:29] <Yuvi> whoops, michael approved them (for this) but I never pushed [16:02:40] <superdump> or maybe expose the available options in sws [16:02:56] <superdump> Yuvi: you have options for controlling whether BT.601/709 are being used? [16:03:22] <elenril> hmm, this new visualisation is nice [16:04:34] <Yuvi> superdump: yeah, not too user friendly though since it needs -colorspace 4 or something like that to manually change it [16:04:45] <Yuvi> let me find them and push [16:04:55] <superdump> well, we can fix that up pretty easily i guess [16:04:59] <superdump> add an option somewhere [16:05:34] <superdump> Yuvi: but, if it's at all doable, that's great [16:07:47] <Dark_Shikari> superdump: there, that better? [16:09:49] <superdump> yes [16:09:53] <superdump> thank you very much :) [16:10:05] <superdump> that's precisely the kind of answer i was looking for [16:13:24] <superdump> Yuvi: are you having any luck finding them? [16:14:14] <Yuvi> http://pastebin.com/m6f194a37 just need to double check a concantenated fullrange -> mpeg range and back conversion [16:14:42] <superdump> cool [16:15:23] <superdump> in this case i think BT.709 is 16..235 [16:15:33] <Dark_Shikari> fullrange and 709/601 are independent iirc [16:15:42] <Dark_Shikari> you can have any of the 4 possible combinations [16:16:05] * elenril wonders why doesn't ffplay exit at EOF [16:16:13] <elenril> is this a bug or a feature [16:16:17] <kshishkov> feature [16:16:27] <kshishkov> useful for image viewing [16:16:32] <elenril> oh [16:16:35] <kshishkov> and seeking back [16:18:16] <superdump> Dark_Shikari: in terms of coefficients and full-/mpeg-range being orthogonal, definitely [16:18:47] <Vitor1001> anyone thinks that quicktime is doing some pos-processing behind users back? [16:18:49] <superdump> but in terms of the specs, i think BT.601 and BT.709 also define the range as 16..235 as well [16:18:53] <superdump> but maybe i'm wrong [16:18:58] <superdump> Vitor1001: possibly, yes [16:19:01] <Vitor1001> it looks like at least they are adding noise [16:19:04] <superdump> the quicktime images look noisier [16:19:08] <superdump> yup [16:19:14] <Vitor1001> looks like a valid lavfi feature request [16:19:17] <superdump> honestly, it does look better [16:19:33] <Vitor1001> "-vfilters happy_machead" [16:19:34] <superdump> to my eyes [16:19:37] <superdump> lol [16:20:21] <Dark_Shikari> superdump: that's not exactly news, vorbis has been doing it for years ;) [16:20:26] <jai> lol [16:20:45] <superdump> dithering? [16:21:34] <Dark_Shikari> no [16:21:36] <Dark_Shikari> noise [16:21:45] <Dark_Shikari> not merely diterhing helps perceptual quality [16:21:46] <Dark_Shikari> noise does too [16:21:53] <Dark_Shikari> because of the energy preservation idea [16:22:01] <kshishkov> noise, dithering, what's the difference? [16:22:11] <Dark_Shikari> dithering covers up lack of bit depth [16:22:14] <Dark_Shikari> it is extremely limited [16:22:16] <Dark_Shikari> and +/-1 only [16:22:21] <Dark_Shikari> noise is much stronger [16:28:19] <superdump> ah, i see [16:28:23] <superdump> that's interesting [16:28:28] <superdump> Dark_Shikari: added decoder-side? [16:29:41] <Dark_Shikari> superdump: no, probably after the decoder [16:29:50] <Dark_Shikari> or are you talking about vorbis? [16:32:30] <superdump> vorbis [16:33:13] <Dark_Shikari> vorbis adds it on encoder-side [16:33:19] <Dark_Shikari> CELT adds it decoder-side as part of dequantization [16:33:50] <superdump> interesting indeed [16:33:59] <superdump> well, whatever aids lossy compression :) [16:34:07] <Dark_Shikari> the reason vorbis doesn't do decoder-side is that they didn't realize it until after bitstream being frozen [16:34:20] <superdump> they didn't realise what? [16:34:27] <superdump> they were adding noise? [16:35:52] <Dark_Shikari> that conserving energy was the single most important psy optimization [16:39:08] <superdump> :) [16:39:21] <superdump> ain't physics great? [16:39:41] <kshishkov> looking at people in general - it ain't [16:40:23] <superdump> Yuvi: looking at that patch you pasted, that'll work if the decoder can set the correct colour space/standard/whatever you want to call it [16:40:55] <superdump> so then we need to make sure it's right and/or accessible in ffmpeg [16:41:02] <superdump> you said there's a -colorspace option? [16:41:07] * superdump looks at the help output [16:41:25] <superdump> yup [16:41:28] <superdump> right [16:43:04] <CIA-17> libswscale: conrad * r30513 /trunk/libswscale/ (swscale.h yuv2rgb.c): Add function to translate SWS_CS_* to coefficient array [16:52:46] <Yuvi> superdump: yep, only mpeg2, h.264, and theora export that atm, dunno how many more codecs could set it [16:53:35] <Yuvi> and it looks like swscale doesn't support this for yuv -> yuv or rgb -> yuv, only yuv -> rgb [16:59:29] <superdump> ok [16:59:48] <superdump> so for RGB input we can't choose BT.709? [17:00:00] <superdump> does it just assume BT.601? [17:00:27] <Yuvi> I think so [17:11:49] <elenril> anyone knows if nut tags are case sensitive? [17:15:52] <kshishkov> nut spec should know [17:16:58] <elenril> it doesn't [17:17:23] <elenril> ie it doesn't say anything => they're case sensitive [17:17:28] <elenril> but that's braindead [17:17:50] <elenril> so i'd rather assume someone just forgot to write it [17:51:24] <Compn> intel guy didnt give me a list of supported boards either [17:51:38] <Compn> Yes, this GPU is only on Atom boards but not all Atom boards have this. By lspci you can find out how the video is enabled. If the VGA compatible controller shows SCH Poulsbo then you know it uses SGX core. [17:53:58] <elenril> ah, that evil proprietary crap :) [17:54:32] <elenril> iirc gma x4500 have vaapi support too [17:57:19] <Compn> arent they all proprietary? [17:57:24] <Compn> nvidia, ati and intel ? [17:59:15] <elenril> intel is free [17:59:26] <elenril> except for this gma 500, but it's not really intel [18:08:42] <iive> well, most users with video driver problems have intel, yesterday somebody had problem with intel audio card... i've personally reported bugs for intel lan cards, and i'm not sure if the fix/workaround hit mainstream... [18:09:20] <kshishkov> +1 for realtek? [18:09:27] <elenril> intel doesn't make audio cards afaik [18:09:40] <iive> no, they embed everything [18:09:48] <kshishkov> Centrino FTW [18:09:55] * superdump has an intel gma h4500mhd [18:10:02] <superdump> erm [18:10:06] <elenril> these "intel" cards have realtek chips [18:10:10] <elenril> or something like that [18:10:13] <superdump> i swear i typed x4500mhd [18:10:16] <superdump> in my head [18:10:19] <superdump> :) [18:16:37] <elenril> did location of preset change recently? [18:18:08] <Kovensky> <+elenril> intel doesn't make audio cards afaik <-- the hdaudio spec is from them IIRC [18:18:16] <elenril> i know [18:18:30] <Kovensky> < iive> well, most users with video driver problems have intel <-- and sis, and via... [18:18:32] <elenril> but afaik they don't actually make any cards [18:19:04] <iive> Kovensky: sis anv via... i can't remember last time somebody got that... [18:19:35] <Kovensky> well, sis users can't have sis video driver problems, there ISN'T a video driver [18:19:52] <elenril> my sister has a via card [18:20:31] <elenril> official drivers are pretty much nonexistent, openchrome is very slow, doesn't support 3d, etc [18:20:52] <kshishkov> wanna Trident video with 512kB RAM? [18:21:09] <elenril> intel drivers have some problems, but they're _much_ better than via [18:21:20] <iive> elenril: intel doesn't make any standalone video cards, yet they own more than half of the market. [18:21:36] * Kovensky would be glad to have an intel igp [18:21:46] <elenril> iive: i was talking about audio cards [18:21:55] <iive> ever heard of ac97? [18:22:11] <elenril> afaik they do manufacture gma [18:22:19] <elenril> sure, so? [18:22:45] <kshishkov> elenril: developing, producing and labeling are 3 separate stages [18:22:51] <iive> it's intel invention. i'm not sure what hda is, but every kernel patch have a lot of changes in it. it's intel too. [18:23:12] <Kovensky> aren't the gma by imagine systems? [18:23:30] <elenril> kshishkov: i know that =p [18:23:59] * elenril kicks ffmpeg for 'av_interleaved_write_frame(): Error while opening file' [18:24:43] <elenril> Despite similarities, Intel's main series of GMA IGPs is not based on the PowerVR technology Intel licensed from Imagination Technologies [18:24:48] <elenril> ^wikipedia [18:25:09] <kshishkov> and I thought PoverVR is for embedded devices [18:26:32] <iive> it is bad idea to accept everything wikipedia says as undoubtful truth [18:26:58] <kshishkov> yes, look what they wrote about Bink [18:27:14] <kshishkov> has someone seen wavelets in it? [18:27:24] * iive points at kshishkov [18:27:44] <elenril> kshishkov: add them ;) [18:28:01] <elenril> btw when are you finally going to commit bink decoder? :) [18:28:12] <kshishkov> when it's reviewed :P [18:29:08] * kshishkov thinks whom to kick for final Indeo 5 decoder review [18:33:13] <elenril> indeo? who uses that? [18:33:26] <iive> there are a lot of legacy videos with it. [18:33:32] <iive> some of them from games. [18:34:01] <kshishkov> not so popular as Indeo 4 for some reason though... [18:34:14] <elenril> everybody switched to bink ;) [18:36:47] <kshishkov> we don't have decoder for it either :P [18:43:04] * elenril wonders if it'll be possible to steal matroska index writing code for nut [18:43:39] <kshishkov> why? [18:43:53] <elenril> because i'm too lame to write it from scratch [18:44:19] <Yuvi> the nut muxer doesn't write an index? [18:44:30] <kshishkov> it does not [18:44:30] <elenril> afaik no [18:44:34] <kshishkov> not lavf one [18:44:41] * kshishkov recodes into nut now [18:44:51] <elenril> (but now it writes all metadata :) ) [18:45:03] <Yuvi> huh, I thought the spec pretty much required one for files not intended to be streamed live [18:45:26] <kshishkov> still, lavf does not create index for them [18:46:03] <elenril> An index packet to facilitate O(1) seek-to-time operations may follow [18:46:10] <elenril> not required [18:47:37] <kshishkov> I'd like it to store real duration time instead [18:48:04] <elenril> i think it's stored in index [18:48:13] <kshishkov> lol [18:48:17] <elenril> at least if i understood the specs [18:59:35] <elenril> wtf does dereferencing type-punned pointer will break strict-aliasing rules mean? [19:00:30] <kshishkov> a warning on place where compiler may botch your code [19:01:27] <elenril> lol [19:01:32] * elenril should learn c sometime [19:01:41] <kshishkov> really [19:04:39] <elenril> maybe i shouldn't have used mru's evil black magic [19:32:28] <Yuvi> huh, I did not know that there was legal precedent for H.264 being safe from submarine patents [19:32:39] <superdump> oh? [19:32:46] <Yuvi> http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Patent_licensing [19:33:15] <Yuvi> qualcomm lost its case for applying its patents to h.264 since they didn't disclose them to JVT by 2003 [19:34:08] <Yuvi> ofc, one of them (http://www.freepatentsonline.com/5576767.pdf) seems like it applies to just about any video codec [19:36:44] <superdump> then only the question of whether there are patents not licensed by the mpeg-la [19:36:46] <superdump> oops [19:37:18] <superdump> i want to ask the question of whether there are patents not licensed by the mpeg-la that were disclosed to jvt before h.264's release [19:39:57] <elenril> no such patents exist [19:59:24] <janneg> Yuvi: but only since qualcomm was participating in JVT. [20:00:39] <janneg> ther could be still h264 submarine patents from everyone not involved in JVT. it's unlikely [20:11:42] <superdump> Dark_Shikari: i have unbanned ohsix. i suggest you both resolve your differences or refrain from devolving into petty arguments or maybe even refrain from talking to each other at all if you so choose [20:11:47] <superdump> there's always /ignore [20:30:25] <m4k3r> hi. I think there are some missing spaces on libavutil/mem.c . The patch is here: ffmpeg.pastebim.com/d23774b55 . If someone could apply without sending to the ml - it's really stupid - .. [20:33:25] <janneg> http://ffmpeg.pastebin.com/d23774b55 [20:33:46] <m4k3r> uh, sorry. [20:33:55] <janneg> assuming the typo wasn't intended to spam [20:35:49] <janneg> m4k3r: I doubt anyone will apply that patch, are those the only 4 occurances of no space before '='? [20:36:18] <m4k3r> yep. That's fot that [20:36:48] <m4k3r> *for that that I haven't send it to the ml. [20:45:11] * elenril wonders if nut spec is obfuscated on purpose [20:51:01] <Yuvi> elenril: that's how micheal actually thinks ;) [20:52:15] <elenril> heh [23:04:20] <CIA-17> ffmpeg: stefano * r21647 /trunk/libavformat/avio.h: Doxument url_fdopen(). [23:25:01] <CIA-17> ffmpeg: stefano * r21648 /trunk/libavdevice/avdevice.h: Satisfy style nits.

1 0

IRC log for 2010-02-04
by irc＠mansr.com 05 Feb '10

05 Feb '10

[00:00:38] <CIA-17> ffmpeg: michael * r21633 /trunk/libavformat/utils.c: [00:00:38] <CIA-17> ffmpeg: Dont try generic seek if seek request before first index entry and backward. [00:00:38] <CIA-17> ffmpeg: Fixes issue1275 [00:25:07] <saste> kovensky: yes that's an option [00:25:22] <saste> they're function are mainly useful for testing [00:25:41] <saste> not that there is a real performance need for keeping them inline [00:26:16] <saste> anyway I remember that iirc michael and mans say something about to make intreadwrite public [00:26:25] <saste> or maybe it was another file... [00:28:34] * Kovensky pokes mru with ^ [01:55:13] <CIA-17> ffmpeg: michael * r21634 /trunk/ffplay.c: [01:55:13] <CIA-17> ffmpeg: autoexit [01:55:13] <CIA-17> ffmpeg: implements issue1019 [07:31:37] <Dark_Shikari> hah@michael [07:31:38] <Dark_Shikari> ENoTimeForReviewingFuckingCosmeticBikeshedPatches [07:32:16] <kshishkov> why, good error code [07:43:36] <benoit-> dobroe utro [07:43:47] <kshishkov> shalom [07:43:58] <Dark_Shikari> guten tag [07:46:09] <kshishkov> FFmpegãã£ã³ãšã«ãã©ããæ©ã [07:46:57] * elenril wonders since when kshishkov knows moonspeak [07:47:17] <kshishkov> uhm, three years maybe [07:47:24] <elenril> o_0 [07:47:47] <kshishkov> I know even more exotic language - Ukrainian. It's so rare even in Ukraine. [07:48:39] * elenril thought ukrainian was getting more popular lately [07:48:48] <kshishkov> where? [07:48:55] <elenril> in ukraine? [07:49:27] <thresh> no, not choosing between stupid politicians is popular there [07:49:29] <kshishkov> with one of major political parties being people who loathe Ukrainian and can't speak even proper Russian? [07:49:44] <kshishkov> thresh: at least it's choosing [07:49:49] <astrange> ah, that's ãã¯ãã not ãã¯ãã [07:50:41] <kshishkov> yep, a bit ambiguous [07:51:27] <kshishkov> like ããã«ã¡ã¯ and ä»æ¥ã¯ [08:48:57] <elenril> siretart: ping [09:46:09] <kshishkov> mate! [09:47:31] <pross-au> Evening [09:53:33] <kierank> are there any formats which pass a lot of metadata back? [09:53:54] <kshishkov> a lot? [09:54:21] <kshishkov> probably any format with not-so-bounded metadata [09:54:33] <kshishkov> i.e. anything with ID3 or APE tags [09:54:56] <kshishkov> RIFF, Matroska, MOV/MP4 [09:55:39] <kierank> ...because in dolby e the metadata is as important as the audio because it tells the final ac3 encoder how to encode [09:56:04] <kshishkov> sounds dubious [09:58:54] <superdump> seems to be the way dolby work [09:59:36] <superdump> but then dolby E is about distribution of multi-channel audio in two channels [09:59:37] <pross-au> .nfo? [10:00:03] <kierank> some nice ascii-art to go with it [10:00:42] <superdump> kierank: what information is in this metadata exactly? [10:01:05] <superdump> i mean, why doesn't it just decode 2 channels and spit out N channels? [10:01:17] <superdump> what more is needed to be passed to the encoder? [10:01:18] <Dark_Shikari> because it's dolby [10:02:19] <kierank> stuff like dialogue normalisation and dynamic range compression [10:02:31] <kierank> and dolby surround flags [10:03:05] <iive> kierank: this doesn't sound like metadata... [10:03:35] <Yuvi> how / where is this stored? [10:03:37] <kierank> it's not metadata like artist/album if that's what you mean iive [10:03:48] <kierank> Yuvi, in a header before the audio [10:04:05] <Yuvi> container header or codec stream header? [10:04:20] <kierank> codec stream [10:04:24] <jez9999> if i want to pass a list of variable size into ffmpeg via the public API, what's the standard way you guys do things? a linked list? [10:04:32] <jez9999> are there any examples? [10:04:42] <Yuvi> isn't it just part of the codec data then? [10:04:55] <kierank> Yuvi: the idea being you can move from a playout server in mxf to a satellite stream etc [10:05:16] <iive> kierank: meta data, is data about the data. while the stuff you pointed out, is part of the decoding, that could be skipped, ignored or exported. [10:05:40] <kierank> nope: that is data about how the encoder at the end of the chain can choose to encode it [10:06:06] <kierank> that stuff is data about the data [10:06:44] <kierank> anyways I can use AVmetadata but just store things as chars [10:06:53] <iive> oh, you don't have ac3 yet. [10:07:21] <iive> no, it's more like 1'st pass log file. [10:25:45] <iive> i think that the right term is hint data. [10:35:22] <jez9999> if i want to pass a list of variable size into ffmpeg via the public API, what's the standard way you guys do things? a linked list? [10:35:23] <jez9999> are there any examples? [10:35:47] <kshishkov> array + length? [10:36:22] <kshishkov> it mostly depends on what and where you intend to feed [10:36:35] <jez9999> a list of sockaddr's [10:37:41] <jez9999> ie. structs [10:38:09] <pross-au> i hope you mean sockaddr_storage [10:38:28] <av500> in xml char string? [10:38:31] <av500> :) [10:40:55] <jez9999> pross-au: ... which is ffmpeg's non-POSIX sort of hacky way of storing a sockaddr? [10:41:18] <pross-au> sockaddr_storage is the POSIX way [10:41:27] <pross-au> for ipv4 and ipv6 (and others) [10:42:05] <pross-au> i am not sure we expose any of the POSIX data structures in the public libav API though [10:42:43] <jez9999> hmm [10:42:48] <jez9999> i thought that was what sockaddr was for [10:43:02] <jez9999> so that _in and _in6 could fit into it [10:43:35] <twnqx> load really [10:44:39] <jez9999> load? [10:45:19] <twnqx> gah... "not really" [10:45:33] <pross-au> sockaddr isn't guaranteed to be big enough for ipv6 [10:45:40] <pross-au> hence sockaddr_storage [10:45:54] <twnqx> sockaddr is guaranteed to be big enough to identify the protocol, right? [10:46:08] <twnqx> so you can then cast it to the appropiate type [10:46:19] <pross-au> yep [10:46:48] <pross-au> read application usage here... http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/socket.h.html [10:47:06] <jez9999> struct sockaddr { ushort sa_family; char sa_data[14]; }; [10:47:35] <pross-au> jez9999: that might be true on your operating system [10:48:09] <kierank> Is it possible to pass an AVMetadata with each packet? [10:48:14] <kierank> AVMetadata struct* [10:48:51] <kshishkov> kierank: probably not [10:49:03] <kshishkov> it's all muxer stuff, not codec [10:49:45] <jez9999> sockaddr is variable length? sheesh [10:49:52] <twnqx> printf ("%d %d %d\n", sizeof (struct sockaddr), sizeof (struct sockaddr_in), sizeof (struct sockaddr_in6)); [10:49:57] <twnqx> 16 16 28 [10:50:15] <jez9999> what's its purpose then? [10:50:26] <twnqx> to have generic access to the protocol [10:50:32] <twnqx> aka sa_family [10:51:35] <pross-au> jez9999: yes, the length of an address varies depending on the protocol being used [10:51:46] <pross-au> ipv4 addresses are much smaller then ipv6 addresses [10:52:02] <jez9999> 'generic access'? [10:52:12] <jez9999> what does that mean [10:52:15] <pross-au> socket.h has always been generic access [10:52:41] <pross-au> it means the API is defined largely indepenant of the protocol [10:53:12] <jez9999> yeah.... that's sockaddr_storage, as far as i can see [10:53:18] <jez9999> so the purpose of sockaddr? [10:53:56] <pross-au> jez9999: its a legacy datastruture [10:54:10] <pross-au> they cant remove it from the standard, doing so will break stuff :D [10:54:18] <jez9999> *shrug* [10:54:40] <jez9999> so i want to pass a list of sockaddr_storage's into ffmpeg [10:54:52] <jez9999> what's the standard way [10:55:14] <pross-au> sockaddr_storage list[NB_LIST]; [10:56:51] <pross-au> if you were to provide a function, av_do_somthing(void *list, int items, int size_of_sockaddr); might be a more portable alternative [10:57:26] <pross-au> that way there is no need to put sockaddr_storage in avformat.h or whatever [10:57:36] <pross-au> (as not all platforms support it. e.g. windows) [10:57:42] <jez9999> a function? [10:57:43] <jez9999> hmm [10:58:03] <jez9999> oh i dont expect sockaddr_storage to be accepted by ffmpeg [10:58:18] <pross-au> ok [10:58:22] <jez9999> that's for testing purposes. the devs will probably want me to roll my own version (if it hasnt been done already) [10:59:11] <jez9999> i dont know of a better non-POSIX way of passing a network address through the API [10:59:22] <jez9999> although i heard that windows could be made POSIX-compliant now. [10:59:24] <pross-au> char* [10:59:44] <jez9999> you mean a string representation of the address? [10:59:57] <pross-au> yep [11:00:10] <jez9999> then some nasty code on the other side to parse it? [11:00:23] <pross-au> yep [11:00:30] <jez9999> how would it even know the address family? [11:00:31] <pross-au> well, what if you want to pass hostnames? [11:00:46] <jez9999> i wouldn't. recvfrom() doesnt do hostnames [11:00:54] <pross-au> oh [11:00:58] <jez9999> they should be resolved beforehand [11:02:15] <pross-au> is the user app sending the list to ffmpeg, or is ffmpeg returning a list of addresses? [11:02:29] <jez9999> the former [11:03:25] <pross-au> maybe then add these fields to the format context: void* address_list; int nb_addresses; int sizeof_sockaddr; [11:04:34] <jez9999> what about an opaque field? [11:04:56] <pross-au> to avoid having to include sockaddr_storage in the public api. [11:05:46] <jez9999> sizeof_sockaddr... didn't you say sockaddr was a legacy data structure? [11:06:07] <pross-au> hah. well call it 'sizeof_sockaddr_storage' then. [11:06:14] <jez9999> i can't find any definition of NB_LIST, by the way, in the ffmpeg codebase or in my /usr/include... [11:06:30] <pross-au> jez9999: NB_LIST would be a number you decide on [11:06:47] <jez9999> it's be variable though [11:06:49] <jez9999> *it;d [11:06:51] <jez9999> it'd [11:07:07] <pross-au> okay then : sockaddr_storage *addresses; int nb_addresses; [11:07:35] <jez9999> sockaddr_storage *? [11:07:44] <jez9999> a pointer to a single sockaddr_storage ? [11:07:59] <pross-au> jez9999: it could be one, it could be many... [11:08:21] <jez9999> ah, concatenated in memory [11:08:55] <jez9999> yeah im preferring the void *address_list [11:08:58] <pross-au> I prefer to call them arrays. [11:09:04] <jez9999> the devs would never approve sockaddr_storage in AVFormatContext [11:09:10] <pross-au> Yep [11:09:32] <jez9999> again, though, what about an opaque field? [11:09:37] <pross-au> opaque? [11:10:38] <pross-au> void *address_list; <-- would be a pointer to an array of socket addresses [11:13:38] <jez9999> opaque, like in ByteIOContext, or AVCodecContext [11:17:28] <jez9999> ? [11:18:36] <pross-au> as i said, it just saves having to specific sockaddr_storage in the API [11:19:01] <jez9999> what are you referring to now? [11:19:10] <jez9999> with 'it'? :-) [11:19:22] <pross-au> void *address_list; [11:19:26] <jez9999> ah right [11:19:34] <jez9999> so you're unaware of the usage of the opaque field [11:19:50] <pross-au> I dont even know what that means. [11:20:08] <jez9999> well it exists in the structs i mentioned above [11:20:21] <pross-au> void * [11:20:34] <jez9999> for 'Private data of the user' [11:20:41] <jez9999> yeah it is a void * [11:20:41] <pross-au> priv_data [11:20:56] <pross-au> yeah, but you dont want this list of ip addresses to be private [11:21:03] <pross-au> you want other people to be able to use them [11:21:16] <jez9999> other people? [11:21:25] <pross-au> 'users of libavformat' [11:21:35] <jez9999> oh, you mean that the intention of opaque is that ffmpeg never reads it. [11:21:42] <jez9999> only ever the calling code [11:21:45] <pross-au> correct [11:21:49] <pross-au> thats what opaque means. [11:21:53] <jez9999> yeah, i see [11:22:05] <pross-au> got to go. [11:22:10] <pross-au> hope ya work it out [11:22:14] <jez9999> AVFormatContext probabyl ought to have an opaque anyway though, for good measure [11:22:26] <jez9999> ....... bye [11:22:26] <jez9999> lol [11:23:54] <siretart`> elenril: pong? [11:25:25] <elenril> siretart`: is there a git repo for x264 in ubuntu? [11:26:28] <siretart`> elenril: yes, it is maintained by the pkg-multimedia team on git.debian.org [11:26:45] <siretart`> ubuntu favors bzr, so we use debian ressources for that [11:27:51] <elenril> good, i feared it was bzr only :) [11:30:17] <siretart`> I guess there is an bzr package import as well, if interested, try 'bzr get lp:ubuntu/x264' [11:32:59] * elenril would prefer to keep the number of vcses on his system as low as possible [13:26:16] <superdump> http://gunshotfx.com/libavcodec/ [13:26:18] <superdump> hmmmmm [13:26:44] <superdump> maybe the file has some 'aperture' colour profile thing in it that ffmpeg is ignoring? [13:32:51] <kierank> does he provide the source? [13:35:17] <superdump> no [13:35:55] <superdump> but iirc Dark_Shikari said something about HD using a different pixel format standard to SD in many/all cases but they don't signal it in the bitstream as they're supposed to [13:36:30] <superdump> so FFmpeg by default chooses a default pixel format that differs to what is commonly used and assumed by other programs for HD content [13:36:39] <superdump> maybe we can provide a patch for this for them to test [13:37:18] <kierank> you mean bt. 609 and bt 709? [13:37:32] <superdump> something like that [13:37:42] <superdump> http://tomvision.blogspot.com/2010/01/i-think-i-found-flaw-in.html [13:37:48] <superdump> that's the author's blog post about it [13:50:54] <J_Darnley> Those two images were converted to or from RGB using different matricies. [13:51:28] <J_Darnley> Loading them into avisynth and then using ConvertToYV12() and manually setting the matrix fixes the colour differences [13:55:20] <J_Darnley> using 709 for the QT image and 601 for the lavc image almost completely removes the differences [14:00:51] <superdump> then it is indeed as we suspected [14:00:53] <superdump> still [14:00:58] <superdump> _almost_ completely? [14:01:13] <superdump> i guess there might be rounding errors going forward and bad [14:01:15] <superdump> back* [14:17:34] <merbzt> yuv2rgb [14:27:55] <CIA-17> ffmpeg: michael * r21635 /trunk/libavcodec/msmpeg4.c: [14:27:55] <CIA-17> ffmpeg: Implement cool new vlc code. [14:27:55] <CIA-17> ffmpeg: Fixes issue1637 [14:43:47] <CIA-17> libswscale: stefano * r30501 /trunk/libswscale/ (rgb2rgb.c rgb2rgb.h swscale.c): [14:43:47] <CIA-17> libswscale: Implement shuffle_bytes_abcd() functions and use them for shuffling [14:43:47] <CIA-17> libswscale: bytes when converting between RGB32 variants. [14:43:47] <CIA-17> libswscale: In particular fix the argb -> rgba and abgr -> bgra conversions. [14:43:47] <CIA-17> libswscale: See the thread: [14:43:48] <CIA-17> libswscale: Subject: [FFmpeg-devel] [RFC] RGB32 / BGR32 ethernal bug [14:43:48] <CIA-17> libswscale: Date: Tue, 26 Jan 2010 01:06:18 +0100 [14:45:19] <kshishkov> hmm, thatimages look like somebody (not) applying loop filter in some places [14:46:08] <superdump> kshishkov: even the difference in the red? [14:46:29] <kshishkov> no, those look more like colourspace conversion differences [14:47:30] <superdump> can we choose between rec 601 and rec 709 in libavcodec somehow? [14:47:55] <kshishkov> not yet, but codec telling which colourspace to use would be a nice feature [14:49:14] <superdump> codecs can set PIX_FMT [14:49:27] <superdump> and i assumed there would be some PIX_FMT for 601 and another for 709 [14:49:31] <kshishkov> too many pix_fmts, Michael does not like that already [14:50:06] <superdump> meh [14:50:08] <superdump> whatever [14:56:07] <superdump> aha [14:56:11] <superdump> found it [14:56:40] <superdump> http://git.ffmpeg.org/?p=libswscale;a=blob;f=swscale.h;h=9e14262d30f4311ef7… [14:57:51] <superdump> merbzt: so that's what you were trying to say [14:58:00] <superdump> libswscale/yuv2rgb.c [14:58:06] <superdump> has the coefficients [14:58:17] <superdump> iirc, you rewrote that didn't you kshishkov ? [15:16:30] <superdump> maybe we can do it at the swscale level then [15:28:55] <superdump> is h.264 deblocking standardised? [15:29:17] <superdump> i.e. any coefficients used and so on [15:30:08] <andoma> superdump: are you attending fosdem? [15:30:22] <superdump> not this year, no [15:30:27] <superdump> mebbe next [15:30:32] <andoma> kay.. yeah me too [15:30:44] <andoma> 4 guys from Spotify are going this year [15:30:48] <superdump> :) [15:30:50] <andoma> i should've joined them [15:31:26] <CIA-17> ffmpeg: michael * r21636 /trunk/libavcodec/ (h264.c h264_ps.c): [15:31:26] <CIA-17> ffmpeg: Fix large timebases. [15:31:26] <CIA-17> ffmpeg: Fixed issue1633 [15:32:52] <kshishkov> superdump: I haven't touched coeffs [15:34:48] <superdump> hmm [16:13:27] <superdump> reynaldo: qcelp is always mono, right? [16:22:19] <CIA-17> ffmpeg: jai_menon * r21637 /trunk/libavcodec/alac.c: Add ALAC 24 bps decoding support. [17:20:12] <Compn> intel emailed me [17:20:18] <kshishkov> and? [17:20:22] <kshishkov> are you sued? [17:20:39] <av500> the offered a refund for the pentium bug? [17:22:09] <Compn> heh [17:22:23] <Compn> it was a note about va-api [17:23:22] <Compn> Hi, [17:23:22] <Compn> I didnt see the support for VAAPI listed on the Mplayer website where you talk about hw acceleration (section on the main page). [17:23:22] <Compn> As youre aware, Gwenole is doing excellent work by patching Mplayer for VAAPI available at: http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/ [17:23:22] <Compn> For the embedded customers, were looking at supporting Mplayer with the embedded graphics driver for the Atom platforms. [17:23:22] <Compn> Please let me know if youve any questions. Thanks. [17:23:23] <Compn> Regards, [17:25:28] <av500> Compn: GMA500? [17:25:32] <kierank> Conpn: was that from eric? [17:26:16] <Compn> Ishu Verma [17:26:16] <Compn> Software Technical Marketing Engineer [17:26:17] <Compn> Digital Enterprise Group - ECG [17:26:17] <Compn> ishu.verma(a)intel.com [17:26:42] <Compn> so... no [17:26:54] <Compn> i sent a reply asking which cards are supported [17:26:56] <kierank> k, so wasn't the guy that did the dxva stuff [17:32:43] <kierank> i wonder if slices will work through vaapi because through dxva they don't [17:34:48] <Compn> kierank : got a list of intel or ati cards that are supported by vaapi ? [17:34:52] <Compn> or anyone / [17:37:23] <kierank> no idea [18:23:48] <Kovensky> isn't there a vaapi->vdpau driver? [18:23:51] <Kovensky> or is it still WIP? [18:29:28] <Anssi> http://www.splitted-desktop.com/~gbeauchesne/vdpau-video/ [19:33:38] <Compn> arg [19:33:55] <Compn> intel guy didnt like that i wrote ati works with vaapi :D [19:35:56] <kshishkov> mention nvidia next time [19:35:59] <Compn> lol [19:39:06] <carignanboy> Where can I find the *-dev library that contains the avcodec_decode_audio3 symbol? [19:39:24] <kshishkov> not here, I think [19:39:34] <kshishkov> try newest version [19:39:54] <carignanboy> FFmpeg version git-91be88c [19:40:35] <kshishkov> main FFmpeg still does not use Git [19:40:43] <kshishkov> ask at #ffmpeg channel [19:41:03] <carignanboy> thanks :) [19:46:03] <_av500_> decode_audio3? that still exists? :) [19:46:51] <kshishkov> yes [19:47:11] <kshishkov> it's default in current FFmpeg [19:47:20] <kshishkov> IIRC, for about a year [19:48:07] <_av500_> kshishkov: I know :) [19:48:54] <kshishkov> maybe you can also sort git commit IDs chronologically without git log? [19:49:12] * _av500_ had to make up packets on the fly to satisfy it [20:08:08] <twnqx> symbian becomes open source? [20:08:15] <twnqx> do want ffmpeg on my e65! [20:09:42] <_av500_> patches welcome I guess [21:01:26] <ShadowJK> do want libc [21:02:00] <_av500_> it has libnokla [21:08:37] <twnqx> i guess a libc would exceed the storage capacity of the mobile >_> [21:08:58] <_av500_> uclibc [21:09:22] <ShadowJK> it probably has 128 or 256 meg storage [21:09:54] <ShadowJK> there is a libc for symbian, I think they call it OpenC or something [21:10:02] <_av500_> 128mb is ok [21:10:06] <drv> even glibc is not that big... [23:44:50] <kierank> Is there a better way of handling the situation where an audio codec has more channels than the container is aware of than making the demuxer parse the codec's header?

1 0

IRC log for 2010-02-03
by irc＠mansr.com 04 Feb '10

04 Feb '10

[00:36:21] <CIA-17> ffmpeg: michael * r21620 /trunk/libavformat/avidec.c: [00:36:21] <CIA-17> ffmpeg: Only set duration for streams where it is likely correct. [00:36:21] <CIA-17> ffmpeg: Fixes issue1120 [02:28:09] <Compn> whoa [02:29:40] <mru> ? [02:44:00] <Compn> nevermind, i was looking at something incorrectly [03:24:04] <Dark_Shikari> apparently if you set the MMX2 flag, but not the MMX flag, when using swscale [03:24:07] <Dark_Shikari> it can give broken output [03:29:04] <aclarke_> Dark_Shikari what's a good proof-of-concept option for me to expose in libx264 specific options in the patch I'm working on? [03:29:30] <Dark_Shikari> anything not currently in libx264.c [03:29:31] <Dark_Shikari> intra-refresh [03:29:32] <aclarke_> i can set up any AVOption-type value to be available at the init(..) call time. [03:29:32] <Dark_Shikari> slice-max-size [03:29:37] <Dark_Shikari> slice-max-mbs [03:29:38] <Dark_Shikari> slices [03:29:40] <aclarke_> k; I'll take those [03:29:42] <aclarke_> thx [03:29:54] <aclarke_> any one a personal favorite? [03:30:43] <Dark_Shikari> aq-strength [03:30:45] <Dark_Shikari> psy-rd [03:30:56] <Dark_Shikari> oh, psy-rd is a special case. it requires a weird syntax [03:31:00] <Dark_Shikari> --psy-rd A:B [04:41:32] <CIA-17> ffmpeg: michael * r21621 /trunk/libavcodec/mpegvideo_parser.c: (log message trimmed) [04:41:32] <CIA-17> ffmpeg: Revert [04:41:32] <CIA-17> ffmpeg: r12684 | michael | 2008-04-04 02:43:34 +0200 (Fri, 04 Apr 2008) | 2 lines [04:41:32] <CIA-17> ffmpeg: Disable the split function. This should end the mpeg1/2 global header issues. [04:41:32] <CIA-17> ffmpeg: The split function is essential for -ss to work [04:41:33] <CIA-17> ffmpeg: Fixes issue1226 [04:41:34] <CIA-17> ffmpeg: If this breaks something please tell me, also if someoen remembers what problem [05:15:02] <astrange> mm, where's unsolo [06:37:00] <astrange> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patched… i was expecting more files... [06:37:13] <elenril> J_Darnley: what happened to your patch for writing vorbiscomment to flac? [06:41:50] <Dark_Shikari> astrange: ? [06:41:52] <Dark_Shikari> it's paginated [06:43:15] <astrange> oh, i have viewvc banner blindness from the cvs branch menu always being there [07:11:53] <benoit-> moin [07:16:22] <kshishkov> bonjour [07:35:56] <KotH> salut [07:36:04] <kshishkov> hej [07:45:05] <benoit-> KotH: Guten Morgen [07:52:53] <andoma> Dark_Shikari: what does x264 use to write mkv files? libmkv (seems it spawned from the x264 dev), or is it just code embedded in the x264 repo? [07:53:25] <kierank> it uses haali's muxer [07:54:47] <kierank> which is in the main x264 repo [07:54:53] <andoma> ah, i see [07:55:03] <andoma> thanks [07:56:56] <kshishkov> andoma: kan ukrainsk man få ett erbete i Sverige? [07:57:44] <andoma> kshishkov: vet inte riktigt hur det funkar [07:57:54] <andoma> kshishkov: hade ni varit med i EU hade det nog varit lättare [07:58:36] <saintdev> andoma: the x264 was written by haali, libmkv is based off of it for HandBrake. [07:58:53] <kshishkov> andoma: naturligtvis [08:12:45] <kierank> kshishkov: when you wrote vc-1 did you RE it or use the spec? [08:13:00] <jai> probably the reference code [08:13:21] <kshishkov> there was both standard draft and reference decoder available [08:13:23] <jai> the spec out there in the wild is too old, good for an overview though [08:13:34] <Dark_Shikari> andoma: it's a very simple mkv muxer [08:13:36] <siretart`> morning [08:13:39] <Dark_Shikari> it could probably use indexing support [08:13:40] <jai> hello siretart` [08:13:47] <siretart`> hi jai [08:18:14] <jai> superdump: i'm still confused as to what exactly we hope to achieve with a release :) [08:18:34] <superdump> jai: hopefully a sync point for distributions [08:18:44] <superdump> so they don't use <random svn checkout> [08:19:38] <jai> superdump: so more like milestones rather than stable api maintained releases [08:20:12] <superdump> unless we can manage to find someone willing to maintain them [08:20:16] * superdump looks at siretart` [08:20:28] <jai> i feel this just leads to people maintaining their own custom patches on top of the tarball [08:20:53] <kshishkov> jai: that's true for any opensource project [08:20:58] <jai> also, maybe there can be a more open discussion this time around regarding the policy itself [08:21:10] <kshishkov> at least we don't release too often [08:21:19] <jai> kshishkov: in this case, these patches can be backported to the branch so all distros benefit [08:22:42] <jai> but at the outset, atleast for 0.5, there was a clear statement from diego that no functionality/bugfix patches would be inegrated [08:22:48] <jai> *integrated [08:23:03] <superdump> that was his choice as release manager [08:23:24] <superdump> maybe if you get baptiste to be release manager this time, things will be different [08:23:32] <jai> superdump: fair enough, so maybe more voices this time around [08:23:52] <jai> roles/titles aside, thats the point i wanted to make [08:25:06] <superdump> last time diego took a stand and did it his way because otherwise we would have sat talking about it again and not got anything done [08:25:22] <superdump> siretart`: what did you think of the last release? any comments? [08:25:50] * siretart` reads backlog [08:25:57] <superdump> j-b: do you have any comments about the 0.5 release or don't you care because you track head or something? [08:26:06] <andoma> i've relied on the 0.5 release for quite some time for one of my projects. works very good for me. prior to 0.5 there was always something that broke when something changed in ffmpeg [08:26:27] <siretart`> superdump: oh, you are asking for a retospective of the 0.5 release? [08:26:32] <superdump> yes [08:26:58] <siretart`> I think it was a great idea, and I'm really glad that it happened. let me explain why [08:27:13] <siretart`> before, the debian package shipped snapshot of more-or-less random dates [08:27:21] <superdump> andoma: you mean certain things change in the api and you have to adapt to them if you track head, but rather if you can stick to a release version there's nothing to change for you? [08:27:33] <siretart`> I started to look at other distros like gentoo to see what snapshot dates they use [08:27:43] <siretart`> but it is impossible to find a proper sync point [08:27:57] <andoma> superdump: exactly [08:28:03] <siretart`> moreover, I was heavily bitten by crash reports of gnome users, they mainly use gst-ffmpeg [08:28:16] <jai> andoma: thats awesome, but i'm sure you would benefit quite a bit more if you could occasionally get a few bugfixes now and then [08:28:26] <siretart`> with the 0.5 release, gst-ffmpeg switched to that branch, so their copy and the system ffmpeg finally went in sync [08:28:31] <jai> andoma: without having to worry about api changes [08:28:37] <siretart`> and crashes went instantly away [08:28:48] <superdump> andoma: so it moves the burden of maintenance from being an ongoing thing to being a do it once and move on until the next release thing [08:29:18] <superdump> siretart`: interesting to know [08:29:32] <siretart`> as for maintenance, well, I'd of course would have preferred more active maintenance on 0.5, but as it didn't really happen (diego was too busy), I accumulated lots of patches for the distro package [08:29:36] <superdump> i'll have to talk to bilboed when he gets back [08:29:46] <siretart`> now that diego granted me svn access and indicated interest in merging them, I'm upstreaming them now [08:30:21] <superdump> another thing with a sync point for distros is that maintenance can be distributed i guess [08:30:28] <superdump> is there much in the way of patch sharing? [08:30:36] <siretart`> that was the intent, but didn't really happen [08:30:53] <siretart`> I plan to create a wiki page on the multimedia wiki that lists the various distro and 3rd party packages [08:30:55] <andoma> but franky, for that particular project i mostly rely on FFmpeg's mkv muxer... that's why i asked around about a library that does just mkv muxing earlier.. [08:30:56] <superdump> and do you know if other distros are still using 0.5 or are now using a more current snapshot? [08:30:57] <KotH> siretart`: do you need/want anything from .ch? [08:31:10] <KotH> siretart`: now is the last chance to let me know :) [08:31:36] <siretart`> KotH: how much are cheap swiss knives with usb pendrives? [08:32:05] <siretart`> superdump: TBH, I don't really know. that's what I intent to learn in that wiki page [08:32:08] <superdump> andoma: what about the official matroska libs? or there is a libmkv that some guys at handbrake made i think [08:32:25] <siretart`> superdump: as in: write to various distro and 3rd party package maintainers to fill in missing information [08:32:39] <superdump> siretart`: sounds like a good plan [08:32:47] <andoma> superdump: the official libs seems c++ish [08:32:48] <siretart`> mike gave me the wiki account yesterday, so I can finally start working on that [08:32:54] <andoma> superdump: so i stoped looked at them [08:32:58] <superdump> andoma: right, i think they are [08:33:01] <superdump> ok [08:34:02] <superdump> siretart`: maybe if maintenance burden is shifted downstream and a sync point is provided by us, then patches can come back upstream (even if they're complete crap and we have to solve the issue in a different way...) [08:34:25] <superdump> i don't know if that's better or not though [08:34:50] <j-b> superdump: I do not care. I use HEAD for WIndows and Mac, and I couldn't care less about Linux's mess [08:34:51] <superdump> i would think downstream noise is the best way to know what's wrong in the release version though [08:35:04] <superdump> j-b: fair enough [08:35:16] <superdump> j-b: thanks for your input :)) [08:35:26] <siretart`> superdump: I didn't say that publicy yet, but I my agenda for a potential 0.6 release includes these points [08:36:00] <KotH> siretart`: uhm.. [08:36:08] <superdump> i think that might be a good approach [08:36:14] <KotH> siretart`: i think they are somewhere between 50 and 100 chf [08:36:20] <jai> superdump: imho its a better idea to leave backporting to people who understand the diffs/fixes [08:36:49] <superdump> it seems fairly clear that very few/none of us want to continue maintaining an old branch with any significant effort [08:36:57] <KotH> siretart`: do you want one? [08:37:13] <jai> superdump: we could ask on the ML one last time ;) [08:37:22] <jai> superdump: but before that the policy must be made clear [08:37:40] <superdump> jai: i was thinking that leveraging downstream for identification of issues and maybe submission of (poor?) patches back upstream, that would reduce the workload a bit [08:37:40] <KotH> siretart`: and there are no cheap swiss army knives ;-) [08:37:47] <jai> superdump: because last time around, it was made pretty clear that only security relevant fixes would go in [08:38:03] <superdump> jai: and then we can review patches and apply or fix issues 'properly' [08:38:05] <jai> superdump: which confuses me atleast. [08:38:11] <superdump> backport whatever is necessary [08:38:23] <jai> superdump: sure [08:38:24] <superdump> and then make point releases [08:38:25] <siretart`> KotH: if it doesn't cause you too much trouble, I'd love to have one! my current pendrive on my keyring broke, and it is always handy to have a rescue system on your key :-) [08:38:36] <jai> superdump: we do have decent commit log messages which describe the intent [08:38:55] <siretart`> I assume that the swiss knives are more protected than these "ultraportable" pendrives [08:39:11] <jai> superdump: so i assume the next release wont have disclaimers like - "no bugfixes evah" [08:39:28] <siretart`> jai: how about the policy "best efford"? [08:39:37] <superdump> depends on the decided policy and/or the release manager [08:39:59] <siretart`> -d+t [08:40:05] <jai> siretart`: i'm okay with that, as long as it is made clear at the beginning [08:40:28] <KotH> siretart`: ok, i'll try to find one... i hope they have some at the train staition (wont have time for much more) [08:40:33] <jai> contradicting statements are something we should avoid [08:40:40] <superdump> like i said, last time diego decided he was going to be release manager, no one strongly objected, he said he was going to do it his way so we could at least get one release out the door and then we could improve things afterwards [08:40:56] <siretart`> KotH: if not, it's really not that important [08:41:15] <superdump> originally me and baptiste wanted a second release within 3-6 months [08:41:18] <superdump> diego said 6 [08:41:24] <superdump> it never happened [08:41:26] <superdump> :) [08:41:49] <superdump> but if we want to get another one out within a year of the last one, we need to get going _now_ [08:41:55] <superdump> we're probably going to overshoot [08:41:58] <jai> superdump: we can make it happen - just write a mail saying you wish to get 0.6 work started [08:42:13] <siretart`> will you two be at fosdem? [08:43:28] <siretart`> I take the silence as 'no'. :-) [08:43:38] <andoma> i wanted to go [08:44:05] <jai> siretart`: sorry, would love to but the the logistics of it seem to fail me ;) [08:44:11] <jai> siretart`: though i'm mostly on irc [08:45:02] <siretart`> I guess the 0.6 release will be an important topic this weekend. perhaps it would be best to not rush decision on a 0.6 release before fosdem [08:46:17] <jai> siretart`: sure [08:51:56] <superdump> siretart`: no, sorry [08:52:43] <superdump> siretart`: you could maybe discuss it at fosdem, but maybe people there will not be those interested in managing a release [08:52:50] <superdump> i think diego is going though [08:54:00] <siretart`> hm, I actually didn't wan't to say it publicy yet, but perhaps I should anyway [08:54:14] <siretart`> I'm strongly considering nominating myself as release manager for the 0.6 release [08:54:31] <siretart`> I will stay in the same hostel as diego this weekend and will use the time to discuss this with him [08:55:19] <kshishkov> bring a big stick [08:56:32] <siretart`> who? me? [08:56:36] <siretart`> or for me? ;-) [08:57:09] <kshishkov> you, for convincing when there are no more technical arguments [09:00:45] <jai> hm [09:02:42] <superdump> jai, siretart` : mail sent [09:03:10] <jai> superdump: excellent :) [09:16:03] <kierank> yes [09:16:07] <kierank> whoops [09:20:49] <siretart`> superdump: thanks for the mail [09:21:05] <superdump> no problem [09:21:31] <merbzt> there are stuff that we should w8 for before we do a new release [09:21:42] <superdump> i think if you're willing to do that extra work of keeping on top of downstream (it seems you're at least interested) then maybe we could do that [09:22:05] <superdump> merbzt: it'd be nice for michael to 'finish' his h.264 commit spree [09:22:23] <siretart`> I'd love to see ffprobe and amr merged for 0.6 [09:22:26] <superdump> merbzt: but what else? things almost ready to land like amr-nb, wmavoice and such? [09:22:41] <kshishkov> Indeo 5 [09:22:46] <merbzt> wmavoice, amr, bink, indeo 5 [09:22:58] <superdump> by all means we can make a feature blocker list [09:23:00] <superdump> :) [09:23:05] <merbzt> he-aac [09:23:11] <siretart`> too bad that roundup doesn't allow 'targetting' bugs to a past or upcoming release… [09:23:21] <superdump> it would be nice to get he aac in, yes [09:24:01] <merbzt> pending als stuff also [09:24:09] <pross-au> superdump: also makes sense to do releases BEFORE northern hemisphere summer (gsoc work) [09:24:22] <superdump> pross-au: that was my thinking too [09:25:04] <superdump> merbzt: please respond to the mail with such a feature hit list :) [09:25:22] <merbzt> we should start a wiki page to collect what we want in the next release [09:25:33] <kshishkov> pross-au: in our case it's "default summer time", too few Australian FFmpeg devs here [09:26:21] <pross-au> your definition of summer hardly passes for spring here [09:27:03] <kshishkov> huh? "hot and nasty weather" is your spring? [09:27:53] * kshishkov was lucky to spend the worst part of Ukrainian summer far away [09:27:58] <pross-au> it was last year [09:29:28] <kshishkov> it's still was a miracle finding time to finish RTMP client while being in Stockholm [09:56:30] <superdump> kshishkov: why? because you liked walking around in stockholm so much? [09:57:07] <CIA-17> ffmpeg: pross * r21622 /trunk/ (6 files in 3 dirs): IFF PBM/ILBM bitmap decoder [09:58:11] <CIA-17> ffmpeg: pross * r21623 /trunk/libavformat/iff.c: Extend IFF demuxer to parse PBM/ILBM bitmap chunks [09:59:06] <CIA-17> ffmpeg: pross * r21624 /trunk/libavformat/iff.c: Indentation cleanup [10:00:26] <superdump> merbzt: maybe we can edit http://wiki.multimedia.cx/index.php?title=FFmpeg_Release_Plan [10:03:06] <merbzt> superdump: fixed [10:03:13] <superdump> merbzt: the things that need doing section at least :) [10:03:33] <superdump> :) [10:05:45] <superdump> merbzt: i moved it to the things that need doing section [10:05:53] <pross-au> dont we already have an API-ABI changelog? [10:06:24] <superdump> i've changed that to 'update' [10:07:27] <pross-au> superdump: its already up to date [10:07:35] <superdump> really? [10:08:17] <superdump> changed to [10:08:19] <superdump> Make sure API/ABI changelog is up-to-date [10:08:21] <superdump> :) [10:08:45] <pross-au> Ok. [10:11:26] <superdump> i guess libavfilter is still a way off...? [10:13:32] <siretart`> superdump: the debian package for 0.5 already shipped libavfilter0. I don't think any application used it yet, though [10:13:50] <superdump> i'm not sure how usable it is yet [10:13:58] <predat> Hello, Avid release an update to his codec (2.1) and i can't decode DNxHD185 with ffmpeg now -> segmentation fault [10:14:03] <superdump> some stuff has been in trunk for a long time, but no integration [10:14:08] <siretart`> superdump: what should be considered however is if you/we want to bump SONAME of libavcodec/libavformat for 0.6 [10:14:26] <superdump> predat: http://ffmpeg.org/bugreports.html [10:16:33] <mru> morning [10:18:46] <superdump> morning mru [10:22:15] <predat> thank you superdump [10:22:35] <superdump> predat: i expect baptiste will look at that at some point [10:23:30] <predat> he send a mail on the user list yesterday [10:25:54] <kshishkov> superdump: why else? [10:26:22] <kierank> Are there any formats where the container sees one stream but in fact there are multiple streams disguised as one stream? [10:26:28] <superdump> kshishkov: it's covered in snow at the moment [10:26:36] <superdump> and the water froze [10:27:17] <kshishkov> well, here it's water in basins formed by ice walls on every street [10:27:37] <kshishkov> and it's slippery as a road to Ukraine [10:28:28] <kshishkov> (not that anyone has tried to clean streets in a weeks) [10:28:54] <kshishkov> and temperature swings from -25 to +5 it's even more fun [10:33:01] <superdump> sounds fun :) [10:33:31] <kshishkov> yeah [10:34:29] <kshishkov> in April I was out of Kharkov for two weeks and it still managed to get worse in that time [10:45:34] <peloverde> mru, http://www.embeddedgurus.net/stack-overflow/2010/02/is-gcc-good-compiler.ht… [10:45:47] <mru> read it just now [10:46:01] <mru> I'll have to write a response [10:46:19] <mru> that guy has some good points [10:46:24] <mru> but often he's plain wrong [10:46:55] <mru> cf his "C tips" series [10:50:00] <mru> I'll have to have a look at that iar compiler [10:50:15] <av500> so high paid consultants use expensive compilers and lowly paid ones use cheap gcc.... [10:50:40] <mru> being highly paid doesn't mean you're right [10:50:48] <kierank> lol [10:50:53] <av500> no, he who pays you thinks you are :) [10:51:15] * mru glances at his clients [10:51:28] <kshishkov> av500: he who pays thinks _he_ is [10:51:53] <av500> the client is always right! [10:52:24] <kshishkov> in certain bounds [10:55:21] <kshishkov> the trouble with commercial compilers is that you usually can't run them on what you like [10:57:44] <av500> no, it runs nicely on the AVR that thos guys loves to develop on.... [10:57:51] <av500> thos->this [11:32:11] <pross-au> peloverde: one could use the same argument with operating systems (free, cheap, expensive, very expensive). [11:32:52] <peloverde> Funny because it is 100x easier to develope FFmpeg with free Linux than with expensive windows [11:33:19] <av500> peloverde: you would think differently if you were paid $$$$$ :) [11:33:30] <pross-au> peloverde: microsoft gcc compiles FFmpeg out of the box [11:33:34] <av500> suddenly using windows would make it so much better [11:33:39] <kshishkov> are there firms dedicated solely to compiler tech support and not being their devs? [11:34:07] <av500> kshishkov: and they binary patch the compilers if they find a problem? [11:34:47] * kshishkov remembers about CodeSourcery [11:34:52] <mru> my advice is to stay well clear of any product that has a dedicated third-party support industry built around it [11:35:21] <peloverde> Well there goes automobiles... [11:35:41] <av500> and relationships [11:35:47] <pross-au> LOL [11:35:56] <kshishkov> and Linux [11:36:07] <av500> thats a relationship [11:36:18] <pross-au> theres heap of third party FFmpeg stuff no? [11:36:21] <kshishkov> and computers (except maybe from Apple) [11:36:42] <mru> av500: what? there's a number I can call for help with my gf? [11:36:54] <pross-au> ffmpeg2theora [11:36:55] <mru> (no, I don't have a gf) [11:36:59] <av500> it was in the paperwork that came with her [11:37:20] <kshishkov> mru: psychoanalysts [11:37:31] <mru> av500: I'm not _that_ desperate [11:37:36] <pross-au> mru: when you do, be sure to cough up for the extended warranty option [11:37:43] <mru> I know a psychologist... [11:38:41] <kshishkov> psychologist is a person who tells what's wrong with your head, psychoanalyst just hears your blabbery about personal issues [11:39:08] <av500> nothing is wrong with MY head, it is all the others' [11:39:21] <mru> kshishkov: I've never asked her to do either [11:39:24] <mru> nor will I [11:40:47] <kshishkov> fine with me [11:41:30] <kshishkov> but you should admit there _is_ a whole industry built around resolving personal issues for money [11:43:00] <pross-au> kshishkov: is there an app for that? [11:43:15] <kshishkov> pross-au: emacs, alt-m elisa [11:44:17] <pross-au> SBAITSO2.EXE [11:44:19] <mru> it's m-x doctor [11:45:17] * kshishkov does not have "meta" key on any of his keyboards. Must be too new. [11:45:41] <mru> meta is old as the hills [11:45:55] <pross-au> shift+':' [11:46:22] * mru has all of Escape, Meta, Alt, Control, Shift [11:46:36] <mru> and hyper and mode-switch too [11:47:02] <kshishkov> Das Keyboard oder Symbolics? [11:47:11] <mru> das keyboard [11:47:22] <mru> lets me make up my own names for keys ;-) [11:50:31] <pross-au> Replace 'F1' with 'Mans' [11:50:51] <merbzt> Måns [11:50:57] <av500> pross-au: F1 holds "/nick _troll_" [11:51:18] <pross-au> merbzt: 7-bit terminal here [11:52:09] <merbzt> I can lend you an extra bit [11:53:29] <pross-au> *i* am the 7-bit terminal [11:53:46] * kshishkov kan ge ä, å och ö [11:54:47] * mru has ü too [11:54:49] <mru> just in case [11:55:01] <av500> ü is important [11:55:05] <merbzt> Müns ? [11:55:06] <mru> and in uppercaser Ü [11:55:08] * kshishkov has a bit of Cyrillic too [11:55:29] <mru> I don't need cyrillic [11:55:38] <mru> don't know any of those languages [11:55:55] <mru> the fragments I know are read-only [11:55:59] <kshishkov> you own a dictionary for one of them [11:56:25] <kshishkov> my fragments are usually are write-only [12:00:30] * kshishkov thinks maybe it's worth to learn Korean as well [12:01:54] <mru> korean is hard [12:01:59] <mru> script is easy [12:02:04] <mru> language is hard [12:02:43] <kshishkov> harder than German or Russian? [12:03:48] <mru> much harder than german [12:04:07] <mru> they inflect verbs in 14 ways depending on politeness level [12:05:01] <kshishkov> that's nothing, how much exceptions for conjugating rules are there? [12:05:20] <mru> I've no idea [12:05:38] <mru> they also have grammatical constructs that don't exist in western languages [12:05:58] <kshishkov> there is similar situation with Japanese, but there are only two irregular verbs [12:06:03] <mru> a western sentence has subject, verb, and zero or more objects [12:06:11] <mru> korean has a special inflection for the topic [12:06:28] <kshishkov> and in Russian (and to lesser extent German) there are almost no _regular_ forms [12:06:35] <mru> which is applied in addition to subject/object inflections [12:07:06] <mru> and that's just about all I know about korean [12:07:28] <kshishkov> what about Russian? [12:07:39] <mru> I know the script [12:07:42] <mru> and a few words [12:07:47] <mru> forgot most of the grammar [12:07:53] <kshishkov> any impression left? [12:08:19] <mru> it was complicated [12:10:06] <kshishkov> well, for example Russian verb "to get victory" does not have future single 1st person form but all other are there [12:15:23] <peloverde> English+Spanish has served me pretty well in the western hemisphere [12:15:49] <kshishkov> it was English+Swedish for me [12:16:25] <mru> my spanish friends keep saying I should learn it [12:17:23] <kshishkov> peloverde: I suspect you've not been to France [12:17:36] <peloverde> I have not [12:17:58] <peloverde> I also make a habit of avoiding Quebec, Haiti, and Brazil [12:18:40] <kshishkov> why Quebec? [12:18:55] <peloverde> I don't speak French [12:19:04] <av500> Quabac? [12:20:13] <mru> quack? [12:20:50] <kshishkov> que? [12:21:00] <av500> bec! [12:25:42] <Compn> the canadians and youpers pronounce it 'kebek' [12:26:03] <Compn> ... i think [12:27:15] <peloverde> That's how my buddy who went to McGill pronounces it [12:29:33] * mru heads for the airport [12:29:42] <mru> 2h to "takeoff" [12:29:57] <kshishkov> where to? [12:30:30] <Compn> 'off to save the world' [12:30:42] <av500> not dominate it? [12:30:52] <Compn> well you cant dominate a world thats been destroyed [12:54:07] <kierank> hmmm trying to make a decoder without a spec is like an online treasure hunt [12:54:38] <av500> kierank: but you are lucky, you at least have an encoder :) [12:54:47] <kierank> yeah that's true [12:54:59] <kierank> except only 1 day left on the trial [12:55:31] <kshishkov> kierank: it's a wrong place to complain [12:55:41] <kierank> not complaining [12:55:55] <kierank> the treasure hunt is quite interesting when you find some random document that helps you [12:56:03] <mru> kierank: so hack the protection [12:56:19] <kierank> it has some ring0 kernel crap [12:56:42] <mru> everything can be hacked [12:56:51] <kierank> and a driver on the system that BSODs when you try and mess with it [12:57:04] <kierank> someone else is working on cracking the anti-debug stuff [12:57:22] <kierank> who's done iLok before [13:01:35] <jai> done as in reversed? [13:01:42] <kierank> yes [13:02:58] <Compn> what codec are you working on ? [13:03:06] <kierank> Dolby E [13:03:39] * av500 has only Dolby B amd C on his tapedeck [13:04:12] <kshishkov> kierank: google seems to know [13:04:45] <kierank> you mean that tutorial on that cracking site? [13:04:59] <kierank> didn't work... [13:05:15] <kshishkov> could not find DEBUG? [13:06:00] <kierank> link m,e [13:06:08] <kierank> dunno what you're talking about [13:06:56] <kshishkov> anyway, what does IDA say? [13:07:23] <kierank> program shuts down as soon as you open it in ida [13:07:36] <twnqx> Oo [13:07:48] <twnqx> wait, you can run programs in ida these days? [13:07:51] <kshishkov> and opening on box without that shit running? [13:08:05] <jai> twnqx: yep [13:08:16] <kierank> kshishkov, what shit? [13:08:17] <jai> it has debugging support since quite some time [13:08:21] <jai> userspace that is [13:08:26] <twnqx> wow. i never used that... [13:08:41] <kshishkov> kierank: simply copy driver to another machine and disassemble it in IDA [13:08:50] <jai> well, with ollydbg around you dont need to ... [13:08:59] <twnqx> but last time i used IDA i gave up on what i intended to do when i recognized RSA encryption :P [13:09:39] <jai> twnqx: as in parts of the binary were encrypted ? [13:11:10] <twnqx> no, keyfiles [13:17:17] * mru wants a pc with jtag [13:17:25] <twnqx> Oo [13:17:37] <kshishkov> mru: build one [13:17:47] <twnqx> you want to jtag into your... what? [13:17:54] <kshishkov> i7 [13:17:59] <twnqx> hm [13:18:04] <mru> av500: when will you fix the android? [13:18:26] <mru> had to reboot it twice to revive bt [13:18:29] <twnqx> does the i7 even have a jtag interface? and is intel giving out the specs? [13:19:06] <jai> kierank: http://www.tuts4you.com/download.php?view.2778 [13:19:10] <av500> mru: u on 1.6? [13:19:24] <av500> 1.7.xx? [13:19:41] <av500> bt tethering is in constant improvement mode atm [13:20:34] <kierank> jai: tried that one [13:22:13] <superdump> av500: bt? mru: the android? [13:24:47] <merbzt> kierank: could you unpack the binary ? [13:25:35] <av500> superdump: android running on an Archos A5, using bluetooth tethering to a mobile phone [13:25:48] <superdump> and what is it being used for? [13:26:16] <av500> I guess for irc chatting on mru's side :) [13:26:37] <superdump> hehe [13:29:28] <kierank> [13:24] <@merbzt> kierank: could you unpack the binary ? --> nope [13:30:12] <superdump> brb [13:30:13] <mru> av500: 1.7.33 [14:54:03] <CIA-17> ffmpeg: michael * r21625 /trunk/ffmpeg.c: Alternative solution for the mpegvideo_split + mov problem. [15:05:02] <ramiro> interesting... this product claims they use ffmpeg: http://www.samsung.com/us/consumer/tv-video/blu-ray/blu-ray-players/BD-P160… [15:05:47] <ramiro> it's also 57% off =) [15:10:00] <CIA-17> ffmpeg: michael * r21626 /trunk/ (tests/ref/lavf/ffm ffmpeg.c): [15:10:00] <CIA-17> ffmpeg: Correct opts calulation in ffmpeg.c. [15:10:00] <CIA-17> ffmpeg: This correct the stop point for demuxing with -vcodec copy and -t as well as [15:10:00] <CIA-17> ffmpeg: packet interleaving. (we already diddrop packets but kept demuxing them [15:10:00] <CIA-17> ffmpeg: for too long due to opts being wrong) [15:10:00] <CIA-17> ffmpeg: the change to ffm is due to 2 packets with timestamp 0 being stored [15:10:01] <CIA-17> ffmpeg: in different order. [15:19:34] <kshishkov> ramiro: maybe it uses FFmpeg solely for decoding interlaced VC-1 on Blu-Ray :P [15:20:10] <CIA-17> ffmpeg: michael * r21627 /trunk/ffplay.c: [15:20:10] <CIA-17> ffmpeg: The convertion between bit and byte is 8 not 60. [15:20:10] <CIA-17> ffmpeg: Fixes wrong cursor key seek distances. [15:24:28] <janneg> time to use the metri^Wbinary system for time [15:37:40] <drv> yay, kega video decoder working [15:38:33] <kshishkov> yep, Compn verified that before adding that DLL entry to codecs.conf, didn't he? [15:38:34] <ramiro> kshishkov: I'm downloading the firmware update right now. I'm still looking for offer for sources [15:39:16] <ramiro> I wonder how it's possible to update it [15:39:19] <drv> had to re-RE some of the details ;) [15:39:29] <ramiro> oh, we don't use gplv3, they don't need to make us update it =/ [15:39:33] <kshishkov> drv: for example? [15:39:56] <drv> the one code references the previous frame, not the current one [15:40:07] <drv> and the offset for that type can wrap around [15:40:10] <drv> updated wiki page :P [15:40:18] <kshishkov> thanks [15:40:34] <drv> also output looks too dark, but i'm not sure if that is a swscale problem or my eyes are broken or what [15:40:35] <kshishkov> for the only sequence I had it made no difference [15:40:45] <drv> i made myself a nice capture of the Zero Wing opening ;) [15:41:03] <kshishkov> with AYB? [15:41:06] <drv> yep [15:43:02] * kshishkov should RE a codec [15:44:31] <ramiro> ok, I sent an e-mail to samsung asking for sources... [15:45:11] <superdump> i was getting the user manual to see what they're using it for [15:45:15] <superdump> or to have a guess [15:45:20] <superdump> do they have some medi@ thing? [15:45:31] <superdump> i guess it'll be some upnp/dlna player [15:45:38] <superdump> s/player/client/ [15:47:14] <drv> aha, it's RGB555, not 565 [15:47:25] <superdump> ramiro: > Hey Rob [15:47:27] <superdump> > [15:47:30] <superdump> oops [15:47:37] <superdump> ramiro: http://is.gd/7CBYj [15:47:41] <superdump> that one too [15:55:19] <ramiro> superdump: do you know what they use ffmpeg for? [15:55:30] <ramiro> they have some youtube downloader thingy... [15:55:51] <ramiro> great, the store that had it 57% off is offline... [15:59:02] <ramiro> I'm curious as to what I can access with the ethernet port. [15:59:23] <ramiro> only those subscription-based services, or is it possible to access your home network and player whatever is there? [16:02:33] <Honoome> ramiro: they might have “DLNA” support (UPnP/AV streaming) [16:03:42] <mru> ugh [16:03:48] <ramiro> what's that? [16:04:00] <ramiro> it seems the characters you used got mangled in xchat here.. [16:04:27] <ramiro> I can se "a with a litte hat" "box" "box" DLNA "a with a little hat" "box" "box" [16:04:40] <drv> "smart" quotes ;) [16:04:51] <peloverde> X-Chat defaults to the MIRC character set [16:06:05] <ohsix> mirc doesn't have a character set, irc just has a weird one :> (but is 8 bit clean) those were multibyte characters [16:06:11] <ramiro> apparently there's a "character set translation" where you have to pick a file, but I don't know what that is. [16:06:34] <drv> irssi at least can autodetect most of the time [16:07:38] <ohsix> utf8 if its sane; but different languages stick with old encodings so you typically have to pick by channel if you're talking in arabic or whatever [16:08:20] <ohsix> this persists even though most ircds have been 8 bit clean for like 15 years; basically because mirc does it the piss poor way [16:29:54] <peloverde> Time to head to the Airport. I'll see whomever at FOSDEM! [16:53:50] <verb3k> Can anyone with a rough forecast of future ffmpeg development tell me whether the developers are interested in implementing frame-accurate seeking/trimming? I asked in the development mailing list but got no reply [16:56:43] <av500> patches welcome, no? [16:57:17] <kshishkov> yep, developer laziness overcomes everything! [16:58:15] <verb3k> I just wanted to know what the core developers think about it, there is already ffmpeg-fas [16:59:58] <kshishkov> well, nobody objects against accurate seeking, patch is welcome [17:04:44] <verb3k> is there a reason why ffmpeg-fas isn't welcome? [17:05:15] <kshishkov> because we have't heard of it [17:05:22] <elenril> o/ people [17:05:44] <verb3k> http://github.com/lbrandy/ffmpeg-fas [17:06:08] <kshishkov> if a clean patch is sent, it will be reviewed and you'll get detailed awnser [17:28:11] <elenril> http://yro.slashdot.org/story/10/02/03/1528242/MPEG-LA-Extends-H264-Royalty… << hahahaha [17:28:33] <kshishkov> not funny to Firefox folks [17:28:48] <elenril> seems hilarious to me [17:29:23] * elenril hopes somebody will port vimperator to chrome soon so he can switch [17:33:01] <jai> elenril: if you are switching just for webkit, then maybe uzbl [17:33:18] <jai> though the name is probably misleading ;) [17:33:43] * elenril heard chrome is omgfast [17:33:50] <kshishkov> how a bunch of meaningless letters mislead? [17:34:08] <kshishkov> s/mislead/can be misleading/ [17:34:59] <elenril> hmm, looks nice [17:35:02] <drv> uzbl -> "usable" in theory [17:35:04] <elenril> jai: are you using it? [17:35:06] <drv> though it looks anything but [17:35:29] <jai> elenril: briefly, yeah [17:35:44] <jai> elenril: i still use it with webkit nightlies [17:36:02] <elenril> hmm, a package in debian [17:36:04] * elenril installs [17:36:24] <kshishkov> drv: that looks like Hebrew where th wrt vwls nl fr chldrn [17:36:32] <jai> drv: requires some tinkering, and some more time "integrating" with your WM [17:36:48] * elenril doesn'd mind some tinkering [17:37:08] * elenril uses fvwm, aka 'script your own window manager', so yeah [17:37:10] <jai> elenril: cool, might as well give it a try :) [17:38:27] <kshishkov> drv: BTW, why don't you output data to RGB555NE? [17:38:53] * elenril wonders why is nobody reviewing bink decoder [17:38:56] <Compn> ugh [17:38:57] <drv> wouldn't it have to be flipped in decoder then? [17:39:07] <Compn> remind me to remove 'kega video' from small tasks page later [17:39:13] <drv> RGB555 endian swapping is not clean and easy ;) [17:39:18] <Compn> if drv didnt already do it :D [17:39:26] <drv> i didn't yet, feel free [17:39:54] <kshishkov> drv: if you read pixels explicitly as 16-bit word, they will be stored in native endianness [17:40:24] <drv> hmm, i think you are probably right, there will be some endianness issues here anyway that i didn't think through... [17:40:36] <drv> someday i should get a BE machine ;) [17:40:40] <kshishkov> elenril: not much serious reviews in last weeks :( [17:41:01] <kshishkov> drv: you can always ask for account on mru's Mac [17:41:13] <elenril> kshishkov: just commit it and see what happens :) [17:41:38] <kshishkov> elenril: no, you commit [17:41:51] * elenril can't [17:42:14] * kshishkov also can't - we have rules after all [17:42:22] <drv> i had a qemu MIPS or something that was BE for a while, but it was painfully slow [17:44:17] * kshishkov has real MIPS bit it's LE :( [17:44:36] <kshishkov> damn those firmware creators - it could be set into BE mode instead [17:46:24] * kshishkov wants anothe BE machine to play with [17:46:48] <J_Darnley> elenril: you were asking about my flac-tag patch... [17:51:43] <elenril> J_Darnley: so? [17:51:53] <elenril> everybody forgot about it? [17:52:01] <J_Darnley> It seems [17:52:20] <kshishkov> even tried to ping it again? [17:52:42] <J_Darnley> No, I've updated the patch so I'll send another mail [17:52:44] * elenril 's experience tells him to bitch about his patches every few days on the ml _and_ irc [17:53:34] <kshishkov> elenril: depends on maintainer [17:56:04] <jez9999> BBB is usually here by now [17:56:12] <jez9999> anyone know where he is? [18:03:54] <kshishkov> there may be slight chance he's also travelling to FOSDEM [18:14:05] <elenril> btw who is still against git? [18:15:49] <Dark_Shikari> I think I have to give some credit to xiph for once. [18:15:54] <Dark_Shikari> H.264 is free for another 5 years [18:15:58] <av500> :) [18:15:58] <Dark_Shikari> thanks xiph! [18:16:00] <kshishkov> elenril: libswscale is [18:16:09] <elenril> lol [18:16:13] <elenril> kshishkov: what? [18:16:26] <kshishkov> really - libswscale and Diego [18:16:35] <av500> and in 5ys we will have H265 vs ...... still theora [18:16:38] <elenril> how does swscale affect anything? [18:16:47] * thresh had put libswscale as a submodule in git and just does not care [18:17:10] <kshishkov> it's in external repo for now and we haven't agreed on a way to merge it in for git yet [18:17:25] <elenril> with git merge? :) [18:17:41] <kshishkov> and Diego does not like the fact it's impossible to correct commit message for siple tpyos [18:18:07] <kshishkov> which is a good point too [18:18:08] <elenril> we can do it like kernel people [18:18:32] <kshishkov> make big companies pay core devs? I like that idea [18:18:51] <jai> lol [18:19:07] <elenril> he'll take care of the official tree and will merge other devs' stuff [18:19:31] <elenril> since he's probably the only one who cares about typos so much [18:19:45] <jai> elenril: ;) [18:19:58] <jai> "tree sheriff"? [18:20:12] <kshishkov> that will bottleneck development [18:20:25] <jai> elenril: or we could just push to a designated master [18:20:38] <elenril> kshishkov: how? [18:20:53] <jai> single point of failure? [18:20:57] <jai> elenril: ^ [18:21:07] <kshishkov> yes - look at the review process [18:21:23] <elenril> meh, everybody can just pick where to pull from [18:22:41] <kshishkov> too many repos [18:23:00] <elenril> what's wrong with that? [18:23:15] <elenril> many people have their own repos anyway [18:23:33] <kshishkov> too forky [18:24:04] * elenril still doesn't see what is wrong with that [18:24:36] <elenril> so yeah, we'll have ten million branches on once server [18:25:07] <elenril> now they exist anyway, just on other servers/people's computers etc [18:26:19] <kshishkov> I just don't like an idea of somebody else between me and and repo [18:26:35] <kshishkov> he can't be online 24/365 [18:27:40] <jai> indeed [18:28:03] <elenril> then we'll have to live with tyops [18:28:30] <thresh> nothing bad with those [18:28:54] <thresh> later you can even arrange the 'most tyoped developer of the year' award [18:28:54] <iive> kshishkov: even if he can be, there are years with 366 days! [18:28:55] <elenril> michael's commits are full of those anyway and nobody does anything with that [18:30:02] <kshishkov> wrong [18:31:40] <jai> elenril: wait till diego comes back, there will be a propedit sled [18:32:16] * elenril somehow doubts that [18:32:28] <elenril> not that fixing them makes any sense [18:32:59] <jai> i personally dont care, error correction kicks in [18:34:03] <kshishkov> jai: some messages are incomprehensible, even Diego has committed one of those [18:35:34] <jai> kshishkov: heh, we all slip sometimes [18:42:17] <mru> so svn has "better" commit messages while git has better commits [18:42:24] <mru> very tough choice that... [18:44:15] <mru> besides, I tend to write better commit messages with git [18:44:17] <kshishkov> too bad we can't get that propedit feature to git [18:45:01] <elenril> you can always do a rebase :) [18:45:23] <mru> it fucks up everybody's cloned trees [18:45:31] <elenril> hence the :) [18:46:06] <Honoome> mru: I tend to agree… actually I tend to *read* the commit messages (and thus write my own) while half the time I just use oneliners in cvs/svn ^^;; [18:46:51] <mru> part of it is because git encourages you to commit to your tree and git-send-email the patch [18:47:06] <mru> then the commit message has to contain the motivation for the path [18:47:47] <Honoome> and the other hart is that git log -p has an usable speed compared to svn log :P [18:47:55] <mru> that too [18:48:03] <mru> and there's git log --grep [18:48:09] <mru> and log -S [18:48:19] <Dark_Shikari> yeah, svn is dog slow [18:48:32] * elenril recently discovered than svn log connects to the server [18:48:38] <mru> of course it does [18:48:46] <mru> svn only stores the current revision locally [18:48:52] <elenril> i thought it keeps at least the log locally [18:48:56] <mru> and manages to do so using more space than an entire git history [18:49:00] <Honoome> rotfl [18:49:14] <elenril> it's more retarted than i thought [18:49:35] <Honoome> mru: don't forget the size of an hg forest :| I haven't tried named branches but last time it was ludicrous [18:49:53] <mru> everything I've heard about hg sounds ludicrous [18:49:58] <mru> writing it in python for starters [18:50:02] * thresh remembers arch [18:50:10] <Honoome> mru: still better than bzr… [18:50:17] <Dark_Shikari> oh god. [18:50:20] <jai> bzr is pure crap [18:50:22] <Honoome> Dark_Shikari: yeah? [18:50:22] <Dark_Shikari> a guy is trying to realtime SD encoding with x264 ... [18:50:26] <Dark_Shikari> ... on a Geode 500mhz [18:50:30] <Dark_Shikari> fuck that thing is slower than a Cortex [18:50:30] <mru> lol [18:50:32] <elenril> lol [18:50:39] <elenril> what's wrong with bzr? [18:50:44] * elenril doesn't know anything about it [18:50:45] <Dark_Shikari> elenril: it's slow as hell [18:50:53] <Dark_Shikari> http://whygitisbetterthanx.com/ [18:51:02] <Dark_Shikari> git and hg are the only good dcvss [18:51:41] <mru> I haven't used hg much [18:51:53] <mru> but git makes everything else look like a bad joke [18:51:53] <Honoome> I have for xine [18:52:05] <Honoome> not bad, actually [18:52:22] <Honoome> but dealing with multiple branches is space-consuming [18:52:41] <mru> as bad as svn? [18:52:47] <mru> and how good is it at merging? [18:52:55] <Honoome> merging is nice [18:53:17] <Honoome> but at least last I used it lacked named branches (went in “recently”) [18:53:25] <Honoome> so you basically had one cloned repository per branch… [18:53:44] <mru> like bitkeeper [18:54:04] <Honoome> I just *love* the git branch command [18:54:36] <mru> there's a reason I have 30-40 branches in my ffmpeg git [18:55:22] <jai> http://whybzrisbetterthanx.github.com/ [18:55:35] <Honoome> jai: rotfl [18:56:11] <jez9999> hey [18:56:14] <jez9999> anyone know where BBB is? [18:56:25] <mru> new york I think [18:56:37] <elenril> lol [19:04:14] <jez9999> yeah but why not on irc [19:04:15] <jez9999> :-) [19:04:49] <mru> maybe they don't have that in new york [19:56:36] <CIA-17> ffmpeg: stefano * r21628 /trunk/ffmpeg.c: [19:56:36] <CIA-17> ffmpeg: Make opt_frame_pix_fmt() call show_pix_fmts() if the provided option [19:56:36] <CIA-17> ffmpeg: is "list". [21:34:21] <CIA-17> ffmpeg: michael * r21629 /trunk/ffplay.c: [21:34:21] <CIA-17> ffmpeg: Move is->frame_timer init from start to flush_pkt handling so it is also [21:34:21] <CIA-17> ffmpeg: done on seeking. This fixes the bug where after reaching the end and waiting [21:34:21] <CIA-17> ffmpeg: a few seconds seeking back to the begin messes up AV sync and playback speed. [21:45:12] <_av500_> mru: looks like stefan has a full car :( [22:51:11] <_av500_> Dark_Shikari: spawn labs? [22:51:35] <Dark_Shikari> ? [22:52:22] <_av500_> they remote your video console over the internet [22:52:28] <_av500_> like onlive [22:52:59] <_av500_> i thought you were involved :) [22:53:11] <Dark_Shikari> no [22:53:28] <_av500_> like that intrarefresh stuff [22:53:32] <iive> _av500_: i've been hearing this for over a year. [22:53:38] <Dark_Shikari> _av500_: different company [22:53:43] <iive> have they made at least convinsing demo? [22:54:05] <_av500_> iive: no idea [22:54:11] <Dark_Shikari> dunno, the company I'm working with has [22:54:11] <_av500_> just saw it on eng [22:54:15] <Dark_Shikari> I've played Call of Duty in my browser [22:54:17] <Dark_Shikari> works pretty well [22:54:22] <_av500_> Dark_Shikari: known? [22:56:15] <_av500_> http://news.creativecow.net/story/861515 looks like no x264 :( [22:56:40] <jez9999> anyone know of any good channels for people who hack assembly code? ;-) [22:57:00] <Dark_Shikari> #x264dev ? ;) [22:57:19] <iive> this one is good start, the one DS point maybe too [23:06:48] <CIA-17> ffmpeg: michael * r21630 /trunk/libavformat/utils.c: [23:06:48] <CIA-17> ffmpeg: Try to open decoders in av_find_stream_info() even if no packets for the [23:06:48] <CIA-17> ffmpeg: stream are found. [23:06:48] <CIA-17> ffmpeg: Fixes issue1385 [23:11:08] <CIA-17> ffmpeg: stefano * r21631 /trunk/libavfilter/vf_crop.c: [23:11:08] <CIA-17> ffmpeg: Use pixel format descriptors for checking if the input format is [23:11:08] <CIA-17> ffmpeg: paletted. Simpler and more robust. [23:15:34] <Dark_Shikari> oh kostya would love this [23:16:31] <Dark_Shikari> http://forum.doom9.org/showthread.php?p=1108393 [23:16:41] <Dark_Shikari> "The VLC tables are not in the specs, and can not be reverse-engineered from binary code" [23:16:49] <twnqx> lol [23:18:32] <Kovensky> the public header libavutil/pixdesc.h is broken [23:19:28] <Kovensky> there's one avcodec deprecated function that got moved there (avcodec_get_pix_fmt -> av_get_pix_fmt) [23:19:44] <Kovensky> more specifically, it depends on intreadwrite.h ._. [23:20:20] <Kovensky> (and avutil.h doesn't include pixdesc.h it for some reason) [23:25:56] <saste> yes intreadwrite.h is not public [23:26:05] <saste> how do I miss this? [23:26:49] <saste> would be possible to export that also? [23:34:57] <CIA-17> ffmpeg: michael * r21632 /trunk/ffplay.c: [23:34:57] <CIA-17> ffmpeg: Clean after togling wave. [23:34:57] <CIA-17> ffmpeg: Fixes issue1180. [23:54:05] <Kovensky> saste: does pixdesc.h really need those inline functions? can't they be moved to some .c file in lavutil? [23:55:53] * Kovensky rages @ cygwin [23:55:55] <Kovensky> y so slow q_q [23:56:08] <Kovensky> takes like 10 minutes to run ffmpeg's configure script

1 0

IRC log for 2010-02-02
by irc＠mansr.com 03 Feb '10

03 Feb '10

[00:02:22] <iive> is this sws thing? [00:03:40] <ramiro> yes [00:03:42] <Yuvi> gcc sign-extends signed 32-bit array indexes on x86-64 [00:03:55] <Dark_Shikari> oh, this is why there's so much movsxd shit [00:05:30] <iive> ramiro: i think michael says in the text " you are having gain, when not only index is in native size, but also the variables that are used to calculate it" [00:05:40] <iive> does this make more sense? [00:05:58] <ramiro> hmmm, not for me. [00:06:05] <Dark_Shikari> which thread is this in? [00:06:23] <ramiro> Dark_Shikari: [PATCH] Fix function parameters for rgb48 to YV12 functions. [00:06:41] <aclarke_> question: should we clean up any per-codec options on close, or create a special avcodec_context_free(...) method? [00:06:42] <iive> well, i guess you have something like table[index] [00:06:51] <iive> and there is something like index=a*b+c [00:07:16] <iive> now, on 64 bit cpu it would be better to have int64_t index, [00:07:36] <iive> but you'd get some (small) speedup gain if you also have int64_t a,b,c; [00:07:45] <mru> not all 64-bit cpus [00:07:49] <mru> x86 perhaps [00:08:04] <Dark_Shikari> "have I mentioned that I hate x86" [00:08:05] <Dark_Shikari> "yes" [00:08:05] <iive> it's not my claim :| [00:08:13] <mru> mips64 and ppc64 are often run with 32-bit pointers [00:09:12] <ramiro> iive: and what we (mru and I) is to remove this x86-specific hack in the function declarations. [00:09:38] <iive> what is this hack like? [00:09:38] <ramiro> long has been misused because it meant 64-bit on 64-bit unix, but it's 32-bit in mingw-w64 [00:09:53] <ramiro> the function declaration is someFunc(long width, whatever...) [00:10:05] <ramiro> while it makes sense that width is int [00:10:07] <mru> maybe intptr_t is what you really want [00:10:38] <iive> well, isn't intptr supposed to be 1 bit (sign) bigger than ptr? [00:10:49] <mru> lol no [00:11:14] <mru> intptr_t is an integer type such that casting a pointer to it and back gives the same pointer [00:11:51] <iive> then this must be what you want to use. [00:12:03] <ramiro> it still looks ugly in the function definition. [00:12:17] <iive> hum... it sound so good that i may do #define int intptr_t [00:15:03] <ramiro> oh, this chat is now publicly logged? where? [00:15:34] <mru> ramiro: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel-irc/ [00:22:23] <Compn> i guess you could put it in the topic [00:22:26] <Compn> so lazy [00:24:08] <aclarke> convention question: what's the right method naming: avcodec_context_free, avcodec_free_context, avcodec_destroy_context or avcodec_destruct_context [00:24:15] <aclarke> i see all conventions in use for different structures [00:24:17] <ramiro> mru: but is there a relation to what a pointer size is and what the register size is? [00:24:25] <mru> not really [00:24:31] <ramiro> so intptr_t seem wrong... [00:24:32] <mru> pointer <= register [00:25:30] <ramiro> aclarke: stefano tried cleaning that up some time ago but it didn't go very far. [00:25:31] <mru> 64-bit systems with 32-bit pointers generally have automatic sign/zero-extension [00:26:39] <aclarke> ramiro: yeah, i'm not talking about cleaning up; I need to introduce a new free method for AVCodecContext though and am trying to figure out right convention [00:26:59] <ramiro> aclarke: it's probably up to what michael finds best. I personally prefer avcodec_free_context(), because of avcodec_alloc_context(). [00:27:07] <Dark_Shikari> mru: what's the point of such a system? [00:27:15] <aclarke> i'll start with that and wait for the revisions on the list [00:27:17] <Dark_Shikari> 64-bit math is not very useful [00:27:49] <aclarke> of course, I could do avcodecContextFreeMemoryFromUseInOrderToMakeItAvailableForOtherAreas(AVCodecContext* thingYouWantToFreeButAreAfraidToDoYourself); [00:28:05] <aclarke> just to get diego's comment [00:28:08] <mru> Dark_Shikari: 4G address space per process is usually enough [00:28:10] <peloverde> aclarke, you've been doing java too long :) [00:28:21] <mru> and 64-bit maths is useful [00:28:21] <Dark_Shikari> mru: but you don't need a 64-bit CPU for that [00:28:27] <ramiro> aclarke: and the doxy would be /** avcodec_free_context() */ ? [00:28:33] <Dark_Shikari> PAE on x86 for example [00:28:35] * mru points at mpegaudiodec.c [00:28:52] <Dark_Shikari> 32x32 -> upper 32 is not 64-bit math [00:28:55] <aclarke> @peloverde tell me about it. [00:29:11] <mru> mpegaudio does more 64-bit than that [00:29:17] <Dark_Shikari> like what? [00:29:18] <mru> maybe it doesn't need to [00:29:21] <Dark_Shikari> Probably [00:29:24] <mru> but it's full of 64-bit stuff [00:29:26] <mru> flac too [00:30:00] <mru> also, 64-bit mips and ppc can easily run some processes with 32-bit pointers and others with 64-bit if you choose [00:30:17] <mru> suppose you have that one app that really eats memory [00:30:22] <mru> gcc... [00:30:56] <Dark_Shikari> gcc hardly needs that much [00:30:58] <peloverde> ld eats far more memory than gcc in my experience [00:31:04] <Dark_Shikari> you could probably compile all of ffmpeg as a single c file [00:31:09] <Dark_Shikari> without exceeding 32bit address space [00:31:18] <mru> it was a joke [00:31:24] <mru> take matlab or something then [00:31:30] <peloverde> I can build chromium in parallel but have to link it serially if I don't want to swap like crazy [00:31:43] <mru> or any large simulation software [00:31:51] <Yuvi> gcc easily eats up 2GB of ram compiling single C++ files [00:32:32] <Dark_Shikari> yes but that's C++ [00:32:41] <mru> still gcc [00:32:45] <Dark_Shikari> no, g++ [00:32:51] <Dark_Shikari> yes yes yes gnu compiler collection [00:32:51] <mru> same thing [00:32:52] <peloverde> I haven't run into that problem and I only have 2GB ram [00:32:52] <Dark_Shikari> fuck that shit [00:33:06] <mru> the only difference between gcc and g++ is the default linker flags [00:33:45] <peloverde> int *foo = malloc(sizeof(int)); [00:33:51] <Yuvi> peloverde: it might limit itself to 1/2 of your total ram, at least 2GB is the max I've seen even when I encountered a bug where gcc ran out of memory compiling 400 lines of altivec [00:34:29] <Yuvi> and I have 4gb [00:34:34] <Dark_Shikari> Yuvi: that's standard on windows [00:34:37] <Dark_Shikari> dunno what linux does [00:35:05] <Yuvi> OS X and linux both only reserve 1gb of the space per app for the kernel I think [00:35:33] <mru> depends on configuration [00:35:42] <mru> 3+1 is the default on x86 [00:35:48] <mru> you can run 2+2 or 4+4 too [00:36:00] <mru> 4+4 doing a full switch [00:36:02] <mru> not recommended [01:02:59] <mru> I have a gcc process using 300MB here right now [01:03:14] <mru> building something in ffmpeg [01:07:49] <Dark_Shikari> is it linking? [01:10:36] <mru> no, that was cc1 [02:20:39] <ramiro> mru: on http://fate.multimedia.cx/index.php?build_record=174000 , --target-exec=/misc/fate/redpole/run--prefix=/misc/fate. There's no space between run and --prefix, is that a bug in the FATE page or in your config? [02:20:54] <mru> bug in my config [02:20:55] <mru> fixed [02:21:10] <mru> just taking forever to run the next iteration [02:22:04] <ramiro> well, it's blackfin... [02:22:40] <mru> the stupid thing is I have to reboot it between each test [02:22:54] <mru> and it takes 10-15 seconds to boot [02:23:57] <mru> now I'm curious why that svq3 test printing junk suddenly decided to bite all configs [02:24:58] <ramiro> why do you have to reboot it? [02:25:22] <mru> otherwise the memory fragments too much [02:25:38] <mru> and kills the network [02:26:11] <mru> that was after I already moved ffmpeg's bss and heap to dedicated areas [02:33:07] <mru> maybe I can reduce the reboot frequency a bit [02:36:20] <ramiro> if I change long (or x86_reg) in the declaration to int and make an "x86_reg width = dstWidth;", nothing changes in relation to how gcc indexes the arrays in the loop. [02:36:47] <ramiro> it only changes one mov from int to x86_reg, either in the caller or the callee... [02:37:02] <ramiro> it doesn't help in any swscale function I've tested so far. [02:37:42] <ramiro> not even the C code, nor the mmx2, nor the x86, or mmx... [02:39:28] <Dark_Shikari> hmm, I need to calculate a rough closed form for this expression [02:39:29] <Dark_Shikari> X(n) = (X(n-1) + I) * R [02:39:29] <Dark_Shikari> where 0 < R < 1 [02:39:35] <Dark_Shikari> I'm looking for X(inf) [02:40:07] <mru> and I is what? [02:40:11] <Dark_Shikari> Some value. [02:40:13] <Dark_Shikari> Positive. [02:40:21] <Dark_Shikari> (intra SATD, but that's not important) [02:40:30] <mru> X(0)? [02:40:35] <Dark_Shikari> Not actually important. [02:40:42] <Dark_Shikari> No matter what it is, it will converge to the same value. [02:41:15] <Dark_Shikari> also, it might be useful to get an approximation for X(largenum), like X(50) [02:41:24] <mru> not if I==inf or X(0)==inf [02:41:28] <Dark_Shikari> well yes [02:41:33] <Dark_Shikari> X(0) = Some Finite Number [02:41:54] <mru> then it converges [02:41:59] <mru> intuitively at least [02:42:17] <Dark_Shikari> Yeah, but I need to figure out what it converges to [02:42:34] <pengvado> dimensional analysis says I/(1-R) [02:42:44] <mru> sounds plausible [02:42:52] <Dark_Shikari> wait, how the hell do you use dimensional analysis there? [02:43:32] <pengvado> * linear in I [02:43:32] <pengvado> * blows up when R->1 [02:43:33] <pengvado> * =I when R=0 [02:44:03] <pengvado> oops, skipped a factor [02:44:18] <Dark_Shikari> oh you mean X(n-1)+I = I/(1-R) [02:44:23] <Dark_Shikari> right? [02:46:08] <Dark_Shikari> in that case: [02:46:09] <Dark_Shikari> 0.100000: 111.111111 [02:46:09] <Dark_Shikari> 0.200000: 125.000000 [02:46:10] <Dark_Shikari> 0.300000: 142.857143 [02:46:10] <Dark_Shikari> 0.400000: 166.666667 [02:46:12] <Dark_Shikari> 0.500000: 200.000000 [02:46:14] <Dark_Shikari> 0.600000: 250.000000 [02:46:17] <Dark_Shikari> 0.700000: 333.333333 [02:46:19] <Dark_Shikari> 0.800000: 500.000000 [02:46:22] <Dark_Shikari> 0.900000: 1000.000000 [02:46:24] <Dark_Shikari> Dimensional analysis is correct. [02:49:15] <pengvado> I*R/(1-R) [02:49:28] <Dark_Shikari> Yeah [02:49:40] <Dark_Shikari> I'm trying to make a lookaheadless approximation of MB-tree [02:49:57] <Dark_Shikari> i.e. "assume frame N+1 is to N as frame N is to frame N-1" [02:50:09] <Dark_Shikari> and ignore motion vectors [02:50:33] <Dark_Shikari> or, well, consider them, but don't extrapolate [02:51:54] <Dark_Shikari> mru: -O11, awesome [02:59:13] <Dark_Shikari> ok, magic formula derived: ( N + (I - N) ) / N, where N = inter cost, I = intra cost [02:59:23] <Dark_Shikari> that approximates an infinite-frame MB-tree lookahead [03:00:08] <pengvado> N+I-N ... [03:00:20] <Dark_Shikari> er, yeah [03:00:36] <Dark_Shikari> .... that simplifies to I / N? [03:00:39] <Dark_Shikari> ..... [03:00:41] <Dark_Shikari> That's it? [03:00:52] <Dark_Shikari> qscale /= (I/N) [03:01:04] <Dark_Shikari> I guess that means mbtree's algorithm is actually more rigorously sensible now [03:01:09] <Dark_Shikari> because it converges to something that simple [03:10:38] <Dark_Shikari> hmm, the problem that comes up is "what to do in I-frames?" [04:23:30] <peloverde> Do we really not have a plain vector_add for floats? [04:24:39] <Compn> whats this demi thing ? [05:03:17] <peloverde> Why are ff_cos_tabs always positive? [06:21:36] <siretart> morning [06:23:17] <jai> morning [06:30:50] <kshishkov> as you say [06:59:27] <benoit-> good morning [06:59:38] <kshishkov> not here [06:59:52] <benoit-> kshishkov: not good ? or not morning ? [07:00:05] <kshishkov> not good at all [07:00:29] <benoit-> what's happening to you ? [07:00:50] <kshishkov> yesterday I tried to go outside [07:01:02] <kshishkov> today the weather seems to be the same [07:01:12] <thresh> moroning [07:47:54] <KotH> grüezi [07:50:54] <kshishkov> whatever! [07:52:27] <pJok> god morgon, kshishkov [07:52:27] <pJok> :) [07:52:38] <kshishkov> god morgon [07:54:06] <astrange> rm doc/ffserver.pod ffmpeg.o doc/ffmpeg.pod doc/ffplay.pod ffserver.o <- why does the last step of make delete ffmpeg.o... [07:54:13] <superdump> morning [07:54:32] <kshishkov> morrow [07:54:53] <kshishkov> astrange: interrogate mru [07:57:46] <astrange> seems like it's a make "feature" [08:04:13] <KotH> juup [08:04:27] <KotH> make deletes "temporary" files after building [08:04:36] <kshishkov> KotH: wanna fix it? [08:04:52] <KotH> no, i have to go out and buy chocolate :) [08:07:03] <jai> living up to the swiss stereotype :) [08:07:22] * superdump wants chocolate [08:07:27] <kshishkov> jai: made abroad too [08:07:33] <KotH> jai: lol [08:07:40] <KotH> jai: no, i have an order for fosdem :) [08:07:49] <jai> KotH: oh, nice [08:08:10] <KotH> jai: if you make it to fosdem, you can have some too ;-) [08:08:54] <jai> KotH: sure, someday before the swines go airborne [08:09:04] <kshishkov> superdump: I can tell you the address in Kharkov where you can buy chocolate and not the stuff mistakenly called so [08:09:04] <jai> KotH: thanks though ;) [08:09:28] <KotH> jai: linuxtag? [08:09:29] <superdump> probably a little too far for a brief morning stroll before work [08:09:41] <KotH> jai: ffmeeting? [08:09:48] <kshishkov> superdump: where are you? [08:09:59] <superdump> kshishkov: stockholm [08:10:13] <kshishkov> superdump: and where is your work? [08:10:21] <jai> KotH: i would love to come over for a meet, but the cost will kill me, not to mention getting a visa is probably tough :| [08:10:24] <superdump> right where i'm sitting [08:10:41] <kshishkov> superdump: and where is that more specifically? [08:10:42] <KotH> jai: it cannot be as bad as with kshishkov [08:10:46] <superdump> (and that applies wherever i am as long as i have an internet connection and a phone with me) [08:10:56] <KotH> jai: at least we've a lot of guys from india here [08:11:02] <KotH> actually.. too many ;) [08:11:06] <jai> KotH: well atleast kshishkov is in the vicinity of europe ;) [08:11:22] <superdump> kshishkov: in an apartment in enskede [08:11:33] <kshishkov> jai: yep but if you are student, it's easier to you to get visa anyway [08:12:13] <kshishkov> superdump: ok, just the closest shop would do then :P [08:12:42] <jai> kshishkov: hmm, i heard that elsewhere too ... [08:12:53] <superdump> there's a kiosk just outside [08:12:59] <superdump> but i think the best they have is marabou [08:13:08] <kshishkov> quite good for me [08:41:30] <Yuvi> ugh, in theora an uncoded block cannot have a mv [08:41:30] <Yuvi> even if the rest of the mb has a mv [08:42:18] <Dark_Shikari> yup [08:42:46] <Yuvi> that makes per-mb mc harder than it needs to be... [08:42:54] <Dark_Shikari> it's even worse on the encoder-side [08:42:55] <kshishkov> did somebody imply Theora was sane? [08:43:06] <Dark_Shikari> Actually, here's a good way to work around that: [08:43:13] <Dark_Shikari> if you have a whole MB that isn't coded but needs an MV [08:43:22] <Yuvi> and if the mb is using the golden ref, uncoded blocks still use the last ref [08:43:25] <Dark_Shikari> set the quantizer extremely low, and code one +1 dc coeff for each block [08:43:45] <Dark_Shikari> since at very low quants,+1 dc rounds to nothing [08:43:56] <Dark_Shikari> (would require dedicating one of the 3 global frame quants to this) [08:44:36] <Yuvi> probably a better use of the quants than trying to do proper AQ [08:44:44] <Dark_Shikari> well, they just implemented adaptive lambda in trunk [08:44:52] <Dark_Shikari> I wonder if they've changed the quantizer selection to match it [08:45:10] <Dark_Shikari> since adaptive lambda without adaptive quant is not as good [09:28:11] <kshishkov> cobber! [09:28:27] <pross-au> Hey, was gonna ask. Wheres the bink video decoder at [09:28:50] <pross-au> (i added it to the wiki list of interesting patches, because *i* found it interesting) [09:29:13] <superdump> :) [09:29:32] <pross-au> hi rob [09:30:02] <superdump> yo [09:31:28] <kshishkov> pross-au: at FFmpeg-devel ML in a few mins [09:32:03] <pross-au> Great [09:34:11] <kshishkov> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/082665.html [09:39:10] <pross-au> Did you get further with those bad block that would appear in some videos? [09:39:24] <kshishkov> no [09:40:02] <pross-au> ill have a play with it this weekend [09:40:11] <kshishkov> fine [09:40:35] * jai should send a patch too [09:40:55] <kshishkov> patch for what? [09:41:13] <jai> kshishkov: alac 24 bit [09:41:19] <jai> never got around to posting [09:41:29] <kshishkov> ah [09:41:36] * kshishkov has some patches rotting too [09:44:50] <jai> same here [09:45:03] <jai> i'll start looking over my tree in a bit [09:45:06] <kshishkov> too many codecs to RE as well [09:45:17] <jai> let the kids do it in gsoc ;) [09:45:21] <av500> VP8 ftw! [09:45:53] <jai> i assume vp8 binaries are now available> [09:45:56] <pross-au> too many! pftt, there will come a day when ya'll are begging for new stuff to r.e. [09:45:58] <jai> s/>/? [09:46:25] <kshishkov> pross-au: sometimes I do. You still have 1.5 EA codecs left to RE [09:46:37] <av500> jai: no idea? [09:47:15] <pross-au> i like low hanging fruit [09:47:39] <pross-au> speex is pretty low, btw [09:47:51] <kshishkov> leave it to gsoc kids [09:48:21] * kshishkov feels a bit old even he is not even 26 [09:48:26] <kshishkov> bbl [09:51:11] <astrange> vp8 isn't out [09:51:23] <astrange> there are some things using vp7 though [09:51:39] <Dark_Shikari> lol vp8 [09:51:43] <Dark_Shikari> they supposedly have an sdk [09:53:40] <Yuvi> supposedly they gave it to google in 2008 but they never used it beyond the evaluation [09:56:09] <av500> supposedly that is why gg bought them, no? :) [09:56:21] <astrange> http://github.com/astrange/ffmpeg/commit/337aca4b3b1b6554f3024ff22ec760a413… 23.8->23.38s on losslesstouhou, i'll send it tomorrow [09:56:38] <av500> gg saw the codec and decided that the only way to make sure nobody ever uses was to buy (and bury) ON2 [09:56:56] <twnqx> lol [09:57:19] <astrange> we can always hope they want to release it as theora II and they ask ffmpeg-devel for comments first [09:57:27] <av500> pity they did not buy them for vp3... [09:58:03] <merbzt> astrange: do you know how much faster the H264 decoder has gotten in the last 2 months ? [09:59:23] <astrange> between 1 and 15% depending on interlaced or not and x86 or not [10:01:05] <astrange> try: for n in 1 2 3 4 5; do for f in ffmpeg-0.5 ffmpeg-now; do echo $f; time $f -i something.mp4 -an -f framecrc -vsync 0 -y crc`basename $f` >/dev/null 2>&1; done; done;md5 crc* [10:01:39] <astrange> i don't keep old binaries around, personally i don't try to measure how much better it is as long as it is better [10:10:52] <astrange> http://github.com/astrange/ffmpeg/blob/master/libavcodec/h264.h#L861 profiling hotspot here, should be easy to skip if 1 frame = 1 slice [11:47:45] <kierank> What does LoRo stand for? [11:48:14] <av500> low robustness? [11:48:32] <kierank> nm found it. It's Left only, right only [12:06:23] <siretart`> does stefano irc? [12:07:08] <mru> siretart`: saste [12:07:15] <siretart`> thanks [12:08:12] <siretart`> mru: I wonder what to do in 0.5 about vhook and symbol versioning. what do you think about disabling versioning if vhook is enabled? [12:09:05] <mru> siretart`: do the packages have vhook enabled? [12:09:35] <siretart`> mru: 'my' packages don't [12:10:03] <mru> it shouldn't be hard to fix it [12:10:33] <siretart`> fix in the sense of "enable both vhook and symbol versioning"? [12:10:58] <mru> yes [12:36:46] <ohsix> anyone use oprofile much with the cache counters? [12:39:29] <mattg> does anyone know why with libavcodec h264 decoding, even with error_concealment = FF_EC_GUESS_MVS | FF_EC_DEBLOCK i'm getting completely green frames after getting "number of reference frames exceeds max" error? [12:40:00] <kshishkov> completely green frame = completely not decoded, I think [12:41:41] <mattg> well there's a completely green frame and then the next frame is green but with bits of what looks like the correct frame. i guess that it's using the green frame as a reference frame? [12:42:40] <kshishkov> could be reference frame lost -> green [12:42:49] <kshishkov> it's exceeding max anyway [12:46:05] <mattg> playing the same stream through ffplay doesn't give the greenness, so i'm assuming that i'm not setting some error concealment values somewhere - but can't seem to find where [12:47:14] <av500> mattg: could it be that ffplay just plays it correctly? [12:47:35] <av500> or do you get the same error msg? [12:47:46] <mattg> ffplay also indicates that it's concealing errors, so yes same error msg [12:51:23] <mattg> just it seems to do it right, whereas through libavcodec it's just not working [12:52:01] <av500> could it be that it drops frames that are not decoded OK? [12:53:00] <ShadowJK> the last nokia ad I remember is the one for 8800 or something... the one Neo uses in Matrix 1.. and in that ad it was hidden behind a banana [12:53:05] <ShadowJK> uh [12:53:09] <ShadowJK> wrong chasnnell [12:53:20] <kshishkov> very wrong indeed [12:53:23] <pross-au> still funny [13:05:58] <mattg> av500: not sure what you mean :-S. ffplay plays it fine, but my app through libavcodec doesn't. presumably it's a setting but i can't figure out which one [13:09:13] <superdump> if it works in ffplay but not in your code using libav* then i think your question is a user question [13:10:38] <mattg> ah huge apologies yes wrong channel indeed [16:02:10] <CIA-17> ffmpeg: michael * r21603 /trunk/ffplay.c: Fix seek flags [16:23:15] <mru> we have fosdem t-shirts [16:23:49] <kshishkov> for very limited number of "we" [16:24:20] <mru> those coming to fosdem of course [16:24:46] <mru> we'll have to organise something in sweden some time [16:24:51] <mru> so you can join [16:25:02] <kshishkov> now it's the same thing [16:25:19] <mru> what is? [16:25:30] <kshishkov> next to impossible to get visa [16:25:42] <mru> sweden too? [16:25:47] <mru> how'd you get it before? [16:25:55] <kshishkov> I was a student [16:25:55] <elenril> even for a RE guru? [16:26:31] <kshishkov> elenril: most RE gurus live in Europe or USA so no troubles for them [16:27:18] <kshishkov> so unless I can somehow get employed abroad, I won't be able to go there [16:27:39] <thresh> seriously, get a travel visa already [16:27:58] <thresh> book a hotel and then decline the booking after you got visa [16:28:00] <thresh> etc [16:29:08] <kshishkov> thresh: the trickiest part is to prove I won't stay in Europe after I get visa [16:37:42] <BBB> kshishkov, :( [16:38:26] <kshishkov> do you think I posted that "looking for a job" only because of sheer will to work? [16:40:09] <thresh> kshishkov: the plain tickets are enough. [16:40:23] <thresh> i'm not a student as well... [16:40:58] <kshishkov> thresh: really? what about references from work? [16:42:15] <thresh> a simple 'this guy works here' with signs by some CTO is enough [16:42:25] <thresh> you don't even have to provide the real salary [16:42:37] <kshishkov> I don't have even that to provide [16:42:44] <thresh> do you have a job? [16:42:50] <kshishkov> no [16:43:00] <kshishkov> I'm selfunemployed [16:43:04] <mru> lol [16:43:21] <thresh> well, it lowers your chances to get a visa, but still [16:43:45] <kshishkov> the fact I don't have friends to fake one for me lowers it even more [16:43:47] <thresh> what will probably ruin it is if you were to prison :) [16:45:04] <kshishkov> thresh: actually I am. The fact it's called "Ukraine" does not change much... [16:46:00] <thresh> :) [16:48:40] <CIA-17> ffmpeg: michael * r21604 /trunk/ (libavformat/mpeg.c tests/seek.regression.ref): Set AVPacket.pos in MPEG-PS demuxer. [16:51:49] <CIA-17> ffmpeg: michael * r21605 /trunk/ffplay.c: [16:51:49] <CIA-17> ffmpeg: Use currently displayed file position instead of just url_ftell() for seeking by bytes. [16:51:49] <CIA-17> ffmpeg: This fixes seeking back with the cursor keys and -bytes. [17:23:03] <BBB> is 1 << 32 0 or undefined? [17:24:20] <mru> undefined [17:24:53] <DonDiego> has anybody played around with gnash? [17:26:16] <kshishkov> what's that? [17:26:21] <iive> i tried it 1 or 2 years ago [17:26:21] <kshishkov> Flash Player? [17:26:32] <BBB> gnu flash right? [17:26:37] <iive> the ffmpeg plugin didn't produce anything but black picture. [17:26:39] <BBB> like a free flash player [17:26:55] <iive> GNuflASH [17:27:54] <iive> I even reported some issues related to gnash and boost... [17:27:59] <jai> lol gnash [17:28:20] <mru> iive: that they exist? [17:28:37] <kshishkov> yuck! boost as in "C++ libraries with size of whole WinXP distribution"? [17:28:56] <iive> well, boost were changing their api... something with threading ... [17:29:28] <iive> and I was very happy when i get rid of it... [17:31:17] <BBB> is the use of __builtin_* discouraged? [17:31:23] <BBB> or disallowed? [17:31:25] <kshishkov> IIRC, gnash is used in GLinux (i.e. Mandrake on Gdium). Outdated version, can't play newer YouTube. [17:31:29] <BBB> or is someone going to shoot me now? [17:31:33] <kshishkov> disallowed [17:31:35] <mru> BBB: it's gcc-specific [17:31:40] <BBB> aha [17:31:41] <BBB> ok [17:31:52] <mru> which builtin do you want to use? [17:32:17] <jai> kshishkov: also takes ages to compile [17:32:35] <iive> Well, about gnash, i decided to give it more time. maybe i should check it again. [17:32:45] <kshishkov> jai: yep, reminds me of my experience with compiling Firefox [17:32:56] <kshishkov> jai: IOW never again [17:33:40] <jai> kshishkov: heh, wise decision [17:33:47] <ohsix> mru used __builtin_clz with proper bumpers [17:34:01] <mru> yes [17:34:11] <mru> after thoroughly checking that it did the right thing too [17:34:11] <ohsix> for some stuff its great, as long as you have an alternate, go nuts [17:34:16] <ohsix> nod [17:34:48] <ohsix> iirc they're weak too, so if you define them yourself the compiler wont add them [17:35:08] <ohsix> then you can just do that when its not gcc [17:35:30] <mru> there's usually a better way than defining a function [17:35:39] <mru> and not all systems have weak symbols [17:36:46] <BBB> is 1 << -1 defined? [17:36:56] <ohsix> in c? [17:36:59] <BBB> ys [17:37:09] <BBB> or int x = -1; 1 << x;? [17:37:20] <BBB> probably not right? [17:38:23] <ohsix> dont know, sorry; 2s compliment should keep it the "same" with shifts [17:39:33] <mru> negative shifts are not defined [17:40:32] <ohsix> they depart from c but they work as you'd expect, right? [17:40:36] <mru> no [17:40:38] <mru> they do not work [17:40:40] <mru> at all [17:40:44] <mru> or very rarely [17:41:04] <mru> shifting negative numbers usually works as you'd expect [17:41:09] <ohsix> what of 0xff... in an unsigned integer [17:41:11] <mru> although that's not defined by the spec either [17:41:25] <ohsix> ic ic [17:41:41] <mru> you're only allowed to shift by a non-negative amount smaller than the width of the shifted operand [17:42:21] <ohsix> OH, SHIFTING by a negative number, not the shift-ee [17:42:27] <ohsix> i read that wrong [18:03:07] <CIA-17> ffmpeg: michael * r21606 /trunk/ffplay.c: [18:03:07] <CIA-17> ffmpeg: Autodetect when byte based seeking is better (that is for all formats that allow [18:03:07] <CIA-17> ffmpeg: discontinuities) [18:03:07] <CIA-17> ffmpeg: Fixes issue1090 [19:36:44] <CIA-17> ffmpeg: cehoyos * r21607 /trunk/libpostproc/postprocess_template.c: [19:36:44] <CIA-17> ffmpeg: Fix warnings about redefining constants when compiling libpostproc. [19:36:44] <CIA-17> ffmpeg: Patch by Yuriy Kaminskiy, yumkam mail ru [19:58:30] <CIA-17> ffmpeg: siretart * r21608 /branches/0.5/subdir.mak: [19:58:30] <CIA-17> ffmpeg: missing hunk to unbreak linking with symbol versioning [19:58:30] <CIA-17> ffmpeg: this hunk is does not apply in trunk/ because there the dependencies for [19:58:30] <CIA-17> ffmpeg: this rule was reworked [19:58:30] <CIA-17> ffmpeg: siretart * r21609 /branches/0.5/configure: [19:58:31] <CIA-17> ffmpeg: unbreak compilation with vhook enabled [19:58:32] <CIA-17> ffmpeg: the backported introduced a regression that prevents successfully [19:58:32] <CIA-17> ffmpeg: linking vhook shared objects on systems with gnu linkers. As the version [19:58:33] <CIA-17> ffmpeg: scripts only apply to shared objects against that applications are being [19:58:33] <CIA-17> ffmpeg: linked, this commit unties the VHOOKSHFLAGS and SHFLAGS variable. [20:14:49] <BBB> mru: oops forgot to cut tables bla bla etc. too big please allow ffmpeg-devel blieb [20:15:03] <BBB> (maybe I should just cut them and then resubmit) [20:17:37] <CIA-17> ffmpeg: siretart * r21610 /branches/0.5/libswscale/libswscale.v: fix version script for libswscale [20:18:18] <siretart> DonDiego: don't ask. I owe you at least one beer, probably more... [20:18:36] <Dark_Shikari> BBB: any update on that patent? [20:18:44] <BBB> didn't ask yet, I [20:18:48] <BBB> 'm going on vacation first [20:18:50] <Dark_Shikari> lol [20:18:52] <BBB> -newline [20:18:54] <DonDiego> hehe, i was about to.. [20:19:01] <DonDiego> well, beer event on friday.. [20:19:04] <DonDiego> :) [20:19:17] <BBB> didn't mru look at billions of nokia patents? [20:19:36] <mru> I only flipped through a couple of pages of hits at google [20:19:37] <DonDiego> wasn't it Dark_Shikari ? [20:19:44] <mru> Dark_Shikari looked more iirc [20:19:54] <DonDiego> anything that might apply to theora? [20:19:57] <BBB> I didn't erally pay attention :) [20:20:07] <BBB> the quant patents looked generic enough to apply to anything [20:20:13] <BBB> literally [20:20:20] <mru> almost all patents look like that [20:20:30] <DonDiego> are they part of the mpeg la portfolio? [20:20:48] <DonDiego> btw: http://mplayerhq.hu/~diego/avc_license.html [20:20:58] <Dark_Shikari> I looked at 280 patents [20:21:09] <Dark_Shikari> everything with "assignee: nokia" in it or whatnot [20:21:21] <Dark_Shikari> that may not cover them all, due to buyouts/etc [20:21:46] <DonDiego> did you find anything? [20:22:40] <Dark_Shikari> I pasted them here earlier when you asked [20:23:04] * DonDiego must have missed that.. [20:23:46] <Dark_Shikari> gle.com/patents/about?id=Ic0CAAAAEBAJ [20:23:53] <Dark_Shikari> er http://www.google.com/patents/about?id=Ic0CAAAAEBAJ [20:24:00] <Dark_Shikari> http://www.google.com/patents/about?id=ieIVAAAAEBAJ <--this patent is a huge wtf [20:24:06] <Dark_Shikari> http://www.google.com/patents/about?id=zGWBAAAAEBAJ [20:31:13] <CIA-17> ffmpeg: siretart * r21611 /branches/ (5 files in 5 dirs): backport cpu runtime detection for libpostproc and libswscale [20:34:01] <BBB> huh? [20:34:15] <BBB> maybe we should just forget about 0.5 and release a 0.6? [20:34:23] <DonDiego> nonsense [20:34:32] <mru> that's not how distros operate [20:34:33] <DonDiego> the 0.5 branch is being tracked by distros [20:34:56] <DonDiego> siretart himself is the debian/ubuntu packager [20:34:56] <siretart> BBB: I disagree. I'm currently 'just' upstreaming the pile of patches that have accumulated in the distro package [20:35:31] <siretart> BBB: while planning 0.6 is certainly a great idea [20:35:35] <BBB> cpu detection is a new feature [20:35:45] <Dark_Shikari> just pick a revision and call it 0.6 [20:35:46] <Dark_Shikari> done [20:35:50] <BBB> or is it considered a bugfix? in which case, what bug does it fix without adding a new feature? [20:36:05] <siretart> BBB: oh, you're right, that is a bit misleading. only the configure parts are backported, not the feature itself [20:36:09] <BBB> (the feature that it adds being: "cpu runtime detection") [20:36:38] <BBB> hmk, then change the revision msg, this is confusing [20:36:41] <BBB> as you can see :) [20:37:38] <siretart> are log edits announced by CIA as well? [20:38:13] <siretart> wow. I didn't know that emacs makes editing commit logs *that* easy... [20:38:29] <Dark_Shikari> it's the only good thing about svn [20:38:31] <Dark_Shikari> editing commit logs is easy [20:38:37] <Dark_Shikari> well, along with the other good thing: it's not cvs [20:39:47] <siretart> *shrug* [20:40:04] <BBB> I see it on the mailinglist [20:40:05] <BBB> so it's ok [20:40:07] <BBB> thanks [20:45:39] <CIA-17> ffmpeg: siretart * r21612 /branches/ (0.5 0.5/configure): [20:45:40] <CIA-17> ffmpeg: Add gnu/kfreebsd to list of recognized operating systems. [20:45:40] <CIA-17> ffmpeg: patch by Andres Mejia, mcitadel gmail com [20:46:18] <DonDiego> bye, cu [20:47:20] <siretart> byebye [20:49:11] <CIA-17> ffmpeg: siretart * r21613 /branches/0.5/configure: build PIC code on G3 macs [20:50:41] <mru> siretart: that builds pic on *all* ppc [20:50:57] <mru> maybe that's what you want, I don't know [20:52:57] <siretart> mru: at least on debian ppc system, linking against shared libraries fails. and I would be quite surprised if this was a debian speciality... [20:53:11] <mru> so why mention g3? [20:53:21] <mru> there is nothing g3-specific in the commit [20:53:38] <siretart> oh, if that's your objection, I'll fix the commit message [20:54:14] <mru> I also doubt that PIC is real issue here [20:55:00] <mru> not that it really matters [20:56:16] <siretart> hm. no, this wasn't a link issue, but rather a runtime issue: /usr/lib/libavformat.so.52: R_PPC_REL24 relocation at 0x0d925f74 for [20:56:19] <siretart> /usr/lib/libavformat.so.52: R_PPC_REL24 relocation at 0x0d925f74 for [20:56:41] <mru> that's a linker problem [20:56:59] <siretart> indeed, I was wrong [20:57:04] <mru> something used a 24-bit relocation and the dynlinker decided to put the libs more than 24 bits apart [20:57:24] <mru> pic only solves that as a side-effect [20:57:55] <siretart> the next line was: 'symbol `fcntl' out of range' [20:58:01] <mru> with pic, all external references go through a per-library GOT [20:58:13] <mru> and the GOT has 32-bit relocations [20:58:47] <mru> it could still fail if a single lib grew larger than 1<<24 bytes [20:58:54] <siretart> how can this issue be prevented without pic? [20:58:56] <mru> or maybe it's x4 on top of that [21:00:58] <mru> -mlongcall would probably fix it [21:01:26] <mru> the linker could also add trampolines as necessary [21:01:29] <mru> but it doesn't [21:09:15] <siretart> log message updated [21:32:16] <CIA-17> ffmpeg: michael * r21614 /trunk/ffplay.c: [21:32:16] <CIA-17> ffmpeg: Commit disapeared hunk, must have editied this out by mistake between local debug statements. [21:32:16] <CIA-17> ffmpeg: This should fix seeking in TS. [22:23:58] <CIA-17> ffmpeg: cehoyos * r21615 /trunk/ (libavformat/flvenc.c ffmpeg.c): [22:23:58] <CIA-17> ffmpeg: Guess the duration before converting video and write guessed duration [22:23:58] <CIA-17> ffmpeg: into flv header. [22:23:58] <CIA-17> ffmpeg: Patch by Justin Johnson, justin D johnson3 A gmail [22:44:00] <CIA-17> ffmpeg: michael * r21616 /trunk/ffplay.c: [22:44:01] <CIA-17> ffmpeg: Move the initial refresh scheduling for audio display away from where it [22:44:01] <CIA-17> ffmpeg: can interfere with video. [22:58:45] <CIA-17> ffmpeg: cehoyos * r21617 /trunk/libavcodec/rawdec.c: Fix r21223: AVup samples (issue 1685) need a buf offset like AV1x (issue 1684). [23:09:22] <ramiro> hi [23:10:53] <ramiro> is a movslq from 32-bit to the same 64-bit register any kind of speed penalty? [23:11:38] <Dark_Shikari> you mean movsxd? [23:11:43] <Dark_Shikari> it takes one uop [23:13:06] <ramiro> hmm... I'm wasting so much time because of 1 uop... [23:23:23] <CIA-17> ffmpeg: michael * r21618 /trunk/ffplay.c: [23:23:23] <CIA-17> ffmpeg: Compare the correct clocks for syncing video to audio/ext. [23:23:23] <CIA-17> ffmpeg: Fixes initial delay on video from issue1134. [23:54:27] <CIA-17> ffmpeg: michael * r21619 /trunk/libavformat/avidec.c: Set nb_frames.

1 0

IRC log for 2010-02-01
by irc＠mansr.com 02 Feb '10

02 Feb '10

[00:02:15] <sab> how can I change my nick? I see sab is already taken [00:02:24] <sab> (i mean registered) [00:02:36] <mru> /nick [00:02:53] <sab> oh i see [00:03:13] <ramiro> mru: what's the topic on reddit? [00:03:21] <mru> http://www.reddit.com/r/programming/comments/aw6vo/even_the_best_compilers_… [00:08:21] <sab> nick stefano [00:08:27] <sab> oops [00:19:39] <CIA-17> ffmpeg: michael * r21580 /trunk/libavcodec/options.c: [00:19:39] <CIA-17> ffmpeg: Set reordered_opaque during context alloc by default to AV_NOPTS_VALUE. [00:19:39] <CIA-17> ffmpeg: This should make sure that pictures allocated prior to avcodec_decode_video() [00:19:39] <CIA-17> ffmpeg: get AV_NOPTS_VALUE assigned. [00:19:39] <iive> mru: does any compiler produce faster code if you have p[i].b++; instead of p[i].b+=a; ? [00:20:17] <mru> don't know [00:23:21] <iive> hum, in your hand written code, i think r2 is used without been filled. [00:23:38] <mru> r2 is the function argument [00:23:47] <iive> hum. [00:23:52] <mru> the first four args are passed in r0-r3 [00:23:55] <iive> oh, i see [00:24:01] <iive> i got confused by .a [00:26:57] <DonDiego> gnite [00:28:07] <saste> good night all! [00:28:19] <Vitor1001> good night saste! [00:29:38] <ramiro> saste: manchester? [00:29:57] <ramiro> I thought you lived in italy [00:30:05] <mru> ramiro: random server [00:30:09] <ramiro> oh, right... [00:30:19] <ramiro> it's freenode that has a server there. [00:30:31] <mru> I'm apparently connected through paris [00:31:07] <mru> saste: now register [00:40:30] <ramiro> bye... [00:49:45] <Yuvi> hm, how could an configure endian check work with llvm LTO? [00:49:45] <Yuvi> -c with LTO implies llvm bitcode, which is always little endian and stores integer constants as variable length [00:50:17] <mru> I guess it would break [00:50:32] <mru> but it's not a problem [00:50:40] <mru> the endian check is done before optimisation flags are added [00:51:06] <Yuvi> but not before user cflags are added [00:51:49] <mru> I'll have to think of something then [00:52:06] <astrange> 1. forbid doing it 2. generate a program instead of an object 3. make llvm do hybrid LTO like gcc [00:52:10] <astrange> ? [00:52:24] <mru> 2 sounds like a good option [02:56:04] <BBB> mru, can you ok my msg to ffmpeg-devel again? [02:56:33] <mru> hmm, why was I expecting that? [02:57:04] <mru> you might want to omit the huge tables in future patch postings [02:58:03] <BBB> nobody said I could commit them [02:58:17] <BBB> reply to the list and tell people to allow me to commit data... [02:58:30] <mru> I meant omit them from the patch you post to the list [02:58:37] <mru> nobody is going to be looking at them right now [02:58:38] <BBB> hm... ok [02:58:53] <BBB> next time I will [03:05:20] <astrange> unsigned int acb_type:2; <- can you make enum types a bitfield and end up with the right layout? [03:06:28] <mru> uh? [03:06:58] <astrange> enum ACBType {ACB_TYPE_NONE,...}; ... ACBType acb_type:2; [03:07:06] <mru> why would you want to do that? [03:07:16] <mru> didn't we just agree that bitfields are bad? [03:07:39] <mru> and the memory layout is unspecified [03:08:39] <astrange> i was thinking of reading from a file using bitfield structs when i said that [03:08:57] <mru> as I said, unspecified [03:09:02] <astrange> but for local data just uint8_t is still better, yeah [03:09:12] <mru> *never* read from a file or whatever into a struct [03:09:47] <Vitor1001> BBB: the function aw_pulse_set2() still bothers me [03:11:42] <Vitor1001> It takes as input five values: s->aw_first_pulse_off[block_idx], s->aw_pitch_range, s->aw_n_pulses[0], s->aw_next_pulse_off_cache and get_bits(gb, s->aw_n_pulses[0] ? 5 - 2 * block_idx : 4); [03:11:59] <Vitor1001> and it output basically just start_off [03:12:52] <CIA-17> ffmpeg: michael * r21581 /trunk/ffplay.c: 10l, forgot HAS_ARG, -drp segfaulted. [03:13:12] <Vitor1001> for that, it uses a intermediary bit buffer, do a double for-loop (one outer one running up to 500 iterations) [03:13:34] <BBB> Vitor1001, I agree it sucks, I unfortunately don't really understand the function [03:13:49] <BBB> set1() was a mess also, multiple loops and double-loops, but I was able to sort of clear that up [03:13:54] <BBB> and your comment made it even simpler [03:14:03] <BBB> set2() sucks, and I don't quite get it :( [03:14:19] <Vitor1001> set1() is nice now [03:14:49] <mru> bedtime, it's pi o'clock here [03:14:50] <BBB> you should look at the original :) [03:15:08] <BBB> g'night mru [03:15:12] <Vitor1001> I can imagine ;) [03:15:34] <Vitor1001> About reimar's comments [03:15:36] <Vitor1001> "> > I guess you can find all of those on your own. " [03:15:50] <Vitor1001> He was talking about doxy comments inside functions [03:16:02] <Vitor1001> it generates crazy nonsense doxy output [03:16:50] <BBB> I noticed [03:16:51] <BBB> the doxy looks weird [03:16:59] <BBB> it looks nice in the code though [03:17:05] <BBB> maybe I should remove them anyway... [03:17:13] <Vitor1001> So what reimar suggested (and I agreed) is not to doxyfy them [03:17:22] <BBB> ok, I'll go through the code [03:17:36] <Vitor1001> And about finding the first non-zero bit [03:18:15] <BBB> I suppose there's some hideous asm for that? [03:18:16] <Vitor1001> You first find the first non-zero byte [03:18:27] <BBB> they're ints, not bytes [03:18:32] <Vitor1001> and them you use av_log() [03:18:32] <BBB> you suggest I make them bytes first? [03:18:35] <Vitor1001> Better yet. [03:18:44] <Vitor1001> No. Just find the first non-zero int [03:18:48] <Vitor1001> and av_log() it. [03:19:07] <Vitor1001> should be more than 32x faster [03:19:23] <astrange> i was going to complain about the use of 'double', but i guess that's already brought up [03:19:34] <BBB> I will change it to float as I test all of them [03:19:48] <BBB> I can make wmavoice float but it won't make a difference [03:19:54] <BBB> lsf->lpc is still float [03:19:57] <BBB> er, double [03:20:02] <BBB> I want that function double first [03:20:32] <BBB> and I need to test sipr, g729, acelp, etc. for that also [03:20:38] <Vitor1001> sipr is ok [03:20:42] <Vitor1001> g729 is fixed point [03:20:51] <Vitor1001> acelp == sipr [03:20:55] <BBB> well there was one where it was bad [03:20:58] <BBB> qclep? [03:20:59] <Vitor1001> QCELP [03:20:59] <BBB> celp? [03:21:03] <BBB> oh ok [03:31:04] <astrange> + s->lsp_q_mode = flags & 0x2000; <- !!(flags & 0x2000) [03:31:09] <astrange> and the associated variable (and more) can be uint8_t [03:32:24] <astrange> + for (idx = pulse_start; idx < 0; idx += fcb->pitch_lag); <- space before ; (and in some other places) [03:33:09] <astrange> and then lower down [03:33:15] <astrange> + int fac = ((n << 1) | 1); <- n * 2 + 1 [03:33:21] <astrange> that's enough for now [03:36:10] <BBB> isn't n<<1|1 faster? [03:36:44] <BBB> at least, isn't |1 faster than +1? [03:36:46] <astrange> no [03:36:49] <BBB> oh [03:37:00] * BBB changes several useless occurrences of |1 [03:37:24] <BBB> is <<1 faster than *2? [03:37:40] * BBB always thought shifts were faster than muls [03:37:55] <astrange> on x86 n (<< 1)/(* 2) (+ 1)/(| 1) all compile to lea 1(%x,%x) so it's all the same [03:38:40] <astrange> and << 1 is faster than * 2 but nearly any compiler will change it back [03:38:51] <astrange> but n*2+1 needs less parens [03:40:17] <BBB> !!(flags&0x2000)? [03:40:19] <BBB> why that? [03:40:28] <BBB> so it fits in a int8_t? [03:40:30] <BBB> does that matter? [03:40:36] <astrange> the comment for the var says it's [0,1] [03:40:40] <astrange> flags & 0x2000 isn't 0,1 [03:40:50] <BBB> oh [03:40:52] <BBB> hm... [03:40:57] <BBB> shall I say [bool]? [03:41:26] <astrange> you could put != 0 if you like that better [03:41:39] <astrange> i think it's easier to read in a debugger if the bools are just 0,1 [03:42:27] * BBB doesn't really care [03:42:37] <BBB> no more gdb for me on this one [03:42:40] <BBB> I'll add != [03:42:42] <BBB> != 0 [03:44:02] <BBB> hm [03:44:09] <BBB> I think I never tested with that flag set [03:44:18] <BBB> I just see I use the second one as a table index [03:44:21] <BBB> so [0] or [0x4000] [03:44:22] <BBB> bad [03:44:26] * BBB changes to !! [03:46:00] <BBB> ok, time to go, thanks so far [03:46:05] <BBB> Vitor1001, will work on set2() [03:46:11] <Vitor1001> Thanks [03:46:16] <Vitor1001> I was looking at it now [03:46:38] <BBB> send replies to the mailinglist i you have more suggestions, I'll try using av_log2() to find unset bits [03:46:50] <BBB> the first line of that 500-time-loop can be moved out of the loop [03:46:53] <BBB> it's always the same [03:46:57] <Vitor1001> Please try first getting rid of the loops ;) [03:47:07] <BBB> I will try [03:47:12] <BBB> can't guanantee [03:47:13] <BBB> :) [03:47:24] <Vitor1001> I also have a hard time understanding what this func does [03:47:47] <BBB> there's research papers on this kind of coding [03:47:53] <BBB> I think I need to read one of them [03:47:57] <BBB> do you have free access to them? [03:47:58] <Vitor1001> And I _hate_ wmavoice habit of using negative vector indexes! [03:48:10] <BBB> yes, ... :( [03:48:11] <Vitor1001> its unlikely, but I can try [03:48:15] <Vitor1001> send me the link in pvt [03:48:23] <BBB> ok, but tomorrow [03:48:26] <BBB> wife is calling :) [06:55:51] <ohsix> mru: have you looked at the graphite changes in gcc? [06:56:43] <astrange> they aren't useful for anything we do [06:56:50] <astrange> maybe for that sbr kernel [06:57:36] <Dark_Shikari> aren't they designed to compensate for stupid programmers? [06:57:42] <Dark_Shikari> e.g. people looping the wrong way around a 2D array [06:58:50] <ohsix> heh, preconditions can change, loop transformations can ensure they're always correct with regard to cache sizes and whatnot, has nothing to do with "stupid programmers" [06:59:05] <elenril> wait, svn log downloads the log from server? [06:59:19] <Dark_Shikari> ohsix: um, but it's the programmer's job to consider the cache size [06:59:31] <Dark_Shikari> for any code that iterates overly a sufficiently gigantic array [06:59:35] <ohsix> it just makes it more scalable without murdering your code [06:59:38] <Dark_Shikari> since such code is _so incredibly rare_ [06:59:59] <Dark_Shikari> I mean, how often do people loop over 50 megabyte arays? [07:00:44] <ohsix> the compiler knows the cache size, if you're doing something for a cache size thats more than available here then what are you really doing, with the loop transforms i can have it chunk it up and reorder it for the small cache size without manual effort [07:01:16] <Dark_Shikari> >the compiler knows cache size [07:01:16] <Dark_Shikari> hahahahahaha [07:01:41] <Dark_Shikari> that's impressive, an optimization that doesn't work with any march other than native [07:02:02] <Dark_Shikari> by comparison, the programmer could just detect the cache size and make it handle all kinds of cache sizes with a few minutes of effort [07:02:11] <ohsix> it wont transform the code [07:02:28] <ohsix> you end up with a certain degree of waste doing that too [07:02:39] <Dark_Shikari> sure, but much less than the compiler would have [07:03:24] <ohsix> you know that for sure in every case that may ever be encountered? [07:04:03] <Dark_Shikari> why does it matter? [07:04:14] <Dark_Shikari> even if the compiler is worse only 90% of the time as opposed to 100%, that's good enough to not trust it [07:04:35] <ohsix> its your foil, not mine; if you know that to be true, and thats why you said it, surely nothing i could say matters [07:04:36] <Dark_Shikari> plus, I don't think I can name a single optimization, of all the things gcc does, that a human isn't better at [07:05:40] <Dark_Shikari> better or tied, at least [07:05:48] <Dark_Shikari> though I'd be hard-pressed to even find a tie case [07:05:50] <ohsix> i get it [07:06:00] <ohsix> but its a straw man [07:06:10] <Dark_Shikari> yes, I agree with mru, deal with it ;) [07:06:35] <ohsix> i guess its better than a religion in some ways :> [07:07:05] <ohsix> btw, enjoying flaming people doesn't neccisarily mean you agree, or understand the perspective of someone; just that you enjoy throwing your shit in [07:07:12] <benoit-> moin [07:07:28] <Dark_Shikari> ohsix: I'm pretty sure mru will confirm that he agrees with me. [07:07:55] <ohsix> thats a red herring [07:08:22] <Dark_Shikari> I prefer blue herrings. [07:08:49] <ohsix> loglcal fallacies follow with irrationality i guess :D [07:09:15] <Dark_Shikari> red herrings are a type of logical fallacy? [07:09:21] <Dark_Shikari> nor is that a red herring [07:09:32] <Dark_Shikari> you made bizarre accusations that made no sense [07:09:36] <Dark_Shikari> simply because I said "mru would agree with me" [07:09:50] <Dark_Shikari> and then when I called you on your bull, you yelled "red herring" [07:10:07] <Dark_Shikari> I said "mru would agree with me" because *we were having this discussion earlier, and he agreed with me* [07:10:12] <ohsix> i'm not making accusations, you know not what you do [07:10:23] <Dark_Shikari> ... I "know not what I do"? [07:10:28] <Dark_Shikari> wtf [07:10:38] <Dark_Shikari> I said someone would agree with me because they agreed with me. [07:10:45] <astrange> gcc is probably better at RISC register allocation for a large function [07:10:46] <Dark_Shikari> Is there now something wrong with this? [07:10:58] <astrange> and some non-gcc compiler is probably better at minimizing instruction size [07:11:19] <Dark_Shikari> I wouldn't be surprised about that, minimizing instruction size is easier than making fast code [07:11:31] <Dark_Shikari> humans have tricks up their sleeves though [07:11:50] <Dark_Shikari> But most of the really evil ones that compilers can't do (self-modifying code, etc) are so horrific [07:11:52] <Yuvi> astrange: 32+ registers? what I've seen of gcc register allocation on arm it was pretty stupid [07:11:59] <ohsix> humans = http://en.wikipedia.org/wiki/Oracle_machine [07:12:26] <Dark_Shikari> ohsix: that's actually how they do AI problem computational complexity [07:12:32] <Dark_Shikari> treat a human as an Oracle machine for a Turing machine [07:12:48] <astrange> 4.4 or earlier than 4.4? [07:12:55] <ohsix> no kidding? wow [07:13:02] <Yuvi> mostly earlier I guess [07:13:20] <astrange> it was rewritten for 4.4, the algorithm is much better now (and better than llvm's) [07:13:54] <ohsix> anyways; graphite has been in gcc for a while, its still disabled on some distros, its worth a shot trying clean, dumb code to see how it does against the rearranged stuff [07:14:05] <astrange> the interaction with reload (the last pass) is still bad and destroys lots of good work in 4.5 though, so it sometimes acts badly anyway [07:14:12] <Dark_Shikari> for reference, someone tested graphite on x264, iirc it was slightly slower [07:14:26] <Dark_Shikari> ohsix: http://en.wikipedia.org/wiki/AI-complete#Results [07:14:40] <astrange> oh, and on x86 it's faster to recalculate stuff than it is to save to stack, gcc never does that [07:14:44] <ohsix> someone? did they keep track of what they were doing [07:15:11] <Yuvi> is that why gcc 4.4 will still emit useless reg->reg movs on arm? [07:15:17] <Dark_Shikari> ohsix: it's probably somewhere in the depths of the x264 builds thread on doom9 [07:15:23] <astrange> probably [07:15:30] <astrange> can i bootstrap an arm compiler from the iphone sdk? [07:15:50] <ohsix> Dark_Shikari: i was being facetious, and no incredulous that you understand what an oracle machine is to a turing machine but you don't understand that what you're saying about gcc with regard to doing it by hand is a logical fallacy [07:16:15] <ohsix> s/no/now [07:16:15] <Yuvi> I haven't tried a fsf gcc targeting iphone, I'd be surprised if apple's patches for that made their way upstream [07:16:51] <astrange> i don't care what it targets, i just want to read gcc -S [07:18:52] <Dark_Shikari> ohsix: you have yet to actually name a specific logical fallacy [07:19:13] <ohsix> Dark_Shikari: you can use --param l1(2)-cache-size to set it if gcc doesn't get it [07:19:22] <Dark_Shikari> but again, it only works with native [07:19:28] <ohsix> i do? i'd rather you figure it out [07:19:30] <Dark_Shikari> i.e. conceptually compiling for the current machine only [07:20:01] <Dark_Shikari> "I'd rather you figure it out" <--So you have no clue what you're talking about, so you instead request that I try to dig you out of the hole you dug [07:20:04] <Dark_Shikari> sorry, no [07:20:11] <ohsix> --param has a lot of machine description stuff so you can set it straight if it doesn't have the right information [07:20:26] <Dark_Shikari> again, the point is that kind of optimization is extremely machine-specific [07:20:40] <Dark_Shikari> most use-cases for gcc don't involve compiling for a single computer [07:20:42] <ohsix> it'd be a much more useful device if you would figure out what it is yourself [07:20:46] <Dark_Shikari> except Gentoo [07:20:54] <Dark_Shikari> and we don't care about Gentoo [07:21:43] <Dark_Shikari> ohsix: so in order, you have decided to spend today trolling [07:21:53] <Dark_Shikari> *so, in short [07:22:09] <Dark_Shikari> well, unfortunately, trolls don't get fed for long here. [07:22:10] <ohsix> and you had already been set on ad hominem [07:22:44] <superdump> morning [07:22:52] <Dark_Shikari> \o [07:23:18] <pJok> mornings :) [07:28:01] <ohsix> hrmph when did /join stop switching to the right channel if you're already on it on irssi [07:30:34] <jai> why the kb? [07:31:15] <Dark_Shikari> ban to prevent autorejoin, then instant unban [07:31:43] <Dark_Shikari> if you mean the reason, he was trolling for like the past 20 minutes [07:31:59] <Dark_Shikari> accusing me of a logical fallacy and not shutting up about it--but when asked what it was, refusing to tell me [07:32:18] <jai> right, i should've read the log [07:32:53] <ohsix> there was no accusation; i was merely informing, as was the original query about recent changes in gcc and if anyone had evaluated them [07:33:04] <Yuvi> astrange: http://www.mediafire.com/?ywkmbzhgtjo if you haven't compiled a toolchain yet [07:33:24] <ohsix> i frankly don't much care what you'll do with any information beyond answering the original query :) [07:33:58] <jai> ohsix: *awnsering :) [07:34:09] <ohsix> thx [07:35:06] <ohsix> speaking of, is there a clean/dumb version of every component in ffmpeg available somewhere? like a reference impl; so you can check it against the permuted versions [07:37:08] <ohsix> anything that tries to outsmart the compiler will be affected in different ways as the compilers change, global transformation stuff can reach lower global minimums, but if you cant test if they do when they're added to the compiler, you cant know :\ [07:38:15] <ohsix> the irony being, this type of "optimization" diverges from the literal definition of it in the end, huhuhuhu [07:39:08] <ohsix> its more like simulated annealing without the statistical check, and human inputs that aren't in the same measurement space [07:39:52] <ohsix> which of course perverts the original intent [07:40:20] <astrange> --disable-asm is the closest thing available [07:40:34] <ohsix> k, thanks [07:41:59] <astrange> but if you're running acovea or something on that the results will be different from with asm [07:42:05] <astrange> and the profiles will also be completely different [07:42:10] <ohsix> dark_shikari: as to this wrt: x264, i have no doubt it would be slower, but not to what degree [07:42:19] <astrange> and it's more useful to optimize the default configuration than to optimize c only... [07:42:39] <ohsix> astrange: ah, nah acovea isn't on the map, just checking out some of the program transformation that came with graphite/cloog [07:42:39] <astrange> anyway if fate can track speed i'll be sure to bug gcc@ about it [07:44:38] <ohsix> what i have in mind though; is how it scales by cache size, cuz theres some rather anemic stuff out there thats on the cusp of working just fine without changes, but you cant reasonably account for the entire breadth of cache sizes and processors with certain types of modifications that should rightly be done for the best case [07:45:12] <ohsix> like places where -Os can swamp -O3 just because the code is smaller [07:45:38] <astrange> that's most places actually. -O3 is badly overtuned [07:45:54] <astrange> mostly because of loop unrolling never being beneficial on x86-32 [07:46:05] <ohsix> well heh yea, but you know what i mean [07:48:23] <ohsix> you could make gcc stop doing that sort of thing, one of the --param things is a quantum/chunk size for that sort of decision, set it so it never decides to do it, or under rarer/smaller circumstances [07:57:15] <ohsix> has anyone tinkered with this ? http://trad4.sourceforge.net/ [07:59:02] <KotH> moin [08:00:00] <osaft> moin moin [08:07:41] <astrange> Yuvi: yours and the iphone one can't find their crt1.o, i think i can bootstrap with the DS compiler i have [08:10:13] <Yuvi> oh yeah, I stripped out the sysroot since it was like 200 MB, http://www.beagleboard.org/uploads/arm-2007q3-macosx-20080828.tar.bz2 has a sysroot [08:11:36] <ohsix> trad4 basically just makes closures for objects you put in the template and schedules threads/ordering, its neat [08:50:27] <astrange> ugh, some of the hq mpeg4 encoding stuff doesn't work with sse2 [08:51:11] <astrange> and dsp_mask isn't in the cli [08:51:29] <Dark_Shikari> why would it not work with sse2? [08:51:37] <Dark_Shikari> if the alignment requirements are wrong, there need to be multiple function pointers [08:52:31] <astrange> alignment for some things isn't satisfied [08:53:37] <astrange> oh, it's the same one snow crashes on [09:12:50] <astrange> sse2 idct crashes too, that's definitely the caller's fault [09:13:11] <astrange> well, it works with simpleidct, i forgot how slow b-strategy 2 was.... [09:14:26] <Dark_Shikari> what does b-strategy 2 actually do anyways? is it viterbi? [09:14:43] <Dark_Shikari> because you can't compare 2 b-frames and 3 b-frames since the number of frames each covers is different [09:16:36] <astrange> brute force rd estimate with optional input downscaling [09:16:57] <Dark_Shikari> I know that part [09:17:05] <Dark_Shikari> but what does it actually _compare_? [09:17:09] <Dark_Shikari> you can't compare PBBP to PBBBP [09:17:15] <Dark_Shikari> because they cover a different number of frames [09:20:00] <astrange> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/mpegvideo_enc.c;h=aaf0c… whatever pattern 1020 results in [09:21:08] <Dark_Shikari> oh. it does it the stupid way [09:21:30] <superdump> patches welcome [09:21:48] <Dark_Shikari> fixing it would involve an x264-alike lookahead system [09:22:13] <Dark_Shikari> and it would get a lot slower [09:22:15] <superdump> so without lookahead, it's the best that can be done? [09:22:23] <Dark_Shikari> well it already effectively does have a lookahead [09:22:26] <Dark_Shikari> I'm not sure how far it looks ahead though [09:22:30] <Dark_Shikari> er, I mean [09:22:38] <Dark_Shikari> I'm not sure how much work it would require to make it look ahead much further [09:22:49] <Dark_Shikari> it'd definitely have to cache the rd values for various P/B combinations [09:23:14] <astrange> mpegvideo enc needs a lot of work. it'd be a great soc project except the student would have to already be an encoder developer [09:23:21] <Dark_Shikari> :/ [09:23:27] <Dark_Shikari> I wonder if it would be easier to turn x264 into an mpeg2 encoder [09:24:39] <superdump> it'd be GPL though [09:24:51] <Dark_Shikari> true [09:24:57] <superdump> GPL/commercial? [09:25:03] <superdump> have you done the dual licensing thing? [09:25:05] <Dark_Shikari> it'd also be bloated as hell [09:25:13] <Dark_Shikari> because it would be extra work to remove a lot of unnecessary stuff [09:25:22] <Dark_Shikari> dual licensing work is ongoing [09:25:27] <Dark_Shikari> got most of the CLAs in [09:26:00] <Dark_Shikari> waiting on Avail--apparently their lawyers didn't get the clue and decided to play the "let's add every single clause we've ever seen to the agreement, just to make sure" game, much to te chagrin of both me *and* my friends at Avail [09:26:50] <superdump> :/ [09:27:06] <Dark_Shikari> so my boss there is going to whack them into shape [09:27:18] <CIA-17> ffmpeg: michael * r21582 /trunk/ffplay.c: Simplify get_video_clock() [09:27:46] <Dark_Shikari> though another question is how much people care about mpeg-2 anymore [09:27:58] <Dark_Shikari> by the time an improved mpeg-2 encoder is done, even fewer people will care about it [09:28:07] <Dark_Shikari> and a lot of the more useful improvement would be stuff like vbv etc [09:54:26] <CIA-17> ffmpeg: thilo.borgmann * r21583 /trunk/libavcodec/alsdec.c: Remove unnecessary fields in ALSSpecificConfig. [10:00:33] <siretart`> morning [10:17:30] <KotH> vormittag [10:19:20] <siretart`> KotH: did you receive my mail in time? [10:20:21] <KotH> yes [10:20:32] <KotH> thanks [10:20:41] <KotH> you were the only one who told us ^^' [10:33:05] <CIA-17> ffmpeg: michael * r21584 /trunk/ffplay.c: [10:33:05] <CIA-17> ffmpeg: Try to more completely update time variables on unpause. [10:33:05] <CIA-17> ffmpeg: Could not notice a differenc in behavior. [10:45:17] <benoit-> OMG [10:45:28] <benoit-> seen on the wiki at my workplace: [10:45:32] <benoit-> "NOTE: Using dash as /bin/sh may cause some problems, please change /bin/sh to bash. " [10:45:40] <benoit-> :'( [10:45:51] <thresh> lol [10:45:54] <benoit-> (I had to share that crying moment with you) [10:46:05] <benoit-> well [10:46:11] <benoit-> this is wiki, I can correct that :) [10:47:09] <pross-au> Wikis, helping morons and experts since 1999 [10:54:43] <benoit-> pross-au: :) [10:56:44] <CIA-17> ffmpeg: michael * r21585 /trunk/ffplay.c: Fix race condition with reading between video_current_pts and video_current_pts_time. [10:57:13] <jez9999> Ward Cunningham started developing WikiWikiWeb in 1994 [10:57:14] <jez9999> ;-) [10:58:43] <pross-au> Ah crap, just proved i am a moron [11:00:24] <merbzt> pic size stuff ? [11:14:00] <elenril> anyone can apply a patch for me? [11:16:51] <pross-au> sure. is it approved? [11:18:16] <elenril> yes, michael and bcoudrier reviewed it [11:18:27] <elenril> thread 'add a list of generic tag names' [11:21:07] <pross-au> Sat, 16 Jan 2010 12:52:23 +0100 <-- this one [11:26:18] <elenril> yes [11:26:44] <elenril> but it probably won't apply cleanly, i'll upload a rebased version in a sec [11:27:07] <elenril> http://filebin.ca/dzezck/0001-Add-a-list-of-generic-tags.patch [11:28:56] <pross-au> rgr [11:31:20] <CIA-17> ffmpeg: michael * r21586 /trunk/ffplay.c: [11:31:20] <CIA-17> ffmpeg: Schedule refreshes from a thread that actually knows the PTS. [11:31:20] <CIA-17> ffmpeg: Fixes wernfried_1.avi [11:31:38] * elenril sighs [11:31:58] <elenril> now you'll have to increment revision in docs/APIchanges [11:32:50] <pross-au> Cool [11:39:10] <merbzt> awesome !!! [11:40:00] <CIA-17> ffmpeg: pross * r21587 /trunk/ (12 files in 2 dirs): [11:40:00] <CIA-17> ffmpeg: Add a list of generic tags and change demuxers to follow it. [11:40:00] <CIA-17> ffmpeg: Patch by Anton Khirnov, wyskas at gmail dot com [11:40:11] <elenril> pross-au: thanks [11:41:13] <pross-au> thank you [11:57:01] <DonDiego> fftrollbot: greetings, troll [11:57:49] <siretart`> DonDiego: hi [11:57:53] <DonDiego> hi [11:58:08] <DonDiego> siretart`: repent evil sinner! [11:58:21] <siretart`> DonDiego: regarding 'butchering', I of course did 'only' append to config.h. [11:58:40] <siretart`> DonDiego: but in the end, I did locate and backport the patch from trunk to 0.5 [11:58:42] <DonDiego> that's still a penance [11:59:03] <DonDiego> the sins of the mind are no less sins than the sins of the actions [11:59:10] <siretart`> DonDiego: regarding the next release, that's exactly what I wanted to discuss with you at FOSDEM [11:59:26] <DonDiego> 7 hail marys for you [11:59:52] <siretart`> DonDiego: the thing is that the backported patch does have other changes that I rather wanted to avoid [12:00:07] <DonDiego> which revision? 18380? [12:00:20] <siretart`> DonDiego: well, it turned out that most of them were indeed trivial, so I just took them [12:00:39] <siretart`> sec, I'm looking up the patch [12:02:04] <siretart`> DonDiego: how are your studies going along? [12:02:48] <siretart`> http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff_plain;h=dd47be64953f558826456e… [12:02:52] <siretart`> is what I've backported [12:02:59] <DonDiego> stalled, my professor broke his leg.. [12:03:06] <siretart`> oh :-( [12:03:12] <av500> you tripped him? [12:03:20] <ohsix> ^ ++ [12:03:46] <DonDiego> hehe [12:03:57] <DonDiego> siretart`: you also want libswscale r29154 [12:04:14] <DonDiego> siretart`: and i would prefer you to backport this to the 0.5 branch [12:04:42] <siretart`> DonDiego: since my packages track the 0.5, I backport to nothing else [12:04:56] <siretart`> DonDiego: or do you want me to commit them to svn? [12:06:19] <siretart`> oh indeed, r29154 of libswscale is very relevant. damn [12:06:54] <DonDiego> yes, commit to svn [12:07:02] <DonDiego> that's the whole point of the branch [12:07:18] <DonDiego> i don't want every other packager to duplicate your work [12:07:28] <siretart`> well, then you'd need to authorize me. I can only commit to mplayer, not ffmpeg [12:07:42] <DonDiego> i don't think so, let me doublecheck.. [12:07:58] <siretart`> I think I've tried a few days ago… [12:08:19] <DonDiego> indeed [12:09:49] <DonDiego> fixed [12:10:16] <DonDiego> siretart`: do you know how to properly backport changes with subversion? [12:10:35] <DonDiego> i.e. using svn merge and an svn version >= 1.5 [12:10:38] <siretart`> okay. do I need to care about magic svn merge properties, or can I stage my commit via git-svn? [12:11:08] <siretart`> oh, obviously the latter [12:11:20] <siretart`> err, the former [12:11:36] <DonDiego> dunno [12:11:49] <DonDiego> if in doubt, use the original client [12:11:49] <mru> svn makes simple things so complicated... [12:11:52] <siretart`> okay, I'll read up the documentation for the details. [12:12:08] <ohsix> so does cvs ;) [12:12:14] <mru> no [12:12:17] <mru> cvs is very simple [12:12:31] <mru> the trouble is it can only do very simple things [12:12:32] <siretart`> but may I ask you why you insist on that feature? AFAIUI it is only useful if you intend to merge back to trunk, which I don't think is something we would want anyways [12:14:36] <DonDiego> mru: stop your stupid trolling, i'm already getting sick of it [12:14:44] <mru> what now? [12:14:48] <DonDiego> especially since you know italy squat about svn [12:14:53] * DonDiego shakes his head [12:15:09] <ohsix> oh boy [12:15:15] <mru> you didn't write it [12:15:18] <mru> why do get so offended? [12:15:21] <siretart`> I don't think mru is trolling over svn nor cvs. at least not in the last 10 minutes [12:15:31] <DonDiego> he was yesterday ;) [12:15:40] <DonDiego> anyway, i've already cooled down again [12:16:13] <siretart`> bah, r29154 doesn't apply cleanly at all :/ [12:16:23] <DonDiego> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branch… [12:16:24] <mru> it's widely accepted that svn handles branches very poorly [12:16:55] <DonDiego> mru: that's a thing of the past, it improved by leaps and bounds since 1.5 [12:17:05] <ohsix> not even accepted, admitted by the developers [12:17:34] <pross-au> is there a way of getting incremental build numbers with git yet? [12:17:43] <pross-au> s/build/revision/ [12:17:45] <mru> pross-au: who cares? [12:17:48] <pross-au> ME [12:18:10] <ohsix> tag the versions [12:18:12] <pross-au> (and those of us incapable of parsing sha hashs) [12:18:24] <mru> pross-au: git log --oneline | wc -l ;-) [12:18:24] <ohsix> if you must, anyways [12:18:34] <pross-au> oh cool [12:18:38] <DonDiego_> fucking isp... [12:18:42] <siretart`> DonDiego: you still didn't answer my earlier question, did you read it? [12:19:47] <DonDiego> siretart`: please repeat [12:20:00] <siretart`> DonDiego: may I ask you why you insist on that feature? AFAIUI it is only useful if you intend to merge back to trunk, which I don't think is something we would want anyways [12:20:26] <CIA-17> ffmpeg: michael * r21588 /trunk/ffplay.c: [12:20:26] <CIA-17> ffmpeg: "Flush" the picture que on seeks, this prevents the display thread from [12:20:26] <CIA-17> ffmpeg: having frames from before and after the seek which just isnt a good idea. [12:20:28] <DonDiego> the metadata is useful as-is [12:20:42] <siretart`> okay, but what are you using it for? [12:20:45] <DonDiego> so that you know which revisions have been applied, etc. [12:21:34] <siretart`> if you want to have that information, no problem, you're the 0.5 release manager. but I still don't see what you want to do with it. [12:22:51] <pross-au> um, without these revision numbers, we wouldnt nearly be as aware of the approaching 30kth commit [12:23:03] <CIA-17> ffmpeg: michael * r21589 /trunk/ffplay.c: [12:23:03] <CIA-17> ffmpeg: Insert a flush packet into the que on init, that way common code between [12:23:03] <CIA-17> ffmpeg: flush and init can be put into the flush handling. [12:25:15] <ohsix> which is important cuz that means you're done [12:27:55] <siretart`> DonDiego: let's discuss that in person this weekend [12:28:12] <DonDiego> fine [12:28:19] <CIA-17> ffmpeg: michael * r21590 /trunk/ffplay.c: [12:28:19] <CIA-17> ffmpeg: Reset frame_last_pts on flush (and thus also at start) [12:28:19] <CIA-17> ffmpeg: fixes issue558 and probably others. [12:28:43] <DonDiego> but what's the big deal about not merging now? [12:30:27] <siretart`> it's not a big deal at all [12:30:43] <siretart`> besides it seems pointless to me and prevents people to use git-svn to stage their changes [12:31:06] <CIA-17> ffmpeg: michael * r21591 /trunk/ffplay.c: [12:31:06] <CIA-17> ffmpeg: Move frame_last_delay into flush code as it must be reset on seeks to, [12:31:06] <CIA-17> ffmpeg: otherwise the first frame after a seek would be delayed by that amount. [12:32:17] <CIA-17> ffmpeg: michael * r21592 /trunk/ffplay.c: [12:32:17] <CIA-17> ffmpeg: Reset frame_last_delay to 0. [12:32:17] <CIA-17> ffmpeg: This avoids a few ms delay for the first frame after a seek in theory. [12:32:19] <siretart`> that's why I asked if you had some tools/scripts whatever that actually make use of this revision information [12:36:30] <DonDiego> ok, i think we can talk now [12:36:51] <siretart`> my last comment was: [12:36:53] <DonDiego> i've logged onto another machine and started irssi in screen [12:37:01] <DonDiego> fuck vodafone [12:37:02] <siretart`> it's not a big deal at all [12:37:05] <siretart`> besides it seems pointless to me and prevents people to use git-svn to stage their changes [12:37:09] <siretart`> that's why I asked if you had some tools/scripts whatever that actually make use of this revision information [12:37:20] <DonDiego> it's useful information [12:37:32] <DonDiego> that may well get used in the future [12:37:37] <siretart`> useful for what/whom? [12:37:47] <DonDiego> to see which revisions got merged [12:37:49] <siretart`> statistics? [12:38:07] <DonDiego> i must say i'm puzzled by the question [12:38:09] <mru> that can be done with a simple note in the commit message [12:38:22] <siretart`> I tend to agree with mru [12:38:35] <DonDiego> nope, that should be metadata in the revision control system [12:38:38] <DonDiego> same as renames [12:38:46] <DonDiego> copies, etc. [12:39:05] <ohsix> D: [12:39:10] <mru> DonDiego: are you aware that git manages to track renames etc much better than svn? [12:39:25] <mru> if you move a few lines from one file to another, the blame tool will follow it [12:39:49] <siretart`> I really don't want to get into trolling, but currently, it *looks* to me that the main point was to please the tool svn [12:40:41] <pross-au> is there a git->svn gateway? [12:40:56] <siretart`> pross-au: there is git-svn, it can nicely commit to an svn repository [12:41:06] <pross-au> no, the other way round [12:41:10] <mru> that how I do all my commits [12:41:15] <siretart`> pross-au: there is http://git.ffmpeg.org [12:41:32] <mru> I think he wants an svn frontend to a git repo [12:41:37] <siretart`> pross-au: which is managed with git-svn as well [12:41:38] <mru> no such thing exists afaik [12:41:48] <pross-au> thanks mru [12:41:52] <pross-au> i too use git.ffmpeg.org [12:41:53] <mru> it's easy enough to set up a read-only mirror [12:42:11] <siretart`> oh, I see. [12:42:25] <siretart`> pross-au: well, there is tailor, which should be able to do that. [12:43:56] <pross-au> ic [12:45:58] <siretart`> I used it some years ago, but for bzr that time. It turned out to be rather fiddly, but it targets at pretty exactly what you are asking for. [12:46:09] <siretart`> for any VCS [12:46:18] <DonDiego> fucking, fucking, fucking isp [12:51:33] <DonDiego> *sigh* [12:51:54] <DonDiego> i'm getting disconnected every other minute.. [12:52:21] <iive> dsl? [12:52:26] <DonDiego> yes [12:52:36] <iive> cold weather ? [12:52:40] <DonDiego> yes [12:52:44] <iive> with lots of ice? [12:52:57] <DonDiego> define lots.. - it's snowing [12:53:15] <siretart`> fucked dsl modem.. such things do happen [12:53:27] <siretart`> perhaps you can decrease the syncronisation speed on your modem. that usually helps [12:54:00] <DonDiego> anyway [12:54:06] <DonDiego> git does not track renames, it guesses [12:54:29] <siretart`> so? [12:54:36] <DonDiego> the way that svn tracks renames can still be improved [12:54:43] <DonDiego> it can guess wrong [12:54:47] <DonDiego> (git) [12:54:56] <ohsix> its a pretty good guess if it has every tracked files history :O [12:55:10] <siretart`> are wrongly guessed renames a practical problem? [12:55:14] <DonDiego> yes [12:55:24] <DonDiego> and to cut the trolling short: [12:55:45] <DonDiego> i maintain the 0.5 branch and backports will be done with svn merge [12:55:47] <DonDiego> period [12:55:49] <siretart`> my experience tells something different, but anyway, this really wasn't my point [12:55:50] <iive> hum, have git actually guessed wrong for you? [12:56:15] <mru> for very small files git guesses can be a bit random [12:56:35] <mru> 20-line licence boilerplate followed be 3 lines of actual content... [12:57:30] <iive> :)) [12:58:23] * pJok reminds mru to stop making so many "hello world!" apps [12:59:40] <siretart`> DonDiego: do you have a list of open issues that are targeted for a 0.5.1 release? [12:59:53] <DonDiego> no [13:00:03] <DonDiego> i expect to get that list from you [13:00:27] <ohsix> eh, isn't that what the issue tracker is for?? [13:00:27] <DonDiego> the 0.5 branch is targeted at packagers [13:00:31] <pross-au> 0.6? [13:01:09] <DonDiego> some day [13:01:53] <siretart`> hm. roundup doesn't seem to support 'targeting' issues at releases [13:02:12] <ohsix> roundup doesn't do much of anything, huhuhu [13:02:43] <ohsix> metabugs should still work, but are hard to track without that stuff [13:03:41] <siretart`> DonDiego: the debian package carries now a rather large amount of patches that apply to the 0.5 branch. However I imagine that you might be rather skeptical about the neon backports [13:03:57] <ohsix> was bugzilla too hard to set up back in the day? why roundup, its like alsa heh, they use mantis (??? lol) [13:04:35] <CIA-17> ffmpeg: michael * r21593 /trunk/ffplay.c: [13:04:35] <CIA-17> ffmpeg: Make sure the faulty timestamp detection is just done when we have a picture [13:04:35] <CIA-17> ffmpeg: from the decoder. [13:05:11] <ohsix> speaking of, have any of you guys used any of those issue tracker things that keep the data in tree with git? [13:05:20] <siretart`> who runs/maintains the roundup instance? [13:05:58] <siretart`> ohsix: please, not another pointless bugtracker bashing/trolling discussion [13:07:06] <pross-au> DonDiego: cool [13:07:44] <ohsix> heh, my intent was only to see if anyone had; it seems ideal for some scenarios [13:08:27] <ohsix> if you pull from someones tree you get their issues against their tree [13:08:30] <siretart`> pross-au: I've read yesterday that this weekend there is going to be some discussion/planning on a potential 0.6 release at FOSDEM. [13:08:36] <DonDiego> siretart`: lu_zero "maintains" roundup [13:08:50] <siretart`> needless to say that I'm very interested in participating in that discussion :-) [13:09:00] <siretart`> DonDiego: ah, excellent! [13:09:15] <pross-au> gotta love 'discussion' [13:09:32] <DonDiego> why did you amass so many 0.5 patches in the debian tree anyway? [13:09:40] <ohsix> people tend to make more sense in person [13:09:56] <siretart`> well, I'm constantly prodding you to have a look at them :-) [13:10:29] <siretart`> now that you've granted me commit access, I can see to apply some of the more obvious ones to svn, and discuss the rest with you [13:11:06] <DonDiego> you should not amass *any* patches [13:11:22] <siretart`> DonDiego: the most important one (at least to me) is the symbol versioning patch. [13:11:26] <ohsix> siretart`: OT but do you know how much ffmpeg/gst-ffmpeg diverges in ubuntu, if at all? [13:11:58] <siretart`> ohsix: I'm not sure I understand the question. gst-ffmpeg is linked against the system ffmpeg [13:12:51] <siretart`> DonDiego: do you have a written policy to assess what patches are acceptable for the 0.5 branch? [13:12:55] <ohsix> right ... but if debian and ubuntu have the same packages, or at least comparable ones; i have some bugs i'd like to discuss, cuz other people aren't very interested :> [13:13:30] <siretart`> I think the policy for the debian package is more lax, which would explain the large pile of patches [13:13:44] <siretart`> ohsix: they do [13:14:03] <ohsix> keen [13:14:31] <ohsix> if you have a few minutes later i can explain, bbiab [13:15:10] <DonDiego> the 0.5 branch is for packagers, so anything that helps them and keeps them from hoarding patches [13:15:23] <DonDiego> which every packager seems hell-bent on doing anyway.. :-( [13:16:16] <DonDiego> i don't understand why patches need to be staged in distro packages *at all* [13:16:38] <siretart`> well, I'm not hell-bent on that, but so far working on the 0.5 branch hasn't been exactly "inviting" [13:16:58] <siretart`> a clear process on how to work on that would be a great step to lower the entry barrier [13:18:03] <DonDiego> what's uninviting? [13:18:56] <siretart`> e.g. yelling at people that don't use svn 0.5 merge capabilites properties properly is one reason [13:19:19] <siretart`> the lack of process documentation is another one, IMO [13:19:45] <siretart`> for example: do you want me to have you approve each and every backported patch, or do you trust my assessment in suitability for 0.5.1? [13:19:57] <iive> siretart`: Diego never yells at people. never! [13:19:59] <ohsix> k, back [13:20:14] <mru> diego is usually well-mannered [13:20:19] <DonDiego> iive: second warning [13:20:22] <mru> the last few weeks he's been a bit irritable [13:20:28] <mru> perhaps related to his exams [13:20:33] <mru> cut him some slack [13:20:38] <DonDiego> thx [13:20:40] <DonDiego> anyway [13:20:50] <DonDiego> proper tool usage is not up for discussion [13:20:53] <ohsix> warnings are for chumps, people are goingn to mess with you if you're going to respond :O [13:20:56] * siretart` feels like the biggest troll on the hill. and I really wanted to avoid that :-( [13:21:00] <benoit-> mru: you're sooooooo cute when you speak about him like that ;) [13:21:37] <ohsix> DonDiego: not up for discussion, but also not written anywhere? [13:21:40] <iive> DonDiego: ? [13:21:50] <DonDiego> sometimes you have to access the advanced capabilities of the tools [13:22:21] <DonDiego> yes, it should all probably be documented better [13:22:31] <ohsix> any time you have a free moment [13:22:36] <ohsix> derp [13:23:12] <DonDiego> and i'd like to approve the first few patches, after that we shall see [13:23:16] <DonDiego> ohsix: derp? [13:23:32] <ohsix> http://www.urbandictionary.com/define.php?term=derp&defid=134579 [13:23:41] <siretart`> ohsix: your questions on the distro packages would probably be most on-topic on http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers. that list is also available on gmane if you prefer [13:23:53] <ohsix> it was supposed to be a message [13:24:35] <ohsix> its a pretty clean issue with gst-ffmpeg and its use of systme libraries, the gstreamer guys wont touch it [13:25:20] <DonDiego> ohsix: tread carefully, next insult earns you a kick [13:25:39] <ohsix> i didn't insult anyone [13:26:01] <siretart`> DonDiego: okay, then I think I'll proceed in rounds of batches via email on the mailing list, ok? [13:26:17] <ohsix> all this meta discussion is pretty hard on the snr [13:26:55] <siretart`> ohsix: then finally stop contributing to the noise [13:27:19] <ohsix> hmm? i'm not going to let an accusation stand [13:28:02] <DonDiego> you called me "derp", anyway, please just shut up now so that we can get some work done, thx [13:28:13] <DonDiego> siretart`: i'm not following the ml currently [13:28:15] <ohsix> i didn't call you a derp, heh [13:28:25] <siretart`> DonDiego: okay, I'll CC you then. [13:28:34] <DonDiego> whatever, then i take it back [13:28:53] <siretart`> take back what? [13:29:06] <DonDiego> the threat to kick ohsix [13:29:09] <ohsix> a derp is just an utterance used when you make a mistake, and i said it was supposed to be a message :< [13:29:23] <siretart`> ah, wrong thread of discussion :-) [13:31:29] <ohsix> siretart`: long story short; gst-ffmpeg with system ffmpeg hits this with some files i have http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/mpegvideo.c;h=21fa5ed79… [13:33:23] <siretart`> ohsix: okay. so? [13:33:43] <ohsix> thats it, gstreamer guys wont look at it at all because they dont support using the system ffmpeg [13:36:47] <siretart`> they track the 0.5 branch as well, so the bug should be also present with their copy [13:37:26] <ohsix> right, i guess i can prod them some more, but they weren't even willing to look at the samples cuz it used the system ffmpeg [13:37:33] <DonDiego> what's the point in fixing bugs in the distro package anyway? [13:37:44] <DonDiego> (if they will go away with the next upload) [13:37:51] <ohsix> i went upstream first [13:38:04] <DonDiego> any program the size of ffmpeg will have plenty of bugs at any time [13:39:04] <ohsix> its their distinction that an out of tree ffmpeg is unsupported, so you need to talk with the distro since thats how they chose to package it (at least for now, i've been trying to get it looked at for almost a week) [13:39:57] <siretart`> ohsix: instead of prodding, better do a proper investigation of the issue, including samples and proper analysis of the defect. just prodding without that is merily annoying and not helpful [13:40:51] <ohsix> heh, they've got all the goods and the knowhow to bisect it, but the fact remains; the division between in tree and system ffmpeg is there, i would have to do work i dont know how to do to fix it, where they could pin it in a few minutes [13:41:38] <ohsix> they just told me to build from git for everything, which doesn't solve anything, even if it did work [13:41:57] <siretart`> so you want some clever advice how to make them work for you. that's how free software work! [13:41:59] <siretart`> s [13:42:41] <ohsix> no, just so someone that cares can see it [13:43:02] <ohsix> its a problem with packaging [13:43:11] <ohsix> and they refuse to touch it [13:43:12] <siretart`> if you say so [13:43:20] <ohsix> heh [13:43:56] <ohsix> you know what gst-ffmpeg is right? [13:44:14] <siretart`> I do [13:44:31] <siretart`> I even know the packager in debian&ubuntu [13:45:20] <ohsix> thats the person that needs to know, i'm ready and able to take instruction; but it has to be acknowleged first [13:45:41] <ohsix> that they can play the file and see the problem without installing another distro helps a bit! [13:46:06] <iive> ohsix: ffplay? [13:46:35] <ohsix> iive: yea i tried that before i did anything [13:46:46] <iive> and? [13:46:57] <ohsix> ffplay works fine; its the interaction between gstreamer and ffmpeg [13:46:58] <siretart`> I had the impression that you knew about bugtrackers. [13:47:47] <ohsix> siretart`: bugs are on the ubuntu bug tracker, i tried to get input from upstream to investigate myself [13:48:12] <siretart`> good luck then! [13:48:36] <ohsix> heh, thats as good as "we dont support ffmpeg out of tree", thanks [13:49:29] <iive> there are people who have/are working on gst, but not sure there are here now. e.g. BBB [13:50:13] <ohsix> iive: right, i've talked to BBB about some other bugs, he's not interested; he was even kind of angry :O they had a falling out i wasn't there to see apparently [13:50:49] <ohsix> bilboed strides both sides too; he was the one that was interested but decided not to help when he heard it was built the way it is :\ [14:15:17] <mru> http://thedailywtf.com/Articles/Else-where.aspx [14:17:07] <siretart`> heh [14:17:08] <ohsix> heh thats cute :D [14:17:16] <jez9999> mru: not the worst WTF ive ever seen :-) [14:17:21] <ohsix> beats a goto [14:17:27] <jez9999> just remember the 'break' at the end ;-) [14:17:30] <ohsix> or so the fellow probably thought [14:18:02] <jez9999> looks like a candidate for a switch though [14:19:17] <ohsix> superdump: how did the enum switch thing work out [14:19:39] <siretart`> reminds me of homework from some of our students who have "programming in C" as minor subject. but even they aren't that confused… [14:20:29] <superdump> ohsix: ? [14:21:19] <ohsix> superdump: oh the thing you asked about with the bitfields and the exclusive switch i think you called it [14:22:43] * superdump doesn't recall [14:26:19] <Honoome> mru: I've seen stuff like that in my daily job :| [14:26:36] <mru> Honoome: but you work on web stuf, what do you expect? ;-) [14:26:55] <Honoome> I *don't* work on web stuff… [14:27:03] <Honoome> or rather, I'm working on web stuff now, and it's an exception… [14:27:15] <mru> ok [14:27:23] <mru> what kind of work do you normally do? [14:27:28] <twnqx> let's do that with ffmpeg, maybe gcc can optimize it :] [14:28:03] <Honoome> usually, “embedded” and support (I use quotes there because I wouldn't call Java code compiled with GCJ embedded…) [14:30:04] <mru> I wouldn't call java embedded, ever [14:30:27] <ohsix> what about jazelle! [14:30:50] <Honoome> well GCJ-compiled Java code on ARM is an entirely different league from usual Java [14:30:53] <mru> ohsix: dead [14:30:57] <Honoome> another league of insanity, obviously [14:31:05] <ohsix> well, dead now; hhuuhhu [14:40:15] * KotH knows people who call a full blown arm/mips system running linux "embedded" [14:41:41] <ohsix> :> hey they may have had to do their own bsp! [14:42:14] <mru> bsp, yuck [14:42:49] * mru suspects "board support package" refers to the board of directors [14:43:43] <ohsix> its a generic cover for twiddling all the right bits and enabling the ram and stuff [14:44:06] <mru> I know what usually comes with that label [14:44:15] <mru> and it's usually something entirely useless [14:44:40] <ohsix> yea but you can show the suits it runs [14:44:43] <mru> just give me a boot loader [14:44:55] <mru> as I said, board of directors [14:45:00] <mru> aka suits [14:45:14] <ohsix> ah, i missed that [14:45:17] <twnqx> reminds me of my current job... [14:45:26] <twnqx> asked the sales guy about recommended dress code [14:45:38] <twnqx> "don't use suit and tie, they won't take you serious!" [14:45:44] <ohsix> but if they got the money they wanna see it work, even if you need to throw it all out [14:45:48] <twnqx> <3 tech jobs [14:46:27] <mru> I worked at a place once where the ceo dressed in ragged jeans and t-shirt [14:46:54] <kierank> me too except the ceo was a billionaire [14:47:11] <mru> mine was a wannabe billionaire... [14:47:18] <mru> never quite panned out though [14:47:31] <twnqx> i'd be happy with the first few millions :X [14:47:46] * mru is a millionaire [14:47:47] <twnqx> billions are nice, though [14:47:48] <mru> in some currencies [14:47:50] <twnqx> in rubel? [14:47:55] <twnqx> old turkish lira? [14:48:05] <thresh> 'rouble' [14:48:14] <twnqx> simbabwe <whatever they have there> [14:48:20] <thresh> dollars, i think [14:48:25] <mru> dust? [14:51:04] <KotH> mru: my current bos often comes in ragged jeans and t-shirt [14:51:25] <KotH> mru: especially then, when we have guests from far east :) [15:19:59] <ohsix> hi BBB [15:20:04] <BBB> hi [15:24:24] <DonDiego> hi [15:24:42] <DonDiego> siretart`: what was the exact command you used to merge the symbol stuff? [15:25:15] <siretart`> svn merge -c svn merge -c21235 svn://ffmpeg.org/ffmpeg/trunk [15:25:32] <BBB> superdump, I'm confused now [15:25:37] <DonDiego> siretart`: what? [15:25:59] <siretart`> svn merge -c21236 svn://ffmpeg.org/ffmpeg/trunk [15:26:21] <siretart`> and later then additionally 'svn merge -c21235 svn://ffmpeg.org/ffmpeg/trunk' as I noticed that this commit is necessary as well [15:27:24] <DonDiego> k [15:27:32] <DonDiego> you also need to add the libswscale stuff [15:27:57] <siretart`> I added that manually [15:27:59] <DonDiego> siretart, siretart`, you have two nicks here, which one is your proper account? [15:28:14] <siretart`> backporting directly is not possible as libswscale is a different svn repository [15:28:25] <DonDiego> yes, i know :-/ [15:28:42] <siretart`> DonDiego: siretart is my irssi instance. at work I prefer rcirc (an elisp irc client) as it distracts me less [15:29:01] <siretart`> perhaps I ditch some day that irssi instance. currently I mainly use it for logging [15:29:25] <DonDiego> i must say i find it somewhat confusing [15:29:34] <DonDiego> and you might miss somebody highlighting you.. [15:29:37] <DonDiego> are the nicks linked? [15:29:54] <siretart`> they are, and I don't miss highlights [15:30:04] <DonDiego> ok, fine then [15:30:12] <DonDiego> i just oped you in the access list [15:30:24] <DonDiego> but the channel does not pick that up.. [15:30:25] <DonDiego> so.. [15:30:39] <siretart`> :-) [15:30:59] <DonDiego> can you quickly show me the complete diff? [15:31:05] <siretart`> if you mean linked as in Freenode nicks linked, then I haven't automated that in rcirc. probably I should someday [15:31:29] <siretart`> DonDiego: how can I retrieve that? 'svn diff' produces exactly what I pasted in the mail [15:31:33] <siretart`> wait, I'll post 'svn status' [15:32:10] <DonDiego> try --notice-ancestry [15:32:16] <siretart`> http://pbot.rmdir.de/e3d0d445bd796b3d356bd47a82b7d724 [15:32:48] <siretart`> --notice-ancestry doesn't help [15:34:39] <DonDiego> libswscale changes are missing [15:34:53] <jez9999> BBB: hiya [15:34:59] <BBB> hi jez9999 [15:36:07] <Compn> http://news.bbc.co.uk/2/hi/health/7813637.stm [15:36:27] <siretart`> indeed. I forgot to 'svn add' it [15:37:46] <jez9999> BBB: you never gave a suggestion as to how to implement the packet blocking [15:37:47] <jez9999> :-) [15:38:03] <BBB> true [15:38:05] <BBB> let me start thinking [15:38:06] <siretart`> DonDiego: fun. now libswscale/swscale.v appears in the diff. but not the other .v files.. [15:38:10] <BBB> it's not easy, I'll admit that [15:38:35] <jez9999> not easy as in i already provided a patch that does it? [15:39:00] <siretart`> DonDiego: http://pbot.rmdir.de/ffb7221cd80743569de18ca81221c1ca <- that is the swscale.v diff [15:39:10] <DonDiego> siretart`: that's because libswscale is not merged.. [15:39:18] <BBB> jez9999, as in "what's the best way" [15:39:21] <BBB> jez9999, needs some thinking :) [15:39:29] <jez9999> ah [15:39:59] <DonDiego> siretart`: for the runtime cpudetect merge you need to do the same [15:40:11] <siretart`> OK [15:42:00] <DonDiego> see, that's why i wanted to do a bit of hand-holding before giving you carte blanche to commit on the branch.. [15:42:17] <siretart`> DonDiego: mru: I think I should add "- enable symbol versioning by default for linkers that support it" to Changelog in trunk as well, right? [15:42:19] <jez9999> BBB: still, have you thought about it? lol [15:42:26] <jez9999> you must have some vague idea of what to do [15:42:28] <jez9999> (ideally) [15:42:34] <ohsix> you have a lot of responsibilities a normal release manager doesn't :\ [15:42:54] <DonDiego> siretart`: yes, please update the trunk changelog, ideally before the merge and make it a separate commit .. [15:43:08] <BBB> jez9999, I'm not sure what's the best way yet [15:43:13] <BBB> I'm thinking about it, but it's not easy [15:43:21] <BBB> who wants to mentor tasks for soc related to lossless audio? [15:43:51] <siretart`> DonDiego: ok [15:44:08] <jai> siretart`: did you get around to proposing security relevant fixes for the 0.5 branch? [15:44:18] <siretart`> jai: I'm on it [15:44:32] <jai> siretart`: cool [15:53:02] <CIA-17> ffmpeg: siretart * r21594 /trunk/Changelog: mention symbol versioning [15:53:13] <siretart`> muhaha! [15:53:20] <DonDiego> hehe [15:53:26] <DonDiego> first commit, welcome aboard :) [15:53:35] <siretart`> thanks :-) [15:53:50] <DonDiego> remember that [15:53:58] <DonDiego> with great power comes great responsibility [15:54:02] <DonDiego> young padavan [15:54:04] <DonDiego> :) [15:54:10] <BBB> don't forget to promote the gsoc2010 on your blog people! [15:54:11] <BBB> </spam> [15:54:15] <DonDiego> oops, i'm mixing up a few things there.. [15:54:39] <siretart`> how nice that svn stores passwords in plaintext in ~/.subversion. I probably would have had to ask for it :-) [16:01:12] <CIA-17> ffmpeg: siretart * r21595 /branches/ (11 files in 9 dirs): backport symbol versioning patch [16:03:59] <CIA-17> ffmpeg: siretart * r21596 /branches/ (0.5 0.5/Changelog): mention symbol versioning [16:04:00] <siretart`> DonDiego: ok. I think I've followed your protocol for working on the 0.5 branch closely. [16:04:35] <DonDiego> \o/ [16:04:50] <siretart`> DonDiego: next patch will be the cpu-runtime patches [16:05:52] <siretart`> I guess you still want to approve them by mail first? [16:07:37] <DonDiego> yes please [16:08:49] <DonDiego> one more note for the next time: [16:08:58] <DonDiego> the changelog update should be part of the commit itself [16:09:01] <DonDiego> less clutter [16:09:33] <siretart`> DonDiego: you said before 'make it a seperate commit', so that's what I did [16:11:21] <DonDiego> oh, that was a misunderstanding [16:11:36] <DonDiego> the changelopg update for trunk should be separate [16:11:42] <DonDiego> nm [16:11:43] <siretart`> ok [16:12:02] <kierank> [15:43] <@BBB> who wants to mentor tasks for soc related to lossless audio? --> presumably that's dts-hd you're talking about? [16:12:13] <kierank> or one of those other dts codecs [16:13:03] <DonDiego> is there a wiki page for soc 2010 yet? [16:13:33] <merbzt> DonDiego: there is [16:15:56] <DonDiego> ah, the main soc page has not yet been updated.. [16:15:56] <jai> kierank: probably wmals or ralf [16:16:06] <jai> kierank: maybe even alsenc [16:16:28] <jai> (just a guess, dont go by what i say) [16:21:06] <BBB> Dondiego: I will add it [16:21:16] <BBB> kierank, I meant ralf/wmals [16:21:24] <BBB> but dts-hd is fine also [16:21:26] <jez9999> BBB: what nick are you on the bugtracker? [16:21:31] <BBB> rbultje [16:21:47] <DonDiego> BBB: i beat you to it ;) [16:21:52] <jez9999> ah ok [16:21:59] <BBB> darnit :) [16:22:02] <BBB> thanks [16:22:12] <BBB> any other tasks that I'm missing? [16:22:19] <BBB> and we need to do suggested qualification tasks [16:22:23] <BBB> if possible, where appropriate, etc. [16:25:10] <DonDiego> finishing amr-nb is missing [16:25:26] <ohsix> is this aliasing business a near term cleanup goal or is it just dark_shikari talking about it being done [16:25:31] <DonDiego> add all the qual tasks from previous years [16:25:45] <mru> ohsix: right now michael is pissing on it [16:25:49] <DonDiego> and all suggestions for projects [16:25:53] <DonDiego> the more the merrier.. [16:26:02] <ohsix> is that good or bad? and is that the cleanup idea or the aliasing =) [16:26:18] <ohsix> i hope he knows what aliasing is [16:27:21] <mru> aliasing must be kept in check [16:27:28] <mru> otherwise the compiler will surprise you [16:27:51] <ohsix> well ya; any plans to start sprinkling the code liberally with restrict? [16:28:09] <mru> that's unrelated [16:28:17] <BBB> DonDiego, I'm sure vitor / colin will finish amrnb before summer 2010 [16:28:36] <BBB> DonDiego, it's been submitted to -devel a few times already [16:28:50] <BBB> (maybe superdump should help also :) ) [16:29:37] <superdump> huh wuh what's going on? [16:29:45] * superdump reads the backlog [16:31:04] <superdump> aha [16:32:34] <DonDiego> hmm [16:32:44] <DonDiego> isn't a better regtest system already done? [16:38:39] <mru> lol, someone got to my blog by googling for gcc bashing [16:50:47] <superdump> :) [16:51:59] <mru> bashing is fun [17:03:56] <mru> now I'm bashing libjpeg [17:04:37] <Honoome> speaking about bashing, I'd really have to write more autotools bashing just to show how the heck they are making our lives more miserable… and pushing people who have no clue into writing _worse_ buildsystems >_< [17:04:40] <ohsix> isn't that like bashing 1998 [17:05:21] <mru> a bit, yes [17:05:45] <mru> but he deserves it [17:06:07] <Honoome> autotools you mean? [17:06:12] <mru> libjpeg [17:06:19] <mru> autotools too of course [17:07:47] <Honoome> libjpeg… I don't remember the last time a library changed ABI twice the same year [17:07:53] <ohsix> 1998 stole my bike [17:09:17] <Honoome> mru: the heck is that a technical proposal or a marketing brochure? [17:09:35] <mru> good question [17:10:10] <DonDiego> Honoome: please do, also, point out the ways to do things better.. - your autotools docs were very helpful to me.. [17:10:39] <Honoome> DonDiego: I always try to :) although this time the ones that would need to change the way they do things is upstream… [17:10:58] <Honoome> I can go on repeating to use AS_HELP_STRING as much as I want, but when the macros provided by autoconf and automake themselves don't……… [17:15:03] <Honoome> mru: I can't believe the excerpt at the end… please tell me it's just a joke gone bad [17:15:17] <mru> go read the thread for yourself [17:20:27] <DonDiego> which thread? [17:20:59] <mru> the one I linked to [17:21:30] <mru> http://groups.google.com/group/comp.dsp/browse_frm/thread/4eb02c1d668daa7d [17:26:03] <av500> mru: typo: "...as the quantiser in increased.." [17:26:18] <mru> where's the typo? [17:27:13] <av500> in -> is, no? [17:27:22] <mru> I'm blind [17:36:26] <Compn> Honoome : i think the 1mb configure script is enough of a reason to hate auto* [17:36:43] <ohsix> you mean the generated files? [17:36:54] <Compn> nope [17:37:39] <ohsix> nice, people usually break em up, and the project into submodules before that happens [17:38:42] <Compn> of course, now i cant find it [17:38:50] <Compn> google only has two hits for '1mb configure script' [17:39:09] <mru> what about 2mb? [17:39:19] <jai> Compn: try "autotools sucks" [17:40:14] <Compn> It's really disturbed me, sometimes, shipping a package of 50kB source [17:40:14] <Compn> and 2MB configure+libtool. [17:40:23] <Compn> http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg00349.html [17:41:20] <Compn> ah "huge configure script" mentions autotools more [17:41:29] <ohsix> its always best to judge something on how random people abuse it :> [17:41:42] <Compn> you bet. [17:45:59] <Honoome> Compn: I'd still take that over about 3/4 of the custom-tailored build systems [17:47:03] <ohsix> bodging' another test in a script instead of modifying the build tool is nice [17:49:20] <Compn> ohsix : so you are saying its broken a lot too? :P [17:50:11] <ohsix> it allows for some pretty crazy circumstances without having to switch to another tool, cant say that about the others [17:51:24] <Compn> just trolling ;p [18:38:26] <DonDiego_> hey, anybody here for whom dcc works? [18:38:37] <DonDiego_> i want to try my new router configuration [18:38:51] <ohsix> me, why? people can recieve if they have their stuff set up, sending is the hard part :> [18:39:44] <DonDiego_> can you dcc me a file please? [18:40:44] <ohsix> sure, but it will work; my stuff is set up right [18:41:11] <DonDiego_> i want to verify both directions, please try, thx [18:41:39] <ohsix> dcc is one direction :D sender says HEY theres a port at this file! then the other guy connects back [18:41:52] <ohsix> file at this port, even [18:41:55] <DonDiego_> lol, good one :) [18:42:08] <DonDiego_> the file you sent i mean :) [18:42:12] <ohsix> :) [18:42:27] <DonDiego_> i assume this is coming from a private nat address? [18:42:46] <ohsix> yea, you need to tell your irc client to use the outside address; 10:42 [freenode] DCC SEND from DonDiego_ [192.168.2.42 port 38880]: dude.txt [9kB] [18:46:44] <ohsix> its weird, i was just explaining dcc to someone else; they always just leave it "broken" but they dont know that means they can still recieve files :> [18:46:56] <ohsix> unless both ends are broken, then its hopeless [18:53:48] <DonDiego_> hmm, i guess my client needs to know the ip of the router in any case.. [18:53:55] <DonDiego_> i.e. the external real ip.. [18:56:33] <ohsix> DonDiego_: yea, but most can be setup to get it from USERHOST when your irc client connects (then the irc server tells them their address) [18:58:09] <DonDiego_> do you happen to know the irssi setting? [18:58:31] <ohsix> hm i haven't had to set it, sec [18:59:35] <ohsix> it may need a script to do it, i dont see anything about it being automatic, but dcc_own_ip is what needs to be set [18:59:47] <ohsix> something like that will be in the irssi script repo [19:00:20] <DonDiego_> ok, i just set dcc_own_ip [19:00:25] <DonDiego_> are you getting something? [19:01:42] <ohsix> http://scripts.irssi.org/scripts/dcc_ip.pl [19:02:12] <ohsix> i only just tried to recieve, if it timed out you'll have to resend [19:02:34] <DonDiego_> i just resent [19:02:46] <ohsix> its picking random ports [19:02:58] <ohsix> set dcc_port to something [19:04:28] <DonDiego_> next try .. [19:04:53] <ohsix> 11:04 DonDiego_ GET: 0B of 9kB (0%) - 0.00kB/s - ETA (stalled) - dude.txt [19:04:59] <ohsix> 11:04 [freenode] DCC SEND from DonDiego_ [84.63.14.108 port 50000]: dude.txt [9kB] [19:05:13] <ohsix> (stalled means i cant reach the port) [19:05:28] <DonDiego_> ok, i'll need to forward it of course.. [19:09:19] <DonDiego_> one more time.. [19:10:54] <ohsix> huzzah [19:11:38] <DonDiego_> you got it.. [19:11:46] <ohsix> i did [19:12:10] <ohsix> you might want to change your port from 50000 now :> people can hammer it and get any file you offer [19:14:20] <DonDiego_> enough for today [19:14:25] <DonDiego_> thx for the assistance... [19:51:09] <CIA-17> ffmpeg: stefano * r21597 /trunk/libavfilter/vf_scale.c: Use pixel format descriptors to check if the input format is paletted. [20:31:13] <Dark_Shikari> hmm, who was it who wanted me to write up some qualification tasks for ffmpeg soc projects? [20:32:40] <BBB> me [20:32:48] <BBB> if you have time etc. [20:33:01] <Dark_Shikari> I won't write up full qual tasks but I can go through them and note my ideas [20:33:04] <BBB> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010 [20:33:08] <BBB> yeah, that's what I mean [20:33:10] <Dark_Shikari> WVP2: It'll have to be something reverse-engineering based, since it's primarily an RE task [20:33:13] <BBB> I'll write it out in the next few days [20:33:19] <BBB> all those projects aren't full-fledged either [20:33:20] <Dark_Shikari> I'd suggest some BASIC RE task involving WVP2 [20:33:29] <BBB> basic as in...? [20:33:35] <BBB> RE the frame parser for wvp2? [20:33:40] <BBB> or get the dll running? [20:33:53] <Dark_Shikari> i.e. make your best attempt to RE the header formats [20:33:57] <Dark_Shikari> or something like that [20:34:00] <BBB> ok [20:34:06] <Dark_Shikari> doesn't matter, something simple but not trivial [20:34:38] <Dark_Shikari> Flash Screen Video 2: I don't really know about this format enough to give a good task [20:35:18] <Dark_Shikari> yeah, some of these are harder to make x264-style qual tasks for [20:35:25] <Dark_Shikari> though it could just be because I don't know enough about them [20:35:59] <Dark_Shikari> for libavfilter: write one filter [20:40:08] <BBB> merbzt, what happened to your RE wiki page? [20:40:10] <BBB> it's gone [20:44:25] <BBB> ok, added some description to wvp2 [20:45:11] <BBB> jai: have you worked on ralf yet? [20:45:24] <BBB> oh he's not here [20:45:46] <drv> there is a thread with some encoder and decoder patches for flashsv2 on the ML [20:47:47] <mru> saste: you still haven't registered [20:48:09] <saste> yes doing that now [20:52:57] <saste> I should be registered now [20:53:13] <saste> can someone confirm that this is actually a bug: [20:53:16] <saste> http://thread.gmane.org/gmane.comp.video.ffmpeg.user/25100 [20:53:29] <saste> ffmpeg 0.5 is not installing the imgconvert.h header [20:53:48] <saste> or am i badly missing something? [20:55:00] <saste> thanks mru [21:28:22] <BBB> I'm confused [21:28:30] <BBB> what should the last argument of INIT_VLC_STATIC() be? [21:30:30] <mru> the size [21:30:36] <mru> of the allocation [21:30:38] <mru> it is a bit confusing [21:30:43] <mru> put something large first [21:30:47] <mru> then run it [21:30:54] <mru> it'll print what size was actually needed [21:31:05] <BBB> ? [21:31:11] <BBB> I'm very confused [21:31:15] <BBB> is it defined? [21:32:11] <BBB> I have tiny tables, 22 entries [21:32:14] <BBB> I put 500 [21:32:16] <BBB> it still aborts [21:32:36] <BBB> isn't that weird? [21:32:52] <mru> what value for bits are you passing? [21:33:57] <BBB> oh, it reinitializes [21:34:00] <BBB> that's bad? [21:34:05] <mru> uh? [21:34:35] <mru> pass (1<<bits)*(max_length/bits) [21:34:42] <mru> or just put something huge [21:34:48] <mru> it will tell you what the correct value is [21:34:51] <BBB> yeah, 132 worked [21:34:55] <mru> because it's hard to calculate [21:35:00] <BBB> but it still aborts because the table is already initialized [21:35:04] <BBB> I'm wondering why [21:35:07] <BBB> (line 264 of bitstream.c) [21:35:08] <mru> you're doing something wrong then [21:35:37] <mru> look at some other place that does it [21:46:47] <BBB> ok now it works [21:49:13] <aclarke> i'm in process of trying to add codec-specific options support [21:49:35] <aclarke> I assume introducing the concept of "avcodec_init()" and "avcodec_free()" before calls to avcodec_open and avcodec_close will be shot down? [21:49:46] <aclarke> (I need something to allow allocing of codec specific options structs) [21:50:00] <mru> every attempt at codec options or even defaults has been shot down [21:50:14] <aclarke> the methods would be OPTIONAL (i.e. if you don't call them, you just can't set codec-specific options) [21:50:44] <aclarke> do you know the major reasons why it was shot down? hate to reinvent the flame^H^H^H^H^Hwheel. [21:51:13] <mru> michael didn't believe it was necessary [21:51:36] <Dark_Shikari> not long ago, he approved the idea [21:51:37] <Dark_Shikari> iirc [21:51:39] <Dark_Shikari> in an email [21:51:46] <mru> ah, that's progress [21:51:50] <Dark_Shikari> codec-specific defaults he did too I think [21:52:27] <BBB> yes [21:52:34] <BBB> I remember that [21:52:58] <aclarke> k; progress good [21:53:18] <aclarke> now, i need a way to alloc a codec-specific options struct in a AVCodecContext, but it has to happen before avcodec_open [21:53:55] <aclarke> my proposal is "avcodec_init(AVCodecContext*,AVCodec*)" and "avcodec_free(AVCodecContext*)" if you called init [21:53:58] <aclarke> thoughts? [21:54:49] <aclarke> my thinking here is that then we can add various libx264 options that don't need to pollute AVCodecContext but use the existing AVOption-based method of setting/getting [21:55:04] <Dark_Shikari> well we should start by adding codec-specific defaults [21:55:14] <mru> that shouldn't be too hard [21:55:18] <Dark_Shikari> i.e. have param_default call a per-codec itnitialization function [21:55:23] <Dark_Shikari> which is optional [21:55:25] <aclarke> yeah; there would be a callback on the AVCodec* option that can set defaults when you call avcodec_init [21:55:25] <Dark_Shikari> thus trivial to implement [21:55:30] <Dark_Shikari> yup [21:55:32] <mru> you don't even need that [21:55:35] <Dark_Shikari> in fact, we should do that right now [21:55:41] <mru> just an optional AVOption array in each codec [21:55:43] <Dark_Shikari> then we can clean up the vpres [21:56:37] <aclarke> @mans I could just assume priv_data is an option-settable think if AVCodec->options is an option array? [21:56:40] <aclarke> s/think/thing [21:56:40] <mru> and add an avcodec_alloc_context3() that takes an AVCodec* [21:56:58] <aclarke> that was my first attempt exactly [21:57:02] <mru> aclarke: not so hasty [21:57:35] <aclarke> I thought avcodec_init(...) worked better because once we do this, you can no longer just av_freep(avctx) like you can the results of avcodec_alloc_context3 [21:57:47] <aclarke> @mans ok... will type slower? [21:58:29] <mru> there isn't an alloc3 [21:58:45] <mru> we could certainly add a context_free() function too [21:58:56] <mru> that's rather unrelated to the interface used to init it [21:59:06] <aclarke> i could do that as well [21:59:40] <aclarke> i could change avcodec_alloc_context2 to take a type or a AVCodec since 'technically' it's not part of the public API, but I think it's been there long enough that people treat it as public [22:00:36] <mru> we'd have to mess with the lib version either way [22:01:54] <aclarke> or require codecs to be able to work if for some reason their codec-specific-options are NULL (which I prefer because it's more backwards compatible). [22:02:07] <aclarke> and really the main area where I'd be adding this is into libx264.c [22:02:27] <aclarke> (well, I plan to do a similar think eventually in AVFormatContext and for flvenc.c to enable some speex packaging options) [22:09:40] <CIA-17> ffmpeg: michael * r21598 /trunk/ (tests/ref/lavf/ogg tests/seek.regression.ref ffmpeg.c): [22:09:40] <CIA-17> ffmpeg: Check pkt.pts against the recording time. [22:09:40] <CIA-17> ffmpeg: This fixes at least ogg encoding with -t where the file was slightly too long. [22:12:45] <aclarke> k; to avoid overriding priv_data I'll take the approach of adding a new member [22:18:04] <CIA-17> ffmpeg: stefano * r21599 /trunk/ffplay.c: Reindent. [22:24:06] <CIA-17> ffmpeg: stefano * r21600 /trunk/ffplay.c: [22:24:06] <CIA-17> ffmpeg: Use parentheses around && within ||, fix the gcc warning: [22:24:06] <CIA-17> ffmpeg: ffplay.c: In function ?video_thread?: [22:24:06] <CIA-17> ffmpeg: ffplay.c:1391: warning: suggest parentheses around && within || [22:32:58] <KotH> bon nuit mes enfants [22:41:53] <aclarke> au revior [23:07:43] <iive> mru: 2 blog posts in just 2 days... [23:08:18] <iive> ok 3. [23:08:56] <mru> the jpeg one has been a while in the making [23:09:34] <iive> the scan order seems intresting. does it produce any better results? [23:10:54] <CIA-17> ffmpeg: cehoyos * r21601 /trunk/libavformat/ (mpegts.c rtpdec.c mpegts.h): [23:10:54] <CIA-17> ffmpeg: Fix warnings about implicit function declaration when compiling rtpdec.c [23:10:54] <CIA-17> ffmpeg: Patch by Alexis Ballier, alexis D ballier A gmail [23:15:06] <Dark_Shikari> mru: you should linkify "major breakthrough" [23:15:08] <Dark_Shikari> to your old blog post [23:15:27] <aclarke_> ugh; ffmpeg.c option setting is squicky [23:17:36] <Dark_Shikari> mru: why don't you add an h264 comparison to the post? [23:17:38] <Dark_Shikari> that would make it more awesome [23:19:32] <Dark_Shikari> mru: also, the phrase is "swings again" [23:19:36] <aclarke_> @mans what's the blog link? [23:25:33] <saste> aclarke: there was a discussion on ffmpeg-devel sometime ago on per-codec options [23:25:41] <saste> should be easy to find it [23:31:20] <CIA-17> ffmpeg: mru * r21602 /trunk/libavformat/mpegts.c: Fix build [23:32:13] * mru looks at fate and weeps [23:57:42] <ramiro> is anyone able to shed some light on michael's response for me here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-January/082066.html [23:58:04] <ramiro> I still don't understand how this array_index type would work nor how it would make things better [23:58:23] <mru> me neither [23:58:31] <mru> there's nothing that special about array indexes

1 0

IRC log for 2010-01-31
by irc＠mansr.com 01 Feb '10

01 Feb '10

[02:07:42] <Kovensky> < CIA-43> ffmpeg: No meassureable speed change. <-- it's half of a clock! [02:11:42] <Compn> lol [02:38:40] <Yuvi> I can't tell if apple not using eabi was deliberate or that someone forgot to enable it in gcc and now they can't change it [02:39:18] <mru> it's eabi except for the stack alignment [02:39:25] <mru> on iphone os 3 [02:39:37] <mru> v2 was horrible [02:39:49] <mru> reserved registers, yuck [02:40:32] <Yuvi> what exactly was the difference? llvm and as far as I can tell arm-gcc both use acps for function calls, not aacps [02:40:46] <mru> uh? [02:40:46] <Yuvi> err apple-gcc [02:40:56] <Yuvi> *apcs aapcs [02:41:10] <mru> what are you trying to say? [02:42:05] <Yuvi> https://llvm.org/svn/llvm-project/llvm/branches/release_26/lib/Target/ARM/A… APCS vs. AAPCS, AAPCS being EABI [02:42:11] <mru> apple uses the standard softfloat calling conventions [02:42:24] <Kovensky> lulz [02:42:32] <mru> the only thing apple doesn't do is maintain 8-byte stack alignment on external function calls [02:42:38] <Kovensky> er, wrong chan =p [02:44:22] <mru> Yuvi: I can't make sense of that file [02:44:51] <Yuvi> yeah, as far as I can tell the only difference between the two that matters is alignment [02:44:54] <mru> it looks like some hideous cross between c++, tcl, and python [02:45:48] <Yuvi> but I can't find what apcs means other than pre-EABI which I can't find documentation for [02:46:21] <mru> parameter passing hasn't changed [02:46:25] <Yuvi> I think llvm made that language up [02:46:58] <Yuvi> sort of a specialized c++ preprocessor [02:50:15] <mru> btw who's in charge of the pa-risc, sparc, and ia64 fate machines? [02:55:11] <astrange> the td format is weird, i don't know why they didn't use a lisp or something [02:55:14] <astrange> i guess gcc already did that [02:56:40] <mru> the gcc one is almost understandable [08:19:49] <pross-au> Hi. [08:19:58] <pross-au> G'day rob! [08:20:25] <superdump> lo :) [08:21:04] <kshishkov> morrow [08:21:29] <pross-au> Q: i have a function 10^(min(value,95)*0.0663999...) . michael suggests this can be transformed into foo*e^(bar). I can't figure it out [08:21:57] <Dark_Shikari> 10^x = e^y [08:22:05] <Dark_Shikari> log10(10^x) = log10(e^y) [08:22:12] <Dark_Shikari> x = log10(e^y) [08:22:19] <pross-au> Awesome :D [08:22:27] <Dark_Shikari> now the log switching theorem, let me go grab that [08:22:48] <Dark_Shikari> ah, log switching theorem only works in the reverse case. [08:22:56] <Dark_Shikari> x = y * log10(e) [08:23:10] <Dark_Shikari> y = x / log10(e) [08:23:20] <Dark_Shikari> 10^x = e^(x/log10(e)) [08:23:23] <Dark_Shikari> that was easy [08:23:35] <pross-au> Oh nice [08:24:18] <kshishkov> so just merge two constants and relax [08:25:26] * kshishkov had to use log+exp for power calculation even before he knew what is that [08:26:13] <pross-au> thanks mate [08:26:17] <Dark_Shikari> and shit, I haven't done this in years =p [08:28:09] <kshishkov> still, knowing a bit of math helps [08:28:40] <Dark_Shikari> this should be high school stuff though >_> [08:29:31] <kshishkov> high? Grade 10 or so here [08:29:43] <Dark_Shikari> high is 9-12 here [08:29:50] <kshishkov> ah [08:32:33] <kshishkov> we have simple school system here: grades 1-3,5-9 are obligatory, 10 and 11 or colledge are optional [08:33:01] <kshishkov> at least it was in my time [08:33:51] <superdump> what happens in grade 4? [08:33:59] <Dark_Shikari> lol [08:34:13] <kshishkov> dunno, is was absent even in Soviet times [08:34:27] <superdump> what do people do? bum around for a year? [08:34:40] <superdump> a year in industry? :B [08:34:49] <kshishkov> no, they just have 5th grade right after 3rd [08:35:25] <elenril> iirc y^x is defined as exp(x*log(y)) [08:35:27] <kshishkov> IIRC this was shifted to show that Soviet education system meets world standards [08:35:29] <superdump> in the uk we have 1-3,4-6,7-9,10-11 [08:36:03] <Dark_Shikari> in the US we have K-6, 7-8, 9-12 [08:36:04] <superdump> i think we learned log stuff in years 10-11 [08:36:07] <Dark_Shikari> and in some places K-5, 6-8, 9-12 [08:36:18] <superdump> which is 14-16 [08:36:22] <superdump> years old [08:36:28] * superdump shrugs [08:37:07] <kshishkov> well, I can't be sure for current system, we had very active reformer for Minister of Science and Education [08:37:58] <elenril> kshishkov: you skipped grade 4 too? [08:38:07] <kshishkov> you know, that ministry once almost approved an Astrological Colledge [08:38:09] <elenril> lol, i thought it was just our school [08:38:23] <kshishkov> elenril: no, simply didn't have it [08:40:19] <kierank> [08:38] <@kshishkov> you know, that ministry once almost approved an Astrological Colledge --> homeopathy is state funded here :/ [08:41:05] <elenril> where is here? [08:41:08] <kierank> uk [08:41:09] <kshishkov> UK [08:41:15] <elenril> o_0 [08:41:24] <kshishkov> the only sane approach to homeopathy was in Germany IIRC [08:41:27] <superdump> kshishkov is ukraine [08:41:39] <superdump> i am united kingdom [08:41:45] <superdump> very different places i think [08:41:47] <superdump> :) [08:42:12] <superdump> homeopathy is state funded? [08:42:15] <kshishkov> unfortunately, not so [08:42:28] <kierank> superdump, yes; its on the nhs here [08:42:35] <superdump> cool [08:42:38] <kshishkov> there are so many suspicious similarities between UK and .ua [08:43:16] <kshishkov> superdump: weren't you living in UK at some point? [08:43:24] <superdump> :) [08:43:26] <superdump> yes [08:43:44] <superdump> for the first 24 years of my life i spent most of my time there [08:43:51] <superdump> now i seem to spend most of my time in sweden [08:44:18] <superdump> men jag maste fixa frukost nu [08:44:20] <superdump> bbl [08:44:42] <superdump> (no, i haven't remapped keys for swedish characters yet) [08:45:02] <kshishkov> that's easy to spot [08:45:22] <kierank> [08:42] <@kshishkov> there are so many suspicious similarities between UK and .ua --> ukraine is meant to have .uk and we're meant to be .gb [08:46:01] <kshishkov> isn't that wonderful? [08:49:08] <kshishkov> and try to guess to which country the following applies: outdated plumbimng, ineffective central heating, bureaucracy [08:49:34] <kierank> both [08:50:31] <kshishkov> idiotic cars? [08:51:07] <kshishkov> former socialist government? [08:57:27] <KotH> salve! [08:57:50] <kierank> greetings KotH [08:57:55] <kshishkov> hej [08:59:55] <KotH> hmpf.. need to reboot [08:59:57] <KotH> bbl [09:05:42] <pross-au> idiotic cars? where [09:08:41] <kshishkov> ever heard of British cars for not so rich people? [09:09:23] <kshishkov> and here it's http://en.wikipedia.org/wiki/ZAZ#ZAZ_and_its_reputation [09:10:41] <KotH> looks like the ram in my router is going bad :-( [09:11:08] <kshishkov> does it rust or has termites problem? [09:11:31] * KotH doesnt live in a third world country [09:11:49] <KotH> but the machine is old [09:11:56] <KotH> about 20a, IIRC [09:12:07] <KotH> and it has been running non-stop for at least 10 [09:24:52] <pross-au> my wheels: http://commons.wikimedia.org/wiki/File:1980-1984_Holden_WB_utility_01.jpg [09:25:25] * kshishkov uses feet [09:25:41] <KotH> i dont know why, but that car doesnt look CO2 neutral [09:25:43] <KotH> ;) [09:25:56] <kshishkov> KotH: it's Australia [09:29:09] <KotH> right, the only thing they have to be is ozon neutral ;) [09:29:42] <kshishkov> that is another climatic FUD [09:29:55] <KotH> hmm..does anyone have a link to a reliability/lifespan analysis of ssd drives? [09:30:24] <kshishkov> probably not [09:30:34] <astrange> ssd are supposed to just go read-only when they run out of writable space, not break [09:30:48] <astrange> though who knows how they do fail, i think they're too new to know [09:32:05] <kshishkov> there should be theory at least [09:33:04] <KotH> no, they arent [09:33:11] <KotH> flahs based memory has been around for ages [09:33:19] <KotH> so you know how the chips will behave [09:33:39] <KotH> from this it's easy to extrapolate how the drive will behave given a certain FTL algo [09:40:42] <iive> yep, it all depends on the firmware [09:41:36] <iive> the real problem is that current sdd doesn't provide direct way to access the data. I think intel were working in this direction. [10:42:17] <DonDiego> Dark_Shikari: say, what was the result of your looking at Nokia patents? [11:20:25] <iive> tripling the damages x264 corp would pay ;) [12:22:01] <pross-au> CIA-17 wake up [12:22:41] <kshishkov> it's voiceless [12:23:01] <superdump> are RE efforts reasonable soc tasks? probably not as it helps to have prior knowledge of codecs and such to figure out what the hell is going on [12:23:06] * superdump is thinking about VP7/VP8 [12:23:22] <mru> make it a qual task ;-) [12:23:53] <kshishkov> why do we want to have VP8 decoder anyway? [12:24:39] <pross-au> VP8? Is there a binary available yet [12:24:50] <pross-au> kshishkov: completeness [12:25:22] <kshishkov> probably not, so why nobody has committed VP4 decoder yet? [12:25:47] <pross-au> Um, low hanging fruit? [12:25:53] <iive> yesterday somebody blamed mike RE of vp3 as reason for existance of theora... [12:26:02] <iive> do we really need to repeat that mistake? [12:26:07] <mru> lol [12:26:13] <kshishkov> iive: it was On2 diversion as well [12:26:37] <kshishkov> who would build open multimedia standard on REd decoder without encoder available? [12:27:12] <iive> the point is, they could have never figured out the workings of vp3, even with the full source, if it wasn't for mike. [12:27:33] <pross-au> I reckon Bink would be a better choice for a HTML5 format [12:27:40] <superdump> :B [12:27:49] <kshishkov> yay, make Bink next Theora for Xiph [12:27:50] <pross-au> Patent free too [12:27:57] <kshishkov> best point - no opensource encoder ever! [12:28:01] * superdump thinks google are working on some codec in the background [12:28:09] <superdump> maybe i'm too optimisitc [12:28:11] <superdump> +i [12:28:36] <pross-au> superdump: probably, but it will suck [12:29:20] <iive> well, think of it this way. It may be better than real codecs [12:29:36] <superdump> hopefully people with a clue would be working on it and make it technically competent [12:29:45] <kshishkov> iive: did you mean existing or Buffering Inc. codecs? [12:30:14] <iive> the inc. ones. these who you love so much ;) [12:37:31] <pross-au> Considerable effort went into h264. I would imagine the same effort will be involved for 265. [12:38:02] <kshishkov> heh, let some Shikari picture the world with wide h.264 adoption without x264 :P [12:38:24] <pross-au> One organisation building something competive, less patents, yeah right :D [12:39:51] <superdump> well, i suppose one might suspect that html5 video could have very significant repercussions [12:41:29] <pross-au> are there c-to-javascript compilers? [12:41:42] <mru> I hope not [12:41:57] <ohsix> you can make sparse do it in short order :> [12:42:47] <pross-au> javascript version of ffmpeg would be one solution to the html5 mess [12:43:00] <Yuvi> ewwww [12:43:09] <ohsix> how would you get the stuff to the browser, rewriting data: urls? [12:43:49] <Yuvi> and actually xiph's solution to browsers that don't support html5 was to write a java decoder [12:43:54] <ohsix> then theres the bit about getting the audio out [12:44:01] <pross-au> Yuvi: and it sucked bigtime [12:44:05] <Yuvi> indeed [12:44:15] <pross-au> java yuv->bgr conversion [12:44:30] <mru> my eyes, my eyes!!! [12:44:32] <Yuvi> but they spent time making it work with netscape 1.0 or something! [12:45:03] <pross-au> my point is, if the 'decoder' was hosted in javascript then you could 'host' the decoder anywhere [12:45:23] <pross-au> as a workaround for the licensing problem [12:45:48] <pross-au> obviously some javascript hooks for dsp-stuff would be required [12:46:21] <Yuvi> but the the patents include the dsp algorithms [12:46:21] <kshishkov> window.ffmpeg.decodeStream('http://video.google.com/...') [12:46:37] <kshishkov> Yuvi: licensing, not patents [12:48:14] <pross-au> Now all we need is some way to profit from this idea. [12:53:43] <pross-au> Hey MrNaz [12:54:51] <MrNaz> hi there [12:54:56] <pross-au> <- Melbourne [13:12:50] <kierank> that java decoder on wikipedia is awful [13:13:22] <kshishkov> Theora is awful by itself [13:14:19] <pross-au> java " " " " [13:14:35] <kshishkov> that is also too obvious [13:15:08] * kshishkov remembers sitting with disassembly printouts at lectures on Java [13:15:09] <kierank> i've never had a video play on wikipedia [13:15:22] <kierank> java just crashes the browser [13:15:26] <pross-au> kshishkov: java byte code disassembly? [13:15:54] <kshishkov> heck no (but worked with that once too) [13:16:07] <kshishkov> QPEG or TrueSpeech decoder or something [13:16:37] <pross-au> surely you would have been more productive by not attending the lectures [13:16:47] <kshishkov> hah [13:16:59] <kshishkov> first of all, you _must_ attend them [13:17:28] <kshishkov> second, if you attend all lectures (and pass some tests) you man skip an exam [13:17:33] <kshishkov> s/man/can/ [13:17:54] <pross-au> oh. lectures were optional in my time. [13:18:16] <kshishkov> next thing you tell me that you could choose subjects too [13:18:27] <elenril> you couldn't? [13:18:38] <pross-au> iirc, not in first year. [13:18:50] <kshishkov> elenril: where you study at? [13:19:05] <iive> theora written in java.... what else could be done to be more horrible? put theora in .rm ? [13:19:08] <elenril> charles university@prague [13:19:32] <kshishkov> elenril: well, you obviously don't have Soviet system [13:19:54] <kshishkov> iive: we have theora in mkv already, thanks [13:20:10] <pross-au> iive: ogg [13:20:18] <elenril> obviously [13:20:22] <iive> pross-au: ogg in rm! [13:20:24] * elenril is so glad he got out of .ua [13:20:26] <pross-au> ya cant get any worse [13:20:50] <pross-au> technically, rm can go in ogg. [13:21:06] <iive> i want the reverse, put ogg inside rm [13:21:17] <iive> i'm trying to make it more evil. [13:21:23] <kshishkov> elenril: but how, I badly in need of that too. Especially after upcoming elections. [13:21:44] <pross-au> cyas [13:21:48] <iive> kshishkov: isn't it more benefitial to skip lectures and just do the exams? [13:22:41] <kshishkov> iive: no, many lecturers won't give you high mark then. And if you skip lectures you can just be not allowed to take exam. [13:22:54] <iive> oh, same here. [13:23:06] <kshishkov> Soviet system with its abundance of choices ;) [13:23:45] <iive> and then people wonder why nobody works what he has studied about. [13:24:50] <kshishkov> yep, especially when you need to bring a letter from your place of post-university work or you won't get your documents back [13:39:12] <jai> hmm..ralf decoder as soc task? [13:39:21] <jai> maybe someone should fix the demuxer first [13:39:58] <kshishkov> jai, may I point that the person who developed RV4 decoder also had to fix lavc RM demuxer? [13:41:02] <jai> kshishkov: yeah, so maybe that can be mentioned in the task description as well? [13:41:48] <kshishkov> nah, it wasn't mentioned there either [13:42:56] <jai> kshishkov: better yet, fixing the demuxer could be a qualification task [13:44:40] <kshishkov> why not [13:45:28] <ohsix> heh freenodes "new" ircd is no better than the last; and it sends no connection cookie [13:46:36] <mru> I haven't noticed a difference [13:46:42] <kshishkov> indeed, maybe I should use web interface for that? [15:08:16] <CIA-17> ffmpeg: daniel * r21573 /trunk/libavcodec/binkaudio.c: Update binkaudio to new DECLARE_ALIGNED syntax [15:10:23] <bogg> Hi, are there any plans on adding support for the CrystalHD chip from Broadcom to FFmpeg? I've been trying to google any potential discussions regarding this but I've come up with nothing [15:10:40] <kshishkov> you are right [15:11:50] <bogg> In that there are nothing? :D [15:12:15] <kshishkov> nothing _yet_ [15:13:09] <bogg> Ah, ok... Anyway... I'm willing to donate money for the cost of one card if a developer needs one to try out [15:13:21] <iive> nothing that we heard of. [15:13:25] <jai> bogg: announce your intent on ffmpeg-devel [15:13:36] <jai> also, more people read that list [15:13:45] <iive> bogg: good idea, be sure to send mail on ffmpeg-devel maillist. [15:14:13] <iive> btw, what is this chip doing? dsp? or full decoding including cabac? [15:14:53] <Honoome> Mike wrote something about crystalhd [15:15:20] <Honoome> http://multimedia.cx/eggs/installing-crystalhd-drivers-in-linux/ fwiw [15:34:29] <Compn> iive : full decoding iirc [15:35:07] <Compn> i wonder how many streams it can do at once :D [15:38:15] <kshishkov> >= 1 I hope :P [15:42:56] <bogg> official specs says it should be able to decode H.264/AVC HP at L4.1 1080i/1080p, 40 Mbps at full speed [15:43:24] <Compn> depending on pci bus :P [15:43:33] <kshishkov> the question was if it can decode something else simultaneously [15:43:48] <kshishkov> Compn: PCI bus is faster [15:43:59] <Compn> fast enough for two 1080 streams ? [15:44:01] <Compn> ;p [15:44:22] <drv> i thought it was pci express anyway, not pci [15:44:34] <bogg> Compn: 1x PCI-E is capable of handling 250MB/s [15:44:36] <Compn> i thought it was mpcie actually ;\ [15:44:50] <Compn> mini/mobile pci [15:45:30] <kshishkov> you know, even old PCI from your 80386 can handle a dozen of H.264 streams [15:45:30] <Compn> Its a PCI Express mini card which has the same form factor as a PCIe mini wireless networking card. [15:45:39] <kshishkov> the question is where is output :P [15:45:50] <Compn> from mike's post [15:46:00] <ohsix> in pci space [15:46:43] <Compn> 133 MB/s (32-bit at 33MHz) [15:46:44] <bogg> Compn: Mini PCI-E is a X1 PCI-express bus with some added lines (for USB, SMBus, Antennas and so on) and another form factor [15:46:48] <Compn> ok fine, its fast enough :) [15:47:01] <kshishkov> Compn: multiply that by 8 for bytes instead of bits [15:47:30] <bogg> 133MB/s is original PCI-speeds, PCI-Express is 250MB/s per lane, (in ver 1.x) [15:47:53] <bogg> 250 is 2000Mbps, more than enough for some H.264 streams :D [15:47:53] <Compn> yes, kshishkov said pci was fast enough so i wikipedided it [15:47:54] <Compn> ;p [15:48:08] <bogg> ah :) [15:48:29] <bogg> but then again, on most PCI-systems the PCI bus was shared (if not on all) between many units [15:48:45] <kshishkov> nope [15:48:56] <kshishkov> lshw shows you several buses [15:52:04] <bogg> On an Original PCI system? Maybe later v2.3 versions of the PCI bus added non-shared buses [15:52:11] <kshishkov> still, I suspect that raw output may be an bottleneck there [15:54:16] * kshishkov begins to want one, playing 1280x760 rips becomes too CPU hoggy even with mpeg-4 asp [15:54:59] <bogg> Mm, would be lovely to let the CPU rest while watching movies... as it is now my iMac struggles quite a bit just playing 720P material [15:55:50] <ohsix> i'm getting one for my netbook :> i dunno how much power its going to use but it'd be cool to get an extra hour or two if you're just using it as a fancy portable dvd player of sorts [16:07:43] * Honoome wouldn't mind replacing the wireless card with the crystalhd on the appletv and just get Linux/XBMC on it [16:08:39] <ohsix> my netbook has a free slot where the cellphone modem goes in other models :> [16:12:58] <Compn> kshishkov : it makes more sense to get cheap nvidia card [16:13:10] <Compn> which can offload mpeg4 asp as well as mpeg4 avc and even mpeg12 [16:13:25] <Compn> unless crystalhd is $10 or you are talking about laptops only [16:13:28] <Dark_Shikari> DonDiego_: [16:13:41] <Dark_Shikari> http://www.google.com/patents/about?id=Ic0CAAAAEBAJ [16:13:47] <Dark_Shikari> http://www.google.com/patents/about?id=ieIVAAAAEBAJ [16:13:56] <Dark_Shikari> http://www.google.com/patents/about?id=zGWBAAAAEBAJ [16:14:19] <kshishkov> Compn: in my case it will probably be laptop and unlikely gray box [16:14:30] <Anssi> ohsix: it may not necessarily work in that slot, as cellphone modems generally use the USB interface of minipci, so cards using pcie interface may not work in that slot (I read somewhere that someone tried crystalhd in such a slot and it didn't work, had to replace the wlan card) [16:14:38] <Compn> Dark_Shikari : why did all these companies waste so much time on patents ? [16:14:49] <Compn> just to make sure no other companies busted them i guess [16:14:52] <Compn> what a stupid system [16:14:52] <ohsix> Anssi ic, good to know [16:15:16] <ohsix> the ssd also goes in there in another model, so i'm pretty sure its all good [16:16:45] <kshishkov> Compn: and you country is to blame [16:18:07] <j-b> pross ? why vst->codec->codec_id = 0; /* FIXME: CODEC_ID_BINKVIDEO */ ? [16:18:08] <Compn> blame for destroying patents, should be happy :) [16:18:17] <Compn> in a few years anyhow... [16:19:06] <kshishkov> j-b: because he forgot to uncomment it [16:19:22] <j-b> kshishkov: yeah, that is what I wondered [16:21:58] <kshishkov> here, fixed it for you [16:22:40] <CIA-17> ffmpeg: kostya * r21574 /trunk/libavformat/bink.c: Bink video codec id is there, demuxer can use it [16:25:15] <j-b> kshishkov: thx [16:25:48] <kshishkov> not that we have video decoder for it though... [16:26:18] <Dark_Shikari> Now we just need an official way to store bink in matroska [16:26:26] <Dark_Shikari> then we can remux all the bink files to mkv [16:26:42] <ohsix> bkv! [16:27:06] <kshishkov> bleh. Why? [16:27:15] <kshishkov> Bink audio + Theora in .mkv? [16:27:38] <Dark_Shikari> That would be funny. [16:28:01] * Compn bets theora in mkv is one of the least supported files [16:28:14] <elenril> not that we have video decoder for it though << didn't some guy called kshishkov write one? [16:28:16] <Dark_Shikari> nah [16:28:19] <Dark_Shikari> That's what Handbrake produces if you choose Theora [16:28:22] <Dark_Shikari> so it's actually used somewhere [16:28:36] <Dark_Shikari> It was done for the purposes of simplicity, and, for a free bonus, fucking with freetards [16:28:40] <Dark_Shikari> since MKV is FREEEEE too [16:28:42] <kshishkov> elenril: there is only Bink audio decoder in SVN [16:28:46] <Compn> lol [16:28:55] * kshishkov shows OGM to Dark_Shikari [16:29:15] <elenril> lol, they should have used nut [16:29:41] * kshishkov still thinks NUT should store right duration time though [16:29:49] <Dark_Shikari> you're nuts [16:30:00] <ohsix> your usage of freetards overlaps with people who have real legal concerns :( [16:30:10] <Dark_Shikari> ohsix: no it doesn't [16:31:37] <elenril> kshishkov: what does it do? [16:32:01] <kshishkov> elenril: what does? [16:32:14] <elenril> nut [16:32:20] <elenril> what's wrong with duration? [16:34:21] <CIA-17> ffmpeg: stefano * r21575 /trunk/libavfilter/ (vf_vflip.c avfilter.c vf_slicify.c vf_scale.c): [16:34:21] <CIA-17> ffmpeg: Avoid usage of avcodec_get_pix_fmt_name() and [16:34:21] <CIA-17> ffmpeg: avcodec_get_chroma_sub_sample(), directly access [16:34:21] <CIA-17> ffmpeg: av_pix_fmt_descriptors instead. [16:34:21] <CIA-17> ffmpeg: Remove some of the dependancies of lavfi on lavc. [16:34:25] <kshishkov> well, demuxer usually shows duration to be 12-20 seconds independent on real duration [16:35:25] <siretart> I need to insert a line in a file before the very last line. what is the correct sed incantation for that? [16:35:44] * elenril tries [16:35:53] <kshishkov> err, %-1a/something/ [16:36:33] <elenril> error, non monotone timestamps << /me facepalms [16:36:42] <elenril> will somebody ever fix that? [16:36:52] <kshishkov> short awnser - no [16:37:38] <siretart> kshishkov: sed: -e expression #1, char 1: unknown command: `%' [16:37:50] * elenril wonders why he doesn't have ultrafast preset [16:37:53] <elenril> kshishkov: why not? [16:38:25] <kshishkov> sirtart: try with % replaced by $ [16:38:52] <siretart> now it stumbles over the '-' [16:39:07] <kshishkov> elenril: I don't know the whole epos, but it has to do something with DTS and parsers [16:39:12] * siretart is a sed noob, sorry [16:39:20] <elenril> i know that much [16:39:49] <elenril> what i don't know is why is it so hard to fix [16:45:52] <ohsix> Anssi: thanks again for mentioning that, teh wwanmodem that goes in there _is_ usb; and the ssd is PATA, so i'll have to scalp another minipci card and give it a shot before i bother with the crystalhd :> [16:46:37] <Anssi> not that crystalhd is expensive at all, though [16:46:38] <jai> elenril: same here :( [16:46:44] <elenril> hmm, duration doesn't seem to be set at all [16:47:03] <ohsix> still, its like 3$ for me to get a router with a minipci thing in it at a thrift shop, and test it out [16:47:29] <ohsix> can it be called minipci if it doesn't have pci? conversely; if it didn't have usb [16:48:18] <elenril> jai: it fails with all b-pyramid h.264 in matroska [16:48:36] <Dark_Shikari> not just b-pyramid [16:48:37] <Dark_Shikari> b-frames [16:48:40] <elenril> (and in many other cases) [16:49:29] <ohsix> wikipedo mentions the zombie minipci things that are in the mini9 and the asus netbooks :P [16:49:59] <kshishkov> I'd stay away from Asus [16:50:35] <ohsix> nod, i still may get one for the tiny keyboard though, my hp mini is downright nice [16:51:30] <kshishkov> Aspire One netbook I own is shitty [16:52:03] <ohsix> heh i know a guy that has one of those, his power adapter has exploded 3 times and its really poor with linux, and not for the regular reasons, the firmware is meh [16:52:28] <kshishkov> well, it worked for me [16:52:47] <kshishkov> except for badblocks on HDD and faulty power socket in netbook itself [16:52:47] <ohsix> keen, does yours have the ath9k or the ath5k? [16:53:10] <kshishkov> probably 5k [16:53:25] <ohsix> do you get lockups with it, or do you not use the wifi [16:53:28] <kshishkov> driver works fine since update in August [16:53:54] <kshishkov> it was fun updating it by downloading package by WiFi [16:53:57] <ohsix> i'll pass that on, i assumed he did all the firmware updates but never asked [16:54:22] <ohsix> mine has a b43 :< needs to have the firmware but otherwise works great [17:14:51] <CIA-17> ffmpeg: stefano * r21576 /trunk/libavutil/pixdesc.h: Fix grammar: write to DST THING -> write THING to DST. [17:44:10] <CIA-17> ffmpeg: michael * r21577 /trunk/libavformat/utils.c: [17:44:10] <CIA-17> ffmpeg: Increase search range if no end timestamp could be found for the duration [17:44:10] <CIA-17> ffmpeg: calculation. [18:08:49] <CIA-17> ffmpeg: michael * r21578 /trunk/ffplay.c: Fix indention. [18:47:04] <siretart> DonDiego: re your mail, for the next upload, I'm going to butcher around in config.h [18:47:19] <mru> ??? [18:47:58] <siretart> mru: see http://bugs.debian.org/567725 [18:50:10] <mru> I don't see why you'd need to butcher config.h [18:50:18] <mru> have you not read the comment at the top? [18:50:35] <siretart> mru: ffmpeg 0.5 does not support that switch yet [18:50:48] <siretart> as stated in a later comment [18:50:51] <mru> so? [18:51:06] <siretart> ? [18:51:12] <mru> I don't see why you'd need to butcher config.h [18:51:51] <siretart> I need to get CONFIG_RUNTIME_CPUDETECT added to config.h [18:52:07] <mru> teach configure to add it [18:52:09] <mru> it's one line [18:52:24] <mru> this ain't autoconf you know... [18:52:46] <siretart> which line? [18:52:57] <siretart> CONFIG_LIST? [18:54:35] <siretart> hm.. that would be revision 18380 [18:54:41] <siretart> ok, let's try that [18:55:20] <CIA-17> ffmpeg: michael * r21579 /trunk/ffplay.c: decoder reorder pts auto detection. [18:55:41] <mru> I'd rather you patched the code than messed with config.h [18:55:59] <mru> makes it easier to see what the change really is [18:56:46] <siretart> r18380 does changes in postproc as well. I hope they are safe for 0.5... [18:56:53] <mru> ask DonDiego [18:57:04] <siretart> I guess he's busy [18:59:39] <siretart> the changes look safe. let's upload and see what burns [20:06:32] <mru> Dark_Shikari: ping [20:18:06] <Yuvi> mru: the stupid in the reddit thread on your latest gcc bash... ugh... [20:35:13] <Dark_Shikari> mru: pong [20:41:47] <astrange> ...the draft copy of c99 i have has "september" misspelled in the header on every page [20:42:29] <Dark_Shikari> lol [20:46:21] <astrange> mru: gcc doesn't "focus on for loop optimization" [20:46:33] <mru> of course not [20:46:58] <astrange> it prefers loops that pass scalar evolution analysis (not modifying or checking the iteration variable) but that is one [21:02:19] <KotH> does anyone of you guys, who come to fosdem want anything from .ch? [21:04:42] <mru> KotH: chocolate and more chocolate [21:22:09] <KotH> mru: why did i know that you'd say that? [21:22:46] <mru> it's because I'm lazy [21:23:49] <thresh> suppose mru is not a big fan of czech beer :) [21:24:05] <iive> KotH: bring some democracy ... you have more than you need there. [21:24:17] <mru> in the interest of minimising effort, I strive to be so predictable that other people will say my jokes with no action required from me [21:24:33] <mru> KotH: bring some minarets [21:24:57] <KotH> iive: democracy? in a country that just outlawed muslims? [21:25:15] <mru> KotH: not muslims, only their attributes [21:25:27] <iive> yes, it was done (too) democratically. [21:25:46] <KotH> mru: you havent reached yet the level of rich... he is able to flame w/o saying even a word himself :) [21:26:38] <mru> ah... _now_ it all makes sense... it's rich that's causing all the flames recently [21:26:43] <mru> I should've known... [21:27:20] <iive> it fits. He is probably at everest, broadcasting flames. [21:31:09] <Compn> FREEDUMB [21:31:22] <Compn> so much of it, we're giving it away [21:31:25] * KotH frees the dumb [21:42:08] <KotH> oyasumi, minna [21:43:14] <pasteeater> in roundup, how do i remove a file I previously uploaded via the web interface for a bug report? I get "Edit Error: Please describe the change" even if i add a change note. [22:55:09] <DonDiego> siretart: please [22:55:16] <DonDiego> what nonsense do i have to read there? [22:55:23] <DonDiego> messing with config.h .. [22:55:31] <mru> that's what I said too [22:55:47] <DonDiego> at least echo a line into config.h from configure [22:55:56] <DonDiego> or just port the relevant commit [22:56:04] <DonDiego> and all of it of course [22:56:39] <mru> we need to do a new release [22:57:17] <DonDiego> let's talk about it at fosdem [22:57:31] <mru> what will it be? 0.75 to be followed by 0.875... [22:57:49] <DonDiego> 0.6 [22:57:56] <mru> so boring ;-) [22:57:57] <DonDiego> 0.5.1 first [23:03:28] <iive> DonDiego: are your exams over? [23:09:41] <DonDiego> no [23:09:48] * DonDiego longs for the demise of flash [23:09:55] <mru> DonDiego: professor back yet? [23:10:15] <DonDiego> nope [23:10:23] <DonDiego> hasn't shown a sign of life yet [23:11:35] <DonDiego> what's it with mike and his flash rants? [23:11:51] <DonDiego> it seems he's drunken too much corporate kool-aid.. [23:14:30] <iive> have in mind, this is my second post where I propose using ffmpeg libraries to accelerate flash. [23:24:41] <DonDiego> not gonna happen [23:42:20] <ramiro> I've just deleted all of /lib [23:42:24] <ramiro> that was fun. [23:44:12] <ramiro> sab: hi stefano [23:44:45] <sab> hi ramiro [23:44:54] <sab> hi all [23:45:07] <sab> I'm trying to take the habit to frequent irc... [23:45:43] <DonDiego> you should identify [23:46:02] <sab> hi diego i'm quite a noob with irc please instruct [23:46:27] <ramiro> sab: /msg nickserv help [23:46:46] <DonDiego> yes - and go from there [23:47:36] <sab> ugh now I remember why I was trying to avoid that ;-) [23:48:55] <ramiro> it's not hard. depending on the program you're irc'ing from you can configure it to identify automatically [23:49:46] <sab> mmh yes I believe you I'm using xchat right now [23:50:03] <ramiro> sab: irssi ftw! [23:50:06] <ramiro> and screen [23:50:34] <ramiro> sab: by the way I tried using mutt like you suggested to ffmpeg-user some time ago and it deleted all my draft folder from gmail. [23:50:45] <ramiro> well, basically I told it to, but I wasn't aware of that. [23:50:52] <sab> ahah good move [23:51:01] <ramiro> so I lost my swscale description I was writing up [23:51:30] <sab> eheh mutt may bite [23:52:06] <ramiro> and now I'm supposedly on vacations. tried acessing my computer at home, deleted all of /lib over there, so nothing works anymore. well I guess I'll actually have to enjoy my week of vacations. [23:52:35] <ramiro> I think the fate boxes will be down, but I'm not sure yet. I'm sure the autobuilds are down. [23:53:41] <mru> hey guys, help me out a bit on reddit [23:53:46] <mru> and bring pitchforks [23:54:08] * DonDiego is busy with his own flames

1 0