S905/X/W/D video acceleration/GPU hw + multi core processing support

[shippy]

Title says all. Please see here my comment (#5) from 1 day ago...can't find a reference on this site:

 

https://www.cnx-software.com/2018/01/24/mainline-linux-on-amlogic-s905-s905x-s912-soc-2018-status-update/

 

So:

 

1. Is there any Armbian wiki or update summary that tells us about progress on video acceleration support ( specifically for Kodi video streaming) and Mali GPU hardware support under Ubuntu desktop?

 

2. Does Ubuntu desktop Armbian distros support SMP multi core processing for this Amlogic series?

 

3. What does it mean to say, e.g., that a S905X/W Android Box (e.g., A95X, MXQ Pro) supports 4K@60/30fps? Does this refer to a single core or multiple ones being supported?

 

4. This leads to whether there is Armbian distros support for Amlogic S905* Ubuntu Multi-seat feature, whereby you can run multiple and concurrent instances of an app with each assigned its own set of I/O ( keyboard-mouse, remote control, HDMI, AV etc.) through Xorg/other driver.

 

There are multiple online references to folks claiming to be running 3-4 concurrent Kodi video streaming instances on a single Linux PC, each with unique channel outputs.

[Tido]

3 hours ago, shippy said:

specifically for Kodi video streaming

did you already search for your questions in the TV boxes section ? https://forum.armbian.com/forum/24-tv-boxes/

 

and also in the download and documentation ?

 

Just so we know where you have already looked at.

[zador.blood.stained]

4 hours ago, shippy said:

1. Is there any Armbian wiki or update summary that tells us about progress on video acceleration support ( specifically for Kodi video streaming) and Mali GPU hardware support under Ubuntu desktop?

No since it is not related to Armbian - we don't work on video acceleration or Kodi integration.

Video acceleration in general is done by other developers, for the mainline kernel its status can be tracked here.

Kodi hardware specific support is up to Kodi developers or other developers interested in this.

[JMCC]

On 13/4/2018 at 4:45 AM, shippy said:

 

2. Does Ubuntu desktop Armbian distros support SMP multi core processing for this Amlogic series?

S905's use SMP, but S912 uses HMP (big.LITTLE architecture). You can google for those terms, and you'll find good explanations about their meaning. That is valid for Armbian as well as any other distro supporting those SoC's.

 

On 13/4/2018 at 4:45 AM, shippy said:

3. What does it mean to say, e.g., that a S905X/W Android Box (e.g., A95X, MXQ Pro) supports 4K@60/30fps? Does this refer to a single core or multiple ones being supported?

That means that it is capable to display 4K resolution (that is, 3,840 pixels wide and 2,160 pixels high), at a framerate of 60 or 30 frames per second, and decode video with those specifications. It has nothing to do with the number of CPU cores being used by the system, but with the video decoding capabilites of another component of the SoC, called VPU (Video Processing Unit). Again, google can give you good definitions about these.

 

On 13/4/2018 at 4:45 AM, shippy said:

4. This leads to whether there is Armbian distros support for Amlogic S905* Ubuntu Multi-seat feature, whereby you can run multiple and concurrent instances of an app with each assigned its own set of I/O ( keyboard-mouse, remote control, HDMI, AV etc.) through Xorg/other driver.

I have never tried that. You can try to configure it, and let us know about the results.

[shippy]

JMCC and Zador,

 

Thanks for good answers. I did check the Amlogic Meson project pages and the BayLibre slides, but it all is still quite dense- I suppose techs are not exactly very communicative beyond their small circle! Not clear to me if the S905* supports "full" hardware video decoding if not encoding, under Ubuntu. They talk about video hardware "support" but then say not yet.

 

I do understand that such video processing *should* take place in the VPU (which may or may not be part of GPU), but then if video hardware acceleration is not supported, then software rendering can take place on the CPU cores instead.

[shippy]

14 hours ago, Tido said:

did you already search for your questions in the TV boxes section ? https://forum.armbian.com/forum/24-tv-boxes/

 

and also in the download and documentation ?

 

Just so we know where you have already looked at.

Yes I did see many threads including:

If you had read them you would have realized they don't answer my questions.

 

Just so you know.

 

[JMCC]

On 13/4/2018 at 9:45 PM, shippy said:

if video hardware acceleration is not supported, then software rendering can take place on the CPU cores instead.

Well, if your question is whether any Amlogic SoC is powerful enough to software decode 4K@30/60 fps, the answer is definitely no. I'm not sure if there is any ARM SoC with such power.  Maybe something like Kirin 970 or Snapdragon 845. The most powerful ARM SoC I own is a Mediatek Helio X20, and it struggles to decode via software AVC 4K@30, with lots of frame skipping; HEVC is really laggy.

 

But that's what VPU's are included in the SoC's for, to avoid using the CPU for those tasks. I don't currently own any Amlogic so I cannot give you details on the current status of VPU video decoding, but I have already ordered a Khadas Vim2, so get back in a couple weeks and I might have more info.

[TonyMac32]

21 hours ago, shippy said:

Just so you know.

 

I am saying this only because I don't want too much time wasted here by talented people who can read:. All of the information we have that you need has been provided.  Mainline has no hardware enc/dec support.  All kernels have software support depending on the application.  

21 hours ago, shippy said:

If you had read them

 

As for "knowing", I know I read that thread while working on an Amlogic TV box.  It answers the questions, or points to where they could be answered.  Read it again.

 

This topic has been satisfactorally addressed in my opinion, if your concern does not seem to be answered in the thread, I propose you research the architecture of ARM systems, there appear to be some foundational issues with your understanding.

 

1 hour ago, JMCC said:

but I have already ordered a Khadas Vim2

 

I can make a csc entry in the build script for that if you like, it should be well supported by the BayLibre patchset.  I was figuring on one for the VIM 1 as well.  The issue you'll have with the VIM 2 is that the GXM is a different GPU than the GX(L,W,etc)

 

[JMCC]

1 hour ago, TonyMac32 said:

the GXM is a different GPU than the GX(L,W,etc)

I knew that GPU is Mali 8xx, while the others have Mali 4xx. And also, I know that Amlogic didn't pay the license for the Linux libmali binaries, so it makes very difficult to have OpenGLES & OpenCL in Armbian .  I know that @balbes150 is making some magic using the Android libs, but I'm not sure how far that approach can reach.

 

On the other hand, I was hoping the VPU part to be very similar to S905X. So far, all the places I have checked show identical video decoding capabilities for S905X and S912.

 

 

1 hour ago, TonyMac32 said:

I can make a csc entry in the build script for that if you like, it should be well supported by the BayLibre patchset. 

You'd make me a happy man if you did so.

[shippy]

2 hours ago, TonyMac32 said:

 

I am saying this only because I don't want too much time wasted here by talented people who can read:. All of the information we have that you need has been provided.  Mainline has no hardware enc/dec support.  All kernels have software support depending on the application.  

 

As for "knowing", I know I read that thread while working on an Amlogic TV box.  It answers the questions, or points to where they could be answered.  Read it again.

 

This topic has been satisfactorally addressed in my opinion, if your concern does not seem to be answered in the thread, I propose you research the architecture of ARM systems, there appear to be some foundational issues with your understanding.

 

 

I can make a csc entry in the build script for that if you like, it should be well supported by the BayLibre patchset.  I was figuring on one for the VIM 1 as well.  The issue you'll have with the VIM 2 is that the GXM is a different GPU than the GX(L,W,etc)

 

I stand by what I said. Searching hundreds of posts under various threads is not very productive, especially if only #1 of my concerns were being addressed.

 

Wouldn't it be nice if the main contributors who already are spending time answering lots of redundant questions start a wiki that is periodically updated to address main developments ? But then read my remark about techs.

 

Those posts can be quite confusing mixing facts with opinions even from well meaning contributors.

 

For instance JMCC (with many admirable contributions) states that 4K@60fps cannot be done by any Amlogic SoC but then says that is what VPUs (part of the SoC) are meant for. 

 

Now he is trying to help but what he really meant was that no Amlogic CPU is that powerful.

 

Of course CPUs need be supplemented by VPU/GPUs for graphics processing; and if these video units are not hardware supported by the OS, then the CPU takes that burden and cannot handle it well.

 

In any case most of my questions ( after #1 question) have been answered in this thread and via further research elsewhere. 

 

Bottom line is that these chip vendors are way behind with Linux kernel updates. Not much progress over last 3 years.

 

Why do they want to hurt their own market as Allwinner foolishly has to save a few pennies, but lose big in growth markets, is their problem.

[JMCC]

27 minutes ago, shippy said:

For instance JMCC (with many admirable contributions) states that 4K@60fps cannot be done by any Amlogic SoC

Sorry, I had typed "software decode" originally, but the word should have been lost in some of the numerous edits I make after writing the posts (English is not my native language, so I need to re-read and change my wording very often). I corrected it in my post.

27 minutes ago, shippy said:

what he really meant was that no Amlogic CPU is that powerful

That is exactly what I meant. I am glad that you understood it in spite of my language mistakes. Maybe the fact that in the following sentence I used the term "decode via software" helped you to read my mind .

[zador.blood.stained]

14 minutes ago, shippy said:

Bottom line is that these chip vendors are way behind with Linux kernel updates. Not much progress over last 3 years.

 

Why do they want to hurt their own market as Allwinner foolishly has to save a few pennies, but lose big in growth markets, is their problem.

Software development takes money and time (which also has a money equivalent).

If you check sunxi (Allwinner), meson (Amlogic) and Rockchip Linux mainlining status then you'll see that there was a lot of progress in non-multimedia related areas. As for multimedia related areas (in Linux) - there are problems and limitations regarding integrating stuff to the kernel, limited, missing or locked by NDAs documentation and also the fact that Android works well enough on those systems already (for people who just want to run Kodi on their devices).

 

Also software development costs more than a few pennies compared to the price of the SoC.

[shippy]

2 hours ago, zador.blood.stained said:

Software development takes money and time (which also has a money equivalent).

If you check sunxi (Allwinner), meson (Amlogic) and Rockchip Linux mainlining status then you'll see that there was a lot of progress in non-multimedia related areas. As for multimedia related areas (in Linux) - there are problems and limitations regarding integrating stuff to the kernel, limited, missing or locked by NDAs documentation and also the fact that Android works well enough on those systems already (for people who just want to run Kodi on their devices).

 

Also software development costs more than a few pennies compared to the price of the SoC.

Compared to potential profits, such software development would be pennies to the dollar: always a matter of comparison, price vs performance.

 

There are reasons RPi has taken off despite high prices, Orange/Banana/ other Pis have not. And they include not just good chipset to board vendor relations, but also market vision, e.g., Amlogic and Rockchip vs Allwinner in the Android Box market.

[TonyMac32]

Well, this is an opportunity cost situation.  Even tens of thousands of Linux guys don't compare to the profits in Android devices.  So, if you're Amlogic, you have a lot more money to gain by putting your effort into new Android devices; money spent on Linux is money that will not net the profits of money spent on Android, and is thus a loss.

 

49 minutes ago, shippy said:

And they include not just good chipset to board vendor relations, but also market vision

 

I worry that "Time's up", so to speak, on RPi.  This last revision is the lamest one yet in terms of features.  It's a bugfix and an "Almost make relevant gains in performance" situation, the most interesting part is the 5 GHz WiFi.  Better thermal is nice, but it's kind of a "Should have been done right the first time" situation (Not that most other guys do it that much better).  Those Broadcom processors are not available to the public, they run Linux as a guest OS under a super-secret firmware on the GPU, etc.  I think Pi had a good vision when it was founded:  today I think it's a gimmick and a prayer.

[shippy]

5 hours ago, zador.blood.stained said:

As for multimedia related areas (in Linux) - there are problems and limitations regarding integrating stuff to the kernel, limited, missing or locked by NDAs documentation and also the fact that Android works well enough on those systems already (for people who just want to run Kodi on their devices).

 

Now here is another area of major confusion. See 3.2 last bullet vs your comment:

https://kodi.wiki/view/supported_hardware

 

Kodi is officially saying that we are better off installing Linux instead of Android on an Android Box !

 

So who can we believe here, given all the hard volunteer work here and on other volunteer forums where very knowledgeable people reside ???

 

Anyways, back to my basic question another way...

 

1. When S905X/W Box vendors say it supports 4K@60/30 fps do they mean it for Android OS 4.4+ only, not Linux?

 

2. With the latest legacy Xenial distro, balbes150 April 6 v5.41 under 3.14.29, how close can we get to 4K@60/30 fps for Kodi 17.6?

 

3. If multiseat Ubuntu can work with v5.41 kind distro, I am more interested in 720p H264/AAC multiple streams.

 

So trying to guestimate what is doable with some overhead as equivalent processing ability regardless of how many CPU/VPU-GPU cores actually get used.

 

3. Is above with single core or with full SMP multicore processing, and/or with full pentacore VPU-GPU processing under v5.41? ( Don't know the extent of VPU hardware support vs CPU software rendering.)

 

[shippy]

2 hours ago, TonyMac32 said:

Well, this is an opportunity cost situation.  Even tens of thousands of Linux guys don't compare to the profits in Android devices.  So, if you're Amlogic, you have a lot more money to gain by putting your effort into new Android devices; money spent on Linux is money that will not net the profits of money spent on Android, and is thus a loss.

 

 

I worry that "Time's up", so to speak, on RPi.  This last revision is the lamest one yet in terms of features.  It's a bugfix and an "Almost make relevant gains in performance" situation, the most interesting part is the 5 GHz WiFi.  Better thermal is nice, but it's kind of a "Should have been done right the first time" situation (Not that most other guys do it that much better).  Those Broadcom processors are not available to the public, they run Linux as a guest OS under a super-secret firmware on the GPU, etc.  I think Pi had a good vision when it was founded:  today I think it's a gimmick and a prayer.

 

I hear you but Kodi says you are better off installing Linux than Android on Android Boxes! See my reply to Zador above, and the useful chart/notes on Android hardware for Kodi updated Feb 18.

 

https://kodi.wiki/view/Android_hardware

 

RPi has always been expensive and the $5 RPi0 was just a joke.

 

The $9 true SBC CHIP went belly up owing to mispricing. $2+ was still affordable and they could have upgraded to multicore with another $2 increase.

 

There were high hopes for Orange Pi Zero but their WiFi chipset and other sojourns into the unknown have dissipated their brand totally.

 

Now it will be interesting to see onion.io Omega 2 at $7.50 competing with the $5-6 ESP32, with way better SBC specs. ESP8266 is a marvel at $1.50, but ESP32 is just hyped, IMHO.

[zador.blood.stained]

5 hours ago, shippy said:

Now here is another area of major confusion. See 3.2 last bullet vs your comment:

https://kodi.wiki/view/supported_hardware

 

Kodi is officially saying that we are better off installing Linux instead of Android on an Android Box !

This should be corrected/expanded: "... better off installing Linux instead of Android ... if you have hardware acceleration support in Linux and available hardware acceleration APIs are supported by Kodi". And my point was that on Android this stuff usually works out of the box and is available through more or less standard Android APIs.

 

5 hours ago, shippy said:

There were high hopes for Orange Pi Zero but their WiFi chipset and other sojourns into the unknown have dissipated their brand totally.

If we are talking about multimedia than a board with only CVBS video output is a joke already for such use cases, and those lower end Orange Pi models have too small RAM amount anyway (IMO) to be useful for Android or Linux with GUI.

[shippy]

22 minutes ago, zador.blood.stained said:

This should be corrected/expanded: "... better off installing Linux instead of Android ... if you have hardware acceleration support in Linux and available hardware acceleration APIs are supported by Kodi". And my point was that on Android this stuff usually works out of the box and is available through more or less standard Android APIs.

 

If we are talking about multimedia than a board with only CVBS video ...

Agreed. 

 

Well Kodi wiki should be more clear, but inserting your qualifiers would make the original statement invalid anyway !

 

Any insights into my above questions (not related to OPi or CVBS)?

[zador.blood.stained]

3 minutes ago, shippy said:

Any insights into my other questions?

Sorry, don't pay much attention to Kodi and 4k video (since I don't own a 4k display).

 

6 hours ago, shippy said:

If multiseat Ubuntu can work with v5.41 kind distro, I am more interested in 720p H264/AAC multiple streams.

Usually it is not possible to run multiple decoding or encoding streams through the hardware VPU (though documentation suggests that simultaneous decoding and encoding is possible).

[shippy]

1 minute ago, zador.blood.stained said:

Sorry, don't pay much attention to Kodi and 4k video (since I don't own a 4k display).

 

Usually it is not possible to run multiple decoding or encoding streams through the hardware VPU (though documentation suggests that simultaneous decoding and encoding is possible).

 I see. Does S905X/W have only one VPU or 5 like GPU cores? With Kodi streaming I just see need for decoding.

 

Btw, Kodi v17+ has dropped support for proprietary APIs (e.g., Amlogic ones) and only uses Android APIs, under Android OS. So if Android OS now supports S905X/W hardware acceleration, then likely Android OS is a better choice than Linux instead.

[zador.blood.stained]

7 minutes ago, shippy said:

Does S905X/W have only one VPU or 5 like GPU cores?

It's logical that it has one VPU, but this VPU has different subengines for different formats (MPEG4, H.265, H.264, ...) and directions (encoding or decoding).

 

Specifications for the S905/S905x AVE contain this

Quote

Supports multiple “secured” video decoding sessions and simultaneous decoding and encoding

but most likely this means that if the engine supports i.e. up to 4k@60fps you may be able to pipe multiple smaller resolution streams through it given that available software libraries support this feature.

[shippy]

5 minutes ago, zador.blood.stained said:

It's logical that it has one VPU, but this VPU has different subengines for different formats (MPEG4, H.265, H.264, ...) and directions (encoding or decoding).

 

Specifications for the S905/S905x AVE contain this

but most likely this means that if the engine supports i.e. up to 4k@60fps you may be able to pipe multiple smaller resolution streams through it given that available software libraries support this feature.

Thanks for this insight...quite a fine print ! Apparently then the HW support for multi-streaming exists.

 

So the answer lies in how the v5.41 legacy Armbian distro works per my questions above. 

[chwe]

12 hours ago, shippy said:

Wouldn't it be nice if the main contributors who already are spending time answering lots of redundant questions start a wiki that is periodically updated to address main developments ? But then read my remark about techs.

the wiki is filled with a lot of useful information..  Multimedia related stuff is just not part of the main development...  @JMCC started to focus on it and I appreciate it.  For me the main goal of the project is still a stable debian/ubuntu. As you figured out by yourself, the whole multimedia stuff is somehow limited for linux on arm.. More or less all SoCs armbian supports (besides the marvell ones) where made for Android devices and therefore all those 'nice specs' you read are often meant for android. 

Update a wiki needs a lot of time. Support over forum needs time and maintaining Armbian needs a lot of time... We're not perfect and there's space for improvement so feel free to contribute.  For example by writing the stuff related to multimedia use cases in the documentation and send it as a PR (which will then show up in docs.armbian.com). 

https://github.com/armbian/documentation 

 

12 hours ago, shippy said:

In any case most of my questions ( after #1 question) have been answered in this thread and via further research elsewhere. 

There's nothing wrong about doing your own research. As for a lot of things opinions and facts are mixed everywhere, so a high google-fu helps to get a broader picture about he situation. 

 

12 hours ago, shippy said:

Bottom line is that these chip vendors are way behind with Linux kernel updates. Not much progress over last 3 years.

I don't think so, as @zador.blood.stained explained for non multimedia related stuff, there's a lot of progress..  And even for the multimedia related stuff, it starts to make fun when you choose the right SoC (e.g. RK3288 where @JMCC did the hard work bringing this to armbian and RockChip delivered the stuff so that it's possible to use it) and probably Allwinner in the future where bootlin brings hardware accelerated video decoding to mainline.  

9 hours ago, shippy said:

Compared to potential profits, such software development would be pennies to the dollar: always a matter of comparison, price vs performance.

I think this is true for android... but not really for linux, the average multimedia/tv box user doesn't care if there's Linux or Android in the background as long as it works.. Only those who want to avoid google products for whatever reason. 

 

It was a good move from the RPi folks to bring up multimedia related stuff quite from the beginning (in terms of selling more devices), in terms of their 'educational goals', doing all this stuff in the blackbox called threadX is a bit questionable.. There's no chance to understand what happens there cause it's closed source. IMO, in terms of opensource RockChip does it better and linux-sunxi does it best (!= Allwinner).

9 hours ago, shippy said:

There are reasons RPi has taken off despite high prices, Orange/Banana/ other Pis have not. And they include not just good chipset to board vendor relations, but also market vision, e.g., Amlogic and Rockchip vs Allwinner in the Android Box market.

The RPi foundation is good in explaining why an RPi is so much better than everything else (no matter if it's true or not)... They manage the community well so that the average RPi user doesn't move to an other SBC and when he moves, he doesn't understand why *random feature* doesn't work out of the box. People forget that this was true for RPi as well in the past... Their backwards compatibility back to the RPi1 is their biggest value but also their biggest problem. The board-design doesn't allow a proper powering and they stick to the VC as long as they don't want to loose everything they benefit from. In terms of their 'educational goal' the RPi is powerful enough, but the group which pays their paychecks will maybe start to look for other boards when their next major update suck too (only 1 USB2 which is responsible for network too, powering through microUSB which I think will start to make problems for their newest version, no cryptoengine and limited to 1GB ram etc.). But cause it is interesting on software side (every bigger software company develops for the RPi when they make something for SBCs, e.g. googles AIY kits, wolfram matematica even microsoft IoT) people may stick to it. 

 

5 hours ago, shippy said:

RPi has always been expensive and the $5 RPi0 was just a joke.

The only thing the RPi is not... is expensive..  Compared to the longterm software-support you get the RPi is cheap as hell. Despite the industrial grade boards, I don't know many boardmakers which deliver a decent BSP kernel over such a long time. 

 

6 hours ago, shippy said:

$5-6 ESP32, with way better SBC specs. ESP8266 is a marvel at $1.50, but ESP32 is just hyped, IMHO.

ESPs are not SBCs (or at least not what I would define as a SBC)... Cause I don't care about bluetooth I should prefere the ESP8266 over the ESP32 (cause cheaper).. But I don't, I prefer to program those things in micropython and 128kb vs. 512kb ram make a huge difference there... It's all about use case. If you only handle one or two sensor, or if you care about power consumption or if you don't want to dig into datasheets on this small things someone wrote an arduino (or micropython) lib accessing the right registers over SPI, I2C for driving those sensors whereas you have to adjust them for a normal Linux useage.  My normal setup is an OPi0 as an IoT server (obviously, I don't use the built in WiFi cause it's crap) for collecting all the data and make it accessible for my phone, notebook etc. and some ESP8266/32 for all my sensor nodes I need. It's all about what you need and not what's most powerful for it's price.. ESPs are long term available and the IoT server software runs on every SBC so I'm more or less independent from boardmakers.

 

 

 

 

[shippy]

29 minutes ago, chwe said:

the wiki is filled with a lot of useful information..  Multimedia related stuff is just not part of the main development...  @JMCC started to focus on it and I appreciate it.  For me the main goal of the project is still a stable debian/ubuntu. As you figured out by yourself, the whole multimedia stuff is somehow limited for linux on arm.. More or less all SoCs armbian supports (besides the marvell ones) where made for Android devices and therefore all those 'nice specs' you read are often meant for android. 

Update a wiki needs a lot of time. Support over forum needs time and maintaining Armbian needs a lot of time... We're not perfect and there's space for improvement so feel free to contribute.  For example by writing the stuff related to multimedia use cases in the documentation and send it as a PR (which will then show up in docs.armbian.com). 

https://github.com/armbian/documentation 

 

There's nothing wrong about doing your own research. As for a lot of things opinions and facts are mixed everywhere, so a high google-fu helps to get a broader picture about he situation. 

 

I don't think so, as @zador.blood.stained explained for non multimedia related stuff, there's a lot of progress..  And even for the multimedia related stuff, it starts to make fun when you choose the right SoC (e.g. RK3288 where @JMCC did the hard work bringing this to armbian and RockChip delivered the stuff so that it's possible to use it) and probably Allwinner in the future where bootlin brings hardware accelerated video decoding to mainline.  

I think this is true for android... but not really for linux, the average multimedia/tv box user doesn't care if there's Linux or Android in the background as long as it works.. Only those who want to avoid google products for whatever reason. 

 

It was a good move from the RPi folks to bring up multimedia related stuff quite from the beginning (in terms of selling more devices), in terms of their 'educational goals', doing all this stuff in the blackbox called threadX is a bit questionable.. There's no chance to understand what happens there cause it's closed source. IMO, in terms of opensource RockChip does it better and linux-sunxi does it best (!= Allwinner).

The RPi foundation is good in explaining why an RPi is so much better than everything else (no matter if it's true or not)... They manage the community well so that the average RPi user doesn't move to an other SBC and when he moves, he doesn't understand why *random feature* doesn't work out of the box. People forget that this was true for RPi as well in the past... Their backwards compatibility back to the RPi1 is their biggest value but also their biggest problem. The board-design doesn't allow a proper powering and they stick to the VC as long as they don't want to loose everything they benefit from. In terms of their 'educational goal' the RPi is powerful enough, but the group which pays their paychecks will maybe start to look for other boards when their next major update suck too (only 1 USB2 which is responsible for network too, powering through microUSB which I think will start to make problems for their newest version, no cryptoengine and limited to 1GB ram etc.). But cause it is interesting on software side (every bigger software company develops for the RPi when they make something for SBCs, e.g. googles AIY kits, wolfram matematica even microsoft IoT) people may stick to it. 

 

The only thing the RPi is not... is expensive..  Compared to the longterm software-support you get the RPi is cheap as hell. Despite the industrial grade boards, I don't know many boardmakers which deliver a decent BSP kernel over such a long time. 

 

ESPs are not SBCs (or at least not what I would define as a SBC)... Cause I don't care about bluetooth I should prefere the ESP8266 over the ESP32 (cause cheaper).. But I don't, I prefer to program those things in micropython and 128kb vs. 512kb ram make a huge difference there... It's all about use case. If you only handle one or two sensor, or if you care about power consumption or if you don't want to dig into datasheets on this small things someone wrote an arduino (or micropython) lib accessing the right registers over SPI, I2C for driving those sensors whereas you have to adjust them for a normal Linux useage.  My normal setup is an OPi0 as an IoT server (obviously, I don't use the built in WiFi cause it's crap) for collecting all the data and make it accessible for my phone, notebook etc. and some ESP8266/32 for all my sensor nodes I need. It's all about what you need and not what's most powerful for it's price.. ESPs are long term available and the IoT server software runs on every SBC so I'm more or less independent from boardmakers.

 

 

 

 

 

Good insights all. 

 

I was calling the Omega2 an SBC, not ESP32. My point is that Omega2 is a much better machine price-performance wise and does all ESP32 stuff and more, except BT.

 

- So you are saying that Armbian multimedia support wise per JMCC, RK3288 is a better choice than S905/912? 

 

- How about the RK3229 v S905X/W?

 

Does RK 3288/3229 have SMP multicore or big.LITTLE support under Armbian?

 

I have been hearing online that RK is more aggressive than Amlogic with open source and kernel updates. I did notice JMCC thread(s) on RK but wasn't sure...

 

I would like to use Armbian on an Android Box simply because it then becomes a server, IoT device, WiFi AP/mesh, USB2+ OTG master/slave port(s) plus Kodi streamer all in one at a very good price-performance point.

 

Not to mention Alexa/GA SDKs voice activation. Even Android over Linux via alpha Anbox.io snaps. Ubuntu based distro should also support Multi-seat. And if S905X/W VPU supports multi streaming ( per above Zador comment), it is a good bet RK3288 VPU also does, competitively- maybe even RK3229 VPU as well.

 

With Android OS all I will get is good Kodi streaming. And Android apps (no dedicated use), maybe GA in dev mode ( Android TV OS is far away.)

[chwe]

1 hour ago, shippy said:

- How about the RK3229 v S905X/W?

 

Does RK 3288/3229 have SMP multicore or big.LITTLE support under Armbian?

I guess you think 3329? SoCs where development happens opensource for RK are 3036 (I don't know any SBC based on it). Rk3288 (e.g. tinker), Rk3329 (Rock64) and RK3399 (a lot of boards will pop up this year). 

http://opensource.rock-chips.com/wiki_Main_Page

And the 3399 is the only one with a big.LITTLE architecture.. 

https://github.com/armbian/build/blob/2a1d686d41ba1345b1b595b53576017c520ebc9d/config/kernel/linux-rockchip-default.config#L468

So, SMP should be supported (this one is for the RK3288, I think this should count for others too).

 

t's over my knowledge to compare Armlogics to RK in terms of multimedia/kodi use-cases. I don't own a TV at all..  It's definitively not my use-case for SBCs. I would count on @JMCC opinion, cause he pushes this stuff to armbian. 

 

1 hour ago, shippy said:

I would like to use Armbian on an Android Box simply because it then becomes a server, IoT device, WiFi AP/mesh, USB2+ OTG master/slave port(s) plus Kodi streamer all in one at a very good price-performance point. Not to mention Alexa/GA SDKs voice activation. Even Android over Linux via alpha Anbox.io snaps.

That's what I call the 'Eierlegende Wollmilchsau'.. And @TonyMac32 will laugh once again.. None of the currently available boards will fit perfect in this use-case. The best server boards aren't made for multimedia and vice versa. I guess, and that's just a guess since I've no proof that the upcoming RK3399 boards might fit good for those kind of use-cases (USB3/pci for attached storage), open source available linux drivers for the multimedia related stuff and maybe a powerful enough CPU cluster for 'Android over Linux' tests. 

But I would split this into two boards. Especially when you plan to open your server to public (not only local network), security becomes more important and therefore IMO I would prefer a mainline kernel over a BSP kernel (but mainline is often problematic in terms of multimedia stuff. As said.. the 'Eierlegende Wollmilchsau' comes back.. ). If the TV box then still needs to be a linux one, I think, RK3288 based ones could be best for that at the moment (but, to make it clear, that's not my field so you might have to look for people who does this stuff. I don't know if someone gave Kodi a try since @JMCC optimized armbian on the RK3288 for this kind of tasks). And a second board which is known to perform well for server use cases, there you should dive into the topics about NAS use case and OMV written by @tkaiser in the: https://forum.armbian.com/forum/26-research-guides-tutorials/

section of our forum (there's a lot of nice benchmark stuff written, background information where he explains why and what is important when it comes to server performance). Obviously this setup will be a bit more expensive to buy, but I think it's easier to maintain and in terms of security it's more save.

I've a Odroid HC1 as fileserver/nas, an OPi0 for IoT related stuff (I do sometimes stupid things with IoT, I don't want to harm my fileserver by doing stupid things ) and a Tinker (cause it was cheap, and it might be useful to have a 'RPi-compatible' board at hand even when the RPi related stuff doesn't work out of the box).  

 

1 hour ago, shippy said:

My point is that Omega2 is a much better machine price-performance wise and does all ESP32 stuff and more, except BT.

I had a (quick) look at the Omega2 when it was announced and though it could be a cool device.. It still can be, I lost a bit track of progress they made in the last months but what counts for all this stuff is software support and that's something where the ESP shines cause it is what you called 'hyped' - I would call it popular.   

If you look into armbians history, the reason @Igor founded the project was cause he wasn't happy with the software support his first SBC had.. I can't say if the Omega2 guys can convince enough devs to bring up all the nice features their board could be capable to do. Something RPi shines.. Even when some of the tutorials which are posted in blogs, articles etc. are crap, their user base spread so many 'good words' about RPi that the average joe (in western countries) think about RPi first when people talk about SBC or 'open source IoT' or or or (despite the fact that their 'opensourceness' is weak compared to projects like the beagle bone or more or less every H3 based SBC where 'full' schematics are available and the whole OS can base on a blob free mainline kernel). 

[JMCC]

I think the upcoming RK3399 boards have the potential to be very versatile, so you can use them for many different purposes. But as @chwe pointed out, I don't think it is a good idea to use one single board for tasks as different as a Kodi TV box and a public server. You normally dedicate a SBC for a purpose, and that is the good thing about them, that since they are very affordable, you can buy one for web server purposes, another for IoT, another for media playing, etc.. Then, having a versatile board has the advantage that can re-use them, (e.g. when you get tired to use it as a web server, you can turn it into a music player for your garage, make a multimedia toy for your kids, or use it as a crypto miner and earn about five cents a week).

 

As for my experiments with multimedia, I wouldn't call them "integrate something into Armbian". That's what real devs do. I just have some fun with the board, and share it with others. Of course, that doesn't mean that real devs don't have fun too, only that their work is more reliable and professional.

 

So far, we've made good progress with RK3288 and Exynos 5422. Both have full OpenGLES, WebGL, OpenCL, and HW video decoding support. By "full", I mean that it is at least as good in Armbian as it is in Android, or even better in some cases (yes, believe it or not). The only exception could be Exynos 5422's HW video decoding, which works slightly better in Android (though, in both cases, it is not too good, VPU is the weakest point of that SoC).

 

I'd like to work in Amlogic VPU stuff too (I don't think GPU is worth paying too much attention for those SoC's). I think the most promising board in that sense is Odroid C2, but I don't have one nor I'm going to buy it for the time being. I ordered a Khadas Vim2, let's see what we can get out of it.

 

RK3328 (Rock64, Renegade) looks also very promising VPU wise, and it could work easily with very few modifications from what we already have. But it is not in my shopping list either. On the other hand, I will very likely get a RK3399 when they are released, and try to make everything work at least as well as RK3288 and Exynos 5422.

 

For last, I acknowledge that all the multimedia stuff for those two SoC's is scattered in long forum threads, so I'll try to put everything together in a single thread, with links to "download-and-run" scripts that can configure it automatically.

[chwe]

4 minutes ago, JMCC said:

I'd like to work in Amlogic VPU stuff too (I don't think GPU is worth paying too much attention for those SoC's). I think the most promising board in that sense is Odroid C2, but I don't have one nor I'm going to buy it for the time being. I ordered a Khadas Vim2, let's see what we can get out of it.

As soon as it comes to the magical "Kodi" people need at least OpenGL ES 2.0 support. That's why people think, cool mali works on my *random SBC*.. I can use Kodi now!!! 

 

8 minutes ago, JMCC said:

RK3328 (Rock64, Renegade) looks also very promising VPU wise, and it could work easily with very few modifications from what we already have.

would be cool, cause boards are relatively cheap, and USB3 is a nice feature when mixing local fileserver with multimedia player (as said, I don't recommend mixing up things, but when it only runs local it might be okay).

 

14 minutes ago, JMCC said:

As for my experiments with multimedia, I wouldn't call them "integrate something into Armbian". That's what real devs do. I just have some fun with the board, and share it with others. Of course, that doesn't mean that real devs don't have fun too, only that their work is more reliable and professional.

should we call it: Adress topics which weren't on a high priority for armbians maintainer but often wished by (parts) the community?  

 

18 minutes ago, JMCC said:

For last, I acknowledge that all the multimedia stuff for those two SoC's is scattered in long forum threads, so I'll try to put everything together in a single thread, with links to "download-and-run" scripts that can configure it automatically.

*thumb up* bring this stuff summarized in one thread will make it easy support over forum to explain those questions.  

[shippy]

2 hours ago, chwe said:

As soon as it comes to the magical "Kodi" people need at least OpenGL ES 2.0 support. That's why people think, cool mali works on my *random SBC*.. I can use Kodi now!!! 

 

would be cool, cause boards are relatively cheap, and USB3 is a nice feature when mixing local fileserver with multimedia player (as said, I don't recommend mixing up things, but when it only runs local it might be okay).

 

should we call it: Adress topics which weren't on a high priority for armbians maintainer but often wished by (parts) the community?  

 

*thumb up* bring this stuff summarized in one thread will make it easy support over forum to explain those questions.  

Thanks for your remarks !

[shippy]

17 hours ago, JMCC said:

I think the upcoming RK3399 boards have the potential to be very versatile, so you can use them for many different purposes. But as @chwe pointed out, I don't think it is a good idea to use one single board for tasks as different as a Kodi TV box and a public server. You normally dedicate a SBC for a purpose, and that is the good thing about them, that since they are very affordable, you can buy one for web server purposes, another for IoT, another for media playing, etc.. Then, having a versatile board has the advantage that can re-use them, (e.g. when you get tired to use it as a web server, you can turn it into a music player for your garage, make a multimedia toy for your kids, or use it as a crypto miner and earn about five cents a week).

 

As for my experiments with multimedia, I wouldn't call them "integrate something into Armbian". That's what real devs do. I just have some fun with the board, and share it with others. Of course, that doesn't mean that real devs don't have fun too, only that their work is more reliable and professional.

 

So far, we've made good progress with RK3288 and Exynos 5422. Both have full OpenGLES, WebGL, OpenCL, and HW video decoding support. By "full", I mean that it is at least as good in Armbian as it is in Android, or even better in some cases (yes, believe it or not). The only exception could be Exynos 5422's HW video decoding, which works slightly better in Android (though, in both cases, it is not too good, VPU is the weakest point of that SoC).

 

I'd like to work in Amlogic VPU stuff too (I don't think GPU is worth paying too much attention for those SoC's). I think the most promising board in that sense is Odroid C2, but I don't have one nor I'm going to buy it for the time being. I ordered a Khadas Vim2, let's see what we can get out of it.

 

RK3328 (Rock64, Renegade) looks also very promising VPU wise, and it could work easily with very few modifications from what we already have. But it is not in my shopping list either. On the other hand, I will very likely get a RK3399 when they are released, and try to make everything work at least as well as RK3288 and Exynos 5422.

 

For last, I acknowledge that all the multimedia stuff for those two SoC's is scattered in long forum threads, so I'll try to put everything together in a single thread, with links to "download-and-run" scripts that can configure it automatically.

Thanks much for your details. I agree fully with your CPU remark.

 

If you could comment on my 4K@60/30fps questions numbered above for RK or Amlogic, I would appreciate much

Btw my Android Box Linux server would have light duty, running with OpenWrt.

[TonyMac32]

4 hours ago, JMCC said:

I think the most promising board in that sense is Odroid C2,

 

The C2 is the same SoC as the NanoPi K2 (and the same evaluation board design), and the same family as the Le Potato and VIM 1, I believe that all share the same video decoding hardware block.  Any of them should provide that ability assuming the kernel supports it.  For now Mainline does not, however I think it's on the to-do list for BayLibre.