[FFmpeg-devel] [HELP] How to regression-test hwaccel/VDPAU?
Reimar.Doeffinger at gmx.de
Thu Sep 19 00:05:02 CEST 2013
On Wed, Sep 18, 2013 at 09:46:51PM +0200, wm4 wrote:
> On Wed, 18 Sep 2013 21:29:13 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > That is a lot of effort (one program for each of old-style VDPAU, new-style VDPAU, VAAPI and DXVA and maybe even the OSX one), doesn't allow proper regression testing (the data passed to the VDPAU decoder might change without triggering a visible change in that specific case, for non-bitexact formats like MPEG-2 and 4 different hardware and/or drivers can give different output, so we at least need per-hardware reference data), is almost useless for debugging (you see it broke, now how do you even correlate the output frame to the changed data?), and testing all formats will require you to both swap cards (no, using them at the same time doesn't really work in my experience) and reboot operating systems.
> > I also have some doubts how many FATE systems we would find for that for automated testing.
> > And if you have an AMD system you'll still get the random hangs when the GPU gets corrupt data. I prefer development where making a mistake does not result in a hard reboot...
> > Or to put it differently: That does not sound like an improvement over visual inspection of MPlayer output to me.
> Well, then let the test program test the bitstream buffers only. It
> doesn't really have to use the vdpau API.
> This probably won't work for
> libva, vda, and dxva.
It seems that these all would require a complete stub to be written,
which would be quite some effort and raise the question how to make the
stub be used (LD_PRELOAD? Not portable and not working with static
builds though). The design choice of direct linking is rather
unfortunate in quite a few aspects.
> But mplayer doesn't support them anyway.
I would prefer something that worked for them, too, though.
Though actually VDPAU is the larger concern mostly because of the
regressions in the hwaccel API.
> (Although for vda there's still this pseudo read-back decoder.)
Requiring to have OSX. I guess we will have some OSX machines
so we could probably add it to FATE, but a lot of developers
will not be able to regression-test this themselves...
More information about the ffmpeg-devel