What platforms should FATE test? So far, it is testing both x86_32 and x86_64 under Linux and Mac OS X, and PowerPC under Linux. These are the first and foremost platforms I care about, and have access to.
What other platforms would people like to see tested through FATE? Windows? *BSD? Solaris? Linux running on exotic bits of hardware? Game consoles? Well, I have great news: After many months of occasional work on the FATE infrastructure, I am confident that the system is in a shape where other people can run the core FATE script and submit results back to the main server.
I have released the first public version of the script at the core of FATE: fate-script.py. Anyone can run it locally on their own platforms, but it requires a few credentials (assigned by me) in order to submit results to the server.
Feedback is very welcome, as are offers to run FATE continuously on other platforms. Also, I would love to know how to properly version something with git. All I can say is that the currently posted version of fate-script.py is version 67eac48073a24deece52cb28fbb25c14858b6c23.
Though this is not an offer (yet), I’d like to see Linux/ARM and Windows/x86
Yeah, I thought that those would be popular requests. Fortunately, I have someone lined up who is eager to set up FATE for all manner of Cygwin and MinGW configurations. MSVC configurations would be another matter, though.
Could you add a hint what size the fate-suite is?
Might be helpful for people like me who have too small disks.
I’m still thinking if I could run it on my OpenWRT MIPS routers – of course I’d have to either cross-compile or use NFS – last time I tried NFS performance was just unusable even over 100 MBit/s Ethernet, no idea why NFS never works for me…
I have also been working on a linux-mingw crosscompile + wine environment for testing MPlayer.
All of these might not be too useful for FATE though, since none of the stuff I have running 24h/day has enough disk space…
Testing against OpenBSD would be great, the current SVN does not cleanly compile due to a number of issues.
The changes that have historically been made can be found at
http://www.openbsd.org/cgi-bin/cvsweb/ports/graphics/ffmpeg/patches/
But those patches are against 20080620
ffmpeg still needs to be changed to work with V4L2 on OpenBSD/non Linux style shared libraries and perhaps a few other things besides.
Well, as usual quite a large parts of the OpenBSD patches are
1) cosmetics
2) workarounds about parts where OpenBSD does not follow POSIX
3) changes due to stuff that OpenBSD changed in other packages (?)
4) possibly wrong
5) are split by file instead of by issue which just makes no sense at all
I don’t doubt there are good parts in there, but is there any documentation for those patches? The CVS log messages at least are quite useless.
I fear if the OpenBSD guys do not make an effort none of these will be included any time soon…
I can test on Linux/ARM. Does the test script support launching commands over ssh?
Reimar, clearly you haven’t read the patches recently but are instead going on what appears to be an ffmpeg-devel thread from
November.
INFINITIY has been defined for over 4 months in OpenBSD.
OpenBSD people do push patches to ffmpeg where appropriate,
in particular Jacob Meuser. The problem is things seem
to keep breaking after they are fixed.
@Jonathan:
No I have looked at the patches you linked to.
Just out of the configure stuff, there is the “nm -P” thing, a (without a comment) removed PPC dcbzl check, a commented out check for malloc.h, and a removed -Wl,-soname that all just look like somebody didn’t know how to fix it right and since they are without comment it means that nobody except the original author actually has a chance to do that.
I will admit that it is not specific to OpenBSD, it was a long fight to get the Debian MPlayer patches managed in a way that is at least somewhat sane.
I just have to honestly wonder, if the main FFmpeg port maintainer were to disappear, who could take over? Is there any who knows what even half the modifications in the patches do and why they are there? If yes, where is that information? Can this be made public to the benefit of all, including your own users?
I had a quick look, and I agree with Reimar, those patches are a total mess. On the bright side, the Attic looks much worse.
@Reimer: On my local system, the fate-suite is presently about 220MB, although someone recently fetched all the samples and found it to be around 170MB. I’m not sure where the discrepancy is; perhaps I have a bunch of samples staged but not uploaded.
Mans: The script is not currently set up to execute remote commands, but I have some ideas on how to hack it to do just that. So I am clear on the goal, would you want to cross-compile the ARM binary on a separate machine and then send it over to the ARM hardware? That could all be done in a build line. Then I suppose I could modify fate-script.py to prepend ‘ssh -credentials’ to each command.
Also, any interest in running the script on your PS3/Linux installation? Only during the 167 hours/week that you’re not playing it, of course. :-)
@Jonathan: I don’t really understand why V4L2-supporting programs should have to be tweaked to support V4L2 on OpenBSD. I would hope that OpenBSD provides compatibility so that app authors don’t have to worry about it. Though you mentioned something about shared library loading, so maybe this doesn’t have to do with API matters.
You should be able to disable the V4L2 systems for compiling on OpenBSD. That’s the compromise I make on x86_32/Mac OS X to work around the infamous register starvation problem– the build configuration line specifies “–disable-decoder=cavs”.
@Jonathan: I had a quick look, these patches are unreviewable and mysterious. We can and will review and apply patches that are sent to us, so please encourage your porters to collaborate with upstream.
@Mike:
You might also a a “prerequisites” list. I’m trying it with OpenSolaris, but have some problems. I guess python 2.4 is probably a bit too old. I’ll just try installing a newer version after I got the compiler and samples installed (yeah, to get over a 150 GB/month download limit I’d need a 34 day month first!), but it’s good to know the “working configuration” :-)
Hmm? The first sentence from http://fate.multimedia.cx/running.html reads, “A prerequisite to running FATE is Python 2.5.” Maybe I could have made it clear that that running.html page is the home page for FATE instructions, rather than, say, this blog post. I don’t like it when random blog posts serve as the homepage and distribution points for software.
Also, I’m not sure what you meant with the samples, but be advised that the fate-suite/ branch encompasses hundreds of megabytes at this point, not gigabytes. Running FATE does not entail downloading the entire mphq samples archive.
It’s just me not reading properly, sorry. I was also confused because I did not complain about sqlite but some missing email stuff.
Well, I’ll see how it works out soon enough.
I suspect the reason that it complained about the email stuff was because that comes before the sqlite3 module in the list of imports. (For the curious, the “email stuff” is needed for Base64 encoding.) Python would have complained about sqlite3 eventually.
Thanks for your persistence in this.
It is not of much use so far. Once upon a time Solaris CC would compile most of FFmpeg. Nowadays it crashes on every single file as soon as -D_POSIX_C_SOURCE=200112 is on the command-line.
And even without it it seems to crash at every inline assembly code…
Mac OS X PowerPC, you do have a Mac Mini, don’t you? Or do you have one with an Intel processor?
I have 2 Mac Minis: one PowerPC and one Intel. However, the PowerPC one is all Linux.
Well, how about adding a small Mac OS X partition then? :-)
It would be easier just to procure another PPC-based Mac Mini.
Or, I suppose I could cross-compile a Mac/PPC version on my MacTel box, as dconrad succinctly explains here.