User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Tue Oct 09, 2018 12:34 am

usable wrote:
Sun Oct 07, 2018 11:04 am
Just signed in to say thank you so much. You are awesome, man! ;) ;) ;)

Ah yes, I remember you – I helped you out on here about 7 months ago!

So just out of curiosity, what inspired you to thank me so much just now? Is it because you recently "upgraded" from my original tutorial to my newly automated script?

I realize that English is not your primary language (as you mentioned earlier this year) – but if you can offer a few details, I would certainly be interested to hear them!

Moredrivers
Posts: 1
Joined: Mon Oct 08, 2018 9:16 pm

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

Thu Oct 11, 2018 11:16 am

hi Mike

have a question to the scriptwriter because i can,t find the script for the ffmpeg for the rasp berry 3 . Please helpme .
requards Gerard

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Fri Oct 12, 2018 6:03 am

Moredrivers wrote:
Thu Oct 11, 2018 11:16 am
i can,t find the script

I'm honestly not sure why you would make that unusual claim.

My script is right in the middle of my tutorial and is clearly marked by giant dashed lines in bold and blue. In fact, this is exactly what the beginning of it looks like:

-----------------------------------------------------------------
***START OF SCRIPT – DO NOT COPY THIS LINE OR THE DASHED LINES***
-----------------------------------------------------------------


If you're having trouble scrolling or need help with other basic computer operations, please consult a friend or instructor who can assist you. This thread is not an appropriate forum for that kind of discussion.

delboy07
Posts: 2
Joined: Sat Oct 13, 2018 10:00 am

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

Sat Oct 13, 2018 11:37 am

Found this excellent tutorial after having problems compiling ffmpeg today. Unfortunately script didn't work the problem was the same as that described by Suicinivrovich:
Suicinivrovich wrote:
Thu Sep 20, 2018 8:40 pm
Hi,
All worked fine and smooth except that for whatever reason mpv dis not compile, failing at the “waf configure” step saying the below:

Code: Select all

Checking for libav* is Libav                                         : no
Checking for Libav/FFmpeg library versions                           : no ('libavutil >= 56.12.100 libavcodec >= 58.16.100 libavformat >= 58.9.100 libswscale >= 5.0.101 libavfilter >= 7.14.100 libswresample >= 3.0.100' not found) 
Unable to find development files for some of the required FFmpeg/Libav libraries. Git master is recommended.
Problem is likely to be associated with the building of the libavcodec during the build of ffmpeg not mpv. To check this go to the ~/Vidware_Build/ffmpeg/libavcodec directory and type ls and check that you have the files

libfdk-aacenc.c libfdk-aacenc.d libfdk-aacenc.o

if you are missing the last two files then the solution to your problem is given here https://github.com/mstorsjo/fdk-aac/issues/93.


After manually applying the patch to libfdk-aacenc.c you can run the script from the make -j4 command in the ffmpeg section and all should work.

If you had down loaded a static binary from https://johnvansickle.com/ffmpeg/ as described https://www.raspberrypi.org/forums/view ... p?t=176239 this commands and script in this tutorial will not remove it and will give the impression that the compilation of ffmpeg has worked

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Sun Oct 14, 2018 4:05 am

delboy07 wrote:
Sat Oct 13, 2018 11:37 am
Found this excellent tutorial after having problems compiling ffmpeg today

Exactly! In other words, after conducting a series of failed experiments building and installing OTHER versions of FFmpeg – thus making a series of unknown and fundamental alterations to the very parts of your system that my script depends on – you finally stumbled across my tutorial and expected it to work!



delboy07 wrote:
Sat Oct 13, 2018 11:37 am
Unfortunately script didn't work

Precision in language is important, especially in dealing with technical matters. Saying my "script didn't work" creates the false impression that there's something fundamentally wrong with my script. A better phrasing would have been that the script didn't work on YOUR system. This may seem like a minor semantic quibble, but it's a hugely important distinction – because it perfectly captures the true nature of the entire problem you're reporting.



delboy07 wrote:
Sat Oct 13, 2018 11:37 am
Unfortunately script didn't work the problem was the same as that described by Suicinivrovich:

Uh oh! Two separate people have now reported the same problem with RPi_Mike's script! This doesn't sound good, because it suggests a pattern – that there may indeed be something wrong with my script. After all, how could two unrelated people have the same problem if there isn't something wrong with the script?

There's just one problem with that interpretation: You failed to mention the critical part where Suicinivrovich revealed that before he used my script, he executed a totally separate and unrelated script that had "gone wild" on his system and "deleted and messed with the setup" he had previously created with prior versions of FFmpeg and mpv. In other words, just like you, the very parts of his system that my script relies on had been altered in unknown and fundamental ways.



delboy07 wrote:
Sat Oct 13, 2018 11:37 am
Problem is likely to be associated with the building of the libavcodec during the build of ffmpeg not mpv..... if you are missing the last two files then the solution to your problem is given here https://github.com/mstorsjo/fdk-aac/issues/93

Believe it or not, I might actually agree with your "proximate" diagnosis as it relates to your particular, experimented-on system. But it's important to distinguish between a "proximate" diagnosis that may be superficially correct and a fundamental diagnosis that truly explains the problem.

A good example of this would be a doctor that correctly diagnoses a patient's infection – but simultaneously gets the true diagnosis wrong! But wait – how can that be? That makes no sense! How can someone be right – but ultimately wrong – about the same thing? It's easy: Unbeknownst to the doctor, the patient has leukemia – a cancer of the bone marrow that has now spread to the white blood cells. And what do the white blood cells do? They fight infection! So although it's good that the doctor spotted the infection, he has also condemned the patient to death by entirely missing WHY the infection occurred in the first place.

The link you reference points to a discussion about FFmpeg and fdk-aac problems with git-acquired source code from master – developmental code that constantly changes from day to day. My script, however, deliberately avoids all those unpredictable problems by using LOCKED-DOWN "stable release tarballs". That means my script reliably uses the same proven source code every time – whether you ran it in the past or run it in the future. That also means that it's impossible for any source-code-related problems to suddenly crop up in my script – with libavcodec or anything else. [OK, fine – nothing is truly "impossible". For example, a hacker could theoretically break into the GitHub servers and secretly tamper with the source code inside a locked-down tarball.]

So no – when it comes to my script, there is no "problem" that's "associated with the building of the libavcodec during the build of ffmpeg". On a perfectly normal, standard copy of Raspbian that hasn't been tainted by a series of previous experiments with other FFmpeg tutorials and builds, my script works perfectly. In fact, what I told Suicinivrovich last month applies equally in this case: "The bottom line is that my entire script is "known good". It has been thoroughly tested – personally by me – on a clean, properly-working copy of Raspbian Stretch."



delboy07 wrote:
Sat Oct 13, 2018 11:37 am
If you had down loaded a static binary from https://johnvansickle.com/ffmpeg/ as described [at] https://www.raspberrypi.org/forums/view ... p?t=176239 [the] commands and script in this tutorial will not remove it

Exactly! My script makes no attempt whatsoever to tamper with or "sanitize" a person's operating system from previous unknown experiments with FFmpeg or any other software. In fact, I proudly failed to test my script on systems with Raspbian + John Van Sickle – just as I proudly failed to test my script on systems with Raspbian + John von Neumann.

That's why I repeatedly bent over backwards – multiple times, all throughout my tutorial – to say that the only "guarantee" I offer is that my script will work on truly "clean", "normal", "standard" copies of Raspbian. I made such a giant show of this because I know from personal experience that the Raspberry community is loaded with people that love to experiment and "tinker" and do all kinds of things with their systems – and to be clear, there's absolutely nothing wrong with that! In fact, it's the core ethos of the Raspberry Pi Foundation and I fully support it.

Nonetheless, I also know that this highly experimental environment poses an "unfair" reputational danger to my tutorial – a tutorial that I have worked on very hard to fully validate and perfect – because some will inevitably come into it with an unorthodox or damaged system with a "history" — the kind of history that's guaranteed to throw a giant monkey wrench into any script!

User avatar
innocent_bystander
Posts: 71
Joined: Mon Oct 15, 2018 12:15 am
Location: Florida, USA

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

Mon Oct 15, 2018 1:00 am

Hi RPi_Mike,
Thanks for putting together the script. Is there any reason not to host prebuilt .deb binaries in a repo and have everyone do the good ole:

Code: Select all

add-apt-repository <Mike's cool repo name>
apt install ffmpeg mpv etc...
Will save you some headaches from dealing with people's compilation problems, etc. The trees will like it too. ;)

-TJ
The motto of the Sirius Cybernetics Corporation is "Share and Enjoy."

To show appreciation for our efforts, please deposit any amount into our Nutri-Matic Drinks Dispenser: https://paypal.me/buy1coffee4me

delboy07
Posts: 2
Joined: Sat Oct 13, 2018 10:00 am

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

Mon Oct 15, 2018 12:05 pm

Think I should have been more verbose in my previous post. Apologies if your thought I was in anyway criticising your brilliant work. I should have said " the script didn't work on my system because of previous attempts I had made to install ffmpeg which I had failed to fully remove from the system".

This tutorial is excellent and if the instructions are followed fully there is no problem. Indeed, in nearly fify years of programming I don't think I have seen a clearer and better example.

What my post was trying to do was to explain that I was able to generate Suicinivrovich error message when like him I tried the script on a machine where I had tried to compile version 4.0.2 without success not using this script. In my case I had then download directly a static version of ffmpeg to use while I sorted out the problem (not something to be recommended.)

Before running the script I thought I had cleaned the machine of all my earlier attempts - but when it failed I finally discovered that the problem was with still having fdk v2 on the machine. This took me a while to discover. For while I had used package manager to clean the machine it hadn't removed the static copy of ffmpeg. So at first I thought the script had compiled the ffmpeg and the problem was with mpv build. It was only on reading through the full output did I realise the problem and remember that I had directly installed the ffmpeg static.

Please accept my apology if I have offended you. There is definitely no problem with you script. Keep up the good work.
Still learning to recognise brick walls when I see them

frost-byte
Posts: 2
Joined: Mon Oct 22, 2018 6:07 pm

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

Mon Oct 22, 2018 6:28 pm

Hi Mike,

First of all thanks for taking the time to maintain your project and so thoroughly document it.
I've been able to set this up on two different Raspberry Pi's. I just needed to have access to FFMpeg because my intention is to use it to stream to Twitch. (I already set up the first PI to take a recorded stream from a laptop connected to it and then encode and stream it up to Twitch and that works)

For the second PI I've added the v2 Camera Module and I'd like to composite the output of that with the recorded stream. I found another repo that lets you monitor the camera output via a web interface, however, because OpenGl ES only allows one video stream to use the GPU I obviously can't use mpv and that software at the same time. (Though I'm going to look into how I can composite the stream from the other device with the output of the camera, then maybe I can just view the combined output?)

