We are getting an upper portion of each frame is repeated (image is attached).
While when I utilize the following command the video is not corrupted, though I get CPU utilization which is not acceptable by our system:
We are using r28.2.1 and with whatever version is available in Jetpack 3.3.
The pipeline with the framerate=60/1 field did not work on the Jetpack 3.3 version, while on the 28.2.1 it did work.
When we removed the field, we got the same result the higher lines were multiplied with the lower lines exactly as in the image in message #1.
I have tried to added the patches, though the whole video becomes shaky every second.
I have printed some debug output with the trace capabilities, and I have notices that every 5,000,000 [nSec] (I guess) rtos_queue_peek_from_isr_failed message is printed out.
It looks like when the encoding is applied to frame rate of 60 Fps the lines issue appears, while when the frame rate drops below, the video is encoded with a satisfying quality.
It is worth noting that I also see the following error in the terminal “MW_ACK_DONE syncpoint time out!0” error every frame (16.66mSec).
Hi,
Per message #5, if I have every frame a failure I guess that the frame size that I use is incorrect?
This is a portion of our device-tree which includes the frame definition:
Is our case the CSI video source provides the full frame to the Jetson via the CSI-2 port.
Does it mean that we need to set the encoding Gstreamer script line with the following parameters:
We cannot use 30 fps we only have 60fps as our video source can provide this frame rate.
The patch here is to modify the camera configuration (#5227866), while we are using a different video source. The problem that I do not understand how to figure out the reason for the failure. We see a good picture accept to the above mention issue.
How much do you propose to increase the clock by? set it to 90000000[Hz] ?
BTW, after running your command we got this message in the terminal: No vi channel is active
The clocks’ extension was already provided without any change.
I have run some comparison between L4T versions 31.1(Kernel 4.9) and 28.2.1(Kernel 4.4.38) and seems like some part of the patches that you proposed were implemented in 31.1 version, but not only.
I mean to changes which were applied to the vi4_fops.c file. Changes that deal with signal stability issues and etc.
Another thing that I’ve noticed which might confuse is the fact that in the new kernel the printout is:
“MW_ACK_DONE syncpoint time out!%d\n” while in the old one is “ATOMP_FE syncpt timeout! err = %d\n”, while both invoked in the tegra_channel_release_frame function.
I have figured out the problem that I had the chan->timeout parameter in the function tegra_channel_release_frame was equal to 0, once I have set it to -1 I was able to encode a satisfying stream at constant 60fps. This value set the wait for the completion of the frame receive to forever (per the kernel code, I’ll fix it later to an acceptable value).
Now… the problem is that when I try to encode 2 streams from two different sources the frame rate drops after 15 seconds to ~52fps ; when I encode 3 streams the frame rate drops after 15 seconds to ~33fps. No error s are displayed.
I have also increased the clock rate, and decreased the bitrate down to 4Mbps, without any changes.