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>
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>
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>
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>
