VDPAU / VAAPI: Use HEVC_MAIN GPU decoding (ffmpeg 2.8+) #7751
Conversation
|
Let's keep it open for testers and merge it after we have bumped to ffmpeg 2.8 which will have HEVC vdpau decoding in a non experimental way. |
|
You should note that the test results were not all positive. @phil65 mentioned issues he does not observe with other players. |
|
@FernetMenta his issues were with standard H264 files, not (only) hevc related. |
|
ahh, I did not read carefully enough. |
|
I think there are some differences in behaviour when seeking in hevc vs h.264. The decoder may act differently in the two situations. I doubt it's something specifically wrong in kodi unless kodi is not even trying to seek to iframes. |
fritsch
changed the title
|
I also added the VAAPI implementation that we need, when we start to use a capable ffmpeg version. Both have been tested and work as expected. |
|
I will prepare ffmpeg 2.8 tree with all our changes. As @FernetMenta and me are running ffmpeg 2.8-pre since some weeks quite succesfully this can go in early to get a lot of testers. This PR here will then start to work and HEVC (VAAPI / VDPAU) acceleration will get integrated. |
|
jenkins build this please @wsnipex: Could you add your famous libva1 0.38 version to our ppa? And if possible also the libvdpau version that includes HEVC support for vdpau? |
|
@Memphiz do you have an idea about what is wrong on OSX? It seems the linker now misses some symbols |
|
you need to disable vtb on osx |
|
Oki - will do. |
|
@FernetMenta disabling it is not a problem, btw. do you know if VTB is the future on OSX? Do we need to go that route? Its implementation rather looks complete: will fix it |
|
VTB is the future. VDA has been removed from El Capitan |
|
check the commit in my master: (do not comment on the typo in commit msg :)) FernetMenta@e86f617 it is called "temp" because vda will disappear in favour of vtb |
|
jenkins build this please |
|
Thanks for the answer. So it's a temporary fix and can be removed later on. |
|
hmm, you won't have a good time if you disable it for iOS :) EDIT: I may be wrong but I thought on iOS we would use vtb already |
|
Lol, yeah just seen it - sorry jenkins. |
|
I triggered manual builds for OSX 32 and 64 |
|
All fine: http://jenkins.kodi.tv/job/OSX-64/5746/ and http://jenkins.kodi.tv/job/OSX-32/5532/ @FernetMenta good to go? |
|
jenkins build this please (ffmpeg is nothing small / little, therefore I want to be fully sure) |
|
looks good to me |
VDPAU / VAAPI: Use HEVC_MAIN GPU decoding (ffmpeg 2.8+)
|
@philipl we are currently running into issues with hevc and certain hevc files, especially with: http://www.libde265.org/downloads-videos/ Tears of Steel and Sintel Users report that this "short stutters", "drops" also happen on windows when using DXVA2. Can you try the 4096 sample on your nvidia gpu? Does that reveal the same issue? |
|
It should start right after the first view seconds. No chance to not see it, thanks for looking into that. |
|
So you said it's visible with dxva2. You didn't say if the other place was vaapi or vdpau or both. Can you confirm which? |
|
In VAAPI on linux it's visible. I guess the user also tested with his Intel hw on Windows. Edit: I don't have any nvidia hw and therefore wanted to know if it's ffmpeg dependend or only intel / vaapi issue. |
|
I don't have access to Intel hevc hardware, but @BtbN took a look and he sees it, but reckons its specific to non-standard resolutions, possible resolutions above the normal 4K (this one is a full 4096 clip). It's quite likely this is a hardware limitation, given the same behaviour on linux and windows. |
|
The forum user rbej reported that everything is fine with the LAVcodecs by Hendrik Leppkes. Though I cannot verify that information as I don't have Windows. The 4096 I have also seen and thought that could be the issue, but this forum post got my interest: Yeah I talked with @BtbN before, so basically you say: All fine on your nvidia? |
|
@Nevcairiel do you have an idea in that regard? (I hope I pinged the right guy, sorry in advance) |
|
I backported all HEVC DXVA2 fixes from LAV to FFmpeg, so any recent git master or 2.8 version should behave the same as LAV, at least on the avcodec side. Of course there could still be something in the DXVA code in xbmc, buy I don't really remember any extra special cases for HEVC there. |
|
@Nevcairiel thanks very much for your answer! |
|
Something new, here: I tried the Sintel 4k sample on windows (mpc-hc): All fine Then I retried on kodi and also on mpv: drops are back. If you play the sintel sample from http://www.libde265.org/hevc-bitstreams/sintel-4096x1744-cfg02.mkv you see directly after 5 seconds when the camera is flying over the mountain that a frame is dropped - i have no idea why this happens. Be it sw decoded or hw decoded. I think there is something wrong in ffmpeg. At least my analysis suggests this. For SW decoding I used a core i5 3400 Mhz and 4 cores ... |
|
I see a hitch at the 10 second mark with software decoding. |
|
@philipl exactly :-) - So, is the file broken? does totem with libde265 drop more intelligently? Why is mpc-hc working? Should we open a bugreport at ffmpeg's trac? |
|
Maybe its related to this issue? It can result in frames being skipped/appear missing. The patch in the ticket is not 100% correct, which is why it was not applied, but it does solve most of the problems. |
|
@Nevcairiel does it work for you and this sample? Edit: I will also start testing right now. |
|
I verified. That patch does fix the problem. |
|
@philipl Very nice. Thanks for reporting back! and obviously thanks to @Nevcairiel for pointing at this fix. I will add my vaapi-hevc results later on. |
|
I posted a new patch in that ffmpeg ticket which no longer breaks other things (that I know of), and still seems to have the intended result, so if you do any testing, use that one! |
|
This fixes the issues! I will add the patch to our ffmpeg-2.8 fork and rebase it away after it landed in your mainline. |
This implements the missing bits to use HEVC_MAIN decoding on nvidia GTX 960+ cards. This was tested by @philipl - We have to wait for ffmpeg 2.8 to land, so that we can use it. Furthermore an nvidia driver >= 355.06 is needed to use it properly.