Test Plan and Validation

Flash and Boot

This section provides information about the Flash and Boot test cases.

Check the Flash and Boot Using the flash.sh Script

To flash the target device:

Place the target device into recovery mode.
1. Power on the carrier board and hold the Recovery button.
2. Press the RESET button.

Note

You can also run the topo command to place device in recovery mode as mentioned in step 3. The topo command is supported only in Jetson Orin.

If you did not place the target device in recovery mode manually, run the topo command.

To download the customer release build from the server, run the following command:
(Optional) Start the serial console to check boot logs.
Flash the device.

Expected Result: The device will boot correctly without a crash or kernel panic. Refer to FlashingSupport for more information.

Check the Flash and Boot SDKM

Note

The following steps mention flashing of NVIDIA shared image on Jetson Platform. If you have a custom BSP, flash it first and then use SDKM only to install additional SDK packages.

Go to https://developer.nvidia.com/nvidia-sdk-manager and download sdkmanager.
- To install sdkmanager on your Ubuntu installation, run the following command.
- To install sdk manager using .deb on your system run the following command.
In a terminal window, to start SDK Manager, run the sdkmanager command.
In the SDK Manager launch screen, select the appropriate login tab for your account type: - NVIDIA Developer (developer.nvidia.com) - NVONLINE (partners.nvidia.com)
To connect serial console, run the sudo minicom -c on -w -D /dev/ttyACM0 command.

When you launch sdkmanager in step 1, your connected device should be identified/listed, for example, jetson AGX Orin.
To the target device into reset/recovery mode, complete the following tasks:
1. Make sure device is power ON, and if it is not, press the power button.
2. Press and hold the Recovery(RCM) button.
3. Press the Reset button.
4. Release the Recovery(RCM)* button
Select Host Machine, Target Hardware(Jetson AGX Orin), or the latest available version of JetPack.
Select Packages to install.
Select ALL the Product Category to be used to validate other feature use cases) continue to step 3.
Select Manual Setup - Jetson Agx Orin, Emmc as the storage device, and the user name/password to be set for the flashed image.

10.To debug a failure in the terminal tab in SDK manager, complete the steps in the SDK Manager User Guide<https://docs.nvidia.com/sdk-manager/index.html>_.

Select install.
To verify the flash, log in to the device.
Verify that the installation should completed successfully.

Expected Result: The device boot should complete without any crash or kernel panic, and all JetPack components should be installed properly on boot. Refer to https://docs.nvidia.com/sdk-manager/install-with-sdkm-jetson/index.html for more information.

NVME Boot

Before you begin, ensure that you have an NVME with the minimum of 16GB.

To flash the target device:

To place the target device in recovery mode, complete the following tasks:
1. Power on the carrier board and keep the Recovery button pressed.
2. Press the Reset button.

Note

You can also use the topo command to place the device in recovery mode.

If you have not yet manually placed the target device in recovery mode, run the topo command.

Download the customer release build from server.
(Optional) To check boot logs, start the serial console.
Flash the device.
Complete the set up, for example, typing the user name, the location, the timezone, and so on.
Log in to system.

NFS Boot

install the packages for NFS.
Complete the following steps to flash the target device:
1. Place the target device into recovery mode.
2. Power on the carrier board and press the Recovery button.
3. Press the Reset button.
Note

You can also use the topo command to place device in recovery mode.
Download the customer release build from the server.

If you have not yet manually placed the target device in recovery mode, run the topo command.
(Optional) To check boot logs, start the serial console.
Add the rootfs path to the /etc/exports directory.
Restart the NFS service.

Refer to To RCM boot to NFS for more information.
Just to make sure your NFS share is visible to the client, run the following command on the NFS server.
Run the rcm boot command.

For example, sudo ./flash.sh -N 10.24.212.249:$HOME/generic_release_aarch64/Linux_for_Tegra/Linux_for_Tegra/rootfs --rcm-boot jetson-agx-orin-devkit eth0
Complete the set up.
Log in to system.

