And now let’s talk about probably the hairiest part of multimedia framework — input-output layer.
Current libavformat
design looks too messy to me and thus my design will be different. I know that some Lucas prefer the old way but I’d rather split protocol handling into several layers.
First, there’s base I/O handler used solely for I/O operations. NAIOHandler
contains functions for reading data, reading data asynchronously, writing data, seeking and ioctl()
for some I/O-specific operations. There will be very few I/O handlers — just file, network (TCP/UDP) and null.
On top of that there’s protocol handler. Protocol handler employs I/O handler to perform I/O operations and provides only reading, writing, seeking and flushing functions. There may be buffered and unbuffered wrappers over I/O handler or something less trivial like HTTP handler.
On top of that there may be a layer or several of other protocol handlers if they need to relate to other protocols (i.e. Some-Streaming-Protocol-over-HTTP).
And on the very top there are I/O functions using protocol handlers for reading and writing data (bytes, X-bit integers, buffers). Those are used by (de)muxers.
That’s the plan, insert usual rant about lack of time, interest and such here.
Nothing about filtering API yet…
[…] will discuss avframe_yield first since Kostya already posted about a better way to handle container […]