Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
I have again synced the wiki page with the website guide and added in a section describing how to compile and package MPlayer2. Works well enough on my system. I suspect the next move would be to add in a few libav and MPlayer compile options, the build system is very different from stock standard MPlayer...
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Updated for Quantal Quetzal.
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Hi
SMPlayer > Help > About SMPlayer
Shows:-
Using MPlayer SVN r35679
This information is contained in file $HOME/.config/smplayer/smplayer.ini
It says "mplayer_detected_version=35679".
When we update MPlayer, can you suggest a suitable command that can be included so that it updates the "mplayer_detected_version" information too?
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Oddly enough the versions seem to match on my system despite regular updates to MPlayer itself. Not sure what to suggest there.... Please feel free to update / change the wiki page as you please, my involvement there will be minimal. The wiki still appears a wasteland after T&T...
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Quote:
Originally Posted by
andrew.46
... Not sure what to suggest there...
I found help here --->http://ubuntuforums.org/showthread.php?t=2095757
Code:
sudo checkinstall -D --install=yes --fstrans=no --pakdir "$HOME/mplayer_build" \
--pkgname mplayer --backup=no --deldoc=yes --deldesc=yes --delspec=yes --default \
--pkgversion "2:1.0~svn$(LC_ALL=C svn info 2> /dev/null | \
grep Revision | cut -d' ' -f2)" --provides "mplayer,mencoder" && \
sed -i "/mplayer_detected_version/ s/=.*$/=$(LC_ALL=C svn info 2> /dev/null | \
grep Revision | cut -d' ' -f2)/" ~/.config/smplayer/smplayer.ini && \
make distclean && sudo ldconfig
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Mind you this might lead to a confusing error message if SMPlayer is not already installed...Perhaps consider placing the text as a sidenote or an extra step, out of the actual MPlayer packaging section?
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Quote:
Originally Posted by
andrew.46
Perhaps consider placing the text as a sidenote or an extra step, out of the actual MPlayer packaging section?
Yes,
It would be better to have a 'stand-alone' command to use at any time without reference to SVN.
When I figure out how to isolate version from:-
@ubuntu:~$ mplayer -h | grep -i "MPlayer SVN-r"
MPlayer SVN-r35695-4.5.2 (C) 2000-2012 MPlayer Team
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Quote:
Originally Posted by
ron999
When I figure out how to isolate version from:-
Code:
@ubuntu:~$ mplayer -h | grep -i "MPlayer SVN-r"
MPlayer SVN-r35695-4.5.2 (C) 2000-2012 MPlayer Team
This is not particularly elegant but should work until the revision numbers reach 100000 :
Code:
andrew@skamandros~$ mplayer -h | grep ^MPlayer | cut -c14-18
35687
I have not really used the -c option before with cut but definitely a good thing to know...
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
Quote:
Originally Posted by
andrew.46
... should work until the revision numbers reach 100000 ...
That works OK.
But we've introduced something like a Y100K bug, lol. :P
I don't think it's necessary to add this feature to the wiki.
Code:
sed -i "/mplayer_detected_version/ s/=.*$/=$(mplayer -h | grep ^MPlayer | cut -c14-18)/" ~/.config/smplayer/smplayer.ini
Re: Support for 'Compiling MPlayer' Ubuntu Wiki page....
As a heads up, there is now another fork worth checking out: mpv
I've moved over to using it as my main mplayer variant on both Ubuntu and Windows (because you can actually compile it under MinGW-w64 without applying patches* and whatall, although it does require building the dependencies first). I also use it as my transcoding solution on OS X, although I don't use OS X nearly as often as the other two.
*slightly untrue, because there is all of one necessary patch to apply: to Fribidi2. But aside from that, there's no patching required. libbluray and twolame also need some minor patching to build with MinGW or link statically, but unlike Fribidi, those components are completely optional (Fribidi is only optional if you don't want support for subtitles).
Of interest is that:
MPlayer2's vo-lavc (aka encoding) branch is no longer developed (hasn't been since around July or August), because development on that moved to mpv (and is not a separate branch; it's also enabled by default). This means that a stock build of mpv does both decoding and encoding to any format supported by the libavcodec that was linked against it.
At least on my older graphics card, I seem to be getting better performance with mpv - much less tearing on Ubuntu with -vo xv, anyway (although the age of my computer means I can't really play video on Ubuntu; -vo direct3d under Windows just runs circles around it). Under Windows, it doesn't have the weird issues dealing with exotic pulldown schemes or playing 29.97fps progressive in MPEG-2 the way MPlayer2 sometimes would have. This might be partially due to the age of the MPlayer2 build I was comparing it to, though.
Support for FFmpeg's extended y4m format that allows higher bit depths (and even in non-y4m cases: though x264 can't encode 12-bit or 14-bit H.264 files yet, mpv can play such streams back if you actually use FFmpeg).
mpv's stated purpose also seems to be to reduce the amount of complexity/cruft in MPlayer/MPlayer2, so some stuff has gotten trimmed out (the win32 binary codec loader is gone, for instance).
I do have my own branch on Github that integrates two changes to mpv itself: one makes it generate a sequential revision number to display in the console readout, the other is a discrete AvxSynth demuxer that was originally posted for MPlayer2 to 0x09's AvxSynth 'osx' branch (since libavformat's AviSynth demuxer doesn't work on Linux and the rewrite posted to ffmpeg-devel that would enable using AvxSynth to do it hasn't gotten all the kinks hammered out of it yet*, a discrete demuxer is really the only solution as of right now). I haven't done a HEAD catchup for a while though, I'm waiting on one of the alternative branches on the main repo to get merged first.
*read: the most recent version of it causes segfaults whenever you try to load a script. Also, due to the move to planar audio decoding going on in libavcodec, FFMS2 can't handle audio aside from PCM at the moment (although you could build it against a pre-November 26th FFmpeg so you can decode AAC, MP3, and AC3 at least). Not that that has anything to do with how well the demuxer works, though - just something to be aware of if you want to try to test it.