[FFmpeg-devel-irc] IRC log for 2010-02-20

[irc at mansr.com]

[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/cfd4b6027476aca8bfc25e5f1ee95accf52a98b3 ?
[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_stereo.ogg
[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.