+- 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 - fritsch - 2015-11-06
As you say - the Pi also works - then this one.
RE: New Era: VAAPI with EGL interoperation - m_gl - 2015-11-07
(2015-11-06, 20:37)fritsch Wrote: As you say - the Pi also works - then this one.
http://pastebin.com/9n6yughw
Same file.
RE: New Era: VAAPI with EGL interoperation - FernetMenta - 2015-11-07
omx player is a different story. not even sure if it logs this. what exactly are your visual observations?
btw: the pi has some capability of "resampling" passthrough
RE: New Era: VAAPI with EGL interoperation - ilovethakush - 2015-11-07
What's the difference between VAAPI Motion Compensated and VAAPI Motion Adaptive and which would you suggest for the chromebox?
I know right now on the wiki it says Motion Adaptive but for the longest time it said Motion Compensated. Just wondering.
RE: New Era: VAAPI with EGL interoperation - -DDD- - 2015-11-07
1st Post: Deinterlacing-Method: VAAPI-MCDI or VAAPI-MADI (Baytrail, Sandybridge)
RE: New Era: VAAPI with EGL interoperation - the-dreamer - 2015-11-07
(2015-11-06, 17:52)fritsch Wrote: Btw. this is by chance the same Series - that the-dreamer is watching? :-)
about what series you are talking? in the logs are only serie201.mkv .... do i have missed something?
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-11-07
I think he renamed the file before - the sample I got from you - looked quite similar codec / audio wise.
RE: New Era: VAAPI with EGL interoperation - the-dreamer - 2015-11-07
i think you confused me with somebody else. i can't remember to send any file to you
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-11-07
Yeah - that's most likely possible.
RE: New Era: VAAPI with EGL interoperation - BigL-New - 2015-11-07
@fritsch
Do you have any reports about problems with intel driver in kernel 4.3.0? On my BeeBox i see in dmesg such messages:
[drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=69823 end=69824)
It's rather unnoticable from Kodi user perspective but i've 6 such messages after 2 days of normal playback.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-11-07
Nope - not yet. Please go to bugs.freedesktop.org and file it accordingly if this did not already happen.
Edit: Check if your kernel contains this commit, mentioned in here: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Edit2: You can try drm-intel-nightly before, please: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/CHANGES
RE: New Era: VAAPI with EGL interoperation - BigL-New - 2015-11-07
Ad. 1 - Yes, my 4.3.0 (vanilla with few OE patches) has this commit.
Ad. 2 - will try :-)
RE: New Era: VAAPI with EGL interoperation - noggin - 2015-11-07
(2015-11-07, 06:22)ilovethakush Wrote: What's the difference between VAAPI Motion Compensated and VAAPI Motion Adaptive and which would you suggest for the chromebox?
I know right now on the wiki it says Motion Adaptive but for the longest time it said Motion Compensated. Just wondering.
This is my understanding :
MADI uses Motion Adaptive techniques. This is where a picture, or elements of a picture, are analysed across fields to detect whether they are static or moving. If they are static then both fields are used to create a frame (i.e. a Weave) - and if they are moving then elements from just one field (i.e. a simple Bob) are used to create a frame (possibly with a bit of filtering to reduce the visibility of the vertical resolution drop and avoid jagged edges) Some deinterlacers use Motion Adaption across the entire field/frame (so switch between all-Bob or all-Weave) whilst others divide the picture into blocks and apply the Bob/Weave decision on a block-by-block basis. I think the Intel approach is the latter. (Some cheap TVs and consumer devices that deinterlace use the former, and you see weave artefacts on shot changes between i and p native content) Effectively with MADI you get the best of both Weave and Bob techniques (either globally across a frame/field or block-by-block within a frame/field).
MCDI uses Motion Compensative techniques. This is where the motion between fields is detected as in MADI and block-based detection is used BUT the motion within blocks between fields is also analysed so a motion vector for each block can be generated, which allows for more than one field to be used to create the output frame even for moving content. The motion vector is detected and allows for the motion to be compensated for, allowing information from both fields to be used to create a frame, even on moving content (you move the content from one field by the motion vectors generated to create the missing field to pair with the field before or after). This is a lot better than the Bob (or Bob with a bit of filtering) that is used on moving content in MADI. It should mean increased vertical resolution on moving content compared to MADI. The quality achieved will depend on the number of fields that are analysed and stored by the deinterlacer, and the motion detection algorithm used.
MADI just needs motion detection, MCDI needs motion detection AND some vector generation algorithm (like block matching) to compensate for the motion. As a result MADI requires less processing than MCDI, so for some very low spec GPUs you can only do MADI.
RE: New Era: VAAPI with EGL interoperation - fritsch - 2015-11-07
Thanks much for the summary. I assume the same.
RE: New Era: VAAPI with EGL interoperation - noggin - 2015-11-07
(2015-11-07, 12:39)fritsch Wrote: Thanks much for the summary. I assume the same.
It's always struck me that the motion vectors in H264 and MPEG2 encoding/decoding would be useful for deinterlacing - yet there never seems to be a way of feeding them from the decoder to the deinterlacer?
I'm old enough to remember the HD-MAC HDTV system - which sent a 576/50i analogue component video signal which had been derived from a 1152/50i HDTV source, and used 1:1, 2:1 and 4:1 interlacing paths on a block-by-block basis BUT also sent the vectors and interlacing technique for each block as digital data in the vertical blanking, to allow a receiver to reconstruct without having to do the motion detecting itself (as the encoder sent the vectors it thought would be best for decoding). The data was carried in VBI and HBI along with digital audio.
H264 and MPEG2 use similar techniques, with the encoder sending the motion vectors rather than the decoder having to detect them, so it seems strange that they can't be fed forward to the deinterlacer?
If the vectors were available, and were useful, they'd reduce the computation requirement of the deinterlacer?