Skip to content

docs: IMX335 at full resolution -- the encoder binds, and line WDR needs the sensor held to it - #259

Merged
widgetii merged 1 commit into
mainfrom
docs/imx335-full-res-encoder
Oct 11, 2026
Merged

widgetii merged 1 commit into
mainfrom
docs/imx335-full-res-encoder

Conversation

@widgetii

Copy link
Copy Markdown
Member

Adds a subsection to the IMX335 part of docs/high-framerate-modes.md. The existing tables stream 1920x1080, where the encoder is not the bottleneck. At the full 2592x1944 frame it is.

  • Encoder ceiling (gk7205v300, stock 30 fps mode, 60 s per reading): asked for 26, H.264 and H.265 both encode 21 fps and VI loses 5 frames a second. Asked for 20, both encode 20 and nothing is lost. That is about 107 Mpixel/s, the same rate as the hi3516ev300's 54 fps at 1080p and 121 fps at 720p in the HMAX table.

  • 5M line WDR: VI shares its buffer pool with the encoder, so each 2592x1944 keyframe costs a VI frame while the sensor runs at 22, even with the stream decimated to 20 or 15. With the sensor at 20, nothing is lost. A linear 30 fps sensor decimated to 20 loses nothing.

  • Ruled out, each changing nothing:

    • the ISP back end (VIPROC) clocked at 360 MHz via PERI_CRG63[3] rather than 257 MHz; its time per frame fell from 23.2 to 16.6 ms;
    • a bigger VB pool;
    • JPEG off.

    VI, VPSS and VEDU are already on their top documented clocks.

Documentation only.

…eds the sensor held to it

Encoding 2592x1944 on gk7205v300, H.264 and H.265 both top out at 21 fps
asked for 26 (VI losing 5 frames a second) and run clean at 20. In 5M line
WDR the sensor itself has to stay at 20: VI shares its buffer pool with the
encoder, and each 5 MP keyframe otherwise costs a VI frame even when the
stream is decimated. A faster ISP back-end clock (360 MHz via PERI_CRG63[3]),
a bigger VB pool and JPEG off each changed nothing.
@qodo-free-for-open-source-projects

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Grey Divider

Tip of the day
💡 Did you know, you can tweak Display settings with a live preview to see your comment before it ships

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects

Copy link
Copy Markdown

PR Summary by Qodo

Document IMX335 full-resolution encoder limits and WDR frame loss

📝 Documentation 🕐 Less than 10 minutes

Grey Divider

AI Description

• Document the gk7205v300’s full-resolution encoder ceiling and a loss-free 20 fps setting.
• Explain why 5M line WDR also needs the sensor held to 20 fps.
• Record clock, buffer-pool, and JPEG tests that did not prevent frame loss.
Diagram

graph TD
  S["IMX335 sensor"] --> V["VI capture"] --> B["Shared VB pool"] --> E["Video encoder"] --> O["Encoded stream"]
  E -. "keyframe stall" .-> B
  B -. "22 fps WDR" .-> L["VI frame loss"]
Loading
High-Level Assessment

Keep the measurements alongside the existing IMX335 mode tables. A separate document would split closely related frame-rate guidance without adding value.

Files changed (1) +41 / -0

Documentation (1) +41 / -0
high-framerate-modes.mdDocument full-resolution IMX335 encoding and line-WDR limits +41/-0

Document full-resolution IMX335 encoding and line-WDR limits

• Adds measured H.264 and H.265 rates at 2592×1944, identifying a roughly 21 fps encoder ceiling and a loss-free 20 fps setting. Explains why the 5M line-WDR sensor must also run at 20 fps, contrasts linear mode, and records unsuccessful clock, VB-pool, and JPEG mitigations.

docs/high-framerate-modes.md

@widgetii
widgetii merged commit 1111d82 into main Oct 11, 2026
35 checks passed
@widgetii
widgetii deleted the docs/imx335-full-res-encoder branch October 11, 2026 16:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant