[FFmpeg-devel-irc] IRC log for 2010-09-29

[irc at mansr.com]

[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