Page 1 of 10

GIANT UPDATE: Build FFmpeg and mpv – Automatically in 54 Minutes!

Posted: Tue Dec 12, 2017 4:20 pm
by RPi_Mike
WITH MY AUTOMATED SCRIPT and a Raspberry Pi 3 you can play or encode almost any video or audio – from the last century's most obscure formats to the very latest in high definition. In fact, my script creates a system so muscular, it will play 1080p live-streamed video without the slightest hiccup. This is extraordinary when you stop and consider that all that capability is coming from a $35 computer that fits in the palm of your hand. How does it do all that? My script does it by automatically building customized versions of FFmpeg, mpv, and several advanced encoders in only 54 minutes! You will get powerful GPU-based hardware acceleration, full-screen display, and extensive decoder, encoder, and filter support. I have also included detailed benchmarks that reveal the Raspberry's outstanding video performance when its GPU is fully utilized. Finally, I wrote ten separate appendices with tons of useful information, including how to use mpv and FFmpeg – and how to download and stream the highest-quality videos from hundreds of websites with a tool known as youtube-dl. At more than 16,000 words, this is the most comprehensive media-related resource for the Raspberry Pi.

JULY 2019 UPDATE: Do you have the brand-new Raspberry Pi 4? Are you using the equally brand-new Raspbian Buster operating system? If so, please see my statement.

GIANT UPDATE – SEPTEMBER 1, 2018: I have now brought the latest versions of the world's leading media engine and player to the Raspberry Pi: FFmpeg 4.0.2 and mpv 0.29.0. The raw source code for these programs was released just a few weeks ago. Many of you probably know this post used to be called "TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv". But I have now taken things to the next level and combined the best of two worlds – an automated script filled with plain-English annotations that explain exactly what I'm doing at every step. That way, it still serves the purpose of a learning-oriented "tutorial" while also making it extremely simple to get your system up and running as a media powerhouse. It will take less than 5 minutes to prepare my script for execution! Automating the process is not only much faster and less tedious, but it greatly simplifies my instructions and dramatically reduces the chance of making mistakes. Perhaps the biggest enhancement with this latest update is full support for all major forms of live streaming, including the HLS protocol. That means you can watch (and record) live broadcasts from sites like YouTube, Twitch, and the national news outlets of Japan, Germany, Australia and France (please see my screenshots). I have also revised and updated this entire post and all 10 appendices from top to bottom. Ever since December 2017 when I first published my findings, I've been gratified by the many people around the world who have enjoyed my customized build of FFmpeg and mpv. In fact, I was pleasantly surprised that one of the leading engineers at the Raspberry Pi Foundation personally recommended it.
NASA.jpg (225.96 KiB) Viewed 52908 times
This 1920 x 1080 screenshot was taken directly from my Raspberry. Captured from a 1080p video, this supercomputer simulation of colliding neutron stars demonstrates the power of my script. Full-screen mode in mpv is always "pure video" with no distractions – but for informational purposes, I have superimposed the small Terminal window in the upper-left corner to show the video's flawless statistics (including no dropped frames). Quite simply, the FFmpeg / mpv combination can handle almost anything you throw at it! To view this image at full resolution, right-click and select "open image in new tab" – or on phones and tablets, "tap and hold" and save it to your pictures for full-size viewing.

ORIGINAL UPDATE – JANUARY 2018: Although my tutorial has worked perfectly from the very beginning, a small but vocal minority objected to my use of the developmental "firmware" code provided by the rpi-update command. That choice was not dictated by me – it was dictated by essential GPU-related files that are missing in the Raspberry's stock firmware. Although no one reported an issue with this command, I conducted an exhaustive binary compare of the stock and developmental firmware codes – more than 4,000 files in total. Through this effort, I identified 4 tiny files that completely eliminate the need for rpi-update!

DUAL TECHNOLOGIES: FFmpeg and the mpv media player are the two most fundamental video and audio tools in the Raspberry Pi universe. This is equally true in the larger open source and Linux multiverse. On the content-creation and encoding side, nothing beats the power and flexibility of FFmpeg. And on the content-consumption side, nothing beats mpv. Simply put, if you’re a Raspberry Pi user and want to share video or audio with anyone in the world, you need FFmpeg to encode it. And if you want to enjoy high-quality video and audio with a truly capable media player, you need mpv to decode and play it. The two work hand-in-hand – FFmpeg is the "engine" that mpv uses to render video and audio. But having just any version of these programs is NOT sufficient. Instead, both programs must fully support hardware acceleration via the Raspberry’s GPU – using the MMAL API to decode, and the OpenMAX API to encode. There’s only one way to do all that and my script makes it happen.

METHOD: My script uses raw source code to build the latest versions of FFmpeg, the mpv media player, and several advanced encoders – with all necessary Raspberry-specific tweaks. Building from source code may sound complicated, but it’s the only viable way to experience multimedia nirvana on a Raspberry Pi. Anyone with a basic understanding of Linux can get my script set up and ready for execution in less than 5 minutes.

REQUIREMENTS: My script will work on any standard Raspberry Pi 3! It will fully execute and finish in only 54 minutes on the model 3B+, and only 58 minutes on the model 3B. All you need is the completely free Raspbian Stretch operating system (initially released on August 17, 2017). Advanced users should know that the stripped-down "lite" version of Raspbian will not work with my script, nor will it work for those who use the experimental desktop GL drivers (via raspi-config). The bottom line is actually very modest and simple – all you need is the current version of the Raspberry Pi's standard operating system. That's it! I don’t have a Raspberry Pi 2, but since the architecture is very similar, there’s a decent but non-guaranteed chance that my script will also work reasonably well on that device. Other versions of the Raspberry will definitely not work.

WHAT, SPECIFICALLY, WILL THIS SCRIPT GIVE ME? My script will enable your Raspberry Pi 3 to play almost any audio or video on any HDMI-capable TV or monitor – in full screen mode – at all resolutions up to 1920 x 1080. In fact, no media player does a better job than mpv at playing all these files: MP4, WebM, MKV, MOV, MPG, TS, AVI, WMV, MP3, M4A, WAV, FLAC – and many others too numerous to mention! But it goes far beyond just playing files: The advanced encoders and FFmpeg will allow you to encode audio and video into multiple formats – including MP4 videos with the most universally-playable codec pair (H.264 for the video track and AAC for the audio track). You will also be able to choose high-quality, software-based H.264 video encoding – or much faster GPU-accelerated H.264 encoding. FFmpeg is also a powerful "media engine" that will allow you to edit, manipulate, filter and convert audio and video in countless ways. Finally, my script will create freestanding Debian software packages that will allow you to quickly install or re-install everything you need on any Raspberry Pi 3 – in only one minute! That means this script is a one-time thing. Once you’ve run it, you'll be in possession of several state-of-the-art packages that can be rapidly installed at any time.

FULLY TESTED AND PROVEN TO WORK: This is not your typical script or "tutorial". If you look for information on hardware-accelerated mpv on the Raspberry Pi, you will find tantalizing bits and pieces on the Internet – most wrong, some right. But nowhere in the entire Googleverse will you find a complete procedure that actually works. All of the existing documentation is generic and utterly useless in dealing with the Raspberry’s unique CPU and GPU architecture. But I was determined to transform my Pi into a truly capable multimedia machine – so I personally struggled with this, off and on, for several weeks and experienced great frustration. That is why I decided to make this contribution to the Raspberry community instead of keeping it to myself. I tried to write everything in a clear, explicit way that does not "assume knowledge" or skip even the slightest step. I also took the time to fully test and validate my script on a clean install of Raspbian Stretch – the Raspberry Pi’s latest operating system. Of course, all operating systems are subject to change at any point in the future – but at the time of this writing, I can confidently say that every aspect of my script works perfectly!

WHY SO COMPLICATED? In a perfect world, you would simply go to the FFmpeg and mpv official websites and download "the Raspberry Pi version" – then double-click the files and relax as they automatically install. Unfortunately, no such thing exists! You will see Linux versions, but they only run on Intel and AMD-based systems – not the ARM-based architecture that the Raspberry uses. You will also find the raw "source code" for each program – but that’s of no use unless you’re a sophisticated user. And even if you are quite advanced, you’ll almost certainly get tripped-up – because there are a whole series of insanely obscure and undocumented Raspberry-specific issues that must be overcome. Or wouldn’t it be nice if you could just type "sudo apt-get install mpv" and have everything work? For reasons I explain below, that won’t work either.

DETAILS & BACKGROUND: Versions of FFmpeg and mpv are available in the Raspbian software repository. In fact, they are now the "official" encoder and media player of the Debian Stretch distribution of Linux, upon which Raspbian Stretch is based. Unfortunately, due to a perfectly legitimate desire to maintain backward compatibility with older Raspberry models, the repository – accessed via "sudo apt-get install" – only provides a generic build of mpv (and an older version of FFmpeg). As a result, mpv is unable to take advantage of hardware acceleration, and therefore does not leverage the Raspberry’s surprisingly powerful on-board GPU to play video. Instead, all video is rendered "in software" by the CPU. Because of this, videos bigger than 240p will drop frames and "stutter". The stuttering gets so bad that at 1080p, the frame rate drops to 0.5 – half a frame per second! That's 60 times too slow for standard 30 FPS video.

Some might point to OMXPlayer as a potential solution. It is, after all, the Raspberry’s only "official" media player with hardware acceleration support. But the playing options and keyboard controls offered by this aging player are severely limited. More importantly, the other leading video format – the more advanced and newer WebM (VP9) – is simply not supported by OMXPlayer. This is not trivial, given that YouTube – the world’s largest provider of video – only supports two major video formats: WebM (VP9) and MP4 (H.264). In the coming future, when the next-generation open source AV1 codec becomes widely deployed, having access to a state-of-the-art media player will be even more crucial.

The other leading potential contender – the generally well-regarded VLC media player – is only available in a more limited and older "stock" version on the Raspberry platform. Its WebM performance is poor and high-resolution MP4s are subject to frame drops. In fact, at the time of this writing, VLC 3 – the latest version – can't even be compiled to support hardware acceleration on the Raspberry.

And what if you need to encode a video in the ONLY modern format that works on every major browser and media player? That "universal" format is of course an MP4. But keep in mind that an MP4 is merely a "container" and file extension. What really matters is what’s on the "inside" – the actual codecs used to encode the video and audio. On the video side, the only universal choice is H.264 (sometimes referred to as AVC or AVC1). That can be done with the advanced "x264" codec – which is included in my script. And on the audio side, the best universal choice (and MP3 successor) is AAC – specifically, the excellent Fraunhofer implementation of AAC (Advanced Audio Codec). That is also included in my script. My builder code provides the very latest versions of these encoding technologies.

Finally, what if you wish to take advantage of hardware-accelerated H.264 encoding on the Raspberry? For those of you that run my script, you will gain access to the "h264_omx" hardware encoder. This leverages the Raspberry’s GPU to encode H.264 video, resulting in a roughly three-fold speed-up in encoding time (versus the software-based, but higher-quality, x264 codec).

TESTING RESULTS & IMPORTANT TECHNICAL COMMENTARY: As the saying goes, "I ate my own dog food". That means I pretended to be a complete novice and robotically followed my own instructions without any assumed knowledge. All my testing was conducted on a standard Raspberry Pi 3B+ with a clean, brand-new installation of the standard operating system (Raspbian Stretch). My results? Everything worked extremely well! Quite frankly, I continue to be astonished by the performance of such a small and inexpensive computer. With the customized versions of FFmpeg and mpv that my script provides, the Raspberry really shines.

