jernej

Presence of SPI NOR gives you possibility to do just that. You must build SPI enabled U-Boot and burn it on SPI chip. Then you can boot from USB, network, etc. But 2 MB is far too litle to boot full OS. AFAIK there is no tutorial how to put U-Boot on chip.

Simple - drivers responsible for multimedia usually arrive last. For example, mainline doesn't have H3/H2+ drivers for HDMI video & audio, TV out and HW video decoding. Some initial patches exists for HDMI video & audio, but they won't be mainlined soon. I think Armbian includes patches at least for HDMI video.

Please don't take everything about VLC wiki too literal. Of course they may talk specifically about ARM platform and there you can trust them. When I was talking that libvdpau-sunxi (VDPAU implementation for H3) doesn't support mpeg4 very well I didn't have VLC in mind. I was talking about library. HW supports this codec pretty well, other programs which know how to use VDPAU might support it just as well, but VDPAU implementation is not complete. What story do you have in mind? WIFI is completely different thing. If driver and chip are good enough then it should work good. For example, USB dongle based on ath9k (Atheros) chip works extremely well, but if you are talking about already present chips (Realtek) on OrangePi boards, I must disappoint you. They are usually bad. From what I read, chip on OPiZero is not very good either, but I'm not sure if that is completely true.

AFAIK mpeg4 is only partially implemented. If it doesn't work for you, try to use SW decoding instead. Just run mpv without any argument/configuration file.

I also needed some time to understand how exactly everything works. Problem here is that in PC world (x86/amd64) nobody speaks precise enough. For example, chip on graphic card is usually called GPU. However in reality it is much more. Calling it GPU is similar that calling H3 chip CPU. GPU is just graphic processor, which takes care for 3D and sometimes also for 2D. Usually it is accessed through OpenGL (ES) or DirectX API. Another part of this chip is HW unit which helps decoding video. Most of the time it has nothing to do with GPU except it is part of the same chip. Of course, you need some kind of output, for example HDMI. For that there is yet another HW unit which takes care for that independent of GPU. There could be another HW units present on the same chip, I don't have full knowledge of contemporary graphic chip design. For example, H3 has also HW composer. This takes two images and based on some rules like plane size, transparency, etc. produces output image which is at the end shown on your screen. Please educate yourself about this. There is a lot of interesting literature on the internet. He meant that VLC wiki is mostly x86/amd64 oriented, which is to be expected, because arm platform is rarely used for desktop. I'm telling you that I don't know. It is best just to try out. And of course you need rendering (which means displaying video, not some fancy 3D effects or whatever) otherwise you would not see anything. As mentioned before, using HW composer unit, rendering (displaying video) is basically for free (no CPU load), but if you use USB output or force SW rendering, then this doesn't work and CPU is definetly pretty involved. I don't see any confusion. Because there is no program which would support CedarX out of the box there is no point of trying to use it. Unless you want to spend time to learn about this interface and modify another program to use it. VDPAU is already prepared, you just use it. Maybe the biggest misunderstanding here is that VDPAU implementation for H3 is not complete. It doesn't implement VC1 codec and has incomplete MPEG4 implementation (possible issues with xvid, divx, etc.). However, MPEG1/2, H264 and H265 are pretty stable and there should not be any issues with them. This VDPAU implementation is missing some other features, which some programs might take them for granted, so they can have troubles using it. From what I read here on this forum, VLC falls in this category. I'm not really sure what problems it have.

Why people every time think on worst possible option? It is more likely that they just forget to disable some clocks for some HW units which still run and eat power.

It is unclear to me if this is HW or SW limitation. When Allwinner updated their driver for video, they didn't implement this option. There is also no detailed datasheet so someone would need to invest some time to figure this out. Nobody has done that as far as I know. Let me be clear, this is meant only for native outputs (HDMI and TV out), extension through USB are independant. Exactly. Depends on the codec, resolution, framerate, so there is no easy answer. Just test it when you get HW. Please don't confuse HW decoding and HW rendering. VDPAU supports HW decoding and HW rendering, where Allwinner library (CedarX) supports only HW decoding and no rendering at all. You can only use HW rendering on native outputs (HDMI and TV out). For USB based ones, you would need SW rendering anyway. I'm not sure if VDPAU supports decoding multiple streams at the same time. I guess it does. Just force SW rendering and you are done. But anything done in SW raises CPU load. Yes, you can run Allwinner library under Armbian, but you can't use it with any program out of the box. Because of that it is not even present on Armbian. You have to find it by yourself on the internet and adapt wanted program to work with it. It is not worth the effort. Just test VDPAU first.

