RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Tue Dec 12, 2017 4:20 pm

WITH THIS TUTORIAL and a Raspberry Pi 3, you can play or encode almost any video or audio – from obscure formats from the last century to the very latest in high-definition. In fact, this tutorial creates a system so muscular, it will play 1080p video at a whopping 60 frames per second. I will show you, step-by-step, how to build customized versions of FFmpeg and mpv that feature powerful GPU-based hardware acceleration, full-screen display, and extensive encoder, decoder 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 eight separate appendices with tons of useful information, including how to use mpv and FFmpeg – and how to acquire the highest-quality videos from hundreds of websites with a downloading tool known as youtube-dl.

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, you must have versions that 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 tutorial tells you how.
NASA.jpg
NASA.jpg (225.96 KiB) Viewed 1174 times
This 1920 x 1080 screenshot was taken directly from my Raspberry. Captured from a 60 frame-per-second 1080p video, this supercomputer simulation of colliding neutron stars demonstrates the power of this tutorial. 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 in most browsers, right-click and select "open image in new tab". On various phones and tablets, you can usually "tap and hold" and save it to your pictures for full-size viewing. NOTE: NASA chose TV-based frame rates rather than monitor-based frame rates, which explains the fractional 59.940 frame rate.

METHOD: My instructions use source code to build the latest versions of FFmpeg and the mpv media player – 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. Fortunately, this tutorial is written in an accessible manner that spells everything out. It can be followed by almost anyone with a basic understanding of Linux.

REQUIREMENTS: This tutorial will work on any standard Raspberry Pi 3. You must also have the official Raspbian Stretch operating system (initially released on August 17, 2017). If you just got a Raspberry kit, there's a chance the pre-made SD card still has Raspbian Jessie on it – that's the previous generation of Raspbian and it will not work with this tutorial. You can always download the latest version of NOOBS from this website and make a brand-new SD card with Raspbian Stretch on it. Also, "lite" versions of Raspbian will not work either. The bottom line is actually very modest and simple – you must have 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 instructions will also work reasonably well on that device. Other versions of the Raspberry will definitely not work.

WHAT, SPECIFICALLY, WILL THIS TUTORIAL GIVE YOU? This tutorial 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. It will even pump out an astonishing 60 frames per second of high-definition 1080p video (MP4 / H.264) without dropping a single frame. It will also let you encode audio and video into almost any format – including MP4 and WEBM. It will let you encode MP4 videos with the most universally-playable codec pair (H.264 for the video track and AAC for the audio track). It will also let you encode WEBM videos with the most advanced compression technology currently available (VP9 for the video track and Opus for the audio track). You will also be able to choose high-quality, software-based H.264 encoding – or much faster hardware-accelerated H.264 encoding. Finally, my instructions will create freestanding Debian software packages that will allow you to quickly install or re-install everything you need, in just a couple minutes, on any Raspberry Pi 3. That means these instructions, though a bit involved, are a one-time thing. Once you’ve done it, you’re good to go – at least until the next version of Raspbian comes out two years from now.

FULLY TESTED AND PROVEN TO WORK: This is not your typical tutorial. If you look for information on hardware-accelerated FFmpeg and mpv for 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 this tutorial 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 procedure on a clean install of Raspbian Stretch – the Raspberry Pi’s latest operating system. So I know it works. Of course, all operating systems and software are subject to change in the future. But at the time of this writing, I can confidently say that as long as you follow my instructions to the letter, you will achieve success!

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 ffmpeg” or “sudo apt-get install mpv” and have everything work? For reasons I explain below, that won’t get you to multimedia nirvana 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 generic builds of FFmpeg and mpv. As a result, they do not take advantage of hardware acceleration, and therefore do not leverage the Raspberry’s surprisingly powerful on-board GPU to encode and decode video. Instead, all video is rendered “in software” by the CPU. As a result, any video with a resolution greater than 480p in today’s most common format – MP4 (H.264) – will drop frames and “stutter”. As the resolution goes up, the stuttering gets progressively worse.

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 biggest provider of video – only supports two major video formats: WEBM (VP9) and MP4 (H.264). In the near future, when the next-generation open source AV1 codec is released, having access to a versatile and continually-updated media player will be even more crucial.

For example, if you download WEBM (VP9) videos with the excellent “youtube-dl” downloading tool, you will not be able to play them with OMXPlayer (or most any other player, for that matter). And your MP4 (H.264) viewing options will be limited.

The other leading potential contender – the generally well-regarded VLC media player – could not properly render WEBM videos and was very unstable with high-resolution MP4s, even when compiling it from source code and configuring it for hardware acceleration. Of course, new updates are issued all the time – for both Raspbian and the VLC player. So this state of affairs could theoretically change at any moment. Nonetheless, my VLC testing results are what they are.

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 open source “x264” codec – which is included in my instructions. 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 instructions. Encoding an MP4 video that fully supports these “best of breed” universal standards cannot be properly done with the “stock” version of FFmpeg that’s available in the Raspbian repository.

And what if you wish to encode a WEBM video with the more advanced VP9 (video) and Opus (audio) codecs? That also can’t be done with the Raspberry’s stock version of FFmpeg.

Finally, what if you wish to take advantage of hardware-accelerated H.264 encoding on the Raspberry? That also can’t be done with the stock version of FFmpeg. But for those of you that follow my instructions, 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: As the saying goes, "I ate my own dog food". That means I followed my own tutorial, confirmed everything worked, and then tested the results. I did everything on a standard Raspberry Pi 3 with the standard operating system (Raspbian Stretch). Quite frankly, I was astonished by the performance of such a small and inexpensive computer. With the customized versions of FFmpeg and mpv that my tutorial provides, the Raspberry really shines. Perhaps the most amazing finding is that the Raspberry's GPU can fully render high-definition video at 60 frames per second! We're talking FULL COLOR, FULL SCREEN, ZERO DROPPED FRAMES and TRUE HIGH-DEFINITION – 1920 x 1080.

