Hi,
Thanks for pointing that out.
You’re right — my current line_length is set to 1493, which is indeed smaller than active_w = 3840, so it doesn’t align with the definition of horizontal timing size.
Coudl you please suggest the correct value for line length as per my specs I used. It would be a great help fo me as a beginner in camera porting.
hello Sunim_1,
let’s try with line_length = active_w = 3840.
Still get error here is the trace log:
cat /sys/kernel/debug/tracing/trace
kworker/0:9-148 [000] .... 106.634530: rtcpu_vinotify_event: tstamp:4058186756 cch:0 vi:0 tag:FS channel:0x00 frame:0 vi_tstamp:129860942528 data:0x0000000000000010
kworker/0:9-148 [000] .... 106.634533: rtcpu_vinotify_event: tstamp:4058186916 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:0 vi_tstamp:129860942528 data:0x0000000800000000
kworker/0:9-148 [000] .... 106.634534: rtcpu_vinotify_event: tstamp:4058187092 cch:0 vi:0 tag:CHANSEL_EMBED_SOF channel:0x23 frame:0 vi_tstamp:129860961984 data:0x0000000000000004
kworker/0:9-148 [000] .... 106.634535: rtcpu_vinotify_event: tstamp:4058187243 cch:0 vi:0 tag:CHANSEL_EMBED_EOF channel:0x23 frame:0 vi_tstamp:129860962432 data:0x0000000000000008
kworker/0:9-148 [000] .... 106.634535: rtcpu_vinotify_event: tstamp:4058187415 cch:0 vi:0 tag:ATOMP_EMB_DATA_DONE channel:0x23 frame:0 vi_tstamp:129860962944 data:0x0000000000000000
kworker/0:9-148 [000] .... 106.634536: rtcpu_vinotify_event: tstamp:4058187566 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:129860969664 data:0x000000000302008d
kworker/0:9-148 [000] .... 106.634537: rtcpu_vinotify_event: tstamp:4058187739 cch:0 vi:0 tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:129860982752 data:0x00000000000006e9
kworker/0:9-148 [000] .... 106.634537: rtcpu_vinotify_event: tstamp:4058187891 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:0 vi_tstamp:129861148928 data:0x0000000000000001
kworker/0:9-148 [000] .... 106.634538: rtcpu_vinotify_event: tstamp:4058188060 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:129861151648 data:0x000000000802008d
kworker/0:9-148 [000] .... 106.634538: rtcpu_vinotify_event: tstamp:4058188210 cch:0 vi:0 tag:CHANSEL_FAULT channel:0x23 frame:0 vi_tstamp:129861162208 data:0x0000000000000100
kworker/0:9-148 [000] .... 106.634539: rtcpu_vinotify_event: tstamp:4058188380 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:129861172928 data:0x000000000102008d
kworker/0:9-148 [000] .... 106.634540: rtcpu_vinotify_event: tstamp:4058299945 cch:0 vi:0 tag:FE channel:0x00 frame:0 vi_tstamp:129865511008 data:0x0000000000000020
kworker/0:9-148 [000] .... 106.634540: rtcpu_vinotify_event: tstamp:4058300121 cch:0 vi:0 tag:CHANSEL_SHORT_FRAME channel:0x01 frame:0 vi_tstamp:129865511008 data:0x0000200001000000
kworker/0:9-148 [000] .... 106.634541: rtcpu_vinotify_event: tstamp:4058300277 cch:0 vi:0 tag:ATOMP_FE channel:0x00 frame:0 vi_tstamp:129865511040 data:0x0000000800000000
kworker/0:9-148 [000] .... 106.634541: rtcpu_vinotify_event: tstamp:4058300444 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:129865551776 data:0xcd9ce50010000000
kworker/0:9-148 [000] .... 106.634542: rtcpu_vinotify_event: tstamp:4058300592 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:129865563712 data:0x000000003100008f
vi-output, imx2-2094 [000] … 106.644972: tegra_channel_capture_frame: sof:129.908613536
vi-output, imx2-2094 [000] … 106.644975: tegra_channel_capture_frame: eof:129.908638336
[ 99.952187] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 99.999640] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256
let me know what else you need, I need to solve this issue ASAP.
hello Sunim_1,
all right, according to the logs, it looks we’ve done parsing the embedded metadata lines.
there’s CHANSEL_PXL_SOF which means a frame-start has detected,
however, it’s follow by CHANSEL_FAULT and also CHANSEL_SHORT_FRAME, which means a frame has shorter than the configuration, it may also due to insufficient data coming from sensor.
please try reduce active_h for testing, please also aware that VI only support with even numbers.
hello Sunim_1,
it still has CHANSEL_SHORT_FRAME reported, and VI also don’t have CHANSEL_PXL_EOF detected as a complete frame.
you may try to reduce the active_h further for testing, please also double check the configuration on the sensor side.
Hi Sunim_1,
We have just released a working IMX283 driver running on Orin NX / Nano with JetPack 6 https://github.com/Kurokesu/imx283-jetson-driver
Different platform and JetPack from yours, but the sensor side is identical, so it might be useful as a cross-check baseline.
One thing that looks directly relevant: during our bring-up we hit the same corr_err: discarding frame ... err_data 256 symptom whenever the DT had embedded_metadata_height = 1, and we couldn’t get it stable across the EBD_X_OUT_SIZE (0x3A54/0x3A55) values we tried. The combination that’s been stable in our config is embedded_metadata_height = 0 together with EBD_X_OUT_SIZE = 0, i.e. EBD fully disabled.
Hope you find something in our driver that helps.
Thanks for sharing, it helped me a lot but once I added one single mode and goes for another modes to add like 3840*2160 it again gives me same frame discarding err 256 and I’m still confused how to solve this issue.
But while capturing raw img sensor is responding and capturing img but while reading fps it gives continous frame discarding issue err 256 and I am not be able to stream using nvarguscamerasrc plugin but my other modes streaming works.
Here is the attached trace log hope this helped you to understand my actual issue, I am facing.
trace_log.txt (147.6 KB)
hello Sunim_1,
this still an issue with sensor configuration, this means a line has more pixels than expected width, pixels dropped.
so, the VI/RCE thinks at least one received image line is longer than the configured width.
I have added another mode Horizontal/vertical 3/3-line binning where livestreaming works well but v4l2-ctl --stream-mmap -d /dev/video0 cmd output nothing.
Also during livestream, video feed looks misalign. Could you please help me which parameters likely cause this cut on the upper region of the livestream.
It would be great help, Thanks.
hello Sunim_1
it looks alignment issues, please note that, we should have follow VI’s 64 byte aligned to set the correct stride, you may give it a try to set the width alignment to 64.
For mode2 (1824x1216), V4L2 reports bytesperline = 3648, which is already divisible by 64. When you mention VI 64-byte alignment, do you mean the memory stride or the active image width itself must be aligned to 64 pixels? The sensor mode is a Sony-defined 3x3 binning mode with output size 1824x1216 from the vendor spreadsheet, and the symptom is a small corrupted/misaligned region at the top of the frame together with CHANSEL_NOMATCH/CHANSEL_FAULT events.
the width itself should follow VI’s width alignment, please try padding to 1856.
Thanks for your help.
I have solved that misalignment issue but I am unable to read fps or raw img capture but I am able to capture in jpg here the cmd I am using for capturing jpg
gst-launch-1.0 nvarguscamerasrc sensor-mode=2 num-buffers=10 ! ‘video/x-raw(memory:NVMM),width=1864,height=1234’ ! nvjpegenc ! filesink location=test.jpg
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1864,height=2134,pixelformat=RG10 --stream-mmap --stream-count=100
The above pipeline continously through error in dmesg:
[ 56.224429] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 56.256288] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 56.288149] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 56.319989] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256
[ 56.351861] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 256
hello Sunim_1,
did you have several sensor modes?
did you enable use_sensor_mode_id = "true"; for mode selection?
you should review your DT property, and please try again with following..
for instance, $ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1864,height=2134,pixelformat=RG10 --set-ctrl bypass_mode=0 --set-ctrl sensor_mode=2 --stream-mmap --stream-count=100
Yes, I have used sensor_mode_id = “true”;
I observe when I use this cmd here is the output:
v4l2-ctl -d /dev/video0 -c sensor_mode=2
v4l2-ctl --set-fmt-video=width=1864,height=1234,pixelformat=RG12 --stream-mmap --stream-count=300 -d /dev/video0
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps, dropped buffers: 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps, dropped buffers: 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps, dropped buffers: 1
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 31.38 fps
dmesg output:
[ 409.210510] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
[ 409.847790] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
[ 412.301310] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
hello Sunim_1
why you’ve different pixel format settings across your 2 tests?
My bad.. Correct format is v4l2-ctl --set-fmt-video=width=1864,height=1234,pixelformat=RG12 --stream-mmap --stream-count=300 -d /dev/video0
now there is no continous error in the dmesg log, but sometime after every few second it through error like this :
[ 177.302275] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
[ 185.108953] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 4194400
