The collected works of Axatax_ - Page 1

Hey guys -- this is the old "Axatax". Sorry for not following up on this. I just moved so have been offline for awhile. My PW for my old account is on a machine I'm nowhere near @ the moment.

Beside the speex dependency, is there any other major issues with this package? I can fix the speex issue and U/L a better .tardist for beta.

I'd like to know if there is anyone else besides Hamei that has tried this release.

If you're really feeling brave -- when you get the MPlayer from beta installed, you can try the following patches and maybe LMK how it's working for you (you need all the MPlayer beta suff installed first). This is my work on the 1.1 MPlayer branch. It's not complete/perfect yet, which is why I'm not sending a .tardist at this time. DVD playback from physical media does work quite nicely, however --

http://home.ix.netcom.com/~jjingber/nek ... irix.patch
http://home.ix.netcom.com/~jjingber/nek ... irix.patch (this one is somewhat sloppy, as I couldn't figure out how to translate those two large macros in pixel.c -- the library works, however).
http://home.ix.netcom.com/~jjingber/nek ... irix.patch

Patches should be up in a few mins -- gotta run over to another computer...

I'm guessing that Axatax linked mplayer against the version of libdvdread from /current instead of /beta.

Confused, as I don't have the dvdread from current on my system AFAIK. -- Is this is still an issue?

The stuff I sent to beta shouldnt't work with the /current libdvdread, as it requires libdvdcss (ie. if you can view commercial DVDs with the MPlayer in /beta, you're running the proper software stack). The new libs don't require libdvdcss, however, as libdvdread dlopen's libdvdcss at runtime. If the MPlayer from /beta can view commercial disks, the software stack is OK.

edit: I see the problem. gcc, we luvs you to death. Emphasis on the object of the preposition. If anyone smarter than me wants to hit this, it seems like the only thing standing between us and a fresher MPlayer with the Irix optimizations inclsuded ...

The above patches target MPlayer 1.1.1 w/MIPSPro (current "official" release as of this post), and do incorporate the previous IRIX optimizations. It was a helluvalot of work.

The issues with this patch that make it less than perfect --

- I haven't ported over the SGI-specific video output driver to the new MPlayer 1.1 VO driver format (working on this). I'm going to finish it, but I'm not convinced it's necessary WRT to the current MPlayer code base. The new OpenGL stuff seems to work like a champ.

- Crash when video post-processing is enabled.

- Crash when x264 video is restarted after a pause.

- Longstanding issue that won't stop me from doing a .tardist -- x264 is still ass. This really needs an expert to go through this (see next post).

Now, here's the really annoying thing --

Both libavcodec and libx264 have native MIPS assembly optimizations in the source tree now. The problem is, it's gcc inline-assembler targeting snapdragon/cell phone-type MIPS CPUs. The ASM could be backported to SGI MIPS with the translation of a handful of SIMD operations (and really, it's just a handful), but all of this needs to be moved to seprate files and broken out from the current C source. I'm looking into this now, but don't have many good examples to go by.

See if I can improve on my 10-year-old SGI vo code now that I can only assume I was so much worse back then

You guys that did the initial work are tops++!. MPlayer just got their *hit in order WRT X11 output drivers since the initial work on the Neko MPlayer. I'm a plagarist standing on the shoulders of giants... -->> but itching for a new MPlayer Help me out.

The newer x264 w/MPlayer 1.1.1 can passibly play 480p on my dual 600 Octane with some command-line kung-fu.

Now that I know you guys are still down with this, I'm going to package up the MPlayer 1.1.1 and maybe you guys can give it a spin (with the understanding it's not 100% yet).

I'm not going to do a whole .tardist yet, just the binary and new x264 lib you can run from a seperate directory.

Works for me, as well as your Xft. Thank you!

ED: If you're using GTK2 apps, this is quite an improvement.

OK,

I've uploaded neko_mplayer-1.1.1.tar.gz to /incomming.

I don't have any more personal space to host this file (I have 10MB on my FTP, and this file is like 15MB). Hopefully someone with mod. access can do something with this, or someone else can provide some web space (maybe an Axatax directory on the FTP site )

Anyhow, this is the latest and greatest MPlayer for IRIX.

1. Install and get the MPlayer in Nekoware /beta working with all dependencies (libdvdread, libdvdnav and libdvdcss).
2. Install neko_gnomeicontheme-2.10.1.tardist from /current.
3. Untar MPlayer-1.1.1.tar.gz into /usr/local (has to be here for now).
4. Run /usr/local/MPlayer-1.1.1/run-mplayer.sh, and you should be good to hook.

This is beta, probably alpha stuff, and the latest patches are included under the /patches directory.

