Underwhelming performance Khadas Vim2 Max in video rendering kdenlive


I made a disassembler code of both versions of the program (aarch64 and armhf). During a quick inspection of the code (perhaps I missed important nuances), I found some interesting differences that can affect the strange behavior of the program (this is not a fact, but only my guess). I don’t have time to study everything. Perhaps in the future I will be able to return to this issue and find a reason.


That is a shame. Not sure if my pet theory has been eliminated yet. It is somewhat useful that you have a faster experiment than 2 hours now.

My theory is that temporary files are full: the way to monitor is a separate command prompt shell/window and watch the output from

df -h

before any problems, as soon as any problems start and then again after a couple of minutes of problems. If any of the tmp filesystems are getting full this will show which and you can then re-tune them.


Hello again, sorry but I again need your advice.
I tried to use “Armbian_5.41.1_S9xxx_Ubuntu_xenial_4.17.0-rc2-next-20180426_mate_KODI.img” +“Armbian_5.41.1_S9xxx_Ubuntu_xenial_4.17.0-rc2-next-20180426_mate_KODI.img” and “KVIM2-emmc”.
When using USB_Burning_Tool to install to eMMC I get “Parse burning image fail”.(you said not to use this)
When using an SD card I can’t boot from sd, pressing function doesn’t do anything. I installed Android on eMMC and installed the file in system update. But that bricks the OS. It restarts the Vim2, but it doesn’t boot anymore. It stays on the Khadas boot up screen(did this 2 times).

I tried following your instructions here

And on other threads. But I can’t make it work. It’s all a bit too complicated for me.

I’ll try again tomorrow. I’m reading all the posts about this, but there’s too much to read, and I can’t find anyone having the same issue.

It’s not only to test Kdenlive that I want to try Armbian. Also because I’m preparing a new video about Armbian on most of my SBC’s(comming in a few weeks).

Thank you. I’ll try that when I’ll install Ubuntu again.


Please note , the system MultiOS_3_in_1 and Armbian, fundamentally different in technology use. For your case, I recommend starting with Armbian.

  1. Restore the native Android to eMMC.
  2. Download, unpack and write a special program the resulting image to SD or USB drive. Please note-do not copy the resulting file"*.img" , write image through a special program (list of programs that you can do is themes about Armbian).
  3. Copy from the directory /dtb (recorded media) in the root directory of the file kvim2_android.dtb and rename it to " dtb.img".
  4. To run Android and execute the activation of the multi-boot (details are in the subject Armbian).
    For your tests with video, I recommend checking out three different images-with kernel 3.14, 4.9, and 4.17. The behavior of the system can vary significantly. If you have any questions about the launch of Armbian, I recommend watching topics about Armbian on this forum and armbian forum. By the way, there are several special topics with step-by-step instructions and pictures, how to activate multi-booting and how to run different systems from external media for beginners.


I know! The thing I do not understand is the low level boot sequence of these ARM chips in general, and Amlogic in particular. Fortunately other folks around here do!

My 6p: your VIM2 is now in some weird unknown state and who knows what is trying to boot from where. So, the way I get mine back to a known state is as follows:

  1. Flash a Khadas image to emmc using a windoze PC and the Amlogic burning tool. My preference for Khadas image is the 4.9.40 Ubuntu server image. The Amlogic burning tool instructions are here. The Ubuntu server image is here.
  2. At this stage your VIM2 will always load the kernel and DTB from emmc which seems like a problem. But in fact it (or at least mine) will load a rootfs from an SDcard! So I also have an SDcard with balbes150 Armbian 5.37 xenial server 20171226.img.xz on it. (Need to unzip, then dd the image to an SDcard). If you get this right then, with the SDcard in the VIM2, when you boot you should get Armbian and not Khadas Ubuntu.
  3. Last, you have a choice when running the rootfs from the SDcard of what you want to install on the VIM2 emmc. You can EITHER
    a) Use the /root/install.sh script which will copy the SDcard OS to the emmc, OR
    b) You can use the kvim2-update script which will install the KVIM2-emmc.img.gz image in the /ddbr directory into emmc. You get a suitable Mate/Server/3in1 image from Yandex here.

After step 3 your VIM2 will boot from emmc with the kernel/DTB and rootfs there. Or, if you have an SDcard in, it will boot with the kernel/DTB and rootfs on the card. Thanks all to balbes150 magic.


I got it to work. Thank you.
I tried installing that file in system update in Android again, this time with a Armbian image in on the sd and it worked. I think it didn’t work because I used the wrong image.

