gounthar

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.

I decompiled sun8i_thermal.ko, not sure what I was expecting...
This is the entirety of their "fix" compared to stock armbian: https://gist.github.com/dbeinder/6c4dac8df91fb4b1b1537bafa8136065/revisions
Yep, that's just a +30C offset shoved straight into the function, couldn't even be bothered with putting it into the struct for H2/H3, never mind chip detection...
> "BREAKING: Our engineer has solved the incorrect temperature Report about Zero LTS boards"
Good job, Xunlong, nice one

i have been updating the kernel, ffmpeg, and kodi in sequence when major new patches from @Kwiboo are updated with consistent success, minus the known issues.

Well, kernel modification is needed for better decoding (less glitches). Probably new *-ctrl.h files contain new fields (not 100% sure) which also need to be filled.
 
There is no any post processing implemented here like scaling. It would be possible to do that via SoC specific peripherals but that wouldn't be universal and thus it's out of scope of this library.
 
Anyway, I'm glad you succeeded.

Finally got it! No kernel modifications needed, only v4l2-request.

Key notes:
Use bootlin code, latest master (not release-2019.03 tag) I merged just one small patch from https://github.com/bootlin/libva-v4l2-request/pull/30/files (seems, it's unecessary) Download kernel sources with corresponding version. For my armbian is: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.45.tar.xz Extract 2 files from kernel/include/media mpeg2-ctrls.h and h264-ctrls.h and replace ones in v4l2-request Replace V4L2_PIX_FMT_H264_SLICE_RAW to V4L2_PIX_FMT_H264_SLICE in v4l2-request source code Compile and install (instruction is as 2 posts above) Don't forget to set VLC as in https://linux-sunxi.org/Sunxi-Cedrus  
Tested with VLC, usable with issues:
Artifacts in some videos h264 720p and higher, for example: https://imgur.com/nYFArT4 (360/480 works fine) Scaling (fullscreen, resizing) not works, slowdown with message [a310cb88] main filter error: Failed to create video converter Minor issues in console output on playback (see bold)  
Thanks to: @jernej for this post:
 

Yes, it is.
On nanopi neo air with armbian 20.08.0 (5.7.8) it works.
 
FFmpeg with 960x720 input from our camera* encode mp4 by h264_omx with 15-20 fps.  If i use cedrus264 as codec, ffmpeg can easy provide 30 fps. With default cam500b  i get 60 fps 640x480 (that is maximum of the camera).  Fps numbers i get from ffmpeg log and i think  this results is accurate enough. 
* our camera  isn't ov5640 default camera and 30 fps likely it's maximum fps. We haven't camera's datasheet. 

Anyone tried hadware encoding whit ffmpeg ?
 

Hello. Thanks to you post, i've started VPU acceleration in H3 (OrangePI PC). For your SBC seems it will be the same.
 
 
Seems, it will be better to upgrade backend headers, than downgrade kernel
 
 
Try this patch: https://github.com/bootlin/libva-v4l2-request/pull/30/files
 
Details:
https://forum.armbian.com/topic/11184-hardware-graphicvideo-acceleration-in-h3-mainline/?do=findComment&comment=105564

I have reverted the following commits:
 
341772b82a3b media: cedrus: Specify H264 startcode and decoding mode 8cae93e09011 media: uapi: h264: Add the concept of start code 5604be66a568 media: uapi: h264: Add the concept of decoding mode Now I can run decoding of H264:
$ export LIBVA_DRIVER_NAME=v4l2_request $ time ffmpeg -hwaccel vaapi -hwaccel_device /dev/video0 -hwaccel_output_format vaapi -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -f null /dev/null ... real 0m15.255s user 0m5.651s sys 0m1.693s Average speed is ~5.3x, fps ~130
There are some errors at the end though:
 