I guess my question is, do you know of software that can do that, that will run on the RPi? (Combine the camera output with another stream) I'm aware that this is an indirect use of what you provide, but was hoping you might know of something, since you obviously already know about related software.

Thanks,
B

User avatar
innocent_bystander
Posts: 71
Joined: Mon Oct 15, 2018 12:15 am
Location: Florida, USA

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

Tue Oct 23, 2018 6:46 pm

frost-byte wrote:
Mon Oct 22, 2018 6:28 pm
I guess my question is, do you know of software that can do that, that will run on the RPi? (Combine the camera output with another stream)
You should be able to do this with ffmpeg using 'scale' and 'overlay' filters. Take a look over here: https://www.oodlestechnologies.com/blog ... ing-FFMPEG

-TJ
The motto of the Sirius Cybernetics Corporation is "Share and Enjoy."

To show appreciation for our efforts, please deposit any amount into our Nutri-Matic Drinks Dispenser: https://paypal.me/buy1coffee4me

frost-byte
Posts: 2
Joined: Mon Oct 22, 2018 6:07 pm

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

Thu Oct 25, 2018 1:13 am

Thanks TJ,

In the meantime I've been able to put together an ffmpeg command to combine my video stream from udp into an overlay using the complex filter. (likely what you are referring to) I'm able to get my stream working and it's sending it up to twitch, unfortunately I'm still trying to work out what is causing some visual artifacts. I've got a Virtue case for my Pi 3B+ that has a fan and 3 heat sinks to control the temps, so it's probably just a matter of the right config for ffmpeg. I was able to figure out that there are some hardware encoders/decoders available using this build of ffmpeg, and that greatly helped get rid of a lot of the errors I was seeing.

Of course none of this directly relates to this guide, other than the fact that the ffmpeg compilation seems to work very well. :D

-B

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Mon Oct 29, 2018 12:56 am

delboy07 wrote:
Mon Oct 15, 2018 12:05 pm
Apologies if you thought I was in any way criticising your brilliant work. I should have said "the script didn't work on my system because of previous attempts I had made to install FFmpeg which I had failed to fully remove from the system".

This tutorial is excellent and if the instructions are followed fully there is no problem. Indeed, in nearly fifty years of programming I don't think I have seen a clearer and better example.

Your reply is greatly appreciated. To be honest, you handled your response in a very thoughtful and reasonable way. So thank you!

Now the following is not directed to anyone in particular – it's just a general commentary:

My 16,000-word tutorial sometimes feels like a miniature doctoral thesis with a giant catch:

When a PhD candidate defends their dissertation, it's a one-time deal. Although their claims may face a vigorous challenge by a panel of experts, they ultimately get to put it behind them if they make it through the gauntlet. Once they've earned their PhD – barring a future discovery of outright fraud – no one can come along later and "challenge" their accolade.

This site, however – like any public forum – is the opposite of that: Although I have thoroughly proven my claims, any random person on the Internet is free to come along and "challenge" me with bogus claims at any time.

Whether these claims are deliberate or unintentional, having to repeatedly beat back false claims about alleged "errors" in my thoroughly tested work can get quite tiresome. This is especially true if someone didn't even read my carefully-documented instructions – or merely ASSERTS that it "didn't work" without any explanation or honesty about the true nature of their system and what they may or may not have done to it before they even laid eyes on my tutorial.

Of course, I could just ignore all of this. And some day I may do exactly that – allowing the inevitable free-for-all to commence. After all, even the universe itself appears to have an expiration date – so I know I can't keep defending my work forever!

For now, at least – due to the heavy "psychological investment" I have made in my tutorial – I will continue to hold the line with great vigor and aplomb.



innocent_bystander wrote:
Mon Oct 15, 2018 1:00 am
Thanks for putting together the script. Is there any reason not to host prebuilt .deb binaries in a repo and have everyone do the good ole:

add-apt-repository <Mike's cool repo name>

apt install ffmpeg mpv etc...

If they wanted, the Raspberry Pi Foundation (RPF) could take things even further and make my entire suite of FFmpeg / mpv software the official Raspbian repository build.

But there's a very good reason not to do any of that. That reason, in fact, is emphasized repeatedly in what amounts to the RPF's official mission statement. The entire thing is only two paragraphs long, so here it is – emphasis added by me:


The Raspberry Pi Foundation is a UK-based charity that works to put the power of digital making into the hands of people all over the world, so they are capable of understanding and shaping our increasingly digital world, able to solve the problems that matter to them, and equipped for the jobs of the future.

We provide low-cost, high-performance computers that people use to learn, solve problems and have fun. We provide outreach and education to help more people access computing and digital making. We develop free resources to help people learn about computing and how to make things with computers, and train educators who can guide other people to learn.



Everyone, of course, is free to have their own opinion about my tutorial and script in terms of what its ultimate purpose should be. There is, after all, no "objective truth" when it comes to the final form a piece of code should take. In that sense, it's a subjective matter of taste. But in my opinion, the primary purpose of my tutorial – and its thoroughly annotated Bash script that explains exactly what I'm doing at every step – is that of a learning tool that fits perfectly with the RPF's mission.

The fact that a suite of "killer apps" comes along for the ride is really just a giant bonus – and a strong incentive to do a modest bit of learning in the process.

If my entire body of work "disappeared" and became available through a simple one-liner, a very practical example of computer science would vanish along with it – how to turn raw source code into a working program.

