Changed missed by accident in 61d72266 (media: ffmpeg: Take AvBuffer
directly in AvPacket::new_owned). The later commits were tested but it
was grouped into the wrong commit in rebase.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: Iabdcc98833b24271f4701fb210e0e5733d1f9f12
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868594
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Creating a context frequently involves optional parameters, and the
builder pattern handles this more descriptively, especially in the case
of an encoder context.
Encoder support is coming in a later commit, but it's a good idea to
align the decoder to use the builder pattern to ensure a consistent way
of doing things.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices video
Change-Id: I92bd5f72b638c13a3257d54238b1beb229c64fa0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3856042
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
With more types going to support AvPacket in the future, it's probably
more maintainable to separate the construction of AvBuffer from the
consumer types.
The borrowing constructor will still take AvBufferSource generically as
it doesn't have a buffer object to construct.
As AvBuffer is directly used in the interface now, make its definition
and methods public.
BUG=None
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p video
Change-Id: I0959d383438a94d562fc6ff34c40389e98be7bfd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3833772
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
The previous signature allowed lifetime laundering if code like below
was used:
impl<'a> AvBufferSource for &'a mut [u8] { ... }
fn foo() {
let mut storage = vec![];
let buf = AvBuffer::new(storage.deref_mut());
drop(storage);
// buf can be used after free
}
Add a 'static bound to prevent it.
BUG=None
TEST=cargo build --release --features "video-decoder,ffmpeg" -p devices
Change-Id: Ifda2793a3e3d4d8b400fa076f1d6f9474d0ae159
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3833771
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
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>
Update the ffmpeg bindings and build script to use 5.0 and update our
code to match the API changes since 4.4.
BUG=None
TEST=cargo test -p ffmpeg
TEST=cargo test --features "video-decoder,ffmpeg" -p devices video
TEST=v4l2r example from the crosvm book passses.
Change-Id: If7820a4dd270d715e89c60d55f89b9730f40e864
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3835501
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This is actually highly unsound since it allows you to write arbitrary
garbage to the buffer pointer fields.
BUG=None
TEST=cargo test -p ffmpeg &&
cargo test --features "video-decoder,ffmpeg" -p devices video
+ v4l2r test from crosvm book
Change-Id: I77bd32b856afef8538791a99829f7248cd77787e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822433
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
We're going to use this pattern more in future CLs, so factor it out to
a helper.
BUG=None
TEST=cargo test -p ffmpeg &&
cargo test --features "video-decoder,ffmpeg" -p devices video
+ v4l2r test from crosvm book
Change-Id: Ic20555f8a4ebf0403cc2f933c92bb9bb1d3f51f9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822432
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
FFmpeg requires buffer alignment in case of SIMD-accelerated codec
implementations. This patch prepares for exposing the
respective requirement in the virtio-video interface.
BUG=None
TEST=cargo build -p ffmpeg
Change-Id: Ia8f3b2987571ddb8cf84b1201019ded83547e8f0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822430
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
A few new grouped imports have made it in since the tree-wide
reformatting.
BUG=None
TEST=tools/presubmit
Change-Id: I93af3c741f57c1da73d4c9e8a28be424c1ea45fe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3818244
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
We used to unref the owned AVBufferRef manually but this is actually
handled by ffmpeg if you call the right destructor for AVPacket.
Do that, remove our internal ownership handling for AvPacket and add a
unit test to confirm we don't leak memory.
BUG=None
TEST=cargo test -p ffmpeg &&
cargo test --features "video-decoder,ffmpeg" -p devices video
Change-Id: I2fbe1c12568ceca0c51013c789c30d6b78059e00
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3813254
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
For the encoder device, we will need to be able to iterate over the
supported pixel formats in order to expose the ones that are supported.
Add a type to wrap the native AVPixelFormat as well as an iterator to
AvCodec that will let us list all the available pixel formats.
BUG=b:239897269
TEST=cargo build --features "video-decoder,ffmpeg"
Change-Id: Ia835dc428b221c70178f2cd6634566001f3a9256
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782040
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
It's slightly less verbose and more idiomatic to do it this way.
BUG=None
TEST=cargo build
Change-Id: I1f67f88543b5e65cb187406179e463b9182fade5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3809196
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Tested-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Since we are going to support encoding, add a method to detect whether a
given codec is an encoder.
BUG=b:239897269
TEST=cargo build --features "video-decoder,ffmpeg"
Change-Id: I547fa6acafc4580f3f2f05c1a82955212d4d6e84
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782041
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Our ffmpeg crate should avoid returning native C avcodec types if
possible, as this means client code could have to resort to unsafe code.
Fix this for AVProfile by introducing a safe wrapper type that provides
us all the useful methods we may need.
BUG=b:169295147
TEST=cargo build --features "video-decoder,ffmpeg"
Change-Id: I2436857d3878b5b6cf4eab35f5b3b0c57c8db60e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782039
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
- Remove trailing ::{self} on all use statements
- Remove any resulting single-level use statements (e.g. use libc;)
- Reformat with `tools/fmt --nightly`
BUG=b:239937122
TEST=tools/dev_container tools/presubmit --all
Change-Id: I8afd1b0458ca6d08d9b41a24583f7d4148597ccb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3798973
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Add a wrapper for libavcodec's AVBufferRef and allow AvPacket to be
built from one ; this makes the AvPacket the owner of the data and means
it doesn't need to internally copy it.
The input data will be dropped once avcodec signals that it doesn't need
it anymore.
BUG=b:169295147
TEST=v4l2r's simple_decoder can decode a H.264 stream.
Change-Id: I9fa54124daed031fd1f397eaa8d57dc73f83c9b8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782037
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
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>
We want the ffmpeg crate to be independent of crosvm - remove a
dependency to base by adding a dedicated trait for types that can be
used as sources to a ffmpeg buffer.
BUG=b:169295147
TEST=v4l2r's simple_decoder can decode a H.264 stream.
Change-Id: I2ae6c2678a6a672746e6fc11a70dee692986db69
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782032
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
We only need to enforce a lifetime to the data source of the packet ; we
are not interested in its type. Replace it by () and remove that generic
parameter.
BUG=b:169295147
TEST=cargo build --features "video-decoder,ffmpeg"
Change-Id: Ibd9e976cab9dcc9cf0a44487580eb067211cc9b8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782031
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Being able to build an AvCodec means that the returned name will be
valid - unless there is a bug in libavcodec itself. Simplify the method
returning the codec's name to not return an Option, but instead a string
representing an invalid codec in the unlikely case we actually get one.
BUG=None
TEST=cargo build --features "video-decoder,ffmpeg"
Change-Id: Ic2c1b5db5391c421ae6f78faabcfe3197090ce17
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3782030
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
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>
As VAAPI is a stateless interface, add a VP8 parser in order to parse
VP8 frames. The frames will be used to feed the VP8 VAAPI backend.
BUG=b:214478588
TEST=cargo test --features "video-decoder,vaapi" -p vp8
Change-Id: Ie7315a5b76cb518b09078fe72d96384965712c28
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3514627
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@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>
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>
This provides at least a minimal one-line description to show what each
crate is about.
BUG=None
TEST=tools/cargo-doc
Change-Id: I26732e8c29062e622d5be09bdc120a49d564b9fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3630422
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a reland of commit 2b85d4d1e5
Diff from the original CL:
* Changed the return value of `main()` in power_monitor/build.rs
* Ran cargo-check with all features enabled
Original change's description:
> github: Minimize dependencies for document generation
>
> Instead of install full dependencies with `install-deps` in GitHub
> action, minimize dependencies because we use GitHub only for document
> generation.
>
> - Passed `CARGO_DOC` environment when running cargo-doc command so we
> can skip unnecessary build flow when we just want to generate API docs.
> - Added a new script `install-docs-deps` to install only doc-related
> dependencies.
>
> BUG=none
> TEST=test on GitHub Action at my personal repository
>
> Change-Id: Ibe988ab43215e285d946812bdd6c1536ae87b50e
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578144
> Tested-by: kokoro <noreply+kokoro@google.com>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Reviewed-by: Anton Romanov <romanton@google.com>
> Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Bug=none
TEST=cargo check --all-features
Change-Id: I77ee6543910e3fe7f69be48f8f965eda3433d4e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3584063
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This reverts commit 2b85d4d1e5.
Reason for revert: breaks powerd compile
Original change's description:
> github: Minimize dependencies for document generation
>
> Instead of install full dependencies with `install-deps` in GitHub
> action, minimize dependencies because we use GitHub only for document
> generation.
>
> - Passed `CARGO_DOC` environment when running cargo-doc command so we
> can skip unnecessary build flow when we just want to generate API docs.
> - Added a new script `install-docs-deps` to install only doc-related
> dependencies.
>
> BUG=none
> TEST=test on GitHub Action at my personal repository
>
> Change-Id: Ibe988ab43215e285d946812bdd6c1536ae87b50e
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578144
> Tested-by: kokoro <noreply+kokoro@google.com>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Reviewed-by: Anton Romanov <romanton@google.com>
> Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Bug: none
Change-Id: Ie16b65235490071ac4e69bf3f09af3ba0c766eab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3581836
Auto-Submit: Junichi Uekawa <uekawa@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Instead of install full dependencies with `install-deps` in GitHub
action, minimize dependencies because we use GitHub only for document
generation.
- Passed `CARGO_DOC` environment when running cargo-doc command so we
can skip unnecessary build flow when we just want to generate API docs.
- Added a new script `install-docs-deps` to install only doc-related
dependencies.
BUG=none
TEST=test on GitHub Action at my personal repository
Change-Id: Ibe988ab43215e285d946812bdd6c1536ae87b50e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3578144
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
As we are going to introduce more media-related crates, reserve the
"media" folder as a placeholder for them, starting with the existing
libvda.
BUG=b:169295147
BUG=b:214478588
TEST=cargo build --features "video-decoder,video-encoder,libvda"
Change-Id: I1b2ec65cbba8b735db3d19845c504546fa1c64ca
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3565623
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
