Linux Video Playback: Difference between revisions

From BakaBT Wiki
Jump to navigation Jump to search
(What NOT to see in a media player - initial edit)
(Reference to ffmpeg/libav external article removed as external article was deleted)
 
(One intermediate revision by the same user not shown)
Line 77: Line 77:
It should be noted that while Libav seems to ignore FFmpeg's development efforts, FFmpeg frequenty merges all of Libav's development efforts. The net result is that Libav features are a subset of FFmpeg.
It should be noted that while Libav seems to ignore FFmpeg's development efforts, FFmpeg frequenty merges all of Libav's development efforts. The net result is that Libav features are a subset of FFmpeg.


If you're interested in knowing a little more about the differences between them, the [https://github.com/mpv-player/mpv/wiki <b>mpv player wicki</b>] has some [https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav <b>excellent commentary</b>].
For these reasons and without considering user invisible merits, we prefer FFmpeg as our codec engine.
 
For these reasons and without considering other user invisible merits, we prefer FFmpeg as our codec engine.


===Active Development Community===
===Active Development Community===
Line 88: Line 86:
==What <b>Not</b> to Look for in a Video Player==
==What <b>Not</b> to Look for in a Video Player==
===Not Using Either ffmpeg or libav===
===Not Using Either ffmpeg or libav===
As part of their core functionality, both ffmpeg and libav are established codec libraries. They represent a large collective effort over time in reverse engineering of hundreds of assorted codecs. It's almost impossible for any project to build such a library of codecs on their own. As a result, media players which only go with internally written codecs possibly combined with externally available individual codecs are always limited to very specific niche playback categories. Notably, media players which are internal to game engines are almost always an example of this. The rule of thumb is to avoid any media player which doesn't make use of either ffmpeg or libav. xine(ui) was originally built this way but now includes ffmpeg in order to be able to playback h.264 and HEVC.
As part of their core functionality, both ffmpeg and libav are established codec libraries. They represent a large collective effort over time in the reverse engineering of hundreds of assorted codecs. It's almost impossible for any project to build such a library of codecs on their own. As a result, media players which only go with internally written codecs and possibly combined with externally available single codecs are always limited to very specific niche playback categories. Notably, media players which are internal to game engines are an example of this.  
 
The rule of thumb is to avoid any media player which doesn't make use of either ffmpeg or libav. xine(ui) was originally built this way but now includes ffmpeg in order to be able to playback h.264 and HEVC.


===Not Permitting Use of External Codecs===
===Not Permitting Use of External Codecs===
While ffmpeg and libav include hundreds of internal codecs, these codecs are not all written to the same quality. For this reason, both mplayer and mpv support the inclusion and use of select external alternative codecs. This allows both media players to use better codecs than the ffmpeg/libav intenally provided ones.
While ffmpeg and libav include hundreds of internal codecs, these codecs are not all written to the same quality. For this reason, both MPlayer and mpv support the inclusion and use of select external alternative codecs. This allows both media players to use better codecs than the ffmpeg/libav intenally provided ones.


===Don't Use Third Tier Media Players===
===Don't Use Third Tier Media Players===

Latest revision as of 01:11, 2 April 2015

Recommended Media Players

This is the tl:dr (or what used to be called the "Executive Summary") section. We flat out tell you what the recommended Linux Video Players are. Feel free to use these links to jump their respective sites immediately. To be better informed, please continue reading.

Previously Recommended but Discontinued Media Players

  • Mplayer2 (fork of Mplayer - inactive, domain expired. Do not install from any distribution)
  • SMplayer2 (graphical interface for Mplayer2 - Do not install from any distribution)

Command Line Interface versus Graphical User Interface

MPlayer amd mpv player are Command Line Interface (CLI) programs while SMPlayer and Baka Player are Graphical User Interface (GUI) frontends. However, MPlayer can optionally include a simple GUI of it's own and both players include an On Screen Display/Control (OSD/OSC) panel. The OSD/C functions as a simple, mouse activated panel control usually giving you the ability to cycle through movie sound tracks (languages) and subtitles, seeking, skipping to the next item in your playlist (if you're using one) and volume (using either point and click or keyboard hot keys). This is usually fine for most people.

If you or your intended users are only comfortable with using a GUI, then SMPlayer and Baka Player both represent the usual graphical user experience. These are front ends to either MPlayer or mpv player. If you install either SMPlayer or Baka Player, depending on which you choose and it's build configuration, you will also be getting either MPlayer or mpv player.

