image.png 328,24 Ko
0 téléchargement(s)
rdk-technical-support
#801
Posté 21 janvier 2026 - 12:31
image.png 328,24 Ko
0 téléchargement(s)
#802
Posté 21 janvier 2026 - 12:33
#803
Posté 21 janvier 2026 - 05:14
#804
Posté 22 janvier 2026 - 03:39
mipi_image_width:=640 mipi_image_height:=352 mipi_lpwm_enable:=True \
mipi_image_framerate:=15.0 need_rectify:=False height_min:=-10.0 \
height_max:=10.0 pc_max_depth:=5.0 \
save_dir:=/home/sunrise/Desktop/calib_data/ \
save_image_all:=True \
save_freq:=150
The images that are saved (left- and right respectively,) are they the raw or calibrated images?
#805
Posté 22 janvier 2026 - 04:41
#806
Posté 22 janvier 2026 - 04:27
#807
Posté 22 janvier 2026 - 04:50
#808
Posté 22 janvier 2026 - 10:47
If you find a tutorial online, they will show which version they used typically.
#809
Posté 22 janvier 2026 - 11:00
#810
Posté 27 janvier 2026 - 10:52
#811
Posté 27 janvier 2026 - 12:58
Target pipeline: UVC MJPEG :rightwards_arrow: HW JPEG decode :rightwards_arrow: VPS/VSE :rightwards_arrow: NPU (YOLO), with minimal CPU copies.
Questions:
- Is HW JPEG/MJPEG decode supported via hb_mm_mc/hbn?
- Can UVC DMABUF (VIDIOC_EXPBUF) be imported directly into codec/VPS, or is MMAP+copy required?
- Which sample is the best reference for USB camera :rightwards_arrow: inference?
- Recommended input format for YOLO (NV12 vs RGB)?
Thanks!
#812
Posté 27 janvier 2026 - 03:25
#813
Posté 27 janvier 2026 - 03:26
#814
Posté 27 janvier 2026 - 03:26
#815
Posté 28 janvier 2026 - 08:06
1. Best Reference: TogetheROS.Bot (TROS) For the "UVC :rightwards_arrow: Decode :rightwards_arrow: YOLO" workflow, we highly recommend using our TROS (TogetheROS.Bot) functional packages. We have already encapsulated high-performance nodes for UVC capture and hardware decoding, which will significantly simplify your development compared to calling low-level C APIs.
YOLO Box Reference: https://developer.d-.../detection/yolo
Model Conversion: [For optimizing your own YOLO model for RDK X5, check our Model Zoo / Ultralytics YOLO.](https://github.com/D...ltralytics_YOLO)
2. Hardware Decoding & Memory (DMABUF)
HW Decode: RDK X5 supports hardware JPEG/MJPEG decoding. You can find the low-level implementation details and C-dev demos here: [Multi-media SP Dev API](https://developer.d-...v_api/cdev_demo).
DMABUF: Most standard UVC drivers do not support direct DMABUF export (VIDIOC_EXPBUF). Typically, an explicit memcpy is required to move the data from the UVC buffer to ION/DMABUF memory before the hardware decoder or BPU can access it.
3. Input Format (NV12 vs RGB) From a performance standpoint, we strongly recommend NV12.
The hardware decoder outputs in NV12 format directly.
The BPU is highly optimized for NV12.
#816
Posté 28 janvier 2026 - 05:36
It confirms several key points for us, especially:
MJPEG/JPEG hardware decoding support on RDK X5
NV12 being the optimal internal format
and the practical limitation of DMABUF with standard UVC drivers.
We did look at TROS and we really like ROS in general. For robotic systems and rapid prototyping, it's clearly a great and powerfull solution and pôwerfull.
For this specific project though (multi-camera edge vision, always-on appliance, tight control over latency and resources), we plan to implement a standalone C/C++ pipeline directly on top of the SP multimedia APIs and BPU inference, without ROS. This gives us finer control over scheduling, memory usage, and performance.
That said, TROS is still very valuable for us as a reference implementation, especially for understanding the recommended UVC :rightwards_arrow: HW decode :rightwards_arrow: NV12 :rightwards_arrow: YOLO workflow. We may even prototype certain parts (like UVC capture) with TROS to validate behavior, then move to a lower-level implementation.
If you don't mind, we have a few follow-up questions to make sure we align with best practices on RDK X5:
For USB UVC MJPEG input (when DMABUF export is not available), is there a recommended method to copy the bitstream into HW-accessible memory (ION / media buffer) before feeding the SP decoder?
Is there any reference sample that shows the officially recommended buffer allocation + memcpy path?
After MJPEG HW decode (NV12 output), is it recommended to always pass the frames through VPS/VSE for resize/CSC before BPU, or can the decoder output be fed directly to the BPU if the resolution already matches the model input?
In multi-camera scenarios, is there any recommended practice for BPU job scheduling (single shared context vs per-pipeline contexts), or is a user-level scheduler the intended approach?
Thanks again for the guidance and the links - they are very useful for building an efficient and well-aligned pipeline on RDK X5.
#817
Posté 28 janvier 2026 - 08:15
#818
Posté 28 janvier 2026 - 11:10
#819
Posté 29 janvier 2026 - 02:06
When I run it however, the websocket streamer shows nothing on the address it is suppossed to. I have copied the original starter.py file and hardocded the changes, as it would ignore the options I set for it.
This is the log. My YOLO model is a pre-trained YOLOv11 model with 640x640 input. When I have dump_render true, it saves a single image.
#820
Posté 29 janvier 2026 - 03:44
13 utilisateur(s) li(sen)t ce sujet
0 members, 13 guests, 0 anonymous users