I'm well aware that my tutorial and a quick installer could co-exist. But if people knew they could obtain the fruits of my tutorial through a one-liner that only takes 3 seconds, it's just human nature that few would bother to learn anything about it. Most would just "install it" and learn nothing in the process, thus defeating the very mission of the RPF.

As it stands, it only takes about 5 brief minutes to prepare my fully automated script for execution – so I'm already striking a very reasonable balance between learning and convenience.



frost-byte wrote:
Thu Oct 25, 2018 1:13 am
Of course none of this directly relates to this guide, other than the fact that the FFmpeg compilation seems to work very well. :D

Glad you're "very happy" with my build of FFmpeg (as indicated by your emoji). You're right, though – your advanced compositing experiments have little relation to my guide – other than the fact my script provides a state-of-the-art platform to conduct your own investigations. To the entities known as "frost-byte" and "innocent_bystander": Let's try to keep things focused and "on topic"!

DougShuffield
Posts: 2
Joined: Mon Dec 10, 2018 9:56 pm

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

Mon Dec 10, 2018 10:07 pm

Thanks for the excellent script!

I have just done a clean install of the following on a Raspberry Pi 3 B+:

Raspbian Stretch with desktop
Version:November 2018
Release date:2018-11-13
Kernel version:4.14

I then ran your script as specified. Everything seems to compile and run as expected except that I cannot seem to display mpv in a smaller window using the --geometry option. For instance, I use the command 'mpv --loop=9 --geometry=50% Neutron_Stars_Colliding_1080p.mp4' but it still plays full screen. Am I missing something?

Any plans on testing on the November Rasbian release with ffmpeg 4.2? After I resolve this windowing issue, I need to move to ffmpeg 4.2 due to issues streaming my udp streams that is fixed in ffmpeg 4.2.

Doug

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Tue Dec 11, 2018 4:54 am

DougShuffield wrote:
Mon Dec 10, 2018 10:07 pm
Thanks for the excellent script! ..... Everything seems to compile and run as expected

I'm glad my script worked well for you!



DougShuffield wrote:
Mon Dec 10, 2018 10:07 pm
I cannot seem to display mpv in a smaller window using the --geometry option. For instance, I use the command 'mpv --loop=9 --geometry=50% Neutron_Stars_Colliding_1080p.mp4' but it still plays full screen. Am I missing something?

FULL-SCREEN PHILOSOPHY:
Your description demonstrates that my build of mpv is performing "as intended" – and doing so in a perfectly correct and rational way!

That's because I deliberately programmed my script to automatically force mpv into full-screen mode whenever it plays a video.

Most people want to sit back and relax and enjoy "pure video" with no distractions. In my subjective opinion, therefore, it's the optimal default setting. Since I'm the author of the script, that's what I chose.

[This default behavior can be easily changed, however. More on this in a moment.]

In full-screen mode, it would make little sense to play a video at a smaller size when the rest of the screen is completely black, covered up, and unviewable. This is, after all, the deliberate nature of any video player's full-screen mode! The whole point is to fill your screen with video and eliminate any distractions.

However, I'm fully aware that there is one major "use case" for intentionally playing a large video as a smaller video. That would be "multitasking" – doing other things on your computer while simultaneously playing a smallish video in the corner of your screen, for example. In such a case, you would NOT want the video to be in full-screen mode – because there would be no way to see anything to multitask with in the first place!

My point is that the developers of mpv correctly share this common-sense perspective: Full-screen mode, therefore, interprets any attempt to shrink the video as being nonsensical and will therefore override it (thus playing the video in standard full-screen mode). This, by the way, has nothing to do with me – it is a core behavior of mpv itself.




FULL-SCREEN OPTIONS FOR MULTITASKING:
If you want videos played in a smaller size for multitasking purposes, you have 3 simple options:

1: PRESS THE f KEY: The "f" key is the convenient on/off toggle for full-screen mode. Since full-screen mode is the default setting established by my script, the command line you were using will initially play the video in "full-screen / full-size" mode. In other words, it will be displayed at 100% size – the size you don't want. So if you want it to instantly revert to your requested 50% size, all you have to do is tap the "f" key... and BOOM – it will appear exactly as your command line instructed! That's because, by tapping "f", you're temporarily switching off full-screen mode – so the override of your 50% request no longer occurs! The other cool thing is that if you're currently watching a video in "50% mode" or "20% mode", etc., you can tap the "f" key at any time and mpv will instantly switch to 100% full-screen mode! Tap "f" again and BOOM — right back to 20% mode or whatever you had chosen.


2: PRESS ALT + 0 AND THEN THE f KEY: This will work on any video – whether you launched it from the command line or by double-clicking it in File Manager. This is for when you have NOT issued any special geometry request. That's because ALT + 0 (zero, not an O) is mpv's standard keyboard shortcut for "window-scale 50%". Once you use ALT + 0 to switch to "50% mode", of course, you still need to exit full-screen mode by pressing "f" to see the results (because, as mentioned earlier, full-screen mode will override any attempt to shrink the video).


3: CHANGE MPV'S DEFAULT SETTINGS: If playing videos in a small window for the purpose of multitasking is something you wish to do all the time, just de-activate "automatic full-screen mode" in mpv's configuration file (mpv.conf)! You can quickly edit the mpv.conf file by simply running the following command line. Just place a "#" in front of "--fullscreen" to remark out (and thus disable) the full-screen setting. Once you do that, mpv will no longer place videos in full-screen mode by default – and therefore, your geometry choice will no longer be overridden. You can also set your preferred geometry in the mpv.conf file as well (the next section of my post tells you how to do that):