Expected Result: The device should boot properly without a crash or kernel panic. Refer to https://forums.developer.nvidia.com/t/how-to-boot-from-nfs-on-xavier-nx/142505 for more information.

System Software

Detection of USB Hub (FS/HS/SS)

Boot the target.
Connect the USB Hub (FS/HS/SS) to one USB port in the target device.
Check on serial terminal.

Serial terminal will show you model and speed of the hub. You can also check the demsg logs for more information.
Connect the hub to the second port and check.

Expected Result: The USB hub should be enumerated on all USB ports of the target.

Detection of USB-3.0 Flashdrive (Hot plug-in)

Boot the target.
Connect the USB3 pendrive to one USB port of the target.
Using a serial terminal, check whether the flash drive has enumerated by running the lsusb command.

You can also check whether the drive is listed in the file browser and check the demsg logs for more information.
Copy the files to pendrive.
Complete steps 1-4 on all USB ports on the target.

Expected Result: The USB3 Pendrive should be detected on all of the USB ports of the target.

Note

Not all ports are USB 3.0 capable, so your device might operate at lower speeds. Review the relevant developer kit documentation to determine whether USB 3.0-capable ports.

Detecting the Keyboard

Boot the target.
Connect keyboard to the device.
Using a serial terminal, check whether the keyboard has enumerated by running the serial terminal command.
Press any key on keyboard to verify the functionality.

Expected Result: The keyboard should be successfully detected and functional.

Detecting the Mouse

Boot the target.
Connect the USB mouse to the device.
Using a serial terminal, check whether the mouse has enumerated.
Use the connected mouse to verify the functionality.

Expected Result: The mouse should be successfully detected and functional.

Cold Boot 10 Cycles

Boot the target.
Log in to the device.
Run the power down command, for example:
Press the power button.

Expected Result: The device should reboot successfully for each iterations without any kernel panic, failures, and errors.

Warm Boot 10 Cycles

Boot the target.
Log in to the device.
Run the sudo systemctl reboot command to warm boot the device.

Expected Result: The device should reboot successfully for each iterations without any kernel panic, failures, and errors.

Checking for Failures and Error Messages in dmesg

Boot the target.
Check the dmesg logs for failures and errors.

Expected Result: There should be no error and failures messages in the dmesg log.

Using the Display Port (DP)

Boot the target with the Display Port (DP) connected (1080P/4K).
Ensure that you see boot logo, framebuffer, and the desktop on the connected DP.

Expected Result: There should be no corruption on the display.

LP0-Resume Basic Functionality

Note

This check needs to be completed five times.

Boot the target.
Ensure that you can access the serial terminal, for example, ttyUSB0.
On the serial terminal, run the sudo systemctl suspend command.

Expected Result: The device suspend prints are displayed on the serial terminal and that the display is off.

You can wake up the device by using the connected USB keyboard.

UART I/O (Debug Print Messages)

Boot the target.
Ensure that you can access the serial terminal, for example, ttyUSB0.

Configuring the 40-Pin Expansion Header

Start Jetson-IO, and on the developer kit, run the following command:
The options to configure the I/O are displayed.
Complete the steps in https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide.
Save and reboot.
After configuring the pins, reboot the device.
Start the jetson-io.oy and check whether the pins have been configured for the selected option.

Refer to ConfiguringTheJetsonExpansionHeaders for more information.

Jetson-Linux WatchDog Timer Enable Verification

Boot the target.
On the serial console, to crash the system, run the following command.
Check WatchDog Timer reboots device after the timeout, for example, 180 seconds.

Expected Result: The device should be rebooted by the WatchDog Timer without errors and failures.

Verifying the Boot Time Services and Scripts

Verify that all boot time scripts are correctly initialized.
To check that there are no failures because of the scripts, run the following command.
To verify that the services/scripts start without failure/errors, run the following command.
Check serial logs during the device boot-up.

Expected Result: There should not be any errors.

nvpmodel: Setting and Verifying the Minimum and Maximum Power Modes

Note

