Raspberry Pi 4: Hardware accelerated video decoding (GPU) in Chromium(lemariva.com)
lemariva.com
Raspberry Pi 4: Hardware accelerated video decoding (GPU) in Chromium
https://lemariva.com/blog/rss/raspberry-pi-4-video-acceleration-decode-chromium
68 comments
It's 2020, the current year, and we're still having ridiculous problems with GPU not being used for decoding video by default. You know, the #1 use case - watching something on youtube or twitch or instagram.
I partly agree with you, but I doubt the #1 use case for someone buying a Raspberry Pi is to sit and watch YouTube or Twitch. People buy Raspberries to experiment with, to have a Linux "server" at home, or to connect it to something, whether it's a web cam or a sensor using the GPIO pins.
I have a bunch of 3s, but I bought a 4 specifically for it's better specs so I'd have a better computer in my garage for looking up schematics/ordering parts/watching youtube how-to videos.
Chiming in as another person using an RPi 4 as a HTPC[1]. It runs YouTube/Netflix swimmingly and connects to a mythbackend server to watch TV and recorded shows. Essentially it's a home theater thin client.
[1] https://www.hackernoon.com/can-a-pi-4-replace-your-home-thea...
[1] https://www.hackernoon.com/can-a-pi-4-replace-your-home-thea...
Will netflix actually let a pi stream at higher resolutions than 480p?
Linux "server"
I am slightly miffed at that. I'm running some docker containers and a Sambashare NAS on a Raspberry Pi, are you claiming what I have is not a server?
I am slightly miffed at that. I'm running some docker containers and a Sambashare NAS on a Raspberry Pi, are you claiming what I have is not a server?
I see your point, but ask yourself this: would you run anything mission critical on a Raspberry Pi? I have had SD card corruption, WiFi chip affecting the GPIO pins, overheating, so yeah, I would personally not.
True, nothing on my Raspberry Pi is mission critical and I do consider the SD card corruption to be a risk and a weak point of the Raspberry Pi.
Does it have ecc and at least n+1 psu redundancy? I think the reason for the air quotes around server is related to hardware and not the software run on it.
I think a better definition of server is something that is always on to provide a service.
If you have ecc or n+1 psu support at home, I ask - do you have cardkey access to your front door? Do you have a fallout shelter and a food stockpile for one year in the basement?
If you have ecc or n+1 psu support at home, I ask - do you have cardkey access to your front door? Do you have a fallout shelter and a food stockpile for one year in the basement?
With how little power RPi needs in comparison to "true server", it could probably run for days or weeks of off a UPS. So it is the more redundant choice!
I believe a pi with kodi is a common use case.
As I cannot trust any multiuser desktop system with sound (it will glitch if I use the computer for much else, I don't care what OS/hardware) I'm mulling a short stack of R.Pi for reliable stream captures. I'm not that voracious but my absolute favorite streams that I really want to time-shift come on at the same time.
Yep. I can watch YouTube no problem on my top of the line 2019 MacBook Pro, presumably it’s hardware accelerated but when I load a Twitch stream it sounds like a jet engine.
This is done to trick people into buying more expensive hardware. I also wonder what motives Google has with disabling GPU acceleration on Linux.
I was pretty active in the Raspberry Pi community around 4 years ago. Playing YouTube easily was a big problem and I tried making a lot of packages to solve this. I would also build Chromium to add widevine support for DRM content.
I also helped the Raspberry Pi Foundation around 4 years ago building and packaging their patched version of Chromium. What they essentially did was directly modify the Chromium source to add HW decoding specifically for the Pi with MMAL. Then, an extension would be auto installed to enable H264 on YouTube instead of VP9. This was released back when they launched the Pixel desktop.
This obviously had some problems, because the patch needed to be manually changed for every release of Chromium, which come pretty often. It couldn't also be easily upstreamed. Looking at it now, it seems it hasn't been updated in about a year, and I'm curious what the Foundation's roadmap for this is in the future, after having been out of the loop for so long.
I also helped the Raspberry Pi Foundation around 4 years ago building and packaging their patched version of Chromium. What they essentially did was directly modify the Chromium source to add HW decoding specifically for the Pi with MMAL. Then, an extension would be auto installed to enable H264 on YouTube instead of VP9. This was released back when they launched the Pixel desktop.
This obviously had some problems, because the patch needed to be manually changed for every release of Chromium, which come pretty often. It couldn't also be easily upstreamed. Looking at it now, it seems it hasn't been updated in about a year, and I'm curious what the Foundation's roadmap for this is in the future, after having been out of the loop for so long.
It also doesn't help that youtube has almost complete dropped h264 these days either, every new video I've seen has been vp9 and av1 only lately.
There must be h264 version available somehow for devices that don't do vp9/avi right?
> youtube has almost complete dropped h264 these days either
Only really true for VOD, and only really true for channels with 300k+ subs.
Only really true for VOD, and only really true for channels with 300k+ subs.
FWIW Rockchip video decode/encode is not in a much better space.
There is the BSP, id est Rockchip's hacked together fork of the 4.4 kernel, which works. But on the mainline kernel h264 is just now getting added (maybe in 5.10), and userspace is still going to take some time to adapt.
I really hope that one day I can actually use the Pinebook Pro webcam for video chats without my CPU spinning while trying to encode (at least) one stream and decode N streams.
There is the BSP, id est Rockchip's hacked together fork of the 4.4 kernel, which works. But on the mainline kernel h264 is just now getting added (maybe in 5.10), and userspace is still going to take some time to adapt.
I really hope that one day I can actually use the Pinebook Pro webcam for video chats without my CPU spinning while trying to encode (at least) one stream and decode N streams.
What about Firefox? Video playback from Youtube on FF is plain terrible; 720p is barely acceptable in full screen for technical videos (forget movies) and 1080p stutters like a kangaroo with parkinson. The same videos play perfectly under LibreElec/Kodi, but due to recent crazy restriction by Google, one is forced to sign up with them to watch videos on YT Kodi addons, while browsers are still ok (for now).
Also, Firefox (which I refuse to swap with anything) crashes like 1 in 3 times when I fast forward or backward the video. I keep the crash reporting on so FF devs are likely inundated by reports about the problem, which happens on a stock RPi4 with stock Raspbian and stock Firefox. All constantly updated.
I haven't tried it on a pi,but mpv (having youtube-dl installed) is my to-go tool for watching youtube videos, since google wants me to sign in or accept its tracking to see them otherwise.
I haven't tried it on a pi, you might have to specify --hwdec or some variation of it to have really smooth playback, otherwise it's as simple as `mpv "url"`.
I haven't tried it on a pi, you might have to specify --hwdec or some variation of it to have really smooth playback, otherwise it's as simple as `mpv "url"`.
Thanks, I'm currently testing Minitube (https://flavio.tordini.org/minitube/) which uses the MPV library and seems not to have some problems experienced with MPV (permissions, unrecognized format, etc). Still have to test it on the RPi though, so I have no idea how fast will do compared to the browser, but at least the crash problems would be solved. I'm afraid it won't last long, however: Google is locking access to more and more resources behind signup walls, which is a turn off for many people, including myself. Hopefully content creators will move elsewhere.
You can also open Youtube URLs in VLC. Haven't tested the performance on a pi though.
I was surprised at how much better (more fluid, less stuttering, fewer artifacts) mpv was compared to VLC with hardware rendering enabled on Linux.
firefox 80 shipped late August & is the first with Linux gpu support under x. wayland was already supported, it seems, since 75.
81 is three weeks old & is the first release that will have Linux video gpu support enabled by default. source: https://9to5linux.com/firefox-81-enters-beta-gpu-acceleratio...
note that this is firefox at large. no idea whether the pi supports the standard va-api acceleration interface or what other potential blockers the pi has.
81 is three weeks old & is the first release that will have Linux video gpu support enabled by default. source: https://9to5linux.com/firefox-81-enters-beta-gpu-acceleratio...
note that this is firefox at large. no idea whether the pi supports the standard va-api acceleration interface or what other potential blockers the pi has.
It just has libva support for video decoding acceleration.
Whether that translates to actual video decoding acceleration on any platform depends on availability of libva backends. And performance (or power consumption) may still suck, if you can't use the frame buffers directly for output to some HW overlay.
Linux kernel APIs are fairly straightforward, and easy to use, if you use them directly from some simple app. But making it work across all the abstractions from browser, to compositor, to display server, via ffmpeg, via libva, etc. is not easy at all.
Whether that translates to actual video decoding acceleration on any platform depends on availability of libva backends. And performance (or power consumption) may still suck, if you can't use the frame buffers directly for output to some HW overlay.
Linux kernel APIs are fairly straightforward, and easy to use, if you use them directly from some simple app. But making it work across all the abstractions from browser, to compositor, to display server, via ffmpeg, via libva, etc. is not easy at all.
Thanks for this comment.
Question-- how exactly does one check that gpu-acceleration is on in FF? I'm running nightly on a NUC with Intel Iris GPU and it seems to be faster than LTS from Debian Bullseye, but I'd like to be sure...
Question-- how exactly does one check that gpu-acceleration is on in FF? I'm running nightly on a NUC with Intel Iris GPU and it seems to be faster than LTS from Debian Bullseye, but I'd like to be sure...
Try running `firefox MOZ_LOG=PlatformDecoderModule:5`, navigating to a video and checking that the decode is being done though VA-API. Depending on your GPU, you might have to use something like enhanced-264ify to force Youtube to use formats that are supported by hardware decode.
More info here:
https://wiki.archlinux.org/index.php/firefox#Hardware_video_...
More info here:
https://wiki.archlinux.org/index.php/firefox#Hardware_video_...
Thanks for the tip. I think you meant `MOZ_LOG=PlatformDecoderModule:5 firefox`. When I run that with Firefox 81.0 I get this when I open Youtube:
[Child 78229: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform [Child 78229: Main Thread]: D/PlatformDecoderModule Sandbox decoder rejects requested type
Same in Nightly 82.0b9.
This is on a Dell XPS 13 amd64 with Mesa Intel® UHD Graphics (ICL GT1) running Ubuntu running Wayland.
I haven't tested my RPI4 yet. But if Intel graphics aren't a "supported platform," it's difficult to imagine any graphics under Linux that would be.
Didn't test trying to force-enable because we're talking about supported platforms.
[Child 78229: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform [Child 78229: Main Thread]: D/PlatformDecoderModule Sandbox decoder rejects requested type
Same in Nightly 82.0b9.
This is on a Dell XPS 13 amd64 with Mesa Intel® UHD Graphics (ICL GT1) running Ubuntu running Wayland.
I haven't tested my RPI4 yet. But if Intel graphics aren't a "supported platform," it's difficult to imagine any graphics under Linux that would be.
Didn't test trying to force-enable because we're talking about supported platforms.
Last week, I tried this on an AMD 3400g (Vega 11 amdgpu) with that specific environment variable and my results were:
- vainfo told me it (VA-API) can decode vp9 and h264 among others
- mpv plays vp9 and h264 using vaapi
- firefox log mentions using VA-API in h264 playback but in vp9 nothing related is printed
Maybe firefox whitelisted only h264 for hw decode?
Maybe firefox whitelisted only h264 for hw decode?
How about VLC?
Anybody have any idea why this isn't enabled out o the box?
I imagine screen tearing, especially under the default compositing window manager, would be unacceptable for the out-of-the-box configuration.
Another possibility is just that nobody has gotten to it yet.
Another possibility is just that nobody has gotten to it yet.
The answer is probably that Broadcom's documentation is dogshit and this required a herculean effort to reverse engineer to get everything working.
That's something I've wondered for a long time: Doesn't Broadcom want users to be able to use the full feature range of it's silicon?
Broadcom doesn't sell its processors to end users.
Good point.
I assumed Broadcom would be happy to have a platform as popular as the Pi using it's SoC. There must be a lot of companies out there prototyping on the Pi (because it's probably one of the easiest dev-board to get started on).
I assumed Broadcom would be happy to have a platform as popular as the Pi using it's SoC. There must be a lot of companies out there prototyping on the Pi (because it's probably one of the easiest dev-board to get started on).
You misunderstand the point of a company like broadcom.
The Pi is a rounding error money wise.
The Pi is a rounding error money wise.
Can you go into a bit more detail on this?
I mean, I get that they supply parts for specialized devices, but why would a company pass up on the opportunity to reap as much goodwill and brand recognition as the position of "the people that made the Raspberry Pi economical" could engender? I mean think about it for a minute. This is this generations 486 or Commodore or VIC-20.
I scratch my head at trying to imagine the thought process of those in management to completely throw away this opportunity unless they really have something big to hide.
I mean, I get that they supply parts for specialized devices, but why would a company pass up on the opportunity to reap as much goodwill and brand recognition as the position of "the people that made the Raspberry Pi economical" could engender? I mean think about it for a minute. This is this generations 486 or Commodore or VIC-20.
I scratch my head at trying to imagine the thought process of those in management to completely throw away this opportunity unless they really have something big to hide.
I think one aspect of the discussion is that the Raspberry Pi does not represent a sample of the engineering that Broadcom customers work with.
It's way too high level. Broadcom would be glad to sponsor something like Verilog/VLSI engineering tools. Maybe like an FPGA board that implements certain Broadcom proprietary instruction sets and lets people use that as an onboarding ramp to get them inducted in a "first hit's free" kinda way.
Broadcom customers buy chips in order to build other electronic products. Not to learn or program python or even C/C++. The original intent of the Rpi as an embedded controller is closer to what Broadcom wanted to do, and likely was how RPi talked them into agreeing with the whole thing in the first place.
That market position has been taken over by the arduino family though, so the positioning of Rpi within the Broadcom general strategy isn't well matched.
It's way too high level. Broadcom would be glad to sponsor something like Verilog/VLSI engineering tools. Maybe like an FPGA board that implements certain Broadcom proprietary instruction sets and lets people use that as an onboarding ramp to get them inducted in a "first hit's free" kinda way.
Broadcom customers buy chips in order to build other electronic products. Not to learn or program python or even C/C++. The original intent of the Rpi as an embedded controller is closer to what Broadcom wanted to do, and likely was how RPi talked them into agreeing with the whole thing in the first place.
That market position has been taken over by the arduino family though, so the positioning of Rpi within the Broadcom general strategy isn't well matched.
It’s because it’s not an opportunity. When you are going after selling millions or tens of millions of units every year in cell phones, these chips at this point are old for them. A lot of tech in this chip was probably in a cell phone 5-7 years ago. So they’ve made their profits from it. Having it out in a few hundred thousand RPis won’t make much of a difference at this point.
> Having it out in a few hundred thousand RPis won’t make much of a difference at this point.
Many millions of Raspberry Pis are sold in a year. They aren't Broadcom's highest priority but the foundation is a legitimate customer now.
Many millions of Raspberry Pis are sold in a year. They aren't Broadcom's highest priority but the foundation is a legitimate customer now.
That said, it is a good way to clear out their warehouse inventory I guess.
Lets say that they start playing nice and fully support the rpi project. How would you as a consumer show your increased support for broadcom? Go out and buy a bunch of products that contain specifically broadcom chips? A bulk order of modems off Digikey?
I think one should feel compelled to go picket competing silicon vendors. I'm not really sure how/where that is even possible.
most companies are only interested in selling chips to companies with teams & teams of engineers willing to sign nda's & slave away until some final appliance thing is shipped. really sad state of affairs across a wide range of the industry.
Of course not.
The Pi itself was a herculean feat just to get broadcom stop suing consumers for using the chips as an individual consumer.
Broadcom itself is about as anti-user as they come.
What they really want to do is to sell you the features - you want decoding that's already on the chip? Sign NDA and pay them a few million dollars for each seat / license and they'll let you use it.
The Pi itself was a herculean feat just to get broadcom stop suing consumers for using the chips as an individual consumer.
Broadcom itself is about as anti-user as they come.
What they really want to do is to sell you the features - you want decoding that's already on the chip? Sign NDA and pay them a few million dollars for each seat / license and they'll let you use it.
Poor documentation can be as much an asset as a liability, depending on your perspective.
- The more comprehensive your documentation, the easier it is for your competition to get a complete read on your product and it's capabilities. Which makes it both easier for competitors to strategically outcompete you, as well as counterfeiters to more accurately counterfeit your chips.
- The more precise your documentation, the more stringent your customer's expectations become. Poor documentation can act as a form of liability insurance - if someone uses a feature and things get weird, you can claim their use is out of spec. Harder to weasel out if things are clearly documented.
- The more expansive your documentation, the less dependent your (potential) customers will be on actually talking to you when evaluating if your product is fit for their use. I could see this being a negative in this industry - Feature X may be fine to use, but introduce intermittent instability if used for extended periods of time simultaneously with Feature Y, which can be compensated for via Z but doing so shortens expected lifespan by 30%. Wargaming out every possible contingency ahead of time would both be extraordinarily expensive, and result in documentation that would overwhelm the people using it. But not doing so while providing otherwise expansive/comprehensive documentation may lead to a false sense of understanding from your customers such that they write you off when your product would have in fact been a good fit.
- A corollary to the above - poor documentation trains your (potential) customers to just reach out directly and have a conversation about it. Which provides the chance for you to truly evaluate their situation and provide a more considered response that takes into account their use/circumstances. Which can either be using the product they may be familiar with, or suggesting a different one that's more appropriate that they may not have thought of.
- Ditto the above for implementation. Directly supporting them during their implementation can be more effective than them relying on generic documentation, since you can provide more contextually relevant details/instructions/direction. Which cycles back to the second bullet above, where you have the opportunity to provide information that steers customers in the right direction, addressing potential issues preventatively rather than playing damage control if their use wasn't completely aligned with the documentation they blindly followed. You can also directly put the costs of this work against the customer, rather than eating it via the comprehensive wargaming scenarios mentioned above. Which sounds harsh, but is far more efficient for everyone involved. Customers with a cookie cutter use case get cheaper per unit prices since you didn't inflate the amount of QC and experimentation required to flesh out the documentation, and you didn't waste time and resources chasing down contingencies that were never actually applicable to any of your customers.
So it sucks for a subset of people - hobbyists who aren't direct customers in the first place, cash strapped hardware shops who can't pay for that support, and the engineers at BigCos who aren't willing to pay for that support. But can still be rationalized when you consider it's an absolute non-issue for their primary target market, while also indirectly benefiting everyone else via the lower unit costs afforded by this mentality/approach.
- The more comprehensive your documentation, the easier it is for your competition to get a complete read on your product and it's capabilities. Which makes it both easier for competitors to strategically outcompete you, as well as counterfeiters to more accurately counterfeit your chips.
- The more precise your documentation, the more stringent your customer's expectations become. Poor documentation can act as a form of liability insurance - if someone uses a feature and things get weird, you can claim their use is out of spec. Harder to weasel out if things are clearly documented.
- The more expansive your documentation, the less dependent your (potential) customers will be on actually talking to you when evaluating if your product is fit for their use. I could see this being a negative in this industry - Feature X may be fine to use, but introduce intermittent instability if used for extended periods of time simultaneously with Feature Y, which can be compensated for via Z but doing so shortens expected lifespan by 30%. Wargaming out every possible contingency ahead of time would both be extraordinarily expensive, and result in documentation that would overwhelm the people using it. But not doing so while providing otherwise expansive/comprehensive documentation may lead to a false sense of understanding from your customers such that they write you off when your product would have in fact been a good fit.
- A corollary to the above - poor documentation trains your (potential) customers to just reach out directly and have a conversation about it. Which provides the chance for you to truly evaluate their situation and provide a more considered response that takes into account their use/circumstances. Which can either be using the product they may be familiar with, or suggesting a different one that's more appropriate that they may not have thought of.
- Ditto the above for implementation. Directly supporting them during their implementation can be more effective than them relying on generic documentation, since you can provide more contextually relevant details/instructions/direction. Which cycles back to the second bullet above, where you have the opportunity to provide information that steers customers in the right direction, addressing potential issues preventatively rather than playing damage control if their use wasn't completely aligned with the documentation they blindly followed. You can also directly put the costs of this work against the customer, rather than eating it via the comprehensive wargaming scenarios mentioned above. Which sounds harsh, but is far more efficient for everyone involved. Customers with a cookie cutter use case get cheaper per unit prices since you didn't inflate the amount of QC and experimentation required to flesh out the documentation, and you didn't waste time and resources chasing down contingencies that were never actually applicable to any of your customers.
So it sucks for a subset of people - hobbyists who aren't direct customers in the first place, cash strapped hardware shops who can't pay for that support, and the engineers at BigCos who aren't willing to pay for that support. But can still be rationalized when you consider it's an absolute non-issue for their primary target market, while also indirectly benefiting everyone else via the lower unit costs afforded by this mentality/approach.
As someone who currently dabbles in pcb design as a hobbyist, oh yes indeed. It sucks so much - every tiny little thing has extensive datasheets: from extremely detailed specs over test and application circuit examples that actually work to bitfield docs for i2c registers.
But the more intelligence a Thing has, the inversely worse the situation becomes: good luck finding, for example, datasheets for a USB controller for Intel HDA codecs (if anyone has a hint on these, email is in profile)... and it's outright impossible to find anything for more complex stuff like Thunderbolt controllers, much less CPU / GPU / SoC chips. The closest a hobbyist comes across to real performance beyond RPi is COMexpress, which is not an as open standard as many would like plus the connectors cost a fortune...
And to top it off: even for components that have datasheets... these lack licensing information, which means it's technically illegal to put a pcb design based on them as open source.
Seriously I'd appreciate it if our governments could do something about that situation. The creativity decent rules about datasheets could unleash...
But the more intelligence a Thing has, the inversely worse the situation becomes: good luck finding, for example, datasheets for a USB controller for Intel HDA codecs (if anyone has a hint on these, email is in profile)... and it's outright impossible to find anything for more complex stuff like Thunderbolt controllers, much less CPU / GPU / SoC chips. The closest a hobbyist comes across to real performance beyond RPi is COMexpress, which is not an as open standard as many would like plus the connectors cost a fortune...
And to top it off: even for components that have datasheets... these lack licensing information, which means it's technically illegal to put a pcb design based on them as open source.
Seriously I'd appreciate it if our governments could do something about that situation. The creativity decent rules about datasheets could unleash...
>while also indirectly benefiting everyone else via the lower unit costs afforded by this mentality/approach
Except everything you mentioned above prevents new competition from ever getting a foothold to drive down prices. Everything you just described is. only good if your end goal is to be an immortal, indispensable fixture of the economy, and I'd even go so far as to say the practices you endorse as strategically sound are (or should be) explicitly considered examples of strategies which are anti-competitive, anti-consumer, and should entail strict liability with a punitive consequence for the company involved if they utilize those practices for the reasons you state as a cost for and any tragedy results from the opaque nature of their dealings with the public. Nothing short of undesirable results and wasted effort is inflicted on the rest of society; which at the end of the day is mired in the quest to efficiently allocate resources, and further the State of the Art and the frontiers of human knowledge.
You'll get the same exact things you counted as benefits for doing things badly simply by being proactive in communication with clients. and reaping the fruits of consumer and investor goodwill. You'll discover new edge cases and directions for truly novel developments when your customer tries to use your thing and, darn it, I need something just like it but with X. Hardware can be far better characterized, and the ability of the public to identify "the right tool for the right job" greatly increased. With more goodwill comes greater leniency, more willingness to allocate capital for novel problems, and a much more accommodating environment when it comes to risk.
It's the difference between being a long living parasite, and becoming a household name. A vampire may live forever, but eventually somebody is getting a Stake and some garlic. Start acting like you've got something to hide, and people will go out of their way to do away with you. Free everybody from being helpless to help themselves though? That gets songs, monuments, and a chapter in the history books about how awesome and pivotal you were.
Goddamnit, don't you want to live forever?
Except everything you mentioned above prevents new competition from ever getting a foothold to drive down prices. Everything you just described is. only good if your end goal is to be an immortal, indispensable fixture of the economy, and I'd even go so far as to say the practices you endorse as strategically sound are (or should be) explicitly considered examples of strategies which are anti-competitive, anti-consumer, and should entail strict liability with a punitive consequence for the company involved if they utilize those practices for the reasons you state as a cost for and any tragedy results from the opaque nature of their dealings with the public. Nothing short of undesirable results and wasted effort is inflicted on the rest of society; which at the end of the day is mired in the quest to efficiently allocate resources, and further the State of the Art and the frontiers of human knowledge.
You'll get the same exact things you counted as benefits for doing things badly simply by being proactive in communication with clients. and reaping the fruits of consumer and investor goodwill. You'll discover new edge cases and directions for truly novel developments when your customer tries to use your thing and, darn it, I need something just like it but with X. Hardware can be far better characterized, and the ability of the public to identify "the right tool for the right job" greatly increased. With more goodwill comes greater leniency, more willingness to allocate capital for novel problems, and a much more accommodating environment when it comes to risk.
It's the difference between being a long living parasite, and becoming a household name. A vampire may live forever, but eventually somebody is getting a Stake and some garlic. Start acting like you've got something to hide, and people will go out of their way to do away with you. Free everybody from being helpless to help themselves though? That gets songs, monuments, and a chapter in the history books about how awesome and pivotal you were.
Goddamnit, don't you want to live forever?
chromium has been resistant to enabling Linux acceleration until very recently.
https://bugs.chromium.org/p/chromium/issues/detail?id=463440
from the article, this seems to require setting up an advanced video card config on the pi side & allocating 128mb ram. that used to be a significant portion of ram. rpi3 came with 1gb.
https://bugs.chromium.org/p/chromium/issues/detail?id=463440
from the article, this seems to require setting up an advanced video card config on the pi side & allocating 128mb ram. that used to be a significant portion of ram. rpi3 came with 1gb.
I just got an rpi4 and it's cool to see what it's about. Probably going to use it as a media center for the tv, and for games (anyone got tips for good games that play with a controller?)
> anyone got tips for good games that play with a controller?
RetroPi + anything from 2D Nintendo consoles, I'm personally a fan of the GBA metroid games. Some other good ones are Fire Emblem, A Link to the Past, Final Fantasy, Mario (1/2/3/World). If you email me, I can help with sourcing ROM's.
As for more modern games, Hollow Knight is a masterpiece. A SNES controller has _almost_ enough buttons, but I had to remap one control to the spacebar.
RetroPi + anything from 2D Nintendo consoles, I'm personally a fan of the GBA metroid games. Some other good ones are Fire Emblem, A Link to the Past, Final Fantasy, Mario (1/2/3/World). If you email me, I can help with sourcing ROM's.
As for more modern games, Hollow Knight is a masterpiece. A SNES controller has _almost_ enough buttons, but I had to remap one control to the spacebar.
If you're into retro/lofi/handmade games, PICO-8 on Raspberry Pi might be fun:
https://www.lexaloffle.com/pico-8.php
https://www.lexaloffle.com/pico-8.php
Thanks a lot for the tip, will check it out!
This got me curious about how using xcompmgr causes flickering. My intuition would tell me the opposite would be true.
The core X protocol doesn't have any actual coordination of frames becoming ready to display. There's isn't even a concept of a frame or page at all.
There was an extension added in an attempt to fix this situation, IIRC it's the xdbe extension, but I don't believe it gained much traction.
If you look at the implementation of xcompmgr and the extensions introduced to make compositing possible, namely Composite and DAMAGE, they too don't have any frame-oriented coordination.
So it's just more racy uncoordinated capacitance in the immediate mode rendering pipeline of X. Your X requests logically just throw things on the screen as they occur. There may or may not be a compositor in the middle of that. When the compositor is scheduled and how much of your X requests sitting in the queue become processed as part of the same timeslice is fairly non-deterministic. There's unpredictable scheduling occurring at the kernel level, the compositor process's event handling, and the X display server's client multiplexing level.
There are some good reasons for a replacement like wayland, this area is definitely one of them.
There was an extension added in an attempt to fix this situation, IIRC it's the xdbe extension, but I don't believe it gained much traction.
If you look at the implementation of xcompmgr and the extensions introduced to make compositing possible, namely Composite and DAMAGE, they too don't have any frame-oriented coordination.
So it's just more racy uncoordinated capacitance in the immediate mode rendering pipeline of X. Your X requests logically just throw things on the screen as they occur. There may or may not be a compositor in the middle of that. When the compositor is scheduled and how much of your X requests sitting in the queue become processed as part of the same timeslice is fairly non-deterministic. There's unpredictable scheduling occurring at the kernel level, the compositor process's event handling, and the X display server's client multiplexing level.
There are some good reasons for a replacement like wayland, this area is definitely one of them.
Got it, so there’s no X client request along the lines of “the frame is fully drawn.” I assumed there was and that the compositor would take advantage of that, doing all the double buffering itself.
Do we know what codecs have hardware acceleration support? I know the author mentioned h264
The rpi4 has hardware blocks for h.264, hevc, and vp9 IIRC.
Ah! So this explains why trying to use a Raspberry Pi 3 to stream a live webcam feed over the network was so slow for me, it was all using software encoding.
Raspberry Pi 3 also has OpenMX Hardware Encoder/Decoder. It should be able to do H264 720p at reasonable speed. If you're using ffmpeg just make sure to use h264_omx instead of libx264 (needs to be on Raspbian, though, since it requires libomx_core.so blob and enabled via a flag).
I ran a 24x7 live stream at 720p on a pi3, that I also downsampled to 360 and 240 concurrently with hardware via ffmpeg compiled with omx support via nginx-rtmp to HLS. The origin stream was from a hardware HDMI capture out of the pi that I split into the display and there was usually a webcam on in the corner of the screen. The 3 streams whizzed along at 1.0x all day.
My family and I have watched hundreds of hours of h.264 1080p on a pi 3b+, but it struggles with HEVC h.265 and runs very hot doing so.
looking forward to vulkan support on the pi4