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

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

Mon Dec 31, 2018 11:36 pm

migg wrote:
Mon Dec 31, 2018 2:48 am
I found a way to recode h264 faster..... with hw decoding + hw encode

As you discovered, my build of FFmpeg is fully equipped to utilize the Raspberry's GPU – on both the decoding AND encoding sides.

It should be pointed out, however, that re-encoding a video with a "lossy" encoder that's already been encoded with another "lossy" encoder – whether you do it with the GPU or the CPU – is not ideal for the simple reason that each "generation" of encoding will degrade the quality to some degree.

But I fully realize there are some "use cases" when re-encoding is necessary: Any time you wish to fundamentally alter a video's properties, you must re-encode it – such as resizing it, lowering its bit rate, or modifying its visual content. [Unless of course you're the author of the video and still have access to a losslessly-encoded "source file". Then you have the luxury of making any edits you wish before making a brand-new "first generation" encoding – without any penalty in quality whatsoever. Or, if you only need to change the audio track, you can alter it without touching the video track by "passing the video track through" as a direct copy – even if you don't have access to the source file.]

Beyond this, for those that wish to occasionally encode brief videos at the HIGHEST QUALITY POSSIBLE – and don't mind if things take a bit longer – I personally recommend doing everything "in software". In other words, let FFmpeg do everything on the CPU, not the GPU. Yes, the GPU's "hardware acceleration" can be up to 3 times faster at encoding – but you must also realize that the software engineers behind both FFmpeg and x264 have much greater flexibility (and desire) to optimize their code for the general-purpose CPU. And, when you choose the CPU over the GPU, you also have access to a wider range of settings and techniques – including two-pass encoding. Bit for bit, at least on the Raspberry, CPU-based encoding is capable of producing higher-quality results than the GPU.

So if I've spent several hours creating a special effect video, for instance, I'm certainly not going to cut corners at the very last step for the sake of "saving" a few minutes on the encoding.

But if you're pressed for time and have a lot to encode, the GPU could easily be the only logical choice. With sufficiently high bit rates, the GPU delivers surprisingly good results. Not only that, but at SD-level resolutions (640 x 480), the GPU has the raw horsepower to encode the video in REAL TIME!

That's why I'm completely agnostic about CPU vs. GPU-based encoding. Like many things in life, each has its pros and cons. It all depends on what you're trying to do!

wormyrocks
Posts: 2
Joined: Fri Jan 11, 2019 5:48 pm

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

Fri Jan 11, 2019 5:53 pm

Hi,

I've run this script on a clean install of the latest version of Raspbian, following the instructions exactly - when I try to run mpv, I get the following error:

Code: Select all