leafpad /home/pi/.config/mpv/mpv.conf




GEOMETRY OPTIONS FOR MULTITASKING:
Here are a few tips on how to display a "small window" in a more sophisticated way. The advanced methods I describe not only allow you to control the size of the video, they also allow you to control the location of the video:

SIMPLE COMMAND-LINE METHOD: Play a video in "50% small mode" right in the middle of your screen (not too useful for multitasking):

mpv --geometry=50% video.mp4


ADVANCED COMMAND-LINE METHOD #1: Perfect multitasking size in upper-left corner (on a 1080p screen):

mpv --geometry=20%+0+0 video.mp4


ADVANCED COMMAND-LINE METHOD #2: Perfect multitasking size in upper-right corner (on a 1080p screen):

mpv --geometry=20%+1536+0 video.mp4


ADVANCED DEFAULT SETTINGS METHOD:

Place any of the above "--geometry" options directly inside mpv's configuration file! For example, you could simply place the following item on a line by itself in the mpv.conf file. Once you do that, all videos will automatically appear in a small overlay in the upper-right corner of your screen:

--geometry=20%+1536+0

Be sure to also remark out the "--fullscreen" option in the mpv.conf file so that your geometry choice is not overridden (place a "#" at the front of the line to disable it). Once you do that, your preferred "small video mode" will become mpv's default behavior! That means if you double-click a video it will automatically exhibit the geometry you want without any command lines. It also means that if you want to use mpv in a command line, you'll no longer have to specify the geometry. Best of all, you can tap the "f" key at any time to instantly switch back-and-forth between "small video" and "full screen" modes!


CRITICAL NOTE: The seemingly arbitrary geometry numbers that you see above (like 1536) only apply to a 1080p screen. If you have a lower-resolution display, you will need to change the math. I explained all of this – and much more – in my very comprehensive appendix on mpv:

APPENDIX 1: MOST ESSENTIAL MPV KEYBOARD CONTROLS & OPTIONS




THE RASPBERRY PI 3 – AN OUTSTANDING $35 COMPUTER:
I've addressed the concept of "multitasking" because your question lent itself to that. Keep in mind, however, that the Raspberry 3 is still a $35 computer. Although my script creates a system that will play 1080p video like a $3,000 computer, multitasking itself is an entirely different and unrelated subject. In fact, the Raspberry is definitely not intended for any significant multitasking! The reality is that it can barely handle certain kinds of "singletasking" (I'm especially thinking of the Chromium web browser and how easily it will choke up your entire system with anything beyond light-duty web browsing). So when it comes to multiasking, your mileage can vary dramatically – and that has absolutely nothing to do with mpv, FFmpeg, or my script!

That said, however, my build of mpv is extremely light on the CPU when playing the most popular video format in the world – an H.264-based MP4. That's because my version of mpv does all the heavy lifting in the Raspberry's GPU, not the CPU. So even a high-definition 1080p video will typically use only 5% of the CPU – thus leaving a ton of computational resources freely available for other purposes!



DougShuffield wrote:
Mon Dec 10, 2018 10:07 pm
I need to move to ffmpeg 4.2

FFmpeg 4.2 is not out yet! According to FFmpeg's official website, the current stable release version is 4.1.

DougShuffield
Posts: 2
Joined: Mon Dec 10, 2018 9:56 pm

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

Tue Dec 11, 2018 3:14 pm

Great! Thanks for the detailed info. And yes, my mistake, I meant ffmpeg 4.1.

I need a smaller screen for my particular use case since I intend to create a picture-in-picture output with screen + mpv using two udp streams. We will see if the RPI B+ has enough power to pull it off. I suspect I may run into issues with the network bandwidth...We shall see.

I will also go ahead and try my hand at modifying the script to use ffmpeg 4.1. Looks like a pretty straightforward modification.

Thanks again for the great script (and the countless hours I am sure it took to make it bulletproof!)

Doug

User avatar
rpiMike
Posts: 852
Joined: Fri Aug 10, 2012 12:38 pm
Location: Cumbria, UK

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

Tue Dec 11, 2018 9:02 pm

Thanks for the great script.

I'm streaming my PS Vita to the Pi using mpv - seems to work pretty well.

https://www.youtube.com/watch?v=BBCCKv-wCis

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Thu Dec 13, 2018 9:06 am

rpiMike wrote:
Tue Dec 11, 2018 9:02 pm
Thanks for the great script.

I'm streaming my PS Vita to the Pi using mpv - seems to work pretty well.

https://www.youtube.com/watch?v=BBCCKv-wCis

RPi_Mike says "you're welcome" to rpiMike!

I just watched a 1080p copy of your video.

Your set-up looks EXTREMELY SLICK! And the scrolling motion is super smooth and "snappy".

Knowing that my script was part of your solution is personally rewarding, so I really appreciate you sharing that!

It's also nice to finally meet my "screen name doppelgänger".

[Meant in the non-demonic, neutral sense of the term, of course!]

However, since you've been a member of this website 5 years longer than I have, perhaps I'm the true doppelgänger!

rocky1410
Posts: 1
Joined: Wed Dec 19, 2018 9:05 pm

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

Wed Dec 19, 2018 9:11 pm

I'm using RPi 3 B+ board, when I use --start command, I'm getting error "Error while decoding frame!" and Dropped frames increasing continuously. Without --start command it works perfect with same file. "mpv --start=30 "filename.mkv"

trigu75
Posts: 3
Joined: Fri Dec 07, 2018 2:22 am

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

