Words and Pictures in Linux

Having recently delved back into Debian and Ubuntu to see if they would be ideal as my long term distros, I have now returned to Slackware. I’m not going to discuss here why I have returned, suffice to say that I have returned because it’s a distro I enjoy using. So there.

Normally, when I reinstall, I go nuts and get absolutely everything up and running straight away. This time I have taken it a wee bit slower and the only essential thing I haven’t done is enable the playing of sounds and movies in Firefox. There are a few ways to do this. My preferred method is to install a movie/audio player and the associated plugin. Why is it my preferred method? Because I know it works and I know it tends not to give me any trouble. Now, under Debian or Fedora or Suse or Gentoo or similar I would either open a console and type in apt-get install ... or yum install .... or open Yast and click some buttons or do emerge ..... and I would be able to walk away and let it install itself. But you can’t really do that on Slackware. Slackware doesn’t have dependency checking natively and now that Swaret is effectively dead or dying, my favourite dependency checking package manager is not an option here. Actually, it wouldn’t be an option anyway - for this install I prefer to do it all by hand. Old school, you see.

As with most things I do, this won’t necessarily be the best way, but this way will work and at the end I will be left with a system that works and I know that I don’t have to repeat my actions further down the line because something broke. I will end up with a system that can play lots and lots of differently encoded media formats. And that’s very important to me.

My preferred player is MPlayer and the plugin for Firefox is mplayerplug-in. To get these running properly and using source code is a long winded but pretty straightforward affair. It can seem daunting, especially if you aren’t used to doing things on the command line, but it really is very easy.

Firstly, a shout out to LinuxQuestions.org. Chris Phillips, creator of AcidRip and LQ Moderator had a great app which relied on MPlayer, but no documentation. Drew Bentley, website owner, host and LQ Moderator wrote that documentation. And I rescued it from the Wayback Machine and posted it to LQ in it’s entirety. Read it here. In short, with or without the steps to install Acidrip, the documentation is detailed enough to help you to install MPlayer and ensure it works. I reference it every time I come to do the install and, even though it’s a few years old now, it has never steered me wrong. In this article, I will only discuss where I diverge from the documentation on LQ, really, if I don’t discuss it I stuck to the docs.

My first step was to create a folder in my temporary directory to store the files. I always download to my temp directory and I always create an “mplayer” storage space there - purely for convenience. I then tell Firefox to store things there. I’ll be downloading a lot of files and this is, for me, a good way to work tidily.

So, what do we need? Well, for my system, I need a lot of Gtk files:

I haven’t, you’ll notice, either put the links directly to the packages or mentioned version numbers. This is because the versions change over time and it’s our own responsibility to get the current or correct versions.

Libdvdread is necessary and has also increased the version number since the guide was written, so don’t download the link in the documentation - instead, strip off the filename and then download from the address that remains. Or click the link at the start of this paragraph. Finally, grab Mplayer, the codecs and a skin (because you want to use it outside of Firefox, right?). Your folder should now look something like this:The downloads at this stage…

All of these files will allow us to end up with MPlayer working on our system. With a GUI, no less! I shouldn’t need to, but I will, point out that these are what I need to do this. I have done this a number of times and I know that this works. You may not need all of these filesor you may need less of them. Check your own requirements before following this.

OK, with that, let us continue. Section 3.1 of the guidance on LQ is now out of date - there is already a symlink set up to /dev/dvd in Slackware and this does not need to be created by hand. So, read that section to increase your knowledge, but don’t do what it says.

We need to install Lame and Libdvdcss ahead of everything else. These aren’t covered in the LQ instructions, but they are easy to do. We will expand the archive the files are in, and start running commands, but first we read the README and INSTALL files. Get into the habit of doing this - the developers put useful and necessary information in there. So, tar zxvf lame-3.97.tar.gz will expand the file and create a directory containing your install files. The README file, in this case, just says to go to the INSTALL file for instructions, so we can leave it here. We can also do ./configure --help to get our install options. But the INSTALL file is usually friendlier. There are a few options in there, but none of them are needed for my system, so I will simply do:
./configure
make
su
enter root's password
make install
exit

Piece of cake. I say to read the files for a very good reason. If you install manually like this, your system will not check for dependencies. Normally, the developers will tell you in these files what the dependencies are. Otherwise, you just do ./configure and read the errors (if any) at the end. This only works if the developers put in meaningful error messages of course.

Do the same again for Libdvdcss. On reading the INSTALL file, as directed by the README file, we can see that the commands are the same as for Lame, with a small addition. This time we do ./configure --prefix=/usr to tell the system where to install it. You can do this with any source install, by the way, particularly if you have your system set up with programs installing to odd places. Though if you know enough to do that, you don’t need me explaining things.

That done, we can now return to the LQ documentation - Section 3.2. As it happens, there is little more for me to say about this part of the install. Drew takes us through the steps very well and the steps haven’t changed since he wrote them.

One thing to say is the Gtk2 depends on Cairo being installed. Look:

Needs something else…..

This is what I meant by meaningful error messages. Most of the results of make are absolute gobbledegook to me, but that final part “Cairo not found” tells me all I need to know. So I just need to install Cairo and reinstall Gtk2. As a tip, and something I have found out by trial and error, you have to install Cairo before Gtk2 but after the other Gtk files. This is because Cairo depends on them for it’s own install. Once Cairo is installed, we get this message from Gtk:

And there it is

And we can finish installing Gtk2. Many people deride source installs for being old-fashioned or too slow. And yet we have seen that despite the fact that there are very good package managers out there, installing with source is easy and tells you where you need something else. No mysteries and it’s all in plain language. OK, back to the documentation and continue with installing libdvdread.

Once you have all your dependencies intalled and you are ready to install MPlayer and it’s associated files, I normally add in a step here. As root, issue the following command: ldconfig and updatedb. This updates your libraries and ensures your system is aware of them and also updates your search database. This is a “belt and braces” approach which ensures that you don’t need to do this further down the road when you are less inclined to do it.

To reiterate Drew’s warning: … remember if you want any other codecs, fonts, etc, be sure to install them before doing this step so MPlayer detects them. If you don’t do it now, you will be prompted at the end of the first install stage and you’ll have to start again. Do it once and do it properly.

So, first step is to expand our codecs and move them to the correct place. The MPlayer files end in .tar.bz2 so our command to expand will be slightly different: tar jxvf essential-20061022.tar.bz2 - make sure that you check the name of any file you expand to ensure that you use the correct command.

The location for our codecs (in theory) doesn’t yet exist, so create a folder like this (as root): mkdir /usr/lib/codecs - weirdly, the folder does exist on my Slack 11 system. But if it didn’t that’s what I’d do. You could also put them into /home/username/.mplayer/codecs but that would only install them for one user. Now install MPlayer as per the instructions.

Talking of meaningful messages, look at the output of MPlayer after the ./configure --enable-gui stage:

Look!

I can see which outputs are enabled and disabled. After make and make install, the I just need to install the skins (ignore this bit if you don’t want a gui frontend). The final output states to put the skin at /usr/local/share/mplayer/skins/ which sounds very reasonable and easy - until you realise that that is not the entirety of the task. Firstly, untar whichever skin you downloaded. Then rename it’s folder to default (lower case) and then move it to /usr/local/share/mplayer/skins. This really threw me for ages since I couldn’t see it referenced anywhere. I figured it out purely by trial and error. Anyway, the first stage is done with - we have a media player which can play all sorts of differently encoded media files, including those encoded in the Microsoft or Quicktime formats. On now to mplayerplug-in.

On the website for mplayerplug-in, the instructions for installing MPlayer are now out of date - ffmpeg is included in MPlayer and you don’t need to add it manually. Which saves a bit of time. I ususally add gecko to my system - it works and takes a few seconds. And I like to go with what works! The site states to get the Mozilla 1.6 sources, I use the Mozilla 1.8b1 sources instead. This is because the 1.6 sources appear to havbeen moved and I don’t want to go searching. 1.8b1 works fine for me. I save my newly untarred gecko folder in /opt. It doesn’t matter where you put it, since you will tell the installer where to find it!

Follow the instructions on the mplayerplug-in website and you will have it installed and working. Go now and watch your videos.

MPlayer (and, by extension, the plugin) has the reputation for being difficult to install. As I hope we have seen here, this is not the case. Yes, installing the whole thing from source takes some time, but it is not difficult. The beauty of Linux (and computing in general) is that most of the hard stuff has already been done and documented. All we need to do is to find it, follow it and change the bits that no longer apply.