Nvpmodel introduces different power modes on the Jetson platforms. The mode that is selected determines which CPU cores are used and the maximum frequency of the CPU and GPU.

To check the current power mode, boot the device and run the sudo nvpmodel -q command.
To set minimum power mode run the 'sudo nvpmodel -m x command.

In this command, x is min power mode.
To set the maximum supported power, run the sudo nvpmodel -m 0 command.
To check the maximum and minimum clocks for each power mode, run the sudo nvpmodel -q --verbose command.
Here are the power modes:
- sudo nvpmodel -m 0 — MAXN
- sudo nvpmodel -m 1 — MODE_15W
- sudo nvpmodel -m 2 — MODE_30W
- sudo nvpmodel -m 3 — MODE_50W

Detailed specifications about power modes are in the /etc/nvpmodel.conf the directory.

Expected Result: You should be able to set supported power model. The CPU/GPU frequency should be changed based on the selected power mode Refer to PlatformPowerAndPerformance for more information.

Running the tegrastats Command

Run the tegrastats command.

Expected Result: The specification values for active CPUs and GPUs should be reflected in the output:

07-11-2023 07:10:08 RAM 4601/63895MB (lfb 3x64MB) CPU [0%@729,0%@729,0%@729,0%@729,0%@729,0%@729,0%@729,0%@729,0%@729,0%@729,0%@729,0%@729] GR3D_FREQ 0% cv0@0C cpu@45.062C tboard@33.25C soc2@41.062C tdio
de@38.625C soc0@41.656C cv1@0C gpu@0C tj@45.062C soc1@40.781C cv2@0C VDD_GPU_SOC 3065mW/3065mW VDD_CPU_CV 766mW/766mW VIN_SYS_5V0 3623mW/3623mW NC 0mW/0mW VDDQ_VDD2_1V8AO 503mW/503mW NC 0mW/0mW

Graphics

Rendering the Graphics Binary on X11

Connect the display to the target and boot it after it flashes.
If gdm or lightdm is enabled, log in to the device.
To run X11 graphics binaries over SSH, ensure that auto-login is enabled on gdm and lightdm.
Export the DISPLAY variable, for example export DISPLAY=:0.
To check for various display modes that are supported by the display, run the following command.

Run a graphics binary on X11, run the following command.

$/usr/src/nvidia/graphics_demos/prebuilts/bin/x11/bubble

Expected Result: The graphics binary should render successfully on the display, and no corruption or hang should be observed while rendering. Refer to Graphics for more information.

Rendering GFX binary on EGLdevice (drm)

Connect the display to the target and boot it after flashing.

Stop GDM and if X is running on the target, kill it.

$ sudo service gdm stop (Stop GDM)
$ sudo pkill x

Load the NVIDIA drm module.
- For Jetson AGX Orin:
```
$ sudo modprobe nvidia_drm modeset=1
```
Run a graphics binary on egldevice.

Expected Result: The graphics binary should render successfully on the display. There should be no corruption or hang while rendering.

Rendering the Graphics Binary on wayland

Connect the display to the target and boot it after flashing.

If X is running on the target, kill it.

$ sudo service gdm stop (Stop GDM)
$ sudo pkill x3. Launch wayland using below commands.
$ unset DISPLAY

Run the following commands.

$ export WESTON_TTY=1
$ sudo XDG_RUNTIME_DIR=/tmp/xdg weston --tty=$WESTON_TTY --idle-time=0 &

Press Enter.

Run a graphics binary on wayland.

$ sudo XDG_RUNTIME_DIR=/tmp/xdg /usr/src/nvidia/graphics_demos/prebuilts/bin/wayland/bubble

Expected Result: The graphics binary should render successfully on the display. No corruption or hang should be observed while rendering.

Refer to Graphics for more information.

Kernel

Checking the Kernel Version

Boot the device.
To determine the kernel version number, run the uname -r command.

Expected Result: The Kernel version should display accordingly, for example, 5.16.0-tegra-g44acfbed970e.

