Support for tokio AsyncRead/AsyncWrite

[DavidDudson]

We are using tokio/futures, however interacting with this library is rather complicated.

Currently, we have to use a SyncIoBridge and spawn a tokio::task::spawn_blocking in order to run the demuxer inside a tokio async runtime. This is not ideal. Theres a few ways I can see us being able to avoid it.

1. Add tokio support to ac_ffmpeg (AsyncRead/AsyncWrite/AsyncSeek)

• IO.from_async_read(AsyncRead)
• IO.from_async_seekable_read(AsyncRead + AsyncSeek)
• IO.from_async_write(AsyncWrite)
• IO.from_async_seekable_write(AsyncSeek)
• IO.from_byte_stream(Stream<Item=[u8]>) // optional, but would allow chaining in an async stream
• These would need to be under an optional crate feature tokio

2. Expose IO::new publically so others can create the above themselves.

Im not sure what the scope of this library is, and whether option 1 is reasonable, happy to whip together a PR either way, just thought I would reach out and ask first.

[operutka]

I know about this limitation but I'm afraid that there isn't a better solution than using the SyncIoBridge together with blocking tasks right now.

Last time I checked this, the problem was in the FFmpeg itself. You can certainly create an asynchronous IO and pass it to an AVFormatContext. However, if your IO returns EWOULDBLOCK, the demuxer will treat it as an error instead of propagating it back to the caller.