mplayer 1.3.0

IRIX/Nekoware development, porting and related topics.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
hamei
Posts: 10476
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

mplayer 1.3.0

Unread postby hamei » Thu Apr 12, 2018 4:19 am

I finally put up an svn suppository for the most recent mplayer code. The one in nekoware is super but is kinda limited as far as some of the formats commonly used now, and also supposedly there have been improvements in the mplayer smp support. Multiple prodcessors are common in Irixland, so a newer version of mplayer might be nice ?

Maybe I am doing this backwards, maybe it would be more effective to start with the functioning irix-specific Mplayer and add newer parts, rather than trying to back down on the latest one ?

Thoughts and even criticism are welcome.

Anyway, anyone interested in messing with this is encouraged to pm me and I'll give you a userpass combo. Even basic skills are welcome, for things like stripping out the Tibetan language version and so on.

A Motif front end might be nice, Mr Vish ;)
2 + 2 = 5

Jack Luminous
Donor
Donor
Posts: 209
Joined: Mon Sep 26, 2011 12:59 am
Location: PARIS

Re: mplayer 1.3.0

Unread postby Jack Luminous » Thu Apr 12, 2018 6:15 am

That's an excellent move ! I was shocked when I discovered that I couldn't even play 720p videos using current mplayer on my dual 600 Octane 2. I think porting back from a newer version using parts of the old version might be easier than the opposite. 8-)
:Octane2: :Octane: :Octane: :O2:

User avatar
marshallh
Posts: 43
Joined: Tue Nov 03, 2009 12:53 pm

Re: mplayer 1.3.0

Unread postby marshallh » Thu Apr 12, 2018 8:25 am

current IRIX mplayer is somewhat able to play some 720p stuff on my 800mhz R16k. It seems to be totally uniprocessor only. Drops frames if VBR is too high.

IIRC the old mplayr doesn't even do h.264, though lots of these newer formats are a total beast on CPU and pretty much require dedicated decoder hardware.

User avatar
vishnu
Donor
Donor
Posts: 3361
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: mplayer 1.3.0

Unread postby vishnu » Thu Apr 12, 2018 11:56 am

Looks like my employers are blocking svn from work, I'll have a look when I get back to the homestead. But as for an mplayer frontend I've only ever used it from the command line, I've found sdl works best, which is to say mplayer -ao sdl -vo sdl filename.mp4 (or whatever format the file to be played is encoded as)...
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
hamei
Posts: 10476
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: mplayer 1.3.0

Unread postby hamei » Thu Apr 12, 2018 6:11 pm

vishnu wrote: ... as for an mplayer frontend I've only ever used it from the command line ...

I found that the easiest way was usually to just drop the file on the mplayer icon. But you know kids these days ... and, ya know, that Motif thing is kinda cool so ...

Rethinking the approach, maybe it's better to start from the working one and move up, rather than start from something that doesn't work and try to back out until it does ?

hmmm ....

marshallh wrote:current IRIX mplayer ... seems to be totally uniprocessor only.

That's why I have been watching the mplayer thing for ages. The original guys were like Mr. Loonus, "my program will never be multi-processor !" then it got forked to some somewhat smarter guys, who were retards in their own way, "our mplayer is going to get rid of all this worthless old cruft, like the Irix crap in here ..."

Anyway, according to rumour the smp stuff finally got incorporated into the main mplayer and lots of SGI computers have more than one p so ... the program itself is incredibly useful so seemed like attempting this is worthwhile.
2 + 2 = 5

computron
Posts: 178
Joined: Thu Apr 18, 2013 4:08 am
Location: france

Re: mplayer 1.3.0

Unread postby computron » Fri Apr 13, 2018 12:13 am

weird....

i was using Mplayer for ages, and it was multithreaded on my Onyx ..... i remember have played Divx with and have all the cpu partially used

Cheers

Eve

User avatar
hamei
Posts: 10476
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: mplayer 1.3.0

Unread postby hamei » Fri Apr 13, 2018 6:18 am

computron wrote:i was using Mplayer for ages, and it was multithreaded on my Onyx ..... i remember have played Divx with and have all the cpu partially used

I have a few versions of mplayer around - just checking with top, nothing sophisticated, there will be a main thread running at a reasonable cpu load and a second thread running a negligible load. I'ma gonna guess that one thread is the window and one is the program ?

For example, same video, a wmv; in the basic mplayer one cpu sees about 30% load (varying) while the other about .6% (static) on a 2p Octane 400. It plays okay but at intervals will go kaleidoscope for a moment. The other one, one of axatax'es, produces a ton of error messages about "invalid frame duration value" and displays chaos.

