Not really sure if this is a problem or not, or if it is, where is to “blame”.
I have put together a computer with a DSBOARD-ORNX Carrier Board and an NVIDIA Jetson Orin NX 16GB, plus the Magewell Eco Capture HDMI 4K+ M.2 capture card.
I have found that when I attempt to capture in 10-bits (i.e. the P010 pixel format) at UHD resolution I get odd artifacts across a middle band of the capture. At lower resolutions/bit-depth I do not get this issue. This suggests it occurs at higher bandwidth captures.
I have found that I can “fix” this issue by running jetson_clocks to max-out the computer. It is not enough just to set the power model to MAXN; I still get artifacts with this alone. I need to run jetson_clocks.
I’m not too sure which of the clocks (CPU? GPU? EMC?) need to be higher for this capture to work, but it strikes me that if I have set the power model to MAXN, shouldn’t things take care of themselves and the relevant clocks spin up to support the maximum transfer rate of the capture?
At the moment, in the capture/encoding software (which is my own) I am working around this by executing a system() (C library) command to run “nvpmodel -m 0 && jetson_clocks” at the start of the capture/encode and then reverting via “nvpmodel -m 0” at the end, but this strikes me as less than optimum. A single program shouldn’t really be dictating the entire power model of the computer…or is this ok?
HI, @oviano 4k is quite a high resolution, with higher data rates its best to enable the high performace mode as you are doing, using jetson-clocks. An easy way to check whats maxing out is using jtop, it shows the usage on CPU, EMC and GPU. It also will depend on the encoding algorithm, ie if it uses CPU. The orin nx supports hardware encoding, so you can use that to offload some CPU usage if thats you bottleneck, for example with nvv4l2h264enc
Although I haven’t proved it, I don’t think the encoding is having an impact. Regardless of encoding settings, it’s only when I reduce the capture input resolution that the issue goes away. Even if I capture in a lower resolution, it still happens if the input resolution is 4K60 P010, until I max out the clocks.
It seems like just the speed at which the Magewell card is able to deliver frames from the input is susceptible to one of the clocks.
Thank you for that suggestion, I will try and report back.
It would be nice if I didn’t have to do this though - if I can set to MAXN then I would have hoped that the clocks would run as fast as required for the task in hand.
The thing is I only would want it to be boosted for the duration of the capture/encode. When the machine is idle, I wouldn’t want all these clocks etc to be running at full speed.
Do the clocks not dynamically change at all then?
If not, then perhaps the best solution is at the start of capture/encode something like:
jetson_clocks store backup_dfs.conf && jetson_clocks
The best solution I found was the one above - have my application call the above commands via a C library system() call.
This works but obviously would be flawed if another application or user changed the clocks via the same method outside of my application, but this is not an issue in my scenario.
My gut feeling though is that as a developer I shouldn’t have to manually set the CPU clocks in this manner; the OS or whatever should recognise I am encoding/capturing/etc and raise the clocks accordingly as I have become used to on desktop OS etc.