@ShaneCCC, I do the same test using Jetpack3.1 with the same source,that video have no problem but jetpack4.2 have.
I dont think the problem is because of video source.raw dump image with no ISP?
Yes, the raw dump without ISP pipeline.
Is 720x288 uyvy16 format conversion related to this issue?
The TRM have tell the support format. uyvy16 is YUV422-8 bit?
21.10.1 Input Data Formats
NVCSI provides input to VI4 in one of several formats. The NVCSI pixel format specification) describes the pixel formats
presented through the NVCSI interface to VI4. In short, NVCSI can transmit the following pixel formats, at the following bus
widths:
• RAW 8ppc: RAW6, RAW7, RAW8, RAW10, RAW12, RAW14, embedded-8
• RGB 8ppc: RGB444, RGB555, RGB565
• RGB 4ppc: RGB666, RGB888
• YUV 8ppc: YUV420-8 legacy, YUV420-8 CSPS, YUV422-8
• YUV 4ppc: YUV422-10
• YUV mixed: YUV420-10 CSPS
Hello Shane,
I‘m still working on this.
This is my test between Jetpack3.1 and Jetpack4.2:
Input mipi video stream is the same: 720x288@50fps uyvy,the source video is display well without tx2,
Jetpack3.1:raw dump image is 768x288 and looks good.
Jetpack4.2:raw dump image is 720x288 and the image looks not aligned as my post#1.
I really dont know what is the difference between the two jetpack versions.
Could you please point me some?
Many thanks.
do you mean that the raw dump file being executed at different jetpack implementations cause different outputs and works in case of Jetpack 3.1 and doesn’t look well in case of JetPack 4.2?
And what if you do the raw file from Jetpack 4.2 implementation and run it on Jetpack 3.1 implementation? Will it look well? And vice versa?
I don’t get your question. Usually I check the raw file from the host or windows system like the 7yuv tool.
I do the jetpack upgrade from 3.1 to 4.2 because of the AI performance improvement.
There is two different video stream connect to tx2’ mipi csi port in my custom carrier board
:1080P and 720x288.
The 1080P video is display well on both of jetpack3.1 and jetpack4.2,but 720x288 not.
The only thing I do is flash tx2 to jetpack4.2 and modify mipi csi drivers to grab the video stream.
From the description above, it seems that raw file recorded with Jetpack 3.1 seems fine,
and the same stream recorded with Jetpack 4.2 differs lacking quality dramatically.
yes Andrey.
That’s weird! As you said 1080P without problem and the trace log show get the frame without problem. I have no idea any problem on TX2’s configure.
Thank you.
Since there is no better way to figure out the problem, I am going to read the source code like channel.c…
We had this exact problem.
I found that for some reason in nvidia/include/media/tegra_camera_core.h
TEGRA_STRIDE_ALIGNMENT was changed from 256 (in L4T 28) to 1 (in L4T 32_1).
Changing it back to 256 solved the problem.
This meant that image widths not multiples of 256 were not padded out to
the next multiple of 256. This only affected our composite input (width 720)
not the hd signals with widths of 1280 and 1920 (multiples of 256).
Porting a video capture driver from 28_1 to 32_1 was quite difficult.
Cary
yes cobrien， Many thanks for your information.
That define should be doesn’t matter. It’s the memory buffer alignment.
It does matter to my case.
Change TEGRA_STRIDE_ALIGNMENT 1 to 256, 720x288 video displayed well like Jetpack3.1
It seems that the issue has been resolved
Yes Andrey,as cobrien said in comment #34. Maybe there is a bug in Jetpack4.2.
Looking forward to a more detailed explanation from nvidia.