jernej

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.

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.

You have to make sure that libva-v4l2-request uses  same *-ctrl.h files that are in kernel sources under include/media/. For starters, just copy them over from kernel to lib source folder. Then you might need to adjust lib sources to new field names. Unless these files are completely the same, you won't have any success.

Mali is only for rendering, video decoding is done on separate HW core. However, its driver is not finished, VAAPI lib for it is also not finished yet and most of all, firefox supports HW video decoding (e.g. VAAPI) only on wayland. So, nothing that you could use right now. If you want decent video player on OPi Plus2E you can use LibreELEC image (Kodi) which has all work in progress included, but that is probably not something you had in mind (multimedia center app with no browser but youtube addon can be installed).

Simple, LibreELEC heavily patches kernel and ffmpeg for better experience. Patches are slowly getting in kernel but ffmpeg patches will need far more time to be accepted (kernel must first declare this API stable which won't happen anytime soon). You also need Kodi master (e.g. Kodi 19 pre-alpha), because it has a lot of important improvements. Last but not least, only Kodi GBM (e.g no desktop environment) version really works well (zero copy playback) and soon wayland. X11 has no chances to work well.
 
TL;DR: LibreELEC uses features which are in development and not present in any stable version yet.
 
BTW, also 4K HEVC videos work well.

@Myy small advice - make links to https://github.com/LibreELEC/LibreELEC.tv because I often delete branches which were already merged. linux56 branch will be removed soon.

No, they are disabled because nobody took time to properly enable them in board DTS until now (it will be in 5.7).
No, sun4i-drm is for all Allwinner SoCs, it supports Display Engine 1.0, 2.0 and 3.0. It's just named by Linux tradition where it takes name of first (oldest) supported platform.

No, they are disabled because nobody took time to properly enable them in board DTS until now (it will be in 5.7).
No, sun4i-drm is for all Allwinner SoCs, it supports Display Engine 1.0, 2.0 and 3.0. It's just named by Linux tradition where it takes name of first (oldest) supported platform.

No, they are disabled because nobody took time to properly enable them in board DTS until now (it will be in 5.7).
No, sun4i-drm is for all Allwinner SoCs, it supports Display Engine 1.0, 2.0 and 3.0. It's just named by Linux tradition where it takes name of first (oldest) supported platform.

If you have Pinebook in mind and the one from Olimex, they both use anx6345 IIRC. Driver for that chip was merged in kernel some time ago, but it doesn't consider "panel-supply" property. I guess that's what's wrong. @Icenowy?

You should send patch for that to U-Boot so next person which tries to use USB on OrangePi Win don't need to do that work again.

OrangePi Win default configuration in U-Boot has only half drivers enabled for ethernet. I fixed that recently with https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi/commit/2936eb2d550a642275113464fc9dcbb03357c049 It will be part of U-Boot v2020.04.

current AC200 Ethernet PHY driver is hacky, so it needs specific combination of drivers set as module and others as build in. You also need PWM driver, which is not yet merged upstream. Check here:
 

Here you have description and images how to do that: http://linux-sunxi.org/Tanix_TX6#Adding_a_serial_port_.28voids_warranty.29

I occasionally experience same issue with my HDMI monitor but not with TV. I suspect that HDMI PHY settings may not be entirely correct, but I couldn't find any problem with them yet.

[    8.586642] Adding 1004568k swap on /dev/zram1.  Priority:5 extents:1 across:1004568k SSFS
[    8.609952] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    8.698664] Bluetooth: HCI UART driver ver 2.3
[    8.698674] Bluetooth: HCI UART protocol H4 registered
[    8.698677] Bluetooth: HCI UART protocol BCSP registered
[    8.698736] Bluetooth: HCI UART protocol LL registered
[    8.698739] Bluetooth: HCI UART protocol ATH3K registered
[    8.698770] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    8.698914] Bluetooth: HCI UART protocol Intel registered
[    8.699026] Bluetooth: HCI UART protocol Broadcom registered
[    8.699064] Bluetooth: HCI UART protocol QCA registered
[    8.699067] Bluetooth: HCI UART protocol AG6XX registered
[    8.699101] Bluetooth: HCI UART protocol Marvell registered
[    8.785335] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    8.785424] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[    8.785826] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct  8 2016 15:31:47 version 7.46.57.4.ap.r4 (A1 Station/P2P) FWID 01-3621395e es6.c5.n4.a3
[    8.887619] zram0: detected capacity change from 0 to 52428800
[    9.057515] Bluetooth: hci0: BCM: chip id 94
[    9.057901] Bluetooth: hci0: BCM: features 0x2e
[    9.059996] Bluetooth: hci0: BCM43430A1
[    9.060004] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
[    9.809864] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0106
 
