PINE A64: 64-bit processor, supports up to 2GB of RAM and can output 4K
#31
Ok. So it's basically (and maybe exclusively) an ethical problem, which grounds on the faults and ignorance of Allwinner, which they stated in the beginning of the XBMC story, when these devices popped up.
To sum up, my interpretation from what I've read in Kodi dev's posts, that allwinner support will only happen, when someone new appears and takes this task.

What I personally prefer on the allwinner devices is, that they are basically good hardware, which suit on the Kodi task, and that kodi may run on them with open source and blob-less software (expect Mali for sure), if someone finishes the task. Efforts startet already. We must stop counting on help from allwinner. We won't get it.

I ack you regarding your last GPL statement btw.

Regards
rellla
Reply
#32
(2016-07-04, 10:12)rellla Wrote:
(2016-06-15, 13:20)noggin Wrote: Allwinner = Fail when it comes to Kodi...
...Is there anything, that can help changing mind? Anything, that linux-sunxi community can help with?

The linux-sunxi community could write open source license compliant VAAPI or VDPAU backend wrappers for Linux (and a MediaCodec API codec wrapper for Android) which legally abstract system libraries and drivers.

Today you really need to use one of these standard APIs to be supported, and if AMD and Nvidia can use these APIs with closed source libraries and drivers then so could Allwinner. When and if Kodi can simply use existing open APIs like VAAPI or VDPAU to decode videos on Allwinner hardware and not violate any open sources licenses doing so, then everyone will be happy.

But you can still not violate any open source licenses when doing the implementation for Allwinner, which most easilty avoided by not mixing closed source and open source in the same code project.
Reply
#33
The linux-community did write an open source compliant backend for VDPAU based on reverse engineering https://github.com/linux-sunxi/libvdpau-sunxi. This exists for a long time now. But i feel kodi developers don't recognize that or think there is something mixed up with allwinner's code or it is just not working?! Not sure, if i am right in claiming that.

We don't use the old GPL violating blobs nor do we use or look into the released so called (GPL compliant?) media-codec. This is, because we (the linux-sunxi community) are just not interested in any code for the video engine we got from Allwinner. We have our own GPL compliant code, that let's us use hardware accelerated video decoding. And we have that since 2013 now.

It's technically possible to use this piece of software with kodi, but it needs some adaptions. We cannot use it directly as a VDPAU backend, because KODI uses the nv_gl_interop feature. This is missing on ARM, because we have OpenGL/ES here and btw. vdpau wasn't designed to be used on arm anyway.
We have a libvdpau-backend, and now a few people started, to imitate the interop feature with gles. User mosterta has worked on that and is still working on that afaik. https://github.com/mosterta?tab=activity http://forum.kodi.tv/showthread.php?tid=254202
(adapted) Kodi with an (gles) adapted vdpau backend is one way we can succeed. Another one would be, to drop the vdpau idea and write our own decoder class, using the knowledge of reverse engineering, that is implemented in the libvdpau-sunxi backend already.

We have everything there, to get a gpl compliant kodi integration. It just has to be put together. And except for mali (which other platforms also depend on) we then have a real "open" integration. "Open" in the meaning in having not any blob for the video decoder (neiter on kernel nor on userland side). Is there any other platform out there, that has this advantage?

I'm not sure, if this facts are all publically known. I admit, that we have to do some clean-up-work in our linux-sunxi wiki, too...

Regards
rellla

PS: mpv, mplayer and a few others work very fine with libvdpau-sunxi already.
Reply
#34
(2016-07-04, 11:39)rellla Wrote: We have our own GPL compliant code, that let's us use hardware accelerated video decoding. And we have that since 2013 now.

It's technically possible to use this piece of software with kodi, but it needs some adaptions. We cannot use it directly as a VDPAU backend, because KODI uses the nv_gl_interop feature. This is missing on ARM, because we have OpenGL/ES here and btw. vdpau wasn't designed to be used on arm anyway.

....

Another one would be, to drop the vdpau idea and write our own decoder class, using the knowledge of reverse engineering, that is implemented in the libvdpau-sunxi backend already.
Maybe the best idea would be to port that code to native OpenMAX codecs for Allwinner? OpenMAX codecscan be made compatible with OpenGL & OpenGL ES, ARM & x86, Linux & Android.

https://www.khronos.org/openmax/