If this totally sucks for you, please get your head into the code and help make this awesome. There's really just a *few* total show-stoppers with this patch, but I'm nearing the end of my abilities with this. Help out. Help everyone here out.

Neko,

Thank you very much!


Guys with the issues --

The other 2 libs (libdca and the new libx264) are in the that archive. How are you launching MPlayer? There is a shell script in there that should set the library path and run MPlayer. The patches for libdca and x264 are also included. If you're having trouble building these, make sure you've patched them.

I'm just going to make a tardist to make this easier. Give me a an hour or so to wrap this up (I've already done the .spec/.idbs -- just gotta packge it).

Please go over the shell script and make sure the library paths are correct for your setup. libdca/x264 should be in /usr/local/MPlayer-1.1.1/lib. Your system is not finding libdca for some reason. Maybe try moving the contents of /usr/local/MPlayer-1.1.1/lib into /usr/local/lib and try again...

An hour was optomistic for those packages -- Brain is fried.

ETA sometime on 1/27.

yay ! It plays ! Don't have enough time in to make comments but one small step for man, one giant leap for mankind

.. Well, that's exactly what it is -- a very small step. It's MPlayer 1.1.1 that works on IRIX. It still needs quite a bit of work (and I'm working on it, and I hope other ppl. here will too...)

I'm packaging up this release now as *.tardists.

Because you are such a nice person I will not scald you with the dragon-breath fricasee /usr/local on my computer is the gateway to Hell, abandon all hope, ye who enter here ...

That's just habit. I put self-compiled stuff in /usr/local, and commerical SW in /opt.

Hamei -- What fonts do you currently have installed?

You guys are gonna have something today. There's just alot of puzzle pieces to this SW and I want to make sure it's done right the first time, and it can co-exist with the 1.0* MPlayer. 16p O300 is burning the midnight oil right now re-building this until it's acceptable.

I'm getting this SW into the position we can do nightly builds or whatever with relative ease.

Longshot here, but you think that eventually you can port the MPlayer fork mpv - people have been saying MPlayer is dying

Maybe -- ft this a spiritual successor to MPlayer. I'm going to check it out.

OK guys --

I just sent a metric ton of updated packages to /incoming relating to this project. Sorry for the delay on this -- getting the dependencies correct to work with both old/new MPlayers are somewhat of a challenge.

There's also a new "old" MPlayer that corrects the speex dependency and corrects some other Q/C-type issues -- LMK if this works OK.

Everything should be a 100% drop in/clean update if I handled this correctly. Please test and let me know.

If you want to play with the new mplayer, the .tar.gz in my directory still pertains. This is going to be a proper .tardist soon, but there's alot of "parts" to this, and I want to get it into a state where I can essentially automate routine builds of this.


Thanks for hanging in...

Sent the xscreensaver 5.32 and rss-glx update to /incomming.

Hey, all -- I appreciate the testing.

Let me clarify what's going on here WRT to all these packages in /beta.

There's effectively three branches of MPlayer now --

1. There's the MPlayer 1.0rc1 in /current - all of the dependencies are satisfied with packages in /current. Circa 2006. Stable branch.

2. There's the MPlayer 1.0rc1-1 in /beta. This requires libdca, libdvdcss, libdvdread, and libdvdnav from /beta. Same branch as /current, but with updated DVD libraraies. If you don't play DVDs off of physical media, this branch is probably not an upgrade from #1 above. It's a **big** improvement for DVD playback off of physical media (I'm batting 100%)...

3: The MPlayer 1.1 link here: ftp://ftp.nekochan.net/pub/downloads/co ... 1.1.tar.gz . This is the latest and greatest MPlayer, and requires the libdca, libdvdcss, libdvdread, and libdvdnav from /beta. This is not a .tardist. You need to install this into /opt and run the included shell script.

These can be removed from /beta, as the current packages effectively obsolete them, and are compatible with both the 1.0 and 1.1 branches --

neko_libdvdcss-1.2.9.tardist (replaced by -r1)
neko_libdvdnav-4.2.1.tardist (replaced by -r1)
neko_libdvdread-4.2.1.tardist (replaced by -r1)
neko_libdts-0.0.2.tardist (obsoleted by libdca, which is compatible with libdts)

I've made a patch for xmms-timidity++ if you want it. LMK.

I don't know if jscrew is still around?? I got my 2x 600 from him for something right around US $250 a few years ago (from a post on this forum).

No idea what the prices are now.

One question tho - any predictions on the -vo sgi feature ?

It'll be there in the next drop of MPlayer 1.1 which will also be a .tardist. I just didn't prioritize this becase I wanted a working 'proof of concept' build and the GL2 renderer was good enough for this.

If one other person would try this hummer out we could move to /current ... the original was excellent (I use it all the time), this one does not go backwards in any way but adds some features for playing from DVD ....

We should already have the 3+ person consensus. This latest drop just added the speex dependency.

Alright -- since you're really interested in this...

I also have an IRIX patch for xmms-JACK... This obviously requires JACK, which I've also worked out a patch for. I did this with the intention of eventually porting Ardour to IRIX.

Right now, I'm not packaging this stuff becase it's 'work in progress' and really convoluted, and I haven't touched it in awhile. JACK works as well as the XMMS plugin, but you'll have to patch and build the SW yourself.

LMK.

With better threading support ?

I didn't even see this...

On the 1.1 branch, you can try runnng it with -lavdopts threads=8 on 480p h.264 content (make sure you have the libx264 from /beta installed)...

"torrent"-type 480p content is _almost_ passible on my 2x600 Octane. Really -----> <----- this close (the audio gets out of sync with the video, but is otherwise passible). I watched the first two chapters of the Hobbit in 480p on the Octane, with sync issues. I bet a fast Fuel or Tezro could pull this off.

I now have two mplayers in the swmgr display but that is quite possibly because my installation is a mess.

Hmm, the .tardist in /beta should repace the current MPlayer cleanly... It does @ my site at least.

Will look into this.

One question tho - any predictions on the -vo sgi feature ?

I have it working now --

gonna try to make a .tardist in the next day or two (depending on schedule). I don't want to promise anything as I've botched that on the last two attempts....

But it always gets into /incomming......

Geez...

I didn't get no love for MAME here so I totally forgot about this thread...

LMK if anyone is still interested int this...

Just an update on this --

I'm now an "official" MPlayer dev., so hopefully the IRIX port can mirror the official releases going forward. There's been alot of "drug dealing" going on behind the scenes, and this has taken up some time -- right now, there's one person (or one and a half ppl.), agnosticising the MIPS assembler stuff in the newer libavcodec and x264. It's really about 90% there.

Just hang on a bit longer -- it's gonna happen... Haven't let you guyz wrong yet...

either way if the package does conform to the nekoware guidelines

See, that's the thing -- It was the first SW I U/L'd here, and it wasn't a .tardist, so I assumed it was just deleted when sent to /incomming (the intent wasn't to get it into the repository, but have it available for testing).

