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

irc at mansr.com irc at mansr.com
Sun Mar 7 01:00:56 CET 2010


[00:01:36] <peloverde> O.o my response to michael's review plus the new patch crossed the 200k limit
[00:02:21] <peloverde> Does a mod want to push it through or should I resend and omit the (unchanged) tables?
[00:03:01] <mru> done
[00:04:42] <peloverde> thanks
[00:08:51] <Dark_Shikari> my fuzzer has detected about half a dozen crases in ffmpeg already
[00:08:55] <Dark_Shikari> testing on h264+aac in mkv
[00:09:14] <mru> fix it!
[00:09:20] <Dark_Shikari> have to get samples first
[00:09:22] <peloverde> Dark_Shikari, I can't get it to crash fuzzing AAC-LC, mdat only in mp4
[00:09:36] <Dark_Shikari> random seeds that caused crashes: 140, 175, 182, 197, 229
[00:09:38] <peloverde> A few illegal reads, no crashes
[00:09:41] * mru needs to extend his bot to be as good as j-b's
[00:09:51] <Dark_Shikari> lemme post the fuzzer so anyone can replicate it
[00:10:33] <Dark_Shikari> http://pastebin.org/102018
[00:10:35] <Dark_Shikari> trivial fuzzer
[00:10:39] <Dark_Shikari> ./fuzzer inputfile outputfile seed
[00:10:59] <Dark_Shikari> http://mirror05.x264.nl/Dark/x264clips/IronMan.mkv test file
[00:11:11] <Dark_Shikari> encoding command: ffmpeg -i input output.avi
[00:11:22] <Dark_Shikari> thus, ./fuzzer IronMan.mkv test.mkv 140 will produce a crash in ffeg.
[00:11:24] <Dark_Shikari> *ffmpeg
[00:12:15] <peloverde> playing AAC with NBC PS crashes the mp3 decoder :)
[00:12:31] <peloverde> (actually it crashes SDL)
[00:12:35] <Dark_Shikari> lol
[00:12:41] <Dark_Shikari> well, time to debug these.
[00:14:15] <Dark_Shikari> woohooo!  crash in memcpy
[00:14:20] <Dark_Shikari> Matroska bug!
[00:14:27] <Dark_Shikari> oh shit this might be exploitable
[00:15:10] <mru> those are usually easy to fix
[00:15:46] <Dark_Shikari> then do it if it's so easy ;)
[00:15:53] * Dark_Shikari makes disabled-optimizations build to track this down better
[00:16:37] <mru> a runaway memcpy that actually crashes is much easier to track than one that corrupts some data causing a crash gigabytes later
[00:17:07] <Dark_Shikari> of course
[00:17:21] <Dark_Shikari> I'm not valgrinding =p
[00:17:23] <Dark_Shikari> too slow for fuzzing
[00:17:33] <peloverde> I always valgrind the crashes from fuzzers
[00:17:34] <mru> don't you have an i7?
[00:17:41] <peloverde> look for the first illegal write
[00:17:43] <Dark_Shikari> mru: I'm running this on a dual i7 linux box
[00:17:46] <Dark_Shikari> only 1.8ghz 2-core
[00:17:52] <Dark_Shikari> and valgrind is still slow
[00:18:01] <peloverde> hell for audio i run the fuzzer with valgrind
[00:18:16] <Dark_Shikari> want to investigate this one then?
[00:18:22] <Dark_Shikari> takes about a minute to crash with a memcpy in matroskadec
[00:18:29] <Dark_Shikari> who the hell maintains matroskadec anyways
[00:18:35] <peloverde> I don't know the matroskadec codebase at all
[00:18:47] <mru> it ain't me
[00:19:07] <Dark_Shikari> what would be the best way to start a fuzzer thread?
[00:19:18] <Dark_Shikari> I was thinking we could work on the bugtracker and offer the same bugfix rewards as usual, but keep it all in one bug report
[00:19:24] <Dark_Shikari> and all I would do is report sample name + random seed
[00:19:37] <Dark_Shikari> then I wouldn't have to upload every single one
[00:20:12] <Dark_Shikari> yup, it crashes where I thought
[00:20:13] <Dark_Shikari>  memcpy (pkt->data+offset, pkt_data, pkt_size);
[00:22:42] <Yuvi> aurel does, but I'm familiar with it too
[00:23:10] <Dark_Shikari> Yuvi: want to look into it?
[00:23:26] <Dark_Shikari> don't have to, it's not critical, just wondering.
[00:23:46] <Yuvi> sure
[00:24:16] <Dark_Shikari> ok, since I have slow upload, it will be fastest for you to replicate it by using the fuzzer
[00:24:19] <Yuvi> btw, pastebin.org's popups are annoying
[00:24:23] <Dark_Shikari> popups?
[00:24:26] <Dark_Shikari> it doesn't have popups
[00:24:33] <Dark_Shikari> or are you on some weird browser without adblocking
[00:24:35] <mru> Yuvi: not enough adblock?
[00:24:42] <Dark_Shikari> anyways, download the fuzzer, run it on the file with a seed of 140
[00:24:48] <Dark_Shikari> I gave the link above, should be enough info to replicate it
[00:24:56] <Yuvi> safari's popup blocking doesn't cover javascript onclick
[00:25:55] <Yuvi> (and view source is disabled for that site somehow?...)
[00:26:20] <mru> not for me
[00:26:31] <mru> you're browser's broken, dude
[00:27:10] <Yuvi> eh, it's the least broken of OS X browsers
[00:27:21] <mru> s/browser/OS/
[00:31:03] <Dark_Shikari> thread started on ffmpeg-devel
[00:32:43] <Yuvi> blocking *.adonion.com fixed it
[00:39:21] <mru> wow, that's an annoying popup
[00:39:44] <Yuvi> seed 140 doesn't crash for me, isn't it dependent on your RNG?
[00:40:38] <Dark_Shikari> Yuvi: shit.  it varies per OS?
[00:41:01] <mru> compare md5 of files
[00:41:03] <Dark_Shikari> blah, I guess that's true
[00:41:08] <Dark_Shikari> I'm running on gentoo here
[00:41:12] <Yuvi> af5356bc1ee63c6f0180f15705d04a33
[00:41:41] <Dark_Shikari> fbf75339bebb9ed4c13c2cc624d8c961  IronMan.mkv
[00:41:43] <Dark_Shikari> 5c59aa9d2bbfb08f1d29db54c4227b9e  test.mkv
[00:41:52] <Dark_Shikari> I could borrow ffmpeg's LCG or something
[00:42:18] <mru> yeah, you can't use rand()
[00:42:24] <Dark_Shikari> rand() differs even on linux systems?
[00:42:27] <mru> it's, err... random
[00:42:50] <mru> it's unspecified by the standard what it should do
[00:42:59] <Dark_Shikari> I guess it depends on libc version?
[00:43:05] <mru> I'm pretty sure glibc has changed it some time or other
[00:43:23] <mru> the old one wasn't bloated enough
[00:44:21] <Dark_Shikari> ok, I'll upload the file separately and modify my code to use a deterministic rng
[00:44:22] <janneg> return 4;?
[00:45:07] <Dark_Shikari> should I just have it link to libavutil?
[00:45:12] <Dark_Shikari> and use the LFG?
[00:45:26] <mru> maybe we need to write ffuzz
[00:48:47] <mru> janneg: xsi requires a period of at least 1<<32
[00:51:04] <Dark_Shikari> wait wtf
[00:51:07] <Dark_Shikari> I included avutil.h
[00:51:08] <Dark_Shikari> fuzzer.c:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'state'
[00:51:11] <Dark_Shikari> line:
[00:51:12] <Dark_Shikari> AVLFG state;
[00:51:18] <Dark_Shikari> is that not sufficient to have AVLFG defined?
[00:51:51] <Dark_Shikari> lfg.h isn't in my /usr/include/libavutil, is it not a public header?
[00:51:51] <mru> for lfg you need lfg.h
[00:52:10] <mru> seems not
[00:52:15] <mru> don't look at me
[00:53:52] <Dark_Shikari> updated the fuzzer
[00:53:56] <Dark_Shikari> obviously the old number (140) won't work
[00:54:34] <peloverde> Does anyone have an old mp3on4 draft from when it used to use AOT 29? I'm trying to add PS without breaking draft mp3on4
[00:56:43] <janneg> mru: I know, it was just a reference to http://xkcd.com/221/
[01:01:26] <janneg> MS shuffle implementation using "return (0.5 - Math.random());return (0.5 - Math.random());"
[01:01:29] <janneg> return (0.5 - Math.random());
[01:01:36] <mru> also http://dilbert.com/fast/2001-10-25/
[01:02:07] <janneg> return (0.5 - Math.random());
[01:02:10] <janneg> return (0.5 - Math.random());
[01:02:57] <Dark_Shikari> 9 9 9 9 9 9 9 9 9 9
[01:03:01] * Dark_Shikari clicks
[01:03:03] <Dark_Shikari> yes, it's that comic
[01:03:34] <mru> Dark_Shikari: I can fuzz the file for you directly on mphq
[01:03:45] <Dark_Shikari> Yuvi: http://www.mediafire.com/?mzmjijtmjhy
[01:03:46] <Dark_Shikari> here's your file
[01:03:51] <Dark_Shikari> mru: what do you mean?
[01:03:55] <Dark_Shikari> in an automated fashion?
[01:04:07] <mru> grab the original and run the fuzzer with your seed
[01:04:20] <mru> if your upload is slow
[01:04:30] <Dark_Shikari> that method is high latency and wastes space
[01:04:48] <mru> I know, cgi
[01:07:11] <janneg> argh, sorry. connection problems
[01:08:22] <janneg> using return (0.5 - Math.random()); as comparison function for a sort algorithm
[01:09:00] <janneg> if you're lucky it'll trigger an infinite loop
[01:09:19] <mru> rock, paper, scissors
[01:09:23] <mru> sort
[01:18:30] <Dark_Shikari> Yuvi: got it?
[01:21:53] <Yuvi> Dark_Shikari: yeah, matches your md5, but doesn't crash for me
[01:22:02] <Dark_Shikari> wtf?
[01:22:06] <Dark_Shikari> with commandline
[01:22:09] <Dark_Shikari> ffmpeg -i input output.avi
[01:22:10] <Dark_Shikari> ?
[01:22:20] <Yuvi> yep
[01:22:22] <Dark_Shikari> well, valgrind it and you'll probably get errors
[01:22:30] <Dark_Shikari> maybe whether or not it actually dies is system-dependent
[01:22:45] <Yuvi> my guess (from looking at the code) is an overread
[01:22:52] <Dark_Shikari> probably
[01:24:06] <Yuvi> wonder if released valgrind supports 64-bit OS X or 32-bit binaries only
[01:24:56] <Yuvi> actually guess I'll have to get a snapshot for 10.6 anyway
[01:27:44] <ohsix> are you guys both on x86_64 or whatever?
[01:28:01] <ohsix> nevermind
[01:32:19] <CIA-92> ffmpeg: michael * r22228 /trunk/tools/trasher.c: Make trasher use a well defined random number generator and allow the seed to be specified on teh cmd line.
[01:33:43] <CIA-92> ffmpeg: michael * r22229 /trunk/tools/trasher.c: Remove apparently unneeded define and includes.
[01:34:05] <J_Darnley> uh "on teh cmd line"?
[01:55:16] <Dark_Shikari> hahaha, michael added my features to trasher ;)
[01:56:00] <Dark_Shikari> Yuvi: try seed 35 with my new fuzzer
[02:12:50] <Compn> i think we need to promote some of ffmpeg's lesser known code
[02:32:11] <Yuvi> Dark_Shikari: got 35 to crash in linux, in os x it has a runaway malloc
[03:55:21] <Yuvi> Dark_Shikari: patch sent, should fix both of them
[04:37:22] <MrNaz_yma> Checking -head but i there's a bug in ffmpeg as of feb 10th: when using -ss and -t in conjunction, ffmpeg does not encode -t duration from the specified time in -ss but from the start... e.g.,   -ss 00:01:00 -t 00:01:30   will result in a 30 second clip instead of a 1 minute and 30 second clip
[04:37:31] <MrNaz_yma> i believe this is a break from past behavior
[06:06:30] <Dark_Shikari> Yuvi: great
[06:10:11] <Dark_Shikari> Yuvi: still here?
[06:10:18] <Yuvi> Dark_Shikari: yep
[06:10:20] <Dark_Shikari> 73, 163, 278,
[06:10:24] <Dark_Shikari> make sure all those are the same crash
[06:12:11] <Dark_Shikari> can you pastebin your patch as well so I can apply it locally?  copy-pasting from email sorta sucks
[06:13:06] <Yuvi> http://pastebin.org/102112
[06:14:22] <Dark_Shikari> thx
[06:17:41] <Dark_Shikari> Yuvi: if all three of those are the same issue, next target will be the mp4 demuxer
[06:38:18] <Yuvi> Dark_Shikari: yep, they are
[06:40:14] <Dark_Shikari> ok, fuzzing mp4 now.
[06:40:34] <Dark_Shikari> thanks for fixing that.
[07:23:41] <superdump> Dark_Shikari: reynaldo got back to me
[07:23:55] <superdump> he said that he hasn't been able to contact the guy who runs the server
[07:24:53] <Dark_Shikari> ooof :/
[07:27:06] <MrNaz_yma> Dark_Shikari can you clarify the correct behaviour for -t ?
[07:27:22] <Dark_Shikari> it should take as input X seconds of the video
[07:27:29] <MrNaz_yma> in that case it's wrong
[07:28:12] <MrNaz_yma> e.g.,     -ss 00:01:00 -t 00:02:00   should yield a 2 minute video... but it yields a 1 minute video, as it seems to take -t as a timestamp to end at rather than a length of time to encode for
[07:29:25] <Dark_Shikari> More likely, the fps is off by a factor of 2
[07:29:53] <superdump> Dark_Shikari: the main problem is that the article is linked to from all over the place
[07:29:54] <MrNaz_yma> no
[07:29:58] <superdump> but we could rewrite it
[07:30:04] <MrNaz_yma> Dark_Shikari no i've tried it with different times
[07:30:11] <superdump> or put up a mirror or something
[07:30:52] <MrNaz_yma> Dark_Shikari i've just confirmed that    -ss 00:04:00 -t 00:05:00   also yields a 1 minute video
[07:31:21] <MrNaz_yma> and that's with -r22168
[07:31:51] <Dark_Shikari> superdump: use google cache
[07:33:31] <superdump> maybe i'll copy and paste it back into a blogger blog i had ages ago so i never have to manage anything myself
[07:34:12] <Dark_Shikari> get hosting from mike
[07:35:09] <kshishkov> yes, it's a sign you work for FFmpeg too ;)
[07:41:12] <MrNaz_yma> Dark_Shikari also, when ffmpeg is invoked with infile === outfile all that happens is that it blows the file away... is there a reason for this or can i suggest a feature where it emits an error in this case ?
[07:41:58] <kshishkov> it's common way
[07:42:18] <kshishkov> i.e. it works this way in any other programe
[07:42:21] <kshishkov> *program
[07:43:06] <kshishkov> and your suggestion will fail something like ffmpeg -i pipe://1.avi pipe://1.avi
[07:43:48] <kshishkov> just accept this
[07:51:48] <MrNaz_yma> ok
[07:51:52] <MrNaz_yma> just wondering
[07:51:59] <MrNaz_yma> anyway... not sure if i've done this right:  https://roundup.ffmpeg.org/issue1797
[07:52:04] <MrNaz_yma> that's my first roundup submission
[09:26:55] <KotH> a wonderfull, snowy, swiss, good morning boys
[09:27:29] <elenril> snow is evil!
[09:27:52] * elenril doesn't want more snow here
[09:28:49] * kshishkov strikes out wrong words and is left with "morning, boys"
[09:29:34] <KotH> lol
[09:29:40] <KotH> hey, we got about 10cm of snow overnight
[09:29:47] <KotH> and it's still snowing :)
[09:30:08] <KotH> and, snow is fun :-)
[09:30:45] <elenril> snowing here too
[09:30:58] <elenril> nothing fun about it
[09:31:04] <kshishkov> slowly melting here
[09:36:25] <kshishkov> lol, Indeo Audio unpacks single bits into int array so getbits() is really a loop reading separate bits back from that array
[10:03:02] <Yuvi> hm, why does oggparsevorbis use the matroska packing for headers
[10:04:35] <Yuvi> wonder if nut specifies which packing of xiph headers to use
[10:13:09] * elenril wonders how long does it take to compile wine
[10:14:30] <kierank> not that long last time i did
[10:14:47] <kierank> i used make -j5 though
[10:15:14] <elenril> heh
[10:15:39] * elenril can't use big -j because of his shitty i/o controller
[10:15:49] <elenril> (i think)
[11:57:03] <Compn> Dark_Shikari : i assume you've seen this article : http://www.guardian.co.uk/technology/2010/feb/26/berners-lee-html5-adobe-argument
[12:20:25] <mru> hey guys, please endorse my separation of fft from dsputil.h
[12:22:13] <_av500_> i endorse it
[12:22:30] <_av500_> anything that makes dsputils smaller
[12:22:55] <peloverde> mru: I like the idea, I just want to review the details one more time
[12:23:23] <mru> the first patch just moves a block of lines from one file to another
[12:23:34] <mru> I'm not entirely happy with those tables
[12:23:41] <_av500_> peloverde: any move on the he issue? i was in no mails land for a week..
[12:23:48] <mru> they're spread out in weird places
[12:24:47] <peloverde> _av500_: Michael delivered a large review yesterday, I fixed most of the issues and asked for approval to commit the result as it stands
[12:25:17] <_av500_> cool
[12:25:28] <_av500_> and the ffplay fix?
[12:27:30] <peloverde> I never liked the name IRIDFT, it doesn't really make sense, i question if it should be made public
[12:28:05] <peloverde> _av500_, michael is ok with a hack in libavformat/utils.c
[12:28:13] <mru> please suggest improvements
[12:28:29] <mru> I have no idea what those values mean
[12:30:02] <_av500_> peloverde: ok
[12:30:43] <kshishkov> peloverde: that could be expressed as INTEGER_DFT|INVERSE_DFT instead of enum
[12:33:24] <peloverde> mail sent
[12:41:31] <CIA-92> ffmpeg: mru * r22230 /trunk/ (libavutil/mem.h libavcodec/dsputil.h):
[12:41:31] <CIA-92> ffmpeg: Move DECLARE_ALIGNED_{8,16} macros to mem.h
[12:41:31] <CIA-92> ffmpeg: These macros naturally belong next to the generic DECLARE_ALIGNED
[12:41:31] <CIA-92> ffmpeg: macro.
[13:07:34] <CIA-92> ffmpeg: stefano * r22231 /trunk/ffprobe.c:
[13:07:34] <CIA-92> ffmpeg: Add support to input devices in ffprobe.
[13:07:34] <CIA-92> ffmpeg: See the thread:
[13:07:34] <CIA-92> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Add support to input device to ffprobe
[13:07:34] <CIA-92> ffmpeg: Date: Sun, 21 Feb 2010 14:57:44 +0100
[14:12:46] <CIA-92> ffmpeg: stefano * r22232 /trunk/cmdutils.c:
[14:12:46] <CIA-92> ffmpeg: Make opt_default() look for options in sws_opts only if sws_opts is
[14:12:46] <CIA-92> ffmpeg: defined, fix crash.
[14:26:08] <CIA-92> ffmpeg: mru * r22233 /trunk/ (58 files in 5 dirs):
[14:26:08] <CIA-92> ffmpeg: Remove DECLARE_ALIGNED_{8,16} macros
[14:26:08] <CIA-92> ffmpeg: These macros are redundant. All uses are replaced with the generic
[14:26:08] <CIA-92> ffmpeg: DECLARE_ALIGNED macro instead.
[14:26:08] <CIA-92> ffmpeg: mru * r22234 /trunk/ (Makefile subdir.mak): Use $(RM) to delete files
[14:35:37] <CIA-92> ffmpeg: mru * r22235 /trunk/ (27 files in 5 dirs): Move FFT parts from dsputil.h to fft.h
[14:37:35] <elmojo> janneg: finished 02_rabbit-04.job and starting 02_rabbit-05_08.job now
[14:42:09] <_av500_> ah, i see more BBB renderers...
[15:10:06] <CIA-92> ffmpeg: kostya * r22236 /trunk/libavcodec/bink.c: Bink version 'h' also has chroma planes swapped
[15:24:36] <janneg> elmojo: nice, where can I download the files?
[15:24:46] <janneg> ah, I see
[16:41:05] <siretart> gmane-- :-/
[16:42:15] <saste> yes she's gone... too bad
[16:42:28] <astrange> pelhttp://github.com/aconverse/ffmpeg-heaac/commit/12cf52f1104e41048b984d3e2740261dcb43ea36 does anything interesting happen if you do "for (i = 0; i < 3; i++) autocorrelate(X_low[k], phi, i);"?
[16:44:47] <mru> astrange: your tab complete didn't take
[16:45:30] <astrange> oh, he quit
[16:46:29] <kshishkov> good IRC client shuld remember all nicks ever present in channel and autocomplete them
[16:46:58] <kshishkov> automatically kicking everybody who's ever offended you and you have op rights there is a bonus
[16:47:37] <astrange> irssi is a reasonable irc client but still has annoyances
[16:47:38] <kshishkov> evil is a cure for incompetence after all ;)
[16:48:16] <astrange> mostly that when you paste something, half the time it just tries to privmsg it to the first word you pasted
[16:51:29] <mru> I never had that problem
[16:51:40] <mru> paste stuff starting with /msg much?
[16:54:07] <astrange> maybe it was pasting things starting with a tab
[16:58:37] <CIA-92> ffmpeg: siretart * r22237 /branches/ (0.5 0.5/configure):
[16:58:37] <CIA-92> ffmpeg: Add Hurd to OS list and disable dv1394 in the Hurd case.
[16:58:37] <CIA-92> ffmpeg: patch by Andres Mejia, mcitadel gmail com
[16:58:37] <CIA-92> ffmpeg: backport r18938 by diego
[16:59:10] <kshishkov> wow, somebody cared about Hurd!
[16:59:27] <mru> lol
[17:01:11] <kshishkov> BTW, how's VMS support status?
[17:14:22] <CIA-92> ffmpeg: thilo.borgmann * r22238 /trunk/libavcodec/alsdec.c: Fix last frame block size correction.
[17:15:02] <CIA-92> ffmpeg: mru * r22239 /trunk/ (subdir.mak configure): Add YASMDEP variable; use for deps on yasm files
[17:15:02] <CIA-92> ffmpeg: mru * r22240 /trunk/ (Makefile configure): Add CP make variable
[17:15:03] <CIA-92> ffmpeg: mru * r22241 /trunk/ (Makefile subdir.mak): Use mkdir -p to create directories
[17:15:03] <CIA-92> ffmpeg: mru * r22242 /trunk/ (Makefile subdir.mak configure): Add INSTALL makefile variable
[17:15:05] <CIA-92> ffmpeg: mru * r22243 /trunk/subdir.mak: Split install-headers target and simplify rules
[17:15:06] <CIA-92> ffmpeg: mru * r22244 /trunk/ (Makefile common.mak subdir.mak):
[17:15:06] <CIA-92> ffmpeg: Prettify make output
[17:15:06] <CIA-92> ffmpeg: This gives brief messages from make by default. For full command
[17:15:06] <CIA-92> ffmpeg: echoing, add V=1 to make command line.
[17:43:10] <J_Darnley> >Prettify make output
[17:43:13] <J_Darnley> eeeewwww
[17:43:54] <kshishkov> well, you can't make it uglier so somebody tried it other way
[17:44:01] <J_Darnley> Makes make -s pointless
[17:45:08] <CIA-92> ffmpeg: mru * r22245 /trunk/ (subdir.mak configure): Fix make install
[17:45:11] <J_Darnley> granted, it isn't very silent with ahh the warning
[17:45:17] <J_Darnley> *all
[17:46:22] <mru> J_Darnley: you liked it better before?
[17:46:29] <CIA-92> ffmpeg: mru * r22246 /trunk/subdir.mak: Fix install with shared libs on weird systems
[17:46:36] <J_Darnley> I was a bit more quiet
[17:46:41] <J_Darnley> *It
[17:46:49] <mru> eh?
[17:47:02] <J_Darnley> make -s doesn't echo the commands
[17:47:10] <mru> make V=1 gives you exactly what you had before
[17:47:19] <J_Darnley> now it echoes CC foo/bar
[17:51:59] * DonDiego is not fond of terse make output
[17:52:10] <mru> so export V=1
[17:54:29] <mru> if you hate it so badly, why didn't you say anything on the ml?
[18:03:02] <mru> http://fate.multimedia.cx/index.php?stderr=195059
[18:03:07] <mru> any clues wtf that is?
[18:24:00] <Dark_Shikari> impressive
[18:24:05] <Dark_Shikari> 500 runs on the fuzzer, mp4+aac hasn't crashed
[18:24:10] <Dark_Shikari> er, h264+aac in mp4
[18:24:15] <kshishkov> good
[18:24:46] <kshishkov> try that also on Theora+Vorbis ;)
[18:26:52] <janneg> in ogg
[18:27:16] <kshishkov> of course, ISO was wise not to allow muxing it into mp4
[18:27:52] <DonDiego> mru: i no longer read the mls and to be honest, i don't yet know if i will make a comeback
[18:29:48] <DonDiego> Dark_Shikari: that was ffmpeg?
[18:30:10] <DonDiego> and sure, putting our theora and vorbis stuff through the same punishment would be interesting..
[18:30:43] <peloverde> Dark_Shikari, google and I spent meany hours cleaning up AAC
[18:31:49] <kshishkov> and somebody worked on H.264 decoder too, obviously
[18:32:15] <DonDiego> ffserver.c:2445: warning: implicit declaration of function ‘strcasestr’
[18:32:42] <DonDiego> is this only on os x or are people now competing to introduce more and lamer warnings?
[18:32:49] * DonDiego shakes his head
[18:33:21] <kshishkov> maybe it's GCC
[18:33:27] <DonDiego> at the current rate the day when mplayer code is cleaner than ffmpeg cannot be far away ;-p
[18:34:24] <kshishkov> unlikely
[18:34:33] <Dark_Shikari> DonDiego: you got a test sample for me to try on?
[18:34:36] <Dark_Shikari> I would be happy to fuzz ogg
[18:34:55] <Dark_Shikari> could just use ffmpeg2theora to make one
[18:34:56] <DonDiego> big buck bunny is the standard one
[18:35:07] <DonDiego> or our samples collection
[18:35:23] <Dark_Shikari> well, 500 runs on mp4 is probably good enough for now.
[18:35:31] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/
[18:35:36] <Dark_Shikari> given it's a 250MB MP4, that's about 75 gigs of fuzzing
[18:35:59] <DonDiego> the samples dir has smaller files
[18:36:13] <Dark_Shikari> bigger means more chances for failure though
[18:36:22] <Dark_Shikari> well, I guess it works both ways
[18:36:27] <Dark_Shikari> smaller is more likely to find header parsing issues
[18:36:54] <peloverde> I generally do two rounds of fuzzing for mp4 files, one on the whole file and one on mdat only
[18:36:58] <DonDiego> Yuvi: this reminds me - what samples do you use for performance comparisons?
[18:37:03] <DonDiego> Yuvi: and how do you test?
[18:37:19] <DonDiego> i ran some tests with mplayer and two samples from the samples dir yesterday
[18:37:27] <DonDiego> and libtheora 1.0 came up slightly faster
[18:43:27] <Dark_Shikari> on an unrelated note
[18:43:30] <Dark_Shikari> http://img682.imageshack.us/img682/3374/theora.png
[18:43:31] <Dark_Shikari> http://img682.imageshack.us/img682/7056/schroedinger.png
[18:43:42] <Dark_Shikari> the new schroedinger beats theora again
[18:44:02] <Dark_Shikari> http://forum.doom9.org/showthread.php?p=1380594#post1380594
[18:45:08] <kshishkov> so?
[18:49:34] <DonDiego> is that in any way surprising?
[18:49:44] <Dark_Shikari> Actually it is, theora used to beat schro on many tests
[18:49:59] <Dark_Shikari> I'm not sure if that was a testament to theora improving, or schro sucking terribly
[18:50:14] <kshishkov> someone should try Haar+fullpel MC+fspp postproc for video codec
[18:50:20] <kshishkov> it should also beat THeora
[18:50:29] <Dark_Shikari> kshishkov: postproc?  I have my own very nice postproc chain
[18:50:53] <Dark_Shikari> SPP + dehalo_alpha + limited_sharpen_faster + very strong gradfun
[18:50:58] <kshishkov> Dark_Shikari: well, postproc is the only thing why Theora does not suck even more
[18:50:59] <Dark_Shikari> it does wonders for blocky-mess videos
[18:51:15] <Dark_Shikari> I watched this awful awful FLV video yesterday and that made it basically fine
[18:51:27] <Dark_Shikari> SPP to kill blocks, dehalo to kill ringing, LSF to make it not blurry, and gradfun to remove smudging
[18:51:35] <Dark_Shikari> And it went barely in realtime on sub-SD on a core i7 ;)
[18:53:54] <kshishkov> still, throwing out all details should give us excellent bitrate, low-complexity gives more CPU to postfilter which drops a bag of fairy dust on the whole codec
[18:54:23] <Dark_Shikari> of course, it's not good if you want to actually _keep_ details
[18:54:23] <Dark_Shikari> =p
[18:54:35] <Dark_Shikari> kshishkov: that's the On2 method
[18:54:42] <Dark_Shikari> 1) low complexity crap codec
[18:54:45] <Dark_Shikari> 2) claim "high performance"
[18:54:48] <kshishkov> yes, so the only way to compete with Theora
[18:54:54] <Dark_Shikari> 3) dump "optional" postprocs on it, without which it looks like shit
[18:55:03] <Dark_Shikari> the theora postproc is not very good
[18:55:08] <Dark_Shikari> ok, it's basically nonexistent
[18:55:18] <Dark_Shikari> Go look at VP6 or VP7 for stupidly complex postproc
[18:55:28] <Dark_Shikari> VP8 will probably be even worse
[18:55:40] * kshishkov hopes it won't be at all
[19:08:38] <Dark_Shikari> Got a segfault on theora+vorbis in ogg
[19:08:47] <Dark_Shikari> Yuvi: interested?
[19:09:12] <kshishkov> try with official player ;)
[19:09:20] <Dark_Shikari> I'm just fuzzing ffmpeg.
[19:15:22] <mru> strcasestr is an evil gnu function
[19:15:31] <mru> the prototype isn't visible in c99 mode
[19:17:15] <Dark_Shikari> http://hothardware.com/News/Sonys-Great-Idea-Demos-That-Become-Less-Fun-When-Played/
[19:17:18] <Dark_Shikari> lol
[19:18:13] <Dark_Shikari> wow, I'm getting a LOT of ogg segfaults
[19:20:02] <CIA-92> ffmpeg: stefano * r22247 /trunk/ffplay.c:
[19:20:02] <CIA-92> ffmpeg: Use av_get_pict_type_char() in debug code within output_picture2(),
[19:20:02] <CIA-92> ffmpeg: simplify.
[19:20:02] <CIA-92> ffmpeg: stefano * r22248 /trunk/ffplay.c: Reindent after the last commit.
[19:21:14] <Dark_Shikari> Yuvi and anyone else who wants to find/fix ogg, vorbis, or theora bugs
[19:21:16] <Dark_Shikari> http://mirror05.x264.nl/Dark/Extra.ogv
[19:21:31] <Dark_Shikari> fuzzer seeds: 6 9 12 13 28
[19:21:54] <Dark_Shikari> I think I actually got an infinite loop too
[19:22:14] <Dark_Shikari> Yup.  Seed 30 is an infinite loop it seems.
[19:22:28] <DonDiego> mru: see, i'm sayin this is a competition to introduce lame warnings
[19:22:39] <DonDiego> see a warning - ignore it - the ffmpeg way..
[19:22:41] <mru> I have a fix queued up
[19:22:53] <mru> spare the sarcasm
[19:23:05] <DonDiego> it's true
[19:23:35] <DonDiego> it took massive flaming and a *vote* to have michael agree to a "let's at least try to fix warnings" policy
[19:24:36] <mru> that was michael
[19:25:10] <DonDiego> strcasesep?
[19:25:16] <twnqx> Oo
[19:25:18] <DonDiego> strcasestr i mean
[19:25:31] <DonDiego> well, no wonder, he is known to actively ignore warnings..
[19:25:42] <twnqx> i did that
[19:25:50] <mru> that wasn't michael
[19:25:55] <mru> and I said I have a fix waiting
[19:25:58] <mru> calm down
[19:26:11] <twnqx> until i wasted a day up to the point where -Wall showed a warning... and it was the cause of the problem
[19:28:29] <kshishkov> so GCC showsonly useless warnings by default?
[19:29:39] <twnqx> nah, but mostly.
[19:30:19] <CIA-92> ffmpeg: mru * r22249 /trunk/common.mak: Fix build with compilers using a separate dependency command
[19:30:25] <DonDiego> nonsense
[19:31:44] <DonDiego> btw, that warnings vote was actually a good opportunity for voting: there was already consensus, it just had not become clear
[19:32:52] <DonDiego> siretart: i have no trouble building either 0.5 or trunk with the configuration you mentioned
[19:33:07] <DonDiego> i.e. --enable-cpudetect --enable-swscale --enable-gpl
[19:41:29] <CIA-92> ffmpeg: diego * r22250 /branches/0.5/configure: libswscale is no longer GPL; update help comment accordingly.
[19:41:49] <kshishkov> no longer GPL-only
[19:41:59] <kshishkov> it still can be GPL
[19:42:03] <DonDiego> sur
[19:42:04] <DonDiego> e
[19:42:12] <CIA-92> ffmpeg: mru * r22251 /trunk/libavutil/ (avstring.h avstring.c):
[19:42:12] <CIA-92> ffmpeg: Add av_stristr() function
[19:42:12] <CIA-92> ffmpeg: This is a case-insensitive version of strstr().
[19:42:12] <CIA-92> ffmpeg: mru * r22252 /trunk/ffserver.c: ffserver: use av_stristr()
[19:42:16] <mru> there, strcasestr gone
[19:43:09] <kshishkov> why that reminds me of Borland vs. something else case-insensitive string function naming?
[19:44:43] <mru> there was already an 'i' function in avstring so I stuck with the pattern
[19:44:54] <mru> I don't really prefer one over the other
[19:45:34] <kshishkov> I don't think there's a real reason to prefer one over oanother anyway
[19:51:45] <CIA-92> ffmpeg: diego * r22253 /branches/0.5/Changelog: Mention LGPL libswscale in the Changelog.
[19:54:05] <saste> mru: r22251 => missing minor bump and APIChanges entry
[19:54:24] <mru> feel free to fix while I fix some actual bugs
[19:54:47] <saste> i'll do
[19:55:02] <saste> not that i consider this *not* an actual bug...
[19:58:24] <kshishkov> you know, inventor of first computer said that it'd be better and cheaper if higher-skilled workers would do tasks requiring high skills and leave mundane tasks to low-skilled workers
[19:59:28] <Dark_Shikari> my god I have a lot of fuzzer failures on ogg
[19:59:30] <Dark_Shikari> so far:
[19:59:31] <Dark_Shikari> Crash: 6 9 12 13 28 38 67 69 73 82 90 91 96
[19:59:31] <Dark_Shikari> Infinite loop: 30 48 60
[20:00:01] <mru> did I mention ogg being difficult to implement?
[20:00:08] <Dark_Shikari> this might be in theora or vorbis too
[20:00:13] <Dark_Shikari> haven't gdb'd anything
[20:01:00] <astrange> turn on coredumps
[20:01:18] <Dark_Shikari> effort, I won't be able to figure out which coredumps associate with which fuzzer seeds
[20:01:48] <mru> fix your script to take care of that
[20:02:14] <Dark_Shikari> meh
[20:08:42] <CIA-92> ffmpeg: stefano * r22254 /trunk/ (libavutil/avutil.h doc/APIchanges):
[20:08:42] <CIA-92> ffmpeg: Bump minor number and add APIchanges entry after the inclusion of
[20:08:42] <CIA-92> ffmpeg: av_stristr().
[20:10:12] <astrange> it's still useful to know where a crash can possibly be
[20:10:27] <astrange> but matching files is better, yes
[20:16:35] <ramiro> is it possible to automate gdb to break at an address and print the value of edi and continue execution?
[20:16:42] <mru> yes
[20:21:27] <ramiro> any specific pointers on how that would be done are welcome...
[20:24:28] <janneg> ramiro: commands
[20:38:44] <ramiro> mru, janneg: thanks, I finally got it...
[21:29:00] <CIA-92> ffmpeg: stefano * r22255 /trunk/libavfilter/avfilter.c: Show aspect ratio information in dprintf_picref() traces.
[21:29:56] <Yuvi> Dark_Shikari: I'll start looking at ogg crashes in a bit
[21:30:20] <Dark_Shikari> k
[21:36:07] <Dark_Shikari> I stopped the fuzzer because it was getting too much stuff
[21:36:11] <Dark_Shikari> I suspect it's probably only a few bugs.
[21:51:47] <verb3k> I get some artifacts with an h.264 video on ffplay and mplayer svn (didn't have that on older revisions)
[21:52:03] <verb3k> is this the right place to talk about this?
[22:00:18] <mru> http://www.nf.mpg.de/orgmode/guest-talk-dominik.html
[22:00:28] <mru> note the video downloads:
[22:00:30] <mru> Best quality (QuickTime, 301 MB)
[22:00:34] <mru> Good quality (Ogg/Vorbis, 364 MB)
[22:00:41] <Dark_Shikari> >quicktime
[22:00:44] <Dark_Shikari> stab him in the face please
[22:00:44] <ShadowJK> lol
[22:00:53] <mru> I assume it's h264 inside
[22:00:58] <Dark_Shikari> probably quicktime h264
[22:01:02] <Dark_Shikari> aka worse than theora
[22:01:12] <kierank> and zipped for good measure
[22:01:15] <mru> yeah
[22:21:23] <CIA-92> ffmpeg: reimar * r22256 /trunk/libavformat/gxf.c:
[22:21:23] <CIA-92> ffmpeg: GXF time base is always based on "fields" per second even for
[22:21:23] <CIA-92> ffmpeg: non-interlaced video.
[22:21:23] <CIA-92> ffmpeg: Should fix issue 1766.
[22:26:45] <CIA-92> ffmpeg: reimar * r22257 /trunk/libavformat/gxf.c: Set GXF fallback time-base to match the one specified for audio-only.
[22:37:27] <CIA-92> ffmpeg: mru * r22258 /trunk/ (7 files in 4 dirs): Add some missing #includes
[22:37:27] <CIA-92> ffmpeg: mru * r22259 /trunk/libavcodec/ (mpegaudiodec.c atrac1.c rdft.c):
[22:37:27] <CIA-92> ffmpeg: Make some functions static
[22:37:27] <CIA-92> ffmpeg: These functions are not used outside their respective files, and they
[22:37:27] <CIA-92> ffmpeg: lack a prototype in a header.
[22:37:28] <CIA-92> ffmpeg: mru * r22260 /trunk/libavcodec/ (lpc.h dsputil.c ac3dec.h png.h vorbis.h): Move some prototypes from dsputil.c to reasonable header files
[22:37:29] <CIA-92> ffmpeg: mru * r22261 /trunk/libavcodec/ (dsputil.c dsputil.h mlpdsp.c): Move prototypes for various dsputil init functions to dsputil.h
[22:37:34] <CIA-92> ffmpeg: mru * r22262 /trunk/libavcodec/ (mpegvideo.h h263.h): Move ff_set_qscale() prototype to mpegvideo.h; it is defined in mpegvideo.c
[22:37:34] <CIA-92> ffmpeg: mru * r22263 /trunk/libavcodec/ (dsputil.c dsputil.h vc1dsp.c):
[22:37:34] <CIA-92> ffmpeg: Move some VC1 dsp prototypes to dsputil.h; they are defined in dsputil.c
[22:37:34] <CIA-92> ffmpeg: Also fix function definitions to match prototypes (missing const).
[22:37:35] <CIA-92> ffmpeg: mru * r22264 /trunk/libavcodec/ (cavsdsp.c dsputil.c dsputil.h): Move some dsp func prototypes to dsputil.h; they are defined in dsputil.c
[22:37:35] <CIA-92> ffmpeg: mru * r22265 /trunk/libavcodec/ (dsputil.c snow.h): Move ff_spatial_dwt() prototype to snow.h
[22:37:36] <CIA-92> ffmpeg: mru * r22266 /trunk/libavcodec/x86/ (6 files): x86: move function prototypes to header files
[22:38:08] <CIA-92> ffmpeg: mru * r22267 /trunk/libavcodec/ppc/ (13 files): PPC: move prototypes to headers and make some functions static
[23:08:25] <saste> how can I generate a random number in pure sh?
[23:08:42] <saste> I just discovered $RANDOM is a bashsism
[23:08:45] <mru> pseudo-random good enough?
[23:09:03] <saste> yes that would work
[23:09:10] <mru> you can cook an LCG PRNG easily enough in sh
[23:09:47] <saste> * uhm ... googling  for LCG
[23:10:03] <iive> /dev/random?
[23:10:06] <mru> next=cur*CONST1+CONST2
[23:10:33] <saste> /dev/random I'm not sure how portable it is
[23:10:40] <mru> not at all
[23:10:40] <saste> LCG should be fine though
[23:10:50] <mru> do an lcg and seed with pid
[23:10:54] <mru> that's portable
[23:11:01] <saste> mru: ok thanks
[23:11:44] <mru> or use date with some format producing numbers
[23:11:52] <saste> (echo $$ ; w ; date) | cksum | cut -d" " -f1
[23:11:57] <saste> this was my first idea
[23:13:18] <mru> what do you need a random number for?
[23:13:39] <saste>         slicify_h=$(expr 8 + \( $RANDOM % 24 \))
[23:13:50] <saste> that's for the lavfi test script
[23:14:07] <Vitor1001> Dark_Shikari: If you are looking for something nice for your fuzzer, try http://samples.mplayerhq.hu/fate-suite/real/spygames-2MB.rmvb
[23:14:19] <Dark_Shikari> Vitor1001: ahahahahah, you want me to torture kostya?
[23:14:43] <Vitor1001> Not his fault, just hacked a 5 min script to run it across all fate samples.
[23:14:51] <Vitor1001> And this one fails for _every_ random seed
[23:14:59] <Dark_Shikari> it crashes on every one?  LOL
[23:15:42] <Vitor1001> Ok, it was an overstatement. For some of them it is just an infinite loop and my script timeout
[23:16:10] <mru> that's what the -timelimit option is good for
[23:16:47] <Dark_Shikari> Vitor1001: lol
[23:16:49] <Vitor1001> mru: does it works when the decoder enter an infinite loop?
[23:16:55] <Dark_Shikari> well, we need a place to stick all these results
[23:16:57] <Dark_Shikari> ;)
[23:16:59] <mru> Vitor1001: yes
[23:17:04] <mru> the OS kills the process
[23:17:09] <Vitor1001> mru: nice
[23:17:18] <Vitor1001> Dark_Shikari: What do you think about the wiki solution?
[23:17:32] <mru> someone found a solution to the wiki problem?
[23:17:38] <Vitor1001> mru: lol
[23:17:59] <Vitor1001> talking about adding a table of fuzzled files that segfaults
[23:18:10] <mru> I figured
[23:18:29] <Vitor1001> Looks readable and script-friendly
[23:18:46] <Vitor1001> at least script-friendly for adding entries
[23:19:07] <Dark_Shikari> a wiki solution sounds fine to me
[23:19:17] <Dark_Shikari> better than spamming fate with useless numbers
[23:19:23] <mru> are wikis soluble in water?
[23:19:27] <mru> or do you need ether?
[23:19:44] <Vitor1001> alcoohol
[23:19:55] <CIA-92> ffmpeg: mru * r22268 /trunk/libavformat/ (seek.c internal.h): Move av_read_frame_flush() prototype to lavf/internal.h
[23:19:57] <CIA-92> ffmpeg: mru * r22269 /trunk/configure:
[23:19:57] <CIA-92> ffmpeg: Error on implicit function declarations
[23:19:57] <CIA-92> ffmpeg: Turning on -Werror=implicit makes implicit function declarations
[23:19:57] <CIA-92> ffmpeg: an error with supported compilers.
[23:20:06] <mru> there, no more of those mistakes
[23:21:06] <twnqx> can't a SINGLE flight this year be on time :(
[23:21:23] <twnqx> *whine*
[23:21:35] <mru> flights on time? unheard of
[23:21:56] <mru> anyway, it's party time over here
[23:22:00] <twnqx> enjoy :)
[23:27:32] <Vitor1001> Dark_Shikari: 5 minutes ugliness: http://wiki.multimedia.cx/index.php?title=Fuzzer_work
[23:28:03] <Dark_Shikari> ah, using the trasher thingy
[23:28:40] <Vitor1001> Dark_Shikari: Does it work worse than yours?
[23:28:56] <Vitor1001> It is pretty pratical to use something already in the tree...
[23:29:26] <Dark_Shikari> I agree
[23:34:24] <Dark_Shikari> Vitor1001: could you get it to automatically update the page?
[23:34:26] <Dark_Shikari> to add new info etc
[23:34:41] <Vitor1001> You mean the script?
[23:34:42] <Dark_Shikari> the ultimate of course would be a button to re-check something, to tell the fuzzer to go try it again, but that would be hard
[23:34:45] <Dark_Shikari> yeah
[23:35:49] <Vitor1001> Looks non-trivial
[23:36:05] <Vitor1001> but outputting cut-and-pastable output should be easy
[23:37:24] <CIA-92> ffmpeg: michael * r22270 /trunk/libavcodec/mpegaudio3.h:
[23:37:25] <CIA-92> ffmpeg: header for common code between mp3 decoder and encoder.
[23:37:25] <CIA-92> ffmpeg: unfinished, iam just commiting this so the functions that should be
[23:37:25] <CIA-92> ffmpeg: non static have prototypes.
[23:38:50] <Vitor1001> Dark_Shikari: Did you already try trasher? I wonder what range of parameters you found useful..
[23:40:35] <Dark_Shikari> didn't try it yet


More information about the FFmpeg-devel-irc mailing list