Verifying Unloading of Kernel Modules Using modprobe

Log in to the device.
To locate the loaded, active module, run the lsmod command.

The output will list the active, and other dependent, modules (for example, x_tables 49152 5 xt_conntrack,iptable_filter,xt_addrtype,ip_tables,xt_MASQUERADE).
To remove this module, run the ‘sudo modprobe -r x_tables` command.

The following error message will display:

modprobe: FATAL: Module x_tables is in use

This message is expected because the module is being used by other modules that appear in the lsmod output against x_tables. You have to remove all modules that depend on x_tables and then remove the x_tables.
Remove modules that have no dependent modules.

This step will not throw an error like rtl8822ce.
Test the modules without dependencies, where “used by” is 0.
After the module is removed, removing it again will not print anything, for example, rtl8822ce , userspace_alert, so this outcome is expected.

Expected Result: Unloading of the module should happen without failure. No error/failure/warning/long delay should happen during, or after, the process, and the system should remain stable.

Verifying the Previous Hang log - last_kmsg/console-ramoops

To checks whether the console-ramoops, which are also known as the last_kmsg file, is being generated after a reboot when a system hang happens.

Power off the device using the Power button or by running the using command sudo poweroff command.
Manually power the device on again.
After the system boots up, ensure that there is no system node (/sys/fs/pstore/console-ramoops).
To complete a typical boot, run the $ sudo reboot command.
After the system boots up, run the sudo cat /sys/fs/pstore/console-ramoops-[0] command and check whether logs are being dumped into the generated file.
To trigger a kernel panic, run the $ sudo bash -c echo c > /proc/sysrq-trigger command.
Reboot device manually.
After system boots up, to check whether console_ramoops is generated, run the sudo cat /sys/fs/pstore/console-ramoops-[0] command.

The output should show show the watchdog timeout kernel messages.
Check for dmesg-ramoops-[0] logs for the dmesg logs.

console-ramoops-x where x is the numeric value generated run time.

Expected Result: When a system hangs, a console_ramoops file is generated under /sys/fs/pstore with enough information about previous hang.

Check DVFS Scaling

This procedure allows you to check whether Dynamic Voltage/Frequency Scaling (DVFS) and EMC scaling are working.

Before you begin:

Ensure that jetson_clocks is not active. (You can just reboot the device).
Verify that the nvpmodel setting is Max-N.

To verify this setting, run the sudo nvpmodel -m 0 command.

Keep device idle for five minutes.

Display and note down the CPU frequency values.

cat /sys/devices/system/cpu/cpu[0-9]/cpufreq/cpuinfo_cur_freq

Run CPU workload, such as the system benchmark, for example, SpecInt.
Observe change in freq values.

Expected Result: The values should be reflected in scaling nodes. To check change in CPU/GPU frequencies, you can also run the tegrastats command instead of the frequency scaling nodes.

CPU-therm System Throttle Alert Check

NVIDIA is providing users UI notifications when CPU temperature reaches the trip point. The CPU hot/thermal throttle alert persistent toast message appears in the upper right corner and ! appears in the task bar.

To raise the temperature of the device, run multiple apps/benchmark on the device for long time.
When the CPU temperature reaches the trip point, the CPU thermal warning toast message will appear.

Expected Result: You should see Hot surface alert when CPU temperature reaches the trip point. You should also see throttle-alert cooling state alerts on serial console. Refer to ThermalSpecifcations for more information.

Camera

Before you begin:

Install the v4l2 utility on the device.
Set the sensor-id based on the output from v4l2-ctl --list-devices (for example, /dev/video<0/1/2> where 0/1/2 are the sensor-id identified by v4l2-ctl

Device: Test Image Capture with Camera Devices

Start the argus camera app with every camera device capture image.
View the captured image.

Expected Result: You should be able to start the camera and capture the image. Refer to AcceleratedGstreamer for more information.

Device: Test Video Capture with Camera Devices

Start the argus camera app with every camera device capture video.
View the captured video.

Expected Result: You should be able to start the camera and capture the image. Refer to AcceleratedGstreamer for more information.

Turn on screen reader support.

To enable screen reader support, press Ctrl+Alt+Z. To learn about keyboard shortcuts, press Ctrl+slash for more information.

Verifying IMX274 Camera Sensor

To connect the IMX274 dual camera module to the target, run one of the following commands:
- nvargus_nvraw --sensorinfo --c <sensor-id1>
  
  For example, nvargus_nvraw --sensorinfo --c 0
- nvargus_nvraw --sensorinfo --c <sensor-id2>
  
  For example, nvargus_nvraw --sensorinfo --c 1
Verify that both sensors are detected.

Capturing a JPEG Image from Each Sensor

To capture a .jpeg image from each sensor, run one of the following commands:

nvargus_nvraw --c 0 --format jpg --file ${HOME}/frame-cam0
nvargus_nvraw --c 1 --format jpg --file ${HOME}/frame-cam1

Expected Result: You should be able to capture the image.

Capture an image using GStreamer

Note

Set the sensor-id based on the output by running the v4l2-ctl --list-devices command.

Run the following command.

gst-launch-1.0 nvarguscamerasrc num-buffers=1 sensor-id=0 ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12' ! nvjpegenc ! filesink location=${HOME}/gst-frame-cam0.jpg
gst-launch-1.0 nvarguscamerasrc num-buffers=1 sensor-id=1 ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12' ! nvjpegenc ! filesink location=${HOME}/gst-frame-cam1.jpg

Expected Result: You should be able to capture the image.

Capturing a Motion-JPEG Stream using GStreamer

Note

Set the sensor-id based on the output from running the v4l2-ctl --list-devices command.

Run the following command.

gst-launch-1.0 nvarguscamerasrc num-buffers=300 sensor-id=0 ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1' ! nvjpegenc !  avimux ! filesink location=${HOME}/mjpeg.avi -e

Expected Result: The motion-JPEG stream should get captured without crashes or errors.

Capturing Video from the Camera and Display

Note

Set the sensor-id based on the output from the v4l2-ctl --list-devices command.

Run the following command.

gst-launch-1.0 nvarguscamerasrc num-buffers=300 sensor-id=0 ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1' ! nvegltransform ! nveglglessink sync=0

Expected Result: You should be able to stream without crashes or errors.

Comms

WiFi AP Connectivity with WPA2 Security

Boot the device.
Open the GUI Wi-Fi settings and connect to AP with WPA2 security.

Expected Result: You should be able to connect selected Wi-Fi AP.

MM Content (YouTube|(TM) 1080p) Streaming Over WiFi

Connect to the Wi-Fi AP through the GUI or the command-line interface (CLI).
Ensure that the ethernet is disconnected.
Start the Chrome (TM) browser on the target.
Play any 1080P video on YouTube.

Expected Result: This test checks the Wi-Fi connectivity, and YouTube video playback should happen.

Setting up WiFi AP Connection over the Command-Line Interface

Flash the build that has no GUI installed.

If you have ubuntu-desktop, disable WiFi using WiFi settings after the boot is complete.
Boot the device and connect it to an AP using the command-line interface (CLI).
```
$ ifconfig -a
```
Note

If the WiFi is soft/hard blocked by the rfkill run command, run sudo rfkill unblock all.

Identify WiFi interface and configure it.

$ iwconfig
$ sudo ifconfig wlan0 up

$ sudo iwlist wlan0 scan | grep ESSID
$ sudo apt install wpasupplicant
$ wpa_passphrase YOUR_AP_NAME PASSWORD | sudo tee /etc/wpa_supplicant.conf
$ sudo wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0
8. Open another terminal: $ sudo systemctl stop NetworkManager
$ iwconfig
$ ifconfig wlan0
$ sudo ifconfig wlan0 up
$ sudo dhclient wlan0
$ ifconfig wlan0
$ ifconfig -a

Verify network connectivity.

$ping -I wlan0 8.8.8.8 (you can test your local IP)

Expected Result: The Wi-Fi should be turn on and be connected to AP, and the connection should be consistent and free from any drops.

Bluetooth Pairing and Unpairing

Boot the device.
Open the Bluetooth GUI settings.
Check nearby Bluetooth devices.
Pair the selected device, for example, the Bluetooth Keyboard.
To disconnect device, double click on connected device, and turn off the connection.
To permanently remove the device, click Remove disconnected device .

Expected Result: You should be able to pair selected device, for example the Bluetooth keyboard, and ensure that the connected device works properly.

Jetson-Linux: LAN Ethernet Browsing

Boot the device.
Connect the LAN cable to the device’s ethernet port.
In a terminal window, ping 8.8.8.8.

You can also test your local IP.

Expected Result: You should be able to ping www.google.com without any packet loss.

Multimedia Encode/Decode

Before you begin:

MM sample files should be available on device
The 4K display should be connected if required by test case.

Video Playback of the VP9_3840x2160_100mbps_30fps.webm File

This procedure verifies that the playback of a 4K video with VP9 codec is successful using nvgstplayer-1.0.

Before you begin*, ensure that your HDMI TV is connected and the X server and the Ubuntu desktop are running.

Log in to the device and open a terminal window.
Download or copy the Webm test clip (VP9_3840x2160_100mbps_30fps) to the device.

Run the following command.

$ nvgstplayer-1.0 -i <VP9_FILE_NAME>.webm --stats

Expected Result: Video playback should be smooth without any corruption and dropped frames.

MP3 Playback Test to Verify that MP3 Playback is Successful Using nvgstplayer-1

Before you begin, ensure the display is connected and that the X server and ubuntu desktop are running.

login to device and Open terminal
Download or Copy the MP3 test clip to device

Run the following command.

$ nvgstplayer-1.0 -i MP3_file.mp3 --stats

Expected Result: The MP3 playback should be fine with no glitches/corruption.

Decoding a JPEG File using nvgstplayer-1.0

Before you begin, ensure that the display is connected and the X server and the Ubuntu desktop are running.

Login to the device and open a terminal window.
Download or copy the JPEG image to the device.
Run the following command.
```
$ nvgstplayer-1.0 -i file.jpg
```

Expected Result: The JPEG decoding should be correct, and there should be no corruption with decoded image.

MP3 Streaming (Stream the MP3 file from an HTTP Server

Before you begin, ensure that the display is connected and the X server and the Ubuntu desktop are running.

Ensure that the host MP3 file is on the HTTP server for streaming.
Log in to the device and open a terminal window.
Navigate to the directory where MP3 file is located and run the following command.
```
$ python3 -m http.server 8001 &
```
Download or copy the MP3 image to the device.

Run the following command.

$ nvgstplayer-1.0 -i http://<IP_ADDR_OF_DEVICE>:8001/MP3_file.mp3 --stats

Expected Result: The Audio streaming should be with out noise and breaks, and there should be no hangs or crashed while streaming.

Streaming Audio and Video File from the HTTP Server

Before you begin, ensure that the display is connected and the X server and the Ubuntu desktop are running.

Ensure that the host MP3 file is on the HTTP server for streaming.
Log in to the device and open a terminal window.
Navigate to the directory where MP3 file is located and run the following command.
```
$ python3 -m http.server 8001 &
```
Download or copy the audio and video image to the device.

Run the following command.

$ nvgstplayer-1.0 -i  http://<IP_ADDR_OF_DEVICE>:8001/<VP9_FILE_NAME>.webm --stats

Expected Result: Video streaming should be with out distortion or issues, and there should be no hang or crash while streaming.

Decoding a JPEG File Using Using gst-launch-1.0

You can complete this task in one of the following ways:

Using nv3d sink

gst-launch-1.0 -v filesrc location=<JPEG_IMAGE_LOCATION><IMAGE_NAME>.jpg ! jpegparse ! nvv4l2decoder ! nvvidconv ! 'video/x-raw(memory:NVMM), format=RGBA' ! nv3dsink

Using nvegl sink

gst-launch-1.0 -v filesrc location=<JPEG_IMAGE_LOCATION><IMAGE_NAME>.jpg ! jpegparse ! nvv4l2decoder ! nvvidconv ! 'video/x-raw(memory:NVMM), format=RGBA' ! nvegltransform ! nveglglessink

Expected Result: The JPEG decoding should be correct, and there should be no corruption with the decoded image.

JEPG Encode using gst-launch-1.0

Run one of the following commands.

- gst-launch-1.0 videotestsrc num-buffers=1 ! 'video/x-raw, format=(string)I420' ! nvvidconv ! 'video/x-raw(memory:NVMM), width=1920, height=1080' ! nvjpegenc ! filesink location=${HOME}/frame.jpg

- gst-launch-1.0 -v filesrc location=${HOME}/frame.jpg ! jpegparse ! nvv4l2decoder ! nvvidconv ! 'video/x-raw(memory:NVMM), format=RGBA' ! nvegltransform ! nveglglessink JPEG encode should be proper. There should be no corruption with decoded image.

AUDIO+VIDEO rtsp streaming:H264+AAC

This procedure allows you to stream the clip link from an rtsp server.

Open the browser.
Stream the content from the rtsp server.
Open the link, for example, http://your_streaming_site.com/rtsp-server.html.
Click the AUDIO+VIDEO test file and stream.

Expected Result: Video streaming should have no distortion or issues, and there should be no hang or crash while streaming.

Camera Argus Samples

Compiling Argus SDK Samples Compilation and Running _cudahistogram

Run the following command.

cd /usr/src/jetson_multimedia_api/argus

Run the following command.

sudo apt-get install cmake; sudo apt-get install build-essential; sudo apt-get install pkg-config; sudo apt-get install libx11-dev; sudo apt-get install libgtk-3-dev; sudo apt-get install libexpat1-dev; sudo apt-get install libjpeg-dev; sudo apt-get install libgstreamer1.0-dev

Run the following command.
```
sudo mkdir build
```
Run the following command.
```
cd build
```
Run the following command.
```
sudo cmake ..
```
Run the following command.
```
cd samples/cudaHistogram
```
Run the following command.
```
sudo make
```
Run the following command.
```
sudo make install
```

Expected Result: No failures should be observed during the compilation, and the sample binary should exist and run without issues.

Compiling Argus SDK Samples and Running _gstvideoencode

Run the following command.

cd /usr/src/jetson_multimedia_api/argus

Run the following command.

sudo apt-get install cmake; sudo apt-get install build-essential; sudo apt-get install pkg-config; sudo apt-get install libx11-dev; sudo apt-get install libgtk-3-dev; sudo apt-get install libexpat1-dev; sudo apt-get install libjpeg-dev; sudo apt-get install libgstreamer1.0-dev

Run the following command.
```
sudo mkdir build
```
Run the following command.
```
cd build
```
Run the following command.
```
sudo cmake ..
```
Run the following command.
```
cd samples/gstVideoEncode
```
Run the following command.
```
sudo make
```
Run the following command.
```
sudo make install
```

Expected Result: No failures should be observed during compilation, and the sample binary should exist and run without issues.

Argus SDK samples compilation and run _multisensor

Before you begin, ensure that two camera sensors are connected to the device.

Run the following command.

cd /usr/src/jetson_multimedia_api/argus

Run the following command.

sudo apt-get install cmake; sudo apt-get install build-essential; sudo apt-get install pkg-config; sudo apt-get install libx11-dev; sudo apt-get install libgtk-3-dev; sudo apt-get install libexpat1-dev; sudo apt-get install libjpeg-dev; sudo apt-get install libgstreamer1.0-dev

Run the following command.
```
sudo mkdir build
```
Run the following command.
```
cd build
```
Run the following command.
```
sudo cmake ..
```
Run the following command.
```
cd samples/multiSensor
```
Run the following command.
```
sudo make
```
Run the following command.
```
sudo make install
```

Expected Result: No failures should be observed during compilation, and the sample binary should exist and run without issues.

Web Camera

Before you begin:

Ensure that gst-launch is available on the device with all dependencies installed.
identify the /dev/videX interface for the USB web cam.
Capture the video and encode it from the USB web cam.

Capture the video from the USB web cam in the MP4 format.

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=300 ! 'video/x-raw, width=640, height=480, format=(string)YUY2, framerate=(fraction)30/1' ! nvvidconv ! 'video/x-raw(memory:NVMM), format=(string)NV12' ! nvv4l2h264enc bitrate=8000000 ! h264parse ! qtmux ! filesink location=${HOME}/test.mp4 -e 2> /dev/null

Encode the captured video.

gst-launch-1.0 filesrc location=${HOME}/test.mp4 !  qtdemux ! h264parse ! nvv4l2decoder ! nvegltransform ! nveglglessink sync=0 2> /dev/null

Capture video from USB web cam in mjpeg.avi format.

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=300 ! 'video/x-raw, width=640, height=480, format=(string)YUY2, framerate=(fraction)30/1 ! nvvidconv ! 'video/x-raw(memory:NVMM), format=(string)I420' ! nvjpegenc !  avimux ! filesink location=${HOME}/mjpeg.avi -e 2> /dev/null

Encode the captured video.

gst-launch-1.0 filesrc location=${HOME}/mjpeg.avi ! avidemux ! jpegparse ! nvjpegdec ! nvegltransform ! nveglglessink sync=0 2> /dev/null

Expected Result: Video Capture and Video Encode should be successful using the USB web cam.

Capturing Video from a USB web cam and Display

Capture the video from the USB web cam and display it.

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=300 ! 'video/x-raw, width=640, height=480, format=(string)YUY2, framerate=(fraction)30/1 ! nvvidconv ! 'video/x-raw(memory:NVMM), format=(string)NV12' ! nvegltransform ! nveglglessink sync=0 2> /dev/null

Expected Result: The captured Video should successfully display.

Capturing Videos from a USB web cam and Running it Through TRT

Capture a video from the USB web cam and run it through TRT.

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=300 ! 'video/x-raw, width=640, height=480, format=(string)YUY2, framerate=(fraction)30/1' ! nvvidconv ! 'video/x-raw(memory:NVMM), format=(string)NV12' ! m.sink_0 nvstreammux width=640 height=480 name=m batch-size=1 ! nvinfer config-file-path=/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_infer_primary.txt batch_size=1 ! nvvidconv ! 'video/x-raw(memory:NVMM), format=RGBA' ! nvdsosd process-mode=1 ! nvegltransform ! nveglglessink sync=0 2> /dev/null

Expected Result: The captured video should successfully run through TRT.

CUDA Samples

Before you begin: Pre-condition

CUDA 12.2 should be installed on device with all dependencies.
install GitHub.

Native compilation of CUDA Samples/Apps on target device

Build the CUDA samples.

cd ${HOME}
git clone https://github.com/NVIDIA/cuda-samples.git
cd ${HOME}/cuda-samples
git checkout v12.2
sudo apt-get install libglfw3
sudo apt-get install libglfw3-dev
make clean
make

Expected Result: No error/failure should be observed during the compilation, and an executable binary file should appear after the compilation is complete. Refer to https://docs.nvidia.com/cuda/cuda-samples/index.html#getting-started-with-cuda-samples for more information.

Run CUDA Samples

Check the display TTY.

11:54:08 up 3 min,  2 users,  load average: 0.33, 0.14, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
ubuntu   ttyS0    -                11:50    0.00s  0.09s  0.04s w
ubuntu   :1       :1               11:53   ?xdm?  39.26s  0.04s /usr/lib/gdm3/g

Set up the DISPLAY environment variable based on the output in step 1.
```
export DISPLAY=:1
```

Run Bandwidth test sample applications.

cd ${HOME}/cuda-samples/bin/aarch64/linux/release
./bandwidthTest