[MPlayer-users] Issues with -vc ff*vdpau and -vc ff*vdpauold

[wm4]

On Sat, 1 Nov 2014 15:18:26 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On Sat, Nov 01, 2014 at 01:54:42PM +0100, wm4 wrote:
> > On Sat, 1 Nov 2014 13:50:12 +0100
> > Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > > This is an undocumented and completely unnecessary API change, patch sent to FFmpeg.
> > > The ffodivxvdpauold crash is due to a clear bug in FFmpeg, patch also sent.
> > > Yes, the FFmpeg VDPAU code is a bugfest that has new errors every time someone touches it since it has 0 test coverage.
> > 
> > I see two problems here:
> > 1. MPlayer insisting on using the old API (but only sometimes?)
> 
> You mean the codec-based one? That is a explicitly user-selectable
> option.
> The reason it exists is exactly the instability. It seems that Carl
> unfortunately had a point that this old method seems to be the most
> reliable still.

But that code also has been removed from Libav, so they won't even
_think_ about how certain changes affect this code. (On the other hand,
I didn't really look how these work.)

> > 2. VLC developer doing whatever he pleases on the Libav side
> 
> Kind of, but I can't blame them for not testing things that are
> not easily testable.

I was a bit frustrated with the fact that there was e.g. no interest to
keep vdpau preemption-recovery working.

> I could blame people for not writing tests, but on the other
> hand I never finished my attempts either.
> So I'll only blame people for not actually showing interest in
> proper testing, but that seems to be standard operating mode
> for both MPlayer and VLC, unfortunately.

Well, ffmpeg.c now has hardware decoding support, but from what I hear
hw decoding is still hard to test. It's hard to run FATE in a way it
can actually access the GPU. And also, most codecs don't even require
bitexact output, I guess.