Almost all video you'll encounter is either 24, 25 or 30 frames per second, but a small number of recent videos on YouTube are now available at 60 FPS. As long as the video is encoded with the extremely common H.264 codec (referred to by YouTube's servers as "avc1"), the Raspberry can play an MP4 video at 60 frames per second – pumping out more than 124 MILLION full-color pixels every second without skipping a beat! Frame rates this high are especially nice for high-motion video with lots of fast movement, as it greatly reduces motion blur. The Raspberry can do this because its GPU is specifically optimized for H.264 at the hardware level. For more details on how to acquire high-quality video, please see Appendix 3 toward the bottom of this document.

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


---------
MPV: BENCHMARK RESULTS FOR MY SOURCE-BUILT VERSION ON THE RASPBERRY PI 3:

PLAYING HIGH-COMPLEXITY VIDEO – 1920 X 1080 – 30 FPS – FULL SCREEN – SIGNIFICANT MOTION AND INTRAFRAME DETAIL:

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

WEBM video (VP9 video / Opus audio): 2.5% dropped frames (almost perfect)



PLAYING MID-COMPLEXITY VIDEO – 1920 X 1080 – 30 FPS – FULL SCREEN – LESS MOTION:

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

WEBM video (VP9 video / Opus audio): 0.2% dropped frames (virtually perfect)



PLAYING HIGH-COMPLEXITY VIDEO – 1280 X 720 – 30 FPS – FULL SCREEN – SIGNIFICANT MOTION AND INTRAFRAME DETAIL:

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

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



---------
FFMPEG: BENCHMARK RESULTS FOR MY SOURCE-BUILT VERSION ON THE RASPBERRY PI 3:

ENCODING HIGH-COMPLEXITY 30 FPS VIDEO FROM A 1920 X 1080 JPEG IMAGE SEQUENCE – SIGNIFICANT MOTION AND INTRAFRAME DETAIL – HIGH QUALITY SETTINGS:

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

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



ENCODING HIGH-COMPLEXITY 30 FPS VIDEO FROM A 640 X 480 JPEG IMAGE SEQUENCE – SIGNIFICANT MOTION AND INTRAFRAME DETAIL – HIGH QUALITY SETTINGS:

