gounthar

I was just filming a video about (your) @JMCC's RK3399 Media Script. 
I`m using the RockPi4B for it, but chromium GPU acc doesn't seem to be working. The Rockchip video player does work.
Here's the gpu info of chromium
 
Using Armbian Bionic 5.98 default. 
I should have tested it first before filming the video.   
I'll wait to do it in the M4V2 review video then. I wanted to make the video for RK3399 in general... 

It works great on the M4. I woulnd't want to live without it anymore. 
Any news on an update for it?

Cheers.

Edit. : Install Log
 
 

Not sure if that is supported and on legacy kernel 3.4.y is more or less: what works, works. Development was abandoned years ago. With modern kernel, there was perhaps too little interest to cover this feature development ? Even for decoding implementation we wait that things get mainstreamed (AFAIK with 5.2.y) since its too big task for a few amateurs around Armbian development.

I've got ffmpeg working with v4l2_request api on Allwinner H3 (orange pi pc).
It achieved in a few steps:
1. Download FFmpeg https://github.com/xbmc/FFmpeg/archive/4.0.4-Leia-18.4.tar.gz
2. Patch it with https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages/multimedia/ffmpeg/patches
3. Download mainline kernel 5.3.5
4. Patch it with https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Allwinner/patches/linux
5. Copy linux headers on rootfs /usr/include after kernel built:
make headers_install ARCH=arm INSTALL_HDR_PATH=/your/path/to/headers 6. Install libdrm-dev and libudev-dev before configuring FFmpeg
7. Configure FFmpeg with:
/configure --enable-v4l2-request --enable-libudev --enable-libdrm --enable-shared --disable-static \ --disable-openssl --disable-gray --disable-vaapi --disable-vdpau --disable-rkmpp 8. Build FFmpeg on the target machine (orange pi pc in my case)
That's it )
 
ffmpeg -re -hwaccel drm -i Big_Buck_Bunny_720_10s_2MB.mp4 out.avi FFmpeg perfectly uses HW acceleration on decoding H264.

thank you for reply 
I got FFmpeg  Cedrus from it's originally Source  and added this patch (ffmpeg_h264_H3) and make configured it with below Command
./configure --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libx264 --enable-libmp3lame --enable-libpulse --enable-libv4l2 when it compiled and installed I got this version:
$ ffmpeg -version ffmpeg version git-2015-01-22-f86a076 Copyright (c) 2000-2014 the FFmpeg developers built on Feb 7 2017 10:05:28 with gcc 4.9.2 (Debian 4.9.2-10) configuration: --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libx264 --enable-libmp3lame --enable-libpulse --enable-libv4l2 libavutil 54. 6.100 / 54. 6.100 libavcodec 56. 0.101 / 56. 0.101 libavformat 56. 2.100 / 56. 2.100 libavdevice 56. 0.100 / 56. 0.100 libavfilter 5. 0.102 / 5. 0.102 libswscale 3. 0.100 / 3. 0.100 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 0.100 / 53. 0.100 but when I try encode video I get this error:  [cedrus264 @ 0x12a1760] VE Open error.
agape@orangepione:~/ffmpegtest$ ffmpeg -i jellyfish-5-mbps-hd-h264.mkv -pix_fmt nv12 -c:v cedrus264 -f null /dev/null ffmpeg version git-2015-01-22-f86a076 Copyright (c) 2000-2014 the FFmpeg developers built on Feb 7 2017 10:05:28 with gcc 4.9.2 (Debian 4.9.2-10) configuration: --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libx264 --enable-libmp3lame --enable-libpulse --enable-libv4l2 libavutil 54. 6.100 / 54. 6.100 libavcodec 56. 0.101 / 56. 0.101 libavformat 56. 2.100 / 56. 2.100 libavdevice 56. 0.100 / 56. 0.100 libavfilter 5. 0.102 / 5. 0.102 libswscale 3. 0.100 / 3. 0.100 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 0.100 / 53. 0.100 Input #0, matroska,webm, from 'jellyfish-5-mbps-hd-h264.mkv': Metadata: encoder : libebml v1.2.0 + libmatroska v1.1.0 creation_time : 2016-02-06 04:00:51 Duration: 00:00:30.03, start: 0.000000, bitrate: 4976 kb/s Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default) [cedrus264 @ 0x12a1760] VE Open error. Output #0, null, to '/dev/null': Metadata: encoder : libebml v1.2.0 + libmatroska v1.1.0 Stream #0:0(eng): Video: h264, q=2-31, 128 kb/s, SAR 1:1 DAR 0:0, 29.97 fps (default) Metadata: encoder : Lavc56.0.101 cedrus264 Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (cedrus264)) Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

Here 's the patch (5.3.4 kernel).
diff -u a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi --- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi 2019-10-17 23:47:33.000000000 +0300 +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi 2019-10-27 22:34:55.988303874 +0300 @@ -105,6 +105,27 @@ }; }; + rt5651-sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "realtek,rt5651-codec"; + simple-audio-card,format = "i2s"; + simple-audio-card,mclk-fs = <256>; + simple-audio-card,widgets = + "Microphone", "Mic Jack", + "Headphone", "Headphone Jack"; + simple-audio-card,routing = + "Mic Jack", "MICBIAS1", + "IN1P", "Mic Jack", + "Headphone Jack", "HPOL", + "Headphone Jack", "HPOR"; + simple-audio-card,cpu { + sound-dai = <&i2s0>; + }; + simple-audio-card,codec { + sound-dai = <&rt5651>; + }; + }; + sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-simple"; clocks = <&rk808 1>; @@ -184,6 +205,10 @@ status = "okay"; }; +&hdmi_sound { + status = "okay"; +}; + &i2c0 { clock-frequency = <400000>; i2c-scl-rising-time-ns = <160>; @@ -432,6 +457,16 @@ i2c-scl-rising-time-ns = <150>; i2c-scl-falling-time-ns = <30>; status = "okay"; + + rt5651: rt5651@1a { + compatible = "rockchip,rt5651"; + reg = <0x1a>; + clocks = <&cru SCLK_I2S_8CH_OUT>; + clock-names = "mclk"; + hp-det-gpio = <&gpio4 RK_PC4 GPIO_ACTIVE_LOW>; + spk-con-gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; + #sound-dai-cells = <0>; + }; }; &i2c2 { @@ -459,6 +494,16 @@ status = "okay"; }; +&i2s0 { + rockchip,playback-channels = <8>; + rockchip,capture-channels = <8>; + status = "okay"; +}; + +&i2s2 { + status = "okay"; +}; + &io_domains { bt656-supply = <&vcc_1v8>; audio-supply = <&vcca1v8_codec>; @@ -724,3 +769,9 @@ &vopl_mmu { status = "okay"; }; + +&spdif { + i2c-scl-rising-time-ns = <450>; + i2c-scl-falling-time-ns = <15>; + status = "okay"; +}; But the patch merely indicates to the kernel what equipment is present. We need another driver for the rt5651. Kernel sources have a module rt5651.c. I haven 't figured it out yet. You might need some more rk3399-specific module.

Hi all.
I'm trying to figure out how to use gstreamer to encode h264 video on Rock64 (Rockchip RK3328). I'm using Armbian Bionic 5.60 (stable Ubuntu 18.04.1 LTS 4.4.156-rockchip64).
I compiled mpp and gstreamer-rockchip from https://github.com/rockchip-linux  and installed both, but I'm still missing mpph264enc, how do I get that?
gst-inspect-1.0 mpph264enc says: No such element or plugin 'mpph264enc'
Many thanks for reading, any help would be greatly appreciated.
 
Regards.
Christian
 

Technically I flashed the image directly to the La Frite eMMC with etcher on a Debian 10 laptop via USB2. Using the bundled USB male to male cable.
 
Upon bootup, I press (a bunch of times) Esc on the keyboard connected to La Frite, then after ~3 seconds (start pressing from turning ON the La Frite) I press down 5 times, then Enter and it appears on linux as "Linux UMS" a 8GB drive you can flash to.

Hi @djismgaming how you did you manage to move armbian to the eMMC?
Thanks

If I looked this up correctly from the i.MX 6Solo/6DualLite Applications Processor Reference Manual the VPU has this specs:
HW Decoder: H.264 Profile: BP/CBP/MP/HP Resolution: 1080 i/p, 30 fps Bitrate: 50 Mbps
HW Encoder: H.264 Profile: BP/CBP       Resolution: 1080p, 30 fps    Bitrate: 14 Mbps
As the VPU is a dedicated IP the number of CPU cores does not matter for the codec performance and 1gb should suffice to provide the required buffer allocations for the intermediate frames.
 
Just composed my first transcode pipeline, see transcode-pipeline.pdf for reference. I do not really know what I am doing (google was my friend) and there are so much knobs for configuration and fine tuning so YMMV.
transcode-pipeline.pdf

If you got a Windows PC try to format the cards with the HP USB Format Tool (HPUSBFW_v2.2.3.exe) to gain again the full capacitiy.
If you did wrote a image to the cards the 32Mb could be a boot-partiton!?

Have you tried with autodetect on? If that doesn't work disable it by changing "true" to "false". 
Then set the correct resolution :
setenv hdmimode "1680x1050"
And set dvi. 
setenv voutmode "dvi"

Should be this simple. 

for me this sounds like the data of a <$50 DSL-Router in a Pi-factor size.
I dont think you will sell so much, that you can make profit
 

On imx6q SoC there is:
v4l2-ctl --device=/dev/video0 --all
 v4l2-ctl --device=/dev/video1 --all
v4l2-ctl --device=/dev/video10 --all
/dev/video10 requires at least kernel 5.4.0-rc1 to work out of the box.
                  
gst-inspect-1.0 exposes:
So hardware accelerated video pipelines can be composed in all flavors.

That is a good idea but I comes with the burden of the maintenance. 

Alternative option is that we add three badges H264D H264E H264T under "Specifications" at download pages and give you access that you can do that?

EspressoBIN is ok - has it's limitations, but living within them, it's good - good enough that pfSense/NetGate built a FreeBSD routing distro on it as a commercial product.
 
EspressoBIN is interesting for many, as not only Armbian, but it's supported in other distro's, and OpenWRT has full support.
 
If you don't mind OpenWRT - the GL-Inet B1300 is a great little box - It's based on the Qualcomm Atheros IPQ4028, which is a routing chipset with working dual-band WiFi - the factory firmware is built off Qualcomm's QSDK fork of OpenWRT (Chaos Calmer), and there's full support in OpenWRT 18.06 and master...
 
QSDK has all the QCA accelerators for routing offload, and the closed source Wave2 Wifi drivers, so it's very well sorted.
 
Factory firmware also includes OpenVPN Client/Server, along with Wireguard Client/Server, and gives direct access to OpenWRT's LUCI interface - their UI is a skin of LUCI, and for many might be good enough. I should mention that it also has Cloudflare DNS-over-TLS support built in - and all the OPKG's that OpenWRT has in their distro.
 
For $90USD, it's a lot of bang for the buck, and a very hackable little device.
 
root@192.168.0.1's password: BusyBox v1.25.1 (2019-01-10 15:04:51 CST) built-in shell (ash) MM NM MMMMMMM M M $MMMMM MMMMM MMMMMMMMMMM MMM MMM MMMMMMMM MM MMMMM. MMMMM:MMMMMM: MMMM MMMMM MMMM= MMMMMM MMM MMMM MMMMM MMMM MMMMMM MMMM MMMMM' MMMM= MMMMM MMMM MM MMMMM MMMM MMMM MMMMNMMMMM MMMM= MMMM MMMMM MMMMM MMMM MMMM MMMMMMMM MMMM= MMMM MMMMMM MMMMM MMMM MMMM MMMMMMMMM MMMM= MMMM MMMMM, NMMMMMMMM MMMM MMMM MMMMMMMMMMM MMMM= MMMM MMMMMM MMMMMMMM MMMM MMMM MMMM MMMMMM MMMM= MMMM MM MMMM MMMM MMMM MMMM MMMM MMMM MMMM$ ,MMMMM MMMMM MMMM MMM MMMM MMMMM MMMM MMMM MMMMMMM: MMMMMMM M MMMMMMMMMMMM MMMMMMM MMMMMMM MMMMMM MMMMN M MMMMMMMMM MMMM MMMM MMMM M MMMMMMM M M M --------------------------------------------------------------- For those about to rock... (Chaos Calmer, r48067) --------------------------------------------------------------- root@GL-B1300:~# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 26.81 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 processor : 1 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 26.81 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 processor : 2 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 26.81 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 processor : 3 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 26.81 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 Hardware : Qualcomm (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000  
 

There are no buttons, just tiny pads and it is hard to short them.
 
We didn't responsible for hardware design failures and if there would be a simpler way ...
 
Wrote on mobile
 
 
 
 

1080p display
xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync &&  xrandr --addmode HDMI-1 1920x1080_60.00 && xrandr --output HDMI-1 --mode 1920x1080_60.00
720p display
xrandr --newmode "1280x720_60.00" 74.50 1280 1344 1472 1664 720 723 728 748 -hsync +vsync && xrandr --addmode HDMI-1 1280x720_60.00 && xrandr --output HDMI-1 --mode 1280x720_60.00
https://linuxconfig.org/how-to-configure-your-monitors-with-xrandr-in-linux
 
You can add the line to armbianEnv.txt if I remember well.

OK, so, if you are the sort to build it yourself, you can.  It's under WIP/CSC, and is currently kernel 5.2.y.  You can do a couple things, one is to flash the image (using etcher) to a USB keyfob, the other is to update your firmware, then use a USB A to A cable from the closest USB port to the IR sensor.  Power up, hitting escape to interrupt the boot process, then type in
 
ums 0 mmc 0 to get the device to show up on the host computer.  The use etcher to flash the image right to the eMMC on the La Frite.

_ _____ _ _ | | __ _ | ___| __(_) |_ ___ | | / _` | | |_ | '__| | __/ _ \ | |__| (_| | | _|| | | | || __/ |_____\__,_| |_| |_| |_|\__\___| Welcome to Ubuntu Bionic with Armbian Linux 5.2.8-meson64 System load: 1.23 0.45 0.17 Up time: 5 min Memory usage: 11 % of 967MB IP: CPU temp: 55°C Usage of /: 4% of 56G Well then.  Give me a few to get it committed.