I tried :

  1. Armbian_5.37_S9xxx_Debian_stretch_3.14.29_server_20171226.img
    I could not see the whole desktop there. I use an 1080p display, it was in 1080p. But only the upper left part I could see. Not the right part nor the lower taskbar.
  2. Armbian_5.37_S9xxx_Debian_stretch_3.14.29_icewm_20171226.img
    I didn’t know what to do with that. I was put off because of the very old look of it.
  3. Armbian_5.37_S9xxx_Ubuntu_xenial_3.14.29_mate_20171226.img
    I can not login. When I type my password it reboots the login page and asks my password again.

I’ll check-out some more things in the weekend.
What is the best alternative distro I should try?
Thanks a lot. Greetings


Start by reading the first post in this topic.


There is no answer to this. To be pedantic, what would be best for you? My view on this is there are 3 layers to the cake:

  1. The kernel: main choices are 3.14 (good if you want video playing, games, …) and 4.9.40 (later version, …) There are some experimental 4.14 and 4.17 options but they are lacking some core functionality (e.g. wifi). My choice is 4.9.40 as best for me… There are 2 choices here - Khadas release and balbes150 version: I use Khadas as it has RNDIS support which I need when building my system. Technically you can build your own with the fenix scripts - I tried and failed!
  2. There is some VIM specific glue in terms of configuring/partitioning the emmc etc. I like the balbes150 options to boot from SDcard so use his partitioning, but of course use the Khadas Bluetooth & LED (pulse) options.
  3. The rootfs: here is where you have in theory a nearly infinite choice - OpenSUSE, Arch, Armbian, Fedora, Debian, Ubuntu, … My main consideration was I want a large repository of aarch64 applications - to the best of my knowledge that left me with Ubuntu (/Debian/Armbian) and SUSE. (e.g. there is no gnucash application in the Arch/ALARM repository). My current install is a homebrew from Ubuntu base 18.04 because I don’t like stuff in any of the standard distros. At a basic level there are only 2 distros in this list for which there is a simple image/install option - Ubuntu and Armbian (arguably SUSE and Arch images from balbes150 as well) so for newbies a much shorter list to choose from.


Hello again.
Another update.
I’ve now got the NanoPC T3+.

I’ve done the same project on it. And I’ve got the same problem with it as on the Khadas Vim2. It’s a bit faster, but that’s expected even with the problem.
It’s 1h25m27s for NanoPC, Khadas 1h43m46s
So it’s better but not what I want.

This may not be good for me, but it does give more information.
Now we know this problem shows up in 64-bit octa core sbc’s. On the XU4’s 32-bit it works fine…

I used on the NanoPC T3+ :
Armbian bionic next 4.14.40
Kdenlive version 17.12.3
MLT version 6.6.0

On the Khadas Vim2 :
Ubuntu 16.04.3 LTS with Mate desktop
Kdenlive version 15.12.3

I’m leaving on a cycling trip tomorrow. I’ll use the C2 for now. When I’m back I’ll do a lot more investigations. I must find a solution for this.

Thank you, greetings.

Here a screenshot of the problem :

Here the result :


That’s not a very scientific approach :wink:

Things to keep in mind:

  • you used different swap/zram settings and memory utilization is pretty different. On your last screenshot above from the Vim2 no swap was configured and only 1.4 GB of memory have been used (so the task was able to cope with 1.4 GB memory). Now on the NanoPC you seem to use 1 GB swap (if it’s an Armbian Ubuntu that’s most probably zram – can you confirm this by providing ‘armbianmonitor -u’ output please?) that have been fully used and the main memory also utilized completey. Now we’re talking about the task needing 3 GB of memory
  • The number of available CPU cores can directly influence the amount of memory needed, so if the task in question needs always the same amount of memory per CPU core then an octa-core device with 2 GB RAM (NanoPC) has a disadvantage compared to a quad-core device (C2).
  • 32-bit software might need magnitudes less memory compared to 64-bit software on ARM. I’ve compared a 32-bit and a 64-bit version of the same software running on a 64-bit SoC with 64-bit kernel a while ago: almost twice as much memory needed when running 64-bit code while not providing any significant performance wins

To summarize:

  • the same task running on 32-bit ODROID-XU4 might need a lot less memory so 2 GB DRAM might be fine for the job
  • If a task (or an application) needs a certain amount of memory per active CPU core then SoCs with twice as much CPU cores would need also twice as much RAM to perform in a linearly scaling fashion
  • Once swapping occurs performance can drop a lot depending on whether zram is used or a swap file/partition on physical storage. If physical storage is used the random IO of the storage is important. So an ODROID-C2 that swaps a little bit on their ultra fast eMMC modules can perform magnitudes faster compared to a system swapping on an ultra slow SD card

Some possible insights wrt count of CPU cores vs. memory demand, zram/swap performance and also on 2nd page of the thread how to temporarely disable CPU cores (maxcpus=4 in kernel cmdline):

As already suggested: without monitoring system behaviour with iostat and vmstat in the background it’s a bit hard to further draw conclusions.