Common Characteristics

All these players are cross platform capable for at least Windows and Linux. MPlayer and mpv player are also crossplatorm capable for OSX and the BSDs. Note: in most cases there is no official support for third party (distribution) provided packages of these players. Problems installing these packages other than from source code needs to be taken up with your distribution.

These packages are all being actively updated/developed and can or by default include support for the latest encoding standards and playback profiles. This includes support beyond H.264, Hi10p such as H.265 (HEVC) profiles and 4k displays. If these notations are gibberish to you, don't worry. The package maintainers are already doing all the worrying that needs to be done for you. What should concern you is that these players are and will continue be capable of playing back just about anything you can find.

Useful Information

Everything Changes - Nothing Stays the Same

People often post: "I can't play this new video even though it says h264 and everything else plays fine and I've been using this player forever! What gives?", "What kind of format is XYZ? I never heard of it before.", : This movie won't play and must be borkened/infected/encoded by idiots!" and from slightly more knowledgeable users "What codec pack should I use with my player to play ABC format?" These questions are almost always based on not realizing the incredibly rapid rate of change in video playback. Here are a few abreviated timelines to consider:

H.264

  • 2003 (Version 1) Formal ratification of initial standards also known as Advanced Video Coding (MPEG-4 AVC).
  • 2005 (Version 3) Major amendment - notable for Hi10p profile.
  • 2007 (Version 8) Major amendment - introduction of Scalable Video Coding (SVC)
  • 2009 (Version 11) Major amendment - introduction of Mulitview Video Coding (MVC)
  • 2013 (Version 20) Current version.

Note there are 20 versions over 10 years. This is an average of 2 revisions each year in what many people consider to be a static standard.

H.265 (HEVC)

  • 2013 (Version 1) Formal ratification of initial standards also known as High Efficiency Video Coding (HEVC)
  • 2014 (Version 2) Major amendment - added approval for 25 new profiles.

