Wow ! That is impressive !
thanks fritsch.
Thats means I will be possible to use in Xbmc/kodibuntu as well. If I use the ppa and correct packages as well?
Awesome work guys!
Does this in practice mean that with this update all the Bay Trail boards (like j1800) deliver exactly the same performance and image quality (deinterlacing 1080i live tv, upscaling) like the new Braswell boards?
Great work guys!
Beside the montioned known issues, kodi segfaults when stopping playback.
Crashlog
@sat4all: Yes, use confluence for now if possible. I will add Aeon Nox to that known issues.
Thanks for the crashlog, that makes the error obvious, will forward to Fernet.
(2015-06-22, 14:16)gurabli Wrote: [ -> ]Awesome work guys!
Does this in practice mean that with this update all the Bay Trail boards (like j1800) deliver exactly the same performance and image quality (deinterlacing 1080i live tv, upscaling) like the new Braswell boards?
Not really. BSW is much more powerful. Those will do 4k@30p including HEVC (not addressed here) when we are done. I need to test 4k@60p again, but last time I tried - BSW was too slow for that - we will see.
(2015-06-22, 14:13)tavoc Wrote: [ -> ]thanks fritsch.
Thats means I will be possible to use in Xbmc/kodibuntu as well. If I use the ppa and correct packages as well?
See above. Self-Builders for now only. After wsnipex holiday, we will see to provide builds.
(2015-06-22, 15:10)fritsch Wrote: [ -> ] (2015-06-22, 14:16)gurabli Wrote: [ -> ]Awesome work guys!
Does this in practice mean that with this update all the Bay Trail boards (like j1800) deliver exactly the same performance and image quality (deinterlacing 1080i live tv, upscaling) like the new Braswell boards?
Not really. BSW is much more powerful. Those will do 4k@30p including HEVC (not addressed here) when we are done. I need to test 4k@60p again, but last time I tried - BSW was too slow for that - we will see.
Thanks! But if we don't look at 4K and HEVC at all, just 1080i live tv and Lanczos3 upscaling for SD and 720p material, then the quality will be the same as with Braswell? I ask this only because I'm able to get j1800 boards at very low price, and those who will use it would not need 4K at all.
I will go with Braswell for myself for sure.
Exactly! One thing you should know though, BYT has some instabilities in "mainline kernels", we specially fix in our OpenELEC tree. Besides that - you are good to go.
Let's wait until others have tested it a bit more, though. Suddenly the BYT is getting a very good buy :-)
(2015-06-22, 15:16)fritsch Wrote: [ -> ]Suddenly the BYT is getting a very good buy :-)
Yes, thanks to you guys and your great work! Amazing what you are able to do and squeeze out from these chips
There are some BYT boards still widely available for ultra low price (like the ASRock J1800 itx), and now thanks to you those boards are usable.
Probably the price of Braswell boards will drop soon (they are not so expensive atm).
(2015-06-22, 13:00)fritsch Wrote: [ -> ]For the future we are working with intel's mesa department to copy the NV12 surfaces directly. That way we will gain another 1.5 increase as we don't need to have VAAPI convert NV12 to RGB32 (limited) internally.
Does copying the NV12 surfaces directly mean keeping YCrCb within the YCrCb domain all the way through Kodi? Or is there an NV12 matrix involved for SD to HD colourspace conversion?
If so - where would the 601 to 709 colour space conversion take place when playing SD 576/50i content (which is 601 colorspace) and scaling it to HD 1080/50p (which needs to be 709 colourspace)?
You can't scale 601 YCrCb to 709 YCrCb without a matrix conversion as they represent different things? If you pass through 601 YCrCb as 709 YCrCb when your TV decodes it to RGB it will use the 709 coefficients rather than 601 coefficients, so will end up with green push and blue and red pull?
For 601 : Y = 0.299R + 0.587G + 0.114B
For 709 : Y = 0.213R + 0.715G + 0.072B
Or am I missing the point somewhere?
As to the rest - AMAZING!
(Any chance of 4:2:2 rendering support to avoid the odd chroma rendering stuff where saturated 4:2:2 50i stuff appears to deinterlace to 25p?)
VPP fully ignores all color flags we give it, therefore we need to use the relevant matrices (that are already in kodi's shadercode) afterwards ourselves. We now get out something "looking like" Limited RGB Range with wrong 601 colorspace, this won't change for now.
We hope to implement this NV12 surface copy and afterwards scale with the correct functions (matrices, that are already there) to be able to output RGB (at the very last moment), which is what OpenGL does at the end. For now nothing else is possible in this "fast path" or in shorter: We have to take _that_ RGB that we are given and have no influence on it.
See:
https://github.com/FernetMenta/xbmc/comm...t-11814215 (make sure to also read the commit he answered to, I wanted to get the colorspace right, but VPP ignores it).
Btw. we are working with Lauri Millary to make fully sure we get "the best out of it" that is possible. E.g. direct unaltered output of the HW decoder, then asking the color space via dvdplayer / ffmpeg and use the relevant shader code to output in the color format we want.
To be more precise: As of now(!) there is _not_ a single chance to get "non altered f*cked up colors" when not using
a) the SSE4 copy (does not scale for 4k ... high load)
b) vaPutSurface, which uses BT601 and BT709 but scales "up" to Full Range RGB ...
