Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2010

1 participants
30 discussions

IRC log for 2010-09-29
by irc＠mansr.com 30 Sep '10

30 Sep '10

[01:15:18] <BBB> Dark_Shikari: you said my horizontal sum sucks, so is there an easier way to do a sum of all parts of a register? [01:43:24] <BBB> oh I see I took the wrong dsputilenc_mmx.c func, HSUM_SSE2 is much better, will copy that [01:43:42] <BBB> another 4-5 cycles off... [02:32:27] <Dark_Shikari> BBB: you could also look at x264 [02:32:40] <BBB> ah, he's back [02:32:43] <BBB> so where do I look? [02:32:50] <BBB> predict-a.asm looks completely different [02:32:59] <BBB> it's passed a int b and int c in the function arguments [02:33:06] <BBB> suggesting that part of the code is run elsewhere [02:33:40] <BBB> (that part = V and H coeff calc) [02:34:07] <Dark_Shikari> go look in predict-c.c then [02:34:08] <Dark_Shikari> use grep [02:36:42] <BBB> I probably grepped in *.asm [02:36:50] <BBB> not very useful, clearly ;) [02:42:35] <Dark_Shikari> BBB: there is no 4x4 plane [02:45:02] * BBB feels stupid [03:05:10] <BBB> Dark_Shikari: yours is about 10 cycles slower [03:05:20] <BBB> (once you add all the non-constant stride and everything) [03:06:53] <Compn> michael : how many people are using vf geq? i found this page > http://www.mtbs3d.com/phpbb/viewtopic.php?f=27&t=4521&start=15 . i'm curious how many applications it has ? [03:07:23] * Compn should probably just mail things to people [03:08:17] <BBB> Compn: he doesn't grep for typos [03:08:23] <BBB> ae->ea? [03:11:58] <Compn> doh [03:12:29] * Compn wonders how bbb spells michael [03:13:17] * Compn goes afk [03:15:39] * BBB never realized that [03:15:47] <BBB> and oddly, when I type his name, I spell it correct [03:15:50] <BBB> without realizing it [03:15:52] <BBB> hm [03:15:54] * BBB needs sleep [04:52:05] <lu_zero> good morning! [06:12:30] <KotH> bonjour mes enfants! [06:13:59] <benoit-> KotH: salut ! [06:16:33] <lu_zero> ohayoo-! [06:24:09] <mru> morning [06:33:22] <lu_zero> hi mru [06:49:15] <Tjoppen> "the comments dont look doxygen compatible" [06:49:41] <Tjoppen> what do inline doxy comments look like? [06:50:03] <mru> //< or /*< iirc [06:50:15] <mru> maybe one more / or * [06:50:30] <mru> I never really cared much about doxygen [06:50:36] <Tjoppen> /**< */ it seems [06:50:50] <Tjoppen> michael appearently does [06:50:59] <mru> has anyone here _ever_ looked at the generated files? [06:51:16] <mru> it's just another obsession he has [06:51:29] <wbs> only to ensure that the doxy comments I've written were correct [06:52:04] <Dark_Shikari> lol [06:52:12] <Tjoppen> hah [06:52:12] <Dark_Shikari> doxy: javadoc for c [06:52:27] <Dark_Shikari> except probably not as good [06:52:51] <mru> Dark_Shikari: have you looked at the mess it produces? [06:52:55] <Dark_Shikari> which? [06:53:00] <mru> doxygen [06:53:03] <Dark_Shikari> yes [06:53:06] <Dark_Shikari> as I said, not as good [06:53:17] <mru> javadoc arranges by class, which is natural for java [06:53:46] <mru> and the style is almost comprehensible [06:54:25] <mru> which is of course no help when dealing with a typical java monstrosity of all framework and no actual code [06:55:24] <Dark_Shikari> of course [06:57:19] <superdump> i have a question - does _anyone_ actually use the doxygen documentation? [06:57:38] <mru> superdump: highly unlikely [06:58:02] <superdump> i looked at it a few times and found it to be weirdly organised, missing information everywhere and looking at the headers / code was far more useful [06:58:13] <mru> +1 [06:58:23] <peloverde> +1 [06:58:26] <mru> I think that's how doxygen is meant to be [06:58:30] <wbs> "far more useful" is like the understatement of the year ;P [06:58:34] <superdump> useless? [06:58:35] <mru> I've never seen it otherwise [06:58:57] <wbs> true, I don't think I've ever got anything out of reading doxygen docs for some other project either [06:59:06] <mru> try alsa for fun [06:59:09] <Dark_Shikari> I find that the best form of documentation is lots of plain-english explanation [06:59:13] <Tjoppen> where is it generated to? I can't find anything related to say http.c in doc/ [06:59:18] <Dark_Shikari> at least for things which do Interesting Things (TM) [06:59:28] <Tjoppen> or do I need to make a special target? [07:00:14] <mru> yes, but I don't remember it [07:00:20] <mru> check the makefile [07:00:22] <Dark_Shikari> http://pastebin.com/8PfkgQSn <--- imagine if this used doxy instead of an actual explanation [07:00:31] <Dark_Shikari> @param x264 handle [07:00:33] <Dark_Shikari> @param pts to invalidate [07:00:59] <mru> that style works for trivial functions like memcpy [07:01:13] <Dark_Shikari> even then, you need to document things like the overlap requirement [07:01:29] <Dark_Shikari> most trivial functions aren't [07:01:40] <mru> I like the posix reference [07:01:48] <Dark_Shikari> yeah, posix is generally good [07:02:18] <mru> odd quirks are usually given a reason too [07:02:22] <mru> not just stated [07:03:23] <Tjoppen> just running doxygen seems to do it. quite a lot of spew though [07:03:36] <mru> yes [07:03:41] <mru> another understatement [07:03:58] <mru> and somewhere in the midst is an important warning [07:05:24] <Dark_Shikari> mru: you could say that about the ffmpeg build too [07:05:28] <Dark_Shikari> ;) [07:05:49] <mru> the spew from ffmpeg build is mostly warnings [07:05:53] <mru> which imo should be fixed [07:06:07] <mru> but that's difficult when we have people dead-set against it [07:06:49] <KotH> Dark_Shikari: using doxygen comments doesn't mean that you should not properly document the function [07:07:11] <Dark_Shikari> mru: "strict aliasing is for chumps" [07:07:36] <mru> and staying within arrays [07:08:07] <Dark_Shikari> I recall a warning in ffmpeg.c about a printf with a zero-length format string [07:08:10] <Dark_Shikari> around line ~500 [07:08:18] <mru> yeah, that's a new one [07:08:39] <mru> stupid gcc [07:09:23] <Dark_Shikari> stupid? [07:09:26] <Dark_Shikari> isn't that a pretty valid complaint? [07:09:43] <mru> how would it know it's not intentional? [07:09:47] <mru> this isn't the actual printf [07:09:52] <Dark_Shikari> av_log(NULL, AV_LOG_QUIET, ""); [07:09:56] <mru> just a function with a printf-style format string [07:10:00] <Dark_Shikari> ahhhhh [07:10:06] <Dark_Shikari> I see [07:10:17] <Dark_Shikari> so it's complaining about something that isn't printf. [07:10:20] <Dark_Shikari> just Like Printf. [07:10:38] <mru> as far as gcc knows, that function might do something sensible with an empty string [07:10:43] <mru> and _does_ do something [07:10:58] <mru> I somewhat disagree about how sensible it is [07:11:09] <mru> but that's beside the point [07:11:17] <Dark_Shikari> oh, I just realized that x264 technically has a bug, from looking at ffmpeg.c [07:11:22] <Dark_Shikari> anything like sigterm_received must be volatile [07:11:25] <Dark_Shikari> x264's aren't [07:11:53] <mru> yeah [07:12:01] <mru> that's one of the rare correct uses of volatile [07:13:47] <Dark_Shikari> well it has to be used for any variable which can be set by another thread and isn't mutexed or similar [07:14:35] <mru> it is often used incorrectly with memory mapped devices [07:14:56] <mru> it simply doesn't do the right thing there [07:15:13] <mru> it screws with the compiler enough that it often ends up working by accident [07:15:32] <KotH> hmm? [07:15:37] <KotH> mru: can you explain that a little bit? [07:15:49] <Tjoppen> interesting.. doxygen doesn't make use of comments in enums [07:16:00] <mru> a write to a memory mapped register usually requires a memory barrier [07:16:15] <mru> volatile doesn't add one [07:16:18] <mru> try it [07:16:22] <KotH> hmm.. [07:16:39] <mru> and the proper barrier depends on the nature of the mapping [07:16:41] <KotH> what's the correct solution then? [07:16:44] <mru> which the compiler cannot know [07:17:11] <mru> correct solution uses compiler intrinsics or inline asm to produce a barrier [07:18:26] <KotH> hmm... i dont exactly see why a write/read to a mem mapped register would need a memory barrier [07:18:43] <mru> to make sure things happen in the right order [07:18:47] <mru> and that they happen at all [07:19:03] <mru> otherwise multiple writes to the same register could be dropped in a write buffer [07:19:08] <mru> seen that happen [07:19:13] <mru> confusing results [07:19:59] <mru> when reads and writes have side effects other than updating some storage, order is very important [07:20:14] <KotH> woudlnt that require just a reorder barrier? [07:20:25] <mru> a barrier nonetheless [07:20:35] <mru> as I said, the right type of barrier depends on the system [07:20:41] <mru> and the type of mapping [07:20:58] <KotH> hmm.. [07:21:01] * KotH takes notes [07:21:14] <KotH> i'll come back to you when i encounter such problems :) [07:21:22] <mru> all volatile does is force the compiler to issue a load or store instruction [07:21:59] <KotH> *nod* [07:22:27] <mru> making the write visible outside the cpu might take more effort [07:22:30] <mru> like barriers [07:23:16] <Dark_Shikari> doing cross-platform mutex-less code is really hard [07:23:34] <Dark_Shikari> *threaded code [07:23:43] <mru> you always need some kind of barrier [07:24:28] <Dark_Shikari> yeah but there's no cross-platform barriers [07:24:30] <Dark_Shikari> besides... mutexes [07:25:34] <mru> so you write your own and fall back to mutexes [07:34:06] <Tjoppen> there's probably one in boost [07:37:26] <pJok> i wonder what happened to Basty [07:37:37] <pJok> and god morgon [07:39:50] <wbs> IIRC, he never finished his qualification task either, right? [07:39:51] <av500> pJok: i guess he is cleaning his 80k LOC line by line... [07:40:11] <av500> converting amiga asm to c and doxygen [07:43:32] * KotH converts av500 to pic asm [07:43:48] <av500> inline or yasm? [07:44:05] <KotH> neither nor [07:44:39] * av500 puts a memory barrier around KotH [07:51:07] <lu_zero> av500: a ppc memory barrier to be extra safe [07:59:40] <av500> lu_zero: more like a physical memory barrier [08:00:35] <kshishkov> av500: i.e. forget about him completely? [08:01:00] <pJok> hehe [08:07:31] <av500> kshishkov: remove the memory module [08:07:41] <mru> lu_zero: eieio [08:19:44] * pJok calls mru for HURD [08:20:06] <Dark_Shikari> The GNU operating system! [08:20:31] <Dark_Shikari> someone should start a promotional campaign for GNU/Windows, promoting it as a modern "GNU operating system". [08:20:44] <Dark_Shikari> just to troll rms [08:21:33] <ohsix> GNU/NT7 [08:22:12] <Dark_Shikari> GNU: a modern enhancement to the world's best operating system. [08:22:45] <pJok> Dark_Shikari, windows is fully POSIX compliant... it answers ENOTIMPLEMENTED to every request [08:23:25] <pJok> and wouldn't ReactOS be a candidate for GNU/Windows? [08:23:41] <ohsix> on the trademark alone, no [08:23:59] <Dark_Shikari> GNU/windows is windows + cygwin or mingw [08:30:36] <thresh> is pandaboard any good? [08:33:20] <av500> omap4 [08:33:29] <av500> its one better than omap3 [08:36:09] <Dark_Shikari> omap4 is out? [08:36:19] <av500> depends on "out" [08:36:35] <av500> engineering samples exist [08:36:43] <av500> and pandaboards [08:37:06] <av500> http://omappedia.org/wiki/PandaBoard/earlyadopter [08:53:36] <superdump> why is http://pandaboard.org/ an image? [08:53:54] <Dark_Shikari> LOL [08:54:29] <superdump> a jpeg no less [08:55:18] <av500> i guess it is a placeholder [09:02:27] <thresh> so it will differ from other sites [10:41:37] <mmu_screen> http://dev.haiku-os.org/changeset/38847 anyone ? [10:46:17] <merbzt> looks ok, proxy it to the mailinglist [11:43:37] <twnqx> mmu_screen: was that dependency build into the makefiles with enable/disable for the codecs as well? [11:44:08] <twnqx> as in: does the mpeg4 encoder enable the h263 encoder automatically? [12:00:19] <CIA-63> ffmpeg: michael * r25250 /trunk/libavcodec/avcodec.h: Add AVClass for the private context, this will be used for codec specific options. [12:13:04] <mmu_man> twnqx didn't look at it [12:13:27] <mmu_man> thing is we keep the config.h in svn there, so maybe it's the reason [12:35:37] <CIA-63> ffmpeg: rbultje * r25251 /trunk/libavfilter/x86/yadif.c: [12:35:37] <CIA-63> ffmpeg: Fix compile on Darwin (FATE). Compile error: [12:35:37] <CIA-63> ffmpeg: yadif.c:226: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' [12:35:37] <CIA-63> ffmpeg: yadif.c:220: error: 'asm' operand has impossible constraints [12:35:38] <CIA-63> ffmpeg: Patch by Alexander Strange <astrange ithinksw com>. [13:35:16] <CIA-63> ffmpeg: rbultje * r25252 /trunk/libavcodec/x86/h264dsp_mmx.c: [13:35:17] <CIA-63> ffmpeg: Unloop the outer loop in h264_loop_filter_strength_mmx2(), which allows [13:35:17] <CIA-63> ffmpeg: inlining various constants within the loop code. 20 cycles faster on [13:35:17] <CIA-63> ffmpeg: cathedral sample. [13:36:20] <CIA-63> ffmpeg: rbultje * r25253 /trunk/libavcodec/x86/h264dsp_mmx.c: [13:36:20] <CIA-63> ffmpeg: Unroll inner bidir loop in h264_loop_filter_strength_mmx2(), which gets rid [13:36:20] <CIA-63> ffmpeg: of the d_idx variable and therefore allows for future optimizations. No speed [13:36:20] <CIA-63> ffmpeg: difference by this commit itself. [14:03:32] <CIA-63> ffmpeg: rbultje * r25254 /trunk/libavcodec/x86/h264dsp_mmx.c: [14:03:32] <CIA-63> ffmpeg: Remove d_idx as a variable, and instead load it as a constant in the asm. [14:03:32] <CIA-63> ffmpeg: This has no measurable speed effect because the surrounding code doesn't [14:03:32] <CIA-63> ffmpeg: take advantage of this yet. [14:04:26] <CIA-63> ffmpeg: rbultje * r25255 /trunk/libavcodec/x86/h264dsp_mmx.c: [14:04:26] <CIA-63> ffmpeg: Remove mv_mask variable. Replace the related pand -1/0 instructions by either [14:04:26] <CIA-63> ffmpeg: a pxor, or remove the instruction alltogether. Altogether, this saves 1 [14:04:26] <CIA-63> ffmpeg: instruction. [14:05:32] <CIA-63> ffmpeg: rbultje * r25256 /trunk/libavcodec/x86/h264dsp_mmx.c: [14:05:32] <CIA-63> ffmpeg: Merge b_idx and edge variables, and optimize the ASM to directly load variables [14:05:32] <CIA-63> ffmpeg: from memory locations/offsets depending on b_idx plus constants, rather than [14:05:32] <CIA-63> ffmpeg: having gcc do this. This saves several lea calls and together saves about [14:05:32] <CIA-63> ffmpeg: 10 cycles in h264_loop_filter_strength_mmx2(). [14:57:37] <BBB> it's a little annoying how the START/STOP_TIMER thing is affected by other stuff running on the system [14:57:51] <BBB> I'm watching a youtube video and my performance drops by a good 20-30% :( [14:59:05] <av500> get a proper "system" :) [15:03:17] <twnqx> ok... how does the ffmpeg from git.ffmpeg.org get its swscale? [15:06:39] <CIA-63> ffmpeg: michael * r25257 /trunk/libavcodec/ (avcodec.h options.c utils.c): [15:06:39] <CIA-63> ffmpeg: Move allocation and init to defaults of the private codec contexts to avcodec_get_context_defaults3(). [15:06:39] <CIA-63> ffmpeg: That way the user app can set codec specific parameters in the private context [15:06:39] <CIA-63> ffmpeg: before opening it. [15:11:31] <astrange> twnqx: git submodule init [15:11:32] <CIA-63> ffmpeg: michael * r25258 /trunk/libavcodec/libvorbis.c: [15:11:32] <CIA-63> ffmpeg: Allow setting the impulse block bias for libvorbis through a private codec parameter. [15:11:32] <CIA-63> ffmpeg: First example and test of private codec parameters. [15:18:27] <jannau> twnqx: just use http://git.jannau.net/git/FFmpeg.swscale/ [15:27:21] <twnqx> hm [15:27:33] <twnqx> and clone that straight into the ffmpeg dir? [15:32:52] <jannau> twnqx: not my repo. that repo has ffmpeg and libswscale integrated with interleaved history [15:34:23] <twnqx> mh [15:34:35] <twnqx> how often are you tracking the svn (or svn tracking git)? [15:35:39] <CIA-63> ffmpeg: rbultje * r25259 /trunk/libavcodec/x86/dsputil_mmx.c: [15:35:39] <CIA-63> ffmpeg: Use sse2 variant of put_pixels16() for no_rnd also. Provides a minor speed [15:35:39] <CIA-63> ffmpeg: increase to e.g. vc1, snow and mpeg decoding. [15:35:39] <CIA-63> ffmpeg: Patch by Eli Friedman <eli dot friedman gmail com>. [15:40:23] <jannau> twnqx: repo sync is triggered by commit mails [15:44:35] <CIA-63> ffmpeg: rbultje * r25260 /trunk/libavformat/mmsh.c: [15:44:35] <CIA-63> ffmpeg: Check return value of get_chunk_header(). Since enum can be unsigned, the [15:44:35] <CIA-63> ffmpeg: current code wouldn't always error out on errors. [15:44:35] <CIA-63> ffmpeg: Based on patch by Stephen d'Angelo <sdangelo evertz com>. [15:44:36] <CIA-63> ffmpeg: astrange * r25261 /trunk/libavcodec/rawdec.c: rawdec: Properly pass reordered_opaque through the decoder [16:07:35] <twnqx> so after i created a local branch that tracks master... i have to add all the files i checked out again? [16:07:40] <twnqx> (in git) [16:08:13] <twnqx> no wait, it complains about .d and .o files. nevermind. [17:00:04] <BBB> mru: can you test my patch on ML agianst gcc-3.x? [17:00:10] <BBB> (or anyone else for that matter) [17:19:22] <lu_zero> BBB: gcc-3? [17:34:52] <BBB> lu_zero: yeah (I don't have gcc3/gcc2.x) [17:43:20] <CIA-63> ffmpeg: rbultje * r25262 /trunk/libavcodec/x86/h264dsp_mmx.c: [17:43:20] <CIA-63> ffmpeg: Move static inline function to a macro, so that constant propagation in [17:43:20] <CIA-63> ffmpeg: inline asm works for gcc-3.x also (hopefully). Should fix gcc-3.x FATE [17:43:20] <CIA-63> ffmpeg: breakage after r25254. [17:58:47] * lu_zero shouldn't [18:06:20] <CIA-63> libswscale: stefano * r32400 /trunk/libswscale/swscale.h: Add documentation for the returned value of sws_init_context(). [18:06:25] <CIA-63> libswscale: stefano * r32401 /trunk/libswscale/ (swscale.h utils.c): [18:06:25] <CIA-63> libswscale: Deprecate sws_getContext(), use sws_alloc_context() and [18:06:25] <CIA-63> libswscale: sws_init_context() instead. [18:06:25] <CIA-63> libswscale: stefano * r32402 /trunk/libswscale/utils.c: Cosmetics: fix braces placement. [18:06:26] <CIA-63> libswscale: stefano * r32403 /trunk/libswscale/options.c: [18:06:26] <CIA-63> libswscale: Amend constraints for the src_format and dst_format options in the [18:06:27] <CIA-63> libswscale: SWScale context. [18:06:30] <CIA-63> libswscale: stefano * r32404 /trunk/libswscale/utils.c: [18:06:30] <CIA-63> libswscale: Put if (...) av_log() in the same line, more compact and increase [18:06:30] <CIA-63> libswscale: readibility. [18:06:30] <CIA-63> libswscale: stefano * r32405 /trunk/libswscale/utils.c: [18:06:30] <CIA-63> libswscale: Cosmetics: put "if (...)" and "av_log(...)" in the same line for [18:06:30] <CIA-63> libswscale: improving vertical alignment and readability. [18:07:05] * KotH just ordered an OGD1 [18:07:25] <KotH> you wouldnt believe that these damn beasts are produced and already shipping! [18:07:32] <lu_zero> uh? [18:07:39] <lu_zero> does it work as well? [18:07:58] <lu_zero> (as in does it makes a good tasting coffee?) [18:08:04] <KotH> according to our guys in the colonies, yes [18:08:27] <Rathann> does it run compiz? ;) [18:08:42] <Rathann> hi guys, BTW [18:10:00] <KotH> moin Rathann [18:10:09] <KotH> Rathann: it can run anything you want to run on it :) [18:10:26] <KotH> there is actually a guy who bought one for cryptography [18:10:28] <lu_zero> (once you wrote the driver AND the firmware) [18:10:34] <Rathann> I didn't ask if it can, I asked if it does [18:10:47] <KotH> i dont know ^^' [18:10:51] <Rathann> i.e. are there dri/3d drivers for it [18:10:53] <KotH> i've been out of touch lately [18:18:18] <_av500_> KotH: can it hw accell bink? [19:21:30] <KotH> _av500_: if you write the verilog code for it :) [19:22:35] <KotH> _av500_: i actually plan to design a video accel unit for it... if i can make some time free [19:27:36] <lu_zero> ^^; [19:27:46] <lu_zero> KotH: and we'd access it using va-api? [19:27:51] * lu_zero runs [19:32:55] * mru is back in the uk [19:33:28] <_av500_> uk: hide [19:42:28] <kshishkov> mru: I won't believe it until ARM5 entry in FATE is not grey ;) [19:44:53] <wbs> kshishkov: oh, we support that old cpus too? ;P [19:44:59] <wbs> or I guess you mean armv5 ;P [19:45:02] <jannau> poor sheevaplug [19:45:38] <jannau> s/plug/zombie/ [19:45:59] <kierank> _av500_: we're not scared of mru [19:48:30] <KotH> lu_zero: you cannot run that fast! ;) [19:51:14] <mru> and now suncc is choking on some inline asm [19:51:25] <mru> BBB: why oh why did you do it like that? [19:51:31] <mru> just use yasm [19:51:42] <mru> ignore the whines from our dear leader [19:56:33] <BBB> mru: suncc is choking on that very piece of asm [19:56:46] <BBB> mru: I may just be waiting for michael to say "ok, we should use yasm for this code" [19:57:27] <BBB> I still have the yasm patch on top of my tree ;) [19:57:40] <mru> he did say "Iam starting to think that too in this case ..." [19:57:42] <mru> about yasm [21:08:22] <BBB> mru: let's finish his thinking with him :) [21:09:11] <lu_zero> 21:47 < KotH> lu_zero: you cannot run that fast! ;) [21:09:24] <lu_zero> I can use chocolate to slow you down =) [21:15:42] <jannau> mru: any suggestions for the colour^Wname of the "base" flag? AV_CPU_FLAG [21:35:23] <CIA-63> ffmpeg: bcoudurier * r25263 /trunk/libavformat/isom.c: Use new apple fourcc for mpeg-1 and mpeg-2 in mov, works natively on osx [21:36:41] <CIA-63> ffmpeg: bcoudurier * r25264 /trunk/libavformat/isom.c: Remove duplicate entries [21:38:36] <BBB> mru: check the awesome new oracle forums [21:38:37] <BBB> http://forums.oracle.com/forums/forum.jspa?forumID=895 [21:38:58] <BBB> I almost don't dare disturb the peaceful silence [21:39:14] <mru> not loading [21:39:23] <mru> I think there's a slight routing problem here [21:40:44] <jannau> mru: there's nothing to see. sun studio c forum with a single message [21:41:03] <mru> I guessed as much [21:42:31] <jannau> to be fair it seems that the forum was created on 2010-09-17 [21:42:48] <mru> don't spoil the fun [21:42:56] <CIA-63> ffmpeg: stefano * r25265 /trunk/libavutil/opt.c: Add missing case for FF_OPT_TYPE_DOUBLE in av_opt_set_defaults2(). [21:43:26] <mru> http://www.eecs.harvard.edu/cs152/lectures/CS152-Lecture_14-Kernighan.pdf [21:43:31] <mru> lol @ page 2 [21:43:34] <_av500_> jannau: and the msg itself is way cool [21:44:04] <_av500_> mru: comic sans? are you serious? [21:44:16] <mru> that was my first thought too [21:44:18] <kierank> mru: clouds [21:44:35] <mru> but I like the description of java [21:45:20] <kierank> _av500_: kernihan has a special "comic sans licence" [21:46:03] <_av500_> we have one school here that has the name of a famous erman politician [21:46:16] <_av500_> and the name is in big comic sans letter on said school... [21:46:21] <_av500_> +g [21:46:47] <kierank> and that school instantly became a nursery? [21:47:00] <_av500_> no [21:49:25] <_av500_> kierank: but look at the homepage: http://www1.tu-darmstadt.de/schulen/fes-da/ [21:49:38] <astrange> tim sweeney and SPJ both tend to do presentations in comic sans too [21:49:46] <bcoudurier> Dark_Shikari, x264 segfault here in macroblock_encoder when trying 10 bit encoding [21:49:49] <kierank> _av500_: where can i sign up [21:49:49] <mru> it's missing <blink> [21:49:58] <_av500_> I once got a presentation from TI in comic sans [21:50:36] <kierank> my win98 desktop used comic sans [21:54:12] <hyc> anyone else get an email today from TI about this new C6EZRun tool for porting ARM code to DSP? [21:55:04] <mru> that's not what it is [21:55:47] <mru> it's a tool for generating rpc stubs to call functions on the dsp [21:55:58] <hyc> ahh [21:56:06] <hyc> so you're already familiar with these tools [21:56:11] <mru> or something like that [21:56:15] <_av500_> hyc: somewhat [21:56:19] <mru> it's not new at all [21:56:22] <_av500_> i am not excited [21:56:42] <hyc> ok, that reaction tells me enough ;) [21:57:10] <_av500_> mru: its also the other way round, you call printf on the dsp and it ends up on the arm [21:57:28] <mru> when excited, a programmer can fall back to normal state by emitting an instruction [21:57:41] <_av500_> HCF [21:57:42] <mru> _av500_: same principle [21:57:48] <lu_zero> mru: excited by what? [21:58:20] <_av500_> mru: thats how you do neon code? [21:58:25] <_av500_> you glow? [21:58:56] <lu_zero> _av500_: might be a fun picture [21:59:02] <lu_zero> "neon coders" [22:07:26] <lu_zero> the new swscale api looks over..over..over. [22:07:28] <lu_zero> over [22:07:42] * lu_zero keeps looping in a corner [22:39:33] * _av500_ glares at lavc mp3 decoder [22:40:00] <mru> what of it? [22:40:20] <_av500_> im trying to use it [22:40:33] <mru> but it's using instead? [22:40:38] <mru> +you [22:40:39] <_av500_> yeah [22:40:52] <_av500_> inb4 soviet russia [22:41:10] <_av500_> it wants whole frames it seems [22:41:11] <kierank> what's wrong with lame? [22:41:17] <_av500_> outrageous! [22:50:43] <mru> libmad is worse [22:51:30] <mru> it insists on a valid header following whatever you give it [22:51:40] <mru> or at least did last time I used it [22:52:28] <_av500_> dunoo [22:52:36] <_av500_> i wrote that adaptor code like 5ys ago [22:53:09] <mru> what I found was that feeding libmad single frames didn't work [22:53:19] <_av500_> yes, sounds familiar [22:58:08] <_av500_> [mp3 @ 0x851a910] Header missing, wtf? [22:58:44] <_av500_> im feeding it 2k, there IS a header inside [22:59:00] <_av500_> I am supposed to hunt for it myself? [22:59:05] <mru> aren't you supposed to feed it frames? [22:59:30] <mru> the CODEC_CAP flags should tell [22:59:30] <spaam> maybe you need to put a header in your header.... [22:59:47] <mru> a zaphod stream [23:00:08] <_av500_> mru: e.g. i have an AVI with 8k per audio chunk... [23:00:48] <mru> avi is disgusting [23:00:49] <_av500_> i am supposed to parse the bitstream my self? [23:01:01] <_av500_> mru: could be anything else as well [23:04:20] <_av500_> CODEC_CAP_PARSE_ONLY [23:05:57] * _av500_ ponders paying the libmad license out of his own pocket... [23:07:51] <CIA-63> ffmpeg: michael * r25266 /trunk/ (ffplay.c ffprobe.c cmdutils.c ffmpeg.c cmdutils.h): User application side of Codec specific parameters. [23:15:05] <CIA-63> libswscale: stefano * r32413 /trunk/libswscale/options.c: [23:15:05] <CIA-63> libswscale: Set valid default values for the srcw, srch, dstw, dsth options in the [23:15:05] <CIA-63> libswscale: scale context. Prevent pointless warnings when using [23:15:05] <CIA-63> libswscale: av_opt_set_defaults() for setting the default values, as in a pending [23:15:05] <CIA-63> libswscale: patch. [23:15:06] <CIA-63> libswscale: stefano * r32414 /trunk/libswscale/options.c: Set the default value of param0 and param1 to SWS_PARAM_DEFAULT. [23:15:07] <CIA-63> libswscale: stefano * r32415 /trunk/libswscale/utils.c: Set default values for the scale context in sws_alloc_context(). [23:33:24] <_av500_> wtf, lavc mp3 decoder needs lavf/mp3.c? [23:33:39] <mru> shouldn't [23:33:47] <_av500_> opps, no [23:33:51] <_av500_> its too late [23:34:49] <_av500_> ok, now it seems to work [23:35:14] <_av500_> its like libmad wrapper code, but i need to hunt for the sync myself... [23:35:15] <_av500_> gn

1 0

IRC log for 2010-09-28
by irc＠mansr.com 29 Sep '10

29 Sep '10

[00:09:02] <mchinen> do people on mac get "xargs: illegal option --d" error messages when running patcheck? [00:09:21] <mchinen> *illegal option -- d [00:11:05] <lu_zero> which os are you on? [00:27:35] <bcoudurier> mchinen, yes [00:28:41] <mchinen> bcoudurier: is this preventing some checks? [00:28:54] <mchinen> lu_zero: mac 10.5 [00:29:25] <mru> whoever wrote the script obviously show complete contempt of standards [00:30:37] <mru> or possibly whoever wrote macos [00:30:53] <mru> though they tend to follow posix pretty well, actually [00:31:53] <mru> standard xargs has no -d option [00:32:58] <mchinen> what does it do? [00:33:37] <mru> in gnu xargs it changes the record delimiter [00:34:14] <CIA-63> ffmpeg: bcoudurier * r25240 /trunk/libavformat/mov.c: In mov demuxer, check that nb_streams is valid before using it in read_dac3 [00:37:04] <lu_zero> ^^; [00:37:25] <lu_zero> nite [02:06:01] <CIA-63> ffmpeg: astrange * r25241 /trunk/ (ffplay.c cmdutils.c cmdutils.h): Extract timestamp correction code from ffplay.c to cmdutils.c [03:23:23] <bcoudurier> indeed the temperature today broke the record of LA [03:23:27] <bcoudurier> 113 high [03:34:44] <saintdev> that's your new onjoin?! [03:36:21] <j0sh> lol [03:46:13] <CIA-63> ffmpeg: astrange * r25242 /trunk/cmdutils.c: (log message trimmed) [03:46:13] <CIA-63> ffmpeg: All else being equal, prefer PTS over DTS in timestamp correction [03:46:13] <CIA-63> ffmpeg: Because DTS values aren't passed through decoders, they tend to be [03:46:13] <CIA-63> ffmpeg: inaccurate if decoder delay doesn't match what was expected by the encoder. [03:46:13] <CIA-63> ffmpeg: In particular this improves timestamps for H.264 without num_reorder_frames [03:46:14] <CIA-63> ffmpeg: set and with -strict 1, which causes DTS to be up to 16 frames ahead of the [03:46:15] <CIA-63> ffmpeg: picture. [03:48:54] <astrange> 4 paragraphs for 1 character commit... [04:07:28] <astrange> bcoudurier: https://roundup.ffmpeg.org/issue2251 know anything about this? [06:15:56] <KotH> salve [06:27:47] <benoit-> moin [06:28:17] <benoit-> KotH: are you interested in receiving complains from people about the website certificate? [06:28:30] <benoit-> (I wonder if we should create a list for that) [06:29:19] * _av500_ gives KotH a bunch of unspecific complaints [06:30:51] <KotH> benoit-: certificate? [06:31:03] * KotH complains to the big troll about _av500_ [06:31:25] <benoit-> KotH: ssl certificate [06:31:35] <KotH> hmm.. [06:31:49] <KotH> benoit-: send the complains to diego please. he handles the certificates [06:32:33] <benoit-> KotH: OK, I'll just send them to /dev/null then [06:32:48] <KotH> hmm? why /dev/null? [06:33:08] <benoit-> I don't think there is any plan having a 'signed by someone who is trusted' version of the certificate [06:33:25] <KotH> uhmm.. no [06:33:47] * KotH could get a x500 cert if he wanted to, but it's too much work for very little benefit [06:33:52] <benoit-> quoting the complaint: "[the website] produces a security certificate violation. I don't join websites that are insecure." [06:34:04] <KotH> well.... [06:34:20] <benoit-> which is fine by me, if you ask me [06:34:32] <KotH> benoit-: if you are in the mood, you can answer him that his security policy is flawed [06:34:44] * benoit- checks his mood [06:34:55] <saintdev> but someone could be eavesdropping on roundup comments! [06:34:59] <_av500_> sm ppl prefer certs signed by NSA... [06:35:09] <KotH> other than that... /dev/null is ok for such mails [06:35:11] <_av500_> err, verisign [06:35:52] <peloverde> some one at FOSDEM was doing free certs for OSS projects [06:35:57] <benoit-> KotH: almost related: do you know who receives mails to root(a)ffmpeg.org? [06:36:26] <KotH> root@mphq [06:36:36] <KotH> hmm.. maybe [06:36:46] <KotH> it could get rejected by natsuki too... [06:37:13] <mru> let's try [06:37:14] <benoit-> I'll try, we'll see [06:37:19] <saintdev> peloverde: <mru> if someone who knows aac were to work on it, how long before it would compete with faac in quality? compete with good encoers? [06:37:20] <saintdev> <mru> weeks, monts, years? [06:37:47] <saintdev> it being the aac encoder [06:38:25] <peloverde> faac probably a month, the good encoders 4-8 months [06:38:43] <saintdev> wow i guessed right, lol [06:38:47] <benoit-> KotH, mru: <root(a)ffmpeg.org>: Relay access denied (in reply to RCPT TO command) [06:38:52] <KotH> benoit-: juup [06:39:13] <KotH> benoit-: should these mails be handled? if yes, why? and how? [06:39:58] <benoit-> KotH: I think that yes, they should, because the domain name is valid :) [06:40:10] <mru> KotH: I think accepting @ffmpeg.org mail makes sense [06:40:47] <benoit-> mru: every devel is going to claim is @ffmpeg.org email address :) [06:40:52] <benoit-> ouch [06:40:59] <mru> I didn't say that [06:41:00] <benoit-> claim his [06:41:12] <mru> only that standard aliases should be accepted [06:41:13] <benoit-> mru: I know. I did [06:41:16] <mru> root, webmaster, etc [06:41:35] <saintdev> peloverde: i wasn't sure about good encoders. i was thinking about a year, but didn't state that :) [06:41:50] <Dark_Shikari> hmm. re the thread on legal, how much do you think getting 10-bit h264 decoding in ffmpeg would cost? [06:42:25] <Dark_Shikari> might be hard considering ffmpeg has no non-trivial >8-bit decoders [06:42:30] <Dark_Shikari> and assumes 8-bit everywhere [06:50:26] <bcoudurier> it's not that hard to deal with, I've had dnxhd decoding 10bits [06:51:00] <mru> Dark_Shikari: obviously all the asm would need rewriting [06:51:05] <mru> and much of the C code [06:51:06] <bcoudurier> astrange, there is a bug, the pts of the packet should not be overwriten [06:54:35] <Tjoppen> ooh, drama on the list [06:55:01] <astrange> -fflags +nofillin+noparse doesn't change it which should limit the code affecting it [06:55:02] <Dark_Shikari> mru: we're doing a lot of the asm in x264 [06:55:09] <astrange> (or i just typed the option wrong) [06:55:17] <Dark_Shikari> we can contribute deblocking, idct, and parts of the MC [06:55:20] <Dark_Shikari> and whatever intra pred we do [06:55:33] <Dark_Shikari> I suspect most of the C code can be kept the same [06:55:53] <Dark_Shikari> particularly if we define stride such that if our image is a uint8_t * [06:56:01] <Dark_Shikari> that stride = (number of pixels of stride)*2 [06:56:15] <Dark_Shikari> the other option is to template the decoder. [06:56:26] <Dark_Shikari> or, at least, the part of the decoder that accesses pixels. [07:04:42] <bcoudurier> that's strange I get pts 0 dts 0 for the first frame [07:27:18] <kshishkov> Dark_Shikari: we have some >8-bit image decoders, including JPEG-LS [07:27:53] <Dark_Shikari> yeah, but those avoid mpegvideo [07:27:59] <Dark_Shikari> but yeah, those might be good inspiration [07:31:43] * kshishkov wonders if "trivial" really means "not using mpegvideo stuff" [07:32:56] <Dark_Shikari> Basically, for video, yeah [07:32:57] <Dark_Shikari> lol [07:33:58] <Dark_Shikari> i.e. any sufficiently complex video decoder will eventually use mpegvideo [07:34:11] <bcoudurier> night guys [07:35:36] * kshishkov thinks that a good troll impulse to write complex decoder without mpegvideo - probably for Indeo [07:37:14] <Dark_Shikari> michael will reject [07:37:14] <Dark_Shikari> lol [07:37:50] * kshishkov looks at Indeo5 decoder - no mpegvideo so it's trivial [07:38:04] <mru> vp568 [07:38:11] <Dark_Shikari> even vp568 calls ff_emulated_edge_mc [07:38:15] <Dark_Shikari> an mpegvideo function [07:38:15] <mru> oh [07:38:26] <mru> isn't that function a bit messed up? [07:39:45] <Dark_Shikari> >mpegvideo [07:39:47] <Dark_Shikari> >messed up [07:39:51] <Dark_Shikari> department of redundancy department [07:40:06] <kshishkov> careful, you may awaken elenril [07:40:20] <mru> is there a trope for that? [07:40:43] <kshishkov> IIRC it's named exactly like what DS just said [07:41:06] <Dark_Shikari> http://tvtropes.org/pmwiki/pmwiki.php/Main/DepartmentOfRedundancyDepartment [07:41:19] <Dark_Shikari> I love the quote [07:41:19] <Dark_Shikari> "The offensive lineman are the biggest guys on the field. They're bigger than everyone else, that's why they're the biggest guys on the field." [07:41:23] <Dark_Shikari> —John Madden [07:42:17] * kshishkov is pretty sure that the next blockbuster should feature life of Captain Obvious [07:43:32] <mru> Dark_Shikari: hmm, that page links to itself [07:43:46] <Dark_Shikari> mru: http://tvtropes.org/pmwiki/pmwiki.php/Main/ShapedLikeItself ?\ [07:44:11] <mru> no, the DoRD [07:44:25] <mru> "Compare ... Department Of Redundancy Department." [07:44:27] <Dark_Shikari> well yes, but I was making a reference to that one intentionally [07:44:27] <Dark_Shikari> =p [07:44:28] <kshishkov> mru: isn't that just natural? [07:44:36] <mru> of course [07:59:39] <Tjoppen> getting crashes in the h264 decoder when I seek. I suspect it has to do with the recent reference frame thing [07:59:59] <cartman> Tjoppen: backtrace or it didn't happen [08:00:04] <cartman> also a sample too [08:01:51] <Dark_Shikari> Tjoppen: yeah, in theory it should only affect seeking to non-keyframes [08:01:54] <Dark_Shikari> which you shouldn't be doing [08:01:58] <Dark_Shikari> And yeah, backtrace [08:02:06] <Dark_Shikari> and feel free to revert it [08:02:25] <mru> Dark_Shikari: the decoder should never crash [08:03:00] <Tjoppen> I'm seeking in mpegts, and that demuxer doesn't seem to seek to keyframes [08:03:02] <av500> mru: hey, thats what I keep tellin the indians... [08:03:31] <Dark_Shikari> mru: it shouldn't crash either way [08:03:42] <Dark_Shikari> and yes I'd like a backtrace [08:03:50] <Dark_Shikari> my point is that patch shouldn't _affect_ anything unless seeking to non-keyframes. [08:03:56] <kshishkov> av500: if it crashes then your belief in Brahma is not strong enough [08:04:39] <Tjoppen> I'll upload a sample. just need to see if it still happens when cut down to size [08:05:45] <Dark_Shikari> I want a backtrace [08:06:17] <cartman> mooooaaaaar [08:06:24] <Tjoppen> :) [08:06:43] * cartman fixes yet another build breakage in WebKit [08:06:51] <av500> kshishkov: my belief in Brahme is zero [08:07:19] <kshishkov> av500: that's why your karma prevents you from having perfect Indian decoders [08:07:41] <av500> kshishkov: they are perfectly indian decodes [08:07:44] <av500> +r [08:08:24] <kshishkov> "perfect (yet) Indian" and "perfectly Indian" differ a bit [08:08:48] <av500> subtly eh? :) [08:09:14] * kshishkov lived in European-style India so he's sure Indian code quality is the best [08:09:49] <av500> kshishkov: usually we got asked "what is the use case and what content do you need to play" [08:09:59] <av500> we always answered "all that is out there" [08:10:42] <av500> and "btw, ffmpeg decodes it correctly" [08:10:58] * kshishkov is glad FFmpeg was used for trolling [08:11:12] <Tjoppen> making a clean compile against master. will take a few mins [08:25:43] <lu_zero> good morning [08:27:23] <kshishkov> buon giorno [08:27:35] <lu_zero> god morgon kshishkov [08:28:30] <Tjoppen> I hope an ffplay trace is ok. ffmpge -ss 10 and transcoding video didn't trigger it [08:28:41] <spaam> lu_zero: hur är det idag? :) [08:30:43] <Tjoppen> roundup is down? [08:31:14] <mru> rounddown? [08:31:17] <lu_zero> Tjoppen: uhm? [08:31:29] <Tjoppen> I'll pastebin the trace for the time being [08:31:58] <Tjoppen> there we go. just really slow [08:32:02] <lu_zero> seems working [08:32:10] <lu_zero> and fast enough [08:32:40] <Tjoppen> 10-20 sec response time isn't my idea of fast [08:32:49] <lu_zero> Tjoppen: uhm? [08:33:01] <mru> welcome to the wonderful world of python [08:33:36] <lu_zero> mru: python has nothing with roundup being stupid. [08:33:48] <mru> there are many stupid python coders [08:33:53] <mru> apparently some of them wrote roundup [08:33:59] <elenril> s/python// [08:33:59] <lu_zero> or mysql being stupid [08:34:12] * elenril yawns [08:34:46] <lu_zero> or roundup having .... [08:34:55] <lu_zero> 1.7GB of trash inside it. [08:36:21] <lu_zero> that reminds me that this beast should be migrated [08:36:56] <lu_zero> and maybe I should figure out why it is taking this much cpu [08:39:30] <lu_zero> apache is strange... [08:39:57] <mru> tell me [08:40:14] <mru> guess why we switched mphq to lighttpd [08:40:16] * kshishkov wonders what ViewVC formerly installed on MPHQ was written with? [08:40:22] <mru> python [08:41:19] <kshishkov> have you found where it improted cpueater and diskdestroyer modules? [08:41:41] <Tjoppen> Dark_Shikari: https://roundup.ffmpeg.org/issue2253 [08:42:24] <Dark_Shikari> duplicate [08:42:26] <Dark_Shikari> see issue 2250 [08:42:52] <Dark_Shikari> Oh. I think I know what the bug is already. [08:42:53] <lu_zero> kshishkov: I could point you to rt if you wish [08:44:01] * lu_zero will not write yet another bug tracker.... [08:44:37] <mru> rt is a bit weird [08:44:42] <mru> they all are [08:45:28] <cartman> try debbugs [08:45:34] <cartman> and see whats really weird [08:46:24] <mru> another contribution from the department of redundancy department [08:46:27] <Dark_Shikari> Tjoppen: can you test a patch [08:47:06] <Dark_Shikari> http://pastebin.com/5W1zE33p [08:47:42] <lu_zero> bugzilla isn't bad [08:47:45] <lu_zero> (now) [08:48:06] <mru> it has far too many weird fields [08:48:11] <Tjoppen> Dark_Shikari: ok [08:48:27] <lu_zero> now you can remove and add your ones [08:50:13] <Tjoppen> Dark_Shikari: nope. still crashes [08:50:32] <Tjoppen> still in av_image_copy() [08:50:59] <mru> hmm, gcc as 20 open bugs matching "ffmpeg" [08:51:39] <lu_zero> _just_ 20? [08:51:59] <mru> those are the _open_ ones [08:52:26] <cartman> Trunk status -- stage 1 || Still 114 regressions in 4.3, 115 in 4.4, 118 in 4.5 and 177 in 4.6 [08:52:31] <kshishkov> were the rest of them closed with resolutions "invalid" or "wontfix"? [08:52:32] <cartman> don't hold your breathe [08:52:52] <mru> 96 total [08:53:08] <Dark_Shikari> Tjoppen: http://pastebin.com/As8AhLds [08:54:19] <Tjoppen> k [08:54:43] <Tjoppen> nope. crash [08:55:11] <Dark_Shikari> WTF? [08:55:12] <Tjoppen> but: only in decode_slice_header [08:55:19] <Dark_Shikari> er... [08:55:26] <Dark_Shikari> wait. it's not even crashing in the same place? [08:55:27] <Dark_Shikari> or what [08:56:05] <Tjoppen> indeed [08:56:11] <Dark_Shikari> give me the backtrace [08:56:12] <Dark_Shikari> not psychic here [08:57:10] <Tjoppen> http://ffmpeg.pastebin.com/amZja7BH [08:57:47] <twnqx> hm [08:58:08] <Dark_Shikari> oh duh I'm stupid [08:58:40] <Dark_Shikari> http://pastebin.com/grCKVXc5 [08:58:41] <twnqx> so this .pss format is a variant of mpeg-ps with WAV inside [08:59:40] <twnqx> i have a windows tool to demux it... but i'd like something else... like, ffmpeg :P [09:01:30] <pJok> twnqx, write your own demuxer? ;) [09:01:46] <twnqx> if i had a format description i would [09:01:57] <twnqx> likely it's just a small change to the .ps demuxer [09:01:58] <Tjoppen> Dark_Shikari: works [09:02:23] <Tjoppen> I harassed ffplay pretty good with seeking forward and backward. apart from the obvious crappy image, it handled it fine [09:02:52] <mru> twnqx: mpegps with wav inside? wtf? [09:03:20] <twnqx> mru: this is all i found so far: http://www.zophar.net/utilities/ps2util/pss-plex.html [09:04:44] <kshishkov> probably it's PCM or even MP3, WAV is just container here to store audio separately [09:05:49] <twnqx> PCM, he's explicitly talking about uncompressed audio streams [09:05:58] <twnqx> (optionally adpcm it seems) [09:06:23] <Dark_Shikari> Tjoppen: applied [09:06:30] <twnqx> ffmpeg at the moment only detects the video stream [09:07:04] <mru> pcm containers are usually easy to RE [09:07:08] <mru> do you have a sample? [09:07:12] <twnqx> yeah [09:07:18] <CIA-63> ffmpeg: darkshikari * r25243 /trunk/libavcodec/h264.c: [09:07:18] <CIA-63> ffmpeg: Try to fix crashes introduced by r25218 [09:07:18] <CIA-63> ffmpeg: r25218 made assumptions about the existence of past reference frames that [09:07:18] <CIA-63> ffmpeg: weren't necessarily true. [09:07:33] <twnqx> but it's somewhere inside the ps stream, so i guess it's just unsupported streams [09:07:40] <mru> yeah [09:07:56] <mru> but they must be identified somehow [09:07:58] <twnqx> apparently even multiple streams (multiaudio) are possible [09:08:11] <Tjoppen> Dark_Shikari: nice [09:08:12] <twnqx> i'll just debug the ps demuxer in the evening [09:08:13] <twnqx> :) [09:08:34] <mru> I'd rather use a ps analyser and hex viewer [09:09:52] <kshishkov> mru: I thought ps analyzer was you [09:15:21] <twnqx> mpegps is libavformat/mpeg.c, right? [09:19:10] <twnqx> make: *** No rule to make target `libavcodec/x86/dsputil_h264_template_mmx.c', needed by `libavcodec/x86/dsputil_mmx.o'. Stop. [09:19:13] <twnqx> hm [09:19:20] * twnqx distcleans [09:19:56] <mru> plain clean is enough [09:32:14] <twnqx> es_type 0 startcode ff [09:32:16] <twnqx> ok... [09:33:58] <mru> where's the sample? [09:34:19] <twnqx> what's the ftp again? [09:34:46] <mru> upload.ffmpeg.org [09:36:43] <twnqx> 80MB file - cut or do you want all? [09:37:02] <mru> enough to contain a few frames of that audio is enough [09:37:45] <twnqx> incoming/pss/pcm-in-mpeg-ps.pss [09:38:15] <KotH> twnqx: dont forget the .txt file :) [10:02:41] <twnqx> oh yeah... [10:06:38] <twnqx> thanks for the reminder, koth :) [10:06:46] <twnqx> mru: the large file can be deleted if you bother [10:12:28] <twnqx> mru: should i try to grab a multilingual sample as well? [10:41:30] <twnqx> mru: found a starting point to .pss demuxing - Arktool sourcecode [10:42:25] <mru> seems to use private_stream_1 [10:43:17] <mru> look at offset 0x8000 in the file [10:46:01] <twnqx> const u8 PssVgsAccess::S_FIRST_HEADER[4] = { 0x00, 0x00, 0x01, 0xBA }; [10:46:04] <twnqx> that matches. [10:46:16] <mru> that's the pack header [10:46:27] <mru> the payload starts at 0x8021 [10:47:15] <twnqx> from what i grapsed by skimming through this source it's something the author alls a VGS file inside [10:48:17] <twnqx> oh well. gonna have to play with this a bit :) [10:51:09] <mru> some kind of header at 0x8025 [10:51:14] <mru> 4-byte tag [10:51:21] <mru> 4-byte size (LE) [10:51:33] <mru> some 32-bit number [10:51:42] <mru> 32-bit LE sample rate [10:52:11] <mru> another 32-bit number (channels?) [10:52:16] <mru> value 2 [10:52:20] <twnqx> yeah, it's stereo [10:52:32] <mru> the first number might be a format tag [10:52:34] <mru> 1 = pcm? [10:52:45] <mru> then ff padding [10:52:49] <twnqx> it supports variants (pcm, adpcm) [10:53:07] <mru> 0x8045 another packet header [10:53:12] <mru> tag SSbd [10:54:26] <mru> meaning of 00 0c 52 01 not obvious [10:54:32] <mru> pcm samples follow [10:55:04] <mru> s16le by the looks of it [10:55:13] <twnqx> at least in this case, yes [10:55:36] <mru> do you have an adpcm sample? [10:55:55] <twnqx> not yet, guess i'd have to download one of the mentioned ps2 isos [10:55:56] <mru> that first 32-bit value probably indicates the sample format [10:57:12] <mru> see, pcm formats are easy to figure out [11:10:20] <twnqx> #define PACK_START_CODE ((unsigned int)0x000001ba) <- does that actually work on BE machines? [11:10:36] <mru> depends on how you read the file [11:10:41] <mru> and that cast is nonsense [11:10:55] <twnqx> it's from mpeg.h in ffmpeg :P [11:11:01] <mru> nonsense nonetheless [11:11:16] <mru> ffmpeg works on BE machines btw [11:11:30] <twnqx> interesting [11:11:46] <av500> and ME? [11:11:54] <mru> no [11:12:09] <twnqx> code = (code<<8) + p->buf[i]; <- ok, it build the code it compares with byte by byte [12:04:14] <Dark_Shikari> holy fucking retards, my intelligence is being destroyed [12:04:18] <Dark_Shikari> someone emailed me for ffmpeg help [12:04:21] <Dark_Shikari> I told them two things [12:04:29] <Dark_Shikari> qt-faststart input.mp4 output.mp4 [12:04:35] <Dark_Shikari> s/-b 3000000/-crf 22/ [12:04:36] <mru> intellectual osmosis? [12:04:45] <Dark_Shikari> They then INSERTED these LITERALLY into their commandline [12:04:58] <Dark_Shikari> -vcodec libx264 s/-b 3000000/-crf 22/ ... [12:05:05] <mru> lol [12:05:12] <lu_zero> wow [12:05:19] <mru> like the guy who ran configure --usual-options [12:05:23] <Dark_Shikari> LOL [12:05:23] <mru> literally [12:05:58] <lu_zero> mru: a patch that actually replies to --usual-options with a message would be too much? [12:06:04] <Dark_Shikari> Hah. [12:06:32] <mru> sorry dave, I can't do that [12:06:47] <lu_zero> mru: that would be fit [12:07:13] <jannau> wtf micheal [12:07:30] <jannau> "Things should be consistent, either everyone should be listed with name or noone" [12:08:02] <kshishkov> sounds like communism [12:10:59] <mru> wtf indeed [12:11:13] <mru> and of course he didn't say how he wants his name [12:11:42] <kshishkov> fried and with mustard [12:11:48] <microchip_> signed, M. Troll [12:11:59] <lu_zero> kshishkov: with or w/out cheese? [12:12:28] <kshishkov> lu_zero: probably without [12:13:34] <jannau> it'll be hard to make sure that nobody commits with full name and email after the full conversion [12:14:03] <lu_zero> uhm? [12:14:13] <lu_zero> I'm missing the start [12:14:21] <jannau> mru: I would say he doesn't care [12:14:41] <mru> I promise I will [12:15:01] <kshishkov> lu_zero: in future official ffmpeg git repo [12:15:37] <jannau> lu_zero: if we decide not to use full names + email for consistancy it will be doomed when all are using git to push to the central repo [12:16:47] <benoit-> "open source people don't have any money so they don't have girlfriends and can't go to nice restaurants" [12:17:16] <benoit-> I must admit I laughed a lot on this one [12:17:32] <mru> desperate troll is desperate [12:18:14] <KotH> mru: correction: this guy is that stupid [12:18:32] <Dark_Shikari> mru: aha. I see what happened here with the retardation [12:18:49] <Dark_Shikari> the CEO had emailed me, and attempted to implement my instructions himself rather than, you know, give them to the guy who's actually coding [12:19:02] <Dark_Shikari> as a "quick fix" [12:19:05] <mru> lol [12:20:48] <lu_zero> oh... [12:22:16] <thresh> the real lol if it made to a product [12:22:46] <av500> for me "--usual-options" would just be ignored [12:23:42] <mru> sometimes with such people I'm tempted to tell them rm -rf / [12:23:55] <mru> possibly slightly obfuscated [12:24:03] <kshishkov> it may fail for them too [12:24:35] <kshishkov> "leave a Russian in an empty room with two cannonball and he'll manage to break one and lose another" [12:25:01] <av500> kshishkov: impossible, one would have been stolen before already... [12:25:34] <kshishkov> av500: what makes you say that? [12:45:50] <av500> err, http://ucnv.github.com/aviglitch/ [12:47:01] <cartman> how useful, reminds me of old times [12:47:27] <thresh> av500: so the guy actually reinvented zzuf? [12:47:36] <kshishkov> zzuf is more realistic [12:50:20] <av500> i dont thing the purpose of this one is the same of zzuf [12:50:24] <av500> think :) [12:50:39] <av500> this one is more about being artistis [12:50:41] <av500> this one is more about being artistic [12:50:48] <kshishkov> yes, it's merely a toy while zzuf is a serious diagnostic tool [12:52:02] <cartman> av500: say that again? [12:53:10] <kshishkov> av500: and you're gravely wrong. Had it been artistic, it'd corrupt MOV instead. [12:59:58] <thresh> :)) [13:03:44] <twnqx> mru: are you maintaining the mpeg-ps demultiplexer? [13:03:52] <twnqx> there's so much stuff that doesn't make sense to me... [13:04:02] <kshishkov> then learn it [13:05:02] <mru> mpegps is a very simple format [13:05:13] <twnqx> i meant the code, not the format [13:05:23] <mru> if you ignore the never-seen-in-the-wild program stream directory [13:05:33] <mru> yes, mpegps has an optional index [13:05:54] <kshishkov> like NUT :) [13:06:00] <mru> it's a bit weird [13:06:02] <mru> like nut [13:06:58] <twnqx> if (startcode == PRIVATE_STREAM_1 && !m->psm_es_type[startcode & 0xff]) { [13:07:08] <twnqx> i don't quite get the second part [13:07:21] <twnqx> startcode & 0xff would be const, no? [13:07:47] <kshishkov> yes, but it'd be less obvious [13:07:47] <twnqx> since startcode == const has been checked first [13:08:36] <mru> there's a lot in that demuxer that's less obvious [13:10:12] <lu_zero> btw [13:10:39] <lu_zero> by default the index is not written by the ffmpeg muxer, isn't it? [13:11:07] <mru> I have never seen anything read or write a PSD [13:12:46] <twnqx> hm [13:16:05] <twnqx> right, so the code doesn't handle my stream types nicely and kills the "private stream 1" startcode and replaces it with 0xff stream id - i wonder if i should keep it like that or make it keep "private stream 1" type [13:17:21] <twnqx> because the private stream is not listed in the program stream map. [13:17:31] <CIA-63> ffmpeg: stefano * r25244 /trunk/ (5 files in 2 dirs): [13:17:31] <CIA-63> ffmpeg: Add the drawbox filter from the soc libavfilter repo. [13:17:31] <CIA-63> ffmpeg: Pedagogically useful. [13:17:38] <twnqx> (or there just is no map) [13:19:11] <twnqx> can i undo get_byte() somehow? [13:45:01] <CIA-63> ffmpeg: stefano * r25245 /trunk/configure: Group togheter filter dependency specifications. [14:21:33] <jannau> bah, git cherry-pick can't pick empty commits [14:22:40] <mru> why would you want an empty commit? [14:24:32] <lu_zero> and how you managed to push an empty commit? [14:24:38] <av500> they have the least bikeshedding... [14:24:43] <twnqx> mru: why is } else if (startcode == 0x1bd) { used and not } else if (startcode == PRIVATE_STREAM_1) {? [14:24:55] <mru> twnqx: I didn't write that code [14:25:00] <twnqx> ah ok [14:25:11] <jannau> the script was stopping due to 'set -e' [14:25:12] <mru> av500: even empty bikesheds have a colour [14:25:28] <lu_zero> interesting... av_interleave_write_frame needs an avcodec_encode_foo before =_= [14:26:09] * lu_zero wanted to pass directly AVPackets but that confuses some of the inner logic... [14:26:33] <twnqx> mru: so if i'd feel the urge to totally refactor some code for brokenness... [14:26:38] <mru> lu_zero: it's lavf... [14:26:41] <jannau> git svn created the empty commit. it was a "dos2unix" commit [14:26:49] <mru> twnqx: it's not me you should be talking to [14:27:04] <twnqx> like being unable to see dvd audio streams if there's no program stream map [14:27:08] <mru> jannau: dos was already unix? [14:27:19] <twnqx> who would i ask? just propose the patch on the mailing list? [14:27:46] <kshishkov> probably it was Diego removing \015 from files [14:27:53] <mru> uhm, dvd audio works fine w/o psm [14:28:05] <twnqx> then there's redundant code. [14:28:21] <twnqx> because no psm => different stream id then with psm. [14:28:23] <jannau> mru: seems so, I guess git converted it already during the import [14:28:39] <jannau> kshishkov: it was Michael [14:30:45] <lu_zero> mru: we have already a troll going with swscale, once that reach the end I'll start bitch with lavf [14:32:26] <Tjoppen> lavf being tightly coupled with lavc is concern for me (and probably others) [14:32:31] <Tjoppen> +a [14:32:51] <lu_zero> Tjoppen: it isn't tightly coupled [14:33:10] <mru> in one direction it is [14:33:16] <mru> lavf is unusable without lavc [14:33:23] <mru> even if you don't intend to use the lavc codecs [14:33:27] <Tjoppen> well.. try to mux packets from a non-lavc encoder [14:33:48] <lu_zero> just you have to set coded_frame [14:33:56] <lu_zero> (so I understood) [14:34:12] <Tjoppen> you have to set a lot of poorly documented stuff in AVStream [14:34:30] <mru> avstream isn't the problem [14:34:35] <mru> avstream->codec is [14:35:20] <lu_zero> and avstream->codec->coded_frame... [14:35:27] <Tjoppen> right [14:46:51] <twnqx> gah this code is too ugly to work with [14:47:02] <twnqx> :( [14:48:13] <mru> that's what I said too [14:48:59] <twnqx> what are the procedures for refactoring? [14:49:17] <av500> 1) refactor [14:49:19] <av500> 2) submit [14:49:25] <mru> 3 goto 1 [14:49:35] <av500> 4) profit (unreached) [14:49:37] <twnqx> i meant for submitting the patches for review. [14:50:48] <CIA-63> ffmpeg: stefano * r25246 /trunk/cmdutils.h: [14:50:48] <CIA-63> ffmpeg: Make new doxy follows the agreed upon style and grammatical [14:50:48] <CIA-63> ffmpeg: conventions, for consistency with the rest of the documentation. [14:50:52] <KotH> send them to -devel and let michael take them apart :) [14:51:18] <KotH> wtf? gramatical conventions for comments? [14:51:34] <KotH> isnt english a strict enough standard already? [14:52:10] <spaam> nope. [14:53:56] <KotH> ok, then i propose that we switch to lojban as documentation language [14:54:26] <twnqx> by the way, how do you guys make those "fix indention after code change" patches? [14:55:08] <astrange> git commit -a; fix indentation; git commit -a [14:56:57] <twnqx> so code, unindent, commit, reindent? [14:57:05] <twnqx> i mean, normal editors fix the indentation as you go [14:57:44] <jannau> define normal [14:57:44] <lu_zero> twnqx: sort of [14:57:44] <astrange> you have an editor that changes indentation of existing lines automatically? [14:57:55] <twnqx> if i press ; or enter, yes [14:57:57] <KotH> no, normal editors do not touch indentation unless you tell it to do so [14:58:08] <lu_zero> avcodec_encode_audio is ... fun.. [14:59:58] <CIA-63> ffmpeg: stefano * r25247 /trunk/libavfilter/vf_scale.c: Cosmetics: apply nits. [14:59:59] <CIA-63> ffmpeg: stefano * r25248 /trunk/libavfilter/vf_scale.c: [14:59:59] <CIA-63> ffmpeg: Make init() return sensible error code rather than -1 in case of [14:59:59] <CIA-63> ffmpeg: invalid values. [14:59:59] <jannau> does anyone understand what michael wants? [15:00:21] <Dark_Shikari> jannau: sorry, that's something beyond the means of any human [15:00:50] <cartman> jannau: virgin blood [15:02:57] <Tjoppen> bah, files with duplicate time stamps [15:03:08] <astrange> what kind of files? [15:03:12] <Tjoppen> mpegts again [15:03:25] <av500> cartman: that would be easy [15:03:26] <Tjoppen> one of the subtitle streams [15:03:38] <cartman> av500: how come? :P [15:03:59] <mru> cartman: stab him [15:04:03] <Tjoppen> I haxed compute_pkt_fields2() to ignore it atm. hopefully it doesn't break too much [15:04:06] <cartman> mru is fast [15:04:12] <cartman> ;> [15:04:53] <astrange> http://pastebin.com/YpmmsSfq i considered something like this to remove next_pts from ffmpeg.c [15:05:12] <astrange> but it doesn't fix the non-monotone timestamp errors from inside lavf, yes [15:07:00] <Tjoppen> the file is from some kind of hardware. the interesting thing is that it's only the second dvbsub stream that's broken. the other three are fine (so far) [15:07:17] <twnqx> are hex values to be written with lowercase a-f or uppercase - or is there no policy? [15:07:33] * mru prefers lowercase [15:07:51] <spaam> use both [15:08:03] <mru> camecase constants [15:08:06] <mru> camel [15:08:26] <mru> 0xCafeBabe [15:08:42] <twnqx> #define o0o0o [15:08:57] <astrange> (that patch is also one reason why the pts correction stuff didn't go in a library - the interface might change) [15:09:20] <Tjoppen> one of my coworkers had fun with the face that java accepts unicode for pretty much all names [15:09:35] <Tjoppen> int A = 5, A = 3; System.out.println(A+A); [15:10:06] <Tjoppen> with one of the A's as a superficially identical but disctinct code point [15:10:24] <av500> Tjoppen: that one is easy, a clever compiler assignd 4 to A, so the output is 8 :) [15:10:24] <mru> try a non-breaking space for fun [15:10:44] <mru> av500: int A=26, A=16 [15:10:46] <mru> 26 [15:10:51] <Tjoppen> mru: how about non-breaking space and dash? int A - A = 2; [15:11:01] <kshishkov> yes, though strategically placed Cyrillic 'с' prevented compiling of sample code for many students on our Java classes [15:11:27] <mru> is there a unicode character that looks like an equals sign? [15:11:39] <kshishkov> yes [15:11:43] <kshishkov> pseudographics [15:11:43] <merbzt> mru: yes = [15:11:46] <Tjoppen> there has to be. after all, there's a snowman [15:12:29] <kshishkov> and basilisk stare [15:12:37] <mru> right [15:12:48] <mru> the compiler dies if it sees it [15:13:25] <kshishkov> nope, it's for real (don't remember in which XKCD it was referenced) [15:14:12] <mru> http://xkcd.com/380/ [15:14:12] <av500> 380 [15:14:35] <kshishkov> av500: do you read alt texts for XKCD strips now? [15:14:43] <av500> read what? :) [15:15:05] * kshishkov feared to get only the first word as question [15:16:22] <av500> fear? [15:17:39] <kshishkov> no, I feared you just simply refuse to read nowadays [15:34:58] <CIA-63> ffmpeg: stefano * r25249 /trunk/doc/APIchanges: Add APIchanges entry for lsws change of r32368. [15:40:48] <twnqx> array out of bounds on read should be fixed in ffmpeg if found, right? [15:41:08] <mru> yes [15:41:22] <twnqx> *sigh* this mpeg-ps code is bad. [15:42:03] <av500> mru: btw, your mkv code lack(ed) header compression. one can save 1 byte for frame :) [15:42:11] <av500> per [15:42:53] <kierank> av500: <tony the tiger> greaaaat!! [15:42:55] <mru> my mkv code? [15:42:58] <twnqx> if((*p&0xC0) == 0x40 && p+2 < end) p+=2; <- what would be the right formatting? [15:42:58] <mru> it's a demuxer [15:43:02] <mru> can't save anything [15:44:06] <av500> I have an mkv that uses header compression to not store one 0 byte at the start of each h264 frame... [15:44:15] <av500> huge savings! [15:44:45] <Dark_Shikari> mkv header compression also breaks every stb out there [15:44:50] <Dark_Shikari> gg [15:45:05] <av500> Dark_Shikari: my users tell me a lot anime uses that [15:45:07] <kierank> then the stb should have read the mkv spec properly [15:45:11] <av500> a lot of [15:45:25] <Dark_Shikari> av500: that's just because mkvmerge started using it by default a few versions ago [15:45:57] * lu_zero found his problem with avformat [15:45:59] <av500> hmm, wouldnt that mean that it has to read the whole stream once? [15:46:01] * lu_zero is an idiot [15:46:19] <av500> mru: 44! [15:46:26] <lu_zero> guess what happens when you set just the pts and stay completely oblivious of dts... [15:46:42] <mru> av500: is that 26+26 with compression? [15:46:49] <av500> :) [15:47:00] <av500> but close [15:47:08] <av500> thx for 43, I will use that a lot [15:47:27] <kshishkov> av500: your users watch anime? I thought your products are not... designed like what they expect [15:47:30] <Dark_Shikari> don't tell te mkv people that there are slice headers in each frame too [15:47:39] <Dark_Shikari> they'll find a way to compress those [15:47:54] <av500> and i thought h264 was somewhat compressed by itself :) [15:48:47] <mru> av500: no need to scan whole file, prefixing a zero never does any harm [15:49:11] <av500> except to add ony byte per frame, thats what I call compression... [15:49:20] <mru> of course then we have a lossy container [15:49:26] <mru> and that's a scary thought [15:49:51] <av500> nothing lost, just added [15:49:58] <av500> it adss value :) [15:50:00] <av500> adds [15:50:11] <kshishkov> mru: lossy container is best read with leacky buckets from HRD! [15:50:19] <kshishkov> *leaky [16:12:42] <twnqx> hm [16:13:41] <twnqx> damn, i still have the pending "do not crash my ffmpeg on broken files patch"... [16:29:14] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/kzXxdjCh please review (not bit-exact yet, but it should be approximately correct) [16:29:29] <BBB> I'll do a sse2 version later [16:49:09] <twnqx> <astrange> git commit -a; fix indentation; git commit -a <-- how do i do that with svn? [16:50:35] <Tjoppen> ehm.. don't touch the indentation of existing code when you write it, then fix it up when you're commited the OK'd stuff? [16:50:44] <twnqx> i *can* not commit stuff [16:50:59] <twnqx> since every single single patch i want to add goes to ML for review [16:51:00] <jannau> quilt [16:51:01] <Tjoppen> oh [16:51:14] <twnqx> and maybe a few weeks later is committed. [16:51:26] <jannau> or use one of the git mirrors [16:51:36] <Tjoppen> well, you still have post stuff on the list even if you have write access [16:51:56] <Tjoppen> or git-svn [16:52:25] <Tjoppen> takes half an hour or something to set up though, since it grabs every single revision [16:52:50] <kierank> yeah git-svn takes ages [16:53:11] <Tjoppen> whenever I have to use svn I find myself missing being able to create local branches and git-stash [16:53:23] <Tjoppen> ever do useful [16:53:26] <Tjoppen> `so [16:53:47] <twnqx> whenever i use git i miss the simplicity of svn :X [16:54:10] <mru> whenever I use svn I'm baffled at how primitive it is [16:55:24] <twnqx> yes, those two go hand in hand [16:56:15] <Tjoppen> also, rebase -i is awesome [16:56:23] <mru> can't do that in svn [16:56:29] <twnqx> can't do many things in svn [16:56:39] <mru> so all those things are simpler in git [16:56:49] <twnqx> yes. versioning, on the other hand, is not [16:56:54] <mru> using git _exactly_ like you'd use svn is not easy [16:57:00] <twnqx> because you only get random numbers that tell you... nothign [16:57:11] <mru> because how svn forces you to work is not how most people actually want to work [16:57:28] <twnqx> and something as simple as "svn up" fails in git with locally commit patches [16:57:40] <mru> git pull --rebase [16:57:43] <Tjoppen> it fails even more with svn [16:57:49] <mru> svn destroys your work [16:57:53] <twnqx> doesn't here [16:58:11] <twnqx> i *still* have the never committed "don't crash on ogm" patch in here... from several months back [16:58:40] <twnqx> the interactive merge feature from git is nice, though [16:59:21] <Tjoppen> I keep all such little fixes as local branches until they're OK'd (or I bother mailing them in) [16:59:36] <twnqx> yeah [16:59:40] <twnqx> it's just annoying me atm [16:59:46] <twnqx> the there a realtime git mirror? [17:00:02] <twnqx> that's always up tp the latest svn, as soon as the commit pops up here? [17:00:27] <mru> git.ffmpeg.org [17:00:42] <mru> and now jannau's tree with proper swscale [17:01:19] <twnqx> good [17:01:31] <Tjoppen> yes, that looks nice [17:01:32] <twnqx> i'll switch to that before working on the mpegps code then [17:01:49] <twnqx> so if you have a bunch of like 20 patches [17:02:15] <mru> git send-email rocks [17:02:19] <twnqx> and then you're asked to edit something in 15 revisions back - can you do that and then forward the change through all newer versions? [17:02:32] <mru> rebase -i [17:02:43] <twnqx> powerful. [17:02:58] <mru> powerful, useful, wonderful [17:03:01] * twnqx needs to learn more git [17:03:03] <Tjoppen> you can even reorder and drop changesets [17:03:11] <mru> and merge [17:03:11] <Tjoppen> and squash of course [17:03:12] <mru> and edit [17:03:34] <twnqx> and bisect, best feature :X [17:03:42] <Tjoppen> yes. magic [17:04:26] <twnqx> too bad if you only code once in a blue moon you forget all the commands :( [17:08:39] <twnqx> hm [17:08:39] <twnqx> bad idea to clone here on 3.5G :S [17:11:50] <jannau> bisecting is only useful with integrated swscale at least when it involves more than a couple of changes [17:13:02] <jannau> twnqx: my tree is only 50M shouldn't be too bad over 3.5G [17:14:44] <mru> jannau: bisecting with separate swscale works as long as there were no api changes in swscale in the interval [17:14:50] <twnqx> i'm cloning http://git.ffmpeg.org/ffmpeg [17:25:20] <ubitux> git add -p is a must-know too [17:26:44] <mru> I usually prefer git gui for such tasks [17:26:52] <mru> better overview [17:27:01] <mru> unless I'm on a slow link of course [17:57:47] <j0sh> lu_zero: did you ever get ffrtmp hooked up? [18:45:17] <bcoudurier> hi guys [18:46:14] <benoit-> salut Baptiste [18:46:26] <bcoudurier> hey benoit- la forme ? [18:49:26] <benoit-> bcoudurier: yep yep... ça roule. still on the west side ? [18:49:44] <bcoudurier> west coast yeah [18:51:35] <mru> why does michael insist on relying on random, undocumented gcc behaviour? [18:54:27] * cartman adds -fconsistency [18:54:45] * mru raises with -mrandom [18:55:52] <benoit-> well, nite guys... time to go ! [19:01:41] <Compn> mru : well, have you seen the bugs he reported to gcc ? [19:02:02] <Compn> some were marked invalid or wontfix [19:02:33] <mru> his definition of bug is a little odd [19:02:49] <mru> he calls a bug whatever doesn't behave the way he'd like it [19:02:56] <mru> whatever the standard says [19:03:19] <mru> now I'm talking about gcc doing something he wants by pure chance [19:03:24] <mru> i.e. the opposite [19:12:06] <iive> you know, it won't hurt if you explain the context of your comments. [19:15:47] <BBB> I know the context :-p [19:15:49] <Compn> context? we dont need no stinking context [19:15:55] <BBB> it's funny [19:15:58] <BBB> anyway [19:16:17] <Compn> iive : mostly mru comes on irc to complain about michael's posts on the mailing list [19:16:32] <Compn> so i think we are talking about some recent posts on ffmpeg-devel ... [19:17:01] <Compn> and i guess michael doesnt like it, since hed rather reply on the list [19:17:13] <Compn> but maybe mru wouldnt want to complain on the list since its mostly off-topic [19:17:37] <Compn> so the cycle continues [19:17:55] <mru> he'll never change [19:20:40] <iive> Compn: tell me something I don't know. [19:30:26] * Compn likes reading michaels' gcc mails [19:30:46] <Compn> 15 mails back and forth instead of having someone test some -msse :D [19:30:58] <lu_zero> j0sh: got to fight with apple and their interesting ways to let you develop with their toys [19:31:02] <Compn> changing a bunch of code around just to use that flag :) [19:32:34] <mru> Compn: this is nothing that needs testing [19:33:39] <Compn> i know, but just that part of it amused me [19:33:46] * Compn is easily amused [19:37:02] <Compn> btw mru , i think 'no one can guarentee that it will always work' swings both ways, why not just use -msse until it does break ? but thats just me trolling [19:37:23] <mru> adding -msse is _asking_ for it to break [19:37:38] <cartman> http://cekirdek.pardus.org.tr/~ismail/safari.png have a good laugh [19:38:25] <Compn> web browsers have tons of memleaks :( [19:40:37] <cartman> this one is just better :D [19:40:44] <cartman> 1G RAM usage in 1 minute [19:41:59] <lu_zero> Compn: memleak or usage? [19:42:06] <mmu_man> well it does last at least a month here without restarting, but it does hog the RAM and it feels much better after a restart [19:42:20] <cartman> lu_zero: usage [19:42:26] <cartman> not leaking i think [19:42:33] <mru> how do you tell the difference? [19:42:40] <cartman> mru: its always around 1GB [19:42:46] <mmu_man> I suppose keeping 110 tabs open for a month doesn't help [19:42:56] <mmu_man> cartman probably it can't get more :p [19:43:10] <lu_zero> mmu_man: that would case it to near 2GB [19:43:11] <mru> my irssi has been running for well over a year [19:43:12] <cartman> mmu_man: got 4GB RAM here, 3GB ready to be allocated :P [19:43:15] <mmu_man> though Firefox crashes more than Safari on OSX [19:43:34] <cartman> I think + 4GB RAM will make things better [19:43:37] <mmu_man> and I usually don't have as many tabs open [19:43:59] <mmu_man> 4GB should be enough for everyone ? :p [19:44:06] <cartman> mmu_man: 8GB :D [19:44:11] <Compn> lu_zero : well i dont think i know the difference between a leak and usage. sometimes its usage that goes nuts i guess? or are we talking about firefox going oom ? [19:44:26] * Compn hates oom [19:44:36] * cartman wants extra RAM [19:44:53] <Compn> maybe newer windows os can handle oom stuff [19:45:29] * mmu_man wants SwapToStore(tm) [19:45:49] <mmu_man> need more RAM => orders it automatically :) [19:48:57] <iive> cartman: i've read that firefox checks what is the size of the ram and uses some percentage of it. could safari be doing the same? [19:49:19] <cartman> iive: might be, it starts allocating a huge chunk on startup [19:50:09] <mru> so how do you trick firefox into thinking there's only 1G or so [19:50:34] <Compn> turn off firefox ram usage, make ramdisk, point firefox at it ? [19:50:51] * Compn hasnt tested this [19:51:05] <mru> point? [19:51:14] <mru> and what is the purpose of the ramdisk? [19:51:45] <Compn> the ramdisk would have a 1G size, so firefox would only see that... [19:51:51] <mru> eh? [19:52:01] <mru> malloc and ramdisks are unrelated [19:53:34] <iive> linux already have ramdisk in /dev/shm [19:54:04] <mmu_man> NetSurf everyone ? [19:55:35] <Compn> maybe i was thinking of running firefox in a ramdisk [19:55:48] <mru> that doesn't make sense [19:56:24] <mru> I suppose you could cap the ram usage with ulimit [19:56:30] <mru> but that would probably just kill it [20:00:11] <lu_zero> mru: which firefox are you using? [20:00:24] <mru> latest 3.6.x [20:00:38] <mru> as built by portage [20:01:00] <mru> what's with the split in xulrunner and firefox packages btw? [20:18:30] <kierank> hahaha wikipedia and p2p-next are joining forces [20:27:35] <saintdev> mru: xulrunner is used by more than just firefox [20:27:52] <av500> like? [20:28:10] <kierank> basically any slow application [20:28:16] <thresh> :) [20:28:18] <saintdev> kierank: lol [20:28:38] <av500> kierank: wow, must tell CEO... [20:28:58] <kierank> av500: ceo of what? [20:29:12] <av500> any enterprise level ceo [20:29:28] <kierank> get some buzzwords [20:30:00] <saintdev> av500: the packages that i have installed that depend on it are gecko-mediaplayer, and google-gadgets [20:31:03] * mru flees in terror [20:38:34] <ohsix> get bartab :D [20:47:16] <CIA-63> libswscale: janne * r32392 /trunk/libswscale/utils.c: cosmetics: break long line update_flags_cpu [20:47:16] <CIA-63> libswscale: janne * r32393 /trunk/libswscale/utils.c: swscale: clear SWS_CPU_CAPS_SSE2 in update_flags_cpu() missed in r32068 [20:47:16] <CIA-63> libswscale: bcoudurier * r32394 /trunk/libswscale/ (swscale_template.c utils.c swscale.c swscale_internal.h): Y400A (gray alpha) input support in libswscale [20:47:16] <CIA-63> libswscale: bcoudurier * r32395 /trunk/libswscale/swscale.c: 100l fix if condition [20:47:17] <CIA-63> libswscale: stefano * r32396 /trunk/libswscale/swscale.h: [20:47:17] <CIA-63> libswscale: Bump minor version after the addition of sws_alloc_context() and [20:47:18] <CIA-63> libswscale: sws_init_context() of r32368. [21:11:56] <BBB> \o/ 660 to 159 cycles, and it mostly works [21:12:03] <BBB> now to fix that "mostly" into "always" [21:12:14] <kierank> BBB: what function is this? [21:12:42] <BBB> pred16x16_plane [21:12:50] <kierank> nice [21:12:51] <BBB> it's high (>1.0%) on my profiling [21:13:28] <BBB> holy fuck [21:13:39] <BBB> apparently it speeds up cathedral by 0.3sec (out of 80 in total) [21:13:41] <BBB> 8.0 [21:13:54] <BBB> that's almost 0.4% [21:13:57] <Dark_Shikari> you didn't realize that? [21:14:07] <Dark_Shikari> it's the slowest prediction function, and gains the most from asm [21:14:10] <Dark_Shikari> now, go compare your function to x264's [21:14:14] <BBB> no [21:14:21] <BBB> I want to finish it myself first ;) [21:14:31] <BBB> why didn't you port x264's to ffmpeg alrady? [21:14:40] <BBB> it wasn't there so I thought you didn't have asm yrt [21:14:50] <Dark_Shikari> dunno [21:14:56] <Dark_Shikari> we have asm for every single prediction function [21:15:00] <Dark_Shikari> (of the ones which are useful to asm) [21:15:02] <Dark_Shikari> i.e. about 50+ [21:15:50] <BBB> that's not 0.4%; it's 3.75% [21:15:54] <BBB> that's pretty darn good :) [21:16:03] <BBB> that makes 5.0% btw, diego owes me a beer now [21:16:14] <BBB> too bad he isn't here [21:16:20] <Dark_Shikari> plane 8x8 is important too [21:16:28] <BBB> it doesn't sow up in my profiling (?) [21:16:33] <BBB> I'll have a look at it [21:16:36] <BBB> it's pretty similar [21:16:37] <Dark_Shikari> pick a different clip [21:16:42] <Dark_Shikari> also, 16x16 shows up high because of that clip [21:16:48] <Dark_Shikari> that clip is from an encoder addicted to i16x16 mode [21:16:55] <Dark_Shikari> on most clips it's going to be much less [21:16:56] <Dark_Shikari> especially x264 [21:16:59] <BBB> fair enough, give me a different clip [21:17:45] <Dark_Shikari> fyi in x264 [21:17:50] <BBB> http://ffmpeg.pastebin.com/Nh2nHzBW [21:17:50] <Dark_Shikari> mmx 16x16: 121 clocks [21:17:53] <BBB> please review [21:17:53] <Dark_Shikari> sse2: 81 [21:17:55] <Dark_Shikari> ssse3: 73 [21:18:20] <BBB> this is only the ssse3 function [21:18:26] <BBB> I'll fill in the blanks for the rest later [21:18:38] <Dark_Shikari> 17-52 is slow [21:18:43] <Dark_Shikari> that would be better in scalar [21:18:49] <Dark_Shikari> x264's version uses a hybrid of C and yasm [21:18:58] <Dark_Shikari> converting it to pure yasm made it slower [21:19:07] <Dark_Shikari> because I was too lazy to reorder the massive series of loads enough to get good performance [21:19:07] <BBB> scalar? [21:19:11] <Dark_Shikari> yes [21:19:14] <BBB> what is that [21:19:18] <Dark_Shikari> not vector [21:19:20] <Dark_Shikari> not using xmmregs [21:19:21] <BBB> oh [21:19:22] <Dark_Shikari> .... [21:20:37] <Dark_Shikari> you have a redundant pmaddubsw [21:20:48] <Dark_Shikari> also you don't need pmaddubsw for that [21:20:52] <BBB> ? [21:20:57] <Dark_Shikari> 95-96 [21:21:03] <Dark_Shikari> protip: [21:21:04] <Dark_Shikari> pmullw xmm3, [pw_76543210] [21:21:04] <Dark_Shikari> psllw xmm1, 3 [21:21:04] <Dark_Shikari> paddsw xmm0, xmm3 ; xmm0 = {i+ 0*b, i+ 1*b, i+ 2*b, i+ 3*b, i+ 4*b, i+ 5*b, i+ 6*b, i+ 7*b} [21:21:08] <Dark_Shikari> paddsw xmm1, xmm0 ; xmm1 = {i+ 8*b, i+ 9*b, i+10*b, i+11*b, i+12*b, i+13*b, i+14*b, i+15*b} [21:22:14] <BBB> oh sweet [21:22:59] <Dark_Shikari> the code has loren's blame on it [21:23:04] <Dark_Shikari> if you want to copy it, ask pengvado [21:23:11] <BBB> pff.... you showed it to me [21:23:15] <Dark_Shikari> I mean the whole function [21:23:16] <BBB> that's evil :) [21:23:23] <BBB> oh right [21:23:51] <BBB> I'll see if I can do that weird vertical part in scalar easily [21:24:03] <Dark_Shikari> in general, repeated testing has shown scalar is faster for "weird vertical parts". [21:24:05] <BBB> do you just use a loop + movzx etc? [21:24:07] <Dark_Shikari> even on cpus with fast shuffle units [21:24:12] <mru> finally x86 catching up with arm... [21:24:28] <Dark_Shikari> I don't know. all I know is when I tried it on a whim [21:24:30] <Dark_Shikari> and spent 10 minutes on it [21:24:32] <Dark_Shikari> it was slower than gcc [21:24:36] <Dark_Shikari> so whatever gcc doing is probably better than the obvious [21:25:07] <Dark_Shikari> I mean what gcc does to the C in x264, of course. [21:25:14] <Dark_Shikari> and by the C I mean the C part of the sse2 function. [21:25:19] <Dark_Shikari> Michael would go nuts if he saw it [21:25:22] <Dark_Shikari> OMG A CALL [21:25:27] <Dark_Shikari> CALL OVERHEAD OH SHIT [21:25:35] <mru> AN ENTIRE CYCLE TO WASTE!!!! [21:25:59] <Dark_Shikari> actually that function is an abomination [21:26:02] <Dark_Shikari> it's inline asm, C, and yasm [21:26:08] <Dark_Shikari> all in a big boulliabaise [21:26:18] <kierank> lol boulliabaise [21:26:33] <mru> he likes that word [21:26:46] <kierank> yes i know [21:26:55] <mru> it's french [21:26:58] <Dark_Shikari> have I even used it before? [21:27:03] <mru> yes [21:27:04] <kierank> yes in a blog post somewhere [21:27:22] <mru> metaphorically, of course [21:27:25] <Dark_Shikari> the only place I remember it being used is http://hqvia.com/wp-content/uploads/Bitchin-fast-3D-2000.jpg [21:28:14] <mru> http://x264dev.multimedia.cx/?p=360 [21:28:40] <mru> "The proposal combines a bouillabaisse of new features, ranging from a 12-tap interpolation filter ..." [21:28:51] <BBB> heh :) [21:28:52] <BBB> new word [21:29:02] <av500> http://erkie.github.com/ [21:29:02] <BBB> ok removed the pmaddubsw [21:29:04] <av500> fun [21:29:25] <BBB> now to redo the V part in scalar [21:29:27] <mru> what is a bookmark bar? [21:29:43] <Dark_Shikari> a crunchy, granola-filled treat [21:30:13] <av500> mru: a hangout for librarians [21:31:02] <mru> the st20 dev tools called the equilvalent of 'ar' the librarian [21:31:40] <mru> wow, nice patch on the ml [21:31:44] <mru> if (!ptr) free(ptr) [21:31:53] <BBB> current one is 150 cycles [21:32:00] <mru> get rid of those null pointers [21:32:01] <BBB> still quite slow compared to x264 :( [21:32:08] <mru> BBB: so steal theirs [21:32:23] <BBB> stealing code doesn't feel as good as rewriting it from scratch [21:33:20] <mru> and even better is selling it [21:35:37] <Dark_Shikari> wheel, reinventing, etc [21:36:03] <mru> would you be interested in purchasing some extra round wheels? [21:54:36] <kierank> mru: if you can put them in a square hole I'd be interested [22:38:43] <Dark_Shikari> holy moses [22:38:51] <Dark_Shikari> I was wondering why my optimized version was slower than the original code [22:38:56] <Dark_Shikari> for(x=offset; x<offset+end_x-start_x; x++) buf[x]= src[x]; [22:39:05] <Dark_Shikari> when compiling this loop, gcc recalculates "offset+end_x-start_x" every iteration. [22:39:15] <Dark_Shikari> fml [22:40:18] <BBB> Dark_Shikari: hmm... scalar is indeed MUCH faster [22:40:21] <BBB> 121 cycles now [22:41:38] <BBB> yours was 71? how on earth do you do that [22:41:58] <BBB> oh 73 [22:41:59] <BBB> still [22:42:01] <BBB> holy cow [22:43:10] <Dark_Shikari> that's on an i7, 32-bit [22:43:43] <BBB> oh this is 64bit [22:43:48] <BBB> shouldn't that be faster? [22:44:52] <Dark_Shikari> Yes [22:44:55] <Dark_Shikari> well, at least equal [22:44:59] <Dark_Shikari> my point being, your code sucks [22:45:01] * Dark_Shikari ducks [22:45:48] <Dark_Shikari> my god. gcc is horrible [22:45:51] <Dark_Shikari> a memcpy loop, according to gcc: [22:45:52] <Dark_Shikari> 4f9480: 0f b6 01 movzx eax,[ecx] [22:45:52] <Dark_Shikari> 4f9483: 83 c3 01 add ebx,0x1 [22:45:52] <Dark_Shikari> 4f9486: 83 c1 01 add ecx,0x1 [22:45:52] <Dark_Shikari> 4f9489: 88 02 mov [edx],al [22:45:55] <Dark_Shikari> 4f948b: 83 c2 01 add edx,0x1 [22:45:57] <Dark_Shikari> 4f948e: 39 de cmp esi,ebx [22:46:00] <Dark_Shikari> 4f9490: 7f ee jg 0x4f9480 [22:46:14] * BBB decides to hate Dark_Shikari for the rest of the day [22:46:21] <BBB> now be helpful, bitch! [22:46:53] <Dark_Shikari> read x264's code [22:47:08] <BBB> http://ffmpeg.pastebin.com/sAqqtBA6 [22:47:16] <BBB> I want to feel at least once like I wrote it [22:47:22] <BBB> copying x264 is like the lamest thing ever [22:47:24] <BBB> I'll never learn [22:47:37] <Dark_Shikari> your horizontal sum sucks [22:48:14] <BBB> this is what ffmpeg's hadamard code does [22:48:28] <Dark_Shikari> 33-77: if you can reduce the number of ops using imul, do it [22:48:29] <BBB> (I know: you'll tell me ffmpeg's hadamard code sucks) [22:48:35] <Dark_Shikari> your loop should be unrolled 2x [22:49:16] <BBB> you mean 2 lines per iter? or 4? [22:49:29] <BBB> (or whatever is faster, I guess) [22:49:39] <Dark_Shikari> 2 [22:49:44] <BBB> k [22:49:45] <Dark_Shikari> did you remember to subtract out nop cycles when doing your timing? [22:49:48] <iive> Dark_Shikari: what I don't understand is, why no CPU optimized the case of rep movsb ? [22:49:53] <BBB> Dark_Shikari: no [22:50:00] <Dark_Shikari> BBB: well then stop comparing different numbers =p [22:50:08] <BBB> Dark_Shikari: this is the time h264.c START_TIMER bla->bla(); STOP_TIMER() [22:50:15] <BBB> hm [22:50:18] <Dark_Shikari> You need to subtract nop cycles [22:50:20] <Dark_Shikari> the cost of an empty start_timer [22:50:25] <BBB> that takes time [22:50:26] * BBB lazy [22:50:35] <pengvado> so do it once and for all [22:50:47] <Dark_Shikari> yes, like we do in x264 [22:50:56] <Dark_Shikari> FFFFFFFFFF [22:50:59] <Dark_Shikari> HOW CAN GCC ADD A CMP TO THIS [22:51:00] <Dark_Shikari> for(x=start; x>=0; x--) [22:51:00] <Dark_Shikari> curdst[x]= cursrc[x]; [22:51:02] <BBB> 25 [22:51:04] <Dark_Shikari> why why why why [22:51:10] <Dark_Shikari> there is no cm pthere [22:51:11] <BBB> so mine is 121-25=96 [22:51:22] <pengvado> http://pastebin.com/BKgq65Lm [22:51:53] <BBB> 96 is still > 73 [22:52:01] <BBB> I'll see what else I can chew off tonight [22:52:20] <BBB> 96 isn't too bad anyway :) [22:53:06] <BBB> saves a good few percent [22:55:16] <BBB> Dark_Shikari: I'm surprised you didn't optimize all h264pred stuff, I assumed you did when you did the vp8 ops [22:55:59] <BBB> pengvado: can I peek at your code? (i.e. can I steal your pred16x16plane code and put it under lgpl, basically :-p) [22:56:58] <Dark_Shikari> if pengvado says yes, I would prefer you: [22:57:06] <Dark_Shikari> a) steal the code outright (don't rewrite) [22:57:17] <Dark_Shikari> b) once you steal it, then try to eliminate the gcc part [22:57:23] <Dark_Shikari> but only commit an elimination of the gcc part if it's faster [22:57:30] <Dark_Shikari> c) once you're done with that, we'll backport it to x264 [22:57:31] <Dark_Shikari> lol [23:04:11] <pengvado> agreed with Dark_Shikari [23:05:30] <BBB> Dark_Shikari: fine with me, I already wrote the asm code for that (see my last link) :-p [23:05:35] <BBB> let's try that [23:06:17] <Dark_Shikari> BBB: it may not be faster ;) [23:06:22] <BBB> true [23:06:28] <BBB> that's why I'll try it ;) [23:06:56] <BBB> which file is this? [23:07:01] <Dark_Shikari> common/x86/predict-a.asm [23:07:03] <Dark_Shikari> brb, going to plane. [23:07:19] <BBB> uh... have a nice trip? [23:07:23] * BBB goes home [23:07:32] <kierank> internet on plane? [23:10:23] <BBB> expensive [23:10:42] <BBB> predict_16x16_p_core_sse2 has no gcc in it (in my version), it just receives b/c as arguments [23:41:36] <Compn> lol [23:43:43] * Compn didnt know the samsung guy posted on Dark_Shikari's blog [23:44:39] <spaam> hmm? [23:46:32] <kierank> the bbc guy was also on x264dev for a while [23:57:25] <Compn> ah [23:57:34] <j0sh> steve jobs reads x264dev [23:57:35] <Compn> spaam : http://x264dev.multimedia.cx/?p=360

1 0

IRC log for 2010-09-27
by irc＠mansr.com 28 Sep '10

28 Sep '10

[00:31:10] <CIA-63> ffmpeg: stefano * r25216 /trunk/ (libavcodec/avcodec.h libavutil/avutil.h doc/APIchanges): Bump version and update APIchanges after r25210. [01:18:35] <CIA-63> ffmpeg: stefano * r25217 /trunk/libavfilter/avfilter.c: [01:18:35] <CIA-63> ffmpeg: Make avfilter_destroy() code less convoluted, introducing a temporary [01:18:35] <CIA-63> ffmpeg: variable link. [02:42:59] <bcoudurier> hey guys [02:43:07] <bcoudurier> wtf is happening in LA now, are we having a very late summer [02:43:33] <Dark_Shikari> Yeah, wtf [02:43:36] <Dark_Shikari> it was SO FUCKING HOT today [02:43:39] <Dark_Shikari> holy christ [02:43:44] <bcoudurier> yeah [02:43:47] <bcoudurier> it's still hot now [02:44:20] <Dark_Shikari> I walk outside in the morning, at 11 AM, and the instant I move into the sun, it feels as if I moved to the Judean Desert [02:44:57] <Dark_Shikari> Oh. No wonder it did. It was _actually_ near 110F. [02:46:27] <Dark_Shikari> bcoudurier: it's odd. every year we seem to have exactly one week (no matter how late) in LA with temps above 100 [02:46:30] <Dark_Shikari> then it never happens again [02:46:38] <Dark_Shikari> same with rain. one week with rain. then it never happens again. [02:47:44] <Dark_Shikari> wow. it's still 97. [02:48:59] <bcoudurier> yeah [02:49:02] <bcoudurier> it's freaking hot [02:49:14] <bcoudurier> we had a _shitty_ summer and now it's hot [03:05:16] <Compn> heh [03:05:22] <Compn> its LA , what are you expecting ? [03:06:55] * Compn realizes he is 15 mins late [04:24:24] <Dark_Shikari> does anyone have anything that can open avc-intra? [04:26:30] <Dark_Shikari> mru: haha oh wow, I found a chinese article series about porting x264 to blackfin [04:26:53] <Dark_Shikari> there's some actually highly interesting results [04:26:57] <Dark_Shikari> they compared write through with writeback caching [04:27:07] <Dark_Shikari> writethrough is 23% slower [04:27:22] <Dark_Shikari> (this is without asm, which means it's REALLY a lot slower) [04:44:37] <CIA-63> ffmpeg: darkshikari * r25218 /trunk/libavcodec/h264.c: [04:44:38] <CIA-63> ffmpeg: Improve error concealment of lost frames [04:44:38] <CIA-63> ffmpeg: If a frame is lost, replace it with data from the previous valid frame. [04:51:44] <Dark_Shikari> bcoudurier: [04:51:45] <Dark_Shikari> [mxf @ 0x10463290] track 0: could not find essence container ul, codec not curre [04:51:48] <Dark_Shikari> ntly supported in container [04:51:51] <Dark_Shikari> do we not support h264 in MXF?!?! [04:58:42] <thresh> moroning [05:31:08] <bcoudurier> not yet [05:32:08] <Dark_Shikari> well, I was able to confirm that if I mux to an mp4 [05:32:11] <Dark_Shikari> x264's avc-intra works in premiere [05:32:42] <bcoudurier> that's great [05:33:12] <Dark_Shikari> (with my patch) [05:46:32] <KotH> hoi zäme [06:02:15] <bcoudurier> Dark_Shikari, did you send the patch somewhere ? [06:03:36] <Dark_Shikari> it's an x264 patch [06:03:40] <Dark_Shikari> it'll go in the next push [06:04:27] <bcoudurier> I fear the MXF mapping of AVCIntra in the P2 flavor is ugly [06:04:39] <Dark_Shikari> what's the issue? [06:06:55] <Dark_Shikari> do you need a test file or something? [06:09:03] <bcoudurier> It's the clip wrapping method, like pack all the frames together in one packet [06:09:23] <bcoudurier> and the audio is in a separate file [07:29:18] <bcoudurier> night guys [07:29:56] * kshishkov looks outside and disagrees with Baptiste and his leaving script [07:34:18] <pJok> god morgon kshishkov [07:36:07] <kshishkov> goda morgnar, pJok [07:37:16] <pJok> im surprised to see swscale slowly getting fixed [07:38:06] <kshishkov> what's the most surprising - that it's swscale or it's mere slowly instead of continental drift speed? [07:46:37] <mru> Dark_Shikari: of course write-through is slow [07:46:43] <mru> every store goes all the way to ram [07:49:55] <Dark_Shikari> mru: so it saves load bandwidth, at the cost of store bandwidth [07:50:00] <Dark_Shikari> probably crap unless you built your application around it [07:50:03] <mru> no it doesn't [07:50:14] <mru> loads are unaffected [07:51:37] <Dark_Shikari> I thought the point of writeback is that you don't automatically load cacheline X if you store to cacheline X? [07:51:47] <Dark_Shikari> er, write-through [07:52:01] <mru> no, that's a different attribute [07:52:16] <mru> you can either allocate on write or not [07:52:31] <Dark_Shikari> ah k [07:52:34] <mru> allocate on write means if a write misses, you fetch the line and dirty the cache [07:52:42] <Dark_Shikari> so why would write-through even be an option? [07:52:56] <mru> it's useful in a few situations [07:53:43] <mru> if you do frequent (clustered) reads, not too many writes, and writes need to be visible by some other device [07:53:54] <mru> otherwise you'd need a cache flush [07:54:18] <mru> it's also useful for debugging purposes [08:07:14] <pJok> kshishkov, its most surprising that its swscale [08:17:38] <pJok> hrm [08:17:44] <pJok> i wonder when OS/2 finally dies [08:17:55] <pJok> even the banks here are slowly switching from it [08:19:10] <mru> never underestimate the koreans [08:19:12] <kshishkov> well, you need to talk to North Korean leader, so he does something to the biggest OS/2 user [08:19:35] <kshishkov> and I heard that Windows 98 is still popular in Vietnam [08:19:57] <cartman> kshishkov: [OT] http://www.meforum.org/2753/turkey-future [08:20:56] <pJok> mru, can't you just let them fork their own version of ffmpeg with OS/2 support? [08:20:56] <kshishkov> cartman: I wonder why they decided to compare Turkey to Russia? [08:21:16] <cartman> kshishkov: should be compared to Iran [08:21:34] <mru> pJok: I don't mind as long as supporting os/2 limited to a few lines configure [08:21:42] <mru> and they actively maintain it [08:21:44] * kshishkov has heard some bad things about last Swedish election winners [08:21:51] <mru> winners? [08:21:55] <mru> there were no winners [08:22:13] <kshishkov> if you got to Riksdag you're winner [08:22:29] <kshishkov> (population obviously doesn't count) [08:27:25] <pJok> kshishkov, the only winners in the swedish election are the media [08:27:55] <pJok> gives them something to write about [08:28:42] * kshishkov thought that's not a problem for media anyway since majority of news nowadays are generated by themselves [08:32:34] <lu_zero> ^^; [08:39:14] <_av500_> gm [08:39:23] <kshishkov> hej [08:40:09] <mru> buon giorno [10:02:33] <CIA-63> ffmpeg: stefano * r25219 /trunk/libavutil/opt.c: Cosmetics: apply misc style fixes. [10:28:53] <asac> hi gents! what's the status of arm/neon optimizations on vp8 codec? who should i talk to about potential contributions on this etc.? [10:29:24] <kshishkov> I suspect it's mru, he'll be here in a minute [10:30:10] <asac> thanks kshishkov! [10:30:19] <asac> mru: ^^ ;) [10:30:21] <Dark_Shikari> yes, he probably has neon on highlight [10:34:36] <asac> mru: we (linaro) are currently planning our work for the next cycle; and one topic that was selected by our steering committee on multimedia is to optimize important software codecs for ARM. VP8 is obvious target, but I would also be interested to hear if there are other common codecs that need some opts for ARM/NEON etc. and that you would like to see contributions for. [10:35:09] <CIA-63> ffmpeg: stefano * r25220 /trunk/libavutil/opt.c: [10:35:09] <CIA-63> ffmpeg: Simplify include, since opt.c is now in libavutil there is no need [10:35:09] <CIA-63> ffmpeg: to use the library path prefix for eval.h. [10:35:36] <mru> asac: there are vp8 neon patches in the queue already [10:35:42] <mru> I just haven't had time to take care of them [10:36:59] <spaam> mru: dont slack ;P [10:37:09] <mru> that's exactly what I'm not doing [10:37:27] <mru> I'm simply prioritising paying clients [10:37:30] <Dark_Shikari> asac: decoders, encoders, or both? [10:37:44] <mru> if linaro were to send some cash my way... [10:43:06] <asac> Dark_Shikari: i think both ... decoders first, but encoders for camera are also important i guess [10:43:32] <asac> mru: we dont have cash. only engineers [10:43:39] <mru> who pays them? [10:43:42] <Dark_Shikari> x264 has a bunch of NEON functions missing [10:43:43] <asac> at least atm ;) [10:43:53] <Dark_Shikari> x264 is the only video encoder that's optimized for ARM at all [10:44:00] <asac> mru: we are an engineering foundation [10:44:01] <Dark_Shikari> nobody else seems to have tried [10:44:17] <Dark_Shikari> we're missing a few functions, as Yuvi wasn't able to write every last one during his GSOC [10:44:28] <asac> thanks Dark_Shikari [10:44:30] <Dark_Shikari> probably at least 20-30% speed could be gotten, plus we could do some larger-scale optimizations [10:44:32] <mru> Dark_Shikari: I'm available for hire [10:44:37] <Dark_Shikari> to compensate for things like the cortex a8's crappy memory [10:44:38] <asac> so x264 encoding [10:44:48] * asac notes down [10:44:49] <Dark_Shikari> mru: We don't have boatloads of money, and if we did, we'd spend it on really important things first [10:44:52] <Dark_Shikari> like 10-bit support in lavc [10:44:56] <mru> asac: but these engineers of yours, someone surely pays them, right? [10:45:01] <Dark_Shikari> (part of our evil plan to swap the entire world over to 10-bit h264) [10:45:16] <mru> Dark_Shikari: I don't care who pays me [10:45:23] <cartman> isn't h.264 decoding more important anyway? [10:45:26] <asac> mru: of course ;). but they wont get fired. we want to help out with code first [10:45:53] * mru is still struggling to understand what linaro is [10:45:56] <asac> http://www.linaro.org/commercial-sponsors/ [10:46:04] <asac> http://www.linaro.org/about-linaro/ [10:46:09] <mru> heck, I haven't even figured out what they're pretending to be yet [10:46:15] <Dark_Shikari> cartman: we already have h264 decoding asm [10:46:16] <Dark_Shikari> shitloads of it [10:46:17] <asac> https://wiki.linaro.org/Releases/1105/TechnicalTopics [10:46:23] <cartman> Dark_Shikari: need moarrrr [10:46:26] <mru> I've read the website [10:46:32] <mru> that's not what I'm talking about [10:46:34] <asac> mru: what do you want to know? [10:46:42] <mru> I want to understand [10:46:46] <mru> there's a difference [10:46:58] <asac> sure. i am here to answer questions then ;) [10:47:35] <asac> in short: we want to bring the linux arm software stack to a shape that its ready to compete with intel ;) [10:47:46] <Dark_Shikari> Then you _really_ have a lot to do with x264 ;) [10:47:47] <Dark_Shikari> lol [10:47:52] <mru> it's the "we" part that's a bit fuzzy [10:48:02] * Dark_Shikari mutters about intel still not sending us a sandy bridge [10:48:29] <asac> mru: ARM is basically the main drivers ... with all the partners seeing that this is importantt to do and hence sending engineers to work on this [10:48:31] <mru> Dark_Shikari: people like to do other things than encode h264, you know [10:49:02] <mru> asac: well, I'm currently discussing possible paid work with ARM [10:49:03] <Dark_Shikari> well, there are 5 things people care about [10:49:09] <Dark_Shikari> audio encoding, decoding, video encoding, decoding, and colorspace conversion [10:49:13] <Dark_Shikari> (mostly)( [10:49:19] <Dark_Shikari> video decoding (h264) is well-optimized, at least asm-wise [10:49:32] <Dark_Shikari> audio decoding is pretty good iirc, with the exception of float/int conversion stuff which is bikeshed [10:49:41] <Dark_Shikari> audio encoding isn't very optimized, and for encoding there's only x264 [10:49:44] <Dark_Shikari> *video encoding [10:49:49] <mru> aac-he needs optimising [10:49:58] <Dark_Shikari> aac-he is a gigantic mess [10:50:06] <mru> that too [10:50:49] <asac> aac-he -> encoding is a mess? or both? [10:51:49] <mru> asac: so which company do you work for? [10:52:22] <asac> mru: i am working for canonical ... we are there as all the partners are competitors, so we provide the balance and keep things rolling ;) [10:52:37] <mru> yada yada yada [10:53:27] <asac> but i am 100% linaro ;) ... in the long run it shouldnt matter much where you originate from ;) [10:56:41] <mru> right now it matters a little [10:57:02] <cartman> it'll cost a leg and an ARM :P [10:57:11] <asac> haha [10:57:59] <mru> all else aside, I do appreciate you coming directly to us [10:58:05] <mru> instead of hoarding patches in ubuntu [10:58:09] <asac> heh [10:58:13] <asac> linaro != ubuntu [10:58:27] <mru> only ~= [10:58:30] <arpu> hello can someone help me i wnat split/cut a avi file with x264 codec (libavformat) [10:58:43] <arpu> i get strange artefakts [10:59:13] <asac> mru: linaro works upstream only ... unless upstream release cycle is really long ...which is when we backport and deliver to distributions like meego, ubuntu, etc. [10:59:46] <asac> if you are working on ARM you should try our toolchain ;) [10:59:54] <mru> I have [10:59:57] <mru> it compiles ffmpeg [11:00:11] <asac> cool. any feedback? compared to fsf/codesourcery ? [11:00:12] <mru> and kudos for making it build without patching [11:00:31] <cartman> asac: why do you need just another toolchain? [11:00:41] <mru> cartman: it's yet another gcc fork [11:02:24] <cartman> mru: gcc doesn't merge useful arm stuff? [11:02:24] <asac> cartman: its not another toolchain. its fsf toolchain. we put stuff upstream and backport so the arm ecosystem gets a well optimized toolchain from stable branch [11:02:25] <superdump> the messy part of he aac is the signalling [11:02:25] <asac> so partly doing what CS did ... just that we bake the toolchain in full distros and hence we think our quality is quite high! [11:02:26] <Dark_Shikari> "bake the toolchain in full distros" [11:02:26] <superdump> plus it's a lot of code and complexity for the gains it gives [11:02:46] <Dark_Shikari> superdump: I think he means decoding [11:02:58] <superdump> i'm talking about decoding [11:03:35] <Dark_Shikari> "the hard part is the signalling" [11:03:43] <Dark_Shikari> but signalling is done by the encoder isn't it? [11:04:05] <superdump> ok, writing code to handle all the different signalling cases [11:04:12] <cartman> asac: I see, thanks [11:04:46] <superdump> and you can't always know from the outset whether sbr is used or so [11:04:52] <asac> cartman: welcome [11:04:54] <superdump> which is a pita [12:28:42] <CIA-63> ffmpeg: thardin * r25221 /trunk/libavformat/mpegtsenc.c: mpegtsenc: Write subtitle extradata if set [12:28:43] <CIA-63> ffmpeg: thardin * r25222 /trunk/libavformat/mpegtsenc.c: mpegtsenc: Indent [13:33:12] <kshishkov> pross-au: g'day, mate. One of our chaps has found 5.1 Bink audio, it seems [13:34:00] <pross-au> Holy crap :D [13:34:08] <DonDiego> astrange: i hear an approved patch of yours is waiting to be applied.. [13:34:24] <Dark_Shikari> _what_ [13:34:24] <Dark_Shikari> 5.1? [13:34:24] <Dark_Shikari> lol [13:34:33] <Dark_Shikari> that sounds like something bink invented on the request of a single customer [13:34:34] <pross-au> Bink is proving its durability [13:35:20] <pross-au> Dark_Shikari: ffmpeg needs to support that for completeness [13:39:07] <kshishkov> pross-au: < kierank> kshishkov: have you seen 5.1 variant of bink audio? [13:39:29] <kshishkov> pross-au: < kierank> header is 1FCB [13:40:26] <pross-au> Must be recent titles [13:40:48] <pross-au> Let me punch that into Bing.com [13:40:53] <kshishkov> speaking of which, you still haven't completed BINKb decoder yet [13:41:33] <pross-au> Yeah, i logged ontonight specifically to post the update wtv demuxer [13:42:10] <pross-au> apparently bink does 5.1 and 7.1 now [13:42:44] <kshishkov> test video decoder while you're on it [13:43:25] <pross-au> Wilco [13:43:50] <pross-au> Im liking the wmvp work too [13:43:55] <pross-au> Nice job [13:44:01] <kshishkov> it's just a hack [13:44:34] <kshishkov> real decoder should decode those pictures to separate planes and perform all that zoom/rotation/fading effects [13:45:13] <pross-au> id rather see a hack then a standalone 'wmvp2ffmpeg' type project [13:46:53] <kshishkov> you can tease Dark_Shikari with wvp2 decoder though [14:04:05] <pross-au> 'ello kierank [14:10:52] <kierank> hello pross-au [14:12:01] <kierank> looks like steam uses libavutil... [14:12:08] <Dark_Shikari> _what_? [14:12:27] <Dark_Shikari> whoa. you're right [14:12:28] <Dark_Shikari> steam uses avcodec [14:12:33] <Dark_Shikari> wtf does steam use avcodec for? [14:12:35] <_av500_> and vapor? [14:12:43] <kierank> they just use the utils it seems [14:12:49] <Dark_Shikari> do they abide by lgpl? [14:13:12] <Dark_Shikari> "third party legal notices" I'm guessing this has the LGPL in it [14:13:15] <Dark_Shikari> and informationa bout sources [14:13:31] <_av500_> they might want to switch to libavcore, no? [14:13:36] <Dark_Shikari> amusing they use it only for utils [14:13:54] <kierank> avcodec etc is in the /bin directory [14:14:09] <kierank> it's because they use chromium as a backend [14:14:15] <Dark_Shikari> aha [14:14:19] <Dark_Shikari> >chromium embedded framework [14:14:32] <mru> sounds scary [14:14:48] <kierank> pross-au: I had a new bink variant from Civ V but I deleted it by accident. [14:14:56] <Dark_Shikari> "For FFMPeg, part of Chromium, part of CEF:" [14:15:01] <Dark_Shikari> lol they mispelled ffmpeg [14:15:08] <Dark_Shikari> and spelled it differently in different parts of the document [14:15:30] <Dark_Shikari> but looks fine otherwise =p [14:15:44] <Dark_Shikari> Interesting that they're now using chromium for the web browser. [14:15:45] <kshishkov> pross-au: and Dark_Shikari claimed to play Civ V, so extort Bink sample from him [14:15:56] <kierank> what about the reverse engineering clauses? [14:16:34] <Dark_Shikari> picking nits is stupid, go after the real violators [14:17:34] <DonDiego> kierank: do they have them? [14:17:45] <Dark_Shikari> >civ5_opening_movie_en_US.wmv [14:17:49] <Dark_Shikari> bink [14:17:50] <Dark_Shikari> lol right [14:17:55] <Dark_Shikari> bink my ass [14:18:04] <kierank> there's a bink audio file in there somewhere [14:18:17] <kierank> the file extension is .binka [14:18:19] * kshishkov claims supporting Bink in WMV then [14:18:37] <Dark_Shikari> confirmed, found it [14:18:46] <Dark_Shikari> OpeningMenu-51mix.binka [14:18:59] <_av500_> .binka sounds like some swedish non-alcohol drink that kshishkov might like [14:19:15] <_av500_> i had a nice bottle of Binka... [14:19:31] <Dark_Shikari> OpeningMenu-51mix.binka: Invalid data found when processing input [14:19:33] <kierank> kshishkov: you're missing out by not drinking alcohol [14:20:43] <mru> we found bink beer in brussels [14:21:50] <kshishkov> _av500_: just don't ask who likes Trocadero on this channel [14:22:13] * pJok should actually go buy a trocadero [14:22:26] <kshishkov> pJok: why? [14:23:33] <pJok> kshishkov, never tried it [14:24:26] <Dark_Shikari> kshishkov: http://www.mediafire.com/?6endqr45j3nbox5 [14:24:37] <Dark_Shikari> now I'm going to sleep, when I wake up, I expect my ffmpeg to be able to play this back! [14:24:43] <Dark_Shikari> get moving ;) [14:25:22] <kshishkov> Dark_Shikari: it's for pross-au then, not me [14:25:28] <Dark_Shikari> lol [14:25:30] <merbzt> ahh trocadero [14:25:30] * Dark_Shikari sleeps [14:26:15] <pross-au> miles\win32\binkawin.asi [14:26:36] <pross-au> there are no other bik/bink files in civ5 [14:27:27] <BBB___> j-b: you are our biggest isv, how can you claim not to be part of our community? [14:28:10] <j-b> BBB___: technically, I am part of the ffmpeg community, not ffmpeg-dev community [14:28:33] <j-b> and as I was answering on ffmpeg-dev@ not ffmpeg-user@ :D [14:29:07] <BBB___> I'll buy you beer anyway :) [14:29:21] <BBB___> you'll be our honorable ffmpeg-user attendee [14:29:28] <j-b> :) [14:39:03] <cartman> BBB___: got a guestion for you [14:39:07] <cartman> hmmmpf what was that [14:39:35] <astrange> DonDiego: i'll apply it today [14:39:41] <cartman> ah yes [14:39:48] <cartman> BBB___: did you ever figure out a solution for http://blogs.gnome.org/rbultje/2009/03/04/firefox-gmail-and-content-type-of… ? [14:40:25] <cartman> BBB___: in my case Chrome/Safari misbehaves too [14:40:48] <DonDiego> astrange: good :) [14:43:02] <BBB___> cartman: no :( [14:43:06] <cartman> BBB___: :-/ [14:45:08] <kshishkov> BBB: where is xvp8? [14:45:22] <BBB> kshishkov: I knew you'd beat me to it! congrats btw [14:45:25] <BBB> where's wvp2? [14:45:30] <BBB> and non-i-frames? [14:52:59] <kshishkov> BBB: where is I-only xvp8 at least? [15:17:08] <CIA-63> ffmpeg: michael * r25223 /trunk/libavcodec/flicvideo.c: [15:17:08] <CIA-63> ffmpeg: Fix several security issues in flicvideo.c [15:17:08] <CIA-63> ffmpeg: This fixes CVE-2010-3429 [16:11:22] <CIA-63> ffmpeg: mstorsjo * r25224 /trunk/libavformat/rtpproto.c: rtpproto: Use a sockaddr_storage instead of a sockaddr_in with recvfrom [16:16:55] <BBB> mru: see? I can write inline asm [16:17:05] <BBB> (kind of a waste of my time, but ohwell) [16:17:48] <BBB> the reason it's faster is likely because gcc knows better which registers to use and how many (x86-64 has many more regs available then x86-32, and I don't take advantage of that to make the code more similar) [16:24:40] <CIA-63> ffmpeg: stefano * r25225 /trunk/ (8 files in 2 dirs): Move av_get_token() from libavfilter to libavutil. [16:25:23] <mru> how often is lack of core registers a problem? [16:27:35] <mru> wow, what an ungrateful itard [16:28:21] <KotH> itard? [16:28:34] <mru> iTard [16:28:38] <KotH> oh.. [16:28:42] <KotH> -devel? [16:28:46] <mru> ! [16:28:59] <CIA-63> ffmpeg: stefano * r25226 /trunk/doc/APIchanges: Add APIchanges entry after r25225. [16:30:28] * KotH wonders, whether people will understand those one character communications when they discover the irc logs in 1000 years, burried under a pile of uncompiling code, written in an ancient programming language nobody has ever heard of [16:35:08] * cartman trolls mru [16:35:14] <cartman> you unhelpful!!111!! [16:36:21] <DonDiego> ah [16:36:27] * DonDiego hadn't flamed in a while [16:40:40] <KotH> if that is a flame, then a burned down candle is a fire storm ;) [16:40:57] <cartman> KotH: you were just too damn nice [16:41:12] <KotH> DonDiego: you should definitly learn to insult people by being polite :) [16:41:51] <KotH> cartman: read again until you spot the insult ;) [16:41:58] <cartman> :D [16:42:42] <KotH> mhmmm.. prinzenrolle... [16:47:26] <BBB> "now go away" is nothing more but a kind request to follow advice [16:47:29] <BBB> it's not a flame [16:47:37] <BBB> DonDiego: and you can do so much better than that :-p [16:49:38] <KotH> hmm... this guy is ...offensive [16:50:09] * KotH would kick him from the ml for that, if it wasnt against his ethos [16:53:24] <BBB> JFDI [16:53:40] <BBB> \o/ >30 cycles off another h264 function [16:53:48] <BBB> I might at some point feel like I'm doing something useful [16:55:01] <KotH> BBB: no, it wouldnt be ok morally to kick someone for so little offense [16:55:37] <KotH> it might not look like it, but even a BofH has moral [16:59:50] <CIA-63> ffmpeg: stefano * r25227 /trunk/libavfilter/ (avfilter.c avfilter.h): [16:59:50] <CIA-63> ffmpeg: Make AVFilterLink store the pointers to the source and destination [16:59:50] <CIA-63> ffmpeg: pads, rather than their index. [16:59:57] <twnqx> BBB: come back once my atom can play 1080p. in software. [17:00:27] <cartman> twnqx: you can do that with dxva [17:00:42] <twnqx> not the "in software" part. [17:01:01] <twnqx> i can do it with vdpau as well :P [17:01:07] <cartman> :D [17:01:37] * cartman wonder if its even possible [17:03:50] <CIA-63> ffmpeg: stefano * r25228 /trunk/doc/APIchanges: Add APIchanges entry after r25227. [17:05:00] <DonDiego> KotH, BBB, lol [17:05:28] <KotH> DonDiego: = [17:05:30] <KotH> DonDiego: ? [17:05:44] <DonDiego> lol @ your comments, nothing mor [17:05:45] <DonDiego> e [17:14:32] <Compn> btw [17:14:46] <Compn> i think we spend more time telling people they are on the wrong list than just answering said dumb questions :P [17:17:06] <KotH> Compn: you know, give a man fire and he has warm for a day, set him on fire and he has warm for the rest of his life [17:19:00] <KotH> Compn: you're cheap! [17:19:22] * KotH doesnt get up for anything less than 100CHF/h.. and that's for simple and fun work [17:22:42] <BBB> this guy is hilarious [17:24:16] * cartman is too cheap it seems [17:28:59] <DonDiego> sshhh [17:29:15] <DonDiego> tread carefully now, mozilla is watching :) [17:29:45] <CIA-63> ffmpeg: stefano * r25229 /trunk/libavfilter/avfilter.c: [17:29:45] <CIA-63> ffmpeg: Make avfilter_insert_filter() propagate an error code in case the [17:29:45] <CIA-63> ffmpeg: called avfilter_link() fails. [17:31:35] <kierank> DonDiego: why are you scared of mozilla? [17:31:52] <kierank> I am not scared of mozilla [17:31:54] <mru> kierank: mozilla is scared of us [17:32:37] <DonDiego> some mozilla person entered the channel and i wished to extend a greeting :) [17:33:01] <DonDiego> jrmuizel: welcome [17:34:55] <cartman> I eat mozerella in the morning [17:35:28] <spaam> good for you [17:37:23] <jrmuizel> DonDiego: thanks [17:39:05] <mru> hmm, he did stop top-posting [17:39:20] <mru> now if he'd also break his long lines [17:43:04] <Compn> diego getting trolled by the lawrence guy [17:44:14] <Compn> jrmuizel : anything in particular bring you here, or are you just along for the ride? [17:44:20] <mru> I find it amusing when people ask a question only to demand a different answer than the they're given [17:47:05] <jrmuizel> Compn: nope, nothing in particular [17:49:08] <BBB> is icc payware? [17:49:17] <BBB> I can't find a free icc download on Intel's website [17:50:22] <cartman> BBB: try google [17:51:03] * Compn googles around [17:51:07] <cartman> BBB: http://software.intel.com/en-us/articles/non-commercial-software-download/ [17:51:27] <Compn> BBB : http://software.intel.com/en-us/articles/intel-software-evaluation-center/ [17:51:34] <Compn> damn, cartman beats me [17:51:35] <cartman> ;) [17:52:29] <BBB> I don't use linux guys, how often do I have to keep fanboying apple? [17:52:51] <cartman> BBB: payware [17:52:52] <mru> no icc for you then [17:52:57] <cartman> torrentware rather [17:53:00] <BBB> nah [17:53:02] <mru> catfree for non-commercial [17:53:03] <BBB> I just won't test it [17:53:06] * cartman got it all [17:53:16] <BBB> it's not like I care [17:53:16] <mru> *cartman: free .. [17:53:20] <BBB> I was just trying to be nice [17:53:27] <kierank> BBB: virtualbox [17:53:31] <cartman> free as in torrentware [17:53:44] <kierank> "you wouldn't download a car" [17:53:44] <mru> no [17:53:53] <cartman> kierank: I would if I could damn it [17:53:59] <iive> I would, if I could. [17:54:07] <mru> intel will give you a non-commercial license for free [17:54:39] <Compn> i would download two, just to have a backup :P [17:54:54] <BBB> download a car [17:54:57] <BBB> that's like dreamland [17:55:03] <iive> Compn: you can download one, then make as many copies as you want :P [17:55:23] <Compn> oh right! [17:55:32] <iive> BBB: give the 3d printer some time to improve :) [17:55:38] <mru> BBB: for some cars you can download firmware to boost the horsepowers [17:55:45] <mru> and void warranty [17:56:21] <Compn> dont you like your car crippled mru ? [17:56:26] <BBB> bsod [17:56:52] <mru> Compn: I don't have a car at all in fact [17:57:03] * elenril wonders if rms will stop using cars now [17:57:16] <mru> here's hoping [17:57:20] * Compn wishes he could go without a car [17:57:21] <kierank> he'll find some piddly car like a reliant robin [17:57:30] <Compn> driving = dangerous :( [17:57:40] <kierank> not as dangerous as riding a motorcycle [17:57:54] <mru> I ride a bike in traffic [17:57:58] <mru> not a motorbike [17:58:35] <kierank> I hate cycling when there are massive lorries about [17:58:39] <Compn> dangerous too, since people who drive cars have some animosity towards bicycles [17:59:04] <mru> there is a simple trick to cycling in traffic [17:59:17] <Compn> swing a crowbar around ? [17:59:21] <mru> keep in the centre of the lane [17:59:33] <mru> if you start creeping along the edges, it gets dangerous [18:00:16] <kierank> and hire a car to carry your belongings behind you like MPs do [18:01:20] <cartman> mru: intel gives free non-commercial licenses for !linux version ? [18:01:39] <mru> cartman: what's wrong with the linux version? [18:01:52] <cartman> mru: nothing [18:02:01] <cartman> if you can get it to run Mac [18:02:51] <Compn> why is intel trying to sell a compiler ? [18:03:02] <Compn> i guess it has optimizations that gcc doesnt have hmm [18:04:47] <BBB> most performance-relevant parts of ffmpeg are written in asm already [18:04:53] <BBB> so we wouldn't really care? [18:04:57] <BBB> (I think) [18:33:46] <pJok> i dont think a compiler would be able to compete with hand optimized assembly code [18:34:20] <mru> pJok: I _know_ it can't [18:34:25] <mru> and so do my clients [18:35:50] <pJok> mru, well, you do optimization for a living, don't you? [18:37:06] <mru> pJok: yes [18:37:28] <pJok> last time i used assembler, it was on a 6510... and it really wasn't that much [18:40:09] <pJok> but at least if you know what you are doing, in any care, you are better than gcc's random code generator [18:43:01] <BBB> I would hope so... [18:43:07] <BBB> gcc is a little funny [19:24:19] <bcoudurier> hey guys\ [19:24:47] <saintdev> hey bcoudurier's onjoin [19:58:17] <Dark_Shikari> first open source AVC-Intra 50 encoder going in today [19:58:20] <Dark_Shikari> now we need a decoder. [19:59:37] <kshishkov> mru: http://c0389161.cdn.cloudfiles.rackspacecloud.com/dyn/str_strip/337170.full… [19:59:41] <Dark_Shikari> I think we should sponsor a 10-bit project for ffh264 [20:00:28] <CIA-63> ffmpeg: janne * r25230 /trunk/ffmpeg.c: [20:00:28] <CIA-63> ffmpeg: use strict_std_complience from avcodec_opts[AVMEDIA_TYPE_*] [20:00:28] <CIA-63> ffmpeg: Options are not yet set for video encoders and for codec specific [20:00:28] <CIA-63> ffmpeg: defaults it is desireable to set the codec options only after the codec [20:00:28] <CIA-63> ffmpeg: is known. [20:08:36] <cartman> is janne on irc? [20:08:56] <mru> jannau: ^^ [20:09:02] <cartman> jannau: Did you mean: compliance ? [20:09:07] <cartman> typo there :-) [20:09:18] <mru> cartman: tab is your friend [20:09:29] <cartman> mru: /me hugs tab [20:10:09] * mru hopes for cartman's sake it's not a bar tab he's hugging [20:10:30] <cartman> :P [20:12:10] <jannau> cartman: fortunately only in the commit message [20:12:27] <cartman> jannau: oh thats not a big damage then :-) [20:53:53] <bcoudurier> shit so hot in LA today [21:00:08] <j-b> shit so cold in Paris today [21:01:51] <cartman> Istanbul was rainy [21:02:27] <mru> fair weather here today [21:02:48] <mru> autumn chill definitely setting in though [21:03:58] <Tjoppen> frost nights here [21:04:11] <mru> but you're in the fucking arctic [21:04:25] <Tjoppen> no water at work today. temporary water hose froze [21:04:40] <mru> where do you live again? [21:04:44] <Tjoppen> umeå [21:05:14] <Tjoppen> they're digging up half the roads and messed up our water pipes. no welder on a week [21:05:22] <Tjoppen> *in [21:08:56] <lu_zero> brr [21:10:17] <lu_zero> here is chilly as well [21:10:36] * mru prefers chilli [21:10:46] <spaam> Tjoppen: any snow yet? D: [21:12:25] <Tjoppen> spaam: not yet [21:14:39] <Tjoppen> time for dexter [21:25:04] <j0sh> it is HOT here [21:25:27] * j0sh just spent 2 hours basking by the pool in 105 degree weather [21:25:40] <mru> where's "here" for you? [21:25:57] <j0sh> LA [21:26:10] <j0sh> well, a bit south (irvine) [21:26:17] <mru> know that place [21:26:21] <j0sh> cool [21:26:32] <mru> I find that area mostly boring [21:26:48] <j0sh> haha irvine is the least exciting place on earth [21:27:05] <mru> costa mesa is no better [21:27:15] <j0sh> s/irvine/orange county [21:27:24] <mru> quite [21:27:27] <j0sh> but its a nice area for the most part [21:27:31] <mru> so why do you live there? [21:27:33] <j0sh> and you cant beat the weather [21:27:43] <j0sh> because i live with my parents [21:27:49] <mru> fair enough [21:28:07] <spaam> j0sh: aww [21:28:13] * mru can't quite imagine living with parents anymore [21:28:40] <j0sh> i just graduated, spent 6 years at school in NY... it is nice to be back home :) [21:28:40] <spaam> mru: better to stay with one of your sisters? ;) [21:29:10] <mru> haven't done that either for a very long time [21:29:24] <mru> I left the damn country 7 years ago [21:29:25] <jannau> is swscale covered by make fate at all? make fate-list is not conclusive [21:29:38] <spaam> mru: damn? pfff its nice ;) [21:29:44] <KotH> eh.. i got an appology out of that itard [21:30:12] <mru> spaam: if you like nanny states, sure [21:30:38] <mru> though that wasn't the reason I left [21:30:48] <mru> it was just how things turned out [21:30:51] <mru> KotH: ? [21:31:41] <KotH> mru: i wrote him a lengthy, not very friendly mail explaining him what he just did [21:31:43] <CIA-63> ffmpeg: bcoudurier * r25231 /trunk/libavcodec/dvdata.c: [21:31:43] <CIA-63> ffmpeg: In dv decoder, use the expected aspect ratio logic, like other decoders do, [21:31:43] <CIA-63> ffmpeg: following width/height = par/dar. [21:31:45] <KotH> mru: and he appologized [21:32:08] <mru> KotH: and you kept the fun to yourself, shame on you [21:32:27] <CIA-63> ffmpeg: bcoudurier * r25232 /trunk/libavcodec/dv.c: In dv decoder, set sample aspect aspect ratio, fix issue #1612 [21:32:28] <mru> jannau: some tests should invoke swscale [21:32:52] <bcoudurier> j0sh, indeed [21:33:00] <mru> e.g. dnxhd tests [21:33:01] <bcoudurier> I'm in santa monica, so hot here too [21:33:29] <KotH> mru: sometimes, it's better to write a pmail than to trampel on other peoples soul in public [21:33:46] <bcoudurier> mru, yeah same here, I've left home 10 years ago now [21:34:16] <mru> KotH: he deserved a public flogging [21:34:53] <jannau> ok, the port to AV_CPU_FLAG_* seems to be not totally broken [21:34:55] <spaam> KotH: tell us about it [21:34:57] <KotH> mru: sure, he deserved it. but wouldnt have acheived what i was aiming at [21:35:06] <BBB> lol @ itard [21:35:06] <KotH> spaam: why should i tell you? [21:35:20] <mru> you already did [21:35:21] <KotH> spaam: you're not even a contributor [21:35:45] <mru> contributory trolling... [21:35:50] <KotH> lol [21:36:20] <spaam> KotH: we are best friends , you and i <3 [21:36:44] <KotH> mru: one kick for calling me best friend please [21:37:18] <j0sh> bcoudurier: is it as hot there as it is here [21:37:25] <KotH> thanks! [21:37:37] <mru> ok, now let's keep this channel sane [21:37:50] <mru> save the kick wars for that other place [21:37:52] <KotH> mru: was this channel ever sane? [21:38:00] <mru> compared to come others, very [21:38:04] <mru> *some [21:38:08] <KotH> hehe :) [21:38:09] <spaam> KotH: <3 [21:38:24] <KotH> anways.. i should be already sleeping for 2h... [21:38:28] <jannau> bah, vsynth1-flashsv is broken and uses swscale. it wasn't earlier [21:38:29] <KotH> good night boys [21:38:36] <spaam> KotH: good night <3 [21:38:39] <jannau> goodnight KotH [21:38:58] <mru> jannau: that uses rgb conversion [21:39:15] <mru> how does it fail? [21:42:39] <jannau> +stddev: 61.85 PSNR: 12.30 MAXDIFF: 156 bytes: 7603200/ 7603200 [21:45:18] <mru> nothing else? [21:46:01] <mru> md5 unchanged? [21:48:13] <jannau> http://pastie.org/1185213 [21:48:37] <mru> so it all changed [21:48:41] <mru> means encoding broke [21:48:57] <CIA-63> ffmpeg: aurel * r25233 /trunk/libavfilter/vf_yadif.c: merge #if with if() [21:49:12] <jannau> it's lukily only the last commit which implements runtime cpu detection with --eanble-runtime-cpudetect [21:49:46] <mru> flashsv encodes rgb, so it seems the yuv to rgb conversion is broken [21:51:21] <CIA-63> ffmpeg: aurel * r25234 /trunk/libavfilter/ (Makefile x86/Makefile x86/yadif.c): use a Makefile in x86 subdir [21:54:20] <jannau> it doesn't like auto detected cpu flags in sws_setColorspaceDetails() [21:55:10] <Dark_Shikari> Los Angeles, California, has broken the all-time record high temperature of 112F with a temperature of 113F at 12:15pm PDT. Their temperature could rise more through the afternoon. [21:55:15] <Dark_Shikari> ffffffffffffffff [21:56:03] <lu_zero> in celsius? [21:56:05] <Dark_Shikari> 45 [21:57:18] <lu_zero> warm enough to kill somebody weak [21:57:27] <mru> solution: don't be weak [21:58:03] <lu_zero> or don't be stupid [21:58:12] <CIA-63> ffmpeg: stefano * r25235 /trunk/libavfilter/ (avfilter.c avfilter.h): [21:58:12] <CIA-63> ffmpeg: Use more expressive names for the avfilter_insert_filter() in and out [21:58:12] <CIA-63> ffmpeg: parameters. [22:01:30] <jannau> found it, hopefully just inconsistant cpu flags between init and the conversion [22:10:47] <CIA-63> ffmpeg: stefano * r25236 /trunk/ (6 files in 2 dirs): Move av_set_options_string() from libavfilter to libavutil. [22:11:32] <CIA-63> ffmpeg: mru * r25237 /trunk/configure: Fix out of tree builds with vf_yadif and mmx [22:14:07] <CIA-63> ffmpeg: stefano * r25238 /trunk/doc/APIchanges: Update APIchanges after r25236. [22:18:49] <CIA-63> ffmpeg: cehoyos * r25239 /trunk/ (libavcodec/avcodec.h libavformat/utils.c libavcodec/parser.c): [22:18:49] <CIA-63> ffmpeg: Fix index_entries pos: [22:18:49] <CIA-63> ffmpeg: It was being set wrong for files with data_offset > 0 [22:18:49] <CIA-63> ffmpeg: Patch by Michael Chinen, mchinen gmail [22:25:06] <twnqx> does ffmpeg support ADX (playstation2 game audio)? [22:25:51] <mru> it supports something it calls adpcm_adx [22:26:05] <mru> described as "SEGA CRI ADX ADPCM" [22:26:06] <twnqx> mh [22:26:18] <mru> ffmpeg -codecs | grep adx [22:26:46] <twnqx> but this 2MB fragment shouldn't really play pretty long, even with 24khz stereo in pcm... [22:29:42] <twnqx> sound_00000_00008.adx: Invalid data found when processing input [22:29:43] <twnqx> hm [22:30:41] <mru> saintdev: ping [22:30:48] <saintdev> mru: sup? [22:30:58] <mru> you've been poking at the aac encoder, right? [22:31:16] <saintdev> very carefully, it bites [22:31:23] <mru> yeah... [22:31:47] <mru> how much work would you say remains to make it usable? [22:33:28] <saintdev> there's a few bugs in channel handling somewhere that need fixed [22:35:05] <saintdev> quantization needs some work, right now on the samples i'm using it ends up using far too many bits for the requested bitrate [22:35:45] <saintdev> that's about all i know of that would be necessary to make it _usable_ in the strict sense of the word [22:36:31] <mru> if someone who knows aac were to work on it, how long before it would compete with faac in quality? compete with good encoers? [22:36:37] <mru> weeks, monts, years? [22:36:44] <saintdev> of course there could be other things peloverde may know of that i don't [22:37:00] <mru> but he's not here... [22:37:08] <saintdev> yeah :/ [22:38:58] <saintdev> to compete with faac, i would probably say a month. [22:39:34] <saintdev> although i'm not familiar with most of the code. really i've only dealt with the psymodel in any detail. [22:42:26] <saintdev> speaking of, i should probably look into the channel issues while i'm waiting to hear something from gabriel [22:52:34] <mru> fate is looking sad... [22:53:02] <saintdev> poor fate, would some ice cream cheer it up? [22:58:17] <Dark_Shikari> gg yadif patch [22:58:59] <lu_zero> Dark_Shikari: is it usable for you now? [23:02:12] <jannau> mru: is there a way to guess the libswscale revision? the date is UTC? [23:02:26] <mru> the last commit broke it [23:10:25] <Dark_Shikari> lu_zero: it doesn't compile [23:11:09] <Dark_Shikari> https://roundup.ffmpeg.org/issue2250 [23:11:09] <Dark_Shikari> lol [23:11:11] <Dark_Shikari> I broke seeking [23:11:18] <Dark_Shikari> why the fuck is mplayer trying to seek to non-keyframes [23:13:35] <twnqx> mhhh [23:13:51] <twnqx> what else is there to try on mpeg-ps other than ffmpeg, mplayer and mediainfo? [23:17:05] <j0sh> jannau: spelling of michael's name [23:17:08] <j0sh> http://git.jannau.net/git/FFmpeg.git.convert/tree/merge_FFmpeg_libswscale_g… [23:28:50] <mru> bcoudurier: ping [23:28:50] <mru> bcoudurier: your swscale commit broke something [23:31:45] <bcoudurier> rah [23:48:00] <bcoudurier> mru, fixed [23:51:38] <lu_zero> bleah installing Xcode takes as much as compiling a gentoo base system... what the hell are they doing!? [23:51:51] <lu_zero> </rant>

1 0

IRC log for 2010-09-26
by irc＠mansr.com 27 Sep '10

27 Sep '10

[00:57:22] <CIA-63> ffmpeg: bcoudurier * r25202 /trunk/libavfilter/vf_yadif.c: [00:57:23] <CIA-63> ffmpeg: In yadif filter, use current frame when previous is missing, [00:57:23] <CIA-63> ffmpeg: better results for the first frame [01:57:46] <CIA-63> ffmpeg: michael * r25203 /trunk/ (4 files in 3 dirs): Fix rv20 encoding so the binary decoder can decode it. [01:57:58] <Dark_Shikari> oh wow. [01:58:03] <Dark_Shikari> I did not see that coming. [01:58:11] <Dark_Shikari> troll-driven development succeeds again [02:24:18] <Compn> how is that troll? [02:24:39] <Compn> carl reported an rv20 bug [02:24:49] <Compn> michael fixed it [02:25:38] <Dark_Shikari> trolling == making rv20 experimental [02:25:42] <Dark_Shikari> solution == fixing it [02:27:03] <Compn> ah, true i suppose [02:28:54] <Compn> i dont see any changes to the muxer [02:29:02] <Compn> so i'm guessing that the vcodec copy is still broken ;\ [05:18:21] <KotH> salve ffmpegians [05:19:20] <johnf> mru: You about? [05:22:13] <johnf> Maybe someone else can help. Not sure if I'm hitting an ffmpeg bug or not. I've got ffmpeg compiled for the an iphone app and am encoding video on the iphone. All working pretty well except I'm getting some pink blocks in the output [06:36:32] <_av500_> hello ffolks [06:40:02] <kshishkov> hello, little guy [08:45:16] <mru> who broke fate this time? [08:47:12] <johnf> mru: I did some more testing on the pink bits problem I was getting yesterday [08:47:20] <Dark_Shikari> mru: test needs to be updated [08:47:32] <johnf> If I configure with --disable-asm the pink bits go away [08:47:48] <mru> Dark_Shikari: so it was michael [08:48:31] <mru> johnf: can you reproduce it using the ffmpeg command line? [08:48:33] <johnf> I tried disabling each of --disable-armv5te --disable-armv6 --disable-armvfp one at a time but none of them seems to make the pink bits disappear [08:48:57] <johnf> mru: this is on the iphone. No command line just the app I'm writing [08:49:17] <johnf> I'm guessing the next step is to manually disable all the different assembly bits to try and work out which one is breaking it [08:49:47] <mru> yes please [08:50:09] <mru> which encoder are you using? [08:50:35] <johnf> mru: FLV but I also tried something else and it didn't seem to make a difference [08:51:18] <Dark_Shikari> they all use mpegvideo [08:51:23] <Dark_Shikari> so I suspect it's a core mpegvideo function [08:51:33] <mru> not all [08:51:42] <mru> e.g. qtrle [08:53:52] <Dark_Shikari> ok, lossy ones. [08:53:53] <Dark_Shikari> =p [08:55:18] <mru> intra-only formats don't use much of mpegvideo either [08:56:06] <kshishkov> mjpeg? [08:56:14] <mru> and all the image formats [08:58:43] <Dark_Shikari> jpeg still goes through mpegvideo [08:58:56] <Dark_Shikari> but yeah, it doesn't use sad, etc [08:58:58] <mru> it doesn't use ME [08:59:45] <johnf> Any hints on the best place to start? [08:59:58] <johnf> I'm going to disable all the asm and then manually turn buts back on [09:00:43] <kshishkov> dct and add/put_pixels are most obvious things to check [09:03:45] <CIA-63> ffmpeg: mru * r25204 /trunk/tests/ref/seek/rv20_rm: Update rv20 seek test reference [09:06:39] <Dark_Shikari> kshishkov: its only in a few blocks [09:06:43] <Dark_Shikari> so I would suspect it's related to mode decision [09:07:47] <kshishkov> Dark_Shikari: I'm an engineer, I'm expected to give theoretical answers even without knowing background [09:09:10] <CIA-63> ffmpeg: reimar * r25205 /trunk/libavcodec/x86/fft_mmx.asm: [09:09:10] <CIA-63> ffmpeg: Split and then simplify address generation macro. [09:09:10] <CIA-63> ffmpeg: Allows nasm to work for this code. [09:16:27] <CIA-63> ffmpeg: reimar * r25206 /trunk/libavcodec/x86/h264_idct.asm: Add d suffix to movd target register to make it work with nasm. [09:21:39] <johnf> Hmm turning bits of asm on and off is a bit tougher than I thought it would be. Has anyone done this before and can give me pointers? [09:23:10] <mru> in libavcodec/arm/ there are some init functions assigning function pointers [09:23:20] <johnf> yes I saw those [09:23:26] <mru> just comment out the assignments to disable them [09:23:36] <johnf> cool, was wondering if I could do that [09:40:26] <johnf> OK I've narrowed it down to ff_put_pixels8_xy2_arm [09:43:00] <johnf> mru: Should I just file a bug or is there something further I can do to debug it [09:56:48] <mru> I can't see anything wrong with that function [10:03:45] <johnf> Do you think the gas-preprocessor.pl could be having some sort of side affect? [10:04:40] <johnf> mru: What should I do next? [10:04:47] <mru> it's unlikely a bug there would only show up in that function [10:05:21] <mru> are you saying it works if you disable just that one function? [10:06:08] <johnf> Let me tripple check [10:12:30] <johnf> mru: OK interesting I didn't notice it before [10:12:40] <johnf> Just commenting out that function the pink blocks go away [10:12:52] <johnf> But now I have what I would call translucent blocks [10:13:18] <johnf> be back in an hour have to go out to dinner [10:24:28] <mru> ah, it is the gas-preprocessor [10:24:31] <mru> Yuvi: ping [10:27:23] * cartman damn iPhoners [11:10:34] <CIA-63> ffmpeg: stefano * r25207 /trunk/libavfilter/vf_yadif.c: Cosmetics: fix style nits. [12:04:46] <mru> johnf: preprocessor fixed: http://github.com/mansr/gas-preprocessor [12:04:58] <mru> not thoroughly tested though [12:26:16] <johnf> mru: That's awesome. Works perfectly now!! [12:26:24] <johnf> Thanks! [12:27:34] <mru> thanks for taking the time to find the broken function [12:27:44] <mru> that was most helpful [12:27:54] <Dark_Shikari> mru: what was the error in gas preprocessor? [12:27:59] <Dark_Shikari> I probably should backport this to x264's copy [12:28:04] <johnf> mru: I don't suppose you are going to OVC or FOMS? [12:28:10] <mru> Dark_Shikari: see above [12:28:18] <mru> johnf: afraid not [12:28:25] <Dark_Shikari> you didn't explain it above [12:28:35] <mru> look at the damn commit [12:28:39] <Dark_Shikari> oh [12:28:49] <Dark_Shikari> tricky [12:29:05] <johnf> mru: shame, would have gotten my partner to buy you a suitable alchoholic beverage :) [12:29:14] <mru> hehe [12:32:10] <mru> another happy customer :-) [12:47:34] <mru> KotH: what's going on, you were out for 40 minutes? [12:48:24] <KotH> accidentally unplugged my router when moving stuff around [13:55:28] <CIA-63> ffmpeg: kostya * r25208 /trunk/libavcodec/ (vc1.c vc1.h): RES_SM in WMV3 is really two flags, so split it in decoder [13:57:39] <CIA-63> ffmpeg: kostya * r25209 /trunk/ (4 files in 2 dirs): Make WMV3 decoder attempt to decode WMVP as well [13:58:22] <kshishkov> if you see BBB, please show this commit to him and ask him to reencode it with xvp8 [13:59:15] <Dark_Shikari> lol [13:59:17] <lu_zero> uh? [13:59:58] <kshishkov> lu_zero: well, somehow he mentions WMVP after I ask him about xvp8 [14:00:13] <Dark_Shikari> good, good, troll-driven development [14:00:24] <mmu_man> ;) [14:00:51] <Dark_Shikari> kshishkov: wait, does this mean we have WVP2 support? [14:00:57] <Dark_Shikari> oh. WMVP9. [14:00:59] <Dark_Shikari> er, WMVP. [14:01:01] <Dark_Shikari> damn. [14:01:12] <kshishkov> WVP2 seems to differ a bit [14:01:18] <Dark_Shikari> what exactly is WVP2? [14:01:35] <kshishkov> the same thing - slideshow encoded in WMV9 [14:01:48] <Dark_Shikari> so how close are you to supporting that? =p [14:02:03] <kshishkov> dunno [14:02:12] <Dark_Shikari> It's the Most Wanted Codec [14:02:27] <kshishkov> preferably dead [14:22:29] <lu_zero> is that ugly? [14:22:40] <lu_zero> rv40 level? [14:23:08] <kshishkov> no, it's totally different codec [14:23:47] <kshishkov> at least in WMVP it's still images and affine transform (with 3x3 matrix) plus fading [14:24:10] <kshishkov> I suspect there is something similar in WVP2 plus additional bells and whistles [14:24:45] <lu_zero> I see [14:25:56] <Compn> kshishkov : did you see there is another screen codec? :P [14:26:14] <Compn> but i've only seen one sample for it so far [14:26:20] <CIA-63> ffmpeg: michael * r25210 /trunk/ (15 files in 4 dirs): Move AVOptions from libavcodec to libavutil [14:26:27] <kshishkov> Compn: have you REd exising ones? [14:26:31] <Compn> no [14:26:48] <Compn> ffmpeg seems to like native screen codecs so far [14:27:07] * Compn still waiting for vivo :P [14:27:19] <kshishkov> what's the name of that screen codec anyway? [14:27:48] <Compn> expression encoder screen codec or so [14:27:55] <Compn> fourcc MTS2 [14:28:20] * kshishkov waits for expletive expressions encoder screen codec [14:28:55] <Compn> err [14:29:06] <Compn> maybe i was thinking MSA1 [14:29:07] <Compn> http://samples.mplayerhq.hu/V-codecs/MSA1.wmv [14:29:20] <Compn> yeah msa1 , not expression, my bad [14:29:33] <Compn> MS ATC screen decoder 1 [14:30:53] * Compn got lost in wmv codecs [14:32:58] <Compn> kshishkov : so what are you working on now? aside from wvp2 [14:38:11] <kshishkov> Compn: dunno [14:47:53] <CIA-63> ffmpeg: mstorsjo * r25211 /trunk/libavcodec/avcodec.h: Bump minor version for the addition of the G.722 encoder [15:26:54] <kshishkov> Compn: the only thing I can say about MSA1 now is that it employs YUV ITU-R variant [15:31:47] <felipec> mru: is uxth always needed between a ldrh and a rev16? [15:32:17] <mru> never [15:32:26] <mru> gcc thinks so [15:32:38] <mru> ldrh zero-extends [15:32:51] <mru> uxth also zero-extends [15:33:52] <felipec> that's what I thought... then AV_RB16 can be optimized [15:34:09] <mru> you mean gcc can be optimised [15:34:14] <mru> that wouldn't be news [15:36:44] <felipec> yeah, AV_RB16 can be optimized further for gcc [15:36:53] <mru> I'm not so sure [15:37:04] <mru> it's hard to stop gcc fucking up [15:37:12] <mru> I'm not putting any uxth in there [15:37:14] <mru> gcc does that [17:55:47] <CIA-63> libswscale: ramiro * r32360 /trunk/libswscale/utils.c: swscale: use full chroma input for point scaler [18:00:11] <cartman> x86/fft_mmx.asm:49: warning: section flags ignored on section redeclaration [18:00:14] <cartman> x86/fft_mmx.asm:74: warning: section flags ignored on section redeclaration [18:00:17] <cartman> possibly for BBB [18:01:06] <mru> better than libavfilter/x86/yadif.c:222: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' [18:03:14] <cartman> mru: thats so 32bit of you [18:03:44] <kshishkov> cartman: that's so GCC for you [18:03:51] <cartman> kshishkov: clang [18:03:52] <cartman> ;> [18:03:59] <cartman> but possibly gas yes [18:04:24] <cartman> I wrote my first inline asm btw \o/ [18:04:30] <cartman> wonder if the hell is frozen :P [18:05:01] <kshishkov> of course not [18:05:06] <cartman> :/ [18:07:00] <mru> that's gcc on osx [18:07:02] <mru> 32-bit [18:07:22] <kshishkov> that can be GCC anywhere on 32-bit [18:07:27] <cartman> yup [18:07:36] * cartman spills some registers [18:07:37] <kshishkov> (32-bit x86 only) [19:08:53] <Compn> kshishkov : do we have samples for fourcc WMVR / WMVB ? [19:09:07] <Compn> or were those from a spec ? [19:09:19] * Compn reading vc-1 wiki page [19:09:24] <kshishkov> from driver IIRC [19:10:08] <kshishkov> and I don't think there'll be problems decoding those anyway [19:10:39] <Compn> ah [19:10:51] * Compn trying to compile list of known codecs stored in wmv [19:11:40] <kshishkov> it's easy. Two words: M$ crap [19:12:28] <Compn> haha [19:15:08] <Compn> oh that expression codec was a screen codec too. [19:15:15] * Compn wonders where he put the sample [19:17:04] * kshishkov thinks it's easier and a bit better to finish Indeo family. Now to find someone to do that [19:17:45] <cartman> find-indeo-coder.py [19:18:08] * kshishkov does not believe in Python [19:18:21] * cartman belives in f00d [19:18:40] * kshishkov just knows food exists [19:19:07] <mru> kshishkov: you look like you've seen some... [19:19:58] <kshishkov> mru: yes, I admit that I had close encounter with food [19:20:12] <mru> and the food lost [19:20:14] * elenril labels kshishkov as a heretic [19:20:14] * Compn eats a bell pepper [19:20:18] <kshishkov> and it didn't survive it it some cases, yes [19:34:42] <CIA-63> libswscale: michael * r32368 /trunk/libswscale/ (swscale.h utils.c): [19:34:43] <CIA-63> libswscale: Split alloc and init of context so that parameters can be set in the context [19:34:43] <CIA-63> libswscale: instead of requireing being passed through function parameters. This also [19:34:43] <CIA-63> libswscale: makes sws work with AVOptions. [19:35:48] <Dark_Shikari> whoa. is that an api change? [19:36:06] <mru> one would hope he left a compat wrapper [19:36:37] <cartman> ah so current sws howtos became obsolute once agaib [19:36:42] <cartman> s/b/n [19:37:37] <mru> yes, there is a wrapper [19:38:29] <mru> this is one (small) step towards swscale sanity [19:38:36] <mru> do not complain about it [19:38:49] <Dark_Shikari> lol [19:38:50] <Dark_Shikari> +1 [19:40:17] <cartman> that will be another ifdef sir [19:42:13] <lu_zero> \o/ [19:55:36] <Dark_Shikari> wow. we really trolled michael into making swscale better. [19:55:46] <Dark_Shikari> another commit went in as well [19:56:06] <Dark_Shikari> I guess when we say "we're reimplenting X in x264, because swscale doesn't do X", he starts getting annoyed [19:56:10] <mru> it has a long way to go [19:56:13] <Dark_Shikari> oh yes [19:56:23] <Dark_Shikari> And I wonder how long it'll be until he implements a dither algorithm that isn't ordered dither [19:56:30] <mru> like the insane ifdef hell around the asm [19:56:35] <Dark_Shikari> we used error diffusion in x264's [19:56:50] <cartman> He doesn't want an ffmpeg work, thats it [19:56:55] <mru> ordered dithering is almost uglier than none at all [19:58:07] <lu_zero> Dark_Shikari: would you donate it to swscale? ^^ [19:58:48] <Dark_Shikari> lu_zero: it's trivial and a dozen lines [20:00:54] <lu_zero> Dark_Shikari: and that would make michael either accept it or write yet another that he likes [20:07:14] * lu_zero waits get his mailbox back... [20:22:06] <mru> hmm, something's weird with nasm [20:37:34] <cartman> mru: yes dylib [20:38:06] <lu_zero> wbs: could you please resend me the reorder patchset? [20:39:16] <wbs> lu_zero: sure [20:40:37] <DonDiego> yasm question: is config.asm required/essential? [20:40:54] <DonDiego> mplayer's configure does not create it, but compilation seems to work fine.. [20:40:54] <mru> of course [20:40:58] <mru> it wouldn't be there otherwise [20:40:58] * lu_zero had to wipe his mailbox [20:41:16] <DonDiego> i wonder how mplayer ever compiled yasm then.. [20:41:27] <mru> it's a rather new addition [20:42:22] <mru> BBB requested it [20:42:29] <mru> not sure what it's used for [20:42:56] <mru> it sets the ARCH_ macros of course [20:43:13] <mru> iirc BBB wanted to use some other config flags for something [20:43:20] <mru> doesn't look like he got round to it yet [20:44:42] <DonDiego> so no part is used (yet)? [20:44:53] <mru> the ARCH_ macros are [20:45:00] <DonDiego> ah, ok [20:45:13] <DonDiego> more stuff i need to port to mplayer.. [20:45:15] <mru> they were duplicated somewhere else before [20:45:21] <DonDiego> *sigh*, this has to end.. [20:45:26] * DonDiego is working on it.. [20:45:48] <mru> you could stop trying to replicate half of the ffmpeg build system and use the real thing directly [20:45:58] <DonDiego> this is what i'm working on [20:46:03] <mru> good [20:46:05] <mru> for you [20:46:29] <DonDiego> if i don't finish this soon i will surely go insane.. [20:49:14] <CIA-63> libswscale: michael * r32369 /trunk/libswscale/options.c: Make the avoptions list of sws more complete. [20:49:14] <CIA-63> libswscale: ramiro * r32370 /trunk/libswscale/swscale.h: fix typos and grammar [20:50:27] <lu_zero> DonDiego: need an hand on that? [20:53:39] <DonDiego> as many as you can give me.. [20:54:05] <DonDiego> but actually, right now i think we would only step on each other's toes [20:54:24] <DonDiego> lu_zero: how about finishing the libmpeg2 stuff? [20:54:38] <DonDiego> that would be a welcome thing in mplayer and nobody else will do it :) [20:55:00] <mru> > as many as you can give me.. [20:55:05] <mru> you need a hindu god [20:55:55] <lu_zero> DonDiego: the libmpeg2 stuff... [20:56:20] <lu_zero> finish in the good way -> (expose the quant bits from ffmpeg) [20:56:34] <DonDiego> you mean from libmpeg2? [20:56:51] <lu_zero> or finish in the dirty way (make our copy the new libmpeg2 release) [20:57:00] <mru> hehe [20:57:17] <DonDiego> choose your poison.. [20:57:20] <lu_zero> since from what we discussed to do postproc we need those value [20:57:22] <lu_zero> s [20:57:40] <lu_zero> and there isn't a nicer interface for them [20:57:48] <pJok> what? swscale is getting fixed? [20:57:48] <DonDiego> somebody just needs to sit down and do it [20:58:05] <lu_zero> still I'd like to know better what's needed and how's used [20:58:14] <DonDiego> lu_zero: i see nobody except you step forward.. [20:59:21] * lu_zero chopped ffmpeg configure few times to see what could be reused with ease [21:02:14] <CIA-63> ffmpeg: mru * r25212 /trunk/libavutil/arm/intreadwrite.h: [21:02:14] <CIA-63> ffmpeg: ARM: change return type of AV_RN16() to unsigned [21:02:14] <CIA-63> ffmpeg: This prevents gcc inserting useless UXTH instructions, at least [21:02:14] <CIA-63> ffmpeg: in some cases. [21:02:14] <CIA-63> ffmpeg: mru * r25213 /trunk/configure: configure: detect nasm vs yasm and set flags correspondingly [21:05:01] <DonDiego> lu_zero: i'm currently whittling mplayer's configure into shape by simplifying all tests as far as possible [21:05:25] <DonDiego> i want all the hidden knowledge there to become explicit [21:06:06] <DonDiego> some checks are unnecessarily complex, others are complex for a good reason, the latter should be explicit about it, the former should be simplified [21:07:24] <Kovensky> some are overly simple [21:07:40] <Kovensky> I remember seeing a few checks that only checked for headers but didn't check for linking of functions [21:08:10] <Kovensky> so it could approve some random library that has headers present but no libraries or the libraries are of the wrong architecture / system [21:16:00] <DonDiego> i think it's ok to be optimistic until we stumble over a broken system that does not work with these assumptions [21:18:49] <Kovensky> which is very easy to find on multilib systems [21:18:53] <Kovensky> or cross-compiling ones [21:20:01] <mru> especially ones with deceptive pkgconfigs [21:20:32] <DonDiego> as i said, i'm open to fixes as soon as such systems appear [21:20:46] <DonDiego> but i don't see mplayer's configure failing left and right.. [21:21:21] * Kovensky has a bunch of workarounds by using --enable/disable-libWhatever and --extra-libs [21:21:24] <DonDiego> btw, anybody seen monty's video podcast? [21:21:42] <spaam> url? [21:21:48] <DonDiego> Kovensky: patches welcome.. [21:22:42] <mru> DonDiego: how full of lies is it? [21:24:02] <DonDiego> it's good, go watch it.. [21:24:13] <DonDiego> it's just about the basics [21:24:19] <DonDiego> but it's well-explained [21:24:35] <mru> I know the basics [21:24:38] <DonDiego> supposedly it's the first in a series [21:24:44] <spaam> Monty aka michael widenius ? [21:24:49] <DonDiego> no [21:24:56] <mru> not that monty [21:24:58] <mru> nor python [21:25:14] <spaam> ok :) [21:25:16] <DonDiego> michael 'monty' montgomery [21:25:19] <spaam> DonDiego: url for it ? [21:25:21] <DonDiego> xiphmont [21:26:04] * Kovensky should watch monty python stuff [21:26:21] <DonDiego> http://xiph.org/video/vid1.shtml [21:26:59] <DonDiego> mru: still i guess you can appreciate the quality or approachability of an explanation.. [21:27:27] <mru> if it doesn't teach me anything, I'd be wasting my time [21:27:42] <mru> I hate videos [21:29:01] <DonDiego> the video part is used very well to teach the concepts [21:29:14] <DonDiego> maybe you are curious to see what monty looks like.. [21:29:21] <mru> I've seen pictures [21:29:30] <DonDiego> anyway, back to work.. [21:30:42] <lu_zero> wbs: why !first_queue_time in @@ -1817,6 +1820,22 @@ static int rtsp_fetch_packet(AVFormatContext *s, AVPacket *pkt) [21:32:34] <wbs> lu_zero: since first_queue_time is initialized to 0.. I guess that part could be skipped if using INT64_MAX or something instead [21:36:59] <CIA-63> ffmpeg: stefano * r25214 /trunk/ (7 files in 3 dirs): [21:36:59] <CIA-63> ffmpeg: Port MPlayer blackframe filter. [21:36:59] <CIA-63> ffmpeg: See thread: [21:36:59] <CIA-63> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Port MPlayer blackframe filter. [21:36:59] <CIA-63> ffmpeg: Date: Sun, 26 Sep 2010 01:10:40 +0200 [21:37:07] <lu_zero> interesting [21:37:41] <DonDiego> lu_zero: do you think you will be able to get to libmpeg2 some time soon? [21:37:54] <lu_zero> uhmmm [21:38:08] <lu_zero> as soon within a month, probably [21:38:52] <DonDiego> cool :) [21:39:42] <lu_zero> IFF I survive ^^; [21:40:07] * lu_zero watched some bits of the webm video of the lesson [21:40:26] <lu_zero> I must say that the handwritten slides are great [21:42:35] <lu_zero> wbs: maybe queue_time != first_queue_time && queue_time - first_queue_time < 0 [21:42:52] <DonDiego> lu_zero: yes, i agree, audio, video and the slides are used very well [21:43:31] <lu_zero> DonDiego: those kind of stuff help spreading mindshare [21:43:40] <lu_zero> we _should_ to that as well =P [21:43:40] <DonDiego> totally [21:43:51] <DonDiego> ah, we should do so many things.. [21:44:00] <DonDiego> we seem to get stuck on hacking code.. [21:44:19] * lu_zero imagines mru with a troll dress teaching asm [21:44:34] <wbs> lu_zero: uhm, that wouldn't work if one stream doesn't have any queue at all (returning queue_time = 0, and first_queue_time already is set) [21:45:22] <lu_zero> ok [21:45:56] <lu_zero> I'm not exactly happy with memmove btw [21:46:32] <wbs> well, it isn't much data, it's just the "metadata", the actual payload data is behind pointers [21:47:20] <wbs> sure it could be a linked list, too.. [21:50:35] <lu_zero> I wonder if we could also spare the memcpy [21:51:31] <wbs> that requires changes at quite many levels, it's a local buffer owned by the rtsp level (and reused on each received packet) [21:51:47] <wbs> so you can't just fix it by handing over ownership of the pointer to rtpdec [21:55:02] <bruceber> Sorry to interrupt, but if anyone familiar with multithreading of libavformat would mind checking out my recent question in #ffmpeg it would be greatly appreciated! [21:56:51] <lu_zero> bruceber: did you have a look at ffmpeg-mt? [22:38:35] <astrange> doesn't touch libavformat [22:38:40] <CIA-63> ffmpeg: mru * r25215 /trunk/libavfilter/vf_yadif.c: yadif: remove unnecessary #include [23:31:11] <lu_zero> astrange: ah

1 0

IRC log for 2010-09-25
by irc＠mansr.com 26 Sep '10

26 Sep '10

[01:19:33] <CIA-63> ffmpeg: stefano * r25185 /trunk/ (5 files in 4 dirs): Make the crop filters accept parametric expressions. [01:32:51] <CIA-63> ffmpeg: stefano * r25186 /trunk/cmdutils.c: [01:32:51] <CIA-63> ffmpeg: Add more missing checks in opt_default(), prevent a crash if [01:32:51] <CIA-63> ffmpeg: avcodec_opts[0] or avformat_opts is not set. [01:32:51] <CIA-63> ffmpeg: stefano * r25187 /trunk/ (ffprobe.c Changelog): Make ffprobe able to set AVFormatContext options. [01:57:51] <CIA-63> ffmpeg: stefano * r25188 /trunk/ (5 files in 2 dirs): [01:57:51] <CIA-63> ffmpeg: Add asrc_anullsrc - null audio source. [01:57:51] <CIA-63> ffmpeg: Based on a patch by "S.N. Hemanth Meenakshisundaram" smeenaks!ucsd!edu. [01:57:51] <CIA-63> ffmpeg: stefano * r25189 /trunk/ (5 files in 2 dirs): [01:57:52] <CIA-63> ffmpeg: Add asink_anullsink - null audio sink. [01:57:52] <CIA-63> ffmpeg: Patch by "S.N. Hemanth Meenakshisundaram" /smeenaks/ucsd/edu. [05:49:40] <ohsix> anyone know a nit about lattice wave digital filters [05:56:30] <_av500_> hmm [06:02:04] <bcoudurier> hey folks [06:08:13] <_av500_> ohsix: http://focus.ti.com/lit/an/slaa331/slaa331.pdf [06:12:05] <ohsix> oh nice; the article i was reading that used them probably derived the stuff from that; the project was also on an msp430 [06:15:33] <KotH> <accent type=asuka>guten morgen!</accent> [07:03:31] <bcoudurier> hey KotH [07:12:04] <Dark_Shikari> whoa. michael approved my hacky patch [07:12:12] <Dark_Shikari> (with being changed to use av_image_copy) [07:13:36] <elenril> yaifications, troll-driven development! [07:21:45] <Dark_Shikari> mru: NICE trolling [07:21:46] <Dark_Shikari> lmao [08:18:27] <lu_zero> bcoudurier: still there is the problem with multiple output ^^; [08:20:19] * lu_zero needs a faster mail client =_= [08:25:26] <lu_zero> hi saste [08:26:34] <saste> hi [08:45:38] <CIA-63> ffmpeg: reimar * r25190 /trunk/libavcodec/rawdec.c: [08:45:38] <CIA-63> ffmpeg: rawdec: ensure that there is always a valid palette for formats that [08:45:38] <CIA-63> ffmpeg: should have one like gray8 etc. [08:49:39] <ohsix> http://wiki.xiph.org/File:Dmpfg_006.jpg huhuuh [09:02:00] <Dark_Shikari> mru: <3 your email on fate [09:02:11] <Dark_Shikari> only just saw it, since it was bumped [09:58:55] <CIA-63> ffmpeg: stefano * r25191 /trunk/doc/filters.texi: Slightly clarify expression in for the anullsrc source documentation. [10:17:08] <CIA-63> ffmpeg: stefano * r25192 /trunk/doc/protocols.texi: [10:17:09] <CIA-63> ffmpeg: Document udp protocol. [10:17:09] <CIA-63> ffmpeg: Based on a patch by Aviad Rozenhek aviadr1 @ reverse(moc.liamg). [10:22:21] <elenril> o_0 ffmpeg compiled with clang is ~10% faster [10:22:27] * elenril wonders if he's doing something wrong [10:23:03] <mru> like using gcc? [10:23:20] <elenril> but srsly - 10% [10:23:28] <kshishkov> there was similar case with icc - it just miscompiled ffmpeg though [10:23:42] <mru> elenril: 10% faster when doing what? [10:23:47] <elenril> decoding h264 [10:23:48] <Dark_Shikari> crashing [10:23:54] <Dark_Shikari> isn't icc broken on h264 decode? [10:24:07] <mru> no [10:24:19] <mru> I've seen gcc regress 25% from one version to the next [10:24:27] <mru> Dark_Shikari: fate says icc is fine with h264 [10:25:02] <Dark_Shikari> it was broken a while back [10:25:06] <Dark_Shikari> when mike did his last compiler comparison [10:25:12] <mru> that was 2 e [10:25:14] <mru> years ago [10:25:33] <mru> now it fails atrac3 on 32-bit and sipr on 64-bit [10:26:20] * elenril tries gcc 4.3 [10:26:33] <mru> what were you using? [10:26:39] <mru> 4.4 is pure shit [10:26:46] <elenril> 4.4.5 [10:26:55] <mru> that's probably why ubuntu ships it [10:27:07] <mru> 4.4.5? [10:27:10] <mru> there is no such version [10:27:22] <elenril> gcc -v says [10:27:28] <elenril> gcc version 4.4.5 20100728 (prerelease) (Debian 4.4.4-8) [10:27:40] <elenril> whatever that means [10:27:50] <mru> it means debian changed the version [10:28:38] <kshishkov> official gcc 2.96 FTW [10:29:06] <cartman> king of the miscompilers [10:30:18] <kshishkov> and IIRC it was just a hack from RedHat for supporting Itanic with breaking some other things [10:30:32] <mru> s/some/all/ [10:30:57] <kshishkov> well, it could print version [10:31:55] <cartman> that was about it :> [10:32:16] <elenril> hm, you're right, 4.3 is as fast as clang [10:32:44] <mru> 4.5 is better than 4.4 too [10:32:47] <mru> about like 4.3 [10:33:24] <kshishkov> and 4.6 is expected to achieve new level of suckyness [10:34:11] <mru> gcc major/minor versions must have odd parity [10:34:14] <mru> 2.95 was good [10:34:16] <Dark_Shikari> Oh, true [10:34:17] <mru> 3.4 was good [10:34:25] <Dark_Shikari> Yeah, the parity of 4.6 is wrong [10:34:25] <mru> 4.3 is good [10:34:35] <mru> 4.1 wasn't all that great [10:34:45] <Dark_Shikari> yeah, but every few versions following a major bump always suck [10:34:52] <mru> but minor <3 always sucks too [10:35:12] <cartman> 4.2 was buggy [10:35:17] <Dark_Shikari> gcc is buggy [10:35:35] <cartman> buggy as in miscompiling should-be-obviously-tested stuff [10:35:45] <mru> 4.3 too [10:35:46] <cartman> it even miscompiled kernel at some point [10:35:58] <elenril> Dark_Shikari: http://m.xkcd.com/703/ [10:44:56] <saste> hi [10:45:09] <saste> where can I find a mapping between MPlayer IMGFMT and PIX_FMT? [10:45:25] <saste> I need it because I'm trying to port a linmpcodecs filter [10:47:00] <kshishkov> it's somewhere in mplayer sources obviously [10:47:16] <kshishkov> and names are similar anyway [10:47:58] <saste> IMGFMT_I420? [10:48:08] <saste> I suppose the I stands for Interlaced right? [10:48:31] <iive> no [10:49:03] <Dark_Shikari> I420 is YV12 with swapped u/v planes [10:49:23] <saste> I already grepped the sources for some mapping and I can't find a file defining them like e.g. in pixfmt.h [10:49:46] <kshishkov> that should hint you of general MPlayer code quality [10:50:01] <saste> YV12 = NV12 ? [10:50:10] * iive facepalms [10:50:20] <kshishkov> nope [10:50:28] <kshishkov> YV12 = YUV420 [10:50:41] <kshishkov> NV12 is separate format [10:50:57] <kshishkov> read mplayer/docs/tech/colorspace.txt first [10:51:04] <saste> kshishkov: thanks [10:54:07] <mru> they're both 4:2:0 [10:54:22] <kshishkov> format = packing as well [10:54:23] <mru> nv12 has interleaved u and v pixels [10:54:46] <mru> 4:2:0 says nothing about memory layout [10:54:51] <mru> only subsampling [10:55:20] <kshishkov> yes, but it's usually implied [10:55:52] <mru> not when I'm speaking [10:56:07] <kshishkov> yes, you're master to your words [10:56:25] <mru> if I say yv12, I mean a planar 420 format [10:56:36] <mru> if I say nv12, I mean a semiplanar one [10:57:05] <mru> if I say 420 I mean an unspecified format with subsampled u/v [10:57:05] <kshishkov> and you don't say yuyv ever [10:57:18] <mru> if I did, it would be obvious what I meant [11:00:31] <iive> saste: try with "pixfmt2imgfmt" [11:01:06] <kshishkov> mru: at least MPlayer did good job with swapping RGB and BGR definitions [11:02:16] <mru> mplayer did the usual mistake of trying to shoehorn everything into a "fourcc" system [11:02:23] <iive> kshishkov: i think that the file you pointed above, explains that mplayer uses same definition as opengl, that is kind of "standard". [11:03:59] <kshishkov> mru: well, you know its history [11:04:11] <mru> it started life as an avi player [11:04:19] <mru> everything else was duct-taped on later [11:04:33] <mru> and somewhere along the way, they ran out of tape [11:04:38] <kshishkov> wasn't it avi player with duct-taped mpeg player? [13:43:09] <CIA-63> ffmpeg: stefano * r25193 /trunk/libavfilter/vf_crop.c: [13:43:09] <CIA-63> ffmpeg: Fix memleak introduced in: [13:43:09] <CIA-63> ffmpeg: r25185 | stefano | 2010-09-25 03:18:43 +0200 (Sat, 25 Sep 2010) | 1 line [13:43:09] <CIA-63> ffmpeg: Make the crop filters accept parametric expressions. [13:54:23] <CIA-63> ffmpeg: stefano * r25194 /trunk/libavfilter/vf_crop.c: [13:54:23] <CIA-63> ffmpeg: Prefix enum var_name symbols with VAR_, to avoid conflicts with already [13:54:23] <CIA-63> ffmpeg: defined symbols, in particular should fix compilation in DOS. [13:55:06] <mru> I can't but wonder if there's really anyone using ffmpeg on dos [13:59:51] <_av500_> i wonder that for 50% of the supported archs [14:00:41] <_av500_> and compilers [14:00:41] <mru> we got a bug report on blackfin once [14:01:20] <_av500_> i bet there are more blackfin than dos users [14:01:38] <kierank> iirc there are more vlc users on windows 95 than on linux so there must be quite a few ffmpeg dos users [14:02:25] <_av500_> kierank: for vlc, not a surprise [14:02:25] <spaam> source? [14:02:34] <mru> there is an advantage to testing on obscure systems even if nobody uses them [14:02:41] <_av500_> mru: agreed [14:02:52] <_av500_> it forces you to keep code clean [14:03:09] <mru> bugs have often shown up first on something strange [14:03:13] <mru> like sparc/bsd [14:03:42] <_av500_> bsd = bug special detector? [14:04:54] <mru> supporting weird things also provides some leverage when we insist that some system is broken [14:14:05] * Compn grumbles something about at least being able to see the fourcc/isom/riff tags all in one file instead of spread out in 20 different demuxers [14:14:36] <mru> the tags are format-specific [14:14:47] <mru> they belong in each (de)muxer [14:14:47] <Compn> i know [14:15:06] <Compn> i'm just grumbling [14:16:27] <Compn> maybe at the next con, ffmpeg should ask if anyone uses dos / win95 [14:16:28] <Compn> ehe [14:23:42] <kierank> does ffmpeg build on gnu hurd? [14:24:06] <mru> does gnu hurd? [14:24:15] <kierank> dunno, ask rms [14:25:11] <mru> if you look at the systems we support, you'll see that they are all real system that have or have had widespread use [14:25:27] <mru> we don't really try to support vapourware [14:38:50] <CIA-63> ffmpeg: banan * r25195 /trunk/libavcodec/imgconvert.c: [14:38:50] <CIA-63> ffmpeg: Support deinterlacing of YUVJ422P in old deinterlacer. [14:38:50] <CIA-63> ffmpeg: Patch by Maksym Veremeyenko verem at m1stereo tv. [15:25:24] <pJok> mru, HURD is too old to be vapourware... [15:25:43] <mru> vapour gone, only vacuum left? [15:26:04] <pJok> yes [15:46:41] <lu_zero> mru: I think ffmpeg builds just fine on hurd [15:47:10] <lu_zero> (and probably we could add a minix) [15:47:21] <lu_zero> the question might be _which_ hurd [15:47:58] <lu_zero> since last time I tried to boot it I guess it got rewrote 3-4 times [15:48:50] <pJok> lu_zero, debian gnu/hurd might be a good choice? gentoo dropped their hurd development at least... [15:49:26] <lu_zero> pJok: eh... [15:49:40] * lu_zero wanted a gentoo/minix [15:49:41] * kshishkov waits for Duke Nukem Forever port to Hurd [15:49:52] <lu_zero> kshishkov: so ... 10 years? [15:50:08] <pJok> kshishkov, sadly Duke Nukem Forever actually seems to have a proper release schedule now... [15:50:13] <kshishkov> lu_zero: 10 years from _any_ point in time [15:50:30] <pJok> kshishkov, so just like the 30 years that fusion power is away from us? [15:50:30] <lu_zero> kshishkov: =) [15:50:43] <kshishkov> lu_zero: do you want gentoo/dos with your gentoo/minix? [15:50:56] <lu_zero> kshishkov: already there I'm afraid... [15:51:17] * kshishkov does not consider Minix to be proper OS (since it's for educational purposes only) [15:51:24] <lu_zero> kshishkov: ehm [15:51:28] <lu_zero> BAD student [15:51:41] <lu_zero> minix3 apparently is a general purpose os [15:51:51] <lu_zero> and got LOTS of founds from EU [15:56:05] <lu_zero> at least that's what I got by listening to the author ^^ [15:56:33] <lu_zero> wbs: you around? [16:00:29] <mru> govt/eu funded _and_ educational... no way that can be good [16:01:02] <mru> btw gentoo is pretty much kernel-agnostic [16:14:01] <kshishkov> hmm, looks like that Minix3 is still something not intended for real life [16:14:19] <mru> of course not [16:14:21] <mru> linux is [16:14:27] <mru> and that's why tanenbaum is so angry [16:16:38] <kshishkov> still? after almost 20 years? [16:16:52] <mru> maybe he calmed down [16:19:22] * kshishkov tries to imagine FFmpeg with microkernel architecture [16:21:08] <pJok> ffOS? [16:21:53] <pJok> chances of that happening is still greater than HURD being a useable OS [16:22:27] <kshishkov> GNU is Not Usable [16:22:54] <kierank> [17:00] <@mru> govt/eu funded _and_ educational... no way that can be good --> like p2p-next [16:34:59] <lu_zero> p2p-next? [16:35:20] <lu_zero> kshishkov: btw why microkernel? [16:36:19] <kshishkov> lu_zero: looks like microkernel and ability to restart drivers are the main hype points of minix3, so I wonder what would happen to FFmpeg if it was designed that way [16:36:46] * iive looks at gstreamer [16:39:31] <lu_zero> kshishkov: the hype point were about being really small and with almost no bug in the foundation [16:39:46] <lu_zero> (embedded/industrial usage) [16:40:09] * kshishkov wonders why industry prefers QMX instead [16:40:12] <kshishkov> *QNX [16:40:19] <mru> because it works [16:40:27] <lu_zero> kshishkov: because exists since ages [16:40:28] <kshishkov> lame excuse IMO [16:40:57] <kshishkov> lu_zero: would you use ITS or Multics? [16:44:35] <CIA-63> ffmpeg: michael * r25196 /trunk/ (8 files in 4 dirs): [16:44:35] <CIA-63> ffmpeg: yadif filter, based on stefanos port of my yadif from mplayer. [16:44:35] <CIA-63> ffmpeg: Compared to stefanos, 2 frame output works with ffplay. [16:47:35] <mru> fuck [16:47:40] <mru> now I have to fix that mess [16:47:59] <kshishkov> nope, just complain [16:48:06] <mru> no point [16:48:11] <mru> nobody else will fix it [16:50:10] <kshishkov> "FIXME change API to not require this red tape" [16:50:14] <kshishkov> sounds ominous [16:50:49] <mru> where? [16:51:01] <kshishkov> libavfilter/vf_yadif.c [16:55:07] <J_Darnley> Wow, look at how red fate is now. [16:55:11] <CIA-63> ffmpeg: michael * r25197 /trunk/libavfilter/vf_yadif.c: Fix 0 vs 1 porting bug from mplayer. [17:04:21] <CIA-63> ffmpeg: stefano * r25198 /trunk/ (libavfilter/avfilter.h Changelog): Bump lavfi minor and add Changelog notice after yadif addition. [17:10:08] <CIA-63> ffmpeg: michael * r25199 /trunk/libavfilter/Makefile: Stefanos port was missing DIRS variable in the Makefile for the newly added x86 [17:10:29] <merbanan> well fate works [17:10:39] <mru> good job michael [17:10:49] <mru> this is why I insist on reviewing things [17:11:36] <mru> and that fix is wrong too [17:12:26] * cartman ponders running fate [17:14:27] <CIA-63> ffmpeg: mru * r25200 /trunk/configure: Create libavfilter/$arch when building outside source tree [17:15:26] <cartman> lol lol lol [17:15:35] <cartman> thedailywtf adobe screenshot is coming [17:18:42] <cartman> http://img210.imageshack.us/img210/1396/screenshot20100925at816.png [17:18:46] <cartman> lamest thing ever [17:18:47] <saste> DonDiego: website documentation is not updated since 26 August 2010 [17:23:08] <kshishkov> cartman: actually that should be aproblem only on Linux. Looks like they really hate it [17:23:29] <cartman> kshishkov: indeed, I had to manually format to get case-sensitive HFS+ [17:27:41] <jannau> mru: how do you refresh the ffmpeg git tree on git.mansr.com? cronjob or something triggered by commit? [17:28:00] <mru> triggered by commit email [17:30:43] <kshishkov> mru: will make still create dependency in libavfilter/x86 even for ppc/arm/other non-x86? [17:31:02] <mru> eh? [17:31:23] <kshishkov> I mean that DIRS addition by michael [17:31:59] <mru> that's only used in make clean [17:34:06] <jannau> thanks, http://git.jannau.net/git/FFmpeg.swscale/ will be updated every 30 until I have time to reroute emails to that server [17:34:56] <lu_zero> uhm [17:35:12] <lu_zero> do we have a container for raw audio and raw video? [17:35:50] * lu_zero tried nut with strange results, but possibly the bug is somewhere else [17:35:58] <mru> nut is strange [17:36:27] <lu_zero> mov pukes with a segfault uhmmm [17:37:21] <kshishkov> acute apple poisoning? [18:25:20] <felipec> are other bitstream readers really used? [18:26:07] <kshishkov> because rectangle [18:26:56] <kshishkov> please tell me more about the one bitstream reader everyone presumably uses [18:28:30] <_av500_> lu_zero: .avi :) [18:33:37] <kshishkov> _av500_: that's still not a reason not to support nut+Snow in Archos players [18:34:00] <_av500_> kshishkov: right, will enable it [18:34:15] <_av500_> i have a wrapper layer for lavf anyway [18:34:54] <_av500_> kshishkov: what is the IP situation on our favorite codec? [18:35:18] <kshishkov> _av500_: the same as on other codecs - nobody cares [18:36:41] <_av500_> sadly, ppl care, there is a court in marshall texas to prove it :( [18:38:16] <kshishkov> _av500_: well, that court will accept any patent [18:39:20] <lu_zero> _av500_: snow <- if dirac is ok so is snow [18:40:28] <lu_zero> curiously avi doesn't misbehave as mov [18:40:38] <lu_zero> still I'm doing something wrong [19:30:29] <felipec> why does the bitstream reader do things like: unsigned index = s->index; index++; s->index = index; [19:31:02] <mru> where does it do that? [19:32:06] <felipec> mru: get_bits1 for example [19:32:19] <mru> do you have a problem with that? [19:33:06] <felipec> mru: no, I was just wondering if it was convenience or some ninja compiler trick [19:33:26] <mru> that's what you get after macro expansion, right? [19:33:27] <roxfan> what type is s->index? [19:33:39] <mru> roxfan: int or unsigned int [19:34:46] <mru> copying struct fields into local variables can improve performance [19:35:03] <mru> if you don't, the compiler assumes the bit buffer might overlap the struct [19:35:18] <mru> which forces it to reread stuff [19:35:26] <mru> aliasing is so much fun [20:01:07] <lu_zero> ok [20:01:17] <lu_zero> output-example looks wrong. [20:02:37] <mru> no really? [20:05:54] <lu_zero> mru: =P [20:06:24] * kshishkov prepares to cite lu_zero [20:06:29] <kshishkov> *yawn* [20:06:38] <kshishkov> g'night everyone [20:06:45] <lu_zero> good night kshishkov =) [22:29:35] <kierank> i wonder if ffmpeg builds on pocket pc; then i could put my phone on fate [23:28:26] <CIA-63> ffmpeg: stefano * r25201 /trunk/ (11 files in 3 dirs): [23:28:26] <CIA-63> ffmpeg: Replace deprecated CODEC_TYPE_AUDIO and CODEC_TYPE_VIDEO with the [23:28:26] <CIA-63> ffmpeg: corresponding AVMEDIA_TYPE_* symbols.

1 0

IRC log for 2010-09-24
by irc＠mansr.com 25 Sep '10

25 Sep '10

[00:03:22] <lu_zero> so it should be replaced completely [00:03:40] <Dark_Shikari> No [00:03:59] <Dark_Shikari> It does the right thing except for the reference frame handling [00:04:00] <Dark_Shikari> which is wrong [00:04:38] <lu_zero> the patch of 8-10hours ago tried to dup the frame but it segfaulted iirc [00:05:01] <Dark_Shikari> Yes [00:05:04] <Dark_Shikari> I gave up on that [00:05:11] <Dark_Shikari> because ffmpeg's buffer handling doesn't understand the concept of duplicate frames [00:05:18] <Dark_Shikari> that's why I posted a new patch above [00:07:14] <lu_zero> adding a flag for it so it wouldn't free all the fields isn't a viable option? [00:07:55] <Dark_Shikari> that isn't the problem [00:08:04] <Dark_Shikari> TONS of stuff breaks if you have two reference frames in the list with the same pointer [00:08:07] <Dark_Shikari> ENORMOUS amounts of stuff. [00:08:16] <Dark_Shikari> I fixed the patch I posted 10 hours ago to not free -- it still breaks [00:08:21] <Dark_Shikari> it just breaks 50 frames later in the video [00:08:26] <Dark_Shikari> where it starts loading the wrong frames [00:08:39] <lu_zero> =\ [00:08:47] <Dark_Shikari> So I just hacked it [00:10:00] <lu_zero> how? doing a deepcopy? [00:10:28] <Dark_Shikari> Just copying the pixels [00:10:32] <Dark_Shikari> read the patch [00:10:35] <Dark_Shikari> it's 10 bloody lines [00:11:40] <lu_zero> I thought that is the minimal one and that first you did a full deepcopy of the thing =P [00:12:50] <Dark_Shikari> No, I didn't do a full deepcopy ever [00:14:09] <lu_zero> ok.. [00:22:59] <Dark_Shikari> oh btw, mru [00:23:08] <Dark_Shikari> I talked to the boost dev who goes to my school about that symbol [00:23:17] <Dark_Shikari> Spirit is a library in boost that generates recursive-descent parsers on compile time [00:23:31] <Dark_Shikari> the concept is sound and perfectly reasonable, but in C++, the only way to do that is to encode the recursive-descent parser as a type [00:23:34] <Dark_Shikari> Which it does. [00:23:44] <Dark_Shikari> Users are... "highly" encouraged to strip such function symbols. [00:33:16] <CIA-63> ffmpeg: stefano * r25165 /trunk/ (7 files in 3 dirs): [00:33:16] <CIA-63> ffmpeg: Add frei0r filter. [00:33:16] <CIA-63> ffmpeg: See thread: [00:33:16] <CIA-63> ffmpeg: Subject: [FFmpeg-devel] [POC] frei0r wrapper [00:33:16] <CIA-63> ffmpeg: Date: Tue, 24 Aug 2010 21:37:32 +0200 [00:52:44] <CIA-63> ffmpeg: stefano * r25166 /trunk/ (4 files in 2 dirs): [00:52:44] <CIA-63> ffmpeg: Deprecate av_opt_show() in favor of a new function av_opt_show2(), [00:52:44] <CIA-63> ffmpeg: which allows to specify only a subset of all the options to show. [00:52:44] <CIA-63> ffmpeg: stefano * r25167 /trunk/ffplay.c: Make ffplay -h show the settable AVOptions. [00:55:50] <CIA-63> ffmpeg: stefano * r25168 /trunk/doc/APIchanges: Update doc/APIchanges after the last API changes. [05:44:04] <KotH> hoi zäme [06:34:42] <_av500_> ahoi [06:44:47] <mru> morning [06:45:51] <Tjoppen> morr [06:45:52] <Tjoppen> n [07:50:51] <merbzt> Armada 628 [07:51:04] <merbzt> is that a capable chip ? [07:51:19] <merbzt> or is it like the tegra2 ? [07:52:50] <mru> spin doctors are doing their job, I see [07:53:01] <mru> it's just another dual-core arm [07:53:41] <kshishkov> dual-dual-core ARM [07:54:02] <merbzt> tri-core [07:54:07] <mru> no, not tri [07:54:07] <kshishkov> nah, 2+1 [07:54:10] <mru> dual + 1 [07:54:15] <kshishkov> those cores are not equal [07:54:35] <Dark_Shikari> some cores are more equal than others [07:54:47] <kshishkov> and IIUC they're intended as alternatives, not for simultaneous work [07:55:20] * kshishkov also would like to point out that Marvell designed that wonderful chip for SheevaPlug [08:35:33] <lu_zero> yawn [09:01:38] <Tjoppen> I wonder why vlc expects libliveMedia.a to reside at /usr/lib/live/liveMedia/libliveMedia.a rather than just /usr/lib [09:02:09] <thresh> because live555 is broken [09:02:15] <thresh> and why do you ask here anyway [09:02:24] <DonDiego> i was just about to say that :) [09:02:31] <DonDiego> that it's broken.. [09:02:52] <Tjoppen> hm. maybe I should join all the other channels :) [09:16:16] <CIA-63> ffmpeg: stefano * r25169 /trunk/libavfilter/vf_frei0r.c: Remove unnecessary av_strdup() and av_free(). [09:20:55] <cartman> ahoy! [09:21:05] <mru> merhaba [09:21:33] <cartman> damn [09:21:35] <cartman> feels weird [09:21:43] <cartman> mru: stop doing that :P [09:21:53] <mru> doing what? [09:22:00] <cartman> speaking Turkish [09:22:05] <cartman> felt really weird :P [09:22:31] * mru does not speak turkish [09:22:46] <cartman> *write [09:23:19] <mru> ^^ that is all the turkish I know [09:23:28] <cartman> :> [09:23:50] <spaam> mru: maybe KotH need to teach you some more ;) [09:24:53] * mru doesn't need to learn turkish [09:25:00] <mru> all my turkish friends speak english [10:02:30] <Dark_Shikari> mru: where's a guide to running fate? [10:02:37] <Dark_Shikari> that is, the set of tests on fate.mansr.com [10:02:58] <mru> what do you want to do? [10:03:07] <mru> just test a patch? [10:03:16] <Dark_Shikari> a guy in #ffmpeg is having an issue even with all asm off [10:03:18] <Dark_Shikari> with artifacting [10:03:20] <Dark_Shikari> I want him to run fate [10:03:25] <Dark_Shikari> (he's on an apple device) [10:03:38] <mru> "apple device"? [10:03:44] <mru> arm based/ [10:03:45] <Dark_Shikari> iphone [10:03:46] <Dark_Shikari> yes [10:03:54] <Dark_Shikari> he's getting pink blocks in flv encoding [10:04:06] <mru> it's very, very hard to run fate on iphone [10:04:11] <Dark_Shikari> why is that? [10:04:15] <mru> apple [10:04:17] <Dark_Shikari> even if you jailbreak it? [10:04:38] <mru> will it mount nfs and run sshd? [10:04:43] <Dark_Shikari> dunno [10:04:52] <mru> or something equivalent [10:18:05] <mru> Dark_Shikari: which iphone model? [10:18:17] <mru> and what os version? [10:18:18] <Dark_Shikari> no idea [10:18:19] <Dark_Shikari> #ffmpeg [10:26:29] <saste> mru: hi [10:26:41] <mru> hi saste [10:26:49] <saste> mru: yes at least in theory it should be possible to build frei0r with MinGW/MSYS [10:27:36] <saste> mru: not sure if strtok_r is supported there tho [10:27:46] <saste> mru: I can check that... [10:38:32] <cartman> wtf is frei0r [10:38:51] <Dark_Shikari> correct, no strtok_r on mingw [10:39:47] <mru> Dark_Shikari: no, but I bet there's no dlopen either [10:40:05] <mru> or other thing frei0ia0i2lisw depends on [10:40:50] <saste> cartman: http://frei0r.dyne.org/ [10:40:59] <cartman> dlopen users -> http://nelsonhaha.com/ [10:41:11] <saste> funny filters which make your ffmpeg look less serious [10:41:20] <cartman> saste: thanx [11:10:51] <cartman> oooh Michael is pissed off for real [11:11:56] * cartman applies +empathy to the channel [11:14:05] <mru> wtf is he smoking? [11:14:56] <cartman> dunnow [11:15:01] <cartman> the man needs a hug or something [11:15:04] <mru> must be something potent [11:15:12] <_av500_> so not the good turkish stuuf? [11:15:35] <cartman> _av500_: we got great waterpipe [11:17:01] <merbzt> cartman: mail subject ? [11:17:16] <cartman> merbzt: [PATCH] move h264 loopfilter strength code to yasm [12:26:12] <twnqx> is there a way to make ffprobe parse the whole file? [12:27:15] <twnqx> these files claim to be video only [12:27:23] <twnqx> and i don't believe ffprobe :X [12:29:07] <kshishkov> does it contradict ffmpeg -i ? [12:30:45] <twnqx> no... [12:30:59] <kshishkov> or ffplay? [12:31:07] <twnqx> sadly not [12:31:17] <twnqx> but i still believe there must be audio somewhere [12:31:24] <mru> BBB: before you spend too much time learning inline asm, know that it's neither intended nor suitable for blocks of more than a few instructions [12:31:26] <twnqx> unless it's in these .afs file... [12:31:34] <twnqx> -> Sega Dreamcast (Compressed Audio) by Sega of America, Inc. [12:31:42] <BBB> mru: probably [12:31:57] <twnqx> i was using inline ASM with borland pascal [12:32:04] <BBB> mru: even so, it might be useful to learn - hey, maybe I can learn how to write better cabac code or so [12:32:14] <twnqx> the gcc syntax is to braindamaged to even consider it, imho [12:32:19] <mru> sure, there's no harm in learning how it works [12:32:40] <BBB> what he asks for is nice in theory, but hard [12:32:52] <BBB> it's easy to write braindead code in inline asm that performs like shit [12:32:57] <BBB> just create a few too many variables [12:32:59] <BBB> tadaa, done [12:32:59] <mru> and the part about changing only the asm to yasm doesn't make sense [12:33:07] <BBB> doing that in yasm is _incredibly difficult_ [12:33:15] <BBB> maybe that's why yasm performs so much better [12:33:19] <BBB> writing shitty code is _hard_ [12:33:31] <mru> unknowingly writing shitty code is hard [12:33:33] <BBB> writing optimal code is hard too, but generally you'll end up somewhere well better than the middle [12:33:58] <BBB> any ideas on what to do then? [12:34:28] <kshishkov> mru: really? Looks like it's most popular thing [12:34:43] <mru> BBB: do about what? [12:35:01] <BBB> shall I rewrite the yasm code to have all these in between variables? :-p [12:35:10] <BBB> and then remove it to be my version? [12:35:15] <BBB> that would be weird [12:35:19] <mru> that would still be changing the c code [12:35:29] <BBB> I think he doesn't necessarily mind [12:35:37] <mru> it's almost like he thinks yasm and c can be mixed [12:35:48] <BBB> I uderstand his frustration that the patches that move inline asm -> yasm are hard to review, because they're by no means 1:1 identical [12:36:00] <BBB> that's just inherent to the whole issue at hand [12:42:32] <kierank> wow michael signed an nda [12:42:45] <kierank> or will do so [12:42:58] <kshishkov> or just selfimposed one [12:43:29] <BBB> merbanan: ping [12:43:29] <kierank> maybe he's trying to negotiate the nda [12:43:37] <kierank> that's why it took a year [12:43:41] <mru> lame excuse [12:45:10] <kshishkov> well, we don't know much about him anyway [12:45:38] <mru> I know enough [12:46:09] <kierank> what do you know [12:46:37] <kshishkov> his personality, of course [12:48:03] <cartman> kierank: which nda? [12:48:27] <mru> cartman: the he's using as an excuse for not working [12:48:42] <cartman> lol :> [12:48:47] <mru> and if he's not working, then neither shall anybody else [12:48:57] <cartman> nero? [12:49:48] <Tjoppen> it seems dvbsub encapsulation in libav* is a bit of a mess. the encoder, decoder, parser, muxer and demuxer all have different ideas of how it should be done [12:50:41] <Tjoppen> more specifically, the leading 20 00 bytes and the trailing FF byte [12:58:11] <Tjoppen> in other words: RFC/PATCH time [14:02:02] <CIA-63> ffmpeg: rbultje * r25170 /trunk/doc/optimization.txt: [14:02:02] <CIA-63> ffmpeg: Update docs regarding writing optimizations: [14:02:02] <CIA-63> ffmpeg: - mention clobber-marking of xmm registers, [14:02:02] <CIA-63> ffmpeg: - some notes on external vs. inline asm, including tips on which to use for [14:02:02] <CIA-63> ffmpeg: what situation and to not rewrite+improve in the same patch (as with C code) [14:02:03] <CIA-63> ffmpeg: - some more best-practice guidelines [14:02:04] <CIA-63> ffmpeg: See "[PATCH] update doc/optimization.txt" thread on ML. [14:06:35] <CIA-63> ffmpeg: rbultje * r25171 /trunk/libavcodec/x86/h264_idct.asm: [14:06:35] <CIA-63> ffmpeg: Unroll loop in h264_idct_add8_sse2(). This means we can inline scan8[] in the [14:06:35] <CIA-63> ffmpeg: code directly also and remove loop setup. 20% faster in function, 0.8% overall. [14:06:35] <CIA-63> ffmpeg: See "[PATCH] unroll loop in h264_idct_add8_sse2()" thread on ML. [14:07:47] <merbzt> BBB___: yes ? [14:08:13] <CIA-63> ffmpeg: rbultje * r25172 /trunk/libavcodec/x86/h264_idct.asm: [14:08:13] <CIA-63> ffmpeg: Unroll loop in h264_idct_add16intra_sse2(). Basically identical to r25171, this [14:08:13] <CIA-63> ffmpeg: inlines scan8[] and removes loop setup. 15% faster, 0.4% overall. [14:08:13] <CIA-63> ffmpeg: See "[PATCH] unroll loop in h264_idct_add8_sse2()" thread on ML. [15:32:37] <CIA-63> ffmpeg: rbultje * r25173 /trunk/libavcodec/x86/h264dsp_mmx.c: Remove unused variable. [15:37:53] <CIA-63> ffmpeg: michael * r25174 /trunk/ (4 files in 2 dirs): 2nd try to fix av_log() repeated detection [15:40:04] <CIA-63> ffmpeg: michael * r25175 /trunk/ (ffplay.c ffmpeg.c): Enable AV_LOG_SKIP_REPEATED to maintain previous behavior. [15:41:42] <CIA-63> ffmpeg: michael * r25176 /trunk/ffmpeg.c: Doxy consistency cosmetics [16:19:05] <CIA-63> ffmpeg: michael * r25177 /trunk/libavutil/log.c: Cosmetic (rename detect_repeats to is_atty which matches the truth) [16:19:06] <CIA-63> ffmpeg: michael * r25178 /trunk/libavutil/log.c: indent [16:32:58] <CIA-63> ffmpeg: stefano * r25179 /trunk/cmdutils.c: Add missing existence checks in opt_default(). [16:36:34] <kierank> kshishkov: have you seen 5.1 variant of bink audio? [16:37:40] <kierank> header is 1FCB [16:40:31] <kshishkov> kierank: I'm not responsible for audio, please notify pross-au instead [16:40:52] <kierank> ok [18:05:13] <CIA-63> ffmpeg: mstorsjo * r25180 /trunk/libavformat/options.c: [18:05:13] <CIA-63> ffmpeg: Add an AVOption max_delay for AVFormatContext->max_delay [18:05:13] <CIA-63> ffmpeg: This can currently also be set via -muxdelay in ffmpeg for muxers, [18:05:13] <CIA-63> ffmpeg: but not for demuxers (nor for demuxers in ffplay) - this patch [18:05:13] <CIA-63> ffmpeg: allows it to be set in all those cases. [19:35:55] <BBB___> why is yadif gpl? [19:36:56] <mru> nobody knows [19:37:14] <J_Darnley> Why wouldn't it be? It is in mplayer [19:37:34] <BBB___> put a gun to the head of whoever wrote it [19:37:35] <mru> I don't care what licence it is [19:37:38] <BBB___> and kindly ask to relicense it [19:37:41] <Compn> probably diego didnt want to support lgpl in the source anymore [19:37:47] <Compn> source/configure that is [19:38:02] <Compn> no, nevermind, i'm thinking of something else [19:42:58] <BBB___> mru: re:ML piece, no REALLY?!??!? :-p [19:45:16] <mru> which part? [19:45:31] <mru> time-wasting? [19:46:06] <mru> I honestly don't see why you're entertaining this folly of his [19:52:09] <cartman> BBB___: yadif is written by Michael himself afaik [19:59:22] <BBB___> mru: maybe I learn from it... [20:00:39] <BBB___> cartman: hm... [20:00:50] <cartman> "We called him Tortoise because he taught us." ;=) [20:02:32] <CIA-63> ffmpeg: stefano * r25181 /trunk/libavfilter/defaults.c: Add missing NULL checks, fix crash. [20:26:44] <mru> BBB___: I prefer learning while doing something useful [20:26:56] <mru> that way I might learn a useful skill [20:32:13] <mru> I really fucking hate michael right now [20:34:34] <Compn> you guys sure do got a lot of drama around [20:42:08] <CIA-63> ffmpeg: stefano * r25182 /trunk/libavfilter/ (7 files): Add missing uses of NULL_IF_CONFIG_SMALL for the filters descriptions. [20:42:59] <CIA-63> ffmpeg: mru * r25183 /trunk/libavcodec/vorbis_enc.c: vorbisenc: remove VLAs [21:08:31] <Compn> anyone want to add a project to the list ? [21:08:34] <Compn> http://sourceforge.net/projects/hypervideoconve/ [21:54:39] <bcoudurier> hi guys [21:57:09] <bcoudurier> mru I saw you mentioning that the picture was copied twice in libavfilter, can you point me where ? [22:00:51] <mru> bcoudurier: I was wrong [22:01:11] <bcoudurier> ah [22:01:24] <mru> but once is already more than it should be [22:01:29] <bcoudurier> I know it's being copied once currently because direct rendering is not hooked up yet [22:01:34] <bcoudurier> agree [22:01:53] <bcoudurier> AVCodecContext->get_buffer need to get set to the first filter get_buffer function [22:01:59] <bcoudurier> and no copy will be left [23:15:05] <CIA-63> ffmpeg: stefano * r25184 /trunk/ (7 files in 4 dirs): [23:15:05] <CIA-63> ffmpeg: Change the syntax of the crop filter from x:y:w:h to w:h:x:y. [23:15:05] <CIA-63> ffmpeg: Slightly more intuitive and required by a pending changes for making [23:15:05] <CIA-63> ffmpeg: the filter parametric.

1 0

IRC log for 2010-09-23
by irc＠mansr.com 24 Sep '10

24 Sep '10

[03:41:00] <CIA-63> ffmpeg: cehoyos * r25158 /trunk/libavformat/asfdec.c: [03:41:00] <CIA-63> ffmpeg: Fix aspect ratio for files that have it stored in [03:41:00] <CIA-63> ffmpeg: ff_asf_extended_content_header. [03:41:00] <CIA-63> ffmpeg: Patch by Richard Buteau, rbuteau rgbnetworks com [07:12:09] <lu_zero> good morning [07:12:21] <kshishkov> buon giorno [07:12:42] <lu_zero> god morgon kshishkov =) [07:13:40] <kshishkov> det är riktig #ffmpeg-devel-se nu :) [07:15:08] <spaam> Det är bra :) [07:15:19] <kshishkov> javisst [07:16:43] <andoma> hej alla :) [07:16:49] <kshishkov> hejsan [07:17:29] <wbs> gäsp [07:18:44] <lu_zero> det -> this| är -> is is| riktig -> right? | nu -> now? [07:19:47] <kshishkov> lu_zero: precis [07:20:53] * lu_zero will master swedish misreading soon [07:22:34] <spaam> ändra alla kommentarer i koden till svenska? :) [07:23:53] <lu_zero> Kotändra -> ??? [07:24:03] <_av500_> gm [07:24:06] <lu_zero> alla -> all? [07:24:29] <lu_zero> kommentarer -> comments, koden -> code [07:24:44] <wbs> lu_zero: du är ganska bra på det här :-) [07:24:50] <lu_zero> till and i I couldn't guess [07:25:02] <wbs> till -> to, i -> in [07:25:10] <wbs> ändra -> change [07:25:15] <lu_zero> ah [07:25:33] <lu_zero> ändra isn't a same-form [07:25:33] <spaam> change all the comments in the code to swedish :) [07:26:02] <wbs> yeah, I guess it's the only word in that sentence that isn't directly related to the english counterpart :-) [07:26:04] <lu_zero> spaam: I'll add some naive japanese just to make non utf-8 readers scream [07:26:38] <spaam> lu_zero: sounds good : ) [07:26:47] <kshishkov> det passar bra [07:27:56] <lu_zero> uhm [07:28:11] <lu_zero> what bra means? [07:28:21] <kshishkov> good [07:28:32] <thresh> yes, bras are good [07:28:36] <mru> mornings [07:28:50] <mru> thresh: removing them is better [07:29:12] <thresh> indeed [07:29:14] <lu_zero> mru: depends on the situation [07:29:28] <kshishkov> thresh: you may find other Swedish words for "good" amusing too [07:29:34] <mru> lu_zero: situation is her bedroom [07:30:09] <lu_zero> mru: ah, not hanging on a cliff, clinging on a bra [07:30:33] <lu_zero> (no, never happened) [07:34:11] <lu_zero> disturbing email of the day [07:34:15] <lu_zero> http://i.somethingawful.com/u/elpintogrande/september10/wtfcontest/katie_be… [07:34:34] <lu_zero> (that's as a post scriptum of a mostly serious email) [07:35:28] <kshishkov> is that the only thing making that mail _mostly_ serious? [07:40:51] * _av500_ does not want to meet lu_zero pen friends [07:41:20] <lu_zero> the email was about 3d printers, daily planning and stuff [07:41:22] <lu_zero> and then [07:41:31] <lu_zero> PS: [link] [07:43:57] <_av500_> lu_zero: now, if only i could ..... https://code.google.com/p/chromium/issues/detail?id=1019 [07:45:47] <spaam> _av500_: fix that feature to ffmpeg also.. [07:45:56] <_av500_> right [07:46:01] <_av500_> -o wallpaper [07:46:08] <lu_zero> ... [07:46:11] <lu_zero> please... [07:46:11] <spaam> yeah [07:46:17] <_av500_> --set-as-wallpaper [07:46:20] <lu_zero> is that serious? [07:46:34] <_av500_> lu_zero: ? [07:46:35] <mru> looks like a troll thread to me [07:46:38] <lu_zero> the bug [07:46:45] <_av500_> they mark it as wontfix [07:46:52] <lu_zero> I just noticed that firefox has it [07:46:59] <_av500_> saying pl can save and then right click in explorer [07:47:02] <mru> _av500_: -o x11:root [07:47:08] <mru> we have -i x11: [07:47:17] <_av500_> mru: yeah, works a charm in windows :) [07:47:30] <_av500_> -o GDI: [07:47:30] <mru> works in my windows [07:47:37] <mru> my windows are all x [07:47:51] <_av500_> -EIKNOW [07:48:11] <_av500_> and like me, you never get to see the wallpaper anyway... [07:48:16] * mru wants EIEIO as an error code [07:48:28] <_av500_> -ETLDR [07:48:37] <kshishkov> mru: what's it use outside farms? [07:48:37] <_av500_> for bloat APIs [07:49:11] <mru> eieio is my favourite ppc instruction [07:49:34] <lu_zero> mru: no wayland for you yet? [07:49:41] <lu_zero> mru: why? [07:49:55] <mru> wayland? [07:50:11] <lu_zero> mru: a bare to nothing server using egl [07:50:28] <mru> X11 is fine [07:50:31] <lu_zero> http://cgit.freedesktop.org/~krh/wayland/ [07:50:35] <kshishkov> mru: I thought it was alias for "register move" [07:50:36] <mru> fdo, yuck [07:50:37] <lu_zero> it's X11, mostly [07:51:24] * thresh will comment on that chromium bug [07:51:46] <_av500_> thresh: ask "what is wallpaper and how do i see it" [07:51:50] <thresh> nah [07:52:06] <thresh> i'll troll the developers [07:52:13] <kshishkov> open new bug since chromium can't operate my coffee machine [07:52:39] <_av500_> kshishkov: only features that are in FF and IE count [07:52:43] <_av500_> like "crahs more" [07:52:46] <_av500_> "use more mem" [07:52:53] <kshishkov> "leaks memory" [07:53:04] <lu_zero> _av500_: chrome can do better and leak processes [07:53:16] * _av500_ has fond memory of leeks [07:53:20] * _av500_ has fond memories of leeks [07:53:33] <_av500_> inb4 mru [07:53:51] <lu_zero> _av500_: http://www.youtube.com/watch?v=kbbA9BhCTko [07:54:13] <mru> _av500_: I didn't know you'd been to Wales [07:54:34] <_av500_> lu_zero: PPS? [07:54:52] <lu_zero> leeks [07:54:56] <_av500_> right [07:57:20] <Tjoppen> grr.. my remuxed mpegts w subtitles doesn't work in vlc [07:57:38] <_av500_> that fringe ipad app? [07:57:42] <_av500_> who cares [07:57:50] <Tjoppen> analyzing it reveals the original files has lots of padding packets for its subtitle streams, while the remuxed file does not [08:00:31] <Tjoppen> would I be right in assuming padding is required for such sparse streams? [08:03:43] <_av500_> thresh: :) [08:07:13] <lu_zero> Tjoppen: try to see if that works [08:20:33] <Tjoppen> I think I will.. just need to figure out where and what to do to the muxer [08:21:10] <_av500_> Dark_Shikari: https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa… [08:22:22] <Dark_Shikari> They'll just mutter "golden frames"a few times and disappear [08:22:42] <_av500_> :) [08:23:25] <Dark_Shikari> iirc the ratecontrol in vp8 is still per-frame, which is kind of hilariously awful [08:23:36] <Dark_Shikari> It also plays the "let's re-encode the frame till it fits" game [08:23:44] <Dark_Shikari> which is great when you need that frame to be done in 20ms [08:24:13] <_av500_> still better than "generate random bitstream and see if it fits" [08:24:49] <_av500_> which is how i would wrtie h266 encoder [08:25:26] <mru> generate random decoders until one gives desired result [08:25:32] <mru> replace encoder with /dev/random [08:25:52] <_av500_> use one fixed bitstream [08:26:06] <_av500_> and generate decoder per video [08:26:40] <kshishkov> mru: congratulations! you've discovered genetic programming [08:27:02] <kshishkov> _av500_: why do you need bitstream then? [08:27:20] <_av500_> true [08:28:05] <kshishkov> and IIUC, MPEG-4 standard was intended to be like that - generate decoder description as bitstream [08:28:22] <_av500_> yes [08:28:40] <_av500_> only define a VM, and let the bistream carry the decoder with it [08:29:04] <_av500_> locats.java :) [08:29:08] <_av500_> lolcats [08:31:55] <kshishkov> essentially, vector formats are like that too [08:32:07] <kshishkov> (unless XML-based) [08:33:00] <kshishkov> though CPU that executes XML may be quite good x86 replacement [08:33:16] <_av500_> mru: https://groups.google.com/a/webmproject.org/group/apps-devel/browse_thread/… [08:33:27] <_av500_> glad I never bought from them :) [08:34:07] <Dark_Shikari> wtf is he on? [08:34:10] <Dark_Shikari> push_neon? [08:34:38] <mru> I think they're trying to save/restore neon regs once per frame or something [08:34:42] <mru> a la michael [08:34:48] <mru> it doesn't work [08:35:04] <Dark_Shikari> if you require that the compiler not use them, it should work [08:35:08] <mru> compilers sometimes use those regs [08:35:19] <_av500_> Dark_Shikari: the fact that sasken is a "professional" codec company [08:35:28] <mru> 54! [08:35:29] <Dark_Shikari> also, the sig (LOL) [08:35:32] <_av500_> yes [08:35:54] <mru> and this is from a "senior" engineer [08:35:55] <_av500_> its like the tata guy on ffdev [08:36:16] <_av500_> mru: yes, sigh [08:36:25] <_av500_> IIT graduates [08:37:39] <cartman> wtf [08:37:44] <cartman> my fate is on fire [08:38:08] <mru> overheating? [08:38:29] <cartman> http://fate.ffmpeg.org/x86_64-apple-darwin10-clang/20100923083337 [08:38:30] <cartman> w00t [08:39:02] <cartman> dropped to 454 tests too, weird [08:39:33] <mru> that is weird [08:40:08] <mru> make: *** [tests/data/acodec.ref.wav] Error 1 [08:40:17] <mru> make: *** [tests/data/vsynth1.ref.yuv] Error 1 [08:40:22] <mru> explains it [08:40:28] <cartman> mru: which is? :D [08:40:56] <mru> all the encode/decode tests depend on those [08:41:53] <mru> check if the machine is overheating [08:42:11] <cartman> only asfdec.c is changed, doesn't make sense [08:42:24] <mru> that's why I said check the hw [08:42:54] <cartman> the machine is not hot at all [08:44:06] <kshishkov> yes, Apple machines nowadays are not hot at all [08:44:19] <mru> it would have cooled off by now [08:44:27] <mru> what kind of machine is it? [08:44:36] <cartman> mru: a macbook pro laptop [08:44:39] <mru> lol [08:45:01] <mru> probably inadequate cooling [08:45:11] <mru> only intended to max out cpu in short bursts [08:45:21] <cartman> it was working until today :P [08:45:27] <cartman> I must have borked something [08:48:52] <mru> did you change anything? [08:49:56] <cartman> updated to clang trunk, thats the biggest change [08:50:27] <mru> that could have broken stuff of course [08:50:35] <cartman> ;> [08:50:50] <mru> mine's on r114171 [08:51:21] <cartman> 114634 here [08:51:26] <cartman> lots of changes :/ [08:55:26] <cartman> mru: is there way to manually run acodec.ref.wav part? [08:55:31] <cartman> maybe the compiler crashes [08:55:57] <mru> compiler isn't involved in that [08:56:04] <j0sh> speaking of compiler crashes [08:56:15] <cartman> mru: ok any manual way to see whats up? [08:58:05] <j0sh> i may be doing something dumb, but ffmpeg sometimes seems to have trouble compiling on gcc 4.4.3/x64 [08:58:56] <j0sh> if i retry a few times it works [08:59:01] <mru> seems stable enough for me [08:59:01] * j0sh is highly unscientific [08:59:23] <mru> is your hw ok? [08:59:48] <j0sh> should be, its a vps on linode [08:59:53] <j0sh> hmm i think i know why [08:59:53] <mru> and how does it fail? [09:00:02] <j0sh> i was doing -j 16 [09:00:15] <mru> out of memory? [09:00:55] <j0sh> not sure, that's likely, i only have 512mb [09:02:23] <cartman> :> [09:03:17] <j0sh> yeah gcc just kills it with an internal error and no other info. prob memory [09:04:45] <cartman> j0sh: -j16 means you have lots of cores, do you? [09:07:34] <j0sh> cartman: i dont know how many cores i have, i just crank it up so it finishes faster :) [09:07:54] <j0sh> probably quad, its a nehalem xeon [09:07:59] <cartman> j0sh: that won't work usually [09:08:11] <cartman> get more RAM too [09:08:30] <cartman> make -j$(core_count +1) is the usual deal [09:08:50] <mru> that +1 is so stupid [09:08:56] <mru> there is no such "rule" [09:08:57] <j0sh> good tip. its a VPS i have for testing random stuff, so my ram is limited [09:09:03] <cartman> mru: right [09:09:16] <mru> it depends on what the limiting factor is [09:09:23] <cartman> i/o or cpu right [09:09:25] <cartman> damn it ;) [09:09:57] <mru> on my quadcore with ht build time drops nicely until -j6 [09:10:08] <mru> -j8 gives only a slight improvement [09:10:15] <mru> -j9 a tiny bit more [09:10:20] <cartman> I have quad-core i7 [09:10:24] <cartman> I am doing -j9 [09:10:36] <mru> quad-i7 here too [09:10:52] <cartman> mru: using -j6 or 9? [09:11:43] <mru> I usually use 4-6 inclusive [09:11:48] <mru> depending on what else I'm doing [09:12:02] <Dark_Shikari> I use 16 [09:12:10] <cartman> Dark_Shikari: core count? [09:12:29] <cartman> mru: makes sense [09:12:36] <Dark_Shikari> 4 cores + HT, so 8 [09:12:44] <cartman> and 16 is because? :D [09:13:02] <mru> 4ht performs about like 5 or 6 real cores [09:13:06] <mru> nowhere near 8 [09:13:20] <cartman> 8, only in the task manager :P [09:13:26] <Dark_Shikari> mru: Yes, but you need 8 threads to have it perform like 6 [09:13:35] <Dark_Shikari> 6 threads will not fully utilize 4 HT cores [09:13:37] <mru> Dark_Shikari: depends on the application [09:13:50] <Dark_Shikari> it's physically impossible for less than 8 threads to saturate an i7 with HT [09:13:52] <mru> make -j6 in ffmpeg fully loads 6 virtual cores [09:14:00] <Dark_Shikari> yes, so you have two not being loaded. [09:14:20] <Dark_Shikari> in order to saturate a physical core, you need two threads going at once in the two virutal cores assigned to it. [09:14:23] <mru> so I have a few cycles spare for doing other things [09:14:27] <Dark_Shikari> ok, true. [09:14:29] <Dark_Shikari> good point =p [09:14:33] <Dark_Shikari> but I rarely have any compilation last more than 30 seconds [09:14:37] <cartman> Dark_Shikari: why 16 still? [09:14:50] <Dark_Shikari> It's probably faster than 8 because of disk reads blocking everything. [09:14:52] <mru> I'd expect build time to increase after -j12 or so [09:14:55] <Dark_Shikari> And I like powers of 2. [09:14:58] <mru> I build in tmpfs [09:15:12] <Dark_Shikari> I'm on windows. Windows doesn't know what a tmpfs is. [09:15:15] <mru> source and compilers are cached [09:15:25] <mru> sucks being you then [09:15:28] <twnqx> windows still knows ramdisks... [09:15:49] <Dark_Shikari> ok, true [09:16:00] <Dark_Shikari> Well, actually, seriously, I run "svn diff" before doing anything with a source tree. [09:16:05] <Dark_Shikari> i.e. when starting up a computer, etc [09:16:09] <Dark_Shikari> it loads all the source files into cache ;) [09:16:25] <mru> my computer is always on [09:16:37] <Dark_Shikari> yes, but things fall out of cache after playing civ5 [09:16:41] <Dark_Shikari> or processing large video files [09:16:49] <Dark_Shikari> hell, encoding one y4m file will kick all my source code out of cache [09:16:50] <mru> I have 12GB ram [09:16:55] <CIA-63> ffmpeg: lucabe * r25159 /trunk/libavdevice/v4l2.c: [09:16:55] <CIA-63> ffmpeg: Allow to set the frame rate in v4l2 devices [09:16:55] <CIA-63> ffmpeg: Patch by Jos? Miguel Gon?alves (jose DOT goncalves AT inov DOT pt) [09:16:58] <Dark_Shikari> and? [09:17:02] <Dark_Shikari> one y4m file... =p [09:17:09] <mru> I don't have many y4m files [09:17:27] <Dark_Shikari> you don't write encoders [09:17:53] <mru> no need to tell me [09:18:36] <Dark_Shikari> also, windows has kind of bad caching [09:18:50] <Dark_Shikari> encoding one file of size $diskcache is practically guaranteed to empty the disk cache of everything else [09:19:04] <Dark_Shikari> it's basically LRU [09:19:11] <mru> so it sucks being you [09:19:30] <Dark_Shikari> actually, is linux's any better? [09:19:58] <cartman> no, but at least Linux has a terminal :p [09:20:33] <Dark_Shikari> linux doesn't have a terminal, linux is a kernel =p [09:20:43] <cartman> rms/linux I mean [09:21:02] <mru> what are those terminal drivers doing in the kernel then? [09:21:36] <Dark_Shikari> because they need something to bloat the code with [09:22:19] <mru> so how do you suggest talking to the hardware? [09:22:29] <mru> and windows users should shut up about kernel bloat [09:22:56] <Dark_Shikari> But Windows makes no pretention of ever being efficient or well written. [09:23:05] <Dark_Shikari> It's _expected_ to be a bloated pile of dung. [09:23:11] <mru> then why the fuck do you use it? [09:23:23] <Dark_Shikari> Because I have a lot of apps that only run on windows, and I don't have many apps that only run on linux. [09:24:20] <Dark_Shikari> And a VM works well for the latter. [09:24:24] <Dark_Shikari> A VM can't really play 3D games. [09:25:15] <Dark_Shikari> well, I guess paravirtualization a'la xen might have a chance. [09:54:16] <CIA-63> ffmpeg: cehoyos * r25160 /trunk/libavformat/asfdec.c: Fix indentation after r25158. [09:56:20] <CIA-63> ffmpeg: mru * r25161 /trunk/tests/ (regression-funcs.sh fate-run.sh): fate: print commands being executed with V=1 [10:27:27] <cartman> mru: so ./fate.sh fate.config V=1 ? [10:27:43] <mru> no [10:28:11] <cartman> obvious question coming up, how then? [10:28:30] <mru> why would you run fate.sh manually anyway? [10:28:54] <cartman> mru: why not? [10:29:13] <mru> simpler to make fate in your usual build dir [10:29:19] <mru> spares you a full rebuild [10:29:34] <cartman> oh but how does it find fate.config ? [10:29:41] <mru> none needed then [10:29:50] <cartman> ah just the output [10:31:34] <cartman> mru: and the path to fate-suite? [10:31:56] <mru> configure --samples=/path/to/fate-suite [10:32:08] <mru> or make fate SAMPLES=/path/to/fate-suite [10:33:00] <cartman> thanks! [10:33:49] <cartman> [NULL @ 0x101000000] [Eval @ 0x7fff5fbfd9d8] Undefined constant or missing '(' in 'si' [10:33:52] <cartman> [NULL @ 0x101000000] Unable to parse option value "simple" [10:33:54] <cartman> this is the first error [10:34:11] <cartman> idct parsing is borked [10:34:33] <cartman> option parsing is broken rather [10:34:34] <cartman> :) [10:35:42] <mru> what's with -no-integrated-as btw? [10:35:53] <cartman> mru: doesn't compile otherwise [10:35:57] <mru> does for me [10:36:05] <cartman> didn't back then [10:36:07] <cartman> lets see [10:36:18] <mru> always did for me [10:38:50] <cartman> libavcodec/x86/dsputil_mmx_avg_template.c:737:9: error: invalid instruction mnemonic 'pavgusb' [10:40:18] <mru> osx retardedness? [10:40:24] <cartman> bleh ;) [10:40:51] <cartman> all errors point to pavgusb [10:40:54] <cartman> whatever it is [10:41:23] <mru> looks like some kind of vector average instruction [10:43:22] <cartman> any ideas about the parsing problem, which file would be responsible for parsing options? [10:43:33] <mru> clearly a miscompilation [10:43:39] <cartman> yup [10:43:41] <mru> it works fine with all other compilers [10:43:43] <cartman> I'll try -O1 etc. [10:43:48] <cartman> which file? :) [10:43:52] <mru> eval.c probably [10:43:56] <cartman> thanx [10:45:11] <cartman> removing -O3 didn't make any change [10:59:57] * lu_zero meanwhile is trying to teach neon to android... [11:00:10] * lu_zero ponders about using another toolchain [11:00:23] <mru> that's usually the easy choice [11:00:51] <cartman> android knows neon already, no? [11:00:56] <lu_zero> it's annoying if you want other people [11:01:03] <lu_zero> cartman: the as is complaining [11:01:05] <mru> other people are annoying [11:01:13] <andoma> </quote> [11:01:14] <cartman> mru: agreed [11:01:50] <lu_zero> So there is a way to tell it to use neon, just not the usual one... [11:02:30] <mru> if it worked the usual way, everybody would see that it's nothing special [11:04:17] <DonDiego> jannau: latm! [11:04:32] <DonDiego> i can see you procrastinating even from here.. [11:04:34] <DonDiego> :) [11:04:57] <cartman> (gdb) print p->s [11:04:57] <cartman> $9 = 0x100e00090 "si" [11:05:02] <cartman> half parsed :D [11:05:13] <mru> cartman: you're wasting your time [11:05:17] * DonDiego sees jannau pay for his own beverages at next year's linuxtag - poor jannau ... [11:05:19] <cartman> mru: why? [11:05:49] <mru> have you tried very latest clang trunk for starters? [11:05:58] <cartman> mru: sure? [11:06:06] <cartman> I compile 2-3 times a day [11:06:19] * mru curses viewvc [11:06:20] <lu_zero> DonDiego: IFF he manages to get his git tree I'll pay for his beverages =P [11:06:30] <mru> no way to see a nice list of commits [11:06:32] * cartman goes back to gdb time waste session [11:07:33] <DonDiego> lu_zero: git is stopping his important work.. [11:07:54] <lu_zero> latm vs git .. [11:07:58] <lu_zero> hard choices... [11:08:08] * mru doesn't care about latm [11:11:22] <DonDiego> it's what separates ffmpeg from aac world domination [11:12:57] <CIA-63> ffmpeg: michael * r25162 /trunk/libavfilter/avfilter.h: [11:12:57] <CIA-63> ffmpeg: Correct terminology bug in poll_frame() [11:12:57] <CIA-63> ffmpeg: it returns the number of samples not frames (for video sample=frame) [11:16:14] <cartman> heh [11:17:54] <mru> I see a few scary-looking commits in clang today [11:23:38] <lu_zero> like? [11:24:04] <mru> bunch things about rearranging branches [11:29:34] <lu_zero> uhmm [11:29:50] <lu_zero> NEON enabled yes [11:29:53] <lu_zero> yai! [11:30:05] <cartman> mru: found it [11:30:07] <cartman> for(i=0; i<sizeof(buf)-1 && val[i] && val[i]!='+' && val[i]!='-'; i++) [11:30:10] <cartman> buf[i]= val[i]; [11:30:18] <cartman> this part is possibly the problem [11:30:21] <cartman> val = "simple" [11:30:26] <cartman> but buf ends up being sşi [11:30:27] <cartman> si* [11:30:32] <cartman> libavcodec/opt.c [11:30:43] <cartman> line 154 [11:30:52] <cartman> work with -O1 broken with -O2 [11:30:53] <mru> I see nothing wrong with that line [11:31:07] <cartman> well thats where simple becomes si [11:31:09] <kurosu> cartman: pavgusb is a 3DNow instruction that lead to the SSE pavgb [11:31:24] <cartman> kurosu: oh clang doesn't support 3DNow I think [11:31:26] <kurosu> (predating it) [11:31:48] <kurosu> disable 3Dnow then in configure [11:31:55] <cartman> mru: compiling opt.c with -O1 fixes it [11:31:58] <kurosu> (if that's possible, I don't know) [11:32:11] <cartman> kurosu: I'll wait for them to fix their assembler [11:32:12] <lu_zero> cartman: use delta to produce a reduced testcase [11:32:27] <cartman> lu_zero: how can I know its miscompiled using delta? [11:32:55] <cartman> I can report and they can do the hard work :P [11:33:10] <lu_zero> as you wish, just report it ^^ [11:37:47] <cartman> http://llvm.org/bugs/show_bug.cgi?id=8212 [11:46:32] <Tjoppen> an update on my subtitle issues: adding padding packets didn't help [11:47:12] <Tjoppen> I'm assuming it's OK to add them pretty much anywhere. I added them after each video packet. plays fine in ffplay [11:48:43] <lu_zero> uhm [11:48:48] <lu_zero> interesting... [11:48:51] <lu_zero> brb [11:49:11] <Tjoppen> I'm grabbing the vlc git. going to see if their demuxer might be the problem [12:05:35] <Tjoppen> .. interesting. netbeans is automagically configuring and making vlc. just had to bootstrap and import it as a new project [12:09:39] <kshishkov> sounds like another reason to avoid VLC [12:10:26] <cartman> netbeans & vlc? [12:10:26] <cartman> wtf [12:11:53] <Tjoppen> it's actually one of the better ide's I've come across [12:12:42] <Tjoppen> quite surprising, yes. sometimes it gets stuck parsing for a while though, such as when switching between my local ffmpeg branches [13:29:27] <Tjoppen> interesting.. vlc has a rather big (360k) table for doing the PID -> stream mapping [13:30:15] <kierank> what pid -> stream mapping? [13:32:03] <Tjoppen> maybe I'm using the wrong words. but it needs to keep some state for each pid seen. lavf allocate such state dynamically afaict. vlc just allocates all 8192 entries [13:32:24] <kierank> i see [13:33:51] <Tjoppen> that demuxer is quite a bit larger too. mpegts.c is 1801 lines while vlc's ts.c is 4367 [13:35:21] <mru> the vlc ts demuxer is horribly complicated [13:35:44] <Tjoppen> so I see. finding this bug is going to be.. nontrivial [13:36:10] <Tjoppen> if it is that demuxer's fault. it might not be [13:44:54] <merbzt> Tjoppen: port the tcvp demuxer to ffmpeg [13:45:11] <lu_zero> the tcvp is better? [13:46:39] <mru> some things are done more cleanly [13:49:49] <Tjoppen> appearently the people who want this remuxing done think the file I have now looks OK. it seems more and more like vlc isn't doing what it should [13:54:37] <lu_zero> tell vlc people to look into it [13:57:50] <Tjoppen> I think I will [15:05:16] <BBB> Dark_Shikari: if I do punpckldq xmm0, [mem], then mem has to be 16-byte aligned right? what if it isn't? is there a "punpckldq for unaligned memory"? or do I have to movdqu into a register first? [15:20:55] <thresh> http://tortoisesvn.net/howpaypalscrewsopensourceprojects [15:25:05] <kshishkov> what do you expect from payment system founded by ex-scammer? [15:34:52] * BBB hates gdb [15:35:28] <BBB> I get a segfault somewhere where it claims I'm reading from a NULL address, and then info-registers tells me the address at that line is perfectly valid [15:35:31] <BBB> now what do I do?? [15:37:40] <mru> debug gdb [15:37:49] <BBB> I want to kill gdb [15:38:00] <mru> have you valground it? [15:38:10] <BBB> I'll try [15:38:54] <kierank> i had a problem like that once and updating gdb fixed it [15:38:57] <iive> kshishkov: is he really ex- ? [15:41:19] <BBB> lots of complaints about pred8x8_plane_c [15:41:26] <BBB> my function runs find in valgrind [15:57:47] <BBB> hm, apparently gdb was off a few instructions of where the problem actually occurred... [15:58:53] <mru> that happens [16:00:02] <BBB> gdb is really shitty sometimes [16:00:27] <kierank> it also sometimes does multiple instructions when you try and step through one instruction [16:02:51] <BBB> it almost works now [16:03:01] <BBB> it's off a tiny bit for the new function I wrote, but mostly correct [16:03:06] <pJok> kierank, its a feature, not a bug [16:03:13] <BBB> and it looks like it's double the speed of the original :) [16:03:25] <BBB> (that's still only 0.1% faster, but hey, 0.1%=0.1% :) ) [16:21:28] <jankowiak> Hi, I have a quick question, I have simple ffplay clone to play audio streams and I have been trying to figure out how to set a progress bar... I've tried a few variations using the get_audio_clock but it isn't working... [16:22:45] <jankowiak> from what I have read the duration in the AVStream is the total length while get_audio_clock * AV_TIME_BASE should give me the current position [16:22:59] <jankowiak> is this correct? [16:23:11] <jankowiak> or I am doing this completely wrong? [16:23:13] <kierank> pJok: huh? [16:23:34] <mru> completely wrong channel methinks [16:24:08] <jankowiak> which would the right channel be? [16:24:12] <mru> #ffmpeg [16:25:13] <jankowiak> thanks, I'll try there, though the last time I questions like this there they had sent me here... [16:26:29] <BBB> this is for ffmpeg development, not developing applications with ffmpeg (?) [16:27:25] <kierank> maybe there should be an "in between" channel [16:30:12] <thresh> #devel-ffmpeg [16:30:24] <mru> #dev-null [16:31:19] <Compn> libav-users list is the in-between [16:31:30] <Compn> mailing list anyways [16:31:42] <mru> yes, but no such channel [16:34:46] <J_Darnley> Make one? [16:34:57] <mru> feel free [16:36:32] <kierank> #libav-users? [17:28:31] <kierank> it's mru's favourite person: http://www.xiph.org/video/vid1.shtml [17:30:19] <kierank> html5, it just works (tm): http://dl.dropbox.com/u/2701213/xiph.png [17:35:17] <Tjoppen> it just works [17:48:26] <Tjoppen> crappy connection on their server :\ [17:48:59] <Tjoppen> 70 kBps? I am amused [17:50:32] <kierank> Tjoppen: i meant the borked aspect ratio [17:51:32] <kierank> ok, i visit the site again and it's out of sync... [17:55:51] <Tjoppen> yes, I saw the aspect ratio problem [18:01:01] <jenk> ok [18:01:04] <jenk> i made #libav-users [18:01:13] <jenk> because i wanted a channel to ask questions using libav* too [18:01:29] <jenk> the documentation is pretty sparse [18:01:32] <jenk> its hard to get into using it [18:03:58] <kierank> you didn't register it [18:04:50] <kierank> wow mru actually owns _troll_ [18:05:09] <mru> you hadn't noticed? [18:05:22] <kierank> I thought you just change to it for trolling [18:05:34] <kierank> just like i changed to kierankCDGS [18:05:59] <mru> one does not preclude the other [19:01:52] <cartman> my fate is green, clang regression is fixed \o/ [19:16:29] <_av500_> http://groups.google.com/group/shibboleth-users/browse_thread/thread/123bd2… [19:17:36] <thresh> _av500_: oh how awesome this e-mail is. [19:18:33] <thresh> goat-time see like the wind, pole, and dragon? [19:18:45] <thresh> it's even fun to decypher that! [19:23:04] <cartman> _av500_: someone used Google Translate [19:23:07] <cartman> I vomitted [19:29:57] <Dark_Shikari> BBB: yes you have to movdqu first [19:30:04] <Dark_Shikari> Note that this only applies to sse. [19:30:08] <Dark_Shikari> the mmx version only loads 4 bytes [19:30:14] <Dark_Shikari> the sse version should only load 8 bytes [19:30:19] <Dark_Shikari> but it doesn't, it loads 16 [19:37:25] <mru> "Please apologize for your stupidity" [19:38:08] * kshishkov lols at http://www.thinq.co.uk/2010/9/23/marvell-launches-triple-core-arm-chip/ [19:39:15] <cartman> kshishkov: battery will dry up in 5 minutes [19:39:50] <mru> counting like that, omap4 is at least octocore [19:39:54] * kshishkov suspects it will suck not only energy [19:58:43] <_av500_> marvell-ous marketing vomit [19:58:55] <_av500_> 2 cores and a 3rd aka dsp [19:59:20] <_av500_> same as omap4, or snapdragon [19:59:53] <wbs> does the current snapdragon have 2 cores, too? or some upcoming versions? [20:00:03] <mru> omap4 has about a dozen little helper cores [20:00:37] <lu_zero> little as scaled down arms or dsp or something? [20:00:53] <_av500_> m3 [20:01:00] <_av500_> so arm7 like [20:01:57] * cartman wonders about energy usage [20:04:43] <_av500_> cartman: why? [20:05:03] <_av500_> core that are unused sleep or are not powered [20:08:46] <cartman> _av500_: wondering the extreme case like decoding 1080p etc. [20:10:42] <cartman> _av500_: in the education sector, a minimum of 8 hours is required for any reading device. [20:11:36] <lu_zero> cartman: 8hour ... [20:11:48] <cartman> a school day is about 8 hours [20:13:00] <cartman> iPad seems to be the battery king for now [20:13:40] <mru> you wouldn't be reading 8h continously [20:13:51] <cartman> true, device can sleep etc. [20:14:01] <cartman> but many devices won't make it after 5 hours [20:14:13] <mru> my archos5it lasts about 30 days on standby [20:14:33] <cartman> mru: that has _av500_ module installed it seems [20:14:48] <_av500_> :) [20:24:09] <CIA-63> ffmpeg: reimar * r25163 /trunk/libavcodec/rawdec.c: [20:24:09] <CIA-63> ffmpeg: rawdec: only allocate a full-frame size buffer if it actually will [20:24:09] <CIA-63> ffmpeg: be used, place palette buffer in the context to simplify this. [20:57:17] <cert_> hi [20:58:06] <cert_> how can i get ffmpeg-devel with lucid to compile xbmc with external lib? [20:58:22] <_av500_> yes [21:01:18] * mru still hasn't managed to parse that question [21:02:01] <cartman> cert_: better ask in #ubuntu [21:05:33] <cert_> ok thank you [21:34:28] <CIA-63> ffmpeg: mstorsjo * r25164 /trunk/ (5 files in 3 dirs): Add a G.722 encoder [22:21:14] <Dark_Shikari> how do I make ffmpeg print AV_LOG_DEBUG messages? [22:21:19] <Dark_Shikari> no -v value seems to do it [22:21:49] <mru> -loglevel [22:21:57] <mru> don't ask [22:22:04] <Dark_Shikari> wait. wtf is the difference between that and -v? [22:22:12] <mru> ^^ [22:27:51] <Dark_Shikari> bah. no response to my ML email [22:27:53] <Dark_Shikari> and my patch still breaks shit subtly [22:58:37] <lu_zero> uhm? [22:58:42] <lu_zero> still the h264 one? [23:01:00] <Dark_Shikari> oh, I have one that works now. [23:01:02] <Dark_Shikari> http://pastebin.org/1130459 [23:01:04] <Dark_Shikari> looooooooooooooooooooooool [23:01:46] <jenk> ? [23:02:49] <Dark_Shikari> it's a downright braindamaged hack, but it works fully [23:02:51] <Dark_Shikari> passes all the test cases [23:07:31] <_av500_> and does what? [23:07:55] <Dark_Shikari> makes h264 error concealment work correctly with drop frames [23:07:57] <Dark_Shikari> *dropped [23:08:05] <Dark_Shikari> currently, it "time warps" back to the end of the ref list [23:08:37] <_av500_> ic [23:09:12] <Dark_Shikari> I can upload a rather effective test clip [23:09:52] <Dark_Shikari> this test clip has every 5th frame dropped, and then the encoder corrects the dropped frame [23:09:59] <Dark_Shikari> if you play it in current ffmpeg, it will look hilariously awful [23:10:07] <Dark_Shikari> if you apply that patch, the loss is almost invisible. [23:11:05] <Dark_Shikari> http://www.mediafire.com/?6huh99qemkrp11y [23:11:08] <Dark_Shikari> here's the test clip [23:32:28] <lu_zero> what did you change? [23:32:34] <Dark_Shikari> read the patch [23:32:57] <lu_zero> I would if thunderbird isn't being killed by my qemu mailbox... [23:33:09] * lu_zero starts purging [23:36:22] <lu_zero> 18789 lu_zero 20 0 1853m 1.3g 15m D 88 67.2 0:29.51 thunderbird-bin [23:36:30] <lu_zero> .... [23:37:07] <Dark_Shikari> sounds like firefox [23:37:55] <lu_zero> 3280 lu_zero 20 0 1037m 226m 4512 S 1 11.4 9:43.41 firefox [23:38:06] <lu_zero> note the difference... [23:46:20] <lu_zero> uhm [23:46:24] <lu_zero> where is your patch? [23:47:01] <Dark_Shikari> I just pasted it above... [23:47:49] <lu_zero> thought you had posted it [23:48:30] <Dark_Shikari> I did. in irc [23:50:49] <lu_zero> on the ml [23:51:30] <Dark_Shikari> of course not [23:51:32] <Dark_Shikari> it's a massive pile of hack [23:54:20] <lu_zero> how do you plan to clean it up? [23:54:46] <Dark_Shikari> I don't [23:54:51] <Dark_Shikari> there's no "cleanup" to do [23:54:54] <Dark_Shikari> it's as clean as it can possibly be [23:55:09] <Dark_Shikari> it's the _wrong_ way to fix it, but it _works_, and michael won't respond to my email, so I won't try to make it right. [23:56:11] <lu_zero> hopefully he'll catch the log and will reply =P [23:56:25] <kierank> ^^ MICHAEL READ THIS [23:56:26] <Dark_Shikari> michael: your code sucks and is broken. [23:56:26] <kierank> ;) [23:56:39] <Dark_Shikari> the error concealment code is completely broken and doesn't work with lost frames [23:56:52] <Dark_Shikari> it doesn't even just assume the frame to be equal to the previous [23:56:55] <Dark_Shikari> it just breaks horribly

1 0

IRC log for 2010-09-22
by irc＠mansr.com 23 Sep '10

23 Sep '10

[00:17:59] <saintdev> you mean they actually would update...? [02:18:55] <CIA-63> ffmpeg: rbultje * r25157 /trunk/doc/optimization.txt: Fix typo (instruciton -> instruction). [05:37:38] <KotH> bonjour [05:37:56] <kshishkov> servus [07:15:10] <kshishkov> KotH: it seems to be excatly 102 years since proclamation of Bulgarian independence, time to celebrate [07:17:03] <_av500_> we switch to bulgarian notation? [07:18:03] <kshishkov> what so special about it? [07:18:20] * iive wonders what he had done last night. [07:18:47] <Dark_Shikari> what code in ffmpeg allocates Pictures? [07:18:56] <Dark_Shikari> ff_alloc_picture doesn't allocate the Picture, it allocates the contents of the Picture [07:18:57] <kshishkov> get_buffer [07:18:59] <Dark_Shikari> i.e. there's two steps [07:19:03] <Dark_Shikari> 1) allocate the Picture struct [07:19:05] <Dark_Shikari> 2) allocate the pointers in it [07:19:11] <Dark_Shikari> 2 is done with ff_allocate_picture [07:19:15] <Dark_Shikari> but how do I do 1? [07:19:23] <Dark_Shikari> am I just supposed to malloc every single time? [07:19:29] <kshishkov> and struct is usually part of context and is allocated along with it [07:19:39] <Dark_Shikari> But I'm dealing with pointers to pictures. [07:19:52] <Dark_Shikari> a "copy" is copying a pointer. [07:20:04] <Dark_Shikari> But ffmpeg REALLY doesn't like it when I put two of the same frame in the reference list [07:20:12] <Dark_Shikari> (same frame in memory, that is) [07:20:21] <Dark_Shikari> so I want to just try duplicating it. [07:20:45] <kshishkov> look at h264 decoder [07:20:54] <Dark_Shikari> That's what I'm looking at [07:21:01] <Dark_Shikari> it's beyond ridiculous [07:21:18] <kshishkov> feel free to submit a simplification patch [07:21:23] <Dark_Shikari> rm -rf [07:22:31] <cartman> Dark_Shikari: Password: [07:22:44] <iive> if I remember right, (and I'm not really sure I do), there is difference in meaning between frame and picture. You allocate memory for a frame, and then you allocate picture in the frame [07:23:01] <iive> the picture could be frame, or one of the 2 fields. [07:26:56] <mru> Dark_Shikari: the struct holding the pointer is typically "static" somewhere else [07:28:20] <Dark_Shikari> it turns out my patch from the other day breaks decoding much later [07:28:24] <Dark_Shikari> after a number of lost frames [07:28:29] <Dark_Shikari> because it fucks up the memory handling [07:28:40] <Dark_Shikari> apparently ffmpeg just assumes all frames in the ref list are different. [07:31:03] <mru> does the spec allow duplicate entries? [07:31:38] <Dark_Shikari> Of course not, there's no way that could happen afaik [07:31:49] <Dark_Shikari> But in practice you need to support it for error concealemnt [07:31:53] <Dark_Shikari> if you lose a frame, you have to stuff something there [07:32:08] <mru> not encouraged doesn't imply forbidden [07:32:54] <Dark_Shikari> There is no way it can happen [07:33:00] <Dark_Shikari> because no MMCO operation results in the duplication of frames [07:33:02] <Dark_Shikari> they just move frames around [07:33:32] <Dark_Shikari> Well, I made it stop generating massive floods of errors. Now it just crashes in ntdll!RtlUpdateClonedSRWLock. [07:33:32] <mru> right [08:00:48] <KotH> kshishkov: this independence will end [08:01:01] <KotH> kshishkov: .tr is currently discussing whether they should buy .gr :) [08:01:17] <kshishkov> again? [08:01:25] <cartman> KotH: lol [08:18:11] <superdump> what does that have to do with bulgaria? [08:18:35] <lu_zero> good morning Honoome [08:19:09] <lu_zero> KotH: brrr... [08:30:35] <Dark_Shikari> someone answer my email so my boss can stop breathing down my neck [08:30:40] <Dark_Shikari> (ffmpeg-devel) [08:31:16] <Dark_Shikari> I reimplemented my own entire reference counting system and I still can't get it to work [08:32:12] <cartman> Dark_Shikari: that was the best patch mail I have seen ever [08:33:04] <Dark_Shikari> It isn't a patch mail. [08:33:17] <cartman> patch mail asking for help :P [08:33:18] <Dark_Shikari> lol [08:33:28] <Dark_Shikari> "this is what I did. this broke. so I did this. then this broke." [08:33:31] <Dark_Shikari> not that complicated =p [08:33:47] <cartman> :> [08:33:59] * cartman goes to optimize zsh startup [08:42:56] <lu_zero> Dark_Shikari: FF_BUFFER_TYPE_SHARED might help? [08:43:08] <Dark_Shikari> what is SHARED? [08:43:21] <Dark_Shikari> er, that won't work [08:43:23] <Dark_Shikari> #define FF_BUFFER_TYPE_SHARED 4 ///< Buffer from somewhere else; don't deallocate image (data/base), all other tables are not shared. [08:43:28] <Dark_Shikari> >all other tables are not shared [08:45:05] <lu_zero> from the dealloc code it seems to do what you want [08:45:18] <Dark_Shikari> No it doesn't [08:45:22] <Dark_Shikari> it tries to free all the tables anyways [08:45:55] <lu_zero> then you have to patch that [08:46:06] * lu_zero is running and just had a random look [08:46:30] <Dark_Shikari> I did it. it doesn't work [08:46:40] <lu_zero> brb [08:47:14] <Dark_Shikari> Even if I comment out all the frees of those tables, it still crashes. [08:47:34] <Dark_Shikari> Wait. Spoke too soon. [08:47:38] <Dark_Shikari> No it doesn't. [08:48:14] <lu_zero> ^^ [08:48:29] <lu_zero> good thing, now plug the leak =) [08:49:52] <KotH> lu_zero: ? [09:00:50] <cartman> mru: you already fixed this but, anyhow http://qt.pastebin.com/GsekmjiQ [09:06:55] <Tjoppen> woo. I just found a bug in the mpegts muxer, or ffmpeg [09:07:20] <mru> the mpegts muxer is only bug [09:07:25] <Tjoppen> heh [09:07:39] <Tjoppen> when remuxing it doesn't interleave subtitle packets properly [09:07:46] <Tjoppen> they all end up at the end of the file [09:30:36] <lu_zero> KotH: the idea of buy .gr wholesale [09:32:31] <kshishkov> lu_zero: well, its value with debts concerned should be low enough that even Turkey can afford that [10:36:20] <cartman> "I know, unfortunately my only Android hardware is Archos5 Internet [10:36:20] <cartman> Tablet and I'm still waiting for Android 2.0 update from ARCHOS :-(" [10:36:26] <cartman> _av500_: ^^^^ stop slacking [10:37:02] <mru> +1 [10:44:18] <_av500_> cartman: says who? [10:44:44] <cartman> _av500_: some Android developer, his name is safe with me [10:44:45] <cartman> :p [10:46:14] <_av500_> we dont give in to anonymous terrorists [10:46:28] * mru terrorises _av500_ non-anonymously [10:47:18] <cartman> _av500_: some Qt developer, porting his app to Android [10:47:34] <cartman> _av500_: Qt port in its all infancy pre-alpha quality does not support Android < 2.1 [10:49:00] <kshishkov> so why should av500 care about some Qt with too high requirements? [10:49:11] <cartman> high? [10:49:12] <cartman> lol [10:49:25] <cartman> high would be requiring Android 2.2 [10:49:27] <cartman> or 3.0 :P [10:50:27] <kshishkov> well, at least you can start bugging av500 to move to Android 4.0 now, maybe you'll convince him to the time it's released [10:51:20] <cartman> kshishkov: seriously, 2.1 is not a high requirement [10:54:27] <kshishkov> cartman: I don't know and don't care. Qt is a high requirement. Too bad it didn't die young, the world would be better without it and KDE [10:54:53] <cartman> kshishkov: won't you ever get tired of this hatred stuff? [10:59:28] <thresh> Qt is awesome [11:00:03] <cartman> kshishkov & others just have pure baseless hatred [11:00:17] <thresh> haters gonna hate, right.. [11:00:22] <cartman> true [11:01:30] <kshishkov> cartman: I've tried Qt programming, even in times it was still very nonfree [11:02:00] <cartman> kshishkov: 1.x times [11:02:45] <kshishkov> same for KDE - when starting single app starts a lot of nonrelevant Kstuff and dumps a lot of noise to console, I say it's substandard design at best [11:03:00] <kshishkov> cartman: does Qt still use moc? [11:03:07] <cartman> kshishkov: yes [11:03:23] <cartman> kshishkov: no more #include "foo.moc" though [11:03:50] <kshishkov> cartman: still, do you call this "baseless" hate? [11:03:59] <cartman> kshishkov: yup :P [11:04:01] <spaam> mru: http://uncrustify.sourceforge.net/ maybe you can use that on c++ so it will be beutiful ;) [11:04:23] <cartman> kshishkov: if you want Qt/KDE to be as fast as bare assembly, not going to happen [11:05:54] <kshishkov> cartman: I don't care about speed in that case. But using additional tools and being forced to use their own inventions for standard stuff sucks [11:06:23] <cartman> kshishkov: the only invention would signal/slot concept [11:06:27] <cartman> not a bad idea :) [11:08:30] <kshishkov> read about Objective C for starters [11:08:48] <cartman> better way for this stuff? [11:09:22] <kshishkov> yes, since it's in the language and not in crutches [11:09:58] <cartman> ok, thanks for the tip [11:10:54] <kshishkov> it's primary Apple language if you didn't know [11:11:01] <cartman> yes I know [11:47:46] <Tjoppen> an update on my mpegts subtitle remuxing woes: the packets get as far as to the parsing stage [11:48:29] <Tjoppen> the original video sometimes strips three bytes from them, while the remuxed one just never return anything [11:52:29] <mru> spaam: I prefer using rm on c++ [11:58:20] <Tjoppen> hm. since it strips that header when parsing, wouldn't it have to be re-added be a bsf when before being re-muxed? [11:58:28] <Tjoppen> *by [12:04:49] <wbs> CDGS? :-) [12:05:27] <mru> lol [12:05:28] <kshishkov> reminds me of certain module guy [12:07:04] <spaam> the awesome amiga group! [12:08:13] <kierank> yup, with one member [12:08:18] <kshishkov> how awesome? They've ported FFmpeg to 68k? [12:08:33] <kshishkov> kierank: you? [12:08:45] <kierank> no, basty [12:09:14] <mru> let's port everything to foocomposer [12:09:33] <lu_zero> brrr... [12:09:46] <Kovensky> <Dark_Shikari> http://pastebin.ca/1946114 <Dark_Shikari> this is a single symbol from a real application. <Dark_Shikari> 36 kilobytes [12:09:49] <mru> start with the kernel and libc [12:09:54] <kshishkov> and let's represent all video as MPEG-4 textures! [12:10:02] <mru> Kovensky: yes, I posted it [12:10:07] <mruCDGS> ok lets go [12:10:12] <Kovensky> oh really [12:10:13] <Kovensky> :D [12:10:27] * Kovensky is just spreading C++ "love" [12:11:07] * kshishkov thinks that the fact C++ creator was Danish should explain it all [12:11:25] <mru> there are good danes too [12:11:40] <mru> like kurt westergaard [12:11:41] <spaam> yeah.. carlsberg ;D [12:11:42] <kshishkov> yes, there are exceptions [12:11:43] <Kovensky> weren't the vikings called "danes" in old english [12:11:58] <mru> many danes were vikings [12:12:02] <mru> and vice versa [12:12:05] <kshishkov> Kovensky: only because England got Danish Vikings mostly [12:13:05] * Kovensky should resume reading Vinland Saga [12:13:11] <Tjoppen> I wonder what that symbol would look like in mangled form :> [12:13:25] <kshishkov> and good Ukrainian rulers were Swedish Vikings, then they started to get closer to natives and it all went downhill [12:14:01] <Kovensky> how is the "vi" from viking pronounced btw [12:14:21] <kshishkov> as plural "jag" [12:14:23] <mru> depends on what language you're speaking [12:14:33] <Kovensky> well, english ._. [12:14:41] <mru> there were no english vikings [12:16:24] <Kovensky> =p [12:16:33] <lu_zero> viking translates to something like sailor in the native language? [12:16:35] * kshishkov hastily writes a saga about Vikings from icy cliffs of Portugal [12:17:28] <Kovensky> lol [12:17:32] <lu_zero> kshishkov: please, daylight glittering vampires are enough [12:19:10] <kierank> lu_zero: twilight? [12:19:21] * kshishkov scribbles notes for epic saga about Italian Empire in XVIIth century, all 20 of them [12:19:31] <lu_zero> 20? [12:20:24] <kshishkov> lu_zero: dunno exacty number. But IIRC in 17th century Italia was as united state as Germany [12:20:34] <kshishkov> *exact [12:21:37] <lu_zero> Italia was a geographic concept [12:23:22] <kshishkov> but you had Italian state back then - every Italian city had its own IIRC [12:27:45] <lu_zero> every city was a state [12:27:52] <lu_zero> (more or less) [12:27:58] <lu_zero> (still is) [12:29:16] <kshishkov> so you live in mighty Fiatia? [12:29:19] <BBB> Dark_Shikari: re: michael's reply, so do I misunderstand why red zone + call in inline asm is a problem? [12:29:27] <BBB> Dark_Shikari: can you enlighten me? [12:29:47] <mru> he's talking about how he thinks things should be [12:29:52] <mru> not about how they actually are [12:29:54] <mru> as usual [12:30:56] <BBB> I had that impression also, I mean of course inline asm can just take redzone off esp before every call, but that's silly, wasteful and stupid [12:31:03] <BBB> plus it takes cycles :p [12:31:29] <mru> and that asm won't be able to take memory arguments on the stack [12:32:33] <mru> or waste time adjusting sp around every call [12:34:00] <iive> i was thinking that the problem with calling function from asm is in the fact that each architecture have its own calling convention. [12:34:41] <mru> each arch has its own asm too [12:35:29] <lu_zero> and each abi might change that as well... [12:35:37] <iive> there is specific linux, windows and macosx assembly? [12:35:55] <mru> those are operating systems [12:36:31] <iive> and you are talking about processors. [12:37:27] <BBB> x86-64 and x86-32 have different call convention, yes [12:37:38] <BBB> so calling functions in general is a little problematic [12:37:44] <BBB> but it can be done [12:38:14] <BBB> (don't forget that for non-external functions, we can use any call convention, see various examples in the h264dsp asm) [12:38:35] <BBB> (and you can abuse that to speed it up greatly by making assumptions that don't always hold for external functions) [12:41:59] <kshishkov> BBB: what about different calling conventions in Win32 itself? [12:42:31] <kshishkov> luckily, they're mostly for system stuff and we don't care but still... [12:57:14] <cartman> is there a way / compiler option to make http://paste2.org/p/998565 fail? [12:58:26] <mru> what are you trying to do? [12:59:06] <kshishkov> cartman: -Dsigned=unsigned of course [12:59:21] <cartman> mru: trying to reproduce a clang error [12:59:29] <cartman> its in python ctypes test [12:59:48] <mru> what is it you'd like to have fail? [12:59:53] <cartman> ctypes claim clang return 43 here [13:00:15] <cartman> tf_b(-126) returning something !-42 [13:00:15] <cartman> :) [13:00:19] <cartman> 43 would be nice ;) [13:00:32] <mru> 126/3 is 42 [13:00:41] <cartman> just trying to find out how the hell it would return 43 [13:00:41] <mru> when rounding towards zero [13:00:49] <mru> -43? [13:00:54] <cartman> nope positive 43 [13:01:00] <kshishkov> cartman: it treats input as unsigned char then [13:01:09] <kshishkov> -126 = 130, 130/3 = 43 [13:01:17] <cartman> kshishkov: aha [13:01:28] <cartman> kshishkov: but clang -O3 test.c doesn't exhibit the problem [13:01:32] <cartman> might be some flag some define [13:01:34] * kshishkov mourns another failed joke [13:01:44] <mru> 54! [13:02:06] <kshishkov> try the flag I typed above, it should work [13:02:16] <cartman> kshishkov: right... [13:44:13] <BBB> kshishkov: re: what you said an hour ago, if that ever becomes something we intend to do, we probably should kill ourselves... that's not what simd is for ;) [13:51:30] <kshishkov> BBB: okay [14:03:00] <Tjoppen> I finally figured out exactly why my subtitles weren't working. two things: [14:03:04] <superdump> mru: another amr-wb mail with patch has been moderated on -devel [14:03:13] <superdump> if you could allow it, that'd be sweet [14:03:21] <Tjoppen> the mpegts muxer doesn't "undo" what the parser does (basically adding a zero byte) [14:03:31] <superdump> BBB: marcelo doesn't come on irc [14:03:36] <Tjoppen> and the extradata somehow ends up wrong [14:03:45] <mru> superdump: he should [14:05:04] <superdump> speak of the devil [14:05:07] <superdump> ahoy mars____ [14:12:24] <superdump> mars____: say something! :) [14:12:36] <mars____> hello all! :) [14:12:41] <superdump> there we go [14:13:13] <lu_zero> Tjoppen: how wrong? [14:13:26] <kshishkov> superdump: traditional words are "Polly wants a cracker" though [14:13:33] <Tjoppen> composition_id and ancillary_id are 1 instead of 2 [14:13:44] <lu_zero> btw who knows quite a lot of subtitles in ffmpeg? [14:13:51] <Tjoppen> or: data is 00010001 instad of 00020002 [14:13:58] * lu_zero wants to get rtp-ass done sooner or later =P [14:14:10] <Tjoppen> so I kind of wonder what code changes the extradata and why [14:14:22] <BBB> superdump: devil indeed ;) [14:14:38] <Tjoppen> and also whether I should have the dvbsub parser idempotent or not [14:14:51] <Tjoppen> atm it can't parse parsed input [14:15:34] <Tjoppen> the fix is simple: instead of requiring the packet to begin 20000F, also allow it to begin just 200F [14:16:02] <mars____> mru: hey, I have a patch sent to ffmpeg-devel that needs approval [14:16:12] <mars____> mru: because of the message size [14:16:25] <mru> mars____: so I heard [14:16:45] <mars____> mru: can you work it out for me? [14:17:04] <mru> why are these patches so huge anyway? [14:17:07] <mru> lots of tables? [14:17:29] <mars____> mru: yes, and because its my whole gsoc project in one big patch :) [14:17:36] <lu_zero> ouch [14:17:45] <lu_zero> one patch or a patchset? [14:17:48] <mru> maybe you could drop the tables from the mails [14:17:59] <mru> lu_zero: it's one decoder [14:18:06] <mars____> mru: since it was reviewed late, I gathered the code in one piece [14:18:09] <mru> not much sense in splitting it [14:18:52] <Tjoppen> wait a minute.. I can't just fix the parser since I'm required to make the output work in vlc as well [14:19:18] <mars____> mru: hmm, I may remove the header file with the tables from the patch then [14:19:19] <Tjoppen> bitstream filter seems like a decent choice then [14:19:59] <mars____> mru: but others would have to analyze it separately, if necessary [14:20:40] <mru> I doubt anyone is going to analyse hundreds of kB of tables carefully [14:22:59] <mars____> the header file doesn't contain only the tables.. but i guess it is less important, in fact [14:23:39] <mru> you might want to move the tables to a file of their own [14:24:17] <mars____> i will consider that too [14:24:38] <mars____> i will send another patch soon, thanks [14:31:14] <Tjoppen> aha! the extradata thing is of course the muxer's fault. it always writes 00010001 [14:31:40] <kierank> this thread is going to attract all the audiophiles: http://forum.doom9.org/showthread.php?p=1445266 [14:34:14] <mru> lol [14:34:58] <mru> always amusing to watch the blind leading the blind [14:35:39] <_av500_> ...and through a minefield [14:36:43] <Tjoppen> there. a three-line fix in the mpegts muxer [14:41:00] <Tjoppen> now I just need to add a single 0x00 byte to the subtitle packets :o [14:44:22] <Compn> simple ehehe [14:44:35] <Compn> is anything related to mpegts simple ? [14:44:51] <mru> demuxing is fairly simple [14:45:22] <kierank> except for abominations like latm and 302m [14:47:50] <Compn> hmm, someone was asking about uncommenting that latm aac audio stream check [14:47:54] <Compn> but now i forgot where [14:48:09] <mru> kierank: by mpegts I mean iso 13818-1 [14:48:17] <mru> neither latm nor 302m are defined there [14:48:40] <kierank> thankfully [14:49:04] <Tjoppen> mpegts looks fairly straightforward. try mxf [14:49:19] <Compn> . //{ 0x11, AVMEDIA_TYPE_AUDIO, CODEC_ID_AAC }, /* LATM syntax */ [14:49:30] <kierank> lol mxf [14:49:54] <Compn> line 500 mpegts.c [14:50:05] <mru> Compn: mpegts defines IDs for payload types specified elsewhere [14:50:14] <Compn> ok then [14:50:15] <mru> extracting the payload from the ts is easy [14:50:42] <kierank> ts is no ogg [14:50:42] <Tjoppen> I don't think there's a player that can handle anything above op2b for mxfd [14:50:45] <Tjoppen> -d [18:18:34] <Naikrovek> is there a method in the ffmpeg api that can take two video streams, and merge them into a single stream with the two original streams side by side? [18:27:33] <bcoudurier> hi guys [18:28:27] <Naikrovek> hi [20:59:29] <kierank> lol BBB: "we can create our own bar-party" --> that's going to be one heck of a party [20:59:33] <kierank> new york watch out... [20:59:39] <kierank> ffmpeg devs are in town [21:07:00] <BBB> kierank: so you will come? [21:10:54] <kierank> no [21:11:05] <kierank> too far [21:15:49] <j0sh> if didn't graduate in may, i would be there :) [21:16:28] <kierank> get them to have it in london next time ;) [21:17:00] <spaam> at your place? [21:17:04] <kierank> yeah ok [21:17:11] <kierank> plenty of beer [21:17:15] <spaam> nice [21:17:35] <kierank> you can have the cheap belgian crap spaam [21:17:47] <spaam> no thanks [21:17:58] <spaam> better with carlsberg export : ) [21:18:15] <spaam> hmm.. maybe go and buy some of that tomorrow :D [21:20:58] <kierank> i haven't seen carlsberg at the pub for ages [21:24:09] <spaam> ok :) [21:24:51] <kierank> there are loads of different bitters though [21:25:46] <spaam> try and find out then :)

1 0

IRC log for 2010-09-21
by irc＠mansr.com 22 Sep '10

22 Sep '10

[00:38:00] <peloverde> ot: I really hate HTML http://spectralhole.blogspot.com/2010/09/aac-channel-model-revisited.html [00:39:03] <roxfan> cute [00:39:29] <roxfan> looks fine in user mode, so it's probably css [00:39:37] <peloverde> yes it is CSS [00:40:00] <peloverde> I feel like floating boxes with rotations isn't the best way to organize content [00:42:31] <peloverde> I've replaced the table with "I can't seem to get the CSS right to display it here." [00:49:31] <peloverde> The wonderful thing about sideways text in a table is the cell is sized as if the text were horizontal... but the blog post should be interesting to anyone who has been bitten by the AAC channel model [00:50:18] <kierank> what i never understood is why aac doesn't allow channel map changes [01:12:03] <peloverde> It kind of does via the pce or adts but is underspecified [01:26:26] <peloverde> I'm still kind of curious about PS in iTunes [01:50:13] <saintd3v> Dark_Shikari: maybe a project for doom10? [05:05:51] <Tjoppen> god morgon [05:44:44] <KotH> ohayou gozaimasu! [05:46:30] <_av500_> wakarimas [06:26:10] <superdump> http://news.slashdot.org/story/10/09/21/0428259/Codec2-mdash-an-Open-Source… [06:26:58] <Dark_Shikari> Sounds a lot shittier than SILK. [06:28:56] <Tjoppen> how does celt compare to these? [06:37:59] <superdump> 2.24kbps [07:09:51] <Tjoppen> looks like he's coding the cepstrum of the signal [07:10:11] <kshishkov> so do a lot of other codecs [07:10:14] <Tjoppen> not a bad idea since it and lpc are quite relate [07:10:15] <Tjoppen> d [07:10:23] <saintdev> cepstrum? [07:10:36] <Tjoppen> cepstrum = spectrum of spectrum [07:11:39] <kshishkov> hmm, that sounds rather dubious [07:11:41] <Tjoppen> there are a bunch of variants. quite populer with the audio classification crowd, where they dft normalized coeffs on a bark scale [07:12:57] <Tjoppen> on a linear scale it seems like a decent way to code harmonics? [07:13:07] <kshishkov> nope [07:13:22] <kshishkov> dft(dft(x)) = x [07:13:40] <saintdev> kshishkov: exactly what i was thinking [07:14:11] <Tjoppen> more like abs(dft(log(abs(dft(x)))) [07:14:15] <saintdev> but i'm a noob, so i wasn't sure if i was right :P [07:14:26] <Tjoppen> maybe I should have clarified that :) [07:14:45] <kshishkov> that still sounds bad [07:14:47] <Tjoppen> dtf of the log of the power spectrum [07:16:17] <kshishkov> personally I don't believe in that approach at all [07:16:44] * kshishkov hasn't studied theory so he may be wrong [07:17:12] <kshishkov> from description this codec seems to employ standard speech codec scheme [07:18:45] <saintdev> well they say it's from one of the speex guys, so i would think it would work similar to speex [07:19:01] <saintdev> just with better decisions based on lessons learned from speex [07:19:15] <kshishkov> not the main Speex guy though, looks like this one worked on pre/postprocessing stuff [07:19:57] <kshishkov> still, since I've read Brooks, I'll wait for the third codec [07:21:28] <saintdev> Brooks? [07:21:39] <kshishkov> yes, "The Mythical Man-month" [07:22:05] <KotH> the third codec? [07:22:12] <saintdev> ok [07:22:36] <kshishkov> KotH: lifecycle of software [07:22:44] <kshishkov> first version is usually may be faulty [07:23:01] <kshishkov> second version is usually packed with too many features to be usable [07:23:09] <kshishkov> the third one may be just right [07:23:19] <kshishkov> (since they really worked on it) [07:23:26] <KotH> so, ffmpeg is the second version ? ;) [07:23:52] <kshishkov> it depends [07:32:26] <Tjoppen> his observation that the spectrum is priodic threw me a bit off track. but he does seem to be doing lpc on the spectrum, so I wan't too far off [08:24:33] <mru> and still nothing on the intel forums [08:24:38] <mru> I told you it was a bad idea [08:27:56] <cartman> LOL [08:28:05] <cartman> open a bug report maybe [08:28:18] <mru> I doubt it's considered a but [08:28:22] <mru> bug [08:28:31] <mru> just a missing feature [08:28:36] <mru> one they added in v11 [08:28:44] <cartman> might be :/ [08:28:50] <mru> btw, where can one find icc 12 beta? [08:32:57] <lu_zero> http://www.rowetel.com/blog/?page_id=452 <- interesting? [08:35:43] * _av500_ waits for codec3 [08:36:45] <lu_zero> uhm [08:37:07] * cartman waits for "the codec" [08:38:50] <kshishkov> cartman: DPCM - it codes audio and video [08:39:22] <kshishkov> so it must be the ultimate codec [08:39:42] * mru wants the universal codec they have in star trek [08:39:58] <mru> the one where all you need to do is say "on screen" [08:40:03] <funman> mru: http://abstrusegoose.com/303 this one? [08:40:44] <mru> funman: can you compensate? [08:41:15] <mru> one of the producers must have _really_ liked that word [08:41:23] <cartman> funman: lol [08:41:38] <kshishkov> mru: on2 screen? [08:41:44] <funman> i don't think i ever watched star trek [08:41:53] <cartman> oooh [08:43:46] <kshishkov> funman: okay, what classic series have you seen then? [08:44:07] <_av500_> ulysse31 [08:44:34] <kshishkov> _av500_: sounds like login, what's the password? [08:44:36] <funman> yeah :) [08:44:42] <mru> swordfish [08:45:07] <_av500_> funman: i have the dvd box set :) [08:45:11] <kshishkov> why is that word _always_ the password? [08:45:23] <funman> TV was only sparsely allowed at home when i was a child [08:45:37] <funman> until we got a NES and my dad started playing Super Mario 3 [08:45:37] <cartman> funman: good idea [08:45:40] <_av500_> kshishkov: marx brothers reference [08:46:01] <kshishkov> funman: was it called "crazy invention of American devils"? [08:46:19] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/ThePasswordIsAlwaysSwordfish [08:46:27] <funman> more "mind-alterating shit box" [08:47:05] * mru didn't watch tv much as a kid but has still seen at least some of the classics [08:47:07] <kshishkov> _av500_: I know only three Marx brothers - Karl, Friedrich and Vladimir Illitch. None of them used it [08:47:30] <funman> i have watched a lot of simpsons [08:48:44] <cartman> funman: http://nelsonhaha.com/ [08:48:46] * kshishkov did too - mostly in RM format and horrible Russian dub [08:48:47] <cartman> there you go [08:49:12] <kshishkov> cartman: at least you've never watched South Park, have you? [08:49:19] <thresh> :) [08:49:22] <cartman> kshishkov: never ever sir [08:49:54] <funman> was the motivation behind RM work, "watch simpsons"? [08:50:03] <kshishkov> funman: nope [08:50:31] <cartman> watch RM pr0n? [08:50:34] <kshishkov> actually I had no particular interest in RM by that time [08:50:41] <cartman> rm anime maybe [08:50:54] <kshishkov> yes, with Chinese hardsubs [08:51:17] * funman read "RM pr0n with Chinese hardsubs" [08:51:31] <cartman> must be hard [08:51:37] <thresh> woah, new house md episode [08:51:51] <kshishkov> funman: RM is pornography by definition [08:52:52] <kshishkov> cartman: well, Chinese is not that hard, especially if you know Japanese and can ignore them ;) [08:53:02] <cartman> kshishkov: right :P [08:59:49] <funman> mru: did you think about this libmp3lame version detection? [09:01:09] <mru> I'm inclined to just test for the function we actually need [09:01:31] <mru> ignoring that the first release which has it was broken [09:02:38] <mru> does anyone know a way to find specific versions of intel compilers? [09:02:55] <mru> like, say, the latest in the 10.1 series [09:04:56] <cartman> mru: http://software.intel.com/en-us/articles/older-version-product/ google is too helpful ;) [09:05:12] <mru> what did you search for? [09:05:22] <cartman> intel old software [09:05:23] <cartman> :) [09:31:58] <mru> wtf is wrong with michael? [09:33:04] <kshishkov> where is proper bugreport on him? [09:33:23] <_av500_> resolution: wontfix? [09:34:30] <kshishkov> everybody suspects so [09:38:00] <cartman> whats up with niedermayer? [09:38:14] <mru> he's on a ranting rampage [09:38:35] <cartman> any link so I can have fun too? [09:38:40] <mru> ml [09:38:46] <cartman> subject? [09:40:11] <cartman> a #flame tag is needed [09:40:18] <cartman> just too much signal in ml [09:40:55] <funman> signal-to-flame ratio? [09:41:32] <cartman> yeah [09:42:07] <cartman> aha found it [09:50:29] * Sho_ spots a cartman [09:51:47] <mru> do we care about icc 11.0 and/or 10.0? [09:52:50] * kshishkov looks if Carl Eugen is around [09:52:52] <kshishkov> no [09:53:41] <kshishkov> though it would be nice to support them (probably) [09:55:14] <cartman> Sho_: lo! [09:55:23] <Sho_> :) [09:56:22] <cartman> Sho_: I am always trolling around here :D [09:57:09] * kshishkov takes a pity on cartman [09:57:39] <cartman> kshishkov: I am having a good time, thanks :P [09:58:09] <kshishkov> cartman: if you call that "trolling", you deserve some pity. Ask av500 for example [09:58:34] <cartman> kshishkov: trolling as in I am doing much useful ffmpeg work [09:59:09] <kshishkov> cartman: that phrase was trolling indeed [09:59:25] <cartman> see, it works [10:00:16] * cartman bows to the master troll [10:00:55] * kshishkov simply continues sitting next to him [10:02:30] <_av500_> err [10:02:51] <funman> kshishkov: is trolling contagious? [10:02:52] <kshishkov> _av500_: you are too small to be considered one [10:02:59] <cartman> lol [10:03:00] <kshishkov> funman: no [10:03:37] <kshishkov> cartman: av500 serves as our smallest troll [10:03:43] <_av500_> kshishkov: i was refering to the highlight above [10:03:55] <_av500_> ocourse i know who the master troll is [10:03:56] <pJok> troll'r'us? [10:04:11] <cartman> _av500_: ;> [10:04:38] <pJok> and there the master troll is [10:04:50] <funman> quick, someone /nick mru [10:05:00] <_troll_> funman: it's registered [10:05:18] <spaam> all hail _troll_ ! [10:05:28] <Sho_> cartman: nice to see you're still involved with the FOSS fray then :) [10:05:53] <cartman> Sho_: I am trying KDE releases from time to time, still brings my nvidia to its knees [10:06:01] <Sho_> heh [10:07:16] <cartman> not fun [12:38:06] <Dark_Shikari> BBB___: Just commit the doc/optimization change. [12:38:08] <Dark_Shikari> Fuck michael. [12:38:34] <Dark_Shikari> In fact, how about we just ignore all of his emails in every thread related to asm? [12:38:38] <Dark_Shikari> We'll hellban him. [12:38:45] <Dark_Shikari> problem solved. [12:39:31] <BBB___> hahaha :) [12:40:00] <Dark_Shikari> seriously. if he wants to whine about things without doing any real work, then we can ignore him [12:40:39] <mru> +1 [12:41:17] <Dark_Shikari> Hellbanning is a very effective technique [12:41:55] <Dark_Shikari> Also, Civilization 5 comes out in 2 hours, so I may disappear around that time. [12:42:48] <BBB> sounds like me and starcraft 2 [12:42:53] <BBB> but I already finished it :( [12:44:08] <elenril> except you can't really 'finish' civilization ;) [12:44:35] <mru> you can finish it off [12:44:49] <mru> ask skynet [12:46:04] <elenril> <insert some tropes here> [12:46:39] <Dark_Shikari> damn, I have so much shit I need to do this week. [12:46:43] <BBB> I wish michael would whine less and review my patches more [12:46:50] <Dark_Shikari> BBB: JUST COMMIT [12:46:51] <Dark_Shikari> we reviewed it [12:46:59] <Dark_Shikari> Ignore michael, he is not an asm maintainer [12:47:01] <BBB> you didn't review my idct unroll patches :-p [12:47:04] <Dark_Shikari> Also, in the meantime, you could get to work on xvp8 [12:47:07] <BBB> but I'll commit anytime [12:47:27] <Dark_Shikari> BBB: If it's faster, you should feel free to commit without discussion. [12:47:35] <Dark_Shikari> Unless there's a good reason you think that it needs discussion. [12:47:59] <Dark_Shikari> OK, your macro name should be all caps. [12:48:00] <Dark_Shikari> But that's it. [12:48:15] <Dark_Shikari> And it should be commented. [12:48:17] <Dark_Shikari> Then commit ti. [12:49:22] <Dark_Shikari> tl;dr I trust you, go make things better. ignore michael. [12:49:30] <Dark_Shikari> And stop stalling on xvp8. [12:50:43] <BBB> yeah yeah yeah [13:28:22] <lu_zero> ^^ [13:30:36] <wbs> stop trolling michael already so he can go on and troll me on the g722 encoder so that I can commit it sometimes this decade ;P [13:41:10] <Compn> wbs : any interest in working on g729 patch after you are done with 722 ? [13:41:12] <kshishkov> wbs: you can always ask say Vitor or Ronald for review and commit on their approval - they are speech codec guys here after all [13:42:12] <wbs> Compn: hmmm, if I have spare time after this, perhaps [13:42:39] <Compn> while all the ffmpeg rules and speech codec stuff is fresh in your mind :P [13:42:40] <Compn> ehe [13:42:49] <wbs> kshishkov: true, but if you've seen the encoder review lately, it hasn't been much about the actual speech coding, only about perhaps optimizing one loop a bit [13:43:32] <wbs> perhaps, as in, the total execution time hasn't really changed much [13:44:31] * kshishkov wonders what other G.7xx codecs FFmpeg lacks [13:47:53] <wbs> kshishkov: I think there may be a few of them left still [13:53:16] <pJok> G.711 · G.718 · G.719 · G.722 · G.722.1 · G.722.2 · G.723 · G.723.1 · G.726 · G.728 · G.729 · G.729.1 from what wiki says of G.7XX standards [13:53:44] <cartman> all of them useful as in used somewhere? [13:54:03] <kshishkov> G.711 is widely supported [13:54:14] <kshishkov> used virtually everywhere [13:54:34] <cartman> kshishkov: voice codec or? [13:54:41] <kshishkov> cartman: aka PCM [13:54:48] <cartman> ah :> [13:55:14] <kshishkov> G.722* is in progress [13:55:24] <wbs> kshishkov: isn't g711 mulaw/alaw and not plain pcm? [13:55:43] <lu_zero> wbs: regarding select + windows [13:56:12] <kshishkov> wbs: those too [13:56:16] <lu_zero> I'm thinking to factorize the poll code among the protocols [13:56:59] <wbs> lu_zero: sure, if you can clean it up without breaking the current apis, feel free to propose patches :-) [13:58:17] <kshishkov> wbs: also look at G.711.0 [13:58:28] <lu_zero> wbs: since every place we have a select we should apply your fix [13:58:51] <wbs> not necessarily all of them, but perhaps in some other, too [13:59:14] <lu_zero> (and given our fd set doesn't change switching to poll might be an option) [14:03:30] <kierank> seen this http://www.rowetel.com/blog/?page_id=452 ? [14:04:12] <kshishkov> congratulations! You've managed to get into top 10 of people who posted this link today [14:04:31] <kierank> what is my prize [14:05:35] <kshishkov> |-C [14:05:36] <spaam> a night with mru ! :D [14:06:12] <kshishkov> kierank: that's your trophy cup, keep it nice and clean [14:10:43] * kierank puts it on his mantlepiece [14:14:24] <BBB> Dark_Shikari: I think he almost agrees now [14:14:39] <mru> no [14:14:41] <mru> far from it [14:17:57] <BBB> he'll never agree with "all non-inlined asm should be external asm (e.g. yasm)" [14:18:13] <Dark_Shikari> Just commit it. [14:18:36] <Dark_Shikari> also, civilization 5 is done. fffffffffffffffffff [14:18:49] <kierank> see you tomorrow Dark_Shikari [14:18:53] <BBB> bye bye Dark_Shikari [14:18:56] <BBB> :-p [14:19:00] <mru> kierank: you're very optimistic [14:19:20] <Dark_Shikari> hahahahaha tomorrow hahahahahaha [14:37:37] <BBB> "I'm only arguing the feature if we implement it nicely, I'm not saying we implement it nicely"? [14:37:43] <BBB> does that mean he hates the feature as-is currently? [14:38:38] <kshishkov> could be [14:52:13] <mru> BBB: I don't think anyone will answer your question on the intel forums [14:56:52] <BBB> mru: I figured :( [14:56:59] <BBB> mru: what do you suggest we do now? [14:57:41] <mru> disable the offending code for compilers that don't support alignment [14:59:08] <BBB> ok, I guess... do you have your patch handy? [14:59:13] <mru> not yet [14:59:22] <BBB> I don't mind if we disable mmx altogether for those cpus btw [14:59:26] <BBB> not cpus [14:59:30] <BBB> compilers [14:59:34] <mru> wrong solution [14:59:38] <BBB> but I guess that's a little extreme [15:00:18] <kshishkov> yes, why my build for i386 doesn't feature MMX by default? [15:00:27] <kshishkov> been there [15:00:42] <mru> this is about old icc versions [15:02:44] <kshishkov> bug Carl until he gives you patches [15:02:50] <mru> he won't [15:02:57] <mru> he'll only provide hacks [15:03:58] <kierank> BBB: as soon as it drops off the first page you won't stand a chance of getting the question answered [15:15:36] <BBB> kierank: that's rather sad [15:15:37] <BBB> but ok [15:16:35] <mru> BBB: that's forums [15:16:38] <mru> forums are sad [15:16:42] <mru> QED [17:10:00] <kierank> ok now i see why civ5 takes a long time... [17:22:22] <mru> BBB: ping [17:22:28] <mru> kierank: and why is that? [17:22:48] <kierank> because I downloaded the demo and had a go [17:23:14] <mru> and what did you find? [17:23:47] <kierank> you could spend weeks playing it without even noticing [17:24:00] <mru> oh, one of those games [17:24:06] <mru> what's the appeal? [17:24:32] <mru> I mean, real life is just like that [17:24:34] <kierank> building a civilisation, going to war [17:24:35] <mru> and far more realistic [17:24:57] <kierank> but most people aren't PM/president/emperor/king etc [17:25:23] <mru> most people don't try [17:27:04] <BBB> mru: pong [17:27:18] <mru> BBB: which functions need 16-byte aligned stack? [17:27:31] <BBB> all sse2 functions that use stack [17:27:37] <BBB> except vp8 [17:27:39] <mru> d'uh [17:27:46] <BBB> heh :) ok that wasn't helpful [17:27:51] <BBB> let's try again [17:28:09] <BBB> do we have a broken fate machine that I can peek at? [17:28:09] <mru> I was hoping to not have to read thousands of lines of asm to figure which ones use the stack [17:28:14] <mru> yes [17:28:24] * BBB checks fate [17:28:28] <mru> icc 10.1 x86_32 [17:28:51] <mru> I know of the h264 loop filter [17:29:02] <mru> but there's at least one more [17:29:06] <BBB> vsynth [17:29:06] <BBB> yeah [17:31:04] <mru> something that's used only in mpeg2 and mpeg4adv tests [17:31:38] <BBB> on x86-32, hadamard8x8_diff_sse2/ssse3 [17:32:01] <BBB> in dsputilenc_mmx.c and dsputilenc_yasm.asm [17:32:25] <mru> yeah, -cmp satd [17:33:09] <_av500_> mru: lol, one of your git commit was just given to us from TI :) [17:33:26] <_av500_> the user space ple one [17:33:26] <mru> what commit? [17:33:31] <mru> heh [17:33:59] <mru> the ple is hard to use efficiently from userspace [17:34:01] <_av500_> it was gone from some ti kernel and we asked and they told us to see your commit on how to get it back :) [17:34:13] <BBB> mru: and the deblock sse2 ones are the only ones I see for h264 [17:34:22] <BBB> mru: together that should fix fate on icc 10.1 [17:34:29] <mru> BBB: yes, that's the ones that were disabled before [17:34:33] <BBB> yes [17:34:38] <BBB> that's all from what I can see [17:34:44] <BBB> the rest of simd functions using stack are all mmx [17:34:47] <BBB> they don't need aligned stack [17:35:19] <BBB> if it doesn't fix the vsynth tests, please get me a backtrace and I'll look further :) [17:35:24] <BBB> (although you probably don't need me for that) [17:36:17] <mru> both ff_hadamard8_diff and ff_hadamard8_diff16? [17:36:23] <mru> sse2 and ssse3? [17:37:30] <BBB> yes [17:37:37] <BBB> only on x86-32 all of them [17:37:45] <BBB> the x86-64 ones don't use stack [17:37:55] <mru> stack is 16-byte aligned there anyway [17:46:07] * BBB loves x86-64 [17:46:09] <BBB> so smart [17:46:17] <BBB> now if only it was 32-byte aligned [17:46:19] <mru> so full of hacks [17:46:22] <BBB> (for avx) [17:46:41] <cartman> BBB: avx needs 32byte alignment? [17:58:26] <CIA-63> ffmpeg: mru * r25151 /trunk/configure: [17:58:26] <CIA-63> ffmpeg: Add HAVE_ALIGNED_STACK config setting [17:58:26] <CIA-63> ffmpeg: This is set to 1 if the stack is guaranteed to be suitably aligned [17:58:26] <CIA-63> ffmpeg: for the strictest access mode of the machine. [17:58:26] <CIA-63> ffmpeg: mru * r25152 /trunk/configure: Disable ALIGNED_STACK with icc 10 or prior on x86_32 [17:58:27] <CIA-63> ffmpeg: mru * r25153 /trunk/libavcodec/x86/ (dsputilenc_mmx.c h264dsp_mmx.c): [17:58:28] <CIA-63> ffmpeg: x86: disable SSE functions using stack when stack is not aligned [17:58:28] <CIA-63> ffmpeg: This fixes crashes with ICC 10.1. [17:58:59] * mru waits for fate to run [17:59:35] <spaam> :) [18:01:10] <mru> there goes the cron job [18:01:19] <mru> now we wait [18:01:26] <mru> 3 minutes per compiler [18:07:27] <cartman> my fate is green ;( [18:07:30] <cartman> ;P [18:28:30] <mru> it's green :-) [18:32:46] <wbs> BBB: any objections to the tcp/select patch I posted earlier today? [19:29:00] <mru> hey look, latest icc passes the als tests [19:30:16] <cartman> si senior [19:31:06] <cartman> mru: whats up with sipr though? [19:31:12] <mru> busted [19:34:56] <cartman> http://safecode.cs.illinois.edu/index.html maybe interesting [19:45:26] <lu_zero> uhm [19:45:45] <lu_zero> llvm seems getting more and more nifty stuff [19:49:35] * mru would rather have _useful_ stuff [19:50:37] <mru> Honoome: ping [19:55:25] <lu_zero> mru: clang is quite useful [19:55:37] <mru> it compiles code [19:55:41] <mru> so do most other compilers [19:55:48] <lu_zero> yup [19:56:00] <lu_zero> what else you'd like from llvm? [19:57:05] <mru> fast code [19:57:11] <mru> correct code [19:57:14] <kierank> less fanboism [19:57:18] <mru> that too [19:57:32] <kierank> fanboism is unsuprising considering apple fund it [19:57:33] <mru> but it comes from apple, so what else is there to expect? [19:57:48] <lu_zero> I wasn't aware of fanboism [19:57:59] <mru> fanbois never are [19:58:07] <lu_zero> maybe just because I started looking at it loong ago [19:58:13] <cartman> it has nothing to do with being an Apple fan [19:58:23] * lu_zero isn't an apple fan =P [19:58:23] <cartman> coming from Apple is a negative thing for me [19:58:45] <kierank> reddit, hacker news etc love it [19:58:51] <lu_zero> pff [19:59:04] <cartman> because its fast & good error reporting [19:59:39] <mru> geez, when was the last time you had a syntax error? [20:00:14] <lu_zero> what's with error reporting btw? [20:00:46] <cartman> Guess why tools like http://www.bdsoft.com/tools/stlfilt.html exist [20:01:21] <lu_zero> C++ [20:01:30] <lu_zero> I don't use and do not care [20:02:24] <cartman> guess you are alone lu_zero :P [20:02:42] <cartman> one of the clang developers is from C++ committee [20:02:47] <cartman> maybe two ;) [20:03:48] <lu_zero> so? [20:04:07] <cartman> the world needs a better C++ compiler, so clang plugs the hole for me [20:04:15] <cartman> Apple or Orange whatever [20:04:16] <cartman> its good [20:04:35] <lu_zero> the world needs to make C++ go the way of perl3 [20:04:44] <cartman> in your dreams ;) [20:04:48] <cartman> Java should die first :P [20:05:10] <lu_zero> groovy and javascript are doing a wonderful job [20:05:21] <lu_zero> (regarding java) [20:05:36] <mru> boost::detail::graph::dot_skipper::definition& boost::spirit::impl::get_definition<boost::detail::graph::dot_skipper, boost::spirit::parser_context<boost::spirit::nil_t>, boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char, char, std::char_traits<char>, long>, boost::spirit::multi_pass_policies::input_iterator, boost::spirit::multi_pass_policies::ref_counted, boost::spirit::multi_pass_policies::buf_id_check, boost::spirit::multi_p [20:05:47] * mru did not make that up [20:05:50] <cartman> mru: boost is the best [20:06:11] <lu_zero> mru: boost is the Glaring example why you shouldn't use C++ [20:06:23] <cartman> or why we need better C++ compilers ;) [20:06:41] <lu_zero> cartman: or uncruft the language [20:06:49] <cartman> lu_zero: sadly not happening [20:06:54] <cartman> time to run! bye. [20:07:11] <lu_zero> sigh [20:07:47] <mru> http://harmful.cat-v.org/software/c++/I_did_it_for_you_all [20:11:01] <BBB> wbs: don't really remember, if I didn't reply it's probably ok or so? [20:11:09] <BBB> wbs: or if you want input, you could kick it [20:11:16] * BBB was a little busy last few weeks [20:11:44] <wbs> it was earlier today, but I don't think there's much to be said on it really, it's quite straightforward [20:11:48] <wbs> I'll apply it then [20:14:41] <mru> Vitor1001: did anyone reply about that pgi compiler? [20:14:43] <BBB> I don't see it... I probably missed it, but yeah, if you're confident it's right I trust you that it's fine [20:14:50] <Vitor1001> mru: No reply atm [20:15:00] <BBB> mru: hey, you're on intel developer network now? :) [20:15:40] <mru> it was the simplest way to find the unprotected urls to download icc [20:15:56] <Vitor1001> BTW, is the general hatred against C++ in ffmpeg related to the language itself or to overexposure to bad c++ code? [20:16:06] <BBB> wbs: oh that one, yes it's fine [20:16:10] <mru> Vitor1001: those two are related [20:16:18] <wbs> ok [20:16:40] <BBB> wbs: sorry for not seeing it earlier [20:16:53] <wbs> BBB: no problem :-) [20:17:05] <Vitor1001> mru: Bad c++ code is more related about the lowest bottom of the C++ users [20:17:35] <Vitor1001> things like "OO is the answer for everything" or "let's break ffmpeg into classes" is unrelated to c++ [20:18:29] <mru> _ZGVZN5boost6spirit4impl17escape_char_parseIcE5parseINS0_7scannerINS0_10multi_passISt16istream_iteratorIccSt11char_traitsIcElENS0_19multi_pass_policies14input_iteratorENSB_11ref_countedENSB_12buf_id_checkENSB_9std_dequeEEENS0_16scanner_policiesINS0_27no_skipper_iteration_policyINS0_28skip_parser_iteration_policyINS_6detail5graph11dot_skipperENS0_16iteration_policyEEEEENS0_12match_policyENS0_13action_policyEEEEENS0_18escape_char_parserILm1EcEEEENS0_13pars [20:18:32] <CIA-63> ffmpeg: mstorsjo * r25154 /trunk/libavformat/tcp.c: [20:18:32] <CIA-63> ffmpeg: tcp: Check both wfds and efds when waiting for the result from connect [20:18:32] <CIA-63> ffmpeg: On windows, a connection failure doesn't trigger wfds as it does on unix. [20:18:32] <CIA-63> ffmpeg: This fixes issue 2237, based on code by yeyingxian. [20:18:37] <mru> ^^ that is one reason to hate c++ [20:18:54] <Vitor1001> mru: I bet can do it with C if I try hard enough ;) [20:19:05] <spaam> Vitor1001: do it [20:19:08] <mru> I know of no other language capable of producing such incomprehensible gibberish [20:19:55] <Vitor1001> mru: Can't this code be translated line-by-line to java or OO-forced C? [20:20:14] <mru> that's a single symbol [20:20:18] <Vitor1001> by "OO-forced" I mean structs with tons of function pointers [20:20:20] <mru> no code at all [20:20:45] <BBB> aiyoh [20:20:46] <Vitor1001> How was that generated? [20:20:46] <BBB> oops [20:20:58] <mru> nm libboost.so [20:21:14] <mru> I figured that would be a good place to find a nasty one [20:22:17] <Vitor1001> In C it would be hidden in a maze of function pointers, but the symbol would have a nice name [20:22:46] <mru> no C programmer would come up with such a contorted design [20:22:53] <pJok> mru, i want to believe that that post with Bjarne saying that C++ was a joke is true [20:24:12] <Vitor1001> mru: Yes, because C++ turned into the language of choice for overengineering. [20:24:47] <ohsix> but its fun to stub out classes [20:24:58] <mru> so why have I never seen one single well-written c++ app? [20:24:59] <Vitor1001> mru: But IMHO it has more to do with the way people teach OO in college... [20:25:26] <mru> http://pastie.org/928309 [20:25:31] <mru> debug that! [20:26:23] <Vitor1001> How ifdef misuse is C++ specific? [20:26:54] <mru> wow, there's a symbol in that lib whose demangled name is 21901 bytes [20:26:54] <Dark_Shikari> mru: you haven't seen many wellw-ritten apps period [20:26:58] <Dark_Shikari> ffmpeg certainly isn't a well-written C app [20:27:08] <mru> a fucking 20k SYMBOL NAME! [20:27:18] <thresh> awesome [20:27:23] <ohsix> thats what you get when you share an encoded namespace with c ;] [20:28:00] <BBB> Dark_Shikari: at least it does something for the 3MB that the binary takes on my HD [20:28:11] <BBB> Dark_Shikari: as opposed to 90% of the libs on a standard linux dist [20:28:13] <mru> http://pastebin.ca/1946106 [20:28:20] <BBB> *ugh* gnome [20:28:55] <BBB> wrappertiewrappertiewrap [20:29:00] <Vitor1001> mru: Language feature abuse IMHO. C++ don't forces you into that mess. [20:29:13] <mru> it does pull really hard [20:29:17] <mru> or so it seems [20:29:28] <Dark_Shikari> mru: "big apps tend to be a mess" [20:29:35] <mru> true [20:29:49] <Vitor1001> mru: It is more likely that people that likes this mess is attracted to c++ [20:29:51] <mru> but with C you stand at least some chance to cut through the mess [20:30:28] <mru> Vitor1001: whatever, I simply don't see how c++ would solve any of my problems in a simpler way [20:30:40] <mru> however, I have often seen c++ _create_ problems [20:30:42] <ohsix> the part that bugs me is for all the sugar it offers it ends up being in lots of lines of crap that don't do anything but add indirection that you have to fight through [20:30:44] <Vitor1001> mru: For me, it looks more like that C++ just gives you more features if you want to obfuscate your code. [20:31:02] <Vitor1001> mru: In ffmpeg there would be no point. [20:31:25] <lu_zero> 22:28 <@Vitor1001> mru: Language feature abuse IMHO. C++ don't forces you into that mess. [20:31:30] <lu_zero> ehm [20:31:36] <Vitor1001> Maybe templates for having floating-point and fixed point versions of the same codec but that's it. [20:31:36] <mru> more often than not when confronted with c++ code, I struggle to find the parts that actually do anything useful [20:31:42] <lu_zero> the symbol mangling happens always... [20:31:44] <mru> rather than being wrappers around each other [20:32:10] <mru> what I posted is the unmangled name [20:32:13] <lu_zero> Vitor1001: you can try using clang abberration [20:32:16] <lu_zero> pardon extension [20:32:18] <mru> that's what the damn thing is actually called [20:32:32] <Vitor1001> mru: I know you that plain-C is almost always valid c++. You don't _have_ to use anything else if there is no point. [20:32:53] <mru> then why bother? [20:32:58] <mru> like to wait longer for builds? [20:33:05] <mru> like your binaries larger? [20:33:11] <mru> like more bugs in the compiler? [20:33:24] <Vitor1001> mru: You might use the other features _when it is worth it_ [20:33:27] <mru> like to have the sky fall down every time you switch compilers? [20:33:30] <Vitor1001> and not just for the sake of it [20:33:38] <mru> Vitor1001: I have never seen a case where they were [20:33:51] <ohsix> its not a foregone conclusion that there is, either [20:34:03] <lu_zero> Vitor1001: we tried to figure out which is the compelling feature [20:34:04] <ohsix> but in the realm of all possibility you never know [20:34:05] <lu_zero> none found [20:34:46] <Vitor1001> For some kinds of programs, OO is useful (again, not ffmpeg) [20:35:08] <mru> found an even longer one [20:35:14] <mru> 36056 chars [20:36:29] <lu_zero> Vitor1001: OO is perfectly attainable using C [20:36:42] <Vitor1001> lu_zero: yes, but uglier. [20:36:53] <Dark_Shikari> mru: pastebin it [20:36:54] <mru> no [20:37:20] <lu_zero> Vitor1001: how so? [20:37:26] * lu_zero points boost [20:37:29] <ohsix> at the very least doing it yourself keeps it from rigidly being one paradigm; you can compose the best to suit the situation [20:37:30] <mru> Dark_Shikari: waiting for it to upload [20:37:32] <lu_zero> uglier? [20:37:38] <mru> http://pastebin.ca/1946114 [20:37:40] * lu_zero points gobject [20:37:44] <lu_zero> is that uglier? [20:38:12] <ohsix> RAII is like the only thing i can think of off the top of my head thats worth it; and thats just from the unwind/scope rules [20:38:18] <Vitor1001> lu_zero: Haven't seen gobject. [20:39:17] <mru> you don't need to emulate c++ syntax to be OO [20:39:35] <Honoome> mru: half-pong, please mail me, today I'm feverish so not really here [20:39:41] <mru> ffmpeg is rather OO [20:39:55] <Dark_Shikari> mru: no, ffmpeg largely uses the "big struct of stuff" method [20:40:03] <Dark_Shikari> Look at, say, the h264 decoder. [20:40:08] <mru> Honoome: I noticed your name in the icc ebuilds [20:40:15] <mru> Honoome: still got anything to do with those? [20:40:20] <Dark_Shikari> the "big struct of stuff" involves a struct with all state stored in it [20:40:26] <Dark_Shikari> instead of information-hiding as in OO [20:40:34] <mru> Dark_Shikari: I was thinking of the API [20:40:36] <Honoome> mru: nope, once they began charging or requiring non-commercial licenses I gave u [20:40:38] <Honoome> +p [20:40:50] <Dark_Shikari> is there a programming term for the "big struct of stuff"? [20:41:02] <mru> BSOS [20:41:07] <lu_zero> tortellini coding? [20:41:26] <Dark_Shikari> It's not a big ball of mud, because it's not necessarily a bad design [20:41:34] <Dark_Shikari> and it's not necessarily thrown together [20:41:41] <Dark_Shikari> (but usually is) [20:41:43] <ohsix> variable clearinghouse [20:41:57] <Dark_Shikari> lol [20:42:09] <twnqx> The Core [20:42:20] <ohsix> graduation [20:42:47] <Dark_Shikari> A classic example of something that's hard to represent in OO [20:42:56] <Dark_Shikari> in x264, the OO way of doing MC would be something like [20:43:10] <Dark_Shikari> MCPixelBuffer mc = new MC(mvx, mvy); [20:43:21] <Dark_Shikari> to do motion compensation [20:43:34] <Dark_Shikari> but in x264, there are some cases where an MC is done as part of analysis that can be re-used during the final encode. [20:43:35] <mru> few real-world problems decompose into a clean hierarchy of "objects" [20:43:42] <Dark_Shikari> how would you "stash" that? [20:43:49] <Dark_Shikari> how would you "remember" that you had done it? [20:43:58] <Dark_Shikari> it doesn't fit cleanly into OO. as mru said. [20:43:58] <mru> they rather tend to be interrelated in very non-hierarchical ways [20:44:04] <ohsix> tagged buffers ftw [20:44:15] <Dark_Shikari> i.e. when you start doing optimization, OO starts to break apart [20:45:18] <ohsix> thats one of the reasons its important to have freedom of composition [20:45:29] <Dark_Shikari> But... OO is the one true standard! [20:45:42] <Dark_Shikari> everyone should develop OO! [20:45:51] <lu_zero> uhmm [20:45:58] <lu_zero> ACC might be interesting [20:46:19] <ohsix> they like to teach it because Oranges are Orange, and .color() is familiar to the uninitiated [20:47:07] <ohsix> the comprehensibility from drawing from irl junk gets idiots pretty hot and bothered right up front, entheusiasm is important for teaching [20:48:23] <BBB> Dark_Shikari: big struct of stuff (BSS) is already reserved for mod playback [20:48:24] <BBB> :-p [20:49:02] <lu_zero> BBB: don't recall that [20:49:31] <BBB> vitor would remember [20:49:31] <spaam> How does it go with that libavseq thing ? :D [20:49:35] <NTQ> hi there. is ffmpeg able to make a video from pictures which are streamed through stdin? [20:49:49] <Dark_Shikari> yes. now ---> #ffmpeg [20:50:22] <BBB> spaam: it's finished, it's called pinkskybluecows [20:50:48] <spaam> BBB: haha ;D [20:50:49] <NTQ> Dark_Shikari: no questions here? [20:50:59] <spaam> NTQ: read the topic .9 [20:51:24] <NTQ> sorry [21:34:49] <lu_zero> mru: ever had a look at aspectC? [21:40:42] <BBB> isn't there a language called D? [21:40:45] <_av500_> yes [21:41:02] <_av500_> lu_zero: i used aspectR [21:42:28] <lu_zero> BBB: D is something aspectC something else [21:42:34] <lu_zero> _av500_: R with aspects? [21:43:14] <_av500_> lu_zero: sorry, it was aspect_n and aspect_d [21:43:43] <lu_zero> aspectC looks like the preprocessor we were discussion or not [21:44:12] <lu_zero> uh actually aspectR does exist and is the ruby flavor of aspectJ [21:52:21] <lu_zero> s/discussion/discussing [22:01:09] <iive> am I the only one who can't compile current svn? [22:06:11] <lu_zero> which error? [22:06:16] <lu_zero> which arch? [22:09:37] <iive> "Makefile:61: *** target pattern contains no `%'. Stop." [22:10:07] <iive> make --version is 3.82 [22:12:14] <lu_zero> 3.81 works [22:14:45] <mru> iive: make 3.82 is intentionally subtly incompatible with 3.81 [22:14:48] <mru> because they can [22:15:38] <mru> moreover, that error makes no fucking sense [22:15:52] <mru> lu_zero: never heard of aspectc [22:16:52] <iive> that line is all I get... [22:17:07] <mru> it's a perfectly normal rule [22:17:13] <mru> on line 61 [22:17:25] <mru> not a pattern rule of any kind [22:22:07] <CIA-63> ffmpeg: diego * r25155 /trunk/libavformat/Makefile: cosmetics: Place concat protocol entry in alphabetical order. [22:27:26] <iive> downgraded to 3.81 and it compiles. [22:33:33] <lu_zero> mru: http://research.msrg.utoronto.ca/ACC [22:33:58] <lu_zero> I'm not sure if it's fun or overdesigned [22:35:59] <kierank> lu_zero: the word "research" in the url should give you a clue [22:37:39] <mru> wtf @ their hello world example [22:39:15] <mru> looks great for spaghetti code [22:42:04] <lu_zero> mru: the example is a bit ill conceived [22:42:31] <lu_zero> kierank: in itself is quite compact [22:43:32] <lu_zero> mru: it could replace most of our preprocessor-template usage [22:43:50] <mru> standard C preprocessor is fine [22:44:38] <lu_zero> mru: s/fine/works-till-a-point [22:45:03] <lu_zero> tracking bugs on macros can be annoying [22:45:19] <mru> so don't put bugs there [22:45:19] <CIA-63> ffmpeg: iive * r25156 /trunk/libavcodec/mpegvideo.c: [22:45:19] <CIA-63> ffmpeg: The debug text output of macroblocks can indicate MB_TYPE_INTERLACED, [22:45:19] <CIA-63> ffmpeg: but it used to do it only for h264 codec. [22:45:19] <CIA-63> ffmpeg: Allow it for other codecs, as mpeg2 and mpeg4 also set this flag. [22:46:10] <mru> having a function call hijacked by unseen code in a different file looks scary [22:46:40] <mru> nor do I see what it would be good for [22:46:57] <mru> it's a "research" project, ignore it [22:47:03] <astrange> the general use is logging other people's code you don't want to touch, i think [22:47:10] <astrange> which is the kind of thing java people want to do [22:48:22] <mru> and which we couldn't care less for [22:50:07] <lu_zero> it can be used for code that has a common chunk to factorize it [22:50:24] <mru> in a most incomprehensible way [22:50:45] <mru> would it be so hard to just put that function call where you want it? [22:51:16] <iive> ok, it wasn't make 3.82 fault. The pathname of the source contained ":" [22:52:09] <mru> instead of writing a complicated description of how what you wrote should be altered to do what you really meant [22:52:23] <mru> isn't that what #pragma dwim is for? [22:53:47] <lu_zero> uh? [22:54:24] <mru> if you want function foo() to call bar() and then baz(), write that [22:54:51] <mru> don't write a function foo that calls baz() and write in another file that, actually, before foo calls baz it should call bar [22:55:24] <lu_zero> like PIXOP2 ... [22:55:37] <mru> I see no resemblance [22:56:43] <lu_zero> that macro generates a batch of function with small differences [22:56:55] <mru> so? [22:57:01] <mru> that's a completely different thing [22:57:20] <mru> it's easy enough to expand it [22:57:31] <mru> and obvious that something like that is going on [22:58:18] <mru> there's no code appearing perfecly normal, but altered by code _in another file_ without prior warning [22:58:38] <mru> if anything, it resembles swscale [22:58:44] <lu_zero> ok, I agree that way to implement it has this shortcoming [22:58:44] <mru> and look how maintainable that is [22:59:00] <lu_zero> mru: swscale had bitten me a lot [23:02:04] <mru> exactly my point [23:03:28] <mru> template systems are fine if when looking at a template, it is immediately obvious that it is one [23:03:36] <mru> well, for certain values of fine [23:04:16] <mru> if you can't tell an actual function from something that will be rewritten by god knows what, you're in trouble [23:06:29] <lu_zero> aspects might help if you have a way to tell where they are applied, I do agree [23:06:43] <lu_zero> (and that's why I like way better python decorators) [23:13:43] <mru> it's a bit like the intercal comefrom directive [23:25:43] <bcoudurier> hey guys\ [23:26:04] <saintdev> i'm confused, it has a typo, is it really an onjoin [23:26:15] <mru> same typo as yesterday [23:26:25] <saintdev> lol, didn't see it yesterday [23:26:55] <saintdev> hey bcoudurier's onjoin script\ [23:27:12] <bcoudurier> lol [23:31:09] <mru> hey look, icc on ia64 [23:31:22] <mru> and it's not pretty [23:32:08] <kierank> I didn't even notice ia64 in fate till now ;) [23:32:47] <mru> we have quite a collection [23:33:11] <bcoudurier> does anybody know zencoder ? [23:33:20] <Dark_Shikari> Yes [23:33:30] <Dark_Shikari> what about them? [23:34:32] <bcoudurier> what are they using ? [23:34:38] <kierank> x264 [23:34:38] <Dark_Shikari> ffmpeg, x264 [23:34:51] <bcoudurier> We fix edge cases. To date, weve solved more than 50 problems compared to a typical transcoding process using a tool like ffmpeg. Without these fixes, youll run into unsupported codecs, audio/video sync problems, intermittent failures, aspect ratio distortion, interlaced content, rotated content, corrupt files, and more. If you just use ffmpeg alone, for example, you wont be able to support dozens of codecs, including some that ar [23:34:51] <bcoudurier> e commonly used. Dont expect to support WPV2, MSS2, files with Quicktime edit lists, etc. [23:35:28] <bcoudurier> this is actually true, though I was wondering what they did to remedy these ? Like using OSX/Windows as a fallback [23:35:30] <kierank> lol biting the hand that feeds you [23:35:51] <bcoudurier> yeah [23:35:52] <bcoudurier> kinda lame [23:35:55] <mru> shall we troll them? [23:36:00] <mru> mediacoder style [23:36:01] <bcoudurier> we should troll them IMHO [23:36:10] <mru> overlays ftw [23:36:17] <Dark_Shikari> bcoudurier: I can contact them and tell them to tell their marketing department to stop being dicks. [23:36:22] <Dark_Shikari> I've worked with them before. [23:36:41] <Dark_Shikari> They _do_ have workarounds for a lot of these issues [23:36:44] <Dark_Shikari> and their point is perfectly valid [23:36:49] <Dark_Shikari> but what they're providing is a _value-add_ [23:36:53] <Dark_Shikari> not a _replacement_ [23:36:58] <mru> have they patched ffmpeg? [23:37:02] <Dark_Shikari> No [23:37:14] <Dark_Shikari> They have your typical Youtube/Facebook-style hackaround script. [23:37:17] <mru> 'cause if they have, sharing would be nice [23:37:36] <Dark_Shikari> Though, arguably, they're not lying [23:37:43] <Dark_Shikari> "compared to a typical transcoding process using a tool like ffmpeg" [23:37:47] <Dark_Shikari> TECHNICALLY, this doesn't imply that they don't use ffmpeg. [23:37:51] <Dark_Shikari> It's saying that their process isn't typical. [23:38:06] <mru> true or not, it's a bit rude [23:38:30] <mru> so if you think you can make them stop, please [23:41:10] <BBB> they don't distribute ffmpeg do they? [23:41:16] <BBB> otherwise I'd ask aaron to piss them off [23:42:15] <Dark_Shikari> of course not [23:42:19] <Dark_Shikari> They're open-source friendly [23:42:23] <Dark_Shikari> it's likely just their marketing being a bit silly [23:42:32] <Dark_Shikari> I poked their CEO [23:42:44] <Dark_Shikari> or main guy, whatever. they're just a startup [23:44:17] <BBB> introduce him to me sometime [23:46:58] <DonDiego> bcoudurier: alternatively, you could finally fix edit lists in mov :) [23:47:14] <DonDiego> mike did that for xine 10 years ago i think... [23:47:36] <Dark_Shikari> lol [23:53:42] <bcoudurier> DonDiego, yeah I should and bug them afterwards ;) [23:54:40] <DonDiego> oh yes, please, let's fix all the issues they mention promptly.. [23:54:54] <DonDiego> and then complain wtf they are talking about.. [23:54:56] <DonDiego> :) [23:56:10] <astrange> my youtube uploads would work a lot better if it supported edit lists deleting the beginning of the video track [23:56:13] <astrange> aka negative pts [23:57:35] <Dark_Shikari> even if that's fixed, youtube won't update until 2015

1 0

IRC log for 2010-09-20
by irc＠mansr.com 21 Sep '10

21 Sep '10

[02:02:34] <saintdev> i wonder if gabriel is ever going to get back to me :( [05:24:33] <peloverde> greetings gentlemen [05:24:39] <thresh> moroning [06:29:30] <KotH> salut mes amis [06:36:08] <Tjoppen> morning [06:39:31] <CIA-63> ffmpeg: mstorsjo * r25147 /trunk/libavformat/udp.c: [06:39:32] <CIA-63> ffmpeg: Check for the IPPROTO_IPV6 define before using it [06:39:32] <CIA-63> ffmpeg: This fixes building on FreeBSD in some configurations, if the IPv6 multicast [06:39:32] <CIA-63> ffmpeg: structs are available, but IPPROTO_IPV6 isn't defined. [07:02:50] <_av500_> gm [07:03:02] <mru> morning [07:05:45] <cartman> mrnng [07:10:26] <KotH> günaydin cartman, av500 [07:10:29] <KotH> hoi mru [07:11:15] <cartman> KotH: av500 knows Turkish since when? ;) [07:11:29] <KotH> cartman: he lives in east turkey :) [07:11:42] <cartman> oooh [07:12:22] <KotH> gtg.. bye boys [07:13:07] <kshishkov> _av500_: Darmstadt may be not the best place around here, but it's lovely [07:14:21] <_av500_> gee [07:14:35] <_av500_> where gave you been :) [07:16:29] <kshishkov> just walked in the direction Hbf - Univ.Library (aka Schloss) - somewhere yonder [07:16:44] <kshishkov> BTW, some of your trams are outdated, the reek of steam [07:17:45] <_av500_> kshishkov: yeah, it was steam train days [07:18:23] <kshishkov> _av500_: also good shop at Hbf building, it has almost sane working hours [07:19:32] <_av500_> its the only one :) [07:20:01] <kshishkov> yes, and it has suspiciously long queues. I thought Germans don't like shopping on Sundays [07:21:04] <_av500_> germans dont like anything [07:21:41] <kshishkov> even beer? [07:22:12] <_av500_> there is always an exception [07:23:45] <kshishkov> _av500_: personally I'd pick Darmstadt for living over Berlin or Frankfurt. But not Sundsvall or Stockholm. [07:24:10] <mru> you're too picky [07:24:26] <mru> oslo was ok [07:24:27] <kshishkov> indeed I am [07:24:30] <mru> a bit too expensive [07:24:58] * thresh has been on dacha eating shashlyk all the weekend. [07:25:22] <_av500_> thresh: so a good morning today? [07:25:26] <kshishkov> thresh: ÐœÑ ÑÑ ÐµÐ³ÐŸ Ð¿ÐŸÐ¶Ð°ÑÐžÐ» Ð±Ñ ÑÐœÐ°ÑÐ°Ð»Ð° ÑÑÐŸ Ð»Ðž [07:25:40] <thresh> av500: not quite, I didnt get enough sleep [07:26:27] <_av500_> you ruskies complain even more then ze germans [07:26:39] <kshishkov> mru: Oslo left an impression of lacking taste completely. And wobbly pavement. And garbage on Jernvegtorget. [07:26:41] <lu_zero> good morning [07:27:14] <kshishkov> lu_zero: it "buon giorno" or "yawn" in Italian? [07:27:22] <thresh> OTOH, i'll probably move to a new flat in Nov [07:27:26] <thresh> so that kinda makes me happy [07:27:48] <kshishkov> thresh: where to? [07:27:56] <lu_zero> kshishkov: "buon giorno" [07:28:02] <thresh> kshishkov: still here, Moscow Area [07:28:17] <lu_zero> the tired alternative is " 'ngiorno" [07:28:54] <kshishkov> lu_zero: noted, thanks [07:29:59] <kshishkov> thresh: http://divov.livejournal.com/268200.html , next to last sentence [07:30:42] <thresh> kshishkov: yep, Moscow sucks for living [07:31:06] <thresh> that's why I'm just outside, so ~20 EUR for taxi and you're in Moscow [07:32:53] <thresh> 2 EUR if you can travel with filthy co-citizens [07:35:38] <cartman> thresh: I do that everyday [07:35:41] <cartman> feels refreshing [07:36:40] <thresh> you mean travel with low-class citizens? [07:38:42] <cartman> there is no low-class citizens, there are just people who I politically disagree :p [07:43:01] <lu_zero> uhm how to make ffmpeg not try to read from stdin? [07:43:09] <Dark_Shikari> don't use -i -? [07:43:38] <kshishkov> lu_zero: ffmpeg -i infile < /dev/null [07:45:03] <lu_zero> I'm trying to see if the pipe protocol works for fd with a different number both for send and receive [07:49:56] <j0sh> i thought pipes worked from stdin only? [07:50:02] <j0sh> unless you explicitly pass a named pipe [07:50:16] <lu_zero> nope [07:50:31] <mru> on linux you can say /dev/fd/X [07:50:33] <lu_zero> pipe is supposed to work passing the fd number [07:50:34] <mru> for any X [07:50:48] <lu_zero> e.g pipe:5 [07:51:02] <mru> and that [07:51:08] <j0sh> fd == any fd? even, say, sockets? [07:51:23] <mru> read and write work any fd [07:51:27] <mru> that's the beauty [07:51:31] <j0sh> cool [07:51:34] <Dark_Shikari> "everything's a file" [07:51:44] <mru> except sysv ipc [07:52:45] * Dark_Shikari loves how firefox takes 5 minutes to close because of de-swapping itself [07:53:01] * mru doesn't use swap [07:53:07] * j0sh uses chrome [07:53:29] <mru> I'd try it if it didn't depend on dbus and gconf [07:53:32] <Dark_Shikari> mru: even if there was no swap it would still take ages, half of the time it's actually cpu-bound [07:53:39] <mru> wow [07:53:44] <Dark_Shikari> yes, cpu-bound on SHUTDOWN [07:53:47] <microchip_> closes really fast here [07:53:55] <Dark_Shikari> microchip_: has it been open with 100 tabs for 3 days? [07:53:57] <mru> kill -9 [07:54:03] <microchip_> nope [07:54:08] <Dark_Shikari> mru: then it loses its cache, and it has to redownload everything [07:54:17] <Dark_Shikari> so it takes... a billion times longer to start up again. [07:54:19] <microchip_> 100 tabs, lol [07:54:30] <Dark_Shikari> The best part is how if you have firefox open for a few days with a lot of tabs [07:54:33] <Dark_Shikari> then you close them all [07:54:36] <Dark_Shikari> it still uses 1.5GB [07:54:45] <Dark_Shikari> And it still takes 5 minutes to shut down [07:54:48] <lu_zero> Dark_Shikari: which firefox are you using? [07:54:51] <Dark_Shikari> latest [07:54:55] <microchip_> doesn't clean up its mem? [07:55:02] <Dark_Shikari> microchip_: leaaaaaaaaaaaak [07:55:38] <ohsix> Dark_Shikari: bartab [07:56:03] <lu_zero> 4beta5 was quite fine [07:56:03] <Dark_Shikari> ohsix: that doesn't stop firefox from leaking [07:56:12] * lu_zero is trying 4beta7 now [07:56:14] <Dark_Shikari> bartab would help if the problem actually _was_ tabs eating memory [07:56:21] <Dark_Shikari> but even if I *close* them all, it still doesn't save any memory [07:56:27] <Dark_Shikari> I've actually seen memory usage go *up* after closing tabs. [07:56:41] <ohsix> vm size changing isn't a leak [07:57:00] <Dark_Shikari> 1.5 gigabytes of allocated memory with nothing open is a leak [07:57:01] <Dark_Shikari> fullstop [07:57:23] <ohsix> and it doesn't tell you what memory is actually being used in said vm space [07:57:27] <Dark_Shikari> And you can't claim "oh, it's not being used", because if it wasn't being used, it wouldn't have to swap every last bit back in when shutting down firefox. [07:58:05] <mru> strictly speaking it isn't a leak [07:58:16] <ohsix> if its really discardable ff shouldn't touch it on shutdown, and maybe it does do too much of that [07:58:17] <mru> precisely because it _is_ able to access it again [07:58:45] <Dark_Shikari> mru: not really, since it keeps its own VM subsystem [07:58:51] <mru> if it were truly leaked, there'd be no references left to it, and the shutdown wouldn't be able to bring it in [07:58:55] <Dark_Shikari> if I make a program that keeps a list of all mallocs, but still doesn't try to free them [07:58:58] <Dark_Shikari> it's still leaking [07:59:04] <ohsix> before they switch to jemalloc the vm size was really fun with the default allocators :] [07:59:05] <Dark_Shikari> just keeping a list doesn't make it not a leak [07:59:09] <mru> bloat is the proper technical term for it [07:59:28] <Dark_Shikari> mru: I would define a leak as an O(N) memory usage that is not reduced when reducing N. [07:59:35] <Dark_Shikari> at least, the kind of leak that matters. [07:59:55] <Dark_Shikari> for example, O(tabs opened). [08:00:05] <mru> if as you suggest, they simply track mallocs and free them on exit, then it's a leak [08:00:16] <Dark_Shikari> mru: well they have their own VM subsystem basically [08:00:25] <lu_zero> uhm [08:00:26] <Dark_Shikari> so even if firefox itself leaks like crazy, it'll still free on close [08:00:36] <Dark_Shikari> since on close the whole system is destroyed [08:00:38] <mru> which is utterly pointless [08:00:47] <lu_zero> we lack a way to suppress streams in an effective way... [08:00:52] <mru> when a process exits, all its resources are freed by the os [08:00:54] <ohsix> VIRT is not an accurate assessment of anything; except if its growing fast its suspicious [08:00:55] <lu_zero> and -map doesn't help at all [08:01:19] <Dark_Shikari> ohsix: Sure it is [08:01:23] <mru> virtual size could be all null cow pages [08:01:27] <Dark_Shikari> it's an accurate assessment of when firefox will crash. [08:01:29] <Dark_Shikari> Extremely accurate. [08:01:34] <Dark_Shikari> When firefox hits 1.5GB VIRT, it crashes. [08:01:36] <Dark_Shikari> (roughly) [08:01:46] <Dark_Shikari> I have replicated this at least 50 times over 2+ years. [08:01:54] <Dark_Shikari> It has never passed that mark without crashing. [08:02:03] <Dark_Shikari> (NB: 32-bit OS) [08:02:03] <mru> mine's at 950M now [08:02:06] <Dark_Shikari> er, 32-bit firefox. [08:02:09] <Dark_Shikari> 64-bit OS [08:02:13] <ohsix> are you on an os with a 2g:2g address split for user/kernel? [08:02:15] <Dark_Shikari> Yes [08:02:20] <Dark_Shikari> That's why it crashes [08:02:24] <Dark_Shikari> It runs out of address space [08:02:29] <Dark_Shikari> Thus, VIRT does matter. [08:02:35] <Dark_Shikari> Because VIRT is the amount of address space it's using. [08:02:44] <kshishkov> maybe it's their subtle way of encouraging people using 64-bit? [08:03:01] <ohsix> not as an indicator of a leak; also ff has a hard cap you have to willfully override for that aspect [08:03:04] <Dark_Shikari> Not while their 64-bit builds are still slow as fuck [08:03:12] <Dark_Shikari> ohsix: no, it doesn't have a cap. [08:03:21] <Dark_Shikari> And yes, that is an indicator of a leak [08:03:23] <Dark_Shikari> a leak of VM [08:03:39] <kshishkov> you know, a lot of problems can be solved by simply adding a near-infinte amount of RAM (or so Java/Firefox/Windows devs think) [08:03:41] <ohsix> how do you leak vm [08:04:32] <Dark_Shikari> ohsix: ever-increasing allocation that never gets freed [08:04:33] <ohsix> just the same, i'll dig up the memory limit thing in a bit here [08:04:34] <Dark_Shikari> trivial. [08:04:43] <Dark_Shikari> I have never modified any memory limit settings. [08:04:48] <Dark_Shikari> The only memory limit is the point where it segfaults. [08:04:54] <Dark_Shikari> Because it doesn't check its mallocs. [08:04:57] <kshishkov> Dark_Shikari: 64-bit Firefox is faster and takes less RAMsince it doesn't have Flash plugin by default [08:05:04] <Dark_Shikari> kshishkov: The JIT is still shit [08:05:06] <Dark_Shikari> or nonexistent [08:05:13] <ohsix> vm is taken in huge chunks by heaps that still might have >0 items in there; the heaps won't go away [08:05:30] <Dark_Shikari> ohsix: Which means that their allocator is a pile of shit [08:05:46] <ohsix> ehh, the 64bit jit stuff was pushed up to 6.4 [08:05:47] <Dark_Shikari> they should stop reimplementing the wheel badly [08:06:24] <ohsix> they aren't; the heap stuff was old news years ago when they switched to jemalloc, stop moving the goalposts :P [08:06:37] <Dark_Shikari> this doesn't make a difference though, it still crashes [08:06:54] <ohsix> and they fixed it because the crt alllocator on windows was really bad for the working set [08:06:59] <Dark_Shikari> Under a working heap system, the worst-case scenario would be that firefox always uses the peak memory usage. [08:07:08] <Dark_Shikari> that is, suppose firefox uses 600MB at peak due to lots of tabs [08:07:17] <Dark_Shikari> the worst case is it can never free any of the heap blocks because there's one object in each [08:07:21] <Dark_Shikari> thus, memory usage stays at 600MB. [08:07:44] <Dark_Shikari> however, because firefox is broken and shit, the results it gets are worse than this hypothetical worst-case. [08:08:06] <Dark_Shikari> in short, firefox should have memory usage O(max tabs open at once) [08:08:12] <elenril> why don't you switch to chromium then? [08:08:12] <microchip_> how is IE doing with so many tabs? [08:08:13] <mru> any form of garbage collection is a very selfish form of memory "management" [08:08:22] <Dark_Shikari> but instead it has memory usage O(A*max tabs open at once + B*total tabs opened ever) [08:08:28] <ohsix> heap usage will go down; in vm they can be discontiguous and moved around, the decoupling of the two is important [08:08:29] <Dark_Shikari> elenril: no tree style tabs [08:08:31] <Dark_Shikari> interface is shit [08:08:43] <mru> "if I can't use this memory, then neither shall anybody else" [08:09:06] <Dark_Shikari> mru: if "garbage collection" worked, it would rm /usr/bin/firefox [08:09:16] <kshishkov> mru: in Russian it's called "dog on hay" [08:10:12] <ohsix> if you rm firefox while its running, garbage collection will work when the in core inode is closed :D [08:11:07] <kshishkov> ohsix: yes, that's an old trick for creating really temporary files [08:12:00] <microchip_> Dark_Shikari: have you used IE with so many tabs? [08:12:10] <ohsix> dunno if its a trick if it was planned to work like that, and linux can open stuff in /proc/pid/fd and keep them around [08:12:22] <lu_zero> Dark_Shikari: beta7 seems not to keep having memory growing per tab [08:12:52] <kshishkov> ohsix: yes, it was - IIRC I read about it in some very old book on C programming [08:13:21] <Dark_Shikari> microchip_: it's probably terrible [08:13:32] <Dark_Shikari> chrome works quite well but the interface just doesn't work [08:13:42] <ohsix> i guess; but you could also read how the os handles files, and back then it was pretty comprehensible, shrug [08:13:53] <kshishkov> lu_zero: did they plug a leak completely or just made it slower? [08:14:35] <ohsix> Dark_Shikari: do you have browser.cache.memory.capacity anywhere in about:config [08:14:40] <kshishkov> ohsix: yes, it's Unix trick. IIRC same story with creating empty file - create, seek, close [08:15:23] <ohsix> the real trick to that is if the fs supports extents and sparse files it'll be instant :P [08:15:37] <Dark_Shikari> ohsix: nope [08:15:56] <lu_zero> kshishkov: given memory usage goes down I think they plugged it [08:16:20] <Dark_Shikari> haven't they claimed to have plugged it every one of the last 15 versions? [08:16:33] <ohsix> k, are you using anyt extensions that are more than just xul/xbl bindings? like ones with 3rd party xpcom objects or .dll's [08:16:37] <lu_zero> Dark_Shikari: they did for me since 3.6 [08:16:51] <Dark_Shikari> have they fixed the entire browser being singlethreaded? [08:16:52] <lu_zero> at least my usage pattern [08:17:08] <Dark_Shikari> ohsix: the only particularly intensive extension I have is probably adblock [08:17:15] <lu_zero> Dark_Shikari: plugins live in different processes at least [08:17:21] <ohsix> Dark_Shikari: the kind of minification you're asking for is just migrating heaps and giving the vm space back [08:17:31] * lu_zero is puzzled [08:17:40] <Dark_Shikari> lu_zero: yeah but that doesn't help when firefox is slower than flash [08:17:42] <Dark_Shikari> i.e. all the time [08:18:07] <lu_zero> Dark_Shikari: flash (and java) are the only crashing parts in firefox [08:18:15] <lu_zero> at least for my usage [08:18:19] <Dark_Shikari> firefox is a pretty crashy part of firefox [08:18:25] <lu_zero> not for me [08:18:32] <ohsix> Dark_Shikari: we'll get on top of this this time around, brb [08:18:48] <lu_zero> the only time it was crashing was for flash and java [08:19:01] <Dark_Shikari> "the only time it crashed was when I was using it" [08:19:10] <kshishkov> Dark_Shikari: elinks - >60 tabs open, 84MB VM, builting adblock. Not closing it for a week [08:19:13] <lu_zero> now I get the sad lego brick from time to time [08:19:28] <Dark_Shikari> kshishkov: it's easy to fit in 84MB if you don't have to display images [08:20:02] <kshishkov> Dark_Shikari: I find that images are not needed in many cases [08:20:23] <Dark_Shikari> 90% of the worthwhile content on the internet is lolcats [08:20:24] <elenril> inb4 4chan [08:21:00] <funman> http://i.imgur.com/du8LI.jpg [08:21:04] <kshishkov> Dark_Shikari: it's tvtropes for elenril [08:21:40] <ohsix> the way ff picks its memory cache size is probably a bit optimistic; barring other stuff playing around in its address space anyways (and theres a lot of crap that does on windows, like mouse software [08:21:57] * elenril wonders why does flash seem faster inside xephyr [08:22:04] <Dark_Shikari> "just allocate all you want" is an optimistic strategy, yes [08:22:39] <ohsix> its not that, either; and like i said its just vm space in the end, they're long lived objects and sometimes they're ejected; that's what the os is supposed to do [08:23:05] <kshishkov> Dark_Shikari: allocate all you want with 150% ratio just in case [08:23:10] <ohsix> but i'm still perplexed by the fact that firefox crashes before the os totally wedges itself; i've had ff crash on windows a lot, but not without really weird circumstances [08:23:36] <Dark_Shikari> ohsix: the OS is 64-bit [08:23:41] <Dark_Shikari> it won't wedge itself when an app allocates 2GB [08:23:57] <ohsix> ff does have a "leak" of sorts on windows too, but not because its leaking objects but with gdi its an untracked "heap" of finite size and they don't measure how many objects they use [08:24:14] <ohsix> right, but memory is hardly as inexaustable as other things ff uses [08:24:23] <Dark_Shikari> yada yada gdi objects yada yada [08:24:46] <ohsix> :] i've got bug numbers at least! [08:26:27] <ohsix> think about how bad it would be if file handles had the same visibility of gdi objects; generally you can assume you can open 32 files no problem, maybe up to 1024; but people know those numbers and they can set the policy for them with one composite number; and when you exceed the limit it doesn't totally thrash the ui of the os, or break file i/o in already open files [08:27:55] <ohsix> anyways, gonna find the name of the rdf i need to look at and how to get a list of dlls in a process with stuff that already comes with windows, should give up some info, if its firefox and some other junk running in its address space you can probably "fix" it by sidestepping the problem and shrinking the memory cache instead of letting it do its heuristics [08:28:27] <Dark_Shikari> but what happens when it runs out of memory? [08:28:29] <Dark_Shikari> it'll just crash [08:28:36] <Dark_Shikari> even if it doesn't hit the address space limit [08:28:40] <Dark_Shikari> it's practically the same thing [08:28:43] <Dark_Shikari> it means a malloc will fail [08:29:06] <ohsix> have you let it generate a minidump? [08:29:13] <ohsix> what module is it faulting in [08:29:18] <Dark_Shikari> dump? what? it just sends me to the windows crash screen [08:29:30] <ohsix> try "view contents of report" [08:29:46] <Dark_Shikari> meh, next time. [08:29:51] <ohsix> but a dumpfile is also generated somewhere in system32 [08:29:52] <Dark_Shikari> it'll be another few days before it hits enough memory [08:30:01] <ohsix> word [08:30:17] <ohsix> brb i'll get that info in a few [08:35:44] <ohsix> Dark_Shikari: the extensions.ini/rdf file from the profile dir you're using and the output of tasklist /fi "imagename eq firefox.exe" /m [08:36:44] <Dark_Shikari> firefox.exe 4488 ntdll.dll, wow64.dll, wow64win.dll, wow64cpu.dll [08:37:37] <ohsix> to a pastebin that is [08:37:42] <Dark_Shikari> That's it. [08:37:43] <Dark_Shikari> It's one line. [08:37:45] <Dark_Shikari> Why pastebin it? [08:38:14] <ohsix> extensions.rdf/ini should be a k or two [08:38:28] <Dark_Shikari> well yes, but I meant the other one [08:38:34] <ohsix> k [08:38:47] <Dark_Shikari> http://www.mediafire.com/?zwpv71eaptiadkl [08:38:58] <ohsix> its weird that xul.dll isn't even in there; not sure how tasklist deals with wow64, it might need voodoo [08:40:30] <ohsix> i know process explorer will list the modules, if you already have it handy [08:40:57] <Dark_Shikari> any magic from extensions.rdf? [08:41:48] <ohsix> ya it'll take a bit to filter out the junk though, wanna take it to pm? [08:41:55] <mru> #define __yyrhdgdtfs66ytgetrfd unsigned long long [08:41:57] <Dark_Shikari> don't really care [08:42:07] <ohsix> thought someone else might [08:42:09] <Dark_Shikari> mru: #define long long long [08:42:09] * mru blames funman for ^ [08:42:46] <funman> i have to add a "Â© Ac1dB1tch3z" [09:23:25] <funman> mru: i dont see a VERSION in lame.h [09:24:10] <mru> me neither [09:24:29] <funman> hip_decode_init() is still present in the header btw [09:24:47] <mru> yes, I know [09:24:51] <funman> you could try to redefine it and see if it breaks? [09:27:47] <funman> if that sounds ok i can make a patch [09:28:07] <mru> let me think about it [09:45:05] <funman> where can i checkout svn for ffmpeg.org website? [09:45:40] <mru> svn://svn.ffmpeg.org/ffmpeg.org/trunk [10:31:19] <mru> no reply to the stack alignment question [10:38:43] <mru> cartman: did you stop running your ubuntu/clang fate config? [10:39:01] <cartman> mru: I thought it was reduntant [10:39:11] <cartman> s/t/d [10:39:21] <mru> yes, agree [10:39:27] <cartman> okies [11:35:18] <CIA-63> ffmpeg: banan * r25148 /trunk/libavcodec/imgconvert.c: Support deinterlacing of YUVJ420P. [11:36:14] <merbzt> is there a way of getting rid of all the bytestream warnings ? [11:36:25] <mru> example? [11:36:41] <merbzt> libavcodec/bytestream.h:44: warning: âbytestream_get_le64â defined but not used [11:37:08] <mru> what configuration are you using? [11:37:19] <mru> those are all inline [11:37:23] <mru> shouldn't be warned about [11:38:02] <merbzt> lucid stock conf [11:38:13] <mru> doesn't mean a thing me [11:38:20] <mru> and you didn't say what ffmpeg configuration [11:38:25] <mru> any unusual options? [11:38:33] <wbs> --disable-optimizations may give that [11:38:35] <wbs> iirc [11:38:36] <merbzt> er ok :) [11:38:44] <merbzt> yeah those are a bit unusual [11:39:09] <merbzt> disable optimizations [11:40:41] <mru> then you get what you asked for [11:40:51] <mru> why are you doing that anyway? [11:40:56] <mru> did that boost troll get to you? [11:48:54] <merbzt> mru: just hacking around abit [11:52:23] * jannau has still a patch to define av_always_inline to av_unused to avoid the warnings for --enable-small || --disable=optimizations [11:53:44] <mru> that's the wrong fix for small [11:54:08] <mru> most of the always_inline functions really should always be inlined [12:01:48] <jannau> I'm just describing current configure behaviour. micheal added that in r3101 [13:30:19] <mru> hmm, michael seems unusually ranty today [13:47:20] <lu_zero> and on a subject in which there isn't much to beat [13:47:34] <lu_zero> we aren't talking about gcc or glibc [13:52:00] <kshishkov> quite flamy statement you've made here [13:52:35] <mru> gdb is better at what it does than gcc is at what it does [13:55:33] * kshishkov still thinks that GCC primary goal is to boldly spread FSF hype [13:55:56] <mru> without a doubt [14:31:53] <mru> BBB___: still no reply on icc [14:43:36] <_av500_> mru: its a forum, replies come after days... [14:44:18] <mru> well, not so much replies [14:44:31] <mru> more like... I think I'm having this issue too [14:44:46] <mru> I use -fsome-completely-other switch, and it not work as I want [14:44:51] <mru> plz give me teh codez [14:46:54] <kierank> also "mru plz can i have your email adress. I want to talk 2u about dis problem" [14:48:25] <spaam> if you dont give the it to mru. then mru will be like this panda http://idiotube.com/2010/09/never-say-no-to-a-panda/ ? ;O [15:09:16] * KotH hates customers who think using keil-C is supperior to using gcc, when every code was written for the gcc/gas toolchain and they dont have the time to properly port stuff [15:10:08] <mru> if the code is written for gcc and known to work well with it, there's no reason to switch [15:10:21] <jenk> switch to clang to piss of RMS [15:11:19] <mru> and feed jobs' ego? [15:11:49] <kshishkov> mru: do you think it will notice your feeding? [15:11:58] <mru> no [15:12:00] <mru> nor will rms [15:13:33] <kshishkov> at least rotten fruit company doesn't make fuss over inside software, only on end result [15:13:55] <jenk> what does $teve have to do with clang? [15:14:06] <mru> apple wrote most of it [15:14:29] <mru> and when apple decides to abandon it, it will die [15:14:32] <mru> _when_ [15:14:35] <jenk> o [15:14:47] <jenk> maybe llvm will support it [15:14:47] <KotH> mru: $customer thinks that keil is better because you pay for it [15:14:52] <kshishkov> mru: RMS abandoned Emacs and it got better [15:15:04] <mru> KotH: I can sell them a copy of gcc [15:15:17] <KotH> mru: that quite a bit of code miscompiles with keil is a different story... and we are not yet talking about the switch from at&t asm to keil asm [15:15:30] <KotH> mru: PLEASE DO! [15:15:35] <mru> what target? [15:15:40] <KotH> arm7 [15:15:42] <mru> at&t? [15:15:49] <KotH> at&t asm syntax [15:15:57] <mru> at&t arm wtf? [15:16:22] <KotH> isnt that was gas uses? [15:16:27] <mru> gas uses gas syntax [15:16:33] <KotH> hmm.. [15:16:44] <mru> what is commonly referred to as "at&t" is a specific syntax for x86 asm [15:16:45] * KotH thought that gas syntax was derived from at&t asm [15:16:54] <KotH> oh..kay.. didnt know [15:17:03] * kshishkov wonders why gas uses AT&T syntax and C was developed in Bell Labs, them being the same company [15:18:01] <KotH> kshishkov: uhmm.. because the fsf thought it would be wise to do everything the same way as the big unix tools did [15:18:18] <KotH> ie, just reimplement their tools w/o much improvement [15:19:44] * kshishkov thinks that Unix was big improvement [15:26:39] <KotH> to what? [15:26:43] <KotH> multics? ;) [15:30:44] <mru> KotH: try getting your customer to use keil ds-5 [15:30:53] <mru> it's gcc with a price tag [15:32:58] <mru> and traditional keil is just armcc in a different wrapping [15:33:37] <mru> and keil itself is owned by arm [15:41:55] <KotH> mru: is ds5 a current product or will it be replaced by the armcc based one? [15:42:13] <KotH> but it really looks good :) [15:42:15] <mru> it's a rather new product [15:42:57] <KotH> cool! [18:08:10] <twnqx> hm, what was the reason of âNULLâ undeclared (first use in this function) again... [18:08:36] <funman> missing stdlib.h [18:09:15] <spaam> :) [18:09:54] <twnqx> uh. i thought that wasn't necessary... [18:13:33] <funman> the definition must come from somewhere [18:13:58] <spaam> /* Get size_t, wchar_t and NULL from <stddef.h>. */ [18:14:10] <mru> stddef.h is where the spec says it's defined [18:14:39] <mru> stdlib.h also [18:15:02] <mru> if you care about fractions of sections of build time, stddef.h is likely faster to parse [18:15:40] <funman> if you want to use more power and destroy the planet, #define _GNU_SOURCE #include <stdlib.h> [18:23:50] <lu_zero> ^^; [18:25:05] <spaam> o,o [18:42:26] <mru> http://news.ycombinator.com/item?id=1709564 [18:43:07] <mru> comment by one zentechen: Does it support .rmvb format? [18:43:19] <mru> (about vlc on ipad) [18:45:56] <_av500_> ocourse [18:46:16] <cartman> RMS will soon chime in I bet [18:46:59] <mru> he doesn't have a stake in vlc so his opinion doesn't count [18:47:06] <cartman> he ownz GPL [18:47:19] <lu_zero> that won't say anything [18:47:29] <mru> he had a hand in writing the text of the gpl, yes [18:47:30] <cartman> GPL is not compatible with AppStore [18:47:39] <cartman> hence he can flame all day long [18:47:51] <mru> that's his opinion [18:47:54] <lu_zero> cartman: I don't see why [18:47:57] <mru> and flame he will [18:48:02] <cartman> lu_zero: I think due to signing [18:48:03] <lu_zero> hi DonDiego [18:48:08] <lu_zero> cartman: so? [18:48:11] <mru> apple and the vlc devs seem not to mind [18:48:20] <cartman> lu_zero: incompatible with some GPL section bla bla [18:48:26] <mru> but it's not [18:48:33] <mru> they do give you the source code [18:48:52] <mru> the gpl doesn't require the source to be included in the binary distribution [18:49:04] <mru> it doesn't even have to be available through the same channels [18:49:15] <mru> all it requires is that the source is available _somehow_ [18:49:19] <mru> at no additional cost [18:49:36] <cartman> I don't care, I hope GPL dies :P [18:51:02] <lu_zero> I hope it doesn't [18:51:11] <_av500_> now, if i take vlc from app store and start charging $10 for it, call it "superduperplayer"? [18:51:11] <funman> <@mru> he doesn't have a stake in vlc [18:51:14] <mru> s/gpl/rms/ [18:51:15] <funman> you wish! [18:51:28] <mru> funman: I don't see any (c) rms in there [18:51:37] <mru> I do see some (c) mru though [18:51:37] <_av500_> and i advertise .rmvb.... [18:51:38] <funman> he bought us [18:51:49] <funman> http://www.fsf.org/campaigns/playogg/ [18:52:04] <cartman> GPL shall die, LGPL shall prevail [18:52:07] <cartman> or BSD ;) [18:52:31] <iive> cartman: i didn't quite get what's the problem with gpl? [18:52:55] <cartman> iive: it has weird restrictions like this, RMS gets a stake somehow too [18:53:13] <iive> cartman: what restriction? [18:53:18] <mru> cartman: the appstore problem is a figment of rms' imagination [18:53:20] <cartman> iive: AppStore vs GPL [18:53:42] <iive> cartman: url? [18:53:58] <mru> apparently the appstore displays some boilerplate eula whenever you download anything [18:54:01] <cartman> iive: http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement [18:54:12] <mru> and this is of course not compatible with gpl [18:54:16] <mru> but that doesn't matter [18:54:36] <mru> apple don't the right to alter the license terms of software the don't own [18:54:41] <mru> they don't own vlc [18:54:44] <funman> cartman: http://geekz.co.uk/lovesraymond/archive/gpl-3-democracy [18:55:02] <mru> thus anything they might try to apply won't stick [18:55:21] <cartman> funman: lol [18:58:15] <iive> cartman: apple is not compatible with freedom. [18:59:05] <iive> It's not gpl problem, it's just how apple do their business. [18:59:28] <cartman> well if the authors of an app is OK with it its not FSF's busines [18:59:30] <cartman> +s [18:59:53] <iive> there is reason android is getting so popular. [19:00:35] <cartman> Android is good [19:00:38] <cartman> Google is evil [19:00:42] <cartman> as evil as Apple [19:00:50] <iive> no, not yet. [19:00:55] <mru> I have no idea what evil agenda they might have [19:01:01] <mru> but their products work well [19:01:07] <mru> I can't say that about apple [19:01:29] <mru> and they don't dictate how people are to use their products [19:01:45] <iive> mru: i guess you tried to program for apple platform, and that's sin! [19:02:17] <mru> pre-osx macs would crash if I entered the same room [19:02:27] <mru> osx is just obnoxious [19:02:34] <cartman> Apple's products are nice too [19:02:38] <cartman> too bad they are evilest [19:03:15] <mru> I find them impossible to use [19:03:37] <cartman> OSX is pretty [19:03:48] <mru> yes, it is pretty [19:03:54] <mru> but it's not very useful [19:03:56] <cartman> and works for me :P [19:08:12] <iive> i've heard that apple products are like roads in a forest. It makes good road to do the stuff you usually do, make it good and easy to go. But if you want to get off the road and do something else [19:08:17] <iive> you hit a tree. [19:09:57] <_av500_> an apple tree? [19:13:07] <iive> most probably [19:13:47] <lu_zero> android is something that works to a point [19:14:24] <lu_zero> but I can say the same for iphone [19:14:25] <_av500_> as everything else [19:14:41] <lu_zero> coding for them is a complementar nightmare [19:15:04] <cartman> Eclipse + java is as bad as it gets [19:15:17] <lu_zero> cartman: I'm not using them [19:15:26] <cartman> I meant for programming Android [19:15:32] <lu_zero> I'm not using them [19:15:42] <_av500_> cartman:i use make [19:15:46] <cartman> yeah ok that makes you and well you [19:16:00] * lu_zero uses make as well [19:16:03] <lu_zero> (and ant) [19:16:07] <lu_zero> (and adb) [19:16:11] <cartman> your ability to miss the point is great ;) [19:16:18] <cartman> you use crap java in the end [19:16:22] <lu_zero> cartman: NO [19:16:30] <cartman> you use NDK ok beats me [19:16:31] <cartman> :P [19:16:53] <lu_zero> IFF the java crap were working I wouldn't spend a week trying to figure out which sdl port is not working less [19:17:20] <cartman> in the end its low standards compared to iOS development [19:17:23] <cartman> XCode is a breeze [19:17:35] <cartman> clang is coming along nicely [19:17:42] <lu_zero> cartman: I must say something on that as well [19:17:54] <lu_zero> since the simulator is a joke [19:18:31] <_av500_> which one? [19:18:38] <cartman> Android simulator doesn't work right with WV800 resolution for me [19:18:48] <cartman> starts with wrong resolution sometimes [19:18:53] <lu_zero> android has a full emulator... [19:18:56] <_av500_> android sim sucks [19:18:59] <lu_zero> iphone a... [19:19:01] <_av500_> big time [19:19:07] <cartman> _av500_: agreed [19:19:08] <_av500_> lu_zero: i prefer the iphone one [19:19:11] <lu_zero> ...x86 port with stub libs [19:19:33] <_av500_> its how we did our prod dev in the past, compile for arm and x86 [19:19:39] <cartman> anyhow too hot in this room! bye! [19:19:39] <_av500_> that forces you to write clean code :) [19:20:10] <lu_zero> _av500_: neon asm isn't that well supported ^^; [19:20:29] <_av500_> in the emu? its armv5 iirc [19:20:44] <lu_zero> qemu supports neon quite well [19:20:50] <_av500_> not the one i tried [19:21:00] <_av500_> it just barfedd on the 1st neon i gave it [19:21:10] <_av500_> that was like 6mo ago.. [19:21:14] <lu_zero> uhmm [19:21:15] <_av500_> might have changed [19:21:26] <lu_zero> qemu changes _quite_ quickly [19:21:32] <_av500_> lu_zero: i gve it a yuv420 to 422 [19:21:39] <_av500_> and it just crashed [19:21:45] <mru> the qemu bugs change quickly [19:21:51] <lu_zero> mru: indeed [19:22:01] <mru> there is no qemu with correct neon emulation [19:22:08] <_av500_> see [19:22:32] <_av500_> mru: hence the idea of a gumstick in the express card slot :) [19:22:37] <_av500_> your [19:22:45] <lu_zero> theheh [19:22:46] <mru> yeah [19:22:49] <mru> it would fit [19:22:58] <lu_zero> might be interesting [19:23:12] <_av500_> you can ducktape a bb to your vaio [19:23:12] <mru> can expresscard "shells" be obtained easily? [19:23:27] <mru> I have one on the table next to it [19:23:27] <_av500_> mru: buy some crap usb3.0 host and gut it :) [19:23:38] <mru> I was consider that option [19:23:53] <_av500_> thn solder vcc and 4 wires for usb [19:25:28] <mru> bonus points for including an hdmi port [19:25:56] <_av500_> your laptop has hdmi input? [19:26:27] <mru> of course not [19:26:54] <_av500_> if you have an external monitor, you can use a bb as well [19:27:11] <_av500_> the monitor is quite larger [19:27:36] <_av500_> bonus points for a fake framebuffer that gets read back to the host via the pciE :) [19:28:09] <mru> or a pcie busmaster writing to the host framebuffer [19:28:57] * _av500_ decides to take a photo of the moon [19:30:21] <funman> _av500_: check out jupiter! [19:30:41] <mru> svn co jupiter? [19:30:47] <_av500_> no telescope here [19:31:40] <mru> bad weather for moon photos here [19:31:49] <mru> too much of something in the air [19:43:15] <bcoudurier> hey guys\ [19:46:49] <mru> adding a typo to the scripted greeting, clever [19:47:07] <bcoudurier> I just mistyped :/ [19:47:45] <bcoudurier> hey mru, sup ? [19:48:01] <mru> just the usual trolling [19:52:08] <BBB> how random can a random greeting script really get? [19:52:16] <BBB> hi bcoudurier :) [19:54:26] <_av500_> there: http://www.flickr.com/photos/av500/5008917453/ [19:55:45] <funman> nice! [19:56:03] <funman> can you photograph the dark side of the moon too? (i imagine with a flash it can be possible) [19:56:21] <peloverde> BBB: You might want to mention gcc loop unrolling and split sections in your defense of yasmification [19:56:51] <mru> funman: easy, just wait for a new moon [19:57:05] <mru> then the dark side is facing earth, and photographing it is easy [19:57:36] <mru> the earthlight is sufficient [20:01:17] <DonDiego> _av500_: ah, i see plenty proof of your forking :) [20:01:58] <_av500_> yep [20:02:04] <jannau> _av500_: congrats [20:02:08] <_av500_> thx [20:02:17] <_av500_> funman: http://www.flickr.com/photos/av500/5008940349/ [20:02:40] <BBB> peloverde: can't you just jump in and say "I like yasm better"? [20:02:41] <BBB> :-p [20:02:42] * cartman goes and look for the kids instead [20:02:48] <BBB> peloverde: and what are you working on now? [20:02:51] <jannau> I guess I'm allowed to 'guess' what http://www.flickr.com/photos/av500/4967965846/in/photostream/ is [20:03:05] <mru> _av500_: did you make absolutely certain it isn't a spork? [20:03:16] <funman> mru: the dark side is facing earth?? [20:03:28] <cartman> av500: he heeee nice kids! [20:03:36] <_av500_> jannau: yeah [20:03:41] <mru> funman: the dark side is whichever isn't sunlit [20:03:46] <jannau> _av500_: +not [20:03:46] <funman> _av500_: this is not enough to photograph jupiter? [20:03:49] <funman> oh right [20:03:56] <_av500_> jannau: what happening to janneg? you ate him? [20:03:57] <mru> you're confusing it with the _back_ side [20:04:05] <mru> that's much harder to see [20:04:12] <funman> not the 'hidden' side? [20:04:23] <mru> although slightly more than half of the total can be seen from earth [20:04:28] <_av500_> funman: my astronomy knowledge: i know the moon and .... i ... know....the moon [20:04:37] <mru> due to the moon wobbling ever so slightly [20:04:38] <funman> 'far' side it seems [20:04:51] <mru> far side will do [20:05:12] <funman> _av500_: these days jupiter is very bright because earth is just between it and the sun [20:05:15] <peloverde> BBB: I'm working on nothing, maybe some blogging, my real computer is in my car underneath everything I own, I don't move into my new place until tomorrow [20:05:26] <funman> dunno how it'd look without a telescope though [20:05:28] <BBB> aiyoh [20:05:32] <jannau> _av500_: just my alternate nick and I haven't changed it back after freenode hickup [20:05:40] <BBB> peloverde: where are you moving to, and I mean what kind of job did you take? [20:06:14] <_av500_> funman: unless it is visible from my bierbank right now, it does not exist [20:06:36] <peloverde> moving to san jose, this job http://zoran.com/Digital-Cameras [20:06:57] <BBB> zoran!!! omg [20:07:11] <_av500_> peloverde: you'll make cheap chinese digicams? [20:07:13] <BBB> my first free software ever was a zoran kernel driver :-p [20:07:23] <_av500_> peloverde: we can do business together :) [20:07:54] <peloverde> They make the flip which seems to be pretty popular [20:08:55] <_av500_> right [20:35:27] <astrange> flip looks like another device set to be completely destroyed by cell phone convergence [21:03:13] <_av500_> astrange: no [21:03:51] <_av500_> flip=cheap, no contract etc.. [21:04:07] <_av500_> buy it, use at the beach, lose it, dont care [21:04:10] <_av500_> not like a phone [21:04:42] <astrange> just don't lose your phone [21:05:15] <astrange> ipod touch is contractless too and at some point facebook video upload or etc. (i think it does that) is better than a larger actual camera [21:06:11] <_av500_> yes, touch is a better contender [21:07:17] <_av500_> i guess ppl like the flip for the 1 button UI [21:48:59] <CIA-63> ffmpeg: stefano * r25149 /trunk/ (cmdutils.c ffmpeg.c cmdutils.h): Move log_callback_help to cmdutils.[hc], for allowing sharing. [21:51:37] <CIA-63> ffmpeg: mru * r25150 /trunk/libavcodec/arm/asm.S: [21:51:37] <CIA-63> ffmpeg: ARM: disable movw/movt for relocated values on Apple platforms [21:51:37] <CIA-63> ffmpeg: Apparently Apple platforms do not handle movw/movt relocations [21:51:37] <CIA-63> ffmpeg: properly, leading to runtime crashes in code using them. [21:52:23] <roxfan> apple uses like five relocs on arm... [21:53:46] <mru> would be much nicer if the linker complained [21:53:52] <roxfan> heh [21:54:26] <astrange> macho runs out of space in the reloc flags field very fast [21:54:42] <astrange> not sure why they didn't change the format to increase it, there were several opportunities [21:54:53] <astrange> well, besides that they don't like relocs [21:55:07] <mru> they like to suck [21:56:56] <DonDiego> isn't there a way to detect this? [21:57:03] <DonDiego> __APPLE__ is very ugly.. [21:57:03] <mru> no [21:57:10] <mru> linker succeeds [21:57:16] <mru> runtime crash [21:59:31] <peloverde> http://spectralhole.blogspot.com/2010/09/aac-bistream-flaws-part-2-aac-960-… [22:15:05] <Dark_Shikari> found a bug in the error concealment in h264 for missing frames [22:15:13] <Dark_Shikari> at least in this stream (p-frames only, so very simple) [22:15:18] <Dark_Shikari> frame 19 is missing [22:15:26] <Dark_Shikari> so at frame 20, it runs the loop that processes mmcos from previous frames [22:15:31] <Dark_Shikari> ref list before: [22:15:34] <Dark_Shikari> 18, 17, 16.... 4 [22:15:46] <Dark_Shikari> ref list that we want after: N, 18, 17, 16... 5 [22:15:49] <Dark_Shikari> where N is our missing frame that we don't have [22:15:54] <Dark_Shikari> what we probably should do: 18, 18, 17, 16... [22:16:00] <Dark_Shikari> what ffmpeg does: 4, 18, 17, 16... (LOL) [22:16:08] <mru> rotate ftw [22:16:38] <Dark_Shikari> my boss dubbed it the "time warp" [22:16:50] <mru> heh [22:18:40] <Dark_Shikari> hack to fix it: http://pastebin.com/phH8b40T [22:19:18] <Dark_Shikari> if michael cares to actually fix it (unlikely, he's lazy as fuck these days and spends all his time complaining about people doing actual work, like yasmification) [22:19:24] <Dark_Shikari> http://www.mediafire.com/?b18akxj5ea1s814 here is the file [22:19:36] <Dark_Shikari> frame 19 is missing. 5 frames later, the encoder corrects for the error via reference invalidation [22:33:50] <bcoudurier> what does yasm fix ? [22:33:57] <mru> gcc [22:35:13] <Dark_Shikari> 1) makes code more maintainable [22:35:16] <Dark_Shikari> 2) adds win64 support [22:35:24] <Dark_Shikari> 3) makes code faster (less gcc stupidity interrupting things) [22:35:35] <Dark_Shikari> 4) adds more optimization posssibilities [22:35:46] <Dark_Shikari> 5) makes it much easier to template code (e.g. for mmx vs sse2 vs ssse3) [22:36:00] <mru> I don't understand this templating thing [22:36:21] <mru> isn't the point of sseN+1 that it can do things sseN couldn't? [22:36:26] <Dark_Shikari> Yes [22:36:28] <Dark_Shikari> So here's an example [22:36:38] <mru> so what is there to template? [22:36:39] <Dark_Shikari> in mmx/sse2, you do absolute value as follows: [22:36:47] <Dark_Shikari> mov tmp, reg [22:36:53] <Dark_Shikari> or er [22:36:54] <Dark_Shikari> it's [22:36:56] <Dark_Shikari> xor tmp, tmp [22:37:00] <Dark_Shikari> sub tmp, reg [22:37:05] <Dark_Shikari> max tmp, reg [22:37:07] <mru> similarly shaped instructions with different widths wuld be one case [22:37:09] <Dark_Shikari> that's 3 instructions [22:37:14] <Dark_Shikari> in ssse3, you have pabsw [22:37:18] <Dark_Shikari> 1 instruction [22:37:23] <Dark_Shikari> thus, in your code, you use [22:37:26] <mru> for things that have both with 8 and 16 versions [22:37:27] <Dark_Shikari> PABSW reg, tmp [22:37:37] <Dark_Shikari> in the mmx/sse2 versions, PABSW is a macro that does 3 instructions. [22:37:45] <Dark_Shikari> in the ssse3 version, it maps to pabsw. [22:38:04] <Dark_Shikari> thus, to do this, you'd do something like this [22:38:10] <Dark_Shikari> %macro MYFUNC <stuff> %endmacro [22:38:17] <Dark_Shikari> %define PABSW PABSW_MMX [22:38:20] <Dark_Shikari> MYFUNC sse2 [22:38:29] <Dark_Shikari> %define PABSW PABSW_SSSE3 [22:38:33] <Dark_Shikari> MYFUNC ssse3 [22:38:38] <Dark_Shikari> now you have two versions, one with the sse2 absolute value method [22:38:40] <Dark_Shikari> and one with ssse3. [22:38:44] <mru> ok, that works when a new instruction maps to a common sequence of old instructions [22:38:54] <Dark_Shikari> That's one example [22:38:57] <Dark_Shikari> Now, the other case is size. [22:39:17] <Dark_Shikari> Let's take the simplest possible function: one that writes zeroes to an output buffer. [22:39:20] <bcoudurier> what does cglobal do in yasm ? [22:39:27] <Dark_Shikari> bcoudurier: declare a function [22:39:30] <bcoudurier> does that declare a global symbol ? [22:39:31] <Dark_Shikari> so simplest output function [22:39:36] <Dark_Shikari> pxor m0, m0 [22:39:40] <Dark_Shikari> .loop: [22:39:47] <Dark_Shikari> mova [output], m0 [22:39:52] <Dark_Shikari> add output, 16 [22:39:54] <Dark_Shikari> cmp output, end [22:39:57] <Dark_Shikari> jl .loop [22:40:05] <Dark_Shikari> you can see what it does. [22:40:16] <Dark_Shikari> now, suppose we want to declare an mmx width-8 and sse width-16 at the same time. [22:40:17] <bcoudurier> it seems all cglobal are prefixed with ff_ [22:40:23] <Dark_Shikari> We change "add output, 16" to "add output, mmsize" [22:40:27] <Dark_Shikari> and we do [22:40:28] <Dark_Shikari> INIT_MMX [22:40:31] <Dark_Shikari> MYFUNC mmx [22:40:32] <Dark_Shikari> INIT_XMM [22:40:34] <Dark_Shikari> MYFUNC sse2 [22:40:42] <Dark_Shikari> now we have a width-8 version, and a width-16 version. [22:40:49] <Dark_Shikari> bcoudurier: yes, cglobal auto-prefixes. [22:41:19] <bcoudurier> how do you define static funcs ? [22:42:11] <Dark_Shikari> you mean locally-accessible-only? [22:42:15] <bcoudurier> yes [22:42:17] <Dark_Shikari> why would you need to? [22:42:18] <Dark_Shikari> this isn't C [22:42:30] <Dark_Shikari> you don't get optimization benefits from static [22:42:43] <bcoudurier> you don't want to export them [22:42:52] <mru> and the most bizarre part of the discussion: [22:43:07] <Dark_Shikari> bcoudurier: they get stripped anyways [22:43:11] <mru> [rant against yasm, rant, rant, rant] [22:43:16] <mru> [I suggested using nasm once] [22:43:28] <mru> [rant against yasm, inline is the way] [22:43:30] <bcoudurier> I don't care if people prefer it [22:43:36] <Dark_Shikari> mru: nasm and yasm are the same language [22:43:40] <mru> I know [22:43:42] <Dark_Shikari> that's like saying "C is crappy, you should use ICC" [22:44:00] <bcoudurier> if there is a "need" that's cool, but translating for the sake of it seems useless to me [22:44:15] <mru> Dark_Shikari: michael claims he once suggested we should use nasm/yasm [22:44:26] <mru> yet he misses no opportunity to rail against it [22:44:35] <Dark_Shikari> ah [22:44:37] <Dark_Shikari> well that's michael [22:44:38] <bcoudurier> he doesn't like it [22:44:40] <Dark_Shikari> bcoudurier: it fixes win64 [22:44:44] <Dark_Shikari> it makes it easier to optimize old asm [22:45:18] <bcoudurier> at least he seems to not like it [22:45:19] <mru> all intermixed with random fud about call overhead [22:45:34] <mru> it doesn't matter whether or not he likes it [22:45:36] <Dark_Shikari> bcoudurier: michael doesn't like anything he didn't write [22:45:40] <mru> he hasn't touched the code for years [22:45:55] <bcoudurier> nobody AFAIK [22:46:06] <bcoudurier> and translating is not touching IMHO [22:46:21] <bcoudurier> besides if he is the maintainer I can understand [22:46:23] <Dark_Shikari> the translation usually involves optimization [22:46:28] <Dark_Shikari> most functions have gotten faster [22:46:30] <mru> he's not maintaining [22:46:32] <Dark_Shikari> iirc h264 decoding has gotten 1% faster [22:46:38] <bcoudurier> that said, win64 should work [22:47:03] <bcoudurier> well I don't like exporting all the fucking yasm functions [22:47:12] <mru> so don't [22:47:18] <bcoudurier> then don't do cglobal ? [22:47:26] <Dark_Shikari> strip -x [22:47:26] <Dark_Shikari> done [22:47:28] <bcoudurier> inline asm means you can declare them static [22:47:32] <Dark_Shikari> strip -x [22:47:32] <Dark_Shikari> done [22:47:42] <bcoudurier> nah strip is not the solution [22:47:49] <Dark_Shikari> It's a one line solution that fixes it [22:47:53] <Dark_Shikari> why do anything more complicated? [22:47:59] <mru> Dark_Shikari: can't you have a function without using cglobal? [22:48:11] <Dark_Shikari> Yes [22:48:13] <Dark_Shikari> Easily [22:48:23] <Dark_Shikari> Just put down a label. [22:48:33] <mru> good, what I though [22:48:35] <Dark_Shikari> It's generally not suitable for complicated stuff that does lots of stack access [22:48:39] <Dark_Shikari> because the macro system wasn't built to handle that [22:48:56] <Dark_Shikari> well, like, for example [22:49:02] <Dark_Shikari> in x264, the CABAC functions share a single set of end code [22:49:18] <Dark_Shikari> jmp cabac_putbyte [22:49:35] <Dark_Shikari> and cabac_putbyte is another, non-global function [22:49:49] <Dark_Shikari> in fact, it's even more complicated than that -- we do something there that is IMPOSSIBLE in C. [22:50:01] <Dark_Shikari> we call cabac_putbyte, and then at the end, to save code size.... [22:50:03] <Dark_Shikari> jmp mangle(x264_cabac_encode_decision_asm.update_queue_low) [22:50:08] <Dark_Shikari> we jump back into one of the previous cabac functions [22:50:20] <Dark_Shikari> Yes you could do it with gotos, but not if it was a separate function. [22:50:28] <Dark_Shikari> And the file has a ton of separate functions which are sharing some code. [22:54:42] <mru> a compiler could theoretically do that [22:55:00] <Dark_Shikari> In theory, a compiler can output any asm [22:55:01] <mru> if it noticed functions sharing a common tail [22:55:07] <Dark_Shikari> however, there is no syntax in C to *signal* that to a compiler. [23:10:35] <peloverde> gah, mike's wiki is down [23:11:00] <peloverde> Have people ever discussed merging with the videolan wiki? [23:11:16] <BBB> not that I know [23:13:24] <peloverde> It seems like there is some overlap and you could wind up with a result that is more robust, more complete, and better updated (I've been frustrated about mike's version of mediawiki being old a few times) [23:14:00] <BBB> maybe mike is getting a little old [23:14:35] <Dark_Shikari> we can have the combined free multimedia wiki [23:14:37] <Dark_Shikari> ffmpeg, x264, vlc [23:44:47] <peloverde> Is it worth adding the one real and 3 broken streams that test the AAC channel model to fate? I don't see anyone touching that code anytime soon but the kinds of brokenness out there we support are quite wonky and varied [23:54:15] <bcoudurier> humm

1 0