No, GPU doesn't help anything with desktop unless it is using OpenGL ES.

Which driver do you have in mind? For HW accelerated video decoding or for multiple video outputs? Well, there is another, Allwinner provided library for video decoding, which can't be used anywhere unless you write your own program, because it doesn't use any standard interface. Allwinner library claims that it can be used with multiple streams at the same time, but I didn't see any proofs for that. libvdpau-sunxi is the only other library, which is written by community, it's open source and uses standard interface, which means it can be used with most other programs. However, it doesn't implement interface fully, so some programs might have some issues with it. I think VLC falls into this category. CPU is definetly capable of decoding one stream by CPU if resolution is not too big. I didn't make any tests for resolution or how many streams is possible to run . Currently I don't have HW at hand to test any of this. It is recommended program for libvdpau-sunxi. Of course you might find another one which is working fully, but this is tested the most. You must know that usb 2.0 has limited throughput, around 35 MiB/s. For 1280x720 @ 60Hz in YUV420 color space (1.5 B/pixel) you need ~80 MiB/s of throughtput. A top of that, I don't know if your output USB device supports YUV420 color space. If it supports only RGB, it means 3 B/pixel, which means 2 times of YUV420 throughput. But because I don't know nothing about USB output devices, I might be completely mistaken and they found some kind of efficient compression which enables streaming such resolutions. But it might pose additional CPU load.

Yes, GPU is used only for OpenGL ES, nothing else, so it doesn't help you. H3 has support for HW accelerated decoding via libvdpau-sunxi library. I'm not sure if it supports decoding multiple stream at the same time, but one thing is sure. HW accelerated rendering is supported only on native screens, e.g. HDMI or TV out, not on screens attached through USB. Everything you describe is perfectly doable if you limit yourself to 1 output and 1 stream. Everything else is just a guess until some experiments are done. BTW, OPiZero has only TV out, no HDMI. TV out is limited to standard PAL or NTSC resolution. With current H3/H2+ TV out driver you can't select another resolution. I'm very skeptical about your goals, but you can always prove me wrong. P.S.: A20 has compeletely different video HW and driver has support for at least screen mirroring, probably even for dual display. That is not the case for H3.

You honestly making assumption base on completely different architecture? Making assumptions is usually bad, making them based on completely unrelated HW is even more bad. Oh, BTW, GPU doesn't do video decoding, unless you abuse shaders (not the case here). Yes, you can run multiple players, but AFAIK VLC currently can't use HW acceleration for decoding, but mpv can. However, I don't think that libvdpau-sunxi can be used for multiple streams at the same time. I'm also not sure how many streams 4 ARMv7 cores are capable of decoding at the same time. I would guess two at the most, if resolution is low enough. Maybe it is time to make some tests instead of making assumptions? AFAIK you are the first with such requirements. First, you can have only one HDMI and one TV out (I checked datasheets). While fex file allows you to initialize (enable) both of them, you can select only one as the output. Maybe there is some way to activate another through ioctl interface. But, unfortunatelly, there is one big issue if both outputs are enabled at the same time. HDMI output will show artifacts every 15 seconds or so. I suggest you test this first - just enable TV in fex file and watch HDMI output for a few minutes. It might be that this won't be an issue with your setup, because you don't need GPU, but anyway, test it first. Next test would be if you can actually run so many streams. I would say that you should open few different streams using mpv and see if there are any issues. If this is still ok, then you can try to find a way to have both outputs active at the same time. Based on what I saw in the driver, I doubt, but I can be wrong.

I think the best way would be to reencode video on a PC or a laptop. For example, you can use ffmpeg and instruct it to copy over audio while you define 8 bit video. I don't know exactly what command to use, search the net for details.

