AMD/ATI Support #90
Comments
|
There aren't any Intel specific in the plugin, so AMD should work, if their VA-API drivers are functional. What does the |
|
thanks for the quick answer on this. I currently cannot access the VDR with the AMD video card, but will be able to access it on Monday. Will look deeper into this then and get back. |
|
I just added a new PR including a script to generate a system report. You could use it to provide the information here. |
VAAPIDEVICE SYSTEM INFORMATION REPORTinxivainfoffmpeggccsvdrpsend |
|
This is what is logged to /var/log/syslog Mar 12 20:36:12 mira vdr: [4223] VDR version 2.2.0 started (the last two messages are continuously repeated until I kill the vdr process) |
|
I did two more tests:
Not sure if this is of any help or if it even makes sense to continue to try getting vaapidevice to run with AMD. |
|
Could you enable and share ffmpeg/libva logs by setting the |
|
With -t 0xF00 the log looks as follows: Mar 13 20:21:49 mira vdr: [2577] VDR version 2.2.0 started |
|
You're using the "noop" sound module and therefore getting those ringbuffer/transfermode errors. Somehow the "svdrpsend" section is empty in your system report as it would show up the used command-line parameters. |
|
Unfortunately, adding "-a pulse" does not really change anything: Mar 14 20:19:31 mira vdr: [2704] starting plugin: vaapidevice svdrpsend indeed does not give anything back on this VDR. Even when I run the script while vdr with vaapidevice is running. |
|
When I set "-v none", sound is working and svdrpsend is giving a result: svdrpsendINCLUDE THIS REPORT INTO YOUR GITHUB ISSUEWith vaapi (i.e. when I remove the "-v none" again), no svdrpsend, also I just see the OSD (which does not vanish as it would be normal after a few seconds), and no sound. I believe somewhere vaapidevice is running into a deadlock blocking the entire vdr. |
|
Sorry for the churn here. I just did a "git pull" and now actually I am getting a working picture and sound. Since my last pull was from yesterday, I suspect one of the commits of today made this work. |
|
Very nice to hear! Out of curiosity, can you run the plugin with -t 0xFC0 and post the log so we could see what hw capabilities are being detected and used and if there is any room for improvement on ATI/AMD devices? |
|
I am currently investigating what made this work. Actually, it's now kind of working. Instead of nothing I get a picture. However, when I switch channel, it crashes again. What I found out so far (by trying around with "git revert") is that the following commit made the difference: 44b0478 |
|
I played through the different changes in that commit. Actually, the difference is made by putting the if(VaapiVideoProcessing) conditional around the call to vaDestroyConfig(). If I take the latest version in git, with all the current commits, and then apply the following patch, it crashes again as it did before: |
|
With current status, now for AMD/ATI the following is working:
Problems:
Glitches:
Still, if we manage to remove the crashes, it is at least usable. Regarding the logging with the "-t 0xFC0" parameter, I saw that this log gets extremely long. Is there anything you are interested in in particular, so that I can filter the log? |
|
Channel switching and changing settings via OSD that affect video display both work when I deactivate postprocessing (i.e. removing the line in video.c that sets "VaapiVideoProcessing = 1"). Therefore, I assume currently postprocessing is done somewhere when it better shouldn't be. However, even with that change still the crashes when resizing happened, so that crash is caused by something unrelated to postprocessing. For the glitches, the first one seems not to be caused by the scaling. It seems that for some reason 576i (or MPEG2) has non-optimal quality in the decoding. HD (H264) material looks much better at the moment. Would be interesting if there is anything that we can do to improve 576i. |
|
From logging I'm interested in the lines from vdr start to when the first few frames are actually shown on screen. The detected postprocessing filters etc. The crashes are an obvious driver bug but can maybe be worked around. Will this very experimental patch help? |
|
Ok, here the requested log. I will try the patch in a new minutes. Mar 14 23:09:04 mira vdr: [16583] VDR version 2.2.0 started |
|
I actually recorded this log already yesterday evening, hope that's fine. |
|
OK, the patch makes a difference, but does not fix all crashes:
|
|
Looks like the driver has more than one issue. We would need backtraces of the crashes (see the link in ISSUE_TEMPLATE.md) to work with them further. |
|
Oh and please upgrade to more recent libva. I don't think AMD/ATI support was properly implemented yet in library&driver versions earlier than 2.0 |
|
Unfortunately, updating libva seems not to be too easy. I try to find more information how I can do this upgrade in a safe way, in worst case further testing with a newer libva needs to wait until May when Mint 19 is going to be released (apparently with libva 2.1.0). I still did the backtrace. The bt for the crash when switching channels looks as this: Indeed when I comment out in video.c line 3223 the block then the crash disappears. The crash when changing window size has following backtrace: did not find an easy way to get rid of this crash. |
|
did "mpv --hwdec=vaapi --vo=vaapi --msg-level=all=v some.ts" work? |
|
yes, mpv plays files via vaapi without crashing. |
|
so there is hope ;-) |
|
you can also try to use the ffmpeg for Kodi it has some fixes for AMD |
tell when playing silence, use macro for default AudioBufferTime
I currently run two VDRs, one based on Intel and the other with an AMD Radeon HD6450 graphics. I also gave now vaapidevice a try on the AMD one, but it only showed the OSD (which was "hanging"/not disappearing anymore) and no picture or sound. I have not done any further research (like checking the logs) so far since I am not sure if vaapidevice is supposed to work on AMD or not. Would be great if one of the devs can clarify if this plugin aims at supporting also AMD or if it is purely restricted to Intel graphics (which would be OK since the old softhddevice plugin with vdpau works reasonably well for AMD).
The text was updated successfully, but these errors were encountered: