jock
-
Posts
1860 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
-
Read the first post of the main thread about rk3318, there is an alternative firmware for your wifi you may want to try
-
@Le Best Noob Thanks for the photos. It looks like a quite a standard rk3229 board, in fact looking into the device tree it uses the same led wiring of mxq_rk3229, which is led-conf2; the only thing doubt is that the leds may be switched in polarity: when set to on, they turn off, and viceversa.
-
2 hours ago, hotnikq said:
If you keep USB3.0 on max speed for a time longer the 30 seconds, probably you will experience a data loss somewhere.
Yeah, USB3 is quite sensitive to interferences, and when the board is not designed nor realized with particular care, that's what you get.
rk322x thread is filled with these minor and major issues and when people asks what they can do, the best answer is always "next time buy a properly supported SBC, whose specifications are clear and has been tested for proper support".
I always say that tv boxes are very nice for toying around - I find it very funny to reverse engineer them.
You may even be lucky and get stability for your project, but if you're not a power user with more than average experience and knowledge you will easily have troubles of some sort sooner or later.
-
1 hour ago, Energokom said:
First of all: there is practically no support for TV box as it is. Basically, users themselves share their best practices.
Which is a false statement. You talk that way only because you don't know what is there behind.
I run the rk322x and rk33x8 thing for years and perhaps I'm more informed than you.
Tv boxes have been always a discussion theme in the past with the armbian "management board". People with more experience than me noted, years ago, that they would be way too costly and practically unmaintainable by project members if community would not be involved in their management. That's true: their hardware changes constantly, market names that means nothing, plenty of revisions for the same "board" with different wirings and different hardware parts. You can't set a supporting level when you get a situation like this.
For that reason dedicated forum sections and Community Supported Configuration (CSC) boads were introduced, and support is given by community itself with a "best effort" fashion.
Tv box and alike configurations are always accepted into armbian, but only as CSC boards. Also rk322x family is there only for tvboxes. Wiping out all csc boards and families and forum section and maintainance would be much easier for everyone.
1 hour ago, Energokom said:Secondly, as I said, SBC manufacturers need to adapt to the needs of users and make cheap SBC (example raspberry).
Perhaps it is somehow true, but still is challenging to deal when your opponent "cheats" in every possible way (scrap or defective parts, false advertisement, etc...)
-
4 hours ago, jpegqs said:
Are there legal reasons to request TV box manufacturers to publish the patches they used for Android? Although Chinese companies will likely ignore this, there is no real leverage over them.
Actually I don't know, but I think that tv box manufacturers do little to nothing adjustment on their android images. I think they deal with the software as little as they can do. Despite there are dozen of tv box brands out there, all of them have the same exact software, the only difference is the device tree to adapt little differences of the boards here and there.
Software support costs, and costs a lot, and tv box manufacturers have to keep the price as down as possible.
-
16 hours ago, Energokom said:
But TV box manufacturers don't use armbian, they use android. How do they parasitize?
Perhaps because they benefit of huge software support without giving anything in return?
You can object that that tv box manufacturers never asked for that software support, which is true, but let's imagine tv box community support ceases immediately, how many people would buy tv box crap and how many people would instead buy an SBC to do their experiments, tests and projects?
I puzzled myself dozen of times with that question, and that's the main reason I stay stick with lower end tv box devices only.
15 hours ago, Energokom said:My friend had an SBC orange pi 3, on which the emmc failed after 2.5 years. I have a s905w TV box (the first one I bought instead of SBC), it has been working for a year with armbian on emmc. (This is me to the reliability of emmc on SBC).
Which is not scientifical and statistically significant way to deduce the global quality. Yet you just take a look to some tv box boards to see the poor quality of soldering, the recycle of passive components, the general low quality of the traces (sdio wifi complaints mostly) and the scrap emmc/ddr components, that often fail to reach the rated performances.
And no, not anyone has a soldering station and is capable of swapping a broken emmc with new one, also because the emmc is not the failing part here (I have tv boxes with half-working ddr parts, half working ethernet due to poor chokes, outdated wifi chips, and so on...)
-
I absolutely don't condemn people - that would be a quite dumb position as long as I maintain a couple of tv box ports of discrete appeal - but indeed I condemn the endorsment.
The point I wanted to make clear was not what YOU, as a person, did for armbian: as you say, armbian is an opensource project and free for everyone.
The point is that tv box manufacturers do nothing for armbian. If users don't want or can't contribute it's ok, because donations are volountary. But if manufacturers don't contribute as well, who will? At the end there will just be nothing because non-profit is one thing but charity is another one. Charity is not sustainable in the long run, and not anyone is willing to.
For the same law of conservation of energy you stated, tv box manufacturers takes energy from the system and gives little to nothing back; users perhaps partially mitigate, donating something back to the project, but why actively endorsing entities whose behaviour is neutral at best and parasitic at worst?
-
@Le Best Noob looks like your board is a new one; could you please post a couple of photos of the front and back?
-
8 hours ago, Energokom said:
TV boxes are in high demand than SBC: they are cheaper, already with a case and a power supply, an HDMI cable, and a remote control.
You should not advise to buy shit, they are cheaper because:
* they are made of scrap parts, that often break after very short usage (see the emmc in the rk3318 thread)
* they have no kind of warranty
* the power supply is a joke, made of cheap components and very lousy - switching power supplies are one of the thing the more they weight the better; confront with a quality 5V/2A power supply and see the difference
* the HDMI cable is crap quality, often not capable to transfer CEC or collects any kind of interference at 1080p/4K
* the case is a bit of plastic, with little to no design for heat dissipation - right now I have a rk322x board here withing its case that reaches 97°C while simply installing a package with apt...
* many sorts of limitations to keep them as cheap as possible: no sd card UHS mode, no real shutdown/suspend, USB ports have limited power: be prepared to have headaches if you try to attach something that requires just a tiny bit more power like an external hard drive.
* wifi is a lottery and clearly tells you the general quality: you can find freshly made boards with wifi chips discontinued years ago!
Most of all: they have absolutely no software support; if you are able to run armbian on your tv boxes it is because some people within armbian and other projects spent their time for the fun of making it.
Tv box makers don't care at all, they just need to sell their cheap shit to make some profit. Some (not all) SBC makers at least in some way provide support, but tv box makers are mostly parasitic and should not be endorsed.
Now that you stated that about 20 pcs of different tv boxes run armbian, may I also ask you what you did in change for that for armbian? Because tv box makers obviously did nothing for armbian, still keeping up the servers infrastructure and the general maintenance cost real money to real people, and who pays that?
-
It would be nice to have some instructions for a gstreamer pipeline that works on v4l2request and mainline kernel also. Most probably the pink color problem is an issue from Mesa, but requires some more deep knowledge to pinpoint the problem; having alternatives to mpv (gstreamer, Kodi) to compare is indeed useful to grasp the problem.
-
legacy kernels are discontinued and discouraged to use as long as they are from ages ago
-
30 minutes ago, s-2 said:
I had used 6.1.50 from https://imola.armbian.com/dl/rk322x-box/archive/ (downloaded ~3 weeks ago, but can try 6.1.63 as well).
try 6.1.63; the new ddrbin has been introduced very recently
-
4 hours ago, s-2 said:
Is there any special output to be expected on the serial console to verify maskrom was entered? I only see
Because your board wants ddrbin v1.11 and not v1.10; just use a new multitool and, perhaps, a fresh armbian image from official repositories and not taken here or there on the forums
-
mpv or ffmpeg may show some "failed" messages, but they appear when they probe v4l2 devices for features and codec support; in case the combo does not work, they report an error and pass to probe the next v4l2 device until they find something valid. You can see similar messages in the screenshots of my PR, but then if you get "Using hardware decoding (drm)" you should be ok.
Does the video play with high cpu usage or it does not play at all?
-
I'm not quite sure I understand what you mean, because the only enforced flag is hwdec=drm in mpv.conf.
There are other two flags to tell mpv which plane to use for drawing and which one for video when it is run in virtual terminal (drmprime-overlay interop).
I'm not enforcing vo=gpu, mpv is selecting it by itself. I guess that is the only way to render frames without actively copying buffers around is to render to an EGLImage object and let the gpu do the presentation.
-
There is a suggestion on how to modify /etc/mpv/mpv.conf in a proper way to use autodetection features by mpv that does not require you to specify everything on the command line.
In my experience, mpv 0.35.1 does a pretty good job in guessing what is the right combination if you don't force it. It always worked fine for me in X11, Wayland and virtual terminal
-
18 hours ago, k405 said:
After a complete system update, I ran rk322x-config again and the HDMI and LED stopped working, but that was ok,
Perhaps you did not select led-conf7 again? rk322x-config is supposed to be run once when system is freshly installed and then it should not be anymore necessary.
-
Hello, first of all I would suggest you to avoid DietPI; there have been some circumstances were has been reported that credits were not due to the big work done here by armbian maintainers and taken without proper attribution.
This is sad to say, but until I hear the opposite, I woudl stay away and don't endorse such "distribution".
More about the hardware decoding and rk3318: legacy kernel is now completely deprecated and not suggested to be used at all. It is old and unmaintained code, plus standard linux tools won't work because it contains vendor-specific modules and paths.
You would rather stay stick to a regular armbian image with recent mainline kernel.
You could also advance to edge kernel (at the moment it is 6.6), but it is not necessary.
For the hardware decoding capabilities, I recently made an apt repository for both debian bookworm and ubuntu jammy that may be helpful to you:
That repository provides ffmpeg compiled with the right patches to work with hardware decoding, and the player of choice is mpv which is working pretty fine.
Unfortunately there is a bug for Mali 400/450 in mpv (or mesa) that causes the video to be pink-colored when played in X11 or wayland, but when run from virtual terminal is works fine though.
Also rockchip64 does not have yet the patch to enable hevc, something which I would like to fix soon
-
14 hours ago, timfischbach said:
Short question: Are the HDMI patches integrated into the nightly builds?
Nope
-
34 minutes ago, Carlos Ervedoso said:
Overlays=led-conf7 only Change led. I make more tests
What do you mean, that HDMI does not work yet?
-
-
Hello, for those still interested in hardware video decoding, I made a new thread introducing an APT repository to make installation easier for Armbian Debian Bookworm and Ubuntu Jammy distros:
-
Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs.
The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages.
Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders.
Preconditions:
- Kernel should be 6.1 or more recent
- armhf or arm64 architecture
- Supported operating systems are Debian Bookworm and Ubuntu Jammy
- Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel
APT REPOSITORY SETUP
To install the repository, just copy and paste the lines for your operating system in a terminal
For Debian Bookworm:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list
For Ubuntu Jammy:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list
INSTALL FFMPEG AND MPV PACKAGES
$ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv
SETUP MPV CONFIG FILE
$ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf
You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!
Enjoy!
Notes:
- your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel)
- bug: when rendered in X11/Wayland window, video may show scattered tiles during frames
- bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968)
- Panfrost driver should work flawlessy
- 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that
CSC Armbian for RK3318/RK3328 TV box boards
in Rockchip CPU Boxes
Posted
Mostly trial and error; if the board is well known and someone already discovered it or if you have the original dtb you can look there