12 Comments

  1. drewNo Gravatar:

    Ah yeah, I remember the good ol acidrip howto.. too bad Chris doesn’t maintain it any longer. But then again, not much else you need except to possibly support new features mplayer comes out with.

    [Reply]

  2. hariNo Gravatar:

    Nice long Linux article… Good work, Ray. :biggrin:

    [Reply]

  3. RayNo Gravatar:

    The original has saved me from forgetting bits a few times, maybe I’ll incorporate this into the original some time.

    Thanks guys.

    [Reply]

  4. J_K9No Gravatar:

    Great article, Ray - thanks :)

    Just a question - why didn’t you use the Slack packages instead of building from source? Wouldn’t it have been easier? (Sorry, I may have misread the reasons behind this as I’m in a bit of a rush :silly: )

    [Reply]

  5. hariNo Gravatar:

    I use slackpkg myself. It’s a useful tool, but only for installing and updating official packages.

    I would still use LinuxPackages.net and see whether a software has a package file before I look for sources.

    [Reply]

  6. RayNo Gravatar:

    Personally, and paradoxically, under Slackware I find it easier to do things via source than via .tgz files. Especially where there are a number of dependencies.

    If you go via Linuxpackages, you need to open each file in your archive manager and look at the requirements file to see what the dependencies are. Then do the same for the dependencies. It’s a lot slower than doing ./configure and then seeing what the program complains about :)

    Also, unless the slackpack installs to the places the source program is expecting, you have to spend even more time tweaking configuration files and the such like.

    Much easier to do it from source from the start.

    Case in point: I used the KDE 3.5.6 files from Linuxpackages to upgrade KDE. Cunningly, whoever put them together has their Konsole program set up strangely and no amount of fiddling would return it to the correct state - it seems that everyone is forced to have their konsole the same way as the package creator….

    [Reply]

  7. J_K9No Gravatar:

    Well, for large packages, I would definitely agree with you, but I personally find it much simpler to install the smaller apps with slackpacks :)

    Then again, you are my Slack mentor, so I should be agreeing with you :tongue:

    [Reply]

  8. RayNo Gravatar:

    Everyone should agree with me anyway :wink:

    Slackpacks can be useful, but if they put files on non standard places - say /usr/lib rather than /usr/locallib and you install something that looks to /usr/local/lib you will end up chasing down the problems and then hand tweaking some programs.

    I had to do that a few times until I realised that i would save time by just getting the source.

    Next step is, theoretically, to hand install KDE (or, at least, use Konstruct to do it). But I’m in no mad rush to get my DE up that 0.01 of a step.

    [Reply]

  9. drewNo Gravatar:

    I use official slackware tgz’s in most cases. It simplifies things. I download what I need and place into a temporary directory. Once all in place, it’s as simple as: upgradepkg *.tgz

    It will upgrade if it’s present, for those that might not already be installed, I go back and just do an installpkg. Perhaps I should write a script that automatically checks for updated packages if I don’t already have them and wget them, notifies me of the new packages and then I can review before installing if it’s necessary.. hmmm..

    But then again, I usually do all my upgrades on test machine before applying to the main servers I have. Never test on a production box, it’s can come back to bite you on some days..

    [Reply]

  10. RayNo Gravatar:

    I use the .tgz’s for upgrades only - anything else is done mostly by hand.

    [Reply]

  11. AndrewNo Gravatar:

    Just a quick question about the mplayer comments in your page. My experience is with the svn mplayer rather than the rc versions but certainly in the svn version of mplayer dvdread and libdvdcss are contained within the program and do not need to installed seperately. This may have changed since you wrote this page.

    Thanks for taking the trouble with the rest of your site which I have enjoyed reading through!!

    Andrew

    [Reply]

  12. RayNo Gravatar:

    Thanks for the comment Andrew - much appreciated. I tend to use the rc version, simply because it’s likely to be more stable (at least, that’s in my opinion). I also tend to use a belt and braces approach - I install everything I think I need because sod’s law says that the one time I don’t bother will be the one time I need to do that!

    [Reply]

Leave a comment

This site uses KeywordLuv. Enter YourName@YourKeywords in the Name field to take advantage.