fc891cea82
The virtio video decoder device is currently only available under very
drastic conditions: a build linked against libvda (a ChromeOS-only
library that needs the cros chroot to be built and linked against), and
a ChromeOS-flavored Chrome instance running alongside crosvm, so the
browser can provide the video decoding service through Mojo.
This makes the decoder device very difficult to develop on for
non-Chromies, and also for Chromies actually since they will always need
a DUT to test it on.
This patch introduces an alternative decoder backend based on
ffmpeg's libraries that performs decoding on the host's CPU. It supports both
guest pages and virtio objects as target, and can be considered a
reliable and predictable way to test the decoder in any environment.
We introduce our own ffmpeg bindings after a quick state of the art
revealed that the existing ones were all unsuitable, either for
technical or licensing reasons. Doing so is also not a big effort and
does not add any new external crate dependency to crosvm.
BUG=b:169295147
TEST=cargo test --features "video-decoder,ffmpeg" -p devices ffmpeg
TEST=v4l2r's simple_decoder example decodes test-25fps.h264 properly with the
following command:
./simple_decoder test-25fps.h264 /dev/video0 --input_format h264 --save test-25fps.nv12
TEST=ARCVM Android youtube plays videos correctly when the ffmpeg
backend is used.
Change-Id: Ic9c586193f7939f2a3fe59d009c3666585a8bbc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026355
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
1.3 KiB
FFmpeg wrapper
This is a minimal FFmpeg 4.4 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.