Mon Dec 24, 2018 6:51 pm

Great post , I successfully built using your script and even changed ffmpeg and mpv configure options adding shared links and libmpv

My question is there any way to compile this making it to work with the Kims drivers enabled?

My problem is , with Kim’s disabled , mpv works great , but libmpv makes the other app using it terminate

And if I enable the Kims drivers , I get the service in use error

I am trying to make a rip version of stremio , and it uses qt5 and mpvlib

Using stretch libmpv (0.23.0) works , but without acceleration , which is why I tried to use this hardware accelerated version

The interesting fact is 0.23.0 works even having Kms enabled

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Tue Dec 25, 2018 9:04 am

trigu75 wrote:
Mon Dec 24, 2018 6:51 pm
Great post, I successfully built using your script

Excellent!



trigu75 wrote:
Mon Dec 24, 2018 6:51 pm
My question is there any way to compile this making it to work with the Kims [KMS] drivers enabled?

As explicitly mentioned in my tutorial's "requirements" section AND Appendix 9, the EXPERIMENTAL desktop GL drivers – known as Full KMS and Fake KMS – will definitely NOT work with my build of mpv!

In fact, I'm not aware of anyone that's managed to pull off that trick. And if they have, they certainly haven't published their findings like I have.

My builds of FFmpeg and mpv are designed to work extremely well on a completely standard Raspberry with a completely standard configuration – on a completely standard copy of the Raspbian Stretch operating system!

My tutorial project was ambitious and difficult enough as it was – so I certainly don't have the time or inclination to start supporting experimental drivers or platforms!

I also have no understanding of the hidden, "bare metal" secrets deep inside the VideoCore GPU. Some of it is not even open-sourced or available for review – except for those granted special access to Broadcom's intellectual property.

And even if I did have access to that kind of information, I certainly don't have the highly-specialized expertise to make any sense of it!

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Tue Dec 25, 2018 9:07 am

rocky1410 wrote:
Wed Dec 19, 2018 9:11 pm
it works perfect

I'm glad to hear my script successfully built FFmpeg and mpv!



rocky1410 wrote:
Wed Dec 19, 2018 9:11 pm
mpv filename.mkv works perfect – but when I add the --start=30 option, I get "Error while decoding frame!" and dropped frames increasing continuously...

Three little letters give me a giant clue that you're attempting to play a "non-standard" video.

I say this for one simple reason – your video ends with the MKV extension!

For those that may not be familiar with MKV, it stands for the Matroska Multimedia Container.

To be clear, I'm not suggesting you're doing anything "wrong" – but you're certainly dealing with a "non-standard" video. So I'm not surprised it's behaving in a manner that doesn't entirely live up to your expectations.

Now before anyone thinks I don't know what I'm talking about, let me go on the record by making this seemingly contradictory statement:

The MKV container is AWESOME for several reasons. For one thing, it's a completely free and fully-open standard. Unlike almost all the other container standards out there – including MP4 – it's not "patent encumbered" or "proprietary" in any way. But more importantly, it's EXTREMELY FLEXIBLE. That's because you can put almost any kind of video and audio encoding format inside it.

By contrast, the vastly more popular MP4 container is NOT that flexible at all – especially by the standard of common, working implementations in the real world.

In theory, the MP4 container supports almost as many encoding formats as the MKV container. But the key phrase in my sentence is "in theory". As with many things, there's a big difference between theory and practice.

When I limit my analysis to (1) modern encoding formats that are (2) common on today's Internet, MP4s are virtually synonymous with only one kind of video encoding format – H.264. And when it comes to the audio encoding format you need to pair it with, you're limited to only 2 realistic choices – AAC or MP3. Again, I'm talking about "real-world common practice that works on almost all modern devices" – not what's theoretically possible on a nerd's computer.

Remember also that there's a GIANT elephant in the room that trumps everything else: Even if someone knows how to place an unconventional combination of encoding formats inside an MP4 container, what good is it if most media players, web browsers and software can't play it? I would argue it's NOT GOOD AT ALL. It's basically worthless.

So, back to MKV. I'm a big fan of it. In fact, in many of my personal experiments with FFmpeg, it's my "go-to" choice for my "internal" work flow.

Creating and processing a video is a multi-stage endeavor – but if you're not careful, each stage can degrade the quality of the source material. So if your goal is to maintain a "lossless pipeline" – 0% image degradation during each processing step – MKV is by far the best and most flexible choice available. [MKV is a completely agnostic container that will just as happily accept a "lossy" encoding, but that's not the point I'm trying to make right now.]

For example, I'll typically choose one of two lossless video encoders while the video is still "in the pipeline": libx264 in "crf 0" lossless quality mode OR FFmpeg's built-in lossless encoder – FFV1. For audio, I'll typically choose the FLAC lossless encoder. The great part is that no matter what combination of encoders I choose, I can almost always drop them into the MKV container no matter what!

