200b293626
We were already accepting AvFrame for swscale inputs, but for the output a different SwConverterTarget trait was being used. The old interface had a few issues: - The use of memory mapping traits, putting a dependency on crosvm/base - Insufficient metadata, not being able to represent custom padding on the stride or non-contiguous plane layouts - Inconsistency between input and output types In this patch, we: 1. Introduce a AvFrame-based API to replace the old SwConverter API. 2. Add a TryAsAvFrameExt extension trait inside devices/ to convert virtio handles to AvFrames. (This is placed inside devices to avoid ffmpeg depending on base.) 3. Add a new wrapper type, MemoryMappingAvBufferSource, that wraps a MemoryMappingArena and implements AvBufferSource for it. This was technically not sound, but it's a low-risk attack vector that we implicitly allowed before. The patch doesn't change the behavior; it just makes this assumption more explicit. BUG=b:239897269 TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg Change-Id: Id15e19b7d2452d1bc722a65f941c2c9150876205 Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3889245 Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com> Reviewed-by: Alexandre Courbot <acourbot@chromium.org> |
||
|---|---|---|
| .. | ||
| src | ||
| bindgen.sh | ||
| build.rs | ||
| Cargo.toml | ||
| README.md | ||
| VERSIONS | ||
FFmpeg wrapper
This is a minimal FFmpeg 5.0 wrapper for use with the virtio-video device, allowing to run a virtual video device backed by software decoding or encoding. This is useful for development and testing in situations where no supported video acceleration is available on the host.
Although several FFmpeg binding crates exist, most of them are not able to link against the system FFmpeg, and the only one that does is released under a software license that makes our lawyers nervous. Also they all run bindgen at build time, which is not possible to do under the Chrome OS build system and would require to patch the crate with fully generated bindings.
So taking this in consideration, as well as the extra work that it is to depend on external Rust crates in Chrome OS, it is preferable to add our own simple bindings here that cover just the parts of FFmpeg that we need.
This crate has minimal dependencies ; on the FFmpeg side, it just uses libavcodec, libavutil and
libswscale.
The bindings can be updated using the bindgen.sh script. A few elements that bindgen cannot
generate because they are behind C macros are re-defined in avutil.rs and error.rs, as well as
tests to ensure their correctness.
And that's about it.