And by that I am not suggesting to just write a OpenMAX wrapper for the VDPAU backend, but instead to actually make native OpenMAX codecs for Allwinner which does not rely on VDPAU at all.

(2016-07-04, 11:39)rellla Wrote: We have everything there, to get a gpl compliant kodi integration. It just has to be put together. And except for mali (which other platforms also depend on) we then have a real "open" integration. "Open" in the meaning in having not any blob for the video decoder (neiter on kernel nor on userland side). Is there any other platform out there, that has this advantage?
Intel does with with VAAPI for hardware video acceleration (and graphics acceleration) on most of its GPUs, they have gone almost completly open source with the exception of a few specific newer Intel GPUs like Intel Skylake & Broxton which require graphics firmware blobs.

https://www.freedesktop.org/wiki/Software/vaapi/

It should however be noted that VAAPI, like VDPAU, is designed for x86, not ARM. Which is why I suggested OpenMAX instead of VAAPI, and strongly suggest to checkout OpenMAX for Allwinner.
Reply
#35
But all of this still relies on someone stepping up and wanting to be a Kodi dev / maintainer for the platform. Until this happens it's kind of irrelevant isn't it?

Kodi devs do this in their spare time, because they want to contribute to the development of the application. If nobody wants to do this for Allwinner platforms - then I guess it won't happen...
Reply
#36
(2016-07-04, 10:44)rellla Wrote: Ok. So it's basically (and maybe exclusively) an ethical problem, which grounds on the faults and ignorance of Allwinner, which they stated in the beginning of the XBMC story, when these devices popped up.
To sum up, my interpretation from what I've read in Kodi dev's posts, that allwinner support will only happen, when someone new appears and takes this task.

What I personally prefer on the allwinner devices is, that they are basically good hardware, which suit on the Kodi task, and that kodi may run on them with open source and blob-less software (expect Mali for sure), if someone finishes the task. Efforts startet already. We must stop counting on help from allwinner. We won't get it.

I ack you regarding your last GPL statement btw.

Regards
rellla

