Conversation
One MPP build serves the CV610, the CV610_10B and the CV608, and the
encoder picks its limits per die at run time. For the CV608 the stock
B051 blob allows nothing wider than 2304 or larger than 2304x1296, so a
4M sensor on that die can only be cropped: ss_mpi_venc_create_chn
answers 0xa0088007 to a 2560x1440 channel.
Nothing ahead of the encoder is the limit. On a CV608 with an OS04D10,
VI, the ISP and VPSS carry the sensor's full 2560x1440 without loss or
error; only the per-die table in the encoder stops it.
Vendors ship the change themselves. An xrscam H4 CV608 firmware
(OS04D10, MPP V1.0.2.0 B051) and an H5SVX firmware built from the same
MPP set the CV608 branch to the 10B's geometry, and this commit copies
their values into the same nine places in our blobs, in place:
hi_venc.o vedu_drv_high_profile_support, CV608 branch
max width in MBs 144 -> 180
max MBs 11808 -> 18540
MB/s budget 0x67dc4 -> 0x85bf6
venc_drv_check_max_resolution, CV608 branch
max side 2304 -> 2880
max pixels 2304x1296 -> 2880x1620
venc_drv_get_video_default_resolution, CV608 branch
2304x1296 -> 2880x1620
hi_rc.o rc_drv_init_primary_param, CV608 entry
2304x1296 -> 2880x1620
Each replacement is the same length as the instruction or literal it
replaces; nothing moves, and no relocation is touched. `objdump -dr`
of old against new differs in exactly those nine lines.
What the table no longer says, the hardware still does: the CV608
encoder's throughput tops out near 103 Mpixel/s. Measured on the
board with these modules, 2560x1440 encodes at 28 fps when asked for
30, the encoder skipping about two ring frames a second whether the
stream is H.265 or H.264 and with or without a JPEG channel, and at
25 fps with no skips at all; 2304x1296 at 30 fps also skips nothing.
So the geometry is unlocked here, and the rate belongs in the sensor
mode file (Isp_FrameRate), the way the EV300's 5M imx335 is held at
20 fps.
Board-verified on a Hi3516CV608 + OS04D10: stream0 2560x1440 H.265
and H.264, 2560x1440 JPEG snapshots, sub-stream unaffected, no VI,
ISP, VPSS or VENC errors. CV610 and CV610_10B take other branches
of the same functions and are untouched.
Claude-Session: https://claude.ai/code/session_0135iarzELmev2nXzBx4SFLU
Code Review by QodoNo Changes in PRQodo reviewed your PR and found no changes in the codeTip of the day💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR |
johnchia
added a commit
to johnchia/raptor-hal
that referenced
this pull request
Sep 25, 2026
The 2304x1296 ceiling that the comments described as the CV608's is a per-die table in the vendor's encoder blob. openhisilicon now ships the encoder with the CV608 set to the 10B's 2880x1620, as xrscam's CV608 firmware does (OpenIPC/openhisilicon#228). With the table out of the way, the hardware limit shows: the CV608 encoder sustains about 103 Mpixel/s. Measured on a CV608 + OS04D10, 2560x1440 at 30 fps encodes 28, with two ring skips a second in H.265 and H.264 alike, and at 25 it skips none. A CV608 mode file can therefore either keep the vendor's crop in [vi_dev.hi3516cv608] or drop it and cap the sensor with [isp_image.hi3516cv608] Isp_FrameRate. The HAL's die-aware lookup already covers every section, and hisi_enc_fill_rc already clamps each stream to the sensor's rate, so neither needs code; this commit only brings the comments in line: the header bullet, a note at the Isp_FrameRate read, and the DevRect comment, which now explains both limits. Claude-Session: https://claude.ai/code/session_0135iarzELmev2nXzBx4SFLU
johnchia
added a commit
to johnchia/firmware
that referenced
this pull request
Sep 25, 2026
The CV608's 2304x1296 ceiling is a per-die table in the encoder blob, not the ISP clock: VI, the ISP and VPSS carry 2560x1440 cleanly on this die. Shipping CV608 firmware (xrscam H4, OS04D10, MPP B051) sets that table to the CV610_10B's values, and johnchia/openhisilicon 7184686 copies them into hi_venc.o and hi_rc.o. That commit sits directly on the upstream pin b922e19 and touches only the CV6xx blobs. It is offered upstream as OpenIPC/openhisilicon#228. With the table lifted the encoder still tops out near 103 Mpixel/s, so 2560x1440 at 30 encodes 28 and skips. The four 2560x1440 sensors (os04d10, gc4023, sc431hai, sc4336p) therefore drop the CV608 crop and cap the ISP at 25 fps instead, as the EV300 5M imx335 config does at 20; the HAL clamps every stream's rate to the sensor's. sc450ai and sc500ai keep the crop: they need 102 and 117 Mpixel/s at 25 and more media memory than the 20 MB zone has left. Their comment now gives that reason instead of the ISP clock. The pin and the INIs land together: without the patched encoder a 2560x1440 channel fails ss_mpi_venc_create_chn with 0xa0088007 and rvd fails at start. Board-tested on a CV608 + OS04D10 with the patched modules: main and sub stream at 25.0 fps, no encoder skips, 2560x1440 snapshot. The other three sensors are untested on this die. Claude-Session: https://claude.ai/code/session_011qHvUfNDKptXf41shaU1vE
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On a Hi3516CV608 the encoder refuses any channel wider than 2304 or larger than 2304x1296:
ss_mpi_venc_create_chnreturns0xa0088007for 2560x1440. A 4M sensor on this die can therefore only be cropped. This PR raises the CV608's limits to the CV610_10B's, 2880x1620, matching what shipping CV608 firmware does.Only the encoder's table was in the way
One MPP build serves the CV610, the CV610_10B and the CV608, and the encoder chooses its limits per die at run time. On a CV608 with an OS04D10, VI, the ISP and VPSS all carry the sensor's full 2560x1440 with no lost frames and no errors. The only thing that refuses it is the CV608 entry in the encoder's per-die table.
Vendors change that table themselves. An xrscam H4 CV608 firmware (OS04D10, MPP V1.0.2.0 B051, the same build as these blobs) gives the CV608 the 10B's geometry, and so does an H5SVX firmware built from the same MPP. This PR copies their values into the same nine places in our blobs:
hi_venc.ovedu_drv_high_profile_supportvenc_drv_check_max_resolutionvenc_drv_get_video_default_resolutionhi_rc.orc_drv_init_primary_paramEvery edit is in the CV608 branch of its function, so the CV610 and CV610_10B paths don't change. Each replacement is the same length as the instruction or literal it replaces. Nothing moves and no relocation is touched.
objdump -drof the old and new objects differs in exactly those nine lines.The frame rate still has to come down
With the geometry unlocked, the hardware's own limit shows. The CV608 encoder tops out near 103 Mpixel/s. Measured with these modules:
A full-size mode on this die therefore needs a lower sensor rate. That belongs in the sensor mode file, for example
[isp_image]Isp_FrameRate = 25, the same way the EV300's 5M imx335 is held at 20 fps. This PR only removes the size check that made cropping the sole option.Testing
Tested on a Hi3516CV608 + OS04D10, kernel 5.10:
The object code in this PR is byte-identical to the modules tested on the board.