File::open() opens the file as O_RDONLY, which can cause issues with the
VA-API driver.
In particular for Intel hardware this will cause allocations to fail, as can
be seen in issue #1449 for intel-media-driver. These failed allocations may or
may not crash the VA-API driver, as the driver might eventually dereference a
NULL pointer.
Fix it by opening the DRM fd as O_RDWR. This is also in line with the examples
in libva-utils.
BUG=b:214478588
TEST=`cargo test --features "video-decoder,vaapi" -p devices vaapi::tests::test_get_capabilities -- --ignored` passes on AMD hardware.
Change-Id: Ie3cf2a6512157a3f23f943b54249eb2928082af9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782999
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Fix the broken timestamp management in the virtio decoder device.
Timestamps are specified by the guest's user-space as a struct timeval,
which is effectively a (seconds, microseconds) pair. This pair is turned
into a u64 with nanoseconds units by V4L2, and passed to the virtio
device in that form.
This is fine so far, save for the fact that libvda works with 32-bit
timestamps. To accomodate that, we divided the original timestamp by
1_000_000_000, passed that truncated timestamp to the decoder backend as
a u32, and when the backend gives us decoded frames, multiplied their
timestamp by 1_000_000_000 again and passed that value as the frame
timestamp to the guest. For some reason, we also used the timestamp as
the key for the `NotifyEndOfBistreamBuffer` event, which forced us to
have a mapping table between an input buffer timestamp and its
corresponding resource ID. This in turn required that each input buffer
has a unique timestamp, lest they collide in the mapping table.
Anyway, the timestamp division by 1_000_000_000 means that any
sub-second timestamp information was lost during the decoding process.
This is not a problem with the Android V4L2 decoder which increases the
timestamp by one second for each frame and does not use sub-second
information, but clients that use *actual* timestamp information (like
ffmpeg) get pretty confused by that and abandon decoding with an error.
Fix this by passing the original 64-bit timestamp to decoder backends,
along with the 32-bit ID of the input resource. This allows backends to
directly send the NotifyEndOfBitstreamBuffer with the currect resource
ID, removing the need for the mapping table and unique timestamps for
input buffers.
More importantly, backends that can work with 64-bit timestamps (all of
them but libvda) can just pass the original timestamp to their decoder
logic and return it as-is in the PictureReady event. Libvda still
requires 32-bit timestamps, so we reproduce the truncation and mapping
table behavior inside the libvda backend (I also tried sending the
32-bit input resource ID as a timestamp to VDA, but it was not happy
with it). At least now that behavior is local to the VDA backend.
Thanks to this change clients other than the Android C2 decoder can get
proper timestamp information. One can argue that the code is also
simpler (except for libvda which adds a simple mapping table that we
were using before anyway).
BUG=b:161774071
TEST=cargo test --features "video-decoder,ffmpeg" -p devices video
TEST=`ffmpeg -codec:v vp8_v4l2m2m -i test-25fps.vp8 test-25fps-%d.png`
in the guest completes successfully with the ffmpeg backend.
TEST=tast arc.VideoDecodeAccel*_vm passes on hatch.
Change-Id: Idb21b4c536acafbdf5458e88cdbc33c9376a405e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3841480
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
crosvm is switching the import style to use one import per line.
While more verbose, this will greatly reduce the occurence of merge
conflicts going forward.
Note: This is using a nightly feature of rustfmt. So it's a one-off
re-format only. We are considering adding a nightly toolchain to
enable the feature permanently.
BUG=b:239937122
TEST=CQ
Change-Id: Id2dd4dbdc0adfc4f8f3dd1d09da1daafa2a39992
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3784345
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Fixes a Rust 1.60 clippy lint:
error: writing `&mut Vec` instead of `&mut [_]` involves a new
object where a slice will do
BUG=b:239075544
TEST=tools/clippy # with rust-toolchain = 1.60.0
Change-Id: I273bd647067b807982f9a9b7248ba788ad3f2032
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3764421
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a reland of commit 213f9fe8a7.
In light of the upcoming VAAPI video decoder backend, add a VAAPI
wrapper crate that exposes a safe Rust API for a subset of the VAAPI C
code. This crate will be called from the VAAPI video decoder backend in
order to decode frames.
BUG=b:214478588
TEST=cargo build --features "video-decoder,vaapi"
TEST=`cargo test -- --include-ignored` in `media/libva` passes on a
device with Intel GPU and libva installed.
Change-Id: I586a160e477e466985c5cfa65a527542ddc03226
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3752274
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This reverts commit 213f9fe8a7.
Reason for revert: breaks the ChromeOS builder.
Original change's description:
> Add a VAAPI wrapper crate
>
> In light of the upcoming VAAPI video decoder backend, add a VAAPI
> wrapper crate that exposes a safe Rust API for a subset of the VAAPI C
> code. This crate will be called from the VAAPI video decoder backend in
> order to decode frames.
>
> BUG=b:214478588
> TEST=cargo build --features "video-decoder,vaapi"
> TEST=`cargo test -- --include-ignored` in `media/libva` passes on a
> device with Intel GPU and libva installed.
>
> Change-Id: I4afa96c49d045251827b97bd78faeba57575aedc
Bug: b:214478588
Change-Id: Ib5a88cd4c5fdd2df2e69fd3a0896ee789585840d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3752267
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
In light of the upcoming VAAPI video decoder backend, add a VAAPI
wrapper crate that exposes a safe Rust API for a subset of the VAAPI C
code. This crate will be called from the VAAPI video decoder backend in
order to decode frames.
BUG=b:214478588
TEST=cargo build --features "video-decoder,vaapi"
TEST=`cargo test -- --include-ignored` in `media/libva` passes on a
device with Intel GPU and libva installed.
Change-Id: I4afa96c49d045251827b97bd78faeba57575aedc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3422779
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
