[MPlayer-users] VDPAU decoding in MPlayer broken by recent FFmpeg changes

[Reimar Döffinger]

On 12.09.2013, at 22:39, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On Thu, Sep 12, 2013 at 06:33:30PM +0000, Carl Eugen Hoyos wrote:
>> Reimar Döffinger <Reimar.Doeffinger <at> gmx.de> writes:
>> 
>>> What are your reasons to want the old code back?
>> 
>> It was tested extensively (to an amount which we 
>> cannot reach now) and I don't remember open bug 
>> reports.
> 
> Though it did have bugs, for example an aspect change
> would incorrectly discard previous reference frames due
> to reinitializing VDPAU.
> But that is not relevant long-term, if we are the only
> user of that code with nobody maintaining it it's just
> not a viable long-term solution.
> We've seen that well enough with the slice rendering.
> And any HEVC hardware acceleration (which is certainly
> going to be more important than MPEG-4 due to the decode
> effort it requires) is likely to use hwaccel.
> So _only_ supporting the old API is very much not a valid
> long-term strategy IMHO.
> Now nothing against supporting both, but
> a) someone needs to implement it
> b) we still need testing and bug reports to know what issues we have

Both are now supported, append "old" to the codec name to use the old code.
However the old code has one more limitation:
It is not possible to extend it to automatically use VDPAU when the codec is supported by the hardware.
So I'd still appreciate help getting the new code to work properly.
This means in particular proper bug reports for MPEG-1/2, H.264, VC-1 and WMV3 issues specific to the new code, and someone debugging the differences for the problematic MPEG-4 cases (shouldn't be that hard in theory now that both methods are supported, somehow vo_vdpau doesn't get the same data - the question is how it differs and why).