[My other favorite technique for a lossless pipeline is a frame-based image sequence approach – where I treat each frame of a video as a standalone image. For that, I use the inherently lossless PNG image format. But that's a topic for a different discussion.]

But here's the catch:

Everything I just said is great for "internal nerd use". But what about sharing the final video when all that internal processing is done? In other words, what modern format is best for "external" use? You know – actually sharing it with normal human beings that aren't FFmpeg nerds!

For that purpose, I would argue there's ONLY ONE LOGICAL CHOICE in the entire media universe:

An MP4 container with 2 things inside it: An H.264-encoded video track and an AAC-encoded audio track.

It's the closest thing you can possibly get to a truly universal standard that almost anyone with a device made in the last 10 years can actually play! That's why, in my view, anyone who wishes to share a video with a general audience would have to be insane to pick any other container or codec pair. It's literally MP4 or it's cra*!

And like most modern devices today – including the Raspberry 1, 2 and 3 – there's a big added bonus for standard MP4 videos: Full support for GPU-based "hardware acceleration". That means that instead of your general-purpose CPU struggling to decode and play the computationally intensive MP4 "in software", you have the amazing power of the GPU doing all the heavy lifting "in hardware" – a chip that's specifically designed from the ground up to play the MP4 perfectly without dropping a single frame.

That's also why my tutorial – which I first published a year ago in December of 2017 – was so significant. Other than some partially-successful builds of VLC that were available at the time, I was the first person to bring a flawlessly-working modern media player to Raspbian Stretch – the Raspberry Pi's official operating system. That player, of course, is my customized build of mpv – a build that fully leverages the power of the Raspberry's GPU.

But like many devices today – when it comes to modern encoders – the Raspberry's built-in GPU support "only" extends to standard H.264-based videos. I say "only" in quotes because that makes it sound like some kind of big limitation. The reality is that it's no more "limited" than the United States dollar. When it comes to the idea of a "universal currency", does the dollar have some "limitations"? Of course it does! That's because there's no such thing as a truly universal currency. You can still find people around the world that won't accept the dollar. But that doesn't change the truth of my statement even slightly – the U.S. dollar is still, by far, the closest thing you'll find in the real world to a universal money standard. And it's no different with an MP4 – it's as close as it gets to a universal video standard. So the fact that the Raspberry supplies full-blown GPU-based hardware acceleration for MP4 video is, in fact, a very big deal.

Now, believe it or not, all of this seemingly academic background relates directly to your question. That's because it provides the necessary context to make the following bold statement:

Outside of "nerd world", no "normal" person who knows what they're doing would ever post or share a video inside an MKV container.

That by itself makes the video you're attempting to play highly "suspicious". By "suspicious", I mean there's a very good chance it doesn't contain an H.264-encoded video. If I had to wager, it probably contains a VP9-based video or maybe even an H.265 video. Or maybe it contains the brand-new AV1 codec. Whatever the case, if there isn't an H.264 video inside the MKV container, you have to realize that no matter how amazing a media player is, it's simply NOT going to provide any GPU acceleration on the Raspberry. That's not a limitation of mpv or any other player – it's simply a fundamental "limitation" of the Raspberry itself.

NOTE #1: I'm fully aware the Raspberry's GPU also supports acceleration for MPEG-2 and VC-1 codecs. But those ancient standards – which are not free and require the purchase of a license – are simply not relevant to my explanation.

NOTE #2: Could an MKV have an H.264 video track inside it? Absolutely! And if it does, my build of mpv – despite the video not being inside an MP4 container – is smart enough to still give it 100% hardware acceleration!

In fact, I sometimes encounter an H.264 video inside an MKV container when I download a music video with youtube-dl. Sometimes, I'll hand-pick the highest quality video track that's available – while ALSO taking into account the "limitations" of the Raspberry's hardware. In other words, that means I'll pick a 1080p video track at 30 FPS that uses the "avc1" codec. [See my very detailed Appendix 2 for instructions on how to do this.] AVC1 – usually written in lower case by YouTube's servers – is just another name for H.264. So by picking an AVC1 / H.264, I'm guaranteeing that it will get full hardware support from the Raspberry's GPU. If I choose any other format – such as WebM / VP9 – there's no guarantee that it won't drop at least some frames. That's especially true if it's a 1080p video with a lot of motion and scene "complexity". Because if the GPU isn't helping out, it means all the heavy lifting is taking place inside the general-purpose CPU.

With a music video, I might also hand-pick the highest-quality audio track available. I might therefore choose an "opus @160k" audio track. But there's an issue with that: In most common implementations, an Opus-based audio track is NOT compatible with an H.264 / AVC1 video track! The solution? Youtube-dl, in conjunction with FFmpeg, automatically "merges" the 2 "incompatible" tracks by placing them inside an MKV container! So yeah, I have a few 1080p music videos as MKV files – with an unconventional H.264 / Opus codec pair inside. When I play it with my build of mpv, it provides an extremely high-quality experience!

An MKV like that works great on my Raspberry – because I get the best of both worlds: An H.264 video that plays perfectly on my GPU, along with the highest-quality audio track available. But again, if I ever intended to share that music video with a friend, I would certainly NOT pick that non-standard combination. Instead, I would pick the only combination that comes close to a truly universal standard: An H.264 / AVC1 video track + an AAC audio track that's wrapped inside an MP4 container!

NOTE #3: Despite the Raspberry not providing GPU support for other modern formats, my build of mpv still produces either perfect or near-perfect results for almost all 1080p videos – even without any assistance from the GPU. See my testing results section for more detail.

So a final "back to your question":

When dealing with an MKV container whose "video insides" are not "GPU-compatible" – especially if it also happens to be a 1080p – you're already pushing the Raspberry's CPU to its limits. But if you also force it to do "frame seeking" on top of that – like jumping ahead by an arbitrary amount of time – that certainly could push things over the edge. The CPU would already be straining, so any further "insult" could certainly make it even harder to keep up with the frames. Under those circumstances, the video could enter a point of no return – where the "drift" would keep accumulating and only get worse over time.

There's another possibility that has nothing to do with a "GPU-unfriendly" format choice – since I obviously don't know diddly about what's inside your MKV container: Some of your file's header data or timestamping could be damaged or missing. That would certainly throw things off. It might also explain why unmodified viewing works fine, but forcing it to seek forward to a specific time causes it to fall off a cliff.

So there ya go – I've covered all the bases in terms of what you're trying to do – and what your expectations should be.

But I'll go one even better!

Just in case this MKV video of yours is super important – for example, you're about to make a major presentation that finally unifies the General Theory of Relativity with the Standard Model – and you need your video to work flawlessly with full GPU support on the Raspberry – there's actually something very specific you can do with my build of FFmpeg. Just run the following command line in Terminal and it will take your MKV video – no matter what encoding technology it uses – and convert it into a perfectly standard and "visually lossless" MP4 video:

ffmpeg -i Nonstandard_Video.MKV -vf format=yuv420p -c:v libx264 -crf 18 -c:a libfdk_aac -b:a 128k Standard_Video.MP4

Is this command line or anything else in life guaranteed to work? Certainly not! If your MKV input video is sufficiently damaged, all bets are off. Nonetheless, especially since your video plays perfectly without seeking, it's got a great chance of doing exactly what you need.

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

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

Tue Dec 25, 2018 9:44 am

This is the range of (HW) Video Codecs all my RPis support (with the additional licenses and the extended firmware):
H264 H263 WVC1 MPG4 MPG2 VP8 VP6 VORB THRA MJPG
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
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Tue Dec 25, 2018 10:10 am

gkreidl wrote:
Tue Dec 25, 2018 9:44 am
(with the additional licenses and the extended firmware)

I'll take that to be your official Christmas Day message!

johndavies
Posts: 182
Joined: Fri Dec 20, 2013 1:00 pm

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

Thu Dec 27, 2018 9:51 am

The Australian Broadcasting Corporation provides 4 live streams on its iview channel. The enhanced and improved mpv will play them at present. Below are the details:

Code: Select all

Programmes
https://iview.abc.net.au/show/abc-live-stream/video/IV1512H001S00
News
https://iview.abc.net.au/show/abc-news-24/video/NS1413V001S00
Comedy (certain times)
https://iview.abc.net.au/show/abc2-live-stream/video/LS1602H001S00
ABCME (certain times)
https://iview.abc.net.au/show/abc3-live-stream/video/LS1603H001S00
Ignore the "Code:Select all". I have forgotten, if I ever knew, how to use the URL indicators.

User avatar
RPi_Mike
Posts: 200
Joined: Sat Dec 09, 2017 12:57 am
Location: United States

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

Thu Dec 27, 2018 12:42 pm

johndavies wrote:
Thu Dec 27, 2018 9:51 am
The Australian Broadcasting Corporation provides 4 live streams on its iview channel. The enhanced and improved mpv will play them at present.

Thanks John!

I just tuned in to one of the links you shared and watched a few minutes of Australian cricket.

Even though I obviously understand the basics of Internet technology, I still find it astonishing that of the 200,000+ years that anatomically modern humans have walked the Earth, only "0.1% ago" it would have taken several weeks or months for even the slightest shred of news to make the perilous journey from Australia to America. Yet today, I can stream high-definition video from a $35 Raspberry – live from the other side of the world!

A quick note of clarification to the other readers out there: When John says he played the live streams with "the enhanced and improved mpv", he's referring to the one my script creates – not some other version of mpv out there! I know this is what he means because we communicated previously on this site.

For those that would like to know more about my build's worldwide streaming capability, check out my extremely detailed Appendix 4.

migg
Posts: 1
Joined: Sun Dec 30, 2018 11:04 pm

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

Mon Dec 31, 2018 2:48 am

I found a way to recode h264 faster, this is how the ffmpeg behaves with native h264+hw encode

Videos is a 1080p youtube video, format 137 (youtube-dl -f 137), with a lot of movement

With ffmpeg h264 native decoding + hw encoding

cd /dev/shm


time /usr/bin/ffmpeg -t 60 -i video.mp4 -codec:v h264_omx youtube.mp4 -y

Code: Select all

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_omx))
frame= 1439 fps= 16 q=-0.0 Lsize=    2478kB time=00:00:59.97 bitrate= 338.5kbits/s speed=0.659x    
video:2471kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.280165%

real	1m32,441s
user	4m43,090s
sys	0m23,650s


with hw decoding + hw encode

time /usr/bin/ffmpeg -t 60 -codec:v h264_mmal -i video.mp4 -codec:v h264_omx youtube.mp4 -y

Code: Select all

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_mmal) -> h264 (h264_omx))
frame= 1439 fps= 17 q=-0.0 Lsize=    2465kB time=00:01:00.06 bitrate= 336.2kbits/s speed=0.711x    
video:2458kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.282149%

real	1m25,854s
user	0m26,338s
sys	0m33,044s
On raspi-config, advanced memory split, to recode 480p you can go with 64 megas, to 720 you need at least 128, for 1080p you need at least 256

Its a 10% faster, but the good thing is that with hw decoding your cpu is at 25% , when with soft decoder is 100% , so you can use the cores for other things. Im using a raspberry pi 2

The key is tell ffmpeg to use hw decoding before the -i

ffmpeg -codec:v h264_mmal -i video.mp4 -codec:v h264_omx youtube.mp4

With 720p the recode speed is 41 fps

So the raspberry pi is a bit more powerful of what i though on higher resolutions and recoding

Return to “Graphics, sound and multimedia”