On Sun, 4 Oct 2015 11:31:31 +0000 (UTC) Carl Eugen Hoyos <ceho...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
