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

[Reimar Döffinger]

Ilja Sekler <ilja_sekler_ at gmx.de> wrote:
>Am 12.09.2013 10:10, schrieb Carl Eugen Hoyos:
>
>> Ilja Sekler <ilja_sekler_ <at> gmx.de> writes:
>>
>>> I have noticed that the removal of the old VDPAU interface was
>>> reverted, but the build of MPlayer r36417 fails on my Fedora 19
>>> system with
>>>
>>> ffmpeg/libavcodec/libavcodec.a(mjpegdec.o): In function
>>> `ff_mjpeg_decode_frame': mjpegdec.c:(.text+0x6cd4): undefined
>>> reference to `ff_exif_decode_ifd' collect2: error: ld returned 1
>>> exit status
>>
>> Yes, it appears that I had added "CONFIG_EXIF=yes" to my config.mak
>> file. (You may have to delete ffmpeg/libavcodec/libavcodec.a)
>
>I see, thanks. With this clue, I could identify the commit (r36427)
>that 
>had to be applied on top of r36417 to allow the build to succeed.
>
>> but I prefer using working vdpau;-)
>
>Could you please shed some light on the rationale behind the recent
>VDPAU turbulence? Should MPlayer return to the old interface, the one 
>which works really well?

I would prefer to support both to be on the safe side, but that needs a bit of work.
Fixing the new one would be good too.
In both cases I would need feedback on what works and what doesn't.
The only issues I know about is VC1 artefacts (which I cannot reproduce) and packed B-frames MPEG-4 (which I cannot even test).
A disputable issue is that the new API will do multithreaded parsing, which requires a good bit more GPU RAM but provides better performance....
What are your reasons to want the old code back?