Software-Based H.264 Encoding (CPU): 16 FPS (1.9 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 14 steps use raw source code to “build” and install the most robust versions possible of FFmpeg and mpv on your Raspberry Pi 3. In Step 11, it will take about 26 minutes for your system to compile FFmpeg’s source code with the “make” command. This is by far the most computationally intensive step in my procedure. By using the “-j4” option, all 4 cores in the Raspberry’s CPU will be placed at full-throttle – so your CPU will run at 100% capacity. A compile time of 26 minutes is actually quite impressive when you consider that over one million lines of FFmpeg code are being compiled on a $35 computer!

CRITICAL TIP: Copy and paste these instructions into the Text Editor (located under Accessories). Other than the simple Text Editor, you should not have any programs running when you follow these instructions – especially not the resource-heavy web browser. That could easily interfere with compiling. You'll want all system resources devoted to this task in order to avoid trouble. It also makes it easier, because you can position the Terminal window on the left side of your screen and the Text Editor (with these instructions) on the right side of your screen. That way, it will be super easy to copy and paste the command lines without accidentally skipping steps or making mistakes.

IMPORTANT NOTE ON CHECKINSTALL: Several of these steps invoke the extremely useful “checkinstall” command. It installs the compiled program *AND* creates a freestanding Debian software package (.deb) that you can quickly use to install or re-install the program at any time! That way, you won’t have to re-do this entire procedure in the future. Checkinstall will first ask if you want to “create a default set of package docs” – simply type “y” and hit Enter. Then it will ask for a description of the package. The exact wording is not critical – simply enter a brief description that applies to the current step – like “MP3 encoder", "VP9 encoder”, etc. Then tap the Enter key a second time. At that point, select option 3 to enter a version number – or tap the Enter key instead to install the program (the correct action, when it comes to the version number, is explicitly described in each step). Don't worry – as long as you pay attention, the checkinstall dialogue is very straightforward.

WARNING #1: Compiling is very intense and will push your CPU to its limits for a prolonged period of time. If you do not have adequate heat dissipation, your Raspberry is very likely to overheat to above 80 degrees Celsius (176 degrees 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. So it’s worth getting a small 40mm fan that attaches to your Raspberry’s case, along with copper heatsinks for the 3 main chips. If you don’t have those add-ons, you can 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 step.

WARNING #2: For experienced users, what I'm about to say is just common sense. But it's still important to emphasize: *ANYTHING* you do with a computer could cause you to lose all your data. And *ANYTHING* you do with a computer could cause your operating system to become unbootable. The simple act of turning on your computer could do either of these things. For example, you could get hit with a random power surge before you even start this tutorial! Every potential reward in life comes with at least some potential risk. Regrettably, one overly dramatic commenter said I was being "irresponsible" to recommend a firmware update in Step 2 of my instructions. That language is clearly overblown, but all activities have at least *SOME* risk! Despite the name "firmware", it does not make any change to your Raspberry's hardware. It is a "software only" update that poses no risk to your hardware. However, there is a remote chance that it could make your existing operating system unbootable. Fortunately, that's no big deal if you've taken two basic safety precautions – backing up your data, and backing up your operating system! So even if you never use this tutorial, it's just good common sense to do the following two things before you do anything significant on your Raspberry:

1: BACKUP YOUR DATA: Always keep a backup copy of any data you would not want to lose. That includes your personal files, documents and pictures. You can easily copy and paste your data to a USB thumb drive (or any other storage device). Once you've made the backup, DO NOT leave it physically attached to your system. Instead, put it away in a safe place!

2: BACKUP YOUR OPERATING SYSTEM: Always keep a second working copy of your operating system. Otherwise, if something goes wrong, your Raspberry could temporarily become a useless "brick" – at least until you can get your hands on another SD card with a working operating system! Making a backup copy of your operating system only takes 10 minutes. HERE'S HOW: First, reboot your computer to make sure everything is "fresh". After it comes back up, give it a few minutes to fully "settle down". Then take a second SD card, place it in a USB SD card adapter, and plug it into your Raspberry. If any windows appear, close them! Then click the Raspberry Menu | Accessories | SD Card Copier. When the SD Card Copier window appears, do nothing for a full minute (I have personally found this pause to be critical for everything to work–at least for the current version of Raspbian). Once you've done that, click the "Copy From Device" drop-down box and select your INTERNAL SD card (typically, it will have a name like "mmcblk0"). Then click the "Copy To Device" drop-down box and select your EXTERNAL SD card (the one you just put in the USB adapter). Then check the "New Partition UUIDs" box and click Start. After only 10 minutes or so, you will have a brand-new working copy of your operating system! Put it away in a safe place and you can breath easy!



---------
STEP 1: INCREASE YOUR RASPBERRY’S GPU MEMORY ALLOCATION TO 128 MB:

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

Change “GPU Memory” from the default of 64 to 128

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




STEP 2: FULLY UPDATE YOUR SYSTEM:

***Open Terminal:

sudo apt-get update

sudo apt-get upgrade

REBOOT!

***Open Terminal:

WARNING: The following line – "sudo rpi-update" – will update your Raspberry's "firmware". The update includes the latest "bleeding-edge" (and somewhat experimental) version of the VideoCore libraries. The VideoCore IV is your Raspberry's GPU, so the latest libraries could prove essential to getting the best video performance from mpv. However, if you do not update your firmware, the existing "stock" version of the VideoCore libraries may still be "new enough" to get excellent performance. Or maybe not! Personally, I went ahead and updated my firmware and everything worked GREAT – so I have NOT tested what happens if you don't update your firmware! There's even a theoretical chance that mpv won't even compile without the latest libraries, in which case it won't just be a performance issue – it will be a "mpv doesn't work at all" issue. I have a backup copy of both my operating system and my data, so there was no risk to me. That's why I updated my firmware! Before you proceed, however, please see "WARNING #2" at the beginning of these instructions. It tells you how to avoid any risk whatsoever. If you decide to skip the following line, you can just see how everything works. If mpv still performs extremely well, then you should leave your firmware alone and not update it. But if mpv drops frames and "stutters" while playing high-resolution video, you can always run "sudo rpi-update" at any time in the future. If that still doesn't improve things – or if mpv fails to even compile – you can always run "sudo rpi-update" and then repeat Step 12 from scratch (building and installing mpv). If you do update your firmware, make sure you do it after a fresh boot with no browser or any other software running. And, of course, wait a few minutes for your Raspberry to fully "settle down" after it's done booting up before you do any critical system updates (like firmware).

sudo rpi-update

REBOOT!




STEP 3: INSTALL DEPENDENCIES – STANDARD SOFTWARE PACKAGES FROM THE OFFICIAL RASPBIAN REPOSITORY:

***Open Terminal:

sudo apt-get install git wget autoconf automake build-essential pkg-config checkinstall libsdl2-dev libtool libva-dev libvdpau-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev texinfo libfribidi-dev libfontconfig1-dev libfreetype6-dev libjpeg-dev gnutls-dev libluajit-5.1-dev python-docutils libbluray-dev libtheora-dev libvorbis-dev linux-headers-rpi2 libomxil-bellagio-dev

***Close Terminal

REBOOT!




STEP 4: CREATE YOUR SOURCE CODE BUILD FOLDER:

***Open Terminal:

mkdir FFmpeg_Build

***Close Terminal




STEP 5: BUILD AND INSTALL THE H.264 VIDEO ENCODER – libx264:

***Open Terminal:

cd FFmpeg_Build

wget https://download.videolan.org/pub/videolan/x264/snapshots/x264-snapshot-20171026-2245-stable.tar.bz2

tar jxvf x264-snapshot-20171026-2245-stable.tar.bz2

cd x264-snapshot-20171026-2245-stable

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

make -j4

sudo checkinstall make install <---Enter the following version number when prompted (or it will fail to create a Debian package): 20171026

sudo ldconfig

***Close Terminal




STEP 6: BUILD AND INSTALL THE FRAUNHOFER AAC AUDIO ENCODER – libfdk-aac:

***Open Terminal:

cd FFmpeg_Build

git clone https://github.com/mstorsjo/fdk-aac.git

cd fdk-aac

./autogen.sh

./configure --enable-shared

make -j4

sudo checkinstall make install <---Enter the following version number when prompted (or it will fail to create a Debian package): 0.1.5

sudo ldconfig

***Close Terminal




STEP 7: BUILD AND INSTALL THE VP9 VIDEO ENCODER – libvpx:

***Open Terminal:

cd FFmpeg_Build

git clone https://chromium.googlesource.com/webm/libvpx

cd libvpx

./configure --enable-shared --disable-examples --disable-unit-tests --enable-vp9-highbitdepth

make -j4

sudo checkinstall make install <---Enter the following version number when prompted (or it will fail to create a Debian package): 1.6.1

sudo ldconfig

***Close Terminal




STEP 8: BUILD AND INSTALL THE OPUS AUDIO ENCODER – libopus:

***Open Terminal:

cd FFmpeg_Build

wget https://archive.mozilla.org/pub/opus/opus-1.2.1.tar.gz

tar xzvf opus-1.2.1.tar.gz

cd opus-1.2.1

./configure --enable-shared

make -j4

sudo checkinstall make install <---No need to enter version number – checkinstall will audodetect it.

sudo ldconfig

***Close Terminal




STEP 9: BUILD AND INSTALL THE MP3 AUDIO ENCODER (LAME) – libmp3lame:

***Open Terminal:

cd FFmpeg_Build

wget https://downloads.sourceforge.net/project/lame/lame/3.100/lame-3.100.tar.gz

tar xzvf lame-3.100.tar.gz

cd lame-3.100

./configure --enable-shared

make -j4

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

sudo checkinstall make install <---No need to enter version number – checkinstall will audodetect it.

sudo ldconfig

***Close Terminal




STEP 10: BUILD AND INSTALL THE SUBTITLE RENDERER – libass (mpv will not work without it):

***Open Terminal:

cd FFmpeg_Build

wget https://github.com/libass/libass/releases/download/0.13.7/libass-0.13.7.tar.gz

tar zxvf libass-0.13.7.tar.gz

cd libass-0.13.7

./configure --enable-shared

make -j4

sudo checkinstall make install <---No need to enter version number – checkinstall will autodetect it.

sudo ldconfig

***Close Terminal

REBOOT!!




STEP 11: BUILD AND INSTALL FFmpeg:

***Open Terminal:

cd FFmpeg_Build

wget http://ffmpeg.org/releases/ffmpeg-3.4.tar.bz2

tar jxvf ffmpeg-3.4.tar.bz2

cd ffmpeg-3.4

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

make -j4 <---This line, which compiles the source code, will take about 26 minutes. Just be patient and let it compile without interference. In the unlikely event that your Raspberry locks up during this step – due to overheating or general system strain – you can always try changing the "-j4" to "-j2". By using only 2 of the CPU's 4 cores, you will lower memory usage and heat. This will reduce the overall strain on your system at the expense of roughly doubling the compile time. If it does lock up, data corruption could occur – so it's best to delete the "ffmpeg-3.4" folder and re-do this entire section (Step 11) from a clean slate. See WARNING #1 at the beginning of these instructions for more detail.

sudo checkinstall make install <---This line will take about 7 minutes. No need to enter version number – checkinstall will audodetect it.

sudo ldconfig

***Close Terminal

REBOOT!




STEP 12: BUILD AND INSTALL MPV:

***Open Terminal:

cd FFmpeg_Build

wget https://github.com/mpv-player/mpv/archive/v0.27.0.tar.gz

tar zxvf v0.27.0.tar.gz

cd mpv-0.27.0

./bootstrap.py

***STOP! YOU MUST NOW EDIT THE "wscript" TEXT FILE INSIDE THE mpv-0.27.0 FOLDER. JUST RIGHT-CLICK "wscript" IN FILE MANAGER AND CLICK “TEXT EDITOR”. THEN CLICK SEARCH | FIND AND DO A TEXT SEARCH FOR "Raspberry". ABOUT 70% DOWN THE PAGE, YOU SHOULD SEE THE FOLLOWING BLOCK OF TEXT. SIMPLY REPLACE IT WITH THE 2ND BLOCK OF TEXT BELOW IT AND SAVE THE FILE. BE EXTREMELY CAREFUL IN THIS STEP – JUST ONE TINY MISTAKE AND MPV WILL NOT WORK:


--------------------------------SELECT THIS BLOCK OF TEXT:
'name': '--rpi',
'desc': 'Raspberry Pi support',
'func': compose_checks(
check_cc(cflags="-isystem/opt/vc/include/ "+
"-isystem/opt/vc/include/interface/vcos/pthreads " +
"-isystem/opt/vc/include/interface/vmcs_host/linux " +
"-fgnu89-inline",
linkflags="-L/opt/vc/lib",
header_name="bcm_host.h",
lib=['mmal_core', 'mmal_util', 'mmal_vc_client', 'bcm_host']),
# We still need all OpenGL symbols, because the vo_opengl code is
# generic and supports anything from GLES2/OpenGL 2.1 to OpenGL 4 core.
check_cc(lib="EGL"),
check_cc(lib="GLESv2"),
-------------------------------------------------------------


--------------------------------AND CAREFULLY REPLACE IT WITH THIS:
'name': '--rpi',
'desc': 'Raspberry Pi support',
'func': compose_checks(
check_cc(cflags="-isystem/opt/vc/include/ "+
"-isystem/opt/vc/include/interface/vcos/pthreads " +
"-isystem/opt/vc/include/interface/vmcs_host/linux " +
"-fgnu89-inline",
linkflags="-L/opt/vc/lib",
header_name="bcm_host.h",
lib=['mmal_core', 'mmal_util', 'mmal_vc_client', 'bcm_host', 'vchostif']),
# We still need all OpenGL symbols, because the vo_opengl code is
# generic and supports anything from GLES2/OpenGL 2.1 to OpenGL 4 core.
check_cc(linkflags="-lbrcmGLESv2", lib="EGL"),
check_cc(lib="GLESv2"),
-----------------------------------------------------------------


ONCE YOU'RE DONE EDITING THE wscript FILE, CONTINUE WITH THESE STEPS:

export PKG_CONFIG_PATH=/opt/vc/lib/pkgconfig

export LIBRARY_PATH=/opt/vc/lib

./waf configure --prefix=/usr --enable-rpi

./waf build -j4

sudo checkinstall ./waf install

***Close Terminal

REBOOT!




STEP 13: BACK UP ALL THE .DEB FILES YOU JUST CREATED. THESE ARE FREESTANDING DEBIAN SOFTWARE PACKAGES. THEY WILL LET YOU QUICKLY INSTALL OR RE-INSTALL EVERYTHING IN THE FUTURE WITHOUT HAVING TO RE-DO THIS ENTIRE PROCEDURE:

Using File Manager, open the “FFmpeg_Build” folder. Then click Tools | Find Files

In the “File Name Patterns” box, enter “*.deb” (without the quote marks) and click the Find button. If you did everything properly, you will find exactly 8 “.deb” files. Simply copy and paste those files to a separate storage device for safe keeping – like a USB thumb drive, hard drive, etc.




STEP 14: CREATE A PROPER “OPEN WITH” BEHAVIOR ON YOUR RASPBERRY SO THAT YOU CAN QUICKLY OPEN ANY VIDEO OR AUDIO FILE BY SIMPLY DOUBLE-CLICKING IT WITHIN FILE MANAGER:

The mpv media player will typically install an mpv file association, by default, in File Manager. So if you right-click a media file, you may already see an item for mpv – such as “mpv Media Player”. Do not use this as it’s not optimized for the Raspbian operating system. In many cases, it will cause you to lose “keyboard control” of a video while it’s playing – which is especially problematic if it’s a full screen video (there will be no way to exit until the video finishes). To avoid all that, you need to create your own custom “Open With” association. To do that, follow these steps:

1: Right-click any media file type you wish to associate with mpv – such as an “.mp4” video.

2: Click “Open With...”

3: Click the “Custom Command Line” tab

4: In the “Command line to execute box”, type “mpv %f” (all lower-case, no quotes)

5: Check “Execute in terminal emulator”

6: Check “Keep terminal window open after command execution”

7: In the “Application name” box, type “MPV” (no quotes)

8: Check “Set selected application as default action for this file type”

9: Click the OK button

10: Repeat this process for any other file type you wish to associate with mpv – such as .webm, .mov, .mkv, .avi, .mp3, etc. Mpv is so versatile, you can even associate it with animated GIFs. From then on, you can simply double-click any of these files and mpv will automatically play them!

IMPORTANT: Be sure that all Terminal windows are closed before using mpv. If you fail to do that, you will probably lose keyboard control of mpv. Mpv uses its own instance of Terminal in order to operate, so having another Terminal window open will confuse it. This is especially problematic if you're watching a video in full-screen mode – because then you will have no way to recover control or even quit out of the video. You will then have to wait until the video finishes on its own before you regain control. But as long as you follow this simple guidance, this problem will not occur.




---------
APPENDIX 1: MOST ESSENTIAL MPV KEYBOARD CONTROLS AND OPTIONS:

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)


REMINDER: Be sure to close any open Terminal windows before you use mpv, or you will lose keyboard control.

CUSTOMIZE MPV's BEHAVIOR: If you wish to customize things further, create a standard text file and name it "mpv.conf". Place it inside "/home/pi/.config/mpv". Inside this file, you can add various options, each one on a separate line, such as "--fullscreen" and "--loop". For example, if you add the "--fullscreen" option, it will force smaller videos to automatically expand to fill your screen while maintaining their aspect ratio. This way, you won't have to tap the "f" key to toggle smaller videos into full screen mode. If you add the "--loop" option, any video you open will automatically play over and over again in an infinite loop until you tap the "q" key to quit. Mpv has MANY other keyboard controls, features and options. Visit mpv’s official website at mpv.io for more detail.




---------
APPENDIX 2: SAMPLE FFMPEG COMMAND LINES – TO ENCODE OR PROCESS VIDEO AND AUDIO:

NOTE: In the following examples, simply right-click any folder that contains the media files you wish to encode or process and click “Open in Terminal”. Then, run the following commands (changing the file names and settings where appropriate):


EXAMPLE 1: Convert an old AVI video (with sound) – or any other input video format you choose – into a modern MP4 (with H.264 video and AAC audio):

ffmpeg -i input.AVI -vf format=yuv420p -c:v libx264 -crf 23 -c:a libfdk_aac -b:a 128k output.MP4

NOTE: This example uses the higher-quality (but slower) x264 software-based encoder. That means there is no GPU hardware acceleration – however it does use a CPU optimization known as “NEON” that helps to speed up the encoding. The “-crf 23” setting is the default video quality and generally produces excellent results. The lower the number, the higher the encoding quality (at the expense of a larger file size). A setting of 18 is said to be “visually lossless” – but the file size will be almost double that of a 23 setting. Be aware that the number scale is non-linear – but as a rough rule of thumb, a change of 5 to 6 will double (or cut in half) the file size. In many cases, when a smaller file size is important, a setting of 26 still maintains a high-quality appearance. Finally, the “-c:a libfdk_aac -b:a 128k” part indicates that the audio will be converted with the Fraunhofer AAC codec, at a bit rate of 128 kbps.



EXAMPLE 2: Resize a large “1080p” MP4 video (1920 x 1080) with sound into a smaller “480p” MP4 video (854 x 480) with sound – without (unnecessarily) re-encoding the original audio:

ffmpeg -i input.MP4 -vf "format=yuv420p, scale=854:480:flags=lanczos" -c:v libx264 -crf 23 -c:a copy output.MP4



EXAMPLE 3: Extract every frame from a 30 FPS MP4 video and output it as a padded, 7-digit numerical JPEG image sequence:

ffmpeg -i video.mp4 -vf fps=30 -q:v 2 %07d.jpg



EXAMPLE 4: Convert an alphanumeric image sequence of JPEG pictures into a 30 FPS MP4 video:

ffmpeg -framerate 30 -pattern_type glob -i "*.jpg" -vf format=yuv420p -c:v libx264 -crf 23 output.MP4



EXAMPLE 5: Add a transparent overlay – such as text or a logo – on top of a video:

ffmpeg -i input.MP4 -i overlay.png -filter_complex "[0:v][1:v] overlay=0:0" -c:v libx264 -crf 23 -c:a copy output.MP4

NOTE: The “overlay.png” file must be a transparent PNG file (with alpha channel) that includes your text or logo. This can be created with any standard image-manipulation program like GIMP or Photoshop. Also, in this particular example, the inputted MP4 video is assumed to have a proper sound track that can simply be copied over without re-encoding. If the sound does require encoding, simply change “-c:a copy” to “-c:a libfdk_aac -b:a 128k”.



EXAMPLE 6: Use the hardware-accelerated H.264 encoder to convert an AVI into an MP4:

ffmpeg -i input.AVI -c:v h264_omx -b:v 4500k -c:a copy output.MP4

NOTE: The hardware encoder, though about 3 times faster, has fewer options and generally, bit for bit, produces a decent but lower-quality result. The software-based encoder, which relies on the versatile and general-purpose CPU, provides the programmers maximum flexibility to use whatever coding techniques they like – but a hardware encoder, by its very nature, is constrained by the features the GPU supports. Like most things in life, there are pros and cons to each approach. In this example, the “-b:v 4500k” part indicates a bit rate of 4,500 kbps – which is generally good for a large 1080p video. Unlike the software-based encoder, there is no “crf” quality setting, since the hardware-based encoder uses bit rate as a proxy for quality. If your video is smaller than 1080p, you will obviously want to lower the bit rate accordingly – to 2,000, 1,500, etc. Finally, this example assumes the existing audio is already in an MP4-compatible format, such as an AAC or MP3, and can thus be copied over. If you do need to transcode the audio, simply change “-c:a copy” to “-c:a libfdk_aac -b:a 128k”.

FINAL NOTE: The 6 examples I just provided are only a small sample of the astonishing capabilities of FFmpeg. For more information, visit their official website at FFmpeg.org.




---------
APPENDIX 3: DOWNLOAD AND RETAIN HIGH-QUALITY VIDEOS FROM HUNDREDS OF WEBSITES – WITH YOUTUBE-DL:

INSTALLING YOUTUBE-DL: Although youtube-dl is available in the Raspbian software repository, it’s nearly a year old. To acquire the very latest version from youtube-dl's official website, enter the following two command lines, one at a time, in the Terminal window:

sudo curl -L https://yt-dl.org/downloads/latest/youtube-dl -o /usr/local/bin/youtube-dl

sudo chmod a+rx /usr/local/bin/youtube-dl


DOWNLOADING MP4 VIDEOS (H.264 / AAC): Let’s say you have your Raspberry hooked up to a high-definition 1920 x 1080 monitor or TV and you wish to download and enjoy a NASA video, at maximum resolution and quality, of two neutron stars colliding – with the screen completely filled-up by the video. Here’s how you do that with youtube-dl:

STEP 1: Identify the URL of the page that contains the video you want. In this example, it’s a YouTube video at the following URL:

https://www.youtube.com/watch?v=x_Akn8fUBeQ


STEP 2: Open the Terminal window and enter the following code (make sure you use a capital “-F”):

youtube-dl -F https://www.youtube.com/watch?v=x_Akn8fUBeQ


STEP 3: You will then see an impressive list of all the different audio and video formats that the YouTube server has available for the NASA video. If you look carefully, you will see there’s a video track with a resolution of 1920 x 1080 that uses the “avc1” codec at 30 FPS (Frames Per Second). “AVC1” is simply another name for the H.264 codec. The Raspberry’s GPU has been specifically optimized to play H.264 video with full-blown hardware acceleration. On the far left column, you will see a “format code” for that particular video format. In this case, it’s code “137”. You will also see a high-quality audio track that’s described as an “m4a” with a sampling rate of 44100Hz. That’s YouTube's terminology for an AAC audio track. It has format code “140”. It's the best choice for this example, since an AAC audio track is specifically designed to work with an H.264 video track when creating an MP4 video. To download the high-resolution video (with sound), you will therefore issue the following command (make sure you use a lower-case “-f”):

1920 x 1080 MP4 – 30 FPS:
youtube-dl -f 137+140 https://www.youtube.com/watch?v=x_Akn8fUBeQ

Once the download is complete, be sure to close the Terminal window or you will lose keyboard control of mpv. Then, simply double-click the MP4 video you just downloaded and mpv will automatically start playing it full screen! If you downloaded a resolution smaller than your screen, you can tap the "f" key to toggle back and forth between actual size and full screen mode.


DOWNLOADING WEBM VIDEOS (VP9 / Opus): If you want a much smaller file size at a surprisingly high quality – albeit with lower resolutions of 720p or 480p – the “VP9” format for video and the “Opus” format for audio are the ones you want. They are the most advanced compression technologies currently available. The two tracks will be automatically combined by youtube-dl (using the FFmpeg engine) and merged into a standard WEBM video. Be aware that the Raspberry’s GPU is only designed to provide full hardware acceleration for MP4 videos using H.264 – so a 1080p VP9-based WEBM video will push your Raspberry to the absolute limit and will likely result in at least some stutter. That's why I recommend 720p and 480p resolutions for VP9-based videos. They also, of course, should not exceed 30 FPS. Finally, if you wish to share the video with someone else who doesn’t have an advanced player like mpv, it’s best to stick with a standard H.264-based MP4 video for compatibility reasons. For the NASA video, here are the two best command lines if you want smaller file sizes (for example, if you're using a cellular connection and need to conserve your data usage). When it's competently encoded by the uploader, I've been consistently amazed by how good a humble 480p video can look when viewed full screen on my large 24 inch 1080p monitor.

1280 x 720 WEBM – 30 FPS:
youtube-dl -f 247+249 https://www.youtube.com/watch?v=x_Akn8fUBeQ

854 x 480 WEBM – 30 FPS:
youtube-dl -f 244+249 https://www.youtube.com/watch?v=x_Akn8fUBeQ


HIGH FRAME-RATE CAPABILITY: In my testing, I was surprised to discover that the Raspberry’s GPU can handle 1920 x 1080 H.264 video at DOUBLE the normal frame rate – 60 FPS without dropping even one frame! Some newer videos on YouTube are now available in 60 FPS format, and the NASA video is one of them. If you wish to download the 60 FPS version of the above 1080p video, you would simply change the video format code from 137 to 299. In other words, you would use this command line instead:

1920 x 1080 MP4 – 60 FPS:
youtube-dl -f 299+140 https://www.youtube.com/watch?v=x_Akn8fUBeQ


CAUTION: Don't assume the format codes will always be the same. YouTube is quite consistent – but even with them, the available formats can vary from one video to another. For example, I've noticed that YouTube's servers will often place different formats in a queue, prioritizing H.264 over VP9. Even for the mighty Google, encoding video is very computationally intensive and time consuming – so it makes sense for them to quickly get the H.264 version up on their server, and then process the VP9 version an hour or half hour later. Other video sites, however, use completely different format codes and are typically limited to H.264 videos – so for them, you'll want to first run youtube-dl's "-F" option (capital F), as explained above, to see exactly what formats are available. Finally, be aware that most other sites tend to integrate the video and audio tracks into a single pre-packaged MP4 video – so there won't be separate video and audio formats to choose from. YouTube does this as well, by the way. It's usually listed in the last couple lines of their available formats. In YouTube's case, you'll know if everything's already been combined if it says both "avc1" and "mp4a" in the description. In those cases, you would not use the "+" symbol. Instead, you would simply use a single format code. For more information on the many other features and capabilities of youtube-dl, visit their official website at yt-dl.org




---------
APPENDIX 4: PLAY ONLINE VIDEOS AUTOMATICALLY WITH MPV (WITHOUT ANY MANUAL DOWNLOADING):

Personally, I like to review all the available video and audio formats before I download a video. If it's a concert or music video, I may want to enjoy it multiple times. By downloading it, as described in Appendix 3, I have immediate access to it at the highest quality – even if I'm offline. Downloading is also crucial if you're using a cellular data connection and need to conserve your data. Even with an "unlimited" plan, your carrier may still throttle back your speed once you reach a monthly limit. For those instances, I've found that 480p videos that use the advanced VP9 video codec and Opus audio codec at 50 or 70 kbps are the perfect balance between file size and quality. In an HD aspect ratio, they typically have resolutions of 854 x 480. For a relatively small video, they look surprisingly good on my large 1080p monitor in full screen mode. Of course, if you want the absolute best in quality on a 1080p screen and data use is not a concern, there's nothing like a 1080p video.

In many cases, however, data use may not be a concern. You also may not have any desire to manually download (and retain) the video. And finally, you may not really care if you're viewing the most optimal format and quality – because you just want to watch a video without any thought. In those cases, I have configured my procedure to support tight integration between mpv and youtube-dl. As long as you have properly followed this tutorial and have installed a recent copy of youtube-dl (see Appendix 3), all you have to do is enter a URL after the mpv command! That will automatically invoke youtube-dl, which will start downloading the first several seconds of the video (invisibly as a background process). It does this to create a sufficient cache to help prevent buffering interruptions while playing. Once it's done that, mpv will automatically start playing the video! Generally, when operating in this mode, youtube-dl's algorithm will attempt to choose the "best quality" version of the video. It works well on leading video sites like YouTube, but there are no guarantees with less sophisticated websites. If you're unsatisfied with the results on other sites, nothing of course beats a manual review of the available formats (as described in Appendix 3).

As an example, if you want to automatically play the NASA video mentioned in Appendix 3, this simple command line is all it takes:

mpv https://www.youtube.com/watch?v=x_Akn8fUBeQ




---------
APPENDIX 5: IF FOR SOME REASON YOU WISH TO COMPLETELY UNINSTALL ALL THE PROGRAMS YOU JUST INSTALLED IN THIS TUTORIAL, JUST RUN THIS COMMAND LINE IN TERMINAL:

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




---------
APPENDIX 6: IF FOR SOME REASON YOU NEED TO RE-INSTALL ALL THE PROGRAMS IN THIS TUTORIAL ON YOUR CURRENT SYSTEM, OPEN TERMINAL IN WHATEVER FOLDER YOU PLACED ALL THE .DEB FILES (SEE STEP 13 IN THE MAIN PART OF THIS DOCUMENT) AND SIMPLY RUN THIS COMMAND:

sudo dpkg -i x264-snapshot-20171026-2245_20171026-1_armhf.deb fdk_0.1.5-1_armhf.deb libvpx_1.6.1-1_armhf.deb opus_1.2.1-1_armhf.deb lame_3.100-1_armhf.deb libass_0.13.7-1_armhf.deb ffmpeg_3.4-1_armhf.deb mpv_0.27.0-1_armhf.deb




---------
APPENDIX 7: IF YOU WISH TO INSTALL ALL THE PROGRAMS IN THIS TUTORIAL ON ANOTHER RASPBERRY PI 3 – OR ON THE SAME RASPBERRY PI 3 AFTER A FRESH INSTALL OF THE OPERATING SYSTEM – DO THE FOLLOWING:

STEP 1: Assuming the other Raspberry has a working copy of Raspbian Stretch, just do a standard update to make sure the system is fully up-to-date:

sudo apt-get update

sudo apt-get upgrade

REBOOT!

WARNING: The following line – "sudo rpi-update" – will update your Raspberry's "firmware". The update includes the latest "bleeding-edge" (and somewhat experimental) version of the VideoCore libraries. The VideoCore IV is your Raspberry's GPU, so the latest libraries could prove essential to getting the best video performance from mpv. However, if you do not update your firmware, the existing "stock" version of the VideoCore libraries may still be "new enough" to get excellent performance. Or maybe not! Personally, I went ahead and updated my firmware and everything worked GREAT – so I have NOT tested what happens if you don't update your firmware! There's even a theoretical chance that mpv won't even compile without the latest libraries, in which case it won't just be a performance issue – it will be a "mpv doesn't work at all" issue. I have a backup copy of both my operating system and my data, so there was no risk to me. That's why I updated my firmware! Before you proceed, however, please see "WARNING #2" at the beginning of these instructions. It tells you how to avoid any risk whatsoever. If you decide to skip the following line, you can just see how everything works. If mpv still performs extremely well, then you should leave your firmware alone and not update it. But if mpv drops frames and "stutters" while playing high-resolution video, you can always run "sudo rpi-update" at any time in the future. If that still doesn't improve things – or if mpv fails to even compile – you can always run "sudo rpi-update" and then repeat Step 12 from scratch (building and installing mpv). If you do update your firmware, make sure you do it after a fresh boot with no browser or any other software running. And, of course, wait a few minutes for your Raspberry to fully "settle down" after it's done booting up before you do any critical system updates (like firmware).

sudo rpi-update

REBOOT!


STEP 2: Install all the basic “dependencies” that FFmpeg and mpv require by running this command line in Terminal:

sudo apt-get install git wget autoconf automake build-essential pkg-config checkinstall libsdl2-dev libtool libva-dev libvdpau-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev texinfo libfribidi-dev libfontconfig1-dev libfreetype6-dev libjpeg-dev gnutls-dev libluajit-5.1-dev python-docutils libbluray-dev libtheora-dev libvorbis-dev linux-headers-rpi2 libomxil-bellagio-dev


STEP 3: Place the “.deb” installer files in any folder on the Raspberry Pi 3 (see Step 13 in the main part of this document), open Terminal inside that folder, and run the following command line to install all the programs:

sudo dpkg -i x264-snapshot-20171026-2245_20171026-1_armhf.deb fdk_0.1.5-1_armhf.deb libvpx_1.6.1-1_armhf.deb opus_1.2.1-1_armhf.deb lame_3.100-1_armhf.deb libass_0.13.7-1_armhf.deb ffmpeg_3.4-1_armhf.deb mpv_0.27.0-1_armhf.deb


STEP 4: Run this command in Terminal to make sure all the “shared libraries” are properly recognized by FFmpeg and mpv:

sudo ldconfig




---------
APPENDIX 8: TROUBLESHOOTING:

If you run a system update – such as "sudo apt-get update" and "sudo apt-get upgrade" – Raspbian's package manager may see that you've installed FFmpeg or mpv and wrongly think "oh, I need to update those programs". If it does this, it may overwrite your enhanced versions with the repository's stock versions, thus eliminating the advanced features this tutorial created. If this happens, you can quickly get everything working again in less than 2 minutes by simply re-installing the ".deb" packages! To do that, see Appendix 5.

Finally, as mentioned previously, be sure that all Terminal windows are closed before you use mpv (in order to maintain keyboard control).




---------
KEYWORDS: FFmpeg, mpv, Raspberry, RPi3, RPi, tutorial, MMAL, OpenMAX, omx, VideoCore, GPU, H.264, AAC, MP4, VP9, Opus, WEBM, x264, video, audio, encoding, decoding, hardware acceleration
Last edited by RPi_Mike on Thu Jan 04, 2018 12:00 am, edited 15 times in total.

treeHouse
Posts: 27
Joined: Sat Aug 06, 2016 2:35 am

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

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?
viewtopic.php?f=66&t=195221

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Sun Dec 17, 2017 7:18 am

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?
viewtopic.php?f=66&t=195221

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. It can quickly become a fundamental part of their life experience. 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 6,500-word 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. How do I know? I can see it with my own eyes!

As to your question of whether my hardware-accelerated FFmpeg / mpv build can coexist with a 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 if I had to guess, they probably can NOT peacefully coexist. The required dependencies for anything as computationally intense as a hardware-accelerated media player are complex and intertwined – so there's a very good chance that in attempting to install a rival media player, certain software libraries will be overwritten or "updated" in unpredictable ways that will either break my tutorial or simply do weird things to the entire "operating 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 boastful and 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 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.

Finally, the author indicates that VLC "did not play some 1080p60 videos which are playing well with omxplayer." Here again, I can shamelessly say that my build comes out on top. Not only can my build play *ANY* 60 FPS H.264 video up to 1080p – it will play it flawlessly, full screen, with no dropped frames.

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.

gkreidl
Posts: 5384
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

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

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!

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).
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Sun Dec 17, 2017 3:22 pm

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

