2413648_en-US

[#1]

MX95: raw video write throughput limited to ~50MB/s

Hi, we're seeing a throughput/frame-rate issue when writing raw camera frames to a file: the actual capture rate drops well below the target frame rate once we write frames to storage, even though pure capture (without writing) runs at full frame rate. We'd like to understand the cause. The following is our environment configuration.

- Board: i.MX95 19x19 LPDDR5 EVK

- BSP: TechNexion Yocto 5.3 (Whinlatter), kernel 6.18.2

- Camera: TechNexion TEVS-AR0234 (MIPI CSI-2)

- Capture device confirmed via media-ctl: tevs → csidev-4ad30000.csi → formatter@20 → crossbar → mxc_isi.0 → /dev/video0

## Test 1: Capture only, no write (baseline)

Sensor locked to 30fps via:
v4l2-ctl -d /dev/v4l-subdev19 --set-subdev-fps pad=0,stream=0,fps=30

gst-launch-1.0 -e libcamerasrc ! video/x-raw,width=1920,height=1080,format=YUY2,framerate=30/1 ! fpsdisplaysink video-sink=fakesink text-overlay=false sync=false

Result: stable 29.98fps, no dropped frames.

## Test 2: Write raw frames to file

gst-launch-1.0 -e libcamerasrc ! video/x-raw,width=1920,height=1080,format=YUY2,framerate=30/1 ! filesink location=/tmp/test.yuv

Result: ~11.7fps (measured by file size / capture duration), with GStreamer logs showing repeated warnings:

WARN NxpNeoPipe neo_pipeline.cpp:3175 Image0 frame loss! expected X received Y

where the gap between expected/received grows over time when fps is not locked, but stays small (1-2 frames) once sensor fps is locked to match the target.

Same test repeated with `v4l2src device=/dev/video0` instead of `libcamerasrc`: same ~11.7-11.8fps result.

Same test repeated at 1280x720: ~28.8fps (~53 MB/s), which converts to a similar MB/s ceiling as the 1920x1080 test above (~52 MB/s).

We would like to know if a write speed limit of approximately 50 MB/s—when writing raw frames captured from `/dev/video0` (mxc-isi) to storage—is expected behavior for the current BSP/kernel version, or if we might be missing a configuration setting. We are happy to provide full logs, `media-ctl` topology output, and device tree information if needed.

Yocto ProjectRe: MX95: raw video write throughput limited to ~50MB/s

Hi,  @JosephAtNXP thank you for your prompt response.

I’d like to confirm whether the root cause lies in the following factor. Additionally, would using Real-Time Yocto be helpful in this case?

The captured frames are stored in a DMA buffer allocated via the Contiguous Memory Allocator (CMA). DMA writes from the ISP hardware to this memory have never been a bottleneck (local tmpfs write speeds reached up to 819 MB/s using dd, ruling out storage media limitations).

The bottleneck occurs during the step where the CPU reads the contents of this buffer. This is further corroborated by the fact that the VPU hardware encoder can directly read the same buffer via DMA without any performance impact. This strongly indicates that the bottleneck stems from the memory's cache attribute configuration or the cost of maintaining cache coherency (e.g., cache invalidation) during each buffer dequeue operation, rather than bus bandwidth or storage device speed limitations.

Re: MX95: raw video write throughput limited to ~50MB/s

Hi,

Thank you for your interest in NXP Semiconductor products,

This is expected behavior as you can see in Linux Users Guide.

In addition, writing frames to the file system generates a huge amount of data that is not absorbable in real time. In that case, because of the delay induced on the application to recycle its buffers, periodic frame loss is expected to occur.

A workaround could be to use hardware video encoding before storing the captured frames.

Regards