• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by JMCC

  1. Then everything is fine. 32 bit (streaming version) is not working well, it is just an experiment. That's why it is disabled by default.
  2. Just try with the default options: click "Accept", "Yes" or "OK" every time, and let it run.
  3. It should work on a fresh Default image (4.4 kernel), just with default options selected. I haven't tested it in a while, let's see if I can find some time and check whether recent updates broke the script.
  4. Correct me if I'm wrong, but I understand that the new V4L2 driver only supports HW decoding, not encoding, right? In that case, IMO the usefulness of an standalone FFmpeg is very limited. What I mean is that you won't get a noticeable benefit in transcoding with FFmpeg if you only accelerate the decoding. Not to mention possible colorspace conversion limitations etc (I think I bumped into some of those with the "old" RKMPP FFmpeg implementation). On the other hand, I see the real usefulness of that when FFmpeg is used as part of media players such as MPV or Kodi. And, in those cases, I always found it easier and more efficient to compile its own version of FFmpeg with the app, than link it against the system libs. So my opinion is that it is better to leave alone the system FFmpeg debs, and compile the new version on a separate directory; that way it will not break other FFmpeg-dependent apps, such as video editors etc.. And let the media players use their own FFmpeg (after all that is what they normally recommend in their compilation instructions), and apply the patch there when necessary.
  5. The following deb package should work for Armbian Bionic arm64 (RK3328/RK3399):!Aj0xDhqxX_nqoygqTuH8eoKnP3in
  6. In that case, mpv builds with V4L2 support by default. Just run on the TinkerBoard: $ sudo apt remove mpv $ git clone $ cd mpv-build $ ./rebuild -j4 $ sudo ./install This will install mpv in your local machine. If you also want to build a debian package, you can do the following additional steps: $ sudo apt-get install devscripts equivs fakeroot $ mk-build-deps -s sudo -i $ dpkg-buildpackage -uc -us -b -rfakeroot -j4 The resulting mpv package can later be installed on any machine running the same distro and architecture. In order to run mpv using the v4l2 support, this is the command line that I use: mpv -hwdec <filename>
  7. Does it need to have also RKMPP support, or just V4L2 is enough for the new driver?
  8. BTW, seems like the Lima driver has been accepted for 5.2. Looking forward to seeing it released
  9. But, just for the records, provided that you have root access, you can hard reboot a board running Armbian by issuing echo b > /proc/sysrq-trigger
  10. If you overwrote your SD card by mistake, the only solution is to power off the system and re-flash it. You will need physical access to the board for that, of course.
  11. It's probably a matter of updating Armbian's kernel config to reflect ayufan's changes. I cannot test with Rock64 since I don't have one, just a Renegade.
  12. You'll need the script to run the game. Just install it making sure that the development libraries are not marked for installation, that should avoid the conflict with mesa-common-dev
  13. The output now shows that gl4es wrapper and mali drivers are being used. Now, since it is just a wrapper, it's possible that some functions are not implemented, or do not exist at all in the GLES 2 API. Another option to play that game could be using this fork for GLES:
  14. Yes, it seems like it is working. Can you re-run the script, selecting only gl4es, and post the install.log
  15. When does that happen, when using GLES or GBM as display driver? (that is, the "regular" mpv launcher or "mpv-gbm")
  16. This means it is not using the GL4ES wrapper, but the Mesa software emulation. First of all, check that OpenGL-ES is working, by running "glmark2-es2" or "es2gears". You should get a message saying it is using the Mali driver, and not the VMware emulation.
  17. As a matter of fact, OpenGL 1.3 can be emulated through GL4ES from any GLES2 compliant board, but even if the current state of the Lima drivers were good enough for that to work , performance in a Mali 450 would be rubbish.
  18. As in so many other cases, the board I'd recommend for this task is Odroid XU4, specially since it is selling for $50 right now. You already have fully working GPU drivers for a recent 4.14 kernel, and even a distro focused on gaming (see this video from @NicoD)
  19. I haven't tried, but if it is not already set to a different value in your config file, I guess it will also work.
  20. There are currently no tablets supported by Armbian, so don't expect any to work out-of-the-box. If you are up to tinkering with things such as u-boot, wifi drivers, etc., in order to make it work yourself, then just look for some tablet with a SoC supported by Armbian, or with WIP images (RK3288 or RK3399 come to my mind as possible candidates).
  21. You can control this by setting INSTALL_HEADERS="no" BUILD_KSRC="no" in config-default.conf About the other issue you describe, I'm not sure to be understanding you correctly. Are you saying that you get different kernel version when building complete images and when building only kernel packages?
  22. If you want to power a external drive relaibly, I would not use any power source that provides less than 3 amps, not only with HC1 but with any board. About power consumption, it will be higher compared to less powerful boards as the Cubie2, but it will stay under 1 amp most of the time, except when you run very demanding tasks.
  23. Totally worth the $50 it costs. As a matter of fact, that would be my first recommendation for your use case.
  24. Are you using Default or Mainline kernel?
  25. When do you get that error? What are you trying to do? What is the command line you are using? Can you play videos with the "Rockchip Gstreamer Player" GUI?