[FFmpeg-devel] [HELP] How to regression-test hwaccel/VDPAU?

[Reimar Döffinger]

On 18.09.2013, at 20:28, wm4 <nfxjfg at googlemail.com> wrote:
> On Tue, 17 Sep 2013 20:36:51 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
>> Unfortunately the best solution I can think of is basically hacking
>> in a special "pretend-VDPAU" into ffmpeg.c.
> 
> Why not create a test program that decodes video with vdpau, then reads
> the resulting video frame, and writes it to stdout? I don't think it
> can be avoided to test this on real hardware.

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.

> Putting it into ffmpeg.c sounds pretty evil, though.

Compared to the disadvantages listed above it sounds like angels singing though :-P
Maybe a special program that still does not need hardware would be a solution, but I don't feel good about the idea of either duplicating a good part of ffmpeg.c or writing a very limited test program that will probably soon be too limited.