DOES IT WORK PERFECTLY?____ YES _________ NO


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:

https://rg3.github.io/youtube-dl/download.html

jccj78
Posts: 2
Joined: Sun Dec 17, 2017 3:05 pm

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

Sun Dec 17, 2017 3:57 pm

Very great theoretical contribution RPi_Mike!!!
For a novice like me it has been very helpful.
Thank you.

User avatar
DougieLawson
Posts: 30961
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

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

Sun Dec 17, 2017 4:06 pm

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.
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.

gkreidl
Posts: 5384
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

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

Sun Dec 17, 2017 4:49 pm

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.
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

User avatar
fruitoftheloom
Posts: 15443
Joined: Tue Mar 25, 2014 12:40 pm
Location: Bognor Regis UK

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

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:
My only "PC" is an Asus ChromeBit running ChromeOS, cloudcentric at its best !
Rockchip Quad-Core RK3288C ARM32 SoC as used in ASUS Chromebook C201 & Chromebook Flip C100PA as well as the Tinker SBC.
3 Mobile Huawei E5330 Mobile Mi-Fi

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Sun Dec 17, 2017 5:14 pm

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.

User avatar
DougieLawson
Posts: 30961
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

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

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.
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 9834
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

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

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?

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!

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Sun Dec 17, 2017 6:44 pm

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.

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Sun Dec 17, 2017 8:04 pm

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!

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 9834
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

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

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.
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.

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Tue Dec 19, 2017 5:50 am

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!

