Victor B.
-
Posts
7 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Victor B.
-
-
Wanted to extend another gesture of support for taking a break. Hopefully the market will be more flexible to enable you guys to push a new product in the coming months.
-
Mighty impressive! Looking forward to the mainline release
-
A small update if you're willing to use a legacy kernel:
I have not tested it yet...
-
5 hours ago, Werner said:
Actually it is not about hardware acceleration in docker. It is more about hardware acceleration at all that needs to be verified if it works
It seems V4L2_M2M acceleration (h264 encode support) is our best option for ffmpeg, however, I have not made much progress beyond learning as I go. If you make progress that'd be great to know.
-
Hello,
I am quite new to this topic, and I have found it to be quite complex. I primarily work with tiny MCUs and RTOSes, but I am enjoying the Linux space so far.In essence I would like to use the Mali GPU that is embedded within the RK3399 of the Helios64 for hardware transcoding. This isn't a novel idea, as shown by these sources:
https://forum.armbian.com/topic/9272-development-rk3399-media-script/
https://emby.media/community/index.php?/topic/66675-36078-transcoding-rockpro64/
I am using Jellying, and in so FFMPEG to decode/encode the data streams. It seems that V4L2 is supported for hardware ecoding/decoding in the FFMPEG package, but in my experience doesn't appropriately work with the Mesa Panfrost drivers (https://wiki.debian.org/PanfrostLima) and the ARM drivers fail to compile with the kernel headers provided by the armbian-config script. I like the idea of having hardware accelerated transcoding, and I'm not even interested in 4K content, but my helios64 fails to transcode h265 (HEVC) to h264 at a playable rate. Secondly I like to have watch-togethers with my friends and I have to use my power-hungry PC for this. Of course I can introduce new hardware to do this like an arm64 laptop, but I like the all-in-one solution, and I simply can't be the only one that feels this way.
Has anyone had success with hardware acceleration? Any ROE or ongoing efforts?
Thanks,Victor
-
On 10/26/2020 at 10:35 PM, gprovost said:
You right. No excuse on our side, we are behind schedule and not up to expectation on the software maturity, maybe we should have stick LK4.4 (from rockchip) and forget about Linux mainline for now :-/
However we are still working at improving the stability and we are optimistic that very soon, it will get better.
Right now as you know LK5.8.16 is for some reason (we still can't figure out) unstable vs 5.8.14
We also realized that OMV install was removing some tx offloading tweak. So a lot of little things here and there that we only discover along the way.
BTW regarding this crash are you sure tx offload on eth1 was disable ?
I respect your transparency and your vision, do you have a GitHub where I can contribute?
Upgrading to Bullseye (troubleshooting Armbian 21.08.1)
in Rockchip
Posted
I upgraded with no problems. Honestly happy to see the stuff with Mesa moving along - you have a desktop with OpenGL acceleration out of the box. Thinking of trying some Retro gaming on it out of curiosity. Still looking out for transcoding or even just decoding.