2016-01-09, 16:52
It's the file fernet an I used when working with the intel folks to get the MCDI deinterlacer up and running. On AML you have a problem if the following does not work:
"Here is video data, please decode and display it, do what you want, I trust you".
Last time I started this discussion about what AML does with HEVC-10 bit content - where does the data end, how is it rendered some fanboys shot me down :-)
In fact you barely have any influence on AML architecture, it's data in and some time later it hopefully ends on the display, don't forget to set the target rect of the buffer or you won't see it. In kodi the player is fooled so it also does not know at all what happens. If something stutters, player has no idea why that happens it's all fully in the decoder / render.
You can imagine that like driving through a tunnel:
Car 1 in, Car 2 in
Tell the supervisor, stop caring about them all will be fine, they come out on the other side at exact the time you want them to come out.
I was reading AMLogic code (mostly the kodi implementation) and some documentation for the last two days and talked to the initial dev that implemented AMLogic for kodi. There are things one needs to live with ...
Edit: There are also a lot of things that can be fixed, but talking is one thing, actually implementing it is another ... developing on such a platform is not as easy as doing VAAPI or whatever, where you have all the tools / toolchain ready for rumble on the target host. But there are also some low hanging fruits: currently on every new image a hook is called to set the render rect, to managedisplays, to query CSettings for brightness, contrast and so on, these things can be fixed quite easily. The player fooling is not so easy, as many tried until now ... AMLogic has some specialities and I know not enough about it to say: It's all fully wrong and it needs to be done like this or that :-)
"Here is video data, please decode and display it, do what you want, I trust you".
Last time I started this discussion about what AML does with HEVC-10 bit content - where does the data end, how is it rendered some fanboys shot me down :-)
In fact you barely have any influence on AML architecture, it's data in and some time later it hopefully ends on the display, don't forget to set the target rect of the buffer or you won't see it. In kodi the player is fooled so it also does not know at all what happens. If something stutters, player has no idea why that happens it's all fully in the decoder / render.
You can imagine that like driving through a tunnel:
Car 1 in, Car 2 in
Tell the supervisor, stop caring about them all will be fine, they come out on the other side at exact the time you want them to come out.
I was reading AMLogic code (mostly the kodi implementation) and some documentation for the last two days and talked to the initial dev that implemented AMLogic for kodi. There are things one needs to live with ...
Edit: There are also a lot of things that can be fixed, but talking is one thing, actually implementing it is another ... developing on such a platform is not as easy as doing VAAPI or whatever, where you have all the tools / toolchain ready for rumble on the target host. But there are also some low hanging fruits: currently on every new image a hook is called to set the render rect, to managedisplays, to query CSettings for brightness, contrast and so on, these things can be fixed quite easily. The player fooling is not so easy, as many tried until now ... AMLogic has some specialities and I know not enough about it to say: It's all fully wrong and it needs to be done like this or that :-)
