We don't really need to use the BackendHandle associated type here as we
know that vaapi will always use the GenericBackendHandle - so let's just
use this and simplify the type map a bit.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: Idb77ecda7bdd566ffb7bc46a35ebaadcb11cdeef
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4060493
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The dummy backends behave the same regardless of the codec, so factorize
their declaration as well as their implementation of VideoDecoderBackend
to avoid duplicate code.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: Ibaa694b885c1ccf969aed3a0cb167a254e0eaab5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4060492
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
...round 2 because building locally missed some :)
Most are safe, similar to crrev.com/c/4014832
Two require an exception, similar to crrev.com/c/4018392
BUG=b:157245930, crbug:908640
TEST=CQ with needless_return suppression disabled
Change-Id: I0f54ee1e4688afe9c9f596bd32a98070aac20612
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4019273
Commit-Queue: Clarissa Garvey <clarissagarvey@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
The DecodedHandle implementations are almost identical across codecs,
save for that display_resolution() method. Abstract it into the
codec-specific data of the picture using a new FrameInfo trait, so that
each backend can share a single implementation of DecodedHandle. This
also allows us to factorize the dummy Handle structs into a single
generic struct.
BUG=b:214478588
TEST=cargo build --features `video-decoder,video-encoder,ffmpeg,vaapi`
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: I959ca39e79f8f7c81d1c75ab42dc4f0b4c67262b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4012399
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
MappableHandle was implemented on the backend handle, but doing so is
sub-optimal in the case of VAAPI which needs to re-create the VA Image
with each call to a method of MappableHandle, which is a costly
operation.
Fix this by implementing MappableHandle on the Image directly. That way
callers can request the mappable handler once to create the image, and
call all the methods on the same instance.
This also allows us to make MappableHandle::image_size return the size
instead of a Result.
BUG=b:214478588
TEST=cargo build --features `video-decoder,video-encoder,ffmpeg,vaapi`
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: Iaa048c1f488021d49376f612ebde560e84a11dc4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4006228
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The dummy BackendHandles used for tests are the same across all codecs,
so share them.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: Ic9bd84c24363f9fbb255480ab2817c7c16dcebdc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4006227
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
GenericBackendHandle is created, accessed and modified by the various
decoders directly, but the access patterns could easily be fulfilled by
a few methods.
This also allows us to make GenericBackendHandleInner private, as its
name suggests it should be, and to simplify it a bit.
BUG=b:214478588
TEST=cargo build --features `video-decoder,video-encoder,ffmpeg,vaapi`
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: I9ef2a58361db37b69315c91e9ad337fd0c99b8cb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4005493
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>
The concept of mapped resolution is only used in the context of copying
the frame to a CPU-mapped buffer in order to compute the size of said
buffer according to the underlying format.
This requires the caller to check the buffer format and perform the
computation themselves. It would be more efficient to just have a
function performing that computation in a single place and returning the
final buffer size.
Thus, replace MappedHandle's mapped_resolution() method with
image_size(), which returns the size of the buffer that should be passed
to read().
BUG=b:214478588
TEST=cargo build --features `video-decoder,video-encoder,ffmpeg,vaapi`
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: Icff17aa5e2e08676edb450a53316e44897604958
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4005492
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
We never use this method, so remove it. Besides how to copy an image is
dependent of the format and handled by read(), so this should be the
prefered way of accessing frames.
This also allows us to remove the dummy mapped handles.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: I4909a33f2ba3dbcc61e27493ed0ad3b8a75cd882
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4005491
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Error descriptions should have no leading capital and do not end with a
dot.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
Change-Id: I807e4874c862bc8e32dc4a394b1e5e46df60c8d0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4005489
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>
These types are only used in two places, and their actual definition is
more explicit about their purpose.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=`cros-codecs --include-ignored` passes on hatch.
Change-Id: I90eec9751bc4aaccab33fe70d96a94a5875f6f6c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3995769
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The DynDecodedHandle traits defined for each codec are basically
identical, and can be simplified into a single one now that we also have
a common DecodedHandle struct.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=`cros-codecs --include-ignored` passes on hatch.
Change-Id: I666d941dfea5b5e40ca46dab661e87aec60d65e4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3998376
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>
The DecodedHandle structs defined for each codec are basically identical
and can be simplified into a single one by adding an associated type.
Doing so required the H.264 types to be constrained with non-trivial
where clauses due to the fact the H264 PictureData is itself generic,
but there is a plan to simplify this too.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=`cros-codecs --include-ignored` passes on hatch.
Change-Id: Idcb0717740e6e700ae83d758f99ba0035981dcca
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3998375
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>
SurfaceContainer was implemented for each codec type, but it can be
simplified into a single generic implementation if move the RefCell out
of InnerHandle.
Since SurfaceContainer's purpose is just to convert one object into a
Surface, rename it into the more idiomatic IntoSurface that just
requires TryInto<Option<Surface>>.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs
TEST=`cros-codecs --include-ignored` passes on hatch.
Change-Id: I00a56132ceaeab5d305e144976a9ea597355bbf8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3998374
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The Picture structs defined for each codec are now basically identical,
and can be simplified into a single one by adding one generic argument.
BUG=b:214478588
TEST=cargo test --features vaapi -p cros-codecs:wq
TEST=`cros-codecs --include-ignored` passes on hatch.
Change-Id: I48a79c615f7c53de5d39bcf37da0b64d05c65a09
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3998373
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.corp-partner.google.com>
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>
