SGI: Development

Sent an updated version of MPlayer and some libraries to /incomming.

This version is a small modification to the existing distribution with the following changes:

- The CSS code has been "backported" into the mainstream libdvdcss source, and MPlayer now uses external versions of libdvdcss, libdvdnav, and libdvdread instead of mpdvdkit. This esentially means we now have modern DVD access libraries available on this platform, and I'm working to to make use of them with a modern MPlayer. These three libs are used by all of the manstream Linux media players, AFAIK.

- DTS audio support was added. This will eliminate the white noise barrage on titles such as FOTR during the transitions during certain chapter breaks, etc. MPlayer is now able to handle all DVD audio formats used by movie disks.

Compatibility is now 100% on all the commercailly pressed DVDs I've tested.

Review the release notes, as the DVDGENDEV variable has been changed to DVDCSS_GENDEV to maintain consistency with other variables used by libdvdcss.

I took _extreme_ care to make sure this is a 1:1 drop-in replacement for the existing (excellent) MPlayer/libdvdread. All the original material and patches have been retained in the .tardist. Please test and report any problems.

neko_libdts-0.0.2.tardist
neko_libdvdcss-1.2.9.tardist
neko_libdvdnav-4.2.1.tardist
neko_libdvdread-4.2.1.tardist
neko_mplayer-1.0rc1-1.tardist

I have a GTK1 version of the mplayer binary avail also, but I don't know what the consenus here is WRT to this toolkit so I'll keep it out of a nekodist for now. This is what I use myself as bringing up the menus won't bog the whole player down, etc.

http://home.ix.netcom.com/~jjingber/mpl ... tk1.tar.gz

Axatax wrote: Sent an updated version of MPlayer and some libraries to /incoming.

I'm sitting in front of /incoming like the RCA Victor dog ... thank you very much, ax. Can hardly wait to get this on the disk.

Out of curiosity, there was some friction within the mplayer group about multi-processor support. There was a fork to develop multi-core, then I read that MPlayer had relented and added better multicore support themselves.

Is that factual ? If so, this one should be even better for 2p SGI's than the prior version.

Thank you!! This is highly appreceated! Now I have to get myself an SCSI DVD. that I want to try out! Cool!

Out of curiosity, there was some friction within the mplayer group about multi-processor support. There was a fork to develop multi-core, then I read that MPlayer had relented and added better multicore support themselves.

Is that factual ? If so, this one should be even better for 2p SGI's than the prior version.

Keep in mind this is the same version of MPlayer, just with updated DVD libraries.

I'm actually working on the latest MPlayer, which is why I split these libs out of the old build.

I don't envy you! I helped back on the original mplayer ports (did some of the platform-specific code to get things playing faster on these machines) and have a few nightmares of the pain...

Axatax wrote: Sent an updated version of MPlayer and some libraries to /incomming.

Finally got it ! Hooray ! thanks jp, I kept looking in all the wrong places.

but alas, much sadness in Mudville



Oh poo


so ...

Oh where oh where is my version sgi4.0 ? Plus now I can't watch George and Ron smack each other around for twenty minutes

Mr Axatax, are you out there somewhere ?

Hamei, it looks like you've got the libdvdread package from /beta installed. All the libdvdread.so.4* files are just symlinks to the version 5 library in that package. Check with 'ls -l'. Also, if you do 'elfdump -L /usr/nekoware/lib/libdvdread.so.5.2' you'll see in the IVERSION field that it is indeed sgi5.2 (or similar) instead of the sgi4.0 that mplayer is looking for.

I'm guessing that Axatax linked mplayer against the version of libdvdread from /current instead of /beta. And this looks like one case where the library symlink trick isn't good enough. The runtime linker is looking inside the library for version numbers rather than just at the filename. In that case, there's a problem (IMHO) with the dependencies in the mplayer beta package: it should depend on neko_libdvdread serial number = 1 rather than >= 1. Or, if the newer libdvdread package is compatible, the binary could be re-linked to it.

That's weird, since wasn't the point of this release that he moved it to the new separate libs?

Well shee-(expletive deleted) ...

So the original problem was my fault, there are two mplayer versions, one with a gui and one without. I got them mixed together so one of each was present. Bad bad

Fixed that.

Now ...

libspeex ? wtf ? Not in current, not in beta. Here it is, whoopee

http://www.speex.org/

It's been outdated by Opie that's better in every way but I ain't going there ...

So, speex-1.2rc1,

./configure--prefix=/usr/nekoware

looks okay until the very end


"getopt_long", isn't that kinda normal ? Should be easy to fix ?

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 included ...

About to step off the high dive here, ref :

viewtopic.php?f=15&t=16726751

and

http://www.gnu.org/software/gnulib/MODU ... topt-posix

can I just put the #include <unistd.h> into whichever pos is using getopt_long then place the .c and .h files into the relevant directories ?

'spose I could just try it but would like to understand the principles ...

On the off chance that this would be helpful to someone who knows what they are doing ...

This version does need libspeex. I guess in the confusion Axatax forgot to build a tardist.

Libspeex is weird (to me, anyhow.) It has an if-def to create getopt_long already, but I couldn't get it to work. However, by accident I built it ./configure but without the --prefix=/usr/nekoware flag and it couldn't find Ogg. Why ? that's totally strange. But then it commenced to build the library without the encoder and decoder. Fine, at least it's a step forward and Mplayer v 1 never had speex. Opie is better in every way anyhow.

Built the library, manhandled it into /usr/nekoware/lib and .....


This could be an optical illusion but I think it's better. Slightly sharper, sound seems cleaner. And it is a first step on the way to updating the base code of MPlayer while still keeping the SGI enhancements we already had.


To me, this is a worthwhile project. Calling all coders, man your stations ! This is not a drill ...

(If you are not afraid of the devil, attached are the libspeex libraries and links I built. Put them into /usr/nekoware and the beta MPlayer should work. This is not a good permanent solution but if you don't have a compiler and want to play ...)



Hmm. Only one file is supposed to be a file, the other two are links but zip turned them all into files. Anyway, it's just for testing so ....

hamei wrote: libspeex ? wtf ? Not in current, not in beta.

Anybody want to chip in to buy hamei some new reading glasses?

There is indeed a neko_speex-1.2rc1.tardist file in beta and it looks like it's been there for more than 5 years. (It's dated 24-10-09!) There's an even older neko_speex in current, too.

jpstewart wrote: Anybody want to chip in to buy hamei some new reading glasses?

Or maybe a brain

I'll be a monkey's uncle , it's hiding right there in plain sight as speex, not libspeex !

Gottit installed, runs about the same as with my phony one. Cool. Better than cool, this is a real tardist. Have to look and see how they got around the getopt_long thingy ...

One hit against the MPlayer beta, it doesn't list speex as a requirement. Other than that tho ... so far so good --


Mr Vegac, while you're here, can you expound on this ?

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.

Hmmm...when I get back next week maybe I'll start looking at this...
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

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.

Axatax_ wrote: 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.

Have you looked at Open264 instead of the x264? I dunno if that will run faster on these ancient computers, but its always worth a shot to see.