[FFmpeg-devel] [PATCH] avcodec: remove old vdpau decoder implementation

[wm4]

On Sun, 4 Oct 2015 11:31:31 +0000 (UTC)
Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> wm4 <nfxjfg <at> googlemail.com> writes:
> 
> > On Sat, 3 Oct 2015 22:23:21 +0200
> > Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
> > 
> > > On Saturday 03 October 2015 10:05:29 pm wm4 wrote:
> > > > Ping. Will push in 24 hours or so if nobody complains.
> > > 
> > > The reason I am against this is just that users told me 
> > > repeatedly (in person) that they switched from the dark 
> > > side to FFmpeg because this (and possibly) other API 
> > > was removed there.
> > 
> > As I've said several times, progress is not possible (or 
> > requires lots of wasted energy) if we don't drop obsolete 
> > APIs.
> 
> What makes the old API "obsolete"? You?

Existence of a better API that does everything the old API did. How is
this so hard to understand?

> > And at this point, the new vdpau API is definitely 
> > superior over the old one. I don't know
> > why anyone would want to use the old API.
> 
> Maybe other people (including other projects) prefer 
> to work on bug fixes and new features and don't want 
> to waste their time rewriting APIs every year?
> 
> > > I simply don't understand what the advantage is of 
> > > removing a few lines of code.
> > 
> > That's not a few lines, that's over 600 lines.
> 
> So why do we still need libavresample? It certainly has 
> more than 600 lines...

It wasn't my idea to duplicate Libav's effort of writing a resampler
library.

On the other hand, FFmpeg constantly keeps duplicate things that come
from Libav merges. Libav got rid of the old vdpau code already 2 years
ago, but FFmpeg reverted this.

I can't agree with this hysteric way of development.

> > To make it worse, it's all duplicated code
> 
> You are talking about the new API?
> 
> > duplicating functionality the vdpau hwaccel provides.
> 
> Yes, by duplicating the existing vdpau code in new 
> files, and duplicating the code again for every new 
> hardware acceleration.
> I do understand that this cannot be avoided, I just 
> don't understand why this is used as an argument.

Your point makes no sense. The code is duplicated for the same
decoding API.

> > Unlike the hwaccel code, it's not cleanly integrated 
> > either. Just look how intrusive it is, while hwaccel 
> > is basically just a bunch of callbacks in the right 
> > places (and works for multiple hwdec APIs, not
> > just vdpau).
> 
> And everytime a new hardware acceleration is added, new 
> callbacks are needeed...

They're not by far as intrusive is the vdpau code. The vdpau code was
just blindly hacked into all the decoders, while the new hwaccel API at
least provides _some_ abstraction and isolation of the API-specific
bits.

If you didn't like the new vdpau API, you should never have merged it.

> Is there really no way to convince you to invest your 
> time in something also useful for other users of FFmpeg?

Not wasting my time with these discussions would help. You know the old
vdpau code has to go one day. And it's been over 2 years since it was
deprecated (and also removed in Libav), and the most important API
users (vlc, kodi) use the new API. Why still refuse?

Apropos useful, the new vdpau API is almost intuitive to use. With the
old API, the only chance to understand how to use it was to
reverse-engineer mplayer code (yes, that's also how the new vdpau
hwaccel was written). I hope there will be further improvements to the
hwaccel code. It's annoying that it happens incrementally and very
slowly, but at least some progress.

Anyway, if this patch is still contended, we should use our fabulous
new voting system.