[FFmpeg-devel] [PATCH] avutil/WIP: add AVAsync API
u at pkh.me
Thu Nov 12 23:08:09 CET 2015
On Thu, Nov 12, 2015 at 10:15:16PM +0100, wm4 wrote:
> On Wed, 11 Nov 2015 08:45:52 +0100
> Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> > On Wed, Nov 11, 2015 at 1:27 AM, Clément Bœsch <u at pkh.me> wrote:
> > > From: Clément Bœsch <clement at stupeflix.com>
> > > I hope this is going in a direction most developers like. If it's not
> > > the case, I'm of course open to any reworking but please be specific.
> > I'm quite confused by this approach, it doesn't really seem to
> > correspond at all to what we talked about earlier.
> > You can't really put a high-level async API on our low-level sync API,
> > we should start re-thinking the low level API first.
> > The first goal should be to get to a new low level API that implements
> > decoupled m:n output, then you could build a high-level API on top of
> > that, if you wanted something like that.
> > Such a low level API would easily integrate into other frameworks,
> > while this async API seems to be rather rigid and may be rather
> > troublesome to integrate into existing workflows.
> I have to agree. It's just not what I expected. While I think having a
> higher level API in FFmpeg would be very good, the async m:n API is
> what we really need.
> Besides that, the presented API looks pretty rigid and inflexible. This
> is basically the wrong way to start. If you start with a high level
> API, all effort should be put into making that API _good_, and not
> making its implementation a playground for low level API improvements.
Alright. Well I was kind of expecting such comments, so sure, OK. I guess
I was trying to solve several issues at a time. Patch withdraw for now
(but I'm probably going to continue to work a bit on it locally).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: not available
More information about the ffmpeg-devel