WAIT — Mixed signals — read the receipts

• Last commit 3mo ago
• 23+ active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 74% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

JavaCV is a Java wrapper layer around OpenCV, FFmpeg, and other native computer vision libraries, generated via JavaCPP Presets. It provides convenient Java APIs for image processing, video capture/encoding, face detection, feature matching, and hardware-accelerated rendering (CanvasFrame, GLCanvasFrame), eliminating the need to call JNI directly. Maven multi-module project: platform/pom.xml is the main build (depends on javacv artifact from parent javacpp-presets). Core Java utilities live in platform/src/main/java; tests in platform/src/test/java/org/bytedeco/javacv/. Samples/ directory contains 40+ standalone demo applications (FaceRecognizerInVideo.java, OpticalFlowTracker.java, etc.). Module-info.java (Java 9+) enables JPMS support.

Java developers and Android developers building computer vision applications who need OpenCV and FFmpeg functionality without managing native bindings themselves. Researchers using face recognition, optical flow, blob detection, or video processing in Java ecosystems.

Production-ready and actively maintained. The project is part of the bytedeco ecosystem (1.1M+ lines of Java), has comprehensive test coverage (FrameConverterTest, FrameGrabberTest, etc.), builds via Travis CI with Maven, and includes 40+ runnable sample applications. Recent snapshot builds at version 1.5.14-SNAPSHOT indicate active development.

Moderate dependency risk: relies on 10+ native library presets (opencv-platform 4.13.0, ffmpeg-platform 8.0.1, flycapture, libdc1394, libfreenect, librealsense, etc.) which must be available on the target platform. Breaking changes in upstream OpenCV or FFmpeg versions could cascade. Maintenance depends on the bytedeco core team; no evidence of multiple active maintainers from the file list.

Active maintenance on snapshot releases (1.5.14-SNAPSHOT). Recent dependency updates: opencv-platform bumped to 4.13.0, ffmpeg-platform to 8.0.1, openblas to 0.3.31. CI/CD via .github/workflows/javacv.yml. No specific PR or issue data visible, but the snapshot versioning and updated native library pins indicate ongoing refinement.

git clone https://github.com/bytedeco/javacv.git
cd javacv
mvn clean install
# To run tests: mvn test
# To run a sample: java -cp target/classes:~/.m2/repository/.../* samples.FaceRecognizer

