gounthar

This is the worst choice.

Which nobody recommended to you since its not better then TV box. Its closed corporate controlled hardware and doesn't have an option for reliable storage.

This information is already outdated and does not correspond to the current market situation.
 
Make a mistake, rk3399 now has one of the best support in the main kernel (not to be confused with specific models of SbS or TV boxes, chip support and ready-made device support are not the same).
 
 

For running services with a bit more confidence and just a little more money I strongly suggest you to limit your selection to officially supported boards https://www.armbian.com/download/ (nanopi m4 / rockpi 4 or even NanoPC T4 could be in this range). Even there things are sometimes not perfect, but hardware is usually a class above. Also none of the TV boxes have official Armbian support. In case of troubles, you are limited to "TV boxes" forum only.
 
my 2c

Just to give you a realistic idea of total you may spend. at least $35 to 50 if you shop around  and be patient, possibly up to $70 or more if you just don't want to wait and haggle so much.
 
So aside from the board you buy,

 
 
 
you may want/need any one of these or similiar.. daughter board for the ops slot.
 


 
 
and that oddly hard to find barrel jack adapter pin *top row, last tip on the right)..
 

 
 
 
or if somehow you get lucky and find something like this ops adapter kit, it has ops powered cooling fans, proper voltage/amp for ops device power adapter, and ops daughtercard all contained inside it and each functioned separately when disassembled.
 

 
 
 
 
 
 
 
 
Here is the usb uart I have at the moment. Haven't gotten to use either of them yet so this could take a bit for me to update on the debug logs.
 
 

 
 
 
Would be nice if anyone else wanted to see what else can be done armbian or otherwise with these boards.
 
Am70 and am40 or am50 i can confirm boot to the operating systems all without an expensive smart board.
 
but yes you will need one or two of the things I have listed above to get the hdmi and or power going on them correctly on a normal or touch hdmi display. and a power switch more than likely. i used one off an old dekstop
 

Here are the Armbian bionic images with installed RTSP streamer using H264 HW encoding on Allwinner H3 boards
Orange Pi One
Orange Pi Zero
Images are able to run on any board with Allwinner H3
 
 

Will there be support for the RK3399PRO processor? e.g. for a Rocki pi N10 SBC?

Since 5.9 is ahead I'd suggest to focus on that since this will become next LTS kernel.

Hello again.
I've compiled libva-v4l2-request for actual orangepipc 5.7.15-sunxi #20.08
Works better than 5.4.45, no artifacts in 720p
Patched sources: https://github.com/Sash0k/libva-v4l2-request

Basically yes. Note that kernel patches are only for improvements - fixing decoding issues. At least H264 API should be promoted to stable with kernel 5.10, maybe others too.
 
Any player which uses ffmpeg directly should be able to benefit from those patches. AFAIK mpv needs only one simple patch in order to use this chain. I have no idea about VLC internals so I can't say much about it. About VAAPI - request API (Cedrus implements it for decoding) is similar in terms of requirements and features to VAAPI so Bootlin created simple library to expose it. That way they could use any VAAPI capable player. However, some codec interfaces changed considerably from those times and Bootlin didn't invest any time to update this library, so it's not very useful ATM unless you know how to fix it. I know that some people has still interest in that library so I imagine it will be forked/updated once api stabilizes further.
 
Note that there is one hidden issue. As long as you play video in native size, all is well. If you want to scale it then you might get a lot of dropped frames. Issue here is how you do scaling. It's pretty intense process for CPU so you should avoid that at any cost. Unfortunately, VLC with VAAPI translation library did just that. Second option is to go with GPU. IIUC it was impossible to do with binary drivers due to missing import buffer functions, but with mesa it should work now (didn't try it myself). Note that mali400 may still be limiting factor for some cases. Another approach is to use dedicated HW cores. For example, deinterlace core on H3 can be used for scaling only (with few driver tweaks). Downside of this is that scaling process depends on SoC. This would be different even for Allwinner SoCs (not all SoCs have deinterlacer). Most efficient approach (used in LibreELEC) is to use DRM planes - you instruct display engine how to scale and crop it and where on screen to render it. However, I'm not sure if this can work on X11 at all. Wayland should be able to pull this off IIUC.
 
