[FFmpeg-devel-irc] IRC log for 2010-04-01

[irc at mansr.com]

[00:59:18] <mru> lol, youtube has libaa rendering
[01:03:26] <astrange> i'm not seeing it yet, is it timezoned?
[01:03:48] <kierank> astrange: does the logo look like it's libaa rendered?
[01:05:29] <astrange> same as always, except for the new page design
[01:05:44] <astrange> the new design somehow causes my flash blocker to download video.mp4 whenever i go to a video page
[01:05:48] <kierank> then i guess it's time delayed
[01:05:53] <astrange> i think that might be more convenient than actually using youtube
[01:06:21] <kierank> "By using text-only mode, you are saving YouTube $1 a second in bandwidth costs. "
[01:08:05] <Dark_Shikari> wait.  so is the new youtube interface an april fools' or not?
[01:08:08] <Dark_Shikari> it's not silly enough
[01:08:22] <kierank> no
[01:08:34] <kierank> the "text mode" is the april fools thing
[01:08:47] <Dark_Shikari> where is that
[01:08:56] <kierank> presumably time-delayed
[01:09:29] <Dark_Shikari> ah
[02:15:56] <Dark_Shikari> oh wow, I just realized michael already fixed my weightb + mbaff bug
[02:15:58] <Dark_Shikari> yesterday
[02:16:05] <Dark_Shikari> he's fast as hell
[04:21:05] <Dark_Shikari> hmm.  is ffmpeg's sync engine supposed to generate a different number of video frames if -an is specified?
[04:21:08] <Dark_Shikari> because it really shouldn't
[04:21:13] <Dark_Shikari> (this without using -r, just straight encoding)
[04:21:34] <Dark_Shikari> a customer of mine is reporting different number of frames in each pass (thus x264 breaks) when they use -an on the first pass.
[05:09:57] <pentanol> hi there, could anybody argue this behaviour on arm uClib? http://codepad.org/N0zpCzLq
[05:14:01] <av500> pentanol: what toolchain/system?
[05:15:37] <elenril> google is down today?
[05:15:51] <elenril> http://www.mail-archive.com/uclibc@uclibc.org/msg04954.html << first result for uclib log2f
[05:19:48] <pentanol> av500 cross-compiler-armv5l
[05:20:34] <pentanol> on my camera elder uclib, thefore I wanna compile it static...
[05:22:02] <pentanol> also log and exp sumbols exist there... http://codepad.org/eodnbg41
[05:34:49] <thresh> moroning
[05:34:58] <kshishkov> as always
[05:38:56] <thresh> yep, that's why they call us Konstantins
[05:39:03] <mru> morning
[05:39:36] <kshishkov> god morgon
[05:39:57] <av500> hi guys
[05:40:27] <kshishkov> hi bcoudurier onjoin script reused by av500
[05:40:55] <elenril> av500: copyright ifringement!!!!11one
[05:47:55] <pentanol> elenril hm, I tries in that way, but fails
[05:57:13] <pentanol> also readelf said about log2f exist there http://codepad.org/wLy8jAuK
[06:00:20] <av500> 0 NOTYPE  GLOBAL DEFAULT  UND log2f
[06:00:26] <av500> UND=undefined
[06:42:09] <CIA-1> ffmpeg: koorogi * r22753 /trunk/ (libavcodec/avcodec.h doc/APIchanges libavcodec/utils.c): Add function to export EDGE_WIDTH from libavcodec.
[06:42:09] <CIA-1> ffmpeg: koorogi * r22754 /trunk/ffplay.c: Hook decoder up to libavfilter's direct rendering for ffplay
[06:42:10] <CIA-1> ffmpeg: koorogi * r22755 /trunk/ffplay.c: Don't create unnecessary refereces to pictures
[06:42:10] <CIA-1> ffmpeg: koorogi * r22756 /trunk/ffplay.c: Cosmetics: indentation
[07:40:38] <KotH> hey boys!
[07:41:19] <kshishkov> hey what?
[07:41:28] <KotH> hey you!
[07:41:46] * kshishkov is not here anyway
[07:41:52] <KotH> and an awfull, post-communist, horrible morning to you!
[07:42:07] <kshishkov> at last you got it right!
[07:54:03] <kshishkov> KotH: BTW, isn't it 1st of April aka Theora Users Day?
[07:54:48] <Dark_Shikari> http://www.videolan.org/
[07:54:52] <Dark_Shikari> videolan is bought out by realnetworks
[07:55:09] <kshishkov> less rivals for FFplay!
[07:55:33] <av500> at least they will get buffering support
[07:55:43] <kshishkov> BTW, when FFmpeg is ported to unixkcd?
[07:55:51] <astrange> it hasn't changed for me
[07:55:59] <astrange> oh
[07:58:43] <elenril> unixkcd ftw!
[08:03:12] <CIA-1> ffmpeg: benoit * r22757 /trunk/libavformat/flvdec.c:
[08:03:13] <CIA-1> ffmpeg: Fix flvdec start-of-frame.
[08:03:13] <CIA-1> ffmpeg: Patch by Howard Chu hyc highlandsun com
[08:09:22] <hyc> cool, thanks for the commit benoit
[10:49:03] <ramiro> kshishkov: nice trackback...
[11:00:54] <av500> ?
[11:04:00] <bilboed-pi> kshishkov, btw, I blame you for making me want to learn the Passcaglia :)
[12:04:41] <KotH> interesting... someone at ST micro seems to be interested in ogg
[12:09:23] <av500> ogg the container?
[12:10:24] <CIA-1> ffmpeg: michael * r22758 /trunk/libavformat/utils.c: Limit probing to probesize.
[12:15:05] <KotH> the guy downloaded all our ogg/vorbis samples
[12:15:17] <av500> ah
[12:15:38] <av500> he might be preparing a law suit :)
[12:38:53] <superdump> lol
[14:16:21] <jez9999> BBB: looks like you didn't get very far with issue 1740 :-P
[14:16:28] <BBB> ?
[14:16:34] <BBB> oh, I've been busy with other things, yes
[14:17:47] <BBB> I should probably put it in my local tree so I don't forget about it...
[14:17:48] <BBB> hmm...
[14:31:29] <roozhou> hi, who maintains the avi demuxer?
[14:31:51] <kshishkov> default maintainer does
[14:32:20] <roozhou> then who?
[14:32:25] <av500> mn?
[14:32:34] <kshishkov> of course
[14:32:39] <roozhou> does he use irc?
[14:32:42] <av500> no
[14:32:48] <av500> but he reads the logs
[14:35:08] <jez9999> he does?  heh
[14:35:11] <jez9999> how boring
[14:35:38] <kshishkov> why does that bother you?
[14:36:01] <jez9999> doesnt bother me
[15:34:56] <pengvado> does anyone know a sigmoid function that can be computed quickly with integer math?
[15:35:56] <kshishkov> uh, maybe you ask three easier questions?
[15:38:27] <bofh__> pengvado: wouldn't arctan(x) work for that?
[15:38:45] <pengvado> since when is arctan fast?
[15:39:37] <pengvado> in SSE, x/(abs(x)+1) takes 5 uops per 4 elements
[15:39:59] <pengvado> but I'm looking for something that can be bit-exact on archs other than SSE
[15:41:00] <pengvado> the baseline is simply a bit-exact C emulation of the SSE ops (dunno how fast I can make that)
[15:41:07] <superdump> is this for ffv2?
[15:41:10] <pengvado> yes
[15:42:07] <kshishkov> Lagarith shows that floating-point math in lossless codecs is a good idea
[15:43:08] <pengvado> Lagarith used float because the developer was lazy. there was absolutely no reason not to do that with something exact.
[15:43:45] <pengvado> I'm asking whether there is any way to do this in int that isn't 2 orders of magnitude slower than float.
[15:44:04] <kshishkov> dpends on your input
[15:44:33] <kshishkov> but in general - unlikely
[15:54:08] <CIA-1> ffmpeg: benoit * r22759 /trunk/libavcodec/libx264.c:
[15:54:09] <CIA-1> ffmpeg: Fix typo: CODEC_FLAG2_SSIM is in flags2, not in flags.
[15:54:09] <CIA-1> ffmpeg: Patch by Takashi Mochizuki mochi (A) da2 (.) so (dash) net (dot) ne (.) jp
[15:56:12] <BBB> hwo do i know yasm was enabled?
[15:56:17] <BBB> I did --enable-yasm
[15:56:23] <BBB> but configure shows no messages
[15:56:27] <janneg> BBB: configure should print it
[15:56:33] <kshishkov> grep config.mak ;)
[15:56:39] <BBB> I don't think it did...
[15:56:55] <BBB> YASM=yasm
[15:56:58] <BBB> is all I find there
[15:57:01] <kshishkov> or make and look if those libavcodec/x86/*.s files were compiled ;)
[15:57:07] <kshishkov> good
[15:57:27] <janneg> BBB: make config | grep -i yasm
[15:57:28] <janneg> yasm                      yes
[15:59:39] <BBB> ok it did work
[15:59:39] <BBB> thanks
[16:11:07] <BBB> oh wait let me guess
[16:11:17] <BBB> all yasm code is under --enable-gpl right?
[16:13:08] <pengvado> no
[16:28:46] <BBB> holy shit that fft is fast
[16:29:15] <kshishkov> compared to what?
[16:29:15] <BBB> my decoding just went to under a second for 4 files together compared to several seconds for one file before
[16:29:28] <BBB> with fft optimizations enabled, I suppose
[16:29:30] <kshishkov> good
[16:31:20] <Dark_Shikari> pengvado: what is atan useful for in ffv2?
[16:32:17] <pengvado> nerual net spatial prediction
[16:32:43] <pengvado> (and nnedi mc, but that would be overkill)
[16:32:51] <Dark_Shikari> .... how much does it help?
[16:32:58] <pengvado> dunno yet
[16:33:15] <Dark_Shikari> You can test it without having a portable version >_>
[16:33:38] <pengvado> don't have a nonportable version either, I just know this issue will come up if it ever works
[16:33:46] <Dark_Shikari> lol
[16:53:05] <CIA-1> ffmpeg: reimar * r22760 /trunk/libavcodec/x86/h264dsp_mmx.c: Convert two "m" constraints to MANGLE to fix compilation with some compilers.
[17:12:37] <CIA-1> ffmpeg: reimar * r22761 /trunk/ (9 files in 2 dirs): Change/simplify the tableprint/tablegen API.
[17:55:06] <CIA-1> ffmpeg: reimar * r22762 /trunk/libavcodec/ (pcm_tablegen.h Makefile pcm.c pcm_tablegen.c): Allow hardcoding of ulaw and alaw tables.
[18:52:02] <CIA-1> ffmpeg: michael * r22763 /trunk/libavcodec/ffv1.c:
[18:52:03] <CIA-1> ffmpeg: Store range coder state transition table.
[18:52:03] <CIA-1> ffmpeg: Use a better table, 2% compression gain for foreman
[18:52:20] <Dark_Shikari> oh shi-  some competition for ffv2
[18:52:25] <Dark_Shikari> wait.  doesn't that break compatibility?
[18:53:35] <Dark_Shikari> hmm, I guess it does.
[18:55:44] <bcoudurier> nope
[18:55:46] <bcoudurier> it extends
[18:55:54] <bcoudurier> ffv1 stores ac in the bitstream
[18:55:58] <bcoudurier> he added ac 2
[18:56:15] <Dark_Shikari> Yeah I know
[18:56:16] <bcoudurier> +    put_symbol(c, state, f->ac, 0);
[18:56:16] <bcoudurier> +    if(f->ac>1){
[18:56:18] <Dark_Shikari> saw that
[18:56:48] <bcoudurier> well anyway ffv2 should outperform everything :)
[18:57:16] <bcoudurier> if that's the case I will switch to it as an archive format as soon as it's stable
[18:57:33] <Dark_Shikari> yeah, we worked pretty hard on the design
[18:57:41] <Dark_Shikari> and it should be really really freaking fast
[18:57:42] <Dark_Shikari> it has no arithcoding
[18:57:56] <bcoudurier> can you make it support 4:2:2 early ? :>
[18:58:05] <Dark_Shikari> should be trivial to support 4:2:2, it codes each chroma plane separately
[18:58:15] <bcoudurier> nice
[18:58:22] <bcoudurier> intra only efficient ?
[18:58:31] <Dark_Shikari> intra only will be pretty efficient but no way as good as ffv1
[18:58:37] <Dark_Shikari> but probably reasonably close
[18:58:37] <bcoudurier> oh :(
[18:58:46] <Dark_Shikari> because you can't possibly beat ffv1 through normal methods
[18:59:00] <Dark_Shikari> the only way to beat ffv1 is a more complicated predictor imo
[18:59:08] <Dark_Shikari> i.e. neural net prediction or something, or LPC
[18:59:16] <Dark_Shikari> the goal of ffv2 is to be fast while remaining useful
[18:59:21] <Dark_Shikari> so it won't use such insane things
[18:59:38] <Dark_Shikari> also, why intra only?  decoding one gop of ffv2 is probably faster than decoding one frame of ffv1 (for a gop size of, say, 12)
[19:04:36] <jai> wow
[19:04:37] <jai> nice
[19:05:35] <bcoudurier> my favorite combo is mov+ffv1+pcm
[19:05:44] <bcoudurier> I can address any frame instantly
[19:07:50] <bcoudurier> but yeah I guess that using a small gop size and decoding a gop should be ok
[19:07:53] <Dark_Shikari> jai: it should be faster than _huffyuv_
[19:08:13] <Dark_Shikari> it's designed from the ground up to make the prediction SIMDable
[19:08:19] <Dark_Shikari> and to merge as many values as possible into one VLC code
[19:08:30] <Dark_Shikari> It also has really, really, really big VLC tables.
[19:08:47] <jai> Dark_Shikari: well, i'd definitely like to use that for archival :)
[19:08:49] <Dark_Shikari> basic structure in short:
[19:08:54] <Dark_Shikari> 1) 8x8 block size only
[19:09:05] <Dark_Shikari> 2) motion vectors are hpel, median-predicted
[19:09:28] <Dark_Shikari> 3) pixels are median-predicted.  on the edges of inter/intra boundaries, the edge pixels are recalculated
[19:09:40] <Dark_Shikari> i.e. for predicting an inter block from an intra block, you recalculate the intra predictions as if they were inter
[19:09:49] <Dark_Shikari> and vice versa
[19:09:57] <Dark_Shikari> without this, mixing intra + inter is impossible
[19:10:12] <Dark_Shikari> 4) groups of 2x2 pixels are coded as a single VLC
[19:10:24] <Dark_Shikari> e.g. a VLC might say [-2,1,0,ESC]
[19:10:33] <Dark_Shikari> where ESC means "one escape code is written after this VLC"
[19:10:51] <Dark_Shikari> 5) groups of 8x4 pixels are coded as a single Coded Block Pattern (to say which groups of 2x2 are coded)
[19:11:20] <Dark_Shikari> 6) MB types are coded as VLCs of groups of 4 blocks, so 4 MB types per VLC
[19:11:42] <Dark_Shikari> each row of blocks is padded to a multiple of 4 for this purpose (not in terms of pixels, just how many are written--the last element may have a junk data value or two added for this purpose)
[19:12:00] <Dark_Shikari> mb types are inter + delta MV, intra, and inter + no delta MV
[19:12:14] <Dark_Shikari> 7) each syntax element is coded per row.  i.e. you have all the mb types, then all the mvs, then all the cbps...
[19:12:30] <Dark_Shikari> 8) the pixels are arranged in a Very Curious Fashion so as to allow median prediction in SIMD.
[19:13:02] <Dark_Shikari> delta MVs are, of course, yet another VLC table.
[19:13:22] <Dark_Shikari> Basically every single syntax element no matter what is an adaptive VLC table written every once in a while to the stream.
[19:14:09] <Dark_Shikari> oh yeah, and 9) there are 8 different VLC tables for 2x2 block codes, chosen based on the sum of the absolute deltas (with escapes clipped to 2) of the top and left 2x2 blocks.
[19:14:14] <Dark_Shikari> i.e. same as CAVLC.
[19:14:49] <Dark_Shikari> FFV2 will probably be scalable, i.e. we can add new optional features to improve compression at the cost of speed.
[19:15:20] <Dark_Shikari> Possibilities: qpel, eighthpel, LPC prediction, NNet prediction, median5 prediction (only useful for intra), etc.
[19:16:48] <Dark_Shikari> (any other ideas are of course welcome)
[19:59:28] <astrange> if you finish ffv2 i'll add encoding support to perian and support it
[20:00:18] <astrange> i'm uncomfortable with supporting other formats though (some because they're clearly proprietary and some because i don't think i can design a ui good enough to hide mpegvideoenc complexity)
[20:00:19] <Dark_Shikari> and I'll harass the ffdshow guys to do it
[20:00:55] <astrange> oh, and if it has an rgba mode actually implement the alpha support
[20:02:22] <astrange> is adding weird predictors really better for compression than range coding?
[20:02:34] <Dark_Shikari> what weird predictors?
[20:02:48] <astrange> neural net
[20:02:56] <Dark_Shikari> there's no reason not to combine them
[20:03:01] <Dark_Shikari> they're separate
[20:03:21] <Dark_Shikari> well, hmm, maybe you're right
[20:03:36] <Dark_Shikari> but a neural network range coder would be sorta hard to construct
[20:39:16] <BBB> lu_zero: what was the ogg/vorbis rtsp test on feng again?
[20:45:12] <bcoudurier> astrange, do you know how peloverde interpolates dts from mkv in perian, does it use code for each audio and video codec ?
[20:49:30] <BBB> lu_zero: or can you please set one up?
[20:50:37] <bcoudurier> how can I get the corresponding svn rev in x264 ?
[20:51:52] <Dark_Shikari> ./version.sh
[20:57:20] <CIA-1> ffmpeg: cehoyos * r22764 /trunk/ (doc/ffplay-doc.texi ffplay.c):
[20:57:20] <CIA-1> ffmpeg: Add -t option to ffplay.
[20:57:20] <CIA-1> ffmpeg: Patch by Robert Kr?ger, krueger signal7 de
[20:59:52] <bcoudurier> how do you retrieve an old one ?
[21:00:43] <bcoudurier> forget it
[21:00:52] <Dark_Shikari> suppose the latest is revision X.  the one you want is revision Y.
[21:00:59] <Dark_Shikari> git checkout HEAD~(X-Y)
[21:01:04] <Dark_Shikari> so 1490 would be HEAD~20.
[21:06:00] <astrange> bcoudurier: yuvi not peloverde
[21:06:15] <bcoudurier> right, sorry
[21:07:10] <astrange> it's all in http://trac.perian.org/browser/trunk/MatroskaImportPrivate.cpp#L1076 and doesn't seem to consider any codec specially
[21:07:17] <astrange> of course, i can't guarantee it's correct
[21:07:27] <Dark_Shikari> can probably look at mkvmerge's code
[21:07:37] <Dark_Shikari> though mkvmerge has a lot of per-codec stuff solely because of parsers
[21:07:39] <astrange> specifically it completely fails to import mpeg-2 generated by MakeMKV, i haven't investigated yet
[21:07:42] <Dark_Shikari> which is a given for any app
[21:08:01] <astrange> about ffv2 again, can you get away with sticking the h.264 vui in it somewhere?
[21:08:23] <astrange> otherwise it will be difficult to use for archival outside mov, because mov is the only container that has colorspace info tags
[21:08:48] <astrange> and about that, can we get colr/pasp atom writing in movenc? i'm going to do it sometime but it may take me a while
[21:08:49] <bcoudurier> don't use h264 vui
[21:08:51] <Dark_Shikari> talk to pengvado about it, I think such flags would be useful
[21:08:55] <Dark_Shikari> not exactly the h264 vui
[21:08:57] <Dark_Shikari> but at least something similar.
[21:09:00] <bcoudurier> yes
[21:09:13] <Dark_Shikari> you could even have an mkv-like or xml-like tag header with arbitrary strings
[21:09:15] <astrange> the vui has all the right fields, it's the lazy way to do it. but as long as it can do all the same values it's ok
[21:10:27] <bcoudurier> astrange, yes about colr pasp
[21:10:47] <bcoudurier> if right information is there :>
[21:10:52] <Dark_Shikari> so we need timebase, aspect ratio, colorspace, etc?
[21:11:09] <bcoudurier> timebase if you want raw I guess
[21:11:13] <bcoudurier> so yes
[21:11:28] <astrange> clap (clean aperture) is "mandatory" in mov and exists in mp4, but i don't think we have the information for that
[21:11:38] <bcoudurier> how mandatory ?
[21:12:00] <Dark_Shikari> IMO it would be nice to make the header extensible
[21:12:04] <Dark_Shikari> so that more fields can be easily added
[21:12:16] <Dark_Shikari> hence the arbitrary strings idea
[21:12:28] <Dark_Shikari> all information can be considered metadata
[21:12:28] <bcoudurier> optional in iso for sure
[21:12:31] <astrange> http://developer.apple.com/quicktime/icefloe/dispatch019.html says "always required", but the default is trivial and qt auto generates it
[21:12:38] <Dark_Shikari> "title" would have the same status as "transfer coefficients"
[21:12:43] <bcoudurier> yes
[21:12:45] <bcoudurier> for uncompressed
[21:12:55] <bcoudurier> and for ycbcr
[21:13:01] <bcoudurier> like the document title
[21:13:11] <bcoudurier> otherwise clean aperture == codec resolution
[21:13:26] <bcoudurier> besides apple is fucked up
[21:13:44] <bcoudurier> it keeps trying to think that HD clean aperture is not the codec resolution
[21:13:49] <Dark_Shikari> I wonder if we can push ffv2 as a standard lossless format
[21:13:59] <astrange> colr/nclc is easy to generate from avcodeccontext, you just have to decide if you want to write "unknown" when it's not set or guess from the resolution
[21:13:59] <Dark_Shikari> it would be really nice because it's basically better than any current ones
[21:14:06] <bcoudurier> while experts explicitely declared that for HD the production aperture is the one encoded
[21:14:30] <bcoudurier> experts ie SMPTE
[21:15:21] <astrange> quicktime people really want you to write colr in your mov files, at wwdc as soon as i introduced myself they asked me to do it
[21:15:35] <bcoudurier> that's because of the mac fucked up display
[21:15:49] <astrange> system gamma changed to 2.2 in 10.6
[21:15:49] <bcoudurier> that changed with snow leopard hopefully
[21:15:58] <bcoudurier> so it's not needed anymore :>
[21:16:01] <bcoudurier> it should not
[21:16:40] <kierank> [22:14] <@Dark_Shikari> I wonder if we can push ffv2 as a standard lossless format --> that would make it VC-4 I think
[21:16:59] <Dark_Shikari> sounds good
[21:17:01] <bcoudurier> the thing is, I'd prefer to avoid writing contradicting infos
[21:17:29] <bcoudurier> it's such a pain that so many mkv have different ar in mkv and h264 bitstream for ex
[21:17:40] <Dark_Shikari> well, being able to parse raw ffv2 would be nice
[21:18:10] <astrange> ffmpeg could complain about more values being different in codec/container values
[21:18:24] <astrange> though the timebase warning isn't very useful because nobody cares
[21:27:27] <bcoudurier> yes
[21:42:00] <CIA-1> ffmpeg: rbultje * r22765 /trunk/libavformat/ (6 files):
[21:42:00] <CIA-1> ffmpeg: Rename rtpdec_theora.[ch] to rtpdec_xiph.[ch], as a preparation for merging
[21:42:00] <CIA-1> ffmpeg: the Vorbis / theora depacketizers.
[21:42:00] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>.
[21:42:42] <CIA-1> ffmpeg: rbultje * r22766 /trunk/libavformat/ (rtpdec_xiph.c rtpdec_xiph.h):
[21:42:42] <CIA-1> ffmpeg: Rename functions / comments from "Theora" to "Xiph" where relevant.
[21:42:42] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>.
[21:42:42] <CIA-1> ffmpeg: rbultje * r22767 /trunk/libavformat/rtpdec_xiph.c:
[21:42:42] <CIA-1> ffmpeg: Reindent after r22766.
[21:42:43] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>.
[21:44:19] <CIA-1> ffmpeg: rbultje * r22768 /trunk/libavformat/ (6 files):
[21:44:19] <CIA-1> ffmpeg: Merge Vorbis / Theora depayloaders.
[21:44:19] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>.
[22:29:41] <peloverde> alex
[22:35:19] <CIA-1> ffmpeg: stefano * r22769 /trunk/ (cmdutils.c ffmpeg.c cmdutils.h):
[22:35:19] <CIA-1> ffmpeg: Implement cmdutils.c:read_file(), and use it in ffmpeg.c for reading
[22:35:19] <CIA-1> ffmpeg: the second pass encoding log file.
[23:48:33] <superdump> peloverde: is your password alex or something? :)
[23:49:49] <hyc> almost as good as 1 - 2 - 3 - 4 - 5
[23:51:21] <Compn> 12345? thats the same password i hav...
[23:51:58] <hyc> Funny, you don't look druish to me...