[ggp759]

Just wanted to report back about the latest openelec build (2015-9-17 (3) ). The out-of-sync audio is till there with passthrough. Totally fixed if i use the settings fritsch provided for the advancedsettings.xml. Thanks again for the hard work! Greatly appreciated!

[fritsch]

@ggp759: This is a good report, btw. - cause the default delay was nothing than a hack ... if others report the same - I can remove these delays by default.

[VirtualRain]

My Sony TV is a 2015 UHD set. The TV has an HDMI setting for "Auto", "Limited", and "Full". Are you saying the TV ignores this setting, or it just doesn't work properly on "Auto"?

I've not tried forcing mine. I have a 2014 set. I just know that in default mode that the VAAPI EGL stuff that fritsch and co have developed here - that allows 16-235 to be preserved by using the GPU in full range AND allows for VAAPI MCDI deinterlacing doesn't work for me in this mode because the TV interprets the xrandr Full setting as Full, when it is there as a 'cheat' (and a very good one) to get Limited all the way through without 0-255 scaling.

FYI, I've currently got things working with OpenElec 5 and Kodi 14.2 with Kodi set to 16-235 (and "Prefer VAAPI render method" disabled), No change to GPU, TV set to "Limited" where I'm getting proper preservation of levels without conversion... I can see blacker than blacks and whiter than whites making it easy to set my TV black level to reference black. Banding is minimal - better than when converting to full range but not as smooth as what I saw in a post on the previous page.

Yep - but that's not what is being discussed in this thread. We specifically want to use VAAPI rendering as it lets us do decent quality Motion Compensated Hardware deinterlacing. The work in this thread allows you to use VAAPI rendering and to avoid 0-255 banding - or if you can't at least mitigate it with dithering.

If you have "Prefer VAAPI render method" disabled you are going to be using software deinterlacing?

If you are only watching progressive sources, this may not be an issue, but lots of us use Kodi for watching Live/Recorded TV, and much of this is interlaced, and MCDI VAAPI deinterlacing is worth having.