In other cases the axatax version plays better than the standard nekoware version.

These are bugs I'd like to see worked out.

Interestingly, neither version seems to stress the cpu that much. That subject is probably a place for someone who knows what he's doing to investigate.

About the smp, it's all speculation on my part based on what the "developers" wrote on their respective websites. There have been a few forks of mplayer. Both of them initially sounded great because they were both "we want better smp support." Then both did the same thing, "We don't need this old cruft ! Remove the antique operating system code, no one needs that !"

Yeah, thanks so much.

Anyway, what they said was, "we're gonna do better threading." And the later scuttlebutt was, that stuff got grafted back into normal mplayer when both those forks died an ignominious death.

But then, all the magazines said "Itanium is going to take over the world !" too, so maybe it's all just hot air.
2 + 2 = 5

shutitalldown
Posts: 126
Joined: Sat Feb 10, 2018 3:28 am

Re: mplayer 1.3.0

Unread postby shutitalldown » Fri Apr 13, 2018 7:03 am

hamei wrote:But then, all the magazines said "Itanium is going to take over the world !" too, so maybe it's all just hot air.


You know, magazines lie. But sometimes (rarely) they tell the Only One Saint Truth that nobody wants to hear: everything ever done up to now in computer science has always been one step ahead and two steps back.
Pointless reminders of the human ego:
  • arguing that you don't care about the right to privacy
  • because you have nothing to hide
  • is no different than saying you don't care about free speech
  • because you have nothing to say

User avatar
vishnu
Donor
Donor
Posts: 3361
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: mplayer 1.3.0

Unread postby vishnu » Fri Apr 13, 2018 9:25 pm

There was a similar explosion of forks (and flame wars) when Jörg Schilling insisted it was a mistake to multithread cdrtools. But in that case, I think he was right. I'm using mplayer 1.2.1-5.3.0 version of 2016 and it works incredibly well on my dual-Xeon linux (and yes, I know hamei is all linux-shminix), what version do you have svn-ed there, mr. hamei?
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
hamei
Posts: 10476
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: mplayer 1.3.0

Unread postby hamei » Fri Apr 13, 2018 9:42 pm

vishnu wrote: I know hamei is all linux-shminix

Not exactly. I think it's fine for people who want it. I just resent having it jammed down my throat ... when you tell someone "this doesn't build" and their reply is "works for me with gcc !" I want to slap their nose across the room.

One goal, btw, would be to repair the source so that the compiler detection code is eliminated. There is *no* excuse for limiting C source to any one compiler. Lowest-common-denominator standards, assholes. If-then statements for systems that have quirks, okay. But tricky shit that only works with gcc can hibernate where the sun she don' shine.

btw, that was one of the banners of preindustrial Loonix ... back when Mickey was the EEE non-standards standard-bearer :) Now that they themselves are the home of nonstandard crap, seems like their prioritites have changed. And not for the better.

what version do you have svn-ed there, mr. hamei?

Re-thinking this. 1.3 is the goal and what I already stuck up. And for pro-fessionals maybe that's the way to go - try it, find a problem, fix the problem, go to the next problem.

But to get more amatoors involved, perhaps start low and work up would be easier ? If we start with one that builds, then add something, test, and move on, is that easier than starting with someone known to not work and beating our heads against the wall ?

I'm undeceived on the amount of support this is likely to get. "we" perhaps applies to myself and the mouse in the back pocket.

Whatcha think ?
2 + 2 = 5

User avatar
vishnu
Donor
Donor
Posts: 3361
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: mplayer 1.3.0

Unread postby vishnu » Fri Apr 13, 2018 10:17 pm

Yes, gcc's extensions to the language are basically the FSF's way of telling the standards committee they should disband and just let RMS be in charge. :lol:

Years ago I used to compile my own version of mplayer because something they were doing was pissing me off, but I can't remember what it was and they must have stopped because I've been using the version that comes with my distro for a while now. So the version you've got svn-ed does or does not compile with MIPSPro? Since, as one of the old dudes, I've been hacking c code longer than most of our members have been alive, I'm the king of the #ifdefs, PM me the relevant infodata to access your svn and I'll have a look-see... :mrgreen:
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
hamei
Posts: 10476
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: mplayer 1.3.0

Unread postby hamei » Sun Apr 15, 2018 3:27 am

vishnu wrote:Years ago I used to compile my own version of mplayer ....

So here's your opportunity to relive the past :lol:

