For those of you sticking to the release version, we recommend to update to 1.1.1 to avoid security issues. The tar file in the download section also contains the latest version of the FFmpeg 0.11 release with many fixes of its own.
If you need a diff of only the fix itself, for example for old versions you still want or need to maintain please use
svn di -c36242 svn://svn.mplayerhq.hu/mplayer/branches/1.1
We would like to get MPlayer-VAAPI merged and need some developers to review and fix up the codebase. Advanced help would be appreciated, please coordinate on mplayer-dev-eng mailing list for more information.
An MPlayer user notified me about the SMPlayer link that we had on our download page. The SMPlayer installer was trying to install adware and toolbars.
The MPlayer project does not condone adware/spyware at all. If you have installed SMPlayer via the web installer, we urge you to uninstall all of the spyware that may have been installed.
When I linked the SMPlayer installer , it was 8mb and contained nothing but MPlayer and SMPlayer gui. The link had been changed and I failed to notice. Any users affected have my sincere apologies.
We gave up on 1.0
After a long pause, we decided that it might be a good idea to make a new release. While we had our fun with the naming scheme with lots of "pre" and "rc" it seemed time to move on and with everyone incrementing major versions between weekly and monthly we hope to be forgiven for jumping ahead to 1.1.
This release is intended to be compatible with the recent FFmpeg 0.11 release. We hope it will be useful to distros and other users relying on FFmpeg 0.11. Everyone else is encouraged to follow Subversion HEAD to always get the latest features and bug fixes. You might still want to read the release announcement to get a short summary of any bigger changes and improvements.
Among the bigger news is that we found a maintainer for the X11 gmplayer GUI, so those holding out on it against our earlier recommendations will get a lot of bug fixes.
There is also support for more subtitle types (Bluray, DVB, DVB closed-caption for example), many improvements to -vo gl including output of 10 bit video, very basic but usable OpenGL ES support and much better SDL support which makes it a usable choice on OSX (particularly on older PowerPC variants much faster than corevideo or quartz). MPlayer will now also try much harder to handle intermittent network failures, for example trying to reconnect.
As part of the code cleanup efforts, the internal libfaad2 copy has been removed since the FFmpeg decoder is working well. Also the internal mp3lib copy is no longer used by default since the many alternatives (FFmpeg, libmpg123, libmad) avoid its recurring issues like incorrect decoding with newer compilers. However it can still be forced at runtime for easier tracking of regressions. Please do not rely on this since it will be removed in the future. If you do not actually need it consider disabling it at compile time with --disable-mp3lib.
As a first for this release, the tarballs are available in two variants: compressed with xz and compressed with gzip. Please get the xz variant if you can to save bandwidth, the gzip version is for everyone that cannot use it. Should you never have encountered xz compressed files, newer versions of tar can uncompress it via "tar xJf MPlayer-1.1.tar.xz".
xz MD5SUM: ac7bf1cfedc1c5c24bfc83107eefb1d9
xz SHA1SUM: 913a4bbeab7cbb515c2f43ad39bc83071b2efd75
gz MD5SUM: 4bf35ef2a802f23b9ad57ba7ef488587
gz SHA1SUM: e46e3294bc96daabe604e4e195721e4f2d1e5b48
MPlayer does support encrypted BluRay playback, though not all steps are handled by MPlayer itself. The two alternative methods use the URL schemes bd:// (always supports decryption, but you need the key for each and every disk in ~/.dvdcss/KEYDB.cfg and only works well with very simple BluRays, similar to dvd:// vs. dvdnav://) and br:// (uses libbluray and should support the same as VideoLAN in the link below but that is untested).
I have not tested, but it looks like it works on Mac OS X, Linux and Windows. Thanks to whoever created this and hopefully no one will have to rip the discs to a hard drive before playing now.
Today, a bill that would create America's first Internet censorship system is going to a full committee for a vote, and is likely to pass. Please call or email or write your congresscritter now!
If you are not in the USA, you still need to talk to your friends who are in the USA and get them to call. You can also petition the state department.
MPlayer's services are operational again. We were unable to move the physical server at this time, but the data has arrived at our new host safely.
The mailing lists have been reindexed, so old urls will point at incorrect mails again. The website /DOCS/ arent updating, so please use the SVN documentation for now.
If you find any problems with the website, please report them on our Bugzilla.
Due to some reorganizations, the MPlayer project server will be moving soon. There will be some downtime for the mailing lists and svn server while things are in transit.
Join us on IRC while we wait for the server and DNS to propagate! Connect to irc.freenode.net and join the #mplayer channel.
Thanks to FFmpeg and its project in the Google Summer of Code program, we
now have multi threaded support for playing back H.264 and other codecs.
To enable threading run mplayer -lavdopts threads=N file.mkv where N is the number of threads you want to use.
You will need to have the latest SVN MPlayer for this. Please report any bugs you find to our Bugzilla.
Yes, we can!
MPlayer 1.0rc4 continues the tradition of long overdue, but better late than never releases. It has been tested thoroughly to work with the FFmpeg 0.6 branch. It will be useful to distros and other users relying on FFmpeg 0.6. To get the latest and greatest in features and bug fixes, Subversion HEAD should be a better fit.
1.0rc4 once again adds a slew of new binary codecs and leverages all the stuff added to FFmpeg. Notable additions are VP8 decoding, H.264 bug fixes and speedups, unencrypted Blu-ray support. Network streams can now be played through FFmpeg, there has been quite a bit of subtitle work and Ogg and Matroska demuxer defaults were switched to libavformat. The window position is now decided by the window manager.
Our constant efforts to clean up the codebase continue as usual. A ton of compiler warnings disappeared and there have been refactorings all around. External library copies have been synchronized with upstream. The internal liba52 copy is gone and it is now possible to build against external libmpeg2 and libmpg123.
It is now possible to donate to MPlayer through flattr. Thank you for your support.
As a special service for Ubuntu users, the mplayer project now provides packages for various versions of Ubuntu. The packages are built twice a week from SVN trunk and run independently of your system libraries.
For instructions how to enable the PPA, please look here
A message from the creator of MPlayer, Arpi:
It was exactly 10 years ago, that I've released first MPlayer version, v0.01: http://www1.mplayerhq.hu/MPlayer/old_stuff/releases/MPlayer-0.01.tar.gz Yes, f*cking 10 years!!!! Nov 11, 2000... Time goes on so fast...
I want to thank you all for the contributions, patches, bugs, docs, testing etc. Especially Michael Niedermayer, Fabrice Bellard and Nick Kurshev, who made it to be the best & fastest open-source player!
And sorry Nick, I made a big mistake rejecting your multi-threaded patches. Unfortunatelly your idea came too early, nobody (at least me) thought that desktop PCs will ever have multiple CPUs... and now that even cheap notebooks and netbooks have multi-core CPUs, it would be very useful for HD playback...
Also special thanks to Gabucino, Pontscho and LGB, for your support in the early days, when everybody thought i'm mad, working on video player for linux...
ps: Albeu, i'll never forgive your playtree patches :)
Some work is being done to the MPEG subtitle code, but we need more samples of DVB and VBI-coded teletext as well as other MPEG-TS/PS subtitles which currently do not work in SVN or which work with -demuxer lavf but not with MPlayer's demuxer.
Just some random notes and changes. In SVN the lavf demuxer is now default for Matroska files. We are trying to fix the problems in it, so please report some bugs if you run into them.
If you just want to undo this change, add the following to the end of your config file:
MPlayer now has the ability to use FFmpeg's network code to access streams. Use mplayer ffmpeg://rtsp://example.invalid/stream.mov syntax to try it.
In general most users should be using SVN MPlayer, as rc3 is over a year old.
Godot has arrived.
1.0rc3 was intended to be rolled out over a year ago, but got delayed again and again. Since it is designed to be compatible with the FFmpeg 0.5 branch, it will be useful to distros and other users still tracking said branch. Thus we are now publishing it even though it is outdated even before the day of its release. For general usage current Subversion snapshots should be a better fit, as many bug fixes and new features are available.
This release adds support for a ton of new binary codecs and leverages all the stuff added to FFmpeg. Hardware-accelerated video output over VDPAU is now possible, as is audio output through PulseAudio. MPlayer now runs natively on 64bit OS X, the Wii and on OS/2.
We have switched to the libavformat MOV/MP4 demuxer to avoid maintaining the duplicate MOV/MP4 code. This breaks binary audio/video codecs with MOV/MP4 files. Please use '-demuxer mov' if you still require the binary decoders.
Our constant efforts to clean up the codebase continue as usual. A ton of compiler warnings disappeared and there have been refactorings all around. External library copies have been synchronized with upstream.
There is no need to download binary codec packages if you already have an older version. The codec packs have not been updated.
Note that this code is ancient, e.g. it still contains this long-fixed bug. Unless you are at least deadly allergic to it, use latest SVN instead.
Newer ATI cards and Intel ATOM owners on Linux can utilize the VA-API hardware accelerated H.264, WMV3/VC1, MPEG2 and MPEG4 playback using MPlayer.
Instructions can be found at http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/
Happy new year! Just a quick note, if you got some DVD's as a gift, mplayer -nocache dvdnav:// should play your new movies better than dvd://.
MPlayer now supports most of the Blu-ray and HD-DVD codecs. You can rip Blu-ray movies on Linux using this guide. There is also an untested patch for playing Blu-ray discs in this thread at doom9.org.
MPlayer is also hosting the rtmpdump project. rtmpdump is a program to download rtmp:// streams. It was previously hosted on SourceForge.
There are several ways to speed up the playback of 1080 H.264 files in MPlayer.
First is to use the newly added VDPAU
output. It allows the newer
Nvidia video cards
to decode the video without using much CPU. It is in SVN MPlayer
(Nvidia binary driver 180.37 or newer required), you can
find known bugs and report bugs
(Linux, Solaris and FreeBSD only)
How to get the SVN version is described on the download page and snapshot tarballs are available as well.
Second is to use MPlayer with the experimental multithreaded
branch, which allows you to use multiple cores/CPU. (all OS and CPU supported)
To enable threading run mplayer -lavdopts threads=N file.mkv where N is the number of threads you want to use.
NOTE: FFmpeg-mt has problems with packed b-frames.
A Windows build of MPlayer using FFmpeg-mt can be found at http://oss.netfarm.it/mplayer-win32.php.
Fourth, FFmpeg has added some optimizations from the x264 project. To fully utilize these you will need to make sure a recent version of YASM is installed and detected by the latest SVN MPlayer when compiling.
Fifth, using -lavdopts skiploopfilter=all:fast=1 may cause artifacts, but will allow you to play larger files in realtime. (all OS and CPU supported) (use -lavdopts skipframe=nonref:skiploopfilter=all:fast=1 for even more speedup, skipframe also works with VDPAU.)
There is also a rejected PATCH which adds support for the new multithreaded binary VC-1/WMV3 codec.