On Wed, 11 Nov 2015 08:45:52 +0100 Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Wed, Nov 11, 2015 at 1:27 AM, Clément Bœsch <u...@pkh.me> wrote: > > From: Clément Bœsch <clem...@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. If the goal is fixing VideoToolbox, ffplay.c could probably be used for experiments. (It runs a separate decoder thread, so it might be ideal for trying such async things.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
