jordiblanchcarles wrote: ↑
Thu May 30, 2019 12:16 pm
I've built and installed your mpv on a fresh Raspbian intallation (latest Raspbian image available) and it works perfectly.....
I'm glad we got that on the record — that my GPU-accelerated build of mpv works perfectly!
jordiblanchcarles wrote: ↑
Thu May 30, 2019 12:16 pm
But when the screen is configured in portrait mode (display_hdmi_rotate=1 or display_hdmi_rotate=3 in /boot/config.txt file), then there are some MMAL errors and many dropped frames..... Do you think this problem is something related to your building configuration? Do you have any clues on how to solve this problem?
What you're describing is definitely NOT
related to any "problem" with my build of mpv.
In fact, since you've altered the Raspberry's fundamental
boot settings, you're no longer using a completely "normal", standard copy of Raspbian. Instead — from my perspective — you're using a different operating system that I refer to as Altered Raspbian!
In fact, I previously published a philosophical statement on this very topic that you might like to read. It's marked in red at the bottom of this post:
Since I make very clear in my tutorial that you must have a truly "normal" and standard system, the issue you're describing is therefore off-topic.
But I'll address it anyway:
When you alter the default boot settings like that, you're no longer using a standard 1920 x 1080 display in any practical sense.
Instead, in effect, you're using a completely opposite display — a 1080 x 1920 display! The entire display is being electronically rotated 90 degrees. In fact, this also means that the hardware of your screen must be physically rotated as well!
In plain English, therefore, you're essentially asking me why my GPU-accelerated build of mpv doesn't behave as you want it to when it's forced to perform SIDEWAYS
When it comes to state-of-the-art media players that support the Raspberry's GPU, my only "competitor" is the Raspberry Pi Foundation itself — which released a GPU build of VLC, 11 months after my mpv contribution.
So just out of curiosity, I tested both mpv and VLC in full-screen mode on a 1080p video — on a 1080p monitor with a "sideways" display (otherwise known as "portrait mode"; display_hdmi_rotate=1).
In full-screen mode, VLC treated the screen as if it were 1920 pixels wide. Unfortunately, because the screen is only 1080 pixels wide in a sideways orientation, almost half the video was cut off and completely disappeared past the edge of the screen. So VLC did not properly resize the video to fit the screen. It also dropped a significant number of frames.
In contrast, my build of mpv displayed all of the video correctly in full-screen mode. But exactly as you described, it dropped a significant number of frames.
At the 30,000 foot level, all of this makes perfect sense:
When you're forcing your system to play a high-definition video that's nearly 2,000 pixels wide on a screen that's only about 1,000 pixels wide, you're forcing it to continuously interpolate the entire video and downscale it to a much smaller size to fit on a much smaller piece of real estate.
Crunching more than 62 MILLION
full-color pixels per second — 1920 x 1080 x 30 FPS — is very computationally demanding for a $35 computer!
I noticed, however, that my build handles 480p videos perfectly on a "sideways" screen! In other words, 854 x 480 videos work extremely well when the screen is acting as a "sideways" 1080 x 1920 display.
This is actually a pretty big deal for those interested in using a sideways screen — for one simple reason: If you have access to the same video in 480p, there's no real purpose in using a 1080p video anyway!
That's because the screen is only going to show you less than 1/3 of the pixels anyway — because both the horizontal AND
vertical pixel count are being cut roughly in half! That's just a law of geometry when you rotate a 1080p screen 90 degrees while maintaining the proper 16:9 aspect ratio on a 1080p video — you automatically lose more than 2/3 of all the displayed pixels!
[For those that are curious, the pixel count drops from about 2.1 megapixels to only 657 kilopixels! That means the pixel count is dropping by a gigantic factor of almost 3.2!]
So the bottom line is that a "sideways" display of a 1920 x 1080 video on a 1080 x 1920 screen — in other words, a 1080p display in portrait mode rather than landscape mode — will cause the video to shrink down to only 1080 x 608. So a 1080p video instantly becomes a much smaller "608p" video! And 608p is a fairly minor improvement in resolution over a 480p video — especially in terms of what the human eye can discern. That's why, in a sideways scenario, there's no big advantage to using a 1080p video in the first place!
Even highly-advanced aliens would not be able to get around this basic issue — because it's a fundamental feature of Euclidean geometry! OK, fine — maybe aliens could instantly increase the number of physical
pixels inside the screen whenever you turn it sideways. But no, even that wouldn't apply to what I'm saying — because then it would no longer be a true 1080p display!
At any rate, switching to 480p videos — and using my build of mpv — provides a great solution for a sideways display. Of course, in some cases, you may not have access to the same 1080p video in 480p — and there's absolutely nothing you can do about that (other than re-encoding the original video and resizing it down to 480p. My build of FFmpeg, by the way, is very well-suited to that task).
But in many cases, such as streaming YouTube videos, using 480p content on a sideways screen is a great solution — because most videos on YouTube are also available in 480p! So if you want to change the default streaming configuration for mpv — so that it never streams videos bigger than 480p on your sideways screen — just run this command in Terminal:
And simply change:
So there ya go — I hope this helps. Good luck on your "sideways" experiments!