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

[irc at mansr.com]

[00:23:36] <CIA-92> ffmpeg: conrad * r22213 /trunk/ffplay.c: Just ignore streams with unknown codec_type instead of exiting
[00:23:38] <CIA-92> ffmpeg: conrad * r22214 /trunk/libavformat/oggparsetheora.c:
[00:23:38] <CIA-92> ffmpeg: oggdec: Parse theora headers since ogg might not mark keyframes
[00:23:38] <CIA-92> ffmpeg: Fixes issue746
[00:26:03] <Yuvi> siretart`: recordmydesktop oggs should be fixed
[00:26:33] <BBB> before you release, can you wait until my float<->int16 patch is applied?
[00:26:57] <DonDiego> that depends on you applying the patch in time :)
[00:26:58] <Yuvi> 0.6 or 0.5.1?
[00:30:25] <DonDiego> Yuvi: did you just fix the loooooooooooooooooooooooongstanding seeking in theora videos produces artifacts issue?
[00:30:47] <Yuvi> shouldn't have
[00:31:13] <DonDiego> pity
[00:31:20] <Yuvi> (yet at least)
[00:31:33] <mru> DonDiego: that issue is old as ogg itself
[00:31:48] <Yuvi> this was just that ffmpeg needs to see a keyframe for -vcodec copy, and those oggs had none marked
[00:51:09] <CIA-92> ffmpeg: stefano * r22215 /trunk/libavcodec/imgconvert.c:
[00:51:09] <CIA-92> ffmpeg: Fix BGR cases missing from depth test in avcodec_get_pix_fmt_loss().
[00:51:09] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik:
[00:51:09] <CIA-92> ffmpeg: <${name initial}${surname less the final "ofik"}@tis.icnet.pl>.
[00:51:45] <DonDiego> i hate these silly cases of email mangling
[00:51:53] <DonDiego> the idea is giving people credit
[00:52:12] <mru> it was funny the first time
[01:00:24] <saste> yes I do it mostly for fun I'm getting tired of the usual mangling methods
[01:00:37] <saste> then bots can fetch the mail from the ML
[01:00:54] <saste> and humans usually have no problem at deciphering the mangled email
[01:28:59] <DonDiego> mru: still around?
[01:30:05] <mru> yes
[01:30:47] <DonDiego> you saw my commit to bktr.c
[01:30:55] <mru> yes
[01:30:58] <DonDiego> it's not enough to fix netbsd compilation
[01:31:07] <DonDiego> i was talking to michael kostylev in private
[01:31:10] <mru> oh dear
[01:31:28] <mru> what else did the idiots fuck up?
[01:31:37] <DonDiego> the fate box adds -D_NETBSD_SOURCE to the global CFLAGS
[01:32:11] <mru> I know
[01:32:17] <mru> god knows what that's masking
[01:32:28] <DonDiego> sockaddr_storage
[01:32:37] <DonDiego> >> /usr/include/sys/socket.h:
[01:32:41] <DonDiego> >> #if (_XOPEN_SOURCE - 0) >= 500 || defined(_NETBSD_SOURCE)
[01:32:44] <DonDiego> >> struct sockaddr_storage {
[01:32:53] <DonDiego> from michael k's mail
[01:33:15] <DonDiego> (geez, why is there whitespace in the paste?
[01:33:23] <DonDiego> - trailing whitespace)
[01:33:51] <mru> already in the email?
[01:34:01] <mru> added by mail reader?
[01:34:17] <DonDiego> no, not in the email
[01:34:41] <DonDiego> normal X copy and paste by middleclick, pasted from an xterm
[01:35:20] <mru> spec for sys/socket.h says nothing about that struct being xsi only
[01:35:29] <mru> which means it's part of the base standard
[01:35:36] <mru> and no _XOPEN_SOURCE is needed
[01:35:43] <mru> die, bsd, just die
[01:35:49] <DonDiego> the problem here is that _XOPEN_SOURCE is not defined during the configure test
[01:36:00] <mru> not relevant
[01:36:06] <DonDiego> but defined in rtpdec.c
[01:36:07] <mru> it shouldn't be needed to get that struct
[01:37:09] <DonDiego> one way to fix this would be defining _XOPEN_SOURCE globally
[01:37:33] <DonDiego> the other would be _NETBSD_SOURCE globally
[01:37:44] <DonDiego> we turn on __EXTENSIONS__ for solaris
[01:37:49] <mru> the first is almost as bad as the second
[01:38:18] <DonDiego> what's so bad about the first?
[01:38:23] <mru> turning something like on just for netbsd would be acceptable
[01:38:48] <mru> we don't want to accidentally start depending on extensions
[01:38:56] <DonDiego> _XOPEN_SOURCE for netbsd?
[01:39:07] <DonDiego> or _NETBSD_SOURCE for netbsd?
[01:39:17] <mru> I'd prefer xopen
[01:39:25] <mru> it's more specific
[01:39:49] <mru> and should only pull in standard stuff
[01:40:05] <mru> there's no telling what _NETBSD_SOURCE might enable
[01:40:24] <mru> there are some historic bsd functions that conflict with standard ones
[01:40:58] <mru> ask michael k if _XOPEN_SOURCE globally works
[01:41:05] <DonDiego> on it...
[01:41:25] <DonDiego> apparently using standard posix int types in bktr.c works as well
[01:41:45] <mru> ?
[01:41:59] <DonDiego> u_int64_t --> uint64_t
[01:42:02] <mru> I thought the system bktr.h used nonstandard crap
[01:43:11] <DonDiego> ok, let's see what he says
[02:21:04] <CIA-92> ffmpeg: michael * r22216 /trunk/ffplay.c:
[02:21:04] <CIA-92> ffmpeg: Libavfilter for ffplay support.
[02:21:04] <CIA-92> ffmpeg: This still needs some minor work here and there but should be already functional.
[02:21:04] <CIA-92> ffmpeg: Note that the code pathes that are under "not avfilter" ifdefs as well as the
[02:21:04] <CIA-92> ffmpeg: ifdefs will be droped as soon as all major issues have been det with, aka could
[02:21:05] <CIA-92> ffmpeg: be real soon or not.
[02:22:05] <Compn> michael : what about libavfilter support for mplayer? :)
[02:43:12] <Compn> [aac @ 0p2598230]SBR not implemented. Update your FFmpeg version to the newest one from SVN. If the
[02:43:12] <Compn>  problem still occurs, it means that your file has a feature which has not been implemented.
[02:43:19] <Compn> need to make this error only appear once ^^
[02:43:29] <mru> s/once/never/
[02:43:36] <mru> peloverde: we're waiting...
[02:44:00] <ShadowJK> wtf @ yield
[02:44:09] <pasteeater> i think 22216 breaks compilation
[02:44:11] <pasteeater> http://pastebin.com/qjMzrkUi
[02:44:18] <mru> yield is almost always the wrong answer
[02:44:25] <ShadowJK> yes
[02:44:53] <pasteeater> ...on arch linux x86_64
[02:46:01] <mru> yep
[02:46:04] <mru> looking into it
[03:03:11] <relaxed> hmm, no problems building SVN-r22216 on debian unstable x86_64
[03:03:36] <mru> it only breaks without --enable-avfilter
[03:29:48] <Yuvi> well, I finally figured out the single use of skeleton: getting the first pts right
[03:30:20] <mru> lol
[03:31:48] <Yuvi> the index uses it too (and actually adds a field for duration), but that's not final so eh
[03:37:47] <CIA-92> ffmpeg: michael * r22217 /trunk/ffplay.c: Fix 100l pkt->pos typo.
[03:55:34] <CIA-92> ffmpeg: michael * r22218 /trunk/ffplay.c: 10l fix timestamps (lavfi update broke them)
[06:01:14] <thresh> moroning
[06:54:29] <Dark_Shikari> superdump: fix your blog
[06:54:34] <Dark_Shikari> http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/ is still down
[07:20:55] <superdump> Dark_Shikari: well, i need a new host
[07:21:07] <superdump> what do you want me to do? unearthquake chile?
[07:21:09] <Dark_Shikari> ask mike
[07:21:33] <superdump> i'd still need to get all the data from reynaldo
[07:21:47] <superdump> i can send him an e-mail though to see what we can do
[07:21:47] <kshishkov> superdump: good idea to unearthquake anyway
[07:21:48] <Dark_Shikari> true.
[07:22:16] <superdump> but i expect he's busy taking care of his wife and kids
[07:23:02] <Dark_Shikari> true
[07:23:07] <Dark_Shikari> where was the server in chile?
[07:23:40] <kshishkov> opendot.cl
[07:27:07] <superdump> concepcion i'm guessing
[07:27:12] <superdump> i think it was at reynaldo's house
[07:27:36] <superdump> his house is fine, but net connections are not stable from what i gather
[07:29:01] <Dark_Shikari> ah.
[07:29:05] <Dark_Shikari> well, good that his house is fine
[07:29:08] <Dark_Shikari> net connections are easier to fix
[07:29:29] <superdump> i've kind of wanted to start the site from scratch anyway
[07:29:36] <superdump> well
[07:29:40] <superdump> keeping some of the content
[07:29:47] <superdump> and adding redirects as appropriate
[07:29:53] <kshishkov> ask web.archive.org
[07:34:07] <superdump> seems to be taking a very long time
[07:35:05] <superdump> it hasn't picked up any of the more recent changes
[07:35:12] <superdump> the last change it noticed was in 2008
[07:35:54] <kshishkov> it's easier for me - no very useful information on my blog
[07:37:34] <astrange> archive.org has a 6 month delay on everything and usually more
[07:39:55] <superdump> is archive.org always so sloooow?
[07:40:20] <kshishkov> no, it depends on popularity of site
[07:40:46] <kshishkov> could be slower
[07:42:25] <superdump> you mean low ranked sites only allow one person to view them per day
[07:42:27] <superdump> ?
[07:42:32] <superdump> omg!
[07:42:36] <superdump> it loaded something!
[07:42:53] <andoma> good morning
[07:43:00] <kshishkov> I've read that archive.org gets its data mostly from alexa.com
[07:43:04] <kshishkov> god morgon
[07:43:18] <superdump> oh dear, it's not even a version that has preset support
[07:43:21] <superdump> not surprising though
[07:43:26] <superdump> oh well
[07:43:48] * superdump goes back to reviewing michael's review of he aac
[07:43:54] <kshishkov> there's also google cache ;)
[07:45:02] <astrange> one or two things he asked were the same things i asked, i should have phrased that as "please name usb something else"
[07:46:56] <kshishkov> wrong channel?
[07:47:40] <astrange> usb is the name of a variable in aacsbr
[07:48:07] <kshishkov> ah
[07:48:54] <kshishkov> yes, a bit misleading name unless there are also variables like "iLink", "com", "lpt"
[08:03:50] <superdump> Dark_Shikari: http://74.125.77.132/search?q=cache:TK96XlO5grYJ:rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/+http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/&cd=1&hl=en&ct=clnk&gl=uk
[08:04:06] <Dark_Shikari> I know about the cache
[08:09:03] <KotH> moin
[08:09:23] <kshishkov> gruss dich
[08:16:10] <CIA-92> ffmpeg: mstorsjo * r22219 /trunk/libavformat/rtpproto.c: Return from rtp_read when select returns an error
[08:27:14] <CIA-92> ffmpeg: benoit * r22220 /trunk/ (3 files in 2 dirs):
[08:27:14] <CIA-92> ffmpeg: Add initial support for 12-bit color mode.
[08:27:14] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik jkrzyszt tis icnet pl
[08:27:14] <CIA-92> ffmpeg: Original thread:
[08:27:14] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH v2] Add initial support for 12-bit color mode.
[08:27:15] <CIA-92> ffmpeg: Date: Mon, 1 Mar 2010 02:05:07 +0100
[08:35:21] <CIA-92> ffmpeg: benoit * r22221 /trunk/doc/swscale.txt:
[08:35:21] <CIA-92> ffmpeg: Update SW scaler doc after libswscale commit 30841.
[08:35:21] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik jkrzyszt, tis icnet pl.
[09:11:18] <siretart`> Yuvi: verified, that ogv works now. do you think it is really just that onliner? in that case, I'd nominate it for the 0.5 branch
[09:11:58] <kshishkov> too late, 0.5.1 is out and we're moving towards 0.6
[09:12:49] <siretart`> kshishkov: indeed, but still interesting for distro packages.
[09:14:00] <siretart`> no, it is not just r22214 :-(
[10:41:20] <Yuvi> siretart`: dunno what else might be needed, don't see anything else that could fix it since 0.5 unless it crashed
[10:58:02] <siretart`> Yuvi: no, it doesn't crash. the video just looks very disorted
[10:58:12] <Yuvi> oh
[10:58:24] <Yuvi> that's theora's 3 quant
[10:58:32] <Yuvi> which probably I added after 0.5
[10:59:16] <siretart`> oh, that means that's rather a new feature than a regression. I see
[11:01:49] <twnqx> is there a spline36 resizer in swscale?
[11:12:55] <CIA-92> libswscale: cehoyos * r30840 /trunk/libswscale/ (yuv2rgb.c swscale.c swscale_internal.h):
[11:12:55] <CIA-92> libswscale: Support BGR555, BGR565, RGB555 and RGB565 foreign endian output in
[11:12:56] <CIA-92> libswscale: libswscale.
[11:12:56] <CIA-92> libswscale: Patch by Alexis Ballier, alexis D ballier A gmail
[11:12:57] <CIA-92> libswscale: benoit * r30841 /trunk/libswscale/ (yuv2rgb.c swscale.c swscale_internal.h):
[11:12:58] <CIA-92> libswscale: libswscale: Extend the unaccelerated path of the unscaled yuv2rgb special
[11:12:58] <CIA-92> libswscale:  converter with support for rgb444 output format.
[11:12:59] <CIA-92> libswscale: Patch by Janusz Krzysztofik jkrzyszt chez tis icnet pl
[11:12:59] <CIA-92> libswscale: benoit * r30842 /trunk/libswscale/yuv2rgb.c: Cosmetics: fix vertical alignment.
[11:14:54] <peloverde> I just found my copy of the old Coding Technologies aacPlusDecoderCheckPackage, I'm a little scared to run it
[11:15:26] * twnqx svn ups
[11:15:55] <thresh> this checkout is going to be legen....wait for it...dary?!
[11:16:27] <twnqx> no, i do it daily to hope that i finally can convert flac to alac and keep my tags
[11:16:50] <twnqx> s/to/and
[11:16:51] <DonDiego> peloverde: go for it :)
[11:17:59] <peloverde> I will shortly, I'm fixing some issues michael found
[11:18:53] <jai> twnqx: ?
[11:19:02] <jai> raw flac?
[11:19:03] <twnqx> the author/artist thingy
[11:19:30] <jai> hmm
[11:20:41] <twnqx> libavcodec/vc1dec.c:2319: warning: suggest parentheses around operand of ‘!’ or change ‘&’ to ‘&&’ or ‘!’ to ‘~’ <- should i be worried?
[11:21:14] <twnqx> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: libavutil/lls.o: relocation R_X86_64_PC32 against undefined symbol `memset@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
[11:21:15] <twnqx> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value
[11:21:18] <twnqx> argh, that's new
[11:22:21] <DonDiego> twnqx: yes, worry that everybody ignores warnings instead of fixing them.. :-(
[11:22:27] <DonDiego> kshishkov: your code..
[11:22:30] <jai> twnqx: gentoo?
[11:22:33] <twnqx> yeah
[11:22:36] <jai> heh
[11:22:43] <twnqx> but manual compile
[11:23:15] <Dark_Shikari> lets say I run for s in 1 2 3;do bash -c 'mycommand $s';done
[11:23:21] <Dark_Shikari> how do I get $s to propagate into the subshell?
[11:24:00] <twnqx> do export s; bash -c ... ?
[11:24:01] <jai> twnqx: -fpic missing, thats strange
[11:24:17] <Dark_Shikari> twnqx: great, thx
[11:24:30] <Dark_Shikari> I now have an ffmpeg fuzzer set up
[11:25:15] <Dark_Shikari> Any particular people want fuzzed?
[11:25:21] <Dark_Shikari> I'm fuzzing h264 + aac in mkv right now.
[11:25:44] <jai> Dark_Shikari: the mov/mp4 demuxer
[11:26:17] <Dark_Shikari> http://pastebin.org/101646 <--lazy 5 minute fuzzer
[11:26:18] <Dark_Shikari> usage:
[11:26:22] <Dark_Shikari> ./fuzzer inputfile outputfile
[11:26:53] <Dark_Shikari> example usage:
[11:26:54] <Dark_Shikari> for a in $(seq 20);do echo $a;./fuzzer IronMan.mkv IronMan.$a.mkv;export a;bash -c 'ffmpeg -y -i IronMan.$a.mkv output.avi > test2.txt 2>&1' 2> failures.txt;done
[11:27:06] <Dark_Shikari> failures.txt will hold "segmentation fault" if something failed
[11:27:16] <Dark_Shikari> hmm, I should make it so that failures.txt holds _which_ number it was
[11:27:24] <Dark_Shikari> test2.txt holds the log
[11:27:41] <Dark_Shikari> oh, guess I need to do 2>> failures.txt too
[11:29:13] <twnqx> jai: CFLAGS=-fPIC ./configure .. did the trick
[11:29:58] <jai> twnqx: ofcourse, my point was it should be set correctly by configure :)
[11:30:32] <twnqx> (in #mplayer) <zak_> is it possible to extract audio from a powerpoint file?
[11:30:39] <twnqx> we need a ppt demuxer!
[11:31:06] <twnqx> oh he asked i ffmpeg, too
[11:31:15] <jai> people must be doing moroccan black again
[11:37:26] <kshishkov> DonDiego: the same offer as for Reimar - place parentheses if you feel that's right
[11:38:44] <kshishkov> twnqx: that would be common OLE dungheap demuxer for old M$ Office documents
[11:39:20] <twnqx> kshishkov: i'd go for && instead of &
[11:39:39] <twnqx> if(!coded_inter) coded_inter = !is_intra[i] & is_coded[i]; <- or is there a reason to use binary?
[11:40:23] * janneg failed with that
[11:41:00] <twnqx> since i don't know if it's supposed to really mask a single bit i can't guarantee
[11:41:01] <janneg> twnqx: there are fears that && creates slower code
[11:41:27] <jai> you could always inspect gcc's output
[11:41:48] <kshishkov> and everybody (starting with me) is too lazy to benchmark and apply either solution
[11:41:59] <janneg> the code differs
[11:42:34] <twnqx> does it differ with (), too?
[11:43:01] <DonDiego> kshishkov: why didn't you add them in the first place? :-(
[11:43:09] <DonDiego> kshishkov: please don't just ignore warnings..
[11:43:13] <janneg> it shouldn't but I haven't tried
[11:44:24] <jai> or just disable that warning, since most people seem to be allergic to it
[11:45:30] <jai> -Wno-parentheses iirc
[11:48:19] <kshishkov> DonDiego: honestly, I don't remember. And I don't think it was printed by older GCCs.
[11:49:43] <DonDiego> yes, it's new, but that should not stop you from fixing it :)
[11:50:41] <kshishkov> yes, but the feeling that GCCs silently redefine operator precedence and come with warnings to cover that does
[11:51:28] <twnqx> if it's legal to redefine them you should have been worried from the beginning
[11:51:54] <twnqx> is there a certain degree of randomness in gcc's code generation?
[11:52:49] <twnqx> if not, using && instead of & canges the evaluation order of the term, and consequently register allocation etc
[11:52:56] <kshishkov> no, it's uncertainly large
[11:53:30] <twnqx> what i meant is: if i'm running the same .c file through it twice, should i getthe same .s file?
[11:53:46] <kshishkov> you should
[11:54:15] <twnqx> because i did the & vs. && change, and i see labels and register/temporary variable address allocation changed
[11:55:08] <kshishkov> first is simple AND, the second is "if !a set 0 else set !!b"
[11:56:07] <twnqx> excuse my while i read 6690 lines of diff -u to find more than label/offset/register changes
[11:56:37] <kshishkov> and for me that GCC warning sounds like "hello, in future your expression will be evaluated as 'coded_inter = !(is_intra[i] & is_coded[i]);', dont forget parentheses now or we'll silently screw it later"
[11:56:57] <twnqx> is precedence of ! vs. & defined?
[11:57:10] <kshishkov> look into K&R
[11:57:44] <twnqx> i don't have the book, and i personally just silence the warnings
[11:58:01] <kshishkov> first is unary operator and they should have the highest priority
[11:58:06] <twnqx> just in case i might be scrwed in a later release
[11:58:34] <DonDiego> #if (!defined(__ICC) || __ICC > 1110) && AV_GCC_VERSION_AT_LEAST(4,2)
[11:58:40] <DonDiego> this is confusing
[11:58:43] <DonDiego> why not
[11:59:06] <twnqx> ICC generates a GCC version?
[11:59:07] <DonDiego> #if (__ICC > 1110) || AV_GCC_VERSION_AT_LEAST(4,2)
[11:59:14] <DonDiego> or even better
[11:59:32] <DonDiego> #if AV_ICC_VERSION_AT_LEAST(1110) || AV_GCC_VERSION_AT_LEAST(4,2)
[11:59:46] <kshishkov> it won't work when it's GCC :)
[12:00:13] <DonDiego> why should it not?
[12:00:31] <twnqx> the first one, coause __ICC will not be defined. the second one should
[12:00:55] <kshishkov> ah, it may fail in case when __ICC > 1100 and it cannot pretend to be GCC 4.2
[12:00:58] <DonDiego> twnqx: summary: it should work
[12:01:03] <kshishkov> the question if that's possible
[12:01:18] <twnqx> yes
[12:01:35] <DonDiego> does anybody here have icc?
[12:01:46] <kshishkov> Carl should
[12:09:09] <twnqx> yuck, compiler inlines the full vc1_decode_p_mb function
[12:09:48] <Dark_Shikari> if it's only called once wouldn't it surely be inlined?
[12:10:11] <kshishkov> once per macroblock
[12:10:13] <twnqx> yeah, but makes finding the code close to impossible since there are no line numbers in the .s
[12:10:20] <Dark_Shikari> add noinline
[12:10:30] <twnqx> that might change the code
[12:11:10] <twnqx> also... i HATE AT&T syntax with a passion
[12:11:40] <kshishkov> well, not being on x86 helps
[12:11:46] <twnqx> heh
[12:11:54] <Compn> kshishkov : help me find 'eidos escape video studio' program so i can make some samples :)
[12:12:00] <peloverde> twnqx, well they invented UNIX, C, and information theory so sometimes we just need to live with their mistakes
[12:12:30] <kshishkov> Compn: ok, I'll try
[12:12:47] <kshishkov> peloverde: sometimes those were different people
[12:12:50] <twnqx> cmovge <- i'm so far out of asm i don't even know what this opcode does
[12:13:02] <kshishkov> conditional move
[12:13:16] <twnqx> oh
[12:13:24] <kshishkov> if previous compare result was "greater or equal"
[12:13:27] <twnqx> that would have been useful back in the 386 days
[12:14:06] <kshishkov> it was - on ARM
[12:18:49] <twnqx> kshishkov: i conclude: && will be slower than &
[12:19:12] <kshishkov> Compn: probably you'd have to ask some videogame dev to leak it to you, it's unlikely to be used outside inhouse dev process :(
[12:19:17] <twnqx> it really generates extra code
[12:19:38] <kshishkov> twnqx: indeed. And I'd rather see GCC fixed not to display idiotic warnings
[12:20:40] <twnqx> the () do not generate any difference
[12:20:49] <kshishkov> it should not
[12:21:43] <twnqx> i assume both variables are either 0 or 1 all the time?
[12:21:51] <kshishkov> yes
[12:32:29] <elenril> wtf
[12:32:46] <elenril> apparrently my system downloads stuff faster if it's doing some i/o
[12:36:03] <Compn> kshishkov : no, it was an actual codec for quicktime... also there was a demo but eidos' site is gone and the links are all 404
[12:36:07] <KotH> elenril: what kernel version?
[12:36:35] <Compn> kshishkov : old 404 links to demo >> http://www.siggraph.org/education/materials/HyperGraph/video/codecs/Escape.html
[12:37:21] <DonDiego> http://samples.ffmpeg.org/V-codecs/3ivx/
[12:37:24] <DonDiego> are these samples supposed to work with ffmpeg?
[12:37:27] <elenril> KotH: 2.6.33
[12:37:36] <DonDiego> it does not work here even after changing the preprocessor check in mpeg4video.h
[12:37:37] <KotH> elenril: have a look at dmesg
[12:37:43] <KotH> elenril: do you have any oopses?
[12:37:56] <KotH> elenril: page alloc failures, that is
[12:38:40] <elenril> no
[12:39:17] <Compn> DonDiego : file roundup issue for it :P
[12:39:39] <elenril> there's one i/o error. but these happen quite often, i blame dm-crypt
[12:49:22] <Compn> DonDiego : file roundup issue for 3ivx
[12:51:50] <DonDiego> hmm, well, ok...
[13:06:19] <DonDiego> mru: your blog appears to be down
[13:09:07] <DonDiego> mru: adding -D_XOPEN_SOURCE=600 fixed compilation on netbsd
[13:09:19] <DonDiego> are you ok with adding that to cppflags in configure then?
[13:11:39] <ShadowJK> I wonder if he got slashdotted (or whatever the modern equivalent is), I saw the link posted outside freenode in non-multimedia channels..
[13:12:09] <KotH> again?
[13:12:15] <DonDiego> reddit? ycombinator?
[13:12:30] <peloverde> he was on /.
[13:12:52] <kierank> there's also a post on the bbc backstage mailing list about how bad ogg is as well
[13:24:19] * mru curses web servers
[13:24:28] <mru> my lighttpd sometimes just stops serving anything
[13:24:38] <thresh> me likey nginx.
[14:10:51] <mru> lol at dilbert "evil is the cure for incompetence"
[14:11:12] <kshishkov> you should know that for ages
[14:12:10] <kshishkov> when I was promoted to project manager I'd been asked to study something other than Dilbert for project management for some reason
[14:12:43] <KotH> lol
[14:12:48] <mru> dilbert is how real companies actually work
[14:13:52] <kshishkov> I suspected that
[14:15:43] <kshishkov> still, there may be some differences. Like competent management is not always pointy-haired
[14:16:26] <mru> the difference is that _incompetent_ management is not always pointy-haired
[14:16:34] <mru> which makes them harder to spot at a distance
[14:17:12] <mru> to assess the competence of a manager, check how often he's changed groups/projects
[14:17:32] <mru> frequent changes w/o a promotion mean he's a problem being shuttled around
[14:17:38] <mru> but not bad enough to be fired on the spot
[14:18:01] <mru> frequent promotions mean he's an arse-licking bastard
[14:18:24] <kshishkov> or somebody's relative
[14:18:34] <KotH> if in japan, check whether his office has only a single desk facing the window ;)
[14:18:44] <mru> it means promotion was the simplest way to get him off your back
[14:18:52] <mru> KotH: :-)
[14:19:02] <mru> also check for red staplers...
[14:19:10] <KotH> red staplers?
[14:19:21] <kshishkov> KotH: "an ilk of looking into the window" or something, forgot that expression
[14:19:22] <mru> not seen Office Space?
[14:20:21] <kshishkov> a big mistake, I must say
[14:20:43] <kshishkov> (not to see it)
[14:21:13] * kshishkov wonders why http://en.wikipedia.org/wiki/C._Northcote_Parkinson is not listed as the greatest economist
[14:22:01] <KotH> mru: nope
[14:22:12] <KotH> mru: torrent? rsync server?
[14:23:21] <kshishkov> KotH: should be available everywhere, it's a cult movie
[14:23:47] <KotH> ofc, but i'm lazy :)
[14:24:29] <BBB> DonDiego: can you still help get the vso 20k?
[14:24:43] <BBB> dondiego: or should I do it through foundation? (that'll involve considerable paperwork here)
[14:44:21] <peloverde> Is there a way to shut up gcc about multilevel const issues short of tossing casts everywhere?
[14:44:43] <kshishkov> -Wsomething
[14:47:53] <BBB> -Wnone?
[14:48:14] <bilboed-pi> -Wburied-somewhere-deep-in-the-gcc-manpage
[14:48:17] <kshishkov> yes, GCC devs seem to stealthly advertise it more and more
[14:48:35] <peloverde> All I can find is -Wcast-qual which has other side effects
[14:48:44] <DonDiego> BBB: what sort of paperwork?
[14:49:21] <BBB> me or you?
[15:09:59] <BBB> peloverde: are you busy today?
[15:10:27] <peloverde> BBB: Just working on implementing michael's feedback on the SBR patch
[15:10:32] <peloverde> do you need something?
[15:11:12] <BBB> let's say I have this code for a postfilter and I rewrote it in float to use all FFmpeg RDFT code... I still don't actually know what it does
[15:11:48] <BBB> I'm hoping to show it to you so you can tell me what every step does (so I can add comments, make up useful function names, learn something useful)
[15:12:06] <BBB> it's 700LOC
[15:12:09] <BBB> approximately
[15:12:15] <peloverde> I can take a look and try to explain
[15:12:42] <BBB> including tables
[15:14:32] <peloverde> e-mail it or pastebin it or something like that
[15:15:23] <BBB> http://ffmpeg.pastebin.com/9VdR7pMA
[15:17:26] <peloverde> ok, it will take me a little while to digest that
[15:17:34] <BBB> basically the apf() function, and all stuff it calls
[15:18:32] <BBB> and sorry if some variable names are bad, it's still in a pretty rough state while I try to understand the code
[15:19:04] <BBB> if variables have a name other than "tmpXX", "varXX" or "arrXX", it should somehow make sense
[15:22:09] <kshishkov> BBB: lines 567-580 remind me of lowpass IIR filter
[15:22:55] <BBB> iir=synthesis
[15:23:01] <BBB> so lowpass speech synthesis?
[15:23:05] <BBB> hmm...
[15:23:36] * kshishkov has employed lowpass IIR filetr in AAC encoder for cutting off high frequencies
[15:23:38] <BBB> oh yeah sorry for those macro names, I think I was getting annoyed at that point for not getting something
[15:24:01] <kshishkov> so you wanted to get revenge at expence of reviewer? ok
[15:24:50] <BBB> I thought it was funny
[15:25:22] <kshishkov> lines 555-563 look like a windowing
[15:26:36] <kshishkov> farr13 is obviously a thing you could've renamed by yourself
[15:26:51] <BBB> some of those I'll get rid of
[15:26:55] <BBB> there's a lot of useless memcpy()s
[15:27:02] <BBB> I already cut half
[15:27:07] <peloverde> 555-563 look like some sort of filter to me, not windowing
[15:27:09] <BBB> I can probably get rid of another 50% of the remainder
[15:27:50] <BBB> so arrays are not yet named because they shouldn't be there, period
[15:28:08] <kshishkov> peloverde: yes, but that  f(n) = (0.99 + c)^n is a bit suspicious
[15:30:56] <peloverde> kshishkov, but it isn't quite (0.99 + c)^n
[15:31:10] <peloverde> f(n) = 0.99*f(n-1) + c
[15:31:36] <peloverde> you'll never wind up with c^n type terms
[15:35:00] <BBB> isn't it gain transition smoothing?
[15:35:33] <BBB> (if that's a term)
[15:35:38] <BBB> that's about all I got from it
[15:35:56] <BBB> and I'm interested especially in your take on 503-526
[15:36:07] <BBB> that's the frequency domain filter
[15:36:16] <BBB> but whatever it's doing inside there is like black magic to me
[15:37:31] <BBB> (and I assume the stuff before, line 466-488, is an echo filter?)
[15:40:16] <peloverde> BBB FYI a dsputil version of ff_dot_productf exists
[15:40:44] <kshishkov> maybe that stuff is used to smoothe frequencies around peaks (and peaks ~= impulses in LPC)
[15:42:20] <BBB> peloverde: I'll optimize/dsputilize after it's in SVN
[15:42:28] <BBB> first I want a version in SVN that works and is clear
[15:42:48] <BBB> that's one good thing I learned in Glib/GNOME - first make it work, then optimize it
[15:43:07] <BBB> unfortunately most people never make it to level 2
[15:43:52] <peloverde> I think one thing that would be helpful is going through and marking what is real and what is complex
[15:45:51] <peloverde> The RDFT calls do make it a little tricky because they transform the two
[15:51:13] <BBB> right
[15:51:33] <BBB> esp. because it's all in the same buffers
[15:54:53] <BBB> wbs: can you implement the URLProtocol caps field as suggested by Michael & me in that thread?
[15:54:59] <BBB> if not, I'll try this weekend
[15:55:04] * BBB seriously low on time now
[15:57:41] <kshishkov> BBB: any FT can be done in the same buffer - first you need to reorder coeffs by swapping and then perform a lot of butterflies with phase coeffs ;)
[15:58:21] <BBB> well the problem is that I have no idea what the data in the buffer means before and after the FT
[15:58:25] <BBB> I start with lpcs
[15:58:32] <BBB> then I FFT the lpcs (RDFT)
[15:58:37] <BBB> I have no idea what I have now
[15:58:51] <BBB> and so on
[16:00:42] <kshishkov> well, lines 94-96 are complex multiplication
[16:01:32] <wbs> BBB: I'll see if I have the time to try it out or if you beat me to it
[16:01:32] <peloverde> Yes, that's multiplying the FFT of the filter by the FFT of the signal
[16:02:21] <kshishkov> so it's really complex numbers in <Re Im> <Re Im> ... order
[16:02:40] <wbs> BBB: but generally, I don't think that netinit is all that expensive to perform a few times extra for  non-network protocols
[16:02:43] <BBB> yes, that's both complex
[16:02:56] <wbs> and that would be within #if CONFIG_NETWORK anyway, I guess
[16:03:19] <BBB> wbs: I was thinking that we shouldn't do it for e.g. file, hnce my suggestion of the extra CAP field
[16:03:46] <wbs> BBB: yeah, that's a good idea generally, but given that it'd break abi, I don't feel that it's all that important
[16:04:00] <BBB> hence my suggestion of the version #ifdef
[16:04:07] <BBB> but like I said, might be too much effort for no gain
[16:04:10] <BBB> I don't know
[16:04:14] <BBB> I'll leave it up to you
[16:04:18] <BBB> Michael seems OK with both
[16:04:24] <BBB> so do whichever seems better to you
[16:04:39] <BBB> I could always change it later, I guess
[16:04:57] <wbs> ok.. I guess I could try to benchmark ff_network_init() and see how slow it really is
[16:05:26] <BBB> it does nothing (on Linux)
[16:05:33] <BBB> or mac
[16:05:37] <wbs> yeah, I know, I meant on windows :-)
[16:05:41] <BBB> ah, ok
[16:05:49] <wbs> so for most normal platforms it doesn't really matter anyway
[16:07:18] <BBB> maybe that's why Michael doesn't care
[16:07:19] <BBB> :)
[16:07:43] <wbs> exactly, and I doubt all that many do multithreaded/intensive server-stuff with libavformat on windows anyway
[16:08:09] <BBB> fair enough, can you do it in url_open/close() then?
[16:08:16] <BBB> assuming your benchmarking is ok
[16:08:46] <wbs> yeah, I'll benchmark it on windows and try that one out; I'm not sure if I have the time to test it out tonight or tomorrow, but soonish anyway
[16:09:25] <wbs> I guess it will be #if CONFIG_NETWORK ff_network_init() #endif in url_open and url_close then, right?
[16:12:13] <BBB> yes
[16:14:13] <wbs> ok, so not all that elegant either, but at least confined to a few small places
[16:15:00] <peloverde> BBB: unfortunately I don't know much about LPCs which puts me a a disadvantage when trying to decipher the early parts of the code
[16:15:21] <BBB> hm, ok... maybe I should bug vitor also then
[16:15:32] <BBB> I don't really know lpcs either btw
[16:16:31] <kshishkov> BBB: look at libavcodec/truespeech.c - that's all _I_ know about speech codecs
[16:16:44] <BBB> still more than me
[16:16:54] <BBB> not for long, hopefully <evil smile>
[16:16:55] <peloverde> The fact that the 3rd input to _DoFilterProjection is treated as angles seems interesting
[16:17:10] <kshishkov> BBB: no, look there for real
[16:17:36] <peloverde> _DoFilterProjection is just farr1 = farr2 .* exp(j*in)
[16:18:58] * BBB poses that kshishkov has interesting ways of "RE'ing" a codec
[16:19:03] <peloverde> someone with better LPC knowledge, vitor or maybe ruggles might have better luck with the earlier sections of the code
[16:19:27] <BBB> kshishkov: that codec is in a rough state, I wouldn't have been comfortable committing it like that :>
[16:20:14] <kshishkov> BBB: look at copyright date, rules were easier those days
[16:20:21] <BBB> aha
[16:20:28] * kshishkov does not have much luck with audio codecs though
[16:21:58] <BBB> peloverde: but yes, many of these functions do very simple math
[16:22:12] <BBB> peloverde: I'm interested in what the math *means*, rather than what it *does*
[16:22:28] <BBB> I know what it does, I simplified it to 1-10 LOC :) - I have no idea what it means, though :-(
[16:22:46] <DonDiego> BBB: what paperwork do you need to do?
[16:22:59] <peloverde> The fact that it does do simple math, may give you clues what it means though
[16:23:16] <peloverde> Like the fact that in is angles is important
[16:23:22] <BBB> dondiego: "hire" michael as an employee, which might not be easy, or do extra taxpaperwork to take him as a consultant
[16:23:32] <BBB> right now I've set up the foundation to not be able to hire people
[16:23:35] <BBB> tax sucks anyway
[16:24:02] <BBB> peloverde: what's your take on 431-434?
[16:24:25] <BBB> peloverde: it does FFT, then shifts all RE into IM and zeroes the RE and then does iFFT
[16:24:28] <BBB> what does that mean?
[16:24:36] <DonDiego> how can the foundation spend money then?
[16:24:44] <kshishkov> BBB: mirroring
[16:24:46] <BBB> dondiego: grands, expenses
[16:24:59] <BBB> dondiego: "hiring" people is a little more complicated
[16:25:15] <BBB> I can hire him as a consultant right now, but then me and he will be taxed for that
[16:25:23] <BBB> I don't care so much, but he might
[16:25:40] * BBB needs an accountant
[16:26:06] <BBB> kshishkov: ?
[16:26:24] <BBB> kshishkov: sorry, that's probably a famous term, but I'm not sure I know what it means
[16:26:36] <BBB> don't forget this still is my first codec
[16:26:40] <kshishkov> BBB: lines 431-434 look like they mirror lower half coeffs
[16:27:22] <BBB> I meant 443
[16:27:28] <BBB> the code under that, after the loop
[16:27:29] <BBB> sorry :)
[16:27:45] <kshishkov> ah
[16:27:55] <BBB> note how I do rdft_calc(farr+1), and then Irdft_calc(farr)
[16:28:29] <BBB> the original code actually does for (n=0;n<0x41;n++) im=re; re=0;
[16:30:53] <BBB> 0x40, not 0x41, but anyway
[16:31:01] <kshishkov> you could use analytics here
[16:31:03] <peloverde> hilbert transformer@
[16:32:04] <BBB> that wikipedia page is scary
[16:32:12] * BBB wishes he had continued math in college now
[16:32:42] * kshishkov had math only for 1.5 years at his university
[16:33:37] <peloverde> When you go from real to imaginary there is an implied part of the spectrum that is conjugate symmetric
[16:33:46] <peloverde> so it goes from real to imaginary with the opposite sign
[16:37:52] <BBB> I think I'm gonna get a math textbook to understand that wikipedia page
[16:38:06] <BBB> do you guys have mathbook suggestions?
[16:38:12] <BBB> I can probably get them cheaply in the uni bookshop
[16:38:51] <kshishkov> anything by German authors ;)
[16:39:17] * BBB will be right back
[16:39:36] <peloverde> If you mean a generic calculs type text then no, if you mean signal processing math then I'm biased toward Haykin VanVeen and Lathi
[16:39:39] <janneg> if the author is dead for at least 50 years
[16:44:45] <DonDiego> peloverde: link?
[16:45:08] <DonDiego> BBB: then how about a grant?
[16:46:57] * mru has signals&systems by oppenheim&willsky
[16:47:04] <mru> made sense back when I read it
[16:47:37] <kshishkov> not anymore?
[16:47:44] <mru> don't know
[16:47:55] <mru> haven't opened it in a long time
[16:47:59] * kshishkov is not sure he's read something serious about signal processing at all
[16:49:23] <mru> that was the recommended textbook in uni
[16:50:14] <kshishkov> you must be liberal, here they just told you what to read (and that's all you could get at the library too)
[16:50:55] <mru> we were allowed to read anything of course
[16:51:03] <mru> so long as we passed the exams nobody cared
[16:51:19] <mru> lectures usually followed some book though
[16:51:27] <mru> so it was a good idea to get the recommended one
[16:51:54] <mru> on a couple of courses I used similar books my brother already had
[16:53:09] <kshishkov> well, mine KTH was definitely worse than yours
[16:53:27] <kshishkov> (but it produces crap in rather large quantities)
[17:18:23] <mru> kshishkov: http://www.theregister.co.uk/2010/02/24/iplayer_xbmc_adobe_swf_verification/
[17:19:48] <kshishkov> nice
[17:19:57] <mru> well, can you fix it?
[17:20:07] <mru> we're not afraid of the dmca are we?
[17:20:12] <kshishkov> no, BBC is not fixable
[17:20:46] <kshishkov> and in my position the less people use that crap the better
[17:20:52] <kierank> presumably because ffmpeg has no knowledge of the swf file?
[17:21:06] <mru> kierank: it's an rtmp thing
[17:21:30] <kierank> yes, but swf verification afaik is a hash of the swf file that is needed to authenticate
[17:21:52] <kshishkov> theoretically it's easy to record official iPlayer session and if they haven't complicated it, fixed reply should be enough
[17:21:56] <mru> if iplayer can do it, so can we
[17:22:06] <kierank> get_iplayer still works
[17:22:38] <mru> DRM rule #1: there is no protection
[17:23:07] <Dark_Shikari> kshishkov: so I hear you want to get out of ukraine
[17:23:12] <kshishkov> see one of Michael's sigs
[17:23:17] <mru> summary of drm: here's a lock and a key, please don't use the key in the lock
[17:23:20] <kshishkov> Dark_Shikari: doesn't everybody?
[17:23:37] <mru> kshishkov: only those who are in to begin with
[17:23:40] <Dark_Shikari> seriously though, what's the issue? =p
[17:23:47] <mru> Dark_Shikari: it's a back-water
[17:23:49] <kshishkov> mru: local corrolary: there's always a hole in the wall anyway
[17:24:39] <Dark_Shikari> well that's a given
[17:24:45] <kshishkov> Dark_Shikari: it's mostly a matter of somebody pulling me to other land
[17:24:46] <Dark_Shikari> I guess the crappy internet is a good enough reason to move
[17:25:06] <Dark_Shikari> I was just wondering if it was some particular event/crappy thing going on
[17:25:07] <kshishkov> crappy everything
[17:25:12] <Dark_Shikari> or just ukraine in general sucking
[17:25:16] <mru> Dark_Shikari: the only difference compared to the ussr is that now they can choose their bureaucrats
[17:25:29] <Dark_Shikari> e.g. right now, the UK and Australia both have great reasons to gtfo
[17:25:45] <kshishkov> Dark_Shikari: it's almost perfect in sucking
[17:25:53] <KotH> mru: hint: if the copyprotection system goes even a tad bit over a very narrow description of what a copy protection system does, then it isn't protected by law. ie it is legal to break it and distribute the tools to do so
[17:25:59] <KotH> mru: at least in .ch :)
[17:26:02] <kierank> Dark_Shikari: it's getting torn to pieces in the house of lords anyway
[17:26:18] <Dark_Shikari> kierank: "it" can mean various different things
[17:26:29] <mru> kierank: what? mandy's stupid law?
[17:26:29] <Dark_Shikari> I'm pretty sure they're not tearing your cameras to pieces :)
[17:26:38] <kierank> mru: yes
[17:27:19] <Dark_Shikari> hopefully this continues and it doesn't pass.
[17:27:23] <CIA-92> ffmpeg: vitor * r22222 /trunk/libavformat/utils.c: Fix memory leak in NUT muxer
[17:27:25] <Dark_Shikari> then again, australia is still royally fucked
[17:28:13] <kierank> won't pass before the election anyway
[17:28:14] <kshishkov> Dark_Shikari: strong selling points - no useful infrastructure, food gets crappier each year, no real perspectives
[17:29:06] <elenril> mafia in the goverment?
[17:29:40] <Dark_Shikari> sounds just like everywhere else then
[17:29:50] <mru> does anyone know a decent, free country?
[17:30:05] <Dark_Shikari> saveden
[17:30:09] <Dark_Shikari> iculando
[17:30:11] <kshishkov> elenril: the term "Dniepropetrovsk mafia" describing local government was coined in Brezhnev times
[17:30:15] <Dark_Shikari> finulando
[17:30:37] <mru> I have doubts about sweden
[17:30:38] <kshishkov> mru: jag vet om gamla och fria land
[17:30:42] <mru> don't know about .fi
[17:30:42] * elenril heard chocolateland is nice
[17:30:47] <mru> language is a bitch there
[17:30:47] <Dark_Shikari> sweden seems to be doing pretty well
[17:30:58] <Dark_Shikari> oh yeah, Netherlands
[17:31:00] <mru> .se has fast internet, that's about it
[17:31:12] <kshishkov> mru: one of those languages, the second language is fine
[17:31:17] <mru> .nl has a learnable language at least
[17:31:28] <mru> kshishkov: swedish only works in parts of finland
[17:31:31] <Dark_Shikari> mru: don't even need to
[17:31:36] <Dark_Shikari> I know a guy who worked out of nl for like 7 years
[17:31:39] <Dark_Shikari> he never learned the language
[17:31:39] <mru> you'd have to learn finnish eventually
[17:31:46] <Dark_Shikari> he said it worked fine
[17:31:52] <mru> sure it would work
[17:31:56] <Dark_Shikari> apparently the .nl guys are really picky about their language too
[17:31:58] <mru> but if I lived there I'd learn it
[17:32:05] <kshishkov> mru: at least it's interesting from linguistics PoV
[17:32:08] <mru> I can pretty much read it
[17:32:09] <Dark_Shikari> i.e. if you get it even very slightly wrong, they get mad and ask you to use english
[17:32:12] <Dark_Shikari> =p
[17:32:41] <kierank> could live with all the british expats in the south of spain
[17:32:57] <Dark_Shikari> meh, spain
[17:33:01] <Dark_Shikari> the rain in spain falls mainly on the plain
[17:33:12] <mru> I know some nice spanish girls
[17:33:47] <kshishkov> mru: asked Diego?
[17:33:51] <Dark_Shikari> japan works mostly fine if you're willing to put up with absurdly high rent and being a gaijin for the rest of your life
[17:33:56] <mru> germany has issues
[17:34:07] <Dark_Shikari> south korea works well if you're willing to learn a mostly useless languaZERG RUSH KEKEKEKEKEKEKEK
[17:34:16] <mru> I don't think I could put up with japan in the long term
[17:34:30] <mru> korean language is hard
[17:34:37] <Dark_Shikari> it's easier than japanese iirc
[17:34:39] <mru> nice people though
[17:34:40] <Dark_Shikari> taiwan works well if you're willing to put up with a hilariously insane political system
[17:34:42] <mru> harder than japanese
[17:34:48] <mru> easier script
[17:34:55] <kshishkov> Dark_Shikari: here it's both absurdly high rent and mostly useless language let alone political system
[17:35:19] <kshishkov> mru: maybe you don't play Starcraft enough
[17:35:28] <Dark_Shikari> Just watch pro starcraft for a year or two
[17:35:34] <Dark_Shikari> and you will get used to the soothing voices of korean commentators
[17:35:49] <mru> I know what korean sounds like
[17:35:55] <kshishkov> mru: also it's fiendishly easy script - no spaces or other means of divinding words
[17:35:59] <Dark_Shikari> puroxy roboticuso bay!
[17:36:06] <peloverde> If you like the sound of Korean, work on the BSAC decoder!
[17:36:07] <mru> kshishkov: they do have spaces
[17:36:27] <kshishkov> mru: but they don't seem to use them often enough
[17:36:33] <mru> it's the grammar that's hard
[17:36:49] <kshishkov> try Russian
[17:36:52] <mru> I did
[17:36:56] <kshishkov> I know
[17:37:23] <Dark_Shikari> Oh yeah, there's israel, which is great if you're jewish and you're fine with a missile attack every once in a while
[17:37:35] <mru> and learning f*cking hebrew
[17:37:41] <peloverde> DonDiego, http://www.amazon.com/Signals-Systems-2nd-Simon-Haykin/dp/0471164747 http://www.amazon.com/Signal-Processing-Linear-Systems-Lathi/dp/0195219171/
[17:37:55] <Dark_Shikari> hebrew isn't that bad
[17:37:59] <Dark_Shikari> probably easier than japanese.
[17:38:03] <mru> lol, spammers selling "steel buildings" again
[17:38:22] <mru> I couldn't live in israel
[17:38:29] <kshishkov> Dark_Shikari: I can comprehend Japanese even when I don't know how to read certain kanji
[17:38:30] <mru> not for the missiles
[17:38:37] <mru> they're not so big a deal
[17:38:39] <kshishkov> not for the people
[17:38:46] <mru> the people are totally weird
[17:38:52] <mru> I've met enough of them
[17:38:59] <mru> some of them are really nice
[17:39:00] <kshishkov> yes, and a good deal of them came from here
[17:39:03] <mru> but they're too few
[17:39:12] <mru> I've met loads in the old company
[17:39:22] <kshishkov> mru: I know only one good "crazy Jewish guy"
[17:39:44] <DonDiego> oded?
[17:39:49] <kshishkov> nej
[17:39:51] <mru> merbzt
[17:40:37] <Dark_Shikari> crazy jewish guy--> is any other type that exists?
[17:40:47] <DonDiego> peloverde: thx
[17:41:54] <kshishkov> Dark_Shikari: yes, I have sheerly mad drunkard guy or certain origin in neighbourhood
[17:42:39] <KotH> peloverde: oh.. thanks... forgot to ask about those books :)
[17:43:14] <kshishkov> Dark_Shikari: and those teachers I met of Jewish origin were probably the best ones I've ever met for both professional and human qualities
[17:43:43] <mru> I didn't say jews, I said israelis
[17:43:54] <mru> the jews in other countries aren't usually as crazy
[17:44:12] <kshishkov> half of them have relatives emigrated to Israel
[17:44:20] <DonDiego> bye
[17:45:18] <KotH> hmm..
[17:45:40] <KotH> does anyone have an idea why irssi would stop loggin a specific channel?
[17:45:50] <mru> you told it to?
[17:46:00] <KotH> correction, everything on freenode
[17:46:17] <KotH> it didnt write a singe line of log for freenode since i reconnected
[17:46:38] <kshishkov> out of free space?
[17:46:43] <KotH> nope
[17:46:46] <mru> maybe you forgot to save some setting
[17:46:47] <KotH> all other servers log fine
[17:46:59] <KotH> mru: i havent touched any setting for years
[17:47:22] <mru> maybe you should have...
[17:47:22] <KotH> wtf...
[17:47:22] <kshishkov> what about writing permissions?
[17:47:24] <KotH> it logs
[17:47:35] <KotH> but to ~/irclogs/freenode/*.log ^^'
[17:47:47] * KotH wonders how that happend
[17:48:00] * KotH tries a restart
[17:49:36] <kshishkov> log this!
[17:50:25] <KotH> wtf..
[17:50:29] <KotH> something is fucked up
[17:50:51] <kshishkov> have you updated irssi?
[17:51:26] <KotH> nope
[17:52:28] <kshishkov> and it's not part of Gnome, i.e. does not have a tendency to randomly screw configs, doesn't it?
[17:53:19] <elenril> blame Kovensky!
[17:54:09] <kshishkov> no, he uses mru for blaming on everything
[17:55:37] <kierank> blame xiph
[17:57:09] <KotH> hmm..
[17:57:12] <KotH> let me try something
[18:02:44] <KotH> at least, i'm not alone with that prob ^^'
[18:03:23] <kshishkov> KotH: try my way - don't treat it as a problem ;)
[18:03:35] <KotH> kshishkov: er.. i think it is a prob
[18:03:54] <kshishkov> KotH: yes, that's exactly what is wrong with you
[18:04:48] * KotH thinks kshishkov is the problem
[18:05:00] <kshishkov> you've not seen me yet
[18:09:37] <kshishkov> here's a nice string for you to log
[18:12:13] <KotH> kshishkov: it was a bug in irssi ^^'
[18:12:24] <elenril> did you send a patch?
[18:12:47] <KotH> it has been fixed ages ago... but i'm using debian/stale :/
[18:13:11] <elenril> o_0
[18:13:16] <elenril> why would you want to do that
[18:13:22] <KotH> lazyness
[18:13:30] <KotH> you know, *effort* and such ;)
[18:13:36] * elenril knows
[18:15:37] <elenril> laziness is the foundation of all physics
[18:21:47] <kshishkov> engineering too
[18:22:53] <kshishkov> for example, C.F. Gauss performed Fourier transforms by hand
[18:24:26] * elenril meant that universe itself is lazy
[18:24:29] <elenril> http://en.wikipedia.org/wiki/Principle_of_least_action
[18:24:39] <peloverde> gauss invented the fft
[18:25:02] <kshishkov> what has that French guy done then?
[18:25:31] <peloverde> Fourier invented the slow fourier transform
[18:25:53] <elenril> iirc without any mathematical foundation for it
[18:26:14] <kshishkov> it can be Tailored ;)
[18:27:57] <elenril> and i think he only invented fourier series
[19:28:20] <peloverde> KotH, I put the old CT aacPlusDecoderCheckPackage_v2.1 on samples but am having trouble making it readable
[19:33:26] <peloverde> nevermind i got it
[19:36:25] <BBB> shit he left
[19:36:34] <BBB> hmm...
[19:36:40] <BBB> peloverde: thanks for the book ref, I'll check it out
[19:36:45] <BBB> I indeed meant signal processing math
[19:36:47] <BBB> I know general math
[19:36:54] <BBB> although I might have to refresh it here and there
[19:37:30] <ohsix> dspguide is free if you haven't seen that yet :P
[19:38:11] <BBB> btw elenril if you think physics is lazy, you should check out biology
[19:38:48] <kshishkov> you mean watching evolution process?
[19:40:34] <peloverde> I'm getting angry warnings on my aacPlus Decoder Check, this can't be good
[19:40:47] <peloverde> It also says that we are missing 3gpp asset metadata support
[19:40:55] <BBB> kshishkov: look at mice grow
[19:40:58] <BBB> if not something else
[19:41:03] <ohsix> why are there so many people with 9 char nicks that start with p :O
[19:41:25] <kshishkov> look at nicks starting with 'k'
[19:41:46] <ohsix> i'm lucky i dont also have 4 of those in one window
[19:53:15] <elenril> http://entertainment.slashdot.org/story/10/03/05/1723215/Microsoft-Sends-Flowers-To-Internet-Explorer-6-Funeral
[19:54:27] <kshishkov> they'd rather send other IEs to bury along with it
[20:00:13] <peloverde> The files in the aacPlus decoder check appear to be illegal... lovely
[20:02:01] <KotH> peloverde: files in the samples directory will have their permissions fixed every hour (xx:17), so just put there what you want and let it ferment ;)
[20:05:15] <CIA-92> ffmpeg: vitor * r22223 /trunk/libavcodec/imgconvert.c:
[20:05:15] <CIA-92> ffmpeg: Round correctly chroma picture height.
[20:05:15] <CIA-92> ffmpeg: Fix issue 956.
[20:26:47] <mru> skype is hiring codec devs
[20:27:11] <elenril> they should hire kshishkov
[20:27:24] <mru> they have office in stockholm
[20:27:49] <BBB> indeed, they should hire that boy that JUST RAN OUT OF THIS CHANNEL
[20:31:04] <mru> hmm, they're using an ancient email address of mine
[20:31:07] <mru> wonder where they got it
[20:31:28] <mru> good thing every email address I've used in the last 10 years still works
[20:37:03] <Dark_Shikari> mru: did you just get a call?
[20:37:12] <mru> email
[20:37:16] <Dark_Shikari> They just called me up asking me to work for them
[20:37:28] <Dark_Shikari> and asking for where to find more codec devs
[20:37:49] <mru> what did you tell them?
[20:38:51] <Dark_Shikari> that I'm probably booked this summer unless they can offer a lot of money
[20:38:52] <peloverde> I'm sure he told them the truth... to forge a new codec dev, you must first slay an old god
[20:39:00] <Dark_Shikari> But I'm willing to consult and contract as always
[20:39:07] <Dark_Shikari> and that their codec devs should feel free to contact me at any time, via any channel
[20:39:15] <Dark_Shikari> And that they should look at Doom9 for more codec people
[20:39:39] <Dark_Shikari> and ffmpeg
[20:49:05] <Compn> skype going to make a new codec?
[20:49:11] <Compn> instead of paying for h264 / aac ? :P
[20:49:19] * Compn forgets what skype uses now
[20:49:28] <wbs> they have some codecs of their own, iirc
[20:49:39] <wbs> http://en.wikipedia.org/wiki/SILK
[20:50:03] <mru> they're looking for people with knowledge of h264
[20:50:13] <kierank> Compn: they use vp7
[20:50:34] <Dark_Shikari> they used VP7
[20:50:34] <Dark_Shikari> yeah
[20:51:15] <Dark_Shikari> This is one reason I want to get that proprietary license done
[20:51:17] <Dark_Shikari> sell them x264
[20:51:20] <Dark_Shikari> get them away from vp7
[21:11:54] <BBB> hm...
[21:12:03] <BBB> so now we can see how people outside rank us
[21:12:13] <BBB> apparently mru and dark)shikari are codec gods
[21:12:28] <BBB> now we'll see who are merely mortal, and who ar nothing at all, just by sequence of calls and whether we get a call at all
[21:12:38] <Dark_Shikari> but mru has never even done work on a lossy codec =p
[21:12:51] <mru> what makes you say that?
[21:13:28] <BBB> Dark_Shikari: well be that true or not, he did get the first call
[21:13:33] <Dark_Shikari> he got an email
[21:13:34] <Dark_Shikari> I got a call
[21:13:35] <BBB> so for all practical purposes, he is THE codec god
[21:13:42] <mru> do they have my number?
[21:13:43] <BBB> maybe they don't have his phone#
[21:13:53] <BBB> method of connection is irrelevant
[21:13:59] <BBB> it's about ORDER, SEQUENCE :-p
[21:14:01] <mru> anyone with basic net skills can find it
[21:14:06] <pasteeater> did they call you with skype?
[21:14:18] <pasteeater> DW BUS CORP. "randome number"
[21:14:19] <Dark_Shikari> pasteeater: lol, my cell phone
[21:14:23] <Dark_Shikari> from my CV
[21:14:41] <mru> the email said someone had recommended me
[21:14:48] <mru> but all such emails say that
[21:14:50] <pasteeater> i meant from skype.  sometimes the caller id is "spammy".  Anzazi Sportswear.
[21:15:23] <pasteeater> mru: Hello, I am Nigerian Royalty named Mr. Elvis Guru.  Someone recommended you.
[21:15:46] <mru> this one seemed genuine
[21:15:48] <Dark_Shikari> they said they saw my resume on my blawg
[21:28:16] <BBB> oops, wrong button
[21:34:54] <Rathann> who's in charge of ffmpeg.org DNS, KotH?
[21:37:06] <mru> root is in charge
[21:37:11] <mru> is there a problem?
[21:41:05] <mru> macros defining macros, OH YEAH
[21:41:17] <mru> and self-undefining macros
[21:42:44] <Honoome> autoconf again?
[21:45:03] <mru> oh no
[21:45:06] <mru> gnu as
[21:46:42] <Honoome> oh even better then
[22:00:57] <wbs> BBB: I tried benchmarking ff_network_init on windows... when using two different timers with millisecond precision, I just get 0 ms runtime for the call. when using a slightly modded START_TIMER/STOP_TIMER (modded to print the runtime for each invocation), I get something like this:
[22:01:09] <wbs> 129155310 dezicycles in ff_network_init, 1 runs, 0 skips (for the first invocation, which actually loads stuff I think)
[22:01:21] <wbs> 940310 dezicycles in ff_network_init, 1 runs, 0 skips (for later invocations)
[22:02:40] <wbs> so later invocations are much faster (I think it just does some reference counting somewhere and doesn't load the networking system twice), and the first invocation is also less than 0 ms on this machine, so calling it once too much on startup isn't all that bad IMO
[22:04:35] <KotH> Rathann: anyone of mru, diego or me
[22:04:58] <Rathann> KotH: ack, thanks
[22:19:01] <BBB> wbs: fair enough, feel free to commit it in url_open/close_protocol() then
[22:20:18] <wbs> BBB: I had to keep ff_network_init/close in rtsp btw, since that's a (de)muxer and not a protocol.. but for gopher/http/rtp/rtmp I could get rid of the protocol-specific initialization
[22:20:35] <BBB> rtsp is fine
[22:20:39] <BBB> I'm surprised it didn't do that already
[22:20:58] <BBB> don't forget rtsp opens tcp control connection
[22:21:05] <BBB> and don't forget sdp either
[22:21:12] <wbs> they're taken care of. :-)
[22:21:31] <BBB> right, but if tcp open happens before sth. else, than rtsp doesn't need it anyway
[22:21:39] <BBB> but well yeah who cares, go ahead and commit it :)
[22:21:57] <wbs> the whole mess, or just the network_init/close stuff?
[22:22:20] <wbs> whole mess as in ff_url_join and network_init/close
[22:23:47] <BBB> just the network_init
[22:23:58] <wbs> ok
[22:24:00] <BBB> I think I already said the ff_url_join stuff was fine, didn't I?
[22:24:05] <BBB> so you can then commit that afterwards also
[22:24:09] <wbs> ok
[22:24:11] <BBB> don't forget to say "applied" on the mailinglist
[22:24:18] <wbs> yeah, I will. :-)
[22:24:21] <BBB> the rest (EGAIN stuff) was not OK yet :)
[22:24:31] <wbs> no, that's a completely different series :-)
[22:30:40] <wbs> ok, here goes nothing...
[22:31:13] <CIA-92> ffmpeg: mstorsjo * r22224 /trunk/libavformat/avio.c:
[22:31:13] <CIA-92> ffmpeg: Always call ff_network_init/ff_network_close when opening protocols
[22:31:13] <CIA-92> ffmpeg: ff_network_init is a no-op on all platforms except windows, and on
[22:31:13] <CIA-92> ffmpeg: windows the performance penalty is minimal (less than 1 ms in my tests).
[22:32:33] <CIA-92> ffmpeg: mstorsjo * r22225 /trunk/libavformat/ (utils.c avformat.h): Add a function ff_url_join for assembling URLs
[22:36:10] <wbs> BBB: ok to remove the ff_network_init/close from tcp.c/udp.c, too, now that they're inited in avio.c?
[22:36:11] <CIA-92> ffmpeg: mstorsjo * r22226 /trunk/libavformat/ (rtmpproto.c rtsp.c rtpproto.c rtspenc.c http.c gopher.c):
[22:36:11] <CIA-92> ffmpeg: Use ff_url_join for assembling URLs, instead of snprintf
[22:36:11] <CIA-92> ffmpeg: This ensures proper escaping of numerical IPv6 addresses.
[22:36:11] <CIA-92> ffmpeg: The RTSP (de)muxer needs its own network initialization, since it isn't
[22:36:11] <CIA-92> ffmpeg: a protocol and url_open hasn't been called yet.
[22:37:42] <BBB> wbs: yes
[22:39:39] <CIA-92> ffmpeg: mstorsjo * r22227 /trunk/libavformat/ (tcp.c udp.c):
[22:39:39] <CIA-92> ffmpeg: Don't explicitly initialize networking in the tcp and udp protocols
[22:39:39] <CIA-92> ffmpeg: Networking is always initialized when opening protocols.
[22:41:10] <elmojo> janneg: one other type of message I see is "cannot read: /home/user/.blender/04.blend_comp7.exr" - let me know if that is a problem.
[22:41:20] <BBB> \o/
[22:45:19] <wbs> ah, always feels great to be able to remove all the temp branches for different versions of submitted patches :-)
[22:45:24] <j0sh> wokring on the theora rtp depayloader. should theora data fragments be buffered to a whole unit before they're sent to a decoder?
[22:46:18] <wbs> j0sh: for H263 at least, the data from each RTP packet is returned immediately, but then passed into a parser that joins the packets as appropriate
[22:46:33] <Yuvi> j0sh: yesh, the decoder only works on an entire frame
[22:46:57] <wbs> but if there isn't any suitable parser that can do that, it's probably better to buffer it up properly in the depacketizer instead
[22:47:24] <Yuvi> with theora it's impossible for a parser to combine them
[22:47:36] <Yuvi> has to be done at the demuxer level
[22:48:02] <wbs> ok, well then the decision is even easier :-)
[22:48:26] <j0sh> gotcha... i noticed in the vp3 (theora) source, there are some provisions for handling "fragments," is this unrelated?
[22:48:45] <Yuvi> yes, it's what vp3 called blocks
[22:49:07] <Yuvi> though theora made some weird distinction between "block" and "fragment" depending on whether you're iterating in hlbert or raster order
[22:49:46] <j0sh> alright, i will buffer the data in the depayloader then. thanks!
[22:52:53] * BBB excited to see sudden interest in ff-rtsp stack
[22:52:57] <BBB> so what drives all this?
[22:53:30] <janneg> elmojo: I think that are blender temp files
[22:55:02] <j0sh> i tried working on h264 but it was too complicated... so i'm turning to rtsp, heh
[22:58:55] <BBB> last year one student tried the theora dpayloader, didn't work unfortunately :(
[22:59:04] <BBB> the vorbis one got done though, so use that as your template
[22:59:05] <BBB> a
[22:59:14] <j0sh> yup thats what im doing
[22:59:14] <BBB> afaik they're almost identical
[22:59:58] <j0sh> the feng rtsp server sends all the theora data as fragmented packets which vorbis rtp doesnt handle, so im adding that
[23:01:36] <j0sh> if the end of a fragmented packet is only a few bytes and there's room to start a new frame, is that done?
[23:01:57] <BBB> probably
[23:02:03] <BBB> every byte is a byte
[23:02:53] * mru thought every byte was 8 bits
[23:05:11] * Kovensky bytes mru
[23:05:22] <mru> ouch, Kovensky bit me
[23:06:12] <ohsix> 8 times
[23:10:27] <CIA-92> libswscale: michael * r30847 /trunk/libswscale/swscale_template.c: try to avoid returning odd slices.
[23:14:44] <wbs> j0sh: don't know how the rtp/theora stuff works, but what I've seen of other rtp schemes, you either split one frame into multiple packets (but only keep data from one frame in each packet, so the last packet is a smallish one) or join multiple frames into one packet (for audio)
[23:20:59] <wbs> BBB: I think one reason for the amount of rtsp-demuxing/decoding related fixes from me, at least, is that I've only found the lacking areas one at a time, so instead of going "omg, this is severly lacking", I've noticed that "this should be quite usable, except for this little detail that's bugging me"
[23:21:52] <wbs> as long as bugs are found in that way, it's much easier to keep up the motivation to fix issues that aren't critical but only annoying :-)
[23:24:15] <j0sh> wbs, yeah thats pretty much what the theora/vorbis rfcs say -- last packet in the fragment is smallish, but i wasn't sure. i ran some tests and that seems to be the case
[23:25:06] <BBB> wbs: I think the stack isn't in too bad a shape, it's got a lot of features
[23:25:11] <BBB> but I know some major stuff is lacking
[23:25:32] <BBB> I always found that firewall hole-poking thing which you wrote an annoying miss
[23:26:01] <BBB> there's probably some other things on my todo list, but it's in quite a good state
[23:26:18] <wbs> j0sh: ok, then I guess you won't have to worry about that case, unless you find an example of such a weird source producing that kind of packets
[23:26:27] <j0sh> yeah, ive been lurking on the ML awhile -- that firewall/nat thing was pretty cool, i gotta say
[23:27:19] <wbs> j0sh: for the hypothetical case with concatenaed split theora frames, you wouldn't get the timestamp for the second frame (unless that's within the payload itself in some way), so I don't think you'll encounter that :-)
[23:27:52] <BBB> video frames are much bigger than that, typically
[23:28:15] <BBB> I have yet to find a video codec that can pack a full 320x240 frame in <1500bytes
[23:28:37] <BBB> PNGalpha with continuous series of black frames does not count
[23:29:49] <wbs> BBB: well, the mess with hardcoded stuff for different codecs vs dynamic payload depacketizers in rtpdec.c feels a bit awkward, but I guess I should step up and convert the AAC stuff to a proper dynamic payload handler
[23:30:13] <mru> BBB: that's 0.15 bits per pixel
[23:30:19] <mru> h264 can manage that on average
[23:30:25] <BBB> hm...
[23:30:29] <mru> I-frames will be bigger
[23:30:35] <BBB> that'd be interesting
[23:30:53] <BBB> wbs: rtpdec.c splitting would be nice
[23:30:58] <BBB> but it used to be worse
[23:31:01] <BBB> so I won't complain too much
[23:31:04] <wbs> I can imagine :-)
[23:31:18] <wbs> reading svn logs is quite a horror trip sometimes :-)
[23:31:48] <mru> hopefully it has a happy ending
[23:32:16] <BBB> mru: the rtsp stack is ok right now
[23:32:19] <mru> but usually there are plenty of openings for sequels
[23:32:21] <BBB> like I said, it's been a lot worse
[23:32:34] <BBB> and most obvious stuff, like radio streams, works now
[23:32:44] <BBB> I had a patch to make quicktime sessions work also, but that's not in yet
[23:32:51] <BBB> (for steve jobs keynotes)
[23:33:13] <mru> I don't think I've ever played an rtsp stream
[23:33:26] <mru> outside of work
[23:36:50] <j0sh> would be nice if html5 <video> and <audio> could work with rtsp, i think
[23:38:12] <j0sh> correct me if i'm wrong but as far as i can reckon, arent the tags limited to progressive playback under most circumstances right now?
[23:39:11] <wbs> j0sh: firefox actually manages to play progressively streamed ogg over http, too, but it doesn't really work well enough to be really usable
[23:40:05] <BBB> j0sh: progressive as in no-seeking? I think it's supposed to be a complete video playback engine
[23:40:11] <BBB> including all the bells and whistles
[23:40:27] <BBB> rtsp should work too then
[23:40:49] <j0sh> i guess, i took progressive to mean download completely (or buffer to a certain length), then play
[23:41:14] <j0sh> no seeking, yeah
[23:42:09] <BBB> I'd be surprised
[23:42:16] <BBB> I'd expect it to work for streaming/live also
[23:42:20] <BBB> but well, who knows :)
[23:44:36] <j0sh> ok well i gotta go eat dinner and run errands. thanks for the help and i'll keep working on the depayloader over the weekend
[23:44:52] <wbs> BBB: well, since the html5 standards don't mandate any formats/protocols/codecs at all, I guess it's all up to the browsers which streaming protocols they want to support
[23:45:19] <BBB> right
[23:45:24] <BBB> j0sh: ok, keep us updated
[23:45:33] * BBB will run for dinner also
[23:46:25] <wbs> and I'll go sleep soon, too
[23:48:03] <BBB> later then!