This was a complete MIPSpro/SGI port that probably took a good portion of two weeks. Unfortunately I no longer have any of this, as I deleted it after receiveing zero feedback on this... (and yes, I regret doing this).

The big issue is building MAME/MESS suite with MIPSpro takes over two days on a 2x600 Octane. If someone is going to work with this, they need access to a big Origin, etc. You can build Mozilla 6x over in the time it takes to build just the MAME portion alone under MIPSpro.

what a pity. you just threw away a 2 week's work?

I sure did, and that was dumb... But I didn't get any feedback on this, up until two days ago (year and 1/2 after the first post)....

Well, I guess the binary has been found if anyone wants to play with it....

Sorry guys...

wait wait, you had a complete working mame .149 or just the coleco mess binary that was found?

The last MAME I sent to /incomming was the whole .149 shebang built under MIPSpro -- the Coleco target was a test build, but was obsoleted by the former. It was the most recent MAME archive available @ the time I built these packages.

I'm really sorry I didn't keep this now, but nobody responded within 1.5+ years, and I'm working almost exclusively with MPlayer now.

Sorry...

unfortunately it seems to segmentation fault on neogeo and CPS1-3 games, not sure if there is something that can be done about that at this point...

While this is a "complete" MAME, alot of the systems will segfault due to endinaness issues that need to be manually corrected on a case-by-case basis. This isn't something that compiler warnings/errors can alert you to - you have to test each machine individually. Flagging an SGI as big-endian is not sufficent in the context of the MAME/MESS source.

You guys are really brave messing with this pile. Good luck.

out of pure curiosity, how does one do that specifically? I would love to learn more about the particular details since I am trying to tackle an older mame build at the moment with the hope of moving up to a more recent release in the near future

Shoot me a PM -- I think we can make this happen.

Does anyone know why GTK2 is so damn slow on IRIX?

You guys that have these machines -- would you consider trading a NeXTCube Turbo w/Dimension for a Crimson (I'd drive down to make the xchange -- anywhere in the US).

gtk2 is so damn slow everywhere

Yeah, kinda, but it's *really* bad on SGI. I have a 200MHz PentiumPro sh*tbox with a Matrox Millennium I (remember that thing -- it pre-dates the incorporation of 3Dfx by three years...). This system will slap my 2x600 Octane left and right running GTK2 apps. Something doesn't compute with GTK2... Missing X extension or Intel-optimized SIMD?? Something 'aint right.