(2015-09-20, 00:58)fritsch Wrote: [ -> ] (2015-09-20, 00:51)VirtualRain Wrote: [ -> ] (2015-09-20, 00:42)fritsch Wrote: [ -> ]You cannot and this the thing you totally don't understand. But yeah - choose what you are happy with, user has choice and this is the OSS spirit we have here.
It's very possible I don't understand. I've been learning a lot about limited vs full levels lately so there might be something I'm missing still. Can you explain? I'd like to know.
I replied to your last post in detail concerning the settings you chose ... more detail is not possible.
Yes, thank you. It's now clear to me what settings make sense and why. Conversions in levels are to be avoided at all cost. Running Kodi Limited, GPU full, and the TV on limited is the best solution... and this can be done on stable versions... you don't need to be running these experimental builds.
What's not clear, is what turning off "prefer VAAPI render mode" does in OE5/Kodi14.2... It appears to have no consequence on my video quality, but as I said, I only watch 24p material... not TV and I have relatively powerful CPU so software rendering is probably just fine. I guess if you really need that option enabled then yes, these experimental builds are helpfu... but I keep saying, no where does it articulate exactly who would benefit from this.
But at least for the time being, it seems any Kodi 15.x builds are not compatible with the Haswell Mac Mini display refresh rate changes... which is more of a problem than VAAPI rendering.
(2015-09-20, 00:41)fritsch Wrote: [ -> ]Don't forget. You are all pioneers testing the code that will be live in v16+ ... :-)
good night.
By the time 16+ goes live we will be here testing the code that will be live in 18+... featuring nneid3,super-xbr,jinc,superRes
Good night
(2015-09-20, 00:41)fritsch Wrote: [ -> ]Don't forget. You are all pioneers testing the code that will be live in v16+ ... :-)
good night.
yes sir, Thanks to you and all here.
I can only assume working with Intel might be difficult at best. My Kodi box is state of the art thanks to all the efforts here.
...Perhaps I might actually watch a movie tonight other than calibrating or testing other settings ^_^
(2015-09-20, 01:09)VirtualRain Wrote: [ -> ]What's not clear, is what turning off "prefer VAAPI render mode" does in OE5/Kodi14.2... It appears to have no consequence on my video quality, but as I said, I only watch 24p material... not TV and I have relatively powerful CPU so software rendering is probably just fine. I guess if you really need that option enabled then yes, these experimental builds are helpfu... but I keep saying, no where does it articulate exactly who would benefit from this.
VAAPI rendering is particularly useful if you watch interlaced content. This is because it allows for hardware deinterlacing, whereas if you deselect VAAPI rendering, whilst you can still benefit from VAAPI hardware decode of the codec (H264, VC-1, MPEG2 etc.) you won't benefit from hardware deinterlacing, and will have to use software deinterlacing. This is CPU-intensive, and low-end CPUs will only be able to do relatively low-quality deinterlaces. The same CPU/GPU combos can deliver high quality hardware deinterlacing if VAAPI rendering is enabled.
Lots of us use Kodi to watch Live and Recorded TV, and some of this is native interlaced, so deinterlacing performance is important to some of us.
Fritsch - I have a completely unrelated problem but figured I would post here and you can tell me where to take it or any suggestions.
My current setup is Asus Chromebox -> Denon4520 -> JVC Projector - all over HDMI and using audio passthrough.
Often when the system changes refresh rates I end up wit a completely garbled screen with lines across it - usually green. If I switch back to the previous working refresh rate it goes back to normal but changing to the new refresh goes back to junk. If I reboot or do anything the screen will remain garbled. I work around this by usually forcing kodi display to 23.98 and so I want 99% blu-ray mkvs and it never has to switch. Some of the last few builds seem to be losing my settings and setting refresh back to 60hz.
What I am not sure about is where the problem exactly is or how to go about and debug it. If I remember I usually end up unplugging the avr and rebooting the chromebox and things will be okay.
I suppose I could connect the chromebox to the jvc directly and switch refresh rates a few times and rule out the Denon.
Any particular logging in Kodi that would help figure this out? Maybe some xrandr output?
I willl do some more debugging - I had forgotten about the problem until it popped back up with the recent builds changing my settings.
Thanks and sorry I know this is likely out of place
This whole thread is about VAAPI rendering and how it relates to current Kodi distros/hardware.
And how to solve issues
I'm confused....
But for the benefit of all please stay on topic!
(2015-09-20, 02:14)noggin Wrote: [ -> ] (2015-09-20, 01:09)VirtualRain Wrote: [ -> ]What's not clear, is what turning off "prefer VAAPI render mode" does in OE5/Kodi14.2... It appears to have no consequence on my video quality, but as I said, I only watch 24p material... not TV and I have relatively powerful CPU so software rendering is probably just fine. I guess if you really need that option enabled then yes, these experimental builds are helpfu... but I keep saying, no where does it articulate exactly who would benefit from this.
VAAPI rendering is particularly useful if you watch interlaced content. This is because it allows for hardware deinterlacing, whereas if you deselect VAAPI rendering, whilst you can still benefit from VAAPI hardware decode of the codec (H264, VC-1, MPEG2 etc.) you won't benefit from hardware deinterlacing, and will have to use software deinterlacing. This is CPU-intensive, and low-end CPUs will only be able to do relatively low-quality deinterlaces. The same CPU/GPU combos can deliver high quality hardware deinterlacing if VAAPI rendering is enabled.
Lots of us use Kodi to watch Live and Recorded TV, and some of this is native interlaced, so deinterlacing performance is important to some of us.
Yes... I think you mentioned this earlier. And I appreciate it. You are very helpful.
I think this should be posted at the top of post #1... It's incredibly helpful in explaining what's going on in this thread and who can benefit. It would help attract the right kind of testers and keep the wrong ones from dragging this down.
My best to all here, especially all you hardcore developers and testers for pushing things forward.
(2015-09-20, 02:56)oshan Wrote: [ -> ]This whole thread is about VAAPI rendering and how it relates to current Kodi distros/hardware.
And how to solve issues
I'm confused....
But for the benefit of all please stay on topic!
The thing you should keep in mind, is that not everyone knows WTF that is... Including the folks who could really help (never mind the dead weight that can't!)
@VirtualRain:
Summary:
a) VAAPI Rendering (before this work): Decode with VAAPI -> BT601, BT701 color computationg and after that Full RGB transformation without any influence by us, massive banding, colors broken -> Full GPU copy of the decoded surfaces for rendering
b) VAAPI Rendering (after this work): Decode with VAAPI -> Directly untouched zero-copy of the NV12 data (EGL image), no color fuckup, colors untouched -> Shader postprocessing to do BT601, BT701 color matrix with optional dithering before output
c) Disable VAAPI Rendering: Decode with VAAPI -> CPU copy with optimized, but as massive CPU intensive task back to system memory, colors untouched -> Software Rendering path from here
Btw. all of this I tried to explain in the very first post.
@noggin:
You are right, that the VAAPI postprocessing methods (VAAPI-BOB, VAAPI-MCDI, VAAPI-MADI) were only possible with the Prefer VAAPI Render enabled. The Render was even automatically switched on, if you choose those methods while playing a video. Also "Use VAAPI Rendering off" is only possible for max 1920x1080, it is disabled for everything with larger.
Copy path GLX (method a) vs. SSE4 (method c) with a 1920x1080@24p movie.
Copy time (method c) for 3840x2160@p30 content (reason why it was disabled afterwards for 4k content), here I tested 8K vs 4K L1 fixed cache buffer.
Hardware: core i5 3400 mhz, 32 gb memory.
Thank you again Fritsch... As you know, this is mostly over my head, but I'm a sucker for improving video quality which is what drew me here. I wish I had more time to help out and try this stuff and trouble-shoot, but I just don't. My interest far exceeds my available time. I'm glad you guys are questing this. I come from Plex where no one gives a damn about playback quality so it's refreshing to see this kind of investment. Sorry to have slowed you guys down.
(2015-09-19, 14:47)fritsch Wrote: [ -> ]Last builds (sort by date and _think_ while downloading): http://fritsch.fruehberger.net/openelec/?C=M;O=D
Changelog:
- Automatically switch to full range (no autostart.sh needed anymore)
- Fixed a little bug in res changing, incorporated iScreenHeight to not run into fake AVR resolutions
- Rebase on fernet's master. Here a whole lot was changed, please be aware of bugs
- I removed the default 175 ms delay - custom video delays already in your DB won't be changed of course.
These builds you mean are broken? Dont use pvr so i did not notice anything. The default to Full RGB and the removal of the delay proved very convenient. Will continue using them until something better surfaces! Thanks again fritsch!
(2015-09-20, 08:05)fritsch Wrote: [ -> ]c) Disable VAAPI Rendering: Decode with VAAPI -> CPU copy with optimized, but as massive CPU intensive task back to system memory, colors untouched -> Software Rendering path from here
Software rendering means no GLSL and this outdated path won't be taken unless render method is "Software". Nobody wants to use this method regardless of what's chose for vaapi.
(2015-09-20, 10:41)VirtualRain Wrote: [ -> ]Thank you again Fritsch... As you know, this is mostly over my head, but I'm a sucker for improving video quality which is what drew me here. I wish I had more time to help out and try this stuff and trouble-shoot, but I just don't. My interest far exceeds my available time. I'm glad you guys are questing this. I come from Plex where no one gives a damn about playback quality so it's refreshing to see this kind of investment. Sorry to have slowed you guys down.
One thing you're missing from a playback quality standpoint even with limited range route and only progressive content: dithering option. This can smooth out banding problems in badly mastered content. That is banding not from rgb conversions.
@fritsch: I cab also confirm default audio delay is no longer needed with EGL! Used to be 50 ms with my particular setup, i3 nuc hsw.
@ggp759: Refreshrate switching is broken there currently, at least if you use PVR with preview and then switch to fullscreen, but that is current WIP currently. Fernet is removing all the old non maintainable code to get refreshrate switching done in a straight forward way.
@VirtualRain: If you only want to test the grayscale ramp, choose the Isengard based build:
http://fritsch.fruehberger.net/openelec/isengard/ Changelog: Pick fixes from master, Use Full range by default without autostart.sh
@Hufvudet: Thanks for that report. Yes, you are perfectly right, Dithering especially helps in that case, too.