[FFmpeg-devel-irc] IRC log for 2010-08-01

[irc at mansr.com]

[00:08:21] <Yuvi>  _skal_paris_ i is guaranteed to be less than 16 before that statement
[00:10:05] <Yuvi> oh hm, it is wrong
[00:16:02] <lu_zero> roundup should be cleaned up
[00:16:11] <lu_zero> it cannot take more than 1GB...
[00:16:51] <peloverde> more than 1GB of...?
[00:17:20] <lu_zero> j0sh: mplayer is already integrated =)
[00:17:42] <lu_zero> 1.4G	roundup-base.tar.xz
[00:18:07] <lu_zero> meh
[00:18:18] <lu_zero> and gnutar obviously is stupid =_=
[00:18:44] <lu_zero> it's a plain tar uncompressed...
[00:31:30] <CIA-92> ffmpeg: alexc * r24639 /trunk/libavformat/ (matroskadec.c avformat.h): Add WebM to the Matroska demuxer name.
[00:46:54] <CIA-92> ffmpeg: stefano * r24640 /trunk/tests/lavfi-regression.sh:
[00:46:54] <CIA-92> ffmpeg: Rename the not yet enabled test lavfi_pix_fmts to pixfmts, which is
[00:46:54] <CIA-92> ffmpeg: simpler and consistent with the names of the other lavfi tests.
[00:46:54] <CIA-92> ffmpeg: stefano * r24641 /trunk/tests/lavfi-regression.sh:
[00:46:54] <CIA-92> ffmpeg: Split the lavfi pixfmts tests in _le and _be, this is required as the
[00:46:55] <CIA-92> ffmpeg: test results and references depend on machine endianess.
[00:46:56] <CIA-92> ffmpeg: stefano * r24642 /trunk/tests/lavfi-regression.sh:
[00:46:56] <CIA-92> ffmpeg: Introduce and use a variable $output in the lavfi pixfmts test code.
[00:46:57] <CIA-92> ffmpeg: Consistent with the lavfi pixdesc test code, and slightly improve
[00:46:57] <CIA-92> ffmpeg: readability.
[00:46:58] <CIA-92> ffmpeg: stefano * r24643 /trunk/tests/lavfi-regression.sh:
[00:46:58] <CIA-92> ffmpeg: Put the filter name before the pixel format name in the lavfi pixfmts
[00:46:59] <CIA-92> ffmpeg: test output files, and add a prefix with the name of the test.
[00:46:59] <CIA-92> ffmpeg: Make per-filter grouping of the generated output files easier, which
[00:47:00] <CIA-92> ffmpeg: is more useful than per-pixel-format grouping.
[00:55:14] <saintdev> lol CELT's attack detection is braindead simple
[00:56:42] <saintdev> i bet it is very susceptible to false-positives
[00:59:08] <Dark_Shikari> should suggest improvements
[00:59:12] <Dark_Shikari> I'm guessing it isn't very optimized
[01:01:21] <saintdev> well, they really want something fast. unlike aac or mp3, where you have all day (comparatively) to spend on it
[01:01:31] <saintdev> even so:
[01:03:23] <saintdev> for(i = 0; i < overlap) begin[i + 1] = max( begin[i], max( abs(in[i*channels]), abs(in[i*channels + 1]));
[01:03:48] <saintdev> threshold = .4f * begin[overlap];
[01:04:02] <saintdev> that's _it_
[01:04:14] <saintdev> compare begin[] to threshold, ofc.
[01:04:17] <Dark_Shikari> lol
[01:04:38] <saintdev> like i said, braindead simple.
[01:05:09] <saintdev> but it is fast...
[01:10:43] <siretart> peloverde: confirmed, but you can safely install libswscale0 for now. that should work equally well
[07:40:19] <mru> mornings
[07:53:18] <mru> we have some bsds on the new fate
[07:53:30] <mru> dragonfly and openbsd are failing vorbis
[08:16:24] <spaam> :D
[08:20:27] <astrange> and freebsd
[08:20:45] <mru> ah, he just added it
[08:21:04] <mru> dragonfly is just a rebranded freebsd anyway
[08:21:19] <mru> openbsd also crashes in wmavoice
[09:33:41] <astrange> dragonfly has different smp support, dunno if anything else is different
[09:34:00] <mru> it actually has slightly less broken system headers
[10:27:51] <CIA-92> ffmpeg: stefano * r24644 /trunk/tests/lavfi-regression.sh:
[10:27:51] <CIA-92> ffmpeg: Use the ffmpeg specified in $ffmpeg in the pixfmts lavfi test,
[10:27:51] <CIA-92> ffmpeg: otherwise the test will be running whatever ffmpeg is installed on the
[10:27:51] <CIA-92> ffmpeg: host system.
[10:27:51] <CIA-92> ffmpeg: stefano * r24645 /trunk/ (Makefile tests/lavfi-regression.sh):
[10:27:52] <CIA-92> ffmpeg: Fix fate-lavfi-pixfmts test cross-compilation.
[10:27:53] <CIA-92> ffmpeg: Add the lavfi-showfiltfmts dependency in the Makefile, and correctly
[10:27:53] <CIA-92> ffmpeg: use the $target_exec and $target_path variables for invoking the
[10:27:54] <CIA-92> ffmpeg: lavfi-showfiltfmts tool.
[10:29:05] <saste> mru: now I'm considering to split the pixfmts test
[10:29:41] <saste> mru: i mean something like fate-pixfmts-scale, fate-pixfmts-crop, etc...
[10:30:03] <saste> mru: that's also because on my old P4 this test is taking ages
[10:38:14] <mru> saste: you have nothing more modern?
[10:38:22] <mru> what is it with ffmpeg devs and ancient hw?
[10:39:11] <peloverde> BBB is finally getting a new computer this week, we are slowly moving forward
[10:40:19] <spaam> mru: only you who got some new hw?
[10:40:30] <saste> mru: I like the smell of old hw
[10:40:57] <mru> saste: but P4 stinks of rotten silicon
[10:41:04] <saste> mru: jokes apart I'm waiting for a new computer
[10:41:33] <saste> mru: in the meaningwhile I'm using this old one... which is working quite fine apart that it's slow
[10:41:54] <saste> mru: but the fault is in most modern software which is *bloated*
[10:42:21] <mru> ffmpeg isn't particularly bloated
[10:42:22] <saste> mru: that said... I tend to prefer many small tests rather than just a big ones
[10:42:27] <mru> sure
[10:42:30] <mru> it's a tradeoff
[10:42:48] <saste> mru: ffmpeg is fine... that's why we love it :)
[10:43:12] <mru> saste: I told you _not_ to enable the test just yet
[10:43:27] <saste> saste: I know.. I won't do that
[10:43:35] <mru> oh, sorry.. /me is confused
[10:46:55] <mru> I was looking at what I thought was svn but was in fact my local stuff
[10:48:30] <CIA-92> ffmpeg: mru * r24646 /trunk/tests/lavfi-regression.sh: Remove temporary files in lavfi-pixfmts test
[10:48:46] <mru> there, that saves >1GB of disk space
[10:49:00] <mru> saste: btw, why do you output to nut in these tests?
[10:50:38] <saste> mru: nut is the only container which supports *all* the rawvideo pixel formats
[10:50:56] <mru> rawvideo?
[10:51:03] <mru> -f rawvideo doesn't work?
[10:51:31] <saste> nut also supports timestamps...
[10:51:44] <mru> ah yes
[10:51:48] <mru> and filters can mess with them
[10:51:54] <mru> or mess the up at least
[10:51:58] <mru> +m
[10:51:59] <saste> exactly
[10:54:30] <peloverde> Compn: Thanks for adding MTS2 to MPlayer
[11:20:14] <Compn> peloverde : i only tested it on winxp, itd be nice if someone could test it on linux ...
[11:20:27] <mru> what's mts2?
[11:20:32] <Compn> the dll file is in samples/drivers32/new/
[11:20:57] <Compn> mru : another microsoft screen codec
[11:21:33] <Compn> er drivers32/newcodecpack
[11:26:54] <mru> saste: http://git.mansr.com/?p=ffmpeg.mru;a=shortlog;h=refs/heads/lavfi-test
[11:31:30] <saste> mru: fine if you prefer like that
[11:31:49] <saste> mru: indeed I never loved too much those get_ sh functions
[11:31:59] <mru> I prefer using standard tools over adhoc shell functions
[11:34:02] <saste> mru: maybe you want to wait for the lavfi-pixfmts test split before to apply the reference file
[11:34:10] <mru> sure
[11:34:26] <saste> mru: i'll post the patch this evening now I'm almost leaving
[11:35:53] <CIA-92> ffmpeg: mru * r24647 /trunk/tools/lavfi-showfiltfmts.c: lavfi-showfiltfmts: print one format per line
[11:35:54] <CIA-92> ffmpeg: mru * r24648 /trunk/tests/lavfi-regression.sh: Simplify lavfi-pixfmts test script
[12:29:55] <CIA-92> ffmpeg: mru * r24649 /trunk/tests/fate.sh:
[12:29:56] <CIA-92> ffmpeg: fate: make tar command configurable
[12:29:56] <CIA-92> ffmpeg: The 'tar' variable should be set to a command writing a tar archive
[12:29:56] <CIA-92> ffmpeg: of the named files to stdout, typically "tar c" or "tar cf -"
[12:29:56] <CIA-92> ffmpeg: mru * r24650 /trunk/tests/fate-run.sh: fate: fix signal name translation
[12:43:26] <siretart> good morning
[12:43:52] <mru> morning siretart
[12:45:11] <mru> bizarre bug of the day: http://code.google.com/p/webm/issues/detail?id=96
[12:45:31] <mru> libvpx can't be built in a directory called foo.o
[12:45:42] <mru> why anyone calls directories *.o is another question
[12:46:00] <peloverde> I hear you can't print the source on Tuesdays either
[12:46:40] <peloverde> I think it would be useful to normalize buildsystems across multimedia projects
[12:46:47] <mru> s/multimedia//
[12:47:00] <peloverde> I'm trying to start with a reasonable goal
[12:47:07] <mru> I've heard of a real bug where the code would crash if built on a wednesday
[12:47:37] <mru> someone put the build date in some file
[12:47:50] <mru> and wednesday is the longest weekday
[12:48:01] <mru> one byte longer than some idiot had counted
[12:48:53] <peloverde> file misidentified postscript files created on Tuesdays, keeping OO.o from printing
[12:49:22] <siretart> https://bugs.edge.launchpad.net/ubuntu/+source/cupsys/+bug/255161
[12:49:41] <siretart> for the record ;-)
[12:52:26] <peloverde> anyway mplayer and x264 seem unable to build out of tree
[12:52:43] * mru blames diego and Dark_Shikari 
[12:53:15] <mru> what kind of weird people build _in_ tree anyway?
[12:53:27] <peloverde> I have no idea
[12:53:49] <peloverde> especially for mplayer where it's useful to make both x86 and x64 builds due to the binary codec loader
[12:54:16] <peloverde> Also mplayer respects the CC env var while FFmpeg doesn't
[12:56:04] <mru> picking up variables from the environment is no end of trouble
[12:57:09] <mru> so I'd say it's less respecting and more being tricked
[12:57:28] <mru> but if people want it, I can add it
[13:12:31] <peloverde> I'd just like some consistency between projects that are closely associated
[13:12:48] <peloverde> IMHO the ideal solution is making the default compiler cc and not gcc
[13:12:58] <peloverde> what's so special about gcc?
[13:13:02] <mru> nothing
[13:25:03] <mru> hmm, gcc doesn't install ${cross_prefix}-cc
[13:25:05] <mru> only -gcc
[15:29:33] <CIA-92> ffmpeg: mru * r24651 /trunk/tests/fate-run.sh: fate: fix non-standard use of bc
[15:46:50] <siretart> mencoder acceted in debian: http://packages.qa.debian.org/m/mplayer/news/20100801T153332Z.html
[15:47:13] <Honoome> wow.. hell's freezing over?
[15:47:42] <mru> are those things in the sky... pigs?
[15:47:58] <siretart> indeed, seems like. this is a great debconf for everyone!
[15:49:01] * Honoome expects some terrorist to have rigged the debconf area and threatened Debian developers "you either start making sense or I blow you up"
[15:49:31] <siretart> heh
[16:14:02] <CIA-92> ffmpeg: mru * r24652 /trunk/configure: Fix suncc ident string (hopefully)
[18:06:40] <Dark_Shikari> BBB: your pextrd is slower because the number of instructions doesn't matter
[18:06:43] <Dark_Shikari> only the number of uops
[18:09:05] <Dark_Shikari> one good example of this is pmovzx
[18:09:12] <Dark_Shikari> pmovzx is often _slower_ than mov + punpck
[18:09:17] <Dark_Shikari> this seems unintuitive -- how could it be slower?
[18:09:23] <Dark_Shikari> even considering uops, it's no more complex
[18:09:33] <Dark_Shikari> the reason is because the CPU needs both uops (load and shuffle) at the same time
[18:09:38] <Dark_Shikari> i.e. during the same clock
[18:09:49] <Dark_Shikari> whereas if the unpack and load are separate ops, they can be done at separate clocks
[18:10:06] <BBB> I guess that makes sense
[18:11:11] <BBB> ok so I've done most of what I was planning on asm, I have two more left, one is to save the *9 in mbedge loopfilter and use that to calculate the 18/27 (you suggested this), might be a few cycles faster on mmx/sse2
[18:11:26] <BBB> the other is to not compile mmx/sse2 on x86-64 if a ssse3 func exists
[18:11:31] <BBB> since x86064 should always have ssse3
[18:11:36] <BBB> is that assumption correct?
[18:12:00] <Dark_Shikari> x86_64 always has sse2
[18:12:03] <Dark_Shikari> it does not always have ssse3
[18:12:05] <BBB> oh
[18:12:06] <Dark_Shikari> phenom, athlon 64
[18:12:16] <BBB> ok, then make that mmx/mmx2 funcs if a sse2 variant is available
[18:12:25] <BBB> shouldn't make it faster, but decreases binary size
[18:12:30] <BBB> which is a good thing
[18:12:33] <BBB> (and not vp8-specific)
[18:12:36] <Dark_Shikari> yes
[18:12:56] <BBB> I plan to do those two, then I'll start xp8
[18:13:01] <BBB> that name sucks
[18:13:06] <Dark_Shikari> xvp8
[18:13:09] <BBB> ok
[18:13:19] <Dark_Shikari> really though, x264 --vp8 is good enough for me =p
[18:13:33] <BBB> there is a limit to how much you want to annoy freetards
[18:13:41] <Dark_Shikari> no there isn't
[18:13:48] * BBB is in doubt :-p
[18:19:58] <Honoome> Dark_Shikari is right
[18:20:35] * kierank is starting to think this is not a joke ;)
[18:21:17] <Dark_Shikari> The best jokes are the ones that work on the largest scale.
[18:22:39] <_av500_> x264 --no-b-frames-but-golden-ones
[18:26:07] <siretart> mru: you said you can run fate on release branches, right? do we have an ia64 machine?
[18:28:17] <mru> siretart: it doesn't work on the 0.6 branch
[18:28:45] <Dark_Shikari> VP8 doesn't have slices, does it?
[18:28:47] <Dark_Shikari> at least not like h264 does
[18:30:41] <Dark_Shikari> BBB: http://pastebin.org/439085  started you off.
[18:34:32] <siretart> mru: what exactly doesn't work? fate or ia64?
[18:34:56] <Honoome> siretart: I'd expect 0.6 does not have "make fate"
[18:35:32] <siretart> ah, well, I guess we can fix that
[18:36:17] <BBB> Dark_Shikari: cool, thanks!
[18:36:55] <Dark_Shikari> oh, the other thing we'll have to deal with is the API (x264 returns NAL units, vp8 doesn't have NAL units)
[18:37:01] <Dark_Shikari> my guess is that we should just make each frame one NAL unit
[18:37:18] <Dark_Shikari> maybe separate NAL units for the stream headers, if there are any
[18:42:41] <mru> and _call_ it nal units
[18:44:58] <Dark_Shikari> well obviously
[18:45:43] <BBB> it'll work, and terminology could be optimized for various purposes
[18:45:51] <BBB> e.g. accuracy, freetard annoyance
[18:46:01] <BBB> whichever you prefer
[18:46:09] <BBB> (those aren't mutually exclusive :-p)
[18:46:43] <mru> I'd say they are strongly correlated
[18:47:27] <BBB> hehehe :)
[20:04:22] <kierank> lol "Encode output as VP8 instead of H.264"
[20:04:44] <spaam> \o/
[20:04:46] <kierank> something very bizzare about that line
[20:09:04] <mru> hi Yuvi
[20:09:23] <Yuvi> Hi mru
[20:09:36] <mru> lots of interesting new failures on the new fate
[20:09:47] <mru> e.g. solaris hates atrac
[20:10:02] <mru> and bsd hates vorbis
[20:10:31] <Yuvi> Poor libm implementations?
[20:10:33] <Honoome> fun about bsd, that's fbsd I guess?
[20:10:38] <mru> Yuvi: worse
[20:10:45] <mru> doesn't look like libm at all
[20:10:51] <mru> bitstream parsing is going to hell
[20:10:59] <Yuvi> Ewes
[20:11:34] <mru> http://fate.ffmpeg.org/report.cgi?slot=x86_64-openbsd-gcc-3.3.5&time=20100801165213
[20:11:54] <Honoome> ah openbsd
[20:11:59] <Honoome> good luck with that
[20:12:07] <Honoome> it probably considered the bitstream too unsecure
[20:12:16] <mru> netbsd passes
[20:12:29] <mru> freebsd has similar errors
[20:12:56] <mru> and dragonfly
[20:14:13] <Honoome> gha I forgot dragonfly even existed for a while
[20:14:18] <Honoome> thank you for giving me nightmares again!
[20:14:40] <mru> MirOS ftw
[20:14:48] <mru> PC-BSD!
[20:15:03] <Yuvi> I'd blame gcc 3.3 but thAt's only openbsd
[20:15:06] <Honoome> at least g/fbsd only handled package management differently
[20:15:27] <mru> omg http://en.wikipedia.org/wiki/List_of_BSD_operating_systems
[20:15:35] <mru> I didn't know there were _that_ many of them
[20:15:41] <mru> someone ought to do something
[20:15:45] <Dark_Shikari> THEY'RE BREEDING
[20:15:50] <Dark_Shikari> like rabbits
[20:16:12] <janneg> peloverde: ping
[20:16:43] <mru> dragonfly has already produced spawn of its own
[20:18:35] <janneg> mru: http://en.wikipedia.org/wiki/List_of_Linux_distributions is at least 3 times as long
[20:19:03] <mru> the difference is I can't actually tell the difference between the bsds
[20:21:06] <mru> the BSDs mainly differ in which system tool is the most outdated
[20:21:45] <Honoome> openbsd -> gcc!
[20:44:19] <lu_zero> openbsd -> everything!
[20:44:33] <lu_zero> netbsd -> depends on the moonphase
[20:44:46] <lu_zero> freebsd -> bleeding edge to be nice
[20:44:47] <mru> phase of the moose...
[20:45:05] <lu_zero> that's openbsd
[20:45:53] <lu_zero> and much depends if the moose got prepared correctly and the beer was good otherwise you will see repercussions for the next year
[20:50:52] <janneg> kierank: latm/loas demuxer patch sent to ffmpeg-devel
[21:42:09] <kierank> janneg: looks good
[21:46:08] <Honoome> wow.. running updates on a fedora 13 fresh install brings in libpvx
[22:15:24] <Rathann> Honoome: why is that such a big deal?
[22:15:52] <Honoome> Rathann: I wasn't expecting for it to be already in f13, surprised, positively so
[22:16:07] <Rathann> in fact it's in F-12 too
[22:16:17] <Honoome> even more surprised then :)
[22:16:40] <Rathann> we do introduce new packages into all supported releases if it's possible
[22:40:17] <Honoome> Rathann: on a slightly-related note, are there f14 install media betas around? I'd like to check if one problem I found in the f13 installation is gone or I should report it
[22:41:40] <ohsix> should probably post regardless, no? then someone from that team can triage it or mark it fixed
[22:42:35] <Honoome> ohsix: as a distro developer myself I wouldn't mind when somebody tests the stuff before reporting anyway ;)
[22:43:18] <ohsix> sure; but you cant mark a bug that doesn't exist as "fix this", and generally "reminders" don't leave local todo files ...
[22:43:39] <Honoome> eh?
[22:44:22] <ohsix> its better that someone file a bug first even if it will immediately be marked fixed
[22:44:35] <ohsix> or marked any other foregone outcome
[22:45:37] <Honoome> different feeling, and since I usually follow the golden rule, I'm following the way I would want my users to follow
[22:45:50] <ohsix> oog
[22:47:16] <ohsix> you can't know what people don't report; and i'd rather have skilled people do triage than try and train all people who might report bugs to report "good bugs"
[22:48:22] <Honoome> well, I seriously try not to file bugs around without reasoning behind
[22:48:49] <Honoome> so _if_ there is any f14 install media beta, I wouldn't mind taking a peek if it's still there or not; if there isn't, I'll file it as it is
[22:49:00] <Honoome> I've just asked _if_ there is that or not
[22:49:25] <ohsix> as to that, i thought f13 was still rawhide; that would be the beta
[22:56:37] <_skal_paris_> http://pastebin.org/439686
[22:56:48] <_skal_paris_> BBB? Yuvi? Dark?
[22:57:12] <mru> this is rather amusing: http://www.openbsd.org/cgi-bin/cvsweb/ports/graphics/ffmpeg/Makefile?rev=1.55
[22:57:37] <mru> --disable-optimizations
[22:57:44] <mru> GOOD JOB
[22:58:24] <ohsix> thats how demons get in
[22:58:47] <mru> and then they put back -O1 for a few files that don't build otherwise
[22:58:59] <mru> those guys are insane
[22:59:20] <lu_zero> we know already
[22:59:40] <Dark_Shikari> _skal_paris_: is it faster?
[23:00:06] <_skal_paris_> no, it's safer
[23:00:21] <Dark_Shikari> why
[23:00:26] <_skal_paris_> vp8_coeff_band[16] was accessed otherwise
[23:00:31] <_skal_paris_> ->kaboom
[23:01:24] <Dark_Shikari> my intuition says it's faster
[23:01:26] <Dark_Shikari> commit it
[23:02:04] <Dark_Shikari> or, well, at least as fast.
[23:02:13] <ohsix> my 1d10 sez 7, so don't
[23:02:30] <Dark_Shikari> make sure it passes regressions, etc
[23:02:43] <Dark_Shikari> make sure the same problem doesn't exist in the other branches
[23:02:48] <Dark_Shikari> and make sure the branches handle that case consistently
[23:03:35] <_skal_paris_> testing speed...
[23:03:42] <_skal_paris_> fate is ok
[23:04:59] <CIA-92> ffmpeg: stefano * r24653 /trunk/configure: Implement set_ne_test_deps() and use if for the lavfi pixdesc test.
[23:05:00] <CIA-92> ffmpeg: stefano * r24654 /trunk/tests/lavfi-regression.sh:
[23:05:01] <CIA-92> ffmpeg: Split lavfi pixfmts test.
[23:05:01] <CIA-92> ffmpeg: Introduce the function do_lavfi_pixfmts(), and use it for generating a
[23:05:01] <CIA-92> ffmpeg: pixfmts test for each different filter.
[23:05:01] <CIA-92> ffmpeg: stefano * r24655 /trunk/tests/lavfi-regression.sh: Reindent.
[23:07:50] <saste> mru: I'm waiting your OK for enabling the le lavfi pixfmts tests
[23:08:38] <mru> saste: ok now
[23:09:24] <_skal_paris_> crap, it's slower
[23:09:35] <ohsix> 1d10 wins again
[23:10:46] <Dark_Shikari> _skal_paris_: how did you measure?
[23:10:56] <_skal_paris_> decode_mb_coeffs()
[23:10:58] <Dark_Shikari> and what's the stdev?
[23:11:03] <_skal_paris_> too much
[23:11:19] <_skal_paris_> lemme try something else
[23:11:19] <Dark_Shikari> if the stdev is high you can't say "it's slower" confidently
[23:11:29] <Dark_Shikari> just commit it
[23:11:37] <Dark_Shikari> any speed change is from rerolling the gcc random code generator
[23:12:31] <ohsix> it is kind of silly to micromanage speed gains when you are dealing with gcc in the end; should only do that with refactoring D:
[23:13:44] <_skal_paris_> k, committing
[23:16:39] <Rathann> Honoome: alpha images should be available soon
[23:17:18] <mru> Dark_Shikari: http://26-26-54.hardwarebug.org/?id=7
[23:18:24] <ohsix> at least its deterministic
[23:18:48] <mru> for same input, yes
[23:20:58] <CIA-92> ffmpeg: skal * r24656 /trunk/libavcodec/vp8.c: prevent access to vp8_coeff_band[16]
[23:21:36] <CIA-92> ffmpeg: stefano * r24657 /trunk/ (6 files in 2 dirs):
[23:21:36] <CIA-92> ffmpeg: Add lavfi-pixfmts LE tests.
[23:21:36] <CIA-92> ffmpeg: The corresponding lavfi-pixfmts BE tests are not yet added, as there
[23:21:36] <CIA-92> ffmpeg: are some bugs in the scaler (scaling rgba, argb, bgra, abgr, yuva420p)
[23:21:37] <CIA-92> ffmpeg: which result in differences with the LE reference, and I cannot
[23:21:37] <CIA-92> ffmpeg: visually check the generated files on BE.
[23:25:34] <ohsix> they should add something to bisect the compiler passesl ike you can with git so pinpointing problems can be done by people who aren't trained to do it
[23:30:33] <mru> saste: did you test your patch?
[23:30:50] <saste> mru: of course
[23:30:56] <mru> fate says you didn't
[23:31:26] <saste> mru: i'm looking at that
[23:32:47] <mru> eh, I know why
[23:32:52] * mru blames self
[23:33:05] <mru> no, /me blames saste
[23:33:13] <mru> it was fine when I wrote it
[23:33:42] <saste> mru: do you know what the problem is?
[23:34:11] <saste> mru: I see only the vflip test is failing... apparently because it cannot rm some files which don't exist
[23:35:18] <mru> fixed
[23:35:39] <CIA-92> ffmpeg: mru * r24658 /trunk/tests/lavfi-regression.sh: lavfi-regression: use different temp file names for each pixfmt test
[23:35:48] <mru> at least I got to test my red hilight on increased failure
[23:37:47] <saste> mru: make -j 4?
[23:37:57] <saste> mru: that explains
[23:38:01] <mru> only -j2 iirc
[23:38:04] <mru> but that was enough