Playing: Neutron_Stars_Colliding_1080p.mp4
 (+) Video --vid=1 (*) (h264 1920x1080 29.970fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[vo/rpi] Could not get DISPMANX objects.
Is anyone else seeing an issue like this? Thanks!

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

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

Sun Jan 13, 2019 4:40 am

wormyrocks wrote:
Fri Jan 11, 2019 5:53 pm
I've run this script on a clean install of the latest version of Raspbian, following the instructions exactly - when I try to run mpv, I get the following error..... Could not get DISPMANX objects.

One of the great things about computer science is that it's a "hard" science like physics or chemistry. Unlike a "softer" science like psychology or climatology, most claims can be verified in a truly definitive way. The biggest test of all is a simple one: Under the same conditions, can the results be fully replicated?

We obviously don't have two Earths on which to conduct comparative studies – nor can we take a 40-year-old back to the womb to see how different the outcome would be if we changed a key behavior in the mother or father.

To be clear, I'm not knocking the "softer" sciences even slightly – I'm simply stating a fact. Sure, we can create supercomputer simulations of multiple Earths and "experiment" on them. We can also look at "twin studies" of genetically identical siblings who were separated at birth to get a good understanding of nature vs. nurture.

These methods, however – though extremely insightful – are hardly as "concrete" and "verifiable" as dropping a steel ball in separate laboratories in London and Tokyo and demonstrating that both objects drop at exactly the same speed to an extreme degree of precision. [Under vacuum conditions while accounting for local variations in the gravitational field, of course.]

That's the beauty of the Raspberry – it brings computer science to life in a fully testable, verifiable, inexpensive, and widely available way. This is especially true if two or more people – or laboratories – both begin with completely identical, clean copies of the Raspbian operating system!

So, just a few minutes ago, I used that scientific principle to test your claim:

I completely nuked an SD card, reinstalled the latest version of Raspbian Desktop, and then followed my own instructions without any assumed knowledge. In other words, I did everything as though I were completely brand-new to the Raspberry.

Now why would I bother doing that if I'm so confident about the perfection of my script? In fact, not a single person – until you came along – has claimed my script didn't work on a truly clean installation of Raspbian.

I did it because there's always the THEORETICAL possibility that the Raspberry Pi Foundation – at any moment – during one of their frequently-issued system updates – could suddenly change a fundamental system component that inadvertently "breaks" my script. So far, this has never happened – but I obviously have no control over what goes on in Cambridge, England.

Well guess what? I'm pleased to report that my script still works perfectly!

To put it mildly, this raises severe doubts about your claim that you've "run this script on a clean install of the latest version of Raspbian, following the instructions exactly".

I'm even more dubious about your claim because the exact error message you report can indeed be replicated – but only if you don't follow my instructions!

For example, if you change the Raspberry's default video driver to the EXPERIMENTAL OpenGL driver – namely Full KMS – mpv will generate the exact same error message you report! Perhaps you recently installed Raspbian – and only made this one "minor" change – thus in your mind, it remained an entirely "clean" copy that fully complied with my instructions. There's just one problem with that perspective: I explicitly stated in my "requirements" section that those experimental drivers will NOT work! It certainly wouldn't be the first time that someone didn't carefully read my comprehensive instructions.

Am I saying that's what you did? Not at all! I'm not the NSA, so I'm not about to make any specific assumptions about what you may or may not have done. Perhaps you tinkered with your system and made some other fundamental change that triggered the same error message by coincidence. Either way, it's not my concern – because none of these scenarios would involve a truly clean, completely standard copy of Raspbian, now would they?

Oh, and just in case you're thinking about switching your Raspberry back to the standard default "legacy" video driver via sudo raspi-config | Advanced Options | GL Driver, there's a bit of a bug in Raspbian that you should know about. When the experimental drivers are switched on, raspi-config will "secretly" change the /boot/config.txt file back to the 64 MB default setting for the GPU memory allocation without telling you! So if you switch back to the default video driver to try and get things working, be sure to re-do my instructions and move your GPU memory back to 128 MB – because if you don't do that, you'll be treated to a whole new batch of error messages that also have nothing to do with my script!

Better yet, if you're not completely sure what you may or may not have done, just nuke your entire system and start all over again from scratch! Otherwise, you could end up wasting several hours because of some obscurity deep inside your system that you don't understand.

Finally, I can't help but mention a supreme irony about your claim: Thanks to your unique but recycled screen name, it only took me a minute to discover that 8 days ago – on January 5, 2019 UTC – you tweeted a sarcastic message about me that says "this guy really likes the shell script he wrote". The irony is that if only you had followed my instructions to the letter, you would have realized just how good my script really is!

But I get it. Some don't like my confident tone – a tone that's clearly evident in my writing style. It's a tone I'm fully aware of, by the way.

I worked hard to achieve what I've done – the proof is in the pudding. I feel zero shame in defending my high-quality contribution – a contribution I've donated for FREE. In fact, I'm the guy that brought a fully GPU-enabled software suite of the world's leading media engine, top-notch encoders, and a truly modern media player to the Raspberry Pi – and presented the whole thing in a clearly-written manner that almost anyone can follow. No one had done all that until I came along.

Knowing that the Raspberry is now a truly historic machine – the best-selling general-purpose computer in the history of the world – eclipsed only by the Mac and PC – makes my contribution even more significant.

Do I sound a bit boastful in the way I phrase things? I certainly hope so – because it's entirely deliberate. When I put a ton of effort into something I know is significant, I'm not about to sacrifice it at the alter of false "modesty" and let it disappear into the noise.

If anyone looks through this giant thread, they'll see that for more than a year, I've had to fight off multiple bogus claims to defend my work. It's amazing how any random person on the Internet can just come along and say WHATEVER! So if people perceive me as having an aggressive posture, they're not mistaken. What some fail to understand, however, is that it's a special kind of aggression – a justified aggression to stand up for what I know to be true!

wormyrocks
Posts: 2
Joined: Fri Jan 11, 2019 5:48 pm

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

Mon Jan 14, 2019 9:38 pm

Christ dude, get a girlfriend or something

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

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

Mon Jan 14, 2019 10:52 pm

wormyrocks wrote:
Mon Jan 14, 2019 9:38 pm
Christ dude, get a girlfriend or something

LOL

There's one good thing about your incivility:

It demonstrates the emptiness of your claim.

dennissss
Posts: 3
Joined: Thu Jan 17, 2019 10:19 am

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

Thu Jan 17, 2019 10:32 am

Great job Mike.
I just tried to install it on a raspbian light, and it failed on installing libass, but I found only a Pi 2 laying around, so maybe that was the problem.
Will find a 3+ and try again, any pointers would be greatly appreciated.

//Dennis
Copying files to the temporary directory...OK
Stripping ELF binaries and libraries...OK
Compressing man pages...OK
Building file list...OK
Building Debian package...OK
Installing Debian package... FAILED!
*** Failed to install the package

dennissss
Posts: 3
Joined: Thu Jan 17, 2019 10:19 am

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

Thu Jan 17, 2019 11:07 pm

OK, I'm back.
Didn't find a Pi 3, so I tried again with a Pi 2 B
Was a bit more organized this time and I got it running

The Pi is connected with HDMI to a monitor, I run commands via ssh from another computer

After installing raspbian and updating I checked what I got running

[email protected]:~ $ lsb_release -a

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


we need 256 meg for GPU so I added this to /boot/config.txt


##################
## GPU MEMORY
##################
##
## gpu_mem_512
## GPU memory allocation in MB for 512MB board revision.
## This option overrides gpu_mem.
##
gpu_mem_512=256

## gpu_mem_1024
## GPU memory allocation in MB for 1024MB board revision.
## This option overrides gpu_mem.
##
gpu_mem_1024=256


then I created a file for the script and made sure (well sure...) there will be not issues with permissions
(in /home/pi/)

sudo touch vidware
sudo chown pi:pi vidware
sudo chmod 777 vidware


checked the file (in /home/pi)

ls -la
-rwxrwxrwx 1 pi pi 0 Jan 17 11:37 vidware


checked it again after pasting the script in the file (now 24k)

ls -la
-rwxrwxrwx 1 pi pi 24129 Jan 17 11:43 vidware




then I run (inside /home/pi)

sudo bash vidware


waited for +1.5 hours for the script to run. (Pi 2 B, constantly complaining about under-voltage, at least it didn't overheat)

The script did not get the file with the colliding stars downloaded, so I downloaded that manually


[email protected]:~ $ mpv --loop=9 Neutron_Stars_Colliding_1080p.f137.mp4
Playing: Neutron_Stars_Colliding_1080p.f137.mp4
(+) Video --vid=1 (*) (h264 1920x1080 29.970fps)
Using hardware decoding (mmal).
VO: [rpi] 1920x1080 mmal
V: 00:00:42 / 00:00:42 (99%)


That one is working fine, although most other files I tried doesn't want to play for different reasons.
Guessing that there was more than the star movie that didn't really make it to the Pi.
Anyways, it's running smooth and looking good.

Thanks for your superb instructions

//Dennis

dennissss wrote: Great job Mike.
I just tried to install it on a raspbian light, and it failed on installing libass, but I found only a Pi 2 laying around, so maybe that was the problem.
Will find a 3+ and try again, any pointers would be greatly appreciated.

//Dennis
Copying files to the temporary directory...OK
Stripping ELF binaries and libraries...OK
Compressing man pages...OK
Building file list...OK
Building Debian package...OK
Installing Debian package... FAILED!
*** Failed to install the package

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

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

Fri Jan 18, 2019 2:04 am

dennissss wrote:
Thu Jan 17, 2019 10:32 am
I just tried to install it on a raspbian light, and it failed on installing libass

Seriously? You're using the lite version of Raspbian and wondering why it doesn't work?

And then you make a second post with a long list of scary-looking problems and "troubleshooting" steps that have absolutely nothing to do with my tutorial or script?

Please review these highly visible, 100% verbatim quotes from my tutorial:


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

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

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

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

Thu Jan 31, 2019 6:32 am

CYB3RBYTE wrote:
Wed Jan 30, 2019 3:16 pm
So, I installed the entire script and everything ran as it should, including the animation at the end.

HOWEVER, when I go to terminal and type in mpv followed by that web address, it will either tell me the stream is not availible (which is correct at the time of posting), or it will tell me that I need to include the full youtube.dl header or something.

Any thoughts?

NOTE TO ALL READERS: This person is trying to use my GPU-accelerated software suite to watch live video streams from the Monterey Bay Aquarium in California. These live streams are simply embedded YouTube videos. I decided to write an in-depth exploration of this topic because youtube-dl is such a fundamental tool in my offering.

Since you saw the "animation" at the very end of my script's execution – the NASA video of colliding neutron stars – that means everything in my script worked perfectly!

I obviously have no clue what URL you entered immediately after "mpv" in the command line – or how you obtained it – since you didn't disclose any of that information. It's also hard to make much of an "or something" when an error message is being described!

But none of that really matters, since my software suite merely USES youtube-dl – the most robust video downloader on the planet. It's important to realize, however, that my script does not modify youtube-dl or its behavior in any manner whatsoever. As you probably saw, it merely downloads and installs the latest version at the very end of my script. In other words, youtube-dl is the one program that is NOT "built" by my script.

So if you're getting an error related to youtube-dl, there are at least 9 possibilities – all of which have absolutely NOTHING to do with my script or the software it builds on your system! Here they are, in no particular order:

1: The video / live stream is simply down, deleted or has been privatized – either temporarily or permanently.

2: The URL has changed or expired. The most common scenario is that the URL has simply expired. Most "live streams" come to an end after x hours. At that point, if a new live stream is started on the same topic – even if it has the exact same title as the previous live stream – YouTube will assign it a completely NEW and different URL!

3: You accidentally entered a wrong URL or made a typo.

4: Youtube-dl might need an update (although in this case, since you just ran my script a day ago, that's unlikely to be the issue – but it's still theoretically possible, since updates are issued all the time). Websites and video servers constantly change the way they handle video, so the developers of youtube-dl must continuously update their software to keep up with all the changes. In fact, my copy of youtube-dl, which was only 4 weeks old, recently stopped working for ALL YouTube videos. Sure enough, upon updating youtube-dl to the latest version, everything worked perfectly again! To update youtube-dl, simply run the following command line in Terminal. All of this, by the way, is discussed in my extremely thorough Appendix 2:

sudo pip install --upgrade youtube_dl

5: There'something wrong with the latest version of youtube-dl (a possibility I just ruled out through testing).

6: There's something wrong with your "Internet connection". This doesn't necessarily mean there's anything wrong with "your" connection, because I'm using the term in the most sweeping (and meaningful) sense. I'm referring to the entire "connection chain" – from your current location all the way to the very last physical connection to the server. A chain is only as strong as its weakest link – wherever that weak link may be. All of that is completely beyond the control of youtube-dl, but a connection problem will still generate a youtube-dl "error" – even though it has absolutely nothing to do with youtube-dl! It's youtube-dl's way of saying "hey, I can't do this – I'm encountering a connection error!" So just because youtube-dl is throwing an error message does not necessarily mean there's anything wrong with youtube-dl.

7: There's something wrong with the server that hosts the video.

8: There's something wrong or "unorthodox" about the web page or other code on the server.

9: The server's copy of the video file, or its metadata, is damaged.

On top of all that, I just visited the Monterey Bay Aquarium's website and some of their live streams are TOTALLY DOWN at the moment. And by "totally down", I don't just mean there isn't any daylight in California right now – and therefore the camera's been temporarily turned off for the night. I mean that some of them are DOWN – as in "totally down for maintenance". That could last 2 hours, 2 days, or 2 weeks. Who knows! This might change at any moment – but just to prove my point, here's a screenshot from their webcam page. It was working the other day, but it's definitely offline as I write these words:
Live_Stream_Down.jpg
Live_Stream_Down.jpg (185.62 KiB) Viewed 3059 times

In general, before you question any streaming-related software, your best bet is to simply pop the YouTube URL directly into a web browser to see if the video even appears. If it doesn't appear, you can rule out any problem that's specific to the streaming software.

Also, a best practice when attempting to acquire the "real URL" for embedded YouTube videos on a 3rd-party website is to actually click the video in your browser like a normal user would and let it start playing for a few seconds. Then, do this:

1: Mouse over the video and click the right-pointing "share arrow" in the upper-right corner to get the YouTube video's direct link. But the fun doesn't stop there, because that's not really a truly direct link (it's more the product of a "URL shortener" – a kind of alias).


2: When the "share URL" appears in the middle of the video, you need to right-click it and then click "Copy link address". That will put something like this in your clipboard:

https://youtu.be/DruzdeTAPvQ


3: If you then pop that URL into a standard web browser, you'll see it's automatically transformed into something like this (note that the core video "ID" – the 11-character string that says "DruzdeTAPvQ" – never changes in these steps – even though the rest of the URL changes a bit):

https://www.youtube.com/watch?v=DruzdeTAPvQ&feature=youtu.be


4: But the truly "direct" and "totally pure" link is actually this – the same as above, but stripped of the "&feature=youtu.be" at the end:

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


That said, youtube-dl does an outstanding job of "parsing" and making sense of YouTube links in ANY form. Nonetheless, I still wanted to point out how to get the "purest" YouTube URL. At a minimum, it makes youtube-dl's parsing a bit quicker as it prepares the video stream to be handed off to mpv. Although by "quicker", I'm only talking about a second or two.

Keep in mind, however, that you can't just submit a random web page to youtube-dl that happens to contain an embedded video and expect youtube-dl – or mpv, which simply uses youtube-dl – to automatically capture the "hidden" video URL with 100% certainty. That's because website designers sometimes use "unorthodox" code that accidentally or deliberately obfuscates the video URL. Youtube-dl does an outstanding job of automatically parsing a large majority of sites – but if you're having problems, there's nothing like obtaining the "real", direct URL to the video. In the case of deliberate obfuscation, of course, that may not be possible. I explore many of these topics in Appendix 4.

Separately, if you already know the exact title of a video you like – and you know it's on YouTube anyway – you might as well just search for the video directly on YouTube.com and grab the "pure" URL directly from there instead of fiddling with some 3rd-party website – whether it's the Monterey Bay Aquarium or any other site.

My final observation is this: What johndavies mentioned is certainly true. YouTube URLs for "live streams" can change. I pointed this out in item #2 at the top of this post. Here's proof of that. Let's do a search for this exact title (in quotes) – directly on YouTube itself:

"Live Monterey Bay Cam"

You can check it out for yourself right now by clicking this link:

https://www.youtube.com/results?search_query=%22Live+Monterey+Bay+Cam%22

Sure enough, if you scroll through the search results, you'll see there are SEVERAL videos with the EXACT SAME TITLE:

Live Monterey Bay Cam - Monterey Bay Aquarium

But only the top result is actually live – it's explicitly marked by a "LIVE NOW" icon. The other ones are older recordings – and even though they have the exact same title, they also have totally different URLs. So in just a day or two – or even a minute or two – the "live" URL may no longer be the "live" URL! There are tons of reasons why this might happen, but one of the most common would be that the Aquarium is simply taking the camera offline for brief periods of maintenance. Then, when they resume the broadcast, YouTube treats it as a brand-new video and therefore assigns it a new URL.

In my experience, the only time this does NOT happen is when you're dealing with a major broadcaster, like France 24, that has a truly uninterrupted, highly reliable, 24/7/365 broadcast. They may also have a special relationship with YouTube at the corporate level to assure that the video's URL does not change. But even with a live stream like France 24, there's certainly no guarantee that it will remain that way forever. At a minimum, the eventual heat death or total collapse of the entire universe will probably have a little something to say about the stability of the URL!

dennissss
Posts: 3
Joined: Thu Jan 17, 2019 10:19 am

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

Wed Feb 06, 2019 2:16 am

Seriously? You're using the lite version of Raspbian and wondering why it doesn't work?

Well, not really wondering, more informing of status of my trying to get it to work on headless Pi.
Anyways, with a Pi 3 it all worked worked fine.
Thanks for the great and super detailed guide.

(I took the liberty of removing some irrelevant ramblings from the Mad Genius.)

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

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

Wed Feb 06, 2019 11:34 pm

dennissss wrote:
Wed Feb 06, 2019 2:16 am
trying to get it to work on headless Pi..... Thanks for the great and super detailed guide.

I'm glad you liked my "great and super detailed guide".

But yeah, NOT supporting the lite / headless version of Raspbian was a conscious decision on my part – just as I have chosen not to support the Commodore 64 or the BBC Micro.

The overwhelming majority of people that value mpv want a fully "visual experience" that includes not only video, but web surfing and many other GUI-based activities – so it makes absolutely no sense to squander my ongoing development AND support efforts to satisfy a tiny demographic of "command-line nerds".

kharloss
Posts: 1
Joined: Fri Feb 15, 2019 10:26 am

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

Fri Feb 15, 2019 10:33 am

If anyone interested, I updated the script with latest versions of FFMpeg, mpv, x264, aac, waf.

code here.

https://gist.github.com/kharloss/34a745 ... 34a27c255a


PS: All credits goes to RPi_Mike, ofcourse.


PS2: forget about it.
Last edited by kharloss on Tue Feb 19, 2019 7:27 am, edited 1 time in total.

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

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

Fri Feb 15, 2019 11:17 pm

kharloss wrote:
Fri Feb 15, 2019 10:33 am
If anyone interested, I updated the script.....

Ugh!

I'm sure you meant well in trying to update my script to a SLIGHTLY newer maintenance release of mpv.

Unfortunately, you did exactly what I anticipated some people might do – you mainly just did an update of the download URLs to the source code without taking into account that the source code itself has fundamentally changed!

In fact, I can't resist mentioning how prescient I was in anticipating this misguided approach. Here's a direct quote from my script:

Be careful if you think you can simply update these links to get even more recent versions in the future! Other parts of my script make specific assumptions about these particular versions. So unless you fully understand all aspects of my script, you definitely don't want to do that!

Just to prove that you did exactly what I warned about, let's take a brief look at my sed-based text manipulations. For example, my script instructs sed to perform a search and replace on "GLESv2" in line 767 of mpv's wscript file.

Well guess what? In the latest version of mpv's source code, it's no longer line 767. It's now line 772! That means you unwittingly disabled that line in my script.

In fact, you didn't make ANY changes to my sed-based text manipulations. That's a real problem, since I also did an entire patch of mpv's sound-related ALSA handling in the same stanza. But the developers of mpv have since modified their ALSA-related code – a critical change you clearly didn't consider.

So it's obvious you thought to yourself "oh, cool – RPi_Mike did a great job with his script, but I'll make it even better by updating it!"

Believe it or not, there's a saying in America for situations like this: "Don't do me any favors!"

I could go on and on about all the other things you overlooked, but I'm not getting into a discussion about a random Internet user's incomplete understanding of MY script! It's also very unfortunate that bad code is now floating out there on GitHub that alleges to be connected to me in some way. That's just not right.

So let me close with a warning to other readers:

Do NOT use this person's script! It is not correct, nor is it approved by me in any way.

PS: I keep my eye on mpv's GitHub page. At the time of this writing, they have not issued a new update to their source code in over 4 months (version 0.29.1 / October 2, 2018). That's a MINOR maintenance release of the 0.29.0 version that my script builds. It just isn't worth my effort to spend hours and hours of hard work any time a minor tweak is issued. However, when they finally post a fundamentally new version, such as 0.30, I will probably update my entire script. But I will do that in the careful and detailed manner it deserves!

IvanKr
Posts: 1
Joined: Fri Feb 22, 2019 5:51 am

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

Fri Feb 22, 2019 9:18 am

Hello, thank you very much for hard working on script! It’s incredible, that you have made, so big work alone. Could you help me? I would like to make Bluetooth Receiver with AAC. I’m using this tutorial https://gist.github.com/Pindar/e259bec5 ... fbcb11bfc1.
In this tutorial, as I understand, author is building ffmpeg with AAC for libfdk-AAC, but your script already has ffmpeg with AAC and libfdk-AAC. Looking forward for building bluealsa another author is using AAC, that has already need to be in system. So I have two questions, first, do I need to skip building ffmpeg with AAC and second, do I need just enable AAC in bluealsa or I couldn’t us your script like this?

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

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

Wed Feb 27, 2019 4:02 am

IvanKr wrote:
Fri Feb 22, 2019 9:18 am
Hello, thank you very much for hard working on script! It’s incredible, that you have made, so big work alone. Could you help me? I would like to make Bluetooth Receiver with AAC.

There's a great word in the English language. The word is "incidental".

It has a variety of subtle meanings, but definition #2 is the closet to the one I have in mind.

Here's a good example of how I might use the word:

There's a very clever developer in England who figured out how to bring Minecraft to the Raspberry. In fact, his post on Minecraft has nearly 150,000 views. [Note: His screen name is almost identical to mine, but that's a total coincidence; I don't even know the gentleman.]

Anyway, in a separate project of his – without my participation or knowledge – he used my build of mpv to stream a live video feed from his Sony PlayStation Vita directly to his TV! He even put a live demonstration of it on YouTube to show how well everything works. Here's his post on that topic:

https://www.raspberrypi.org/forums/view ... 5#p1403160

In theory, he could have attempted to use VLC or OMXPlayer. But he apparently discovered that my build of mpv provided the best performance.

The moral of the story is that I've never even touched a PS Vita. In fact, I barely know anything about it. Yet he was still able to use my creation for his own purposes!

THAT is what I mean by "incidental". His use of my mpv build was never an intended application, so his use of my build was "incidental". It worked great for him and it became a core part of his solution – but it was still totally "incidental" to my work.

People are welcome to use my GPU-accelerated software suite any way they want – but if they need some kind of technical help or guidance for an incidental application I don't know anything about (or am not interested in), I obviously can't help them!

All I can say about your particular question is that my script builds a 100% "official" and completely "normal" instance of the AAC decoder. It's provided by the source code of FFmpeg itself. Since FFmpeg is the powerful "engine" that mpv uses, my build of mpv will play ANY audio that's compliant with the well-established AAC standard. Simple as that. It will also play tons of other audio standards!

On the encoding side, my script builds the most highly-rated implementation of AAC encoding – Fraunhofer AAC.

[Fraunhofer, by the way, was the dude that discovered mysterious dark lines in the spectra of light from the Sun – as well as some bright stars – all the way back in 1814. He never found out what those weird lines meant (they were atomic absorption lines that reveal what stars are made of) – but several decades later it led to the mind-blowing discovery that those little dot things called "stars" are actually other suns!]

The bottom line is that all the technologies I chose are "best in class" and completely standard.

My build of mpv also works perfectly in playing audio over a Bluetooth speaker (I've tested it myself). It also works great with all standard audio outputs that the Raspberry recognizes, such as the analog jack or HDMI. My personal favorite is a 4th means of audio output – a USB speaker that does all the audio processing on board.

[As a side note, I'm not a big fan of Bluetooth audio on the Raspberry because there are numerous credible reports of the Raspberry's WiFi interfering with the Raspberry's Bluetooth – which is not entirely surprising considering that both wireless signals are handled on the same chip.]

But you're not asking about audio output TO Bluetooth. Instead, you're asking about the complete opposite – you want to turn the Raspberry into a Bluetooth "audio sink". In other words, you want to transform a Raspberry into a Bluetooth receiver – which is basically the electronic "guts" of a Bluetooth speaker. You're talking about Bluetooth INPUT, not OUTPUT.

Is it possible that my build of mpv could somehow act as ONE PIECE of the entire puzzle – just like the Minecraft expert used my build of mpv to interface with his PS Vita? Yes, it might be possible. Or maybe not.

To figure that out, I would have to spend hours or days painstakingly testing a random tutorial you found on the Internet – line by line – until I finally knew how everything fits or doesn't fit together. [And to make things even worse, the tutorial you found is a bit lacking in clarity.]

Whatever the case, one thing is certain – what you're talking about is totally "incidental" to anything I've done.

A cruder way of putting it is simply this: Your question is off topic!

Nonetheless, I wish you well in your project. Perhaps the tutorial's author on GitHub might be of some assistance.

micro8765
Posts: 2
Joined: Mon Mar 04, 2019 12:03 am

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

Mon Mar 04, 2019 12:20 am

Hi Mike

Many thanks for your efforts.

I'm trying to install your system for the first time and not getting past the downloads section. This is on RPi3 with a virign Raspbian install, lsb_release -a shows Release 9.8.

The culprit is waf-2.0.9 - it times out. I found website https://waf.io/ but so far I haven't tracked down a location to get this library.

I'll keep trying but thought I would let you know.

xsmax
Posts: 4
Joined: Mon Mar 04, 2019 1:47 am

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

Mon Mar 04, 2019 1:51 am

Hey Mike, this might be a dumb question but would this allow me to view chromium html5 videos at 1080 full screen. Via HW/GPU mmal acceleration. Im not looking to download the videos or use m3u streams.

Ant advice is appreciated.

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

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

Mon Mar 04, 2019 5:43 am

micro8765 wrote:
Mon Mar 04, 2019 12:20 am
Hi Mike

Many thanks for your efforts.

I'm trying to install your system for the first time and not getting past the downloads section..... The culprit is waf-2.0.9 - it times out.

I appreciate you letting me know about this!

As I pointed out in my tutorial's WARNING #2, my script – like any script that needs to download files – is inherently "vulnerable" and at the mercy of both your Internet connection AND the external servers. So if a server is down – temporarily or otherwise – that will certainly bring things to a screeching halt! For others seeking advise on what to do in that situation, please see my full statement under WARNING #2.

In this case, it appears that freehackers.org – the site which used to host the official copy of the waf meta-build file – is now completely offline. I don't know if that's a temporary situation or what, but I've now found another official URL at waf.io that works perfectly!

[In case anyone is wondering, waf was chosen by the mpv developers (not me) as an essential part of the mpv building process — so it's not an unusual element or idiosyncrasy of my script.]

I have therefore updated the following line in my script FROM THIS:

wget -q --show-progress --no-use-server-timestamps http://www.freehackers.org/~tnagy/release/waf-2.0.9

TO THIS:

wget -q --show-progress --no-use-server-timestamps https://waf.io/waf-2.0.9

BOTTOM LINE: Problem solved!

Thanks again for alerting me to this external server issue.

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

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

Mon Mar 04, 2019 9:41 am

xsmax wrote:
Mon Mar 04, 2019 1:51 am
this might be a dumb question but would this allow me to view chromium html5 videos at 1080 full screen. Via HW/GPU mmal acceleration. Im not looking to download the videos or use m3u streams.

When people talk about HTML5 in the context of video, they're usually referring to an "element" in the web code that simply says to ANY modern browser — Chromium or otherwise — "hey, play this video!" That's all it does. The video itself, however, could be anything from an MP4 to a WebM to an Ogg.

So I don't know what you mean by a "Chromium HTML5 video". Websites provide video — browsers don't provide video! "HTML5 video" is NOT a video format like MP4 or WebM. Heck, it's not even a video! It's just a piece of web code that handles video — it's not the video itself.

But if you're wondering if my software suite can play ALL the video formats I mentioned without "downloading" or "streaming" them, the answer is YES! My build of mpv uses the extremely potent FFmpeg as its "engine", so it can play virtually any video format you throw at it.

However, when it comes to modern video formats, the Raspberry's GPU only supports H.264-based MP4 video. That's a fundamental "limitation" of the Raspberry's hardware, not my script. Fortunately, mpv is so efficient, it typically does a beautiful job at rendering non-MP4 1080p video as well — even though all the heavy lifting is being done by the CPU, not the GPU. This is not really an issue anyway — because I've never come across a major website in the last 5 years that doesn't use MP4 as their primary video format. It's the de facto global standard.

As for identifying the "hidden" video files that are available on a web page — HTML5-related or otherwise — you can simply run this in Terminal:

youtube-dl -F https://www.example.com

I've already written a TON about EVERYTHING your question touches upon — so I recommend that you take advantage of all the hard work and writing I've done throughout this giant thread.

I would especially point you to Appendix 3 — but you really should review everything in my tutorial, including my interaction with all the posts. Otherwise, your understanding of the "big picture" will be incomplete at best.

micro8765
Posts: 2
Joined: Mon Mar 04, 2019 12:03 am

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

Tue Mar 05, 2019 12:17 am

RPi_Mike wrote:
Mon Mar 04, 2019 5:43 am
I have therefore updated the following line in my script FROM THIS:

wget -q --show-progress --no-use-server-timestamps http://www.freehackers.org/~tnagy/release/waf-2.0.9

TO THIS:

wget -q --show-progress --no-use-server-timestamps https://waf.io/waf-2.0.9

BOTTOM LINE: Problem solved!

Thanks again for alerting me to this external server issue.
No thank you!

That fixed it and your script ran absolutely perfectly - well done and as an IT DIYer I appreciate both the commenting and robustness of your script.

I'm also pleased to report that this has resolved an ongoing issue for me with certain audio streams (in my case, SBS Chill in Australia) with various symptoms including unrecognised stream (e.g. 404) / pausing / skipping / terminating. So while I don't really have any current need of the hardware acceleration, the new ffmpeg libraries installed by your script solve some heinous streaming audio issues.

Once again, well done and thanks for sharing with the community.

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

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

Sat Mar 09, 2019 8:10 pm

micro8765 wrote:
Tue Mar 05, 2019 12:17 am
your script ran absolutely perfectly

That's great to hear!

I'm glad I could help.

Fatr3d
Posts: 1
Joined: Wed Mar 20, 2019 3:42 pm

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

Wed Mar 20, 2019 3:57 pm

@RPi_Mike This was the best solution I could find to get MPV playing videos smoothly without any tearing. Thank you

One question I have that may sound dumb, after running the initial compile and getting the deb file output. If I were to take those deb files to another RPi, is there any specific order I should install them in, or will I be safe installing them in any order?

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

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

Sat Mar 23, 2019 12:54 am

Fatr3d wrote:
Wed Mar 20, 2019 3:57 pm
@RPi_Mike This was the best solution I could find to get MPV playing videos smoothly without any tearing. Thank you

One question I have that may sound dumb, after running the initial compile and getting the deb file output. If I were to take those deb files to another RPi, is there any specific order I should install them in, or will I be safe installing them in any order?

The order of installation on another Raspberry does not matter.

The 6 software packages that my script builds – FFmpeg, mpv, x264, Fraunhofer AAC, LAME mp3, and libass – are all installed through this simple command line:

sudo dpkg -i *.deb

Due to the use of the wildcard (*), the typical installation order would be alphanumeric. It simply goes through the directory and starts with any package name beginning with "A", then "B", etc.

However, although the installation order is not important, all of these packages are designed to work TOGETHER. So unless you're looking to do something outside the scope of this tutorial, you'll definitely want to install all of them in one shot.

More importantly, the very fact you're asking this abstract question tells me there's a good chance you didn't bother reading Appendix 8. If you had read that appendix, you would already know that you can't just install the 6 packages on another Raspberry and expect things to work. For example, you also need to install some dependencies from the official Raspbian repository.

It's extremely simple to "prep" another Raspberry for my GPU-accelerated software suite. It only takes a minute. But you still need to do things properly.

For step-by-step installation instructions, please read my carefully-written Appendix 8:

viewtopic.php?f=38&t=199775&p=1360263#p1360263

jonny789
Posts: 51
Joined: Tue May 14, 2013 2:34 pm
Location: Near My Raspberry Pi

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

Sun Mar 24, 2019 2:38 am

Excellent Tutorial .
I have compiled and installed it on my RPI3. I want to compile and install on my RPi Zero W too.
Could you guide me.

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

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

Tue Mar 26, 2019 12:07 am

jonny789 wrote:
Sun Mar 24, 2019 2:38 am
Excellent Tutorial .
I have compiled and installed it on my RPI3. I want to compile and install on my RPi Zero W too.
Could you guide me.

The Pi Zero line of computers was never intended for compiling or using intense multimedia applications like FFmpeg or mpv.

As a result, I have no interest in "supporting" these devices. I don't even own a Pi Zero!

Nonetheless, a previous poster on my thread apparently managed to get things "working" on a Pi Zero by making ONE simple change in 2 different locations of my script. The item that requires a change is the "extra-cflags" option for the CPU. This appears in both the x264 and FFmpeg sections of my script. According to this user, it needs to be changed to the following generic version (in order to support the more primitive CPU in the Pi Zero):

--extra-cflags="-march=armv6zk -mfloat-abi=hard -mfpu=vfp"

Since the Pi Zero has only 1 CPU core and the RPi 3 has 4 CPU cores and a higher clock speed, you might be able to dramatically speed up the compiling by making the small change the poster recommends and then running the modified version of my script with a CLEAN copy of Raspbian Desktop on the RPi 3 (even though the compiled software it generates would be intended for use on the Pi Zero).

The commenter ran the modified version of my script on the Pi Zero itself – but I suspect it can also be run on the RPi 3. By using the RPi 3 as a "cross-compiling machine", you should be able to generate working packages for the Pi Zero more than 5 times faster!

By "clean", I mean that all 6 packages previously created by my script, along with the 3 build-related "Vidware" folders, need to be completely removed from your system. But I would strongly recommend using a totally fresh, brand-new copy of Raspbian Desktop before you proceed with this untested "experiment". The last thing you need when exploring uncharted territory is to have unknown gremlins from the past interfering with your efforts.

Also, keep in mind that compiling a million-line program like FFmpeg is very memory intensive. Since the RPi 3 has twice the memory of the Pi Zero, your chance of success should be much better if you can do all the compiling on the RPi 3.

There is, of course, a remote chance the RPi 3 will not like the generic version of the CPU flag. However, it appears to be a baseline optimizer for the entire ARMv6-compatible line, so it should compile on both CPUs. If you do have trouble on the RPi 3, you'll obviously have to do the compiling on the Pi Zero itself — which could easily take 5 or more hours.

Once the RPi 3 has finished building all the software – assuming everything works – you'll have the 6 ".deb" packages that can then be installed on the Pi Zero by following my instructions in Appendix 8.

GIANT CAUTION: Do I know what the other poster said is actually true? No. Have I tested any of this to confirm it actually works? No. Is it possible that even if this method technically "works", it will produce unsatisfying and inconsistent results? Yes. Is the use of my script on the Pi Zero off topic? Yes.

Also, be aware that mpv requires a GPU memory allocation of 128 MB. Since a Pi Zero only has 512 MB of total system memory (versus 1,024 MB on the RPi 3), that's a very tight squeeze that may cause a variety of issues.

Finally, keep in mind that both the RPi 3 and Pi Zero only provide GPU hardware support for H.264-based video (among modern codecs in common use today). In practical terms, this is almost always an MP4 video – which is not bad, considering that MP4s are the de facto universal standard on the Internet. So the Pi Zero might perform reasonably well with most MP4s. But if you're trying to play a WebM video on a Pi Zero, for example, all the heavy lifting would fall on the single CPU core. That would definitely cause the Pi Zero to choke and drop frames in a wide variety of "CPU only" scenarios. By comparison, the RPi 3 has much greater CPU horsepower — with 3 extra cores to render non-GPU-supported video AND a higher clock speed!
Last edited by RPi_Mike on Tue Mar 26, 2019 1:31 pm, edited 1 time in total.

Return to “Graphics, sound and multimedia”