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.
Thanks
Andy
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
