[00:23:51] <Kovensky> <+twnqx> ok, blender doesn't die to ctrl-c <-- ctrl-\ ? [04:39:49] <ohsix> how fraught with peril is making these changes larger, 128 or more http://trac.perian.org/browser/trunk/Patches/ffmpeg-larger-internal-buffer.d... [04:40:14] <ohsix> gstreamer isn't releasing frames so i've got all sorts of shit that eventually and without fail will abort [04:51:17] <astrange> it only uses more memory [04:51:26] <astrange> and it might fail no matter what size it is [04:56:58] <ohsix> k cool, yea it kept doing it on the same videos as i increased it, it just pushed the crashes out [04:57:44] <astrange> i don't like that patch myself, but i honestly can't understand how perian's lavc interface works in the slightest [04:58:08] <astrange> i'll probably rewrite it sometime and hopefully that won't be necessary afterwards [05:11:59] <ohsix> gst is just holding outstanding frames, i'm not qualified to really look into why; it staggers their release, they eventually make it out in bursts of 15, 16 frames, but it eventually gets far enough behind to abort [09:24:54] <CIA-30> ffmpeg: diego * r22613 /trunk/libavdevice/bktr.c: [09:24:54] <CIA-30> ffmpeg: Revert removal of _NETBSD_SOURCE definition. [09:24:54] <CIA-30> ffmpeg: It is indeed necessary to compile on NetBSD. [10:26:59] <CIA-30> ffmpeg: kostya * r22614 /trunk/libavcodec/bink.c: fix minor typo [11:04:42] <J_Darnley> Damn, I just found a compiling bug that is my fault! [11:08:59] * iive gives a bottle of cola to J_Darnley [11:24:51] <CIA-30> ffmpeg: vitor * r22615 /trunk/libavcodec/fft.h: DCT: remove unused field from context [11:29:32] <CIA-30> ffmpeg: vitor * r22616 /trunk/libavcodec/dct.c: Cosmetics: move ff_dct_init() to the bottom of the file [11:32:01] <CIA-30> ffmpeg: vitor * r22617 /trunk/libavcodec/ (fft.h dct.c): [11:32:01] <CIA-30> ffmpeg: Call DCT by function pointer. Needed for any future ASM implementation and [11:32:01] <CIA-30> ffmpeg: allows further cleanup. [11:35:55] <CIA-30> ffmpeg: vitor * r22618 /trunk/libavcodec/dct.c: Split DCT-II and DCT-III in different functions, they do not share any code. [11:37:04] <CIA-30> ffmpeg: vitor * r22619 /trunk/libavcodec/dct.c: Reindent after r22618. [13:56:32] <J_Darnley> Wow, doing things correctly makes them much cleaner! [13:58:38] <J_Darnley> No need to add stuff to lavc... [13:58:52] <J_Darnley> No need to detect which encoder... [14:28:27] <J_Darnley> elenril: There is a present for you on the mailing list [14:29:43] <elenril> w00tness! [14:30:21] * elenril waits six months until it's approved [14:41:54] <KotH> is anyone here interested in giving a lesson on how to write c code? [14:41:59] <KotH> our company needs one [14:42:17] * KotH will go bonkers if he continues to read such code [14:42:23] <Dark_Shikari> lol [14:44:02] * KotH just stumbled over a if(bitmask&1){ do_something_with(1)}; if(bitmask&2){do_the_same_with(2)}; ... [14:44:22] * KotH wonders whether the guy who wrote it was a datatypist or an engineer [14:44:37] <Dark_Shikari> what's so bad about that? [14:44:40] <CIA-30> ffmpeg: reimar * r22620 /trunk/libavcodec/ (dvdata.h dv.c dv_vlc_data.h): [14:44:40] <CIA-30> ffmpeg: Split VLC-related tables out of dvdata.h to make it easier to add support [14:44:40] <CIA-30> ffmpeg: for hard-coding tables. [14:44:48] <Dark_Shikari> if it went on to 4 and 8 I'd write a loop, sure [14:45:00] <KotH> it goes on until 256 [14:45:03] <Dark_Shikari> LOL [14:45:07] <Dark_Shikari> ok, that's hilarious [14:45:45] <KotH> i'd write a loop even if it was for two values, just to avoid code dublication... [14:45:59] <Dark_Shikari> if it's just a function call, I wouldn't [14:47:22] <CIA-30> ffmpeg: reimar * r22621 /trunk/libavcodec/ (tableprint.c tableprint.h): [14:47:22] <CIA-30> ffmpeg: Extend and move macros to create table printing functions to header. [14:47:22] <CIA-30> ffmpeg: Simplifies creating custom functions for printing DV VLC-related tables. [14:47:32] <KotH> ah.. the joys of thrid party code.... struct blah { uint32 reg1; uint32 reg2; ... uint32 reg8}; [14:48:12] * KotH blames the mexican hired by atmel for this one [14:51:04] <ramiro> KotH: if do_something_with() is static inline gcc might optimize if you call it with 1, 2, etc... it won't if you call it with a variable. [14:51:18] <Dark_Shikari> true, I've unrolled those sorts of things at times [14:52:31] <KotH> actually, do_something is not a function but some arithmetic operations and accessing registers [14:53:15] <ramiro> Dark_Shikari: I've asked a question yesterday but I don't think you were around. why would gcc - then + rsp here: http://ffmpeg.pastebin.com/9hGE8wkQ [14:54:04] <Dark_Shikari> because it's gcc [14:54:40] <ramiro> ok, good, that's what I thought =) [14:54:52] <Dark_Shikari> notice some other things wrong with the code [14:54:57] <Dark_Shikari> it should really have done: [14:55:04] <Dark_Shikari> add eax, edx [14:55:07] <Dark_Shikari> add eax, ecx [14:55:11] <Dark_Shikari> i.e. two instructions [14:55:18] <Dark_Shikari> try with a newer gcc maybe. [14:55:50] <ramiro> it's 4.4.2. what's wrong with using lea here? [14:56:04] <Dark_Shikari> pointless. no gain, extra instruction size [14:56:25] <Dark_Shikari> gcc 3.4 on cygwin Does The Right Thing [14:56:38] <Dark_Shikari> on x86_32 [14:56:57] <Dark_Shikari> the lea mess is probably because of gcc being stupid on x86_64 [14:58:34] <ramiro> gcc 4.4.2 on mingw32 uses add too. [14:58:46] <Dark_Shikari> which means it's an x86_64 suckage issue. [15:48:29] <jre2> what's the policy on submitting patches? would it be easier just to alert someone to a trivial (1 line) typo? [15:48:39] <Dark_Shikari> I meant mention the typo [15:48:41] <Dark_Shikari> not the question [15:48:43] <Dark_Shikari> >_> [15:49:55] <Compn> jre2 : much easier to mention the typo [15:49:58] <jre2> libavformat/asf.c:138 has a typo. '"album "' should be '"album"' [15:50:55] <jre2> someone submitted a patch to indent everything nicely and I assume accidently added that [15:56:00] <elenril> lol [15:56:06] * elenril blames himself [16:04:39] <CIA-30> ffmpeg: reimar * r22622 /trunk/libavcodec/ (dv.c dv_tablegen.c Makefile dv_tablegen.h): Add support for hard-coding the 256kB large dv_vlc_map table. [16:16:59] <KotH> wtf? 256kb?? [16:17:48] <Dark_Shikari> I have no idea why anyone would want to hardcode that [16:18:01] <KotH> embedded systems [16:18:17] <KotH> most times you've more than enough flash, but hardly enough ram [16:19:17] <Compn> ffmpeg: friend to arm and x86 alike [16:20:32] * KotH speaks friend and enters [16:22:05] * elenril remembers http://xkcd.com/424/ [16:29:58] <CIA-30> ffmpeg: reimar * r22623 /trunk/libavcodec/tableprint.c: [16:29:58] <CIA-30> ffmpeg: Do not use puts, it adds additional newlines making the generated files [16:29:58] <CIA-30> ffmpeg: needlessly ugly. [16:34:51] <CIA-30> ffmpeg: stefano * r22624 /trunk/libavcodec/g729dec.c: [16:34:51] <CIA-30> ffmpeg: Make g729dec.c:decode_frame() return AVERROR_INVALIDDATA rather than [16:34:51] <CIA-30> ffmpeg: AVERROR_NOFMT in case of invalid / unknown packet size. [16:34:53] <CIA-30> ffmpeg: stefano * r22625 /trunk/libavformat/utils.c: [16:34:53] <CIA-30> ffmpeg: Make av_open_input_file() return AVERROR_INVALIDDATA rather than [16:34:53] <CIA-30> ffmpeg: AVERROR_NOFMT if the format is unknown / cannot be recognized. [16:34:53] <CIA-30> ffmpeg: It is returned AVERROR_INVALIDDATA, in the sense that the data is [16:34:53] <CIA-30> ffmpeg: invalid within what the specific libav* binary supports. [16:34:54] <CIA-30> ffmpeg: That was the last remaining use of AVERROR_NOFMT, which is going to be [16:34:54] <CIA-30> ffmpeg: dropped at the next libavutil major bump. [16:34:55] <CIA-30> ffmpeg: stefano * r22626 /trunk/libavutil/error.h: Drop AVERROR_NOFMT at the next libavutil major bump. [17:10:07] <macman_> hello ..do we report problems here ? [17:10:20] <macman_> maybe bugs ? [17:13:55] <macman_> [mpeg @ 0x9d113d0]max_analyze_duration reached < -- is this something i have to worry about ? [17:14:04] <kshishkov> no [17:14:31] <macman_> let me throw my real problem out ok [17:14:58] <macman_> http://pastie.org/879808 < -- here is my full movie output [17:15:12] <macman_> this is the command i use .. i will be padding it [17:18:28] <macman_> http://pastie.org/879813 < -- the only way i get this to work is to do -target ntsc-dvd .. i haven't had this issue in the past but i have been having this issue and i can't do anything .. i try -ac 2 or -ac 6 or even -acodec ac3 -ar 48000 -ab 444 or even -acodec libmp3lame -ar 44100 -ab 192k [17:18:38] <macman_> regardless i get same output .. i think its a bug [17:19:09] * elenril points to topic [17:20:48] <macman_> i thought we submit bugs and stuff here ? [17:20:52] <kshishkov> make sure all those options are placed before output file name [17:21:09] <macman_> of course they are kshishkov [17:21:19] <macman_> kshishkov: output is at the end [17:21:28] <kshishkov> I mean -ac 2 [17:21:35] <macman_> yes before output [17:22:13] <kshishkov> then it should generate different messages than pasted [17:23:08] <macman_> if you don't mind looking one more time here is output of final with -ac 2 http://pastie.org/879823 [17:24:08] <kshishkov> it seems to recode [17:28:31] <macman_> takes forever but yes [17:52:08] <elenril> http://games.slashdot.org/story/10/03/21/1552221/Switzerland-Passes-Violent-... o_0 [17:56:24] <kshishkov> it would be worse if they prohibit downloading violent games with torrents. Who cares about sales/distribution? [18:07:47] <CIA-30> ffmpeg: jbr * r22627 /trunk/libavformat/Makefile: [18:07:47] <CIA-30> ffmpeg: Fix FLAC demuxer dependencies. [18:07:47] <CIA-30> ffmpeg: Patch by James Darnley <james darnley at gmail> [18:21:59] * Compn wonders what video games KotH plays [18:22:00] <Compn> ehe [18:22:50] <KotH> the first one i played was called something like debug.exe ;-) [18:24:15] <KotH> but why are you asking? [18:26:29] <Compn> elenril's link about switz banning of violent video games [18:27:18] <KotH> ah.. [18:27:33] <KotH> yeah.. another law we got from the big canton in the north... [18:27:47] <kshishkov> debug.exe was violent - with all that poking around [18:48:20] <jai> wasnt that debug.com? [18:52:37] <kshishkov> maybe in older DOSes where it was smaller [22:24:27] <CIA-30> ffmpeg: michael * r22628 /trunk/libavcodec/h264_sei.c: [22:24:27] <CIA-30> ffmpeg: Ignore x264 build=0 as there is no such version, this restores previous [22:24:27] <CIA-30> ffmpeg: behavior approximately.