(2015-11-25, 14:08)Sunflux Wrote: You said you need an actual receiver to test the TrueHD issue. But if the issue is that the video won't play in the first place, do you need an actual TrueHD supporting receiver to test that part? So long as the system thinks it supports TrueHD and tries to bitstream, does it matter if the device on the other end can decode it?

(2015-11-25, 14:08)gurabli Wrote: @fritsch
In the first post you write: "While we are trying to get this code tested and merged into kodi v17...", I understand that VAAPI with EGL will not be included in Jarvis final. What will happen once Jarvis final is released, the ppa here will be based on v17 development builds?

Few post before you wrote: "I don't have my Braswell anymore - gave it away after everything we could do was implemented."
This means that fine tuning and bugfixes are still to do without implementing anything (since everything possible already works). What is on the to do list for this project?

Thanks!

(2015-11-25, 14:13)Milhouse Wrote: The problem with Dolby TrueHD seems to be passthrough related (I can reproduce this problem in my latest Nvidia_Legacy test build).

However if you disable passthrough then the TrueHD audio plays without a problem (I'm guessing this is now being decoded to 8 channel PCM etc.)

But with passthrough enabled for TrueHD, the stream will pause forever at start of playback.

(2015-11-25, 14:17)fritsch Wrote:

(2015-11-25, 14:08)gurabli Wrote: @fritsch
In the first post you write: "While we are trying to get this code tested and merged into kodi v17...", I understand that VAAPI with EGL will not be included in Jarvis final. What will happen once Jarvis final is released, the ppa here will be based on v17 development builds?

Few post before you wrote: "I don't have my Braswell anymore - gave it away after everything we could do was implemented."
This means that fine tuning and bugfixes are still to do without implementing anything (since everything possible already works). What is on the to do list for this project?

Thanks!

I think @FernetMenta will be so kind and create a branch directly after v16 stable was released - which can then be used for endusers until v17 is out. Currently we have reworked handling of IEC encapsulated audio to support Android's passthrough in the future. Basically I don't know what will be done next. There is still a lot stuff to cleanup. Getting EGL / Videoplayer rework to v17 and test it on all platforms, including Android, AMLogic, IMX and so on is not trivial. VDPAU / VAAPI as provided in this thread is one of the most tested versions currently.

I currently think of giving VAAPI scalers a new chance - but I am not yet sure - we need to improve our scaler performance by a lot - cause if we are honest - we currently cannot upscale 1080p24 to 3840x2160p60 without pushing the GPU to a limit. Future TVs and HDMI output will be 4k@60 and users want to run the GUI in 4k then. I need to evaluate those again (adding a VPP step for deinterlacing is easy) adding another for the progressive path is not that easy. We will see. I had this implemented some years (!) ago on a baytrail and it was able to do lanczos3 optimized scaling, which is why i am quite curious. On the other hand if someone could fix up our lanczos shader to use intermediate float to save some steps would also be nice.

Currently work is ongoing to implement mipmapping for textures to make the GUI looking better. So a lot stuff that needs love and time - while just love is existent most of the time :-)

In short: Get yourself a source copy and start hacking today. When you are ready I am sure there is still a lot to do for you.

(2015-11-25, 14:17)fritsch Wrote: Currently work is ongoing to implement mipmapping for textures to make the GUI looking better.

(2015-11-25, 14:17)fritsch Wrote: Currently work is ongoing to implement mipmapping for textures to make the GUI looking better. So a lot stuff that needs love and time - while just love is existent most of the time :-)

(2015-11-25, 14:08)Sunflux Wrote: You said you need an actual receiver to test the TrueHD issue. But if the issue is that the video won't play in the first place, do you need an actual TrueHD supporting receiver to test that part? So long as the system thinks it supports TrueHD and tries to bitstream, does it matter if the device on the other end can decode it?

(2015-11-25, 14:17)fritsch Wrote: I think @FernetMenta will be so kind and create a branch directly after v16 stable was released - which can then be used for endusers until v17 is out. Currently we have reworked handling of IEC encapsulated audio to support Android's passthrough in the future. Basically I don't know what will be done next. There is still a lot stuff to cleanup. Getting EGL / Videoplayer rework to v17 and test it on all platforms, including Android, AMLogic, IMX and so on is not trivial. VDPAU / VAAPI as provided in this thread is one of the most tested versions currently.

I currently think of giving VAAPI scalers a new chance - but I am not yet sure - we need to improve our scaler performance by a lot - cause if we are honest - we currently cannot upscale 1080p24 to 3840x2160p60 without pushing the GPU to a limit. Future TVs and HDMI output will be 4k@60 and users want to run the GUI in 4k then. I need to evaluate those again (adding a VPP step for deinterlacing is easy) adding another for the progressive path is not that easy. We will see. I had this implemented some years (!) ago on a baytrail and it was able to do lanczos3 optimized scaling, which is why i am quite curious. On the other hand if someone could fix up our lanczos shader to use intermediate float to save some steps would also be nice.

Currently work is ongoing to implement mipmapping for textures to make the GUI looking better. So a lot stuff that needs love and time - while just love is existent most of the time :-)
..