You mean disabling boot screen (Armbian logo)? Not sure why this bothers you, except for maybe slightly lower power consumption. This is set up by U-Boot and Linux kernel has nothing to do with it, e.g. there is no process or driver active which uses screen.

@zador, maybe a multimedia subsection should be made with a big red warning saying "GPU doesn't decode video" with the link to http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/ This is most detailed description I could find in datasheet: Obviously, 10 bit HEVC is not mentioned anywhere. Of course they might just forget to state it, but until I see working 10 bit decoding, I will claim that HW acceleration of 10 bit HEVC is not possible. I'm not sure if CPU is fast enough to do it in SW. @hojnikb, maybe because they wanted to join 64 bit ARM hype? Easy, take H3 and change 32 bit core with 64 bit, update Mali cores and you are done. As you may noticed, sales are fuelled with marketing bullshit instead of common sense.

Where did you get an idea that H5 is capable of decoding 10bit hevc? Datasheet doesn't mention this capability. Afaik, vpu unit is same as in H3. However, it might be possible that CPU is powerful enough to SW decode it fast enough, but then you must count on higher temperature. Yes, SW decoded, but I'm not sure if I put check correctly for that. Mostly what zador said. U-Boot is horrible, not clear if GPU drivers from the net would work or would I need to wait for Allwinner ones, only community VPU drivers are available, which means I would basicly need to rewrite all Kodi support... Currently I don't see that it would be feasable to make OpenELEC support until mainline kernel is good enough. Fortunatelly, it is almost same as H3 with 64 bit cores.

No there is not and will not be for some time. Multitude of reasons, really. Are you saying that H3 image works on H5? That would be extremely interesting.

While exact differences between H3 and H2+ are a bit unclear, I can assure you that H3 was never advertised as capable of decoding 4K H264, only H265. You can check that in datasheet. I think I tried once and it wasn't good. But then again, you have lower resolution, so it might still work. Which program do you intend to use for video conversion? It has to support VDPAU. Precompiled programs for ARM usually don't have support enabled because VDPAU is not used on ARM anywhere, not even on Tegra, except here. BTW, HDMI is output and has nothing to do with HW decoding, they are two separate units. Actually, also GPU has nothing to do with HW decoding and are two separate units. You are asking about VPU (video processing unit).

Please check this code: https://github.com/jernejsk/linux/blob/hdmi_wip/drivers/video/sunxi/disp2/hdmi/hdmi_edid.c#L75-L193 Around 15 variables... This means that it would be tedious to do so and it doesn't take into account the fact that monitor can be replaced with another one. Please note that also clocks must be set properly. One way to achieve this is that they are not touched within kernel. IMO, it is better to just leave BSP kernel as it is and concentrate on the mainline.

Current H3 build with device tree info included is less than 512 KiB in size. U-Boot for H5 might be a little bigger due to larger instructions and additional FW. But even if it is twice in size, it will still fit. So this flash is really U-Boot only. Kernel is definetly at least few MiB in size. Oh, having U-Boot in flash enables usage of GPT partitions on other storage devices. Allwinner boot procedure has unfortunate consequence of breaking GPT partition table (at least without hacks).

This is explained already in OPi PC2 topic pretty well. Short summary - it enables bios like functionality. U-Boot with proper device tree file can be threated like bios. It support plethora of boot options and best of all, OS images can become board agnostic (universal), just like on PC, because board specific bits are contained on flash chip.

True, but why would they cripple TV out unit? Trying doesn't hurt.

If you feel like hacking kernel, you can try to port these values: https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/tv/de_tve_sun8iw11.c#L300-L463 But AFAIK nobody really tried them, so I can't guarantee any success.

Serial is not same as SID. SID is special storage for one time programmable data (OTP) also known as eFuse (you can change it too). Many different things can be stored there, calibration factors among the others... I'm not sure if this data is exposed via procfs or sysfs.

Mentioned link has discussion about issues with hw acceleration (libvdpau-sunxi). Anyway, you must forget anything you know about video on Raspberry Pi and start learning again. OpenMAX is rarely used outside RPi and Android. VDPAU is used here.

Why did you open new topic? https://forum.armbian.com/index.php/topic/3100-no-usable-video-on-orange-pi-pc-using-vlc/