Slight change in direction, definitely seems better to start with something that works and go from there so re-organizing the functioning neko mplayer as a starting point and putting that up ... as soon as I remember how to solve the missing inttypes problem. I distinctly remember running into this before. Lessee, where did I put my brain ...
2 + 2 = 5

User avatar
vishnu
Donor
Donor
Posts: 3361
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: mplayer 1.3.0

Unread postby vishnu » Sun Apr 15, 2018 2:14 pm

hamei wrote:
vishnu wrote:Years ago I used to compile my own version of mplayer ....

So here's your opportunity to relive the past :lol:

Slight change in direction, definitely seems better to start with something that works and go from there so re-organizing the functioning neko mplayer as a starting point and putting that up ... as soon as I remember how to solve the missing inttypes problem. I distinctly remember running into this before. Lessee, where did I put my brain ...

Some useful info on compiling with the IRIX version of inttypes.h located here.
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
hamei
Posts: 10476
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: mplayer 1.3.0

Unread postby hamei » Sun Apr 15, 2018 7:52 pm

vishnu wrote:Some useful info on compiling with the IRIX version of inttypes.h located here.

Cool, thank you ...

Okay le, back to the beginning, decided to start with the foundation instead of the roof and document the steps here in case someone in the far far future wants to play ...

Downloaded the nekoware mplayer tardist and extracted the source and the patches.

Opened release notes and read.

Followed instructions ... pretty accurate except for a hyphen was mistaken for an underscore in a patch name, easy to figure out.

Applied first four patches, the last one seems to be mostly about paths, so skip that for the moment. Uh-oh, decision time ...

I'm thinking, at least for myself and considering the state of nekoware, that I will be putting this in /opt/mplayer with the includes and libraries under that roof. At least in the first stages that should be a lot easier. So Decision One made, onward and upward ..

Okay, time to run configure. In this case configure is not part of autotools, it just pretends to be. Don'tcha just love them geeks ? So it doesn't behave exactly the same. At least this is described in the mplayer docs, not hidden knowledge that you need the Jimmy Wilson Decoder Ring to access. They missed a trick there, careless :(

Configure comes to a screeching halt finding inttypes. Hmm. Seems to me I remember this. Search nekochan. ritchan had the same problem.

viewtopic.php?f=15&t=16721459&p=7304595&hilit=inttypes#p7304595

He solved the problem by removing a gcc-only optimization flag but that did not work for me. So rather than brush up my magisterial coding skills, I applied logic.

Section of configure that looks for inttypes first checks for inttypes.h, then it checks for bitypes.h as a fallback. Well I know Irix has inttypes so why should we be checking for a fallback ? Let's remove that section and see if the error codes show something we can understand ...

Code: Select all

echocheck "inttypes.h (required)"
cat > $TMPC << EOF
#include <inttypes.h>
int main(void) { return 0; }
EOF
_inttypes=no
cc_check && _inttypes=yes
echores "$_inttypes"

------------------------
# removed after this line excepting the final fi statement
------------------------

if test "$_inttypes" = no ; then
  echocheck "bitypes.h (inttypes.h predecessor)"
  cat > $TMPC << EOF
#include <sys/bitypes.h>
int main(void) { return 0; }
EOF
  cc_check && _inttypes=yes
  if test "$_inttypes" = yes ; then
    die "You don't have inttypes.h, but sys/bitypes.h is present. Please copy etc/inttypes.h into the include path, and re-run configure."
  else
    die "Cannot find header either inttypes.h or bitypes.h (see DOCS/HTML/$_doc_lang/faq.html)."
  fi
fi


Ran it again and viola, not only did we get a better error message, we didn't get any error message, configure found everything nicely. Woohoo :D

So I am happy with the result but if someone who understands scripting can explain what happened, might help the overall coding skills of us beginners ?

With this configure done there should be a Makefile to which the last patch can be applied, but our program says I'll change those paths to something else, so that next chapter can come tomorrow. Maybe :)


big bunny, over
2 + 2 = 5

Axatax_
Posts: 102
Joined: Wed Jan 21, 2015 3:08 pm

Re: mplayer 1.3.0

Unread postby Axatax_ » Mon Apr 16, 2018 12:47 am

I don't think I ever posted a patch for the "beta" Mplayer I sent up. It's newer than what's in Neko maninline but probably older than current official Mplayer.

LMK if you're still interested. I have to set the Octane back up but that's not a big deal. Like alot of people life (my first kid) got in the way... :D


Return to “SGI: Development”

Who is online

Users browsing this forum: No registered users and 1 guest