Not entirely. At one point the driver support that was available was buggy and had patchy compatibility (i.e. video that played fine on other platforms didn't on the Allwinner stuff when used with the drivers that were released ISTR) Their closed stuff WOULD play the same content ISTR.
Reply
#37
(2016-07-04, 12:58)noggin Wrote: But all of this still relies on someone stepping up and wanting to be a Kodi dev / maintainer for the platform. Until this happens it's kind of irrelevant isn't it?
Kodi devs do this in their spare time, because they want to contribute to the development of the application. If nobody wants to do this for Allwinner platforms - then I guess it won't happen...
Fullack. But the very first step would be, to find people that want to have some solution at all. If nobody cares about sunxi, it's wasted time for anyone. The main reason why I joined this discussion was, that I just want to get rid of that "Bah, bad allwinner, GPL violator, everything is shit, f**k off" - mentality. Therefore it's necessary to know about the work of linux-sunxi - and that it has NOTHING to do with Allwinner code. Time to stop flaming and look forward imho. If nobody cares, ok. It's people's choice. To don't get me wrong, I don't want to whitewash Allwinner's reputation. The story is known. We just don't need them anymore to finish this task. And we don't need their software.

@RockerC: I'm not familiar with OpenMax. This may be another way. VDPAU is very limited. Especially because it will ever remain a "hack" on ARM. If and once the open source implementation of the video decoding engine finds it's place in the linux kernel as a v4l2 mem2mem device, how could this be used with kodi?

Regards
rellla
Reply
#38
(2016-07-04, 13:36)rellla Wrote:
(2016-07-04, 12:58)noggin Wrote: But all of this still relies on someone stepping up and wanting to be a Kodi dev / maintainer for the platform. Until this happens it's kind of irrelevant isn't it?
Kodi devs do this in their spare time, because they want to contribute to the development of the application. If nobody wants to do this for Allwinner platforms - then I guess it won't happen...
Fullack. But the very first step would be, to find people that want to have some solution at all. If nobody cares about sunxi, it's wasted time for anyone. The main reason why I joined this discussion was, that I just want to get rid of that "Bah, bad allwinner, GPL violator, everything is shit, f**k off" - mentality. Therefore it's necessary to know about the work of linux-sunxi - and that it has NOTHING to do with Allwinner code. Time to stop flaming and look forward imho. If nobody cares, ok. It's people's choice. To don't get me wrong, I don't want to whitewash Allwinner's reputation. The story is known. We just don't need them anymore to finish this task. And we don't need their software.
Yes - I think if this had happened a couple of years ago when Allwinner looked to be a great potential option things would be different. But with AMLogic support so positive that's where the developers have gone. Until someone decides that Allwinner is worth investing their time and effort in I suspect it will be stuck in stalemate.

Quote:@RockerC: I'm not familiar with OpenMax. This may be another way. VDPAU is very limited. Especially because it will ever remain a "hack" on ARM. If and once the open source implementation of the video decoding engine finds it's place in the linux kernel as a v4l2 mem2mem device, how could this be used with kodi?

Think OpenMax may be the approach used by the Raspberry Pi OMXPlayer option (there is also MMAL as an option on Kodi on the Pi)
Reply
#39
(2016-07-04, 13:36)rellla Wrote: @RockerC: I'm not familiar with OpenMax. This may be another way. VDPAU is very limited. Especially because it will ever remain a "hack" on ARM. If and once the open source implementation of the video decoding engine finds it's place in the linux kernel as a v4l2 mem2mem device, how could this be used with kodi?
Yes you should deffinitly checkout OpenMAX (often abbriviated as "OMX" which is nice to know when searchning), starting with wikipedia https://en.wikipedia.org/wiki/OpenMAX

As noggin mentioned; the existing integrated OMXPlayer code for Kodi is one of possible ways to implement OpenMAX support in Kodi as a proof-of-concept, another way looks to be via an OpenMAX codec for DVDPlayer (now VideoPlayer)?

Just keep in mind that OMXPlayer might or might not be the best longterm way to implement OpenMAX support in Kodi, and to get a better answer then it could probably be a good idea to start a new dedicated thread in the development forum to specifically discuss different possible implementations of OpenMAX decoding in Kodi today.

Anyway, today Kodi now defaults to MMAL on the Raspberry Pi, but you have the option to use OMXPlayer which previously used to be the default. So OMXPlayer is still probably a good for proof-of-concept.

Note that even if not in your interest is only for Linux, it is still good to know that OpenMAX codecs for the MediaCodec API on Android is among the best way to implement decoding on Android, so if your OpenMAX codec implementation for Allwinner is flexible enough then you could possibly also reuse that code in a codec for MediaCodec API to get Android support as a bonus.

Really, it should be in Allwinner's own interest to provide OpenMAX codecs themselves for all their VPUs and supported codecs, for both Linux and for Android, as that would be most versitile for all their customers and users. Would not cost them more than manhours as OpenMAX is royalty-free to use.
Reply
#40
^^ great info ^^ what do you do for a living? Developer?
Reply
#41
I think it would be better to drop the OMX idea and look for a long time solution. There has work started to create a v4l2 kernel driver for the decoder. As this seems to become some kind of standard in linux kernel for decoding and encoding work, we may better try to implement the usage of v4l2 into kodi. Some others (Rockchip...) already pushed patches for kernel mainlining....

rellla
Reply
#42
(2016-07-06, 10:16)rellla Wrote: I think it would be better to drop the OMX idea and look for a long time solution.
I think that you may I missunderstood me. Using some kind of OpenMAX implementation would be a great long-term solution. I only meant that using Kodi's existing "OMXPlayer" might not be the very best solution. I still think that some type of OpenMAX solution is the way to go.

Really, since OpenMAX could be implement in several different ways it could probably be a good to start a conversation with Kodi's team developers to get their opinion on the matters of which of the many different ways would be THE best way.

(2016-07-06, 09:48)PantsOnFire Wrote: ^^ great info ^^ what do you do for a living? Developer?
No, I'm only an IT technician. I used to be a hardcore HTPC enthusiast so done a lot of research in the past just for my personal interest, but now days I'm only an regular end-user as time allows.
Reply
#43
OpenMAX is a real pain in the rear Smile Did a version for xbmc long ago. Twitchy as all. Maybe because OpenMAX was pretty new back then, maybe not.

The real problem on Linux is as soon as something becomes semi-stable, it gets abandoned for something more 'shiny'.
MrMC Forums : http://forum.mrmc.tv
Reply

Logout Mark Read Team Forum Stats Members Help
PINE A64: 64-bit processor, supports up to 2GB of RAM and can output 4K0