Posts: 23,266
Joined: Aug 2011
Reputation:
1,074
fritsch
Team-Kodi Developer
Posts: 23,266
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.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 6,810
Joined: Jul 2010
Reputation:
198
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.
Posts: 23,266
Joined: Aug 2011
Reputation:
1,074
fritsch
Team-Kodi Developer
Posts: 23,266
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 ...
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 758
Joined: Jun 2014
Reputation:
31
MrMC
Posting Freak
Posts: 758
2016-01-10, 00:08
(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.
Posts: 6,810
Joined: Jul 2010
Reputation:
198
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.