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

[irc at mansr.com]

[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/bitstreams/File7.3gp
[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/4f3345b375aa5c73918330e478396c6ce682f3d0
[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?