424635328 opened a new pull request, #3960:
URL: https://github.com/apache/nuttx-apps/pull/3960
## Summary
Gate the libyuv JPEG support on `CONFIG_LIBJPEG` instead of
`CONFIG_LIB_JPEG_TURBO`.
The guard added earlier keys on `CONFIG_LIB_JPEG_TURBO`, but no Kconfig entry
defines that symbol in either nuttx or nuttx-apps, and it also points the
include path at `external/libjpeg-turbo`, which this repository does not
carry.
The condition was therefore always false, so `HAVE_JPEG` was never defined
and
`MJpegDecoder` was compiled out of every build.
`graphics/libjpeg` already exports its include directory through its
`Make.defs`, so the explicit include path is not needed.
## Impact
Only the libyuv build flags change. When `CONFIG_LIBJPEG=n`, the generated
flags are identical to before. When `CONFIG_LIBJPEG=y`, libyuv now compiles
`mjpeg_decoder.cc` with `HAVE_JPEG` and references the libjpeg decoder.
CMake parity is skipped on purpose: `graphics/libjpeg` has no
`CMakeLists.txt`, so it is absent from CMake builds and there is no libjpeg
target for the CMake side to depend on. The existing CMake stanza is left
untouched.
## Testing
Simulator, `sim:nxcamera` configuration with `CONFIG_LIBYUV=y` and
`CONFIG_LIBJPEG=y`.
Effect of the change, measured on the object file for `mjpeg_decoder.cc`:
| | unresolved `jpeg_*` symbols | object size |
|-|-|-|
| before | 0 | 3800 B |
| after | 16 | 62792 B |
The symbols include `jpeg_CreateDecompress`, `jpeg_read_header`,
`jpeg_start_decompress` and `jpeg_read_raw_data`, which is the decoder path
`MJPGToARGB()` uses.
A host-side check of the same libyuv sources, built with the newly enabled
`HAVE_JPEG`, decodes a 640x480 4:2:0 JPEG:
```Plain Text
MJPGSize ret=0 size 640x480 jpeg=14324
ConvertToARGB(FOURCC_MJPG) ret=0 640x480 nonblack=270425/307200
```
Built the same way without `HAVE_JPEG`, `MJPGSize` does not exist and the
link
fails, which is the behaviour every build had before this change.
Build and style checks:
- `make -j16` on `sim:nxcamera` completes with no warnings.
- `tools/checkpatch.sh -c -u -m` reports `All checks pass`.
- The existing `YU12` capture path still works: 10 of 10 frames captured,
4608000 bytes, 10 distinct MD5 sums, luma in `[16,235]`.
Not covered: capturing MJPEG from the host. `v4l2loopback` rejects
`VIDIOC_TRY_FMT` for `V4L2_PIX_FMT_JPEG` on this machine, so the simulator
never reaches the decode path. The decode path itself is covered by the host
check above.
--
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]
