[FFmpeg-devel] Asynchronously delivering data to FFmpeg, and extending the API to do this...
andrey.turkin at gmail.com
Tue Mar 20 13:42:38 EET 2018
I've had a need for something similar a while back and the best solution I
could come up with was using stackful coroutines to invert code flow.
Basically the main program would fire up the the coroutine, the coroutine
would set up avformat context with custom AVIO (avio's read callback
transfers execution back to main program) and then it would go into a cycle
reading packets from avformat. Every time main program needs to process
more data, it would add it to avio's buffer and resume the coroutine;
coroutine would then return into avformat internals which would process it
as if nothing had happened. Basically main program goes into coroutine each
time it needs to process more data, and coroutine returns to main program
every time it needs more data or upon receiving AVPacket from avformat call.
I don't really like that solution as it is a bit fragile, requires some
quirks to work around some issues, hinders readability as well as
I'd really like to see something like new avcodec's API where one can push
data in and then get the processed data out (and avio as a separate
component which can be pulled from?). However that probably requires
(assuming ffmpeg stays in C) rewriting all of avformat into some kind of
state-machine monstrosity which nobody wants to do.
2018-03-20 11:43 GMT+03:00 Hendrik Leppkes <h.leppkes at gmail.com>:
> On Tue, Mar 20, 2018 at 3:06 AM, Philip Prindeville
> <philipp_subx at redfish-solutions.com> wrote:
> > What’s involved in doing this?
> Re-writing every single demuxer in libavformat, probably.
> It seems entirely unfeasible to me to do this, because nothing in the
> architecture even remotely supports something like this. IO is
> fundamentally a "pull" model in ffmpeg, all components pull data as
> they need it, and they don't have any mechanism to give feedback when
> a packet was finished, or anything like that.
> If you have a push data source, the easiest way to interface with
> ffmpeg would be to buffer data and let it pull from the buffer as it
> needs (with blocking when waiting for new data, possibly). It'll tell
> you if it finished a frame because av_read_frame returns one to you.
> Obviously this defeats the purpose of using an event-based source, but
> if thats all you have, then you gotta make it work somehow.
> - Hendrik
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel