[00:40:36] <Honoome> … michael now replies in rebuses? did I miss his replies in Haiku before? [00:57:12] <Dark_Shikari> http://i45.tinypic.com/w7d3ch.jpg [00:57:18] <Dark_Shikari> http://i46.tinypic.com/2v1uikh.jpg [00:57:52] <Dark_Shikari> I now have my x264 shirt. [00:57:58] <Honoome> haha :) [00:58:05] <Honoome> for a moment I was expecting Michael's haiku :P [00:58:14] <Dark_Shikari> lol [01:00:29] <beandog> Dark_Shikari: very nice [01:02:45] * Honoome is tempted to make one with ffmpeg, xine, lscube and gentoo logos for the next fosdem [01:02:59] <Honoome> it was difficult to find the rest of the guys not knowing anybody's face :P [01:04:58] <peloverde> I was lucky that I overheard mru, KotH, and siretart talking about FFmpeg at delirium [01:07:52] <Honoome> I was lucky I was with Luca ;) [01:36:29] <Dark_Shikari> btw, if you want a shirt [01:36:31] <Dark_Shikari> I recommend spreadshirt [01:36:36] <Dark_Shikari> 1) upload pngs with transparency (high res) [01:36:37] <Dark_Shikari> 2) ??? [01:36:38] <Dark_Shikari> 3) profit [01:36:46] <Dark_Shikari> cafepress doesn't let you print on the back of a black t-shirt. [01:37:35] <Honoome> Dark_Shikari: myself I have a supplier already ;) -- a customer of mine does prints, so I don't even have to pay, beside the shirt itself [01:38:14] <Dark_Shikari> ah [01:38:57] <peloverde> I've thought about doing FFmpeg stickers [03:12:42] <Dark_Shikari> http://pastebin.com/f6dd893ef <--this sort of thing good for porting the x264 presets to ffmpeg? [03:29:02] <mfg> I have a question about AVMetadataConv: does it actually do anything for a demuxer? is the idea that the application use it to translate the metadata tags into something useable (with av_metadata_conv), because otherwise, it doesn't do anything on its own (as far as I can tell). TIA! [05:10:14] <ramiro> great. I took apart the only windows notebook I had left and there are broken pieces scattered all around my room. [05:10:38] <ramiro> any suggestion for a cheap netbook I could acquire? (with windows) [07:58:57] <elenril> morning [08:06:40] <kshishkov> god morgon [08:12:37] <Yuvi> astrange: how much speedup did you get from http://github.com/astrange/ffmpeg/commit/cfd4b6027476aca8bfc25e5f1ee95accf52... ? [08:13:01] <Dark_Shikari> wow, "not much speedup"? [08:13:05] <Dark_Shikari> I guess because most of the time is in bitstream decoding? [08:13:23] <Yuvi> yeah, and that isn't included in what can be multithreaded within a frame [08:13:45] <astrange> yeah, i hardly measured any. that was before fast fragment mapping [08:13:52] <kshishkov> 1.73 cycles speedup ? [08:14:00] <astrange> so it still spent pretty much all the time in bitstream decoding [08:14:01] <Yuvi> I'm wondering because the next patch gives a speedup of 12-20% but makes that impossible to do [08:14:13] <Dark_Shikari> Yuvi: that's fine imo [08:14:16] <Dark_Shikari> any good threading will be frame based [08:14:39] <astrange> yeah, whatever you do won't break frame threading [08:14:57] <astrange> actually draw_horiz_band code can be combined with that [08:15:11] <astrange> since they both run when the smallest possible # of rows are finished [08:16:08] <astrange> let me try it again [08:17:02] <astrange> what's a difficult theora clip? i only have small ones [08:17:26] <Yuvi> 1080p BBB is decent [08:17:46] <Yuvi> http://mirror.bigbuckbunny.de/peach/bigbuckbunny_movies/big_buck_bunny_1080p... [08:18:57] <astrange> that's.... big [08:19:18] <kshishkov> someone should name next opensource movie something like "Medium Robust Unicorn" to cause further confusion on this channel [08:19:46] <Yuvi> yeah... and it's slightly worse quality than that 1.2 mbit x264 BBB [09:00:02] <pentanol> hi mru [09:01:32] <pentanol> or perhaps someone here may help me [09:02:16] <pentanol> I want make ffpmeg for rtp-proxy for arm [09:02:22] <pentanol> I did it ./configure --prefix=/usr/local/ffmpeg-dev-cris --arch=arm --enable-cross-compile --cross-prefix=cris- --disable-doc --sysinclude=/usr/local/cris/cris-axis-linux-gnu/include [09:02:39] <pentanol> but there.. Enabled protocols: [09:02:39] <pentanol> file pipe [09:03:05] <pentanol> I can't obtain tcp, udp, rtp... so on [09:03:31] <kshishkov> obviously your compiler lacks networking headers [09:03:37] <kshishkov> look at config.log [09:05:38] <pentanol> perhaps, it looks like --sysinclude=/usr/local/cris/cris-axis-linux-gnu/include won't work [09:06:06] <pentanol> but there /usr/local/cris/cris-axis-linux-gnu/include/net/ [09:06:26] <kshishkov> whatever, look at logs [09:06:49] <kshishkov> and probably ask at #ffmpeg, this has nothing to do with FFmpeg development [09:21:24] <astrange> int current_edge_emu_buffer = s->edge_emu_buffer; oops [09:21:36] <pentanol> #ffmpeg there no one :( [09:21:47] <pentanol> hm, why if I put it... --sysinclude=/usr/local/cris/cris-axis-linux-gnu/include/ it said netinet/in.h: No such file or directory [09:22:27] <pentanol> it's header exist there... /usr/local/cris/cris-axis-linux-gnu/include/netinet/in.h [09:23:49] <kshishkov> dunno, must be some compiler options you don't pass, like --basedir [09:23:58] * kshishkov does not know about it a thing [09:31:59] <Yuvi> Dark_Shikari: http://pastebin.com/m89f3ebe you mentioned this was uncommented, is that clearer? [09:32:01] <pentanol> kshishkov looks like it broken in current, with 0.5 it works [09:32:52] <astrange> Yuvi: 15.97s -> 14.24s [09:33:12] <astrange> but the crcs don't match so i must have rebased it wrong (it looks visually correct) [09:35:56] <Yuvi> so a little less than what I'm getting from not sorting the coeffs until right before idct [09:37:57] <astrange> ffmpeg-mt (r21620) 1: 17.19s 2: 12.036s [09:39:02] <Yuvi> different vp3.c bases? [09:40:46] <astrange> yeah, i haven't merged mainline since before the loop filter changes [09:45:06] <Yuvi> woah, 28% faster on BBB 1080p on my g4 [10:20:35] <Dark_Shikari> Yuvi: LOOKS GOOD [10:20:50] <Dark_Shikari> er, oops, caps [10:56:05] <siretart> Dark_Shikari: I botched the last upload, it wasn't really r1442 after all. I've now redone the package properly, and r1442 does build on armel just fine [10:57:03] <Dark_Shikari> lol [10:57:06] <Dark_Shikari> oops :) [10:58:27] <siretart> I've also redone version.sh in the package, it now identifies (x264 --version) itself as: 'x264 0.85.1442 Ubuntu_2:0.85.1442+git781d30-1' [10:58:55] <Dark_Shikari> isn't that a bit redundant? [10:59:03] <siretart> a bit, yes [11:00:07] <siretart> I wasn't sure what other tools might parse the original information, and this was the least annoying I could come up after 20min thinking on it [11:01:32] <Dark_Shikari> I guess you have 80 characters to work with [11:01:34] <Dark_Shikari> so it's not really a big deal [11:23:38] <CIA-90> ffmpeg: vitor * r21916 /trunk/libavformat/mpc.c: [11:23:38] <CIA-90> ffmpeg: Do not leave uninitialized data in the packet in MPC demuxer. Should allow for [11:23:38] <CIA-90> ffmpeg: adding a demuxer test to FATE. [11:36:31] <lool> siretart: w00t [11:36:38] <lool> Dark_Shikari: Heya, around? [11:36:52] <lool> Dark_Shikari: siretart suggested I could probably discuss this directly on IRC with you [11:37:11] <lool> Dark_Shikari: By default, x264 turns on NEON support if one doesn't set any fpu/cpu CFLAGS [11:37:31] <astrange> -> #x264dev if you're going to have too many long conversations [11:37:35] <lool> Dark_Shikari: But Debian/Ubuntu's armel architecture doesn't expect NEON [11:37:42] <lool> astrange: Ok [11:37:52] <lool> astrange: Not many, but perhaps one long [12:23:12] <CIA-90> ffmpeg: cehoyos * r21917 /trunk/libavutil/internal.h: Gcc attribute may_alias is not supported (or silently ignored) by all supported compilers. [12:33:21] <CIA-90> ffmpeg: stefang * r21918 /trunk/libavcodec/aactab.c: [12:33:21] <CIA-90> ffmpeg: remove tables of codebook vector values which are contained in [12:33:21] <CIA-90> ffmpeg: another table [13:13:39] <pentanol> static void put_pixels_clamped_c(const DCTELEM *block, uint8_t *restrict pixels,int line_size) [13:13:53] <pentanol> looks like a bug? restrict [13:14:04] <kshishkov> looks like an attribute [13:14:24] <pentanol> my gcc give an error [13:14:46] <kshishkov> it's not C99-compliant then [13:15:18] <mru> restrict is c99 [13:15:30] <kshishkov> pass -Drestrict= and it should be fine [13:15:34] <mru> supported in gcc at least since 2.95 [13:15:40] <kshishkov> (or upgrade to this century compiler) [13:15:43] <mru> and configure probes for it [13:20:22] <CIA-90> ffmpeg: mru * r21919 /trunk/Makefile: Delete all test related files in testclean rule [13:20:23] <CIA-90> ffmpeg: mru * r21920 /trunk/Makefile: Delete avconfig.h on distclean [13:27:02] <pentanol> hm, I delete from config.mak -std=c99 and -D__ISO.... , anyway [13:27:26] <pentanol> that is exact? CFLAGS="-Drestrict=" ? [13:27:48] <pentanol> or equal something? [13:28:20] <mru> DO NOT EDIT config.mak [13:28:32] <mru> that's asking for trouble [13:28:47] <mru> what compiler are you using? [13:30:00] <pentanol> cris-gcc [13:30:05] <pentanol> arm for axis [13:30:38] <pentanol> gcc version 3.2.1 Axis release R64/1.64 [13:30:56] <mru> arm or cris? I'm confused... [13:32:08] <kshishkov> why? It sounds valid as MIPS III for AVR [13:32:18] <mru> and why the hell are you running ffmpeg on a cris? [13:34:07] <mru> hmm, they're not even selling them anymore [13:34:40] <pentanol> actually I need convert rtsp to rtmp [13:35:59] <pentanol> --arch= no even know about cirs [13:36:04] <pentanol> cris [13:40:47] <pentanol> with live555 we've this one config.cris-axis-linux-gnu, with ffmpeg hm... [13:44:11] <mru> why don't you use a modern gcc version? [13:45:28] <_av500_> 2.9.5 ftw [13:52:09] <pentanol> you mean configure it by default and then make ARCH=CRIS ? [13:52:19] <mru> no [13:52:29] <mru> I mean get a modern gcc version [13:54:34] <pentanol> I've gcc version 4.3.2, but there nothing about cris in configure [13:54:48] <mru> just pass --arch=cris anyway [13:54:54] <mru> it will print a warning and continue [13:55:17] <mru> and why did you say you have gcc 3.2.1 a while ago? [13:58:58] <pentanol> it was about cris [13:59:04] <pentanol> anyway dsputil.h:449: error: expected ';', ',' or ')' before 'v1' [13:59:10] <mru> you're more confused than I am [13:59:17] <mru> why don't you get a modern gcc FOR CRIS? [13:59:38] <pentanol> because you said [13:59:51] <pentanol> agh doN't [14:00:06] <pentanol> 4.3.2 looks like modern? [14:00:13] <mru> but you said you have 3.2.1 [14:00:24] <pentanol> yes, it's latest [14:00:29] <mru> no, 4.4.3 is latest [14:00:39] <mru> go see at gcc.gnu.org for yourself [14:01:14] <pentanol> with 4.3.2 it wouldn't work? [14:01:27] <mru> 4.3.2 should be fine [14:01:35] <mru> but apparently 3.2.1 isn't working [14:02:01] <pentanol> dsputil.h:449: error: expected ';', ',' or ')' before 'v1' it was with 4.3.2 [14:02:12] <pentanol> gcc -DHAVE_AV_CONFIG_H -I. -I"/lib/init/rw/ffmpeg" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/usr/local/cris/cris-axis-linux-gnu/sys-include/ -L/usr/local/cris/cris-axis-linux-gnu/lib/ -MMD -MF libavdevice/v4l.d -MT libavdevice/v4l.o -c -o libavdevice/v4l.o libavdevice/v4l.c [14:02:51] <mru> SO WHY DID YOU TALK ABOUT 3.2.1? [14:03:17] <pentanol> I use it [14:03:25] <mru> gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhh [14:03:28] * kshishkov ansiktehandflatar [14:03:47] <mru> I'll footarse him if he continues [14:03:54] <pentanol> libavcodec/dsputil.h:449: parse error before "v1" whis what I 've got with 3.2.1 [14:04:04] <mru> so don't bloody use that broken version then [14:05:10] <pentanol> it's cleaned find ./ -name "*\.o" rm -rf {} \; [14:05:22] <pentanol> -exec* [14:05:24] <mru> ????????????? [14:05:43] <pentanol> what you mean about broken version [14:07:16] <kshishkov> only a couple of shrimps [14:07:31] <mru> broken: something that doesn't work [14:08:17] <pentanol> which would works? [14:08:53] <mru> 4.3 or 4.4 I'd guess [14:44:07] <KotH> mru: take it easy [14:44:19] <KotH> mru: life is too short for broken gcc versions [14:45:57] <kshishkov> may I add that idiots are in abundance as well? [14:47:08] <mru> kshishkov: I've noticed [14:47:21] <mru> KotH: tell that to the gcc devs [14:50:31] * elenril wonders why is it harder to find someone to apply the patch than to get it through review [14:51:34] <kshishkov> because patch monkeys are out? [14:52:28] <elenril> no, because you're too lazy =p [14:52:49] <elenril> btw who should i blame for bink audio bugs? [14:53:12] <kshishkov> Bink owners for not disclosing the code [14:54:05] <elenril> audio in one of my sh2 videos sounds weird [14:54:19] <kshishkov> dct or rdft? [14:54:22] <elenril> dct [14:55:00] <kshishkov> yes, it's output is far from perfect [14:55:03] <kshishkov> *its [14:55:13] <elenril> another one sounds fine [14:58:13] <elenril> at least the colors look fine now [14:58:20] <kshishkov> sorry [14:59:12] <elenril> they were weird with some earlier version of the decoder [15:00:43] <kshishkov> yes, I saw them myself too [15:28:23] <twnqx> hi [15:28:36] <kshishkov> why? [15:28:44] <twnqx> is the tag-fix for mp4/mov already applied? [15:30:06] <elenril> no [15:30:15] <twnqx> :( [15:30:37] <elenril> you'll probably have to wait for bcoudrier to reappear [15:40:17] <CIA-90> ffmpeg: ramiro * r21921 /trunk/libavcodec/Makefile: x86_fft.o depends on MMX. [16:00:25] <pentanol> ho I may run it on i386 http://codepad.org/QP7eRmEs hen ... make ARCH=cris if I building it for cris? [16:00:50] <mru> obviously not [16:03:38] <CIA-90> ffmpeg: mru * r21922 /trunk/libavutil/internal.h: Add casts to correct return type in macros for missing libm funcs [18:28:59] <CIA-90> ffmpeg: vitor * r21923 /trunk/libavcodec/utils.c: [18:28:59] <CIA-90> ffmpeg: Free encoder extradata in avcodec_close(). Should fix several small memory [18:28:59] <CIA-90> ffmpeg: leaks when encoding (at least for asv, wma and aac). [18:28:59] <CIA-90> ffmpeg: Fix also issue 1577. [19:45:39] <BBB> Vitor1001, I'm confused about the fft code in the postfilter [20:14:37] <CIA-90> ffmpeg: mru * r21924 /trunk/ (libavutil/mathematics.h libavcodec/acelp_pitch_delay.c): Replace log2f(10) with a constant [20:17:37] <Vitor1001> BBB: what's the problem? [20:21:55] <BBB> Vitor1001, it doesn't work :) [20:22:12] <BBB> Vitor1001, you said that ForwFFT_INT was the same as Fourier [20:22:22] <BBB> but I tried ff_fft_permute+calc, and I get completely different results [20:22:28] <BBB> I think I misunderstand something very basic [20:22:42] <Vitor1001> Are you trying rdft? [20:22:46] <BBB> no, fft [20:22:56] <Vitor1001> But the input is real-only [20:23:18] <BBB> I'm affraid I don't really know what the difference is [20:23:23] <Vitor1001> So I think you should be using rdft [20:23:28] * BBB should read documents on what fft is [20:23:36] <BBB> I tried, and the result was also completely confusing [20:23:42] <Vitor1001> fft [20:24:04] <Vitor1001> q_k = sum_i x_i Exp[2 * pi* i/n] [20:24:07] <Vitor1001> rdft same thing [20:24:08] <BBB> can you recommend a doc on what it is? [20:24:11] <Vitor1001> but x_i is real [20:24:32] <BBB> what is q_k, what is sum_i, what is x_i and what is i/n? [20:26:30] <BBB> I remember getting complex numbers in math class, that was about as much as I understood of fft [20:26:39] <Vitor1001> ok [20:26:46] <Vitor1001> I'll try to explain [20:27:14] <Vitor1001> I pose j "=" sqrt(-1) [20:27:25] <Vitor1001> So [20:28:15] <Vitor1001> q[k] = (x[0].Re + j * x[0].Im)*Exp[2 * pi * 0 * j / n] +(x[1].Re + j * x[1].Im)*Exp[2 * pi * 1 * j / n] + ... [20:28:27] <Vitor1001> That's the FFT [20:28:58] <Vitor1001> RDFT is the special case where x[a].Im == 0 for all a. [20:29:52] <BBB> ok [20:30:54] <BBB> (I think) [20:31:05] <Vitor1001> I think the simplest thing to do is to print both the output of the function and the RDFT of the input [20:31:10] <Vitor1001> and them compare them [20:31:18] <BBB> I'm trying to do that [20:31:24] <BBB> let me try again [20:31:31] <Vitor1001> the second zero you put it by hand, it should be always 0. [20:32:00] <Vitor1001> The output of the function should be the first half of rdft interleaved with the second half [20:33:07] <Vitor1001> First thing I'd do is to rescale by the right constant [20:33:30] <Vitor1001> I think you should be able to find it by the first component of both (that should correspond) [20:34:37] <BBB> hmm.... [20:34:39] <BBB> [0/47] 0.001923 -> 0.002190 (RDFT: 0.002190, div=1.000000) [20:34:39] <BBB> [1/47] 0.000158 -> 0.000000 (RDFT: 0.001870, div=inf) [20:34:39] <BBB> [2/47] 0.000213 -> 0.002202 (RDFT: 0.002202, div=1.000024) [20:34:39] <BBB> [3/47] 0.000114 -> 0.000019 (RDFT: 0.000019, div=1.008606) [20:34:39] <BBB> [4/47] -0.000117 -> 0.002233 (RDFT: 0.002233, div=1.000065) [20:35:01] <BBB> where the first number is input (as int-num / (1<<30)) [20:35:07] <BBB> the second number is output (same) [20:35:13] <BBB> the third is output of ff_rdft_calc() [20:35:18] <BBB> ad div is the two divided by each other [20:35:54] <Vitor1001> looks good to me [20:36:05] <BBB> how come each second number is worse than each third [20:36:06] <BBB> ? [20:36:06] <Vitor1001> The second zero you should put by hand [20:36:11] <BBB> is that imprecision? [20:36:19] <BBB> look at [3] [20:36:21] <BBB> or 5: [20:36:27] <Vitor1001> no, the second number of the FFT of a real vector is always 0. [20:36:34] <Vitor1001> no matter the input [20:36:35] <BBB> [5/47] -0.000113 -> 0.000018 (RDFT: 0.000019, div=1.015727) [20:36:35] <BBB> [6/47] 0.000067 -> 0.002255 (RDFT: 0.002255, div=1.000046) [20:36:35] <BBB> [7/47] 0.000007 -> -0.000003 (RDFT: -0.000002, div=0.948960) [20:36:46] <BBB> I don't mean [1], I understand that's uninitialized [20:36:51] <BBB> but [3], [5] and [7] [20:37:04] <BBB> those are result[1].im, result[2].im and result[3].im, right? [20:37:11] <BBB> (the ones before are result[n].re) [20:37:50] <Vitor1001> You mean the ~ 5% difference? [20:38:07] <BBB> yes [20:38:10] <Vitor1001> I think it should be some bad numerical precision [20:38:22] <Vitor1001> if it is always not much greater than that [20:38:30] <BBB> it's about stable [20:38:37] <Vitor1001> Doing a FFT with reals should be not very precise [20:38:51] <Vitor1001> well, I'll be back in a few hours, have to go now. [20:40:27] <BBB> ok, thanks [20:43:46] <Kovensky> math D: [20:43:47] * Kovensky runs [20:45:44] <peloverde> BBB "i=0 is a special case because of packing, the DC term is real, so we are going to throw the N/2 term (also real) in with it. " [20:46:18] <BBB> peloverde, so it is uninitialized? [20:46:31] <peloverde> BBB: No [20:46:37] <BBB> or result[1<<n_bits].real is placed in result[0].im? [20:47:27] <peloverde> yes [20:49:25] <BBB> but because rdft functions on float[], not fftcomplex[], each float[n*2] is really the real and float[n*2+1] is its complementary im [20:49:26] <peloverde> you need it if you are going to unfold the RDFT into a regular FFT [20:50:06] <peloverde> yes that is the output on the forward RDFT [20:50:25] <peloverde> For the IRDFT it's interleaved complex in and real out [20:50:32] <BBB> got it [20:50:53] <BBB> does irdft expect the result[1<<n_bits].real to be in [1]? [20:50:58] <BBB> or is it unused? [20:51:29] <peloverde> it is needed for correct output [20:51:52] <BBB> because I believe this code does irdft also [20:51:59] <BBB> although I have no idea what its purpose is [20:53:03] <peloverde> We also have a pair that does complex time to real frequency and vice versa [20:55:50] <BBB> can I ask very stupid questions? [20:55:53] <BBB> what is the point? [20:56:06] <BBB> how does the output of rdft help in smoothening the audio? [20:56:14] <BBB> or what is the significance of the output of the rdft? [20:56:53] <BBB> here, for example, they're doing rdft(lpcs) [20:57:16] <BBB> x=rdft(lpcs); <- now what is x, except for some very complex set of numbers? [20:58:19] <peloverde> increasing indicies in the RDFT represent sines and cosines of increasing frequency [20:59:11] <Kovensky> [mp3 @ 0x8844460]max_analyze_duration reached <-- any harm? [20:59:28] <peloverde> So if you took the RDFT and multiplied it by function that decreased in value as index increased, you would put more emphasis on low frequencies and less on high frequencies [20:59:35] <Kovensky> elenril: TYER: 2009 <-- what [21:00:00] <peloverde> that's called frequency domain filtering [21:00:46] <BBB> that's the name of one of the functions here!!!!! [21:00:49] <BBB> I think [21:00:59] <BBB> (i.e. you're genious) [21:01:22] <BBB> "filterframefrequencydomain" [21:02:19] <peloverde> glad to help [21:09:07] <elenril> Kovensky: ? [21:09:59] <Kovensky> elenril: it's showing "TYER" instead of "date" (mp3 demuxer) [21:10:10] <elenril> ah [21:10:22] <elenril> blame me for being lazy/busy [21:33:22] <Kovensky> I also noticed that some demuxers export metadata all lower, some others all upper [21:33:34] <Kovensky> (metadata names, not values) [21:33:59] <elenril> export means before or after conversion? [21:34:19] <Kovensky> whatever mplayer prints when you use -demuxer lavf :P [21:35:09] <elenril> metadata system is mostly case insensitive [21:36:31] <elenril> generic keys in the conversion tables are lowercase, so converted tags would be lowercase [21:36:36] <Kovensky> and I see that flac still can't tell / seek :( [21:36:45] <elenril> blame jruggles [21:37:01] <elenril> he said it's on his todo list :) [22:48:59] <CIA-90> ffmpeg: michael * r21925 /trunk/libavformat/mov.c: [22:48:59] <CIA-90> ffmpeg: Do not attempt to open references through absolute pathes. [22:48:59] <CIA-90> ffmpeg: This would allow an attacker to test remotely if a local file exists. [22:58:11] <CIA-90> ffmpeg: michael * r21926 /trunk/libavformat/mov.c: [22:58:12] <CIA-90> ffmpeg: Make sure we dont write more bytes into filename than the array is long. [22:58:12] <CIA-90> ffmpeg: just a precaution in case the size of the source array is increased or [22:58:12] <CIA-90> ffmpeg: made dynamically allocateable.