g4bch
Posts: 7
Joined: Mon Oct 01, 2012 12:06 pm

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

Tue Dec 19, 2017 1:22 pm

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

Peter

Gadgetguy
Posts: 63
Joined: Fri Aug 15, 2014 2:55 am

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

Tue Dec 19, 2017 2:56 pm

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:

http://www.meticulus.co.vu/p/tactical-o ... 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 OS.by users infinitely better qualified than myself ( alas still a linux novitiate with no experience at all in coding or compiling.)


viewtopic.php?f=66&t=148185&p=975000&hilit=mpv#p975000

viewtopic.php?f=63&t=153480



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:


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


The entry :

geometry=20%+1075+550

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 playlists ,cycling through aspect ratios although it always seems to find the correct aspect ratio au tomatically. 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: 

http://downloads.sourceforge.net/smplay ... .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 :http://www.smtube.org/ 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:

https://github.com/mpv-player/mpv/issues/2532 

and here

https://github.com/mpv-player/mpv/pull/2723.

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:


https://raspberrypi.stackexchange.com/q ... 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.

Gadgetguy
Posts: 63
Joined: Fri Aug 15, 2014 2:55 am

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

Tue Dec 19, 2017 3:28 pm

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.

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Wed Dec 20, 2017 1:42 pm

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.

jccj78
Posts: 2
Joined: Sun Dec 17, 2017 3:05 pm

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

Wed Dec 20, 2017 7:24 pm

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!

tomf90
Posts: 7
Joined: Sun Dec 10, 2017 5:36 pm

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

Fri Dec 22, 2017 7:04 pm

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.

Cheers

jerryrp
Posts: 5
Joined: Sat Dec 23, 2017 7:39 pm

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

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?

RPi_Mike
Posts: 14
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Sun Dec 24, 2017 4:17 am

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!

Gadgetguy
Posts: 63
Joined: Fri Aug 15, 2014 2:55 am

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

Sun Dec 24, 2017 7:37 am

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.

Return to “Graphics, sound and multimedia”

Who is online

Users browsing this forum: bernyone and 12 guests