MODEL 3B vs 3B+: I also ran my script and duplicated my testing on the original and slightly slower Raspberry Pi 3B. I did this to guarantee that everything works on the older model as well. With MP4 videos, performance was identical and flawless. This makes sense, given that the GPU is the same on both models. However, since WebM rendering is entirely CPU-based (and because the 3B's CPU is about 14% slower than the 3B+), the frame throughput at 1080p was about 98% to 100% perfect instead of 99.6% to 100% perfect. Given the minor performance difference with WebM videos, it shows that non-CPU factors play an even bigger role when it comes to video formats not supported by the Raspberry's GPU – such as RAM speed and internal bus speed.

60 FPS VIDEO: My original tutorial, which used FFmpeg 3.4 as mpv's "engine", could easily handle 60 FPS MP4 video. However, due to the increased computational demands of FFmpeg 4, my extensive testing has shown the "internal" frame rate for 1080p MP4s is now 48 FPS instead of 60. This, however, is a better-than-even trade-off when you consider that the latest combination now fully supports 1080p live streaming – a significant capability that did not previously exist. That also explains the attributes I have given the "ytdl-format" line in mpv's configuration file. It ensures that a command line like "mpv" will automatically download and play the best possible video that does not exceed mpv's capabilities (above 1080p or above 30 FPS).

WebM (VP9) VIDEO PERFORMANCE: Please see Appendix 10 – Technical Notes and Observations – for extensive commentary on this subject (space is limited on this page).

Here are my testing results – for both mpv (decoding/playing video) and FFmpeg (encoding video). All frame rates are 30 FPS:



MP4 video (H.264 video / AAC audio): 0.0% dropped frames (100% perfect)

WebM video (VP9 video / Opus audio): 0.4% dropped frames (99.6% perfect)


MP4 video (H.264 video / AAC audio): 0.0% dropped frames (100% perfect)

WebM video (VP9 video / Opus audio): 0.1% dropped frames (99.9% perfect)


MP4 video (H.264 video / AAC audio): 0.0% dropped frames (100% perfect)

WebM video (VP9 video / Opus audio): 0.0% dropped frames (100% perfect)



Software-Based H.264 Encoding (CPU): 2.6 FPS (11.5 times slower than real time)

Hardware-Based H.264 Encoding (GPU): 6.3 FPS (4.8 times slower than real time)


Software-Based H.264 Encoding (CPU): 18 FPS (1.7 times slower than real time)

Hardware-Based H.264 Encoding (GPU): 38 FPS (1.3 times FASTER than real time)

INSTRUCTIONS: Here, finally, are my instructions. The following script uses raw source code to "build" and install the latest versions of FFmpeg and mpv on your Raspberry Pi 3. It also builds 3 advanced encoders – x264 (for H.264 video), Fraunhofer AAC (for AAC audio), and LAME MP3 (for MP3 audio). My entire script will only take about 54 minutes to finish on the model 3B+ and about 58 minutes on the model 3B.

WHAT IF I HAVE A PROBLEM? Carefully re-read my requirements section. I've been surprised at the number of people in the past who skimmed over my tutorial and completely ignored my requirements section or warnings. For example, some went ahead and tried to do it with the "lite" version of Raspbian – even though I explicitly said it will NOT work with the lite version! My script only takes a few minutes to set up, but these instructions definitely require your full attention. It's not the kind of thing you can do while watching your favorite TV show!

WARNING #1: Compiling a million+ lines of source code is very intense and will push all 4 cores in your CPU to their limits for a prolonged period of time. If you do not have adequate heat dissipation, your Raspberry could overheat to above 80° Celsius (176° Fahrenheit) and will throttle-back, lock-up or crash – or even worse, it might quietly corrupt your code in random ways without you even knowing. Then you might get stuck with inexplicable behavior that will be impossible to troubleshoot. Keep in mind that the temperatures I've mentioned are not that far away from boiling water – 100° Celsius / 212° Fahrenheit – so this matter needs to be taken very seriously! [On the model 3B+, Raspbian will automatically throttle the CPU back from 1.4 GHz to 1.2 GHz if you exceed 60°. If it does that, my claimed "54 minutes" will obviously not apply.] In my experience, your Raspberry MUST have a fan if you do heavy-duty compiling. So it’s worth getting a small 40mm fan that attaches to your Raspberry’s case and sits directly above the CPU. The model 3B+ has a superior thermal design to the 3B, so I have found that a tiny fan is sufficient with the newer model. But if you run my script on a 3B, you may also want to have copper heatsinks on the 3 main chips. If your Raspberry doesn't have its own fan, you can carefully hang your Raspberry (by the rugged HDMI cable) in front of a standard house fan. That should "blow away" enough heat to keep your Raspberry cool enough to get through the compiling!

KNOW YOUR CPU's TEMPERATURE: When you're doing heavy compiling, you definitely don't want to fly blind – at least not until you have a good idea of your Raspberry's thermal behavior. So monitor your CPU temperature by doing this: Right-click the Task Bar and click Add / Remove Panel Items. Then click the Add button; scroll down and double-click "Temperature Monitor"; then click the Close button. With just a tiny 40mm fan and no heat sinks, my 3B+ never exceeds 58° Celsius!

WARNING #2: My script takes less than an hour to complete and does not require any human intervention. So you can relax and have a sandwich while your Raspberry does all the hard work! However, be aware that the script is "vulnerable" for the first 2 to 3 minutes. I designed it on purpose to download everything it needs at the beginning – so that once it gets past that point, it's completely independent of the outside world (except for the very end where it downloads youtube-dl and a brief demonstration video). Just know that during the first couple minutes, my script is obviously at the mercy of your Internet connection – and is dependent on all the remote servers being fully up and running (GitHub,, etc.). Since my script has no control over these external factors, it's a good idea to watch it at the beginning to make sure it gets through that phase. If it doesn't, my best advice is to stop everything and delete all 3 script-related folders – Vidware_Downloads, Vidware_Build, and Vidware_Packages – and just re-boot and start all over again at a later time!

WARNING #3: There is no specific risk associated with my script – but I still wish to mention 2 basic items of common sense advice: (1) Always keep a backup copy of any data you would not want to lose and (2) Always have a second working copy of the Raspbian operating system available – or at least the means to easily make one with the aid of a separate computer. I highly recommend the SD Card Copier to make a backup of your existing system in less than 10 minutes – it's a free program that comes with Raspbian. You can access it at Raspberry Menu | Accessories | SD Card Copier.

WARNING #4: Have you already built and installed FFmpeg 3.4.1 and mpv 0.27.0 with my original tutorial? If so, my best advice is to start with a completely fresh, unused copy of the Raspbian operating system if you want to GUARANTEE that everything works perfectly (my script is 100% certified to work on an unaltered copy of Raspbian). But if you're absolutely sure that your existing system is completely functional and totally "normal" in every way – see Step 2, below, for what I mean by that – then you at least need to remove your old installations of FFmpeg and mpv (and the encoders) to prevent any potential conflict. So if that applies to you, run the these 2 simple lines in Terminal before you proceed:

sudo dpkg -r ffmpeg mpv x264-snapshot-20180125-2245 fdk-aac lame libass libvpx opus

sudo rm -r /home/pi/.config/mpv

SCRIPT ETIQUETTE: My script is "polite" and makes a backup copy of any existing file associations you've manually added, as well as any package-pinning preferences you've made (I'm sure most of you haven't pinned any packages anyway). If any of this matters to you, please see my thoroughly annotated script for the location of these backup files.


Make sure no programs are running. The only open window on your system should be Terminal. Copy the following line, paste it into Terminal, and hit the Enter key:

sudo apt-get update

NOTE: When the following command asks if you want to continue, press "y" and hit Enter. If the screen goes blank after 10 minutes of keyboard inactivity, you can *CAREFULLY* tap the SHIFT key to reawaken the display:

sudo apt-get dist-upgrade

***Close Terminal



Before you proceed, let's make sure you really have a completely "normal", truly standard, and fully updated version of the Raspbian Stretch operating system! I am especially dubious of systems that have been "upgraded" from Raspbian Jessie to Raspbian Stretch (as opposed to a completely clean install, from scratch, on a blank SD card). This isn't just my opinion – it's the opinion of the Raspberry Pi Foundation in their official release statement. And I quote: "As this is a major version upgrade, we recommend using a clean image; these are available from the downloads page on our site as usual. Upgrading an existing Jessie image is possible, but is not guaranteed to work in every circumstance."

Now, open Terminal and interrogate your system with the following command:

lsb_release -a

You should now see the following output:

No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch

BIG WARNING: If your results diverge even slightly from the above output, please don't bother using my script – unless of course you live in the future and the version number has since moved to 9.5 or greater. Even then, there are no guarantees – I obviously have no control over the behavior of future operating systems! Also, if it says "9.4" but does not explicitly say "stretch", please abandon this tutorial and carefully review my "requirements" section and what I just said about Jessie. Even if your results precisely match the above output, be on notice that your success is still questionable if you have merely "upgraded" from Jessie. On top of that, even if you superficially meet all the requirements I'm describing here, your success is still questionable if you've been "tinkering" with your Raspberry – modifying system files, changing fundamental system settings, or "experimenting" with other media players. If that's the background of your Raspberry – especially if you're not a total expert – it's probably a good idea to start with a completely clean install of your operating system if you want my script to run without a hitch!

I must also assume that you have not "monkeyed" with the default user name or home path. In other words, I must assume that when you launch Terminal, it automatically opens inside the standard home path – /home/pi. My script is based on very reasonable and basic assumptions, so if you've changed all that you'll need to carefully edit my entire script without making a single mistake – or better yet, just nuke your entire system and make it NORMAL!

Now, if you're truly certain your Raspberry Pi 3 is completely "normal" and meets all the above requirements, you may proceed!


The default GPU memory setting on the Raspberry is 64 MB. Mpv requires 128 MB or it will not work – so let's change that setting:

Click the Raspberry Menu | Preferences | Raspberry Pi Configuration | Performance Tab

Change "GPU Memory" to 128

Click OK | Click No to reboot (You’ll be rebooting soon anyway – so rebooting now is not necessary.)


Open Terminal and run this command:

leafpad vidware

You should now see the Raspberry's standard text editor (known as leafpad). That's what you'll be pasting my script into.

Now, carefully copy my entire script – which appears below – and paste it into the empty leafpad document. Make certain you successfully copied everything and didn't accidentally leave out a few characters or lines at the top or bottom. After you've verified everything, press ctrl + s to save the file and then close leafpad. The file should automatically be called "vidware".

Now, flip back to Terminal and enter this command line – it will make my script executable:

chmod u+x vidware


OK, the moment of truth has arrived! As long as you followed my instructions to the letter, your Raspberry will automatically create a whole bunch of free presents for you in less than one hour!

GIVE YOUR RASPBERRY A FULL MINUTE AFTER IT BOOTS UP TO FULLY "CALM DOWN" AND RELAX BEFORE YOU RUN MY SCRIPT! And this should be obvious, but I'll say it anyway: After you've given your system a fresh reboot, the only "program" running on your Raspberry should be your Terminal screen! That's it! My script is very intense and requires the full attention of your system.

To run my script, simply open Terminal and run the following command line. Please memorize it or write it down on a piece of paper. After your system has had a fresh reboot, do NOT re-launch the memory-hogging web browser to look at these instructions again!

bash vidware



##### Vidware_Downloads: My script philosophy is to keep things clean and simple. That's why my first step is to create 3 different folders to keep the main elements of my script completely separate from each other. Before anything can be built, we first have to download 6 files in the form of "stable release tarballs". This is the raw source code my script will use to build the 6 programs. We also need 4 GPU-related files from the Raspberry Pi Foundation's official GitHub site that provide OpenGL ES and EGL support (they allow mpv to "talk" to the Raspberry's VideoCore GPU and thus facilitate hardware acceleration). Finally, we need a "waf" file that will allow us to build mpv. All of this will go inside the "Vidware_Downloads" folder – which we're creating with the mkdir command:

mkdir Vidware_Downloads

##### Vidware_Build: This is the folder where all our "building" will take place – the folder where the raw source code of 6 programs will be compiled and transformed into working software. The "primary" programs are FFmpeg and mpv. But my script also builds a mandatory library called libass – a subtitle renderer that mpv requires. It also builds an advanced H.264 video encoder (x264) and two advanced audio encoders (Fraunhofer AAC and LAME MP3):

mkdir Vidware_Build

##### Vidware_Packages: This folder will remain empty until the very end of the script. When the script is about 95% complete, all 6 programs will be fully built, installed, and "packaged". These packages are free-standing Debian installers (commonly known as .deb files). What makes these so incredibly useful is that at any time, you can use them to automatically install (or re-install) all the programs on another Raspberry or your existing Raspberry in the future – IN ONLY ONE MINUTE! No scripts or "building" required! My script will conveniently place all of them in the Vidware_Packages folder – so be sure to back them up to a safe place!

mkdir Vidware_Packages

##### I've discovered an odd quirk about checkinstall: If we don't manually create a standard usr doc path before running it, checkinstall will fail to install some of our programs. This affects the LAME MP3 encoder – but not having the path up to "doc" also affects FFmpeg (even if you don't build or install LAME). This command line takes care of that:

sudo mkdir -p /usr/share/doc/lame

##### You'll see a lot of "echo" commands in my script. Why? Because I like VISUAL SEPARATION. A simple echo command inserts a blank line in Terminal's output:

echo; echo

##### The echo command is also the tool I'm using to "print" information on the Terminal screen – such as letting the user know that we're about to download the tarballs. I also "pipe" the output of echo through the "fold" command with the "-s" option. This ensures my longer sentences are properly "word wrapped" and that my words aren't abruptly cut in half when they hit the edge of your Terminal screen:

echo "------------------------------"
echo "Now downloading the source code tarballs and other essential files for building FFmpeg, mpv, and the 3 advanced encoders. At a connection speed of 1 MB per second, it will take less than 20 seconds." | fold -s
echo "------------------------------"

##### We're about to download all the files that the script needs. It may look like a lot, but the grand total is less than 18 MB! This is quite impressive when you consider that FFmpeg alone contains more than one MILLION lines of source code! Before we do the downloads, however, we need to change our current working directory to the Vidware_Downloads folder with the cd command:

cd /home/pi/Vidware_Downloads

##### This is where my script downloads the 11 files it needs. At the time of this writing – August 2018 – all URLs link to the most recent versions available. Be careful if you think you can simply update these links to get even more recent versions in the future! Other parts of my script make specific assumptions about these particular versions. So unless you fully understand all aspects of my script, you definitely don't want to do that!

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

wget -q --show-progress --no-use-server-timestamps

##### For backup purposes – and for mental clarity – I deliberately decided not to "wget" the files directly into their ultimate destinations. Instead, I wanted all the downloads to first be consolidated into the Vidware_Downloads folder – and then copy them over, later on, into wherever they need to be. So that's what I'm doing here. Sudo is required, by the way, because the opt parent folder (and its children) are owned by user "root", not "pi". If we didn't add the "sudo", we would get a "permission denied" error:

sudo cp /opt/vc/lib

sudo cp /opt/vc/lib

sudo cp glesv2.pc /opt/vc/lib/pkgconfig

sudo cp egl.pc /opt/vc/lib/pkgconfig

##### The script downloaded version 2.0.9 of waf (the version that mpv 0.29.0 expects). But mpv also expects the file to simply be named "waf", not "waf-2.0.9". That's why I'm renaming it here with the mv command. Finally, since waf is a Python script that needs to be executed in order to build mpv, I'm using the chmod command to make it executable by the user that owns the file (which in this case is the user named pi):

mv waf-2.0.9 waf

chmod u+x waf

##### This makes an exact copy of our 6 source code tarballs (for FFmpeg, mpv, etc.) and places them inside the Vidware_Build folder. Some of the tarballs end in tar.gz, while others end in tar.bz2 – hence the 2 separate lines:

cp *.gz /home/pi/Vidware_Build

cp *.bz2 /home/pi/Vidware_Build

##### We're pretty much all done with the Vidware_Downloads folder at this point – so we now need to make sure the script is performing its actions inside the Vidware_Build folder. That's why we cd into it. We then need to "unzip" the 6 source code tarballs into folders – that's what the 2 "ls" lines with the xargs command does (for technical reasons, you can't use a simple asterisk wildcard to unzip multiple tarballs in the same folder). Finally, I delete all the tarballs in the build folder with the rm command. Why? Because we already have the original copy of them in our Vidware_Downloads folder – so there's no reason to clutter things up with duplicate tarballs!

cd /home/pi/Vidware_Build

ls *.gz | xargs -n1 tar xzf

ls *.bz2 | xargs -n1 tar jxf

rm *.gz

rm *.bz2

##### I don't want to keep seeing "fdk-aac-0.1.6" as the source code folder name, for example. That's just confusing. Instead, I just want to see "aac" – because that's what it really is. It's the AAC audio encoder! That's why I'm simplifying all the source code folder names by renaming them with the mv command:

mv ffmpeg* ffmpeg

mv mpv* mpv

mv x264* x264

mv fdk* aac

mv lame* mp3

mv libass* libass

##### We can now copy over the waf file into the mpv source code folder:

cp /home/pi/Vidware_Downloads/waf /home/pi/Vidware_Build/mpv

##### This is where we install the dependencies we need to build all 6 pieces of software – via "sudo apt-get install". Read my statement in the echo line for more detail:

echo; echo
echo "------------------------------"
echo "Now downloading and installing the dependencies – essential packages from the official Raspbian repository that are needed to build the programs. At a connection speed of 1 MB per second, it will take less than 50 seconds to download. It will then take about 5 minutes for your system to install all the packages." | fold -s
echo "------------------------------"

sudo apt-get install -y automake checkinstall libsdl2-dev libva-dev libluajit-5.1-dev libgles2-mesa-dev libtool libvdpau-dev libxcb-shm0-dev texinfo libfontconfig1-dev libfribidi-dev python-docutils libbluray-dev libjpeg-dev libtheora-dev libvorbis-dev libgnutls28-dev linux-headers-rpi2 libomxil-bellagio-dev xdotool libcdio-cdda-dev libcdio-paranoia-dev libdvdread-dev libdvdnav-dev libbluray-dev

##### This begins the "software building" phase of my script. We're configuring and compiling the source code for our first program – the advanced x264 video encoder. That's what people mean by "building" a program. In the "./configure" line, we're enabling and disabling various options that will customize the build in the manner necessary for everything to work. We then compile the program with the "make -j4" command – which is quite impressive given that the "j4" means that all 4 cores inside the Raspberry's CPU will be computing simultaneously! For more information on how to use the encoders with FFmpeg, please see my extremely detailed appendices. After the x264 encoder is fully built, I use the checkinstall command to both install the program and "package it up" into the extremely useful .deb installer packages I mentioned earlier. The final line – sudo ldconfig – is essential in making sure the "shared libraries" are properly recognized.

echo; echo
echo "------------------------------"
echo "Now building the x264 video encoder. This will take about 2 to 3 minutes." | fold -s
echo "------------------------------"

cd /home/pi/Vidware_Build/x264

./configure --prefix=/usr --enable-shared --disable-opencl --extra-cflags="-march=armv8-a+crc -mfpu=neon-fp-armv8 -mtune=cortex-a53"

make -j4

sudo checkinstall -y --pkgname x264 --pkgversion 0.155 make install

sudo ldconfig

##### We now move on to build and install the Fraunhofer AAC audio encoder. I don't need to say much here because I already described the basic outline of the "building from source code" process in my above comments about the x264 encoder.

echo; echo; echo
echo "------------------------------"
echo "Now building the Fraunhofer AAC audio encoder. This will take about 3 to 4 minutes." | fold -s
echo "------------------------------"

cd /home/pi/Vidware_Build/aac


./configure --prefix=/usr --enable-shared

make -j4

sudo checkinstall -y --pkgname fdk-aac --pkgversion 0.1.6 make install

sudo ldconfig

##### Now we build and install the LAME MP3 audio encoder:

echo; echo; echo
echo "------------------------------"
echo "Now building the LAME MP3 audio encoder. This will take about 1 minute." | fold -s
echo "------------------------------"

cd /home/pi/Vidware_Build/mp3

./configure --prefix=/usr --enable-shared

make -j4

sudo checkinstall -y --pkgname mp3lame --pkgversion 3.100 make install

sudo ldconfig

##### Now we build and install the libass subtitle renderer (mpv will not work without this software library):

echo; echo; echo
echo "------------------------------"
echo "Now building the libass subtitle renderer. This will take about 1 minute." | fold -s
echo "------------------------------"

cd /home/pi/Vidware_Build/libass

./configure --prefix=/usr --enable-shared

make -j4

sudo checkinstall -y --pkgname libass --pkgversion 0.14.0 make install

sudo ldconfig

##### Now we build and install FFmpeg! This is the very powerful media "engine" at the center of everything we're doing. The last 3 "--enable" lines under "./configure" enable FFmpeg to access the 3 advanced encoders – x264, Fraunhofer AAC, and LAME MP3. Compiling a million+ lines of code is INTENSE and could easily overheat your CPU. Your Raspberry must therefore have its own small fan or an external fan blowing on it. Please see the explicit warnings on this subject in my instructions!

echo; echo; echo
echo "------------------------------"
echo "Now preparing to build FFmpeg. This will take about 2 minutes." | fold -s
echo "------------------------------"

cd /home/pi/Vidware_Build/ffmpeg

./configure \
--prefix=/usr \
--enable-gpl \
--enable-nonfree \
--enable-static \
--enable-libtheora \
--enable-libvorbis \
--enable-omx \
--enable-omx-rpi \
--enable-mmal \
--enable-libxcb \
--enable-libfreetype \
--enable-libass \
--enable-gnutls \
--disable-opencl \
--enable-libcdio \
--enable-libbluray \
--extra-cflags="-march=armv8-a+crc -mfpu=neon-fp-armv8 -mtune=cortex-a53" \
--enable-libx264 \
--enable-libfdk-aac \

echo; echo; echo
echo "------------------------------"
echo "Now building FFmpeg. This will take about 24 minutes on the Raspberry 3B+ (and 2 or 3 minutes longer on the 3B)." | fold -s
echo "------------------------------"

make -j4

echo; echo; echo
echo "------------------------------"
echo "Now installing FFmpeg. This will take about 7 minutes." | fold -s
echo "------------------------------"

sudo checkinstall -y --pkgname ffmpeg --pkgversion 4.0.2 make install

sudo ldconfig

##### Now we build and install mpv. Unlike the prior builds which were fairly straightforward, I'll add a few extra comments here – because I had to do quite a bit of arcane tweaking to successfully "port" mpv to the Raspberry platform with full GPU-based hardware acceleration.

echo; echo; echo
echo "------------------------------"
echo "Now preparing to build mpv. This will take about 1 minute." | fold -s
echo "------------------------------"

cd /home/pi/Vidware_Build/mpv

##### In this section, I'm using the sed command to manipulate mpv's raw source code before we build it. The first edit specifically targets line 767 of mpv's wscript file. The wscript file contains the "building instructions" for mpv. There are more than 1,100 lines of code in the file, but only 18 of them are directly related to the Raspberry. The line I'm editing makes reference to a generic OpenGL ES "linkflag". With the sed command, I'm doing a "search & replace" so that it will now make reference to the Broadcom-specific version of the linkflag (Broadcom is the manufacturer of the Raspberry's VideoCore GPU). Beginning with the next line, I delete an entire stanza (13 lines) of audio-related source code and then replace it with 20 lines of modified and expanded code. Specifically, it affects how mpv interacts with the ALSA framework. Without this change, mpv would throw various audio-related "[ao/alsa]" errors. Hat tip: My ALSA source code patch combines the ideas of mpv contributor "orbea" and user "yumkam" on mpv's official GitHub site. And then we have the final sed line – it serves absolutely no purpose other than to give a bit of credit to yours truly!

sed -i_BACKUP '767s|GLESv2|brcmGLESv2|g' /home/pi/Vidware_Build/mpv/wscript

sed -i_BACKUP '939,951d' /home/pi/Vidware_Build/mpv/audio/out/ao_alsa.c

sed -i '939i\
static int get_space(struct ao *ao)\
int err;\
struct priv *p = ao->priv;\
snd_pcm_state_t state = snd_pcm_state(p->alsa);\
snd_pcm_sframes_t space = state == SND_PCM_STATE_SETUP || state == SND_PCM_STATE_PAUSED\
? p->buffersize : snd_pcm_avail(p->alsa);\
if (space < 0) {\
if (space == -EPIPE) { // EOF\
err = snd_pcm_prepare(p->alsa);\
CHECK_ALSA_ERROR("pcm recover error");\
return p->buffersize;\
MP_ERR(ao, "Error received from snd_pcm_avail (%ld, %s)!\\n",\
space, snd_strerror(space));\
// request a reload of the AO if device is not present,\
// then error out.\
' /home/pi/Vidware_Build/mpv/audio/out/ao_alsa.c

sed -i_BACKUP '143s|built on|built by the RPi_Mike script on|g' /home/pi/Vidware_Build/mpv/player/main.c

##### The next 3 lines temporarily define the proper paths for 3 "environmental variables". Without these, mpv will not compile.

export LIBRARY_PATH=/opt/vc/lib

export PKG_CONFIG_PATH=/opt/vc/lib/pkgconfig

export CPATH=/opt/vc/include

##### This next section is fairly straightforward. This is where we build and install mpv! The only noteworthy point is that instead of using the "make" system to do our building like all the other programs in this script, we're using the "waf" system. That simply reflects the preferences of the mpv developers.

./waf configure --prefix=/usr --enable-rpi --enable-cdda --enable-dvdread --enable-dvdnav --enable-libbluray

echo; echo; echo
echo "------------------------------"
echo "Now building mpv. This will take about 2 minutes." | fold -s
echo "------------------------------"

./waf build -j4

echo; echo; echo
echo "------------------------------"
echo "Now installing mpv. This will take about 1 minute." | fold -s
echo "------------------------------"

sudo checkinstall -y --pkgname mpv --pkgversion 0.29.0 ./waf install

sudo ldconfig

##### This is where we create mpv's configuration file that controls how mpv behaves with ALL video and audio. Please see the full version of Appendix 1 for details; also see the testing section for commentary on the "ytdl-format" line. NOTE: The "alsa-buffer-time" completes the fix to the ALSA issue I described earlier. It defines an audio buffer time of 800,000 microseconds (8/10 of a second). Through extensive testing, I found that this was the final step needed to get mpv and ALSA to play nice together.

mkdir -p /home/pi/.config/mpv

echo "--fullscreen
--alsa-buffer-time=800000" > /home/pi/.config/mpv/mpv.conf

##### I didn't want users of my script to have to go through the 10-step "Open With" process in File Manager – over and over again – to associate every common type of video and audio file with mpv. So to save everyone a lot of time and eliminate this error-prone task, my script does it automatically! The first line demonstrates proper "etiquette" – before it creates the new associations, it first backs up your original mimeapps.list file (just in case you'd like to review or re-add your initial file associations). I then associate the following video and audio file types with mpv: MP4, WebM, MKV, TS, MOV, AVI, WMV, MPG, WAV, MP3, M4A, and FLAC.

cp /home/pi/.config/mimeapps.list /home/pi/.config/mimeapps.list_BACKUP &> /dev/null

echo "[Added Associations]

[Default Applications]

[Removed Associations]" > /home/pi/.config/mimeapps.list

##### Raspbian places its overall file association "system" in 2 separate locations. The items above act as a kind of pointer to the item below. The two work hand-in-hand. The following stanza generates a special kind of file known as a "desktop" file that ends with the ".desktop" extension – but also has an "alias" (in this case, "MPV") and an executable line that tells it what to do. My complicated use of bash -c and xdotool is the result of hours of testing – to guarantee that you never lose keyboard control of mpv, due to other windows stealing "focus" from mpv's Terminal window. You see, mpv relies upon an active Terminal window "behind the screen" to detect the keyboard inputs which allow you to control the video or audio being played. Of course, if you actively do things to lose keyboard control – like hitting alt + tab or randomly clicking the screen with your mouse – there's nothing I can do about that!

echo "[Desktop Entry]
Exec=lxterminal -t mpv_control -e bash -c \"sleep 0.25; xdotool search --name mpv_control windowactivate; mpv %f\"
Icon=mpv" > /home/pi/.local/share/applications/mpv.desktop

##### This section "pins" the advanced versions of the programs my script just built. Without doing this, anytime you run a standard system update via "sudo apt-get upgrade" or "sudo apt-get dist-upgrade", the Raspbian package manager might wrongly think the newly-built programs are old and therefore need to be "upgraded". They might then be overwritten with the older, more primitive versions that exist in the Raspbian repository! Pinning them, in effect, says to your system's packager manager: "Don't touch these programs – leave them alone!" As per standard etiquette, I first back up your preferences file – on the remote chance you've been pinning other packages. Hat tip to "rpdom" for his pinning suggestion.

sudo cp /etc/apt/preferences /etc/apt/preferences_BACKUP &> /dev/null

echo "Package: ffmpeg
Pin: version 4.0.2-1
Pin-Priority: 1001

Package: mpv
Pin: version 0.29.0-1
Pin-Priority: 1001

Package: x264
Pin: version 0.155-1
Pin-Priority: 1001

Package: fdk-aac
Pin: version 0.1.6-1
Pin-Priority: 1001

Package: mp3lame
Pin: version 3.100-1
Pin-Priority: 1001

Package: libass
Pin: version 0.14.0-1
Pin-Priority: 1001" | sudo cp /dev/stdin /etc/apt/preferences

sudo chmod 644 /etc/apt/preferences

##### In some ways, this next section just might be the coolest part of the entire script. That's because it takes the TRILLIONS of computations the script just performed – distilled into 6 tiny packages – and neatly places them in the Vidware_Packages folder. They contain everything you need to reconstitute all the programs on any Raspberry 3B or 3B+ IN ONLY 1 MINUTE! So when the script is all done and the demonstration video has played, be sure to back up the 6 .deb files to a safe location.

echo; echo; echo
echo "------------------------------"
echo "Almost finished! The Debian package files are now in the Vidware_Packages folder. You can use them at any time in the future to install all the programs my script just built! Now downloading youtube-dl and a brief 1080p demonstration video from YouTube. All of this should take less than 2 minutes. After the looped video starts playing, feel free to press the q key to quit." | fold -s
echo "------------------------------"

find /home/pi/Vidware_Build -name '*.deb' -exec mv -t /home/pi/Vidware_Packages {} +

##### This final section does 3 simple things: First, it downloads and installs the latest version of youtube-dl. If you already have it on your system, it will upgrade it (if necessary). If you don't have it, it will make sure you that you do. At that point, youtube-dl will download a very brief 1080p demonstration video from YouTube. And then comes the final act – mpv will play the video several times in a loop! Press q to quit at any time.

sudo pip install --upgrade youtube_dl

echo; echo

cd /home/pi

youtube-dl -f 137+140 --no-mtime -o Neutron_Stars_Colliding_1080p.mp4

echo; echo

mpv -version


mpv --loop=9 Neutron_Stars_Colliding_1080p.mp4


f key: Toggle the video between full screen and actual size

space bar: Toggle the video (or audio) between pause and play

left and right arrow keys: Rewind and fast-forward by 6 seconds

up and down arrow keys: Rewind and fast-forward by 1 minute

9 and 0 keys: Lower and raise the volume

o key: Make the on-screen display briefly appear to show time remaining, etc.

[ and ] keys: Speed up or slow down the video

q key: Quit out of the video (or audio)

WARNING: I had to greatly abbreviate this appendix to free up room on this page. See below for how to access the FULL versions of all of my appendices!


APPENDICES: Build FFmpeg and mpv – Automatically in 54 Minutes!

KEYWORDS: Raspberry Pi 3, RPi3, Pi3, 3B, 3B+, RPi, FFmpeg, mpv, tutorial, 1080p, MP4, H.264, AAC, WebM, VP9, Opus, x264, LAME, MP3, Fraunhofer, GPU, VideoCore, MMAL, OpenMAX, OMX, video, audio, encoding, decoding, compiling, source code, hardware acceleration

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sat Dec 16, 2017 11:00 pm
by treeHouse
Wow, this is beautifully done!
Thanks for the tutorial. I'll hopefully get a chance to try this out next weekend.

Can this build coexist with the accelerated vlc build outlined here?

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 7:18 am
by RPi_Mike
treeHouse wrote:
Sat Dec 16, 2017 11:00 pm
Wow, this is beautifully done!
Thanks for the tutorial. I'll hopefully get a chance to try this out next weekend.

Can this build coexist with the accelerated vlc build outlined here?

Thanks – I appreciate the kind words.

I'm almost hesitant to weigh-in on your VLC question. Many people use their preferred media player every single day. It's how they use their two most important senses to inform and entertain themselves – through sight and through sound. For obvious psychological reasons, many people will therefore develop a deep emotional attachment to their favorite media player – which also explains why they can get quite upset when one person claims a certain player is better than another. It reminds me of the never-ending "Mac vs. Windows" and "iPhone vs. Android" debates.

I have no association with the mpv and FFmpeg communities, so I can assure you that my feelings on this topic were completely agnostic just a few months ago. I went down the typical path I'm sure many other Raspberry users have traveled – first I tried OMXPlayer, then I tried VLC. I honestly didn't care what player did the job – I just wanted something to work. I wanted what most people want in a media player. I wanted FULL SCREEN NIRVANA. That means HIGH RESOLUTION. That means SMOOTH PLAY with no stuttering from frame drops. That means ANY FILE AND FORMAT will play. Everything I tried came up short, so I Googled some more and stumbled across this thing called "mpv". That didn't work either because of the typical Raspberry-specific roadblocks. But it was the moment I fell down the rabbit hole in a quest to get the most from my Raspberry Pi 3.

The Intel x86 architecture dates back to the 1970s, so it got a giant head-start in the Linux world over ARM-based systems. Although rapid progress continues to be made, the ripple effects of this history continues to haunt the Raspberry, and it's clearly reflected in the absurdly difficult time I had in getting a decent media player to work. Not just "work", mind you – WORK WELL! Many of us in the Raspberry community are quite advanced in the computer world, especially compared to the general population. But the irony is that a barely-literate computer user on Windows or Mac can just download and double-click a simple installer file and be all set in less than ONE MINUTE! They certainly wouldn't have to struggle off and on for several weeks, as I did, to get one program to work!

Since I have now written an extremely comprehensive tutorial on this subject, I freely admit that when it comes to the best media player on the Raspberry, I'm not agnostic anymore! FFmpeg and mpv are truly fantastic programs that work exceptionally well together. When properly customized to meet the unique architectural demands of the Raspberry, the results are nothing less than amazing – especially when you consider that all that "magic" is happening on a $35 device. After great frustration and effort, I finally came up with a solution that does everything I want.

As to your question of whether my hardware-accelerated FFmpeg / mpv build can coexist with a particular hardware-accelerated VLC build, the honest answer is WHO KNOWS! The only way for me to test that scenario would be to go through the painstaking process of following someone else's tutorial to theoretically achieve something I've already achieved! That wouldn't be too rational on my part. But there certainly could be problems. The required dependencies for anything as computationally intense as a hardware-accelerated media player are complex and intertwined – so there's certainly a chance that in attempting to install a rival media player, certain files might get overwritten or "updated" in unpredictable ways that will either break my tutorial or simply do weird things to the entire "environment" – an environment I like to keep stable, predictable, and pristine. That's why I began with a clean install of Raspbian Stretch. That way I can know there are no hidden assumptions or "accidental tricks" that allowed my method to work. Only in that context can I guarantee that my tutorial will do what it claims. Once someone starts tinkering with something as fundamental as the video and audio dependencies of their system, all bets are off. This would be true whether they do that tinkering BEFORE my build or AFTER my build.

Now, to put my blatantly partisan hat on for just a moment, here are a few quick observations on the VLC tutorial you referenced:

My tutorial is very lean and mean. It only requires 27 dependencies. But the VLC tutorial you referenced requires a whopping 224 dependencies – nearly 10 times as many. And yes, I actually counted them. Of course, even this isn't a fair comparison, since my tutorial provides a SUPERSET of features – a truly capable media player PLUS a full-blown encoding suite. It really is apples and oranges.

The author of the VLC tutorial says that "VLC requires quite a lot of shared libraries. Some may be already installed on your system, but we cannot be sure." He then lists 119 dependencies that must be installed. He then says in the next paragraph that "these libraries will enable us to run VLC, but to compile a new version we also have to add the matching development (-dev) packages". He then proceeds to list an additional 105 dependencies that must also be installed. 119 + 105 = 224 dependencies! Quite frankly, I would be afraid to install such an astonishing array of software packages to get one program to work! Even if it "works", that introduces so much unnecessary complexity and "package baggage" that all kinds of unpredictable things could happen to your system.

He also indicates that "SD video and some 720p video (RPi3) can also be played using software codecs, if you select SDL video output." In other words, there can sometimes be a need to manually change VLC's video output settings from "OpenMAX IL" to "SDL". With my build, however, the optimal hardware – GPU or CPU – is automatically selected on the fly without any user intervention. You just double-click the file and BOOM – it starts playing no matter what the format or codec. If the codec is supported by the GPU, it will use the GPU. If the codec requires the CPU, it will use the CPU.

For those who would like to know more about the performance and capabilities of my build, please review the detailed benchmarks under the "Testing Results" section of my tutorial.

UPDATE: Hello there, this is RPi_Mike – author of this tutorial – speaking from the future!

Down below, you'll see the hostile reception I received from a small but vocal group of critics who clearly didn't like my sudden encroachment upon "their" territory. It was my first post on this website – a fact that undoubtedly made my significant contribution quite provocative to the established tribe that inhabited this forum for several years.

JUST KNOW THIS: Their negative comments were either exaggerated, untrue or rendered utterly irrelevant when I published "version 2.0" of my tutorial just a few weeks later.

That was a full year ago. Since then, I've received numerous compliments and enough views to fill the majority of seats at the world's largest football stadium. I even took things to the next level when I published "version 3.0" – a fully automated script that does everything for you. As if that weren't enough, a leading engineer at the Raspberry Pi Foundation personally recommended my contribution.

For details, see my updates above. Or if you have several hours to kill, check out the 150+ posts on this thread to see the truth of my claims!

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 10:34 am
by gkreidl
Nice tutorial, but why do you think you have to use a big font everywhere?

WARNING: Do not advice people to run
sudo rpi-update
This will install experimental kernel and firmware and might break your system!

You are installing newer versions of a number of libraries, which may be used by other software as well (kodi, VLC, gstreamer, webkit browsers etc.). There's always a risk that other software depending on these libraries won't work any more. You should at least issue a warning about it.

Except for mpv you have not set the --prefix, which means that the default path /usr/local will be used. This means that there will be two sets of libraries in your system now (the new ones will take preference), as long as you install them using "sudo make install". By creating and installing .deb packages the old packages will be removed and only the new packages will remain (in a different place!). This also may lead to problems with other software. And removing the .deb packages might require to remove other packages as well, which depend on them. The only solution would be to replace them by the default versions again.

Regarding youtube-dl: It's much better to use pip to install and upgrade youtube-dl. The "fake-binary" contains 1000+ modules zipped in .py format which have to be converted each time you run the program. It's much faster to load them as precompiled .pyc files (programs starts about twice as fast). And the pip installation also allows other python software to use youtube-dl as a module (as I do in my youtube-dl-server to speed up video URL extraction).

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 3:22 pm
by RPi_Mike
gkreidl wrote:
Sun Dec 17, 2017 10:34 am
Nice tutorial, but why do you think you have to use a big font everywhere?

WARNING: Do not advice people to run
sudo rpi-update
This will install experimental kernel and firmware and might break your system!

Another poster simply asked for my thoughts on your VLC tutorial and I provided my technical assessment.

I'm sorry you don't like my font-size choice. I have a 1080p monitor hooked up to my Raspberry and the default font size was hurting my eyes, so my only motivation was to make the text a bit easier to read.

I'm reluctant to get into a tit-for-tat with you on each point, because I can already tell from the tone of your first message that you'll find it irresistible to fire back with counter-points to everything I say. I'm simply not here to get into an ongoing argument with anyone. My tutorial stands on its own merits. It's tested and proven to work. Are there certain minor elements in my procedure that a total expert might legitimately quibble with? Probably so! Although if there is such an expert, they haven't taken the time to create a tutorial that actually works like I have!

Nonetheless, I will make a one-time exception and respond to your comments.

Your "WARNING" to me about sudo rpi-update is overly dramatic. It also seems a bit inappropriate to be issuing a "WARNING" to a fellow member of the community who made a good-faith contribution. Are you the Raspberry police? You make it sound as though I was advising people to install some kind of bogus file from a random website. The rpi-update command in my instructions is a built-in feature that comes pre-installed with the Raspberry's official operating system, as sanctioned by the Raspberry Pi Foundation. Among other critical things, the command updates the VideoCore libraries. The VideoCore IV, of course, is the Raspberry's GPU. Having the latest updates for the GPU is essential for my tutorial to work as fantastically well as it does.

It's also ironic that you dwell on the libraries my tutorial installs when your tutorial installs a BLIZZARD of libraries 10 times bigger than mine. Do I agree with your general observation that any installation of software can "break" a system? OF COURSE I DO! Nothing in life is guaranteed, and that certainly applies to *anything* one does on the Raspberry. Everyone should follow common-sense practices and keep a backup of their important data.

But even if a Raspberry "breaks", the worst outcome is to run NOOBS again. Or in my case, I keep a cloned SD card with a fresh install of Raspbian PLUS all the "core" software I use. If anything bad happens, I simply pop out the cloned card and make another clone – and I'm back up and running with a full system in only 10 minutes! For those of you who wish to do this, I highly recommend the free "SD Card Copier" tool that comes with Raspbian.

Beyond all these theoretical concerns – negative events that have never happened to me – I can't help but mention that my system is extremely stable and both FFmpeg and mpv are working great!

Ultimately, I'll leave it to the other readers to decide which tutorial they wish to follow with this simple chart:

–––––––––––––––––––– MY MPV ––– YOUR VLC

REQUIRED DEPENDENCIES:_____ 27 __________ 224


Finally, as to your comments on youtube-dl, I'll also leave it to the other readers to make their own judgments. In this case, my installation advice for youtube-dl was taken directly from their official website – written by the actual developers who made the program! It is the FIRST method they advise. The pip method you suggest is the THIRD method listed. Now, I don't necessarily dispute your very specific technical claim. What you say sounds credible – the pip method might lead to a slightly faster load time, although I must say that my copy is very responsive as it is. But since you feel your installation method is "much better", I suggest you take it up with the developers of youtube-dl so that they can follow your sage advice and reverse the order of their suggested installation methods. Here's their official installation instructions in case anyone wants to see it for themselves:

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 3:57 pm
by jccj78
Very great theoretical contribution RPi_Mike!!!
For a novice like me it has been very helpful.
Thank you.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 4:06 pm
by DougieLawson
You really don't need to use [size=140], just get your browser to magnify the text if you can't read it using [CTRL] and [+] keys.

Anyone suggesting that brand new users run sudo rpi-update is irresponsible. It can (and has done) break your system so that it's not bootable. If you don't know what it does and how it can break a system then don't recommend it. The stock, standard, safe & tested kernel and bootcode are delivered with apt-get upgrade and apt-get dist-upgrade.

Anyone who has a pressing need to run sudo rpi-update should backup their SDCard and know how to recover their system from that backup in minutes rather than hours. I won't recommend it unless I'm 100% convinced that the experimental kernel and bootcode will solve a problem.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 4:49 pm
by gkreidl
The "warning" was for the users, not for you. You may break your system, if you like, but you should not add this advice it to a general tutorial. Dougie has said everything what has to be said about it above.

Regarding dependencies: the number is not so important, but adding newer versions (not from the repository) is always risky. That's simply violating Debian policy. Of course anybody can do that - and I'm doing it myself sometimes - but people should be aware of the risks.

I don't want to enter any kind of stupid "competition" between your ffmpeg/mpv installation and VLC and so I'll stop here.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 5:09 pm
by fruitoftheloom
RPi_Mike please can you edit your posts and put text back to standard size for this forum :roll: :roll:

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 5:14 pm
by RPi_Mike
DougieLawson wrote:
Sun Dec 17, 2017 4:06 pm
I won't recommend it unless I'm 100% convinced that the experimental kernel and bootcode will solve a problem.

For me, the bleeding-edge firmware code solved a very real problem – it proved to be a critical element in getting the FFmpeg / mpv combination to provide maximum performance.

Nonetheless, I have no objection to issuing a simple warning about basic "data safety" – always having a backup for both your data and your operating system itself. Your suggestion is perfectly reasonable.

As a result, I have now included a warning IN ALL CAPS in Step 2 of my tutorial.

PS: I have seen several of your posts over the last few months and greatly respect your technical opinions – you're clearly one of the most technically sophisticated and prolific posters on this forum. What I didn't entirely appreciate, however, was your condescending "lesson" on how to use my browser – complete with exaggerated font effects to amplify your ridicule. I simply thought the default font size was too small and difficult to read, so I made use of the built-in font size tool to make it bigger. I didn't realize that was a cardinal sin.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 5:16 pm
by DougieLawson
fruitoftheloom wrote:
Sun Dec 17, 2017 5:09 pm
RPi_Mike please can you edit your posts and put text back to standard size for this forum :roll: :roll:
You can always fix it the other way with [CTRL] & [-] to reduce RPi_Mike's antisocial font size to something more readable.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 6:07 pm
by mahjongg
I have/will edite(d) all posts with size =140 (or 125) settings, to turn them back to normal, please don't do this!
wasnt it a hint enough that I edited your post, you really couldn't resist undoing my changes?

Anyone who wants to increase the text size can do so himself with his browser, so I consider increasing the text size impolite, like shouting in public.

If necessary I will make the edit, and then simply lock the thread!

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 6:44 pm
by RPi_Mike
DougieLawson wrote:
Sun Dec 17, 2017 5:16 pm
fruitoftheloom wrote:
Sun Dec 17, 2017 5:09 pm
RPi_Mike please can you edit your posts and put text back to standard size for this forum :roll: :roll:
You can always fix it the other way with [CTRL] & [-] to reduce RPi_Mike's antisocial font size to something more readable.

I can't believe I'm getting sucked into a debate about font size, but allow me to provide some essential context that makes my initial font size choice seem perfectly reasonable.

Believe it or not, I actually put considerable thought into my initial font size choice – because I'm fully aware that people can get quite worked up about such things. For some, it's like not knowing what a caps lock key is and SHOUTING EVERYTHING IN ALL CAPS. I've never been clueless or obnoxious like that.

So I made a sincere effort from the very start to "get it right" and be respectful. Here's what I did when I made my very first post with my giant tutorial:

Since font sizes often use arbitrary units that vary from site to site, I had no idea what "normal" size was in Raspberry land. So to find out, I selected some text and clicked the "normal" option under the text-size button to get its numerical code. But it didn't do anything – I assume that was because the text was already, by default, in a "normal" size, so the button was simply ignoring my input by design.

At that point, I had no way of knowing what the numerical value for "normal" was. But I noticed that if I clicked "small", it gave me a value of 85. And if I clicked "large", it gave me a value of 150. So I calculated the midpoint and rounded to the nearest multiple of 5. I realize that numerical patterns can be non-linear, but it was all I had to go on. That gave me a theoretical value of 120 for "normal" text. My thought was that "normal" looked too small and "large" looked too big. So I actually went to extreme lengths to select a socially-appropriate font size. I ended up picking a value of 140, which is just a hair above the 135 midpoint between normal and large. In other words, I had every right to see my choice as being "large normal" – well within the bounds of reasonable and a far cry from "antisocial".

Some of you guys obviously didn't see it that way, but it is what it is. It seemed quite unfair to get ridiculed for something I actually made a genuine effort to be courteous about.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 17, 2017 8:04 pm
by RPi_Mike
mahjongg wrote:
Sun Dec 17, 2017 6:07 pm
I have/will edite(d) all posts with size =140 (or 125) settings, to turn them back to normal, please don't do this!
wasnt it a hint enough that I edited your post, you really couldn't resist undoing my changes?

I feel I need to defend myself on this one, because it could create the FALSE perception that I was somehow being sneaky or underhanded by deliberately not taking the "hint" and undoing your changes behind your back.

The simple fact is I didn't know they were your changes! All I knew was that my font settings mysteriously changed only minutes after a regular member said they didn't like my font size. So my first thought was that my account had been hacked and that I was being subjected to some kind of retaliation. I also speculated that maybe it was a weird bug and that it was just a coincidence. Either way, I was determined to put my settings back to where I had left them! And yes, I briefly considered the possibility that it was an official of the Raspberry Pi Foundation who was using their legitimate authority as a moderator to change things at their discretion. But I reasoned that if it were a legitimate change, I would have received some kind of official communication to indicate this – an email or private message to inform me that I had unintentionally violated "the font size policy". So although I *FULLY* understand why you might have thought I was being sneaky and couldn't take a hint, the supreme irony is that I thought someone was being sneaky with me!

Anyway, the font size matter is what it is. I've now learned that it's a very sensitive issue on this website and I will not attempt to modify my font size settings ever again. I promise!

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Mon Dec 18, 2017 9:06 pm
by mahjongg
The normal font size is what you get when you DO NOT FIDDLE WITH THE SIZE OPTION, and leave it alone (the default even says "Normal" size).

To aberrant from that you have to put size = tags around the text you want to resize, or use the re-size pulldown menu, so its obvious you are doing something abnormal.
no-one else but you, or a moderator can edit your posts, seems obvious to me, if anyone else could edit your posts it would be like anarchy in here.

You may claim you didn't think you did anything out of the ordinary. But look how many posts there are here that have enlarged text, it is almost none! Yes we have a simple to use re-size option, but it is meant to be used sparingly!

Ill leave it to that.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Tue Dec 19, 2017 5:50 am
by RPi_Mike
mahjongg wrote:
Mon Dec 18, 2017 9:06 pm
The normal font size is what you get when you DO NOT FIDDLE WITH THE SIZE OPTION, and leave it alone (the default even says "Normal" size).

To aberrant from that you have to put size = tags around the text, you want to resize, or use the re-size pulldown menu, so its obvious you are doing something abnormal.

FINAL THOUGHTS ON "FONTGATE": I have only one issue with your analysis. I never "put size = tags around the text". Instead, I innocently clicked the built-in text size button and it automatically inserted the tags all by itself! I simply changed the number inside the tag to a smaller and more respectful value – from large (150) to smaller than large (140).

This may seem like a trivial distinction, but I feel it's important because it creates yet another false and unfair impression about me – that I was doing something "abnormal" and "aberrant", to use your words. It makes it sound like I was being sneaky and deviously "hacking" the font size code with some kind of undocumented trick to be "antisocial", as DougieLawson put it the other day.

What makes the "sneaky and abnormal" narrative even more unfair is the giant elephant in the room: The text-size button is a highly visible and built-in tool on the forum. I didn't put it there – the Raspberry Pi Foundation did. Any reasonable person would conclude that the tool, like all tools, is there for a reason – TO BE USED! So, I used it. And I used it in a well-intentioned and thoughtful manner. As I explained earlier in great detail, I even made mathematical calculations to determine the optimal font size. What more could a person do? Given the tremendous length of my tutorial, my only goal was to make my writing as easy on the eyes as possible by default – for everyone – without requiring end-user browser adjustments. That doesn't make my design choice aberrant or antisocial. Quite the opposite: It means I was trying to make things easier to read for everyone by using a tool that was provided to me! Nonetheless, I believe that "when in Rome, do as the Romans do". Now that it's been made abundantly clear that small font sizes are sacred on this site, I will respect that unfortunate cultural norm.

THE PRIESTHOOD: For just a moment, I'd like to step back from the absurdity of a font-size debate and take the 30,000 foot view on all this:

I deeply respect what you guys do and have been quietly reading the excellent commentary and advice on these forums for several months.

I have been watching things on here long enough to be aware of the basic sociology of this site. There's a large number of novices and intermediate-level users on this forum. And then there's a very small but elite "priesthood" of Raspberry gurus that dominate the discussions. These "alpha males" have achieved their status through great knowledge and expertise, and by generating a vast number of posts (numbering in the thousands and tens of thousands per individual). These prolific and technically sophisticated persons have been on here for a long time and would certainly include DougieLawson (5 years), fruitoftheloom (4 years), and gkreidl (6 years).

Given the surprising level of grief I encountered on a single obscure topic like font size, I should hasten to add that my calendrical values are based on standard accounting principles and are therefore rounded to the nearest year. :P

So you have the priesthood. And then there's me. I just got my first Raspberry six months ago. And I joined this forum only eleven DAYS ago – a complete stranger from out of nowhere. The established tribe is understandably suspicious about the newcomer.

This newcomer, however – though not as technically advanced as the priesthood – just made a very significant contribution to the entire community. He is the first person in history to publish a comprehensive, step-by-step tutorial that transforms a standard media player on a $35 computer into a multimedia juggernaut. Quite astonishingly, it plays full screen 1080p video at 60 frames per second without skipping a beat. It even switches between GPU and CPU modes on the fly. Sure, there are "media centers" like Kodi that are quite excellent. But they place the user inside a full-blown "environment". I'm not suggesting there's anything wrong with that approach, but it is a distinct experience from a simple and straightforward media player. THAT is my contribution.

Researching, developing, validating, and writing-up my extremely comprehensive 6,500-word tutorial obviously took dozens of hours. If I were charging standard market rates for my service, it would literally cost thousands of dollars. Yet I DONATED IT to the Raspberry community in an act of philanthropy and good will.

As you can see in the posts, however, the priesthood didn't quite seem to appreciate my efforts. In fact, their reaction was entirely negative. Perhaps they considered it to be an overly bold encroachment upon their established territory. Other than a sarcastic "nice tutorial", there was no acknowledgment of my significant contribution. In fairness, they expressed a legitimate concern about *ONE* experimental line in my entire tutorial; I acted reasonably and updated my instructions to incorporate their caveat. I can't help but note, however, that even the priesthood did not dispute the fantastic performance claims of my tutorial. Instead, they decided to focus on my choice of font size and ridicule me for it! I also found it quite hilarious that they all suddenly appeared out of the woodwork to attack my font size in the space of just a few hours. I can almost imagine them messaging privately among themselves and saying "hey, some dude just came on the board who thinks he's so smart – let's put him in his place!" I can't say I'm surprised, however. From a primatological and evolutionary psychology standpoint, this is pretty standard territorial defense behavior.

I am heartened, however, by the genuine appreciation of the regular members. As you can see in the posts above, one said my tutorial was "beautifully done", while another said "very great theoretical contribution RPi_Mike!!!" And to them I say: THANK YOU!

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Tue Dec 19, 2017 1:22 pm
by g4bch
Thank you for the detailed ‘How To’. As far as my limited testing has gone so far mpv seems to be working. And I not yet found anything to have been broken.
For anyone having got this far past the font size stuffand contemplating trying this, I did have problems with compiling ffmpeg. Despite having a fan, heatsinks and an official power supply the RPi froze several times. I eventually got it to compile by using –j2 instead of –j4 to give the processor some spare capacity and by turning off the screen blanking. I’m not sure which of those actions cured teh problem, the object was to get it to compile rather that find out exactly why it would not. I did not note the time taken to compile with only 2 cores but it did not seem to take all that long.

Thanks again for teh detailed instructions


Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Tue Dec 19, 2017 2:56 pm
by Gadgetguy
Mike, it is great and greatly appreciated to have such a well written and sorely needed contribution on what should be a very important subject to to those of us who use their Raspberry Pi’s for multimedia. because MPV is at the moment probably the pre-eminent and best multi-platform media player especially when used as the engine for Smplayer on Windows and Linux. and it does work very well on the Pi, once you, as you eloquently note get past the rather difficult process of compiling from source.. ( my but that’s a long sentence! )

In my opinion, it definitely has not received the attention it merits in the Raspberry forums probably because there are still some easily deployed and very good and serviceable alternatives which I still use, like G. Kreidl’s estimable Omxplayergui,an integral part of his Kweb suite which he scrupulously maintains and recently updated with a web interface with on the fly resizable fonts!!! that makes it particularly well suited to television users playing all local media files in a folder or from a playlist. It pays dividends to read his manual! Another recent media player that has received no attention on the Raspberry forums that also uses omxplayer is Tomxplayer (Tactical omxplayer) which has a very nice interface and is simple to use and set up- just install the deb file from his site: ... layer.html

It was incidentally given a very enthusiastic endorsement from Martin Wimpress, the main man at Ubuntu Mate. That being said and as you noted MPV brings additional and valuable capabilities, It also has a few minor disadvantages when used on the Pi. Bottom line I think it is nice to have a variety of media players and web browsers in the quiver and available to Pi users. Horses for courses, as they say. Variety is the spice of life etc.,etc

I have been using MPV as the engine for Smplayer on Windows for some time and have been happily using them both on the Raspberry Pi for over a year and one half.. Like you I was impressed with it’s capabilities and astonished at the paucity of reference to it on the Raspberry forums, and that users seemed largely unaware of it. I felt it was too good to keep its many felicities to myself and accordingly made several posts to the forum in the hope this would lead to further and easier access to users and the further development and refinement of it on the Raspbian users infinitely better qualified than myself ( alas still a linux novitiate with no experience at all in coding or compiling.)



I have frequently made reference to it in my infrequent posts in attempt to proselytise it’s virtues. .When I encountered your post I was actually on the verge of posting an update to some of my previous posts to elucidate on my further experiences and some changes I made to mpv and smplayer configurations, and to pose some questions I hoped could be answered. I was also going to post the dependencies, configurations etc that I found successfully compiled ffmpeg and mpv on a fresh Stretch image, As one who had a weak grasp of such things I felt inadequate to the task .

My experience mirrored your’s eg. mountains of research from disparate sources not all of them applicable to the Pi ,determining the dependencies,figuring out the proper configuration options experiencing numerous compiling failures , going through logs filled with cryptic unfamiliar names trying to figure out what went wrong, checking forums and bug trackers on Git. Oh the fun! My compiling time for ffmpeg was roughly the same as yours. I have a case for my Pi 3 that came with a fan but I never installed it since I found it rarely got particularly hot and I didn’t want the drain on power, but when the ffmpeg compile got going and as temperatures approached 80 I started blowing furiously on the Pi to cool things down!(It worked!)
I would like to find a cheap mini usb fan that I can run externally only when needed.

I know rules are rules and if they aren’t followed it can lead to anarchy but I too felt (that especially to a new contributor) that it was a bit unfair and unwelcoming to belabour the focus on font size to the point that the substance of your important contribution ( I think) ) seems to have been largely ignored rather than welcomed. To tell the truth I sort of appreciated the font size because I am myopic and view my Pi display on a television screen from a distance. But rules are rules! Perhaps you too, got a little testy in your responses to some very valued and senior members of the community (understandable when you obviously put so much work in your tutorial ) At this point I think everyone should just cool it and concentrate on substance. I sort of wish your post had been made to the general section or to the raspbian section of the forum where it would probably have received more attention. By the way that's another rule that is strictly enforced you can’t cross-post the same subject to more than one section.

