cmuki

GPU is only doing 3D graphics.
Media applications are accelerated by VPU, which is a totally different part of the chip. I think gstreamer is already quite capable of using the v4l2 interface to profit of media acceleration drivers already in mainline kernel (namely hantro and rkvdec for rk3318, both accelerating h.264, vp8, vp9 and hevc, but some codecs still have partial support on rockchip64 armbian branch).
Ffmpeg needs to be built with patches and in a custom way because kernel interface for codecs has been made "stable" very recently (I guess in kernel 5.19).
Also mpv has the capability to use hardware video decoding via v4l2, but still need a custom build because it uses in turn ffmpeg. There is this old thread where I provided a custom build binary of mpv, but it was for ubuntu hirsute and debian bullseye; surely it would require some adaptations and tinker if you want to run on newer distros.
 
Accelarerating youtube in a browser is a whole different story. I don't know what is the current status (maybe @usual user has some clues?), but surely it is much more challenging than standalone video playing.
 

UPDATE!!
 
Hello, I'm pleased to announce that rk3318 CSC configuration has been accepted into mainline kernel!.
This means that next Armbian release (probably August) will provide regular kernel upgrades offered by Armbian ecosystem via normal apt upgrade command.
Until then, please stay stick to the usual manual upgrade!
 
But there is something more: new update for the rk3318/rk3328 images!
Most important changes:
Kernel upgraded to version v5.18.6 Memory clock set to 667 MHz (was 333 MHz), providing a nice boost in general, desktop and GPU performance; despite this works fine on my board I always warn you to test images first via sdcard Introduces MGLRU patches from @yuzhaogoogle (you can read about here and search google for more details), which should provide much snappier experience especially on low-memory devices You can find the images and deb packages for upgrades browsing the directory pointed on first page as usual.
 
You can visit the Armbian MGLRU topic, if you have questions about the features or kernel issues (like crash dumps which involve kswapd, for example)
 
 

@cmuki
Assuming the boot you provided is from the original image, I think there is no extra questions to ask: if the ddrbin says that you have 2048 megabytes, that is so.
The ddrbin, which is the first piece of code that is executed at all and initializes the board DDR memory, is the most reliable source from this point of view.
 
Going on with the bootstrap phase, u-boot says the same:
U-Boot 2017.09-gaa00306-201224-dirty #foxluo (Jan 19 2021 - 14:31:53 +0800) PreSerial: 2, raw, 0xff130000 DRAM: 2 GiB  
And obviously even the linux android kernel also detects 2 gigabytes of total RAM:
[ 0.000000] Memory: 1955884K/2064384K available (14910K kernel code, 2056K rwdata, 8884K rodata, 3968K init, 2806K bss, 75732K reserved, 32768K cma-reserved)  
That's it, fake hardware specs; the manufacturer altered the Android image somehow to show fake specs and maybe something is wrong with the DDR chips too (are they have been reprinted? are they just fake chips or not really connected to the board? who knows...)

@jock, thank you for you swift reply! I'll try to get my hands on a UART module in the next couple of weeks and report back.
 
Hopefully the information will be helpful for other members of the forum as well!