424635328 opened a new pull request, #3955:
URL: https://github.com/apache/nuttx-apps/pull/3955
## Summary
Add V4L2 control commands, file output and display scaling to the nxcamera
test application, and single-frame JPEG/MJPEG decoding to nxcodec.
- `system/nxcamera`: add `set` / `get` / `query` shell commands for V4L2
controls
- `graphics/libyuv`, `system/nxcamera`: add the libyuv `HAVE_JPEG` build
switch and
pass `bytesused` as the libyuv sample size, so compressed frames are not
read
past their payload
- `system/nxcamera`: write captured frames to a file, in image or video mode
- `system/nxcodec`: decode a single JPEG/MJPEG frame, and drop the duplicate
decode log
- `system/nxcamera`: support RGB24 framebuffers, and scale/centre the preview
on all display paths
## Impact
Only the `nxcamera` and `nxcodec` applications and the libyuv build flags are
touched. No kernel API change. The existing framebuffer path keeps its
behaviour when the panel format is unchanged.
## Testing
Simulator, `sim:nxcamera` configuration with `CONFIG_SYSTEM_NXCODEC=y`, and a
`640x480` `testsrc` stream fed through `v4l2loopback`:
```Plain Text
nsh> mount -t hostfs -o fs=/home/mi/capture /host
nsh> nxcamera -h
nxcamera> input /dev/video0
nxcamera> output /host/frames.yuv 10
nxcamera> stream 640 480 30 YU12
nxcamera> q
nsh> ls -l /host
-rw-r--r-- 4608000 2026-11-02 12:57 frames.yuv
```
10 of 10 frames were captured with distinct MD5 sums, `Y` values in
`[16,235]`
and 169-172 distinct luma values per frame, so the payload is real image data
rather than a stale or zeroed buffer.
Single-image mode (`output /host/one.jpg`, no frame count) writes exactly one
frame, 460800 bytes.
The display path was checked with `output /dev/fb0` on a 32 bpp and a 24 bpp
simulator framebuffer. For a 640x480 capture on a 640x360 panel the preview
keeps the aspect ratio and centres itself, with 80 black pixels on each side
(`(640 - 480) / 2`), which exercises the `ARGBScale` path.
`checkpatch.sh -c -u -m -g <base>..HEAD` reports `All checks pass`, and
`make -j16` builds without warnings.
Not covered by this run:
- The libyuv `HAVE_JPEG` switch is keyed on `CONFIG_LIB_JPEG_TURBO`, which
has no
Kconfig entry in either tree today, so it stays off. MJPEG display was not
exercised; only `YU12` capture was.
- The v4l2m2m decode path in `nxcodec` needs `CONFIG_SIM_VIDEO_DECODER`,
which
depends on `VIDEOUTILS_OPENH264`; that library is not enabled in the tested
configuration, so `/dev/video1` was absent.
- The simulator camera registers no V4L2 controls, so `set`, `get` and
`query`
return `-ENOTTY` here. Argument parsing and the unknown-control branch were
checked instead.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