Disclaimer: I don't care about desktop on ARM boards so I didn't do many experiments in this regard and I don't plan to work on improving desktop experience. LE runs without any desktop on ARM boards. Note that I also don't plan to work on any player except ffmpeg/Kodi combo.

Am I understanding it correctly that it works as follows?
LibreElec patches the kernel to make use of the SoC's VPU. (Some of these patches make their way upstream eventually, but that's a slow process.) It also forks ffmpeg, which is patched to recognise these new kernel features & to make use of them. Kodi then refers to ffmpeg to access them.
What would be necessary for players other than Kodi—mpv or VLC for example—to benefit from this as well? And what is the role of libva, VAAPI, and these other things in this process?

Note that ffmpeg patches for request API are important - without patched ffmpeg, all kernel patches have no meaning. Second important thing is that LibreELEC runs Kodi without X11 for ARM boards - this allows to use display more efficiently. On X11 it would be needed to render video through GPU which is less efficient. Note that I never actually tried that.

Maybe you wanna to share your success by commiting a PR to https://github.com/armbian/build/blob/master/config/kernel/linux-rk3399-legacy.config ?
 

I read carefully user manual and found it
#Dont supports imultaneous HDMI and Screen for HDMI IN Using HDMI IN with HDMI port CONFIG_VIDEO_TC358749XBG=y #CONFIG_ROCKCHIP_DW_MIPI_DSI=y #CONFIG_DRM_PANEL_SIMPLE=y I did so and went to rebuild kernel image  
git clone --depth 1 https://github.com/armbian/build cd build ./compile.sh # in dialog menu # U-boot and kernel packages -> Show a kernel configuration menu before compilation # then in kernel configuration menu use save config -> edit via vi -> laod config ___ ____ _ ____ _ ____________ ___ ___ / _ \| _ \(_) | _ \| |/ /___ /___ // _ \ / _ \ | | | | |_) | | | |_) | ' / |_ \ |_ \ (_) | (_) | | |_| | __/| | | _ <| . \ ___) |__) \__, |\__, | \___/|_| |_| |_| \_\_|\_\____/____/ /_/ /_/ Welcome to Armbian Focal with Linux 4.4.213-rk3399 System load: 0.19 0.14 0.06 Up time: 1 min Memory usage: 3 % of 3809MB IP: 192.168.1.90 CPU temp: 55°C Usage of /: 19% of 15G Last login: Sat Aug 8 18:47:55 2020 from 192.168.1.85 root@orangepi-rk3399:~# v4l2-ctl --list-devices rkisp10_selfpath (platform:rkisp10-000): /dev/video0 /dev/video1 /dev/video2 /dev/video3 root@orangepi-rk3399:~# root@orangepi-rk3399:~# ffmpeg -f v4l2 -list_formats all -i /dev/video0 ffmpeg version 4.2.4-1ubuntu0.1 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 9 (Ubuntu 9.3.0-10ubuntu2) configuration: --prefix=/usr --extra-version=1ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/aarch64-linux-gnu --incdir=/usr/include/aarch64-linux-gnu --arch=arm64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat 58. 29.100 / 58. 29.100 libavdevice 58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 libpostproc 55. 5.100 / 55. 5.100 [video4linux2,v4l2 @ 0x5594189760] Raw : yuyv422 : YUYV 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuyv422 : YUYV 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : uyvy422 : UYVY 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv422p : Planar YVU 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : Y/CbCr 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv420p : Planar YUV 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv420p : Planar YUV 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv420p : Planar YVU 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : nv12 : Y/CbCr 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : Y/CrCb 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : gray : 8-bit Greyscale : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : 16-bit A/XYUV 4-4-4-4 : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : Y/CbCr 4:4:4 : [video4linux2,v4l2 @ 0x5594189760] Compressed: mjpeg : JFIF JPEG : [video4linux2,v4l2 @ 0x5594189760] Raw : rgb565le : 16-bit RGB 5-6-5 : [video4linux2,v4l2 @ 0x5594189760] Raw : bayer_grbg8 : 8-bit Bayer GRGR/BGBG : /dev/video0: Immediate exit requested root@orangepi-rk3399:~# Profit !
 
