The Picture structs defined for each codec are essentially identical,
with only the H.264 one having its codec-specific data inlined into the
struct instead of being part of another one. Move the H.264 data in
order to make the 3 structures similar. This will allow us to merge them
into one common struct in the next CL.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=`cros-codecs --include-ignored` passes on hatch.
Change-Id: I3282fde1dbbc2ad303f2691e00c46aa8b6c0de41
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3998372
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
backend_handle_unchecked* were only used in tests, and the DynPicture
interface provides equivalent functions anyway, so use these ones and
drop the former.
Ideally these methods that can potentially panic should be replaced by
something else, but this will have to wait further cleanups.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=`cros-codecs --include-ignored` passes on hatch.
Change-Id: I339f6893599c5ffc24e738f5ad11f35cbfcaab25
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3998371
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
These types do not need to be exported.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: I5310bb4ce34956d6f6edbbe8a8852b4c18b8130c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4005487
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The `blocking` boolean was converted into a `BlockingMode` anyway, and
using `BlockingMode` directly is also more explicit about what the
parameters is about.
BUG=b:214478588
TEST=cargo build --features `video-decoder,video-encoder,ffmpeg,vaapi`
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: If72067d8218d53ff8d092cef384909d282862e0a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3995885
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
When decoding H.264, ffmpeg tries to set the frame format before
receiving the first DRC event, which is currently rejected even though
this is valid from the point of view of the client. We need to silently
accept the temporary format and all queued output buffers until the
initial DRC event is fired, even though we won't emit any frame.
BUG=None
TEST=`ffmpeg -codec:v h264_v4l2m2m -i Big_Buck_Bunny_720_10s_1MB.mp4 BBB-%d.png`
completes successfully in the guest and produces valid frames.
Change-Id: I9a190ab2748bd59ff57d54be681f2a1553d1c6a3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3841484
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Use backticks around comments that use array syntax with [] to avoid
interpreting those as Markdown links.
Additionally, convert a few file headers to //! so they show up in the
generated docs.
BUG=None
TEST=tools/cargo-doc
Change-Id: I34799ff8e0e48b799f31255ae1ed84a0c18e8601
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3993931
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Fix, extend, and reformat the documentation of libva to be closer to the
style of the standard library.
BUG=b:214478588
TEST=`cargo doc --document-private-items` in `media/libva` does not
generate any error.
Change-Id: Iee18f3471ddf8f2e65b5111f40fad3a020eafe41
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3932442
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Using the same CARGO_TARGET_DIR for all builds prevents us from
building for platforms in parallel, since cargo will lock the
directory to only run one build at a time.
Use the same directory for clippy as well, and ensure that
clippy won't invalidate caches created by run_tests.
This reduces the build time for tools/presubmit by about 50%.
Another advantage is that rust_analyzer and run_tests will no longer
block each other or invalidate the cache when run with different
feature flags.
Note: This introduces two subtle changes to the build that required nit
fixes:
- build.rs files are now run through clippy as well
- common/* crates are now also built for the target architecture instead
the host.
BUG=None
TEST=tools/presubmit
Change-Id: I8da9ef53418c0b15827d512a04e77828621aef88
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3984416
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
libva Displays and Contexts are only useful if they are
reference-counted, and all callers of `create_context` immediately wraps
the result into a Rc. Make `create_context` return a `Rc` directly to
make sure we cannot end up with stray objects.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=cargo test --features "video-decoder,vaapi" -p devices
Change-Id: I04c90059df71ea8a09a1fa937d731e1f4a5c27fc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3932441
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The attributes array can be passed as empty to indicate we don't have
any preference for the configuration (which is what passing None
results into anyway), so remove the Option in order to simplify the
arguments.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=cargo test --features "video-decoder,vaapi" -p devices
Change-Id: I677b61f595f82cfbb519da3d78f433478eede8b9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3932439
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Allow for polling the decoders. This will return any pending decode
requests that happen to be ready. If block is set to true, it will
block until they are all ready.
This is different from flush, in that flush will empty the decoder's
internal state, altering the DPB, whereas poll will not.
BUG=b:214478588
TEST=cd media/cros-codecs && cargo test --features vaapi
Change-Id: I56b1b9d7b704c17d75bbe93d4fd4eb0a9a468af7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3918838
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Make it possible to retrieve the display order by adding a
display_order() member to the DynDecodedHandle trait.
This is in preparation for further CrosVM changes where the handles
will be sorted by the display order.
The decoders will issue the display order from a monotonically
increasing counter after applying any codec-specific reordering
algorithm. We will build upon the monotonically increasing counter to
identify gaps in CrosVM and wait until said gaps are filled by newer
frames.
BUG=b:214478588
TEST="cargo build --features=video-decoder,vaapi" successfully builds
the libva crate
Change-Id: I4e4b1becb9aea124b6b942069dcc676385bd6986
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3907528
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The raw capabilities should not depend on the value for rt_format.
Both in the Intel and Mesa implementations it can be seen that setting
VAConfigAttribRTFormat as a parameter to vaCreateConfig only serves as a
way to validate that the to-be-generated config supports it.
This means that the Intel implementation will only use it in
CheckAttribList, while Mesa will AND it with a precomputed bitmask of
supported values in vaCreateConfig.
Thus, creating one RawCaps instance per value of RT_FORMAT only serves
to create needless duplication.
Not only that, but it frequently makes the call to QUERY_CAPABILITIES
fail, as the resulting structures become too large to fit into the 1024
byte buffer.
Remove all traces of VA_RT_FORMAT_* from this code path. While we are at
it, note that the libva crate API for vaQuerySurfaceAttribute changed to
reflect that this call can return more than one attribute at once.
This is particularly important for VASurfaceAttribPixelFormat, as one
value per supported fourcc is returned. We now properly return one
instance of RawCaps per VA_FOURCC supported.
Also reflect that Surface attributes can be defined more than once
This is particularly the case with VASurfaceAttribPixelFormat, where the
driver will define one attrib per pixel format supported.
This can be seen in the Intel driver, for example, in
MediaLibvaCaps::QuerySurfaceAttributes.
The previous code assumed that a given attribute could only be defined
once, and thus used find(). It was refactored to use filter() instead.
The name of the method was changed to reflect that it can now return
more than one attribute per call. The return type was changed to Vec for
the same reason.
BUG=b:214478588
TEST="cargo test --package devices --lib --features video-decoder --features vaapi -- virtio::video::decoder::backend::vaapi::tests::test_get_capabilities --include-ignored"
Change-Id: I914376beb026e30b2a52ca8f7d01c81e6a9a2775
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3946301
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Port the VAAPI backend to the new cros-codecs crate. This crate now
contains all codec related code and is independent from the rest of the
CrosVM code.
BUG=b:214478588
TEST="cargo test --package devices --lib --features video-decoder --features vaapi -- virtio::video::decoder::backend::vaapi::tests::test_get_capabilities --include-ignored"
Change-Id: Id207c53c0c4200e03ce8793d7c37cb5fbe808829
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3875044
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Introduce the cros-codecs crate. This crate contains all the
codec-related code and does not depend on CrosVM. The decoders are
decoupled from the backends, which allows for the implementation of new
backends without touching the decoder code.
This crate comes with dummy backends to test the decoder functionality
in isolation, but in order to decode frames, a real backend is needed.
Currently this backend is the VAAPI backend. Using it adds a dependency
on the libva crate.
This change adds support for VP8, H264 and VP9.
BUG=b:214478588
TEST="cd media/cros-codecs && cargo test --release --features vaapi -- --include-ignored"
TEST="emerge-hatch chromeos-base/crosvm" completes successfully.
Change-Id: I596d5db4dabcc96dcfdbce1f41c8092e01b64271
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3875043
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
libvda is only available on ChromeOS, and being unable to link to it
with regular builds reduces our build coverage.
Add a "libvda-stub" feature that, if enabled, results in dummy C stubs
being build for all the exported libvda functions. This allows builds
with the "libvda" feature to pass, although of course the resulting
video device would immediately crash and thus should not be used.
BUG=b:244619291
TEST=`cargo build --features="video-decoder,video-encoder,libvda-stub"`
completes.
TEST=`cargo build --features="video-decoder,video-encoder,libvda"`
reports link errors against libvda.
TEST=`cargo build --features all-x86_64` builds libvda and completes
without error.
Change-Id: I9bb60f6caf670081d67c91275727f3888272d64b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3947844
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
It's not ergonomic for the calling code to pass in an array of
references.
Just take ownership of that array, as it's not going to be used again
when the calling code succeeds in creating the wrapper.
BUG=b:214478588
TEST="cargo build --features=video-decoder,vaapi" successfully builds
the libva crate
Change-Id: I97d91f9f996c298450e65c21c126a9739ec4615f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3900314
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Implement access to vaQuerySurfaceStatus for Picture<PictureEnd>. This
means that a decoder can initiate a decode operation and query its
status at a convenient time instead of blocking on it for completion.
Also expose libva::VASurfaceStatus to calling code while at it, since it
is needed to interface with this API.
BUG=b:214478588
TEST="cargo build --features=video-decoder,vaapi" successfully builds
the libva crate
Change-Id: I8a20455ef9937a4a54943325d359fa361190d8a4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3875042
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Previously, only PictureSync would allow us to retrieve a borrow to the
underlying surface, but this is too restrictive. If we can take the
Surface back by calling take_surface() in PictureReclaimableSurface,
there is no reason not to be able to get a borrow to a Surface as well.
This makes the calling code more ergonomic.
BUG=b:214478588
TEST="cargo build --features=video-decoder,vaapi" successfully builds
the libva crate
Change-Id: I71f9f46e6bac6188c4c3862332c445c68028dbef
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3783006
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
In preparation for interlaced support, allow for picture creation using
another picture's Surface. This is so one can decode both fields to the
same underlying surface.
BUG=b:214478588
TEST="cargo build --features=video-decoder,vaapi" successfully builds
the libva crate
Change-Id: If3ffcc2592b7213644ed92f7202502fc92bac4b3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3783005
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
While the current design works well for progressive content, in
interlaced content a common strategy is to decode both fields to the
same Surface.
Thus, add support for sharing the underlying Surface. This means that we
can only retrieve the Surface if we are the last Picture with a
reference to it.
While we are at it: only retrieve Surfaces if we are the last users
In preparation for interlaced decoding support, only retrieve Surfaces
back into the surface pool if we are the last users. This means that the
surface will not be dropped until both of its fields have been dropped.
BUG=b:214478588
TEST="cargo build --features=video-decoder,vaapi" successfully
builds the libva crate
Change-Id: I80412a86f51ab639fab6af229572fb7bc800a928
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3946300
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This was disabled in https://crrev.com/c/3835500 due to the lack
of ffmgeg 5.0 in our dev containers.
The container has since been upgraded in https://crrev.com/c/3892621
BUG=b:244619658
TEST=presubmit
Change-Id: Ia2bd41fbd780bad7d7706e0ffe7554e202ec0eb1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3907377
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We currently use cargo features to modify the build process, which
makes them non-additive and prevents us from moving towards
using --all-features in the future.
To change build.rs behavior to integrate with downstream build
systems (e.g. use pkg_config only on chromeos) we will use the newly
added CROSVM_BUILD_VARIANT env variable. Currently only
used by ChromeOS, but not limited to it.
For now, CROSVM_BUILD_VARIANT=chromeos will prevent the
embedding of seccomp policies.
BUG=b:244618505
TEST=Test in combination with https://crrev.com/c/3923813
Change-Id: I2bfe999b5252740d57c73c4a85d73bd343c8259e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3926325
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Fix a few recently introduced formatting mismatches.
Change-Id: I1617683532d3cc45f67ec15408fbd4ec4c9d6bb2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928132
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
It's not ergonomic for the calling code to pass in an array of
references.
Just take ownership of that array, as it's not going to be used again
when the calling code succeeds in creating the wrapper.
BUG=b:214478588
TEST="cargo test"
Change-Id: Ifbb78968ebb29b41fe2ccaa653f30a81fcb23427
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3783002
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The FFmpeg backend is a software emulated video encoder device backend.
It can be used for testing, for developing guest kernel changes and
more.
The backend roughly mirrors how the FFmpeg decoder backend is
implemented right now, with the notable difference that it does not use
swscale as the de-facto input format is NV12 or YUV420 and the guest can
likely provide buffers in that format.
BUG=b:239897269
TEST=See testing instructions in the updated book document.
Change-Id: Iae9928bdad86729f890e738acfa58e21573a115b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920263
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
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>
The buffer will be allocated by FFmpeg on-demand. This will be used in
encoding scenarios.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: Ie1e83a6a1129ea666bb3580a669beb7c6cbc8c10
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920260
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
For reading out the packet size and flags. We already have AsRef
implementations for AVCodecContext and AVFrame.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: Ie330c1863f989211dcad758cd8df96058dfbc2ea
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920259
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Add setters for time_base, bit_rate and rc_max_rate for use in encoder.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: If006abf5b32cdb740c33075f8d5f480c65c20806
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920258
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
These covers the "writable" notion exposed by FFmpeg. If a non-writable
frame is passed to a codec, the codec will clone the frame before
writing to it. Some interfaces (notably swscale) doesn't respect this
convention yet; for those, we'll add our own checks for writeability so
ideally this copy-on-write convention is held everywhere within our
bindings.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: I566f44a44491a7507bd6446e1bf8e1f8550f16d6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920257
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Fixes the following failure:
error[E0659]: `ffmpeg` is ambiguous
--> crosvm/media/ffmpeg/src/lib.rs:11:5
|
11 | use ffmpeg as ffi;
| ^^^^^^ ambiguous name
|
= note: ambiguous because of multiple potential import sources
= note: `ffmpeg` could refer to a crate passed with `--extern`
= help: use `::ffmpeg` to refer to this crate unambiguously
note: `ffmpeg` could also refer to the module defined here
--> crosvm/media/ffmpeg/src/lib.rs:10:1
|
10 | mod ffmpeg;
| ^^^^^^^^^^^
= help: use `crate::ffmpeg` to refer to this module unambiguously
BUG=None
TEST=cargo test -p ffmpeg
Change-Id: I6665bec21336c78cd773593cd0310e996a345e1d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924262
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Generalize and move it out of the decoder for potential future use in
the encoder module.
A ffmpeg.rs module is introduced to accommodate any video-related code
that requires the ffmpeg feature flag, similar to what we have for
libvda.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: I341d6d238b5593d16cbdc8dd8c96eb2fa4e143fe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911109
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Since re-enumerating all the formats supported by FFmpeg in our bindings
would be a rather large effort, it looks like a good compromise here is
to allow the user to create an AvPixelFormat from the raw enum values
exposed by bindgen.
Add a helper that checks that the value is in range of valid formats and
convert it into our enum wrapper.
BUG=b:239897269
TEST=cargo test --features ffmpeg -p ffmpeg
Change-Id: I3c1433e9d76d645b7615bde81433e1df2cfa3910
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911108
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The decoder and encoder uses different calls for flushing. Add a new
flush_encoder helper for that, and rename the existing one to
flush_decoder.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: Id237424209dc8d64d43424570003d735ee164d36
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868598
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
try_send_frame and try_receive_packet together forms the basis of the
(AVFrame-based) encoding API. This change adds helper methods for them,
with the return value being handled similarly to their decoding
counterpart.
TryReceiveFrameResult has been renamed to TryReceiveResult as the
encoding interface shares the handling of these return codes, and we'll
be sharing this logic between try_receive_packet and try_receive_frame.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: I32c11053daed86c32067ac2b2a8f7218f6dbcd4f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868597
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This API allows the user to allocate and set the buffer/data of an AvFrame.
This will be needed when using AvFrame as encoder input.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: If2c46a1b19f5fb98a296ca42b1917f8260174c83
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868596
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
These are wrappers of av_image_get_linesize and
av_image_fill_plane_sizes, and will be used for bounds checking and
mmap bounds calculation purposes.
It's kind of weird that one is singular and the other is plural, but
we should probably blame FFmpeg for not having a singular version of
av_image_fill_plane_sizes.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: I34104f5062089377aeab0d4a4ab0534837e56d6f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868595
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Similar to the decoder builder, add an encoder context builder.
The encoder requires a few more parameters to be set before calling
avcodec2_open, and the respective setters are provided here. As for
checking for the required fields, it looks like FFmpeg will check it and
error on avcodec2_open if any are missing anyway, so we'll avoid
duplicating that on the binding side.
BUG=b:239897269
TEST=cargo build --features ffmpeg -p ffmpeg
Change-Id: I448b56ba9bae9b38ce5c2fb540e9577a2dfcd83c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3856043
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This requires a few tweaks to non-generated code:
- VIRTIO_ID_VIDEO_ENC/DEC -> ENCODER/DECODER
- io_uring unnamed union layout change
Change-Id: I58e118efa5c6bf28ff56d211fec5603651cb60bc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3893753
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Check if the VERSIONS file actually changed before printing the related
message.
Also print the path to the VERSIONS file to give some more context.
BUG=None
TEST=media/ffmpeg/bindgen.sh
Change-Id: I6e7cd2ace37ca99ed744a307675272a2e3c205f6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3893752
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Switch to the common bindgen wrapper so that the ffmpeg bindings get the
same defaults as other bindgen-generated bindings.
BUG=None
TEST=media/ffmpeg/bindgen.sh
TEST=cargo build --features=ffmpeg,video-decoder
Change-Id: I09901c122401fe1b65eed154a6be8348decfcc33
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3893751
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
While we are tweaking all of the copyright headers, let's take the
opportunity to ensure there is always a blank line after the copyright
header for consistency. (Almost all files already follow this style.)
This includes a slightly ugly regex to allow the end of a C-style
comment block after the end of the copyright:
/*
* Example comment block
*/ <-- this line
Change-Id: Idfd0855861e5ecb3d33afae942fdba908af0dcff
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892521
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This search/replace updates all copyright notices to drop the
"All rights reserved", Use "ChromiumOS" instead of "Chromium OS"
and drops the trailing dots.
This fulfills the request from legal and unifies our notices.
./tools/health-check has been updated to only accept this style.
BUG=b:246579983
TEST=./tools/health-check
Change-Id: I87a80701dc651f1baf4820e5cc42469d7c5f5bf7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3894243
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
generated files and a list of excluded files are skipped.
Others are fixed to include the missing header.
BUG=b:246579983
TEST=./tools/health-check --all copyright_header
Change-Id: I13e9bf79df18789f1ed4b83fc47c0c2e080d70a8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3894240
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
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>
