NicoD

RockPi is ok with vp9 4k60fps, thanks for telling me about it (about RockPi)

I did not had this message (but LongChair's mpv seems to not working with 10bits? on rk3399) so what i did:
cd /home/dante4 && mkdir video && cd video && git clone -b master https://github.com/rockchip-linux/libmali && git clone https://github.com/rockchip-linux/mpp && git clone -b master https://github.com/rockchip-linux/gstreamer-rockchip && git clone https://github.com/rockchip-linux/gstreamer-rockchip-extra && git clone https://github.com/mpv-player/mpv-build cd libmali && cmake CMakeLists.txt && make -j4 && make install && ldconfig LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/include cd ../mpp && cmake -DRKPLATFORM=ON -DHAVE_DRM=ON && make -j6 && make install apt-get update && apt-get upgrade -y && apt-get install -y libqt5opengl5 libqt5qml5 libqt5quick5 libqt5widgets5 libqt5gui5 libqt5core5a qml-module-qtquick2 libqt5multimedia5 libqt5multimedia5-plugins libqt5multimediaquick-p5 qtmultimedia5-examples qtmultimedia5-doc-html pkg-config gcc make git unzip wget xz-utils cmake devscripts equivs build-essential docutils-common mercurial cmake-curses-gui build-essential yasm mercurial cmake cmake-curses-gui build-essential gcc-arm-linux-gnueabi g++-arm-linux-gnueabi texinfo nasm automake pkg-config apt-get install libass-dev apt-get install libfdk-aac-dev fdkaac aac-enc libfdk-aac1 apt-get install autoconf automake build-essential cmake git-core libass-dev libfreetype6-dev libsdl2-dev libtool libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo wget zlib1g-dev yasm libx264-dev libx265-dev libnuma-dev libvpx-dev libfdk-aac-dev libmp3lame-dev libopus-dev mc locate libghc-bzlib-dev and then i configured FFmpeg with this options
PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" +http://forum.loverpi.com/discussion/comment/1426/#Comment_1426
 
with doing this first
where $home/ffmpeg_build is place where folder FFmpeg laying

And SBC vendors - they just look for the best solution to fit their needs and business plan for a certain board...
 
The cost and efforts need to verify/validate ISA conformance are extremely high, as they should be - you look at companies like Intel and AMD, qualification of a chip can take years - and same with ARM folks like Apple and Qualcomm, where they take the ARM ISA and do their own designs - the chips you see on the market now were actually done 3-4 years ago in a cadence of development.
 
And that's millions of euro's/dollars...
 
You look at SoC vendors like Allwinner, Rockchip, Amlogic - they're using IP blocks that have been pre-certified by ARM (and others) with the fabs - so each block has tapeouts for a certain geometry node and process.. Grab the ARM core of choice, the Mali GPU block, wrap it around DesignWare blocks for peripherals for UART's, GPIO, Ethernet, etc... It's like lego's or ikea furniture...
 
And to the CN side - this is all dependencies on foreign IP... whether is ARM, Intel, Imagination Tech (GPU's with PowerVR), MIPS, Oracle (ex-SUN), etc...
 
With RISC-V - that's all out the door - which makes this interesting - going back to CN, there's enough government money at the local and national level to make things happen, and enough research in the academic space, along with the industrial resources to get things done...
 
Remember the CN initiative - "Made in China 2025"
 
I'm just an observer on the industry here - not being political...but it is interesting what the mainland is doing, and worth watching...

that's ok, but what I have found is that UnixBench a good equalizer across different SoC's on these cheap little boards - even though UnixBench is still variable based on the compiler...
 
It runs long enough (a full run can be 28 minutes) to show if thermals are a challenge (for TinkerBoard, absolutely with stock config compared to NanoPI NEO, where the Tinker has a much better architecture (A12) vs. NEO with A7, but the Neo can shed heat faster, and outperform the Tinker in the longer run - heck, even Pi3B+ runs UnixBench faster than Tinker...

Good questions, I've added them. Thanks.

How can SoC vendors help here with support for chips, interfaces, GPU/VPU, network, etc...
The Armbian team has done a lot of development, how receptive has upstream been to accepting changes/pull requests?
What's the best approach for SoC/Board Vendors to get Armbian ported to their board/chipset?
Documentation is key for supporting a chip or board - where are the opportunities for the vendors to improve?

Well, yes, I didn't mention that you need to configure the system with the script first. I'll PM you a link of the preliminary version, though it is almost finished

well we have what you would call a militia parliament.. It's not always that they understand stuff better.. But hey.. data is the new oil.. we might need a few exxon valdez'es or deep water horizons to figure out how this new oil is handled safely..
some other bad jokes..
we don't understand it fully yet but let's build up a cartel (that's some years ago for the real oil)... wherever the pipeline goes.. someone is upset once it's in the environment it needs years until it disappears.. seems that this 'dataset' also contains information of their kids (account-names etc.), maybe this helps them a bit to understand the issue better...
 

 
feeling like grandpa simpson

@NicoD Well, in order to compile ffmpeg with rkmpp support, you need to pass these three configure flags (or their cmake equivalent, if that's what you are using): 
--enable-libdrm --enable-version3 --enable-rkmpp  
Then, make sure your user has access to DRM. It should be enabled out-of-the-box for the default user in Armbian, if you build a current NanoPC-T4 image with the script (not in the one for download). Or you can just try to launch ffplay with sudo.
 
For last, when you launch it try changing the "h264" decoder to the "h264_rkmpp" decoder. Here is a link to a thread in the ffmpeg lists from someone who tried to do something similar: http://ffmpeg.org/pipermail/libav-user/2018-April/011081.html
 
Good luck with that 

AFAIK, ffmpeg can only display rkmpp decoded video through drmprime/gbm. Meaning that it cannot show it windowed in kdenlive.
 
I see more chances of using mpp accelerated decoding in a gstreamer-based video editor, such as pitivi

This thread summarizes the efforts done to get armbian support for the new RockPi 4b.
 

 
Boardspecs (from: https://wiki.radxa.com/Rockpi4/getting_started):
 
Rockchip RK3399 64bit dual channel LPDDR4@3200Mb/s, 1GB/2GB/4GB optioal storage:
eMMC module (optional) uSD card M.2 SSD (M.2 connector supports up to 2T M2 NVME SSD) display:
HDMI 2.0 up to 4k@60 MIPI DSI 2 lanes via FPC connector other features:
3.5mm jack with mic MIPI CSI 2 lanes via FPC connector, support up to 800 MP camera. 802.11 ac wifi Bluetooth 5.0 USB 3.0 OTG X1, hardware switch for host/device switch, upper one USB 3.0 HOST X1, dedicated USB 3.0 channel, lower one USB 2.0 HOST X2 GbE LAN with PoE support (hat required!) 40-pin expansion header USB PD, support USB Type C PD 2.0, 9V/2A, 12V/2A, 15V/2A, 20V/2A. (supports Qualcomm® Quick Charge as well) 85mm x 54mm  
Current support status (and some background):
first dev samples arrived and @martinayotte and @TonyMac32 started to integrate it into the rockchip64 boardfamily. Radxa offers a patched kernel and u-boot based on rockchips out of tree 4.4 kernel and 2017.09 u-boot. The our rockchip64 family is based on @ayufan s u-boot (which is a fork of rockchips) but a simple patch in of raxdas defconfig and the needed devicetree files don't work (it breaks on several parts during compilation related to USB and other stuff I'm still not 100% sure why.. ). So we went for a defconfig and DT file based on the one of the RockPro64 (cause even without patching, those images booted - a lot of stuff didn't work but at least it allowed us to start getting things working).
People related to Radxa forked the buildscript (https://github.com/brian541/build) and I assume that's why they can provide some 'preview' Armbian images on their site. Problem here is that they defined their kernel and their u-boot in a new linuxfamily (https://github.com/brian541/build/blob/master/config/sources/rk3399rockpi4b.conf) we simply can't have another RK3399 boardfamily (we have two, they share the kernels but not u-boot cause some boards have issues with upstream u-boot - we don't want to manage another u-boot fork nor another 4.4 kernel, it's ayufans or upstream).
That's why things may need a bit of time until they work properly on the RockPi.
 
Currently working (rockchip64-dev branch):
GbE
USB
Wifi (but laggy)
SD-Card (seems to be fine now)
HDMI (not committed yet)
 
Currently broken or with issues:
SD-Card has random hangs (probably speed issues)
 
everything else must be expected as broken at the moment. As far as I know nobody is currently working on 4.4 images and it might need some time to bring things up there. So RockPi 4b images must be considered as early wip at the moment and have to be built on your own cause we don't provide images yet.
 
side-note: first patches are also upstream to support the board in mainline kernel (not done by us https://patchwork.kernel.org/patch/10745929/)
 
@martinayotte & @TonyMac32 can you please correct in case I screwed something up in my summary?
 
@Igor or @zador.blood.stained if you think the thread fits better into the 'board bring up' subforum just move it.

That`s a joke. Learn to laugh
Don`t joke about C, that`s serious stuff. (again...)
Greetings

I am there Friday evening - Monday morning. 
 

See you there.  

I plan to attend FOSDEM 2019, anyone else too?

I'm afraid not.  A few have some sort of "marker" to show what they are (a resistor somewhere tied to an ADC, and efuse value, etc), but they are as non-standard as the SoC's themselves.
 
 
A lot of people feel this way, but it would require an agreement on a standard.  SPI flash or an eeprom drive cost some vendors will never sign up for, and create some problems when needing to upgrade the information stored on them (device tree bugs, bootloader fixes, etc)
 
And projects like this one wouldn't have much to do either, the "big guys" would take over and you'd have the same basic options as PC, with others like us and Arch being "alternatives".  That said, there is a versatility of application to SBC's that does not exist with PC.  Few strap a PC to a bench with bare I/O monitoring things, that died with the parallel port.  So I think there will always be room.
 
An FPGA that runs a RISC-V  powerful enough for linux isn't in my budget just yet, but it does look interesting.

That would be ideal, but some of these boards have... peculiarities that cause source code issues (Tinker has some gymnastics around reboot that require some ugly hacking of the sd/emmc driver that can break other RK3288 devices) or userspace issues (manually toggling IO's to reset BT adapters).  In general, though, you'll find that most of our images are the same for the same SoC, just with DTB/boot script differences for each particular layout, it's why on any board bringup you see us just manually swapping DTB's to see if it will work out of the box.

In Libreelec (KODI-18) on Khadas EDGE (RK3399) play all video works. Including HW for 4K and sound.
 
 
p.s. pls test  https://forum.armbian.com/topic/8898-ramblings-and-progress-with-the-rk3399/?do=findComment&comment=68690 
 

You read my mind! I'm brushing up the last stages for the RK3328/3399 multimedia support, and after that I was going to propose to add it to the build script.
 
So my plan is to release the media scripts for those two SoC's in a few days, and after having some feedback from the community integrate the main features into the main build.
 
Edit: I mean including all three RK SoC's: 3288, 3399 and 3328.

You've got an undervoltage before it goes into the board.
I wonder what your USB voltage is?

Heatsink and M.2 Expander Board are out. You can buy them here https://shop.allnetchina.cn/collections/rock-pi-4-accessories?page=2

I built Jock's forked X11 armsoc driver,   Installed and configured the Malie BLOB rpm and configured for X11.
 
Rebooted.
 
I ran glmark2-es2 :
=======================================================
root@nanopct4:~/Desktop# glmark2-es2 --fullscreen
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T860
    GL_VERSION:    OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).f44c85cb3d2ceb87e8be88e7592755c3
=======================================================
[build] use-vbo=false: FPS: 11 FrameTime: 90.909 ms
[build] use-vbo=true: FPS: 13 FrameTime: 76.923 ms
=======================================================
                                  glmark2 Score: 12 
=======================================================
 
I checked the Xorg.0.log.. armsock_dri isn't installed.  Isn't that part of the armsoc driver build ?
 
[   732.501] (EE) AIGLX error: dlopen of /usr/lib/aarch64-linux-gnu/dri/armsoc_d
ri.so failed (/usr/lib/aarch64-linux-gnu/dri/armsoc_dri.so: cannot open shared o
bject file: No such file or directory)
 
 
Without armsoc_dri I'm stuck software rendering.
 
If you have armsoc_dri.so can you attach it to this thread ?
 
 
I'm pretty sure I'm getting close to getting hardware acceleration working on my nanopc-t4 

Of course. You need to fix this otherwise everything you do is just a waste of time. And it's under-VOLTAGE and not under-current so as long as you ignore Ohm's law you're getting nowhere. The problem is high resistance and most probably (and as usual) the cable between PSU and device is to blame.

I'm going to test with the current stable armbian image and update this thread when done.
 

Some news:
 
https://wiki.radxa.com/Rockpi4/downloads
 
There is a first Armbian image available.

Yep.. I am using uname -a to get the architecture type.   I get aarch64.
I will rebuild with arm64 and post it.
It should be posted within the hour