EdgeFirst Camera v2.9.0

EdgeFirst Camera v2.9.0

Installation

Download Binaries

Platform	Binary
Linux x86_64	edgefirst-camera-linux-x86_64
Linux ARM64	edgefirst-camera-linux-aarch64
Configuration	camera.default

# Download and install (ARM64 example)
wget https://github.com/EdgeFirstAI/camera/releases/download/v2.9.0/edgefirst-camera-linux-aarch64
chmod +x edgefirst-camera-linux-aarch64
sudo mv edgefirst-camera-linux-aarch64 /usr/local/bin/edgefirst-camera

# Install default configuration (optional)
sudo cp camera.default /etc/default/camera

What's Changed

Capture-rate honesty for the H.264 encoder, H.264 on by default, configurable
JPEG quality, and capture-loop resilience. Wire format is unchanged from 2.8.0.

Added

• Dropped-frame counters. Frames discarded because an encoder channel was
  full were previously invisible -- the discard arm was empty -- so an
  operator could not tell a captured frame from a discarded one, or know
  a recording had holes. Drops are now counted per sink and summarised in
  one rate-limited log line every 10s (EDGEAI-1403).
• camera.default documents RECORD, REPLAY, REPLAY_LOOP and
  REPLAY_FPS, which were settable from the environment but undocumented.
  RECORD writes continuously with no size cap or rotation, so leaving it
  set will fill the filesystem; that is now stated (EDGEAI-1403).

Changed

• The H.264 frame queue holds three frames instead of one. This is not
  what fixed the dropped frames above, and it changes nothing while the
  encoder keeps up -- the queue stays empty and latency is unchanged. It
  only matters under saturation, where it trades up to two frames of
  latency for frames that would otherwise be discarded outright:
  measured 6.9% loss down to 5.1% with JPEG encoding running
  (EDGEAI-1403).
• H.264 output is now on by default. It was off unless --h264 or
  H264=true was given, so a bare edgefirst-camera published no video
  at all. The service never saw this -- /etc/default/camera sets
  H264=true -- but it caught out every manual run. --h264 false and
  H264=false still turn it off (EDGEAI-1230).
• JPEG encodes at quality 85 by default instead of a hardcoded 100, and
  the quality is configurable via --jpeg-quality / JPEG_QUALITY
  (1-100). Measured at 1080p30 on a Verdin iMX8MP, this recovers about 3
  percentage points of CPU; enabling JPEG at all costs about 77, so
  quality is a weak lever and the setting is documented as such
  (EDGEAI-1230).
• SBOM CI installs its pinned Cargo tools with their published lockfiles,
  preventing newly released transitive dependencies from breaking release
  artifact generation.

Fixed

• The H.264 encoder is now told the frame rate the camera is actually
  configured for, read from the driver with VIDIOC_G_PARM, instead of a
  hardcoded 30. On a 1080p60 sensor the encoder was being told half the
  real rate, and that -- not queue depth -- was what made the capture
  path drop frames: measured 26 of 3600 frames lost over 60s before, and
  0 of 3601 after, on an otherwise idle device (EDGEAI-1403).
• The low-frame-rate warning compares against the configured rate rather
  than a fixed 30, so it can actually fire. At 1080p60 it previously
  could not warn until capture had collapsed below 27fps -- more than a
  55% drop went unreported (EDGEAI-1403).
• Recording metadata records the real capture rate rather than 30.
• Tile frame pacing is now phase locked to the requested rate. It
  restarted its interval from the instant a frame was accepted, so
  jitter pushed each deadline later and the error accumulated: a 30fps
  source asked for 15 measured 11.5, and asked for 10 measured 8.5. The
  deadline now advances by exactly one interval, and the interval is
  computed in nanoseconds rather than truncated milliseconds
  (EDGEAI-1230).
• STREAM_SIZE larger than CAMERA_SIZE is rejected at startup with an
  error naming both settings. The ISP scales down but never up, so the
  combination produced a stream the WebUI would not display, with no
  diagnostic (EDGEAI-1230).
• A failed camera read no longer kills the process on the first failure.
  vsl_camera_get_data reports a timeout by returning NULL, leaving
  videostream to surface whatever errno happened to hold, so the
  error cannot be trusted to distinguish a transient gap from a dead
  camera. The capture loop now spends a budget of 5 consecutive failures
  before giving up, logging each retry (EDGEAI-1403).
• H264_TILES_FPS=0 no longer divides by zero and takes the tile
  encoder threads down silently. Zero now means no limit, and is
  documented as such (EDGEAI-1403).
• Topic and frame-ID options are now settable from the environment.
  --frame-topic, --info-topic, --jpeg-topic, --h264-topic,
  --h264-tiles-topics, --base-frame-id and --camera-frame-id had a
  command-line flag but no env binding, so FRAME_TOPIC and friends
  were silently ignored -- including from /etc/default/camera, which
  systemd applies as an EnvironmentFile. All seven are now documented
  in camera.default (EDGEAI-1438).
• A calibration file that cannot be loaded no longer aborts the node.
  CAM_INFO_PATH pointing at a missing, unreadable, malformed, or
  structurally invalid JSON is now reported with a warning and the node
  continues on the same built-in defaults it uses when no calibration is
  configured, so camera/info keeps publishing. Calibration only
  describes the geometry on that one topic; losing it should not take the
  capture pipeline down, nor starve a subscriber that requires
  camera/info to exist (EDGEAI-1441).

---

Full Documentation: https://github.com/EdgeFirstAI/camera#readme