[FFmpeg-devel] [PATCH] avcodec: remove old vdpau decoder implementation
Carl Eugen Hoyos
cehoyos at ag.or.at
Sun Oct 4 13:31:31 CEST 2015
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?
> 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...
> 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.
> 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...
Is there really no way to convince you to invest your
time in something also useful for other users of FFmpeg?
Carl Eugen
More information about the ffmpeg-devel
mailing list