[AVHWFramesContext @ 0xae54cfe0] Failed to destroy surface 0x400000b: 6 (invalid VASurfaceID). Here is the test of decoding without hardware:
$ time ffmpeg -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -f null /dev/null real 0m37.776s user 0m57.906s sys 0m1.983s Average speed is ~2.0x, fps ~50
I also tried to decode in software and encode in hardware. This causes crash of ffmpeg (I was not able to get a stack with gdb yet):
ffmpeg -vaapi_device /dev/video0 -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -vf 'format=nv12,hwupload' -c:v h264_vaapi -an stream.mp4 ... Segmentation fault  

I've found that the issue with h264 codec is caused by the size of the struct v4l2_ctrl_h264_slice_params defined in include/media/h264-ctrls.h (kernel) and include/h264-ctrls.h (libva-v4l2-request).
Kernel's version adds one more field start_byte_offset with commit
commit 5604be66a56867a784e162299a48c214921ffa1b Author: Boris Brezillon <boris.brezillon@collabora.com> Date: Fri Aug 16 13:01:24 2019 -0300 media: uapi: h264: Add the concept of decoding mode I did not find any changes in libva-v4l2-request that match this change in kernel.
I'm going to revert the above commit to test whether this can fix the issue.

Yes, I did. If was long time ago and I found kerberosio more attractive. There was also a performace issue with ZM on bananapi that time.
I've tested ZM recently again (on bananapi m3) and it seems using less CPU than kerberosio while movement detection. So, I would switch to ZM if it will be able to handle >1 cameras.
But I decided to first play with HW decoding on bananapi prior to migrating to ZM.
 
-----
Here are the results of my attempt to use cedrus.
- I've built libva-v4l2-request. There were few issues with it. It requires libva-dev and libdrm-dev, I've installed it with apt.
Version release-2019.03 of libva-v4l2-request failed on build due to libva-dev version mismatch (this package seems declared incorrect verion for pkg-config).
I've switched to a tip of the master branch was built successfully (but with small change in the /usr/include/linux/videodev2.h - I've added v4l2_timeval_to_ns which
is missing. BTW, I've also installed linux headers with apt, these headers contain v4l2_timeval_to_ns but libva-v4l2-request does not use these)
This lib is installed by default to /usr/lib/dri/, but libVA will search it under /usr/lib/arm-linux-gnueabihf/dri/ and I've just create a symbolic link. Maybe --prefic should be specified to autoconf instead.

- I've tried to use this lib with ffmpeg (default, installed with apt):
export LIBVA_DRIVER_NAME=v4l2_request ffmpeg -v verbose -hwaccel vaapi -hwaccel_device /dev/video0 -hwaccel_output_format vaapi -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -r 5 -an stream.mp4
It produces the following error:
 
[AVHWDeviceContext @ 0x1d7a820] libva: VA-API version 1.1.0 [AVHWDeviceContext @ 0x1d7a820] libva: va_getDriverName() returns -1 [AVHWDeviceContext @ 0x1d7a820] libva: User requested driver 'v4l2_request' [AVHWDeviceContext @ 0x1d7a820] libva: Trying to open /usr/lib/arm-linux-gnueabihf/dri/v4l2_request_drv_video.so [AVHWDeviceContext @ 0x1d7a820] libva: Found init function __vaDriverInit_1_1 [AVHWDeviceContext @ 0x1d7a820] libva: va_openDriver() returns 0 [AVHWDeviceContext @ 0x1d7a820] Initialised VAAPI connection: version 1.1 [AVHWDeviceContext @ 0x1d7a820] Unknown driver "v4l2-request", assuming standard behaviour. Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Press [q] to stop, [?] for help [h264 @ 0x1d77fc0] Reinit context to 1280x720, pix_fmt: vaapi_vld v4l2-request: Unable to set control: Bad address v4l2-request: Unable to queue media request: No such file or directory [h264 @ 0x1d77fc0] Failed to end picture decode issue: 1 (operation failed). [h264 @ 0x1d77fc0] hardware accelerator failed to decode picture Kernel log also contains errors:
 
