[enigma7]

mpv --hwdec=vaapi gives same result ans correct image.
I've set KODI_GL_INTERFACE=GLX in environment file, reboot computer + check printenv is set
No i have vdpau
but vdpau bob gives same result, half screen
but now i have new choices without crash Bob, Temporal temporal half .
rest of result in bug tracker

[enigma7]

mpv --hwdec=vaapi  gives same result, : correct image
i have set variable KODI_GL_INTERFACE  to GLX in variable file, reboot computer , check printenv variable is set.
Then lunch kodi 18.5
Vdpau bob gives same result, half screen picture .
I have now new options, including normal bob that not chashed . fine
I diden't find preformance differences between them, is it normal not sure...
Next of story on bug tracker

[enigma7]

The setting :variable KODI_GL_INTERFACE  to GLX solves definitively the hang issue.
I think this is important for AMD cards, is it possible to put the words in red color in the wiki?
Shame Kodi haven't a autodetect mechanism like VLC for that.

But i still have problem, il will explain, here in details.
On the left row Video setting when video is playing
On the right row below Deinterlace method show with osd player Info (key menu 'o')

off                   ->    none                      (can't be used for broadcast, here all is interlaced (DVB-T, Sat etc)
Vdpau - bob     ->    Vdpau - bob            (still result half screen compressed image, see image on bug tracker)
bob                 ->    bob                        (no Vdpau)
temp               ->    Vdpau  - temp         (information don't match,  my default setting)
temporal(hallf) ->    Vdpau - temp - half  (information don't match, bad picture)

As you can see, for my setting, there is a doubt it is Vdpau or not.
What is right, my setting or osd info ?
How to retrieve the info , any other debug or log ?

As I have mention in bug tracker there is a big performance of cpu usage between VLC and Kodi for same video clip.
But a member respond to me that Kodi is doing more processes as VLC, i agree with he but how to isolate the pure video process for cpu usage ?
Vlc use ffmpeg with Vdpau too for decompression .

Last question : will Vdpau be keeped for Kodi 19 ?
If yes can i try it today with Vdpau?

[FernetMenta]

The setting :variable KODI_GL_INTERFACE  to GLX solves definitively the hang issue.
I think this is important for AMD cards, is it possible to put the words in red color in the wiki?
Shame Kodi haven't a autodetect mechanism like VLC for that.

You can't compare Kodi to VLC in this regard because VLC does not render the the video surfaces directly with OpenGL. Means VLC does not use the buggy code in mesa. The fact that you are facing the issue with vdpau and vaapi is a clear indicator that they messed it up in mesa.

[enigma7]

OK OK OK... forgot my comments on VLC..

But it would be nice if somebody would respond to my 2 questions above that are related on pure Kodi codings:

- my mistakes for temp / Vdpau  - temp  and  temporal(hallf)  / Vdpau - temp - half  , what is right and what is wrong ?
- my question for Kodi 19 and Vdpau

[yol]

- my question for Kodi 19 and Vdpau

To the extent of my knowledge, there are currently no plans to remove the KODI_GL_INTERFACE environment variable. But VDPAU is deprecated nevertheless and I can't promise that it will be kept forever. This is also an incentive to fix the vaapi side of things ;-)

As you can see, for my setting, there is a doubt it is Vdpau or not.

I don't know a lot about the VDPAU code, but with VAAPI it's like this (I'm just going to assume VDPAU is the same): Changing deinterlace method does not change whether VAAPI is used for decoding, that is completely independent. Using a non-VAAPI deinterlacing method only means that the deinterlacing will be done in software by the CPU and not by the GPU hardware. So the "mismatch" you are speaking of is not really there.

As I have mention in bug tracker there is a big performance of cpu usage between VLC and Kodi for same video clip.

I won't go into this here. As FernetMenta mentioned, you just cannot compare the render pipeline of VLC and Kodi in this way. If you want minimum CPU usage, use a video player and not a media center.

As for the actual bug, I'm still moving around and haven't had the chance to look at it.
@FernetMenta Do you already have a specific mesa bug in mind/identified? If so, that could speed things up for sure.

[FernetMenta]

@yol I haven't spend much time on it because on Ubuntu 19.10 there's a good chance that gpu hangs when playing interlaced content du to this mesa bug:

https://gitlab.freedesktop.org/mesa/mesa/issues/2321

There is another bug referenced:

https://gitlab.freedesktop.org/mesa/mesa/issues/2454

Maybe all related.

[enigma7]

@FernetMenta
Yes your 2 links show VAAPI bugs. I'm setting to Vdpau  with environnement variable . Hope I'm no more concerned by this

@yol
Thanks for your post 21, it's more clear now.
My only bug now is Bob interlacing
Bob setting is software interlacing, picture is correct but is software.
Vdpau - bob gives me half screen compressed, any idea to solve this ?
On bug tracker side no reaction for this bug….

And my last question was : can i test Kodi 19 and Vdpau now, and if yes how ?

[FernetMenta]

@FernetMenta
Yes your 2 links show VAAPI bugs. I'm setting to Vdpau  with environnement variable . Hope I'm no more concerned by this

On AMD hardware vdpau and vaapi are just two APIs that share the same implementation. This is why you encounter the same
bug with both, vdpau and vaapi. Moving to vdpau is pointless in this case.

[enigma7]

Ok .
The only positive point is that normal bob (not Vdpau - bob) is working with Vdpau environment variable.
It makes Kodi to crash without.

[asavah]

Disclaimer: I'm not a pro coder and my "investigation" of the issue might be wrong.

These are 2 different bugs in mesa 20.x.
First https://gitlab.freedesktop.org/mesa/mesa/issues/2454 - https://gitlab.freedesktop.org/mesa/mesa...6cc0a4dcbb
The commit above is totally wrong:
1) https://gitlab.freedesktop.org/mesa/mesa...26_277_301 it deletes the original surface thus invalidating VASurfaceID hence "invalid VASurfaceID" errors in the log.
Edit: and looks totlaly wrong to me - why deinterlace NV12 in vlVaDeriveImage() ?
Why deinterlace is forced when no one "asked" for the surface to be deinterlaced ?
They "fixed" a VLC related bug, but broke others ...
2) It somehow enables software postprocessing in Kodi (like with Intel driver) - options "Deintelace" and "Bob" shouldn't be available on amd, because amd driver does not implement/allow copying frames back to memory and Kodi crashes in copy_frame() function.

I have a ryzen 2400g with kernel 5.5.x and mesa 20.
Reverting the aforementioned commit removes sofware Deinterlace,Bob and there no longer any "invalid VASurfaceID" errors in the log
Vaapi-madi works fine for me.
Vaapi-bob is exacty as originally described - halfscreen video with the lower half being a corrupted mess.
So it is broken in more places than one.
So far I wasn't able to find the origin of vaapi-bob issues, but I'm convinced that it's mesa problem and not Kodi.

Rant:
Amd (re)learned how to make great hardware but their drivers (both windows and linux) are written by monkeys.

[enigma7]

@asavah
Yes i can confirm, with VLC same interlaced content, same shit mesa driver, with setting auto or forced VDPAU for interlacing, it's working without the screen bug.
I can imagine Kodi hasn't same mechanism for some good reason.
Shame we can't have accelerated VDPAU deinterlacing with Kodi, here all broadcast are interlaced!
In waiting time i have set to normal Bob and post the bug in bug tracker #17314

And yes blame AMD and there bad drivers coders

[asavah]

Nah, blaming them is pointless, while they do deserve the blame - the amount of nasty (crashes, hangs) bugs in amdgpu (kernel) and mesa has been pretty high for long time.
It would be nice to find the root cause and fix it, but my coding skills are very limited, I'm like an old dog - can understand a lot of human speech but can't talk, only barf,
I can read the code and understand parts of it but I can't write my own, I'll continue digging tho when I get some free time.

[fritsch]

Guys, be very, very happy that you don't have to use fglrx anymore. While there are bugs, and yes the bug that hits oneself is always the one with the most priority 111!!, AMD folks do a very good job since a very long time. With just 5 or 6 devs they engineer this driver while Windows AMD team has felt 100+ developers ....

[asavah]

@fritsch This bug does not affect me - I don't have interlaced content, in order to reproduce the bug I had to download a few samples )
Amd having 5-6 devs is not my problem as amd customer, they explicitly state linux support on their product pages.
They should have enough money now to get bigger and better team working on linux drivers.
I do remember fglrx and xvba (/me shrugs) ...