+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
+---- Thread: Intel VAAPI howto with Leia v18 nightly based on Ubuntu 18.04 server (/showthread.php?tid=231955)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
RE: New Era: VAAPI with EGL interoperation - ggp759 - 2015-09-18
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!
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-18
@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.
RE: New Era: VAAPI with EGL interoperation - VirtualRain - 2015-09-18
(2015-09-18, 02:17)noggin Wrote:(2015-09-17, 20:20)VirtualRain Wrote: 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.
Quote: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.
Quote:Quote: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.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-18
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.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-18
Quote: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.
RE: New Era: VAAPI with EGL interoperation - Klojum - 2015-09-18
(2015-09-18, 11:00)fritsch Wrote: @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.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-18
@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 ...
RE: New Era: VAAPI with EGL interoperation - ggp759 - 2015-09-18
(2015-09-18, 12:53)fritsch Wrote: @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.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-18
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 ...
RE: New Era: VAAPI with EGL interoperation - ggp759 - 2015-09-18
(2015-09-18, 14:35)fritsch Wrote: 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.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-18
Just use new posts in the future - I never read back, just like a hw decoder -> decoding forward only.
RE: New Era: VAAPI with EGL interoperation - furii - 2015-09-19
(2015-09-18, 14:35)fritsch Wrote: 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.
RE: New Era: VAAPI with EGL interoperation - VirtualRain - 2015-09-19
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?
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-19
Nobody knows ... post your damn Debug Log.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-09-19
(2015-09-19, 01:30)furii Wrote:(2015-09-18, 14:35)fritsch Wrote: 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.