@jernej great!!

Nope, that goes through AC200 chip and there is no driver for it. Unfortunately it's not easy to reuse BSP driver as the API changed too much. If we would have AC100 driver, this would be easy... I might look into it in future...
I'll test that a bit later. Anyway, I mostly test using some video files, not with plugins. Note that plugins may have troubles due to recent switch to Python 3 and development version of Kodi.

@manuti No, I really didn't. Good to know.

Hi, your images @jernej are right here https://dl.armbian.com/_openelec/ I don't know if you know this or not.
Regards

Hi!
 
HW video decoding on mainline kernel is possible, but in most cases you have to do some kernel patching yourself and use special library which provides VAAPI or use modified ffmpeg libraries. MPEG2 decoding is possible with kernel 5.0 or 5.1 (not sure), basic H264 decoding will be possible with kernel 5.3 and HEVC decoding will probably come with kernel 5.5 (patches already exist). Note that H264 and HEVC codecs are feature incomplete currently. However, I did some improvements for LibreELEC and there most H264 and HEVC videos work. Patches are available on LibreELEC github but are incompatible with VAAPI library, so only option is to use modified ffmpeg.
 
Regarding memory consumption, please note that with OrangePi Lite you have only 512 MiB of RAM which is a bit low. LibreELEC for that reason doesn't support devices with less than 1 GiB of RAM. Consider following calculations for memory requirements, no matter which kernel you use:
1. Multiple variants of 4K and 1440p resolutions exist, so I'll assume that 4K means 4096x2160 (same as on my LG TV) and 1440p means 2560x1440
2. kernel allocates one XRGB (4 bytes per pixel) buffer for user interface (no matter if you're using window manager or not), so for that you need 4096*2160*4 ~ 34 MiB of CMA memory
3. video is decoded to NV12 or NV21 formats and both take 1.5 byte per pixel, that means 2560*1440*1.5 = 5.27 MiB of CMA memory per single frame
4. worst case for H264 and HEVC is that you need 16 reference frames to properly decode current frame, which means additional 5.27 * 16 ~ 84 MiB of CMA memory
5. VPU needs additional scratch buffers per frame. Size of those buffers depends on codec features used, but for H264 is typically about 1/4th of multiplied width and height, so in worst case (1 + 16)*2560*1440/4  ~ 15 MiB of CMA memory
6. VPU needs some other scratch buffers, but they are small, about 1 MiB in total
7. you also need additional CMA memory for providing encoded data to VPU, but memory consumption for that heavily depends on userspace library/player implementation. Hard to give any estimation, so let's use 20 MiB.
 
Final estimation for worst case display + VPU CMA consumption for 4K display and 1440p video: 34 + 5.27 + 84 + 15 + 1 + 20 ~ 160 MiB. You also have to consider that other devices may use CMA memory at the same time. In LibreELEC, CMA memory size is set to 256 MiB because so much is needed for decoding 4K videos.
 
Hopefully that gives you perspective how much memory is needed for H264/HEVC video decoding.
 
I won't touch (use) 3.4 kernel anymore, but I can help you with patching mainline kernel for better H264 and/or HEVC support and bring up ffmpeg based solutions (that includes mpv), if you want.

In the old days, I provided OpenELEC images with 3.4 kernel (https://github.com/jernejsk/OpenELEC-OPi2) and it worked with 4K videos on 1080p display. Sadly, images don't exist anymore and source doesn't build anymore. Be aware, I used CedarX library instead of libvdpau-sunxi.
 
I don't think I ever make it work with 4K screens, mostly because I didn't have such screen at the time.

Hi!
 
HW video decoding on mainline kernel is possible, but in most cases you have to do some kernel patching yourself and use special library which provides VAAPI or use modified ffmpeg libraries. MPEG2 decoding is possible with kernel 5.0 or 5.1 (not sure), basic H264 decoding will be possible with kernel 5.3 and HEVC decoding will probably come with kernel 5.5 (patches already exist). Note that H264 and HEVC codecs are feature incomplete currently. However, I did some improvements for LibreELEC and there most H264 and HEVC videos work. Patches are available on LibreELEC github but are incompatible with VAAPI library, so only option is to use modified ffmpeg.
 
Regarding memory consumption, please note that with OrangePi Lite you have only 512 MiB of RAM which is a bit low. LibreELEC for that reason doesn't support devices with less than 1 GiB of RAM. Consider following calculations for memory requirements, no matter which kernel you use:
1. Multiple variants of 4K and 1440p resolutions exist, so I'll assume that 4K means 4096x2160 (same as on my LG TV) and 1440p means 2560x1440
2. kernel allocates one XRGB (4 bytes per pixel) buffer for user interface (no matter if you're using window manager or not), so for that you need 4096*2160*4 ~ 34 MiB of CMA memory
3. video is decoded to NV12 or NV21 formats and both take 1.5 byte per pixel, that means 2560*1440*1.5 = 5.27 MiB of CMA memory per single frame
4. worst case for H264 and HEVC is that you need 16 reference frames to properly decode current frame, which means additional 5.27 * 16 ~ 84 MiB of CMA memory
5. VPU needs additional scratch buffers per frame. Size of those buffers depends on codec features used, but for H264 is typically about 1/4th of multiplied width and height, so in worst case (1 + 16)*2560*1440/4  ~ 15 MiB of CMA memory
6. VPU needs some other scratch buffers, but they are small, about 1 MiB in total
7. you also need additional CMA memory for providing encoded data to VPU, but memory consumption for that heavily depends on userspace library/player implementation. Hard to give any estimation, so let's use 20 MiB.
 
Final estimation for worst case display + VPU CMA consumption for 4K display and 1440p video: 34 + 5.27 + 84 + 15 + 1 + 20 ~ 160 MiB. You also have to consider that other devices may use CMA memory at the same time. In LibreELEC, CMA memory size is set to 256 MiB because so much is needed for decoding 4K videos.
 
Hopefully that gives you perspective how much memory is needed for H264/HEVC video decoding.
 
I won't touch (use) 3.4 kernel anymore, but I can help you with patching mainline kernel for better H264 and/or HEVC support and bring up ffmpeg based solutions (that includes mpv), if you want.

@jernej - good news: this patch seems to fix the emmc problem - on the eachlink i can now read and write the emmc in a stable way and on the qplus - where it was hanging on boot with emmc enabled in dtb - it does not hang anymore on boot and i can also read and write the emmc

It was not easy at all to come to this point. A lot of new code was written for ffmpeg, cedrus and Kodi to make it work. But since LibreELEC is closed ecosystem, we can afford to make some hacks which would otherwise cause issues with other programs.
 
Anyway, I plan to rework some Cedrus patches these days to remove at least one hack and after that I can try to help you with using that special version of ffmpeg. Reportedly it works fine with unmodified mpv but I didn't test that yet. However, be prepared to pick a lot of patches from latest linux git master. Unfortunately, this is moving target and modified ffmpeg will work with only specific version of Cedrus driver.
 
Once you are able to match ffmpeg and Cedrus driver it's best not to change anything until you have good reason to do so, like extending driver with new features.

@jernej - bisecting in progress - 14 rounds, so it will take a while