[94838.781065] cedrus 1c0e000.video-codec: Missing required codec control [94838.785428] cedrus 1c0e000.video-codec: Missing required codec control [94838.791230] cedrus 1c0e000.video-codec: Missing required codec control [94838.794613] cedrus 1c0e000.video-codec: Missing required codec control - I've built v4l2-request-test and play with it. Initially it complains "Unable to start display engine" so, I've commented this functionality (so it can decode, but does not try to display frames).
This suite contains several test packages (frames). MPEG2 tests works perfectly (decoding only, as I said).
H265 tests fail with error Processing frame 1/50 Loaded 145064 bytes of video slice data Unable to set control: Bad address There was no kernel errors.
H264 tests are disabled because of absence of V4L2_PIX_FMT_H264_SLICE in the system headers (linux headers contain it but autoconf does not see those).
 
Any suggestions how to enable H264? Should I also rebuild the kernel? What's wrong with H265?

Encoding using cedrus264 was for legacy kernel.
I think Uboborov has done some work with mainline kernel for encoding with cedrus. Search the forum for "encoding" or uboborov

most scripts are not pbp specific, but that has been the focus so i am not sure for other devices. i would say test and give feedback after reading the scripts. i will be making these more generic as i expect to get a few HardRock64 devices when they are available.
 
the most specific is the linux build script because of the pbp patch and kernel config, but you can override this with KERNELCONFIG and use your own config to build for almost any rockchip device. I will make the pbp patch overrideable.
 
back on topic:
 
kwiboo's linux-rockchip WIP branch is working great - and we have a LOT of activity for v4l2 and rkvdec on linux-media. excited for 5.9.
 
kwiboo's ffmpeg 4.3 branch patch applies to 4.3.1 and master as well as release/4.3 -- all working well!
 
i shared the vp9 file that gives me problems above. the same file decodes fine with intel vaapi.
 
the ffmpeg frontend still does not share v4l2request support, so software that uses libavcodec like mpv are still broken due to lack of decoder detection and selection capability.
 
wildly thankful for the work of kwiboo and jernej and others. thanks!
 
 
 
 

Unfortunately, no success.
 
First, mainline bootlin backend is outdated, h264 broken. It has some pull requests, that not merged.
Tryng to recompile Philipp Zabel's version, and merge his work for h264
 
 
This version works with artifacts in VLC:

 

Hi @Kwiboo,
 
I did some testing using your version 2 of the patch:
1) Few seconds after starting the video, the screen gets blank for few seconds.
2) If the decoder gets stuck is hard to make it work again. I tried the soft reset patch does not help much.
A sample video is here (has few missing packets): https://minisatip.org/tmp/tmp2.ts
 
Thanks

What i know orange pi has two microphone option.
 
1- on board microphone
2 - from audio in out
 
When i check with arecord -l
 
i see only one card which is realtek5651
 
ı have tried voice record with arecord. ı couldnt get any voice.
 
with usb sound card i can record.
 
i can listen with on board auido out.
 
Why i can not get any voice from on board microphone or audio in.?
 
you can see my alsa values
http://alsa-project.org/db/?f=351ef8f0285ef89eaa267f2b7ff9866f06ef3413
 
you can see all informations
http://ix.io/2rH8

I guess they rebranded an armbian image which includes alternative drivers for xradio and added the temperature fix....

I installed Orange Pi's version of Ubuntu Bionic server with kernel 5.34.27 mentioned in the tweet refered to by @gounthar above on a Orange Pi Zero LTS V1.5 board, and it has indeed fixed the temperature reporting problem.  The onboard wifi is working flawlessly, too.

I have some work-in-progress patches at https://github.com/Kwiboo/linux-rockchip/compare/next-20200501...next-20200501-drm-rockchip that should enable up to 4k30hz hdmi modes on rk3399.
 
My focus switched to rkvdec so these patches have been on hold for some time, they need to be synced with some of my older rk3328 patches for 420-mode support before they can be sent upstream. With 10-bit decoding now working I am expecting readying 4k/10-bit hdmi patches to be more fun :-)