Sebastian Dröge

Did you get in touch with the cbindgen people to see how this can be integrated without us having to maintain a fork?

Not yet, it's on my list of things to review :)

That's expected and intended behaviour. If there are multiple threads then frames are decoded in parallel and you have to either wait or provide more frames first. Also once you're...

That seems like something to report to https://code.videolan.org/videolan/dav1d but they're going to ask for a C example to reproduce it. Theoretically the above code should work correctly.

According to the documentation of the C API docs, the expected behaviour is ```cpp * Dav1dData data = { 0 }; * Dav1dPicture p = { 0 }; * int...

To be more clear: `get_picture()` called once is setting `drain = 1` and might return `EAGAIN` even if not all pictures were returned yet. The next time you call it...

That would only make sense if you have an iterator of all data until the end of the stream, which is not necessarily the case. You rarely have all input...

> Iterators are lazy, they don't require all the data in memory. You'd need to handle errors in the iterator then as reading can fail, and reading might be blocking...

That's still a pull based API, so would make usage in other situations a bit inconvenient. Also the dav1d API does block under certain conditions, which is suboptimal for Rust...

You're not really using much of the tokio API (nvim-rs seems completely runtime-agnostic fortunately), so switching should be quite simple. Instead of the async `Mutex` you'd use the one from...