but it's too early to rejoice ffmpeg and gstreamer  not runing
Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video0' failed during initialization Additional debug info: gstv4l2object.c(3782): gst_v4l2_object_set_format_full (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Call to S_FMT failed for NV12 @ 1920x1080: Bad address Execution ended after 0:00:00.117020985 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline .. Parsing a group of options: input url /dev/video0. Applying option hwaccel (use HW accelerated decoding) with argument vaapi. Applying option f (force format) with argument v4l2. Applying option pix_fmt (set pixel format) with argument nv12. Applying option s (set frame size (WxH or abbreviation)) with argument 1920x1080. Applying option r (set frame rate (Hz value, fraction or abbreviation)) with argument 30. Successfully parsed a group of options. Opening an input file: /dev/video0. [video4linux2,v4l2 @ 0x5595907930] fd:3 capabilities:84200001 [video4linux2,v4l2 @ 0x5595907930] Current input_channel: 0, input_name: tc358749xbg, input_std: 0 /dev/video0: Bad address  

Hi there,
is the RK3399 (OrangePi4) already supported by Armbian?
The manufacturer claims support "Debian 9" but current Armbian is Debian Buster 10 - based.
Anyone tried this board with success?

IMHO is 85 celsius really hot. I don´t also know how a big themalpad could work. Is the heatsink warm when you run?
 
 
Mine have i running really slow and the temperature is arround 32 degrees on normal day with normal load. Full speed about 50 degrees. But i need to say that i have also a heatsink on the CPU from an old Fritzbox router. But even on fullspeed is the fan really quiet and you need to listen very well to here it run. In my opinion is 15 euros a really good deal when i compare with a lot of noisie fans i have. The only problem is that the fan is a little bit bigger than the fan opening of the Geekworm case... So i din´t have the original cover on the case...
 

Another solution to avoid noise and fan management for orange pi 4 is to use a big heatsink (fanless solution):
 
Orange Pi 4 Heatsink
 
I tried it and it works well.
 
The temperature can rise to 85°C in peak (and 82°C in average) when I tried to stress the cpu with benchmark or with high resolution youtube video, but I never stayed stuck due to a overheat.
In normal use, I have more something between 58 to 65 °C.

I think I found the chipset I'd need to find boards for - the Rockchip RK3308. It has 8-channel input. There's one cheap board with this - the Rock Pi S. I'm curious if any of the Rock Pi S users here have got audio input working!

Error prone HW design with floating IO.
Proper design with fixed IO states:
VCC --------> Pullup Resistor ---| GND --------> Push Button -------+------> PA19 The pullup is already in place.
Pressing the button will flip the IO from 1 to 0.

Pretty normal : PA19 is shared also as TWI1-SDA which is an I2C bus provided on header, and there are some PullUps resistors already present on the OPiZero board.
 
So, simply short PA19 to GND, you will see that your script will print "0".
 

When using the switch circuit, it's possible.
The switch circuit is possible by the photo switch or a transistor.
 
When the switch does a blue line, a backlight of LCD turns on /OFF.

Questions and answers about powering the Orange Pi Zero using the "Power over Ethernet" option.
 
The aim is to answer community questions about Power Over Ethernet options (both official 802.3af/at and unofficial "PoE" solutions) and to improve the wiki page with these answers:
http://linux-sunxi.org/Xunlong_Orange_Pi_Zero
 
