[FFmpeg-devel-irc] IRC log for 2010-03-21

[irc at mansr.com]

[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.diff
[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-Games-Ban 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.