a) I have absolutely no idea _why_ you force Deinterlacing for progressive video content :-( deinterlacing is needed for interlaced content and nothing else - see the first post.
b) DTS-HD is decoded lossless. The only thing we currently miss is Atmos decoding, everything else works fine.
c) As you are not a master in reading: No
Debug Log no issue.
(2016-06-08, 08:06)fritsch Wrote: [ -> ]a) I have absolutely no idea _why_ you force Deinterlacing for progressive video content :-( deinterlacing is needed for interlaced content and nothing else - see the first post.
You blame your users again for something that might actually be something that requires to be fixed in Kodi.
Just as you said things like "
0% is the most non smart thing you can do.", yet it
was the default setting in Kodi...
Why do you allow forcing deinterlacing on progressive content if it doesn't make sense at all?
If deinterlacing should not be forced, then just remove the setting which allows forcing it.
Currently you can switch between "On", "Off" and "Auto".
Just remove "On". Problem solved.
There is content that is sadly not progressive completely, but mixed with interlaced stuff, which one cannot auto detect. Therefore there is an option for the user to force it on. It can change per spec. Especially TV in great britain has such streams.
I cannot do more than: Give a straight howto, which clearly in fat / bold says: Don't force deinterlace to On ...
I can explain things to you - but I can't understand them for you.
Since you said you can explain things to me (us), I'd like to ask another question:
(2015-07-12, 20:06)fritsch Wrote: [ -> ]Besides the performance issue, this putSurface method always scaled the limited color range of the original files to FULL RGB. Introducing Banding or even worse it was scaled twice, e.g. back to limited, by the driver itself. All this won't happen anymore, cause the new zero copy approach allows us to directly render the decoded NV12 surface with our own shader. So all color conversions are in our hands now. You can savely use "Prefer VAAPI Render Method" set to on again and don't need to waste CPU cycles with bypassing this Method. All colors will be fine. If you have a Limited Range TV - you need to set "Use Limited Range" to On additionally. Also make sure that your GPU itself is running at full range, which this howto and also all OpenELEC images will do by default.
Why, in that case, would you have to set your GPU (driver) to output at full range?
You said the issue was that the limited range video was expanded to full range.
You said this would no longer happen.
But then why set the driver to output at full range?
Why can't we leave the GPU output (driver) at limited range if this no longer happens?
Wouldn't it make more sense to leave everything at limited range (when using a limited range TV)?
If we set the GPU (driver) to output at full range, then we are expanding the limited range image to full range again and it's then being reduced to limited range again by the TV, right? So we have a "double scale" again...
Or don't we?
No fully wrong ... the TV is dump it just clamps when it runs limited, no scaling. If you have a limited range TV and output full range to it, it will just cut 0 .. 16 and 235 .. 255.
Now software part:
xrandr setting Limited 16:235 - scales (!) everything it gets no matter what it is down! so if you give it 16 it will make ~ 2x from it, if you give it 235 it will make ~ 21x out of it -> result: No blacks, no whites.
xrandr full: assume everything you get is fine and directly output it without touching ... so 16 will be 16 and 235 will be 235. With a limited TV -> direct output.
No we don't. If it was that way - we had no problem at all.
Btw. if you would just use the forum search, you would find all that information:
http://forum.kodi.tv/showthread.php?tid=...pid2319474 so that I don't have to explain it again and again. Or just look into the wiki:
http://kodi.wiki/view/Video_levels_and_color_space
(2016-06-08, 08:06)fritsch Wrote: [ -> ]a) I have absolutely no idea _why_ you force Deinterlacing for progressive video content :-( deinterlacing is needed for interlaced content and nothing else - see the first post.
b) DTS-HD is decoded lossless. The only thing we currently miss is Atmos decoding, everything else works fine.
c) As you are not a master in reading: No Debug Log no issue.
Everyone here is not an expert, this is a forum where everyone is at different levels. I appreciate your input but there is no reason to insult me if I give some input or have a question that might be obvious to you and not to me.
As far as not offering up a debug log, I'm not sure what problem you're addressing? Everything works fine for me, except for the jitter which you explained I can solve by turning off deinterlacing. There is a lot of information in your first post and I simply just missed it. Everything is a learning process for me as I am new to this.
Deinterlace -> Auto.
Ack for the rest.
(2016-06-05, 17:35)fritsch Wrote: [ -> ](or set xrandr to VideoRange 16:235, which is _NOT_ in any mainline kernel, but in openelec / libreelec)
(2016-04-24, 19:08)fritsch Wrote: [ -> ]Video 16:235 pass-through: Implemented for OE / LE. Signal Limited, but don't scale / clamp color values -> pass-through mode.
Is there any feature request / pull request somewhere which deals with putting the 16-235 passthrough mode into the mainline kernel?
Would be appreciated if you could post a link to it.
intel-gfx mailing list archive - just search for my name
So, has anyone been able to get the pretty fancy splash that worked in 14.04 to work in 16.04? I tried installing th epackages from th eold guide, but it does not seem to work.
@
fritsch , sorry if this has been asked before, but using your build , would it be possible to decode 4K h.264 (not h265 , as you would need Brasswell or up for this) on a SandyBridge CPU , say an Intel Celeron G530 using the integrated graphics ?
(2016-06-11, 19:19)Soulbind Wrote: [ -> ]@fritsch , sorry if this has been asked before, but using your build , would it be possible to decode 4K h.264 (not h265 , as you would need Broadwell or up for this) on a SandyBridge CPU , say an Intel Celeron G530 using the integrated graphics ?
Afaik IVB or later is needed.
Hello fritsch,
When I reinstall my HTPC, is enough to follow the guide in the first post, or I need to update the driver from
this post too?
Driver from this post is needed as the ppa did not like to build it and wsnipex is busy ... btw. nearly no one has seen a difference besides one after using a hdmi capture card. It will be fixed in 1.7.1 version of the driver.
?