Google Git
Sign in
android / platform / system / cros-codecs / 903a163
commit903a1636b8c4daaca0baaac9ce6f857fd181351e[log] [tgz]
authorAndres Calderon Jaramillo <andrescj@google.com>Mon Jun 02 20:20:24 2025 +0000
committerAndres Calderon Jaramillo <andrescj@google.com>Thu Jun 26 21:59:40 2025 +0000
treeff1875b2a540f2d42211d1a0b5b868071df69d1b
parent8d56b885ce11b4ee1df683adb9f19c7af4182c0c [diff]
C2EncodeJob: Surface whether an encoded frame is a "sync frame"

A "sync frame" is one that resets the decoding process. It's
intentionally not named "key frame" in this CL because that's an
overloaded term. For example, in the case of H.264, a key frame may
refer to and IDR frame or to a non-IDR I frame. A sync frame would more
specifically refer to an IDR frame in that case. The "sync" terminology
is borrowed from the codec 2.0 API [1][2].

This information is plumbed all the way to the C2EncodeJob so that it
can be used to provide it to the codec 2.0 client through
C2StreamPictureTypeMaskInfo::output.

[1] https://android.googlesource.com/platform/frameworks/av/+/ff39b9f6b399d35befbb7e65190a7db90893422c/media/codec2/core/include/C2Config.h#2157
[2] https://android.googlesource.com/platform/frameworks/av/+/ff39b9f6b399d35befbb7e65190a7db90893422c/media/codec2/core/include/C2Config.h#2058

Bug: 389993558
Test: VtsHalMediaC2V1_0TargetVideoEncTest on brya
Test: atest ccenc_test on brya
Change-Id: I337f68fbff03de1c9eccc4767d2b21d177460d20
9 files changed
tree: ff1875b2a540f2d42211d1a0b5b868071df69d1b
  1. .cargo/
  2. ci/
  3. examples/
  4. fuzz/
  5. src/
  6. tests/
  7. .clippy.toml
  8. .gitignore
  9. Android.bp
  10. Cargo.toml
  11. cargo_embargo.json
  12. CONTRIBUTING.md
  13. DIR_METADATA
  14. LICENSE
  15. METADATA
  16. MODULE_LICENSE_BSD
  17. OWNERS
  18. README.md
  19. rustfmt.toml
  20. simple_test.py
README.md

Cros-codecs

A lightweight, simple, low-dependency, and hopefully safe crate for hardware-accelerated video decoding and encoding on Linux.

It is developed for use in ChromeOS (particularly crosvm), but has no dependency to ChromeOS and should be usable anywhere.

Current features

  • Simple decoder API,
  • VAAPI decoder support (using cros-libva) for H.264, H.265, VP8, VP9 and AV1,
  • VAAPI encoder support for H.264, VP9 and AV1,
  • Stateful V4L2 encoder support.

Planned features

  • Stateful V4L2 decoder support,
  • Stateless V4L2 decoder support,
  • Support for more encoder codecs,
  • C API to be used in non-Rust projects.

Non-goals

  • Support for systems other than Linux.

Example programs

The ccdec example program can decode an encoded stream and write the decoded frames to a file. As such it can be used for testing purposes.

$ cargo build --examples
$ ./target/debug/examples/ccdec --help
Usage: ccdec <input> [--output <output>] --input-format <input-format> [--output-format <output-format>] [--compute-md5 <compute-md5>]

Simple player using cros-codecs

Positional Arguments:
  input             input file

Options:
  --output          output file to write the decoded frames to
  --input-format    input format to decode from.
  --output-format   pixel format to decode into. Default: i420
  --compute-md5     whether to display the MD5 of the decoded stream, and at
                    which granularity (stream or frame)
  --help            display usage information

Testing

Fluster can be used for testing, using the ccdec example program described above. This branch contains support for cros-codecs testing. Just make sure the ccdec binary is in your PATH, and run Fluster using one of the ccdec decoders, e.g.

python fluster.py run -d ccdec-H.264 -ts JVT-AVC_V1

Credits

The majority of the code in the initial commit has been written by Daniel Almeida as a VAAPI backend for crosvm, before being split into this crate.