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

[Zhao, Halley]

Thanks your explanation.
1. I know our team/Intel plan to maintain this lib for the following years. I'm a developer, I can't promise more.
2. as to libxyz, it is some way like investment: Nobody is sure of the future, but make decision basing on investment and profit.
  A small yami wrapper enables rich codec on Intel platform, I think it deserve to try. Moreover, you can disable it easily if you don't like it.



-----Original Message-----
From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Ronald S. Bultje
Sent: Monday, January 12, 2015 10:35 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami

Hi,

On Mon, Jan 12, 2015 at 9:04 AM, wm4 <nfxjfg at googlemail.com> wrote:

> On Mon, 12 Jan 2015 08:24:35 -0500
> "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
>
> > Hi,
> >
> > On Mon, Jan 12, 2015 at 12:59 AM, Zhao, Halley 
> > <halley.zhao at intel.com>
> > wrote:
> >
> > > I understand you concern.
> > > The wrapper doesn't help much to ffmpeg itself, however, it 
> > > benefits
> much
> > > to the apps uses ffmpeg, to pick up hw capability for codec.
> >
> >
> > So specifically, what are the features that you get with yaml that 
> > ffmpeg doesn't already provide (that is: yaml is itself just a 
> > wrapper for other stuff; what does it wrap that ffmpeg doesn't have 
> > already?). I see h264enc/vp8dec/vp8enc/vp9dec/jpegdec/jpegenc vaapi. 
> > Anything else? Why
> not
> > just implement these in ffmpeg directly?
>
> From what I can see:
>
> - libyami doesn't require the relatively terrible boilerplate for
>   hwaccel (creating the hw decoder yourself, maintaining a surface
>   pool, etc.), making this lib very attractive for those who want
>   something simple, and who possibly don't even want to depend on 
> ffmpeg
> - uses some new APIs (not supported by all drivers yet), which work
>   around vaapi suckage, such as requiring a shared context. Namely, the
>   dma_buf stuff.
>
> I wonder how well the latter actually works...


So I don't know if anyone remembers me ranting about libxyz suckage, but yami sounds a lot like xyz. So: what are the chances that five years down the line, this lib ends up being unmaintained, having security issues, portability issues etc., and us basically just being stuck with yet another xyz that doesn't really solve our issue so we have to re-do it internally anyway a few years down the line, wishing we had done so a few years earlier?

There's examples of good xyzs, e.g. x264 is a most wonderful software project; there's also examples of (imo) fails, such as librtmp. What guarantees do we have that yami is a good xyz?

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel