It seems by default AVCaptureVideoDataOutput converts frames to
kCMVideoCodecType_422YpCbCr8. (= kCMPixelFormat_422YpCbCr8)
Unfortunately it doesn't match what nokhwa decides to use
on my environment. (kCMPixelFormat_422YpCbCr8_yuvs)
This commit configures AVCaptureVideoDataOutput to use the same
pixel format. (Thus no conversions)
Only tested for kCMPixelFormat_422YpCbCr8_yuvs.
In a build script `cfg(target_os=...)` refers to the host, not the target. Using the `CARGO_CFG_TARGET_OS` environment variable sets the link parameters properly.
- Calling `stream.next` push internal buffers to v4l then call `stream.start`. By default with `new` buffer count is 4.
- #121 directly call `stream.start`, without setting any buffer. This result in v4l only having 1 buffer (I guess), so because there is no double buffer (or more), 1 frame out of two is skipped.
- Introduce a global array that keep track of every opened device
- A device can be shared between multiple capture backend, but only one can open the stream
- Cleaning of dropped device is done lazily
This release bump bindgen = "0.59" to bindgen = "0.65.1" which fix compilation error on ubuntu 20.04
# Changelog
## [0.14.0] - 2023-05-13
### Added
- Expose raw file descriptor of streams through `Stream::handle()` ### Changed
- Updated `bindgen` dependency to 0.65.1 ### Fixed
- Use proper C FFI struct field for `Integer64` controls
- Fix example in README.md to account for the negotiated pixelformat
```
error: failed to run custom build command for `v4l2-sys-mit v0.2.0`
Caused by:
process didn't exit successfully: `/home/naostage/dev/nokhwa/target/debug/build/v4l2-sys-mit-5048993d2f304be7/build-script-build` (exit status: 101)
--- stderr
thread 'main' panicked at '"v4l2_pix_format_union_(anonymous_at_/usr/include/linux/videodev2_h_493_2)" is not a valid Ident'
```
Includes:
- Use whole range of frame interval steps, including max.
- Start stream capture explicitly. While the v4l dependency can do that automatically when trying to fetch a frame, it will do so by providing several buffers that will end up not released properly by the Raspberry Pi V4L2 driver. Starting the capture explicitly allows us to only use a single buffer with proper lifecycle management.
This fixes lock contention that prevented any operations on the camera once capture loop is started by using a fair mutex instead of a regular one.
It's slightly more expensive, but this usecase - trying to access a shared resource that is repeatedly locked/unlocked by someone else - is exactly what it's designed for, and indeed it fixes the deadlock issue.
Fixes#111.
l1npengtul