In your post you mention backing up deb files( a really really good idea) in case ffmpeg. Mpv etc gets overwritten on an update. You can easily lock your compiled version via the gui Synaptic package manager (the very first thing I install on a fresh Raspbian image ) or you can do it by command line (off the top of my head I forgot the command. As a stupid old geezer I like to use a gui when I can.

In my opinion probably seconded by millions of users( unless you are an extreme minimalist) on other platforms the enjoyment and utility of mpv is greatly enhanced by using it as the engine for the smplayer gui rather than standalone. This is even more true on the Pi .Since you configured your ffmpeg with mmal i presume your video output is in the form of an overlay. This is in my opinion the biggest disadvantage of mpv on the Pi. However this disadvantage can be mitigated and even made into something of a virtue via a hack I employ in the mpv.conf file and also in the configuration of smplayer.. My current mpv.conf file reads:


The entry :


instructs mpv when the keyboard toggle “f” is used to toggle back and forth between a full screen and a small overlay pseudo-window if you will, that takes up 20% of the display and that starts at 1075 pixels from the right and 550 pixels down from the top and on my my television screen with a native resolution of 1360x768 this places a small but crystal clear video ( rendered as overlay rather than window) just up from the bottom right hand corner where it can be monitored and listened to without interfering too much with the rest of the screen and then toggled back and forth to fullscreen by using the keyboard command “ f ” . Obviously this hack could be varied to suit personal preferences. Another hack I experimented with was to instead put the following entry into the configuration file “ autofit=1% “ which allows you to toggle back and forth between fullscreen and a minuscule nearly invisible dot but still retain audio playback. Various configurations options using autofit and geometry are described in mpv's online manual referenced above. I fid it incredibly confusing. I would be very interested in hearing from other users of mpv what other options might be available for viewing mpvs video output in non full screen configurations. This hack allows you multitask, continue browsing, manipulate controls, change configurations etc. While still monitoring the video in a small unobtrusive window

The entry: rpi-background=yes instructs mpv to paint a black background on the sides if a standard definition video does not take up the full width of the screen as this is more aesthetically pleasing and less distracting

The entry : ytdl-format=bestvideo[ext=mp4][width<=1920][height<=1080]+bestaudio[ext=m4a]/best[ext=mp4]/best

instructs mpv to play the best quality video returned by youtube-dl within the parameters specified.

All these configuration options can also be entered in smplayers configuration as well and I do so by going to the tab options/preferences/advanced/mplayer/mpv/ and selecting run mpv in it’s own window and pasting the desired options in the options space. My currently used smplayer options are :

--geometry=20%+1075+550 --rpi-background=yes --hwdec=rpi --ytdl-format=bestvideo[ext=mp4][width<=1920][height<=1080]+bestaudio[ext=m4a]/best[ext=mp4]/best

which in this case are the same as I use in mpv. If you are using mpv via smplayer the specified configuration in smplayer will tbe used rather than those in the mpv.conf

Using mpv with the smplayer gui brings a number of advantages over standalone mpv, perhaps most noteworthy are the ability to drag and drop web video links or local multimedia links to the smplayer interface and have them play,, an easy gui allowing multiple configuration and control options.. By using the pseudo-window hack I referred to you can switch to the small window and use and change Smplayer’s controls and configuration on the fly. Also Smplayer has it’s own internal youtube code which is even faster to respond than youtube-dl. By going into smplayers preferences/network tab you can select auto which I believes instructs you tube to return the specified video quality by using either youtube-dl or smplayer"s internal code which ever fetches the video first. Smplayer supports youtube and regular playlists,,cycling through aspect ratios although it always seems to find the correct aspect ratio automatically. You can also easily specify only one instance of smplayer so that when you are watching youtube you don’t even have to close the existing window when selecting a new video to watch.

One of my favourite firefox extensions has only very recently become available in the Chromium web store and as such is also now available in Vivaldi browser -namely “ Open With “ (by Geoff Lankow). This extension is designed to permit you to open a web url in another web browser. However it also has the widely recognised off-label utility of being able to add a smplayer or other media player instead of a browser and then if you add open with smplayer by clicking on a button icon it places on the browser and in the right-click context menu to open a video url with smplayer. Sweet ! To use the argot of the young!. Thus I have now configured both Vivaldi and Chromium so that I can open video links in mere seconds with smplayer. Thus when browsing youtube videos for example, I can with one click not only quickly open the video in the currently loaded tab but also the suggested videos beneath or to the side, in smplayer 

Once again a recent version of smplayer with an up-to date internal youtube code is I dont think available in the Raspbian repository (17.5 and above needed). However again it is better and not hard to create your own smplayer deb so as to enable installing the most recent version, by following the easy install instructions contained in the install text of the source file which can be downloaded here: ... .0.tar.bz2

While you are at it you might also wish to obtain and build a deb for smtube -smplayer's integrateda youtube browser- smtube -which can also run independent of smplayer -using the same procedure.: See : It is a very quick uncluttered way of browsing and viewing youtube and can utilise a variety of video engines in addition to smplayer. For example you can use G.Kreidl's omxplayergui as the engine for smtube browser. Omxplayer gui is nice because among it's other virtues unlike mpv and smplayer it is both draggable and resalable. and can be minimized. You can also use the hardware accelerated ffplay player derived from compiling ffmpeg. which is very quick and displays in a non overlay resizable, draggable and minimizable. The version of smtube in the raspbian repository is old and no longer works.

My suggested configuration for smplayer is under the general tab you must specify mpv as the media player and show the path to its executable if not already specified ie. /usr/bin/mpv.
For video output select rpi and for audio alsa for performance threads 4 and auto for hardware decoding. On the most recent versions of smplayer under the network tab select auto for support for video sites. Under the advanced tab select run mpv in its own window and under options I have specified those I noted previously These options would of course vary depending on the individuals preferences and the resolution of their monitor etc. It would be ideal if one could configure mpv and smplayer so that mpv would output its mmal overlay video into smplayers window so as to be dragable and resizable . Mpv has windowed options but i don't think they work with mmal decode. Some discussion of the complexeities involved can be found here: 

and here

G. Kreidl's omxplayergui through some kind of ingenious wizadry managed to put omxplayers overlay output into a resizable dragable pseudo window so perhaps there is hope for mpv on the Pi.

I would be interested in knowing what your mpv configuration file looks like? I gather your video output at the moment is a non-resizable or draggable overlay wihch you can only toggle between full screen or the videos original size?

I presume your compile of ffmpeg yielded the ffplay player component which only happens when you have installed the sdl dependencies which I believe you did. I really like ffplay because it will play videos in a non-overlay infinetly resizable,minimizable draggable window. And is quick to respond. It makes a really nice player for smtube and livestreamer. When I specify mpv as the player for livestreamer I lose keyboard control. Ffplay uses more cpu typically 15-25 % and doesnt have quite the same video quality as smplayer or omxplayergui perhaps it is something like the quality you see on the chromium browser. But it has its own virtues.It has no controls but responds to keyboard and some mouse commands> I made desktop shortcuts for two versions of ffplay. (By the way I also use the desktop shortcut for mpv you must click on properties and specify open and keep open terminal so as to retain keyboard control)

Unfortunately when I use an ffmpeg version greater than the 3.1 version while I can get a good working mpv the ffplay player stuuters badly with high cpu and video rendered like a slideshow.
I note other users have reported not being able to get ffplay to work with versions of ffmpeg 3.2 and above see: ... al-support

I suspect that this has something to do with the fact that ffmpeg dropped support for sdl1 around this time and went to sdl2. But sdl remains installed on raspbian as well as sdl2 because I beleive it is is used for other applications. Any workarounds?

Unfortunately versions of mpv greater than 22 require an ffmpeg 3.2.2 or above Nonetheless,. Mpv versions 22 and below work fine at the moment. But some of the later versions of mpv bring minor fixes to mpv with respect to its utilisation of toutube-dl particularly as it relates to dash video. Since I am using smplayer which has it’s own internal youtube code this hasn’t been a problem to date.

As you mentioned since mmal video is rendered as an overlay if you are in full screen mode it is important to retain keyboard control or you are up the creek without a paddle so to speak. It is the same with Smplayer if you are in full screen and should lose focus as the application “ on top “ you lose keyboard control. I notice this can happen if you should inadvertently though force of habit mouse click on the full screen display. Focus can usually be quickly regained by pressing the alt-tab combo followed by fhe “f” toggle untill focus is regained. This is one of the few annoying drawbacks of mpv/smplayer on the Pi. And it doesn’t happen often. It would be great if someone could offer advice on how to prevent this from happening in the first place.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Tue Dec 19, 2017 3:28 pm
by Gadgetguy
By the way another nice feature of mpv and smplayer is that by toggling the keyboard command o ie oh you bring up via on screen display(osd) in sequence time elapsed /total time .visual progress bar and v to toggle subtitles. Many other niceities too numerous to mention. Incidentally back when I first compiled mpv it wasn't neccessary to update-rpi firmware. Only the later versions of mpv seem to require this update to compile. I did the update bwith some trepidation noting the warning that is given to users of rpi-update, knowing I had more than one sd card bard backed up. I didn't observe any adverse consequences not to say the might be some unnoticed problems that might manifest later.

Another problem I have with some of the mpv versions greater than 21 is that on some of the mpv versions greater than 21 the mpv documentation states that vo-rpi is deprecated and vo-opengl is recommended/ or necessary for the pi.. I was never able to get the vo=opengl to work satisfactorily high cpu dropedd frames etc.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Wed Dec 20, 2017 1:42 pm
by RPi_Mike
Gadgetguy wrote:
Tue Dec 19, 2017 2:56 pm
In my opinion probably seconded by millions of users( unless you are an extreme minimalist) on other platforms the enjoyment and utility of mpv is greatly enhanced by using it as the engine for the smplayer gui rather than standalone. This is even more true on the Pi .Since you configured your ffmpeg with mmal i presume your video output is in the form of an overlay. This is in my opinion the biggest disadvantage of mpv on the Pi.

Wow, Gadgetguy! That was a tremendous amount of stuff you wrote about SMPlayer – and a whole bunch of other experiences you've had in the past. Don't get me wrong – I'm truly grateful that you appreciate my "well written and sorely needed contribution". But if at all possible, I'd like to keep this thread focused on its designated topic. That topic, of course, is using my tutorial to build FFmpeg and mpv from source code.

My bigger concern is that less-advanced users might read your exuberant post and think "wow, this SMPlayer sure sounds nifty – it will make RPi_Mike's tutorial even better!!" Unfortunately, it won't do any of that.

As with almost all software in the Raspberry world, a normal user has only one realistic option to acquire SMPlayer – they must run "sudo apt-get install smplayer". That will grab version 16.11.0 from the Raspbian Stretch repository. That version is already more than a year old. And yes, I'm well aware that a user could try building the latest version of SMPlayer from source code – but that's a complicated topic for a separate tutorial in a separate thread. They could also try downloading a pre-built installer from some website. Believe me – I'm well aware of all the possibilities.

Nonetheless, out of curiosity, I just installed the repository's version of SMPlayer. To be blunt, it provides ZERO value to my brand-new build of mpv. All it does is get in the way.

Although it fully recognizes my build of mpv, it simply acts as a file manager without actually doing anything. In other words, if I launch SMPlayer and attempt to open a video inside it, it simply triggers my build of mpv – which then plays the video *OUTSIDE* the SMPLayer GUI. In other words, SMPlayer acts as an "empty middleman" that does nothing. I realize you may have used older, less functional versions of mpv IN THE PAST that "worked great" with SMPlayer. But when it comes to the brand-new version my tutorial builds, historical observations are obviously not relevant. I might add, by the way, that I *ADMIRE* how my build of mpv ASSERTS ITSELF – that it insists on running as a highly efficient overlay, rather than being trapped inside a sluggish GUI environment! That's half the point of mpv.

And yes, there's a chance that if I fiddled around for hours with the older version of SMPlayer – or even the newest version of SMPlayer – I might eventually get mpv to "work" inside the GUI. But that still wouldn't address a much more fundamental issue in my eyes – I don't like the concept of SMPlayer! Even if it did "work".

This is partly because my combination of FFmpeg and mpv does everything I want. But it's also because the "mpv philosophy" is to not get bogged down by the computational overhead of a GUI or any windowed environment. The Raspberry has limited resources, so the whole point of mpv is to have a "pure player" that squeezes every last drop of system power into the only thing that really matters: PLAYING VIDEO! That's partly why my build is able to crank out an amazing 60 frames per second without dropping a single frame. That's also why it's designed to behave as an overlay, rather than inside the "bloatware" of a GUI.

On top of that, many of the "enhanced features" that you claim are unique to the SMPlayer / mpv "combination" are already available in the latest version of mpv by itself – without any help from third-party software. An example would be the on-screen display via the "o" key toggle that you mention. This comes standard with mpv. I'm not saying you're mistaken about your past experiences – I'm just trying to remind the readers that you're talking about past experiences with OLD VERSIONS of mpv that no longer apply to this discussion.

And yes, I know you may be tempted to say "oh, but with SMPlayer it will do sooo much more" – and then you might tick off a long list of things that you adore about SMPlayer. Ultimately, if you want to create a brand new thread and write a crisp, clearly-written, step-by-step tutorial about SMPlayer and all its many advantages, I'd be happy to check it out. But it's definitely not the appropriate "companion" for my turbo-charged build of mpv.

Finally, let me conclude with a long quote from your last posting: "Another problem I have with some of the mpv versions greater than 21 is that on some of the mpv versions greater than 21 the mpv documentation states that vo-rpi is deprecated and vo-opengl is recommended/ or necessary for the pi.. I was never able to get the vo=opengl to work satisfactorily high cpu dropedd frames etc."

This again is a historical observation about one man's experience with outdated versions of mpv, so it's not relevant to this thread. But unfortunately, it creates the false impression that there might be something wrong or broken with newer versions of mpv. In the latest version of mpv that my build creates, there's no issue whatsoever with "vo" or dropped frames. In fact, it automatically selects the correct video output mode – on the fly – without any user intervention.

If you'd like to share additional thoughts with me about SMPlayer or other off-topic subjects, I'd be happy to discuss it with you via Private Message.

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Wed Dec 20, 2017 7:24 pm
by jccj78
Would it be possible to implement all this in emby server?
Transcode dvb-sat2 on the fly to view home TV over internet? It would be like a dream that Raspberry could do it!

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Fri Dec 22, 2017 7:04 pm
by tomf90
As a complete novice it was refreshing to find a tutorial on this forum that covers what I needed and explains it clearly.

I don't suppose you could drop me a message explaining how I would be able to use this to stream video from my pi noir cam and audio from my usb mic to a webpage? I know you're explanation would be far more understandable than any of the other stuff i've endured so far in my quest to find out how to do this.


Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sat Dec 23, 2017 7:47 pm
by jerryrp
Great post, thank you!

But for me one thing is not clear: do I have to uninstall all existing versions of mpv, ffmpeg, etc before compiling "my own", or I can install on top of them? Or this new libs/binaries will coexist peacefully with old ones?

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 24, 2017 4:17 am
by RPi_Mike
jerryrp wrote:
Sat Dec 23, 2017 7:47 pm
Great post, thank you!

But for me one thing is not clear: do I have to uninstall all existing versions of mpv, ffmpeg, etc before compiling "my own", or I can install on top of them? Or this new libs/binaries will coexist peacefully with old ones?

I appreciate your question. There are several things to say about this, but let me start with a quick answer: If you already have older versions of FFmpeg and mpv that you installed from the Raspbian Stretch repository – and then you compile and install my builds after the fact – my builds *should* automatically become the new, "dominant" versions.

My builds are a SUPERSET of the older, generic, non-hardware-accelerated versions that are available in the repository. My builds are also NEWER in both the case of FFmpeg (version 3.4 vs. 3.2.9) and in the case of mpv (version 0.27 vs. 0.23). The 3.2 release branch of FFmpeg came out in October of 2016. And the 0.23 version of mpv came out in December of 2016. But my builds are based on official source code released in October and September of THIS YEAR (2017). So my builds give you versions that are a year newer!

Obviously, because my builds are newer and much better than the stock versions, I had no reason to first install the old versions before I installed mine. After all, I'm just a random dude that researched, developed, validated and wrote a tutorial for free – I'm not a full-blown commercial testing facility that's deliberately trying to create every possible configuration someone might have in order to see what happens! That's why I made very clear in my tutorial that my "guarantee" only applies to a fresh, brand-new, unaltered copy of the Raspberry's current operating system – Raspbian Stretch. I did this on purpose so that I was not making any false assumptions or accidentally achieving success because of something else I had installed a month earlier. If someone has been tinkering with their system before they came upon my tutorial, I have no way to accurately model their likelihood of success.

Nonetheless, as a quick test, I went ahead and installed the old repository versions – and then I re-installed my versions in less than two minutes from the extremely convenient Debian software packages that my tutorial creates (see Appendix 6 for more detail). My results? Everything worked perfectly! My builds became the new, dominant versions. When I went to the Terminal window and entered "ffmpeg -version", it correctly responded with "ffmpeg version 3.4 Copyright (c) 2000-2017 the FFmpeg developers". And when I entered "mpv -version", it correctly responded with "mpv 0.27.0 (C) 2000-2017 mpv/MPlayer/mplayer2 projects".

Finally, unless you're a total expert, I wouldn't try "uninstalling" the old versions. Many packages are interlinked with other packages, so if you don't go about it properly, you could end up with a mess. Sure, you might free up a few extra megabytes on your system. But even on a small SD card, that's still less than 1/1000 of the total data capacity. Totally not worth it!

Re: TUTORIAL: Play or Encode High-Quality Video and Audio – with FFmpeg and mpv

Posted: Sun Dec 24, 2017 7:37 am
by Gadgetguy
Sorry I didn’t mean to hijack your thread and only discussed smplayer because I I found smplayer greatly enhances mpv’s caabilities especoally on the Raspberry Pi where mpv’s screen output is an ovelay. However I will mention it no further in this thread. Could you tell me whether your version of ffmpeg yielded the ffplay component of ffmpeg. I presume it did since you compiled ffmpeg with ffplay’s sdl dependency. If so would you be able to test play a hd video with ffplay and advise whether it plays fluidly without stutter. I and others were unable to get a good working ffplay with a version of ffmpeg higher than the 3.1 series.

I gathered from your tutorial that your video output from mpv only comes in two flavours: full screen and the native size of the video both output as overlays. I wonder if it would be too much to ask if you could try the hack I mentioned whereby you direct mpv, via it’s very easily changed and changed back again configuration file, to output its non- full screen overlay to a window of specified size at a predetermined location on the screen so as to enable multi- tasking and/or access to desktop controls. I suspect this hack which I do find very serviceable and an improvement. could be refined or developed further by someone much more qualified than me.