[02:05:53] <Yuvi> mru: OS X 10.6 hides the prototype for inet_aton with _POSIX_C_SOURCE [02:16:08] <Yuvi> it looks like only inet_ntoa is in posix? [02:21:10] <Dark_Shikari> Yuvi: found anything yet? [02:21:35] <Yuvi> for the crashes, no (since I needed ffmpeg to compile first :P) [02:22:07] <Dark_Shikari> lol [02:27:32] <CIA-92> ffmpeg: conrad * r22271 /trunk/libavformat/matroskadec.c: matroskadec: Fix a buffer overread [02:27:32] <CIA-92> ffmpeg: conrad * r22272 /trunk/libavformat/oggparsedirac.c: Fix warning about incompatible pointer types [02:35:12] <Compn> j-b : can you add t263 to h263 decoder in vlc fourcc.c ? samples > http://samples.mplayerhq.hu/V-codecs/T263/ [02:36:38] <CIA-92> ffmpeg: conrad * r22273 /trunk/libavformat/seek.c: [02:36:38] <CIA-92> ffmpeg: Add internal.h include for av_read_frame_flush prototype [02:36:38] <CIA-92> ffmpeg: Fixes build with clang [02:43:26] <Yuvi> clang being more strict with -Werror=implicit seems like it'll be prone to breakage... [03:02:27] <CIA-92> ffmpeg: conrad * r22274 /trunk/configure: [03:02:27] <CIA-92> ffmpeg: Fix clang sysroot flag [03:02:27] <CIA-92> ffmpeg: Older versions accepted both with and without an '=', but newer versions [03:02:27] <CIA-92> ffmpeg: require the '=' to be omitted [06:04:37] <CIA-92> ffmpeg: kostya * r22275 /trunk/libavcodec/ivi_common.c: [06:04:37] <CIA-92> ffmpeg: When tracking non-zero coefficients during Indeo 5 decoding, make sure [06:04:37] <CIA-92> ffmpeg: it does not ignore coefficient value = 256. [06:04:37] <CIA-92> ffmpeg: Patch by Maxim ((!min)_pole \at gmx dot/ de) [06:46:08] <superdump> i like the make output beautification [06:46:23] * kshishkov does not care much [06:54:06] <CIA-92> ffmpeg: mru * r22276 /trunk/configure: [06:54:06] <CIA-92> ffmpeg: Use -Werror=implicit only with gcc [06:54:06] <CIA-92> ffmpeg: Some other compilers turn too many warnings into errors with this flag. [06:54:58] * kshishkov wants to fix some warnings but that feeling quickly passes [08:32:42] <kshishkov> wow, FFMpeg does not compile on MacOSX/PPC [08:32:46] <kshishkov> *FFmpeg [08:33:01] <kshishkov> and FATE ignores it for two weeks too [08:35:11] <twnqx> heh [08:41:52] <kshishkov> and since I may be now the only core FFmpeg dev with such platform, tough luck for it to be fixed [08:42:09] <Yuvi> it compiles for me on 10.5 ppc? [08:42:42] <kshishkov> mine is 10.4 [08:43:35] <kshishkov> it complains about NSIG being undefined [08:53:45] <CIA-92> ffmpeg: kostya * r22277 /trunk/libavformat/rtmppkt.c: 1l trocadero: forgot reference operator on bytestream_get_be32() argument [09:14:09] <CIA-92> libswscale: stefano * r30855 /trunk/libswscale/ (yuv2rgb.c swscale_internal.h): [09:14:09] <CIA-92> libswscale: Add support to BGR444/RGB444 foreign endian output in libswscale. [09:14:09] <CIA-92> libswscale: Patch by Janusz Krzysztofik |jkrzyszt ^ tis icnet pl|. [09:14:11] <CIA-92> libswscale: stefano * r30856 /trunk/libswscale/ (utils.c swscale.c swscale_internal.h): Avoid duplication of usePal() macro. [09:26:47] <CIA-92> ffmpeg: reimar * r22278 /trunk/libavcodec/costablegen.c: [09:26:47] <CIA-92> ffmpeg: Fix --enable-hardcoded-tables compilation: the generate table files now [09:26:47] <CIA-92> ffmpeg: need to include fft.h, not dsputil.h. [11:22:12] <j-b> Compn: thanks [12:13:34] <CIA-92> ffmpeg: kostya * r22279 /trunk/libavcodec/indeo5.c: [12:13:34] <CIA-92> ffmpeg: Band quant tables should not be assigned inside band tile loop, [12:13:34] <CIA-92> ffmpeg: one time is enough. [12:13:34] <CIA-92> ffmpeg: Patch by Maxim (max_pole, gmx de) [15:41:33] <Houdini-tuxbox> Hello, make install is broken for CONFIG_SHARED with 52fb16d2c74bc608207c4f4947786757e8c8fb96 [15:41:54] <Houdini-tuxbox> install-headers doesn't exist anymore [15:41:57] <mru> what svn rev is that? [15:42:14] <Houdini-tuxbox> --- subdir.mak.orig 2010-03-07 16:34:27.000000000 +0100 [15:42:14] <Houdini-tuxbox> +++ subdir.mak 2010-03-07 16:34:44.000000000 +0100 [15:42:14] <Houdini-tuxbox> @@ -5,11 +5,12 @@ [15:42:14] <Houdini-tuxbox> LIBVERSION := $(lib$(NAME)_VERSION) [15:42:14] <Houdini-tuxbox> LIBMAJOR := $(lib$(NAME)_VERSION_MAJOR) [15:42:15] <Houdini-tuxbox> [15:42:15] <Houdini-tuxbox> +install-headers: install-lib$(NAME)-headers install-lib$(NAME)-pkgconfig [15:42:16] <Houdini-tuxbox> + [15:42:16] <Houdini-tuxbox> ifdef CONFIG_STATIC [15:42:17] <Houdini-tuxbox> all: $(SUBDIR)$(LIBNAME) [15:42:17] <Houdini-tuxbox> [15:42:18] <Houdini-tuxbox> install-libs: install-lib$(NAME)-static [15:42:18] <Houdini-tuxbox> -install-headers: install-lib$(NAME)-headers install-lib$(NAME)-pkgconfig [15:42:19] <Houdini-tuxbox> [15:42:48] <mru> what's that supposed to be? [15:42:54] <Houdini-tuxbox> hm, tag is "Split install-headers target and simplify rules" [15:43:07] <mru> which part of "svn revision" don't you understand? [15:43:33] <kshishkov> both, obviously [15:43:53] <Houdini-tuxbox> I fully understand "svn revision" [15:44:18] <mru> you just don't know how to apply that understanding to answer a simple question [15:44:45] <Houdini-tuxbox> but your web if only gives me a git view [15:45:15] <kshishkov> mru: mine is funnier - MacOSX 10.4/PPC, compiling fresh SVN libavcodec/ppc/check_altivec.c gives "/usr/include/signal.h:71: error: ‘NSIG’ undeclared here (not in a function)" [15:46:49] <Honoome> kshishkov: uh I have read that one before… [15:46:54] <Honoome> just I forgot where… [15:47:15] <CIA-92> ffmpeg: mru * r22280 /trunk/subdir.mak: 10l: fix make install with only shared libs [15:47:38] <Houdini-tuxbox> thanx [15:47:43] * mru needs to extend his buildtest script [15:48:28] <Houdini-tuxbox> it was 22243 :-) [15:49:27] <Houdini-tuxbox> have a nice sunday evening, bye [16:19:10] <twnqx> does ffmpeg's ac3 decoder support downmixing? [16:19:57] <mru> yes [16:22:28] <twnqx> cool, so if i'm requesting 2.0 from a 5.1 stream it will "do the right thing"? [16:22:32] <twnqx> nice :) [16:42:09] <roozhou> does ffmpeg's ac3 decoder support float output? [16:45:16] <kierank> you could probably make it output float if you wanted to [17:35:59] <roozhou> kierank: if i need post-processing on audio it is good to output float [17:36:40] <peloverde> roozhou, if your postprocessing code is float then it is [17:36:44] <roozhou> liba52 can output float [17:37:40] <peloverde> there is no technical reason why ffmpeg can't output float for ac3 or aac [17:38:04] <peloverde> except for nasty hacks optimizing for int16 on systems without simd float->int16 [17:39:57] <roozhou> does ffmpeg use simd float->int16? [17:40:21] <peloverde> on architectures where it is available [17:42:39] <roozhou> wmadec.c line 790: [17:42:40] <roozhou> n = s->frame_len; [17:42:40] <roozhou> incr = s->nb_channels; [17:42:40] <roozhou> for(ch = 0; ch < s->nb_channels; ch++) { [17:42:40] <roozhou> ptr = samples + ch; [17:42:41] <roozhou> iptr = s->frame_out[ch]; [17:42:41] <roozhou> for(i=0;i<n;i++) { [17:42:42] <roozhou> *ptr = av_clip_int16(lrintf(*iptr++)); [17:42:42] <roozhou> ptr += incr; [17:42:43] <roozhou> } [17:42:44] <roozhou> memmove(&s->frame_out[ch][0], &s->frame_out[ch][s->frame_len], [17:42:44] <roozhou> s->frame_len * sizeof(float)); [17:42:45] <roozhou> } [17:42:48] <roozhou> no simd at all [17:43:03] <peloverde> it's on a percodec basis [17:43:48] <peloverde> ac3dec.c:1320: s->dsp.float_to_int16_interleave(out_samples, output, 256, s->out_channels); [17:56:22] <CIA-92> ffmpeg: alexc * r22281 /trunk/libavcodec/mpeg4audio.c: [17:56:22] <CIA-92> ffmpeg: Add support for non-backwards compatible signaled parametric stereo. [17:56:22] <CIA-92> ffmpeg: This is done without breaking W6132 Annex YYYY draft MP3onMP4 which also uses AOT 29. [17:56:22] <CIA-92> ffmpeg: Samples: [17:56:22] <CIA-92> ffmpeg: http://samples.mplayerhq.hu/A-codecs/AAC/aacPlusDecoderCheckPackage_v2.1/bit... [17:56:23] <CIA-92> ffmpeg: http://samples.mplayerhq.hu/MPEG-4/mp3on4/id5_1.mp4 [18:07:12] <BBB> Vitor1001: ping [18:15:35] <BBB> Vitor1001: when you have time, could you look at http://people.gnome.org/~rbultje/graph.png and tell me what kind of math function you're thinking of when you see it? it's a 2d array in postfilter, seems like some sort of a z * (1 + log(1 + (x - ~59 / y))) for whatever values for z/y, but I couldn't really figure it out and my best tool is excel so then you know it's not gonna be much help :-p [18:16:36] <kshishkov> BBB: can you RE Indeo Audio (aka iac)? Along with Indeo4 it's the only thing missing from Intel codecs [18:16:48] <BBB> kshishkov: what type of audio is it? [18:16:51] <BBB> I'm certainly interested [18:17:00] <BBB> do you have a binary with debug symbols that runs? [18:17:05] <kshishkov> looks like MDCT from the look on it [18:17:32] <BBB> I was hoping to RE a video codec next, but I suppose a different type of audio codec is fine also :) [18:17:40] <kshishkov> no debug symbols, but iac_25.ax can be found even on MPHQ [18:18:53] <BBB> ok [18:19:37] * BBB chased vitor away :( [18:19:57] <BBB> I suppose you would have a ready-made wrapper handy for ffmpeg? [18:20:08] * BBB tries to prevent doing double work ;) [18:20:14] <kshishkov> yes, it's called MPlayer [18:20:23] <BBB> hmk, I'll write my own then [18:20:29] * BBB doesn't use mplayer [18:20:34] <kshishkov> it's standard ACM codec anyway [18:21:01] <BBB> I used objdump to convert dll to so for wmavoice [18:21:09] <BBB> then I figured out the api just by inspecting the binary [18:21:12] <BBB> made a wrapper [18:21:21] <BBB> and could link it in and run it as native code without needing any part of wine [18:21:23] <BBB> lovely [18:21:26] <BBB> gotta love objdump [18:21:42] <BBB> actually I think apple calls .so .dylib [18:21:51] * kshishkov rarely got to the point where he needed to run something because it was too problematic [18:21:58] <kshishkov> yes [18:22:07] <BBB> it's useful for ensuring bincompat [18:22:16] <BBB> or how do we call that again? [18:22:19] <BBB> bitexactness [18:22:20] <BBB> or whatever [18:23:12] <kshishkov> well, running binary decoder can be performed by different means, even gstreamer ;) [18:27:47] * BBB lets ida chew [18:28:00] <BBB> still have to finish postfilter, I think I understand about half of it now [18:28:58] <kshishkov> maybe you should just search for docs on speech codecs postfilters, I don't think they invented everything by themselves [18:31:51] <BBB> quite likely [18:32:05] <BBB> I've seen some functions copied from AMR [18:32:08] <BBB> I'll get there :) [18:34:28] * kshishkov wants to learn things about speech coding too [19:05:04] <nfl> Hi What does a negative timestamp in read_seek indicate? [19:05:53] <BBB> depends on the whence? [19:06:07] <BBB> it could e.g. mean "this much before the end of the file" [19:06:33] <kshishkov> first packets may have negative timestamps too [19:07:31] <siretart> DonDiego: hi. regarding the issue from yesterday, did you really configure with --disable-altivec? [19:08:26] <Vitor1001> BBB: can you send me the raw data? [19:08:40] <BBB> ok [19:09:46] <Vitor1001> BBB: I'll give a look [19:10:56] <peloverde> BBB, can variable names 1:1 copied in from an MPEG spec legally be used in an LGPL program? [19:11:31] <kshishkov> why not? [19:11:41] <kshishkov> it's not covered by copyrite [19:11:54] <peloverde> It wasn't my concern [19:12:22] <kshishkov> then what? [19:12:28] <peloverde> see: "[PATCH] HE-AAC v1 try 5" http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/084391.html [19:12:34] <DonDiego> siretart: no, that was what i missed.. [19:13:09] <kierank> a lot of the x264 variable names come from the spec [19:13:11] <kshishkov> peloverde: Mans is right [19:13:14] <siretart> DonDiego: okay, anyway, it seems that my patch was posted twice because of gmane hickups.. [19:13:56] <mru> I did a ppc build yesterday with --disable-altivec [19:13:59] <mru> worked fine [19:14:00] <peloverde> kshishkov, would you mind sending something to the list to that effect? [19:14:59] <kshishkov> I don't see any need for that [19:15:10] <siretart> mru: also with swscale and runtime-cpudetect? [19:17:30] <Vitor1001> First line: [19:17:42] <mru> siretart: no [19:17:43] <Vitor1001> pow(((x+6.9)/64), 0.025) [19:18:03] <mru> siretart: runtime-cpudetect is kind of pointless if you disable all the accels though [19:18:04] <Vitor1001> BBB: second line pow(((x+6.9)/64), 0.05) [19:18:26] <kshishkov> and you can guess the rest :) [19:19:31] <Vitor1001> kshishkov: exactly [19:20:53] <siretart> mru: indeed [19:22:22] <siretart> mru: I don't think it should fail though. moreover, I'd like to avoid handling --enable-runtime-cpudetect on a per-arch basis [19:22:26] <mru> while I agree it shouldn't fail to build, it's a pointless configuration [19:22:44] <siretart> well, I don't disable all accels though [19:22:46] <siretart> just altivec [19:22:59] <mru> that's the only one on ppc [19:23:08] <BBB> Vitor1001: how did you do that? [19:23:13] <siretart> oh, if you mean that with accels, right [19:23:19] * BBB wishes excel had better functions for trendline guessing [19:23:32] <Vitor1001> openoffice + "paste special with transpose" = gnuplot input [19:23:50] <Vitor1001> all crosses in x=1, looks like f(x) = x^a [19:24:03] <Vitor1001> in gnuplot [19:24:09] <Vitor1001> f(x) = ((x-a)/b)**c [19:24:15] <Vitor1001> fit f(x) 't2.csv' using 0:1 via a,b,c [19:26:50] <CIA-92> ffmpeg: mru * r22282 /trunk/tests/ (9 files in 2 dirs): regtest: place image sequence outputs in separate directories [19:26:50] <CIA-92> ffmpeg: mru * r22283 /trunk/tests/seek-regression.sh: [19:26:50] <CIA-92> ffmpeg: regtest: run seektest on lavftest output files [19:26:50] <CIA-92> ffmpeg: Somehow this got lost in the recent overhaul. [19:28:48] <BBB> that was impressive [19:28:57] * BBB goes fit this in [19:29:06] <Vitor1001> Thanks, I was lucky :) [19:29:07] <Yuvi> DonDiego: for testing I'm using BBB 1080p, and ffmpeg -f null vs. dump_video -r modified to also not do a needless memcpy [19:39:34] <DonDiego> Yuvi: http://samples.ffmpeg.org/V-codecs/Theora/ [19:39:49] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/WobblyWindowsIntro.ogg [19:39:52] <DonDiego> that one for example [19:40:04] <DonDiego> it ran faster with libtheora [19:40:53] <Yuvi> hm, my cpu's too fast for really meaningful benchmarks with that [19:41:03] <Yuvi> btw, is this on a cpu that doesn't support mmx? [19:41:06] <Yuvi> mmx2 [19:41:18] <mru> Yuvi: benchmark on a beagle :-) [19:41:24] <DonDiego> i used 'time mplayer -benchmark <file>' 'time mplayer -demuxer lavf -benchmark <file>' [19:41:26] <mru> seriously, you should do that [19:41:49] <DonDiego> Yuvi: yes, my K6-III does not have mmx2, just mmx and 3dnow/3dnowext [19:42:05] <Yuvi> mru: good idea [19:42:23] <DonDiego> does libtheora run on the beagle? [19:42:24] <Yuvi> DonDiego: then another problem is that we only have a mmx2 loop filter, wheras libtheora has an mmx one [19:42:34] <DonDiego> oh, ok :( [19:43:18] <DonDiego> Yuvi: sorry if i keep asking you what feels like every half hour, but what's the status of your theora and ogg work now? [19:43:19] <Yuvi> DonDiego: yeah, but it has no arm optimizations [19:43:39] <DonDiego> oh, let's publish benchmarks then ;) [19:43:47] <DonDiego> arm is an up and coming platform... [19:44:00] <Yuvi> I keep coming up with more special cases with seek that need handling [19:44:35] <Yuvi> since for just about everything, one or two codecs do things differently [19:44:42] <Kovensky> does anyone know of a tool that reads a file or stdin and puts the contents on the X clipboard? [19:45:12] <DonDiego> Yuvi: ogg seeking? [19:45:18] <peloverde> Kovensky, xclip? [19:45:19] <Yuvi> DonDiego: yep [19:45:26] <DonDiego> :( [19:45:31] <DonDiego> ogg is a bitch.. [19:46:03] <DonDiego> Yuvi: you should mention your experience as an answer to mans' blog post about ogg.. [19:46:19] <DonDiego> the xiph people honestly believe it's not so bad... [19:47:16] <DonDiego> Yuvi: and the theora optimizations? [19:48:30] <Yuvi> haven't gotten back to working on them, Dark_Shikari found some segfaults in the current code [19:49:49] <CIA-92> ffmpeg: conrad * r22284 /trunk/libavformat/ (rtsp.c os_support.c network.h): Localize the #define _SVID_SOURCE needed for inet_aton() to os_support.c [19:49:50] <CIA-92> ffmpeg: conrad * r22285 /trunk/libavformat/os_support.c: inet_aton needs _DARWIN_C_SOURCE on OS X [19:50:13] <Yuvi> 3dnow had an equivlant to pavgb right? [19:50:43] <Dark_Shikari> yes [19:50:44] <Dark_Shikari> pavgusb [19:50:47] <DonDiego> Yuvi: so you switched priorities to fixing those segfaults? [19:50:50] <Kovensky> <peloverde> Kovensky, xclip? <-- perfect :3 [19:50:56] <Kovensky> now, to learn el... [19:51:20] <Dark_Shikari> well IMO before 0.6 we should both fix the segfaults _and_ get optimizations in [19:51:24] <Yuvi> good, then for k6-III at least it won't be too hard to have a good loop filter [19:51:30] <Dark_Shikari> because "ready for html5" means "it doesn't crash" too [19:51:45] <CIA-92> ffmpeg: mru * r22286 /trunk/tests/ (17 files in 2 dirs): [19:51:45] <CIA-92> ffmpeg: regtest: run seektest on image sequences [19:51:45] <CIA-92> ffmpeg: Seeking on image sequences doesn't actually work, so this [19:51:45] <CIA-92> ffmpeg: test isn't very useful until that capability is added. [19:51:46] <Dark_Shikari> and we can explicitly brag that we did extra fuzz-testing to fix crash bugs =p [19:51:51] <Yuvi> DonDiego: yeah, putting segfaults against the web isn't a good idea ;) [19:52:18] <DonDiego> yes, i absolutely agree [19:52:32] <DonDiego> i'm just looking out for stuff i need to keep on the radar for 0.6 [19:52:34] <peloverde> Dark_Shikari, one thing I think about sometimes is illegal reads [19:52:38] <DonDiego> astrange: what about ffmpeg-mt? [19:52:39] <peloverde> should we be worried about them [19:52:43] <Dark_Shikari> peloverde: yes [19:52:45] <Dark_Shikari> DOS is bad [19:53:13] <mru> also what segfaults on one system might do something much nastier on another [19:53:17] <DonDiego> peloverde: that reminds me to ask you what i always ask as well (it would not be fair to just annoy yuvi): [19:53:22] <DonDiego> what about sbr? [19:53:23] <DonDiego> :) [19:53:25] <peloverde> Dark_Shikari, then we need more input buffer padding [19:53:31] <Dark_Shikari> you can sell Quicktime DOSs for $5k+ on _legitimate_ channels [19:53:49] <peloverde> DonDiego, we need a second legal opinion about variable names [19:53:50] <DonDiego> Dark_Shikari: ? [19:54:02] <Dark_Shikari> DonDiego: hence DOSs are important enough that people pay for said exploits... [19:54:08] <Dark_Shikari> any exploit someone would pay for is something we should fix [19:54:29] <peloverde> Dark_Shikari, if we want to stop illegal reads then we should look at the google patches or be willing to up input buffer padding size [19:54:44] <Dark_Shikari> peloverde: Or we could simply do what x264 does [19:54:47] <peloverde> Dark_Shikari, why not just sell the exploits ourselves [19:54:54] <Dark_Shikari> peloverde: because it's in our interest to fix them [19:54:54] <peloverde> :) [19:55:15] <peloverde> anyway what does x264 do? [19:55:45] <Dark_Shikari> at each macroblock, it checks to see that the amount of buffer left is greater than or equal to the estimated maximum size of an MB (worst-case) [19:55:49] <Dark_Shikari> this avoids massive buffer padding [19:55:54] <Dark_Shikari> This can be applied to any set of syntax elements [19:56:00] <peloverde> I did that for AAC [19:56:03] <Dark_Shikari> calculate the maximum size, round up a lot, check buffer against that _before_ decoding that set [19:56:06] <Dark_Shikari> thus you don't have to check on every read [19:56:07] <peloverde> but I still need more padding [19:56:18] <peloverde> I need 36 bytes per frame [19:56:24] <Dark_Shikari> that's "more"? [19:56:28] <peloverde> yes [19:56:29] <Dark_Shikari> I would have assumed we already had a megabyte or two [19:56:48] <peloverde> FF_INPUT_BUFFER_PADDING_SIZE 8 [19:56:55] <Dark_Shikari> LOL [19:57:03] <Dark_Shikari> this some kind of joke? [19:57:12] <peloverde> and some of that is for get_bits [19:57:22] <merbanan> how about we add a CONFIG_SMALL define ? [19:57:22] <peloverde> so I really need to increase it to 44 [19:57:43] <Dark_Shikari> 44? more like 44,000 [19:57:46] <mru> the existing padding is only to allow get_bits loading chunks of 8 bytes [19:57:54] <BBB> Vitor1001: ok, all math is done now, I'll work on code comments and then hopefully post & commit [19:57:57] <Dark_Shikari> yeah, it doesn't stop overreads [19:58:02] <BBB> (plus all variables need useful names) [19:58:03] <Dark_Shikari> mru: we could add a branch to get_bits ;) [19:58:07] <peloverde> It stops small overeads [19:58:23] <peloverde> I do one bit overeads for w6132 and that seems to work fine [19:58:42] <Dark_Shikari> that's not tolerable [19:58:46] <Dark_Shikari> anything that makes valgrind complain is bad [19:58:49] <Dark_Shikari> _anything_ [19:59:00] <mru> reading into the padding is of course ok [19:59:00] <peloverde> Dark_Shikari, valgrind doesn't complain about the 1 bit overeads [19:59:01] <merbanan> even bugs in valgrind ? [19:59:06] <Dark_Shikari> merbanan: ok, true [19:59:09] <Dark_Shikari> but those are not that common. [19:59:12] <Dark_Shikari> mru: obviously. [19:59:12] <mru> bugs in valgrind are bad too [19:59:29] <Dark_Shikari> the only valgrind bugs I know of that affect this sort of thing are the simd data tracking bugs [19:59:32] <Dark_Shikari> in pmaddwd, etc [19:59:34] <Dark_Shikari> er, pmaddusbw [19:59:41] <Dark_Shikari> but they're trivial to shut up [19:59:49] <Dark_Shikari> you just zero on malloc [19:59:51] <peloverde> anyway until someone is willing to increase FF_INPUT_BUFFER_PADDING_SIZE to something real, trying to stop overeads is insane [20:00:32] <Dark_Shikari> then we do it [20:02:33] <Yuvi> is it worth worrying about CPUs without mmx2 or 3dnow? [20:02:55] <DonDiego> without any or both of them? [20:02:56] <mru> I think we can increase the padding to, say, 64 without much debate [20:03:02] <Yuvi> both [20:03:04] <peloverde> Yuvi, I wouldn't bother but i'm sure there are people who care [20:03:41] <DonDiego> i fear i'm about the only person with such a vintage machine, but i do care :) [20:03:57] <Yuvi> well, it's easy enough to fix for you :) [20:04:36] <Dark_Shikari> Yuvi: I say no [20:04:46] <Dark_Shikari> then again I believe we shouldn't care about cpus without sse [20:05:51] <DonDiego> Yuvi: would it be worthwhile to port the libtheora loopfilter? [20:06:55] <Yuvi> maybe, I can post a patch and see what michael says [20:07:00] <Dark_Shikari> isn't our current version pretty good? [20:07:12] <Yuvi> yeah, but requires pavgb [20:07:56] <Yuvi> (the optimal mmx loop filter would unpack to 16-bits instead, so it's mostly different code) [20:08:06] <Dark_Shikari> are you sure it would? [20:08:37] <Yuvi> it should be faster than emulating pavgb in addition to the munging pavgb needs [20:08:46] <Dark_Shikari> nope, doesn't seem so [20:09:16] <Dark_Shikari> at least maybe not [20:09:39] <Yuvi> well, if it's questionable, it's easier to emulate pavgb unless someone with such a cpu cares enough to benchmark [20:09:39] <Dark_Shikari> pavgb in coreavc is pxor/por/pand pb_254/psrlq 1/psubb [20:09:41] <Yuvi> so I'll do that [20:09:51] <Dark_Shikari> I trust the original coreavc author on this [20:09:55] <Dark_Shikari> but he might be wrong. [20:13:52] <Dark_Shikari> Yuvi: http://pastebin.org/103997 [20:15:23] <peloverde> care to use a pastebin variant that doesn't have talking ads? [20:16:13] <Dark_Shikari> what ads? [20:16:35] <mru> pastebin.ca seems clean, at least with adblock [20:16:43] <Dark_Shikari> I prefer pastebin.org's interface [20:16:46] <Dark_Shikari> and it doesn't have ads either [20:16:58] <mru> w/o adblock has the most obnoxious ads ever [20:17:03] <mru> full-screen popups [20:17:17] <Dark_Shikari> wait, people still exist that browse without adblock? [20:17:32] <mru> as surprising as it sounds, yes [20:17:53] <Yuvi> mine didn't have the offending domain blocked initially [20:17:58] <Yuvi> *.adonion.com [20:22:10] <peloverde> I find most adblockers to aggressive, so I just avoid sites that use obnoxious ads [20:22:26] <Vitor1001> BBB: are you sure that the code that does RDFT -> set real part to zero -> IRDFT is correct? [20:22:47] <BBB> Vitor1001: it gives the same output as binary [20:22:57] <BBB> Vitor1001: but I admit it looks a little odd [20:23:06] <BBB> and I have no idea what it does [20:23:10] <Vitor1001> Weird... I'll try to understand it... [20:25:26] <BBB> I'm working on simpler parts of the code ATM, the tilt correction appears similar to AMR-NB [20:25:36] <BBB> I can probably merge the two into 1 shared function [20:25:54] <Vitor1001> Nice, shared code is great, but maybe it is speed critical to AMR... [20:26:38] <BBB> to be honest, doesn't look speed-critical [20:26:41] <BBB> but I'll measure [20:26:46] <BBB> is amrnbdec slow? [20:27:16] <Vitor1001> I don't know, never benchmarked it against opencore [20:27:43] <Vitor1001> But since it is float-based, it should be faster in desktops [20:34:16] <BBB> in ~3yrs, it'll be faster&better on smartphones also [20:34:24] <BBB> moore's law probably still applies there [20:34:55] <Vitor1001> I think for smartphones its already the case [20:35:14] <BBB> we'll see [21:08:13] <CIA-92> ffmpeg: alexc * r22287 /trunk/libavcodec/aac.c: AAC: Add a new line after the TNS error message. [21:10:07] <Kovensky> <Dark_Shikari> I prefer pastebin.org's interface <-- I don't see any major difference other than colors [21:10:19] <Kovensky> also, pastebin.ca doesn't corrupt your diffs and UTF-8s [21:10:28] <ohsix> gist ftw [21:10:37] <mru> I hate the @@ munging on .com/.org [21:10:53] <superdump> mmm [21:11:16] <Kovensky> the only thing I have against pastebin.ca is that the hilighters give comments less priority than keywords / string delimiters [21:11:30] <Dark_Shikari> Kovensky: um, have you seen pastebin.com? [21:11:32] <Dark_Shikari> it's a disaster [21:11:35] <Kovensky> so you get random hilighting inside comments [21:11:36] <Dark_Shikari> it was bought out [21:11:38] <Kovensky> Dark_Shikari: pastebin.com IS a disaster [21:11:46] <Dark_Shikari> pastebin.ca doesn't show line numbers correctly [21:11:48] <Kovensky> I'm talking in pastebin.ca's defense :P [21:11:51] <Dark_Shikari> they're covered up by the interface [21:11:56] <Kovensky> o_O [21:12:03] <mru> oh, .org is the old .com [21:12:06] <Dark_Shikari> mru: exactly. [21:12:13] <Kovensky> http://pastebin.ca/1827586 <-- they look correctly on this paste [21:12:19] <Kovensky> correct* [21:13:03] <mru> I have scripts to post on .ca [21:13:27] <mru> git diff | pastediff [21:13:51] <mru> even copies the url as X selection [21:14:22] <Dark_Shikari> Kovensky: http://i47.tinypic.com/dcrj1z.png [21:14:25] <Dark_Shikari> "correct" [21:14:32] <Dark_Shikari> fail css is fail [21:14:52] <Kovensky> Dark_Shikari: it's on your side then [21:14:56] <Kovensky> which browser [21:15:06] <Dark_Shikari> firefox [21:15:38] <Dark_Shikari> the problem is that the CSS is badly written and assumes a particular font size [21:16:01] <Dark_Shikari> but, in the interests of not losing my vision before I'm 30, I use a larger font [21:16:29] <Kovensky> oic [21:16:44] <Kovensky> Dark_Shikari: submit a bug report? :P [21:17:13] <Kovensky> oh great, the bug report link is 404 =p [21:17:37] <CIA-92> ffmpeg: alexc * r22288 /trunk/libavcodec/avcodec.h: [21:17:37] <CIA-92> ffmpeg: Increase FF_INPUT_BUFFER_PADDING_SIZE to 64. [21:17:37] <CIA-92> ffmpeg: The purpose of this is to give decoders a reasonable amount of buffer to work [21:17:37] <CIA-92> ffmpeg: with before needing to check for overreads. [21:17:46] <peloverde> ^Let's see if I get flamed [21:18:03] <superdump> :) [21:18:11] <Yuvi> (isn't that an API change?) [21:18:17] <Yuvi> ABI I guess [21:18:59] <peloverde> Couldn't you have said something about that when we were discussing it five minutes ago? :) [21:20:07] <peloverde> So does that mean I need to revert? [21:20:16] <mru> no, leave it [21:20:18] <mru> we need it [21:20:21] <Yuvi> yeah [21:20:22] <mru> no point pushing it off [21:20:25] <Kovensky> bump minor? [21:20:29] <Yuvi> going to happen sooner or later [21:20:33] <Dark_Shikari> I would go for more than 64 [21:20:39] <Dark_Shikari> we need enough to cover things like "one dct block of coeffs" [21:20:41] <Dark_Shikari> in h264 [21:20:52] <Dark_Shikari> to avoid checking per-read [21:21:03] <peloverde> I went with 64 because it fixes AAC and mru suggested 64 would be ok [21:21:27] <peloverde> I didn't submit a patch because I didn't want to waste weeks bikeshedding the size [21:21:39] <peloverde> If you have a legitamte reason to increase it, increase it [21:21:49] <Dark_Shikari> k [21:22:05] <mru> if we were talking about kilobytes there could be valid objections [21:22:10] <superdump> so the revolt begins...? :) [21:22:16] <Dark_Shikari> IMO we should try to go through the codecs and certify them as "not a problem" [21:22:19] <Dark_Shikari> wrt buffer overreads [21:22:24] <peloverde> yes [21:22:27] <Dark_Shikari> and possibly raise the size. [21:22:28] <mru> ultimately we may need to have per-codec padding [21:22:35] <Dark_Shikari> mru: I agree [21:22:37] <Dark_Shikari> it should be part of the API [21:22:41] <peloverde> Indeed [21:22:42] <superdump> that would make sense i guess [21:22:43] <Dark_Shikari> that each codec has an amount of padding it asks for [21:22:49] <Dark_Shikari> a codec property [21:23:01] <Dark_Shikari> for h264, if we wanted to check per-MB, it would be a few kilobytes [21:23:05] <Yuvi> that increases the dependence of lavf on lavc though [21:23:22] <mru> lavf is already hopelessly entangled in lavc [21:23:30] * superdump sighs [21:23:44] <mru> but this change wouldn't need to make it worse [21:24:06] <mru> add a field somewhere so the calling app can request whatever padding it wants from lavf [21:25:04] <peloverde> Issue 1295 closed [21:28:56] <peloverde> superdump, do you have any thoughts on this: http://github.com/aconverse/ffmpeg-heaac/commit/4f3345b375aa5c73918330e47839... [21:30:54] <superdump> let's see... [21:33:33] <superdump> well, the logical operator doesn't display correctly in my pdf [21:33:41] <superdump> it's just a square [21:33:45] <superdump> so i can't tell [21:34:49] <superdump> i'd say unless you find any files that have numpatches 6 or you can prove that it's a bug in the spec, stick with the spec and go with 5 i guess [21:34:54] <mru> peloverde: does this look right? http://pastebin.ca/1827665 [21:35:08] <peloverde> Oh shit, it is " <=" in the .doc [21:35:12] <superdump> aha [21:35:38] <peloverde> mru, yes [21:36:19] <superdump> peloverde: is it <= 5 in the doc and < 6 in the coding tech code and > 5 in our code? :) [21:38:37] <peloverde> now I'm even more confused [21:38:57] <superdump> why? [21:39:34] <peloverde> nevermind [21:39:55] <peloverde> for a minute I thought that 6 was allowed by the spec [21:40:57] <superdump> :) [21:41:38] <peloverde> anyway the files imply CT had an encoder outputting 6 patches, which means we need to support it [21:41:40] <DonDiego> astrange: what's the status of ffmpeg-mt? [21:42:18] <peloverde> I wonder If I should forward this to dolby [21:42:31] <superdump> peloverde: hmm, might be an idea i guess [21:42:50] <peloverde> they took down the check package though [21:43:02] <peloverde> CT's website had a ton of useful stuff that dolby just killed [21:44:17] <peloverde> also can a fate test just look at sample rate and a number of channels? because I want to add tests for HE-AAC signaling [21:45:44] <mru> ffprobe tests [21:48:01] <peloverde> presumably, but that would also cover metadata [21:48:33] <CIA-92> ffmpeg: mru * r22289 /trunk/libavcodec/fft-test.c: Update include directives in fft-test.c [21:48:33] <CIA-92> ffmpeg: mru * r22290 /trunk/ (6 files in 2 dirs): Give RDFT types more meaningful names [21:48:43] <mru> we could teach ffprobe to not print metadata [21:49:09] <peloverde> maybe a flag to suppress metadata? [21:49:32] <mru> exactly [21:50:00] <mru> what harm does the metadata printout do anyway? [21:50:49] <peloverde> if someone adds 3gpp asset information it will break the test [21:57:34] <CIA-92> ffmpeg: mru * r22291 /trunk/ (6 files in 2 dirs): Create a public API for FFT family of functions [21:57:34] <CIA-92> ffmpeg: mru * r22292 /trunk/ffplay.c: ffplay: use public fft interface [22:19:22] <CIA-92> ffmpeg: mru * r22293 /trunk/ffserver.c: [22:19:22] <CIA-92> ffmpeg: ffserver: do not use intreadwrite.h [22:19:22] <CIA-92> ffmpeg: intreadwrite.h is not part of the public API and should thus [22:19:22] <CIA-92> ffmpeg: not be used by the ff* applications. [22:19:22] <CIA-92> ffmpeg: mru * r22294 /trunk/ (common.mak subdir.mak): Define HAVE_AV_CONFIG_H only when building libraries [22:19:23] <CIA-92> ffmpeg: mru * r22295 /trunk/ (ffplay.c ffserver.c ffprobe.c cmdutils.c ffmpeg.c): Remove hacks not required since HAVE_AV_CONFIG_H was unset for the apps [22:35:45] <saste> hurrah for mans! \o/ [22:35:55] <saste> FFmpeg code never has been so sweet.. [22:36:23] <saste> but now there are some suspicious warnings in ffserver.c [22:36:34] <saste> ffserver.c: In function ‘http_parse_request’: ffserver.c:1341: warning: implicit declaration of function ‘av_match_ext’ [22:36:35] <mru> I'm looking at those right now [22:37:03] <Yuvi> oh, that's a cool trick, pavgb(a,~b) is (a-b)>>1 [22:37:09] <Yuvi> didn't think of that before [22:38:00] * mru looks at VHSUB [22:38:18] <Yuvi> of course neon has the more useful instructions :P [22:43:01] <CIA-92> ffmpeg: stefano * r22296 /trunk/libavformat/ (utils.c internal.h): (log message trimmed) [22:43:02] <CIA-92> ffmpeg: Move the probe loop from av_open_input_file() into its own method [22:43:02] <CIA-92> ffmpeg: av_probe_input_buffer() so that it can be reused. Here are a few [22:43:02] <CIA-92> ffmpeg: differences to the original way things were probed: [22:43:02] <CIA-92> ffmpeg: - maximum probe buffer size can be specified as a parameter. [22:43:02] <CIA-92> ffmpeg: - offset within the stream to probe from can be specified as a parameter. [22:43:03] <CIA-92> ffmpeg: - instead of seeking back to the start each time a probe fails, stream [23:11:14] <CIA-92> ffmpeg: cehoyos * r22297 /trunk/libavformat/utils.c: [23:11:14] <CIA-92> ffmpeg: Fix pts->dts conversion init for non-zero initial value for pts. [23:11:14] <CIA-92> ffmpeg: Patch by Daniel Kristjansson, danielk cuymedia net [23:11:24] <superdump> when did concat get merged? [23:11:46] <superdump> and what's the syntax? (i don't see anything in the help output) [23:13:58] <janneg> superdump: 21666 [23:14:06] <superdump> thanks [23:14:21] <janneg> git sha1 a4b47b0b864e3 [23:17:06] <superdump> looks like -i concat:/path/to/file1|/path/to/file2... [23:18:47] <janneg> doesn't work for me [23:47:31] <CIA-92> ffmpeg: alexc * r22298 /trunk/libavcodec/aac.c: AAC: Set codec parameters in the first frame rather than in .init() [23:53:20] <CIA-92> ffmpeg: alexc * r22299 /trunk/libavcodec/aac.c: 10l: AAC: Set multiplier to 0. [23:54:35] <CIA-92> ffmpeg: stefano * r22300 /trunk/libavfilter/defaults.c: [23:54:35] <CIA-92> ffmpeg: Make avfilter_default_start_frame() correctly pass the aspect ratio [23:54:35] <CIA-92> ffmpeg: information to the next filter. [23:55:25] <saste> janneg: how is not working? [23:56:31] <janneg> saste: concat:file1.avi|file2.avi: no such file or directory [23:58:56] <saste> which is the complete command?