Helpful links:
http://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Powering_the_board https://en.wikipedia.org/wiki/Power_over_Ethernet https://forum.armbian.com/index.php/topic/1762-new-oranges-with-h5-and-h2/page-2#entry19054  
Examples of standards-compliant PoE hardware:
802.3af switch: https://www.amazon.com/TP-Link-8-Port-Ethernet-Desktop-TL-SF1008P/dp/B003CFATT2/ 100MBit 802.3af to 5V power supply (10W max): https://www.aliexpress.com/item/1PCS-Micro-USB-Active-POE-Splitter-Power-48V-to-5V-2-4A-for-Raspberry-pi-3/32741378583.html Gigabit 802.3af to 12/9/5V power supply (12W max): http://www.tp-link.com/en/products/details/cat-4794_TL-POE10R.html  
Examples of non-standards-compliant PoE hardware:
8 port "PoE" injector (you pick the input voltage): https://www.aliexpress.com/item/Cameye-8-Channel-CCTV-POE-Injector-for-Surveillance-IP-Cameras-Power-over-Ethernet-Adapter-with-Shell/32745669802.html "PoE" splitter: https://www.aliexpress.com/item/POE-Adapter-cable-Tape-Screened-Passive-Power-Over-Ethernet-RJ45-Injector-Splitter-Kit-12-48v-Synthesizer/32516398486.html https://www.aliexpress.com/item/10cm-3-9-5-5mm-x-2-1mm-DC-Female-to-Micro-USB-Male-Charging-Cable/32319957922.html (Zero soldering option!) Solder to pads on Orange Pi Zero and use a DC-DC step down converter to get 5V: https://www.aliexpress.com/item/5-pcs-Ultra-Small-Size-DC-DC-Step-Down-Power-Supply-Module-3A-Adjustable-Step-Down/32261885063.html https://www.aliexpress.com/item/15924-Free-shipping-DC-DC-Step-Down-Converter-Module-LM2596-DC-4-0-40-to-1/32354635261.html https://www.aliexpress.com/item/24V-12V-To-5V-5A-DC-DC-Buck-Step-Down-Power-Supply-Module-Synchronous-Rectification-Power/32689938167.html Q&A:
 
1. The Orange Pi Zero says it supports "PoE" how is this implemented?
The Ethernet port on the Orange Pi Zero exposes pins 4/5 and 7/8 via pads on the bottom of the board. Photo here. Note that this is 802.3af mode B, which is not fully standards compliant (802.3af/at specifies mode A and mode B, it is not allowed to have a device which only accepts one mode).
 
Out of the box, there is NO way to power the board from Ethernet, either with an 802.3af/at switch or with passive "PoE" injectors. More effort is needed.
 
2. What are the options to power the Orange Pi with "PoE" ?
Option 1:
Solder 0 Ohm resistors across the pads and use a PoE injector with 5V.
Pro:
 + No additional power supply needed
Con:
 - 5V cannot travel long distances without voltage sag. You can put in a higher voltage (e.g. 7V DC) but then all the cables would need to be the same length and you risk destroying the Orange Pi if the voltage spikes.
 
Option 2:
Solder a step-down converter and use a PoE injector with a higher voltage (e.g. 24V).
Pro:
 + 24V will travel much farther than 5V in a CAT5/6 cable.
Cons:
 - You will need to purchase and solder an additional voltage regulator to take the input voltage and drop it down to 5V.
 
Option 3:
Buy/use a PoE switch implementing 802.3af/at.
Pro:
 + Standards compliant
 + 802.3af/at operate at ~48V, which can power devices up to 100m away from the switch
 + Plugging in a non-PoE device will not result in fireworks
 + Cable faults will not result in short circuits because the switch will shut down the port
Con:
 - Power electronics to turn 48V into 5V may consume more power than the Orange Pi itself
 - More expensive

Full .dts, which is works for us, now is  placed in uboborov repository.