Login at Kodi Home

**fritsch** · 2016-01-09, 23:36

And concerning your picture quality: On Linux we don't have influence at all on what reaches the screen when AMLogic hwdecoder / render is in use, we can only tell where it should be output. kodi can only influence the overlays :-) so if you don't like the transparency level of the codec screen we can adjust that. The rest is done by a black box.

With Mediacodec stuff like Limited / Full Range is also not possible to my knowledge. So if you don't like your blacks / whites - yeah currently nothing (I am aware of) can be done to compensate that.

Milkado · (This post was last modified: 2016-01-09, 23:45 by Milkado.)

The only reason to open it is to see the fps Smile

I need it to test if auto frame rate is working fine.

About the quality: is there any difference between Kodi Isengard version in Android and the version used in your Openelec release (transparency layer)?
If Linux cann't influence the picture quality, what about Android?

Maybe both images are exactly the same and it is just in my brain.

**fritsch** · 2016-01-09, 23:41

(2016-01-09, 23:39)Milkado Wrote: The only reason to open it is to see the fps
I need it to test if auto frame rate is working fine.

:-(

FernetMenta · 2016-01-09, 23:42

Unfortunately Kodi's implementation of AML codec decayed heavily after davilla left. Currently it is a disaster without a maintainer. Either this state changes or I think about purging the code from our repo.
Don't get me wrong, I am no against AML but I don't like unmaintained and decayed code.

**fritsch** · 2016-01-09, 23:46

There are some things, that we can easily solve, for example, the constant ManageDisplay, Settings, RenderRect querying with every pic that gets output. What I currently don't have an idea is _if_ it is possible to convince the decoder to play a bit more nicely with our architecture, like popcornmix did with the RPi, at the beginning the PI also had ~ 5 seconds of video data somewhere in his buffers and did not play nicely, but MMal majored quite nicely over time and currently is the "see how he did it implementation of such a bypass like" codec.

For AMLogic it was too long only cared, that "as long as it outputs something" all is fine ...

FernetMenta · 2016-01-09, 23:55

popcornmix is the active maintainer of RPi (MMAL) and is in continuous communication with me. After Koying resigned AML has no maintainer and while he was active he did not talk to me. The result is the current mess AML codes is in.
The rules did not change: unmaintained code has to go. @fritsch, are you the new maintainer of AML?

Milkado · (This post was last modified: 2016-01-10, 00:01 by Milkado.)

(2016-01-09, 23:42)FernetMenta Wrote: Unfortunately Kodi's implementation of AML codec decayed heavily after davilla left. Currently it is a disaster without a maintainer. Either this state changes or I think about purging the code from our repo.
Don't get me wrong, I am no against AML but I don't like unmaintained and decayed code.

But kodi implementation of AML codec has to be the same in Android and Openelec, isn't it?
Sorry for this silly questions but I'm going crazy with your technical knowledge Blush

**fritsch** · 2016-01-10, 00:05

(2016-01-09, 23:55)FernetMenta Wrote: popcornmix is the active maintainer of RPi (MMAL) and is in continuous communication with me. After Koying resigned AML has no maintainer and while he was active he did not talk to me. The result is the current mess AML codes is in.
The rules did not change: unmaintained code has to go. @fritsch, are you the new maintainer of AML?

Nope - I am not. If I wanted to use a hacked together kernel and receive great pain I prefered to bring the XVBA code back to life and use the fglrx blob :-). Nope, but if you intend to look into that I' ll do the sparing partner of course :-)

MrMC · (This post was last modified: 2016-01-10, 00:12 by MrMC.)

If AMLCodec is removed, then say goodbye to every OpenElec distro (ie WeTek) running on AML hardware. Just an FYI as to the result.

To keep it means creating a viable solution to the case where the internal renderer path is bypassed for video display. You can't just wave your hands and say it does things wrong. That's the way the system amcodec it works and no amount of words will change that. And as I have mentioned before, it was only when renderer started caring about time stamps did AMLCodec behavior start to degrade.

However there might be another way. The AML kernel drivers (there are many involved) now support a V4L interface. Memphiz used parts of it to handle boblight usage and I pointed him that way as a better solution to a kernel driver written by me for pivos lightpack usage. In theory, under OpenElec/Linux use the V4L API to pull back decoded frames, then pass then up to renderer. You might even be able to keep them on the GPU side to skip copy round trips. This would replicate the existing "not wrong' behavior of internal codecs.

Then nuke AMLCodec, replaced by MediaCodec on Android and a new V4LCodec for Linux.

FernetMenta · 2016-01-10, 00:08

(2016-01-10, 00:05)fritsch Wrote:
(2016-01-09, 23:55)FernetMenta Wrote: popcornmix is the active maintainer of RPi (MMAL) and is in continuous communication with me. After Koying resigned AML has no maintainer and while he was active he did not talk to me. The result is the current mess AML codes is in.
The rules did not change: unmaintained code has to go. @fritsch, are you the new maintainer of AML?

Nope - I am not. If I wanted to use a hacked together kernel and receive great pain I prefered to bring the XVBA code back to life and use the fglrx blob :-). Nope, but if you intend to look into that I' ll do the sparing partner of course :-)

hehe, revive xvba Smile

FernetMenta · 2016-01-10, 00:12

(2016-01-10, 00:08)MrMC Wrote: If AMLCodec is removed, then say goodbye to every OpenElec distro (ie WeTek) running on AML hardware. Just an FYI as to the result.

That's exactly my point. I am not payed by companies making money with this port am I don't invest my time for them to make money. Either they contribute or the code in Kodi repo will be history.

MrMC · 2016-01-10, 00:15

Hehe, then nuke it and be done with it. No skin off my ass Smile

I don't think windows has an active maintainer, nuke it too. And BSD support along with other non-Linux flavors.

droidelec · 2016-01-10, 00:19

(2016-01-10, 00:12)FernetMenta Wrote:
(2016-01-10, 00:08)MrMC Wrote: If AMLCodec is removed, then say goodbye to every OpenElec distro (ie WeTek) running on AML hardware. Just an FYI as to the result.

That's exactly my point. I am not payed by companies making money with this port am I don't invest my time for them to make money. Either they contribute or the code in Kodi repo will be history.

Fernetmenta, as company we are one of rare to contribute as much as we can especially to OE. All our work on MX, S8xx is public and pushed to OE and our github.

noggin · 2016-01-10, 00:24

(2016-01-09, 23:31)fritsch Wrote: As AMLogic user you should not open the CodecInfo at all ... as it does not relate to anything your hw decoder / render does.

It's quite useful to confirm the codecs in a file and whether they are being decoded in hardware or software. And the CPU info is useful (if it works). But yes - no point in thinking it tells you much about decode quality.

FernetMenta · 2016-01-10, 00:25

Windows has an active maintainer and you can't compare Windows with AML. But yes, it is the application that counts, not some decayed customisations. We just got an PR from Actions-Semi for a codec. If it really happens that AML is nuked, that does not mean that it can't ever reintegrated. If devs or companies think that code once integrated into Kodi will be maintained by the community, I'll prove them wrong.