[FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami

compn tempn at mi.rr.com
Wed Jan 14 15:23:04 CET 2015


On Mon, 12 Jan 2015 10:30:34 -0500
"Ronald S. Bultje" <rsbultje at gmail.com> wrote:

> Hi,
> 
> On Mon, Jan 12, 2015 at 10:07 AM, compn <tempn at mi.rr.com> wrote:
> 
> > On Mon, 12 Jan 2015 08:24:35 -0500
> > "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> >
> > > Anything else? Why not just implement these in ffmpeg directly?
> >
> > because (i'm guessing) they are developing libyami with other
> > projects, not ffmpeg.
> >
> > i know everyone wants to reinvent the wheels here, but also that may
> > have a detrimental effect on development if nothing gets in except
> > ffmpeg-style-wheels.
> 
> 
> These are two extremes: every single C function should be shareable
> between any two random software projects, or we should have no
> dependencies at all.
> 
> In the real world, we balance these extremes by the practical
> implications (benefits vs. risks) associated with it.
> - too big dependency tree (how long does it take you to build gnome?
> I know users don't care, but what if you're a dev? I'm a dev)
> - are talented developers likely to maintain the alternate codebase
> (as opposed to a hypothetical impl in our tree)?
> - are talented (app) developers likely to use ffmpeg if we use a lib's
> implementation, rather than our own?
> - will they be around in 5 years? will they fix bugs? security issues?
> portability issues? will they care about ffmpeg-specific exposed bugs
> in their code?
> 
> vs.
> 
> - how long will it take us to implement these features ourselves?
> - are we the right people to take on long-term maintenance of such a
> feature?
> - are talented (app) developers interested in such features likely to
> use it if we directly provide it, as opposed to through some other
> lib (which is linked into ffmpeg)?
> - are talented developers likely to help us maintain the feature in
> our codebase as opposed to the impl in another lib?
> 
> It's very complex. I don't have straight answers to all of these.

thank you, this is exactly what i was thinking and there is no easy
answer to any of these questions. i really appreciate the long writeup.

i say if intel is going to maintain it, go for it.

if we are going to reimplement all this into vaapi ourselves, we need a
test lib for it anyway (also to steal from although its c++).

i think whats going to happen is either we get a bunch more new api
(how much longer do you think vdpau api will be used?), or a bunch more
new features in those old api (encoding and decoding of a ton of
formats/codecs and extendable in the future for future codecs like
h265). which still means a new api change in vaapi/vdpau with old cards
not supporting xx feature and new cards supporting it.

imo theres no way we can maintain all hardware and all features
ourselves. how far are we on a hwaccel fate test ? we cant even test
the features we have now automatically!

we can either convince devels who are working on other libs
to do it The FFmpeg Way™ and we review and help those devels, or we go
along with whatever lib wrapper and move on.

the bikeshed being 'we are tired of more api that might or will go
unmaintained' vs 'we just want it to work for a few years until the next
thing comes along'.

i'm not the one who has to maintain it. if the underlying lib being
unmaintained in the future is an issue, how much of an issue is it when
theres only one or two active devs with the hardware required?

i wonder how vlc does its hwaccel testing? maybe we should steal from
them.

-compn


More information about the ffmpeg-devel mailing list