Armbian doesn't manage the HDMI Input ...

This is exactly what our build script does. For many years. But we don't deal with/support proprietary Rockchip tools http://wiki.t-firefly.com/en/ROC-RK3399-PC/upgrade_firmware_emmc.html for flashing ... which actually might even work. I successfully flashed Armbian image directly (via USB) to emmc to some older Rockchip hardware like https://www.armbian.com/z28-pro/ or https://www.armbian.com/miqi/ 
 
I assume it with this board it should go the same / similar but it is on you to try that. 

We already provide proper (ofc not fully finished/polished) DTB for Orangepi RK3399 by default.

Also forgot to:

Sudo update-alternatives --config mali
and choose the gl4es

OK GPU is working actually, had to input this command to get it to work. Part of it is in the readme.php in the repository where the images have been uploaded by the guys @ LoveRPi.com
 
sudo update-alternatives --install /usr/local/lib/aarch64-linux-gnu/mali mali /opt/libre-computer/model/aml-s805x-ac/mali/lib/aarch64-linux-gnu/gl4es 100
 
then using sudo update-alternatives --config mali chose the gl4es entry just added
after that glxinfo and glxgears worked! FPS counter and everything.
 
Video: 
 
 
 
 
Debian images README: http://share.loverpi.com/board/libre-computer-project/libre-computer-board/image/debian/README.php
 
Total Linux noob by the way but I like to tinker. README.php has no indication of this gl4es entry, although it is included in the image.

Yes, I flashed from the USB into the eMMC using an included utility with this command:
 
$ sudo lc_distro_transfer libre-computer/aml-s805x-ac /dev/mmcblk0

Thanks for these commands. They helped me getting my board out of a strange mode where it only displayed hw 0 0 0 0 0 0 0 0 0 0 and powerOn "someNumbers". Before that, I could not get into MASKROM mode anymore, nor in LOADER mode... It appeared kind of bricked to me.
By the way, I read there that one could get into MASKROM mode from software by zeroing part of the boot partition.
That's what got me into that "almost bricked" mode.
If anyone has the correct sequence of commands that could do it, I will use it from now on.