Daily commands: No traditional 'dev server'. Build with mvn clean install (compiles Java bindings). Run tests: mvn test (executes FrameGrabberTest, FrameConverterTest, etc.). Run samples directly: java -cp target/javacv-platform-1.5.14-SNAPSHOT.jar:$HOME/.m2/repository/org/bytedeco/opencv/opencv-platform/4.13.0-1.5.14-SNAPSHOT/* samples.BlobDemo input.jpg. Most samples are single-file, no server startup needed.

• src/main/java/org/bytedeco/javacv/Frame.java — Core data structure representing captured/processed video/image frames; all grabbers, filters, and recorders operate on Frame objects.
• src/main/java/org/bytedeco/javacv/FrameGrabber.java — Abstract base for all frame acquisition (cameras, files, streams); essential to understand the input pipeline for any media source.
• src/main/java/org/bytedeco/javacv/FFmpegFrameGrabber.java — Primary FFmpeg-based frame grabber handling video files and network streams; most common input path in JavaCV applications.
• src/main/java/org/bytedeco/javacv/FrameConverter.java — Abstraction for converting Frame objects to/from OpenCV Mat, Android Bitmap, and other formats; critical for interoperability.
• src/main/java/org/bytedeco/javacv/FFmpegFrameRecorder.java — Primary output path for encoded video/audio; handles FFmpeg encoding configuration and stream multiplexing.
• src/main/java/org/bytedeco/javacv/FrameFilter.java — Abstract interface for FFmpeg filtergraph-based video/audio processing; entry point for effects, scaling, and format conversion.
• pom.xml — Root Maven POM defining JavaCPP preset dependencies and platform-specific native library bindings; controls native code exposure.

Add support for a new camera type

1. Create new class extending FrameGrabber.java with your camera SDK initialization in start() (src/main/java/org/bytedeco/javacv/YourCameraFrameGrabber.java)
2. Implement grab() to fetch frames from camera and wrap in Frame.java objects (src/main/java/org/bytedeco/javacv/YourCameraFrameGrabber.java)
3. Add static createDefault() method to FrameGrabber.java to instantiate your grabber if native library detected (src/main/java/org/bytedeco/javacv/FrameGrabber.java)
4. Add unit test mirroring FrameGrabberTest.java pattern to verify frame delivery (platform/src/test/java/org/bytedeco/javacv/YourCameraFrameGrabberTest.java)

Add a new FFmpeg filter or effect

1. Instantiate FFmpegFrameFilter.java with your filtergraph string (e.g., 'scale=640:480,hflip') (samples/YourEffectDemo.java)
2. Call push(frame) in loop to feed frames; pull(frame) to get filtered output (samples/YourEffectDemo.java)
3. Optionally create reusable wrapper class extending FrameFilter.java if effect needs state (src/main/java/org/bytedeco/javacv/YourCustomFilter.java)

Add support for a new output format or codec

1. Construct FFmpegFrameRecorder.java with your file path, dimensions, and set audioChannels, videoCodec, audioCodec (samples/YourEncodingDemo.java)
2. Call start() to initialize encoder, record(frame) for each frame, stop() to finalize file (samples/YourEncodingDemo.java)
3. Test with FFmpegFrameGrabber.java to verify round-trip encoding/decoding integrity (platform/src/test/java/org/bytedeco/javacv/YourCodecTest.java)

Add custom frame format conversion

1. Create class implementing FrameConverter.java with convert(Frame) and convertBack() methods (src/main/java/org/bytedeco/javacv/YourFormatConverter.java)
2. Register converter in your application or add factory method to FrameConverter.java if widely needed (src/main/java/org/bytedeco/javacv/FrameConverter.java)
3. Write test in FrameConverterTest.java pattern to validate round-trip fidelity (platform/src/test/java/org/bytedeco/javacv/YourFormatConverterTest.java)

• JavaCPP + JNI — Zero-copy access to OpenCV Mat, FFmpeg AVFrame, and hardware codec APIs; critical for real-time video processing at high frame rates.
• FFmpeg (libavformat, libavcodec, libswscale, libavfilter) — De facto standard for codec support (H.264, VP9, HEVC, audio codecs) and container multiplexing; enables format-agnostic grabber/recorder.
• OpenCV (libopencv_core, libopencv_imgproc, libopencv — undefined

1. Native library availability: FFmpeg, OpenCV, and optional hardware libs (libdc1394, FlyCapture) must be pre-installed or included via javacpp-presets platform jars; missing native libs at runtime cause UnsatisfiedLinkError. 2. FrameGrabber and FrameRecorder are platform-specific; some classes (FFmpegFrameGrabber, OpenCVFrameGrabber) have different availability on Linux/Windows/macOS. 3. Snapshot versions (1.5.14-SNAPSHOT) require access to Sonatype SNAPSHOTS repo or local build; released versions are stable on Maven Central. 4. JavaFxPlayVideoAndAudio.java requires JavaFX on the module path (--module-path), not in classpath. 5. Hardware-accelerated rendering (GLCanvasFrame) requires OpenGL support and native OpenGL library on system.

• JNI (Java Native Interface) Bridge Generation — JavaCV uses JavaCPP to auto-generate JNI bindings instead of hand-writing them; understanding this code generation pattern is crucial for debugging native crashes and extending library support
• Frame Abstraction (Video/Audio Unified Representation) — The Frame class unifies OpenCV Mats, FFmpeg AVFrames, and audio samples into a single Java interface; mastering Frame semantics is essential for writing cross-library video processing pipelines
• Platform-Specific Native Library Packaging (javacpp-presets) — JavaCV bundles pre-compiled native libraries for Windows/Linux/macOS as platform-specific Maven artifacts (e.g. opencv-platform-linux-x86_64); understanding classifier-based dependency resolution is critical for cross-platform deployment
• Direct Memory Buffers (ByteBuffer ↔ Native Pointer Mapping) — JavaCV uses ByteBuffer.allocateDirect() and native pointers to zero-copy data exchange with C++ libraries; inefficient buffer handling causes memory leaks and GC pressure in real-time video processing
• Lazy Hardware Initialization (OpenCL/OpenGL Optional Backends) — Classes like JavaCVCL and GLCanvasFrame optionally offload computation to GPU; understanding when and how to enable these backends is key for performance-critical applications (face detection, optical flow)
• Codec Wrapper Abstraction (FFmpeg → Uniform FrameRecorder API) — FrameRecorder abstracts away H.264/VP9/ProRes codec selection; knowing which FFmpeg parameters map to codec options prevents silent encoding failures and bitrate mismatches
• Module System (JPMS) Compatibility — JavaCV includes module-info.java for Java 9+ modular builds; understanding how native bindings interact with module exports/requires is essential for modern Java deployments and avoiding dependency hell

• bytedeco/javacpp-presets — The parent project that generates JavaCV's native bindings; contains the actual JNI glue code for OpenCV, FFmpeg, and other libraries
• bytedeco/javacpp — Core framework that generates the low-level JNI wrappers; JavaCV depends on its annotation processing and native bridging capabilities
• opencv/opencv — The upstream C++ computer vision library that JavaCV wraps; understanding OpenCV API design is essential for using JavaCV effectively
• FFmpeg/FFmpeg — The upstream multimedia framework that JavaCV wraps for video encoding, decoding, and streaming; key to FrameGrabber and FrameRecorder functionality
• openpnp/openpnp — Real-world Java/JavaCV user combining computer vision for robotics; good reference for industrial-grade FrameGrabber and image processing usage

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for FrameGrabber with multiple video formats

The repo has basic FrameGrabberTest.java but lacks tests for edge cases across different codecs (H.264, H.265, VP9) and containers (MP4, WebM, MKV). Given that FFmpeg 8.0.1 and OpenCV 4.13.0 are core dependencies, testing frame grabbing across these formats would catch regressions early and improve reliability for video processing pipelines.

• [ ] Review existing platform/src/test/java/org/bytedeco/javacv/FrameGrabberTest.java to understand current test coverage
• [ ] Create new test class FrameGrabberMultiFormatTest.java covering H.264, H.265, VP9, and AV1 codecs
• [ ] Add test cases for seeking, frame rate changes, and resolution handling across different containers
• [ ] Ensure tests use sample video files that can be committed or downloaded during CI (reference platform/src/test patterns)

Add GitHub Actions workflow for multi-platform native library validation

The repo has .github/workflows/javacv.yml but only basic CI. With dependencies on platform-specific natives (openblas, opencv, ffmpeg, libdc1394, libfreenect), there's no explicit validation that prebuilt binaries load correctly on Windows, Linux, and macOS. Adding a workflow that attempts to initialize these libraries on each platform would catch binary incompatibility issues early.

• [ ] Review existing .github/workflows/javacv.yml to understand current pipeline structure
• [ ] Create new workflow .github/workflows/native-libs-validation.yml with matrix for [ubuntu-latest, windows-latest, macos-latest]
• [ ] Add job that loads javacpp-presets natives and validates FrameGrabber, FrameRecorder initialization on each OS
• [ ] Include validation for OpenCV DNN module (referenced in samples like CaffeGooglenet.java, DeepLearningFaceDetection.java)

Add unit tests for FrameConverter edge cases and format support matrix

FrameConverterTest.java exists but appears minimal. Given the complexity of converting between BufferedImage, Mat, Frame across various color spaces (RGB, BGR, YUV), bit depths, and the heavy use of FrameConverter in samples (15+ sample files depend on it), comprehensive tests would prevent regressions when OpenCV or AWT APIs change.

• [ ] Review platform/src/test/java/org/bytedeco/javacv/FrameConverterTest.java for existing coverage gaps
• [ ] Create test matrix covering: RGB↔BGR, YUV420↔RGB, grayscale↔color, 8-bit↔16-bit conversions
• [ ] Add performance benchmark tests for large frame conversions (1080p, 4K) to catch performance regressions
• [ ] Test edge cases: null frames, zero-size frames, unsupported color space combinations with explicit assertions

• Add comprehensive unit tests for FrameConverter subclasses (OpenCVFrameConverter, FFmpegFrameConverter) currently lacking test coverage in platform/src/test/java/; write at least 3 roundtrip conversion tests per converter type
• Document the Frame class API and lifecycle (acquire → use → release) with Javadoc examples and a new platform/docs/FRAME_USAGE.md guide, since samples show varied usage patterns but no canonical reference
• Create a new SeekableByteArrayInputStream complement to SeekableByteArrayOutputStream (already exists in tests); implement Seekable interface for memory-backed input streams to enable non-file video sources in FrameGrabber

• High · Outdated FFmpeg Dependency — platform/pom.xml - ffmpeg-platform dependency. The FFmpeg platform dependency is pinned to version 8.0.1, which may contain known security vulnerabilities. FFmpeg is a critical multimedia library that processes untrusted media files and has a history of security issues including buffer overflows and code execution vulnerabilities. Fix: Regularly update FFmpeg to the latest stable version and monitor CVE databases for FFmpeg vulnerabilities. Consider implementing input validation and sandboxing for media processing operations.
• High · Outdated OpenCV Dependency — platform/pom.xml - opencv-platform dependency. OpenCV dependency is pinned to version 4.13.0, which is recent but should be regularly reviewed for security patches. OpenCV processes image/video data and can be vulnerable to malformed input attacks. Fix: Establish a dependency update policy for OpenCV. Monitor OpenCV security advisories and update promptly when security patches are released.
• Medium · Outdated Native Library Dependencies — platform/pom.xml - libdc1394-platform, libfreenect-platform, flycapture-platform dependencies. Several native library dependencies are pinned to older versions (libdc1394 v2.2.6-1.5.9, libfreenect v0.5.7-1.5.9, flycapture v2.13.3.31-1.5.9) that may no longer receive security updates. These are 5+ years old based on versioning. Fix: Evaluate if these legacy native libraries are still necessary. If required, review their security status. Consider replacing with actively maintained alternatives or implementing additional security controls around their usage.
• Medium · Snapshot Version in Parent POM — platform/pom.xml - parent version. The parent POM references javacpp-presets version 1.5.14-SNAPSHOT, which is a development/snapshot version. Snapshot versions may contain unstable code and are not recommended for production use. Fix: Use stable releases instead of snapshot versions for production deployments. Snapshot dependencies should only be used in development environments with appropriate controls.
• Medium · No Dependency Version Locking — platform/pom.xml. The pom.xml uses properties for versioning (e.g., ${javacpp.version}) but many dependencies use explicit version strings without lock files or Bill of Materials (BOM), increasing risk of transitive dependency issues. Fix: Implement Maven dependency lock files (maven-lockfile-plugin) and consider using a BOM (Bill of Materials) to explicitly manage all transitive dependencies. Run 'mvn dependency:tree' regularly to audit the dependency graph.
• Medium · Potential Code Injection via Frame Processing — src/main/java/org/bytedeco/javacv/FFmpegFrameFilter.java, FFmpegFrameGrabber.java. The codebase includes FFmpegFrameFilter, FFmpegFrameGrabber, and other frame processing utilities. Without proper input validation, untrusted media files could potentially trigger vulnerabilities in the underlying FFmpeg/OpenCV libraries. Fix: Implement strict input validation for all media files processed. Validate file headers, dimensions, and formats before processing. Consider using containerization to isolate media processing operations.
• Low · Missing SBOM (Software Bill of Materials) — Repository root. No evidence of generated SBOM (CycloneDX or SPDX format) in the repository structure, which complicates dependency tracking and vulnerability assessment for downstream consumers. Fix: Add Maven CycloneDX plugin to generate Software Bill of Materials during build. Include SBOM in release artifacts for supply chain security.
• Low · No Security Policy File — Repository root. No SECURITY.md file found in the repository to establish responsible disclosure procedures for security vulnerabilities. Fix: Create a SECURITY.md file documenting how to report security vulnerabilities responsibly, response timeframes, and contact information.
• Low · Travis CI Configuration Outdated — undefined. .travis.yml file may be using deprecated Travis CI features. GitHub Actions workflow exists but Travis CI configuration is still present, indicating potential inconsistency in CI/ Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/bytedeco/javacv shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live bytedeco/javacv repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/bytedeco/javacv.

What it runs against: a local clone of bytedeco/javacv — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in bytedeco/javacv | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 105 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of bytedeco/javacv. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/bytedeco/javacv.git
#   cd javacv
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of bytedeco/javacv and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "bytedeco/javacv(\\.git)?\\b" \\
  && ok "origin remote is bytedeco/javacv" \\
  || miss "origin remote is not bytedeco/javacv (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/main/java/org/bytedeco/javacv/Frame.java" \\
  && ok "src/main/java/org/bytedeco/javacv/Frame.java" \\
  || miss "missing critical file: src/main/java/org/bytedeco/javacv/Frame.java"
test -f "src/main/java/org/bytedeco/javacv/FrameGrabber.java" \\
  && ok "src/main/java/org/bytedeco/javacv/FrameGrabber.java" \\
  || miss "missing critical file: src/main/java/org/bytedeco/javacv/FrameGrabber.java"
test -f "src/main/java/org/bytedeco/javacv/FFmpegFrameGrabber.java" \\
  && ok "src/main/java/org/bytedeco/javacv/FFmpegFrameGrabber.java" \\
  || miss "missing critical file: src/main/java/org/bytedeco/javacv/FFmpegFrameGrabber.java"
test -f "src/main/java/org/bytedeco/javacv/FrameConverter.java" \\
  && ok "src/main/java/org/bytedeco/javacv/FrameConverter.java" \\
  || miss "missing critical file: src/main/java/org/bytedeco/javacv/FrameConverter.java"
test -f "src/main/java/org/bytedeco/javacv/FFmpegFrameRecorder.java" \\
  && ok "src/main/java/org/bytedeco/javacv/FFmpegFrameRecorder.java" \\
  || miss "missing critical file: src/main/java/org/bytedeco/javacv/FFmpegFrameRecorder.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 105 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~75d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/bytedeco/javacv"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.