You did note in that last the ".. addition of 25 new profiles", yes? The same type of active timelines are also true for video technologies like VP8 and VP9 (HTML5, Google's Youtube). Then there are all the hardware based proprietary codecs which various manufacturers have decided upon for reasons including lockin and ease of manufacturing.

That's a lot of change over time and there are no signs that this rate of change will slow down. Playback is a stone cold beach.

Hardware Changes Too

Many of the above amendments and growth in profiles made to the h.264 and h.265 standards are done to meet the need of broadcasters and equipment manufacters for higher resolution, larger color space and higher frame rates. Those new resolutions, more capable devices and better broadcasts are here now, assuming of course, if you have the funds and are in the select areas of availability. Here are a few timeline points to give you some background:

UHDTV

  • 2012 Announcment of Ultra-high-definition television also known as UHDTV or UHD. Immediate availability of 4K displays/TVs.
  • 2013
    • January 8, activation of the first 4k dedicated UHDTV satellite channel by Eutelsat. The 4K Ultra HD channel has a frame rate of 50 fps and is encoded at 40 Mbit/s.
    • NHK and Mitsubishi Electric announced that they had jointly developed the first HEVC encoder for 8K Ultra HD TV. The HEVC encoder supports the Main 10 profile at Level 6.1 allowing it to encode 10-bit video with a resolution of 7680x4320 at 60 fps. At the NHK Open House 2013 the HEVC encoder used a bit rate of 85 Mbit/s which gives a compression ratio of 350:1.
    • YouTube adds a "2160p 4K" option to its videoplayer.
  • 2014
    • European Southern Observatory became the first scientific organization to deliver Ultra HD footage at regular intervals.
    • On September 4, 2014, Canon Inc. announced that with a firmware upgrade they will add support for the Rec. 2020 color space to their EOS C500 and EOS C500 PL camera models and their DP-V3010 4K display.
    • On November 19, 2014, rock band Linkin Park's concert at Berlin's O2 World Arena was broadcast live in Ultra HD via an Astra 19.2°E satellite.

There are a lot of terms here you don't need to be concerned with. The upshot is that hardware manufacturers and broadcasters implementing bigger and better multimedia everything right now. As they get more experience with both 4k and 8k playback, you can be certain they'll request futher changes/additions to the new HEVC standards as well.

What to Look for in a Video Player

Codec Support

Coder/decoder support is the first and most important factor to consider in a video player. If your player can't understand the container/format or the video/audio/subtitle data stream it's trying to play, then that player will be useless to you.

If you're coming from the Windows world and are new to Linux, you are probably more familiar with the concept of Codec Packs such as CCCP and K-Lite. Codec packs such as these were individually collected codecs from multiple sources in a single package. In Windows, the collection would identify and register each codec to the operating system and then any player which was Windows aware of Microsoft's infrastructure for calling codec dlls could use any of the newly registered codecs. In theory, this is nice but .. This gets real complicated real fast as the number of available codecs goes up. Also, this method and the supporting infrastructure is subject to the whims and limitations built-in by Microsoft design. For example, it's virtually impossible to build a reasonable transcoder under this design.

Aside from Microsoft's built-in limitations, traditional codec packs are dependent on others to update each individual codec in the collection. This means that the availability of the updated codec you need for a new video release is at the mercy of both the original source of that codec and the Codec Pack collecting group.

FFmpeg and Libav can be viewed as the Linux/OSX/BSDs equivalents of Codec Packs but they are much, much more than that. Since they are based upon open source code, the individual codecs can be updated at any time. Since they are not Codec Packs, they are not subject to the built-in limitations of the Windows environment. Being able to easily create/stream your own videos as well as transcode an existing video from one container/format/resolution to another is a natual consequence. At the time of this writing, FFmpeg supports 395 different video/audio/subtitle codecs on the author's systems.

FFmpeg or Libav

Libav is a fork of FFmpeg. From your, the user's standpoint, the most visible difference between the two libraries is that Libav doesn't support some user desired features including some subtitle formats as well as external vob based subtitles. All the recommended media players here either are built only with FFmpeg or they preferentially default to FFmpeg.

It should be noted that while Libav seems to ignore FFmpeg's development efforts, FFmpeg frequenty merges all of Libav's development efforts. The net result is that Libav features are a subset of FFmpeg.

For these reasons and without considering user invisible merits, we prefer FFmpeg as our codec engine.

Active Development Community

It should be crystal clear that any Video Player worth installing requires two important though intangible components.

  1. You the user must take responsiblity to install an updated version regularly. This is true of all PC environments. Many fansub encoders will experiment with new encoding profiles as they become available. Updating your player is the best way for you to keep your playback ability current.
  2. The player you choose must have an active, accessible development community. All the players listed here are in active development.

What Not to Look for in a Video Player

Not Using Either ffmpeg or libav

As part of their core functionality, both ffmpeg and libav are established codec libraries. They represent a large collective effort over time in the reverse engineering of hundreds of assorted codecs. It's almost impossible for any project to build such a library of codecs on their own. As a result, media players which only go with internally written codecs and possibly combined with externally available single codecs are always limited to very specific niche playback categories. Notably, media players which are internal to game engines are an example of this.

The rule of thumb is to avoid any media player which doesn't make use of either ffmpeg or libav. xine(ui) was originally built this way but now includes ffmpeg in order to be able to playback h.264 and HEVC.

Not Permitting Use of External Codecs

While ffmpeg and libav include hundreds of internal codecs, these codecs are not all written to the same quality. For this reason, both MPlayer and mpv support the inclusion and use of select external alternative codecs. This allows both media players to use better codecs than the ffmpeg/libav intenally provided ones.

Don't Use Third Tier Media Players

We define third tier players by how far they are removed from the source underlying media player they rely on. This is probably best explained by example. Since you're reading this page from the Linux user's perspective, you'll most likely be running one or more of the available Window Managers/Desktop Environments. We'll pick on KDE (Komputer Desktop Environement) for this particular example. Other desktops will do something similar if they provide this functionality at all.

In KDE and also depending on the linux distribution you use, you can either install or build in a media player. In the case of KDE, KDE will pull in a KDE native wrapper for mplayer. At the present time, this media player is named "Dragon". On the Author's systems, It's configured to be based on a version of mplayer with makes use of ffmpeg. This would seem like a "good thing" but there are problems.

  • You cannot update Dragon outside of your distribution's KDE update schedule.
  • Most distributions seem to build Dragon without access to external codecs. i.e. You're limited to your distribution's decisions regarding what to in/exclude in Dragon.
  • Depending on your distribution's release policies (more on this further down), Dragon may be limited to only 'stable' versions of mplayer and mpv player and, by extension, ffmpeg or libav. In the case of mplayer, the last official 'stable' version dates back to May 2013.

What's true for Dragon under KDE is true for all natively built media players which may be included in all other Windows Managers/Desktop Environments and similar.

'Stable' Version Media Players

All distributions have software release policies. These release policies control which versions of any given package are nstalled and under which circumstances each version is installed. Most distribution's policies have a minimum of two levels generally defined as 'stable' and 'unstable' or equivalent. A smaller set of distributions will also have a 3rd tier referenced as 'developer' or 'alpha'. These three levels are commonly viewed as:

  1. Stable - Tried and true versions with no known unexpected behavior. This level intended for business systems and expecially for critical business infrastructure.
  2. Unstable - Latest official release by package provider for 'official' beta testing. These versions have all the latest available features for their category of package. In common practice, this is the level nearly all home users and most business desktop users want to be on. If you're not on this level or it's equivalent in your distribution, we recommend you consider looking at it.
  3. Developer or Alpha Testing - This means building directly from the same source code library the developer is working from.

Noted earlier, the last 'stable' version of MPlayer dates back to May 2013. As of this writing, that's almost 2 years ago. Also as of this writing, the last 'stable' mpv player version is 0.8.3 dated March 17, 2015. If you have a requirement for 'Stable' versions only of the distribution you use, then you should consider mpv player over MPlayer.


Update Notice

This page is currently being updated/rewritten.
Everything below this notice is part of the old page and will be removed as applicable updates are applied.

Please revisit often.

MPlayer

Installation

Perform one of the following commands as root, depending on your distribution. If you do not find information pertaining to the distribution you use, refer to your distributions documentation.

Debian Based Distributions

mplayer is packaged for Debian. As root:

apt-get install mplayer

However, this is often not the newest release (especially if you are running Debian stable) and does not contain support for all codecs. In particular, very old builds may not have 10-bit support. Such users will want to install newer packages:

  • Double-check what version of Debian you are running (cat /etc/debian_version). If it contains any (or more than one) of the words "wheezy", "jessie", "sid", "testing", or "unstable", or a number starting with 7.0, you're already current enough and the command above should do.
If it is a number starting with 6.0, consider upgrading your system, as this is now an old release. If that's not an option, continue on:
apt-get -t squeeze-backports install mplayer

Old codec (RealVideo) support

The "official" Debian mplayer packages are now (as of 2012) much better than they used to be, and so you probably don't need to load third-party repositories any longer. However, if you need to decode old RealVideo or QuickTime files, you might need them for the binary-only decoders. In that case only:

apt-get update && apt-get install mplayer deb-multimedia-keyring

apt-get will warn you about unsigned packages the first time you run this; allow them. Installing the keyring package will eliminate those warnings for future upgrades.

For RealVideo support, then install the packages w32codecs (32-bit OS) or w64codecs (64-bit OS).

Ubuntu

To be sure that you can play video files encoded using certain proprietary codecs, it may be useful to install w32codecs (32-bit) or w64codecs (64-bit) from the package manager. Not all users will require this, but many find it useful all the same. This package is one of those installed as part of ubuntu-restricted-extras. A full list of the codecs which require this package is available here.

Since mplayer is a command-line application, it might be useful to install a GUI front-end like gnome-mplayer like so:

sudo apt-get install gnome-mplayer

OpenSuse

zypper in mplayer

Red Hat Based Distributions (Including Fedora)

MPlayer is not in the official Fedora repositories. You will have to add and enable the RPM Fusion third-party repositories before being able to install MPlayer.

yum install mplayer

Arch Linux

pacman -S mplayer

Gentoo

emerge -ptva mplayer

MPlayer codecs

Not all distributions include the full set of MPlayer codecs in their repositories, although these are often not needed except for Real or Quicktime videos. To install the full set follow these easy steps.

  1. Download: http://www4.mplayerhq.hu/MPlayer/releases/codecs/all-20071007.tar.bz2
  2. Extract with: tar xvf all-20071007.tar.bz2
  3. Copy the codecs (but not the directory) to the MPlayer codec directory. Default is /usr/lib/win32

GPU Acceleration

NVIDIA VDPAU

If you use an NVIDIA GPU be sure to install their latest binary drivers as they offer a feature that enables offloading video decoding from the CPU to GPU which may provide smoother video playback, especially for h264 encoded videos, while keeping CPU usage at low levels. Check your MPlayer configuration to use the VDPAU video output (–vo vdpau). Type "mplayer –vo help" to list available outputs.

Note that this generally offers no advantage (yet) for Hi10p encodes, which are not hardware supported. With modern desktop CPUs — roughly 2011 or newer — GPU decoding may actually be slower for some files. If you encounter stuttering with one setting, try it the other way: "–vo xv" for CPU decoding, "–vo vdpau" for GPU decoding.

  • Debian, Ubuntu users: Install the drivers with apt-get install nvidia-glx nvidia-kernel-dkms

ATI

The open-source video driver now supports AMD's UVD hardware-decoding functionality via VDPAU (with linux 3.11 and later).

The proprietary video driver provides hardware accelerated video decoding (and indeed, only works at all) for R600+ based GPUs.

  • Debian users: Install the drivers with apt-get install fglrx-glx fglrx-modules-dkms
  • Ubuntu users: apt-get install fglrx
  • Other distributions usually package the driver as either fglrx or catalyst

Note: The above packages are only valid for HD5000 chipsets and over, HD2000-4000 users should check their distribution's documentation for how to install the legacy variant.

Exposing the video decoding capabilities over VA-API (e.g. for use with VLC, mplayer or xine) requires the additional package xvba-video. XBMC (only) can natively use AMD's XvBA (the Linux DXVA equivalent) built-into the proprietary driver. Neither MPlayer nor MPlayer2 support VA-API in their standard releases, but there is an MPlayer branch mplayer-vaapi with VA-API capability.

MPlayer tweaks

This is a sample configuration file tailored for specific preferences. The MPlayer configuration file can be found at: ~/.mplayer/config. All of the options are documented in the manual.

# If you have a multicore CPU, use as many threads as you have cores.
lavdopts=threads=4
# Use the GPU accelerated video output driver if available.  If not, fall back
# to xv (which offers good speed on most cards) as a safe backup.
# For audio output, always use ALSA.
# Sometimes "vo=xv,vdpau," gives better results!  Test on your own system.
vo=vdpau,xv,
ao=alsa
# 4 audio channels for surround sound files
channels=4
# Default audio and subtitle tracks. (Not all files use the correct tags,
# so sometimes it will be necessary to switch streams manually with '#' and 'j'
# or from the command line with "-aid x" and "-sid x")
alang=jp,jpn,
slang=en,eng,
# Find ASS subs and use the fonts provided in the file if possible
ass=1
embeddedfonts=1
fontconfig=1
# The highest level of subtitle anti-aliasing
spuaa=4
# Less stdout text
quiet=1

MPlayer Tricks

MPlayer has a large collection of video filters included. You may use them to achieve different results.

  • Play interlaced video without combing:
mplayer -vf pullup myvideo.ext
  • Increase saturation and contrast:
mplayer -vf eq2=0.8 myvideo.ext
  • Remove "mosquito" noise:
mplayer -vf hqdn3d myvideo.ext
  • Make crappy video look good:
mplayer -vf pp7 myvideo.ext
  • Combine:
mplayer -ass -embeddedfonts -vf pullup,eq2=0.8,unsharp=l3x3:0.2,hqdn3d myvideo.ext

SMPlayer

SMPlayer provides a QT based front-end to MPlayer. It contains useful features such as saving the video position allowing you to continue watching the video from that point at a later date.

Installing SMPlayer

Debian Based Distributions (Including Ubuntu)

sudo apt-get install smplayer

You can also:

  • Download the .deb file from the SMPlayer website or
  • Add the SMPlayer repository to your /etc/apt/sources.list.

8.04 (hardy):

deb http://ppa.launchpad.net/rvm/ubuntu hardy main

8.10 (intrepid):

deb http://ppa.launchpad.net/rvm/ubuntu intrepid main

Arch Linux

pacman -S smplayer

Gentoo

emerge -ptva smplayer

Red Hat Based Distributions (Including Fedora)

You will need to enable the RPM Fusion third-party repositories to be able to install SMplayer.

yum install smplayer

Building from Source (Compiling)

Grab the tarball from the SMPlayer download page. Decompress it, cd into the directory, and run

./configure
make
sudo make install

If you don't have sudo installed/configured, then the last step will be instead

su
make install

SMPlayer tweaks

After installation you may want to configure SMPlayer. Start SMPlayer, open the options (Ctrl + P), go to the subtitles section, within the section go to the SSA/ASS library tab and check the check box for using SSA/ASS library.

If you see a black screen at playing, the colors don't seem to be right, or playback is too slow, you may need to change the video rendering mode. To do this go to the Options > general section > general tab > output drivers > Video, and set it to x11 - this will use software rendering. Alternatively you can use xv for XVideo rendering or either gl or gl2 for OpenGL rendering. In general you should try these options in the following order for best quality and performance: xv, gl2, gl and finally x11.