In this situation you have two options. Stick with Full level output (not an issue if you switch between Limited and Full sources with an AVR as this should pass through the info frames that the TV follows), however disable the 16-235 settings in Kodi, and run with dithering enabled to help mask the banding otherwise caused by 16-235->0-255 range extension, or run the HDMI output in "Limited" mode (i.e. don't do the xrandr thing to change the GPU output range) and also make sure Limited levels in Kodi are disabled but again ensure dithering is enabled to hide the banding.

Maybe I misunderstand, but in either of these scenarios, you're going to lose your BTB and WTW information. It's not just about banding. You need everything to pass through without levels conversion... player, GPU and TV. When any part of the signal chain does a conversion, 16 becomes 0 and 235 becomes 256 and you lose that extra dynamic range. Dithering is better than nothing, but no conversion is the ideal solution.

Does your TV not have a mode where it can be forced to accept 16-235 without conversion?

BTB and WTW don't really worry me. Yes - they help you calibrate your TV - but any content <16 shouldn't be visible on a correctly calibrated display, so clipping it in the digital domain (whilst not good practice) isn't the end of the world with a well mastered source (though clipping <16 >235 transients can cause issues with scaling at a later date)

Scaling artefacts do worry me - as I don't like banding. A little bit of dither helps a lot to mask them. (My first employer patented such a technique...)

I see... It all makes sense now. Thank you for taking the time to step in here and write a helpful response. Really appreciate it. Learning a lot.

It was not clear at all from the first two posts that this is primarily addressing issues with interlacing. It seemed to me to be about overall better video quality and passing proper levels. As mentioned above, I appear to have proper levels pass through working end-to-end using standard builds, but still see some very slight lines in gradients... Not sure where those are coming from... Any ideas? My gradients are not perfectly smooth (but much better than initially when levels were being converted). Is it possible my GPU is still converting levels or something? (I can't imagine that's true if I have preservation of BTB and WTW?)

As noted above, In my recent quest for proper levels pass-through, I found I had to disable "Prefer VAAPI render method" not knowing what it does... Is it only necessary for interlaced content or does it also benefit progressive content? What is it exactly?

Given I almost exclusively view progressive material, is there any point in me having a look at the stuff being tested in this thread?

And, you may want to have a look at your Sony TV settings... You might have a setting for forcing video levels vs full range like mine.

[fritsch]

The Hybrid approach, that is used under windows also works on linux, it is the same blob shipped with the media-sdk. So 10 bit hybrid decoding is already there. Release is not done, cause of political reasons.

We (kodi) try to contact intel management to ask for release of this wrapper (hybrid wrapper is in place already as you know). Furthermore the intel driver already has some "decoding + transform" in place, so that we could use the same arch for now, but add the 10 to 8 transformation in a pipeline.

Let's see what will happen.

[fritsch]

As noted above, In my recent quest for proper levels pass-through, I found I had to disable "Prefer VAAPI render method" not knowing what it does... Is it only necessary for interlaced content or does it also benefit progressive content? What is it exactly?

With the old intel vaapi implementation we had to use a method called vaPutSurface to transfer decoded data to our render. This Method would have scaled the colors to RGB Full Range. This introduced banding and bad quality. By disabling this feature, a CPU copy path would have been used. (All this is documented in the first thread).

Second problem here is, that intel's driver is doing limited range by default (no matter which kodi setting you tick). So also with your "Prefer VAAPI Render Method" disabled, you will get a double scaled picture ... and most likely only can correct it by upping the contrast (multiplicative operator):-(


With this code here in the thread. You can savely keep prefer vaapi method _enabled. This is even suggested. Make sure though, that your GPU runs at full range (see second post of this thread) to not do additional downscaling ...

What noggin meant with LiveTV: It's a heavy operation to copy things. After that it's a heavy operation to deinterlace things on the CPU -> so this approach is not practical on low power / low performance devices.

So: In order to enjoy perfect colors, just follow the howto.

[Klojum]

@ggp759: This is a good report, btw. - cause the default delay was nothing than a hack ... if others report the same - I can remove these delays by default.

I'm a bit puzzled... It's possible that different hardware setups (older and newer) produce different audio delays. And if so, which hardware is considered "the norm"? I take it, the newer hardware?

My old Intel P5470 laptop has a different view on audio delays than my C1037+ TV setup has. But since the audio delays are stored (in my case) in the centralized MySQL database (in the 'settings' table), sometimes the audio delay has to be changed back and forth when watching.

[fritsch]

@Klojum: We set a default delay of 175 ms for 23.976 and 24.0 content. This "constant" delay is too much for ggp759's setup.

@ggp759: Do you have configured your AVR to delay? If yes - then it is clear that both delays would add up ...

[ggp759]

@Klojum: We set a default delay of 175 ms for 23.976 and 24.0 content. This "constant" delay is too much for ggp759's setup.

@ggp759: Do you have configured your AVR to delay? If yes - then it is clear that both delays would add up ...

There is no delay in my avr setup. No delay for the speakers. It is set to zero. Also nothing else is happening on my avr i.e scaling, picture adjusting etc. It just passes through the video to the tv. With the official openelec builds and the isengard build from this thread there was never an out-of-sync situation. Out-of sync happened with the jarvis builds from this thread. After applying fritsch's advanced settings sync is back to normal. Also i want to point out that if i dont use passthrough, use the chromebox to decode the sound, pass lpcm to the receiver and i choose "sync playback to display"there is no out-of sync audio and fritsch's advanced settings are not needed.

[fritsch]

What makes me wonder here is, that all other don't see the difference :-)

Cause 175 ms should be noticable by everyone. If all would have reported this I would be happy - cause we somehow found "the missing ~ 150 ms" we searched for a long time ...

[ggp759]

What makes me wonder here is, that all other don't see the difference :-)

Cause 175 ms should be noticable by everyone. If all would have reported this I would be happy - cause we somehow found "the missing ~ 150 ms" we searched for a long time ...

i see. edited my first post with some more info.

[fritsch]

Just use new posts in the future - I never read back, just like a hw decoder -> decoding forward only.

[furii]

What makes me wonder here is, that all other don't see the difference :-)

Cause 175 ms should be noticable by everyone. If all would have reported this I would be happy - cause we somehow found "the missing ~ 150 ms" we searched for a long time ...

in case it wasn't clear from my previous post, i found negating the built in 175ms delay present in OE through the gui fixed things for me as well. i made it permanent with an updated as.xml as well. +1 for removing it from OE by default.

[VirtualRain]

So I'm trying the latest OpenELEC build... from here... http://fritsch.fruehberger.net/openelec/

Set everything according to the first and 2nd post (including xrandr) and get no video. In order to enable playback of AVS709 files I have to turn off the option under Video Settings for "Adjust Display Refresh Rate". This worked fine on OE5/Kodi14. Am I missing something?

[fritsch]

Nobody knows ... post your damn Debug Log.

[fritsch]

What makes me wonder here is, that all other don't see the difference :-)

Cause 175 ms should be noticable by everyone. If all would have reported this I would be happy - cause we somehow found "the missing ~ 150 ms" we searched for a long time ...

in case it wasn't clear from my previous post, i found negating the built in 175ms delay present in OE through the gui fixed things for me as well. i made it permanent with an updated as.xml as well. +1 for removing it from OE by default.

Cool. I can do a build that has this advancedsettings.xml removed - but please test first if you really need "zero" delay now for passthrough _and_ non passthrough. Test the very same video, please and make sure the delay (which is saved if you change it via gui) is not set. So test with a movie you did not play before. Curious on your results.