Login at Kodi Home

gurabli · 2015-07-17, 15:56

What a great work guys, really appreciated!

A quick question: in terms of quality, which is the better and where can I read about the main differences: VAAPI-MCDI or VAAPI-MADI?
How does this compare in quality with nVidia deinterlacing (better, same, worse)?

jteeuw · 2015-07-17, 16:01

(2015-07-17, 15:53)fritsch Wrote: Yeah, then you need to upload the journalctl -a > debug.txt somewhere.

But I think you are affected by the bug mentioned above, so it won't work.

i have read https://bugs.freedesktop.org/show_bug.cgi?id=88331 and think i have the bug to, is there a how-to to build linux kernel from source and applying that patch manually ?

**fritsch** · (This post was last modified: 2015-07-17, 17:40 by fritsch.)

(2015-07-17, 15:56)gurabli Wrote: What a great work guys, really appreciated!

A quick question: in terms of quality, which is the better and where can I read about the main differences: VAAPI-MCDI or VAAPI-MADI?
How does this compare in quality with nVidia deinterlacing (better, same, worse)?

Basically nowhere. Nvidia can take n forward and m backward references to do a spatial / temporal deinterlacing.
Intel only takes one forward frame when it does either Motion adaptive or Motion compensation. So in theory nvidia is better here. But as I don't see much differences between ffmpeg's yadif and VAAPI's MCDI / MADI I did not care much.

Download the burosch samples and compare yourself.

wizziwig · 2015-07-17, 23:16

(2015-07-14, 23:16)puithove Wrote:
(2015-07-14, 22:31)puithove Wrote:
(2015-07-14, 22:30)fritsch Wrote: bugs.freedesktop.org please in VAAPI section. Let's see what the vaapi guys tell.

Ok, will do.

Bug filed here in case you want to track it. Let me know if there's anything I should add, or feel free to jump in.
https://bugs.freedesktop.org/show_bug.cgi?id=91339

I looked at your sample. It uses repeat-first-field flags on the picture headers in order to extend 24fps content to 29.97fps video as specified by the sequence header. Because the repetition pattern is not regular, you end up with stutter because frames are presented at a variable frame rate. Intel is not going to fix this for you because it's not a bug. Their Windows driver will do the same thing. I don't think the field repeat flags are even visible to the VPP/Deinterlacer. This needs to be handled in the player (Kodi in this case) by taking decoded frames and buffering some of the fields to repeat on the next frame. You're basically converting a partially soft-telecined video into a fully hard-telecined one (wiki). The final frames with repeated fields applied can then be sent to VPP.

I covered this topic before in an older thread.

puithove · 2015-07-18, 13:03

(2015-07-17, 23:16)wizziwig Wrote: I looked at your sample. It uses repeat-first-field flags on the picture headers in order to extend 24fps content to 29.97fps video as specified by the sequence header. Because the repetition pattern is not regular, you end up with stutter because frames are presented at a variable frame rate. Intel is not going to fix this for you because it's not a bug. Their Windows driver will do the same thing. I don't think the field repeat flags are even visible to the VPP/Deinterlacer. This needs to be handled in the player (Kodi in this case) by taking decoded frames and buffering some of the fields to repeat on the next frame. You're basically converting a partially soft-telecined video into a fully hard-telecined one (wiki). The final frames with repeated fields applied can then be sent to VPP.

I covered this topic before in an older thread.

Now that you mention it, I do remember seeing your post on this before. Would you mind outlining your findings on the bug report (and therefore also indicating that I'm not the only one having this issue)?

In my mind, it seems like it would still be something Intel would need to fix. I'm not going to pretend I really know a whole lot in this area, but wouldn't the field repeat be applied after the frames are decoded but before being sent to the deinterlacer? This would all be in the VAAPI chain it seems.

@fritsch - any thoughts here? Anything that could be done on the Kodi side?

**fritsch** · 2015-07-18, 13:04

Yeah, sending a PR would be nice, then we can talk about the proper integration?

dirtydesaster · 2015-07-18, 13:33

hey fritsch,
is your OpenElec-Build newer then OE 6.0 Beta 3?

**fritsch** · (This post was last modified: 2015-07-18, 14:06 by fritsch.)

No. It does not have to be. As the code is superior in every VAAPI regard.

Edit: Latest images are rc3 based.

gurabli · 2015-07-18, 22:19

Fritsch, is the Kodi version used here a special version or from the regular repository? I ask this because I use a Dual Audio build version of Kodi, and I wonder if I can use it? The thread is here: http://forum.kodi.tv/showthread.php?tid=192480
And it is located here: https://github.com/xhbl/Kodi_dualaudio
Version 14.2.

**fritsch** · 2015-07-18, 22:21

Read the first page again, please.

gurabli · 2015-07-18, 22:33

Sorry, I missed the PPA part, focused on install part Sad

Then my question would be: Is the Kodi version used here available at github, apart from the ppa, so that the dual audio patch could be implemented?
I know, I want too much, but the dual audio version is very important to me, just as Braswell support.

Ales · 2015-07-18, 22:38

Hi fritsch,
would you mind to write up git sources for packages in point 1.) to first post for non ubuntu users? I have compiled mesa packages from chadversary nv12-transcode git branch a week ago, but this branch no longer exist.

Is pvr.vdr.vnsi plugin working fine for you with recent FernetMenta/xbmc/EGL branch? I have just compiled this EGL branch and vnsi wont load because of API version check. Logs says that plugin API version is 1.10.0, but I'm sure it is not. I have compiled https://github.com/kodi-pvr/pvr.vdr.vnsi just now, which suppose to be 2.0.0 API (confirmed in my /usr/share/kodi/addons/pvr.vdr.vnsi/addon.xml).

FernetMenta · 2015-07-18, 22:45

my EGL branch: https://github.com/FernetMenta/xbmc/tree/EGL
works with vnsi:
https://github.com/kodi-pvr/pvr.vdr.vnsi

But you have to build vnsi against kodi tree:
http://forum.kodi.tv/showthread.php?tid=...pid1934922

**fritsch** · (This post was last modified: 2015-07-18, 22:46 by fritsch.)

@gurabil:
Yes, of course: https://github.com/FernetMenta/xbmc/commits/EGL if you talk about the Ubuntu edition.

@Ales:
Compile fernetmenta's master branch of vnsi addon and add the api bump. This is a really rough edge - I know. We are preparing an Isengard based build - so that average joe can get a running system with current state of implementation. See above.

gurabli · 2015-07-18, 22:49

Yes, Ubuntu version, and many thanks! You are the best devs ever!