[Libav-user] avio_* APIs and muxing to memory

Michael Chisholm chisholm at mitre.org
Tue Jun 12 22:00:43 CEST 2012

So I've been looking at how the I/O APIs have changed, to investigate 
updating our codebase to work with the latest libav* libraries.  Our old 
way was to create a custom protocol, but the protocol registration APIs 
have become private.  I think I can use the avio_* APIs, but it's 
awkward.  I'm wondering if there is a better way.

Our app transcodes video in a streaming fashion, so there is not 
necessarily any file to read nor any begin or end to the video.  It's 
just a stream (e.g. network stream) you tap into.  I need to mux encoded 
video data to an in-memory buffer.  So here are some observations:

The avio_*_dyn_buf() functions won't work for that, because that API is 
written to build up data behind the scenes and not give it to you until 
you call avio_close_dyn_buf() to close.  Since I am working with a 
conceptually infinite stream, it would build up data infinitely.

You can create your own AVIOContext via avio_alloc_context() and pass 
some reader/writer functions of your own.  That seems to assume you want 
buffering above wherever the data is ultimately going (where your 
read/writer functions are reading and writing to): the first params are 
a buffer and size.  But in my case, the ultimate destination of the data 
IS a buffer, and it doesn't make sense to buffer a buffer.  That's the 
awkwardness.  I could set the AVIOContext->direct flag, but the docs 
don't say you're ever allowed to pass NULL as the buffer in 
avio_alloc_context(), regardless of that flag.  From inspecting the 
code, it seemed like it may work, but I want to rely on the public 
interface, not a quirk of the current implementation.

So I am just wondering if others have found a good way of doing this? 
Is a NULL buffer supported (if not documented) if you set the direct 
flag?  I am looking at the latest downloadable version, ffmpeg 0.11.1.


More information about the Libav-user mailing list