Closed sgerwk closed 6 years ago
In case you haven't seen it, this is just a fork of vdr-plugin-softhddevice to add support Intel GPU using vpp/va-api. Nothing has been changed on VDPAU part, but the vpp/va-api hasn't unfortunately been merged to original upstream so far.
You may ask the original author regarding VDPAU and open issues here:
Among the many forks and branches of softhddevice this is the only one that works for me. With the original versions, and also the other branches of this one, what I get is this: http://sgerwk.altervista.org/output2.mpg
So, something must have been changed from the original version, at least in the part that is common between vdpau and vaapi.
Well, sure va-api part has been changed to add vpp. But as long as you don't provide a proper fix as pull request, I don't see anybody fixing things for your OrangePi.
VDPAU seems to be a dead horse. Nvidia did not develop/improve it since a long time and will not do any further development obviuously. Existing hardware will surely work for quite a while, as Nvidia's binary drivers still carries that API and it's also implemented into open source nouveau driver, but missing VDPAUs best things of video post processing.
Alternatively you might checkout that VDR nativ video output for Raspberry Devices:
And please check that thread @ vdr-portal:
look at the last posts, they are in english.
Closing this issue as we're dropping VDPAU support in favor of VA-API from this fork of softhddevice.
To further emphaisize that we're renaming this plugin to vaapidevice. I suspect rpihddevice is the way to go for output on various Pi devices.
Hi,
softhddevice does not play video smoothly on the Orange Pi Zero (is a 32-bit armhf SoC with vdpau). Here is an example output: http://sgerwk.altervista.org/output.mpg
The transport stream coming from the dvb stick looks like this: http://sgerwk.altervista.org/input.ts (same channels, a few seconds later).
mpv has no problem playing dvb:// with vdpau.
Maybe the problem is with the timing of playing of the frames. A quick hack is to increase the delay from 1 1000 to 18 1000 in video.c:
This only avoid frames being shown too quickly, is not a real solution. Maybe the problem is with the SoC being 32 bits.